hygiene(tick-history): 2026-05-03T03:54Z — v0.5 review-cycle (8 findings hardened)

docs/hygiene-history/ticks/2026/05/03/0354Z.md

@@ -0,0 +1 @@
+| 2026-05-03T03:54:00Z | opus-4-7 / autonomous-loop continuation | a2e2cc3a | **v0.5 PR #1298 review-cycle: 8 substantive findings + markdownlint failure addressed.** Cycle worked: refresh post-#1294/#1297/#1296 + #1300 still wait-ci revealed #1298 (v0.5 existence-drift) had 8 threads + 1 failed CI check. ALL 8 findings were substantive (no stale): (1) P1 restrict candidate roots to repo-root (security: don't probe /etc/, /tmp/); (2) P2 'deliverable' marker too broad (removed bare match; kept narrower variants); (3) reason includes absolute paths (now uses repo-relative; logs no longer leak local/CI paths); (4) duplicate candidate-root comment block (collapsed to single coherent comment); (5) tests don't cover checkFile (added 5 new tests: missing-path, ok=false on missing input, ok=false on directory, clean-file, future-state exempts); (6) markdownlint MD032 (added blank line before list); (7) README intro stale ("one class" → "two of seven"); (8) statExists treats any error as missing (now distinguishes ENOENT vs EACCES/EPERM; unreadable claims don't false-positive). Markdownlint failure was the same MD032 issue. Tests now 22 (up from 17 in initial v0.5); 38 total in dir, all pass. Retroactive eval still 7/49 drift rate. **Pattern observation**: substantive code-review findings on a 200-line TS tool produced 8 high-quality fixes — code review on this codebase is rigorous + the substrate-claim-checker now ships much more robust v0.5. The hardening cycle is itself worked-example data for verify-then-claim discipline applied to my own tool authoring. | #1298 (v0.5 hardened) wait-ci on rebuild, 8 threads resolved + auto-merge armed; #1300 (tick 0349Z) wait-ci, auto-merge armed; #1294 + #1297 + #1299 MERGED | This tick teaches **code-review-as-substrate-quality-amplifier**: 8 substantive findings on a 200-line TS file means review is genuinely catching things at every layer (security, correctness, test coverage, documentation, error handling, false-positive class boundaries). The hardening adds defensive properties (repo-root-bounded probing, ENOENT-vs-other-error distinction, relative-path logs, blank-line markdownlint compliance) that wouldn't have surfaced from author-only inspection. Ottos's principle-strong + specific-weak pattern shows up here too: I had the principles right (existence-drift sub-class, future-state markers, candidate-root resolution) but missed the specific-implementation details (security boundaries, error-type distinction, relative-path discipline). Reviewer caught all of them. |