What running means on the board

Running on the Rig board is not a mood. It means Rig started a process (or adopted one it knows how to supervise) and is still watching that pid. Healthy means the checks you configured — or the defaults Rig attached — are passing. Needs you means something concrete failed: port conflict, crash loop, bad config, or a dependency that never came up.

Agents should ask for status instead of assuming green. Humans should too. The whole point of a local control plane is that the board is allowed to disagree with your memory of “I started it earlier.”

Running vs healthy vs needs you

These states look similar from across the room and are not interchangeable.

Running answers: is there a live process under Rig’s supervision for this row? If you started Vite outside Rig in a random terminal, the board may not claim it. If Rig started it and the process exited, the row should stop saying running — even if a browser tab still shows an old page.

Healthy answers: does the service respond the way we expect? An HTTP health check that returns 500 is still a running process. A managed Postgres that is up but rejecting connections is a different failure mode than “never started.” Health-aware start order exists so later processes wait for earlier ones; a blocked check stalls the chain on purpose. See Health-aware start order.

Needs you (and the Attention board) answers: should a human or an agent stop guessing and look? Failing HTTP checks, crash loops, stuck ports, and deps that never became ready land here. The menu bar reflects the same idea at a glance — overall project health and when something needs attention.

Why vibes-based green is expensive

The old workflow is muscle memory: “I ran npm run dev after coffee, so it is fine.” That fails in predictable ways:

The process died twenty minutes ago and the terminal scrollback is buried under a build.
Vite moved to another port after a conflict; the bookmark still hits the dead one.
The API is up; Postgres never was; every request looks like an app bug.
Cursor restarted “the project” by killing a pid it guessed wrong.

A board that only paints green because a start command was issued once is theatre. Rig’s job is to keep the supervision story honest: started under us, still alive, checks passing — or not.

How agents should read the board

When MCP is linked, editors should call status and health tools instead of inferring from chat history. A good agent loop looks like:

Ask what is running for this project.
Ask health / Attention if anything is red.
Restart only the failed process, not the entire group, unless the group is the unit of recovery.
Re-check instead of declaring victory after one restart.

That is why MCP is not a pasted terminal and why project-scoped tokens matter. An agent with a vague shell and a vibes-based “it should be up” will thrash your ports. An agent that reads the same states you see on the board can restart Horizon without touching Vite.

Edge cases that confuse people

You started it outside Rig. The process can be alive and invisible to Rig’s “running” definition. Either add/start it through Rig or accept that the board will not claim it. Mixing both is how mornings get two copies of the same app.

Healthy but wrong. A health endpoint that always returns 200 on an empty stub will stay green while the real feature is broken. Health checks are not product tests; they are liveness/readiness for the control plane. Point them at something that fails when the service is useless.

Running but unreachable. Firewall, bind address, or HTTPS mismatch can leave a process up while the browser fails. Check the port owner and the URL Rig opens — especially with local HTTPS or Valet/Herd hosts beside Node.

Group started, one sidecar red. The group can be partially up. Read the process table, not only the group badge. Restart the red row; do not assume “start group again” is the only fix.

Stale browser tabs. A tab is not a health check. Close it or hard-refresh after a port reclaim.

A practical morning read of the board

Open Rig before you open six terminals.
Start the group you actually use (or resume what Continuity restored).
Scan red / Needs you first — Attention board before Slack.
Confirm ports match the URLs you will share or bookmark.
Only then link or re-link MCP if the hub was down after an OS update.

If everything is running and healthy, you are allowed to ignore the board until it nags you. That is the point of a quiet control plane — not a dashboard you stare at for sport.

What to do when the board and reality disagree

Trust the board enough to investigate, not enough to panic.

Process says running, curl fails → check bind address, HTTPS, and whether you are hitting the right port.
Process says stopped, something still answers on the port → reclaim; something else owns it (reclaim a port from the board).
Health fails on boot → look at start order and database containers before rewriting app code.
Agents insist it is fine → make them call get_status / health tools; past chat is not instrumentation.