feat: role scopes limited to what an installation owns

README.md

@@ -229,7 +229,7 @@ staging validated.
 **Rung 1 first; it is the one that matters (owner, 2026-10-21).** The loop:
 
 1. Cut a branch in module-saas-starter. accounts declares in its module
-   interface that it implements `codefly.dev/authority@0.2.0`, `codefly.dev/composition@0.1.0`,
+   interface that it implements `codefly.dev/authority@0.3.1`, `codefly.dev/composition@0.2.0`,
    `codefly.dev/installation@0.1.0` and `codefly.dev/session@0.2.0`, takes this repo's
    protos (bindings via `codefly generate proto`), and serves the four services as
    adapters over what it already has: `Issue` → StartTask / StartInstallationTask /
@@ -276,7 +276,7 @@ Gap 7 was a decision, taken on 2026-10-22: the interface carries the host's name
 ## The namespace, settled (2026-10-22)
 
 The interfaces are the host's contract, so they carry the host's names: publisher
-`codefly.dev` (ids `codefly.dev/authority@0.2.0`, `composition`, `installation`,
+`codefly.dev` (ids `codefly.dev/authority@0.3.1`, `composition`, `installation`,
 `installable`, `session`) and protobuf packages `host.authority.v1`,
 `host.composition.v1`, `host.installation.v1`, `host.session.v1` under `proto/host/`.
 Not `codefly.*`: the host's buf configuration excludes a `codefly/` proto directory
@@ -956,3 +956,40 @@ under the existing
 All consumers and implementations must select the updated interface versions;
 this repository updates its module, edge, hop and console declarations. SaaS
 must adopt the version and fields before claiming this contract.
+
+`codefly.dev/authority@0.3.1` adds `AttachResource` and `DetachResource`, and
+`codefly.dev/composition@0.2.0` adds `RoleV1.installation_owned_scopes`: a role
+scope held only on the resources its installation owns. The kind's one serving
+module attaches a resource from a capability holding `create` on the whole kind
+for a newly created resource. Existing resources change owner through
+`AuthorizeTransfer`: the serving module attests the current owner and presents
+a person's capability through the target installation. The existing policy
+requires that person's live organization admin grant on the resource and write
+through their target role, and refuses foreign owners, solution-principal
+owners, agents, missing grants and wrong provenance by name. Only after those
+checks succeed does the same transaction record the owned id. Admin-only
+`AttachResource` is refused with `AuthorizeTransfer` named; ordinary solution
+roles always retain their resource-owner selector. A resource has one owner per organisation,
+an installation owns at most 32 of a kind at a time, and the serving module
+detaches what it deletes and rolls back a create whose attach is refused. Both
+are additive. The local authority implements authority 0.3.1 and composition 0.2.0; the edge, hop and
+console call nothing new, so they require `>=0.2.0 <0.4.0` and resolve against
+a host still at 0.2.0. Shared conformance requires `InstallationResources`, so
+a host must implement both before it passes.
+
+The local authority keeps installation ownership in memory, for development
+only: a restart (a hot reload included) re-derives installations from the
+fixture but not what they own, so viewers lose owned resources until the store
+reconciles them through the authorized creation or transfer path. A host keeps ownership durably.
+
+The installation-owned resolver and ownership transactions live in
+`libraries/authority-core/go`, alongside the ordinary role resolver. Hosts
+persist `domain.Module.OwnedRoles` and `domain.Installation.Owned` through the
+shared Store contract. Ordinary roles retain main's resource-owner selection;
+installation-owned rows contain only attached ids, and an empty owned set emits
+no grant. The local host is an adapter to that core. Accounts adoption and
+its durable adapter are not qualified by a local authority test.
+
+The 0.3.1 authority version is an additive pre-stable revision selected for
+this refresh so existing `>=0.2.0 <0.4.0` consumers admit it. It retains 0.3.0's
+`AuthorizeTransfer` and adds attachment operations. Composition remains 0.2.0.

interfaces/authority/interface.codefly.yaml

@@ -2,10 +2,10 @@ kind: interface
 publisher: codefly.dev
 name: authority
 description: What a module or solution calls on its host to be issued, checked and verified authority. Implemented by accounts and by the local authority.
-version: 0.3.0
+version: 0.3.1
 type: connect
 protobuf:
     package: host.authority.v1
     services:
         - name: AuthorityService
-          methods: [Issue, Check, Keys, ListResources, AuthorizeTransfer, Delegate, RevokeDelegation, GetDelegation]
+          methods: [Issue, Check, Keys, ListResources, AuthorizeTransfer, AttachResource, DetachResource, Delegate, RevokeDelegation, GetDelegation]

libraries/authority-client/contract/catalog.codefly.json

@@ -10,7 +10,7 @@
       "kind": "protobuf",
       "package": "api",
       "path": "contract.binpb",
-      "digest": "sha256:f70c838a51dc2bfe1d95bfec4a1ab0f67d7bfd48ce60ccce58de30d342dce6c0",
+      "digest": "sha256:c991396ffbfdc2ec53c75e6dd9ea244a15951ad78bb0a99cf00e24a788cb9f74",
       "services": [
         {
           "name": "LocalService",