@agent-native/core 0.130.2 → 0.131.3

package/corpus/templates/content/docs/product/capabilities/content.presentation.mode.md

@@ -0,0 +1,76 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.presentation.mode"
+name: "Presentation mode"
+user_promise: "Pages and ordered records can present through shared Slides primitives without creating slide-only content."
+primary_user_job: "Present existing Content in a focused sequence without copying it into a separate slide document."
+kind: "surface"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.layout.responsive", "content.renderer.typed"]
+related_features: ["content.feature.build-living-dashboards"]
+roadmap_boundary: "feature"
+acceptance_summary: "Presentation mode sequences canonical Pages or ordered records through shared slide primitives while preserving source identity, access, and ordinary editing."
+proof_requirements:
+  [
+    "Source selection, ordering, navigation, speaker-focus, and configuration persistence coverage",
+    "Canonical edit, access, sharing, export, reload, and recovery coverage",
+    "Real-interface keyboard, assistive-technology, responsive, and embedded presentation workflow",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Presentation mode
+
+## Why this exists
+
+Presenting should reveal a useful sequence, not ask people to maintain a shadow copy of
+their work in a slide-only silo.
+
+## Example workflow
+
+An editor presents an ordered set of Pages, advances with the keyboard, and corrects a
+fact through the ordinary Page editor. The next presentation uses that canonical change.
+
+## Product contract
+
+- Presentation mode is a View configuration over canonical Pages, Blocks, or ordered records.
+- Sequence, focus, and presenter controls are presentation state; source content retains identity and access.
+- Edits, sharing, export, and agent context use the same object and Action boundaries as ordinary Content.
+- Empty, unavailable, denied, and stale source states are visible rather than replaced by a blank deck.
+
+## Boundaries and non-goals
+
+Responsive layout supplies primitives. Presentation mode is not a slide-only document
+type, an animation authoring suite, or a bypass around source permissions.
+
+## Acceptance stories
+
+### Present canonical pages
+
+Given ordered authorized Pages, when a presenter enters presentation mode, then each
+slide reflects the canonical source and a viewer sees only Pages they may access.
+
+### Edit without forking
+
+Given a visible slide, when an editor changes its source Page, then the source history
+records one ordinary edit and the presentation refreshes without a duplicate slide copy.
+
+## Current evidence
+
+No complete Slides primitive or cross-surface proof is recorded. This Capability remains
+`approved_shape`.
+
+## Proof plan
+
+1. Test source selection, ordering, presenter navigation, persistence, and source mutation.
+2. Verify access, sharing, export, agent context, stale state, and recovery.
+3. Exercise keyboard, screen-reader, responsive, embedded, and reload workflows.
+
+## Open questions
+
+Speaker notes and transition scope need separate design without changing source truth.

package/corpus/templates/content/docs/product/capabilities/content.preset.catalog.md

@@ -0,0 +1,71 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.preset.catalog"
+name: "Presets"
+user_promise: "Understand that older preassembled configurations now live as inspectable Templates rather than a competing product type."
+primary_user_job: "Follow historical Preset lineage to its Template successor."
+kind: "primitive"
+state: "superseded"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.template.graph"]
+related_features: []
+roadmap_boundary: "superseded"
+acceptance_summary: "Presets are superseded by Multi-object Templates: governed preassembled ordinary primitives continue through the Template graph and governance contracts with no alternate hidden engine."
+proof_requirements:
+  [
+    "All new reusable-system work belongs to content.template.graph and its governance/update capabilities.",
+    "A former preset must remain inspectable as ordinary Pages, Databases, Views, Properties, Rules, expressions, and bodies.",
+    "This record preserves lineage only and does not create a second catalog or migration requirement.",
+  ]
+evidence: []
+superseded_by: "content.template.graph"
+last_reviewed: "2026-07-29"
+---
+
+# Presets
+
+## Why this exists
+
+Historical Preset terminology can mislead people into looking for a separate engine that no longer exists. The lineage needs to remain legible while all real reuse work proceeds through Templates.
+
+## Example workflow
+
+A team follows a legacy Preset link to its Template graph lineage and adopts a Template version rather than creating a Preset instance.
+
+## Product contract
+
+- All new reusable-system work belongs to content.template.graph and its governance/update capabilities.
+- A former preset must remain inspectable as ordinary Pages, Databases, Views, Properties, Rules, expressions, and bodies.
+- This record preserves lineage only and does not create a second catalog or migration requirement.
+
+## Boundaries and non-goals
+
+- `content.template.graph`, Template governance, and Template updates own every successor workflow; this record preserves only the historical mapping.
+- Presets do not retain a separate catalog, instance type, mutation surface, or migration engine.
+
+## Acceptance stories
+
+### Preserve lineage only
+
+Given historical Preset provenance, when a person opens the legacy entry, then the record points to Template successor and exposes no Preset mutation action.
+
+### Use Template updates
+
+Given an old configuration changes, when its owner reviews it, then Template pinning, diff, selective apply, and detach govern it.
+
+## Current evidence
+
+`docs/product/architecture.md` and `content.template.graph.md` define the successor; no separate Presets implementation is intended.
+
+## Proof plan
+
+1. Resolve historic links to Template records.
+2. Confirm no separate Preset discovery/mutation engine.
+3. Exercise inspection/adoption/update through Template contracts.
+4. Preserve legacy provenance in export/history.
+
+## Open questions
+
+No product question remains.

package/corpus/templates/content/docs/product/capabilities/content.property.actor.md

@@ -0,0 +1,75 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.property.actor"
+name: "Actor properties"
+user_promise: "Know who actually created or last changed a record, whether that actor was a person, agent, automation, or integration."
+primary_user_job: "Understand actual creators and editors across actor kinds."
+kind: "primitive"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.event.committed"]
+related_features:
+  [
+    "content.feature.durable-foundations",
+    "content.feature.data-that-keeps-itself-right",
+  ]
+roadmap_boundary: "feature"
+acceptance_summary: "Created by and Last edited by are typed actor properties derived from committed mutations and retain actual actor and origin rather than a misleading shared account."
+proof_requirements:
+  [
+    "Actor values identify the actual human, agent, automation, or integration that committed the change.",
+    "Creation sets Created by once; later committed changes update Last edited by without overwriting provenance.",
+    "Denied, imported, or unavailable actor identity is represented honestly and does not collapse into a false personal attribution.",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Actor properties
+
+## Why this exists
+
+Collaboration loses accountability when automation and agents are flattened into a generic service identity. People need to distinguish who first created a record from who most recently changed it and how that change arrived.
+
+## Example workflow
+
+A coordinator creates a request, automation enriches it, and an agent edits status; Created by stays coordinator while Last edited by names the agent.
+
+## Product contract
+
+- Actor values identify the actual human, agent, automation, or integration that committed the change.
+- Creation sets Created by once; later committed changes update Last edited by without overwriting provenance.
+- Denied, imported, or unavailable actor identity is represented honestly and does not collapse into a false personal attribution.
+
+## Boundaries and non-goals
+
+- Committed events own mutation attribution and origin; Actor Properties project that record into stable created/last-edited fields.
+- Actor fields are not a permissions mechanism and do not fabricate a current-person identity when provenance is unresolved.
+
+## Acceptance stories
+
+### Keep creation provenance
+
+Given imported work is later edited, when a person commits the change, then Created by remains imported origin.
+
+### Admit unknown identity
+
+Given legacy resolution fails, when the actor Property renders, then the actor field says unresolved rather than current viewer.
+
+## Current evidence
+
+`actions/create-document.ts`, `update-document.ts`, and `edit-document.ts` are donors; `server/db/schema.ts` timestamps do not prove actor fields.
+
+## Proof plan
+
+1. Exercise person/agent/automation/integration/import/restore.
+2. Render access-aware actor and unresolved states.
+3. Export/import without identity leakage.
+4. Compare receipts and displayed actor.
+
+## Open questions
+
+Actor card versus text renderer remains open.

package/corpus/templates/content/docs/product/capabilities/content.property.catalog.md

@@ -0,0 +1,76 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.property.catalog"
+name: "Custom Properties"
+user_promise: "Reuse an approved field definition deliberately without making same-named local columns secretly equal."
+primary_user_job: "Reuse a governed field and safely update or detach it."
+kind: "primitive"
+state: "exploring"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.property.typed", "content.template.governance"]
+related_features:
+  [
+    "content.feature.connect-your-sources",
+    "content.feature.share-how-your-organization-works",
+    "content.feature.evolve-systems-safely",
+  ]
+roadmap_boundary: "feature"
+acceptance_summary: "Custom Properties are governed, scoped reusable typed definitions with stable identity, description, provenance, query semantics, versioned updates, impact preview, safe migration, and detachable local copies."
+proof_requirements:
+  [
+    "The add-column picker distinguishes built-in local types, source-backed fields, and personal, workspace, or organization Custom Properties.",
+    "A definition's stable identity—not its name—controls query meaning, provenance, and compatible updates.",
+    "A consumer may detach to a local field; updates are reviewed and impact-previewed, never silently applied.",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Custom Properties
+
+## Why this exists
+
+Same-named columns are not shared meaning. Organizations need a way to reuse a field deliberately, understand where it came from, and evolve it without silently rewriting a local database.
+
+## Example workflow
+
+Marta publishes Customer tier, a database adopts it, previews an enum update, and another database detaches locally while keeping values.
+
+## Product contract
+
+- The add-column picker distinguishes built-in local types, source-backed fields, and personal, workspace, or organization Custom Properties.
+- A definition's stable identity—not its name—controls query meaning, provenance, and compatible updates.
+- A consumer may detach to a local field; updates are reviewed and impact-previewed, never silently applied.
+
+## Boundaries and non-goals
+
+- `content.property.typed` owns type semantics and Template governance owns catalog policy; Custom Properties own reusable definition/adoption identity.
+- The catalog does not equate columns by name, make local columns secretly global, or auto-migrate incompatible values.
+
+## Acceptance stories
+
+### Labels are not identity
+
+Given local and organization Status fields, when an author opens Add column, then Add column distinguishes their IDs and origins.
+
+### Stage risky migration
+
+Given a breaking type/option update, when its owner proposes publication, then Content previews impact and blocks or stages unsafe conversion.
+
+## Current evidence
+
+`server/plugins/db.ts`, `actions/configure-document-property.ts`, `actions/bind-content-database-source-field.ts`, and `DocumentProperties.tsx` are donors; catalog/adoption/detach/migration do not exist.
+
+## Proof plan
+
+1. Build scoped Add column discovery with IDs/provenance.
+2. Adopt across databases and test semantics/access.
+3. Publish compatible/breaking versions with impact/migration/receipts.
+4. Detach without losing values.
+
+## Open questions
+
+Scope names need root judgment.

package/corpus/templates/content/docs/product/capabilities/content.property.constraints.md

@@ -0,0 +1,75 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.property.constraints"
+name: "Property validation and defaults"
+user_promise: "Configure requiredness, defaults, validation, formatting, and edit policy once and trust every write path to enforce them."
+primary_user_job: "Set constraints and defaults every mutation path enforces."
+kind: "primitive"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.property.typed", "content.expression.language"]
+related_features:
+  [
+    "content.feature.data-that-keeps-itself-right",
+    "content.feature.collect-structured-input",
+  ]
+roadmap_boundary: "feature"
+acceptance_summary: "Property configuration validates every mutation atomically; formulas remain live, while defaults evaluate once during a successful creation transaction and become stored values."
+proof_requirements:
+  [
+    "Constraints, format, requiredness, and edit policy are typed configuration interpreted by the shared mutation boundary.",
+    "Defaults evaluate exactly once only after the creation transaction has enough context to succeed; they are not live formulas.",
+    "Validation failure returns typed field diagnostics and commits no partial mutation through UI, agent, import, source sync, or API.",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Property validation and defaults
+
+## Why this exists
+
+A rule that only the form enforces is not a data rule. Authors need defaults and validation to behave predictably whether a record comes from a person, agent, import, or source synchronization.
+
+## Example workflow
+
+Elena creates a Form row with required Priority and a Due date default; the default stores once while a formula remains live.
+
+## Product contract
+
+- Constraints, format, requiredness, and edit policy are typed configuration interpreted by the shared mutation boundary.
+- Defaults evaluate exactly once only after the creation transaction has enough context to succeed; they are not live formulas.
+- Validation failure returns typed field diagnostics and commits no partial mutation through UI, agent, import, source sync, or API.
+
+## Boundaries and non-goals
+
+- Typed Properties own field type and Expressions own live computation; this record owns transaction-time defaults, constraints, format, and edit policy.
+- Defaults are not formulas, and client-side form checks are not a substitute for the shared mutation boundary.
+
+## Acceptance stories
+
+### Roll back atomically
+
+Given an agent changes two fields and one is invalid, when the mutation commits, then neither commits and the failing field is identified.
+
+### Do not turn defaults live
+
+Given a current-actor default, when the actor later changes, then later actor changes do not rewrite the stored value.
+
+## Current evidence
+
+`actions/configure-document-property.ts`, `set-document-property.ts`, and lifecycle tests are donors; cross-origin rule semantics are unproved.
+
+## Proof plan
+
+1. Configure/test via forms, UI, actions, import, and sync.
+2. Verify defaults evaluate once and formulas remain live.
+3. Test invalid multi-field rollback and typed errors.
+4. Exercise denied dependencies and retry.
+
+## Open questions
+
+Default dependency ordering needs shaping.

package/corpus/templates/content/docs/product/capabilities/content.property.guarded-change.md

@@ -0,0 +1,76 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.property.guarded-change"
+name: "Guarded property changes"
+user_promise: "Require an explained confirmation or policy check before a sensitive field transition while keeping one general validation engine."
+primary_user_job: "Satisfy a clear shared safeguard before sensitive changes."
+kind: "primitive"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.property.constraints", "content.event.committed"]
+related_features:
+  [
+    "content.feature.trust-your-connected-sources",
+    "content.feature.data-that-keeps-itself-right",
+    "content.feature.publish-with-confidence",
+  ]
+roadmap_boundary: "feature"
+acceptance_summary: "Any Property can declare validation and safeguards for sensitive transitions; the shared mutation boundary evaluates them, explains required confirmation or policy failure, and records committed changes normally."
+proof_requirements:
+  [
+    "Status is a useful UI for a guarded change but is not the exclusive safeguard engine.",
+    "UI, agent, automation, source sync, import, and API calls use the same validation and policy boundary.",
+    "A blocked transition produces an actionable reason and no partial write; accepted confirmation or policy result is attributable in history.",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Guarded property changes
+
+## Why this exists
+
+Some values carry consequences that deserve more than an accidental click, yet a special status dialog cannot protect the same change made by automation. People need one explainable safeguard at the mutation boundary.
+
+## Example workflow
+
+A release manager moves Draft to Published with required confirmation and sees the same policy apply to agent and source-sync changes.
+
+## Product contract
+
+- Status is a useful UI for a guarded change but is not the exclusive safeguard engine.
+- UI, agent, automation, source sync, import, and API calls use the same validation and policy boundary.
+- A blocked transition produces an actionable reason and no partial write; accepted confirmation or policy result is attributable in history.
+
+## Boundaries and non-goals
+
+- Constraints own ordinary validity; committed events own attribution/history; guarded change owns the added safeguard decision and explanation.
+- Status is only one useful surface: safeguards are not status-only workflows, a new permission system, or a client-only confirmation.
+
+## Acceptance stories
+
+### Guard every origin
+
+Given source sync attempts a sensitive transition, when it reaches the mutation boundary, then it receives the same decision as UI.
+
+### Explain refusal
+
+Given confirmation is absent, when an editor requests the transition, then no mutation occurs and the rule/next action are clear.
+
+## Current evidence
+
+`actions/change-content-database-source-role.ts` and `set-document-property.ts` are donors; general safeguard evaluation is absent.
+
+## Proof plan
+
+1. Configure safeguards on status, date, relation, and ordinary fields.
+2. Compare UI/action/agent/automation/import/sync decisions.
+3. Test expiry, retry, concurrency, no partial writes.
+4. Verify explanations and actor history.
+
+## Open questions
+
+Vocabulary and separate-reviewer policy remain open.

package/corpus/templates/content/docs/product/capabilities/content.property.location.md

@@ -0,0 +1,71 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.property.location"
+name: "Typed locations"
+user_promise: "Store a place or coordinates as a meaningful location that maps, queries, sources, and export can understand."
+primary_user_job: "Capture a place at known precision for portable use."
+kind: "primitive"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.property.typed"]
+related_features: []
+roadmap_boundary: "supporting"
+acceptance_summary: "Location Properties preserve a typed structured place and coordinates with clear precision, display, query, source mapping, and portable export behavior."
+proof_requirements:
+  [
+    "A location is typed structured data, not a display string or map pin owned by one renderer.",
+    "Authors can keep a human place, coordinates, and known precision without fabricating missing geocoding data.",
+    "Maps and sources are projections/adapters; access, queries, and export use the canonical value and disclose unsupported fields honestly.",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Typed locations
+
+## Why this exists
+
+A place has more meaning than an address string, but false precision is actively misleading. Authors need to preserve what they know about a location while letting maps and exports consume it without inventing details.
+
+## Example workflow
+
+Nia records a field visit with label, coordinates, and approximate precision; map and nearby query use it while export retains known data.
+
+## Product contract
+
+- A location is typed structured data, not a display string or map pin owned by one renderer.
+- Authors can keep a human place, coordinates, and known precision without fabricating missing geocoding data.
+- Maps and sources are projections/adapters; access, queries, and export use the canonical value and disclose unsupported fields honestly.
+
+## Boundaries and non-goals
+
+- Typed Properties own the value contract; map Views and provider adapters consume or map locations without becoming the source of truth.
+- Locations do not imply geocoding, tracking, hidden precision, or an automatic map-provider dependency.
+
+## Acceptance stories
+
+### Do not invent precision
+
+Given a source only provides a city, when Content imports it, then Content keeps city/precision without fabricating coordinates.
+
+### Maps are projections
+
+Given a renderer fails, when a person opens the Location Property, then the location remains queryable and exportable.
+
+## Current evidence
+
+`app/components/editor/DocumentProperties.tsx` maps location to `place`; `shared/properties.ts` includes `place`, but no structured location schema exists.
+
+## Proof plan
+
+1. Author labels/coordinates/precision and serialize them.
+2. Query/render in map and non-map surfaces.
+3. Import partial provider values without invented geocoding.
+4. Export/import with access-aware coordinates.
+
+## Open questions
+
+Points versus polygons/routes is open.

package/corpus/templates/content/docs/product/capabilities/content.property.typed.md

@@ -0,0 +1,71 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.property.typed"
+name: "Typed Properties"
+user_promise: "Define stored and computed fields whose values and descriptions stay meaningful in every surface."
+primary_user_job: "Define fields whose types survive every Content operation."
+kind: "primitive"
+state: "in_progress"
+publicness: "public"
+availability: "universal"
+dependencies: []
+related_features: ["content.feature.data-that-keeps-itself-right"]
+roadmap_boundary: "feature"
+acceptance_summary: "Properties declare stable stored or computed types, descriptions, configuration, and renderer contracts so values can be authored, queried, validated, rendered, and exported without ambiguous coercion."
+proof_requirements:
+  [
+    "Stored values and computed results both declare exact output types; presentation is a renderer choice, not a hidden data conversion.",
+    "Descriptions and typed semantics are available to people, agents, queries, validation, and export.",
+    "Unknown, invalid, absent, and unreadable values remain distinct.",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Typed Properties
+
+## Why this exists
+
+A field label alone cannot tell a database, export, or agent what a value means. Without durable types, dates become text and missing access becomes an innocent blank, quietly corrupting later work.
+
+## Example workflow
+
+Dara adds a place field, describes it, and sees the same typed value in property panel, database view, and export.
+
+## Product contract
+
+- Stored values and computed results both declare exact output types; presentation is a renderer choice, not a hidden data conversion.
+- Descriptions and typed semantics are available to people, agents, queries, validation, and export.
+- Unknown, invalid, absent, and unreadable values remain distinct.
+
+## Boundaries and non-goals
+
+- `content.property.constraints` owns validation/default behavior and `content.expression.language` owns computed semantics; Typed Properties own declared value/output types.
+- A renderer may change presentation but cannot change stored meaning or coerce denied/invalid/absent states into a normal value.
+
+## Acceptance stories
+
+### Keep computed type
+
+Given a date formula, when sorted/rendered/exported, then each consumer gets a declared date.
+
+### Do not coerce absence
+
+Given unreadable relation and blank text, then renderers keep them distinct.
+
+## Current evidence
+
+`shared/properties.ts`, `actions/configure-document-property.ts`, and `app/components/editor/DocumentProperties.tsx` are donors; formula output types are not durable general declarations.
+
+## Proof plan
+
+1. Create/query/render/export stored and computed types.
+2. Propagate descriptions to UI/actions/agents/serialization.
+3. Test absent, invalid, unreadable, unsupported values.
+4. Compare UI/action validation.
+
+## Open questions
+
+Computed output taxonomy needs root judgment.

package/corpus/templates/content/docs/product/capabilities/content.publish.public.md

@@ -0,0 +1,75 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.publish.public"
+name: "Public publication"
+user_promise: "Publish one chosen Page revision at a stable public destination while private work continues safely."
+primary_user_job: "Make an approved version public without accidentally publishing draft edits, comments, or private dependencies."
+kind: "workflow"
+state: "approved_shape"
+publicness: "public"
+availability: "configured"
+dependencies:
+  [
+    "content.access.visibility-closure",
+    "content.version.branching",
+    "content.renderer.typed",
+  ]
+related_features: ["content.feature.publish-with-confidence"]
+roadmap_boundary: "feature"
+acceptance_summary: "A Page-first publication object binds a stable destination to one Page, selected Version, and exact revision, previews the actual audience closure, records lifecycle events, and changes only when an authorized publisher explicitly updates or withdraws it."
+proof_requirements:
+  [
+    "Publication identity, revision binding, lifecycle, URL, and rollback tests",
+    "Audience-closure and private-collaboration leakage tests",
+    "Publisher preview, publish, private follow-on edit, update, and unpublish interface workflow",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Public publication
+
+## Why this exists
+
+Public truth deserves a deliberate pin, not whatever happened to be in the editor when the wind changed.
+
+## Example workflow
+
+An editor previews the approved article revision, publishes it at a stable URL, continues private revision work, then explicitly replaces the public revision after another preview.
+
+## Product contract
+
+- Publication is Page-first and binds Page identity, selected Version, exact revision, destination, audience closure, and lifecycle history.
+- The stable URL serves the last explicitly published revision; private edits, comments, unpublished Versions, and inaccessible assets do not follow it automatically.
+- Preview evaluates the real audience closure and renderer fallback before publish. Publish, update, and unpublish are explicit guarded actions with actor/origin receipts.
+- Provider publishing remains a separate Source lifecycle action, not a consequence of public Content publication.
+
+## Boundaries and non-goals
+
+Public reading owns rendering; sharing owns access; provider adapters own external publishing. This does not turn every shared Page into a public publication.
+
+## Acceptance stories
+
+### Hold a public revision steady
+
+Given a published Page and a private draft edit, when the draft changes, then the public URL keeps serving the prior bound revision until an authorized publisher updates it.
+
+### Prevent private closure leaks
+
+Given the selected revision references a private comment and inaccessible asset, when preview runs, then it identifies their public treatment and publishing does not expose either.
+
+## Current evidence
+
+Donor evidence: `server/lib/public-documents.ts`, `server/lib/public-documents.spec.ts`, and `app/routes/p.$id.tsx` implement public Page substrate. They do not prove Page/Version/revision publication identity or lifecycle isolation; this record remains `approved_shape`.
+
+## Proof plan
+
+1. Model publication bindings and guarded lifecycle Actions.
+2. Test revision stability, closure, rollback, update, withdrawal, and provider separation.
+3. Verify preview and full public lifecycle in the browser.
+
+## Open questions
+
+- Publication scheduling and multiple destinations are future decisions.