Test suite
0 + 37
110 pytest cases (server, rules, policy, fixture loop) plus 37 Playwright browser checks on the extension panel — all green at submission
Loading...
Project Context
Role
Sole Designer, Builder & Operator
Team
Solo (AI sub-agents for research, implementation and review)
Duration
Oct 2026Oct 2026
0
2-day sprint, Oct 11–12: business-design gates → live sandbox probes → build, demo and Devpost submission
Tools
PayPal sandbox (Orders / Shipping Trackers / Disputes APIs)Chrome MV3 side panel + content extractionPlaywright (panel checks + demo recorder)
A submission to the PayPal AI Hackathon 2026 (Devpost). PayPal's `seller_protection` flag says `ELIGIBLE` — but that flag is a declared-data snapshot, not a decision on whether the seller's actions satisfy the US Seller Protection terms. In sandbox measurements the flag stayed `ELIGIBLE` on orders missing a shipping address, missing tracking, and carrying digital goods — while a separate card-funded capture returned `NOT_ELIGIBLE` where wallet-funded captures stayed `ELIGIBLE`. Preflight is a Chrome extension that lives inside the PayPal merchant console: before shipping, the seller pastes a capture/order ID and gets 7 checks mapped clause-by-clause to the current terms (ver. 2026-01-26), each carrying the real clause name it derives from. Failures ship fixed prescriptions — including 'do not ship' — and registering tracking writes back through PayPal's own Shipping Trackers API. The demo closes the loop on a real sandbox dispute: the evidence type PayPal demanded after the dispute is the one Preflight flagged before shipment. Judge-runnable in ~2 minutes via fixture mode, no PayPal account needed; submitted 2026-10-12.
Challenge
A seller who trusts the `ELIGIBLE` flag ships unprotected — and when an item-not-received dispute lands, they lose the goods and the payment. The flag is PayPal's declared-data snapshot: it reflects what the transaction declares, not whether the seller's actions satisfy the Seller Protection terms. Measured in sandbox, six varied orders all returned `ELIGIBLE` — including ones missing a shipping address or tracking — while a separate card-funded capture returned `NOT_ELIGIBLE`, meaning card-side sellers sit outside protection entirely. The terms themselves are prose scattered across a legal document; nothing in the merchant console tells a seller, at the moment of shipping, which required condition their specific order fails.
Solution
A preflight check inside the PayPal console, run before the label is printed. The seller pastes a capture or order ID; a localhost backend evaluates the transaction against 7 checks, each citing the clause it derives from in the current US Seller Protection terms (pinned to ver. 2026-01-26 after a clause-by-clause audit). Results split honestly into pass / fail / not assessable — conditions the Orders API cannot see are never dressed up as failures, and conditions that can't be fixed for this order are marked `unfixable_for_order` with a 'do not ship' prescription rather than a false fix. Fixable gaps close a real write loop: §05 FIX registers tracking through PayPal's Shipping Trackers API, and §06 BEFORE/AFTER shows the check flip fail→pass on re-check. When a dispute does exist, the Disputes API record marks the evidence slot PayPal actually requested — making the pre-shipment/post-dispute correspondence visible on screen.
Challenge & Solution
Challenge
A seller who trusts the `ELIGIBLE` flag ships unprotected — and when an item-not-received dispute lands, they lose the goods and the payment. The flag is PayPal's declared-data snapshot: it reflects what the transaction declares, not whether the seller's actions satisfy the Seller Protection terms. Measured in sandbox, six varied orders all returned `ELIGIBLE` — including ones missing a shipping address or tracking — while a separate card-funded capture returned `NOT_ELIGIBLE`, meaning card-side sellers sit outside protection entirely. The terms themselves are prose scattered across a legal document; nothing in the merchant console tells a seller, at the moment of shipping, which required condition their specific order fails.
Solution
A preflight check inside the PayPal console, run before the label is printed. The seller pastes a capture or order ID; a localhost backend evaluates the transaction against 7 checks, each citing the clause it derives from in the current US Seller Protection terms (pinned to ver. 2026-01-26 after a clause-by-clause audit). Results split honestly into pass / fail / not assessable — conditions the Orders API cannot see are never dressed up as failures, and conditions that can't be fixed for this order are marked `unfixable_for_order` with a 'do not ship' prescription rather than a false fix. Fixable gaps close a real write loop: §05 FIX registers tracking through PayPal's Shipping Trackers API, and §06 BEFORE/AFTER shows the check flip fail→pass on re-check. When a dispute does exist, the Disputes API record marks the evidence slot PayPal actually requested — making the pre-shipment/post-dispute correspondence visible on screen.
Design Philosophy
Declared data is not verified data — and the UI must never blur the two. PayPal's flag is labeled on screen as a 'declared-data snapshot,' never as our endorsement. The check layer is deterministic and table-driven, with every verdict carrying its real clause name; an LLM meaning layer exists but degrades honestly — without credentials it reports `ran=false` rather than fabricating analysis. Conditions the API can't see are 'not assessable,' not failed; conditions the seller can't fix are 'do not ship,' not fixable. The product never predicts dispute outcomes and is labeled as not legal advice. Even the demo is honest about its substrate: fixture mode is labeled as captured sandbox data, and the one thing that couldn't be automated in sandbox (creating a second dispute needs buyer-side credentials) is documented as a manual step rather than hidden. What the product claims, a judge can click and verify.
Key Features
7 checks with real clause citations, inside the console
Each check maps to the current US Seller Protection terms by real section name (ver. 2026-01-26) — the clause audit found and removed invented section numbers before submission. Fail states carry fixed prescriptions; `unfixable_for_order` conditions prescribe not shipping instead of a fake fix.
The flag-vs-conditions gap is measured, not asserted
A six-order variation matrix showed `ELIGIBLE` surviving missing addresses, missing tracking, and digital goods; a separate card-funded capture returned `NOT_ELIGIBLE` live in sandbox where wallet-funded ones stayed `ELIGIBLE`. That measurement — not a narrative — is the product's reason to exist.
A real write loop, not a screenshot of one
§05 FIX registers tracking through PayPal's Shipping Trackers API (fixture mode simulates it in memory); §06 BEFORE/AFTER re-checks and shows `TRACKING_REQUIRED` flip fail→pass — while the missing-address fail honestly remains. Registration success and re-check failure are displayed separately, never merged into one green banner.
Evidence correspondence with a real dispute
The demo's capture later became real sandbox dispute `PP-R-XGB-10190971` (item not received). The panel names it in an amber banner and marks `PROOF_OF_FULFILLMENT` as 'requested in dispute' — the same evidence type Preflight flagged before shipment. What PayPal demands after a dispute is what Preflight surfaces before it.
Technology Stack
Frontend
Chrome Extension MV3 (side panel + 3-stage content extraction)Vanilla JS/CSS panel UI
Backend
Python stdlib HTTP server (127.0.0.1-only bind)Token auth on write path (constant-time compare, 1 MB body cap)
Database
Fixture store (6 orders / 6 captures / 1 dispute captured from live sandbox)In-memory tracker store for the register→re-check loop
Tools
PayPal Orders API / Payments capturePayPal Shipping Trackers APIPayPal Disputes APIHonest-degrading LLM meaning layer (`ran=false` without credentials)Playwright (37 panel checks + demo recorder that asserts on-screen content)
Development Process
The idea survived a business-design gauntlet before code: premise analysis, structural break, customer forces, Lean Canvas, Fermi estimate, and a conditional-Go decision — during which the original differentiator died (a competitor's published playbooks) and the product pivoted to the flag-vs-conditions gap. Every claim was then measured against the live sandbox: the Disputes API lifecycle was driven end-to-end (require-evidence → provide-evidence), tracker writes were confirmed as real API mutations, and the `payment_source`-dependent flag difference was measured across captures. Three rounds of independent adversarial review attacked the build — including a P1 where capture IDs routed to the order lookup and 404'd — and all findings were fixed before submission. The 2-minute, 3-act demo video is produced by a Playwright harness that asserts on-screen content rather than file existence. Submitted to Devpost 2026-10-12 (devpost.com/software/preflight-for-paypal); the public repo (MIT) keeps the full trail, including the clause audit and the things that didn't work.
Results & Metrics
Diagnostic coverage
0 checks
Each pinned to a real clause of the US Seller Protection terms ver. 2026-01-26; results split pass / fail / not assessable
Measured probes
0 orders + 1 dispute
Variation matrix proving the flag survives missing conditions; real dispute record driving the evidence-correspondence layer
Build → submit
0 days
Business-design gates Oct 11 → implementation, reviews, demo and Devpost submission Oct 12
Gallery
Act 2 (Evidence slots) — each shape maps to one dispute evidence category; PROOF_OF_FULFILLMENT is marked 'requested in dispute PP-R-XGB-10190971', unfillable slots say so instead of pretending