wesleymatosdev/proof-bearing-verification

증명을 수반한 검증 (Proof-Bearing Verification)

기존 구현, 위임된 작업, 또는 전달 준비 상태를 검토할 때 사용하세요. 초록불 명령어, 정적 리뷰, 또는 에이전트 요약만으로는 증명이 될 수 없습니다. 반드시 주장하는 행동을 실제로 실행해야 합니다.

사용 시기

• 에이전트가 작업이 완료되었다고 말할 때.
• 테스트는 통과했지만, 테스트가 행동을 얼마나 강력하게 검증하는지 알 수 없을 때.
• 버그 수정, UI 변경, 통합, 또는 운영 변경에 대한 검증이 필요할 때.
• 정적 리뷰의 결과가 이전에 런타임에서 검증된 행동과 충돌할 때.

새로운 코드를 작성할 때 test-driven-development를 대신하여 사용하지 마십시오. 구현 이후 또는 구현과 함께 증거를 검증하는 데 사용하십시오.

절차

1. 주장된 행동을 명명하세요.

   • 사용자에게 보이거나 외부에서 관찰 가능한 결과를 명시하세요.
   • 완료 조건: 구현 세부 사항을 참조하지 않고도 주장을 테스트할 수 있어야 합니다.

2. 실제 환경에 가장 가까운 시임(seam)을 선택하세요.

   • import 전용이나 스냅샷 전용 테스트보다 마운트된 컴포넌트 상호작용, 통합 요청, CLI 호출, API 호출, 또는 종단간 흐름을 선호하세요.
   • 실제적인 페이로드와 프로덕션 형태의 픽스처를 사용하세요.
   • 완료 조건: 프로브가 행동이 주장되는 코드 경로에 도달해야 합니다.

3. 프로브(probe)에 이빨이 있는지 증명하세요.

   • 변경되거나 제거된 행동의 경우, 구현 없이 또는 안전할 때 의도적으로 no-op을 넣어 먼저 실패를 관찰하세요.
   • 변경된 유닛을 우회했을 때도 여전히 초록불이 유지되는 테스트는 공허한 증거이며, 증거로 사용해서는 안 됩니다.
   • 완료 조건: 프로브가 정상 동작과 관련된 고장 동작을 구별할 수 있어야 합니다.

4. 증명을 실행하고 검사하세요.

   • 집중 검사를 실행한 다음, 프로젝트의 적용 가능한 더 넓은 검사를 실행하세요.
   • 작성자의 요약을 신뢰하지 말고 테스트 또는 테스트 하네스를 직접 읽으세요.
   • 완료 조건: 출력과 구현 모두 정확한 주장을 뒷받침해야 합니다.

5. 상충하는 증거를 처리하세요.

   • 사용자가 검증한 런타임 행동은 정적 리뷰 권장 사항으로 대체하기 전에 설명을 요구하는 증거로 취급하세요.
   • 명백한 모순을 일으키는 프레임워크, 캐시, 인프라, 또는 런타임 의미론을 추적하세요.
   • 완료 조건: 모든 변경은 리뷰어의 확신이 아닌 가장 강력한 사용 가능한 증거를 따라야 합니다.

함정

• Node에서 브라우저 콘솔 행동을 검증하지 마세요. Node의 console.log는 %c를 지원하지 않습니다. 스타일 문자열을 일반 인수로 처리하고 조용히 버리므로, Node/Python 하네스는 깨끗한 그리드를 출력하지만 실제 DevTools 렌더링의 문제를 숨깁니다. 콘솔 출력을 검증하려면 실제 브라우저를 CDP를 통해 구동하거나(헤드리스 Chrome --remote-debugging-port + Runtime.consoleAPICalled를 캡처하는 WebSocket 스크립트), 실제 콘솔에서 사용자에게 보이는 증거를 얻으세요. 다른 콘솔 엔진에서 실행되는 하네스는 증명이 아닙니다.
• 매우 많은 %c 세그먼트가 포함된 console.log 하나는 DevTools를 오버플로시킵니다. 콘솔 포매터는 한 번에 하나의 지정자(specifier)씩 인수를 소비합니다. 단일 호출에 너무 많은 스타일 세그먼트(예: 약 193개)가 있으면, 끝부분의 스타일 문자열이 스타일로 소비되지 않고 일반 텍스트로 그대로 출력됩니다(고전적인 color:#...;font-family... 쓰레기 덤프). Chrome 문서에 따른 해결책: 줄/행당 하나의 console.log를 사용하고, 각각에 제한된 수의 %c 실행을 포함하세요. 이것이 하나의 거대한 console.log('%c%s%c%s...')로 문자 단위 ASCII 아트를 그리면 스타일이 새는 이유입니다.
• "던지지 않고 렌더링됨", 타입 전용 픽스처, 테스트 대상 유닛을 대체하는 모의 객체(mock), .todo() 테스트는 행동을 증명하지 않습니다.
• 얕은 테스트 스캐폴딩을 만족시키기 위해 프로덕션 행동을 변경하지 마십시오.
• 외부 의존성, UI 상호작용, 또는 배포 경로가 실행되지 않았을 때 완료를 주장하지 마십시오. 검증되지 않은 경계를 보고하세요.

검증

완료 보고서에는 다음이 포함되어야 합니다: 증명된 행동, 사용된 정확한 명령어 또는 작업, 관찰된 결과, 그리고 검증되지 않은 모든 경계.