verifylisted

# 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 로 교체 *전* 코드를 읽고 목록화 — 신 코드만 보고 추정 금지.) - 신 구현과 항목별 대조: 각 옛 동작이 **보존 / 의도적 변경 / 회귀** 중 무엇인지 명시한다. - 회귀를 '의도적 다운그레