control-looplisted

# Control Loop 스킬 축은 *기획 대 컨트롤*이 아니라 **결정 대 조사**다. 판별식: 브리프를 전제·범위/계약· 금지사항·보고형식 4블록으로 쓸 수 있으면 그 작업은 워커에게 위임 가능한 **조사**다. 4블록을 **쓰는 행위 자체**는 위임 불가능한 **결정**이다. 이 스킬은 기획용·컨트롤용으로 나뉘지 않는다 — 같은 세션 안에서 조사와 결정을 섞지 않고 3페이즈로 가른다. ## 언제 쓰는가 컨트롤 세션이 자신이 아닌 별도의 워커(다른 세션, 격리된 워크트리, 그 밖에 호스트가 제공하는 어떤 위임 수단이든)에게 작업을 맡기고, 그 결과를 검증한 뒤 통합 브랜치로 되돌릴 때. 구체적 위임 수단은 이 스킬의 관심사가 아니다 — 아래 "운송" 참고. --- ## P1 — 조사·설계 (위임 가능) - 목적은 결정에 필요한 **사실**을 모으는 것이다. 결정은 여기서 하지 않는다. - **"없다 / 신설한다" 같은 존재 판정은 실측 뒤에만 쓴다.** `grep`, `git log --all`, 대상 파일 직접 열람으로 확인하지 않은 존재 판정은 그 자체가 결함이다 — 이 판정을 틀린 채로 다음 페이즈에 넘기면 컨트롤이 잘못된 전제로 브리프를 쓰게 된다. - P1을 워커에게 위임할 때도 4블록 브리프(P2 참조)로 위임한다 — 조사 자체는 위임 가능, 결정만 위임 불가라는 뜻이다. - P1 산출물은 사실 목록이지 결정이 아니다. "이렇게 해야 한다"가 섞여 있다면 그것은 이미 P2로 넘어간 것이므로, 컨트롤이 그 부분만 따로 검증하고 결정으로 승격한다. ## P2 — 결정·브리프 (컨트롤 전용, 위임 불가) P1 산출물을 놓고 채택·금지를 결정하고, 그 결정을 4블록 브리프로 쓴다. - 4블록 스키마·보고 첫 줄 고정 형식·형식 검사 정규식은 `rules/delegation-contract.md`가 SSOT다. 이 스킬은 그 계약을 **참조만** 한다 — 여기서 다시 정의하면 두 곳이 어긋날 때 아무것도 그것을 강제하지 않는 결함 클래스(동기화 안 되는 이중 선언)가 재현된다. - **되돌림 규칙**: 4블록(전제 / 범위·계약 / 금지사항 / 보고형식) 중 하나라도 채울 수 없으면 — 전제가 실측되지 않았거나 완료 기준을 문장으로 확정할 수 없으면 — **P1으로 되돌린다.** 4블록을 못 쓰는 채로 디스패치하지 않는다. - 브리프의 전제 서술은 P1의 실측을 **그대로 인용**한다. 컨트롤이 전제를 추측해서 쓰면 워커가 반려하게 된다(관측된 실패 지점 — 전제를 추측한 브리프가 하루 여러 건 반려됐다). ### 기준 커밋을 못박는다 디스패치 전 컨트롤은 기준 ref의 **실제 커밋 해시**를 확인하고(`git rev-parse <ref>`) 그 해시를 브리프에 적는다. **브랜치 이름(`main` 등)은 기준으로 쓰지 않는다** — 다른 체크아웃이 그 브랜치를 물고 있으면 로컬 이름이 원격보다 여러 커밋 뒤처져 있을 수 있고, 그 상태로 워커 워크트리를 생성하면 낡은 기준점에