speccrew 0.7.57 → 0.7.59

package/.speccrew/agents/speccrew-system-designer.md

@@ -36,7 +36,10 @@ Phase 4: Generate DESIGN-OVERVIEW.md (WORKER-DISPATCH + HARD STOP)
         ↓
 Phase 5: Dispatch Per-Platform Skills
   ├── Single Feature + Single Platform → Direct skill invocation
-  └── Multi-Feature or Multi-Platform → Worker dispatch (batch of 6)
+  └── Multi-Feature or Multi-Platform → Worker dispatch (batch of 6, skip_confirmation + skip_index_generation)
+        ↓
+Phase 5.5: Generate Platform INDEX.md (AGENT-OWNED)
+  └── Orchestrator generates INDEX.md per platform after all workers complete
         ↓
 Phase 6: Joint Confirmation (HARD STOP)
   └── Present all designs → User confirms → Finalize stage
@@ -59,6 +62,7 @@ This agent is an **orchestrator/dispatcher**. For system design execution (Phase
 This agent MAY directly create/modify ONLY the following files:
 - ✅ `DISPATCH-PROGRESS.json` (via update-progress.js script only)
 - ✅ `.checkpoints.json` (via update-progress.js script only)
+- ✅ `INDEX.md` per platform directory (AGENT-OWNED — generated by orchestrator after all workers complete, NOT by workers in batch mode)
 - ✅ Progress summary messages to user
 
 > Note: `framework-evaluation.md` is generated **ONLY** by the `speccrew-sd-framework-evaluate` skill.
@@ -74,7 +78,7 @@ This agent MAY directly create/modify ONLY the following files:
 3. ❌ DO NOT invoke `speccrew-sd-mobile` skill directly
 4. ❌ DO NOT invoke `speccrew-sd-desktop` skill directly
 5. ❌ DO NOT generate `*-design.md` files yourself
-6. ❌ DO NOT generate platform `INDEX.md` files yourself
+6. ❌ DO NOT let individual workers generate platform `INDEX.md` in batch mode — orchestrator generates INDEX.md in Phase 5.5 (AGENT-OWNED)
 7. ❌ DO NOT create design document content as fallback if worker fails
 
 ### Violation Recovery
@@ -128,6 +132,8 @@ This agent MUST execute tasks continuously without unnecessary interruptions.
 | Phase 3 | HARD STOP | User must confirm framework decisions before proceeding to Phase 4 |
 | Phase 4 | WORKER-DISPATCH + HARD STOP | DESIGN-OVERVIEW.md generation MUST be dispatched to speccrew-task-worker via **Agent tool**. After worker completes, present summary to user and WAIT for confirmation before Phase 5. |
 | Phase 5 | SKILL-ONLY | Platform design workers MUST use platform-specific design skills. Agent MUST NOT write design documents itself |
+| Phase 5 | SKIP-CONFIRMATION | Batch dispatch MUST include `skip_confirmation: true` and `skip_index_generation: true` in worker context. Workers skip Checkpoint A and Step 5 in batch mode |
+| Phase 5.5 | AGENT-OWNED-INDEX | After all workers complete, orchestrator generates INDEX.md per platform. Workers MUST NOT generate INDEX.md in batch mode |
 | Phase 6 | HARD STOP | User must confirm all designs before finalizing |
 | ALL | ABORT ON FAILURE | If any skill invocation fails → STOP and report. Do NOT generate content manually as fallback |
 | ALL | SCRIPT ENFORCEMENT | All .checkpoints.json and WORKFLOW-PROGRESS.json updates via update-progress.js script. Manual JSON creation FORBIDDEN |
@@ -786,6 +792,22 @@ node {update_progress_script} update-task --file {iterations_dir}/{current}/03.s
 
 All workers execute simultaneously to maximize efficiency.
 
+> 🛑 **CRITICAL: Phase 5 dispatch-to-worker Protocol**
+> 1. **ONE Worker per Feature×Platform combination** — DO NOT group
+> 2. Use **Agent tool** to create `speccrew-task-worker` for each task
+> 3. Pass `skill_path`: `${ide_skills_dir}/${skill_name}/SKILL.md` (platform-specific skill)
+> 4. Pass context: task_id, feature_id, feature_name, platform_id, feature_spec_path, api_contract_path, techs_knowledge_paths, framework_decisions, output_base_path, **skip_confirmation: true**, **skip_index_generation: true**
+> 5. Dispatch ALL Workers in the same batch **SIMULTANEOUSLY** in a single turn
+> 6. **Wait** for ALL Workers in the batch to complete before dispatching next batch
+> 7. Update DISPATCH-PROGRESS.json after each Worker completes
+> 8. After ALL workers complete, generate INDEX.md for each platform directory (AGENT-OWNED task — see Phase 5.5 in orchestration SKILL.md)
+> **FORBIDDEN**:
+> - ❌ DO NOT group multiple features into one Worker
+> - ❌ DO NOT use Skill tool to invoke platform skills (when Features ≥ 2 OR Platforms ≥ 2)
+> - ❌ DO NOT dispatch Workers sequentially — ALL in same batch must be simultaneous
+> - ❌ DO NOT generate *-design.md files yourself as fallback
+> - ❌ DO NOT let individual workers generate INDEX.md in batch mode — set `skip_index_generation: true`; orchestrator generates INDEX.md after all workers complete
+
 ### 5.5 Update DISPATCH-PROGRESS.json
 
 After each worker completes, parse its **Task Completion Report** and update:
@@ -1074,6 +1096,7 @@ Otherwise
 - DO NOT create or manually edit DISPATCH-PROGRESS.json, .checkpoints.json, or WORKFLOW-PROGRESS.json — use update-progress.js script only
 - DO NOT update WORKFLOW-PROGRESS.json status to "confirmed" before joint user confirmation in Phase 6
 - DO NOT proceed to the next batch or Phase 6 if any Phase 5 batch worker failure rate > 50% — follow the Batch Failure recovery flow in Phase 5.6
+- DO NOT let individual workers generate INDEX.md in batch mode — set `skip_index_generation: true` in worker context; orchestrator generates INDEX.md in Phase 5.5 (AGENT-OWNED)
 - DO NOT skip backward compatibility checks for old format Feature Specs
 - DO NOT automatically transition to or invoke the next stage agent — user starts next stage in a new conversation
 

package/.speccrew/skills/speccrew-sd-backend/SKILL.md

@@ -34,6 +34,8 @@ tools: Read, Write, Glob, Grep
 - `feature_id` (optional): Feature identifier, e.g., `F-CRM-01`. If provided, use new naming format.
 - `feature_name`: Feature name, e.g., `customer-list`.
 - `platform_id`: Target platform, e.g., `backend-spring`, `backend-nestjs`.
+- `skip_confirmation` (optional, boolean): When `true`, skip Checkpoint A user confirmation (used in batch dispatch mode)
+- `skip_index_generation` (optional, boolean): When `true`, skip Step 5 INDEX.md generation (INDEX.md will be generated by orchestrator after all workers complete)
 
 Read in order:
 
@@ -88,7 +90,11 @@ Mark each function as:
 | `[MODIFIED]` | Modify existing implementation |
 | `[NEW]` | Create brand new implementation |
 
-**Checkpoint A: Present function list with markers to user for confirmation before proceeding.**
+**Checkpoint A**:
+- If `skip_confirmation` = `true`: Log the function list with markers and **proceed automatically** without waiting for user confirmation.
+- If `skip_confirmation` is not set or `false`: Present function list with markers to user and **wait for explicit confirmation** before proceeding.
+
+> ⚠️ **FORBIDDEN**: Worker MUST NOT self-decide to skip confirmation. Only the `skip_confirmation` parameter from dispatch context controls this behavior.
 
 ## Step 4: Generate Module Design Documents
 
@@ -160,6 +166,8 @@ Verify the completed design document:
 
 ## Step 5: Generate Platform INDEX.md
 
+> **Conditional Execution**: If `skip_index_generation` = `true`, **skip this entire Step 5** and proceed to completion. INDEX.md will be generated by the orchestrator after all platform workers complete.
+
 After all module designs are complete:
 
 ### 5.1 Read Index Template
@@ -311,7 +319,7 @@ When generating Mermaid diagrams, follow compatibility guidelines:
 - [ ] Feature Spec and API Contract read and understood
 - [ ] Existing codebase structure analyzed (Glob/Grep)
 - [ ] Function extraction completed with [EXISTING]/[MODIFIED]/[NEW] markers
-- [ ] Checkpoint A passed: function list confirmed with user
+- [ ] Checkpoint A passed: function list confirmed (or skipped via skip_confirmation)
 - [ ] Every API in API Contract has a corresponding implementation design
 - [ ] Database entities cover all data requirements from Feature Spec
 - [ ] Transaction boundaries defined for multi-step operations

package/.speccrew/skills/speccrew-sd-frontend/SKILL.md

@@ -34,6 +34,8 @@ tools: Read, Write, Glob, Grep
 - `feature_id` (optional): Feature identifier, e.g., `F-CRM-01`. If provided, use new naming format.
 - `feature_name`: Feature name, e.g., `customer-list`.
 - `platform_id`: Target platform, e.g., `frontend-vue`, `frontend-react`.
+- `skip_confirmation` (optional, boolean): When `true`, skip Checkpoint A user confirmation (used in batch dispatch mode)
+- `skip_index_generation` (optional, boolean): When `true`, skip Step 5 INDEX.md generation (INDEX.md will be generated by orchestrator after all workers complete)
 
 Read in order:
 
@@ -86,7 +88,11 @@ Mark each function's components as:
 | `[MODIFIED]` | Enhance/change existing | `[MODIFIED] OrderTable - add new column` |
 | `[NEW]` | Create brand new | `[NEW] ProductDetailDrawer` |
 
-**Checkpoint A: Present function extraction summary to user for confirmation.**
+**Checkpoint A**:
+- If `skip_confirmation` = `true`: Log the function extraction summary and **proceed automatically** without waiting for user confirmation.
+- If `skip_confirmation` is not set or `false`: Present function extraction summary to user and **wait for explicit confirmation** before proceeding.
+
+> ⚠️ **FORBIDDEN**: Worker MUST NOT self-decide to skip confirmation. Only the `skip_confirmation` parameter from dispatch context controls this behavior.
 
 ## Step 4: Generate Module Design Documents
 
@@ -143,6 +149,8 @@ Verify the completed design document:
 
 ## Step 5: Generate Platform INDEX.md
 
+> **Conditional Execution**: If `skip_index_generation` = `true`, **skip this entire Step 5** and proceed to completion. INDEX.md will be generated by the orchestrator after all platform workers complete.
+
 After all module designs are complete:
 
 ### 5.1 Read Template
@@ -286,7 +294,7 @@ After completing all steps, output a structured completion report for the System
 - [ ] Directory structure follows conventions-design.md
 - [ ] INDEX.md generated with complete module list
 - [ ] All files written to correct paths under 03.system-design/{platform_id}/
-- [ ] Checkpoint A passed: function extraction confirmed with user
+- [ ] Checkpoint A passed: function extraction confirmed (or skipped via skip_confirmation)
 - [ ] **No TODO/FIXME placeholders** — all components and methods have complete pseudocode
 - [ ] **API routes match API Contract exactly** — verified route-by-route
 - [ ] **Cross-Feature dependencies explicitly marked** — all `[DEPENDENCY: F-XXX-NNN]` tags present with degradation strategy

package/.speccrew/skills/speccrew-sd-mobile/SKILL.md

@@ -30,6 +30,13 @@ tools: Read, Write, Glob, Grep
 
 ## Step 1: Read Inputs
 
+**Input Parameters** (from agent context):
+- `feature_id` (optional): Feature identifier, e.g., `F-CRM-01`.
+- `feature_name`: Feature name, e.g., `customer-list`.
+- `platform_id`: Target platform, e.g., `mobile-uniapp`, `mobile-flutter`.
+- `skip_confirmation` (optional, boolean): When `true`, skip Checkpoint A user confirmation (used in batch dispatch mode)
+- `skip_index_generation` (optional, boolean): When `true`, skip Step 5 INDEX.md generation (INDEX.md will be generated by orchestrator after all workers complete)
+
 Read in order:
 
 1. **Feature Spec document(s)**: `speccrew-workspace/iterations/{number}-{type}-{name}/02.feature-design/[feature-name]-feature-spec.md`
@@ -80,7 +87,11 @@ Mark each function's screens/widgets as:
 | `[MODIFIED]` | Enhance/change existing | `[MODIFIED] OrderList - add pull-to-refresh` |
 | `[NEW]` | Create brand new | `[NEW] ProductDetailPage` |
 
-**Checkpoint A: Present function extraction summary to user for confirmation.**
+**Checkpoint A**:
+- If `skip_confirmation` = `true`: Log the function extraction summary and **proceed automatically** without waiting for user confirmation.
+- If `skip_confirmation` is not set or `false`: Present function extraction summary to user and **wait for explicit confirmation** before proceeding.
+
+> ⚠️ **FORBIDDEN**: Worker MUST NOT self-decide to skip confirmation. Only the `skip_confirmation` parameter from dispatch context controls this behavior.
 
 ## Step 4: Generate Module Design Documents
 
@@ -136,6 +147,8 @@ Verify the completed design document:
 
 ## Step 5: Generate Platform INDEX.md
 
+> **Conditional Execution**: If `skip_index_generation` = `true`, **skip this entire Step 5** and proceed to completion. INDEX.md will be generated by the orchestrator after all platform workers complete.
+
 After all module designs are complete:
 
 ### 5.1 Read Template
@@ -279,7 +292,7 @@ After completing all steps, output a structured completion report for the System
 - [ ] App lifecycle handling documented
 - [ ] INDEX.md generated with complete module list
 - [ ] All files written to correct paths under 03.system-design/{platform_id}/
-- [ ] **Checkpoint A passed**: function extraction confirmed with user
+- [ ] **Checkpoint A passed**: function extraction confirmed (or skipped via skip_confirmation)
 - [ ] **No TODO/FIXME placeholders** — all screens and methods have complete pseudocode
 - [ ] **API routes match API Contract exactly** — verified route-by-route
 - [ ] **Cross-Feature dependencies explicitly marked** — all `[DEPENDENCY: F-XXX-NNN]` tags present with degradation strategy

package/.speccrew/skills/speccrew-system-designer-orchestration/SKILL.md

@@ -119,11 +119,56 @@ This skill MUST execute tasks continuously without unnecessary interruptions.
 
 **CRITICAL**: The `Agent tool` creates a NEW agent session — this is completely different from the `Skill tool` which executes inline.
 
+### Phase 5 Execution Method — Feature×Platform Worker Dispatch
+
+**DISPATCH GRANULARITY**: ONE Worker per Feature×Platform combination — NO EXCEPTIONS.
+
+**HOW TO DISPATCH**: When executing Phase 5 dispatch blocks (action="dispatch-to-worker"):
+1. Build Feature×Platform matrix from DESIGN-OVERVIEW.md Platform Design Index
+2. Create `.tasks-temp.json` with one entry per Feature×Platform combination
+3. Initialize DISPATCH-PROGRESS.json via `update-progress.js init`
+4. Compute batch plan (batch size = 6)
+5. For each batch:
+   a. Use **Agent tool** to create `speccrew-task-worker` agents for ALL tasks in the batch **SIMULTANEOUSLY**
+   b. Each Worker receives: `skill_path` (platform-specific skill), `task_id`, `feature_id`, `feature_name`, `platform_id`, `feature_spec_path`, `api_contract_path`, `techs_knowledge_paths`, `framework_decisions`, `output_base_path`, `skip_confirmation: true`, `skip_index_generation: true`
+   c. **Wait** for ALL Workers in the batch to complete
+   d. Update DISPATCH-PROGRESS.json for each completed Worker
+   e. Log batch progress
+6. After all batches complete, read final progress summary
+7. Generate INDEX.md for each platform (AGENT-OWNED, see Phase 5.5)
+
+**CRITICAL**: Each Worker handles exactly ONE feature on ONE platform. DO NOT group multiple features or platforms into a single Worker.
+
+**Batch Dispatch Context Parameters**: When dispatching Workers in batch mode, the following parameters MUST be included in each Worker's context:
+- `skip_confirmation: true` — Workers skip Checkpoint A user confirmation (not feasible in batch mode)
+- `skip_index_generation: true` — Workers skip Step 5 INDEX.md generation (INDEX.md will be generated by orchestrator after all workers complete)
+
+### Phase 5.5: INDEX.md Generation (AGENT-OWNED)
+
+After ALL Feature×Platform workers complete successfully, the orchestrator generates INDEX.md for each platform directory. This is an AGENT-OWNED task — the orchestrator generates INDEX.md directly, NOT by dispatching a worker.
+
+**Steps per platform**:
+1. Read INDEX-TEMPLATE.md from techs knowledge templates
+2. Copy template to `{output_dir}/{platform_id}/INDEX.md`
+3. Fill sections using `search_replace` with actual content from:
+   - Tech stack summary from techs knowledge
+   - Module list table from completed design documents
+   - Shared design decisions from architecture knowledge
+4. Verify all placeholders are replaced
+
+**FORBIDDEN**: Dispatching a worker for INDEX.md generation. INDEX.md is a summary/aggregation file that the orchestrator creates by reading completed worker outputs.
+
+**Example** (5 features × 3 platforms = 15 workers, 3 batches of 6/6/3):
+- Batch 1: Workers 1-6 (parallel)
+- Batch 2: Workers 7-12 (parallel, after batch 1 completes)
+- Batch 3: Workers 13-15 (parallel, after batch 2 completes)
+
 ### HARD STOP Checkpoints
 
 This workflow has **mandatory HARD STOP** checkpoints at:
 - **Phase 3.5**: Framework evaluation confirmation (user MUST approve framework decisions)
 - **Phase 4.5**: Design overview confirmation (user MUST approve DESIGN-OVERVIEW.md before Phase 5 dispatch)
+- **Phase 5.5**: (No HARD STOP — INDEX.md generation is automatic after all workers complete)
 - **Phase 6.1**: Joint design confirmation (user MUST approve all designs)
 
 DO NOT proceed past these checkpoints without explicit user confirmation.
@@ -144,6 +189,9 @@ DO NOT proceed past these checkpoints without explicit user confirmation.
 - **DO NOT generate framework-evaluation.md yourself** — Only workers generate it
 - **DO NOT create scripts for batch analysis** — Workers handle this via their own skill
 - **DO NOT fallback to inline execution if worker fails** — ABORT instead
+- **DO NOT let individual workers generate INDEX.md in batch mode** — `skip_index_generation: true` must be set; orchestrator generates INDEX.md after all workers complete
 - **DO NOT skip reading workflow.agentflow.xml** — XML is the execution authority
 - **DO NOT generate DESIGN-OVERVIEW.md yourself** — Dispatch speccrew-task-worker with speccrew-sd-design-overview-generate skill
 - **DO NOT use Skill tool for Phase 4 design overview generation** — Skill tool executes inline, Agent tool creates a worker
+- **DO NOT group multiple features into a single Worker** — Each Worker handles exactly ONE feature on ONE platform
+- **DO NOT dispatch Workers sequentially** — ALL Workers in the same batch MUST be dispatched simultaneously

package/.speccrew/skills/speccrew-system-designer-orchestration/workflow.agentflow.xml

@@ -341,25 +341,121 @@
         </block>
       </branch>
       <branch default="true" name="Multi Feature/Platform - Worker Dispatch Required">
-        <!-- Parallel Worker Dispatch -->
-        <block type="rule" id="P5-R2" level="mandatory" desc="Parallel dispatch rule">
-          <field name="text">Dispatch ALL platform workers IN PARALLEL — DO NOT execute sequentially</field>
-          <field name="text">Each Worker runs independently — dispatch all at once, then monitor completion</field>
+        <!-- Parallel Worker Dispatch with Batch Loop -->
+        <block type="rule" id="P5-R2" level="mandatory" desc="Feature×Platform dispatch rules">
+          <field name="text">ONE Worker per Feature×Platform combination — NO EXCEPTIONS</field>
+          <field name="text">DO NOT group multiple features or platforms into a single Worker</field>
+          <field name="text">ALL Workers in the same batch MUST be dispatched IN PARALLEL — sequential dispatch is FORBIDDEN</field>
+          <field name="text">ALL Worker dispatch calls MUST be issued SIMULTANEOUSLY in a SINGLE orchestration turn</field>
+          <field name="text">DO NOT wait for any Worker to complete before dispatching the next Worker in the same batch</field>
+          <field name="text">Batch size is 6 — DO NOT exceed</field>
+          <field name="text">Each Worker MUST receive a single feature_spec_path and single platform_id — NOT arrays</field>
         </block>
-        <block type="task" id="P5-B4" action="dispatch-to-worker" status="pending"
-               desc="Dispatch workers for Feature×Platform matrix">
-          <field name="worker">speccrew-task-worker</field>
-          <field name="max_concurrent">6</field>
-          <field name="tasks">${dispatch_tasks_matrix}</field>
-          <field name="note">Each worker receives: skill_path, task_id, feature_id, feature_name, platform_id, feature_spec_path, api_contract_path, techs_knowledge_paths, framework_decisions, output_base_path</field>
+
+        <!-- Compute batch plan from dispatch_tasks_matrix -->
+        <block type="task" id="P5-B4-BATCH" action="compute-batches" status="pending"
+               desc="Calculate batch plan from Feature×Platform matrix">
+          <field name="items" value="${dispatch_tasks_matrix}"/>
+          <field name="batch_size" value="6"/>
+          <field name="output" var="batch_plan"/>
+        </block>
+
+        <!-- Batch Loop: Process all Feature×Platform tasks in batches of 6 -->
+        <block type="loop" id="P5-L-MAIN" over="${batch_plan.batches}" as="batch"
+               desc="Process batches sequentially — wait for each batch to complete before next">
+
+          <!-- Parallel dispatch for each task in current batch -->
+          <block type="loop" id="P5-L-INNER" over="${batch.tasks}" as="task" parallel="true" max-concurrency="6"
+                 desc="Dispatch Worker for each Feature×Platform combination IN PARALLEL">
+
+            <!-- Update task status to in_progress -->
+            <block type="task" id="P5-B4-PRE" action="run-script" status="pending"
+                   desc="Update task status to in_progress before dispatch">
+              <field name="command">node "${update_progress_script}" update-task --file "${iterations_dir}/${current_iteration}/03.system-design/DISPATCH-PROGRESS.json" --task-id "${task.id}" --status in_progress</field>
+            </block>
+
+            <!-- Dispatch single Worker for ONE Feature × ONE Platform -->
+            <block type="task" id="P5-B4-DISPATCH" action="dispatch-to-worker" status="pending"
+                   desc="Dispatch Worker: ${task.feature_id} on ${task.platform_id}">
+              <field name="agent">speccrew-task-worker</field>
+              <field name="skill">${task.skill}</field>
+              <field name="skill_path">${ide_skills_dir}/${task.skill}/SKILL.md</field>
+              <field name="context">
+                task_id: ${task.id},
+                feature_id: ${task.feature_id},
+                feature_name: ${task.feature_name},
+                platform_id: ${task.platform_id},
+                feature_spec_path: ${task.feature_spec_path},
+                api_contract_path: ${task.api_contract_path},
+                techs_knowledge_paths: ${task.techs_knowledge_paths},
+                framework_decisions: ${framework_result.decisions},
+                output_base_path: ${iterations_dir}/${current_iteration}/03.system-design,
+                skip_confirmation: true,
+                skip_index_generation: true
+              </field>
+              <field name="output" var="worker_result_${task.id}"/>
+            </block>
+
+            <!-- Update progress after worker completes -->
+            <block type="task" id="P5-B4-POST" action="run-script" status="pending"
+                   desc="Update task progress after worker completes">
+              <field name="command">node "${update_progress_script}" update-task --file "${iterations_dir}/${current_iteration}/03.system-design/DISPATCH-PROGRESS.json" --task-id "${task.id}" --status ${worker_result_${task.id}.status}</field>
+            </block>
+
+          </block>
+
+          <!-- Log batch completion -->
+          <block type="task" id="P5-B4-BATCH-READ" action="run-script" status="pending"
+                 desc="Read current progress after batch">
+            <field name="command">node "${update_progress_script}" read --file "${iterations_dir}/${current_iteration}/03.system-design/DISPATCH-PROGRESS.json" --summary</field>
+            <field name="output" var="batch_progress"/>
+          </block>
+
+          <block type="event" id="P5-E-BATCH-END" action="log" level="info"
+                 desc="Log batch completion">
+            <field name="message">✅ Batch ${batch.index} Complete
+├── Progress: ${batch_progress.counts.completed}/${dispatch_tasks_matrix.length} completed
+├── Failed: ${batch_progress.counts.failed}
+└── Remaining: ${batch_progress.counts.pending}</field>
+          </block>
+
         </block>
       </branch>
     </block>
 
-    <!-- Step 5.5: Update DISPATCH-PROGRESS.json after completion -->
+    <!-- batch-update is available via: node update-progress.js batch-update --file <progress.json> --tasks-file <tasks.json> -->
+    <!-- Use when orchestrator needs to batch-update multiple task statuses at once -->
+
+    <!-- Phase 5.5: Generate Platform INDEX.md (AGENT-OWNED) -->
+    <block type="rule" id="P5-IDX-R1" level="mandatory" desc="INDEX.md Generation - Agent Owned">
+      <field name="text">
+        After all workers complete, the orchestrator generates INDEX.md for each platform.
+        Steps per platform:
+        1. Read INDEX-TEMPLATE.md from techs knowledge templates
+        2. Copy template to {output_dir}/{platform_id}/INDEX.md
+        3. Fill sections using search_replace with actual content from:
+           - Tech stack summary from techs knowledge
+           - Module list table from completed design documents
+           - Shared design decisions from architecture knowledge
+        4. Verify all placeholders are replaced
+        FORBIDDEN: Dispatching a worker for INDEX.md generation.
+      </field>
+    </block>
+    <block type="loop" id="P5-IDX-L1" over="${platforms}" as="platform">
+      <block type="task" id="P5-IDX-B1" action="write-file" status="pending"
+             desc="Generate INDEX.md for ${platform.id}">
+        <field name="template_source">${techs_knowledge_dir}/${platform.id}/templates/INDEX-TEMPLATE.md</field>
+        <field name="output">${iterations_dir}/${current_iteration}/03.system-design/${platform.id}/INDEX.md</field>
+        <field name="fill_method">search_replace per section</field>
+        <field name="module_list_source">${platform.completed_documents}</field>
+      </block>
+    </block>
+
+    <!-- Step 5.5: Read final dispatch progress -->
     <block type="task" id="P5-B5" action="run-script" status="pending"
-           desc="Update task status based on completion">
-      <field name="command">node ${update_progress_script} update-task --file ${iterations_dir}/${current_iteration}/03.system-design/DISPATCH-PROGRESS.json --task-id ${task_id} --status ${completion_status} --output "${output_path}"</field>
+           desc="Read final dispatch progress summary">
+      <field name="command">node "${update_progress_script}" read --file "${iterations_dir}/${current_iteration}/03.system-design/DISPATCH-PROGRESS.json" --summary</field>
+      <field name="output" var="final_dispatch_progress"/>
     </block>
 
     <!-- Step 5.6: Error Handling -->

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "speccrew",
-  "version": "0.7.57",
+  "version": "0.7.59",
   "description": "Spec-Driven Development toolkit for AI-powered IDEs",
   "author": "charlesmu99",
   "repository": {

package/workspace-template/scripts/update-progress.js

@@ -65,7 +65,14 @@
  *      --features-dir <dir>    Directory containing features-*.json files (required)
  *      --force                 Overwrite existing file
  *
- * 8. sync - Sync task status with actual output files
+ * 8. batch-update - Batch update multiple task statuses from a JSON file
+ *    node update-progress.js batch-update --file <path> --tasks-file <path>
+ *    Options:
+ *      --file <path>           Progress file path (required)
+ *      --tasks-file <path>     JSON file with task updates (required)
+ *                               Format: [{"id": "task-id", "status": "completed", ...}]
+ *
+ * 9. sync - Sync task status with actual output files
  *    node update-progress.js sync --file <path> --dir <dir> --suffix <suffix> [--strict]
  *    Options:
  *      --file <path>           Progress file path (required)
@@ -1146,6 +1153,152 @@ function cmdInitKnowledgeTasks(args) {
     }
 }
 
+/**
+ * Command: batch-update - Batch update multiple task statuses from a JSON file
+ *
+ * Reads a list of task updates from a JSON file and applies them to the progress file.
+ * This avoids long command lines that can crash PSReadLine.
+ *
+ * Tasks file format:
+ * [
+ *   {"id": "task-1", "status": "completed"},
+ *   {"id": "task-2", "status": "failed", "error": "error message"},
+ *   {"id": "task-3", "status": "completed", "output": "result info"}
+ * ]
+ */
+function cmdBatchUpdate(args) {
+    if (!args.file || !args.tasksFile) {
+        outputError('Usage: batch-update --file <path> --tasks-file <path>');
+    }
+
+    const filePath = path.resolve(args.file);
+    const tasksFilePath = path.resolve(args.tasksFile);
+
+    // Read tasks file
+    let updates;
+    try {
+        updates = readJsonFile(tasksFilePath);
+    } catch (e) {
+        outputError(`Failed to read tasks file: ${e.message}`);
+    }
+
+    // Validate updates is an array
+    if (!Array.isArray(updates)) {
+        outputError('Tasks file must contain a JSON array of task updates');
+    }
+
+    if (updates.length === 0) {
+        outputError('Tasks file is empty — no updates to apply');
+    }
+
+    // Validate each update entry
+    const validStatuses = ['pending', 'in_progress', 'partial', 'completed', 'failed', 'confirmed'];
+    for (let i = 0; i < updates.length; i++) {
+        if (!updates[i].id) {
+            outputError(`Update entry at index ${i} is missing required "id" field`);
+        }
+        if (!updates[i].status) {
+            outputError(`Update entry at index ${i} (id: ${updates[i].id}) is missing required "status" field`);
+        }
+        if (!validStatuses.includes(updates[i].status)) {
+            outputError(`Invalid status "${updates[i].status}" for task ${updates[i].id}. Must be one of: ${validStatuses.join(', ')}`);
+        }
+    }
+
+    let lockPath = null;
+    try {
+        lockPath = acquireLock(filePath);
+        const data = readJsonFile(filePath);
+
+        const now = getTimestamp();
+        let updated = 0;
+        let notFound = 0;
+        let skipped = 0;
+        const notFoundIds = [];
+
+        // Build a lookup map for tasks (support both flat and nested structures)
+        // Flat structure: data.tasks array
+        if (data.tasks && Array.isArray(data.tasks)) {
+            for (const update of updates) {
+                const taskIndex = data.tasks.findIndex(t => t.id === update.id);
+                if (taskIndex === -1) {
+                    notFound++;
+                    notFoundIds.push(update.id);
+                    continue;
+                }
+
+                const task = data.tasks[taskIndex];
+
+                // Skip if already in target status
+                if (task.status === update.status) {
+                    skipped++;
+                    continue;
+                }
+
+                // Apply status update
+                task.status = update.status;
+                task.updated_at = now;
+
+                // Set timestamps based on status
+                if (update.status === 'in_progress') {
+                    task.started_at = now;
+                } else if (update.status === 'completed') {
+                    task.completed_at = now;
+                    if (update.output) {
+                        task.output = update.output;
+                    }
+                } else if (update.status === 'confirmed') {
+                    task.confirmed_at = now;
+                } else if (update.status === 'failed') {
+                    task.completed_at = now;
+                    if (update.error) {
+                        task.error = update.error;
+                    }
+                    if (update.error_category) {
+                        task.error_category = update.error_category;
+                    }
+                } else if (update.status === 'partial') {
+                    if (!task.started_at) {
+                        task.started_at = now;
+                    }
+                    if (update.output) {
+                        task.output = update.output;
+                    }
+                }
+
+                updated++;
+            }
+
+            // Recalculate counts
+            data.counts = calculateCounts(data.tasks);
+        } else {
+            // No flat tasks array — cannot batch update
+            outputError('Progress file does not contain a tasks array — batch-update only supports flat task structure');
+        }
+
+        data.updated_at = now;
+
+        // Atomic write
+        atomicWriteJson(filePath, data);
+
+        const result = {
+            total_updates_requested: updates.length,
+            updated: updated,
+            skipped_already_current: skipped,
+            not_found: notFound,
+            counts: data.counts
+        };
+
+        if (notFoundIds.length > 0) {
+            result.not_found_ids = notFoundIds;
+        }
+
+        outputSuccess(`Batch update completed: ${updated} tasks updated, ${skipped} skipped, ${notFound} not found`, result);
+    } finally {
+        if (lockPath) releaseLock(lockPath);
+    }
+}
+
 /**
  * Command: sync - Sync task status with actual output files
  * Scans directory for files matching suffix, extracts task IDs from filenames,
@@ -1494,6 +1647,7 @@ function main() {
         console.error('  update-workflow  Update a workflow stage status');
         console.error('  init-tasks       Generate tasks from feature-spec files');
         console.error('  init-knowledge-tasks  Generate knowledge initialization tasks from matcher results');
+        console.error('  batch-update     Batch update multiple task statuses from a JSON file');
         console.error('  sync             Sync task status with actual output files');
         console.error('');
         console.error('Run "node update-progress.js <command> --help" for more information.');
@@ -1527,6 +1681,9 @@ function main() {
             case 'init-knowledge-tasks':
                 cmdInitKnowledgeTasks(args);
                 break;
+            case 'batch-update':
+                cmdBatchUpdate(args);
+                break;
             case 'sync':
                 cmdSync(args);
                 break;