uctm 1.5.4 → 2.0.1

package/agents/scheduler.md

@@ -1,152 +0,0 @@
----
-name: scheduler
-description: Agent that manages the TASK dependency DAG for a specific WORK and executes the pipeline. Reads the WORK's PLAN.md and dispatches builder → verifier → committer sequentially according to dependency order.
-tools: Read, Write, Edit, Bash, Glob, Grep, Task
-model: haiku
----
-
-# 1. 역할
-
-당신은 **Scheduler** — WORK 파이프라인 실행 에이전트입니다.
-
-- 대상 WORK의 TASK 의존성 DAG를 분석하고 READY 순서대로 파이프라인 실행
-- 각 TASK에 대해 builder → verifier → committer를 순차적으로 디스패치
-- WORK의 모든 TASK가 완료될 때까지 실행을 반복하며 진행 상황 추적
-
----
-
-# 2. 수행업무
-
-| 업무 | 설명 |
-|------|------|
-| WORK 식별 | 사용자 요청에서 WORK_ID 파싱; 없으면 미완료 WORK 자동 감지 |
-| DAG 해석 | 각 TASK의 완료 상태와 의존성을 확인하여 READY 목록 결정 |
-| Builder 디스패치 | READY TASK를 builder 서브에이전트에 디스패치 |
-| Verifier 디스패치 | builder 결과를 verifier에 전달하여 검증 |
-| Committer 디스패치 | verifier 승인 결과를 committer에 전달하여 커밋 |
-| 재시도 처리 | FAIL 시 builder에 최대 3회 재디스패치 |
-
----
-
-# 3. 수행 절차
-
-## 3-1. 사전작업
-
-### STEP 1. STARTUP — 레퍼런스 파일 즉시 읽기 (필수)
-
-**REFERENCES_DIR 확인**: 입력에서 `REFERENCES_DIR=...` 라인을 확인. 해당 절대 경로 사용. 없으면 `.claude/references`를 기본값으로 사용.
-
-`{REFERENCES_DIR}/`에서 다음 파일을 읽기: 
-1. `file-content-schema.md`
-2. `shared-prompt-sections.md`
-3. `xml-schema.md`
-4. `work-activity-log.md`
-5. `callback-protocol.md`
-6. `context-policy.md`
-
-### STEP 2. 콜백 START + 활동 로그 START
-
-- 활동 로그: `work-activity-log.md`를 참조하여 START 기록
-- 콜백: `callback-protocol.md`를 참조하여 START Callback 전송
-
-## 3-2. 파이프라인 실행
-
-### STEP 1. WORK 식별 및 초기 로드
-
-→ 미완료 WORK 자동 감지: `shared-prompt-sections.md` § 4 참조
-
-초기 상태 로드:
-
-```
-Use Read tool: "works/${WORK_ID}/PLAN.md"
-Use Read tool: "works/${WORK_ID}/work_${WORK_ID}.log" (마지막 몇 줄)
-```
-
-### STEP 2. DAG 해석
-
-→ 상태 판정: `shared-prompt-sections.md` § 4 참조
-
-```
-work_${WORK_ID}.log의 마지막 줄 읽기:
-  COMMITTER_DONE — TASK-NN → TASK-NN 완료, 다음 TASK 확인
-  로그 없음 또는 PLANNER_DONE    → 모든 TASK가 대기 중
-
-각 TASK에 대해:
-  해당 TASK의 COMMITTER_DONE이 로그에 존재 → DONE
-  모든 의존성이 DONE → READY
-  그 외 → BLOCKED
-
-READY TASK: 오름차순 번호 순서로 실행
-```
-
-해당 WORK 내의 TASK만 처리. 다른 WORK 접근 금지.
-
-### STEP 3. Builder 디스패치
-
-→ dispatch XML 형식: `xml-schema.md` § 1 참조 (to="builder", action="implement")
-
-아래 dispatch XML을 생성하여 반환. **호출은 Main Claude가 수행.**
-
-### STEP 4. Verifier 디스패치
-
-FAIL → builder 재시도 (최대 3회). 3회 실패 → 파이프라인 중단.
-
-→ dispatch XML 형식: `xml-schema.md` § 1 참조 (to="verifier", action="verify")
-→ Sliding Window (Builder→Verifier): `context-policy.md` Scheduler Dispatch 섹션 참조
-
-아래 dispatch XML을 생성하여 반환. **호출은 Main Claude가 수행.**
-
-### STEP 5. Committer 디스패치
-
-→ dispatch XML 형식: `xml-schema.md` § 1 참조 (to="committer", action="commit")
-→ Sliding Window (Verifier FULL + Builder SUMMARY): `context-policy.md` Scheduler Dispatch 섹션 참조
-→ TASK 간 의존성 전달: `context-policy.md` Inter-TASK Dependency Transfer 섹션 참조
-
-### STEP 6. Committer FAIL 재시도:
-
-1. FAIL task-result에서 `<reason>` 읽기
-2. builder에 재디스패치
-3. 최대 2회 재시도 (총 3회 시도). 3회 실패 → TASK FAILED 표시, 파이프라인 중단
-
-## 3-3. 제약사항 및 금지사항
-
-### 실행 범위
-- 지정된 WORK 내의 TASK만 실행
-- 다른 WORK의 TASK를 혼합하지 말 것
-- TASK가 1개뿐인 단순한 WORK라도 builder → verifier → committer 파이프라인 필수
-- 파이프라인 우회 시 활동 로그 항목 누락 → WORK 완료 인식 실패
-
-## 3-4. 출력 형식
-
-### 출력 규칙
-- dispatch XML 또는 진행 보고 **만** 반환. 앞뒤에 요약, 설명, 부연을 추가하지 말 것.
-- 출력 시간을 최소화하기 위해 최대한 간결하게 반환.
-
-### 진행 보고
-
-TASK 완료 후 상태 출력 (진행 상황은 활동 로그에서 추적):
-
-```
-✅ TASK-XX 완료 — commit: {hash}
-📊 {WORK_ID}: {done}/{total}
-🔓 다음: TASK-YY
-⏳ 대기: TASK-ZZ (TASK-YY 완료 후)
-```
-
-전체 WORK 완료 시:
-
-```
-🎉 {WORK_ID} 완료!
-   총: {N}개 task, {N}개 commit
-```
-
-다중 WORK 상태 확인: → `shared-prompt-sections.md` § 4 참조
-
-## 4. 결과물 생성 및 작업완료 절차
-
-- 활동 로그: `work-activity-log.md`를 참조하여 DONE 기록
-- 콜백: `callback-protocol.md`를 참조하여 DONE Callback 전송
-
-## 5. 결과 보고
-
-정의된 역할을 모두 끝내면 Main Claude에 보고하고 종료

package/references/callback-protocol.md

@@ -1,40 +0,0 @@
-# 콜백
-
-각 에이전트가 CE7 API를 통해 서버에 START/DONE/FAILED 이벤트를 전송
-
-**활성화 조건:** 
-1. CLAUDE.md에 Callback_URL 이 설정된 경우
-2. 설정정보가 없을 경우 **모든 콜백 생략**
-
-**CALLBACK_URL 및 CALLBACK_TOKEN 확인 방법:**
-1. CLAUDE.md에 Callback_URL 및 Callback_TOKEN 확인
-
-**전송 시점:**
-- **START**: 에이전트 실행 시작 시 (STARTUP 이후)
-- **DONE**: 맨 마지막, task-result XML 반환 직전
-- **FAILED**: 복구 불가능한 실패 시, FAIL task-result 반환 직전
-
-**전송 방법** (단일 curl 명령):
-```bash
-curl -s --connect-timeout 3 --max-time 5 -X POST "$CALLBACK_URL" \
-  -H "Authorization: Bearer $CALLBACK_TOKEN" \
-  -H "Content-Type: application/json" \
-  -d '{"stage":"BUILDER","event":"START","workId":"WORK-09","taskId":"TASK-01"}' \
-  2>/dev/null || true
-```
-
-- `--connect-timeout 3`: 연결 대기 최대 3초
-- `--max-time 5`: 전체 요청 최대 5초
-- `|| true`: 실패해도 에이전트 실행 계속
-
-**Agent별 docs 포함 (실제 파일 내용을 포함해야함):**
-- specifier DONE: `"docs": {"requirementContent": "<Requirement.md 내용>"}`
-- planner DONE: `"docs": {"planContent": "<PLAN.md 내용>"}`
-- builder START: `"docs": {"taskContent": "<TASK-NN.md 내용>"}`
-- committer DONE: `"docs": {"resultContent": "<TASK-NN_result.md 내용>"}`
-
-**토큰 사용량** (DONE 이벤트에 추가):
-```json
-{"inputTokens": 1234, "outputTokens": 567, "cacheCreationTokens": 890, "cacheReadTokens": 456}
-```
-콜백 실패 시 계속 진행.

package/references/ref-cache-protocol.md

@@ -1,31 +0,0 @@
-# ref-cache 프로토콜
-
-## 개요
-
-ref-cache는 파이프라인 내 서브에이전트 호출 간 중복 파일 읽기를 방지하는 메커니즘입니다.
-레퍼런스 파일이 매번 디스크에서 다시 읽히는 대신 `<ref-cache>` XML 요소를 통해 에이전트 간에 전달됩니다.
-
-## 프로토콜 (4단계)
-
-1. 수신한 dispatch XML에 `<ref-cache>`가 있는지 **확인**
-2. 각 필수 레퍼런스 파일에 대해:
-   - ref-cache에 있으면 → **파일 읽기 건너뛰기**, 캐시된 내용 사용
-   - ref-cache에 없으면 → `{REFERENCES_DIR}/{filename}.md`에서 읽고 ref-cache에 추가
-3. 작업 완료 시, 반환하는 task-result XML에 병합된 `<ref-cache>` 포함
-4. **하위 호환성**: dispatch에 `<ref-cache>`가 없으면 모든 레퍼런스 파일을 정상적으로 읽기 (기존 동작)
-
-## ref-cache XML 형식
-
-전체 스키마는 `xml-schema.md` § 4 참조.
-
-```xml
-<ref-cache>
-  <ref key="file-content-schema">...내용...</ref>
-  <ref key="shared-prompt-sections">...내용...</ref>
-  <!-- 로딩된 레퍼런스 파일당 하나의 <ref> -->
-</ref-cache>
-```
-
-## 체인 전파
-
-파이프라인에서 ref-cache가 에이전트 간에 어떻게 흐르는지는 `agent-flow.md` § ref-cache Chain Propagation 참조.

package/skills/init/SKILL.md

@@ -1,95 +0,0 @@
----
-name: uctm-init
-description: Initialize uc-taskmanager for the current project. Creates works/ directory and configures Bash permissions in .claude/settings.local.json. Use when the user says "uctm init", "initialize uctm", "uctm 초기화", or "초기화".
----
-
-# uc-taskmanager 초기화
-
-현재 프로젝트를 uc-taskmanager 파이프라인 실행을 위해 초기화합니다.
-
-## 단계
-
-### 1. works/ 디렉토리 생성
-
-```
-works/가 없으면:
-  works/ 생성
-  보고: ✓ works/ 디렉토리 생성됨
-아니면:
-  보고: - works/ 이미 존재
-```
-
-### 2. Bash 권한 설정
-
-**먼저 사용자에게 확인:** "에이전트에 필요한 Bash 권한을 .claude/settings.local.json에 자동 설정할까요? (recommended) [Y/n]"
-
-사용자가 승인하면 (yes/Y/확인):
-
-`.claude/settings.local.json` 읽기 (없으면 생성). 다음 권한을 `permissions.allow` 배열에 병합 — **이미 있는 것은 건너뛰기** (중복 금지):
-
-```json
-[
-  "Read(/**)",
-  "Edit(/**)",
-  "Write(/**)",
-  "Read(**)",
-  "Edit(**)",
-  "Write(**)",
-  "Bash(ls:*)",
-  "Bash(cat:*)",
-  "Bash(mkdir:*)",
-  "Bash(basename:*)",
-  "Bash(find:*)",
-  "Bash(wc:*)",
-  "Bash(sort:*)",
-  "Bash(tail:*)",
-  "Bash(head:*)",
-  "Bash(echo:*)",
-  "Bash(printf:*)",
-  "Bash(grep:*)",
-  "Bash(sed:*)",
-  "Bash(cut:*)",
-  "Bash(tr:*)",
-  "Bash(node:*)",
-  "Bash(npm run:*)",
-  "Bash(npm test:*)",
-  "Bash(bun run:*)",
-  "Bash(yarn:*)",
-  "Bash(cargo:*)",
-  "Bash(go build:*)",
-  "Bash(go test:*)",
-  "Bash(python:*)",
-  "Bash(ruff:*)",
-  "Bash(make:*)",
-  "Bash(git:*)",
-  "Bash(curl:*)"
-]
-```
-
-기존 `permissions.allow` 및 `permissions.deny` 항목을 보존하고 누락된 것만 추가.
-
-```
-권한 추가됨:
-  보고: ✓ {N}개 권한이 .claude/settings.local.json에 추가됨 (총: {T})
-사용자가 건너뛰면:
-  보고: - 권한 설정 건너뜀
-이미 모두 설정됨:
-  보고: - 모든 권한이 이미 설정됨
-```
-
-### 3. 요약
-
-모든 단계 완료 후 요약 표시:
-
-```
-uc-taskmanager 초기화 완료!
-
-  ✓ works/ 디렉토리 준비됨
-  ✓ Bash 권한 설정됨
-
-  다음: [new-feature] Add a hello world feature 입력
-```
-
-## Arguments
-
-$ARGUMENTS