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

.agents/MULTI_AGENT_RULES.md

@@ -23,18 +23,19 @@ Newly spawned agents (e.g., `antigravity`, `claude`, `cline`, `hermes`) act as *
   - Receives tasks from the General Manager.
   - **Task Breakdown & Planning**: Thoroughly analyzes the task, breaks it down into small units, and creates a plan.
   - **Internal Parallelism**: Can run subagents in parallel internally to handle the delegated work.
-  - **Review Integrity & Refusal**: Thoroughly reviews feedback from Reviewers. Adopts/implements recommendations if valid. If any recommendation is judged invalid, the Developer Team Leader must **not** implement it, but instead return the refutation along with detailed reasons to the Reviewer.
+  - **Review Integrity & Refusal**: Thoroughly reviews feedback from Reviewers. Adopts/implements recommendations if valid. If any recommendation is judged invalid, the Developer Team Leader must **not** implement it, but instead return the refutation along with detailed reasons to the Reviewer (see §3.1 for the '[REBUT:]' protocol).
   - **Completion Signal**: Once all reviewers yield a `PASS` and changes are verified, the Developer Team Leader who first received the task sends a completion signal back to the General Manager.
 - **Reviewer Team Leader (리뷰어 팀장)**:
   - Receives review requests from the Developer Team Leader.
   - **Detailed Feedback with Directions**: Simply rejecting changes (`NOT PASS`) is forbidden. Reviewers **must** specify the exact reason for the issue and provide a concrete, stable, and verified alternative direction for improvement.
   - **Consensus Loop**: Engages in the review cycle until all objections are resolved and a final `PASS` is issued.
+  - **Re-adjudication Duty**: Upon receiving a rebuttal with '[REBUT:]' tag, the Reviewer Team Leader must re-examine the objection and explicitly issue '[ADJUDICATION: SUSTAINED]' (withdraw objection) or '[ADJUDICATION: OVERRULED]' (maintain objection). Ignoring or bypassing a received rebuttal is forbidden.
 
 ### 🛡️ Role Suitability Check Principle (자신의 역할 범위 수행 원칙)
 - Every agent must only perform tasks suitable for its designated role (e.g., Developer Team Leaders do not issue final reviews, and Reviewer Team Leaders do not write project code).
 - **If an agent receives a task that does not fit its role**, it must either:
-  1. Recommend the optimal agent session to delegate the task to, or
-  2. Perform the task directly if strictly necessary for project continuity.
+  1. Defer or re-delegate the task to a suitable subagent/session, OR
+  2. Reject the task explicitly by explaining the role mismatch.
 
 ---
 
@@ -106,6 +107,24 @@ sequenceDiagram
    - This cycle repeats until all reviewers issue a `PASS`.
 4. **Completion and Report**: The Developer Team Leader sends the final completion signal to the General Manager, who notifies the user.
 
+### 3.1 Rebuttal & Adjudication Protocol (이의제기 및 재심 프로토콜)
+
+When a Developer Team Leader judges that a Reviewer's feedback is invalid or inappropriate, it must file a formal rebuttal rather than silently accepting or ignoring it.
+
+| Tag | Issuer | Meaning |
+|---|---|---|
+| `[REBUT: <reviewer_session>]` | Developer | Formally rejects feedback from specified reviewer. Must provide detailed reasoning in report body. Valid suggestions must still be implemented. |
+| `[ADJUDICATION: SUSTAINED]` | Reviewer | Accepts developer's refutation and withdraws previous objection. |
+| `[ADJUDICATION: OVERRULED]` | Reviewer | Rejects developer's refutation and maintains objection. |
+| `[ARBITRATION: CREATOR]` / `[ARBITRATION: REVIEWER]` | Planner | Final ruling in case of deadlock between Developer and Reviewer (`--plan` mode). |
+
+**Protocol Rules**:
+1. **Rebuttal does NOT substitute for a PASS**: A sustained rebuttal only withdraws the specified objection. The review loop will still require a unanimous `[VERDICT: PASS]` from all active reviewers to complete successfully.
+2. **Fail-Closed Principle**: Unless a Reviewer explicitly issues `[ADJUDICATION: SUSTAINED]`, the objection stands by default.
+3. **Budget & Bound Constraints**: Rebuttals are bounded by an iteration budget (`--max-rebut`, default 1 per iteration, resets each pass for new findings) and a total run budget (`MAX_REBUT x MAX_LOOP`).
+4. **Deadlock Escalation**: If a Reviewer issues `[ADJUDICATION: OVERRULED]` and Planner is enabled (`--plan`), Planner arbitrates. If Planner is absent, the Reviewer's objection prevails (`Fail-Closed`).
+5. **Session Matching & Deduplication**: Rebuttals must target valid objecting reviewer session names. Duplicate tags targeting the same reviewer in a single report are merged into a single re-adjudication round.
+
 ---
 
 ## 4. Analysis Infrastructure Patterns & Practical Guide (Infra Patterns)