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:
2026-08-02 12:24:48 +02:00
parent acb44672fd
commit 6d45b60f94
2 changed files with 19 additions and 5 deletions
+1 -1
View File
@@ -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