Prerequisites

• I will write this issue in English
• I searched existing issues and PRs for duplicates
• This is specific to oh-my-opencode / oh-my-openagent
• I reviewed the current Atlas prompts, Atlas hooks, and runtime behavior

Bug Description

Atlas currently has an internally inconsistent execution contract around plan files and post-verification behavior.

At a high level, Atlas is told the plan is read-only, but the post-task reminder pipeline also tells Atlas to update that same plan file immediately after verification. One prompt variant also still points Atlas at the wrong plan state path, and the reminder pipeline used to tell Atlas to commit directly even though the main Atlas role text says git work should be delegated.

This makes the Atlas role ambiguous in practice:

• Is the plan immutable once Prometheus writes it?
• Is Atlas allowed to change only execution status?
• Should Atlas commit directly, or should git work always be delegated?

Right now the code says different things in different places.

Evidence

1. Atlas prompts currently own the plan as the execution artifact

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

These prompt variants define .sisyphus/plans/{name}.md as the work-plan artifact Atlas should read while executing.

2. Atlas verification reminders also mutate the plan file immediately after verification

• Atlas verification reminders
• Atlas system reminder templates

The reminder pipeline explicitly instructs Atlas to:

• read the plan directly after verification
• mark task completion in the plan immediately
• continue execution from that updated state

That is a valid pattern if Atlas is allowed to make status-only updates, but the permission boundary is not stated clearly enough.

3. One prompt variant still used a stale plan-state path

• Atlas default prompt
• Boulder state storage

Atlas default still referenced .sisyphus/tasks/{plan-name}.yaml for the boulder ground truth, while the rest of the execution stack uses .sisyphus/plans/{name}.md.

That means Atlas can be pointed at the wrong state source depending on prompt variant.

4. Git responsibility is also contradictory

• Atlas default prompt
• Atlas GPT prompt
• Atlas verification reminders

Atlas role text says git operations should be delegated, but the reminder pipeline also instructed Atlas to stage and commit verified work directly.

Why This Matters

This is not just wording drift. It changes runtime behavior:

1. The model is forced to infer a mutability policy that is never stated explicitly.
2. Atlas can reasonably interpret "read-only plan" and "edit this plan right now" in conflicting ways.
3. The stale .sisyphus/tasks/*.yaml path can send Atlas to the wrong execution-state source.
4. The planner / executor / implementer boundary becomes blurry.

The core ambiguity is:

Atlas must not rewrite the plan
vs
Atlas must update the plan immediately

Those are only compatible if the system states the narrower policy clearly.

Expected Behavior

Atlas should have one explicit plan-mutation contract:

• Atlas MAY update checkbox / status markers in .sisyphus/plans/{name}.md after verification
• Atlas MAY NOT rewrite task wording
• Atlas MAY NOT add/remove/reorder tasks
• Atlas MAY NOT change dependencies or acceptance criteria
• Atlas should use one canonical plan path only: .sisyphus/plans/{name}.md

Git responsibility should also be coherent:

• either Atlas may commit verified work
• or Atlas must delegate commits

but not both at once.

Related Issues / Why This Is Not A Duplicate

This is related to, but not the same as:

• [Feature]: atlas should follow qa / testing manuals much better #1705 atlas should follow qa / testing manuals much better
• todo plan checkboxes keep re-triggering after tasks are completed #1562 todo plan checkboxes keep re-triggering after tasks are completed
• [BUG]: TODO/BOULDER Continuation enters infinite loop when remaining tasks are blocked on external action #2025 TODO/BOULDER Continuation enters infinite loop when remaining tasks are blocked on external action
• Prometheus READ-ONLY mode persists after /start-work, preventing task execution #864 Prometheus READ-ONLY mode persists after /start-work, preventing task execution

Those issues cover QA rigor, checkbox state bugs, continuation loops, or lingering read-only execution state.

This issue is specifically about the Atlas execution contract itself being internally inconsistent.

Proposed Solution

1. Define Atlas plan mutation policy explicitly in all prompt variants:
   • allowed: checkbox / status-only edits
   • forbidden: task-content / dependency / acceptance-criteria edits
2. Remove the stale .sisyphus/tasks/{plan-name}.yaml reference from Atlas prompts.
3. Reconcile git responsibility:
   • either Atlas commits
   • or Atlas delegates commits
4. Keep .sisyphus/plans/{name}.md as the single execution-state source of truth.