@angar2/taskery 0.8.0 → 1.0.0

package/template/.project/rules/GIT_RULE.md

@@ -1,325 +0,0 @@
-# GIT_RULE
-
-> 이 파일은 taskery 시스템 권장 프로젝트별 git 정책이다.
-> 우선순위: **이 파일** (`.project/rules/GIT_RULE.md`) → 글로벌 (`~/.claude/rules/GIT_RULE.md`) → 메인 판단.
-> 프로젝트별 변형이 필요하면 `.project/rules/GIT_RULE.local.md` 생성 (npx update 미터치, 구속력은 코어와 동등 — `TASKERY_RULE` §7).
-
----
-
-## 기본 원칙
-
-- **git 작업은 메인 세션이 `/task-close` 스킬 또는 직접 수행**.
-- **main, dev 직접 커밋 절대 금지**: 모든 작업은 태스크 브랜치에서 진행.
-- **하나의 브랜치는 하나의 태스크만 담당**.
-- **작업 브랜치는 *task-init 시점의 현재 브랜치*(= 부모 브랜치)에서 분기, *task-close 시점에* 그 부모 브랜치로 병합** (멀티세션 0.1.2+ / 부모 파라미터화 0.6.0+). 부모는 `dev` 고정이 아니라 서 있는 브랜치 — 개인 기본 `dev`, 회사/로드맵 `dev_feat_x`/`master` 등. task 헤더에 기록돼 close가 그 값으로 되병합한다.
-- **부모 → 상위(dev/voyager/master 등) 병합은 사용자가 직접 수행** (로컬 또는 PR). taskery는 부모까지만 병합.
-- **수동 git 작업 시 정합성 보장 X** — taskery 명령(스킬 호출 / `npx @angar2/taskery <서브>`)으로만 운영. 수동 `git worktree add` / `branch` / `merge` 시 SSoT·락·자동 정리 흐름이 깨질 수 있음.
-
----
-
-## 브랜치 구조
-
-| 브랜치 | 용도 |
-|--------|------|
-| `main` | 프로덕션 |
-| `dev` | 통합 개발 — 개인 기본 부모 브랜치 (메인 워크트리는 *현재 부모 브랜치* 고정, dev는 그 기본값) |
-| `{타입}/{개발자}_TASK-NNN_{출처}_{슬러그}` | 태스크 작업 브랜치 (멀티세션 시스템 단일 식별자) |
-
-### 브랜치 타입
-
-| 타입 | 태스크 유형 |
-|------|-----------|
-| `feature` | feature |
-| `bug` | bug |
-| `improve` | improvement |
-| `refactor` | refactor |
-| `docs` | docs |
-| `chore` | chore |
-
-### 개발자 식별자
-
-고정 목록이 아니며 실제 작업자 이름을 사용한다.
-
-| 작업자 | 식별자 |
-|--------|--------|
-| 사용자 | `angar2` |
-| Claude | `claude` |
-| 기타 AI | 해당 AI 이름 (예: `gpt`, `gemini`) |
-
-### 출처 (Source — 멀티세션 0.1.2+)
-
-| 출처 | 의미 | 채번 주체 |
-|------|------|---------|
-| `BL-NNN` | 백로그 항목 | `/add-backlog` 스킬 (0.1.2). plan(기능 그룹)별 `.project/tasks/<NNN_slug>/BACKLOG.md`에 누적 |
-| `ST-N` | 로드맵 Stage | 별도 채번 없음 — ROADMAP의 Stage 번호 그대로 (`ST-2` = Stage 2). Stage 하나에서 복수 task 정상(동일 출처 중복 게이트 미적용). 구형 `RM-NNN`은 호환 수용만 |
-| `DR` | 직접 요구사항 (별도 ID 없음) | 사용자 발화 → `/task-init` |
-
-### 브랜치 예시
-
-```
-feature/claude_TASK-007_BL-003_login-feature
-bug/angar2_TASK-012_DR_mobile-form-refresh
-refactor/claude_TASK-018_ST-2_api-cleanup
-docs/claude_TASK-021_DR_readme-rewrite
-```
-
-### 케이스 2 — TASK 없는 작업 브랜치 (시스템 밖)
-
-`TASK-NNN` 없는 작업 브랜치(`feature/claude_simple-config-fix` 등)는 *taskery 멀티세션 시스템 밖*에서 진행되는 단순/긴급 작업. SSoT 조회(`/task-init` 다음 번호 계산 / 진행중 목록)에서 자동 제외. **사용자 명시 운영 한정** — 메인 세션 자체 진입 금지.
-
----
-
-## 커밋 태그
-
-| 태그 | 용도 |
-|------|------|
-| `feat:` | feature |
-| `fix:` | bug |
-| `improve:` | improvement |
-| `refactor:` | refactor |
-| `docs:` | docs, chore |
-| `test:` | 테스트 파일 (유형 무관) |
-
----
-
-## 커밋 메시지 형식
-
-```
-{태그}: [TASK-{NNN}] Phase {N} - {작업 요약}
-
-- {처리 내용 1}
-- {처리 내용 2}
-- 사유: {변경 이유}
-```
-
-### 예시
-
-```
-feat: [TASK-001] Phase 1 - 사용자 인증 로직 구현
-
-- JWT 기반 인증 로직 구현
-- 로그인 API 엔드포인트 추가
-- 사유: 기존 세션 방식 한계로 전환
-```
-
----
-
-## 커밋 순서 (태스크 완료 시 — `/task-close` 스킬)
-
-태스크 마무리 시 메인이 아래 순서를 반드시 준수한다.
-
-```
-1. Phase별 기능 커밋 (각 Phase마다 1개)
-2. 태스크 문서 커밋
-3. CHANGELOG 커밋
-4. 부모 브랜치 병합 (--no-ff, 머지 락 직렬화)
-5. 워크트리 자동 제거 + 작업 브랜치 자동 삭제 (멀티세션 0.1.2+ — §"작업 브랜치 삭제 정책" 면제 조항)
-```
-
-### Phase↔파일 매핑 규칙 (`close` 자동 커밋)
-
-`close`가 코드 변경분을 Dev Plan Phase에 매핑해 Phase별 커밋을 자동 생성할 때 아래 규칙을 따른다 (한 파일 = 한 Phase가 성립하지 않는 정상 케이스의 blocked 반복 방지 — stash 6회·recordion 5회 마찰 반영):
-
-- **한 파일이 여러 Phase에 걸치면 → 가장 이른 Phase 커밋에 편입** + 커밋 메시지에 `(Phase a·b 변경 포함)` 표기. 뒤 Phase가 앞 Phase의 타입·함수를 참조하므로 이른 쪽이 의존 방향과 일치한다.
-- **Dev Plan에 없는 빌드 산출물**(`*.pbxproj` / `package-lock.json` 등 잠금파일 계열) **→ 마지막 Phase 커밋에 자동 편입** + `(빌드 산출물 자동 편입)` 표기. 산출물은 소스에 딸려 바뀌는 파생물이라 Phase 소속을 물을 대상이 아니다.
-- **Dev Plan에 없는 일반 파일 → 자동 편입 없이 중단(blocked)** — 계획에 없던 작업일 수 있어 사람 판단으로 남긴다.
-- **중간 커밋의 독립 빌드 가능성은 보장 대상이 아니다** — 다중 Phase 편입 시 어느 배치로도 중간 커밋 빌드는 성립하지 않을 수 있다(최종 트리 정상이면 충분). 이를 이유로 매핑을 수동 재배치하지 않는다.
-- **`- 파일:` 다중 파일 표기 규격** — 권장 = `- 파일:` 다음 줄부터 들여쓴 목록(`  - <경로>`), 허용 = 쉼표·가운뎃점(`·`) 구분 한 줄. `(신규)`류 꼬리 괄호 주석은 파서가 제거한다. **규격 밖 표기는 파서가 못 읽어 `blocked:'mapping'`으로 멈춘다.**
-
-### 태스크 문서 커밋 메시지
-
-```
-docs: [TASK-{NNN}] 태스크 문서 완료
-```
-
-### CHANGELOG 커밋 메시지
-
-```
-docs: [TASK-{NNN}] CHANGELOG 업데이트
-```
-
-### 병합 커밋
-
-- 머지 커밋 메시지는 git 기본 메시지 사용
-- `-m` 옵션으로 커밋 메시지 지정 금지
-- **`--no-ff` 강제 (일반 타입)**: feature/bug/improvement/refactor 등 일반 작업 브랜치 → 부모 병합 시 `git merge --no-ff {브랜치명}` 사용. fast-forward 병합 절대 금지. 머지 커밋이 없으면 작업 브랜치 삭제 후 분기 정보 영구 손실(90일 reflog GC 후 추적 불가).
-- **추적 변경 0 → 마커 빈커밋 (`--allow-empty` 금지의 유일 예외)**: 코드 변경 0 + `.project` gitignore로 작업 브랜치가 부모보다 앞선 커밋이 0개이면 `--no-ff`도 *Already up to date*가 되어 머지 커밋이 생성되지 않는다. 이 경우 `/task-close`가 추적 마커 빈커밋 1개(`--allow-empty`)를 생성해 분기·채번 정보를 보존한다 (상세: task-close Step 6-8). 그 외 빈커밋은 금지.
-- **plan/roadmap 임시 docs 브랜치 예외**: plan-init 단계의 단일 커밋(plan 신규 생성 — PLAN/ROADMAP + 제품 관통 문서 delta)에 한정 `--ff-only` 가능.
-- **task 진행 중 ROADMAP/플랜 문서 갱신은 별도 `docs/*` 브랜치 분리 절대 금지**: 해당 task의 작업 브랜치 (`feature/*` / `improve/*` 등) 안에서 수정 + 다른 구현 커밋과 함께 `--no-ff` 머지로 부모 병합 (분기 정보 손실 방지).
-
----
-
-## 작업 브랜치 삭제 정책
-
-### 기본 (멀티세션 외 / 케이스 2 / 사용자 수동 작업)
-
-작업 브랜치(feature/* / bug/* / improve/* / refactor/* / docs/* / chore/*)는 다음 조건 모두 만족 시에만 삭제한다:
-1. 부모 브랜치에 `--no-ff` 병합 완료 (머지 커밋이 부모에 기록됨)
-2. 사용자 명시 승인 ("브랜치 삭제해" 등 직접 요청)
-
-**메인 세션 룰**: 사용자 승인 없는 작업 브랜치 삭제 지시 절대 금지. 머지 후 자동 삭제 X. 사용자가 직접 요청 시에만 `git branch -d {브랜치명}` 실행. (단, plan/roadmap 임시 docs 브랜치는 단일 커밋 ff-only 머지 후 자동 삭제 가능.)
-
-### `/task-close` 자동 삭제 면제 조항 (멀티세션 0.1.2+)
-
-`/task-close` 마지막 단계의 *작업 브랜치 자동 삭제 + 워크트리 자동 제거*는 본 정책의 *사용자 명시 승인 룰* 면제 — 사용자가 `/task-close` 호출 자체로 *사전 승인*한 것으로 간주.
-
-| 동작 | 명령 | 면제 사유 |
-|------|------|----------|
-| 워크트리 제거 | `git -C "$MAIN_WT" worktree remove "$WT_PATH"` | task 완료 후 격리 폴더 정리 필요. 사전 안전 검증 (§"멀티세션 워크트리 정책" 참조) 후 진행 |
-| 작업 브랜치 삭제 | `git -C "$MAIN_WT" branch -d "$BRANCH"` | 부모 `--no-ff` 머지 완료 후 안전 삭제 (-D 강제 X). 머지 커밋이 부모에 박혀 분기 정보 보존 |
-
-#### 보존 키워드 (양쪽 다 보존)
-
-사용자 발화에서 다음 키워드 감지 시 **워크트리 + 브랜치 모두 보존** (Step 11~13 건너뜀):
-- `keep` / `--keep-branch` / `브랜치 남겨` / `브랜치 보존` / `브랜치 유지`
-
-#### 사전 안전 검증 (자동 흐름 차단 트리거)
-
-`/task-close` Step 11에서 다음 조건 발견 시 *자동 흐름 차단 + 사용자 호출*:
-- 워크트리 안 미커밋 변경 (`git status --porcelain` 결과 있음)
-- 워크트리 안 추적 X 파일 (`git ls-files --others --exclude-standard` 결과 있음)
-
-사용자 선택:
-- 보존 → 워크트리 + 브랜치 모두 보존 (Step 12, 13 건너뜀)
-- 삭제 → 정상 자동 흐름 (Step 12, 13 진행)
-- 취소 → close 중단 (단, 부모 브랜치 머지는 이미 완료된 상태)
-
-#### 안전망 출력 (브랜치 삭제 직후)
-
-```
-삭제됨: {브랜치명}
-복구: git -C "$MAIN_WT" branch {브랜치명} {머지 커밋 해시}
-```
-
-#### 면제 범위 한정
-
-본 면제는 *`/task-close` 마지막 단계 자동 흐름 한정*. 그 외 모든 destructive 명령(`git reset --hard` / `git push --force` / `git branch -D` / `git clean -fd`)은 §"금지 사항" 그대로 사용자 명시 승인 필수.
-
----
-
-## 멀티세션 워크트리 정책 (0.1.2+)
-
-### 메인 워크트리 = 부모 브랜치 고정
-
-- 메인 워크트리는 `/task-init` 시점에 서 있던 브랜치(= 그 task의 *부모 브랜치*)를 유지. 개인 기본 `dev`, 회사/로드맵 `dev_feat_x`/`master` 등 — taskery는 현재 브랜치를 부모로 삼는다(이름 고정 X).
-- 모든 태스크 작업은 *예외 없이* 별도 워크트리에서 수행
-- **진행 중 태스크가 있는 동안 메인 워크트리 HEAD를 옮기는 어떤 명령도 영구 금지**: `git checkout <task-branch>` / `git switch <task-branch>` / `git reset` HEAD 이동 / `git rebase` HEAD 이동 등. close가 부모로 되병합해야 하므로 부모에 서 있어야 한다. *"잠깐만 메인에서"* / *"테스트 한 번만"* 같은 예외 발화도 거부 (별도 워크트리로 처리). (부모 브랜치 자체 전환은 진행 중 태스크가 없을 때만.)
-- **모호 발화 자의 해석 금지**: *"워크트리 없이"* / *"메인에서"* / *"이 자리에서"* 류 발화 = 본 규칙 충돌 신호 → 즉시 정지 + 규칙 명시 + 1줄 confirm 요청 (자의 해석 후 진행 영구 금지). 사용자 의도가 *오타/모호*일 가능성은 *워크트리 사용*으로 읽는 게 자연스러움
-- `/task-init` / `/task-close` 시작 시 검증 (위배 시 사용자 호출 + 중단)
-
-### 워크트리 위치
-
-```
-~/.taskery/worktrees/<projectId>/TASK-NNN_<출처>_<슬러그>/
-```
-
-- `<projectId>`: `.taskery-manifest.json`의 `projectId` 필드 (8자 hex, taskery init 자동 생성)
-- 부모 디렉토리는 `/task-init`이 자동 `mkdir -p`
-
-### 워크트리 생성 / 제거
-
-| 작업 | 명령 | 주체 |
-|------|------|------|
-| 생성 | `npx @angar2/taskery fork <type> <dev> <src> <slug>` (내부: init 락 + `worktree add -b`) | `/task-init` |
-| 제거 | `git -C "$MAIN_WT" worktree remove "$WT_PATH"` | `/task-close` (자동 흐름 + 안전 검증) |
-| stale 정리 | `git -C "$MAIN_WT" worktree prune` | `npx @angar2/taskery prune` (사용자 확인 후) |
-
-### 워크트리 실행 환경 (의존성 — 앱 실행·검수 시)
-
-새 워크트리에는 의존성·빌드 산출물이 없다(생태계마다 형태 상이). 이를 메인 워크트리에서 **심링크로 끌어오지 않는다.**
-
-- 심링크는 실제 경로가 메인 워크트리를 가리켜, *파일 접근을 워크트리 내부로 제한하는 도구*(개발 서버 등)에서 로딩 실패(예: 빈 화면)를 일으킨다.
-- 빌드·테스트는 이 제한을 거치지 않아 심링크로도 통과하므로 "코드는 정상인데 실행만 깨짐"으로 오진하기 쉽다.
-- 해당 task에서 앱을 **실행·검수**해야 한다면 심링크 대신 워크트리 안에 의존성을 실제로 마련한다(프로젝트 고유의 설치 명령 사용). 실행·검수가 필요 없는 task는 무관하다.
-
-### 메인 워크트리 절대 경로 검출
-
-워크트리 안에서 메인 워크트리 메타(`.project/`, `AGENTS.md`)에 접근할 때 사용:
-
-```sh
-MAIN_WT=$(dirname "$(git rev-parse --path-format=absolute --git-common-dir)")
-```
-
-git ≥ 2.31 필요 (`--path-format=absolute` 옵션).
-
-### SSoT 조회 (진행중 태스크)
-
-```sh
-git -C "$MAIN_WT" branch --list \
-  'feature/*_TASK-*' 'bug/*_TASK-*' 'improve/*_TASK-*' \
-  'refactor/*_TASK-*' 'docs/*_TASK-*' 'chore/*_TASK-*'
-```
-
-`_TASK-*` 패턴 강제로 케이스 2(TASK 없는 브랜치) 자동 제외. (부모 기준 `--no-merged` 미사용 — 분기 직후 브랜치는 부모와 동일 commit이라 완전 머지로 오판돼 채번이 충돌하기 때문. 브랜치 존재 자체가 SSoT. `bin/lib.js` `getActiveTasks` 참조.) 별도 상태 파일/락 운영 X — git 분산 락(동일 브랜치명 자동 거부) + 결정적 슬러그(백로그/로드맵 항목 제목 → kebab-case)가 race 차단 2층 안전망.
-
-### 머지 직렬화 (head-to-head race 차단)
-
-`/task-close` Step 6에서 `proper-lockfile` 기반 머지 락 (`~/.taskery/<projectId>.merge.lock`) 획득 후 rebase + 머지 시퀀스 실행:
-- stale: manifest `lock_timeout_ms` (기본 30000ms)
-- retries: 5회, 1초 간격
-- 락 외 *사전 rebase* (UX용 조기 충돌 감지) → 락 안 *재 rebase*로 락 외에서 발생한 다른 세션 머지 흡수
-
-### 멀티세션 검수 환경 (dev 서버 · 터널 — 검수 서버를 띄우는 프로젝트 한정)
-
-여러 세션이 병렬로 검수용 dev 서버·터널을 띄울 때 포트·프로세스가 충돌하지 않도록 task별로 자원을 독립 소유한다. CLI·라이브러리 등 검수 서버가 없는 프로젝트는 무관.
-
-- **포트 격리 (결정적)**: 메인 세션(부모 브랜치) = 기준 포트, task 워크트리 = 기준 포트 + TASK번호. 기준 포트는 프로젝트가 `AGENTS.md` `## 검수 실행 명령`에 선언한다 (멀티 프로젝트 동시 운영 시 프로젝트마다 다른 기준 포트). TASK번호는 1부터라 offset 0(기준 포트)이 메인 몫으로 항상 비어 충돌하지 않는다.
-- **터널 (필수 아님)**: 모바일 검수 등 필요한 task만, 자기 포트를 가리키는 별도 프로세스로 판다 → task별 독립 URL.
-- **자기 것만 정리**: `/task-close` 시 본 task가 띄운 서버·터널(자기 포트 것)만 종료한다. **`pkill -f` 같은 광역 종료 금지** — 다른 세션의 서버까지 죽이는 원인.
-- **검수 기동 (자동)**: 사용자가 결과를 *눈으로 검수*하는 시점에 위 포트로 서버를 백그라운드 기동하고 접속 URL을 보고한다 (사용자가 매번 실행을 지시하지 않게). 정확한 발동 지점은 각 스킬 참조 — `/task-dev`는 세션이 거기서 끝날 때(Step 9), `/task-test`는 UNCERTAIN 검수 직전(Step 5)·PASS 후 종료 시(Step 7). FAIL→수정 흐름에서는 기동하지 않는다. 단계가 *기능상* 서버를 요구하면(E2E 등) 검수 시점과 무관하게 띄운다.
-- **중복 기동 방지**: 새로 띄우기 전에 해당 포트·프로세스가 이미 살아 있는지 확인한다. `Port … is in use` 류 경고는 *이미 떠 있다*는 신호이므로 무시하고 재기동하지 않는다. 종료 시에는 부모 프로세스만이 아니라 자식 프로세스(브라우저·렌더러 창 등)까지 확인해 정리한다.
-- **화면·입력 점유 회피**: 실제 앱을 띄워 UI를 자동 조작하는 테스트 스위트는 사용자의 화면·마우스·키보드를 점유해 작업을 중단시킨다. 자동 게이트·격리 세션은 `.project/rules/TEST_RULE.local.md` *테스트 실행 환경* 절에 선언된 격리 실행 경로(창 숨김·헤드리스 / 컨테이너 / VM / CI)로만 자동 실행하고, 선언이 없으면 비점유 부분만 실행하거나 사용자 승인을 받는다.
-- **효과 (정직)**: 포트 충돌은 결정적으로 제거된다. 다른 세션의 종료·턴 경계 프로세스 소실은 위 규율·백그라운드 실행으로 완화되나 문서 규율이라 강제는 아니다(best-effort).
-
----
-
-## Hook 안전망 — `git-guard.sh`
-
-`.claude/hooks/git-guard.sh`가 PreToolUse(Bash)로 다음 명령 차단:
-- `main` / `dev` 직접 커밋 — **5종 변형 인식** (0.1.3+): `git -C <경로>` / `git --git-dir=<경로>` / `git --git-dir <경로>` / `git --work-tree=<경로>` / `git --work-tree <경로>` 모두 인식해 *대상 경로의 브랜치*로 검사. 어느 cwd에서 호출하든 워크트리 브랜치 커밋이 dev 직접 커밋으로 오인 차단되지 않음
-- `git push --force` (작업 브랜치 외 / 사용자 미승인)
-- `git commit --no-verify`
-- `git branch -D` (사용자 미승인)
-- `git reset --hard` (사용자 미승인)
-- `git clean -fd` (사용자 미승인)
-
-**셸 prefix 금지**: `cd <경로> && git ...` / `(cd <경로> && git ...)` 형태는 hook이 정확히 인식 X (변형 우회 위험). 모든 워크트리 대상 명령은 `git -C <경로> ...` 형태로만 발행.
-
-이 hook은 *catastrophic 차단 안전망*. 잘 지키면 작동 0회 (무해).
-
----
-
-## 금지 사항
-
-- 민감 정보 커밋 금지 (`.env`, API KEY, Secret Key 등)
-- 여러 태스크를 하나의 브랜치에서 작업 금지
-- 커밋 순서 임의 변경 금지
-- 승인 없이 부모 브랜치 병합 금지
-- **destructive 명령 사용자 승인 필수**: 다음 명령은 사용자 명시 승인 없이 절대 실행 금지:
-  - `git reset --hard ...`
-  - `git push --force ...`
-  - `git branch -D ...`
-  - `git clean -fd ...`
-  → 정상 흐름에서 위 명령 사용 사유 없음. 충돌/오류 발생 시 사용자에게 보고 + 승인 요청 의무.
-
----
-
-## 수정 이력
-
-| 날짜 | 변경 사항 |
-|------|----------|
-| 2026-05-07 | `--no-ff` 강제 + 작업 브랜치 삭제 정책 + destructive 명령 사용자 승인 필수 룰 추가 |
-| 2026-05-08 | git 작업은 메인 세션이 `/task-close` 스킬 또는 직접 수행으로 단일화. git-guard.sh hook 안전망 명시 추가 |
-| 2026-05-09 | 표현 정제 — 인명 / 경박 표현 / 스킬 용어 / 이전 버전 비교 단락 정리 |
-| 2026-05-30 | docs/* 브랜치 ff-only 예외 명시 — plan-init 단일 커밋 한정. task 진행 중 ROADMAP/플랜 갱신은 작업 브랜치 + --no-ff 명시 추가 (stash FRICTION_LOG #4 반영) |
-| 2026-05-31 | 멀티세션 0.1.2 오버라이드 — 브랜치명에 출처(BL/RM/DR) 추가 / 케이스 2(TASK 없는 브랜치) 시스템 외 명시 / `/task-close` 자동 삭제 + 워크트리 제거 면제 조항 / 멀티세션 워크트리 정책 섹션 신규 (메인=dev 전용 / SSoT 조회 / 머지 락 직렬화) |
-| 2026-05-31 | 0.1.2 백로그 스킬 추가 정합 — 출처 표 `BL-NNN` 채번 주체 `/backlog-add` → `/add-backlog`로 갱신 + 버전별 경로(`.project/tasks/<vX.X>/BACKLOG.md`) 명시 |
-| 2026-06-02 | 0.1.3 F2·F3 정합 — §멀티세션 워크트리 정책 *메인 HEAD 떼기 금지* + *모호 발화 자의 해석 금지* / §git-guard.sh 5종 변형 인식 (-C / --git-dir / --work-tree) + 셸 prefix 금지 명시. stash FRICTION_LOG 2026-06-01 반영 |
-| 2026-06-25 | 추적 변경 0(코드 0 · `.project` gitignore) close 시 마커 빈커밋으로 분기·채번 정보 보존 — `--no-ff` 머지 커밋 미생성 케이스의 `--allow-empty` 유일 예외 명시 (상세: task-close Step 6-8). FRICTION 검토 F1 반영 |
-| 2026-06-28 | 워크트리 생성 메커니즘 갱신 — `git worktree add` 직접 실행 → `npx @angar2/taskery fork`(init 락 안에서 채번+분기 원자 실행). 병렬 task-init 번호 충돌(레이스) 차단 |
-| 2026-06-25 | §멀티세션 워크트리 정책에 "워크트리 실행 환경" 추가 — 워크트리에 의존성 심링크 금지(개발 서버 fs 접근 제한으로 로딩 실패), 실행·검수 task는 워크트리 안에 의존성 실제 마련. FRICTION 검토 F6 반영 |
-| 2026-06-25 | §멀티세션 워크트리 정책에 "멀티세션 검수 환경" 추가 — task별 dev 서버 포트 격리(메인=기준 포트, task=기준+TASK번호) + 터널 독립 + close 시 자기 것만 종료(광역 종료 금지) + 사용자 검수 시점 서버 자동 기동(task-test UNCERTAIN/PASS·task-dev 종료, FAIL 제외). FRICTION 검토 F7 반영 |
-| 2026-08-08 | 출처 표기 개편 — `RM-NNN`(로드맵 항목 채번, 미구현) → `ST-N`(ROADMAP Stage 번호 그대로, 채번 불요·동일 출처 중복 게이트 미적용). 구형 RM-NNN은 호환 수용만. + §커밋 순서에 "Phase↔파일 매핑 규칙" 신설 — 다중 Phase 파일=이른 Phase 편입+표기 / 빌드 산출물=마지막 Phase 자동 편입 / 일반 미매핑만 blocked / 중간 커밋 독립 빌드 비보장 명문화. stash·recordion FRICTION_LOG 반영 |
-| 2026-08-08 | §멀티세션 검수 환경에 "중복 기동 방지"·"화면·입력 점유 회피" 2항 추가 — 검수 앱 중복 기동(부모만 종료해 창 잔존) 및 UI 자동조작 스위트의 화면·입력 강탈 마찰 반영. stash·recordion FRICTION_LOG |
-| 2026-08-08 | 0.7.0 문서 체계 재편 정합 — 진입 문서 단일화(`AGENTS.md` 본문 + `CLAUDE.md`는 임포트 한 줄)에 따라 검증 명령 참조 경로 변경, 폐지된 `TEST-GUIDE.md` 참조를 `TEST_RULE.local.md`로 교체. 머리말에 `.local.md` 구속력 안내 추가(코어와 동등 — `TASKERY_RULE` §7) |
-| 2026-08-09 | §Phase↔파일 매핑 규칙에 `- 파일:` 다중 파일 표기 규격 추가 — 권장=들여쓴 목록 / 허용=쉼표·가운뎃점 한 줄 / 꼬리 괄호 주석 파서 제거 / 규격 밖=blocked 명문화. recordion FRICTION 2026-08-09(TASK-010 — 가운뎃점 표기가 줄 전체 경로 하나로 파싱) 반영 |

package/template/.project/rules/MOCKUP_RULE.md

@@ -1,86 +0,0 @@
-# MOCKUP_RULE
-
-> 본 파일은 taskery 시스템 권장 UX/UI 구현 task의 HTML 목업 정책이다.
-> 우선순위: **이 파일** (`.project/rules/MOCKUP_RULE.md`) → 메인 판단.
-> 프로젝트별 변형이 필요하면 `.project/rules/MOCKUP_RULE.local.md` 생성 (npx update 미터치, 구속력은 코어와 동등 — `TASKERY_RULE` §7).
-
----
-
-## 1. 목적
-
-UX/UI 구현 task의 *시각 영역 사전 정합* + *task-test 시 USER 검수 기준 확보*. stash FRICTION_LOG #14+19 반영 — UX/UI 검증의 시각 fix 사이클 반복 마찰 사전 차단.
-
-**효과**:
-- 사용자가 *눈으로 보고* 의도 확인 → 인지 불일치 사전 차단
-- 메인이 *시각 기준* 확보 → 구현 시 디자인 정합 검증 기준
-- task-test USER 시각 시나리오의 *기준 파일* 역할
-
----
-
-## 2. 적용 대상 task
-
-**적용**:
-- UX/UI 구현 포함 task (페이지 / 컴포넌트 신규 / 시각 변경 / 인터랙션 신규)
-- `/task-plan` Step 2 Requirements 인터뷰 결과로 *UX/UI 구현 포함* 판단되면 Step 4.5 목업 프로세스 진입
-
-**미적용**:
-- 백엔드 / CLI / 인프라 / 설정 변경 등 시각 영역 없는 task
-- UX/UI 포함이지만 사용자가 *"NO"* 응답한 task (Step 4.5에서 confirm)
-
----
-
-## 3. 파일 위치 / 네이밍
-
-- **경로**: `.project/tasks/<NNN_slug>/mockup/<task-doc-name>-mockup.html`
-- **네이밍**: task 문서 파일명 + `-mockup.html`
-  - 예 1: `001_login-form.md` → `001_login-form-mockup.html`
-  - 예 2: 폴더 승격 `TASK-007_payment-flow/task.md` → `TASK-007_payment-flow-mockup.html`
-- **task 1개 = 목업 1개** — multi-file 예외 영구 X. 복잡해도 한 파일 안 섹션 분리 (`<section id="popover">` 등)
-
----
-
-## 4. 파일 형식
-
-- 정적 HTML (외부 라이브러리 X)
-- 단일 파일 안 inline `<style>` + 필요 시 vanilla `<script>`
-- 시각 영역 (레이아웃 / 색상 / 간격 / 타이포 / 호버 효과) 본질 표현
-- 인터랙션 가능 범위 (클릭 / 호버 시뮬) — 구현 정확도 ↑
-
----
-
-## 5. 생성 흐름 (`/task-plan` Step 4.5 정합)
-
-1. UX/UI 구현 task 판단 (Step 2 Requirements 인터뷰 결과)
-2. 사용자에게 *"HTML 목업 만들까?"* 한 줄 confirm — **예외 없이 발화 강제**. 메인의 효용 판단(*"이 케이스는 목업 효용 낮음"* / *"SF Symbol은 HTML 재현 X"* 등)으로 confirm 자체를 생략하는 행위 영구 금지. 효용 판단은 질문에 *곁들이는 의견*으로만 가능 (생략 결정 대체 X — 목업 제작 여부는 *사용자 검수 방식 선택권*이라 *개발 자율 판단* 영역 X).
-3. OK → 메인이 정적 HTML 생성 → 사용자 시각 승인 (✓ → 진행 / ✗ → 수정 재승인)
-4. 승인된 목업 = task-test의 *시각 영역 USER 검수 기준*
-
----
-
-## 6. 두 시점 활용
-
-| 시점 | 활용 |
-|------|------|
-| `/task-dev` | 메인이 *직접 Read* (sub-agent 위임 X) 후 구현. 구현 = 목업 기준 (역방향 X — 코드 편의로 목업 어김 절대 X) |
-| `/task-test` | 격리 세션 prompt에서 *목업 파일 정독 후 시각 USER 시나리오 기준*으로 사용. 자동 비교 X. 사용자 검수 보고 시 *체크리스트 + 목업 경로 명시* |
-
----
-
-## 7. 시각 fix 사이클 사전 예고
-
-시각 영역은 한 사이클로 100% 일치 보장 X. `/task-plan` Test Plan 작성 시 + `/task-test` 결과 보고 시 *"fix 사이클 1~2회 예상"* 사용자 안내 (기대치 사전 정렬, 부정 반응 누적 방지).
-
----
-
-## 8. 디자인 산출 정독 의무
-
-목업 = 디자인 산출. 메인이 *직접 Read* 후 구현 (sub-agent 위임 X — 요약만 받아 시각 정합 깨짐 함정 회피). stash FRICTION_LOG #12 일반화.
-
----
-
-## 9. 수정 이력
-
-| 날짜 | 변경 사항 |
-|------|----------|
-| 2026-05-30 | 신규 작성 — UX/UI task HTML 목업 위치 / 형식 / 생성 흐름 / 두 시점 활용 / 시각 fix 사이클 예고 / 디자인 정독 의무 정의 (stash FRICTION_LOG #14+19 / #12 반영) |
-| 2026-06-02 | §5 #2 — 목업 confirm *예외 없이 발화 강제* 명시 추가 (메인 효용 판단으로 confirm 자체 생략 금지). stash FRICTION_LOG 2026-06-01 F1 반영 |

package/template/.project/rules/TASKERY_RULE.md

@@ -1,237 +0,0 @@
-# TASKERY_RULE — taskery 사용 설명서
-
-> 본 문서는 taskery의 **전체 사용법 단일 소스**다. 세션은 본 문서를 필독한 후 작업한다.
-> 본 문서는 taskery 패키지가 관리한다 — `npx @angar2/taskery update`로 갱신되므로 직접 수정하지 않는다.
-> 리포 특성 커스텀은 `TASKERY_RULE.local.md`(본 문서 짝)로 한다.
-> **경계**: 본 문서는 *전체 그림과 체계*까지만 담는다. 각 단계의 상세 수행 절차는 해당 스킬(`SKILL.md`)이, git 정책 상세는 `GIT_RULE`이, task 문서 양식은 `TASK_DOC_RULE`이 담당한다 — 여기에 상세 절차를 옮겨 적지 않는다.
-
----
-
-## 1. taskery란
-
-taskery는 **task 단위 라이프사이클 관리 시스템**이다. 하나의 작업을 task로 세우고, 그 task의 문서·상태·git 브랜치·검증을 정해진 순서로 진행시킨다. 각 단계는 **스킬**(에이전트가 호출하는 절차서)이 주도하고, 결정적인 부분(채번·상태 전이·분기·커밋 준비)은 **CLI/도구**가 코드로 수행한다.
-
-목적은 두 가지다. 하나는 작업 이력이 문서와 git 양쪽에 일관된 형태로 남게 하는 것, 다른 하나는 여러 세션이 같은 리포에서 동시에 일해도 서로를 망가뜨리지 않게 하는 것이다.
-
----
-
-## 2. task 라이프사이클
-
-### 7상태
-
-```
-draft → planned → developing → developed → testing → tested → closed
-```
-
-| 상태 | 의미 |
-|------|------|
-| `draft` | task 문서 골격만 생성된 상태 |
-| `planned` | 요구사항·범위·구현 계획·검증 계획 확정 |
-| `developing` | 구현 진행 중 |
-| `developed` | 구현 완료 + 자체 점검(린트·타입·빌드) 통과 |
-| `testing` | 격리 검증 진행 중 |
-| `tested` | 격리 검증 통과 |
-| `closed` | git 마무리 완료 |
-
-상태 전이는 **코드가 유효성을 검증**한다(`set_status` 도구 / `npx @angar2/taskery set-status`). 문서를 직접 편집해 상태를 바꾸지 않는다. 유효 전이표와 FAIL·UNCERTAIN 분기의 상세는 `TASK_DOC_RULE` §1.2에 있다.
-
-### 어느 상황에 어느 스킬을 호출하나
-
-| 상황 | 스킬 |
-|------|------|
-| 새 작업을 시작한다 | `/task-init` |
-| 무엇을 어떻게 만들지 정한다 | `/task-plan` |
-| 구현한다 | `/task-dev` |
-| 검증한다 | `/task-test` |
-| 마무리하고 부모 브랜치에 합친다 | `/task-close` |
-| 프로젝트를 처음 세운다 | `/project-init` (1회성) |
-| 기능 그룹을 새로 연다 | `/plan-init` |
-| 나중에 할 일을 적어 둔다 | `/add-backlog` |
-| 작업 중 겪은 불편을 남긴다 | `/log-friction` |
-
-**사용자가 명시한 범위만 수행한다.** 예를 들어 `/task-dev`까지 지시받았으면 `developed`에서 정지하고 보고한다. 다음 단계로 스스로 진입하지 않는다.
-
----
-
-## 3. plan · task · 백로그의 관계
-
-- **plan** = 기능 그룹 단위. `.project/plans/<NNN_slug>/`에 `PLAN.md`(인덱스)와 `ROADMAP.md`(Stage 계획)를 둔다.
-- **task** = 실제 작업 단위. `.project/tasks/<NNN_slug>/`에 task 문서가 쌓인다.
-- **백로그** = 아직 task로 옮기지 않은 후보. `.project/tasks/<NNN_slug>/BACKLOG.md`에 `BL-NNN`으로 누적한다.
-
-**활성 plan**은 `.taskery-manifest.json`의 `activePlan` 필드가 단일 진실이다. 문서에 활성 plan을 자기선언하는 줄을 만들지 않는다. 확인은 `status` 도구, 전환은 `npx @angar2/taskery plan-switch <NNN_slug>`로 한다.
-
-**백로그 체크박스의 의미**:
-- `[ ]` = 미확인(task로 옮기지 않은 메모) / `[x]` = task로 옮김.
-- `[x]`는 *task로 옮겼다*는 메모일 뿐 완료·머지 여부와 무관하다. **`[x]` 항목이 실제로 끝났는지 굳이 확인하려 들지 않는다.**
-- 완료 여부를 반드시 알아야 하면 순서를 지킨다. ① `taskery status` 진행중 목록에 있으면 아직 진행 중이므로 `git log`가 비는 것이 정상이다(재조회하지 않는다). ② 목록에 없으면 `git log --all --grep 'BL-NNN'`으로 확인한다.
-
-백로그 조작은 **손편집하지 않는다** — `backlog_add` / `backlog_get` / `backlog_mark` 도구가 채번·서식·직렬화를 보장한다. 파일 위치는 등록/미등록과 무관하게 항상 메인 워크트리다.
-
-`.project/BACKLOG.md`(글로벌)는 *다음 기능 그룹* 후보 카탈로그로 성격이 다르며 `/plan-init` 영역이다.
-
----
-
-## 4. 스킬
-
-| 스킬 | 레벨 | 하는 일 |
-|------|------|--------|
-| `/project-init` | project | `AGENTS.md` 리포 값 기입 + `.project/` 진입·제품 관통 문서 + 리포 로컬 룰 초안 생성 (1회성) |
-| `/plan-init` | plan | plan 폴더·PLAN·ROADMAP 생성 + FEATURES/UX-UI에 의도 추가 |
-| `/task-init` | task | 채번 + 워크트리·브랜치 분기 + task 문서 골격 (→ `draft`) |
-| `/task-plan` | task | Requirements / Scope / Dev Plan / Test Plan 작성 (→ `planned`). 해석 여지 태스크는 Test Plan을 격리 서브에이전트 B가 출제(출제 분리 — 구현자 겸 출제의 오독 동조 차단, 원문 origin 보존) |
-| `/task-dev` | task | Phase 순서 구현 + 자체 점검 (→ `developed`) |
-| `/task-test` | task | 서브에이전트 격리 검증 (→ `tested`). 출제 분리 태스크는 origin 대조로 시험지 오염 검사(무플래그 수정 즉시 반려) + 핵심 시나리오 음성 대조 |
-| `/task-close` | task | 문서 게이트(PLAN·수정이력 grep) + 커밋 + CHANGELOG 자동 append + 부모 브랜치 병합 (→ `closed`) |
-| `/add-backlog` | meta | 백로그 항목 1건 추가 (얕은 분석 + 채번) |
-| `/log-friction` | meta | 작업 흐름의 불편을 `FRICTION_LOG.md`에 한 행 기록 |
-| `/run-team` | meta · **Claude 전용** | 다건 task를 팀원 세션에 분배해 병렬 처리 |
-
-각 스킬의 수행 절차는 해당 `SKILL.md`에 있다. **스킬은 반드시 정식 호출한다** — 본문을 기억으로 대체해 진행하지 않는다(컨텍스트가 압축된 상태에서도 동일).
-
-`/run-team`은 기본 흐름이 아니다. *"백로그 한 번에 진행해"* 류의 트리거 발화가 있을 때만 발동하며, 실험 기능이라 `~/.claude/settings.json`의 `env`에 `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS: "1"` 설정이 선행돼야 한다. Codex에는 해당 기능이 없어 미지원이다.
-
----
-
-## 5. 멀티세션 (워크트리)
-
-여러 메인 세션이 같은 프로젝트에서 독립 task를 병렬 진행할 수 있다. 작업 폴더는 git worktree로 격리하고, 부모 브랜치 병합은 락으로 직렬화한다.
-
-- **메인 워크트리 = 부모 브랜치 고정.** 메인 워크트리는 `/task-init` 시점에 체크아웃돼 있던 브랜치를 유지한다. taskery는 특정 이름을 고정하지 않고 *그때 서 있는 브랜치*를 부모로 삼는다.
-- **진행 중 task가 있는 동안 메인 워크트리의 HEAD를 옮기는 어떤 작업도 금지**한다(`checkout` / `switch` / `reset` / `rebase` 등). close가 부모로 되병합해야 하므로 부모에 서 있어야 한다.
-- ***"잠깐만 메인에서"* / *"테스트 한 번만 메인에서"* 류의 예외 발화도 거부**한다. 별도 워크트리에서 처리한다. 이런 발화는 규칙 충돌 신호이므로 정지 후 확인한다.
-- **세션 시작 시 자가 진단**: `git rev-parse --show-toplevel` 결과를 `~/.taskery/worktrees/` 경로와 비교해 지금이 메인 워크트리인지 task 워크트리인지 판정한다. task 워크트리면 그 task 맥락으로, 메인이면 새 task 또는 진행중 목록 흐름으로 진입한다.
-- **워크트리에서 메인 메타에 접근**할 때는 메인 워크트리 절대 경로를 쓴다:
-  ```sh
-  MAIN_WT=$(dirname "$(git rev-parse --path-format=absolute --git-common-dir)")
-  ```
-- **수동 git 작업은 정합성을 보장하지 않는다.** taskery 스킬과 `npx @angar2/taskery <서브커맨드>`로만 운영한다.
-- 보조 명령: `status`(진행중 task·워크트리·부모 머지 상태) / `prune`(오래된 워크트리 대화형 정리).
-
-git 정책의 상세(브랜치 명명·커밋 형식·병합 방식·금지 명령)는 `GIT_RULE`에 있다. 요건은 git 2.31 이상이다.
-
----
-
-## 6. 문서 체계 지도
-
-| 구분 | 위치 | 성격 |
-|------|------|------|
-| 진입 문서 | `AGENTS.md` (+ `CLAUDE.md`는 이를 임포트) | 에이전트 최상위 지침 + 이 리포의 메타·명령 값 |
-| 코어 룰 | `.project/rules/` | taskery가 제공하며 모든 리포에 동일 |
-| 리포 로컬 룰 | `.project/rules/*.local.md` | 이 리포 고유 규칙 (§7) |
-| 제품 관통 문서 | `.project/` 루트 | SERVICE-POLICY / TECH-STACK / ARCHITECTURE / DATA-MODEL / API-SPEC / FEATURES / UX-UI |
-| plan 문서 | `.project/plans/<NNN_slug>/` | PLAN · ROADMAP |
-| task 문서 | `.project/tasks/<NNN_slug>/` | task 본문 · spec-diffs · screenshots · mockup |
-| 기계 상태 | `.taskery-manifest.json` | 활성 plan · projectId · 설치 자산 해시 — **손편집 금지** |
-
-**코어 룰 5종**:
-
-| 룰 | 관할 |
-|----|------|
-| `TASKERY_RULE` | taskery 사용법 전체 (본 문서) |
-| `TASK_DOC_RULE` | task 문서 양식 — 헤더 6컬럼 / 6섹션 / 7상태 |
-| `GIT_RULE` | git 정책 — 브랜치 · 커밋 · 병합 · 금지 명령 |
-| `CHANGELOG_RULE` | CHANGELOG 위치 · 형식 · 필수 필드 |
-| `MOCKUP_RULE` | UX/UI task의 HTML 목업 위치 · 형식 · 네이밍 |
-
-**Hook 안전망 2종** — 정상적으로 지키면 한 번도 작동하지 않는다.
-
-| Hook | 차단 대상 |
-|------|----------|
-| `git-guard.sh` | 보호 브랜치 직접 커밋 / `--force` / `--no-verify` / `branch -D` / `reset --hard` / `clean -fd` |
-| `closed-immutable.sh` | `closed` 상태 task 문서의 재수정 (spec-diffs · screenshots · mockup은 자유) |
-
----
-
-## 7. `.local.md` 커스텀 체계
-
-코어 룰은 **항상 준수가 기본값**이다. 이 리포만의 규칙이 필요하면 해당 코어 문서의 짝을 만든다 — 파일명은 `<코어문서명>.local.md`이며 같은 `.project/rules/`에 둔다. 예: `GIT_RULE.local.md` · `TASK_DOC_RULE.local.md`.
-
-**구속력**:
-
-> 로컬 룰의 조항은 코어와 **동등한 구속력**을 가진다. 겹치는 조항은 로컬이 최우선이고, **겹치지 않는 로컬 조항도 그대로 준수한다.**
-
-**로컬이 뒤집을 수 없는 안전선** (아래는 로컬에 무엇을 적든 무효다):
-- 멀티세션 불변식 — 메인 워크트리 부모 브랜치 고정, task는 워크트리에서.
-- git 되병합·워크트리 정리는 `/task-close`만 수행.
-- destructive git 명령은 사용자 승인 필수.
-- 상태 전이 유효성 검증(코드 게이트).
-
-**갱신 안전 보장**: `*.local.md`는 taskery 패키지가 배포하는 자산이 아니므로 `npx @angar2/taskery update`가 **영구히 건드리지 않는다.** 반대로 코어 룰은 update가 갱신하므로 코어 파일을 직접 고치지 않는다 — 고쳐야 할 내용은 로컬 짝으로 옮긴다.
-
----
-
-## 8. TEST_RULE.local.md · DEV_RULE.local.md — 모든 리포 필수
-
-이 둘은 코어 짝이 없는 **로컬 전용 문서**다. 프로젝트마다 검증·구현 방식이 근본적으로 달라 공통으로 배포할 내용이 없기 때문이다. 그러나 **모든 리포에 반드시 존재해야 한다** — 없으면 세션이 그 리포의 방식을 모른 채 일반론으로 진행하게 된다. `/project-init`이 초안을 만들고, 이후 작업 중 확인된 사항을 누적한다.
-
-**`TEST_RULE.local.md` 구성**:
-
-| 섹션 | 내용 |
-|------|------|
-| 방식별 실행 경로 | 데이터 조회 / API 호출 / UI·E2E / 시각 실행 — 각 방식을 *이 프로젝트에서 실제로 돌리는 명령·경로·셋업* |
-| 테스트 실행 환경 | 화면·입력을 점유하는 스위트의 **격리 실행 경로**(창 숨김·헤드리스 플래그 / 컨테이너·가상 디스플레이 / VM / CI 러너). 결정 자체도 기록 대상이다 — 격리 경로를 두지 않기로 했다면 *"없음 — 매번 승인(사용자 결정 YYYY-MM-DD)"*로 적어 미결정 상태와 구분한다 |
-| 범위·방식 정책 | 무엇을 얼마나 검증하나 — 수정 루프에서의 실행 범위, 테스트 신설 상한 등 |
-
-**"방식별 실행 경로"는 그대로 실행 가능한 형태로 적는다.** 추상적 설명이 아니라 명령과 경로다. 모르면 비워 두지 말고 사용자에게 확인한 즉시 기록한다 — 재사용의 근거는 기억이 아니라 파일이어야 세션이 바뀌어도 남는다.
-
-**"테스트 실행 환경"이 비어 있으면 점유 스위트를 자동 실행하지 않는다.** 사용자의 화면·마우스·키보드를 뺏어 작업을 중단시키기 때문이다. 비점유 부분만 한정 실행하거나, 실행 보류로 표시해 사용자 승인을 받는다.
-
-**`DEV_RULE.local.md` 구성**: 이 프로젝트 고유의 구현 정책과 테스트 실행 정책(빌드 선행 여부, 커밋 단위 관행, 금지 패턴 등).
-
----
-
-## 9. 규칙을 새로 만드는 절차
-
-**트리거 2종**:
-1. 사용자가 직접 언급하거나 불편을 표현한 경우.
-2. 세션이 작업 중 문제를 인지한 경우(같은 실수 반복, 방식이 프로젝트와 맞지 않음 등).
-
-**판단** — 둘 중 어느 쪽인지 먼저 가른다.
-
-| 성격 | 처리 |
-|------|------|
-| **taskery 자체의 결함** — 모든 리포에서 똑같이 발생할 문제 | `/log-friction`으로 기록한다. 예: 스킬 지시가 서로 모순됨, CLI 반환값이 문서와 다름 |
-| **이 리포의 특성** — 이 프로젝트에서만 해당하는 방식·관행 | 해당 문서의 `.local.md` 감이다. 예: 이 프로젝트는 테스트 전에 빌드가 필요함, 이 리포는 특정 브랜치 명명을 씀 |
-
-**질문 후 생성** — 리포 특성으로 판단했으면 **반드시 사용자에게 묻는다**: *"이걸 이 리포 규칙(`<문서>.local.md`)으로 등록할까?"* 승인받은 후에만 파일을 만들거나 조항을 추가한다. 문안은 사용자와 확정한 내용으로 적는다. 양쪽에 모두 해당하면 둘 다 제안한다.
-
-새 로컬 문서의 파일명은 §7의 규칙을 따른다 — 코어 짝이 있으면 `<코어문서명>.local.md`, 없으면 `TEST_RULE` · `DEV_RULE`처럼 관할이 드러나는 이름에 `.local.md`를 붙인다.
-
----
-
-## 10. 폴더 구조
-
-```
-.project/
-├─ rules/                    코어 룰 5종 + 이 리포의 *.local.md
-├─ *.md (루트)               제품 관통 문서 (SERVICE-POLICY / TECH-STACK / ARCHITECTURE /
-│                            DATA-MODEL / API-SPEC / FEATURES / UX-UI)
-├─ PROJECT.md                프로젝트 개요 + 초기 빌드 로드맵
-├─ GLOSSARY.md               도메인 용어집 (영문/한글 표기 단일 진실)
-├─ LINKED-REPOS.md           연결 리포 목록
-├─ BACKLOG.md                다음 기능 그룹 후보 카탈로그
-├─ FRICTION_LOG.md           불편 기록 (첫 기록 시 생성)
-├─ plans/<NNN_slug>/         PLAN.md · ROADMAP.md
-├─ tasks/<NNN_slug>/         task 문서 · spec-diffs/ · screenshots/ · mockup/
-├─ flows/                    도메인 흐름
-├─ shared/                   멀티리포 메시지
-├─ changelog/                월별 변경 이력
-└─ .env                      연결 리포 경로 (gitignore)
-```
-
----
-
-## 11. 동기화 · 불편 기록 · 멀티리포
-
-**동기화 (사용자 의무)** — taskery는 문서 간 자동 빌드를 하지 않는다.
-- `.project/` 루트 제품 관통 문서를 변경하면 → 관련 task의 `spec-diffs/`를 갱신한다.
-- 진입 문서의 검증·테스트 명령을 변경하면 → 모든 스킬과 hook이 그대로 따르므로 별도 동기화가 불필요하다.
-- 룰 문서를 변경하면 → 다음 스킬 호출부터 반영된다.
-
-**불편 기록** — `.project/FRICTION_LOG.md`에 한 행씩 누적한다. 파일이 없으면 `/log-friction`이 첫 기록 때 생성한다. 발동 계기는 사용자 명시 호출 / 불만 발화 감지 / `/task-close` 직후 마찰 신호 자체 감지다.
-
-**멀티리포 통신** (해당 시)
-- 송신: `.project/shared/sent/<파일명>.md` 작성 → 수신 리포에서 `received/`로 복사 후 정독.
-- 처리 완료분은 각각 `completed/`로 이동한다.
-- 연결 리포 경로는 `.project/.env`, 리포 목록은 `.project/LINKED-REPOS.md`에 둔다.