opencode-orchestrator 1.0.14 → 1.0.16

package/dist/index.js

@@ -907,6 +907,54 @@ var PHILOSOPHY_TAGLINE = "Explore \u2192 Learn \u2192 Adapt \u2192 Act";
 var PHILOSOPHY_QUOTE = "Like an astronaut landing on unknown planets \u2014 never assume, always discover.";
 var PHILOSOPHY_LEARN_PRINCIPLE = "LEARN = DOCUMENT: What you discover, you record. Your learnings become the team's knowledge.";
 
+// src/shared/prompt/constants/mandates.ts
+var MANDATES = {
+  /**
+   * Phase 0: Discovery Swarm Mandate
+   */
+  PHASE_0_SCOUT_SWARM: `**Mandatory Parallel Initialization**: DO NOT run discovery tools (ls, grep, find) yourself. Your job is to ORCHESTRATE. 
+
+1. **LAUNCH Parallel Scouts**: In your VERY FIRST response, output ALL '${TOOL_NAMES.DELEGATE_TASK}' calls (background: true) for:
+   - [Scout: Structure]: Map project tree via ${AGENT_NAMES.PLANNER}.
+   - [Scout: Stack]: Identify tech stack via ${AGENT_NAMES.PLANNER}.
+   - [Scout: Docs]: Digest README and architecture via ${AGENT_NAMES.PLANNER}.
+   - [Scout: Infra]: Detect CI/CD and Docker via ${AGENT_NAMES.PLANNER}.
+2. **BARRIER SYNC**: READ consolidated results from ${PATHS.CONTEXT} and scout sessions only AFTER all show'DONE'.`,
+  /**
+   * Phase 1: THINK (Strategic Mandate)
+   */
+  PHASE_1_THINK_ANALYSIS: `### 1.1 MISSION SCOPE
+- What is the FULL scope? What are the success criteria?
+- What does the user REALLY want?
+
+### 1.2 DECOMPOSITION
+- Break into INDEPENDENT sub-tasks.
+- Identify sequential dependencies vs parallel opportunities.
+
+### 1.3 DELEGATION
+- Choose best agent for each task (${AGENT_NAMES.PLANNER}/${AGENT_NAMES.WORKER}/${AGENT_NAMES.REVIEWER}).
+- Provide focused context for each.
+
+### 1.4 RISK ASSESSMENT
+- Identify high-risk parts and fallback plans.
+- If agent fails \u2192 See RECOVERY section.`,
+  /**
+   * Phase 5: MSVP (Multi-Stage Verification Pipeline)
+   */
+  PHASE_5_MSVP: `1. **STAGE 1 (Unit)**: Workers MUST trigger ${AGENT_NAMES.REVIEWER} for unit verification immediately upon completion.
+2. **STAGE 2 (Integration)**: ${AGENT_NAMES.REVIEWER} validates cross-module consistency.
+3. **E2E VALIDATION**: Run full system tests and build pass check.
+4. **SEAL GATE**: No SEALED output until ${PATHS.TODO} is all [x] and zero issues remain.`,
+  /**
+   * HPFA (Hyper-Parallel Fractal Architecture) Rules
+   */
+  HPFA_RULES: `1. **Fractal Spawning**: Workers spawn sub-workers for complex files/modules.
+2. **Speculative Racing**: Launch multiple strategies in parallel (mode: race) for uncertainty.
+3. **Asynchronous Batching**: Group non-dependent tool calls to trigger host-side parallelism.
+4. **Barrier-Sync Pipeline**: Reviewers start Unit Review (Stage 1) while other workers still run.
+5. **Real-time Brain Sync**: Parallel sessions share public interfaces via shared task logs.`
+};
+
 // src/core/agents/consts/task-status.const.ts
 var TASK_STATUS = {
   PENDING: STATUS_LABEL.PENDING,
@@ -13772,34 +13820,9 @@ var HYPER_PARALLEL_ENFORCEMENT = `${PROMPT_TAGS.QUALITY_CHECKLIST.open}
 
 To achieve maximum velocity, you MUST leverage these advanced parallel execution patterns:
 
-### 1. Fractal Self-Delegation (Recursive Scaling)
-If you are a Worker and your assigned task is complex (e.g., implementing multiple endpoints, refactoring several files), **do not do it sequentially**.
--   **Spawn Sub-Workers**: Use \`delegate_task\` to launch sub-agents for independent sub-components.
--   **Fractal Depth**: You can scale down to any depth. Each worker acts as a local coordinator for its sub-workers.
--   **Context Sharding**: Give each sub-worker a focused, atomic prompt and relevant file context.
-
-### 2. Speculative Racing (Competitive Implementation)
-When faced with a high-uncertainty problem (bug fixing, complex refactoring with multiple possible approaches):
--   **Launch a Race**: Spawn multiple Workers (\`mode: "race"\`) with slightly different prompts or strategies.
--   **Winning Criteria**: The first agent to produce a solution that passes unit tests "wins".
--   **Efficiency**: This eliminates the "try-fail-repeat" loop by trying all likely solutions simultaneously.
-
-### 3. Asynchronous Batching
-When you need to perform many independent reads or metadata checks:
--   **Batch Operations**: Group your tool calls to trigger massive parallel execution host-side.
--   **Avoid Serial Bottlenecks**: Never wait for a tool result if you have other independent tasks you could be launching in parallel.
-
-### 4. Barrier-Sync Integrated Pipeline (BSIP)
-Don't wait for all workers to finish before starting reviews:
--   **Pipelined Verification**: Immediately spawn a Reviewer task as soon as a Worker finishes its individual sub-task. The review of Module A happens while Module B is still being built.
--   **Synchronization Point**: Use the "Final Sync Barrier" to wait for all parallel implementation AND individual reviews to complete.
--   **Global Integration**: The final master Reviewer only acts once all individual units have been verified by their respective sub-reviewers.
-
-### 5. Real-time Brain Sync
-As you work in a parallel session, log your critical findings or discovered interface changes to the shared task log. 
-Assume that:
--   **Global Awareness**: Other workers are aware of your public findings.
--   **Consistency**: You must check for "Global Context Updates" to ensure your parallel work aligns with the latest state of the system.
+${MANDATES.HPFA_RULES}
+
+[CRITICAL]: Sequential execution when parallel is possible is a mission failure.
 ${PROMPT_TAGS.QUALITY_CHECKLIST.close}`;
 
 // src/agents/prompts/commander/role.ts
@@ -13906,41 +13929,12 @@ ${PROMPT_TAGS.TOOLS.close}`;
 // src/agents/prompts/commander/execution.ts
 var COMMANDER_EXECUTION = `${PROMPT_TAGS.EXECUTION_STRATEGY.open}
 ## ${PHASES.PHASE_0.ID}: ${PHASES.PHASE_0.NAME} (Cognitive Velocity Launch)
-**Mandatory High-Velocity Initialization**: Do not perform discovery sequentially. Launch a swarm of scouts immediately.
-
-1. **Initialize \`${PATHS.OPENCODE}\` folder**:
-   - Immediate setup for CONTEXT SHARING (DELETE existing if fresh start).
-2. **LAUNCH Parallel Discovery Tasks (background=true)**:
-   - **[Scout: Structure]**: Analyze project tree (ls, find) at depth 2-3.
-   - **[Scout: Stack]**: Parse package.json, Cargo.toml, or pyproject.toml for identity.
-   - **[Scout: Docs]**: Analyze README.md, CONTRIBUTING.md, and core architecture docs.
-   - **[Scout: Infra]**: Detect Docker, CI/CD pipelines, and environment variables.
-3. **BARRIER SYNC & RETRIEVE**: Monitor scouts. Once finished, **READ all scout results** and \`${PATHS.CONTEXT}\` to ingest all findings.
-4. **SET TARGET**: Use the unified context to proceed to Phase 1.
+${MANDATES.PHASE_0_SCOUT_SWARM}
 
 ## ${PHASES.PHASE_1.ID}: ${PHASES.PHASE_1.NAME} (Mandatory - Never Skip!)
 **THINK FIRST**: As ${AGENT_NAMES.COMMANDER}, think about ORCHESTRATION and synthesis before action.
 
-### 1.1 MISSION SCOPE
-- What is the FULL scope of this mission?
-- What are the deliverables and success criteria?
-- What does the user REALLY want (not just what they said)?
-
-### 1.2 DECOMPOSITION
-- How can I break this into INDEPENDENT sub-tasks?
-- Which tasks MUST be sequential (dependencies)?
-- What is the MAXIMUM parallelism I can achieve?
-
-### 1.3 DELEGATION
-- Which agent is BEST for each task? (${AGENT_NAMES.PLANNER}/${AGENT_NAMES.WORKER}/${AGENT_NAMES.REVIEWER})
-- What context does each agent NEED to succeed?
-- What could cause an agent to FAIL or get stuck?
-
-### 1.4 RISK ASSESSMENT
-- What are the HIGH-RISK parts of this mission?
-- What is my FALLBACK if a task fails?
-- How will I DETECT and RECOVER from issues?
-- If agent fails \u2192 See ${PROMPT_TAGS.RECOVERY.open} section: DECOMPOSE and retry
+${MANDATES.PHASE_1_THINK_ANALYSIS}
 
 **ANTI-PATTERNS**: Sequential execution when parallel is possible. Doing work yourself instead of delegating. Starting without clear decomposition or intellectual synthesis.
 
@@ -13962,10 +13956,7 @@ ${AGENT_NAMES.PLANNER} creates ${PATHS.TODO} with parallel groups
 5. REPEAT until all [ ] become [x]
 
 ## ${PHASES.PHASE_5.ID}: ${PHASES.PHASE_5.NAME}
-1. **STAGE 1 (Unit)**: Reviewers validate individual module changes (triggered by Workers).
-2. **STAGE 2 (Integration)**: ${AGENT_NAMES.REVIEWER} validates cross-module consistency.
-3. **E2E VALIDATION**: Run full system tests and build pass check.
-4. Only proceed to SEAL if all criteria are met with zero regressions.
+${MANDATES.PHASE_5_MSVP}
 
 ## ${PHASES.PHASE_6.ID}: ${PHASES.PHASE_6.NAME}
 When ALL conditions met, output ${MISSION_SEAL.PATTERN}
@@ -14637,7 +14628,6 @@ var WORKER_WORKFLOW = `${PROMPT_TAGS.WORKFLOW.open}
 ADAPTIVE IMPLEMENTATION WORKFLOW
 
 ## Phase 1: UNDERSTAND (Before writing ANY code)
-
 1. Read ${PATHS.CONTEXT} \u2192 Get project environment, build/test commands
 2. Read ${PATHS.TODO} \u2192 Understand assigned task and acceptance criteria
 3. Read ${PATHS.DOCS}/ \u2192 Check for cached API docs, syntax references
@@ -14648,7 +14638,6 @@ ADAPTIVE IMPLEMENTATION WORKFLOW
    # Find related files
    find . -name "*.ts" -o -name "*.py" -o -name "*.go" | head -${LIMITS.DEFAULT_SCAN_LIMIT}
    \`\`\`
-
 5. Study existing PATTERNS:
    - How are errors handled?
    - How are tests structured?
@@ -14660,20 +14649,16 @@ ADAPTIVE IMPLEMENTATION WORKFLOW
    - Use **${TOOL_NAMES.WEBSEARCH}** to find official docs
    - Use **${TOOL_NAMES.WEBFETCH}** to read URL content
    - Use **${TOOL_NAMES.CACHE_DOCS}** to save to ${PATHS.DOCS}/
-   - Example: \`${TOOL_NAMES.WEBSEARCH}({ query: "[library] [version] API docs" })\`
 
 ## Phase 4: IMPLEMENT (Following discoveries)
 7. Write code following OBSERVED patterns
 8. Handle edge cases like existing code does
 9. Add tests matching project's test style
 
-## Phase 5: VERIFY & TRIGGER SHADOW REVIEW
-10. Run ${TOOL_NAMES.LSP_DIAGNOSTICS} \u2192 Must be clean
-11. Run BUILD & TEST commands from ${PATHS.CONTEXT}
-12. **TRIGGER STAGE 1 REVIEW**: 
-    - Before finishing, ${TOOL_NAMES.DELEGATE_TASK} to **${AGENT_NAMES.REVIEWER}** for unit verification.
-    - Prompt: "Verify unit changes in [your module] for mission [mission_id]. Run tests and check diagnostics."
-13. Report completion WITH evidence (test logs, review status).
+## Phase 5: VERIFY & MSVP STAGE 1
+${MANDATES.PHASE_5_MSVP}
+
+[ACTION]: Use ${TOOL_NAMES.DELEGATE_TASK} to trigger ${AGENT_NAMES.REVIEWER} for Unit Verification before reporting DONE.
 
 **CRITICAL**: Do NOT mark [x] in ${PATHS.TODO} - that's ${AGENT_NAMES.REVIEWER}'s job after Stage 2!
 ${PROMPT_TAGS.WORKFLOW.close}`;

package/dist/shared/prompt/constants/index.d.ts

@@ -4,3 +4,4 @@
 export { PROMPT_TAGS, wrapTag } from "./tags.js";
 export { WORK_STATUS } from "./status.js";
 export { PHILOSOPHY_PHASES, PHILOSOPHY_TAGLINE, PHILOSOPHY_QUOTE, PHILOSOPHY_LEARN_PRINCIPLE, EXECUTION_CYCLE, EXECUTION_CYCLE_STEPS, } from "./philosophy.js";
+export { MANDATES } from "./mandates.js";

package/dist/shared/prompt/constants/mandates.d.ts

@@ -0,0 +1,24 @@
+/**
+ * Architectural Mandates - Immutable Core Logic
+ *
+ * These constants define the non-negotiable architectural requirements
+ * that ensure the orchestrator operates according to the verified diagram.
+ */
+export declare const MANDATES: {
+    /**
+     * Phase 0: Discovery Swarm Mandate
+     */
+    readonly PHASE_0_SCOUT_SWARM: "**Mandatory Parallel Initialization**: DO NOT run discovery tools (ls, grep, find) yourself. Your job is to ORCHESTRATE. \n\n1. **LAUNCH Parallel Scouts**: In your VERY FIRST response, output ALL 'delegate_task' calls (background: true) for:\n   - [Scout: Structure]: Map project tree via Planner.\n   - [Scout: Stack]: Identify tech stack via Planner.\n   - [Scout: Docs]: Digest README and architecture via Planner.\n   - [Scout: Infra]: Detect CI/CD and Docker via Planner.\n2. **BARRIER SYNC**: READ consolidated results from .opencode/context.md and scout sessions only AFTER all show'DONE'.";
+    /**
+     * Phase 1: THINK (Strategic Mandate)
+     */
+    readonly PHASE_1_THINK_ANALYSIS: "### 1.1 MISSION SCOPE\n- What is the FULL scope? What are the success criteria?\n- What does the user REALLY want?\n\n### 1.2 DECOMPOSITION\n- Break into INDEPENDENT sub-tasks.\n- Identify sequential dependencies vs parallel opportunities.\n\n### 1.3 DELEGATION\n- Choose best agent for each task (Planner/Worker/Reviewer).\n- Provide focused context for each.\n\n### 1.4 RISK ASSESSMENT\n- Identify high-risk parts and fallback plans.\n- If agent fails → See RECOVERY section.";
+    /**
+     * Phase 5: MSVP (Multi-Stage Verification Pipeline)
+     */
+    readonly PHASE_5_MSVP: "1. **STAGE 1 (Unit)**: Workers MUST trigger Reviewer for unit verification immediately upon completion.\n2. **STAGE 2 (Integration)**: Reviewer validates cross-module consistency.\n3. **E2E VALIDATION**: Run full system tests and build pass check.\n4. **SEAL GATE**: No SEALED output until .opencode/todo.md is all [x] and zero issues remain.";
+    /**
+     * HPFA (Hyper-Parallel Fractal Architecture) Rules
+     */
+    readonly HPFA_RULES: "1. **Fractal Spawning**: Workers spawn sub-workers for complex files/modules.\n2. **Speculative Racing**: Launch multiple strategies in parallel (mode: race) for uncertainty.\n3. **Asynchronous Batching**: Group non-dependent tool calls to trigger host-side parallelism.\n4. **Barrier-Sync Pipeline**: Reviewers start Unit Review (Stage 1) while other workers still run.\n5. **Real-time Brain Sync**: Parallel sessions share public interfaces via shared task logs.";
+};

package/package.json

@@ -2,7 +2,7 @@
   "name": "opencode-orchestrator",
   "displayName": "OpenCode Orchestrator",
   "description": "Distributed Cognitive Architecture for OpenCode. Turns simple prompts into specialized multi-agent workflows (Planner, Coder, Reviewer).",
-  "version": "1.0.14",
+  "version": "1.0.16",
   "author": "agnusdei1207",
   "license": "MIT",
   "repository": {