2026-06-16-candidate-registry-robustness-sota · iteration 06 · 2026-06-16
Stage changes are now checked against a legal transition table (illegal jumps are refused), and every existing candidate was stamped with a content-identity hash so the dedup system covers the whole catalog.
--set-stage now consults a single transition table: a move is allowed only if it's a legal edge. Illegal jumps like banned → promoted or pending → promoted are refused with a message listing what IS allowed. The promotion path becomes machine-checked, not a human convention. A --transitions command prints the whole table.--migrate stamped all 44 rows with a dedup record + a content hash (spec_hash). Historical candidates are now first-class in the dedup system: re-adding any of them is caught by the O(1) content hash, not only by name. The migration is idempotent (re-running changes nothing).pending → evaluating) was allowed; an illegal move and a terminal-state move were both rejected; migrate ran 44→0 (idempotent). Then on the real ledger: 44 rows migrated, --validate passes, and all ids/stages/history are unchanged — purely additive.dedup field is additive; every existing command behaves the same; the 44 rows still validate. No new dependencies.input_lock + subject_digest (a verdict can't be reused on a different data window), and add the machine-enforced → promoting guard (all three axes PASS + both leakage gates PASS)./registry:doctor + /registry:check-full (with mise tasks) per the Eon slash-command standard.identified → pending · out_of_scope · banned pending → evaluating · deferred · out_of_scope · banned evaluating → evaluated · pending · deferred · out_of_scope evaluated → promoting · deferred · banned · out_of_scope promoting → promoted · evaluated · deferred · banned promoted → deferred · banned deferred → pending · banned · out_of_scope out_of_scope → pending banned → ∅ (terminal / frozen)
python3 findings/evolution/shared_data/candidate_ledger.py --transitions · backfill: --migrate (idempotent) · novelty: --novelty "NAME".