verify

Verify — 변경이 실제로 배포·동작하는지 구동 확인

"고쳤다"·"커밋했다"가 아니라 "신 코드가 라이브에서 실제로 도는가" 를 grep·프로세스·실행으로 확정한다. 어댑터(claude/codex/openai) 무관 — 전부 Bash 명령 수준. SYSTEM.md §1 「완료」 정의의 실행 절차.

A. 반영 실측 — 변경이 실제로 도는가

원칙: 네가 바꾼 소스와 지금 실제로 도는 것이 같은지 확인한다. 인터프리트 실행이면 리로드로, 컴파일·빌드 산출물이면 재빌드+재배포 후에야 반영된다 — 그 프로젝트의 배포·실행 방식을 따른다.

• ① 산출물–소스 일치: 이번에 바꾼 고유 마커(새 함수명·새 문구)가 실제로 도는 산출물에도 있는지 grep. 없으면 빌드/배포 누락(소스만 바뀐 상태). 옛 마커가 산출물에 남았는지 역방향으로도 확인하라 (신·구 공존 = 부분 빌드 신호).
• ② 시각 순서: 소스 수정 ≤ 빌드/배포 ≤ 프로세스 기동 순서여야 신 코드가 로드된 것. mtime 은 ls -la, 프로세스 기동은 ps -o lstart= -p <pid>. 소스가 산출물보다 새로우면 빌드 후 재수정된 것 — 재빌드부터.
• ③ 실동작 마커: 바뀐 경로를 실제 1회 흘려 로그·출력·응답에서 신 동작을 관측한다.
• 불일치 → 그 런타임의 재빌드·재배포 → 재실측. 소스 저장·커밋·typecheck 통과만 = 미완.

예 — 컴파일·빌드 후 배포되는 서비스: 소스 수정 → 재빌드 → 재배포/프로세스 재시작 → 도는 산출물에서 마커 grep(①) + 산출물 mtime vs 프로세스 기동시각(②) + 런타임 로그·응답에서 신 동작 관측(③). 인터프리트·핫리로드 런타임이면 빌드 단계 없이 리로드 후 ①③. 정적 사이트·스크립트도 같은 골격: 바꾼 것이 실제로 서비스되는 것에 반영됐는지 대조한다.

B. 분기 커버리지 — 새 분기를 실제로 탔는가

• 이번 변경에서 새로 만들거나 바꾼 조건분기를 나열한다(git diff 에서 if/삼항/switch/길이·개수 비교).
• 분기마다 그 분기를 실제로 타는 입력 최소 1개로 실측한다(단위 실행·수동 호출·실메시지). 예: length > 4096 분기를 새로 만들었으면 4096자 초과 입력을 반드시 하나 넣어본다.
• 기존 픽스처·테스트가 전부 같은 분기만 치면 새 경로는 미검증으로 명시하라 — "테스트 통과"가 그 분기의 검증이 아니다.

C. 행동 보존 대조 — 교체가 무엇을 잃었나 (교체·리팩터 시만)

• 옛 구현의 동작 인벤토리를 먼저 만든다: 입력 유형별 관측 동작·엣지 케이스·포맷 보장. (git show 로 교체 전 코드를 읽고 목록화 — 신 코드만 보고 추정 금지.)
• 신 구현과 항목별 대조: 각 옛 동작이 보존 / 의도적 변경 / 회귀 중 무엇인지 명시한다.
• 회귀를 '의도적 다운그레이드'로 합리화하지 마라 — 의도적 변경이면 그 근거와 사용자 영향을 적고, 근거가 없으면 복구한다.

D. 완료 보고 전 체크리스트

보고 직전 아래를 확인하고, 미충족 항목은 "미완/보류"로 명시한다(조용한 '완료' 금지):

• 라이브 반영됨(빌드·배포가 필요한 런타임이면 재빌드·재배포 실행)
• 산출물 마커 grep + 시각 순서(소스≤산출물≤기동) 통과 (§A①②)
• 새 분기마다 실입력 1개 실측 (§B)
• (교체·리팩터면) 옛 행동 인벤토리 대조 완료 (§C)
• 실동작 마커로 신 경로 1회 관측 (§A③)

경계 — code-review 와의 분업 (중복 구현 금지)

• code-review = 정적 결함 탐지("이 코드에 버그·더 나은 방법이 있나" — diff 를 읽는다). 반영 전.
• verify = 동적 구동 확인("이 변경이 실제로 반영·동작하나" — 산출물을 돌린다). 반영 후.
• verify 는 결함 분석을 재구현하지 않고, code-review 는 배포·부팅·분기 실측을 하지 않는다.