Prerequisites

• I will write this issue in English
• I searched existing issues and PRs for duplicates
• This request is specific to oh-my-opencode / oh-my-openagent
• I reviewed the current Prometheus and Atlas planning/execution code paths

Problem Description

Prometheus is already required to produce execution-ready metadata:

• task dependency graph
• parallel execution graph
• per-task delegation recommendation
• per-task category recommendation
• per-task skill recommendation

However, Atlas does not currently consume that output as an authoritative execution contract. Atlas still re-parses the plan and re-derives parallelization and category choice at execution time.

That weakens the planner / executor separation and makes runtime behavior harder to predict and audit than the architecture suggests.

Evidence

1. Prometheus is explicitly required to emit execution metadata

• delegate-task planning constants
• Prometheus plan template
• Prometheus GPT prompt

The planning contract explicitly requires:

• dependency graph
• parallel execution graph
• recommended category + skills per task
• explicit task-level execution metadata

The output format already includes blocks like:

### Task N
**Delegation Recommendation**
- Category: ...
- Skills: ...
**Depends On**: ...

and in the newer plan format:

**Recommended Agent Profile**
- Category: ...
- Skills: ...
**Parallelization**
...

2. Atlas still re-analyzes the plan instead of defaulting to planner metadata

• Atlas default prompt
• Atlas GPT prompt
• Atlas Gemini prompt

Atlas is still instructed to:

• read the plan
• parse incomplete checkboxes
• build its own parallelization map
• choose delegation routing dynamically

That means the current implementation behaves more like:

Prometheus proposes execution structure
Atlas re-decides execution structure

than:

Prometheus defines execution structure
Atlas executes it

3. The Atlas decision matrix is generic fallback guidance, not a plan-bound contract

• Atlas prompt section builder

Atlas gets a generic category / agent decision matrix, but that matrix is not bound to the current task block in the plan. So Atlas can still classify the task ad hoc even when Prometheus already wrote a recommendation.

4. Runtime behavior reflects this drift

In local Atlas runtime evidence, Atlas dynamically routed work across:

• visual-engineering
• unspecified-high
• deep
• writing
• quick
• explore
• librarian
• oracle

That flexibility can be useful, but it also confirms Atlas is acting as a live execution planner rather than a strict dispatcher of Prometheus decisions.

Why This Matters

The current architecture looks like:

Prometheus -> Plan
Atlas -> Execute the plan

But the effective runtime contract is closer to:

Prometheus -> Plan
Atlas -> Re-interpret plan -> Choose routing again -> Execute

That creates several problems:

1. Prometheus output is less authoritative than the system implies.
2. Atlas category / model behavior is harder to reason about.
3. Planner intent vs runtime execution is harder to audit.
4. It becomes difficult to tell whether failures came from the plan itself or from Atlas re-routing around it.

Expected Behavior

Atlas should treat Prometheus execution metadata as authoritative by default.

If a task already specifies:

• dependencies
• execution wave / parallelization
• category
• skills

then Atlas should use that directly unless there is a concrete runtime reason to override it.

Suggested contract:

Planner output is binding by default.
Atlas may override only with an explicit justification.

Related Issues / Why This Is Not A Duplicate

This is related to, but not the same as:

• [Feature]: Atlas subagent rules to get better result of plan execution #1309 Atlas subagent rules to get better result of plan execution
• [Feature]: atlas should follow qa / testing manuals much better #1705 atlas should follow qa / testing manuals much better
• [Feature]: Persistent plan/todo tracking and checkpoints between plans #1688 Persistent plan/todo tracking and checkpoints between plans
• [feedback]: Orchestration is too aggressive, some behaviours are dangerous/destructive #1081 Orchestration is too aggressive, some behaviours are dangerous/destructive

Those issues focus on rule-following quality, QA rigor, state tracking, or orchestration aggressiveness.

This issue is specifically about planner / executor boundary drift:

• Prometheus already emits execution metadata
• Atlas should honor it instead of silently re-planning execution

Proposed Solution

1. Parse and extract Prometheus execution metadata from the plan as structured input, or at minimum treat the existing task block metadata as authoritative when present.
2. Use Delegation Recommendation, Recommended Agent Profile, Depends On, and wave / parallelization information as the default execution contract.
3. Allow Atlas to override category / skills / ordering only when:
   • verification reveals a mismatch
   • a blocker changes the dependency graph
   • the planner clearly misclassified the task
4. When Atlas overrides, require a short explicit note in-session:
   • planned category / wave
   • actual category / wave
   • concrete reason for override