chadtmiller.com/knotless

Switch repository

Loading…

What changes

Three more flows in e2e, as bob. He forks alice's notes from its Fork menu. The fork's page says where it came from, and the fork's record and branches are checked. He merges the pull his fork's queue ejected, with the merge box's "Merge pull". The thread shows the same commit once read anew, with Revert, and the fork's main holds it. He takes a queued pull out of the merge queue and puts it back, each read anew.

Every flow waits for the page to be ready. Each navigation, each reload and each return from the PDS waits for the root's data-ready, as the shots do. A click before the page's script has taken over reaches no handler, and that made the labelling flow fail now and then.

Why

These are the writes from the pages that cost most when they fail silently, after the first pull's: merging, the merge queue, and forking. The labelling flow's failure was the harness's, not the product's: labelItem puts the label in the index before it answers.

How it was checked

just e2e here: 12 of 12 flows, three runs in a row, about 50 s each with seeding.

Shortcomings

Rerunning a check, starting an organization, editing and hiding comments, and the settings pages still have no flow. The merge flow merges on bob's fork, whose main is not protected. A linear, protected main, as alice's is, is not merged from the page here.

🤖 Generated with Claude Code

This adds e2e flows for forking, merging a pull on bob's fork, and leaving and rejoining the merge queue. It also makes every navigation, reload and PDS return wait for html[data-ready]. The wait matches what the shots already do. pull-ejected and pull-queued exist in the world's views (harness/shots/world.mjs). AGENTS.md, docs/development.md, the Justfile and the workflow header are updated to match, as the repo asks of a new writing flow.

I found nothing that must change. The e2e check was still running when I read the checks, so it hasn't confirmed the three new flows on the runner. The other checks that ran passed or were skipped. I'd wait for e2e to go green before merging. If getByText('Forked from') matches more than one element, Playwright's strict mode will fail the fork flow.

Minor: the diff leaves an extra blank line at the end of flows.spec.mjs.

The new commit fixes a race in the merge flow. It now waits for the thread's "Merged as" event and reads the sha there, instead of the merge box's message, which can disappear at once. After that it checks Revert and reads the page anew. That follows from the fix and I found nothing wrong with it. My earlier approval stands, and I have nothing new to ask for.

The e2e and test checks were still running when I read them, so they haven't confirmed the three new flows on the runner. The other checks passed or were skipped. I'd wait for e2e to go green before merging. The PR says 12 of 12 flows passed three times locally. The extra blank line at the end of flows.spec.mjs that I flagged earlier is a nit and not worth blocking on.