Independent answers from a pinned fleet — cyberine run --compare (kmrcz)

A build fleet inside a git repository always means the implement-task chain above, whatever the prompt says: the design winner is pasted into every implementer's prompt, so the second worker reads the first one's answer. That is wrong when the point is several independent opinions (the /cyberine:ask advisors). --compare asks for the other shape: one step, every worker gets the identical prompt at the same time, none sees another's answer, and nothing is diffed or applied.

CYBERINE_TASK_TRUSTED=false cyberine run --compare --fleet codex,muse "$(cat brief.md)"
# stdout: the result card, a verdict line, then one block per worker:
#   === codex (judged winner): done ===
#   <codex's answer>
#   === muse: done ===
#   <muse's answer>
cyberine run --compare --fleet codex,muse -p "<question>"    # prints only the judged winner's answer
cyberine run --bg --compare --fleet codex,muse "<question>"  # detached; answers land in run.json steps[0].workerRuns[].output
jq -r '.steps[0].workerRuns[] | "=== \(.agentId)\n\(.output)"' .local/runs/<runId>/run.json

• The run is cyberine-compare with one step, main, whose workers are exactly the --fleet ids with a strict pin: no auto-routing, no failover hop, and a pinned id that is not built on this machine is skipped with a warning instead of being replaced.
• The run's memory preamble (prior runs and notes) is left out, because a prior run can hold another advisor's earlier answer; the rules and hard invariants still lead the prompt.
• The usual text-judge panel still ranks the answers, so judged winner is a ranking, not a ruling; the per-worker blocks are the point.
• --compare without --fleet runs the default compare pool (the always-on loop workers, plus every seat and CLI worker cyberine route reports since kw920; see "A mixed fleet dispatches to every active worker" below) with the router off, through the same one-step engine run, so the foreground prints every answer and keeps run.json exactly like the pinned form (before k229g the foreground went through the in-memory compare pool, printed only a runId that no run.json backed, and showed no answer without -p). It refuses --mode swarm and a remote server (CYBERINE_SERVER_URL).
• A planning brief no longer needs --compare (kdfhv): the router has a plan kind (see "Plan briefs route as a text compare" below), so a plain cyberine run "<planning brief>" runs this same one-step compare on the fleet cyberine route prints. Before kdfhv (k229g, observed 2026-10-04) the router read a planning brief as a code task, pinned a build fleet, and inside a git repository ran implement-task, which handed back one diff (a PLAN.md from the /cyberine:az walk-through) instead of one task list per worker, so /cyberine:plan had to dispatch every round as cyberine route then cyberine run --compare --fleet <ids>. That forced form still works and stays the right one whenever a fleet is already pinned.
• The compare step is never turned into a chunk-handoff chain, even when budget planning would chunk a plain run, and -p prints only an answer from a worker that finished, exiting 1 when none did.
• Measured 2026-10-04 in a scratch repo: run --bg --fleet codex,muse "<one-line question>" ran implement-task with loop-deepseek-direct in the design step and fed the design winner into the implement prompt; the same line with --compare ran one step with exactly codex and muse, started 70 ms apart, each answering on its own.

--fleet is a hard limit on every cyberine run shape. A cyberine run (foreground, through the engine or the plain compare pool outside a git repository) or cyberine run --bg run (and every other dispatch that goes through the same background entry, launchBackgroundRun: chat /run, the queue consumer, the TUI new-task key) with an explicit pin now cuts the built workers to the pinned ids before any step picks from them. Before this, the always-on loop workers (loop-deepseek-direct and the other -direct workers, built whenever their key exists) slipped into a step whose candidate list named them, and a step whose pinned workers were not built degraded to every built worker. The run prints fleet pin [...] is a hard limit: not dispatching [...] for what it dropped, and a pin that builds nothing refuses rather than widening. A fleet that came from config.json's preference, or a pin given to an engine started elsewhere (npm run wf, cyberine research, the autonomy loop's own engine), keeps the old narrowing behaviour.

Known Limitations and Deferred Work: inside a git repository a compare run gives each write-capable worker (every CLI worker, and every loop worker holding a tool outside the read-only set) its own disposable git worktree off HEAD, removed when the worker finishes. Its edits are discarded, never captured or applied, and the run records a progress event naming the worker and the discarded paths; a read-only loop worker still runs in the live tree. Outside a git repository, or before the first commit, the workers run in the live tree and a progress event says so. The worktree moves the cwd but is not a host sandbox: a CLI worker run without one can still write the live repo by absolute path, so CYBERINE_TASK_TRUSTED=false (which makes the sandbox mandatory) stays the setting to use when that matters. The judge panel spends its usual backends on a compare run and cannot be turned off per run yet. Failover hops in an implement step can still reach a worker outside the pin when a pinned worker hits its quota; that is the failover feature's own chain, unchanged here. A background run whose fleet the router picked reaches the child without its router provenance, so the child treats that routed fleet as an explicit pin too.