テストスイート
0 + 37
pytest110件(サーバ・ルール・ポリシー・fixtureループ)+拡張パネルのPlaywrightブラウザチェック37件 — 提出時点で全Green
Loading...
プロジェクトの背景
役割
設計者・実装者・運用者(単独)
チーム構成
1人(調査・実装・レビューはAIエージェントチーム)
期間
2026年10月2026年10月
0
2日間のスプリント(10-11〜10-12): 事業設計ゲート → ライブサンドボックス実測 → 実装・デモ・Devpost提出
使用ツール
PayPal sandbox (Orders / Shipping Trackers / Disputes APIs)Chrome MV3 side panel + content extractionPlaywright (panel checks + demo recorder)
PayPal AI Hackathon 2026への提出物です(Devpost)。PayPalの`seller_protection`フラグは`ELIGIBLE`を返しますが、これは申告データのスナップショットであり、セラーの行為が米国セラー保護規約を満たすかの判定ではありません。サンドボックスの実測では、配送先住所なし・追跡番号なし・デジタル商品の注文でもフラグは`ELIGIBLE`のまま、一方で、カード支払い(`payment_source`がカード)の別キャプチャは`NOT_ELIGIBLE`を返し、ウォレット経由のキャプチャ群は`ELIGIBLE`でした。PreflightはPayPalのマーチャントコンソール内に常駐するChrome拡張です — 出荷前にキャプチャ/注文IDを貼ると、現行規約(ver. 2026-01-26)の条項名を個別に引用する7チェックで診断します。failには「出荷しない」を含む定められた処方が付き、追跡番号の登録はPayPalのShipping Trackers APIへの実書き込みで閉ループを作ります。デモは実サンドボックスのdispute(紛争)で対応を示します — 紛争後にPayPalが要求した証拠種別が、出荷前にPreflightが指摘したものと一致しました。審査員はfixtureモードで約2分・PayPalアカウント不要で実行可能。2026-10-12に提出済みです。
課題
`ELIGIBLE`の旗を信じたセラーは、無保護のまま出荷します — そして「商品未着」のdispute(紛争)が届いたとき、商品も代金も失います。この旗はPayPalの申告データのスナップショットで、取引が何を申告したかを映すものであって、セラーの行為がセラー保護規約を満たすかの判定ではありません。サンドボックスで実測すると、条件を変えた6つの注文はすべて`ELIGIBLE`を返しました — 配送先住所や追跡番号が無い注文でも。一方、カード支払いの別キャプチャは`NOT_ELIGIBLE`を返し、カード側の決済を受けるセラーは保護の枠外にいることが実測で分かりました。規約そのものは散文で、マーチャントコンソールのどこにも「あなたのこの注文が、いま、どの必須条件を満たしていないか」を出荷の瞬間に教えるものはありません。
解決策
PayPalコンソール内で、送り状を印刷する前に回す診断です。セラーがキャプチャまたは注文IDを貼ると、localhostのバックエンドが取引を7チェックで評価 — 各チェックは現行の米国セラー保護規約(条項照合監査の末にver. 2026-01-26へピン留め)の引用条項名を伴います。結果は正直に pass / fail / not assessable(判定不能)に分離 — Orders APIから見えない条件をfailに見せることはなく、その注文では直せない条件には`unfixable_for_order`フラグを立てて「出荷しない」という処方を返します。直せる欠落は実書き込みのループで閉じます — §05 FIXがShipping Trackers APIで追跡番号を登録し、§06 BEFORE/AFTERが再チェックでfail→passへの反転を表示。disputeが実在する場合は、Disputes APIのレコードがPayPalが実際に要求した証拠スロットに印を付け、出荷前の警告と紛争後の要求の対応が画面上で見えます。
課題と解決策
課題
`ELIGIBLE`の旗を信じたセラーは、無保護のまま出荷します — そして「商品未着」のdispute(紛争)が届いたとき、商品も代金も失います。この旗はPayPalの申告データのスナップショットで、取引が何を申告したかを映すものであって、セラーの行為がセラー保護規約を満たすかの判定ではありません。サンドボックスで実測すると、条件を変えた6つの注文はすべて`ELIGIBLE`を返しました — 配送先住所や追跡番号が無い注文でも。一方、カード支払いの別キャプチャは`NOT_ELIGIBLE`を返し、カード側の決済を受けるセラーは保護の枠外にいることが実測で分かりました。規約そのものは散文で、マーチャントコンソールのどこにも「あなたのこの注文が、いま、どの必須条件を満たしていないか」を出荷の瞬間に教えるものはありません。
解決策
PayPalコンソール内で、送り状を印刷する前に回す診断です。セラーがキャプチャまたは注文IDを貼ると、localhostのバックエンドが取引を7チェックで評価 — 各チェックは現行の米国セラー保護規約(条項照合監査の末にver. 2026-01-26へピン留め)の引用条項名を伴います。結果は正直に pass / fail / not assessable(判定不能)に分離 — Orders APIから見えない条件をfailに見せることはなく、その注文では直せない条件には`unfixable_for_order`フラグを立てて「出荷しない」という処方を返します。直せる欠落は実書き込みのループで閉じます — §05 FIXがShipping Trackers APIで追跡番号を登録し、§06 BEFORE/AFTERが再チェックでfail→passへの反転を表示。disputeが実在する場合は、Disputes APIのレコードがPayPalが実際に要求した証拠スロットに印を付け、出荷前の警告と紛争後の要求の対応が画面上で見えます。
デザインフィロソフィー
申告データは検証済みデータではない — そしてUIはこの2つを決して混ぜません。PayPalの旗は画面に「declared-data snapshot(申告データのスナップショット)」と表示し、私たちの裏付けとしては見せません。チェック層は決定的なテーブル駆動で、すべての判定が実在する条項名を伴います。LLM意味層は存在しますが正直に退化します — 資格情報がなければ`ran=false`を返し、分析を捏造しません。APIから見えない条件はfailではなく「判定不能」、セラーが直せない条件は「修正可能」ではなく「出荷しない」。裁定結果を予測することはなく、法的助言でないことも明記しています。デモも基盤について正直です — fixtureモードはサンドボックスから捕捉したデータと表示し、サンドボックスで自動化できなかった1点(2件目のdispute作成にはbuyer側の資格情報が要る)は、隠さず手動手順として文書化しています。製品が主張することは、審査員がクリックして検証できる形にしてあります。
主要機能
実条項を引用する7チェックを、コンソール内に
各チェックは現行の米国セラー保護規約(ver. 2026-01-26)の実在する条項名に対応 — 条項照合監査で、実在しない節番号が混入していたのを発見し提出前に除去しています。failには定められた処方が付き、`unfixable_for_order`(その注文では直せない)条件には偽の修正ではなく「出荷しない」処方を返します。
旗と条件の乖離は、主張ではなく実測
条件を変えた6注文のバリエーション行列で、`ELIGIBLE`が住所欠落・追跡欠落・デジタル商品のもとで生き残ることを確認。カード支払いの別キャプチャは`NOT_ELIGIBLE`を返し、ウォレット経由は`ELIGIBLE`のままでした。この実測が — 物語ではなく — 製品の存在理由です。
写した絵ではない、実書き込みのループ
§05 FIXはPayPalのShipping Trackers APIを通じて追跡番号を実登録します(fixtureモードではメモリ内で再現)。§06 BEFORE/AFTERは再チェックして`TRACKING_REQUIRED`がfail→passへ反転する様子を表示 — 直せない住所のfailは正直に残ったままです。登録の成功と再チェックの失敗は別々に表示し、1つの緑バナーに合成しません。
実disputeとの証拠対応
デモのキャプチャは後に実サンドボックスのdispute`PP-R-XGB-10190971`(商品未着)になりました。パネルは琥珀色のバナーでその存在を示し、`PROOF_OF_FULFILLMENT`スロットを「requested in dispute(紛争で要求済み)」とマーク — 出荷前にPreflightが指摘した証拠種別と同じものです。紛争後にPayPalが要求する証拠を、Preflightは出荷前に表に出します。
技術スタック
フロントエンド
Chrome Extension MV3 (side panel + 3-stage content extraction)Vanilla JS/CSS panel UI
バックエンド
Python stdlib HTTP server (127.0.0.1-only bind)Token auth on write path (constant-time compare, 1 MB body cap)
データベース
Fixture store (6 orders / 6 captures / 1 dispute captured from live sandbox)In-memory tracker store for the register→re-check loop
ツール
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)
開発プロセス
コードの前に、企画は事業設計の関門を通りました — 前提整理・構造破壊・顧客フォース・Lean Canvas・フェルミ推定・条件付きGo判定。その過程で当初の差別化は一度死に(競合の公開プレイブック)、旗と条件の乖離の露出へとピボットしています。すべての主張はその後ライブなサンドボックスで実測 — Disputes APIのライフサイクル(require-evidence→provide-evidence)を端から端まで駆動し、トラッカー書き込みが実API変更であることを確認、`payment_source`による旗の差を捕捉しました。独立した敵対的レビューを3ラウンド受け — capture IDがorder参照にルーティングされ404になるP1を含む — 全指摘を提出前に修正しています。2分・3幕構成のデモ動画は、ファイルの存在ではなく画面の表示内容をアサートするPlaywrightハーネスで生成。2026-10-12にDevpostへ提出(devpost.com/software/preflight-for-paypal)。公開リポジトリ(MIT)には条項照合監査や動かなかった経路を含む全工程の記録が残っています。
結果とメトリクス
診断カバレッジ
0 checks
すべて米国セラー保護規約ver. 2026-01-26の実条項にピン留め。結果はpass / fail / not assessableに分離
実測プローブ
0 orders + 1 dispute
条件欠落下でも旗が残ることを示したバリエーション行列。実disputeレコードが証拠対応層を駆動
着手→提出
0 days
10-11に事業設計ゲート → 10-12に実装・レビュー・デモ・Devpost提出
ギャラリー
第2幕(証拠スロット) — 各シェイプが1つの証拠カテゴリに対応。PROOF_OF_FULFILLMENTは「dispute PP-R-XGB-10190971で要求済み」とマーク。充足不可能なスロットは可能なふりをせず明示