배치 계획과 실행

남은 일을 배치로 나누고(계획), 역할을 배정해 연달아 실행하고(실행), 진척을 숫자로 알린다(보고). 사용자가 자리를 비운 동안에도 이어 간다(8절). research-session의 공통 규칙을 따른다. 프로젝트의 할일목록이나 현황에 다른 규칙이 있으면 그 규칙이 앞선다. 다만 공통 규칙 3, 8, 9, 10, 13보다 앞서지 않는다.

1. 상태 읽기

1. research-session 1절대로 현황, 세션 기록, 인계 노트, 승인기록, 할일목록 현행 판을 읽는다.
2. 마지막 기록 뒤에 바뀐 파일을 확인한다. 파일이 바뀐 것과 진행이 있었던 것은 다르다. 바뀐 파일을 읽고 무엇이 달라졌는지 확인한 뒤에만 진행으로 적는다.
3. 기록의 시각이 실제 파일 수정 시각과 어긋나면 오기로 적어 둔다.
4. 계획 전에 관문 기록(docs/관문/)과 접은 주제(docs/접은주제.md)를 읽는다. 조건부 통과의 조건은 계획의 항목이나 통과 조건으로 옮긴다.

2. 계획: 할일목록 새 판

배치 구조나 일정이 바뀔 때만 새 판을 만든다. 항목의 상태만 바뀌면 현행 판을 고친다.

• 새 판은 docs/할일목록.md에 쓰고 지난 판은 docs/구판/할일목록-v<번호>.md로 내린다. 첫 줄에 대체한 판을 적는다.
• 배치 표 열: 번호, 항목, 역할, 산출(파일 경로), 통과 조건, 선행, 어림 시간, 상태.
• 함께 둘 표: 사용자 작업(무엇, 걸리는 시간, 기한), 남은 사용자 결정(결정, 권고, 언제), 위험(위험, 가능성, 생기면 할 일. 결과가 불리할 때의 서술을 미리 적는다).
• 실험이나 측정 항목에는 선행으로 preregister-seal을 둔다.
• research-portfolio의 투고처표와 요건계산이 있으면 읽고 마감과 분량을 일정에 반영한다.
• 사용자 결정은 시각과 함께 그대로 적는다. 추측으로 결정을 채우지 않는다.
• 계획을 사용자에게 보이고 승인을 받는다. 계획 승인은 실행 승인이 아니다. 실행은 사용자가 지시할 때 시작한다.

3. 역할 배정

역할은 총괄, 규칙 작성, 실행, 독립 검산, 심사, 새 독자, 문헌 정찰이다. 역할별 모델은 프로젝트 설정을 따르고, 설정이 없으면 총괄과 규칙 작성과 심사는 큰 모델, 나머지는 중간 모델로 둔다.

• 한 에이전트는 한 관심사만 맡는다. 서로 의존하지 않는 항목은 한 번에 함께 띄운다.
• 실행 에이전트가 일이 크다며 멈추면 큰 모델로 넘기고 쪼갠다.
• 규칙을 쓰는 에이전트는 결과 파일을 보지 않는다.
• 에이전트 지시문에 늘 넣는 것: 역할과 파일 위치, 읽을 파일 목록, 보고할 숫자의 정확한 지정, "지시와 자료가 다르면 자료를 따르고 차이를 보고한다", 공개 저장소 규칙.

4. 실행

• 배치를 순서대로 연달아 진행한다. 배치 사이에 허락을 다시 묻지 않는다.
• 사용자가 자리를 비운 동안에는 승인된 맡김 지시서가 있을 때만 돌리고 8절을 함께 따른다.
• 멈추는 경우는 셋뿐이다. 사용자가 멈추라고 할 때, 되돌릴 수 없고 어느 쪽으로도 갈 수 있는 결정일 때, 환경이 막혀 그 항목을 진행할 수 없을 때. 막힌 항목만 멈추고 다른 항목은 계속한다.
• 사용자 대신 내린 판정은 대리 판정 대기열(docs/승인기록.md의 대리 판정 절)에 넣고 진행한다. 사용자는 나중에 읽고 뒤집을 수 있다.
• 쿼리 크레딧, API 한도 같은 공유 자원은 preregister-seal 6절의 비용 장부에 항목마다 쓴 양과 남은 양을 적는다. 멈춤 선에 닿으면 그 항목을 멈추고 알린다.
• 클라우드 작업 공간에서 돌리면 배치가 끝날 때마다 결과를 연결 폴더에 쓰고 코드는 bundle로 남긴다.
• 숫자를 문서에 넣기 전에 fact-check로 대조한다.

5. 보고

배치를 시작할 때 시작 안내를, 항목이 시작하거나 끝날 때와 막히거나 방향이 바뀔 때 진행판을, 배치가 끝날 때 마침 보고를 보인다. 길게 돌아가는 실행은 research-session 8.3대로 5분 넘게 침묵하지 않는다. 틀은 research-session 8절(시작 안내, 진행판, 마침 보고)을 따른다. 아래는 이 스킬의 보고에 들어갈 내용의 예다.

== 진행 | <프로젝트> | 배치 G | HH:MM (시작 HH:MM, 경과 n분, 남은 어림 n분) ==
전체   [##----------] 4/27  15%   (배치 G 3/6)
단계   G1 [완료] 봉인 a1b2  G2 [완료] 계단표  G3 [진행]  G4 [예정]  G5 [예정]  G6 [예정]

에이전트    역할        맡은 일              상태     시작   마지막 신호  진척
rules-1     규칙 작성   G3 사전 등록         [진행]   HH:MM  HH:MM        초안 2/3절
checker     독립 검산   G2 계단표 재계산     [완료]   HH:MM  HH:MM        불일치 0

최근   HH:MM G2 끝: 계단표 12행, 독립 검산 불일치 0
대기   rules-1, 어림 8분, HH:MM에 다시 알림
결정   없음 / 대리 판정 대기 2건 / 크레딧 1,240/2,500

• 진척은 항목 수로 센다(전체, 배치 안). 남은 시간 어림을 적고, 어림을 넘기면 넘겼다고 적는다.
• 끝낸 일에는 결과의 핵심 숫자나 판정을 한 줄로 붙인다.
• 하지 않은 것과 확인하지 못한 것을 분명히 적는다.
• 작업 목록 위젯이 있으면 진행판의 단계와 같은 이름으로 올리고 항목이 바뀔 때마다 갱신한다.

6. 배치가 끝날 때

1. 현황 맨 위에 "갱신: 날짜 시각(시계에서 읽음), 무엇을 했나"를 더한다.
2. 할일목록의 상태 칸을 고친다.
3. 결과 파일을 프로젝트 폴더에 쓰고, 바뀐 파일을 답에서 바로 열 수 있게 보인다.
4. 다음 배치로 넘어간다. 마지막 배치면 research-session 3절대로 세션을 마친다.

7. 다른 스킬로 넘기는 곳

8. 사용자가 없는 동안

사용자가 자리를 비운 동안(밤, 회의, 주말)에도 배치를 이어 갈 수 있다. 사용자의 시간은 결정과 검토에 쓰고, 기준이 이미 있는 조사, 구현, 확인은 사용자가 없는 시간으로 옮긴다. 원칙과 실패 양상은 운영 체계 저장소의 docs/08-사용자가-없는-시간.md에, 양식은 templates/맡김지시서.md, templates/검토서.md, templates/맡김-예약프롬프트.md에 있다. 파일은 프로젝트의 docs/맡김/에 둔다. <시작>은 지시서를 쓴 시각(YYYY-MM-DD-HHMM, 시계에서 읽음)이고 브랜치 이름과 파일 이름에 같이 쓴다. 지시서는 main에, 결과와 검토서는 away/<시작> 브랜치에 커밋한다.

8.1 떠나기 전

research-session 3절이 세션을 마칠 때 이 절을 부른다.

1. 검토 대기를 센다. 지난 검토서에서 받지도 돌려보내지도 않은 항목이 이번에 맡길 새 항목보다 많거나 검토 대기가 세 번 연속 늘었으면 새 일을 맡기지 않고 정리(요약, 검산, 변경 기록)만 맡긴다.
2. 할일목록에서 맡기기 좋은 항목을 고른다. 기준이 이미 있고 다른 에이전트가 결과를 확인할 수 있는 일이다. 판단이 필요한 항목은 지금 기준으로 바꾸거나 뺀다. 고른 항목의 상태를 할일목록에서 "맡김(<시작>)"으로 바꾼다. 구현 항목은 통과 시험을 지시서에 적거나, 확인 에이전트가 쓰게 한다. 구현한 에이전트가 쓴 시험만으로는 확인으로 치지 않는다.
3. docs/맡김/<시작>-지시서.md를 양식대로 쓴다. 바꾸지 않을 것(문제 정의와 주장 목록의 판, 봉인 해시), 항목과 통과 조건과 확인 방법, 갈림길의 사전 결정, 멈춤 선, 하지 않을 것, 사용자가 돌아오는 시각과 검토 예산, 시작 방식과 승인 설정을 채운다.
4. 사용자에게 보이고 승인을 받아 승인 시각을 적는다. 승인 없는 지시서로는 맡기지 않는다. 지시서의 항목 표에 적고 승인받은 일은 프로젝트의 "사용자 확인 후에만 하는 일"(예: 실험 실행)이라도 확인을 받은 것으로 본다. 표에 없는 그런 일은 여전히 하지 않는다.
5. 지시서를 main에 커밋하고 push한다. 이 일은 research-session 3절의 세션 기록보다 앞에 한다. 지금 세션에서 이어 돌리면 바로 8.2로 간다. 예약하면 templates/맡김-예약프롬프트.md를 채워 예약 작업을 만들고, 그 승인 설정이 쓰는 동작을 막지 않는지 확인한다. 막으면 사용자에게 알린다.

8.2 맡긴 동안

1. date로 시각을 읽고 지시서를 읽는다. 다음 가운데 하나면 실행하지 않는다. 승인 시각이 비어 있다(검토서에 그 사실만 적는다). 사용자가 돌아오는 시각이 지났다. 그 지시서의 검토서에 사용자 표시가 있다. 진행 칸의 항목이 모두 [완료], [멈춤], [건너뜀]이다.
2. git fetch origin. origin/away/<시작>이 있으면 받아서 잇고(git switch away/<시작>), 없으면 main에서 만든다(git switch -c away/<시작> origin/main). 검토서 초안이 있으면 진행 칸에서 끝나지 않은 첫 항목부터 잇는다. [진행]인데 마지막 신호가 30분 안인 항목은 앞 실행이 하고 있으므로 건너뛰고, 30분 넘게 지난 항목은 멈춘 것으로 보고 이어 받는다. 항목을 시작할 때 [진행]과 시각을 적고 커밋해 바로 push한다. 항목이 오래 걸리면 30분 안의 간격으로 진척과 마지막 신호를 고쳐 push한다. 겹쳐 도는 다른 실행이 그 표시를 보게 하려는 것이다.
3. 4절의 방법으로 실행하되 다음을 더 지킨다.
   • 지시서의 "바꾸지 않을 것"에 닿는 발견은 고치지 않고 검토서의 결정 대기에 올린다.
   • 적힌 갈림길은 적힌 대로 한다. 적히지 않은 갈림길은 되돌릴 수 있는 쪽을 고르고 대리 판정으로 적는다. 되돌릴 수 없는 쪽밖에 없으면 그 항목을 멈춘다.
   • 같은 항목이 실패 상한에 닿으면 멈추고 다음 항목으로 간다. 확인 불일치가 나온 결과에 기대는 항목은 시작하지 않는다.
   • 지시서의 하지 않을 것과 공통 규칙 6의 일은 하지 않는다. 사용자에게 묻지 않는다.
4. 항목마다 away/<시작>에 커밋하고 push하며 진행 칸을 고친다. 진행 칸의 커밋 해시는 같은 커밋에 적을 수 없으므로 다음 커밋에서 적는다. main에는 커밋하지 않는다.
5. 결과는 만들지 않은 에이전트가 확인한다(숫자와 인용은 fact-check, 구현은 지시서에 적힌 시험이나 확인 에이전트가 쓴 시험, 문헌은 확인 수준). 따로 띄울 에이전트가 없어 총괄이 확인했으면 그 사실을 적는다(공통 규칙 3). 확인하지 못했으면 미검산으로 적는다. 다른 계열 도구가 있으면 마지막에 반론자로 넣는다.
6. 전체 마감이 되거나 항목을 모두 끝내면 docs/맡김/<시작>-검토서.md를 완성한다. 결정 대기를 맨 위에 두고, 결과마다 한 줄 결론, 핵심 숫자, 확인 상태, 근거 파일, git diff origin/main...origin/away/<시작> -- <경로>를 붙인다. 대리 판정은 모두 검토서 4절에 적는다. 예상 검토 시간이 예산을 넘으면 세부를 근거 파일로 옮긴다. 실패, 미검산, 하지 않은 일을 결과보다 작게 쓰지 않는다. 커밋하고 push한 뒤 세션 기록을 남긴다.

8.3 돌아와서

research-session 1절이 세션을 시작할 때 이 절을 부른다.

1. git fetch origin 뒤 검토서를 찾는다. 검토서는 away/ 브랜치에 있다. git branch -r --list "origin/away/*"의 브랜치마다 git show origin/away/<시작>:docs/맡김/<시작>-검토서.md로 읽고, 사용자 표시가 비어 있는 것을 보인다. 결정 대기에 답을 받고, 결과마다 받음, 돌려보냄, 버림 가운데 하나를 받는다.
2. 받은 항목만 main에 합친다. 받은 경로를 가져오고(git checkout origin/away/<시작> -- <경로>), 검토서와 맡긴 동안의 세션 기록도 함께 가져온다. 검토서의 사용자 표시를 채우고 합친 커밋을 적은 뒤 main에 커밋한다.
3. 할일목록에서 받은 항목은 [완료]로, 돌려보낸 항목은 이유와 함께 맡기기 전 상태로 되돌리고, 버린 항목은 이유만 적는다. 브랜치는 지우지 않는다.
4. 결정 대기의 답을 승인기록에 적는다. 검토서의 대리 판정은 모두 승인기록의 대리 판정 절로 옮기고, 사용자가 뒤집은 것을 표시한다.
5. docs/맡김/지표.md에 한 줄을 더한다. 열은 그 파일의 머리줄을 따른다(시작, 끝낸 항목, 받은 항목, 돌려보낸 항목, 버린 항목, 확인한 항목, 확인 불일치, 올라온 결정, 답한 결정, 검토 예산, 실제 검토 시간, 검토 대기). 실제 검토 시간은 사용자에게 묻는다.
6. 받은 비율이 세 번 연속 60% 아래이거나 실제 검토 시간이 세 번 연속 예산의 1.5배를 넘으면 다음 맡김의 항목 수를 줄이자고 권한다.

처음 맡길 때는 항목 하나, 한 시간, 크레딧을 쓰지 않는 일로 시험한다. 예약 작업이 승인이나 인증에서 멈추지 않는지, 브랜치 push와 검토서 작성이 되는지만 본다.