control-loop

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 등)은 기준으로 쓰지 않는다 — 다른 체크아웃이 그 브랜치를 물고 있으면 로컬 이름이 원격보다 여러 커밋 뒤처져 있을 수 있고, 그 상태로 워커 워크트리를 생성하면 낡은 기준점에서 작업이 시작된다(실측 사고: 워크트리 5개가 로컬 main 기준으로 생성됐는데 그 main 자체가 원격보다 11커밋 뒤처져 있었다).

워커는 착수 시 자기 워크트리 HEAD(git rev-parse HEAD)가 브리프의 해시와 같은지 확인한다. 다르면 구현을 시작하지 않고 즉시 에스컬레이션한다.

자식 생성 절차 — 인자 4개

호스트가 제공하는 위임 수단으로 워커를 만들 때, 다음 4개를 함께 전달한다:

1. 부모 세션 이름/식별자 — 워커가 완료·에스컬레이션을 보고할 대상
2. 역할 + 워크트리 경로 — 무엇을 맡았고 어디서 작업하는지
3. 4블록 브리프 — 이 페이즈의 산출물 그대로
4. 금지사항 기본값 — 최소 다음을 포함한다: push 금지, 통합 브랜치(main 등) 직접 쓰기 금지, 파괴적 git 명령(bare stash/reset --hard/clean -fd) 금지, 병합 전 공유 상태 파일(진행 원장 등) 쓰기 금지