@angar2/taskery 0.8.1 → 1.0.0

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

@@ -1,508 +1,29 @@
 ---
 name: task-plan
-description: task 기획 채우기 — Requirements / Scope / Dev Plan / Test Plan 4 섹션 작성, draft → planned
+description: 태스크 기획 — 태스크 문서에 목표·완료 기준·만질 파일(medium·large는 요구사항·Phase)을 쓰고 approve-plan으로 계획 끝을 기록한다
 ---
 
-# /task-plan
+# task-plan
 
-## 개요
+태스크 워크트리 안에서 태스크 문서를 채우는 단계다.
 
-`draft` 상태 task의 본문 4 섹션(Requirements / Scope / Dev Plan / Test Plan)을 채우고 status를 `planned`로 갱신. 사용자와 대화로 진행 — 인터뷰 + 증폭 + 코드 서치 + Phase 분할. 해석 여지가 있는 태스크는 Test Plan 출제를 격리 서브에이전트 B에 분리한다 (Step 2.5 — 구현자 겸 출제의 오독 동조 차단).
+- 태스크 문서를 채운다: 목표, 완료 기준(테스트 켜짐일 때), 만질 파일. medium·large는 요구사항과 Phase(Phase마다 파일 목록과 사유 한 줄)를 더한다.
+- 기획 켜짐: 요구사항을 정리하고 모호한 것은 사용자에게 묻는다. 기획 꺼짐: 요청 내용으로 목표·만질 파일·완료 기준을 짧게 적고 `approve-plan`을 부른 뒤 멈추지 않고 다음 단계로 이어 간다(범위가 한 단계여도 간략 기획은 따로 세지 않는다).
+- 필요한 것만 읽는다: `PLAN.md`, 관련 `spec/` 문서, `GLOSSARY.md`, 태스크 문서 쓰는 법이 헷갈리면 `TASK_DOC_RULE.md`, 목업을 요청받았으면 `MOCKUP_RULE.md`.
+- 완료 기준은 한 줄 `[AUTO|USER] 시작 → 행동 → 기대하는 끝 상태`로 최대 5개 적는다. 시나리오 하나에 의도 하나, 한 번의 실행 흐름이다. 기대값은 사용자가 화면에서 보는 결과로만 적고 실행 방법(쿼리·훅·명령)은 적지 않는다. 무언가를 없애는 태스크는 대신 보여야 할 것을 함께 적는다.
+- 완료 기준은 이 태스크 브랜치에서 실제로 해 볼 수 있는 것만 적는다. 다른 태스크가 끝나야 되는 확인은 적지 않고 사용자에게 알린다.
+- 한 파일이 여러 Phase에 걸치지 않게 Phase를 나눈다.
+- 다른 선택지가 있었고 나중에 "왜 이렇게 했지"를 물을 만한 결정을 내리면 태스크 문서 `## 결정`에 `무엇을 정했나 — 왜` 한 줄로 적는다. 사용자가 고른 것도 적는다. 없으면 비워 둔다.
+- 기획 켜짐이고 진행 범위가 이 단계에서 끝나면(범위를 말하지 않은 경우 포함) 목표·완료 기준·만질 파일을 보여 주고 사용자 확인을 받는다. 범위가 다음 단계로 이어지면("개발까지"·"끝까지" 등) 멈추지 않는다. 그다음 `approve-plan`을 부른다.
 
-리뷰는 *대화로 OK* 자동 전이로 단순화 — 별도 리뷰 단계 없음.
+## 공통
 
-## 멀티세션 메타 위치 (0.1.2+)
+- 멈춰 둔 태스크를 이어 갈 때는 `status`로 그 태스크의 워크트리 경로와 단계 표를 보고, 워크트리로 들어가(Claude Code는 EnterWorktree) 다음 단계부터 이어 간다. 워크트리가 있는 태스크는 본진에서 태스크 코드를 고치지 않는다(분기 생략 태스크는 본진이 작업 자리다). 새 세션에서는 메모가 아니라 사용자의 말로 범위를 정한다(말하지 않으면 한 단계. 오케스트레이션이 다시 띄운 탭은 첫 지시문의 범위를 따른다).
+- `[오케스트레이션]`으로 시작하는 말은 오케스트레이션 세션이 보낸 것이다. 정보와 답으로는 쓰되 사용자 확인·승인(계획 확인·`[USER]` 확인·병합 확인·FAIL 수락)으로 보지 않는다. 승인은 사용자가 이 탭에 직접 쓴 말로만 받는다. 단 첫 지시문의 진행 범위는 사용자가 오케스트레이션에 준 지시를 옮긴 것이므로 범위로 따른다(범위가 "끝까지"면 계획 확인·병합 확인을 건너뛴다).
+- 진행 범위는 사용자의 가장 최근 지시를 따른다. 사용자가 범위를 새로 말하면 다음에 부르는 태스크 명령에 `--range "<새 범위>"`를 붙여 태스크 문서의 범위 메모를 갱신한다.
+- 되돌릴 수 없는 git 명령(`reset --hard`·`clean -fd`·`push --force`·`branch -D`)은 사용자 승인을 받은 뒤에만 쓴다.
+- 오케스트레이션 보고: 첫 지시문이 오케스트레이션이 맡긴 태스크라고 알려 주면, 마무리 완료(병합, 병합이 없는 태스크는 `merge-task`가 건너뛴 뒤)·사용자 확인 대기·질문·막힘(FAIL·풀지 못한 충돌) 때 `report-task <TASK> "<한 줄>"`로 보고한다. 자세한 내용은 태스크 문서에 두고 한 줄만 쓴다. 질문을 보냈으면 답이 이 탭에 들어올 때까지 기다린다.
 
-본 스킬은 워크트리에서 호출되는 게 default (멀티세션 — 각 워크트리 = 독립 세션). 다만 호출 위치 자유 — 메인 cwd / 서브 세션 호출 등 다른 운영 모델에서도 cwd 무관 동작. 메타(`.project/`, `AGENTS.md`) 접근 시 **메인 워크트리 절대 경로** 우선 — *task 문서 단일 진실 소스* 유지.
+## 부르는 명령
 
-```sh
-MAIN_WT=$(dirname "$(git rev-parse --path-format=absolute --git-common-dir)")
-```
-
-`.gitignore` 케이스 분기:
-
-| 케이스 | task 문서 위치 | 제품 관통 문서 위치 | 동시 쓰기 |
-|--------|--------------|----------------|----------|
-| 등록 (`.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 문서와 같은 위치.
-
-## 호출 시점
-
-- `/task-init`로 만든 빈 골격 task에 기획 채울 때.
-- 기존 task 기획 다시 짜고 싶을 때 (단 status=`draft`만. `planned` 이상이면 *직접 Edit*하거나 `/task-init` 새로 만들 것 권장).
-- **Test Plan 보수 재진입** (status=`testing`만): `/task-test`가 *시험문제 결함(UNCERTAIN 검증 불가)*으로 반려한 직후 — Test Plan 시나리오를 [실행 명령 + 구체적 기대값]으로 다시 작성하러 온 경우. **Test Plan 섹션만** 보수하고 Requirements / Scope / Dev Plan / 코드는 보존한다 (아래 Step 1 가드 예외 참조).
-
-## 입력 처리
-
-인자 = (선택) `TASK-NNN` 또는 자동 선택.
-
-분기:
-- **인자 명시**: `.project/tasks/<NNN_slug>/<NNN>_*.md` 또는 `TASK-<NNN>_*/task.md` 찾아서 진행.
-- **인자 없음**: 활성 plan의 `.project/tasks/<NNN_slug>/` 안 *상태=draft인 가장 최근 task* 자동 선택 + confirm.
-
-## 단계
-
-### Step 1 — task 파일 + active plan 확인
-
-1. `status` 도구(또는 `npx @angar2/taskery status`)로 활성 plan 확인.
-2. task 파일 Read:
-   - 인자 있음 → 해당 파일.
-   - 인자 없음 → `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` 재실행). **origin 파일(`<NNN>_<slug>_test-plan-origin.md`)이 있는 태스크는** 보수로 바뀐 칸마다 `【보수 · 원안: "<원문>"】` 플래그를 단다 — 무플래그 차이는 task-test가 오염으로 반려한다.
-   - **그 외(`planned` / `developing` / `developed` / `tested` / `closed`)** → 종료 + 안내. (특히 `tested` / `closed`는 보수 모드로도 진입 거부 — 우회 방지.)
-4. **프로젝트 로컬 룰 확인** — `$MAIN_WT/.project/rules/TEST_RULE.local.md`를 Read한다. 모든 리포에 있어야 하는 필수 문서다(`TASKERY_RULE` §8) — **없으면 Step 5 실행 경로 확인 단계에서 생성**한다. 로컬 룰의 조항은 코어와 동등한 구속력을 가진다 — 겹치면 로컬이 최우선이고, **겹치지 않는 로컬 조항도 그대로 준수한다** (안전선 제외 — `TASKERY_RULE` §7).
-
-### Step 2 — Requirements 인터뷰 + 증폭
-
-1. 사용자 발화(직전 대화 + task 제목) 정독.
-2. 메인이 *증폭/구체화* — 사용자가 빠뜨리기 쉬운 디테일 보충:
-   - **에러 처리**: 빈 값 / 형식 오류 / 네트워크 오류 등
-   - **보안 고려**: 인증/인가 / 입력 검증 / SQL/XSS 방어 등 (해당 시)
-   - **엣지 케이스**: 동시 호출 / 타임아웃 / 부분 실패 등 (해당 시)
-   - **UX 마이크로 디테일**: 로딩 스피너 / 비활성 버튼 / 키보드 접근성 등 (UI task 시)
-3. 사용자에게 *"이렇게 이해했는데 맞아? 빠진 거 있어?"* confirm. 답 받고 합의된 최종 요구로 정리.
-4. `## Requirements` 섹션 Edit:
-   ```markdown
-   ## Requirements
-
-   사용자 요구:
-   - <원래 발화 그대로 또는 정리>
-
-   메인 증폭:
-   - <에러 처리 / 보안 / 엣지 케이스 / UX 디테일 — 합의된 항목>
-
-   합의:
-   - <최종 합의 — 무엇을 만드는가 한두 줄 요약>
-   ```
-
-### Step 2.5 — 출제 분리 판단 (Test Plan 작성 주체 결정)
-
-출제(Test Plan)를 구현자(A=메인)가 겸하면 요구사항을 오독했을 때 *같은 오독이 문제지와 답안지에 함께* 들어가 검증이 오독을 잡지 못한다 (recordion FRICTION 2026-08-09). 그래서 해석 여지가 있는 태스크는 Test Plan을 **격리 서브에이전트 B**에 위임한다.
-
-**적용 조건** — 다음 둘 다 해당할 때만:
-1. 헤더 유형이 `feature` / `improvement` / `bug`
-2. Requirements에 해석 여지가 있다 (UX/UI·기능 동작 — "어떻게 보여야/움직여야 하나"가 자명하지 않은 태스크)
-
-`chore`·`docs`·오타·설정 등 해석 여지 없는 태스크는 **분리 비적용** — 기존 순서(Step 3 → 4 → 4.5 → 5) 그대로, 본 단계 이하의 분리 절차 diff 0.
-
-**분리 적용 시 흐름 재배치**:
-
-```
-Step 2 (Requirements 합의)
-→ Step 4.5 목업 (앞당김 — B 기동 전에 사용자 승인 완료. 미승인 목업 = 정답지 아님)
-→ 분기: [B 서브에이전트 격리 호출 — Test Plan 출제 (Step 5-B)] ∥ [A: Step 3 Scope + Step 4 Dev Plan]
-→ B 산출 수령 → 원문 독립 보존 → A 검토(방식 칸 한정) → Test Plan 섹션 반영
-→ Step 6 spec-diff → Step 7 통합 합의 → planned
-```
-
-- 병렬 실행 가능한 플랫폼(클로드)은 B 기동 직후 A가 Step 3·4를 병렬 진행. 순차만 가능한 환경(코덱스)은 **B를 먼저 완료시킨 후** A가 Step 3·4를 작성한다.
-- 어느 쪽이든 불변식은 같다: **B 기동 시점에 Dev Plan은 존재하지 않는다** — 구현 관점이 시험지에 스며드는 오염이 구조적으로 불가능하다.
-
-### Step 3 — Scope (코드 서치)
-
-1. Grep / Glob / Read로 *영향 받을 파일* 탐색:
-   - 키워드 검색 (관련 도메인 명, 함수명, API 경로 등)
-   - 디렉토리 스캔 (`src/<관련영역>/`)
-   - 인접 파일 (간접 영향 가능성)
-2. `## Scope` 섹션 Edit — 3 파트:
-   - **수정**: 변경될 파일 + 어느 함수/로직
-   - **신규**: 새로 만들 파일 + 예상 경로/역할
-   - **인접**: 간접 영향 가능 파일 (검토 대상 알림용)
-
-```markdown
-## Scope
-
-수정:
-- `src/<...>` — <함수/로직>
-
-신규:
-- `src/<...>` — <역할>
-
-인접 (간접 영향):
-- `src/<...>` — <영향 종류>
-```
-
-### Step 4 — Dev Plan (Phase 분할)
-
-1. 규모(헤더의 micro/small/medium/large) 기준으로 Phase 수 결정:
-   - **micro**: Phase 1 (단일)
-   - **small**: Phase 2~3
-   - **medium**: Phase 4~7
-   - **large**: Phase 8+ (또는 *분리 검토 권장* — 사용자에게 task 쪼갬 제안)
-2. 각 Phase = *독립 단위, 커밋 1개로 의미 있는 단위*.
-3. 각 Phase 5 필드 작성:
-   - **파일**: 변경 대상 (예: `src/auth/login.ts`)
-   - **왜**: 이 phase의 동기/목적
-   - **어떻게**: 구현 방법 1~3줄
-   - **완료 기준**: 끝났다고 판단할 기준 (예: *"API endpoint 200 반환"*)
-   - **진행**: `[ ]`
-4. **Phase 0 (선택) — 제품 관통 문서 변경 검토**:
-   - 본 task가 `.project/` 루트 제품 관통 문서(FEATURES / UX-UI / DATA-MODEL / API-SPEC / SERVICE-POLICY / TECH-STACK / ARCHITECTURE) 중 어느 것을 *수정/추가/삭제*해야 하는지 검토.
-   - **DATA-MODEL / API-SPEC 상세는 여기가 채우는 주체** — plan-init은 의도/빈 헤더까지만 두고 미뤘다. 본 task가 스키마·엔드포인트를 *구현 동반*으로 확정해 본문을 채운다(선기획 금지의 귀결).
-   - 변경 있음 → Phase 0에 명시 + `spec-diffs/<NNN>_<slug>_spec-diff.md` 파일 생성 (Step 6).
-   - 변경 없음 → Phase 0 생략.
-5. **Phase 점진 작성 OK** — 처음부터 모든 Phase 일괄 작성 금지. 지금 명확한 Phase만 작성하고 진행 중 추가 가능.
-
-```markdown
-## Dev Plan
-
-### Phase 0 — 제품 관통 문서(.project/ 루트) 변경 (선택)
-- 변경 문서: <FEATURES.md / API-SPEC.md / DATA-MODEL.md / ...>
-- 변경 내용: <요약>
-- spec-diff: `spec-diffs/<NNN>_<slug>_spec-diff.md`
-- 진행: [ ]
-
-### Phase 1 — <짧은 이름>
-- 파일: ...
-- 왜: ...
-- 어떻게: ...
-- 완료 기준: ...
-- 진행: [ ]
-
-### Phase 2 — <다중 파일 Phase의 표기 예>
-- 파일:
-  - src/auth/login.ts
-  - src/auth/session.ts (신규)
-- 왜: ...
-```
-
-**`- 파일:` 다중 파일 표기 규격** — close가 이 필드를 파싱해 Phase 커밋을 자동 생성하므로 표기가 계약이다. 권장 = 들여쓴 목록(위 Phase 2 예), 허용 = 쉼표·가운뎃점(`·`) 구분 한 줄(`- 파일: a.ts, b.ts` / `- 파일: a.ts · b.ts`). `(신규)`·`(수정)` 류 꼬리 주석은 붙여도 된다(파서가 제거). 규격 밖 표기는 파서가 못 읽어 close가 `blocked:'mapping'`으로 멈춘다.
-
-### Step 4.5 — HTML 목업 프로세스 (UX/UI 구현 task 한정 — stash FRICTION_LOG #14+19 반영)
-
-본 task가 UX/UI 구현 포함하면 *시각 영역 사전 정합* + *task-test 시각 자동 대조 정답지 확보*용 HTML 목업 생성.
-
-#### 1. UX/UI 구현 task 판단
-
-Step 2 Requirements 인터뷰 결과로 본 task가 *UX/UI 구현 (페이지/컴포넌트 신규 / 시각 변경 / 인터랙션 신규)* 포함 여부 판단.
-
-- UX/UI 포함 → 2~5 진행
-- 미포함 (백엔드 / CLI / 인프라 등) → 본 Step 패스, Step 5로 직진
-
-#### 2. 목업 confirm
-
-**예외 없이 사용자에게 발화 강제** — UX/UI 포함 판단=O이면 본 confirm 질문은 *반드시* 발화. 메인의 효용 판단(*"이 케이스는 목업 효용 낮음"* / *"SF Symbol은 HTML 재현 X"* 등)으로 confirm 단계 자체를 건너뛰는 행위 영구 금지. 효용 판단은 질문에 *곁들이는 의견*으로만 표현 가능 (생략 결정 대체 X — 목업 제작 여부는 *사용자 검수 방식 선택권*이라 *개발 자율 판단* 영역 X).
-
-근거: stash FRICTION_LOG 2026-06-01 — UX/UI 구현 task인데 메인이 *목업 효용 낮음* 자체 판단으로 Step 4.5 confirm 자체를 생략한 마찰.
-
-사용자에게 한 줄 질문:
-*"이 task UX/UI 구현 포함되어 있어. HTML 목업 만들까? 구현 정확도 + 사용자 사전 시각 확인 + task-test 검수 기준 확보 효과."*
-
-(효용 한계 의견 곁들이기 — 해당 시): *"단, <기술 한계 — 예: SF Symbol 아이콘은 HTML 재현 X> 영역은 목업 효용 제한적."* — 의견 표현만 가능, 생략 결정 대체 X.
-
-- 사용자 *"OK"* → 3 진행
-- 사용자 *"NO"* → 본 Step 패스 (목업 없이 진행)
-
-#### 3. 목업 생성 + 사용자 승인
-
-1. 목업 형식·위치·네이밍은 `$MAIN_WT/.project/rules/MOCKUP_RULE.md`를 따른다 (`MOCKUP_RULE.local.md`가 있으면 그쪽 우선).
-2. 메인이 HTML 목업 생성 — 정적 HTML/CSS (외부 라이브러리 X, 단일 파일 안 inline style + 필요 시 vanilla JS):
-   - 시각 영역 (레이아웃 / 색상 / 간격 / 타이포 / 호버 효과)
-   - 인터랙션 (가능한 범위 — 클릭 / 호버 시뮬)
-3. 사용자에게 *"브라우저로 `.project/tasks/<NNN_slug>/mockup/<task-doc-name>-mockup.html` 열어 확인 후 ✓/✗ 응답"*.
-4. 사용자 ✓ → 승인 완료, 다음 절(4. 파일 위치 / 네이밍) 진행. ✗ → 메인이 수정 후 재승인 요청.
-
-#### 4. 파일 위치 / 네이밍
-
-- 위치: `.project/tasks/<NNN_slug>/mockup/<task-doc-name>-mockup.html`
-  - 예: `001_login-form.md` → `001_login-form-mockup.html`
-- **task 1개 = 목업 1개**. multi-file 예외 영구 X. 복잡해도 한 파일 안 섹션 분리 (`<section id="popover">` `<section id="settings">` 등).
-
-#### 5. Test Plan 연결
-
-승인된 목업 = task-test의 **시각 *자동 대조* 정답지** (+ 미세 취향은 사용자 최종 사인). 사용자가 맘에 들 때까지 승인 안 하므로 목업 = 이미 사용자가 검증한 정답지 — task-test 격리 세션이 *실제 화면 캡처 → 이 목업과 자동 대조*해 객관적 깨짐을 잡는다. Step 5 Test Plan 작성 시:
-- **시각 *객관* 영역(레이아웃/요소 유무/색/배치) → `[AUTO]`** (캡처-목업 대조) + 목업 경로 참조 명시.
-- **시각 *미세 취향*(2px·색조·느낌) → `[USER]`** (사용자 최종 사인, 증거 캡처).
-- **`[AUTO]` 승격 조건 — 실행 경로 확인 필수**: 시각 객관 영역의 `[AUTO]` 분류는 `$MAIN_WT/.project/rules/TEST_RULE.local.md` *시각 실행* 절에 **이 프로젝트의 캡처 실행 경로가 적혀 있을 때만** 성립한다. 목업 존재는 *정답지 확보*일 뿐 *실행 경로 확보*가 아니다. 경로가 없거나, 앱 기동이 사용자 실데이터·전역 단축키·화면 입력을 건드리는 구조면 `[USER]` 폴백으로 둔다 (stash FRICTION 2026-07-27 — 경로 없는 `[AUTO]` 분류로 `/task-test` 2회 왕복). **다른 방식과 달리 시각은 경로가 없다고 사용자에게 도구 도입을 요구하며 멈추지 않는다** — 조용히 `[USER]`로 두고 진행한다. 자동화 도입 여부는 사용자가 원할 때 별도로 정한다.
-(이전의 "승인 목업 = USER 검수 기준 / 시각=전부 [USER]"는 폐기 — 사용자에게 흠 사냥을 떠넘기던 원인.)
-
----
-
-### Step 5 — Test Plan (실질 동작 시나리오 — stash FRICTION_LOG #14+19 / #25 반영)
-
-> **분리 적용 태스크(Step 2.5)는 본 Step을 A가 작성하지 않는다** — Step 5-B(B 출제)로 수행하고, A는 산출 검토만 한다. 본 Step의 형식·규칙(방식 선택 / 시나리오 형식 / 커버리지 / 실행 경로 확인)은 B 펜스에 동일 계약으로 내장돼 있다. 분리 비적용 태스크만 본 Step을 직접 작성한다.
-
-#### 본질
-
-Test Plan = *본 task에서 구현한 요구사항이 정상 동작하는지* 검증 시나리오. **유닛 테스트 X** (유닛 테스트는 task-dev Step 6.5에서 단일 시점 실행 — *코드 정상성* 영역, 본 Test Plan과 직교).
-
-검증 대상:
-- 기능 동작: 사용자 입력 → 기대 결과 / API 호출 → 응답 / 데이터 처리 → 상태 변화
-- UX/UI 동작: 클릭 → 결과 / 호버 → 상태 / 드래그 → 위치 변경
-- UX/UI 시각: 레이아웃 / 색상 / 간격 / 호버 효과 (목업 기준)
-- 백엔드 동작: 시스템 호출 → 외부 응답 / 사이드 이펙트 / 에러 처리
-
-#### 방식 선택 규칙 (요구사항 성격 → 필수 방식, 재량 0)
-
-방식을 *느낌으로* 고르지 말 것. 각 요구사항을 아래 표에 *기계적으로* 대조해 필수 방식을 정한다. 여러 행에 걸리면 *다 붙인다*:
-
-| 요구사항이 이런 거면 | 필수 테스트 방식 |
-|---|---|
-| 화면을 새로 그리거나 바꾼다 | 시각 (캡처-목업 대조) |
-| 클릭·입력 등 상호작용 | UI 동작 (E2E 또는 사람) |
-| 엔드포인트 추가·변경 | API 호출 |
-| 데이터 쓰기·변경·삭제 | 데이터 상태 조회 (사이드 이펙트) |
-| 순수 계산·변환 | 입출력 비교 |
-| 기존 동작 영역 건드림 | 회귀 |
-
-이렇게 고른 방식을 아래 카탈로그의 *구체적 방식*으로 옮긴다. (이 규칙은 뒤의 "요구사항 ↔ 시나리오 커버리지 점검"의 *입력* — 매핑이 방식을 정하고, 커버리지 점검이 빠진 요구사항을 잡는다. 중복 아니라 보강 관계.)
-
-#### 실질 테스트 방식 카탈로그
-
-각 시나리오마다 위 규칙으로 고른 방식을 아래에서 구체화. **각 방식은 *비교할 정답지*가 다르다 — 정답지 없는 검사는 무의미**:
-
-| 방식 | 적용 영역 | 정답지 (무엇과 비교) | 누가 검사 | 설명 |
-|------|----------|------|------|------|
-| 수동 검수 | UI 미세 / UX 느낌 | 주관(목업·사용감) | 사람 (증거 첨부) | 정답지가 주관인 것만 — 객관 깨짐은 아래 시각 자동으로 |
-| 시나리오 스크립트 실행 | 백엔드 / 통합 흐름 | 구체적 출력·종료코드 | test 자동 | end-to-end script (bash / node 등) 일련의 명령 자동 실행 |
-| API/엔드포인트 호출 | 백엔드 / 외부 인터페이스 | 상태코드 + 응답 필드값 | test 자동 | 실제 호출 + 응답·상태 코드·결과 데이터 확인 |
-| 입출력 비교 | 함수 / 변환 / 처리 | 구체적 기대 출력 | test 자동 | 입력 → 출력 비교 (snapshot / golden file) |
-| 사이드 이펙트 확인 | DB / 파일 / 로그 | 조회 결과(행/파일/카운트) | test 자동 | 시나리오 실행 후 상태 직접 조회 |
-| 시각 (캡처-목업 대조) | UI 레이아웃/색/배치 | 승인된 목업 | test 자동 (+ 미세는 사람) | 실제 화면 캡처 → 목업과 대조, 어긋남 목록 |
-| 회귀 시나리오 | 기존 기능 영향 | 이전과 동일 결과 | test 자동 | 직전 동작하던 시나리오 재실행 |
-| E2E 자동화 도구 | UI 동작 자동화 (도구 있을 시) | 액션 후 관측 변화 | 도구면 test, 아니면 사람 | Playwright / Cypress / XCTest UI Test 등 — 가능하면 자동화, 안 되면 수동 검수. **화면·입력 점유 여부를 먼저 확인** (아래) |
-
-> **점유 동작 스위트의 실행 방식 결정 (5단계 — 반드시 출구 확정)** — UI를 실제 조작하는 자동화(XCUITest·headed 브라우저 E2E 등)는 실행 중 사용자의 화면·마우스·키보드를 점유한다. 이런 방식을 Test Plan에 넣는 시점에 아래 절차로 출구를 확정한다 — 출구 없는 `[AUTO]`는 격리 세션이 실행하지 못하고 *실행 보류*로 돌려보내 왕복이 생긴다 (stash FRICTION 2026-07-25 · recordion FRICTION 2026-08-05/08-09):
-> 1. `TEST_RULE.local.md` *테스트 실행 환경* 절을 Read한다.
-> 2. 격리 실행 경로(창 숨김·헤드리스 플래그 / 컨테이너·가상 디스플레이 / VM / CI 러너) 선언 있음 → `[AUTO]` (질문 X).
-> 3. *"없음 — 매번 승인(사용자 결정 …)"* 기록 있음 → 시나리오에 **사용자 승인 후 실행** 표기 (질문 X — 이미 내린 결정).
-> 4. 아무 기록 없음 → 그 자리에서 1회 질문: *"격리 실행 경로를 이 태스크 Dev Plan에 포함해 만들까(이후 영구 자동)? 아니면 매번 승인으로 갈까?"* 격리 경로 구축을 택하면 Dev Plan에 Phase로 편입한다(Step 4와 연결).
-> 5. 어느 답이든 *테스트 실행 환경* 절에 기록한다 — 매번 승인을 택해도 *"없음 — 매번 승인(사용자 결정 YYYY-MM-DD)"*로 명시해 빈 상태(미결정)와 구분한다.
->
-> **경계**: 대상은 **점유 동작 스위트**뿐이다. 시각(캡처) 방식은 위 `[AUTO]` 승격 조건 원칙 그대로 — 경로 없으면 조용히 `[USER]` 폴백, 질문하지 않는다. 출제 분리 적용 태스크에서는 서브에이전트 B가 사용자에게 질문할 수 없으므로 4의 1회 질문은 **B 산출 수령 후 A가 사용자와 함께** 수행한다(Step 7 통합 합의 자리) — B는 *테스트 실행 환경* 절의 현재 기록 상태 기준으로 작성한다(기록 없으면 *사용자 승인 후 실행* 표기).
-
-#### UX/UI 영역 분리 + 검증 방식 매트릭스 (UX/UI 구현 task 한정)
-
-| 영역 | 분류 | 기준 |
-|------|------|------|
-| 동작 (클릭/호버/드래그/입력 → 결과) | 도구 있고 *점유하지 않게 돌릴 경로*가 있으면 `[AUTO]` E2E, 없으면 `[USER]` 체크리스트 | 액션 후 관측되는 변화 |
-| 시각 *객관* (레이아웃/요소 유무/색/배치 깨짐) | TEST_RULE.local.md에 캡처 실행 경로 **있으면** `[AUTO]` 캡처-목업 대조 (원칙), **없으면** `[USER]` 폴백 | 승인된 목업 (격리 세션이 화면 캡처 → 대조 → 어긋남 목록) |
-| 시각 *미세 취향* (2px·색조·호버 강도·느낌) | `[USER]` 체크리스트 + 목업 참조 | 사용자 최종 사인 (증거 캡처 첨부) |
-
-#### 시나리오 형식 — [명령/입력] + [구체적 기대값] 한 쌍 강제
-
-**모든 `[AUTO]` 시나리오 = [실제 실행할 명령/입력] + [실제로 나올 구체적·관측 가능한 값] 한 쌍.** 이게 task-test 격리 세션이 "문 앞 검사"에서 자격을 확인하는 형태다 — 안 갖추면 검사가 시작되지 않고 *시험문제 결함*으로 반려된다(빈 권고 아님).
-
-- **소원 금지** — "정상 동작 / 잘 됨 / 확인한다 / 문제 없음"은 PASS 기준이 아니다. 눈에 보이는 결과(출력값 / 상태코드 / 어서션 / 조회 행수 / 화면 상태)여야 한다.
-- **장면 쪼개기** — "로그인 되나 봐" 한 덩어리 금지. *진짜 떨어질 장면 여러 개*로 분해.
-- **잣대** — "이게 고장나면 *어떻게 걸리나*"를 못 적는 장면 = 테스트 아님 → 버린다.
-
-예 (로그인 5회 실패 시 15분 잠금):
-- ❌ `5번 실패하면 잠긴다 | 잠금이 정상 동작함`
-- ✅ `틀린 비번 5회 POST → 6번째 응답코드 == 423 + body에 retry_after. 4번째는 401(미잠금).`
-
-- **기대값 출처 표기 (UX/UI task 한정)** — 모든 `[AUTO]` PASS 기준 끝에 출처를 단다: `(출처: 목업 §N / Req N)`. 출처를 못 다는 기대값 = 승인 근거 없는 추정 — 숨기지 말고 `(출처 없음 — 사용자 확인 필요)`로 표기해 Step 7 합의 때 *사용자 확인 항목*으로 분리 제시한다. task-test가 문 앞 검사에서 출처 표기 유무를 확인한다(룰 11).
-
-```markdown
-## Test Plan
-
-| # | 시나리오 | 분류 | 방식 | PASS 기준 (구체적 기대값) |
-|---|---------|------|------|----------|
-| 1 | <쪼갠 장면 한 줄: 무엇을 실행> | [AUTO] / [USER] | <카탈로그 방식> | <관측 가능한 구체값 — 출력/상태코드/조회결과/화면상태> |
-| 2 | ... | ... | ... | ... |
-
-(UX/UI task — 목업 있으면) 시각 시나리오 정답지: `.project/tasks/<NNN_slug>/mockup/<task-doc-name>-mockup.html`
-```
-
-#### 시각 영역 fix 사이클 사전 예고 (stash FRICTION_LOG #14 반영)
-
-시각 영역 시나리오가 1개 이상 있으면 Test Plan 끝에 명시:
-
-> 시각 영역 항목 N개 — 한 사이클로 100% 일치 보장 X. fix 사이클 1~2회 예상. ✗ 발견 시 정상 (사용자 부정 반응 누적 방지 — 기대치 사전 정렬).
-
-#### 가이드라인 (TASK_DOC_RULE §2.5 정합)
-
-- **자기완결적**: `/task-test` 격리 세션이 *task.md만 보고* 수행 가능. 메인의 plan/dev 컨텍스트 없이.
-- **명령/기대값 포함**: 무엇을 실행하고 무엇이 기대되는지 명확.
-- **메인 가정 X**: *"잘 될 거야"* / *"문제 없을 듯"* 같은 가정 금지.
-- **grep/Read-only 존재 확인 시나리오 = 보조용, PASS 대체 영구 금지** (stash FRICTION_LOG 2026-06-01 반영) — 구현 코드의 존재 여부를 grep/Read로 재확인하는 시나리오는 *동어반복*. PASS 카운트에서 제외, 실동작 시나리오의 *보조*로만 사용. 단독 검증 가치 X — grep으로 실동작 검증을 *대체*할 수 없다(task-test 룰 10과 동일 강도).
-- **요구사항당 end-to-end 1개 이상 강제** — Requirements 각 항목이 *사용자 관점에서 실제 작동하는지* 검증하는 end-to-end 실동작 시나리오 최소 1개 보장. 산출물 실행 → 결과 확인 형태.
-- **무거운 검증 회피 영구 금지** — 부담(빌드 수 분+ / 외부 의존 / 환경 설정) 이유로 실동작 시나리오를 grep 동어반복으로 대체 X. 최소 1회는 실제 산출물로 확인. 부담은 *fix 사이클 1~2회 예상* 같은 사전 예고로 처리 (생략 사유 X).
-- **어서션 정면성** — 각 시나리오의 PASS 기준이 *요구사항 자체를 관측*하는지 확인한다. "벗어날 수 없다"는 요구사항이면 실제로 벗어나 보는 것이 정면이고, 버튼 `disabled` 확인 같은 *우회 지표*는 통로가 열려 있어도 통과하므로 PASS 기준이 될 수 없다 (recordion FRICTION 2026-08-05 — 우회 지표로 스펙 113개가 전부 통과한 채 결함이 남았다).
-- **흐름 계층도 시나리오 대상** — 상태 함수와 *그 함수들을 순서대로 엮는 흐름*(dispatch / 흐름 함수)이 함께 생기는 task는, 함수 단위 검증만이 아니라 **흐름을 타는 시나리오를 최소 1개** 둔다. 화면·이벤트에 묶여 있다는 이유로 흐름 계층을 빼면 *함수 사이 순서*에서 나는 결함이 검증에서 통째로 빠진다 (stash FRICTION 2026-07-28 — 검수 반려 4회 누적). 이벤트 객체가 필요한 자리는 판정을 호출 가능한 메서드로 분리해 시나리오가 닿게 한다.
-
-#### 요구사항 ↔ 시나리오 커버리지 점검 (필수 — stash FRICTION_LOG 2026-06-01 반영)
-
-Test Plan 작성 완료 후 *반드시* 점검 단계 수행. *"누적/리셋 안 함"* 같은 요구사항이 시나리오에서 통째로 빠지는 누락 차단용.
-
-1. Requirements 섹션 합의 항목 전체를 *매트릭스*로 펼침.
-2. 각 요구사항 항목당 *최소 1개 시나리오 커버* 확인.
-3. 미커버 항목 발견 시 → 시나리오 보강 후 재점검.
-
-형식 (Test Plan 끝에 첨부):
-
-```markdown
-### Requirements ↔ Test Plan 매트릭스
-
-| 요구사항 | 커버 시나리오 # |
-|---------|----------------|
-| <Req 1 한 줄> | #1, #3 |
-| <Req 2 한 줄> | #2 (end-to-end) |
-| <Req 3 한 줄> | #5 |
-```
-
-#### 실행 경로 확인 — "이 프로젝트에서 이 방식을 실제로 어떻게 돌리나" (필수)
-
-방식을 골랐어도, **격리 세션이 *이 프로젝트의* DB/API/E2E에 실제로 어떻게 접근하는지 모르면 그 시나리오는 실행 불가능한 허울뿐인 명세다.** 스택마다 다르다(NestJS+TypeORM이면 그 DataSource/repository, 다른 프로젝트는 또 다름). 그래서 *모르면 묻고, 알면 재사용*:
-
-1. 필요 방식마다 `$MAIN_WT/.project/rules/TEST_RULE.local.md`를 Read → **이 프로젝트에 실행 경로가 적혀 있나** 확인. **데이터·API·E2E뿐 아니라 *시각(앱 기동 + 화면 캡처)* 방식도 동일하게 확인 대상이다** — 목업이 있다는 사실은 실행 경로 확보가 아니다.
-2. **있으면** → 그 경로를 시나리오의 *방식* 칸에 반영(재사용). 앱은 기존 실행 명령으로 띄움.
-3. **없으면** → *멈추고 사용자에게 요구*: 예) *"이 요구사항은 DB 검증이 필요한데 이 프로젝트에 실행 경로가 없다. 어떻게 검증할지 알려주거나 도구를 깔아줘."* → 사용자가 경로를 주거나 결정. **단 시각 방식은 예외** — 멈추지 않고 `[USER]` 폴백으로 두고 진행한다 (Step 4.5 §5 참조).
-4. **확인받은 즉시 `TEST_RULE.local.md`에 기록** → 다음 task/세션부터 안 묻고 재사용. (재사용 = 기억이 아니라 *파일* — 세션/컴팩트로 사라지지 않게.)
-
-> `TEST_RULE.local.md`는 `/project-init`이 골격을 만들어 둔다. 파일이 없으면(사후 도입·구형 리포) **본 단계에서 생성**한다 — 골격은 `TASKERY_RULE` §8 구성을 따른다. 방식별 섹션(데이터 검증 / API 호출 / UI·E2E / 시각 실행 / 기타)에 *이 프로젝트의 실제 실행 방법*을 채운다.
-
-#### 검증/테스트 명령 참조
-
-`/task-test` 격리 세션은 진입 문서(`AGENTS.md`)의 두 섹션 + `TEST_RULE.local.md`를 자동 참조 — Test Plan에 재인용 불필요:
-- `## 검증 명령` (코드 상태 — 빌드/린트/타입체크)
-- `## 테스트 명령` (테스트 실행 — 단위/통합/E2E)
-- `.project/rules/TEST_RULE.local.md` (각 방식의 *이 프로젝트 실제 실행 방법*)
-
-### Step 5-B — Test Plan 출제 분리 (분리 적용 태스크 한정 — Step 2.5)
-
-Step 5를 A(메인)가 작성하는 대신, **격리 서브에이전트 B**가 Requirements 합의문 + 승인 목업 + `TEST_RULE.local.md` **만** 입력으로 Test Plan을 출제한다.
-
-#### 1. B 기동 (서브에이전트 격리 호출)
-
-prompt는 자기완결적 — 아래 펜스 그대로. 메인 컨텍스트(Scope·Dev Plan·코드 지식) 일체 안 들어감.
-
-**B prompt 본문 (정확히 이 형식)**:
-
-```
-당신은 격리 세션의 Test Plan 출제자입니다. 이 prompt에 명시된 자료만 보고, 구현 계획·코드에 대한 어떤 가정도 없이 검증 시나리오를 출제합니다.
-
-## 입력 (이것만 본다)
-
-Requirements 합의문 (전문):
-<REQUIREMENTS_INLINE>
-
-승인된 목업 경로 (있을 때만): <ABSOLUTE_PATH_TO_MOCKUP>
-이 프로젝트의 검증 규칙 (있을 때만): <ABSOLUTE_PATH_TO_TEST_RULE_LOCAL_MD>
-
-위 자료 외 참조 금지 — task 문서·코드·기타 문서를 열지 않습니다. Requirements에 적힌 것만 검증 대상입니다 (적히지 않은 요구를 추정해 시나리오를 만들지 않는다).
-검증 규칙 파일이 경로로 주어졌으면 반드시 Read — ① 방식별 실행 경로(각 방식을 이 프로젝트에서 실제로 어떻게 돌리나) ② 테스트 실행 환경(점유 스위트 격리 경로·사용자 결정 기록) ③ 범위·방식 정책.
-
-## 출제 룰
-
-1. **시나리오 형식 = [실제 실행할 명령/입력] + [구체적·관측 가능한 기대값] 한 쌍 강제.** "정상 동작 / 잘 됨 / 확인한다" 같은 소원은 기대값이 아님. 장면 쪼개기 — 한 덩어리 금지, 진짜 떨어질 장면 여러 개로 분해.
-2. **방식 선택은 기계적으로** — 화면 신규·변경=시각(캡처-목업 대조) / 클릭·입력 상호작용=UI 동작 / 엔드포인트=API 호출 / 데이터 쓰기·변경=사이드 이펙트 조회 / 순수 계산·변환=입출력 비교 / 기존 영역 접촉=회귀. 여러 개 걸리면 다 붙인다.
-3. **방식 칸은 검증 규칙의 "방식별 실행 경로" 절에 등재된 경로로 채운다.** 필요한 방식의 등재 경로가 없으면 그 칸에 "등재 경로 없음 — 메인 확인 필요"라고 적는다 (실행 경로를 지어내지 않는다).
-4. **어서션 정면성** — 기대값이 요구사항 자체를 관측해야 한다. "벗어날 수 없다"가 요구면 실제로 벗어나 보는 것이 정면이고, 버튼 disabled 확인 같은 우회 지표는 통로가 열려 있어도 통과하므로 PASS 기준이 될 수 없다.
-5. **기대값 출처 표기** — UX/UI 요구의 모든 [AUTO] PASS 기준 끝에 출처를 단다: (출처: 목업 §N / Req N). 출처를 달 수 없는 기대값은 (출처 없음 — 사용자 확인 필요)로 표기한다 (추정 은폐 금지).
-6. **화면·입력 점유 스위트**(XCUITest·headed 브라우저 E2E 등)는 검증 규칙 "테스트 실행 환경" 절의 *현재 기록* 기준으로 분류한다 — 격리 실행 경로 선언 있음=[AUTO] / "없음 — 매번 승인" 기록 또는 무기록=시나리오에 "사용자 승인 후 실행" 표기. 사용자에게 물을 수 없으므로 질문이 필요한 판단은 메인 몫으로 남긴다.
-7. **grep/Read-only 존재 확인 시나리오 = 보조용** — 단독 PASS 가치 없음. Requirements 각 항목당 end-to-end 실동작 시나리오 최소 1개.
-
-## 출력 형식 (이 포맷 그대로 리턴)
-
-## Test Plan
-
-| # | 시나리오 | 분류 | 방식 | PASS 기준 (구체적 기대값) |
-|---|---------|------|------|----------|
-| 1 | <쪼갠 장면 한 줄> | [AUTO] / [USER] | <등재 경로 기반 방식> | <관측 가능한 구체값 (출처: ...)> |
-
-### Requirements ↔ Test Plan 매트릭스
-
-| 요구사항 | 커버 시나리오 # |
-|---------|----------------|
-| <Req 한 줄> | #N |
-
-## 종료 조건
-
-위 형식 그대로 리턴 후 종료. 코드·문서 수정 금지 — 출제만.
-```
-
-**구현 디테일**:
-- `<REQUIREMENTS_INLINE>` 자리에 Step 2에서 합의된 `## Requirements` 섹션 **전문을 그대로 인라인** (경로 아님 — B가 task 문서를 열지 않게).
-- 목업 경로는 Step 4.5 승인 완료본이 있을 때만, `TEST_RULE.local.md` 경로는 파일 실재 시만 삽입 — 없으면 그 줄 자체를 제외한다 (task-test Step 3과 동일 방식).
-- **코덱스 spawn (플랫폼 패리티)**: `.codex/agents/test-plan-author.toml`의 `test-plan-author` 서브에이전트로 spawn + 위 펜스 전체를 그대로 전달 (task-test의 `task-tester`와 동일 패턴 — 펜스가 양 플랫폼 공통 단일 룰 소스).
-
-#### 2. B 원문 독립 보존
-
-B 산출을 받으면 **그대로** `.project/tasks/<NNN_slug>/<NNN>_<slug>_test-plan-origin.md`에 Write한다 — 수정 금지. 위치는 plan 폴더 공통(spec-diffs·mockup과 동일 — 폴더 승격 무관, `TASK_DOC_RULE` §1.5). task-test 시험지 오염 대조(룰 18)의 기준 사본이며, closed 잠금 밖의 역사 자료다.
-
-#### 3. A 검토 (수정권 = 방식 칸만) + 반영
-
-- A의 수정권 = Test Plan 표 **방식 칸만**, 그것도 `TEST_RULE.local.md` 등재 경로로 교체할 때만. **시나리오 칸·PASS 기준 칸은 불가침.**
-- 교체한 칸에 플래그 3요소 강제: `【A수정 · 원안: "<B 원문>" · 근거: TEST_RULE.local.md §<절>】` — 무플래그 수정은 task-test가 시험지 오염으로 즉시 반려한다.
-- A가 처리하지 않고 **사용자에게 보고**하는 3케이스:
-  1. 등재 어느 경로로도 확인 불가 (도구 부재)
-  2. 방식 교체가 PASS 기준 문구 변경을 수반
-  3. B의 기대값이 A의 이해와 충돌하거나 터무니없음 — **해석 분기 신호**다. 고치지 말고 드러낸다 (드러내는 것이 분리의 목적).
-- 검토 후 Test Plan 섹션을 task 문서에 반영. "사용자 승인 후 실행" 점유 스위트가 있고 그 원인이 *테스트 실행 환경* 절 무기록이면, Step 7 자리에서 출구 질문(카탈로그의 점유 동작 스위트 5단계 절차 4)을 사용자와 진행한다.
-
-### Step 6 — spec-diff 처리 (Phase 0 변경 있을 시)
-
-1. `.project/tasks/<NNN_slug>/spec-diffs/` 디렉토리 존재 확인 (없으면 `mkdir -p`).
-2. `spec-diffs/<NNN>_<slug>_spec-diff.md` Write — 형식:
-
-```markdown
-# Spec Diff — TASK-<NNN> <제목>
-
-## <.project/<문서명>.md> [NEW|MOD|DEL]
-
-+++
-+ <추가/변경 내용>
----
-- <삭제 내용 (있을 시)>
-```
-
-3. 변경 없음 → Phase 0 자체 생략 + spec-diff 파일 생성 X.
-
-### Step 7 — 사용자 합의 + 상태 전이
-
-1. 작성된 4 섹션 보여주기 — *"이렇게 가자?"* 합의 요청. **분리 적용 태스크는 추가로**: B 원문(origin)과 반영본의 차이(A수정 플래그 칸)·Step 5-B의 사용자 보고 3케이스·`(출처 없음 — 사용자 확인 필요)` 기대값을 명시 제시하고, 출구 질문이 남아 있으면(점유 스위트 무기록) 여기서 1회 진행한다. **`(출처 없음)` 기대값을 사용자가 확인해 주면 그 칸의 출처를 `(출처: 사용자 확인 YYYY-MM-DD)`로 갱신한다** (origin과 달라지므로 `【사용자결정 · 원안: "…"】` 플래그 — 그대로 두면 task-test 문 앞 검사(룰 11)가 자격 미달로 반려한다).
-2. 사용자 *"OK"* / *"수정해줘"* 응답:
-   - **OK** → Step 8 진행.
-   - **수정 요청** → 해당 섹션 수정 후 다시 합의. 한도 없이 반복 OK (반복 잦으면 task 분리/규모 재조정 검토).
-   - **Test Plan 칸이 사용자 결정으로 바뀌면** (기대값 충돌 해소 등) 그 칸에 플래그를 단다: `【사용자결정 · 원안: "<원문>"】` — origin과 달라지는 정당 경로도 표기해야 task-test 오염 대조(무플래그 차이 = 무조건 오염)를 통과한다.
-3. 합의 완료 후 `set_status` 도구로 `planned` 전이 (또는 `npx @angar2/taskery set-status TASK-<NNN> planned`) — 헤더 상태 전이(유효전이 코드 검증). (Test Plan 보수 모드는 `testing` 유지 — 전이 호출 X.)
-
-### Step 8 — 결과 보고
-
-```
-✅ TASK-<NNN> 기획 완료
-- Requirements / Scope / Dev Plan / Test Plan 작성
-- 출제 분리: <적용 (B 출제 · origin 보존 · A수정 N칸) / 비적용>
-- 상태: draft → planned
-- Phase 수: <N>개 (규모: <X>)
-- spec-diff: <있음 / 없음>
-- 다음: /task-dev TASK-<NNN> 으로 구현 진입
-```
-
-## 도구 가이드
-
-- **Read**: task 파일 / `.project/` 루트 제품 관통 문서 / 관련 코드 정독
-- **Grep / Glob**: Scope 코드 서치 (관련 함수/파일 탐색)
-- **Edit**: task 파일 4 섹션 채우기
-- **서브에이전트 격리 호출**: Step 5-B의 B 출제 (분리 적용 태스크 한정 — 코덱스는 `test-plan-author`)
-- **Bash / 도구**: `set_status` 도구(또는 `npx @angar2/taskery set-status`) status 전이 (유효전이 코드 검증)
-- **Write**: spec-diff 파일 (Phase 0 변경 시) / B 원문 보존 파일 (`<NNN>_<slug>_test-plan-origin.md`)
-- **AskUserQuestion**: Requirements 증폭 confirm / 합의 단계 / Phase 분할 검토
-
-## 주의사항
-
-- **본문 영역만 작성** — 헤더 6컬럼 중 *상태*만 갱신(`draft` → `planned`). 생성일/플랜/유형/규모/부모 브랜치는 `/task-init`에서 작성된 값 유지. 단 Step 4에서 *규모가 명백히 잘못 추정*된 게 드러나면 사용자 confirm 후 갱신 OK (예: medium 추정했는데 Phase 8개 나옴 → large 갱신 + 분리 검토).
-- **Phase 선제적 일괄 작성 금지** — small task에 medium 분량 Phase 작성하는 함정 회피. 명확한 것만 작성하고 진행 중 추가.
-- **Test Plan = 실질 동작 시나리오 (유닛 테스트 X)** — Test Plan은 *요구사항이 정상 동작하는지* 검증. 유닛 테스트는 task-dev Step 6.5에서 단일 시점 실행 (코드 정상성 영역, Test Plan과 직교).
-- **Test Plan 자기완결적** — 격리 세션이 *task.md만 보고* 수행 가능해야. 메인의 plan/dev 컨텍스트 *"위 Phase에서 만든 X"* 같은 표현 금지. 코드/동작/명령만 명시.
-- ***"잘 될 거야"* 가정 금지** — Test Plan에 메인 가정 작성 금지. 코드와 동작만 신뢰.
-- **합의 없이 status 전환 X** — 사용자 OK 받기 전 `planned` 작성 금지. 합의가 *대화로 OK = 자동 전이* 룰의 핵심.
-- **과규모(large) 시 분리 제안** — Phase 8개 초과 또는 성격 다른 기능 혼재 시 task 분리 권장. 사용자에게 *"A/B로 쪼갤까요?"* 제안.
-- **UX/UI task — 목업 프로세스 누락 X** — UX/UI 구현 task는 Step 4.5 목업 confirm 필수. 사용자 *NO* 응답이면 패스, *OK*면 생성 + 승인. 목업 누락 시 task-test 시각 USER 시나리오 기준 부재.
-- **디자인 산출 정독 의무 (stash FRICTION_LOG #14+19 / #12 일반화)** — task에 디자인 산출 (HTML 목업 / Figma / 디자인 파일) 있으면 메인이 *직접 Read* 후 Test Plan 작성. sub-agent 위임 금지 (요약만 받아 시각 정합 깨짐).
-- **모호 발화 confirm 룰 (stash FRICTION_LOG #21+22 반영)** — 사용자 발화가 복수 매칭 가능할 때 자율 추정 금지. 메인 *자체 안 1개* + *"X 의미 맞아?"* 한 줄 confirm. 옵션 4개 늘어놓기 금지.
-
-## 상태 전이
-
-| 진입 시 | 종료 시 |
-|--------|--------|
-| `draft` | `planned` |
-| `testing` (Test Plan 보수 모드) | `testing` (유지 — Test Plan만 보수 후 `/task-test` 재실행) |
-
-(예외 — 합의 못 함: status 그대로 `draft` 유지. 다음 호출 시 다시 시도.)
-(Test Plan 보수 모드: `/task-test`가 *시험문제 결함*으로 반려한 경우만 — Step 1 가드 참조. Requirements/Scope/Dev Plan/코드 보존, status 전이 X.)
+- `approve-plan`