@su-record/vibe 2.9.4 → 2.9.5

package/agents/teams/refactor-team.md

@@ -1,94 +1,94 @@
-# Refactor Team
-
-안전한 멀티파일 리팩터링을 위한 팀. Characterization test로 현재 동작을 잠그고 변경 후 회귀를 검증한다.
-
-## 팀 구성
-
-| 팀원 | 역할 | Model |
-|------|------|-------|
-| architect (리더) | 리팩터링 범위 설정, 단계별 계획, 리스크 평가 | Opus |
-| refactor-cleaner | 데드코드 탐지, 미사용 export/파일/의존성 분석 | Sonnet |
-| implementer | architect 계획에 따라 리팩터링 실행 (파일 단위) | Sonnet |
-| tester | Characterization test 작성 + 회귀 테스트 실행 | Haiku |
-
-## 활성화 조건
-
-- `/vibe.run refactor` 수동 트리거
-- complexity-reviewer가 동일 모듈에서 P2 이슈 5개 이상 발견 시 제안
-
-## 워크플로우
-
-```
-architect: 대상 모듈 분석, 리팩터링 범위 + 리스크 평가
-    |
-refactor-cleaner: knip/depcheck/ts-prune → 데드코드 스캔 결과
-    |
-tester: characterization test 작성 (현재 동작 잠금, 변경 전)
-    |
-architect: 스캔 결과 + 테스트 커버리지 검토 → 단계별 리팩터링 계획
-    |
-implementer: 파일 단위 리팩터링 실행
-    │   각 파일마다:
-    │   ├──→ tester: characterization test 실행
-    │   │       ├─ PASS → 다음 파일
-    │   │       └─ FAIL → implementer 롤백 → architect 재계획
-    |
-architect: 최종 검증, before/after 메트릭 비교, 요약 작성
-```
-
-## spawn 패턴
-
-```text
-TeamCreate(team_name="refactor-{module}", description="Safe refactoring team for {module}")
-
-Task(team_name="refactor-{module}", name="architect", subagent_type="architect",
-  prompt="리팩터링 팀 리더. 대상 모듈을 분석하고 안전한 리팩터링 계획을 수립하세요.
-  대상: {target_path}
-  목표: {refactor_goal}
-  역할: 범위 설정, 리스크 평가, 단계별 계획. refactor-cleaner에게 스캔을 요청하세요.
-  tester가 characterization test를 작성할 때까지 구현을 시작하지 마세요.
-  각 단계 후 tester 결과를 확인하고 다음 단계를 승인하세요.")
-
-Task(team_name="refactor-{module}", name="refactor-cleaner", subagent_type="refactor-cleaner",
-  prompt="리팩터링 팀 분석 담당. 대상: {target_path}
-  역할: knip/depcheck/ts-prune으로 데드코드, 미사용 export, 불필요 의존성 탐지.
-  스캔 결과를 architect에게 SendMessage로 전달하세요.
-  DELETION_LOG.md에 삭제 대상을 기록하세요.")
-
-Task(team_name="refactor-{module}", name="implementer", subagent_type="implementer",
-  mode="bypassPermissions",
-  prompt="리팩터링 팀 구현 담당. 대상: {target_path}
-  역할: architect의 계획에 따라 파일 단위로 리팩터링 실행.
-  각 파일 수정 후 tester에게 SendMessage로 테스트 요청하세요.
-  테스트 실패 시 즉시 롤백하고 architect에게 알리세요.")
-
-Task(team_name="refactor-{module}", name="tester", subagent_type="tester",
-  mode="bypassPermissions",
-  prompt="리팩터링 팀 테스트 담당. 대상: {target_path}
-  역할: 1) 리팩터링 전 characterization test 작성 (현재 동작 잠금).
-  2) 각 파일 수정 후 회귀 테스트 실행.
-  실패 시 implementer에게 SendMessage로 즉시 알리세요.
-  architect에게 테스트 커버리지 현황을 보고하세요.")
-```
-
-## 팀원 간 통신
-
-```text
-architect → refactor-cleaner: "src/services/ 모듈 스캔 요청. 미사용 export와 데드코드를 찾아주세요"
-refactor-cleaner → architect: "미사용 export 12개, 데드파일 3개, 미사용 의존성 2개 발견"
-architect → tester: "src/services/auth.ts의 현재 동작을 characterization test로 잠그세요"
-tester → architect: "auth.ts 커버리지 94%. 리팩터링 진행 가능합니다"
-architect → implementer: "Step 1: auth.ts에서 미사용 export 4개 제거. 계획 참조하세요"
-implementer → tester: "auth.ts 수정 완료. 회귀 테스트 요청합니다"
-tester → implementer: "1건 실패: validateToken() 시그니처 변경으로 호출부 깨짐"
-implementer → architect: "호출부 수정 필요. 영향 범위: 3파일"
-architect → broadcast: "리팩터링 완료. 복잡도 42→28, 데드코드 15개 제거, 테스트 전체 통과"
-```
-
-## ⛔ 하지 않는 것
-
-- characterization test 없이 리팩터링 시작
-- 테스트 실패 상태에서 다음 파일 진행
-- architect 승인 없이 범위 확대
-- 기능 추가/변경 (구조 개선만)
-- refactor-cleaner가 코드 수정 (탐지/리포트만)
+# Refactor Team
+
+안전한 멀티파일 리팩터링을 위한 팀. Characterization test로 현재 동작을 잠그고 변경 후 회귀를 검증한다.
+
+## 팀 구성
+
+| 팀원 | 역할 | Model |
+|------|------|-------|
+| architect (리더) | 리팩터링 범위 설정, 단계별 계획, 리스크 평가 | Opus |
+| refactor-cleaner | 데드코드 탐지, 미사용 export/파일/의존성 분석 | Sonnet |
+| implementer | architect 계획에 따라 리팩터링 실행 (파일 단위) | Sonnet |
+| tester | Characterization test 작성 + 회귀 테스트 실행 | Haiku |
+
+## 활성화 조건
+
+- `/vibe.run refactor` 수동 트리거
+- complexity-reviewer가 동일 모듈에서 P2 이슈 5개 이상 발견 시 제안
+
+## 워크플로우
+
+```
+architect: 대상 모듈 분석, 리팩터링 범위 + 리스크 평가
+    |
+refactor-cleaner: knip/depcheck/ts-prune → 데드코드 스캔 결과
+    |
+tester: characterization test 작성 (현재 동작 잠금, 변경 전)
+    |
+architect: 스캔 결과 + 테스트 커버리지 검토 → 단계별 리팩터링 계획
+    |
+implementer: 파일 단위 리팩터링 실행
+    │   각 파일마다:
+    │   ├──→ tester: characterization test 실행
+    │   │       ├─ PASS → 다음 파일
+    │   │       └─ FAIL → implementer 롤백 → architect 재계획
+    |
+architect: 최종 검증, before/after 메트릭 비교, 요약 작성
+```
+
+## spawn 패턴
+
+```text
+TeamCreate(team_name="refactor-{module}", description="Safe refactoring team for {module}")
+
+Task(team_name="refactor-{module}", name="architect", subagent_type="architect",
+  prompt="리팩터링 팀 리더. 대상 모듈을 분석하고 안전한 리팩터링 계획을 수립하세요.
+  대상: {target_path}
+  목표: {refactor_goal}
+  역할: 범위 설정, 리스크 평가, 단계별 계획. refactor-cleaner에게 스캔을 요청하세요.
+  tester가 characterization test를 작성할 때까지 구현을 시작하지 마세요.
+  각 단계 후 tester 결과를 확인하고 다음 단계를 승인하세요.")
+
+Task(team_name="refactor-{module}", name="refactor-cleaner", subagent_type="refactor-cleaner",
+  prompt="리팩터링 팀 분석 담당. 대상: {target_path}
+  역할: knip/depcheck/ts-prune으로 데드코드, 미사용 export, 불필요 의존성 탐지.
+  스캔 결과를 architect에게 SendMessage로 전달하세요.
+  DELETION_LOG.md에 삭제 대상을 기록하세요.")
+
+Task(team_name="refactor-{module}", name="implementer", subagent_type="implementer",
+  mode="bypassPermissions",
+  prompt="리팩터링 팀 구현 담당. 대상: {target_path}
+  역할: architect의 계획에 따라 파일 단위로 리팩터링 실행.
+  각 파일 수정 후 tester에게 SendMessage로 테스트 요청하세요.
+  테스트 실패 시 즉시 롤백하고 architect에게 알리세요.")
+
+Task(team_name="refactor-{module}", name="tester", subagent_type="tester",
+  mode="bypassPermissions",
+  prompt="리팩터링 팀 테스트 담당. 대상: {target_path}
+  역할: 1) 리팩터링 전 characterization test 작성 (현재 동작 잠금).
+  2) 각 파일 수정 후 회귀 테스트 실행.
+  실패 시 implementer에게 SendMessage로 즉시 알리세요.
+  architect에게 테스트 커버리지 현황을 보고하세요.")
+```
+
+## 팀원 간 통신
+
+```text
+architect → refactor-cleaner: "src/services/ 모듈 스캔 요청. 미사용 export와 데드코드를 찾아주세요"
+refactor-cleaner → architect: "미사용 export 12개, 데드파일 3개, 미사용 의존성 2개 발견"
+architect → tester: "src/services/auth.ts의 현재 동작을 characterization test로 잠그세요"
+tester → architect: "auth.ts 커버리지 94%. 리팩터링 진행 가능합니다"
+architect → implementer: "Step 1: auth.ts에서 미사용 export 4개 제거. 계획 참조하세요"
+implementer → tester: "auth.ts 수정 완료. 회귀 테스트 요청합니다"
+tester → implementer: "1건 실패: validateToken() 시그니처 변경으로 호출부 깨짐"
+implementer → architect: "호출부 수정 필요. 영향 범위: 3파일"
+architect → broadcast: "리팩터링 완료. 복잡도 42→28, 데드코드 15개 제거, 테스트 전체 통과"
+```
+
+## ⛔ 하지 않는 것
+
+- characterization test 없이 리팩터링 시작
+- 테스트 실패 상태에서 다음 파일 진행
+- architect 승인 없이 범위 확대
+- 기능 추가/변경 (구조 개선만)
+- refactor-cleaner가 코드 수정 (탐지/리포트만)

package/agents/teams/research-team.md

@@ -1,86 +1,86 @@
-# Research Team
-
-리서치 결과를 팀으로 교차 검증하여 정확성과 호환성을 보장하는 리서치 협업 팀.
-
-## 팀 구성
-
-| 팀원 | 역할 | Model |
-|------|------|-------|
-| best-practices (리더) | 패턴/안티패턴 종합, 팀원 간 충돌 해결, 최종 통합 요약 작성 | Haiku |
-| security-advisory | 보안 관점에서 모든 권장사항 검증 | Haiku |
-| codebase-patterns | 권장사항이 기존 코드 패턴과 호환되는지 검증 | Haiku |
-| framework-docs | 최신 API/문서와 권장사항 대조 검증 | Haiku |
-
-## 활성화 조건
-
-- `/vibe.spec` Step 3 리서치 단계에서 자동 활성화
-- Agent Teams 환경변수 활성화 상태
-
-## 워크플로우
-
-```
-[입력: 10개 병렬 리서치 결과]
-    |
-    ├──→ best-practices: 패턴 종합 + 합의 주도
-    ├──→ security-advisory: 보안 리스크 검증
-    ├──→ codebase-patterns: 기존 코드 호환성 검증
-    └──→ framework-docs: 최신 API 대조 검증
-         |
-    [SendMessage 교차 검증]
-         |
-    best-practices: 최종 통합 요약 → SPEC Context 반영
-```
-
-## spawn 패턴
-
-```text
-TeamCreate(team_name="research-{feature}", description="Research collaboration for {feature}")
-
-Task(team_name="research-{feature}", name="best-practices", subagent_type="best-practices-agent",
-  prompt="리서치 팀 리더. 10개 병렬 리서치 결과를 종합하세요.
-  리서치 결과: {all_research_results}
-  역할: 패턴/안티패턴 종합, 팀원 간 충돌 해결, 최종 통합 요약 작성.
-  TaskList를 확인하고 작업을 claim하세요. 팀원에게 SendMessage로 검증을 요청하세요.
-  모든 작업 완료 후 최종 요약을 작성하세요.")
-
-Task(team_name="research-{feature}", name="security-advisory", subagent_type="security-advisory-agent",
-  prompt="리서치 팀 보안 담당. 리서치 결과: {all_research_results}
-  역할: 보안 관점에서 모든 권장사항 검증.
-  보안 리스크 발견 시 best-practices에게 SendMessage로 알리세요.
-  TaskList에서 보안 관련 작업을 claim하세요.")
-
-Task(team_name="research-{feature}", name="codebase-patterns", subagent_type="codebase-patterns-agent",
-  prompt="리서치 팀 코드베이스 담당. 리서치 결과: {all_research_results}
-  역할: 권장사항이 기존 코드 패턴과 호환되는지 검증.
-  비호환 발견 시 best-practices에게 SendMessage로 알리세요.
-  TaskList에서 호환성 관련 작업을 claim하세요.")
-
-Task(team_name="research-{feature}", name="framework-docs", subagent_type="framework-docs-agent",
-  prompt="리서치 팀 문서 담당. 리서치 결과: {all_research_results}
-  역할: 최신 API/문서와 권장사항 대조 검증.
-  폐기/변경된 API 발견 시 best-practices에게 SendMessage로 알리세요.
-  TaskList에서 문서 검증 관련 작업을 claim하세요.")
-```
-
-## Result Merge Rules
-
-| Area | Merge Strategy |
-|------|----------------|
-| Best Practices | Deduplicate, keep most detailed |
-| Security | ALL included (no dedup for safety) |
-| Libraries | Consensus recommendations |
-
-## 팀원 간 통신
-
-```text
-security-advisory → best-practices: "JWT 라이브러리 권장사항에 CVE-2024-xxxx 취약점. 대안 필요"
-codebase-patterns → best-practices: "기존 코드가 class 패턴인데 함수형 권장은 비호환. 점진적 마이그레이션 제안"
-framework-docs → best-practices: "React 19에서 useEffect 패턴 변경됨. 리서치 결과의 패턴은 구버전"
-best-practices → broadcast: "최종 합의: JWT는 jose 라이브러리로 교체, 함수형 전환은 신규 파일만 적용"
-```
-
-## ⛔ 하지 않는 것
-
-- 코드 작성/수정 (리서치 결과만 텍스트로 반환)
-- 파일 생성 (SPEC에 반영은 메인 에이전트가 담당)
-- 보안 이슈 중복 제거 (안전을 위해 ALL 포함)
+# Research Team
+
+리서치 결과를 팀으로 교차 검증하여 정확성과 호환성을 보장하는 리서치 협업 팀.
+
+## 팀 구성
+
+| 팀원 | 역할 | Model |
+|------|------|-------|
+| best-practices (리더) | 패턴/안티패턴 종합, 팀원 간 충돌 해결, 최종 통합 요약 작성 | Haiku |
+| security-advisory | 보안 관점에서 모든 권장사항 검증 | Haiku |
+| codebase-patterns | 권장사항이 기존 코드 패턴과 호환되는지 검증 | Haiku |
+| framework-docs | 최신 API/문서와 권장사항 대조 검증 | Haiku |
+
+## 활성화 조건
+
+- `/vibe.spec` Step 3 리서치 단계에서 자동 활성화
+- Agent Teams 환경변수 활성화 상태
+
+## 워크플로우
+
+```
+[입력: 10개 병렬 리서치 결과]
+    |
+    ├──→ best-practices: 패턴 종합 + 합의 주도
+    ├──→ security-advisory: 보안 리스크 검증
+    ├──→ codebase-patterns: 기존 코드 호환성 검증
+    └──→ framework-docs: 최신 API 대조 검증
+         |
+    [SendMessage 교차 검증]
+         |
+    best-practices: 최종 통합 요약 → SPEC Context 반영
+```
+
+## spawn 패턴
+
+```text
+TeamCreate(team_name="research-{feature}", description="Research collaboration for {feature}")
+
+Task(team_name="research-{feature}", name="best-practices", subagent_type="best-practices-agent",
+  prompt="리서치 팀 리더. 10개 병렬 리서치 결과를 종합하세요.
+  리서치 결과: {all_research_results}
+  역할: 패턴/안티패턴 종합, 팀원 간 충돌 해결, 최종 통합 요약 작성.
+  TaskList를 확인하고 작업을 claim하세요. 팀원에게 SendMessage로 검증을 요청하세요.
+  모든 작업 완료 후 최종 요약을 작성하세요.")
+
+Task(team_name="research-{feature}", name="security-advisory", subagent_type="security-advisory-agent",
+  prompt="리서치 팀 보안 담당. 리서치 결과: {all_research_results}
+  역할: 보안 관점에서 모든 권장사항 검증.
+  보안 리스크 발견 시 best-practices에게 SendMessage로 알리세요.
+  TaskList에서 보안 관련 작업을 claim하세요.")
+
+Task(team_name="research-{feature}", name="codebase-patterns", subagent_type="codebase-patterns-agent",
+  prompt="리서치 팀 코드베이스 담당. 리서치 결과: {all_research_results}
+  역할: 권장사항이 기존 코드 패턴과 호환되는지 검증.
+  비호환 발견 시 best-practices에게 SendMessage로 알리세요.
+  TaskList에서 호환성 관련 작업을 claim하세요.")
+
+Task(team_name="research-{feature}", name="framework-docs", subagent_type="framework-docs-agent",
+  prompt="리서치 팀 문서 담당. 리서치 결과: {all_research_results}
+  역할: 최신 API/문서와 권장사항 대조 검증.
+  폐기/변경된 API 발견 시 best-practices에게 SendMessage로 알리세요.
+  TaskList에서 문서 검증 관련 작업을 claim하세요.")
+```
+
+## Result Merge Rules
+
+| Area | Merge Strategy |
+|------|----------------|
+| Best Practices | Deduplicate, keep most detailed |
+| Security | ALL included (no dedup for safety) |
+| Libraries | Consensus recommendations |
+
+## 팀원 간 통신
+
+```text
+security-advisory → best-practices: "JWT 라이브러리 권장사항에 CVE-2024-xxxx 취약점. 대안 필요"
+codebase-patterns → best-practices: "기존 코드가 class 패턴인데 함수형 권장은 비호환. 점진적 마이그레이션 제안"
+framework-docs → best-practices: "React 19에서 useEffect 패턴 변경됨. 리서치 결과의 패턴은 구버전"
+best-practices → broadcast: "최종 합의: JWT는 jose 라이브러리로 교체, 함수형 전환은 신규 파일만 적용"
+```
+
+## ⛔ 하지 않는 것
+
+- 코드 작성/수정 (리서치 결과만 텍스트로 반환)
+- 파일 생성 (SPEC에 반영은 메인 에이전트가 담당)
+- 보안 이슈 중복 제거 (안전을 위해 ALL 포함)

package/agents/teams/review-debate-team.md

@@ -1,125 +1,125 @@
-# Review Debate Team
-
-개별 리뷰어의 발견을 팀으로 토론하여 우선순위를 검증하고 오탐을 제거하는 교차 검증 팀.
-
-## 팀 구성
-
-| 팀원 | 역할 | Model |
-|------|------|-------|
-| security-reviewer (리더) | P1/P2 이슈 종합, 보안 이슈 최종 판정, 합의 주도 | Sonnet |
-| architecture-reviewer | 구조적 영향 평가, 숨겨진 결합도 식별 | Sonnet |
-| performance-reviewer | 성능 영향 평가, 부하 시나리오 검증 | Sonnet |
-| simplicity-reviewer | 과잉 설계 지적, 더 단순한 대안 제시, 오탐 식별 | Sonnet |
-
-## 활성화 조건
-
-- P1 또는 P2 이슈 2개 이상 발견 시 자동 활성화
-- Agent Teams 환경변수 활성화 상태
-- P1/P2 이슈 1개 이하 → 스킵
-
-## 사용 스킬
-
-- `/vibe.review` (Phase 4.5: Review Debate)
-- `vibe.spec.review` skill (Step 3.5: SPEC Debate)
-- `/vibe.run` (Review Team: 구현 후 리뷰)
-
-## 워크플로우
-
-```
-[입력: P1/P2 이슈 목록]
-    |
-    ├──→ security-reviewer: 보안 이슈 판정 + 합의 주도
-    ├──→ architecture-reviewer: 구조적 영향 평가
-    ├──→ performance-reviewer: 성능 영향 평가
-    └──→ simplicity-reviewer: 오탐 식별, 단순 대안 제시
-         |
-    [SendMessage 교차 검증]
-         |
-    security-reviewer: 팀 합의 종합 → 최종 P1/P2 목록
-```
-
-## spawn 패턴
-
-### Code Review 컨텍스트 (vibe.review, vibe.run)
-
-```text
-TeamCreate(team_name="review-debate-{feature}", description="Review debate for {feature}")
-
-Task(team_name="review-debate-{feature}", name="security-reviewer", subagent_type="security-reviewer",
-  mode="bypassPermissions",
-  prompt="리뷰 토론 팀 리더. Phase 2에서 발견된 P1/P2 이슈를 팀과 함께 검증하세요.
-  Phase 2 결과: {phase2_findings}
-  역할: 보안 이슈 최종 판정, 팀원 간 우선순위 충돌 해결, 최종 합의 요약 작성.
-  TaskList를 확인하고 이슈를 claim하세요. 각 이슈에 대해 팀원에게 SendMessage로 검증을 요청하세요.
-  모든 이슈 검증 완료 후 최종 합의 결과를 작성하세요.")
-
-Task(team_name="review-debate-{feature}", name="architecture-reviewer", subagent_type="architecture-reviewer",
-  mode="bypassPermissions",
-  prompt="리뷰 토론 팀 아키텍처 담당. Phase 2 결과: {phase2_findings}
-  역할: 각 이슈의 구조적 영향 평가, 숨겨진 결합도/의존성 식별.
-  아키텍처 관점에서 우선순위 변경이 필요하면 security-reviewer에게 SendMessage로 알리세요.
-  TaskList에서 아키텍처 관련 이슈를 claim하세요.")
-
-Task(team_name="review-debate-{feature}", name="performance-reviewer", subagent_type="performance-reviewer",
-  mode="bypassPermissions",
-  prompt="리뷰 토론 팀 성능 담당. Phase 2 결과: {phase2_findings}
-  역할: 성능 영향 평가, 부하 시 cascading failure 가능성 검증.
-  성능 관점에서 P2→P1 승격이 필요하면 security-reviewer에게 SendMessage로 알리세요.
-  TaskList에서 성능 관련 이슈를 claim하세요.")
-
-Task(team_name="review-debate-{feature}", name="simplicity-reviewer", subagent_type="simplicity-reviewer",
-  mode="bypassPermissions",
-  prompt="리뷰 토론 팀 복잡도 담당. Phase 2 결과: {phase2_findings}
-  역할: 과잉 진단(오탐) 식별, 더 단순한 수정 방안 제시.
-  오탐이나 P1→P2 강등이 필요하면 security-reviewer에게 SendMessage로 알리세요.
-  TaskList에서 복잡도/단순화 관련 이슈를 claim하세요.")
-```
-
-### SPEC Review 컨텍스트 (vibe.spec.review)
-
-spawn 패턴은 동일하되, prompt의 입력이 다름:
-
-```text
-TeamCreate(team_name="spec-debate-{feature}", description="SPEC review debate for {feature}")
-
-# prompt 차이점:
-# - "Phase 2 결과: {phase2_findings}" 대신 "SPEC: {spec_content}, 발견된 이슈: {p1_p2_issues}"
-# - 코드가 아닌 SPEC 문서를 대상으로 검증
-# - 나머지 팀 구성/통신 패턴은 동일
-```
-
-## 팀원 간 통신
-
-```text
-architecture-reviewer → security-reviewer: "Unbounded query는 부하 시 cascading failure 가능. P2→P1 승격 제안"
-simplicity-reviewer → security-reviewer: "CSRF on read-only endpoint는 side effect 없음. P1→P2 강등 제안"
-performance-reviewer → architecture-reviewer: "N+1 query가 현재 데이터 규모에서는 영향 없으나 확장 시 문제. 의견?"
-security-reviewer → broadcast: "최종 합의: SQL Injection P1 유지, Unbounded query P1 승격, CSRF P2 강등, Circular dep 오탐 제거"
-```
-
-## 토론 결과 형식
-
-```
-🤝 REVIEW DEBATE RESULTS
-
-Team Consensus (4 reviewers):
-
-✅ Validated P1 (unanimous):
-  1. [SECURITY] SQL Injection — 4/4 agree critical
-
-⬆️ Upgraded P2→P1 (debate result):
-  2. [PERF] Unbounded query — cascading failure risk under load
-
-⬇️ Downgraded P1→P2:
-  3. [SECURITY] CSRF — read-only endpoint, no side effect
-
-❌ Removed (false positive):
-  4. [ARCH] Circular dep — actually a valid cross-reference
-```
-
-## ⛔ 하지 않는 것
-
-- 코드 직접 수정 (리포트만 작성)
-- 이슈 수정 방법 구현
-- P3 이슈 토론 (P1/P2만)
-- 합의 없이 단독 판정
+# Review Debate Team
+
+개별 리뷰어의 발견을 팀으로 토론하여 우선순위를 검증하고 오탐을 제거하는 교차 검증 팀.
+
+## 팀 구성
+
+| 팀원 | 역할 | Model |
+|------|------|-------|
+| security-reviewer (리더) | P1/P2 이슈 종합, 보안 이슈 최종 판정, 합의 주도 | Sonnet |
+| architecture-reviewer | 구조적 영향 평가, 숨겨진 결합도 식별 | Sonnet |
+| performance-reviewer | 성능 영향 평가, 부하 시나리오 검증 | Sonnet |
+| simplicity-reviewer | 과잉 설계 지적, 더 단순한 대안 제시, 오탐 식별 | Sonnet |
+
+## 활성화 조건
+
+- P1 또는 P2 이슈 2개 이상 발견 시 자동 활성화
+- Agent Teams 환경변수 활성화 상태
+- P1/P2 이슈 1개 이하 → 스킵
+
+## 사용 스킬
+
+- `/vibe.review` (Phase 4.5: Review Debate)
+- `vibe-spec-review` skill (Step 3.5: SPEC Debate)
+- `/vibe.run` (Review Team: 구현 후 리뷰)
+
+## 워크플로우
+
+```
+[입력: P1/P2 이슈 목록]
+    |
+    ├──→ security-reviewer: 보안 이슈 판정 + 합의 주도
+    ├──→ architecture-reviewer: 구조적 영향 평가
+    ├──→ performance-reviewer: 성능 영향 평가
+    └──→ simplicity-reviewer: 오탐 식별, 단순 대안 제시
+         |
+    [SendMessage 교차 검증]
+         |
+    security-reviewer: 팀 합의 종합 → 최종 P1/P2 목록
+```
+
+## spawn 패턴
+
+### Code Review 컨텍스트 (vibe.review, vibe.run)
+
+```text
+TeamCreate(team_name="review-debate-{feature}", description="Review debate for {feature}")
+
+Task(team_name="review-debate-{feature}", name="security-reviewer", subagent_type="security-reviewer",
+  mode="bypassPermissions",
+  prompt="리뷰 토론 팀 리더. Phase 2에서 발견된 P1/P2 이슈를 팀과 함께 검증하세요.
+  Phase 2 결과: {phase2_findings}
+  역할: 보안 이슈 최종 판정, 팀원 간 우선순위 충돌 해결, 최종 합의 요약 작성.
+  TaskList를 확인하고 이슈를 claim하세요. 각 이슈에 대해 팀원에게 SendMessage로 검증을 요청하세요.
+  모든 이슈 검증 완료 후 최종 합의 결과를 작성하세요.")
+
+Task(team_name="review-debate-{feature}", name="architecture-reviewer", subagent_type="architecture-reviewer",
+  mode="bypassPermissions",
+  prompt="리뷰 토론 팀 아키텍처 담당. Phase 2 결과: {phase2_findings}
+  역할: 각 이슈의 구조적 영향 평가, 숨겨진 결합도/의존성 식별.
+  아키텍처 관점에서 우선순위 변경이 필요하면 security-reviewer에게 SendMessage로 알리세요.
+  TaskList에서 아키텍처 관련 이슈를 claim하세요.")
+
+Task(team_name="review-debate-{feature}", name="performance-reviewer", subagent_type="performance-reviewer",
+  mode="bypassPermissions",
+  prompt="리뷰 토론 팀 성능 담당. Phase 2 결과: {phase2_findings}
+  역할: 성능 영향 평가, 부하 시 cascading failure 가능성 검증.
+  성능 관점에서 P2→P1 승격이 필요하면 security-reviewer에게 SendMessage로 알리세요.
+  TaskList에서 성능 관련 이슈를 claim하세요.")
+
+Task(team_name="review-debate-{feature}", name="simplicity-reviewer", subagent_type="simplicity-reviewer",
+  mode="bypassPermissions",
+  prompt="리뷰 토론 팀 복잡도 담당. Phase 2 결과: {phase2_findings}
+  역할: 과잉 진단(오탐) 식별, 더 단순한 수정 방안 제시.
+  오탐이나 P1→P2 강등이 필요하면 security-reviewer에게 SendMessage로 알리세요.
+  TaskList에서 복잡도/단순화 관련 이슈를 claim하세요.")
+```
+
+### SPEC Review 컨텍스트 (vibe-spec-review)
+
+spawn 패턴은 동일하되, prompt의 입력이 다름:
+
+```text
+TeamCreate(team_name="spec-debate-{feature}", description="SPEC review debate for {feature}")
+
+# prompt 차이점:
+# - "Phase 2 결과: {phase2_findings}" 대신 "SPEC: {spec_content}, 발견된 이슈: {p1_p2_issues}"
+# - 코드가 아닌 SPEC 문서를 대상으로 검증
+# - 나머지 팀 구성/통신 패턴은 동일
+```
+
+## 팀원 간 통신
+
+```text
+architecture-reviewer → security-reviewer: "Unbounded query는 부하 시 cascading failure 가능. P2→P1 승격 제안"
+simplicity-reviewer → security-reviewer: "CSRF on read-only endpoint는 side effect 없음. P1→P2 강등 제안"
+performance-reviewer → architecture-reviewer: "N+1 query가 현재 데이터 규모에서는 영향 없으나 확장 시 문제. 의견?"
+security-reviewer → broadcast: "최종 합의: SQL Injection P1 유지, Unbounded query P1 승격, CSRF P2 강등, Circular dep 오탐 제거"
+```
+
+## 토론 결과 형식
+
+```
+🤝 REVIEW DEBATE RESULTS
+
+Team Consensus (4 reviewers):
+
+✅ Validated P1 (unanimous):
+  1. [SECURITY] SQL Injection — 4/4 agree critical
+
+⬆️ Upgraded P2→P1 (debate result):
+  2. [PERF] Unbounded query — cascading failure risk under load
+
+⬇️ Downgraded P1→P2:
+  3. [SECURITY] CSRF — read-only endpoint, no side effect
+
+❌ Removed (false positive):
+  4. [ARCH] Circular dep — actually a valid cross-reference
+```
+
+## ⛔ 하지 않는 것
+
+- 코드 직접 수정 (리포트만 작성)
+- 이슈 수정 방법 구현
+- P3 이슈 토론 (P1/P2만)
+- 합의 없이 단독 판정