`coord-order-done --return` rewrites the order file's mtime, and both age
surfaces read mtime, so putting an order back reset the very reading that
says how long it has waited. An order returned three times could never look
old - on the one surface that exists precisely so a repo nobody opens still
shows something.
Found by reading the board right after this repo returned an order of its
own, not by looking for it: a file whose name says 2026-09-02 rendered
`ORDRE 1:0d` and `pending, 0d old` minutes later. Verified live after the
fix: the same order now reads 1d.
Two questions, two sources, and only one of them moved. A PENDING order's
age is "how long has this sat with no owner" = now - delivery time, which
only the filename carries and nothing rewrites. A CLAIMED order's age is
"how long has it been in flight", which is the claim's own mtime and was
already right. So oldest_pending_age() sits BESIDE oldest_order_age(), and
pending_age_of() beside age_of() - switching FLY to the filename would
answer the delivery question in the column that asks the flight question.
An unparseable filename yields "?" for the whole reading, never a
fabricated 0, because an unmeasured order could be the oldest one.
TDD, red first: orders-selftest section 11 (110 -> 116) and board-selftest
section 30 (360 -> 368), each asserting its own ground truth before
anything depends on it, with controls that a freshly delivered order still
reads 0d and that FLY did not move. Mutation-verified in both files:
restoring the mtime read turns exactly the defect checks red and leaves
every control green.
Section 28's fixtures were rewritten as part of this rather than
incidentally: they encoded their ages in `touch -t` while their filenames
held fixed 2026-01/2026-08 dates, which a filename-based reading makes both
wrong and time-dependent. They now compute their stems from `date -v` and
the section asserts two ground truths, the filename for ORDRE and the mtime
for FLY.
Order 20260903T185736Z-1290610855 (.claude). Version 0.32.1 across all
seven files; no catalog change in this session.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
board.sh's --dispatch --order-id thin starter told a dispatched session
to run `coord-order-claim <id>` / `coord-order-done <id> ...` literally.
Neither is on PATH, so step one was command-not-found - easy to misread
as "the order does not exist" (Verifiseringsloven ansikt 4).
Measuring the denominator beyond the one line the order named found the
same defect in two more emitters that hand a session its own next-step
text: coord-order-inbox.sh's SessionStart injection (every pending/claimed
order, not only dispatched ones) and coord-order-claim.sh's own WHEN DONE
/ IF YOU CANNOT lines. All three now call the verb via $SELFDIR (derived
from $0's directory, correct at emission time), and board.sh's interpolation
of it is shell-clean-guarded like the other two values sharing its
double-quoted position - reachability proven with a copy of board.sh run
from a space-containing path, not asserted.
board-selftest 239->246, orders-selftest 99->104. CLAUDE.md counts and a
new F-paragraph updated to match.
ORDRE 20260817T213139Z-643032142-from-.claude
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019syEQHvw2jf1dTR4bUPKRG
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
