Operating modes — --mode compete|swarm (+ CYBERINE_MODE env)

Two preset bundles that drive WorkflowEngine behaviour end-to-end: fleet size cap, judge chain selection, verify gate, governor, and M5 escalation. Selected via flag, env, or auto-routing.

# Compete mode — full fleet race, DiffJudge + BehaviorJudge chain with verifyCmd gate
cyberine run --mode compete --bg "refactor the auth module"
CYBERINE_MODE=compete cyberine run --bg "fix the off-by-one in pagination"

# Swarm mode — single cheapest worker, DiffJudge-only gate (no verifyCmd check)
cyberine run --mode swarm --bg "add JSDoc to src/utils/*.ts"
CYBERINE_MODE=swarm cyberine run --bg "update all dependency versions"

# Auto-routing (default) — router picks compete/swarm per task; check the dry-run:
cyberine route "rewrite the auth module"   # complex -> mode: compete
cyberine route "add a comment to utils.ts" # standard -> mode: swarm

How the preset is wired: WorkflowEngine reads preset from WorkflowEngineOpts (injected by cyberine-bg-run.ts). It caps the adapter list to preset.fleetSize after buildDefaultAdapters(), builds the judge chain from preset.judgeChain ('diff' → DiffJudge, 'behavior' → BehaviorJudge or DiffJudge when verifyGate: false), skips the M6 BehaviorJudge early-kill when verifyGate: false, and initialises the concurrency governor from preset.governor before the first worker runs. When CYBERINE_MODE is unset the engine falls through to the existing default rule (T64 tier classification + DiffJudge/BehaviorJudge/panel selection) unchanged.

Auto-routing (M5): when CYBERINE_ROUTE=auto and no explicit mode is set, the router picks the mode automatically — complex tasks (large refactors, repo-wide scope) get compete; trivial/ standard tasks get swarm. A failed swarm run is automatically re-dispatched in compete mode with lessons from the failure appended, so the compete fleet starts with full context. To disable auto-routing entirely set CYBERINE_ROUTE=off or pass --mode explicitly.

Judge model auto-selection: the same task-tier classification (complex / standard / trivial) that selects the worker fleet also governs which LLM model backs the judge: complex tasks → CYBERINE_JUDGE_MODEL_STRONG (default deepseek/deepseek-v4-pro-0813); trivial / standard tasks → CYBERINE_JUDGE_MODEL_WEAK (default deepseek/deepseek-v4-flash). Set CYBERINE_JUDGE_MODEL to pin one model for every tier. The chosen model appears in every verdict's rationale field (e.g. [judge-model: deepseek/deepseek-v4-flash]) so run.json is auditable.

Selectable judge backend: Moonshot-direct (T651c). By default the LLM-based judges (LlmJudge/AdversarialJudge/ClaimVerifier/synthesizer) use the DeepSeek-direct-first / OpenRouter-fallback precedence above — unchanged. Set CYBERINE_JUDGE_BACKEND=moonshot to switch the whole panel to Moonshot's direct API instead, using kimi-k3 (near-frontier general reasoning, native vision, always-on thinking — a Sonnet-tier-priced alternative opinion, distinct from the DeepSeek/OpenRouter judge model) when MOONSHOT_API_KEY is configured:

CYBERINE_JUDGE_BACKEND=moonshot npm run cli -- "<task>"
# override the model (default kimi-k3):
CYBERINE_JUDGE_BACKEND=moonshot CYBERINE_MOONSHOT_JUDGE_MODEL=kimi-k2.7-code npm run cli -- "<task>"

CYBERINE_JUDGE_BACKEND=moonshot with no MOONSHOT_API_KEY configured falls back to the default DeepSeek/OpenRouter precedence with a note explaining why (never silently builds an empty judge panel). Known limitation: this path is selectable, opt-in, and typechecked, but was NOT verified against a live judge verdict — the Moonshot account behind MOONSHOT_API_KEY in this repo's own .env was confirmed suspended for insufficient balance (HTTP 429 exceeded_current_quota_error, live-probed 2026-08-27) at the time this was wired. It is expected to work once the account is funded; re-verify with a real dispatch at that point rather than trusting the code alone. See docs/providers/moonshot-kimi.md.

The mode is threaded through launchBackgroundRun into the child process as CYBERINE_MODE; the workflow engine reads it to drive fleet size, judge chain, and verify gate. Unset = no preset (current default behaviour unchanged). A --mode flag overrides CYBERINE_MODE env, which overrides auto-routing.

A CODE task dispatched this way runs the implementer fleet (implementTaskWorkflow): each routed build worker competes in its OWN isolated git worktree and DiffJudge picks the winning diff — the live working tree is never edited directly. The winning diff is NOT auto-applied; land it deliberately. Two paths:

Two-turn dogfood protocol (preferred for batches): fire all background runs in Turn A, then collapse the whole landing leg in Turn B with cyberine land:

cyberine run --bg "fix the off-by-one in pagination"   # Turn A: returns runId immediately
cyberine land <runId>                                   # Turn B: wait -> digest -> apply+commit -> typecheck
cyberine land <runId1> <runId2> --dry-run               # dry-run: digests + apply checks, no commits

Manual single-run path: use cyberine apply when you want to review the diff before committing:

cyberine run --bg "fix the off-by-one in pagination"   # -> prints runId + an `cyberine apply <id>` hint
cyberine apply <runId> --dry-run     # show the winning diff's file stat; confirm it applies cleanly
cyberine apply <runId>               # git-apply the winning diff to the working tree (review, then commit)
cyberine apply <runId> --step <id>   # apply a specific step's winner (default: the implement step)

cyberine apply accepts a runId prefix, resolves it from the local .local/runs first then the global registry, gates on git apply --check, and errors cleanly when the winner is a text answer (a QA run) rather than a code diff. A QA/question dispatch keeps the single-step consensus flow (no diff).

Key-only run recipe (no CLI required):

CYBERINE_TASK="Add a sandbox-pinned word_count tool as src/tools/wordCount.ts following the Tool
interface in src/core/Tool.ts." \
CYBERINE_BUILD_FLEET="loop-deepseek-build" \
  npm run wf -- src/engine/implementTaskWorkflow.ts