Scope guard for AI-written changesField notes / 002

The diff changed.
What else did?

Your agent says it is done. ChangeClause checks the claim. It checks the finished change against the spec you agreed before the agent started: changed files, criteria, and boundaries.

Early CLI from source today. Homebrew, curl, and npm installs are coming soon.

Worked example / 01 Executed CLI · synthetic fixture

Requested change

“Add signup. Keep authentication out.”

TypeScript

01 / Agreed spec

Validate an email and store the subscription.

The signup module must not depend on authentication. Keep the existing health API unchanged.

See the actual contract
forbids:
  - id: no-auth-boundary
    match:
      kind: dependency
      file: src/newsletter.ts
      to: src/auth.ts
      typeOnly: false

02 / Check results

DRIFT

Signup now imports authentication code.

The change adds import { sessionTag } from './auth.js'. That crosses the forbidden dependency boundary.

TypeScript analysis · src/newsletter.ts:1

3/3 tests

The behavior tests still pass.

Successful signup, invalid email, and storage failure all pass. Passing tests do not cancel the boundary finding.

Executed Vitest results · imported evidence

Inspect the evidence

Read the code, contract, and full results ↗
A reproducible synthetic example, not a customer incident.

01 / The problem

The tests pass.
You still cannot tell.

You ask a coding agent for a change. It returns a large PR. The tests pass. You still cannot tell:

  • which changes were necessary for the request,
  • which acceptance criteria have evidence behind them,
  • what else it touched: a new dependency, a crossed module boundary, an edited migration, a rewritten plan.

Review bots give an opinion. They read the diff and comment on it. They do not hold the change to what was agreed.

02 / How it works

Agree the scope.
Then check the change.

  1. 01

    Agree the scope.

    Before coding, the agent drafts a short spec: outcome, acceptance criteria, allowed areas, non-goals, and what must stay unchanged. A person approves it. The person approves; the person does not author.

    Spec + contract
  2. 02

    Build.

    The agent works as usual. The spec stays the reference.

    Your agent, your repo
  3. 03

    Check.

    ChangeClause compares the finished change with the agreed spec, mechanically:

    • Every changed file is checked against the agreed scope.
    • Every criterion in the contract needs evidence (a test, a check, a record), or ChangeClause flags it.
    • Forbidden dependencies, boundaries, and preserved APIs hold.
    • Anything it cannot decide stays UNKNOWN, never a silent pass.
    Findings with evidence

PASS · INCOMPLETE · DRIFT · UNKNOWN · ERROR

Local and deterministic. No LLM in the check, no account.

Evidence has edges. A passing check supports a claim only within its scope. Untested behavior stays unknown.

03 / What it catches

The agent says done.
The check disagrees.

Three illustrative scenarios. Recognize one? Send us a similar change and tell us what made it difficult to review.

A / Out-of-scope files

“Fix the typo.”

It also refactored the auth module.

What does the check report?
Finding
Changed files in the auth module fall outside the agreed scope.
Result
DRIFT
Share an out-of-scope example
B / Claim without evidence

“All criteria met.”

One acceptance criterion has no test.

What does the check report?
Finding
The claim for that criterion has no evidence: no test, check, or record backs it.
Result
INCOMPLETE
Share a missing-evidence example
C / Unapproved dependency

“Tests pass.”

It added a dependency that nobody approved.

What does the check report?
Finding
The change adds a dependency that the spec does not allow.
Result
DRIFT
Share a dependency example
04 / Real-world signal

The plan followed the code,
not the other way around.

We looked at 16 plan-linked PRs in a production Astro and Cloudflare app built mostly by coding agents.

16 of 16
changed files that their plan phase did not name. That is 164 of 218 changed files; about half were tests, fixtures, and translations.
15 of 16
rewrote the plan in the same PR to match the code.
6 of 16
started from a plan phase that named no files at all.

One project, one sample. These numbers describe one codebase. They show the pattern ChangeClause checks for; they do not measure every team.

Get updates

Hear when
you can install it.

We will write when there is something to try: new releases, install options as they ship, and results from real changes. No other use of your address.

Help choose the next check

Bring a change
that was hard to review.

What did you ask the agent for? What did it change? What was hard to confirm? A few sentences about a real review help us decide what to build next.

Share a change

A short form. Email is optional. A public link or sanitized description is enough.