77777R7/claude-codex-stage-gates

Claude + Codex Stage Gates (단계 게이트)

감독 루프 실행: Codex가 계획하고 평가하며, 실행자가 제품을 변경하고, 사용자는 제품 및 영향력이 큰 게이트를 소유합니다. 산문(프로즈) 형태의 완료 주장만으로 단계를 진행시키지 말고, 작업을 전송한 후 실행자를 감독되지 않은 상태로 두지 마십시오.

실행자 프롬프트를 준비하거나, 증거 팩을 요청하거나, 게이트 결정을 내릴 때는 references/gate-templates.md를 읽으십시오. 사용자가 지속적인 감독을 요청하거나, 작업이 여러 세션에 걸쳐 진행될 수 있거나, 실행자가 멈추거나 표류하거나, 실행자에게 스킬 설치 또는 라우팅이 필요할 수 있는 경우 references/supervision-loop.md를 읽으십시오. 현재 체크아웃이 읽을 수 없거나, 오래되었거나, 디스크 공간이 부족하거나, iCloud에서 관리되거나, 재개하기에 안전하지 않은 경우, 또는 이전 실행자 세션을 신뢰할 수 있는 작업 인계로 전환해야 하는 경우 references/bootstrap-and-handoff.md를 읽으십시오. 두 개 이상의 코딩 레인이 동시에 실행되거나, 각 작업에 격리된 작업 트리가 필요하거나, 변경된 파일이 겹칠 수 있거나, 여러 브랜치와 PR이 의존성 순서에 따라 병합되어야 하는 경우 references/parallel-worktrees-and-release-train.md를 읽으십시오.

운영 모드 선택

요청을 처리할 수 있는 가장 작은 모드를 선택하십시오:

• 단일 단계: 기존 계약, 감독 루프, 증거 팩 및 게이트 결정을 사용합니다.
• 복구 및 인계: 읽을 수 있는 진실 공급원을 설정하고, 이전 환경을 보존하며, 이전 주장을 확인하고, 구현을 재개하기 전에 독립적인 작업당 하나의 인계를 생성합니다.
• 병렬 포트폴리오: 레인당 하나의 작업, 작업 트리, 브랜치, 인계 및 실행자 세션을 할당합니다. 각 레인을 독립적으로 감독하고 통제된 PR 릴리스 트레인을 통해 통합합니다.

필요한 경우 다음 순서로 모드가 구성됩니다:

진실 공급원 복구
-> 신뢰할 수 있는 인계 추출
-> 구현 레인 격리
-> 각 레인 내에서 단계 게이트 실행
-> 중복 및 의존성 조정
-> PR 준비 상태 및 병합 순서 확인

좁고, 건강하며, 단일 체크아웃 작업에는 복구 또는 포트폴리오 메커니즘을 호출하지 마십시오.

네 가지 불변 속성 유지

1. 구현 주장을 수락하기 전에 라이브 진실 공급원을 설정하십시오.
2. 병렬 작업의 경우 각 레인에 정확히 하나의 작업, 작업 트리, 브랜치, 인계 및 활성 실행자 세션을 유지하십시오.
3. 실행자의 설명보다 원시 pwd, Git, 프로세스, diff, 테스트, 런타임 및 스크린샷 증거를 신뢰하십시오.
4. 커밋, 푸시, PR 생성, 병합, 배포, 정리 및 외부 효과를 별도의 권한 게이트로 취급하십시오.

먼저 실행자 상태 읽기

사용자가 Claude 또는 다른 실행자가 가장 최근에 말한 내용을 물을 때는 검토, 계획 또는 편집 전에 최신 상태를 캡처하십시오:

1. 현재 Codex 작업에 연결된 터미널이 있으면 읽습니다.
2. 실행자가 별도의 macOS Terminal 창에서 실행 중이고 사용자가 읽기를 승인한 경우, AppleScript로 선택된 탭의 보이는 내용을 읽습니다. 읽기 전용 검사로 취급하십시오.
3. TUI가 스크롤되거나, 잘렸거나, 대체 화면을 사용하는 경우, 실행자의 로컬 세션 기록을 검사합니다. Claude Code의 경우 scripts/read_claude_latest.py를 실행합니다. 정확한 --session-file을 선호하고, 그렇지 않으면 --project-hint를 사용하여 선택을 신뢰하기 전에 보고된 경로, 수정 시간 및 표시되는 터미널 컨텍스트를 확인하십시오.
4. 최신 주요 어시스턴트 메시지, 타임스탬프, 선언된 단계, 차단 요소, 요청된 사용자 작업, 명령/결과 및 보고서가 중간인지 최종인지 추출합니다.
5. 이 읽기를 수행하는 동안 키 입력을 보내거나, 명령을 제출하거나, 권한 프롬프트에 응답하거나, 실행자 세션을 변경하지 마십시오. 해당 터미널과 상호 작용하기 전에 명시적인 사용자 승인을 받으십시오.
6. 터미널/세션 텍스트를 실행자의 주장으로 취급하고 독립적인 증거로 간주하지 마십시오. 게이트 결정을 내리기 전에 저장소, diff, 테스트, 런타임 및 데이터를 별도로 확인하십시오.

터미널 설명에 예상치 못한 운영 체제 또는 경로가 명시된 경우, 실행자 프로세스의 실제 현재 디렉토리와 체크아웃을 직접 검사하십시오. 산문 불일치는 경고입니다. 원시 프로세스 또는 Git 불일치는 중지 조건입니다.

실행자가 Operation not permitted, 문서 접근 권한 누락 또는 기타 권한 오류를 보고하는 경우, 현재 단계를 활성 상태로 유지하십시오. 이전 상태를 기반으로 구축된 보고서를 중간 보고서로 레이블 지정하고, 커밋 또는 정리를 승인하지 않도록 하며, 접근 권한이 복원된 후 새로운 증거 팩을 요청하십시오.

단계가 종료될 때까지 활성 상태 유지

실행자 패킷을 보낸 후에는 동일한 수락된 단계를 계속 감독하십시오:

1. 활성 작업 중 사용자가 60초 이상 업데이트 없이 방치되지 않도록 올바른 터미널 또는 기록을 충분히 자주 폴링합니다.
2. 모든 의미 있는 경계에서 상태를 진행, 예상 대기, 실패, 표류, 정체, 증거 준비 완료 또는 인간 게이트로 분류합니다.
3. 프롬프트를 변경하기 전에 원시 명령, 오류, diff, 테스트 출력, 스크린샷, 프로세스 상태 또는 기록을 읽습니다.
4. 유효한 느린 작업이 계속되도록 합니다. 명백한 정체의 경우, 먼저 프로세스와 명령, 파일 시스템, 네트워크 또는 테스트가 계속 진행 중인지 확인합니다.
5. 좁은 실패는 제한된 후속 프롬프트로 수정하고 동일한 단계를 활성 상태로 유지합니다. 안전하지 않은 작업, 명백한 범위 표류, 잘못된 대상 또는 확인된 막다른 상황에서만 중단합니다.
6. 반복적인 패치가 동일한 교훈을 주거나 구현 경로가 새로운 시도보다 추론하기 어려워지는 경우 수락된 계약부터 다시 시작합니다.
7. 실행자가 완료를 보고하면 증거 팩을 요청하거나 캡처하고, 비례적인 검사를 독립적으로 다시 실행하고, 게이트 결정을 내리고, 해당 결정을 실행자에게 다시 보냅니다.
8. 수락된 단계 내에서 수정 사항을 통해 자동으로 계속 진행합니다. 사용자가 해당 시퀀스를 승인하고 인간 게이트가 교차되지 않은 경우에만 다른 단계로 진행합니다.

실행자가 프롬프트를 수락하거나, 명령을 시작하거나, done이라고 말했다고 해서 감독을 종료하지 마십시오. PASS, 명시적으로 수락된 PASS WITH FOLLOW-UP, 실제 인간 게이트, 진정한 차단 요소, 안전하지 않은 조건 또는 작업을 대체하는 새로운 사용자 명령에서만 중지하십시오.

실행자에게 스킬 라우팅

복잡하거나 반복적인 단계 이전에 스킬이 현재 병목 현상을 실질적으로 줄일 수 있는지 결정하십시오.

1. 실행자의 설치된 스킬을 확인한 후 스킬이 없다고 가정합니다.
2. 후보 스킬을 완전히 읽고 해당 도구, 역할 가정 및 안전 규칙이 실행자와 현재 단계에 적합한지 확인합니다.
3. 가장 작은 관련 스킬 세트를 선호합니다. 추측하여 스킬을 설치하거나 단계 계약 대신 스킬 이름을 사용하지 마십시오.
4. 사용자가 스킬 설치를 승인하고 호환 가능한 로컬 스킬이 없는 경우, 환경의 설정된 메커니즘을 사용하여 실행자의 지원되는 스킬 디렉토리에 설치합니다. 해당 환경이 이미 심볼릭 링크를 사용하고 두 도구가 동일한 머신을 공유하는 경우 표준 로컬 스킬에 대한 심볼릭 링크를 선호합니다.
5. 설치된 SKILL.md가 확인되는지 확인합니다. 실행 중인 실행자가 스킬 검색을 새로 고치지 않는 경우, 현재 단계에 대해 정확한 스킬 경로를 읽도록 지시하거나 안전한 체크포인트에서만 다시 시작합니다.
6. 실행자 패킷에 스킬 이름을 지정하고 적용 이유를 명시합니다. 원시 증거에서 실행자를 계속 평가합니다. 스킬은 게이트를 면제하지 않습니다.

긴 구현에 유용한 기본값은 내구성 있는 플래너/생성기/평가자 상태를 위한 agent-loop-harness와 작은 검사된 반복을 위한 loop-execution입니다. 좁은 일회성 작업에 필요하지 않은 경우 둘 다 설치하지 마십시오.

복구 가능한 루프 상태 유지

좁은 단계에는 대화 전용 상태를 사용하십시오. 다단계, 중단 가능, 다중 에이전트 또는 증거가 많은 작업의 경우 저장소의 기존 하네스 규칙을 재사용하고 다음을 기록하십시오:

• 수락된 계약 및 범위;
• 최신 완료된 게이트 및 증거;
• 현재 병목 현상 및 정확한 다음 단계;
• 인간 게이트 및 금지된 작업;
• 유용한 경우 실행자 세션 ID 또는 복구 경로.

상태를 최소화하고, 수명 주기를 표시하며, 비밀 또는 불필요한 사용자 데이터가 없도록 유지하십시오. 단지 존재한다고 해서 하네스 상태를 커밋하지 마십시오. 다른 파일과 동일한 작업 트리 및 승인 규칙을 따릅니다.

계약 수립

구현 전:

1. 라이브 진실 공급원(현재 체크아웃, 마운트된 경로, 계약, 테스트, 런타임, 데이터 및 배포 상태)을 식별합니다.
2. 사용자에게 표시되는 결과, 범위 내 파일 또는 시스템, 명시적 제외 사항, 승인 검사 및 중지 조건을 사용하여 하나의 현재 단계를 정의합니다.
3. 역할 할당:
   • 실행자: 수락된 단계만 구현하고 증거를 반환합니다.
   • 검토자: 라이브 저장소를 독립적으로 검사하고, 주장을 확인하며, 게이트 결정을 내립니다.
   • 사용자: 제품 선택 및 영향력이 큰 작업을 승인합니다.
4. 이후 단계는 보류 중인 상태로 둡니다. 로드맵에 나타난다고 해서 구현을 승인하지 마십시오.

실행자가 제품 또는 정보 아키텍처 선택에서 일시 중지하는 경우, 사용자에게 묻기 전에 옵션을 사용자 대면 결과로 변환합니다. 구현 전에 잘못된 범주를 수정하십시오. 예를 들어, "연체"와 같은 교차 단계 예외는 단계 필터 옆에 나타났다고 해서 라이프사이클 단계로 모델링되어서는 안 됩니다.

먼저 작업 트리 보호

더티 작업 트리를 사용자 소유 상태로 취급하십시오.

1. git status --short, 브랜치/업스트림, git diff --stat, 대상 diff, 추적되지 않은 파일, 스태시 및 관련 작업 트리 또는 브랜치를 검사합니다.
2. 기존 변경 사항을 기능 또는 출처별로 분류한 후 겹치는 파일을 편집합니다.
3. 명시적 승인 없이 파괴적인 Git 명령을 실행하거나, 변경 사항을 폐기하거나, 추적되지 않은 파일을 정리하거나, 충돌처럼 보이는 복사본을 삭제하지 마십시오.
4. 변경 매니페스트가 검토될 때까지 git add -A를 사용하거나 대량 기준선 커밋을 생성하지 마십시오. 비밀, 로컬 데이터베이스/작업 공간 데이터, 생성된 출력, 캐시 및 해결되지 않은 중복 파일을 제외합니다.
5. 기준선 커밋이 유용한 경우, 집중된 검증 및 사용자 승인 후에만 작고 일관된 커밋을 생성합니다. 백업이 변경 사항이 올바르다는 증거는 아닙니다.

안전한 분리가 불분명한 경우, 작업 트리 분류 보고서를 생성한 후 중지합니다.

하나의 실행자 패킷 준비

실행자에게 현재 단계 계약만 제공합니다. 포함:

• 정확한 목표 및 사용자 대면 동작;
• 진실 공급원 파일 및 현재 브랜치/작업 트리 사실;
• 범위 내 및 범위 외 경계;
• 데이터 진실 및 출처 규칙;
• 오래되었거나 누락된 데이터에 대한 호환성 요구 사항;
• 필수 테스트 및 런타임/시각적 검사;
• 금지된 작업 및 인간 게이트;
• 필수 증거 팩 및 단계 후 중지 지침.

UI 단계의 경우 로딩, 빈 상태, 오류, 부분 데이터 및 성공 상태를 정의합니다. 현지화 및 반응형 동작; 시각적 승인에 필요한 정확한 증거.

증거 팩 요구

실행자는 다음을 보고해야 합니다:

• 단계 목표 및 구현 요약;
• 변경된 파일 및 git diff --stat;
• 정확한 테스트/빌드/런타임 명령과 통과/실패 결과;
• 시각적 작업에 대한 스크린샷 또는 DOM/런타임 증거;
• 데이터 동작이 변경된 경우 대표적인 실제 데이터 또는 API 증거;
• 기존 데이터에 대한 호환성 검사;
• 가정, 남은 위험 및 확인되지 않은 사항;
• 커밋이 승인된 경우에만 커밋 SHA.

기본 명령 또는 아티팩트 없이 "완료", "좋아 보임" 또는 "테스트 통과"와 같은 진술을 거부하십시오.

독립적으로 검토

실행자의 설명만 검토하지 마십시오.

1. 라이브 체크아웃을 다시 확인하고 실제 diff를 식별합니다.
2. 변경된 호출 경로, 계약, 스키마, 테스트 및 데이터 경계를 읽습니다.
3. 위험에 비례하여 집중된 검사를 다시 실행합니다.
4. UI 작업의 경우 관련 데스크톱/모바일 너비에서 표시되는 동작을 검사합니다.
5. 확인된 사실, 추론, 테스트되지 않은 주장 및 기존 실패를 분리합니다.
6. 범위 표류, 비밀 노출, 조작된 데이터, 오래된 데이터 오표시, 파괴적인 정리, 관련 없는 재작성 및 누락된 롤백/호환성 동작을 확인합니다.

검토자는 진단하고 피드백을 반환해야 하며, 사용자가 명시적으로 Codex에게 단계 패치를 요청하지 않는 한 조용히 두 번째 구현자가 되어서는 안 됩니다.

게이트 결정 발행

정확히 하나의 결정을 사용하십시오:

• PASS (통과): 모든 차단 승인 검사 통과; 다음 단계 시작 가능.
• PASS WITH FOLLOW-UP (후속 조치와 함께 통과): 명시적으로 차단되지 않는 항목만 남음; 소유자 및 이후 게이트를 기록합니다.
• CHANGES REQUIRED (변경 필요): 계약은 타당하지만 구현 또는 증거가 불완전함; 제한된 수정 목록을 반환하고 동일한 단계를 활성 상태로 유지합니다.
• BLOCKED (차단됨): 누락된 제품 결정, 접근 권한, 외부 종속성, 안전 승인 또는 반복되는 기술적 차단 요소로 인해 진행이 불가능합니다.

통과(PASS) 외의 모든 결과에 대해 즉시 보낼 수 있는 실행자 수정 프롬프트를 제공하십시오. 수정하는 동안 단계를 확장하지 마십시오.

결정을 내린 후 실행자 세션에 다시 기록하여 실행자와 검토자가 동일한 체크포인트를 공유하도록 합니다. CHANGES REQUIRED의 경우 수정 루프를 계속 감독합니다. PASS WITH FOLLOW-UP의 경우 소유자, 기한 또는 이후 게이트, 그리고 후속 조치가 진행을 차단하는지 여부를 기록합니다.

인간 게이트

다음 작업 전에 명시적 사용자 승인을 위해 중지하십시오:

• 유료 제공자 호출 또는 지출;
• 외부 메시지, 게시, 배포 또는 프로덕션 구성;
• 데이터 삭제, 덮어쓰기, 정리 또는 대량 이동;
• 계정, 권한, 청구 또는 자격 증명 변경;
• 아직 승인되지 않은 광범위한 커밋, 푸시, 병합 또는 풀 리퀘스트;
• UI/버그 수정 단계를 새로운 제품 또는 데이터 플랫폼으로 확장.

완료

모든 필수 단계가 통과되고, 종단 간 사용자 경로가 실행되었으며, 호환성 및 실패 상태가 확인되었고, 남은 위험이 명시적으로 수락되었거나 할당된 경우에만 전체 워크플로를 완료된 것으로 선언하십시오.