Maintainer-facing, directional, evidence-driven and subject to validation. This is not a release promise, an implementation specification, a commitment to every proposed command, or permission to implement later phases automatically. SHIPPED describes delivered capabilities; IN VALIDATION identifies work with qualification still in progress; PLANNED is future work; EXPLORATION is an uncommitted UX idea. Qualification and review precede any promotion of status.
- OpenCode V2 — ACTIVE DEVELOPMENT. Prioritize it for every new feature, agent, command, architectural improvement, and runtime capability. OpenCode-only capabilities need no Codex equivalent or parity gate.
- Codex — FROZEN COMPATIBILITY. Codex is neither removed nor declared wholly incompatible. Retain its existing components, installers, manifests, and uninstall protections. Do not add integrations or close gaps solely for parity; allow only evidenced critical Codex fixes or regressions caused by shared-code changes, with a concrete bounded scope.
- Keep existing tests that protect shared integrity and compatibility. Do not add Codex gates for OpenCode-only capabilities. Do not claim newer Codex versions are verified without version-specific evidence.
- Frozen Codex gaps include differences in authority, Aegis, hard
DENY, and observability. The historical compatibility evidence and its version/date qualifications below remain intact; this policy does not promote it to evidence for newer versions. - The twelve canonical Olympus Core roles and their responsibilities remain intact. Runtime support status does not remove or reassign a role.
- Kael's three optional execution modifiers are OpenCode-only and task-scoped: terminal standalone
long-mode,fast-mode, andsurgical-modelines.fast-modereuses existing FAST; no parser, scheduler, model, permission, or Codex change is introduced. Prompt instructions can define marker placement, but static checks do not prove live model recognition or compliance.
- Harness Core, OpenCode adapter, and Codex adapter are present; OpenCode V2 is actively developed, while Codex stays at its frozen compatibility baseline and its capability differences remain explicit.
- The dual-harness project and global installer entrypoints are published.
-Scope projectremains the default; Codex/OpenCode/All selection is supported. Global installation and agent discovery are Windows-qualified for OpenCode V2.0.26 (isolated runtime, Issue #7); no prompt execution or other runtime versions are implied. - Completion/reconciliation, external-work ownership, authority, and the explicit
/maintain→ Aegis maintenance entry are part of Core. OpenCode has Aegis, hard DENY, native ASK, and the passive Activity HUD. Codex DENY/Aegis remain gaps and activity visibility is basic/partial. - Upstream OpenCode result-correlation issue #1 remains OPEN; Olympus keeps no-blind-retry/result reconciliation. Issues #2–#6, #9 and #10 are CLOSED. Issue #8 was reopened for compaction/authorization continuity. Global discovery #7 has a Windows V2.0.26 real-install and Kael-selection acceptance PASS; historical early roster results remain in the issue thread.
- Release history: the v0.4.0 validation tag records the integrated foundation; its release validation failed because documentation still named beta.5 as the active baseline and contradicted the established integration/tag state, and no GitHub Release was created.
- The v0.4.1 validation tag also failed release validation because documentation treated that version as upcoming and advised against publishing it; no GitHub Release was created.
- Both validation tags are immutable historical records.
- The corrective v0.4.2 release established stable release-facing documentation; v0.4.3 subsequently published the public install and uninstall UX.
- The v0.4.0 foundation introduced one canonical Full Agent Display Identity source and derived adapters, plus the global OpenCode/Codex/All installer foundation, manifests, verification, update, safe uninstall, and non-destructive project→global migration. The corrective v0.4.2 and subsequent v0.4.3 releases preserve these capabilities and project scope as the default; project-local behavior remains backwards-compatible.
- Historical OpenCode V2.0.20 global-runtime runs returned empty rosters; the old diagnostic used the wrong location query and lacked loader-activation confirmation. The original cause remains unknown (Issue #7), so the results are preserved as historical investigation rather than an active unsupported-capability verdict.
- OpenCode V2.0.26
GLOBAL_RUNTIME_DISCOVERY = SUPPORTEDon isolated Windows with the actual v0.4.6 global installer (15 resources), verified loader, 12/12 agents, 2/2 controls, and configuration-level selection of primary Kael; no LLM prompt. Acceptance evidence. Codex remainsSUPPORTEDon separately supplied evidence, not rerun. - Codex DENY and Codex Aegis remain explicit frozen GAPs. Research found no demonstrated hard-deny equivalent or safely enforced privileged maintenance entry; do not use prompt-only theater or weaken Core. No parity work is planned solely to close these gaps.
- Phase 12 cross-harness evaluation is CLOSED: 3 matched pairs and 6/6 verified executions, with PASS for the tested functional, routing, completion, and scope invariants. Capability gaps remain; this does not establish total parity, superiority, or a harness/model winner.
Olympus coordinates technical execution, routes only useful specialists, reconciles their results, and reports evidence. The runtime remains responsible for tools, sessions, permissions, and process behavior. Kael reuses the completed Capability Preflight (#74) and TFR (#34) contracts; neither requires a second capability system or a blanket test campaign. Codex remains FROZEN COMPATIBILITY. Product requirements, feature priority, and acceptance decisions remain with each project owner. Flutter on Android and 2D games with Flame are priorities, not exclusions: web support remains, and projects need not install every optional device, game, or web tool.
| Disposition | Reconciled scope |
|---|---|
| KEEP | Kael's coordination, authority checks, useful specialists, dependency management, result reconciliation, and truthful completion; runtime-owned tools, sessions, and permissions. |
| REDUCE | Unnecessary specialist fan-out, mandatory all-role workflows, broad tool-suite installation, and blanket validation. Use only the smallest useful roles and TFR-proportionate checks; preserve applicable project and CI gates. |
| DEFER | Product feature implementation and the proposed mobile/game pilot below. The 70–80% useful-work target is an objective to measure, not a demonstrated capability. No product scope or acceptance decision is made here. |
| REUSE | Completed #74 Capability Preflight, completed #34 TFR, current Question Barrier/FAST/completion policies, and the target project's authorized runtime/tooling. Do not create parallel mechanisms. |
Evidence boundary: Preflight, TFR, FAST, native permissions, and session/result handling are existing contracts with their documented qualification limits. The three Kael modifiers are prompt instructions available in the OpenCode adapter; this change has static contract evidence only, not live marker-recognition evidence. The pilot is proposed, not performed, and no autonomy percentage is claimed.
Use a small, project-owner-approved Flutter/Android vertical slice: for example, a single checklist item's completion toggle in a demo app. The owner must decide the feature and acceptance criteria before implementation. A future authorized pilot would use Preflight to establish the permitted project/device route, capture the focused test plus observable emulator/device evidence required by TFR, and record accepted outcome, elapsed time, human interventions, avoidable handoffs, and rework against a simple baseline. Missing device/tool capability is reported honestly; the whole tool suite is not a prerequisite. This is a proposal only: no app, game, or pilot was started here.
- Role purity. Orchestrators/reasoners own decisions and questions: reason, compare evidence, decide, request focused follow-up, re-consult specialists, synthesize. They do not implement, fix, run tests, or take over another specialist's domain merely to avoid a handoff.
- Iterative evidence. Delegation is not one-shot. Re-consult the same specialist for new evidence, clarification, conflict resolution, hypothesis testing, narrower investigation, or validation of a newly discovered fact; prefer focused follow-up to restarting discovery from zero.
- Orchestrator ownership. Kael alone routes normal workers. Specialized reasoners own domain questions, hypotheses, and decisions; they request evidence through Kael and do not execute discovery, fixes or tests themselves.
- Acyclic orchestration. All workers/reasoners are direct children of Kael; no worker or reasoner spawns another agent. The same reasoner session can be re-consulted after Kael collects new evidence; no reasoner-to-Kael child call or reasoner nesting.
- Completion ownership. An orchestrator that launches child/descendant work owns it until required descendants are terminal, collected, and validated. A progress response or parent/root idle state is not family completion; the root entrypoint retains final user-facing completion authority.
- No-progress rule. Another diagnostic round needs materially new evidence, a discriminating experiment, a new viable hypothesis, or meaningful scope narrowing. Repeating reasoning over unchanged evidence is not progress.
- Containment before heroics. For third-party, build, deployment, tooling, or test-infrastructure failures, prefer a safe local unblock when appropriate over automatically changing upstream source or spending disproportionate time proving root cause.
The table captures shipped roles and current in-validation identities. Model entries describe the corresponding target/current candidate configuration, not an authorization to change other roles. Future role or command changes still require separate validation.
| Agent | Target model | Responsibility | Status |
|---|---|---|---|
kael — Kael — The Master |
GPT-6.1 Sol High | Master orchestration | SHIPPED; evolving |
veyra — Veyra — The Explorer |
GPT-6 Luna Max | Research/discovery | SHIPPED; evolving |
orin — Orin — The Architect |
GPT-6 Luna Max | Architecture/boundaries | SHIPPED; evolving |
atlas — Atlas — The Planner |
GPT-6.1 Sol High | Execution planning | SHIPPED; optional, Planning Gate only |
kovan — Kovan — The Coder |
GPT-6 Luna Max | Implementation | SHIPPED; evolving |
argus — Argus — The Bug Hunter |
GPT-6.1 Sol High | Functional defect reasoning | SHIPPED; optional, Functional Bug Routing Gate only |
nox — Nox — The Tester |
GPT-6 Luna Max | Testing/runtime evidence | SHIPPED; evolving |
vera — Vera — The Judge |
GPT-6 Luna Max | Independent review | SHIPPED; evolving |
talos — Talos — The Sentinel |
GPT-6.1 Sol High | Security defect and trust-boundary reasoning | SHIPPED; required for established/strongly evidenced material security/trust/authorization boundary defects under diagnosis/classification; no extra unanswered question required |
thales — Thales — The Sage |
GPT-6.1 Sol XHigh | High-uncertainty diagnostic escalation | SHIPPED: native evolution of Sorin; live routing qualified |
helios — Helios — The Optimizer |
GPT-6.1 Sol High | Explicit-only optimization feasibility and evidence-bounded proposal | SHIPPED; user-executed live qualification passed |
aegis — Aegis — The Keeper |
GPT-6 Luna Max | Hidden privileged task executor through explicit /maintain; never a Kael child or ownership gate |
SHIPPED on OpenCode; CODEX_AEGIS = GAP |
- FUNCTIONAL_BUG → optional Argus only if cause/fix direction is not obvious; deterministic trivial bugs bypass him. SECURITY_BUG → Talos required when diagnosing/classifying an established or strongly evidenced material security/trust/authorization boundary defect; no additional unanswered security-specific question is required. A generic security mention or suspicion without evidence does not automatically route Talos. Phase 7 qualification passed; its earlier activation criterion was superseded by Phase 11. OPERATIONAL_ISSUE (build/deploy/tooling/test infrastructure) → low-cost unblock/containment by default. A GAP / FEATURE / OPTIMIZATION is not a bug.
- Thales is not a bug category: escalate to this specialist when ordinary diagnosis reaches high uncertainty or stops making useful progress.
- Argus normally uses up to two consultations, with a third only after a second materially discriminating evidence round; a fourth automatic call is denied. Kael alone considers Thales under the independent Diagnostic Gate if diagnosis stays unresolved. Stop on no progress.
- Third-party resolution ladder: correct usage/configuration → available fixed version → upgrade/downgrade/pin → adapter/wrapper → fallback/feature flag → local reversible workaround → patch/vendor/fork only with explicit approval. Give workarounds a removal condition when practical.
Explicit user optimization intent may engage Helios; a performance fact alone never does. Cheap feasibility triage precedes bounded Nox measurements or Veyra source evidence. Helios proposes a small, evidence-backed benefit/effort/risk envelope or DO_NOT_OPTIMIZE; two automatic consultations normally suffice, third automatic denied. STOP for user approval of the concrete proposal before any implementation; Kael alone coordinates approved work, and success requires measured BEFORE / AFTER / DELTA / TARGET / CORRECTNESS. Static, synthetic, fresh-install, managed-upgrade and full non-live regression qualification passed. User-executed live evidence passed: Case A (Kael ses_f1d00092cffei3vpkwwod5V6Gw) used one Sol High Helios (ses_f1cffb27fffeQK1m5hcXSf3t3u) for two consultations in the same session, with bounded Kael-owned Veyra evidence (ses_f1cff4df4ffeTmrPSOqZia0GBp), a conservative proposal and an explicit approval stop; Case B (Kael ses_f1cd99003ffeq9C1V0uMOt5G5L) was observation-only, with zero Helios children. Case A's generic observer flagged complete=False, but native reconciliation confirmed the succeeded root, both terminal children consumed, empty inbox and no remaining required work. Neither live case was rerun during release review.
Phase 10 evaluated /power, /plan, /performance and /fast; none provides an exclusive capability or authority boundary that justifies a new Olympus command. Natural language and existing routing remain the primary UX. /maintain remains the exception because it explicitly enters the privileged Aegis maintenance plane.
/power— DROP. It mixes model, reasoning, parallelism, configuration and routing concerns; Olympus is not a model-configuration dashboard./plan— DROP as an Olympus command. Users can say “Plan X. Do not implement.” Atlas remains optional. Codex's native/planbelongs to that harness and does not equate to invoking Atlas./performance— DROP. An explicit optimization request already activates the Helios workflow; a discoverability alias adds no capability./fast— DROP. Keep contextualFAST: <task>for useful parallelism. It is distinct from FAST qualification, the automatic fast path and Codex's native/fastwhen available; it never skips validation or completion gates.
| Phase | Status | Target / qualification focus |
|---|---|---|
| 0 — Foundation | SHIPPED | OpenCode V2 runtime, preflight/discovery, completion and external-work gates, HUD, trusted-project execution, Maintenance Plane, NORMAL/FAST up to four. |
| 1 — Adaptive Concurrency finalization | DEFERRED | The earlier NORMAL 4 / FAST 6 proposal remains unimplemented. Current policy retains useful parallelism by default in NORMAL and explicitly requested FAST with at most four active children; this maintenance release makes no concurrency change. |
| 2 — Current Sorin baseline qualification | SUPERSEDED | The Sorin-specific qualification plan was superseded by shipped Phase 4 Thales evolution; no Sorin agent or session is to be resurrected. Evidence: the Thales evolution entry in CHANGELOG.md and the Phase 4 migration qualification in tests/thales/. |
| 3 — Role Purity + Iterative Evidence | SHIPPED | Kael-mediated Role Purity, same-session Sorin evidence follow-up, no-progress stop, completion ownership, Issue #1 reconciliation and Issue #2 Maintenance safety. Static/synthetic/full regression passed; user-executed live Cases A and B passed. No third automatic Sorin consultation. |
| 4 — Thales evolution | SHIPPED | Sorin visible identity → Thales The Sage; Sol XHigh deep-escalation role, user-executed live routing and deterministic negative control passed. |
| 5 — Atlas The Planner | SHIPPED | Sol High, smallest sufficient execution plan; no implementation/discovery ownership; gated use. User-executed live planning and negative control passed. |
| 6 — Argus The Bug Hunter | SHIPPED | Optional functional diagnosis; static/synthetic, installer, regression and user-executed live qualification passed. No implementation or direct discovery. |
| 7 — Talos The Sentinel | SHIPPED | Bounded security defect and trust-boundary diagnosis; static/synthetic, installer, regression and user-executed live qualification passed. |
| 8 — Helios The Optimizer | SHIPPED | Explicit-only feasibility/proposal, mandatory user approval, before/after validation; user-executed live cases A and B passed. |
| 9 — Aegis evolution | SHIPPED on OpenCode; Codex GAP | Hidden Aegis on Luna Max accepts the explicit /maintain command's task declaration immediately, without repository ownership/provenance admission; preserves Kael/child denials, task scope, and result reconciliation. |
| 10 — Command UX | CLOSED | /power, /plan, /performance and /fast were evaluated and dropped: no exclusive capability; natural language and routing remain primary, with /maintain retained for its explicit privileged authority boundary. |
| 11 — Integrated Routing Qualification | SHIPPED | Closure evidence: qualification is complete with no pending native cases. Case I remains guided PARTIAL; Argus/Thales same-session follow-up runtime coverage was NOT_EXERCISED. These are non-blocking limits, not evidence that every runtime path was exercised. |
| 12 — Cross-harness evaluation | CLOSED | Results: 3 matched pairs / 6 verified executions; PASS for tested invariants only. Capability limitations remain; no total parity, superiority, or winner is claimed. |
KAEL_MEDIATED passed offline topology certification and the user-executed Phase 3 live qualification: specialized reasoners request bounded evidence through Kael; Kael owns worker sessions, routes focused follow-up to direct children, and re-consults the same reasoner with collected evidence. Case A (ses_f21e09d97ffeiyjqAvmZuDRxa9) confirmed one bounded Veyra evidence round, two consultations in one Sorin session, Role Purity and complete family reconciliation (unresolved/unknown = 0). Case B (ses_f21dad776ffevU6A5qKcenexjh) confirmed the deterministic negative control with Sorin sessions/consultations = 0 and complete family reconciliation. The captured session/message review satisfied the manual structural-review gate. Evidence class: USER_EXECUTED_LIVE_EVIDENCE, not task-executed live evidence. No case was rerun during integration. Reasoners remain diagnostic rather than implementing; workers stay direct children of Kael. This respects native subagent depth, simplifies cycle prevention, keeps Completion Gates root-owned, and needs no custom scheduler/runtime.
DIRECT_NESTED is RUNTIME-INCOMPATIBLE with current OpenCode native subagent depth (Subagent depth limit reached (1)), not a prompt failure. No bypass or custom runtime is recommended.
Historical model references in the Phase 4–7 session records below are retained verbatim as evidence of those sessions, not as current configuration. Current model families and reasoning efforts are listed in the roster above.
Offline/static, fresh-install, v0.2.0-to-candidate upgrade and full non-live regression passed. User-executed live Case A (Kael ses_f217c2a55ffeXgwTNO96v5Ybzr, Thales ses_f217bf452ffe50smZ2Ad30z8z3, Veyra ses_f217b9d60ffeOvaDBJN71MxUCc) verified runtime agent ID thales at openai/gpt-6-sol#xhigh, one Thales session, two consultations in that same session (EVIDENCE_REQUEST then calibrated ADVICE), direct Kael-owned worker evidence and no Sorin sessions. User-executed live Case B (Kael ses_f216b02a1ffe0N79YjA86GUgL6, Veyra ses_f216ae227ffewhO6EdE35g0cLr) verified a bounded REDA → READY deterministic correction recommendation with Thales, Sorin and Maintenance counts all zero. Both families completed with pending and unknown counts zero. Evidence class: USER_EXECUTED_LIVE_EVIDENCE, not task-executed live evidence. Neither case was rerun for integration; no third automatic consultation is authorized.
Optional Atlas plans the execution of an already-scoped and already-architected change, using the smallest sufficient sequence; Kael applies the Planning Gate and retains evidence routing and completion ownership. Atlas neither discovers, redesigns architecture, diagnoses root cause, implements, tests nor reviews. Offline/static, synthetic, fresh-install, managed-upgrade and non-live regression qualification passed.
User-executed live Case A (Kael ses_f1e1eef3cffeV8KbtBWzwZbDVm, Atlas ses_f1e1ebd96ffeBiApFHkJ4paS6p, Veyra ses_f1e1e6759ffevt47wXhKeJsAH2) verified runtime ID atlas at openai/gpt-6-sol#high: one Atlas session, two consultations, bounded contracts/compatibility.txt evidence from a direct Kael-owned Veyra, EVIDENCE_REQUEST followed by PLAN in the same Atlas session, and a useful smallest-sufficient compatibility rollout and rollback plan. No direct Atlas discovery, implementation or third consultation occurred. Case B (Kael ses_f1e1af036ffecnp6pzOjibKQT5, Kovan ses_f1e1ac7c6ffePDii4zHwm7fI9e) changed READY to READY! with Atlas count and consultation count zero. Both families completed with pending and unknown counts zero. Evidence class: USER_EXECUTED_LIVE_EVIDENCE, not task-executed live evidence; neither case was rerun during integration. The disposable fixture manifest retained an older source commit, but SHA-256 comparisons matched the final candidate's runtime assets; an initial empty opencode debug agents response resolved on subsequent invocation in the intact fixture. Neither observation required fixture recreation.
Argus is one optional argus subagent at openai/gpt-6-sol#high, with no direct repository discovery, edits or tests. Veyra/Nox collect bounded evidence as direct Kael children; Argus compares hypotheses and returns a calibrated diagnosis or bounded request in the same session. Normal limit two consultations; a third needs a second discriminating evidence round; no automatic fourth. Security, operational failures, unpromised features, optimization and trivial deterministic bugs bypass Argus. Static/synthetic, fresh-install, managed-upgrade and all 16 applicable post-merge non-live suites passed.
USER_EXECUTED_LIVE_EVIDENCE: Case A (Kael ses_f1daec63fffe9KIz6iwZVDMlwd, Argus ses_f1dae9029ffe99un2V7aOy5kRZ, Veyra ses_f1dae4cd7ffemKeV6WP0EGVCTW) verified runtime Argus ID and Sol High model, one Argus session with two consultations, EVIDENCE_REQUEST followed by an evidence-backed BUG_DIAGNOSIS in that same session after bounded bug/shipping-rule.txt evidence from direct Kael-owned Veyra. Diagnosis identified strict > excluding threshold 50 against the established >= 50 contract, suggested inclusive threshold semantics, and bounded validation to 49/50/51. No third consultation, Argus direct discovery, implementation, Atlas, Thales or Maintenance; family complete with pending/unknown zero. Case B (Kael ses_f1da3bab2ffefQIzpvzR03Awsq, Kovan ses_f1da36c9dffefQSzUcybi9eg74) corrected REEDY to READY with Argus count zero; family complete with pending/unknown zero. Neither valid case was rerun for integration. Earlier attempted Case A (ses_f1dc6f099ffep6VsmAj6yz4vG7) was INFRA_OR_TEST_INSTRUCTION_BLOCKED, not an Argus failure: root assistant was build rather than Kael, with zero Argus/Veyra executions. tests/argus/RUNME.md now requires a fresh explicit Kael root, native agent verification and stop on wrong-agent roots without blind retry. Disposable live fixtures remain retained.
Historical criterion note: The Phase 7 wording and traces below are preserved as originally recorded. Phase 11 later replaced the earlier “only when materially security-specific reasoning remains” activation criterion: Talos is required for an established or strongly evidenced material security/trust/authorization boundary defect being diagnosed/classified, without requiring another unanswered security question.
Talos is an optional pure security-defect reasoner, not an auditor, implementer or orchestrator. Kael applies the Security Routing Gate only when an evidenced security boundary violation still needs specialist classification, trust-boundary, exploitability, cause, impact or bounded fix-direction reasoning. Functional-only bugs remain Argus territory; operational tooling failures, unpromised security features and optimization do not automatically route Talos. Talos receives Kael-supplied evidence, requests one bounded fact from Veyra or Nox through Kael when needed, and continues in the same session; two consultations normally suffice, three require a second discriminating round and a fourth automatic consultation is denied. No whole-repository audit or exploit execution is required. Vera still independently reviews a change, Thales remains a separate high-uncertainty gate, Atlas plans when needed, Kovan implements, and Kael owns completion. All 17 applicable post-merge non-live suites passed.
USER_EXECUTED_LIVE_EVIDENCE (not task-executed): Case A (Kael ses_f1d56d318ffed1ifg2je4sHOQf, Talos ses_f1d569e61ffeKTNR7mL4nZ0SGg, Veyra ses_f1d5650eaffee7Cn4Rql085IKm) verified runtime ID talos at openai/gpt-6-sol#high, one Talos session with two consultations: EVIDENCE_REQUEST followed by an evidence-backed SECURITY_DIAGNOSIS in that same session after bounded security/access-rule.txt evidence from a direct Kael-owned Veyra. The diagnosis compared the ADMIN-only DELETE_ACCOUNT boundary against MEMBER accepted, identified a likely guard accepting all non-GUEST roles while preserving runtime-link uncertainty, and bounded impact to the demonstrated non-admin crossing of an admin-only authorization boundary. Fix direction requires ADMIN; validate GUEST denied, MEMBER denied, ADMIN allowed. No direct Talos discovery, implementation, exploit execution, broad audit, third consultation, Argus, Atlas, Thales or Maintenance. Case B (Kael ses_f1d4251e0ffeXugAHMOPRQpCDw, Kovan ses_f1d422305ffey61RnQAE3q38xi) corrected REEDY to READY with Talos count zero and no other security/diagnostic specialists. Both families completed with pending and unknown zero. The generic Phase-3 observer's default case-A policy label on Case B was not a Talos failure; native child inspection established the zero count. Both cases were user-executed and were not rerun for integration; their disposable fixtures remain retained.
| Risk | Mitigation direction |
|---|---|
| Orchestration bureaucracy, role overlap, redundant discovery | Smallest sufficient handoff; explicit ownership; re-use focused evidence. |
| Runaway diagnostic loops, Thales overuse/underuse | Evidence budgets, no-progress stop, uncertainty gate and negative controls. |
| Atlas overplanning; Argus gap-vs-bug confusion; Talos security overclassification | Gate planning by complexity; classify against evidence before specialist routing. |
| Helios analysis costs more than benefit; third-party fork/patch debt | Baseline and expected-value stop; reversible containment first, explicit approval for patch/fork. |
Command ambiguity or sprawl, including confusion among FAST:, FAST qualification, fast path and Codex-native /fast |
Keep natural language and routing primary; preserve dependency, writer, validation and completion gates. |
| False completion | Join, collect, validate and report all required work, including descendants and external jobs. |