RFC: govern sharing and isolation for exact context assets

Feature description

Define governed sharing and isolation for exact PowerContext context assets beyond the first Handoff access-control profile.

The design should let a principal share one immutable Memory entry version, Experience Revision, managed Skill Revision, or other explicitly supported context asset without granting the receiver access to the complete scope, future revisions, linked evidence bodies, or execution authority.

Problem and proposed solution

#1395 correctly establishes that scope_id is a business partition, not an ACL, and starts with exact Handoff transfer. Production collaboration also needs explicit sharing for other context assets and safe composition of those assets into PreparedContext.

Extend the same Server Policy Enforcement Point and replaceable authorization-provider boundary rather than adding resource-specific /share endpoints or embedding ACLs in Artifact content.

The RFC should define:

• exact resource identities for Memory entry versions and Artifact Revisions;
• actions for exact read, scope-level collaboration, evidence inspection, context composition, publication, and target projection;
• fixed roles and exact grants, including expiry and revocation;
• whether and how Sources, Prompt Templates, Context Profiles, and External Skills participate;
• safe list semantics that authorize identities before repository query and pagination;
• multi-resource authorization where every required decision must allow before composition or publication;
• how an exact asset grant differs from a scope role;
• Dashboard, CLI, HTTP, and MCP user flows for grant, revoke, inspect, and audit;
• migration and compatibility for deployments that use only the current static Bearer token.

Key invariants:

• latest is never an exact grant target.
• A grant for one Revision does not inherit to earlier or future Revisions.
• Reading one asset does not automatically reveal linked Source, Memory, Artifact, Handoff, or PreparedContext bodies.
• A Context Profile or bundle cannot amplify the caller's authority; every child resource and publication target is reauthorized.
• Approval, sharing, publication, installation, and execution remain separate decisions.

Acceptance criteria

• User A can grant User B access to one exact context asset and later revoke or expire that access without deleting immutable history.
• User B cannot read adjacent revisions, enumerate the full scope, resolve ungranted evidence bodies, or publish the asset unless separately authorized.
• The same principal/action/resource/policy input produces equivalent decisions over HTTP, MCP, and Dashboard paths.
• Unauthorized list operations do not load a complete repository page and filter it afterward.
• Multi-asset context preparation and Skill publication fail closed unless every required access decision allows.
• Audit records contain bounded identity, decision, resource, policy, request, time, and reason data only; they never contain tokens, complete context, prompts, provider bodies, or configured policy URLs.
• SQLite and OceanBase preserve the same public authorization behavior.

Alternatives considered

• Treat scope_id as tenant or authorization proof: breaks the current product boundary and permits caller-chosen identifiers to become credentials.
• Put ACL fields on every Artifact Family: couples immutable domain content to changing identity and policy lifecycles.
• Create /memory/share, /skill/share, and similar endpoints: duplicates one access-control model across domain APIs.
• Grant the complete scope whenever one asset is shared: exposes unrelated history and future revisions.

Additional context

Builds on #1395. Related lifecycle and identity work: #1397 and #1219.

• I am willing to contribute code, docs, or design feedback.

Start by reading #1395 and the related lifecycle and identity work in #1397 and #1219, then trace the current static Bearer token policy boundary. The RFC must cover equivalent authorization decisions across HTTP, MCP, and Dashboard paths, including SQLite and OceanBase behavior. Done means the design addresses exact grants, revocation, safe listing, multi-resource fail-closed composition, and bounded audit records.