ho-06.7 — Delete: the missing destructive verb

Build the verb the app was missing. A user cannot delete a scope or a shared entry from anywhere — not the Workshop, not the CLI, and — the real gap — not SharibakoCore. The system design commits that "deletion is always an explicit user action and only ever touches the vault" (kamae-2, line 174), but the Vault Core operation that sentence describes was never among ho-01's nine. The only path today is hand-deleting a directory inside the vault and committing it by hand — exactly the raw-filesystem surgery the app exists to spare its user.

This ho adds one destructive capability across all three surfaces at once:

• SharibakoCore — deleteScope and deleteSharedEntry, the tenth and eleventh vault operations, filesystem-only (they decrypt nothing).
• CLI — a sharibako delete verb over both, following clean's confirmation discipline.
• Workshop — a Delete Scope affordance in the action panel, wired to the pālana rust token — the first real in-window consumer of the destructive voice ho-06.4 reserved and ho-06.5 could find no home for.

This surfaced as the ho-06.5 gate's owed finding. It is new vault behavior, not chrome — which is why it is its own ho and not part of 06.5.

Out of scope:

• The GUI delete-shared affordance. No surface in the Workshop lists shared entries yet — the shared-secret browser is ho-07. Core and CLI delete shared entries this ho; the Workshop affordance for it rides ho-07 when there is a shared list to attach it to. Named as a deferred boundary, not skipped.
• Cascade-unlink convenience. --force orphans linked entries; it does not auto-convert linkers back to local values. The clean path is unlink first (it already preserves the value locally); --force is the escape hatch.
• History scrubbing. A deleted secret remains in git history and is recoverable — consistent with the threat model, not a leak (SECURITY.md already treats git-as-backup as accepting historical ciphertext).
• Auto-commit. Deletion writes the working tree; sync commits it, on the user's existing commit boundary. No new git behavior.
• Marker or materialized-.env removal. Deletion only touches the vault (Decision 3).

Phase 1 — Think

Six decisions. Five were ratified with the practitioner before authoring; the sixth (CLI surface shape) follows the established list [--shared] idiom and is logged for the record.

Decision 1 — Two Core verbs, filesystem-only, no crypto

deleteScope(_ id:) and deleteSharedEntry(_ id:force:) join VaultCore. Neither decrypts anything — a scope directory and a shared/<id>.age file are removed as files, not read. Both are reachable through VaultCore.init(vaultURL:) (the keyless initializer, line 42) — the same no-identity path link and unlink-adjacent filesystem work already uses. Deletion never acquires an age key, which is what makes Decision 4's "confirmation, not Touch ID" honest at the Core boundary: there is no key to gate on.

deleteScope removes scopes/<id>/ and its entire contents (scope.yaml, every <KEY>.age, every <KEY>.link). A scope's own .link files are pointers; they vanish with the scope and touch nothing in shared/. Absent scope → the existing scopeNotFound. Identifier validation is free — it rides VaultLayout's single path-building chokepoint, same as every other scope operation.

Decision 2 — Shared-delete linker guard: refuse by default, --force to orphan

Deleting a shared entry that other scopes link to is the one case with real blast radius, and the existing linkGraph() already answers "who links this." deleteSharedEntry computes the linkers; if any exist and force is false, it throws a new VaultError.sharedEntryLinked(id:, linkers:) naming every (scope, key) pair and removes nothing. With force: true, it removes the shared entry and leaves the linkers as dangling .link files — the explicit orphaning the practitioner ratified. Those dangling links surface through the machinery that already exists for it (linkTargetMissing on resolution, the heal/orphan surfaces). No cascade, no silent cleanup — the design's "deletion is always explicit" holds at the sharpest edge.

Decision 3 — Blast radius: only the vault

Restated from kamae-2 line 174 so the executing agent carries it without the system design open:

Decision 4 — Gating: confirmation, not Touch ID

Deletion is a mutation, not a reveal — it decrypts nothing — so it does not prompt for biometry. The gate is explicit confirmation, matching how the design gates on value-reveal, not on mutation. CLI: a mandatory confirm prompt unless --yes, erroring if stdin is not a TTY and --yes is absent, exactly CleanCommand's pattern (exit 130 on decline). GUI: a system confirmation dialog naming what will be removed.

Decision 5 — GUI: scope-delete only, rust's first in-window consumer

The Workshop sidebar lists scopes, so Delete Scope has a natural home — a destructive action in the panel's scope group. This is the first real in-window destructive affordance in the app, and it consumes Color.drift (pālana rust), closing the gap ho-06.4 flagged and ho-06.5 confirmed had no consumer. The ho-06.5 gate proved the precise boundary: an in-window control can wear rust; the confirmation dialog cannot (dialogs render out of the view hierarchy, take no tint, and paint the system's own destructive red). So the panel button reads rust; the confirm dialog stays fully system-rendered. No workaround attempted — that was settled empirically at the 06.5 gate.

Deleting a shared entry from the GUI has no surface to attach to (there is no shared-entry list in the Workshop until ho-07). It defers there, named in Out of scope. Core and CLI carry full shared-delete this ho.

Decision 7 — Per-key deletion folded in (scope widened mid-build)

The ratified scope was scope + shared deletion. Dogfooding the built app surfaced the same gap one level down — no way to delete a single secret within a scope, on any surface. Rather than close 06.7 and open a near-identical follow-up, the practitioner folded per-key deletion into this ho (a deliberate scope widening, recorded here, not a quiet edit). It reuses every decision above: VaultCore.deleteSecret(_:inScope:) (keyless — removes the key's .age or .link; deleting a link drops only the pointer, the shared entry is untouched), sharibako delete <scope> <key> (optional second positional, same confirmation), and a rust-toned Delete Secret button in the detail pane raising the same system-rendered confirm dialog. The three Core deletion verbs moved to VaultCore+Deletion.swift (the additions crossed SwiftLint's body-length ceiling; split by extension per the VaultCore+Encryption precedent).

Decision 6 — CLI surface: one delete verb, --shared flag

A single sharibako delete <id> command, with --shared selecting the shared pool (mirroring list [--shared]), --yes to skip confirmation, and --force to orphan linked shared entries. One verb, not a delete scope / delete shared subcommand pair — the flag idiom is already the project's convention for the scope/shared split.

Discovery (deferred to execution)

• Confirmation copy. The exact prompt/dialog wording that names the blast radius plainly (and, for shared, the linker count). Execution-level.
• Exit-code mapping for sharedEntryLinked. Whether it reuses the user-error code or earns its own; an ErrorReporter/ExitCode find.
• Where the Delete Scope button sits in the panel scope group, and how its disabled state reads (no scope selected / model.activity). Execution-level, following the existing panel-verb pattern.