Merge pull request #2705 from MoerAI/fix/sisyphus-premature-implementation

fix(sisyphus): block premature implementation before context is complete (fixes #2274)

src/agents/dynamic-agent-prompt-builder.ts

@@ -308,6 +308,12 @@ Briefly announce "Consulting Oracle for [reason]" before invocation.
 
 **Collect Oracle results before your final answer. No exceptions.**
 
+**Oracle-dependent implementation is BLOCKED until Oracle finishes.**
+
+- If you asked Oracle for architecture/debugging direction that affects the fix, do not implement before Oracle result arrives.
+- While waiting, only do non-overlapping prep work. Never ship implementation decisions Oracle was asked to decide.
+- Never "time out and continue anyway" for Oracle-dependent tasks.
+
 - Oracle takes minutes. When done with your own work: **end your response** — wait for the \`<system-reminder>\`.
 - Do NOT poll \`background_output\` on a running Oracle. The notification will come.
 - Never cancel Oracle.

src/agents/sisyphus.ts

@@ -127,6 +127,12 @@ This verbalization anchors your routing decision and makes your reasoning transp
 - **Open-ended** ("Improve", "Refactor", "Add feature") → Assess codebase first
 - **Ambiguous** (unclear scope, multiple interpretations) → Ask ONE clarifying question
 
+### Step 1.5: Turn-Local Intent Reset (MANDATORY)
+
+- Reclassify intent from the CURRENT user message only. Never auto-carry "implementation mode" from prior turns.
+- If current message is a question/explanation/investigation request, answer/analyze only. Do NOT create todos or edit files.
+- If user is still giving context or constraints, gather/confirm context first. Do NOT start implementation yet.
+
 ### Step 2: Check for Ambiguity
 
 - Single valid interpretation → Proceed
@@ -135,6 +141,15 @@ This verbalization anchors your routing decision and makes your reasoning transp
 - Missing critical info (file, error, context) → **MUST ask**
 - User's design seems flawed or suboptimal → **MUST raise concern** before implementing
 
+### Step 2.5: Context-Completion Gate (BEFORE Implementation)
+
+You may implement only when ALL are true:
+1. The current message contains an explicit implementation verb (implement/add/create/fix/change/write).
+2. Scope/objective is sufficiently concrete to execute without guessing.
+3. No blocking specialist result is pending that your implementation depends on (especially Oracle).
+
+If any condition fails, do research/clarification only, then wait.
+
 ### Step 3: Validate Before Acting
 
 **Assumptions Check:**

src/agents/sisyphus/gpt-5-4.ts

@@ -167,6 +167,11 @@ Complexity:
 - Open-ended ("improve", "refactor") → assess codebase first, then propose
 - Ambiguous (multiple interpretations with 2x+ effort difference) → ask ONE question
 
+Turn-local reset (mandatory): classify from the CURRENT user message, not conversation momentum.
+- Never carry implementation mode from prior turns.
+- If current turn is question/explanation/investigation, answer or analyze only.
+- If user appears to still be providing context, gather/confirm context first and wait.
+
 Domain guess (provisional — finalized in ROUTE after exploration):
 - Visual (UI, CSS, styling, layout, design, animation) → likely visual-engineering
 - Logic (algorithms, architecture, complex business logic) → likely ultrabrain
@@ -184,6 +189,11 @@ Step 2 — Check before acting:
 - Missing critical info → ask
 - User's design seems flawed → raise concern concisely, propose alternative, ask if they want to proceed anyway
 
+Context-completion gate before implementation:
+- Implement only when the current message explicitly requests implementation (implement/add/create/fix/change/write),
+  scope is concrete enough to execute without guessing, and no blocking specialist result is pending.
+- If any condition fails, continue with research/clarification only and wait.
+
 <ask_gate>
 Proceed unless:
 (a) the action is irreversible,