@didim365/agent-cli-core 0.1.0 → 0.1.2

package/dist/docs/ai_adapter/template/00_vibecoding_workflow.md

@@ -1,636 +0,0 @@
-## _TDD 기반 설계 중심 · 인간 검증 중심 · 다중 AI 순환 개발 방법론_
-
-> "빠르게 짜는 방법"이 아니라  
-
-> **"빠르게 설계하고, 빠르게 검증하고, 빠르게 수정하는 구조"**
-
----
-
-## 슬라이드 1. 기존 바이브코딩의 진짜 문제
-
-❌ 문제의 본질은 **속도**가 아니다  
-
-❌ 문제의 본질은 **검증 구조의 부재**
-
-**정리**
-
-- AI는 빠르다
-    
-- 하지만 **틀린 방향으로도 매우 빠르다**
-    
-- 방향을 잡는 구조가 없으면 → 실패 속도만 빨라진다
-    
-
-> 👉 그래서 이 방법론은 "속도"가 아니라 **"짧은 검증 순환"을 목표로 한다**
-
----
-
-## 슬라이드 2. R2-D2란 무엇인가?
-
-### **R**ecursive **R**eview - **D**esign **D**riven (TDD)
-
-|   |   |   |
-|---|---|---|
-|약어|의미|설명|
-|R2|Recursive Review|다중 AI 순환 검증 구조|
-|D2|Test Design Driven|TDD 기반 설계 중심 개발|
-
-**핵심 정의**
-
-> R2-D2는 AI가 생성한 결과물을    
-> **다른 AI로 교차 검증**하고,    
-> **인간이 최종 승인**하는    
-> **설계 중심 순환 개발 프레임워크**이다.
-
----
-
-## 슬라이드 3. 이 방법론의 핵심은 3가지다
-
-### ❌ "AI를 잘 쓰는 방법론" 아님
-
-### ⭕ **"검증을 구조화한 TDD 기반 개발 방법론"**
-
-|핵심 원칙|설명|
-|---|---|
-|TDD 기반|테스트 = AI를 위한 설계 명세이자 가드레일|
-|인간 검증 중심|최종 판단은 항상 인간|
-|다중 AI 순환|교차 검증으로 편향 제거|
-
----
-
-## 슬라이드 4. R2-D2 방법론의 기반 문서 체계
-
-|문서|역할|파일|
-|---|---|---|
-|TDD 방법론|Kent Beck TDD + Tidy First 원칙|[99_TDD_plan.md](./99_TDD_plan.md)|
-|성능 가이드|파이썬 성능 최적화 기준|[100_Python_Performance_Guide.md](./100_Python_Performance_Guide.md)|
-|작업계획서 템플릿|단계별 작업 계획 구조|[01_todolist_performance_template.md](./01_todolist_performance_template.md)|
-|코드리뷰 템플릿|AI 코드 리뷰 구조|[02_code_review_template.md](./02_code_review_template.md)|
-|작업결과서 템플릿|작업 결과 기록 구조|[03_work_result_report_template.md](./03_work_result_report_template.md)|
-
-> 💡 이 문서들이 **AI 에이전트의 가드레일**이자 **인간 검증의 기준**이 된다
-
----
-
-## 슬라이드 5. 왜 TDD가 이 방법론의 중심인가
-
-**일반적인 오해**
-
-- TDD = 테스트 많이 쓰는 개발 방식 ❌
-    
-
-**R2-D2에서의 TDD**
-
-- **설계 중심 개발** — 테스트가 "무엇을 만들어야 하는지" 정의
-    
-- **빠른 실패 → 빠른 수정** — 짧은 사이클로 방향 검증
-    
-- **AI의 가드레일** — 테스트 범위 안에서만 AI가 작동
-    
-
----
-
-## 슬라이드 6. TDD = AI를 위한 설계 명세이자 가드레일
-
-R2-D2에서 TDD는:
-
-- "이 기능을 어떻게 구현할까?" ❌ (구현 중심 사고)
-    
-- **"이 기능의 설계를 어떻게 정의하고, AI가 이를 따르게 할까?" ⭕** (설계 + 가드레일)
-    
-
-👉 테스트는 단순 검증이 아니라 **AI를 위한 설계 명세이자 가드레일**
-
-**TDD의 3가지 역할**
-
-|역할|설명|
-|---|---|
-|설계 정의|테스트 = "무엇을 만들어야 하는지"의 명세|
-|빠른 검증|작은 단위로 설계 의도대로 구현됐는지 확인|
-|가드레일|AI가 설계 범위를 벗어나지 않도록 경계 설정|
-
-**한 문장 정의**
-
-> _TDD는 AI가 코드를 쓰는 시대에,_    
-> _인간이 설계를 정의하고, AI가 그 안에서만 움직이도록_    
-> _가드레일을 세우는 장치다._
-
-📄 참고: [99_TDD_plan.md](./99_TDD_plan.md)
-
----
-
-## 슬라이드 7. TDD의 짧은 순환 구조 (Red → Green → Refactor)
-
-`설계 가설     ↓ 🔴 실패 테스트 작성 (Red)     ↓ 🟢 최소 구현 (Green) — "Make it work"     ↓ 🔵 구조/성능 개선 (Refactor) — "Make it right, Make it fast"     ↓ 다음 설계 가설`
-
-**TDD 핵심 원칙** ([99_TDD_plan.md](./99_TDD_plan.md) 발췌)
-
-|원칙|설명|
-|---|---|
-|Red First|반드시 **실패하는 테스트**를 먼저 작성|
-|Minimal Green|테스트를 통과하는 **최소한의 코드만** 구현|
-|Safe Refactor|테스트가 **통과하는 상태에서만** 리팩터링|
-|Tidy First|구조 변경(Structural)과 동작 변경(Behavioral) 분리|
-|**Commit Discipline**|**작업 단계 완료 시에만** 커밋 (아래 조건 충족 필수)|
-
-**커밋 규율** (Commit Discipline)
-
-> ⚠️ **커밋은 반드시 사용자 승인 완료 후에만 수행**
-
-|조건|설명|
-|---|---|
-|✅ 모든 테스트 통과|테스트가 실패한 상태로 커밋 금지|
-|✅ 린터 경고 0개|모든 경고 해결 후 커밋|
-|✅ 다중 AI 리뷰 완료|리뷰 피드백 반영 완료 ([02_code_review_template.md](./02_code_review_template.md) 활용)|
-|✅ 사용자 최종 승인|인간이 검토하고 승인한 후에만 커밋|
-|✅ 단일 논리 단위|하나의 변경 목적만 포함|
-
-`# ❌ BAD: 테스트 실패 상태로 커밋 git commit -m "WIP: 작업 중"  # ✅ GOOD: 단계 완료 후 커밋 git commit -m "[Phase1-Green] 사용자 인증 최소 구현 완료" git commit -m "[Phase1-Refactor] 인증 로직 구조 개선"`
-
-**롤백 규율** (Rollback Discipline)
-
-> 🔄 **작업이 잘못된 방향으로 진행 시 즉시 롤백**
-
-|상황|조치|
-|---|---|
-|AI가 지속적으로 잘못된 방향으로 진행|git reset --hard HEAD 후 재시작|
-|테스트가 계속 실패하고 해결 불가|작업 직전 커밋으로 롤백|
-|설계 방향 자체가 잘못됨|PRD 또는 작업계획서 재검토 후 롤백|
-
-`# 작업 직전 상태로 롤백 (변경사항 폐기) git reset --hard HEAD  # 특정 커밋으로 롤백 git reset --hard <commit-hash>  # 변경사항 보존하며 롤백 (재작업용) git reset --soft HEAD~1`
-
-> 💡 **핵심**: 잘못된 방향으로 계속 진행하는 것보다 **빠르게 롤백하고 재시작**하는 것이 효율적
-
-**권장 사이클 시간**
-
-|작업 유형|권장 시간|
-|---|---|
-|단순 기능|15-30분|
-|복잡 로직|30-60분|
-|아키텍처 변경|60-120분 (분할 권장)|
-
----
-
-## 슬라이드 8. AI 검증의 핵심 원칙
-
-> **같은 AI가 자신의 결과를 검증하면 안 된다.**    
-> **다른 AI가 교차 검증 도구로 사용되어야 한다.**    
-> **최종 검증 주체는 항상 인간이다.**
-
-**왜 다른 AI로 검증하는가?**
-
-|문제|해결|
-|---|---|
-|동일 모델 → 동일 편향|서로 다른 모델로 교차 검증|
-|같은 프롬프트 → 같은 실수|다른 관점의 프롬프트 사용|
-
-👉 결과가 같으면 **신뢰도 상승**  
-
-👉 결과가 다르면 **설계 의심 신호**
-
----
-
-## 슬라이드 9. R2-D2 전체 프로세스 (10단계)
-
-```mermaid
-flowchart TD
-  subgraph PHASE1["Phase 1: PRD 작성 및 검증"]
-    A1[1. 사용자: PRD 초안 작성<br/>01_basic_project_plan]
-    A2[2. 다른 AI: PRD 리뷰 및 개선]
-    A3[3. 사용자: PRD 최종 승인]
-    A1 --> A2 --> A3
-    A2 -.->|개선 필요| A1
-  end
-
-  subgraph PHASE2["Phase 2: 작업계획서 작성 및 검증"]
-    B1[4. 작업계획서 작성<br/>01_todolist_performance_template.md]
-    B2[5. 다른 AI: 작업계획서 리뷰]
-    B3[6. 사용자: 작업계획서 승인]
-    B1 --> B2 --> B3
-    B2 -.->|개선 필요| B1
-  end
-
-  subgraph PHASE3["Phase 3: 작업 실행 (TDD 순환)"]
-    C1[7. 사전작업 🔴<br/>컨텍스트 수집 + 테스트 작성]
-    C2[8. 본작업 🟢<br/>최소 구현]
-    C3[9. 사후작업 🔵<br/>리팩터링 + 결과서 작성]
-    C1 --> C2 --> C3
-  end
-
-  subgraph PHASE4["Phase 4: 검증 및 순환"]
-    D1[10. 다른 AI: 작업결과서 기반 리뷰]
-    D2{문제 발견?}
-    D3[사용자: Step 완료 승인]
-    D4[✅ 커밋]
-    D1 --> D2
-    D2 -->|YES 수정가능| C2
-    D2 -->|NO| D3
-    D3 --> D4
-  end
-
-  subgraph ROLLBACK["롤백 분기"]
-    R1{방향이 잘못됨?}
-    R2[git reset --hard]
-    R3[작업 직전 상태로 복원]
-    R1 -->|YES| R2 --> R3
-  end
-
-  A3 --> B1
-  B3 --> C1
-  C3 --> D1
-  D2 -->|YES 방향 잘못| R1
-  R3 -->|재시작| C1
-  D4 -->|다음 Step| C1
-  D4 -->|완료| E[릴리즈]
-```
-
----
-
-## 슬라이드 10. Phase 1 — PRD 작성 및 다중 AI 검증
-
-### Step 1-3: PRD 순환
-
-|Step|담당|내용|
-|---|---|---|
-|1|사용자|PRD 초안 작성 (01_basic_project_plan)|
-|2|다른 AI|PRD 리뷰 및 개선 의견 도출|
-|3|사용자|PRD 최종 검증 및 승인|
-
-**PRD 리뷰 포인트**
-
-- 요구사항의 명확성
-    
-- 기술적 실현 가능성
-    
-- 누락된 케이스/예외 상황
-    
-- 성능 요구사항 명시 여부
-    
-
-> 💡 PRD가 명확해야 **테스트(가드레일)도 명확**해진다
-
----
-
-## 슬라이드 11. Phase 2 — 작업계획서 작성 및 검증
-
-### Step 4-6: 작업계획서 순환
-
-|Step|담당|내용|
-|---|---|---|
-|4|사용자/AI|작업계획서 작성 ([01_todolist_performance_template.md](./01_todolist_performance_template.md))|
-|5|다른 AI|작업계획서 리뷰 및 검증|
-|6|사용자|작업계획서 최종 승인|
-
-**작업계획서 구조** ([01_todolist_performance_template.md](./01_todolist_performance_template.md) 기반)
-
-`Phase N: [Phase 제목] ├── N.1 사전 작업 (Pre-Work) │   ├── [CONTEXT] 작업 목적 및 배경 확인 │   ├── [REVIEW] 이전 작업 결과서 검토 │   └── [ANALYSIS] 현재 코드/설정 분석 ├── N.2 🔴 RED Phase: 실패 테스트 작성 ├── N.3 🟢 GREEN Phase: 최소 코드 구현 ├── N.4 🔵 REFACTOR Phase: 코드 개선 + 성능 최적화 └── N.5 사후 작업 (Post-Work)     ├── [TEST] 전체 테스트 실행     ├── [DOC] 작업 결과서 작성     └── [COMMIT] 변경사항 커밋`
-
----
-
-## 슬라이드 12. Phase 3 — 작업 실행 (사전 → 본작업 → 사후)
-
-### 작업 단위의 3단계 = TDD 사이클
-
-|단계|TDD 매핑|역할|원칙|
-|---|---|---|---|
-|**사전 작업**|🔴 Red|컨텍스트 수집 + 테스트 작성|이전 결과서 참조, 실패 테스트 먼저|
-|**본 작업**|🟢 Green|최소 구현|"Make it work" — 동작 우선|
-|**사후 작업**|🔵 Refactor|구조/성능 개선 + 결과서 작성|"Make it right, Make it fast"|
-
-**사전 작업 체크리스트**
-
-PRD 문서 검토
-
-**이전 작업 결과서 확인** (Phase 2 이후 필수)
-
-현재 코드/설정 분석
-
-🔴 실패 테스트 작성 및 실패 확인
-
-**본 작업 체크리스트**
-
-🟢 테스트를 통과하는 **최소한의 코드** 구현
-
-테스트 통과 확인
-
-**사후 작업 체크리스트**
-
-🔵 코드 구조 개선 (중복 제거, 네이밍, 책임 분리)
-
-🔵 성능 최적화 적용 ([100_Python_Performance_Guide.md](./100_Python_Performance_Guide.md) 참조)
-
-테스트 재확인 (여전히 PASS)
-
-린터 검사 통과 (경고 0개)
-
-**작업 결과서 작성** ([03_work_result_report_template.md](./03_work_result_report_template.md))
-
-다중 AI 리뷰 요청 → 피드백 반영 ([02_code_review_template.md](./02_code_review_template.md))
-
-**사용자 최종 승인** ← 여기서 검토!
-
-**커밋** (승인 완료 후에만)
-
-  `git commit -m "[Phase{N}-{단계}] {작업 내용} 완료"`
-
-> 🔄 **롤백 판단**: 작업이 잘못된 방향이면 즉시 git reset --hard HEAD 후 재시작
-
----
-
-## 슬라이드 13. Refactor 단계의 성능 최적화 (Make it fast)
-
-> 📄 참고: [100_Python_Performance_Guide.md](./100_Python_Performance_Guide.md)
-
-**Refactor 원칙**: 먼저 동작(Green) → 구조 개선(Right) → **성능 최적화(Fast)**
-
-|패턴|Before|After|개선|⚠️ 주의|
-|---|---|---|---|---|
-|멤버십 검사|if x in list|if x in set|O(1)|반복 검사 시만!|
-|리스트 생성|for + append|컴프리헨션|~20-30%↑||
-|JSON 처리|json.dumps()|orjson.dumps()|~8배↑|**bytes 반환**|
-|대량 인스턴스|일반 클래스|__slots__|메모리 50%↓|제약사항 확인|
-
-**성능 최적화 프로세스**
-
-`1. 측정 (Baseline) → 2. 분석 (체크리스트) → 3. 최적화 → 4. 검증 (테스트 + 성능)`
-
-> ⚠️ **주의**: 성능 수치는 환경별로 다름. **본인 환경에서 측정 후 적용**
-
----
-
-## 슬라이드 14. Phase 4 — 작업결과서와 다중 AI 리뷰
-
-### Step 10: 작업결과서 기반 검증
-
-**작업결과서의 2가지 역할**
-
-|역할|설명|
-|---|---|
-|**RAG 컨텍스트**|다음 작업의 사전작업에서 참조 → 판단의 연속성 유지|
-|**리뷰 기준자료**|다른 AI가 코드를 리뷰하는 기준|
-
-**작업결과서 구조** ([03_work_result_report_template.md](./03_work_result_report_template.md) 기반)
-
-`Step X.X: [작업명] 작업 기록 ├── 📋 작업 개요 (목표, 범위) ├── 🔴 Red Phase (테스트 작성) ├── 🟢 Green Phase (구현) ├── ✅ 검증 결과 (테스트, 커버리지, Linter) ├── 🐛 이슈 및 해결 ├── 📝 다음 단계 └── 📊 커밋 요약`
-
-**다중 AI 리뷰 프로세스**
-
-`작업결과서 + 변경 코드         ↓ 다른 AI 에이전트 리뷰 (Codex, Claude, Gemini 등) ([02_code_review_template.md](./02_code_review_template.md) 활용)         ↓     문제/리팩터링 포인트 도출         ↓     YES → 수정 작업 → 결과서에 추가 기록     NO  → 사용자 최종 승인`
-
----
-
-## 슬라이드 15. 작업결과서 = 지식 순환의 핵심
-
-❌ 단순 보고서    
-⭕ **다음 작업을 위한 RAG 컨텍스트**
-
-**활용 흐름**
-
-`이전 작업 결과서     ↓ 다음 작업의 [REVIEW] 사전작업에서 참조     ↓ "왜 이렇게 했는지" AI가 이해     ↓ 판단의 연속성 유지`
-
-**필수 확인 항목** (Phase 2 이후)
-
-- 이전 체크리스트 완료 여부
-    
-- 미해결 이슈
-    
-- 성능 개선 결과
-    
-- 다음 단계 안내 사항
-    
-
-> 💡 **사람의 기억을 문서화 → AI의 컨텍스트로 확장**
-
----
-
-## 슬라이드 16. TDD 적용 예시: 사용자 인증 기능
-
-|단계|TDD|내용|
-|---|---|---|
-|사전|🔴 Red|"로그인 실패 시 401 반환" 테스트 작성 (실패 확인)|
-|본작업|🟢 Green|AI에게 최소 구현 요청, 테스트 통과|
-|사후|🔵 Refactor|코드 구조 개선, 성능 최적화|
-|사후|📝 Record|작업결과서 작성 ([03_work_result_report_template.md](./03_work_result_report_template.md))|
-|검증|🔍 Review|다른 AI로 교차 검증|
-|승인|✅ Approve|사용자 최종 승인|
-
-**테스트 예시** (가드레일)
-
-`def test_login_fail_returns_401():     """로그인 실패 시 401 반환 - AI가 이 범위 안에서만 구현"""     response = client.post("/login", json={"email": "wrong", "password": "wrong"})     assert response.status_code == 401     assert "error" in response.json()`
-
----
-
-## 슬라이드 17. R2-D2 도구 스택 예시
-
-|역할|권장 도구|비고|
-|---|---|---|
-|메인 코딩|Cursor (Claude)|주 개발 환경|
-|코드 리뷰|Claude Code, Codex|교차 검증용|
-|설계 검증|Gemini|다른 관점 확보|
-|문서화|Notion / Obsidian|작업결과서 관리|
-|작업 관리|GitHub Issues / Jira|추적성 확보|
-
-**문서 체계**
-
-`docs/working_history/ ├── 99_TDD_plan.md                    # TDD 방법론 ├── 100_Python_Performance_Guide.md   # 성능 가이드 ├── v{버전}/ │   ├── {기능}_todolist.md            # 작업계획서 │   └── working_history/ │       ├── template.md               # 결과서 템플릿 │       └── Phase{N}_{타이틀}_{날짜}.md # 실제 결과서`
-
----
-
-## 슬라이드 18. R2-D2 Anti-Patterns
-
-### ❌ 하지 말아야 할 것
-
-|Anti-Pattern|문제점|올바른 방법|
-|---|---|---|
-|**자기 검증**|같은 AI로 작성 → 같은 AI로 검증|다른 AI로 교차 검증|
-|**컨텍스트 단절**|작업 결과서 생략|모든 Phase에 결과서 필수|
-|**Big Bang 구현**|테스트 없이 대규모 구현|Red → Green → Refactor 순환|
-|**무승인 진행**|인간 승인 없이 다음 단계|사용자 최종 승인 필수|
-|**Green에서 최적화**|구현하면서 성능 최적화|Refactor 단계에서만 최적화|
-|**사전작업 생략**|바로 본작업 진행|이전 결과서 검토 후 진행|
-|**승인 전 커밋**|리뷰/승인 없이 커밋|사용자 승인 후에만 커밋|
-|**잘못된 방향 고집**|실패해도 계속 같은 방향 진행|즉시 롤백 후 재시작|
-|**롤백 지연**|문제 인지 후에도 진행|빠르게 git reset 결정|
-
----
-
-## 슬라이드 19. 인간 검증의 위치
-
-R2-D2에서 **모든 단계는 인간이 최종 검증**:
-
-|Phase|단계|실행 주체|검증 주체|
-|---|---|---|---|
-|1|PRD 작성|사용자|사용자|
-|1|PRD 리뷰|다른 AI|**사용자**|
-|2|작업계획서 작성|사용자/AI|사용자|
-|2|작업계획서 리뷰|다른 AI|**사용자**|
-|3|작업 실행|AI 에이전트|**사용자**|
-|4|코드 리뷰|다른 AI|**사용자**|
-
-> 💡 **AI는 서로 교차 검증하지만,**    
-> **최종 승인 책임은 항상 사람에게 있다**
-
----
-
-## 슬라이드 20. R2-D2는 무엇인가?
-
-|항목|해당 여부|
-|---|---|
-|Agile|✅|
-|TDD (Kent Beck)|✅|
-|Tidy First|✅|
-|AI Pair Programming|✅|
-|문서 중심 개발|✅|
-|RAG 기반 지식 순환|✅|
-|다중 에이전트 검증|✅|
-
-**정의**
-
-> _AI 에이전트를 포함한 검증 중심 Agile 개발 프레임워크_
-
----
-
-## 슬라이드 21. 기존 방식과의 차이
-
-|구분|일반 바이브코딩|R2-D2 방법론|
-|---|---|---|
-|속도|빠름|빠름|
-|품질|불안정|안정|
-|재현성|없음|있음|
-|기록|거의 없음|구조화 (결과서)|
-|확장|어려움|쉬움|
-|검증|단일/없음|다중 순환|
-|AI 가드레일|없음|TDD 테스트|
-|지식 축적|없음|결과서 → RAG|
-
----
-
-## 슬라이드 22. 한 문장 정의
-
-> **"R2-D2는**    
-> **TDD로 AI의 가드레일을 세우고,**    
-> **다른 AI가 교차 검증하며,**    
-> **인간이 최종 승인하는**    
-> **설계 중심 순환 개발 프레임워크다."**
-
----
-
-## 슬라이드 23. AI 시대의 개발자는 무엇을 해야 하는가
-
-- 코드를 많이 짜는 사람 ❌
-    
-- AI를 잘 다루는 사람 ❌
-    
-
-⭕ **설계를 정의하고, 검증하고, 판단을 축적하는 사람**
-
-**개발자의 역할 변화**
-
-|역할|설명|
-|---|---|
-|과거|R2-D2 시대|
-|코드 작성|**설계 정의** (테스트 = 명세)|
-|버그 수정|**가드레일 설정** (TDD)|
-|코드 리뷰|**다중 AI 리뷰 조율**|
-|문서화|**결과서로 지식 축적**|
-
----
-
-## 슬라이드 24. 마지막 문장
-
-> **TDD는 더 이상 '테스트 방법론'이 아니다.**
-> 
-> **AI 시대의 개발자에게**    
-> **설계를 정의하고, AI를 가드레일 안에서 움직이게 하는**    
-> **최소한의 통제 장치다.**
-
----
-
-## 부록 A. R2-D2 Quick Reference
-
-### 10단계 프로세스 요약
-
-|#|단계|담당|산출물|커밋|
-|---|---|---|---|---|
-|1|PRD 초안 작성|사용자|01_basic_project_plan|❌|
-|2|PRD 리뷰|다른 AI|개선 의견|❌|
-|3|**PRD 승인**|사용자|확정 PRD|✅ 가능|
-|4|작업계획서 작성|사용자/AI|*_todolist.md|❌|
-|5|작업계획서 리뷰|다른 AI|개선 의견|❌|
-|6|**작업계획서 승인**|사용자|확정 계획서|✅ 가능|
-|7|사전작업 (🔴 Red)|AI|테스트 + 컨텍스트|❌|
-|8|본작업 (🟢 Green)|AI|최소 구현|❌|
-|9|사후작업 (🔵 Refactor)|AI|개선 코드 + 결과서|❌|
-|10|다중 AI 리뷰|다른 AI|리뷰 의견|❌|
-|✅|**사용자 승인**|사용자|완료|✅ 필수|
-
-> ⚠️ **커밋 규칙**: **사용자 승인 완료 후에만** 커밋 (테스트 통과 + 린터 0개 + 승인)  
-
-> 🔄 **롤백 규칙**: 작업이 잘못된 방향으로 진행 시 git reset으로 작업 직전 상태로 복원 후 재시작
-
-### 핵심 문서
-
-|문서|용도|
-|---|---|
-|[99_TDD_plan.md](./99_TDD_plan.md)|TDD 방법론 (Red→Green→Refactor, Tidy First)|
-|[100_Python_Performance_Guide.md](./100_Python_Performance_Guide.md)|Refactor 단계 성능 최적화 기준|
-|[01_todolist_performance_template.md](./01_todolist_performance_template.md)|작업계획서 템플릿|
-|[02_code_review_template.md](./02_code_review_template.md)|코드 리뷰 템플릿|
-|[03_work_result_report_template.md](./03_work_result_report_template.md)|작업결과서 템플릿|
-
----
-
-## 부록 B. 전체 프로세스 통합 다이어그램
-
-```mermaid
-flowchart TD
-  %% =========================
-  %% R2-D2 Framework Process
-  %% Recursive Review - Design Driven (TDD)
-  %% =========================
-
-  %% --- PRD Phase ---
-  A[1. 사용자: PRD 초안 작성<br/>01_basic_project_plan]
-  A --> B[2. 다른 AI: PRD 리뷰 및 개선 의견]
-  B --> C{개선 필요?}
-  C -- YES --> A
-  C -- NO --> D[3. 사용자: PRD 최종 승인]
-
-  %% --- Planning Phase ---
-  D --> E[4. 작업계획서 작성<br/>01_todolist_performance_template.md]
-  E --> F[5. 다른 AI: 작업계획서 리뷰]
-  F --> G{개선 필요?}
-  G -- YES --> E
-  G -- NO --> H[6. 사용자: 작업계획서 승인]
-
-  %% --- Task Cycle ---
-  H --> K{다음 작업 Step 선택}
-
-  subgraph R2D2["R2-D2 작업 순환 (TDD Cycle)"]
-    direction TB
-    K --> P[7. 🔴 사전작업 Red<br/>- 이전 결과서 검토<br/>- 컨텍스트 수집<br/>- 실패 테스트 작성]
-    P --> Q[8. 🟢 본작업 Green<br/>- 최소 구현<br/>- 테스트 통과]
-    Q --> R[9. 🔵 사후작업 Refactor<br/>- 구조 개선<br/>- 성능 최적화<br/>- 작업결과서 작성]
-    R --> S[작업결과서 저장<br/>03_work_result_report_template.md]
-    S --> T[10. 다른 AI: 작업결과서 기반 리뷰<br/>Codex, Claude, Gemini]
-    T --> U{문제 발견?}
-    U -- YES 수정가능 --> V[수정 피드백]
-    V --> Q
-    U -- NO --> W[사용자: Step 완료 승인]
-    W --> COMMIT[✅ 커밋]
-  end
-
-  %% --- Rollback Branch ---
-  U -- YES 방향 잘못 --> RESET{롤백 결정}
-  RESET --> GIT[git reset --hard]
-  GIT --> RESTORE[작업 직전 상태 복원]
-  RESTORE -->|재시작| P
-
-  %% --- Iteration / Finish ---
-  COMMIT --> X{남은 Step?}
-  X -- YES --> K
-  X -- NO --> Y[릴리즈 및 회고<br/>결과서 정리]
-
-  %% --- RAG Connection ---
-  S -.->|다음 사전작업에서 참조| P
-```