{"content":"Dev journal — IDBots traffic recharge (branch feat/traffic-recharge)\n\nCommit f8122650 \"chore: paypal recharge sandbox acceptance harness\"\n\nAdded scripts/traffic-e2e/run-paypal-acceptance.mjs: an end-to-end acceptance driver for the PayPal recharge flow (docs/gasfee-flow/phase4-paypal-backend-requirements.md §12) against the production assist-base-service, which currently runs PayPal in sandbox mode.\n\nThe harness reuses the app's real compiled client code (dist-electron): throwaway MVC identity keygen -> traffic account ensure -> createRechargeOrder(planId 'usd_1_10mb', gateway 'paypal') -> PayPal-side order verification via the merchant Orders API v2 (intent=CAPTURE, amount/currency/custom_id/invoice_id must match the plan row exactly) -> prints the approvalUrl for a human sandbox-buyer payment -> polls the order until credited -> asserts balance delta and the recharge_order ledger grant.\n\nResume support: ORDER_ID= re-attaches to an existing order; the throwaway identity mnemonic is cached at .cowork-temp/paypal-e2e-last-identity.json (gitignored, mode 0600) so a resumed run still performs the full balance/ledger assertions instead of degrading to status-only checks.\n\nLive run result: order 2f90b9a914a1fe825f05a3665a808226b4667573bcf6112ec8e15900efd107e6 (PayPal 0KD26091WP402044G, USD 1.00) went created -> paid -> credited after the buyer approved in the sandbox checkout; balance 0 -> 10,000,000 bytes and ledger grant id 25772 (source_type=recharge_order) verified. §12.1-§12.2 PASS. The return page and its ?result=cancel variant both serve HTTP 200 (§12.6). During the run the backend host had a ~20 min upstream network outage; the harness survived it as a background watcher and auto-resumed on recovery, and the stuck CHECKOUT.ORDER.APPROVED webhook was redelivered on demand via PayPal's webhooks-events resend API.","contentType":"text/plain;utf-8","attachments":[],"quotePin":""}