Which verdict wins a step (k0fxw)
Every judge in a step's panel returns a verdict; the step records ONE of them as verdict. ConsensusJudge wins only when a real majority of candidates produced the same answer (agreement above 0.5, which includes a single-candidate step). When no answer is shared by a majority, the first non-consensus verdict with a winner (LlmJudge, then AdversarialJudge) is used instead. CYBERINE_PROFILE_JUDGE_METHOD still overrides both.
Why: on a prose step (a design plan, a review, a research answer) no two workers ever write the same text, so every consensus cluster has one member, and consensus used to pick the cheapest candidate by its tie-break while the LLM judge's verdict was computed and ignored. Measured on the kv09j live runs (e910865f, 6229515b): the design step recorded consensus 1/2 sources for a Claude seat over codex because codex reports no cost. Read the step's verdict.method in run.json to see which rule applied.
Known Limitations and Deferred Work. A tie between two equal-size majority clusters is impossible above 0.5, but a plurality below it (4 candidates, 2 agreeing) now defers to the LLM judge rather than counting as agreement. With no LLM backend enabled the panel is consensus alone, so a no-majority step still falls back to consensus's cheapest-candidate pick.
7. Implementer fleet: do a real task (multiple providers compete, judge picks the best diff)
Beyond Q&A/design, Cyberine can run a real file-changing task as an implementer fleet: several vendor coding agents each implement the same task in their OWN isolated git worktree, and a DiffJudge
Judge phase is fail-bounded (T551)
Every judge (ConsensusJudge, LlmJudge, AdversarialJudge, DiffJudge, BehaviorJudge, SwarmMergeJudge/LaneMergeJudge) is raced against CYBERINEJUDGETIMEOUTMS (default 60000ms) in...