On /next the owner moves a row by keyboard: select, up or down, t to top, l to Later #12305

On /next, a focused row now moves by keyboard. Shift+J or Alt+↓ moves it down one place, Shift+K or Alt+↑ moves it up one place, t sends it to the top and l puts it behind the Later gate. bun x tsc --noEmit and bun scripts/design-lint.ts pass. test/next-keys.test.ts and test/next-up.test.ts pass. I did not run bun test on the other test files, only week-doors and next-order-page once, before the fix below. bun scripts/gate.ts printed nothing I could confirm passed, so treat it as unchecked here. I did not take the before/after screenshots at 390 px and 1280 px. The sandbox can only reach the deployed previews, and I did not look at the one for this pull.

• Already there: j/k row selection, t, u/d, the per-row forms, and focus returning to the moved row after the reload were already on /next. I left them as they were.
• One ordering path: each key finds the row's existing data-key form and sends it as the same same-origin POST. The step targets still come from stepTo, and there is no second way to reorder. Without script the per-row buttons still work.
• l replaces n: the "Not now" button's key changes from n to l, as the issue asks. I updated one assertion in test/next-up.test.ts that expected n, because the old key was what that test was checking.
• Key help: the line under the list now names the keys: t top, l Later, u/d one place, Shift+K/J and Alt+↑/↓ as the same moves, and j/k to move between rows.
• New test: test/next-keys.test.ts renders the page and checks the data-key hooks and the help line. It then reads each key's form from the page and POSTs it. It checks the new order after top, down, up and Later.

To try it, open /<owner>/<repo>/next as someone with write access, press j to focus a row, then Shift+J, Alt+↑, t or l.

Left out: no new JavaScript beyond the key mapping, and no change to drag-and-drop.

The pre-push hook refused the first push because no commit said how to try the change, so I added an empty "Try:" commit.

🤖 Generated with Claude Code

I fixed points 1 and 3 and the two line comments on the same branch and pushed. Point 2, the before/after screenshots at 390 and 1280 px, is not done: this sandbox has no browser. The change adds no markup and no styles, only keys and one help line. bun x tsc --noEmit, bun scripts/design-lint.ts, test/next-keys.test.ts and test/tui-next-up.test.ts pass, and test/next-order-page.test.ts passed before a last typing fix. I did not re-run bun scripts/gate.ts: it printed nothing in its last run and I didn't check its exit status.

What changed

• One l key on both doors. The terminal's Not now binding and handler (src/tui/screens/next.ts) are l, and docs/features/next-up.md says l in all three places. test/tui-next-up.test.ts now presses l, which covers the terminal binding.
• Key mapping is a pure function. keyStep(e) in the new src/web/pages/next_keys.ts replaces the nested ternary with a small lookup table. The page ships that same function to the browser through keyStep.toString().
• Tests call the mapping. test/next-keys.test.ts now calls keyStep directly:

- Plain t and l map to themselves. - Shift+J/K and Alt+↓/↑ map to down and up. - Alt+J, Shift+T and Alt+Shift+arrow return nothing. - The shipped script contains the function's source. - The old substring assertions on the key list are gone.

• Shorter help line. It now reads Keys: t top · l Later · Shift+J/K or Alt+↓/↑ down/up · j/k choose a row. The docs state that Alt+Shift combos do nothing, but I did not add that to the page help. I kept the help line to the keys, as you suggested.

Left out

• Screenshots. Someone with a browser needs to attach them, or point me at a way to take them. The preview is at https://lab--12305--forge-trevato-apps.open-platform.sh/<owner>/<repo>/next.

On /next, the owner can now move a row by keyboard: Shift+J and Shift+K, or Alt+↓ and Alt+↑, move the focused row down or up, and l sends it to Later. This push fixes the three gate failures from the last check, and the tests I ran pass locally.

• Line width: I rewrapped the two comments in src/web/pages/next_keys.ts that were over 100 columns.
• Door and pipeline rules: the gate failed because the pull adds next_keys.ts. Both rules are cleared by commit-message lines, No door: and Direction:. The /next terminal screen (src/tui/screens/next.ts) and docs/features/next-up.md already carry the keys.
• Stale test: test/next-up.test.ts still asserted the old help wording "j and k move between rows". The page's help line now says "j/k choose a row", so I updated the test; the test was wrong, not the code.

bun scripts/gate.ts and tsc --noEmit are clean. test/next-keys.test.ts, test/next-up.test.ts and test/tui-next-up.test.ts all pass. I did not run the full suite; the forge's check does that on this push.

To try it, open /<owner>/<repo>/next, focus a row with j, then press Shift+J, Alt+ArrowUp, t or l.

I left Alt+Shift combinations unmapped on purpose; they do nothing.

The gate now passes locally, and I've pushed the fix. The failure was the "before/after looks" rule, which wants a commit line naming the page in app.looks that shows the change.

I added an empty commit with Looks: /preview-admin/sample/next. That page is in forge.json's looks list and is the sample /next page where the new help line shows. The commit changes no code, so I did not re-run the tests or tsc for it.

The forge will take the before/after pictures of that page on the preview.

I found nothing in this pull to fix for either failure, so I pushed an empty commit to re-run the check.

• engine-split ("an engine that stops saying it is alive is ended and started again"): it passes here, 12 of 12 when run on its own. This pull touches none of the engine code. It failed in a run where the slowest shard took 173 s, so I think the timing-based test was starved of CPU. The forge also found it green on main.
• did-you-mean ("the suggestion costs queries on a 404 only"): the forge found this red on main at 5595b9f with the same tests, so it doesn't count against this pull. I didn't change it.

If engine-split fails again on the re-run, it needs a person to look at the test's timing margin, not a change in this pull.