@agent-native/core 0.130.1 → 0.131.2

package/corpus/templates/content/docs/product/capabilities/content.rule.deterministic.md

@@ -0,0 +1,79 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.rule.deterministic"
+name: "Rules"
+user_promise: "Event plus typed condition plus action"
+primary_user_job: "Define repeatable operational behavior that is explicit, authorized, idempotent, and explainable."
+kind: "workflow"
+state: "in_progress"
+publicness: "public"
+availability: "universal"
+dependencies:
+  [
+    "content.event.committed",
+    "content.expression.language",
+    "content.agent.action-parity",
+  ]
+related_features:
+  [
+    "content.feature.when-this-happens-that-follows",
+    "content.feature.collect-structured-input",
+    "content.feature.capture-into-action",
+  ]
+roadmap_boundary: "feature"
+acceptance_summary: "Rules are versioned subscriptions from committed Events through one expression language to typed Actions."
+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"
+---
+
+# Rules
+
+## Why this exists
+
+A Rule turns a recurring intention into a visible promise: one committed event, one typed condition, and one authorized action.
+
+A Rule makes an operational promise visible: one committed event, one typed condition, one authorized action.
+
+## Example workflow
+
+A Database update emits a committed Event, a versioned Rule evaluates a typed condition, and an Action assigns a follow-up property once. The receipt identifies the event, Rule version, authority, and outcome.
+
+## Product contract
+
+Rules are versioned subscriptions from committed Events through one expression language to typed Actions. They have owner authority, idempotency, causal receipts, disablement, retries, and visible failures.
+
+## Boundaries and non-goals
+
+Events own committed triggers, expressions own conditions, and Actions own mutations. This is not client-side scripting, hidden retries that look successful, or unrestricted recursive automation.
+
+## Acceptance stories
+
+### Record a duplicate Event delivery
+
+Given the same Event is delivered twice, when a Rule would mutate a record, then idempotency commits at most one canonical effect and records the duplicate receipt.
+
+### Surface an unevaluable condition
+
+Given a Rule condition cannot be evaluated, when its source is unavailable, then Content records an explicit failure or retry state rather than an empty successful run.
+
+## Current evidence
+
+Rule substrate is in progress, but complete subscription, idempotency, authority, receipt, and recovery proof is incomplete. This Capability remains `in_progress`.
+
+## Proof plan
+
+1. Test versioned subscriptions from committed Events through typed expressions to Actions.
+2. Simulate duplicates, false and unevaluable conditions, retries, recursion, and disablement.
+3. Inspect causal history, owner controls, failure states, reload recovery, and no-success-on-failure.
+
+## Open questions
+
+The initial retry and dead-letter policy need design.

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

@@ -0,0 +1,81 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.schedule.constraints"
+name: "Schedule constraints"
+user_promise: "Planning surfaces detect dependency and date violations, explain them, and apply only explicit policy or accepted repairs."
+primary_user_job: "Understand whether a plan conflicts with its dates and dependencies, then choose a visible repair rather than accepting a hidden schedule rewrite."
+kind: "primitive"
+state: "exploring"
+publicness: "public"
+availability: "universal"
+dependencies:
+  [
+    "content.relationship.edge",
+    "content.time.types",
+    "content.expression.language",
+  ]
+related_features: ["content.feature.plan-work-across-time"]
+roadmap_boundary: "feature"
+acceptance_summary: "Planning Views evaluate typed date and dependency constraints, explain violations and uncertainty, and apply only explicit policy or accepted canonical repairs."
+proof_requirements:
+  [
+    "Typed date/range and Relationship constraint evaluation, cycle, missing-data, and uncertainty coverage",
+    "Access-safe violation disclosure, repair proposal, policy, Action, history, and recovery coverage",
+    "Real-interface planning workflow for Timeline composition, unavailable inputs, reload, and assistive access",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Schedule constraints
+
+## Why this exists
+
+Planning needs honest friction: a date conflict should be explainable, not silently “fixed”
+by a renderer that decides on behalf of the work.
+
+## Example workflow
+
+A planner moves a task before a blocking task ends. Timeline identifies the violation,
+shows the dependency and dates involved, and offers a policy-backed repair only for approval.
+
+## Product contract
+
+- Constraint evaluation consumes canonical typed Relationships, dates, ranges, and expressions.
+- Planning Views distinguish violation, uncertainty, missing input, unavailable source, and no conflict.
+- A policy may propose repairs; only an explicit accepted shared Action changes canonical records.
+- Access applies before constraints, explanations, counts, previews, exports, and agent context.
+
+## Boundaries and non-goals
+
+Dependencies and time types own inputs; Timeline is a consumer. This is not automatic
+project management, a hidden date inference system, or a separate scheduler datastore.
+
+## Acceptance stories
+
+### Explain a blocking conflict
+
+Given a task scheduled before an accessible blocker completes, when a planner opens the
+planning View, then Content identifies the typed dependency and conflicting dates clearly.
+
+### Refuse a hidden repair
+
+Given a policy offers a later start date, when the planner declines it, then no canonical
+date changes; accepting it creates one attributable shared Action and history entry.
+
+## Current evidence
+
+This record remains `exploring`; no complete constraint evaluator or repair contract is
+proven by current Timeline donor code.
+
+## Proof plan
+
+1. Test dates, ranges, dependencies, cycles, missing inputs, and uncertainty.
+2. Verify access-safe explanations, explicit repair Actions, history, and recovery.
+3. Exercise planning UI, Timeline composition, unavailable sources, reload, and accessibility.
+
+## Open questions
+
+The initial constraint policy catalog and repair proposal language remain exploratory.

package/corpus/templates/content/docs/product/capabilities/content.security.private-vault.md

@@ -0,0 +1,71 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.security.private-vault"
+name: "Private vault encryption"
+user_promise: "Private-vault custody can be user-held and fail closed without disguising unresolved recovery, collaboration, or agent authority problems."
+primary_user_job: "Keep selected work unreadable to the service while retaining understandable device, recovery, sharing, agent, and exit choices."
+kind: "primitive"
+state: "in_progress"
+publicness: "public"
+availability: "desktop"
+dependencies:
+  ["content.agent.resource-consent", "content.portability.vault-export"]
+related_features: ["content.feature.keep-your-private-vault-private"]
+roadmap_boundary: "feature"
+acceptance_summary: "A reviewed private-vault system establishes user-held cryptographic custody, explicit enrollment and device authorization, fail-closed decryption and recovery, bounded agent plaintext access, revocation, collaboration semantics, and portable exit without claiming readiness before production proof."
+proof_requirements:
+  [
+    "Threat model, protocol, key lifecycle, enrollment, recovery, revocation, and fail-closed tests across supported architectures",
+    "Agent-consent, collaboration, merge, export, and unavailable-key authorization tests",
+    "Independent security review plus production-like end-to-end device, recovery, revocation, and exit evidence",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Private vault encryption
+
+## Why this exists
+
+Private custody is a promise about who can read, not a decorative lock icon.
+
+## Example workflow
+
+A person enrolls a trusted device, opens a private vault locally, grants one local agent a bounded task, revokes the device, and exports readable authorized material without exposing plaintext to the service.
+
+## Product contract
+
+- User-held cryptographic custody, key enrollment, device authorization, rotation, revocation, and recovery are explicit ceremonies with fail-closed behavior.
+- Clients decrypt only vaults and operations they are currently authorized to handle; unavailable keys never coerce to empty or apparently successful content.
+- Agent plaintext access is separate bounded consent, not an implication of ordinary sharing or recoverable edit access.
+- Collaboration, Versions, comments, access changes, and portable exit must preserve the custody claim or state their limitation plainly.
+
+## Boundaries and non-goals
+
+This is a paused product lane, not a claim that current experiments are production-ready. Vault export owns package semantics; resource consent owns agent scope.
+
+## Acceptance stories
+
+### Fail closed on an unenrolled device
+
+Given a device without the vault key, when it opens a private-vault resource, then it receives an explicit unavailable/enrollment state and no plaintext or plausible empty document.
+
+### Revoke bounded access
+
+Given a device and an agent were separately authorized, when the owner revokes their grants, then subsequent decrypt or task attempts fail and the audit record distinguishes device revocation from agent consent.
+
+## Current evidence
+
+Donor evidence: repository feature records retain the historical research and fork boundary. No repository-local audited protocol, integration, cross-architecture proof, or production receipt supports a complete claim; this record remains `in_progress` and the Feature is paused.
+
+## Proof plan
+
+1. Publish a sanitized protocol and implementation wayfinder with threat boundaries.
+2. Test key lifecycle, recovery, revocation, agent consent, collaboration, and portable exit across architectures.
+3. Obtain independent review and production-like end-to-end evidence before changing state.
+
+## Open questions
+
+- Recovery ceremony, collaboration cryptography, and supported-device order remain material decisions.

package/corpus/templates/content/docs/product/capabilities/content.share.views.md

@@ -0,0 +1,140 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.share.views"
+name: "Shared Views"
+user_promise: "A shared View gives collaborators a dependable starting presentation while preserving each viewer's existing access and personal exploration."
+primary_user_job: "Share a useful way of seeing a collection without changing the records, exposing private rows, or trapping collaborators in my arrangement."
+kind: "primitive"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.view.query", "content.access.page-database"]
+related_features: ["content.feature.make-the-workspace-yours"]
+roadmap_boundary: "feature"
+acceptance_summary: "Shared named Views preserve one reusable presentation over a Database or Query; every viewer sees only their authorized intersection, may retain one automatic personal arrangement, and can create explicit named alternatives without forking data or granting source rows."
+proof_requirements:
+  [
+    "Stable shared and Only-me View identity, links, embeds, defaults, revisions, deletion, and personal-arrangement lifecycle",
+    "Viewer-specific access intersection across View, owner input, Source, row, field, and current authorization",
+    "UI and Action workflows for personal changes, reset, save-as-new, permitted shared updates, and access-safe degraded states",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Shared Views
+
+## Why this exists
+
+Teams need a dependable shared starting point, but a collaborator's filter,
+sort, grouping, density, or column choice should not accidentally rearrange
+everyone else's work. Sharing a presentation must also never smuggle access to
+the records behind it; a polished View is not a diplomatic passport.
+
+## Example workflow
+
+A team shares a Board over a Database. One person privately filters it to work
+assigned to them and changes column widths. Content remembers that one personal
+arrangement and marks **Viewing with personal changes**. They can reset to the
+shared View, save an explicit Only-me alternative, or—if authorized—update the
+shared default. A teammate follows the ordinary shared link and receives the
+saved Board definition, not the first person's unnamed arrangement, and sees
+only rows they can already access.
+
+## Product contract
+
+### One shared definition, personal exploration
+
+- A shared saved View owns its Database or Query input, renderer, visible
+  fields, downstream filters, sorts, groups, layout, formatting, and permitted
+  creation behavior. It never owns the input records or Query output contract.
+- Each person has at most one unnamed automatically remembered personal
+  arrangement for a shared View. It may alter presentation and downstream
+  refinement without mutating the shared definition or other viewers' state.
+- The focused View Instance carries the immediate effective state while someone
+  works. Content quietly indicates when it differs from the shared default.
+- **Reset to shared View** removes the personal arrangement. **Save as new
+  View** creates a named Only-me or otherwise permitted shared alternative.
+  **Update shared View** requires the owning input's relevant edit authority
+  and records one reversible attributable Revision.
+- Agents may inspect the shared definition, personal arrangement, effective
+  View, and delta; they may explore with ephemeral typed Queries without
+  changing UI state. They change personal, named, or shared state only when the
+  person explicitly asks and authority permits it.
+
+### Sharing narrows or intersects; it never grants rows
+
+- A named View may be shared or **Only me** and may narrow access below its
+  owning Database or Query, never widen it.
+- Effective visibility is the intersection of View access, Database/Query
+  access, Source and row access, field access, and the current viewer's
+  authorization. The View never runs with its creator's authority.
+- Counts, groups, aggregates, search, source state, field visibility, embeds,
+  agents, exports, and creation choices use that same intersection. A View does
+  not reveal inaccessible rows by their count or failure shape.
+- Restricting a View protects its configuration and surface. It does not revoke
+  independent access to the underlying Database, Query, or records elsewhere.
+- A fixed output for recipients is a separate explicitly published or
+  materialized snapshot capability, not a shared View that grants access.
+
+## Boundaries and non-goals
+
+- Database and Query Views owns generic View identity and presentation;
+  Personal View State owns detailed local persistence; this Capability owns the
+  shared/personal collaboration policy over that primitive.
+- Queries derive collections and output contracts; Views refine and render
+  them. A shared View cannot widen a Query or become a second collection.
+- This Capability does not define access-granting Views, snapshot publication,
+  a second sharing model, or copied private data.
+
+## Acceptance stories
+
+### Share a starting point without sharing a private arrangement
+
+Given a shared View and one viewer's saved personal filters, grouping, and
+column sizes, when another authorized viewer follows the ordinary View link,
+then they receive the shared definition and their own effective state, never
+the first viewer's unnamed arrangement.
+
+### Preserve row access under a shared link
+
+Given two people with different access to rows and fields of a shared View's
+input, when each opens the View, searches it, inspects group counts, asks an
+agent, or exports it, then each sees only their authorized intersection and no
+inaccessible item is exposed through metadata or aggregates.
+
+### Save an alternative without forking work
+
+Given a person changes a shared View's arrangement, when they choose **Save as
+new View** with **Only me**, then the new View has its own stable configuration
+over the same input, the shared default remains unchanged, and canonical rows
+and source authority are not copied or widened.
+
+## Current evidence
+
+Saved Database Views, filters, sorting, grouping, several renderers, and
+ordinary access checks are useful substrate. They do not yet prove the complete
+one-person arrangement lifecycle, View-configuration narrowing, shared Action
+parity, or access-safe outputs across every consumer. This Capability remains
+`approved_shape`.
+
+## Proof plan
+
+1. Create shared and Only-me Views; link, embed, pin, select defaults, update,
+   reset, save alternatives, delete, restore, and verify Revision history.
+2. Exercise one automatic personal arrangement per viewer across filters, sorts,
+   groups, layout, formatting, focus, reload, concurrent changes, and agents.
+3. Run the full access matrix through direct View reads, rows, fields, counts,
+   aggregates, search, embeds, agents, exports, creation, permission changes,
+   and source unavailability.
+4. Verify keyboard and assistive-technology behavior for personal-change state,
+   reset, save, shared update, access denial, and degraded states.
+
+## Open questions
+
+- The exact personal-arrangement storage, conflict resolution for concurrent
+  shared updates, and display of the effective-state delta remain open.
+- Snapshot publication needs its own capability contract before a fixed output
+  can be offered to recipients outside source access.

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

@@ -0,0 +1,154 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.source.adapters"
+name: "Source adapters"
+user_promise: "Local, native, and provider Sources use one typed contract while each adapter proves only the operations it can safely perform."
+primary_user_job: "Use connected work through one Content experience without losing its provider identity, authority, or meaning."
+kind: "primitive"
+state: "in_progress"
+publicness: "public"
+availability: "configured"
+dependencies: ["content.source.catalog", "content.source.sync-policy"]
+related_features:
+  [
+    "content.feature.connect-your-sources",
+    "content.feature.trust-your-connected-sources",
+    "content.feature.bring-your-local-work",
+    "content.feature.read-and-annotate-anything",
+    "content.feature.cite-what-you-found",
+    "content.feature.move-without-starting-over",
+  ]
+roadmap_boundary: "feature"
+acceptance_summary: "Adapters declare and certify their read, watch, write, create, move, delete, review, publish, fidelity, and bridge requirements; shared Content behavior routes through those declarations and preserves provenance, ownership, conflicts, and truthful outcomes."
+proof_requirements:
+  [
+    "Typed adapter declaration, validation, and action routing for identity, provenance, ownership, capabilities, policy, and receipts",
+    "Independent certification of declared operations, authorization, conflict, retry, and unknown-data behavior for each adapter",
+    "Cross-adapter interface and Action workflows that distinguish unsupported, unavailable, queued, failed, conflicted, and provider-confirmed states",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Source adapters
+
+## Why this exists
+
+People should be able to work with local folders, native Content data, and
+provider collections without treating every integration as a separate product.
+The common experience must not erase the important differences: which system
+owns a representation, what a provider permits, whether a device is available,
+and what Content cannot safely interpret.
+
+## Example workflow
+
+A team selects two provider collections and one local folder from the Sources
+catalog. Content shows them in one Query while retaining each result's origin.
+An edit to a mapped writable field routes to its one declared adapter; an
+unknown provider component remains preserved and read-only; a local-only
+operation reports that the current device lacks bridge authority. The Query is
+not a new owner and does not send the same edit to all three Sources.
+
+## Product contract
+
+### One contract, declared capabilities
+
+- A Source adapter declares stable Source and item identity, provenance,
+  supported representations, field ownership, freshness/baseline behavior,
+  authenticated grant requirements, and its certified operations.
+- Operations are explicit rather than implied by a connection: read, watch,
+  write, create, move, delete, review, publish, fidelity/export behavior, and
+  whether a trusted local bridge is required.
+- Content exposes only operations that pass the adapter declaration and the
+  current access, approval, grant, policy, and device checks. Unsupported and
+  unavailable are distinct states; neither is represented as an empty success.
+- UI, agents, automations, and APIs use the same typed Action surface and see
+  the same capability decision. Adapters do not receive private mutation paths.
+
+### Preserve one owner and one route
+
+- Adapter bindings connect an external item to stable Content identity without
+  making the provider the Page's identity or copying it into a rival datastore.
+- Source-owned fields and representations retain their adapter identity;
+  Content-owned properties, comments, memberships, views, and collaboration
+  remain Content-owned unless explicitly mapped otherwise.
+- Queries and Views project adapter-backed records but do not own canonical
+  values or provider write authority. An edit routes only through an
+  unambiguous authorized binding; ambiguous projections are read-only.
+- Provider lifecycle actions such as publish are declared separately and remain
+  guarded. An adapter's ordinary write capability never implies publish.
+
+### Certify behavior, not a provider name
+
+- An adapter may implement a narrow subset of the contract. A read-only source
+  can certify refresh without claiming write or review; a local adapter may
+  require a bridge for watch or physical writes.
+- Certification tests each declared operation's identity, authorization,
+  policy, base revision, conflict, retry, receipt, and fidelity behavior.
+  Passing one adapter's tests is evidence for that adapter, not generic proof.
+- Adapters preserve provider-owned structures they cannot safely render or edit
+  through the faithful round-tripping contract. They must not flatten unknown
+  data into a normal editable representation.
+
+## Boundaries and non-goals
+
+- The Sources catalog owns governed discovery and connection records; sync
+  policy owns user-facing write-back modes; this record owns the provider and
+  local implementation boundary between them.
+- Provider-specific codecs may define exact format mappings. They cannot widen
+  the generic adapter promise without independent contract proof.
+- Adapters are not a second access system, a generic REST proxy, or a promise
+  that all providers support the same operations.
+- Git branches, commits, pull requests, and provider publishing may be
+  adapter-specific review or lifecycle work; they are not universal Versions.
+
+## Acceptance stories
+
+### Route an edit to its sole declared owner
+
+Given a Query containing records from two writable Sources and one read-only
+Source, when an editor changes an unambiguously mapped field on one result,
+then only that result's authorized adapter receives the change, the other
+memberships do not fan out, and the receipt identifies the destination.
+
+### Reject an unavailable operation honestly
+
+Given a local Source whose current client lacks its required bridge, when a
+person asks to reveal or immediately write a local-only file, then Content
+reports the unavailable device capability and offers the applicable route; it
+does not claim the operation completed or make unrelated Content work fail.
+
+### Keep unknown provider content intact
+
+Given an adapter reads a provider representation containing an unsupported
+component, when an editor changes a separately mapped supported field and the
+adapter writes it back, then the unsupported component survives with its source
+identity and the adapter's receipt records the actual provider result.
+
+## Current evidence
+
+Content has source-backed data, provenance, local material, and provider
+adapters that are valuable substrate. Existing provider-specific behavior does
+not yet certify the common declaration model, every operation, or cross-source
+authorization and fidelity behavior. This Capability remains `in_progress`.
+
+## Proof plan
+
+1. Validate adapter declarations and Action routing for a read-only provider,
+   a writable provider, native Content, and a bridge-dependent local Source.
+2. Certify every declared operation independently, including denied grants,
+   stale bases, conflicts, retry after interrupted delivery, and provider
+   receipts; assert undeclared operations cannot be invoked.
+3. Test identity/provenance, field ownership, Query routing, access-first
+   results, unknown preservation, and lifecycle separation across adapters.
+4. Complete real-interface connection, refresh, edit, review, failure, and
+   recovery flows with assistive-technology and keyboard coverage.
+
+## Open questions
+
+- The exact adapter declaration schema and certification fixture format remain
+  implementation work.
+- Which provider operations graduate from review-only to automatic support must
+  be decided adapter by adapter after certification.

package/corpus/templates/content/docs/product/capabilities/content.source.builder-codec.md

@@ -0,0 +1,70 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.source.builder-codec"
+name: "Builder round-trip codec"
+user_promise: "Builder JSON blocks can pass through one typed codec without supported edits erasing unfamiliar provider content."
+primary_user_job: "Edit supported Builder content in Content while keeping unsupported components and provider lifecycle decisions intact."
+kind: "primitive"
+state: "approved_shape"
+publicness: "public"
+availability: "configured"
+dependencies: ["content.portability.roundtrip", "content.source.adapters"]
+related_features: ["content.feature.trust-your-connected-sources"]
+roadmap_boundary: "feature"
+acceptance_summary: "A pure typed codec maps supported Builder blocks and structured bodies in both directions, retains unknown raw components with stable provenance, detects baseline/hash conflicts, and produces deterministic golden round trips while source policy governs writes and publish."
+proof_requirements:
+  [
+    "Golden codec fixtures for supported blocks, structured bodies, unknown raw fallbacks, and deterministic output",
+    "Hash/baseline conflict, preservation, malformed input, and fidelity-report tests",
+    "Builder source workflow editing a supported field while preserving an unknown component and keeping publish guarded",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Builder round-trip codec
+
+## Why this exists
+
+Connected editing is only trustworthy if unfamiliar provider material survives the journey home.
+
+## Example workflow
+
+An editor changes a mapped Builder article body. The codec writes supported blocks, preserves an unknown component as raw source-owned data, detects a changed provider baseline, and leaves publishing as a separate review action.
+
+## Product contract
+
+- One pure typed codec is shared by repo-backed docs and CMS-backed databases where the representation applies.
+- Known blocks map to typed Content structures; unknown components retain raw payload, provider identity, ordering, and fidelity state.
+- Baselines and hashes detect stale/conflicting writes. Codec output is deterministic and covered by golden fixtures.
+- Codec conversion does not decide source truth, write mode, review, or provider publication; adapter and sync policy own those decisions.
+
+## Boundaries and non-goals
+
+This is Builder-specific format machinery, not generic Source behavior or a guarantee that every Builder component becomes editable.
+
+## Acceptance stories
+
+### Preserve an unknown component
+
+Given a Builder article contains one unknown component and one supported text block, when the editor changes the text and writes back, then the unknown component remains unchanged with provider provenance.
+
+### Stop on a stale baseline
+
+Given Builder changes the source after Content reads it, when Content attempts write-back, then the codec reports a baseline conflict and does not overwrite the newer provider representation.
+
+## Current evidence
+
+Donor evidence: `actions/_builder-cms-source-adapter.ts`, `actions/_builder-cms-source-adapter.test.ts`, and `shared/builder-source-component-registry.ts` provide concrete Builder conversion substrate. No single certified pure codec and complete golden/conflict workflow proof exists; this record remains `approved_shape`.
+
+## Proof plan
+
+1. Extract or define pure codec inputs, outputs, opaque fallbacks, and fidelity reports.
+2. Add golden, malformed, hash, conflict, and unknown-preservation fixtures.
+3. Verify a supported edit, unknown preservation, review, and guarded publish workflow.
+
+## Open questions
+
+- The first supported component matrix and raw-payload archive encoding remain open.