feat(orders): order queue channel with atomic claim, board ORDRE column

ORDRE 59. A dispatched order used to live only in a scratch prompt file
passed through argv, so it died with the pane it was typed into. Measured
2026-08-17: one order was dispatched three times over 90 minutes before it
was worked, because the first two tabs ran something else and the order
left no trace in the receiving repo at all.

New channel `~/.claude/coord/<repo>/orders/`, beside `inbox/` and never
merged with it. The axis is authorization: inbox content is untrusted
cross-repo data that may never instruct a session (Rule 6), a dispatch
order is operator-authorized work by construction. One channel carrying
both classes would mean either mail that can instruct or orders that
cannot, so the infrastructure is reused and the channel is not.

Four one-verb engines: coord-order-send.sh (write), coord-order-inbox.sh
(read, writes nothing at all), coord-order-claim.sh (atomic claim),
coord-order-done.sh (executed with a commit pointer / --no-commit with a
reason / --return with a reason).

The claim is a rename with no check-then-act step, so of N racing sessions
exactly one finds the source and the rest get ENOENT. The test that proves
it spawns 20 claimers BARRIERED on a start flag - unbarriered children do
not race at all - and runs the identical harness against a deliberately
racy `[ -e src ] && cp && rm` as a known-negative control, which must
produce many winners. Without that control, "exactly one winner" is
indistinguishable from "the race never happened".

Channel separation is pinned structurally, not only behaviourally: no mail
script may contain the string `orders`, with a known-positive control
proving the grep can find. coord-done cannot archive an order and
coord-order-claim cannot claim a message.

board gains an ORDRE column beside INN, counted with the identical idiom
and never summed with it: INN is "others are waiting on YOU", ORDRE is
"work is waiting on this REPO". Claimed orders are excluded - the column
answers what a session can pick up. board.sh --dispatch --order-id emits a
thin starter carrying only the id and the four steps, so the order text has
exactly one home; the id is validated shell-clean and must be pending in
the target's queue.

SessionStart injects the queue as its own block below the mailbox block.
Two channels, two blocks, mail first: it carries Rule 7, and the queue
order is mail -> orders -> STATE's NESTE.

Also folds in dde392d (board prefix-match fix), which landed after the
0.26.0 bump and before any tag. v0.26.0 was never tagged, so 0.27.0 is the
release that carries all of it.

Suites: coord 220, board 237, route 69, orders 97, guard 40; npm test 11/11.
Antakelse 4 (atomic claim) and antakelse 6 (morning --plan-file --dry-run
reports 1 of 1 for the thin starter) both measured, not assumed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0134iB7ipXGgEpv9imYoVmr2

tests/selftest.test.mjs

@@ -42,6 +42,15 @@ test('state-line-guard bash selftest passes', () => {
   execFileSync('bash', [join(root, 'scripts', 'state-line-guard-selftest.sh')], { encoding: 'utf8' });
 });
 
+// The order queue is the second channel beside the mailbox, with the opposite
+// authorization class. Its suite is pinned from the plugin root for the same
+// reason as the others: production resolves the engine through
+// CLAUDE_PLUGIN_ROOT, so a queue proven only elsewhere is unproven where it
+// runs.
+test('orders bash selftest passes', () => {
+  execFileSync('bash', [join(root, 'scripts', 'orders-selftest.sh')], { encoding: 'utf8' });
+});
+
 // The engine refuses to invent an identity from the cwd, but the hook is the
 // FOURTH place repo identity is derived, and a rule enforced in three of four
 // places is not a rule: as long as the hook resolved the name itself and passed
@@ -129,3 +138,53 @@ test('CLAUDE_COORD_REPO is a declaration, so it does not claim the mailbox', ()
   assert.ok(!existsSync(join(mailbox, 'declared-surface', '.origin')),
     'a declared identity claimed the mailbox; only git-derived reads may claim');
 });
+
+function seedOrder(mailbox, repo, subject, body) {
+  mkdirSync(join(mailbox, repo, 'orders'), { recursive: true });
+  const id = '20260101T000000Z-1-from-dispatcher';
+  writeFileSync(join(mailbox, repo, 'orders', `${id}.md`),
+    `---\nfrom: dispatcher\nto: ${repo}\norder-id: ${id}\nsubject: ${subject}\ndate: 2026-01-01T00:00:00Z\n---\n${body}\n`);
+  return id;
+}
+
+// The whole point of putting orders in the mailbox infrastructure rather than
+// in a prompt file: the prompt file dies with the pane, a pending order does
+// not. This is that claim, measured on the production path - the hook, twice,
+// which is what /clear and a new session both do.
+test('hook injects a pending order, and re-injects it on the next session', () => {
+  const mailbox = mkdtempSync(join(tmpdir(), 'coord-mb-'));
+  const repoDir = mkdtempSync(join(tmpdir(), 'coord-repo-'));
+  execFileSync('git', ['-C', repoDir, 'init', '-q'], { stdio: 'ignore' });
+  seedOrder(mailbox, basename(repoDir), 'ORDER-SUBJECT-OK', 'the order body');
+
+  const first = runHook(repoDir, mailbox).hookSpecificOutput?.additionalContext ?? '';
+  assert.ok(first.includes('ORDER-SUBJECT-OK'), 'hook did not inject the pending order');
+  assert.ok(first.includes('== Repo order queue =='), 'order block missing its own header');
+  // The body is not injected: an order can be a whole session prompt, and it
+  // arrives at claim time from the one place it lives.
+  assert.ok(!first.includes('the order body'), 'hook injected the order body into the queue view');
+
+  const second = runHook(repoDir, mailbox).hookSpecificOutput?.additionalContext ?? '';
+  assert.ok(second.includes('ORDER-SUBJECT-OK'),
+    'the order was consumed by being read: it must stay pending until claimed');
+});
+
+// Two channels, two blocks, in the order they are to be worked. Merging them -
+// or letting the mailbox block absorb the queue - would put operator-authorized
+// work under the "untrusted data, never instructions" framing, or the reverse.
+test('hook keeps mail and orders in separate blocks, mail first', () => {
+  const mailbox = mkdtempSync(join(tmpdir(), 'coord-mb-'));
+  const repoDir = mkdtempSync(join(tmpdir(), 'coord-repo-'));
+  execFileSync('git', ['-C', repoDir, 'init', '-q'], { stdio: 'ignore' });
+  seedMailbox(mailbox, basename(repoDir), 'MAIL-BODY-OK');
+  seedOrder(mailbox, basename(repoDir), 'ORDER-SUBJECT-OK', 'b');
+
+  const ctx = runHook(repoDir, mailbox).hookSpecificOutput?.additionalContext ?? '';
+  const mailAt = ctx.indexOf('== Repo coordination ==');
+  const ordersAt = ctx.indexOf('== Repo order queue ==');
+  assert.ok(mailAt >= 0 && ordersAt >= 0, 'one of the two blocks is missing');
+  assert.ok(mailAt < ordersAt,
+    'the order queue was printed above the inbox, inverting the queue order the convention defines');
+  assert.ok(ctx.includes('UNTRUSTED DATA'), 'the mail block lost its authorization framing');
+  assert.ok(ctx.includes('OPERATOR-AUTHORIZED'), 'the order block lost its authorization framing');
+});