summercms/.planning/debug/resolved/phase9-verification-stale-loop.md

status, trigger, created, updated

status	trigger	created	updated
resolved	I already did that execute 9 like 3 times and gsd-progress still talks about it, wtf	2026-09-28T00:00:00+02:00	2026-10-05T15:08:52Z

DEBUG: Phase 9 verification stale loop

Discovered: 2026-09-28 during $gsd-progress Status: resolved Goal: stop gsd-progress routing back to Phase 9 after execute-phase 09

Symptoms

• $gsd-progress kept routing to $gsd-execute-phase 09 with verification.status=stale
• execute-phase 09 had already been run several times
• No separate error; the progress report simply named Phase 9 again

Root Cause (two layers)

Layer 1 (2026-09-28, fixed in 1a878b3): Phase 10.2 commit 5e50b16 moved 42 Phase 9-covered files under modules/. 09-VERIFICATION.md still listed the old top-level paths, so computeCoveredDigest returned null and status was always stale.

Layer 2 (2026-10-05, the remaining loop): After the paths were corrected and the report passed at HEAD ba1aaef (9692315), Phases 12.1, 12.2, 13 and 14 edited 25 of those same files (+3294/-217). The fingerprint then mismatched current bytes. That is GSD working as designed — later work on shared modules re-stales an earlier phase — not a missing-path bug. Progress always routes to the lowest-numbered incomplete phase, so 09 stayed in front of the later-phase queue.

Fix

1. Confirmed every declared covered_files path exists (0 missing).
2. Ran scripts/check-phase9.sh --all at summercms.go 104a1c9 / fonoteka.go 93b8b75 — passed.
3. Recomputed covered_digest to v2:sha256:c2f48f6ce04a5eed4788d745da45b1c1555a769df4feebfe88b9bbf671b634fb and recorded the re-verification in 09-VERIFICATION.md.

Verification

gsd_run query verification.status on the Phase 9 directory returns passed.

Note

Phases 10, 10.1, 10.2, 11, 11.1, 11.2 and 12 can still read stale for the same digest-drift reason. Closing 09 only unblocks the first slot of that cascade.