feat(pipeline): adaptive gate selection based on intent + complexity classification

[pertrai1]

Summary

The pipeline currently runs all six quality gates sequentially on every phase regardless of task type. This is likely overkill for simple tasks and creates a multiplicative cost problem — potentially hundreds of LLM invocations just on quality enforcement for a multi-phase project.

Proposal

Extend the intent router to output both a task type and a complexity score, then use that classification to select which quality gates to run via a gate policy matrix.

Gate Selection Policy

Intent Router classifies task
       │
       ├─ bug-fix (simple)     → verify + lint only
       ├─ bug-fix (complex)    → verify + lint + QA + code review
       ├─ feature (small)      → verify + QA + code review
       ├─ feature (large)      → full gate sequence
       ├─ refactor             → verify + architect + integration
       └─ migration            → full gate sequence + extra integration

Why This Works

This follows the same principle as adaptive RAG — route dynamically based on classified intent rather than running a fixed pipeline. The classifier itself is cheap (one fast LLM call) compared to the 6-18 gate invocations it can skip.

Key Design Considerations

• Conservative by default — When the classifier is uncertain about complexity, run more gates, not fewer. Unlike adaptive RAG where a wrong routing decision means a worse answer, here it could mean shipping a bug.
• Configurable via forge.config.json — A gate policy matrix mapping (intent, complexity) → gates[] lets users override defaults for their risk tolerance.
• Telemetry enforcement — @open-forge/telemetry should verify that the selected gates actually ran for a given phase, closing the loop between classification and execution.

Implementation Sketch

1. Extend the intent router to output a complexity score alongside the task type
2. Define a default gate policy matrix (conservative)
3. Add gatePolicy configuration to forge.config.json for user overrides
4. Update the pipeline orchestrator to select gates based on policy
5. Add telemetry constraints that validate gate execution against the policy

Context

• Discussed in the context of the architectural overview added in docs: add architecture overview with telemetry to root README #7
• Related to telemetry constraint enforcement scaffolded in feat(telemetry): scaffold @open-forge/telemetry package #6
• See pipeline REQUIREMENTS.md for the current gate sequence design