버그 수정
근본 원인을 찾으세요. 증상을 고치지 마세요. 앱 또는 라이브러리 여부는 상관없습니다.
이 스킬은 수정이 성공한 후에만 prove-it을 로드하며, 사용자가 선택하거나 이미 증명을 요청한 경우에만 로드합니다. CopilotKit 디버그 스킬을 덮어쓰지 않습니다.
사용 시기
실패가 발생한 경우에 로드합니다: 테스트 실패, CI 빨간불, 예상치 못한 결과, 스택 트레이스, 또는 사용자가 '고장났다' / '수정해줘'라고 말할 때.
실패 없는 새로운 기능 작업은 건너뜁니다. 문서 및 타입 전용 편집도 건너뜁니다.
하드 게이트
- 로그에서 원인이 확인될 때까지 수정하지 않습니다. "몇 가지 시도해보는" 방식은 금지.
- 핫 경로에 대해 최소 세 가지 가설을 세워야 합니다. 각기 다른 위치(우리 함수, 호출자, 의존성)여야 합니다.
- 모든 가설 경로의 전후에 디버그 로그를 추가합니다. 서드파티 패키지에 디버그 모드가 있다면, 이 버그 추적 동안 활성화합니다.
- 원인이 확인되면: 이 스킬이 추가한 모든 로그를 삭제하고, 서드파티 디버그를 끕니다. 그런 다음 실패하는 테스트를 작성합니다. 그 다음 수정합니다. 로그가 수정 코드에 남아있으면 안 됩니다.
- 실패하는 테스트를 건너뛰거나, 삭제하거나, 비활성화하여 초록불을 만들지 마세요. 오류를 삼키지 마세요(
|| true, 빈 catch). 경쟁 조건을 숨기기 위해 타임아웃을 늘리지 마세요. - 근본 원인을 수정하고, 같은 파일/인접 모듈에서 동일한 패턴도 수정합니다. 추가 리팩토링은 금지.
- 사용자가 선택하거나 이미 이 수정에 대한 증명을 요청하지 않는 한
prove-it을 로드하지 마세요. 테스트 통과가 증명이 아닙니다. 기본값은 건너뛰기입니다.
핫 경로
실패하는 테스트(또는 사용자 동작)에서부터 오류 라인까지의 스택 아래, 그리고 그곳에서 호출하고 호출되는 함수들을 포함합니다.
거기서 시작하세요. 제거하세요. 좁혀가세요. 해당 경로의 모든 가설이 틀렸을 때만 넓힙니다.
절차
절차 1: 읽기
- 전체 오류, 스택, 또는 CI 로그를 읽습니다. 모든 줄을.
- 실패하는 테스트 본문이 있으면 읽습니다.
- 문제를 도입한 것으로 보이는 diff가 있으면 읽습니다.
- 아직 편집하지 마세요.
절차 2: 가설
- 핫 경로(파일 및 함수)를 매핑합니다.
- 최소 세 가지 가설을 작성합니다: "오류는 X 때문에 발생합니다. 왜냐하면 Y이기 때문입니다." 가설은 핫 경로 전체에 걸쳐야 합니다(한 줄에 대한 세 가지 추측이 아니라).
- 세 가지를 작성할 수 없다면, 충분히 읽지 않은 것입니다. 절차 1로 돌아갑니다.
절차 3: 계측
- 가설에 언급된 각 서드파티 패키지에 대해: 문서에서 디버그 플래그 또는 환경 변수를 확인합니다. 있으면 활성화합니다.
- 각 가설 분기 전후에 임시 로그를 추가합니다(입력, 출력). 저장소의 기존 로거나
console을 사용하세요. 로깅 패키지를 추가하지 마세요. - 한 번 재현합니다. 로그를 읽습니다. 로그가 무효화하는 가설을 제거합니다.
- 세 가지 모두 틀렸다면, 핫 경로를 한 단계 넓힙니다(다음 호출자 또는 다음 의존성). 새로운 가설. 새로운 로그. 다시 제거합니다.
- 하나의 원인이 확인되면: 이 스킬이 추가한 모든 로그를 삭제합니다. 서드파티 디버그를 끕니다. 작업 트리에 해당 로그가 남아있지 않은지 확인합니다.
절차 4: 실패 테스트, 그 다음 수정
- 이 버그 때문에 실패하는 테스트를 작성합니다(빨간불). 독립적인 예상 값을 사용하세요. 이 단계를 건너뛰지 마세요.
- 실행합니다. 지정한 이유로 실패해야 합니다.
- 근본 원인만 수정합니다. 같은 파일/인접 모듈에서 동일한 실수의 복사본도 수정합니다.
- 해당 테스트(초록불)를 실행합니다. 그런 다음 이 패키지/이 파일의 기존 테스트 모음을 실행합니다.
- 새로운 실패가 발생하면, 새로운 버그로 취급합니다. 절차 1부터 시작합니다. 새로운 중단 위에 첫 번째 수정을 배포하지 마세요.
절차 5: 선택적 증명(prove-it)
- 이 패키지의 테스트 모음이 초록불이고 로그가 사라진 후, 한 번 묻습니다. 옵션:
prove-it로드, 또는 건너뛰기. 기본값 건너뛰기. - 기다립니다. 사용자가 선택할 때까지
prove-it을 로드하지 마세요. - 사용자가 이 대화에서 이미 이 수정에 대한 증명을 요청했다면, 묻지 않습니다.
prove-it을 로드합니다. - 건너뛰기: 수정이 증명되지 않음을 사용자 경로로 말합니다. 초록불 테스트 모음을 증명으로 취급하지 마세요. 절차 6.
- 사용자가
prove-it을 선택하면:prove-it을 로드하고 따릅니다. 그런 다음 절차 6. - 앱을 클릭하거나, API를 호출하거나, 이 스킬 내에서 증명 보고서를 작성하지 마세요. 그 작업은
prove-it에 속합니다.
절차 6: 중지
건너뛰기 후, 또는 prove-it이 반환된 후, 중지합니다.
결정 트리
- 실패 발생 → 절차 1 → 2 → 3 → 4 → 5 → 6.
- 재현 불가 → 중지. 재현되지 않음이라고 말합니다. 단계를 요청합니다. 추측 수정하지 마세요.
- 로그가 모든 핫 경로 가설을 무효화 → 넓힙니다, 절차 2 다시.
- 수정 후에도 테스트가 여전히 빨간불 → 잘못된 원인입니다. 수정을 되돌립니다. 절차 2로 돌아갑니다.
- 다음 함수에서 동일한 패턴 발견 → 이 변경에서 함께 수정합니다(하드 게이트 6).
- 테스트 모음 초록불, 아직 증명 요청 없음 → 절차 5(물음, 기본 건너뛰기).
- 사용자가 이미 이 수정에 대한 증명을 요청함 →
prove-it을 로드한 후, 절차 6.
위험 신호
| 신호 | 의미 | 대신 할 일 |
|---|---|---|
| 하나의 가설, 그 다음 패치 | 추측 | 절차 2. 핫 경로에 세 가지. |
| 로그 없는 수정 | 제거 없음 | 절차 3. |
diff에 여전히 남아있는 디버그 console.log | 로그가 제거되지 않음 | 절차 3 단계 5. 그 다음 테스트. |
서드파티 DEBUG=*가 켜진 채로 남아있음 | 추적 플래그가 배송됨 | 로그와 함께 끕니다. |
.skip / 실패 테스트 삭제 | 증상 치료 | 코드를 수정합니다. |
| ` | true` / 빈 catch | |
| 더 긴 타임아웃 | 숨겨진 경쟁 조건 | 경쟁 조건을 수정합니다. |
| 수정 중 리팩토링 | 딴짓 | 근본 원인 + 같은 패턴만. |
| 전체 모노레포 테스트 실행 | 요청되지 않음 | 이 패키지 / 이 파일 모음. |
| "내 컴퓨터에서는 됩니다" | 다른 환경 | 실패와 같은 명령어 / 같은 조건. |
요청 없이 prove-it 로드 | 요청되지 않은 증명 | 절차 5. 기본 건너뛰기. |
| 이 스킬 내에서 미니 브라우저 통과 | prove-it의 중복 | 사용자가 선택한 후 prove-it을 로드합니다. |
| "테스트 통과했으므로 증명됨" | 초록불 모음을 증명으로 취급 | 절차 5. 건너뛰기는 증명되지 않음을 의미합니다. |
오류 처리
- 재현되지 않음: 그렇게 말합니다. 실행한 내용을 나열합니다. 수정을 지어내지 마세요.
- 의존성에 디버그 모드 없음: 그 단계를 건너뜁니다. 여전히 핫 경로에서 우리 코드를 로깅합니다.
- 로그가 너무 큼: 파일의 모든 줄이 아닌 가설 분기만 로깅합니다.
- 아직 실패 테스트를 작성할 수 없음(테스트 도구 없음): 버그를 단언하는 단일 파일 스크립트를 대체로 사용합니다. 여전히 빨간불, 그 다음 수정, 그 다음 초록불.
- 수정이 다른 테스트를 실패하게 함: 해당 실패에 대해 절차 1. 연쇄 문제가 해결될 때까지 첫 번째 수정을 푸시하지 마세요.
- 이 에이전트에
prove-it이 없음: 그렇게 말합니다. 건너뛰기를 제안합니다. 여기서 두 번째 증명 절차를 지어내지 마세요. - 사용자가
prove-it을 선택한 후 그 안에서 건너뛰기: 수정이 증명되지 않았습니다. 절차 6.
이 스킬은 도우미를 배치하거나 문서를 작성하지 않습니다. 증명은 절차 5에서만 가능합니다.