# Agent 미팅: done_watcher 데몬 설계 심층 검증

**날짜**: 2026-03-10
**소집 이유**: 멀티팀 동시 .done 처리, Phase 체이닝 충돌 방지, 팀장 자기체이닝 구조 전환
**참여 페르소나**: 토르(동시성), 불칸(안정성), 야누스(DevOps), 아르고스(엣지케이스), 로키(보안)
**미팅 모드**: hybrid
**토론 깊이**: thorough (Lv.3)
**총 사이클 수**: 2

---

## Cycle 1 — Independent 라운드

### 아누 분석

done_watcher.py는 3팀이 구현한 독립 Python 데몬으로, .done 파일 polling + chain JSON 기반 자동 dispatch를 수행한다.
제이회장님의 우려: 멀티팀 동시 .done 처리 시 기찻길이 꼬이지 않는지.

### 페르소나 의견

**토르 (동시성)**:
- 이중 처리 경로가 최고 위험: done_watcher + notify-completion.py + 아누 수동 스캔 → 3경로가 동일 .done에 대해 경합
- chain.py와 done_watcher.py의 chain 시스템이 이원화 (memory/tasks/ vs memory/chains/, 스키마도 다름)
- update_chain_file에 파일 락 없음
- subprocess 타임아웃 누적 (3팀 동시 .done → 최대 270초 블로킹)
- 권장: 단일 처리 경로로 통합

**불칸 (안정성)**:
- task-timer start → dispatch 실패 시 "유령 타이머" 반쪽 상태
- chain JSON 업데이트 원자성 문제 → 데몬 죽으면 이중 dispatch
- 권장: dispatch 전에 chain 상태 선업데이트 (멱등성 보장)
- 보고서 파싱 대신 구조화된 status.json 제안
- 무한 체이닝 보호 (절대 상한 10 Phase)

**야누스 (DevOps)**:
- .env.keys의 export 키워드 문제 (systemd EnvironmentFile 비호환)
- SIGTERM 핸들러 추가 필요 (graceful shutdown)
- PID 파일과 systemd 충돌 가능성
- logrotate 미설정 → 로그 무한 성장
- systemd unit 보완 필요 (메모리 제한, 보안 옵션)

**아르고스 (엣지 케이스)** — ★ 가장 중요한 발견:
- **TOP 1**: 이중 처리 경로 충돌 (done_watcher + notify-completion + 아누). 세 경로가 서로의 존재를 모름
- **TOP 2**: 데몬 재시작 시 전체 재처리 (self.processed 메모리 only, .done.clear rename 안 함)
- **TOP 3**: chain 디렉토리/스키마 불일치 → **done_watcher의 체이닝이 사실상 작동하지 않음**
- ★ **핵심 발견**: 이미 notify-completion.py + completion-handler-instructions.md + chain_manager.py가 **완전한 체이닝 파이프라인**을 구성하고 있음. done_watcher.py는 이 기존 시스템과 중복.
- 비관습적 대안: "데몬 불필요론" — 기존 인프라 활용 + stalled task 감지 크론이면 충분

**로키 (보안)**:
- **TOP 1 (Critical)**: chain JSON 변조 → task_file path traversal → LLM 프롬프트 인젝션 → 임의 코드 실행
- **TOP 2 (Critical)**: team_prompts.py 18행에 ANU_KEY 평문 하드코딩. 환경변수 47개가 모든 subprocess에 무차별 상속
- **TOP 3 (High)**: 파일 기반 이벤트 시스템 무인증 (디렉토리 775, 누구나 .done 생성 가능)
- "done_watcher 자체가 공격 표면 확대" — 24/7 상시 동작 + 자동 dispatch = 자동 공격 실행

### Cycle 1 합의

**전원 공통 지적 (4가지)**:
1. 이중 처리 경로 → 단일 경로로 통합 필수
2. chain 시스템 이원화 → 통합 필요
3. self.processed 메모리 only → 디스크 persist 또는 .done.clear rename
4. chain JSON/done 파일 무검증 → 스키마 검증 + 보안 강화

### 미해결 항목
- done_watcher.py를 유지/통합/폐기 중 어떤 방향이 최선인가?
- 기존 인프라(notify-completion + chain_manager)를 활용하는 것이 더 나은가?

---

## Cycle 2 — DA 라운드 + 비관습적 대안 평가

### Devil's Advocate: 아르고스 지정

**DA 3대 질문**:

1. **이 설계가 실패하는 가장 현실적인 시나리오는?**
   - done_watcher와 notify-completion이 동시 활성화 → 이중 dispatch → 팀봇 2개 세션이 같은 파일 수정 → 데이터 손상
   - 이건 "가능성"이 아니라 현재 코드에서 **확실히 발생**하는 문제

2. **6개월 후 이 결정을 후회할 이유가 있다면?**
   - done_watcher를 별도 시스템으로 유지하면, chain.py / chain_manager.py / done_watcher.py 3개의 체이닝 시스템을 관리해야 함
   - 기능 추가/버그 수정 시 3곳을 동시에 수정해야 하는 유지보수 지옥

3. **우리가 놓치고 있는 더 단순한 대안은?**
   - **기존 인프라가 이미 답을 가지고 있다.** notify-completion.py가 팀장 완료 시 아누에게 통보하고, completion-handler가 chain_manager.py next를 호출. 이 흐름에 "팀장 자기체이닝" 개념만 추가하면 된다. 새 데몬 불필요.

### 반박 시도

"아누 세션이 죽으면 체이닝이 끊긴다"가 done_watcher 도입 이유였음.
→ 반박: notify-completion.py는 cokacdir --cron으로 **새 아누 세션을 생성**한다. 아누 세션이 죽어도 notify-completion이 새 세션을 깨우므로 체이닝은 끊기지 않는다. 원래 문제는 notify-completion 호출 전에 아누가 죽는 게 아니라, **아누 세션이 이미 죽어있어서 .done을 감지 못하는 것**이었음.
→ 그런데 notify-completion.py는 **팀장이 직접 호출**하므로, 팀장 세션 완료 → notify-completion 호출은 아누 생사와 무관. 따라서 **아누가 죽어있어도 체이닝이 가능**.

### 판정: 반박 수용 — done_watcher 데몬은 불필요할 수 있음

### 비관습적 대안: "데몬 대신 기존 인프라 강화"

**제안**: done_watcher.py를 새로 만들지 않고, 기존 notify-completion.py + completion-handler를 강화
1. 팀장이 Phase 완료 시 → .done 생성 + Phase N+1 지시서 작성 + notify-completion.py 호출
2. notify-completion.py가 cokacdir --cron으로 아누 통보 (또는 텔레그램 직접 알림)
3. completion-handler가 chain_manager.py next 호출 → 다음 Phase dispatch
4. "팀장 자기체이닝"은 팀장 워크플로우에 "다음 Phase 지시서 작성" 추가만 하면 됨

**5개 평가 항목**:
1. 최강 지지 논거: 이미 검증된 인프라 위에 최소 변경으로 목표 달성
2. 최강 반론: completion-handler가 아누 Opus 세션을 깨우므로 토큰 소모 발생
3. 이상적 사용 시나리오: 현재 규모 (팀 3개, Phase 최대 10)에서 최적
4. 노력 수준: 낮음 (기존 코드 수정만)
5. 리스크 등급: 낮음 (기존 시스템이므로 새 버그 유입 최소)

### 토큰 소모 문제 해결
- 중간 Phase 완료 → 아누 Opus 세션 안 깨우고 텔레그램 텍스트만 전송
- 마지막 Phase / 마일스톤 Phase에서만 아누 깨움
- 이걸 completion-handler에서 분기 처리

---

## 최종 합의 사항

1. **done_watcher.py 신규 데몬은 폐기** — 기존 인프라와 중복 + 이중 처리 경로 충돌 위험
2. **기존 인프라 강화**: notify-completion.py + completion-handler + chain_manager.py 경로를 유일한 체이닝 경로로 확정
3. **팀장 자기체이닝**: 팀장 워크플로우(DIRECT-WORKFLOW.md, GLM-WORKFLOW.md)에 "Phase 완료 시 다음 Phase 지시서 작성" 규칙 추가
4. **토큰 절약**: 중간 Phase는 텔레그램 텍스트만, 마지막/마일스톤에서만 아누 세션
5. **보안 즉시 조치**: team_prompts.py 하드코딩 키 제거, 디렉토리 권한 강화

## 미해결 항목

- completion-handler에서 "중간 Phase → 텔레그램만" 분기 로직 구체 설계
- chain_manager.py가 팀장 자기체이닝과 호환되는지 검증
- stalled task 감지 크론 (혹시 notify-completion이 호출 안 된 경우 대비)

## 다음 단계

### 합의 사항 → 작업 매핑
- "done_watcher 폐기" → 3팀 산출물 사용 안 함 (참고만)
- "기존 인프라 강화" → 2팀 또는 1팀에 위임
- "보안 즉시 조치" → team_prompts.py 키 제거 즉시 실행
- "팀장 워크플로우 수정" → DIRECT-WORKFLOW.md, GLM-WORKFLOW.md 업데이트