ChangeClause

Three changes. One contract.

Missing required scenario

INCOMPLETE

The storage-failure scenario is missing. A green test run covers fewer obligations.

2 of 2 tests pass.

Full INCOMPLETE report ↗

These are captured fixture results from the CLI. The two linked demo PRs use the same code and contract and were also verified separately against their Git merge base. The source is synthetic and deliberately small. A passing result covers the selected contract, not every possible behavior.

01 / The implementation

Two extra lines cross the boundary.

The drifting version adds the authentication import and sessionTag() call. The helper simply returns a string, so the signup tests stay green. The violation is the declared architectural boundary—not proof of a security flaw.

src/newsletter.ts · drifting version

import { sessionTag } from './auth.js';
import type { NewsletterStore } from './storage.js';
export async function subscribe(
  email: string,
  store: NewsletterStore,
): Promise<string> {
  if (!/^[^@\s]+@[^@\s]+\.[^@\s]+$/.test(email))
    throw new Error('invalid_email');
  sessionTag();
  await store.put(email);
  return 'subscribed';
}

Passing source · Drifting source · The three tests · Authentication helper

02 / The contract

Make the boundary explicit.

The schema 0.2 contract forbids a runtime dependency from src/newsletter.ts to src/auth.ts. It also requires the handler and its call to signup, preserves the health API signature, and names three executed test scenarios.

Read the complete executed contract
schema: '0.2'
change:
  name: Newsletter signup with executed evidence
  intent: Validate email and store subscriptions without authentication coupling.
scope:
  allowed:
    [src/newsletter.ts, src/handler.ts, src/newsletter.test.ts, tsconfig.json]
requires:
  - id: handler
    match: { kind: api, file: src/handler.ts, name: post }
  - id: handler-calls-subscribe
    match:
      {
        kind: resolved-call,
        file: src/handler.ts,
        from: 'src/handler.ts#post',
        to: 'src/newsletter.ts#subscribe',
      }
forbids:
  - id: no-auth-boundary
    match:
      {
        kind: dependency,
        file: src/newsletter.ts,
        to: src/auth.ts,
        typeOnly: false,
      }
preserves:
  - id: health-api
    match: { kind: api, file: src/health.ts, name: health }
evidence:
  - id: stores-email
    stage: test
    method: execution
    scenario: successful_signup
    file: src/newsletter.test.ts
  - id: rejects-invalid-email
    stage: test
    method: execution
    scenario: invalid_email
    file: src/newsletter.test.ts
  - id: propagates-storage-failure
    stage: test
    method: execution
    scenario: storage_failure
    file: src/newsletter.test.ts

Download the contract ↗

For this controlled fixture, the same known contract is explicitly selected as candidate and approved input. That demonstrates evaluation; it does not establish authenticated approval.

03 / Reproduce the run

Run the code. Inspect the result.

Clone the public MVP repository and use Node 24 with pnpm 10.29.3. Check out the public revision used for these results:

git checkout b2925f9e6433cc94d5bbb2224dbb1143cc5704b5
pnpm install --frozen-lockfile
pnpm build
pnpm qualify

The qualification script explicitly runs Vitest, imports its JSON results, then verifies the contract. It also checks an aliased dependency and two deliberately broken implementations. Review and verify themselves do not execute the analyzed code.

What this evidence does—and does not—establish
  • Static analysis observes the forbidden dependency in the candidate source.
  • Imported test results report execution of the named scenarios. They are self-attested, not signed CI attestations.
  • Missing execution evidence produces UNKNOWN; a test definition alone is insufficient.
  • No runtime trace, deployed service, real email, customer data, or hosted repository access is involved.
  • The capture uses directory snapshots from the pinned MVP revision. The linked PRs have separate Git-based verification; these downloadable reports describe the fixture run.

What boundary would matter in your review?

Share a change where passing tests left an important question unanswered. A sanitized description is enough.

Share a real change ↗