Captains in dispute

Continuing Work across ships: Captain B declines A’s request (“the extension point already exists; use it in A”), and Captain A disagrees (“the extension point cannot express this; the fix belongs in B”). Other disputes take the same path:

both Captains claim the same fix, or both decline it;
two ships each need to land a breaking change first;
two Captains read one change and derive conflicting intents from it.

There is no lead Captain, and a Captain has no authority in another ship (authority-governance §2). The fleet’s Captain, though admiral-like, makes roadmap decisions and does not rule here. So no Captain can settle a dispute by ruling. The ladder below settles most disputes without the Council, and brings the rest to the Council already summarized. It replaces ADR-0023 §5’s step from the dispute thread straight to the Council.

Who is involved

Automaton	Tier	Role in this scenario
Captain A and Captain B	Opus	State their positions, and apply standing rules
Mediator	Opus, cold	Writes a brief of both positions with a recommendation. Decides nothing.
Operator	Sonnet	Starts the mediator, puts the brief to the Council, and relays the answer
Council	—	Decides any dispute the rules do not settle

The ladder

flowchart TD
d["Captains disagree"] --> ch["open a dispute thread<br/>anchored at the disputed entry"]
ch --> pos["each Captain posts its position:<br/>claim, evidence, cost, what would change its mind"]
pos --> r1{"one rebuttal each:<br/>agreed?"}
r1 -- yes --> done["record the outcome, both proceed"]
r1 -- no --> rule{"does a standing rule settle it?"}
rule -- yes --> done
rule -- no --> med["Operator starts a cold mediator"]
med --> brief["brief: both positions, options,<br/>consequences, recommendation"]
brief --> council["Council decides"]
council --> relay["Operator relays the Council's words,<br/>verbatim, as a turn to each Captain"]
relay --> done

Each rung settles what it can. Only the Council's rung binds both ships.

Step by step

1. Open a dispute thread

The Captain that hits the disagreement branches a dispute thread from the disputed entry on the mission channel both Captains share, with both Captains as members. The channel is a thread: it is anchored at that entry, and it posts its outcome back to the channel that holds the entry. Arguing moves out of the mission channel, so the plan and the blockers stay readable. The thread’s briefing names only its own exchange.

cynapse channel create <handle> --kind work --type fleet.dispute --title "<the question>" \
  --anchor <disputed-entry> --member <captain-a>:party --member <captain-b>:party
cynapse entry append <dispute-thread> --body "@<other-captain-handle> <position>"

Meanwhile both Captains hold the disputed missions and keep working everything else. Nobody acts on the disputed point while it is open.

2. State positions, with a bound

Each Captain posts one position: the claim, the evidence, the cost to its ship, and what would change its mind. Each gets one rebuttal. The bound matters, because two Opus sessions arguing without one is the most expensive loop the fleet can run. If they agree, either Captain records the outcome and the channel closes with its outcome posted to the parent.

3. Apply standing rules

Many disputes repeat, so the Council writes rules for them in advance, and either Captain can settle a dispute by citing one. For example:

The owner of an artifact decides about that artifact. B decides B’s API; A decides how A uses it.
A ratified decision outranks an unratified one.
A green trunk and a released contract outrank convenience. The change that keeps both is preferred.

The Council writes standing rules. The Captains apply them and never widen them, and editing a rule is widening it. A rule lives as a reference in the repository it binds (.agents/references/), or in ~/.agents/references/ for a rule across ships.

4. Mediate, then put it to the Council

If no rule settles it, either Captain asks the Operator for mediation. The Operator starts a mediator: a fresh Opus session that has worked for neither ship. It reads the dispute thread and both issues, and writes a brief: each position in its own words, the options, what each option costs each ship, and a recommendation.

cyberlegion spawn --agent mediator --model opus --cwd <home> --brief-file <dispute-brief>

The mediator decides nothing. A decision binding two ships is cross-project authority, and only the Council’s rung binds two ships.

5. The Council decides, and the Operator relays

The Operator puts the brief to you, in the Operator’s seat or through a ship’s remote pane. Your answer goes to each Captain, as you wrote it, as a turn (cyberlegion send --start --message), and onto the dispute thread as the record. Each Captain applies it within its own ship. If the decision becomes a pattern, it is a candidate for a new standing rule, and only you can add one.

Why a mediator, not one of the Captains

Either Captain summarizing the dispute would present its own side best. A cold session reads both sides from the channel with no stake and no context from either ship. The Operator could write the brief itself, but it runs on the mid tier, and weighing two plans against each other is the judgment the high tier is for.

Features this scenario needs

Step	Need	cyberlegion	cynapse	Status
1	Branch a channel from an entry, with both Captains	—	`channel create --anchor --member`	Built
1	Hold the disputed missions while the rest continue	—	A state record on the mission	Gap: shared with cross-repository ordering
2	Bound the exchange	—	Channel conventions (`--convention`)	Built in cynapse; the bound is persona logic
3	Standing rules the Council writes	—	—	Gap: the file format is decided when the first reader is built
4	Start a mediator	`spawn --agent mediator --model opus`	—	Spawn built; no mediator agent
5	Relay the Council’s words to two ships	`send --start --message`	`entry append`	Gap: `send --start` is not built; `unit nudge --message` works today