cyberine
UsageRun recipes

Judge phase is fail-bounded (T551)

Every judge (ConsensusJudge, LlmJudge, AdversarialJudge, DiffJudge, BehaviorJudge, SwarmMergeJudge/LaneMergeJudge) is raced against CYBERINEJUDGETIMEOUTMS (default 60000ms) in...

Every judge (ConsensusJudge, LlmJudge, AdversarialJudge, DiffJudge, BehaviorJudge, SwarmMergeJudge/LaneMergeJudge) is raced against CYBERINE_JUDGE_TIMEOUT_MS (default 60000ms) in WorkflowEngine.decideWithTimeout. Previously an unreachable/misconfigured judge-model endpoint (e.g. GATEWAY_BASE_URL pointed at a dead port) left the judge's decide() call never settling, which blocked the run's finalization step forever — run.json stayed running with no recorded verdict even after every worker had already finished. A judge that does not settle within the budget is now treated as a failed judge: the run still reaches a terminal state (done when a worker still produced a usable answer, error otherwise) and the step's verdict.rationale records the timeout so the cause is visible in cyberine wait / digest / the TUI run detail, instead of an unexplained hang.

# lower the budget for a fast-fail dev loop against a possibly-down local gateway
CYBERINE_JUDGE_TIMEOUT_MS=10000 npm run wf -- src/engine/implementTaskWorkflow.ts

Regression guard (model-free — a fake judge that never settles stands in for the unreachable endpoint): npm run selftest:judge-timeout.

If GATEWAY_BASE_URL explicitly points at port 4000 (LiteLLM's raw container-internal default, distinct from Cyberine's published host port 41400), Cyberine also warns once at startup — a stale .env from before the uncommon-port migration is the most common cause.