Feature/Fleet
Every slot on every machine, live.
The Fleet page is where you watch and steer the Code Sentinel orchestrator and the worker slots it dispatches from GitHub issues. Nautelle drives the orchestrator; it does not replace it, and it never picks an issue or a slot’s model for it.
Start, stop and status
Operators start the orchestrator with start, for a new round, or next, for the next queued issue, with a model and a permission mode. Stop kills only the orchestrator’s own tmux session; workers keep running.
- The runner launches it as an argument list, never a shell string
- Start is refused with a reason: runner offline, no profile, already running, or a stop budget used up
- bypassPermissions is admin-only, and the choice is audited
- Refresh status asks the runner without typing into the session
Slot statuses you can trust
A slot’s status is derived from its session, pane, worktree and pull request. A source badge says how far to trust it: events from the plugin, scraped from its boards, or both.
- Each row shows the issue, status, last checkpoint, pull request with checks, and age
- The slot sheet shows the brief, branch, worktree, file fence and checkpoints
- prompt and quota also raise notifications
- dispatchedBrief written, session not up yet
- runningThe agent is working
- idleAlive, not working
- promptA dialog waits on a person
- quotaThe usage limit banner is up
- staleSession gone, unmerged work left
- endedPR merged or worktree gone
Live pane, messages and terminal attach
Every member of the project can watch a worker’s terminal, read-only. Operators can message a worker; admins can attach a real terminal to answer a prompt it is stuck on.
- The pane is captured once a second, only while someone is watching, and is never stored
- Strings that look like secrets are masked on the runner before they are sent
- Message worker writes your text into the slot’s worktree and tells the worker to read it
- Attach opens read-only; Take control is explicit, idle-limited and audited, and nothing is recorded
● Reading src/billing/invoices.ts ● Running bun test billing 42 pass · 0 fail GITHUB_TOKEN=••• ● Writing .orchestrator-reply.md
The queue the orchestrator sees
The Queue page shows the project’s ready-labelled GitHub issues the way the orchestrator triages them: in flight, blocked by a person, blocked by other work, missing a spec, or ready.
- Each row says why, and what would clear it
- Ordered by priority label, then by lowest issue number
- GitHub stays the editor; the only write is filing a new issue
Where it sits in the chain
The whole chainSpans the chain. The fleet runs GitHub-issue work in parallel to the Board lane, and its slots show on the Board next to your cards.
- 01Say what you want
- 02Interview
- 03Card, split or stack
- 04Design
- 05Run
- 06CI
- 07Merge
Every screen and setting, in the fleet guide.
The guide covers each control, limit and rule on this page, with the exact names you will see in the app.