feat(o1): implement reviewer feedback rebuttal and re-adjudication protocol (100% PASS)

This commit is contained in:
2026-08-06 09:21:28 +09:00
parent 2d5e20a6aa
commit cdeb9e2c8f
7 changed files with 550 additions and 22 deletions
+20 -1
View File
@@ -23,12 +23,13 @@
- 총괄 매니저로부터 작업을 위임받습니다.
- **작업 분석 및 계획**: 주어진 작업을 철저히 분석하고, 작은 단위로 문제를 나누어 세부 계획을 수립합니다.
- **내부 병렬 처리**: 내부적으로 subagent를 활용해 위임받은 작업을 병렬적으로 처리할 수 있습니다.
- **리뷰 타당성 검증 및 거부**: 리뷰어가 지적한 피드백을 면밀히 검토합니다. 타당한 제안은 수렴하여 코드를 수정하지만, 타당하지 않다고 판단되는 안건은 반영하지 않고 **그 명확한 이유를 작성하여 리뷰어에게 되돌려 보냅니다**.
- **리뷰 타당성 검증 및 거부**: 리뷰어가 지적한 피드백을 면밀히 검토합니다. 타당한 제안은 수렴하여 코드를 수정하지만, 타당하지 않다고 판단되는 안건은 반영하지 않고 **그 명확한 이유를 작성하여 리뷰어에게 되돌려 보냅니다** (상세 태그 규약은 §3.1 '[REBUT:]' 참조).
- **완료 신호 송신**: 모든 리뷰어들로부터 `PASS`를 획득하고 변경 사항이 검증되면, 최초 작업을 위임받았던 개발 팀장이 총괄 매니저에게 최종 작업 완료 신호를 송신합니다.
- **Reviewer Team Leader (리뷰어 팀장)**:
- 개발 팀장으로부터 리뷰 요청을 접수합니다.
- **문제 제시에 대한 이유와 개선 방향 포함**: 단순한 반려(`NOT PASS`) 통보는 금지됩니다. 이슈를 제기할 때는 **반드시 해당 문제가 발생하는 구체적인 이유와 확실한 개선 방향(코드 대안 포함)을 함께 작성**해야 합니다.
- **합의 루프**: 모든 지적 사항이 해결되고 최종 `PASS`를 발행할 때까지 리뷰 루프에 동참합니다.
- **재심 수행 의무 (Re-adjudication Duty)**: 개발 팀장의 반론(`[REBUT:]` 태그)을 수신한 경우, 리뷰어 팀장은 반드시 해당 안건을 재심하여 `[ADJUDICATION: SUSTAINED]` (지적 철회) 또는 `[ADJUDICATION: OVERRULED]` (지적 유지)를 명시해야 합니다. 수신된 반론을 무시하거나 재심을 우회하는 것은 금지됩니다.
### 🛡️ 역할 범위 준수 원칙 (Role Suitability Check)
- 모든 에이전트는 자신에게 부여된 역할에 부합하는 작업만을 수행해야 합니다. (예: 개발 팀장은 최종 PASS 여부를 결정하지 않으며, 리뷰어 팀장은 직접 프로젝트 소스코드를 작성하지 않습니다.)
@@ -106,6 +107,24 @@ sequenceDiagram
- 리뷰어 전원이 `PASS`를 인가할 때까지 이 과정이 반복됩니다.
4. **최종 보고**: 개발 팀장이 총괄 매니저에게 완료 신호를 보내면 총괄 매니저가 사용자에게 완료를 알립니다.
### 3.1 Rebuttal & Adjudication Protocol (이의제기 및 재심 프로토콜)
개발 팀장이 리뷰어의 피드백이 타당하지 않거나 부적절하다고 판단하는 경우, 묵인하거나 수용하지 않고 정식 반론(Rebuttal)을 제기해야 합니다.
| 태그 | 발행 주체 | 의미 |
|---|---|---|
| `[REBUT: <리뷰어_세션명>]` | 개발자 | 지정된 리뷰어의 피드백을 공식 거부. 리포트에 상세 근거 서술 필수. 타당한 지적은 정상 반영. |
| `[ADJUDICATION: SUSTAINED]` | 리뷰어 | 개발자의 반론을 수용하여 이전 지적 사항을 철회함. |
| `[ADJUDICATION: OVERRULED]` | Reviewer | 개발자의 반론을 기각하고 이전 지적 사항을 유지함. |
| `[ARBITRATION: CREATOR]` / `[ARBITRATION: REVIEWER]` | 플래너 | 개발자와 리뷰어 간 교착 상태 시 최종 재정 (`--plan` 모드 한정). |
**프로토콜 불변 규칙**:
1. **반론은 PASS를 대체하지 않음**: 수용된 반론(`SUSTAINED`)은 해당 지적 사항만 철회시킵니다. 리뷰 루프가 완수되려면 여전히 모든 리뷰어로부터 만장일치 `[VERDICT: PASS]`를 획득해야 합니다.
2. **Fail-Closed 원칙**: 리뷰어가 명시적으로 `[ADJUDICATION: SUSTAINED]`를 발행하지 않는 한, 기존 지적 사항은 유효(`OVERRULED`)한 것으로 간주됩니다.
3. **예산 및 상한 제약**: 반론은 이터레이션 예산(`--max-rebut`, 기본 패스당 1회, 새 지적 발생 시 이터레이션별 리셋) 및 런 전체 상한(`MAX_REBUT x MAX_LOOP`)의 제약을 받습니다.
4. **교착 상태 에스컬레이션**: 리뷰어가 `OVERRULED`를 고수하고 플래너 모드(`--plan`)가 활성화된 경우 플래너가 재정합니다. 플래너가 없으면 리뷰어의 지적이 우선 반영됩니다(`Fail-Closed`).
5. **세션 매칭 및 중복 제거**: 반론 태그는 실제로 지적을 제기한 리뷰어 세션명을 지정해야 합니다. 단일 리포트 내 동일 리뷰어 대상 중복 태그는 단 1회의 재심 라운드로 병합됩니다.
---
## 4. 분석 인프라 패턴 & 실무 가이드 (Infra Patterns)