The screenshot harness has no Stripe subscription, so plan-change states are captured by hand #143

New Issue

2026-09-27T05:33:53Z

cgalo5758 commented

2026-09-27 05:33:53 +00:00

What a contributor runs into

The demo snapshot make screens restores holds no Stripe-backed subscription, so the plan cards only ever show a member on a granted tier. Every state of a paid plan change comes from Stripe's answer to a call and is out of the harness's reach:

the upgrade confirmation, with the amount Stripe previews
an upgrade the card declines (422, reason in the form's slot)
an upgrade awaiting the bank's approval, with the "Approve payment" link
the downgrade confirmation, with the renewal date
a scheduled downgrade on the current card ("moves to … on …", "Keep …")
the cancel confirmation, with and without a default rung to fall back to
a scheduled cancellation on the current card ("ends …", "Keep …")

These exist as hand captures against the Stripe sandbox, at both widths.

Why it costs

Hand captures are not a baseline, as #118 says for interaction states in general. These are worse: reproducing them needs the sandbox, stripe listen, test cards swapped on the subscription, and a 3D Secure challenge completed by keyboard. Nobody will re-shoot them on the next change to the plan cards, and the cards carry the member's money.

Where

test/e2e/screens, and the Stripe stand-in in internal/stripetest, which already answers subscription schedules, pending updates and invoice voids for the package tests.

Done when

The harness can boot the console against a Stripe stand-in seeded per screen (a subscription, a schedule, a declined or approval-needing charge), and the states listed above are named, captured at both widths and diffed like every other state.

## What a contributor runs into The demo snapshot `make screens` restores holds no Stripe-backed subscription, so the plan cards only ever show a member on a granted tier. Every state of a paid plan change comes from Stripe's answer to a call and is out of the harness's reach: - the upgrade confirmation, with the amount Stripe previews - an upgrade the card declines (422, reason in the form's slot) - an upgrade awaiting the bank's approval, with the "Approve payment" link - the downgrade confirmation, with the renewal date - a scheduled downgrade on the current card ("moves to … on …", "Keep …") - the cancel confirmation, with and without a default rung to fall back to - a scheduled cancellation on the current card ("ends …", "Keep …") These exist as hand captures against the Stripe sandbox, at both widths. ## Why it costs Hand captures are not a baseline, as #118 says for interaction states in general. These are worse: reproducing them needs the sandbox, `stripe listen`, test cards swapped on the subscription, and a 3D Secure challenge completed by keyboard. Nobody will re-shoot them on the next change to the plan cards, and the cards carry the member's money. ## Where [`test/e2e/screens`](https://git.coopcloud.tech/wiki-cafe/member-console/src/branch/main/test/e2e/screens), and the Stripe stand-in in [`internal/stripetest`](https://git.coopcloud.tech/wiki-cafe/member-console/src/branch/main/internal/stripetest), which already answers subscription schedules, pending updates and invoice voids for the package tests. ## Done when The harness can boot the console against a Stripe stand-in seeded per screen (a subscription, a schedule, a declined or approval-needing charge), and the states listed above are named, captured at both widths and diffed like every other state.

cgalo5758 added the

kind

debt

area/billing area/testing labels 2026-09-27 05:33:53 +00:00

cgalo5758 commented

2026-09-27 06:20:02 +00:00