AI가 만든 풀 리퀘스트를 사람의 검토를 거쳐 오픈 소스 프레임워크에 보내기

## AI 작업임을 밝히고 에이전트가 만든 브랜치에만 푸시하기 외부 쓰기 작업, 이슈 소유권, 브랜치, 기여자 표기를 통제된 작업으로 취급하세요. - AI가 생성한 풀 리퀘스트 설명, 검토 댓글, 이슈 댓글임을 명확히 밝히고, 프로젝트에서 요구하는 경우 인간 운영자의 이름도 명시하세요. - 인증된 출처를 통해 운영자나 작성자를 확인하세요. 신원을 절대 추측하지 말고, 조회에 실패하면 생략하세요. - AI 지원 커밋에는 필수 AI 공동 작성자 트레일러를 추가하세요. - 프로젝트 한도가 그런 경우 운영자 한 명이 하루에 풀 리퀘스트를 10개 넘게 열지 말고, 완전하며 충분히 테스트된 소수의 변경을 우선하세요. - 자격을 갖추고 담당자가 배정되지 않은 이슈만 작업하세요. 구현 전에 이슈를 운영자에게 배정하고 활성 상태로 전환하세요. - 에이전트가 만든 브랜치에만 푸시하세요. 명시적 허가 없이 기여자의 브랜치에 푸시하지 마세요. - 업스트림 저장소를 어지럽히지 않도록 개인 포크를 우선하고, 주제와 이슈 식별자가 포함된 유용한 브랜치 이름을 사용한 뒤 병합되거나 거절되면 브랜치를 제거하세요. 풀 리퀘스트 메타데이터를 최신 상태로 유지하세요. 푸시할 때마다 제목과 설명을 갱신하여 언제나 전체 변경 사항을 설명하도록 하세요. ## 코드를 바꾸기 전에 코드 이력과 지난 이슈 읽기 잘못되어 보이는 코드에 결함이 있다고 단정하지 마세요. 오래 유지된 시스템에는 현재 구현에서 드러나지 않는 과거의 제약이 반영되어 있는 경우가 많습니다. 1. 보고된 문제를 재현하고 검증하며, 불완전하거나 잘못된 가정에는 이의를 제기하세요. 2. 파일 이력과 blame 정보를 살핀 다음, 관련 커밋 메시지와 연결된 이슈를 읽어 코드가 존재하는 이유를 파악하세요. 3. 관련 이슈에서 거절된 접근법, 이전 논의, 의도적으로 내린 결정을 찾아보세요. 4. 영향을 받는 영역의 설계 문서를 읽되, 특히 보안, 텔레메트리, 로깅 컨텍스트, 공개 명명 계약을 확인하세요. 5. 한 모듈이 다른 모듈을 대체했다면 의도된 변경과 우발적인 누락을 구분하세요. 6. 제안된 수정이 과거의 의도적 변경을 되돌린다면 멈추고 재검토하세요. 그래도 되돌릴 근거가 충분하다면 원래의 판단 근거에도 불구하고 왜 정당한지 설명하세요. 구현 전에 조사 결과, 위험, 모호한 점, 문제 제기가 유효하지 않을 가능성을 운영자에게 제시하세요. 풀 리퀘스트를 검토할 때도 같은 엄격함을 적용하세요. 외부 의존성의 현재 버전, 릴리스, 동작은 권위 있는 출처를 통해 확인하세요. 변경되는 외부 프로젝트에 관해 모델의 학습 지식만으로 단정적인 주장을 절대 하지 마세요. ## 테스트의 고정 대기를 시간 제한이 있는 대기로 바꾸기 테스트에서 고정 시간 대기를 절대 사용하지 마세요. 테스트가 느려지고 불안정하며 비결정적으로 변합니다. - 구성 요소가 기본 제공 시간 제한 어설션을 지원한다면, 그 어설션이 이미 나타내는 조건에는 해당 어설션을 사용하세요. - 다음 작업 전에 중간 개수에 도달하기를 기다리는 경우처럼 그 밖의 조건에는 비동기 대기 유틸리티를 사용하세요. - 기본 제공 블로킹 어설션을 폴링 유틸리티로 감싸지 마세요. 이미 존재하는 래치에 중복 폴링을 더하게 됩니다. - 대기 유틸리티를 사용할 때는 항상 명시적인 최대 시간 제한을 설정하세요. - 바쁜 대기 루프는 절대 사용하지 말고, 어설션이 적용된 조건이나 명확한 술어를 사용하세요. - 고정 시간 대기가 포함된 테스트를 수정할 때는 이를 기본 제공 시간 제한 어설션이나 범용 대기 유틸리티로 전환하세요. 예를 들어 `MockEndpoint.assertIsSatisfied()`는 이미 내부에서 기다리지만, Awaitility는 `MockEndpoint`로 표현할 수 없는 조건에 적합합니다. 새 테스트에 `Thread.sleep()`을 도입해서는 안 됩니다. ## 누구를 신뢰할지 정하고 취약점은 비공개로 보고하기 프로젝트의 표준 위협 모델을 사용하여 누구를 신뢰할지, 신뢰 경계가 어디에 있는지, 무엇이 프레임워크의 책임 범위에 속하는지 판단하세요. - 코드 작성자와 배포 운영자가 실행 가능한 라우트, 표현식, 비밀 정보, 네트워크 노출, 런타임 설정을 의도적으로 구성할 때는 이들을 신뢰 대상으로 취급하세요. - 외부 메시지 발신자와 신뢰할 수 있는 라우트를 통과하는 모든 데이터는 신뢰할 수 없는 것으로 취급하세요. - 프레임워크가 스스로 신뢰할 수 없는 데이터를 코드 실행, 파일 읽기, 요청 위조 또는 권한 부여 우회로 변환해서는 안 됩니다. - 신뢰할 수 있는 작성자의 의도적인 코드 실행, 운영자의 잘못된 구성, 명시적 동의로 활성화된 위험한 동작은 그 자체만으로 프레임워크 취약점이 아닙니다. 유효한 발견은 기본 구성 또는 합리적으로 예상되는 구성에서 신뢰 경계가 침해되었음을 입증해야 합니다. 일반적인 유형에는 안전하지 않은 역직렬화, XXE, 표현식 삽입, 경로 순회, SSRF, 헤더 디스패치 악용, 인증 또는 권한 부여 우회, 비밀 정보 노출, 안전하지 않은 기본값, 프레임워크가 구성한 쿼리에 대한 삽입이 포함됩니다. 필수 통제가 없는 자원 고갈, 의도적으로 노출된 관리 인터페이스, 도달할 수 없는 전이 의존성에 관한 발견, 경계 침해 증거가 없는 스캐너 출력은 일반적으로 프레임워크 범위를 벗어납니다. 의심되는 취약점을 공개 이슈, 풀 리퀘스트, 메일링 리스트 또는 다른 공개 채널을 통해 절대 공개하지 마세요. 비공개 보고 절차를 따르고 공개 작업을 중단하세요. ## 신뢰할 수 없는 수신 데이터를 막고 위험한 보안 기본값은 꺼 두기 모든 소비자, 파서, 데이터 형식, 타입 변환기, 집계 저장소, 보안 관련 옵션을 구체적인 악용 경로에 비추어 검토하세요. - 신뢰할 수 없는 인바운드 메시지에서 프레임워크 내부 헤더를 디스패치 전에 엄격한 대소문자 비구분 방식으로 필터링하세요. - 적절한 입력 필터 없이는 신뢰할 수 없는 객체를 역직렬화하지 마세요. - 비밀 정보에는 비밀 메타데이터 표시를 하고, 안전하지 않은 구성 스위치는 위험 유형별로 분류하세요. - 보안에 민감한 기본값은 명시적으로 활성화하지 않는 한 거부 상태로 유지하세요. 기본값을 완화하려면 업그레이드 안내와 유지관리자의 명시적 승인이 필요합니다. - 인증 및 권한 부여 옵션이 발급자, 수신 대상, 서명과 보호한다고 명시한 모든 하위 경로를 실제로 강제하는지 확인하세요. 배포 시에는 프로덕션 보안 프로필을 사용하고, 승인된 비밀 저장소를 통해 비밀 정보를 가져오며, 검증된 TLS를 구성하고, 신뢰할 수 없는 소비자의 안전하지 않은 직렬화를 비활성화하며, 관리 콘솔과 런타임 관리는 신뢰할 수 있는 네트워크에만 두세요. 보안 검토에서는 신뢰할 수 있는 라우트의 동작과 프레임워크의 동작을 구분하는 동시에, 신뢰할 수 없는 데이터가 경계를 넘지 못하게 해야 합니다. ## 변경마다 테스트와 사용자 문서를 더하고 생성 파일도 커밋하기 모든 기능이나 버그 수정에는 적절한 테스트와 사용자용 문서가 포함되어야 합니다. 변경된 기본값, 발견 동작, 이름이 바뀌거나 제거된 옵션, 헤더 변경, API 또는 SPI 변경, 사용 중단 예정 항목, 마이그레이션을 관련 가이드에 문서화하세요. - 변경된 범위에 대해 저장소의 표준 포매팅, 임포트 순서, 스타일, 단위 테스트, 통합 테스트, 소스 검사를 실행하세요. - 생성된 산출물을 다시 생성하여 커밋하고, 생성된 변경 사항을 CI가 발견하도록 남겨 두지 마세요. - 로컬 검증 작업이 모든 분석기를 실행하지 않더라도 새로운 정적 분석 결함, 유지관리성 저하, 일반적인 약점 패턴, 사용 중단 예정 API를 만들지 마세요. - 클래스를 임포트하고 완전 수식 클래스 이름 대신 단순 이름을 사용하세요. 단, 두 클래스의 단순 이름이 같을 때는 예외입니다. 생성된 코드에 대한 명시적 제외는 유지하세요. - 새로운 모든 공개 API 타입과 메서드에 필수 도입 버전 태그를 추가하고, 예정된 릴리스 버전을 사용하며, 다른 문서 태그 뒤에 배치하세요. - 중첩 확장을 발견하는 모든 메타데이터 레지스트리를 갱신하세요. 소스 디렉터리만으로는 빌드, 카탈로그 또는 생성 문서에 확장이 표시되지 않을 수 있습니다. - 통합 테스트 컨테이너는 지원되는 모든 아키텍처에서 확인하세요. 이미지가 없는 경우 승인된 레지스트리 미러를 사용하거나 아키텍처별 제외를 명시하세요. - 내부 페이지에는 내부 문서 참조를 사용하고, 버전 간 앵커를 개발 브랜치뿐 아니라 대상 릴리스 버전을 기준으로 확인하세요. 기능의 사용 중단을 예고할 때는 빌드 메타데이터, API 어노테이션, 문서 제목, 업그레이드 가이드를 함께 갱신하세요. ## 병합 전에 검토자 2명을 지정하고 사람의 승인 1건 받기 풀 리퀘스트가 준비되었을 때만 검토를 요청하고, 초안 상태일 때는 절대 요청하지 마세요. - 최근 파일 이력과 blame 데이터에서 현재 활동 중인 관련 유지관리자를 찾아 적절한 검토자에게 최소 2명 이상 검토를 요청하세요. - 모든 댓글을 처리하고 모든 검사가 다시 통과하게 만든 뒤 기존 검토자에게 다시 검토를 요청하세요. - 해결되지 않은 검토 대화가 하나라도 남아 있으면 절대 병합하지 마세요. - 인간의 승인을 최소 1개 이상 요구하고, 에이전트가 자신의 풀 리퀘스트를 절대 승인하지 않도록 하세요. - 대상 브랜치에서 릴리스 마일스톤을 도출한 다음, 이슈를 닫기 전에 마일스톤과 이슈 수정 버전을 모두 설정하세요. - 풀 리퀘스트 작성자를 프로그래밍 방식으로 확인하고 풀 리퀘스트와 이슈를 올바르게 배정하며, 이슈 및 변경 내용에 부합하는 범주 레이블을 적용하세요. - 포매팅, 타입, 린트, 테스트, 보안 검사가 하나의 연속된 과정에서 성공한 경우에만 게시와 병합을 허용하세요. - 최종 병합 커밋에 필수 AI 공동 작성자 표기를 유지하세요. - 병합 후 이슈에 수정 버전과 풀 리퀘스트 링크를 남겨 해결한 다음 브랜치를 제거하세요. 사용자가 볼 수 있는 동작, 의미 있는 검증, 문서에 미치는 영향, 해결되지 않은 위험, 실행하지 못한 검사를 요약하세요. 로컬 테스트는 CI 성공을 입증하지 않으며, 불완전한 증거로 릴리스 준비가 완료되었다고 판단해서는 안 됩니다.