crew

Bolt teams of Claude agents, run in herdr, and each partition's main level above them.

The teams and partitions are data in ~/.config/crew/teams.json (version 2), written by the machine's configuration (in swancloud, lib/crew-teams.nix); each partition carries its batch setting, review: {every, hours}, and crew refuses one without it. Hosts, sessions, each session's partition and the repos of its space come from ~/.config/swancloud/herdr-hosts.json.
plugin/ is the same for every team: the roles (roles/, each an agent definition naming its model and effort), the crew and crew-role commands (bin/), the builder that turns the teams file into briefs and settings (lib/crew.py), the plan (lib/plan.py, with lib/gather.py, which reads a host's kits, and lib/transcript.py, which checks a signal's excerpt against its agent's transcript), crew sites (lib/sites.py), and the skills. It installs as a Claude Code plugin; this repository is its marketplace.

Teams

crew list
crew status   [team]
crew up|down|rebuild|close <team>
crew restart|resume <team> [conductor|ops]
crew clear    <team> conductor|ops
crew unit run <unit> construct|code|verify|settle|merge ["<words>"]
crew unit free <unit> [--team <team>]
crew chore run <chore> code|verify|merge ["<words>"]
crew chore free <chore> [--team <team>]
crew fix      <team> <name> "<what is wrong>" [--bolt <bolt>]
crew fix      <team> <name> --merge [--bolt <bolt>]
crew fix      <team> <name> --drop [--force] [--bolt <bolt>]
crew fix      <team> <name> --wait [--timeout <ms>] [--stuck <ms>] [--bolt <bolt>]
crew needs    "<what you tried and what you need>"

A team builds one bolt at a time: a body of work on the branch bolt/<bolt> on GitHub, which crew bolt give has sluice make from the kit's main, with no worktree, which moves only through sluice and then lands on main. Once a bolt is proven, every unit and chore merged and its verification green, it waits to land on the user's yes, and the team may hold one more beside it: crew bolt give gives it its next bolt then, and refuses while a bolt it holds is not proven or it holds two. The team builds the one given last, and the bolt that waits to land keeps of it only its reading, as a row of its kit's landings card, its ops and a fix's slot when its landing or a forecast conflicts with main; a give beside it restarts the conductor and ops at their next stop, the conductor told both bolts, and a merge that leaves the team free with a bolt planned for it tells the partition's dispatchers. Its standing roles are the conductor and ops. A bolt is built from units, each one OpenSpec change on unit/<unit> in <kit>/places/<unit>, taken stage by stage: construct writes the change, code builds it as soon as it is committed, with no review between, verify checks it once, code run once more fixes what its report marks fix, and merge archives its change, then submits it to the bolt with wt submit bolt/<bolt> --no-remove: sluice tests the bolt with it merged on the checks the kit's policy requires of its bolt branches, [branches."bolt/*"] in the .config/sluice.toml on its main, read from origin/main, and lands it as a merge commit only when they pass. crew bolt give has sluice make the bolt's branch on GitHub, sluice branch create bolt/<bolt> --from main in the kit's main checkout on the team's host, before it writes the plan, and makes nothing else; it refuses, with the plan unchanged and no branch made, a kit whose policy at origin/main names no such checks or no remote for its bolt branches, naming the file and the key, a host whose sluice is older than 0.20.0, which has no branch create, or whose version it can't read, naming the version it needs and what the host's said, and a create sluice refuses, in sluice's words, but for a branch already on GitHub at main's tip with no commit of its own, as a give that failed after sluice made it leaves it, which the give takes and goes on with, saying so; a branch with commits of its own is refused by name. A plan write refused after the create, or after the give took the branch, has sluice delete the branch again. Every unit's, chore's and fix's place is cut from origin/bolt/<bolt> after a fetch and tracks it, so it holds every merge sluice landed there from any host. crew reads a bolt on GitHub where it lives, at origin/bolt/<bolt>, when the policy there names a remote for it: its head, its verification, the changes and chores it holds and every stage read from it, never the host's own bolt/<bolt>, which is sluice's copy and may lag GitHub's. crew bolts, a give's check that the team's bolts are proven, each look a wait takes at a merge, and a give's making of the branch fetch the kit's origin first, a fetch that fails named in git's words and nothing read from the host's copy in its place; every other read, crew status, the rail and the board among them, takes the bolt as the host last fetched it. A bolt whose branch crew made on its host before gives went through sluice stays local until it lands: no create is run for it, its places are cut from the local branch, and each read of its team says so once. Each stage is a fresh agent at that stage's effort, in one of the team's units slots; a team taken down with crew down starts no stage until it is brought up. crew sends the agent the stage's prompt only once it is ready for input, and the stage begins only once the agent's own transcript shows Claude received it; a prompt it does not show within a short time is cleared from the agent's input with one Ctrl+C and sent once more. When the second is not taken either, or the agent was never ready, nothing is left typed in its pane: the stage never started, its start is recorded refused with no end owed, its slot and idle agent stay, and crew unit run or crew fix fails saying so and how to run it again. crew sends nothing more, and presses nothing, while the agent is working, or when it cannot read whether the prompt was taken, and says what it could not read. Construct can be run again with the user's words at any stage before the unit merges: run on a unit that is planned, in code or in verify, it marks the unit amended in the plan, code, verify and merge are refused until the change written again is committed, and the write that records that construct's end clears the mark; the unit then goes on from its tasks, with nothing to approve, and its revised change is in the partition's next batch. A merged unit is not amended: a defect in it is a fix, and a new need a new unit.

Every worktree crew makes for work, the place of a unit, a chore or a fix, is made ready by its kit's own toolchain, as the kit declares it in sluice's words: the [tests] table of .config/sluice.toml in the worktree, with toolchain, a command whose output is shell code that sets the kit's tools up (["devenv", "print-dev-env"]), and runner, "moon" or "command" (with command). crew runs the toolchain in the worktree on the team's host, with only PATH, HOME, USER, LOGNAME, SHELL, TMPDIR, LANG, TERM, PROTO_HOME, MOON_HOME and LC_* of the host's environment and stdin closed, keeps what it prints in the worktree's git directory, and then, for the moon runner, runs moon --version, refusing only a moon whose version it cannot read, since crew enforces no moon floor (sluice's moon runner refuses a moon below 2.6 at its own run, so a kit on sluice runs 2.6 or later), and moon setup, each with that output sourced by the bash on the PATH. It does this before any agent starts there, and again when it finds the worktree already made, so a command run again after a step failed sets it up; a step that fails refuses a unit's or a chore's stage in the tool's words, the worktree made, while a fix's agent starts all the same, told the step that failed, since a fix is how a bolt whose toolchain is broken is repaired. A kit that declares nothing has nothing run: crew assumes neither moon nor devenv, and runs no script a kit names for crew. crew reads only those keys of the file, through plugin/lib/kit.py; sluice reads the same table to run a kit's checks, and the file becomes flywheel.toml once flywheel uses sluice's SDK.

A bolt's units are built side by side, as slots allow, their changes written in waves: every unit with no After is constructed at once, and a unit that comes after others as soon as their changes are committed, never waiting on their merge. A dependent's new place takes the head of each of its unmerged After units as it stands; when one of them merges, crew rebases the dependent's place onto the bolt at the team's next read or the conductor's next wait, only while its agent is not working and its place is clean, the bolt's commits dropping out, and the merged unit's work as the place took it with them, since the bolt holds that work as it merged; a rebase that conflicts is undone and reaches the dependent as a forecast does, with the command that rebases it from the same upstream. A dependent merges only after each unit it comes after has merged. Construct ends the proposal with ## Touches and a fenced block of paths or globs; code is refused without it, a unit whose Touches overlap those of an unmerged unit ahead of it in the bolt's merge order starts code with the overlap and that unit's change in its prompt, and verify's prompt names each path the unit changed against its bolt and did not declare. Overlap holds nothing. On every crew unit wait, crew dry-runs with git merge-tree, writing no ref, the merge of each unmerged unit with the bolt and with each unmerged unit ahead of it in the bolt's merge order, After first and the plan's order only between units neither comes after, so a unit's dependents are never ahead of it, a dependent's with a unit it comes after from the head of that unit its place took, so the unit's own work, rewritten since by its rebase or settle, is no conflict of the dependent's; a forecast conflict reaches only the later unit, once for a pair of heads (forecast in the run record): told to its stage's agent once that is not working, carried in its next stage's prompt when none of it runs (a forecast against the bolt only until a newer one against the bolt is made for the unit), or as a settle stage, a fresh coder in its slot, when it has delivered its verify and waits to merge; a settle ends at a commit on its branch, or its agent saying nothing needs to change, and the unit then merges with no verify again. A forecast between two unmerged units orders neither by itself: when the later unit's settle delivers a commit that takes the earlier's work, crew puts the later after the earlier, once for the pair and in the conductor's name, and the settle's wait says so; an order of crew's whose settle then stopped short with nothing to change, the later's branch not holding the earlier's work, crew lifts itself at that wait or any wait after, and an order anyone else lifted is never written again, so no proposal or card asks the user to undo one. An After unit constructed again reaches each of its dependents the same way, and holds none of them. The later unit resolves every conflict, keeping both changes' intents; the earlier is never changed for it. A fix is built the same way on fix/<bolt>/<name> from the bolt, in <kit>/places/fix-<bolt>--<name>, with no change and no plan record; a fix name already in use on the bolt is refused. While the team holds two bolts, a new fix names its bolt, crew fix <team> <name> "<words>" --bolt <bolt>, and is refused without it; one in flight is found by its name. A fix merges into the bolt like a unit, by a submission; nothing of crew's moves a bolt's branch. A landing that conflicts with main is the bolt's: a fix merges main into its place, resolving the conflict, and is submitted to the bolt. Every worktree crew made goes, with its branch, once its work is over: a bolt's branch, which crew marks as its own in the kit's git config when it makes it (branch.bolt/<bolt>.crew), and marks landed once sluice has landed it on main, once no plan has it and no worktree is on it, a dropped bolt's only by sluice's delete, which keeps it on GitHub and the team's host, marked dropped, named as the drop's unmerged work in sluice's words and recorded once, while main lacks its tip, the team's reads asking sluice again once main holds it, and a landed bolt's only when git cherry finds no commit on it whose patch main lacks, and the worktree a bolt given before bolts were branches still has likewise, a unit's once it has merged into its bolt or landed or no plan has it, and a fix's once it has merged into its bolt, its conductor dropped it, or no plan has its bolt. A unit's, chore's or fix's branch goes with its place only when git cherry finds no commit on it whose patch its bolt lacks, or, once the bolt has landed or its branch is gone, the kit's main, and crew then says the commit it was at; a branch holding work of its own, a landed bolt's holding a commit main lacks, or one git cannot compare, is kept, named in the command's output with the commit it is at and how many commits it holds of its own, the user's to keep or delete, and recorded once in the run record (branch.kept), so a landing leaves in the kit only what main lacks. A unit or chore added again under a kept branch's name starts from it: its place is made on the branch as it stands, which then tracks the new bolt, and its construct's start, a chore's code, says so. crew fix <team> <name> --drop ends a fix that is not wanted, one in flight or one whose branch and place stand with no slot: its slot is freed and its agent ended, a working one only with --force, its branch is marked branch.<fix>.crew dropped in the kit's git config, and the team's read that follows removes its place and branch as a dropped unit's, keeping the branch, named and unmarked, when git cherry finds commits of its own beyond the bolt. A fix that has merged into its bolt is not dropped: a new fix undoes it. Each time crew reads a team (crew status <team>, crew unit run, crew fix) it frees every slot whose unit or fix has merged or been dropped, or whose unit has left the team's bolt (queued again by crew bolt drop --requeue, or moved to another bolt), once the slot's agent is not working, then removes every such worktree in the team's kit checkout that no slot holds, whatever left it there. crew bolt drop, crew unit drop and crew bolt land do the same on the team's host right after they change the plan, and a conductor's wait does it once it sees a merge into the bolt delivered; when that host doesn't answer, the team's next read does it. A worktree with uncommitted changes (modified files, or untracked files git doesn't ignore) or a lock is kept with its branch, and every read names it until it is clean, when crew removes it, or gone; ignored files, such as installed dependencies, never keep one. Each removal first has sluice let the worktree go, asked from the kit's main checkout: sluice runs the teardown command the kit's sluice policy gives, ends what the worktree's runs left running and frees its ports, so what sluice stood up for it goes too; a let-go that fails, its teardown command among them, keeps the worktree with its branch, and every read names it, in sluice's words, and tries it again. It then goes through the kit's own wt remove, run from the kit's main checkout with the branch left to crew, so the kit's remove hooks run: those before removal with the worktree's files still there, those after once it is gone. A remove hook that fails, or that the user has not approved on that host (wt config approvals add, in the kit's main checkout), keeps the worktree with its branch, and every read names it, with what wt said failed but never its advice to skip the hooks, and tries it again; crew never approves or skips a kit's hooks. A host whose path has no wt keeps the worktree too, named. crew removes only worktrees directly under <kit>/bolts/ or <kit>/places/ on a bolt/, unit/, chore/ or fix/ branch it names, the landing's place <kit>/places/land-<bolt> on bolt/<bolt> among them, which goes once no plan has the bolt and never while its submission is with sluice, never the main checkout, a worktree made by hand or a detached one but a bolt's, and nothing while a plan the kit's work goes in can't be read. A bolt's worktree from before bolts were branches holds no bolt branch while the bolt lasts: each read of the team detaches it at the bolt's tip when it is clean, saying so, its branch then marked as crew's, and names it as kept on the branch while it has uncommitted changes, until it is clean; it goes, detached, once the bolt is over. crew rebuild frees those slots too, its agents ended with the rest, and keeps only the slots of work still in flight on the bolt. crew unit free <unit> frees a slot still holding a dropped unit, or one no longer in the team's bolt, at once, and refuses a unit still in it.

A bolt may also hold chores: planned maintenance that changes nothing a spec says must be true and needs no decision, such as a tool or dependency bump, a pin or config aligned with another, the archive of a change whose every task is ticked, a rename, or a stale instruction or line of documentation. A chore has no OpenSpec change, no construct and no review: crew chore run <chore> code|verify|merge builds it in its bolt, on chore/<chore> in <kit>/places/chore-<chore> from the bolt, each stage a fresh agent in a slot of the team as a unit's is. Code is told Chore <chore>: <its words> and commits each change with a Chore: <chore> trailer; verify is told Verify chore <chore>: <its words> and checks every commit beyond the bolt against them, saving its report as a unit's verify does, each finding marked fix or leave; merge merges it into the bolt as a unit's merge does. After means for a chore what it means for a unit: a chore's code starts once each unit or chore it comes after has something committed to build on, a unit's change or a chore's code, never waiting on a merge, its new place taking their heads as they stand (Took), and it merges only after each has merged; a unit that comes after a chore is constructed once the chore's code has delivered, its place taking the chore's head. Verify waits for a commit of the chore's own beyond the bolt, what its place took of others never counting as its own; merge waits for the chore's verify to have delivered, once, and is refused, naming the commits, while one of its own lacks the trailer. When what a chore comes after merges, the team's next read rebases the chore's place onto the bolt, as a unit's. crew unit run on a chore, or crew chore run on a unit, is refused naming its kind. A chore's stage is read from the kit like a unit's: landed once main's history holds its trailer, merged once the bolt's does, verify once its place holds a commit of its own beyond the bolt, code while it holds none, else ready or waiting. No batch ever holds a chore. Its slot is freed and its place removed as a unit's are, once it has merged or landed, been dropped, or left the team's bolt; crew chore free <chore> frees its slot at once, as crew unit free does a unit's.

A stage ends at what it delivers, read in the kit or on the team's host, never when its agent goes quiet: construct's change committed since the stage began, its planning complete; code's commit since it began, with every task ticked at the branch's head; settle's commit since it began; verify's report for the unit saved since it began in the team's reports folder, ~/.local/state/<team>-team/reports; merge's bolt holding the unit's change archived, the chore's trailer or the fix's commits; a fix's commit, and a chore's code's, on its branch since it began; and a chore's verify's report. When a stage began is the time at the front of its start's entry id. crew unit wait <unit>, crew chore wait <chore> and crew fix <team> <name> --wait run on the team's host and return with one line: the stage delivered, once its agent has stopped working, with what it delivered, and its end recorded; it stopped short, with what its agent needs in the agent's words; it is stuck, its agent quiet past --stuck (15 minutes) with nothing delivered, nothing said and no background work of its own still running, which crew reads from the agent's Claude transcript (when it can't, the clock runs and the line says what could not be read); its agent is gone; a verify's agent has ended its turn, its transcript's last message its own ending the turn and nothing of its own still running, with no report saved, so the verify has not ended, which the line says then, naming the report and the folder crew reads, never calling it stuck; or it is still running when --timeout (an hour) passes, its agent working or waiting on work of its own. A wait ends with the Claude session that started it, read by the process id Claude Code gives each command it runs (CLAUDE_PID): once that session is gone the wait ends at its next look, saying so and recording nothing, and so do crew review <label> --wait and the sluice wait a landing keeps running while sluice has its submission; a wait run from a shell, or forwarded from another host, has no session to end with. Only a delivered end is recorded by a wait. A verify saves its report every run, one with nothing to do as well, its last section then the one line "Nothing to do.", and a unit's merge is refused until its verify has delivered its report since its change was last written, naming the report it lacks and the folder. Each look also reads sluice overview --json on the team's host and says at once, before the answer, each conflict or failed check sluice records for a submission from the stage's place, in sluice's words (conflict #2 on shared.txt, blamed #3 on 3d44d6b), asking sluice status <id> --json where the submission left the queue before a look saw it; an overview it cannot read is said once, and the wait goes on by refs alone. crew needs "<what it needs>", run by a stage's agent, ends the stage short: crew records the end without the words and gives them to the conductor, as the answer of a wait running on the stage, else in a tell marked as from the agent; anyone with no stage owed is refused. crew then ends the agent's session, from a process of its own on the team's host, once its turn ends, or half a minute on if it works on, so no agent goes on after its needs as if its stage stood; the slot's next start ends such an agent at once if it still runs, so it needs no --force, and an agent whose Claude session crew can't read is ended by none. A unit's merge archives what its own archive needs first, so its stop-short is refused, once in the stage and naming them, while its branch holds its change open beside changes it can archive itself: each change no unit of the plan has, every task ticked, whose deltas touch a capability its change's do, or one such change's do; told, it stops short again only when openspec refuses one of them, and that is passed on. The answer comes back as the stage run again with it as its words, in a fresh agent.

A team is two herdr workspaces in its session: <team>, with a conductor tab (the conductor and ops, started in the kit's main checkout, or in the worktree a bolt given before bolts were branches still has) and no git tab, on a Mac as on a box (a git tab an earlier crew opened there is the user's to close), and <team> units, one tiled pane per slot in flight, which exists only while a unit or fix is. Neither folder names the branch the conductor and ops work for, so while their team holds a bolt each carries the branch of the bolt it builds for sluice's sidebar and board, as SLUICE_BRANCH and as its pane's sluice_branch token, set again when herdr resumes it and cleared once the bolt lands or is dropped, when the conductor and ops are restarted at their next stop without it; a unit slot carries neither, its place being on its own branch. A team sits whole on one host, and its panes and state live there: a command about a team run anywhere else is run on the team's host, over ssh, by the crew checkout that host's sessions keep.

The plan

crew bolts [<bolt>] [--label L] [--json]
crew bolt  new <bolt> "<goal>" --repo <kit> [--source S]... [--before <bolt>]
crew bolt  give <team> [<bolt>]
crew bolt  order <bolt> --before <bolt>|--first|--last
crew bolt  drop <bolt> "<reason>" [--requeue]
crew bolt  land <bolt>
crew bolt  leave <bolt>... --excerpt "<the user's words>"
crew unit  add <unit> "<intent>" --bolt <bolt>|--repo <kit> [--source S]... [--after U]... [--before U] [--signal ID] [--unblocks <bolt>]
crew unit  split <unit> "<narrowed intent>" --into <unit> "<intent>"
crew unit  amend <unit> "<new intent>"
crew unit  order <unit> --before <unit>|--first|--last
crew unit  after <unit> <unit>...|--none
crew unit  move <unit> <bolt>|queue [--unblocks <bolt>]
crew unit  drop <unit> "<reason>"
crew chore add <chore> "<what is done>" --bolt <bolt>|--repo <kit> [--source S]... [--after U]... [--before U] [--signal ID] [--unblocks <bolt>]
crew chore order <chore> --before <unit or chore>|--first|--last
crew chore after <chore> <unit or chore>...|--none
crew chore move <chore> <bolt>|queue [--unblocks <bolt>]
crew chore drop <chore> "<reason>"

Each partition keeps one recutils plan.rec, for all its kits, on its flywheel's branch of its state repository (see State). It holds only intent: Bolt and Unit records, in build order, a Unit record marked Kind: chore being a chore, its Intent its words. A name is taken once in a kit, by a unit or a chore: crew unit add and crew chore add refuse one the plan holds, one the kit's main has a change by, and one main's history holds a chore trailer for. The crew chore commands take a unit's flags and make its refusals; there is no chore split or chore amend, a chore's words changing by a drop and an add, and a unit command on a chore, or a chore command on a unit, is refused naming its kind. A Source is a path in the partition's first blueprints repo, or <owner>/<name>:<path> in another. Every stage is read from the kits, one call per host. A command fetches the branch and reads each kit once on each host it runs on, however many steps it has, and a step that makes or removes a worktree leaves the next to read that kit again; a wait reads afresh each time it looks, and the host's follower and crew events --follow read again, at each look, only what has moved since they last read. A unit's tasks and planning mean what OpenSpec means by them, read from the change's files when it uses OpenSpec's spec-driven workflow and through openspec otherwise. A write fetches the branch over https into crew's bare cache of the repo (~/.cache/crew/git/<owner>/<name>.git), applies itself to the tip, checks each file it changed with recfix --check and the plan with crew's rules, commits through a temporary index, and pushes without force; a push refused because someone wrote first is applied again to the new tip, up to five times. Nothing is ever merged. A write that touches a bolt a team holds sends that team's conductor the commit's subject.

A unit's stage, as crew bolts shows it and --json gives it in stage, is the first that holds of landed (main has its change), merged (its bolt holds its change archived, as its own merge leaves it), verify (every task ticked), code (some ticked), planned (its planning complete), construct (its worktree exists), and ready or waiting by whether each of its After units has finished construct; a unit with no bolt is queued. A unit whose change its bolt holds open, carried there inside another unit's merge, has not merged: it reads at its own stage, from its place or, once that is gone, from the change on the bolt, keeps its place and slot, and crew status names it carried by another's merge, its own merge owed; that merge makes its place again from the bolt when it is gone. A unit's or chore's merge is refused while its branch holds another unit's change open that the bolt does not hold archived, naming it. A unit the plan marks Amended reads, after landed and merged, amended until construct is run again, then construct until that commits, whatever its tasks say; then the mark stops counting, the unit reads from its tasks again, and the write that records that construct's end clears it.

While a submission stands in sluice's queue, crew bolts shows its number and state on its bolt's row from the first read after the submit, whoever made it: a unit's, chore's or fix's merge into bolt/<bolt> on that line, #41 under test, and the bolt's landing on its kit's main, from bolt/<bolt> or a pull request opened from it, on the bolt's head line, landing #355 queued; --json gives each line a submission and the bolt a landing, each with its id and sluice's state. crew reads them from sluice's own record of the queue, sluice overview --json once in the kit's main checkout on the team's host, so a session that comes back after a restart finds on the row each submission it had in sluice. A queue that can't be read there is said once on the bolt's head line, and no line shows a number or says it has none.

A unit in flight is amended in one of two ways, and both put its revised change in the partition's next batch. How it builds what it builds changes when its conductor runs construct again with the user's words (see Teams). What it builds changes with crew unit amend <unit> "<new intent>", which the user runs at a shell and the planner only inside a proposal: it replaces the unit's intent, and a unit that has a worktree is marked amended (intent, or proposal/<n> from an approval). Once the plan's write has landed, the amendment hands its construct to the team's host, in the name of whoever applied it, the user or the proposal's approver, and answers once the host has it, never waiting on an agent's session coming up or its prompt landing: a process of its own there runs crew unit run <unit> construct, one handed construct at a time on a team, and its fresh agent is told the intent was amended and by whom, and given the planner's case as the user approved it for a proposal. The conductor is told that construct runs again and to wait for it, with the card of the verify the amendment ended named once construct starts; or why it did not start (the host does not answer, the team is down, or the slot's agent is still working, which crew never ends for it), with that card, and to run it once it can. crew unit wait <unit> waits for a handed construct to start before it waits on the stage, and says why when it did not; a stage of the unit run while it starts is refused. A team taken down is said, and its conductor told, at the hand-off. A unit whose construct did not start reads amended, and anyone may start its construct, the user having approved the amendment. A conductor crew brings back finds such units: the greeting of crew up, rebuild, restart and revive opens with the units of its bolt that read amended, and crew resume, which greets only an agent it has to start fresh, sends a conductor it brought back with its conversation the same line as crew's notice. A unit that has merged is refused: a defect in it is a fix, and new work is a new unit.

crew bolt drop removes a bolt and its units and chores from the plan, or with --requeue queues them, which it refuses while one of them has a worktree, since a queued unit has none; for a bolt a team holds, it then has sluice delete the bolt's branch, sluice branch delete bolt/<bolt> --into main on the team's host once its worktrees are gone, wherever the policy at its tip keeps it, crew deleting none with git: sluice deletes a branch whose tip main holds, and keeps one while main lacks its tip, on GitHub and the host, which the drop names as its unmerged work in sluice's words, the user's to keep or delete, and records once, the team's next read after main comes to hold its tip having sluice delete it; a drop whose host does not answer names the command, which the team's next read asks. crew bolt land removes a bolt whose units and chores have all landed on main, which crew bolt submit runs for each bolt as it lands and main-level ops runs itself for one the submission landed and could not close, has sluice delete the bolt's branch after its plan write, sluice branch delete bolt/<bolt> --into main on the team's host once the landing's place is gone, wherever the policy at its tip keeps it, on GitHub for a bolt given through sluice or a bolt made before whose landing's pull request put it there, naming a delete sluice refuses in its words with the bolt out of the plan all the same, ends the bolt's reading and lets go its preview on its team's host, and raises its kit's landings card on the partition's main machine, which closes once every bolt the user ticked has landed or been held, "Landed on GitHub's main: at <sha>; every host's folder follows by swancloud's timer within minutes". The word to land is the user's send on that card, or their own words in main-level ops's pane, which ops passes with crew bolt submit <bolt>... --excerpt "<the user's words>": before anything is submitted, crew reads the words in ops's own session transcript on its host and goes on only when it reads them as the user's, typed in the pane or told from the user's shell, refusing ops's own words, another agent's, crew's, a tool's and a word from the board, naming who said them; each landed bolt's bolt.submit entry names the transcript record and the words' length and none of the words, ops's host keeps the words until crew bolt land, and the kit's landings card then says first that the bolt landed on the user's word in ops's pane, with their words, changed in place while other rows can land and closed as answered there once none can, or, run on another host than the submission, naming the pane and the time without them. crew bolt submit <bolt>... lands one kit's bolts in the order given, refused before anything is submitted when they are of two kits, one is named twice or one is held by no team; a landing of a bolt already standing in sluice on its kit's main at the head it would submit, as when the session that submitted it ended, read from sluice's queue on the team's host, is waited on again rather than submitted anew, saying its number, nothing submitted and its pull request left as it is, and its end read and recorded as any landing's, while one standing at another head is said, naming its number and head, and the bolt submitted as below, as it is when the queue can't be read; for each other it first fetches the bolt's branch from the kit's origin on its team's host and submits the bolt where it lives: a bolt on GitHub, whose copy there has a policy naming a remote for it, at GitHub's head, never the host's own bolt/<bolt>, sluice's copy, which may lag and which crew first sets to that head with git update-ref guarded by the value it read, the one write sluice's guard lets through, saying so with both commits, or makes there when the host has none; a legacy bolt whose host tip holds merges GitHub's copy lacks, and GitHub's nothing beyond it, at that tip, its push moving GitHub's branch forward; and a bolt that lives on its host at its host's branch; a bolt whose two copies have diverged, each holding merges the other lacks, is submitted nothing and nothing is written, naming both commits and what each lacks, since either submission would drop merges, and the way on: the bolt is its branch on GitHub, so its team's conductor starts a fix, cut from GitHub's head, that takes the host copy's merges in with git merge bolt/<bolt> and merges into the bolt through sluice, the one merge into a split bolt crew lets through, since its head holds the host's tip and sluice drops none of it, and the landing then submits GitHub's head, levelling the host's copy to it; so is one whose copy on GitHub can't be read, in git's words, each before its pull request is readied; then it makes a short-lived worktree on the bolt's branch at <kit>/places/land-<bolt> on its team's host, or brings one a stopped landing left there to that head without writing a ref, and runs wt submit main --no-wait --json there in the asker's name, the next as soon as sluice has queued it when both are on one host, so sluice tests them as one chain and lands them in that order, and only once it has ended when the next is on another; then it waits on each in order with sluice wait, removes its worktree, naming it with git's words when git cannot, for crew bolt land to remove with the bolt's branch or name with why it stays, closes each that landed with crew bolt land's own code, naming one it could not close with that command, and records one that did not land at the head it submitted, the rest going on, the command exiting non-zero naming each that did not land: refused, holding its row on the kit's landings card for its team's fix, only when sluice's own record of the submission has it in conflict or blamed for a check that ran and failed or that its time limit cut off, the bolt's own content; and stopped, with what stopped it and no refusal, for anything else, sluice itself failing, checks the host could not run, a refusal or an answer with no conflict or failed check in sluice's record, a withdrawal or an outcome crew can't tell, which keeps its row's box and the user's word, its row and its rail line saying what stopped it at that head and that main-level ops submits it again once that is cleared, which ops does with the same crew bolt submit on that word, with no new word of the user's, an answered landings card left as it is while it is stopped, a card that follows naming it as still landing with what stopped it, and crew card read land/<kit> printing the stop beside the command that lands it; sluice forms the landing on GitHub's main and pushes it with a lease, so nothing is refused for the host's own main lagging GitHub's, and whatever sluice warns of stops nothing. A landing pushes nothing and levels no host's checkout, its one write on the host the level of its copy of the bolt's branch above: every kit's main checkout is an anchor at GitHub's main that the fleet's timer moves within minutes, which crew never moves, and one still on branch main is brought level only until the timer reaches it, crew saying nothing of a detached one. A bolt no team holds, built outside a team, lands the same way on the user's word once main holds each of its units' changes and chores, read on the host of a team of the partition building that kit, with nothing to merge; its entry in the run record names the kit and the commit GitHub's main holds afterwards, read after a fetch (Repo and Head), from which a deploy's view tells the bolts it carried, and, for a bolt a team held, its age in whole minutes from its newest give to sluice's landing of it (Age) and those minutes by holder, as its head line on the board splits them (Split, team 200, kit 12, team-or-kit 13, user 125, hold 0, nobody 20, team-or-kit a submission's stay crew can't split between queued and under test), read once from sluice's record on the team's host, or neither when that or the give can't be read, the landing going on. A landing that conflicts with main, or fails main's checks, lands nothing and moves nothing: main-level ops passes sluice's words to the bolt's conductor, and the team takes main into the bolt by a fix submitted to it (see Teams). In a kit whose sluice policy at main takes pull requests into main, as crew's does, a landing's pull request from bolt/<bolt> is live only on the user's word, since sluice takes an open pull request out of draft back into main's queue whenever its branch moves: crew bolt submit readies each bolt's draft pull request before it submits it, submitting nothing of that bolt when it can't, and a landing that does not land leaves it a draft, said with its link, which a fix's start and every unit's, chore's or fix's merge into the bolt keep, each drafting it first, a merge that can't not starting, so only the next crew bolt submit, on the user's word, makes it live again; crew reads and marks it with gh on the team's host, and asks nothing of GitHub in a kit whose main takes no pull requests. Either way the bolt's branch and worktrees then go from its team's host (see Teams), and a landing whose worktree is kept, for uncommitted changes or a remove hook, still lands.

Proposals

crew plan propose <file> [--replaces <n>]
crew plan proposed [<n>] [--label L] [--json] [--open]
crew plan agree <n> [--team <team>]
crew plan approve <n> [--clear <unit>...]
crew plan answer <n> <question> <answer>... [--note "<text>"]
crew plan drop <n> "<reason>"

crew plan propose <file> takes a file of one record, a Case and its Do lines. Each command is checked in order against the plan as the ones before it leave it, with every refusal it has run directly; a refused command refuses the proposal and nothing is written. A proposal is also refused, with nothing written and no card raised, when a bolt it creates, or a unit or chore it adds or moves into a bolt, names as a source a decision record (docs/adr/<number>, of its kit, or of the repository written before it as <owner>/<name>:) that its main on GitHub does not hold accepted, naming each record and what main holds: proposed, rejected, accepted with an amendment still marked proposed, no status, or no such record. The conductor of each bolt in flight the proposal touches is told. --replaces <n> drops proposal n and writes its successor in one commit. Once the proposal is written, crew raises its Pending You card itself, in the planner's name, keyed proposal/<n> of the first proposal of its chain (the one each --replaces follows back to), and prints the line the planner adopts it with; a rewrite changes the chain's one card, "Rewritten as proposal after your note", in place while it waits on the user, and once the user's note answered it, by acking it with that note and posting the new version following it; a card whose rows fill more than one list asks them as questions, which Pending You never changes in place, so a rewrite, or a conductor's agreement, withdraws it with the note while it waits and posts the new version following it, as does a rewrite that moves the card to another form, a hold-to-approve, a choice, one list or lists; the rail's row for the successor carries the chain's key. A proposal the user writes has no card. The card asks only the units and chores the proposal makes new to a bolt or the queue, in one checkbox list, each a box ticked as proposed, which the user clears to leave it out; what else it changes, a drop, an amendment, a move, an order or a new bolt, is drawn on its face and applies with it, as its summary says. A lone new unit is the choice of its two sides, and a proposal with none a hold-to-approve, which the user declines with a note to keep what it drops or amends. A card Pending You refuses refuses nothing of the proposal.
crew plan proposed lists the open proposals and what each waits on; crew plan proposed <n> prints one as markdown: the case, then each change in plain words, a unit's intent beside what it rests on (a signal's assertion and excerpt) and the goal and team of the bolt it would join, and an amended unit's bolt, team and stage, its intent as it stands and as proposed, and what approval sets in motion; under each change, the command approval runs; and, for an open proposal, who it waits on, in words. It reads only the branch, so any host can answer. With --open, it writes that page to ~/.local/state/crew/proposals/<label>-<n>.md on the host it runs on and opens it in plannotator, for the user to read and annotate: beside the caller in herdr, inline in the terminal otherwise.
crew plan agree <n> is a conductor's recorded agreement to a proposal that touches the bolt its team holds; the user may agree for any team it touches. crew changes the proposal's card to say it no longer waits on that conductor, where the card was posted or on the planner's own host.
crew plan approve <n> applies the proposal's commands, as read, to the plan at the tip and closes the proposal, in one commit, or changes nothing when one no longer applies or a touched bolt's conductor has not agreed. A unit or chore with a worktree that moves is rebased before the push and put back if the approval is refused. With --clear <unit>... it leaves out the new units and chores the user cleared and every command that concerns only one of them, so a cleared unit is never made and one moved in from the queue or another bolt stays where it was; it refuses, changing nothing, a cleared unit the proposal does not make new to a bolt, and a command left in that names a cleared unit, for the planner to write the proposal again; and it records each as Cleared on the proposal. The user runs it, or an agent on the user's word. crew then closes the proposal's card with what was applied and what was left out, and tells the planner the same when someone else approved it.
crew plan answer <n> <question> <answer>... records one answer of open proposal n's card, as the planner reads it: rows-<k> and the ids of the boxes the user left ticked (rows-1 for a card of one list, and for a lone new unit the side picked), or, for a hold-to-approve, plan approve or plan decline, with --note for the user's note. It checks the answer against the card crew builds for the proposal, refuses an answer that differs from one it holds, and keeps the answers in ~/.local/state/crew/cards/<label>/proposal/<n>/answers.json on the host it runs on, the planner's, never on the branch. Once it holds every question's answer, it applies the change with the boxes as they stand, as crew plan approve does: a new unit unticked left out, as --clear leaves it, and recorded as Cleared; and it prints the note as the user's word for the planner's next proposal. A decline applies nothing. Either way the answers go.
crew plan drop <n> "<reason>" closes a proposal unapplied, with the reason, and crew withdraws its card with it, or, once the user answered the card, closes it as dropped on their note, since their note may ask them something, which Pending You refuses as a close's outcome.

Work a bolt in flight needs before it can be proven or land goes into that bolt: a unit add or unit move marked --unblocks <bolt> must place the unit in that held bolt, where it goes ahead of the first unit not yet merged, and the mark is shown on the proposal.

Who writes the plan directly, when the command runs as an agent crew started (CREW_AGENT):

Agent	Writes directly	Otherwise
the user at a shell	everything
`<label>-planner`	proposals	refused, naming `crew plan propose`
`<team>-conductor`	`unit split`, `unit order`, `unit after`, `chore order`, `chore after` on units and chores of the bolt its team holds, and the amended mark `crew unit run <unit> construct` sets on one that is planned, in code or in verify; `plan agree`. The mark's move on a unit whose intent was amended is made by whoever starts that construct	refused, naming the planner
`<label>-design`	`unit add … --repo <kit>` and `chore add … --repo <kit>`, the queue	refused, naming the planner
`<label>-dispatch-<host>`	`bolt give`	refused, naming the planner
`<label>-ops`	`bolt land`	refused, naming the planner
any other agent	nothing	refused, naming the planner

Every refusal is a run-record entry. Writing, agreeing, approving and dropping a proposal are entries naming proposal/<n>, and each change an approval applies is an entry of its own, from the proposal, with the approval's commit; crew trace follows them.

State

crew state init <label>

A partition's flywheel is its loop, named by its label. Its state is the files on one branch, <label>/main, of the state repository the teams file names for it (state, one per organisation, such as WilldanGroup/crew-state), apart from the design:

plan.rec, the plan;
moves.rec, every signal's one move;
proposals.rec, the planner's proposals;
signals/<capture>/, the captures and signals recorded through crew (see Signals);
runs/<host>/<YYYY-MM-DD>.rec, the run record, each entry pushed by the host that wrote it as it is written.

Flywheels sharing a repository never meet: each command fetches and pushes only its own flywheel's branch, and no branch shares history with another. A write that changes several files is one commit, and its message ends with a Crew-Entry: trailer naming the run-record entry that describes it; that entry follows it as a commit of its own, changing its day's file under runs/<host>/ alone and naming the entry it adds. crew state init <label> creates the branch: it adopts the first blueprints repo's plan/<label> with its history where there is one, joins another blueprints repo's plan/<label> in one commit naming where it came from, and copies the first blueprints repo's signals/moves.rec; run again, it finishes what a stopped run left, or says the branch exists. A clone of the branch reads with recsel and nothing else.

Signals

crew signal <slug> "<what it asserts>" --excerpt "<the words, verbatim>"|--excerpt-file <path> [--kind K] [--subject a,b]
crew signal show <id>
crew signal move <id> attach|challenge|new-territory|answered|drop [--target T] [--reason R]
crew signal land <capture-dir> [--label L]

A signal is one thing noticed, with the words that show it, in the shape the blueprints' signals/README.md gives: a directory per capture, holding capture.md and one file per signal. Signals have two homes. What the agents and the user record with crew signal is under signals/ on the flywheel's branch of its state repository; what the daily pass reads from meetings and channels stays under signals/ in the partition's first blueprints repo. An id is unique across both, and every command looks it up on the flywheel's branch first.

An agent crew started gives an excerpt: the words that show the finding, copied as its session received them, from the user or from a tool's output (--excerpt-file for words the shell would mangle). crew looks for them, whitespace aside, in the agent's own Claude transcript, ~/.claude*/projects/*/<session>.jsonl for the session herdr names for the agent, and records a grade on the capture:

verified: the words are in a record the session received, and the capture says who asserted them: user; tool, for a command's output; agent:<name>, for what another agent sent with crew tell; or crew, for crew's own notice;
found: they are in the transcript, in a record crew cannot classify;
unverified: crew could not read the transcript, and the capture says why: herdr names no session, there is no file, its lines are not JSON, or it has not been written for 15 minutes, so crew may be reading another session's.

A signal is refused only when the transcript is the live session's, its last record written within 15 minutes, and the words are nowhere in it but in what the agent wrote itself: a paraphrase. The refusal says so, and names the other way words a tool printed can be missing: a background task's output reaches the transcript only once the agent has read the output file its task notification names, so the agent reads that file and records the signal again. A change in Claude Code's format lowers a grade and never stops a capture, and no command refuses anything for its grade; the grade is shown wherever the excerpt is.

A capture is the one record the excerpt came from. Its capture.md names the host, the Claude session, the record and its time, who asserted it, and where the agent was working: its team, the bolt the team holds and the unit its slot holds, or the main level. The record itself is copied to ~/.local/state/crew/<label>/raw/<capture>.jsonl on the host, and the capture points at it as <host>:<path>; of the source, only the excerpt enters git. A second signal from the same record joins its capture as its next signal, and the same signal again writes nothing. The capture and its signal are one commit on the flywheel's branch. The user's own note, crew signal at a shell, is its own excerpt (excerpt: own), of kind ask unless another is given.

A program records its own captures, a kit's deployer one per failed deploy, an adapter watching the tools the fleet pins one per newer upstream version, and hands each to crew with crew signal land <capture-dir> --label L, run as the program (CREW_AGENT) on the host that ran it. The folder holds capture.md and its signals, NN-<slug>.md, and nothing else; the capture names itself, the program as its source, who captured it, its event's date and its raw record, <host>:<path>, which must be on that host, since only the excerpt enters git; it is read, and counts its signals, at least one, made by the program with no model between: the capture is its own excerpt. Each signal names itself, its kind and who asserted it, says what it asserts, quotes its excerpt, and is no larger than 8 KiB, the program cutting its excerpt to fit and keeping the whole in the raw record. A capture whose name is not crew's kind of name, lowercase words, digits and dashes, is refused. crew lands the folder whole on the flywheel's branch in one commit, as a capture entry naming each signal; files the branch holds already are passed over, the same capture again prints that it is already landed and writes nothing, and a capture or signal there that differs is refused, since neither is ever changed. A program never writes a blueprints repo, and crew signal land --help's first line is its usage, which a program reads to know this crew takes captures.

crew signal show <id> prints a signal, its capture's fields (the grade, who captured it, where and when, the session and the raw record) and its move, from any host. Every command that takes a signal's id, show, move, --signal and crew trace signals/<id> among them, takes its full id, <capture>/<NN>-<slug>, or its short one, <capture>/<NN>, which names the one signal of that capture numbered NN. Curation's moves, crew signal move, are appended to moves.rec on the flywheel's branch, and a signal becomes work only through its route move, which crew unit add --signal writes in the same commit as the unit, and crew chore add --signal with the chore. Each signal has one move, and nothing is ever merged.

What crew sends an agent is marked as crew's: crew tell sends [crew tell from <sender>] <text>, the sender being the agent or <user>@<host>, and crew's greetings and notices send [crew] <text>, so neither is taken for the user's typing. A word the user sends from a dock of the board reaches its item's agent through crew tell --board, which reads the word as the board's listener posts it, {"label", "key", "to", "text"} on its standard input, refuses one that is not of that form, names no partition crew knows, is on a key of no dock's kind, is for an agent its item's kind does not go to in that partition, or is empty, over 1000 characters or more than one line, and sends [crew tell from <user>@board] (on <kind> <name>) <text>, <user> being whom the listener runs as, printing sent to <agent>; a tell it can't make types nothing and says why in the tell's own words. It is recorded as any tell, with its length and never its text. A tell from <user>@board is the user's word on the item it names, and a signal captured from it is the user's, but it answers nothing: crew never takes words that reached an agent only from the board as the user's word to land a bolt, answer a batch or settle a record in a pane, saying the words came from the board and where the user answers instead, and the same words typed in the pane, or told from the user's shell, still count. Every brief says so beside its roster.

The main level and the console

crew main     up|down|status <label>
crew console  up|down <label> [flow] [rail] [board]
crew _follow  [--once]
crew rail     [--label L]
crew board    [--label L] [--json]
crew card     session|end <key> [<unit>] [--label L]
crew card     read <key> [--label L] [--json]
crew card     answer batch/<n> --excerpt "<words>" [--label L]
crew card     preview <key> <thing> [--done] [--label L]
crew record   <kit> <number> --proposed|--accepted|--rejected [--settled-in-pane --excerpt "<words>"] [--alternatives <file>] [--label L]
crew review   <label> [--wait [--timeout <ms>]]
crew revive
crew tell     <agent> "<text>"
crew tell     --board < word.json
crew send     <team or partition> "<text>"
crew sites    [<label>] [--json]

Operations

crew ops offer <env> --label L --to <sha> --from <sha|none> [--notes <file>] [--steps <file>]
crew ops approve <env> --label L --to <sha>
crew ops word|quiet <env> --label L
crew ops record <env> --label L --to <sha> --act start|step|end [--from F] [--step S] [--outcome O] [--log P] [--rows F]
crew ops step <env> --label L --key K --state waiting|handed|done|failed|declined [--to <sha>] [--doer D] [--agent A] [--when W] [--held] [--text F] [--changes C] [--note N]
crew ops steps <env> --label L --json

The operations on a partition's environments, a deploy being one kind. A landing deploys nothing; a kit's deployer, or a hosted CI/CD in its place, deploys main under each environment's policy (ADR 0012, plan.14), and these are what it asks of crew, each run where the partition's main level runs, as the one asking, on that host's run record (ops.* entries on env/<env>); an offer run on another host carries its files' text there. offer makes a manual environment's deploy of a commit a row under operations on the rail, keyed deploy/<env>, and crew raises its card in main-level ops's name, telling ops the line that adopts it: on its face the kit's notes for the range from the environment's last deployed commit, as the kit's changelog tool wrote them and the deployer hands them with --notes <file>, and the range's after-deploy steps with their doers, one a line as the deployer gathers them (step <n> <doer> <when> <environments> <why> <text>, tab-separated, held among the when words), with --steps <file>; handed no notes, the landings the range carries: the first-parent commits of the kit's main from the environment's last deployed commit to the offered one, read with git where the main level runs, a landing of sluice's by the subject of the branch it merged and one the run record holds by its bolt, or what git could not read. crew writes none of the notes, keeps the files beside the offer on its host and none of their text in the run record, and refuses a file it can't read, offering nothing. The card follows the environment's last deploy card when the user declined it, and otherwise no card: never a landings card, whose landings the deploy carries on its face. The same offer again writes nothing, and posts the deploy's card again when main-level ops holds none open, as when Pending You refused it; handed other notes or steps, it changes its card in place; a newer one replaces it and changes its one card in place. The user's word is holding that card, recorded with approve for the commit the row shows, and refused for any other; word prints the commit a word was given for, or exits 1 when there is none, and a word is for one deploy: once its end is recorded, there is none until the next approval. record puts a deploy's start, each of its steps (the machine, the guests, the suite and its rows) and its end in the run record as it runs; its end closes the deploy's card with each step's outcome, or the step that failed and its log. Every other operation, a command after a deploy, a restart, a check, is a step, recorded with its state, its doer, the agent it was handed to and its text, after the deploy it names with --to or on its own; one whose doer is the user, or an agent's marked --held for the user's word, waits as a rail row, op/<env>/<n>, until it is marked done or declined, and steps gives each step's latest state as JSON. crew raises such a step's card in main-level ops's name, one at a time on an environment, each following the one before: the user's a do with the step's words and, from its text's - why:, - where:, - command: and - done: lines, why, where, each command whole and what is seen when it worked; a held one a choice of now, when the host is quiet, or skip. Recorded again while its own card is open, the step changes that card in place when its words, its doer or its hold differ, a change of doer between the user and an agent withdrawing the card and posting the new one following it, since Pending You changes no card's kind, and the command prints the line that adopts the card either way; only another step's open card holds a step's card back. It closes the card when the step is marked done or declined, and raises the next. A step an agent runs on its own has no card. quiet exits 0 when no stage agent of a team on the environment's host is working and no test of crew's runs there, and 1 saying what does.

Each partition has a main level in the session the teams file names: the design agent (elaboration on main and curation of signals), the planner (the only writer of bolts and placements, and the poster of the partition's review batches), the reviewer (started fresh for each batch, in a review tab, and ended once its summary is written) and the main-level ops (lands the bolts whose verification is green by one procedure, their submission to main through sluice in order, on the user's send on their kit's landings card, and deploys a kit with no deployer only on the user's word for that deploy), as tabs of the <label> workspace; and a dispatcher on each host the partition's teams run on, in <label> dispatch, which gives that host's teams their bolts. The operator, <label>-operator, is the main level's fourth role and the partition's one door (record 0035): it works for the user, and every wait with no card is told to it. A main-level role runs in the main level's session unless its partition's roles names another of the machine's sessions for it, roles.planner.session, so a partition's design agent and planner, both Fable, can sit on two Claude accounts; crew main up opens a <label> workspace in each, and refuses while a role's agent still runs in a session it no longer stands in, which crew main down ends. The console is the console workspace of each host's operator session (the session named <label>), opened by crew console up <label> and closed by crew console down <label>, with no agent in it. It opens with a shell tab alone, a shell with crew on its path, and opens its flow, rail and board tabs only when they are named after the label, in any order, crew console up <label> rail; another word is refused, naming the three. The rail tab opens of itself too while no host job runs the host's follower, since its loop is then the follower. Every later crew console up keeps each tab already open, named or not, and a tab the user closed stays closed unless it is named again. crew operator up <label>, its name before record 0035, opens it too, with no tab named, and ends the operator agent a host's console held before, once it is not working, closing the panes crew recorded beside it. Each agent crew main up starts is greeted once it is up, as a conductor is, marked [crew]: told to read where the partition stands and carry on with what is its role's; one that was already up is neither started nor greeted. crew tell prompts any of these agents by name, wherever it runs, marked with who sent it. Anything for another team or partition goes with crew send <team or partition> "<text>", to that partition's operator, its one door, wherever it runs: a team by the partition it belongs to, a partition by its label. The operator is told [crew tell from <sender>] (sent to <team or partition>) <text> and carries it on to the agent whose job it is, in the sender's words, and the send is one send entry in that partition's run record, with its length and never its text. A name that is no team or partition is refused, naming each, and so is the operator's own send to its partition, which it carries on with crew tell; every brief says beside its roster that this is the one way. A tell to an agent waiting on a question in its pane fails with nothing typed, and says to send it again once the question is answered, whether herdr sees the question or crew's PreToolUse hook marked it when the agent opened a question or a plan for the user; the mark counts until the agent's transcript holds the answer. When herdr names no Claude session for the agent's pane, as after herdr's own restore resumed it, crew reads the session it recorded of that agent starting in that pane, and with neither, herdr's reading of the pane alone guards the tell. crew's greetings and notices go the same way. A greeting is also read back as a stage's prompt is: sent once the agent is ready, cleared and sent once more when its transcript does not show it, and when the second is not taken either, nothing is left typed, no greeting is recorded, and crew says the agent was not greeted, with the crew tell that would greet it.

crew rail lists everything that waits on the user, from any host, in four groups, always in this order: open proposals, review batches that still wait on the user, their card not yet answered and some unit of each neither landed, dropped from the plan nor held by a later batch, each kit with a bolt whose every unit has merged, one row naming each such bolt in the plan's order with what it waits on, main-level ops's, and operations: an environment's deploy offered and not yet approved, and an operation that is the user's to take (see Operations). Each row says what waits, when it began to wait and how long ago that was, and carries the commands that answer it, written to be pasted; within a group, the oldest comes first. A proposal waits from its entry in the run record (or the day it was opened), a batch from its review's end, and a bolt from its last merge. Each bolt's line on its kit's landing row ends with the bolt's age since its newest give and who held that time, by the same rule and from the same read as its head line on the board (see crew board), so the two never differ. Every row and every time is read from the plan, the proposals, the kits and the run record, and nothing is kept by hand: a row leaves the list as soon as its answer is recorded. A host that doesn't answer is named. A bolt whose every unit has merged is offered for landing only once every unit's latest change has been in a batch whose card the user has answered: until then its row names the units that have been in no batch and the batches whose card waits on the user's answer, and carries no command. Nor is it offered until its verification is green, which is the bolt's proof: sluice's verdict on its last landing, the Sluice-Result trailer sluice writes on the commit it lands, read at the bolt's head; until then its row says what the verification is. The host's follower keeps the list fresh, for every partition with an operator session on the host in one read: once a minute on its clock it fetches each partition's state branch and blueprints main, asks Pending You and herdr after the cards its sweep acts on, and reads the dev servers portless lists; each second it looks at this host's caches, so a write on this host shows within seconds and another host's within the minute. Before it reads, it checks whether anything it acts on has moved since its last read, each partition's branches as this host's caches hold them, each kit's refs, worktrees, places and slots on every host it reads, each host's card readings, where a reading the user sends back lands, the cards, crew's checkout and the teams file, and reads nothing when nothing has, or only what moved. It follows each kit's merge queue through sluice's overview, one sluice overview --json --watch for each kit whose queue it shows, a new line putting a submission's number on its row with nothing read again, and reads no folder of sluice's. It hands the agents there that an update made due their restarts once crew's checkout or the teams file has moved, prints the rail, ending card sessions as crew rail does, and writes what it printed and the board as frames in ~/.cache/crew/board/, <label>.rail.json and <label>.json, each saying when it last checked. A host has one follower, which holds the host's follower lock for as long as it follows and says on it which it is: crew _follow, which swancloud runs as a job of the host's with no tab open, or, where no job runs it, the console's rail tab's own loop; a crew _follow started while a rail tab holds the lock waits for it, reading nothing. crew console up <label> rail opens a rail tab in the console workspace: the rail frame above, drawn again whenever it changes, and a shell below with crew on its path, to paste a row's command into; while no one holds the lock, the tab takes it and follows itself, so a tab drawing the job's frames follows within a second of the job ending. crew console up <label> board opens a board tab, after rail when it is there, drawing the board crew board prints from the follower's same read, at its own width, and crew console up <label> flow a flow tab following the run record. A rail or a board read more than three minutes ago is headed with how long ago, so a follower that has stopped is never taken for a live one, and a tab with nothing written yet says so, and that the host's follower writes it. A restart ends the tabs' commands, and herdr brings each tab's pane back as its shell alone: crew console up <label>, which swancloud's timer runs every five minutes, runs each tab's command again in a pane holding its shell alone, read from herdr's pane process-info, and leaves one running anything else, saying so.

crew board shows a partition's whole flow at once, as four lanes stacked one above the other, one object to a line, with a header naming the partition, when it was read and the hosts that answered: Inception, the signals no move has taken in either of their homes, grouped by who captured them, each group with how many it holds and when its oldest was captured, each signal with its kind and its first words, then each exploration on main of each kit the partition's teams build, with the first line of its first file; Bolt plan, each open proposal with its number, who proposed it and its case, each bolt no team holds with its repository, goal and units and their stages, and the queue, each unit with its sources; Construction, each bolt a team holds as a ledger, its head naming its repository, team and host and its landing's number and state while one stands in sluice, and ending with the bolt's age since its newest give, the minutes of it each holder held, a holder that held none left out, and who holds it now and since when, 3h 05m: team 2h 10m, kit 12m, user 40m; user since 14:02, batch/12: each minute goes to the first of these that applies, the team while a stage of its work runs other than a merge, the kit while one of its submissions is under test in sluice, from the start of its checks, the team or the kit, unsplit, while one of its submissions is in sluice with no start of its checks crew holds, from its submit to its decision, or a merge ended with no submit of its work crew holds, shown as team or kit 12m and said once why, team or kit: sluice keeps no start of its checks, and never counted the team's under its merge nor the kit's, the team while a merge runs or one of its submissions stands in sluice not under test, the user while a card of the bolt's is open (its landing card, a batch's holding its work, a proposal's naming it, its kit's landings card once its last merge ended, or a question its team asked), a hold while its team's host is held, held since 14:02: its host deneb is held by chuck, and nobody, a bolt nobody has held for five minutes said to be stalled, stalled since 14:02; it is read from the run record and sluice's overview alone, the line the follower's watch of the kit printed or one ask of it, and no gather runs sluice status: the host's follower keeps each submission of a held bolt it saw stand, with its submit and, once a candidate tests it, the start of its checks, decides it at the time the recent events of the line that no longer holds it give, or at that line's own time when they name it not, a withdrawal, and keeps it for as long as the bolt is held, so a merge decided before the follower saw it, after a restart, reads as team or kit; what can't be read is said with why in place of any share; no card is raised and no one told for a bolt's age. Then each unit in plan order with its stage, its tasks done and total in code and verify, its merge's number and state while one stands in sluice, the slot holding it and the URL of the dev server running in its worktree, each fix with whether it has merged and its merge's number while one stands, and the bolt's own server at the foot; and Operation, each bolt landed in the last seven days, newest first, with when, who landed it, its team and its units, then each environment's deploys that moved in those seven days or are still open, newest first, each with the commit it deploys and the one it comes from, where it stands (waiting on the user's word, replaced by a newer offer unanswered, approved and then replaced when the user's word went to a newer offer before it started, deploying, approved and not yet deployed, or its outcome and when it ended, at the step that failed), whose word it went on and the bolts it carried, and the operations waiting on that environment, each with who has it: a deploy carried the landings on its kit after the one that left main at the commit it came from, up to the one that left main at its own, and when no landing in the record left main at either, the line names that commit rather than a bolt. A lane with nothing in it says none. Every rail row but a batch's is a marker on its object's line, never a line of its own: ✓ on a proposal waiting on the user, on the head of each bolt its kit's landing row names, on a deploy waiting on the user's word and on an operation waiting on the user, each saying at the line's end whether its card is open and who asked it, or that its post was refused, when none is open and Pending You refused the last post under its key, so the row owes its card. The board prints no command and answers nothing: the rail and its shell are where things are answered. At its foot, attention names with ! each host that did not answer, each plan or signals home that could not be read, and each bolt whose every unit has landed but which is still in the plan, whose head carries ! too. It reads the plan, the proposals, the moves, the signals, the kits and the run record, and writes nothing. crew board --json prints the same lanes as data, each held bolt with its time, its age, shares and holder now in minutes, or why it can't be told, each partition's environments with the teams on their host, each object with its markers, each marker with its rail group, its card key, when its row began to wait, its card and, with none open, the words of Pending You's refusal of its row's last post, for the page that draws the board.

Each refresh of the host's follower also writes every agent's view of that board beside the board tab's, in ~/.cache/crew/board/<label>.agents.json, and crew's plugin draws it in the band above that agent's prompt, as a Claude Code mod (plugin/hooks/status.js). A conductor sees the bolt its team holds as a ledger, a pip to each unit for its stage (○ not begun, ◔ construct, ◑ code, ◕ verify, ● merged, ? unread), each rail marker on its line, each merge standing in sluice with its number and state on its unit's, chore's or fix's line and the bolt's landing on its head line, which ends with its age and who held its time, the open proposals that name its team, saying which waits on its agreement, what is planned and queued next for its kit, and what needs attention there; the planner sees the plan in brief, each team's bolt as its pips, the open proposals and whom each waits on, and what comes next and is queued; the design agent sees the signals no move has taken, by who captured them, each decision record proposed and not yet accepted or rejected, from the entries crew record writes, with its card or that the user settled it in the pane, and the first explorations; main-level ops sees the partition's operations, each kit's landing row naming each bolt's landing standing in sluice with its number and state, then, environment by environment: each deploy waiting on the user's word with its card, each approved and not yet deployed, each running, and each operation step waiting, handed or failed, with the deploy it comes after and its doer; and an operator sees the partition's board in brief, a line to each lane, each team's bolt, each environment with a deploy or an operation waiting, its latest deploy and how many operations wait, and how many rows wait on the user, its deploys' and operations' among them. Every bolt's line is led by its product, the repository it builds, and, in the planner's and the operator's, by the team holding it, dim, product by product. Above its view, each agent sees its own open cards, oldest first, its questions among them, each with its key, its id and how long it has been open. Any other agent, and a session that is no crew agent, draws nothing. The mod finds its agent from CREW_AGENT and CREW_LABEL, or from the session's record for one herdr resumed, looks at the file's time every five seconds and reads it only when it has changed: it starts no process and adds nothing Claude reads. Views read more than three minutes ago are not drawn, so no band names a bolt that has landed since or a card closed since: the band says only the day and time they were read and that the host's follower has not refreshed them since; while no follower on the host has written any, a crew agent's band says so in one line, naming crew console up <label>.

Each row of the rail is also answered through one Pending You card, which crew raises at its event in the name of the role that owns its decision: the planner's for each proposal, raised by crew plan propose, and each review batch's one card, which crew raises in the planner's name, and each kit's landings card, land/<kit>, which crew raises in main-level ops's name on the partition's main machine once a bolt of the kit reads proven: a row for each proven bolt waiting on its main, in the plan's order, each a box ticked as crew proposes and carrying the conflicts crew forecasts with main and with each row above it, a bolt held for a fix or for sluice's refusal at its head named with no box, and so is a bolt that takes main first, forecast to conflict with what main holds or with a take-main fix in flight, which the rail's land row also leaves out of the tell that lands; it is changed in place as its rows change, followed when its form changes, and closed once every bolt the user ticked has landed or been held, a new card following it while rows can land, the user's send kept for a bolt held at the close, and a ticked bolt taking main in keeping the user's send standing and the card left. Its rows are forecast again against GitHub's main, after a fetch, whenever main moves: at a landing crew closes, at a conductor's wait that finds a bolt in conflict with what main has landed, and on each rail read on the main level's host, crew rail and each refresh of the rail tab, once the host's origin/main, as the fleet's timer last fetched it, is at another revision than the one the card's rows were last forecast against, which crew keeps beside the card's state there; a row newly forecast to conflict with main has its conductor told the take-main fix, in the words a conductor's wait gives, once for the bolt's head and main's revision, whichever forecast found it first, recorded as a forecast on the bolt. A bolt the user left, cleared on their send or stopped in their own words in main-level ops's pane, which ops records with crew bolt leave <bolt>... --excerpt "<their words>", read in ops's own transcript as theirs and holding none of them in the run record, is forecast the same and told no fix: its row keeps its box, unticked on each card that follows, and says whether it would take main first, a waiting card changed in place the first time a forecast finds it so, and a conductor's wait says its conflict once, as one to take nothing in for; it stays left until the user ticks it on a later send, ops lands it on their words, or its head moves, and the rail's land row says it takes main first once ticked and leaves it out of the tell that lands. Ticked, it takes main first at once: crew card read land/<kit> raises the card before it prints, so its conductor is told the take-main fix, and leaves it out of the crew bolt submit it prints, the send standing for it. A bolt's landing card from before, land/<bolt> in its conductor's name, is withdrawn by the rail's sweep, saying the bolt is now a row of its kit's landings card, and crew refuses a bolt named as a kit of its partition. A decision record's card is crew's, raised in the design agent's name by crew record <kit> <number> --proposed, which the design agent runs once the record or its amendment, committed as proposed, has landed on the kit's main, for a kit its partition builds, under record/<kit>/<number>: one card per record, changed in place, the new commit named, when the record is revised and run again while the card waits on the user, and once the user has answered it, closed with the new commit named and followed by a new card for the revised record, and closed with the commit by crew record … --accepted or --rejected; --settled-in-pane --excerpt "<words>" records the user's yes given in the pane and raises nothing, once crew reads the words in the design agent's own session transcript on this host as the user's, naming the transcript record and never the words in the run record; it refuses the design agent's own words, another agent's tell of them, crew's or a tool's, a word from the board and a transcript it can't read, whoever runs it, recording nothing, and the design agent then runs it without the flag so the user answers on the card; and --alternatives <file> makes the card one choice, loosen the rules as drafted, accept as ruled or send back, the file's alternatives on its face before the record, its frontmatter naming the rules that decided (rules:), the other path (other:) and, when the user's own words point there, recommended: loosen. crew record reads the record on the kit's main where the partition's main level runs, records its status with the commit that last changed it, and refuses a status the file does not hold there and an alternatives file it can't read, recording nothing. --proposed records whether its card offered alternatives, none of the file's words, and posts the card saying an older copy is dead when the design agent's card for the record is held on a host the main level left, or was lost to it. The record is accepted only on the user's yes, in the pane or on that card. No agent posts, changes or closes one of crew's cards: only a conductor, the planner, main-level ops and the design agent post a card of their own, a question, and crew's card hook refuses, before it reaches Pending You, a card's post, change or close from any other role, naming whom to ask, one under crew's own key or of crew's own card, naming the card as crew's, and an area under any key but its kit's create-area:<owner>/<kit>. Before any Pending You tool, the hook also refuses a crew agent's call that names its caller as anyone else, in name (but an area's), whoami's previousName, match_area's task or a card's session.label, since Pending You labels a session by the name its latest call gives and would send that agent's answers to it; a call that gives no name passes (briefs.17). A landings card of one row is an approval of risk high, not reversible, so it is approved only by holding the button in the Pending You app, never with a key in Herdr's popup; one of two to five rows is one list of boxes carrying highStakes, the same test, and one of more is lists of five; one send lands every bolt left ticked, in the card's order, a note moving one or naming a defect, which main-level ops passes to that bolt's conductor, and crew card read land/<kit> prints the ticked bolts and the crew bolt submit that lands them, after what an earlier send still lands, with or without a card open. A send stands for a bolt's work, not its head: a bolt the user ticked whose head moved only by taking main in, or by its host's copy being brought level with GitHub's, keeps the send, is no row of a later card and lands on it once it reads proven again, its own work being its non-merge commits GitHub's main lacks, read where the kit's forecasts are made; one whose own work changed is a row of the next card, which says the head sent, the head now and the commits gained or lost, or why crew could not tell. Each row's card has its row's form: a proposal's is drawn by crew from the plan and the proposal when crew plan propose accepts it, an approval with a question per five units the proposal makes new to a bolt, each to be cleared to leave it out, and its answers recorded with crew plan answer; a kit's landings card is crew's own, in main-level ops's name, an approval of risk high for one row and a list of ticked boxes for more, whose send has main-level ops land the ticked bolts in its order, each row linking one reading session on what its bolt brings to main, offered and never required, which lands nothing; a batch's is one notice, kind fyi, that says first what it is, names every unit with its team and the reviewer's opening paragraph as prose, asks nothing and links the batch's one reading session, sent back with one tap, its notes the annotations the user sends from that session and the card's own note; a decision record's is an approval of low risk, reversible, with no options or steps; and no card of crew's asks a question in words, which Pending You makes required. A question's form is its asker's. Answering a card wakes its owner, which acts on the user's word; crew closes a row's card itself at the event that ends the row. Under each row's commands, crew rail prints the row's card key (proposal/<n>, batch/<n> or land/<kit>) and whether a card with that key is open, who asked it and the card's id, by which its owner asks Pending You for it; a newer card under a row's key is the row's card, and the older is taken as lost; with none open, it gives the words of the refusal of the row's last post; after the groups, it lists the questions the agents asked the user, each with its key, which names it, its asker and its age, then each card act of an agent's whose reply named no card, then the decision records waiting on the user, each open card under a record key with when it was asked and by whom, and then each open card whose row is gone that its read did not close, oldest first, with the host whose rail read closes it, a record card never among those; then each card its read closed, withdrew, recorded lost or posted, and each batch it closed with no card, and each partition whose cards it could not sweep, with why; then each card session it ended on that read, with its card key (and unit, for an old batch card's), its partition, its host and why, its card closed or its row gone, and each host whose sessions it could not check, with why. When it ended none and checked every host, it says nothing about sessions. A landing's key is its bolt's: crew raises its card once the bolt reads proven, every unit and chore merged, every unit's latest change in a batch whose card the user has answered, sluice green at its head and no fix in flight on it, at the merge's end that finds it so or at a rail read; changes it in place when a merge moves the head, its reading started again on the new head and the new link on the card; withdraws it, held for the fix, when a fix starts on the bolt, and raises it again following the held card once the bolt reads proven again; and closes it at crew bolt land. In a kit whose sluice policy at the bolt's head declares [preview], the bolt's row on its kit's landings card carries what brings a preview of that head up, the bolt branch and its head, and says no preview is held while the card waits; a row whose policy declares none says "no preview", and crew asks sluice for nothing when it raises or changes the row. A batch's card carries, under each unit, what its stages recorded as made, as the run wrote it: until crew runs stages through Flume, the conductor's wait reads made.jsonl in the stage's place's own git directory at each look and keeps a copy of each new line on the team's host, which the batch's raise reads and which goes when the bolt lands or is dropped, a line kept while the card waits on the user changing it in place. A thing a card carries that must run comes up only when the user writes on the card asking for it: its owner, main-level ops for a landings row and the planner for a batch's line, runs crew card preview <key> <thing>, which brings it up through sluice preview on the host of the team holding its work and lists its addresses on the card while it is up, and --done puts it away when the user writes that they are done. crew has sluice let one go too when a merge moves a row's head, leaving nothing asked at the new head, when the row is held or leaves the card, when the bolt lands or is dropped, when a batch's card closes, and at a rail read for one whose card is closed or whose row is gone, sluice's one preview of a revision kept while another of crew's records still names it; the preview lands nothing, and one that failed is said on the card and holds nothing. Each rail read, crew rail and each refresh of the rail tab, sweeps the cards posted on its host, under that host's sign-in, after asking Pending You in crew's own name, never an agent's, whether it still finds each: it closes a row's card whose row is gone, with the event's outcome, a proposal applied or a bolt landed, or withdraws it with why, a proposal or a bolt dropped, or a batch that waits on nothing; it withdraws a question whose asker herdr no longer lists, " ended; ask again if it still matters"; a card that reads "not found", after the host signs in to Pending You again, is lost, and while its row still waits crew posts it again under its row's key through its kind's raise, its summary saying an older copy is dead, which the user dismisses in the app; every row's card posted from a host other than its owner's, the main level's, a kit's landings card's among them, never closed, or recorded lost to its owner on any host, is posted again on its owner's host at its next rail read, through its kind's raise while the row still waits, its summary saying the older copy is dead, and the older copy, which that host's sign-in can't reach, is never asked after nor closed from there; so, on the main level's host, is a decision record's card while its record is still proposed and was not settled in the pane, built again from the record on the kit's main in the design agent's name, but one raised with alternatives, of which crew keeps no copy, is named with the crew record <kit> <number> --proposed --alternatives <file> the design agent runs to raise it again; and it posts a row's card that has none, a post refused or never made, through its kind's raise, which decides whether the kind's point has come. A kind with no raise on a rail read has its rows left as they are, and its lost card recorded lost for its owner to raise again with the command that raised it; a lost card whose row is gone is posted again by nobody. A post or close Pending You refused is tried again ten minutes on, a host not signed in changes nothing and is named, and so is a partition whose run record could not be read from its branch; crew board sweeps nothing. crew learns of its agents' questions from their own sessions: its PostToolUse hook records each one a crew agent posts, updates, withdraws or closes in the run record, on the agent, with the card's id and key and nothing written on the card, and one whose reply names no card as unread.

An agent's own question is the one card it posts: a conductor, the planner, main-level ops and the design agent ask through Pending You's own tools in their sessions, in their own name, under a key of their own, ask/<agent>/<slug>, shaped as they see fit, and crew's card hook records it; a stage agent asks its conductor with crew needs, a team's ops tells its conductor, and a dispatcher asks through the planner. Every other card is crew's own, and the hook refuses an agent's post, change or close under a row's key, of a row's card, or from any other role, naming whom to ask. crew card read <key> prints where the asker's card under a key stands, its status, whose turn it is, and the user's answer and words, and closes an approval the user declined, with their words. The card a key names is the asker's newest posted under it on this host that no close has closed. What Pending You refuses is refused in its words; a host with no sign-in is refused saying the user signs it in with pendingyou-signin.

A proposal's card holds the proposal whole, crew's picture of the change, its text and the case, and links no session, but for a proposal of more than fifteen new units, which the card can't hold and whose card links the session on its page. A card that asks the user to read something else, a batch's changes or what a bolt brings to main before it lands, carries the link to a plannotator session on it rather than a file or a path, so the user reads and annotates it from wherever the card is answered, the phone included. The link is the first thing in the card's words, its summary and its background, but on a batch card and a landing card, whose summary says first what it is and whose background opens with the link, and is among its links; the card's words say what the user decides from in the document's own words, a change's Why and the lead sentence of each of its changes, a proposal's case and changes, a report's findings, and no card carries a path. crew starts the session itself when it raises a batch's card, a bolt's row on its kit's landings card or the card of a proposal of more than fifteen new units, before it builds the card, and puts the link on it; a card whose session could not start is raised all the same, saying its reading could not be opened on the tailnet, why first in its details and in the command's output, and why kept in the run record as Unread on the card's post or change. A bolt's reading is tried once more before that, as crew card session land/<bolt> would: the kit's main fetched on the team's host, the bolt read afresh and its reading opened again, the bolt no row when it no longer reads proven; a row raised without its reading says crew tries it again when the rail is read and names crew card session land/<bolt> as how the bolt's conductor starts it, and the card is then changed to carry its link. A batch card's reading and a long proposal card's are tried once more too, the batch's files written afresh; such a card raised without its reading says crew tries it again when the rail is read and names crew card session <key> as how the planner starts it, and is then changed to carry its link. Each rail read tries the reading of each such card, a batch's, a long proposal's or a kit's landings card, posted on its host that waits on the user, ten minutes on from its last post, change or try, a landings card's by raising it again, which tries each row's reading as crew card session land/<bolt> does, on the team's host with the bolt read afresh, changes the card to carry the link, and lists it opened, or left with why. A try made after the card's raise, by crew card session or the rail's read of a batch's or a proposal's card, is recorded as card.reading in its owner's name, the planner's or the bolt's conductor's, done when it started the reading and refused with why when it could not, and the rail's raise of a landings card as the card's change; a link given again records nothing. crew card session <key> finds the rail row with that key and prints the running session's link, or starts plannotator on the row's document (the proposal's page as crew plan proposed <n> prints it) on the host it runs on, with an Approve button and no browser opened there, and prints the link, the host's tailnet name and a port. Run again while that session runs, it prints the same link and starts nothing. It refuses a proposal's whose card holds it whole, a key with no row, a document on another host, and a link that would open only on the host itself. Nothing of crew's waits on a session or a card: crew card wait is refused at once, naming crew card read <key>. A card's answer wakes its owner through the fleet's wake mod, and each rail read tells the owner of each reading on each host of the partition that the user sent, approved or annotated, and nobody has read, once, through crew tell, naming crew card read <key> and none of the user's words; it marks the reading told once the tell goes through, tells it again at the next read when it does not, and tells nothing of a reading closed with no decision. crew card read <key>, run by the owner, gives the decision beside the card's answer, approved or annotated with the user's words as they wrote them, or closed in plannotator with no decision, and a decision made while nobody read is given by the next read. The owner acts on that decision as the card's answer. When a crew agent closes or withdraws a keyed card, crew's hook ends the session started for its key, and crew ends it when it closes or withdraws a card of its own; crew card end <key> ends one by hand. And every rail read, crew rail and each refresh of the rail tab, ends each session crew started whose card is closed or whose row is gone, on every host of the partition, whoever closed the card, and says which it ended; it runs crew card sweep on each host with what it judged, which is the rail's and not for hand use. It leaves alone every session crew did not start and every one it can't judge: none on a host that does not answer, which it names, none of a closed card and no batch card's while the partition's run record could not be read from its branch, and none started under two minutes before, which a later read judges. crew board ends nothing. crew ends only a process plannotator lists as serving the document it started for that key, and keeps each key's session in ~/.local/state/crew/cards/<label>/<key>/ on the owner's host; when plannotator's list of sessions can't be read there, it ends nothing, keeps the session and says so, and a later rail read ends it. The session's link is plain http on the tailnet: its host from swancloud's PLANNOTATOR_URL_HOST, and its port the first free one of the range the environment's PLANNOTATOR_PORT names, or else of crew's own, 19432–19451, swancloud's agents' range, so a session started from a shell outside any agent takes a free port as one started in an agent's pane does. A batch card has one session, on the whole batch: crew card session batch/<n>, run on the partition's main level's host and refused elsewhere, writes the batch's folder beside its summary, batch-<label>-<n>/, holding the summary and then every unit's Markdown files as the batch read them at their commits, each named for its unit, and starts plannotator on those files as one review, so each opens whole. It refuses a unit with that key, and a batch it can't read whole, naming the unit and its host, with nothing written or started. crew card read batch/<n>, run by the planner on the main level's host once the card's answer wakes it or crew tells it the reading was sent, reads the batch's card and that session together: it prints the card's note and every annotation word for word, even what the user sent while nobody read, and closes the card with what was read ("Read; 2 notes sent to their teams", "Read; no notes"), which ends the session; when the session is sent and no card of the batch is closed on the main level's host, none held there, one lost or one whose close Pending You refused, it records the batch read, crew's own close of it in the planner's name with what was read (batch.close), ending the session when no card was held; with nothing sent yet it says the batch waits on the user and closes nothing. A reading approved with no annotations has no words to pass on, and the rail's read on that host records it read the same way, its card closed "Read; no notes", whichever comes first; one with annotations is recorded read only by the planner's read, which gives them, so no bolt lands before its notes are given. A session closed with no decision leaves the batch on its card, and crew card session batch/<n> starts it again. When crew card session batch/<n> or proposal/<n> starts the reading anew because none runs, it changes the planner's open card in place to carry the link while the card waits on the user, and leaves a card the user has answered as it is, printing the link alone. crew card end batch/<n> ends the session by hand. A batch posted under batch/<n>-<k>, before a batch was one card, keeps a session for each unit it holds: crew card session batch/<n>-<k> <unit> starts one on that unit's change, given its Markdown files, proposal first, rather than its folder, on the host the teams file names for the unit's team; crew card end takes the unit the same way, crew card end <key> with no unit ends each of them, and so does the card's close. Each row of a landings card has one session too, its bolt's reading, on what the bolt brings to main: crew card session land/<bolt>, run on the host of the team holding the bolt and refused elsewhere, naming that host, writes the bolt's reading into ~/.local/state/crew/cards/<label>/land/<bolt>/<head>/ there, a page naming the bolt, its head and the units and chores that land, then each unit's change as the bolt holds it at its head, then the bolt's diff against main, from where it last met main to its head, less its change folders, as text, and starts plannotator on those files as one review; it reads the bolt as its row does, and refuses a bolt that is no row that can land, saying why, and land/<kit>, which has no reading of its own. When a merge moves the bolt's head, crew ends the session on the old head and starts one on the new, and the card, changed in place, carries the new link; when crew card session land/<bolt> starts the session anew because none runs, as after the host restarts, or gives a running session's link again while the run record shows the kit's card standing without a row's reading, it has the kit's open card changed the same way while the card waits on the user, and leaves a card the user has answered as it is, printing the link alone. crew card read land/<bolt>, run by the bolt's conductor on the team's host once crew tells it the reading was sent, gives what the user sent from the reading: annotations, word for word, as notes on the bolt's row, and an approval as landing nothing, since the user's send on the kit's card is the word to land; it leaves the card as it is and sets the decided session aside, so the next crew card session land/<bolt> starts it anew. With nothing sent it says the reading waits on the user, and with no session running it says so, naming crew card session land/<bolt>. The reading ends with the bolt's row, when the bolt lands and when a fix holds it, or by crew card end land/<bolt>; a card of the bolt's own from before, land/<bolt>, closed by the rail's sweep or otherwise, is no word on the row and ends neither its reading nor its preview.

The user reads a partition's constructed and amended changes in batches that span its teams. A unit's change is due each time a construct of it delivers, and stops being due once a batch has held it at the commit that construct left. On each wait of one of the partition's conductors, crew counts the changes due from the run record and makes a batch due at the partition's setting in the teams file (review: every N changes, or hours T since its last batch with at least one due), or at once when a bolt has every unit merged and some unit's latest change outside a batch; it then tells the planner once (batch.due). The planner runs crew review <label>, which starts the reviewer, a main-level role taking no slot and greeted by nobody, fresh in a review tab of the <label> workspace on the main level's host, sent the changes due and how to read each at its commit (review.start). The reviewer writes its summary to ~/.local/state/crew/<label>-main/reports/batch-<label>-<n>.md, as prose with no code block, each unit's section opening with a paragraph of what it does and what the user would most care about, and nothing else; crew review <label> --wait returns its path once it is written, records the batch with each unit at its commit (review.batch), starts the batch's one reading session and raises its one card in the planner's name, keyed batch/<n>, however many units it holds, ends the reviewer and closes its tab: a notice titled by what its units' bolts are for, that says first how many changes there are to read and that nothing is to approve, names every unit with its team and its opening paragraph, asks nothing and links the session, filed in the kit of its first unit's team. The batch's notes are the annotations the user sends from that session and the card's own note, which crew card read batch/<n> gives the planner: the planner sends them, word for word, to the conductor of each unit they speak of, or to every unit's when they name none, saying so, and the conductor runs construct again with them. The user may also answer a batch in their own words in the planner's pane or the operator's, typed there or told from their shell: that agent runs crew card answer batch/<n> --excerpt "<their words>", once for each batch, and crew records the batch answered only when it reads the words in that agent's own session transcript as the user's, never in what the agent wrote, another agent's tell, a tool's output, crew's own message or a word from the board (batch.answer, which keeps no words, only the transcript record they came from and their length). It counts as a tap on the card: the card held on that host is closed answered with the words, one held on another host is closed by the rail's sweep there, saying in whose pane and when, the planner's crew card read batch/<n> then says in whose pane, closing the card it holds, and the bolts the batch held are offered for landing. The words are the batch's notes: crew tells the planner them when the operator ran the command, and the planner sends them on as any notes. A batch answered already, on its card, in its session or in a pane, or one that waits on nothing, is refused. An unanswered card holds no code, but it holds the landing of each bolt whose unit's latest change it holds: a bolt is a row of its kit's landings card, and its rail line carries the word to land, only once each unit's latest change has been in a batch whose card the user has answered; and crew bolt land is refused while a unit's latest change has been in no batch. A batch whose reading session the user sent is answered too, its card's close the record, or crew's own close of it when no card closed: it counts as answered for a bolt's landing, and is no row, names no landing row and has no card raised for it until a newer card is posted under its key. A batch waits on nothing once each of its units has landed, has been dropped from the plan since the batch was made, by crew unit drop, a proposal's drop or its bolt's drop without --requeue, or is held by a later batch, whose card then carries that unit to the user, as when the user answered it in the planner's pane: crew reads such a batch closed from the run record alone, on every read of the rail and the board, so it is no row, crew review --wait raises no card for it and the rail's sweep posts none; the sweep on the main level's host records crew's close of it once, in the planner's name, saying which units have landed, which were dropped and which later batch holds the others (batch.close), before it asks anything of Pending You, and withdraws a card still open under its key with the same words. A batch with one unit that has not landed, was not dropped since and that no later batch holds stays a row until the user answers its card. crew's close is not the user's answer: a bolt still lands only once each unit's latest change has been in a batch whose card the user has answered.

A partition or host without Pending You keeps the rail as it is, and its conductors tell the partition's operator of every wait instead.

A herdr server that restarts resumes each agent in its saved pane folder, which is the folder crew moved the pane to before starting the agent, since Claude finds a conversation only from the folder it began in. crew's SessionStart hook gives a resumed agent its name and identity back, and at each compaction its brief, which such a session keeps only until its first. A main level's design agent, planner, ops, operator or reviewer gets them back only on the host the teams file names for its main level, and crew-role starts one only there: a pane herdr replays on any other host, a standby that once ran the main level, gets no identity, pane name or brief, and is told at each start that it is no agent of crew's there and which host the main level runs on. An agent that never had a message has no conversation to resume, and its pane comes back as a shell, so crew gives every agent it starts a first message: a unit slot its stage's prompt, the reviewer its batch, and every other agent a greeting, a team's ops told who it is, what its team holds and to wait to be told whenever crew up, rebuild, restart, resume, revive or a bolt's give starts it with a new conversation. crew revive, run on a host after a restart, brings back each standing agent of that host whose pane came back empty, from its last conversation or fresh, greets each conductor and each agent outside a team it brought back, and each agent it had to start fresh, and leaves a team or main level taken down with crew down as it is. A pane whose folder was gone when herdr's server started, as a worktree removed since, comes back dead, listed with no terminal behind it: crew up, resume and restart, a stage's start, crew main up, a dispatcher's up, crew console up and crew revive close it and open it again in its workspace, saying so, crew revive then picking up its agent there, and never touch a pane an agent holds. crew sites lists each host's bolts, units and fixes with the URL of each running dev server, named by swancloud's devurl and found among the host's portless routes.

Holding a host, and updates

crew hold <host>|--all "<why>" puts on the brakes before herdr is upgraded or a host rebooted. crew starts no agent on a held host until crew go, and refuses every command that would, saying who held it and why. Every standing agent up there is told to finish the step it is in and start nothing new, and a stage already running ends as it would. crew hold status says what still works on each host: an agent working, one waiting on a question to you, one running background work of its own, a stage not yet ended, crew's tests. crew hold wait waits until each host is quiet and then ends every crew agent there, keeping its panes, so herdr's restart brings back only shells; --now ends them at once. crew go lifts the hold, brings each standing agent back with its conversation through crew, greeted, tells one still up to carry on, and runs each console's tabs again.

crew's code is live on every call, but an agent takes its brief and crew's plugin (its hooks, skills and this band) once, at its start. Each start records the crew it loaded and what it was started with, and a landing or a teams file that changes either makes the standing agents it touches due a restart: crew restarts each at its next stop, once its turn has ended with no question open and nothing of its own running in the background but crew's waits. A conductor starts fresh; every other standing role resumes its conversation and is told what changed. crew's Stop hook catches an agent at the end of its turn, the host's follower catches one sitting idle when crew's checkout or the teams file moves, and crew update does it by hand. Nothing restarts on a held host. Each agent's band shows the crew it started on, and once it is due the version it takes at its next stop.

Seeing what happened

crew events [--label L] [--about <object>] [--since <time>] [--follow] [--json]
crew events --push [--label L]
crew trace  <object>
crew page   <label> [--out <file>] [--since <time>]
crew page   --fleet [--out <file>]
crew unit wait <unit> [--timeout <ms>] [--stuck <ms>]
crew chore wait <chore> [--timeout <ms>] [--stuck <ms>]

Every crew command that moves work appends one entry per act, after the act, to the run record of the partition it acts for, on the host where it ran: ~/.local/state/crew/<label>/runs/<host>/<YYYY-MM-DD>.rec, one recutils file per UTC day, each entry one write, never rewritten. An entry holds:

Id, At (UTC) and Host, where crew ran;
By, the agent crew started that asked (CREW_AGENT), or <user>@<host>, and Session, that agent's Claude session as <host>:<id>, carried with a command crew runs again on another host;
Act, such as unit.add, bolt.give, stage.start, stage.end, tell, team.up or agent.restart; forecast, amendment and unit.rebase, what reached a unit from another; batch.due, review.start, review.batch and batch.close, a partition's review batches and crew's close of one that waits on nothing; the card acts, card.post, card.update and card.close, which crew's hook writes for an agent's card and crew for its own, and card.reading, a try of a batch's, a long proposal's or a landing's reading after its card was raised, done or refused;
On, each object acted on, and From, each object it came from, as typed names: unit/<unit>, chore/<chore>, bolt/<bolt>, queue/<kit>, signals/<id>, team/<team>, agent/<name>, stage/<unit or chore>/<stage>, stage/<bolt>/proof, fix/<bolt>/<name>, batch/<n>;
Commit, <owner>/<name>@<sha>, when the act wrote one, and Why, the subject crew composed from the names of things;
Refused, crew's reason, when a command that would have moved work was refused;
a stage's end's Result (the stage the unit reached), Tasks, Head (the unit's or fix's branch head), Ended (delivered; short, when its agent said what it needs through crew; or stopped, when crew ended its agent first), Delivered, what it delivered as an object (unit/<unit>@<head>, chore/<chore>@<head>, fix/<bolt>/<name>@<head>, bolt/<bolt>@<head> or report/<file>, and proof/<file> in an entry from before a bolt's proof was its verification), and Observed: late when nobody waited for it, a tell's Chars, Amended: yes on the start of a construct that marked its unit amended, whose Commit is the plan's, and Took, the heads of the units it comes after that a construct's new place took; a forecast's Heads (<unit>@<sha> <other>@<sha>), its conflicting Paths and how it Reached the later unit (told, prompt or settle), and a stage start's Forecast, the forecasts its prompt carried; on crew's own unit.after that orders two units a forecast found in conflict, After, the unit it now comes after, or Lifted, the one it no longer does, and Settle, the settle end that decided it; a review batch's Batch and Units (each <unit>:<team>@<commit>), and a batch due's Count; and a card act's Card (the Pending You card's id), Key (its rail row's card key, or its record key) and Unread (why its reading could not open, crew's own message, on the post or change of a card raised without it), on the row's object, on record/<kit>/<number> for a decision record's card, or on agent/<name> for a card with neither key.

No entry holds text anyone typed: not a tell's text, what a stage's agent said it needs, an intent, a goal, a reason or an excerpt. A read writes nothing, and a record that can't be written is said on standard error and changes nothing about the command. recsel -t Entry reads the files with no crew involved.

Every entry reaches the flywheel's branch as it is written: the command that appended it pushes it to runs/<host>/<YYYY-MM-DD>.rec there before it goes on, as a commit of its own from that host, by the one write every state write takes, its subject runs(<host>): <act> <first object> (<agent>) and its Crew-Entry: trailer naming it. Each day's file on the branch is the union by Id of what it had and what the host has, so a host only ever adds to its own files, and one that is asleep or rebuilt loses nothing it pushed. When the push can't be made, GitHub out of reach, the branch not started or a file of the host's failing recfix --check, the command says so once on standard error and does what it would have done; the entry waits in the host's file, and the host's next entry pushes it first, each still a commit of its own. crew events --push pushes by hand what a refused push left, or says nothing is left. crew events reads the run record from the partition's branch alone and prints it in time order, asking no host for it, so a host that is asleep hides nothing it pushed; it names the branch when that can't be read. --follow reads the branch as this host's cache holds it, again whenever its tip moves, reading only the files that changed, and prints each entry once it is there: a write on this host moves the cache at once, and the branch is fetched once a minute, by the host's follower, or by the follow itself for a partition no follower on the host follows, so another host's entry shows within the minute. The console's flow tab runs it. crew trace <object> prints one bolt's, unit's, chore's or signal's history from the entries alone: what was done, by whom, with which commit, what it came from and what came from it, each line with the zoe <session> to open on its host. A bare name is tried as a unit, then a chore, then a bolt, then a signal; report/<file> and proof/<file> find the end that delivered them. crew unit wait <unit> waits on the team's host for the unit's stage to end at its deliverable and records that end. An end nobody waited for is recorded, once and marked late, the next time crew reads the team, but only once its deliverable is there: a stage whose agent has only gone quiet has no end. A stage whose agent crew ends first, to run it again or to free its slot, is recorded delivered when its deliverable is there, else stopped; one stopped short is recorded by crew needs itself.

crew page <label> writes the partition's page, one HTML file that opens on its board: the four lanes crew board reads, Inception, Bolt plan, Construction and Operation, made by the same read at the same commit of <label>/main as the rest of the page, and drawn as the flywheel mockup's phases view draws them: a signal as a quote under who captured it, a proposal as a sheet, a queued unit as a slip, a bolt as a ledger with its units as a chain, a landed bolt as a record, and every rail row a ✓ marker on its object, saying whether its card is open and who asked it, or that it has no card, its post refused, Pending You's words shown when the marker is pointed at. The lanes sit side by side on a desktop and stack under 760 px, as on a phone, and the page follows the viewer's light or dark preference. A strip under the header shows each host the board asked, one that did not answer marked, each team of the partition with its host, in the teams file's order, and what needs attention. A click on any item of the board, or Enter on it, opens its dock: one panel over the right of the board, which does not move under it, its head in the item's form, holding the item's details as the page's data and lineage hold them, its markers in the board's own words, each item it names that the page draws a link that opens that item's dock in its place, with a back control along the way it came, and its history from the run record as crew trace walks it. A team opens from its pill in the strip or its name on a ledger or a landing, and the Claude account its session runs on opens from the team's dock, listing the partition's sessions on that account; a deploy opens the same dock from the Operation lane and from the deploys view. Esc, the dock's × or a click outside closes it, and under 760 px it fills the screen with its back control. The dock open is kept in the page's address (#dock=<key>), so a reload, or a page written over this one, opens it again, and none is opened for an item the page no longer holds. The header's team control narrows every lane but that strip to one of the partition's teams; the choice is kept in the page's address (#team=<name>) and in the browser for that partition, so it survives a reload and a page written over this one. The header names every partition in the teams file, and each other one links to its page in the layout of this page's own file: ../<label>/page.html in crew's, ~/.local/state/crew/<label>/page.html or the same under another folder; <label>.html beside a page written as <label>.html, as swancloud's board serves the pages side by side; ../<label>/<label>.html when both the file and its folder are named for the partition; and none, which the command says, for a page whose file and folder are not named for it, since crew cannot tell where the others are. Before the partitions the header links to the fleet page in the same layout: ../page.html from crew's <label>/page.html, index.html beside a page written as <label>.html, and none in any other. Each dock ends with a one-line field for a word to the item's agent, saying whom it goes to: for a bolt, a unit or chore, or a fix, the conductor of the team holding its bolt, else the partition's operator; for a proposal, the planner; for a signal, the design agent; for a landing, a deploy or an operation, main-level ops; and for a team or a subscription, the operator. Send posts the word to the page's own address, word beside it, where swancloud's listener on the board's host hands it to crew tell --board, and the dock says what came back: sent to <agent>, the field emptied, or crew's words for why nothing was sent, the word left in the field; when the listener does not answer, that nothing was sent; and a page opened from disk sends nothing. The board and its docks answer nothing: a dock has no control that answers or moves anything, a word from it answers no card, and its card is answered on the rail. Making the page asks every host of the partition for its kits, as crew board does.

crew page --fleet writes the fleet page, every partition of the teams file at once, made from the one read crew board makes of all of them, one file that loads nothing, in the partition page's colours, light or dark as the viewer prefers, its partitions side by side on a desktop and stacked under 760 px. Each partition is a block saying the commit of its plan it was read at, and holding: where it runs, each host its teams and main level run on, one that did not answer marked, and under each host the herdr sessions its agents run in, each naming its teams, its design agent, planner, ops and operator and its dispatcher there, with the Claude account the hosts file gives the session, or that it names none; its kits, each with the teams building it, its main's last landing in the run record's window of seven days (the bolt, the commit main then held, when and who landed it, or none since the window's start) and what is queued for that main, the bolts that wait to land with their landing card open or none, those in construction, and how many bolts are planned and units queued; its teams, each with its host, session and account, the bolt it holds with its units' pips, how many have merged and whether it waits to land, each slot at work on a stage (read from the run record's stage starts and ends), holding work with no stage running, or free, how many are at work, and what its conductor waits on, the stages running, the landing on the user's word, or nothing; and what needs attention, in the board's words, with how many of its cards are open. Above the partitions the page shows each Claude subscription, every account the hosts file gives a session and every account a host published a reading for, by name: its five-hour and seven-day use, each the percentage used and when it resets, and its weekly use by model where the reading gives it (Opus, Sonnet, and each model the server names, such as Fable), exactly as the host holding its sign-in published them, a figure the reading leaves out said not given, each in words and a plain bar, never graded, summed or coloured by level; which host read it and how long before the page was made, and every other host's reading with its age or its own words for why it could not read, a subscription with no reading made saying its use could not be read and one no host published for saying so; and beside its use, computed from nothing of it, the sessions on it by host, each with crew's agents in it and each team's slots at work and what its conductor waits on, a session that runs no crew agent said so, and the partitions whose agents run on it. The use is read from ~/.local/state/crew/usage/<host>.json on the host the page is made on, one file per host in the shape Claude Code's /usage reading names, {"host": ..., "readings": [{"account", "at", "five_hour", "seven_day", "seven_day_opus", "seven_day_sonnet", "model_scoped"}, or {"account", "at", "unread"}]}, which swancloud's reader writes on the board's host; crew reads no host and no credential for it, and checks each file before it uses any of it, a file it cannot read named on the page with what is wrong and the rest shown. Each partition's name links to its page and each team to its dock there, in the layout of the fleet page's own file: <label>/page.html beside it written as page.html, crew's own, by default ~/.local/state/crew/page.html beside the partitions' folders; <label>.html beside it written as index.html with --out, as swancloud's board serves the pages; and none, which the command says, for any other name. The command prints the path, then as of when and which commit of each partition's plan, then each host or plan that did not answer, by partition, then each published file whose use it could not read, with why, and that no subscription's use is published when the folder holds no file, and writes the page all the same; like the board, it answers nothing.

The page's flow view, one switch away, draws the partition's lineage: its signals, agenda items, proposals, units and bolts as columns in that order, a line from each to what it led to, a timeline of the entries per day beneath, and each object opening to its history, the entries crew trace prints for it, each with who did it, on which host, with which commit, and the zoe <session> to open. Selecting an object marks everything it came from and everything that came from it; a filter hides closed and landed work, and a box narrows by name. Which objects there are, how they are linked and in what order things happened are read from the run record alone, by the walk crew trace makes, so the page and the trace cannot disagree; labels and present status (a signal's assertion and move, an item's subject, a proposal's case, a unit's intent and stage, a bolt's goal and team) are read from the flywheel's branch at the commit the entries were read at, and an object the branch no longer holds, such as a landed bolt's units, is labelled from its newest entry. The file holds its data, style and script and loads nothing, so it opens from disk with the network off; the one request it makes is a dock's word, posted to its own address when the user sends it. It is written whole to ~/.local/state/crew/<label>/page.html on the host where the command runs, or to --out, and never committed; the command prints its path, then as of when and which commit of <label>/main it was drawn from, then each host whose kits did not answer, whose units' and bolts' stages the page leaves blank; its run record is the branch's, whole. --since draws only the entries from then on. When the branch can't be read, no page is written and an earlier one is left as it was. The page's deploys view, a third switch, draws each environment's deploys as a timeline over the same window, oldest at the top, so the sequence of what was approved, replaced or left waiting reads down it: each deploy with the commit it moved from and to, the user's word on it as its card's answer recorded it, its steps, the suite's checks and its outcome, the bolts it carried, each with the proposals the lineage joins to it, which say what the deploy brought, and the after-deploy steps of its commit with their doers and states, then the operations waiting on the environment; it is read from the ops entries of the main level's host and the landings, as the board's Operation lane is. Nothing reads the page and making it appends no entry: it is a view, made again to refresh it. The operator agent makes it and opens it beside its pane when asked to show how work flowed.

Roles

role	definition	model	effort
design agent	`design.md`	Fable 5.1	xhigh
planner	`planner.md`	Fable 5.1	xhigh
conductor	`conductor.md`	Opus 5.5	high
ops, team and main level	`ops.md`, `main-ops.md`	Opus 5.5	high
unit: construct	`construct.md`	Opus 5.5	high
unit: code, settle, merge; chore: code, merge; fix	`coder.md`	Opus 5.5	xhigh
unit and chore: verify	`verify.md`	Opus 5.5	high
reviewer	`reviewer.md`	Opus 5.5	high
dispatcher	`dispatcher.md`	Opus 5.5	medium
operator	`operator.md`	Opus 5.5	medium

A definition's frontmatter names its model and effort; a team or a partition overrides either in the teams file under roles.<definition>. crew-role starts each role with them and appends the definition's body, filled from the teams file, to Claude Code's own system prompt. python3 plugin/lib/crew.py brief <team|label> <definition> prints a brief.

Needs

herdr, jq, python3, git, and recutils for the plan; in each kit wt, sluice with its wt-submit, which worktrunk runs as wt submit, moon and openspec; devurl and portless for crew sites. crew's own toolchain is devenv's system tools, jq, recutils, proto and git-cliff, with convco for the commit-msg hook entering the shell installs, and the application tools .prototools pins, which entering the shell installs when one is missing, and activates: moon, and Python at the minor every host runs crew on, with uv; the tiers' venv task syncs pytest from tests/uv.lock into tests/.venv before every run of them, with the uv moon's toolchain gives, since moon's own install is skipped under --force, as sluice runs.

tests/run [name...] runs crew's tests one after another on stub herdr, ssh, claude and wt submit, each simulated host with its own scratch home, so no test reaches a real session, host or agent. tests/suite runs them as moon tasks, one per test file, each running its test through tests/run, side by side; a test whose inputs are identical to a run that passed on the host, in any worktree of crew, is replayed rather than run again. tests/suite --affected runs only the tests a change affects, against the merge-base with main and counting uncommitted edits, tests/suite <name>... the ones named, and tests/suite --force runs without replaying. An agent runs the tests that prove what it changes by name while it works and --affected once before its merge, never the whole suite by hand: sluice runs every check-full task afresh on each submission to a bolt and to main, as crew's .config/sluice.toml requires. Every test waits for one of the host's test slots (tests/slot), its cores less two unless CREW_TEST_SLOTS says otherwise, shared by every worktree on the host. The tasks are tests/moon.yml, written by tests/moon-tasks from the test files with each task's inputs: crew's command core (plugin/bin/ and the modules plan.py and crew.py import) and the common files, and whatever else the test's outcome depends on, named on a # Reads: line of its opening comment; after adding or removing a test, or changing what one reads, run tests/moon-tasks and commit tests/moon.yml, since tests/suite refuses to run while they are out of step. Both run in crew's devenv shell, and enter it themselves when started outside it; crew's other tools run through it per command, devenv shell -- <command>, and a terminal enters it with devenv shell, or direnv with the checkout's .envrc. crew's mod has its own cases, plugin/tests/*.test.ts, run as the task mod by tests/mod, which runs them with claude plugin test plugin: Claude Code's test kit, with no session, model, sign-in or network. claude plugin test takes no option before plugin, so where claude is a wrapper that adds its own, tests/mod runs the program the wrapper's last exec names, once it answers --version as Claude Code; CREW_TEST_CLAUDE names another. The live crew sites check on mac-studio is no task: CREW_TEST_LIVE=1 tests/run sites-live runs it.

Name		Name	Last commit message	Last commit date
.claude-plugin		.claude-plugin
.claude		.claude
.config		.config
.github/workflows		.github/workflows
.moon		.moon
docs		docs
openspec		openspec
plugin		plugin
tests		tests
.envrc		.envrc
.gitignore		.gitignore
.prototools		.prototools
.versionrc		.versionrc
CLAUDE.md		CLAUDE.md
README.md		README.md
adrs.toml		adrs.toml
cliff.toml		cliff.toml
devenv.lock		devenv.lock
devenv.nix		devenv.nix
devenv.yaml		devenv.yaml

Navigation Menu

Repository navigation

About

Repository files navigation

crew

Teams

The plan

Proposals

State

Signals

The main level and the console

Operations

Holding a host, and updates

Seeing what happened

Roles

Needs

About

Releases

Packages

Contributors

Languages

Latest commit

History

Folders and files

Repository files navigation

crew

Teams

The plan

Proposals

State

Signals

The main level and the console

Operations

Holding a host, and updates

Seeing what happened

Roles

Needs

About

Resources

Stars

Watchers

Forks

Releases

Packages

Contributors

Languages