Handoff Strategy: Handoff = hypothesis 원칙 명문화

[bluejayA]

배경

docs/analysis/2026-04-24-handoff-strategy-comparison.md §4.2 참조.

외부 블로그(https://codex.epril.com/claude-session-context-handoff-4-layer-strategy)의 핵심 원칙:

Handoff는 fact가 아니라 hypothesis로 다뤄야 한다.

이전 세션이 혼동 상태에서 문서를 썼다면 새 세션이 그 오류를 그대로 이어받는다. 우리 시스템은 태스크 재검증 프로토콜은 있지만, handoff 문서 자체의 검증 은 없다. session-summary.md의 주장(예: "Unit X 완료")이 실제 코드와 일치하는지 확인하는 단계 부재.

액션

1. skills/_shared/patterns/session-continuity.md에 "Handoff = hypothesis" 원칙 섹션 추가:
   • session-summary.md의 모든 claim은 코드/git 상태와 대조해 검증해야 함
   • 검증 실패 시 session-summary.md를 우선 갱신 후 작업 재개
2. orchestrator 재개 step에 "summary verification" 게이트 추가:
   • ## Completed Work [x] Unit-X 가 있다면, 실제 devflow-docs/construction/unit-x/와 git log로 교차 확인
   • 불일치 시: 사용자에게 보고 + summary 수정 후 진행

연동

• BL-093(작성 규칙) [10/13] application-design 최종안에 제3자 AI 리뷰 + 반영 분석 프로세스 추가 #4 "검증 지시 포함"의 시스템 측 강제
• 기존 §4 "태스크 재검증 프로토콜"을 confirm("문서 vs 실재") 단계로 확장

영향도

• 수정 대상:
  • skills/_shared/patterns/session-continuity.md (원칙 + verification 게이트 정의)
  • aidlc-using-devflow, aidlc-construction-orchestrator, aidlc-executing-plans (재개 step에 verification 호출 추가)
• 토큰 비용: 재개 시 1회 추가 read (audit.md, 산출물 디렉터리). 부담 작음
• 부작용: false positive(문서가 옳은데 코드가 안 맞음) 발생 시 사용자 결정 게이트 필요

Priority

P2 (영향 고, 난이도 저)

[bluejayA]

Codex 세컨드 오피니언 반영 — 설계 전제 재검토 필요

Codex 권고 핵심: "post-tool-file-edit가 session-summary/devflow-state를 audit 제외 → 증거 부족 상태에서 verification이 false positive 발생 가능. hard gate 위험"

사실 검증 결과 (코드 확인 완료)

hooks/post-tool-file-edit:97-100:

case "$REL_PATH" in
  ...
  devflow-docs/.archive/*|devflow-docs/archieve/*|devflow-docs/audit.md|devflow-docs/audit-log/*)
    exit 0 ;;
  devflow-docs/devflow-state.md|devflow-docs/session-summary.md)
    exit 0 ;;
esac

→ session-summary.md, devflow-state.md는 명시적으로 audit에서 제외됨. (의도: self-amplification 방지)

영향

원안 BL-095의 verification 게이트는 "session-summary의 claim vs audit.md의 file-edit 이벤트" 대조를 가정했으나, session-summary 자체의 변경 이력이 audit에 없음. 비교 가능한 evidence가 약함.

대안 evidence 소스:

• git log (산출물 파일 commit history) — 가장 신뢰성 높음
• devflow-docs/construction/<unit>/ 디렉터리 존재 여부
• 산출물 파일 내 체크리스트 ([x] 마커)

스코프 축소안 — Hard gate → Advisory 모드

단계	동작	비고
Phase 1 (advisory)	session-summary의 [x] Unit-X 발견 시 git log + 산출물 디렉터리 확인. 불일치 시 경고 + 증거 링크 표시, 작업은 계속	false positive 모니터링
Phase 2 (semi-strict)	1주 운영 후 false positive < 임계점이면 사용자 confirm 게이트 추가	로그 누적 후 결정
Phase 3 (strict)	신뢰도 충분 시 hard gate (재개 차단)	옵션

다음 세션에서 결정할 것

1. Phase 1만 BL-095로 두고 Phase 2/3는 별도 BL로 분리할지
2. evidence 소스로 git log 사용 시 commit 누락 케이스 처리 (WIP 코드)
3. "Handoff = hypothesis" 원칙 명문화 자체는 verification 게이트와 분리 가능 — 원칙만 먼저 도입하는 minimal 안 검토

추가 — Codex가 언급한 보류안 BL 승격 후보

docs/analysis/2026-04-24-handoff-strategy-comparison.md §6의 보류안 #4(In-session 관리 가이드: /compact focus 강제, 60% 임계점)는 Codex가 "난이도 저, 효과 즉시"로 승격 권장. BL-096으로 등록 후보. BL-095와 무관하게 병행 가능.

[bluejayA]

결정 (2026-04-24)

Phase 분리. 본 이슈(BL-095)는 Phase 1: 원칙 명문화만 담당. Phase 2(시스템 강제 verification gate)는 신규 이슈 #184로 분리.

분리 사유:

• Phase 1은 session-continuity.md에 원칙 텍스트 추가 → ROI 즉시, 충돌 0
• Phase 2는 3개 orchestrator 수정 + false-positive 결정 게이트 설계 필요 → 영향 범위 다름
• 효과 측정도 분리 가능 (Phase 1 정착 후 강제 도입 판단)

evidence 소스 결정 (Phase 2에 적용):

• 산출물 디렉터리 존재 + git log 조합 (예: devflow-docs/construction/unit-x/ 존재 + 관련 커밋)
• audit.md는 자기 보고이므로 보조 (handoff = hypothesis라는 본 원칙과 audit.md 신뢰는 모순)

본 이슈 범위 축소: session-continuity.md에 "Handoff = hypothesis" 원칙 섹션 추가 + 사용자 가이드. orchestrator 코드 수정은 #184에서.

[bluejayA]

PR #188 작성 완료. Phase 1만 다루며, Phase 2(verification gate)는 BL-095b (#184)에서 진행.