lee-spec-kit 0.7.11 → 0.8.1

package/templates/en/common/features/feature-base/tasks.md

@@ -4,10 +4,10 @@
 
 - **Status**: `[TODO]` → `[DOING]` → `[DONE]`
 - **Task communication / confirmation**:
-  - `[TODO] → [DOING]`: share the task title first, then follow the latest `context --json-compact`
-  - `[DOING] → [DONE]`: share the result/verification first, then follow the latest `context --json-compact`
-  - If `approvalRequest.required=true`, wait for the exact CLI-provided label reply before changing task state.
-  - If `approvalRequest.required=false`, do not invent a separate `OK` approval step; update task state after real completion/verification.
+  - `[TODO] → [DOING]`: share the task title first, then update the task state in `tasks.md`
+  - `[DOING] → [DONE]`: share the result and verification first, then update `Acceptance` and `Checklist` in the same edit
+  - Ask for approval before changing task state only when the task crosses a documented review checkpoint or before remote/destructive actions.
+  - Do not invent a standalone `OK` approval step when the workflow does not require one.
   - `task-complete` rejects `[DONE]` while any item in that task's `Checklist` remains unchecked.
 - **PRD mapping (recommended)**: add an existing PRD requirement ID tag like `[PRD-FR-001]` or `[PRD-SCOPE-V1-DESKTOP-EDITOR]` to each task line, or tag non-PRD tasks as `[NON-PRD]`.
   - Do not invent PRD IDs in `tasks.md`. Only reference IDs that already exist in `docs/prd` or the upstream requirements doc.
@@ -81,7 +81,7 @@
 
 - [ ] All tasks are `[DONE]`, and each task's `Acceptance` is verified and `Checklist` is checked
 - [ ] Tests executed and passing (record command/result below)
-- [ ] Final outcome shared and user confirmation recorded according to the current `context` approval state
+- [ ] Final outcome shared and any required user confirmation recorded at the documented workflow checkpoint
 
 ### Test Run Log (Latest by Command)
 

package/templates/ko/common/README.md

@@ -11,23 +11,23 @@ npx lee-spec-kit onboard --strict
 # 1) 프로젝트 감지
 npx lee-spec-kit detect --json
 
-# 2) 감지 성공 시 컨텍스트 조회
-npx lee-spec-kit context --json-compact
+# 2) 감지 성공 시 워크플로우 정책 조회
+npx lee-spec-kit docs get agents --json
 ```
 
 - `isLeeSpecKitProject: true`일 때만 lee-spec-kit 워크플로우를 적용합니다.
-- `context --json-compact`는 read-only 상태 확인용으로 쓰고, 실제 실행/재개 기본 엔트리포인트는 `flow`를 사용합니다.
-- 승인 대기 여부는 항상 최신 `context --json-compact` / `flow --json-compact`를 기준으로 판단합니다.
-- `approvalRequest.required=true`일 때는 승인이 끝날 때까지 승인 상태를 유지합니다. 가능하면 `matchedFeature.currentSubstate*` 기반 현재 단계 한 줄 요약을 먼저 말하고, 그 다음 CLI가 준 승인 문구를 그대로 보여준 뒤 승인(`<LABEL>` 또는 `<LABEL> OK`)을 받은 후 실행합니다.
-- 명령 실행은 기본적으로 `npx lee-spec-kit flow <featureRef> --approve <LABEL> --execute`를 사용합니다.
-- `approvalRequest.required=false`이면 별도 라벨 승인 문구를 만들지 않습니다.
+- 기본 실행 경로는 workspace-scoped `AGENTS.md`, Codex 공식 hooks, 그리고 활성 feature 문서입니다.
+- 활성 feature를 정한 뒤에는 `spec.md`, `plan.md`, `tasks.md`, `decisions.md`를 작업 SSOT로 사용합니다.
+- 사용자 승인 요청은 문서화된 workflow checkpoint와 원격/파괴적 작업 전에만 합니다.
+- staged된 docs 경로 검사가 필요하면 `git commit` 전에 `npx lee-spec-kit commit-audit --json`를 사용합니다.
+- 코드나 feature 문서를 바꿨다면 종료 전 `npx lee-spec-kit workflow-audit --json`로 동기화 상태를 확인합니다.
 - `isLeeSpecKitProject: false`면 lee-spec-kit 전용 절차를 건너뛰고 일반 워크플로우로 진행합니다.
 
 ## 신규 프로젝트 시작 순서
 
 - 코드 프로젝트 스캐폴딩(예: Next.js/NestJS) 후 `lee-spec-kit init`을 실행하세요.
 - 그 다음 `docs/prd/`에 상위 요구사항을 정리하고, `idea`/`feature`로 작업 단위를 구체화하세요.
-- 이후 `detect --json`으로 감지 결과를 확인하고, `context` 순서로 진행하세요.
+- 이후 `detect --json`으로 감지 결과를 확인하고, `docs get agents --json`과 활성 feature 문서 기준으로 진행하세요.
 - 대부분의 경우(기본값: embedded) 위 순서만 따르면 됩니다.
 - docs를 코드 저장소와 분리해 운영할 때만 standalone을 선택하세요. 이때는 상위 워크스페이스 폴더(예: `workspace/docs`, `workspace/project`)에서 `init`을 실행해 docs/project 경로를 함께 지정하는 방식을 권장합니다. (예: `npx lee-spec-kit init --docs-repo standalone --dir ./docs --project-root ./project`)
 
@@ -77,7 +77,7 @@ npx lee-spec-kit context --json-compact
 - **Unmanaged docs 엔트리**: canonical surface 밖의 모든 `docs/` 최상위 엔트리
   - 예: `docs/plans/`, `docs/superpowers/`, 또는 다른 스킬이 만든 폴더
   - 이 문서들은 활성 워크플로우 SSOT가 아니라 staging/reference 입력으로만 취급합니다
-  - Feature가 활성화된 상태에서는 `context`가 `docs_normalize` 단계를 먼저 요구할 수 있으며, 정규화 또는 allowlist 등록 전까지 구현 진행을 막을 수 있습니다
+  - commit 전에 정규화하거나 allowlist에 넣어야 하며, `commit-audit`는 staged된 비정규 docs 경로를 차단합니다
   - 아래처럼 feature-local 문서로 정규화하세요:
     - design/spec 산출물 → `spec.md`, `plan.md`, `decisions.md`
     - implementation plan 산출물 → `plan.md`, `tasks.md`
@@ -117,7 +117,9 @@ npx lee-spec-kit context --json-compact
 - `docsRepo` ("embedded" | "standalone"): Docs 관리 방식
 - `pushDocs` (boolean, optional): `docsRepo: "standalone"`일 때만 생성 (원격 push 여부)
 - `docsRemote` (string, optional): `pushDocs: true`일 때만 생성 (원격 레포 URL)
-- `approval` (object, optional): `context` 출력의 `[확인 필요]` / `requiresUserCheck` 정책 오버라이드
+- `approval` (object, optional): repo 정책/커스텀 validator용 승인 checkpoint 메타데이터
+  - 기본 Codex-native 경로는 여전히 문서화된 checkpoint와 원격/파괴적 작업을 우선 기준으로 승인 요청합니다.
+  - legacy runtime은 이 필드를 직접 소비했지만, 이제는 category 기반 checkpoint 메타데이터가 정말 필요할 때만 유지하세요.
   - 현재 기본값:
     - `mode: "category"`
     - `default: "skip"`

package/templates/ko/common/agents/agents.md

@@ -1,108 +1,55 @@
 # Agents Guide
 
 코드 어시스턴트/에이전트 운영 규칙입니다.
-이 문서는 **정책(강제 규칙)만** 다룹니다.
+이 문서는 커스텀 런타임이 아니라 워크플로우 정책만 정의합니다.
 
 ---
 
-## 🚨 사용자 승인 처리 규칙 (MUST)
+## 감지 게이트
 
-사용자 확인 필수 규칙입니다.
+- 항상 먼저 `npx lee-spec-kit detect --json`를 실행합니다.
+- `status === "ok"` 이고 `isLeeSpecKitProject === true`일 때만 lee-spec-kit 규칙을 적용합니다.
+- 감지 실패 또는 false면 lee-spec-kit 전용 규칙을 건너뛰고 일반 워크플로우로 진행합니다.
 
-> ⚠️ 액션 종류만 보고 승인 필요 여부를 판단하지 마세요. workflow 승인 대기 여부는 항상 최신 `context --json-compact` / `flow --json-compact` 출력으로 결정합니다.
-> ✅ 승인 대기 상태에서는 응답 형식이 항상 `<라벨>` 또는 `<라벨> OK` 형식(예: `A`, `A OK`)입니다.
-> ℹ️ 기본 정책에서 주요 workflow 승인 경계는 `spec_approve`, `implementation_approve` 두 곳입니다. 프로젝트 config가 추가 경계를 둘 수 있습니다.
-> ℹ️ 일부 원격 helper 명령은 `--confirm OK` 같은 명시 확인을 별도로 요구합니다. 이 command-level confirm은 라벨 기반 workflow 승인과 별개입니다.
+## 기본 실행 경로
 
-현재 액션이 승인 대기 상태라면, 실행 전에 해당 내용을 공유하세요:
+- 기본 실행은 workspace-scoped `AGENTS.md`와 Codex 공식 hooks를 우선 사용합니다.
+- 사용자가 "규칙에 따라 다음 feature를 진행해라"처럼 일반적으로 말해도 이 워크플로우로 자동 해석합니다.
 
-| 현재 액션 예시 | 공유 내용 |
-| --- | --- |
-| spec / plan / tasks 검토 | 검토 대상 문서 또는 정확한 섹션 |
-| 태스크 완료 / 최종 체크리스트 | 결과와 검증 근거 |
-| 커밋 / push / merge | 커밋 메시지, 포함 파일, 브랜치 |
-| 이슈 생성 | `npx lee-spec-kit github issue <featureRef> --create` 전 |
-| PR 생성 | `npx lee-spec-kit github pr <featureRef> --create` 전 |
-| Assignee 변경 | 대상 사용자명 |
-
-확인 절차:
-1. 작업 내용을 먼저 공유
-2. 최신 `context --json-compact` 기준으로 승인 대기 여부(`approvalRequest.required`) 확인
-3. 승인 대기 상태면 CLI가 준 승인 문구 그대로 라벨 응답을 기다리고, 비승인 상태면 별도 승인 문구를 만들지 않음
-4. 승인 후 실행 (명령 실행은 기본적으로 `npx lee-spec-kit flow <featureRef> --approve <LABEL> --execute`를 사용)
-
-금지:
-- 사용자 응답 없이 임의 진행
-
----
-
-## 🧾 라벨 응답 계약 (SSOT)
-
-- 승인 대기 상태를 별도 상태로 취급합니다. 승인 대기란 최신 `context --json-compact` / `flow --json-compact`(fallback: `context --json` / `flow --json`)에 `approvalRequest.required=true`가 나타난 경우를 의미합니다.
-- 승인 대기 여부를 대화 분위기, action type, 또는 `actionOptions[]` 존재만으로 추정하지 마세요.
-- 기준 데이터는 최신 `npx lee-spec-kit context --json-compact`를 기본으로 사용하고, 상세 필드가 필요할 때만 `context --json` 또는 `flow --json`을 사용합니다. (`flow`는 기본적으로 `--json-compact` 우선)
-- `flow --json-compact`(또는 `flow --json`)의 auto 결과를 사용할 때는 `autoRun.resume.flowCommand`를 재개 SSOT로 사용합니다. (컨텍스트 압축/리셋 후 동일 규칙 적용)
-- `AUTO_DELEGATED_HANDOFF`는 delegated run 일시정지 상태이며 실패가 아닙니다. 같은 승인 라벨을 다시 열지 말고 delegated 경로를 이어서 진행하거나 재개합니다.
-- `AUTO_MANUAL_REQUIRED`는 instruction-only 자동화 경계 상태이며 실패 단정 신호가 아닙니다. `context --json-compact` 재확인 후 `approvalRequest.required` 기준으로 멈춤/보고를 판단합니다. (상세 디버깅 필드가 필요할 때만 `context --json`)
-- 예외: `matchedFeature.currentSubstateId === "change_request_sync"`이거나 `matchedFeature.pendingChangeRequest`가 있으면, 이 manual boundary는 우선 사용자 보고용 정지가 아니라 내부 docs-sync 단계로 취급합니다. 문서를 먼저 동기화하고 pending change 필드를 비운 뒤 최신 `context --json-compact` 또는 `flow`로 계속 진행하세요.
-- `AUTO_SELECTION_REQUIRED`는 feature 선택 경계 일시정지 상태이며 실행 실패가 아닙니다. 먼저 활성 feature 선택을 해소한 뒤 최신 `context --json-compact` 또는 `flow`로 이어서 진행합니다.
-- 승인 대기 상태에서 `matchedFeature.currentSubstateId`가 있으면 `matchedFeature.currentSubstateId/currentSubstateOwner/currentSubstatePhase`에서 가져온 현재 단계 한 줄 요약을 먼저 붙입니다.
-- 그 다음 `context --json-compact`의 `approvalRequest.userFacingLines`를 우선 그대로 보여주세요. 전체 `--json`을 쓸 때만 `actionOptions[*].approvalPrompt`와 `approvalRequest.finalPrompt` 조합으로 폴백합니다. 이 사이에 에이전트가 임의로 다시 쓴 라벨 요약을 끼워 넣지 않습니다.
-- 위임 판단 SSOT는 `matchedFeature.currentSubstateOwner`와 `agentOrchestration.subAgentHandoff`를 우선 사용하세요.
-- 비승인 상태의 진행 보고/분석/일반 답변에서는 라벨 블록이나 `approvalRequest.finalPrompt`를 덧붙이지 않습니다. 현재 옵션을 사용자가 직접 물었을 때만 예외입니다.
-- 관련 없는 질문에 먼저 답한 뒤에도 승인이 여전히 필요하면, 먼저 `approvalRequest.required`를 다시 확인하고 여전히 `true`일 때만 현재 단계 한 줄 요약과 함께 CLI가 준 승인 문구(`approvalRequest.userFacingLines`, 또는 전체 `--json`의 `actionOptions[*].approvalPrompt` + `approvalRequest.finalPrompt`)를 다시 제시합니다.
-- 사용자 입력에 유효 라벨이 없으면 실행하지 말고 라벨 선택을 다시 요청합니다.
-- 위임 대상이 아닌 command 옵션은 `flow --approve <LABEL> --execute` 1회 호출을 기본으로 하며, `context --approve`와 `context --execute --ticket`를 턴/세션 사이로 분리하지 않습니다.
-- `matchedFeature.currentSubstateOwner="subagent"`이고 `agentOrchestration.subAgentHandoff.required=true`이며 `mode="command"`면 위임이 필수입니다. 먼저 `spawn_agent`를 호출하고, 해당 명령을 메인 에이전트에서 직접 실행하지 않습니다.
-- 그 delegated command가 handoff-only(`handoffOnly=true`, `advancesWorkflow=false`)라면 `--execute`는 handoff 준비까지만 의미합니다. 바로 delegated work를 이어서 수행하고 같은 라벨을 다시 승인 루프로 열지 마세요.
-- `autoRun.available`만으로 auto 루프 위임을 결정하지 않습니다. `agentOrchestration.subAgentHandoff.required=true`이고 `agentOrchestration.subAgentHandoff.mode="auto_run"`일 때만 auto 루프를 서브 에이전트에 위임합니다.
-- 위임 시에는 `agentOrchestration.subAgentHandoff`를 handoff SSOT로 사용하고, 최소 필드(`featureRef`, `category`, `cwd`, `cmd`)만 전달합니다.
-- 위임 실행 전 `subAgentHandoff.verify`의 검증 명령(`pwd`, `git rev-parse --show-toplevel`)을 세션당 1회만 실행하고(`verify.cacheKey` 기준), 불일치 시 즉시 중단/보고합니다. 상세 로그 수집은 불일치 시에만 수행합니다.
-- 메인 에이전트 fallback은 서브 에이전트 실행이 불가능한 경우(예: 도구 미지원, spawn 실패, 명령 실행 전 서브 에이전트 실패)에만 허용합니다.
-- fallback을 사용할 때는 메인 실행 전에 fallback 사유를 사용자에게 한 줄로 먼저 알립니다.
-
-승인 대기 상태 출력은 CLI가 제공한 승인 문구를 그대로 재사용해야 합니다. `matchedFeature.currentSubstate*`에서 가져온 간단한 현재 단계 한 줄 요약은 앞에 붙일 수 있지만, 그 외에 CLI가 주지 않은 `현재 상태:` / `선택 가능:` 같은 라벨 요약 래퍼를 임의로 만들어 붙이지 마세요.
-
----
-
-## 📚 내장 문서 조회 규칙 (MUST)
+## 문서가 SSOT
 
-- `docs get`은 세션 시작(또는 context 압축/리셋 직후) 기준으로 1회 확인합니다.
-- 같은 세션에서 이미 읽은 동일 문서는 다시 읽지 않습니다.
-- 현재 액션의 `requiredDocs[*].command` 중 이번 세션에 아직 읽지 않은 문서만 추가 조회합니다.
-- 아래 경우에는 예외적으로 재조회할 수 있습니다:
-  - 사용자가 정책 새로고침을 요청한 경우
-  - `update` 실행 등으로 정책/설정이 변경된 경우
-  - 세션이 새로 시작되었거나 context 압축/리셋이 발생한 경우
+- 세션 시작 시점이나 context 리셋 직후 `npx lee-spec-kit docs get agents --json`를 1회 읽습니다.
+- 응답의 `requiredDocs[*].command` 중 아직 읽지 않은 문서를 모두 확인합니다.
+- 활성 feature를 정한 뒤에는 해당 feature 폴더를 작업 SSOT로 사용합니다.
+- 최소 기준 문서는 `spec.md`, `plan.md`, `tasks.md`, `decisions.md`입니다.
+- GitHub 워크플로우가 얽히면 `issue.md`, `pr.md`도 함께 봅니다.
+- 활성 feature 문서를 읽은 뒤에는 `npx lee-spec-kit workflow-stage <featureRef> --json`를 실행하고, 그 `nextAction`만 따릅니다.
 
----
+## 실행 규칙
 
-## 필수 참조
+- lee-spec-kit은 문서 구조, workflow 단계, validator를 담당합니다.
+- Codex는 실행 루프, 도구 사용, hook lifecycle을 담당합니다.
+- `workflow-stage --json`가 `stage === "implementation"`이고 `implementationAllowed === true`를 반환하기 전에는 구현을 시작하지 않습니다.
+- spec / plan / tasks 승인, issue 생성, branch 생성은 구현 전 하드 게이트로 취급합니다.
+- 동작이나 범위가 바뀌는 코드 변경이 있으면 같은 턴 안에서 feature 문서를 같이 동기화합니다.
+- staged된 docs 경로 검사가 필요하면 `git commit` 전에 `npx lee-spec-kit commit-audit --json`를 사용합니다.
+- 기본 docs sync 검사는 `npx lee-spec-kit workflow-audit --json`를 사용합니다.
 
-- 최우선 규칙: `/docs/agents/custom.md`
-- 프로젝트 원칙: `/docs/agents/constitution.md`
-- 루트 가이드: `npx lee-spec-kit docs get agents --json`
-- Git 워크플로우: `npx lee-spec-kit docs get git-workflow --json`
-- 태스크 실행: `npx lee-spec-kit docs get execute-task --json`
-- 이슈 절차/문서: `npx lee-spec-kit docs get create-issue --json` → `npx lee-spec-kit docs get issue-doc --json`
-- PR 절차/문서: `npx lee-spec-kit docs get create-pr --json` → `npx lee-spec-kit docs get pr-doc --json`
-
----
+## 승인 규칙
 
-## 범위 분리
+사용자 확인 필수 규칙을 항상 먼저 적용합니다.
 
-- docs 구조/경로 규칙: `docs/README.md`를 SSOT로 사용
-- canonical docs surface는 `docs/README.md`에 정의된 `docs/` 최상위 엔트리만을 의미합니다. allowlist에 없는 추가 `docs/*` 최상위 엔트리는 unmanaged docs로 취급합니다.
-- `docs/plans/*`, `docs/superpowers/*`, 또는 다른 스킬이 만든 docs 폴더 같은 unmanaged docs는 staging/reference 입력으로만 취급합니다. Feature가 활성화되어 있으면 해당 내용을 Feature 문서로 흡수하고, 최종 SSOT는 Feature 폴더로 봅니다.
-- `context`에 `docs_normalize` action/category가 나타나면, 구현이나 다른 workflow action보다 먼저 그 정규화 단계를 완료하세요.
-- ADR 작성 형식: `docs/features/.../decisions.md` 템플릿을 SSOT로 사용
-- 이슈/PR 실행 상태: 각 Feature의 `issue.md`, `pr.md`를 SSOT로 사용
+| 현재 액션 예시 | 공유 내용 |
+| --- | --- |
+| 이슈 생성 | `npx lee-spec-kit github issue <featureRef> --create` 전 |
+| PR 생성 | `npx lee-spec-kit github pr <featureRef> --create` 전 |
 
----
+- 문서화된 workflow checkpoint와 원격/파괴적 작업 전에만 사용자 승인을 요청합니다.
+- `workflow-stage --json`가 `approvalRequired === true`를 반환하면 그 checkpoint에서 멈추고 사용자 승인을 받습니다.
+- GitHub 원격 작업 전에는 올릴 artifact나 계획을 먼저 공유합니다.
 
-## 언어/표기 규칙
+## 표기 규칙
 
 - 답변: 한국어
 - 코드/파일명: 영어
-- 주석/커밋메시지: 한국어
-- 날짜/시간: 사용자 PC 시스템 시간 사용
+- 날짜/시간: 사용자 로컬 시스템 시간

package/templates/ko/common/agents/skills/create-feature.md

@@ -1,62 +1,36 @@
-# 기능 구현 프로세스: CLI 주도형
+# 기능 구현 프로세스: Docs-first
 
-이 문서는 새 기능(Feature)을 추가할 때 따르는 **유일한 규칙**입니다.
-에이전트는 자신의 판단을 신뢰하지 않고, 오직 **CLI 도구의 지시**에 따라 행동합니다.
+이 가이드는 Codex-native lee-spec-kit 경로에서 feature를 시작하거나 이어갈 때 따르는 기준입니다.
 
 ---
 
-## 🔄 The Loop (무한 반복)
-
-Feature 구현이 완료될 때까지(문서 커밋까지) 다음 과정을 **계속 반복**하세요.
-
-### 1단계: 상태 확인
-
-작업을 시작하거나 한 단계를 마칠 때마다 **반드시** 아래 명령어를 실행합니다.
-
-```bash
-npx lee-spec-kit context
-```
-
-### 2단계: 지시 수행 (Next Options)
-
-CLI가 출력하는 **`👉 Next Options (Atomic)` 목록에서 단 하나의 옵션(A/B/C)을 선택**해 수행합니다.
-승인이 필요한 작업은 사용자에게 공유한 뒤 **`<라벨>` 또는 `<라벨> OK` 응답(예: `A`, `A OK`)**을 받은 옵션만 실행합니다.
-
-- **승인 대기(Review)** 상태라면 사용자에게 공유하고 멈춥니다.
-- CLI가 파일 작성을 지시하면 해당 파일을 작성합니다.
-- CLI가 이슈 생성을 지시하면 이슈를 생성합니다.
-- CLI가 명령어를 출력하면 **그대로 복사해 실행**합니다. (standalone 환경에서도 레포 경로가 포함될 수 있습니다)
-- 승인 요청 시 라벨 옵션은 `A: ...` 형식으로 **CLI가 출력한 원문(detail/cmd) 그대로** 공유합니다. 요약/의역하지 않습니다.
-- 승인된 command 옵션을 실행할 때는 세션 불일치 방지를 위해 `npx lee-spec-kit flow <slug|F001|F001-slug> --approve <LABEL> --execute`를 기본으로 사용합니다.
-
-### 3단계: 반복
-
-지시된 행동을 완료했다면, **즉시 1단계로 돌아가** 다시 `context`를 확인합니다.
-
----
-
-## 🛑 절대 금지 사항 (Strict Rules)
-
-1. **앞서가지 않기**: CLI가 "Spec 작성"을 지시했는데 "Plan 작성"까지 한 번에 하지 마세요.
-2. **건너뛰지 않기**: "이슈 생성" 단계를 귀찮아서 생략하거나 가짜 번호를 넣지 마세요.
-3. **스스로 판단 금지**: "이 정도면 됐겠지?"라고 생각하지 말고 CLI에게 물어보세요.
-
-> 참고: 워크플로우 단계는 변경될 수 있으므로, “단계 번호”를 외우지 마세요.
-> **항상 `context` 출력만**을 SSOT로 따르세요.
-
----
-
-## 시작하기
-
-아직 기능 폴더가 없다면, 먼저 폴더를 생성하고 루프를 시작하세요:
-
-- 사용자의 요청에 `I001`, `I001-slug`, `docs/ideas/...` 같은 **명시적 Idea ref**가 있으면, 일반 생성 대신 해당 ref를 유지해서 `npx lee-spec-kit feature <name> --idea <ref>`를 사용합니다.
-- 이 경우 Idea를 추정하지 않습니다. 요청에 명시된 ref가 있을 때만 `--idea`를 붙입니다.
-
-```bash
-# 1. 생성
-npx lee-spec-kit feature <name> -d "<설명>"
-
-# 2. 루프 진입
-npx lee-spec-kit context
-```
+## 시작
+
+1. `npx lee-spec-kit detect --json`를 실행합니다.
+2. 감지되면 `npx lee-spec-kit docs get agents --json`과 아직 읽지 않은 후속 문서를 확인합니다.
+3. 아직 feature 폴더가 없다면:
+   - 사용자가 실제로 `I001`, `I001-slug`, `docs/ideas/...` 같은 explicit Idea ref를 말한 경우에만 그 ref를 유지합니다
+   - 그럴 때만 `npx lee-spec-kit feature <name> --idea <ref>`를 사용합니다
+   - 그 외에는 `npx lee-spec-kit feature <name> -d "<설명>"`으로 생성합니다
+4. 활성 feature를 정하고 `spec.md`, `plan.md`, `tasks.md`, `decisions.md`를 읽습니다.
+5. 다음 workflow 액션을 시작하기 전에 `npx lee-spec-kit workflow-stage <feature-ref> --json`를 실행합니다.
+
+## 작업 규칙
+
+- 문서가 SSOT입니다. 활성 feature 문서를 직접 따라갑니다.
+- 문서 단계는 직접 따라갑니다:
+  - `spec.md`는 범위와 리뷰 상태를 정의합니다
+  - `plan.md`는 구현 접근을 정의합니다
+  - `tasks.md`는 실제 실행 순서를 정의합니다
+  - `issue.md`, `pr.md`는 GitHub 단계에 들어가면 stage gate의 일부로 사용합니다
+- `tasks.md`가 있다고 바로 구현하지 않습니다. 구현은 `workflow-stage --json`가 허용할 때만 시작합니다.
+- 범위나 동작이 바뀌면 같은 턴 안에서 활성 feature 문서를 같이 업데이트합니다.
+- 사용자 승인은 문서화된 review checkpoint와 원격/파괴적 작업 전에만 요청합니다.
+- docs 경로 검사가 중요하면 `git commit` 전에 `npx lee-spec-kit commit-audit --json`를 사용합니다.
+- 코드나 feature 문서를 바꿨다면 종료 전에 `npx lee-spec-kit workflow-audit --json`로 동기화 상태를 확인합니다.
+
+## 절대 규칙
+
+1. 이슈/PR 번호나 상태를 임의로 만들지 않습니다.
+2. 범위, 동작, evidence가 바뀌었는데 필요한 문서 업데이트를 건너뛰지 않습니다.
+3. unmanaged docs 산출물은 feature 폴더로 정규화하거나 allowlist하기 전까지 active workflow SSOT로 취급하지 않습니다.

package/templates/ko/common/agents/skills/create-issue.md

@@ -8,7 +8,10 @@ GitHub Issue를 생성할 때 따르는 가이드입니다.
 ## 사전 조건
 
 - [ ] `spec.md` 작성 완료
-- [ ] 최신 `context --json-compact` 확인
+- [ ] `plan.md` 작성 완료
+- [ ] `tasks.md` 작성 완료 및 execution-ready
+- [ ] 활성 feature 문서 검토
+- [ ] `npx lee-spec-kit workflow-stage <feature-ref> --json` 결과가 issue 준비 또는 issue 생성 단계여야 함
 
 ---
 
@@ -38,9 +41,7 @@ npx lee-spec-kit github issue F001 --json
 | 라벨   | `enhancement`, `bug`, `documentation` 등 |
 | 담당자 | `@me` (기본값)                           |
 
-### 2. `Ready` 전환 (context가 요구할 때만 승인 요청)
-
-> ⚠️ **workflow 라벨 승인은 조건부입니다**
+### 2. `Ready` 전환
 
 `issue.md` 초안 기준으로 다음 내용을 공유하세요:
 
@@ -48,16 +49,13 @@ npx lee-spec-kit github issue F001 --json
 - 본문 전체 초안 (`issue.md` 기준)
 - 라벨
 
-그 다음 최신 `npx lee-spec-kit context --json-compact`를 다시 확인합니다.
-
-- `approvalRequest.required=true`이면 CLI가 준 승인 문구를 그대로 보여주고 라벨 응답(`A` 또는 `A OK`)을 기다린 뒤 계속 진행합니다.
-- `approvalRequest.required=false`이면 별도 라벨 승인 문구를 만들지 말고, 초안을 다듬은 뒤 `issue.md` 상태를 `Ready`로 변경합니다.
+초안을 다듬은 뒤 `issue.md` 상태를 `Ready`로 변경합니다.
 
 ### 3. 이슈 생성 (`issue.md`가 `Ready`일 때)
 
 원격 이슈 생성은 반드시 lee-spec-kit helper로만 실행합니다.
 `gh issue create`를 직접 호출하거나 raw `issue.md`를 그대로 `--body-file`에 넘기지 마세요.
-workflow 라벨 승인과 별개로, 원격 생성 command 자체의 명시 확인은 계속 필요합니다.
+원격 생성 command 자체의 명시 확인은 항상 필요합니다.
 
 - 최종 제목/본문/라벨을 사용자에게 공유하고
 - 그 다음 `--confirm OK`를 붙여 helper를 실행하세요
@@ -69,6 +67,7 @@ npx lee-spec-kit github issue F001 --create --confirm OK --labels enhancement
 생성 후:
 - 생성된 이슈 번호를 `tasks.md`에 기록
 - `issue.md` 상태는 `Ready`로 유지 (생성 상태는 `tasks.md`에서 관리)
+- 바로 구현으로 가지 말고 `npx lee-spec-kit workflow-stage <feature-ref> --json`를 다시 실행해 반환된 다음 단계부터 이어갑니다
 
 ---
 
@@ -76,6 +75,6 @@ npx lee-spec-kit github issue F001 --create --confirm OK --labels enhancement
 
 - **초안 생성기**: `npx lee-spec-kit github issue <feature-name>`
 - **원격 생성 규칙**: 반드시 `npx lee-spec-kit github issue <feature-name> --create --confirm OK --labels ...` 사용
-- **workflow 승인 규칙**: `approvalRequest.required=true`일 때만 라벨 승인을 기다립니다
+- **workflow 승인 규칙**: 원격 issue 생성 전에는 항상 사용자 승인을 받습니다
 - **원격 확인 규칙**: 제목/본문/라벨 공유 후 `--create --confirm OK` 실행
 - **실행 상태 SSOT**: `docs/features/.../<feature>/issue.md`

package/templates/ko/common/agents/skills/create-pr.md

@@ -9,6 +9,7 @@ Pull Request를 생성할 때 따르는 가이드입니다.
 
 - [ ] 모든 태스크 `[DONE]` 상태
 - [ ] `tasks.md`의 "완료 조건" 체크리스트 모두 체크
+- [ ] `npx lee-spec-kit workflow-stage <feature-ref> --json` 결과가 PR 준비 또는 PR 생성 단계여야 함
 - [ ] 변경 사항 커밋 완료
 - [ ] 브랜치 푸시 완료
 
@@ -22,7 +23,7 @@ Pre-PR 리뷰에서 항상 수행하는 최소 기준입니다. 가능한 경우
 2. 회귀/예외 처리, 크리티컬·보안 리스크, 사이드 이펙트, 사용자 흐름 영향, 배포 준비도를 점검합니다.
 3. 유지보수성을 점검합니다: 큰 함수/파일은 필요 시 분리하고, 기존 코드 재사용·통합 가능성을 확인하며, 불필요해진 코드를 정리합니다.
 4. 현재 구현이 `spec.md` / `plan.md` / `tasks.md`에 기록된 feature 의도와 범위에 실제로 맞는지 평가합니다.
-5. `workflow.prePrReview.evidenceMode=path_required`(기본)일 때는 리뷰 에이전트를 먼저 실행해 `review-trace.json`을 만든 뒤 `npx lee-spec-kit pre-pr-review <feature-ref> --evidence review-trace.json`을 실행합니다. `evidenceMode=any`에서는 실행 증거 강제가 없는 한 `--evidence` 없이 직접 기록하는 경로도 허용됩니다.
+5. `workflow.prePrReview.evidenceMode=path_required`(기본)일 때는 승인 전에 `review-trace.json` 같은 실제 리뷰 산출물을 남깁니다. `evidenceMode=any`에서는 실행 증거 강제가 없는 한 별도 산출물 없이 직접 기록하는 경로도 허용됩니다.
 6. `PR 전 리뷰 Evidence`는 설정된 evidence 정책을 따라야 합니다. `path_required`일 때는 실제 존재하는 문서 경로를 사용합니다.
 7. `Summary`, `Feature Intent Summary`, `Implementation Fit`, `Missing Cases`, `Spec Alignment Checked`, `Finding Count`, `Blocking Findings`, `Findings`, `Residual Risks`를 placeholder 없이 기록합니다.
 8. 리뷰 중에 audit/타깃 검증 명령을 실제로 실행했다면 그때만 `commandsExecuted`에 기록합니다.
@@ -145,9 +146,7 @@ echo \"![](https://github.com/${REPO}/releases/download/${TAG}/ui-1.png)\"
 - PR 본문에 Mermaid **`sequenceDiagram`**을 작성하고, 생성된 본문 템플릿 형식과 일치하게 유지합니다.
 - 이 기준은 프론트/백엔드 구분이 아니라 변경 유형(로직/구조) 기준으로 적용합니다.
 
-### 4. `Ready` 전환 (context가 요구할 때만 승인 요청)
-
-> ⚠️ **workflow 라벨 승인은 조건부입니다**
+### 4. `Ready` 전환
 
 PR 생성 전 다음 내용을 **코드블록으로** 사용자에게 공유하세요:
 
@@ -155,18 +154,13 @@ PR 생성 전 다음 내용을 **코드블록으로** 사용자에게 공유하
 - 본문 전체 템플릿 (`pr.md` 기준)
 - 라벨(최소 1개, 비워둘 수 없음)
 
-그 다음 최신 `npx lee-spec-kit context --json-compact`를 다시 확인합니다.
-
-- `approvalRequest.required=true`이면 CLI가 준 `<라벨>` 또는 `<라벨> OK` 응답을 기다립니다.
-- `approvalRequest.required=false`이면 별도 라벨 승인 문구를 만들지 않습니다.
-
 이후 `pr.md`의 변경 사항/테스트 섹션을 실제 작업 기준으로 보완하고 `Ready`로 변경하세요.
 
 ### 5. PR 생성 (`pr.md`가 `Ready`일 때)
 
 원격 PR 생성은 반드시 lee-spec-kit helper로만 실행합니다.
 `gh pr create`를 직접 호출하거나 raw `pr.md`를 그대로 `--body-file`에 넘기지 마세요.
-workflow 라벨 승인과 별개로, 원격 생성 command 자체의 명시 확인은 계속 필요합니다.
+원격 생성 command 자체의 명시 확인은 항상 필요합니다.
 
 - 최종 제목/본문/라벨을 사용자에게 공유하고
 - 그 다음 `--confirm OK`를 붙여 helper를 실행하세요
@@ -179,6 +173,7 @@ npx lee-spec-kit github pr F001 --create --confirm OK --labels enhancement
 - 생성된 PR 링크를 `tasks.md`에 기록
 - PR 상태를 `Review`로 기록/유지
 - `pr.md` 상태는 `Ready`로 유지 (생성/머지 상태는 `tasks.md`의 PR/PR 상태로 관리)
+- `npx lee-spec-kit workflow-stage <feature-ref> --json`를 다시 실행하고 반환된 review/merge 단계로 이어갑니다
 
 ---
 
@@ -221,6 +216,6 @@ PR 본문의 파일 링크는 **현재 브랜치명**을 사용:
 
 - **본문 템플릿 생성기**: `npx lee-spec-kit github pr <feature-name>`
 - **원격 생성 규칙**: 반드시 `npx lee-spec-kit github pr <feature-name> --create --confirm OK --labels ...` 사용
-- **workflow 승인 규칙**: `approvalRequest.required=true`일 때만 라벨 승인을 기다립니다
+- **workflow 승인 규칙**: 원격 PR 생성 또는 merge 전에 사용자 승인을 받습니다
 - **원격 확인 규칙**: 제목/본문/라벨 공유 후 `--create --confirm OK` 실행
 - **실행 상태 SSOT**: `docs/features/.../<feature>/pr.md`

package/templates/ko/common/agents/skills/execute-task.md

@@ -1,117 +1,50 @@
-# 태스크 실행 프로세스: CLI 주도형
+# 태스크 실행 프로세스: Docs-first
 
-기능 구현(tasks.md) 단계에서 태스크를 하나씩 실행할 때 따르는 가이드입니다.
-에이전트는 자신의 판단을 신뢰하지 않고, 오직 **CLI 도구의 지시**에 따라 행동합니다.
+활성 feature 폴더를 실행 SSOT로 사용하세요.
 
 ---
 
-## 🔄 The Execution Loop (실행 반복)
+## 1. 현재 태스크 선택
 
-모든 태스크가 완료될 때까지(`[DONE]`) 다음 과정을 **계속 반복**하세요.
+- 코드를 건드리기 전에 `npx lee-spec-kit workflow-stage <feature-ref> --json`를 실행합니다.
+- 반환값이 `stage === "implementation"`이고 `implementationAllowed === true`일 때만 구현을 계속합니다.
+- 먼저 활성 feature를 정합니다.
+- `tasks.md`에서:
+  - 이미 `[DOING]`인 태스크가 하나 있으면 그것을 이어서 수행하고
+  - 없으면 가장 우선순위가 높은 `[TODO]` 태스크를 `[DOING]`으로 바꿉니다
+- 한 번에 하나의 태스크만 진행합니다.
 
-### 1단계: 할 일 확인
+## 2. 실행과 기록
 
-작업을 시작하거나 하나를 마칠 때마다 **반드시** 아래 명령어를 실행합니다.
+- `tasks.md`를 현실과 맞게 유지합니다:
+  - 실제 완료/검증 없이 `[DONE]`로 바꾸지 않습니다
+  - 태스크를 닫을 때는 같은 수정에서 `Acceptance`와 `Checklist`도 함께 갱신합니다
+  - 완료된 태스크에 후속 작업이 생기면 히스토리를 고치지 말고 새 태스크를 추가합니다
+- 새 태스크를 추가해야 한다면 우선 `npx lee-spec-kit task add <feature-ref> --title "..." --ref NON-PRD|PRD-*`를 사용하세요.
+- 새 태스크에 placeholder `Acceptance` 또는 `Checklist`를 남기지 않습니다.
 
-```bash
-npx lee-spec-kit context
-```
+## 3. 문서 동기화
 
-### 2단계: 태스크 수행 (Action)
+- `spec.md`: 사용자-visible scope 또는 acceptance criteria가 바뀌면 갱신합니다
+- `plan.md`: 아키텍처, 파일 구조, 테스트 전략이 바뀌면 갱신합니다
+- `decisions.md`: 비자명한 결정, 트레이드오프, 호환성 처리, 사용자 요청으로 바뀐 동작을 기록합니다
+- `대기 중 변경 요청`이 있으면 먼저 `tasks.md`에 반영하고, 관련 문서를 맞춘 뒤 필드를 비우고 구현을 이어갑니다
 
-CLI가 가리키는 **Active Task** 또는 **`👉 Next Options (Atomic)`의 단일 옵션**을 수행합니다.
+## 4. 커밋과 종료 가드레일
 
-- **[DOING] 상태인 태스크가 있다면**: 해당 태스크를 최우선으로 완료하세요.
-- 태스크 상태 전환 규칙은 `tasks.md`의 **"태스크 규칙"** 섹션을 SSOT로 따릅니다.
-- 승인 대기 여부는 `context --json-compact`의 `approvalRequest.required`를 SSOT로 따릅니다. (`--json`은 상세 디버깅이 필요할 때만 사용) `false`면 라벨 승인 없이 진행하고, `true`면 라벨 규칙(`A`, `A OK`)으로 승인 후 진행합니다.
-- 기본 실행 모델은 **메인 에이전트 오케스트레이션 + 서브에이전트 소유 run 상태의 우선 위임 실행**입니다. `context --json-compact`에 `matchedFeature.currentSubstateId/currentSubstateOwner/currentSubstatePhase`가 있으면 그것을 실행 상태 SSOT로 사용합니다.
-- 메인 에이전트는 승인 경계, 상태 전이, record/commit 단계, 원격 작업을 담당합니다. `subagent` 소유 command substate(예: `task_run`, `pre_pr_review_run`, `code_review_run`, auto-run handoff command)는 서브 에이전트 실행이 기본입니다.
-- `pre_pr_review`는 `pre_pr_review_run`(서브 에이전트 리뷰 실행)과 `pre_pr_review_record`(메인 에이전트의 결과 기록)로 분리됩니다.
-- PR 리뷰도 같은 패턴입니다. `code_review_run`은 서브 에이전트 리뷰/수정 실행 상태이고, push/merge/최종 결정은 메인 에이전트 finalize 상태에 남깁니다.
-- 위임 판단은 `matchedFeature.currentSubstateOwner`와 `agentOrchestration.subAgentHandoff`를 SSOT로 우선 사용하세요.
-- `matchedFeature.currentSubstateOwner="subagent"`이고 `agentOrchestration.subAgentHandoff.required=true`이며 `mode="command"`면 위임이 필수입니다. 먼저 `spawn_agent`를 호출하고, 해당 명령을 메인 에이전트에서 직접 실행하지 않습니다.
-- `autoRun.available`만으로 auto 루프 위임을 결정하지 않습니다. `agentOrchestration.subAgentHandoff.required=true`이고 `agentOrchestration.subAgentHandoff.mode="auto_run"`일 때만 auto 루프를 서브 에이전트에 위임합니다.
-- `agentOrchestration.subAgentHandoff`를 최소 handoff 계약(`featureRef`, `category`, `cwd`, `cmd`)으로 사용합니다.
-- action option에 `handoffOnly=true`와 `advancesWorkflow=false`가 있으면 `--execute` 성공을 workflow 전진으로 간주하지 않습니다. delegated work와 필요한 evidence/state 갱신을 끝낸 뒤에 다시 `context`를 실행합니다.
-- `subAgentHandoff.verify.commands`(`pwd`, `git rev-parse --show-toplevel`)은 `verify.cacheKey` 기준 세션당 1회만 실행합니다. 불일치 시 즉시 중단/보고하고, 상세 로그는 불일치 시에만 수집합니다.
-- 메인 에이전트 fallback은 서브 에이전트 실행이 불가능한 경우(예: 도구 미지원, spawn 실패, 명령 실행 전 서브 에이전트 실패)에만 허용합니다. fallback 실행 전에는 사유를 사용자에게 한 줄로 먼저 알립니다.
-- `context --json-compact`에서 `autoRun.available=true`일 때만 `autoRun.command`를 사용해 자동 루프를 시작합니다.
-- `autoRun.policyEligible=true`이지만 `autoRun.executableNow=false`이면 auto 루프를 시작하지 말고 `autoRun.manualBoundary`를 먼저 처리합니다.
-- 장시간 자동 실행이 필요하면 `flow <feature> --auto-... --start-auto --json-compact`으로 run id를 생성하고, 중단/압축 후에는 `autoRun.run.resumeCommand`(`flow --resume <RUN_ID>`)를 우선 사용해 재개합니다. (상세 디버깅 필드가 필요할 때만 `--json`)
-- auto 실행이 중단되면 `flow --json-compact`(또는 `flow --json`)의 `autoRun.resume`를 SSOT로 따릅니다. 컨텍스트 압축/리셋 후에는 `autoRun.resume.flowCommand`로 재개하고, 필요 시 `autoRun.resume.contextCommand`로 상태를 먼저 확인합니다.
-- `AUTO_DELEGATED_HANDOFF`는 실패가 아니라 delegated run 일시정지입니다. 새 승인 라벨을 다시 열기 전에 delegated 경로를 재사용해 작업을 이어갑니다.
-- `AUTO_MANUAL_REQUIRED`는 실패가 아니라 자동화 경계(현재 instruction-only 구간)입니다. 즉시 오류로 단정하지 말고 현재 `context --json-compact`를 다시 확인한 뒤 승인 필요 여부(`approvalRequest.required`)를 보고합니다.
-- `AUTO_SELECTION_REQUIRED`는 실패가 아니라 feature 선택 경계 일시정지입니다. 활성 feature 선택을 먼저 해소한 뒤 `context --json-compact` 또는 `flow`를 다시 실행합니다.
-- `matchedFeature.currentSubstateId === "change_request_sync"`이거나 `matchedFeature.pendingChangeRequest`가 있으면 코드 작업보다 문서 동기화가 먼저입니다. `tasks.md`에 요청을 반영해 태스크를 추가/재태깅하고, 실제 사용자 동작이나 범위가 바뀌면 `decisions.md`와 `spec.md` / PRD 참조도 함께 맞춘 뒤 `대기 중 변경 요청` 필드를 비우고 `context --json-compact` 또는 `flow`를 다시 실행하세요.
-- CLI가 명령어를 출력하면 **그대로 복사해 실행**합니다. (standalone 환경에서도 레포 경로가 포함될 수 있습니다)
-- 사용자 응답 포맷은 `agents.md`의 **"라벨 응답 계약 (SSOT)"** 을 따릅니다. 라벨 문구는 승인 대기 상태에서만 보여주고, CLI가 준 승인 문구를 임의로 바꾸지 않습니다.
-- `approvalRequest.required=true`인 상태에서 옆 질문에 먼저 답했다면, 답변 후 `matchedFeature.currentSubstateId/currentSubstateOwner/currentSubstatePhase` 기반 현재 단계 한 줄 요약을 짧게 붙이고 CLI가 준 승인 문구를 그대로 다시 보여준 뒤 대기하세요.
-- 위임 대상이 아닌 command 옵션 실행은 `npx lee-spec-kit flow <slug|F001|F001-slug> --approve <LABEL> --execute`를 기본으로 사용하고, `context --approve`와 `context --execute --ticket` 분리 실행은 지양합니다.
-- 현재 command가 delegated 상태(`matchedFeature.currentSubstateOwner="subagent"` + `agentOrchestration.subAgentHandoff.required=true` + `mode="command"`)라면 메인 에이전트에서 직접 실행하지 말고 먼저 `spawn_agent`를 호출해 handoff 계약을 넘기세요.
-- `flow/context --execute --json` 결과가 `approved_handoff_prepared`이면 같은 라벨을 다시 승인 루프로 열지 말고, 먼저 delegated work를 완료한 뒤 context를 새로 확인합니다.
+- docs 경로 검사가 중요하면 `git commit` 전에 `npx lee-spec-kit commit-audit --json`를 사용합니다.
+- 코드나 feature 문서를 바꿨다면 종료 전에 `npx lee-spec-kit workflow-audit --json`로 동기화 상태를 확인합니다.
+- `tasks.md` 테스트 로그는 명령어당 1개 행만 유지하고, 재실행 시 기존 행을 갱신합니다.
 
-### 3단계: 기록 및 반복 (Record & Loop)
+## 5. 승인 경계
 
-- 새 태스크를 추가해야 한다면 우선 `npx lee-spec-kit task add <feature-ref> --title "..." --ref NON-PRD|PRD-*`를 사용하세요. `PRD-FR-001`이나 `PRD-SCOPE-V1-DESKTOP-EDITOR`처럼 이미 정의된 PRD key를 넣으면 됩니다. 필요하면 `--acceptance`, `--check`로 바로 구체 항목을 함께 추가할 수 있습니다.
-- 새로 추가한 태스크에 placeholder `Acceptance` / `Checklist`를 남기지 마세요. concrete item이 아니면 `task-run`이 실행을 막습니다.
-- 수동 편집이 꼭 필요할 때만 `태스크 목록` 섹션의 마지막 기존 태스크 block 바로 아래에 append 하세요.
-- 현재 작업 중인 태스크 근처나 `완료 조건`/다음 `##` 헤더 앞에 끼워 넣지 마세요.
-- 구현 도중 새 사용자 요청을 반영할 때는 `대기 중 변경 요청`을 임시 sync marker로 취급하세요. 요청을 `tasks.md`에 반영하고, 동작/범위 변경이면 관련 문서까지 맞춘 뒤 해당 필드를 비우고 구현으로 돌아갑니다.
+- 사용자 승인은 문서화된 review checkpoint와 원격/파괴적 작업 전에만 요청합니다.
+- issue 생성, PR 생성, push, merge 같은 원격 작업 전에는 올릴 artifact나 계획을 먼저 공유합니다.
+- 구현 자체는 Codex가 필요하면 위임할 수 있지만, 문서 갱신, 승인 처리, 원격 작업은 메인 세션에서 유지합니다.
 
-#### 3-1) Decision 기록 (매우 권장, 사실상 필수)
+## 절대 규칙
 
-에이전트가 “왜 이렇게 구현했지?” 라는 질문에 답할 수 있도록, **비직관적이거나 선택의 여지가 있었던 구현**이 들어갔다면 `decisions.md`에 반드시 기록합니다.
-
-다음 중 하나라도 해당되면 기록하세요:
-
-- 구현 방식에 대한 **트레이드오프(성능/안정성/보안/유지보수성)** 가 있었다
-- **새로운 규칙/휴리스틱/상태 전이**가 추가되었다 (예: context 판단 로직, 예외 처리 기준)
-- 사용자가 “왜 이렇게 했나요?” 라고 **이유/근거**를 물었다
-- 사용자가 “이렇게 바꿔주세요” 처럼 **직접 변경을 요청**했다 (요구사항/정책/기준 변경 포함)
-- 기존 동작을 **호환성/버그 회피** 목적으로 변경했다
-- 데이터 구조/파일 구조/CLI 출력 규칙이 바뀌었다
-- “나중에 보면 헷갈릴 것 같은” 결정이 있었다
-
-작성 시점 규칙:
-
-- 태스크를 `[DOING]`으로 전환할 때 `Context/Constraints`와 `Trace(초기 가설)`를 1~3줄로 먼저 기록합니다.
-- 태스크를 `[DONE]`으로 전환하기 전에 `Options/Decision/Rationale`를 최종화하고 `Trace(확정 근거)`를 보강합니다.
-- PR 머지 후 `Trace(머지 후 확인)`에 실제 결과/영향을 1~2줄로 추가합니다.
-
-증거 링크 규칙:
-
-- 모든 ADR에는 최소 1개 이상의 Evidence 링크(커밋/PR/테스트 로그 중 하나 이상)를 남깁니다.
-- 가능하면 `Commit`, `PR`, `Test/Log` 3가지를 모두 채우고, 미해당 항목은 `N/A`로 명시합니다.
-
-최종 형식은 Feature의 `decisions.md` 템플릿을 따릅니다. (Context/Constraints/Options/Decision/Rationale/Trace/Evidence/Consequences)
-
-#### 3-2) 태스크/체크리스트 업데이트 + 커밋
-
-1. 작업이 끝나면 결과/검증을 공유합니다. `[DONE]`으로 바꿀 때는 같은 수정에서 task-local `Checklist`도 함께 갱신해야 하며, unchecked box가 남아 있으면 `task-complete`가 `[DONE]` 전환을 거부합니다. 승인 대기(`approvalRequest.required=true`) 상태라면 CLI가 준 승인 문구를 그대로 제시하고 사용자의 `<라벨>` 또는 `<라벨> OK` 응답을 받은 뒤 `[DONE]`으로 변경합니다. 비승인 상태면 별도 승인 문구 없이 `[DONE]`과 `Acceptance/Checklist`를 갱신합니다.
-2. **한 번에 하나의 태스크만** `[DONE]` 처리합니다. (태스크 2개 이상을 한 번에 완료/커밋으로 묶지 않기)
-3. `tasks.md`의 테스트 실행 기록은 명령어별 1개 행만 유지하고, 같은 명령어 재실행 시 날짜/결과를 갱신합니다. (중복 누적 금지, 날짜 형식: 로컬 `YYYY-MM-DD`)
-4. 커밋을 생성합니다 (코드 커밋 + 문서 커밋). 태스크 단위로 커밋이 남아야 합니다.
-   - `context`에 `[확인 필요]`가 보이면, **커밋/푸시 같은 원격 작업은 사용자에게 커밋 메시지/포함 파일을 공유한 뒤 최신 CLI 승인 문구의 라벨 응답을 받은 후** 실행합니다.
-5. 모든 태스크가 `[DONE]`가 되면, "완료 조건" 체크리스트를 사용자에게 공유합니다. 이 시점이 승인 대기 상태면 `<라벨>` 또는 `<라벨> OK` 응답을 받은 뒤 체크하고, 비승인 상태면 일반 확인 응답을 받은 뒤 체크합니다. (특히 최종 결과/사용자 확인 항목)
-   - 참고: 진행 승인/최종 승인은 모두 현재 `approvalRequest.required` 상태를 기준으로 판단합니다. 라벨 승인 상태면 항상 라벨 응답을 사용하고, 비승인 상태면 standalone `OK`를 승인 토큰처럼 강제하지 않습니다.
-6. **즉시 1단계로 돌아가** 다음 할 일을 CLI에게 물어봅니다.
-
----
-
-## 🛑 절대 금지 사항 (Strict Rules)
-
-1. **병렬 처리 금지**: 한 번에 하나의 태스크만 `[DOING]`으로 만드세요.
-2. **임의 건너뛰기 금지**: CLI가 가리키는 순서대로 진행하세요.
-3. **완료된 태스크 수정 금지**: 이미 `[DONE]` 된 태스크는 절대 건드리지 마세요. 수정이 필요하면 새 태스크를 추가하세요.
-
----
-
-## 참조: 태스크 상태 전환 규칙
-
-> ⚠️ 직접 판단하지 말고 CLI가 시키는 대로 하세요.
-
-태스크 상태 전환/승인 규칙은 `tasks.md`의 **"태스크 규칙"** 섹션을 따르세요.
-
-## 비상시 대처 (Emergency)
-
-만약 CLI가 이상한 태스크를 가리키거나 멈춘다면, 사용자가 직접 `tasks.md`를 수동으로 수정하도록 요청하세요. 에이전트가 임의로 판단하지 마세요.
+1. 필요한 문서 업데이트를 건너뛰지 않습니다.
+2. `[DONE]` 태스크를 다시 쓰지 않습니다.
+3. unmanaged docs 산출물은 정규화하거나 allowlist하기 전까지 active workflow 상태로 취급하지 않습니다.
+4. issue 생성, branch 생성, 그 이전 단계가 막혀 있으면 구현을 시작하지 않습니다.