AI 모델을 평가하는 대규모 TypeScript 리포지토리를 수정하고 테스트하기

## 리뷰인지 수정인지 정하고 가까운 에이전트 가이드 읽기 먼저 리포지토리 루트, 요청된 결과, 변경을 소유하는 하위 시스템을 파악하세요. 대규모 리포지토리는 핵심 라이브러리, CLI, 웹 애플리케이션, 영속성 계층, 프로바이더, 스케줄러, 스키마, 유틸리티, 테스트, 문서, 예시, 마이그레이션, 자동화, 보안 도구에 책임을 나누는 경우가 많습니다. 디렉터리를 편집하기 전에 해당 범위에 가장 가까운 에이전트 가이드와 작업별 설계 또는 워크플로 문서를 읽으세요. 로컬 가이드는 테스트, 생성 파일, 공개 계약, 데이터베이스 접근, 릴리스 동작에 관한 루트 규칙을 구체화할 수 있습니다. 실행하기 전에 요청을 분류하세요. - 검토 또는 감사는 읽기 전용입니다. 현재 branch, diff, 댓글, CI를 살펴보고, 유용할 때 상태를 변경하지 않는 검사를 실행하며, 파일을 commit하거나 push하거나 다시 쓰지 않고 결과를 보고하세요. - 수정, 개선, 반영 요청에는 기능 branch에서 수행하는 일반적인 구현 순환이 포함됩니다. 조사, 변경, 검증, commit, push를 수행하고 관련 CI를 추적하세요. - 동작 변경은 분리된 단위 테스트만이 아니라 사용자가 이용하는 워크플로를 통해 입증해야 합니다. 올바른 루트에서 작업하고, 실패를 확정적인 근거로 취급하기 전에 런타임과 패키지 관리자 버전을 리포지토리 선언에 맞추세요. 새 checkout에서는 모듈 누락을 코드 결함으로 단정하기 전에 결정론적인 종속성 설치를 수행하세요. 변경 범위를 건드린 하위 시스템과 그 직접적인 사용처로 제한하세요. 또 다른 추상화를 만들거나 패키지를 추가하기 전에 기존 구현, 유틸리티, 종속성, 인접한 패턴을 검색하세요. ## 실제 CLI, API, 브라우저 흐름에서 변경 테스트하기 우연한 도구 호출로 우회하지 말고 리포지토리에 선언된 스크립트와 래퍼를 사용하세요. 래퍼에서 요구할 때 패키지 실행기의 구분자를 통해 명령 플래그를 전달하고, 리포지토리 단위 평가는 리포지토리 루트에서 실행하세요. 범위를 점차 넓히며 검증을 선택하세요. 1. 변경된 모듈을 대상으로 한 테스트를 실행하세요. 2. 관련 타입, lint, 포맷 검사를 실행하세요. 3. 영향을 받는 통합 테스트 모음을 실행하세요. 4. 로컬 빌드로 실제 CLI, 예시, API 또는 브라우저 흐름을 실행하세요. 5. 위험이나 리포지토리 정책이 정당화할 때만 더 넓은 테스트 모음을 실행하세요. 평가형 워크플로에서는 캐시를 지우지 말고 결과 재사용을 비활성화하세요. 기계가 읽을 수 있는 결과를 내보내고 사례별 성공, 점수, 오류, 프로바이더 출력, 추적, 보안 결과를 확인하세요. 종료 상태가 제로여도 집계 임계값을 통과했다는 뜻일 뿐일 수 있으며 모든 사례가 성공했음을 입증하지 않습니다. 워크플로에 자격 증명이 필요하고 파일이 존재할 때만 환경 파일을 불러오세요. 백그라운드 프로세스가 소리 없이 사라지지 않도록 서비스를 활성 세션에 연결된 상태로 유지하세요. 프레임워크 기본값을 가정하지 말고 시작 출력이나 포트 검사로 실제 수신 포트를 확인하세요. 요청에서 요구하지 않는 한 정적 프로덕션 뷰어나 다른 개발 서버를 시작하지 마세요. 먼저 예상 서비스가 이미 실행 중인지 확인하세요. 시작하면 사용자 세션과 충돌할 경우 실행 전에 물어보세요. 문서, 스키마, 마이그레이션, 인용이 생성되는 경우 해당 정본 생성기를 사용하고 결과물을 검증하세요. 지원되는 빠른 경로가 있다면 이를 통해 문서를 테스트하되 변경에 중요한 검사를 조용히 건너뛰지 마세요. ## 실패를 재현한 뒤 디버깅하고 캐시나 데이터를 지우지 않기 장애가 드러났을 때와 동일한 입력, 상태, 실행 경로로 실패를 재현하세요. 구조화된 디버그 로깅을 켜고 해당 실행의 캐시 읽기를 비활성화한 뒤 코드를 변경하기 전에 실패 범위를 좁히세요. 환경 실패와 제품 실패를 구분하세요. - 런타임 또는 패키지 관리자 버전 불일치는 환경 문제입니다. - 깨끗한 checkout에서 종속성이 누락되었다면 일반적으로 결정론적인 설치가 필요합니다. - 오래된 빌드는 지원되는 로컬 래퍼를 통해 다시 빌드해야 합니다. - 환경을 맞춘 뒤에도 같은 코드 경로에서 발생하는 결정론적 실패는 제품 결함의 근거입니다. 테스트를 통과시키기 위한 목적으로 캐시, 데이터베이스, lockfile, 생성된 기록, 사용자 데이터를 삭제하거나 비우지 마세요. 캐시를 사용하지 않는 옵션, 임시 격리 저장소, 읽기 전용 조사를 우선하세요. 삭제에는 명시적인 승인과 정확한 대상이 필요합니다. secret은 무시 대상 환경 파일이나 승인된 secret 저장소에 보관해야 합니다. 자격 증명을 로그, 코드, branch 이름, commit 메시지, 검토 문구, 스크린샷, 예시 명령에 출력·삽입·commit·복사하지 마세요. 원본 자료에서 발견된 자격 증명은 재사용할 수 있는 지침이 아니라 유출된 데이터로 취급하세요. 객체 컨텍스트와 정제 계층을 갖춘 프로젝트의 구조화 로거를 사용하세요. 그래도 로거에 필요 없는 secret을 제공하지 마세요. 오류 처리는 민감한 payload를 노출하지 않으면서 타입이 지정된 컨텍스트를 보존해야 합니다. 여러 원인 가설을 세우고 대상이 명확한 검사로 하나씩 배제하세요. 최소 수정 전이나 동시에 관찰된 동작에 대해 실패하는 회귀 테스트를 추가하고, 원인이 불확실한 동안에는 무관한 리팩터링을 피하세요. ## 기능 브랜치로 변경을 반영하고 CI 통과까지 지켜보기 모든 변경은 기능 branch와 pull request를 거쳐야 합니다. 명시적 승인 없이 보호 branch에 직접 commit하거나 hook을 우회하거나 force-push하지 마세요. 기본적으로 새 commit을 만들고, 관리자가 해당 기록 작업을 요청한 경우에만 amend, squash, rebase를 수행하세요. 의도한 파일만 stage하고 범위가 한정된 lint와 포맷 검사를 실행하며 리포지토리의 commit 규칙을 사용하세요. 중복 pull request를 만들지 말고 해당 branch에 이미 열려 있는 pull request를 업데이트하세요. 무관한 lockfile이나 종속성 변동을 변경에 포함하지 마세요. 사용자가 기능 branch 변경의 수정, 개선, 반영을 요청하면 모든 일반 단계에서 멈추지 말고 승인된 순환을 완료하세요. 요청대로 동기화하고 대상 검증과 실제 워크플로를 실행하며 commit, push, CI 관찰까지 진행하세요. 이 승인을 보호 branch, 파괴적인 기록 변경, 정보 공개, 프로덕션 작업으로 확대하지 마세요. merge 후 보호 branch의 새 CI 실행을 완료될 때까지 추적하세요. 대응하기 전에 실패를 분류하세요. - flake는 비결정적인 인프라 또는 worker 잡음이며, 특히 테스트가 성공적으로 완료된 뒤 job이 실패한 경우가 해당됩니다. 실패한 job만 다시 실행하고 복구를 확인하세요. - 실제 회귀는 결정론적이며 변경에 귀속됩니다. 후속 pull request를 통해 보호 branch를 복원하세요. 공유 branch가 깨졌다면 신속한 revert를 우선하세요. - 반복되는 flake는 그 자체가 결함입니다. 무기한 다시 실행하지 말고 누출된 리소스, 취약한 설정, 비현실적인 timeout을 수정하세요. 보호 branch가 green인 상태로 마치거나, 기존에 있던 무관한 실패를 뒷받침 로그와 함께 명시하세요. 실행한 검사, 확인한 근거, 완료하지 못한 검증을 보고하세요. ## 보안을 먼저 검토하고 공격자 관점으로 테스트하기 일반적인 정확성보다 보안 회귀를 먼저 검토하세요. 프롬프트 인젝션, 적대적 입력의 안전하지 않은 처리, 자격 증명 노출, 서버 측 요청 위조, 경로 순회, 안전하지 않은 역직렬화, 인가 오류, 데이터 유출, 안전하지 않은 도구 사용, 캐시 오용, 근거 누락을 우선하세요. 그다음 공개 계약, 데이터 무결성, 동시성, 오류 처리, 프로바이더 상호 운용성, 영속화된 결과를 깨뜨릴 수 있는 동작을 살피세요. 변경이 보안 동작, 공개 인터페이스, 버그 수정에 영향을 미칠 때 누락되거나 효과 없는 테스트 범위를 높은 우선순위로 취급하세요. 공격자의 관점에서 보안과 모델 평가 기능을 테스트하세요. 거짓 음성, 우회, 숨겨진 payload, 중첩된 지침, 인코딩 기법, 안전하지 않은 도구 호출, 불완전한 추적을 확인하세요. 우회를 발견하면 원래 공격 벡터를 대상이 명확한 회귀 테스트에 보존하세요. 변경된 diff와 현재 branch 끝을 기준으로 검토하세요. 기존 댓글, 자동 검토, issue 보고는 단서이지 증거가 아니므로 동기화 후 다시 검증하세요. 해결된 결과를 반복하거나 변경으로 악화되지 않은 무관한 기존 결함을 지적하지 마세요. 공개되지 않은 취약점에 대한 변경을 공개하기 전에 조정된 공개 절차에서 공개를 허용하는지 확인하세요. 그때까지는 승인된 비공개 협업 경로를 사용하고 식별자, exploit 세부 정보, 취약한 버전 범위, 내용을 드러내는 branch 이름을 피하세요. 모든 보안 수정에는 원래 벡터에 대한 회귀 테스트를 포함해야 합니다. 적대적 테스트를 가르치기 위한 데모 애플리케이션에서는 데모 강화가 명시적인 목표가 아닌 한 의도적인 약점을 제거하지 마세요. 검토 스크린샷에는 승인된 호스팅 워크플로와 승인된 자격 증명만 사용하세요. 업로드 키를 노출하거나 부수적으로 생긴 이미지를 commit하지 마세요. ## 엄격한 TypeScript를 쓰고 마지막 diff 검토하기 리포지토리의 모듈 시스템과 컴파일러 경계를 따르는 엄격하고 관용적인 TypeScript를 작성하세요. 직접 import, `const`, 객체 축약형, 일관된 중괄호, `async`/`await`, 타입 지정 오류 검사, 신뢰할 수 없는 경계에서의 스키마 검증을 우선하세요. 코드베이스가 직접 소유권을 요구할 때는 재export 배럴을 피하세요. helper나 종속성을 추가하기 전에 확립된 구현과 로컬 유틸리티를 재사용하세요. 기존 예시 패턴을 통해 프로바이더와 통합 설정을 문서화된 상태로 유지하세요. 프런트엔드와 백엔드 규칙이 다를 때 각각을 포함하여 성공과 실패 경로를 모두 테스트하세요. 데드 코드 보고를 설계 피드백으로 취급하세요. - 실제로 사용되지 않는 코드는 제거하세요. - 규칙에 따라 불러오는 worker, fixture, 대체 항목은 로딩 방식을 설명하는 주석과 함께 명시적 항목으로 등록하세요. - 외부에서 사용하는 export는 사용처를 명시한 주석이 있을 때만 허용 목록에 추가하세요. - 문서화된 사용처를 확인할 때까지 허용 목록 항목이나 보호된 export를 제거하지 마세요. 생성된 changelog나 다른 생성물을 직접 편집하지 마세요. 소스를 변경하고 정본 생성기를 실행하세요. 예시는 실행에 충분한 문서와 함께 지정 영역에 보관하세요. 완료 전에 최종 diff에서 의도하지 않은 파일, 오래된 생성물, secret 자료, 범위 확대가 있는지 검토하세요. 대상 테스트, 관련 통합 검사, 실제 사용자 경로를 확인하세요. 결과를 정확히 설명하여 무엇이 통과했고 무엇을 확인했으며 무엇이 미검증 상태이고 실패가 무관한지 구분하세요.