istosandClaude Opus 5
f428ee0468
"You" was the else-branch of session_label: anything the board could not attribute to an agent it attributed to the person. Every session read back from disk was one of those, because the agent id lived only in the session registry and never reached the persisted events — so past agent runs came back wearing the human's label, carrying their own closing reports underneath it. Identity is now a small whole file beside each event log (state/sessions/<id>.who.json): agent id, the agent's name, the model it rode, and the task. A file rather than a key on the events, because the logs are append-only JSONL whose first line every reader takes for an event — and because the name and the model are nowhere in the stream, so this is the only thing a restart can read them back from. It is rewritten only when what the board knows changes, which also covers an agent id that arrives on a later event. load_disk_sessions() reads it back, and the label now has three registers instead of two: the agent's name (persisted, so a restart no longer costs it), "You" only for a session positively recorded as carrying no agent, and a neutral "Session · <id>" for a log written before any of this was recorded. Old logs are not retro-attributed in either direction. agentFor() in board.html falls back to the persisted identity when this board no longer holds the live record, so a replayed agent session wears its model chip from what was written rather than from what happens to be in memory. What depends on liveness (Hold, the worktree branch) finds nothing there and stays silent, as before. tests/test_session_identity.py drives the real ingest → persist → reload path and the page's own chip functions in node. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bench
A live kanban for coding-agent work: task files in stage directories are
the only source of truth; a stdlib-only board narrates everything that
happens to them — agents working in git worktrees, PRs opening on review,
CI and Copilot state on the cards, drives of the app from a task's own
branch, and an archive that is never a delete. Turn on team mode
(BOARD_SYNC=1) and the truth is origin/main: moves commit and push
themselves, every board pulls on a beat, and the person who claimed a
card first keeps it.
Install into a repo
mkdir .task-manager && curl -L \
https://github.com/12vectors/bench/releases/latest/download/bench.tar.gz \
| tar -xz -C .task-manager
./.task-manager/start.sh # wires the project (idempotent) and serves
No token, no clone: releases are curated artifacts that never contained bench's own cards or settings, so the board starts empty by construction.
The first run asks three questions it cannot answer for you — solo or
team, which agent adapter, what command runs your tests — and writes
manager/local/.env from the documented example, so every other setting
is discoverable in your own copy. Bare Enter takes the default
throughout; with no terminal (CI, a script) it asks nothing and
install.py --setup asks later.
Commit .task-manager/ into the host repo — core is vendored on purpose,
so clones work offline and updates show up in the host's own diffs.
The workflow brief ships as .task-manager/AGENTS.md — the cross-vendor
name coding agents read natively — with CLAUDE.md beside it as a one-line
compatibility pointer. Both live inside .task-manager/, so a host repo's
own root AGENTS.md is never touched.
Update
./.task-manager/update.sh # latest release
BENCH_REF=v2 ./.task-manager/update.sh # an exact release tag
The artifact is stamped with the repo it was built from, so updating
needs no configuration; BENCH_SOURCE=<owner/repo> in
manager/local/.env overrides the stamp. Updates replace
manager/core/ and the top-level scripts wholesale and touch nothing
else — tasks, plans, reference, and everything under manager/local/
(your driver, commands, prompt overrides, settings, state) survive every
update. Then python3 .task-manager/install.py and restart the board.
If the source repo has no published release yet, update.sh says so and
changes nothing.
Working on bench itself
git clone git@github.com:12vectors/bench.git && cd bench && ./start.sh
A clone carries bench's own cards and local/ content — that is dev mode,
not an install. (Installing from a clone anyway works: install.py
clears the shipped cards on its first boot in a host repo.) Releases are
built by ./release.sh from the manifest at
manager/core/release-manifest: tag = v<VERSION>, one stable asset
name (bench.tar.gz), contents at the tarball root — the two things the
install one-liner above depends on.
The three-layer law
Core knows about tasks, worktrees, PRs and events. It knows nothing about
any particular app (drivers do: manager/local/driver/start), agent
vendor (adapters do: manager/core/adapters/), or project
(manager/local/ does).
The consequence is what makes an update safe: update.sh replaces
manager/core/ wholesale, and everything a project taught bench about
itself lives outside it. Full docs in AGENTS.md; the adapter
contract in
manager/core/adapters/README.md.
License
MIT.