Originally created by: fu351
Fixes weak-path secret-detector false positives on identifiers, paths, UUIDs/digests, and word+number build tags, and hardens SecretLeakageRule so a bad edit can no longer brick it.
possible_high_entropy_secret fired on benign shapes because the heuristic keys on Shannon entropy per character — which measures alphabet variety, not randomness. An ordinary identifier, a relative path, a UUID, or a tag like py311 sits in the same 3.6–4.5 bits/char band as a short base64 token. Measured at roughly 6:1 false positives in the field (the alert-fatigue source that trains a human to approve without reading), and through the host-hook taint ledger a single UUID-bearing scratch path could gate a whole session's egress.
/_.--split segment is a word, a number, a short length-capped word+number atom, or a digest/UUID id. A long base64/JWT segment fails, so the token is judged whole — no secret is fragmented below the length floor./ carve-out. On egress the identifier exemption is withheld for a word-joined token (a passphrase has the same shape) but kept for a /-bearing one, since a filesystem path, URL path, or git ref is not a passphrase — which stops every gh api call and branch ref from prompting on a push.SecretLeakageRule runs an invariant self-check at import; if it fails, the rule degrades to a fail-closed AUTH (never PASS) instead of raising rule_error on every action.evaluate() is a total wrapper: it never raises and never mutates the action (idempotent).tests/unit/test_secrets_compound_token_fp.py — FP shapes, recall guards, egress asymmetry, self-check + degradation + idempotency. Existing test_rule_secrets, test_secrets_identifier_fp, test_secrets_bare_token_fp remain green.
README → Known limitations (hex floor 40 → 32, the new exemption and its measured cost) and CHANGELOG → Unreleased.
🤖 Generated with Claude Code
Ticket changed by: fu351