forked from bchanot/claude
Bastien Chanot
5e19419981
New T18-T20 in lib/tests/config-protection.test.sh (+4 assertions,
20→24). T18 Write payload, T19 MultiEdit payload → both exit 2 (pass
trivially today — the extraction is tool-name-agnostic — but lock
against a future narrowing to Edit-only; stated honestly, per report).
T20 sentinel containing ONLY whitespace bytes (" \n\t", not literally
empty) → exit 2 AND consumed — exercises config-protection.sh:44-46's
`grep -q '[^[:space:]]'` check specifically, which the pre-existing
T17 (zero-byte file) doesn't reach. Closes J4-07 (WEAK): every payload
in this suite said "Edit", so a future Edit-only narrowing (or a
weaker sentinel-emptiness check) would have failed open with no red.
DOUBLY GATED per report §3.5 (edits config-protection's own test) +
user's stated exception (STOP and show the exact draft before writing,
even though the formal AUTHORIZATION line said AUTHORIZED) — drafted
inline, user confirmed "proceed as drafted" before the sentinel/edit.
Mutations (lean scratch copy — only hooks/config-protection.sh + this
test file, not the whole repo/.git), one at a time, each reverted
before the next:
- T18/T19: gated the file_path extraction on `tool_name == "Edit"`
(python3 tool_name check + if/else) → both red alone, everything
else (incl. T1-T17) unaffected.
- T20: swapped the whitespace-aware `grep -q '[^[:space:]]'` for
`[ -n "$reason" ]` (byte-count only) → T20 reds alone; T17 (the
zero-byte case) stays green either way, confirming T20 tests
something T17 structurally cannot.
GREEN: real repo unmutated, 24/24 passed, shellcheck clean.