feat(pipeline): pipeline proposal engine — context-aware sequencing from health artifact

[nextlevelshit]

Parent: #184

Summary

Implement the pipeline proposal engine that consumes the codebase health analysis artifact and the available pipeline catalog to propose optimal pipeline sequences. The engine applies contextual intelligence (nous) and practical judgment (phronesis) to recommend what pipelines to run, in what order, and which can run in parallel. This may extend or replace the existing wave meta / MetaPipelineExecutor (internal/pipeline/meta.go) which already supports dynamic child pipeline generation via the philosopher persona.

Acceptance Criteria

• Engine consumes the health analysis artifact (from feat(pipeline): codebase health analysis step — forge-aware repository state artifact #207) as primary input
• Engine discovers available pipelines from the manifest/pipeline catalog
• Engine produces a structured proposal: ordered list of pipeline runs with dependency edges
• Proposals identify pipelines that can run in parallel (independent inputs)
• Proposals include rationale for each recommended pipeline (why it's relevant given codebase state)
• Engine filters pipelines by detected forge type (only propose gh-* for GitHub repos, etc.)
• Proposal output is a structured artifact consumable by the interactive TUI
• Engine handles edge cases: no actionable proposals, all pipelines already completed, conflicting recommendations
• Relationship with existing wave meta (internal/pipeline/meta.go) is resolved — either extends it or documents why a separate engine is needed

Dependencies

• feat(pipeline): codebase health analysis step — forge-aware repository state artifact #207 — Codebase health analysis (provides the input artifact)
• feat(preflight): extend system readiness checks for wave run wave pre-flight #206 — System readiness checks (ensures forge detection is available)

Scope Notes

• In scope: Proposal generation logic, pipeline catalog discovery, forge-aware filtering, dependency ordering, parallel eligibility detection, structured proposal output
• Out of scope: Executing the proposed pipelines (that's the orchestrator's job), interactive UI for selecting proposals (feat(pipeline): pipeline proposal engine — context-aware sequencing from health artifact #208), creating new pipeline definitions on the fly
• Design decision needed: Whether to extend MetaPipelineExecutor or build a separate proposal engine. The existing meta executor uses a philosopher persona to generate child pipelines dynamically — the proposal engine could be a pipeline step that produces proposals as artifacts
• Overlap note: feat: restore and stabilize wave meta dynamic pipeline generation #95 covers stabilizing wave meta — this issue should coordinate with or build upon that work

[nextlevelshit]

Revival Update (March 2026)

Audit Findings

What exists:

• ✅ wave meta — philosopher persona generates and executes pipelines dynamically from task descriptions
• ✅ wave compose — validates artifact compatibility between pipelines and executes sequences
• ✅ 47 pipelines across 4 forge families in the catalog

What does NOT exist:

• ❌ No context-aware pipeline proposal logic
• ❌ No mapping from codebase state → recommended pipelines
• ❌ No rationale generation for proposals

Revised Scope: wave suggest

Per the parent issue #184 revival, this becomes the wave suggest command:

$ wave suggest
Based on repository state:

  1. [gh-research]  → Issue #184 needs investigation
  2. [gh-implement] → Issue #42 has approved design
  3. [gh-pr-review] → PR #219 awaiting review

  Parallel group: 1 + 2 (independent inputs)
  Sequence: [1,2] → 3

$ wave suggest --json     # Structured proposal
$ wave suggest --accept   # Execute the proposal
$ wave suggest --dry-run  # Show plan without executing

Design Decision: Deterministic Engine vs. Philosopher Persona

Two approaches:

1. Deterministic rules engine — hardcoded mapping: "open issues without PRs → xx-research", "approved PRs → xx-pr-review", etc. Fast, predictable, testable.

2. Philosopher persona (extends wave meta) — feed health artifact to philosopher, get pipeline proposals. More flexible, handles edge cases, but slower and less predictable.

Recommendation: Start with deterministic rules, add philosopher refinement later. The rules handle 80% of cases; the philosopher handles nuance.

Revised Size: L (was XL)

The deterministic engine is a function that maps health artifact fields to pipeline selections. The hard part is getting the heuristics right, not the code volume. Previous PR #218 was closed without merging.

[nextlevelshit]

Implementation Update (March 2026)

Current status: In progress

TUI suggest views are being implemented in the active session:

• ViewSuggest TUI view — in progress
• Suggest provider, list, detail, and messages — in progress
• Wiring into TUI app — pending

Relationship to #296

The new #296 (AI-steered project optimization) produces a project profile that is a key input for this proposal engine. Without accurate project configuration (test commands, forge type, relevant pipelines), the proposal engine would suggest wrong pipelines. #296 ensures the foundation data is correct before wave suggest runs.

Dependency chain: wave init → wave doctor --optimize (#296) → wave doctor (#206) → wave suggest (#208)

Previous attempt

PR #218 was closed without merging. Fresh implementation takes a different approach — TUI-native rather than CLI-first.