Compose whole responsibilities from workflows, triggers, authority, and exception policy

[George-RD]

What to build

Compose whole responsibilities from workflows, triggers, authority, and exception policy. Last ticket in the roadmap: only after Effect Truth settlement (T3) and protocol conformance (T19 WhatsApp) are stable.

Acceptance criteria

1. Design responsibility composition model. 2. Implement workflow + trigger + authority binding. 3. Add exception policy application. 4. Write end-to-end tests covering composed workflows.

Blocked by

T3 (Effect Truth settlement, epic #198), T19 (WhatsApp #131); Bell fit review

Fence: Do not start before the Bell fit review lands on build-on. Route through delivery vehicle in DIRECTION.md.

Original report

Why

A scoped standing rule removes one repeated approval at an effect boundary. That is necessary, but it is not the complete employee-like responsibility OpenSpine ultimately promises.

A real responsibility also answers:

• what event or owner delegation starts the job;
• which workflow and skills perform it;
• which accounts, objects, relationships, and data it covers;
• which effects may happen automatically and which still require review;
• budgets, schedule, expiry, drift, and escalation behavior;
• what result/receipt closes the loop;
• how the owner pauses, changes, hands off, or removes it.

Without an explicit composition model, future growth risks becoming a pile of independently approved routes, workflows, packs, and standing rules that the owner cannot understand or control as one job.

Goal

Define and ship the user-facing responsibility as a governed composition above existing runtime artifacts. Preserve the existing separation of mechanisms:

• routes/triggers choose the task;
• workflows provide deterministic shape and approval states;
• skills provide how-to knowledge;
• capability packs/policies bound authority;
• reviewed standing rules smooth specific repeated effects;
• task grants remain the sole live authority object.

The responsibility layer must reference/compose these pieces; it must not duplicate their enforcement inside a new model-controlled object.

Architecture decision

After #126 and the first Gmail proof, decide whether the durable form is:

1. a new versioned ResponsibilityManifest containing immutable digest-bound references to the component artifacts; or
2. an atomic reviewed bundle/plan that activates a compatible set of existing artifacts and stores one owner-facing responsibility record over them.

Whichever form is chosen must support atomic review/activation/rollback. The owner must never approve a responsibility whose route/workflow/authority pieces can drift independently before activation.

Required fields/semantics

• owner-facing name and purpose;
• trigger/event/task-shape selector;
• agent/workflow/skill references;
• reviewed scope and action descriptors;
• authority and approval boundaries;
• budgets, schedule, expiry, drift and exception policy;
• output/receipt contract;
• provenance/evidence and generation lineage;
• lifecycle state and compatibility fingerprint;
• pause/resume/revoke/amend controls;
• component digests/versions and base-epoch compatibility.

Product progression

The roadmap should distinguish:

1. effect shortcut — a reviewed standing rule reduces one repeated approval in an owner-initiated workflow;
2. responsibility — Lyra can recognize/accept the job, run the workflow, handle expected effects within scope, and return receipts/exceptions;
3. capability growth — miner-proposed workflow/skill/responsibility changes become new reviewed versions rather than silent mutation.

The Gmail proof in #130 may complete stage 1 with an owner-facing responsibility view. This issue owns stages 2–3.

Adversarial requirements

• One component change cannot silently widen the composed responsibility.
• A workflow update that changes effects or approval states forces a new responsibility review.
• A skill update cannot change authority; its effect attempts remain contained by the same reviewed scope/grant.
• A trigger cannot route a different principal, account, channel, or counterparty into an existing responsibility.
• Partial activation/rollback cannot leave a route live without its matching authority/controls.
• Revocation removes every reusable shortcut and trigger belonging to the responsibility without deleting historical receipts.
• Export/restore and base updates preserve or explicitly re-confirm the composition.
• The owner can inspect one coherent diff: what job changed, why, and what authority changed.

End-to-end proof after Gmail

Demonstrate one responsibility that is not merely a repeated button bypass, for example:

• a reviewed inbound communication routine for one relationship/workspace;
• or a commitment/research workflow that returns at the right time and asks only at disclosure/effect boundaries.

The owner should delegate the job in ordinary language, review the composed responsibility once, then receive concise receipts and exceptions.

Done when

• OpenSpine has a documented and versioned responsibility composition model.
• Multi-artifact review/activation is atomic and digest-bound.
• The owner controls the whole job through one lifecycle surface.
• Workflow/skill/route drift cannot silently widen authority.
• One end-to-end owner path runs from trigger through workflow, scoped effects, result, and receipt without exposing internal artifact management.

Relationship

Parent: #123.

Requires the architecture contract #126 and should start after the first effect-shortcut proof #130. The protocol conformance work #131 should inform its connector/task-shape abstractions.

[George-RD]

Headless and trigger boundary to make explicit

The current headless action path deliberately sets headless: true, which prevents a standing rule from downgrading ApprovalRequired to Allow. That is a sound fail-closed default. It also means the employee-like product cannot gain unattended inbound/scheduled responsibilities merely by adding a standing rule.

Whole-responsibility composition must therefore define a separately reviewed trigger/headless contract:

• which verified event source, connector instance, account, route, workflow, principal, counterparty/task shape, and schedule may start the job;
• which task grant is composed for each firing;
• which effects may consult the responsibility's reviewed rules without a live owner conversation;
• where neutral counterparty deferral and deterministic owner escalation apply;
• how replay/idempotency and one-message-at-a-time/thread binding work;
• how pause/revoke immediately prevents new firings while preserving in-flight recovery truth.

Do not remove the current blanket headless refusal until an explicit responsibility/trigger proof replaces it. A generic standing rule must never make arbitrary webhooks, timers, or inbound messages self-approving.

[coderabbitai]

Coding Plan

Summary

• Add a versioned ResponsibilityManifest as a new proposable artifact kind. It pins exact component digests/versions and rides the existing digest-bound propose→eval-gate→approve→activate ceremony, so review and activation are atomic and pieces cannot drift before activation.
• Reuse existing primitives as sealed layers: compose_authority/gate() for enforcement (the responsibility scope only narrows authority), compatibility_epoch/dependency_fingerprint for drift detection and forced re-review, overlay_export_restore's bundle+rollback FSM as the reference for atomic co-activation, and escalation.rs/the audit trail for receipts and exceptions.
• Give the owner one lifecycle surface: pause/resume/revoke/amend, receipts, exceptions, and one coherent WYSIWYS diff. Keep the TaskGrant the sole live authority object, and add only a non-authority responsibility_id annotation for correlation.
• Extend the reflection miner to propose new reviewed responsibility versions (stage 3). Prove one non-trivial end-to-end owner path with adversarial tests, all landed through the openspec change ceremony.

Design Choices

Design Choice 1: Durable form of the responsibility (the ticket's explicit architecture decision)

Options Considered:

1. A new versioned ResponsibilityManifest artifact kind that carries immutable, digest-and-version-pinned references to its component artifacts and rides the existing single-artifact atomic activation ceremony; the manifest is the one owner-facing record and its pins are re-checked at activation.
2. An atomic reviewed bundle/plan that co-activates a compatible set of component artifacts through a new bundle-level transaction (an extension of the overlay_export_restore control-plane OperationStage FSM) and stores one owner-facing record over them.

Chosen Option: 1

Rationale: Option 1 reuses the existing digest-bound single-artifact atomic activation and drift machinery with the least net-new code. It directly enforces "pieces cannot drift independently before activation" through pinned component digests. It treats existing components as sealed reusable primitives. The bundle/FSM pattern from Option 2 is reused only for the narrower case of co-proposing several new components under one review (Phase 4).

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Governance, Specification, and Architecture Contract

This phase establishes the capability in the openspec process before code. It records the architecture decision and defines the testable requirements that all later phases must satisfy.

Task 1: Create the responsibility-composition capability spec and change

Author the new capability and its delta spec following repo conventions.

• Create a dated change directory under openspec/changes/ (for example openspec/changes/<date>-implement-responsibility-composition/) with proposal.md, design.md, tasks.md, and a delta specs/responsibility-composition/spec.md.
• In proposal.md, state the composition-over-enforcement principle. Mark it authority-sensitive. List non-goals (no re-implementation of compose_authority/gate()/route resolution; the stage-1 Gmail shortcut stays owned by #130).
• In the delta spec, use ## ADDED Requirements with ### Requirement: MUST statements and Gherkin #### Scenario: blocks. Encode the adversarial requirements: no silent widening, workflow-change forces re-review, skill cannot change authority, trigger cannot rebind counterparty, atomic partial activation/rollback, revocation preserves receipts, export/restore preserves composition, one coherent diff.

Task 2: Record the decision and amend the change sequence

Ground the new capability in the decision canon and dependency order.

• Add a new D-0xx entry in .raw/openspine-decision-log.md. Capture the chosen durable form (versioned ResponsibilityManifest with pinned component digests) and the rationale.
• Append an implement-responsibility-composition subsection to openspec/openspine-change-sequence.md with Canon:, Requires: implement-artifact-lifecycle-slice; implement-standing-rules; implement-gate-action-api; implement-authority-composition; implement-reflection-miner., and terse Scope:/Done when: bullets.
• Update the roadmap and capability ledger (site/src/content/docs/roadmap.md, capabilities/capability-map.json). Mark stages 2–3 of the progressive-delegation loop as in progress. Define the effect-shortcut / responsibility / capability-growth distinction.

🤖 Prompt for AI agents

Implement Phase 1: set up the openspec governance artifacts for the
responsibility-composition capability before writing any code.

- Create a dated change directory under `openspec/changes/` (e.g.
`openspec/changes/<date>-implement-responsibility-composition/`) containing
`proposal.md`, `design.md`, `tasks.md`, and a delta spec at
`specs/responsibility-composition/spec.md`.
- In `proposal.md`: state the composition-over-enforcement principle, mark the
change authority-sensitive, and list non-goals — no re-implementation of
`compose_authority`/`gate()`/route resolution, and the stage-1 Gmail shortcut
stays owned by ticket `#130`.
- In the delta spec: use `## ADDED Requirements` with `### Requirement:` MUST
statements, each with Gherkin `#### Scenario:` blocks. Cover these adversarial
requirements: no silent authority widening, a workflow change forces re-review,
a skill update cannot change authority, a trigger cannot rebind counterparty,
partial activation must roll back atomically, revocation preserves receipts,
export/restore preserves composition, and reviews present one coherent diff.
- Add a new `D-0xx` decision entry to `.raw/openspine-decision-log.md`
documenting the chosen durable form (versioned `ResponsibilityManifest` with
pinned component digests) and its rationale.
- Append an `implement-responsibility-composition` subsection to
`openspec/openspine-change-sequence.md` including `Canon:`, `Requires:
implement-artifact-lifecycle-slice; implement-standing-rules;
implement-gate-action-api; implement-authority-composition;
implement-reflection-miner.`, plus `Scope:` and `Done when:` bullets.
- Update `site/src/content/docs/roadmap.md` and
`capabilities/capability-map.json` to mark stages 2–3 of the
progressive-delegation loop as in progress, and to define the distinction
between effect-shortcut, responsibility, and capability-growth.

Phase 2: Responsibility Schema and Compatibility Primitives

This phase adds the pure data model in openspine-schemas. The type only references other artifacts by pinned digest/version. It holds no live-authority fields and reuses existing digest/lineage primitives.

Task 1: Add the ResponsibilityManifest type

Introduce the composition record as a new declarative artifact type.

• Create crates/openspine-schemas/src/responsibility.rs defining ResponsibilityManifest with id: ArtifactId, schema_version, version, lifecycle_state: Lifecycle, owner-facing name/purpose, a trigger selector, component references, reviewed scope/action descriptors, an authority/approval boundaries summary, budgets/schedule/expiry/drift/exception-policy fields, an output/receipt contract, provenance/lineage: ArtifactLineage, and the compatibility fingerprint fields.
• Represent each component reference as a pinned tuple {kind, artifact_id, version, content_digest: Digest} (reusing Digest, ArtifactRef, and the (kind, artifact_id, version) shape from lineage.rs). This binds the manifest to the exact reviewed bytes of route/workflow/agent/pack/policy/standing-rule/skill components.
• Bind the trigger selector to the identity dimensions that must not rebind after review: pin channel_account, resolved RelationshipKind, account, and counterparty key alongside the route reference. This stops a trigger from later routing a different principal/account/channel/counterparty into the responsibility.
• Add deny_unknown_fields and a validate() method that rejects any authority-shaped field on the manifest itself. The manifest is a composition input; it must never become a live authority object.
• Register the module in crates/openspine-schemas/src/lib.rs.

Task 2: Define the composition compatibility fingerprint

Provide a deterministic fingerprint over the pinned component set.

• Add a pure composition_fingerprint() on ResponsibilityManifest that produces an order-independent digest over the sorted {kind|id|version|content_digest} component tuples, mirroring overlay_compat::compatibility_epoch() semantics.
• Add helper predicates that reuse the dependency_fingerprint_allows subset-check idiom. Given a current live-registry digest set, these predicates decide whether the reviewed composition still holds or requires re-review.

🤖 Prompt for AI agents

Implement Phase 2: add the pure `ResponsibilityManifest` data model and its
compatibility fingerprint to `openspine-schemas`. The type must reference other
artifacts only by pinned digest/version and must hold no live-authority fields.

- Create `crates/openspine-schemas/src/responsibility.rs` defining
`ResponsibilityManifest` with fields: `id: ArtifactId`, `schema_version`,
`version`, `lifecycle_state: Lifecycle`, owner-facing `name`/`purpose`, a
`trigger` selector, component references, reviewed scope/action descriptors, an
authority/approval boundaries summary,
budgets/schedule/expiry/drift/exception-policy fields, an output/receipt
contract, `provenance`/`lineage: ArtifactLineage`, and compatibility fingerprint
fields.
- Represent each component reference as a pinned tuple `{kind, artifact_id,
version, content_digest: Digest}`, reusing `Digest`, `ArtifactRef`, and the
`(kind, artifact_id, version)` shape already defined in `lineage.rs`. This must
bind the manifest to the exact reviewed bytes of each
route/workflow/agent/pack/policy/standing-rule/skill component.
- In the trigger selector, pin `channel_account`, the resolved
`RelationshipKind`, the account, and the counterparty key alongside the route
reference, so the trigger cannot later rebind a different
principal/account/channel/counterparty into the responsibility.
- Add `deny_unknown_fields` on the struct and a `validate()` method that rejects
any authority-shaped field on the manifest, since the manifest must remain a
composition input and never a live authority object.
- Register the new module in `crates/openspine-schemas/src/lib.rs`.
- Add a pure `composition_fingerprint()` method on `ResponsibilityManifest` that
computes an order-independent digest over the sorted
`{kind|id|version|content_digest}` component tuples, following the same
semantics as `overlay_compat::compatibility_epoch()`.
- Add helper predicates that reuse the `dependency_fingerprint_allows`
subset-check idiom, to decide — given a current live-registry digest set —
whether the reviewed composition still holds or needs re-review.

Phase 3: Kernel Lifecycle — Propose, Atomic Digest-Bound Activation, and Drift

This phase makes responsibility a proposable artifact kind that rides the existing digest-bound ceremony. It activates atomically with all component pins re-verified, and it triggers re-review on drift.

Task 1: Add responsibility as a proposable artifact kind

Route the new kind through the unchanged propose→eval-gate→review→approve pipeline.

• Extend the proposable-kind handling in crates/openspine-kernel/src/api/artifact_propose.rs to accept kind = responsibility, parse and validate() the ResponsibilityManifest, and reject any lifecycle_state != Proposed.
• Reuse the existing AD-142 overlay eval gate and promote_authority_bearing_proposal path. Add no new bypass.
• At propose time, resolve each pinned component reference against the live registry. Reject the proposal if any referenced component is not Active or if its live content digest differs from the pinned digest, so the reviewed composition is internally consistent before it can reach review_required.

Task 2: Activate the responsibility atomically with pin re-verification

Guarantee the owner never activates a composition whose pieces drifted.

• Extend crates/openspine-kernel/src/pipeline/artifact_activation.rs to handle the responsibility kind under the existing ACTIVATION_LOCK and single Immediate transaction commit-then-publish ordering.
• Before publishing, re-verify every pinned component digest/version against the current live registry inside the same transaction. If any component drifted, fail closed and issue a digest-bound artifact.reconfirm request instead of publishing (reusing the existing reconfirmation path in pipeline/artifact_reconfirmation.rs).
• Persist the responsibility record and its accepted composition_fingerprint and accepted_base_epoch in a new store module crates/openspine-kernel/src/store/responsibilities.rs, following the durable schema and audit patterns of store/standing_rules.rs and store/learned_artifacts.rs. Append responsibility.activated/responsibility.superseded audit rows.

Task 3: Detect drift and force re-review

Make any component change that affects effects or approval states return the responsibility to review.

• In crates/openspine-kernel/src/overlay_compat.rs, extend the base-update revalidation to recompute each active responsibility's composition_fingerprint against the current registry. When a pinned component version/digest changes, mark the responsibility needs_review and exclude it from effective composition (fail closed), reusing the CompatibilityStatus idiom.
• Ensure a workflow update that changes candidate action lists or approval semantics changes the workflow content digest, and therefore trips the fingerprint check, forcing a new responsibility review.
• Ensure a skill update changes only skill content (skills carry no authority fields), so the responsibility's reviewed scope/grant stays unaffected, while the skill body change still trips the fingerprint and surfaces for owner awareness where the skill is a pinned component.

🤖 Prompt for AI agents

Implement Phase 3: wire `responsibility` into the kernel's existing digest-bound
propose→eval-gate→approve→activate ceremony, with atomic activation and
drift-triggered re-review.

- In `crates/openspine-kernel/src/api/artifact_propose.rs`, extend the
proposable-kind handling to accept `kind = responsibility`. Parse and call
`validate()` on the `ResponsibilityManifest`. Reject any proposal whose
`lifecycle_state != Proposed`.
- Reuse the existing AD-142 overlay eval gate and
`promote_authority_bearing_proposal` path unchanged. Do not add a new bypass.
- At propose time, resolve each pinned component reference against the live
registry. Reject the proposal if any referenced component is not `Active`, or if
its live content digest differs from the pinned digest. This keeps the reviewed
composition internally consistent before it reaches `review_required`.
- In `crates/openspine-kernel/src/pipeline/artifact_activation.rs`, add handling
for the `responsibility` kind under the existing `ACTIVATION_LOCK` and the
existing single `Immediate` transaction commit-then-publish ordering.
- Before publishing, re-verify every pinned component digest/version against the
current live registry inside the same transaction. If any component has drifted,
fail closed and issue a digest-bound `artifact.reconfirm` request instead of
publishing, reusing the existing reconfirmation path in
`pipeline/artifact_reconfirmation.rs`.
- Create `crates/openspine-kernel/src/store/responsibilities.rs` to persist the
responsibility record together with its accepted `composition_fingerprint` and
`accepted_base_epoch`, following the durable schema and audit patterns already
used in `store/standing_rules.rs` and `store/learned_artifacts.rs`. Append
`responsibility.activated`/`responsibility.superseded` audit rows.
- In `crates/openspine-kernel/src/overlay_compat.rs`, extend the base-update
revalidation to recompute each active responsibility's `composition_fingerprint`
against the current registry. When a pinned component's version/digest changes,
mark the responsibility `needs_review` and exclude it from effective composition
(fail closed), reusing the existing `CompatibilityStatus` idiom.
- Confirm that a workflow update that changes candidate action lists or approval
semantics changes the workflow's content digest, which trips the fingerprint
check and forces a new responsibility review.
- Confirm that a skill update changes only skill content, since skills carry no
authority fields, so the responsibility's reviewed scope/grant stays unaffected.
The skill body change must still trip the fingerprint and surface for owner
awareness wherever the skill is a pinned component.

Phase 4: Composition, Scope Narrowing, and Adversarial Enforcement

This phase wires the active responsibility into grant composition as a purely-narrowing input and enforces the remaining adversarial guarantees, reusing the existing pure composition and standing-rule gate layers.

Task 1: Narrow composed grants by responsibility scope

Apply responsibility scope without re-implementing compose_authority.

• After resolve_route matches a route belonging to a responsibility, resolve the active responsibility in crates/openspine-kernel/src/pipeline/driver.rs at the existing post-compose/pre-seal seam (where persona binding runs).
• Feed responsibility-derived denies/approval-required/candidate-allows through the existing AuthorityInput.session: SessionPolicy narrowing source, or post-filter the Granted grant using the same "intersect, never union" discipline; never widen. Seal exactly once, after all narrowing.
• Add an optional annotation field responsibility_id to TaskGrant in crates/openspine-schemas/src/grant.rs (parallel to persona_id/thread_id). This field carries no authority; use it only for receipt/audit correlation.
• Verify the trigger's resolved principal/account/channel/counterparty match the responsibility's pinned trigger selector before applying its scope. On mismatch, do not apply the responsibility and fail closed to normal composition.

Task 2: Associate standing rules with the responsibility and keep the gate layer unchanged

Group the responsibility's reusable shortcuts without changing the pure gate() decision.

• Record the responsibility→standing-rule association in store/responsibilities.rs so that the responsibility owns the set of standing rules it composes. Do not add a grouping column inside store/standing_rules.rs enforcement paths.
• Keep crates/openspine-kernel/src/standing_rules_gate.rs and the pure openspine-gate::gate() unchanged; standing rules remain a post-decision budget waiver keyed by action_id.

Task 3: Support co-proposing multiple new components under one review

Handle the case where a responsibility needs new components created atomically with it.

• For responsibilities that require net-new component artifacts, sequence the individual single-artifact atomic activations behind one owner approval whose digest binds all constituent digests, so partial activation cannot leave a route live without its matching authority/controls.
• Reuse the signed-manifest + OperationStage rollback FSM pattern from crates/openspine-kernel/src/overlay_export_restore/ as the reference for the staged install with an explicit rollback branch. Parameterize scope to the responsibility rather than the whole data root.

🤖 Prompt for AI agents

Implement Phase 4: wire the active responsibility into grant composition as a
purely-narrowing input, and enforce the remaining adversarial guarantees, while
keeping `compose_authority` and `gate()` unchanged.

- In `crates/openspine-kernel/src/pipeline/driver.rs`, after `resolve_route`
matches a route belonging to a responsibility, resolve the active responsibility
at the existing post-compose/pre-seal seam (the same seam where persona binding
runs).
- Feed responsibility-derived denies/approval-required/candidate-allows through
the existing `AuthorityInput.session: SessionPolicy` narrowing source, or
post-filter the `Granted` grant using the same "intersect, never union"
discipline. The responsibility must never widen authority. Seal the grant
exactly once, after all narrowing is applied.
- In `crates/openspine-schemas/src/grant.rs`, add an optional annotation field
`responsibility_id` to `TaskGrant`, parallel to the existing
`persona_id`/`thread_id` fields. This field must carry no authority and must be
used only for receipt/audit correlation.
- Before applying responsibility scope, verify that the trigger's resolved
principal/account/channel/counterparty match the responsibility's pinned trigger
selector. On any mismatch, do not apply the responsibility, and fail closed to
normal composition.
- In `store/responsibilities.rs`, record the responsibility→standing-rule
association so the responsibility owns the set of standing rules it composes. Do
not add a grouping column inside the `store/standing_rules.rs` enforcement
paths.
- Leave `crates/openspine-kernel/src/standing_rules_gate.rs` and the pure
`openspine-gate::gate()` unchanged. Standing rules remain a post-decision budget
waiver keyed by `action_id`.
- For responsibilities that require net-new component artifacts, sequence the
individual single-artifact atomic activations behind one owner approval whose
digest binds all constituent digests, so a partial activation cannot leave a
route live without its matching authority/controls.
- Reuse the signed-manifest + `OperationStage` rollback FSM pattern from
`crates/openspine-kernel/src/overlay_export_restore/` as the reference
implementation for this staged install, including an explicit rollback branch.
Parameterize the scope to the responsibility, not the whole data root.

Phase 5: Owner Controls, Receipt/Exception Surface, and Coherent Diff

This phase gives the owner one lifecycle surface: pause/resume/revoke/amend, concise receipts, exceptions, and one coherent review diff.

Task 1: Add pause/resume/revoke/amend controls

Give the owner whole-job lifecycle control.

• In store/responsibilities.rs, add durable states and audited transitions for active, paused, and revoked. Implement amend as a new monotonic version re-proposal through the Phase 3 ceremony (no edit-in-place), matching standing-rule versioning semantics.
• On revoke, revoke every standing rule the responsibility owns (reuse the idempotent, audited revoke_standing_rule) and deactivate its trigger/route participation, while preserving all historical receipts and audit rows. Revocation deletes reusable shortcuts and triggers; it never deletes receipts.
• Expose these controls through the digest-bound owner-approval callback pattern used in pipeline/plan_approval.rs, so control actions are authenticated and audited.

Task 2: Define the receipt and exception contract

Close the loop with concise receipts and route exceptions to the owner.

• Define an owner-facing responsibility receipt as a bounded, content-addressed projection (reuse the TaskSlice/ArtifactRef pattern) that records which matching action fired, under which responsibility and standing-rule id, its digest, and outcome. Source the content from the existing audit trail, not from TaskGrant fields.
• Follow the receipt-keyed idempotency rule already used across the kernel: bind an idempotency key to the request digest, so replay never re-runs the effect.
• For exceptions, reuse crates/openspine-schemas/src/escalation.rs: route responsibility-scope denials and boundary escalations through EscalationEvent (add a new EscalationPayload variant if required) and the FailureClass routing in failure_surfacing.rs. Do not create a parallel notification channel.

Task 3: Present one coherent responsibility diff and view

Let the owner inspect what job changed, why, and what authority changed.

• Extend the owner-facing API layer (near crates/openspine-kernel/src/api/task.rs/api/plan.rs) with a redacted responsibility view that shows name/purpose, trigger selector, component references, effective scope, budgets/expiry, current lifecycle state, and recent receipts, without exposing internal artifact-management surfaces.
• For review and amend, render one coherent diff that shows the changed job, the reason (miner provenance or owner delegation), and the authority delta between the prior and proposed composition, using the WYSIWYS digest-bound rendering pattern from PlanApprovalQuestion so the rendered text and approved digest cannot diverge.

🤖 Prompt for AI agents

Implement Phase 5: give the owner a single lifecycle surface over the
responsibility, covering pause/resume/revoke/amend controls, a receipt and
exception contract, and a coherent review diff.

- In `store/responsibilities.rs`, add durable states and audited transitions for
`active`, `paused`, and `revoked`. Implement amend as a new monotonic `version`
re-proposal that goes through the Phase 3 propose/activate ceremony — never edit
the record in place — matching the existing standing-rule versioning semantics.
- On revoke, revoke every standing rule owned by the responsibility (reuse the
existing idempotent, audited `revoke_standing_rule`) and deactivate the
responsibility's trigger/route participation. Preserve all historical receipts
and audit rows: revocation deletes reusable shortcuts and triggers, but it must
never delete receipts.
- Expose the pause/resume/revoke/amend controls through the digest-bound
owner-approval callback pattern already used in `pipeline/plan_approval.rs`, so
every control action is authenticated and audited.
- Define an owner-facing responsibility receipt as a bounded, content-addressed
projection, reusing the `TaskSlice`/`ArtifactRef` pattern. Each receipt must
record which matching action fired, under which responsibility and standing-rule
id, its digest, and its outcome. Source the receipt content from the existing
audit trail, not from `TaskGrant` fields.
- Follow the receipt-keyed idempotency rule already used across the kernel: bind
an idempotency key to the request digest, so a replay never re-runs the effect.
- For exceptions, reuse `crates/openspine-schemas/src/escalation.rs`. Route
responsibility-scope denials and boundary escalations through `EscalationEvent`
(adding a new `EscalationPayload` variant if required) and through the
`FailureClass` routing already defined in `failure_surfacing.rs`. Do not create
a separate, parallel notification channel.
- Extend the owner-facing API layer, near
`crates/openspine-kernel/src/api/task.rs`/`api/plan.rs`, with a redacted
responsibility view. The view must show name/purpose, trigger selector,
component references, effective scope, budgets/expiry, current lifecycle state,
and recent receipts. It must not expose internal artifact-management surfaces.
- For review and amend, render one coherent diff. The diff must show the changed
job, the reason for the change (miner provenance or owner delegation), and the
authority delta between the prior and proposed composition. Use the WYSIWYS
digest-bound rendering pattern already used in `PlanApprovalQuestion`, so the
rendered text and the approved digest can never diverge.

Phase 6: Capability Growth and End-to-End Proof

This phase completes stage 3 (miner-proposed responsibility changes become new reviewed versions) and demonstrates one non-trivial owner path end to end.

Task 1: Extend the reflection miner to propose responsibility versions

Make repeated approvals/corrections produce a reviewed responsibility change, not a silent mutation.

• Add a ResponsibilityCandidate proposal variant to the pure ReflectionMiner in crates/openspine-schemas/src/reflection_miner.rs, hard-coding lifecycle_state = Proposed and reusing the kernel-counted repeated-approval evidence and provenance-binding guards.
• Serialize it to the {kind: responsibility, yaml} payload in crates/openspine-schemas/src/reflection_miner_payload.rs and dispatch it through the unchanged dispatch_reflection_proposal path in crates/openspine-kernel/src/reflection_miner_runtime.rs, so activation still requires explicit owner approval via the Phase 3 ceremony.
• Preserve the miner's structural inability to hold mutation authority; the miner proposes new versions only and never widens authority.

Task 2: Wire and verify one end-to-end responsibility path

Demonstrate delegation → composed review → scoped effects → receipts/exceptions.

• Implement one starter responsibility (for example a reviewed inbound communication routine for one relationship/workspace) that composes a route/trigger, workflow, skills, pack/policy, and standing rules, and returns receipts with escalation only at disclosure/effect boundaries.
• Add integration tests that exercise the adversarial requirements: a component change forces re-review; a skill update does not change authority; a trigger with a different counterparty is not admitted; a mid-activation failure rolls back with no route left live without authority; export/restore preserves or re-confirms the composition.
• Run the openspec ceremony (./scripts/check.sh, reviewer pass, then openspec archive and openspec validate --all --strict).

🤖 Prompt for AI agents

Implement Phase 6: extend the reflection miner to propose new reviewed
responsibility versions, and prove the full responsibility path end to end with
adversarial tests.

- In `crates/openspine-schemas/src/reflection_miner.rs`, add a
`ResponsibilityCandidate` proposal variant to the pure `ReflectionMiner`.
Hard-code `lifecycle_state = Proposed`. Reuse the existing kernel-counted
repeated-approval evidence and provenance-binding guards.
- In `crates/openspine-schemas/src/reflection_miner_payload.rs`, serialize the
candidate to the `{kind: responsibility, yaml}` payload format.
- Dispatch the payload through the unchanged `dispatch_reflection_proposal` path
in `crates/openspine-kernel/src/reflection_miner_runtime.rs`, so activation
still requires explicit owner approval via the Phase 3 propose/activate
ceremony.
- Preserve the miner's structural inability to hold mutation authority: the
miner must propose new versions only, and must never widen authority.
- Implement one starter responsibility end to end — for example, a reviewed
inbound communication routine for one relationship/workspace — that composes a
route/trigger, workflow, skills, pack/policy, and standing rules, and that
returns receipts with escalation only at disclosure/effect boundaries.
- Add integration tests that exercise the adversarial requirements: a component
change forces re-review; a skill update does not change authority; a trigger
with a different counterparty is not admitted; a mid-activation failure rolls
back with no route left live without authority; export/restore preserves or
re-confirms the composition.
- Run the openspec ceremony: run `./scripts/check.sh`, complete a reviewer pass,
then run `openspec archive` and `openspec validate --all --strict`.

Research

OpenSpine splits into openspine-schemas (pure data types and digest/id primitives), openspine-authority (pure composition: compose_authority, resolve_route, resolve_persona, mint_worker_grant, authority-equivalence classes), openspine-gate (pure gate() decision), and openspine-kernel (all I/O, storage, orchestration).

Declarative artifacts (route, workflow, pack, policy, persona, skill, standing rule) only contribute candidate authority. The TaskGrant produced by compose_authority is the sole live authority object.

The artifact lifecycle (Proposed→Validated→ReviewRequired→Approved→Active→{Quarantined,Retired}) rides a digest-bound propose→eval-gate→approve→activate ceremony with single-artifact atomic commit-then-publish.

Standing rules are the current runtime primitive that product docs call a "responsibility."

Compatibility drift uses compatibility_epoch() plus dependency_fingerprint. Multi-component atomicity exists only in overlay_export_restore (signed bundle manifest + OperationStage rollback FSM).

No "responsibility", grouping, or multi-artifact review concept exists today.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement Phase 1: set up the openspec governance artifacts for the
responsibility-composition capability before writing any code.

- Create a dated change directory under `openspec/changes/` (e.g.
`openspec/changes/<date>-implement-responsibility-composition/`) containing
`proposal.md`, `design.md`, `tasks.md`, and a delta spec at
`specs/responsibility-composition/spec.md`.
- In `proposal.md`: state the composition-over-enforcement principle, mark the
change authority-sensitive, and list non-goals — no re-implementation of
`compose_authority`/`gate()`/route resolution, and the stage-1 Gmail shortcut
stays owned by ticket `#130`.
- In the delta spec: use `## ADDED Requirements` with `### Requirement:` MUST
statements, each with Gherkin `#### Scenario:` blocks. Cover these adversarial
requirements: no silent authority widening, a workflow change forces re-review,
a skill update cannot change authority, a trigger cannot rebind counterparty,
partial activation must roll back atomically, revocation preserves receipts,
export/restore preserves composition, and reviews present one coherent diff.
- Add a new `D-0xx` decision entry to `.raw/openspine-decision-log.md`
documenting the chosen durable form (versioned `ResponsibilityManifest` with
pinned component digests) and its rationale.
- Append an `implement-responsibility-composition` subsection to
`openspec/openspine-change-sequence.md` including `Canon:`, `Requires:
implement-artifact-lifecycle-slice; implement-standing-rules;
implement-gate-action-api; implement-authority-composition;
implement-reflection-miner.`, plus `Scope:` and `Done when:` bullets.
- Update `site/src/content/docs/roadmap.md` and
`capabilities/capability-map.json` to mark stages 2–3 of the
progressive-delegation loop as in progress, and to define the distinction
between effect-shortcut, responsibility, and capability-growth.
===============================================================================

Task: 2

Implement Phase 2: add the pure `ResponsibilityManifest` data model and its
compatibility fingerprint to `openspine-schemas`. The type must reference other
artifacts only by pinned digest/version and must hold no live-authority fields.

- Create `crates/openspine-schemas/src/responsibility.rs` defining
`ResponsibilityManifest` with fields: `id: ArtifactId`, `schema_version`,
`version`, `lifecycle_state: Lifecycle`, owner-facing `name`/`purpose`, a
`trigger` selector, component references, reviewed scope/action descriptors, an
authority/approval boundaries summary,
budgets/schedule/expiry/drift/exception-policy fields, an output/receipt
contract, `provenance`/`lineage: ArtifactLineage`, and compatibility fingerprint
fields.
- Represent each component reference as a pinned tuple `{kind, artifact_id,
version, content_digest: Digest}`, reusing `Digest`, `ArtifactRef`, and the
`(kind, artifact_id, version)` shape already defined in `lineage.rs`. This must
bind the manifest to the exact reviewed bytes of each
route/workflow/agent/pack/policy/standing-rule/skill component.
- In the trigger selector, pin `channel_account`, the resolved
`RelationshipKind`, the account, and the counterparty key alongside the route
reference, so the trigger cannot later rebind a different
principal/account/channel/counterparty into the responsibility.
- Add `deny_unknown_fields` on the struct and a `validate()` method that rejects
any authority-shaped field on the manifest, since the manifest must remain a
composition input and never a live authority object.
- Register the new module in `crates/openspine-schemas/src/lib.rs`.
- Add a pure `composition_fingerprint()` method on `ResponsibilityManifest` that
computes an order-independent digest over the sorted
`{kind|id|version|content_digest}` component tuples, following the same
semantics as `overlay_compat::compatibility_epoch()`.
- Add helper predicates that reuse the `dependency_fingerprint_allows`
subset-check idiom, to decide — given a current live-registry digest set —
whether the reviewed composition still holds or needs re-review.
===============================================================================

Task: 3

Implement Phase 3: wire `responsibility` into the kernel's existing digest-bound
propose→eval-gate→approve→activate ceremony, with atomic activation and
drift-triggered re-review.

- In `crates/openspine-kernel/src/api/artifact_propose.rs`, extend the
proposable-kind handling to accept `kind = responsibility`. Parse and call
`validate()` on the `ResponsibilityManifest`. Reject any proposal whose
`lifecycle_state != Proposed`.
- Reuse the existing AD-142 overlay eval gate and
`promote_authority_bearing_proposal` path unchanged. Do not add a new bypass.
- At propose time, resolve each pinned component reference against the live
registry. Reject the proposal if any referenced component is not `Active`, or if
its live content digest differs from the pinned digest. This keeps the reviewed
composition internally consistent before it reaches `review_required`.
- In `crates/openspine-kernel/src/pipeline/artifact_activation.rs`, add handling
for the `responsibility` kind under the existing `ACTIVATION_LOCK` and the
existing single `Immediate` transaction commit-then-publish ordering.
- Before publishing, re-verify every pinned component digest/version against the
current live registry inside the same transaction. If any component has drifted,
fail closed and issue a digest-bound `artifact.reconfirm` request instead of
publishing, reusing the existing reconfirmation path in
`pipeline/artifact_reconfirmation.rs`.
- Create `crates/openspine-kernel/src/store/responsibilities.rs` to persist the
responsibility record together with its accepted `composition_fingerprint` and
`accepted_base_epoch`, following the durable schema and audit patterns already
used in `store/standing_rules.rs` and `store/learned_artifacts.rs`. Append
`responsibility.activated`/`responsibility.superseded` audit rows.
- In `crates/openspine-kernel/src/overlay_compat.rs`, extend the base-update
revalidation to recompute each active responsibility's `composition_fingerprint`
against the current registry. When a pinned component's version/digest changes,
mark the responsibility `needs_review` and exclude it from effective composition
(fail closed), reusing the existing `CompatibilityStatus` idiom.
- Confirm that a workflow update that changes candidate action lists or approval
semantics changes the workflow's content digest, which trips the fingerprint
check and forces a new responsibility review.
- Confirm that a skill update changes only skill content, since skills carry no
authority fields, so the responsibility's reviewed scope/grant stays unaffected.
The skill body change must still trip the fingerprint and surface for owner
awareness wherever the skill is a pinned component.
===============================================================================

Task: 4

Implement Phase 4: wire the active responsibility into grant composition as a
purely-narrowing input, and enforce the remaining adversarial guarantees, while
keeping `compose_authority` and `gate()` unchanged.

- In `crates/openspine-kernel/src/pipeline/driver.rs`, after `resolve_route`
matches a route belonging to a responsibility, resolve the active responsibility
at the existing post-compose/pre-seal seam (the same seam where persona binding
runs).
- Feed responsibility-derived denies/approval-required/candidate-allows through
the existing `AuthorityInput.session: SessionPolicy` narrowing source, or
post-filter the `Granted` grant using the same "intersect, never union"
discipline. The responsibility must never widen authority. Seal the grant
exactly once, after all narrowing is applied.
- In `crates/openspine-schemas/src/grant.rs`, add an optional annotation field
`responsibility_id` to `TaskGrant`, parallel to the existing
`persona_id`/`thread_id` fields. This field must carry no authority and must be
used only for receipt/audit correlation.
- Before applying responsibility scope, verify that the trigger's resolved
principal/account/channel/counterparty match the responsibility's pinned trigger
selector. On any mismatch, do not apply the responsibility, and fail closed to
normal composition.
- In `store/responsibilities.rs`, record the responsibility→standing-rule
association so the responsibility owns the set of standing rules it composes. Do
not add a grouping column inside the `store/standing_rules.rs` enforcement
paths.
- Leave `crates/openspine-kernel/src/standing_rules_gate.rs` and the pure
`openspine-gate::gate()` unchanged. Standing rules remain a post-decision budget
waiver keyed by `action_id`.
- For responsibilities that require net-new component artifacts, sequence the
individual single-artifact atomic activations behind one owner approval whose
digest binds all constituent digests, so a partial activation cannot leave a
route live without its matching authority/controls.
- Reuse the signed-manifest + `OperationStage` rollback FSM pattern from
`crates/openspine-kernel/src/overlay_export_restore/` as the reference
implementation for this staged install, including an explicit rollback branch.
Parameterize the scope to the responsibility, not the whole data root.
===============================================================================

Task: 5

Implement Phase 5: give the owner a single lifecycle surface over the
responsibility, covering pause/resume/revoke/amend controls, a receipt and
exception contract, and a coherent review diff.

- In `store/responsibilities.rs`, add durable states and audited transitions for
`active`, `paused`, and `revoked`. Implement amend as a new monotonic `version`
re-proposal that goes through the Phase 3 propose/activate ceremony — never edit
the record in place — matching the existing standing-rule versioning semantics.
- On revoke, revoke every standing rule owned by the responsibility (reuse the
existing idempotent, audited `revoke_standing_rule`) and deactivate the
responsibility's trigger/route participation. Preserve all historical receipts
and audit rows: revocation deletes reusable shortcuts and triggers, but it must
never delete receipts.
- Expose the pause/resume/revoke/amend controls through the digest-bound
owner-approval callback pattern already used in `pipeline/plan_approval.rs`, so
every control action is authenticated and audited.
- Define an owner-facing responsibility receipt as a bounded, content-addressed
projection, reusing the `TaskSlice`/`ArtifactRef` pattern. Each receipt must
record which matching action fired, under which responsibility and standing-rule
id, its digest, and its outcome. Source the receipt content from the existing
audit trail, not from `TaskGrant` fields.
- Follow the receipt-keyed idempotency rule already used across the kernel: bind
an idempotency key to the request digest, so a replay never re-runs the effect.
- For exceptions, reuse `crates/openspine-schemas/src/escalation.rs`. Route
responsibility-scope denials and boundary escalations through `EscalationEvent`
(adding a new `EscalationPayload` variant if required) and through the
`FailureClass` routing already defined in `failure_surfacing.rs`. Do not create
a separate, parallel notification channel.
- Extend the owner-facing API layer, near
`crates/openspine-kernel/src/api/task.rs`/`api/plan.rs`, with a redacted
responsibility view. The view must show name/purpose, trigger selector,
component references, effective scope, budgets/expiry, current lifecycle state,
and recent receipts. It must not expose internal artifact-management surfaces.
- For review and amend, render one coherent diff. The diff must show the changed
job, the reason for the change (miner provenance or owner delegation), and the
authority delta between the prior and proposed composition. Use the WYSIWYS
digest-bound rendering pattern already used in `PlanApprovalQuestion`, so the
rendered text and the approved digest can never diverge.
===============================================================================

Task: 6

Implement Phase 6: extend the reflection miner to propose new reviewed
responsibility versions, and prove the full responsibility path end to end with
adversarial tests.

- In `crates/openspine-schemas/src/reflection_miner.rs`, add a
`ResponsibilityCandidate` proposal variant to the pure `ReflectionMiner`.
Hard-code `lifecycle_state = Proposed`. Reuse the existing kernel-counted
repeated-approval evidence and provenance-binding guards.
- In `crates/openspine-schemas/src/reflection_miner_payload.rs`, serialize the
candidate to the `{kind: responsibility, yaml}` payload format.
- Dispatch the payload through the unchanged `dispatch_reflection_proposal` path
in `crates/openspine-kernel/src/reflection_miner_runtime.rs`, so activation
still requires explicit owner approval via the Phase 3 propose/activate
ceremony.
- Preserve the miner's structural inability to hold mutation authority: the
miner must propose new versions only, and must never widen authority.
- Implement one starter responsibility end to end — for example, a reviewed
inbound communication routine for one relationship/workspace — that composes a
route/trigger, workflow, skills, pack/policy, and standing rules, and that
returns receipts with escalation only at disclosure/effect boundaries.
- Add integration tests that exercise the adversarial requirements: a component
change forces re-review; a skill update does not change authority; a trigger
with a different counterparty is not admitted; a mid-activation failure rolls
back with no route left live without authority; export/restore preserves or
re-confirms the composition.
- Run the openspec ceremony: run `./scripts/check.sh`, complete a reviewer pass,
then run `openspec archive` and `openspec validate --all --strict`.

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!

[coderabbitai]

🔗 Related PRs

#19 - Implement implement-artifact-lifecycle-slice: propose/approve/activate (PR-5) [merged]
#95 - feat(kernel): standing rules (AD-010/106/013/012, D-107) [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[George-RD]

Roadmap review note (2026-08-06): external AutoGPT-platform comparison, folded into this issue

We evaluated a detailed external comparison of AutoGPT's current platform (typed-block graphs, AutoPilot NL authoring, validate/repair, dry-run simulator, marketplace) against OpenSpine. Full text archived at .raw/openspine-autogpt-comparison-2026-08-06.md; verdict recorded as D-150..D-152 in .raw/openspine-decision-log.md. What it changes here:

1. Authoring-surface framing (D-151). The "Architecture decision" above (ResponsibilityManifest vs atomic reviewed bundle) stays open exactly as written, but whichever durable form wins is a compiler input: Lyra and the owner author a typed, non-authoritative composition; routes/workflows/packs/standing rules are its compiler target, never the surface anyone authors directly. AutoGPT is working evidence that model-assembled typed-brick composition is feasible at product quality — and equally that the composition object must not itself be authority (their blocks execute inside the credential boundary with review default-off; our composition must resolve every effectful node to a D-146 action descriptor + implementation descriptor and execute only under a per-run task grant through gate()).

2. Capability author ≠ evidence miner (D-152). Stage 3 ("capability growth") gets two proposal sources with one shared boundary. The deterministic reflection miner derives candidates from kernel-counted repeated approvals (D-130..D-141). A future capability-author agent may run the AutoPilot-shaped loop — find existing capability → discover bricks → compose → validate → simulate → propose — under an ordinary bounded task grant with zero activation authority. Neither role can mint a privileged brick: connectors, resolvers, and executors remain developer-landed kernel code (AutoGPT's own LLM-writes-a-block installer ships disabled because it is RCE on the backend — the same boundary, confirmed independently).

3. Builder dry-run is authoring UX, never an activation gate. A validate/repair/simulate loop is worth reproducing for composition velocity, but activation evidence remains #133's proposal-specific structural judge + replay bound to the exact proposal digest, followed by digest-bound owner approval. Their simulator deliberately tolerates schema-conformance failures — fine for iteration, meaningless as proof.

4. Preferred post-Gmail proof shape. Of the two examples in "End-to-end proof after Gmail", prefer the second, in a concrete zero-new-connector-authority shape: kernel timer (D-074 substrate) → read-only research/summary workflow → owner receipt. It exercises trigger/workflow/scope/receipt composition end to end with no new effect surface, and the trigger/headless contract in the comment above remains the separately reviewed gate for the timer boundary.

Rejected:

• Replacing or forking the platform (D-150): trust-model inversion (block code inside the credential boundary; is_sensitive_action and graph safe-mode both default false) plus the PolyForm Shield noncompete. Stance is study-and-independently-reproduce; autogpt_platform never becomes a dependency or fork base.
• Pulling a composition-IR track forward of the delegation proofs: the HARD edge on ship-recurring-gmail-draft-proof stands. Composing over unproven executors is Unify approved and delegated effect execution; fail closed on missing executors #127's false-success bug at bundle scale.

Worth studying when this issue starts: their graph JSON model (versioned identity, typed links, graph-level input/output schemas, sub-graphs), the block schema fields, and the agent-generation guide's build loop. The "secure brick" field list from the assessment (canonical action, effect kind, reversibility, kernel-owned resolver, reviewed-scope dimensions, idempotency/delivery-unknown semantics, budget bounds, credential handle never bytes, evaluation fixtures, compatibility version) is already descriptor-axis material owned by openspec/specs/responsibility-contract/spec.md — it is confirmation, not a new object.

[George-RD]

Restructured into the cohesive roadmap (map #182); original preserved below.