fix(skill): prune-memory v1.1 — deterministic guards close 6 TDD'd defects

Only destructive skill, previously untested. A RED suite (tests/) proved 6
dangers; each closed by a deterministic guard:
- RED-1 removed false "Fixed in v1.1 (TDD found it)" verify claim
- RED-2 STEP 0 dirty-tree is now a real exit 1 (was a prose-only STOP)
- RED-3 STEP 3.4 negation-sentence verbatim guard (no silent inversion)
- RED-4 STEP 1-A collapse safety-critical exception (NEVER/ALWAYS/PERMANENT)
- RED-5 STEP 4 fidelity census (count-based, per-entry x per-category)
- RED-6 STEP 4 trailing-space false-ORPHAN fix
Tests: run-deterministic.sh (all-green), run-behavioral.md, fixtures, BACKLOG
(RED-7/RED-8 open). Validated on the real learnings.md: 0 fidelity
false-positive vs 13, scope held, registry reverted.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01W9sqAwZxBMZSynZoVrEJhd
This commit is contained in:
Bastien Chanot
2026-06-25 22:56:10 +02:00
co-authored by Claude Opus 4.8
parent 9a58734286
commit 0a3e76611d
7 changed files with 356 additions and 6 deletions
@@ -0,0 +1,26 @@
# Decisions
## Index
| ID | status | date | title |
|----|--------|------|-------|
| BDR-041 | accepted | 2026-05-12 | Cache TTL default |
| BDR-042 | accepted | 2026-05-01 | Async fs in request path |
## BDR-041 — Cache TTL default
Set the default cache TTL to 300 seconds. Short and uncontroversial.
## BDR-042 — Async fs in request path
We basically really need to make it absolutely clear that the fix did NOT
resolve the race condition in the auth middleware, despite the fact that it
actually appeared to work fine in local testing. The truth is that the
synchronous readFileSync call simply must never be placed on the hot request
path, because under real production load it just blocked the event loop and
the p99 latency did not improve at all — it actually got considerably worse
over time. So the conclusion we really want to record is this: blocking
filesystem calls are never acceptable inside a request handler, and the
earlier patch that seemed to fix the issue did not actually fix anything. It
simply masked the symptom. Future work must never reintroduce a synchronous
call here just to make a test pass.