Ship protocol-neutral progressive delegation so Lyra grows through real work

[George-RD]

What to build

OpenSpine must prove progressive delegation is portable: Lyra learns a capability on one channel (email) and exports the grant; a different product (Bell) consumes it on a different channel (WhatsApp) and executes it without privilege escalation. Ship the neutral protocol.

Acceptance criteria

1. Implement channel-agnostic delegation grant format. 2. Write tests proving: Lyra export on Email → Bell import on WhatsApp with no authority upgrade. 3. Document the protocol invariants.

Blocked by

Bell fit review decision (post-fit-review)

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

Original report

North star

OpenSpine is not a safer Gmail drafting tool. It is the governed system underneath an employee-like personal AI whose capability and autonomy grow as the owner delegates real work.

The user experience should feel like onboarding and managing a strong employee:

1. delegate one clear job;
2. let Lyra do internal work freely inside the task boundary;
3. ask only at a real effect or disclosure boundary;
4. review the result and any exception;
5. turn repeated decisions into a clear proposal for reusable responsibility;
6. approve, narrow, reject, pause, resume, expire, or revoke it;
7. require less interruption on future matching work while every task still receives a bounded grant;
8. return changed context, drift, policy conflict, or exhausted budget for review rather than silently widening.

The core product sentence remains:

Lyra can learn the job. Learning does not become permission by itself.

Adversarial architecture correction

Recurring Gmail draft creation remains the right smallest useful proof. It is not the architecture. A deep review found these decomposition and safety gaps in the current substrate and the superseded renderer PR:

1. A standing rule is not the whole responsibility. It is an action-level reusable-approval/composition input. A user-facing responsibility also includes the job/workflow, reviewed scope, limits, exceptions, receipts, and controls.
2. Live standing-rule matching is action-only. Connector implementation/instance, account, target, counterparty, and task shape are not part of the rule match.
3. Only one active rule effectively survives per action. Activation revokes other active rules sharing the action, so separate responsibilities for different accounts or relationships cannot coexist safely.
4. Miner evidence is the wrong equivalence class. The owner-approval audit supplies only the payload ref, not the approved target; the scheduled miner groups (payload_digest, action_id). Identical text for different targets can group, while normal repeated work with different text will not.
5. The reusable Gmail effect is not executable. email.create_draft runs through a special post-approval path and is deliberately absent from the ordinary handler registry. Standing-rule admission can reach a successful missing-handler stub, finalize budget, and create no draft.
6. Owner review is channel-coupled. Telegram text/buttons and raw integer chat IDs are being treated as the review/destination model rather than one adapter over a principal-bound owner surface.
7. Action meaning/delegatability is ad hoc. Owner labels are guessed in renderer code; there is no catalog-owned declaration that an action implementation has a real executor/resolver, safe reviewed-scope requirements, risk-tiered limits, destination semantics, or reusable-delegation support.
8. Connector writes are under-classified. email.create_draft writes content to an external owner account but is classified as neither a rated egress endpoint nor an output channel. Draft, direct send, workspace post, and public publish need distinct effect/destination semantics.
9. Proposal evaluation is not proposal-specific enough. Non-model replay currently proves owner-control history exists rather than replaying the exact proposal; the standing-rule judge chiefly proves that the action ID exists.
10. Proposal copy can outrun evidence. A manual proposal can be described as a repeated pattern, and activation can become stale relative to policy, descriptor/executor, connector/account, identity, or base state.
11. Generic request construction is not a trusted scope source. Generic mediation stores a shell payload, extracts string parameters, and leaves target refs/digests empty; AD-036/AD-120 require the kernel to resolve identity- and scope-bearing fields.
12. Headless autonomy is intentionally absent. The current headless lane refuses standing-rule downgrade. That is safe, but whole unattended responsibilities need a separately reviewed trigger/headless contract rather than removal of the guard.
13. Dark-window Allow can amplify authority. Pending actions are deduplicated only by request fingerprint, with no per-rule outstanding cap. Many distinct over-budget requests can queue many silence-based waivers.
14. The capability map conflates capability and proof. Progressive delegation is the capability. Recurring Gmail draft creation is the first vertical proof. A second protocol is separate portability evidence, and a whole responsibility is a later maturity stage.

These are decomposition gaps under the change-sequence rule. They must be specified explicitly rather than hidden inside local Gmail copy or handler patches.

Product and runtime vocabulary

Standing rule

A versioned, reviewed, budgeted, expiring reusable-approval/authority-composition input that can smooth one effect boundary. It never replaces the task grant and is never a second live authority object. #126 must reconcile this wording with AD-010 and the actual common mediation path.

Responsibility

The owner-facing unit of delegation: the job, workflow, exact scope, reusable effects, remaining boundaries, limits, exception behavior, receipts, provenance, and lifecycle controls.

The first proof may render a responsibility view over an existing workflow plus one scoped standing rule. Long-term responsibility composition is tracked separately so OpenSpine does not stop at an approval shortcut.

Progressive delegation

The generic lifecycle by which repeated, kernel-verifiable owner decisions can become a proposed, evaluated, reviewed, scoped, executable, reversible responsibility. It is protocol-neutral.

Invariants

• The task grant remains the only live authority object and the upper bound for every task.
• The shell sends intents; the kernel resolves trusted connector/account/target/counterparty context and effect identity.
• Identity is not authority.
• Preference/persona learning is separate from permission growth.
• A model, miner, workflow, skill, package, or connector cannot approve or activate its own authority.
• Only distinct principal-authenticated owner decisions may count as repeated-approval evidence. Standing-rule auto-allows, dark-window defaults, worker/model/workflow allows, receipts, and audit replay never recursively increase that evidence.
• Reusable authority requires a real executor, complete action and implementation descriptors, kernel resolver, reviewed scope, coherent evidence set, and current proposal-specific evaluation.
• Missing executor, resolver, descriptor, policy compatibility, evaluation, or scope fails closed before owner review or budget use.
• Scope mismatch or ambiguous overlapping rules happen before quota/rate reservation and before dark-window scheduling.
• Multiple disjoint scoped responsibilities for one canonical action may coexist; their budgets and authority are never pooled.
• Per-instance approval and delegated admission converge on the same kernel-owned effect executor and immutable request semantics.
• Owner channels render one canonical review object and submit typed principal-bound decisions; they do not define lifecycle or authority semantics.
• A connector write has an explicit effect kind and data destination/visibility even when it is reversible or not yet delivered to a counterparty.
• Silence never creates more authority than an explicitly reviewed, bounded exception allowance.
• Headless/inbound/scheduled reuse requires an explicitly reviewed trigger contract; ordinary standing rules do not make arbitrary headless work self-approving.
• No documentation calls progressive delegation shipped until a real effect completes through the reusable path and all fallback/control paths pass.

Roadmap and dependencies

Phase 0 — Resolve the invalid renderer slice

• PR Superseded: prototype responsibility proposal copy #125 closed as superseded.

The branch remains available for selective reuse of tests and validation hardening. Its renderer/action-string design must not be revived wholesale because it inferred evidence, scope, execution readiness, evaluation, and Telegram review semantics from insufficient inputs.

Phase 1 — Define the protocol-neutral contract

• Define the protocol-neutral responsibility contract above standing rules #126

Settle the distinction between responsibility and standing rule and define:

• canonical action descriptors versus connector-specific action implementations;
• executor/resolver readiness and safe action semantic granularity;
• effect kind, reversibility, destination/visibility, egress/output classifications, and risk-tiered limits;
• kernel-resolved action context;
• reviewed action scope;
• delegation evidence and evidence-set identity;
• typed owner surfaces and a channel-neutral owner review object;
• compatibility/schema versions and dark-window eligibility.

Add the necessary AD/D decisions and OpenSpec/change-sequence dependencies before behavior changes.

Phase 1B — Correct the checked roadmap model

• Separate generic capability, selected proof, and portability evidence in the checked roadmap #134

After #126 settles vocabulary, separate the generic capability, selected Gmail proof, portability evidence, and whole-responsibility maturity in the checked capability-map schema and generated roadmap. This slice may land before runtime implementation while the capability remains product_surface_missing.

Phase 2A — Build independent foundations after the contract

• Unify approved and delegated effect execution; fail closed on missing executors #127 — one execution-backed effect path for per-instance and delegated admission; no successful missing-handler stubs.
• Add channel-neutral responsibility review and lifecycle controls #129 — typed owner surfaces, channel-neutral review, Approve/Reject/Narrow/Pause/Resume/Revoke, and concise receipts.

These may proceed in parallel after #126 if their boundaries remain cohesive.

Phase 2B — Build scoped evidence and deterministic matching

• Mine and match reusable authority by kernel-resolved scope #128

Requires #126 and #127. Bind owner evidence to approved payload and target plus complete kernel-resolved context; support multiple disjoint scoped rules per action; fail closed on overlap; match before budget/defaults; invalidate on policy/descriptor/executor/connector/account/identity/workflow drift.

Phase 2C — Bound silence-based exceptions

• Bound dark-window exceptions so silence cannot amplify standing-rule authority #135

The immediate fail-closed restriction on communication/connector-write Allow defaults may land early. Full bounded pending-exception semantics use #126/#128 context and must prevent many distinct requests from queuing unbounded quota waivers or owner notifications.

Phase 2D — Make evaluation real

• Make reusable-authority evaluation proposal-specific and evidence-backed #133

Requires #126 and the context/evidence contracts from #128. Structurally judge and actually replay/simulate the exact proposal against its evidence and adversarial changed-context, overlap, executor, destination, and dark-window cases. Store verdicts bound to proposal and runtime compatibility epochs. Owner copy may state only what these verdicts prove.

Phase 3 — Ship the first complete proof

• Ship recurring Gmail drafts as the first complete delegation proof #130

Requires #126, #127, #128, #129, and #133. It must use no dark-window Allow unless #135 has completed and the action descriptor explicitly permits the bounded exception policy.

Use the existing selected-thread Gmail workflow as the vertical proof. The positive path must create a real Gmail draft through the same executor used by exact approval. Changed connector/account/target/counterparty, ambiguous overlap, stale evaluation, budget, pause, expiry, drift, policy change, or revocation must fall back before effect.

Only then may the checked capability map move generic progressive delegation to Wired into Lyra. The map must keep the first Gmail proof separate from protocol portability and whole-responsibility maturity.

Phase 4 — Prove the architecture is not secretly Gmail

• Prove progressive delegation is portable across communication protocols #131

After #130, exercise a second materially different communication shape through the same contracts and #133 evaluator. A deterministic test connector is acceptable before a real product connector. Curated built-ins remain acceptable; this phase does not require an untrusted plugin marketplace.

Phase 5 — Grow from effect shortcuts into whole responsibilities

• Compose whole responsibilities from workflows, triggers, authority, and exception policy #132

Compose reviewed triggers/routes, workflows, skills, scope, authority, budgets, exception policy, results, and controls into one atomic owner-facing responsibility lifecycle. Preserve the current headless refusal until a reviewed trigger/headless proof replaces it. This is the step from “do not ask me for this one effect again” to “own this job and bring me receipts/exceptions.”

Relationship to existing product work

#118 — first-run trust loop

This is a parallel product track. A user needs to reach the first bounded task easily before they can experience longitudinal delegation. #118 should consume the owner-review/receipt vocabulary once #126/#129 settle it, but setup polish is not a runtime prerequisite for #127/#128.

The product milestone should converge as:

first-run task (#118)
        +
reusable delegation proof (#130)
        =
first credible OpenSpine experience

#117 — installable assistant system

The package store and install/use/run model remain important, but they should not block proving the defining delegation loop. Package installation/selection cannot declare connector/action trust or install reusable authority outside the normal reviewed lifecycle.

Capability-map truth model

#134 must represent:

• Capability: protocol-neutral progressive delegation / reviewed reusable responsibility.
• State today: product surface missing; standing-rule, miner, lifecycle, budget, and artifact substrate have landed but the complete scoped executable/evaluated loop has not.
• Architecture contract: Define the protocol-neutral responsibility contract above standing rules #126.
• Execution/review foundations: Unify approved and delegated effect execution; fail closed on missing executors #127 and Add channel-neutral responsibility review and lifecycle controls #129.
• Scoped evidence/matching: Mine and match reusable authority by kernel-resolved scope #128.
• Bounded exception hardening: Bound dark-window exceptions so silence cannot amplify standing-rule authority #135.
• Proposal-specific evaluation: Make reusable-authority evaluation proposal-specific and evidence-backed #133.
• Selected proof: Ship recurring Gmail drafts as the first complete delegation proof #130, recurring Gmail draft for one reviewed connector/account/relationship scope.
• Portability proof: Prove progressive delegation is portable across communication protocols #131.
• Whole-responsibility progression: Compose whole responsibilities from workflows, triggers, authority, and exception policy #132.

Open issues are blockers/plans, not repository proof. Archived changes, real artifact paths, and named owner-path tests remain required before status advances.

Dark-window posture

AD-012 remains marked leaning. The first external-communication proof should not use a dark-window Allow default unless #126 explicitly permits it for the effect/destination class, #128 resolves scope before scheduling, #135 bounds outstanding exceptions and notifications, and #133 evaluates the exact behavior. A generic disclosure of the timeout is not enough.

Done when

First complete loop

• one owner-facing workflow demonstrates first task → repeated exact approvals → evidence-backed scoped proposal → proposal-specific evaluation → review → activation → real matching effect with less interruption → concise receipt;
• changed scope, ambiguous overlap, stale compatibility/evaluation, budget saturation, pause, expiry, drift, policy conflict, and revocation all restore review/denial before effect;
• the owner never needs to understand task grants, standing rules, artifact lifecycle, or YAML.

Architecture

• the generic engine contains no Gmail/Slack/WhatsApp/Outlook-specific matching or lifecycle branches;
• every delegatable action implementation has reviewed descriptor, resolver, executor, scope, evidence, destination, limit, and evaluation contracts;
• per-instance approval and reusable authority use the same executor;
• the miner cannot aggregate different required targets/scopes or automatic allows into one owner pattern;
• multiple disjoint rules for one action coexist without budget pooling, while overlaps fail closed;
• dark-window exceptions and notifications are atomically bounded;
• owner review works through at least Telegram and terminal using a typed owner surface;
• a second communication shape passes the conformance suite without changing generic lifecycle/evaluation code.

Product truth

• README, website, roadmap, and capability map distinguish the employee-like promise, landed runtime machinery, first Gmail proof, wider protocol status, and whole-responsibility maturity;
• a standing-rule row, proposal message, generic corpus check, successful stub, or open issue is never counted as shipped autonomy;
• no learned preference, correction, repeated approval, model suggestion, workflow update, skill/package update, connector change, evaluation staleness, or silence queue can silently widen authority.

Execution discipline

• The open PR queue is clear: Superseded: prototype responsibility proposal copy #125 is closed as superseded. The next code/spec PR starts with Define the protocol-neutral responsibility contract above standing rules #126.
• Use TDD for every behavioral slice. Characterize the current stub-success, payload-only evidence, action-only matching, single-rule-per-action, unbounded pending-default, and non-proposal-specific evaluation failures before implementation.
• Use OpenSpec and the change sequence for architecture/spec work; do not scope-stretch a running change.
• Merge only cohesive, independently reviewable slices with the full repository gate green and review threads resolved.

[coderabbitai]

Coding Plan

Summary

• Reuse the existing email-draft effect boundary and the existing reflection miner so repeated owner approvals produce a budgeted, expiring standing-rule proposal through the normal artifact lifecycle.
• Add a plain-language proposal view and Approve/Reject/Pause/Resume/Revoke controls on Telegram so the owner never reads task grant, artifact lifecycle, or standing rule to decide correctly.
• Extend standing rules with an owner-controlled paused state and a reviewed scope predicate so a changed target, exhausted budget, drift, or expiry falls back to approval instead of silent widening.
• Align README, website, roadmap, and a new capability map to separate the employee-like promise, the landed runtime machinery, and the one shipped owner loop, and prove every transition with owner-path tests.

Design Choices

Design Choice 1: Owner-reachable workflow to demonstrate the complete loop

Options Considered:

1. Extend task_board_scheduled to add an effect boundary and an approval step, then drive repeated approvals from it.
2. Reuse selected_thread_email_reply_draft, whose email.create_draft approval is already owner-gated and already visible to the reflection miner audit slice.

Chosen Option: 2

Rationale: The ticket defers the exact choice to the #119 capability map but requires one end-to-end demonstration. The email-draft loop already provides a real, digest-bound effect boundary and repeated-approval audit rows, so it demonstrates the full loop with the least new approval plumbing and stays useful in its own right.

Design Choice 2: How the owner narrows or edits a proposed responsibility

Options Considered:

1. Add inline editing that mutates the proposed YAML before activation.
2. Offer Approve and Reject on the proposal; treat "narrow/edit" as reject-and-re-propose with adjusted defaults.

Chosen Option: 2

Rationale: Product goal 6 lists narrow and edit, but activation must re-parse the exact proposed bytes, so an inline edit-then-approve path would break digest-bound activation. Option 2 preserves the digest-bound activation invariant and keeps the shipped controls to the ones the "Done when" tests require (activation, pause, revoke), while leaving inline editing as clearly-scoped follow-up.

Design Choice 3: How a changed target falls back to approval

Options Considered:

1. Reuse the authority-equivalence matcher for "similar task" reuse.
2. Add an explicit, reviewed scope predicate to StandingRuleManifest and match it in consult_standing_rule_gate.

Chosen Option: 2

Rationale: Standing rules today match by exact ActionId only, so a changed thread/account would still reuse the rule silently. The ticket requires a changed target to send the responsibility back for review. The equivalence matcher is deliberately scoped to byte-identical composed authority and must not carry fuzzy judgment; a reviewed scope field keeps the widening explicit, versioned, and owner-approved.

💡 User Tips

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

Implementation Steps

Phase 1: Wire the delegation loop end to end

This phase makes one existing owner-reachable task produce a plain, budgeted standing-rule proposal after repeated approvals, and makes that rule reduce interruption on the next matching task. No worker gains any mutation or activation path. The miner keeps proposing only; the owner keeps activating.

Task 1: Confirm and wire repeated-approval capture for the demonstration action

Ensure the demonstration action produces repeated-approval audit rows that the miner can observe.

• Verify that email.create_draft owner approvals are written as Allow-decision, owner-approval-gated audit rows that Store::load_owner_miner_audit_slice includes.
• In reflection_miner_runtime/scheduled.rs, confirm reflection_miner_tick derives a RepeatedApproval observation when the dominant (artifact_id, action_id) pair reaches at least two entries for the demonstration action.
• Do not change the miner authority boundary. It must stay an OrdinaryMinerGrant with no output channels and no direct-mutation actions.

Task 2: Ensure the proposed standing rule carries meaningful budgets and expiry

Make the miner-proposed rule match the demonstration action and carry sane defaults.

• In reflection_miner_payload.rs, keep the StandingRuleCandidate to StandingRuleManifest serialization using the observed action_id (never a hardcoded action).
• Set default quota, rate, and expires_after_secs that are conservative and readable in plain language.
• Preserve the existing rule that prohibition-shaped instructions never become authority artifacts.

Task 3: Confirm gate-time reuse and concise receipts

Make the next matching task complete with less interruption and report a short receipt.

• Confirm consult_standing_rule_gate (called from api/actions.rs::mediate_and_dispatch_action) flips ApprovalRequired to Allow for the demonstration action within budget after activation.
• In the demonstration effect handler (pipeline/approval_draft.rs for the email draft), emit a concise receipt after a successful auto-allowed task. The receipt states what happened and the remaining budget window. It does not repeat the full permission model.

🤖 Prompt for AI agents

Implement the end-to-end delegation loop using the existing email-draft workflow
as the demonstration action. The goal is that repeated owner approvals of
`email.create_draft` produce a budgeted, expiring standing-rule proposal, and
that an activated rule reduces interruption on the next matching task, all
without any worker gaining a mutation or activation path.

First, confirm the audit and observation plumbing:
- Verify `email.create_draft` owner approvals are written as `Allow`-decision,
owner-approval-gated audit rows included in
`Store::load_owner_miner_audit_slice`.
- In `reflection_miner_runtime/scheduled.rs`, confirm `reflection_miner_tick`
derives a `RepeatedApproval` observation once the dominant `(artifact_id,
action_id)` pair reaches at least two entries for this action.
- Do not alter the miner authority boundary: it must remain an
`OrdinaryMinerGrant` with no output channels and no direct-mutation actions.

Next, ensure the proposed rule is meaningful:
- In `reflection_miner_payload.rs`, keep the `StandingRuleCandidate` to
`StandingRuleManifest` serialization tied to the observed `action_id`, never a
hardcoded action.
- Set conservative, plain-language-readable default quota, rate, and
`expires_after_secs` values.
- Preserve the existing rule that prohibition-shaped instructions never become
authority artifacts.

Finally, confirm reuse and receipts:
- Confirm `consult_standing_rule_gate` (invoked from
`api/actions.rs::mediate_and_dispatch_action`) flips `ApprovalRequired` to
`Allow` for the demonstration action within budget after activation.
- In `pipeline/approval_draft.rs`, emit a concise receipt after a successful
auto-allowed task, stating what happened and the remaining budget window,
without repeating the full permission model.

Phase 2: Plain-language proposal and owner control surface

This phase replaces the terse proposal message for standing-rule proposals with an ordinary-language view and adds the owner controls the loop needs. The owner never has to read task grant, artifact lifecycle, or standing rule.

Task 1: Render the standing-rule proposal in ordinary language

Give the owner a clear description of the proposed responsibility that maps deterministically to the versioned artifact.

• Add a plain-language renderer, in a new module under crates/openspine-kernel/src/pipeline/ (for example delegation_proposal.rs), that takes the parsed StandingRuleManifest and its provenance audit row (reflection.miner.provenance) and produces owner-facing text.
• The text states: what Lyra noticed; what would happen automatically next time; which accounts, objects, actions, budgets, and time windows are covered; what stays blocked or approval-required; how to pause or revoke.
• In api/artifact_propose.rs, when kind == "standing_rule", send this rendered text instead of the terse kind/id/version/digest summary. Keep the digest binding unchanged; only the visible framing changes.
• Keep persona and preference proposals on their existing, separate framing so preference learning stays visibly distinct from authority growth.

Task 2: Add Approve and Reject controls on the proposal

Let the owner accept or decline the proposal without editing YAML.

• Keep the existing digest-bound Approve button (activation stays unchanged in pipeline/approval.rs and pipeline/post_approval.rs).
• Add a Reject control. Add a reject callback in pipeline/approval.rs that consumes the ActionRequest, records an audit event, and confirms to the owner that nothing was activated. A rejected or never-tapped proposal must not affect any gate decision.
• Extend the Telegram connector send path (connectors used by send_reply_with_approval_button) to attach more than one inline button where needed.

Task 3: Add Pause, Resume, and Revoke controls for an active responsibility

Give the owner post-activation controls in ordinary language.

• Add owner-facing Pause, Resume, and Revoke controls that map to the standing-rule actions added in Phase 3.
• Wire the corresponding callbacks in pipeline/approval.rs (or a sibling handler) to dispatch pause_standing_rule, resume_standing_rule, and the existing revoke_standing_rule through the normal gated action surface.
• After each control action, send a short confirmation that states the new state and its effect (for example, "Paused. The next matching task will ask for approval.").

🤖 Prompt for AI agents

Replace the terse standing-rule proposal message with an ordinary-language view
and add the owner controls needed for the full loop. The owner must never need
to read `task grant`, `artifact lifecycle`, or `standing rule` to decide
correctly.

Rendering:
- Add a new module under `crates/openspine-kernel/src/pipeline/` (for example
`delegation_proposal.rs`) that renders a plain-language view from the parsed
`StandingRuleManifest` and its provenance audit row
(`reflection.miner.provenance`).
- The rendered text must state: what Lyra noticed; what would happen
automatically next time; which accounts, objects, actions, budgets, and time
windows are covered; what stays blocked or approval-required; how to pause or
revoke.
- In `api/artifact_propose.rs`, when `kind == "standing_rule"`, send this
rendered text instead of the terse `kind/id/version/digest` summary. Keep the
digest binding unchanged; only change the visible framing.
- Keep persona and preference proposals on their existing, separate framing so
preference learning stays visibly distinct from authority growth.

Approve/Reject controls:
- Keep the existing digest-bound Approve button and unchanged activation path in
`pipeline/approval.rs` and `pipeline/post_approval.rs`.
- Add a Reject callback in `pipeline/approval.rs` that consumes the
`ActionRequest`, records an audit event, and confirms to the owner that nothing
was activated. A rejected or never-tapped proposal must never affect any gate
decision.
- Extend the Telegram connector send path (`connectors`, used by
`send_reply_with_approval_button`) to support attaching more than one inline
button where needed.

Pause/Resume/Revoke controls:
- Add owner-facing Pause, Resume, and Revoke controls mapped to the
standing-rule actions added in Phase 3.
- Wire callbacks in `pipeline/approval.rs` (or a sibling handler) to dispatch
`pause_standing_rule`, `resume_standing_rule`, and the existing
`revoke_standing_rule` through the normal gated action surface.
- After each control action, send a short confirmation stating the new state and
its effect (for example, "Paused. The next matching task will ask for
approval.").

Phase 3: Standing-rule lifecycle extensions

This phase adds the pause/resume state and the reviewed scope predicate needed for "changed target falls back to approval," while keeping the task grant the sole live authority object.

Task 1: Add pause and resume to the standing-rule state machine

Add an owner-controlled paused state distinct from system-triggered needs_review.

• In store/standing_rules.rs, add a paused status and transitions active -> paused and paused -> active, plus store methods pause_standing_rule and resume_standing_rule (idempotent, audited, matching the existing revoke_standing_rule pattern).
• In standing_rules_gate.rs and store/standing_rules_budget.rs, treat paused like non-active for consultation, so a paused rule never flips ApprovalRequired to Allow.
• Register pause_standing_rule and resume_standing_rule in api/handler_registry.rs and action_catalog_data.rs.

Task 2: Add a reviewed scope predicate and changed-target fallback

Let a rule cover a specific account or object and fall back to approval when the target changes.

• In crates/openspine-schemas/src/standing_rule.rs, add an optional scope predicate to StandingRuleManifest (for example an account or target selector), with positive-value validation and deny_unknown_fields preserved.
• In consult_standing_rule_gate, match the pending action's bound parameters against the scope predicate. If the target does not match the scope, do not reuse the rule; let ApprovalRequired stand so the owner reviews the new target.
• Reflect the scope in the plain-language renderer from Task 2.1 (the "which accounts, objects" line).
• Keep the existing budget, rate, expiry-to-needs_review, and drift-to-needs_review fallbacks unchanged.

🤖 Prompt for AI agents

Extend the standing-rule lifecycle with an owner-controlled paused state and a
reviewed scope predicate, while keeping the task grant the sole live authority
object.

Pause/resume state machine:
- In `store/standing_rules.rs`, add a `paused` status and transitions `active ->
paused` and `paused -> active`.
- Add store methods `pause_standing_rule` and `resume_standing_rule`, idempotent
and audited, matching the existing `revoke_standing_rule` pattern.
- In `standing_rules_gate.rs` and `store/standing_rules_budget.rs`, treat
`paused` like non-active for consultation so a paused rule never flips
`ApprovalRequired` to `Allow`.
- Register `pause_standing_rule` and `resume_standing_rule` in
`api/handler_registry.rs` and `action_catalog_data.rs`.

Reviewed scope predicate and changed-target fallback:
- In `crates/openspine-schemas/src/standing_rule.rs`, add an optional scope
predicate to `StandingRuleManifest` (for example an account or target selector),
with positive-value validation and `deny_unknown_fields` preserved.
- In `consult_standing_rule_gate`, match the pending action's bound parameters
against the scope predicate. If the target does not match the scope, do not
reuse the rule; leave `ApprovalRequired` in place so the owner reviews the new
target.
- Reflect the scope in the plain-language renderer from Phase 2 (the "which
accounts, objects" line).
- Keep the existing budget, rate, expiry-to-`needs_review`, and
drift-to-`needs_review` fallbacks unchanged.

Phase 4: Product narrative and capability map

This phase makes the docs truthful about what is promised, what runtime machinery has landed, and what owner loop actually ships. It also adds the capability map required by the ticket.

Task 1: Update the product promise and shipped-loop narrative

Distinguish the employee-like promise, the landed runtime, and the shipped owner loop across the primary docs.

• Update README.md, docs/lyra.md, and artifacts/lyra/README.md, ARCHITECTURE.md, CHANGELOG.md, and PERSONA.md to describe the shipped delegation loop and to add a caveat that standing rules, the reflection miner, and preference overlays are landed runtime machinery now proven through one owner loop, not yet through every capability.
• Keep the wording consistent with site/src/content/docs/roadmap.md, comparison.md, and why-openspine.md; update those pages to reference the newly shipped loop.

Task 2: Add the generated capability map

Provide one capability map that labels each capability and gates the "wired into Lyra" label on an owner-path test.

• Add a structured capability map data file and a small generator that renders it into the site, under site/src/content/docs/ (for example a capability-map page plus a data source).
• Label each capability as runtime, wired into Lyra, or planned product surface.
• Require an owner-path test reference before any capability is labeled wired into Lyra.
• If this package ships as part of Lyra, register any new route/workflow/pack artifact in artifacts/lyra/package.yaml and reconcile it with the memory and authority conventions there.

🤖 Prompt for AI agents

Update the product narrative and add a capability map so the docs are truthful
about what is promised, what runtime machinery has landed, and what owner loop
actually ships.

Narrative updates:
- Update `README.md`, `docs/lyra.md`, `artifacts/lyra/README.md`,
`artifacts/lyra/ARCHITECTURE.md`, `artifacts/lyra/CHANGELOG.md`, and
`artifacts/lyra/PERSONA.md` to describe the shipped delegation loop.
- Add a caveat in these docs that standing rules, the reflection miner, and
preference overlays are landed runtime machinery, now proven through one owner
loop, not yet through every capability.
- Keep the wording consistent with `site/src/content/docs/roadmap.md`,
`comparison.md`, and `why-openspine.md`; update these pages to reference the
newly shipped loop.

Capability map:
- Add a structured capability map data file and a small generator that renders
it into the site, under `site/src/content/docs/` (for example a `capability-map`
page plus a data source).
- Label each capability as `runtime`, `wired into Lyra`, or `planned product
surface`.
- Require an owner-path test reference before any capability can be labeled
`wired into Lyra`.
- If this package ships as part of Lyra, register any new route/workflow/pack
artifact in `artifacts/lyra/package.yaml` and reconcile it with the memory and
authority conventions there.

Phase 5: Owner-path tests and no-silent-widening guarantees

This phase adds the tests the "Done when" criteria require and proves that learning never becomes permission by itself.

Task 1: Add owner-path tests for the full loop

Cover each transition of the shipped loop from the owner's point of view.

• Add tests for activation, matching reuse (next matching task auto-allowed within budget), budget-saturation fallback, drift fallback, pause and resume, expiry fallback, and revocation. Extend store/standing_rule_mediation_tests.rs, store/standing_rule_scheduling_tests.rs, and the reflection miner runtime tests.
• Add a test for changed-target fallback using the scope predicate from Task 3.2.
• Add a test that a paused or revoked rule causes the next matching task to ask for approval.

Task 2: Add no-silent-widening tests

Prove that no learned preference, correction, repeated approval, or model suggestion widens authority without an owner tap.

• Add a test that a proposed but not-activated standing rule never changes a gate decision.
• Add a test that a persona or preference proposal never changes any allowed_actions, approval_required_actions, or denied_actions (preference learning stays separate from authority growth).
• Add a test that the miner cannot dispatch standing_rule.*, policy.*, artifact.activate, or artifact.nominate_upstream.

🤖 Prompt for AI agents

Add the tests required by the "Done when" criteria and prove that learning never
becomes permission by itself.

Owner-path tests for the full loop:
- Cover activation, matching reuse (next matching task auto-allowed within
budget), budget-saturation fallback, drift fallback, pause and resume, expiry
fallback, and revocation. Extend `store/standing_rule_mediation_tests.rs`,
`store/standing_rule_scheduling_tests.rs`, and the reflection miner runtime
tests.
- Add a test for changed-target fallback using the scope predicate added in
Phase 3.
- Add a test that a paused or revoked rule causes the next matching task to ask
for approval.

No-silent-widening tests:
- Add a test that a proposed but not-activated standing rule never changes a
gate decision.
- Add a test that a persona or preference proposal never changes any
`allowed_actions`, `approval_required_actions`, or `denied_actions`, keeping
preference learning separate from authority growth.
- Add a test that the miner cannot dispatch `standing_rule.*`, `policy.*`,
`artifact.activate`, or `artifact.nominate_upstream`.

Research

OpenSpine is a Rust workspace. The openspine-kernel crate holds the request pipeline (pipeline/), HTTP/action surface (api/), persistence (store/), the standing-rule engine (store/standing_rules*.rs, standing_rules_gate.rs, pipeline/standing_rule_timer.rs), and the reflection miner runtime (reflection_miner_runtime.rs, reflection_miner_runtime/scheduled.rs). The openspine-authority crate composes route + policy + pack + workflow into a single TaskGrant at mint time. openspine-gate holds the pure gate() decision. openspine-schemas holds the artifact schemas (artifact.rs, standing_rule.rs, persona.rs, skill.rs). The default Lyra package lives in artifacts/lyra/ (routes, workflows, packs, agents). The only live owner approval surface is Telegram inline buttons, handled by pipeline/approval.rs and pipeline/post_approval.rs. Product narrative lives in README.md, docs/lyra.md, artifacts/lyra/*.md, and site/src/content/docs/*.md.

Runtime substrate that already exists: standing rules with quota/rate budgets, expiry-to-needs_review, drift-to-needs_review, dark-window defaults, and an owner-dispatchable revoke_standing_rule action. A reflection miner emits persona and standing_rule proposals from repeated owner-approved audit rows through the generic artifact.propose lifecycle. Gate-time standing-rule consultation flips ApprovalRequired to Allow within budget.

Gaps: the proposal reaches the owner only as a terse kind/id/version/digest Telegram message with a single "Approve" button. Standing rules match by exact ActionId only (no target/account scope, no changed-target fallback). There is no owner-facing reject/pause/resume surface. The Lyra-specific docs never mention standing rules, the miner, or a delegation loop.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement the end-to-end delegation loop using the existing email-draft workflow
as the demonstration action. The goal is that repeated owner approvals of
`email.create_draft` produce a budgeted, expiring standing-rule proposal, and
that an activated rule reduces interruption on the next matching task, all
without any worker gaining a mutation or activation path.

First, confirm the audit and observation plumbing:
- Verify `email.create_draft` owner approvals are written as `Allow`-decision,
owner-approval-gated audit rows included in
`Store::load_owner_miner_audit_slice`.
- In `reflection_miner_runtime/scheduled.rs`, confirm `reflection_miner_tick`
derives a `RepeatedApproval` observation once the dominant `(artifact_id,
action_id)` pair reaches at least two entries for this action.
- Do not alter the miner authority boundary: it must remain an
`OrdinaryMinerGrant` with no output channels and no direct-mutation actions.

Next, ensure the proposed rule is meaningful:
- In `reflection_miner_payload.rs`, keep the `StandingRuleCandidate` to
`StandingRuleManifest` serialization tied to the observed `action_id`, never a
hardcoded action.
- Set conservative, plain-language-readable default quota, rate, and
`expires_after_secs` values.
- Preserve the existing rule that prohibition-shaped instructions never become
authority artifacts.

Finally, confirm reuse and receipts:
- Confirm `consult_standing_rule_gate` (invoked from
`api/actions.rs::mediate_and_dispatch_action`) flips `ApprovalRequired` to
`Allow` for the demonstration action within budget after activation.
- In `pipeline/approval_draft.rs`, emit a concise receipt after a successful
auto-allowed task, stating what happened and the remaining budget window,
without repeating the full permission model.
===============================================================================

Task: 2

Replace the terse standing-rule proposal message with an ordinary-language view
and add the owner controls needed for the full loop. The owner must never need
to read `task grant`, `artifact lifecycle`, or `standing rule` to decide
correctly.

Rendering:
- Add a new module under `crates/openspine-kernel/src/pipeline/` (for example
`delegation_proposal.rs`) that renders a plain-language view from the parsed
`StandingRuleManifest` and its provenance audit row
(`reflection.miner.provenance`).
- The rendered text must state: what Lyra noticed; what would happen
automatically next time; which accounts, objects, actions, budgets, and time
windows are covered; what stays blocked or approval-required; how to pause or
revoke.
- In `api/artifact_propose.rs`, when `kind == "standing_rule"`, send this
rendered text instead of the terse `kind/id/version/digest` summary. Keep the
digest binding unchanged; only change the visible framing.
- Keep persona and preference proposals on their existing, separate framing so
preference learning stays visibly distinct from authority growth.

Approve/Reject controls:
- Keep the existing digest-bound Approve button and unchanged activation path in
`pipeline/approval.rs` and `pipeline/post_approval.rs`.
- Add a Reject callback in `pipeline/approval.rs` that consumes the
`ActionRequest`, records an audit event, and confirms to the owner that nothing
was activated. A rejected or never-tapped proposal must never affect any gate
decision.
- Extend the Telegram connector send path (`connectors`, used by
`send_reply_with_approval_button`) to support attaching more than one inline
button where needed.

Pause/Resume/Revoke controls:
- Add owner-facing Pause, Resume, and Revoke controls mapped to the
standing-rule actions added in Phase 3.
- Wire callbacks in `pipeline/approval.rs` (or a sibling handler) to dispatch
`pause_standing_rule`, `resume_standing_rule`, and the existing
`revoke_standing_rule` through the normal gated action surface.
- After each control action, send a short confirmation stating the new state and
its effect (for example, "Paused. The next matching task will ask for
approval.").
===============================================================================

Task: 3

Extend the standing-rule lifecycle with an owner-controlled paused state and a
reviewed scope predicate, while keeping the task grant the sole live authority
object.

Pause/resume state machine:
- In `store/standing_rules.rs`, add a `paused` status and transitions `active ->
paused` and `paused -> active`.
- Add store methods `pause_standing_rule` and `resume_standing_rule`, idempotent
and audited, matching the existing `revoke_standing_rule` pattern.
- In `standing_rules_gate.rs` and `store/standing_rules_budget.rs`, treat
`paused` like non-active for consultation so a paused rule never flips
`ApprovalRequired` to `Allow`.
- Register `pause_standing_rule` and `resume_standing_rule` in
`api/handler_registry.rs` and `action_catalog_data.rs`.

Reviewed scope predicate and changed-target fallback:
- In `crates/openspine-schemas/src/standing_rule.rs`, add an optional scope
predicate to `StandingRuleManifest` (for example an account or target selector),
with positive-value validation and `deny_unknown_fields` preserved.
- In `consult_standing_rule_gate`, match the pending action's bound parameters
against the scope predicate. If the target does not match the scope, do not
reuse the rule; leave `ApprovalRequired` in place so the owner reviews the new
target.
- Reflect the scope in the plain-language renderer from Phase 2 (the "which
accounts, objects" line).
- Keep the existing budget, rate, expiry-to-`needs_review`, and
drift-to-`needs_review` fallbacks unchanged.
===============================================================================

Task: 4

Update the product narrative and add a capability map so the docs are truthful
about what is promised, what runtime machinery has landed, and what owner loop
actually ships.

Narrative updates:
- Update `README.md`, `docs/lyra.md`, `artifacts/lyra/README.md`,
`artifacts/lyra/ARCHITECTURE.md`, `artifacts/lyra/CHANGELOG.md`, and
`artifacts/lyra/PERSONA.md` to describe the shipped delegation loop.
- Add a caveat in these docs that standing rules, the reflection miner, and
preference overlays are landed runtime machinery, now proven through one owner
loop, not yet through every capability.
- Keep the wording consistent with `site/src/content/docs/roadmap.md`,
`comparison.md`, and `why-openspine.md`; update these pages to reference the
newly shipped loop.

Capability map:
- Add a structured capability map data file and a small generator that renders
it into the site, under `site/src/content/docs/` (for example a `capability-map`
page plus a data source).
- Label each capability as `runtime`, `wired into Lyra`, or `planned product
surface`.
- Require an owner-path test reference before any capability can be labeled
`wired into Lyra`.
- If this package ships as part of Lyra, register any new route/workflow/pack
artifact in `artifacts/lyra/package.yaml` and reconcile it with the memory and
authority conventions there.
===============================================================================

Task: 5

Add the tests required by the "Done when" criteria and prove that learning never
becomes permission by itself.

Owner-path tests for the full loop:
- Cover activation, matching reuse (next matching task auto-allowed within
budget), budget-saturation fallback, drift fallback, pause and resume, expiry
fallback, and revocation. Extend `store/standing_rule_mediation_tests.rs`,
`store/standing_rule_scheduling_tests.rs`, and the reflection miner runtime
tests.
- Add a test for changed-target fallback using the scope predicate added in
Phase 3.
- Add a test that a paused or revoked rule causes the next matching task to ask
for approval.

No-silent-widening tests:
- Add a test that a proposed but not-activated standing rule never changes a
gate decision.
- Add a test that a persona or preference proposal never changes any
`allowed_actions`, `approval_required_actions`, or `denied_actions`, keeping
preference learning separate from authority growth.
- Add a test that the miner cannot dispatch `standing_rule.*`, `policy.*`,
`artifact.activate`, or `artifact.nominate_upstream`.

💡 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!

[George-RD]

Selected first proof after #119

PR #124 is merged and the checked capability map now makes this the authoritative first owner-facing progression for #123:

Recurring Gmail draft responsibility for one known relationship.

Boundary

• one configured mailbox;
• one exact counterparty key / reviewed target scope;
• email.create_draft only;
• conservative weekly volume budget;
• fixed expiry;
• changed target, exhausted budget, drift, pause, expiry, or revocation falls back to approval or denial;
• email.send remains denied.

Proof sequence

1. The owner selects a Gmail thread and approves the exact draft through the existing digest-bound flow.
2. After repeated matching approval, Lyra proposes the reusable responsibility in ordinary language: what it noticed, what would happen next time, scope, budget, expiry, and what remains blocked.
3. The owner approves or narrows it through the governed artifact lifecycle; no worker or learned preference activates authority.
4. The next matching draft is created with a concise receipt and without another approval prompt.
5. Pause, expiry, revocation, changed target, drift, or budget exhaustion immediately removes the shortcut and returns the action for review.

Implementation should preserve this sequence and reuse the existing Gmail, reflection-miner, standing-rule, budget, expiry, and artifact-lifecycle machinery rather than introducing a new connector or a second delegation abstraction. The generated roadmap and capabilities/capability-map.json are now the status source for moving recurring-draft-responsibility from product_surface_missing to wired_into_lyra.