Fleet Command

Fleet Command

Conductor for the -fleet family — one tier above the members, coordinating the fleets themselves rather than fanning out over an item-queue. It derives the run as a hybrid DAG whose wave boundaries come from a dependency edge or an evidence-fidelity exclusivity requirement — either one alone sufficient — instead of accepting a hand-picked order, enforces one global leaf-slot budget across every fleet in flight rather than the sum of their per-fleet governors, deconflicts the lanes whose emissions collide before any of them runs, presents each ready member's own human CONFIRM gate verbatim in one batched round per wave without ever answering it, verifies every lane from its emitted artifacts rather than its self-report, and hands back one consolidated report. It never merges.

Thirteen -fleet skills exist, and each is a competent orchestrator over exactly one SDLC work-queue. What does not exist is anything that can run more than one of them in the same session without the operator personally holding the whole shape in their head — which fleets may run together, in what order, under what aggregate load, colliding on what, and arriving as how many separate reports.

That gap costs three specific things, and none of them is reachable from inside a single member. Fan-out². Each member caps its concurrent subagents at the family's machine-storm limit, and that cap is per fleet; nothing enforces it across fleets, so two well-behaved members at their own caps is double the load and a naive "run all the sweeps" is an order of magnitude more. A cap that every participant honors locally and nobody enforces globally is not a cap. Dependency. The conveyor is a real chain, not a menu — intake produces the queue that decide and build consume, and land lands what all of them produced — so members run concurrently consume their predecessors' stale output, while members run fully serially waste the genuine parallelism of the quality sweeps, whose inputs depend on none of the spine even though several of their outputs file back into it. Collision. Members write shared generated artifacts, allocate from shared number sequences, edit the same source regions, and file the same defect several times over, because no member can see the others.

The conductor is Tier 3 of Skills → Pipelines → Fleets → Conductor — a position on the composition ladder, which counts how deeply orchestrators nest. That is a different axis from the tier field in the skill's own manifest, which classifies loading (how eagerly the body is pulled into context) and says nothing about what the skill composes; the two numbers measure different things and are not comparable. Its authority is deliberately coordinator plus global governor, never dictator: it owns the scheduling, the budget, the deconfliction, and the reporting, and it owns none of the judgment inside the fleets it runs. It builds on the shared spine documented in docs/reference/fleet-family.md — the five-phase skeleton, the worktree-isolated fan-out, the front-load / park-unforeseen interaction model, and the never-silent-merge invariant — and on the family decisions recorded as Subagent worktree fan-out (vs the Workflow primitive) for -fleet execution, The front-load / park-unforeseen interaction model for the -fleet family, The pr-fleet land-stage human-merge-gate model, The adr-fleet decide-stage batch-sign-off-gate model, and its own The fleet-command conductor-tier authority model. It keeps the family's phase names deliberately — a conductor that invented a private vocabulary would be harder to reason about standing next to the members it runs — with one stated substitution: at this tier SELECT enumerates fleets and DISPATCH dispatches fleet lanes, where a member's SELECT enumerates items and its DISPATCH dispatches item subagents. It is not a -fleet and is deliberately not named one: a member fans out over an item-queue into outcomes, while this one's queue is other orchestrators.

When to Use

• Running several fleets in one session, where the aggregate load, the dependency order, and the cross-fleet collisions would otherwise be held in the operator's head
• A periodic full-conveyor or full-maintenance sweep whose outputs must arrive as one report rather than as many separate piles to collate by hand
• When the interruption budget is the binding constraint: one run-plan authorization plus one batched gate round per wave, instead of every member's gate arriving at an unpredictable moment
• When the run must be provably bounded — a global cap, one pass per fleet, a fleet cap, and a wall-clock budget, with everything shed named rather than silently dropped
• NOT for running a single fleet — invoke that member directly; the conductor's scheduling overhead only pays off across several lanes
• NOT for merging anything — the merge-order plan is advice handed to the land member or to the human, never an action
• NOT for answering a member's CONFIRM — batching a gate is scheduling, and answering it is the collapse this tier exists to reject
• NOT for scheduling a convergence pipeline — pipelines are the primitive a fleet runs, and conducting them directly collapses the tier distinction the family is built on
• NOT for re-verifying every item a member produced — the member already verified them to the family standard, and duplicating that roughly doubles the run's cost for no new evidence
• NOT for adding a member to the family or changing an existing member's behavior — a fleet that needs a change to be conductable owns that change itself

Capability Roles

• Defines (Service Definition): the shared -fleet handoff contract — the five-phase skeleton, worktree-isolated fan-out, gate-free --report-only probe path, and never-silent-merge invariant documented in docs/reference/fleet-family.md, concretized as the canonical FleetHandoffRecord in @harness-engineering/types (packages/types/src/fleet-handoff.ts, validated via validateFleetHandoffRecord; landed in #1414). fleet-command consumes this contract; it does not own it and never modifies a member to make it conductable.
• Provides (Provider): the -fleet members — roadmap-fleet, bug-fleet, cicd-fleet, cleanup-fleet, security-fleet, issue-fleet, pr-fleet, test-fleet, adr-fleet, ideate-fleet, craft-fleet, perf-fleet, docs-fleet — each emitting the shared handoff shape through its gate-free probe path.
• Consumes (Consumer): this skill — fleet-command probes each member through the gate-free path only and verifies every lane from its emitted handoff artifacts, so any new -fleet member is conductable with zero conductor change.

Flags

--report-only and --dry-run are not synonyms, and the difference is the human gate. --report-only is the gate-free path: it never presents CONFIRM, so it is safe to invoke from tooling, from a wrapper, or from another skill's SELECT without raising a decision the caller cannot answer. --dry-run is the gated path: it runs SELECT and then presents the run-plan CONFIRM, and only then stops. This is the same split the members keep, and the conductor depends on it in both directions — it honors the split in its own flags and it relies on the members honoring it when it probes them.

The --max-fleets shed is structural, not a ranking. When more fleets are schedulable than the cap allows, the run sheds in a fixed order: the CI trust gate and the terminal lander are never shed — dropping the trust gate discards the run's only read on evidence quality, and dropping the lander leaves every emission unlanded with nothing scheduled to look at it. The independent quality sweeps are shed first, lowest probed queue depth first, because they are the lanes whose omission costs the run the least and whose queues survive to the next run intact. That category is defined by input, not by wave, so perf-fleet belongs to it: it reads standing code, consumes nothing the spine produces, and is therefore shed by probed depth like any other sweep despite occupying a wave of its own. An exclusive wave is not a reason to protect a member — the trust gate and the lander are exempt because dropping them costs the run its evidence base or its reviewable terminal state, and neither applies to a benchmark sweep; a shed perf-fleet simply empties its wave, which is then skipped rather than renumbered. (Everywhere else in this body "the sweeps" is scoped to wave 2. Here alone it names the whole input-independent group, wave-2 and wave-5 alike, and the distinction is load-bearing precisely because the exclusive wave split the two readings apart.) A conveyor-spine member is shed only if the human trims it at CONFIRM — the conductor never sheds a spine member to fit a cap, because the spine is the dependency chain the derived order exists to respect. Every schedulable member falls into exactly one of these three categories — never-shed, independent quality sweep, conveyor spine — so the question "which reason shed this lane?" is always answerable, and everything shed is reported by name with the reason that applied.

The depth-ordered shed is keyed on a probe, so it is only as available as the probe is. "Lowest probed queue depth first" is the cap's one mechanical rule, and a member whose depth is unknown is — correctly — not sheddable by it. Those two rules deadlock whenever the sweeps in contention are all unknown-depth: the cap binds, and nothing can decide it. The resolution is stated in SELECT step 4 and is deliberately not a fallback ordering invented for the occasion — inventing one (alphabetical, wave index, declaration order) would produce a shed that looks structural and is arbitrary, which is worse than an honest abstention. Instead the reduction becomes the human's trim at CONFIRM and is reported as cap undecidable, so a reader can always tell a shed the policy made from a shed a person made.

One pass per fleet per run is fixed, and is deliberately not a flag. A fleet is never re-run inside a run to clear more of its queue. Exposing that as a lever would invite the "just one more sweep" drift the bound exists to prevent, and an unbounded conductor is indistinguishable from no conductor at all.

Process

Iron Law

GLOBAL BUDGET, DERIVED ORDER, UNTOUCHED GATES, NEVER MERGE — no lane is dispatched outside the global governor; no fleet runs before the fleets it depends on have finished; no member's human gate is answered, skipped, or summarized by the conductor; and nothing is merged.

All four are stated as law rather than guidance because each has an obvious-feeling shortcut, and each shortcut is available at precisely the moment it is most tempting. "Just this once, run them all" arrives when the queues are long and the wall-clock looks generous. "The spine is probably fine out of order" arrives when intake looks quiet and the sweeps are ready first. "That gate's answer is clearly yes" arrives after the fourth identical-looking gate in a batched round. "It is all green, land it" arrives at the end, when the merge order is already computed and sitting in the report. A property that survives only when it is convenient is not a property.

They are also the four that make a multi-fleet run safe to authorize at all. The human approving a run plan is approving a bounded amount of machine load, a correct consumption order, an unchanged set of decision rights, and a terminal state that is reviewable rather than landed. Violating any one of them retroactively invalidates the authorization that started the run — which is why a violation is a gate violation and a stop, never a tuning decision made mid-flight.

The corollary matters as much as the law. A quiet run — every fleet reporting an empty queue — is a valid, valuable result. It says the backlog is clear, which is worth knowing and worth reporting as such. It is never a reason to lower a member's noise floor, widen a queue, or re-probe with looser criteria so that some lane produces something. The conductor is the one actor in the family positioned to apply that pressure across every member at once, which is exactly why it is the one actor forbidden to.

Phase 1: SELECT --> Phase 2: CONFIRM --> Phase 3: DISPATCH
                                                    |
                                                    v
                     Phase 5: REPORT <-- Phase 4: VERIFY

Phase 1: SELECT — Enumerate Fleets, Probe Queues, Derive the DAG, Build the Contention Map

1. Determine which members are installed. A missing member does not abort the run: the DAG degrades to the members present and the absence is recorded in the run plan and the report, never silently dropped. A degraded DAG the human can see is a schedule; a silently degraded one is a surprise. If no member at all is available, stop and report — there is nothing to conduct.

2. Probe each member's queue depth through its own gate-free path only — never by reimplementing its SELECT, and never through a path that presents that member's human gate. A member's selection logic is that member's, including its scoring, its noise floor, and its cross-checks; a conductor that re-derived it would drift from the member on the first change to either.

   The probe contract distinguishes two kinds of path, and they are not interchangeable:

   • A gate-free probe path (a member's --report-only) enumerates and presents its queue and stops without asking the human anything. This is the only path SELECT may use.
   • A gated path (a member's --dry-run) runs that member's SELECT and its CONFIRM. Using it to probe would fire a member's own gate during the conductor's Phase 1 — before the run plan exists, let alone is authorized — and would falsify the promise that CONFIRM is the only guaranteed human touchpoint before the first lane starts.

   A member with no gate-free probe path is not probed. Some members deliberately ship none: a member that files nothing has no destructive mode to suppress, so a report-only flag would do nothing for it. Such a member is recorded as queue depth unknown, presented that way at CONFIRM alongside every probed depth, and scheduled or not on the human's call rather than on a guess. Unknown is a fact worth reporting; a fabricated depth is not.

   A member whose queue comes back empty is unscheduled, not run, and is reported as such. A member that errors on its probe degrades exactly like a missing one: recorded, excluded, reported.

3. Derive the wave assignment from the fixed dependency shape and the fixed evidence-fidelity requirements. Scheduling is derived, never hand-picked. Two criteria create a wave boundary, and either one alone is enough: a dependency edge between members, or an evidence-fidelity exclusivity requirement — a member whose evidence is silently corrupted by co-scheduled load takes a wave of its own even though no dependency edge explains it (ADR 0125). Both are fixed ahead of the run, so the assignment stays derived rather than chosen. The dependency criterion alone would place perf-fleet in wave 2 beside the sweeps, since it consumes nothing the spine produces — which is exactly the co-scheduled benchmark the second criterion exists to prevent:

   Wave	Fleets	Why this wave
   0 — CI trust gate	cicd-fleet	Every downstream fleet's VERIFY treats all-OS CI green as its evidence, so the run reads how trustworthy that signal is before anything else rests on it. A trust gate, not a repair — see below.
   1 — ideate	ideate-fleet	Ideation feeds intake, so it is its own wave rather than a sequential pair inside one. A dependency edge belongs between waves; a wave holding one would make "wave" mean two different things.
   2 — intake + sweeps	issue-fleet; test-fleet, cleanup-fleet, bug-fleet, security-fleet, craft-fleet, docs-fleet	Intake consumes ideation. The quality sweeps read standing code, so none of their inputs comes from the spine and they are genuinely parallel — subject to the global governor, to deconfliction, and to the output-coupling note below. docs-fleet joins as an ordinary sweep — it reads standing code, takes no input from the spine, and its evidence is load-insensitive.
   3 — decide	adr-fleet	Consumes intake's routed decisions.
   4 — build	roadmap-fleet	Consumes the ranked queue plus the decisions above it.
   5 — perf (exclusive)	perf-fleet	Its verdicts are measurements, and a measurement taken under co-scheduled load is silently wrong rather than visibly broken. Runs alone — see below.
   6 — terminal	pr-fleet	Lands what every other lane produced, so it must run last or it lands a stale subset.

   A wave is a barrier, and it holds no dependency edges inside it. Every member in a wave is independent of every other member in that wave; anything with a real edge between them belongs in different waves. That property is necessary but not sufficient to explain the wave list: a wave may also exist because a member's evidence requires exclusivity, and wave 5 is exactly such a wave — no dependency edge explains it. Reading "no wave contains a dependency edge" as the whole derivation rule would collapse the exclusive wave back into wave 2. The barrier property is what makes "at most one batched gate round per wave" satisfiable and what makes a wave boundary a meaningful place to check the budget. Wave indices come from the fixed dependency shape plus the fixed evidence-fidelity exclusivity requirements — the two admission criteria above — so a wave with no scheduled members is skipped, not renumbered and not a barrier — trimming or shedding a fleet empties its wave rather than shifting the ones after it. Excluding a fleet at CONFIRM re-derives its dependents rather than leaving them scheduled against something that will not run.

   Wave 0 is a trust gate, not a repair — and the distinction is load-bearing. The CI lane's terminal act is a report: it hands back unmerged remediation PRs and merges nothing, the conductor merges nothing, and the terminal lander runs at the last wave. So within a single run, waves 1 through N execute against the same CI signal wave 0 found. A run cannot repair its own evidence base. What wave 0 actually produces this run is two things: evidence-quality information — a read on whether downstream verdicts can be trusted — and remediation PRs whose payoff lands on the next run, once a human has merged them. Anything that claims wave 0 heals the signal in-run is claiming something the schedule cannot deliver.

   The trust read itself is available before dispatch, for free: SELECT already probes the CI lane's own queue, and a red/flaky queue depth is the signal's trust level. So the trust gate's product is surfaced as a fork at CONFIRM with a recommended default, not as a silent precondition. When that probe comes back non-empty, the human is shown: the CI signal is untrustworthy, so every downstream verdict this run would rest on degraded evidence — and offered, in order of recommendation, to run the CI lane alone this session and conduct the rest on the next run once its remediation PRs have landed (the default), to proceed with the full run with every downstream verdict explicitly recorded as resting on degraded evidence, or to trim the fleets whose verdicts lean hardest on the CI signal and run the rest. A degraded run the human chose and the report labels is honest; a degraded run presented as clean is not.

   The sweeps are input-independent of the spine and output-coupled to it, and only the first half is a scheduling fact. The wave-2 sweeps read standing code, so nothing they consume comes from intake — which is what makes them safe to run beside it. But several of them file issues and roadmap items into exactly the queue intake triages, so whatever they file this run is intake for the next run, not for this one. The conductor states this rather than hiding it, and records it in the run's assumptions-made note. It does not serialize the sweeps behind intake, and the reason is a tradeoff rather than an oversight: doing so would spend the sweeps' entire parallelism — the single largest source of concurrency the schedule has — to freshen a queue the next run picks up anyway, for filings the human has not yet even seen. "Depends on none of the spine" is true of the sweeps' inputs and false of their outputs, and leaving that unqualified would be the same stale-consumption error the derived order exists to prevent.

   Wave 5 is exclusive, and an exclusive wave is not a valid deferral target. perf-fleet's verdicts are measurements, and that makes its evidence fail differently from every other member's. A contended test fails loudly — the flake is visible, a rerun exposes it, and the family already treats "prove the failure is outside your diff, then rerun once" as routine. A contended benchmark succeeds with a plausible wrong number: nothing in the artifact distinguishes a clean 40ms from a contended 40ms, so the lane gates a fix on corrupted evidence and reports it as verified. That corruption is silent rather than exposable, and no downstream verification recovers from it, because there is nothing to recover — the artifact is well-formed and wrong. This is why wave 5 admits perf-fleet and nothing else. Load-sensitive evidence is not new here (.husky/pre-push already caps parallel test load for the same reason, and a throughput cap is the right instrument when the corruption announces itself); what is new is corruption that cannot be seen. The exclusivity has a second consequence: wave 5 is not a place a deferral may land.

   A wave is non-admitting when it is exclusive or terminal, and neither is a matter of how many members it holds. Waves 0, 1, 3 and 4 each hold exactly one named member too, and every one of them will take a deferred lane — holding one member is not what makes a wave closed. An exclusive wave admits only its named member and refuses deferrals outright, because a deferred lane is precisely the co-scheduled load that corrupts the measurement. A terminal wave admits nothing scheduled after it. So wave 5 is non-admitting by exclusivity and wave 6 by terminality, while wave 3 is admitting — which is why the worked example below defers craft-fleet into wave 3 rather than shedding it. The serialization deferral stop below is therefore bound to the first non-admitting wave — today wave 5 — and not to the lander's index. Moving the lander from wave 5 to wave 6 nominally opened a wave of headroom; it did not, because the wave it opened refuses deferrals by construction. A lane whose deferral would reach wave 5 is shed with its reason, exactly as before the renumber.

4. Apply the fleet cap structurally. If more fleets are schedulable than --max-fleets allows, shed in the fixed order stated under Flags: the CI trust gate and the terminal lander are never shed; the independent quality sweeps are shed first, lowest probed queue depth first; and a conveyor-spine member is shed only if the human trims it at CONFIRM. A member whose queue depth is unknown is not sheddable by depth — it is carried to CONFIRM as a fork. Every shed fleet is recorded with the reason that shed it, and the reasons are distinguishable: over the cap, empty queue, missing or errored on its probe, trimmed by the human, or cap undecidable (below).

   When no sweep in contention carries a probed depth, the depth-ordered shed does not run — and the cap is reported as undecidable rather than applied. The ordering rule is keyed on probed depth, and the unknown-depth rule withholds exactly that key; each is individually correct and together they are inert. A run in which every schedulable sweep came back unknown therefore has no mechanism at all to close the gap between the schedulable set and the cap. This is not a hypothetical corner: it is what every run gets while the members expose no executable gate-free probe path, which is the state of the CLI today. In that case the conductor carries the whole over-cap reduction to CONFIRM as the human's trim and records each resulting shed as cap undecidable — reduced by human trim, never as a depth-ordered shed. Reporting "over the cap, lowest depth first" for a reduction no depth informed would attribute a structural policy to a hand-made decision — the same species of overstatement as claiming a verified within-allocation check, and it fails the same way: the run reads as though a mechanism ran when none did. A partially-probed run sheds by depth only among the sweeps whose depth is known; if that does not reach the cap, the remainder is carried to CONFIRM exactly as above, and the report distinguishes the two groups rather than merging them under one reason.

5. Build the contention map and the derived merge-order plan over the four collision classes — see The Contention Map below. This happens before dispatch, because its whole product is a scheduling constraint: a serialization decided after two lanes are already running is not a serialization.

6. Detect run-level forks worth surfacing. Each is carried to CONFIRM with a recommended default, so the human confirms a decision rather than makes one from scratch. The recurring ones are: an untrustworthy CI signal, read from the CI lane's own queue probe, with its three options above; a member with no gate-free probe path, whose queue depth is unknown and whose scheduling is therefore the human's call; a member whose queue is far larger than one pass can absorb; two sweeps whose contention resolution could go either way; and a spine member whose predecessor came back empty.

7. Build the records.

   FleetLane {
     member,        // the fleet this lane runs
     wave,          // derived wave index
     dependsOn,     // the lanes that must finish first
     queueDepth,    // probed via the member's own gate-free path, or "unknown"
     state,         // "scheduled" | "running" | "parked" | "unscheduled" | "shed"
     slots,         // leaf slots allocated from the global pool, passed as --concurrency
     artifacts,     // emitted PRs / filed items / drafted decision records / shortlists
     verdictRefs,   // per-item verdict references the conductor spot-checks
     verdict,       // "verified" | "parked" | "rejected" | "unscheduled" | "quiet"
     parkedForks,   // unforeseen run-level forks this lane parked on
   }
   

   RunPlan {
     waves,         // the wave-ordered DAG
     selection,     // the fleets scheduled, with queue depths
     budget,        // { slots, passesPerFleet: 1, maxFleets, wallClock }
     contention,    // the contention map (see below)
     mergeOrder,    // derived merge-order plan — advice, never executed
     authorization, // the human's single run-plan approval
   }
   

Phase 2: CONFIRM — The Single Up-Front Run-Plan Authorization [checkpoint:human-verify]

1. Present the whole run plan in one surface. This is the only guaranteed human touchpoint before the first lane starts, and everything in it is a scheduling decision the human can still change cheaply:

   • The wave DAG, with each fleet's wave and the criterion that placed it there — the dependency edge, or the evidence-fidelity exclusivity requirement where no edge explains the wave.
   • The fleet selection with its probed queue depths, and — listed explicitly rather than omitted — the fleets whose queue depth is unknown because they expose no gate-free probe path, the empty-queue fleets that will not be scheduled, the fleets shed by the cap with the structural reason that shed them, and any member that was missing or errored on its probe.
   • The global budget: the slot cap with its default of 3 and hard max of 4, the per-fleet sub-cap of 2, one pass per fleet, the fleet cap, and the wall-clock budget.
   • The contention map with its consequences made concrete — which lanes are serialized into different waves, and what merge order the generated-artifact class implies.
   • The detected forks, each with a recommended default — including the CI-trust fork whenever the wave-0 probe found the signal red or flaky, and a schedule-or-not call for every member whose queue depth is unknown.

2. The human approves, trims fleets, or re-tunes the budget — once. Trimming a fleet re-derives the DAG, including its dependents, rather than leaving a consumer scheduled against a producer that will not run. Under --dry-run the skill stops at the end of this phase. Under --report-only this phase does not run at all: the run plan is printed and the skill exits without presenting a gate, which is what makes --report-only safe to call from tooling.

3. Why this is a run-plan authorization and not a batch approval. At this tier the human is authorizing a schedule and a budget — how much machine load the run may create, in what order, with what collisions already resolved. They are not authorizing the work itself. Each member's own approvals still belong to that member's gate and arrive later, per wave, in the member's own words. Conflating the two would be exactly the dictator design this tier rejects: it would convert every member's human taste-check into a single machine judgment made before any of the work was even enumerated, at the largest blast radius in the family.

Phase 3: DISPATCH — Wave-by-Wave Lane Scheduling Under the Global Governor

1. One worktree-isolated lane per scheduled fleet, each running the real member skill for its stage — never a reimplementation of what that fleet does. This is the family's dogfooding invariant applied one tier up, and it is also what makes VERIFY possible: the artifacts the real member leaves behind are exactly what VERIFY checks for, and a reimplementation would leave different ones.

2. The governor allocates leaf slots from one global pool — default 3, hard max 4, with no single fleet ever allocated more than 2 of that pool. The sub-cap is the family's per-fleet default, not its ceiling: pinning it to the ceiling would let one lane hold the whole pool at the default setting, which is a single-fleet run wearing a conductor's name. At 2 there are always at least two lanes genuinely in flight at the default pool, which is the property that makes the run a run.

   The unit argument is the whole design: the scarce resource is consumed by the leaf subagents a member's DISPATCH fans out, not by a member's cheap select, confirm, verify, or report phases. So a fleet in a cheap phase holds no slot, which is precisely what lets several lanes be genuinely in flight while the aggregate load stays at single-fleet scale.

3. The allocation is imposed at dispatch time, through each member's own --concurrency flag. This is the seam, and it is the only one: every member of the family exposes --concurrency, and the conductor dispatches each lane with --concurrency <allocated> set to that lane's allocation from the global pool. A member dispatched without it runs at its own default of 2, chosen against a single-fleet world with no knowledge of the other lanes — which is exactly the cap-everyone-honors-locally-and-nobody-enforces

…(truncated)