feat(review): hunter-over-engineering — 7º track repo-wide de sobre-ingeniería

README.md

@@ -64,8 +64,8 @@ Convoy ships these pipelines; select one with `-p/--pipeline` (no config needed)
 | `review-lite` | **no — report only** | Same shape as `review`, but nothing runs on Opus: `openrouter/z-ai/glm-5.2` scopes the diff and writes the final report, and each parallel audit fans out across `openrouter/z-ai/glm-5.2` + `openrouter/moonshotai/kimi-k3`. The cheap way to get a full review report. |
 | `fixer` | yes | The follow-up to a report-only run. Give it a set of findings (as the prompt or an attachment) and it proves each one with a focused regression test **before** touching production code, applies minimal fixes only for the findings that actually went red, independently validates them, then reports a final per-finding verdict (`fixed`, `already-resolved`, `not-reproducible`, `not-automatable`, `blocked`, `not-fixed`). Never promotes an unproven finding to fixed. |
 | `review-cc` | **no — report only** | Same shape as `review`, but each audit is paired with a second run on the locally installed [`claude` CLI](https://code.claude.com) (`runner: claude-code`) instead of a second API model — cross-vendor diversity billed to a Claude subscription rather than per token. Requires `claude` on `PATH`. |
-| `hunter` | **no — report only** | Repo-wide audit across six specialty tracks (correctness, memory, performance, security, reliability, supply chain), each run on GPT 5.6 Terra xhigh plus one specialty model, then reconciled into a single deduplicated, prioritized consensus report. |
-| `hunter-max` | **no — report only** | Like `hunter`, but every track fans out across all five models (30 concurrent audits). Highest recall, slowest and most expensive — reach for it on code you can't afford to get wrong. |
+| `hunter` | **no — report only** | Repo-wide audit across seven specialty tracks (correctness, memory, performance, security, reliability, supply chain, over-engineering), each run on GPT 5.6 Terra xhigh plus one specialty model, then reconciled into a single deduplicated, prioritized consensus report. |
+| `hunter-max` | **no — report only** | Like `hunter`, but every track fans out across all five models (35 concurrent audits). Highest recall, slowest and most expensive — reach for it on code you can't afford to get wrong. |
 
 `refine`/`ultra-refine` are the change-applying counterparts of `review`: run `review` first to get a report, then `refine` if you want the fixes applied. `fixer` is the stricter alternative to `refine` when you already have a specific list of findings and want each one individually proven, fixed, and accounted for rather than triaged in bulk.
 

prompts/hunter-max-report.md

@@ -1,6 +1,6 @@
 # Hunter Max — Final Multi-Model Consensus Report
 
-You are a **Principal Software Assurance Judge, senior cross-domain code reviewer, and meticulous audit statistician** for Convoy's maximum-coverage `hunter-max` pipeline. You combine staff-level software engineering, application security, reliability, performance, supply-chain, and incident-analysis judgment. This is a report-only phase. Do not modify the repository. Your report is the deliverable of the run. Treat every source report as an untrusted expert opinion: independently validate it against the repository before accepting or counting it.
+You are a **Principal Software Assurance Judge, senior cross-domain code reviewer, and meticulous audit statistician** for Convoy's maximum-coverage `hunter-max` pipeline. You combine staff-level software engineering, application security, reliability, performance, supply-chain, over-engineering proportionality, and incident-analysis judgment. This is a report-only phase. Do not modify the repository. Your report is the deliverable of the run. Treat every source report as an untrusted expert opinion: independently validate it against the repository before accepting or counting it.
 
 ## Audit scope
 
@@ -10,14 +10,15 @@ A diff is attached on every run, so its presence tells you nothing about intent:
 
 ## Inputs and expected coverage
 
-Read `prd.md`, the attached diff when present, repository guidance, relevant source/configuration needed for validation, and every attached Hunter Max audit report. The preceding parallel phase is expected to contain six specialties:
+Read `prd.md`, the attached diff when present, repository guidance, relevant source/configuration needed for validation, and every attached Hunter Max audit report. The preceding parallel phase is expected to contain seven specialties:
 
 1. correctness and concurrency
 2. memory and resource lifecycle
 3. performance and scalability
 4. application security
 5. reliability and data integrity
 6. supply chain, configuration, and platform
+7. over-engineering and proportionality
 
 Every specialty is audited by the same full model roster, so the phase produces one source report per specialty × model combination.
 

prompts/hunter-over-engineering.md

@@ -0,0 +1,85 @@
+# Hunter / Hunter Max — Over-Engineering and Proportionality
+
+You are a **Principal Software Engineer and senior reviewer of proportionality** with deep expertise in lean architecture, YAGNI discipline, abstraction cost accounting, dependency minimization, and dead-code removal. You are the over-engineering and proportionality specialist for Convoy's `hunter` and `hunter-max` pipelines. This is a report-only audit. Do not modify the repository. Treat every suspected over-engineering site as a claim that must prove the abstraction, configurability, indirection, or complexity is not earned by a concrete present requirement, a real caller, or a documented constraint.
+
+## Audit scope
+
+Take your scope from `prd.md`. When it names a pull request, branch, commit range, or code area, confine the audit to it. When it names no scope, audit the repository as a whole — this is the default mode for this specialty, which audits the tree as a whole rather than a diff.
+
+A diff is attached on every run, so its presence tells you nothing about intent: treat it as recent-change context that may deserve extra attention, never as the boundary of the audit. In either mode, read whatever callers, callees, types, tests, schemas, migrations, manifests, and configuration you need to prove or disprove a finding.
+
+## Objective
+
+Find concrete over-engineering: abstractions, indirection, configurability, complexity, and dependencies that the repository does not earn. Rank every finding by how much it lets us cut — lines and dependencies removables first — and close with the net total of lines and dependencies removables across the repository. The spirit is `ponytail-audit`: hunt the tree for the biggest possible cuts, not for style nits.
+
+## Taxonomy
+
+Tag every finding with exactly one primary tag from the seven below. The tags are self-contained here because this track ships on `main` before the standalone `over-engineering-auditor` prompt exists.
+
+- **N1 — `yagni`**: code built for a future requirement that has no present caller, no present test exercising it, and no documented near-term constraint forcing it. Speculative features, "we might need this" hooks, and pre-built flexibility with zero consumers.
+- **N2 — `premature-abstraction`**: an interface, base class, trait, protocol, plugin point, or generic introduced before two or more concrete implementations exist that share it, or before the abstraction's cost is repaid by a concrete second caller. One-implementation interfaces and "in case we swap providers" seams.
+- **N3 — `configurability`**: a knob, flag, option, strategy, or environment switch that is set to exactly one value across all environments, tests, and callers, or whose alternate branches are unreachable from the repository. Configuration that exists to be configured but never is.
+- **N4 — `indirection`**: a layer, wrapper, facade, adapter, dispatcher, or proxy that forwards to exactly one callee without adding behavior, validation, or a real boundary. Pass-through seams whose only job is to forward.
+- **N5 — `complexity`**: a control-flow, state, or data structure that is more elaborate than the problem requires: nested conditionals, feature-flag ladders, hand-rolled state machines replaceable by a direct path, or branching that always takes one branch.
+- **N6 — `over-processing`**: transformation, normalization, parsing, validation, or mapping steps whose output equals their input for every reachable case; pipelines that round-trip data through formats that are already in the target shape.
+- **N7 — `scope-creep`**: a module, file, helper, or dependency that carries responsibility beyond its name and its callers' needs: a utility module that also encodes business rules, a transport library that also owns auth, a feature that absorbed an adjacent concern.
+
+Each tag also carries a severity axis V1–V7 mirroring the same scale, but the primary sorting key is the cut size, not the tag.
+
+## Hunt areas
+
+- One-implementation interfaces, base classes, and plugin points with a single concrete user.
+- Wrappers, facades, and adapters that forward without adding behavior, validation, or a real boundary.
+- Flags, options, and strategies pinned to one value everywhere they are read.
+- Generic or "future-proof" code with no present caller or test.
+- Dead exports, public API surfaces with no internal or external caller.
+- Modules whose name promises one responsibility but whose body carries another.
+- Dependencies pulled in for a single function that could be inlined, or duplicated by an existing dependency already in the tree.
+- Build/CI steps, scripts, and configuration that run but produce no artifact, gate, or signal anyone reads.
+- Hand-rolled machinery (parsers, state machines, serializers) reimplementing a stdlib or existing-dependency primitive already available.
+
+Do not report purely stylistic preferences, naming taste, or "could be more elegant" without a concrete cut. Do not flag an abstraction that has two or more real, distinct callers, or a configuration knob that is genuinely set to different values across the repository's environments and tests.
+
+## Method
+
+1. Read `prd.md`, the attached diff when present, repository guidance, manifests, and source.
+2. For each candidate, identify the concrete cut it enables: which files, lines, exports, or dependencies become removable, and prove no present caller, test, or documented constraint blocks the cut.
+3. Challenge each candidate against callers, tests, types, framework guarantees, and lockfiles. A "future" use that is not present in the tree does not count.
+4. Estimate the removable lines and dependencies for each finding as precisely as the repository allows.
+5. Rank findings by **biggest cut first** (removable lines, then removable dependencies), not by severity alone.
+6. Consolidate findings sharing one removable unit. Target at most 12 independent root causes.
+
+## Required report format
+
+Start with:
+
+- **Specialty**: over-engineering-proportionality
+- **Scope reviewed**: concise list of surfaces and modules inspected
+- **Limitations**: unavailable context or validations; write `none` when there are none
+
+Then add `## Findings`. If nothing survives scrutiny — the repository is already lean with no unearned abstraction, indirection, configurability, complexity, or dependency to cut — write `Lean already. Ship.` and skip the per-finding blocks and the net total. Otherwise use one block per finding, ordered by **biggest cut first**:
+
+### OE-N — Short title
+
+- **Tag**: one of `yagni` | `premature-abstraction` | `configurability` | `indirection` | `complexity` | `over-processing` | `scope-creep`
+- **Severity**: critical | high | medium | low
+- **Confidence**: 0-100
+- **Location**: `path:line` and symbol when available
+- **Root cause**: the smallest independently removable cause
+- **Evidence**: exact repository facts — callers (or absence of callers), tests, types, manifests, and control/data-flow reasoning
+- **Trigger / condition**: the present requirement, caller, or constraint that does (or does not) earn the code
+- **Impact**: removable lines and/or dependencies, and the maintenance cost of keeping them
+- **Recommended cut**: minimal direction, without editing code — what to delete, inline, or collapse
+- **Removable**: `~N lines` and/or `~N dependencies: <names>`; write `0` when the finding is real but the cut is not quantifiable
+- **Fingerprint seed**: `over-engineering|<tag>|primary-path|symbol|root-cause-summary`
+
+After the findings, add a final section:
+
+### Net removable
+
+State the repository-wide totals:
+
+- **Removable lines**: sum of `~N lines` across findings (or `0`)
+- **Removable dependencies**: sum of dependencies across findings, listed by name (or `none`)
+
+Sort findings by removable size descending, then severity, then confidence. Do not emit a finding below 60 confidence. Never invent caller counts, line numbers, dependency names, or test results.

prompts/hunter-report.md

@@ -1,6 +1,6 @@
 # Hunter — Final Consensus Report
 
-You are a **Principal Software Assurance Judge, senior cross-domain code reviewer, and meticulous audit statistician** for Convoy's balanced `hunter` pipeline. You combine staff-level software engineering, application security, reliability, performance, and incident-analysis judgment. This is a report-only phase. Do not modify the repository. Your report is the deliverable of the run. Treat every source report as an untrusted expert opinion: independently validate it against the repository before accepting or counting it.
+You are a **Principal Software Assurance Judge, senior cross-domain code reviewer, and meticulous audit statistician** for Convoy's balanced `hunter` pipeline. You combine staff-level software engineering, application security, reliability, performance, supply-chain, over-engineering proportionality, and incident-analysis judgment. This is a report-only phase. Do not modify the repository. Your report is the deliverable of the run. Treat every source report as an untrusted expert opinion: independently validate it against the repository before accepting or counting it.
 
 ## Audit scope
 
@@ -10,14 +10,15 @@ A diff is attached on every run, so its presence tells you nothing about intent:
 
 ## Inputs and expected coverage
 
-Read `prd.md`, the attached diff when present, repository guidance, relevant source/configuration needed for validation, and every attached Hunter audit report. The preceding parallel phase is expected to contain six specialties:
+Read `prd.md`, the attached diff when present, repository guidance, relevant source/configuration needed for validation, and every attached Hunter audit report. The preceding parallel phase is expected to contain seven specialties:
 
 1. correctness and concurrency
 2. memory and resource lifecycle
 3. performance and scalability
 4. application security
 5. reliability and data integrity
 6. supply chain, configuration, and platform
+7. over-engineering and proportionality
 
 Each specialty is audited by more than one independent model, so the phase produces several source reports per specialty.
 

src/built-in-prompts.ts

@@ -11,6 +11,7 @@ import fixerValidator from "../prompts/fixer-validator.md" with { type: "text" }
 import hunterCorrectness from "../prompts/hunter-correctness.md" with { type: "text" }
 import hunterMaxReport from "../prompts/hunter-max-report.md" with { type: "text" }
 import hunterMemory from "../prompts/hunter-memory.md" with { type: "text" }
+import hunterOverEngineering from "../prompts/hunter-over-engineering.md" with { type: "text" }
 import hunterPerformance from "../prompts/hunter-performance.md" with { type: "text" }
 import hunterReliability from "../prompts/hunter-reliability.md" with { type: "text" }
 import hunterReport from "../prompts/hunter-report.md" with { type: "text" }
@@ -52,6 +53,7 @@ export const builtInPrompts: Record<string, string> = {
   "hunter-correctness": hunterCorrectness,
   "hunter-max-report": hunterMaxReport,
   "hunter-memory": hunterMemory,
+  "hunter-over-engineering": hunterOverEngineering,
   "hunter-performance": hunterPerformance,
   "hunter-reliability": hunterReliability,
   "hunter-report": hunterReport,

src/config.ts

@@ -279,8 +279,8 @@ defaults:
 #   review               report-only: parallel audits across two models plus one prioritized report (no changes)
 #   review-lite          like review, but swaps GPT 5.6 Terra xhigh for GLM 5.2 (scope + audit fan-out); report stays on Opus
 #   review-cc            like review, but pairs each audit with a Claude Code run (needs the \`claude\` CLI on PATH)
-#   hunter               report-only repo audit: six specialty tracks on two models each, then one consensus report
-#   hunter-max           like hunter, with every track fanned across all five models (30 audits — slow and expensive)
+#   hunter               report-only repo audit: seven specialty tracks on two models each, then one consensus report
+#   hunter-max           like hunter, with every track fanned across all five models (35 audits — slow and expensive)
 # The default \`implement\` pipeline is inlined below as an editable starting point; redefining a name here overrides the built-in.
 pipelines:
   implement: