@agent-native/core 0.130.2 → 0.131.2

package/corpus/templates/content/docs/product/capabilities/content.view.query.md

@@ -0,0 +1,106 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.view.query"
+name: "Database and Query Views"
+user_promise: "A View is one stable presentation over exactly one Database or Query, with its own downstream filters, layout, and renderer"
+primary_user_job: "Present and refine one collection for a particular workflow without changing the collection's identity or upstream meaning."
+kind: "surface"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.query.object", "content.property.typed"]
+related_features:
+  [
+    "content.feature.make-the-workspace-yours",
+    "content.feature.see-your-information-your-way",
+    "content.feature.understand-what-your-data-says",
+  ]
+roadmap_boundary: "feature"
+acceptance_summary: "Named Views retain stable identity and presentation over one owner input, bind configuration to stable fields, refine but never widen that input, and remain reusable without becoming collections or granting access."
+proof_requirements:
+  [
+    "Stable View identity, one owning Database/Query, default selection, links, embeds, templates, deletion, and copying",
+    "Renderer, visible fields, filters, sorts, groups, formatting, layout, and creation-seed ownership",
+    "Stable field bindings plus atomic cleanup or truthful degraded state during schema evolution",
+    "Access narrowing, shared Action parity, personal/effective state, accessibility, persistence, and recovery",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Database and Query Views
+
+## Why this exists
+
+The same collection can support very different work: quick List capture, a grouped Board, a Calendar, or an analytical Chart. People need to save those presentations without duplicating records, hiding a second collection beneath the screen, or confusing a temporary filter with the Query's meaning.
+
+## Example workflow
+
+A Projects Database has a shared Board grouped by Status and a private List showing only the current person's recent projects. Both are stable Views over the same Database. Changing the List filter does not change the Database or Board, and changing a project so it no longer matches simply moves it out of the List while preserving the record.
+
+## Product contract
+
+- A named View has stable identity and an addressable URL while belonging to exactly one Database or Query.
+- A Database or Query selects one default View. A link, embed, template, sidebar pin, or agent may address another named View directly.
+- The View owns renderer, visible fields, downstream filters, sorting, grouping, layout, formatting, collapsed state, and safe creation seeds.
+- Query filters define the upstream result contract. View filters refine what this presentation shows and can never widen past that input.
+- An ordinary View directly over a Database uses its implicit base Query; no hidden named Query is created.
+- **Save as new View** creates another View over the same owner. **Save as Query** appears on Query-building surfaces, not as ordinary View promotion.
+- **Create Query from this View** may prefill a builder with owner, filters, fields, and sorting, but the person confirms sources, output schema, variables, and write behavior before saving a separate Query.
+- A View binds to stable Property and Query-output IDs. Local aliases and formatting remain View-owned; matching display names never create semantic equivalence.
+- An embedding occurrence may select a named View and apply occurrence-local presentation overrides without mutating the saved View.
+- Deleting a View deletes only its configuration. Copying a View to another input creates a new View and explicitly maps compatible stable fields; a View never silently retargets itself.
+
+## Schema evolution and access
+
+- Renaming a bound field preserves the View automatically.
+- Before intentional deletion or incompatible type change, Content gives one compact impact summary. Confirmation applies the schema change and dependent cleanup as one attributable Revision.
+- Intentional deletion removes only affected filter leaves, sorts, groups, columns, seeds, or renderer bindings; unaffected configuration remains. Nested groups simplify and empty groups disappear.
+- Temporary source unavailability, permission loss, or stale provider schema is not deletion. The View preserves configuration and shows a typed degraded or Unavailable state rather than widening itself.
+- A View may be shared or **Only me** and may narrow access below its owner, never widen it. Effective visibility intersects View, Database/Query, Source, row, field, and viewer access.
+- Restricting a View protects the saved surface; it does not revoke access someone independently has to the underlying records elsewhere.
+- Private View cleanup and impact counts never expose private configuration to a schema editor.
+
+## Boundaries and non-goals
+
+- A View does not own records, source schemas, canonical values, Query variables, or provider write authority.
+- View filters control visibility, not validity. Database validation alone decides whether a mutation may commit.
+- A View never grants row access or runs with its creator's authority.
+- Sidebar is a navigation projection that may render a View; it is not a general View renderer owned here.
+- Renderer-specific behavior belongs to each View-family Capability and the shared conformance contract.
+
+## Acceptance stories
+
+### Preserve upstream meaning
+
+Given a Query that admits only published records and two Views with different downstream filters, when one View filter is removed, then it may reveal only other published Query results and never records excluded upstream.
+
+### Survive schema change coherently
+
+Given a View whose nested filter, grouping, and displayed column use one Property, when an authorized editor deletes that Property after one impact confirmation, then only the affected configuration is removed in the same Revision, unaffected settings remain, and Undo restores both schema and View.
+
+### Narrow without granting access
+
+Given an Only-me View over a shared Database and a shared link to another View, when readers open either, then each receives only the intersection they may already access and no View reveals private counts or records.
+
+### Delete presentation without deleting data
+
+Given a named View linked and embedded in several places, when it is deleted, then its configuration and references enter the normal broken/recovery state while the owner Database/Query and canonical records remain unchanged.
+
+## Current evidence
+
+Content already has useful saved Database Views, filters, sorting, grouping, and several renderers. The complete stable View identity, Database-or-Query ownership, private/shared alternatives, typed field bindings, schema-evolution cleanup, occurrence overrides, and renderer-conformance contract are not yet proven end to end. This Capability remains `approved_shape`.
+
+## Proof plan
+
+1. Create, link, embed, pin, copy, delete, restore, and select default named Views over both Databases and Queries.
+2. Exercise every shared renderer setting, downstream filter, sort, group, layout, formatting, and occurrence override through UI and Actions.
+3. Rename, delete, restore, and change types of local, custom, source, and Query-output fields; verify atomic cleanup versus degraded preservation.
+4. Run shared, Only-me, and occurrence-local Views under changing record/field/source access; verify no widening or derived leaks.
+5. Verify personal overrides, agent context, creation seeds, reload, concurrent shared edits, accessibility, export, and recovery.
+
+## Open questions
+
+The stable ID `content.view.query` sounds Query-specific even though the accepted concept is a general View over a Database or Query. Preserve the ID until a deliberate normalization provides a replacement. Exact ownership of named-View identity across this record, Shared Views, and Personal View State should remain this record for the generic primitive, with the others adding their focused policy.

package/corpus/templates/content/docs/product/capabilities/content.view.renderer-conformance.md

@@ -0,0 +1,77 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.view.renderer-conformance"
+name: "View renderer conformance"
+user_promise: "Every View obeys the same permissions, Actions, agent context, accessibility, persistence, performance, and recovery contract."
+primary_user_job: "Move between Views confidently because changing the renderer never changes what I may know, do, recover, or ask an agent to do."
+kind: "surface"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.renderer.typed", "content.view.query"]
+related_features: ["content.feature.see-your-information-your-way"]
+roadmap_boundary: "feature"
+acceptance_summary: "Every renderer consumes canonical access-scoped results and implements shared Actions, agent context, accessible interaction, persisted configuration, bounded performance, and truthful recovery."
+proof_requirements:
+  [
+    "Reusable conformance suite for result, permission, Action, and agent-context parity",
+    "Keyboard and assistive-technology, persistence, reload, failure, stale, and recovery fixtures",
+    "Representative renderer real-interface and performance-budget workflows",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# View renderer conformance
+
+## Why this exists
+
+Changing how a collection looks must not quietly change its authority. A renderer is a
+projection, not a new application hiding behind a pretty icon.
+
+## Example workflow
+
+An editor switches the same Database from Table to Timeline, asks the agent about the
+focused result, then reloads. Both surfaces use the same authorized records and Actions;
+each preserves only its own presentation settings.
+
+## Product contract
+
+- Every View renders its canonical Database or Query result after access evaluation.
+- Renderers use one typed Action and agent-context contract; UI affordances never widen authority.
+- Configuration, focused selection, empty, stale, unavailable, denied, and recovery states are explicit.
+- Keyboard and assistive-technology access, bounded loading, and persistence are conformance requirements.
+
+## Boundaries and non-goals
+
+Typed renderers and Queries supply common substrate. This does not force identical
+layouts, make every renderer writable, or replace renderer-specific product contracts.
+
+## Acceptance stories
+
+### Keep authority while changing renderer
+
+Given a viewer with partial row and field access, when they switch Views, then results,
+counts, previews, Actions, exports, and agent context disclose no additional information.
+
+### Recover consistently
+
+Given an unavailable query or a failed mutation, when any conforming View renders it,
+then it reports the state and retry or recovery route without presenting empty success.
+
+## Current evidence
+
+Timeline and existing Database renderers provide useful donor paths, but they do not
+prove a cross-renderer suite or complete contract. This Capability remains `approved_shape`.
+
+## Proof plan
+
+1. Create reusable fixtures for permissions, results, Actions, agent context, and state transitions.
+2. Run keyboard, assistive technology, persistence, recovery, and reload checks per renderer.
+3. Measure representative large-result workflows and test unavailable or stale inputs.
+
+## Open questions
+
+The first enforceable conformance-harness API and performance budgets need implementation design.

package/corpus/templates/content/docs/product/capabilities/content.view.scale.md

@@ -0,0 +1,77 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.view.scale"
+name: "Large Database performance"
+user_promise: "Databases stay responsive and incrementally queryable well beyond a few hundred rows"
+primary_user_job: "Find, change, and navigate a large authorized collection without waiting for every row to arrive or trusting an incomplete result as final."
+kind: "surface"
+state: "failing"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.view.query"]
+related_features: ["content.feature.see-your-information-your-way"]
+roadmap_boundary: "feature"
+acceptance_summary: "Views use server-side typed queries, bounded windows and aggregates, indexes, explicit partial states, and measured interaction budgets for large authorized collections."
+proof_requirements:
+  [
+    "Server-side filter, sort, pagination/window, index, cursor, and bounded-aggregate coverage",
+    "Partial-result, mutation, refresh, access-change, and unavailable-source correctness tests",
+    "Real-interface performance traces for representative large collections and renderer interactions",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Large Database performance
+
+## Why this exists
+
+A View that feels quick only while its collection is small has not yet earned the word
+View. Scale must preserve both responsiveness and truthful result boundaries.
+
+## Example workflow
+
+An editor filters a large Database, scrolls to another window, edits a visible record,
+and refreshes after another editor changes the result. The interface identifies partial
+loading and does not count unseen rows as if it had completed the query.
+
+## Product contract
+
+- Filtering, sorting, access evaluation, pagination, and aggregates execute against bounded typed results.
+- Windows, cursors, counts, totals, and loading state state whether results are complete, partial, stale, or unavailable.
+- Mutations reconcile with canonical results and do not silently retain a record that no longer matches.
+- Performance work preserves renderer conformance, accessible navigation, and Action parity.
+
+## Boundaries and non-goals
+
+Query execution owns collection semantics. This Capability is not a client-side cache
+excuse, a permission shortcut, or a promise of unbounded instant export.
+
+## Acceptance stories
+
+### Navigate a partial result honestly
+
+Given a large authorized result, when a viewer opens and scrolls it, then they can
+navigate incremental windows and distinguish loaded rows and totals from incomplete work.
+
+### Reconcile a changing collection
+
+Given a visible record changed to no longer match a filter, when the Action succeeds,
+then the View removes or repositions it truthfully without stale duplicate rows.
+
+## Current evidence
+
+The prior record is `failing`; existing View code does not constitute measured server-side
+query, budget, or real-interface proof. It remains `failing`.
+
+## Proof plan
+
+1. Benchmark indexed filters, sorts, cursors, windows, and bounded aggregates at representative sizes.
+2. Test partial, stale, access-changing, unavailable, and mutation-reconciliation states.
+3. Capture real UI traces for initial load, navigation, edit, refresh, and accessible keyboard use.
+
+## Open questions
+
+Target data sizes and interaction budgets need an agreed workload before a verified claim.

package/corpus/templates/content/docs/product/capabilities/content.view.source-query.md

@@ -0,0 +1,159 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.view.source-query"
+name: "Cross-source Queries"
+user_promise: "One visual typed Query composes authorized Databases, Sources, and Queries without copying their records or hiding where values come from."
+primary_user_job: "Combine related work from several places into one useful live result while keeping each record's owner, access, and write route clear."
+kind: "surface"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.query.object", "content.source.catalog"]
+related_features: ["content.feature.connect-your-sources"]
+roadmap_boundary: "feature"
+acceptance_summary: "A visual builder composes access-scoped Databases, governed Sources, and Queries with explicit stable-identity alignment and Query-owned outputs; every result retains provenance, and edits or creation route only through declared unambiguous authorized owners."
+proof_requirements:
+  [
+    "Visual and agent editing of one validated typed Query representation with sources, alignment, filters, joins, preview, renderers, scale, and cycle checks",
+    "Access-first provenance, source-qualified field identity, aliases/computed outputs, write-through, read-only derived outputs, and creation-route behavior",
+    "Lossless migration and compatibility verification from row-union and joined-detail donor machinery without treating either donor UI as the product contract",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Cross-source Queries
+
+## Why this exists
+
+Work often lives in several collections that people need to read together.
+Copying it into a third table produces stale duplicates and ambiguous writes.
+A cross-source Query provides one visual composition surface while leaving
+canonical records, stored values, access, and provider authority with the
+Databases and Sources that already own them.
+
+## Example workflow
+
+An editor creates a Query, adds two governed provider collections and a local
+Database, then aligns two stable title fields into an output field named
+`Title`. They add a relation-based join, a filter, and a Board renderer. Each
+result shows its Source provenance. Editing a mapped provider field routes only
+to its authorized owner; the `Title` alias and a computed score are Query-owned
+output and cannot be mistaken for stored source fields. Creating a new result
+uses a declared route or asks which source should own it.
+
+## Product contract
+
+### One visual builder and typed representation
+
+- A Query may compose authorized Databases, catalog-selected Sources, and other
+  Queries through unions, joins, relationships, filters, grouping, sorting,
+  limits, variables, and compatible renderers without creating a third
+  canonical row store.
+- The visual builder and agents manipulate the same validated typed Query AST.
+  Source selection, field alignment, rules, preview, and rendering remain
+  editable through ordinary controls; a textual inspector is optional, not a
+  separate authoring language.
+- Live preview places ambiguity, access exclusions, stale Sources,
+  write-through limits, cycle failures, and scale bounds beside the relevant
+  builder stage rather than returning an unexplained empty result.
+- Query-as-input remains lazy and access-scoped. Dependency and cycle analysis
+  occurs before save; pagination, traversal, aggregation, and cancellation
+  bounds prevent unbounded background work.
+
+### Align fields explicitly and retain provenance
+
+- Exact Custom Property or Source Property identities may align automatically.
+  Same display names do not establish equivalence: unrelated fields stay
+  source-qualified until a person or agent explicitly aligns them.
+- A named Query owns stable output-field identities, aliases, computed fields,
+  output types, documentation, ordering that is part of result meaning, and
+  compatible renderer defaults. Renaming `Title` changes the projection, not
+  either source schema.
+- Every result retains canonical record identity, source and field provenance,
+  freshness, access, and declared write capability. Viewer access applies before
+  results, groups, aggregates, counts, errors, and previews are computed.
+- A View presents and downstream-refines the Query result. It cannot widen the
+  Query contract or turn an output alias into a canonical source field.
+
+### Write and create only through an owner
+
+- An ordinary mapped field writes through only when canonical identity, stable
+  field mapping, authorization, Source policy, and provider capability are
+  unambiguous. Computed fields, aggregates, lossy alignments, and ambiguous
+  joined fields are read-only.
+- A Query declares zero or more creation routes terminating in writable
+  Databases or Sources. A View may select an applicable declared default but
+  cannot invent a destination; zero routes is read-only, one route proceeds,
+  and several routes require a permitted default or an explicit choice.
+- Existing row-union source identity, guarded writes, per-source bindings,
+  joined detail records, and source selection are donor and migration substrate.
+  Their specialized configuration surfaces are not the long-term product model.
+
+## Boundaries and non-goals
+
+- A Database owns a writable collection, schema, membership, validation, and
+  canonical create route. A Query derives a result and output contract. A View
+  presents and refines either input.
+- Sources catalog owns governed Source discovery; Source adapters own provider
+  operations and policy; this Capability does not create a generic provider API
+  or change source ownership.
+- A Query is not an access grant, static share, materialized clone, or a way to
+  infer field equivalence from names.
+
+## Acceptance stories
+
+### Align separate titles without changing either source
+
+Given two authorized collections expose distinct stable fields both labeled
+`Title`, when an editor explicitly aligns them into a Query output called
+`Title`, then the output has Query-owned identity while both source fields,
+schemas, provenance, and writes remain separate.
+
+### Write only when the route is clear
+
+Given a result with a mapped source field, a computed field, and an ambiguous
+joined field, when an authorized editor changes each one, then only the mapped
+field reaches its canonical owner; the computed and ambiguous fields remain
+read-only with an explanatory state.
+
+### Create through a declared source route
+
+Given a Query with two writable creation routes and a View with no applicable
+default, when a person creates a record, then Content presents a compact source
+choice and records the chosen owner's outcome. Given no route, creation is
+truthfully unavailable rather than guessed.
+
+## Current evidence
+
+Existing row-union and joined-detail machinery, source identity, guarded
+writes, field bindings, and source selection provide substantial donor
+implementation. They do not yet prove one visual typed Query experience,
+explicit output ownership, access-first nested composition, or complete
+write/create behavior. This Capability remains `approved_shape`.
+
+## Proof plan
+
+1. Build equivalent Queries through visual controls and agent Actions across
+   Databases, governed Sources, and nested Queries; compare AST, output schema,
+   preview, cycle checks, and compatible renderer behavior.
+2. Test stable field identities, qualified collisions, explicit alignments,
+   aliases, computed outputs, joins, filters, variables, provenance, freshness,
+   access-first results, counts, aggregates, pagination, and scale bounds.
+3. Exercise mapped write-through, derived-field refusal, zero/one/many creation
+   routes, defaults, validation, Source policy, provider receipts, conflicts,
+   retries, and mixed permissions.
+4. Migrate representative row-union and joined-detail configurations without
+   losing local rows, identities, write settings, review history, or Source
+   mappings, then complete the workflow through the real interface.
+
+## Open questions
+
+- The stable ID `content.view.source-query` lives in the View namespace even
+  though the accepted concept is a Query specialization. Preserve it for
+  compatibility until a deliberate graph-wide normalization defines a safe
+  replacement and migration path.
+- Exact materialization/cache strategy and the detailed visual controls for
+  complex joins, traversal, and scale warnings remain implementation work.

package/corpus/templates/content/docs/product/capabilities/content.view.timeline.md

@@ -0,0 +1,86 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.view.timeline"
+name: "Timeline View"
+user_promise: "Timeline places and directly edits canonical records across typed dates and ranges while obeying the View conformance contract."
+primary_user_job: "See work across time, adjust an authorized date or range directly, and understand what the timeline cannot safely infer."
+kind: "surface"
+state: "in_progress"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.time.types", "content.view.renderer-conformance"]
+related_features:
+  [
+    "content.feature.see-your-information-your-way",
+    "content.feature.plan-work-across-time",
+  ]
+roadmap_boundary: "feature"
+acceptance_summary: "Timeline renders canonical, access-scoped records across selected typed date or range Properties and edits them through shared Actions with conformance, recovery, and accessible navigation."
+proof_requirements:
+  [
+    "Typed date/range placement, end-date, undated, overlap, range navigation, and configuration persistence coverage",
+    "Shared Action edit, permission, history, optimistic recovery, and agent-context parity coverage",
+    "Real-interface keyboard, assistive-technology, responsive, reload, and unavailable-state workflow",
+  ]
+evidence:
+  [
+    "../../../app/components/editor/database/TimelineView.tsx",
+    "../../../app/components/editor/DocumentDatabase.test.ts",
+  ]
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Timeline View
+
+## Why this exists
+
+Time is an important projection of work, but a bar is never a schedule engine or a
+second record. Timeline makes typed temporal values visible and editable in place.
+
+## Example workflow
+
+An editor selects a date Property and optional end-date Property, moves to the next
+range, creates a dated record, and edits a card. The shared Action changes the canonical
+record; undated and unavailable records are reported rather than invented into a lane.
+
+## Product contract
+
+- Timeline consumes canonical, access-scoped results and configured typed dates or ranges.
+- Cards, overlap lanes, range controls, counts, and previews reflect authorized records only.
+- Direct edits and creation use shared Actions, validation, history, and recovery behavior.
+- Timeline is the current shallow renderer donor; Gantt is a composed mode/Feature, not proof of scheduling or a separate renderer contract.
+
+## Boundaries and non-goals
+
+Time types own temporal meaning; schedule constraints own dependency evaluation. Timeline
+does not infer dates, create a Gantt engine, or claim runtime feature-flag work not proven here.
+
+## Acceptance stories
+
+### Place a dated range
+
+Given authorized records with start and end date Properties, when a viewer opens Timeline,
+then overlapping cards appear in the selected range and an undated state is explicit.
+
+### Edit one canonical date
+
+Given an editable timeline card, when an editor changes its date, then the shared Action
+updates one canonical record, records history, and refreshes every authorized projection.
+
+## Current evidence
+
+`TimelineView.tsx` and `DocumentDatabase.test.ts` show a current Timeline renderer and
+date-window donor behavior. They do not prove the complete typed-time, Action-parity,
+conformance, accessibility, or recovery contract; this Capability remains `in_progress`.
+
+## Proof plan
+
+1. Test date-only, instant, ranges, end dates, undated records, overlaps, and range navigation.
+2. Verify Action edits, access closure, history, error rollback, and agent context.
+3. Run keyboard, assistive technology, responsive, reload, and unavailable-source workflows.
+
+## Open questions
+
+Precise Gantt composition and schedule-constraint visualization belong to their own Feature work.

package/corpus/templates/content/docs/product/capabilities/content.view.tree.md

@@ -0,0 +1,77 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.view.tree"
+name: "Tree View"
+user_promise: "Tree renders any suitable hierarchical Relationship without creating a parallel parent system."
+primary_user_job: "Navigate and change an authorized hierarchy while knowing that its structure is a typed relationship, not an accidental page parent."
+kind: "surface"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.relationship.edge", "content.view.renderer-conformance"]
+related_features: []
+roadmap_boundary: "supporting"
+acceptance_summary: "Tree renders a chosen hierarchical Relationship over canonical access-scoped results, supports authorized relationship edits, and preserves typed edge truth across expansion and arrangement."
+proof_requirements:
+  [
+    "Hierarchical relationship selection, roots, cycles, multi-parent or orphan policy, expansion, and configuration coverage",
+    "Shared typed Relationship Action, access-safe disclosure, history, and recovery coverage",
+    "Real-interface keyboard tree semantics, assistive technology, lazy loading, reload, and dense hierarchy workflow",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Tree View
+
+## Why this exists
+
+Some relationships are best read as nesting. Tree makes that shape useful without
+smuggling a universal parent field into Pages.
+
+## Example workflow
+
+A manager selects the `contains` relationship for a project View, expands a branch,
+and moves a task through the shared Relationship Action. The same edge remains visible
+in Connections and other authorized projections.
+
+## Product contract
+
+- Tree selects a suitable typed hierarchical Relationship and renders canonical nodes and edges.
+- Expansion, collapse, order, and focused state are View presentation; they do not redefine hierarchy.
+- Relationship creation, removal, and move use the shared typed Action with its constraints and history.
+- Access applies before roots, branch counts, labels, traversal, export, or agent context.
+
+## Boundaries and non-goals
+
+Relationships own semantic truth and cardinality. Tree is not Page-parent ownership,
+a sidebar model, a file system, or a separate hierarchy datastore.
+
+## Acceptance stories
+
+### Expand an authorized branch
+
+Given a hierarchy with inaccessible descendants, when a viewer expands a node, then no
+child label, count, or placeholder leaks inaccessible relationships.
+
+### Change a typed edge
+
+Given an editor allowed to alter a hierarchical edge, when they move a node, then the
+shared Relationship Action applies its cycle and cardinality rules and records history.
+
+## Current evidence
+
+The shared relationship boundary is prerequisite substrate; no complete Tree renderer
+contract is proven in the repository. This Capability remains `approved_shape`.
+
+## Proof plan
+
+1. Test roots, cycles, multiple parents, orphans, expansion, configuration, and lazy loading.
+2. Verify Action parity, access closure, history, concurrent changes, and recovery.
+3. Exercise ARIA tree navigation, keyboard moves, screen readers, reload, and dense branches.
+
+## Open questions
+
+The default policy for a relationship type that permits multiple parents needs design.

package/corpus/templates/content/docs/product/capabilities/content.workspace.multi-scope.md

@@ -0,0 +1,80 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.workspace.multi-scope"
+name: "Personal and organization contexts"
+user_promise: "One identity can hold personal Content plus several workspaces without account switching"
+primary_user_job: "Work in Personal and organization contexts under one identity without confusing their ownership, authority, or source of truth."
+kind: "primitive"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.access.page-database"]
+related_features:
+  [
+    "content.feature.find-your-place-again",
+    "content.feature.work-across-every-workspace",
+  ]
+roadmap_boundary: "feature"
+acceptance_summary: "One identity supports distinct Personal and organization contexts with visible current scope, explicit cross-context retrieval, organization opt-out, provenance, and audit."
+proof_requirements:
+  [
+    "Distinct context identity, current-scope switching, and ownership persistence coverage",
+    "Explicit cross-context retrieval, opt-out, access, provenance, and audit coverage",
+    "Revoked membership, unavailable context, agent context, reload, and recovery workflows",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Personal and organization contexts
+
+## Why this exists
+
+One person may carry private work and belong to many organizations. Convenience must not
+turn those distinct contexts into one leaking room.
+
+## Example workflow
+
+A person switches from Personal to an organization, then asks for an explicitly global
+search. Results carry their origin; an organization policy can exclude its work entirely.
+
+## Product contract
+
+- Personal and organization contexts remain distinct ownership and access domains under one identity.
+- Current context is visible; cross-context retrieval is explicit, access-scoped, policy-governed, and auditable.
+- Every returned object retains origin and opens under its owning context's authority.
+- Membership loss, deletion, stale state, and unavailable contexts are not restored as usable state.
+
+## Boundaries and non-goals
+
+This primitive informs Home and working sets. It does not create an organization, merge
+contexts, duplicate records, or make cross-context write implicit.
+
+## Acceptance stories
+
+### Switch without merging
+
+Given Personal and organization work, when a person changes current context, then only
+that scope is shown until they deliberately choose an allowed global retrieval.
+
+### Revoke a membership
+
+Given a previously visible organization item, when membership is revoked, then it no
+longer appears in navigation, Home, agent context, or session restoration.
+
+## Current evidence
+
+The architecture establishes the required distinction; no complete multi-scope interface,
+policy, provenance, and recovery proof is recorded. This remains `approved_shape`.
+
+## Proof plan
+
+1. Test scope switching, ownership, origin badges, global opt-in, and audit events.
+2. Verify organization opt-out and access changes across UI, Actions, search, and agents.
+3. Exercise revoked membership, unavailable context, reload, and recovery workflows.
+
+## Open questions
+
+The user-facing scope selector and default global-search posture need design.