Guard universe audit — where every guard stops looking

Agent: read-only. Nothing in either repo was modified; no test suite was run. Method: every COUNT in this report was produced by readFileSync(f,"utf8") and matching in-process under node. No count came from grep. (§8b.5 — eight first-party files carry a NUL byte, which makes GNU grep print nothing and exit 0.)

Provenance at time of writing:

A writing agent is active in harness-main-v1. Two of my subagents observed integration HEAD as cebe0f4fcd29a8a34d9a06beafe4e0dee6742e7c — i.e. the writer committed during this audit. Every live-defect claim below carries the mtime of the file it rests on, and every harness claim was re-derived by me after the subagents reported. All the web claims rest on a clean tree at a single sha.

LADDER VERDICT (§0)

Rung reached: 5 (source scan) for essentially the entire guard estate — by construction. This audit produces no code, so the verdict here is about what the guards themselves reached and what is available to them. The finding is that rungs 1–4 were never unavailable; they were never attempted. Specifics are in §5.

• Rung 1 (physically impossible): unavailable to a test, but NOT unavailable to the system — a CSS build step that refuses to compile a hex literal, or a checked-in perf baseline, are both rung-1 answers that were skipped in favour of a scan.
• Rung 2 (unrepresentable): available and unused. The clearest case: tests/** in the web repo is in no tsconfig at all, so the 439 guard files are never typechecked — the guards are the least type-protected code in the repository.
• Rung 3 (unreachable by shape): available and unused. walk() returning string[] is why 105 guards cannot tell “clean” from “empty”.
• Rung 4 (runtime choke point): available, unused, and one line from existing — see §5.1.

0. THE HEADLINE

The thesis I was asked to test is confirmed, and it is now mechanical rather than rhetorical. Three independent measurements, each reproduced from bytes:

1. The cockpit token guard checks only the <style> block of .svelte files. 18 literal colours live in src/cockpit/** — 3 in .svelte outside <style>, 15 in .ts. Exactly the region the guard’s universe stops at. (§1.3)
2. The dead-token guard’s universe is the single hardcoded path src/styles/tokens.css. The repo has two token files. In the other one — src/cockpit/tokens.css, the larger at 925 lines — there are 18 dead tokens, including --t-3, the exact token a guard asserts exists. (§1.2, §2.1)
3. no-dead-css-selectors.test.ts contains a second test named “the scanner itself is precise” whose body is a loop over the findings array. Today that array is empty, so the test executes zero assertions — and it can only ever execute one in a state where the first test has already failed. It is structurally incapable of failing. (§3.2)

But the deeper result is not any of those three. It is this:

The single most consequential line in the entire guard estate is tests/helpers/source-scan.ts:68 — if (!existsSync(root)) return out;. 105 web guards call this walker. 72 of them assert no floor on what it returned. If a scanned directory is renamed, those 72 guards — holding 2,161 assertions — go green having read nothing. The same shape, hand-written, covers 13 harness guards and 244 more assertions.

That is not 85 separate bugs. It is one bug, in one line, inherited 85 times — and it is fixable at rung 4 by changing that line to throw.

1. THE EXCLUSION MAP

1.1 Inventory

I found guards in more places than the brief’s two directories. Searching by shape rather than path:

523 test files inventoried, 17,013 assertions. cockpit-tokens-owner.test.ts — the file the brief named — is in tests/cockpit/, which is why an audit scoped to tests/prevention/ would have declared it absent. That is the exclusion map applied to the audit itself.

Excluded with reason, not silently: experiments/, candidate/, large-codebases/, mutant-tests/, probes/, research/, detect-secrets/ are all gitignored forks or vendored trees, not this product’s source.

1.2 Exclusion by EXTENSION

Across all 439 web guard files, counting how many scan each extension:

Two .css files exist. src/styles/tokens.css (514 lines) is covered for deadness. src/cockpit/tokens.css (925 lines) is covered by no deadness guard at all — and it is the one holding the dead tokens.

A latent extension hole, honestly bounded. tests/helpers/source-scan.ts:32 exports SOURCE_EXTS = [".ts",".svelte",".mjs",".cjs",".js"], documented as “the single owner of the extension set so a new executable extension … auto-covers every prevention test that imports it (deny-by-default: a bypass cannot hide in a non-TS extension)”. But:

• walk()’s own default (source-scan.ts:65) is [".ts",".svelte"] — not SOURCE_EXTS.
• Only 3 guards import it: async-db-facade-owner.test.ts:37, db-transaction-owner.test.ts:27, no-raw-sql-outside-db.test.ts:36.
• 3 more re-declare the identical literal locally — centralized-config.test.ts:61, config-handler-dedup.test.ts:23, no-hardcoded-config-values.test.ts:49. That is a second source of truth for one question (§1): adding .mts to the declared owner silently fails to reach these three, and the docstring’s promise is already false for them.
• 31 guards rely on the default and therefore exclude .js/.mjs/.cjs.

Do not overstate this one. The currently-excluded population is 2 files (scripts/generate-pwa-icons.mjs, scripts/sd.mjs), neither under src/ or server/. The live defect here is the duplicated declaration, not a hidden bypass. The extension hole is latent, not exploited.

1.3 Exclusion by REGION — the confirmed defect

tests/cockpit/cockpit-tokens-owner.test.ts:31-38 defines the scanned region:

function styleBlock(src: string): string {
  const start = src.indexOf("<style");
  const end = src.indexOf("</style>");
  if (start === -1 || end === -1) return "";

Checks A (no literal colours), B (no literal durations) and F (no literal lengths) run on this substring only, over .svelte files only. So two regions are excluded where the invariant plainly still applies: the <script> block and template of a .svelte file, and every .ts file in src/cockpit/ (96 of them).

I re-ran the guard’s own findColorLiterals regex over exactly those excluded regions. 18 literal colours, all in the excluded regions, zero in the guarded region:

mtimes: categories.ts 2026-07-26 09:55, MicroSweep.svelte 2026-07-26 15:11, Spark.svelte 2026-07-26 13:08 — all older than HEAD 0c7e536, tree clean.

This reproduces the count the earlier audit reported (18), from an independent measurement, and establishes it is still open today. I am not claiming a new finding; I am closing the question of whether it was fixed. It was not.

The sharper framing nobody has applied. These are not merely style violations. Every one is a fallback: tokenColor(el, "--ink-4", "#4d545e") and fallbackDark: "#dc8b8b" are second sources of truth for a question the token file already answers. §5b prohibits exactly this — “THERE IS NO FALLBACK SOURCE … a fallback is a second source of truth for one question, and it will drift — and the drift is invisible precisely because the fallback only fires when the real source is missing, which is the moment nobody is looking.” A colour-literal guard reads this as a lint issue. The contract reads it as a correctness issue.

1.4 Region treatment across the estate

34 guards deliberately blank string literals before matching. That is correct for finding code, and it means no guard in that group can see a violation expressed as a string literal — which is precisely how the 15 .ts colours above are written.

1.5 Ranked exclusion risk

2. PRESENCE VS CONSUMPTION

The class: a guard asserts a thing is declared and nothing asserts a thing reads it.

2.1 The confirmed instance, verified independently

tests/cockpit/cockpit-tokens-owner.test.ts:156-182, test E, holds a hardcoded array of 20 strings and asserts each appears in the token file:

const missing = required.filter((token) => !css.includes(token));

Line 170 is "--t-3:". css.includes("--t-3:") is satisfied by the declaration alone. Nothing in the file — or in any other guard — asserts --t-3 is read.

Absence of consumption established two ways, independently:

• Mine: every consumption form the sibling guard recognises (var(), readCssVar, readCssPx, readToken, getPropertyValue, setProperty) searched across 1,583 files in both repos, 10 extensions, reading bytes. Zero consumers.
• Subagent, independently: 4,407 files with no extension filter (so dist/ and .md included). 6 occurrences of --t-3 total — two declarations in src/cockpit/tokens.css:365,624, two in the built bundle dist/client/assets/main-BvbVT859.css (--t-3:.24s, --t-3:1ms — again both declarations), one prose mention, one the guard itself. var(--t-3) matches nowhere, including in the shipped bundle.
• Control: --t-1 and --t-2 both resolve as consumed. --t-3 is the only one of the three that does not — so this is not an artefact of the search.

--t-3 is declared twice, asserted to exist by a guard, shipped in the production CSS bundle, and read by nothing. It is the CSS form of wired-but-inert, and it survives because the guard that would catch deadness (no-dead-css-tokens.test.ts) hardcodes a different file.

2.2 The whole class in that file

src/cockpit/tokens.css holds 18 tokens declared with zero consumers, confirmed against all consumption forms across both repos:

--on-cat-turn, --on-cat-tool, --on-cat-effect, --on-cat-check, --on-cat-finding, --on-cat-steer, --on-cat-anomaly, --on-cat-heal (:81-88, redeclared :555-562), --f-hero-size (:109), --f-hero-weight (:110), --verbs-pad-y (:164), --tick-w (:265), --bead-glow (:281), --t-3 (:365, :624), --ease-exit (:367), --density-type-delta (:372, :515), --stream-rate-w (:437), --editor-page-h (:478).

Deliberately excluded from that list: the 8 --cat-* tokens, which are consumed dynamically via src/cockpit/sweep/categories.ts:219 (pick(c.cssVar, pick(c.aliasVar, c.fallbackDark)), reached from Sweep.svelte:350). A naive var() scan would have called those dead too. Both my pass and the subagent’s caught this independently — worth recording because it is the shape that manufactures a false finding.

2.3 The rest of the class

Honest bound: 180 declaration-presence assertions of this shape exist across the two prevention directories. 43 were audited; ~137 were not. One live defect (--t-3) was found in the 43. The class is confirmed and its full size is unmeasured.

One incidental finding worth a task: exposure-registry-counts.test.ts:61-63 carries a comment saying “88 -> 80” while the constant on :64 is 96. The comment and the code disagree; not investigated.

3. SILENT SKIPS

3.1 Dark on a fresh checkout TODAY — the number

27 assertions across 21 tests, in exactly one file.

tests/performance/regression.test.ts:39:

describe.skipIf(!existsSync(REPORT_PATH))("web UI performance regression gate", () => {

Derivation, without running the suite:

1. REPORT_PATH resolves to tests/performance/.report.json.
2. git check-ignore -v returns .gitignore:12 → the path is gitignored, so it is never in a checkout. Confirmed absent on disk right now.
3. The file is inside the vitest include (vite.config.ts:124), so it is collected — it collects and skips, which is why it is invisible rather than missing.
4. Reading the file’s bytes: 1 outer describe.skipIf, 20 inner it.skipIf, 21 it blocks, 27 expect( calls.

So on a fresh checkout the entire performance budget — LCP, CLS, long tasks, tab switch, DOM node counts, typing latency, API response, heap growth, DOM growth, route discovery, viewport coverage, and report freshness — is enforced by nothing.

Correction to the brief. I was told “22 inner skips”. My byte-derived count is 20 inner it.skipIf plus 1 outer describe.skipIf. I report my number and flag the discrepancy rather than reconciling to the one I was given.

A third darkness layer nobody has counted. Even with a report present, 13 of the 21 tests begin with a bare if (…) return; on a missing report field (:87, 88, 95, 115, 127, 141, 148, 156, 165, 171, 177, 185, 194). A profile that ran but measured nothing produces a green gate. Per §8’s cost-guard rule — “a guard about the COST of an operation must first assert the operation happened” — these needed a liveness precondition and have an early return instead.

Census basis: across all 439 web test files, only 3 contain any skip construct. profile.spec.ts is Playwright (.spec.ts, outside the vitest include) and test-naming-structure.test.ts’s hit is a comment. So this is the only unconditionally dark guard in the web repo — a genuinely good result, and it should be said plainly.

3.2 Dark by construction — a guard that cannot fail

tests/prevention/no-dead-css-selectors.test.ts, second test:

test("the scanner itself is precise — no false-positive classes flagged", () => {
  for (const d of dead) { … expect(nonStyle).not.toContain(d.cls); }
});

dead is the findings array. If it is non-empty the first test throws, so the suite is already red. If it is empty this loop body never runs. I replicated the scanner’s exact logic over its own universe (150 .svelte files under src/): dead.length === 0, so this test executes zero assertions and always passes. A test that presents itself as the scanner’s own precision self-check is, structurally, incapable of ever failing.

3.3 Conditionally dark — the 2,405-assertion inheritance

tests/helpers/source-scan.ts:68:

export function walk(root, opts = {}, visited = new Set()) {
  …
  if (!existsSync(root)) return out;   // ← returns []

Plus two more swallows in the same function: :70-74 catch { return out; } on realpathSync, and :81-85 catch { continue; } on statSync (a broken symlink or an EACCES path is dropped from ~every guard’s candidate set with no signal).

Measured across the web guard estate:

Hand-written equivalents in the harness (if (!existsSync(dir)) return acc;): 26 guards, 13 with no floor, 244 assertions.

Combined: 2,405 assertions that would survive their subject directory being renamed.

This is not dark today — the directories exist, so these guards are live. I am stating it as conditional, because that is what it is. But “conditional on nobody restructuring a directory” is precisely the condition the repository violates constantly, and the failure mode is a green suite.

3.4 The worst sub-class: guards with zero expect()

8 guards produce their verdict solely by throw new Error(...) when a findings array is non-empty — and all 8 use the shared walker:

no-dead-css-tokens, no-duplicate-code, no-duplicate-constants, no-empty-catch, no-hardcoded-values, no-throw-new-error, no-unused-exports (all tests/prevention/), and tests/unit/hardcoded-values.test.ts.

These are structurally unable to distinguish “nothing is wrong” from “nothing was scanned”, because both produce an empty findings array. And they are all no-X deny rules — the place where a vacuous pass is least affordable.

3.5 The self-defeating liveness check

tests/prevention/integration-rule-refs-ratchet.test.ts roots its scan at "../harness-main-v1/integration/src" (:30) and ".../test/prevention" (:37) — a relative path out of the repository, depending on the two repos being siblings and the harness directory being named exactly harness-main-v1. Then:

test("the integration source is co-located (scan is not vacuous)", () => {
  if (!existsSync(INTEGRATION_SRC)) return;          // :96
  expect(files.length, "…").toBeGreaterThan(100);
});

The test that exists to prove the scan is not vacuous returns early exactly when the scan is vacuous. All four tests in the file are gated the same way (:96, 101, 129, 134).

Live today: the path resolves, 512 files, count 176 against baseline 178; the prevention half is at 238 against a baseline of 238 — zero headroom. So the guard is real and tight right now. Rename the harness directory and all four go green in silence.

Two more cross-repo guards share the shape: centralized-config.test.ts:49 and subprocess-confinement-owner.test.ts:1562 (join("..","harness-main-v1","integration","src","awareness","engine.ts")).

3.6 Dark by never being invoked

There is a category worse than skipping: never being called at all.

• integration/scripts/run-prevention-suite.ts — a runner for the prevention suite. No package.json script references it.
• integration/scripts/audit-12-point.mjs (285 lines) and a duplicate copy at harness-main-v1/scripts/audit-12-point.mjs. Neither is referenced by any script, and the workspace root has no package.json at all.
• integration/guardian/tests/run-tests.sh — the Landlock guardian’s fail-closed contract test. A bash script no npm path invokes.
• web bench/** — 13 files, no runner, not in the vitest include.
• harness: 20 recognizable test files on disk are absent from the executed inventory; 5 are registered pending-external-qualification and therefore never execute, including test/improper-usage.test.ts — the improper-usage suite §8 explicitly asks for.

3.7 The rung above all of this does not exist

Verified by me directly, both repos: no .github/ directory, no non-sample git hook, no eslint/biome/oxlint config tracked, no lint script.

tracked CI/lint files: 0    (harness-main-v1)
tracked CI/lint files: 0    (web-interface-foundation-v1)

Every guard’s entire enforcement is that somebody typed npm test. The 17,013 assertions have no mechanism compelling them to run before a commit, a merge, or a push. And npm run check (which runs the 2,261-line s1-verification.ts) and npm run typecheck are not part of npm test in either repo — they are separate manual commands.

4. EXEMPTIONS

§8: “EVERY EXEMPTION CARRIES THE SAME EVIDENCE BURDEN AS EVERY DETECTION.” Measured against that standard:

176 of 255 prevention guards contain no mechanism capable of proving any exemption — no fixture write, no synthetic source, no hostile/mutant/sanity test. (147 of 208 web, 29 of 47 harness.)

4.1 Staleness — the good news, stated plainly

I verified the 121 external JSON path references resolve on disk myself. All resolve. Two of these guards additionally fail on a stale hash at runtime (no-duplicate-function-bodies.test.ts:124-130, no-duplicated-string-literals.test.ts:97-103) — those are the correct design, and they should be the template.

Not verified: whether each of the 77 hashes still matches a real clone group. I checked paths, not hashes.

4.2 The six stale in-source exemptions

tests/prevention/no-rule-refs.test.ts:40-46 — DOCS, five entries, all five stale:

AGENTS.md  TASKS.md  WORKFLOW.md  ALL-BUGS-AND-ISSUES.md  ALL-MERGE-MANIFESTS.json

I confirmed all five are ABSENT from the web repo. And the exemption is doubly dead: EXTS on :50 is .ts/.svelte/.mjs/.cjs/.css/.js, so a .md or .json basename could never reach DOCS.has(basename(file)) even if the files existed. An exemption that has never once fired.

test/prevention/integration-awareness-arch-owner.test.ts:51 — "tmp-r48", a directory that does not exist. Harmless (fails open), but proof the exclusion was never re-verified.

4.3 Live defect: an exemption that is a permanent no-op

integration/test/prevention/integration-remaining-owner.test.ts:97

if (shouldExcludeExperiment(entry.name)) continue;

entry.name is a bare directory name ("editor", "exp999"). isExperimentPath (src/shared/source-scan.ts:88-106) iterates scanRoots and at :96 does if (!relativePath.startsWith(prefix)) continue; where prefix is src/, test/, scripts/ or _experiments/. A bare name matches no prefix, so the function always returns false and the exemption never fires.

I verified this independently rather than accepting it: of the 25 shouldExcludeExperiment( call sites in test/prevention/, 24 pass relative(ROOT, full) and this one passes a bare name. It is the sole outlier.

It fails open (scans more than intended), so it is not an escape. But it is an exemption that has never once done anything, in a guard nobody noticed was making a claim it could not honour. mtime 2026-07-25 02:39; verified by me after the writer’s commit.

4.4 Top exemptions by risk — unproven, and the invariant still applies

4.5 The three exemptions that meet the standard

Name them, because they are the template:

• harness/no-duplicate-function-bodies.test.ts:181-205 — plants an allowlisted pair, asserts zero findings; then :207-229 plants a stale entry and asserts it FAILS.
• harness/no-duplicated-string-literals.test.ts:146-162 — the same inversion.
• web/centralized-config.test.ts:204-212 — asserts its exception set is non-empty and that every entry resolves on disk. The only guard in either repo that checks its own allowlist for staleness.

3 of 255.

5. THE LADDER — what to make impossible

The standing instruction is “ideally we want these holes to just not be possible in the first place.” Ranked by (value ÷ effort).

5.1 Make a vacuous scan unrepresentable — one line, 2,405 assertions

Now: rung 5. walk() returns [] for a missing root; 72+13 guards cannot tell that from clean.

Rung 4 (available immediately). Change source-scan.ts:68 from return out; to a throw:

if (!existsSync(root)) throw new Error(`walk(): scan root does not exist: ${root}`);

This is the trunk (§3): one assertion at the single door, and every one of the 105 consumers gains it without being edited. It converts the largest silent-failure class in the estate into a loud one.

Rung 3 (better, still small). Give walk a required floor — walk(root, { exts, minFiles }) — and throw when the yield is under it. Forgetting the floor becomes a compile error rather than a habit, which is what §3’s “relieve responsibility” asks for: nobody has to remember.

Rung 2 (the real answer). Return a branded NonEmptyFileSet that cannot be iterated until narrowed. Then “I scanned nothing and passed” is not expressible in the type system. This also retires §3.4 — the 8 zero-expect() guards stop being able to confuse empty with clean.

The same edit, applied to the harness’s 26 hand-written if (!existsSync(dir)) return acc; walkers, is the argument for hoisting them onto one shared walker first (§14, §16).

5.2 Make the token-file universe discovered, not named

Now: rung 5 with a hardcoded path. no-dead-css-tokens.test.ts names src/styles/tokens.css; a second token file appeared and inherited no guard.

Fix (still rung 5, but the universe stops being a decision): discover every .css file and every <style> block, rather than naming one. §6 states it directly — “a test that needs editing when you add a module is itself a defect”. This closes §2.2’s 18 dead tokens and any third token file nobody has written yet.

Rung 2 for the consumption half: generate a TokenName union type from the discovered CSS at build time and require every read to go through readToken(name: TokenName). A typo’d or deleted token then fails tsc, not a scan. (I found 2 dangling var(--x) references with no declaration anywhere — src/state/theme.ts:10 and src/styles/tokens.css:6 — both look like documentation placeholders, but nothing mechanical distinguishes them from a real typo.)

5.3 Make the colour literal unrepresentable — a signature change

Now: rung 5, scanning <style> blocks. 18 escapes in <script> and .ts.

The instinct is to widen the scan to .ts. That is the third round of the mistake §0 records — the scan’s universe was wrong in a new way each time.

Rung 2, and it is one signature. Every one of the 18 is a fallback argument:

tokenColor(el, "--ink-4", "#4d545e")        // 3 sites
{ …, fallbackDark: "#dc8b8b" }               // 8 sites

Delete the third parameter of tokenColor, and the fallbackDark field from the category record. A hardcoded colour then has nowhere to be written — the bad state is unrepresentable and every call site that tries is a compile error. This also brings the code into line with §5b: absence of a token is a guided state, never a silent fallback to a second source of truth.

That is one type-level change replacing a scan whose universe has now been wrong twice.

5.4 Make the perf gate refuse to be absent

Now: rung 6 (convention: “run Playwright first”). 27 assertions dark on every fresh checkout.

• Rung 4: invert the default. describe.skipIf(!existsSync(REPORT_PATH) && !process.env.CI) — absent locally is a skip, absent in CI is a failure. (This presumes a CI exists; per §3.7 none does, which makes this the second-order fix.)
• Rung 1: commit a baseline report. The input can then never be absent, and the gate has no skip branch to take.
• Independently: replace the 13 bare if (…) return; field guards with liveness assertions, per §8’s cost-guard rule.

5.5 Make a stale exemption expire

Now: rung 5/6 — prose in a comment, believed.

Rung 4, and the machinery already exists. Two harness guards already fail on an allowlist entry that matches nothing. Generalise it: every exemption records whether it fired this run, and an exemption that fired zero times fails the suite. no-rule-refs.test.ts’s five dead DOCS entries and the tmp-r48 exclusion would both have died the day they went stale, and §4.3’s permanent no-op would have been caught the day it was written.

This is the single highest-leverage change to the exemption class, because it converts an exemption from a permanent claim about the world into one that must keep earning its place.

5.6 Typecheck the guards

Now: rung 0. tests/** is in no tsconfig — tsconfig.json includes src+contracts, tsconfig.server.json excludes tests, tsconfig.templates.json includes src+contracts. 439 web guard files, holding 14,364 assertions, are never typechecked.

Rung 2, trivially: add a tsconfig.tests.json. The code enforcing every invariant in the repository is currently the least-protected code in it.

5.7 Resolve the cross-repo root by resolution, not by directory name

Now: rung 5 depending on a sibling directory literally named harness-main-v1.

Rung 3: resolve the harness through its package specifier from the importing file (Node’s own resolution — §8b records that a bare specifier resolves from the file’s directory, not process.cwd()). Resolution then either succeeds or throws; it cannot silently yield an empty universe. Combined with §5.1, the self-defeating liveness check at integration-rule-refs-ratchet.test.ts:96 disappears rather than being fixed.

6. COVERAGE — what I did NOT verify

Required by the brief, and the most important section for anyone acting on this.

Not run, not measured:

• I ran no test suite in either repo (read-only). Every “this guard passes vacuously” claim is derived from source structure and from re-executing a guard’s own scanning logic in a scratch script — never from an observed pass/fail. I did not mutation-test a single guard, which is the only thing that would prove a vacuous pass.
• I did not run tsc --listFiles. §8b says it is the program’s file set and my walker is only a claim about it. My per-extension population counts (326 .ts, 150 .svelte, 2 .css) are therefore a walker’s claim, not the compiler’s. They are load-bearing for §1.2 and should be re-derived with tsc before anyone acts on the extension analysis.

Bounded, not complete:

• The per-guard table (Appendix A) is machine-generated by regex, not hand-read. Its “universe” column is extracted from const … = join(…) and SCAN_DIRS-style array literals; a guard that computes its root any other way shows as “named files”. Its “plant?” column is a vocabulary match (plant|mutat|synthetic|liveness|self-test), which overcounts (a comment mentioning mutation scores as a plant) and undercounts (a genuine plant written without those words). Treat it as a triage index, not a verdict.
• I read roughly 25 guards in full, out of 523.
• Exemption counts are lower bounds, stated as such: 304 single-line if (…) continue/return; sites were bucketed but not read; multi-line conditions and ~485 .filter()-based drops were never parsed at all.
• §2’s presence-vs-consumption class is 43 of 180 audited — ~137 declaration-presence assertions are unexamined.
• I verified allowlist paths resolve; I did not verify the 77 hashes still match real clone groups.
• Symbol-level allowlist entries ("join", "tool", "clean_state_verified", the *Row types) were assessed for plausibility, not resolved to declarations.
• I did not audit integration/verification/benchmarks/**, a large tree with its own .mjs runners that may hold further dark checkers.
• I did not check core.hooksPath or any machine-level CI outside these two repos. §3.7’s “no CI” claim is “no workflow file is tracked in either repo”, which is what I verified.

Concurrency caveat, honoured: the harness writer committed mid-audit (e3e036a → cebe0f4). Every harness claim in §4.3 and §4.2 I re-derived myself after that commit. All web claims rest on a clean tree at 0c7e536. Anything here about harness-main-v1 should still be re-checked against current HEAD before action — §8b’s “true when written, false six minutes later” applies to this document too.

Claims I deliberately did not make: I found no evidence that the .js/.mjs/.cjs extension gap has been exploited (2 files, both in scripts/), and I say so rather than presenting a latent hole as a live one. The --cat-* tokens look dead to a naive scan and are not; I excluded them. Several exemptions in §4.4 are unproven, which is not the same as wrong — the finding is the missing evidence, not a demonstrated escape.

7. WORKFLOW FINDING (§20)

An audit scoped by path inherits the defect it is auditing.

The brief pointed at tests/prevention/** and added “look for them by shape, not just by that path”. Following the path alone would have inventoried 255 files and missed 268 more — including tests/cockpit/, which holds 120 guards and the very file the brief cited as its canonical example. The audit’s own universe would have been wrong in exactly the way the thesis predicts.

The mechanism, not the moral: the guard estate has no self-inventory. Nothing asserts “every file matching a guard shape is inside a directory the runner executes”. The web repo happens to be clean here (zero orphaned *.test.ts); the harness is not — 20 recognizable test files are absent from the executed inventory and 5 more are registered as permanently unqualified.

Concrete proposal: a guard whose subject is the guard estate itself — discover every file matching the guard shape, assert each is matched by a configured runner glob, and assert the count only grows. It is the same deny-by-default discovery the estate already applies to routes and registrations, turned on itself. This is the finding I would most want to exist next time, and per §8 (“every issue should be findable by a test next time”) it is expressible as one.

Second-order: the three subagents I ran disagreed with the brief on two facts — the location of cockpit-tokens-owner.test.ts and the inner-skip count — and were right about the first and wrong-or-unreconciled about the second. Re-deriving load-bearing subagent claims personally (which I did for four of them, §4.3 especially) changed one from “reported” to “verified” and would have caught it had it been wrong. Analyst findings should be routed through independent re-derivation by default, not by exception.

APPENDIX A — per-guard table

Machine-generated over all 258 files in the two prevention directories. Columns: universe (walker roots / extension filter), instrument (bytes vs shells out), population floor asserted, plant vocabulary present, and the silent-skip shapes found with line numbers.

Read the caveat in §6 before using the plant? column as a verdict.