Unify approved and delegated effect execution; fail closed on missing executors

[George-RD]

Why

The current standing-rule mediation can turn ApprovalRequired into Allow and then call the generic action dispatcher. A catalogued action without a registered handler returns a successful stub response. This is not safe for reusable delegation:

• email.create_draft is deliberately absent from the allowed-action handler registry because the working Gmail write lives in the separate post-approval path;
• a standing rule for email.create_draft can therefore reserve/finalize budget and report success without creating a Gmail draft;
• the owner-facing proposal in PR Superseded: prototype responsibility proposal copy #125 can promise less interruption even though the executable effect path is not connected;
• future actions could repeat the same false-success pattern.

Approval source must not choose a different implementation. Per-instance approval and reusable delegated authority must converge on the same kernel-owned effect executor and immutable request semantics.

Scope

1. Effect executor registry

Introduce a catalog/registry-owned effect executor contract for effectful actions. A delegatable action must have exactly one executable adapter that accepts the kernel-built action request/resolved context.

The registry must distinguish:

• catalogued but intentionally unavailable actions;
• actions handled on the ordinary allowed path;
• actions requiring per-instance approval or standing-rule mediation before the same executor runs;
• internal/non-effect actions.

A missing executor MUST be a fail-closed typed error. It must never return stub: true as successful execution for an effectful or delegatable action.

2. Shared Gmail draft executor

Extract the existing approved Gmail draft write into one kernel-owned email.create_draft executor. Both paths must call it:

1. exact digest-bound per-instance approval;
2. a future scope-matched, budget-reserved standing-rule admission.

The executor must re-use the existing immutable payload/target re-derivation, recipient/thread/account checks, connector breaker, delivery-unknown fencing, audit, and idempotency behavior. The standing-rule path must not reconstruct those semantics from a shell payload.

3. Reservation correctness

• No executor available: cancel any pre-effect standing-rule reservation.
• Confirmed pre-effect failure: cancel reservation.
• Confirmed success: finalize once.
• Delivery unknown after an external write may have landed: retain/finalize and fence retry, matching the existing Gmail contract.
• A successful result must mean the real effect executor ran or an explicitly non-effect action completed; never merely that an ID was known.

4. Delegation readiness

Action proposal/review must be able to ask the registry whether an action is execution-backed for reusable delegation. email.create_draft is not marked ready until the shared executor is wired.

TDD sequence

1. Characterize the current failure with a test showing that standing-rule mediation for email.create_draft reaches the missing-handler stub and consumes budget without a Gmail write.
2. Add a contract test that any effectful action missing an executor fails before reservation finalization.
3. Extract the Gmail draft executor while preserving all current per-instance approval tests.
4. Add tests proving per-instance approval and delegated admission call the same executor with the same target/payload semantics.
5. Add delivery-unknown and audit-failure tests on both admission sources.

Invariants

• The shell still sends intents; it never selects the executor or trusted target.
• gate() and current policy precedence remain unchanged.
• email.send remains denied.
• Standing rules remain composition inputs; they do not become an alternate connector API.
• No connector write happens without durable gate/audit evidence.

Done when

• dispatch_allowed_action cannot report a successful stub for an effectful/delegatable action.
• email.create_draft has one real executor used by both approval sources.
• A standing-rule reservation is finalized only when the executor ran or the write outcome is truthfully delivery-unknown.
• All existing digest-bound approval and Gmail mutation tests remain green.
• The action descriptor from Define the protocol-neutral responsibility contract above standing rules #126 can deterministically report executor readiness.

Relationship

Parent: #123.

Requires: #126.

Blocks the scoped matching and Gmail end-to-end proof slices.

[coderabbitai]

Coding Plan

Summary

• Introduce an EffectExecutorRegistry in AppState that classifies each action id and owns the single readiness query, so dispatch and proposal/review agree on executor presence.
• Change dispatch_allowed_action to fail closed with a typed DispatchError::NoExecutor for effectful and delegatable actions, and route that error to reservation cancellation instead of returning a successful stub.
• Extract the Gmail draft write into one shared kernel-owned executor that preserves immutable payload/target re-derivation, breaker, delivery-unknown fencing, idempotency, and audit, and route the per-instance approval path through it.
• Follow the ticket TDD order: characterize the bug, assert the fail-closed contract, extract without regressing existing approval tests, then prove convergence, reservation correctness, and readiness, and record the change in openspec.

Design Choices

Design Choice 1: How to represent execution readiness given the dependency on ticket `#126`

Options Considered:

1. Add an execution-class field directly to ActionCatalog in openspine-schemas.
2. Own execution class and readiness inside a new EffectExecutorRegistry in the kernel, and let a future #126 descriptor delegate to it.

Chosen Option: 2

Rationale: The registry is the single source of truth for executor presence. This keeps the readiness query consistent with actual dispatch behavior. A future #126 descriptor can read from it without a schema change.

Design Choice 2: What the standing-rule path must do for `email.create_draft` in this slice

Options Considered:

1. Run the shared Gmail executor from the generic allowed path immediately.
2. Fail closed on the generic allowed path and cancel the reservation, until scope-matched admission supplies a digest-bound request.

Chosen Option: 2

Rationale: The generic path has no approved target_digest or payload_ref. Running the executor here would violate digest-bound re-derivation. Failing closed cancels the reservation and removes the false-success bug now.

💡 User Tips

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

Implementation Steps

Phase 1: Characterize the current failure

This phase adds the red tests that prove the bug and define the fail-closed contract before any behavior change.

Task 1: Characterize the standing-rule stub bug for `email.create_draft`

Prove that standing-rule mediation for email.create_draft reaches the missing-handler stub and consumes budget without a Gmail write.

• Add a test in crates/openspine-kernel/src/api/standing_rule_mediation_tests.rs.
• Drive mediate_and_dispatch_action with an active standing rule for email.create_draft so the decision flips from ApprovalRequired to Allow.
• Assert current behavior: a stub: true result, a finalized reservation, and no Gmail draft or draft.created audit.
• Mark this test as the characterization baseline. It will be inverted in later phases.

Task 2: Add the missing-executor contract test

Define that any effectful action without an executor fails before reservation finalization.

• Add a contract test near crates/openspine-kernel/src/api/dispatch_tests.rs and standing_rule_mediation_tests.rs.
• Assert that dispatch of an effectful, executor-less action returns a typed failure, never a successful stub.
• Assert that the standing-rule reservation is cancelled, not finalized, on that failure.

🤖 Prompt for AI agents

Implement Phase 1 of the plan: write failing tests that characterize the current
bug and define the target fail-closed contract, before any production code
changes.

For Task 1.1:
- Add a test in
`crates/openspine-kernel/src/api/standing_rule_mediation_tests.rs`.
- Drive `mediate_and_dispatch_action` with an active standing rule for
`email.create_draft` so the decision flips from `ApprovalRequired` to `Allow`.
- Assert the current behavior: the result is `stub: true`, the reservation is
finalized, and there is no Gmail draft or `draft.created` audit.
- Mark this test explicitly as the characterization baseline for the bug; it
will be inverted in a later phase.

For Task 1.2:
- Add a contract test near `crates/openspine-kernel/src/api/dispatch_tests.rs`
and `standing_rule_mediation_tests.rs`.
- Assert that dispatch of an effectful, executor-less action returns a typed
failure, and never a successful stub.
- Assert that the standing-rule reservation is cancelled, not finalized, when
that failure occurs.

Phase 2: Effect executor registry and fail-closed dispatch

This phase introduces the registry, wires it into AppState, and replaces the stub-on-miss behavior with a fail-closed typed error for effectful and delegatable actions.

Task 1: Introduce the effect executor registry and classification

Create a registry that owns the executor contract and classifies each action id.

• Create a new registry type (for example EffectExecutorRegistry) in a new module under crates/openspine-kernel/src/api/, modeled on ActionHandlerRegistry.
• Define an execution-class enum with four cases that match the ticket: ordinary allowed path, mediated (per-instance approval or standing-rule), intentionally unavailable, and internal/non-effect.
• Provide a default_registrations() constructor and lookup methods: one to resolve a class, and one readiness query is_execution_backed(action_id).
• Derive effectful classification from existing catalog signals (effect-path class such as PostGateApprovedEffect/GatedShell, egress declarations, and the non-delegable set), so reads and internal actions stay distinct from effectful ones.
• Classify email.create_draft as mediated with a wired shared executor (readiness true). Classify email.send as intentionally unavailable.

Task 2: Wire the registry into AppState

Add the registry to the shared state at the same seam as action_handlers.

• Add a field (for example effect_executors: EffectExecutorRegistry) to AppState in crates/openspine-kernel/src/pipeline/mod.rs.
• Construct it in the AppState literal in crates/openspine-kernel/src/main.rs.
• Construct it identically in crates/openspine-kernel/src/test_support.rs::fixtures::build_state_with_store, which covers all test helpers.

Task 3: Replace stub-on-miss with fail-closed dispatch

Make dispatch_allowed_action consult the registry and fail closed for effectful and delegatable actions.

• Update dispatch_allowed_action in crates/openspine-kernel/src/api/connector_breaker.rs to resolve the execution class before returning any result.
• For ordinary allowed-path actions with a registered handler: run the handler as today.
• For internal/non-effect actions with no side effect: return an explicit non-effect completion (not a result labeled as an executed effect).
• For effectful, delegatable, or mediated actions with no runnable executor on this path: return a new typed error instead of a stub.
• Add a DispatchError::NoExecutor variant (carrying the ActionId) in crates/openspine-kernel/src/api/actions.rs.
• Keep the benign stub only where the registry classifies the action as a non-effect placeholder; effectful and delegatable ids must never produce stub: true.

Task 4: Handle the new error in reservation and audit logic

Ensure the new error cancels reservations and audits like a confirmed pre-effect failure.

• Update the match dispatched error branch in mediate_and_dispatch_action_with_attribution_and_token in crates/openspine-kernel/src/api/actions.rs.
• Map DispatchError::NoExecutor to the cancel branch (retain_reservation = false) with cleanup_pre_effect_reservations.
• Emit an action.dispatch_failed audit for the missing-executor case, classified as a resource/connector failure consistent with the existing branches.
• Update the existing unregistered_known_action_returns_stub_shape test in dispatch_tests.rs to reflect the new contract: reads/non-effect ids keep the stub, effectful/delegatable ids fail closed.

🤖 Prompt for AI agents

Implement Phase 2 of the plan: introduce the `EffectExecutorRegistry`, wire it
into `AppState`, and change dispatch behavior so effectful and delegatable
actions fail closed instead of returning a stub.

Registry and classification:
- Create a new registry type (for example `EffectExecutorRegistry`) in a new
module under `crates/openspine-kernel/src/api/`, modeled on
`ActionHandlerRegistry`.
- Define an execution-class enum with four cases: ordinary allowed path,
mediated (per-instance approval or standing-rule), intentionally unavailable,
and internal/non-effect.
- Provide a `default_registrations()` constructor and lookup methods: one to
resolve a class, and one readiness query `is_execution_backed(action_id)`.
- Derive effectful classification from existing catalog signals (effect-path
class such as `PostGateApprovedEffect`/`GatedShell`, egress declarations, and
the non-delegable set), so reads and internal actions stay distinct from
effectful ones.
- Classify `email.create_draft` as mediated with a wired shared executor
(readiness true). Classify `email.send` as intentionally unavailable.

Wiring:
- Add a field (for example `effect_executors: EffectExecutorRegistry`) to
`AppState` in `crates/openspine-kernel/src/pipeline/mod.rs`.
- Construct it in the `AppState` literal in
`crates/openspine-kernel/src/main.rs`.
- Construct it identically in
`crates/openspine-kernel/src/test_support.rs::fixtures::build_state_with_store`.

Dispatch behavior:
- Update `dispatch_allowed_action` in
`crates/openspine-kernel/src/api/connector_breaker.rs` to resolve the execution
class before returning any result.
- For ordinary allowed-path actions with a registered handler, run the handler
as today.
- For internal/non-effect actions with no side effect, return an explicit
non-effect completion, not a result labeled as an executed effect.
- For effectful, delegatable, or mediated actions with no runnable executor on
this path, return a new typed error instead of a stub.
- Add a `DispatchError::NoExecutor` variant carrying the `ActionId` in
`crates/openspine-kernel/src/api/actions.rs`.
- Keep the benign stub only where the registry classifies the action as a
non-effect placeholder. Effectful and delegatable ids must never produce `stub:
true`.

Reservation and audit handling:
- Update the `match dispatched` error branch in
`mediate_and_dispatch_action_with_attribution_and_token` in
`crates/openspine-kernel/src/api/actions.rs`.
- Map `DispatchError::NoExecutor` to the cancel branch (`retain_reservation =
false`) using `cleanup_pre_effect_reservations`.
- Emit an `action.dispatch_failed` audit for the missing-executor case,
classified as a resource/connector failure consistent with the existing
branches.
- Update the existing `unregistered_known_action_returns_stub_shape` test in
`dispatch_tests.rs` to reflect the new contract: reads and non-effect ids keep
the stub; effectful and delegatable ids fail closed.

Phase 3: Extract the shared Gmail draft executor

This phase moves the Gmail draft write into one kernel-owned executor and routes the per-instance approval path through it, with no behavior change for existing approval tests.

Task 1: Extract `create_approved_draft` into a shared executor

Create one executor that owns the immutable re-derivation and connector semantics.

• Extract the body of create_approved_draft from crates/openspine-kernel/src/pipeline/approval_draft.rs into a shared kernel-owned executor callable from both the effect executor registry and the post-approval path.
• Preserve, unchanged: payload digest re-derivation from request.payload_ref, thread re-fetch and recipient re-derivation, target_digest re-check against request.target_digest, the connector breaker calls (call_with_connector, call_with_connector_write, map_write_error), delivery-unknown fencing, and all audit event kinds (draft.payload_mutated_since_approval, draft.target_mutated_since_approval, draft.delivery_unknown, draft.creation_failed, draft.created).
• Preserve pending-write idempotency: insert_pending_draft_write before the write and resolve_pending_draft_write only on a confirmed outcome, leaving the row pending on delivery-unknown (store/pending_draft.rs).
• Widen the visibility of insert_pending_draft_write/resolve_pending_draft_write only if the executor moves outside the current module tree.

Task 2: Route the per-instance approval path through the shared executor

Keep the owner-approval flow behavior identical while using the shared executor.

• Update handle_create_approved_draft in crates/openspine-kernel/src/pipeline/post_approval.rs to call the shared executor.
• Keep the POST_APPROVAL_HANDLERS call-site contract (handler(state, grant, request, chat_id)) unchanged so pipeline/approval.rs does not change.
• Register the same shared executor in the effect executor registry as the email.create_draft executor, so readiness reports true.

Task 3: Keep all existing draft approval tests green

Confirm no regression in the digest-bound and mutation tests.

• Run and preserve pipeline/tests/approval_draft_reconcile_tests.rs and pipeline/tests/effect_paths.rs (Path 2).
• Confirm payload-mutation, target-mutation, delivery-unknown, and idempotency cases still produce the same audit fingerprints.

🤖 Prompt for AI agents

Implement Phase 3 of the plan: extract the Gmail draft write into one shared
kernel-owned executor and route the per-instance approval path through it,
without changing observable behavior for existing approval tests.

Extraction:
- Extract the body of `create_approved_draft` from
`crates/openspine-kernel/src/pipeline/approval_draft.rs` into a shared
kernel-owned executor callable from both the effect executor registry and the
post-approval path.
- Preserve, unchanged: payload digest re-derivation from `request.payload_ref`,
thread re-fetch and recipient re-derivation, `target_digest` re-check against
`request.target_digest`, the connector breaker calls (`call_with_connector`,
`call_with_connector_write`, `map_write_error`), delivery-unknown fencing, and
all audit event kinds (`draft.payload_mutated_since_approval`,
`draft.target_mutated_since_approval`, `draft.delivery_unknown`,
`draft.creation_failed`, `draft.created`).
- Preserve pending-write idempotency: `insert_pending_draft_write` before the
write, and `resolve_pending_draft_write` only on a confirmed outcome. Leave the
row pending on delivery-unknown, per `store/pending_draft.rs`.
- Widen the visibility of
`insert_pending_draft_write`/`resolve_pending_draft_write` only if the executor
moves outside the current module tree.

Routing:
- Update `handle_create_approved_draft` in
`crates/openspine-kernel/src/pipeline/post_approval.rs` to call the shared
executor.
- Keep the `POST_APPROVAL_HANDLERS` call-site contract (`handler(state, grant,
request, chat_id)`) unchanged, so `pipeline/approval.rs` does not change.
- Register the same shared executor in the effect executor registry as the
`email.create_draft` executor, so readiness reports true.

Verification:
- Run and preserve `pipeline/tests/approval_draft_reconcile_tests.rs` and
`pipeline/tests/effect_paths.rs` (Path 2).
- Confirm payload-mutation, target-mutation, delivery-unknown, and idempotency
cases still produce the same audit fingerprints.

Phase 4: Reservation correctness, convergence, and delegation readiness

This phase adds the convergence and delivery-unknown tests and exposes the readiness query used by proposal and review.

Task 1: Prove one executor across both approval sources

Show that per-instance approval and delegated admission call the same executor with the same target and payload semantics.

• Add tests in standing_rule_mediation_tests.rs and the draft test modules.
• Invert the Phase 1 characterization: email.create_draft on the generic standing-rule path now fails closed and cancels the reservation (no stub, no budget consumed on a confirmed pre-effect failure).
• Add a test that invokes the shared executor from both call sites with a digest-bound request and asserts identical target/payload re-derivation and identical draft.created audit references.

Task 2: Add delivery-unknown and audit-failure tests on both admission sources

Confirm the reservation and fencing contract holds regardless of the admission source.

• Add tests asserting: confirmed success finalizes the reservation once; confirmed pre-effect failure cancels it; delivery-unknown retains/finalizes and leaves the pending-draft row open to fence retry.
• Assert audit evidence exists before any connector write, per the connector-reality contract.

Task 3: Expose delegation-readiness to proposal and review

Let proposal/review ask the registry whether an action is execution-backed.

• Expose is_execution_backed(action_id) from the effect executor registry through AppState.
• Reference it from the action proposal/review path (for example api/proposal.rs) so a reusable-delegation proposal can query readiness.
• Confirm email.create_draft reports ready only after Phase 3 wiring; unwired effectful ids report not ready.

🤖 Prompt for AI agents

Implement Phase 4 of the plan: add convergence and delivery-unknown tests across
both admission sources, and expose the readiness query to proposal and review.

Convergence tests:
- Add tests in `standing_rule_mediation_tests.rs` and the draft test modules.
- Invert the Phase 1 characterization test: `email.create_draft` on the generic
standing-rule path now fails closed and cancels the reservation, with no stub
and no budget consumed on a confirmed pre-effect failure.
- Add a test that invokes the shared executor from both call sites with a
digest-bound request and asserts identical target/payload re-derivation and
identical `draft.created` audit references.

Delivery-unknown and audit tests:
- Add tests asserting: confirmed success finalizes the reservation once;
confirmed pre-effect failure cancels it; delivery-unknown retains/finalizes and
leaves the pending-draft row open to fence retry.
- Assert audit evidence exists before any connector write, per the
connector-reality contract.

Readiness exposure:
- Expose `is_execution_backed(action_id)` from the effect executor registry
through `AppState`.
- Reference it from the action proposal/review path (for example
`api/proposal.rs`) so a reusable-delegation proposal can query readiness.
- Confirm `email.create_draft` reports ready only after the Phase 3 wiring, and
that unwired effectful ids report not ready.

Phase 5: OpenSpec change artifacts

This phase records the authority-sensitive change per repo conventions.

Author the openspec change

Create the change proposal and spec deltas.

• Create a new change directory under openspec/changes/ with proposal.md, design.md, and tasks.md.
• Include the required proposal sections: Dependencies, Problem/Context, Proposed Solution, Acceptance Criteria, Out of Scope, and explicit verification tasks (authority-sensitive).
• Add spec deltas as ## MODIFIED Requirements for gate-action-api (dispatch fail-closed, no stub for effectful actions), connector-reality (executor preserves breaker/delivery-unknown/idempotency), standing-rules (reservation cancel/finalize/retain rules), and digest-bound-draft-approval (shared executor keeps kernel re-derivation).
• State in Out of Scope that scope-matched standing-rule admission for email.create_draft is future work.

🤖 Prompt for AI agents

Implement Phase 5 of the plan: author the openspec change artifacts for this
authority-sensitive change.

- Create a new change directory under `openspec/changes/` with `proposal.md`,
`design.md`, and `tasks.md`.
- Include the required proposal sections: Dependencies, Problem/Context,
Proposed Solution, Acceptance Criteria, Out of Scope, and explicit verification
tasks (authority-sensitive).
- Add spec deltas as `## MODIFIED Requirements` for: `gate-action-api` (dispatch
fail-closed, no stub for effectful actions); `connector-reality` (executor
preserves breaker, delivery-unknown, and idempotency behavior); `standing-rules`
(reservation cancel/finalize/retain rules); and `digest-bound-draft-approval`
(shared executor keeps kernel re-derivation).
- State in Out of Scope that scope-matched standing-rule admission for
`email.create_draft` is future work.

Research

The kernel routes each effect through gate() and then dispatches allowed actions through one low-level adapter, dispatch_allowed_action, in crates/openspine-kernel/src/api/connector_breaker.rs. This adapter looks up AppState.action_handlers, an ActionHandlerRegistry defined in api/handler_registry.rs. On a lookup miss, the adapter returns {"stub": true, ...} as a successful result.

Standing-rule mediation in api/actions.rs can flip ApprovalRequired to Allow, reserve budget, and then call this same adapter. The Gmail draft write is implemented separately in pipeline/approval_draft.rs::create_approved_draft. This function is reached only through the post-approval dispatch table in pipeline/post_approval.rs.

Reservation lifecycle functions live in store/standing_rules_budget.rs. Gmail idempotency fencing lives in store/pending_draft.rs.

AppState is a flat struct in pipeline/mod.rs. It is constructed identically in main.rs and test_support.rs.

The action catalog and EffectPathClass live in openspine-schemas/src/action.rs and action_catalog.rs. These classify named effect paths, not action ids. There is no per-action "execution readiness" concept yet.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement Phase 1 of the plan: write failing tests that characterize the current
bug and define the target fail-closed contract, before any production code
changes.

For Task 1.1:
- Add a test in
`crates/openspine-kernel/src/api/standing_rule_mediation_tests.rs`.
- Drive `mediate_and_dispatch_action` with an active standing rule for
`email.create_draft` so the decision flips from `ApprovalRequired` to `Allow`.
- Assert the current behavior: the result is `stub: true`, the reservation is
finalized, and there is no Gmail draft or `draft.created` audit.
- Mark this test explicitly as the characterization baseline for the bug; it
will be inverted in a later phase.

For Task 1.2:
- Add a contract test near `crates/openspine-kernel/src/api/dispatch_tests.rs`
and `standing_rule_mediation_tests.rs`.
- Assert that dispatch of an effectful, executor-less action returns a typed
failure, and never a successful stub.
- Assert that the standing-rule reservation is cancelled, not finalized, when
that failure occurs.
===============================================================================

Task: 2

Implement Phase 2 of the plan: introduce the `EffectExecutorRegistry`, wire it
into `AppState`, and change dispatch behavior so effectful and delegatable
actions fail closed instead of returning a stub.

Registry and classification:
- Create a new registry type (for example `EffectExecutorRegistry`) in a new
module under `crates/openspine-kernel/src/api/`, modeled on
`ActionHandlerRegistry`.
- Define an execution-class enum with four cases: ordinary allowed path,
mediated (per-instance approval or standing-rule), intentionally unavailable,
and internal/non-effect.
- Provide a `default_registrations()` constructor and lookup methods: one to
resolve a class, and one readiness query `is_execution_backed(action_id)`.
- Derive effectful classification from existing catalog signals (effect-path
class such as `PostGateApprovedEffect`/`GatedShell`, egress declarations, and
the non-delegable set), so reads and internal actions stay distinct from
effectful ones.
- Classify `email.create_draft` as mediated with a wired shared executor
(readiness true). Classify `email.send` as intentionally unavailable.

Wiring:
- Add a field (for example `effect_executors: EffectExecutorRegistry`) to
`AppState` in `crates/openspine-kernel/src/pipeline/mod.rs`.
- Construct it in the `AppState` literal in
`crates/openspine-kernel/src/main.rs`.
- Construct it identically in
`crates/openspine-kernel/src/test_support.rs::fixtures::build_state_with_store`.

Dispatch behavior:
- Update `dispatch_allowed_action` in
`crates/openspine-kernel/src/api/connector_breaker.rs` to resolve the execution
class before returning any result.
- For ordinary allowed-path actions with a registered handler, run the handler
as today.
- For internal/non-effect actions with no side effect, return an explicit
non-effect completion, not a result labeled as an executed effect.
- For effectful, delegatable, or mediated actions with no runnable executor on
this path, return a new typed error instead of a stub.
- Add a `DispatchError::NoExecutor` variant carrying the `ActionId` in
`crates/openspine-kernel/src/api/actions.rs`.
- Keep the benign stub only where the registry classifies the action as a
non-effect placeholder. Effectful and delegatable ids must never produce `stub:
true`.

Reservation and audit handling:
- Update the `match dispatched` error branch in
`mediate_and_dispatch_action_with_attribution_and_token` in
`crates/openspine-kernel/src/api/actions.rs`.
- Map `DispatchError::NoExecutor` to the cancel branch (`retain_reservation =
false`) using `cleanup_pre_effect_reservations`.
- Emit an `action.dispatch_failed` audit for the missing-executor case,
classified as a resource/connector failure consistent with the existing
branches.
- Update the existing `unregistered_known_action_returns_stub_shape` test in
`dispatch_tests.rs` to reflect the new contract: reads and non-effect ids keep
the stub; effectful and delegatable ids fail closed.
===============================================================================

Task: 3

Implement Phase 3 of the plan: extract the Gmail draft write into one shared
kernel-owned executor and route the per-instance approval path through it,
without changing observable behavior for existing approval tests.

Extraction:
- Extract the body of `create_approved_draft` from
`crates/openspine-kernel/src/pipeline/approval_draft.rs` into a shared
kernel-owned executor callable from both the effect executor registry and the
post-approval path.
- Preserve, unchanged: payload digest re-derivation from `request.payload_ref`,
thread re-fetch and recipient re-derivation, `target_digest` re-check against
`request.target_digest`, the connector breaker calls (`call_with_connector`,
`call_with_connector_write`, `map_write_error`), delivery-unknown fencing, and
all audit event kinds (`draft.payload_mutated_since_approval`,
`draft.target_mutated_since_approval`, `draft.delivery_unknown`,
`draft.creation_failed`, `draft.created`).
- Preserve pending-write idempotency: `insert_pending_draft_write` before the
write, and `resolve_pending_draft_write` only on a confirmed outcome. Leave the
row pending on delivery-unknown, per `store/pending_draft.rs`.
- Widen the visibility of
`insert_pending_draft_write`/`resolve_pending_draft_write` only if the executor
moves outside the current module tree.

Routing:
- Update `handle_create_approved_draft` in
`crates/openspine-kernel/src/pipeline/post_approval.rs` to call the shared
executor.
- Keep the `POST_APPROVAL_HANDLERS` call-site contract (`handler(state, grant,
request, chat_id)`) unchanged, so `pipeline/approval.rs` does not change.
- Register the same shared executor in the effect executor registry as the
`email.create_draft` executor, so readiness reports true.

Verification:
- Run and preserve `pipeline/tests/approval_draft_reconcile_tests.rs` and
`pipeline/tests/effect_paths.rs` (Path 2).
- Confirm payload-mutation, target-mutation, delivery-unknown, and idempotency
cases still produce the same audit fingerprints.
===============================================================================

Task: 4

Implement Phase 4 of the plan: add convergence and delivery-unknown tests across
both admission sources, and expose the readiness query to proposal and review.

Convergence tests:
- Add tests in `standing_rule_mediation_tests.rs` and the draft test modules.
- Invert the Phase 1 characterization test: `email.create_draft` on the generic
standing-rule path now fails closed and cancels the reservation, with no stub
and no budget consumed on a confirmed pre-effect failure.
- Add a test that invokes the shared executor from both call sites with a
digest-bound request and asserts identical target/payload re-derivation and
identical `draft.created` audit references.

Delivery-unknown and audit tests:
- Add tests asserting: confirmed success finalizes the reservation once;
confirmed pre-effect failure cancels it; delivery-unknown retains/finalizes and
leaves the pending-draft row open to fence retry.
- Assert audit evidence exists before any connector write, per the
connector-reality contract.

Readiness exposure:
- Expose `is_execution_backed(action_id)` from the effect executor registry
through `AppState`.
- Reference it from the action proposal/review path (for example
`api/proposal.rs`) so a reusable-delegation proposal can query readiness.
- Confirm `email.create_draft` reports ready only after the Phase 3 wiring, and
that unwired effectful ids report not ready.
===============================================================================

Task: 5

Implement Phase 5 of the plan: author the openspec change artifacts for this
authority-sensitive change.

- Create a new change directory under `openspec/changes/` with `proposal.md`,
`design.md`, and `tasks.md`.
- Include the required proposal sections: Dependencies, Problem/Context,
Proposed Solution, Acceptance Criteria, Out of Scope, and explicit verification
tasks (authority-sensitive).
- Add spec deltas as `## MODIFIED Requirements` for: `gate-action-api` (dispatch
fail-closed, no stub for effectful actions); `connector-reality` (executor
preserves breaker, delivery-unknown, and idempotency behavior); `standing-rules`
(reservation cancel/finalize/retain rules); and `digest-bound-draft-approval`
(shared executor keeps kernel re-derivation).
- State in Out of Scope that scope-matched standing-rule admission for
`email.create_draft` is future work.

💡 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]
#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]
#107 - chore(openspec): archive wire-authority-equivalence-selection [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!