fix(llm-security): golden gate - coverage block measured something else

The `coverage` block never looked at the 61 hook invocations. It probed every
payload STRING against every injection regex in-process, so `47/83` meant
"if you threw all 61 strings at all 83 patterns, 47 would match" - not "the
reference run exercised 47". The pre-bash-destructive payloads never reach
injection-patterns at all, yet their strings were in the probe set and could
mark a pattern exercised.

That number was asserted as reference-run coverage in three places that
instruct a future session: tests/golden/README.md, the STATE golden-gate
section, and the generator's summary line. In a repo whose v7.8.2 lesson was
"the check reported success without running", a figure that measures one
thing while labelled another is the same defect wearing a different hat.

Relabelled rather than re-measured - the probe still honestly bounds the gate
(an unreachable pattern is one the corpus cannot protect under ANY
attribution), it just has to say what it is:

  coverage.kind = 'static-reachability', with the caveat in a `note` field.
  patternsExercised  -> patternsReachable
  uncoveredPatterns  -> unreachablePatterns
  tablesExercised    -> corpusContains  (a payload CONTAINS a homoglyph; it
                        does not say the run folded one)

The gate now pins both the `kind` and the note, so the honest label cannot be
dropped quietly by a later edit.

Also surfaced the gap the old wording hid: the four OWASP maps have NO
behavioural coverage - they are scanner-side and no hook in this corpus
reaches them. They are precisely the tables the dump was widened to cover, so
the table digest is their only protection. Stated in the README next to the
47/83 line, where a reader was previously left to infer the reference run
backed them.

Flakiness check for the new gate (61 sequential spawns, ~12s, the most
process-heavy file in the suite, added to a suite npm test runs concurrently):
three consecutive full runs, 2053/2053, 0 fail. The three known
timing-sensitive files did not destabilise.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BB4vXvwvtW4dxbPRd6vsez
This commit is contained in:
Kjell Tore Guttormsen 2026-08-09 13:06:45 +02:00
commit 2fe29152b3
5 changed files with 87 additions and 37 deletions

View file

@ -2,9 +2,11 @@
"artifact": "golden-reference-run",
"schema": 1,
"coverage": {
"kind": "static-reachability",
"note": "Payload strings probed against patterns in-process. NOT a measurement of what the 61 hook invocations evaluated — pre-bash-destructive payloads never reach injection-patterns yet are in the probe set. The four OWASP maps are scanner-side and have no behavioural coverage here at all; their only protection is the table digest.",
"patternsTotal": 83,
"patternsExercised": 47,
"uncoveredPatterns": [
"patternsReachable": 47,
"unreachablePatterns": [
"CRITICAL_PATTERNS[5]",
"CRITICAL_PATTERNS[8]",
"CRITICAL_PATTERNS[15]",
@ -42,9 +44,9 @@
"HYBRID_PATTERNS[1]",
"HYBRID_PATTERNS[7]"
],
"tablesExercised": {
"HOMOGLYPH_MAP": true,
"normalizeForScan": true
"corpusContains": {
"homoglyphChars": true,
"payloadsAlteredByNormalize": 5
}
},
"summary": {