사용자 코드를 잃지 않고, AI 코드 리뷰와 수정을 자동으로 돌리는 도구 만들기

## 코드를 바꾸기 전에 빌드 정의와 책임 문서 읽기 코드를 변경하기 전에 저장소의 진입점, 패키지 맵, 빌드 정의, 소유권 문서를 읽으십시오. 생성된 사본과 편의를 위한 요약은 서로 경쟁하는 진실의 원천이 아니라 참조 포인터로 취급하십시오. ### 저장소 파악 - 실행 가능한 진입점, 구현 패키지, 공유 인프라, 빌드 시스템을 찾으십시오. - 변경되어 낡을 수 있는 안내문에 명령을 복사하지 말고 빌드 정의를 현재 명령 목록으로 사용하십시오. - 각 공개 동작, 구성 키, 환경 변수, 운영 불변 조건을 어느 문서나 소스 파일이 소유하는지 식별하십시오. - 호스트별 어댑터를 명시적으로 유지하십시오. 외부 CLI 버전에 관한 가정을 고정하고, 워크트리 상태 때문에 상위 수준 명령을 신뢰할 수 없을 때는 안정적인 API 대체 경로를 사용하십시오. ### 검증 게이트 - 인계하기 전에 형식 지정과 린트를 수행하고 생성된 아티팩트의 드리프트 검사도 포함하십시오. - 반복 작업 중에는 집중 테스트를 실행한 뒤 변경된 경계에 필요한 정본 단위, 통합, 경쟁 상태, 엔드투엔드 테스트 스위트를 실행하십시오. - 프로세스, 입출력, 구성, Git, 데몬, 기록된 픽스처 동작에는 엔드투엔드 테스트를 우선하고, 순수 헬퍼는 속도와 오류 위치 파악을 위해 단위 테스트하십시오. - 사소하지 않은 변경 후에는 실제 실행 파일을 빌드하십시오. - 버그 수정과 기능 개발에는 테스트 주도 개발을 사용하고, 해결되지 않은 작업을 관련 없는 편집에 숨기지 말고 이슈 트래커에 남기십시오. ## 취소 시 모든 자식 프로세스를 멈추고 Git 디렉터리를 명시적으로 넘기기 장시간 실행되는 자동화는 지원되는 모든 운영 체제에서 자체 취소, 하위 프로세스, 공유 상태, 파일 시스템 영향을 직접 소유해야 합니다. ### 프로세스 규율 - 장시간 실행 작업, 하위 프로세스 작업, 네트워크 작업 전체에 취소 컨텍스트를 전달하십시오. - 정리, 프로브, HTTP 호출에 범위가 제한된 타임아웃을 도출하십시오. - 취소 가능한 하위 프로세스를 프로세스 트리 경계에 넣어 취소 시 직계 자식뿐 아니라 모든 하위 프로세스가 종료되게 하십시오. - 정상 종료와 오류 발생 시에도 취소 때와 마찬가지로 프로세스 그룹을 회수하십시오. 상속된 파이프와 누출된 손자 프로세스가 실행보다 오래 살아남아서는 안 됩니다. - 플랫폼별 자식 프로세스 강화 조치를 하나의 멱등 래퍼를 통해 적용하여 백그라운드 작업이 원치 않는 콘솔을 절대 열지 않게 하십시오. - 표준 동기화 기본 요소로 공유 가변 상태를 보호하고 고루틴, 채널, 워크트리, 임시 디렉터리의 소유권을 명시하십시오. ### 파일 시스템과 Git 규율 - 플랫폼 경로 헬퍼, 애플리케이션 소유 상태 루트, 문서화된 파일 모드를 사용하십시오. - 플랫폼 별칭 때문에 동등한 경로가 다르게 비교될 수 있다면 심볼릭 링크를 해석하십시오. - 베어 저장소의 Git 작업은 Git 디렉터리를 명시적으로 전달하는 헬퍼를 통해 수행하십시오. 강화된 Git 설정에서는 현재 디렉터리 검색에 절대 의존하지 마십시오. - 소유권과 수명 주기 기록이 안전함을 입증할 때만 상태를 제거하거나 교체하십시오. ## 실행할 명령은 신뢰할 수 있는 브랜치의 설정으로만 정하기 명령이나 실행 가능한 에이전트를 선택하는 구성은 코드입니다. 기여자가 제어하는 구성과 지침은 신뢰할 수 없는 데이터로 취급하면서, 신뢰할 수 있는 리비전에서만 구성을 로드하십시오. ### 신뢰할 수 있는 입력 - 새로 fetch하여 신뢰할 수 있는 기본 브랜치를 확인하고, 코드를 실행하는 설정을 읽기 전에 정확한 커밋을 고정하십시오. - 신뢰할 수 있는 커밋이나 그 시점의 구성을 fetch, 읽기 또는 파싱할 수 없으면 중단하십시오. 계약에서 허용한다면 구성이 없어도 읽을 수 있는 신뢰할 수 있는 트리는 유효할 수 있습니다. - 명령 선택기, 에이전트 선택기, 문서화 정책, 프로젝트 지침 적용 제외, 저장소 명령 권한은 신뢰할 수 있는 사본에서만 읽으십시오. - 저장소 명령 권한은 기본적으로 비활성화하십시오. 푸시된 브랜치가 자체 실행 권한을 활성화하거나 신뢰할 수 있는 정책을 약화해서는 절대 안 됩니다. - 실행을 수반하지 않는 기능 설정은 분리하여 브랜치별 동작이 실행 경계를 넘지 않게 하십시오. ### 장애 시 차단 처리 - 사용자 또는 저장소 콘텐츠를 에이전트 프롬프트에 넣기 전에 적대적 제어 텍스트를 정제하고 비밀 정보를 가리십시오. - 선택한 어댑터를 실행하기 전에 지침 억제 옵션이 실제로 작동하는지 확인하십시오. - fetch, 파싱 또는 승인 실패 후에 신뢰를 절대 조작해 내지 마십시오. - 푸시된 콘텐츠가 자체적으로 명령 실행을 승인하거나 신뢰할 수 있는 정책을 교체하거나 장애 시 차단 동작을 우회할 수 없음을 입증하는 회귀 테스트를 추가하십시오. ## 상주 서비스를 하나만 띄우고 작업 중에는 중지 요청 거절하기 머신 전체 범위의 서비스에는 싱글턴 소유권, 소켓 안전, 복구, 파괴적 수명 주기 명령을 위한 독립적인 방어 장치가 필요합니다. ### 싱글턴과 복구 - 복구 작업이나 소켓 바인딩 전에 운영 체제의 배타적 잠금을 획득하고 프로세스 수명 전체에 걸쳐 유지하십시오. - 유지 중인 커널 잠금을 살아 있는 소유자의 증거로 취급하고, 이에 대해 노후 상태를 추정하는 휴리스틱을 만들어 내지 마십시오. - 기존 소켓을 제거하기 전에 프로브하고, 연결 타임아웃과 상태 검사 타임아웃을 각각 독립적으로 제한하십시오. - 명시적 모드를 통해서만 서비스 실행을 시작하십시오. 상속된 환경 변수가 일반 프로브를 워커로 재해석해서는 안 됩니다. - 시작 정리가 상태를 인식하게 하십시오. 작업 기록이 대기 중이거나 실행 중인 워크트리 또는 리소스를 절대 제거하지 마십시오. ### 수명 주기 제어 - 활성 작업이 있으면 운영자가 명시적인 파괴적 재정의를 제공하지 않는 한 중지, 다시 시작, 업데이트를 거부하십시오. - 비대화형 확인 플래그가 활성 작업 보호 장치를 우회하게 두지 마십시오. - 차단 중인 작업을 나열하고 프로세스 및 부모 프로세스 귀속 정보와 함께 각 수명 주기 호출을 감사하십시오. - CI 모니터링 제한을 유휴 타임아웃으로 취급하십시오. 검증된 업스트림 진행이 있을 때만 다시 설정하고 기존 기한을 절대 단축하지 말며, 진행 상황을 확인할 수 없을 때는 안전하게 실패하십시오. - 고아 중단 작업을 멱등으로 만들고 에이전트 대기 타임스탬프는 관찰 용도로만 유지하십시오. 게이트가 실제로 보류된 동안에만 설정하고 게이트의 결정 결과를 바꾸는 데 절대 사용하지 마십시오. ## 리뷰 세션과 수정 세션을 나누고 변경을 요청한 목표와 비교하기 검토는 신뢰할 수 없는 텍스트, 배포 시점 또는 수정자의 근거가 결정을 왜곡하지 못하게 하면서 전체 변경을 소스에서 검증 가능한 의도와 비교해야 합니다. ### 의도와 발견 사항 - 의도의 출처를 보존하십시오. 명시적 의도는 정본 인수 기준으로 취급하고, 추론된 의도는 신뢰도가 낮은 힌트로만 취급하십시오. - 두 형태 모두에 동일한 정제, 비밀 정보 가림, 비실행 보호 장치를 적용하십시오. - 명시적 기준과 충돌하는 수정자의 변경은 실행을 보류하는 사용자 문의 발견 사항으로 전환하십시오. - 배포 전 검토에서는 이후 파이프라인 단계가 소유한 결과만 제외하고, 외부 또는 기존 수명 주기 요구 사항은 계속 적용하십시오. - 발견 사항의 조치가 없거나 알려지지 않았다면 장애 시 차단하십시오. 자동 수정 가능으로 분류하지 말고 반드시 사용자 문의로 분류하십시오. ### 세션과 수정 규율 - 실행마다 하나의 지속성 있는 검토자 세션과 별도의 지속성 있는 수정자 세션을 유지하십시오. 두 역할은 상태를 절대 공유해서는 안 됩니다. - 세션은 검토 루프에서만 재사용하고 최소한의 식별 메타데이터만 영속화하며 프롬프트나 기록은 절대 영속화하지 마십시오. - 재개를 지원하지 않거나 재개에 실패하면 해당 식별 정보를 폐기하고 같은 역할의 차례를 초기 상태로 반복하십시오. 취소된 뒤에는 다시 시도하지 마십시오. - 모든 재검토는 전체 브랜치 diff에 대한 완전한 적대적 검토로 유지되어야 합니다. - 한 번의 수정 라운드에서는 모든 수정을 먼저 적용한 후 변경 영역으로 제한된 집중 검증을 한 번만 실행하십시오. 정본 전체 테스트 스위트와 린트 게이트는 전용 단계에서 실행하게 두십시오. ## 생성 문서는 소스에서 다시 만들고 사용 통계에 프롬프트와 코드를 넣지 않기 각 사실에 대해 하나의 소유자만 유지하고, 파생 안내는 그 소스에서 다시 생성하며, 로컬 진단 증거와 범위가 제한된 원격 분석을 분리하십시오. ### 문서와 생성된 콘텐츠 - 개요 문서는 간결하게 유지하고, 상세 참조 사실은 지정된 소유자에 두며, 가이드에서 해당 사실로 연결하십시오. - 책임이 이동하면 소유권 맵을 업데이트하십시오. - 생성된 에이전트 안내의 소스를 편집하고 승인된 빌드를 통해 아티팩트를 다시 생성하며, 드리프트가 있으면 린트가 실패하게 하십시오. - 소스 안내와 사용 지점의 명령 출력이 동일한 운영 계약을 표현한다면 둘을 함께 변경하십시오. - 하나의 에이전트 패스가 문서와 린트 업무를 결합한다면 각 결과를 정확히 한 번씩 사용하고, 출력이 누락되거나 유효하지 않거나 신뢰할 수 없을 때마다 독립적인 패스로 대체하십시오. - 문서 편집은 현재 변경으로 낡은 내용에만 한정하고, 전체 코퍼스를 다시 훑는 작업을 재도입하지 마십시오. ### 개인정보 보호형 관측성 - 읽기 전용 화면은 페이지 조회 이벤트를 전송해서는 안 됩니다. 해당 화면의 원격 명령 이벤트는 상태가 변경되고 제한된 간격 조건을 충족할 때만 보내십시오. - 변경 이벤트는 완전한 충실도로 유지하되 상세 성능 증거는 로컬에만 저장하십시오. - 호출 메트릭에 프롬프트, 출력, diff, 비밀 정보 또는 원시 명령 인수를 절대 저장하지 말고, 실행 식별자, 경로, 세션 식별 정보 또는 호출별 기록을 원격 분석으로 절대 보내지 마십시오. - 종료 이벤트에서는 범위가 제한된 집계 개수만 전송하십시오. - 메트릭 정의와 시간 경계는 하나의 정본 구현에서만 관리하십시오. 사용할 수 없는 값은 조작된 0이 아니라 null로 나타내고, 필요하면 누적 세션 값의 차이로 라운드별 사용량을 계산하십시오. ## force push 전에 원격을 다시 확인하고 모든 릴리스 빌드에 서명하기 가장 중요한 불변 조건은 사용자 코드를 보존하는 것입니다. 관찰되지 않은 작업을 덮어쓸 수 있는 영리한 복구를 시도하지 말고 안전하지 않은 동기화나 배포를 거부하십시오. ### 저장소와 브랜치 안전 - 풀 리퀘스트 베이스 라우팅을 선택적 포크 푸시 대상과 분리하십시오. 호스트가 포크 라우팅을 엔드투엔드로 지원할 수 없다면 잘못된 자체 대상 풀 리퀘스트를 열지 말고 생성을 건너뛰십시오. - 일반 동기화는 깨끗한 엄격한 fast-forward 또는 정확한 파이프라인 head에 고정되고 동등성이 입증된 분기 이동으로 제한하십시오. - 수동 상태 확인은 fetch하거나 변경해서는 안 됩니다. 차단된 경로에서는 외부 remote를 reset, stash, merge, rebase, force, switch, delete 또는 update해서는 안 됩니다. - 정확히 푸시된 커밋, 자격 증명이 제거된 대상 식별 정보, 세대를 영속화한 뒤 동기화를 적용하기 직전에 변경 가능한 모든 가정을 다시 확인하십시오. - 게시되지 않은 종료 작업은 복구 참조 아래에 보존하십시오. 복구는 깨끗한 워크트리를 엄격한 fast-forward로만 이동할 수 있으며, 로컬 작업을 유지할 때는 새 파이프라인을 시작하지 않고 비교 후 교환으로 게이트를 업데이트해야 합니다. - 새로 fetch한 정본 원격 참조에서 rebase 베이스를 도출하십시오. 푸시하지 않은 기본 브랜치 커밋이 변경 범위를 암묵적으로 넓힌다면 실행을 보류하십시오. - 강제 푸시 전에 원격 head를 다시 읽고, 새 브랜치이거나 head가 같거나 이전에 관찰한 head가 변경되지 않았거나 원격에 추가된 커밋의 동등성이 이미 패치 식별자로 입증된 경우에만 진행하십시오. 조회 또는 입증에 실패하면 반드시 장애 시 차단해야 합니다. - 실행에서 실제로 마지막으로 관찰한 head를 lease 기준점으로 유지하고, 강제 작업 직전에 fetch한 tip을 절대 사용하지 마십시오. ### 릴리스와 종속성 안전 - 영구 서명 계약이 있는 플랫폼에서는 모든 공식 아티팩트를 보관하거나 체크섬을 계산하기 전에 고정된 애플리케이션 식별 정보, 강화된 런타임, 안전한 타임스탬프로 서명하십시오. - 서명 자격 증명을 릴리스 작업 범위로 제한하고 휘발성 저장소로 가져오며 성공하거나 실패했을 때 모두 제거하십시오. - 서명이 없거나 모호한 경우, 식별 정보나 아키텍처가 잘못된 경우, 가변 식별 정보가 요구되는 경우, 강화 조치가 없거나 타임스탬프가 없는 경우 릴리스 검증을 실패 처리하십시오. - 릴리스 계약에 포함되어 있지 않다면 공증, 패키징 형식, 유니버설 바이너리를 별도 범위로 취급하십시오. - 종속성을 추가하기 전에 현재 정본 문서를 확인하고 사용자와 변경 사항을 논의하십시오. - 형식 지정, 린트, 집중 테스트, 통합 테스트, 전체 스위트, 빌드 검사, 문서 검사, 릴리스별 검증에서 실제 결과가 나오기 전에는 준비가 끝났다고 주장하지 마십시오.