## EVIDENCE STATE Mode: EVIDENCE. Background: strong TypeScript/backend experience; React hooks are the stated gap. Supplied evidence covers the button component, the checkout hook behavior, and one existing interaction test. I do not have the full files, redirect implementation, error UI, or test framework configuration. ## TICKET CONTRACT **T1 — Pending state** While checkout submission is active, the Pay button must be disabled. **T2 — Pending label** While submission is active, the button must display `Processing…`. **T3 — Failure recovery** If `createCheckoutSession()` fails, the button must become usable again. **Preserve** Successful checkout still redirects through the existing success path. **Non-goals** No checkout redesign, API change, payment retry system, or new state library is requested. ## CONTEXT SLICE **READ — `useCheckout.ts`** Question: where is `isSubmitting` reset on every non-success exit? The supplied description shows `true` before the request and an error assignment in `catch`, but no evidenced reset. **READ / TOUCH — `CheckoutButton.tsx`** Question: does the component already render from `isSubmitting`, or will the ticket require only conditional `disabled` and label behavior? **PROVE — existing checkout interaction test** It already establishes the current click-to-request path and is the best evidenced place to extend behavior checks. **ASK** The exact `useCheckout.ts`, `CheckoutButton.tsx`, and current test body are still needed before an exact patch can be claimed. **AVOID** Payment API/server logic. Nothing supplied indicates the ticket needs to change money movement or checkout-session creation. ## LEARNING BRIDGE ### Gap: React render from state Why now: T1/T2 depend on `isSubmitting` causing a re-render. **15-minute drill** In a tiny component, toggle one boolean state and use it to change both `disabled` and button text. **Proof of readiness** Explain: “state changes cause a render; the button derives its visible and disabled state from that value.” **Stop condition** Do not study reducers, context, or external state libraries for this ticket. ### Gap: async cleanup path Why now: T3 requires pending state to clear after failure. **15-minute drill** Trace a `try/catch/finally` example and list which blocks execute on success, failure, and thrown error. **Proof** Identify the one location that can restore a pending flag regardless of failure path. ## FIRST-PR SAFETY GATE **READY WITH MENTOR GATE** Reason: the requested surface is small and the supplied evidence keeps payment creation itself out of scope. However, the exact hook must be checked before editing because redirect timing may affect whether a `finally` reset is useful or visible on success. Mentor gate: “Does the existing checkout hook intentionally leave `isSubmitting` true until navigation on success?” That answer affects only the reset strategy, not T1/T2. ## FLIGHT PLAN ### READ 1. Full `useCheckout.ts` — confirm every exit path and redirect order. 2. Full `CheckoutButton.tsx` — confirm current prop/render contract. 3. Existing checkout test — copy repository testing conventions. ### TRACE Follow one click: Pay click → hook submission state → `createCheckoutSession()` → success redirect or error path → rendered button state. ### SANDBOX Before editing production code, add or sketch a controlled rejected-promise test and observe whether pending state remains stuck under the current implementation. ### CHANGE Narrow intended surface: - derive button `disabled` and label from the existing `isSubmitting`; - ensure the failure path resets pending state using the repository's existing async pattern; - preserve the success redirect. Do not change the checkout API. ### PROVE Add behavior checks: 1. click Pay with a pending promise → button disabled and text `Processing…`; 2. reject the promise → error path occurs and button returns to enabled Pay state; 3. existing success-call expectation still passes. These are test requirements, not tests I ran. ### PR HANDOFF **Purpose:** expose existing checkout submission state in the Pay button and recover it after request failure. **Reviewer focus:** success redirect ordering and whether pending-state cleanup matches existing hook conventions. **Rollback:** revert the button-state rendering and hook cleanup only; no API/database contract changes are required. ## MENTOR ESCALATION **Question:** Does success intentionally keep `isSubmitting=true` until navigation? **Why it matters:** an unconditional reset may briefly re-enable Pay before redirect if navigation is asynchronous. **Evidence checked:** supplied hook description shows redirect on success and no visible `finally`. **Decision needed:** keep pending true through successful navigation, or reset on every completion. Next artifact with highest information value: the exact checkout hook.