The ship

Proposed design

These scenarios walk through the design: the roles and rules are in its model, and the terms in its glossary. The Captain and the Coordinator are not shipped yet. Each scenario ends with the features it still needs and whether cyberlegion or cynapse already provides them.

A ship is a project. Its home is the project’s main checkout, and it opens as one herdr workspace with three tabs. The Command Center is a second kind of workspace with two tabs: it holds the one Operator and the fleet-level roles. Both open on a Dashboard. The scenarios in this section all happen on these layouts:

• Work from a ship’s remote pane: the Council asks the one Operator for work from inside a ship.
• Work from the Command Center: the Council asks the Operator directly, and the Operator relays to the ship’s Captain.
• Landing a pull request: a Pod’s pull request reaches trunk through the Coordinator.
• Work across ships: a Captain needs work from another ship.
• Captains in dispute: two Captains disagree, and the dispute needs settling.

The crew

Automaton	Seat	Model tier	Starts	Job
Council	Wherever you are	Human	—	Gives directions and makes decisions. All authority starts here.
Operator	Command Center Dashboard, left pane. There is one.	Mid (Sonnet)	With the Command Center	Your voice to the fleet. Answers status itself and relays work and orders to the target ship.
Captain	A ship’s Bridge, left pane. One per ship, plus one for the fleet on the Flag Bridge.	High (Opus)	On demand	Decides. Judges a request’s freshness, priority, and scope, owns the issue tracker and the plan, spawns and manages Pods, reviews what landed, and rules on escalations. The fleet’s Captain makes the roadmap and cross-ship decisions.
Coordinator	A ship’s Bridge, right pane. One per ship, plus one for the fleet on the Flag Bridge.	Low (Haiku)	On demand	A ship’s lands pull requests: it applies the clean bar, orders rebases, merges clean work, and escalates judgment. The fleet’s does the mechanics for the fleet’s Captain, for issues in the fleet’s tracker.
Pod	Its own herdr workspace and git worktree	Set per Pod by the Captain	Spawned by the Captain, or by a Pod for a gate	Carries one line of work (implementation, judge, refactor, audit) in one mission.
Mediator	Cold	High	Per dispute	Writes a brief of a dispute. Decides nothing.

A ship has no Operator. The Dashboard’s left pane is the remote pane, a mid-tier session for talking to the one Operator and directing traffic from inside the ship. The fleet’s Captain is admiral-like, and is still called a Captain.

The tiers follow how often each role acts and how much each action matters. The Captain takes few turns, and each one changes the plan. The Coordinator takes many turns, and most are a check and a command. The Operator holds a conversation. Starting the Captain and the Coordinator on demand means the Opus session costs nothing while there is nothing to decide.

Where the Council talks

Each pane is a place to talk on purpose. The remote pane and the Operator’s seat are the mid tier. Talking in a Captain’s pane is a deliberate choice to spend the high tier. The Coordinator’s pane is where you speak to the landing directly.

You start a Captain by invoking /captain in that Captain’s pane. The session becomes the Captain and takes its lease. Anywhere else, /operator and /captain call the existing automaton and never make the calling session one: the session passes your words, verbatim, to the role by mentioning its handle, and shows the reply.

Orders travel as they do today (authority-governance §3). Wherever you give an order, the automaton that receives it relays your words, verbatim and as a turn, to the unit that acts, unless it is that unit.

The layouts

flowchart TB
subgraph dash["Tab 1: Dashboard (main checkout)"]
  direction LR
  rp["Remote pane<br/>Sonnet, calls the Operator"]
  ui["Status UI<br/>issues, PRs, SDD-missions, CI"]
end
subgraph bridge["Tab 2: Bridge (main checkout)"]
  direction LR
  cap["Captain session<br/>Opus, on demand"]
  coord["Coordinator session<br/>Haiku, on demand"]
end
subgraph engine["Tab 3: Engine Room"]
  direction LR
  sb["Storybook"]
  site["Docs site, dev server"]
end
subgraph pods["Pod workspaces, one git worktree each, spawned by the Captain"]
  direction LR
  p1["Pod A"]
  p2["Pod B"]
end
rp ~~~ ui
cap ~~~ coord
sb ~~~ site
p1 ~~~ p2
dash ~~~ bridge ~~~ engine ~~~ pods

One herdr workspace per ship, three tabs. Pods open in their own workspaces, nested under the ship.

flowchart TB
subgraph cdash["Tab 1: Dashboard"]
  direction LR
  op["Operator's seat<br/>Sonnet, the one Operator"]
  fleet["Fleet status<br/>across ships"]
end
subgraph flag["Tab 2: Flag Bridge"]
  direction LR
  fcap["Fleet's Captain<br/>Opus, on demand"]
  fcoord["Fleet's Coordinator<br/>Haiku, on demand"]
end
op ~~~ fleet
fcap ~~~ fcoord
cdash ~~~ flag

The Command Center, one per fleet, two tabs. Its roles are the fleet's own.

Every layout is a template slot you can change.

Dashboard (ship)

The first tab, running in the main checkout. The default puts the remote pane on the left, where you talk to the Operator and direct traffic, and a status UI on the right that shows the ship’s issues, pull requests, and status. The UI is any program that renders that state, such as a refreshing cyberfleet status view until the mission TUI replaces it.

Bridge

The second tab. The Captain’s session is on the left, and the Coordinator’s session is on the right. Both panes stay empty until something needs them. You start the Captain with /captain in its pane. When a post that needs an answer mentions a Captain or a Coordinator that is not running, the mention starts it through its lease, so a ship you only ask questions of never starts an Opus session.

Engine Room

The third tab, for long-running processes the work needs: Storybook, the docs site, a dev server. These are processes for the main checkout, not agents. A Pod that needs a preview of its own branch starts one in its own worktree.

Command Center

The Dashboard holds the Operator’s seat on the left and fleet status on the right. The Flag Bridge holds the fleet’s Captain on the left, where the fleet’s roadmap and cross-ship decisions are made, and the fleet’s Coordinator on the right. Both start on demand.

Missions and their channels

The fleet’s roles sit on the tracker’s levels, read from the tracker and never inferred.

Tracker level	Fleet role	Channel
Issue, with any sub-issues	Mission: an issue in flight. One Captain, one lease. It may land several pull requests and ends when the Captain closes the issue. It may have sub-missions, and may be blocked by a mission in another ship.	The mission channel
Subtask: not releasable on its own	A line of work in a mission, carried by Pods	A thread on the mission channel, holding its SDD-mission’s ledger

Everything is a mission. A Captain adds sub-missions to break work down. Crossing a repository boundary makes the work a dependency: a mission in the other repository that blocks this one, because each repository releases on its own.

The automatons talk over cynapse channels, like channels in Slack or Discord. Missions, a ship’s queue, and threads have channels; roles do not. A role is reached by mentioning its handle: cyberlegion/captain, cyberlegion/coordinator, operator, fleet/captain, cyberlegion/pod-7a. The ship’s part of a handle is the repository name. An exchange that needs different readers from its parent is a thread: a child channel anchored at the entry that starts it. A line of work, a gate (whose cold judge reads only its thread), an escalation with its ruling, a dispute, and an item in the ship queue are threads. Every thread posts its outcome back to its parent, so a reader of the parent never has to open it.

flowchart TB
op["Operator"]
cap["Captain"]
coord["Coordinator"]
pod["Pod"]
mission[("mission channel per issue<br/>members: Operator, Captain")]
queue[("ship queue<br/>members: Captain, Coordinator")]
lane[("line-of-work thread<br/>holds the SDD-mission ledger")]
thread[("gate, escalation,<br/>dispute threads")]
qthread[("queue thread<br/>one per pull request")]
rp["remote pane or any other pane"] -- calls, with the Council's words --> op
op -- the Council's words verbatim, mention the Captain --> mission
mission -.-> cap
cap -- outcome, mention the Operator --> mission
mission -.-> op
cap -- opens --> lane
pod -- progress, done report --> lane
lane -- outcome --> mission
pod -- opens a gate or escalation --> thread
thread -- outcome --> mission
pod -- PR ready --> qthread
cap -- tracker mechanics --> queue
qthread --- queue
queue -.-> coord
coord -- landing talk, settled-queue report --> qthread
coord -- escalation between pull requests --> queue

Who posts where. Solid arrows post; dotted arrows read.

Channel	Members	Carries
Mission, one per issue	The Operator that brought it and the ship’s Captain; each Pod joins its own mission’s	The Council’s words as the first entry, the plan, decisions and rulings, the delegation record, and the outcome. For a mission with sub-missions or blockers, only what crosses them: the plan, blockers, invitations, and the delegation record
Line-of-work thread, on the mission channel	The Pods carrying the line	The Pod’s progress and done reports, and its SDD-mission’s ledger
Gate, escalation, or dispute thread	The parties to it	One exchange, and its outcome posted back to its parent
Ship queue, one per ship	The Captain and the Coordinator; a Pod joins when it posts	One thread per item: “PR ready” from Pods, tracker mechanics from the Captain, and landing talk. Two pull requests that conflict in meaning are escalated here

The Coordinator joins no mission channel, and the ship’s remote pane is never invited to one. No pull request channel is opened. Review lives on the host, and landing talk lives in the pull request’s queue thread. A starting Captain rereads the channels of its open missions and its ship queue.

A mention is a ping. It wakes every live session acting as the handle. When none is running and the post needs an answer (a request, an escalation, a decision-request), it starts one through the handle’s lease. A notification, such as an outcome, only wakes. Waking and starting are the runtime’s job.

Features this layout needs

Need	Provided by	Status
A per-role model and effort	cyberlegion spawn --model --effort, also accepted by service start	Built
Start a role on demand, at most once, with a fenced lease	cyberlegion service start <project> <name>	Built
Mission and queue channels with members, and anchored threads	cynapse channel create --kind work --member --anchor	Built in cynapse; cyberfleet does not depend on cynapse yet. How the queue is keyed apart from cynapse’s repository address channel is open
Own the ships: name, remote, template, tracker routing, landing setting, and the path to each main checkout	cyberfleet ship commands	Gap: replaces the project address; the runtime is handed paths and handles
Open a ship or the Command Center as a workspace with named tabs and a pane layout	cyber-mux layout templates	cyber-mux has templates; cyberlegion does not call them, and no cyberfleet verb opens a ship
Start a session in a named slot, such as the Bridge’s right pane	cyberlegion spawn --at	Gap: --at only places relative to the caller (pane:right, pane:down, tab, workspace), and tabs are unnamed
A mention that wakes every live session acting as a handle, and starts one through the handle’s lease only when the post needs an answer	The runtime’s wake and lease	Gap: the runtime must accept a handle as an opaque lease key (ADR-0030)
/captain and /operator as a call from any pane	Operator and Captain personas	Gap: neither persona is rewritten for it yet