@angar2/taskery 0.6.1 → 0.7.0

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,19 +47,20 @@ 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 게이트는 *코드 상태*만, 테스트는 *별도 단계*.
-5. **프로젝트 로컬 룰 확인** — `$MAIN_WT/.project/rules/DEV_RULE.local.md`(구현 정책)와 `$MAIN_WT/.project/rules/TEST_RULE.local.md`(테스트 범위·방식 정책)를 각각 있으면 Read한다 (없으면 넘어간다. `npx update` 미터치 영역이라 프로젝트가 자유롭게 소유한다). 본 스킬 조항과 겹치는 항목은 **로컬 룰을 우선 적용**한다 — 프로젝트마다 구현·테스트 실행 방식이 다르므로 본 스킬 조항은 *안전한 기본값*이다. **Step 6.5의 테스트 실행 범위·신설 상한은 `TEST_RULE.local.md`가 있으면 그 규정을 따른다** (본 스킬이 테스트를 실제로 실행하는 주체이므로, 그 파일을 읽지 않으면 프로젝트 고유 규칙이 무력해진다).
+   - **미기입 가드**: 값이 `<예:` 로 시작하는 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)
@@ -100,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 기준 |
 |------|---------|
@@ -120,7 +121,7 @@ Dev Plan에 Phase 0(제품 관통 문서 변경)이 있으면:
 
 stash FRICTION_LOG #14+19 / #25 반영 — 유닛 테스트는 본 단계에서 단일 시점 실행 (task-close / hook 영역 중복 제거).
 
-`CLAUDE.md` `## 테스트 명령` 섹션의 명령을 *전부* 실행. 모두 PASS여야 `developed`로 전이 가능. **본 게이트는 *구현 완료 시점 1회*다** — 아래 "수정 루프 국면"에 해당하는 동안에는 매 사이클 전부 실행하지 않는다. 또한 수정 루프 국면을 거친 뒤 곧바로 `/task-test`로 이어가는 경우에는 국면 ⑥에 따라 본 게이트의 전체 실행을 생략하고 *격리 세션의 실행*으로 갈음한다 (그때의 `developed` 전이 근거 = 린트·타입체크 PASS + 변경이 닿는 테스트 PASS이며, 전체 스위트는 격리 세션이 책임진다).
+`AGENTS.md` `## 테스트 명령` 섹션의 명령을 *전부* 실행. 모두 PASS여야 `developed`로 전이 가능. **본 게이트는 *구현 완료 시점 1회*다** — 아래 "수정 루프 국면"에 해당하는 동안에는 매 사이클 전부 실행하지 않는다. 또한 수정 루프 국면을 거친 뒤 곧바로 `/task-test`로 이어가는 경우에는 국면 ⑥에 따라 본 게이트의 전체 실행을 생략하고 *격리 세션의 실행*으로 갈음한다 (그때의 `developed` 전이 근거 = 린트·타입체크 PASS + 변경이 닿는 테스트 PASS이며, 전체 스위트는 격리 세션이 책임진다).
 
 | 명령 | PASS 기준 |
 |------|---------|
@@ -142,13 +143,13 @@ stash FRICTION_LOG #14+19 / #25 반영 — 유닛 테스트는 본 단계에서
 
 | 상황 | 실행 방식 |
 |------|----------|
-| `TEST-GUIDE.md` *테스트 실행 환경* 절에 **격리 실행 경로**(창 숨김·헤드리스 플래그 / 컨테이너·가상 디스플레이 / VM / CI 러너) 선언됨 | 그 경로로 **자동 실행 OK** |
+| `TEST_RULE.local.md` *테스트 실행 환경* 절에 **격리 실행 경로**(창 숨김·헤드리스 플래그 / 컨테이너·가상 디스플레이 / VM / CI 러너) 선언됨 | 그 경로로 **자동 실행 OK** |
 | 격리 경로 없음 + 비점유 부분만 한정 실행 가능 (번들·프로젝트·태그 지정 등) | **비점유 부분만 자동 실행**, 점유 스위트는 제외 |
 | 격리 경로 없음 + 한정 수단도 없음 | **자동 실행 금지** — 사용자에게 *무엇을 왜 돌려야 하고 얼마나 걸리며 그동안 화면·입력을 못 쓴다*를 예고하고 승인을 받은 뒤에만 실행 |
 
 - 헤드리스 모드가 존재하면 항상 그쪽을 쓴다.
 - 본 task가 UI를 건드리지 않는데(순수 로직·CLI 등) 테스트 명령이 UI 스위트를 포함하면, 그 스위트는 실행 대상이 아니다.
-- 격리 실행 경로를 새로 확인했으면 `TEST-GUIDE.md` *테스트 실행 환경* 절에 기록해 다음 task가 재사용하게 한다.
+- 격리 실행 경로를 새로 확인했으면 `TEST_RULE.local.md` *테스트 실행 환경* 절에 기록해 다음 task가 재사용하게 한다.
 
 **수정 루프 국면 — 재실행 범위 비례 (recordion FRICTION 2026-08-08 반영)**:
 
@@ -156,7 +157,7 @@ stash FRICTION_LOG #14+19 / #25 반영 — 유닛 테스트는 본 단계에서
 
 1. **매 사이클 실행** — 린트·타입체크(수 초) + *변경한 파일이 닿는 테스트* + 그 테스트가 쓰는 공유 헬퍼를 함께 쓰는 테스트. 대개 1~2개·수십 초다.
 2. **전체 게이트(Step 6 + Step 6.5)는 국면이 끝날 때 1회** — 국면 도중에는 돌리지 않는다. 풀빌드를 포함한 Step 6도 매 사이클 대상이 아니다. (국면이 끝나는 시점에 *실제로 돌릴지*는 아래 ⑥이 정한다 — 바로 `/task-test`로 이어가면 격리 세션의 실행으로 갈음한다.)
-3. **테스트 러너가 빌드를 포함하지 않으면 빌드를 선행**한다 — 옛 산출물로 돌면 이미 고친 결함이 남아 있는 것처럼 보여 없는 버그를 쫓게 된다 (recordion에서 이 때문에 30분을 소모했다). 어느 명령이 빌드를 포함하는지는 `TEST-GUIDE.md`에 기록해 재사용한다.
+3. **테스트 러너가 빌드를 포함하지 않으면 빌드를 선행**한다 — 옛 산출물로 돌면 이미 고친 결함이 남아 있는 것처럼 보여 없는 버그를 쫓게 된다 (recordion에서 이 때문에 30분을 소모했다). 어느 명령이 빌드를 포함하는지는 `TEST_RULE.local.md`에 기록해 재사용한다.
 4. **무관한 테스트가 깨질 때만 범위를 넓힌다** — 예상 밖 실패가 나오면 그때 상위 범위로 확대한다.
 5. **회귀 누락 위험은 2 + `/task-test` 격리 세션의 이중 게이트가 막는다.** 좁힌 범위 때문에 회귀를 놓친다는 우려로 매 사이클 전체를 도는 것은 비용 대비 효과가 없다.
 6. **`/task-test`로 바로 이어갈 때는 2의 전체 1회를 생략한다** — 격리 세션이 `## 검증 명령`·`## 테스트 명령`을 다시 전부 실행하므로 같은 스위트를 연달아 두 번 돌리는 셈이 된다. 세션이 `developed`에서 멈추고 사용자에게 제어를 넘길 때만 메인이 전체를 1회 실행한다. (결과: 전체 스위트는 태스크당 원칙 1회.)
@@ -200,7 +201,7 @@ stash FRICTION_LOG #14+19 / #25 반영 — 유닛 테스트는 본 단계에서
 
 ### Step 9 — 검수 서버 기동 (중단점·해당 시)
 
-**조건**: ① 이번 세션이 여기서 멈추고 사용자에게 제어를 넘김(= `/task-test`로 계속 진행하지 않음) + ② `CLAUDE.md`(코덱스 `AGENTS.md`)에 `## 검수 실행 명령`이 선언됨.
+**조건**: ① 이번 세션이 여기서 멈추고 사용자에게 제어를 넘김(= `/task-test`로 계속 진행하지 않음) + ② `AGENTS.md`에 `## 검수 실행 명령`이 선언됨.
 
 - 두 조건 충족 시 — 그 명령으로 서버를 *백그라운드* 기동(포트 = 기준 포트 + TASK번호) + 접속 URL 보고. 모바일 검수가 필요하다고 판단되면 터널도 기동.
 - `/task-test`로 계속 진행하면 본 단계 생략 (마지막 단계에서만 기동 — 상세: GIT_RULE "멀티세션 검수 환경").
@@ -209,7 +210,7 @@ stash FRICTION_LOG #14+19 / #25 반영 — 유닛 테스트는 본 단계에서
 
 ## 도구 가이드
 
-- **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
@@ -23,7 +23,7 @@ description: task 시작 — 워크트리 분기 + 6 섹션 빈 골격 + 헤더
 직전 대화 정독 → 추정 가능하면 분기 1(제안), 불가하면 분기 2(인터뷰):
 - 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 — 출처별 메타 + 슬러그
 
@@ -49,7 +49,7 @@ description: task 시작 — 워크트리 분기 + 6 섹션 빈 골격 + 헤더
 
 ## 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`).
 

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

@@ -13,7 +13,7 @@ description: task 기획 채우기 — Requirements / Scope / Dev Plan / Test Pl
 
 ## 멀티세션 메타 위치 (0.1.2+)
 
-본 스킬은 워크트리에서 호출되는 게 default (멀티세션 — 각 워크트리 = 독립 세션). 다만 호출 위치 자유 — 메인 cwd / 서브 세션 호출 등 다른 운영 모델에서도 cwd 무관 동작. 메타(`.project/`, `CLAUDE.md`) 접근 시 **메인 워크트리 절대 경로** 우선 — *task 문서 단일 진실 소스* 유지.
+본 스킬은 워크트리에서 호출되는 게 default (멀티세션 — 각 워크트리 = 독립 세션). 다만 호출 위치 자유 — 메인 cwd / 서브 세션 호출 등 다른 운영 모델에서도 cwd 무관 동작. 메타(`.project/`, `AGENTS.md`) 접근 시 **메인 워크트리 절대 경로** 우선 — *task 문서 단일 진실 소스* 유지.
 
 ```sh
 MAIN_WT=$(dirname "$(git rev-parse --path-format=absolute --git-common-dir)")
@@ -23,8 +23,8 @@ MAIN_WT=$(dirname "$(git rev-parse --path-format=absolute --git-common-dir)")
 
 | 케이스 | task 문서 위치 | 제품 관통 문서 위치 | 동시 쓰기 |
 |--------|--------------|----------------|----------|
-| 등록 (퍼블릭 리포 default) | `$MAIN_WT/.project/tasks/<NNN_slug>/...` | `$MAIN_WT/.project/<doc>.md` (루트 평평) | `withMetaLock` (`bin/lib.js`) |
-| 미등록 | `$WT_PATH/.project/tasks/<NNN_slug>/...` (워크트리 안, 머지 시 부모 브랜치 반영) | `$MAIN_WT/.project/<doc>.md` (제품 문서는 여전히 단일 소스) | 단일 세션 가정 (워크트리 내부) |
+| 등록 (`.project/`가 `.gitignore`에 있음) | `$MAIN_WT/.project/tasks/<NNN_slug>/...` | `$MAIN_WT/.project/<doc>.md` (루트 평평) | `withMetaLock` (`bin/lib.js`) |
+| 미등록 (**기본 설치값** — `fork`/`status` 반환의 `registered:false`) | `$WT_PATH/.project/tasks/<NNN_slug>/...` (워크트리 안, 머지 시 부모 브랜치 반영) | `$MAIN_WT/.project/<doc>.md` (제품 문서는 여전히 단일 소스) | 단일 세션 가정 (워크트리 내부) |
 
 본문 모든 `.project/...` 경로는 *위 분기에 따라* 적용. spec-diff / mockup / screenshots는 task 문서와 같은 위치.
 
@@ -46,15 +46,15 @@ MAIN_WT=$(dirname "$(git rev-parse --path-format=absolute --git-common-dir)")
 
 ### Step 1 — task 파일 + active plan 확인
 
-1. `.project/AGENT-GUIDE.md` Read → 활성 plan 버전 확인.
+1. `status` 도구(또는 `npx @angar2/taskery status`)로 활성 plan 확인.
 2. task 파일 Read:
    - 인자 있음 → 해당 파일.
-   - 인자 없음 → `ls .project/tasks/<NNN_slug>/` 결과 중 status=draft인 가장 최근 파일. 발견 시 *"TASK-<NNN> 진행할까요?"* confirm. 없으면 *"draft 상태 task가 없네요. `/task-init` 먼저 호출하세요."* + 종료.
+   - 인자 없음 → `status` 도구(또는 `npx @angar2/taskery status`)의 *진행중 태스크* 목록에서 후보를 찾는다 — task 문서는 미등록 케이스에서 **각 task의 워크트리 안에만** 있으므로, 메인 워크트리에서 `ls .project/tasks/<NNN_slug>/`로 찾으면 아무것도 안 나와 *"task가 없다"*고 잘못 끝난다. 각 후보의 문서 경로는 `status`가 알려주는 워크트리 경로 아래 `.project/tasks/<NNN_slug>/`다. 그중 status=`draft`인 가장 최근 task. 발견 시 *"TASK-<NNN> 진행할까요?"* confirm. 진행중 목록 자체가 비어 있을 때만 *"draft 상태 task가 없네요. `/task-init` 먼저 호출하세요."* + 종료.
 3. 상태 검증 — 두 진입만 허용, 그 외 종료 + 안내:
    - **`draft`** → 일반 기획 (Step 2~ 전체 진행).
    - **`testing` + Test Plan 보수 모드** → `/task-test`가 *시험문제 결함*으로 반려해 되돌아온 경우에 한해 허용. 이때는 **Test Plan 섹션만 보수**(Requirements / Scope / Dev Plan 보존), Step 2~4는 건너뛰고 Step 5(Test Plan)만 수행, status는 `testing` 그대로 둔다(전이 X — 보수 후 `/task-test` 재실행).
    - **그 외(`planned` / `developing` / `developed` / `tested` / `closed`)** → 종료 + 안내. (특히 `tested` / `closed`는 보수 모드로도 진입 거부 — 우회 방지.)
-4. **프로젝트 로컬 룰 확인** — `$MAIN_WT/.project/rules/TEST_RULE.local.md`가 있으면 Read한다 (없으면 넘어간다). Test Plan의 검증 범위·방식 선택에서 본 스킬 조항과 겹치면 **로컬 룰 우선** (멀티세션 불변식·안전 조항 제외).
+4. **프로젝트 로컬 룰 확인** — `$MAIN_WT/.project/rules/TEST_RULE.local.md`를 Read한다. 모든 리포에 있어야 하는 필수 문서다(`TASKERY_RULE` §8) — **없으면 Step 5 실행 경로 확인 단계에서 생성**한다. 로컬 룰의 조항은 코어와 동등한 구속력을 가진다 — 겹치면 로컬이 최우선이고, **겹치지 않는 로컬 조항도 그대로 준수한다** (안전선 제외 — `TASKERY_RULE` §7).
 
 ### Step 2 — Requirements 인터뷰 + 증폭
 
@@ -188,7 +188,7 @@ Step 2 Requirements 인터뷰 결과로 본 task가 *UX/UI 구현 (페이지/컴
 승인된 목업 = task-test의 **시각 *자동 대조* 정답지** (+ 미세 취향은 사용자 최종 사인). 사용자가 맘에 들 때까지 승인 안 하므로 목업 = 이미 사용자가 검증한 정답지 — task-test 격리 세션이 *실제 화면 캡처 → 이 목업과 자동 대조*해 객관적 깨짐을 잡는다. Step 5 Test Plan 작성 시:
 - **시각 *객관* 영역(레이아웃/요소 유무/색/배치) → `[AUTO]`** (캡처-목업 대조) + 목업 경로 참조 명시.
 - **시각 *미세 취향*(2px·색조·느낌) → `[USER]`** (사용자 최종 사인, 증거 캡처).
-- **`[AUTO]` 승격 조건 — 실행 경로 확인 필수**: 시각 객관 영역의 `[AUTO]` 분류는 `$MAIN_WT/.project/TEST-GUIDE.md` *시각 실행* 절에 **이 프로젝트의 캡처 실행 경로가 적혀 있을 때만** 성립한다. 목업 존재는 *정답지 확보*일 뿐 *실행 경로 확보*가 아니다. 경로가 없거나, 앱 기동이 사용자 실데이터·전역 단축키·화면 입력을 건드리는 구조면 `[USER]` 폴백으로 둔다 (stash FRICTION 2026-07-27 — 경로 없는 `[AUTO]` 분류로 `/task-test` 2회 왕복). **다른 방식과 달리 시각은 경로가 없다고 사용자에게 도구 도입을 요구하며 멈추지 않는다** — 조용히 `[USER]`로 두고 진행한다. 자동화 도입 여부는 사용자가 원할 때 별도로 정한다.
+- **`[AUTO]` 승격 조건 — 실행 경로 확인 필수**: 시각 객관 영역의 `[AUTO]` 분류는 `$MAIN_WT/.project/rules/TEST_RULE.local.md` *시각 실행* 절에 **이 프로젝트의 캡처 실행 경로가 적혀 있을 때만** 성립한다. 목업 존재는 *정답지 확보*일 뿐 *실행 경로 확보*가 아니다. 경로가 없거나, 앱 기동이 사용자 실데이터·전역 단축키·화면 입력을 건드리는 구조면 `[USER]` 폴백으로 둔다 (stash FRICTION 2026-07-27 — 경로 없는 `[AUTO]` 분류로 `/task-test` 2회 왕복). **다른 방식과 달리 시각은 경로가 없다고 사용자에게 도구 도입을 요구하며 멈추지 않는다** — 조용히 `[USER]`로 두고 진행한다. 자동화 도입 여부는 사용자가 원할 때 별도로 정한다.
 (이전의 "승인 목업 = USER 검수 기준 / 시각=전부 [USER]"는 폐기 — 사용자에게 흠 사냥을 떠넘기던 원인.)
 
 ---
@@ -235,14 +235,14 @@ Test Plan = *본 task에서 구현한 요구사항이 정상 동작하는지*
 | 회귀 시나리오 | 기존 기능 영향 | 이전과 동일 결과 | test 자동 | 직전 동작하던 시나리오 재실행 |
 | E2E 자동화 도구 | UI 동작 자동화 (도구 있을 시) | 액션 후 관측 변화 | 도구면 test, 아니면 사람 | Playwright / Cypress / XCTest UI Test 등 — 가능하면 자동화, 안 되면 수동 검수. **화면·입력 점유 여부를 먼저 확인** (아래) |
 
-> **점유 스위트의 `[AUTO]` 조건** — UI를 실제 조작하는 자동화(XCUITest·headed 브라우저 E2E 등)는 실행 중 사용자의 화면·마우스·키보드를 점유한다. 이런 방식을 `[AUTO]`로 두려면 `TEST-GUIDE.md` *테스트 실행 환경* 절에 **격리 실행 경로**(창 숨김·헤드리스 플래그 / 컨테이너·가상 디스플레이 / VM / CI 러너)가 있어야 한다. 없으면 `[USER]`로 두거나 *사용자 승인 후 실행*을 시나리오에 명시한다 — 그냥 `[AUTO]`로 두면 격리 세션이 실행하지 못하고 *실행 보류*로 돌려보내 왕복이 생긴다 (stash FRICTION 2026-07-25 · recordion FRICTION 2026-08-05 — 자동 게이트가 사용자 작업을 중단시킨 마찰).
+> **점유 스위트의 `[AUTO]` 조건** — UI를 실제 조작하는 자동화(XCUITest·headed 브라우저 E2E 등)는 실행 중 사용자의 화면·마우스·키보드를 점유한다. 이런 방식을 `[AUTO]`로 두려면 `TEST_RULE.local.md` *테스트 실행 환경* 절에 **격리 실행 경로**(창 숨김·헤드리스 플래그 / 컨테이너·가상 디스플레이 / VM / CI 러너)가 있어야 한다. 없으면 `[USER]`로 두거나 *사용자 승인 후 실행*을 시나리오에 명시한다 — 그냥 `[AUTO]`로 두면 격리 세션이 실행하지 못하고 *실행 보류*로 돌려보내 왕복이 생긴다 (stash FRICTION 2026-07-25 · recordion FRICTION 2026-08-05 — 자동 게이트가 사용자 작업을 중단시킨 마찰).
 
 #### UX/UI 영역 분리 + 검증 방식 매트릭스 (UX/UI 구현 task 한정)
 
 | 영역 | 분류 | 기준 |
 |------|------|------|
 | 동작 (클릭/호버/드래그/입력 → 결과) | 도구 있고 *점유하지 않게 돌릴 경로*가 있으면 `[AUTO]` E2E, 없으면 `[USER]` 체크리스트 | 액션 후 관측되는 변화 |
-| 시각 *객관* (레이아웃/요소 유무/색/배치 깨짐) | TEST-GUIDE에 캡처 실행 경로 **있으면** `[AUTO]` 캡처-목업 대조 (원칙), **없으면** `[USER]` 폴백 | 승인된 목업 (격리 세션이 화면 캡처 → 대조 → 어긋남 목록) |
+| 시각 *객관* (레이아웃/요소 유무/색/배치 깨짐) | TEST_RULE.local.md에 캡처 실행 경로 **있으면** `[AUTO]` 캡처-목업 대조 (원칙), **없으면** `[USER]` 폴백 | 승인된 목업 (격리 세션이 화면 캡처 → 대조 → 어긋남 목록) |
 | 시각 *미세 취향* (2px·색조·호버 강도·느낌) | `[USER]` 체크리스트 + 목업 참조 | 사용자 최종 사인 (증거 캡처 첨부) |
 
 #### 시나리오 형식 — [명령/입력] + [구체적 기대값] 한 쌍 강제
@@ -309,19 +309,19 @@ Test Plan 작성 완료 후 *반드시* 점검 단계 수행. *"누적/리셋
 
 방식을 골랐어도, **격리 세션이 *이 프로젝트의* DB/API/E2E에 실제로 어떻게 접근하는지 모르면 그 시나리오는 실행 불가능한 허울뿐인 명세다.** 스택마다 다르다(NestJS+TypeORM이면 그 DataSource/repository, 다른 프로젝트는 또 다름). 그래서 *모르면 묻고, 알면 재사용*:
 
-1. 필요 방식마다 `$MAIN_WT/.project/TEST-GUIDE.md`를 Read → **이 프로젝트에 실행 경로가 적혀 있나** 확인. **데이터·API·E2E뿐 아니라 *시각(앱 기동 + 화면 캡처)* 방식도 동일하게 확인 대상이다** — 목업이 있다는 사실은 실행 경로 확보가 아니다.
+1. 필요 방식마다 `$MAIN_WT/.project/rules/TEST_RULE.local.md`를 Read → **이 프로젝트에 실행 경로가 적혀 있나** 확인. **데이터·API·E2E뿐 아니라 *시각(앱 기동 + 화면 캡처)* 방식도 동일하게 확인 대상이다** — 목업이 있다는 사실은 실행 경로 확보가 아니다.
 2. **있으면** → 그 경로를 시나리오의 *방식* 칸에 반영(재사용). 앱은 기존 실행 명령으로 띄움.
 3. **없으면** → *멈추고 사용자에게 요구*: 예) *"이 요구사항은 DB 검증이 필요한데 이 프로젝트에 실행 경로가 없다. 어떻게 검증할지 알려주거나 도구를 깔아줘."* → 사용자가 경로를 주거나 결정. **단 시각 방식은 예외** — 멈추지 않고 `[USER]` 폴백으로 두고 진행한다 (Step 4.5 §5 참조).
-4. **확인받은 즉시 `TEST-GUIDE.md`에 기록** → 다음 task/세션부터 안 묻고 재사용. (재사용 = 기억이 아니라 *파일* — 세션/컴팩트로 사라지지 않게.)
+4. **확인받은 즉시 `TEST_RULE.local.md`에 기록** → 다음 task/세션부터 안 묻고 재사용. (재사용 = 기억이 아니라 *파일* — 세션/컴팩트로 사라지지 않게.)
 
-> TEST-GUIDE는 init이 빈 골격으로 깔아둔다(`.project/TEST-GUIDE.md`). 방식별 섹션(데이터 검증 / API 호출 / UI·E2E / 시각 실행 / 기타)에 *이 프로젝트의 실제 실행 방법*을 채운다.
+> `TEST_RULE.local.md`는 `/project-init`이 골격을 만들어 둔다. 파일이 없으면(사후 도입·구형 리포) **본 단계에서 생성**한다 — 골격은 `TASKERY_RULE` §8 구성을 따른다. 방식별 섹션(데이터 검증 / API 호출 / UI·E2E / 시각 실행 / 기타)에 *이 프로젝트의 실제 실행 방법*을 채운다.
 
 #### 검증/테스트 명령 참조
 
-`/task-test` 격리 세션은 프로젝트 루트 `CLAUDE.md`의 두 섹션 + `TEST-GUIDE.md`를 자동 참조 — Test Plan에 재인용 불필요:
+`/task-test` 격리 세션은 진입 문서(`AGENTS.md`)의 두 섹션 + `TEST_RULE.local.md`를 자동 참조 — Test Plan에 재인용 불필요:
 - `## 검증 명령` (코드 상태 — 빌드/린트/타입체크)
 - `## 테스트 명령` (테스트 실행 — 단위/통합/E2E)
-- `.project/TEST-GUIDE.md` (각 방식의 *이 프로젝트 실제 실행 방법*)
+- `.project/rules/TEST_RULE.local.md` (각 방식의 *이 프로젝트 실제 실행 방법*)
 
 ### Step 6 — spec-diff 처리 (Phase 0 변경 있을 시)
 

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

@@ -23,12 +23,12 @@ MAIN_WT=$(dirname "$(git rev-parse --path-format=absolute --git-common-dir)")
 
 | 케이스 | task 문서 위치 | 격리 세션 작업 디렉토리 |
 |--------|--------------|---------------------|
-| 등록 (퍼블릭 리포 default) | `$MAIN_WT/.project/tasks/<NNN_slug>/...` | `$WT_PATH` (워크트리 — 코드 변경 위치) |
-| 미등록 | `$WT_PATH/.project/tasks/<NNN_slug>/...` (워크트리 안) | `$WT_PATH` (워크트리) |
+| 등록 (`.project/`가 `.gitignore`에 있음) | `$MAIN_WT/.project/tasks/<NNN_slug>/...` | `$WT_PATH` (워크트리 — 코드 변경 위치) |
+| 미등록 (**기본 설치값** — `fork`/`status` 반환의 `registered:false`) | `$WT_PATH/.project/tasks/<NNN_slug>/...` (워크트리 안) | `$WT_PATH` (워크트리) |
 
-격리 세션은 *워크트리 안*에서 검증/테스트 명령 실행 (`$MAIN_WT/CLAUDE.md`의 `## 검증 명령` / `## 테스트 명령` 단일 진실 소스).
+격리 세션은 *워크트리 안*에서 검증/테스트 명령 실행 (`$MAIN_WT/AGENTS.md`의 `## 검증 명령` / `## 테스트 명령` 단일 진실 소스).
 
-**검증 방법 출처 = `$MAIN_WT/.project/TEST-GUIDE.md`** — 각 테스트 방식(데이터 조회 / API 호출 / E2E / 시각 실행)을 *이 프로젝트에서 실제로 어떻게 돌리나*가 적힌 단일 소스. 격리 세션 prompt에 task 문서 경로와 *동일 방식*으로 이 절대 경로를 넘긴다 (메모리 아닌 파일 — 세션/컴팩트 무관 재사용).
+**검증 방법 출처 = `$MAIN_WT/.project/rules/TEST_RULE.local.md`** — 각 테스트 방식(데이터 조회 / API 호출 / E2E / 시각 실행)을 *이 프로젝트에서 실제로 어떻게 돌리나*가 적힌 단일 소스. 격리 세션 prompt에 task 문서 경로와 *동일 방식*으로 이 절대 경로를 넘긴다 (메모리 아닌 파일 — 세션/컴팩트 무관 재사용).
 
 ## 호출 시점
 
@@ -47,13 +47,13 @@ MAIN_WT=$(dirname "$(git rev-parse --path-format=absolute --git-common-dir)")
 
 ### Step 1 — task 파일 + Test Plan 추출
 
-1. `.project/AGENT-GUIDE.md` Read → 활성 plan 버전 확인.
+1. `status` 도구(또는 `npx @angar2/taskery status`)로 활성 plan 확인.
 2. task 파일 Read:
    - 인자 있음 → 해당 파일.
-   - 인자 없음 → `developed` 상태 가장 최근 task. 발견 시 confirm. 없으면 *"검증할 task 없음."* + 종료.
+   - 인자 없음 → `status` 도구(또는 `npx @angar2/taskery status`)의 *진행중 태스크* 목록에서 후보를 찾는다 — task 문서는 미등록 케이스에서 **각 task의 워크트리 안에만** 있으므로, 메인 워크트리에서 `ls .project/tasks/<NNN_slug>/`로 찾으면 아무것도 안 나와 *"task가 없다"*고 잘못 끝난다. 각 후보의 문서 경로는 `status`가 알려주는 워크트리 경로 아래 `.project/tasks/<NNN_slug>/`다. 그중 status=`developed`인 가장 최근 task. 발견 시 confirm. 진행중 목록 자체가 비어 있을 때만 *"검증할 task 없음."* + 종료.
 3. 상태 = `developed` 검증. `testing`이면 이어가기 (Step 2 skip). 그 외면 종료.
 4. `## Test Plan` 섹션 + `## Dev Plan`의 Phase별 *완료 기준* 정독. 자기완결성 점검 — 다른 문서 참조나 *"위에서 만든 X"* 같은 표현 있으면 사용자에게 보고 + Test Plan 보강 후 재시도.
-5. **프로젝트 로컬 룰 확인** — `$MAIN_WT/.project/rules/TEST_RULE.local.md`가 있으면 Read한다 (없으면 넘어간다). 검증 범위·방식에서 본 스킬 조항과 겹치면 **로컬 룰 우선**. 단 멀티세션 불변식·destructive 승인·상태 전이 유효성은 로컬이 뒤집지 못한다.
+5. **프로젝트 로컬 룰 확인** — `$MAIN_WT/.project/rules/TEST_RULE.local.md`를 Read한다. 이 파일은 모든 리포에 있어야 하는 필수 문서다(`TASKERY_RULE` §8) — **없으면 사용자에게 알리고** 이번 검증은 실행 경로를 지어내지 말고 진행한다(확인 불가한 시나리오는 실행 보류). 로컬 룰의 조항은 코어와 동등한 구속력을 가진다 — 겹치면 **로컬이 최우선**이고, **겹치지 않는 로컬 조항도 그대로 준수한다** (`TASKERY_RULE` §7). 단 멀티세션 불변식·destructive 승인·상태 전이 유효성은 로컬이 뒤집지 못한다.
 
 ### Step 2 — status 전환 (developed → testing)
 
@@ -71,20 +71,19 @@ Task tool로 sub-agent spawn. prompt는 *자기완결적* — task.md 경로 +
 ## 대상 task
 
 task 파일 경로: <ABSOLUTE_PATH_TO_TASK_MD>
-검증 방법 문서: <ABSOLUTE_PATH_TO_TEST_GUIDE_MD>
-프로젝트 검증 정책(있을 때만): <ABSOLUTE_PATH_TO_TEST_RULE_LOCAL_MD>
+이 프로젝트의 검증 규칙(있을 때만): <ABSOLUTE_PATH_TO_TEST_RULE_LOCAL_MD>
 
-task 파일을 직접 Read 해서 ## Test Plan 섹션 + ## Dev Plan의 Phase별 완료 기준을 정독하세요. 그리고 *검증 방법 문서(TEST-GUIDE.md)* 도 직접 Read — 각 테스트 방식을 *이 프로젝트에서 실제로 어떻게 실행하나*(DB 조회 경로 / API 호출법 / E2E 셋업 등)의 단일 소스입니다. 위에 경로로 명시된 문서(task 파일 · 검증 방법 문서 · 프로젝트 검증 정책) + 목업 외 다른 문서 참조 X.
+task 파일을 직접 Read 해서 ## Test Plan 섹션 + ## Dev Plan의 Phase별 완료 기준을 정독하세요. 위에 경로로 명시된 문서(task 파일 · 검증 규칙) + 목업 외 다른 문서 참조 X.
 (단 task.md가 `mockup/<task-doc-name>-mockup.html` 참조하면 해당 목업 파일도 직접 Read — *승인된 목업 = 시각 시나리오의 정답지*입니다. 시각 시나리오 = 실제 화면 캡처 → 이 목업과 자동 대조.)
-프로젝트 검증 정책 파일이 경로로 주어졌으면 그것도 Read한다 — 이 프로젝트 고유의 검증 범위·방식 규칙이며, 위 수행 룰과 겹치는 항목은 그쪽을 우선한다(멀티세션 불변식·안전 조항 제외).
+검증 규칙 파일(`TEST_RULE.local.md`)이 경로로 주어졌으면 반드시 Read한다 — 두 가지가 그 안에 있다. ① *방식별 실행 경로*: 각 테스트 방식을 이 프로젝트에서 실제로 어떻게 돌리나(DB 조회 경로 / API 호출법 / E2E 셋업 / 시각 실행 / 격리 실행 환경). ② *범위·방식 정책*: 무엇을 얼마나 검증하나. 위 수행 룰과 겹치는 항목은 그쪽을 우선하고, 겹치지 않는 조항도 그대로 준수한다(멀티세션 불변식·안전 조항 제외). 경로가 주어지지 않았으면 그 프로젝트에 아직 규칙이 없다는 뜻이므로, 실행 경로를 스스로 지어내지 말고 확인 불가한 시나리오는 실행 보류로 리턴한다.
 
 ## 수행 룰
 
 1. **본질 — Test Plan 시나리오 기반 실질 동작 검증**. 본 task에서 구현한 *요구사항이 정상 동작하는지* 검증이 목적. 단위 테스트 수치(카운트 +N / 모든 PASS) 자체로 task PASS 단정 절대 X — Test Plan에 명시된 *각 시나리오*가 PASS인지가 본질.
 2. ## Test Plan 시나리오를 *순서대로* 그대로 수행. 임의 추가 / 스킵 / 변형 금지. 각 시나리오의 `[AUTO]` / `[USER]` 분류 (task-plan에서 정의됨) 그대로 따름.
 3. `[AUTO]` 시나리오 — *실제 명령 실행*. 실행 없이 pass 처리 절대 금지. 검증 도구 (단위/통합/E2E 테스트 / API 호출 / 스크립트 실행 등) 직접 수행 + 결과 로그 확보.
-4. `[USER]` 시나리오 — *정답지가 주관*인 영역만 (시각 미세 취향 / 색조·여백 2px 수준 / UX 사용감·매끄러움). UNCERTAIN(사람 검수)으로 분류 + *사용자 직접 검수 항목*으로 리턴 (단 증거=캡처 첨부). **시각 *객관* 영역(레이아웃 깨짐 / 요소 빠짐 / 빈 화면 / 색 완전히 틀림 / 배치 딴판)은 `[USER]`가 아니라 `[AUTO]`** — 실제 화면 캡처 → 승인 목업과 직접 대조해 격리 세션이 판정. **단 이 승격은 TEST-GUIDE.md *시각 실행* 절에 이 프로젝트의 캡처 실행 경로가 있을 때 한정이다** — 경로가 없어 task.md가 시각 시나리오를 `[USER]`로 분류했다면 그 분류를 존중하고 `[AUTO]`로 뒤집지 않는다. (시각이라고 무조건 사람에게 넘기지 말 것 — 객관 깨짐은 네가 잡는다.)
-5. CLAUDE.md `## 검증 명령` (빌드/린트/타입체크) + `## 테스트 명령` (단위/통합/E2E 테스트) 둘 다 직접 실행 + 결과 리턴. **단 화면·입력을 점유하는 스위트는 룰 17의 제약을 먼저 따른다** (무단 실행 금지 — 룰 17이 본 룰보다 우선).
+4. `[USER]` 시나리오 — *정답지가 주관*인 영역만 (시각 미세 취향 / 색조·여백 2px 수준 / UX 사용감·매끄러움). UNCERTAIN(사람 검수)으로 분류 + *사용자 직접 검수 항목*으로 리턴 (단 증거=캡처 첨부). **시각 *객관* 영역(레이아웃 깨짐 / 요소 빠짐 / 빈 화면 / 색 완전히 틀림 / 배치 딴판)은 `[USER]`가 아니라 `[AUTO]`** — 실제 화면 캡처 → 승인 목업과 직접 대조해 격리 세션이 판정. **단 이 승격은 TEST_RULE.local.md *시각 실행* 절에 이 프로젝트의 캡처 실행 경로가 있을 때 한정이다** — 경로가 없어 task.md가 시각 시나리오를 `[USER]`로 분류했다면 그 분류를 존중하고 `[AUTO]`로 뒤집지 않는다. (시각이라고 무조건 사람에게 넘기지 말 것 — 객관 깨짐은 네가 잡는다.)
+5. `AGENTS.md` `## 검증 명령` (빌드/린트/타입체크) + `## 테스트 명령` (단위/통합/E2E 테스트) 둘 다 직접 실행 + 결과 리턴. **단 값이 `<예:` 로 시작하는 placeholder이거나 비어 있으면 실행하지 말고 *진입 문서 미기입*으로 표시해 리턴한다** (없는 명령을 지어내지 않는다). **단 화면·입력을 점유하는 스위트는 룰 17의 제약을 먼저 따른다** (무단 실행 금지 — 룰 17이 본 룰보다 우선).
 6. **신규 테스트 식별자 등장 확인 (stash FRICTION_LOG #19 반영)** — 본 task에서 신규 테스트 추가되었으면, 단순 *카운트 +N / 모든 PASS* 자체로 PASS 단정 X. 신규 *테스트 식별자* (suite / class / function / describe 등) 가 테스트 runner 결과 로그에 *실제 등장*했는지 grep 직접 확인 (1 hit 이상). 등장 안 하면 *Suite 미실행* → FAIL.
 7. 코드와 동작만 신뢰. *"잘 될 거야"* / *"문제 없을 듯"* 같은 가정 일체 금지.
 8. 코드 파일 직접 수정 절대 금지. 임시 파일(테스트 스크립트 등) 생성 시 종료 후 삭제.
@@ -96,12 +95,12 @@ task 파일을 직접 Read 해서 ## Test Plan 섹션 + ## Dev Plan의 Phase별
     - **UNCERTAIN(사람 검수)** — 정답지가 *주관*인 영역(룰 4: 시각 미세 취향 / UX 느낌). 정상. 사용자 직접 검수 항목으로 리턴 (증거 캡처 첨부).
     - **UNCERTAIN(검증 불가)** — `[AUTO]`로 분류됐는데 *대조할 기대값을 구성하지 못한* 경우 = **시험문제 결함**. PASS로 반올림 금지, 사람 검수로도 넘기지 말 것(주관 아님). **근거 의무**: *무엇을 시도했고 왜 기대값을 구성할 수 없는지* 반드시 기록. (이건 네가 쉴 자리가 아니라 task-plan으로 되돌아가 Test Plan을 보수해야 하는 신호 — 도망쳐도 이득 없음.)
     - **UNCERTAIN(실행 보류)** — 룰 17에 걸려 *실행하지 않은* 경우 = 시험문제도 코드도 아닌 **환경 제약**. 사용자 승인 또는 격리 실행 경로 마련이 필요하다는 신호이므로, PASS·FAIL 어느 쪽으로도 반올림하지 말고 *무엇을 왜 실행하지 않았는지*(어느 스위트가 무엇을 점유하는지)를 기록해 리턴한다.
-14. **시각 `[AUTO]` 시나리오 = 캡처-목업 대조**. 앱을 띄워 실제 화면을 캡처 → 승인된 목업(정답지)과 대조. (본 룰은 TEST-GUIDE에 캡처 실행 경로가 있는 경우에만 적용된다. 경로가 없으면 해당 시나리오는 `[USER]`이며 룰 4 단서에 따른다.) 어긋나면 → *구체적 어긋남 목록*(예: "헤더 색 틀림 / 카드가 가로 아닌 세로로 쌓임 / 저장 버튼 없음")을 뽑아 **FAIL**로 보고. 합격선 = *픽셀 일치가 아니라* "사람이 보면 '이거네' 할 정도로 본질적으로 같다" (객관적 깨짐만 잡고 미세 취향은 룰 4로). 증거 = 스크린샷 + 어긋남 목록.
+14. **시각 `[AUTO]` 시나리오 = 캡처-목업 대조**. 앱을 띄워 실제 화면을 캡처 → 승인된 목업(정답지)과 대조. (본 룰은 TEST_RULE.local.md에 캡처 실행 경로가 있는 경우에만 적용된다. 경로가 없으면 해당 시나리오는 `[USER]`이며 룰 4 단서에 따른다.) 어긋나면 → *구체적 어긋남 목록*(예: "헤더 색 틀림 / 카드가 가로 아닌 세로로 쌓임 / 저장 버튼 없음")을 뽑아 **FAIL**로 보고. 합격선 = *픽셀 일치가 아니라* "사람이 보면 '이거네' 할 정도로 본질적으로 같다" (객관적 깨짐만 잡고 미세 취향은 룰 4로). 증거 = 스크린샷 + 어긋남 목록.
 
 15. **픽스처 현실성 의심 + 재생성 판정**. 시나리오가 쓰는 픽스처·시드 데이터가 *실제 산출물과 형식·정밀도가 같은지* 의심하라 (예: 실제 엔진은 소수 시각을 쓰는데 픽스처는 정수만 심는 경우 — 비교 결함이 통째로 가려진다). 의심되면 **실제 코드(writer·생성기)로 픽스처를 재생성해 시나리오를 재실행하고, 그 결과로 판정**한다. 재생성 경로가 없어 대조를 구성할 수 없으면 그 시나리오는 *시험문제 결함(검증 불가)*으로 분류한다. 손으로 심은 픽스처는 구현자의 맹점을 그대로 복제하므로, 통과했다는 사실만으로 안전하다고 보지 않는다.
 16. **어서션 정면성**. 각 시나리오의 기대값이 요구사항을 *정면으로* 겨누는지 확인하라. "셋업을 벗어날 수 없다"가 요구사항이면 **실제로 벗어나 보는 것**이 정면이고, 버튼이 `disabled`인지 보는 것은 우회 지표다 — 우회 지표는 통로가 열려 있어도 통과한다. 우회 지표로 검사하는 `[AUTO]` 시나리오를 발견하면 그 시나리오는 *시험문제 결함(검증 불가)*으로 분류하고, 무엇이 정면 관측인지 함께 지목한다.
 
-17. **화면·입력 점유 스위트 자동 실행 금지**. 실제 앱을 띄워 UI를 자동 조작하는 스위트(XCUITest·headed 브라우저 E2E 등)는 사용자의 화면·마우스·키보드를 점유해 작업을 중단시킨다. TEST-GUIDE.md *테스트 실행 환경* 절에 **격리 실행 경로**(창 숨김·헤드리스 플래그 / 컨테이너·가상 디스플레이 / VM / CI 러너)가 선언돼 있으면 그 경로로 실행한다. 선언이 없으면 — 비점유 부분만 한정 실행할 수 있으면 그것만 실행하고, 한정 수단도 없으면 **실행하지 말고** 해당 시나리오를 *실행 보류(사용자 승인 필요)*로 표시해 메인에 리턴한다 (무단 실행 금지). 헤드리스 모드가 있으면 항상 그쪽을 쓴다.
+17. **화면·입력 점유 스위트 자동 실행 금지**. 실제 앱을 띄워 UI를 자동 조작하는 스위트(XCUITest·headed 브라우저 E2E 등)는 사용자의 화면·마우스·키보드를 점유해 작업을 중단시킨다. TEST_RULE.local.md *테스트 실행 환경* 절에 **격리 실행 경로**(창 숨김·헤드리스 플래그 / 컨테이너·가상 디스플레이 / VM / CI 러너)가 선언돼 있으면 그 경로로 실행한다. 선언이 없으면 — 비점유 부분만 한정 실행할 수 있으면 그것만 실행하고, 한정 수단도 없으면 **실행하지 말고** 해당 시나리오를 *실행 보류(사용자 승인 필요)*로 표시해 메인에 리턴한다 (무단 실행 금지). 헤드리스 모드가 있으면 항상 그쪽을 쓴다.
 
 ## 결과 형식 (이 포맷 그대로 리턴)
 
@@ -144,7 +143,7 @@ task 파일을 직접 Read 해서 ## Test Plan 섹션 + ## Dev Plan의 Phase별
 
 ### 실행 보류 (UNCERTAIN 실행 보류 — 해당 시)
 - <어느 시나리오/명령을 실행하지 않았나 + 무엇을 점유하는가(화면·마우스·키보드·전역 단축키 등) + 비점유 부분만 실행했다면 그 범위>
-  → 메인이 사용자 승인을 받아 실행하거나, TEST-GUIDE *테스트 실행 환경* 절에 격리 실행 경로를 마련한 뒤 재검증 필요.
+  → 메인이 사용자 승인을 받아 실행하거나, TEST_RULE.local.md *테스트 실행 환경* 절에 격리 실행 경로를 마련한 뒤 재검증 필요.
 
 ## 종료 조건
 
@@ -153,8 +152,7 @@ task 파일을 직접 Read 해서 ## Test Plan 섹션 + ## Dev Plan의 Phase별
 
 **구현 디테일**:
 - `<ABSOLUTE_PATH_TO_TASK_MD>` 자리에 `.project/tasks/<NNN_slug>/<NNN>_<slug>.md` (또는 폴더 승격 시 `<...>/task.md`)의 절대 경로 삽입.
-- `<ABSOLUTE_PATH_TO_TEST_GUIDE_MD>` 자리에 `$MAIN_WT/.project/TEST-GUIDE.md`의 절대 경로 삽입 (위 "멀티세션 메타 위치"의 `MAIN_WT` 사용 — 워크트리에서 호출돼도 메인 워크트리의 단일 소스를 읽도록).
-- `<ABSOLUTE_PATH_TO_TEST_RULE_LOCAL_MD>` 자리에 `$MAIN_WT/.project/rules/TEST_RULE.local.md`의 절대 경로 삽입. **파일이 없으면 그 줄 자체를 prompt에서 제외**한다 (없는 경로를 넘기면 격리 세션이 헤맨다).
+- `<ABSOLUTE_PATH_TO_TEST_RULE_LOCAL_MD>` 자리에 `$MAIN_WT/.project/rules/TEST_RULE.local.md`의 절대 경로 삽입 (위 "멀티세션 메타 위치"의 `MAIN_WT` 사용 — 워크트리에서 호출돼도 메인 워크트리의 단일 소스를 읽도록). **파일이 없으면 그 줄 자체를 prompt에서 제외**한다 (없는 경로를 넘기면 격리 세션이 헤맨다). 0.7.0 이전 리포라 파일이 없고 구형 `$MAIN_WT/.project/TEST-GUIDE.md`가 남아 있으면 **그 경로를 대신 넘기고**, 메인은 사용자에게 `TEST_RULE.local.md`로의 이행을 1회 제안한다.
 - Task tool의 `subagent_type`: `general-purpose` (도구 풀 다 필요).
 - Task tool의 `description`: `Isolated test for TASK-<NNN>`.
 - **코덱스 spawn (플랫폼 패리티)**: 코덱스에선 `.codex/agents/task-tester.toml`의 `task-tester` 서브에이전트로 spawn하되, *위 펜스 전체를 task prompt로 그대로 전달*한다 — 펜스가 양 플랫폼 공통 단일 룰 소스다(클로드 = `general-purpose` + 펜스 / 코덱스 = `task-tester` + 펜스, 동일 효과). `task-tester`의 `developer_instructions`는 같은 룰의 코덱스 기준선 미러 — 본 펜스의 수행 룰을 바꾸면 그 `developer_instructions`도 함께 갱신한다.
@@ -248,7 +246,7 @@ task 파일을 직접 Read 해서 ## Test Plan 섹션 + ## Dev Plan의 Phase별
 3. 사용자 응답별 처리:
    - **"지금 돌려"** → 승인받았으므로 점유 스위트를 실행하고, 그 결과로 PASS / FAIL 분기를 따른다.
    - **"나중에"** → 보류 유지. status는 `testing` 그대로 두고 **여기서 멈춘다** (`/task-close`로 넘어가지 않는다 — close는 `tested`가 아니면 `blocked:'status'`로 차단된다). 사용자가 자리를 비운 뒤 *"이제 돌려"* 하면 위 "지금 돌려"로 재개.
-   - **"격리 경로 만들자"** → 경로(창 숨김·헤드리스 / 컨테이너 / VM / CI)를 마련하고 `TEST-GUIDE.md` *테스트 실행 환경* 절에 기록한 뒤 `/task-test` 재실행. 다음 task부터는 승인 없이 자동 실행된다.
+   - **"격리 경로 만들자"** → 경로(창 숨김·헤드리스 / 컨테이너 / VM / CI)를 마련하고 `TEST_RULE.local.md` *테스트 실행 환경* 절에 기록한 뒤 `/task-test` 재실행. 다음 task부터는 승인 없이 자동 실행된다.
    - **"보류인 채로 마무리해"** (알려진 미검증 감수) → FAIL 분기의 *"OK 마무리"*와 동일 처리 — `set_status` 도구로 `tested` 전이(또는 `npx @angar2/taskery set-status TASK-<NNN> tested`) + Result 섹션에 *"미검증 영역: <보류 시나리오> — 사유: 화면·입력 점유, 사용자 판단으로 미실행"* 명시 후 `/task-close` 안내.
 4. **묵묵히 PASS 처리 금지** — 어느 경로로 가든 보류된 시나리오는 Result에 *미검증 영역*으로 남긴다. 실행하지 않은 것을 통과로 적지 않는다.
 
@@ -290,7 +288,7 @@ USER 검수 — N 항목 (목업 기준: <mockup path — 있을 시>)
 
 ### Step 7 — 검수 서버 기동 (PASS 후 세션 종료·해당 시)
 
-**조건**: ① 종합 판정 PASS + 이번 세션이 여기서 멈추고 사용자에게 제어를 넘김(= `/task-close`로 바로 진행하지 않음) + ② `CLAUDE.md`(코덱스 `AGENTS.md`)에 `## 검수 실행 명령`이 선언됨.
+**조건**: ① 종합 판정 PASS + 이번 세션이 여기서 멈추고 사용자에게 제어를 넘김(= `/task-close`로 바로 진행하지 않음) + ② `AGENTS.md`에 `## 검수 실행 명령`이 선언됨.
 
 - 두 조건 충족 시 — 그 명령으로 서버를 *백그라운드* 기동(포트 = 기준 포트 + TASK번호) + 접속 URL 보고. 모바일 검수가 필요하다고 판단되면 터널도 기동.
 - 격리 세션 검증이 *기능상* 이미 서버를 띄워 둔 경우 — 죽였다 다시 띄우지 말고 그대로 두고 URL만 보고.

package/template/.project/FRICTION_LOG.md

@@ -1,16 +0,0 @@
-# FRICTION_LOG
-
-> 사용자가 작업 흐름 중 겪은 불편 / 한계 / 짚이는 부분의 누적.
-> `/log-friction` 스킬이 사용자 합의 후 한 행씩 추가한다.
-
-**사용 규칙**:
-- 한 행에 한 불편
-- 손수 편집 X — 메인이 대화로 적음
-- 사용자 명시 호출 / 사용자 불만 발화 캐치 / task-close 직후 마찰 신호 자체 감지 시 추가
-
----
-
-## 불편 누적
-
-| 날짜 | 불편 | 맥락 (어느 task / 스킬 / 카테고리) |
-|------|------|-----------------------------------|

package/template/.project/TEST-GUIDE.md

@@ -1,62 +0,0 @@
-# TEST-GUIDE
-
-> 이 프로젝트에서 각 테스트 방식을 *실제로 어떻게 실행하나*의 단일 소스.
-> **제품 관통 문서 아님 — 검증 방법 문서.** (제품 스펙은 `.project/` 루트 그룹 A/B 문서 참조.)
-> `/task-test` 격리 세션이 task.md와 함께 이 파일을 읽어, 명세된 방식을 *이 프로젝트의 실제 경로*로 실행한다.
-> **역할 구분**: 본 문서 = *어떻게 실행하나*(경로·명령·셋업). `.project/rules/TEST_RULE.local.md` = *무엇을 얼마나 검증하나*(범위·방식 정책, 옵션·로컬 전용). 둘을 섞어 적으면 어느 쪽에도 안 남는다.
-
-**사용 규칙**:
-- 처음엔 빈 골격 — 검증 방법을 아직 모름. `/task-plan`이 방식별 실행 경로를 *사용자에게 확인받은 즉시* 채운다.
-- 각 항목 = "이 프로젝트에서의 실제 실행 방법" (명령 · 경로 · 연결). 추상 설명 아니라 *그대로 돌릴 수 있는* 형태.
-- 모르면 비워 두지 말고 `/task-plan`이 사용자에게 물어 채운다 (모르면 묻고, 알면 재사용).
-- 부정확이 드러나면 정정. 손수 편집보다 task 진행 중 갱신 권장.
-
----
-
-## 데이터 검증 (DB / 파일 / 상태 조회)
-
-> 시나리오 실행 후 데이터 상태를 *직접 조회*하는 실제 경로. (예: ORM repository / DB 클라이언트 / 쿼리 명령 / 파일 확인 명령.)
-
-<아직 미정 — 데이터 쓰기·변경·삭제 검증이 필요한 task에서 `/task-plan`이 사용자에게 확인 후 기록>
-
----
-
-## API 호출 (엔드포인트 / 외부 인터페이스)
-
-> 엔드포인트를 실제로 호출하고 상태코드·응답 필드를 확인하는 경로. (예: curl / httpie / 테스트 클라이언트 + 베이스 URL · 인증 방법.)
-
-<아직 미정>
-
----
-
-## UI 동작 · E2E (클릭 / 입력 / 흐름 자동화)
-
-> UI 동작·흐름을 자동화하는 도구와 셋업. (예: Playwright / Cypress 설치 여부 · 실행 명령 · 셋업 단계.) 도구가 없으면 "없음 — 사람 검수"로 명시.
-
-<아직 미정>
-
----
-
-## 시각 실행 (앱 기동 + 화면 캡처)
-
-> 앱을 띄워 실제 화면을 캡처해 승인 목업과 대조하는 경로. (예: 개발 서버 실행 명령 · 포트 · 캡처 방법.) 검수 서버는 `CLAUDE.md`(코덱스 `AGENTS.md`)의 `## 검수 실행 명령` 참조.
-
-<아직 미정>
-
----
-
-## 테스트 실행 환경 (격리 실행 경로 — 화면·입력 점유 회피)
-
-> 실제 앱을 띄워 UI를 자동 조작하는 스위트(XCUITest · headed 브라우저 E2E 등)를 **사용자의 화면·마우스·키보드를 뺏지 않고** 돌리는 경로. 여기에 경로가 적혀 있으면 자동 게이트·격리 세션이 그 경로로 자동 실행하고, 비어 있으면 자동 실행하지 않고 사용자 승인을 받는다 (`/task-dev` Step 6.5 · `/task-test` 격리 룰).
->
-> 적을 수 있는 것: 창 숨김·헤드리스 플래그(예: 테스트 모드 환경변수로 창 표시·포커스 탈취 비활성) / 가상 디스플레이·컨테이너 / VM / CI 러너 위임 / 점유 스위트를 제외하는 한정 실행 옵션(번들·프로젝트·태그 지정).
-
-<아직 미정 — 점유 스위트가 있는 프로젝트에서 `/task-dev`·`/task-test`가 사용자에게 확인 후 기록>
-
----
-
-## 기타
-
-> 위 분류에 안 맞는 프로젝트 고유 검증 방법.
-
-<아직 미정>