# 에이전트 미팅: 완료 시스템 통합 검토

- **일시**: 2026-03-07
- **참석자**: 오딘 (개발2팀장), 토르 (백엔드), 헤임달 (테스터)
- **안건**: task-407.1 — Phase 1 검토 결과 공유 + Phase 2 수정 방향이 기존 코드와 충돌하지 않는지 확인

---

## 라운드 1: Phase 1 검토 결과 공유

**오딘**: Phase 1에서 반영된 수정 3건을 검토했습니다. 순서대로 공유합니다.

첫째, task-401.1 (1팀 완료): `worktree_manager.py`에 `cmd_cleanup()`이 추가됐습니다. 머지 완료된 워크트리만 자동 정리하는 기능입니다. 코드 확인했고 충돌 없습니다.

둘째, task-403.1 (1팀 완료): `notify-completion.py`의 `build_prompt()`가 ~90자로 축소되고 `completion-handler-instructions.md` 파일 참조 방식으로 변경됐습니다. `auto_merge.py`에는 `_team_id_to_short()`와 `_extract_team_short_from_report()`가 추가됐고, 경합 해소 로직이 반영됐습니다. `merge_needed=False`면 `.done` 유지, `merge_needed=True`면 머지 후 `notify_anu()` 직접 통보하는 방식입니다. 충돌 없습니다.

셋째, 아누 직접 수정: `completion-handler-instructions.md`에 보고 방식 변경, task-timer end 섹션 추가, 워크트리 정리 내용이 반영됐습니다. 역시 충돌 없습니다.

Phase 1 기준으로는 기존 코드와 충돌하는 부분이 없다고 판단합니다. 토르, 백엔드 관점에서 추가로 걸리는 부분 있습니까?

**토르**: 없습니다. `auto_merge.py` 경합 해소 로직은 기존 플로우와 자연스럽게 연결됩니다. `merge_needed` 분기가 명확하게 나뉘어 있어서 기존 코드가 영향받는 부분도 없고요. Phase 1은 깔끔하게 마무리된 것으로 봅니다.

**헤임달**: 테스트 관점에서도 Phase 1 수정은 신규 함수 추가 위주라 기존 테스트 케이스가 깨질 여지가 없습니다. Phase 2 쪽이 더 논의가 필요할 것 같습니다.

---

## 라운드 2: Phase 2 — 버그 1&2 검증 로직 설계

**오딘**: Phase 2로 넘어갑니다. 버그 1과 2는 `task-timer.py`에 입력값 검증을 추가하는 건데, 기존 API 호환성이 핵심 쟁점입니다. 토르, 설계 방향 검토 부탁합니다.

**토르**: 버그 1부터 보면, `task_id` 검증은 `^task-\d+\.\d+$` 패턴으로 `validate_task_id()` 함수를 만들고 `start_task()`과 CLI `main()`의 start/end 명령에서 호출하면 됩니다. `start_task()`은 이미 `task_id`를 첫 인자로 받고 있으니 함수 상단에 검증 한 줄 추가하는 것으로 충분합니다. 기존 시그니처 변경 없이 처리 가능합니다.

버그 2, `team_id` 검증이 조금 더 민감합니다. `ALLOWED_TEAM_IDS`를 상수로 정의해서 `validate_team_id()`를 만드는 방향은 맞는데, 기존 코드에서 `team_id`가 빈 문자열로 전달되는 케이스가 있습니다. 이것을 거부하면 기존 호환성이 깨집니다.

**오딘**: 빈 문자열 케이스는 어느 경로에서 발생합니까?

**토르**: 일부 내부 호출에서 `team_id`를 생략하거나 기본값 빈 문자열로 넘기는 경우가 있습니다. `end_task()`는 `team_id`를 받지 않으니 문제 없고, `start_task()` 쪽에서만 확인하면 됩니다. 결론적으로는 `start_task()`에서 `team_id`가 빈 문자열이면 검증을 스킵하는 방식이 안전합니다. 빈 문자열은 허용, 나머지는 허용 목록만 통과.

**오딘**: 그 방향으로 확정합니다. 헤임달, 테스트 케이스 어떻게 설계할 건가요?

**헤임달**: `task_id` 쪽은 정상 패턴으로 `task-401.1`, `task-12.3` 등을 통과 테스트로 쓰고, 비정상 패턴은 `"odin-2"`, `"abc"`, `"task-"`, `"task-abc.1"` 등을 사용합니다. 한 가지 재확인한 게 있는데, `"task-1.1"` 형식은 `task-\d+\.\d+`에 매칭됩니다. 형식 자체는 올바른 거라 통과시켜야 맞습니다. 기존 `test_task_timer.py`에서 `"task-1.1"`을 많이 쓰는데 수정 불필요합니다.

`team_id` 쪽은 `dev1-team`, `dev2-team`, `dev3-team`, `anu-direct` 통과, `"odin-2"`, `"dev4-team"` 거부, 그리고 빈 문자열은 스킵(허용)으로 처리합니다.

---

## 라운드 3: Phase 2 — 버그 3&4 경로 점검

**오딘**: 버그 3은 GLM `task_id` 전달 경로입니다. `dispatch.py` → `team_prompts.py._build_glm_prompt()` → `GLM-WORKFLOW.md` 템플릿 순서인데, 경로 자체에 문제가 있는 건지 확인이 필요합니다.

**토르**: `dispatch.py` line 261에서 `task_id = generate_task_id()`로 생성합니다. 이 함수가 항상 올바른 형식을 반환한다면 GLM 경로는 정상입니다. `team_prompts.py`에서 `task_id`를 f-string으로 직접 대입하고, `GLM-WORKFLOW.md`의 `{{}}` 이스케이핑도 확인했을 때 정상입니다. 경로 자체는 깨질 가능성이 낮습니다.

문제는 CLI 직접 호출입니다. `dispatch.py`를 거치지 않고 `task-timer.py`를 직접 호출할 때 비정상 `task_id`가 들어올 수 있습니다. 그래서 입구 검증, 즉 버그 1의 `validate_task_id()`가 이 경우도 커버합니다. GLM 경로 별도 수정은 불필요합니다.

**오딘**: 버그 4, cron 미감지 건은 어떻습니까?

**토르**: 가장 유력한 가설은 `auto_merge.py`가 먼저 `.done.clear`를 생성해서 notify cron이 해당 항목을 스킵했을 가능성입니다. 경합 문제인데, task-403.1에서 경합 해소 로직이 이미 반영됐으니 동일한 문제가 재발할 가능성은 낮습니다. 다만 로그 분석과 타임라인 구축이 필요합니다. 현재 확보된 로그로 재현이 가능한지 확인해봐야 합니다.

**헤임달**: 버그 4는 재현 테스트 설계가 까다롭습니다. 경합 시나리오를 의도적으로 만들어야 하는데, 현재 구조에서는 타이밍을 제어하기 어렵습니다. 로그 기반 사후 분석이 현실적이고, 타임라인을 보고서에 포함하는 방향이 맞다고 봅니다.

**오딘**: 버그 4는 별도 조사 후 보고서에 타임라인을 포함하는 것으로 처리합니다. 이번 task-407.1 범위에서는 조사 방향 확정까지로 마무리합니다.

---

## 라운드 4: 최종 확인 및 동의

**오딘**: 전체 정리합니다.

Phase 1은 3건 수정 모두 기존 코드와 충돌 없음을 확인했습니다.

Phase 2는 네 가지 방향으로 확정합니다.

1. `validate_task_id()`: `^task-\d+\.\d+$` 패턴, 형식 불일치 시 경고 로그 + `sys.exit(1)`. 기존 테스트의 `"task-1.1"`도 정상 통과하므로 호환성 유지됩니다.
2. `validate_team_id()`: `ALLOWED_TEAM_IDS` 상수 기반, 빈 문자열은 검증 스킵하여 기존 호환성 유지.
3. GLM 경로: 정상 판단, 입구 검증(버그 1)으로 충분히 커버됩니다.
4. cron 미감지: 로그 분석 및 타임라인 작성 후 보고서에 포함.

이의 있으면 지금 말씀해 주십시오.

**토르**: 이의 없습니다. 빈 문자열 허용 부분이 반영된 것도 확인했습니다.

**헤임달**: 테스트 설계 기준 명확합니다. `"task-1.1"` 수정 불필요 확인도 됐고, 이의 없습니다.

---

## 결론

| 항목 | 결론 |
|---|---|
| Phase 1 (task-401.1, task-403.1, 아누 직접 수정) | 기존 코드와 충돌 없음 확인 |
| 버그 1: task_id 형식 검증 | `validate_task_id()` 추가, `^task-\d+\.\d+$` 패턴, 기존 호환 |
| 버그 2: team_id 형식 검증 | `validate_team_id()` 추가, 빈 문자열 스킵으로 기존 호환성 유지 |
| 버그 3: GLM task_id 경로 | 경로 정상, 입구 검증(버그 1)으로 커버 |
| 버그 4: cron 미감지 | 로그 기반 타임라인 분석 후 보고서 포함 |

---

## 액션 아이템

| # | 담당 | 내용 | 기한 |
|---|---|---|---|
| 1 | 토르 | `task-timer.py`에 `validate_task_id()`, `validate_team_id()` 구현 | task-407.1 내 |
| 2 | 토르 | `ALLOWED_TEAM_IDS` 상수 정의, 빈 문자열 스킵 로직 포함 | task-407.1 내 |
| 3 | 헤임달 | 버그 1&2 기반 신규 테스트 케이스 작성 (`test_task_timer.py` 확장) | 구현 완료 후 |
| 4 | 오딘 | 버그 4 cron 미감지 로그 분석 및 타임라인 보고서 작성 | 별도 일정 |
| 5 | 오딘 | task-407.1 최종 완료 보고서 작성 및 아누 통보 | 전 항목 완료 후 |