A deck chooses among sibling pulls: one card each, like or dislike recorded in the decision ledger, disliked ones closed with a reason #1727

The core is sound. Identity comes from the session, every write checks canWrite, posts go through readForm(ctx, "rw") (same-origin check and capped body), the group is checked against a regex before it reaches a redirect, the output is escaped through html, and no SQL is built from user text. But it does not meet the bar for done.

Fix first: it is reachable only by typing the URL. The direction says done means reachable on the page, through MCP, in a test and by eye. This pull adds one page and two form posts, and:

• No pull page, studio card or inbox row links to /variants/:group.
• There is no JSON API route and no MCP tool to like or dislike a variant.
• There is no terminal door (src/tui).
• The README does not say a word about the deck.

The pull description admits the missing link. The fix: add a 'Choose among N variants' link wherever variantSiblings is already shown, put like/dislike in the API and MCP (or a variant action in the bulk decide verbs) on top of the same voteVariant, give the terminal the same deck, and add a README paragraph.

Also fix:

1. The dislike is not atomic and does not order its steps safely. The ledger row is written before the close. If setIssueState refuses (a mirrored repo, for example), the ledger says disliked but the pull stays open, and the user can retry because the pull is still open, so each retry writes another dislike row and another 'Closed: …' comment on a pull that never closed. Check that the close can happen first (or close, then comment, then record), and do it in one transaction.
2. A like can be recorded any number of times. Every Like post writes another lean row, so the ledger counts clicks, not decisions. Keep one vote per person per pull (replace the earlier one), and add a test that posts Like twice.
3. The swipe closes a pull on a 90px horizontal move, with no check of the vertical move and no confirmation. A diagonal scroll on a phone can close a sibling. Require the move to be mostly horizontal, or have the swipe only reveal the buttons. No test covers the script.

I could not open the preview or the pictures from my sandbox, so none of this was checked by eye.

The security is sound. Every door (page, JSON API, MCP tool and terminal) goes through voteVariant, which checks canWrite. The form posts use readForm(ctx, "rw"), so the origin and scope are checked. The deck filters by mayView. The group is checked against a regex before it reaches a URL. A refused close leaves no comment and no ledger row.

This cannot land yet, because two of the checklist items fail.

1. Tests (fix this first). The variant MCP tool and the terminal's +/- keys are new behaviour, and nothing tests either. test/mcp.test.ts only adds the tool's name to a list. Add:

- an MCP test: a reader's variant call is refused and writes nothing; a writer's dislike closes the pull, leaves the reason as a comment and writes one lean row; - a terminal test, following the existing pull-screen tests: + on a variant pull writes a like; - (after the confirm below) closes it.

1. The terminal closes a pull on one stray keypress. - closes the pull at once, with no confirm and no reason. The page asks before a swipe dislike, and its form takes a reason. Make - open the same confirm, with a one-line reason prompt, so the terminal does what the page does. Also show the +/- binding only when the pull has a variant group; at the moment it shows on every pull and does nothing on most.

Smaller points:

• src/web/pages/variants.ts has a stale comment above the rewritten one.
• setIssueState returns ok when the pull is already closed (its compare-and-set changes nothing). Two dislikes at the same moment therefore both add a "Closed: …" comment. Check closed.value.state against the pull's state before the vote, or treat that case as not_open.
• change.ts calls variantSiblings twice per render; compute it once.

I couldn't reach the preview from my sandbox, and I couldn't read the screenshots, so this review is based on the code and its tests.

Approved. I read every changed line, and at head f5c81de test/variants-deck.test.ts, test/variants-surfaces.test.ts and test/mcp.test.ts pass (33/33).

Security:

• Every door goes through voteVariant, which needs a signed-in writer and an open pull that belongs to a variant group in that repository.
• The page's form post goes through readForm(ctx, "rw"), so it is same-origin checked and its body is capped by the bytes actually read. The API uses requireScope("rw") and the bounded body(). The MCP tool is writes: true and checks mayView.
• The deck filters each sibling through mayView, so a sealed pull does not leak. group must match ^[A-Za-z0-9_-]{1,64}$ before it reaches a URL. The title goes out through the escaping html template. The swipe script runs under the page nonce.
• No SQL is built from user text and no shell is involved.

Correctness:

• A dislike closes, comments and records in one transaction, and re-reads the pull's state inside it, so a double close writes nothing twice. A test forces the close to fail and checks that nothing is left behind.
• One vote per person per pull is enforced.
• The terminal's +/- goes through the same action, appears only on a pull in a variant group, and - asks for a reason before it closes.
• The README section covers the page, the API, MCP and the terminal.

Not verified: from this sandbox I could not reach the preview host or read the look pictures. This verdict rests on the code and the tests.

One note, not blocking: recordVariantVote deletes every lean row from that person on that pull, including any old studio-ask rows. That is harmless today, but filtering on state.group would keep the ledger's history intact.