@agent-native/core 0.130.1 → 0.131.2

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

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

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

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

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

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

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

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

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

@@ -0,0 +1,78 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.portability.pdf-export"
+name: "PDF export"
+user_promise: "Create a readable PDF of an authorized Content representation without confusing it with the editable or lossless export."
+primary_user_job: "Hand someone a stable, readable document that faithfully represents what I am authorized to share."
+kind: "workflow"
+state: "in_progress"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.renderer.typed", "content.access.visibility-closure"]
+related_features:
+  [
+    "content.feature.publish-with-confidence",
+    "content.feature.take-the-whole-vault-with-you",
+  ]
+roadmap_boundary: "feature"
+acceptance_summary: "PDF export resolves the acting user's authorized representation through shared rendering, gives supported blocks a faithful layout or explicit fallback, and returns a durable file with clear scope and failure reporting."
+proof_requirements:
+  [
+    "Renderer fidelity tests for supported blocks, media, math, code, and explicit fallbacks",
+    "Access-closure, asset, pagination, metadata, and error reporting tests",
+    "Interface export workflow validated against the selected representation and downloaded PDF",
+  ]
+evidence:
+  [
+    "../../../shared/document-export.ts",
+    "../../../shared/document-export.spec.ts",
+  ]
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# PDF export
+
+## Why this exists
+
+PDF is a dependable reading artifact, not a promise that a flat page can carry every living behavior.
+
+## Example workflow
+
+An editor exports the approved article revision. Content renders the same authorized blocks, reports an unavailable protected asset, and produces a PDF whose scope identifies the selected representation.
+
+## Product contract
+
+- Export materializes the acting user's authorized closure at export time; it never borrows a collaborator's access.
+- It uses shared semantic rendering where possible and provides deliberate, readable fallbacks for unsupported interactive behavior.
+- The artifact records enough representation and generation context to explain what it contains. Asset failures are reported, not silently omitted.
+- A PDF is read-oriented output, separate from editable source and lossless archive formats.
+
+## Boundaries and non-goals
+
+Publication owns stable public URLs; vault export owns complete package closure. PDF export does not promise round-trip editing or live embeds.
+
+## Acceptance stories
+
+### Export only the viewer's closure
+
+Given a Page references an inaccessible private asset, when a permitted editor exports it, then the PDF does not expose the asset and reports the unavailable representation.
+
+### Render a deliberate fallback
+
+Given a supported Page contains an interactive Block without a print equivalent, when it exports, then the PDF includes a labeled safe fallback rather than pretending the interaction survived.
+
+## Current evidence
+
+Implementation evidence: `shared/document-export.ts` and `shared/document-export.spec.ts` cover current document export machinery. Donor evidence does not yet prove all block fidelity, access closure, or interface-level PDF behavior, so this record remains `in_progress`.
+
+## Proof plan
+
+1. Expand fixture coverage across supported blocks and intentional fallbacks.
+2. Test access changes, media resolution, metadata, pagination, and failures.
+3. Compare a real export against the selected authorized representation.
+
+## Open questions
+
+- Print styling and accessibility metadata policy need final acceptance criteria.

package/corpus/templates/content/docs/product/capabilities/content.portability.roundtrip.md

@@ -0,0 +1,154 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.portability.roundtrip"
+name: "Faithful round-tripping"
+user_promise: "Content preserves provider-owned meaning it cannot safely render or edit, so a supported change never silently destroys the rest of the work."
+primary_user_job: "Edit what Content understands while keeping connected and portable work recoverable and intelligible outside one application."
+kind: "primitive"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.portability.source-representation"]
+related_features:
+  [
+    "content.feature.trust-your-connected-sources",
+    "content.feature.cite-what-you-found",
+    "content.feature.take-the-whole-vault-with-you",
+    "content.feature.move-without-starting-over",
+  ]
+roadmap_boundary: "feature"
+acceptance_summary: "Authorized imports, edits, exports, and provider write-back preserve stable identity, known semantics, provenance, and unknown provider structures through explicit raw or typed fallback representations, while reporting unsupported or unresolved material instead of silently flattening it."
+proof_requirements:
+  [
+    "Golden import-edit-export and provider write-back fixtures covering known, unknown, mixed, and malformed representations",
+    "Stable identity, provenance, block/comment/reference/custom structure, and source mapping preservation or explicit unresolved reporting",
+    "Conflict, access, recovery, and lossless archive verification across at least two independently certified adapter formats",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Faithful round-tripping
+
+## Why this exists
+
+People bring work with structure Content may not yet understand: provider
+components, bindings, embeds, custom blocks, references, comments, and other
+format-specific detail. A friendly editable view is not permission to discard
+what it cannot represent. Lossy simplicity has excellent manners right up to
+the moment it loses a component.
+
+## Example workflow
+
+An editor opens a provider article containing ordinary text and an unsupported
+component. Content renders and edits the text through its native grammar while
+retaining the unsupported component as a preserved source-backed representation.
+After the editor changes the text and completes the Source's allowed write-back
+flow, the provider receives the changed text and the unknown component remains
+unchanged. A later export includes the information needed to preserve both the
+known Content semantics and unresolved provider material.
+
+## Product contract
+
+### Preserve what is known and what is not
+
+- A source representation maps known semantics into typed Content structures
+  only when that mapping is safe. It retains stable source identity,
+  provenance, ordering, and enough fidelity information to reconstruct the
+  provider-facing representation.
+- Unknown, unsupported, or not-yet-safe provider material survives as an
+  explicit raw or typed fallback with source identity and an inspectable status.
+  It is not flattened into ordinary text, silently dropped, or presented as a
+  fully editable native Block.
+- Known native-like semantics may render through ordinary Content Blocks while
+  retaining their source binding. Provider-specific reusable or custom
+  components remain source-backed until explicitly forked with provenance.
+- Expressions, references, custom blocks, comments, block identities, and
+  other typed Content structures need exact encodings or an explicit unresolved
+  representation; a best-effort export may not claim lossless completion.
+
+### Round trips retain authority and recoverability
+
+- Import, refresh, edit, export, and provider write-back retain the source
+  mapping, baseline, ownership, and policy needed to route later work safely.
+- A compatible Content edit changes only the mapped authorized portion. It
+  preserves unknown siblings and provider-owned fields outside that mapping.
+- Access applies before import preview, export, provider write-back, raw
+  fallback inspection, and recovery. Export includes only material the acting
+  user may access and reports unavailable or excluded dependencies.
+- A failed conversion, stale base, malformed input, or missing payload produces
+  an explicit failure or unresolved state. It never returns an empty or clean
+  representation that callers can mistake for a completed round trip.
+
+### Provider and portable forms remain distinct
+
+- The portable source representation owns provider-neutral interchange;
+  adapters and codecs own provider-specific mapping details. A provider codec
+  is not the universal Content authoring grammar.
+- A lossless archive may carry structured sidecars and stable asset handles in
+  addition to humane Markdown/MDX. Raw payloads and assets use appropriate file
+  or blob storage, not shared SQL fields.
+- Detaching or converting source-backed content into Content-managed work is an
+  explicit fork with provenance and policy consequences, never an accidental
+  outcome of opening or editing it.
+
+## Boundaries and non-goals
+
+- Sync policy decides whether and when outbound work may cross a Source
+  boundary; adapters certify a provider's codec and operations. This record
+  defines the fidelity obligation shared by those paths.
+- Faithful preservation does not promise a native editor for every provider
+  feature, universal raw-source editing, or byte-identical output where the
+  provider itself normalizes content.
+- Publication and other provider lifecycle changes are separate guarded actions.
+
+## Acceptance stories
+
+### Preserve an unknown sibling during a supported edit
+
+Given a provider representation with one editable text region and one unknown
+component, when an authorized editor changes the text and completes permitted
+write-back, then the provider receives the text change while the unknown
+component, ordering, and source identity remain intact.
+
+### Report an incomplete conversion honestly
+
+Given an import whose typed extension cannot be encoded by the target format,
+when a person exports it, then Content either emits the declared lossless
+sidecar/fallback or reports that representation as unresolved; it does not
+produce a clean-looking export that silently omits the extension.
+
+### Recover identity through a mixed-format round trip
+
+Given a Source with mapped Blocks, references, comments, and preserved raw
+provider material, when an authorized lossless archive is exported and restored,
+then stable identities, provenance, supported semantics, fallback material, and
+source mappings remain coherent or each unresolved dependency is reported.
+
+## Current evidence
+
+Content exports editable text formats and existing source machinery includes
+raw sidecars, hashes, and guarded provider paths. Those prove useful pieces,
+not a generic lossless contract across representations, access, recovery, and
+independently certified adapters. This Capability remains `approved_shape`.
+
+## Proof plan
+
+1. Build golden fixtures for known, unknown, mixed, reordered, malformed, and
+   partially unavailable representations across at least two adapter formats.
+2. Run import, refresh, native edit, review/write-back, export, restore, and
+   re-import; compare stable identity, provenance, mapped semantics, fallback
+   payloads, source mappings, and explicit unresolved reports.
+3. Exercise stale bases, provider normalization, interrupted conversion,
+   conflicts, retries, access denial, redaction, and missing assets or handles.
+4. Verify fallback status and recovery paths in the real interface and shared
+   Actions, including accessible inspection of unsupported material.
+
+## Open questions
+
+- The canonical sidecar envelope and the exact portable encoding for every
+  typed Content structure remain implementation work.
+- Fidelity equivalence must define when provider normalization is acceptable
+  without weakening the obligation to preserve unknown meaning.

package/corpus/templates/content/docs/product/capabilities/content.portability.source-representation.md

@@ -0,0 +1,70 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.portability.source-representation"
+name: "Portable Source representation"
+user_promise: "Connected and local material has a portable Content representation without pretending Content owns every original."
+primary_user_job: "Move between local, hosted, and provider-backed work while retaining identity, provenance, fidelity limits, and a readable recovery path."
+kind: "primitive"
+state: "approved_shape"
+publicness: "public"
+availability: "configured"
+dependencies: ["content.source.adapters"]
+related_features: ["content.feature.bring-your-local-work"]
+roadmap_boundary: "feature"
+acceptance_summary: "A portable representation separates stable Content identity from source bindings, preserves source-owned unknown data and baselines, records fidelity and access limits, and can be materialized or repaired without default dual truth."
+proof_requirements:
+  [
+    "Representation schema and round-trip fixtures for native, provider, and local sources",
+    "Identity, provenance, unknown-data, baseline, conflict, access, and repair tests",
+    "Cross-client materialization and recovery workflow without raw local handles in shared state",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Portable Source representation
+
+## Why this exists
+
+Portability needs a map of what Content knows and what remains somewhere else, not an accidental second original.
+
+## Example workflow
+
+A local document is materialized for browser reading. Its Page identity, source binding, baseline, and unavailable local bytes remain distinguishable; an authorized bridge can later refresh or repair it.
+
+## Product contract
+
+- Stable Content identity is distinct from source connection, provider item identity, representation, baseline, and field ownership.
+- Source-owned unknown structures survive as faithful opaque data or explicit unsupported state; Content does not flatten them into editable guesses.
+- Materializations retain provenance, freshness, fidelity, and access boundaries. Local paths and handles do not enter shared state.
+- A source policy declares which direction may write and how conflict/recovery works; default SQL and filesystem dual truth is prohibited.
+
+## Boundaries and non-goals
+
+Adapters own provider behavior; round-trip owns conversion fidelity; local bridge owns device authority. This is not a universal file format or a claim of byte-perfect representation for every provider.
+
+## Acceptance stories
+
+### Preserve an unknown provider structure
+
+Given a source representation contains an unsupported provider component, when a mapped Content field changes, then the unknown component remains tied to its source identity and is not rewritten as ordinary Content data.
+
+### Keep local custody local
+
+Given a local file is materialized for another client, when that client inspects its Source metadata, then it can identify freshness and availability without receiving a raw path or filesystem handle.
+
+## Current evidence
+
+Donor evidence: `shared/content-source.ts`, `actions/_document-source.ts`, and source adapter actions model present source metadata. No complete portable representation, cross-client recovery, and fidelity proof exists; this record remains `approved_shape`.
+
+## Proof plan
+
+1. Specify representation, baseline, opaque payload, fidelity, and access fields.
+2. Test source identities, unknown preservation, conflicts, repair, and redaction.
+3. Verify local and provider materialization across clients with no dual truth claim.
+
+## Open questions
+
+- The exact portable archive encoding for opaque provider payloads remains open.