ChangeClause
Software intent verificationField notes / 001

The diff changed.
What else did?

Declare what a change should do and what must stay true. ChangeClause compares those claims with evidence so you can review unexpected changes before merging.

Early local CLI · looking for real changes to evaluate.

PR checks for what must stay true.

See the MVP in action
MVP example / 01 Executed CLI · synthetic fixture

Requested change

“Add signup. Keep authentication out.”

TypeScript
MVP 0.1.0

01 / Declared intent

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 clause 
forbids:
  - id: no-auth-boundary
    match:
      kind: dependency
      file: src/newsletter.ts
      to: src/auth.ts
      typeOnly: false

02 / Actual MVP results

DRIFT

Signup now imports authentication code.

The candidate adds import { sessionTag } from './auth.js'. That crosses the explicitly 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. Their results do not cancel the dependency violation.

Executed Vitest results · imported, self-attested evidence

Inspect the evidence

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

01 / The approach

Make “only”
a checkable claim.

Tests can pass while permissions expand or behavior drifts beyond a change’s purpose. Start with explicit constraints and bring the evidence into the review.

  1. 01

    Declare the boundary.

    Turn declared intent into machine-checkable constraints: “Add newsletter signup; keep authentication out.”

    Intent + constraints
  2. 02

    Compare the evidence.

    Check supported TypeScript dependencies and APIs. Import the results of explicitly run tests; missing evidence stays unknown.

    Base → candidate
  3. 03

    Review the discrepancy.

    See violations, supported claims, and unknowns before merging. Fix the change, amend its intent, or investigate further.

    A decision with reasons

Available now: an early local CLI for bounded TypeScript/JavaScript changes, with static checks and imported test results. The runtime and configuration examples on this page show directions to explore.

Explore the CLI on GitHub

Evidence has edges. A passing check only supports a claim within its scope. Each result needs a revision, environment, and coverage boundary. Untested behavior stays unknown.

02 / Where to look

Ordinary changes.
Unexpected reach.

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

A / CI permissions

“Just speed up the build.”

A caching change also broadens the job token from read to write.

What would we check?
Constraint
Effective repository permissions must not increase.
Evidence to inspect
Resolved workflow permissions at the base and candidate revisions.
Share a CI example
B / Runtime behavior

“Just add retries.”

A retry policy causes a payment request to execute twice after a timeout.

What would we check?
Constraint
One logical request produces at most one charge.
Evidence to inspect
Fault-injection traces and idempotency behavior for the exercised scenarios.
Share a runtime example
C / Configuration

“Just update the defaults.”

A service starts listening on every interface instead of loopback.

What would we check?
Constraint
The service must remain reachable only from the host.
Evidence to inspect
Effective bind configuration and observed sockets in the test environment.
Share a configuration example

Help choose the first useful check

Bring a change
that was hard to review.

What was supposed to change? What needed to stay true? A few sentences about a real review will help us decide what to build first.

Share your example

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