Repository navigation
docs: the whole-repo self-scan criterion cannot be met - docs/PATTERN-CATALOGUE.md self-matches PI001 and PI031 (standing since Phase 3) #171
Description
The pattern-library skill, and every Phase 5 pattern plan, require the whole-repo self-scan to return [] outside examples/, patterns/, tests/ and tools/. It does not, and has not for three milestones. Measured at every wave of Phase 5 and again at close-out:
[('./docs/PATTERN-CATALOGUE.md', 77, 'PI001'), ('./docs/PATTERN-CATALOGUE.md', 890, 'PI031')]
Why it matters: the criterion is unsatisfiable, so every wave reports a deviation for a condition nobody intends to fix in-flight. That trains executors to treat a failed self-scan as expected noise, which is how a real new finding would get waved through.
Root cause: docs/PATTERN-CATALOGUE.md is generated from the pattern library, so it reproduces each pattern's example verbatim, including PI001's and PI031's. It is the same self-reference as docs/DETECTION-BACKLOG.md (fixed with code spans), except that this file is generated and cannot be hand-edited.
Fix shape (one of): exclude the generated catalogue from the self-scan the way .planning/** is excluded; or have the generator emit example values inside code spans (the only option that keeps the catalogue honest and the gate strict); or accept the two findings in .github/code-scanning-baseline.json and restate the criterion as "no new findings beyond the accepted baseline". Phase 5 close-out restated the criterion that way for its own record.
Filed at the close-out of Phase 5 (CAT-03, #35), plan 05-07 Task 2, from .planning/phases/05-persistence-lifecycle-hijack-cat-03-35/deferred-items.md. Nothing here is fixed in v0.2.0.
Activity
hermanngeorge15 commentedon Oct 22, 2026
Still reproducing on released v0.2.0 (
main@edec71c), unchanged and still exactly two findings:One thing worth recording, because it makes this easy to mis-close: the repo's two self-scan gates now disagree, and only one of them is red.
code-scanning.yml, which runs with--baseline .github/code-scanning-baseline.json) reports 0 findings. Both catalogue findings are accepted baseline entries — I verified they are the only twoPATTERN-CATALOGUEentries in the baseline, and they are identical onmainand on PR feat: add PI114-PI118 multilingual evasion patterns #197.pattern-libraryskill criterion is a raw scan with no baseline, so it still returns the two findings above and is still unsatisfiable, exactly as filed.So anyone glancing at green CI will conclude this is fixed. It is not — the baseline is what is green, and the criterion the pattern plans actually quote is still failing. That is precisely the "trains executors to treat a failed self-scan as expected noise" risk in the original report, now with a green badge reinforcing it.
Of the two fix shapes proposed, the first is the one consistent with existing practice: exclude the generated catalogue from the raw criterion the way
.planning/**is already excluded incode-scanning.yml. That keeps the generator untouched and makes the two gates agree. The alternative — teaching the generator to emit the examples inside code spans, asdocs/DETECTION-BACKLOG.mddoes — would fix it at the source but changes generated output for all 79 patterns.Either way the valuable part is cheap: make the skill's criterion and the CI gate use the same exclusion set, so a genuinely new finding cannot hide behind an expected one.
hermanngeorge15 commentedon Oct 24, 2026
Launch-plan note (#211): this is why the demo recording (#206) runs in a scratch repository rather than at this repo's root. Verified today:
injection-scanner check . --quietonmainexits 1 and also prints threestructural config pass skippedwarnings for.planning/archive/...summaries with invalid frontmatter. Not a launch blocker; left as is.