--- What it does --- Collectible-card sales run on trust the buyer can't verify: is the card in the envelope the card in the listing — and is it real? Rosette-Sealed Checkout puts a verification seal between the buyer's money and the seller's settlement.
- A seller's agent drafts a listing from a verified card identity (name, set, printed number) read from real store state, and Rosette — a print-forensics verification method — attaches its seal (verdict + receipt) to the listing.
- The buyer checks out with PayPal. The payment is authorized and held, not captured (Orders v2 with intent: AUTHORIZE).
- Before capture, the engine re-checks the fulfilment evidence — the shipped card's scans against the sealed identity — and produces a dry-run preview. A human approves.
- Seal passes → capture, money settles. Seal fails (Likely Counterfeit) or the seal abstains (Inconclusive) → the authorization is voided and the buyer keeps their money. An abstention never captures.
- Every step is written to an append-only receipt chain, and a completed capture can be undone by refund.
Verdicts follow a strict honesty law — Likely Genuine / Likely Counterfeit / Inconclusive, never a certainty claim — and the demo's third listing is a mandatory Inconclusive case (illegible fulfilment scans) that proves the abstention path on camera.
This flow has run live, not just locally: on Nov 10, 2026 all three demo listings were driven end-to-end on PayPal's real sandbox — the Charizard ex (order 3DC72019VN240042T) captured after a Likely Genuine seal (capture 0DT92802L3371522U, COMPLETED), the Pikachu (order 3A1944745V5807419) voided after a Likely Counterfeit seal, the Bulbasaur (order 4UJ88068JA0347306) voided after an Inconclusive seal — with real PayPal ids in the receipt chain throughout.
--- How we built it --- The state machine underneath — read → check → dry-run → approve → apply / log / undo — is the Blast Radius engine, first built for the Vultr: Agent Rush hackathon and reused here behind a published interface contract (docs/ENGINE-CONTRACT.md, vendored in the repo). The agent drafts listings, runs seal checks, and proposes captures or voids; it can never approve its own proposals — approval is a human-only verb, enforced and tested.
The demo core is Python standard library only (~925 lines + tests, no installs for judges to run). A PayPal adapter implements Orders v2 + Payments v2 (create order, authorize, capture, void, refund) with the base URL pinned to the sandbox. A Channel3 integration supplies a live comparable-offers market panel (five comparable offers shown per demo listing) as advisory evidence — never a seal input. Buyer approval happens in PayPal's own sandbox checkout: PayPal reserves that click for the buyer, by design, and this app authorizes the moment PayPal reports the approval. A Kernel cloud-browser persona is the designed automation of that buyer step for the filmed demo — integration scheduled, not yet filmed; the verified live runs were approved by a human buyer in PayPal's checkout.
The test suite (11 tests, all passing) covers the seal verdict table, snapshot-hash stability on reads, happy-path capture + refund undo, the counterfeit void path, Inconclusive-never-captures, agent-cannot-approve, denial-is-terminal, honest state captions, rail honesty (no credentials configured → the stub rail, and it says so), the conforming capture-request shape, and a regression test that feeds the adapter the exact minimal capture body PayPal returned live (see "What we learned" below).
--- What we learned — the capture that "failed" --- The first live capture looked like a failure: the apply step reported an error on the amount field. PayPal had in fact captured the money — our capture request hadn't asked for the full representation, so PayPal answered with a minimal body (id / status / links, no amount), and our receipt code crashed trying to derive the amount from that body. The fix: send a conforming capture body and request the full representation (Prefer: return=representation), and never derive receipt amounts from response bodies — a receipt takes its amount from the approved change itself. A regression test now replays the exact minimal body PayPal returned that day.
All money in this project is PayPal sandbox money — no real funds ever move.
