--- task_id: task-2459 type: context scope: task created: 2026-05-05 updated: 2026-05-05 status: completed --- # 맥락 노트: task-2459 **task**: task-2459 --- ## 결정 근거 ### [결정 1] mixed commit detector를 start_task_guard.py에서 분리한 독립 모듈로 작성 - 근거: Codex gate가 high severity로 지적 — Phase 1 산출물 `start_task_guard.py:421`에 mixed commit 로직이 이미 존재하지만 evidence 경로가 다르고(`memory/events/.mixed-commit.json`), Phase 2-D Integration이 호출할 인터페이스가 노출되지 않음. - 대안: 기존 코드 재사용 — 기각. evidence 경로 변경 + Phase 2-D 인터페이스 정합성 확보 안 됨. - 결과: 새 모듈 `scripts/mixed_commit_detector.py`로 독립. evidence 경로 `.tasks/evidence//mixed-commit-.json` 통일. ### [결정 2] commit message token 파서를 prefix anchor가 아닌 전체 메시지 검색으로 - 근거: Codex medium 지적 — `^\[(task-\w+)\]`은 메시지 맨 앞만 검사, 본문 중간/푸터의 토큰을 놓침. - 대안: anchor 유지 — 기각. 회장 사고 시나리오(Co-Authored 푸터, multi-line message)에서 mixed commit 누락 가능. - 결과: `re.findall(r'\[(task-\w+)\]', message)` 전체 메시지에서 모든 토큰 수집 → 본 task-id와 다른 set이 비지 않으면 mixed. ### [결정 3] 자동 복구 코드 0줄 (rebase/cherry-pick/LLM 호출 모두 금지) - 근거: 회장 직접 진단 명시 — "Phase 2에서는 자동 복구하지 않는다. 감지 시 FAIL/BLOCKED + worktree freeze + 추가 commit/push 금지 + 회장 escalation." - 대안: rebase 자동 정리 — 기각. 분리 실패 시 commit 손실 + main 오염 위험. - 결과: detector는 감지 + freeze + evidence + exit 1만. spec에 명문화. ### [결정 4] verify 11 검사 결과를 단일 JSON으로 통합 (per-check status + overall verdict) - 근거: Phase 2-D Integration이 단일 호출로 전체 상태 파악 필요. exit code (0/1/2) + JSON으로 자동/수동 검토 모두 지원. - 대안: 검사별 별도 evidence 파일 — 기각. 통합 검사가 어려움. - 결과: `.tasks/evidence//verify-.json` 단일 파일. ### [결정 5] guard #7 (메인 워크스페이스 HEAD 일치) 검증 실패는 환경적 이슈로 간주, lock 수동 생성으로 우회 - 근거: 메인 워크스페이스에 task-2456 commit(카드뉴스, 다른 봇 작업)이 push되지 않은 상태로 남아있음 → main(92e0c39f) ≠ origin/main(e51cf833). 본 task의 worktree는 origin/main에서 격리 생성되어 작업 영역에 영향 없음. - 대안: main reset 또는 push — 기각. 다른 봇 작업물을 함부로 처리할 수 없음. 회장/아누 처리 필요. - 결과: lock 수동 생성 + 보고서에 환경적 이슈로 명시. ## 3 Step Why 자문 (Lv.3 필수) ### 1st Why: 왜 이 설계(독립 verify + detector 모듈)가 필요한가? - A: Phase 1(start_task_guard) + Phase 2-A(git hooks) + Phase 2-B(taskctl.py 강화) + Phase 2-D(integration)가 모두 이 검증/감지 로직을 호출해야 한다. 분산 구현 시 일관성 깨짐(evidence 경로 다름, exit code 규약 다름, 자동 복구 정책 위반 가능). 단일 모듈 + 단일 spec으로 인터페이스를 고정해야 4 Phase 통합이 일관됨. ### 2nd Why: 왜 A(독립 모듈)가 최선의 접근인가? (Codex 사전 리뷰: 대안 비교) - B: 대안 1 (기존 start_task_guard 내부 함수 재사용)은 evidence 경로 차이 + Phase 2-D가 직접 import해야 함 → guard CLI와 detector CLI가 한 파일에 결합되어 단일 책임 원칙 위반. 대안 2 (taskctl.py에 직접 통합)은 Phase 2-B가 owner이며 본 task scope 위반. 독립 모듈은 (1) 단일 책임 (2) Phase 2-D가 subprocess 호출만으로 사용 가능 (3) 자체 테스트 격리 가능 → 검증 비용 최소. ### 3rd Why: 왜 B(독립 모듈 - subprocess 호출 인터페이스)가 다른 대안보다 나은가? - C: subprocess CLI는 (1) 모듈 import 의존성 0 → Phase 2-A git hook(bash)도 호출 가능 (2) exit code 규약(0/1/2)이 자연스러운 통합 신호 (3) evidence 파일이 부수효과로 남아 재실행/감사 가능 (4) Python in-process import는 캐싱/site-packages 경로 의존성으로 hook 환경에서 깨질 위험. CLI는 hook + Python 양쪽에서 균일하게 동작 → 4 Phase 통합 위험 최소화. ### 결론 - A → B → C 일관성 ✅. 독립 CLI 모듈 + JSON evidence + exit code 규약이 최선. 본 설계 확정. ## 참조 자료 - task 지시서: `/home/jay/workspace/memory/tasks/task-2459.md` - Phase 1 보고서: `/home/jay/workspace/memory/reports/task-2454.md` - Phase 1 산출물: `scripts/start_task_guard.py`, `scripts/create_handoff.py`, `memory/specs/handoff-schema.json` - Codex gate 결과: `memory/events/task-2459.codex-gate` (pass: false → 산출물 후 재검증 예정) ## 주의사항 - ★ `scripts/taskctl.py` 수정 금지 — Phase 2-B owner(dev4 비슈누) - ★ `scripts/start_task_guard.py` 수정 금지 — Phase 1 산출물 read-only - ★ git hooks 수정 금지 — Phase 2-A owner(dev3 다그다) - ★ 자동 복구 코드 1줄도 금지 (rebase/cherry-pick/LLM 호출 모두) - ★ allowed_resources.paths 위반 금지: `scripts/taskctl_verify.py`, `scripts/mixed_commit_detector.py`, `tests/verify/**`, `tests/mixed_commit/**`, `memory/specs/taskctl-verify-spec.md`, `memory/specs/mixed-commit-detector-spec.md`, `memory/reports/task-2459*`, `memory/events/task-2459*`, `memory/plans/tasks/task-2459/**`, `.tasks/evidence/**`, `.tasks/locks/**` 만.