launchpad-plan

Launchpad Plan

Analyze a task breakdown and produce a parallelization-aware implementation plan.

Purpose

Bridge between the spec's task list and the runner's parallel execution. The planner determines what can run concurrently and what must be sequential by analyzing dependency declarations and file mutation overlaps.

Workflow

1. Locate the Spec

Resolve the spec name from the user's request. Read specs/<spec-name>.tasks.md (or equivalent task breakdown file).

If missing or ambiguous, list specs/ and ask.

2. Parse Task Sections

Extract all task sections. For each task, collect:

• Task ID: Identifier (e.g., task-001, T-0, etc.)
• Files: Each file path and its operation (create vs modify)
• Steps: The implementation steps
• Tests: The test/validation scenarios
• Dependencies: Explicit from the spec, plus implicit from section ordering

3. Build the Dependency Graph

For each task, determine what it depends on:

1. Explicit dependencies: From the spec's task definitions (e.g., depends_on fields).
2. File mutation conflicts: Two tasks that both modify the same file cannot safely run in parallel. If task A appears before task B and both modify src/index.ts, B depends on A.
3. Shared types/foundation dependency: If a foundational task exists (e.g., types, schema, config), all dependent tasks must wait for it.
4. Create-then-modify: If task A creates a file and task B modifies or imports from it, B depends on A.

4. Determine Task Granularity

Each task section becomes one task by default. Adjust when:

• Split a task if it contains clearly independent substeps touching different files with no data flow between them, AND splitting would enable more parallelism. Don't split just for granularity's sake.
• Merge tasks that are trivially small into a parent task or mark as no-op.

5. Assign Parallel Waves

Group tasks into execution waves — sets of tasks that can run concurrently: