Michael Freno 8990a94321 fix: a finished all-run is not a run to resume ...

`/pygienium-all` loaded the previous run-state and skipped every check
whose entry was terminal, so a second invocation dispatched nothing at
all. The one check that did run was whichever an interrupted run had
left non-terminal — registry order made that `comments`, which read as
"comments ran, everything after it was skipped".

Resumability belongs to unfinished work: continue only when the stored
run is not complete (`in_progress`, `partial`, `failed`), so completed
checks are carried forward cheaply and the interrupted one picks up
where it stopped. A completed run means the next invocation is a new
scan, which is what the command name promises; `--fresh` and
`/pygienium-resume` keep their explicit jobs.

Settle a terminal check's phases on the way past too: an interrupted run
can leave a phase `in_progress` behind a check that reads `complete`,
which made the state claim both finished and still running.

Tests: reverted src/ fails "a completed run is not resumed", "settles a
phase an interrupted run left in_progress", and the integration test "an
unfinished run-state is continued, not restarted"; all pass with the
fix. Suite 164 pass, 1 pre-existing worktree-only failure (MISC-46).
bun run typecheck clean; port-to-omp regenerates and typechecks.

MISC-47

Co-Authored-By: nw-flash-flex <noreply@neuralwatt.com>

2026-10-20 23:29:01 -04:00

6.2 KiB

Raw Blame History

View Raw