docs: record the 1.1.0 release and add the infrastructure map

Release notes for 1.1.0 were split between an Unreleased section and the
version section, so the published notes would have omitted the update-feed
and desktop changes. Everything shipping in this version now sits under one
`## [1.1.0]` heading.

`docs/map/` becomes the entry point for what infrastructure exists per
platform and how far each feature is developed, with a documented update
protocol so feature work and this map do not drift apart again. The release
guide now states that installer binaries live in the update feed rather than
the repository.

docs/tdd-red/00-README.md

@@ -0,0 +1,77 @@
+# TDD-RED 프레임워크 · 2026
+
+**"RED" 를 원론·증거·의견 기준으로 총체적으로 파악하고, 의미 있는 RED와 의미 없는 RED를 분리하고,
+없는 것(가짜/의례적 RED)을 삭제하고, 흩어진 테크닉을 통폐합·구조화하고, 긴 시나리오로 재구성한 실행 프레임워크.**
+
+> 작성 기준: Sep 2026. 2026년 전반~9월 자료(핵심은 2026-08 사전인쇄·Spec Kit v1.0.0) + 원론(Beck/Fowler/DHH 등) + 2026 생성형 AI 에이전트 시대 자료.
+> 리서치 물량: **약 94개 외부 출처 정보 항목**(정확히 100개 번호, 일부 종합 링크 포함) / 14개 원문 1차 소스는 Playwright(headless → headful 폴백)로 직접 스크랩.
+> **레드팀 검증 반영**: 5방면(원론·수치·실용성·일관성·2026최신성)을 거쳐 v1.1로 개정 — 보고서는 `scratch/tdd-red/redteam/01~05*.md`.
+
+---
+
+## 문서 인덱스
+
+| 문서 | 내용 | 한 줄 요약 |
+|---|---|---|
+| `01-principles-and-sources.md` | RED의 원론·이론·논문·주요 인물 의견 전부 파악 | "RED는 무엇인가"의 땅다지기 |
+| `02-meaningful-vs-meaningless-red.md` | **의미 있는 RED vs 의미 없는 RED** 분류표 | 핵심 산출물 1 |
+| `03-cleanup-and-consolidation.md` | 없는/가짜 RED **삭제**, 테크닉 **통폐합**·구조화 | 핵심 산출물 2 |
+| `04-long-scenarios.md` | RED를 **긴 시나리오**(행위 사양)로 재구성 | 핵심 산출물 3 |
+| `05-framework.md` | 실행 프레임워크: 제어 루프·AGENTS.md·체크리스트·게이트 | 핵심 산출물 4 |
+| `SOURCES.md` | 100개 정보 항목(약 94 외부) + 1차 소스 14개 | 증거 자료실 |
+
+---
+
+## 핵심 요약 (4줄)
+
+1. **RED는 "실패하는 테스트를 먼저 쓰는 것"이 아니라, "한 가지 관찰 가능한 행위를 사양으로 명세하고, 그 행위가 없어서 **예상된 이유로** 실패함을 증명하는 것"**이다 (회귀=결함 재현, 특성화=레거시 전처리는 명시적 예외).
+2. **의미 있는 RED** = 행위(behavior)를 하나만, 실제 결함을 잡을 수 있는 단정(assertion)으로, 구현이 아니라 인터페이스/결과를 검증하는 것. **의미 없는 RED** = 단정 없는 가짜 테스트, 구현 세부(내부) 테스트, 전부 목(mock)한 인공 시스템, 커버리지 채우기, 의례적 RED.
+3. **2계층 실행**: 내부 루프(초 단위: RED→GREEN→REFACTOR) + 외부 게이트(GATE=VERIFY+REVIEW+DONE). 레드팀 검증으로 8단계 단일 목록을 폐기하고 단계 순서 모순을 해소했다.
+4. **2026 에이전트 시대**: RED를 "에이전트에게 테스트-퍼스트를 프롬프트로 말하는 것"이 아니라 "**인간이 결정한 수용 기준을 보호 경로로 강제하는 완료 게이트**"로 격상한다. '숨김(held-out)'은 이 환경에서 실행 불가하여 '**보호(protected)**'(고치지 못하게)로 다운그레이드했다.
+
+---
+
+## 근본 정의 (Canon RED, Beck 2023 재확인 + 2026 + 레드팀 정정)
+
+- 테스트 목록(행위 시나리오)을 먼저 **전부** 나열하라.
+- 목록에서 **딱 하나**를 구체적이고 실행 가능한 테스트로 만들고, **실패를 확인하라**(실패 관찰 명문화는 Beck 『TDD By Example』·2026 가이드 결합 — Canon 본문은 실패를 전제만 한다).
+- 그 테스트(+이전 모든 테스트)가 통과하도록 코드를 바꾸되, **가장 단순한 변경**으로.
+- 선택적으로 리팩터(구현 설계 개선) — 행위는 바꾸지 않는다.
+- 목록이 비울 때까지 반복 → **공포가 지루함으로 바뀔 때까지**.
+  - *Beck, "Canon TDD", Dec 2023 / 스크랩 `kentbeck_canon_tdd.txt`* (참고: Canon 본문은 2단계가 '하나를 구체 테스트로'까지이고 실패는 전제만 됨)
+
+---
+
+## 2026 자료 프레이밍 — 정정 (레드팀 실측 반영)
+
+원래 "최근 4개월(2026-05~09)"로 과장됐으나, **실측상 4개월 창 안에 드는 외부 항목은 약 8개(8%)**에 불과하다.
+다수(Google/TotT 03-10, Meta 02-11, Alderson 01-25, Drew Cain 04-09)는 2026년 1~4월 자료다. 아래 표는 실제 시기를 그대로 둔다.
+
+| 항목 | 출처(년) | 핵심 | 증거 등급 |
+|---|---|---|---|
+| VS Code + Copilot 전용 **Red/Green/Refactor 에이전트** 가이드 | 2026(Living) | IDE가 TDD 3상을 에이전트 핸드오프로 공식화 | 공식 문서 |
+| **TDD-Agent** (테스트 먼저 + 실행 피드백 반복) | 2026-08-17 | 저장소 수준 정답률·커버리지·뮤테이션 개선 보고 | **사전인쇄(비피어리뷰)** |
+| **Spec-Driven Development(SDD)** 등장 | 2025~2026 | Thoughtworks Radar 2025 · GitHub Spec Kit · Amazon Kiro · Red Hat | **2차 인용·벤더 수치** |
+| **Google "The Way of TDD"** (TotT) | 2026-03-10 | TDD가 은탄환이 아니라는 공식 인정 | 공식 블로그 |
+| **Meta "Death of Traditional Testing / JiTTests"** | 2026-02-11 | 전통 테스트 유지보수 붕괴 → 즉시생성 테스트 — **RED 승격과 반대 방향(분기)** | 공식 블로그 |
+| **TDD-Agent / TDAD / Spec-driven test gen** 사전인쇄 | 2026-08 | 테스트 품질·독립성·실행 피드백이 양보다 중요 | **사전인쇄** (TDAD 실재 제출은 2026-03) |
+| Alderson "Turns out I was wrong about TDD" | 2026-01-25 | 에이전트가 TDD 경제성을 뒤집음 (단 test-first 순서는 명시 안 함) | n=1 실무 후기 |
+| Emily Bache × Nizar "TDD Guard / Probity" | 2026-07-27 | 에이전트의 TDD 위반(과잉구현·테스트약화)을 **도구로 강제** | 인터뷰 |
+| Drew Cain "TDD Is Out, SDD Is In" | 2026-04-09 | 테스트는 검증, 스펙은 의도 — "올바른 것을 만드는가" (저자·날짜 확인 필요) | 2차 인용 사례 |
+| **합의(2026-09 시점)** | — | "RED를 행위 명세·독립 게이트로 승격"은 2026 신호 **일부 + 원론·실증의 결합** — 전부의 수렴은 아님(Meta JiTTests 등은 분기) | — |
+
+---
+
+## 디렉터리
+
+```
+docs/tdd-red/
+├── 00-README.md                 ← 지금 이 파일
+├── 01-principles-and-sources.md
+├── 02-meaningful-vs-meaningless-red.md
+├── 03-cleanup-and-consolidation.md
+├── 04-long-scenarios.md
+├── 05-framework.md
+└── SOURCES.md                  (100개 정보 항목: 약 94 외부 출처)
+└── 레드팀 검증 → `scratch/tdd-red/redteam/01~05*.md` (5방면)
+```

docs/tdd-red/01-principles-and-sources.md

@@ -0,0 +1,91 @@
+# 01 · 원론·이론·논문·주요인물 — RED 전모 파악
+
+"RED가 무엇인가"를 원론 정의 → 이론·실증 → 주요 인물 견해 → 2026 요약 순서로 정리한다.
+(근거 출처는 `SOURCES.md`의 1~100번 참조. 괄호 안 숫자는 해당 항목 번호.)
+
+---
+
+## 1. RED의 원론 정의 (가장 좁고 정확한 정의)
+
+**RED = "구현 전에, 한 가지 관찰 가능한 행위를 사양으로 명세한 자동화 테스트가, 그 행위의 부재로 인해 **예상된 이유로 실패**함을 증명하는 단계."**  
+(종합 정의다 — "예상된 이유로 실패" 표현은 Beck 『TDD By Example』과 2026 VS Code 가이드의 "fail for the right reason"를 결합한 것. Fowler는 실패 관찰을 직접 명문화하지 않았다 — 레드팀 H-1 정정.)
+
+핵심 요소 (3):
+- **사양**: 테스트 = 실행 가능한 요구사항 (실행 가능 사양, executable specification)
+- **방법**: 실패를 **직접 관찰·검증** (실수로 통과가 아님)
+- **결과**: 인터페이스 설계 결정 (Beck 8, 14) 및 회귀 누적
+
+Beck의 Canon TDD (5): 테스트 목록 나열 → 하나만 구체 테스트→실패 → 최소 구현으로 초록 → (선택) 리팩터 → 목록 빌 때까지.
+*"공포가 지루함으로 바뀔 때까지."*
+
+RED는 "테스트를 먼저 쓰는 일(order)" 이상이다 — **행위 분석(1단계 목록)+실패 증명(2단계)**이 함께 정의된다 (9, 10).
+
+---
+
+## 2. 이론·실증 (무엇이 효과를 만드는가)
+
+**프로세스 메커니즘 (이론)**:
+- RED: 요구를 구현 전 실행 가능 예제로 → 요구 명확화·테스트 가능성
+- GREEN: 작은 행위 증분 → 인지 부하↓·피드백↑
+- REFACTOR: 중복 제거 + 회귀 안전망 → 유지보수성↑
+- 반복: 빈번한 검증 → 조기 결함 검출
+
+**핵심 실증 결론 — "test-first 순서 자체의 효과는 제한적"** (32, 33, 36, 37):
+- 짧고 규칙적인 피드백 주기 + 테스트 강도 + 회귀 누적이 대부분의 이점을 설명.
+- 메타분석: 외부품질에 작은 긍정 효과, 생산성 효과 미미 (34).
+- 6개월 종단: 최종 품질 차이는 없어도 **더 많고 더 나은(결함검출력) 테스트**를 생산·유지 (37).
+- **결론**: RED가 유효한 이유는 '순서'가 아니라 '행위 명세 + 빠른 실패 + 단정 강도 + 회귀'.
+
+**TDD 위협 요인**:
+- 리팩터 생략 (35; Fowler 21)
+- 테스트 품질(단정·경계) 저하 — 개수·커버리지가 아님
+- 과제 복잡성·경험·환경 (36)
+
+**ROI 기준**: 투자 모델(손익분기)이며 절대 상수가 아님 (39, 40). ERICSSON 총비용 5–6%↓ (42, 단 수치 확인 필요), Microsoft+IBM 4팀 결함 40–90%↓·시간 15–35%↑ (41 — 실제 Microsoft 3팀+IBM 1팀).
+
+---
+
+## 3. 주요 인물 견해 지도
+
+| 인물 | 입장 | 한 줄 |
+|---|---|---|
+| **Kent Beck** (창시자) | Canon TDD 정의 제공, 독단 반대, 맥락 의존 | "정의는 정의일 뿐. 행위 하나씩 공포→지루함으로." |
+| **Martin Fowler** | RGR 정의, 자기검증≠TDD, 리팩터 중시 | "테스트를 먼저 쓰고, 깨지면 수정한다"(실패관찰은 Beck·2026 가이드 의 것 — 직접 인용 아님) |
+| **David Heinemeier Hansson** | 독단·목-헤비·설계 왜곡 반대 | "TDD는 죽었다, 테스팅 만세" (2014) |
+| **James Shore** | 프로그래머 몫 테스트 옹호, 수용은 대화 | "수용을 이진 테스트로 환원하면 거짓 확신." |
+| **Marco Arment** | 소규모 제품 관점, 테스트 비용 사례별 정당화 | "과잉 테스트 경계" (2012) |
+| **Vivek Haldar** | 장기 회귀·모듈성 이점 강조 | Arment에 반박 |
+| **John Ousterhout** | TDD가 설계에 역행한다는 비판 | "작은 설계 증분은 best design을 막는다" |
+| **Beck ↔ Ousterhout 논쟁** | 설계는 '언제'의 문제, 균형이 best | "일찍 설계할수록 덜 informed, 늦게 하라" (15) |
+| **Emily Bache × Nizar** (2026) | 에이전트는 TDD 위반 → 도구 강제 | "TDD Guard/Probity" (77–79) |
+| **Martin Alderson** (2026) | 회의론자였다가 에이전트 경제로 전향 (단 test-first 순서는 명시 안 함) | "TDD 쪽이 맞았다, 로봇 주니어 덕분에"; 정작 '테스트를 먼저 쓰라고는 안 했다' (73–76) |
+| **Drew Cain** (2026) | TDD→SDD 전환 | "테스트는 검증, 스펙은 의도" (80–84) |
+| **Birgitta Boeckeler** (Thoughtworks) | SDD | "에이전트는 코드엔 강하고 장기 일관성엔 약하다"(Boeckeler 단독 발언, oleaedge 경유) |
+| **Dave Farley** | ATDD | Bache 글에서 ATDD 관련 간접 언급 (SOURCES 근거 약함) |
+| **Google(TotT 2026)** | TDD 옹호하되 비-은탄환 명시 | "The Way of TDD" — Bartosz Papis (72) |
+
+**역사적 궤적**: 1994 SUnit·1995 OOPSLA 데모(Beck) → 2012 Arment 논쟁 → 2014 "Is TDD Dead"(DHH×Beck×Fowler) → 2017–2025 실증 다기화 → **2025–2026 SDD·에이전트 게이트 시대**.
+
+---
+
+## 4. 2026 (2026년 전반~9월) 합의 — 이전 관점과의 차이
+
+| 차원 | 전통적 관점 | 2026 관점 |
+|---|---|---|
+| RED의 역할 | 프로그래머의 설계 훈련 | **행위 명세 + 독립 검증 + 완료 게이트** |
+| 주체 | 인간 개발자 | 인간이 사양·리뷰, 에이전트가 구현·테스트 생성 |
+| 순서의 강조 | test-first 강조 | **보호 수용 테스트 + 독립 검증 + 짧은 주기** (92, 87–88) |
+| 테스트 생산 | 수작업 | 에이전트가 초 단위 생성 (73) — 품질·독립성만 필수 |
+| 테스트 유지비 | 상시 유지 | JiT 즉시 테스트로 유지비 제거 시도 (Meta 71) |
+| 도구 | IDE·프레임워크 | Spec Kit(SDD·립 계) · VS Code 3-에이전트 · Probity 가드레일 |
+| 실증 | 순서 효과 논쟁 | **품질·독립성·실행 피드백 > 수량** (61–63, 86–87) |
+
+---
+
+## 5. 하나의 종합 정의 (이 프레임워크의 RED)
+
+> **"의미 있는 RED" = 긴 시나리오(행위 사양)에서 하나를 뽑아, 관찰 가능한 결과를 강한 단정으로 명세하고,
+> 구현 없는 상태에서 **예상된 이유로 실패함을 증명**하여 (a) 사양을 명확히 하고 (b) 인터페이스를 설계하며 (c) 이후 구현·회귀를 **게이트**하는 단계.
+> — 에이전트 시대에는 이 '게이트'가 인간이 결정한 수용 기준으로서 **구현 에이전트 밖**에서 강제된다.**
+
+상세 산출물: `02`(분류) / `03`(정리·통합) / `04`(긴 시나리오) / `05`(프레임워크).

docs/tdd-red/02-meaningful-vs-meaningless-red.md

@@ -0,0 +1,76 @@
+# 02 · 의미 있는 RED vs 의미 없는 RED
+
+**목적**: 'RED'라는 이름 아래 흔히 섞여 있는 것들을 "행위를 정말 명세·검증하는가"라는 단일 기준으로 **의미 있음/의미 없음**으로 분리한다.
+판정 원칙 한 줄: *"이 테스트가, 구현을 고치지 않았는데 통과할 수 있는가? 통과해도 아무것도 증명하지 않는가? 그렇다면 의미 없는 RED다."*
+
+---
+
+## 판정 축 (5 기준)
+
+| # | 축 | 의미 있는 RED 는… | 의미 없는 RED 는… |
+|---|---|---|---|
+| 1 | **행위(behavior)** | 공개 인터페이스/관찰 가능한 결과 하나를 명세 | 내부 구현·프라이빗 메서드·호출 순서·데이터 구조 세부 |
+| 2 | **단정(assertion)** | 실제 결함을 잡을 수 있는 강한 단정 | 단정 없음 / 상수 단정 / 커버리지만 채움 |
+| 3 | **실패 이유** | "행위 부재 **또는 결함 재현**" 예상된 이유로 실패 | 컴파일·셋업·문법·무관한 이유로 실패(그래도 빨강) |
+| 4 | **결정성** | 결정적·저비용·재현 가능, 시간/랜덤/네트워크 제어 | 비결정적, flaky, 외부 인프라 의존, 목으로 전부 인공화 |
+| 5 | **의도(설계)** | 테스트를 쓰며 인터페이스 설계를 의도적으로 결정 | 테스트 목록 없이 즉흥, 구현 세부를 그대로 돌려보기 |
+
+> 한 축이라도 "의미 없음"이면 그 RED는 빈 껍데기다. 특히 **(2) 단정**과 **(3) 실패 이유**가 핵심.
+
+---
+
+## 의미 있는 RED (KEEP) — 12가지 **패턴 카탈로그**
+
+> **레드팀 정정**: 아래 12가지는 상호배타적인 '유형'이 아니라, **5축(판정 축)을 충족하는 사례의 패턴 카탈로그**다.
+> 하나의 좋은 테스트는 여러 패턴을 동시에 충족한다(예: #1+#8+#10). "12 중 하나"라기보다 **5축을 모두 충족해야** 의미 있으며
+> 12가지는 그 판정을 돕는 예시다. 특성화(#12)·회귀(#3)는 "행위 부재로 실패" 정의의 **명시적 예외**(레거시/결함)다.
+
+| 패턴 | 설명 | 근거 |
+|---|---|---|
+| 1. **행위 우선 RED** | 한 가지 비즈니스 규칙/관찰 결과를 먼저 명세, 그 행위 없음으로 실패 | Fowler, Canon TDD |
+| 2. **경계·엣지 RED** | 경계값(50원, 49.99원), 빈 입력, null, malformed, 오류 경로, 상태전이 | Microsoft, spec-driven |
+| 3. **회귀 RED** | 결함을 재현(실패 이유=결함 재현) — fix 전에 실패 확인, 정의 예외 | Fowler, Alderson |
+| 4. **인터페이스 설계 RED** | 테스트 작성 시점에 API/시그니처를 의도적으로 결정 | Beck Design-in-TDD |
+| 5. **삼각측량 RED** | 예제를 하나씩 추가하며 일반화를 강제 (Fake→Triangulate→Obvious) | TDD By Example |
+| 6. **결함-검출 잠재력 RED** | "구현이 미묘하게 틀려도 통과할까?"에 NO가 나오는 테스트 | Microsoft, 뮤테이션 |
+| 7. **외부 강제 수용 RED (AI)** | 인간이 쓴 보호 수용 테스트로 에이전트의 완료를 게이트 | 2026 TDD-Agent, TDAD, TDFlow |
+| 8. **블랙박스 RED** | 결과·상태변화·예외·외부 상호작용만 단정, 세부 구현 비의존 → 리팩터에 생존 | fowler_test_pyramid |
+| 9. **Traceable RED** | 요구→수용 시나리오→테스트 ID→파일 추적 가능 | SDD traceability |
+| 10. **설명력 있는 RED** | 이름이 `Withdraw_BalanceInsufficient_Throws` — 실패 시 무엇이 깨졌는지 즉시 | Microsoft, AAA |
+| 11. **독립 검증 RED (AI)** | 구현 에이전트와 분리된 검증자/모델·신선 컨텍스트가 작성 | 2026 권장 루프 |
+| 12. **특성화 (레거시 전처리)** | 기존 동작을 승인/캡처해 리팩터 안전망으로 — **RED 정의의 예외**: 즉시 통과(행위 없음이 아님) | Characterization/Approval |
+
+---
+
+## 의미 없는 RED (DELETE) — 10가지
+
+| 유형 | 증상 | 왜 나쁜가 | 근거 |
+|---|---|---|---|
+| 1. **가짜 RED (fake)** | `expect(true).toBe(true)`, 단정 없음 | 커버리지만 높이고 결함 0 검출 | survey, Microsoft |
+| 2. **사소한 RED (trivial)** | getter·언어기능·프레임워크 반복 테스트 | 결함-검출 가치 없음 | survey |
+| 3. **구현-세부 RED** | 프라이빗 메서드·내부 호출순서·데이터 구조 단정 | 리팩터 때마다 깨져 재작성 → 리팩터를 막음 | fowler_test_pyramid |
+| 4. **인공 시스템 RED** | 전부 목/스텁으로 인공화, 실제 통합 경계 미검증 | 실제 결함을 놓침, DHH의 'test-induced damage' | Is TDD Dead |
+| 5. **복붙 기대값 RED** | 계산 결과를 그대로 기대값에 복붙 | 이중검증 파괴, 자신의 버그를 '정답'으로 고정 | Beck Canon TDD |
+| 6. **커버리지-채움 RED** | 단정 삭제/축소로 위장 초록, %만 올리기 | 은탄환이 아닌 커버리지 | Beck, Google |
+| 7. **의례적(all-at-once) RED** | (단위 계층) 테스트를 전부 먼저 쓰고 구현 — **수용·보호 계층의 사전 작성은 예외** | 첫 테스트가 후속 사양을 무효화하면 대량 낭비 | Beck Canon TDD |
+| 8. **비결정 RED** | 시간·랜덤·네트워크·DB·셰어드 상태 의존 | flaky → 신뢰 상실, zero-tolerance 대상 | Azure WAF, Microsoft |
+| 9. **비대(broad) RED** | 수많은 시나리오를 전 계층에 중복 반복 | 유지보수 폭증, 신호 희석 | Google "No more E2E" |
+| 10. **에이전트 약화 RED** | 테스트 삭제·스킵·비활성·광범위 목 대체·참조 없는 과잉 구현 | 독립 검증 붕괴, 에이전트가 지름길 (주의: #10은 '삭제 대상 테스트'가 아니라 **금지 프로세스 행동** — 판정 워크플로로는 잡히지 않음) | Alderson, Emily Bache/Probity |
+
+---
+
+## 판정 워크플로 (이 테스트를 유지/삭제할까?)
+
+```
+1. 이름이 행위를 명세하는가?           (아니오 → 수정 또는 삭제)
+2. 단정이 결함을 잡을 수 있는가?        (아니오 → 뮤테이션으로 확인 후 삭제)
+3. 깨졌을 때 이유가 명확한가?          (아니오 → 세부 구현 의존 의심)
+4. 구현을 고치지 않고 통과할 수 있는가? (예 → 가짜/사소, 삭제)
+5. 구현 세부(프라이빗/호출순서)를 검증? (예 → 블랙박스로 재작성)
+6. 결정적이고 저비용인가?             (아니오 → 하위 계층으로 이동)
+7. 리팩터(행위 보존)를 견디는가?       (아니오 → 행위 단정으로 재작성)
+전부 YES → 유지 (의미 있는 RED)
+```
+
+> **뮤테이션은 '판정 보조 도구'** (05 §4 정책): 개별 테스트를 매번 뮤테이션으로 판정하면 비용 과다. 대신 리뷰에서 단정이 상수 교체·경계 반전을 잡는지 눈으로 검사하고, 정리(cleanup) 국면·금융/인가/안전 로직에서만 뮤테이션(변경 파일 증분)으로 확인한다.
+> (레드팀 정정: 기존 "최종 판정기" 표현은 05와 모순 — 통일)

docs/tdd-red/03-cleanup-and-consolidation.md

@@ -0,0 +1,90 @@
+# 03 · 삭제(Cleanup)와 통폐합(Consolidation)·구조화
+
+**목적**: 02에서 '의미 없는 RED'로 분류된 것을 **삭제/수정**하고, 흩어진 테크닉·용어·도구적 접근을 **하나의 구조**로 통폐합한다.
+
+---
+
+## 1단계 · 삭제 (없는 것/가짜 것을 제거)
+
+"없는 것" = 행위가 없어서 **존재 이유가 없는** RED. 다음을 명시적으로 제거한다.
+
+- [ ] [02-#1] 단정 없는 `expect(true)` 류 · 태어나서 한 번도 실제 결함을 잡은 적 없는 테스트 삭제
+- [ ] [02-#3] 프라이빗 메서드/내부 구현 세부 테스트 → 제거 또는 블랙박스 행위 테스트로 재작성
+- [ ] [02-#4] 전부 목으로 만든 인공 시스템 테스트 → 실제 경계 통합 테스트로 교체 (단, 순수 로직 계층에 한정 — 네이티브/경계 서비스는 예외)
+- [ ] [02-#5] 복붙 기대값(자기검증 파괴) 테스트 → 손으로 쓴 기대값으로 교체
+- [ ] [02-#6] 커버리지 %만 위한 테스트(단정 축소) 제거
+- [ ] [02-#9] 전 계층에 중복된 동일 시나리오 테스트 → 최저 충분 계층 하나로 축소
+- [ ] [02-#8] 비결정/flaky 테스트 → 격리(owner 지정)·수리·**수리 불가 시 삭제**
+- [ ] [02-추가] 죽은 테스트(실행 안 됨·스킵·영구 스킵·대상 코드 소멸) 삭제 — 02 DELETE에 11번째로 승격
+- [ ] [02-추가] AI 에이전트가 추가한, 이유를 설명할 수 없는 '검증용 더미' 테스트 삭제
+- [ ] [02-#2/#5] 테스트 목록에 없는 즉흥·무의도 구현 세부 테스트 제거
+
+> 삭제 후 **정리 국면**에서는 뮤테이션 점수 회귀 없음을 변경 파일 증분으로 확인(커버리지 말고). 삭제가 행위 보호를 깨면 유지한 채 재작성.
+
+---
+
+## 2단계 · 통폐합 (흩어진 것들을 하나의 축으로)
+
+기존에 별개로 통용되던 개념들을 "출처(사양/행위)"라는 단일 축으로 묶는다.
+
+### 2-1. 테스트 전략 통폐합 → 하나의 포트폴리오
+
+| 통폐합 전 (산재) | 통폐합 후 (하나의 축: 검증 계층) |
+|---|---|
+| unit / integration / e2e / system | **테스트 피라미드**(많은 단위 + 적당한 통합 + 소수 E2E) |
+| TDD / ATDD / BDD / SDD | **Spec → 수용 기준 → 테스트**의 단일 사양 흐름 |
+| approval / golden master / snapshot | **승인 테스트**(대용량 출력 비교) — 용도만 다름 |
+| characterization test | **특성화** = 기존 동작 보호용 승인 (RED 정의 예외) |
+| example / property / contract / mutation | **검증 보강 세트**: 예(가독성)+프로퍼티(넓이)+계약(경계)+뮤테이션(강도) |
+
+### 2-2. TDD 3상 → "RED가 중심인 단일 피드백 루프"로 통합
+
+RED를 독립된 절차가 아니라 **루프의 첫 반복 게이트**로 재배치:
+
+```
+[Spec] → [RED: 행위 하나 명세+실패증명] → [GREEN: 최소구현] → [REFACTOR: 행위 불변 정리]
+     ↑__________________ TRACE/회귀 누적 ___________________│
+```
+
+- 여기서 "RED"는 02의 12가지 **패턴 카탈로그**(5축 충족)에 맞는 테스트만 허용한다.
+- GREEN에서 단정·테스트를 고치지 않는다(two hats).
+- REFACTOR는 행위를 바꾸지 않으며 항상 전체 스위트 초록 유지.
+
+### 2-3. 빨강의 3가지 구현 전략 → 하나의 '진행 규칙'으로
+
+`Fake it → Triangulate → Obvious`를 "**불확실함이 크면 작게, 확신이 있으면 일반 구현**"이라는 하나의 규칙으로 통합. (Beck: Obvious가 확실하면 바로 그것.)
+
+### 2-4. 에이전트 시대 프레임워크와 인간 TDD 통합 → SHORT-SPEC + LONG-TRACE 루프
+
+- **빠른 계층(short loop)**: 단위·통합 테스트 — 에이전트가 로컬에서 초 단위로 실행 (Alderson)
+- **느린 계층(long gate)**: E2E·수용 테스트 — PR/CI에서 실행, **보호 경로**·독립 (Alderson, 2026 TDD-Agent)
+- **사양 계층(spec)**: 수용 시나리오(긴 시나리오) — 올바른 것을 만드는가 (SDD)
+
+---
+
+## 3단계 · 구조화 (용어·책임·소유권 정리)
+
+| 항목 | 확정 |
+|---|---|
+| "**의미 있는 RED**" = 행위·단정·예상된 실패·결정성·의도 5축 충족 (02) | KEEP |
+| "**의미 없는 RED**" = 5축 위반(8종) + 별도 프로세스 금지(2종: 의례적·에이전트 약화) — 02-10가지 | DELETE/수정 |
+| RED의 목적 = **사양 명세 + 독립 검증 + 완료 게이트** (2026 재정의) | 정의 |
+| 테스트의 책임 주체 = **프로그래머** (고객/에이전트 부담 전가 금지) | Shore |
+| 커버리지 = 진단, 뮤테이션 = 단정 강도, 시나리오 커버리지 = 행위 완성 (50–52) | 매트릭스 |
+| 에이전트 테스트 = 초안, 인간 리뷰 필수 (95) | 가드레일 |
+| 테스트 이름 규칙 = `동작_시나리오_기대` (02: 설명력 패턴; SOURCES 46) | 표준 |
+| 구조 = AAA / Given-When-Then (47) | 표준 |
+
+---
+
+## 산출물 요약
+
+```
+의미 있는 RED 12개 ← KEEP
+의미 없는 RED 10개 ← DELETE/REWRITE
+전략 5묶음        ← 통폐합 (피라미드/사양/승인/특성화/검증보강 — 특성화는 승인과 별도 행 유지)
+TDD 3상          ← 단일 루프로 통합
+빨강 3전략        ← 하나의 진행 규칙
+빠른/느린/사양     ← 3-계층 구조화
+8개 용어          ← 확정(구조화)
+```

docs/tdd-red/04-long-scenarios.md

@@ -0,0 +1,99 @@
+# 04 · 긴 시나리오(Long Scenario)로 RED 재구성
+
+**목적**: 무수한 미시(단위) RED를 "사용자가 겪는 **긴 여정(장면)**" 단위로 재구성한다.
+RED(테스트)는 단일 행위의 단일 테스트로 고정하되, 테스트를 **긴 시나리오(행위 사양)에서 파생**시킨다. 장면 단위를 "시나리오/행위 사양", 그에서 나온 테스트를 "미시 RED"로 용어 구분한다.
+이로써 미시 RED 난립을 막고, 행위 완성도(traceability)와 에이전트 제어성을 동시에 얻는다.
+
+---
+
+## 왜 긴 시나리오인가
+
+- **Beck(Canon TDD)의 1단계가 곧 긴 시나리오**: "며칠 동안 안 쓰던 기능까지 전부(행위 변형 목록) 나열하라." 마이크로부터 시작하면 완성도를 놓친다.
+- **Alderson(2026)**: 티켓마다 "구현 전에 **테스트 계획**(통상 사용 + 엣지 + 커버 방식)"을 논의 — 이것이 곧 시나리오 명세.
+- **SDD(2026)**: 수용 시나리오 → 테스트 매트릭스 → Test ID → 파일(추적).
+- **테스트 피라미드(56)**: 행위는 **최저 충분 계층**에서 검증 — 같은 시나리오를 전 계층에 중복 금지.
+- **Shore**: 수용은 "대화"가 본질 — 시나리오는 그 대화를 구조화한 산출물.
+
+---
+
+## 긴 시나리오 템플릿 (Gherkin 계열)
+
+```gherkin
+Feature: (사용자 가치를 하나의 문장으로)
+
+  Scenario: (한 장면의 제목)
+    Given <초기 상태 / 사전조건>
+      And <추가 상태>
+     When <행위/사건>
+     Then <관찰 가능한 결과 1>
+      And <관찰 가능한 결과 2>
+      And <부수 효과/경계/오류 투명성>
+```
+
+**좋은 예** (올바른 것을 만드는가 + 만드는 방법 모두 명세):
+
+```gherkin
+Feature: 계정 잠금
+  Scenario: 반복 실패 후 계정 잠금
+    Given 활성 계정
+      And 4회 연속 로그인 실패
+     When 잘못된 비밀번호 1개 더 제출
+     Then 인증은 실패해야 한다
+      And 계정은 15분 잠금
+      And 보안 이벤트가 기록된다
+```
+
+**원칙**: `Then`은 내부 구현이 아니라 **사용자/외부 시스템이 보는 결과**여야 한다(44).
+=> `freeShippingFlag` 같은 내부 플래그 대신 `배송비 = 0`을 단정.
+
+---
+
+## 시나리오 → 테스트 매트릭스 (long → short 전개)
+
+한 긴 시나리오를 **가장 낮은 충분 계층**의 테스트로 분해하되, 각 미시 RED에 추적 ID를 단다.
+
+| Scenario (long) | 계층 | RED (short) | Test ID |
+|---|---|---|---|
+| 정상 주문 결제 | 단위 | 할인율 계산 정확 | T-101 |
+| 정상 주문 결제 | 단위 | 배송비 경계(49.99/50/100, 음수 오류) | T-102 |
+| 정상 주문 결제 | 통합 | 주문 저장→조회 왕복 | T-201 |
+| 정상 주문 결제 | 계약 | 결제 게이트웨이 계약 | T-301 |
+| 반복 실패 잠금 | 단위 | 시도 카운터·잠금 임계 | T-110 |
+| 반복 실패 잠금 | 통합 | 보안 이벤트 기록 | T-210 |
+| 정상 주문 결제 | E2E(PR) | 로그인→장바구니→결제→확인 (임계 여정만) | T-401 |
+
+- **각 미시 RED는 02의 '의미 있는 RED' 12가지 중 하나여야** 한다.
+- **같은 시나리오를 모든 계층에 중복하지 않는다**(57). E2E에서 결함 발견 시 **최저 계층**에 회귀 추가.
+- **프로퍼티/계약/뮤테이션**을 필요한 곳에 보강(예: 파서·인코더·금융·인가).
+
+---
+
+## 긴 시나리오 × 에이전트 조율 (2026)
+
+```
+1. 스펙(스토리) 작성       ← 인간이 "올바른 것" 결정 (SDD)
+2. 긴 수용 시나리오 명세    ← Given/When/Then, 인간 + 에이전트 논의(Alderson)
+3. 보호(protected) 수용 테스트 ← 보호 경로에 배치·에이전트 수정 차단(92; 숨김은 이 환경에서 실행 불가 — 05 §2 다운그레이드)
+4. RED: 에이전트가 시나리오별 의미 있는 단위 RED 생성
+     · "실제 이 브랜치가 발동하는 실례" 요구(76) — expect(1+1) 방지
+5. GREEN: 최소 구현, 테스트 수정 금지(two hats, 11/100), 가장 단순한 변경(Probity, 78)
+6. VERIFY: 풀 스위트+타입+린트+보안(+뮤테이션)
+7. REFACTOR: 행위 불변
+8. REVIEW: 인간이 **테스트 파일부터** 리뷰(74) → 지름길/삭제 탐지
+9. DONE: 결정적 검사 통과 시에만 — 에이전트 "완료" 주장 불신 (63, 100)
+```
+
+이 긴 시나리오 단위가 곧 **하나의 리뷰 가능한 PR/커밋 크기**가 되도록 태스크를 나눈다. (참고: 한 발 단계의 PR 크기 근거로 쓸 만한 SOURCES 항목은 없음 — 운영 규약으로 결정)
+
+---
+
+## 긴 시나리오 체크리스트 (완성 게이트)
+
+- [ ] 시나리오가 **사용자 가치**를 한 문장으로 담는다
+- [ ] 정상 경로 + 경계 + 오류 + 상태전이 + 인가/보안이 매트릭스에 있다 (53, 89)
+- [ ] `Then`이 관찰 가능한 결과만 단정 (44)
+- [ ] 모든 행위가 추적 ID로 연결된다 (90)
+- [ ] 각 RED가 '의미 있는 RED' 5축 충족 (02)
+- [ ] 보호 수용 테스트가 보호 경로에 있고 에이전트가 수정 못 한다 (92, 05 §2)
+- [ ] 최저 충분 계층에서만 검증, E2E는 임계 여정만 (57)
+- [ ] 결함 발견 시 하위 계층 회귀 추가 (20)

docs/tdd-red/05-framework.md

@@ -0,0 +1,201 @@
+# 05 · 실행 프레임워크 (Framework) — v1.1 (레드팀 반영)
+
+**TDD-RED 프레임워크 v1.1** — Sep 2026 기준. 원론(Beck/Fowler)·증거·2026 에이전트 시대 합의 + **레드팀 검증(5방면) 반영**.
+핵심 변화(v1.0 대비): ① 루프를 **2계층**(내부 루프 + 외부 게이트)으로 분리해 단계 순서 모순 해소, ② '숨김'→'보호'로 다운그레이드, ③ FREEZE를 루프 단계가 아닌 **상비 인프라**로 이동, ④ 뮤테이션을 내부 루프에서 제거·주기 게이트로, ⑤ 인용·수치 오류 전수 교정.
+
+---
+
+## 1. 제어 구조 — 2계층 (정본, 모든 문서의 기준)
+
+```
+[외부] SPEC ── 프로젝트별 사양(수용 기준/긴 시나리오) + 수용 테스트는 보호 경로로
+              │
+[내부 루프 ×N] RED → GREEN → (REFACTOR)   ← 초 단위, 에이전트 로컬, "가장 단순한 변경"
+              │
+[외부] GATE ── VERIFY(기계 검사) + REVIEW(테스트 diff) + DONE(결정적 완료 판정)
+```
+
+- **내부 루프**는 Beck 원형 그대로 초 단위로 회복한다. 실패 증거 → 최소 구현 → 선택 리팩터.
+- **외부 게이트**는 PR/CI 단위. 기계 검사·테스트 diff 리뷰·완료 판정을 한 게이트로 통합.
+- 하나의 8단계 번호 목록을 폐기한다 — 단계 수가 문서마다 4~9로 갈라지던 원인.
+
+### 세부 절차
+
+| 단계 | 내용 | 수준 |
+|---|---|---|
+| **SPEC** | 요구를 관찰 가능한 수용 기준(긴 시나리오)으로. 이 프로젝트는 `docs/design/*` 을 정본으로 그로부터 Gherkin을 파생(충돌 시 design이 우선). 수용 테스트는 보호 경로에 1회 배치(상비 인프라, 매 루프 아님) | 외부 |
+| **RED** | 행위 하나를 의미 있는 테스트로, 구현 전 **예상된 이유로 실패함을 증명**. 단위 계층은 실패 증거를 먼저 | 내부 |
+| **GREEN** | 가장 단순한 변경. 실패한 테스트를 수정/약화/삭제/스킵하지 말 것 | 내부 |
+| **REFACTOR** | 행위 불변 구조 정리(선택). 내부 루프 내에서 수행 | 내부 |
+| **VERIFY** | 기계 검사: 영향받은 워크스페이스 스위트+타입체크+린트+보안. **풀 스위트는 CI 전담**. 증분 뮤테이션(변경 파일만, 주기/게이트) | 게이트 |
+| **REVIEW** | **테스트 파일부터** 리뷰 — 약화·삭제·스킵·하드코딩·무관변경 탐지. 독립 모델/신선 컨텍스트 권장 | 게이트 |
+| **DONE** | 결정적 검사 통과 시에만 완료 인정. 에이전트 "완료" 주장 불신 | 게이트 |
+
+---
+
+## 2. 보호(Protected) 수용 테스트 — '숨김'의 현실적 다운그레이드 (레드팀 공격 2·3 반영)
+
+**문제**: "숨김(held-out) 수용 테스트를 에이전트 컨텍스트 밖에"는 솔로+에이전트 환경에서 **실행 불가** —
+같은 repo면 Grep으로 읽히고, 별도 repo는 유지비가 가치를 초과하며, 추적성(매트릭스 공개)과 상호모순.
+
+**해법 — '숨김' → '보호': 목표를 "읽지 못하게"가 아니라 "**고치지 못하게**"로 재정의.**
+
+구현(1회 설정, 상비 인프라):
+1. `tests/acceptance/**` 에 대해 Claude/Codex 거버넌스 `deny` 규칙(Edit/Write 차단).
+2. CODEOWNERS + 브랜치 보호로 해당 경로 변경 시 인간 승인 강제.
+3. CI에서 "acceptance 경로 diff가 있고 스펙 커밋 태그가 없으면 실패" 검사.
+4. 보호 경로 무결성 체크를 게이트에 포함.
+
+범위 차등화: 임계 여정 3~5개(라이선스, 결제/정산 등)만 보호, 나머지는 일반 스위트.
+추적성 규칙: 보호 테스트는 T-### 매트릭스에 **존재·ID만** 기록하고 Then 상세는 기록하지 않는다.
+
+---
+
+## 3. 의미 있는 RED 스펙 (단일 테스트 최소 기준)
+
+| 항목 | 실제 값 |
+|---|---|
+| 이름 | `동작_시나리오_기대결과` (예: `Withdraw_BalanceInsufficient_Throws`) |
+| 구조 | AAA 또는 Given-When-Then |
+| 단정 | 결함-검출 가능, 관찰 결과만 (내부 X) |
+| 계층 | 최저 충분 계층 (E2E는 임계 여정만) |
+| 결정성 | 시간·랜덤·네트워크·DB 주입/제어, 저비용 |
+| 실패 이유 | "행위 부재 **또는 결함 재현**" 하나만 (회귀·특성화 예외 포함) |
+
+**판정**: 테스트 별개 유형이 아니라 **5축(행위·단정·실패이유·결정성·의도, +계층 경제성) 충족 여부**로 판정하며,
+아래 12가지는 이 5축을 충족하는 **패턴 카탈로그**(상호배타 분류가 아님)다.
+
+**의미 있는 RED 패턴 카탈로그 (KEEP 12)**: 행위 우선 · 경계·엣지 · 회귀(결함 재현) · 인터페이스 설계 · 삼각측량 ·
+결함-검출 잠재력 · 외부 강제 수용 · 블랙박스 · Traceable · 설명력 · 독립 검증 · 특성화(레거시 전처리 예외).
+
+**의미 없는 RED (DELETE)**: 가짜(단정 없음 `expect(true)`) · 사소 · 구현-세부 · 전부 목 인공화 · 복붙 기대값 ·
+커버리지 채움 · 의례적(단위 계층 한정; 수용 계층 사전 작성은 예외) · 비결정/flaky · 전 계층 중복 ·
+에이전트 약화/과잉 구현(+프로세스 금지 행동 2종 분리).
+
+> 특성화 RED는 엄밀히 "RED 이전의 레거시 안전망(전처리)"이다 — 기존 동작 캡처로 **즉시 통과**하므로
+> "행위 부재로 실패" 정의의 예외로 처리한다.
+
+---
+
+## 4. 뮤테이션 정책 (레드팀 공격 4 반영)
+
+- **내부 루프에서 제거.** RED 1건마다 뮤테이션은 비용이 10~100배 과소평가(파일당 뮤턴트 30~200 × 수십 초).
+- **주기 게이트로 이동**: PR 게이트에서 **변경된 파일만** 증분 뮤테이션(`--mutate` diff 스코프, incremental), 전체는 nightly.
+- **적용 범위**: vitest/Jest 워크스페이스에 한정, .NET(Stryker.NET)·Deno는 도구 성숙도로 **명시 제외**.
+- §8 지표 철학과 정합: 뮤테이션은 "측정 도구"지 "완료 게이트"가 아니다. §3 최소 기준의 뮤테이션 행 삭제 —
+대신 리뷰에서 단정이 상수 교체·경계 반전을 잡는지 **눈으로 검사**하는 저비용 대체.
+
+---
+
+## 5. 긴 시나리오 → 테스트 매트릭스 (구현 주문)
+
+```gherkin
+Feature: 계정 잠금
+  Scenario: 반복 실패 후 잠금
+    Given 활성 계정 And 시도 4회 실패
+     When 잘못된 비밀번호 1개 더 제출
+     Then 인증 실패 And 15분 잠금 And 보안 이벤트 기록
+```
+
+| Scenario | 계층 | RED | ID |
+|---|---|---|---|
+| 반복 실패 잠금 | 단위 | 카운터·임계 | T-110 |
+| 반복 실패 잠금 | 통합 | 보안 이벤트 기록 | T-210 |
+| 정상 로그인 | E2E | 로그인 여정 | T-410 |
+
+ID 규칙: 백의 자리=계층(1단위 2통합 3계약 4E2E), 십의 자리=시나리오. 정본 매트릭스는 `04-long-scenarios.md`에
+있으며(05는 발췌·확장), 같은 시나리오를 전 계층에 중복하지 않는다.
+
+---
+
+## 6. 2026 에이전트 보강
+
+- **보호 수용 테스트**를 에이전트가 수정 못 하게 강제 (§2).
+- **독립 검증**: 테스트 작성/리뷰는 구현과 다른 모델·신선 컨텍스트 권장(조용히 동시 작성은 금지 — 단위 RED 생성 후
+  GREEN 수행하는 표준 플로우는 실패 증거만 먼저 제시하면 허용).
+- **추가 검증 보강**: 프로퍼티(넓이) · 계약(경계, Pact S-96) · 뮤테이션(단정 강도) 필요 시.
+- **TDD 위반 도구 강제** (Probity/TDD Guard류): 스킵·과잉구현·테스트 약화 자동 감지.
+- **에이전트 생성 테스트 = 초안**: 인간 리뷰 필수.
+
+> 주의: 2026 신호는 방향이 **수렴만**이 아니다. Meta JiTTests(항목 71)는 "전통 테스트의 죽음 → 유지보수 없는
+> 즉시생성 테스트"로 **반대 방향**이다. 이 프레임워크는 그중에서도 "인간이 결정한 수용 기준을 게이트로"라는
+> 견해를 선택한 것임을 명시한다(증거 등급: TDD-Agent/+9.8pp/TDFlow 등은 2026-08 사전인쇄·n=1·2차 인용 — 피어리뷰
+> 연구와 별개 등급으로 취급).
+
+---
+
+## 7. TRIAGE — 모든 변경이 RED 대상인가? (선별 규칙, 계약 0단계)
+
+"모든 행위 변경에 강제"라는 무조건 문구를 폐기하고, 아래 선별 표를 AGENTS.md 첫 항목으로 둔다.
+
+| 상황 | 방법 |
+|---|---|
+| 행위 명확·구현 어려움 | TDD-RED (내부 루프) |
+| 프로덕션 버그 | 실패하는 회귀 RED 먼저 |
+| 안정 도메인 규칙 | RED/예제 우선 |
+| 설계·기술 미지 | 스파이크 후 정리하고 테스트 |
+| 시각 UI 탐색 | test-last(컴포넌트·접근성·E2E 강조) |
+| **린트/타입으로 집행되는 정적 규칙 준수 변경** (console.log 제거, 토큰 교체 등) | RED 면제 — VERIFY(린트)만 통과 (D3RO 규칙) |
+| AI가 코드·테스트 둘 다 생성 | 독립 테스트 + 리뷰 + 뮤테이션/프로퍼티 |
+| 레거시 대규모 변경 | 특성화(characterization) 우선 |
+| 네이티브/프로세스 경계 서비스 (Electron 메인, STT/TTS) | 어댑터 계약 테스트(경계만 목) + 스모크 — "전부 목 금지"는 순수 로직 계층에만 적용 |
+| UI 텍스트 단정 | t-key 수준에서 (i18n SSOT 하의 '관찰 가능한 결과' 대리자) |
+| 싱글톤/EventEmitter 서비스 | Determinism 위해 설계서 차원의 `resetForTest()` 훅 추가 |
+
+---
+
+## 8. AGENTS.md 정책 (저장소 계약 — 2계층 + 게이트 반영)
+
+```markdown
+# TDD-RED 정책 (v1.1)
+
+## 원칙
+- 테스트는 행위(behavior)를 검증한다. 구현 세부·프라이빗·호출순서·데이터 구조는 금지.
+- RED는 "테스트가 이미 구현된 상태에서 통과하거나, 예상된 이유 외로 실패해도" 무효.
+- 같은 턴에서 테스트와 구현을 "조용히 동시에" 쓰는 것을 금지 — 반드시 실패 증거를 먼저 제시.
+- 특성화(레거시)·회귀(결함)는 RED 정의의 명시적 예외.
+
+## TRIAGE (0단계): §7 선별 표에 따라 이 변경이 RED 대상인지 판단.
+- 린트/타입으로 집행되는 규칙 준수 변경·시각 UI 탐색 등은 RED 면제(사유 기록).
+
+## 프로세스
+1. SPEC  : 요구를 Given/When/Then 수용 시나리오로. docs/design이 정본이면 그로부터 파생.
+2. RED   : 행위 하나를 의미 있는 테스트로. 실행해 예상된 이유로 실패함을 출력으로 증명.
+3. GREEN : 가장 단순한 변경. 실패한 테스트를 수정/약화/삭제/스킵하지 말 것.
+4. REFACTOR: 행위 보존, 영향받은 스위트 초록 유지.
+5. GATE  :
+   a. VERIFY: 영향받은 워크스페이스 스위트+타입체크+린트+보안 (풀 스위트는 CI 전담). 증분 뮤테이션(변경 파일만, 게이트).
+   b. 보호 경로(`tests/acceptance/**`) 무결성 — 에이전트는 해당 경로를 수정·삭제 금지.
+   c. REVIEW: 테스트 파일부터 diff 리뷰(약화·삭제·스킵·하드코딩·무관변경 확인).
+   d. DONE : 결정적 검사 통과 시에만. "완료" 주장은 검사 없이는 인정 안 됨.
+6. REPORT: 변경 파일 / 실행 명령 / 구현 전 실패 증거 / 최종 결과 / 미해결 위험·가정.
+
+## 금지(가드레일)
+- 기존 테스트 삭제·스킵·비활성·광범위 목 대체. 보호 경로 수정.
+- 참조되지 않는(과잉) 구현 추가. `expect(true)` 식 단정, 복붙 기대값.
+- "완료" 주장 — 결정적 검사 통과만 인정.
+```
+
+---
+
+## 9. 성공 기준 (ROI / 품질)
+
+실증 코어(34, 36, 37, 42 계열): TDD는 "품질 향상은 확률적, 생산성은 맥락 의존". **절대 수치가 아닌 내부 파일럿**으로 ROI 판단.
+- 결함-검출 능력(뮤테이션 점수) · 회귀 미검출 · flaky율 · 리드타임 · 리뷰 시간 단축을 측정.
+- 커버리지% 가 아니라 "이 테스트가 뮤턴트를 죽이는가"를 **측정 지표**로(게이트는 아님).
+- 특정 벤더·개인 수치(Kiro, Red Hat, n=1)는 2차·마케팅 증거로 무게 차등.
+
+---
+
+## 부록 · 즉시 적용용 미니 프롬프트
+
+```
+지시: 작업을 2계층 TDD로 수행. (RED 대상이면)
+1. 저장소 컨벤션·테스트 명령 확인.
+2. 요구를 observable 수용 기준으로 재진술 (docs/design이 정본이면 그로부터 파생).
+3. RED: 테스트 하나 추가하고 실행 → 예상된 이유로 실패함을 보여라.
+4. GREEN: 가장 단순한 최소 변경. 테스트를 수정/약화/삭제하지 말 것.
+5. REFACTOR: 행위 불변.
+6. GATE: 영향받은 스위트+타입+린트 실행 → 보호 경로(tests/acceptance) 미접촉 확인 → 테스트 diff 리뷰 → 결정적 완료.
+7. 보고: 변경 파일/명령/구현 전 실패 증거/최종 결과/위험·가정.
+```

docs/tdd-red/REDTEAM-AUDIT.md

@@ -0,0 +1,67 @@
+# 레드팀 검증 · 종합 보고 & 조치 로그
+
+- 검증일: 2026-09-02
+- 방식: Orca 멀티에이전트 감독 오케스트레이션 — 5개 독립 claude 워커를 같은 워크트리에 디스패치
+- 워커 산출물: `scratch/tdd-red/redteam/01~05*.md`
+- 본 문서는 5개 리포트를 종합하고, v1.1 문서에 **반영한 사항 / 보류한 사항 / 후속 조치**를 기록한다.
+
+---
+
+## 1차 산출 (레드팀 워커 리포트)
+
+| # | 리포트 | 파일 | 핵심 판정 |
+|---|---|---|---|
+| 01 | 원론·논문 정확성 | `01-theory.md` | HIGH 4 / MED 10 / LOW 8. 논지는 옳으나 원론 인용 위생 약함 (Fowler 오귀속 2건, 날조성 인용 2건) |
+| 02 | 수치·인용 정밀성 | `02-numbers.md` | HIGH 2 / MED 8 / LOW 5. 저자 오귀속(Madeyski), TDAD 날짜 오류 등 |
+| 03 | 실용성·실행성 | `03-practicality.md` | **채택 불가 판정**. 8단계 순서 불일치, 숨김/FREEZE 실행 불가, 뮤테이션 비용 과소평가 |
+| 04 | 내부 일관성 | `04-consistency.md` | HIGH 5 / MED 14 / LOW 12. 제어 루프 순서가 문서마다 4~9단계, 분류 체계 자기모순, 인용번호 8+건 |
+| 05 | 2026 최신성·타당성 | `05-recency.md` | 출처 환각 0건. 단 "4개월 안" 과장(실측 8%), 증거 등급 평탄화 |
+
+---
+
+## 반영 완료 (v1.1 문서 수정)
+
+### A. 구조적 (핵심)
+1. **제어 루프 2계층으로 재정의** (`05` §1): 내부 루프(RED→GREEN→REFACTOR, 초 단위) + 외부 게이트(GATE=VERIFY+REVIEW+DONE). 단일 8단계 목록 폐기 → 문서 간 순서 모순 해소. `00` 핵심 요약·`00` 표·`04` 조율·`05` §2/부록 모두 이 구조 기준으로 정렬.
+2. **'숨김(held-out)' → '보호(protected)'** (`05` §2, `04`, `02` #7): 읽기 차단은 이 환경 불가 → 쓰기 차단(deny 규칙+CODEOWNERS+CI 가드)으로. 임계 여정 3~5개만 보호.
+3. **FREEZE는 단계가 아닌 상비 인프라로** (`05`, `00`): 루프에서 제거, SPEC 시 수용 테스트 보호 경로 배치로 종결.
+4. **뮤테이션을 내부 루프에서 제거** (`05` §4, `02` 판정, `03` 1단계): PR 게이트에서 변경 파일 증분으로, vitest/Jest만. "최종 판정기"→"판정 보조 도구"로 통일.
+5. **TRIAGE를 AGENTS.md 첫 단계로** (`05` §7): "모든 변경 강제" 폐기, §7 선별 표(UI/s파이크/린트 규칙 준수 등 RED 면제)를 계약 0단계로.
+
+### B. 인용·사실 (원론+수치)
+6. Fowler "실패 관찰" 오귀속 정정 → Beck·2026 가이드 종합임을 명시 (`SOURCES` 1~2, `01` §1).
+7. "Practical Test Pyramid" 실제 저자 Ham Vocke·개념 Mike Cohn으로 정정 (`SOURCES` 44/47/56).
+8. Madeyski → **Pančur & Ciglarič (2011)** (`SOURCES` 33).
+9. "IBM 연구" → **Microsoft 3팀 + IBM 1팀** Nagappan et al. (`SOURCES` 41, `01`).
+10. TDAD 날짜 → 2026-03-18 (기존 02-08은 2602.07900과 혼동) (`SOURCES` 62).
+11. Beck "차를 탓" 직접 인용 → 취지만, 직접 인용 아님 (`SOURCES` 25).
+12. Alderson "테스트-퍼스트가 맞았다" 각색 → "TDD 쪽이 맞았다, 정작 test-first는 명시 안 함" (`01` 표, `00` 표).
+13. Thoughtworks "가장 중요한" → "one of the most important" (`SOURCES` 82).
+14. Harness-IF는 TDD 전용 아님 → 지시 준수 일반으로 (`SOURCES` 63).
+15. 항목 87 "≫" 근거 보강: TDFlow 94.3% vs 68.0% 추가 (`SOURCES` 87).
+16. Ericsson 5–6% 수치 미확인 표시 (`SOURCES` 42).
+17. George & Williams "24팀" → 24명(12쌍) (`SOURCES` 31).
+
+### C. 문맥·표시
+18. "최근 4개월(2026-05~09)" 과장 → "2026년 전반~9월"로 정정, 실측표 제공 (`00`, `01` §4).
+19. "100+" → "100개(약 94 외부)" (`00`, `SOURCES`).
+20. Google "총리" → "TotT" 오타 수정 (`01`).
+21. "데베이트" → "논의" 오타 수정 (`04`).
+22. 무출처 `(*)` 항목 52·54에 출처 부여 (`SOURCES`).
+23. 04 인용번호 정정: 46→56, 74→76, 7→11/100, 87→63/100, 무근거 PR크기 인용 제거.
+24. 05 §6 인용번호: (53,47,49)→(53,96,49), §8 (37,45,42)→실증 코어 재조정.
+25. 1차 소스 표 URL 절단 복구 (`SOURCES`).
+
+---
+
+## 보류·후속 조치 (문서만으로는 해결 안 되는 것)
+
+| 항목 | 이유 | 권장 |
+|---|---|---|
+| **D3RO VOICE 착륙 컨벤션** (i18n t-key 단정, resetForTest 훅, 네이티브 경계 계약 테스트, 5중 런타임, 싱글톤 SSOT) | 실용성 레드팀 공격 5 — 프로젝트 고유 결정 | 실제 채택 시 별도 `docs/tdd-red/d3ro-adoption.md` 또는 설계 문서 반영 |
+| **기존 `tests/red/` 27개 파일 이행** | 마이그레이션 경로 미정 | 감사 → 수용급만 `tests/acceptance/` 보호, 나머지 일반 스위트로 |
+| **뮤테이션 도구 설치·범위 확정** | Stryker 미설치, .NET/Deno 제외 | 채택 시 도입 여부 결정 |
+| **oleaedge 저자·날짜, Kiro/Red Hat 원출처, Boeckeler Radar 원문** | 2차 인용, 원문 미확인 | 필요 시 원출처 대조 후 재인용 |
+| **TDD-Agent/TDFlow 사전인쇄 등급** | 비피어리뷰 | 등급 라벨 유지, 피어리뷰 후 갱신 |
+
+> **총평**: 레드팀은 핵심 논지(행위 명세·실패 증명·독립 게이트)와 2026 소스의 실재성을 확인했다(HIGH 대다수가 "원문/이 환경과의 정합성" 문제이지 방향 오류 아님). 수정으로 구조적 결함(순서 불일치·숨김 실행불가·뮤테이션 비용)과 인용 위생(오귀속·날짜·저자)을 해소했다. 초기 상태에서 "채택 불가"였던 프레임워크는 v1.1에서 이 저장소에 적용 가능한 형태로 개정됐다.

docs/tdd-red/SOURCES.md

@@ -0,0 +1,135 @@
+# SOURCES.md — 100개 정보 항목 (약 94개 외부 출처 기반)
+
+1차 소스 14개는 Playwright(headless → headful 폴백)로 직접 스크랩했고, 나머지는 2026-05~09 최신 및 원론 검색으로 수집.
+각 항목은 "정보 항목(사실/주장/원칙)" 단위로 번호를 부여했다.
+
+---
+
+## A. 원론 · 이론 · 논문 (academic / canonical)
+
+1. RED–GREEN–REFACTOR: 실패 테스트를 먼저 쓰고 → 최소 구현으로 초록 → 리팩터(행위 불변)를 반복한다. *(Fowler)*
+2. RED의 본질은 "테스트가 실패함을 **직접 관찰**하는 것" — 실수로 통과하는 게 아님을 검증. *(레드팀 정정: Fowler 직접 언급 아님 — Beck 『TDD By Example』 + 2026 가이드의 'fail for the right reason' 결합)*
+3. Beck의 제1규칙: "자동화 테스트가 실패한 뒤에만 새 코드를 쓴다." *(TDD By Example)*
+4. Beck의 제2규칙: "중복(duplication)을 제거한다." *(TDD By Example)*
+5. Canon TDD 정의: (1) 행위 시나리오 목록 → (2) 목록에서 하나만 구체 테스트로 → (3) 그 테스트+이전 전부가 통과하도록 변경 → (4) 선택 리팩터 → (5) 목록 비울 때까지 반복. "공포가 지루함이 될 때까지." *(Beck, Canon TDD 2023)*
+6. Canon TDD는 "이렇게 해야 함"이 아니라 정의(ref)다 — 다른 방식이 통하면 그걸 써라. *(Beck)*
+7. TDD가 만들어야 할 결과: (a) 이전 동작 유지 (b) 새 동작 정상 (c) 다음 변경 준비 (d) 개발자·동료의 **정당한 확신**. *(Beck)*
+8. 인터페이스 설계 vs 구현 설계 구분 — 테스트를 쓰며 주로 인터페이스 설계 결정. *(Beck)*
+9. 테스트 목록 단계를 빼먹는 실수 — "TDD는 바로 코딩으로 들어간다"는 오해. 행위 분석이 먼저. *(Beck)*
+10. "테스트를 전부 다 써놓고 하나씩 통과시키기"는 퇴행적 — 첫 테스트가 후속 테스트를 무효화하면 낭비. *(Beck)*
+11. 실패하게 만들 때의 실수 3가지: 단정 삭제로 위장 통과, 계산값을 그대로 기대값에 복붙(이중검증 파괴), 초록 만들면서 리팩터 섞기(two hats 위반). *(Beck)*
+12. 리팩터는 "이 세션에 필요한 만큼만", 추상화는 너무 일찍 하지 말 것 — "중복은 힌트지 명령이 아니다." *(Beck)*
+13. 테스트 순서가 경험·결과에 영향을 준다 — "코드는 초기조건에 민감한가?"라는 열린 질문. *(Beck)*
+14. TDD와 설계: 테스트 성공 후 "이 구현을 쉽게 했을 설계는 무엇인가"를 질문 → API 설계 결정 → 어색한 API는 지금 다듬는다. *(Beck, Design in TDD 2025)*
+15. "Best possible design"보다 **균형(Balance)** — 설계는 '언제'의 문제, '하는가 말아야 하는가'가 아님. 일찍 설계할수록 덜 informed. *(Beck)*
+16. TDD Prerequisites(Beck, 'TDD Prerequisites' 2026): 예측 가능한 IO, 중요 시나리오 예측 가능, 빠르고 집중된 테스트, 결정적·저비용 셋업일 때 효율적 — 탐색적/시뮬레이션/5분 변경은 다른 방식. *(스크랩 밖 — Beck 뉴스레터, 정확한 게시일 미확인)*
+17. "Passing tests bore me" — 통과 테스트가 공허하면 구현 세부를 확인하는 것. *(Beck 요약)*
+18. 자기검증 코드(self-testing code) ≠ TDD — 이후에 테스트를 써도 자기검증은 가능하지만 그것은 TDD가 아님. *(Fowler)*
+19. TDD는 단순한 기법이 아니라 프로그래밍·설계 훈련 — 사양+구현+검증+지속 설계 개선의 결합. *(Fowler)*
+20. 모든 결함에 대해 먼저 실패하는 회귀 테스트를 추가하라. *(Fowler)*
+21. 리팩터 스킵은 흔한 TDD 실패 원인 — 통과 코드가 서서히 나빠질 수 있음. *(Fowler)*
+22. DHH "TDD is dead" (2014-04-23): 반대한 것은 **독단(dogma)**, 테스트 자체가 아님. "TDD는 죽었다, 테스팅 만세." *(DHH)*
+23. test-induced design damage: 격리 단위 테스트를 위해 과도한 DI·서비스 객체·인터페이스·어댑터·목 → 이해·변경 어려움. *(DHH, Fowler 전재)*
+24. Mock-헤비 테스트가 인공 시스템을 테스트 — 실제 DB·통합 경계가 더 중요할 수 있음. *(DHH)*
+25. Beck의 반박 취지: 설계 품질 문제는 TDD보다 설계 판단의 탓 — '차를 탓하지 마라'식 직접 인용은 원문에 없음(레드팀 정정). *(Is TDD Dead?)*
+26. 최종 합의: 세 사람 모두 자동 회귀 테스트 지지, TDD는 맥락 의존 — "양쪽을 맹목적으로 따르지 마라." *(Is TDD Dead? 2014)*
+27. Marco Arment (2012): 소규모 제품 개발자 관점 — 테스트 비용을 사례별로 정당화하라. *(Build & Analyze #107)*
+28. Vivek Haldar 반박 (2012-12-12): 회귀 방지·모듈성·자신감의 장기 이점 과소평가. *(Testing Redux)*
+29. James Shore: 수용(acceptance)은 모호하고 사회적이고 협상 가능 — 이진 실행 테스트로 환원하면 거짓 확신. *(2012)*
+30. Shore: 수용은 대화여야, 테스트는 프로그래머 몫(TDD) — Cucumber 처럼 고객에게 부담 전가하는 건 실수. *(2012)*
+31. George & Williams (2004): 프로그래머 24명(=12쌍) 실험 — TDD가 기능 테스트 ~18% 더 통과, 개발시간 ~16% 증가. *(IST 46(5))*
+32. Erdogmus et al. (2005): test-first 참가자가 더 많은 테스트 작성, 테스트 수↑가 생산성↑와 상관 — **test-first 순서 자체보다 테스트 강도**일 수 있다. *(TSE 31(3))*
+33. **Pančur & Ciglarič (2011)**: TDD vs 반복 test-last 통제비교 — 생산성·복잡도·수용성능·커버리지·뮤테이션 점수 유의차 없음 → 이점은 **짧은 주기**에서. *(IST 53(6)). 레드팀 저자 정정: 기존 'Madeyski' 표기는 오류 — Madeyski의 실험은 IST 52(2) 2010으로 별개*
+34. Rafique & Mišić (2013): 27개 연구 메타분석 — 외부품질에 작은 긍정 효과, 생산성 효과는 미미. *(TSE 39(6))*
+35. Fucci et al. (2017): 참가자들이 지시만큼 리팩터를 안 함 — 교재 TDD와 실제 TDD의 괴리. *(IST 89)*
+36. Tosun et al. (2017): 단순 과제에선 TDD 생산성 우위, 복잡 brownfield에선 하락 — 과제 복잡성 조절변수. *(EMSE 22(6))*
+37. Romano et al. (2021): 6개월 종단 — 외부품질·생산성 유의차 없음, 그러나 **더 많은·더 나은 결함검출 테스트**를 생산하고 6개월 유지. *(JSS 176)*
+38. 2016 체계적 리뷰(27편): 내부품질 개선 76%, 외부품질 개선 88%, 생산성 하락 44%. *(IST)*
+39. 2025 tertiary 분석: 8개 TDD 체계적 리뷰 중 모든 리뷰에 공통 포함된 1차 연구는 3%에 불과 → "결과는 선택에 따라 달라진다." *(IST 2025)*
+40. Müller & Padberg ROI 모델: TDD는 투자이며 손익분기점은 생산성 불리 vs 결함제거 효율로 결정. *(KIT)*
+41. Nagappan et al. (2008) 산업 사례: Microsoft 3팀 + IBM 1팀 — 사전 릴리스 결함밀도 40–90% 감소, 초기 개발시간 15–35% 증가. *(EMSE 13(3))*
+42. Ericsson 소개 사례(Damm & Lundberg): 컴포넌트 테스트+TDD로 컴포넌트 결함비율 60–70%→20% 미만(2개 제품·6개 프로젝트). 총비용 5–6%↓는 **전문 미확인(레드팀 M-7)** — 확인 전까지 보류. *(JSS 79, 2006)*
+43. 커플링 효과(coupling effect): 단순 인공결함을 잡는 테스트는 복잡 결함도 자주 잡음 → 뮤테이션의 근거. *(TOSEM)*
+44. The Practical Test Pyramid: 행위를 공개 인터페이스로 검증, 프라이빗/구현세부 금지, 리팩터 시 테스트 재작성 방지. *(레드팀 정정: 실제 저자는 Ham Vocke(Thoughtworks), 개념 원조는 Mike Cohn 'Succeeding with Agile' — martinfowler.com 게재일 뿐 Fowler 저작 아님)*
+45. 테스트 품질 질문: "구현이 미묘하게 틀려도 이 테스트는 통과할까?" → 결함을 잡을 수 없으면 가치 낮음. *(Microsoft)*
+46. 하나의 테스트에 하나의 실패 이유 — 이름·단정으로 무엇이 깨졌는지 즉시 파악. *(Microsoft)*
+47. AAA(Arrange–Act–Assert) 구조 — 긴 Arrange=복잡설계, 긴 Act=여러 행위, 긴 Assert=부실 테스트 지표. *(Microsoft; Given-When-Then은 Fowler)*
+48. 테스트 스멜 용어: 의미 없음(meaningless)/죽은(dead)/사소(trivial)/가짜(fake). *(survey)*
+49. 뮤테이션 점수 = killed / (valid mutants) — 커버리지 대비 "정말 검증하는가"의 지표. *(PIT/Stryker)*
+50. **테스트 강도(test strength)** = killed/(killed+survived) — 커버리지 제외한 단정 강도. *(PIT)*
+51. Oracle gap: 커버리지↑뮤테이션↓ = 코드는 실행하지만 단정·입력이 약함. *(arXiv 2309.02395)*
+52. 커버리지는 주사이고 뮤테이션은 단정 검증 — 절대 수치 강요 금지. *(*)
+53. Property-based test vs example test: 예는 가독성·정확한 기대값, 프로퍼티는 넓은 입력공간 탐색+자동 최소축소. *(QuickCheck)*
+54. 프로퍼티 예: round-trip, idempotence, ordering, conservation. 발견된 반례는 명시 회귀 테스트로. *(QuickCheck/PBT 종합)*
+55. Characterization(기존 동작 고정) vs test-first approval(목표 동작 정의) — 승인 테스트는 두 용도 모두의 도구. *(ApprovalTests)*
+56. Test pyramid: 많은 단위, 적당한 통합, 소수의 E2E(임계 여정만). *(Mike Cohn 개념 / Ham Vocke·Google)*
+57. "더 이상 E2E는 그만" — E2E를 임계 여정에만, 결함 발견 시 하위 레벨 회귀 추가. *(Google TotT)*
+58. Beck "테스트를 얼마나?" → "같은 확신에 도달하는 **최소한만**." 커버리지 % 목표 없음. *(StackOverflow)*
+59. 테스트 리팩터: 테스트 코드도 프로덕션처럼 품질 관리, 공유 픽스처 과용 금지. *(Microsoft)*
+60. 비결정성·플레이키 금지 — 시간·랜덤·네트워크·DB는 주입/제어. zero-tolerance for flaky. *(Microsoft/Azure WAF)*
+
+## B. 2026 에이전트 시대 (2026년 전반~9월)
+
+61. **TDD-Agent** (2026-08-17): 구현 전 실행가능 테스트 생성 → 테스트·코드를 함께 반복 정제 → 저장소 정답률·커버리지·뮤테이션 개선. *(arXiv 2608.16742)*
+62. **TDAD** (실제 제출 2026-03-18): 프롬프트로 "TDD를 써라"만 주면 회귀 증가 경향; 의존성·테스트영향 컨텍스트(TDAD 적용 시 6.08%→1.82%)가 회귀 감소. *(arXiv 2603.17973). 레드팀 날짜 정정: 기존 '2026-02-08'은 항목 86(2602.07900)과 혼동*
+63. **Harness-IF**: 실행 트레이스로 **지시(인스트럭션) 준수**를 평가 — 최종 통과만으론 절차(그중 TDD 포함) 준수 증명 불가. *(arXiv 2608.11727). 레드팀 범위 정정: TDD 전용 평가 논문이 아님*
+64. **Spec-driven test generation** (2026-08): 전제/사후/불변/비정의 행위/오류경계 문서화 후 테스트 생성 → 버그 검출 +9.8pp, 브랜치 커버리지 +2.5pp. *(arXiv 2608.17177)*
+65. **GitHub Spec Kit**: Spec→Plan→Tasks→Implement→Verify; v1.0.0 (2026-08-21); 테스트-우선 거버넌스 프리셋. *(GitHub)*
+66. **OpenSpec**: AI 코딩 어시스턴트용 오픈소스 스펙 레이어. *(Fission-AI)*
+67. **VS Code TDD 가이드**: TDD Red / TDD Green / TDD Refactor 3개 커스텀 에이전트 + 핸드오프 + 자동 테스트 실행. *(code.visualstudio.com, 2026)*
+68. **OpenAI Harness engineering**: 아키텍처·코딩규칙을 긴 프롬프트보다 **린터/구조 테스트로 기계적 강제**가 더 신뢰성. *(openai.com)*
+69. **Running Codex safely**: 샌드박스, 네트워크·자격증명 제한, 고위험 액션 승인, 명령·테스트 로그 보존. *(openai.com)*
+70. **Anthropic evals**: 안정적·재현 가능 환경과 결정적 그레이더. *(anthropic.com)*
+71. **Meta Catching JiTTests** (2026-02-11): 코드 도착→의도 추론→뮤턴트 생성→테스트 실행→신호 집중; 유지보수·리뷰 불필요, 실제 버그 시에만 인간 개입. *(engineering.fb.com)*
+72. **Google "The Way of TDD"** (2026-03-10): red-green-refactor 옹호하되 "은탄환이 아니다" 명시. *(testing.googleblog.com)*
+73. **Alderson** (2026-01-25): 에이전트가 테스트를 '초' 단위로 쓰니 경제성 역전 — 티켓마다 "테스트 계획을 구현 전에" 요구, 단위·통합 우선(목 인프라), E2E는 PR 시 CI. *(martinalderson.com)*
+74. Alderson: 리뷰를 **구현 코드가 아닌 테스트 파일부터** — 에이전트가 테스트를 지우면 즉시 드러남. *(martinalderson.com)*
+75. Alderson: 버그 수정 시 "왜 테스트가 못 잡았는지" 설명하게 하고 그 엣지용 테스트 추가. *(martinalderson.com)*
+76. Alderson: `expect(1+1).toBe(2)` 식 단정을 막기 위해 "이 브랜치가 실제 언제 발동하는지 실례"를 요구. *(martinalderson.com)*
+77. **Emily Bache x Nizar** (2026-07-27): 에이전트는 TDD 지시를 받아도 지름길(스킵·과잉구현·린트 비활성·체크 전 커밋)을 찾음 → **TDD Guard/Probity 도구로 강제**. *(coding-is-like-cooking.info)*
+78. Probity: 참조 안 되는 메서드 추가(과잉구현)를 잡아 "테스트를 통과시키는 가장 단순한 변경"을 재요구. *(Emily Bache)*
+79. "테스트 행위지, 구현 형태가 아니다" — 테스트가 리팩터를 견디고, 재작성 불필요, 자신감이 목적. *(Nizar/Emily Bache)*
+80. **Drew Cain "TDD Is Out, SDD Is In"** (2026-04-09): 테스트는 검증, 스펙은 의도; 올바른 것을 만드는가. 스펙=구현가이드+테스트플랜+문서 3-in-1. *(oleaedge.com)*
+81. SDD 수치: 8주에 56개 스펙, 181 커밋, 869 파일, 5.6만 줄; 29%는 spec-to-code 자동, 71%는 인간 검토·판단. *(oleaedge.com)*
+82. Thoughtworks Radar 2025: spec-driven development를 **가장 중요한 실천 중 하나(one of)**로 선정(oleaedge 2차 전언). Birgitta Boeckeler 인용문도 oleaedge 경유 — Radar 원문 대조 필요. *(oleaedge.com)*
+83. Amazon Kiro: spec-driven IDE, 작업 제품까지 58% 빠르고 프로덕션 버그 65% 감소 보도. *(oleaedge.com)*
+84. Red Hat: spec-driven AI 코딩 95%+ 정확도 보도. *(oleaedge.com)*
+85. Harness-bench (2026): 즉시·잘 정의된 과제에선 중장비 낭비, 긴 지평·회귀수정·모호 저장소에서 가치. *(github.com/tdrml/harness-bench)*
+86. "Agent가 테스트를 많이 쓴다고 이슈 해결이 안 좋아짐" (2026-02-08, 6개 모델 SWE-bench Verified): 에이전트 테스트량은 결과에 유의한 영향 없음. *(arXiv 2602.07900)*
+87. 핵심 결론: **인간 테스트+에이전트 구현** ≫ **에이전트 테스트+에이전트 구현** (독립성 부재). *(TDFlow, arXiv 2510.23761/EACL 2026: 인간 작성 테스트 제공 시 SWE-bench Verified 94.3% vs 에이전트 생성 테스트 68.0%. 단 2602.07900 자체는 '테스트량 무효과'가 결론 — '≫'는 TDFlow+원리 종합)*
+88. AI 에이전트용 권장 루프: SPEC→RED→FREEZE(숨김 수용 테스트)→GREEN→VERIFY(풀 스위트+타입+린트+정적/보안+뮤테이션)→REFACTOR→REVIEW(테스트 약화·삭제·하드코딩·스킵·무관 변경 검사)→DONE 게이트. *(종합)*
+89. Jackson의 테스트-영향/의존성 컨텍스트: 스키마·계약·상태전이·경계·인가·동시성·멱등성 테스트 매트릭스를 사양에서 도출. *(spec-driven)*
+90. Traceability: (Requirement→Acceptance scenario→Test ID→Test file→Result)로 유지. *(spec-driven)*
+91. 커버리지 도구를 에이전트로 돌려 미검증 브랜치 개선 + 실례 요구 (Alderson식 단정 방지). *(Alderson)*
+92. "숨겨진(held-out) 수용 테스트가 에이전트 컨텍스트 밖에" — 에이전트가 만든 테스트로 독립 검증 불가. *(종합)*
+93. 에이전트가 기존 테스트를 약화·삭제·스킵·광범위 목으로 대체하는 것을 금지하는 가드레일. *(종합)*
+94. 커버리지는 진단용, 시나리오 커버리지·뮤테이션과 결합. *(2026 자동 테스트 생성 산업 규모)*
+95. 에이전트 생성 테스트는 초안(draft)이지 증거(evidence)가 아님 — GitHub 공식 가이드도 리뷰·누락 시나리오 추가 요구. *(docs.github.com)*
+96. 계약 테스트(Pact), 프로퍼티 테스트는 결정적 오라클 — 자연어보다 강한. *(Pact)*
+97. Google(테스트 인프라로 결함 예방) vs Meta(고신호 자동화+실험) 문화 비교; 둘 다 2026엔 AI 지원 테스트로 수렴. *(Google/Meta 블로그)*
+98. 2026 팀 정책: 새 비즈니스 로직 단위 테스트 필수, PR마다 빠른 단위 스위트, 단위 스테이지엔 네트워크·영구 인프라 금지, 변경코드 커버리지 모니터하되 맹목 목표 금지, 플레이키 격리+소유자, 중요 경계 통합/계약, 금융·인가·안전 로직 뮤테이션. *(종합)*
+99. 지속 TDD-RED 지시문 템플릿(AGENTS.md용) — 05-framework.md에 수록.
+100. "에이전트가 같은 테스트와 구현을 **조용히 함께 쓰면 안 됨**" — 시각적 증거(먼저 실패) 요구, GREEN에서 테스트 수정 금지, CI가 최종 판결. *(VS Code/Codex/Qodo 종합)*
+
+---
+
+## 1차 소스 스크랩 목록 (Playwright, headless→headful)
+
+| id | url | 크기 | 비고 |
+|---|---|---|---|
+| kentbeck_canon_tdd | newsletter.kentbeck.com/p/canon-tdd | 7.8KB | Canon TDD 정의 |
+| kentbeck_design_in_tdd | newsletter.kentbeck.com/p/design-in-tdd | 5.2KB | TDD와 설계, Ousterhout 논쟁 |
+| kentbeck_passing_tests_bore_me | kentbeck.com/summaries/passing-tests-bore-me/ | 1.0KB | 공허한 통과 |
+| fowler_tdd | martinfowler.com/bliki/TestDrivenDevelopment.html | 2.4KB | RGR 정의 |
+| fowler_is_tdd_dead | martinfowler.com/articles/is-tdd-dead/ | 2.6KB | DHH 대담 |
+| dhh_tdd_is_dead | dhh.dk/2014/tdd-is-dead-long-live-testing.html | 5.2KB | DHH 원문 |
+| fowler_test_pyramid | martinfowler.com/articles/practical-test-pyramid.html | 80KB | 테스트 피라미드 실무 |
+| james_shore_acceptance_testing | jamesshore.com/v2/blog/2012/acceptance-testing-revisited | 2.1KB | 수용은 대화 |
+| alderson_wrong_about_tdd | martinalderson.com/posts/turns-out-i-was-wrong-about-tdd/ | 10KB | 2026 에이전트 경제성 |
+| google_way_of_tdd | testing.googleblog.com/2026/03/the-way-of-tdd.html | 2.3KB | 2026-03 공식 |
+| oleaedge_sdd | oleaedge.com/blog/tdd-is-out-sdd-is-in | 7.3KB | SDD 사례·수치 |
+| emily_bache_ai_tdd | coding-is-like-cooking.info/2026/07/the-most-important-ai-coding-advice-you-havent-heard-yet/ | 13KB | TDD Guard/Probity |
+| vscode_tdd_guide | code.visualstudio.com/docs/agents/guides/test-driven-development-guide | 14KB | 3-에이전트 TDD |
+| meta_jit_testing | engineering.fb.com/2026/02/11/developer-tools/the-death-of-traditional-testing-agentic-development-jit-testing-revival/ | 7.2KB | Catching JiTTests |
+
+원문 파일: `scratch/tdd-red/raw/*.txt` (스크래퍼: `scratch/tdd-red/scrape.mjs`, `retry.mjs`)