Wave as a general-purpose task runner — pipeline architecture refactoring

[nextlevelshit]

Vision

Wave is not just a code review tool or a PR automation system. It is a general-purpose task runner for code and other deliverables. Pipelines are interchangeable, composable chunks — users shouldn't need to know the difference between a "pipeline" and a "composition". There should be hundreds of standard pipelines, and compositions bring them together into massive workflows.

Current State

We have ~60 pipeline YAML files, many overlapping:

• 4+ variants of PR review/rework (ops-pr-review, ops-pr-rework, ops-pr-fix-review, impl-review-loop)
• Multiple impl variants that differ only in scaffolding (impl-issue, impl-feature, impl-refactor, impl-hotfix)
• Audit pipelines that could be composed from smaller chunks (audit-dual = audit-security + audit-quality)
• ops-pr-fix-review is a monolithic leaf pipeline when it should be a composition of granular steps

Target Architecture

Principle: Compose everything

• Leaf pipelines do ONE thing (review, triage, fix, reply, scan, test, etc.)
• Compositions wire leafs together — they are thin orchestrations with no inline logic
• Users run compositions. Leaf pipelines are implementation details.
• Same leaf step is reusable across many compositions — no duplication

Example: Full PR lifecycle composition

scan-issues → split-if-needed → implement → review → triage → fix → reply → resolve-conversations → merge

Each arrow is a leaf pipeline. The composition just defines the graph.

Example: Autonomous issue triage

fetch-issues → classify-priority → assign-labels → split-epic → create-sub-issues → schedule-impl

Hundreds of standard pipelines

• Code: lint, test, build, format, security-scan, dead-code, dependency-check
• Review: pr-review, code-review, security-review, agent-review, self-review
• PR lifecycle: pr-create, pr-update, pr-reply, pr-merge, pr-close, pr-rebase
• Issue: issue-scan, issue-triage, issue-split, issue-assign, issue-close
• Forge: release-create, release-harden, changelog-generate, tag-create
• Documentation: doc-scan, doc-fix, doc-generate, doc-onboard
• Meta: pipeline-validate, pipeline-compose, pipeline-dry-run

Compositions are disposable

• Compositions are created per-task, not per-project
• wave run compose --steps "scan → impl → review → fix → reply" (future CLI)
• Or define in YAML for recurring workflows
• The same leaf pipelines power all compositions — no lock-in

Scope

• Audit all 60+ existing pipelines for redundancy
• Extract leaf pipelines from monolithic ones (see Consolidate PR review/rework pipelines — eliminate redundancy #705 for PR review consolidation)
• Define a standard leaf pipeline naming taxonomy
• Rewrite compositions as thin orchestrations
• Add composition CLI support (inline composition definition)
• Document the architecture: leaf vs composition, when to use which
• Remove all monolithic pipelines that are just hardcoded compositions

Related

• Consolidate PR review/rework pipelines — eliminate redundancy #705 — Consolidate PR review/rework pipelines (specific instance of this)
• feat(engine): implement composition primitives — iterate, aggregate, loop, branch #677 — Composition primitives (iterate, aggregate, branch, loop)

[nextlevelshit]

Closing: deferred — valid work but not near-term priority. Will reopen when prioritized.