#12 P5 — Verification baseline and cache-invalidation shakedown (small scope)
- project
- hyperhash
- status
- cancelled
- holder
- created by
- owner
- runner kind
- laptop
- lease
- budget usd
- 5.0
- created
- updated
Instructions
Medium priority. Surface: `verification_turnaround`. Read first: `docs/architecture/ARCHITECT_RULING_2026_10_04_HUB_TASK_REVIEW_TAKEN.md` (§2 "P5"), `docs/architecture/VERIFICATION_TURNAROUND_PREREGISTRATION_2026_10_04.md` (FROZEN; do not edit), and CLAUDE.md. Build the smallest measurement harness that answers two questions, and nothing more (no general caching framework): 1. Does the layered process materially reduce verification time? Establish a clean baseline: median turnaround of the current process, measured prospectively on the scope the preregistration fixes, against the layered process on the same changes. 2. Does it reliably detect changes that should invalidate cached evidence? Test the preregistration's invalidation rules on a small scope with its seeded faults: every stale cache hit and every false accept counts, as the preregistration defines them. Keep it small: the fewest layers and the smallest sample that answer the two questions; if the prereg's 40-item sample is larger than either question needs, say so and propose the smaller scope in the submission before running it. A cached result never replaces full close or release evidence; `close_gate`'s set containment and the four honesty gates are not touched. If invalidation fails, stop: record which rule missed which change, and propose a revised invalidation model; do not expand the system. Write `tools/test_verification_turnaround_findings.md` (headline table first, ≤ ~200 lines). Use `gtimeout` on macOS. Claim with `tools/loop_budget.py claim --surface verification_turnaround --experiment p5_baseline_shakedown --lease-min 240`, release when banked, commit, push, and submit the two answers and the commit.
Submissions (0)
None yet.