taskforge-execute-all

Execute All — Sprint Auto-Execution (Wave Parallel) v2

Continuously execute the remaining tasks in the current sprint without stopping.

Prerequisites

• Same as /taskforge-execute (project selection, approved plan, execution-state)
• All file paths are relative to _workspace/projects/{projectId}/

v2 Pre-flight: Size Gate Check

Before starting execution, verify that the current sprint's tasks are real planned tasks:

1. Load project-plan.json and execution-state.json
2. Confirm each pending task in the sprint exists in project-plan.json with a valid plan field
3. If any task is missing or has an empty plan, skip it with a warning and continue with the remaining tasks
4. Log the pre-flight result to telemetry.jsonl as a sprint_start event

This prevents phantom tasks (tasks in execution-state that were never in the plan) from running silently.

Behavior

Wave-Based Parallel Execution

If tasks have a wave field, execute in wave order:

Wave 1: [t1, t2, t3] — no dependencies, parallel execution
  ↓ (after all complete)
Wave 2: [t4, t5] — depends on Wave 1, parallel execution
  ↓ (after all complete)
Wave 3: [t6] — depends on Wave 2, single execution

1. Tasks in the same wave are executed in parallel using the Agent tool (each acquires its own task lock)
2. Skip tasks that are already locked by another session
3. Proceed to the next wave only after all tasks in the current wave complete
4. Tasks without a wave field are executed sequentially in dependency order

Execution Flow

For each task, perform the same flow as /taskforge-execute:

• Assemble context → route model → execute → self-review → check acceptance criteria → write handoff → silent error scan → validate

Handoff: Always ON (v2)

Every completed task gets a handoff written to handoffs/{task-id}.json. This is no longer conditional. Handoff content: what was built, key decisions made, anything the next task needs to know.

Failure Handling

• Do not stop on task failure; continue to the next task
• However, skip tasks that depend on a failed task (marked as skipped)
• If one task fails within a wave, only that task is marked failed; the rest continue

v2 Guardrail Monitoring

Track guardrail events across the sprint:

• A guardrail event is any of: task retry triggered, silent error detected, acceptance criteria partially failed, model fallback applied
• Maintain a running count: guardrailCount in memory during the sprint run
• At sprint completion, include the count in the summary and in the sprint_complete telemetry event
• If guardrailCount >= 3, surface a warning in the sprint summary prompting the user to review /taskforge-status

v2 Silent Error Scan

After each task completes (same as /taskforge-execute):

1. Scan the changed files for common silent failure patterns:
   • TODO, FIXME, PLACEHOLDER, NOT IMPLEMENTED in new code
   • Functions that always return null, undefined, or false
   • console.error / throw paths that are unreachable (dead catch blocks)
   • Empty function bodies
2. If any are found, record them as warnings in handoffs/{task-id}.json under silentErrors
3. Increment guardrailCount by the number of issues found
4. Do not block execution — surface as warnings only

v2 Telemetry Logging

Append each event to telemetry.jsonl (newline-delimited JSON, one object per line).

Event: task_start

{"t":"2026-04-19T10:23:00Z","event":"task_start","taskId":"M1-S1-T3","wave":1,"model":"sonnet","size":"feature","referencesInjected":["ui-pattern.html"],"cotUsed":true,"manifestFiles":5}

• size: "tiny" | "normal" | "feature" | "milestone" (matches plan task size)
• referencesInjected: array of reference file paths injected into context
• cotUsed: whether a CoT template from prompts/cot/ was injected
• manifestFiles: total number of files read from contextManifest

Event: task_end

{"t":"2026-04-19T10:41:00Z","event":"task_end","taskId":"M1-S1-T3","outcome":"pass","retryCount":0,"tokens":12450,"costUSD":0.42,"wallMin":18}

• outcome: "pass" | "fail" | "skip"
• retryCount: number of retries before outcome (0 = first-try pass)

Event: sprint_complete

{"t":"2026-04-19T10:45:00Z","event":"sprint_complete","sprintId":"M1-S1","tasksCompleted":5,"tasksFailed":0,"totalCostUSD":1.2,"guardrailEvents":0}

Write to _workspace/projects/{projectId}/telemetry.jsonl. Create the file if it does not exist. Never overwrite — always append.

Sprint Completion: User Summary (v2)

After all tasks in the sprint complete, display:

Template — fill from actual sprint state:

스프린트 {sprintId} "{sprintName}" 완료

  Wave {n} (병렬): {taskName} ✅ {taskName} ✅
  Wave {n} (병렬): {taskName} ✅ {taskName} ✅
  Wave {n}: {taskName} ✅

  소요: {duration} | 비용: ${cost} | 가드레일 발동: {n}회

  다음 단계:
  → 스프린트 검증이 백그라운드에서 진행 중 (결과는 /taskforge-status에서 확인)
  → 다음 스프린트로 자동 진행 중...

If guardrailCount >= 3, append:

  ⚠️  이번 스프린트에서 가드레일이 여러 번 발동됐습니다. /taskforge-status로 확인하세요.

Sprint Boundary: Async Validation + Auto-Refresh (built-in)

At every sprint boundary:

1. Launch sprint validation in the background (/taskforge-validate sprint, async). It is advisory only and must NOT block the next sprint. Results land in validations/sprint-{id}.json with status: "advisory". Failures become warnings carried into the next milestone gate.
2. Refresh the follow-up plan (below).
3. Immediately start the next sprint's Wave 1 — do not wait for the background validation to finish.

This is the core change that makes wave parallelism work across sprint boundaries: the executor never stalls on sprint review.

Auto-Refresh

After a sprint completes, automatically refresh the follow-up plan:

1. Read all handoffs from the completed sprint (design decisions, issues discovered)
2. Check remaining tasks — do any plan fields need updating based on what actually happened?
3. If changes needed:
   • Modify task plans to reflect actual design decisions
   • Add tasks if new work was discovered
   • Remove tasks if work is no longer needed
   • Show the user a brief change summary
4. If no changes needed: proceed silently

Plan refresh happens automatically at sprint boundaries. No separate refresh command needed.

Milestone Completion: User Guidance (v2)

When the final sprint of a milestone completes, display:

마일스톤 M1 모든 스프린트 완료!

권장 순서:
1. /taskforge-validate milestone — 자동 품질 검증
2. /taskforge-playtest — 직접 플레이해서 확인
3. /taskforge-retro — 회고 + 다음 마일스톤 계획 업데이트

Then halt. Do not start the next milestone automatically. The user must run /taskforge-validate milestone first.

Stopping

If the user says "stop", "halt", "pause", or similar mid-execution, stop after the current task completes. Then use /taskforge-execute to continue one at a time, or /taskforge-execute-all to resume continuous execution.

Notes

• Auto-execution runs through sprints continuously within a single milestone. Sprint validation is async and advisory, so the executor flows from one sprint into the next without stopping.
• Halt automatically at the milestone boundary — that is the blocking validation gate. Guide the user to run /taskforge-validate milestone before starting the next milestone.
• Sprint advisories accumulated during the milestone are surfaced in /taskforge-status and rolled into the milestone gate review.
• telemetry.jsonl is the source of truth for /taskforge-cost aggregation.