Files
python-tdd/src
Disco DeDisco 1c799d35ca
All checks were successful
ci/woodpecker/push/pyswiss Pipeline was successful
ci/woodpecker/push/main Pipeline was successful
room-stage FTs: realign 4 fails to new my-sea NVM + spread-modal + landscape kit-bag UX — TDD
CI #346 test-FTs-room had 4 consistent fails (failed on both the first run
AND the retry, so real, not flakes). All 4 are test-side — the shipped
features are correct; the FTs lagged behind deliberate UX changes + a
race they never needed to depend on.

test_game_my_sea.py
- test_nvm_navigates_back_to_gameboard → renamed test_nvm_navigates_back_to_
  my_sea_hex; asserts /gameboard/my-sea/$ now. NVM on the gatekeeper navigates
  to the table hex, not out to /gameboard/ (changed 5cade51: gatekeeper +
  picker NVM → hex; only landing + sign-gate eject to /gameboard/). Sibling
  test_gear_btn_opens_menu_with_nvm_only still passes (only checks the onclick
  contains /gameboard/).
- test_default_spread_is_situation_action_outcome → add _open_spread_modal(self).
  The spread combobox moved into #id_sea_spread_modal (burger Sea sub-btn
  sprint); .sea-select-current .text returned '' while the modal was hidden.
  Mirrors the already-updated sibling test_picking_spread_swaps_*.

test_trinket_carte_blanche.py (the recurring #344/#345/#346 carte fail)
- Sign-gate Brief: replace the hard wait_for_slow(find .my-sea-sign-gate-brief)
  + NVM-click with dismiss_brief_if_present(). The Brief fires via
  Brief.showBanner on DOM-ready; its appearance is a DOM-ready-vs-note.js-load
  race, so under CI contention it sometimes never lands in-window and ANY hard
  wait throws NoSuchElement. a39053d misdiagnosed this as a timeout (→
  wait_for_slow); it is not. The test never asserts the Brief — it only clears
  it to unblock a later click. dismiss_brief_if_present removes it if present +
  no-ops if absent: robust to the race.
- Kit-bag token select: JS-click the #id_kit_bag_dialog CARTE token. In
  landscape (CI default viewport) the kit-bag dialog is a vertical bar that
  slides in via a max-width transition (burger landscape refactor), so a
  Selenium .click races the animation + can't scroll the token into the
  overflow container ("could not be scrolled into view"). execute_script fires
  the bound handler directly. Applied in both carte tests
  (open_kit_and_select_carte + the in-use attribution flow); token-rails stays
  a normal click (it lives on the gate page, not in the dialog).

Verification: all 4 methods green locally (landscape viewport) —
test_carte_in_use_game_kit_shows_room_attribution 10.8s; the multi-slot carte
+ both my-sea methods 35.5s.

Code architected by Disco DeDisco <discodedisco@outlook.com>
Git commit message Co-Authored-By:
Claude Opus 4.7 <noreply@anthropic.com>
2026-05-27 02:00:35 -04:00
..
feat: shop PaymentIntent flow — shop_buy + shop_confirm + stripe_webhook — Chunk 3 of [[project-wallet-shop-expansion]]. Three-endpoint split per the locked Stripe design: webhook is authoritative for fulfillment (resilient to 3DS, browser closes, network drops); sync /shop/confirm is a best-effort UX speedup (fulfills immediately when Stripe.js confirms client-side, no waiting for webhook delivery); both call Purchase.fulfill() which is idempotent — whichever lands first wins, the other becomes a no-op via the status==SUCCEEDED guard. **POST /dashboard/wallet/shop/buy** (form-encoded shop_item_slug): looks up active ShopItem (404 if missing/inactive); enforces max_owned via is_available_for(user) (409 if cap hit, eg already-owned BAND); requires a saved PaymentMethod (402 otherwise — picks most-recent via order_by('-pk').first() per the open-Q note in the scope doc); creates Stripe PaymentIntent (amount=item.price_cents, currency=usd, customer=user.stripe_customer_id, payment_method=pm.stripe_pm_id, automatic_payment_methods={enabled, allow_redirects=never} for in-window 3DS); creates Purchase w. pi.id; backfills pi.metadata.purchase_id via PaymentIntent.modify so the webhook handler can resolve back to the row; returns {client_secret, purchase_id} JSON for Stripe.js confirmCardPayment. **POST /dashboard/wallet/shop/confirm** (form-encoded purchase_id): retrieves PI from Stripe, if status=='succeeded' calls purchase.fulfill(); returns {status} JSON. 404 if the purchase doesn't belong to request.user. Idempotent — re-firing after fulfill is a safe no-op. **POST /stripe/webhook** (csrf_exempt, mounted at root /stripe/webhook so the URL stays stable across app-routing refactors w. Stripe's dashboard config): verifies signature via stripe.Webhook.construct_event against STRIPE_WEBHOOK_SECRET env var (400 on mismatch — Stripe won't retry on 4xx, only 5xx); on payment_intent.succeeded looks up Purchase by metadata.purchase_id w. fall-back to stripe_payment_intent_id (both unique). Unknown event types are no-op 200 (Stripe sends charge.dispute.created etc. + would retry indefinitely on 5xx). New STRIPE_WEBHOOK_SECRET = os.environ.get(...) setting; user swaps it on staging+prod per the live-mode env-var-only decision. TDD — 17 ITs in test_shop_views.py across 3 classes: ShopBuyViewTest (7 cases — login required, success path creates PI + Purchase w. correct shape, PI.create called w. correct args, unknown slug 404, inactive item 404, max_owned 409, no PM 402); ShopConfirmViewTest (5 cases — login required, succeeded PI triggers fulfill, processing PI leaves PENDING, idempotent on already-SUCCEEDED, other user's purchase 404); StripeWebhookViewTest (5 cases — sig mismatch 400, succeeded event triggers fulfill, unknown event type 2xx no-op, duplicate delivery idempotent, unknown purchase_id 2xx no-op). All Stripe API calls mocked via mock.patch('apps.dashboard.views.stripe'). 1208 IT/UT green
2026-05-22 00:42:09 -04:00