@ai-dev-methodologies/rlp-desk 0.15.3 → 0.15.5

package/docs/rlp-desk/internal/verification-policy-gap-analysis.md

@@ -1,523 +0,0 @@
-# Verification Policy — 전체 구현 계획
-
-> 작성일: 2026-03-24
-> 브랜치: feature/verification-policy
-> 상태: 1차 드래프트 stash 보관 (verification-policy-v1-draft), 원본 복원
-> 프로세스: 항목별 ralplan 검토 → codex 검토 → 개선사항 0까지 반복 → 근거 기록 → 반영
-
----
-
-## 1. 적용 대상 파일
-
-| 파일 | 역할 | 변경 범위 |
-|------|------|----------|
-| `src/governance.md` | 프로토콜 정의 (Iron Laws, L1-L4, Checkpoints 등) | 신규 섹션 추가 |
-| `src/scripts/init_ralph_desk.zsh` | PRD, test-spec, Worker, Verifier 템플릿 생성 | 4개 템플릿 전면 강화 |
-| `src/commands/rlp-desk.md` | brainstorm 질문 + run 실행 로직 | brainstorm 항목 추가, run checkpoint/debug 확장 |
-
----
-
-## 2. 적용 항목 전체 목록 (18개)
-
-각 항목에 대해 다음 세션에서 수행할 프로세스:
-
-```
-1. 항목 정의: 무엇을 바꾸는가
-2. 근거 확인: 왜 바꾸는가 (논문/실전사례/공식문서 참조)
-3. 적용 방법 설계: 어떻게 바꾸는가 (구체적 코드/텍스트)
-4. ralplan 검토: Planner→Architect→Critic 3관점 합의
-5. codex 검토: 독립 관점 리뷰
-6. 개선사항 반영: 검토 피드백 0건까지 반복
-7. 코드 반영: 확정된 내용만 적용
-8. 근거 기록: 이 문서에 판정 이유와 최종 형태 기록
-9. E2E 검증: 실제 /rlp-desk run으로 동작 확인
-```
-
----
-
-### P0-1: governance.md — Iron Laws 4개
-
-**무엇을**: governance.md §1 뒤에 §1a Iron Laws 섹션 추가
-**왜**: superpowers verification-before-completion에서 24건 실패 사례로 도출. "should pass" 같은 증거 없는 주장 방지.
-**근거 출처**:
-- superpowers verification-before-completion SKILL.md (research §56)
-- NIST CAISI 2026 anti-gaming (research §8)
-- 실전: 이 세션에서 echo 시뮬레이션만으로 "검증 완료" 보고한 사례
-
-**적용 대상**:
-```
-IL-1: NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
-IL-2: NO INIT WITHOUT AC QUALITY SCORE ≥ 6
-IL-3: NO PASS WITH TODO IN ANY REQUIRED VERIFICATION LAYER
-IL-4: NO PASS WITHOUT TEST COUNT ≥ AC COUNT × 3
-```
-
-**검토 포인트**:
-- IL-2 점수 6은 적절한가? (12점 만점의 50%)
-- IL-4 배수 3은 적절한가? (happy+negative+boundary = 최소 3)
-- Iron Law가 너무 엄격해서 작은 프로젝트에서 오버헤드가 되지는 않는가?
-
-**판정**: APPROVED (ralplan Option C 합의 + codex review 반영)
-- IL-2 threshold 6: 적절 (REJECT 경계, 3단계 REJECT/WARN/PASS 채택)
-- IL-4 multiplier 3: 적절 (per-AC only, aggregate 제거 — 논리적 중복)
-- 소규모 프로젝트 오버헤드: Option C 내장 비례성으로 해결
-- 주요 변경: IL-3 인라인 L1-L4 정의, IL-1 command output=primary, IL-2 pre-run gate, Enforcement 테이블 추가
-**최종 형태**: governance.md §1a에 반영 완료 (§1~§2 사이)
-
----
-
-### P0-2: governance.md — Evidence Gate 5-Step
-
-**무엇을**: governance.md §1b Evidence Gate 섹션 추가
-**왜**: Verifier가 "should pass"로 verdict 내리는 것 방지. 명령어 실행 → 출력 확인 → 판정 순서 강제.
-**근거 출처**:
-- superpowers verification-before-completion 5-Step (research §56)
-- 이 세션 실전: agent debug mode를 echo로만 "검증"한 사례
-
-**적용 대상**:
-```
-1. IDENTIFY: 증명 명령어
-2. RUN: 실행
-3. READ: 출력 + exit code
-4. VERIFY: 주장과 일치?
-5. ONLY THEN: 판정
-```
-
-**검토 포인트**:
-- Verifier 템플릿에 5-Step을 넣으면 LLM이 실제로 따르는가?
-- Agent mode vs tmux mode에서 동일하게 적용 가능한가?
-- 5-Step이 검증 시간을 얼마나 늘리는가?
-
-**판정**: APPROVED (ralplan 합의 + codex 반영)
-- 5-Step은 IL-1의 구체적 운용 프로토콜로 명시 ("operationalizes IL-1")
-- Agent/tmux 동일 적용 (Verifier 프롬프트에 내장)
-- Forbidden Patterns 5개: 실전 실패 패턴 기반
-**최종 형태**: governance.md §1b에 반영 완료
-
----
-
-### P0-3: governance.md — Risk Classification (LOW/MEDIUM/HIGH/CRITICAL)
-
-**무엇을**: governance.md §1c Risk Classification 섹션 추가
-**왜**: 모든 US에 동일한 검증 강도를 적용하면 오버헤드. 리스크에 비례한 검증 계층 배분.
-**근거 출처**:
-- DO-178C DAL A-E (research §27)
-- IEC 62304 소프트웨어 안전 분류 (research §41)
-- GAMP 5 Cat 1-5 (research §41)
-- ISO 26262 ASIL A-D (research §41)
-- 규제 산업 7가지 보편 패턴 §48 "리스크 기반 강도 조절"
-
-**적용 대상**:
-```
-LOW: L1+L3
-MEDIUM: L1+L2+L3
-HIGH: L1+L2+L3+L4
-CRITICAL: L1+L2+L3+L4+consensus+mutation
-```
-
-**검토 포인트**:
-- 4등급이 적절한가? 3등급(LOW/MEDIUM/HIGH)으로 단순화?
-- CRITICAL에 consensus + mutation 둘 다 강제하면 비용이 과도한가?
-- 누가 리스크 등급을 결정하는가? (brainstorm에서 사용자? Leader 자동?)
-
-**판정**: APPROVED (ralplan 합의 + codex 반영)
-- 4등급 유지: LOW/MEDIUM/HIGH/CRITICAL (DO-178C/IEC 62304 근거)
-- MEDIUM L2 조건부: "L1 + L2 (if external deps) + L3" — §1d와 일관성 확보
-- CRITICAL mutation: "(when P0-8 tooling is available)" 한정자 추가
-- 누가 결정: brainstorm에서 사용자 확인, skip시 Leader 지정
-**최종 형태**: governance.md §1c에 반영 완료
-
----
-
-### P0-4: governance.md — Verification Layers L1-L4
-
-**무엇을**: governance.md §1d Verification Layers 섹션 추가
-**왜**: L1(unit test)만으로는 프로덕션 장애를 못 잡음. trading 시스템에서 mock 73개 pass → 4가지 프로덕션 장애.
-**근거 출처**:
-- 실전 피드백: trading paper trading L1-only 장애 (2026-03)
-- TVER-WAVE1 P0: "verification checkpoint를 더 잘게 나눈다"
-- Testing Trophy (Kent C. Dodds): integration 중심 (research §29)
-
-**적용 대상**:
-```
-L1: Unit Test (항상 필수)
-L2: Integration (외부 서비스 시 필수, 아니면 "N/A — 사유")
-L3: E2E Simulation (항상 필수)
-L4: Deploy Verify (배포 시 필수, 아니면 "N/A — 사유")
-```
-
-**검토 포인트**:
-- L3(E2E)를 "항상 필수"로 하면 간단한 유틸리티 함수에도 E2E가 필요한가?
-- "N/A — 사유" 형식이 충분한가? Verifier가 사유의 타당성을 판단할 수 있는가?
-- L2와 L3의 경계가 모호한 경우 가이드라인이 필요한가?
-
-**판정**: APPROVED (ralplan 합의 + codex 반영)
-- L3 항상 필수: 유틸리티 함수도 "run with known input, verify output" 형태로 충족
-- N/A 사유 형식: "N/A — {specific reason}" IL-3 연계
-- L2/L3 경계: §1d에 scope 명확화 (L2=real services, L3=full pipeline)
-- §1a IL-3 "all four required by default" → "risk classification (§1c)에 의해 결정"으로 수정
-**최종 형태**: governance.md §1d에 반영 완료
-
----
-
-### P0-5: governance.md — Verification Checkpoints 3단계
-
-**무엇을**: governance.md §1e + rlp-desk.md run 섹션에 §⑦d 추가
-**왜**: 한 번의 큰 verify보다 중간 checkpoint가 agent 우회를 막음.
-**근거 출처**:
-- Claude Code/Cursor/Devin 공식 문서 (TVER-WAVE1 official §1-4)
-- TDFlow multi-agent (arxiv 2510.23761)
-- Addy Osmani 5단계 검증 (TVER-WAVE1 blogs)
-
-**적용 대상**:
-```
-Checkpoint 1: Story/Unit (per-US verify)
-Checkpoint 2: Integration (us_id=ALL 첫 번째)
-Checkpoint 3: Release/Readiness (us_id=ALL 최종)
-```
-
-**검토 포인트**:
-- 기존 per-US → ALL 2단계와 어떻게 다른가?
-- Checkpoint 2(Integration)를 별도로 강제하면 iteration 수가 늘어나는가?
-- rlp-desk.md run 섹션에 어떤 형태로 넣는가? (Leader 지시? Verifier 판단?)
-
-**판정**: APPROVED (ralplan 합의 + codex 반영)
-- 3→2 체크포인트로 축소: Checkpoint 2+3 합쳐서 "Release Readiness" (기존 us_id=ALL과 정확히 매핑)
-- 기존 flow와 차이 없음: per-US = Checkpoint 1, ALL = Checkpoint 2. 새 iteration 없음.
-- §7¾ 참조 제거 (P1-8에서 추가 예정), inline으로 "escalation to user if 3 consecutive failures"
-**최종 형태**: governance.md §1e에 반영 완료
-
----
-
-### P0-6: init — test-spec 5개 필수 필드
-
-**무엇을**: test-spec 템플릿에 Verification Context 섹션 (target behavior, impacted tests, required new tests, forbidden shortcuts, pass/fail evidence)
-**왜**: "어떻게 TDD를 해라" 보다 "어떤 테스트를 확인해라"가 regression 70% 감소.
-**근거 출처**:
-- TDAD arxiv 2603.17973 (research §57, TVER-WAVE1 P0)
-- TVER-WAVE1 insight memo P0: "test-spec에 먼저 적게 한다"
-
-**적용 대상**: init_ralph_desk.zsh test-spec 템플릿 Verification Context 섹션
-**검토 포인트**:
-- 5개 필드가 모든 프로젝트 유형에 적합한가?
-- "impacted tests"는 첫 init 시점에 비어있을 수밖에 없는데, TODO로 두는 게 맞는가?
-- Worker가 이 필드를 채우는가, 사용자가 채우는가?
-
-**판정**: APPROVED (ralplan + codex NO ISSUES FOUND)
-- 5개 필드 모든 프로젝트 적합 (universal fields)
-- Impacted Tests TODO: 허용 (Verification Context ≠ Verification Layer, IL-3 적용 안됨). Worker가 첫 iteration에 채움.
-- 사용자가 Target Behavior 채움, Worker가 나머지 채움
-**최종 형태**: init_ralph_desk.zsh test-spec 템플릿에 Verification Context 섹션 반영. zsh -n OK + init E2E OK.
-
----
-
-### P0-7: init — test-spec L1-L4 필수 섹션
-
-**무엇을**: test-spec 템플릿에 L1/L2/L3/L4 각 섹션 (TODO = Verifier FAIL)
-**왜**: P0-4(L1-L4 정의)의 실제 적용 지점. 빈칸 허용 시 L1만 채우고 나머지 무시.
-**근거 출처**: P0-4와 동일 + IL-3 (research §56 Iron Laws)
-
-**적용 대상**: init_ralph_desk.zsh test-spec 템플릿
-**검토 포인트**:
-- L2, L4가 N/A인 경우 "N/A — 사유"를 어떤 형식으로 강제하는가?
-- Deploy Checklist는 L4가 필요한 경우만 표시? 항상 표시?
-- 섹션 순서: L1→L2→L3→L4 vs L1→L3→L2→L4 (필수를 먼저?)
-
-**판정**: APPROVED (ralplan + codex NO ISSUES FOUND)
-- N/A 형식: governance §1d 원문 그대로 사용 ("N/A — no external services (pure computation/transformation)")
-- Deploy Checklist: 제거 — L4 섹션 자체가 항상 존재하되 N/A 표기. 별도 체크리스트 불필요.
-- 순서: L1→L2→L3→L4 (governance §1d와 일치)
-**최종 형태**: init_ralph_desk.zsh test-spec 템플릿에 L1-L4 섹션 반영. zsh -n OK + init E2E OK.
-
----
-
-### P0-8: init — Mutation Testing Gate
-
-**무엇을**: test-spec 템플릿에 Mutation Testing Gate 섹션
-**왜**: coverage 100%여도 mutation score 4%인 테스트 스위트가 존재.
-**근거 출처**:
-- MutGen arxiv 2506.02954 "100% coverage이지만 4% mutation score" (research §57)
-- MuTAP arxiv 2308.16557 (research §57)
-- Meta ACH: 73% 엔지니어 수용률 (TVER-WAVE1 blogs)
-- Sentry: Stryker mutation score 62% (TVER-WAVE1 blogs)
-- Trail of Bits: "100% coverage 함정" (TVER-WAVE1 blogs)
-
-**적용 대상**: init_ralph_desk.zsh test-spec 템플릿
-**검토 포인트**:
-- ≥60% 기준은 적절한가? (Sentry 실전 62%, 학술 권장 85%)
-- "recommended for MEDIUM+ risk"로 하면 LOW는 면제?
-- 언어별 도구 매핑을 test-spec에 넣는가, governance에 넣는가?
-
-**판정**: APPROVED (ralplan + codex NO ISSUES FOUND)
-- ≥60% 기준: 적절 (Sentry 실전 62% 기반). "project default; override in PRD if justified" 주석 추가.
-- CRITICAL only: governance §1c와 일치. MEDIUM+로 확장 안 함.
-- 도구 매핑: test-spec에 (프로젝트별 도구 상이). governance에는 정책만.
-**최종 형태**: init_ralph_desk.zsh test-spec 템플릿에 Mutation Testing Gate 섹션 반영. zsh -n OK + init E2E OK.
-
----
-
-### P1-1: brainstorm — INVEST + GWT + Task Type + Risk Level
-
-**무엇을**: brainstorm 항목 3~5번에 INVEST, Given/When/Then, Task Type, Risk Level 추가
-**왜**: 모호한 AC로 init되면 이후 전체 파이프라인이 무의미.
-**근거 출처**:
-- Specification by Example (Gojko Adzic): 2.75x 품질 향상 (research §11)
-- Example Mapping (Cucumber): 4색 카드 (research §11)
-- INVEST 기준 (research §11)
-- 성공 서비스 4조건: "명확한 범위 설정" (research §55)
-
-**적용 대상**: rlp-desk.md brainstorm 섹션
-**검토 포인트**:
-- brainstorm 항목이 14개로 늘어나면 사용자 피로도가 높아지는가?
-- Task Type 5종이 모든 경우를 커버하는가?
-- 도메인 언어 강제를 brainstorm에서 하는 게 맞는가, init에서 하는 게 맞는가?
-
-**판정**: APPROVED — INVEST/GWT/TaskType/Risk를 item 3 하위에 nest (12개 유지). brainstorm에서 강제.
-**최종 형태**: rlp-desk.md brainstorm item 3에 sub-bullets로 반영. zsh -n N/A (md 파일).
-
----
-
-### P1-2: brainstorm — Ambiguity Gate (AC 점수 0-12)
-
-**무엇을**: brainstorm 마지막에 AC 품질 점수 산출 + 5이하 차단
-**왜**: 모호한 AC를 시스템적으로 차단. deep-interview의 ambiguity score와 유사.
-**근거 출처**:
-- deep-interview 스킬: ambiguity ≤ 20% gate (OMC)
-- Ouroboros project: specification quality = primary bottleneck
-- 성공 서비스 4조건: "문제 정의가 모호하면 적용 어렵다" → 모호함 제거가 선결
-
-**적용 대상**: rlp-desk.md brainstorm 섹션 (After all items are confirmed 부분)
-**검토 포인트**:
-- 6개 차원(단일 행동, 도메인 언어, 이해관계자, 이식성, 구체적 예시, 독립성)이 적절한가?
-- LLM이 점수를 일관되게 매길 수 있는가? (temperature 0 필요?)
-- init 차단이 너무 공격적인가? WARN만으로 충분한가?
-
-**판정**: APPROVED — per-AC minimum (ANY AC < 6 = REJECT, 평균 아님). 3단계 REJECT/WARN/PASS.
-**최종 형태**: rlp-desk.md brainstorm "After all items confirmed" 섹션에 반영.
-
----
-
-### P1-3: init — Worker 템플릿 Test-First + Forbidden Shortcuts
-
-**무엇을**: Worker 템플릿에 TDAD 기반 Test-First Approach + Forbidden Shortcuts 추가
-**왜**: 일반적 "TDD를 따르세요" 지시 → regression 악화 (6.08%→9.94%). 영향 테스트 컨텍스트 제공 → 70% 감소.
-**근거 출처**:
-- TDAD arxiv 2603.17973 (research §57)
-- superpowers TDD SKILL.md 합리화 방지 12패턴 (research §56)
-
-**적용 대상**: init_ralph_desk.zsh Worker 템플릿
-**검토 포인트**:
-- "TDD를 해라" 대신 "이 테스트를 확인해라" — Worker가 test-spec을 읽고 실행하는 순서가 명확한가?
-- Forbidden Shortcuts 5개가 충분한가? 너무 많으면 Worker 컨텍스트 낭비?
-- superpowers의 "코드 먼저 작성 → 삭제하고 다시" 규칙을 넣을 것인가?
-
-**판정**: APPROVED as-is — "delete and rewrite" 규칙 미포함 (Worker 접근법 과도 제약). 5개 shortcuts 충분.
-**최종 형태**: init_ralph_desk.zsh Worker 템플릿에 Test-First + Forbidden Shortcuts 반영. zsh -n OK + init E2E OK.
-
----
-
-### P1-4: init — Verifier 템플릿 강화 (Evidence Gate + Layer + Anti-gaming + 정량 기준)
-
-**무엇을**: Verifier 템플릿에 Iron Law, Evidence Gate, Layer Enforcement, Anti-Gaming, Test Sufficiency 카운트, AI 결함율 정량 기준, Reproducibility 체크 추가
-**왜**: 현재 Verifier는 "신뢰하지 마라" 1줄만 있고, 구체적 검증 프로세스가 없음.
-**근거 출처**:
-- P0-1~P0-8의 모든 근거
-- CodeRabbit 1.7x/2.74x/3x 정량 기준 (TVER-WAVE1 blogs)
-- NIST CAISI anti-gaming (research §8)
-
-**적용 대상**: init_ralph_desk.zsh Verifier 템플릿
-**검토 포인트**:
-- Verifier 템플릿이 너무 길어지면 Agent() 호출 시 토큰 비용 증가. 적정 길이는?
-- 정량 기준(mock ≤30%, 중복 ≤3%, complexity ≤10, 함수 ≤50줄)이 보편적으로 적용 가능한가?
-- verdict JSON에 layer_status, test_quality 필드 추가 시 기존 파싱 로직에 영향?
-
-**판정**: APPROVED — layer_status/test_quality는 additive JSON 필드 (기존 파싱 무영향). 토큰 비용 허용 범위.
-**최종 형태**: init_ralph_desk.zsh Verifier 템플릿에 Iron Law, Evidence Gate, Layer Enforcement, Anti-Gaming, Test Sufficiency, verdict JSON 확장 반영. zsh -n OK + init E2E OK.
-
----
-
-### P1-5: init — test-spec Code Quality Gates (중복, Mock, AI 결함율)
-
-**무엇을**: test-spec에 Code Duplication Threshold, Mock Ratio Limit, AI Code Defect Thresholds 섹션
-**왜**: AI 코드의 정량적 품질 저하를 수치로 탐지.
-**근거 출처**:
-- SonarSource/GitClear: 2020-2024 중복 8x 증가 (TVER-WAVE1 blogs)
-- "Mocking Everything Made Our Tests Useless": mock 에러 12→203 (research §57)
-- CodeRabbit: 1.7x 이슈, 2.74x 보안, 3x 가독성 (TVER-WAVE1 blogs)
-
-**적용 대상**: init_ralph_desk.zsh test-spec 템플릿
-**검토 포인트**:
-- 중복 ≤3%, mock ≤30% 수치가 업계 표준과 일치하는가?
-- 이 수치를 프로젝트별로 커스터마이즈 할 수 있어야 하는가?
-- 도구 제안(jscpd, pylint)을 test-spec에 넣으면 언어 종속적이 되는가?
-
-**판정**: APPROVED — "project-appropriate tool (e.g., jscpd, pylint, sonar)"로 일반화. 프로젝트별 override 가능.
-**최종 형태**: init_ralph_desk.zsh test-spec 템플릿에 Code Quality Gates 섹션 반영. zsh -n OK + init E2E OK.
-
----
-
-### P1-6: init — test-spec Reproducibility Gate
-
-**무엇을**: test-spec에 Reproducibility Gate 섹션 (lock 파일, clean install, 보안 스캔, 환경변수)
-**왜**: 성공 서비스 4조건 중 "고정된 의존성 관리". 재현 불가능한 빌드 방지.
-**근거 출처**:
-- 성공 서비스 4조건 (research §55)
-- Continuous Delivery (Humble, Farley) (research §29)
-
-**적용 대상**: init_ralph_desk.zsh test-spec 템플릿
-**검토 포인트**:
-- 모든 프로젝트에 lock 파일이 있는가? (순수 스크립트 프로젝트는?)
-- "exact version" 강제가 현실적인가? (^ 허용하는 프로젝트가 많음)
-- Verifier가 clean install을 실제로 실행하면 시간이 얼마나 걸리는가?
-
-**판정**: APPROVED — "N/A — no external dependencies" 이스케이프 추가. 보안 스캔도 "known vulnerabilities documented" 허용.
-**최종 형태**: init_ralph_desk.zsh test-spec 템플릿에 Reproducibility Gate 섹션 반영. zsh -n OK + init E2E OK.
-
----
-
-### P1-7: rlp-desk.md — run 섹션 debug.log 확장
-
-**무엇을**: run 섹션의 --debug 지시에 Layer check, Sufficiency, Anti-gaming, Scope Lock, Checkpoint 로그 추가
-**왜**: 새 검증 활동이 debug.log에 안 남으면 사후 분석 불가.
-**근거 출처**:
-- 이 세션 실전: debug.log에 [PLAN]/[EXEC]/[VALIDATE]만 있고 검증 세부 과정 없음
-- superpowers: 3-phase logging ([PLAN]/[EXEC]/[VALIDATE]) 패턴
-
-**적용 대상**: rlp-desk.md run 섹션 ⑦c, ⑦d, ⑧
-**검토 포인트**:
-- 로그가 너무 많으면 debug.log 읽기 어려워지는가?
-- 새 태그 형식: [EXEC] phase=layer_check vs [VERIFY] layer_check?
-- Agent mode에서 LLM이 이 로그를 빠뜨리지 않도록 강제하는 방법?
-
-**판정**: APPROVED as-is — 3개 debug_log 추가. 기존 [EXEC] phase= 형식 유지. --debug에서만 발동.
-**최종 형태**: rlp-desk.md run ⑦c에 layer_check, sufficiency, checkpoint 로그 3줄 반영.
-
----
-
-### P1-8: governance.md — Architecture Escalation (3회 실패)
-
-**무엇을**: governance.md §7¾ Architecture Escalation 섹션 추가
-**왜**: Fix Loop가 무한 반복되는 anti-pattern 방지. 3회 실패 = 표면 수정이 아닌 설계 문제.
-**근거 출처**:
-- superpowers systematic-debugging Phase 4.5 (research §56)
-- 실전: trading system consensus fail → 40분 낭비
-
-**적용 대상**: governance.md §7½ 뒤
-**검토 포인트**:
-- 3회가 적절한가? 2회? 5회?
-- 에스컬레이션 시 BLOCKED vs 사용자 질문 중 어느 것?
-- tmux mode에서도 동일하게 작동하는가?
-
-**판정**: APPROVED — 3회 적절. tmux mode: escalation.md 작성 + BLOCKED sentinel (reason: architecture-escalation).
-**최종 형태**: governance.md §7¾ Architecture Escalation 섹션 반영 (§7½와 §8 사이).
-
----
-
-### P2-1: init — PRD 템플릿 강화 (Type, Risk, GWT, Boundary, Layers)
-
-**무엇을**: PRD US 템플릿에 Type, Risk, Given/When/Then AC, Boundary Cases, Verification Layers 필드 추가
-**왜**: PRD가 검증의 출발점. 여기가 약하면 이후 전부 무너짐.
-**근거 출처**: P1-1의 근거 + P0-3(Risk) + P0-4(L1-L4) 종합
-
-**검토 포인트**:
-- 필드가 너무 많으면 사용자가 init 후 PRD 작성을 포기하는가?
-- 기존 프로젝트(v0.2.4)와의 하위 호환성? (기존 scaffold가 있는 프로젝트에서 재init?)
-
-**판정**: APPROVED — GWT AC, Type, Risk, Boundary Cases, Verification Layers 추가. 기존 호환성: init은 파일 존재시 skip하므로 무영향.
-**최종 형태**: init_ralph_desk.zsh PRD 템플릿에 반영. zsh -n OK + init E2E OK.
-
----
-
-### P2-2: init — test-spec Anti-pattern Checklist + Traceability Matrix
-
-**무엇을**: test-spec에 Test Quality Checklist (7항목) + Traceability Matrix (US→AC→Test→Evidence)
-**왜**: 테스트 존재만으로 부족. 테스트가 행동을 검증하고, 추적 가능해야 함.
-**근거 출처**:
-- 23종 anti-pattern 카탈로그에서 7개 핵심 축약 (research §32)
-- IEEE 829 traceability (research §28)
-- aidoc-flow-framework cumulative tagging (research §24)
-
-**검토 포인트**:
-- 7항목이 적절한 축약인가? 핵심을 놓친 항목은?
-- Traceability Matrix를 Worker가 채우는가, 사용자가 채우는가?
-- 23종 전체를 참고 문서로 제공하고, 7종만 필수 체크로?
-
-**판정**: APPROVED — 7항목 체크리스트 + Traceability Matrix (US→AC→Test→Layer→Evidence→Status). Worker가 구현 중 채움. 23종은 참고용 (governance에 미포함).
-**최종 형태**: init_ralph_desk.zsh test-spec 템플릿에 Test Quality Checklist + Traceability Matrix 반영. zsh -n OK + init E2E OK.
-
----
-
-### P2-3: Scope Lock Enforcement
-
-**무엇을**: Verifier가 git diff --name-only vs US 범위 대조
-**왜**: Worker가 다른 US의 파일을 건드리거나 의존성 파일을 임의로 수정하는 것 방지.
-**근거 출처**:
-- 성공 서비스 4조건: "독립적인 작업 환경" (research §55)
-- v0.2.3 pre-existing failure filter에서 이미 git diff 사용 중
-
-**검토 포인트**:
-- 정당한 사유(리팩터링, 공유 유틸리티)를 허용하는 예외 메커니즘 필요?
-- 의존성 파일(package.json) 변경 시 AC에 명시 여부 체크?
-
-**판정**: APPROVED — P1-4 Verifier 프로세스 step 4에 이미 구현 ("Scope Lock check: verify Worker only modified files within the US scope"). 예외 메커니즘은 AC에 명시된 파일만 허용.
-**최종 형태**: init_ralph_desk.zsh Verifier 템플릿 Verification Process step 4에 반영 완료.
-
----
-
-### P3-1/2/3: Domain Rule Packs, Playwright Agents, Mutahunter, Spec Kit
-
-**결정 필요**: P3 항목은 이번 feature/verification-policy에 포함할 것인가, 별도 브랜치?
-**현재 판단**: 이번 브랜치는 P0+P1+P2까지. P3는 별도 feature branch에서 다음 iteration.
-
----
-
-## 3. --with-self-verification 신규 기능 (별도 설계)
-
-**개념**: `--debug`와 별도 플래그. Worker/Verifier의 행위 이력, 산출물, 검증 방법, 대상을 구조화된 JSON으로 기록.
-
-**용도**:
-1. Verifier가 Worker 행위를 교차 검증 (같은 iteration)
-2. Meta-loop: 완료 후 report 분석 → PRD/test-spec 보강 → 재실행 (cross-iteration)
-
-**설계 필요 사항**:
-- 출력 파일 형식 (JSON? Markdown?)
-- 파일 위치 (logs/<slug>/self-verification-report-NNN.json?)
-- Worker와 Verifier 각각 기록하는가, Leader가 조합하는가?
-- Meta-loop 시 어떤 도구가 report를 분석하는가? (Leader? 별도 Agent?)
-
-**결정**: 이번 브랜치에서는 설계만. 구현은 P3 또는 별도 feature.
-
----
-
-## 4. E2E 자가검증 시나리오 (반영 후 실행)
-
-모든 항목 반영 후 최소 3개 시나리오로 `/rlp-desk run --debug` 실행:
-
-| # | 시나리오 | 리스크 | 검증 포인트 |
-|---|---------|--------|-----------|
-| 1 | Python calculator (단순, LOW) | LOW | L1+L3만 필요, L2/L4는 N/A, GWT AC, test sufficiency |
-| 2 | REST API with PostgreSQL (중간, MEDIUM) | MEDIUM | L1+L2+L3, integration test, mock 비율, forbidden shortcuts |
-| 3 | Trading engine with Redis (복잡, CRITICAL) | CRITICAL | L1+L2+L3+L4, mutation gate, anti-gaming, 3-checkpoint, architecture escalation |
-
----
-
-## 5. 검토 프로세스 (다음 세션)
-
-```
-for each item in P0-1 ~ P2-3:
-  1. 이 문서에서 항목 읽기
-  2. 1차 코드 초안 작성
-  3. ralplan 검토 (Planner→Architect→Critic)
-  4. codex 검토 (독립 관점)
-  5. 개선사항 반영
-  6. 개선사항 0건까지 3-5 반복
-  7. 이 문서에 "판정"과 "최종 형태" 기록
-  8. 코드 반영
-  9. zsh -n 구문 검증
-  10. init E2E 검증 (scaffold 생성)
-done
-
-전체 항목 반영 후:
-  11. 3개 시나리오 E2E 자가검증
-  12. 최종 보고
-```