@agent-native/core 0.130.2 → 0.131.3

package/corpus/templates/content/docs/product/capabilities/content.access.page-database.md

@@ -0,0 +1,76 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.access.page-database"
+name: "Page and Database access"
+user_promise: "Page and Database roles separate reading, commenting, entry editing, and structure authority."
+primary_user_job: "Share work at the appropriate level without accidentally granting collection-wide power."
+kind: "primitive"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: []
+related_features: []
+roadmap_boundary: "supporting"
+acceptance_summary: "Fixed Page and Database roles are enforced by the shared Action surface before every read or mutation, including deletion and structured-value policy."
+proof_requirements:
+  [
+    "Page role decisions for view, comment, edit, and full access",
+    "Database role decisions for entry versus schema authority",
+    "Identical UI, agent, API, and automation enforcement",
+    "Deletion, select-option, source-policy, and stale-capability failure coverage",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Page and Database access
+
+## Why this exists
+
+Collaboration needs more than editor or viewer. A teammate may comment on a Page, edit a Database entry, or manage the Database structure—those are deliberately different powers.
+
+## Example workflow
+
+A manager gives a collaborator **Can edit entries** in a planning Database. The collaborator changes authorized rows but cannot alter Properties or delete the Database; a Page commenter can discuss a brief but cannot edit its body.
+
+## Product contract
+
+- Page roles are **Can view**, **Can comment**, **Can edit**, and **Full access**.
+- Database roles are **Can view**, **Can comment**, **Can edit entries**, **Can edit database**, and **Full access**.
+- Roles are fixed product roles backed by internal capabilities, not custom checkbox combinations.
+- Every UI, agent, automation, and API operation calls the same Action authorization and operation-specific validation.
+- Source truth, Property locks, and policy can narrow authority; they never widen a role.
+- Deletion and option/schema mutation require the stronger authority their impact demands.
+
+## Boundaries and non-goals
+
+- This record defines role semantics, not row-specific overrides, public publication, or derived-result closure.
+- A personal Favorite or Only-me View is a private capability, not shared edit authority.
+- Seeing an object or relationship never grants authority to mutate it.
+
+## Acceptance stories
+
+### Edit entries but not structure
+
+Given a collaborator with **Can edit entries**, when they update an allowed row, then it succeeds through UI and Action. When they rename a Property or change a select option, then it is denied without a partial mutation.
+
+### Comment without editing body
+
+Given a Page commenter, when they add a comment, then it is permitted. When they submit a body edit or ask an agent to do it, then both surfaces return the same denial.
+
+## Current evidence
+
+Current Content actions and Database permission work provide role and ownership substrate, but the complete fixed-role matrix, shared effective operation capabilities, and all destructive/structured-value paths are not yet proven together. This remains `approved_shape`.
+
+## Proof plan
+
+1. Build a role-by-operation matrix for Page and Database actions and UI controls.
+2. Test direct, bulk, agent, automation, source-backed, and stale client capability paths.
+3. Verify denial is typed and leaves content, schema, and audit state unchanged.
+4. Test role changes during a pending mutation, reload, keyboard, and assistive technology.
+
+## Open questions
+
+Internal capability representation is an implementation detail. The fixed product role vocabulary and no-widening rule are settled.

package/corpus/templates/content/docs/product/capabilities/content.access.row-private.md

@@ -0,0 +1,75 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.access.row-private"
+name: "Row-level privacy"
+user_promise: "A Page or Database row can be shared more narrowly than its collection's ordinary visibility."
+primary_user_job: "Keep a sensitive item in an otherwise shared workflow without copying it into a secret parallel system."
+kind: "primitive"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.access.page-database"]
+related_features: ["content.feature.explore-alternatives-safely"]
+roadmap_boundary: "feature"
+acceptance_summary: "Default Database visibility can be narrowed by row/Page principals, and every read, query, source operation, and mutation applies the resulting access before returning data."
+proof_requirements:
+  [
+    "Default inheritance and explicit row/Page principal behavior",
+    "Access-first query, view, search, aggregate, and export behavior",
+    "Shared Action and UI mutation enforcement",
+    "Source synchronization, deletion, restore, and access-change tests",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Row-level privacy
+
+## Why this exists
+
+A shared tracker sometimes contains a draft, personnel matter, or private alternative. The item should remain in the governed workflow without becoming ambiently discoverable.
+
+## Example workflow
+
+A team keeps a hiring Database visible to managers. One candidate row is restricted to a smaller panel. The panel can work with the row; other managers see neither its fields nor its contribution to counts.
+
+## Product contract
+
+- A Database supplies ordinary default access; a Page/row may narrow that visibility through explicit principals.
+- Narrower row access applies before list, View, Query, relation traversal, search, aggregate, export, agent context, and source operations.
+- An authorized direct link opens the Page; an unauthorized known direct link returns an honest generic denial.
+- Row privacy does not make a Page's identity dependent on a Database or grant access through another membership.
+- All mutations use the shared Action decision and record attributable history.
+
+## Boundaries and non-goals
+
+- Row privacy narrows inherited access; it does not widen a Page beyond allowed policy.
+- It does not define public publishing or named-Version access, which have their own boundaries.
+- Hiding a View column is presentation, not row privacy.
+
+## Acceptance stories
+
+### Hide a restricted row from collection work
+
+Given one private row in a shared Database, when an unauthorized member opens a View, searches, groups, or exports it, then the row and its values do not appear or affect derived output.
+
+### Keep direct access honest
+
+Given an unauthorized person knows the private row's URL, when they open it or invoke an Action, then access is denied without reporting a successful empty Page or exposing its title.
+
+## Current evidence
+
+The repository has ownable records and access-aware Content surfaces, providing substrate. It does not yet prove complete per-row principals across every derived path and source policy, so the capability remains `approved_shape`.
+
+## Proof plan
+
+1. Exercise inheritance, restriction, principal changes, and recovery through UI and Actions.
+2. Re-run Views, Queries, search, relationships, exports, agents, and aggregates for each role.
+3. Test source sync/write-back and access changes during pending work.
+4. Verify trash, restore, audit/history, and generic denial behavior.
+
+## Open questions
+
+Exact principal-management controls remain a surface design choice; no implementation may turn unavailable data into a successful empty result.

package/corpus/templates/content/docs/product/capabilities/content.access.safe-aggregate.md

@@ -0,0 +1,75 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.access.safe-aggregate"
+name: "Access-safe computation"
+user_promise: "Counts, rollups, groups, and aggregates reveal only records the viewer may access."
+primary_user_job: "Understand shared data without private records leaking through a total, relation count, or derived value."
+kind: "primitive"
+state: "exploring"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.access.page-database"]
+related_features: ["content.feature.understand-what-your-data-says"]
+roadmap_boundary: "feature"
+acceptance_summary: "Every derived computation filters inaccessible records and endpoints before traversal, grouping, measure calculation, caching, or rendering."
+proof_requirements:
+  [
+    "Relation traversal and count asymmetry repair",
+    "Access-first rollup, group, Pivot, Chart, and expression tests",
+    "No leakage through empty, error, cache, drill-down, or export states",
+    "Equivalent UI, Action, agent, and API results under changing access",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Access-safe computation
+
+## Why this exists
+
+A total can betray a secret as surely as a sentence can. Analytics must count the authorized world, not calculate privately and hide only the rows.
+
+## Example workflow
+
+A manager groups a pipeline by stage and drills into a total. Restricted opportunities are absent from both the count and the drill-down, even though authorized peers see a larger total.
+
+## Product contract
+
+- Access filters apply before relationship traversal, Query evaluation, grouping, rollup, count, measure, chart, pivot, expression, and export.
+- A result and its drill-down describe the same authorized input set.
+- Caches and precomputed indexes are implementation machinery and may not reveal an inaccessible cardinality or stale value.
+- Known inaccessible direct objects return denial; ambient derived work omits them without a side-channel.
+- UI, agents, APIs, and automations receive the same scoped result or typed failure.
+
+## Boundaries and non-goals
+
+- This record does not define query syntax, Chart presentation, or row-sharing controls.
+- It does not require hiding authorized zero results; a true zero remains meaningful.
+- Performance optimizations cannot weaken the access-before-computation ordering.
+
+## Acceptance stories
+
+### Count only visible relations
+
+Given a visible Page related to one visible and one private Page, when a viewer calculates a relation count, then it reports one and cannot infer the second endpoint from count, error, or timing behavior.
+
+### Drill into the same cohort
+
+Given a grouped aggregate with restricted rows, when a viewer opens drill-down, then every returned row and total matches the viewer-scoped aggregate rather than a wider cached cohort.
+
+## Current evidence
+
+The product architecture requires access before derived work, while the current audit identified relation-count asymmetry as a repair seam. No complete generic aggregate implementation proof exists; this capability remains `exploring`.
+
+## Proof plan
+
+1. Build adversarial fixtures for private rows/endpoints across counts, rollups, groups, expressions, pivots, charts, and exports.
+2. Compare results across UI, Actions, agents, APIs, cache refreshes, and changing access.
+3. Verify drill-down, pagination, empty/error states, and timing do not leak presence.
+4. Test source-backed values and concurrent access changes.
+
+## Open questions
+
+The evaluation and cache design are open. The access-first semantics and equal result/drill-down cohort are not.

package/corpus/templates/content/docs/product/capabilities/content.access.visibility-closure.md

@@ -0,0 +1,79 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.access.visibility-closure"
+name: "Visibility closure"
+user_promise: "Ambient traversal and derived results omit inaccessible objects while known direct links receive an honest denial."
+primary_user_job: "Follow, search, embed, publish, and export work without private neighborhoods spilling into view."
+kind: "primitive"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.access.page-database", "content.access.safe-aggregate"]
+related_features:
+  [
+    "content.feature.work-across-every-workspace",
+    "content.feature.publish-with-confidence",
+  ]
+roadmap_boundary: "feature"
+acceptance_summary: "All ambient discovery and derived surfaces close over authorized objects; direct known targets fail honestly without revealing private existence or contents."
+proof_requirements:
+  [
+    "Traversal, search, Query, embedding, and export closure",
+    "Aggregate and relationship endpoint closure",
+    "Direct-link generic denial distinct from successful absence",
+    "Public, agent, source, cache, and access-change regression coverage",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Visibility closure
+
+## Why this exists
+
+Access must remain true after information starts moving. A private object cannot become visible merely because a backlink, embed, export, or agent happened to pass nearby.
+
+## Example workflow
+
+An author publishes a Page that references internal research. Public readers see the authorized Page with the private reference omitted or safely degraded; a person with the internal link gets a generic denial rather than a plausible empty success.
+
+## Product contract
+
+- Search, traversal, Queries, Views, links, embeds, exports, public projections, and agents operate only over authorized closure.
+- A direct known target may return a generic denial; ambient lists and derived results do not confirm its existence.
+- Closure applies recursively to relationship endpoints and transcluded content before rendering or calculating.
+- Caches, previews, snippets, errors, counts, and pagination preserve the same boundary.
+- Access changes take effect before future reads and cannot be masked as normal emptiness.
+
+## Boundaries and non-goals
+
+- Visibility closure is not a replacement for Page/Database roles or row principals.
+- It does not decide how a public Page is published, only what its reachable projections may reveal.
+- It does not require every broken public reference to be silently invisible; authorized degradation can be meaningful.
+
+## Acceptance stories
+
+### Omit a private neighbor from export
+
+Given a Page with a reference or transclusion to a private neighbor, when an unauthorized viewer exports or opens a public projection, then the neighbor's content, title, and cardinality do not leak.
+
+### Differentiate denial from absence
+
+Given an unauthorized person has a direct private URL, when they request it, then they receive an honest generic denial rather than a successful empty result that callers may mistake for normal absence.
+
+## Current evidence
+
+The architecture and existing access-aware Content paths establish the required direction. Repository evidence does not yet prove closure across every traversal, export, embed, cache, and agent path; this remains `approved_shape`.
+
+## Proof plan
+
+1. Test recursive references, Relationships, transclusions, Views, search, exports, and public output under access changes.
+2. Inspect snippets, counts, errors, caches, pagination, previews, and agent summaries for side channels.
+3. Verify direct denial versus ambient omission through UI and Actions.
+4. Exercise source and integration paths plus reload and concurrent permission changes.
+
+## Open questions
+
+Exact degraded-reference presentation remains open; it must never disclose protected identity or turn denial into false success.

package/corpus/templates/content/docs/product/capabilities/content.action.button.md

@@ -0,0 +1,67 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.action.button"
+name: "Action Buttons"
+user_promise: "An owner-governed Button invokes an ordinary action or Rule with typed inputs and visible authority"
+primary_user_job: "Let people trigger a governed operation from the object where its result matters."
+kind: "primitive"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.command.fabric", "content.rule.deterministic"]
+related_features: ["content.feature.when-this-happens-that-follows"]
+roadmap_boundary: "feature"
+acceptance_summary: "Buttons are owner-governed command bindings with stable IDs, typed inputs, can-run reasons, confirmation, permission checks, receipts, and Undo where supported."
+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"
+---
+
+# Action Buttons
+
+## Why this exists
+
+A repeated local decision should be visible where people encounter its consequence, with authority and confirmation clear before anyone acts.
+
+## Example workflow
+
+A workspace owner adds an Approve button to a request Page. An editor sees its effect and required confirmation, invokes it, and receives an Event receipt with Undo when the action supports it.
+
+## Product contract
+
+Buttons are owner-governed command bindings with stable IDs, typed inputs, can-run reasons, confirmation, permission checks, receipts, and Undo where supported. They invoke the ordinary command or Rule Action; a Button never owns a private mutation path.
+
+## Boundaries and non-goals
+
+Button configuration and target Actions own behavior. This is not a macro language, hidden automation engine, or permission bypass.
+
+## Acceptance stories
+
+### Deny a button that cannot run
+
+Given an editor without the target Action permission, when they view a Button, then it explains why it cannot run and cannot invoke the operation.
+
+### Receipt and undo after approval
+
+Given a confirmed reversible Button action, when it succeeds, then Content records one ordinary Event and exposes its supported Undo route.
+
+## Current evidence
+
+Template and Action substrate exist, but no complete button insertion, authority, confirmation, receipt, and recovery proof is recorded. This Capability remains `approved_shape`.
+
+## Proof plan
+
+1. Insert template Buttons and test stable bindings, arguments, and unavailable targets.
+2. Exercise viewer, editor, owner, confirmation, cancellation, denial, receipts, Undo, and reload.
+3. Use keyboard and screen readers to discover a Button, read its effect, and recover from failure.
+
+## Open questions
+
+The exact first Button placement and confirmation copy need interaction design.

package/corpus/templates/content/docs/product/capabilities/content.agent.action-parity.md

@@ -0,0 +1,73 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.agent.action-parity"
+name: "Agent and UI parity"
+user_promise: "Humans and agents use the same operations and visible state"
+primary_user_job: "Use an agent to do ordinary Content work with the same authority, validation, and truthful result a person would receive."
+kind: "primitive"
+state: "in_progress"
+publicness: "public"
+availability: "universal"
+dependencies: []
+related_features:
+  [
+    "content.feature.durable-foundations",
+    "content.feature.when-this-happens-that-follows",
+    "content.feature.collect-structured-input",
+    "content.feature.work-on-content-inside-another-application",
+  ]
+roadmap_boundary: "feature"
+acceptance_summary: "Every operation exposes one typed Action contract for UI, agent, automation, and API callers."
+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"
+---
+
+# Agent and UI parity
+
+## Why this exists
+
+An assistant that succeeds where the editor would fail erodes trust in both surfaces. Content needs one accountable path from request to committed change.
+
+## Example workflow
+
+A person asks an agent to update a Database record. The agent calls the same Action as the editor, receives the same validation failure if it is invalid, and returns the canonical result.
+
+## Product contract
+
+Every operation exposes one typed Action contract for UI, agent, automation, and API callers. Authorization, validation, Events, history, recovery, current context, and error states are shared; caller-specific presentation cannot invent a privileged task engine.
+
+## Boundaries and non-goals
+
+Individual capability records own their concrete workflows. Parity does not mean identical interface affordances or unrestricted agent context.
+
+## Acceptance stories
+
+### Reject an agent-only privilege
+
+Given a viewer denied an edit in the UI, when an agent attempts the same edit, then the same Action denies it without leaking unavailable fields.
+
+### Observe one change from both surfaces
+
+Given an Action succeeds through an agent, when the Page is opened, then it shows one canonical mutation and ordinary history rather than an agent-only copy.
+
+## Current evidence
+
+Existing Actions provide in-progress donor substrate, but per-capability parity evaluations and real-interface proof remain incomplete. This Capability remains `in_progress`.
+
+## Proof plan
+
+1. Compare Page, Database, and collaboration Action inputs, results, and failures.
+2. Test permission changes, field visibility, history, conflict, and unavailable sources in both callers.
+3. Run paired human and agent workflows with accessible UI evidence.
+
+## Open questions
+
+The first cross-surface parity fixture catalog needs implementation design.

package/corpus/templates/content/docs/product/capabilities/content.agent.audience-safe.md

@@ -0,0 +1,91 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.agent.audience-safe"
+name: "Audience-safe synthesis"
+user_promise: "A governed agent run can synthesize from only the resources every intended viewer may access and consent to use for that audience."
+primary_user_job: "Prepare a shared answer for a defined audience without borrowing an owner's private authority or silently carrying excluded material into the result."
+kind: "workflow"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies:
+  ["content.agent.resource-consent", "content.access.visibility-closure"]
+related_features: ["content.feature.keep-your-private-vault-private"]
+roadmap_boundary: "feature"
+acceptance_summary: "A strict-audience run resolves its inputs through the intended audience's common authorized-and-consented intersection, rechecks it throughout the run, and never exposes excluded inputs through output, cache, metadata, or errors."
+proof_requirements:
+  [
+    "Audience identity and common authorized-and-consented input intersection resolved before retrieval and at every subsequent use",
+    "Strict-audience behavior that never borrows owner, author, agent, or cached private authority",
+    "Cache keys, invalidation, output handling, errors, counts, and provenance that cannot reveal excluded inputs",
+    "Real-interface workflow tests for changing audience membership, access, consent, source availability, and direct inspection",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Audience-safe synthesis
+
+## Why this exists
+
+An author can often see more than the people who will receive an agent's answer. Summarizing with the author's authority and then sharing the result can leak the very material the audience was not allowed to see. A warning after generation is too late; a careful-looking answer may already contain the private detail.
+
+Audience-safe synthesis is a workflow over resource consent and access closure. It constrains the run's inputs to the common intersection for its stated audience before the agent reasons over them.
+
+## Example workflow
+
+A project lead asks for a status update for three collaborators. The agent resolves the intended audience, then gathers only project resources that all three collaborators can access and that are consented for agent context. A private planning note and a resource one collaborator lost access to are excluded. When a fourth collaborator is added during the run, the remaining work is re-evaluated against the smaller intersection. The agent can state that its answer is based on the permitted shared material, but it does not name or count excluded inputs.
+
+## Product contract
+
+### Audience-bound input closure
+
+- A strict-audience run names an intended audience and evaluates every candidate input as the intersection of that audience's current ordinary authorization and effective agent-context consent, including resource, source, and inherited policy ceilings.
+- The run may use only inputs in that common intersection. It does not borrow the initiating owner's, author's, operator's, or agent's broader authority to fill a gap.
+- Audience changes, access changes, consent revocation, source-policy changes, and unavailable authority state are re-evaluated before each remaining retrieval, tool call, context reuse, and output-affecting step. Unreadable authority state is not treated as an empty allowed intersection.
+- Strict-audience mode is an opt-in governed workflow. It may produce a narrower answer, a truthful unavailable state, or a request to revise the audience; it may not silently broaden the audience or switch to owner-authority mode.
+
+### Outputs, caches, and provenance
+
+- Excluded inputs cannot appear in generated output, citations, snippets, titles, tool traces, error messages, counts, timing summaries, or aggregate explanations. The output may identify its declared audience and describe authorized-source limitations only when doing so does not reveal excluded material.
+- Cached retrievals, intermediate context, embeddings, plans, and generated results are scoped to the exact audience/access/consent state that authorized them. Access or consent revocation invalidates them for affected viewers; an owner-private cached result is never reused for a strict-audience run.
+- The workflow records run identity, declared audience representation, policy mode, and safe provenance needed for inspection. Origin/provenance says where an authorized result came from; it is not a review, verification, or truth guarantee.
+- Audience-safe synthesis does not prove that its answer is complete, correct, endorsed, or fit for publication. Review and verification remain separate decisions.
+
+## Boundaries and non-goals
+
+- This is not a new sharing model, an audience-wide permission grant, a way to make private resources public, or an alternative to resource consent/access closure.
+- It does not make an agent's summary authoritative, verified, or approved merely because the input intersection was safe.
+- It does not disclose the identity, existence, count, or cached remnants of resources excluded by access or consent.
+- It does not authorize owner-credential fallbacks, privileged cache reuse, or source reads outside the audience's effective closure.
+
+## Acceptance stories
+
+### Synthesize only from the common intersection
+
+Given an author can access three resources and one intended viewer cannot access one of them, when a strict-audience run creates a status update for that audience, then it uses only the two common authorized-and-consented resources and does not mention the excluded resource or its absence.
+
+### Re-evaluate a changing audience
+
+Given a strict-audience run is gathering material for two viewers, when another viewer is added or a current viewer loses access before the next retrieval, then the run re-evaluates the remaining input closure and neither uses newly excluded context nor reuses a broader cached result.
+
+### Preserve the distinction between provenance and review
+
+Given a strict-audience run produces an answer with safe authorized provenance, when a recipient opens it, then they can inspect permitted origin information appropriate to their access but do not see a claim that the result was reviewed, verified, or true unless another Capability supplied that decision.
+
+## Current evidence
+
+`content.agent.resource-consent` and `content.access.visibility-closure` define required dependencies, but neither is verified as a complete implementation. Current architecture establishes access before computation in `templates/content/docs/product/architecture.md`; no repository evidence yet proves an intended-audience intersection resolver, strict-mode cache partitioning/invalidation, or non-leaking output behavior across agent tools. This Capability remains `approved_shape`.
+
+## Proof plan
+
+1. Build deterministic resolver tests for multi-viewer intersections across Pages, Databases, Sources, inherited consent ceilings, membership changes, revocation, and authority-read failures.
+2. Verify agent retrieval, search, traversal, tool calls, aggregation, citations, error rendering, and final output use the same strict context and cannot observe excluded identity or counts.
+3. Test cache and intermediate-artifact keys against audience identity, membership/access epoch, consent epoch, source policy, and resource version; prove revocation and audience change invalidate unsafe reuse.
+4. Run real-interface workflows that define an audience, generate a result, alter its membership/access/consent mid-run, inspect safe provenance, and confirm that review/verification status remains distinct.
+
+## Open questions
+
+The durable representation of a dynamic audience, safe wording for partial-result notices, and retention rules for run intermediates remain open implementation choices. They must not weaken common-intersection input selection, strict cache isolation, or the distinction between safe provenance and verification.

package/corpus/templates/content/docs/product/capabilities/content.agent.automation.md

@@ -0,0 +1,67 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.agent.automation"
+name: "Agent-run automation"
+user_promise: "AI work composes Event → expression/query → action → mutation → Event"
+primary_user_job: "Automate bounded AI work while preserving an accountable owner, visible context, and a recoverable causal chain."
+kind: "primitive"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.rule.deterministic", "content.agent.action-parity"]
+related_features: ["content.feature.when-this-happens-that-follows"]
+roadmap_boundary: "feature"
+acceptance_summary: "An agent automation consumes an Event, evaluated expression or Query, scoped context, and typed Action."
+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"
+---
+
+# Agent-run automation
+
+## Why this exists
+
+AI work can travel farther than its initiator intended. Its boundaries must remain inspectable, stoppable, and attributable.
+
+## Example workflow
+
+A Rule detects a new intake record, prepares an owner-scoped brief, and creates a draft through a shared Action. The run shows its inputs, cost limit, resulting Event, and disable control.
+
+## Product contract
+
+An agent automation consumes an Event, evaluated expression or Query, scoped context, and typed Action. Owner authority, dry run, chain and cost limits, receipts, disablement, and supported Undo apply to every run.
+
+## Boundaries and non-goals
+
+Deterministic Rules own non-AI behavior and Action parity owns mutations. This is not background prompt execution without an owner or an unbounded self-triggering loop.
+
+## Acceptance stories
+
+### Stop a self-triggering chain
+
+Given a run reaches its chain limit, when it would emit another triggering Event, then Content stops it and records an explicit limit receipt.
+
+### Preview an owner-scoped draft
+
+Given a dry run, when the automation evaluates its context, then it returns proposed Actions and changes no canonical object.
+
+## Current evidence
+
+No complete owner, context, limit, dry-run, receipt, and recovery proof is recorded. This Capability remains `approved_shape`.
+
+## Proof plan
+
+1. Test owner delegation and revocation with bounded context, dry runs, and effect previews.
+2. Drive chains through duplicate triggers, limits, Action failure, and disablement.
+3. Inspect receipts, retry state, supported Undo, and accessible supervision.
+
+## Open questions
+
+Cost accounting and the first safe context-preview surface need design.