vigiles 29.1.0 → 30.0.1

package/dist/adapters/claude-code/layout.js

@@ -1,30 +1,64 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.claudeCodeLayout = void 0;
+/**
+ * claudeCodeLayout — the Claude Code plugin/repo layout (the `PluginLayout`
+ * port's reference implementation). `loadPlugin` defaults to it; a Codex adapter
+ * defines a sibling `codexLayout` and passes it to the same loader.
+ * 🔴 THE PATHS BELOW ARE DOCUMENTED IN `docs/configuration.md`. Change any of
+ * them — `instructionFile`, `surfaces`, `userSurfaceRoot`, `rulesDir` — and
+ * that page is wrong until you edit it too. The page marks this symbol with
+ * `vigiles:symbol`, so RENAMING it turns `vigiles lint` red and forces the
+ * edit; changing a VALUE in place does not, and nothing today catches that.
+ */
+const layout_js_1 = require("../../core/layout.js");
+const instruction_chain_js_1 = require("../../core/instruction-chain.js");
+const settings_codec_js_1 = require("../../core/settings-codec.js");
+const instruction_chain_js_2 = require("./instruction-chain.js");
 exports.claudeCodeLayout = {
     name: "claude-code",
     manifestPath: ".claude-plugin/plugin.json",
     hooksConventionPath: "hooks/hooks.json",
     settingsPath: ".claude/settings.json",
-    settingsFormat: "json",
+    settings: settings_codec_js_1.jsonSettingsCodec,
     instructionFile: "CLAUDE.md",
-    surfaceDirs: ["skills", "agents", "commands"],
+    surfaces: { skill: "skills", agent: "agents", command: "commands" },
     // A plain Claude Code USER keeps skills/agents/commands under `.claude/`, not at
     // the repo root (that's the published-plugin shape). Read both so a normal repo
-    // isn't seen as an empty machine.
+    // isn't seen as an empty machine. This is also the materialize prefix — it used
+    // to be a second field, `materializeRoot: ".claude"`, saying the same thing.
     userSurfaceRoot: ".claude",
-    skillDir: "skills",
-    agentDir: "agents",
-    commandDir: "commands",
     // `.claude/rules/*.md` — path-scoped project instructions (see PluginLayout).
     rulesDir: "rules",
-    materializeRoot: ".claude",
+    // `.claude/settings.local.json` — the per-machine layer, gitignored by
+    // `init`. Declared because only this adapter knows the word; Codex and
+    // OpenCode name none, so none is synthesized for them.
+    settingsLocalInfix: "local",
+    // Plugin hook SCRIPTS (`hooks/*.sh`), distinct from where hooks are
+    // REGISTERED (`hooks/hooks.json`, `.claude/settings.json`).
+    hookScriptsDir: "hooks",
     pluginRootToken: "${CLAUDE_PLUGIN_ROOT}",
     // Both names Claude Code uses for the project root (mirrors the
     // `NON_PLUGIN_VARS` set in plugin-loader.ts / scan-files.ts).
     projectRootTokens: ["${CLAUDE_PROJECT_DIR}", "${CLAUDE_PROJECT}"],
     mcpConfigFile: ".mcp.json",
     mcpManifestKey: "mcpServers",
-    intraRefDirs: ["hooks", "skills", "agents", "commands"],
+    // What a repo-root session LOADS, and why each remaining candidate does not —
+    // see ./instruction-chain.ts for the vendor quotes behind every branch. The
+    // regexes and paths handed over are DERIVED from the fields above, so moving
+    // `rulesDir` or `userSurfaceRoot` moves the chain with it.
+    instructionChain(files) {
+        return (0, instruction_chain_js_2.claudeCodeInstructionChain)(files, {
+            instructionFile: exports.claudeCodeLayout.instructionFile,
+            userSurfaceRoot: exports.claudeCodeLayout.userSurfaceRoot ?? "",
+            settingsSources: (0, instruction_chain_js_1.settingsSources)(exports.claudeCodeLayout),
+            parseSettings: (text) => exports.claudeCodeLayout.settings.parse(text),
+            // ANCHORED to `.claude/rules`, not to any path segment spelled `rules`
+            // — see `ruleFileRe`. `??` is safe here and not a silent default: this
+            // layout declares `rulesDir`, and a layout that did not would want no
+            // rule matcher at all rather than one matching nothing.
+            ruleRe: (0, layout_js_1.ruleFileRe)(exports.claudeCodeLayout) ?? /(?!)/,
+        });
+    },
 };
 //# sourceMappingURL=layout.js.map

package/dist/adapters/claude-code/model-access.d.ts

@@ -0,0 +1,41 @@
+/**
+ * Claude Code's answer to "is a real model reachable, and on whose bill" — the
+ * env-only half of `HarnessLiveDriver.access`.
+ *
+ * 🔴 IT USED TO LIVE IN `src/scan-trigger-suggest.ts`, the module named for the
+ * harness-AGNOSTIC read-vs-run decision, and its whole body was one harness's
+ * environment variables. The CLI then paired it with a name check for the other
+ * harness (`adapter.name === "codex" || hasModelAccess(process.env)`), which is
+ * the same fact said twice in two vocabularies. Here it is one adapter's
+ * knowledge of its own credentials, and the CLI asks the port.
+ *
+ * A tiny env-only predicate, never a live probe: deciding whether to offer a
+ * measurement must not itself spend a token.
+ */
+/** Only the env vars that signal a reachable model (parse, don't validate). */
+export interface ModelEnv {
+    readonly ANTHROPIC_API_KEY?: string;
+    readonly CLAUDECODE?: string;
+    readonly CLAUDE_CODE_ENTRYPOINT?: string;
+}
+/**
+ * Is a real model reachable for the executing tiers? Either a metered API key
+ * (`ANTHROPIC_API_KEY`), OR an authenticated Claude Code session (`CLAUDECODE=1`
+ * / `CLAUDE_CODE_ENTRYPOINT`, web/desktop/CLI) — the latter drives the `claude`
+ * CLI on the user's subscription, no key needed and $0 metered.
+ */
+export declare function hasModelAccess(env: ModelEnv): boolean;
+/**
+ * Is the reachable model METERED (a paid API key) rather than a subscription?
+ * Only affects the consent DISCLOSURE wording (a metered key bills per token; a
+ * subscription is $0 metered) — the run/skip decision itself is consent-driven,
+ * not metered-driven.
+ */
+export declare function isMeteredAccess(env: ModelEnv): boolean;
+/**
+ * The one line printed instead of running, when nothing is reachable. It names
+ * THIS harness's CLI and credential — the string it replaces was printed for
+ * every harness, so a Codex repo was told to authenticate `claude`.
+ */
+export declare const CLAUDE_CODE_ACCESS_FIX = "authenticate the `claude` CLI or set ANTHROPIC_API_KEY";
+//# sourceMappingURL=model-access.d.ts.map

package/dist/adapters/claude-code/model-access.js

@@ -0,0 +1,46 @@
+"use strict";
+/**
+ * Claude Code's answer to "is a real model reachable, and on whose bill" — the
+ * env-only half of `HarnessLiveDriver.access`.
+ *
+ * 🔴 IT USED TO LIVE IN `src/scan-trigger-suggest.ts`, the module named for the
+ * harness-AGNOSTIC read-vs-run decision, and its whole body was one harness's
+ * environment variables. The CLI then paired it with a name check for the other
+ * harness (`adapter.name === "codex" || hasModelAccess(process.env)`), which is
+ * the same fact said twice in two vocabularies. Here it is one adapter's
+ * knowledge of its own credentials, and the CLI asks the port.
+ *
+ * A tiny env-only predicate, never a live probe: deciding whether to offer a
+ * measurement must not itself spend a token.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.CLAUDE_CODE_ACCESS_FIX = void 0;
+exports.hasModelAccess = hasModelAccess;
+exports.isMeteredAccess = isMeteredAccess;
+/**
+ * Is a real model reachable for the executing tiers? Either a metered API key
+ * (`ANTHROPIC_API_KEY`), OR an authenticated Claude Code session (`CLAUDECODE=1`
+ * / `CLAUDE_CODE_ENTRYPOINT`, web/desktop/CLI) — the latter drives the `claude`
+ * CLI on the user's subscription, no key needed and $0 metered.
+ */
+function hasModelAccess(env) {
+    return Boolean(env.ANTHROPIC_API_KEY ||
+        env.CLAUDECODE === "1" ||
+        env.CLAUDE_CODE_ENTRYPOINT);
+}
+/**
+ * Is the reachable model METERED (a paid API key) rather than a subscription?
+ * Only affects the consent DISCLOSURE wording (a metered key bills per token; a
+ * subscription is $0 metered) — the run/skip decision itself is consent-driven,
+ * not metered-driven.
+ */
+function isMeteredAccess(env) {
+    return Boolean(env.ANTHROPIC_API_KEY);
+}
+/**
+ * The one line printed instead of running, when nothing is reachable. It names
+ * THIS harness's CLI and credential — the string it replaces was printed for
+ * every harness, so a Codex repo was told to authenticate `claude`.
+ */
+exports.CLAUDE_CODE_ACCESS_FIX = "authenticate the `claude` CLI or set ANTHROPIC_API_KEY";
+//# sourceMappingURL=model-access.js.map

package/dist/adapters/claude-code/skill-reachability.d.ts

@@ -0,0 +1,125 @@
+/**
+ * Are vigiles's SHIPPED SKILLS actually reachable by the agent in this repo?
+ *
+ * vigiles publishes six user-facing skills (`SHIPPED_SKILLS`) — the teaching
+ * surface. `test-harness` alone answers "which testing tier do I want?", the
+ * question this project's docs are otherwise organized around. They reach the
+ * agent through the GLOBAL plugin install (`vigiles init`, or
+ * `claude plugin marketplace add zernie/vigiles` + `claude plugin install
+ * vigiles@vigiles`), which lands in `~/.claude/plugins/` — deliberately never
+ * vendored into the repo (`docs/agent-setup.md`).
+ *
+ * The failure this module makes loud: `npm install vigiles` ALSO puts those
+ * skills on disk, at `node_modules/vigiles/skills/` (they are in package.json's
+ * `files`, because the npm tarball doubles as the plugin payload). Claude Code
+ * never scans `node_modules`. So a repo that took the dependency but never ran
+ * the plugin install has all six skills present, unreachable, and **silent** —
+ * observed in a real consumer repo, where a full day went into re-deriving what
+ * `test-harness` teaches while it sat three directories away.
+ *
+ * ⚠️ The part that is easy to get wrong, and did get wrong TWICE, in opposite
+ * directions:
+ *
+ * 1. The authoritative record of a `claude plugin install` is the GLOBAL
+ *    `~/.claude/plugins/installed_plugins.json`. A repo's `.claude/settings.json`
+ *    carries PROJECT-level `enabledPlugins`, which a correctly-installed
+ *    user-scope plugin does not appear in. Judging "is it wired?" from
+ *    `settings.json` alone reports a working install as broken — the misread
+ *    that made this look like an npm packaging bug.
+ * 2. The converse is ALSO false: a project `enabledPlugins` entry does not make
+ *    the plugin load. Per the Claude Code docs (Discover plugins → "Configure
+ *    team marketplaces"), as of CC v2.1.195 — "A plugin that only the project's
+ *    `.claude/settings.json` enables, and that comes from an external source
+ *    such as a GitHub repository or npm package, doesn't load until the team
+ *    member installs it." vigiles ships from a GitHub marketplace, so that is
+ *    exactly our case. Committing `extraKnownMarketplaces` + `enabledPlugins`
+ *    makes Claude Code PROMPT each collaborator to install; it does not install.
+ *    Confirmed empirically: in a repo whose committed settings.json declares an
+ *    external plugin project-level, the global registry had no marketplace
+ *    entry, no cache dir, and no install record for it, while a plugin installed
+ *    the normal way on the same machine had all three.
+ *
+ * So a project declaration is a THIRD state — declared, not installed — that
+ * still warrants a warning, with a different fix line: the collaborator runs the
+ * install, the repo cannot run it for them.
+ *
+ * Shape follows `./dialect-drift.ts`: pure parsers + a best-effort local read
+ * that NEVER throws + a formatter that returns null when there is nothing to
+ * say, so `vigiles audit` can print it without a new verb, flag, or failure mode.
+ * It is ADVISORY — it never touches the audit score, because reachability is a
+ * property of the machine (is the plugin installed?), not of the repo, and a
+ * score that moved between a laptop and CI for identical source would be a lie.
+ */
+import type { InstallReader } from "../../core/adapter.js";
+/** The plugin id `claude plugin install` records — `<plugin>@<marketplace>`. */
+export declare const VIGILES_PLUGIN_ID = "vigiles@vigiles";
+/**
+ * Where a reachable install was found. Deliberately does NOT include a project
+ * `enabledPlugins` entry: that declares the plugin, it does not install it (see
+ * the header). It is reported as {@link SkillReachability.declaredNotInstalled}.
+ */
+export type ReachabilitySource = 
+/** `~/.claude/plugins/installed_plugins.json` — what `claude plugin install` writes. */
+"global-plugin"
+/** The skills vendored into the repo's own `.claude/skills/` (standalone config, always loaded). */
+ | "repo-skills";
+/** The advisory: can the agent see vigiles's skills from this repo? */
+export interface SkillReachability {
+    /** True when at least one {@link ReachabilitySource} was found. */
+    readonly reachable: boolean;
+    /** Every source that resolved, in check order. Empty when un-wired. */
+    readonly sources: readonly ReachabilitySource[];
+    /**
+     * The repo's `.claude/settings.json` enables the plugin, but no install was
+     * found. Claude Code will prompt this collaborator to install it; until they
+     * do, it does not load. A distinct state from "nothing configured at all",
+     * because the fix belongs to the person, not the repo.
+     */
+    readonly declaredNotInstalled: boolean;
+    /**
+     * Shipped skills found under `node_modules/vigiles/skills/` while UNREACHABLE
+     * — present on disk, invisible to the agent. Empty when reachable (there is
+     * nothing stranded if they are wired) or when the package isn't installed yet.
+     */
+    readonly strandedSkills: readonly string[];
+}
+/**
+ * Does the global registry record a live install of the vigiles plugin? Pure over
+ * the raw `installed_plugins.json` text. An entry with an EMPTY array is a
+ * leftover record, not an install, so it does not count.
+ */
+export declare function hasGlobalPluginInstall(installedPluginsJson: string): boolean;
+/**
+ * Does the repo's `.claude/settings.json` explicitly enable the vigiles plugin?
+ * Pure. An explicit `false` is a deliberate disable and does NOT count.
+ */
+export declare function hasEnabledPlugin(settingsJson: string): boolean;
+/**
+ * Best-effort, read-local reachability check for `vigiles audit`. Returns null
+ * when the question does not apply — the repo does not depend on vigiles, or IS
+ * vigiles — so a non-consumer is never nagged. NEVER throws: every read the
+ * reader performs degrades to "not found".
+ *
+ * 🔴 IT READS THROUGH A REPO-BOUND {@link InstallReader}, NOT `node:fs`. Two of
+ * its five reads are of files NO adapter claims (`package.json`, vigiles's own
+ * package under `node_modules`), so the domain performs those and passes the
+ * ANSWER; the rest go through a reader that refuses any path this adapter does
+ * not claim. That is why this module no longer imports `node:fs` at all.
+ *
+ * ⚠️ ONE MEASURED CHANGE, NAMED BECAUSE IT IS A CHANGE: the repo-vendored check
+ * used to ENUMERATE `.claude/skills/` and compare directory names. Enumeration
+ * is precisely what the reader exists to prevent, and it is not needed here —
+ * the names being looked for are a fixed list — so each shipped skill is probed
+ * for its own `SKILL.md` instead. The narrow difference: a directory named after
+ * a shipped skill but holding no `SKILL.md` used to count as reachable and no
+ * longer does. It was never loadable by the agent, which is the question asked.
+ */
+export declare function checkSkillReachability(read: InstallReader): SkillReachability | null;
+/**
+ * The warning for an un-wired repo, or null when there is nothing to say
+ * (reachable, or the check did not apply). Names the skill the user most likely
+ * went looking for, says where the copies are stranded when they exist, and ends
+ * on a command that fixes it.
+ */
+export declare function formatSkillReachability(r: SkillReachability | null): string | null;
+//# sourceMappingURL=skill-reachability.d.ts.map

package/dist/adapters/claude-code/skill-reachability.js

@@ -0,0 +1,111 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.VIGILES_PLUGIN_ID = void 0;
+exports.hasGlobalPluginInstall = hasGlobalPluginInstall;
+exports.hasEnabledPlugin = hasEnabledPlugin;
+exports.checkSkillReachability = checkSkillReachability;
+exports.formatSkillReachability = formatSkillReachability;
+const setup_plan_js_1 = require("../../setup-plan.js");
+/** The plugin id `claude plugin install` records — `<plugin>@<marketplace>`. */
+exports.VIGILES_PLUGIN_ID = "vigiles@vigiles";
+/**
+ * Does the global registry record a live install of the vigiles plugin? Pure over
+ * the raw `installed_plugins.json` text. An entry with an EMPTY array is a
+ * leftover record, not an install, so it does not count.
+ */
+function hasGlobalPluginInstall(installedPluginsJson) {
+    try {
+        const parsed = JSON.parse(installedPluginsJson);
+        const entry = parsed.plugins?.[exports.VIGILES_PLUGIN_ID];
+        return Array.isArray(entry) && entry.length > 0;
+    }
+    catch {
+        return false;
+    }
+}
+/**
+ * Does the repo's `.claude/settings.json` explicitly enable the vigiles plugin?
+ * Pure. An explicit `false` is a deliberate disable and does NOT count.
+ */
+function hasEnabledPlugin(settingsJson) {
+    try {
+        const parsed = JSON.parse(settingsJson);
+        return parsed.enabledPlugins?.[exports.VIGILES_PLUGIN_ID] === true;
+    }
+    catch {
+        return false;
+    }
+}
+/**
+ * Best-effort, read-local reachability check for `vigiles audit`. Returns null
+ * when the question does not apply — the repo does not depend on vigiles, or IS
+ * vigiles — so a non-consumer is never nagged. NEVER throws: every read the
+ * reader performs degrades to "not found".
+ *
+ * 🔴 IT READS THROUGH A REPO-BOUND {@link InstallReader}, NOT `node:fs`. Two of
+ * its five reads are of files NO adapter claims (`package.json`, vigiles's own
+ * package under `node_modules`), so the domain performs those and passes the
+ * ANSWER; the rest go through a reader that refuses any path this adapter does
+ * not claim. That is why this module no longer imports `node:fs` at all.
+ *
+ * ⚠️ ONE MEASURED CHANGE, NAMED BECAUSE IT IS A CHANGE: the repo-vendored check
+ * used to ENUMERATE `.claude/skills/` and compare directory names. Enumeration
+ * is precisely what the reader exists to prevent, and it is not needed here —
+ * the names being looked for are a fixed list — so each shipped skill is probed
+ * for its own `SKILL.md` instead. The narrow difference: a directory named after
+ * a shipped skill but holding no `SKILL.md` used to count as reachable and no
+ * longer does. It was never loadable by the agent, which is the question asked.
+ */
+function checkSkillReachability(read) {
+    if (!read.repoDependsOnVigiles)
+        return null;
+    const sources = [];
+    const installed = read.home(".claude/plugins/installed_plugins.json");
+    if (installed !== null && hasGlobalPluginInstall(installed))
+        sources.push("global-plugin");
+    // Vendored copies: only vigiles's OWN skill names count. A repo with 38
+    // unrelated skills in `.claude/skills/` is still un-wired.
+    if (setup_plan_js_1.SHIPPED_SKILLS.some((s) => read.repo(`.claude/skills/${s}/SKILL.md`)))
+        sources.push("repo-skills");
+    const reachable = sources.length > 0;
+    // A project declaration is NOT a source — it makes Claude Code prompt for an
+    // install, it does not perform one. Only meaningful while unreachable.
+    const settings = read.repo(".claude/settings.json");
+    const declaredNotInstalled = !reachable && settings !== null && hasEnabledPlugin(settings);
+    const vendored = new Set(read.vendoredSkillNames);
+    return {
+        reachable,
+        sources,
+        declaredNotInstalled,
+        strandedSkills: reachable
+            ? []
+            : setup_plan_js_1.SHIPPED_SKILLS.filter((s) => vendored.has(s)),
+    };
+}
+/**
+ * The warning for an un-wired repo, or null when there is nothing to say
+ * (reachable, or the check did not apply). Names the skill the user most likely
+ * went looking for, says where the copies are stranded when they exist, and ends
+ * on a command that fixes it.
+ */
+function formatSkillReachability(r) {
+    if (!r || r.reachable)
+        return null;
+    const stranded = r.strandedSkills.length > 0
+        ? ` ${String(r.strandedSkills.length)} of them are sitting in ` +
+            `node_modules/vigiles/skills/, which the agent never scans.`
+        : "";
+    const why = r.declaredNotInstalled
+        ? `This repo DECLARES the vigiles plugin in .claude/settings.json, but a ` +
+            `project declaration doesn't install it — Claude Code loads an ` +
+            `external-source plugin only once each collaborator installs it on their ` +
+            `own machine.`
+        : `This repo depends on vigiles, but its plugin isn't installed.`;
+    return (`⚠ vigiles's skills are NOT reachable by your agent here. ${why} So the ` +
+        `shipped skills (${setup_plan_js_1.SHIPPED_SKILLS.join(", ")}) can't be selected — ` +
+        `including test-harness, which picks the testing tier for you.${stranded}\n` +
+        `  Fix (per machine): claude plugin marketplace add zernie/vigiles && ` +
+        `claude plugin install ${exports.VIGILES_PLUGIN_ID}\n` +
+        `  (or run \`vigiles init\`, which does both)`);
+}
+//# sourceMappingURL=skill-reachability.js.map

package/dist/adapters/claude-code/skill-runtime.js

@@ -38,6 +38,7 @@ const node_fs_1 = require("node:fs");
 const node_path_1 = require("node:path");
 const effects_js_1 = require("../../core/effects.js");
 const dialect_js_1 = require("./dialect.js");
+const local_files_js_1 = require("../../local-files.js");
 const STEP_RE = /^###\s+Step\s+(\d+)/;
 const GATE_CMD_RE = /<!--\s*vigiles:gate\s+"([^"]*)"(?:\s+retry:(\d+))?\s*-->/;
 const GATE_FILE_RE = /<!--\s*vigiles:gate\s+file:(\S+)\s*-->/;
@@ -235,11 +236,12 @@ function runSkillGates(gates, cwd) {
 // (Claude Code hooks don't surface the active skill, so we record it). Wiring
 // `skill-start` to fire automatically is the integration step; the decision
 // logic below is harness-agnostic and fully testable.
-const ACTIVE_PATH = ".vigiles/active-skill.json";
+const ACTIVE_PATH = `${local_files_js_1.VIGILES_DIR}/${local_files_js_1.ACTIVE_SKILL_FILE}`;
 /** Record the skill the agent is currently executing. */
 function setActiveSkill(cwd, skillPath) {
     const p = (0, node_path_1.resolve)(cwd, ACTIVE_PATH);
     (0, node_fs_1.mkdirSync)((0, node_path_1.dirname)(p), { recursive: true });
+    (0, local_files_js_1.ensureLocalFilesIgnored)((0, node_path_1.dirname)(p));
     (0, node_fs_1.writeFileSync)(p, JSON.stringify({ skill: skillPath }) + "\n");
 }
 /** Clear the active-skill marker (the skill finished). */

package/dist/adapters/codex/adapter.d.ts

@@ -1,3 +1,40 @@
-import type { HarnessAdapter } from "../../core/adapter.js";
-export declare const codexAdapter: HarnessAdapter;
+/**
+ * codexAdapter — the OpenAI Codex `HarnessAdapter`. Bundles the five Codex ports
+ * + a `detect`. SHIPPED: registered in `src/adapter-registry.ts` (the CLI
+ * auto-detects a `.codex/config.toml` or `AGENTS.md` repo) and exported as
+ * `vigiles/codex`. It passes `assertAdapterConformance`/`assertAdapterLoadsHooks`,
+ * drives the compiler + loader against real Codex fixtures (codex.test.ts), and
+ * its transport (`mock-model.ts`) is proven against the real `codex` binary.
+ *
+ * Caveat — pillar 1 (compile) is partial: the instruction/skill *renderers* still
+ * emit the Claude-Code shape until the format-axis renderers land
+ * (`research/code-adapter-architecture.md`). Pillar 2 (harness testing) is full.
+ */
+import type { DetectSignal } from "../../core/adapter.js";
+export declare const codexAdapter: {
+    readonly name: "codex";
+    readonly harnessTesting: true;
+    readonly shellHooks: true;
+    readonly subagents: false;
+    readonly dialect: import("../claude-code/dialect.js").HarnessDialect;
+    readonly layout: import("../../adapter.js").PluginLayout;
+    readonly runtime: import("../../adapter.js").HarnessRuntime;
+    readonly hookProtocol: import("../../adapter.js").HookProtocol;
+    readonly modelMock: import("../../adapter.js").ModelMock;
+    readonly harnessTestDriver: () => Promise<import("../../harness-test.js").HarnessTestDriver>;
+    readonly liveDriver: () => Promise<import("../../core/live-driver.js").HarnessLiveDriver>;
+    readonly claims: (path: string) => boolean;
+    readonly detect: (exists: (repoRelative: string) => boolean) => DetectSignal;
+    /**
+     * Nothing to say about a Codex install today, and `[]` IS the answer rather
+     * than a missing capability: the CLI prints whatever it is given, so an empty
+     * list produces exactly the silence a `localAdvisories: false` flag would
+     * have bought, without a second fact to keep in step with this method.
+     *
+     * What would go here: anything about THIS machine's `codex` install that bears
+     * on how far the report can be trusted — a vendor version whose tool catalog
+     * has drifted from ours, or a config the agent cannot read from this repo.
+     */
+    readonly advisories: () => readonly string[];
+};
 //# sourceMappingURL=adapter.d.ts.map

package/dist/adapters/codex/adapter.js

@@ -1,20 +1,6 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.codexAdapter = void 0;
-/**
- * codexAdapter — the OpenAI Codex `HarnessAdapter`. Bundles the five Codex ports
- * + a `detect`. SHIPPED: registered in `src/adapter-registry.ts` (the CLI
- * auto-detects a `.codex/config.toml` or `AGENTS.md` repo) and exported as
- * `vigiles/codex`. It passes `assertAdapterConformance`/`assertAdapterLoadsHooks`,
- * drives the compiler + loader against real Codex fixtures (codex.test.ts), and
- * its transport (`mock-model.ts`) is proven against the real `codex` binary.
- *
- * Caveat — pillar 1 (compile) is partial: the instruction/skill *renderers* still
- * emit the Claude-Code shape until the format-axis renderers land
- * (`research/code-adapter-architecture.md`). Pillar 2 (harness testing) is full.
- */
-const node_fs_1 = require("node:fs");
-const node_path_1 = require("node:path");
 const dialect_js_1 = require("./dialect.js");
 const layout_js_1 = require("./layout.js");
 const surface_discovery_js_1 = require("../../core/surface-discovery.js");
@@ -25,33 +11,47 @@ exports.codexAdapter = {
     name: "codex",
     // Full convergence with Claude Code: mockable (Responses SSE) + shell hooks
     // with veto (permissionDecision/exit 2). Both pillars, all tiers.
-    capabilities: {
-        referenceVerification: true,
-        harnessTesting: true,
-        shellHooks: true,
-        // Codex `[agents]` is a concurrency table, not a subagent tool-contract file
-        // — the subagent-surface rules report n/a here (a deliberate non-goal).
-        subagents: false,
-    },
+    harnessTesting: true,
+    shellHooks: true,
+    // Codex `[agents]` is a concurrency table, not a subagent tool-contract file
+    // — the subagent-surface rules report n/a here (a deliberate non-goal).
+    subagents: false,
     dialect: dialect_js_1.codexDialect,
     layout: layout_js_1.codexLayout,
     runtime: runtime_js_1.codexRuntime,
     hookProtocol: hook_protocol_js_1.codexHookProtocol,
     modelMock: model_mock_js_1.codexModelMock,
     harnessTestDriver: async () => (await import("./driver.js")).codexDriver,
+    liveDriver: async () => (await import("./eval.js")).codexLiveDriver,
     // Derived from the layout, never listed again here — see `claims` on
     // `HarnessAdapter` for why this method takes a PATH and not a root.
     claims(path) {
         return (0, surface_discovery_js_1.layoutClaims)(layout_js_1.codexLayout, path);
     },
-    detect(root) {
+    detect(exists) {
         // A `.codex/config.toml` is a strong signal; a bare AGENTS.md is weak (many
-        // harnesses read it). (Unused while unregistered — kept for symmetry.)
-        if ((0, node_fs_1.existsSync)((0, node_path_1.join)(root, ".codex", "config.toml")))
-            return 3;
-        if ((0, node_fs_1.existsSync)((0, node_path_1.join)(root, layout_js_1.codexLayout.instructionFile)))
-            return 1;
-        return 0;
+        // harnesses read it). The manifest path IS `.codex/config.toml` — asked for
+        // by the layout field rather than respelled, so a layout that moves takes
+        // its detection with it (the path used to be typed out here as
+        // `join(root, ".codex", "config.toml")`).
+        if (exists(layout_js_1.codexLayout.manifestPath))
+            return { specificity: 3, via: "manifest" };
+        if (exists(layout_js_1.codexLayout.instructionFile))
+            return { specificity: 1, via: "instruction-file" };
+        return { specificity: 0, via: "instruction-file" };
+    },
+    /**
+     * Nothing to say about a Codex install today, and `[]` IS the answer rather
+     * than a missing capability: the CLI prints whatever it is given, so an empty
+     * list produces exactly the silence a `localAdvisories: false` flag would
+     * have bought, without a second fact to keep in step with this method.
+     *
+     * What would go here: anything about THIS machine's `codex` install that bears
+     * on how far the report can be trusted — a vendor version whose tool catalog
+     * has drifted from ours, or a config the agent cannot read from this repo.
+     */
+    advisories() {
+        return [];
     },
 };
 //# sourceMappingURL=adapter.js.map

package/dist/adapters/codex/dialect.js

@@ -36,14 +36,19 @@ exports.codexDialect = {
         limit: 32768,
         onExceed: "truncates",
         capturedFrom: "codex config project_doc_max_bytes default 32 * 1024; truncation quoted in openai/codex#7138",
-        // Read root-to-leaf and concatenated, so a nested AGENTS.md pays into the
-        // same budget — the sum is what gets cut, not the individual file.
-        alwaysLoaded: ["AGENTS.md", "**/AGENTS.md"],
     },
+    // 🔴 `alwaysLoaded: ["AGENTS.md", "**/AGENTS.md"]` USED TO STAND HERE, and it
+    // was wrong twice over: the core expanded that second glob by walking the
+    // whole repository (an adapter choosing what the domain reads), and the set it
+    // produced is not what a root session loads — Codex takes AT MOST ONE FILE PER
+    // DIRECTORY along root→cwd, so at the root it is one file. A monorepo with
+    // twelve package-level AGENTS.md files was told it was 12x over a budget no
+    // session approaches. Which files load is now `codexLayout.instructionChain`.
     instructionTargets: ["AGENTS.md"],
     pluginRootToken: "${PLUGIN_ROOT}",
-    // Codex SKILL.md frontmatter is name + description ONLY — the CC-only keys
-    // (disable-model-invocation, argument-hint, …) are not part of its format.
-    skillFrontmatter: "minimal",
+    // Codex SKILL.md frontmatter is name + description ONLY — the richer keys
+    // (disable-model-invocation, argument-hint, disallowed-tools, …) are not part
+    // of its format, so the compiler omits them instead of writing inert noise.
+    skillFrontmatterKeys: ["name", "description"],
 };
 //# sourceMappingURL=dialect.js.map

package/dist/adapters/codex/eval.d.ts

@@ -25,6 +25,7 @@
  * SKILL.md read (`codexSkillFired`). Best-effort by nature (a cached skill might
  * not be re-read); pair with a behavioral/judged check for certainty.
  */
+import type { HarnessLiveDriver } from "../../core/live-driver.js";
 import type { ParsedModelRun, AgentRunArgs, RunOut, EvalDriver } from "../../eval.js";
 import type { ToolCall } from "../../core/harness-driver.js";
 /** Parse `codex exec --json` stdout into the common trace fields (confirmed schema). */
@@ -103,6 +104,15 @@ export declare const CODEX_TRIGGER_RATE_EXPERIMENTAL: string;
  * the spec's `fired` with `codexSkillFired` (Codex has no Skill-tool event).
  */
 export declare const codexEvalDriver: EvalDriver;
+/**
+ * The Codex {@link HarnessLiveDriver} — the EXECUTING tiers' side of the
+ * adapter, reached through `codexAdapter.liveDriver()`.
+ *
+ * It is the object `scan-behavioral.ts:buildProbe` used to build from
+ * `harness === "codex"`: the same four answers, now carried by the adapter that
+ * knows them instead of switched on by a name in the application layer.
+ */
+export declare const codexLiveDriver: HarnessLiveDriver;
 /**
  * Spawn real `codex exec --json` for the eval tier (real model, the user's codex
  * auth — NOT the mock). CONFIRMED flags (codex 0.139.0): `--json` for the event