@agent-native/core 0.130.2 → 0.131.3

package/corpus/templates/content/docs/product/capabilities/content.layout.responsive.md

@@ -0,0 +1,80 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.layout.responsive"
+name: "Responsive Page layout"
+user_promise: "Pages arrange, resize, and reorder Blocks in columns that remain coherent on smaller screens and in exports."
+primary_user_job: "Arrange a Page for the work at hand while retaining readable, accessible content on any supported surface."
+kind: "surface"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.object.blocks-field", "content.renderer.typed"]
+related_features:
+  [
+    "content.feature.build-living-dashboards",
+    "content.feature.work-on-content-inside-another-application",
+  ]
+roadmap_boundary: "feature"
+acceptance_summary: "Page layout stores responsive Block arrangement separately from Block content and renders coherent, accessible columns across supported sizes and exports."
+proof_requirements:
+  [
+    "Column create, resize, reorder, persistence, conflict, and recovery coverage",
+    "Responsive, embed, export, keyboard, and assistive-technology coverage",
+    "Shared Action authorization, history, and canonical Block identity coverage",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Responsive Page layout
+
+## Why this exists
+
+Pages need room to breathe on a wide screen without becoming a pile of clipped fragments
+on a narrow one.
+
+## Example workflow
+
+An editor arranges live Blocks in two columns, reorders one, then opens the Page on a
+smaller screen. The readable order is preserved; each Block remains its canonical content.
+
+## Product contract
+
+- Layout stores arrangement and responsive rules separately from canonical Blocks and their content.
+- Authorized edits use shared Actions, history, recovery, and concurrent-change behavior.
+- Small surfaces and exports use a deterministic readable order, not hidden or duplicated content.
+- Keyboard and assistive technology can inspect and change supported layout operations.
+
+## Boundaries and non-goals
+
+Blocks fields own content. This is not a freeform Canvas, slide engine, or alternate Page
+identity.
+
+## Acceptance stories
+
+### Reflow a column layout
+
+Given a two-column Page, when a viewer opens it on a narrow surface, then Blocks appear
+once in a readable deterministic order without inaccessible overflow.
+
+### Keep Blocks canonical
+
+Given an editor reorders a Block, when another authorized View opens the Page, then it
+observes the same Block identity and changed layout without copied content.
+
+## Current evidence
+
+The product boundary is shaped, but no complete layout, responsive, export, and recovery
+proof is recorded. This Capability remains `approved_shape`.
+
+## Proof plan
+
+1. Test layout edits, persistence, undo, conflicts, and canonical Block identity.
+2. Test responsive and embed/export rendering across supported breakpoints.
+3. Exercise keyboard, screen reader, permission, reload, and failure recovery workflows.
+
+## Open questions
+
+The initial supported layout primitives and export fidelity thresholds need design.

package/corpus/templates/content/docs/product/capabilities/content.navigation.sidebar.md

@@ -0,0 +1,86 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.navigation.sidebar"
+name: "Personal sidebar"
+user_promise: "The sidebar is a personal navigation surface with pinned references and query-backed dynamic sections, not object hierarchy."
+primary_user_job: "Return to my important work and discover authorized dynamic collections without changing shared object structure."
+kind: "surface"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.object.reference", "content.query.object"]
+related_features:
+  [
+    "content.feature.find-your-place-again",
+    "content.feature.make-the-workspace-yours",
+  ]
+roadmap_boundary: "feature"
+acceptance_summary: "A personal sidebar stores pinned References and dynamic query sections, supports intentional expansion and order, and never treats navigation placement as object parentage or shared mutation."
+proof_requirements:
+  [
+    "Personal pin, order, expand, collapse, query-section, and reload coverage",
+    "Access-safe section results, counts, previews, stale references, and dynamic recovery coverage",
+    "Keyboard, screen-reader, responsive, agent-context, and shared-mutation-denial workflows",
+  ]
+evidence:
+  [
+    "../../../app/components/sidebar/document-sidebar-sections.test.ts",
+    "../../../app/components/editor/database/sidebar.tsx",
+  ]
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Personal sidebar
+
+## Why this exists
+
+Navigation should remember what matters to a person without quietly rewriting the
+workspace's structure. The sidebar is a map, not the territory; maps are allowed taste.
+
+## Example workflow
+
+A viewer pins a Page, reorders their personal references, expands an intentional
+reference, and opens a dynamic query section. Another viewer's order and the Page's
+parentage remain unchanged.
+
+## Product contract
+
+- Pinned entries are personal References; dynamic sections are access-scoped query results.
+- Personal ordering, expansion, and collapse do not reparent Pages, change Database membership, or grant shared edit authority.
+- Intentional references may expand; the sidebar is not a general-purpose object renderer.
+- Missing, deleted, inaccessible, stale, and unavailable entries are handled honestly and recoverably.
+
+## Boundaries and non-goals
+
+References and Queries own target and result meaning. This does not define Page hierarchy,
+general Tree View, or a hidden shared workspace organizer.
+
+## Acceptance stories
+
+### Reorder a personal pin
+
+Given two pinned References, when a viewer changes their order, then only that person's
+navigation preference changes and neither target Page's parentage nor membership changes.
+
+### Open an access-scoped section
+
+Given a dynamic section with inaccessible items, when a viewer expands it, then its rows,
+counts, and previews disclose only authorized results.
+
+## Current evidence
+
+Existing sidebar section tests and sidebar rendering show useful donor behavior. They do
+not prove the full Reference/query, access, recovery, and personal-state contract; this
+Capability remains `approved_shape`.
+
+## Proof plan
+
+1. Test pin, reorder, expand, query sections, reload, and stale-reference recovery.
+2. Verify access closure and that personal operations cannot mutate shared structure.
+3. Exercise keyboard, ARIA navigation, responsive behavior, agent context, and unavailable sources.
+
+## Open questions
+
+The first dynamic-section catalog and section-level personalization controls need design.

package/corpus/templates/content/docs/product/capabilities/content.notification.source.md

@@ -0,0 +1,71 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.notification.source"
+name: "Notifications"
+user_promise: "Canonical notifications exposed as queryable Content source and Views"
+primary_user_job: "Receive and organize meaningful notices without confusing them with Tasks or losing their read state."
+kind: "primitive"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.event.committed"]
+related_features:
+  [
+    "content.feature.collaborate-in-context",
+    "content.feature.run-projects-your-way",
+  ]
+roadmap_boundary: "feature"
+acceptance_summary: "Notifications have stable identity, actor and origin, read and archive state, access-scoped routing Rules, and queryable Source/View representation."
+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"
+---
+
+# Notifications
+
+## Why this exists
+
+A notification is a trace of something that happened to a person, not an assignment pretending to be urgent. Its read state belongs to that trace.
+
+## Example workflow
+
+A person receives a comment notification, opens its canonical target, marks the notice read, and archives it. A notification View updates without turning the item into My Tasks.
+
+## Product contract
+
+Notifications have stable identity, actor and origin, read and archive state, access-scoped routing Rules, and queryable Source/View representation. Their target remains canonical and My Tasks stays separate.
+
+## Boundaries and non-goals
+
+Committed Events own origins and routing owns delivery. This is not a task assignment engine, a duplicated inbox record, or a bypass around target access.
+
+## Acceptance stories
+
+### Read a comment notice without creating a task
+
+Given a notification target becomes inaccessible, when the list refreshes, then the notice follows its policy without leaking the target title or preview.
+
+### Remove a notice when target access is revoked
+
+Given a person marks one notice read, when they reopen another View, then the same canonical notification state appears without altering task membership.
+
+## Current evidence
+
+No complete notification identity, routing, state, and recovery proof is recorded. This Capability remains `approved_shape`.
+
+## Proof plan
+
+1. Test committed-event notices, target routes, read/archive state, and routing Rules.
+2. Verify target access changes, queryable Views, duplicate delivery, and task separation.
+3. Exercise revocation, archive retention, device conflicts, and accessible navigation.
+
+## Open questions
+
+The archive-retention and multi-device read-conflict policies need design.

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.