TDD RGB 사이클 Skill

Red → Green → Blue 사이클을 조율하여 테스트 목록의 각 항목을 순차적으로 구현합니다.

GOAL

• 성공 = 테스트 목록의 모든 항목이 - [x]로 완료되고, 모든 테스트가 통과하며, 작업 내역이 마크다운에 반영됨
• 모든 테스트 케이스가 - [x]로 완료됨
• 모든 테스트가 통과함
• 작업 내역이 마크다운 파일에 반영됨
• (Web App의 경우) 모든 .feature 시나리오의 @pending 해제·green, JPA Repository 완성, DSL 개선까지 완료
• 검토 지점의 밀도는 기어(low/mid/high)가 정한다 — 아래 "기어(Gears)" 섹션 참조

CONSTRAINTS

Hard Rules

Three Laws of TDD

1. "Write NO production code except to pass a failing test."
2. "Write only ENOUGH of a test to demonstrate a failure."
3. "Write only ENOUGH production code to pass the test."

TDD 핵심 규칙

• don't write code without a failing test.
• only write the code necessary to get the test to pass (little golf game).
• never delete tests without express permission.
• 테스트를 추가할 때는 반드시 한번에 하나씩 추가. 실패하는 테스트가 있을 때는 절대 새로운 테스트를 추가할 수 없음.

마이크로 사이클

각 단계는 2-3분 이내 작업으로 빠른 피드백을 받습니다.

• 복잡한 목표를 작은, 집중된, 검증 가능한 단계로 분해하여 순차적으로 실행
• low·mid 기어: 각 R/G/B 에이전트가 작업 완료 후 자체적으로 커밋을 수행 (커밋 → 피드백 → 다음 단계)
• high 기어: 에이전트는 커밋을 보류하고(stage까지만), 오케스트레이터가 use case 전체를 Red 전체→Green 전체→Blue 전체 3단계로 진행하며 각 단계 종료 시 한 번씩 커밋한다 (아래 "진행 표기 규칙"의 기어별 커밋 단위)

피드백 규칙

• 기어가 정의하는 검토 지점에서 반드시 사용자 피드백을 요청하고 대기 ("기어(Gears)" 섹션의 검토 지점 표 참조)
• 검토 지점에서는 사용자가 명시적으로 다음 단계로 진행을 결정해야만 진행
• 검토 지점이 아닌 phase 경계(mid/high 기어)에서는 대기 없이 다음 phase로 진행한다. 커밋은 기어별 커밋 단위를 따른다 — low는 phase마다, mid는 사이클마다, high는 use case 내 3-phase(전체 Red·전체 Green·전체 Blue)마다
• 피드백 요청 형식: "이 [구현/테스트/설계]에 대한 피드백을 주시겠어요? 특히 [집중해야 할 부분]에 대해서요."

기어(Gears) — 검토 밀도 조절

Kent Beck의 "driving in gears": 이론에 대한 확신(confidence)이 검토 지점의 밀도를 정한다. 기어는 검토 지점의 밀도를 바꾸고, 그에 맞춰 커밋 단위도 바뀐다 — TDD 3법칙, 한 번에 테스트 하나, 테스트 삭제 금지는 모든 기어에서 동일하지만, 커밋 단위는 low=phase(테스트마다 R/G/B 각각), mid=사이클(테스트마다 RGB 하나), high=use case 내 3-phase(use case 전체의 Red 한 번·Green 한 번·Blue 한 번)다.

revert 단위는 커밋 단위와 같다: low·mid는 테스트 단위로 되돌리고, high는 use case 내 phase 단위(전체 구현 또는 tidying만)로 되돌린다. high에서는 테스트 하나만 골라 되돌릴 수 없다.

기어별 검토 지점

기어	검토 지점(사용자 피드백 대기)	이해 채널(사용자가 코드를 이해하는 방법)	대응 상황
low (기본)	Red 후 · Green 후 · Blue 후	편집 하나하나 직접 읽기, 리팩터링도 직접 지시 (이해 체화)	이론에 확신 없음, 낯선 도메인·기술, 학습 목적
mid	테스트 1개의 R→G→B 사이클 완료 후 1회	사이클 경계의 diff 검토 + tidying 방향 지목·승인 (실행은 위임하되 판단은 유지)	유사 문제 경험 있음, 작동하는 이론을 빠르게 확보할 것으로 기대
high	전체 테스트 목록 완료 + 적대적 리뷰 통과 후 최종 1회	행동 명세(테스트 목록·Gherkin)로 이해 + 최종 검토에서 대표 슬라이스 하나를 골라 표본 정독	이론이 상용구(boilerplate) 수준으로 명확

기어 운용 — 호출 형식·전환 신호·폭발 반경(blast radius)·기어 기록

시작 시·사이클 경계 점검 시 이 스킬 디렉터리의 references/gears.md(정본)를 Read로 읽는다:

• Step 1 시작 시 — 기어 결정, 폭발 반경(blast radius) 점검, 기어 기록 형식
• 사이클 완료 시 — 업/다운시프트 신호 점검
• /tdd-feature와의 경계가 궁금할 때

기억할 최소한: 기어는 검토 밀도를 정하고, 폭발 반경(blast radius)은 틀렸을 때의 비용을 정한다 — 다른 축이다. 그래서 폭발 반경(blast radius) high-stakes(인증·인가, 결제·금액 계산, 데이터 삭제·변경, 외부 API, 동시성)가 감지되면 기어 권장과 별개로 적대적 리뷰 1회가 기어와 무관하게 실행되고, 그 diff 기준점이 될 HEAD 해시를 진행 기록에 남겨야 한다.

진행 표기 규칙 (기어 무관 — 정본)

체크박스는 커밋과 동기화된다: 표기는 그 커밋과 같은 커밋에 들어가고, 그 커밋에 담긴 만큼만 표기한다. 기어마다 커밋 단위가 달라서 결과가 달라 보일 뿐이다.

기어	커밋 단위	그래서 표기
low	R / G / B 각각 별도 커밋	각 커밋에서 그 단계를 표기
mid	테스트 1개의 RGB가 한 커밋	그 커밋에서 R·G·B를 한 번에 표기
high	use case 전체를 3단계로 나눠 커밋: 전체 Red→test:, 전체 Green→feat:, 전체 Blue→refactor:	Green 커밋에서 use case의 모든 테스트를 한 번에 [x]로 표기

high의 커밋 단위는 use case 내 3-phase다 — use case에 속한 모든 테스트의 Red 변경을 한 커밋(test:)에, Green 변경을 한 커밋(feat:)에, Blue 변경을 한 커밋 (refactor:, tidying이 불필요하면 생략)에 담는다. 테스트 단위가 아니라 phase 단위로 묶는다 — "이 use case가 무엇을 보장하는가"(Red) → "어떻게 최소 구현으로 통과시켰는가"(Green) → "구조를 어떻게 정리했는가"(Blue)가 각각 하나의 리뷰 단위가 된다. 에이전트는 커밋하지 않고 git add까지만 수행하며(커밋 보류), 오케스트레이터가 각 phase가 use case의 모든 테스트에 대해 끝날 때마다 커밋한다. body에는 그 phase에서 그 use case 전체에 걸쳐 내린 결정들을 docs/reviewable-commits.md 표준대로 담되, 길이는 ../../references/commit-style.md의 간결성 규칙(제목 + 핵심 bullet 2~4줄)을 따른다. 실행 절차는 "use case 완료 시" 섹션 참조.

이 규칙은 "Red 커밋에 테스트 파일과 문서 갱신을 같은 커밋에"(tdd-red)의 일반형이다. 표기가 커밋과 불일치하는 순간 진행 기록이 실제와 어긋난다(드리프트).

단, 완료 판정에 그대로 쓰지 않는다. 현재 포맷은 테스트당 체크박스가 하나라 R/G/B를 구분해 적을 자리가 없다 — low 기어에서는 Red 커밋이 그 하나를 채우므로, 마지막 테스트가 Red만 된 상태에서도 "모두 [x]"가 성립한다. high 기어도 같은 간극이 생긴다 — use case 전체의 Red 커밋(test:) 시점에는 모든 테스트가 아직 실패 상태이므로 체크박스는 전부 [ ]로 남는다. Green 커밋(feat:) 시점에 비로소 전부 [x]로 일괄 갱신한다. 완료는 체크박스가 아니라 전체 스위트 green으로 판정한다(mid는 한 커밋에 G·B가 함께 담기므로 이 간극이 없다).

배움 반영 게이트 (Spec Anchored)

구현 중 앵커 문서(규칙·예제)와 어긋나는 배움을 발견하면 코드보다 앵커를 먼저 갱신하고 같은 커밋에 담는다. 규칙이 바뀌는 배움만 사용자에게 질문한다. 절차·기준은 ../../references/anchor-update.md가 정본.

Principles

설계의 두 축과 Test Desiderata

phase마다 다른 설계를 한다: Red = 인터페이스 설계("이 행위가 외부에서 어떻게 호출되어야 하는가"), Green = 설계 없음·오직 동작, Blue = 구현 설계("내부적으로 어떻게 구현할 것인가"). 이 셋을 섞지 않는 것이 사이클을 도는 이유다.

테스트 품질의 기준: "Tests should be coupled to the behavior of code and decoupled from the structure of code."

Kent Beck 인용 원문, phase별 상세, Test Desiderata 12가지 속성 전체 표는 이 스킬 디렉터리의 references/test-design-principles.md가 정본이다 — 처음 이해할 때, 또는 phase 구분이 흐려졌다고 느낄 때 Read로 읽는다. (tdd-plan이 참조하는 정본이기도 하다.)

---

Mocking 가이드라인

판단에 바로 쓰는 규칙만 둔다. 근거·인용·안티패턴 전체 목록·테스트 더블 분류는 이 스킬 디렉터리의 references/mocking-guide.md를 Read로 읽는다.

무엇을 대체하는가 — 역할(role)이지 객체가 아니다.

대체해도 되는 것	대체하면 안 되는 것
다른 application service	내부 구현(리팩토링으로 생긴 협력자)
driven port(경계 인터페이스)	adapter — port를 대체하지 adapter를 대체하지 않는다
아직 구현 안 된 API 경계(설계 목적)	소유하지 않은 타입(3rd party) — 얇은 추상화로 감싼다
생성 비용이 크거나 공유되는 자원	데이터 객체(Entity·Value Object) — 실제 객체를 쓴다

무엇으로 대체하는가 — Fake를 먼저 고려한다. stubbing(when) 대신 save(), verify 대신 findAll()로 실제 결과를 검증한다. 영속성 계층에서 특히 그렇다. Mock은 상호작용 검증이 요구사항일 때만 쓴다.

경계 객체 자체는 모킹하지 않고 통합 테스트한다. UserService를 테스트할 때 UserRepository를 대체하고, UserRepositoryImpl은 실제 DB로 테스트한다.

단위(unit)는 동작(behavior)의 단위다. 격리 대상은 SUT가 아니라 테스트다 ("the unit of isolation is the test not the thing under test"). 테스트끼리 격리되어 있다면 단위 테스트가 DB나 파일시스템과 통신해도 된다.

아래가 보이면 설계 신호다 — 테스트가 아니라 대상을 고친다.

• mock이 mock을 반환한다 / mock이 너무 많다 → code smell
• static 메서드를 모킹해야 한다 → 그건 static이 아니어야 한다
• stub한 메서드를 verify한다 / 호출 횟수를 검증한다 → CQS 위반 의심
• 클래스 격리를 위해 모든 의존성을 mock으로 채운다 → 단위 개념 오해

모킹 자체를 줄이는 설계: 복잡한 로직을 순수 함수로 분리하면 stubbing·verify가 사라진다 (segregate-functional-core 스킬 참조).

OUTPUT FORMAT

실행 흐름

Step 1: 현재 상태 확인

1. 구현 목록 확인 — web-app은 .feature의 @pending 시나리오 목록(각 Green이 자기 시나리오 태그를 해제하는 이중 루프), general은 앵커 문서 ## 예제 (검산표) 표의 미구현 행(Degenerate→General로 이미 정렬됨)이 원천이다. 구현 중 발견되는 필요한 동작은 발견 즉시 목록에 추가한다(../../references/anchor-update.md의 "테스트 목록 갱신") (--full로 작성한 경우 ../tdd-plan/references/full-plan.md의 unit test 목록이 그 원천)
2. 첫 미완성 테스트(- [ ]) 식별
3. 현재 테스트 실행 상태 확인
4. 기어 결정: --gear 파라미터 > 템플릿 문서의 기어 기록 > 기본 low 순으로 결정. references/gears.md를 Read로 읽어 폭발 반경(blast radius) 점검을 수행하고, high-stakes 영역이면 두 처방을 함께 출력한다 — 한 단 낮은 기어 권장(사용자 결정)과 완료 시 적대적 리뷰 1회 실행 (기어 무관). 경고를 출력한 경우 사용자의 기어 확정 응답을 기다린 뒤 진행한다. 적대적 리뷰가 예정되면(high 기어이거나 폭발 반경(blast radius) high-stakes) 현재 HEAD 해시를 진행 기록에 남긴다 — 리뷰 diff 기준점이다. --gear로 명시 지정되었거나 문서의 기존 기록과 다를 때만 진행 기록을 갱신 — --gear 미지정 + 기록 없음이면 low로 동작하되 문서는 변경하지 않는다(하위 호환).

Step 2: RGB 사이클 실행

low·mid 기어: 각 미완성 테스트(- [ ])에 대해 아래 Red→Green→Blue 사이클을 반복한다.

high 기어: 테스트 단위로 사이클을 반복하지 않는다. use case에 속한 모든 테스트에 대해 Red를 전부 마친 뒤, 전부에 대해 Green을 마치고, 마지막에 Blue를 use case 범위로 한 번 수행한다 — 아래 Red/Green/Blue 단계 설명은 각 phase 내부에서 에이전트에게 위임하는 방식을 다루고, 전체 순서와 커밋 지점은 "use case 완료 시" 섹션(3-phase 실행 순서)이 정본이다.

Red 단계

• tdd-red agent에 위임
• 실패하는 테스트 작성 — Test Desiderata 준수 (12가지 속성 전체는 references/test-design-principles.md)
• 테스트 추가 후 구현 방향을 즉시 결정할 수 없으면 Getting Stuck으로 간주 — tdd-green의 "Getting Stuck 복구 경로"(더 단순한 테스트로 후퇴 우선)를 따른다. 후퇴 결정은 Red/Green 경계를 넘으므로 오케스트레이터가 인지하고 조율한다. 후퇴가 발생하면 진행 기록에 남긴다(특히 mid/high 기어 자율 진행 중에는 사용자가 최종 검토에서 볼 수 있도록)
• approved.txt 파일 생성 (필요 시)
• low·mid: 에이전트 내에서 test: 접두사로 커밋 수행 / high: 커밋 보류(git add까지만)
• 검토 지점이면 사용자 피드백 대기 (low: 매 phase 후 / mid·high: 대기 없이 다음 phase)

Green 단계

• tdd-green agent에 위임
• 최소 구현으로 테스트 통과 (Little Golf Game)
• TPP (Transformation Priority Premise) 적용
• Make-it-Work 전략 (Obvious / Fake it / Triangulation)
• 테스트가 성공하면 javadoc comment의 테스트 항목에 완료 표시('X')
• low·mid: 에이전트 내에서 feat: 접두사로 커밋 수행 / high: 커밋 보류(git add까지만)
• 검토 지점이면 사용자 피드백 대기 (low: 매 phase 후 / mid·high: 대기 없이 다음 phase)

Blue 단계

• tdd-blue agent에 위임
• Tidying Process — Composed Method 지향 리팩토링. 단계 목록과 순서는 ../../agents/references/tidying-process.md가 유일한 정본이다(여기서 재나열하지 않는다). Domain Logic 이동(다른 클래스로 옮기는 분리)은 Blue 범위 밖 — /system-wide-refactoring 전담.
• 변경이 있는 경우 low·mid는 에이전트 내에서 refactor: 접두사로 커밋 수행 / high는 커밋 보류(git add까지만)
• 검토 지점이면 사용자 피드백 대기 (low: 매 phase 후 / mid·high: 대기 없이 다음 phase)

사이클 완료 시 (low·mid 기어 — 테스트 1개의 R→G→B 종료)

• 테스트 목록 갱신 확인 (다음 Red 전) — 세 에이전트 보고의 목록 추가: 필드를 모은다. 자율 추가 항목은 문서에 행이 있는지 확인하고, 규칙이 바뀌는 항목은 사용자에게 질문한 뒤 반영한다. 필드가 없는 보고는 그 에이전트에 재확인한다. 다음 Red는 갱신된 목록에서 Degenerate→General 순서로 고른다
• mid 기어: 여기가 검토 지점 — 사이클 요약(테스트·구현·리팩토링)과 사이클 diff를 함께 제시하고 사용자 피드백 대기. tidying 방향 지시(추가 리팩터링 지목)를 받으면 반영 후 재보고
• 기어 전환 점검 (low·mid): references/gears.md의 업/다운시프트 신호를 점검하고, 감지 시 전환을 제안 — 전환을 제안한 경우 사용자 응답을 기다린 뒤 진행한다(제안만 출력하고 지나가지 않는다). 사용자가 수락하면 템플릿 문서의 기어 기록을 갱신하고 다음 사이클부터 새 기어 적용
• 폭발 반경(blast radius)이 사이클 도중 처음 감지되면(그 영역에 이제야 진입) 두 처방을 그때 적용하고, diff 기준점은 이 작업의 첫 커밋의 부모를 남긴다 — 감지 시점 HEAD를 남기면 리뷰 diff가 그 이전 구현을 포함하지 못한다("리뷰 diff가 전체 구현을 포함해야 한다"). 이미 기록된 기준점이 있으면 갱신하지 않는다

use case 완료 시 (high 기어 전용 — 3-phase 실행 순서 + 커밋 지점)

high 기어는 use case를 테스트 단위가 아니라 **phase 단위(Red 전체→Green 전체→Blue 전체)**로 진행한다. 협력 객체가 다수 관여하는 use case에서도 phase를 끝까지 마친 뒤 실행한다.

1. Red 전체 — use case의 미완성 테스트(- [ ]) 각각에 대해 tdd-red를 순차 위임한다. 각 위임은 그 테스트 하나의 실패 테스트만 작성하고 커밋 보류(git add까지만). 모든 테스트를 다 쓴 뒤 스위트를 실행해 신규 테스트 수만큼 의도한 실패인지 확인한다.
2. 커밋 1 (test:) — git add 누락분 확인 후 커밋. subject test(<범위>): <use case 이름> — 실패 테스트 작성. body에는 이 use case가 검증하려는 행동들과 테스트를 그 순서로 고른 근거(Gherkin·도메인 규칙과의 대응)를 담는다. 진행 기록 체크박스는 아직 갱신하지 않는다 — 전부 [ ]로 남는다(아직 실패 상태이므로).
3. Green 전체 — 같은 순서로 tdd-green을 순차 위임한다. 위임 prompt에 "최대한 절차적으로"를 명시한다 — 이 phase는 추출·일반화를 하지 않고 통과만 시킨다(tdd-green의 평소 최소 구현 원칙에 이 제약을 추가하는 것 — 정리는 Blue phase에서 한 번에 한다). 커밋 보류. 전체 완료 후 스위트 전부 green을 확인한다.
4. self-check (Green 커밋 전) — 커밋할 diff가 이미 추출된 private 메서드·이름 붙은 중간 변수를 여럿 갖고 있다면(Composed Method 형태), "Blue가 정리할 게 없다"로 넘기지 말고 Green 위임 자체를 의심한다 — tdd-green에 실제로 위임했는지, 참조 구현이나 최종 형태를 그대로 옮겨 쓰지 않았는지 확인한다. 참조 구현을 참고하더라도 3단계 지시 ("최대한 절차적으로")를 지켜 인위적으로 절차적인 형태로 만든 뒤 커밋한다 — 그래야 Blue 단계가 실제로 할 일이 생기고 refactor: 커밋이 의미를 갖는다.
5. 커밋 2 (feat:) — git add 후 커밋. subject feat(<범위>): <use case 이름>. body에는 왜 이 구현을 택했는지·배제한 접근을 결정별로 담는다. 진행 기록의 그 use case에 속한 모든 체크박스를 [x]로 갱신해 같은 커밋에 담는다.
6. Blue 전체 — tdd-blue에 이 use case 범위 전체(커밋 2 이후 변경된 파일 목록)로 위임한다. Composed Method 지향 Tidying Process를 적용. 커밋 보류. 적용 후에도 스위트 green 유지를 확인한다.
7. 커밋 3 (refactor:) — 변경이 있으면 git add 후 커밋. subject refactor(<범위>): <use case 이름> — tidying. body에는 tidying이 무엇을 드러냈는지. 변경이 없으면(이미 깔끔하면) 커밋 3은 생략한다.
8. 추가 항목 pass — 1·3·6의 에이전트 보고에서 목록 추가: 항목을 모은다. 규칙이 바뀌는 항목은 사용자에게 질문해 확정한다. 확정된 추가 행이 있으면 그 행만 대상으로 1~7을 한 번 더 실행한다(커밋 최대 3개 추가, subject에 "추가 항목" 명시). 추가가 없을 때까지 반복한다

각 phase 내부(1, 3, 6)에서 테스트 사이 대기·피드백 요청은 없다. phase 경계에서도 대기하지 않는다 — 검토 지점은 여전히 "전체 테스트 목록 완료 + 적대적 리뷰 통과 후" 1회뿐이다.

use case 경계를 넘겨 합치지 않는다 — 두 use case를 같은 phase 커밋에 담으면 "이 phase가 이 use case에 대해 무엇을 했는가"라는 리뷰 단위가 성립하지 않는다. 이것이 high 기어가 지키는 커밋 경계다.

기어가 use case 도중 바뀌면: high→다운시프트 시 그때까지 stage된 변경을 진행 중이던 phase 기준으로 그 자리에서 한 번 커밋하고(불완전한 use case임을 body에 명시) 낮은 기어의 커밋 단위로 이어간다. →high 업시프트는 이미 커밋된 phase를 그대로 두고, 그 시점 이후 phase부터 3-phase 커밋으로 모은다.

Step 3: 완료 처리

• 체크박스 확인 (- [x]) — 표기는 각 커밋에서 이미 끝났어야 한다("진행 표기 규칙" 참조). 아직 - [ ]인데 대응 커밋이 있으면 그 커밋에서 누락된 것이므로 여기서 채우고, 왜 불일치했는지 확인한다
• 완료 판정은 체크박스만으로 하지 않는다 — low 기어에서는 마지막 테스트가 Red만 된 상태에서도 "모두 [x]"가 성립한다. 전체 스위트 green을 함께 확인한다
• high 기어면 미커밋 변경이 없는지 확인한다 — git status가 깨끗해야 한다. 남아 있으면 마지막 phase(test:/feat:/refactor:)의 커밋이 누락된 것이므로 여기서 커밋한다
• 작업 내역을 마크다운 파일에 반영
• 완료 판정 전 대응 점검 (모든 기어) — 미구현 행 0개(사이클 중 추가 행 포함) + ## 규칙 모든 번호가 테스트 1개 이상과 대응하는지 확인한다. 대응 없는 규칙은 미구현 행으로 추가하고 Step 2로 돌아간다. 정본은 ../../references/anchor-update.md의 "완료 판정 전 대응 점검"
• 진행 기록 대조 (모든 기어) — 전체 완료 시, 체크된 항목과 실제 테스트 코드를 한 번 대조한다. 체크 안 된 항목을 검증하는 테스트가 이미 있거나, 체크됐는데 대응 테스트가 없으면 그 자리에서 바로잡는다. 1차 방어는 Red 커밋의 원자성이지만 (tdd-red의 "테스트 파일과 체크박스 갱신을 같은 커밋에"), 리팩터링 중 테스트가 이동·통합되면서도 어긋나므로 완료 시점에 한 번 더 대조한다. 드리프트는 기어와 무관하게 발생하므로 이 대조는 low·mid·high 모두에서 수행한다
• Web App이면 추가 단계(인수 테스트 완료 확인·JPA Repository 완성·DSL 개선)를 수행한다 — references/web-app-finish.md
• high 기어였거나 폭발 반경(blast radius) high-stakes였다면: 최종 사용자 검토 전에 적대적 리뷰를 실행한다 — references/adversarial-review.md. Web App이면 위 추가 단계를 마친 뒤에 실행한다(리뷰 diff가 전체 구현을 포함해야 하기 때문). green 스위트 + 적대적 리뷰 통과가 이 경우의 Definition of Done. high 기어라면 최종 검토 보고에 표본 정독 대상으로 대표 슬라이스 하나(가장 복잡했거나 후퇴가 있었던 것)를 추천해 함께 제시
• 하드닝 제안 (실행 아님, 모든 기어): 최종 검토 보고 마지막에 references/hardening-gate.md를 Read로 읽어 그 규칙대로 제안 블록을 추가한다 — CRAP·DRY(빠름, 변경 파일 한정)와 mutation(느림, 파일 1개)을 사용자가 복사해 실행할 수 있는 명령으로. 블록 안의 순서는 비용순이 아니라 파이프라인순이다 — ①CRAP·DRY(정리할 곳 찾기) → ②/system-wide-refactoring(정리) → ③mutation(정리된 코드에). ②가 뮤턴트 지점을 바꾸므로 ③이 마지막이다. 적용 조건(Java·src/main 변경 존재, CRAP·mutation은 추가로 Maven 필요) 미충족 시 생략 사실만 한 줄 보고. 자동 실행 금지.
• 세션 프로파일 안내 (전체 완료 시, 모든 기어): 하드닝 제안 다음 줄에 "/tdd-profile — 이 세션의 단계·에이전트별 시간·토큰과 model/effort 조정안" 한 줄을 추가한다. 실행은 사용자가 한다(transcript 사후 분석이라 세션이 끝난 뒤가 정확하다)
• 다음 테스트 안내 또는 전체 완료

---

작업 내역 기록 형식

각 테스트를 구현할 때마다 템플릿 문서에 작업 내역을 남긴다 (Step 2의 사이클과 함께 수행):

• 각 테스트에 대한 작업 내역을 ### n.x 레벨로 추가
• multiline git commit message 수준으로 작성
• "gutter test 추가"처럼 제목을 작성하고, 빈칸 넣고, 주목할 내용 2~3줄
• code는 markdown 파일에 추가하지 않음

---

조건부 절차 — references

아래 절차는 조건이 맞을 때만 실행되므로 본문에 두지 않는다. 해당 시점에 Read로 읽는다.

절차	언제	정본
적대적 리뷰	high 기어 또는 폭발 반경(blast radius) high-stakes. 전체 green 후, 최종 사용자 검토 전	references/adversarial-review.md
Web App 추가 단계	Web App이고 모든 테스트 완료 후 (인수 테스트 확인·JPA Repository 완성·DSL 개선)	references/web-app-finish.md
하드닝 제안 (실행 아님)	전체 완료 처리(Step 3) 시, 최종 검토 보고 마지막 (모든 기어)	references/hardening-gate.md

둘 다 해당하면 Web App 추가 단계를 먼저 마친 뒤 적대적 리뷰를 실행한다 — 리뷰 diff가 전체 구현을 포함해야 하기 때문이다.

references/adversarial-review.md는 tdd-feature가 그대로 참조하는 정본이기도 하다.

FAILURE CONDITIONS

단계별 검증 체크리스트

1. 테스트 작성 후 확인

• 테스트가 명확한 하나의 동작만 검증하는가?
• 테스트 이름이 검증하려는 내용을 명확하게 설명하는가?
• approved.txt 파일이 필요한 경우 작성되었는가?
• 테스트가 실행되고 예상대로 실패하는가?

2. 구현 후 확인

• 테스트를 통과하는 가장 단순한 구현인가?
• make-it-work-strategy, TPP 규칙의 단계를 적절히 적용했는가?
• 불필요한 코드가 없는가?
• 모든 테스트가 통과하는가?

3. 리팩토링 후 확인

• 중복이 제거되었는가?
• 코드가 더 명확해졌는가?
• 모든 테스트가 여전히 통과하는가?

4. 전체 과정 후 확인

• 작업 내역이 마크다운 파일에 반영되었는가?
• 다음 단계 진행을 위한 피드백을 요청했는가?
• (모든 기어) 진행 기록의 체크박스와 실제 테스트가 일치하는가?
• (모든 기어) 사이클 중 발견한 필요한 동작이 목록에 추가되었고, 모든 규칙이 테스트와 대응하는가?
• (high 기어 또는 폭발 반경(blast radius) high-stakes) 적대적 리뷰를 실행하고 결과를 보고했는가?
• (high 기어 또는 폭발 반경(blast radius) high-stakes) 시작 커밋 해시가 진행 기록에 있는가?
• (high 기어) 커밋이 test:/feat:/refactor: 3-phase(tidying 불필요 시 2-phase)로 남았고, git status에 미커밋 변경이 없는가?
• (모든 기어) 하드닝 제안 블록을 최종 검토 보고에 붙였는가(적용 조건 미충족 시 생략 사유 한 줄)? 하드닝 도구를 자동 실행하지 않았는가?
• 앵커와 어긋난 코드 변경을 앵커 갱신 없이(또는 다른 커밋으로) 커밋하지 않았는가?