---
task_id: task-2488
type: context
scope: task
created: 2026-05-08
updated: 2026-05-08
status: completed
---

# 맥락 노트: task-2488

**task**: task-2488

---

## 결정 근거

### 핵심 결정 1 — 격리 경로 `tools/poc/cycle_advancer/`
- 이유: 회장 명시 "production 격리, 외부 AI 호출 mock"
- 대안: production scripts/ 직접 생성 → 기각 (forbidden_actions: production_path_modification 위반)
- 대안: `.poc/` hidden dir → 기각 (gitignore 충돌 가능, 가시성 부족)

### 핵심 결정 2 — Mock LLM은 deterministic stub
- 이유: 합격 조건 #4 "deterministic 출력 (mock seed 고정)"
- 구현: 입력 task_id → 미리 정의된 응답 dict 매핑 (hash-stable)
- 대안: random + seed → 기각 (mock fixture 변형 시 회귀 깨짐)

### 핵심 결정 3 — 회귀 fixture: task-2485 → task-2486
- 이유: 합격 조건 #3, 실제 chain 사례로 mapping 검증 가능
- 입력: task-2485 evidence (CODE_PASS / MERGE_PENDING_DEPENDENCY 분류)
- 기대 출력: task-2486 같은 "CI workflow SHA payload fix" 제안서 (stub 매핑)

### 핵심 결정 4 — analyzer 5단계 (task 명세 그대로)
1. gap analysis (목표 vs 실제 결과)
2. root cause 후보 N개 생성 (mock = 3개 stub)
3. 마아트(facts) + 외부 AI(strategy) 비평 시뮬레이션
4. 합의/충돌 판정
5. 다음 task 제안서 draft 생성

### 핵심 결정 5 — 합의 시 `proposal_only=True, ready_for_dispatch=False`
- 이유: 회장 금지 "real_dispatch", "real_done_creation"
- 출력 yaml frontmatter에 명시. dispatch.py가 이 플래그를 보고 거부하도록 설계

## 3 Step Why 자문

**1st Why: 왜 이 PoC가 필요한가?**
A: 회장과 ChatGPT의 closed loop를 시스템화하려면, 먼저 evidence → 다음 task 제안 매핑 로직을 검증 가능한 형태로 코드화해야 한다. PoC 없이 production 통합 시 회귀 위험 큼.

**2nd Why: 왜 dry-run + mock adapter 접근이 최선인가?**
B: Phase B는 회장 결정 대기 상태. 실제 외부 AI 호출 + dispatch는 정책 결정 전. mock으로 형태/계약을 먼저 못박으면, 정책 결정 후 adapter만 교체해 production 진입 가능. 또한 deterministic 회귀로 mapping 로직 자체의 정합성 검증 가능.
**대안 평가**:
- 실제 LLM 호출 → 비용 + 비결정성 + 정책 미정 상태 위반
- 문서만 작성 → 회장 명시 "코드 PoC" 미충족
- production 직접 통합 → forbidden_actions 위반

**3rd Why: 왜 격리 경로 + 회귀 fixture가 다른 대안보다 나은가?**
C: production 격리는 회장 명시 제약. 회귀 fixture(task-2485 → task-2486)는 실제 chain 사례라 mapping 정확도를 검증 가능. 별도 새 fixture를 만들면 가설 검증이 약함. 격리 + 실제 사례 fixture 조합이 "최소 침습 + 최대 신뢰도" 균형.

★ A-B-C 일관성 확인: closed loop 시스템화 → 검증 가능한 형태가 필요 → mock + 격리 → 실제 사례로 회귀. 논리 일관 ✅

## 참조 자료

- task 본문: `memory/tasks/task-2488.md`
- Phase B 통합 항목: `memory/orchestration/phase_b_integration_items_260507.md` (8종 분류 enum)
- 회귀 사례 입력: `memory/tasks/task-2485.md`, `memory/events/task-2485.code-pass-merge-pending`
- 회귀 사례 기대 출력: `memory/tasks/task-2486.md`
- Phase A v2: `memory/orchestration/orchestrator_subagent_prompt_260506_v2.md`

## Codex 1차 검증 결과 + 대응 (2026-05-08 01:26)

Codex `pass=false` (코드 부재 critical) — 설계만 있는 상태에서 정상. 5개 리스크 대응:

1. **critical (코드 부재)**: 코드 작성 후 재검증 진행 (정상 사이클)
2. **high (forbidden_paths read-only 차단 우려)**: fixture를 PoC 디렉토리에 별도 복사본으로 두고, 실제 `memory/events/task-2485*` 직접 읽기 안 함. fixture 격리로 회피.
3. **high (.done vs real_done_creation 충돌)**: 본 task의 `.done`은 task-2488 lifecycle 완료(허용). `real_done_creation` 금지는 PoC가 *다른 task의* `.done` 가짜 생성 행위 금지. 컨텍스트 분리됨.
4. **medium (timestamp 비결정성)**: `--fixed-timestamp` CLI 옵션 + 환경변수 `CYCLE_ADVANCER_FIXED_TS` 도입. 테스트는 고정 타임스탬프 주입. 출력 파일명은 `draft-{task_id}-{ts}.md`로 결정성 보장.
5. **medium (출력 스키마 미정의)**: YAML frontmatter 스키마를 코드 상단에 명세 + 테스트에서 strict 검증.

→ 엔키에게 위 대응 명시하여 위임. 코드 완료 후 Codex 재검증 (PASS 목표).

## 주의사항

- ★ forbidden_paths 절대 미터치: scripts/, utils/, teams/, .github/, memory/events/task-2472~2487
- ★ production 외부 AI 호출 금지 (mock 또는 dry-run adapter만)
- ★ task-timer.py 변경 금지 (allowed_resources 미포함)
- ★ 실제 .done / .escalate / .fail / dispatch 생성 금지
- 결과물은 `memory/poc/cycle_advancer/draft-{task_id}-{timestamp}.md`로만 출력
- micro-commit: 팀원 작업 완료 즉시 git commit (worktree 미사용 — 시스템 작업, 격리 경로만)
- worktree 정책: project_id 없는 시스템 작업이지만 코드 변경 있음 → workspace 메인 git에 직접 commit