# V3 x402 website compatibility inspection — 2026-08-25

## Scope boundary

This inspection treats `theloopbreaker.com`, its V2 APIs, and its V2 playground
as a protected production compatibility baseline.

No file in any of these areas was edited:

- `repos/theloopbreaker-site/app/api/x402/**` outside the pre-existing isolated
  `app/api/x402/v3/_lib/receipt-store.ts`;
- the V2 playground or any website navigation, copy, route, endpoint, contract,
  or deployment configuration;
- `repos/vaultfire-x402/**`;
- Base contracts;
- `repos/vaultfire-solana/**`.

No public request that could write, pay, sign, connect a wallet, settle,
broadcast, or deploy was issued. No deployment, commit, or push was performed.
The production V2 discovery endpoint and playground were not changed or
characterized as broken.

## Exact V3 source/build/deployment boundary

The repository has three different V3 x402 layers, and they are intentionally
not equivalent to a live production implementation:

1. `pr7/generated/route-registry.json` records four V3 candidates:
   `GET /api/v3/protocol/solvency`, `GET /api/v3/protocol/status`,
   `GET /api/v3/mandate/:mandateHash`, and
   `POST /api/v3/x402/actions/create-partnership-bond`.
2. `pr7/generated/coinbase-bazaar-v2.json` publishes local candidate metadata
   for the two priced V3 resources. It labels its state
   `metadata-candidates-not-live-validated`.
3. The website contains no matching route handler under `app/api/v3/**`.
   `repos/theloopbreaker-site/middleware.ts` matches
   `/api/v3/x402/:path*` and returns the release-closed 503 response, while the
   other three candidate paths have no checked-in website implementation.

The only V3-namespaced website x402 implementation file is
`repos/theloopbreaker-site/app/api/x402/v3/_lib/receipt-store.ts`. It has no
route handler and no import from a V2 handler. Repository consumers are limited
to the V3 receipt-store tests. Therefore it cannot make a V3 endpoint live by
itself.

This is a candidate-metadata versus materialized-route boundary, not a V2
playground defect. The existing readiness labels are appropriately
fail-closed:

- `operatingPolicy.v3DefaultState`: `fail-closed`;
- `operatingPolicy.v3LiveReadiness`:
  `not-established-by-this-inventory`;
- `discoveryPublication.liveIndexingOrSettlementProven`: `false`;
- Bazaar `publicationState`: `metadata-candidates-not-live-validated`.

## Additive V3-only regression protection

Added:

- `pr7/tests/x402/x402-v3-website-isolation.spec.ts`

The four deterministic checks protect these boundaries:

1. no protected V2 x402 handler imports the isolated V3 receipt store;
2. the two priced V3 candidates remain non-materialized while readiness is
   explicitly unestablished and fail-closed;
3. Bazaar output remains labeled local and not live-validated, with no indexing
   or settlement claim;
4. the `/api/v3/x402/**` namespace remains covered by the website release gate.

The test adds no runtime code, endpoint, UI, build output, or deployment change.

## Verification results

Run from `pr7` with its pinned Vitest configuration:

```text
vitest run tests/x402/x402-v3-website-isolation.spec.ts
PASS: 1 file, 4 tests

vitest run \
  tests/x402/x402-receipt-store.spec.ts \
  tests/x402/x402-receipt-store.multiprocess.spec.ts \
  tests/x402/x402-payment-security.spec.ts \
  tests/api/v2-v3-compatibility-matrix.spec.ts
PASS: 4 files, 52 tests

tsc --project pr7/tsconfig.json --noEmit
PASS
```

The compatibility generator check was also run read-only:

```text
python3 pr7/compat/build-v2-v3-compatibility-matrix.py --check
FAIL: V2/V3 compatibility outputs are stale:
pr7/compat/compatibility-discovery-v2-v3.json
```

The stale delta is unrelated to this inspection's new test. The builder now
discovers an additional file in the default SDK surface,
`repos/vaultfire-sdk/src/baseSepoliaV3Rehearsal.ts`, which changes the generated
`sdk.v2DefaultPackages[0].surface` inventory from five entries to six and shifts
the subsequent array positions. Regenerating that artifact would rewrite a
mixed V2/V3 compatibility record based on an SDK path outside this task's
allowed edit boundary, so it was deliberately not regenerated.

## Workspace concurrency note

The worktree was clean when this inspection began. During testing, unrelated
changes appeared under `repos/vaultfire-solana/**` and
`v3-src/contracts/bonds/AccountabilityBondV3Safe.sol`. They were not created,
read for modification, staged, reverted, or otherwise touched by this work.
The only files added by this inspection are this report and
`pr7/tests/x402/x402-v3-website-isolation.spec.ts`.

## Deployment boundary and required confirmation

There is no runtime website change to deploy from this inspection. A Vercel
deployment would therefore be unnecessary and was not attempted.

Before any future Vercel deployment, explicit user confirmation would be
required for:

1. the exact reviewed diff and whether it is an additive V3 content-only change
   or an actual V3 route activation;
2. the target Vercel project, team, environment, domain, and production versus
   preview scope;
3. any environment-variable additions or use of existing KV/Upstash
   credentials;
4. any change from candidate metadata to a live/readiness claim;
5. any V3 route activation, allowlist, payment challenge, facilitator,
   settlement, receipt, wallet, signing, or spending plan.

Actual wallet connection, signing, payment, settlement, broadcasting, or a
production deployment must remain separate, explicitly confirmed actions.
