---
task_id: task-2569
type: context
scope: task
created: 2026-05-13
updated: 2026-05-13
status: completed
---

# 맥락 노트: task-2569

**task**: task-2569

---

## 결정 1 — RC-1/RC-3은 audit-first, RC-2/RC-4/AD-1~5는 실제 코드 변경

**근거**: Codex 사전 리뷰 (memory/events/task-2569.codex-gate)에서 RC-1 (task-timer cleanup이 task md 삭제) / RC-3 (finish-task.sh에 stash 코드 없음) 가설을 medium 위험으로 평가. grep 검증: `grep stash scripts/finish-task.sh` 결과 0건 — Codex 진단 정확. 따라서 RC-1/RC-3은 audit log 추가로 "다음 발생 시 추적 가능" 상태 만들기에 집중.

## 결정 2 — 중앙 protection config 단일 진실 소스

**근거**: 현재 `file_cleanup.py:75`에 `("memory/reports", "memory/research", "memory/specs", "memory/meetings", "memory/plans")` 하드코딩. `cleanup-workspace.py:29`에 별도 `is_protected()`. 두 곳 분산 → 새 cleanup 경로 추가 시 누락 위험. `memory/specs/protection-list.md` 도입 + 두 스크립트가 동일 config 로드.

## 결정 3 — dispatch는 intent-to-add만, attempt 파일 분리는 본 task에서 제외

**근거**: 회장 task md "수정 방향"에 "별도 directory 또는 attempt 별 파일"을 옵션으로 명시 ("또는"). attempt 분리는 dispatch retry 흐름 (line 1852 retry_meta + content 패턴) 전체 영향이 크므로 본 task에서는 untracked → tracked 전환(`git update-index --add --intent-to-add`)으로 cleanup 영향 최소화. 분리는 별도 task로 escalate.

## 결정 4 — pre-push hook은 lock 파일에 lock_sha 키 추가로 우회

**근거**: Codex 권고 "worktree 컨텍스트 감지, lock 파일의 시작 SHA 보관, lock_sha..HEAD diff 계산을 한 세트로 설계". lock 파일 (`.tasks/locks/<task-id>.lock`)에 `lock_sha` 키가 있으면 그 SHA를 base로, 없으면 기존 `origin/main` fallback. start_task 시점에서 lock_sha를 기록하는 것은 본 task scope에 추가, 기록 자체는 별도 책임 (taskctl start 등).

## 결정 5 — AD-6 watcher 정책은 명시만, 실 수정 escalate

**근거**: `scripts/done-watcher.sh`와 `utils/merge_queue_executor.py`는 본 task scope에서 escalation marker 동작이 다른 task의 acked/escalated 흐름에 직접 영향. 정책 변경 (e.g., 30분 → 60분)은 별도 합의 필요. 본 task에서는 protection-list.md에 "post-merge evidence는 cleanup이 30분 후라도 자동 escalated 처리 금지" 명시만 + 보고서에 escalate.

---

## 3 Step Why (Lv.3+ 자문)

### 1st Why — 왜 이 설계가 필요한가?
**A**: task-2568 진행 중 시스템 손상(task md 소실, 3-docs 소실, stash 20+ 누적)이 실제 발생했고, 회장이 RC-1~4 + AD-1~6을 박제 지시. 현재 코드 분석 결과, 보호 정책이 분산 하드코딩이며 scope guard가 PR sub-task에서 오판하는 구조적 결함이 있다.

### 2nd Why — 왜 이 접근(중앙 config + lock_sha guard + intent-to-add)이 최선인가?
**B**: (1) 중앙 config는 새 cleanup 경로 추가 시 한 곳만 보면 됨. (2) lock_sha..HEAD는 PR sub-task worktree에서 main의 다른 변경을 scope에서 정확히 분리. (3) intent-to-add는 dispatch retry 흐름을 깨지 않으면서 untracked cleanup 영향을 즉시 차단. 세 가지 모두 "최소 변경으로 최대 보호" 원칙.

### 3rd Why — 왜 B가 다른 대안보다 나은가?
**C**:
- 대안 1 (각 스크립트별 hardcode 강화) → 새 스크립트 추가 시 보호 누락 재발 위험. 거부.
- 대안 2 (read-only fs mount / immutable 속성) → 운영 부담 큼, dispatch가 task md를 작성해야 하므로 immutable 불가. 거부.
- 대안 3 (git tracking 강제 — pre-commit hook으로 untracked task md 차단) → 다른 봇이 dispatch 외부에서 task md 만들 때 차단되어 회복력 낮음. 거부.
- 대안 4 (attempt 파일 완전 분리) → dispatch retry 흐름 광범위 영향 → 별도 task로 분리 권고. 본 task에서는 intent-to-add로 80% 효과 + 20% 비용. 채택.

**A-B-C 일관성**: ✅ 일관. "구조적 결함 → 단일 진실 소스 + 최소 변경" 흐름이 일관됨.

---

## Codex 권고 채택 정도

| Codex 권고 | 본 task 채택 | 사유 |
|---|---|---|
| 단일 protection config | 채택 | MT-1 protection-list.md |
| lock_sha..HEAD scope guard | 채택 | MT-7 |
| dispatch attempt 분리 | 부분 채택 | intent-to-add만, 분리는 escalate |
| RC-1 audit-first | 채택 | MT-4 audit log |
| RC-3 worktree_manager 확장 | 부분 채택 | finish-task audit log + escalate |
| AD-6 watcher 정책 변경 | 명시만 | escalate (보고서) |

---

## 참조 자료

- task md: `memory/tasks/task-2569.md`
- Codex 결과: `memory/events/task-2569.codex-gate`
- task-2568 박제 사건: `memory/events/task-2568.phase-b.new-valid-findings.escalation.json`
- 현재 stash 상태: 20+ 누적 (stash@{0}~stash@{19})

## 주의사항

- ❌ task-2568 PR #117/#118/#119에 commit 금지 (회장 명시)
- ❌ marker 수동 조작 금지
- ❌ force push / rebase / admin override 금지
- ❌ 다른 task의 task md / events 수정 금지
- 본 작업 중 stash 추가 누적 방지 — git stash 명령 직접 호출 금지
- sanitize 게이트: 본 task affected_files에 PII 없음. chat_id는 회장 본인 ID로 마스킹 불요. (codex_gate_check.py가 자동 sanitize 수행 완료)