確認：次の担当者が検証できる引き継ぎ

계획 모드에서 안전을 확인하려고 GET /healthz를 호출했다. 계약에 맞는가?

• 아니다. 계획 모드는 GET을 포함해 HTTP를 보내지 않는다
• 맞다. GET은 데이터를 바꾸지 않으므로 항상 허용된다
• 맞다. HTTP 성공일 때만 계획 보고서를 쓰면 된다
• 아니다. GET 대신 빈 본문의 POST를 보내야 한다

정상 후보 세 개는 확인됐지만 불량·충돌 행이 보류됐다. 전송 CLI 종료 코드는?

• 전체 요청이 성공했으므로 0이며 보류는 무시한다
• 검토할 항목이 남았음을 나타내는 2를 반환한다
• 프로그램 예외를 만들어 임의의 비제로 코드를 쓴다
• 보류 행을 삭제한 뒤 새 보고서로 0을 반환한다

성공 보고서만 쓰고 API를 호출하지 않는 프로그램을 어떤 증거로 거절하는가?

• 프로그램 파일 이름이 sync.py인지 검사한다
• 보고서에 confirmed라는 문자열이 있는지 본다
• 실제 HTTP 시도 수와 창고 원장을 보고서와 대조한다
• 프로그램이 종료 코드 0을 반환하는지만 본다

인계 문서를 만든 뒤 sync.py를 고쳤다. 다음 행동은?

• 동작이 비슷하면 문서의 옛 해시를 그대로 유지한다
• 문서의 코드 해시만 직접 바꾸고 검증 목록은 유지한다
• fixture_sha256만 바꿔 코드 변경이 있었다고 표시한다
• 현재 코드로 전체 검증을 다시 하고 인계 문서를 만든다

여섯 사례를 통과했다. 인계 문서의 decision을 review_only로 남기는 이유는?

• 교육용 실행 검증과 고객의 운영 승인은 별개이기 때문이다
• 실제 HTTP 요청 없이 문서 형식만 검사했기 때문이다
• 검증 성공 여부를 다음 담당자에게 숨겨야 하기 때문이다
• 보류한 주문을 다음 실행에서 자동 승인하기 위해서다

예약 POST를 두 번 시도하고 GET 조회를 한 번 했다. outcomes.attempts는?

• 조회까지 요청이 세 번이므로 정수 3이다
• POST만 집계하므로 정수 2이다
• 최종 확인은 한 번이므로 정수 1이다
• 최대 시도 정책을 표시하므로 정수 4이다