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/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`)