fix(board): one spec for next-cost, and it is the rubric's

The board line's cost field had two specifications and one of them was this
script. `--help` prescribed a versionless `sonnet/xhigh`; the global model
rubric it points at spells the model `Sonnet 5 / xhigh`. A session following
either was correct by its own source, so the field drifted with nobody making
a mistake. Measured across a real 44-repo tree: 14 board lines carrying eight
distinct strings, and not one of them the form documented here - the only
spelling nobody used was ours.

The help now prescribes the rubric's, which is also what most lines already
carry. The parser is untouched and stays lenient: it reads to `;` or `-->` so
the rubric's spacing survives, and the fixtures still vary the spelling on
purpose to pin that. Read-side leniency was never the defect; it is what makes
a documentation-only fix sufficient.

No normalization at read, deliberately. Board lines are rewritten every session
by convention, so an unambiguous spec self-heals the existing lines in about one
session per active repo - mapping variants would be permanent code migrating
data that migrates itself. Nothing compares the field mechanically today either:
KOST is a display column and the board sorts on a numeric bucket key, so the
defect was real but latent. Two checks (28 -> 30) pin the documented form,
red first, because cleaning the data cannot fix a spec that regenerates the
divergence every session. Validation at write has no write path to attach to:
nothing in this repo emits a board line outside the fixtures.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U6EixQo6hpoRCVtiAXdnFs

scripts/board-selftest.sh

@@ -213,6 +213,23 @@ mkrepo "$ROOT/repo-f"
 # Unreadable root is a no-op, not a crash.
 "$BOARD" --roots "$ROOT/does-not-exist" >/dev/null 2>&1; check "missing root is a clean no-op" $?
 
+# --- 8. The documented next-cost form IS the convention --------------------
+# The cost field is free text on purpose: the parser reads to ';' or '-->' so
+# the rubric's spacing survives, and the fixtures above deliberately vary the
+# spelling to pin that leniency. But leniency on the read side means the ONLY
+# thing holding the field uniform is what --help prescribes, and --help once
+# prescribed a versionless `sonnet/xhigh` while the global rubric spelled
+# `Sonnet 5 / xhigh`. Two specs for one field: measured across the real tree,
+# not one board line used ours, and eight distinct strings were in circulation.
+# Pinned here because cleaning the DATA cannot fix that - a spec that
+# contradicts the rubric regenerates the divergence every session.
+HELP="$("$BOARD" --help 2>/dev/null)"
+printf '%s' "$HELP" | grep -q 'next-cost=Sonnet 5/xhigh'
+check "--help prescribes the canonical next-cost form" $?
+# The versionless form is what the rubric does NOT use; no example may show it.
+if printf '%s' "$HELP" | grep -qE '(sonnet|opus|fable)/(high|xhigh)'; then rc=1; else rc=0; fi
+check "--help shows no versionless model example" "$rc"
+
 echo ""
 echo "board-selftest: $PASS passed, $FAIL failed"
 [ "$FAIL" -eq 0 ] || exit 1

scripts/board.sh

@@ -18,11 +18,15 @@
 #
 # Board line (optional, one per STATE.md, directly under the NESTE heading):
 #
-#   <!-- board: status=in-progress; blocked-on=-; next-cost=sonnet/xhigh -->
+#   <!-- board: status=in-progress; blocked-on=-; next-cost=Sonnet 5/xhigh -->
 #
 #   status     planned | in-progress | blocked | deferred | done
 #   blocked-on <repo-name> or - (only meaningful with status=blocked)
-#   next-cost  <model>/<effort> from the global model rubric, e.g. opus/xhigh
+#   next-cost  <model>/<effort>, the model spelled EXACTLY as the global rubric
+#              spells it: Sonnet 5/xhigh, Opus 5/high. The parser below accepts
+#              any spelling, but this field is compared across repos by eye, so
+#              one form is the whole point - and a second spelling documented
+#              here is how a field with no write path drifts.
 #
 # ATTENTION AXIS, NOT A TOPIC AXIS. This status vocabulary is deliberately NOT
 # the vocabulary a cross-repo TOPIC register uses. A topic register answers