Ship recurring Gmail drafts as the first complete delegation proof

[George-RD]

Why

Gmail remains the right first vertical proof because the selected-thread read, draft generation, exact preview, digest-bound approval, and real draft write already exist. It is not the architecture. This issue starts only after the protocol-neutral contracts and execution/scope/control/evaluation foundations are complete.

The proof must demonstrate OpenSpine's product promise end to end:

one bounded task → repeated exact approvals → truthful responsibility proposal → reviewed activation → less interruption on matching work → clear fallback and control.

It must create a real Gmail draft on the reusable path. A proposal message or standing-rule row alone is not the proof.

Preconditions

Requires:

• Define the protocol-neutral responsibility contract above standing rules #126 protocol-neutral responsibility/action/review contracts;
• Unify approved and delegated effect execution; fail closed on missing executors #127 one shared execution-backed email.create_draft effect path;
• Mine and match reusable authority by kernel-resolved scope #128 kernel-resolved evidence and reviewed-scope matching before budget use;
• Add channel-neutral responsibility review and lifecycle controls #129 channel-neutral review and lifecycle controls;
• Make reusable-authority evaluation proposal-specific and evidence-backed #133 proposal-specific structural evaluation and real replay/simulation evidence.

Issue #118 should make the first task easy to reach for users, but its full onboarding polish is not a code prerequisite for this runtime proof.

Selected responsibility

Initial reviewed scope should be deliberately narrow and understandable. The design should default to:

• one configured Gmail connector instance;
• one owner mailbox;
• one bound counterparty/relationship;
• the existing selected-thread reply-draft workflow;
• draft creation only;
• conservative quota/rate and lapse-after-unused expiry;
• no final send;
• no dark-window Allow in the first proof unless Define the protocol-neutral responsibility contract above standing rules #126 separately settles and permits it.

Whether a new thread with the same bound relationship matches must be an explicit reviewed scope choice, not an implementation accident.

End-to-end sequence

1. The owner selects a Gmail thread through the existing trusted selection path.
2. Lyra reads only that thread, drafts a reply, and shows the exact payload and target.
3. The owner approves the exact draft; the shared executor creates it.
4. A later approval in the same kernel-resolved context class creates sufficient repeated-approval evidence.
5. The miner proposes a reusable responsibility with the real evidence summary, exact scope, effect, budget, expiry, and blocked actions.
6. The exact proposal is structurally judged and replayed/simulated against its positive evidence and changed-context cases; stored verdicts bind the proposal/runtime compatibility.
7. The owner may approve, reject, or request a narrower immutable version.
8. On a later matching task, the normal grant still marks draft creation approval-required; scoped standing-rule mediation reserves budget and the same executor creates the draft without another per-instance approval.
9. Lyra sends a concise receipt naming the responsibility/version, target, and remaining budget.
10. Changed scope, budget saturation, pause, expiry, drift, policy change, or revocation restores ordinary approval/denial before any effect.

Required owner-path tests

Positive path

• two distinct exact approvals in the same context class produce one reviewable candidate;
• proposal-specific structural/replay verdicts pass and bind the exact reviewed version;
• approval activates the exact reviewed version;
• the next matching task creates one real Gmail draft without a per-instance approval;
• the task grant remains the only live authority object;
• the receipt is concise, truthful, and audit-linked.

Scope fallback

• different Gmail account/connector instance;
• different mailbox;
• different bound counterparty;
• changed recipient after preview;
• target/counterparty becomes unresolved or erased;
• foreign/expired/used selection token;
• scope descriptor/version drift;
• ambiguous overlap with another scoped rule.

Each must require normal approval or deny before reservation/effect.

Budget and lifecycle fallback

• quota exhausted;
• rate exhausted;
• pause;
• expiry;
• drift/needs-review;
• revoke;
• active policy change;
• connector removal/reconfiguration;
• stale evaluation verdict after a compatibility epoch changes.

Each must avoid unintended effect and produce the correct short exception surface.

Effect correctness

• same executor under per-instance and standing-rule admission;
• double-tap/replay remains idempotent;
• target/payload mutation fails;
• confirmed pre-effect connector failure releases budget;
• delivery unknown fences retry and retains truthful budget/audit state;
• audit failure prevents or truthfully fences the effect according to existing ordering.

Owner-surface correctness

• Telegram and terminal can review/decide the same responsibility;
• Reject activates nothing;
• narrow/amend creates a new version and new evaluation binding;
• Pause/Resume/Revoke act immediately and are replay-safe;
• no internal ontology is required to make the correct decision;
• review text says only what the actual evidence/verdicts prove.

Documentation truth gate

Only after the complete positive owner path passes may the capability map move generic progressive delegation to Wired into Lyra. Documentation must say:

• progressive delegation is the capability;
• recurring Gmail draft is the first proof;
• only the reviewed Gmail scope is shipped;
• other protocols require their own connector/action conformance and owner-path proof;
• email send remains denied.

Done when

• A real reusable Gmail draft is created through the same executor as exact approval.
• Every listed changed-context and lifecycle case falls back before effect.
• Owner controls and receipts work through the generic review model.
• Proposal-specific evaluation is real, stored, truthful, and compatibility-bound.
• The complete path has named owner-facing tests used by the checked capability map.
• README/site/roadmap distinguish the generic capability from the first Gmail proof.

Relationship

Parent: #123.

Requires: #126, #127, #128, #129, and #133.

[coderabbitai]

Coding Plan

Summary

• Give the Gmail draft responsibility a first-class, kernel-resolved reviewed-scope descriptor. Extend the manifest with evidence, scope, and blocked actions, so matching is explicit and narrow.
• Wire the reflection miner to detect repeated exact approvals in one context class. Propose a truthful responsibility through the normal proposal-to-activation ceremony.
• Route email.create_draft through the mediation boundary. Converge per-instance approval and standing-rule admission on the same create_approved_draft executor, with scope match before budget use and correct failure/delivery-unknown handling.
• Add Pause/Resume, narrow/amend, and a channel-neutral review surface. Prove every fallback with named owner-path tests. Move the capability to wired_into_lyra only after the positive path passes.

Design Choices

Design Choice 1: Relationship between this ticket and preconditions `#126-`#129

Options Considered:

1. Assume #126–Add channel-neutral responsibility review and lifecycle controls #129 deliver the generic abstractions; this ticket wires only the Gmail-specific concrete pieces and defaults.
2. Build the generic abstractions inside this ticket alongside the Gmail proof.

Chosen Option: 1

Rationale: The ticket explicitly separates #126–#129 as required issues. This plan wires the Gmail concrete scope, mediation, review, and defaults onto those foundations. The plan flags where each foundation must exist before the phase begins. The exploration found no in-flight change for the protocol-neutral contracts (#126), the shared email.create_draft execution path (#127), kernel-resolved evidence/scope matching (#128), or channel-neutral review/lifecycle controls (#129). The ticket states this work "starts only after" those foundations are complete.

Design Choice 2: Match rule for a new Gmail thread with the same bound counterparty

Options Considered:

1. Same-thread-only match (most conservative): the reviewed scope binds the exact thread.
2. Same-counterparty-any-thread match: any thread with the bound counterparty matches.

Chosen Option: 1

Rationale: The first proof must be deliberately narrow. The scope descriptor carries an explicit thread_match field. This lets a wider choice become a reviewed decision later, not a default. The ticket requires this to be an explicit reviewed choice, not an implementation accident.

💡 User Tips

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

Implementation Steps

Phase 1: Define the Gmail reusable-responsibility scope and contract

This phase defines the narrow reviewed scope and the responsibility contract fields the ticket requires. It gives the standing rule a first-class scope descriptor so that matching is explicit and kernel-resolved, not a duplicated JSON literal.

Task 1: Define the reviewed-scope descriptor as a first-class type

Create a single named scope descriptor for Gmail draft responsibilities.

• Add a GmailDraftScope type in crates/openspine-schemas/ that names the tuple currently built ad hoc as target_digest: connector_instance, mailbox_role, bound counterparty identity, workflow (selected-thread reply-draft), and an explicit thread_match field (default: same-thread-only).
• Provide one canonical digest function for this descriptor so proposal time and effect time compute identical bytes.
• Restrict the effect to email.create_draft only; record email.send as a blocked action.

Task 2: Extend the responsibility manifest with evidence, scope, and blocked actions

Add the fields the ticket requires to the standing-rule manifest.

• Update crates/openspine-schemas/src/standing_rule.rs StandingRuleManifest to carry an evidence_summary, the GmailDraftScope descriptor, and an explicit blocked_actions list.
• Keep the existing quota, rate, and expires_after_secs; set conservative defaults for the Gmail proof and forbid dark_window for this scope.
• Extend StandingRuleManifest::validate to reject a Gmail draft responsibility that sets a final-send action, sets a dark-window Allow, or omits the scope descriptor.

Task 3: Persist and match the reviewed scope in the store

Make the standing-rule store scope-aware.

• Update crates/openspine-kernel/src/store/standing_rules.rs to persist the scope descriptor with the rule row.
• Change the lookup used by active_standing_rule_for_action/consult_and_reserve_standing_rule from flat action_id equality to action_id plus an exact scope-descriptor match, so a rule never applies outside its reviewed scope.

🤖 Prompt for AI agents

Implement the Gmail reusable-responsibility scope and contract so matching is
explicit and kernel-resolved instead of a duplicated JSON literal.

- In `crates/openspine-schemas/`, add a `GmailDraftScope` type. Name the tuple
currently built ad hoc as `target_digest`: `connector_instance`, `mailbox_role`,
bound `counterparty` identity, `workflow` (selected-thread reply-draft), and an
explicit `thread_match` field with default same-thread-only.
- Provide one canonical digest function for `GmailDraftScope` so proposal time
and effect time compute identical bytes.
- Restrict the effect to `email.create_draft` only. Record `email.send` as a
blocked action.
- In `crates/openspine-schemas/src/standing_rule.rs`, extend
`StandingRuleManifest` to carry an `evidence_summary` field, the
`GmailDraftScope` descriptor, and an explicit `blocked_actions` list.
- Keep the existing `quota`, `rate`, and `expires_after_secs` fields. Set
conservative defaults for the Gmail proof. Forbid `dark_window` for this scope.
- Extend `StandingRuleManifest::validate` to reject a Gmail draft responsibility
when it sets a final-send action, sets a dark-window Allow, or omits the scope
descriptor.
- In `crates/openspine-kernel/src/store/standing_rules.rs`, persist the scope
descriptor with the rule row.
- Change the lookup used by `active_standing_rule_for_action` and
`consult_and_reserve_standing_rule` from flat `action_id` equality to
`action_id` plus an exact scope-descriptor match, so a rule never applies
outside its reviewed scope.

Phase 2: Repeated-approval detection and responsibility proposal

This phase makes the reflection miner detect repeated exact Gmail draft approvals inside one kernel-resolved context class and propose a truthful reusable responsibility. The miner keeps no activation authority.

Task 1: Define the kernel-resolved context class for Gmail draft approvals

Give the miner a concrete, kernel-computed grouping key.

• Define the context class as the GmailDraftScope descriptor from Task 1.1, resolved by the kernel at approval time, not supplied by a caller.
• Record the resolved scope on each email.create_draft approval so repeated approvals in the same class can be counted.

Task 2: Detect repeated approvals and emit a scoped candidate

Extend the miner to propose the Gmail responsibility.

• Update crates/openspine-schemas/src/reflection_miner.rs and the miner payload builder so a RepeatedApproval observation for email.create_draft requires at least two kernel-packed audit entries in the same context class.
• Emit a candidate that carries the real action_id, the real evidence summary, the exact reviewed scope, conservative budget, lapse-after-unused expiry, and the blocked-actions list.
• Submit the candidate through the normal artifact.propose → eval → approval → activation ceremony; the miner activates nothing.

🤖 Prompt for AI agents

Implement repeated-approval detection and responsibility proposal for Gmail
drafts, with no activation authority granted to the miner.

- Define the context class as the `GmailDraftScope` descriptor (from Phase 1),
resolved by the kernel at approval time. The context class must not be supplied
by a caller.
- Record the resolved scope on each `email.create_draft` approval, so repeated
approvals in the same context class can be counted.
- Update `crates/openspine-schemas/src/reflection_miner.rs` and the miner
payload builder so a `RepeatedApproval` observation for `email.create_draft`
requires at least two kernel-packed audit entries in the same context class.
- Emit a candidate that carries the real `action_id`, the real evidence summary,
the exact reviewed scope, a conservative budget, lapse-after-unused expiry, and
the blocked-actions list.
- Submit the candidate through the normal `artifact.propose → eval → approval →
activation` ceremony. Ensure the miner does not activate anything itself.

Phase 3: Scoped standing-rule mediation on one shared executor

This phase wires email.create_draft through the mediation boundary, matches the reviewed scope before budget use, reserves budget, and runs the same executor used by per-instance approval. It also sends the receipt and handles effect-correctness fallback.

Task 1: Route the Gmail draft effect through the mediation boundary

Let standing-rule consultation admit email.create_draft.

• Ensure the email.create_draft request reaches mediate_and_dispatch_action_with_attribution_and_token in crates/openspine-kernel/src/api/actions.rs, so consult_standing_rule_gate runs when the normal gate returns ApprovalRequired.
• Keep the task grant as the only live authority object; the standing rule stays a composition input.

Task 2: Match scope and evidence before budget reservation

Enforce precondition #128 for the Gmail path.

• Before reserve_standing_rule_budget, resolve the live scope descriptor and require an exact match to the rule's reviewed scope.
• Deny admission and fall back to ordinary approval when the connector instance, mailbox, bound counterparty, thread-match choice, or scope version differs.
• Add a counterparty check that consults counterparty_keys.rs/erasure ledger; fall back to ordinary approval when the counterparty is unresolved or erased.

Task 3: Converge per-instance and mediated admission on the same executor

Enforce precondition #127.

• Reach create_approved_draft in crates/openspine-kernel/src/pipeline/approval_draft.rs from both the Telegram approval callback and the standing-rule-mediated path, with identical payload-bytes and target_digest re-derivation guarantees.
• Reserve budget before the effect, finalize on success, cancel on confirmed pre-effect connector failure, and retain/fence on delivery-unknown, reusing the retain_reservation classification in actions.rs.
• Preserve idempotency for double-tap/replay and preserve the pending_draft_writes fencing for delivery-unknown.

Task 4: Send the truthful receipt

Report the reusable-path effect concisely.

• After a mediated draft is created, send a concise receipt that names the responsibility id and version, the target, and the remaining budget.
• Link the receipt to the audit entry for the effect.

🤖 Prompt for AI agents

Implement scoped standing-rule mediation for `email.create_draft` so it runs
through the same shared executor as per-instance approval, with correct scope
matching, budget handling, and receipts.

- Ensure the `email.create_draft` request reaches
`mediate_and_dispatch_action_with_attribution_and_token` in
`crates/openspine-kernel/src/api/actions.rs`, so `consult_standing_rule_gate`
runs when the normal gate returns `ApprovalRequired`.
- Keep the task grant as the only live authority object. The standing rule
remains a composition input, not a second authority.
- Before `reserve_standing_rule_budget`, resolve the live scope descriptor and
require an exact match to the rule's reviewed scope.
- Deny admission and fall back to ordinary approval when the connector instance,
mailbox, bound counterparty, thread-match choice, or scope version differs from
the reviewed scope.
- Add a counterparty check that consults `counterparty_keys.rs`/the erasure
ledger. Fall back to ordinary approval when the counterparty is unresolved or
erased.
- Reach `create_approved_draft` in
`crates/openspine-kernel/src/pipeline/approval_draft.rs` from both the Telegram
approval callback and the standing-rule-mediated path. Guarantee identical
payload-bytes and `target_digest` re-derivation on both paths.
- Reserve budget before the effect. Finalize the reservation on success. Cancel
it on confirmed pre-effect connector failure. Retain and fence the reservation
on delivery-unknown, reusing the `retain_reservation` classification in
`actions.rs`.
- Preserve idempotency for double-tap and replay. Preserve the
`pending_draft_writes` fencing for delivery-unknown cases.
- After a mediated draft is created, send a concise receipt that names the
responsibility id and version, the target, and the remaining budget.
- Link the receipt to the audit entry for the effect.

Phase 4: Lifecycle and channel-neutral owner controls

This phase adds the missing lifecycle controls and the channel-neutral review surface (precondition #129), and ensures every lifecycle change restores ordinary approval before any effect.

Task 1: Add Pause and Resume for standing rules

Extend the store with two new lifecycle states.

• Add pause_standing_rule/resume_standing_rule to crates/openspine-kernel/src/store/standing_rules.rs, mirroring the transactional, idempotent, audited pattern of revoke_standing_rule.
• Add a paused status that hides the rule from gate consultation but keeps it resumable, unlike revoked.

Task 2: Add narrow/amend as a new immutable version

Let the owner request a narrower version.

• Support proposing a narrower manifest at version = current + 1 through the existing artifact.propose → artifact.activate ceremony in pipeline/artifact_activation.rs.
• Ensure the amended version supersedes the prior one and never widens the reviewed scope.

Task 3: Make review and decide channel-neutral

Give terminal parity with Telegram.

• Extend the decide/review surface (pipeline/approval.rs, pipeline/artifact_activation.rs, pipeline/message_notify.rs) so both Telegram and terminal can review, approve, reject, narrow, pause, resume, and revoke the same responsibility.
• Present evidence, scope, effect, budget, expiry, and blocked actions in plain language so no internal ontology is required to decide.

Task 4: Restore ordinary approval on any scope or lifecycle change

Guarantee fallback before effect.

• Ensure changed scope, quota or rate saturation, pause, expiry, drift/needs_review, active policy change, connector removal or reconfiguration, and revoke all remove the standing rule from live consultation.
• After any such change, email.create_draft returns to ordinary approval or deny before any reservation or effect.

🤖 Prompt for AI agents

Implement the missing lifecycle controls (Pause/Resume, narrow/amend) and the
channel-neutral review surface, and guarantee fallback to ordinary approval on
every lifecycle or scope change.

- Add `pause_standing_rule` and `resume_standing_rule` to
`crates/openspine-kernel/src/store/standing_rules.rs`. Mirror the transactional,
idempotent, audited pattern of `revoke_standing_rule`.
- Add a `paused` status that hides the rule from gate consultation but keeps it
resumable, unlike `revoked`.
- Support proposing a narrower manifest at `version = current + 1` through the
existing `artifact.propose → artifact.activate` ceremony in
`pipeline/artifact_activation.rs`.
- Ensure the amended version supersedes the prior version and never widens the
reviewed scope.
- Extend the decide/review surface across `pipeline/approval.rs`,
`pipeline/artifact_activation.rs`, and `pipeline/message_notify.rs` so both
Telegram and terminal can review, approve, reject, narrow, pause, resume, and
revoke the same responsibility.
- Present evidence, scope, effect, budget, expiry, and blocked actions in plain
language, so no internal ontology is required to make a decision.
- Ensure that changed scope, quota or rate saturation, pause, expiry,
drift/`needs_review`, active policy change, connector removal or
reconfiguration, and revoke all remove the standing rule from live consultation.
- After any such change, ensure `email.create_draft` returns to ordinary
approval or deny before any reservation or effect happens.

Phase 5: Named owner-path tests

This phase adds the named owner-facing tests the ticket lists and that the capability map will reference.

Task 1: Positive-path tests

Prove the complete loop.

• Add tests near crates/openspine-kernel/src/api/standing_rule_mediation_tests.rs and pipeline/tests/ for: two distinct exact approvals in one context class produce one reviewable candidate; approval activates the exact reviewed version; the next matching task creates one real Gmail draft with no per-instance approval; the task grant stays the only live authority; the receipt is concise, truthful, and audit-linked.

Task 2: Scope, budget, lifecycle, and effect-correctness fallback tests

Prove every fallback case.

• Cover scope fallback: different connector instance, different mailbox, different counterparty, changed recipient after preview, unresolved or erased counterparty, foreign/expired/used selection token, scope descriptor/version drift.
• Cover budget and lifecycle fallback: quota exhausted, rate exhausted, pause, expiry, drift/needs_review, revoke, active policy change, connector removal/reconfiguration.
• Cover effect correctness: same executor under both admissions, idempotent double-tap/replay, target/payload mutation fails, confirmed pre-effect failure releases budget, delivery-unknown fences retry and retains truthful budget/audit state, audit-failure ordering.

Task 3: Owner-surface tests

Prove the generic review model.

• Cover: Telegram and terminal review/decide the same responsibility; Reject activates nothing; narrow/amend creates a new version; Pause/Resume/Revoke act immediately and are replay-safe.

🤖 Prompt for AI agents

Add the named owner-path tests listed by the ticket, near
`crates/openspine-kernel/src/api/standing_rule_mediation_tests.rs` and
`pipeline/tests/`.

Positive-path tests must cover:
- Two distinct exact approvals in one context class produce one reviewable
candidate.
- Approval activates the exact reviewed version.
- The next matching task creates one real Gmail draft with no per-instance
approval.
- The task grant stays the only live authority.
- The receipt is concise, truthful, and audit-linked.

Scope, budget, lifecycle, and effect-correctness fallback tests must cover:
- Scope fallback: different connector instance, different mailbox, different
counterparty, changed recipient after preview, unresolved or erased
counterparty, foreign/expired/used selection token, scope descriptor/version
drift.
- Budget and lifecycle fallback: quota exhausted, rate exhausted, pause, expiry,
drift/`needs_review`, revoke, active policy change, connector
removal/reconfiguration.
- Effect correctness: same executor under both admissions, idempotent
double-tap/replay, target/payload mutation fails, confirmed pre-effect failure
releases budget, delivery-unknown fences retry and retains truthful budget/audit
state, audit-failure ordering.

Owner-surface tests must cover:
- Telegram and terminal review/decide the same responsibility.
- Reject activates nothing.
- Narrow/amend creates a new version.
- Pause/Resume/Revoke act immediately and are replay-safe.

Phase 6: Documentation truth gate

This phase moves the capability to wired_into_lyra only after the complete positive owner path passes, and updates prose to distinguish the generic capability from the first Gmail proof.

Task 1: Archive the change and update the capability map

Satisfy the validator in scripts/capability-map.mjs.

• Archive the implementation change id in openspec/openspine-change-sequence.md.
• Update the recurring-draft-responsibility capability in capabilities/capability-map.json: add real lyra_artifacts, add named owner_path_tests that exist and are registered, and flip state to wired_into_lyra.
• Re-point starter_workflow_candidates so the single selected candidate still references a product_surface_missing capability, as the validator requires.

Task 2: Regenerate and update prose documentation

Keep prose truthful.

• Regenerate the roadmap block with node scripts/capability-map.mjs --write.
• Update README.md and site/src/content/docs/roadmap.md prose to state: progressive delegation is the capability; the recurring Gmail draft is the first proof; only the reviewed Gmail scope is shipped; other protocols require their own connector/action conformance and owner-path proof; email send remains denied.

🤖 Prompt for AI agents

Move the capability to `wired_into_lyra` only after the complete positive owner
path passes, and update prose so it distinguishes the generic capability from
the first Gmail proof.

- Archive the implementation change id in
`openspec/openspine-change-sequence.md`.
- Update the `recurring-draft-responsibility` capability in
`capabilities/capability-map.json`: add real `lyra_artifacts`, add named
`owner_path_tests` that exist and are registered, and flip `state` to
`wired_into_lyra`.
- Re-point `starter_workflow_candidates` so the single selected candidate still
references a `product_surface_missing` capability, as required by the validator
in `scripts/capability-map.mjs`.
- Regenerate the roadmap block with `node scripts/capability-map.mjs --write`.
- Update `README.md` and `site/src/content/docs/roadmap.md` prose to state:
progressive delegation is the capability; the recurring Gmail draft is the first
proof; only the reviewed Gmail scope is shipped; other protocols require their
own connector/action conformance and owner-path proof; email send remains
denied.

Research

OpenSpine composes a single live TaskGrant (D-007) from routes, agents, workflows, packs, and policies. Standing rules are composition inputs, not second authorities.

The Gmail draft path already has one shared executor, create_approved_draft in pipeline/approval_draft.rs. This executor re-derives payload bytes and a target_digest over {thread_id, connector, account_role, recipients} before it calls gmail.create_draft.

Today the executor is reached only from the Telegram approval callback handle_draft_approval_callback. It bypasses the standing-rule mediation boundary in api/actions.rs.

Standing rules match on a flat action_id only, with no scope fields.

The reflection miner detects repeated approvals by exact artifact_id match. No "context class" concept exists.

Pause/Resume and narrow/amend do not exist. Only Revoke and drift-driven needs_review exist.

The review/decide surface is Telegram-only.

The capability map validator (scripts/capability-map.mjs) is the documentation truth gate.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement the Gmail reusable-responsibility scope and contract so matching is
explicit and kernel-resolved instead of a duplicated JSON literal.

- In `crates/openspine-schemas/`, add a `GmailDraftScope` type. Name the tuple
currently built ad hoc as `target_digest`: `connector_instance`, `mailbox_role`,
bound `counterparty` identity, `workflow` (selected-thread reply-draft), and an
explicit `thread_match` field with default same-thread-only.
- Provide one canonical digest function for `GmailDraftScope` so proposal time
and effect time compute identical bytes.
- Restrict the effect to `email.create_draft` only. Record `email.send` as a
blocked action.
- In `crates/openspine-schemas/src/standing_rule.rs`, extend
`StandingRuleManifest` to carry an `evidence_summary` field, the
`GmailDraftScope` descriptor, and an explicit `blocked_actions` list.
- Keep the existing `quota`, `rate`, and `expires_after_secs` fields. Set
conservative defaults for the Gmail proof. Forbid `dark_window` for this scope.
- Extend `StandingRuleManifest::validate` to reject a Gmail draft responsibility
when it sets a final-send action, sets a dark-window Allow, or omits the scope
descriptor.
- In `crates/openspine-kernel/src/store/standing_rules.rs`, persist the scope
descriptor with the rule row.
- Change the lookup used by `active_standing_rule_for_action` and
`consult_and_reserve_standing_rule` from flat `action_id` equality to
`action_id` plus an exact scope-descriptor match, so a rule never applies
outside its reviewed scope.
===============================================================================

Task: 2

Implement repeated-approval detection and responsibility proposal for Gmail
drafts, with no activation authority granted to the miner.

- Define the context class as the `GmailDraftScope` descriptor (from Phase 1),
resolved by the kernel at approval time. The context class must not be supplied
by a caller.
- Record the resolved scope on each `email.create_draft` approval, so repeated
approvals in the same context class can be counted.
- Update `crates/openspine-schemas/src/reflection_miner.rs` and the miner
payload builder so a `RepeatedApproval` observation for `email.create_draft`
requires at least two kernel-packed audit entries in the same context class.
- Emit a candidate that carries the real `action_id`, the real evidence summary,
the exact reviewed scope, a conservative budget, lapse-after-unused expiry, and
the blocked-actions list.
- Submit the candidate through the normal `artifact.propose → eval → approval →
activation` ceremony. Ensure the miner does not activate anything itself.
===============================================================================

Task: 3

Implement scoped standing-rule mediation for `email.create_draft` so it runs
through the same shared executor as per-instance approval, with correct scope
matching, budget handling, and receipts.

- Ensure the `email.create_draft` request reaches
`mediate_and_dispatch_action_with_attribution_and_token` in
`crates/openspine-kernel/src/api/actions.rs`, so `consult_standing_rule_gate`
runs when the normal gate returns `ApprovalRequired`.
- Keep the task grant as the only live authority object. The standing rule
remains a composition input, not a second authority.
- Before `reserve_standing_rule_budget`, resolve the live scope descriptor and
require an exact match to the rule's reviewed scope.
- Deny admission and fall back to ordinary approval when the connector instance,
mailbox, bound counterparty, thread-match choice, or scope version differs from
the reviewed scope.
- Add a counterparty check that consults `counterparty_keys.rs`/the erasure
ledger. Fall back to ordinary approval when the counterparty is unresolved or
erased.
- Reach `create_approved_draft` in
`crates/openspine-kernel/src/pipeline/approval_draft.rs` from both the Telegram
approval callback and the standing-rule-mediated path. Guarantee identical
payload-bytes and `target_digest` re-derivation on both paths.
- Reserve budget before the effect. Finalize the reservation on success. Cancel
it on confirmed pre-effect connector failure. Retain and fence the reservation
on delivery-unknown, reusing the `retain_reservation` classification in
`actions.rs`.
- Preserve idempotency for double-tap and replay. Preserve the
`pending_draft_writes` fencing for delivery-unknown cases.
- After a mediated draft is created, send a concise receipt that names the
responsibility id and version, the target, and the remaining budget.
- Link the receipt to the audit entry for the effect.
===============================================================================

Task: 4

Implement the missing lifecycle controls (Pause/Resume, narrow/amend) and the
channel-neutral review surface, and guarantee fallback to ordinary approval on
every lifecycle or scope change.

- Add `pause_standing_rule` and `resume_standing_rule` to
`crates/openspine-kernel/src/store/standing_rules.rs`. Mirror the transactional,
idempotent, audited pattern of `revoke_standing_rule`.
- Add a `paused` status that hides the rule from gate consultation but keeps it
resumable, unlike `revoked`.
- Support proposing a narrower manifest at `version = current + 1` through the
existing `artifact.propose → artifact.activate` ceremony in
`pipeline/artifact_activation.rs`.
- Ensure the amended version supersedes the prior version and never widens the
reviewed scope.
- Extend the decide/review surface across `pipeline/approval.rs`,
`pipeline/artifact_activation.rs`, and `pipeline/message_notify.rs` so both
Telegram and terminal can review, approve, reject, narrow, pause, resume, and
revoke the same responsibility.
- Present evidence, scope, effect, budget, expiry, and blocked actions in plain
language, so no internal ontology is required to make a decision.
- Ensure that changed scope, quota or rate saturation, pause, expiry,
drift/`needs_review`, active policy change, connector removal or
reconfiguration, and revoke all remove the standing rule from live consultation.
- After any such change, ensure `email.create_draft` returns to ordinary
approval or deny before any reservation or effect happens.
===============================================================================

Task: 5

Add the named owner-path tests listed by the ticket, near
`crates/openspine-kernel/src/api/standing_rule_mediation_tests.rs` and
`pipeline/tests/`.

Positive-path tests must cover:
- Two distinct exact approvals in one context class produce one reviewable
candidate.
- Approval activates the exact reviewed version.
- The next matching task creates one real Gmail draft with no per-instance
approval.
- The task grant stays the only live authority.
- The receipt is concise, truthful, and audit-linked.

Scope, budget, lifecycle, and effect-correctness fallback tests must cover:
- Scope fallback: different connector instance, different mailbox, different
counterparty, changed recipient after preview, unresolved or erased
counterparty, foreign/expired/used selection token, scope descriptor/version
drift.
- Budget and lifecycle fallback: quota exhausted, rate exhausted, pause, expiry,
drift/`needs_review`, revoke, active policy change, connector
removal/reconfiguration.
- Effect correctness: same executor under both admissions, idempotent
double-tap/replay, target/payload mutation fails, confirmed pre-effect failure
releases budget, delivery-unknown fences retry and retains truthful budget/audit
state, audit-failure ordering.

Owner-surface tests must cover:
- Telegram and terminal review/decide the same responsibility.
- Reject activates nothing.
- Narrow/amend creates a new version.
- Pause/Resume/Revoke act immediately and are replay-safe.
===============================================================================

Task: 6

Move the capability to `wired_into_lyra` only after the complete positive owner
path passes, and update prose so it distinguishes the generic capability from
the first Gmail proof.

- Archive the implementation change id in
`openspec/openspine-change-sequence.md`.
- Update the `recurring-draft-responsibility` capability in
`capabilities/capability-map.json`: add real `lyra_artifacts`, add named
`owner_path_tests` that exist and are registered, and flip `state` to
`wired_into_lyra`.
- Re-point `starter_workflow_candidates` so the single selected candidate still
references a `product_surface_missing` capability, as required by the validator
in `scripts/capability-map.mjs`.
- Regenerate the roadmap block with `node scripts/capability-map.mjs --write`.
- Update `README.md` and `site/src/content/docs/roadmap.md` prose to state:
progressive delegation is the capability; the recurring Gmail draft is the first
proof; only the reviewed Gmail scope is shipped; other protocols require their
own connector/action conformance and owner-path proof; email send remains
denied.

💡 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

#9 - Implement implement-selected-thread-email-preview-slice (Step 5) [merged]
#14 - Implement harden-approval-and-budgets: WYSIWYS, grant budgets, token hashing (Step 7) [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!