harness-updatelisted

# 하네스 갱신 (Layer 4) ## 이 스킬의 목적 하네스는 한 번 세우고 끝나는 것이 아니다. **phase 가 진행되면 검증할 수 있는 것이 늘어나고, 설계가 바뀌면 흐름이 낡고, 새 의존 서비스가 붙는다.** 원본 사양이 "필요한 경우 적극적으로 업데이트되어야 한다"고 적은 것이 이 자리다. 갱신되지 않는 하네스는 두 방향으로 망가진다. ``` 갱신이 늦으면 → 만들어진 기능이 검증 대상에 안 들어간다. 아무도 그것을 확인하지 않는다 갱신이 헐거우면 → 실패하는 게이트를 통과시키려고 기준을 낮춘다. 하네스가 조용히 죽는다 ``` **두 번째가 이 스킬의 진짜 위험이다.** 게이트를 고칠 권한이 있는 쪽이 그 게이트에 걸려 있는 쪽과 같으면, 가장 빠른 해결은 언제나 기준을 낮추는 것이다. 그래서 이 스킬의 절반은 **무엇을 고쳐도 되는지**가 아니라 **무엇을 고치면 안 되는지**에 대한 것이다. ### 여기서 하는 일과 하지 않는 일 | 하지 않는 것 | 어디서 하는가 | |---|---| | 하네스를 처음 세우는 것 | `harness-setup` — `harness_setup/` 이 없으면 그쪽이다 | | 게이트를 새로 만들거나 없애는 것 | 아무 데서도 하지 않는다. 네 게이트는 원본 사양이 정했다 | | 도구를 바꾸는 것 (테스트 러너, 브라우저 자동화) | TRD (`trd-generator`) — 돌아가서 고친다 | | 태스크·수용 기준·`verification` 값을 고치는 것 | Layer 3 (`plan-generator` 10단계 부분 갱신) | | 실패한 코드를 고치는 것 | Layer 5 개발 루프 — **검증하는 쪽이 고치면 검증이 아니다** | | 게이트를 실행하고 재시도를 세는 것 | Layer 5 (`loop-setup`) | | STATE.md 를 고치는 것 | Layer 5 — 여기서는 **읽기만** 한다 | **형식은 새로 정하지 않는다.** 게이트 정의서의 절 구성, 구성 요소 표의 열, 판정 블록의 모양은 `harness-setup` 의 산출물 템플릿에 이미 있다. 여기서 다시 정하면 두 스킬이 다른 형식을 만들고, 그러면 갱신을 한 번 돌릴 때마다 문서가 조금씩 달라진다. **기존 파일의 형식을 그대로 따라 쓴다.** --- ## 0단계. 언제 이 스킬을 부르는가 ### 하네스는 처음부터 완성될 수 없다 `harness-setup` 은 **코드가 0줄인 상태**에서 선다. 플랜 전체를 읽고 세우지만, phase-04 의 태스크가 실제로 무엇을 요구하는지는 **그것을 구현할 때 드러난다.** 그래서 첫 태스크에 들어갈 때 하네스가 미완성인 것은 결함이 아니라 **전제**다. 게이트마다 활성 시점을 적어 둔 것이 그 전제를 문서로 만든 것이고, 이 스킬이 그것을 메워 나가는 수단이다. **두 종류의 부족을 구별한다.** 다루는 방법이 다르다. | | 계획된 성숙 | 계획에 없던 부족 | |---|---|---| | 무엇인가 | 활성 시점 도달, 흐름 활성화, 커버