The generated site's whole value is that drift is loud, so the tests
are mostly about drift: a heading renamed in AGENTS.md must fail the
build naming the route and the heading, a slice emptied to its heading
must fail rather than emit a page, and a heading inside a code fence
must never match — AGENTS.md fences a task template whose first line is
'# Task title', and matching that would slice the document in half.
Alongside: link rewriting (GitHub blob, link_routes overrides, dead and
escaping links refused), manifest validation, the output-directory
guard, and the acceptance criterion that no built page fetches anything
third-party — mechanised as 'every rel that opens a connection is
same-origin', with rel=canonical excluded because it is a statement,
not a fetch.
The release artifact test now asserts site/ is absent from bench.tar.gz.
The manifest already excludes it by saying nothing about it, but
correct-by-omission is exactly what a future manifest edit undoes
silently.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
bench has no public page. site/ is the machinery for one: a manifest,
a generator, two layouts from the turn-2 docs design, and the Daylight
half of the board's own token set.
Nothing here is transcribed. Every page body is a heading slice of a
file that already documents bench, and site/pages.json is the only
place that mapping is written down — the IA is editorial judgement, so
it lives in one readable file rather than in a directory convention.
The point is the failure: a from/to heading the source no longer
contains stops the build naming the route, the file and the heading,
and every page renders before the output directory is touched, so a
drifting rebuild leaves the last good build standing instead of
replacing it with an empty one. Repo-relative links come out as site
routes or GitHub links; a dead one stops the build too.
Rendering is markdown-it-py, pinned in site/requirements.txt. The
stdlib-only law binds manager/core/ — the tool people install — and
site/ is neither shipped nor installed, so a hand-rolled parser would
have been risk spent in the wrong place on a document that leans on
fenced code, nested lists and inline code throughout.
Templates are string.Template: $name substitutes and a literal dollar
doubles, because str.format's braces collide with every line of CSS.
Fonts are self-hosted and same-origin: no page bench serves may need a
request to a third party to be read. fetch-fonts.py downloads the seven
woff2 files once; until they are there the build says which are missing
and the pages fall back to the system stack.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Turn 1 of the docs design wrapped three good layouts around invented
content — a bench.toml, a brew-installed CLI, "lanes", a handoff rule
engine, port 7331, PAS-411 cards. None of it exists. Turn 2 holds all
three layouts and replaces every word, label and code block with the
product AGENTS.md, README.md and manager/core/.env.example describe.
1b Dockside — hero terminal is the real install one-liner, the real
first-run questions and the real board.py startup lines on 26071.
The six doors are install, the five stages, agents on the board,
PRs & review, team mode, the three-layer law.
1a Harbour — the article is "Claiming a card": what each move writes
to **Assignee:**, the two local/.env keys that turn it on, and the
board: <n> → <stage> (<name>) commit it makes.
1c Logbook — the CLI reference is now a settings reference, with
BOARD_SYNC as the shown key and the board's own activity log (real
event strings from sync.py, agents.py and github.py) in the pinned
console.
The design project's write path needs an interactive permission grant,
which a headless run cannot answer, so the finished file lands here as
reference/bench-docs-design-turn2.dc.html for a human to upload as
"Bench Docs.dc.html". The card scoped itself to the design project with
no repo files changed; this one file is the deviation, and a git rm
undoes it once the upload has happened.
A project could run bench for months without a manager/local/.env:
everything fell back to core/.env.example, so the two settings that
change what bench is — claim-on-move and syncing through origin/main —
were invisible to anyone who had not read that file.
install.py now writes it on a first run. It asks three questions no
default can be right about (solo or team, which agent adapter, the
project's test command) and writes core/.env.example with the answers
substituted into their lines, comments and all keys intact — so the
written file is where the project reads what else it can change.
- Runs after first_boot_clean: .env is one of the two things the
first-boot guard reads, so writing it earlier would skip the clean.
- Never asks without a terminal on stdin. install.py sits on the path
of start.sh, update.sh and every hook, so no TTY prints one line and
carries on rather than blocking a board start on an invisible prompt.
--dry-run reports the questions and writes nothing.
- An existing .env is never touched; --setup is the only way back to
the questions, pre-filling from the current file and rewriting it in
place, so start.sh's fallback BOARD_PORT line survives.
- Bare Enter takes every default (the result is the example verbatim,
i.e. today's behaviour exactly); Ctrl-D skips the rest.
start.sh needed no change — it already calls install.py before the port
dance, which is the right order. Tests drive the interactive runs over a
real pty and the non-interactive ones with /dev/null on stdin.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The MultiEdit deny rule was already dropped in the hotfix; this is task
10's follow-up half — the guard that catches the next fossil.
The claude adapter's review branch spells "cannot edit files" in the
vendor's own tool names, and that roster moves: a rule naming a tool the
installed CLI does not have is refused at startup, so the launch dies
before the agent speaks. Membership assertions could not see that
happening, so the stub-binary test now asserts each mode's flag list
literally (settings payload elided) — a deny name added or renamed shows
up as a diff a reviewer must re-verify against the installed CLI. The
run script carries the same warning where the list actually lives.
The helper drops a leaked AGENT_MODEL, since --model would otherwise
appear in an argv now compared whole; test_agent_model.py owns that flag.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Both from the first downstream 0.2 update report: the vendored diff
left as homework in a clean-main workflow, and the TIME_WAIT port hop
that rewrote an explicit BOARD_PORT pin.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
An agent that exits non-zero was the least-handled outcome on the board:
one ticker line that scrolled away, a card that looked exactly as it did
before the launch, and the log's contents — usually the whole story — left
on disk. Three launches died in an API outage and the board said nothing a
person would notice.
So the outcome is recorded on the run: exit code, ended-at, and the
cleaned tail of its log as the excerpt (a launch that died before the
agent spoke says so rather than showing blank). From that the card takes
the alarm border and a `run failed` pill, with the excerpt on hover and in
full in the card sheet; a toast fires, because failures are rare and
actionable; and the ticker line stays, now naming what the log ended on.
Every headless kind lands in _finish, so work, act-pr, PR review and the
relevance check are all covered. The state is scoped to the run and the
stage: the next launch supersedes it, and the watcher drops it when the
card moves, so nothing follows a card into review/.
The way is cleared for the relaunch too: a failed run with no commits has
its worktree and empty branch removed — the reasoning a decline already
uses — so ▸ start work works without a hand `git worktree remove`. A
failed run with commits keeps its worktree.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Task 12 recorded which model each launch rode, but it surfaced only at
the tail of the session-detail metadata line, where nobody's eye lands.
With work and review models diverging per intent, "which brain did this"
is a routine review question, so the answer now sits beside the name that
did it.
One component, modelChip(), rendered wherever a name identifies a run:
the sessions list row, the session-detail header, the Focus header and
the working card's agent line. It borrows the session-id hash's register
— small, mono, dim — and takes no colour, because a model is not a state.
The vendor prefix a name repeats is dropped for the chip (claude-opus-4-8
→ opus-4-8, anthropic/x → x) with the whole string on hover; an
unfamiliar name is shown as recorded rather than guessed at.
A launch that never knew its model wears no chip at all — an inherited
default, or a session replayed from disk after a restart. The two
metadata lines that used to carry the model keep only what the chip
cannot say: "model inherited", and only when it genuinely is.
Tests lift the two functions out of the page and run them in node (skipped
where node is absent) for the shortening, escaping and silence; placement
and register stay source-level invariants, as board.html has no frontend
test runner.
install.py shipped mode 644 in v0.1-alpha, so the README one-liner's
./install.py was permission-denied on every install. The repo modes and
update.sh's repair line were hotfixed already (all 14 shebang'd tracked
files are 100755; update.sh:165 names install.py) — this is the guard
that keeps them that way, and the patch release that heals the field.
- tests/test_release_artifact.py: the invariant, read from the tar
header rather than the repo — every member whose content starts `#!`
must carry the exec bit, failing by name. No exception list: there is
no shipped file that legitimately may not be run, and gaining one
means editing the test with a reason. Two tests keep it honest: the
guard is proven to bite by repacking the real artifact with
install.py's mode stripped, and an unpacked release must run
./install.py as a program, not via python3.
- tests/test_update_from_release.py: an install whose install.py is
mode 644 — the shape v0.1-alpha left in the field — is executable
again after any update. `cp` onto an existing file keeps the
destination's mode, so the chmod line is the only thing healing it;
removing that line fails this test.
- manager/core/VERSION → 0.1-alpha.1: cutting the patch is the honest
move over a release note telling users to work around it.
- manager/core/release-manifest: the invariant, stated where the
shipping list lives.
Verified: python3 -m unittest discover -s tests (267 tests, OK). Both
new assertions were watched failing first — a build-side `chmod -x` on
the staged install.py, and update.sh with install.py dropped from its
chmod list — then restored.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
