docs(x402): record the self-facilitated settlement; split the two claims

PRODUCT.md

@@ -38,7 +38,7 @@ The demo thesis, in the team's own words: *"We gave our AI business zero dollars
 - Nine surfaces: Overview, Jobs, job detail, Approvals, Float, Portal (customer), Audit, Workforce, Settings.
 - Money is always atomic USDC — six decimal places, carried as base-10 strings or integers. Never a float, anywhere, including in display code.
 - Contracts are frozen: JobVault (escrow), FloatPool (advance vault), AuditAnchor. An advance is capped at 10% of pool TVL per org and 80% utilisation pool-wide; the fee is 2% of principal and 20% of that fee goes to a first-loss reserve.
-- **No payment has settled through the x402 agent-purchase path, and no end-to-end run has ever been logged.** The facilitator client exists but has never run against Circle. Surfaces must not imply otherwise.
+- **A 0.04 USDC agent purchase has settled end to end through the x402 path, self-facilitated (`docs/spine-runs/2026-08-08-first-x402-settlement.md`). Separately, the Circle Gateway facilitator client is built and has never run against Circle's live service.** These are two independent facts — settlement did not require Gateway — and surfaces must state both, implying neither's reverse.
 - Two figures on Overview are read live from the chain and are real today (pool TVL, advance rate). Most other panels have no data until a run happens.
 - Sample data is permitted **only** behind an explicit flag stripped from the deployed artifact, following the existing `SNAPFALL_DEMO_STREAM` precedent. This was a deliberate operator decision, taken after the risk was raised.
 
@@ -53,7 +53,7 @@ The demo thesis, in the team's own words: *"We gave our AI business zero dollars
 
 - Real settlement transactions on Arc testnet, with block numbers and explorer links (`docs/CP2-SUBMISSION.md`, `docs/addresses.md`). Two jobs have run the full on-chain lifecycle: funded, worked, delivered, accepted, settled.
 - Live contract reads: pool TVL (~20.02 USDC at time of writing), advance rate, utilisation, fees accrued.
-- **Absences that must never be fabricated:** no x402 purchase has settled; no spine run has been logged (`docs/spine-runs/` holds only `.gitkeep`); the compliance screen is a labelled stub returning `not-screened`; discovery is a local TF-IDF ranker, not the Circle Agent Marketplace; USYC is a mock strategy. These are documented as honest gaps and the interface must not contradict them.
+- **Absences that must never be fabricated:** the Circle Gateway facilitator has never run against the live service (settlement so far is self-facilitated); the compliance screen is a labelled stub returning `not-screened`; discovery is a local TF-IDF ranker, not the Circle Agent Marketplace; USYC is a mock strategy. These are documented as honest gaps and the interface must not contradict them.
 
 ## Product Principles
 

dashboard/app/page.tsx

@@ -188,10 +188,12 @@ export default function LandingPage() {
           What is not proven yet
         </h2>
         <p className="lp-body">
-          No agent purchase has settled through the x402 payment path, no end-to-end run has been
-          logged, and compliance screening is a labelled stub that fabricates no result. A product
-          about verifiability should be easiest to check where it is weakest, so the full list is
-          on the audit page beside the evidence.
+          A 0.04 USDC agent purchase has settled end to end on Arc through the x402 path,
+          self-facilitated — its transaction is on the audit page. What is still not proven: the
+          Circle Gateway facilitator path is built and has never run against the live service, and
+          compliance screening is a labelled stub that fabricates no result. A product about
+          verifiability should be easiest to check where it is weakest, so the full list is on the
+          audit page beside the evidence.
         </p>
         <Link className="lp-alt" href="/audit">
           Read the gaps

docs/CIRCLE-FEEDBACK.md

@@ -115,15 +115,21 @@ itself the feedback.
 loop was the easy part; the settlement onboarding is where we stalled. The broadcast path is
 built — `sidecar/src/facilitator.ts` (landed 2 Aug) calls Circle's Gateway `settle` endpoint
 and reads `CIRCLE_API_KEY` — but it has **never run against the live Circle service**. It is
-dormant without a key, so our seller reports `settlement: NOT_BROADCAST` and **no x402 purchase
-has ever settled**; the loop is cryptographically end to end and financially a dry run, stated
-plainly in `docs/CP2-SUBMISSION.md` and `docs/PRD.md` §0.1. Two honest consequences: the wire
+dormant without a key, so with Gateway as the configured facilitator the seller reports
+`settlement: NOT_BROADCAST` and **the Gateway path has never settled a payment**. We reached
+SETTLED a different way — **self-facilitating the EIP-3009 authorization** (broadcasting
+`transferWithAuthorization` directly, no Gateway): a real 0.04 USDC x402 payment settled on Arc
+(`docs/spine-runs/2026-08-08-first-x402-settlement.md`). So the loop is now end to end both
+cryptographically and financially; what has never run is the Gateway integration specifically,
+stated plainly in `docs/CP2-SUBMISSION.md` and `docs/PRD.md` §0.1. Two honest consequences: the wire
 contract we coded against Circle's documented interface — the request/response field names — is
 an **assumption until that first live call**, which is the actual test; and a *green CI check on
 the facilitator path is not evidence the broadcast works*, because that path has never touched
-the real endpoint. Getting to a live settlement needs a human-gated setup we could not complete
+the real endpoint. Getting to a live *Gateway* settlement needs a human-gated setup we could not complete
 in the timebox: a Circle account, terms acceptance, an API key, a funded Agent Wallet, and a
-spend policy (`docs/V3-CIRCLE-SETUP.md`). Two smaller frictions compound it: the protocol ships
+spend policy (`docs/V3-CIRCLE-SETUP.md`). **x402 settlement itself required none of that** — an
+EIP-3009 authorization is a bearer instrument, so we broadcast it ourselves; the gate is on
+Gateway, not on x402. Two smaller frictions compound it: the protocol ships
 in **two coexisting transport versions** (v1 carries the challenge in the 402 *body*, v2 in a
 `payment-required` *header*) that a seller must emit both of; and Circle's Gateway facilitator
 lives at a **distinct endpoint** (`gateway-api-testnet.circle.com/gateway/v1/x402/*`) separate

docs/CP2-SUBMISSION.md

@@ -110,9 +110,10 @@ movement and the hashes that anchor it.
 - **USDC** — escrow, advances, waterfall settlement, agent purchases
 - **x402 nanopayments** — agents pay per-call for data through the sidecar, under
   deterministic per-category spending caps with human approval escalation
-- **Circle facilitator** — the sidecar calls Circle's Gateway x402 `verify` and `settle`
-  endpoints, and the endpoints themselves are contract-asserted in CI (AT-18). **No x402 payment
-  has settled on chain yet**; see gaps.
+- **Circle facilitator** — the sidecar's Gateway client calls Circle's Gateway x402 `verify` and
+  `settle` endpoints, and the endpoints themselves are contract-asserted in CI (AT-18). **A 0.04
+  USDC x402 payment has settled on chain — self-facilitated, not through Gateway; the Gateway
+  `settle` call is built and has never run against the live service. See gaps.**
 - **USYC** — idle-float yield strategy (currently a mock strategy; see gaps)
 
 ### Both tracks, one system
@@ -149,14 +150,18 @@ We would rather state these than have them found.
   expense, but it is not yet joined to the daemon's own purchase provenance — so an
   expense recorded via CLI surfaces correctly as outside-policy in the invoice. Settlement
   ordering is enforced; expense origination is not yet fully attested.
-- **No x402 purchase has settled.** This is the honest state of the agent-payment leg. The full
-  402 → sign → retry → 200 loop is real and runs end to end, with the EIP-3009 authorization
-  signed by a real key and verified by the seller. What has never happened is the broadcast: the
-  Circle facilitator client was written on 2 Aug 2026 (`sidecar/src/facilitator.ts`) and has
-  never run against the live service, because that needs a Circle account and API key we do not
-  have yet. Without a key the seller reports `settlement: NOT_BROADCAST` and the fixture capture
-  refuses to write evidence. So the loop is cryptographically end-to-end and financially a dry
-  run, and the settlement code is unproven rather than proven.
+- **A 0.04 USDC x402 purchase has settled, self-facilitated. The Circle Gateway path is built and
+  has never run.** Two independent facts. The full 402 → sign → retry → 200 loop is real and runs
+  end to end, with the EIP-3009 authorization signed by a real key and verified by the seller —
+  and that authorization was then **broadcast directly** (`transferWithAuthorization`), settling
+  0.04 USDC operator → seller on Arc ([`0x0d39b5…dccc`](https://testnet.arcscan.app/tx/0x0d39b5738f7042ae82ae0a17f24474e67c27db0cd837b791c112f8d264b6dccc);
+  `docs/spine-runs/2026-08-08-first-x402-settlement.md`). Settlement did not require Gateway.
+  Separately, the Circle Gateway facilitator client (written 2 Aug, `sidecar/src/facilitator.ts`)
+  has never run against the live service — that path needs a Circle account, key, and Gateway
+  allowlisting we do not have. A self-facilitated settlement is marked as such (`self:` facilitator
+  markers), and the fixture capture (AT-18) refuses it as *Circle* evidence. So the loop is now
+  end to end both cryptographically and financially; what stays unexercised is the Gateway path
+  specifically, not settlement itself.
 - **No end-to-end spine run has been logged.** `docs/spine-runs/` is empty. The harness exists
   (`scripts/spine_run`) and can now run against the pool we already hold (`--scaled`), but the
   claim "green on N consecutive days" is not one we can make.

docs/HARD-QUESTIONS.md

@@ -134,9 +134,12 @@ you are asked.
 
 ## 5. Can we see it run?
 
-Be straight about the state of this. As of 3 Aug 2026 no end-to-end spine run has been logged
-(`docs/spine-runs/` holds only `.gitkeep`), and no agent purchase has settled through x402 — the
-facilitator client exists and has never run against Circle, so the seller records `NOT_BROADCAST`.
+Be straight about the state of this. As of 8 Aug 2026 spine runs have been logged (`docs/spine-runs/`;
+first automated settlement 2026-08-07), and a 0.04 USDC agent purchase has settled through x402,
+self-facilitated (`docs/spine-runs/2026-08-08-first-x402-settlement.md`) — the authorization was
+broadcast directly, not through Gateway. Separately, the Circle Gateway facilitator client is built
+and has never run against Circle's live service; under that facilitator with no key the seller
+records `NOT_BROADCAST`. Two independent facts: settlement happened, and it did not use Gateway.
 
 What *has* happened, on chain, is the full money lifecycle for two jobs: fund → advance → expense →
 delivery → accept → waterfall → rate rise. What has not happened is the agent-payment leg settling

docs/PRD.md

@@ -56,7 +56,7 @@ a **committed artifact**. Code cannot satisfy those. A green CI run is not evide
 | V1 real four-cent purchase + committed fixture | V3, then a live capture. `capture-v1-fixture.ts` refuses to write a fixture without a real transaction hash from Circle's endpoints (refusals 5–7). |
 | V7 / V10 / V11 "renders live" | One green spine run with a human watching. |
 | V12 reset → spine → reset → spine | Two consecutive green runs. |
-| Spine runs (schedule, §16) | **First automated settlement logged 2026-08-07, verdict UNVERIFIED** — the waterfall settled on chain and only the x402 beat is unproven (settlement rests at `NOT_BROADCAST`, pending a funded Circle Gateway deposit). **Three prior FAIL runs the same day** are recorded in `docs/spine-runs/spine-runs.tsv` and kept deliberately: the live runs surfaced what CI could not — the missing `startWork`/`submitDelivery` caller, and an operator-owned pool. **No daily cadence exists**: the Wed 29 Jul gate was missed; runs are on-demand, not scheduled. |
+| Spine runs (schedule, §16) | **First automated settlement logged 2026-08-07, verdict UNVERIFIED** — the waterfall settled on chain; the x402 beat rested at `NOT_BROADCAST` in that run (Gateway facilitator, no key). **The x402 beat has since settled separately**: a real 0.04 USDC x402 payment settled on Arc 2026-08-08, **self-facilitated** — broadcasting the EIP-3009 authorization directly, not through Circle Gateway, which is built and has never run against the live service (`docs/spine-runs/2026-08-08-first-x402-settlement.md`). **Three prior FAIL runs the same day** are recorded in `docs/spine-runs/spine-runs.tsv` and kept deliberately: the live runs surfaced what CI could not — the missing `startWork`/`submitDelivery` caller, and an operator-owned pool. **No daily cadence exists**: the Wed 29 Jul gate was missed; runs are on-demand, not scheduled. |
 
 **Known gaps carried deliberately**
 
@@ -317,7 +317,7 @@ Worker need = a fuzzy description, vectorised and similarity-matched against a s
 |---|---|
 | Brain (control plane) | Circle CLI + Circle Skills |
 | Funding agent | Circle Agent Wallet spend-policy (outer guard) + deterministic policy engine (inner) |
-| DD-worker discovery + purchases | Circle Agent Marketplace *(discovery: **roadmap** — the shipped code embedding-matches against a local stand-in catalog, our own V2 paid API, behind a `Catalog` seam built for the marketplace; no marketplace API is integrated today)* + **Circle's Gateway x402 facilitator** — **never** the generic x402.org facilitator or another vendor's (Coinbase/Stripe/Cloudflare also implement x402; judges score *Circle's* tools). *Integration detail, stated precisely because it is judge-facing: we call Circle's documented Gateway x402 `verify` and `settle` endpoints directly over HTTP (`sidecar/src/facilitator.ts`, endpoints pinned in `circle-facilitator-fixture.ts` and asserted by AT-18). We do **not** depend on the `@circle-fin/x402-batching` package, which earlier drafts of this table named. As of 2 Aug 2026 that client is written but has never run against the live service — it is dormant without `CIRCLE_API_KEY`, and no payment has settled.* |
+| DD-worker discovery + purchases | Circle Agent Marketplace *(discovery: **roadmap** — the shipped code embedding-matches against a local stand-in catalog, our own V2 paid API, behind a `Catalog` seam built for the marketplace; no marketplace API is integrated today)* + **Circle's Gateway x402 facilitator** — **never** the generic x402.org facilitator or another vendor's (Coinbase/Stripe/Cloudflare also implement x402; judges score *Circle's* tools). *Integration detail, stated precisely because it is judge-facing: we call Circle's documented Gateway x402 `verify` and `settle` endpoints directly over HTTP (`sidecar/src/facilitator.ts`, endpoints pinned in `circle-facilitator-fixture.ts` and asserted by AT-18). We do **not** depend on the `@circle-fin/x402-batching` package, which earlier drafts of this table named. As of 2 Aug 2026 that client is written but has never run against the live service — it is dormant without `CIRCLE_API_KEY`. Settlement itself is not blocked on it: a 0.04 USDC x402 payment has settled on Arc self-facilitated (2026-08-08), broadcasting the authorization directly; the Gateway client specifically remains unexercised.* |
 | Compliance step | Circle Compliance Engine *(**seam only — not integrated**. The shipped screen is `worker.StubCompliance` (`daemon/internal/worker/worker.go:178`), wired at `daemon/cmd/snapfall/main.go:759`, which fabricates nothing: decision `not-screened`, provider `stub`, `stub: true`. No Compliance Engine client or endpoint exists in the tree. What IS real: the screen runs as a task step, the report carries "evidence, not a guarantee", and QA reads the stub flag and attaches a disclosure note rather than passing it silently. Unlike the facilitator this is not credential-blocked — no client has been written.)* |
 | Billing agent | Arc Explorer + Gateway settlement records |
 | JobVault / FloatPool / Waterfall | **Ours** — Arc supplies sub-second finality + USDC-native gas; the primitive is our own engineering |
@@ -470,7 +470,7 @@ AT-01..15 remain in force from the v4 SRS annex, with AT-10 extended (restart re
 - Restart recovery demonstrated, including Brain.
 - Secret audit clean.
 - Full reset rehearsed twice (reset ×2).
-- Spine runs: first automated settlement 2026-08-07, verdict UNVERIFIED (the waterfall settled on chain; only the x402 beat is unproven). Three prior FAIL runs the same day are kept in `docs/spine-runs/spine-runs.tsv` — a live run found what CI could not. No daily cadence: on-demand, not scheduled. See §0.1.
+- Spine runs: first automated settlement 2026-08-07, verdict UNVERIFIED (waterfall settled on chain; the x402 beat rested at `NOT_BROADCAST` then). The x402 beat has since settled on Arc 2026-08-08, self-facilitated (not through Gateway); the Circle Gateway path is built and has never run. Three prior FAIL runs the same day are kept in `docs/spine-runs/spine-runs.tsv` — a live run found what CI could not. No daily cadence: on-demand, not scheduled. See §0.1.
 - Recording integrity: replay of real runs, live transactions, disclosed caption. Record Thu; edit + deck + README Fri (**Teammate 2 owns final README/deck review**).
 - Submission Sat 8 Aug, evening IST; all links verified incognito. Sun 9 Aug = AoE contingency only, not build time.
 

docs/SPINE-RUNS.md

@@ -10,7 +10,7 @@ that no unit test can close, because the clause names a live run:
 
 | Task | Done when (WORK-SPLIT §2) | Closed by |
 |---|---|---|
-| V1 | "a real four-cent purchase completes on testnet **and the raw request/response pair is committed as a fixture**" | **NOT closed by any beat yet.** Beat 3 proves the x402 handshake, the EIP-3009 signature and the resource delivery are real, and stops at UNVERIFIED because `seller.ts:217` returns `settlement: NOT_BROADCAST`, so nothing reaches Arc and `SETTLED` is unreachable (H3 section 8). Both halves of the clause need the facilitator broadcast plus a funded wallet: see `docs/V3-CIRCLE-SETUP.md`. |
+| V1 | "a real four-cent purchase completes on testnet **and the raw request/response pair is committed as a fixture**" | **Settlement half proven 2026-08-08; the Circle-specific fixture half stays open.** Beat 3 proves the x402 handshake, the EIP-3009 signature and the resource delivery are real. It rested at UNVERIFIED in the 2026-08-07 run because, under the (unconfigured) Gateway facilitator, `seller.ts` returned `settlement: NOT_BROADCAST`. `SETTLED` is **not** unreachable: a real 0.04 USDC x402 payment has since settled on Arc, **self-facilitated** — broadcasting the EIP-3009 authorization directly, no Gateway (tx [`0x0d39b5…dccc`](https://testnet.arcscan.app/tx/0x0d39b5738f7042ae82ae0a17f24474e67c27db0cd837b791c112f8d264b6dccc); `docs/spine-runs/2026-08-08-first-x402-settlement.md`). The open half is the Circle-specific one: the committed fixture (`capture-v1-fixture`, AT-18) requires Circle's endpoints, and the Gateway path is built but has never run against the live service (`docs/V3-CIRCLE-SETUP.md`). |
 | V7 | "a full spine run renders every state transition live" | a human watching during a green run |
 | V9 | "clicking Accept produces the on-chain settlement tx" | beat 6, from JobVault status on chain |
 | V10 | "a live spine run animates correctly with zero manual triggers" | a human watching during a green run |