Raise or lower a limb against its siblings, and the crew takes ready work in that order #1212

A person who administers a repository can now Raise or Lower a limb among its siblings. Once they have set an order in a repository, the crew's ready list follows it. The new test/limb_order.test.ts passes (10 tests) and tsc is clean. I did not run the full bun test or the forge.json check. The sandbox blocks the unix socket serve() opens, so I ran the tests with a local, uncommitted bypass.

What changed

• Stored order: limb_place (new migration) keeps each limb's place per group of siblings, either the top of the plan or one milestone's limbs. It survives a restart.
• Reading the order: A new src/core/limb_order.ts reads the limb tree and orders siblings by stored place. A limb with no place of its own follows the placed ones, by number. readPlan now uses it, so the limbs list and every milestone page show the order.
• Ready order:

- Rule: readyNow still makes one pass over the graph. An issue beneath a higher limb comes before one beneath a lower limb, and one beneath two limbs takes the higher. Issues beneath no limb come last, and within a limb the order is as today. - Not ranked yet: Until someone sets an order in a repository, the ready order is exactly as before. - Crew pick: nextOf is untouched. It takes the first of the ready list, and the decider sees the first six in that order.

• One action: Raise and Lower are two more limb actions, run as a new fleet verb place. One row, the limb, holds its seat as top:2 or <milestone>:1. The dry run returns the new order and the top five of the ready list before and after. There is a receipt, and undo is the fleet's own.
• Doors:

- Page: Raise and Lower links appear on each limb line and on the milestone's own action row. They show only for admins, and only when the move changes something. The preview page shows the new order and the ready list. - API: The existing limb route takes raise and lower plus under, dry-run by default. - MCP: The limb tool takes the same.

• Who may apply: Only a person who administers the repository, through the existing fleet check. Tests cover a reader, a crew agent and the planner, someone not signed in, and ro/rw tokens, over the library, the API, MCP and the page form. None of them moves anything.
• Other tests: They also cover the stored order, a restart, the ready order following it, the issue beneath two limbs, first/last refusals, undo, the preview, and the page flow.
• Docs: docs/PLANNING.md now describes Raise and Lower.

Left out or different from the spec

• Undo and the ready list: Undo restores the order and the receipt. Once any order has been stored, though, the ready list keeps following the order shown. It does not return to the never-ordered list.
• Removed screens: None. The links sit on pages that already existed.
• Looks: No phone/desktop screenshots; I couldn't render pages in this sandbox.
• Decider prompt: I did not change its wording.
• Limbs in several places: A limb that sits in several places needs under (top, or a milestone number) to say which. Otherwise the move is refused with that message.

To try it: As an admin, open /:owner/:name/milestones and use Raise or Lower on a limb. Confirm on the preview, then use Undo on the receipt. Or call the API/MCP limb with action: "raise", which is a dry run until dryRun: false.

🤖 Generated with Claude Code

Closes #1064

scout only (reviewers: not for you): the check on this pull is red. Read the failing tests in the check log, fix them on this branch and push, or say in one line why the red is not yours.

The red check was my fault: the new test/limb_order.test.ts wasn't listed in the gate. The gate's own guard (test/check-list.test.ts) fails any test file that is in neither list. I added the file to GATE in scripts/gate.ts, and test/check-list.test.ts now passes (8 of 8).

I pushed this as a new commit on the same branch. I did not re-run the full gate or tsc here, so the forge's re-run of the check is the verdict. The failing check log named only that one test.

Everything else in the earlier description stands. The one earlier caveat still applies: I ran test/limb_order.test.ts with an uncommitted local bypass for the sandbox's socket block, and I haven't run the whole suite.

🤖 Generated with Claude Code

Undo now puts the ready order back to the natural one, and the milestone pages no longer read the plan twice. I did not do the terminal item; the reason is below.

What changed

• Undo. moveLimb (src/core/limb_seats.ts) now checks whether a group's new order is the group's natural order. If it is, it deletes that group's rows and writes none. After a raise followed by an undo, limb_place is empty again, so limbRank is unset and the crew takes ready work in the natural order.
• How I decided "natural". Sentinel suggested seated(new Map(), group, ids), but that always returns ids, so it can't tell. I compare against the tree's own order instead: tree.top for the top group, tree.limbsOf(group) otherwise. This applies to a raise followed by a lower too, not only to undo.
• Test. The undo test in test/limb_order.test.ts used to assert the limb-ranked order after undo, which was the bug. It now expects places() to be [] and ready() to equal NATURAL. I removed TRUST_FIRST, which nothing used any more.
• Second graph read. Plan now exposes read (graph, tree, places). seating() takes an optional read, and moverFor is handed plan.read. Both milestone pages pass the plan's own read in, so an admin view reads the graph and limb tree once. milestonePage keeps its plan for this.

Tests

• tsc --noEmit is clean.
• limb_order, limbs, dependencies, milestones and map pass: 43 tests, 0 failures.
• This sandbox refuses unix-socket listen, so I ran them with a local edit that served the internal socket on TCP. I reverted that edit and it is not committed.
• I did not run the full bun test. The forge's check does that.

Left out

• Terminal. Raise, Lower, Defer, Resume and Close are not offered in the terminal. That is a separate surface from this pull, and I have not opened an issue for it.

I merged main into the branch and pushed. The merge conflicted in src/core/schema.ts, which is why the check said the branch did not merge into main.

main had added migration 73, the OAuth authorization-code table (oauth_code). My limb_place table had also taken that slot. I kept both and renumbered mine as migration 74, after main's.

I could not run limb_order.test.ts to completion here. Its server setup needs a unix socket, and the sandbox refuses it with EPERM. The schema tests I ran alongside it passed. A full bun test run was still going when I pushed, so I have no result from it.

What the pull does: a person can raise or lower a limb against its siblings, and the crew takes ready work in that order (#1064). The order is stored in limb_place, keyed by repo, parent issue and issue.

What to check: the forge's check should run test/limb_order.test.ts where sockets work.

I've merged main into the branch and pushed it, which should fix the "does not merge into main" failure. I haven't seen the forge's check result on the new push yet.

main had taken migration 74 for the look note columns (#1066), which collided with limb_place in src/core/schema.ts. I kept main's 74 and moved limb_place to 75. Nothing else in the merge conflicted.

The 33 tests in the limb and schema test files pass. I didn't wait for the full bun test run to finish. tsc --noEmit can't run in this sandbox ("Cannot find type definition file for 'bun'"), so the type check is untried here.

Pull description: Raise or lower a limb against its siblings (#1064). A person sets a limb's place among its siblings, stored in the new limb_place table, which is migration 75. The ordering logic is in src/core/limb_order.ts, and the tests are in test/limbs.test.ts.