Counterparty erasure has no local origination surface: sweep guard is wired but only externally reachable

[George-RD]

What to build

Counterparty crypto-erasure guards are production-wired and invoked at startup, but no local owner origination path exists—the erasure set can only be populated by an accepted external ledger on restore. Add an authenticated owner command to originate erasure locally, signed ledger entry first, then local transaction. Give the erasure-sweep census row a caller-level test.

Acceptance criteria

1. Add owner API command: erasure_counterparty(id: ULID) -> Result. 2. Sign the ledger delta and persist. 3. Run transactional erasure sweep. 4. Add caller-level test covering the command path and the transactional recheck. 5. Inventory existing guard tests from Ship recurring Gmail drafts as the first complete delegation proof #130 and carry them forward.

Blocked by

None (correctness gap; no fit-review fence required)

Original report

Summary

#130 extends Store::mark_learned_artifacts_erased with a generic reviewed-scope standing-rule sweep, so a crypto-erased counterparty loses live scoped authority. The guard site is production-wired and unconditionally invoked at startup, and it is reachable whenever a valid, continuity-compatible external terminal ledger carrying erased ids is accepted through restore — which the archived overlay-restore contract explicitly provides for. What is absent is local owner origination: no production caller of record_terminal_erasure exists in any commit, so nothing running on this terminal can begin an erasure.

Filed at the moment the gap is created, rather than left for a caller census to discover two changes later.

The precise state, in three parts

1. The path is live and unconditional. main.rs:303-309 calls validate_startup_and_reconcile_overlay_terminal_erasures, which at main.rs:144 calls counterparty_erasure::reconcile_overlay_terminal_erasures (:89-106) after the boot-clock and audit-chain gates. There is no configuration or feature guard. It loads the signed ledger, iterates erased_counterparty_ids(), rejects SYSTEM_SCOPE (:98, :108-115), closes the in-memory scope (:99-102), then finish_local_erasure (:117-129) calls Store::mark_learned_artifacts_erased at :122.

2. Local origination is absent, and always was. OverlayControl::record_terminal_erasure (overlay_export_restore/control/continuity.rs:125-152) is the sole mutator of the erasure set — the only site performing body.erased_counterparty_ids.insert(...) followed by write_ledger(&signed). Every other reference under control/ is a read, a comparison, a superset check, or a wire-format field. Its only non-test caller is erase_counterparty (counterparty_erasure.rs:71), which carries #[allow(dead_code)] at :59-60; all of its own callers are *_tests.rs. git log -S on both the function and its annotated form returns exactly one commit — 5c51ded feat(kernel): implement counterparty key model (AD-140, resolves QQ-7) (#102) — so the function was born dead and was never wired.

3. External ledgers can carry ids, by contract. Bundle merge collects merged.erased_counterparty_ids() (operation/process.rs:174) and applies a terminal-erasure delta at :175. The incoming baseline is re-signed under the local master key and rejected on mismatch (process.rs:263-278), but that check validates shape and lineage, not provenance: sign_ledger (control/continuity.rs:242-252) HMACs a canonical TerminalLedger of exactly {version, continuity_id, sequence, erased_counterparty_ids} (control/wire.rs:108-113), with no producer identity, build provenance, or origination-path field.

The archived design makes this an input rather than an accident — openspec/changes/archive/2026-07-24-implement-overlay-export-restore/design.md §5: "portable recovery additionally requires the latest separately preserved signed ledger, analogous to the external master key. Restore requires the local/imported ledger and bundle baseline to share the same continuity id, then merges their monotonic state." That section also places "a malicious host operator deliberately supplying both an old bundle and stale valid ledger" outside the trust boundary rather than declaring it impossible.

So the work set is not provably empty. It is unpopulated by local action, and populated by any accepted continuity-compatible ledger.

Reachability condition

Reconciliation always runs. It has work iff a continuity-compatible signed terminal ledger containing at least one parseable, non-SYSTEM_SCOPE ULID counterparty id is present locally or imported through restore. Producing such a ledger requires the master key but not a live local caller — so the missing piece is specifically local owner origination, not production erasure ingress.

Why the guards were still right to land in #130

The mechanism is fail-closed and correct: the SQLite erased_counterparties marker is the single admission predicate, checked at both entry paths and re-read inside the same BEGIN IMMEDIATE transaction that selects/reserves a scoped rule or consumes a fired token, so an erase committing mid-admission is ordered rather than raced.

The alternative was to leave the hole open until an origination surface arrives — so that the first accepted erasure would land on a runtime where erased counterparties keep live scoped authority to act on their own data. Because external ledgers are an accepted input today, that exposure is live, not hypothetical. Building the mechanism first and disclosing that local origination is missing is strictly better than shipping the surface onto an unguarded runtime.

This is deliberate mechanism-first sequencing, disclosed at creation.

Inherited obligation

Whoever lands the origination surface inherits proving guards written earlier by someone else. #130's reachability census is the map. Rows to carry forward:

• Generic standing-rule erasure sweep — proven at store level by owner_review_created_scoped_rule_is_revoked_on_counterparty_erasure_store_level; needs a caller-level test once origination exists.
• is_counterparty_erased + normal admission check — api/scoped_admission.rs::resolve_scoped_admission from api/actions.rs::post_actions.
• Scoped reservation transactional recheck — store/standing_rules.rs::consult_and_reserve_scoped_rule from api/scoped_admission.rs::consult_scoped_rule.
• Fired-entry marker check and fired-token transactional recheck — both UNPROVEN / latent in #130 for a different and unrelated reason: token minting is inert while the dark-window Allow allowlist is empty (action_catalog_contracts.rs:54-60) and email.create_draft is DarkWindowPolicy::Prohibited (action_catalog_data.rs:84). An origination surface does not unblock these — they need a non-empty allowlist. Do not assume one fix reaches both.

Canon exposure

AD-140 ratifies crypto-erase — named as canon at openspec/openspine-change-sequence.md:411, scope at :414-416: "per-counterparty payload keys replacing the single global artifact-store key; crypto-erase = key deletion — plaintext unrecoverable while the hash chain keeps tamper evidence; derived overlay artifacts" invalidated. The completion machinery exists, is wired, and runs; what is absent is any way for an owner to originate the act locally.

docs/threat-claims.md carries no erasure claim. Its only counterparty row is CLAIM-31 (:44), about counterparty identity binding being gated on an authenticated owner-principal context and audited atomically — not erasure. No gated claim is currently false, so nothing needs walking back; the exposure is a missing surface, not an overstatement.

Correction owed to #130's census

The census row for the generic erasure sweep records NONE in the production-caller column. That understates the state: the guard is wired and unconditionally invoked at startup. The accurate wording is "wired and unconditionally invoked at startup; reachable via imported continuity ledger; local origination absent." That correction belongs with #130, not here.

Scope

Add an authenticated owner-facing erasure command that originates a terminal erasure locally — signed ledger entry first, then the local transaction — and give the erasure-sweep census row a caller-level test.

Out of scope: plaintext briefcases, SYSTEM_SCOPE/pending protected payloads, owner-review row lifecycle, and cross-store atomicity between the external ledger, SQLite, and filesystem key cleanup. Those are recorded residuals of #130.

Related: #130

[coderabbitai]

Coding Plan

Summary

• Add openspine.counterparty.erase as a non-delegable root-owner gate-mediated action, modeled exactly on openspine.overlay.export/restore, so erasure origination passes through gate() and stays fail-closed.
• Activate the existing erase_counterparty primitive as the handler's backend, preserving its ledger-first ordering (signed terminal-ledger entry, then local SQLite invalidation and key deletion).
• Author the required OpenSpec change (proposal, design, tasks, spec delta) and update the change-sequence file, because the surface is authority-sensitive.
• Discharge the #130 inherited obligation with a caller-level test that proves the standing-rule erasure sweep through the new handler, plus authorization and payload negative tests.

File-Level Change Summary and Follow-up Notes

• crates/openspine-kernel/src/counterparty_erasure.rs: remove #[allow(dead_code)] on erase_counterparty.
• crates/openspine-kernel/src/action_catalog.rs: add id, with_non_delegable entry, EffectPath; update effect-path enumeration test.
• crates/openspine-kernel/src/action_catalog_data.rs: add the ActionEgressDeclaration (None/None).
• crates/openspine-kernel/src/api/overlay_export_restore.rs: call the shared root-owner grant helper instead of the local copy.
• crates/openspine-kernel/src/api/ (shared helper location): host the reused require_root_owner_grant logic.
• crates/openspine-kernel/src/api/erase_counterparty.rs (new) and crates/openspine-kernel/src/api/erase_counterparty_tests.rs (new if split): handler, payload validation, and tests.
• crates/openspine-kernel/src/api/mod.rs: declare the new submodule.
• crates/openspine-kernel/src/api/handler_registry.rs: import and register the handler.
• artifacts/lyra/packs/owner_control_basic_pack.yaml, artifacts/lyra/agents/main_assistant_agent.yaml: add the action id.
• openspec/changes/<new-change>/ and openspec/openspine-change-sequence.md: OpenSpec change and sequence entry.

Follow-up agent notes:

• Run the inner loop with cargo test -p openspine-kernel, then the full gate scripts/check.sh <change-id>. The gate builds openspine-shell before workspace tests.
• Archive the OpenSpec change only with the pinned CLI (openspec archive <id> --yes), then run openspec validate --all --strict. Do not move directories by hand.
• Do not touch the #130 census wording correction here; the ticket states that correction lands with #130.
• Do not add fired-token or dark-window reachability work; those remain latent for an unrelated reason (empty dark-window Allow allowlist) and are out of scope.

Design Choices

Design Choice 1: Trigger surface for the erasure

Options Considered:

1. Add a new clap CLI subcommand in main.rs that opens the store/artifact/overlay triple and calls erase_counterparty directly.
2. Add a new non-delegable root-owner gate-mediated action (openspine.counterparty.erase), dispatched through post_actions → gate() → handler, mirroring openspine.overlay.export/restore.

Chosen Option: 2

Rationale: The gate-action-api spec requires every effectful action to pass through gate(). The day-2-operations spec and the overlay export/restore precedent establish that destructive owner-admin operations MUST be non-delegable root-owner actions, not CLI bypasses.

Design Choice 2: Sharing the root-owner authorization check

Options Considered:

1. Duplicate require_root_owner_grant verbatim into the new handler file with renamed messages.
2. Hoist the check into a small shared helper that both overlay_export_restore.rs and the new erasure handler call.

Chosen Option: 2

Rationale: This is a security-critical invariant. A single shared helper prevents the two copies from diverging over time. The refactor is small and preserves the existing checks exactly.

💡 User Tips

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

Implementation Steps

Phase 1: Author the OpenSpec change

This phase records the new capability through the required OpenSpec workflow before code lands, because the change is authority-sensitive (audit, recovery, owner authority).

Task 1: Create the change proposal and design

Document the problem, the chosen surface, and the ordering rationale.

• Create a new change folder under openspec/changes/ with proposal.md, design.md, and tasks.md.
• In proposal.md, include the required sections: ## Dependencies, ## Problem/Context, ## Proposed Solution, ## Acceptance Criteria, ## Out of Scope. State that this depends on #130, and that plaintext briefcases, SYSTEM_SCOPE/pending protected payloads, owner-review row lifecycle, and cross-store atomicity are out of scope.
• In design.md, state the durability ordering as a numbered decision: the signed terminal-ledger entry MUST be durable before the local SQLite invalidation and key deletion, because a restored older generation could otherwise resurrect erased data. Model this on Decision 5 of the archived implement-overlay-export-restore change. Add a Risks/Trade-offs section.
• In tasks.md, group tasks by design decision, name concrete code paths, and include an explicit "Document and record (authority-sensitive)" section with verification tasks.

Task 2: Write the spec delta

Add the requirement that the origination surface is a non-delegable root-owner action.

• Add a spec delta under specs/counterparty-key-model/spec.md in the change folder. Because counterparty-key-model already exists as a canonical spec, use ## MODIFIED Requirements if you extend an existing requirement, or ## ADDED Requirements only for a genuinely new requirement.
• Add a requirement stating that owner-initiated counterparty erasure MUST be exposed only through a non-delegable root-owner gate-mediated action, with the ledger-first ordering and audit obligations. Add Given/When/Then scenarios covering: owner root-grant success, foreign-principal rejection, owner-derived worker-grant rejection, SYSTEM_SCOPE rejection, and malformed payload rejection.
• Add a new entry and any Requires: edge to openspec/openspine-change-sequence.md, since a new decomposition item is being introduced.

🤖 Prompt for AI agents

Implement this phase by authoring the required OpenSpec change artifacts before
any code changes, because the capability is authority-sensitive.

- Create a new change folder under `openspec/changes/` containing `proposal.md`,
`design.md`, and `tasks.md`.
- In `proposal.md`, add the sections `## Dependencies`, `## Problem/Context`,
`## Proposed Solution`, `## Acceptance Criteria`, `## Out of Scope`. State the
dependency on `#130`. List as out of scope: plaintext briefcases,
`SYSTEM_SCOPE`/pending protected payloads, owner-review row lifecycle, and
cross-store atomicity.
- In `design.md`, record as a numbered decision that the signed terminal-ledger
entry MUST be durable before the local SQLite invalidation and key deletion,
with the rationale that a restored older generation could otherwise resurrect
erased data. Model this on Decision 5 of the archived
`implement-overlay-export-restore` change. Add a Risks/Trade-offs section.
- In `tasks.md`, group tasks by design decision, name concrete code paths, and
add an explicit "Document and record (authority-sensitive)" section with
verification tasks.
- Add a spec delta file at `specs/counterparty-key-model/spec.md` inside the
change folder, using `## MODIFIED Requirements` for extended requirements or `##
ADDED Requirements` only for a genuinely new requirement.
- In the spec delta, add a requirement that owner-initiated counterparty erasure
MUST be exposed only through a non-delegable root-owner gate-mediated action,
with ledger-first ordering and audit obligations. Add Given/When/Then scenarios
for: owner root-grant success, foreign-principal rejection, owner-derived
worker-grant rejection, `SYSTEM_SCOPE` rejection, and malformed payload
rejection.
- Add a new entry and any `Requires:` edge to
`openspec/openspine-change-sequence.md` for this new decomposition item.

Phase 2: Implement the erasure origination action

This phase adds the production origination surface. It registers a new catalog action, adds a gated handler that calls the existing erase_counterparty primitive, and wires the owner conversational path so a root owner can actually compose a grant for the action.

Task 1: Activate the erasure primitive

Make erase_counterparty a live production function.

• Remove the #[allow(dead_code)] attribute above erase_counterparty in crates/openspine-kernel/src/counterparty_erasure.rs, since it will now have a production caller.
• Do not change the body; the ledger-first ordering and reject_system_scope check are already correct.
• The file is 133 lines; no module split is required.

Task 2: Register the new catalog action

Add openspine.counterparty.erase to the action catalog as non-delegable.

• In crates/openspine-kernel/src/action_catalog.rs, add the id string "openspine.counterparty.erase" to the ids list in canonical_catalog(), add it to .with_non_delegable([...]), and add an EffectPath entry with EffectPathClass::GatedShell. Update the effect-path enumeration test to include the new path name.
• In crates/openspine-kernel/src/action_catalog_data.rs, add an ActionEgressDeclaration { output_channels: None, egress_class: None } entry for the new id (erasure is a local effect, not a network egress).
• Do not add the action to any dark-window allowlist or delegation descriptor in action_catalog_contracts.rs; this omission keeps it fail-closed and non-delegable.

Task 3: Add a shared root-owner grant check

Extract the root-owner authorization invariant for reuse.

• Move the body of require_root_owner_grant from crates/openspine-kernel/src/api/overlay_export_restore.rs into a shared location under crates/openspine-kernel/src/api/ (for example a small helper module), keeping all four checks identical: owner principal match, true root grant with no delegation hops, non-delegable classification, and exact effectively_allows.
• Update overlay_export_restore.rs to call the shared helper, so its behavior is unchanged.
• Keep the error messages action-agnostic, or pass the action label so messages stay descriptive.

Task 4: Add the erasure action handler

Create the handler that validates the payload, authorizes the owner, and calls erase_counterparty.

• Create crates/openspine-kernel/src/api/erase_counterparty.rs.
• Define a #[serde(deny_unknown_fields)] payload struct with a single counterparty_id: String field, and a parse_payload function that folds all decode failures to DispatchError::BadRequest with a static message.
• Parse counterparty_id with Ulid::from_str, and map failure to DispatchError::BadRequest("counterparty_id is not a valid id"), following the API-layer ULID convention.
• Implement handle_erase_counterparty matching the ActionHandler fn-pointer signature. Assert the action id equals "openspine.counterparty.erase". Call the shared root-owner grant check. Reject SYSTEM_SCOPE as a DispatchError::BadRequest (defense in depth; erase_counterparty also rejects it).
• Access state.store, state.artifacts, and state.overlay_operations directly, and call erase_counterparty(store, artifacts, operations, counterparty_id).
• Return a JSON Value containing only non-sensitive fields from ErasureReport: derived_artifacts_invalidated, key_deleted, and ledger_sequence. Do not return invalidated_identities content, to avoid leaking learned-artifact detail in the response.
• Declare pub(crate) mod erase_counterparty; in crates/openspine-kernel/src/api/mod.rs, and register the handler in crates/openspine-kernel/src/api/handler_registry.rs (use import plus map.insert("openspine.counterparty.erase", handle_erase_counterparty as ActionHandler)).

Task 5: Wire the owner conversational path

Let a root owner compose a grant for the new action.

• Add openspine.counterparty.erase to artifacts/lyra/packs/owner_control_basic_pack.yaml and artifacts/lyra/agents/main_assistant_agent.yaml, mirroring how openspine.overlay.export / openspine.overlay.restore are listed, so an owner-composed root grant effectively_allows the action.

🤖 Prompt for AI agents

Implement this phase by adding the production origination surface for
counterparty erasure: a catalog action, a gated handler, and owner
conversational wiring.

- In `crates/openspine-kernel/src/counterparty_erasure.rs`, remove the
`#[allow(dead_code)]` attribute above `erase_counterparty`, since it now has a
production caller. Do not change the function body; the ledger-first ordering
and `reject_system_scope` check are already correct. The file is 133 lines, so
no module split is required.
- In `crates/openspine-kernel/src/action_catalog.rs`, add the id string
`"openspine.counterparty.erase"` to the `ids` list in `canonical_catalog()`, add
it to `.with_non_delegable([...])`, and add an `EffectPath` entry with
`EffectPathClass::GatedShell`. Update the effect-path enumeration test to
include the new path name.
- In `crates/openspine-kernel/src/action_catalog_data.rs`, add an
`ActionEgressDeclaration { output_channels: None, egress_class: None }` entry
for the new id, since erasure is a local effect, not a network egress.
- Do not add the action to any dark-window allowlist or delegation descriptor in
`action_catalog_contracts.rs`; this omission keeps it fail-closed and
non-delegable.
- Extract the shared root-owner grant check: move the body of
`require_root_owner_grant` from
`crates/openspine-kernel/src/api/overlay_export_restore.rs` into a shared
location under `crates/openspine-kernel/src/api/` (for example a small helper
module). Keep all four checks identical: owner principal match, true root grant
with no delegation hops, non-delegable classification, and exact
`effectively_allows`. Update `overlay_export_restore.rs` to call the shared
helper so its behavior is unchanged. Keep error messages action-agnostic, or
pass the action label so messages stay descriptive.
- Create `crates/openspine-kernel/src/api/erase_counterparty.rs`. Define a
`#[serde(deny_unknown_fields)]` payload struct with a single `counterparty_id:
String` field, and a `parse_payload` function that folds all decode failures to
`DispatchError::BadRequest` with a static message. Parse `counterparty_id` with
`Ulid::from_str`, mapping failure to `DispatchError::BadRequest("counterparty_id
is not a valid id")`, following the API-layer ULID convention.
- Implement `handle_erase_counterparty` matching the `ActionHandler` fn-pointer
signature. Assert the action id equals `"openspine.counterparty.erase"`. Call
the shared root-owner grant check. Reject `SYSTEM_SCOPE` as a
`DispatchError::BadRequest` for defense in depth (`erase_counterparty` also
rejects it).
- Access `state.store`, `state.artifacts`, and `state.overlay_operations`
directly, and call `erase_counterparty(store, artifacts, operations,
counterparty_id)`.
- Return a JSON `Value` with only the non-sensitive fields from `ErasureReport`:
`derived_artifacts_invalidated`, `key_deleted`, and `ledger_sequence`. Do not
return `invalidated_identities` content, to avoid leaking learned-artifact
detail in the response.
- Declare `pub(crate) mod erase_counterparty;` in
`crates/openspine-kernel/src/api/mod.rs`, and register the handler in
`crates/openspine-kernel/src/api/handler_registry.rs` with a `use` import plus
`map.insert("openspine.counterparty.erase", handle_erase_counterparty as
ActionHandler)`.
- Add `openspine.counterparty.erase` to
`artifacts/lyra/packs/owner_control_basic_pack.yaml` and
`artifacts/lyra/agents/main_assistant_agent.yaml`, mirroring how
`openspine.overlay.export` / `openspine.overlay.restore` are listed, so an
owner-composed root grant `effectively_allows` the action.

Phase 3: Prove the guard with a caller-level test

This phase discharges the inherited obligation from #130: prove the generic standing-rule erasure sweep through the new origination surface rather than through a direct erase_counterparty call.

Task 1: Add the caller-level erasure-sweep test

Drive erasure through the new handler and assert the standing-rule sweep.

• Add tests in crates/openspine-kernel/src/api/erase_counterparty.rs behind #[cfg(test)] #[path = "erase_counterparty_tests.rs"] mod tests;, or an inline test module if the file stays under 500 lines. Create the paired crates/openspine-kernel/src/api/erase_counterparty_tests.rs if a split is needed.
• Add a caller-level test named to parallel the store-level test, for example owner_review_created_scoped_rule_is_revoked_on_counterparty_erasure_caller_level.
• Build AppState via crate::test_support::fixtures. Seed a learned artifact and an active scoped standing rule bound to a target counterparty, and a control rule bound to an unrelated counterparty.
• Mint a root, non-delegable-classified owner TaskGrant for the action, following the mint_grant / mint_composed_owner_grant pattern in api/overlay_export_restore.rs.
• Call handle_erase_counterparty directly with crate::test_support::owner_surface_for(...) and a JSON payload containing the target counterparty_id.
• Assert post-erasure state as in counterparty_erasure_runtime_tests.rs: the target rule's DB row is status = 'revoked', active_standing_rule_for_action returns None for it, and consult_standing_rule_gate no longer matches or allows; the control rule stays unaffected. Assert verify_audit_chain() still passes and exactly one counterparty.erased audit event exists.

Task 2: Add authorization negative tests

Prove the gate rejects unauthorized callers and bad input.

• Add tests mirroring the overlay export/restore negatives: foreign principal rejected, non-root or delegated-hop grant rejected, owner-derived worker grant rejected, wrong action id rejected, malformed or unknown-field payload rejected, invalid ULID rejected, and SYSTEM_SCOPE rejected.
• If a test: <name> row is added to docs/threat-claims.md for the erasure guard, ensure it names a real landing test so scripts/check-claims.sh passes.

🤖 Prompt for AI agents

Implement this phase by adding tests that prove the standing-rule erasure sweep
through the new handler, plus authorization negative tests.

- Add tests in `crates/openspine-kernel/src/api/erase_counterparty.rs` behind
`#[cfg(test)] #[path = "erase_counterparty_tests.rs"] mod tests;`, or use an
inline test module if the file stays under 500 lines. Create the paired
`crates/openspine-kernel/src/api/erase_counterparty_tests.rs` if a split is
needed.
- Add a caller-level test named to parallel the store-level test, for example
`owner_review_created_scoped_rule_is_revoked_on_counterparty_erasure_caller_level`.
Build `AppState` via `crate::test_support::fixtures`. Seed a learned artifact
and an active scoped standing rule bound to a target counterparty, plus a
control rule bound to an unrelated counterparty.
- Mint a root, non-delegable-classified owner `TaskGrant` for the action,
following the `mint_grant` / `mint_composed_owner_grant` pattern in
`api/overlay_export_restore.rs`.
- Call `handle_erase_counterparty` directly with
`crate::test_support::owner_surface_for(...)` and a JSON payload containing the
target `counterparty_id`.
- Assert post-erasure state as in `counterparty_erasure_runtime_tests.rs`: the
target rule's DB row has `status = 'revoked'`, `active_standing_rule_for_action`
returns `None` for it, and `consult_standing_rule_gate` no longer matches or
allows. Assert the control rule stays unaffected. Assert `verify_audit_chain()`
still passes and exactly one `counterparty.erased` audit event exists.
- Add negative tests mirroring the overlay export/restore negatives: foreign
principal rejected, non-root or delegated-hop grant rejected, owner-derived
worker grant rejected, wrong action id rejected, malformed or unknown-field
payload rejected, invalid ULID rejected, and `SYSTEM_SCOPE` rejected.
- If a `test: <name>` row is added to `docs/threat-claims.md` for the erasure
guard, name a real landing test so `scripts/check-claims.sh` passes.

Research

The kernel lives in crates/openspine-kernel. Counterparty erasure logic is in counterparty_erasure.rs. The function erase_counterparty(store, artifacts, operations, counterparty_id) already performs the correct ordering: it calls OverlayOperations::record_terminal_erasure (the sole ledger mutator) under a per-scope lock, then calls finish_local_erasure → Store::mark_learned_artifacts_erased. erase_counterparty carries #[allow(dead_code)] and only tests call it. Its startup sibling reconcile_overlay_terminal_erasures is wired at main.rs:144 and iterates the signed ledger.

Destructive owner-administrative operations in this codebase are exposed as non-delegable root-owner gate-mediated actions, not CLI flags. The canonical precedent is openspine.overlay.export / openspine.overlay.restore in api/overlay_export_restore.rs: a catalog entry (action_catalog.rs, action_catalog_data.rs), a handler registered in api/handler_registry.rs, a local require_root_owner_grant check, strict deny_unknown_fields payload parsing, and owner-pack wiring in artifacts/lyra/. New capabilities also require an OpenSpec change (proposal/design/tasks/spec delta) per AGENTS.md and openspec/conventions.md. Files under crates/**/*.rs must stay at 500 lines or fewer.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement this phase by authoring the required OpenSpec change artifacts before
any code changes, because the capability is authority-sensitive.

- Create a new change folder under `openspec/changes/` containing `proposal.md`,
`design.md`, and `tasks.md`.
- In `proposal.md`, add the sections `## Dependencies`, `## Problem/Context`,
`## Proposed Solution`, `## Acceptance Criteria`, `## Out of Scope`. State the
dependency on `#130`. List as out of scope: plaintext briefcases,
`SYSTEM_SCOPE`/pending protected payloads, owner-review row lifecycle, and
cross-store atomicity.
- In `design.md`, record as a numbered decision that the signed terminal-ledger
entry MUST be durable before the local SQLite invalidation and key deletion,
with the rationale that a restored older generation could otherwise resurrect
erased data. Model this on Decision 5 of the archived
`implement-overlay-export-restore` change. Add a Risks/Trade-offs section.
- In `tasks.md`, group tasks by design decision, name concrete code paths, and
add an explicit "Document and record (authority-sensitive)" section with
verification tasks.
- Add a spec delta file at `specs/counterparty-key-model/spec.md` inside the
change folder, using `## MODIFIED Requirements` for extended requirements or `##
ADDED Requirements` only for a genuinely new requirement.
- In the spec delta, add a requirement that owner-initiated counterparty erasure
MUST be exposed only through a non-delegable root-owner gate-mediated action,
with ledger-first ordering and audit obligations. Add Given/When/Then scenarios
for: owner root-grant success, foreign-principal rejection, owner-derived
worker-grant rejection, `SYSTEM_SCOPE` rejection, and malformed payload
rejection.
- Add a new entry and any `Requires:` edge to
`openspec/openspine-change-sequence.md` for this new decomposition item.
===============================================================================

Task: 2

Implement this phase by adding the production origination surface for
counterparty erasure: a catalog action, a gated handler, and owner
conversational wiring.

- In `crates/openspine-kernel/src/counterparty_erasure.rs`, remove the
`#[allow(dead_code)]` attribute above `erase_counterparty`, since it now has a
production caller. Do not change the function body; the ledger-first ordering
and `reject_system_scope` check are already correct. The file is 133 lines, so
no module split is required.
- In `crates/openspine-kernel/src/action_catalog.rs`, add the id string
`"openspine.counterparty.erase"` to the `ids` list in `canonical_catalog()`, add
it to `.with_non_delegable([...])`, and add an `EffectPath` entry with
`EffectPathClass::GatedShell`. Update the effect-path enumeration test to
include the new path name.
- In `crates/openspine-kernel/src/action_catalog_data.rs`, add an
`ActionEgressDeclaration { output_channels: None, egress_class: None }` entry
for the new id, since erasure is a local effect, not a network egress.
- Do not add the action to any dark-window allowlist or delegation descriptor in
`action_catalog_contracts.rs`; this omission keeps it fail-closed and
non-delegable.
- Extract the shared root-owner grant check: move the body of
`require_root_owner_grant` from
`crates/openspine-kernel/src/api/overlay_export_restore.rs` into a shared
location under `crates/openspine-kernel/src/api/` (for example a small helper
module). Keep all four checks identical: owner principal match, true root grant
with no delegation hops, non-delegable classification, and exact
`effectively_allows`. Update `overlay_export_restore.rs` to call the shared
helper so its behavior is unchanged. Keep error messages action-agnostic, or
pass the action label so messages stay descriptive.
- Create `crates/openspine-kernel/src/api/erase_counterparty.rs`. Define a
`#[serde(deny_unknown_fields)]` payload struct with a single `counterparty_id:
String` field, and a `parse_payload` function that folds all decode failures to
`DispatchError::BadRequest` with a static message. Parse `counterparty_id` with
`Ulid::from_str`, mapping failure to `DispatchError::BadRequest("counterparty_id
is not a valid id")`, following the API-layer ULID convention.
- Implement `handle_erase_counterparty` matching the `ActionHandler` fn-pointer
signature. Assert the action id equals `"openspine.counterparty.erase"`. Call
the shared root-owner grant check. Reject `SYSTEM_SCOPE` as a
`DispatchError::BadRequest` for defense in depth (`erase_counterparty` also
rejects it).
- Access `state.store`, `state.artifacts`, and `state.overlay_operations`
directly, and call `erase_counterparty(store, artifacts, operations,
counterparty_id)`.
- Return a JSON `Value` with only the non-sensitive fields from `ErasureReport`:
`derived_artifacts_invalidated`, `key_deleted`, and `ledger_sequence`. Do not
return `invalidated_identities` content, to avoid leaking learned-artifact
detail in the response.
- Declare `pub(crate) mod erase_counterparty;` in
`crates/openspine-kernel/src/api/mod.rs`, and register the handler in
`crates/openspine-kernel/src/api/handler_registry.rs` with a `use` import plus
`map.insert("openspine.counterparty.erase", handle_erase_counterparty as
ActionHandler)`.
- Add `openspine.counterparty.erase` to
`artifacts/lyra/packs/owner_control_basic_pack.yaml` and
`artifacts/lyra/agents/main_assistant_agent.yaml`, mirroring how
`openspine.overlay.export` / `openspine.overlay.restore` are listed, so an
owner-composed root grant `effectively_allows` the action.
===============================================================================

Task: 3

Implement this phase by adding tests that prove the standing-rule erasure sweep
through the new handler, plus authorization negative tests.

- Add tests in `crates/openspine-kernel/src/api/erase_counterparty.rs` behind
`#[cfg(test)] #[path = "erase_counterparty_tests.rs"] mod tests;`, or use an
inline test module if the file stays under 500 lines. Create the paired
`crates/openspine-kernel/src/api/erase_counterparty_tests.rs` if a split is
needed.
- Add a caller-level test named to parallel the store-level test, for example
`owner_review_created_scoped_rule_is_revoked_on_counterparty_erasure_caller_level`.
Build `AppState` via `crate::test_support::fixtures`. Seed a learned artifact
and an active scoped standing rule bound to a target counterparty, plus a
control rule bound to an unrelated counterparty.
- Mint a root, non-delegable-classified owner `TaskGrant` for the action,
following the `mint_grant` / `mint_composed_owner_grant` pattern in
`api/overlay_export_restore.rs`.
- Call `handle_erase_counterparty` directly with
`crate::test_support::owner_surface_for(...)` and a JSON payload containing the
target `counterparty_id`.
- Assert post-erasure state as in `counterparty_erasure_runtime_tests.rs`: the
target rule's DB row has `status = 'revoked'`, `active_standing_rule_for_action`
returns `None` for it, and `consult_standing_rule_gate` no longer matches or
allows. Assert the control rule stays unaffected. Assert `verify_audit_chain()`
still passes and exactly one `counterparty.erased` audit event exists.
- Add negative tests mirroring the overlay export/restore negatives: foreign
principal rejected, non-root or delegated-hop grant rejected, owner-derived
worker grant rejected, wrong action id rejected, malformed or unknown-field
payload rejected, invalid ULID rejected, and `SYSTEM_SCOPE` rejected.
- If a `test: <name>` row is added to `docs/threat-claims.md` for the erasure
guard, name a real landing test so `scripts/check-claims.sh` passes.

💡 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

#95 - feat(kernel): standing rules (AD-010/106/013/012, D-107) [merged]
#102 - feat(kernel): implement counterparty key model [merged]
#103 - chore(openspec): archive implement-counterparty-key-model [merged]
#164 - feat(kernel): bound dark-window exceptions so silence cannot amplify authority (#135) [merged]
#167 - Make reusable-authority evaluation proposal-specific [merged]

---

📝 Issue Planner

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

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

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

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[George-RD]

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