Watching BoB Work

One run, four layers. In BoB in One Day you watched a run with bob warp status and bob warp viz. Those show the run. This tutorial keeps one run going and climbs from it to the project around it, the machine under it and the fleet it belongs to, one view at a time. Every command below comes from Watching BoB Work, which also explains what each view reads.

← Tutorials · docs home

What you will do

Stop	Layer	Question it answers
1	—	Start a run to watch
2	The run	What phase is it in, and how did it get there?
3	The project	Is this project set up to be worked on?
4	The machine	Does this machine run the BoB it thinks it does?
5	The fleet	Is every machine alive and reporting?
6	When something is wrong	Is a hook failing, is GitHub down, what did it cost?

Then a table that maps each question you will ask to the one command that answers it.

Allow about an hour. The run works the whole time; you only look.

Before you start

• Finish BoB in One Day first. This tutorial reuses its hello-bob project, and needs nothing from the later tutorials.
• One approved requirement in hello-bob. Open Claude Code there, file a small one with /requirement (for example "The greeting names the day of the week"), say yes when it asks whether to approve it, and /exit.
• A browser on this machine for bob warp viz and bob viz.
• Nothing to fix. Every view in this tutorial only reads. If one reports a problem, note its next: or Fix: line and carry on; the tutorial does not need you to fix it.

---

Stop 1. Start a run to watch

From the hello-bob directory, in a plain shell:

bob warp start --level 3 --session hello-bob-watch

What you should see.

• The preflight verdict (PASS), then the session name hello-bob-watch, its tmux attach line and a viz URL.
• The shell prompt comes back at once. The run keeps working in tmux.

What just happened. The run lives in the tmux session, so it keeps going while you run every other command in this tutorial from the same shell.

Checkpoint. tmux ls lists hello-bob-watch.

Stop 2. The run

bob warp status
bob warp log
bob warp viz

Run the first two lines, then the third. Leave the browser tab open.

What you should see.

• bob warp status prints WARP DRIVE ACTIVE, then Phase: (for example coding), Issue: with your requirement's number, Chunk: and Preflight: PASS.
• bob warp log prints one numbered row per transition: the phase, the event that caused it, and the time. The last row's phase is the one bob warp status shows.
• bob warp viz opens a page with the run's phases as a graph and the current one highlighted.

What just happened. All three read the run's one state file, .claude/.warp-drive-state.json. The run writes it at every phase change, and every view reads the same copy, so they cannot disagree.

Checkpoint. The phase in bob warp status, the last row of bob warp log and the highlighted node in the viz are the same phase. If the run moved on between commands, run bob warp status again: all three still agree.

Stop 3. The project

bob status
bob status --scope project
bob dash status --projects-only
bob dash serve --list

What you should see.

• bob status prints four blocks: a host line, a project hello-bob line with its last bob ready verdict and how long ago it was graded, a fleet line, then running here: with warp-drive run hello-bob: <phase> on #<issue> and the dashboard's URL. It ends with next: bob warp status, because a run is going here.
• bob status --scope project prints a table of sections (project, readiness, rituals, backups), then one line per bob ready step: ok, no-op or would, each with what it checked.
• bob dash status --projects-only lists the projects on this machine. hello-bob shows its linked commands, hooks and agents, and a ready: line.
• bob dash serve --list lists hello-bob as running, on the port its viz URL uses.

What just happened. The front door read cached verdicts only, so it was fast and made no network call. The project scope graded the project live, as a dry run: a would line is something bob ready would do, not a failure. The dashboard server in the list is the one bob warp viz started; one server per project serves its viz and its dashboard.

Checkpoint. The running here: line in bob status shows the same phase as bob warp status.

Stop 4. The machine

bob status --scope host
bob doctor

What you should see.

• bob status --scope host prints one section, host, with its verdict (ok), then the probe's lines.
• bob doctor prints the same probe: PASS lines for surfaces, symlinks, project links, toolchain and settings_hooks, then INFO lines, among them version (the release and the commit this machine was deployed from) and snapshot timer.

What just happened. Every bob command you ran today executed the copy of BoB in ~/.claude. The probe checked that copy against the commit it was deployed from. INFO lines are reported but never graded: behind source says the source checkout has moved on since the deploy, which is normal and never drift. The run in tmux kept working while you looked; a probe changes nothing.

Checkpoint. bob doctor exits 0 with every check PASS. If one fails, its Fix: line names the command; note it and carry on.

Stop 5. The fleet

bob status --scope fleet --no-live
bob viz
node ~/.claude/scripts/fleet/snapshot-timer.js status

What you should see.

• bob status --scope fleet --no-live prints Fleet audit, then one row per machine: MACHINE, ROLE, STATUS, AGE and PROJECTS. Under the table, a summary line counts machines that never published, that are stale and that are unreachable, with a fix: line when any are.
• bob viz opens a page with one tile per project on every machine. The hello-bob tile on this machine shows the run.
• The last command says whether the snapshot timer is installed on this machine and how often it fires.

What just happened. Each machine publishes a snapshot of itself, on a timer. The fleet view reads those snapshots, so a machine is only as current as its last one. cached means under a day old; cached(stale) means older, so the machine is off or its timer stopped; never means it has never published. Run the first command again without --no-live: this machine's row turns live, because it is measured now instead of read from the cache.

Checkpoint. Without --no-live, this machine's row is live. In bob viz, the hello-bob tile shows the same phase as bob warp status.

Stop 6. When something is wrong

Every layer can report OK while a run still struggles. Three views say why. First, the steps a session had to do by hand:

bob dash status --projects-only
node ~/.claude/scripts/warp-drive/harness-defect-summary.js state .

What you should see. For a clean run, no ⚠ harness-defects: line under hello-bob in the dashboard, and harness-defects: none from the summary script. A run that compensated for a hook prints a line such as harness-defects: 1 open (3 recurrences).

What just happened. When a hook that should advance the run does not fire and the session does the step itself, the run records it with a fingerprint. The same fingerprint on several runs, or on several machines in the fleet view's Harness defects table, is a BoB bug worth reporting.

Next, GitHub:

bob forge health
echo $?
bob forge queue status

What you should see.

• bob forge health prints forge: operational with its reason, then quota: lines for each GitHub API with what is left and when it resets, and spent by: with the calls each project made.
• echo $? prints 0.
• bob forge queue status prints the queue's path and (empty — nothing awaiting replay).

What just happened. The verdict came from the outcomes of the real gh calls this machine made, not from a guess. The exit code carries it: 0 operational, 3 degraded, 4 unreachable, 5 unknown. When GitHub is down, a run keeps working and queues the writes it cannot make. bob forge queue status is where you would see them waiting.

Last, cost. Wait until the run in tmux has finished (bob warp status reports no active run), then run one of these: the first inside Claude Code in hello-bob if the token-report skill is provisioned there, the second from the shell:

/token-report

node ~/.claude/scripts/warp-drive/token-report.js --last 1

What you should see. A Token Usage Report with three tables: By Project, Last 1 Sessions and Totals. The last session is your hello-bob run, with its tokens and estimated cost.

What just happened. The run recorded its tokens at each chunk and wrote its total when it ended. While a run is live, the Segment: line in bob warp status shows the tokens used so far.

Checkpoint. bob forge health exits with the code its verdict names (0 for operational), and the token report lists your hello-bob run as the last session.

---

Which view answers which question

When you want to know something, open the one view that answers it:

Question	Command
What is the run doing right now?	bob warp status
How did the run get here?	bob warp log
Is the loop stuck?	bob warp status --watch (the phase and chunk stop moving)
Is everything OK, and what do I run if not?	bob status
Is this project ready to be worked on?	bob status --scope project
Is this machine drifted from its deploy?	bob doctor
Is the farm alive?	bob status --scope fleet (its row is cached, not cached(stale) or never)
What is every project doing, everywhere?	bob viz
Is a hook failing silently?	bob dash status --projects-only (a ⚠ harness-defects: line)
Is GitHub answering?	bob forge health (the exit code)
Are writes waiting for GitHub?	bob forge queue status
What did this cost?	/token-report

---

Where you are now

You watched one run from four layers without changing anything: the run's own state, the project around it, the machine under it and the fleet. You also know where to look when a hook is failing, when GitHub is down and what a run cost. Each layer has one view you open first: bob warp status, bob status, bob doctor and bob status --scope fleet. When the run finishes, bob warp status reports no active run, and the bob status front door stops listing it under running here:.

Where to go next

• Watching BoB Work: what each view reads, and why none of them changes anything.
• bob status: every scope, section and exit code.
• bob viz: what the fleet page draws.
• Fleet Snapshot Timer: installing the timer on a machine that shows never.

Next tutorial: Coming Back to a Project — The first hour back on a project after time away, as a fixed routine: machine, catch-up, your todos, the plan, the records, memory, rituals and the farm — then one ranked choice.