persistence sweep: renumber proposed findings R-159..R-162 (R-158 collided mid-session)
The register grep that put these at R-158..R-161 was true when run and stale within hours: the parallel session pushed SPIKE-recovery-unit-space-2026-08-02.md and CAMPAIGN-10-closeout-2026-08-02.md mid-run, both using R-158 for an unrelated finding, and neither files it — ROADMAP.md and OPEN-ITEMS.md still stop at R-155. So two sessions minted the same number for different findings on the same day, which is the exact failure §8.0 was already documenting about R-154/R-155 and R-156/R-157. Now recorded with itself as the third instance. R-156, R-157 and R-158 are all live in audit documents and none is filed.
This commit is contained in:
@@ -31,7 +31,7 @@ demonstration of R-156 and of its fix. 41 fixture tests driving `check()` (the f
|
||||
calls); every rule red-proofed.
|
||||
|
||||
Registered in `CLAUDE.md` and `REUSE.md`. **Enforcement is convention, not CI** — the catalog repo
|
||||
has no CI of any kind. Raising that is proposed as R-160.
|
||||
has no CI of any kind. Raising that is proposed as R-161.
|
||||
|
||||
## Method notes worth carrying forward
|
||||
|
||||
|
||||
Reference in New Issue
Block a user