feat(route,board): strike the advisor rule, add board.sh --row <repo>

Order 20260912T202210Z-7588027378-from-.claude, operator decision
2026-09-12 (helhetlig vurdering av arbeidssystemet, cut row 3 and the
board.sh --row improvement row). One order, two parts, one version bump.

THE ADVISOR RULE IS STRUCK. route.sh and board.sh --dispatch emit no
--advisor at all. The rule fired per ROW on a need - always on the Sonnet
rows (a capability lift, which is what made the quota fallback safe to
take), and on the Opus rows at reversibility=costly|one-way - and it read
well. It was killed by a MEASUREMENT, not by taste: of 54 dispatches the
PM issued 08.-12.09, ZERO carried the flag, because sessions are started
by hand from the model and effort rather than from the whole emitted
line. A rule nothing honours is not a policy, and an emitted value nobody
acts on is decoration in a field whose only job is to be evidence. The
advisor is now what it already was in practice: an operator decision per
session, said in one sentence in route.sh --help.

The comments that rested on the rule were REWRITTEN, not left standing.
board.sh --dispatch still refuses a --model/--effort pair, but the reason
is no longer "the advisor is a property of the ROW": it is that the rubric
has exactly one copy, and a dispatch taking the model directly would be a
second, unscored way to reach the same decision - recording no traits, no
rationale and no next-cost, so nothing afterwards could say whether the
routing or the scoring was wrong. A comment defending a removed mechanism
is how the next session restores it. Both skills carry the correction.

Pinned as an ABSENCE over the whole trait space - 81 combinations, every
line of output, with a known-positive control proving the sweep's grep
can find a planted advisor - rather than on four sampled rows, because
the claim is that no path emits it. board.sh --dispatch at
reversibility=costly is pinned separately: that is the exact input a
reintroduced rule would fire on. The literal string is absent from
route.sh entirely, including the paragraph recording what was struck (it
says "an opus advisor flag" in words), because a blunt grep cannot tell a
description from a specification. Backward compatibility is pinned rather
than assumed: a route line carrying a legacy advisor= field still parses
and still yields a command - measured, 0 of 48 route lines in ~/repos
carry one, but a reader that broke on an unknown field would turn last
month's STATE.md into "that repo has no route line". The three CLI gates
section 14 carried went with the rule; the suite no longer depends on the
installed claude at all.

board.sh --row <repo> IS THE SEVENTH RENDERING of the same scan, never a
second scan, read-only like every other one. (The order calls it the
sixth; by this file's own numbering --inbox-plan is the fourth and
--dispatch the fifth. Corrected rather than carried wrong.) It exists
because the columns WERE misread: on 11.09 the PM read FLY off the table
by eye and got it wrong, while every other rendering a program consumes
is already key=value. inn, ordre and fly are three separate fields
because they are three separate facts; status is the bare token, never
the table's blocked>target display, with blocked-on beside it; neste is
last and uncut. An unknown repo exits 2 and writes NOTHING to stdout - an
empty block would read as a repo whose every column is blank, which is a
real and different state.

upushet is the ONE field that is not a rendering of the scan, and it is
named rather than blended in: nothing in the scan measures it, so it is
read once, for the named repo only, and never enters the table, the plan
or the briefing. It reads the remote-TRACKING ref, not the remote, so
upushet=N honestly means "the local ref says N"; a repo with no upstream
reports ?, never 0.

The row fixture's three counts are three DIFFERENT integers (3/2/1), and
that is the finding worth recording. Built first with 2/1/1, it was
mutation-tested by making fly read the ORDRE field - the exact 11.09
misreading - and the check stayed GREEN, because the two fields held the
same digit. A fixture that cannot tell two columns apart is the defect
wearing a passing test, inside the section written to prevent it.

Suites under /bin/bash 3.2, before -> after: coord 257 -> 257, board
393 -> 427, route 73 -> 73 (13 advisor checks and 3 CLI gates out, 15
absence/legacy checks in, and it no longer varies with claude being on
PATH), orders 116 -> 116, state-line-guard 54 -> 54. Sum 893 -> 927,
README badge updated to the measured sum. npm test 12/12, fail 0.

Verified live against the real tree, not only fixtures: --row
repo-mailbox reports fly=1 beside ordre=0 (the distinction that was
misread), --row on the nested key from-ai-to-chitta/content-sadhguru
resolves, and an unknown repo exits 2.

No tag, no push, no catalog change - that is the operator's
release-plugin.mjs run.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

skills/board/SKILL.md

@@ -23,7 +23,7 @@ description: >-
   user names no repo and no tool — choosing *between* repos is this skill. Not for
   "where were we" inside the current repo: that is this repo's own STATE.md,
   already injected at session start.
-version: "0.33.1"
+version: "0.34.0"
 ---
 
 # board — which repo deserves the next session

skills/coord-send/SKILL.md

@@ -15,7 +15,7 @@ description: >-
   covers retiring a broadcast that has become wrong or obsolete: "retract that
   broadcast", "that announcement is outdated, pull it", "trekk tilbake kringkastingen",
   "den broadcasten er utdatert".
-version: "0.33.1"
+version: "0.34.0"
 ---
 
 # coord-send — natural-language front door for inter-repo messages

skills/dispatch/SKILL.md

@@ -17,7 +17,7 @@ description: >-
   skill. Not for choosing WHICH repo deserves the next session (that is `board`),
   not for scoring model and effort alone (that is `route`), and not for sending a
   message to another repo (that is `coord-send`).
-version: "0.33.1"
+version: "0.34.0"
 ---
 
 # dispatch — hand a session a task it can actually start on
@@ -124,8 +124,8 @@ Two facts about this measurement, both verified 2026-08-16 against the installed
 
 ### 4. Score the four traits and call `--dispatch`
 
-Scoring is judgement and it is yours; the model, effort and advisor flag are a
-lookup and are `route.sh`'s. Score the task **the dispatched session** will do,
+Scoring is judgement and it is yours; the model and effort are a lookup and are
+`route.sh`'s. Score the task **the dispatched session** will do,
 using the `route` skill's trait table.
 
 Pass `--order-id <id>`, not `--prompt-file`. The emitted command is then a thin
@@ -140,13 +140,18 @@ empty prompt file, one level up.
 queue to write to. Passing both is refused: the session would be told two
 things.
 
-`--dispatch` deliberately takes no `--model`/`--effort`. `--advisor opus` is a
-property of the rubric *row* — two rows share a model/effort pair while
-differing on it, and the CLI accepts a wrong advisor silently — so a dispatch
-that took the model directly would have no honest source for that flag. If the
-right call is a Fable row, the rubric cannot produce it: write that command by
-hand, and say in the handover that it is a recorded override, running without an
-advisor.
+`--dispatch` deliberately takes no `--model`/`--effort`. The rubric is a policy
+with exactly one copy, and a dispatch that took the model directly would be a
+second, unscored way to reach the same decision — one that records no traits, no
+rationale and no `next-cost`, so nothing afterwards could say whether the
+routing or the scoring was wrong. Score the traits and let the lookup spell the
+command. If the right call is a Fable row, the rubric cannot produce it: write
+that command by hand and say in the handover that it is a recorded override.
+
+**No `--advisor` is emitted, by the rubric or by this skill.** That rule was
+struck 2026-09-12 on a measurement — 0 of 54 dispatches carried the flag. The
+advisor is an operator decision per session; do not add one to a dispatch
+command.
 
 ### 5. Verify, then hand it over
 

skills/route/SKILL.md

@@ -14,7 +14,7 @@ description: >-
   the operator names no model and no tool — choosing the model for the next
   session IS this skill. Not for choosing which REPO gets the next session:
   that is the `board` skill.
-version: "0.33.1"
+version: "0.34.0"
 ---
 
 # route — what the next session should run with
@@ -104,8 +104,7 @@ in STATE as an **override**, never as something this skill produces. If Fable
 is the right call for the next step's *form* (big-picture, review, planning),
 write the board line and the `rule` by hand — `board.sh` still parses
 "Fable 5/high" and "Fable 5/xhigh" — and say so plainly in the rationale rather
-than scoring the four traits to land there. One fact worth carrying into that
-override: a Fable session runs without an advisor.
+than scoring the four traits to land there.
 
 ## The last-session record
 
@@ -186,24 +185,26 @@ Give the operator the two closing-line items and nothing more:
   the working directory is already right. If the next step belongs in a
   different repo, say so in plain words — that is a different tab, not a `cd`.
 
-**Paste `command` verbatim, `--advisor opus` included.** The calculator decides
-the advisor per row, and it is not decoration: on a Sonnet row it is what lifts
-the session to Opus judgement at Sonnet cost, which is what makes the cheaper
-`fallback-command` safe to take under quota pressure. Dropping it because it
-looks like noise silently removes that. Equally, never *add* it to a command
-that came back without one — an unconditional advisor is the global
-`advisorModel` setting, which costs quota in every session in every repo and is
-the failure mode this rule replaces. `route.sh --help` carries the full rule.
+**Paste `command` verbatim.** It is the row's whole spelling: model and effort,
+and nothing else. Do not add flags the calculator did not emit.
+
+**The advisor is not this skill's to decide.** Until 2026-09-12 the rubric
+appended an opus advisor on some rows; that rule is struck, on a measurement —
+of 54 dispatches issued 08.–12.09 not one carried it, because sessions are
+started by hand from the model and effort. The advisor is now an operator
+decision per session. Never add `--advisor` to an emitted command on your own
+initiative; if the operator asks for one, that is their call and it belongs in
+the handover as what it is — an operator choice, not a rubric outcome.
 
 If `command` and `fallback-command` are the same as the current session's model,
 say `/clear` is enough instead — but only if no newly installed plugin or skill
 needs a fresh process to be picked up.
 
-**`--advisor` is part of that comparison, not an afterthought.** It is a launch
-flag, so `/clear` reuses the process and keeps whatever advisor the session
-started with. If `command` carries `--advisor opus` and this session was not
-launched with it, `/clear` is *not* enough — the operator needs `/exit` and the
-full command, or the advisor silently never appears.
+**An advisor the operator asked for is part of that comparison.** It is a
+launch flag, so `/clear` reuses the process and keeps whatever advisor the
+session started with — a session that is to gain or lose one needs `/exit` and
+a full command, never `/clear`. The rubric never puts it there; the operator
+does.
 
 Do not paste the whole output block. One row, the rule that produced it, the
 command.