@angar2/taskery 0.6.0 → 0.7.0

package/template/shared/skills/project-init/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: project-init
-description: taskery 도입 직후 1회성 — 진입 문서(PROJECT/AGENT-GUIDE/…) + 제품 관통 기획 문서(그룹 A 작성 / 그룹 B 골격) 생성
+description: taskery 도입 직후 1회성 — AGENTS.md 리포 값 + 진입 문서(PROJECT/GLOSSARY/…) + 리포 로컬 룰 초안 + 제품 관통 기획 문서(그룹 A 작성 / 그룹 B 골격) 생성
 ---
 
 # /project-init
 
 ## 개요
 
-taskery 도입 직후 **1회성**으로 호출. 사용자 또는 동료가 새 리포에 npx로 taskery 세팅 직후 처음 부르는 스킬. `.project/` 영역의 사람용/메인용 진입 문서와 **제품 관통 기획 문서**(루트 평평 배치)를 만든다.
+taskery 도입 직후 **1회성**으로 호출. 사용자 또는 동료가 새 리포에 npx로 taskery 세팅 직후 처음 부르는 스킬. 진입 문서 `AGENTS.md`의 리포 값(메타·명령)을 채우고, `.project/` 영역의 사람용/메인용 문서와 **제품 관통 기획 문서**(루트 평평 배치), 그리고 이 리포의 로컬 룰 초안을 만든다.
 
 제품 관통 문서 2그룹 (`.project/` 루트):
 - **그룹 A — 정적(내용까지 작성)**: SERVICE-POLICY.md / TECH-STACK.md / ARCHITECTURE.md. project-init이 인터뷰로 *작성*. (이후 plan-init은 부수적 add/mod만.)
@@ -53,6 +53,25 @@ taskery 도입 직후 **1회성**으로 호출. 사용자 또는 동료가 새
    - Q4: 단일 리포 / 멀티 리포?
    - Q5: (멀티 리포 시) 연결 리포 목록 + 각 역할?
 
+### Step 2.5 — `AGENTS.md` 리포 값 채우기
+
+진입 문서 `AGENTS.md`(프로젝트 루트)에는 **이 리포의 값이 들어갈 빈 칸 4개**가 있다. 이 칸이 placeholder(`<예: ...>`)로 남으면 `/task-dev` self-check 게이트, `/task-close` 최종 게이트, `/task-test` 격리 세션이 **실행할 명령을 찾지 못한다.** 본 단계에서 반드시 채운다.
+
+> `CLAUDE.md`는 `@AGENTS.md` 임포트 한 줄이라 채울 것이 없다. 값은 `AGENTS.md`에만 쓴다.
+
+| 절 | 채울 내용 | 출처 |
+|----|----------|------|
+| `## 프로젝트 메타` | 이름 / 타입 / 한 줄 소개 | Step 2 수집 결과 그대로 |
+| `## 검증 명령` | 린트 · 타입체크 · 빌드 — *코드 상태* 검증 | 기존 코드면 `package.json` scripts·`Makefile` 등에서 탐지 후 confirm / 빈 프로젝트면 스택 확정 후 기입 |
+| `## 테스트 명령` | 단위 · 통합 · E2E — *테스트 실행* | 위와 동일 |
+| `## 검수 실행 명령` | 기준 포트 · 실행 명령 | 앱을 띄워 사람이 확인하는 프로젝트만. 아니면 **절 전체를 삭제** |
+
+규칙:
+- 백틱 안 명령은 *그대로 실행 가능한* 형태여야 한다. 추상 서술 금지.
+- 해당 없는 항목은 **행 자체를 삭제**한다. 빈 백틱(``)을 남기지 않는다.
+- 아직 정할 수 없으면 placeholder를 지우고 *"미정 — 첫 `/task-plan`에서 확정"*이라고 명시한다. 방치 금지.
+- 최종안을 사용자에게 보여주고 confirm 받은 후 기록한다.
+
 ### Step 3 — `.project/PROJECT.md` 작성
 
 사람용 진입 문서. 개발자가 *"이 프로젝트 뭐 하는 거야?"* 알 수 있게.
@@ -138,45 +157,63 @@ taskery 도입 직후 **1회성**으로 호출. 사용자 또는 동료가 새
 <!-- 기능 그룹 / 도메인 섹션이 여기 누적된다. 초기엔 비어 있음. -->
 ```
 
-### Step 4 — `.project/AGENT-GUIDE.md` 작성
+### Step 4 — 리포 로컬 룰 초안 작성 (`TEST_RULE.local.md` · `DEV_RULE.local.md`)
+
+이 둘은 코어 짝이 없는 로컬 전용 문서이나 **모든 리포에 반드시 존재해야 한다** (`TASKERY_RULE` §8). 없으면 이후 세션이 이 프로젝트의 검증·구현 방식을 모른 채 일반론으로 진행한다.
+
+1. **리포 분석** — 기존 코드가 있으면 테스트 러너·빌드 도구·실행 스크립트를 탐지한다(`package.json` scripts, `Makefile`, `*.xcodeproj`, `pytest.ini` 등).
+2. **초안 제시 → 사용자 confirm → 생성.** 탐지 결과를 근거로 채운 초안을 보여주고 승인받은 후 `.project/rules/`에 작성한다.
+3. 빈 프로젝트라 정할 것이 없으면 **섹션 헤더만 있는 골격을 생성**한다 (각 절에 *"첫 `/task-plan`에서 확인 후 기록"* 표시). **파일 자체는 어떤 경우에도 생성한다.**
+
+`TEST_RULE.local.md` 골격:
+
+```markdown
+# TEST_RULE.local.md — 이 리포의 검증 규칙
+
+> 이 프로젝트에서 각 테스트 방식을 *실제로 어떻게 실행하나* + *무엇을 얼마나 검증하나*의 단일 소스.
+> 구성과 의무는 `.project/rules/TASKERY_RULE.md` §8 참조.
+> `*.local.md`는 taskery update가 건드리지 않는다 — 이 리포가 소유한다.
+
+## 방식별 실행 경로
+
+> 그대로 실행 가능한 명령·경로로 적는다. 모르면 비워 두지 말고 `/task-plan`이 사용자에게 확인한 즉시 기록한다.
 
-메인 세션 진입 가이드. 새 메인 세션이 부르는 *"읽고 시작"* 문서.
+- **데이터 검증** (DB / 파일 / 상태 조회): <아직 미정>
+- **API 호출** (엔드포인트 / 외부 인터페이스): <아직 미정>
+- **UI 동작 · E2E** (클릭 / 입력 / 흐름 자동화): <아직 미정>
+- **시각 실행** (앱 기동 + 화면 캡처): <아직 미정>
+- **기타**: <아직 미정>
+
+## 테스트 실행 환경 (격리 실행 경로)
+
+> 실제 앱을 띄워 UI를 자동 조작하는 스위트를 **사용자의 화면·마우스·키보드를 뺏지 않고** 돌리는 경로.
+> 여기가 비어 있으면 자동 게이트·격리 세션은 그 스위트를 실행하지 않고 사용자 승인을 받는다.
+> 적을 수 있는 것: 창 숨김·헤드리스 플래그 / 가상 디스플레이·컨테이너 / VM / CI 러너 위임 / 점유 스위트를 제외하는 한정 실행 옵션.
+
+<아직 미정>
+
+## 범위·방식 정책
+
+> 무엇을 얼마나 검증하나 — 수정 루프에서의 실행 범위, 테스트 신설 상한 등.
+
+<아직 미정>
+```
+
+`DEV_RULE.local.md` 골격:
 
 ```markdown
-# AGENT-GUIDE.md
-
-## 활성 plan 버전   <!-- 값 = NNN_slug 폴더명(버전 아님). 헤딩 텍스트는 lib.js/스킬이 의존하므로 변경 X -->
-<예: 001_mvp — `.project/plans/001_mvp/` 참조>
-
-## 메인이 매 세션 시작 시 읽을 것
-1. `CLAUDE.md` — 프로젝트 메타 + 검증 명령 + 룰 참조
-2. `.project/PROJECT.md` — 프로젝트 개요 + 초기 빌드 로드맵
-3. `.project/` 루트 제품 관통 문서 — SERVICE-POLICY / TECH-STACK / ARCHITECTURE / DATA-MODEL / API-SPEC / FEATURES / UX-UI (해당 시. 기능 분류 단일 진실)
-4. `.project/plans/<활성 plan>/PLAN.md` — 활성 plan(기능 그룹) 인덱스 (이 그룹이 건드린 루트 문서 요약 + task 체크리스트)
-5. `.project/GLOSSARY.md` — 도메인 용어집 (영문/한글 표기 일관성 단일 진실 소스)
-6. `.project/tasks/<활성 plan>/BACKLOG.md` — 현재 plan 진행 중 누적된 후속 task 후보 (사용자 발화 *"이건 다음 task로"* / task-close 직후 메인 감지로 추가)
-7. `.project/AGENT-GUIDE.md` — 본 파일 (그대로)
-8. `.project/TEST-GUIDE.md` — 검증 방법 문서 (각 테스트 방식의 이 프로젝트 실제 실행 경로). 매 세션 통독 아니라 *`/task-plan`·`/task-test` 시 참조* — 발견성 위해 등재
-
-## 작업 흐름
-- task 시작: `/task-init` 또는 `/task-plan`
-- task 진행: `/task-dev` → `/task-test` → `/task-close`
-- 불편 등록: `/log-friction` (사용자 호출 / 발화 캐치 / task-close 자체 감지)
-
-## 폴더 구조
-- `.project/rules/` — 코어 룰 (TASK_DOC_RULE / GIT_RULE / CHANGELOG_RULE / MOCKUP_RULE)
-- `.project/*.md` (루트) — 제품 관통 문서 (SERVICE-POLICY / TECH-STACK / ARCHITECTURE / DATA-MODEL / API-SPEC / FEATURES / UX-UI)
-- `.project/plans/<NNN_slug>/` — plan(기능 그룹) 로컬: PLAN.md / ROADMAP.md
-- `.project/tasks/<NNN_slug>/` — task 문서
-- `.project/flows/` — 도메인 흐름
-- `.project/shared/` — 멀티리포 메시지
-- `.project/changelog/` — 월별 변경 이력
-- `.project/FRICTION_LOG.md` — 불편 데이터
-- `.project/TEST-GUIDE.md` — 검증 방법 문서 (각 테스트 방식의 이 프로젝트 실제 실행 경로. 제품 관통 문서 아님)
-
-## 멀티리포
-<단일 리포면 "단일 리포. LINKED-REPOS.md 빈 템플릿."
-멀티 리포면 "LINKED-REPOS.md 참조">
+# DEV_RULE.local.md — 이 리포의 구현 규칙
+
+> 이 프로젝트 고유의 구현 정책. 구성과 의무는 `.project/rules/TASKERY_RULE.md` §8 참조.
+> `*.local.md`는 taskery update가 건드리지 않는다 — 이 리포가 소유한다.
+
+## 구현 정책
+
+<아직 미정 — 코드 배치 관행 · 금지 패턴 · 의존성 추가 기준 등>
+
+## 빌드·실행 전제
+
+<아직 미정 — 테스트 전 빌드 필요 여부 등>
 ```
 
 ### Step 4.5 — `.project/GLOSSARY.md` 작성 (도메인 용어집)
@@ -243,8 +280,7 @@ stash FRICTION_LOG #3 반영 — 프로젝트 도메인 용어를 *영문/한글
 - `.project/plans/` (`.gitkeep` — `/plan-init`이 `NNN_slug/` 하위 작성)
 - `.project/tasks/` (`.gitkeep` — `/task-init`이 `NNN_slug/TASK-<NNN>_<slug>.md` 작성)
 - `.project/shared/{sent,received}/completed/` (`.gitkeep`)
-- `.project/FRICTION_LOG.md` (빈 템플릿)
-- `.project/rules/{TASK_DOC_RULE,GIT_RULE,CHANGELOG_RULE,MOCKUP_RULE}.md` (코어 룰)
+- `.project/rules/{TASKERY_RULE,TASK_DOC_RULE,GIT_RULE,CHANGELOG_RULE,MOCKUP_RULE}.md` (코어 룰 5종)
 
 → `/project-init`은 폴더 생성 X. 누락 시(`init` 안 거치고 수동 셋업한 경우)에만 `mkdir -p` 실행.
 
@@ -254,7 +290,7 @@ mkdir -p .project/{changelog,flows,plans,tasks}
 mkdir -p .project/shared/sent/completed .project/shared/received/completed
 ```
 
-`.project/FRICTION_LOG.md`도 `init`이 카피한 빈 템플릿 그대로 사용. **이미 있으면 덮어쓰기 X** — 사용자 데이터 보호.
+`.project/FRICTION_LOG.md`는 배포되지 않는다 — `/log-friction`이 첫 기록 때 생성한다. **이미 있으면 덮어쓰기 X** — 사용자 데이터 보호.
 
 ### Step 7.5 — git 초기화 + 첫 ref 분기 (빈 폴더 케이스)
 
@@ -284,11 +320,11 @@ git branch -a                                        # main(또는 master) + dev
 ### Step 8 — 결과 보고
 
 작성된 파일 목록 + 다음 단계 안내:
-- *"PROJECT.md(초기 빌드 로드맵 포함) / AGENT-GUIDE.md / LINKED-REPOS.md / GLOSSARY.md / .env + 제품 관통 문서(그룹 A 작성: SERVICE-POLICY·TECH-STACK·ARCHITECTURE / 그룹 B 골격: DATA-MODEL·API-SPEC·FEATURES·UX-UI, 타입 해당분) 생성. (FRICTION_LOG.md / TEST-GUIDE.md(검증 방법 문서, 빈 골격) / 빈 골격 폴더는 npx init이 이미 카피한 것 그대로 — project-init이 생성 X). **빈 폴더 케이스라 git init + dev 분기까지 완료** (이미 git 리포면 건너뜀). 다음은 `/plan-init <기능그룹>`으로 첫 plan(MVP면 여러 기능 그룹을 묶은 큰 plan) 작성."*
+- *"AGENTS.md 리포 값 4칸(메타·검증·테스트·검수 명령) 기입 + PROJECT.md(초기 빌드 로드맵 포함) / LINKED-REPOS.md / GLOSSARY.md / .env + 제품 관통 문서(그룹 A 작성: SERVICE-POLICY·TECH-STACK·ARCHITECTURE / 그룹 B 골격: DATA-MODEL·API-SPEC·FEATURES·UX-UI, 타입 해당분) + 리포 로컬 룰 초안(TEST_RULE.local.md · DEV_RULE.local.md) 생성. (빈 골격 폴더·코어 룰은 npx init이 이미 카피한 것 그대로 — project-init이 생성 X). **빈 폴더 케이스라 git init + dev 분기까지 완료** (이미 git 리포면 건너뜀). 다음은 `/plan-init <기능그룹>`으로 첫 plan(MVP면 여러 기능 그룹을 묶은 큰 plan) 작성."*
 
 **결과 commit 흐름** (GIT_RULE 정합):
 - 현재 브랜치(= 부모, 기본 dev)가 dev/main이면 직접 commit *금지* (git-guard.sh 차단). 두 가지 default 흐름:
-  1. **첫 task에 묶기 (권장)**: `/plan-init` 끝나고 첫 `/task-init` (보통 TASK-001 부트스트랩 chore)으로 만든 작업 브랜치에서 init 산출물(PROJECT/AGENT-GUIDE/LINKED-REPOS/.env)도 함께 commit. task-close 단계의 "태스크 문서 커밋"에 자연스럽게 묶임.
+  1. **임시 docs 브랜치 (권장)**: `git checkout -b docs/{개발자}_init-bootstrap` 후 commit → 현재 브랜치(부모)에 `--no-ff` 머지. **첫 task 브랜치에 묶는 방식은 쓰지 않는다** — init 산출물은 메인 워크트리에 남고 task는 별도 워크트리라 같은 브랜치에 담을 경로가 없다.
   2. **임시 docs 브랜치**: `git checkout -b docs/{개발자}_init-bootstrap` 후 commit → 현재 브랜치(부모)에 `--no-ff` 머지. 첫 task 생성 *전*에 init 결과를 깔끔히 기록하고 싶을 때.
 
 ## 도구 가이드

package/template/shared/skills/task-close/SKILL.md

@@ -80,10 +80,11 @@ LOCK_FILE="$HOME/.taskery/${PROJECT_ID}.merge.lock"
      - `$MAIN_WT/.project/rules/GIT_RULE.md` (프로젝트별 — 우선)
      - `~/.claude/rules/GIT_RULE.md` (글로벌)
      둘 다 없으면 종료 + *"GIT_RULE 누락"* 보고.
+   - **로컬 오버라이드** — `$MAIN_WT/.project/rules/GIT_RULE.local.md`가 있으면 함께 Read하고, 겹치는 항목은 **로컬 우선**, **겹치지 않는 로컬 조항도 그대로 준수**한다 (`TASKERY_RULE` §7 — 구속력은 코어와 동등). 단 로컬 룰이 뒤집을 수 없는 것: 부모 브랜치 직접 커밋 금지 · `--no-ff` 강제 · 머지 락 직렬화 · destructive 명령 사용자 승인.
 
 ### Step 2 — 최종 검증 명령 재실행 (게이트)
 
-`$MAIN_WT/CLAUDE.md`의 `## 검증 명령` (빌드/린트/타입체크) 만 재실행. **하나라도 FAIL이면 close 차단**.
+`$MAIN_WT/AGENTS.md`의 `## 검증 명령` (빌드/린트/타입체크) 만 재실행. **하나라도 FAIL이면 close 차단**.
 
 | 명령 | 결과 |
 |------|------|
@@ -101,18 +102,42 @@ FAIL 시:
   - *"고쳐"* → status `developing`으로 되돌림 + `/task-dev` 안내 + close 중단.
   - *"OK 마무리"* → 결함 명시한 채 진행 (Result 섹션에 *"검증 명령 X FAIL 알려진 결함 — 사유: ..."* 추가).
 
+### Step 2.5 — 문서 갱신 훑기 (게이트 통과 후 · `close` 호출 전)
+
+본 task로 갱신돼야 할 문서를 *목록으로* 훑는다. 이 단계가 없어 PLAN.md 체크리스트·수정이력·CHANGELOG가 연속으로 누락된 사례가 있다 (recordion FRICTION 2026-08-05, 5태스크 연속·26문서 무이력·6태스크 무CHANGELOG). 개별 항목이 아니라 *목록 훑기*가 본 단계의 요지다 — 하나씩 규칙을 더하는 방식으로는 습관 밖의 문서가 계속 빠진다.
+
+**편집 위치** (`.gitignore` 케이스 — Step 1에서 판정한 값 사용):
+- 등록 케이스 → `$MAIN_WT/.project/...` (gitignore라 git 추적 무관, 즉시 반영)
+- 미등록 케이스 → `$WT_PATH/.project/...` (Step 3 `close`의 문서 커밋이 자동 수거 → 부모 머지로 반영)
+
+**점검 목록** (해당 없으면 "해당 없음"으로 명시하고 넘어간다 — 침묵 통과 금지):
+
+| # | 대상 | 갱신 내용 |
+|---|------|----------|
+| 1 | `.project/plans/<활성 plan>/PLAN.md` | 본 task에 해당하는 체크리스트 항목 `[x]` + TASK 번호 표기 |
+| 2 | `.project/plans/<활성 plan>/ROADMAP.md` | Stage 상태·완료 노트 (출처가 `ST-N`이거나 Stage 진척이 생긴 경우) |
+| 3 | `.project/changelog/<YYYY-MM>.md` | 본 task 항목 추가. **파일이 없으면 생성한다** (형식은 `.project/rules/CHANGELOG_RULE.md` — `.local.md` 있으면 그쪽 우선) |
+| 4 | 본 task가 수정한 **제품 관통 문서·plan 문서**의 `## 수정 이력` | 해당 문서마다 행 추가, 표가 없으면 신설. 대상 목록의 출처 = `spec-diffs/` + Dev Plan Phase 0 기록 (등록 케이스는 `.project/`가 git 밖이라 `git diff`로 찾을 수 없다). **task 문서는 제외** — close가 잠그는 별개 계열이다 |
+| 5 | 후속 task 후보 (있을 때만) | **손편집 금지** — `backlog_add` 도구(또는 `npx @angar2/taskery backlog-add ...`)로 등재한다. BL 채번·서식·`withMetaLock` 직렬화를 코드가 보장하며, 파일 위치는 등록/미등록과 무관하게 **항상 메인 워크트리**(`.project/tasks/<활성 plan>/BACKLOG.md`)다 — 위 "편집 위치" 분기가 적용되지 않는 유일한 항목 |
+| 6 | `spec-diffs/` ↔ 실제 문서 변경 | 기재한 diff가 실제 반영됐는지 대조 |
+
+- 갱신 결과는 Step 8 보고의 `- 문서 갱신:` 줄에 적는다.
+- 본 단계에서 git 명령을 실행하지 않는다 (커밋은 Step 3 `close`와 Step 5 머지가 담당).
+
 ### Step 3 — 결정적 준비 (`task_close` 도구)
 
 `task_close` 도구 (또는 `npx @angar2/taskery close TASK-NNN`) 한 번으로 다음을 코드가 수행:
-- **Phase 기능 커밋** — uncommitted 코드 변경분(`.project/` 외)을 task.md `### Phase N`의 `- 파일:` 필드에 매핑해 Phase 순서대로 자동 커밋 (GIT_RULE 메시지 형식, 태그 자동: feature→`feat:` / bug→`fix:` / improve→`improve:` / refactor→`refactor:` / docs·chore→`docs:`).
+- **Phase 기능 커밋** — uncommitted 코드 변경분(`.project/` 외)을 task.md `### Phase N`의 `- 파일:` 필드에 매핑해 Phase 순서대로 자동 커밋 (GIT_RULE 메시지 형식, 태그 자동: feature→`feat:` / bug→`fix:` / improve→`improve:` / refactor→`refactor:` / docs·chore→`docs:`). 매핑 폴백은 GIT_RULE §"Phase↔파일 매핑 규칙" — 한 파일이 여러 Phase에 걸치면 *가장 이른 Phase*, Dev Plan에 없는 *빌드 산출물*(`*.pbxproj`·잠금파일)은 *마지막 Phase*에 자동 편입(커밋 메시지에 사유 표기).
 - **status → `closed`** — task 문서 헤더 (`.gitignore` 케이스 자동 판정 — 등록=메인WT / 미등록=워크트리).
 - **flows/문서 커밋** (미등록 케이스) — 워크트리 안 `.project/flows/` + task 문서.
 - **추적 마커 빈커밋** — 부모 브랜치보다 앞선 커밋이 0개(코드 0·`.project` gitignore인 docs/분석 task)면 채번 보존용 1개.
 
-반환 JSON `{ prepped, branch, parent, wtPath, registered, commits, aheadOfParent }`. **`parent`(= task 헤더에 기록된 부모 브랜치, 예 `dev` / `dev_feat_x`)가 이후 Step 4·5의 rebase·머지 대상이다** — 아래 명령의 `$PARENT`로 사용. (task-init이 fork 시점 현재 브랜치를 헤더에 기록해뒀다.)
+반환 JSON `{ prepped, branch, parent, wtPath, registered, commits, aheadOfParent, multiPhase?, autoAssigned? }`. **`parent`(= task 헤더에 기록된 부모 브랜치, 예 `dev` / `dev_feat_x`)가 이후 Step 4·5의 rebase·머지 대상이다** — 아래 명령의 `$PARENT`로 사용. (task-init이 fork 시점 현재 브랜치를 헤더에 기록해뒀다.)
+
+- **`multiPhase` / `autoAssigned`가 있으면 Step 8 보고에 그대로 옮긴다** — 코드가 자동 편입한 파일과 그 근거(어느 Phase로 갔는지)를 사용자가 볼 수 있어야 한다. 재배치 목적의 수동 커밋 재작업은 하지 않는다(GIT_RULE: 중간 커밋 독립 빌드 비보장).
 
 **콜백 (반환 `blocked` 필드 / npx는 특수 exit — 메인이 LLM 판단 후 처리):**
-- **`blocked:'mapping'`** (npx exit 2 — `{files, phases, reason}`): Dev Plan `- 파일:` 필드가 변경 파일을 못 덮음(미매핑) 또는 한 파일이 여러 Phase에 걸침. → 메인이 Dev Plan + `git -C "$WT_PATH" diff --name-only` 정독 후 **코드 변경분을 Phase별로 수동 커밋**(GIT_RULE 형식, 위 태그) → `task_close` 도구(또는 `npx ... close`) **재호출**. 코드가 이미 커밋돼 있으므로 close가 status=closed + 문서 커밋 + 마커를 자동 완료한다.
+- **`blocked:'mapping'`** (npx exit 2 — `{files, phases, reason}`): Dev Plan `- 파일:` 필드가 변경 파일을 못 덮음(**미매핑 — 빌드 산출물이 아닌 일반 파일 한정**. 다중 Phase 파일·산출물은 위 폴백으로 자동 처리돼 여기 오지 않는다). → 메인이 Dev Plan + `git -C "$WT_PATH" diff --name-only` 정독 후 **코드 변경분을 Phase별로 수동 커밋**(GIT_RULE 형식, 위 태그) → `task_close` 도구(또는 `npx ... close`) **재호출**. 코드가 이미 커밋돼 있으므로 close가 status=closed + 문서 커밋 + 마커를 자동 완료한다.
 - **`blocked:'status'`** (npx exit 3 — `{current}`): status가 `tested`가 아님. Step 1~2 통과했다면 발생 X. 발생 시 사용자 보고 + 중단.
 
 > **close 후 task 문서 수정 금지** — close가 status=`closed`로 잠갔다(`closed-immutable.sh` hook 차단). 이후 Step 4 충돌 해결 내역은 *task 문서가 아니라 rebase/머지 커밋 메시지*에 기록한다.
@@ -206,9 +231,16 @@ git -C "$MAIN_WT" merge --no-ff "$BRANCH"
 - 사용자 부정 반응 발화 누적
 - **충돌 해결에서 *판단 불가 (4-c)* 1회 이상** — 멀티세션 자료 한계 신호
 
-분기:
-- 감지 신호 있음 → *"이번 task에서 X 부분이 마찰이었어 보여 — `/log-friction`으로 등록할까?"* OK 시 자동 발동.
-- 없음 → prompt X.
+분기 — **감지했으면 성격부터 가른다** (`TASKERY_RULE` §9):
+
+| 성격 | 판단 기준 | 제안 |
+|------|----------|------|
+| **taskery 자체의 결함** | 모든 리포에서 똑같이 발생할 문제 (스킬 지시 모순 / CLI 반환값이 문서와 다름 / 절차 자체의 빈틈) | *"이번 task에서 X 부분이 마찰이었어 보여 — `/log-friction`으로 등록할까?"* OK 시 자동 발동 |
+| **이 리포의 특성** | 이 프로젝트에서만 해당하는 방식·관행 (테스트 범위·실행 방법·빌드 전제·명명 관행) | *"이걸 이 리포 규칙(`<문서>.local.md`)으로 등록할까?"* **OK 받은 후에만** 해당 `.local.md`를 생성·추가한다. 문안은 사용자와 확정한 내용으로 적는다 |
+
+- 둘 다 해당하면 **둘 다 제안**한다.
+- 신호 없음 → prompt X.
+- 로컬 룰 등록은 **반드시 질문 후 승인**을 거친다 — 임의 생성 금지.
 
 ### Step 7 — 워크트리 / 브랜치 정리 (비가역 — git-guard 면제 조항)
 
@@ -247,6 +279,8 @@ git -C "$MAIN_WT" worktree remove "$WT_PATH"
 - 작업 브랜치: <BRANCH> (삭제 / 보존)
 - 워크트리: <WT_PATH> (제거 / 보존)
 - 커밋: Phase <N>개 + 태스크 문서 + (CHANGELOG)
+- 문서 갱신: <Step 2.5 점검 6항 중 실제 갱신한 것 — 예: PLAN.md 체크리스트 [x] / changelog 2026-08 신규 / ARCHITECTURE 수정이력 1행. 없으면 "해당 없음">
+- 자동 편입: <multiPhase / autoAssigned 있을 때만 — 예: `src/ipc.ts` Phase 2·5 → Phase 2 / `project.pbxproj` → Phase 3(빌드 산출물)>
 - 부모 브랜치 병합: <PARENT> ← --no-ff 완료 ($MERGE_COMMIT)
 - 충돌 해결: <건수, 자료 한계 보고 있으면 포함>
 - 상태: tested → closed
@@ -255,7 +289,7 @@ git -C "$MAIN_WT" worktree remove "$WT_PATH"
 
 ## 도구 가이드
 
-- **Read**: GIT_RULE / task 파일 / CLAUDE.md 검증 명령 정독 / `task_close` 반환 JSON
+- **Read**: GIT_RULE / task 파일 / AGENTS.md 검증 명령 정독 / `task_close` 반환 JSON
 - **Bash / 도구**: `task_close` 도구(또는 `npx @angar2/taskery close TASK-NNN`) 결정적 준비 + git 명령 (`rebase`, `merge`, `worktree`, `branch`) + 검증 명령 재실행. **유일하게 git 사용 허가된 스킬**
 - **Edit / Write**: (매핑 콜백 시) 수동 Phase 커밋용 staging / CHANGELOG 내용 (close가 커밋). **close 후 task 문서는 closed라 수정 X**
 - **bin/lib.js**: `withMergeLock` (머지 락 — Step 5)

package/template/shared/skills/task-dev/SKILL.md

@@ -9,11 +9,11 @@ description: task 구현 — Dev Plan Phase 순서대로 코드 작성 + self-ch
 
 `planned` 상태 task의 Dev Plan을 Phase 순서대로 구현. 각 Phase 완료 시 체크박스 갱신 + Result 섹션에 진행 기록. 모든 Phase 완료 + self-check (린트/타입/빌드/단위테스트) PASS 시 status를 `developed`로 갱신.
 
-self-check 명령은 프로젝트 루트 `CLAUDE.md`의 *검증 명령* 섹션 참조 — 단일 진실 소스.
+self-check 명령은 진입 문서 `AGENTS.md`의 *검증 명령* 섹션 참조 — 단일 진실 소스.
 
 ## 멀티세션 메타 위치 (0.1.2+)
 
-본 스킬은 워크트리에서 호출되는 게 default (멀티세션 — 각 워크트리 = 독립 세션). 다만 호출 위치 자유 — 메인 cwd / 서브 세션 호출 등 다른 운영 모델에서도 cwd 무관 동작. 메타(`.project/`, `CLAUDE.md`) 접근 시 **메인 워크트리 절대 경로** 우선.
+본 스킬은 워크트리에서 호출되는 게 default (멀티세션 — 각 워크트리 = 독립 세션). 다만 호출 위치 자유 — 메인 cwd / 서브 세션 호출 등 다른 운영 모델에서도 cwd 무관 동작. 메타(`.project/`, `AGENTS.md`) 접근 시 **메인 워크트리 절대 경로** 우선.
 
 ```sh
 MAIN_WT=$(dirname "$(git rev-parse --path-format=absolute --git-common-dir)")
@@ -21,10 +21,10 @@ MAIN_WT=$(dirname "$(git rev-parse --path-format=absolute --git-common-dir)")
 
 `.gitignore` 케이스 분기:
 
-| 케이스 | task 문서 / Result 갱신 위치 | CLAUDE.md (검증 명령) |
+| 케이스 | task 문서 / Result 갱신 위치 | AGENTS.md (검증 명령) |
 |--------|---------------------------|----------------------|
-| 등록 (퍼블릭 리포 default) | `$MAIN_WT/.project/tasks/<NNN_slug>/...` (`bin/lib.js` `withMetaLock`) | `$MAIN_WT/CLAUDE.md` |
-| 미등록 | `$WT_PATH/.project/tasks/<NNN_slug>/...` (워크트리 안, 머지 시 dev 반영) | `$MAIN_WT/CLAUDE.md` (CLAUDE.md는 단일 소스) |
+| 등록 (`.project/`가 `.gitignore`에 있음) | `$MAIN_WT/.project/tasks/<NNN_slug>/...` (`bin/lib.js` `withMetaLock`) | `$MAIN_WT/AGENTS.md` |
+| 미등록 (**기본 설치값** — `fork`/`status` 반환의 `registered:false`) | `$WT_PATH/.project/tasks/<NNN_slug>/...` (워크트리 안, 머지 시 dev 반영) | `$MAIN_WT/AGENTS.md` (AGENTS.md는 단일 소스) |
 
 self-check 명령은 워크트리(`$WT_PATH`)에서 실행 — 코드 변경이 워크트리 안에 있으므로 검증 대상도 거기.
 
@@ -47,18 +47,21 @@ self-check 명령은 워크트리(`$WT_PATH`)에서 실행 — 코드 변경이
 
 ### Step 1 — task 파일 + 검증 명령 확인
 
-1. `.project/AGENT-GUIDE.md` Read → 활성 plan 버전 확인.
+1. `status` 도구(또는 `npx @angar2/taskery status`)로 활성 plan 확인.
 2. task 파일 Read:
    - 인자 있음 → 해당 파일.
-   - 인자 없음 → `ls .project/tasks/<NNN_slug>/` 결과 중 status=`planned` 또는 `developing`인 가장 최근 파일. 발견 시 *"TASK-<NNN> 진행할까요?"* confirm. 없으면 *"진행할 task 없음. `/task-plan` 먼저 호출."* + 종료.
+   - 인자 없음 → `status` 도구(또는 `npx @angar2/taskery status`)의 *진행중 태스크* 목록에서 후보를 찾는다 — task 문서는 미등록 케이스에서 **각 task의 워크트리 안에만** 있으므로, 메인 워크트리에서 `ls .project/tasks/<NNN_slug>/`로 찾으면 아무것도 안 나와 *"task가 없다"*고 잘못 끝난다. 각 후보의 문서 경로는 `status`가 알려주는 워크트리 경로 아래 `.project/tasks/<NNN_slug>/`다. 그중 status=`planned` 또는 `developing`인 가장 최근 task. 발견 시 *"TASK-<NNN> 진행할까요?"* confirm. 진행중 목록 자체가 비어 있을 때만 *"진행할 task 없음. `/task-plan` 먼저 호출."* + 종료.
 3. 상태 검증:
    - `planned` → 신규 진행 (Step 2 status 전환).
    - `developing` → 이어가기 (Step 2 skip — 이미 developing).
    - 그 외 → 종료 + 안내.
-4. 프로젝트 루트 `CLAUDE.md` Read → 두 섹션 명령 추출:
+4. 진입 문서 `AGENTS.md` Read → 두 섹션 명령 추출:
    - **`## 검증 명령`** (코드 상태 — 빌드/린트/타입체크): self-check 게이트의 단일 진실 소스 (Step 6).
    - **`## 테스트 명령`** (테스트 실행 — 단위/통합/E2E): 구현 후 테스트 실행의 단일 진실 소스 (Step 6.5).
    - stash FRICTION_LOG #25 반영 — 두 섹션 분리. self-check 게이트는 *코드 상태*만, 테스트는 *별도 단계*.
+   - **미기입 가드**: 값이 `<예:` 로 시작하는 placeholder이거나 비어 있으면 **그 명령을 실행하지 않는다.** 이 리포는 진입 문서가 아직 안 채워진 상태이므로 *"`AGENTS.md`의 `## 검증 명령`이 비어 있다. `/project-init`으로 채운 뒤 다시 부르거나, 지금 값을 알려달라"*고 사용자에게 알리고 **중단**한다. placeholder를 명령으로 착각해 실행하면 매번 실패하며 원인을 엉뚱한 데서 찾게 된다.
+5. **프로젝트 로컬 룰 확인** — `$MAIN_WT/.project/rules/DEV_RULE.local.md`(구현 정책)와 `$MAIN_WT/.project/rules/TEST_RULE.local.md`(테스트 범위·방식 정책)를 각각 Read한다. 둘 다 모든 리포에 있어야 하는 필수 문서이며(`TASKERY_RULE` §8), **없으면 사용자에게 알리고** 본 스킬의 기본값으로 진행한다 (`npx update` 미터치 영역이라 프로젝트가 자유롭게 소유한다). 본 스킬 조항과 겹치는 항목은 **로컬 룰을 우선 적용**한다 — 프로젝트마다 구현·테스트 실행 방식이 다르므로 본 스킬 조항은 *안전한 기본값*이다. **Step 6.5의 테스트 실행 범위·신설 상한은 `TEST_RULE.local.md`가 있으면 그 규정을 따른다** (본 스킬이 테스트를 실제로 실행하는 주체이므로, 그 파일을 읽지 않으면 프로젝트 고유 규칙이 무력해진다).
+   - **로컬 룰이 뒤집을 수 없는 것** (충돌 시 코어 우선): 멀티세션 불변식(머지 락 · 메인 워크트리 테스트 금지 · git 명령은 `/task-close`만) · destructive 명령 사용자 승인 · 상태 전이 유효성.
 
 ### Step 2 — status 전환 (planned → developing)
 
@@ -98,7 +101,7 @@ Dev Plan에 Phase 0(제품 관통 문서 변경)이 있으면:
 
 ### Step 6 — self-check 게이트 (`## 검증 명령` — 코드 상태)
 
-`CLAUDE.md` `## 검증 명령` 섹션의 명령을 *전부* 실행. 모두 PASS여야 다음 단계 (Step 6.5 테스트 실행) 진입 가능. 테스트 명령은 본 게이트에서 실행 X.
+`AGENTS.md` `## 검증 명령` 섹션의 명령을 *전부* 실행. 모두 PASS여야 다음 단계 (Step 6.5 테스트 실행) 진입 가능. 테스트 명령은 본 게이트에서 실행 X.
 
 | 명령 | PASS 기준 |
 |------|---------|
@@ -118,7 +121,7 @@ Dev Plan에 Phase 0(제품 관통 문서 변경)이 있으면:
 
 stash FRICTION_LOG #14+19 / #25 반영 — 유닛 테스트는 본 단계에서 단일 시점 실행 (task-close / hook 영역 중복 제거).
 
-`CLAUDE.md` `## 테스트 명령` 섹션의 명령을 *전부* 실행. 모두 PASS여야 `developed`로 전이 가능.
+`AGENTS.md` `## 테스트 명령` 섹션의 명령을 *전부* 실행. 모두 PASS여야 `developed`로 전이 가능. **본 게이트는 *구현 완료 시점 1회*다** — 아래 "수정 루프 국면"에 해당하는 동안에는 매 사이클 전부 실행하지 않는다. 또한 수정 루프 국면을 거친 뒤 곧바로 `/task-test`로 이어가는 경우에는 국면 ⑥에 따라 본 게이트의 전체 실행을 생략하고 *격리 세션의 실행*으로 갈음한다 (그때의 `developed` 전이 근거 = 린트·타입체크 PASS + 변경이 닿는 테스트 PASS이며, 전체 스위트는 격리 세션이 책임진다).
 
 | 명령 | PASS 기준 |
 |------|---------|
@@ -132,6 +135,34 @@ stash FRICTION_LOG #14+19 / #25 반영 — 유닛 테스트는 본 단계에서
 - 신규 *테스트 식별자* (suite / class / function / describe 등) 가 테스트 runner 결과 로그에 *실제 등장*했는지 grep 직접 확인 (1 hit 이상).
 - 예: `grep -E "Suite \"<NewSuite>\"" test-output.log` → hit 1 이상.
 - 등장 안 하면 *Suite 미실행* (빌드 시스템 등록 누락 등) → FAIL 처리.
+- **신규 테스트 실효성 확인 (음성대조)** — 본 task에서 테스트를 신설했으면, 가능한 범위에서 *구현을 일시적으로 되돌린 상태에서 그 테스트가 실제로 FAIL하는지* 확인한 뒤 통과를 근거로 삼는다 (Edit로 되돌렸다가 확인 후 즉시 원복 — git 명령 사용 금지). 통과만 보면 테스트가 무력해도 알 수 없다 (stash FRICTION 2026-07-28 — 흐름 테스트 2건이 이 확인으로 실효성을 입증했다). 되돌리기가 위험하거나 부작용이 큰 영역이면 생략하고 그 사유를 Result에 적는다.
+
+**화면·입력 점유 스위트 자동 실행 금지 (stash FRICTION 2026-07-25 / recordion FRICTION 2026-08-05 반영)**:
+
+실제 앱을 띄워 UI를 자동 조작하는 스위트(XCUITest·headed 브라우저 E2E 등)는 사용자의 화면·마우스·키보드를 점유해 **작업을 중단시킨다.** `## 테스트 명령`이 단일 진실 소스라는 원칙은 유지하되, 실행 방식은 아래를 따른다.
+
+| 상황 | 실행 방식 |
+|------|----------|
+| `TEST_RULE.local.md` *테스트 실행 환경* 절에 **격리 실행 경로**(창 숨김·헤드리스 플래그 / 컨테이너·가상 디스플레이 / VM / CI 러너) 선언됨 | 그 경로로 **자동 실행 OK** |
+| 격리 경로 없음 + 비점유 부분만 한정 실행 가능 (번들·프로젝트·태그 지정 등) | **비점유 부분만 자동 실행**, 점유 스위트는 제외 |
+| 격리 경로 없음 + 한정 수단도 없음 | **자동 실행 금지** — 사용자에게 *무엇을 왜 돌려야 하고 얼마나 걸리며 그동안 화면·입력을 못 쓴다*를 예고하고 승인을 받은 뒤에만 실행 |
+
+- 헤드리스 모드가 존재하면 항상 그쪽을 쓴다.
+- 본 task가 UI를 건드리지 않는데(순수 로직·CLI 등) 테스트 명령이 UI 스위트를 포함하면, 그 스위트는 실행 대상이 아니다.
+- 격리 실행 경로를 새로 확인했으면 `TEST_RULE.local.md` *테스트 실행 환경* 절에 기록해 다음 task가 재사용하게 한다.
+
+**수정 루프 국면 — 재실행 범위 비례 (recordion FRICTION 2026-08-08 반영)**:
+
+적용 범위 = ① `developed` 이후 사용자 검수 피드백으로 고치는 동안, ② `/task-test` FAIL 후 사용자 *"고쳐"*로 재진입해 고치는 동안. 이 두 국면은 *구현 완료 게이트*와 별개이며, 매 사이클 전체를 돌리지 않는다 (한 태스크에서 전체 E2E를 6회 이상 재실행해 사용자 시간을 수십 분 태운 사례가 있다).
+
+1. **매 사이클 실행** — 린트·타입체크(수 초) + *변경한 파일이 닿는 테스트* + 그 테스트가 쓰는 공유 헬퍼를 함께 쓰는 테스트. 대개 1~2개·수십 초다.
+2. **전체 게이트(Step 6 + Step 6.5)는 국면이 끝날 때 1회** — 국면 도중에는 돌리지 않는다. 풀빌드를 포함한 Step 6도 매 사이클 대상이 아니다. (국면이 끝나는 시점에 *실제로 돌릴지*는 아래 ⑥이 정한다 — 바로 `/task-test`로 이어가면 격리 세션의 실행으로 갈음한다.)
+3. **테스트 러너가 빌드를 포함하지 않으면 빌드를 선행**한다 — 옛 산출물로 돌면 이미 고친 결함이 남아 있는 것처럼 보여 없는 버그를 쫓게 된다 (recordion에서 이 때문에 30분을 소모했다). 어느 명령이 빌드를 포함하는지는 `TEST_RULE.local.md`에 기록해 재사용한다.
+4. **무관한 테스트가 깨질 때만 범위를 넓힌다** — 예상 밖 실패가 나오면 그때 상위 범위로 확대한다.
+5. **회귀 누락 위험은 2 + `/task-test` 격리 세션의 이중 게이트가 막는다.** 좁힌 범위 때문에 회귀를 놓친다는 우려로 매 사이클 전체를 도는 것은 비용 대비 효과가 없다.
+6. **`/task-test`로 바로 이어갈 때는 2의 전체 1회를 생략한다** — 격리 세션이 `## 검증 명령`·`## 테스트 명령`을 다시 전부 실행하므로 같은 스위트를 연달아 두 번 돌리는 셈이 된다. 세션이 `developed`에서 멈추고 사용자에게 제어를 넘길 때만 메인이 전체를 1회 실행한다. (결과: 전체 스위트는 태스크당 원칙 1회.)
+
+**테스트 신설은 요구 범위에 비례** — 신설하는 테스트는 *본 task 요구사항을 덮는 데 필요한 최소*로 둔다. 기존 스펙이 이미 덮는 영역을 중복 검증하는 테스트를 새로 만들지 않는다. 스위트가 커질수록 이후 모든 task의 재실행 비용이 늘어난다. 프로젝트별 상한(예: *"E2E는 핵심 흐름만"*)은 `.project/rules/TEST_RULE.local.md`가 있으면 그쪽을 우선한다.
 
 **FAIL 시**: Step 6의 FAIL 룰 동일 적용 (추측 fix 반복 방지 / 진단 로그 / 동일 신고 재발 시 root cause).
 
@@ -156,7 +187,7 @@ stash FRICTION_LOG #14+19 / #25 반영 — 유닛 테스트는 본 단계에서
 
 ### Step 8 — status 전환 + 결과 보고
 
-1. `set_status` 도구로 `developed` 전이 (또는 `npx @angar2/taskery set-status TASK-<NNN> developed`) — self-check + 테스트 PASS 후. (유효전이 코드 검증.)
+1. `set_status` 도구로 `developed` 전이 (또는 `npx @angar2/taskery set-status TASK-<NNN> developed`) — self-check + 테스트 PASS 후. (유효전이 코드 검증.) 수정 루프 국면을 거쳐 곧바로 `/task-test`로 이어가는 경우에는 Step 6.5 ⑥에 따라 *린트·타입체크 + 변경이 닿는 테스트 PASS*가 전이 근거이며, 전체 스위트는 격리 세션이 실행한다.
 2. 결과 보고:
 
 ```
@@ -170,15 +201,16 @@ stash FRICTION_LOG #14+19 / #25 반영 — 유닛 테스트는 본 단계에서
 
 ### Step 9 — 검수 서버 기동 (중단점·해당 시)
 
-**조건**: ① 이번 세션이 여기서 멈추고 사용자에게 제어를 넘김(= `/task-test`로 계속 진행하지 않음) + ② `CLAUDE.md`(코덱스 `AGENTS.md`)에 `## 검수 실행 명령`이 선언됨.
+**조건**: ① 이번 세션이 여기서 멈추고 사용자에게 제어를 넘김(= `/task-test`로 계속 진행하지 않음) + ② `AGENTS.md`에 `## 검수 실행 명령`이 선언됨.
 
 - 두 조건 충족 시 — 그 명령으로 서버를 *백그라운드* 기동(포트 = 기준 포트 + TASK번호) + 접속 URL 보고. 모바일 검수가 필요하다고 판단되면 터널도 기동.
 - `/task-test`로 계속 진행하면 본 단계 생략 (마지막 단계에서만 기동 — 상세: GIT_RULE "멀티세션 검수 환경").
 - `## 검수 실행 명령` 미선언(CLI/라이브러리 등) 또는 사용자 *"안 띄워도 돼"* 발화 시 생략.
+- **기동 전 확인 필수** — 새로 띄우기 전에 해당 포트·프로세스가 이미 살아 있는지 확인한다. `Port … is in use` 류 경고는 *이미 떠 있다*는 뜻이므로 무시하고 재기동하지 않는다. 종료할 때는 부모 프로세스만이 아니라 **자식 프로세스(브라우저·렌더러 창 등)까지** 확인해 정리한다 (recordion FRICTION 2026-08-05 — 중복 기동 + 창 잔존으로 두 번 지적, TASK-005 재발).
 
 ## 도구 가이드
 
-- **Read**: task 파일 / `CLAUDE.md` 검증 명령 / 관련 코드 정독
+- **Read**: task 파일 / `AGENTS.md` 검증 명령 / 관련 코드 정독
 - **Edit / Write**: 코드 작성 + Phase 체크박스 갱신 + Result 섹션 갱신
 - **Bash / 도구**: 검증 명령 실행 (린트/타입/빌드/단위테스트) / `set_status` 도구(또는 `npx @angar2/taskery set-status`) status 전이. **git 명령 절대 X — `/task-close`만 git 담당**
 - **Grep / Glob**: 추가 코드 탐색 (Phase 진행 중 인접 영향 발견 시)

package/template/shared/skills/task-init/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: task-init
-description: task 시작 — 워크트리 분기 + 6 섹션 빈 골격 + 헤더 6컬럼 (부모 브랜치 자동 기록 · status=draft) task.md 생성 (멀티세션 0.1.2+)
+description: task 시작 — 워크트리 분기 + 빈 골격(헤더 6컬럼 + 본문 5 섹션) (부모 브랜치 자동 기록 · status=draft) task.md 생성 (멀티세션 0.1.2+)
 ---
 
 # /task-init
@@ -13,22 +13,22 @@ description: task 시작 — 워크트리 분기 + 6 섹션 빈 골격 + 헤더
 
 ## 호출 시점 + 입력
 
-- 새 task 시작 (*"~~ 추가해줘"* / *"~~ 버그 고쳐"* / *"~~ 리팩터링"*), 백로그 진행(*"BL-003 진행하자"*), 로드맵 진행(*"RM-002 시작"*).
-- 인자 = (선택) 주제 / 유형 / 출처(BL-NNN, RM-NNN, DR) / 규모.
+- 새 task 시작 (*"~~ 추가해줘"* / *"~~ 버그 고쳐"* / *"~~ 리팩터링"*), 백로그 진행(*"BL-003 진행하자"*), 로드맵 진행(*"Stage 2 진행하자"* / *"로드맵 다음 거 시작"*).
+- 인자 = (선택) 주제 / 유형 / 출처(BL-NNN, ST-N, DR) / 규모.
 - **두 분기**: ① **제안** — 직전 맥락 명확 → *"이렇게 task 만들까요?"* + confirm. ② **인터뷰** — 맥락 부족 → 한 번에 한 질문씩.
 - **자동 추정 진행 X** — confirm 또는 답 받기 전 워크트리/파일 생성 금지.
 
 ## Step 1 — 메타 수집
 
 직전 대화 정독 → 추정 가능하면 분기 1(제안), 불가하면 분기 2(인터뷰):
-- Q1 *"무슨 작업? (한 줄로)"* / Q2 *"유형? (feature / bug / improvement / refactor / docs / chore)"* / Q3 *"출처? (백로그 BL-NNN / 로드맵 RM-NNN / 직접 요구사항 DR)"* / Q4 *"규모? (micro / small / medium / large)"* / (필요 시) Q5 *"plan `<NNN_slug>` 맞나요?"*
+- Q1 *"무슨 작업? (한 줄로)"* / Q2 *"유형? (feature / bug / improvement / refactor / docs / chore)"* / Q3 *"출처? (백로그 BL-NNN / 로드맵 Stage ST-N / 직접 요구사항 DR)"* / Q4 *"규모? (micro / small / medium / large)"* / (필요 시) Q5 *"plan `<NNN_slug>` 맞나요?"*
 
-수집 항목(모두 확정 후 진행): 주제(한국어) · 유형 · 출처 · 규모 · plan(활성 plan — `status` 도구나 AGENT-GUIDE에서). 활성 plan 부재 시 *"`/plan-init` 먼저 실행할까요?"* 안내 + 중단.
+수집 항목(모두 확정 후 진행): 주제(한국어) · 유형 · 출처 · 규모 · plan(활성 plan — `status` 도구에서). 활성 plan 부재 시 *"`/plan-init` 먼저 실행할까요?"* 안내 + 중단.
 
 ## Step 2 — 출처별 메타 + 슬러그
 
 - **BL**: `backlog_get` 도구(또는 `npx @angar2/taskery backlog-get BL-NNN`) → `{ blId, status, type, title, slug, summary, target, taskNums }`. 항목 없으면 에러 → 보고 + 중단. **개요/대상 영역은 task.md §1 Requirements 초안 시작점**으로 기억(본문은 task-plan에서). 슬러그 = 반환 `slug` 그대로(재현성 — 별도 변환 X).
-- **RM**: `$MAIN_WT/.project/plans/<활성 plan>/ROADMAP.md`에서 `RM-NNN` 항목 메타 파싱. 슬러그 = ROADMAP에 박힌 그대로.
+- **ST**: `$MAIN_WT/.project/plans/<활성 plan>/ROADMAP.md`에서 해당 Stage N의 작업 단위 확인 → 이번 task가 맡을 작업 단위를 사용자와 confirm. 슬러그 = 그 작업 단위 제목 → 영어 kebab-case(3 단어 이내) → confirm. (ROADMAP은 Stage 단위·별도 항목 채번 없음 — `ST-N` = Stage 번호 그대로.)
 - **DR**: 사용자 발화에서 주제 그대로. 슬러그 = 한국어 제목 → 영어 kebab-case(3 단어 이내) → confirm.
 
 **이미 `[x]` BL 재진행 케이스** — `backlog_get` 결과 `status==='checked'` & `taskNums` 비어있지 않으면: 사용자 호출 *"BL-NNN은 ${taskNums}로 이미 처리된 적 있어. 새 task로 다시 진행할까?"* → OK면 새 TASK 진행(§4 마킹은 콤마 누적) / X면 중단.
@@ -41,15 +41,15 @@ description: task 시작 — 워크트리 분기 + 6 섹션 빈 골격 + 헤더
 
 ## Step 4 — 분기 + 골격 생성 (`task_init`) + BL 마킹
 
-`task_init` 도구(또는 `npx @angar2/taskery fork <타입> <개발자> <출처> <슬러그> --size <규모> --title "<한국어 제목>" [--promote]`) 한 번으로 **채번 → 워크트리·브랜치 생성**(init 락 원자 — 병렬 task-init 번호 충돌·동일 출처 중복·동일 브랜치명을 코드가 차단)에 더해 **빈 골격 task.md 자동 생성**(생성일=오늘 · plan=활성 plan · 유형 자동매핑 `improve`→`improvement` · **부모 브랜치=fork 시점 현재 브랜치 자동 기록**(dev 고정 아님) · status=draft · `.gitignore` 케이스로 위치 자동 판정)까지 수행한다.
+`task_init` 도구(또는 `npx @angar2/taskery fork <타입> <개발자> <출처> <슬러그> --size <규모> --title "<한국어 제목>" [--promote]`) 한 번으로 **채번 → 워크트리·브랜치 생성**(init 락 원자 — 병렬 task-init 번호 충돌·동일 출처 중복(**BL·구형 RM 한정** — `ST-N`은 Stage 하나에서 복수 task가 정상, `DR`은 ID 없음이라 둘 다 중복 검사 제외)·동일 브랜치명을 코드가 차단)에 더해 **빈 골격 task.md 자동 생성**(생성일=오늘 · plan=활성 plan · 유형 자동매핑 `improve`→`improvement` · **부모 브랜치=fork 시점 현재 브랜치 자동 기록**(dev 고정 아님) · status=draft · `.gitignore` 케이스로 위치 자동 판정)까지 수행한다.
 
-- 반환 `{ taskNum, nnn, branch, wtPath, projectId, docPath, registered, promoted }`. 폴더 승격은 `--promote`/`promote:true`.
+- 반환 `{ taskNum, nnn, branch, wtPath, projectId, parent, docPath, registered, promoted }` (`parent` = fork 시점 현재 브랜치 = 이 task의 부모 브랜치. `/task-close`가 이 브랜치로 되병합한다). 폴더 승격은 `--promote`/`promote:true`.
 - 에러 시(*"… 이미 진행중"* / *"… detached HEAD"* — 부모 브랜치(현재 브랜치) 확인·SSoT를 fork가 강제) stderr 메시지 그대로 보고 + 중단.
-- **BL 출처면** 직후 `backlog_mark` 도구(또는 `npx @angar2/taskery backlog-mark BL-NNN TASK-NNN`)로 `[ ]→[x]` + `- TASK:` 마크(콤마 누적, withMetaLock). RM/DR은 skip.
+- **BL 출처면** 직후 `backlog_mark` 도구(또는 `npx @angar2/taskery backlog-mark BL-NNN TASK-NNN`)로 `[ ]→[x]` + `- TASK:` 마크(콤마 누적, withMetaLock). ST/DR은 skip.
 
 ## Step 5 — 골격 확인 + 보고
 
-반환 `docPath`(절대 경로)를 Read해 헤더 6컬럼 + 6 섹션 placeholder + status=draft 확인만 한다. **본문 작성 금지** — Requirements / Scope / Dev Plan / Test Plan은 *반드시* `/task-plan`에서.
+반환 `docPath`(절대 경로)를 Read해 헤더 6컬럼 + 본문 5 섹션(Requirements / Scope / Dev Plan / Test Plan / Result) placeholder + status=draft 확인만 한다. (`TASK_DOC_RULE`이 말하는 "6 섹션"은 헤더 표를 1개로 세는 표기다.) **본문 작성 금지** — Requirements / Scope / Dev Plan / Test Plan은 *반드시* `/task-plan`에서.
 
 > **폴백** (반환에 `docPath` 없이 `scaffoldError`만 있을 때만): TASK_DOC_RULE §1.3 형식으로 해당 위치에 직접 작성(생성일=오늘, status=draft, 단일=`<NNN>_<slug>.md` / 폴더=`TASK-<NNN>_<slug>/task.md`).
 
@@ -57,17 +57,17 @@ description: task 시작 — 워크트리 분기 + 6 섹션 빈 골격 + 헤더
 ✅ TASK-<NNN> 생성 완료
 - 워크트리: <wtPath> / 브랜치: <branch> / task 문서: <docPath>
 - 헤더: <생성일> / <plan> / <유형> / <규모> / <부모 브랜치> / draft
-- BL 마킹: BL-<NNN> [x] (BL 출처 시. RM/DR 생략)
+- BL 마킹: BL-<NNN> [x] (BL 출처 시. ST/DR 생략)
 - 다음: /task-plan TASK-<NNN> 으로 기획 채우기
 ```
 
 ## 주의사항
 
 - **워크트리 생성 + 골격 작성만** — 본문 채우기 금지. Requirements / Scope / Dev Plan / Test Plan은 *반드시* `/task-plan`.
-- **단계 경계** — 허용: ROADMAP §4 확인 / SSoT 조회 / `task_init` 호출 / 빈 골격 확인. 금지: ARCHITECTURE/API-SPEC/FEATURES 등 루트 제품 관통 문서 본문 Read · 도메인 코드 Read·Grep · 기존 task 본문 Read (그건 `/task-plan` 영역).
+- **단계 경계** — 허용: ROADMAP의 해당 Stage 확인(출처가 `ST-N`일 때) / SSoT 조회 / `task_init` 호출 / 빈 골격 확인. 금지: ARCHITECTURE/API-SPEC/FEATURES 등 루트 제품 관통 문서 본문 Read · 도메인 코드 Read·Grep · 기존 task 본문 Read (그건 `/task-plan` 영역).
 - **자동 추정 진행 X** — 맥락 명확해도 *제안 + OK* 후 생성.
 - **상태는 `draft` 고정** · **slug 영어 kebab-case** · **헤더 6컬럼 모두 채움**(*"미정"* placeholder X — 코드가 채움. 부모 브랜치도 코드 자동 기록).
-- **fork 실패(같은 브랜치명 / 같은 출처 진행중) → 사용자 호출** + 중단(*"다른 세션이 같은 항목 진행 중"*).
+- **fork 실패(같은 브랜치명 / 같은 출처 진행중 — BL·구형 RM 한정) → 사용자 호출** + 중단(*"다른 세션이 같은 항목 진행 중"*). `ST-N`·`DR`은 중복 게이트가 없으므로 같은 Stage로 두 번째 task를 만들 때 코드가 막아주지 않는다 — 중복 진행 여부는 메인이 `status`로 확인한다.
 
 ## 상태 전이