fix(health): fsck survives approved delete proposals

[galuis116]

What changed

_check_decided_proposals in src/vouch/health.py now handles
ProposalKind.DELETE proposals in a dedicated first pass instead of
indexing a presence dict that has no entry for that kind.

Why

presence was keyed by ProposalKind for the four artifact kinds
(CLAIM/PAGE/ENTITY/RELATION), and every approved proposal was
looked up by presence[pr.kind]. But propose_delete() files proposals
with kind=ProposalKind.DELETE, and approve() explicitly allows a
DELETE proposal to clear without its target artifact pre-existing
(it's being removed, not created). Any approved delete proposal reaching
this loop hit presence[ProposalKind.DELETE] → uncaught KeyError,
aborting fsck() entirely — and vouch fsck's CLI entry has no
exception handling around the call, so the command itself crashed.
Confirmed end-to-end: approve a claim, then approve a delete of it, then
call health.fsck(store) — raises.

Delete proposals are now checked against target_kind (the kind of
what was deleted, not pr.kind, which is always DELETE):
decided_delete_invalid_target_kind if it's missing or unrecognized,
decided_delete_artifact_present if the target somehow still exists on
disk. A second pass then checks ordinary create/edit proposals, skipping
any artifact id a delete proposal legitimately removed — without that
exclusion, the original creating proposal (still recorded APPROVED
in decided/) false-positives as decided_missing_artifact the moment
its artifact is correctly deleted, which I hit and fixed while verifying
this change.

Fixes #682

What might break

Nothing for users with an existing .vouch/ directory — no on-disk
shape, kb.* method, or object model change. Behaviorally: vouch fsck
now runs to completion instead of crashing on any KB with an approved
delete in its history, and correctly reports zero findings for a
legitimate delete rather than either crashing or false-positiving.

VEP

Not applicable — no object model, kb.* method, on-disk layout, bundle
format, or audit-log shape change. A health-check logic fix inside
health.py.

Prior art

This exact defect and a fix were previously submitted as #538
(fix(health): fsck survives approved delete proposals,
CodeRabbit-reviewed, author addressed all review feedback) but closed
unmerged on 2026-07-29 purely for going stale against test (a
CHANGELOG.md conflict) — the maintainer's closing comment explicitly
invited a rebase or fresh PR. Re-verified independently against current
test HEAD: the crash is still live. This PR reintroduces the fix,
freshly rebased, with the additional false-positive fix for the
originating creation proposal.

Tests

• Local make check-equivalent: ruff clean (src + tests); mypy
  clean on health.py; all 26 tests/test_health.py cases pass (23
  pre-existing + 3 new)
• New / changed behaviour has a test —
  test_fsck_survives_approved_delete_proposal,
  test_fsck_flags_delete_whose_artifact_still_exists,
  test_fsck_flags_delete_with_invalid_target_kind
• CHANGELOG.md updated under ## [Unreleased]

[plind-junior]

the diagnosis is right, and the second-pass exclusion you found while verifying — skipping the ids a delete legitimately removed, so the original creating proposal does not false-positive as decided_missing_artifact — is the part that makes this a real fix rather than a crash patch. checking target_kind instead of pr.kind is correct.

but the fix is one kind short, and the same KeyError is still live on test today. ProposalKind has six members (models.py:485-491) — CLAIM, PAGE, ENTITY, RELATION, DELETE, GOAL — and presence is keyed on four. your first pass skips non-DELETE and your second pass skips DELETE, so an approved GOAL proposal falls through to deleted[pr.kind], which is built with the same four keys.

verified against current test:

pr = proposals.propose_goal(store, title="ship the thing", proposed_by="agent")
proposals.approve(store, pr.id, approved_by="reviewer")
health.fsck(store)

health.py:497: in _check_decided_proposals
    if artifact_id not in presence[pr.kind]:
E   KeyError: <ProposalKind.GOAL: 'goal'>

goal proposals are fully live — proposals.py:566 files them, :900 approves them, :1241 maps them to get_goal — so any KB that has approved one crashes vouch fsck exactly as an approved delete does. with this PR applied the crash just moves up two lines to deleted[pr.kind], since that lookup now runs first.

which points at the actual root cause: presence is a hand-maintained mapping over an enum that grows, with no guard tying the two together. adding GOAL alongside DELETE fixes today; the durable version is making the mapping exhaustive over ProposalKind and adding a test that walks every member — the same exhaustiveness pattern #692 uses for METHOD_SCOPES, where a new method with no entry fails the suite instead of failing a user. that would have caught this the day GOAL landed, and will catch the seventh kind.

happy to see this merge with GOAL handled and the exhaustiveness test added; the delete logic itself i have no objection to.

[plind-junior]

Check the comment above

[plind-junior]

closing this — the fix is one proposal kind short, and the PR's own new line is where the crash now lands.

ProposalKind has six members (models.py:485-491): CLAIM, PAGE, ENTITY, RELATION, DELETE, GOAL. presence is built over four of them. this PR's first pass skips non-DELETE and its second pass skips DELETE, so an approved GOAL proposal reaches deleted[pr.kind] at health.py:555 — and deleted is {k: set() for k in presence}, the same four keys. same KeyError, two lines earlier than before.

verified against current test:

pr = proposals.propose_goal(store, title="ship the thing", proposed_by="agent")
proposals.approve(store, pr.id, approved_by="reviewer")
health.fsck(store)

health.py:497: in _check_decided_proposals
    if artifact_id not in presence[pr.kind]:
E   KeyError: <ProposalKind.GOAL: 'goal'>

goals are fully live — proposals.py:566 files them, :900 approves them, :1241 maps them to get_goal — so vouch fsck crashes today on any KB with an approved goal, exactly as it does on an approved delete. this PR's title says "fsck survives approved delete proposals" and that much is true, but vouch fsck still does not survive decided/.

the delete logic itself is good and the second-pass exclusion you found while verifying — skipping ids a delete legitimately removed so the original creating proposal does not false-positive as decided_missing_artifact — is a genuine catch worth keeping.

what i want instead of a GOAL line added next to DELETE: the root cause is a hand-maintained mapping over an enum that grows, with nothing tying the two together. make presence exhaustive over ProposalKind and add a test that walks every member — the same shape #692 uses for METHOD_SCOPES, where a new method with no entry fails the suite instead of failing a user. that would have caught this the day GOAL landed, and it catches the seventh kind for free.

please reopen with that and i will merge it. this is a scope objection, not a quality one.

[galuis116]

reopening failed via the API for this branch, so opened fresh instead: #735 - same branch, GOAL added to presence per the review above, plus the exhaustiveness assert.