@agent-native/core 0.130.2 → 0.131.2

package/corpus/templates/content/docs/product/capabilities/content.object.block.md

@@ -0,0 +1,76 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.object.block"
+name: "Blocks"
+user_promise: "A Block is a stable addressable unit of rich content inside its owning field."
+primary_user_job: "Edit and point to a meaningful part of content without fragile position-only anchors."
+kind: "primitive"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: []
+related_features:
+  ["content.feature.durable-foundations", "content.feature.living-references"]
+roadmap_boundary: "feature"
+acceptance_summary: "Every rich-content Block keeps a stable identity through edits, reordering, deletion, recovery, references, and Page-owned collaboration anchors."
+proof_requirements:
+  [
+    "Stable Block IDs across text and structured edits, reorder, deletion, and recovery",
+    "Reference serialization and rendering resolve by ID with access checks",
+    "Comment anchors retain historical target context",
+    "Shared Action/UI editing, conflict, undo, and reload behavior",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Blocks
+
+## Why this exists
+
+People comment on a paragraph, reuse a callout, and return to an exact idea. Positional text ranges alone drift; stable Blocks give those gestures a durable address.
+
+## Example workflow
+
+An editor moves a callout above a heading while a reviewer comments on it and another Page references it. The callout keeps its identity; the comment and reference still lead to the same material or its authorized historical context.
+
+## Product contract
+
+- A Block is a stable, typed content unit owned by one Blocks field; it is not a Page.
+- Editing text or typed props and reordering Blocks preserve identity whenever the logical Block survives.
+- References store Block identity, not renderer position. Comments remain Page-owned while targeting one or more Block anchors.
+- Deletion records an attributable historical target; recovery never silently reassigns an old anchor to unrelated new text.
+- One Action surface applies validation, access, Events, and concurrency behavior for people and agents.
+
+## Boundaries and non-goals
+
+- Blocks do not own independent Page access, Database membership, or top-level Properties.
+- A Block reference is not automatically a synced editable transclusion.
+- Blocks-field history owns the field revision sequence; this record owns the stable local unit.
+
+## Acceptance stories
+
+### Keep the comment on the intended material
+
+Given a comment anchored to a Block, when the Block is reordered and edited, then the anchor follows that Block. When it is deleted, then the comment opens authorized historical context rather than a similarly placed replacement.
+
+### Resolve a reference safely
+
+Given a Block reference in another Page, when an authorized reader opens it, then it resolves the canonical Block. When access is lost, then the renderer degrades without exposing its content.
+
+## Current evidence
+
+The current editor stores rich document content and supports anchored comments, but the repository does not yet demonstrate stable universal Block IDs, reference serialization, or recovery across all typed Block operations. This remains `approved_shape`.
+
+## Proof plan
+
+1. Test typed Block creation, edit, split, merge, move, deletion, restore, and undo.
+2. Verify comment, reference, and history anchors through each operation and reload.
+3. Exercise concurrent edits and stale restore through UI and shared Actions.
+4. Test inaccessible, unknown-renderer, and portable-export degradation.
+
+## Open questions
+
+Storage encoding and identity assignment timing remain implementation choices, provided logical Block identity and historical anchors survive.

package/corpus/templates/content/docs/product/capabilities/content.object.blocks-field.md

@@ -0,0 +1,79 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.object.blocks-field"
+name: "Blocks fields"
+user_promise: "Every editable rich-content body uses one Blocks-field grammar and keeps its own stable revision boundary."
+primary_user_job: "Write rich content in Pages and collaboration surfaces without each body inventing incompatible editing and history rules."
+kind: "primitive"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.object.block"]
+related_features:
+  [
+    "content.feature.durable-foundations",
+    "content.feature.collaborate-in-context",
+  ]
+roadmap_boundary: "feature"
+acceptance_summary: "Pages, additional rich fields, Comments, and Discussion messages use compatible typed Blocks while retaining distinct owner, field identity, access, and attributable revision history."
+proof_requirements:
+  [
+    "One grammar across each supported editable body",
+    "Stable field and Block identity with independent revision/recovery boundaries",
+    "Owner-scoped access and typed rendering including unavailable content",
+    "Shared Action/UI behavior for concurrency, history, and portable output",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Blocks fields
+
+## Why this exists
+
+An article, a comment, and a Discussion message should support the same useful content rather than forcing people into a plain-text side channel or making every small body a full Page.
+
+## Example workflow
+
+A reviewer writes a Comment containing a Page reference and a code Block, while an author keeps a research-notes field beside the Page body. Each body renders through the same grammar, but only the intended field is revised or recovered.
+
+## Product contract
+
+- A Blocks field is one editable rich-content body with stable identity and a canonical owning object.
+- Page bodies, additional rich fields, Comments, and Discussion messages reuse the grammar; their ownership and access do not collapse into one Page.
+- Field history distinguishes atomic Events, logical Revisions, recovery snapshots, and named Page Versions.
+- Typed Blocks preserve source when a renderer is unavailable and report a degraded state rather than dropping content.
+- A multi-field action can share causality while retaining which field changed.
+
+## Boundaries and non-goals
+
+- A Blocks field does not become a top-level Page, Database row, or sharing principal.
+- It does not decide Page Version branching, cross-field merge, or generic query history.
+- Shared grammar does not imply every renderer is supported in every host.
+
+## Acceptance stories
+
+### Reuse grammar without merging ownership
+
+Given a Page body and a Comment body containing references, when each is edited, then both use compatible Blocks while Comment access and history remain owned by the Comment's Page context.
+
+### Recover exactly one body
+
+Given a Page with two Blocks fields, when an authorized editor restores one field, then the other field, title, Properties, and memberships remain unchanged and a new attributable Revision records the recovery.
+
+## Current evidence
+
+The document editor proves rich Page-body editing and comments provide collaboration substrate. The repository does not yet prove one generalized Blocks-field grammar or independent field history across all owners; this remains `approved_shape`.
+
+## Proof plan
+
+1. Author equivalent typed content in every supported field owner and compare serialization/rendering.
+2. Verify per-field identity, history, recovery, deletion, and inaccessible rendering.
+3. Test agent, human, and automation edits with causal attribution and concurrent writes.
+4. Exercise UI, Actions, export, import, keyboard, and assistive technology paths.
+
+## Open questions
+
+The exact first set of non-Page field owners can grow incrementally; no owner may claim grammar compatibility without its own proof.

package/corpus/templates/content/docs/product/capabilities/content.object.database.md

@@ -0,0 +1,92 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.object.database"
+name: "Databases"
+user_promise: "Database as a Page-backed typed collection"
+primary_user_job: "Keep a durable set of Pages together with shared structure, rules, permissions, and one dependable place for new records to belong."
+kind: "primitive"
+state: "verified"
+publicness: "public"
+availability: "universal"
+dependencies: []
+related_features: ["content.feature.durable-foundations"]
+roadmap_boundary: "feature"
+acceptance_summary: "A Database owns canonical membership, membership-specific values, structure, validation, permissions, Rules, source bindings, and creation while every View evaluates its access-scoped base collection."
+proof_requirements:
+  [
+    "Stable Page-backed Database identity, membership, schema, and membership-specific values",
+    "Access-scoped implicit base Query shared by full-page and inline Views",
+    "Canonical creation and write Actions with validation, Rules, and source ownership",
+    "Reload, recovery, permissions, accessibility, and agent/UI parity",
+  ]
+evidence: ["../../../server/db/schema.ts"]
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Databases
+
+## Why this exists
+
+A collection is more than a table-shaped result. People need one governed place that owns which Pages belong, what shared structure applies, where a new item is created, and which rules or sources control its values.
+
+## Example workflow
+
+A marketing team creates a Content Calendar Database, adds Page records, defines Status and Publish date Properties, and builds Table and Calendar Views. Both Views show the same authorized members. Creating through either View creates one Page in the Database and applies its defaults and validation; changing presentation never manufactures a second collection.
+
+## Product contract
+
+- A Database is a Page-backed, stable Content object with its own identity, access, description, and Views.
+- It owns durable Page membership, membership-specific Property values, Property definitions, defaults, validation, Rules, source bindings, canonical creation, and canonical write routing.
+- A Page may belong to several Databases. Each Database owns only its membership and membership-local values; no Database becomes the Page's identity, primary parent, or universal read context.
+- Opening a Database evaluates an implicit base Query: every member the current viewer may access. This base relation is execution machinery, not a hidden named Query object.
+- Every Table, List, Board, Gallery, Calendar, Timeline, Form, Chart, or other Database View consumes that same base relation and adds downstream presentation and View filters.
+- Schema and values bind through stable Property IDs, never display names alone. Renaming preserves dependencies.
+- Creating through a Database or an unambiguous Database View creates the Page in this Database and applies safe defaults, View-derived seeds, validation, and Rules atomically.
+- UI, agents, automations, and APIs use the same typed Actions and authorization. A screen does not own a second mutation path.
+
+## Permissions and source behavior
+
+- The fixed roles are **Can view**, **Can comment**, **Can edit entries**, **Can edit database**, and **Full access**.
+- Personal filters and presentation do not require schema authority. Editing shared Views and structure follows Database-edit authority.
+- Source truth policy, provider grants, Property locks, and operation-specific guards may narrow an actor's role but never widen it.
+- A Database View or shared link reveals only rows and fields already authorized for that viewer.
+- Removing a Page from a Database removes that membership and its membership-local values; it does not delete the Page or its other memberships.
+
+## Boundaries and non-goals
+
+- A Database owns records and structure; a Query derives a collection without taking ownership; a View presents and refines one Database or Query.
+- The common query engine does not make every Database a named Query.
+- Database membership is not Page hierarchy, sidebar placement, or an access grant to other memberships.
+- A multi-source Query may compose several Databases, but it does not become a new Database unless someone explicitly creates a governed writable collection.
+
+## Acceptance stories
+
+### Render one collection several ways
+
+Given one Database with authorized and private members, when a viewer opens its Table and Calendar Views, then both evaluate the same access-scoped membership, preserve stable record identity, and reveal no private rows through counts or groups.
+
+### Create through the owning collection
+
+Given a Database View with unambiguous positive creation seeds, when an editor creates a row, then one Page gains this Database membership, valid seeds/defaults apply atomically, and the shared Action returns the same result as the UI.
+
+### Remove membership without deleting the Page
+
+Given a Page in two Databases, when an authorized editor removes it from one, then that membership and its local values disappear while the Page, its other membership, and Page-owned content remain intact and recoverable.
+
+## Current evidence
+
+The linked schema and existing Content actions implement Page-backed Databases, access-scoped rows, schema/value operations, and full-page and inline surfaces. This record remains `verified` for that atomic foundation. Derived Query composition, advanced View families, complete renderer conformance, and multi-source workflows retain their own proof gates.
+
+## Proof plan
+
+1. Exercise Database creation, membership, schema, values, defaults, validation, Rules, permissions, and deletion through UI and Actions.
+2. Verify the implicit base Query across full-page and embedded Views under row and field access changes.
+3. Create and edit through several View renderers; confirm one canonical Page and write path.
+4. Add and remove multi-membership while preserving Page identity and unrelated memberships.
+5. Test reload, concurrent edits, rollback, Undo, accessibility, agent context, and source-policy intersections.
+
+## Open questions
+
+No open product question changes this atomic foundation. Advanced query composition, custom reusable Properties, heterogeneous source collections, and renderer-specific behavior are documented separately.

package/corpus/templates/content/docs/product/capabilities/content.object.multi-membership.md

@@ -0,0 +1,75 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.object.multi-membership"
+name: "Multiple Database memberships"
+user_promise: "One Page can belong to several Databases without copies or a hidden primary home."
+primary_user_job: "Organize the same work for several legitimate collections without choosing which copy is true."
+kind: "primitive"
+state: "in_progress"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.object.page", "content.object.database"]
+related_features: ["content.feature.make-the-workspace-yours"]
+roadmap_boundary: "feature"
+acceptance_summary: "A Page retains one identity while each Database independently owns membership, membership-local values, access-scoped presentation, addition, and removal."
+proof_requirements:
+  [
+    "Plural membership reads and writes through UI and Actions",
+    "No primary-membership inference in identity, URL, access, or export",
+    "Remove one membership without deleting Page-owned content or other memberships",
+    "Grouped Info and recovery behavior under access and concurrent changes",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Multiple Database memberships
+
+## Why this exists
+
+A project can belong to a roadmap, a client portfolio, and a quarterly review. Copies make those lists disagree; a false primary home makes one view accidentally sovereign.
+
+## Example workflow
+
+An initiative Page appears in Projects and Launches. Each Database shows its own membership-specific fields. Removing it from Launches leaves the Page and Projects entry intact; Info groups the two memberships without naming one primary.
+
+## Product contract
+
+- A Page may have zero, one, or many Database memberships while keeping one Page identity.
+- Each Database owns its membership and membership-local values; Page-owned body, title, access, comments, and references remain common.
+- Adding or removing membership uses the Database's authorized Action, validation, source policy, and Events.
+- No URL, parent, export, agent context, or access decision infers a primary Database from membership order.
+- Info presents authorized memberships as a group; inaccessible memberships do not leak.
+
+## Boundaries and non-goals
+
+- Membership is not hierarchy, sidebar placement, a reference, or a share grant.
+- It does not merge conflicting Database schemas or values into Page properties.
+- Personal View order is separate from shared membership order.
+
+## Acceptance stories
+
+### Keep one Page across two collections
+
+Given a Page in two Databases, when it is edited from either, then both show the same Page-owned content while retaining their own membership-local values.
+
+### Remove only the selected membership
+
+Given a Page in two Databases, when an authorized editor removes it from one, then only that membership disappears and the Page, other membership, comments, and history remain recoverable.
+
+## Current evidence
+
+The Database data model and actions provide Page-backed collection substrate, and current product behavior supports several membership contexts. Complete plural APIs, grouped Info, and proof that no path infers a primary membership remain incomplete; this is `in_progress`.
+
+## Proof plan
+
+1. Add, display, edit, and remove memberships through all supported Views and Actions.
+2. Verify identity, URLs, access, export, search, and agent context with several memberships.
+3. Test source-managed membership, mixed permissions, trash/restore, and concurrent add/remove.
+4. Inspect Info grouping, keyboard, and assistive-technology behavior.
+
+## Open questions
+
+Membership-local property conflict presentation is owned by Database and typed-property work; it must not create a primary Page home.

package/corpus/templates/content/docs/product/capabilities/content.object.page.md

@@ -0,0 +1,76 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.object.page"
+name: "Pages"
+user_promise: "A durable Page keeps its identity, body, properties, access, discussion, and portable representation wherever it appears."
+primary_user_job: "Create work that can be found, shared, revised, and reused without losing what the work is."
+kind: "primitive"
+state: "verified"
+publicness: "public"
+availability: "universal"
+dependencies: []
+related_features: ["content.feature.durable-foundations"]
+roadmap_boundary: "feature"
+acceptance_summary: "A Page has one stable identity and owner-governed content/access context across editing, Database membership, URLs, comments, source operations, trash, and export."
+proof_requirements:
+  [
+    "Stable Page identity through move, rename, membership, trash, restore, and export",
+    "Authorized UI and Action reads/writes with identical access decisions",
+    "Portable Markdown/MDX body behavior without making serialization the live identity",
+    "Reload and recovery preserve Page content, context, and access boundaries",
+  ]
+evidence:
+  ["../../../server/db/schema.ts", "../../../actions/update-document.ts"]
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Pages
+
+## Why this exists
+
+A person needs a durable home for a piece of work, not a row that changes identity with its location or a file that cannot carry access and collaboration context.
+
+## Example workflow
+
+An editor creates a brief, adds body content and Properties, places it in two Databases, shares it with a colleague, then moves it in the sidebar. The same Page URL, comments, history, and source/export identity continue to refer to the brief.
+
+## Product contract
+
+- A Page owns stable identity, title, access, top-level Properties, and one or more Blocks fields.
+- A Database row is a Page; membership supplies collection context but never replaces Page identity or creates a primary membership.
+- UI, agents, automations, and APIs use shared Actions and the same authorization boundary.
+- References, comments, Discussion, history, Versions, sources, and exports target the Page identity, not a transient renderer or location.
+- Trash suspends ordinary use without silently reusing the identity; restore returns the Page with its durable context.
+
+## Boundaries and non-goals
+
+- A Page is not a Blocks field, Database membership, Query result, or named Version.
+- Page identity does not grant access to a source, another membership, or a referenced object.
+- The Page foundation does not itself define stable Block anchors, source synchronization, or Version branching.
+
+## Acceptance stories
+
+### Move without becoming another document
+
+Given a Page in two Databases, when an editor moves it in navigation or removes one membership, then its URL, body, comments, and remaining membership still resolve to the same Page.
+
+### Deny before revealing context
+
+Given a person who knows a Page link but lacks access, when they open it through UI or an Action, then they receive an honest denial and no title, body, membership, or comment data leaks.
+
+## Current evidence
+
+`server/db/schema.ts` defines durable document rows with IDs, content, ownership, source context, and trash fields. `update-document` persists Page changes through Actions and snapshots prior content; this proves the current Page foundation, not the future Block or Version contracts.
+
+## Proof plan
+
+1. Create, rename, move, multi-home, trash, restore, and export Pages through UI and Actions.
+2. Verify identical access decisions for direct links, search, memberships, comments, and agent reads.
+3. Reload during edits and recovery, confirming stable identity and no duplicate Page.
+4. Check keyboard and assistive-technology navigation and portable Markdown/MDX output.
+
+## Open questions
+
+No open product question changes the verified Page foundation. Richer Page property and source behavior belongs to its adjacent records.

package/corpus/templates/content/docs/product/capabilities/content.object.reference.md

@@ -0,0 +1,75 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.object.reference"
+name: "References"
+user_promise: "A compact reference points to a stable Page, Database, or Block without pretending to be computation."
+primary_user_job: "Mention and reuse a known object so people can navigate, render, and index the same identity everywhere."
+kind: "primitive"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.object.page", "content.object.block"]
+related_features: ["content.feature.living-references"]
+roadmap_boundary: "feature"
+acceptance_summary: "References store stable target identity plus presentation configuration, resolve under access control, remain portable, and stay distinct from expressions and semantic Relationships."
+proof_requirements:
+  [
+    "ID-based Page, Database, and Block resolution",
+    "Access-safe rendering, search, and backlinks",
+    "Portable encoding and explicit broken/deleted target states",
+    "Renderer inheritance and UI/Action parity",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# References
+
+## Why this exists
+
+People need an effortless `@`-style mention that is indexable and portable. Turning a simple reference into a program makes it harder to inspect, secure, and preserve.
+
+## Example workflow
+
+An author mentions a project Page in a brief and chooses a compact pill presentation. The target is later renamed and appears in another Database; the mention still resolves the stable Page and Connections can find it.
+
+## Product contract
+
+- A Reference stores the stable ID of a Page, Database, or Block with presentation configuration.
+- `@Page` is a Reference; accessing a Property, comparing, or traversing it is expression work.
+- Renderers may change presentation without changing target identity.
+- Resolution, backlinks, search, export, and agents apply target access before showing data.
+- Deleted, unavailable, and inaccessible targets are distinguishable only as far as authorization permits and degrade honestly.
+
+## Boundaries and non-goals
+
+- A Reference does not add Database membership, grant access, or create a semantic Relationship.
+- It is not a live embed or synced editable content; transclusion owns that behavior.
+- Expressions can consume references but do not replace the simple stored primitive.
+
+## Acceptance stories
+
+### Keep identity through a rename
+
+Given a Page reference rendered as a pill, when the target is renamed and moved, then the same reference resolves the renamed target without rewriting it as an expression or a new reference.
+
+### Do not leak a private target
+
+Given a reference to a Page a reader cannot access, when the reader opens, searches, exports, or asks an agent about the host Page, then the target's private content and metadata do not appear.
+
+## Current evidence
+
+Current Content can link Pages and has reference-like editor substrate. It does not yet prove a generic stable Reference value across Page, Database, and Block targets, portable degradation, or universal access-safe indexing; this remains `approved_shape`.
+
+## Proof plan
+
+1. Create and resolve each target kind through editor, Actions, search, backlinks, and agents.
+2. Rename, move, trash, restore, delete, and export targets; inspect encoded identity and degradation.
+3. Test access loss and restoration across every projection.
+4. Verify renderer variants, keyboard navigation, and assistive labels.
+
+## Open questions
+
+Presentation variants and source codecs may differ, but they cannot alter Reference identity or bypass access.

package/corpus/templates/content/docs/product/capabilities/content.object.transclusion.md

@@ -0,0 +1,75 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.object.transclusion"
+name: "Synced Blocks and live embeds"
+user_promise: "A Page or Block can appear by reference in several places and authorized edits change the one canonical object."
+primary_user_job: "Reuse maintained material without copy-and-paste drift."
+kind: "primitive"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.object.reference"]
+related_features: ["content.feature.living-references"]
+roadmap_boundary: "feature"
+acceptance_summary: "Live inclusion preserves canonical Page or Block identity, access intersection, provenance, history, and editing behavior while making fork and static snapshot modes explicit."
+proof_requirements:
+  [
+    "Canonical target identity and occurrence rendering",
+    "Explicit live, snapshot, and fork semantics",
+    "Access intersection and source/provenance affordances",
+    "Comment, Version, deletion, and portable-degradation behavior",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Synced Blocks and live embeds
+
+## Why this exists
+
+Repeated canonical language should update once. A copied paragraph grows quiet forks; a live inclusion keeps the work one living thing.
+
+## Example workflow
+
+A team includes its approved product-description Block in three guides. An authorized editor changes it from any occurrence, all authorized renderings update, and each occurrence offers the source/provenance context.
+
+## Product contract
+
+- A live transclusion renders one canonical Page or Block identity in another authorized host.
+- Editing a live occurrence invokes the target's shared Action and authority, never a synchronized copy.
+- Live inclusion, static snapshot, and editable fork are explicit modes with different update and provenance behavior.
+- The viewer must satisfy both host and target access; the render cannot widen either object's audience.
+- Comments, Discussion context, history, and Versions identify the canonical target and the viewing occurrence where useful.
+
+## Boundaries and non-goals
+
+- A compact Reference may preview a target but is not necessarily an editable live transclusion.
+- A transclusion does not merge Page identity, membership, access, or history with its host.
+- This record does not define source synchronization or arbitrary remote embeds.
+
+## Acceptance stories
+
+### Edit one canonical Block
+
+Given a live Block included in three Pages, when an authorized editor changes it from one occurrence, then every authorized occurrence shows the canonical update and one attributable history records the target change.
+
+### Preserve an intentional fork
+
+Given an editor chooses fork instead of live inclusion, when the source later changes, then the fork remains independent, retains provenance, and is not silently overwritten.
+
+## Current evidence
+
+Existing Page references and ordinary embedded Database surfaces are useful substrate. The repository does not yet prove stable editable Block transclusion, explicit mode selection, access intersection, or complete history behavior; this remains `approved_shape`.
+
+## Proof plan
+
+1. Render and edit live Page and Block inclusions from multiple hosts.
+2. Test live, snapshot, and fork conversion, source deletion, and portable export.
+3. Verify access changes, private hosts/targets, comments, Versions, and agent actions.
+4. Exercise concurrent target edits, undo, reload, keyboard, and assistive technology.
+
+## Open questions
+
+The exact occurrence controls and portable encoding can vary; the target identity and explicit mode distinctions cannot.

package/corpus/templates/content/docs/product/capabilities/content.organization.teams.md

@@ -0,0 +1,71 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.organization.teams"
+name: "Organization teams"
+user_promise: "Canonical framework-wide Team membership can be managed through Content without giving each app a conflicting identity system."
+primary_user_job: "Manage organizational Teams where work is configured while preserving one framework identity authority."
+kind: "primitive"
+state: "approved_shape"
+publicness: "public"
+availability: "organization"
+dependencies: ["content.workspace.multi-scope", "content.access.page-database"]
+related_features:
+  [
+    "content.feature.work-across-every-workspace",
+    "content.feature.share-how-your-organization-works",
+  ]
+roadmap_boundary: "feature"
+acceptance_summary: "Content manages the framework-wide Team representation through canonical organization identity and membership services."
+proof_requirements:
+  [
+    "Typed contract, authorization, validation, Event/history, and recovery coverage",
+    "Cross-surface UI, Action, agent-context, reload, and failure-state coverage",
+    "Real-interface keyboard and assistive-technology workflow coverage",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Organization teams
+
+## Why this exists
+
+One Team membership truth prevents each app from growing a conflicting roster. Content may manage it without becoming a second identity provider.
+
+## Example workflow
+
+An organization administrator creates a Team in Content, assigns members under the existing organization, and uses it in a Page access rule. Another app reads the same canonical Team membership.
+
+## Product contract
+
+Content manages the framework-wide Team representation through canonical organization identity and membership services. Team changes use authorized Actions, audit history, and propagate to compatible access and workflow surfaces.
+
+## Boundaries and non-goals
+
+Multi-scope and page/database access own context and authorization. This is not an app-local roster, automatic organization creation, or an alternate identity provider.
+
+## Acceptance stories
+
+### Deny an app-local roster edit
+
+Given a non-administrator, when they try to change Team membership, then the canonical Action denies it and no app-local fallback is created.
+
+### Propagate a canonical Team change
+
+Given a Team is used in a Page rule, when an authorized administrator changes membership, then compatible consumers observe the canonical membership with attributable audit history.
+
+## Current evidence
+
+No complete framework-wide Team management and consumer-consistency proof is recorded. This Capability remains `approved_shape`.
+
+## Proof plan
+
+1. Test canonical Team membership changes for administrators and non-administrators.
+2. Verify consumer reads, access rules, audit records, propagation, and no local fallback.
+3. Exercise revocation, sync conflict, organization boundaries, and accessible management.
+
+## Open questions
+
+The organization-admin delegation and membership-sync conflict policy need design.