librenotes/.wave/pipelines/plan.yaml

kind: WavePipeline
metadata:
  name: plan
  description: "Break down a feature into actionable tasks with structured exploration, planning, and review"
  release: true

input:
  source: cli
  example: "add webhook support for pipeline completion events"

steps:
  - id: explore
    persona: navigator
    workspace:
      type: worktree
      branch: "{{ pipeline_id }}"
    exec:
      type: prompt
      source: |
        You are exploring a codebase to gather context for planning this feature or task:

        {{ input }}

        Your goal is to produce a rich, structured JSON exploration that a planner persona
        will use (without any other context) to break the work into tasks.

        ## Exploration Steps

        1. **Understand the request**: Summarize what is being asked and assess scope
           (small = 1-2 files, medium = 3-7 files, large = 8-15 files, epic = 16+ files).

        2. **Find related files**: Use Glob and Grep to find files related to the feature.
           For each file, note its path, relevance (primary/secondary/reference), why it
           matters, and key symbols (functions, types, constants) within it.

        3. **Identify patterns**: Use Read to examine key files. Document codebase patterns
           and conventions. Assign each a PAT-### ID and relevance level:
           - must_follow: Violating this would break consistency or cause bugs
           - should_follow: Strong convention but exceptions exist
           - informational: Good to know but not binding

        4. **Map affected modules**: Identify which packages/modules will be directly or
           indirectly affected. Note their dependencies and dependents.

        5. **Survey testing landscape**: Find test files related to the affected code.
           Note testing patterns (table-driven, mocks, fixtures, etc.) and coverage gaps.

        6. **Assess risks**: Identify potential risks (breaking changes, performance concerns,
           security implications). Rate severity (high/medium/low) and suggest mitigations.

        CRITICAL: Write ONLY the JSON object. No markdown wrapping, no explanation
        outside the file. The file must parse as valid JSON.
    output_artifacts:
      - name: exploration
        path: .wave/output/exploration.json
        type: json
    handover:
      contract:
        type: json_schema
        source: .wave/output/exploration.json
        schema_path: .wave/contracts/plan-exploration.schema.json
        on_failure: retry
        max_retries: 2

  - id: breakdown
    persona: planner
    dependencies: [explore]
    memory:
      inject_artifacts:
        - step: explore
          artifact: exploration
          as: context
    workspace:
      type: worktree
      branch: "{{ pipeline_id }}"
    exec:
      type: prompt
      source: |
        You are breaking down a feature into actionable implementation tasks.

        ## Input

        Feature request: {{ input }}

        Codebase exploration has already been done and injected into your workspace.
        It contains structured JSON with: related files, codebase patterns,
        affected modules, testing landscape, and identified risks. Use ALL of this
        information to inform your task breakdown.

        ## Task Breakdown Rules

        1. **Task IDs**: Use T01, T02, T03... format (zero-padded two digits).

        2. **Personas**: Assign each task to the most appropriate persona:
           - navigator: architecture decisions, exploration, planning
           - craftsman: implementation, coding, file creation
           - philosopher: review, analysis, quality assessment
           - auditor: security review, compliance checking
           - implementer: focused implementation tasks
           - reviewer: code review tasks

        3. **Dependencies**: Express as task IDs (e.g., ["T01", "T02"]).
           A task with no dependencies gets an empty array [].

        4. **Complexity**: S (< 1hr), M (1-4hr), L (4-8hr), XL (> 1 day).

        5. **Acceptance criteria**: Each task MUST have at least one concrete,
           verifiable acceptance criterion.

        6. **Affected files**: List files each task will create or modify.

        7. **Execution order**: Group tasks into phases. Tasks within a phase
           can run in parallel. Phase 1 has no dependencies, Phase 2 depends
           on Phase 1, etc.

        8. **Risks**: Note task-specific risks from the exploration.

        CRITICAL: Write ONLY the JSON object. No markdown wrapping, no explanation
        outside the file. The file must parse as valid JSON.
    output_artifacts:
      - name: tasks
        path: .wave/output/tasks.json
        type: json
    handover:
      contract:
        type: json_schema
        source: .wave/output/tasks.json
        schema_path: .wave/contracts/plan-tasks.schema.json
        on_failure: retry
        max_retries: 2

  - id: review
    persona: philosopher
    dependencies: [breakdown]
    memory:
      inject_artifacts:
        - step: explore
          artifact: exploration
          as: context
        - step: breakdown
          artifact: tasks
          as: task_list
    workspace:
      type: worktree
      branch: "{{ pipeline_id }}"
    exec:
      type: prompt
      source: |
        You are reviewing a task breakdown plan for quality, completeness, and correctness.

        ## Input

        Feature request: {{ input }}

        Two artifacts have been injected into your workspace: the codebase exploration
        and the task breakdown plan. Read them BOTH before proceeding.

        The exploration contains: related files, patterns, affected modules, testing
        landscape, and risks. The task list contains: feature summary, tasks with
        dependencies and acceptance criteria, and execution order.

        ## Review Checklist

        For EACH task in the plan, evaluate and assign a status:
        - ok: Task is well-defined and ready to execute
        - needs_refinement: Good idea but needs clearer description or criteria
        - missing_details: Lacks acceptance criteria, affected files, or dependencies
        - overcomplicated: Should be split or simplified
        - wrong_persona: Different persona would be more appropriate
        - bad_dependencies: Dependencies are incorrect or missing

        For each issue found, assign a REV-### ID, severity, description, and suggestion.

        ## Cross-Cutting Concerns

        Look for concerns that span multiple tasks (CC-### IDs):
        - Testing strategy: Are tests planned? Do they follow codebase patterns?
        - Security: Are security implications addressed?
        - Performance: Will changes affect performance?
        - Backwards compatibility: Are breaking changes handled?
        - Documentation: Is documentation updated?

        ## Recommendations

        Provide actionable recommendations (REC-### IDs) with type:
        add_task, modify_task, remove_task, reorder, split_task, merge_tasks,
        change_persona, add_dependency

        ## Verdict

        Provide an overall verdict:
        - approve: Plan is ready to execute as-is
        - approve_with_notes: Plan is good but has minor issues to note
        - revise: Plan needs significant changes before execution

        CRITICAL: Write ONLY the JSON object. No markdown wrapping, no explanation
        outside the file. The file must parse as valid JSON.
    output_artifacts:
      - name: review
        path: .wave/output/plan-review.json
        type: json
    handover:
      contract:
        type: json_schema
        source: .wave/output/plan-review.json
        schema_path: .wave/contracts/plan-review.schema.json
        on_failure: retry
        max_retries: 2