Explore specialist review passes behind a single reviewer lane

[davidruzicka]

Summary

Evaluate whether the code review stage should stay externally single-lane (reviewer) while internally supporting specialized review passes (for example security, performance, API/contract, and test adequacy).

Motivation

Current workflow design treats review as a single reviewer lane. That keeps the state machine simple, but a single generic review prompt may not cover the full space of review concerns well enough across code quality, security, performance, compatibility, and test quality.

Recent discussion and current research direction suggest a useful hybrid shape:

• keep one public reviewer lane for deterministic workflow semantics,
• optionally run specialized internal review passes when repo/risk signals justify them,
• aggregate findings into one normalized review artifact/comment instead of producing multiple noisy public reviewer personas.

Why this might help

• Better coverage for heterogeneous review tasks.
• Preserve current external workflow semantics (reviewer + merger).
• Reduce noise compared with multiple public reviewer agents commenting independently.
• Allow selective, risk-triggered review depth instead of paying full cost on every PR.

Candidate design direction

External contract

• Keep one public reviewer lane.
• Keep one merge decision path through merger.

Internal review passes

• reviewer-general
• reviewer-security
• reviewer-performance
• reviewer-api
• reviewer-tests

Triggering

Only run specialist passes when justified, for example:

• security-sensitive files / auth / crypto / shell / file / deserialization paths,
• hot paths or likely performance-sensitive changes,
• schema / API / contract changes,
• large test deltas or suspiciously low test impact.

Output shape

Aggregate all findings into a normalized machine-readable artifact with fields like:

• category
• severity
• confidence
• evidence
• blocking
• head_sha
• source_pass

Guardrails

• avoid duplicate findings across passes,
• keep fail-closed merge semantics explicit,
• do not let multiple reviewer personas create contradictory public state,
• prefer specialist passes + tooling/analyzers over multiple nearly-identical free-text prompts.

Open questions

• Which specialist passes are worth the runtime/cost overhead first?
• Should specialist findings be blocking by default or only after confidence/severity thresholds?
• How should the planner/implementor handoff represent specialist findings?
• Which findings should remain advisory vs merge-blocking?

Relationship to current work

• Related to Tracking: Close PR review/fix loop #184 (close PR review/fix loop)
• Related to Define merge blocking policy for unresolved review threads #180 (merge blocking policy)
• Could become a later-phase hardening/design issue after the current phase-1 review loop is stable.

Agent note: this issue body was drafted by an agent from a research-backed design discussion.

[davidruzicka]

Agent note: Aktualizovaný metodický plán implementace s nejmodernějšími modely Claude Opus 4.6, Claude Sonnet 4.6, GPT-5.3-Codex a GPT-5.4.

Přehled modelů (březen 2026)

Model	Kontext	Cena (in/out)	Specializace	Klíčová vlastnost pro Code Review
Claude Opus 4.6	1M (beta) / 200K std	$15/$75	Deep reasoning, agent teams	76% retrieval @ 1M tokenů, extended thinking
Claude Sonnet 4.6	200K	$3/$15	Everyday coding	98% výkonu Opusu za 1/5 ceny, rychlý
GPT-5.3-Codex	1M s compaction	$5/$15	Autonomous coding	Trained pro agentic coding, tool use
GPT-5.4	1M	variabilní	General reasoning	Reasoning effort controls, 47% méně tokenů než 5.3

*Ceny za 1M tokenů. Zdroje: *

---

Revidovaná architektura MACRS v2.0

Assignace modelů podle rolí

1. Security Auditor → Claude Opus 4.6 (High Effort)

Proč: Bezpečnost vyžaduje nejhlubší reasoning a detekce subtilních zranitelností. Opus 4.6 má oproti Sonnetu výrazně lepší výsledky v "long document work" (76% vs 18.5% retrieval) a podporuje agent teams pro paralelní kontrolu různých attack vektorů.

Konfigurace:

model: claude-opus-4-6
thinking: {type: "adaptive"}  # Nový doporučený mód místo budget_tokens
effort: max  # Pro security je nutné maximum
context_window: 1M  # Pro analýzu velkých změn napříč celým codebase

Prompt specifika pro Opus 4.6:

• Použij structured autonomy clauses - Opus 4.6 vyžaduje explicitní instrukce pro persistenci (podobně jako Codex, ale s většíemphasis na "catching own mistakes")
• Využij agent teams pro sub-úkoly: "Spawn 3 sub-agents: one for SQL injection, one for auth bypass, one for dependency vulnerabilities"
• Implementuj context compaction pro session > 200K tokenů (automatické shrnutí kontextu)

2. Performance Agent → GPT-5.3-Codex (Medium Effort)

Proč: Specializovaný model pro kódování s optimalizací pro codebase exploration a pattern matching. Dle dokumentace je "recommended agentic coding model" s výrazně lepším token efficiency (47% méně tokenů než předchozí verze na komplexních úkolech).

Konfigurace:

model: gpt-5.3-codex
reasoning_effort: medium  # Doporučeno pro interaktivní coding tasks
compaction: enabled  # Pro dlouhé analýzy
max_completion_tokens: 4096  # Prevence runaway responses

Prompt specifika pro Codex:

• Odstraň upfront plány: Prompting pro "upfront plan" způsobuje abrupt stops u Codexu - místo toho použij "autonomy and persistence" clause
• Parallel tool calls: Codex je trénován na paralelizaci (multi_tool_use.parallel) - vždy čti více souborů najednou
• Použij apply_patch: Preferuj apply_patch tool místo raw terminal commands pro editaci
• Redakce metadat: Odstraň Lxxx: prefixy z kódu před analýzou (Codex je může brát jako obsah)

Codex-Max prompt template:

You are Codex, based on GPT-5. You are running as a performance analysis agent.

# Autonomy and Persistence
Persist until the task is fully handled end-to-end: do not stop at analysis or partial fixes. Bias to action: default to implementing with reasonable assumptions.

# Performance Analysis Specifics
- Focus: Big-O complexity, N+1 queries, memory leaks, async bottlenecks
- Search first: Use rg for pattern matching across codebase
- When exploring: Batch all file reads via multi_tool_use.parallel
- Before any tool call, decide ALL files you will need
- Provide working code fixes, not just descriptions

# Output Format
Structured JSON with fields: severity, line, issue_type, current_complexity, suggested_fix, confidence

3. Maintainability Agent → Claude Sonnet 4.6 (Low Effort)

Proč: Code quality review nevyžaduje deep reasoning jako security. Sonnet 4.6 poskytuje 98% kódového výkonu Opusu za 1/5 ceny ($3/$15 vs $15/$75) a je výrazně rychlejší. Nemá extended thinking (což je OK pro tuto doménu), ale má stejný 200K kontext jako Opus.

Konfigurace:

model: claude-sonnet-4-6
effort: low  # Maintainability nevyžaduje max effort, low stačí a je rychlé
# Poznámka: Sonnet 4.6 nepodporuje agent teams ani extended thinking

Prompt specifika:

• Standardní strukturovaný prompt s output contract
• Využij rychlosti pro diversity generation - spusť 3x se stejným promptem s různými temperature (0.2, 0.4, 0.6) pro pokrytí různých perspektiv quality

4. Coverage Validator (Meta-Agent) → Claude Opus 4.6 s 1M kontextem

Proč: Tento agent musí držet v paměti celý diff + všechny reporty všech agentů pro validaci pokrytí. Opus 4.6 s 1M kontextem (beta) je jediný model schopný držet velké PRs s kontextem bez "context rot" (76% retrieval vs 18.5% u předchozí generace).

Konfigurace:

model: claude-opus-4-6
context_window: 1M  # Nutné pro large PRs
effort: medium  # Metatask nevyžaduje max, ale potřebuje spolehlivost

5. Consensus Builder / Synthesis → GPT-5.4 s reasoning controls

Proč: Potřebuje strukturovaný výstup a schopnost "výběru úsilí" podle složitosti konfliktů. GPT-5.4 má explicitní reasoning_effort parametr (none/medium/high/xhigh) a podporuje "output contracts" pro garantovanou strukturu výstupu.

Konfigurace:

model: gpt-5.4
reasoning_effort: medium  # Zvýš na high pouze pokud jsou konflikty komplexní
max_completion_tokens: 8192  # Pro dlouhé syntetické reporty

Prompt specifika pro GPT-5.4:

• Output Contract: Explicitně definuj strukturu výstupu
• Verbosity Controls: "Prefer concise, information-dense writing"
• Front-load relevant files: V promptu dej nejdřív reporty od důležitějších agentů (security > performance > maintainability)
• Avoid nested bullets: GPT-5.4 má tendenci přehánět s formátováním - explicitně zakáž nested structures

Synthesis prompt pattern:

<output_contract>
- Return exactly: 1) Summary of security issues (critical only), 2) Performance bottlenecks, 3) Maintainability suggestions, 4) Coverage gaps if any
- Format: Markdown with flat lists only (single level), no nested bullets
- Length: Max 200 words per section
</output_contract>

<verbosity_controls>
- Prefer concise, information-dense writing
- Avoid repeating agent findings verbatim, synthesize instead
</verbosity_controls>

---

GitHub Actions Workflow (aktualizovaný)

name: MACRS v2.0 - Multi-Agent Code Review

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  # Paralelní agenti - každý s vlastním modelem
  security-opus:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      
      - name: Security Analysis (Opus 4.6)
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          python agents/opus_security_agent.py \
            --model claude-opus-4-6 \
            --effort max \
            --thinking adaptive \
            --diff "${{ github.event.pull_request.diff_url }}" \
            --checklist config/security_criteria.json
      
      - name: Upload Security Report
        uses: actions/upload-artifact@v4
        with:
          name: security-report
          path: reports/security.json

  performance-codex:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Performance Analysis (GPT-5.3-Codex)
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        run: |
          # Codex specific: použijeme medium reasoning a compaction
          python agents/codex_performance_agent.py \
            --model gpt-5.3-codex \
            --reasoning-effort medium \
            --compaction enabled \
            --diff "${{ github.event.pull_request.diff_url }}" \
            --focus complexity,async_patterns,memory \
            --parallel-tools  # Codex optimalizace
      
      - name: Upload Performance Report
        uses: actions/upload-artifact@v4
        with:
          name: performance-report
          path: reports/performance.json

  maintainability-sonnet:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        temperature: [0.2, 0.5]  # Diversity generation pro pokrytí
    steps:
      - uses: actions/checkout@v4
      
      - name: Maintainability Analysis (Sonnet 4.6)
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          python agents/sonnet_maintainability_agent.py \
            --model claude-sonnet-4-6 \
            --effort low \
            --temperature ${{ matrix.temperature }} \
            --diff "${{ github.event.pull_request.diff_url }}"
      
      - name: Upload Maintainability Report
        uses: actions/upload-artifact@v4
        with:
          name: maintainability-report-${{ matrix.temperature }}
          path: reports/maintainability_${{ matrix.temperature }}.json

  # Syntéza a coverage validation
  synthesis:
    needs: [security-opus, performance-codex, maintainability-sonnet]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Coverage Validation (Opus 4.6 - 1M context)
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          # Využijeme 1M kontext pro velké PRs
          python agents/opus_coverage_validator.py \
            --model claude-opus-4-6 \
            --context-window 1m \
            --security reports/security.json \
            --performance reports/performance.json \
            --maintainability reports/maintainability_*.json \
            --diff "${{ github.event.pull_request.diff_url }}"
      
      - name: Consensus Building (GPT-5.4)
        if: success() || failure()  # Spustí i když coverage najde mezery
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        run: |
          python agents/gpt54_consensus_agent.py \
            --model gpt-5.4 \
            --reasoning-effort medium \
            --input reports/ \
            --output final_report.md
      
      - name: Post PR Comment
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const report = fs.readFileSync('final_report.md', 'utf8');
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: report
            });

---

Model-specific prompting doporučení

Pro Claude Opus 4.6 (Security & Coverage)

1. Agent Teams pro bezpečnost: Pokud máš složitý PR, použij Opus 4.6 capability pro spawnování sub-agentů: "Spawn 3 security sub-agents: one for injection analysis, one for auth logic, one for dependencies"
2. Adaptive Thinking: Použij thinking: {type: "adaptive"} místo fixed budget - Opus 4.6 dynamicky rozhoduje kdy myslet hluboce
3. Context Compaction: Pro session > 200K tokenů zapni compaction (automated context summarization)

Pro GPT-5.3-Codex (Performance)

1. Nepoužívej upfront plány: Codex má tendenci zastavit se po vytvoření plánu. Místo toho použij "Persist until fully handled" clause
2. Parallelization je klíčová: Vždy batchuj file reads přes multi_tool_use.parallel - Codex je trénován na paralelní tool use
3. apply_patch tool: Pro editaci kódu použij dedicated apply_patch tool místo shell commands
4. Redakce metadat: Před posláním kódu odstraň line number prefixy (L123:) - Codex je může brát jako součást kódu

Pro GPT-5.4 (Synthesis)

1. Output Contracts: Definuj explicitně strukturu výstupu pro syntézu
2. Front-loading: Dej nejdůležitější reporty (security) na začátek kontextu - GPT-5.4 dává silnější attention začátku a konci
3. Verbosity Controls: Explicitně požádej o "concise, information-dense writing" - jinak má tendenci generovat verbose výstupy

Pro Claude Sonnet 4.6 (Maintainability)

1. Cost-efficiency: Sonnet je 5x levnější než Opus - ideální pro high-volume tasks jako maintainability review
2. Low effort: Pro maintainability stačí effort: low - je rychlé a levné, high effort je overkill
3. Diversity via temperature: Spusť více instancí s různými teplotami (0.2 a 0.5) pro pokrytí různých perspektiv kvality

---

Cost analýza (projekce)

Pro PR s ~500 řádky změn (typický střední PR):

Agent	Model	Odhad tokenů	Cena	Poznámka
Security	Opus 4.6 (max)	50K in / 10K out	$1.50	High effort nutný
Performance	Codex (medium)	30K in / 8K out	$0.27	Compaction šetří tokeny
Maintainability (×2)	Sonnet 4.6 (low)	25K in / 5K out ×2	$0.23	2× pro diversity
Coverage	Opus 4.6 (medium)	80K in / 5K out	$1.68	1M kontext pro velké PRs
Synthesis	GPT-5.4 (medium)	20K in / 3K out	~$0.40	Závisí na struktuře
Celkem			~$3.08

*Ceny výpočteny podle $15/$75 pro Opus, $3/$15 pro Sonnet, $5/$15 pro Codex, odhad pro GPT-5.4 dle struktury pricingu *

Toto je o ~50% levnější než použití Opus 4.6 pro všechny agenty, při zachování kvality bezpečnostní analýzy (kde Opus exceluje) a efektivity maintainability (kde Sonnet stačí).

---

Implementační checklist pro agenta

1. Setup API klíčů: Zajisti ANTHROPIC_API_KEY (Opus + Sonnet) a OPENAI_API_KEY (Codex + GPT-5.4)
2. Rate limiting: Opus 4.6 s max effort a 1M kontextem může být pomalý - nastav timeouty min. 5 minut
3. Compaction test: Pro Codex otestuj compaction na dlouhých diffech (>100K tokenů)
4. Agent teams test: Pokud použiješ Opus 4.6 agent teams pro security, otestuj nejdřív v isolated environment (research preview feature)
5. Cost caps: Nastav billing alerts - 1M kontext Opusu je výkonný ale může být drahý při velkých PRs
6. Prompt versioning: Codex a GPT-5.4 mají odlišné prompt preferences - verzuj prompty separátně pro Anthropic a OpenAI modely

Tento plán využívá model tiering pro optimalizaci cost/performance při zachování nejvyšší kvality u kritické bezpečnostní analýzy a pokrytí kontextu u velkých PRs.

[davidruzicka]

Agent-authored framing note: the model/provider-specific implementation sketch above is useful as design input, but it should be treated as a secondary follow-up layer rather than the primary decision captured by this issue.

For #202, the first-order questions are still workflow-contract questions:

• should we support specialist internal review passes at all,
• which passes are worth introducing first,
• what normalized artifact/output contract they must produce,
• how specialist findings map into the single public reviewer lane,
• which findings are advisory vs merge-blocking,
• how deduplication and head-SHA binding should work.

A reasonable sequencing would be:

1. decide the workflow contract and merge semantics,
2. define trigger rules and normalized outputs,
3. only then evaluate provider/model routing and runtime orchestration as an implementation strategy.

So the detailed model-tiering proposal is relevant, but best understood here as one candidate implementation direction after the phase-1 review-loop work and the workflow-level decisions are settled.

[github-actions]

🤖 Agent implementation note (implementor)

Implementation lease acquired for issue #202.

[github-actions]

🤖 Agent implementation note (implementor)

Implementation result: failed
Summary: Implementor command failed: Command failed: bash -lc node dist/scripts/run-implementor-codex.js
node:internal/errors:984
const err = new Error(message);
^

Error: Command failed: codex exec --full-auto You are the Codex implementor backend for the mcp4openapi autonomous issue pipeline.
Work only inside the current git repository/worktree and keep the change narrowly scoped to the issue below.
Use senior-level code quality: modular design, clean code, explicit boundaries, data-oriented logic where reasonable, no duplication, and safe defaults.
Use strict TDD: add or update tests first, confirm the relevant tests fail, implement the minimal change, then rerun targeted tests and typecheck.
Run targeted tests and typecheck before creating the PR.
Use English for code comments, commit messages, PR title/body, and notes.
Create a dedicated branch if needed, commit with a Conventional Commits message, push it, and open a PR linked to the issue.
The PR description must clearly disclose automation with this exact sentence: "This PR was created by an automated agent."
The PR body should also mention the agent role, source issue number, workflow run ID, testing performed, and any assumptions or limits.
If you cannot complete the task safely, do not open a PR. Return outcome "blocked" for policy/scope blockers or "failed" for implementation/tooling failures.

Repository: davidruzicka/mcp4openapi
Agent ID: implementor
Workflow run ID: github-actions-23397114201
Timestamp: 2026-03-22T06:11:40.905Z
Issue #202: Explore specialist review passes behind a single reviewer lane
Issue URL: #202
Issue labels: enhancement, agent:safe, architecture, agent-support, agent:planned

Issue body:

Summary

Evaluate whether the code review stage should stay externally single-lane (reviewer) while internally supporting specialized review passes (for example security, performance, API/contract, and test adequacy).

Motivation

Current workflow design treats review as a single reviewer lane. That keeps the state machine simple, but a single generic review prompt may not cover the full space of review concerns well enough across code quality, security, performance, compatibility, and test quality.

Recent discussion and current research direction suggest a useful hybrid shape:

• keep one public reviewer lane for deterministic workflow semantics,
• optionally run specialized internal review passes when repo/risk signals justify them,
• aggregate findings into one normalized review artifact/comment instead of producing multiple noisy public reviewer personas.

Why this might help

• Better coverage for heterogeneous review tasks.
• Preserve current external workflow semantics (reviewer + merger).
• Reduce noise compared with multiple public reviewer agents commenting independently.
• Allow selective, risk-triggered review depth instead of paying full cost on every PR.

Candidate design direction

External contract

• Keep one public reviewer lane.
• Keep one merge decision path through merger.

Internal review passes

• reviewer-general
• reviewer-security
• reviewer-performance
• reviewer-api
• reviewer-tests

Triggering

Only run specialist passes when justified, for example:

• security-sensitive files / auth / crypto / shell / file / deserialization paths,
• hot paths or likely performance-sensitive changes,
• schema / API / contract changes,
• large test deltas or suspiciously low test impact.

Output shape

Aggregate all findings into a normalized machine-readable artifact with fields like:

• category
• severity
• confidence
• evidence
• blocking
• head_sha
• source_pass

Guardrails

• avoid duplicate findings across passes,
• keep fail-closed merge semantics explicit,
• do not let multiple reviewer personas create contradictory public state,
• prefer specialist passes + tooling/analyzers over multiple nearly-identical free-text prompts.

Open questions

• Which specialist passes are worth the runtime/cost overhead first?
• Should specialist findings be blocking by default or only after confidence/severity thresholds?
• How should the planner/implementor handoff represent specialist findings?
• Which findings should remain advisory vs merge-blocking?

Relationship to current work

• Related to Tracking: Close PR review/fix loop #184 (close PR review/fix loop)
• Related to Define merge blocking policy for unresolved review threads #180 (merge blocking policy)
• Could become a later-phase hardening/design issue after the current phase-1 review loop is stable.

Agent note: this issue body was drafted by an agent from a research-backed design discussion.

Required final output:

• Write exactly one JSON object to /tmp/mcp4openapi-implementor-codex-dUzGLn/result.json
• The JSON must match this schema:
  {
  "outcome": "pr-created" | "failed" | "blocked",
  "summary": "short human-readable summary",
  "pullRequest": { "number": 123, "url": "https://github.com/owner/repo/pull/123" }
  }
• Include pullRequest only when outcome is "pr-created".
• Do not wrap the JSON in markdown.
• Ensure the file contents are valid JSON before exiting.
  OpenAI Codex v0.116.0 (research preview)

---

workdir: /home/runner/work/mcp4openapi/mcp4openapi
model: gpt-5.3-codex
provider: openai
approval: never
sandbox: workspace-write [workdir, /tmp, $TMPDIR, /home/runner/.codex/memories]
reasoning effort: none
reasoning summaries: none
session id: 019d142b-bba7-7d91-a709-5c103e72046e

user
You are the Codex implementor backend for the mcp4openapi autonomous issue pipeline.
Work only inside the current git repository/worktree and keep the change narrowly scoped to the issue below.
Use senior-level code quality: modular design, clean code, explicit boundaries, data-oriented logic where reasonable, no duplication, and safe defaults.
Use strict TDD: add or update tests first, confirm the relevant tests fail, implement the minimal change, then rerun targeted tests and typecheck.
Run targeted tests and typecheck before creating the PR.
Use English for code comments, commit messages, PR title/body, and notes.
Create a dedicated branch if needed, commit with a Conventional Commits message, push it, and open a PR linked to the issue.
The PR description must clearly disclose automation with this exact sentence: "This PR was created by an automated agent."
The PR body should also mention the agent role, source issue number, workflow run ID, testing performed, and any assumptions or limits.
If you cannot complete the task safely, do not open a PR. Return outcome "blocked" for policy/scope blockers or "failed" for implementation/tooling failures.

Repository: davidruzicka/mcp4openapi
Agent ID: implementor
Workflow run ID: github-actions-23397114201
Timestamp: 2026-03-22T06:11:40.905Z
Issue #202: Explore specialist review passes behind a single reviewer lane
Issue URL: #202
Issue labels: enhancement, agent:safe, architecture, agent-support, agent:planned

Issue body:

Summary

Evaluate whether the code review stage should stay externally single-lane (reviewer) while internally supporting specialized review passes (for example security, performance, API/contract, and test adequacy).

Motivation

Current workflow design treats review as a single reviewer lane. That keeps the state machine simple, but a single generic review prompt may not cover the full space of review concerns well enough across code quality, security, performance, compatibility, and test quality.

Recent discussion and current research direction suggest a useful hybrid shape:

• keep one public reviewer lane for deterministic workflow semantics,
• optionally run specialized internal review passes when repo/risk signals justify them,
• aggregate findings into one normalized review artifact/comment instead of producing multiple noisy public reviewer personas.

Why this might help

• Better coverage for heterogeneous review tasks.
• Preserve current external workflow semantics (reviewer + merger).
• Reduce noise compared with multiple public reviewer agents commenting independently.
• Allow selective, risk-triggered review depth instead of paying full cost on every PR.

Candidate design direction

External contract

• Keep one public reviewer lane.
• Keep one merge decision path through merger.

Internal review passes

• reviewer-general
• reviewer-security
• reviewer-performance
• reviewer-api
• reviewer-tests

Triggering

Only run specialist passes when justified, for example:

• security-sensitive files / auth / crypto / shell / file / deserialization paths,
• hot paths or likely performance-sensitive changes,
• schema / API / contract changes,
• large test deltas or suspiciously low test impact.

Output shape

Aggregate all findings into a normalized machine-readable artifact with fields like:

• category
• severity
• confidence
• evidence
• blocking
• head_sha
• source_pass

Guardrails

• avoid duplicate findings across passes,
• keep fail-closed merge semantics explicit,
• do not let multiple reviewer personas create contradictory public state,
• prefer specialist passes + tooling/analyzers over multiple nearly-identical free-text prompts.

Open questions

• Which specialist passes are worth the runtime/cost overhead first?
• Should specialist findings be blocking by default or only after confidence/severity thresholds?
• How should the planner/implementor handoff represent specialist findings?
• Which findings should remain advisory vs merge-blocking?

Relationship to current work

• Related to Tracking: Close PR review/fix loop #184 (close PR review/fix loop)
• Related to Define merge blocking policy for unresolved review threads #180 (merge blocking policy)
• Could become a later-phase hardening/design issue after the current phase-1 review loop is stable.

Agent note: this issue body was drafted by an agent from a research-backed design discussion.

Required final output:

• Write exactly one JSON object to /tmp/mcp4openapi-implementor-codex-dUzGLn/result.json

• The JSON must match this schema:
  {
  "outcome": "pr-created" | "failed" | "blocked",
  "summary": "short human-readable summary",
  "pullRequest": { "number": 123, "url": "https://github.com/owner/repo/pull/123" }
  }

• Include pullRequest only when outcome is "pr-created".

• Do not wrap the JSON in markdown.

• Ensure the file contents are valid JSON before exiting.
  warning: Codex could not find system bubblewrap at /usr/bin/bwrap. Please install bubblewrap with your package manager. Codex will use the vendored bubblewrap in the meantime.
  mcp startup: no servers
  2026-03-22T06:11:43.950205Z ERROR codex_api::endpoint::responses_websocket: failed to connect to websocket: HTTP error: 500 Internal Server Error, url: wss://api.openai.com/v1/responses
  2026-03-22T06:11:44.232820Z ERROR codex_api::endpoint::responses_websocket: failed to connect to websocket: HTTP error: 500 Internal Server Error, url: wss://api.openai.com/v1/responses
  2026-03-22T06:11:44.677093Z ERROR codex_api::endpoint::responses_websocket: failed to connect to websocket: HTTP error: 500 Internal Server Error, url: wss://api.openai.com/v1/responses
  Reconnecting... 2/5 (We're currently experiencing high demand, which may cause temporary errors.)
  2026-03-22T06:11:45.345094Z ERROR codex_api::endpoint::responses_websocket: failed to connect to websocket: HTTP error: 500 Internal Server Error, url: wss://api.openai.com/v1/responses
  Reconnecting... 3/5 (We're currently experiencing high demand, which may cause temporary errors.)
  2026-03-22T06:11:46.439882Z ERROR codex_api::endpoint::responses_websocket: failed to connect to websocket: HTTP error: 500 Internal Server Error, url: wss://api.openai.com/v1/responses
  Reconnecting... 4/5 (We're currently experiencing high demand, which may cause temporary errors.)
  2026-03-22T06:11:48.311544Z ERROR codex_api::endpoint::responses_websocket: failed to connect to websocket: HTTP error: 500 Internal Server Error, url: wss://api.openai.com/v1/responses
  Reconnecting... 5/5 (We're currently experiencing high demand, which may cause temporary errors.)
  2026-03-22T06:11:51.808238Z ERROR codex_api::endpoint::responses_websocket: failed to connect to websocket: HTTP error: 500 Internal Server Error, url: wss://api.openai.com/v1/responses
  warning: Falling back from WebSockets to HTTPS transport. We're currently experiencing high demand, which may cause temporary errors.
  Reconnecting... 1/5 (unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses, cf-ray: 9e030a991b6be5f9-IAD, request id: req_f54570939118446997c3ba434f96adcd)
  Reconnecting... 2/5 (unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses, cf-ray: 9e030a9b4c107fa2-IAD, request id: req_16d5f611c7854beaa15dc63acd2dc1b9)
  Reconnecting... 3/5 (unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses, cf-ray: 9e030a9eb9b0dab8-IAD, request id: req_a25d85ce73d84ec9a695ce29fbfb7878)
  Reconnecting... 4/5 (unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses, cf-ray: 9e030aa468e22d85-IAD, request id: req_79496814620e4e2c8815fa979e6bd9d8)
  Reconnecting... 5/5 (unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses, cf-ray: 9e030aaf9ece593d-IAD, request id: req_11fe97e57fe343ef9e5f08a3ac390fe1)
  ERROR: unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses, cf-ray: 9e030ac3d9e2e5f9-IAD, request id: req_e7de71fe77574fb7a0836fd2123743da

  at genericNodeError (node:internal/errors:984:15)
  at wrappedFn (node:internal/errors:538:14)
  at ChildProcess.exithandler (node:child_process:422:12)
  at ChildProcess.emit (node:events:524:28)
  at maybeClose (node:internal/child_process:1104:16)
  at ChildProcess._handle.onexit (node:internal/child_process:304:5) {
  code: 1,
  killed: false,
  signal: null,
  cmd: 'codex exec --full-auto You are the Codex implementor backend for the mcp4openapi autonomous issue pipeline.\n' +
  'Work only inside the current git repository/worktree and keep the change narrowly scoped to the issue below.\n' +
  'Use senior-level code quality: modular design, clean code, explicit boundaries, data-oriented logic where reasonable, no duplication, and safe defaults.\n' +
  'Use strict TDD: add or update tests first, confirm the relevant tests fail, implement the minimal change, then rerun targeted tests and typecheck.\n' +
  'Run targeted tests and typecheck before creating the PR.\n' +
  'Use English for code comments, commit messages, PR title/body, and notes.\n' +
  'Create a dedicated branch if needed, commit with a Conventional Commits message, push it, and open a PR linked to the issue.\n' +
  'The PR description must clearly disclose automation with this exact sentence: "This PR was created by an automated agent."\n' +
  'The PR body should also mention the agent role, source issue number, workflow run ID, testing performed, and any assumptions or limits.\n' +
  'If you cannot complete the task safely, do not open a PR. Return outcome "blocked" for policy/scope blockers or "failed" for implementation/tooling failures.\n' +
  '\n' +
  'Repository: davidruzicka/mcp4openapi\n' +
  'Agent ID: implementor\n' +
  'Workflow run ID: github-actions-23397114201\n' +
  'Timestamp: 2026-03-22T06:11:40.905Z\n' +
  'Issue Explore specialist review passes behind a single reviewer lane #202: Explore specialist review passes behind a single reviewer lane\n' +
  'Issue URL: https://github.com/davidruzicka/mcp4openapi/issues/202\n' +
  'Issue labels: enhancement, agent:safe, architecture, agent-support, agent:planned\n' +
  '\n' +
  'Issue body:\n' +
  '## Summary\n' +
  'Evaluate whether the code review stage should stay externally single-lane (reviewer) while internally supporting specialized review passes (for example security, performance, API/contract, and test adequacy).\n' +
  '\n' +
  '## Motivation\n' +
  'Current workflow design treats review as a single reviewer lane. That keeps the state machine simple, but a single generic review prompt may not cover the full space of review concerns well enough across code quality, security, performance, compatibility, and test quality.\n' +
  '\n' +
  'Recent discussion and current research direction suggest a useful hybrid shape:\n' +
  '- keep one public reviewer lane for deterministic workflow semantics,\n' +
  '- optionally run specialized internal review passes when repo/risk signals justify them,\n' +
  '- aggregate findings into one normalized review artifact/comment instead of producing multiple noisy public reviewer personas.\n' +
  '\n' +
  '## Why this might help\n' +
  '- Better coverage for heterogeneous review tasks.\n' +
  '- Preserve current external workflow semantics (reviewer + merger).\n' +
  '- Reduce noise compared with multiple public reviewer agents commenting independently.\n' +
  '- Allow selective, risk-triggered review depth instead of paying full cost on every PR.\n' +
  '\n' +
  '## Candidate design direction\n' +
  '### External contract\n' +
  '- Keep one public reviewer lane.\n' +
  '- Keep one merge decision path through merger.\n' +
  '\n' +
  '### Internal review passes\n' +
  '- reviewer-general\n' +
  '- reviewer-security\n' +
  '- reviewer-performance\n' +
  '- reviewer-api\n' +
  '- reviewer-tests\n' +
  '\n' +
  '### Triggering\n' +
  'Only run specialist passes when justified, for example:\n' +
  '- security-sensitive files / auth / crypto / shell / file / deserialization paths,\n' +
  '- hot paths or likely performance-sensitive changes,\n' +
  '- schema / API / contract changes,\n' +
  '- large test deltas or suspiciously low test impact.\n' +
  '\n' +
  '### Output shape\n' +
  'Aggregate all findings into a normalized machine-readable artifact with fields like:\n' +
  '- category\n' +
  '- severity\n' +
  '- confidence\n' +
  '- evidence\n' +
  '- blocking\n' +
  '- head_sha\n' +
  '- source_pass\n' +
  '\n' +
  '### Guardrails\n' +
  '- avoid duplicate findings across passes,\n' +
  '- keep fail-closed merge semantics explicit,\n' +
  '- do not let multiple reviewer personas create contradictory public state,\n' +
  '- prefer specialist passes + tooling/analyzers over multiple nearly-identical free-text prompts.\n' +
  '\n' +
  '## Open questions\n' +
  '- Which specialist passes are worth the runtime/cost overhead first?\n' +
  '- Should specialist findings be blocking by default or only after confidence/severity thresholds?\n' +
  '- How should the planner/implementor handoff represent specialist findings?\n' +
  '- Which findings should remain advisory vs merge-blocking?\n' +
  '\n' +
  '## Relationship to current work\n' +
  '- Related to Tracking: Close PR review/fix loop #184 (close PR review/fix loop)\n' +
  '- Related to Define merge blocking policy for unresolved review threads #180 (merge blocking policy)\n' +
  '- Could become a later-phase hardening/design issue after the current phase-1 review loop is stable.\n' +
  '\n' +
  'Agent note: this issue body was drafted by an agent from a research-backed design discussion.\n' +
  '\n' +
  'Required final output:\n' +
  '- Write exactly one JSON object to /tmp/mcp4openapi-implementor-codex-dUzGLn/result.json\n' +
  '- The JSON must match this schema:\n' +
  '{\n' +
  ' "outcome": "pr-created" | "failed" | "blocked",\n' +
  ' "summary": "short human-readable summary",\n' +
  ' "pullRequest": { "number": 123, "url": "https://github.com/owner/repo/pull/123" }\n' +
  '}\n' +
  '- Include pullRequest only when outcome is "pr-created".\n' +
  '- Do not wrap the JSON in markdown.\n' +
  '- Ensure the file contents are valid JSON before exiting.',
  stdout: '',
  stderr: 'OpenAI Codex v0.116.0 (research preview)\n' +
  '--------\n' +
  'workdir: /home/runner/work/mcp4openapi/mcp4openapi\n' +
  'model: gpt-5.3-codex\n' +
  'provider: openai\n' +
  'approval: never\n' +
  'sandbox: workspace-write [workdir, /tmp, $TMPDIR, /home/runner/.codex/memories]\n' +
  'reasoning effort: none\n' +
  'reasoning summaries: none\n' +
  'session id: 019d142b-bba7-7d91-a709-5c103e72046e\n' +
  '--------\n' +
  'user\n' +
  'You are the Codex implementor backend for the mcp4openapi autonomous issue pipeline.\n' +
  'Work only inside the current git repository/worktree and keep the change narrowly scoped to the issue below.\n' +
  'Use senior-level code quality: modular design, clean code, explicit boundaries, data-oriented logic where reasonable, no duplication, and safe defaults.\n' +
  'Use strict TDD: add or update tests first, confirm the relevant tests fail, implement the minimal change, then rerun targeted tests and typecheck.\n' +
  'Run targeted tests and typecheck before creating the PR.\n' +
  'Use English for code comments, commit messages, PR title/body, and notes.\n' +
  'Create a dedicated branch if needed, commit with a Conventional Commits message, push it, and open a PR linked to the issue.\n' +
  'The PR description must clearly disclose automation with this exact sentence: "This PR was created by an automated agent."\n' +
  'The PR body should also mention the agent role, source issue number, workflow run ID, testing performed, and any assumptions or limits.\n' +
  'If you cannot complete the task safely, do not open a PR. Return outcome "blocked" for policy/scope blockers or "failed" for implementation/tooling failures.\n' +
  '\n' +
  'Repository: davidruzicka/mcp4openapi\n' +
  'Agent ID: implementor\n' +
  'Workflow run ID: github-actions-23397114201\n' +
  'Timestamp: 2026-03-22T06:11:40.905Z\n' +
  'Issue Explore specialist review passes behind a single reviewer lane #202: Explore specialist review passes behind a single reviewer lane\n' +
  'Issue URL: https://github.com/davidruzicka/mcp4openapi/issues/202\n' +
  'Issue labels: enhancement, agent:safe, architecture, agent-support, agent:planned\n' +
  '\n' +
  'Issue body:\n' +
  '## Summary\n' +
  'Evaluate whether the code review stage should stay externally single-lane (reviewer) while internally supporting specialized review passes (for example security, performance, API/contract, and test adequacy).\n' +
  '\n' +
  '## Motivation\n' +
  'Current workflow design treats review as a single reviewer lane. That keeps the state machine simple, but a single generic review prompt may not cover the full space of review concerns well enough across code quality, security, performance, compatibility, and test quality.\n' +
  '\n' +
  'Recent discussion and current research direction suggest a useful hybrid shape:\n' +
  '- keep one public reviewer lane for deterministic workflow semantics,\n' +
  '- optionally run specialized internal review passes when repo/risk signals justify them,\n' +
  '- aggregate findings into one normalized review artifact/comment instead of producing multiple noisy public reviewer personas.\n' +
  '\n' +
  '## Why this might help\n' +
  '- Better coverage for heterogeneous review tasks.\n' +
  '- Preserve current external workflow semantics (reviewer + merger).\n' +
  '- Reduce noise compared with multiple public reviewer agents commenting independently.\n' +
  '- Allow selective, risk-triggered review depth instead of paying full cost on every PR.\n' +
  '\n' +
  '## Candidate design direction\n' +
  '### External contract\n' +
  '- Keep one public reviewer lane.\n' +
  '- Keep one merge decision path through merger.\n' +
  '\n' +
  '### Internal review passes\n' +
  '- reviewer-general\n' +
  '- reviewer-security\n' +
  '- reviewer-performance\n' +
  '- reviewer-api\n' +
  '- reviewer-tests\n' +
  '\n' +
  '### Triggering\n' +
  'Only run specialist passes when justified, for example:\n' +
  '- security-sensitive files / auth / crypto / shell / file / deserialization paths,\n' +
  '- hot paths or likely performance-sensitive changes,\n' +
  '- schema / API / contract changes,\n' +
  '- large test deltas or suspiciously low test impact.\n' +
  '\n' +
  '### Output shape\n' +
  'Aggregate all findings into a normalized machine-readable artifact with fields like:\n' +
  '- category\n' +
  '- severity\n' +
  '- confidence\n' +
  '- evidence\n' +
  '- blocking\n' +
  '- head_sha\n' +
  '- source_pass\n' +
  '\n' +
  '### Guardrails\n' +
  '- avoid duplicate findings across passes,\n' +
  '- keep fail-closed merge semantics explicit,\n' +
  '- do not let multiple reviewer personas create contradictory public state,\n' +
  '- prefer specialist passes + tooling/analyzers over multiple nearly-identical free-text prompts.\n' +
  '\n' +
  '## Open questions\n' +
  '- Which specialist passes are worth the runtime/cost overhead first?\n' +
  '- Should specialist findings be blocking by default or only after confidence/severity thresholds?\n' +
  '- How should the planner/implementor handoff represent specialist findings?\n' +
  '- Which findings should remain advisory vs merge-blocking?\n' +
  '\n' +
  '## Relationship to current work\n' +
  '- Related to Tracking: Close PR review/fix loop #184 (close PR review/fix loop)\n' +
  '- Related to Define merge blocking policy for unresolved review threads #180 (merge blocking policy)\n' +
  '- Could become a later-phase hardening/design issue after the current phase-1 review loop is stable.\n' +
  '\n' +
  'Agent note: this issue body was drafted by an agent from a research-backed design discussion.\n' +
  '\n' +
  'Required final output:\n' +
  '- Write exactly one JSON object to /tmp/mcp4openapi-implementor-codex-dUzGLn/result.json\n' +
  '- The JSON must match this schema:\n' +
  '{\n' +
  ' "outcome": "pr-created" | "failed" | "blocked",\n' +
  ' "summary": "short human-readable summary",\n' +
  ' "pullRequest": { "number": 123, "url": "https://github.com/owner/repo/pull/123" }\n' +
  '}\n' +
  '- Include pullRequest only when outcome is "pr-created".\n' +
  '- Do not wrap the JSON in markdown.\n' +
  '- Ensure the file contents are valid JSON before exiting.\n' +
  'warning: Codex could not find system bubblewrap at /usr/bin/bwrap. Please install bubblewrap with your package manager. Codex will use the vendored bubblewrap in the meantime.\n' +
  'mcp startup: no servers\n' +
  '2026-03-22T06:11:43.950205Z ERROR codex_api::endpoint::responses_websocket: failed to connect to websocket: HTTP error: 500 Internal Server Error, url: wss://api.openai.com/v1/responses\n' +
  '2026-03-22T06:11:44.232820Z ERROR codex_api::endpoint::responses_websocket: failed to connect to websocket: HTTP error: 500 Internal Server Error, url: wss://api.openai.com/v1/responses\n' +
  '2026-03-22T06:11:44.677093Z ERROR codex_api::endpoint::responses_websocket: failed to connect to websocket: HTTP error: 500 Internal Server Error, url: wss://api.openai.com/v1/responses\n' +
  "Reconnecting... 2/5 (We're currently experiencing high demand, which may cause temporary errors.)\n" +
  '2026-03-22T06:11:45.345094Z ERROR codex_api::endpoint::responses_websocket: failed to connect to websocket: HTTP error: 500 Internal Server Error, url: wss://api.openai.com/v1/responses\n' +
  "Reconnecting... 3/5 (We're currently experiencing high demand, which may cause temporary errors.)\n" +
  '2026-03-22T06:11:46.439882Z ERROR codex_api::endpoint::responses_websocket: failed to connect to websocket: HTTP error: 500 Internal Server Error, url: wss://api.openai.com/v1/responses\n' +
  "Reconnecting... 4/5 (We're currently experiencing high demand, which may cause temporary errors.)\n" +
  '2026-03-22T06:11:48.311544Z ERROR codex_api::endpoint::responses_websocket: failed to connect to websocket: HTTP error: 500 Internal Server Error, url: wss://api.openai.com/v1/responses\n' +
  "Reconnecting... 5/5 (We're currently experiencing high demand, which may cause temporary errors.)\n" +
  '2026-03-22T06:11:51.808238Z ERROR codex_api::endpoint::responses_websocket: failed to connect to websocket: HTTP error: 500 Internal Server Error, url: wss://api.openai.com/v1/responses\n' +
  "warning: Falling back from WebSockets to HTTPS transport. We're currently experiencing high demand, which may cause temporary errors.\n" +
  'Reconnecting... 1/5 (unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses, cf-ray: 9e030a991b6be5f9-IAD, request id: req_f54570939118446997c3ba434f96adcd)\n' +
  'Reconnecting... 2/5 (unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses, cf-ray: 9e030a9b4c107fa2-IAD, request id: req_16d5f611c7854beaa15dc63acd2dc1b9)\n' +
  'Reconnecting... 3/5 (unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses, cf-ray: 9e030a9eb9b0dab8-IAD, request id: req_a25d85ce73d84ec9a695ce29fbfb7878)\n' +
  'Reconnecting... 4/5 (unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses, cf-ray: 9e030aa468e22d85-IAD, request id: req_79496814620e4e2c8815fa979e6bd9d8)\n' +
  'Reconnecting... 5/5 (unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses, cf-ray: 9e030aaf9ece593d-IAD, request id: req_11fe97e57fe343ef9e5f08a3ac390fe1)\n' +
  'ERROR: unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses, cf-ray: 9e030ac3d9e2e5f9-IAD, request id: req_e7de71fe77574fb7a0836fd2123743da\n'
  }

Node.js v20.20.1

[github-actions]

🤖 Agent note (proposal-intake)

Resolution: create-fresh
Reason: no relevant existing issue or pull request matches this proposal
Linked issue: #208 (#208)