The open question was recorded as "19 entries here against the guard's 25,
cut at different granularity". Measured at a pinned tag, that premise does
not hold: commons ported llm-security's `hooks/scripts/pre-edit-secrets.mjs`
(19 entries, name + pattern only), the guard ported its
`knowledge/secrets-patterns.md` (33 entries, ids + severity + FP notes) and
took 25 of them. Two seeds, not two cuts.
The guard's docstring asserting the second seed was not relayed - the file
was read at the pinned commit and all 25 guard ids are in it verbatim.
Beyond the count, three things a membership table would have hidden:
- Match semantics disagree. Commons declares first-match-wins with normative
ordering and a load-bearing last entry; the guard reports every match. One
Bearer-plus-JWT witness: one label vs two.
- Only 2 of 19 patterns are byte-identical across the two sides. The pair
earlier called the clean 1:1 (AWS access key) is not one of them.
- The guard suppresses placeholder and variable-reference values; commons has
no field that could carry that, because its seed carries none.
Membership diverges both ways and neither port is at fault - the seeds
disagree. Reported, not fixed, per the behaviour-preservation invariant.
No id is proposed: that is the carrier rule, and both runtimes are asked
first. manifest.json is untouched.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UFforUbBA7GnUYijg78kpK
Kjell Tore Guttormsen
2d9ee9c434