vigiles 2.6.0 → 3.0.0

package/.claude-plugin/plugin.json

@@ -30,6 +30,15 @@
             "command": "bash ${CLAUDE_PLUGIN_ROOT}/hooks/post-edit.sh"
           }
         ]
+      },
+      {
+        "matcher": "Edit|Write",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bash ${CLAUDE_PLUGIN_ROOT}/hooks/refs-nudge.sh"
+          }
+        ]
       }
     ],
     "SessionStart": [

package/README.md

@@ -19,175 +19,120 @@
   <a href="https://github.com/zernie/vigiles/blob/main/LICENSE"><img src="https://img.shields.io/github/license/zernie/vigiles" alt="License" /></a>
 </p>
 
-<p align="center">
-  <b>Two pillars →</b>
-  &nbsp;<a href="#verify-your-instruction-files">① Verify your instruction files</a>
-  &nbsp;·&nbsp;
-  <a href="#test-your-claude-code-harness">② Test your Claude Code harness</a>
-</p>
-
 ---
 
-<details>
-<summary><b>Contents</b></summary>
-
-- [**Two pillars — pick one or both**](#two-pillars--pick-one-or-both)
-- **Pillar 1** — [verify your instruction files](#verify-your-instruction-files) · full guide: [docs/verifying-instruction-files.md](docs/verifying-instruction-files.md)
-- **Pillar 2** — [test your Claude Code harness](#test-your-claude-code-harness) · full guide: [docs/harness-testing.md](docs/harness-testing.md)
-- [Quick start](#quick-start) · [CLI & CI](#cli--ci) · [Skills](#skills) · [Related tools](#related-tools)
-
-</details>
-
-## Two pillars — pick one or both
-
-An agent runs real commands in your repo — it can delete the wrong files, leak a secret, or burn tokens looping on a stale instruction nobody checked. You'd never ship an app without a linter and a test suite. An AI agent steering your codebase is no different — so why is its harness trusted on vibes?
-
-`Agent = Model + Harness`. Your harness is everything that steers a run — the **instructions** you write _and_ the **hooks, skills, and settings** that enforce them. vigiles is the **missing linting + testing layer for agentic coding**: it **lints** your instruction files and **tests** your harness. Two pillars of equal weight — adopt either on its own, or both:
-
-|       | Pillar                                                              | What it does                                                                                                                                                                 |
-| ----- | ------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| **①** | [**Verify your instruction files**](#verify-your-instruction-files) | Every linter rule, file path, script, and code symbol your CLAUDE.md cites is checked against reality, so stale references can't silently mislead the agent.                 |
-| **②** | [**Test your harness**](#test-your-claude-code-harness)             | Your hooks and skills are code — vigiles tests that they actually fire, **deterministically and for free** (no model, no API key) before you ever pay for a real-model eval. |
+`Agent = Model + Harness`. You'd never ship an app without a linter and a test
+suite — yet an AI agent steering your repo is trusted on vibes. vigiles is the
+deterministic layer for the harness: it **lints** the references your instruction
+files make and **tests** that your hooks and skills actually fire. Two independent
+pillars — adopt either, or both:
 
-They share the thesis but not a dependency: verify your instructions without ever writing a harness test, or test your harness without a single `.spec.ts`. Pick the pillar that hurts today.
+|       | Pillar                            | What it does                                                                                                                                                                                                |
+| ----- | --------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **①** | **Verify your instruction files** | Every linter rule, file path, script, and code symbol your CLAUDE.md cites is checked against reality, so stale references can't silently mislead the agent. → [guide](docs/verifying-instruction-files.md) |
+| **②** | **Test your harness**             | Your hooks and skills are code — vigiles tests they actually fire, **deterministically and free** (no model, no API key) before you pay for an eval. → [guide](docs/harness-testing.md)                     |
 
-## Verify your instruction files
+Neither pillar depends on the other — pick the one that hurts today. **Works with
+Claude Code and Codex** ([`vigiles/codex`](docs/harnesses.md)) behind a five-port
+adapter; [custom adapters welcome](docs/authoring-an-adapter.md).
 
-Your CLAUDE.md lies to your agent. Here's the fix.
+## ① Verify — your CLAUDE.md lies to your agent
 
-Hand-written CLAUDE.md files rot silently. Here's what a typical one looks like:
+Your CLAUDE.md says _"enforce `eslint/no-console`."_ But it was switched off
+months ago — and the agent trusts the claim. (Same story for the file path it
+cites that got renamed, and the script that was deleted.)
 
-```markdown
-## Code Style
+**Without vigiles:** nobody checks. The agent acts on fiction.
 
-Never use `any` — the `@typescript-eslint/no-explicit-any` rule
-catches this. Always use `unknown` and narrow with type guards.
-See `src/utils/type-helpers.ts` for project utilities.
+**With vigiles:** `npx vigiles audit` resolves every reference against reality —
 
-## Testing
-
-Run `npm run typecheck` before submitting. Every service in
-src/services/ should have a corresponding test file.
+```text
+CLAUDE.md (inline mode):
+  ✗ line 1: Rule "eslint/no-console" exists but is disabled in eslint config
+  ✓ line 2: eslint/eqeqeq
+  ✗ line 3: Rule "no-consoel" not found in eslint. Did you mean: "eslint/no-console"?
 ```
 
-Reads fine. Four things are wrong:
-
-1. `@typescript-eslint/no-explicit-any` — disabled to unblock a deadline, never re-enabled
-2. `src/utils/type-helpers.ts` — renamed to `src/utils/narrowing.ts` last quarter
-3. `npm run typecheck` — script removed from package.json
-4. Service/test pairing — no automated check, just a hope
-
-The agent reads this, trusts it, and writes code based on stale claims nobody verified. vigiles **verifies the references in your instruction files** — that each linter rule exists and is enabled, that every file path and script is real, and that referenced **code symbols** (functions, classes, constants) actually exist in the files that define them — and meets you at whatever commitment level you want.
-
-> **Set it up — paste this into Claude Code:**
->
-> > Install vigiles and verify my instruction files. Scan my CLAUDE.md / AGENTS.md, turn its real claims into checked references (linter rules, file paths, scripts, symbols), run `vigiles audit`, and show me what's already stale. Use sensible defaults, but **ask me first** whether to stay in markdown mode or generate a typed `.spec.ts`, and whether to wire the audit into CI and install the edit-blocking hooks.
-
-Or do it by hand — add a marker to your existing CLAUDE.md and audit it, no install, no new files:
+It resolves rule names across **7 linter catalogs** — the rule exists **and is
+enabled** — and checks file paths, scripts, and code symbols the same way. Start
+with one comment, no new files:
 
 ```md
 <!-- vigiles:enforce eslint/no-console "Route output through logger.ts" -->
 ```
 
-```bash
-npx vigiles audit CLAUDE.md
-```
+Step up to a typed `.spec.ts` (compiled to CLAUDE.md, compiler-grade) when you
+want it. **[Full guide →](docs/verifying-instruction-files.md)**
 
-Each reference is checked against reality — a typo gets a closest-match suggestion, a disabled rule is flagged. That's **markdown mode**; step up to a **typed spec** (`.spec.ts` → compiled CLAUDE.md, compiler-grade guarantees) when you want it.
+## ② Test — does your harness actually fire?
 
-→ **Full guide: [docs/verifying-instruction-files.md](docs/verifying-instruction-files.md)** — the adoption ladder, the three rule types (`enforce` / `guidance` / `guard`), verified references (`file` / `cmd` / `symbol` / `ref`), and the before/after tables.
+A hook can be wired wrong, a skill's description can fail to trigger, injected
+context can never reach the model — silently, all passing a naive "did it run?"
+check.
 
-## Quick Start
+**Without vigiles:** you assume your `--no-verify` guard blocks. You don't know.
 
-```bash
-npx vigiles init
-```
-
-The wizard auto-detects your project, creates a spec, scans your linters, compiles to markdown, adds a CI step, and installs Claude Code hooks. After install: the agent edits the spec (hooks block direct CLAUDE.md edits), the spec auto-compiles on save, and `vigiles audit` catches drift in CI. Prefer no new files? Stay in [markdown mode](docs/markdown-mode.md). Start with `guidance()` rules and `/strengthen` them to `enforce()` later; flags and agent usage are in the [CLI reference](docs/cli.md).
-
-Companion repo for [Feedback Loop Is All You Need](https://zernie.com/blog/feedback-loop-is-all-you-need).
-
-## Test your Claude Code harness
-
-Verifying references proves your instructions are _true_ — but the hooks and
-skills that enforce them still have to **actually fire**. A hook can be wired
-wrong, a skill's description can fail to trigger, injected context can never reach
-the model — all silently, all passing a naive "did it run?" check. So vigiles's
-second pillar **tests the harness itself**, as the assembled machine it ships as.
-
-> **Set it up — paste this into Claude Code:**
->
-> > Install vigiles and use its `test-harness` skill to write and run a harness test for this project. If I didn't say what to test, pick something real from my hooks / skills / settings, choose the cheapest tier (unit / deterministic / eval), write the test, and run it. Use good defaults, but **ask me** whether to gate it in CI and whether to add a real-model eval.
-
-It's a small library of plain async functions (drops into node:test / vitest /
-jest, or a zero-setup `vigiles test`), with three tiers, cheapest first. The
-design bet is **deterministic and cheap**: the first two tiers never call a model
-or need an API key, so they run on every commit for free — the opposite of
-eval-only frameworks like promptfoo, where every run hits a real model **by
-design**. You only reach for the paid real-model tier when the question genuinely
-needs it.
-
-- **Unit-test a hook** — `runHook` hands a hook a fake event and checks block/allow. No `claude`, no model, milliseconds, reaches **every** event type.
-- **Deterministic harness test** — `runHarnessTest` runs the **real** `claude` against a **scripted mock model**, so your hooks fire for real with no API key and the same result every time.
-- **Eval** — `runEval` runs the real model A/B (change on vs off) and reports the gap as **mean ± se**, with a Welch-t-test [significance gate](docs/harness-testing.md#significance--is-the-gap-real), regression baselines, and cost/latency/token tracking.
+**With vigiles:** a deterministic test proves it — no model, no API key,
+milliseconds:
 
 ```typescript
 import { runHook } from "vigiles/testing";
 
-const r = runHook(guardCommand, {
+const r = runHook(guard, {
   hook_event_name: "PreToolUse",
   tool_name: "Bash",
   tool_input: { command: "git commit --no-verify" },
 });
-assert(r.blocked); // exit 2 / decision:"block" / permissionDecision:"deny"
+assert(r.blocked); // a red ✗ here means your hook silently lets it through
 ```
 
-**[Full guide → `docs/harness-testing.md`](docs/harness-testing.md)** — the tier
-walkthrough, testing skills for real, "fired ≠ landed" (`trace.modelRequests`),
-the safe-by-default sandbox for untrusted plugins, the surface × tier coverage
-matrix, and how it compares to promptfoo. Also: [benchmarks](research/benchmarks-runtime-gates.md).
+```text
+  ✓ guard blocks --no-verify and allows a clean commit
 
-## CLI & CI
-
-```bash
-npx vigiles init        # Scaffold a spec (full setup wizard)
-npx vigiles compile     # Compile .spec.ts → .md
-npx vigiles audit       # Verify hashes + inline/frontmatter/spec rules + symbols + coverage
-npx vigiles test        # Run *.harness.mjs deterministic harness tests (no API key)
-npx vigiles eval        # Run *.eval.mjs real-model harness evals (--trials=N)
+2 passed.
 ```
 
-`vigiles audit` enforces four rules — `require-spec`, `require-skill-spec`, `integrity`, `coverage` — configurable in `.vigilesrc.json`. The GitHub Action runs `audit` by default; the Claude Code plugin (`npx skills add zernie/vigiles`) adds the Pre/PostToolUse hooks that block direct `.md` edits and auto-compile specs. [Full CLI, Action, plugin & validation reference →](docs/cli.md)
-
-## Skills
-
-Install with [Vercel Skills](https://github.com/vercel-labs/skills): `npx skills add zernie/vigiles`
+Three tiers, cheapest first: **`runHook`** (a hook's logic), **`runHarnessTest`**
+(the real agent CLI against a scripted mock model), **`runEval`** (the real model
+A/B with a significance gate). **Testing a skill?** `measureTriggerRate` checks
+its description actually **fires** across varied prompts (recall) without
+hijacking unrelated ones (precision). **[Full guide →](docs/harness-testing.md)**
 
-<details>
-<summary><b>The 8 skills</b></summary>
+## Quick start
 
-| Skill                  | What it does                                                                                      |
-| ---------------------- | ------------------------------------------------------------------------------------------------- |
-| `strengthen`           | Upgrade `guidance()` → `enforce()` using linter-specific reference docs                           |
-| `edit-spec`            | Edit a spec file — guided workflow with compile step                                              |
-| `migrate-to-spec`      | Convert a hand-written CLAUDE.md to a typed `.spec.ts`                                            |
-| `generate-rule`        | Add a new `enforce()` / `guidance()` rule to a spec                                               |
-| `pr-to-lint-rule`      | Turn a recurring PR review comment into a lint rule + spec entry                                  |
-| `enforce-rules-format` | Validate all rules have enforcement classification                                                |
-| `audit-feedback-loop`  | Score your repo's feedback loop maturity                                                          |
-| `test-harness`         | Test a Claude Code harness — pick the tier (unit / deterministic / eval) and write a passing test |
+> **Paste into Claude Code or Codex:**
+>
+> > Install vigiles in this repo and run it. Verify my CLAUDE.md / AGENTS.md
+> > references and show me what's stale, then write and run a harness test for one
+> > of my hooks or skills. Use good defaults (both pillars, non-interactive), but
+> > **ask me first** whether to gate it in CI, whether to add a real-model eval,
+> > and whether to enforce strictly (`--strict`).
 
-</details>
+Or do it yourself:
 
-## Related Tools
+```bash
+npx vigiles init   # sets up BOTH pillars: spec + harness test + CI + plugin
+```
 
-vigiles composes with other tools rather than replacing them: architectural linters ([ast-grep](https://ast-grep.github.io/), [Dependency Cruiser](https://github.com/sverweij/dependency-cruiser)) referenced via `enforce()`, and file-sync tools ([Ruler](https://github.com/intellectronica/ruler), [rulesync](https://github.com/dyoshikawa/rulesync)) that distribute the compiled output. [How it fits with each, and why runtime-LLM rule checkers are the opposite paradigm →](docs/related-tools.md)
+It's interactive in a terminal and non-interactive for agents/CI (or with
+`--yes`), so "set up vigiles" from a Claude Code / Codex prompt Just Works — and
+it installs a model-invocable **`test-harness` skill**, so afterward you can just
+tell your agent _"test my skills"_ and it picks the tier and writes the test.
+Scope `init` with `--pillars=verify|test|both`. Or write harness tests yourself in
+JS **or** TS (`*.harness.{mjs,ts}`) and run `npx vigiles test`. `init` wires CI as
+a `zernie/vigiles@v1` workflow — a composite over the same CLI:
+
+```yaml
+- uses: actions/checkout@v4
+- uses: zernie/vigiles@v1 # audits by default; posts a sticky PR comment + a `valid` output
+```
 
-## Documentation
+## More
 
-- **The two pillar guides:** [verifying instruction files](docs/verifying-instruction-files.md) (Pillar 1) · [testing your harness](docs/harness-testing.md) (Pillar 2).
-- **[docs/](docs/README.md)** — the full how-to & reference index: adoption ladder, CLI, linter support, skills/agents.
-- **[research/](research/README.md)** — the thinking behind it: design docs, the [harness-testing coverage roadmap](research/harness-testing-coverage-matrix.md), benchmark findings, landscape, and parked ideas.
+- **[CLI & GitHub Action →](docs/cli.md)** — every command, the Action (inputs / output / versioning), the Claude Code plugin, and the five `audit` rules.
+- **[Skills →](docs/skills.md)** — 8 skills (`strengthen`, `migrate-to-spec`, `test-harness`, …) via `npx skills add zernie/vigiles`.
+- **[Docs index →](docs/README.md)** · **[Research →](research/README.md)** · **[Related tools →](docs/related-tools.md)** (ast-grep, Dependency Cruiser, Ruler, rulesync).
+- Companion to [Feedback Loop Is All You Need](https://zernie.com/blog/feedback-loop-is-all-you-need).
 
 ## License
 

package/action.yml

@@ -1,25 +1,161 @@
 name: "vigiles"
-description: "Compile typed specs to instruction files and verify integrity"
+description: "Verify the references in your agent instruction files (CLAUDE.md/AGENTS.md) and compile typed specs — in CI."
+author: "zernie"
 branding:
   icon: "check-circle"
   color: "orange"
 
 inputs:
   command:
-    description: "Command to run: 'compile' or 'audit' (default: audit)"
+    description: "Which vigiles command to run: 'audit' (verify references + integrity + coverage) or 'compile' (specs → markdown)."
     required: false
     default: "audit"
   paths:
-    description: "Comma-separated paths to .spec.ts files (compile) or .md files (audit). Auto-discovers by default."
+    description: "Comma- or space-separated paths to operate on (.md files for audit, .spec.ts files for compile). Auto-discovers when empty."
     required: false
+    default: ""
+  version:
+    description: "Version of the vigiles npm package to run (e.g. '1', '1.2.3', 'latest'). Use 'local' to run the action's own checkout — for dogfooding via `uses: ./` in this repo's CI."
+    required: false
+    default: "latest"
   max-rules:
-    description: "Maximum number of rules per spec file"
+    description: "Maximum number of rules per spec file (maps to the CLI's --max-rules)."
     required: false
+    default: ""
   catalog-only:
-    description: "Only check that linter rules exist, skip config-enabled checks (true/false)"
+    description: "Only check that linter rules exist; skip config-enabled checks (maps to the CLI's --catalog-only). 'true' or 'false'."
     required: false
     default: "false"
+  working-directory:
+    description: "Directory to run vigiles in."
+    required: false
+    default: "."
+  comment:
+    description: "On pull_request events, post/update a sticky PR comment with the result ('true' or 'false'). Requires `pull-requests: write`."
+    required: false
+    default: "true"
+  github-token:
+    description: "Token used to post the PR comment. Defaults to the workflow token."
+    required: false
+    default: ${{ github.token }}
+
+outputs:
+  valid:
+    description: "'true' if vigiles passed (exit 0), 'false' otherwise."
+    value: ${{ steps.vigiles.outputs.valid }}
 
 runs:
-  using: "node20"
-  main: "dist/action.js"
+  using: "composite"
+  steps:
+    - id: vigiles
+      shell: bash
+      working-directory: ${{ inputs.working-directory }}
+      env:
+        # Inputs are passed through the environment (never interpolated into
+        # the script body) so a value can't break out of the command line.
+        VIGILES_COMMAND: ${{ inputs.command }}
+        VIGILES_PATHS: ${{ inputs.paths }}
+        VIGILES_VERSION: ${{ inputs.version }}
+        VIGILES_MAX_RULES: ${{ inputs.max-rules }}
+        VIGILES_CATALOG_ONLY: ${{ inputs.catalog-only }}
+        VIGILES_ACTION_PATH: ${{ github.action_path }}
+        VIGILES_COMMENT: ${{ inputs.comment }}
+        GH_TOKEN: ${{ inputs.github-token }}
+      run: |
+        set -euo pipefail
+
+        cmd="${VIGILES_COMMAND:-audit}"
+        args=("$cmd")
+
+        # paths: split on commas and whitespace into positional args.
+        paths="${VIGILES_PATHS:-}"
+        if [[ -n "${paths// /}" ]]; then
+          IFS=', ' read -r -a _paths <<< "$paths"
+          args+=("${_paths[@]}")
+        fi
+
+        max_rules="${VIGILES_MAX_RULES:-}"
+        if [[ -n "${max_rules// /}" ]]; then
+          args+=("--max-rules=${max_rules}")
+        fi
+
+        if [[ "${VIGILES_CATALOG_ONLY:-false}" == "true" ]]; then
+          args+=("--catalog-only")
+        fi
+
+        # Resolve the runner. 'local' runs the action's own build (CI
+        # dogfood via `uses: ./`); any other value runs the published npm
+        # package at that version, so the Action reuses the same tested
+        # artifact users get from `npx vigiles`.
+        version="${VIGILES_VERSION:-latest}"
+        if [[ "$version" == "local" ]]; then
+          runner=(node "${VIGILES_ACTION_PATH}/dist/cli.js")
+        else
+          runner=(npx --yes "vigiles@${version}")
+        fi
+
+        echo "vigiles: ${runner[*]} ${args[*]}"
+
+        # Run, streaming to the log AND capturing for the summary/comment.
+        out="$(mktemp)"
+        set +e
+        GITHUB_ACTIONS=true "${runner[@]}" "${args[@]}" 2>&1 | tee "$out"
+        status="${PIPESTATUS[0]}"
+        set -e
+
+        if [[ "$status" -eq 0 ]]; then
+          echo "valid=true" >> "$GITHUB_OUTPUT"
+          headline="✅ \`vigiles ${cmd}\` passed"
+        else
+          echo "valid=false" >> "$GITHUB_OUTPUT"
+          headline="❌ \`vigiles ${cmd}\` failed (exit ${status})"
+          echo "::error::vigiles ${cmd} failed (exit ${status})"
+        fi
+
+        # Build a markdown report (cap the log tail so a huge run stays sane).
+        report="$(mktemp)"
+        {
+          echo "## vigiles"
+          echo
+          echo "$headline"
+          echo
+          echo '<details><summary>Output</summary>'
+          echo
+          echo '```'
+          tail -c 60000 "$out"
+          echo '```'
+          echo
+          echo '</details>'
+        } > "$report"
+
+        # Job summary (always, when available) — the modern run-page output.
+        if [[ -n "${GITHUB_STEP_SUMMARY:-}" ]]; then
+          cat "$report" >> "$GITHUB_STEP_SUMMARY"
+        fi
+
+        # Sticky PR comment (pull_request events only, best-effort): find the
+        # prior vigiles comment by marker and update it in place, else create.
+        marker="<!-- vigiles-action -->"
+        if [[ "${VIGILES_COMMENT:-true}" == "true" \
+              && "${GITHUB_EVENT_NAME:-}" == "pull_request" \
+              && -n "${GH_TOKEN:-}" ]] && command -v gh >/dev/null 2>&1; then
+          pr="$(jq -r '.pull_request.number // empty' "${GITHUB_EVENT_PATH:-/dev/null}")"
+          if [[ -n "$pr" ]]; then
+            body="$(printf '%s\n%s\n' "$marker" "$(cat "$report")")"
+            repo="${GITHUB_REPOSITORY}"
+            cid="$(gh api "repos/${repo}/issues/${pr}/comments" --paginate \
+              --jq "map(select(.body | startswith(\"${marker}\"))) | .[0].id // empty" \
+              2>/dev/null || true)"
+            if [[ -n "$cid" ]]; then
+              gh api -X PATCH "repos/${repo}/issues/comments/${cid}" -f body="$body" >/dev/null \
+                && echo "Updated PR comment #${cid}" \
+                || echo "::warning::could not update PR comment (need pull-requests: write?)"
+            else
+              gh api -X POST "repos/${repo}/issues/${pr}/comments" -f body="$body" >/dev/null \
+                && echo "Posted PR comment" \
+                || echo "::warning::could not post PR comment (need pull-requests: write?)"
+            fi
+          fi
+        fi
+
+        exit "$status"

package/dist/action-gate.d.ts

@@ -1,4 +1,4 @@
-import { type RuntimeGate } from "./skill-runtime.js";
+import { type RuntimeGate } from "./adapters/claude-code/skill-runtime.js";
 export interface ActionGate {
     /** Tool name to gate, e.g. "Write" | "Edit" | "Bash". */
     readonly on: string;

package/dist/action-gate.js

@@ -21,7 +21,7 @@ exports.loadActionGates = loadActionGates;
  */
 const node_fs_1 = require("node:fs");
 const node_path_1 = require("node:path");
-const skill_runtime_js_1 = require("./skill-runtime.js");
+const skill_runtime_js_1 = require("./adapters/claude-code/skill-runtime.js");
 /** The file path an action touched, for `{file}` substitution. */
 function fileOf(event) {
     const i = event.input ?? {};

package/dist/adapter-conformance.d.ts

@@ -0,0 +1,30 @@
+import type { HarnessAdapter } from "./core/adapter.js";
+export interface ConformanceResult {
+    readonly ok: boolean;
+    readonly failures: readonly string[];
+}
+/** Check an adapter against the port contracts; returns the (possibly empty) failure list. */
+export declare function checkAdapterConformance(adapter: HarnessAdapter): ConformanceResult;
+/** Throw if the adapter fails conformance — drop this in an adapter's test suite. */
+export declare function assertAdapterConformance(adapter: HarnessAdapter): void;
+/**
+ * Guard for the pillar-2 entry points (runHarnessTest/runEval): a pillar-1-only
+ * adapter (Cursor, Devin, Amp, Amazon Q) has no mockable transport, so driving
+ * the deterministic/eval tiers against it would hang or spawn nothing. Calling
+ * this up front turns that into a clear, immediate error. Returns the narrowed
+ * runtime+modelMock so the caller can use them without re-checking for undefined.
+ */
+export declare function assertHarnessTestable(adapter: HarnessAdapter): {
+    runtime: NonNullable<HarnessAdapter["runtime"]>;
+    modelMock: NonNullable<HarnessAdapter["modelMock"]>;
+};
+/**
+ * Behavioural conformance the pure checks can't reach: write a minimal settings
+ * file in the adapter's declared `settingsFormat` (with a hook), load it through
+ * the adapter's `layout`, and assert the hooks actually came back. This is what
+ * catches a layout that points at the right file but in the wrong format (the
+ * JSON-vs-TOML trap) — the pure checker would pass it, the agent would silently
+ * run with zero hooks. Does filesystem IO, so it's a separate opt-in assert.
+ */
+export declare function assertAdapterLoadsHooks(adapter: HarnessAdapter): void;
+//# sourceMappingURL=adapter-conformance.d.ts.map