feat(intent): standalone checker crate and the CI that gates the corpus

[schickling-assistant]

Lifts the VRS checker out of schickling/dotfiles into a standalone crate in this
repo, and wires the two checks that gate the corpus onto this repo's own CI.

Packages it as a flake too, which is the only supported distribution.

What is here

Path	What
crates/intent/	Standalone package: intent binary + library exposing run
.github/workflows/ci.yml	materialises, crate, corpus-strict, semantic-review-fixtures
flake.nix / flake.lock	Packages the CLI; checks for fmt, clippy, tests, help, corpus
.github/workflows/nix.yml	The nix lane — a separate workflow, deliberately
crates/intent/README.md	Command surface + the enforcement-asset contract
.gitignore	target/, result, and the JSON reports CI writes at the root

axe vrs embeds the library and calls intent::run directly, so main.rs is a
thin shell over the same entry point — anything living only in the binary would be
behavior the embedded caller silently does not get.

The path bug this fixes, and the proof it was real

The staged corpus-strict job built with --manifest-path crates/intent/Cargo.toml
and then invoked ./target/release/intent. crates/intent is a standalone
package — its own Cargo.lock, no workspace root above it — so cargo writes to
crates/intent/target/, not ./target/. Both the strict step and the graph step
would have died on "no such file" before either gate ran, which is a green-looking
job that never checked anything.

Reproduced from a clean checkout root with no pre-existing target/:

$ cargo build --locked --manifest-path crates/intent/Cargo.toml   # the staged command
$ ls ./target/debug/intent                     # ABSENT  <- the step dies here
$ ls crates/intent/target/debug/intent         # PRESENT <- where cargo actually wrote it

Fixed by passing --target-dir target explicitly, rather than by rewriting the two
consumer steps to the nested path. --target-dir pins the output location
independent of workspace detection, so if a workspace root ever appears above the
crate the binary does not silently relocate again.

Path audit, closed: the cargo output directory was the only cwd-dependent path
in the file. Every other path — intent, intent/15-evaluation/semantic-review,
intent/16-enforcement/review-result.schema.json, report.json, graph.json — is
relative to the checkout root, and each was verified against the real tree.

Why the checks look paranoid

intent check exits 0 on an empty directory and on a directory holding no VRS
artifacts, so "the check passed" cannot by itself distinguish a healthy corpus from
a missing one. Porting the assertion as-is would reproduce a known silent-pass class.

So corpus-strict asserts the corpus exists before checking, and afterwards asserts
the derived graph is non-empty. The graph is what discriminates: it is empty for both
an empty directory and a wrong path, and non-empty only when artifacts were genuinely
read. semantic-review-fixtures fails when it finds zero fixtures for the same
reason — a loop that is green over nothing is the same silent pass.

The jobs are deliberately kept separate and separately named rather than
collapsed behind a single gate, so a run shows which one concluded and how.

Behavior change: enforcement assets resolve under the corpus

review resolves 16-enforcement/review-prompt.md and
16-enforcement/review-result.schema.json relative to the corpus root, not the
enclosing repository. A corpus without its own 16-enforcement/ now fails rather
than quietly borrowing the repository's copies — silently falling back produced a
review graded against a rubric the corpus never declared.

Exit 2, naming both the missing asset and the corpus it was missing from:

$ intent review ./some-corpus
axe vrs review: missing review asset 16-enforcement/review-prompt.md under corpus /abs/path/to/some-corpus

The asset alone would not say which corpus was searched; the root alone would not say
what it was expected to contain. Documented in crates/intent/README.md.

Verified locally before pushing

From a clean checkout root, against this repo's actual corpus:

Check	Result
cargo metadata --locked	lock satisfies --locked
cargo test --locked	8 passed, 0 failed
check intent --profile strict --json	exit 0, 0 diagnostics
graph intent --json	246 nodes / 215 edges (non-vacuous)
5 fixtures vs enforcement schema	all 5 validate, each with ≥1 finding
actionlint on both workflows	clean
cargo clippy --all-targets -D warnings	clean
cargo fmt --check	clean
nix flake check	all 5 checks pass
checks.reads-the-corpus	packaged binary reports 246 nodes

The Nix build's test phase was checked in the derivation log rather than assumed: it
runs all 8 tests, so doCheck is not silently vacuous here either.

check-jsonschema runs fully offline — every schema is a local file, so none is ever
fetched.

Packaging, and why the nix lane is its own workflow

Two attributes are needed to package a crate that is not at the repository root, and
they are not the same knob — this is the part that is easy to get wrong:

• buildAndTestSubdir moves only the build and test phases.
• cargoSetupPostPatchHook still reconciles the vendored lockfile against
  $sourceRoot/Cargo.lock — the repository root — and fails with "Missing Cargo.lock
  from src". cargoRoot is what points that reconciliation at the crate.

src stays the whole repository on purpose, so the corpus at intent/ remains visible
to a check aimed at it from the same source tree. That is what checks.reads-the-corpus
uses to prove the packaged binary reads real artifacts, not merely that it compiles.

The lane is a separate workflow rather than a job inside ci.yml. Running the corpus
gates through nix flake check would collapse corpus-strict and
semantic-review-fixtures into a single check named check, and a run would no longer
show which gate concluded and how. Folding a multi-minute Nix build in beside the fast
corpus gates would couple them for no benefit. This lane packages the CLI and re-gates
nothing.

Two deliberate changes to the lifted source

Both are called out rather than buried, because this is a lift whose acceptance bar is
that axe vrs behaves identically:

• Comments. The block comments carried hand-aligned continuation lines that rustfmt
  de-indents to column 0 — which reads worse than what it replaced. Rather than commit
  that, or drop the fmt gate, they became line comments, which rustfmt leaves alone.
  Wording is unchanged.
• Clippy. automated_context_indicator becomes the Iterator::find it was already
  written as by hand. require_section keeps its eight arguments under an explicit
  #[allow(clippy::too_many_arguments)] with the reason inline: regrouping them is a
  refactor motivated only by a style lint, and doing it inside a lift would make any
  resulting regression unattributable. Worth doing later, on its own.

The integration suite that stayed behind — and what did not travel

The checker was lifted into this crate but its integration suite was not: 19 tests in
flakes/axe/tests/vrs_check.rs stayed in schickling/dotfiles and drive the axe
binary. They are the differential oracle for the extraction, so a tool whose real test
suite lives in its own consumer is backwards — and invisible until the day that
consumer stops depending on it.

10 of the 19 travelled. The other 9 did not, and crates/intent/tests/vrs_check.rs
names each one and why, rather than presenting a suite that looks complete:

Ported	8 check/graph tests + the 2 review tests that refuse before CAIC runs
Omitted	9 tests that drive review / review-fixtures through the CAIC runner

The omitted 9 assert on the CAIC envelope itself — coding_agent.result.v1,
run.context_files, run.permission.effective. CAIC is a separate binary
(coding-agent, a shim over axe::caic) owned by axe. This crate builds no such
binary, and lifting caic here would invert the settled dependency: axe consumes
intent, not the reverse. A stub could only make them pass by reimplementing the
collaborator under test — the "green because the hard cases were dropped" failure in a
more expensive disguise.

They stay green in axe's own suite, so the behaviour is still covered — but only
while axe keeps consuming this crate. Closing that properly needs a CAIC boundary
this crate can drive on its own.

The corpus-relative asset resolution the lift introduced was checked rather than
assumed: the harness helpers pass repo/context/vrs — a corpus root, not a repository
root — and build 16-enforcement/ underneath it, which is what resolution now requires.
--coding-agent is handed a deliberately non-existent path, so if a test ever needs it
to execute, that test does not belong in this file.

Totals: 8 unit + 10 integration, passing natively and inside nix flake check,
where the sandbox runs the exec'd fake providers without complaint.

About the CI runs

concurrency.cancel-in-progress: true means each push cancels the run in flight, and a
cancelled run demonstrates nothing — the citable run is the last one on this branch.

The materialises job answers a question that is not a given: does this repository
materialise jobs at all? A run object can exist with zero jobs, and that is how a
sibling repo's CI sat "queued" for a month unnoticed. It does — 4 jobs in the ci run
and 1 in the nix run, all concluding.

A README-only commit from another agent landed on this branch as expected. It was kept
and rebased onto, not reverted.

Not in scope here

• Merging. This repo is private and stays private; the merge is not the author's.
• Renaming axe.vrs.check.v1 or the AXE.VRS-R* ids — a separate coordinated pass,
  and renaming now would cost the differential oracle these checks depend on.
• crates.io publication or a release workflow. Distribution is the flake only.

Posted on behalf of @schickling

field	value
agent_name	unknown
agent_tool	Claude Code
agent_tool_version	2.1.220
agent_runtime	Claude Code 2.1.220
agent_session_lookup	unavailable
tooling_profile	dotfiles@unknown-dirty