Two PRs. One contract.

Actual GitHub Actions results: both changes pass their behavior tests. Only one stays within the declared boundary.

Captured September 21, 2026 from the exact runs linked above. These are synthetic examples, not a live status feed. Imported test evidence remains self-attested. Run metadata and report hashes ↗

Also see a missing-evidence fixture

The local INCOMPLETE fixture passes 2 of 2 tests but omits the required storage-failure scenario. Read its fixture report. This report comes from the separate local fixture run, not either Actions run above.

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';
}

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 ↗

The CI runs select the approved contract from the Git merge base and compare it with the candidate at the tested head. This is explicit baseline selection, not authenticated approval.

03 / Reproduce the run

Run the code. Inspect the result.

Reproduce the exact CI runs, or run the local qualification fixtures below. Use Node 24 and pnpm 10.29.3 with the public MVP revision used by the examples:

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 two result cards preserve Git-based reports from the linked Actions runs. The additional INCOMPLETE report uses a separate local directory fixture.

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 ↗