The screenshot harness cannot reach a page's interaction states #118

New Issue

2026-09-21T07:18:35Z

cgalo5758 commented

2026-09-21 07:18:35 +00:00

What a contributor runs into

The capture harness visits each route and shoots it in generic states: as it arrives, with every disclosure opened, and with an invalid submission. It has no hook to perform a sequence of acts first. So a surface whose interesting states exist only after a click, such as a table row being edited, a staged change awaiting review, a tray holding one change and then several, or the page just after a batch is applied, is captured by hand at both widths into a sheet and reviewed by eye.

Why it costs

Hand captures are not a baseline. Nothing re-shoots them on the next change, so nothing diffs them, and the review depends on someone remembering which states mattered. Every stateful surface pays this again, and the surfaces with the most states are the ones most worth watching.

Where

test/e2e/screens.

Done when

A screen can declare a sequence of acts against the page's declared form, replayed before the capture; the states reached that way are named, captured at both widths and diffed like every other state; and the surfaces currently captured by hand are covered by it.

Migrated from status/issues.md at b7a0e15

## What a contributor runs into The capture harness visits each route and shoots it in generic states: as it arrives, with every disclosure opened, and with an invalid submission. It has no hook to perform a sequence of acts first. So a surface whose interesting states exist only after a click, such as a table row being edited, a staged change awaiting review, a tray holding one change and then several, or the page just after a batch is applied, is captured by hand at both widths into a sheet and reviewed by eye. ## Why it costs Hand captures are not a baseline. Nothing re-shoots them on the next change, so nothing diffs them, and the review depends on someone remembering which states mattered. Every stateful surface pays this again, and the surfaces with the most states are the ones most worth watching. ## Where [`test/e2e/screens`](https://git.coopcloud.tech/wiki-cafe/member-console/src/commit/b7a0e15/test/e2e/screens). ## Done when A screen can declare a sequence of acts against the page's declared form, replayed before the capture; the states reached that way are named, captured at both widths and diffed like every other state; and the surfaces currently captured by hand are covered by it. Migrated from status/issues.md at b7a0e15

cgalo5758 added the

kind

debt

area/testing labels 2026-09-21 07:18:35 +00:00

cgalo5758 referenced this issue

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

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

cgalo5758 referenced this issue

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

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

cgalo5758 referenced this issue from a commit

2026-10-02 00:49:58 +00:00

Charge upgrades now and defer downgrades to renewal

cgalo5758 commented

2026-10-06 08:23:13 +00:00

The FedWiki sites list on the member dashboard adds states of this kind. Each needs an act first or an answer from the wiki farm, so they are captured by hand at both widths, and some were reached only by writing request rows straight into the database:

a notice for a declined create: the farm refused the name, or the site limit or the active-site limit was reached;
a notice for a failed action on an active site;
a create that is still Pending, and a row action that is still Pending;
a request whose workflow never started ("Try again.");
the create form's "This form is out of date. Submit it again." after another tab used the same form;
"A change to this site is already in progress" when a second action is sent while one runs.

The notice states need more than a sequence of acts on the page: the harness would also have to make the farm, or a stand-in for it, answer with a refusal or a failure.

The FedWiki sites list on the member dashboard adds states of this kind. Each needs an act first or an answer from the wiki farm, so they are captured by hand at both widths, and some were reached only by writing request rows straight into the database: - a notice for a declined create: the farm refused the name, or the site limit or the active-site limit was reached; - a notice for a failed action on an active site; - a create that is still Pending, and a row action that is still Pending; - a request whose workflow never started ("Try again."); - the create form's "This form is out of date. Submit it again." after another tab used the same form; - "A change to this site is already in progress" when a second action is sent while one runs. The notice states need more than a sequence of acts on the page: the harness would also have to make the farm, or a stand-in for it, answer with a refusal or a failure.

cgalo5758 commented

2026-10-06 21:26:44 +00:00

The read-only site with Keep active on the member sites list is another state of this kind. Parking needs a force-reduce rule the demo catalog does not carry, so the sites walkthrough (test/e2e/operator-walkthroughs/fedwiki_sites_test.go) parks the site on the farm and then writes the site row and the usage counter straight into the database.

The read-only site with Keep active on the member sites list is another state of this kind. Parking needs a force-reduce rule the demo catalog does not carry, so the sites walkthrough (`test/e2e/operator-walkthroughs/fedwiki_sites_test.go`) parks the site on the farm and then writes the site row and the usage counter straight into the database.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wiki-cafe/member-console#118