# repo-mailbox

Renamed from `coord` in v0.3.0. The plugin/repo is `repo-mailbox`; the CLI
(`coord-send.sh`, `coord-inbox.sh`, `coord-done.sh`), the mailbox root
(`~/.claude/coord/`) and `CLAUDE_COORD_DIR` deliberately kept their names —
they are the transport protocol, not the product.

## Context

Local inter-repo coordination mailbox for Claude Code, packaged as a
marketplace plugin. Three components, one boundary:

- **Engine (`scripts/*.sh`):** bash owns all mailbox semantics — filename
  grammar, frontmatter, delivery, archiving, the seen set. `coord-send.sh`
  writes, `coord-inbox.sh` reads (formatted for context injection),
  `coord-done.sh` archives, `coord-count.sh` counts without delivering,
  `coord-sweep.sh` closes the aged FYI backlog machine-wide.
  Everything is pinned by `coord-selftest.sh`
  (257 checks, throwaway mailbox via `CLAUDE_COORD_DIR`).

  **`ktg-plugin-marketplace` is a RETIRED `--to` address (operator decision
  2026-08-15), rejected rather than redirected.** It is a polyrepo directory,
  not a git repo, so `basename(git toplevel)` can never resolve to it and no
  session was ever able to hold that identity naturally - mail for it belongs
  to `catalog` instead. A silent redirect was considered and declined: it
  delivers mail somewhere the sender does not believe it landed, which is the
  same misdelivery defect this closes a second time (2 messages sat
  undelivered 2 days on this exact misaddressing before `catalog`'s H4 count
  caught 6 more). Rejection fails loud at the sender, at the moment the
  mistake is made. Only `--to` is retired, not `--from` - the defect was mail
  *arriving* there, never mail claiming to *originate* there.

  **`coord-send --reply-to` asserts "marked handled" against GROUND TRUTH, and
  the exit code alone is NOT that ground truth.** The line used to print
  unconditionally with `coord-done`'s output discarded (`>/dev/null 2>&1`),
  so the one line a session relies on to close a reply debt was false at the
  moment it was printed — measured with a stub `coord-done` exiting 1: original
  still in the inbox, no `archive/`, exit 0, "marked handled". Every reply this
  repo sent had to be verified by hand afterwards, which is what a false
  success in the TRANSPORT costs. The check is `exit 0` **and** the original no
  longer being at `$COORD/$FROM/inbox/$REPLYTO`, because `coord-done` exits 0
  when it archives nothing (an unknown name is idempotently fine by its own
  contract), so a nonzero-exit test still certifies a message that never moved.
  The path is recomputed rather than reusing `$REPLY_ORIG`, which resolves to
  the inbox OR the archive — replying to an already-archived original moves
  nothing and must not warn. Failure is exit **1**, a new status: the reply WAS
  delivered and re-sending would duplicate it, so 2 stays the
  nothing-was-written status it has always been. Selftest section 34 pins all
  four cases (fails outright / exits 0 without moving / real happy path /
  archive-path reply).

  **`--to` is the one line-oriented field that is REFUSED rather than
  sanitized, and the asymmetry with `--from`/`--subject` is the whole point.**
  A target name is also the destination DIRECTORY name (`$COORD/$TO/inbox`,
  and `$COORD/$TO/orders` in `coord-order-send.sh`), so collapsing a control
  character to a space the way `sanitize_field` does everywhere else would
  deliver the message to a mailbox the sender never named - the same
  misdelivery the retired `ktg-plugin-marketplace` address is rejected rather
  than redirected to avoid. Both corruptions were measured on the live engine
  before the guard existed, each with exit 0 and a "delivered" line: a newline
  lands its payload INSIDE the frontmatter block, above the `reply-expected:
  yes` the engine itself wrote, so `coord-count` reads `owed=0` and the debt
  the engine declared is silenced (defeating its own rule that only the
  frontmatter block may speak - the injected line IS in the block); a tab makes
  `coord-count` print FIVE tab-separated fields where its contract is four, so
  a consumer reads the mailbox name as the part before the tab and its pending
  count as the part after. `board.sh` consumes that TSV. The guard sits AFTER
  reply-mode resolution because `--reply-to` takes the target from the
  original's `from:` line - untrusted cross-repo input this repo did not write,
  and the one target name nobody typed. The denominator was measured rather
  than assumed: two scripts build a directory from a caller-supplied name, and
  `coord-order-send.sh` had the identical defect, where it costs more - an
  order filed under a name no session can hold is exactly the silent
  evaporation the ownership chain exists to prevent, while `board.sh`'s ORDRE
  column counts the INTENDED repo's queue and stays 0 with nothing reporting a
  failure. The read-side `--repo` arguments were checked and left alone: they
  resolve an EXISTING directory, so a control character there finds nothing and
  writes nothing. Both selftests carry the mandatory known-positive controls -
  an ordinary name still delivers, and so does a dot-prefixed one, since
  `coord-send.sh`'s own guard comment protects dot names as real repos
  (`basename` of a git toplevel under a hidden directory).

  **`coord-sweep.sh` is the only path that closes a message with no human in
  the loop, and every constraint on it follows from that.** It may close exactly
  one mechanically decidable class - `reply-expected: no`, older than the grace
  window - because a message that owes a reply can only be answered by a session
  in the repo that owes it. Dry-run is the default, inverted from the rest of the
  engine, since this is the one script that destroys pending state. It closes
  through `coord-done.sh --repo` rather than moving files, so the archive layout
  and the `_broadcast` refusal stay in one place. And it logs every closure with
  sender and subject, because directed messages have no seen-tracking: the sweep
  genuinely cannot tell "seen and ignored" from "never delivered", so a notice
  can be closed unread and the log is the only record that it existed. Widening
  the class, defaulting to `--write`, or dropping the log each independently
  turn this from a bounded cleanup into silent data loss.

  **Order 20260902T113745Z-1254925290 (WP5, 2026-09-02, amended by the operator
  2026-09-03): the sweep was CORRECT AND UNREACHABLE, and the fix is a schedule,
  not a mechanism.** It shipped in 0.10.0 and had never run once against the
  real mailbox. Measured 2026-09-03 with a denominator
  (`docs/2026-09-03-coordination-debt-measurement.md`): 55 mailbox directories,
  52 with an `inbox/`, 27 pending directed messages, of which **23 were pure
  notices** being re-injected at every session start in repos nobody had opened.
  The order asked for a mechanism and named two candidates; the measurement
  chose neither, and the session returned it saying so. Bulk-ack for pure
  notices *was already built* - this script - so building the order's candidate
  B would have been two copies of one policy; and the broadcast class converges
  on its own (reading sets `seen`), with 34 of 263 unread pairs belonging to two
  mailboxes no session can hold, so a TTL would have **closed** those, not
  reduced them. `launchd/com.ktg.repo-mailbox-sweep.plist` is the entire
  0.33.0 change. **Invocation was the gap.**

  **The 14-day window is written OUT in the plist, never left to the script's
  default.** It is a policy constant the operator chose on a measured
  distribution (30d -> 0 messages, 14d -> 7, 7d -> 13), of the same class as the
  STATE.md line limit - so a later change to `DAYS=14` in the script must not
  silently change what an unattended nightly job closes across every other
  mailbox on this machine. (A hard count belongs in the dated measurement doc,
  not here: it was 52 with an `inbox/` on 2026-09-03 and 53 a day later.)
  The agent runs at **05:30**, clear of the 06:00 briefing agent, because the
  briefing scans the same mailbox this mutates; selftest section 38 asserts the
  two hours differ. It does **not** change the briefing's DEBT figure - since
  0.22.0 that is read from `coord-count.sh`'s `owed` column, and this sweep
  closes only messages that owe nothing, so the debt listing is byte-identical
  before and after. What moves is the raw pending count (the table's `INN`
  column, `--brief`'s FYI-only naming, and the volume injected at every session
  start). The first cut of this paragraph claimed the sweep made the briefing
  report "the debt that remains" - an overclaim, caught in review, and recorded
  here because it is the kind of plausible sentence that survives a reread.

  **`launchctl list` proves an agent is LOADED, never that it is RIGHT, and a
  wrong program path is the one defect in this repo that nothing catches at
  runtime** - the agent simply never runs, in silence, with no output to be
  wrong and no exit status to read. Two separate things close it, and neither
  substitutes for the other: `launchctl start <label>` plus a line appearing in
  the launchd log is the only *runtime* proof the path resolves, and selftest
  **section 38** asserts *statically*, for every plist in `launchd/`, that the
  path names a file that exists here, that `Label` matches the filename, that
  the `__CHECKOUT__`/`__HOME__` placeholders survive (the repo is mirrored
  publicly), and that no agent points into the version-pinned plugin cache.
  Section 38 covers **every** plist rather than only the new one, deliberately:
  the plist grammar gets one reader here instead of one per agent, and
  `board-selftest.sh` section 9 keeps owning `brief-nightly.sh`'s *behaviour*.
  The cache assertion runs on the **extracted path, never the whole file** - the
  brief plist's header explains in prose why it does not point at the cache, and
  a file-wide grep read that explanation as the defect it warns about, exactly
  as prose saying `status=done` must never trigger the board's done-guard.
  XML well-formedness is deliberately NOT checked: `plutil` is not coreutils,
  and malformed XML already fails loudly at `launchctl load`, which is the
  opposite of the failure this section exists for. Mutation-verified: a
  one-letter typo (`coord-sweeep.sh`) turns exactly that check red.

  **`coord-count.sh` prints TWO integers per mailbox** (`<name>\t<pending>\t<debt>`),
  and the first must stay pending: `board.sh` counts the same inbox files
  itself, so a debt-only count would put two different numbers under one name.
  Debt is read from `reply-expected` in the FRONTMATTER BLOCK ONLY - a body line
  is untrusted input and must not be able to silence a debt - and an absent
  field means a reply IS owed, because every message written before 0.11.0
  lacks it.

  **F5+F14 (2026-08-26): the header promised exit 0 unconditionally, and both
  halves of that were false - one of them silently.** `--exclude` with no value
  already exited 2 (F14), so the documented contract contradicted the code a
  reader could run. Worse, `[ -d "$COORD" ] || exit 0` (F5) made a mailbox root
  that DOES NOT EXIST byte-identical to one where nobody has pending mail: zero
  lines on stdout, exit 0, nothing on stderr. `board.sh` consumes this TSV.
  That is Verifiseringsloven ansikt 4 in the transport itself - a broken query
  returning a positive-looking null, read as a fact about the world. The
  contract is now three statuses: 0 = counted, 2 = usage error, 3 = mailbox root
  absent. **3 rather than 2 on purpose:** 2 already means "you called me wrong"
  and this means "the world you named is not there" - two different repairs,
  and a consumer that only ever sees one integer cannot tell them apart. Both
  nonzero paths print NOTHING on stdout, so neither can be mistaken for a count
  of zero. What the old "always 0" claim was protecting is kept and made
  precise: no state OF THE MAILBOX can produce a nonzero exit - not an empty
  root, not a malformed message, not an unreadable date - so a SessionStart
  still cannot be failed by mail. An EXISTING but empty root stays a silent,
  clean 0, and selftest section 36 pins that silence as hard as it pins the
  failure: a warning on the ordinary path would train every reader to ignore
  the channel the defect case needs. Section 37 pins the header TEXT itself
  (the same technique board-selftest uses on the FLY legend) - a doc line
  nothing tests is a doc line that drifts, which is how this one drifted.

  **Bounded gap, stated rather than closed:** `coord-inbox.sh:57` and
  `coord-order-inbox.sh:60/64` carry the identical `[ -d "$COORD" ] || exit 0`
  shape. The denominator was measured, not estimated (`grep -n '|| exit 0'
  scripts/*.sh`), and they were deliberately left alone: they are the
  INJECTION path, their output is prose a session reads rather than a TSV a
  program parses, and their contract really is "never fail a SessionStart".
  Changing them would change what every session sees, in every repo, and that
  was not ordered. Naming them here is the point - the next session that greps
  for this shape finds a decision, not an oversight.

  **Reading is delivering — counting is not.** `coord-inbox.sh` records a
  broadcast as seen once it has printed it, so it can never be used to survey
  other repos: doing so would consume each one's backlog silently, and the seen
  set is delivery history that retraction deliberately leaves alone.
  `coord-count.sh` exists for every "what is pending" question and writes
  nothing at all. Any future read-shaped feature belongs there, not in the
  read path.
- **Order queue (`scripts/coord-order-*.sh`):** a SECOND channel beside the
  mailbox, `~/.claude/coord/<repo>/orders/`, with four one-verb scripts —
  `coord-order-send.sh` (write), `coord-order-inbox.sh` (read for injection),
  `coord-order-claim.sh` (claim), `coord-order-done.sh` (terminal state).
  Pinned by `orders-selftest.sh` (116 checks).

  **It is a separate CHANNEL, not more mail, and 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 —
  dispatch IS the operator's authorization. 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. The separation is pinned
  STRUCTURALLY, not only behaviourally: no mail script may contain the string
  `orders` at all (with a known-positive control proving the grep can find),
  `coord-done` cannot archive an order, `coord-order-claim` cannot claim a
  message. A behavioural test alone samples one case; the claim is that no
  write path exists.

  **What the queue does NOT claim is that dispatch is its only writer.**
  `--from` redefines identity here exactly as it does in `coord-send.sh`, so
  any session can write an order into any repo's queue. The authority rests on
  a CONVENTION about who writes, not on enforcement, and the injected text says
  so in those words. Asserting the guarantee instead would be this repo's
  oldest defect class (`--reply-to` claiming "marked handled" against the call
  rather than the world).

  **The claim is a `mv` with NO check-then-act step, and the test that proves
  it is built to be able to fail.** `rename(2)` is atomic, so of N racing
  processes exactly one finds the source and the rest get ENOENT — the source
  is the contended resource, not any lock. The selftest spawns 20 claimers
  BARRIERED on a start flag, because unbarriered children do not race at all
  (the first finishes before the second starts) and the test would go green
  having proven nothing. It then runs the identical harness against a
  deliberately racy `[ -e src ] && cp && rm`, which must produce MANY winners.
  Deleting that known-negative control turns the whole section back into an
  unmeasured assumption wearing a passing test — this is the assumption the
  design document marked RISIKO, and the control is what closes it.

  **Claimed orders stay visible in the read path.** A session that claims an
  order and dies is the only remaining way an order can evaporate, so the
  injection keeps showing claimed orders with their in-flight age and the
  command that returns them. Visible-again, NOT a lease timer: nothing here
  expires anything, and building expiry would make the engine decide that a
  session is dead, which it cannot know.

  **`--return` costs a stated reason, and so does `--no-commit`.** A return
  with no reason is a silent drop with extra steps; a `--no-commit` with no
  reason is "trust me" and would quietly become the cheapest way to close any
  order. The reason is written INTO the order, so the next session that picks
  it up sees why the last one put it down.

  **ORDRE 65 (.claude, 2026-08-17): the verbs told a session to run themselves
  by a BARE name, and neither is on PATH.** `board.sh`'s dispatch starter
  (`--dispatch --order-id`) told a dispatched session to run `coord-order-claim
  <id>` and `coord-order-done <id> ...` literally — command-not-found on step
  one, misreadable as "the order does not exist" (Verifiseringsloven ansikt 4).
  Measuring the denominator (the order asked only about `board.sh`, but the
  defect is a class, not one line) found the SAME bare name in two more places
  that print text a session is meant to execute next: `coord-order-inbox.sh`'s
  SessionStart injection (the `-> claim:` / `-> in flight` hints shown for
  EVERY pending/claimed order, not only a dispatched one) and
  `coord-order-claim.sh`'s own `WHEN DONE` / `IF YOU CANNOT` lines, printed
  directly to the session that just claimed. All three now call the verb by
  the absolute path SIBLING TO THE PRINTING SCRIPT ITSELF (`$SELFDIR`, derived
  from `$0`'s directory — the same technique `route.sh`'s own path already
  uses in `board.sh`), not a literal version string: correct at the moment the
  text is generated, for whichever install location is live then. It does not
  survive a version bump landing between generation and paste — a plan-file
  form held across a release can still go stale, the same way any other path
  baked into a plan file would. `board.sh`'s `$SELFDIR` interpolation sits in
  the exact double-quoted position `--prompt-file`/`--order-id` are already
  shell-clean-checked in, so it got the identical guard — proven reachable
  (not speculative) by invoking a COPY of `board.sh` from a directory whose
  path contains a space, mirroring the fixture the `--prompt-file` tests
  already use for the same reason. `coord-inbox.sh`/`coord-send.sh`/
  `coord-done.sh` remain undisturbed: they have only ever been documented as
  bare names in prose a human reads, never in text a session is handed to run.
- **Hook (`hooks/scripts/session-start.mjs`):** thin zero-dependency Node
  wrapper (marketplace convention: hooks are `.mjs`) that calls
  `coord-inbox.sh` AND `coord-order-inbox.sh` and emits the
  `hookSpecificOutput.additionalContext` envelope. No mailbox logic lives here.
  Always exits 0.

  **Two channels, two blocks, never merged, mail first.** Each engine owns the
  words its own block is read under; concatenating them, or letting the wrapper
  write a shared header, would put both authorization classes under one framing
  — the exact thing the channel split exists to prevent. Mail goes above the
  queue because the mail block carries Rule 7 and because the convention's
  queue order is mail -> orders -> STATE's NESTE, so printing the queue first
  would invert on the page the order the two are to be worked in. Each engine
  is run in its own try: an order queue that stayed invisible because the
  mailbox threw would be precisely the silent evaporation the queue exists to
  stop.
- **Hook (`hooks/scripts/pre-state-line-guard.mjs`):** a `PreToolUse` hook on
  `Write|Edit` that enforces the STATE.md convention's `maks ~120 linjer`
  (global CLAUDE.md; raised from `~60` by operator decision 2026-08-14 —
  see the dated paragraph below) mechanically. It exists because the prose limit alone
  failed: a real STATE.md drifted to 155-156 lines before an /insights sweep
  of 160 sessions noticed, and one trim pass on it *increased* the line count
  instead of shrinking it. org-ops dispatched the work order
  (20260814T144553Z) asking for a `PostToolUse` hook — that was the wrong
  event, and the fix is not cosmetic: `PostToolUse` fires only after the tool
  has already written the file (confirmed against the official hooks docs,
  2026-08-14 — "Can block? No", stderr is shown to the model but the write
  already landed), so it cannot stop an oversized STATE.md from landing, only
  nag about it afterward. `PreToolUse` is the only event that can deny the
  call before the file is touched, which is what "enforces" has to mean here.
  Denial is stderr + `exit 2`, matching `llm-security`'s
  `pre-write-pathguard.mjs` — the only other `PreToolUse` `Write|Edit` guard
  in this marketplace — rather than the `hookSpecificOutput.permissionDecision`
  JSON form; both block, and matching the sibling convention keeps one idiom
  for "block a write" instead of two. For `Write` the projected content is the
  call's own `content`; for `Edit` it is the CURRENT on-disk file (read fresh,
  since `PreToolUse` fires before the edit is applied) with `old_string`
  replaced by `new_string` — every occurrence when `replace_all` is set,
  otherwise only the first, mirroring what the real Edit tool does. Getting
  `replace_all` wrong in either direction is not a hypothetical: a hook that
  only ever replaced the first occurrence would silently pass a bulk edit that
  balloons the file, so `state-line-guard-selftest.sh` pins a
  fixture where only counting every `replace_all` occurrence produces the
  correct denial. Anything the hook cannot project with confidence — a
  missing file, an `old_string` that is not present, fields of the wrong
  type — is left to the real tool, which reports a clearer error than a guess
  here would; the guard only ever touches files named exactly `STATE.md`, at
  any depth, matching the same basename rule the global session-start hook's
  nearest-STATE-wins search already uses.

  **It is a RATCHET against the file's current size, not a flat gate at 60 —
  found by advisor review before the tag landed, not by the selftest, which
  had no fixture for it.** The first cut compared the projected line count
  only against `MAX_LINES`, never against what the file already was, so
  trimming an oversized STATE.md from, say, 156 to 100 lines — still over 60,
  but strictly smaller — was denied exactly like growing it would have been.
  Verified empirically against the real tree (2026-08-14):
  `wc -l ~/repos/*/STATE.md ~/repos/*/*/STATE.md | awk '$1 > 60'` found 23
  files already over 60 lines, one at 1405. Shipped as a flat gate, this hook
  would have made most of the machine's STATE.md files un-editable except by
  a single write landing at `<=60` in one shot — backwards for a guard whose
  whole point is making the trim the /insights finding asked for actually
  possible. The fix reads the file's current line count for BOTH tool types
  (previously only `Edit` read the file at all) and denies only when the
  projection is over `MAX_LINES` **and** larger than that current count: a
  compliant file still cannot grow past the limit, a brand-new file still
  cannot be created oversized (current defaults to 0), but an already-oversized
  file can always be edited toward compliance, one write at a time, without
  ever making it worse. Section 8 of the selftest pins all four cases:
  shrink-while-still-over-limit allows, same-size-rewrite allows, grow-an-
  already-oversized-file still denies, and create-new-oversized-file still
  denies.

  **`MAX_LINES` raised 60 -> 120, operator decision 2026-08-14 (evening),
  reported via coord by `.claude` after the global CLAUDE.md prose was
  already updated.** The ratchet mechanics above are unchanged - only the
  constant moved, plus every selftest fixture and boundary value that
  encoded 60 as a literal. Re-verified empirically against the real tree at
  the new threshold (2026-08-14): `wc -l ~/repos/*/STATE.md
  ~/repos/*/*/STATE.md | awk '$1 > 120'` found 13 files already over 120
  lines, one at 1496 - the historical 23-files-over-60/one-at-1405 figures
  above describe the tree as it was at the moment the ratchet bug was found,
  not the current threshold, and are left as-is rather than rewritten.
  `session-start.mjs`'s 160-line injection window still covers the new
  120-line limit with room to spare, so no change was needed there.

  **The Edit path's `current.replace(oldStr, newStr)` was a dollar-pattern
  injection bug, found and fixed 2026-08-15.** Passing `newStr` as a STRING
  makes JavaScript interpret `$`-sequences inside it ($&, `` $` ``, `$'`,
  `$$`, `$n`) as special replacement patterns, even though `oldStr` (the
  search side) is a plain string, not a RegExp. A `new_string` documenting
  old backtick-substitution style (`` $`cmd` ``) - exactly the prose a
  STATE.md's shell-conventions section writes routinely - triggers it.
  Measured against the real bug (`.claude/STATE.md`): a 5-line addition on a
  112-line file projected to 219 lines and was wrongly denied. Direction is
  always fail-CLOSED (never fail-open: it can only over-block, never
  under-block a real oversize), but it made exactly the kind of STATE.md
  that documents shell conventions hard to edit. Fix: replace with a
  function, `current.replace(oldStr, () => newStr)` - a function result is
  never pattern-substituted, so this covers every `$`-sequence at once, not
  a `` $` ``-specific escape. The `replace_all` branch (`split`/`join`) was
  never affected - `join` does not interpret its argument as a pattern.
  Pinned by state-line-guard-selftest.sh section 9 (`$\`` as the real repro,
  `$&` as a second sequence proving the fix is general).

  **F13 (2026-08-26): `MAX_LINES` is now overridable by
  `CLAUDE_STATE_MAX_LINES`, and an UNUSABLE override is refused by name rather
  than ignored.** As a bare constant the limit forced every boundary fixture to
  hardcode the same number the code carried - two copies of one policy, both
  rewritten by hand the last time the operator moved it (60 -> 120). The knob is
  the same kind `CLAUDE_COORD_DIR` is for the mailbox root. It is **not** a
  bypass claim: this guard has always been escapable by writing the file another
  way, exactly as the sibling pathguard is. The one thing it must never do is
  silently fail to take effect, so an unusable value (`""`, `"0"`, negatives,
  anything not made of digits) **denies with a message naming the variable**
  instead of falling back to 120 - a caller who set it and got the default
  anyway would be reading a limit that was never in force, which is the exact
  positive-looking null this whole tier of work closes. Empty counts as
  unusable, not as unset: it is what an expansion of an unset variable produces,
  and a value was meant. Recovery is one `unset`, and the message says so.
  Resolution happens AFTER the STATE.md basename gate, so a bad override can
  never block a write this guard would not have judged anyway.

  **Section 11's first cut was VACUOUSLY GREEN, and that is worth recording
  rather than quietly fixing.** The ratchet fixture wrote to
  `f13-ratchet-STATE.md` - a basename that is not `STATE.md`, so the guard
  allowed the write without measuring anything - and its path variable was not
  exported when `node` read it, so the fixture file was never created either.
  Two independent faults, one passing check, testing nothing. It was caught by
  an `ERR_INVALID_ARG_TYPE` trace in `npm test` output that a green summary
  line would otherwise have buried. The section now asserts its own ground
  truth (the oversized file really is 40 lines) before the check that depends
  on it, and carries the inverse case (growing that same file is still denied),
  so neither fault can recur silently. Mutation-verified: removing the ratchet
  now turns the check red, which it could not do before.

  **Since ORDRE 42 (operator, 2026-08-16) it carries a SECOND invariant: the
  projected content may not claim `status=done` in its board line while the
  repo holds commits the branch's upstream does not have.** Measured that day:
  two sessions had their push refused by the UFW rate limit on port 22, said so
  honestly in the coord inbox, and wrote `status=done` regardless - board line
  green, one commit unpushed, published surface 404. `done` meant "the session
  finished" where every reader takes it to mean "the work landed", and since
  `done` drops a repo from the board plan, `morning --say <repo>` could not
  reach either of them: one defect hid the other.

  **The order recommended a session-end hook and that direction does not exist
  in the form it assumes - measured against the official hooks docs, not
  reasoned.** `Stop` fires "once per turn", not once when the session ends, with
  no signal marking the last turn; its exit 2 "prevents Claude from stopping,
  continues the conversation", so a repo that genuinely cannot push (the very
  rate limit that caused the incident) would get a session that will not end.
  `SessionEnd` is the once-per-session event and cannot block at all
  ("Can block? No" - exit 2 "shows stderr to user only"), which is the
  after-the-fact nagging the order explicitly refused. Warn-on-write plus
  deny-at-session-end inherits the broken half and buys nothing. So the deny
  sits on the write, where the false claim is actually made.

  **The false-positive trap is real but bounded, and the deny is escapable by
  telling the truth.** STATE.md is written BEFORE the session's final commit, so
  a session that batches its pushes does hold unpushed commits at that moment -
  but the global git rule already requires a push immediately after every
  commit, and the real tree bears that out (2026-08-16: 43 of 44 repos carrying
  a STATE.md had nothing unpushed; the one exception was `status=blocked` and
  honest). `status=blocked` and `status=in-progress` stay writable in the same
  single edit, so a session that cannot push is never wedged - only stopped from
  claiming otherwise.

  **No ratchet here, unlike the line limit above, and the asymmetry is the
  reason.** An oversized file needs many writes to come back under the limit, so
  denying the intermediate steps would make trimming impossible; a false `done`
  is corrected by changing one token in the write already being made. A
  "deny only the transition into done" variant was rejected outright: the
  common shape is a repo that ended `done` last session and writes `done` again
  this session, which such a rule waves straight through. It **fails OPEN** on
  every git uncertainty - no upstream, detached HEAD, missing remote-tracking
  ref, not a repo, git slow or absent - because 8 of those 44 repos have no
  upstream at all (one already `status=done`), and a confident denial resting on
  a measurement that never happened is the worse error. The board line is
  selected with `board.sh`'s own anchor (`^<!-- board:`) and the status token
  compared exactly, so prose saying `status=done` never triggers it (a STATE.md
  documenting this guard writes that string routinely) and `done2` is not `done`
  here - and, since F3 (see `board.sh` below), not on `board.sh` either
  anymore: both now do the same exact match on the same extracted value, so
  `done2` reads as MALFORMED in both places, never as `done` in one and
  something else in the other.
  Selftest section 10, 17 checks, including the mandatory known-positive: a
  `status=done` with everything pushed must still go through, or the guard is a
  gate that denies everything and proves nothing.
- **Board (`scripts/board.sh`):** cross-repo attention board. Reads STATE.md
  next-step blocks + board lines, `git status`, and mailbox pending counts, and
  prints one line per repo. Read-only by construction: it writes to no repo, no
  STATE.md and no mailbox. Pinned by `board-selftest.sh` (368 checks).

  **It lives here because the mailbox is one of its three inputs, and it carries
  the same axis distinction the mailbox does.** A pending count means *others
  are waiting on this repo*; who a repo waits *on* comes only from its board
  line, because the message format has no reply-to field. Enforcing that in one
  of two repos would not be enforcing it. The operator invokes both `board` and
  `coord-send` exclusively through their Skill front doors, never a personal
  terminal alias — a claim this file carried until 0.12.1 (`~/.claude/scripts/board.sh`
  is a deployed copy the operator's `board()` function points at) did not survive
  inspection: no such file ever existed, and `route.sh` had no deployed copy
  either. Only the five `coord-*.sh` scripts were ever deployed there, and their
  one measured effect was an accidental fallback target for Claude sessions'
  own Bash tool calls (the bug 0.12.1 fixed) — once that fallback was gone they
  had no remaining function and were deleted.
  **`board.sh --brief` is a second RENDERING of that scan, never a second
  scan, and `brief-nightly.sh` is the only writer in that path.** The briefing
  answers the narrower question an unattended job can answer without judgement:
  which repos have an unhandled inbox, what their next step says in full, and
  the exact command to start a session in each. It prints NESTE uncut because
  the 38-character cut is the table column's property, not the record's — the
  value used to be truncated at record-build time, which left the cut string as
  the only copy. Each command is derived by CALLING `route.sh` with that repo's
  own four traits; `next-cost` alone cannot yield it, since the advisor flag is
  a property of the ROW and two rows can share a model/effort pair while
  differing on it. A repo with no route line is told so rather than handed a
  guess, because a guessed command reads as authoritative.

  **`board.sh --plan` is the THIRD rendering, and the only one that takes a
  position.** It answers which repos to open a tab for today, in what order,
  with which command. The position it takes is the ORDER and nothing else -
  there is no cutoff, so the plan hides nothing, and every term is a lookup over
  fields the scan already read. Since 0.20.0 it is FIVE ORDERED GROUPS -
  chain-root, debt, planned, in-progress, undeclared - ranked within a group by
  that group's own quantity, then a Sonnet next-cost, then oldest plan first.

  **0.19.0 shipped a weighted score here and 0.20.0 replaced it, and the
  objection the score answered is ACCEPTED, not forgotten.** A group order
  genuinely cannot express "this repo owes one message and releases two others"
  as one quantity; a score could, and that was its point. What a score could not
  do was hold still for the second consumer - re-tuning 40 against 15 silently
  reorders a parser living in another repo, and no test in THIS repo can catch
  that. The operator weighed both and chose the lookup (2026-08-03). Write that
  down every time this paragraph is edited: a later session that reads the
  objection as an unfixed defect will "restore" the score, and the round trip is
  the loop this file exists to stop.

  **`planned` ranks ABOVE `in-progress`, inverted at 0.20.0 by operator
  decision.** Turning a decision into motion is the slow step; live work is
  already moving. Flipping it back is a policy change, not a sort fix.

  **Debt is never excluded and never capped, and that is the rule most likely to
  be "fixed" into a defect.** Excluding `blocked` or `done` is a claim about a
  repo's OWN next step, which by definition cannot be moved, while owing a reply
  is the other axis entirely - answering is often what unblocks it. Measured on
  the real tree at 0.16.0, two of 26 planned repos were `done` with an unhandled
  inbox. A cap on debt was proposed with the chain credit at 0.19.0 and DECLINED
  by the operator. Sitting one group below chain-root credit is NOT that cap:
  the debtor keeps its tab, its most-owed-first position among the other
  debtors, and its `why=inbox:N`. A change that DROPPED a debtor from the plan
  would be the declined cap wearing the group order as a disguise, and selftest
  section 12 pins both halves - the root outranking four owed messages, and the
  debtor keeping everything it had.

  **"Debt" means OWED, never raw pending, since 0.22.0 - and this NARROWS what
  counts as debt, it does not reopen the paragraph above.** The paragraph above
  settles a different question: once a repo has debt, is it ever excluded or
  capped (no). This one settles what counts as debt in the first place. Through
  0.21.0, group 2's `keep`/`mag`/`why=inbox:N` and `--brief`'s whole "repo som
  skylder et svar" listing were computed from the raw pending-file count - every
  unhandled message in the inbox, including ones the sender declared
  `reply-expected: no`. That is a notice, not a request, and 0.11.0 gave
  `coord-count.sh` a second column (`owed`) for exactly this distinction - but
  `board.sh` never read it. Reported by morning-driver (2026-08-11) and
  independently reproduced against the live mailbox 2026-08-13: 27 of 72
  pending messages (37.5%) were notices. The fix joins `--plan` and `--brief`
  against `coord-count.sh`'s `owed` column by repo name (same technique as the
  chain-root `$UNBLOCKS` join below), so a `done`/`deferred`/`blocked` repo
  whose only mail is FYI no longer gets a tab, and `--brief` no longer counts a
  notice as an obligation. This reverses a decision from session 41
  (2026-08-10) that declined to build this filter, on the premise that "the
  arrival of the request IS the admission signal" - a premise that assumed
  group 2 already meant requests. It didn't; the code computed pending, the
  comments already said "owed" throughout, and the plan's own printed header
  ("Utelatt naar repoet verken skylder svar...") already claimed the exclusion
  was debt-based. The fix makes the code match what its own comments and
  header already promised. Pinned by board-selftest.sh section 8/12 fixtures
  `repo-done-fyi` (pending 2, owed 0 - excluded) and `repo-blocked-mixed`
  (pending 3, owed 2 - planned on 2, not 3). The TABLE's `INN` column and the
  raw scan (`RECORDS` field 6) are UNCHANGED - they answer "what is the state
  of every repo," not "who is waiting on you," and stay on raw pending by
  design.

  **The same 0.22.0 patch that switched `n_owe` to OWED also had to fix what
  `n_owe == 0` claims.** `--brief`'s empty-debt branch said "Ingen repo har
  uhaandtert innboks. Ingen skylder noen et svar i dag." (no repo has
  unhandled inbox; nobody owes a reply) - two claims in one branch, and only
  the second is what `n_owe == 0` actually proves once `n_owe` means OWED. A
  repo can hold FYI-only mail with zero debt, which makes the first sentence
  false while it fires - caught in review before release, not by any fixture
  (the shared test tree never reaches `n_owe == 0`, since it always carries a
  debtor). Fixed to state only the debt claim, and to name any FYI-only
  mailboxes found rather than let their existence become invisible again -
  the same "labelled, not silently dropped" principle `--plan` already
  applies to unknown-status repos. Pinned by board-selftest.sh section 14
  with its own isolated root (debt-free, one FYI-only repo).

  **The `$UNBLOCKS`/`$RECORDS` join used `NR==FNR` through 0.21.0, and that
  idiom silently drops the entire plan whenever the FIRST file is empty - fixed
  to `FILENAME==` comparison in 0.22.0, found while adding the `$OWED` join
  above.** Verified against the shipped 0.21.0 script: one in-progress repo
  with an unhandled inbox message, zero blocked repos anywhere in the tree
  (so `$UNBLOCKS` is empty, which is a common, ordinary tree state, not an
  edge case) - `--plan` printed "0 tabber". `NR==FNR` is only true for the
  FIRST file's own lines; when that file is empty, `FNR` and `NR` stay equal
  for the ENTIRE next file too (not just its first line - verified with a
  minimal awk reproduction), so every record in it is misrouted into the
  `ub[]` branch and dropped via `next`. This was invisible to
  board-selftest.sh because the fixture tree has carried at least one
  `blocked` repo since the chain-root feature shipped, and it was invisible
  on the real tree because `~/repos` currently always has one too - neither
  is a guarantee. `FILENAME==UBF`/`FILENAME==OWF` compares the exact path,
  never line counts, so an empty lookup file degrades to "nothing matched,"
  never to "everything after it is misrouted."

  **Chain-root credit lands on the ROOT and nowhere else.** For every `blocked`
  repo the `blocked-on` edge is followed transitively to the first repo that is
  not itself blocked. Crediting a blocked repo would open a tab that cannot move;
  crediting only the direct blocker leaves a two-hop chain's root uncredited,
  which is the shape the real tree actually had. A cycle, a `blocked-on` naming
  an unscanned repo, and a blocked repo with no target must all credit NOBODY:
  inventing a root there produces a plan that looks correct and sends the
  operator to the wrong repo.

  Repos with no board line rank last and are LABELLED rather than dropped,
  because the table already prints a MERK line about them and a plan that
  omitted them silently would repeat that defect.

  It renders `key=value` blocks, not prose, because it has two consumers: the
  operator, and a driver repo consuming the plan. Prose would make the rendered
  format an API no test in THIS repo could hold stable for a consumer in
  another. `command_missing=` carries both no-command causes (no route line, and
  a route line route.sh rejects) because a bare `command=` is the shape of a
  runnable command carrying nothing - a driver reading `^command=` would type an
  empty line into a live pane. `route_cmd_for()` is the single reader of the
  route-line grammar, shared with `--brief`, and distinguishes the two causes by
  exit code rather than by an empty string.

  **`paste=` and `dir=`/`command=` are the same fact for the two consumers, and
  neither is redundant.** A driver moves the pane itself and then types the
  command, so it needs them apart; a human needs ONE thing to select. Handing
  the operator two fields to join by hand is not a saved output line, it is the
  step where a session starts in the wrong repo - and it was measured the moment
  the feature met its first user, who could not act on the block at all. `paste=`
  is emitted only alongside `command=`: `paste=cd X && ` with nothing after it
  would run the cd and then a bare newline, which fails SILENTLY by leaving the
  operator in the right directory with no session started.

  **`board.sh --dispatch` is the FOURTH rendering, and the generator-ownership
  question it settles was open for two sessions.** It carries a task INTO
  another repo — "start a session in repo X, on order Y, at cost Z" — and emits
  either a plan block or a single paste line. It lives in `board.sh` rather
  than in a script of its own for one reason, and it is the reason the operator
  and `.claude` both named first: the block format has exactly ONE generator,
  and this file already is it. A second emitter of
  `tab=`/`repo=`/`dir=`/`command=`/`paste=` would be two copies of one file
  format, drifting apart, with a second place to get `paste=` wrong. Read-only
  survives untouched: every check is a read, and the two writes a dispatch needs
  (prompt file, plan file) stay with the caller — the same split
  `brief-nightly.sh` already carries for the briefing.

  **The cost comes from `route.sh`'s row table, and `--dispatch` deliberately
  refuses a `--model`/`--effort` pair.** `--advisor opus` is a property of the
  ROW; two rows share a model/effort pair while differing on it, and the CLI
  accepts a wrong advisor silently. A dispatch taking the model directly would
  have no honest source for that flag, and both available guesses produce the
  same failure — a session that looks peer-reviewed without being. A Fable
  dispatch is therefore not a `--dispatch` outcome at all, exactly as it is not
  a `route.sh` outcome; it is a hand-written override.

  **`--target-pane yes|no` is REQUIRED, with no default, and that is the same
  rule `--last-effort` carries.** It is a measurement of the world — does the
  target repo already have a Ghostty pane — and this repo must never learn to
  look for a terminal itself; the caller measures with `morning --probe-panes`
  and passes the fact in. Defaulting would be worst at `no`: that is the
  plan-file form, and `morning`'s `plan_drop_open` (morning:1788) silently drops
  a plan block for a repo that already has a pane, reporting "0 of 1" — which
  reads as a broken plan file. Measured four times on 2026-08-16 by two
  different repos. The `yes` form therefore emits **no `tab=` key at all**:
  `plan_parse` discards a block without one, so the wrong use is impossible
  rather than merely discouraged.

  **The dry-run is a parse check, not the pane gate, and the difference was
  measured (2026-08-16).** `morning --plan-file <f> --dry-run` proves the block
  parses and yields a command. Run from a Claude session there is no tty, so
  `morning` prints "window: unknown ... assuming an empty window" and
  `plan_drop_open` never fires — a gate built on it would pass the self-dispatch
  case every single time, which is the one case it would exist to catch.
  `--probe-panes`, by contrast, DOES work without a tty: it cannot identify the
  anchor pane, but the `DIR` column is there.

  **The prompt goes in argv, and only the PATH has to be shell-clean.** Verified
  directly: `"$(cat f)"` hands the file's bytes to the session as one argv
  element with no re-evaluation, so `$(...)`, backticks, quotes and UTF-8 in the
  BODY are inert — which is precisely why the prompt is passed this way instead
  of inlined. The path sits inside those quotes and IS evaluated, so it must be
  absolute (a relative one resolves against the pane's directory, not the
  emitter's) and drawn from a safe character class. An empty prompt file is
  refused with `test -s`: it would start a session and tell it nothing, which
  from the far end is indistinguishable from one waiting for a Go.

  **Driving a terminal from the plan does NOT belong here, and the measurement
  in `docs/ghostty-orchestration-measurement.md` is the argument, not taste.**
  It is a version-pinned undocumented composition over a preview API whose
  documented path is already broken upstream and whose regression was closed as
  not planned, with a blast radius reaching into other repos' live sessions.
  None of that is mailbox transport, and none of it may be able to break
  `coord-inbox` or `board`. The dependency runs one way: the driver consumes the
  plan, the plan never knows a terminal exists.

  **Order 20260826T115026Z-9982513971 (2026-08-26): board consumed
  `coord-count.sh`'s STDOUT and threw away its EXIT STATUS, so the whole
  three-status contract F5 had just built stopped at the producer.** Every call
  site piped it (`bash coord-count.sh 2>/dev/null | awk ...`), and a pipeline
  reports the LAST stage's status, so `exit 3` - "the mailbox root you named is
  not there, not counted, not zero" - was discarded at each one. `HAVE_COUNT`
  only ever tested that the SIBLING FILE exists, which is a strictly weaker
  question. Measured on the shipped 0.30.0 script against a mailbox root that
  does not exist: `coord-count.sh` printed "not counted, not zero" and exited 3
  while `--brief` answered "Ingen repo skylder noen et svar i dag." and `--plan`
  emitted no `advarsel=` key at all. A gate that can fail whose consumer does not
  listen is a gate that does not fall. It was carved out of F5 deliberately
  rather than swept in - that session scoped itself to `coord-count.sh` and said
  widening in silence was not its call, and the operator agreed - which is why
  this is its own order and its own commit.

  **`COUNT_OK` is the measurement's verdict; `HAVE_COUNT` stays, and the two
  messages stay DISTINCT.** "The sibling is missing" is repaired by restoring a
  file, "the world you named is not there" by fixing `CLAUDE_COORD_DIR` - the
  same reason `coord-count.sh`'s own 2 and 3 are different statuses, and a
  reader handed one "unavailable" for both cannot tell which repair to make.
  `$COUNT_WHY` carries the exact reason, including the status number, into all
  five reporting sites, and any nonzero is caught - the rule is "the measurement
  failed", not "3 specifically". A partial stdout captured before a failure is
  DISCARDED: a half-count is the same defect one layer down, since it also looks
  measured. Selftest section 27 pins the failure cases behind SIX known-positive
  controls (an existing root still names its debtor; a successful measurement
  warns about nothing; an existing but EMPTY root still claims zero debt) plus a
  ground-truth assertion that `coord-count.sh` really does exit 3 on that input,
  so a future coord-count that stops doing so fails the section rather than
  silently disarming it. Mutation-verified: restoring `if true` in place of the
  status test turns exactly those seven checks red and leaves all six controls
  green.

  **The three separate `coord-count.sh` invocations `--brief` used to make are
  now one.** With a status to honour, three runs would mean three statuses to
  reconcile; `coord-count.sh` writes nothing, so one reading is the same reading.
  The table and `--plain` views still never invoke it at all - they read the
  mailbox only through what `RECORDS` already counted, and `$COUNT_WHY` says so
  in those words rather than claiming a measurement nobody attempted.

  **Bounded gap, stated rather than closed:** the TABLE's own `INN`/`ORDRE`/`FLY`
  columns count with `ls "$COORD/$name/..."`, which yields 0 for every repo when
  the mailbox root is absent - the same "failed measurement renders as a
  reassuring value" shape, one source over. It is NOT a `coord-count.sh`
  consumer, so consuming exit 3 cannot reach it, and the order scoped itself to
  exit 3 and warned by name against silent widening. Naming it here is the
  point: the next session finds a decision, not an oversight.

  It also cross-checks itself against `coord-count.sh`, and that is not
  belt-and-braces. The repo scan and the mailbox are two different populations:
  a mailbox can carry a name no scan will ever produce — a declared non-git
  surface (`CLAUDE_COORD_REPO`, e.g. `~/repos` itself) or a checkout outside the
  roots. Measured on the real mailbox at 0.15.0: the briefing found 11 repos /
  21 messages where `coord-count` saw 12 mailboxes / 22 pending, the missing one
  being the declared surface `repos`. A briefing that only walks the scan
  answers "who is waiting on you" with a number it quietly knows is short.

  **Zero model calls, and that is the load-bearing property, not an
  implementation detail.** The operator authenticates by subscription, so a
  headless `claude -p` job draws from the same quota pool as interactive work.
  Measured against 2.1.220: `--max-budget-usd` DOES bite under subscription auth
  (`terminal_reason: budget_exhausted`, exit 1), but it aborts AFTER turn one,
  never before it — floor ~0.25 USD-equivalent per turn on `claude-opus-5[1m]`.
  It is a runaway brake, not a pre-flight gate. Making the briefing deterministic
  removes the question entirely.

  `board.sh` stays read-only, which is why the file write lives in the wrapper
  instead of behind a `--brief --out FILE` flag. The wrapper renders to a temp
  file in the target directory and renames it into place, and treats an EMPTY
  render as a FAILED one: board prints nothing at all when its scan roots do not
  exist, which is what a mistyped path or a moved home directory looks like, and
  a plain `> file` redirect would destroy yesterday's briefing on a bad launchd
  environment. A tree where nobody owes anything is a different case — that is a
  valid, non-empty briefing saying so, and is written normally.

  **F3+F4 (2026-08-16): the status classifier and `route_cmd_for()`'s four-trait
  extraction both matched a PREFIX of the closed vocabulary, not the exact
  token.** Both used a `[a-z-]*` sed capture, which stops at the first byte
  outside that class instead of running to the field's real boundary. Two
  distinct failure shapes came out of the same defect: `status=done2` (a valid
  token plus one byte) captured as `done` and was silently classified as a real
  `done` - excluded from `--plan` the same way a genuine done repo is, and shown
  green in the table, never flagged; `status=Planned` (a case variant) captured
  as empty and was silently classified as `?` - "no board line at all" - which
  fed the MERK footer a false count for a repo that has one. `route_cmd_for()`
  carried the identical class on all four route traits, and there the failure is
  worse: `path=known2` truncated to `known`, which `route.sh`'s own exact-match
  validation then ACCEPTS, producing a safely-worded but WRONG startup command
  (row 1) instead of the refusal a typo like `knwon` (a whole different word,
  already handled correctly) already got. Fixed by capturing to the next `;` or
  the closing `-->` instead - the same `[^;>]*` + trim shape `next-cost` already
  used for its own reason (spec-conformant values contain spaces and capitals) -
  so the classifier and `route.sh`'s case statement see the value un-truncated
  and the exact-match either accepts it or correctly calls it MALFORMED /
  `command_missing=`. `blocked-on`'s `[A-Za-z0-9._-]*` capture is a different,
  wider class feeding a different mechanism (matched against scanned repo
  names for chain-root credit, not a closed vocabulary) and was checked, not
  touched - grepping `scripts/board.sh` for `[a-z-]*` after the fix returns
  nothing. Selftest fixtures `repo-status-prefix`, `repo-status-case`,
  `repo-trait-prefix` and `repo-revers-prefix` pin all four cases, plus the
  known-positive controls that a genuinely absent board line still reads `?`
  and a genuinely valid route line still derives a real command.

  **F12 (2026-08-17): a third `NR==FNR` survived at the focus-filter join in
  `plan()` (`fp_names` x `pf`), next to two comments (the block above and the
  one on `--brief`'s OWED join) that already state the file's own rule -
  "never by `NR==FNR`" - as prose. Measured, not assumed, before touching
  it: for a plain two-file keep-set join with no THIRD file whose lookup
  table a misroute could corrupt, an empty `fp_names` produces the SAME
  output (0 kept) under `NR==FNR` and under `FILENAME==` alike - run
  standalone with both forms against both an empty and a non-empty first
  file, output was identical every time. That is because when `fp_names` is
  genuinely empty (0 repos anywhere declare the resolved focus slug), 0 kept
  IS the correct answer, unlike the two prior instances in this file where an
  empty first file corrupted a lookup table (`ub[]`/`ow[]`) consumed by a
  THIRD file and silently dropped repos that should have stayed. Stronger
  than that: `FOCUS_SLUGS` is provably a subset of what `focus_slugs()` finds
  by scanning the same `$RECORDS`, and `focus_declares()` re-checks the
  identical regex against the identical `$RECORDS`, so `fp_names` cannot be
  empty while the filter is applied in normal use - there is no reachable,
  observable defect here to pin behaviourally, and a `--focus` fixture
  asserting one would pass identically before and after the fix, which this
  repo's own CLAUDE.md already names as the "unmeasured assumption wearing a
  passing test" defect class. The fix is applied anyway, but for a different
  reason: it is a live counter-example to a rule the file states about
  itself, and a trap for the next session that greps `NR==FNR` expecting
  every hit to be a bug and finds one that quietly works. Selftest section 21
  pins it structurally - `board.sh` has no `NR==FNR` outside a comment line,
  with a known-positive control proving the comment-stripping grep can still
  find a live one when planted - never behaviourally, because there is no
  behaviour to pin.**

  **F6+F10 (2026-08-26): two of the board's own readings turned a FAILED
  measurement into a reassuring value.** `git -C "$d" status --porcelain
  2>/dev/null | wc -l` yields zero lines whether the tree is CLEAN or git
  refused to answer at all, so DRT printed **0** - and every reader took that
  as "nothing uncommitted here" (F6). It is reachable, not theoretical:
  discovery tests `.git` with `-e` precisely so worktrees are found, and a
  worktree whose parent checkout was deleted exits **128** here (measured
  directly before the fixture was written, and the fixture asserts that ground
  truth itself so a future git that starts answering fails the check rather
  than silently disarming the section). The exit status is now the
  discriminator and an unmeasured tree reads **`?`** - the same token
  `coord-count.sh` already uses for an age it could not compute, for the same
  fail-safe reason. **The fix is worthless without its two awk consumers, and
  one of them is the whole point:** `--plan`'s free-capacity test compared
  `$7 + 0`, and `"?"` coerces to **0** in arithmetic, so an UNMEASURED tree
  would have been certified as free capacity - the defect reappearing one
  layer down, wearing the fix as a disguise. It now compares the field as a
  STRING against exactly `"0"`; only a tree measured clean is clean. Mutation
  test: restoring the numeric comparison turns exactly that one check red
  while both controls (clean repo still free, dirty repo still not) stay
  green. The SUM roll-up sums the same field, where a `?` adds 0 and quietly
  understates the total, so it now NAMES the repos it could not add -
  labelled, never silently dropped, the same rule `--plan` already applies to
  repos with no board line. Every SHELL consumer prints the field with `%s`
  and was unaffected; that denominator was measured, not assumed.

  **F10 is the same defect at the scan boundary.** `[ -d "$root" ] || continue`
  skipped a bad root in silence, and a scan that then found nothing exited 0
  printing nothing - so a typo in `--roots`, a moved home directory and a
  genuinely empty tree were one single output, with the nevner never reported.
  Every bad root is now NAMED on stderr; the exit status changes only when NO
  root was scanned at all (**3**, matching `coord-count.sh`'s F5 fix for the
  same reason). **A mix still exits 0 and still prints the board** - some repos
  really were scanned, so the board is real; the reader just also learns that
  one root contributed nothing because it is absent rather than because it is
  empty. An EXISTING but empty root stays a silent, clean 0. This REPLACES an
  older assertion reading `check "missing root is a clean no-op"` - the defect
  encoded as a passing test, which is why nothing ever caught it.
  `brief-nightly.sh` needed no change and gains from this: it already treats a
  nonzero `--brief` as failure and keeps yesterday's briefing, so a mistyped
  root now preserves the file instead of overwriting it with an empty render.

  **Ordre 20260818T124828Z (2026-08-18): repo discovery had no dotglob, so a
  dot-prefixed repo (`.profile`, the Forgejo/GitHub org-profile convention)
  was permanently invisible to the board - not listed, and `--dispatch
  --repo .profile` refused outright with "no repo named '.profile' in the
  scanned roots".** Measured with a known-positive control by `.claude`
  before the order was written: two repos in one root, one dot-prefixed one
  not, `board.sh --plain` found only the non-dot one. **The obvious fix -
  `shopt -s dotglob` on the existing discovery loops - is wrong, and the
  order proved it before this repo ever wrote one line:** turned on, the
  SAME `[ -e "$entry/.git" ]` test that already decides repo-vs-container
  would route a dot-prefixed directory that is NOT itself a repo (e.g.
  `.claude`) into the else-branch polyrepo-container scan, silently
  expanding what counts as a container to a class of directory nobody
  vetted for that. The fix is a dedicated `add_dot_repos()`, called once at
  root level and once per polyrepo container (the identical gap exists at
  both `board.sh:265` and `:271` - "same glob, two places" in the order's
  words): it walks `"$1"/.* ` and adds an entry ONLY when that entry is
  ITSELF a git repo, skipping `.` and `..` and skipping every dot-directory
  that isn't a repo outright - never recursing into it as a container. No
  `shopt` toggle is needed at all: `.* ` as a literal glob pattern already
  matches dot-entries without `dotglob` set - only a bare `*` needs it -
  which is what makes the targeted function possible without touching the
  existing `*` loops' behavior for ordinary (non-dot) entries at all.
  Verified against the real tree (2026-08-18): `.profile` and `.github`
  (both real repos) now appear; `.claude` (a directory, not a repo) stays
  invisible, exactly as before. Selftest section 22 pins the known-positive
  control the order specified - two repos in one root, board must find
  BOTH, not just the dot one - plus the container-non-promotion case (a
  dot-dir with a child repo must NOT surface the child) and the depth-2
  case (`:271`).

  **Bounded gap, stated rather than closed:** a dot-prefixed directory that
  is not itself a repo is never treated as a polyrepo container, so if a
  directory like `.claude` ever grows an actual git-repo child, that child
  stays invisible to the board - the identical class of gap `board.sh`
  already accepts for orders addressed to an unscanned mailbox name. Widening
  dot-directories to ALSO act as containers was deliberately left undone:
  it was exactly the unmeasured side effect the order flagged, and nothing
  in `~/repos` currently needs it (`.claude` has no repo children today).

  **Ordre 20260820T204409Z (2026-08-20): `route_cmd_for()`'s four trait
  extractions searched the WHOLE route line, and `.*trait=` is greedy, so a
  rationale that names a trait won the match over the field itself.**
  `route.sh --help` asks for a rationale per score, so a real rationale names
  the traits routinely - this is the ordinary shape of the data, not an edge
  case. Measured by `.claude` on four live STATE.md files before the order was
  written: catalog's `path` read `known: notatet som skal skrives...`,
  app-creator's read `known. Ingen maskin sjekker...`, claude-code-llm-wiki's
  read `undetermined), det er en prosa/beslutnings...`; okr's read `known`
  correctly, because its rationale happens to name no trait - and that
  contrast is what isolates the parser from the data. `route.sh` then refuses
  the prose (exactly as it should - it was handed garbage, and it is not
  changed by this fix), `--plan` prints `command_missing=route-linjen kunne
  ikke tolkes`, and the operator reads a broken PARSER as "that repo has no
  route line": Verifiseringsloven ansikt 4 turned on our own tooling. The
  denominator was measured, not estimated - and then re-measured here rather
  than quoted: A/B-ing the pre-fix script against the fixed one over the real
  tree at the same moment gives 25 tabs, `command_missing` 7 -> 2, and the five
  repos that gained a command (app-creator, catalog, claude-code-llm-wiki,
  llm-security-commons, portfolio-optimiser-commons) are exactly the five the
  order named. The two that remain are real and belong to their own repos:
  `okr` writes `scope=multi-module`, outside the vocabulary, and `llm-security`
  has no route line at all.

  **The fix cuts the line at the first `rationale=` before extracting, and
  keeps the `[^;>]*` class exactly as F4 left it.** The two are answers to
  different questions and neither replaces the other: F4 stopped a valid-
  looking token from being TRUNCATED into something `route.sh` would accept
  (`known2` -> `known`), this stops the search space from containing prose at
  all. The cut keys on `rationale=` rather than `; rationale=` because
  everything from that token on is free text by definition and the separator
  form would miss a line written without the space. A route line that placed a
  trait AFTER the rationale would lose it and degrade to `command_missing=` -
  the safe direction, and the one this fix exists to restore.
  The board line needs no equivalent change, and that was measured rather than
  assumed: `grep -n 's/\.\*' scripts/board.sh` is the denominator, and the
  board line's grammar (`status` / `blocked-on` / `next-cost`) carries no
  free-text field, so no trait token can occur on it twice. Selftest section
  23 pins both failure directions - the greedy repo that must now yield a
  command, and the sharp inverse where the FIELD is invalid (`known2`) while
  the rationale holds a VALID value: before the fix that emitted a confident
  `command=` built on prose the STATE line never declared, which is worse than
  the missing command it usually caused. Two known-positive controls
  (a trait-free rationale, and a route line with no `rationale=` at all) prove
  the cut does not break the path that already worked.

- **Route (`scripts/route.sh`):** pure calculator for the next session's model
  and effort. Takes four scored traits of the next task plus a required
  rationale, and prints one block of `key=value` lines: the rubric row, the rule
  that fired, the `next-cost` value, a pasteable startup command, the one-row
  cheaper fallback, and the STATE.md comment lines. Pinned by
  `route-selftest.sh` (73 checks).

  **It is here because it is the WRITER for the field `board.sh` already reads.**
  `next-cost` had a reader and no writer, so it was hand-typed every session and
  drifted into several competing spellings — cleaning the data
  could not fix that, because the cause was the missing write path. The row
  table is a closed set of six values, so a seventh cannot enter circulation,
  and section 6 of the selftest runs the round trip (route emits → board parses)
  *inside* one repo rather than across two. `board.sh` itself is untouched: a
  calculator that prints to stdout writes nothing, and the session writes
  STATE.md.

  **The row table is the operator's global rubric, moved here as the single
  copy.** It is not a second spec — `board.sh --help` documents the board line's
  *grammar* and points here for the *values*. Scoring the traits is judgement
  and belongs to the skill; turning scores into a row is a lookup and takes zero
  model calls.

  **`--advisor opus` is emitted per ROW, on a need, never unconditionally.**
  Rows 1-2 always carry it (Sonnet main model, so opus is a capability lift —
  and since every fallback is one row cheaper and the cheap rows are Sonnet,
  this is what makes the quota fallback safe to take); rows 3-4 only at
  `reversibility=costly|one-way` (Opus main model, so it buys peer review where
  a mistake is not cheap to undo); rows 5-6 never, because the CLI rejects every
  advisor for a Fable main model. The alternative — the global `advisorModel`
  setting written by `/advisor` — is what this replaces: it applies to every
  session in every repo, which is how it burned quota before. The two triggers
  are almost disjoint by construction, since `costly` forces row 3 and `one-way`
  forces row 4, so a Sonnet row always has `reversibility=cheap`.
  `verification=none` is deliberately NOT a third trigger: beyond the stakes
  rule it would only add mistakes that are cheap to reverse, docs sessions
  (`known/none/cheap/local`) among them. Section 14 pins the rule and gates the
  three CLI facts it rests on against the installed `claude` without spending a
  token — advisor validation runs before the empty-prompt check, so `-p ""`
  reaches the validator and stops there.

  **Rows 5-6 are never a `route.sh` outcome.** Until 2026-08-06 they fired
  only from an explicit `--opus-xhigh-failed` flag, mirroring a global
  CLAUDE.md policy that Fable could only be *suggested* after a failed Opus
  5/xhigh session. That policy was removed by operator decision — "for ofte
  ER Fable riktig" — and the flag went with it rather than being repurposed:
  `route.sh`'s output range is now closed at row 4, and a Fable choice is
  always a hand-written deviation from the rubric, recorded in STATE as an
  override per the model-selection rule in the global CLAUDE.md, never
  produced by the calculator. `board.sh` still parses "Fable 5/high" and
  "Fable 5/xhigh" written by hand into the board line — that parsing is what
  the override actually uses, and it is pinned separately from anything
  `route.sh` emits (route-selftest.sh section 6).

  **`--last-effort` is MEASURED from `CLAUDE_EFFORT`, and the calculator must
  never default it.** Claude Code exports that variable into every tool-use
  context as the session's current effort, so the caller reads it and passes it
  in; having `route.sh` read it directly would make the output depend on the
  environment instead of on its arguments, and the round trip in selftest
  section 6 rests on that determinism. The two sources it replaces fail
  identically: the previous board line holds what was *prescribed*, and asking
  the operator launders that same prescription through someone reading their own
  startup command. Corollary pinned by section 13: `skills/route/SKILL.md` must
  never declare an `effort:` frontmatter field, because frontmatter overrides the
  session effort and the reading would then measure the skill, not the session.
  **Order 20260901T185028Z-3612729538 (2026-09-01): `--last-model` was a closed
  set of three, Fable 5.1 shipped that day, and the refusal turned a
  measurement into a lie.** A session that genuinely ran Fable 5.1 could not
  record what it ran, so its record was either omitted or written as a name
  already in the set - and a lied record reads back months later as a
  measurement rather than as the gap it is. The whole point of the four
  `--last-*` fields is to be readable evidence, so this is the field's own
  failure mode, not a cosmetic one. Both edit sites moved, never one: the usage
  block and the validating case, because fixing the case alone is the
  two-copies-of-one-policy defect this file names repeatedly.

  **"Fable 5" is KEPT, and the reason is NOT backward compatibility.** The
  nevner was measured rather than assumed - exactly 1 of 45 `route-last` lines
  across the machine carries it - which is thin enough that a future session
  would happily "clean up" the one stale line and then drop the value. The
  load-bearing reason is that `route.sh`'s own row table spells rows 5-6
  `Fable 5/high` and `Fable 5/xhigh`. Dropping the value would make the script
  refuse to record a name its own spec writes.

  **The set is WIDENED, never replaced by form validation, and the selftest is
  what makes that a fact rather than a paragraph.** A pattern like
  `<family> <digits>[.<digits>]` would still catch a misspelled family and a
  drifted case (`opus 5`), and would stop catching **a version that does not
  exist**: `Fable 5.2` and `Opus 7` would both pass and read back as evidence
  that a model ran when it never shipped - the positive-looking null this repo
  refuses everywhere else, in the one field whose entire purpose is to be
  believed later. Section 8b therefore rejects `Fable 5.2` / `Fable 6` /
  `Fable 5.10` beside the accept case, so a later switch to form validation
  fails here instead of silently widening what the record can claim. The cost
  of the closed set is real and was paid before the choice was made, so the die
  message now names the repair - a newly shipped model is ADDED to the list,
  never approximated to a value already in it.

  Untouched, deliberately: the row table (still six rows; `route.sh` still
  emits only 1-4, and Fable remains a hand-written override), and the note that
  a Fable session runs without an advisor because the CLI does not enforce it.

  **Bounded gap, stated rather than closed:** `Fable 5.1/xhigh` is 15
  characters and overflows `board.sh`'s `%-14s` KOST column, shifting the rest
  of that row one column right. Parsing is unaffected - `next-cost` extraction
  is free text, and selftest section 6 now pins that the point release survives
  the round trip - so this is alignment, not data. Widening the column is a
  `board.sh` rendering change nobody ordered in this session, which is also why
  the value is deliberately ABSENT from section 6's widest-value loop: adding
  it there would go red, and the red would be the unfixed gap wearing a broken
  test's clothes. Reported to `.claude` instead.

- **Board's ORDRE column** counts PENDING orders per repo with the identical
  idiom as INN, and the two are never summed: INN is "others are waiting on
  YOU" (outgoing obligation), ORDRE is "authorized work is waiting on this
  REPO" (incoming). Claimed orders are excluded from THIS column — it answers
  what a session can pick up, and one in flight cannot be; since 0.29.0 they are
  counted in FLY beside it (below). Bounded gap, stated rather
  than closed: an order addressed to a mailbox with no matching directory in
  the scanned roots is invisible here, exactly as mail to such a name is
  invisible in INN. There is deliberately no join built for it; `coord-count.sh`
  is the cross-check for the mail half only.

  **Order 20260823T162951Z (2026-08-23): ORDRE alone printed the SAME DIGIT for
  two opposite facts, and the fix is a second column, not a fourth axis.** A
  repo holding one order in flight and a repo holding no orders at all both
  read `ORDRE 0` — "work is happening here" and "nothing is waiting here" were
  byte-identical rows. Measured the day the order was written: two panes stood
  open and idle for 45 hours holding finished orders, during a window with full
  quota authorised, and no column on the board reported it. **FLY** counts
  `orders/claimed/` — the same queue in its other state, which is why it is a
  second reading of a source the board already had rather than a new source,
  and why it is never summed with ORDRE. Verified live: one repo moved from
  `ORDRE 0` to `ORDRE 0 / FLY 1` beside another still reading `ORDRE 0 / FLY 0`
  and genuinely holding nothing.

  **FLY never claims a session is ALIVE, and the legend denies it in those
  words.** A claim is a `mv` a session performed once; nothing un-claims it when
  that session dies, which is precisely why `coord-order-inbox.sh` already shows
  claimed orders with their in-flight age. Measured on the live mailbox the same
  day: one order had been claimed for **117 hours**. Rewording the column into
  "a session is running here" would be the process axis smuggled in as a file
  count. Selftest section 24 pins the denial as a check on the legend TEXT, so
  the wording is engine behavior and not prose.

  **Order 20260829T045435Z-276822386 (2026-08-29): both columns were pure
  COUNTS, so ORDRE 2 read identically whether both orders arrived yesterday or
  both had sat for ten days.** They now render `N:Md` - the count and the age of
  the oldest order. The defect was never that orders sit there; that is a
  prioritisation question owned by humans. It was that NO SURFACE SHOWED THE AGE
  ACROSS REPOS: `coord-order-inbox.sh` does show one ("1d old"), but only inside
  the one repo at SessionStart, so a repo nobody opens shows nobody anything.
  Measured across the live mailbox that day with `find ~/.claude/coord -path
  '*/orders/*.md' -maxdepth 3 -type f`: 30 pending orders over 22 repos, 5 of
  them ten days old. This is not a new mechanism in the file - ALDER (STATE.md
  mtime) and SISTE (last commit) already read a clock the same way; it is a
  third application of a measurement `board.sh` was already making.

  **The age is the OLDEST order, never the newest and never a mean.** A repo
  holding one fresh order and one ten-day-old order has a ten-day-old problem,
  and the newest reading is precisely what would hide that case. Mutation-
  verified: flipping `-lt` to `-gt` in `oldest_order_age()` turns exactly the
  two oldest-specific checks red while every control stays green. FLY carries
  the identical reading, and there it matters at least as much: nothing
  un-claims an order when the session that took it dies, so a claim with no age
  is the 117-hour claim above with its only counter-evidence removed.

  **An empty queue prints a BARE 0, and an unreadable mtime prints `?`.** "No
  orders" and "an order that arrived today" are two different facts - the same
  reason FLY exists beside ORDRE in the first place - so `0` never grows a
  `:0d`. `?` is reported for the WHOLE reading rather than skipping the file,
  because an unmeasured file could be the oldest one, which makes "oldest" a
  claim the function is no longer entitled to make; it is the same token
  `coord-count.sh` and DRT already use for a measurement that failed.

  **The age is DISPLAY only - it is deliberately NOT in the sort.** Putting it
  in the ranking would silently reorder a parser living in another repo, which
  is the standing rule two sections up, and the order made it an explicit
  condition: a new sort axis would have to be stated in the commit message and
  in `--help`. It was not needed, so it was not taken. `--plan`'s `fly=` key and
  every other emitted `key=value` block are likewise untouched: the requirement
  is that a HUMAN reading the board can see an order is old without opening the
  repo, and the table is where that is read. Selftest section 28 builds a
  throwaway coord tree with `touch -t` mtimes and asserts its OWN ground truth
  (the stale fixture really is 10 days old) before anything depends on it, so a
  broken `touch -t` fails there rather than turning the section into a test of
  nothing.

  **Order 20260903T185736Z-1290610855 (2026-09-03): the PENDING age read the
  mtime, and `coord-order-done --return` rewrites it - 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` minutes later. It is the
  same class as every other reading hardened here - a failed or reset
  measurement rendering as a reassuring value - with the twist that the reset
  was performed by the engine itself.

  **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, and only
  the filename carries that; it is written once and nothing rewrites it. 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()` rather than replacing it, and `coord-order-inbox.sh`
  keeps `age_of` for the claim marker next to a new `pending_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 - the same rule the mtime path already carried.

  **Section 28's fixtures had to be rewritten, and that is the finding worth
  recording.** They encoded their intended 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 - the checks would have started failing
  on their own as the wall clock moved past them. They now compute their stems
  from `date -v`, and the section asserts TWO ground truths, the filename for
  ORDRE and the mtime for FLY, because a fixture check guarding only one source
  leaves the other assertion resting on nothing. Mutation-verified in both
  files: restoring the mtime read turns exactly the defect checks red with
  every control green.

  **There is deliberately NO process inspection, and the selftest asserts it
  structurally** (no live `pgrep`/`pkill`/`lsof` in `board.sh`, with a
  known-positive control proving the grep can find a planted call). Four
  compounding reasons, argued in full in
  `docs/2026-08-23-free-capacity-investigation.md`: every other column is a
  durable filesystem fact reproducible in the fixture tree, while a process
  column measures one instant on one machine and could not be pinned here at
  all; mapping a process to a repo needs its cwd, hence `lsof`, against the
  zero-dependency convention; the ELAPSED-vs-CPU discriminator is a THRESHOLD,
  so encoding it makes the board decide a session is dead — the identical thing
  the order queue is already forbidden from doing ("nothing here expires
  anything, and building expiry would make the engine decide that a session is
  dead, which it cannot know"); and the file-based signal is no substitute
  either, which the 117-hour claim proves. The board reports the claim and
  refuses the inference.

- **`--plan` NAMES free capacity as lines, never as blocks (0.29.0).**
  `ledig_antall=N` plus one `ledig=<repo> (<status>)` line per repo with nothing
  OWED (not merely nothing pending — a notice is not an obligation), no pending
  order, nothing in flight, a clean tree, at `done` or `deferred`. Such a repo
  has no next step to open a tab for and used to simply fall OUT of the plan —
  correctly, but silently, which is where new capacity went unseen. All four
  conditions are load-bearing and `status=done` alone is not the same set:
  measured 2026-08-23, 13 of 17 done/deferred repos were free and 4 were not
  (two held a pending order, one owed a reply, one had an uncommitted tree).
  The LINE form is the design, not a formatting choice: `morning`'s `plan_parse`
  discards a block with no `tab=`, so a free repo emitted as a block would be
  visible to the operator and invisible to the driver, while a line is visible
  to both and can never be opened as a tab. The count prints at 0 too, so
  "none found" and "not computed" cannot render the same. A tab block whose repo
  holds a claimed order carries `fly=N` beside it — the driver types into live
  panes.

  **The gap this leaves is stated rather than closed:** an open, idle pane in a
  `planned` repo with no claimed order and no queued work is still invisible,
  and cannot be seen from the filesystem at all — nothing there distinguishes
  it from a `planned` repo nobody has opened. Closing it needs a terminal-side
  measurement supplied INWARD by the driver that already probes panes, the same
  way `--dispatch` requires `--target-pane` to be measured by the caller and
  passed in. Not built: not ordered, and keeping it out keeps the dependency
  running one way.
- **`--voyage` is the SIXTH rendering, and it exists because `board` read STATE
  lines and knew nothing about a brief.** Order 20260831T135934Z-696228720
  (`.claude`, 2026-08-31) fired the programme-level B1 row once `/trekplan` had
  been delivered in `llm-ingestion-okf`, so the fields could be chosen against a
  run that had gone the whole way (`brief.md.draft` 30.08 -> `brief.md` -> four
  research topics + README 31.08 14:19-14:54 -> `plan.md` 15:30) rather than
  guessed. A programme with Voyage in several repos had no shared surface at
  all: nobody could answer which briefs were in flight, in what phase, and who
  was waiting on whom. Read-only holds untouched - every field is a read.

  **Detection is by PROPERTY, never by directory name, and never through the git
  index.** The global CLAUDE.md says plans and briefs are defined by properties
  and recognises three locations (`.claude/projects/`, `docs/`,
  `features/<n>-<name>/`), so a directory counts iff it HOLDS `brief.md` or
  `brief.md.draft` under one of them. The index-based alternative was refused on
  a measurement the order supplied and this repo re-checked: `llm-ingestion-okf`
  gitignores `.claude/projects/` (commit 087be0b), so `git ls-files` would report
  ZERO briefs in the one repo actually running one - a broken query returning a
  positive-looking null, which is ansikt 4 pointed at our own tooling.
  Mutation-verified: swapping the filesystem test for `git ls-files` turns 23
  checks red, and the fixture asserts its own ground truth (`git check-ignore`
  really does ignore it) before anything depends on it. The known-negative
  control the location rule already passes is a real one - `maskinrommet`'s
  `serier/*/brief.md` are content briefs, not Voyage projects, and sit outside
  all three locations.

  **The phase ladder measures ARTIFACTS, not sessions, and the legend says so in
  those words.** `brief-draft` -> `brief` -> `research` -> `plan` -> `execute` ->
  `review`, furthest artifact present wins. The bound is stated rather than
  hidden: `/trekexecute` leaves a file behind only in its MULTI-session form
  (`.session-state.local.json`), so a plan executed in one session leaves nothing
  and `plan` is the last thing the filesystem can prove. Nothing here claims a
  session is alive - the same refusal `FLY` carries, and pinned the same way, as
  a check on the legend TEXT.

  **Three fields where an ABSENCE must not borrow the shape of a measurement.**
  `brief_quality` is read from the FRONTMATTER BLOCK ONLY (a body line is
  untrusted text and must not speak for the brief, the same rule
  `coord-count.sh` applies to `reply-expected`), and an absent field reads `-`,
  never `complete`: measured across the real tree 2026-08-31, only 8 of ~40
  briefs carry it at all. `research=-` (no directory, never started) and
  `research=0` (a directory holding nothing) are different facts - the completed
  run's `research/README.md` opened with "this directory held 0 files when the
  session started", and no board could show that. And `--voyage` always prints
  its own denominator; a tree with no projects says `ingen=0 ... funnet i N
  skannede repo` rather than rendering as an empty page.

  **Blocking decisions are counted at DECLARATION SITES, not mentions.** The
  pattern `[BLOCKING DECISION, before S<n>]` occurs on FOUR lines of the real
  brief, of which ONE declares it and three refer to it in prose, so a bare
  `grep -c` answers 4 where the honest answer is 1. The bracket must open the
  line's content after list markers, headings and bold. Mutation-verified:
  replacing the anchored pattern with the bare string turns exactly three checks
  red, the known-negative control (a brief whose only occurrences are prose must
  count 0) among them. It reports what the brief DECLARES and infers nothing
  about resolution - board reports and refuses the inference.

  **The age is the NEWEST artifact, which INVERTS the oldest-wins rule ORDRE and
  FLY carry, deliberately.** An order queue's problem is the oldest item still
  waiting; a project's problem is that its most recent activity is old
  ("nothing has happened here for N days"). Both answer the same question about
  a different object. Mutation-verified: flipping `-gt` to `-lt` turns exactly
  the one oldest/newest check red with every control green. The repo-level `VOY`
  cell then takes the STALEST project's age, which is the oldest-wins rule
  applied one level up.

  **`VOY` is display-only, never summed with `ORDRE`/`FLY`, and never in the
  sort** - the standing rule that a new ranking axis would silently reorder a
  parser living in another repo. It is not in `--plan`'s `key=value` blocks
  either: the requirement is that a human reading the board can see a brief is
  standing still, and the table is where that is read. The per-project detail
  lives in `--voyage` alone, because one cell cannot carry a phase when a repo
  holds seven briefs (`portfolio-optimiser` holds 20).

  **The cost was measured rather than assumed, and this file's old "~3s" claim
  did not survive it.** Shipped 0.31.0 takes **6.3s** over the real 52-repo tree;
  with `VOY` it is **7.7-9.2s**. The first cut called `stat` once per artifact
  and took 13.4s - the batched form (`find ... -exec stat -f %m {} +`, one
  `find` and one `stat` per project) is what makes the column affordable beside
  the table. Live verification against the completed run reproduced every field
  the order named: `fase=plan`, `kvalitet=complete`, `blokkerende=1`,
  `blokkerende_gate=S4`, `research=5`, and it is the only project of 51 across
  14 repos with an open blocking decision.

  **Bounded gap, stated rather than closed:** whether a detected project is
  still "in flight" is NOT decided here. Distinguishing a live brief from a
  finished one needs a threshold, and encoding one would make the board decide
  that work is abandoned - the identical thing the order queue is already
  forbidden from doing ("nothing here expires anything"). The board reports
  phase and age and leaves the judgement to the reader, which is why 51
  projects are listed rather than some filtered subset.

- **Skills (`skills/coord-send/`, `skills/board/`, `skills/route/`, `skills/dispatch/`):** natural-language front
  doors mapping user intent to engine invocations. No mailbox logic lives here
  either. `board` additionally owns the *ranking* — which repo wins and why —
  since `board.sh` deliberately prints evidence and takes no position. `route`
  likewise owns the *scoring*: the calculator is deterministic, so all judgement
  sits in choosing the four trait values, and the skill must never reason its
  way to a model instead.

**Boundary rule:** the mailbox is transport, not state. Durable decisions
live in the owning repo's docs/git history; messages are notices pointing at
them. Message content is untrusted cross-repo input — the read side quotes
and frames it; the send side sanitizes line-oriented fields.

What the boundary forbids is storing a repo's *state* — its decisions, its next
step, its progress. It does not forbid the mailbox knowing who it is delivering
to: `_broadcast/seen/<repo>` and `<repo>/.origin` (0.6.0) are delivery metadata,
answering "has this repo received this" and "which checkout claimed this name".
Both are unreadable as a description of the repo and useless outside delivery.
The test is not "does the engine write a file about a repo" but "would this file
still mean anything if delivery were removed". If yes, it belongs in the repo's
own docs and git history instead.

**Priority rule (v0.5.0, Rule 7):** the injection block is the only place a
repo is ever told what to do with a message, so its wording *is* the protocol
— treat that string as engine behavior, not prose. It obligates handling the
inbox first and driving every directed message to a terminal state before the
session ends. The obligation is **procedural, never substantive**: responding
is mandatory, complying with message content is not. Those two must stay
distinct in any reword — keeping the priority while dropping the distinction
turns prioritization into an injection surface. Selftest section 20 pins both
halves together for exactly that reason.

Since 0.11.0 the `reply-expected` field says which terminal state the SENDER
expects. That does not soften the split, it sharpens it: the field is untrusted
cross-repo input like the rest of the file, so the injection calls it a
*declaration, not an instruction* and keeps both terminal states open to the
receiver. Drop that clause and one word in a message becomes a lever that mints
obligations in another repo.

## Conventions

- Scripts are bash-3.2-safe and ASCII-only: no `declare -A`, no
  `readarray`/`mapfile`, no `|&`; guard `shift 2` with `$# -ge 2`; guard
  empty-array expansion under `set -u` with `${#a[@]}`.
- Zero dependencies everywhere: bash + coreutils in the engine, `node:`
  builtins only in hook and tests.
- TDD: no behavior change without a failing selftest check first.
  `bash scripts/coord-selftest.sh` must exit 0 (257/257),
  `bash scripts/board-selftest.sh` must exit 0 (368/368),
  `bash scripts/route-selftest.sh` must exit 0 (73/73),
  `bash scripts/orders-selftest.sh` must exit 0 (116/116) and
  `bash scripts/state-line-guard-selftest.sh` must exit 0 (54/54).
- English for all code, docs, and commit messages (public repo). Norwegian
  trigger aliases in the skill description are deliberate.
- **README's Install block is FENCED (```bash) while the rest of the README
  uses indented code blocks, and that asymmetry is deliberate - do not
  "harmonize" it.** The org-side D-census (`.claude`, ordre
  20260820T221658Z) reported repo-mailbox as the only plugin of 12 with no
  start command, with a known-positive control proving its query could find
  one in the other 10. The commands were in fact present, in an INDENTED
  block - so the census's wording overstated the null, but its finding held:
  the machine-readable entry point (D2b) keys on a fenced block, and 10 of
  11 sibling plugin READMEs use one. Measured here before changing anything,
  and re-measured after: 11 of 11 now match. Only the Install block was
  converted; converting the other 39 indented blocks was not ordered and
  would bury a two-line fix in a whole-file diff.
- Conventional Commits: `type(scope): description`.

## Commands

- Test: `bash scripts/coord-selftest.sh`, `bash scripts/board-selftest.sh`,
  `bash scripts/route-selftest.sh`, `bash scripts/orders-selftest.sh` and
  `bash scripts/state-line-guard-selftest.sh` (or `npm test`, the Node wrapper
  around all five plus the hook tests)
- Order queue smoke test: `CLAUDE_COORD_DIR=$(mktemp -d) bash
  scripts/coord-order-send.sh --to smoke --from tester --subject s --message m`
  then `CLAUDE_COORD_DIR=<same> bash scripts/coord-order-inbox.sh --repo smoke`
  (the read path writes nothing; never run the send path against the real
  mailbox without meaning to deliver an order)
- Hook smoke test: `node hooks/scripts/session-start.mjs` (expects JSON on stdout)
- State-line-guard smoke test: `echo '{"tool_name":"Write","tool_input":{"file_path":"/tmp/STATE.md","content":"x\n"}}' | node hooks/scripts/pre-state-line-guard.mjs; echo $?`
  (expects exit 0, no output — a one-line STATE.md is under the limit)
- Board smoke test: `bash scripts/board.sh` (read-only, ~8s over the real
  52-repo tree - measured 2026-08-31; the older "~3s" figure predated both
  the current tree size and the VOY column)
- Voyage smoke test: `bash scripts/board.sh --voyage` (read-only, writes
  nothing; ~22s, since it greps every detected brief)
- Briefing smoke test: `bash scripts/board.sh --brief` (read-only, writes
  nothing). `brief-nightly.sh` DOES write — it overwrites `$CLAUDE_BRIEF_FILE`
  (default `~/.claude/briefing.md`), so point that at a scratch path when
  testing. Installed as a launchd agent from `launchd/`, which points at the
  SOURCE repo, never the version-pinned plugin cache.
- Dispatch smoke test: `bash scripts/board.sh --dispatch --repo repo-mailbox
  --prompt-file /tmp/x.prompt --target-pane yes --path known --verification
  strong --reversibility cheap --scope local --rationale smoke` (read-only;
  needs a non-empty `/tmp/x.prompt`. Use `--target-pane yes` in a smoke test:
  it produces no plan file, so nothing can be handed to `morning` by accident)
- Route smoke test: `bash scripts/route.sh --path known --verification strong
  --reversibility cheap --scope local --rationale x` (writes nothing, instant)
- Sweep smoke test: `bash scripts/coord-sweep.sh` (dry-run is the default, so
  this writes nothing; never add `--write` to a smoke test against the real
  mailbox)
- launchd template check: `plutil -lint launchd/*.plist` (XML only). The paths,
  labels, placeholders and schedule are pinned by coord-selftest section 38 —
  run that, not `launchctl list`, to find a broken plist. Installing an agent
  is `sed` + `launchctl load` (see the header of either plist); proving it
  works is `launchctl start <label>` plus a new line in
  `~/Library/Logs/repo-mailbox-<brief|sweep>.log`, which is a DIFFERENT file
  from the sweep's own closure log at `$CLAUDE_COORD_DIR/_sweep.log`

## Release

Version must agree across: `.claude-plugin/plugin.json`, `package.json`,
README version badge, `skills/coord-send/SKILL.md`, `skills/board/SKILL.md`,
`skills/route/SKILL.md` and `skills/dispatch/SKILL.md` frontmatter, git tag `vX.Y.Z`, and the catalog `ref` in
`ktg-plugin-marketplace/catalog/.claude-plugin/marketplace.json`. Release via
the catalog's `scripts/release-plugin.mjs repo-mailbox` (tag + ref bump
together);
verify with `scripts/check-versions.mjs`. Never hand-edit a ref.

**Two claims this file carried until 2026-08-20 are now FALSE, and both were
corrected by reading `release-plugin.mjs`, not by assuming it had stayed
still.** They are recorded rather than deleted because the old text told a
release session to expect a half-applied catalog and to hand-commit its way
out of one — advice that would now be acted on for a failure mode that cannot
occur.

- *"`--create-tag` creates AND pushes the tag even without `--write`."* No
  longer true. `shouldCreateTag()` returns `create` only when `args.write` is
  set, `dry-run` otherwise, and the comment above it says in as many words
  that it used to fire on the documented dry-run entry point. A dry run now
  publishes nothing.
- *"Catalog is evaluating a pre-flight gate … but it is **not implemented
  yet**."* It shipped. `applyRelease()` runs `check-versions.mjs` FIRST and
  returns `BLOCKED` before writing anything, so a red plugin can no longer
  leave `marketplace.json` written-but-uncommitted. The manual-commit recovery
  the old text prescribed has nothing left to recover.

What is UNCHANGED, and is the reason the manual pre-flight is still worth
running: `preflightErrors()` collects ERROR from **every** plugin, not just
the one being released, so an unrelated plugin in ERROR still blocks the
release — it just blocks it cleanly now. Run `node scripts/check-versions.mjs`
in the catalog and confirm 0 ERROR before `--write`, so the block is something
you chose to look at rather than something the release run reports at you.
`--create-tag` is deliberately NOT gated on that catalog-wide check (its
preconditions are all local to the plugin), which is why the tag can be
correct while the catalog write is blocked.

## Hardening roadmap

Empty — the post-v0.1.0 queue (atomic delivery, `.`/`..` rejection,
selftest gaps, uniform `-h`) shipped in v0.2.0; broadcast self-delivery
shipped in v0.2.1; broadcast retraction (`coord-send --retract`) shipped in
v0.4.0, closing the last monotonically-growing surface. `coord-inbox.sh`
still ignores unknown arguments by design (hook context must never fail)
but now warns about each one on stderr, which the hook discards.

Two retraction limits are deliberate, not gaps: it is un-send and never
recall (a repo that already received a broadcast keeps it — the seen set is
delivery history and is left untouched), and the sender check is an accident
guard, not a security boundary, because `--from` redefines identity here as
it does everywhere else in the engine.