sligter/codex-autoloop

Codex AutoLoop

장기 실행 개발 작업을 재개 가능, 감사 가능, 안전 레일 포함, 적시에 중단되는 워크플로로 만듭니다.

사용 시기

다음과 같은 요청을 받았을 때 활성화하세요:

• "지속적으로 개발 / 자동 루프 / 백그라운드 실행"
• "멈추지 말고, 완료되면 보고"
• "잠자고 있을게요, 계속 진행하세요"
• "CSV 작업 목록에 따라 진행"
• "plan.md를 따라 계속 진행"
• "Codex / Claude Code가 장시간 자체적으로 반복 작업 수행"
• "소모성 모드"

매우 작고 몇 분 안에 완료되는 작업이라면 AutoLoop를 강제로 적용하지 말고, 평소처럼 직접 처리하는 것이 더 적절합니다.

핵심 원칙

메인 루프는 간단합니다:

1. 현재 컨텍스트를 먼저 읽습니다.
2. 경계가 명확한 작은 작업 / 단일 가설을 선택합니다.
3. 해석 가능한 원자적 변경을 한 번 수행합니다.
4. 기계적 검증(verify)으로 결과를 판단합니다.
5. 통과하면 유지, 실패하면 롤백합니다.
6. 상태와 결과를 기록합니다.
7. 중단 조건이 트리거될 때까지 계속합니다.

git과 상태 파일을 기억(메모리)으로 사용하고, verify를 안전 레일로 사용하세요. verify를 '진실 그 자체'로 착각하지 마십시오.

두 가지 작업 모드

모드 A: 단일 목표 루프

목표와 지표가 명확한 작업에 적합합니다. 예:

• 특정 디렉토리 내 any 타입 사용 줄이기
• 특정 테스트 스위트를 완전히 통과시키기
• 특정 벤치마크 지속적 최적화
• 특정 기능의 코드 커버리지 향상

모드 B: CSV / plan 기반 전달

백로그 작업 목록이 이미 준비되어 있을 때 적합합니다:

• 우선순위
• 의존성
• 승인 기준
• verify 명령어
• 수정 범위

필요시 다음을 참조하세요:

• references/csv-template.md: 작업 테이블 작성 방법
• references/plan-template.md: plan을 기계가 실행 가능한 계약으로 작성하는 방법

시작 전 확인 사항

다음 조건을 모두 충족하지 않으면 장기 루프를 시작하지 마십시오:

• 저장소가 이미 git 관리 하에 있음
• 기준(baseline) verify 명령어를 수동으로 한 번 통과시킨 상태
• 수정이 허용된 경로가 명확함
• 절대 건드리면 안 되는 경로가 명확함
• state / results 파일이 실수로 커밋되지 않음
• 사용자가 "자율 진행 / 백그라운드 실행 / 장시간 실행"을 명시적으로 요청함

중단 조건

기본적으로 계속 진행하지만, 다음 상황이 발생하면 반드시 중단하고 보고해야 합니다:

1. 게이트 실패: 전체 게이트 / 리뷰 게이트가 실패함
2. 요구사항 모호성: 여러 합리적인 제품 선택이 존재하지만, plan/작업에 판단 규칙이 명시되지 않음
3. 위험한 동작: 데이터베이스 삭제, 마이그레이션, 자격 증명 처리, 프로덕션 영향, 외부 쓰기 작업
4. 검증 표류(Verification Drift): verify가 더 이상 '작업 완료'를 실제로 대표하지 못함
5. 연속 실패: 여러 번의 폐기(discard) / 충돌 후에도 새로운 가설이 없음
6. 범위 초과 수정: 수정해야 할 내용이 scope를 벗어남
7. 인적 체크포인트: 사용자가 먼저 보여달라고 명시적으로 요청함

'절대 방해하지 않음'을 맹신하지 마십시오. 올바른 원칙은 다음과 같습니다:

기본적으로 자율적으로 진행하지만, 위험, 모호함, 범위 초과 시 즉시 에스컬레이션합니다.

단일 라운드 실행 프로토콜

매 라운드마다 다음을 수행합니다:

1. 관련 in-scope 파일, 최근 결과, 최근 git 히스토리를 다시 읽습니다.
2. 하나의 작업 또는 하나의 원자적 가설만 선택합니다.
3. 최소한의 검증 가능한 변경을 수행합니다.
4. 해당 작업에 대응되는 verify 명령어를 실행합니다.
5. 통과: 변경 사항을 유지하고 결과를 기록합니다.
6. 실패: 깨끗하게 롤백하고 실패 원인을 기록합니다.
7. 중단 조건이 트리거되었는지 확인합니다.
8. 다음 라운드로 진행합니다.

실험과 시행착오가 우선시되는 작업은 임시 브랜치 / 독립 작업 공간에 두고, 메인 브랜치를 실험 쓰레기장으로 만들지 마십시오.

verify 설계 요구사항

좋은 verify 명령어는 다음을 충족해야 합니다:

• 기계적(Mechanical): 가능한 주관적 판단에 의존하지 않음
• 충분히 빠름: 반복 실행에 적합
• 속이기 어려움: '지표 부풀리기'에 쉽게 속지 않음
• 실제 승인 기준에 가까움: 실제 완료 기준과 최대한 유사
• 무인 실행 가능: unattended 실행에도 안전

verify를 설계하거나 수정해야 할 때는 다음을 읽으세요:

• references/verify-scripts.md

git / 롤백 원칙

git은 기억(Memory)이지, 만능 보험사가 아닙니다.

무분별한 역사 다시 쓰기보다 다음 방법을 우선 고려하세요:

• 스크래치 브랜치(Scratch branch)
• 워크트리(Worktree)
• 되돌릴 수 있는 커밋 시퀀스
• 범위를 지정한 리버트(Scoped revert)

두 작업의 glob 패턴이 겹치지 않는다고 해서 쉽게 병렬 실행하지 마십시오. 공유 타입, 설정, 빌드 프로세스, 테스트 스냅샷 등에서 여전히 충돌할 수 있습니다.

OpenClaw / Codex 실전 조언

세션 / 서브 에이전트 / ACP harness를 지원하는 환경에서는:

• 작은 작업: 현재 세션에서 직접 수행
• 긴 작업: 격리된 세션에 던져서 지속 실행
• Codex / Claude Code / Gemini 스타일 실행을 명시적으로 요청받은 경우: 해당 harness / 영구 스레드 사용
• 진행 상황을 높은 빈도로 폴링하지 말고, 체크포인트와 완료 콜백에 의존
• 상태(state)로부터 복구하는 것을 우선시하고, 매번 중단 후 재계획하지 않음

필요시 다음을 참조하세요:

• references/openclaw-execution.md: OpenClaw / managed session의 권장 방식
• references/python-launcher.md: 로컬 DIY launcher 참고

권장 읽기 순서

먼저 실행해보고 싶다면

1. 이 파일
2. references/openclaw-execution.md
3. references/verify-scripts.md

작업 목록으로 배치 진행하고 싶다면

1. 이 파일
2. references/csv-template.md
3. references/plan-template.md
4. references/openclaw-execution.md

launcher를 직접 수정하고 싶다면

1. 이 파일
2. references/python-launcher.md
3. references/verify-scripts.md

마지막으로 기억하세요

목표는 "영원히 실행하는 것"이 아닙니다.

목표는:

• 최소한의 감독(babysitting)
• 과정 추적 가능성
• 문제 발생 시 복구 가능성
• 적시에 중단
• 최종 결과물이 실제로 전달 가능한 상태

Autonomous by default. Interruptible by design.