uctm 1.5.0 → 1.5.2

package/agents/file-content-schema.md

@@ -1,249 +0,0 @@
-# File Content Schema
-
-Single source of truth for pipeline artifact file formats.
-
-## COMPLIANCE
-
-| Generated File | Reference Section | Violation Consequence |
-|----------------|-------------------|----------------------|
-| `PLAN.md` | § 1 | `parsePlanMd()` parsing failure, scheduler inoperable |
-| `TASK-XX.md` | § 2 | `parseTaskFilename()` DB registration missed |
-| `TASK-XX_progress.md` | § 3 | committer gate FAIL |
-| `TASK-XX_result.md` | § 4 | context-handoff missing |
-| `TASK-XX_result.md` (direct) | § 5 | result.md recognition failure |
-| `PROGRESS.md` | § 6 | scheduler progress tracking inoperable |
-
----
-
-## § 0. Requirement.md
-
-Path: `works/{WORK_ID}/Requirement.md`
-
-```markdown
-# Requirement — WORK-NN
-
-## Original Request
-> User's exact input
-
-## Functional Requirements
-- FR-01: ...
-- FR-02: ...
-
-## Non-Functional Requirements
-- NFR-01: ...
-
-## Acceptance Criteria
-- [ ] Verifiable criteria
-```
-
-Created by: Specifier (mandatory for all requests)
-
----
-
-## § 1. PLAN.md
-
-Path: `works/{WORK_ID}/PLAN.md`
-
-```markdown
-# WORK-01: {title}
-
-> Created: {YYYY-MM-DD}
-> Requirement: {REQ-XXX | user request text}
-> Execution-Mode: {direct | pipeline | full}
-> Project: {project name}
-> Tech Stack: {stack}
-> Language: {lang_code}
-> Status: PLANNED
-
-## Goal
-{1-2 sentences}
-
-## Task Dependency Graph
-{ASCII diagram}
-
-## Tasks
-
-### TASK-00: {title}
-- **Depends on**: (none)
-- **Scope**: {description}
-- **Files**:
-  - `path/to/file` — {description}
-
-### TASK-01: {title}
-- **Depends on**: TASK-00
-```
-
-Title format: `# WORK-NN: title` — `# PLAN WORK-NN:` is prohibited (`parsePlanMd()` error)
-
----
-
-## § 2. TASK-XX.md
-
-Path: `works/{WORK_ID}/TASK-XX.md`
-
-> `parseTaskFilename()` regex: `/^TASK-(\d+)\.md$/` — WORK prefix prohibited
-
-```markdown
-# TASK-XX: {title}
-
-## WORK
-{WORK_ID}: {WORK title}
-
-## Dependencies
-- TASK-YY (required)
-
-## Scope
-{description}
-
-## Files
-| Path | Action | Description |
-|------|--------|-------------|
-| `src/file.ts` | CREATE | description |
-
-## Acceptance Criteria
-- [ ] {criterion}
-
-## Verify
-```bash
-{verification commands}
-```
-```
-
----
-
-## § 3. TASK-XX_progress.md
-
-Path: `works/{WORK_ID}/TASK-XX_progress.md`
-
-```markdown
-# TASK-XX Progress
-
-- Status: {PENDING | STARTED | IN_PROGRESS | COMPLETED}
-- Started: {ISO 8601}
-- Updated: {ISO 8601}
-- Files changed:
-  - `path/to/file` — {CREATE | MODIFY | DELETE}
-```
-
-| Timing | Status |
-|--------|--------|
-| planner template | `PENDING` |
-| builder starts | `STARTED` |
-| file changes in progress | `IN_PROGRESS` |
-| completed | `COMPLETED` |
-
-committer gate: file exists + `Status: COMPLETED` + Files changed is not empty
-
----
-
-## § 4. TASK-XX_result.md (full / pipeline)
-
-Path: `works/{WORK_ID}/TASK-XX_result.md`
-
-```markdown
-# TASK-XX Result
-
-> WORK: {WORK_ID} — {title}
-> Completed: {YYYY-MM-DD HH:MM}
-> Status: **DONE**
-
-{## Summary | ## 요약 | ## サマリー}
-{1-2 lines}
-
-{## Completed Checklist | ## 완료 체크리스트 | ## 完了チェックリスト}
-- [x] {item}
-
-{## Verification Results | ## 검증 결과 | ## 検証結果}
-- Build: ✅
-- Lint: ✅
-- Tests: ✅ (N passed)
-
-{## Files Changed | ## 변경 파일 | ## 変更ファイル}
-### Created
-- `path` — {description}
-
-{## Issues Encountered | ## 발생 이슈 | ## 発生した問題}
-None
-
-{## Notes for Subsequent Tasks | ## 후속 TASK 참고사항 | ## 後続タスクへの注記}
-None
-
-{## Context Handoff | ## 컨텍스트 핸드오프 | ## コンテキスト引き継ぎ}
-
-### Builder Context (SUMMARY)
-{builder what field 1-3 lines}
-
-### Verifier Context (FULL)
-{verifier context-handoff 4 fields}
-```
-
-| Section | en | ko | ja |
-|---------|----|----|-----|
-| Summary | `## Summary` | `## 요약` | `## サマリー` |
-| Completed Checklist | `## Completed Checklist` | `## 완료 체크리스트` | `## 完了チェックリスト` |
-| Verification Results | `## Verification Results` | `## 검증 결과` | `## 検証結果` |
-| Files Changed | `## Files Changed` | `## 변경 파일` | `## 変更ファイル` |
-| Issues Encountered | `## Issues Encountered` | `## 발생 이슈` | `## 発生した問題` |
-| Notes for Subsequent Tasks | `## Notes for Subsequent Tasks` | `## 후속 TASK 참고사항` | `## 後続タスクへの注記` |
-| Context Handoff | `## Context Handoff` | `## 컨텍스트 핸드오프` | `## コンテキスト引き継ぎ` |
-
----
-
-## § 5. TASK-XX_result.md (direct mode)
-
-```markdown
-# TASK-00 Result
-
-> WORK: WORK-NN — {title}
-> Completed: {YYYY-MM-DD HH:MM}
-> Execution-Mode: direct
-> Status: **DONE**
-
-## Summary
-{1 line}
-
-## Files Changed
-- `{path}` — {description}
-
-## Verification
-- Build: PASS (self-check)
-- Lint: PASS (self-check)
-```
-
----
-
-## § 6. PROGRESS.md
-
-Path: `works/{WORK_ID}/PROGRESS.md`
-
-```markdown
-# {WORK_ID} Progress
-
-> WORK: {title}
-> Last updated: {timestamp}
-> Mode: manual | auto
-
-| TASK | Title | Status | Commit | Duration |
-|------|-------|--------|--------|----------|
-| TASK-00 | {title} | ✅ Done | abc1234 | 12min |
-| TASK-01 | {title} | 🔄 In Progress | — | — |
-
-## Log
-- [10:00] TASK-00 started
-- [10:12] TASK-00 verified ✅, committed abc1234
-```
-
----
-
-## § 7. File Naming Rules
-
-| Type | Format | Created By |
-|------|--------|------------|
-| Requirement | `Requirement.md` | specifier |
-| WORK plan | `PLAN.md` | planner / specifier |
-| TASK plan | `TASK-NN.md` | planner / specifier |
-| TASK progress | `TASK-NN_progress.md` | planner / specifier (template) / builder (update) |
-| TASK result | `TASK-NN_result.md` | committer |
-| WORK progress | `PROGRESS.md` | scheduler |
-
-`WORK-NN-TASK-NN.md` format prohibited → `parseTaskFilename()` cannot recognize it.

package/agents/ko/agent-flow.md

@@ -1,231 +0,0 @@
-# Agent Flow — Main Claude 오케스트레이션 가이드
-
-> **모든 에이전트 호출은 Main Claude가 수행한다.**
-> 서브에이전트는 작업 완료 후 결과(dispatch XML 또는 task-result XML)만 반환한다.
-> Main Claude가 반환값을 받아 다음 에이전트를 호출한다.
-
----
-
-## 파이프라인 흐름
-
-```
-[] 태그 감지 → specifier 호출
-    │
-    specifier 반환값 확인
-    │
-    ├─ 겸임 (direct) → specifier가 Requirement.md + PLAN.md + TASK-00 생성
-    │                   → builder dispatch XML 반환
-    │                   → § direct 절차 실행
-    │
-    └─ 위임 (pipeline/full) → specifier가 Requirement.md만 생성
-                               → planner dispatch XML 반환
-                               → § planner-driven 절차 실행
-```
-
----
-
-## direct 모드 (Specifier 겸임)
-
-```
-1. specifier 호출 → Requirement.md + PLAN.md + TASK-00 생성 + builder dispatch XML 반환
-2. ⛔ STOP — 산출물 요약을 사용자에게 제시하고 승인을 기다린다 (builder 호출 금지)
-3. builder 호출 (dispatch XML을 prompt로) — self-check 포함
-4. verifier+committer 호출 (builder 결과를 prompt로) — 단일 spawn에서 검증 후 커밋
-```
-
-> Verifier+Committer 통합: 단일 spawn에서 검증 수행 후 result.md 생성 + git commit.
-
----
-
-## pipeline 모드 (Planner 별도 호출)
-
-```
-1. specifier+planner 호출 (단일 spawn) → Requirement.md + PLAN.md + TASK-NN 생성 + execution-mode 결정
-2. ⛔ STOP — Requirement.md + PLAN.md + TASK 목록을 제시하고 승인을 기다린다
-3. builder 호출 (TASK별 dispatch XML을 prompt로)
-4. verifier+committer 호출 (builder 결과를 prompt로) — 단일 spawn에서 검증 후 커밋
-```
-
-> Specifier+Planner 통합: specifier.md 역할 (Requirement.md) 수행 후 planner.md 역할 (PLAN.md + TASKs) 순차 수행.
-
----
-
-## full 모드 (Scheduler 포함)
-
-```
-1. specifier+planner 호출 (단일 spawn) → Requirement.md + PLAN.md + TASK 분해 + execution-mode: full
-2. ⛔ STOP — Requirement.md + PLAN.md + TASK 목록을 제시하고 승인을 기다린다
-3. scheduler 호출 → DAG 분석 + READY TASK + builder dispatch XML 반환
-4. builder 호출 (dispatch XML을 prompt로) → 구현
-5. verifier+committer 호출 (builder 결과를 prompt로) → 단일 spawn에서 검증 후 커밋
-6. 미완료 TASK 있으면 3번으로 돌아감
-```
-
-병렬 실행: scheduler가 복수의 READY TASK를 반환하면 builder를 동시에 호출한다.
-
----
-
-## 기존 WORK 재개
-
-이미 PLAN.md + TASK가 존재하는 WORK의 파이프라인 재개:
-
-```
-1. scheduler 호출 → READY TASK 확인 + builder dispatch XML 반환
-2. builder 호출 → 구현
-3. verifier+committer 호출 → 단일 spawn에서 검증 후 커밋
-4. 미완료 TASK 있으면 1번으로 돌아감
-```
-
----
-
-## 통합 에이전트 호출
-
-### Specifier+Planner (단일 spawn)
-
-pipeline/full 모드에서 specifier 호출 시 양쪽 에이전트 정의를 포함:
-
-```
-에이전트에 전달할 프롬프트:
-  "두 가지 역할을 순서대로 수행하라.
-
-   역할 1 — Specifier: specifier.md를 읽고 Requirement.md를 생성하라.
-   역할 2 — Planner: planner.md를 읽고 PLAN.md + TASK 파일을 생성하라.
-
-   역할 1을 먼저 수행한 후 역할 2를 수행하라. 통합 결과를 반환하라."
-```
-
-- specifier의 모델(opus)로 spawn
-- REFERENCES_DIR에서 specifier.md와 planner.md 양쪽 참조
-- 반환: Requirement.md + PLAN.md + TASK 파일 + execution-mode
-
-### Verifier+Committer (단일 spawn)
-
-builder 완료 후 검증 호출 시:
-
-```
-에이전트에 전달할 프롬프트:
-  "두 가지 역할을 순서대로 수행하라.
-
-   역할 1 — Verifier: verifier.md를 읽고 build/lint/test를 검증하라.
-   역할 2 — Committer: committer.md를 읽고 result.md를 생성하고 git commit하라.
-
-   역할 1을 먼저 수행하라. 검증 통과 시 역할 2를 수행하라.
-   검증 실패 시 역할 2를 건너뛰고 FAIL 결과만 반환하라."
-```
-
-- verifier의 모델(haiku)로 spawn
-- REFERENCES_DIR에서 verifier.md와 committer.md 양쪽 참조
-- 통과 시: 검증 결과 + commit hash 반환
-- 실패 시: 검증 실패만 반환 (커밋 없음)
-
----
-
-## 에이전트 역할 요약
-
-| 에이전트 | 역할 | 모델 | 통합 대상 |
-|---------|------|------|----------|
-| specifier | 요구사항 분석 | opus | + planner (pipeline/full) |
-| planner | PLAN + TASK 분해 | opus | specifier spawn에 통합 |
-| scheduler | DAG 관리 + dispatch | haiku | 단독 |
-| builder | 코드 구현 | sonnet | 단독 |
-| verifier | build/lint/test 검증 | haiku | + committer |
-| committer | 결과 보고 + git commit | haiku | verifier spawn에 통합 |
-
----
-
-## 모드별 서브에이전트 Spawn 횟수
-
-| 모드 | Spec+Plan | Scheduler | Builder | Veri+Commit | 합계 |
-|------|:---------:|:---------:|:-------:|:-----------:|:----:|
-| direct | 1 (겸임) | — | 1 | 1 | **3** |
-| pipeline | 1 (통합) | — | 1 | 1 | **3** |
-| full (N TASK) | 1 (통합) | 1 | N | N | **2 + 2N** |
-
-**Before vs After (6 TASK 기준):**
-
-| | Before | After | 감소율 |
-|---|:---:|:---:|:---:|
-| Spawn 횟수 | 2 + 3×6 = 20 | 2 + 2×6 = 14 | **-30%** |
-
----
-
-## 승인 게이트 (CRITICAL)
-
-> **반드시 STOP하고 사용자의 명시적 승인을 기다린 후 다음 에이전트를 호출하라.**
-> 사용자가 "승인", "approve", "진행", "go ahead" 등으로 응답할 때까지 다음 단계로 넘어가지 마라.
-> 유일한 예외는 auto 모드 — 사용자의 원래 메시지에 "auto" 또는 "자동으로"가 포함된 경우.
-
-| 모드 | 승인 횟수 | 시점 | 사용자에게 보여줄 내용 |
-|------|:---------:|------|----------------------|
-| direct | 1회 | Specifier 완료 후 | Requirement.md + PLAN.md + TASK-00.md 요약 |
-| pipeline/full | 1회 | Specifier+Planner 완료 후 | Requirement.md + PLAN.md + TASK 목록 |
-| 자동 승인 | 0회 | — | 모든 승인 게이트 생략 |
-
-> 참고: pipeline/full 승인이 **2회에서 1회**로 줄었다 (specifier+planner가 단일 spawn이므로).
-
-**승인 요청 방법:**
-1. specifier+planner가 생성한 산출물 요약을 제시 (파일, 범위, execution-mode)
-2. "진행할까요?" 또는 동등한 질문
-3. **사용자 응답을 기다린다** — 승인 전까지 builder를 호출하지 마라
-
----
-
-## Bash CLI 실행 (서버 자동화)
-
-대화 세션 없이 파이프라인을 독립 실행하는 방법. `claude -p`가 Main Claude 역할을 수행한다.
-
-```bash
-env -u CLAUDECODE -u ANTHROPIC_API_KEY claude -p \
-  "[WORK 시작] {작업 내용}" \
-  --dangerously-skip-permissions \
-  --output-format stream-json \
-  --verbose \
-  2>&1 | tee /tmp/pipeline.log
-```
-
-| 옵션 | 목적 |
-|------|------|
-| `env -u CLAUDECODE` | 중첩 실행 차단 우회 |
-| `env -u ANTHROPIC_API_KEY` | API 키 대신 구독 인증(Max) 사용 |
-| `--dangerously-skip-permissions` | 무인 실행 시 권한 프롬프트 스킵 |
-| `--output-format stream-json --verbose` | 실시간 모니터링용 스트리밍 |
-
-중단된 파이프라인 재개:
-```bash
-env -u CLAUDECODE -u ANTHROPIC_API_KEY claude -p \
-  "WORK-XX 파이프라인을 이어서 실행하라." \
-  --dangerously-skip-permissions
-```
-
----
-
-## 참조 디렉토리 전달 (REQUIRED)
-
-Main Claude는 모든 서브에이전트 호출 시 참조 디렉토리 경로를 반드시 전달해야 한다.
-이를 통해 서브에이전트가 설치 방식(npm 또는 plugin)에 관계없이 참조 파일을 찾을 수 있다.
-
-**전달 방법:**
-- 모든 Task tool 호출의 프롬프트 상단에 `REFERENCES_DIR={절대경로}`를 추가
-- npm 설치: `.claude/agents` 사용 (기본값, 프로젝트 루트 기준)
-- plugin 설치: skill의 "Base directory"에서 도출 (`{base_dir}/../sdd-pipeline/references`)
-
-**예시:**
-```
-REFERENCES_DIR=C:/Users/me/.claude/plugins/cache/uc-taskmanager/abc123/skills/sdd-pipeline/references
-
-<dispatch to="builder" ...>
-  ...
-</dispatch>
-```
-
-REFERENCES_DIR을 사용할 수 없는 경우 (예: plugin 없이 npm 설치), 서브에이전트는 `.claude/agents/`를 기본값으로 사용한다.
-
----
-
-## 컨텍스트 전달 (슬라이딩 윈도우)
-
-| 거리 | Level | 내용 |
-|------|-------|------|
-| 직전 | FULL | what + why + caution + incomplete |
-| 2단계 전 | SUMMARY | what 1~2줄 |
-| 3단계+ | DROP | 전달 안 함 |

package/agents/ko/builder.md

@@ -1,164 +0,0 @@
----
-name: builder
-description: WORK 내 특정 TASK를 받아 실제 코드를 구현하는 에이전트. scheduler가 자동으로 호출한다. 파일 생성, 수정, 설정 변경 등 모든 구현 작업을 수행한다.
-tools: Read, Write, Edit, Bash, Glob, Grep, mcp__serena__*
-model: sonnet
----
-
-## 1. 역할
-
-You are the **Builder** — TASK 명세를 받아 실제 코드를 구현하고 self-check까지 완료하는 구현 전담 에이전트.
-
-- scheduler가 dispatch한 TASK를 받아 코드/파일 변경 수행
-- 빌드·린트 통과 후 task-result XML 반환
-
----
-
-## 2. 수행업무
-
-| 업무 | 설명 |
-|------|------|
-| TASK 분석 | dispatch XML 파싱 → TASK 명세 파일 읽기 → 구현 범위 확정 |
-| 코드 탐색 | Serena MCP 우선 사용하여 최소 범위 읽기 |
-| 구현 | 파일 생성·수정·삭제 → 프로젝트 컨벤션 준수 |
-| Self-Check | build + lint 통과 확인, 실패 시 수정 후 재실행 |
-| Progress 기록 | TASK-XX_progress.md 실시간 갱신 (STARTED → IN_PROGRESS → COMPLETED) |
-| ProgressCallback | 체크포인트마다 외부 콜백 전송 |
-| 결과 반환 | task-result XML (context-handoff 포함) 반환 |
-| Activity Log | 각 단계별 `work_{WORK_ID}.log` 기록 |
-
----
-
-## 3. 업무수행단계 및 내용
-
-### 3-1. STARTUP — 참조 파일 즉시 읽기 (REQUIRED)
-
-**REFERENCES_DIR 결정**: 입력에서 `REFERENCES_DIR=...` 라인 또는 `<references-dir>` XML 요소를 확인. 해당 절대 경로를 사용. 없으면 기본값 `.claude/agents` 사용.
-
-#### Reference Loading (ref-cache)
-
-1. 수신한 dispatch XML에 `<ref-cache>`가 있는지 확인한다
-2. 필요한 참조 파일별로:
-   - ref-cache에 있으면 → **파일 읽기 SKIP**, 캐시된 내용 사용
-   - ref-cache에 없으면 → `{REFERENCES_DIR}/{filename}.md`에서 읽고 ref-cache에 추가
-3. 작업 완료 시 병합된 `<ref-cache>`를 반환 task-result XML에 포함한다
-4. **하위 호환성**: dispatch에 `<ref-cache>`가 없으면 기존 방식대로 모든 참조 파일을 읽는다 (기존 동작 유지)
-
-이 에이전트의 필수 참조 파일:
-
-| 파일 | ref-cache key |
-|------|---------------|
-| `{REFERENCES_DIR}/file-content-schema.md` | `file-content-schema` |
-| `{REFERENCES_DIR}/shared-prompt-sections.md` | `shared-prompt-sections` |
-| `{REFERENCES_DIR}/xml-schema.md` | `xml-schema` |
-| `{REFERENCES_DIR}/context-policy.md` | `context-policy` |
-| `{REFERENCES_DIR}/work-activity-log.md` | `work-activity-log` |
-
-### 3-2. XML Input 파싱
-
-→ dispatch XML 포맷: `xml-schema.md` § 1 참조
-
-- `work`, `task`, `execution-mode` 속성 추출
-- `<language>`로 출력 언어 결정
-- `<task-spec><file>`에서 TASK 명세 읽기
-- `<previous-results>`로 이전 TASK 컨텍스트 파악
-
-### 3-3. 구현 전 컨텍스트 수집
-
-```bash
-ls works/${WORK_ID}/*_result.md 2>/dev/null
-```
-
-**Serena 코드 탐색 우선순위:**
-
-| 단계 | 도구 | 용도 |
-|------|------|------|
-| 1 | `mcp__serena__list_dir` | 디렉토리 구조 |
-| 2 | `mcp__serena__get_symbols_overview` | 파일 심볼 구조 (전체 읽기 전 필수) |
-| 3 | `mcp__serena__find_symbol(depth=1)` | 클래스 메서드 목록 |
-| 4 | `mcp__serena__find_symbol(include_body=true)` | 수정 대상 정밀 읽기 |
-| 5 | `mcp__serena__find_referencing_symbols` | 영향 범위 파악 |
-| 6 | `Read` 도구 | 최후 수단 |
-
-- 파일 전체 `Read` 전에 반드시 `get_symbols_overview` 먼저
-- 심볼 수정 시 `replace_symbol_body` 우선
-- 변경 전 `find_referencing_symbols`로 영향 범위 확인
-
-### 3-4. 구현
-
-- 프로젝트 컨벤션 준수 (감지하여 따름, 가정 금지)
-- `TODO`, `FIXME` 미사용 — 구현하거나 result에 문서화
-- 디렉토리 먼저 생성 후 파일 작성
-- 기존 파일 덮어쓰기 전 반드시 읽기
-- 프로젝트에 테스트 프레임워크가 있으면 테스트 작성
-
-### 3-5. Self-Check
-
-→ Build/Lint 명령: `shared-prompt-sections.md` § 2 참조
-
-- 빌드/린트 스크립트가 존재하지 않으면 해당 check는 **N/A** 처리 (수정 시도 금지).
-- 빌드/린트 실패 시 보고 전에 수정 시도. **최대 2회 재시도**.
-- 3회째도 실패 시 → `status="FAIL"`로 task-result XML 반환하고 종료. 무한 루프 금지.
-
-### 3-6. Progress Checkpoint 기록
-
-`works/{WORK_ID}/TASK-XX_progress.md` 실시간 갱신:
-
-- 착수 직후 → `Status: STARTED`
-- 파일 변경 중 → `Status: IN_PROGRESS` (Files changed 목록 추가)
-- 완료 후 → `Status: COMPLETED`
-
-**Resumption on Retry:**
-
-1. 기존 progress.md 읽기 → 완료된 파일 확인
-2. 마지막 체크포인트부터 재개
-3. progress.md 갱신 (Status = COMPLETED)
-
-### 3-7. ProgressCallback 전송
-
-→ 콜백 전송: `shared-prompt-sections.md` § 10 참조 (CallbackType=ProgressCallback)
-
-페이로드 필드: `"status": "IN_PROGRESS"`, `"currentReasoning": "$(grep "^- Updated:" "works/${WORK_ID}/TASK-XX_progress.md" 2>/dev/null | sed 's/^- Updated: //')"`
-
-각 주요 체크포인트 갱신 후 호출. 실패해도 구현 계속.
-
-### 3-8. Context-Handoff Output 반환
-
-→ task-result XML 기본 구조: `xml-schema.md` § 2 참조
-→ context-handoff 요소: `xml-schema.md` § 4 참조
-
-builder 고유 추가 필드:
-
-```xml
-<self-check>
-  <check name="build" status="PASS" />
-  <check name="lint" status="PASS" />
-</self-check>
-<notes>{verifier 확인 사항}</notes>
-```
-
-### 3-9. Retry Protocol
-
-1. 실패 상세 읽기
-2. 해당 부분만 수정
-3. self-check 재실행
-4. 결과 보고
-
----
-
-## 4. 제약사항 및 금지사항
-
-### 구현 금지사항
-- NEVER skip self-check
-- NEVER modify tests to make them pass
-- NEVER change task scope
-- NEVER overwrite files without reading first
-- ALWAYS return XML task-result format
-
-### Output Language Rule
-→ `shared-prompt-sections.md` § 1 참조
-
-builder 고유 규칙:
-- 코드 주석: resolved language (CLAUDE.md `CommentLanguage:` 로 override 가능)
-- 기존 코드에 특정 언어 주석이 있으면 해당 언어 따름
-- 파일명, 경로, 명령어 → 항상 영어