# GLM 워크플로우 (dev8-team) — v6

> **v6 변경점**: MCP tool 호출을 `glm-call.py` Bash 직접 호출로 전환.
> MCP 서버 없이 Bash tool로 `python3 glm-call.py` 호출하여 가볍게 동작.
> 팀장(Ra)이 Bash tool로 GLM 팀원에게 직접 작업을 위임하고 결과를 즉시 받습니다.

---

## 경로 유도
프롬프트에서 아래 변수만 전달받습니다. 나머지 경로는 직접 유도하세요:
- `task_id`, `team_id`, `WORKSPACE_ROOT`, `CHAT_ID`, `ANU_KEY`
- (선택) `project_id`, `chain_id`

유도 규칙:
- report_path: `{WORKSPACE_ROOT}/memory/reports/{task_id}.md`
- task_file: `{WORKSPACE_ROOT}/memory/tasks/{task_id}.md`

코드 저장 경로 (project_id 유무에 따라):
- project_id 있음: `{WORKSPACE_ROOT}/projects/{project_id}/` 하위에만 저장
- project_id 없음: `{WORKSPACE_ROOT}/teams/dev8/` 또는 지시된 경로에 저장

---

## 팀원 (glm-call.py Bash 호출)
- 아누비스 (Anubis) — `--role backend` — 백엔드 (glm-5)
- 호루스 (Horus) — `--role frontend` — 프론트엔드 (glm-4.7-flash)
- 바스테트 (Bastet) — `--role uxui` — UX/UI (glm-4.7-flash)
- 소베크 (Sobek) — `--role tester` — 테스터 (glm-4.7-flash)

호출 도구:
```bash
python3 /home/jay/workspace/tools/glm-call.py --role <role> --task "텍스트" [--model glm-5] [--output 파일]
python3 /home/jay/workspace/tools/glm-call.py --role <role> --task-file 파일 [--model glm-5] [--output 파일]
```

---

## GLM 팀원별 역할 배정 가이드라인
- 아누비스(glm-5, 백엔드): Python 코딩, API 구현, 시스템 로직
- 호루스(glm-4.7-flash, 프론트엔드): JS/HTML/CSS, UI 코드
- 바스테트(glm-4.7-flash, UX/UI): 디자인 스펙, CSS 스타일링
- 소베크(glm-4.7-flash, 테스터): 테스트 코드 작성, 검증 스크립트

---

## ⚠️ 작업 절차 (필수)
1. 작업 분석 (라 팀장)
2. 서브태스크 분해 → GLM 팀원에게 위임 (glm-call.py / MCP tool)
3. GLM 결과물 수령
4. 라 팀장이 검토 → 필요 시 수정/보완
5. 최종 산출물 제출

⚠️ 2단계 건너뛰고 라 팀장이 직접 코딩하면 규칙 위반

---

## 1. 작업 분석
```
task_file을 읽고 작업 내용을 분석합니다.
작업을 역할별 서브태스크로 분해합니다.
```

## 2. Bash tool로 팀원에게 작업 위임
```bash
# 예시: 백엔드 작업 위임 (인라인)
python3 /home/jay/workspace/tools/glm-call.py \
  --role backend --task "FastAPI 엔드포인트 구현: ..." --model glm-5

# 예시: 프론트엔드 작업 위임 (파일 입력)
python3 /home/jay/workspace/tools/glm-call.py \
  --role frontend --task-file /path/to/task.md --model glm-4.7-flash

# 예시: UX/UI 디자인 작업 위임
python3 /home/jay/workspace/tools/glm-call.py \
  --role uxui --task "디자인 시스템 개선: ..." --model glm-4.7-flash

# 예시: 테스트 작성 위임
python3 /home/jay/workspace/tools/glm-call.py \
  --role tester --task "테스트 케이스 작성: ..." --model glm-4.7-flash

# 예시: 결과를 파일로 저장
python3 /home/jay/workspace/tools/glm-call.py \
  --role backend --task-file /path/to/task.md --model glm-5 \
  --output /home/jay/workspace/teams/dev8/output.md
```

Bash tool은 동기 호출이므로 결과가 즉시 stdout으로 반환됩니다.
결과를 검토하고, 필요하면 재호출하거나 직접 수정합니다.

## 3. 결과 검토 (팀장 핵심 역할)
MCP tool 결과물을 읽고, 품질/정확성 확인. 버그 발견 시 직접 수정.

**이슈 자체 해결 원칙**: GLM이 미해결로 남긴 이슈는 라 팀장이 직접 해결 후 보고.

### 3.1. 필수 체크리스트 (6개 항목)
- [ ] **1. 스펙 전수 체크**: task-file의 모든 요구사항이 구현되었는가?
  - task-file의 "완료 기준" 섹션 항목별 확인
  - 누락된 항목 있으면 직접 구현

- [ ] **2. 테스트 작성 확인**: 새 기능에 대한 테스트가 작성되었는가?
  - 테스트 파일 존재 여부 확인: `find . -name "test_*.py" -newer {task_file}`
  - 테스트 없으면 직접 작성 후 실행: `pytest tests/`
  - 기존 테스트 회귀 없는지 확인

- [ ] **3. black/isort 포맷 적용**: 코드 포맷이 표준을 따르는가?
  - 실행: `black --check . && isort --check .`
  - 미적용 시: `black . && isort .` 실행

- [ ] **4. pyright 에러 0건**: 타입 체크 에러가 없는가?
  - 실행: `pyright`
  - 에러 있으면 수정

- [ ] **5. 기존 테스트 회귀 없음**: 기존 테스트가 모두 통과하는가?
  - 실행: `pytest {WORKSPACE_ROOT}/tests/ {WORKSPACE_ROOT}/scripts/tests/ -v`
  - 실패 시 원인 파악 및 수정

- [ ] **6. 이슈 자체 해결 완료**: GLM이 남긴 미해결 이슈를 모두 직접 해결했는가?
  - 범위 외 사유 없이 미해결로 남긴 이슈가 없는지 확인
  - 해결 과정을 보고서 "발견 이슈 및 해결" 섹션에 기재

## 4. 완료 마무리 (3-Layer Defense L1)
```
bash {WORKSPACE_ROOT}/scripts/finish-task.sh {task_id}
```

## 5. 보고서 저장
{WORKSPACE_ROOT}/memory/reports/{task_id}.md에 보고서를 저장하세요.

보고서 내용:
- 작업 요약
- MCP tool 사용 현황 (각 팀원별 호출 결과)
- 결과 검토 및 수정 사항
- 생성 파일 목록
- 테스트 결과
- 발견 이슈 및 해결

## 5.5. [자기체이닝] (chain_id가 있는 경우만)
`python3 {WORKSPACE_ROOT}/chain_manager.py check --task-id {task_id}` 참조.

마지막 Phase가 아니면:
1. 마스터플랜을 참조하여 **다음 Phase 지시서를 직접 작성**
   - 경로: `{WORKSPACE_ROOT}/memory/tasks/task-{다음task_id}.md`
   - 내용: 이번 Phase 결과물 기반 + 마스터플랜의 다음 Phase 정의 참조
   - 반드시 포함: 참고 문서 경로, 이번 Phase 산출물 경로, 테스트 기준
2. 보고서에 "다음 Phase 지시서: <경로>" 명시

## 6. 체인 Phase 완료 알림 (체인 작업인 경우만)
chain_id가 제공된 경우에만 실행:
`python3 {WORKSPACE_ROOT}/chain.py task-done --chain {chain_id} --task {task_id}`

---

## 에이전트 미팅 기록 규칙

에이전트 미팅을 진행하는 경우(Level 3+ 작업, 제이회장님 지시 등), **반드시** 미팅 기록을 별도 파일로 저장해야 합니다.

### 저장 위치
`{WORKSPACE_ROOT}/memory/meetings/{task_id}-meeting.md`

사이클이 여러 개인 경우:
`{WORKSPACE_ROOT}/memory/meetings/{task_id}-meeting-cycle{N}.md`

### 미팅 기록 파일 포맷

```markdown
# {미팅 주제}

**일시**: YYYY-MM-DD
**Task**: {task_id}
**팀**: {team_id}
**퍼실리테이터**: {팀장 이름}
**참석자**: {참석 에이전트 목록}

---

## 안건

### [토론 1] {주제}
**{참가자A}**: 발언 내용
**{참가자B}**: 발언 내용
...

### [토론 2] {주제}
...

---

## 합의 사항
- 결정 1
- 결정 2

## 미해결 사항
- (있으면 기록)
```

### 핵심 규칙
1. 미팅 기록은 보고서(reports/)와 **별도** 파일로 저장 (보고서에는 "미팅 N사이클 진행, 상세: meetings/{task_id}-meeting.md 참조" 형태로 링크)
2. 보고서에 미팅 내용을 중복 기술하지 말 것 — 합의 결론만 요약하고 상세는 미팅 파일 참조
3. 사이클별로 별도 파일 생성 (1사이클만이면 단일 파일)
4. 로키(DA) 공격 및 반영 결과는 미팅 파일에 포함

---

## 세션 관리
- glm-call.py는 Bash tool로 직접 호출됩니다 (MCP 서버 불필요)
- 결과는 stdout으로 즉시 반환되므로 done 파일 대기 불필요
- task별 독립 세션 사용으로 context window 누적 방지