@agent-native/core 0.130.1 → 0.131.2

package/corpus/templates/content/docs/product/capabilities/content.portability.vault-export.md

@@ -0,0 +1,80 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.portability.vault-export"
+name: "Portable vault export"
+user_promise: "Take the authorized Content vault away in open files plus a lossless archive instead of remaining dependent on one service."
+primary_user_job: "Export my authorized work with enough meaning, assets, provenance, and verification to use or recover it elsewhere."
+kind: "workflow"
+state: "approved_shape"
+publicness: "public"
+availability: "configured"
+dependencies:
+  [
+    "content.portability.roundtrip",
+    "content.job.durable",
+    "content.access.visibility-closure",
+  ]
+related_features:
+  [
+    "content.feature.take-the-whole-vault-with-you",
+    "content.feature.bring-your-local-work",
+    "content.feature.keep-your-private-vault-private",
+  ]
+roadmap_boundary: "feature"
+acceptance_summary: "A resumable export materializes only the acting user's authorized closure into readable open files and a lossless Content archive, includes or reports assets and source handles, and supplies a verifiable conversion report."
+proof_requirements:
+  [
+    "Authorized-closure, dependency, asset, and inaccessible-reference tests",
+    "Open-package, lossless-archive, manifest, integrity, and conversion-report verification",
+    "Interrupted whole-vault export and resume workflow on a realistic corpus",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Portable vault export
+
+## Why this exists
+
+Portable work should leave with its meaning, not merely a pile of filenames.
+
+## Example workflow
+
+An administrator exports their authorized workspace. The package includes readable Markdown or MDX, tabular files, assets or stable handles, a manifest, and a Content archive; the report names inaccessible or unresolved dependencies.
+
+## Product contract
+
+- Export resolves the acting user's authorized closure at run time. It neither leaks inaccessible relations nor silently treats them as successfully included.
+- The open package uses readable files and a small manifest for stable identity and richer semantics; the lossless archive retains Content-specific history, annotations, discussion, rules, and provenance where authorized.
+- Assets are included when authorized and resolvable, otherwise represented by an honest report entry. Connected originals remain governed by Source policy.
+- Work is durable, resumable, verifiable, and separated from a disposable local cache.
+
+## Boundaries and non-goals
+
+PDF export is a reading artifact; round-trip owns format conversion; private vault owns encryption and keys. This does not promise every destination understands every Content feature.
+
+## Acceptance stories
+
+### Export only an authorized graph
+
+Given a Page references a record the exporter cannot access, when the vault exports, then the package does not include that record and the manifest reports the unresolved relationship without revealing hidden content.
+
+### Resume a large package
+
+Given export stops after writing a subset of assets, when the job resumes, then it verifies prior outputs and continues without duplicate objects or a false complete receipt.
+
+## Current evidence
+
+Donor evidence: `actions/export-document.ts`, `actions/export-content-source.ts`, and `shared/document-export.ts` cover bounded exports. No whole-vault authorized closure, lossless archive, or resume proof exists; this record remains `approved_shape`.
+
+## Proof plan
+
+1. Define package layout, manifest, archive semantics, and verification tool.
+2. Test closure, inaccessible dependencies, assets, source handles, and integrity.
+3. Run interrupted export/resume and validate the package outside Content.
+
+## Open questions
+
+- The first destination-compatible package and archive encryption handling remain open.

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.