lee-spec-kit 0.7.10 → 0.7.11

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "lee-spec-kit",
-  "version": "0.7.10",
+  "version": "0.7.11",
   "description": "Agent-guided development harness CLI for spec-driven projects",
   "type": "module",
   "bin": {

package/templates/en/common/README.md

@@ -16,8 +16,10 @@ npx lee-spec-kit context --json-compact
 ```
 
 - Apply lee-spec-kit workflow only when `isLeeSpecKitProject: true`.
+- Use `context --json-compact` as the read-only state probe, then use `flow` as the default execution/resume entrypoint.
 - Determine approval waiting only from the latest `context --json-compact` / `flow --json-compact`.
-- When `approvalRequest.required=true`, show `approvalPrompt`/`finalPrompt` exactly as provided and wait for user approval (`<LABEL>` or `<LABEL> OK`) before execution.
+- When `approvalRequest.required=true`, keep approval open until it is resolved: briefly restate the current stage from `matchedFeature.currentSubstate*` when available, then show the exact CLI approval lines and wait for user approval (`<LABEL>` or `<LABEL> OK`) before execution.
+- For command execution, default to `npx lee-spec-kit flow <featureRef> --approve <LABEL> --execute`.
 - When `approvalRequest.required=false`, do not invent a separate label approval prompt.
 - If `isLeeSpecKitProject: false`, skip lee-spec-kit-specific flow and continue with normal workflow.
 
@@ -53,17 +55,17 @@ Recommended flow:
 
 - **PRD (`docs/prd/`)**: requirements SSOT
   - This top-level space is created by `init`; PRD is edited directly here rather than generated by a separate CLI step.
-  - Assign stable IDs per requirement: `PRD-FR-001`, `PRD-US-002`, `PRD-NFR-003`
+  - Assign stable `PRD-*` IDs per requirement: numeric IDs like `PRD-FR-001`, `PRD-US-002`, `PRD-NFR-003` or semantic keys like `PRD-SCOPE-V1-DESKTOP-EDITOR`
   - Keep IDs stable (prefer marking as Deprecated over deleting; do not renumber).
   - Define PRD IDs in the PRD source first. Do not invent them inside feature docs.
 - **Ideas (`docs/ideas/`)**: pre-Feature SSOT (hypotheses/experiments/candidates)
   - Ideas usually start from PRD requirements and should keep `PRD Refs` when applicable.
-  - Put `PRD Refs:` at the top (example: `PRD-FR-001, PRD-US-002`).
+  - Put `PRD Refs:` at the top (example: `PRD-FR-001, PRD-US-002` or `PRD-SCOPE-V1-DESKTOP-EDITOR`).
   - Once promoted, the SSOT moves to `docs/features/` and the idea should be archived.
 - **Features (`docs/features/`)**: implementation scope/progress SSOT
   - Features are the executable units that come after PRD and idea refinement.
   - `spec.md`: scope + `PRD Refs` (the PRD IDs this feature covers)
-  - `tasks.md`: map each task line to PRD IDs via bracket tags like `[PRD-FR-001]`, or tag non-PRD tasks as `[NON-PRD]`
+  - `tasks.md`: map each task line to PRD IDs via bracket tags like `[PRD-FR-001]` or `[PRD-SCOPE-V1-DESKTOP-EDITOR]`, or tag non-PRD tasks as `[NON-PRD]`
     - Use `[NON-PRD]` only for internal work such as refactors, renames, tooling, tests, and cleanup.
     - If a task changes user-facing behavior, acceptance criteria, or feature scope, backfill PRD first and tag the task as `[PRD-...]` instead of leaving it as `[NON-PRD]`.
   - For legacy docs without PRD IDs yet, backfill the source requirements doc first, then link the feature docs.

package/templates/en/common/agents/agents.md

@@ -38,15 +38,19 @@ Prohibited:
 
 ## 🧾 Label Response Contract (SSOT)
 
-- Treat approval-waiting as a separate state. Approval-waiting means `context --json-compact` (or `context --json`) exposes executable `actionOptions[]` and you are explicitly waiting for user approval.
+- Treat approval-waiting as a separate state. Approval-waiting means the latest `context --json-compact` / `flow --json-compact` (fallback: `context --json` / `flow --json`) shows `approvalRequest.required=true`.
+- Do not infer approval-waiting from conversation tone, action type, or the mere presence of `actionOptions[]`.
 - Use the latest `npx lee-spec-kit context --json-compact` as the default source (fallback: `context --json` or `flow --json` when full detail is required; prefer `flow --json-compact` for default flow output).
 - When using auto results from `flow --json-compact` (or `flow --json`), treat `autoRun.resume.flowCommand` as SSOT for resume (including after context compression/reset).
 - Treat `AUTO_DELEGATED_HANDOFF` as a delegated pause, not a failure. Continue or resume the delegated run path and do not reopen the same approval label.
 - Treat `AUTO_MANUAL_REQUIRED` as an instruction-only automation boundary, not an immediate failure. Re-check `context --json-compact`, then decide stop/report by `approvalRequest.required` (`context --json` only for full-detail debugging fields).
-- In approval-waiting state, prefer `approvalRequest.userFacingLines` from `context --json-compact`. If full `--json` is used, fall back to `actionOptions[*].approvalPrompt` plus `approvalRequest.finalPrompt`. Do not add your own rewritten label summary before or between those lines.
+- Special case: if `matchedFeature.currentSubstateId === "change_request_sync"` or `matchedFeature.pendingChangeRequest` is present, treat that manual boundary as an internal docs-sync step first, not an immediate user-facing stop. Sync docs, clear the pending change field, then continue with fresh `context --json-compact` or `flow`.
+- Treat `AUTO_SELECTION_REQUIRED` as a feature-selection pause, not an execution failure. Resolve the active feature first, then continue with fresh `context --json-compact` or `flow`.
+- In approval-waiting state, if `matchedFeature.currentSubstateId` exists, prepend one brief current-stage recap derived from `matchedFeature.currentSubstateId/currentSubstateOwner/currentSubstatePhase`.
+- Then prefer `approvalRequest.userFacingLines` from `context --json-compact`. If full `--json` is used, fall back to `actionOptions[*].approvalPrompt` plus `approvalRequest.finalPrompt`. Do not add your own rewritten label summary before or between those lines.
 - Prefer `matchedFeature.currentSubstateOwner` plus `agentOrchestration.subAgentHandoff` as the delegation SSOT.
 - In non-approval state, do not append labels or `approvalRequest.finalPrompt` unless the user explicitly asked for current options.
-- If approval is still pending after answering an unrelated question, answer first, then re-open approval with the exact CLI-provided approval lines (`approvalRequest.userFacingLines`, or `actionOptions[*].approvalPrompt` + `approvalRequest.finalPrompt` in full `--json`).
+- If approval is still pending after answering an unrelated question, answer first, re-check `approvalRequest.required`, and if it is still `true`, re-open approval with one brief current-stage recap plus the exact CLI-provided approval lines (`approvalRequest.userFacingLines`, or `actionOptions[*].approvalPrompt` + `approvalRequest.finalPrompt` in full `--json`).
 - If user input does not contain a valid label, do not execute; request label selection again.
 - For non-delegated command options, prefer one-shot `flow --approve <LABEL> --execute`; do not split `context --approve` and `context --execute --ticket` across turns/sessions.
 - If `matchedFeature.currentSubstateOwner="subagent"` and `agentOrchestration.subAgentHandoff.required=true` with `mode="command"`, delegation is mandatory: call `spawn_agent` first. Do not execute that command directly from the main agent.
@@ -57,7 +61,7 @@ Prohibited:
 - Main-agent fallback is allowed only when sub-agent execution is unavailable (for example: tool not available, spawn failed, or sub-agent failed before command execution).
 - When fallback is used, report a one-line fallback reason to the user before running the command in the main agent.
 
-Approval-waiting output must reuse the exact CLI-provided prompt lines. Do not invent a custom wrapper such as `Current status:` / `Available labels:` if the CLI did not provide those lines.
+Approval-waiting output must reuse the exact CLI-provided prompt lines. A single concise current-stage recap derived from `matchedFeature.currentSubstate*` is allowed before those lines. Do not invent label-summary wrappers such as `Current status:` / `Available labels:` or paraphrase label meanings.
 
 ---
 

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

@@ -41,8 +41,11 @@ Execute exactly one option from `👉 Next Options (Atomic)` as printed by the C
 - If auto execution stops, treat `autoRun.resume` from `flow --json-compact` (or `flow --json`) as SSOT. After interruption/compression, resume with `autoRun.resume.flowCommand`; if needed, check current state first with `autoRun.resume.contextCommand`.
 - Treat `AUTO_DELEGATED_HANDOFF` as a delegated pause, not a crash. Reuse the delegated run path and continue the delegated work before asking for a fresh approval label.
 - Treat `AUTO_MANUAL_REQUIRED` as an automation boundary (instruction-only segment), not an immediate crash. Re-check `context --json-compact` and report whether `approvalRequest.required` is now true.
+- Treat `AUTO_SELECTION_REQUIRED` as a feature-selection pause, not a crash. Resolve the active feature first, then rerun `context --json-compact` or `flow`.
+- If `matchedFeature.currentSubstateId === "change_request_sync"` or `matchedFeature.pendingChangeRequest` is present, sync docs before more code work: update `tasks.md` first, add or retag the affected task, and if shipped behavior or scope changed, sync `decisions.md` plus `spec.md` / PRD refs as needed. Clear `Pending Change Request` after syncing, then rerun `context --json-compact` or `flow`.
 - If the CLI prints commands, copy/paste them. (In standalone setups commands may include `git -C ...` and scopes like `project`/`docs`.)
 - Follow `agents.md` **"Label Response Contract (SSOT)"**. Show label prompts only in approval-waiting state, and reuse the exact CLI-provided approval lines instead of paraphrasing them.
+- If you answer a side question while `approvalRequest.required=true`, answer first, then briefly restate `matchedFeature.currentSubstateId/currentSubstateOwner/currentSubstatePhase` when available and re-show the exact CLI approval lines before waiting again.
 - For non-delegated command options, default to `npx lee-spec-kit flow <slug|F001|F001-slug> --approve <LABEL> --execute` and avoid split `context --approve` / `context --execute --ticket` runs across turns.
 - If the current command is delegated (`matchedFeature.currentSubstateOwner="subagent"` and `agentOrchestration.subAgentHandoff.required=true` with `mode="command"`), call `spawn_agent` first and pass the handoff contract instead of executing that command from the main agent.
 - If `flow/context --execute --json` returns `approved_handoff_prepared`, stop re-approving the same label. Complete the delegated work first, then refresh context.
@@ -53,10 +56,11 @@ Keep `tasks.md` aligned with reality.
 
 - Do not mark `[DONE]` without actually completing the work and verifying criteria.
 - If you need to change a completed task, add a new task instead of rewriting history.
-- If you need to add a new task, prefer `npx lee-spec-kit task add <feature-ref> --title "..." --ref NON-PRD|PRD-FR-001`. Add `--acceptance` and `--check` inline when you already know the concrete items.
+- If you need to add a new task, prefer `npx lee-spec-kit task add <feature-ref> --title "..." --ref NON-PRD|PRD-*`. Use an existing PRD key such as `PRD-FR-001` or `PRD-SCOPE-V1-DESKTOP-EDITOR`. Add `--acceptance` and `--check` inline when you already know the concrete items.
 - Do not leave placeholder `Acceptance` / `Checklist` items in a newly added task. `task-run` will block until those fields contain concrete execution/verification items.
 - If manual editing is unavoidable, append the new task directly below the last existing task block in the `Task List` section.
 - Do not insert it near the current task or right before `Completion Criteria` / the next `##` heading.
+- When handling a mid-implementation user change request, treat `Pending Change Request` as a temporary sync marker: reflect the request in `tasks.md`, sync supporting docs if the behavior/scope changed, then clear that field before resuming implementation.
 
 ### Step 3.25: Record decisions (strongly recommended, effectively required)
 

package/templates/en/common/features/README.md

@@ -65,8 +65,8 @@ npx lee-spec-kit status --write
 
 ## PRD Requirement Traceability (Recommended)
 
-- Assign stable requirement IDs in PRD docs (`docs/prd/*.md`) like `PRD-FR-001`.
-- Link each task line in `tasks.md` with a tag like `[PRD-FR-001]`. For non-PRD tasks, use `[NON-PRD]`.
+- Assign stable `PRD-*` requirement IDs in PRD docs (`docs/prd/*.md`) like `PRD-FR-001` or `PRD-SCOPE-V1-DESKTOP-EDITOR`.
+- Link each task line in `tasks.md` with a tag like `[PRD-FR-001]` or `[PRD-SCOPE-V1-DESKTOP-EDITOR]`. For non-PRD tasks, use `[NON-PRD]`.
 - Use `[NON-PRD]` only for internal implementation work such as refactors, test-only work, tooling, renames, and cleanup.
 - If a change affects user-facing behavior, acceptance criteria, or scope, update PRD first and retag the task as `[PRD-...]`.
 - Do not invent PRD IDs inside feature docs. Define them in the PRD source first, and backfill legacy docs before linking tasks.
@@ -79,6 +79,7 @@ npx lee-spec-kit status --write
 When things change mid-work, it must be explicit what was updated.
 
 - Record changes as **new tasks** (do not edit `[DONE]` tasks; create a new task instead).
+- During that sync, `tasks.md` may temporarily carry `Pending Change Request` as an internal marker. Clear it after the request is reflected in the new task(s) and related docs.
 - Every change task must be tagged as `[PRD-...]` or `[NON-PRD]`. (Recommended: also add `[CHANGE]`.)
 - If a change starts as internal exploration but ends up changing user-visible behavior, do not leave it as `[NON-PRD]`.
   - Backfill/update `docs/prd/*.md`

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

@@ -55,7 +55,7 @@
 ## Related Documents
 
 - PRD: `../../prd/`
-- PRD Refs: - (e.g. `PRD-FR-001`, `PRD-US-002`)
+- PRD Refs: - (e.g. `PRD-FR-001`, `PRD-US-002`, `PRD-SCOPE-V1-DESKTOP-EDITOR`)
   - Only list IDs that already exist in the source requirements doc. Do not invent PRD IDs in `spec.md` or `tasks.md`.
   - If this is a legacy requirements doc without PRD IDs yet, backfill IDs in the source first, then update this field and the `tasks.md` task tags together.
   - When requirements/scope change, update PRD docs + this field + `tasks.md` task tags together.

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

@@ -9,7 +9,7 @@
   - 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.
   - `task-complete` rejects `[DONE]` while any item in that task's `Checklist` remains unchecked.
-- **PRD mapping (recommended)**: add a PRD requirement ID tag like `[PRD-FR-001]` to each task line, or tag non-PRD tasks as `[NON-PRD]`.
+- **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.
   - If this is a legacy feature without PRD IDs yet, backfill IDs in the source requirements doc first, then align `spec.md` `PRD Refs` and task tags together.
   - `[NON-PRD]` is for internal implementation work only. If the task changes user-facing behavior, acceptance criteria, or scope, backfill PRD first and tag it as `[PRD-...]`.
@@ -23,6 +23,9 @@
 - **Repo**: {{projectName}}-{component}
 - **Issue**: #{issue-number}
 - **Branch**: `feat/{issue-number}-{feature-name}`
+- **Pending Change Request**: -
+  - Temporary sync marker for a newly accepted user request during implementation
+  - Clear it after reflecting the request in `tasks.md` and related docs
 - **PR**: -
   - Example: `#123` or PR URL
 - **PR Status**: -
@@ -57,7 +60,7 @@
     - [ ] (subtask)
 ```
 
-> `PRD-FR-001` in the example means an ID that already exists in the PRD source. If it is not defined yet, do not add it to tasks first.
+> `PRD-FR-001` in the example is just one valid `PRD-*` key. If the key is not defined in the PRD source yet, do not add it to tasks first.
 > If a task began as exploration/internal work but became a product requirement change, update PRD first, then retag the task from `[NON-PRD]` to `[PRD-...]`.
 
 ---
@@ -66,7 +69,7 @@
 
 > Add tasks below. **At least 1 task is required.**
 > Keep tasks as one ordered list. The list order itself is the execution priority.
-> To add a new task, prefer `npx lee-spec-kit task add <feature-ref> --title "..." --ref NON-PRD|PRD-FR-001`. Add `--acceptance` and `--check` inline when you already know the concrete items.
+> To add a new task, prefer `npx lee-spec-kit task add <feature-ref> --title "..." --ref NON-PRD|PRD-*`. Use an existing PRD key such as `PRD-FR-001` or `PRD-SCOPE-V1-DESKTOP-EDITOR`. Add `--acceptance` and `--check` inline when you already know the concrete items.
 > Do not leave placeholder `Acceptance` / `Checklist` content in place. `task-run` will block execution until those items are concrete.
 > If you must edit manually, append it below the last existing task block in `Task List` instead of inserting it near the current task or right before `Completion Criteria`.
 

package/templates/en/common/ideas/README.md

@@ -17,7 +17,7 @@ Typical flow: PRD defines the requirement, Idea explores or scopes the candidate
   - `Idea ID` (`I###` for indexed ideas)
   - Goal / context
   - Rough scope (what’s in/out)
-  - PRD Refs (recommended): `PRD-FR-001, PRD-US-002` (use `NON-PRD` when not tied to PRD)
+  - PRD Refs (recommended): `PRD-FR-001, PRD-US-002` or `PRD-SCOPE-V1-DESKTOP-EDITOR` (use `NON-PRD` when not tied to PRD)
   - Target component (optional): `api` / `app` / `worker` / `all`
   - Status: `Active | Featureized | Dropped`
   - Feature: `F###-slug` when promoted
@@ -32,7 +32,7 @@ Typical flow: PRD defines the requirement, Idea explores or scopes the candidate
 3. In the new Feature, record all of the following:
 - The source idea path is stamped into `spec.md` automatically when `--idea` is used.
 - `PRD Refs` still need to be completed in `spec.md`.
-- `tasks.md` still needs PRD mapping tags like `[PRD-FR-001]`.
+- `tasks.md` still needs PRD mapping tags like `[PRD-FR-001]` or `[PRD-SCOPE-V1-DESKTOP-EDITOR]`.
 4. Keep the idea doc for history and update it to `Status: Featureized`, `Feature: F00X-...`
 
 > Tip: keeping the source idea doc is usually better than deleting it for traceability (“why this feature exists”).

package/templates/en/common/prd/README.md

@@ -28,9 +28,9 @@ If work starts from a PRD item, keep the relationship visible through `PRD Refs`
 
 To let the CLI report “which PRD items are implemented”, assign **stable IDs** to PRD requirements.
 
-- Format: `PRD-FR-001`, `PRD-US-002`, `PRD-NFR-003`
+- Use stable `PRD-*` keys. Numeric IDs like `PRD-FR-001`, `PRD-US-002`, `PRD-NFR-003` and semantic keys like `PRD-SCOPE-V1-DESKTOP-EDITOR` are all valid.
 - The ID only needs to appear on the same line (heading/bullet).
-- Reference it from a Feature `tasks.md` task line as a **bracket tag** like `[PRD-FR-001]`.
+- Reference it from a Feature `tasks.md` task line as a **bracket tag** like `[PRD-FR-001]` or `[PRD-SCOPE-V1-DESKTOP-EDITOR]`.
 - For non-PRD tasks, tag them as `[NON-PRD]`.
 - Important: do not invent PRD IDs in `tasks.md` or `spec.md`. Define them in this folder or the upstream requirements source first, then reference them.
 - For legacy PRD/requirements docs without IDs yet, backfill IDs in the source first, then align the Feature `PRD Refs` and task tags.

package/templates/ko/common/README.md

@@ -16,8 +16,10 @@ npx lee-spec-kit context --json-compact
 ```
 
 - `isLeeSpecKitProject: true`일 때만 lee-spec-kit 워크플로우를 적용합니다.
+- `context --json-compact`는 read-only 상태 확인용으로 쓰고, 실제 실행/재개 기본 엔트리포인트는 `flow`를 사용합니다.
 - 승인 대기 여부는 항상 최신 `context --json-compact` / `flow --json-compact`를 기준으로 판단합니다.
-- `approvalRequest.required=true`일 때만 `approvalPrompt`/`finalPrompt`를 그대로 사용자에게 보여주고 승인(`<LABEL>` 또는 `<LABEL> OK`)을 받은 뒤 실행합니다.
+- `approvalRequest.required=true`일 때는 승인이 끝날 때까지 승인 상태를 유지합니다. 가능하면 `matchedFeature.currentSubstate*` 기반 현재 단계 한 줄 요약을 먼저 말하고, 그 다음 CLI가 준 승인 문구를 그대로 보여준 뒤 승인(`<LABEL>` 또는 `<LABEL> OK`)을 받은 후 실행합니다.
+- 명령 실행은 기본적으로 `npx lee-spec-kit flow <featureRef> --approve <LABEL> --execute`를 사용합니다.
 - `approvalRequest.required=false`이면 별도 라벨 승인 문구를 만들지 않습니다.
 - `isLeeSpecKitProject: false`면 lee-spec-kit 전용 절차를 건너뛰고 일반 워크플로우로 진행합니다.
 
@@ -53,17 +55,17 @@ npx lee-spec-kit context --json-compact
 
 - **PRD (`docs/prd/`)**: 요구사항 SSOT
   - 이 공간은 `init`이 만들어 주며, 별도 생성 명령 없이 여기에서 직접 PRD를 관리합니다.
-  - 요구사항마다 ID를 부여합니다: `PRD-FR-001`, `PRD-US-002`, `PRD-NFR-003`
+  - 요구사항마다 안정적인 `PRD-*` ID를 부여합니다: `PRD-FR-001`, `PRD-US-002`, `PRD-NFR-003` 같은 numeric ID 또는 `PRD-SCOPE-V1-DESKTOP-EDITOR` 같은 semantic key
   - ID는 안정적으로 유지합니다. (삭제 대신 `Deprecated` 표기 권장, 재번호 부여 금지)
   - PRD ID는 PRD 원문에 먼저 정의합니다. Feature 문서에서 임의 생성하지 않습니다.
 - **Ideas (`docs/ideas/`)**: Feature 전 단계 SSOT (가설/실험/후보)
   - 가능하면 PRD에서 출발한 후보라는 점이 보이도록 `PRD Refs`를 유지합니다.
-  - Idea 문서 상단에 `PRD Refs:`를 기록합니다. (예: `PRD-FR-001, PRD-US-002`)
+  - Idea 문서 상단에 `PRD Refs:`를 기록합니다. (예: `PRD-FR-001, PRD-US-002` 또는 `PRD-SCOPE-V1-DESKTOP-EDITOR`)
   - Feature로 승격되면 SSOT는 `docs/features/`로 이동하고, Idea는 archive로 정리합니다.
 - **Features (`docs/features/`)**: 구현 범위/진행 SSOT
   - Feature는 PRD와 idea를 바탕으로 실제 구현을 진행하는 실행 단위입니다.
   - `spec.md`: 범위 정의 + `PRD Refs`(기능이 커버하는 PRD ID 목록)
-  - `tasks.md`: 태스크 단위로 PRD ID를 태그(`[PRD-FR-001]`)로 매핑하거나, PRD 무관 태스크는 `[NON-PRD]`로 표시
+  - `tasks.md`: 태스크 단위로 PRD ID를 태그(`[PRD-FR-001]`, `[PRD-SCOPE-V1-DESKTOP-EDITOR]`)로 매핑하거나, PRD 무관 태스크는 `[NON-PRD]`로 표시
     - `[NON-PRD]`는 refactor, rename, tooling, 테스트, cleanup 같은 내부 작업에만 사용합니다.
     - 태스크가 사용자 동작, acceptance criteria, 기능 범위를 바꾸게 되면 `[NON-PRD]`로 끝내지 말고 PRD를 backfill한 뒤 `[PRD-...]`로 연결합니다.
   - 레거시 문서에 PRD ID가 없다면, 먼저 원문 요구사항 문서에 ID를 backfill한 뒤 Feature 문서를 연결합니다.

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

@@ -38,15 +38,19 @@
 
 ## 🧾 라벨 응답 계약 (SSOT)
 
-- 승인 대기 상태를 별도 상태로 취급합니다. 승인 대기란 `context --json-compact`(또는 `context --json`)에 실행 가능한 `actionOptions[]`가 있고, 현재 사용자의 승인을 기다리는 경우를 의미합니다.
+- 승인 대기 상태를 별도 상태로 취급합니다. 승인 대기란 최신 `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`)
-- 승인 대기 상태에서는 `context --json-compact`의 `approvalRequest.userFacingLines`를 우선 그대로 보여주세요. 전체 `--json`을 쓸 때만 `actionOptions[*].approvalPrompt`와 `approvalRequest.finalPrompt` 조합으로 폴백합니다. 이 사이에 에이전트가 임의로 다시 쓴 라벨 요약을 끼워 넣지 않습니다.
+- 예외: `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`를 덧붙이지 않습니다. 현재 옵션을 사용자가 직접 물었을 때만 예외입니다.
-- 관련 없는 질문에 먼저 답한 뒤에도 승인이 여전히 필요하면, 답변 후 CLI가 준 승인 문구(`approvalRequest.userFacingLines`, 또는 전체 `--json`의 `actionOptions[*].approvalPrompt` + `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`를 호출하고, 해당 명령을 메인 에이전트에서 직접 실행하지 않습니다.
@@ -57,7 +61,7 @@
 - 메인 에이전트 fallback은 서브 에이전트 실행이 불가능한 경우(예: 도구 미지원, spawn 실패, 명령 실행 전 서브 에이전트 실패)에만 허용합니다.
 - fallback을 사용할 때는 메인 실행 전에 fallback 사유를 사용자에게 한 줄로 먼저 알립니다.
 
-승인 대기 상태 출력은 CLI가 제공한 승인 문구를 그대로 재사용해야 합니다. CLI가 주지 않은 `현재 상태:` / `선택 가능:` 같은 래퍼 문구를 에이전트가 임의로 만들어 붙이지 마세요.
+승인 대기 상태 출력은 CLI가 제공한 승인 문구를 그대로 재사용해야 합니다. `matchedFeature.currentSubstate*`에서 가져온 간단한 현재 단계 한 줄 요약은 앞에 붙일 수 있지만, 그 외에 CLI가 주지 않은 `현재 상태:` / `선택 가능:` 같은 라벨 요약 래퍼를 임의로 만들어 붙이지 마세요.
 
 ---
 

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

@@ -41,18 +41,22 @@ CLI가 가리키는 **Active Task** 또는 **`👉 Next Options (Atomic)`의 단
 - 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를 새로 확인합니다.
 
 ### 3단계: 기록 및 반복 (Record & Loop)
 
-- 새 태스크를 추가해야 한다면 우선 `npx lee-spec-kit task add <feature-ref> --title "..." --ref NON-PRD|PRD-FR-001`를 사용하세요. 필요하면 `--acceptance`, `--check`로 바로 구체 항목을 함께 추가할 수 있습니다.
+- 새 태스크를 추가해야 한다면 우선 `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`에 반영하고, 동작/범위 변경이면 관련 문서까지 맞춘 뒤 해당 필드를 비우고 구현으로 돌아갑니다.
 
 #### 3-1) Decision 기록 (매우 권장, 사실상 필수)
 

package/templates/ko/common/features/README.md

@@ -65,8 +65,8 @@ npx lee-spec-kit status --write
 
 ## PRD 요구사항 추적 (권장)
 
-- PRD 문서(`docs/prd/*.md`)에 `PRD-FR-001` 같은 요구사항 ID를 부여하세요.
-- `tasks.md`의 각 태스크 라인에 `[PRD-FR-001]` 태그로 연결하세요. PRD와 무관한 태스크는 `[NON-PRD]`를 사용하세요.
+- PRD 문서(`docs/prd/*.md`)에 `PRD-FR-001` 또는 `PRD-SCOPE-V1-DESKTOP-EDITOR` 같은 `PRD-*` 요구사항 ID를 부여하세요.
+- `tasks.md`의 각 태스크 라인에 `[PRD-FR-001]` 또는 `[PRD-SCOPE-V1-DESKTOP-EDITOR]` 태그로 연결하세요. PRD와 무관한 태스크는 `[NON-PRD]`를 사용하세요.
 - `[NON-PRD]`는 refactor, 테스트 전용 작업, tooling, rename, cleanup 같은 내부 구현 작업에만 사용하세요.
 - 변경이 사용자 동작, acceptance criteria, 범위를 바꾸면 PRD를 먼저 갱신하고 태스크도 `[PRD-...]`로 다시 연결하세요.
 - 단, 태스크 문서에서 PRD ID를 임의 생성하지 않습니다. 먼저 PRD 원문에 정의하고, 레거시 문서는 원문 ID backfill 후 연결하세요.
@@ -79,6 +79,7 @@ npx lee-spec-kit status --write
 중간 변경이 생기면, “어디를 고쳤는지”와 “무엇을 업데이트했는지”가 문서로 남아야 합니다.
 
 - 변경은 **새 태스크로 추가**합니다. (`[DONE]` 태스크를 고치지 말고 새 태스크를 만드세요)
+- 이 동기화 중 `tasks.md`에는 내부 marker로 `대기 중 변경 요청` 필드가 잠시 들어갈 수 있습니다. 새 태스크와 관련 문서에 반영이 끝나면 값을 비우세요.
 - 변경 태스크에는 `[PRD-...]` 또는 `[NON-PRD]` 태그를 반드시 붙입니다. (권장: `[CHANGE]` 태그 추가)
 - 내부 검토로 시작했더라도, 최종적으로 사용자 요구/동작 변경이 되면 `[NON-PRD]`로 남기지 않습니다.
   - `docs/prd/*.md`를 backfill/수정

package/templates/ko/common/features/feature-base/spec.md

@@ -55,7 +55,7 @@
 ## 관련 문서
 
 - PRD: `../../prd/`
-- PRD Refs: - (예: `PRD-FR-001`, `PRD-US-002`)
+- PRD Refs: - (예: `PRD-FR-001`, `PRD-US-002`, `PRD-SCOPE-V1-DESKTOP-EDITOR`)
   - 이미 원문 요구사항 문서에 정의된 ID만 적으세요. `spec.md`나 `tasks.md`에서 임의로 PRD ID를 만들지 않습니다.
   - 레거시 요구사항 문서에 아직 PRD ID가 없다면, 먼저 원문에 ID를 backfill한 뒤 이 필드와 `tasks.md` 태스크 태그를 함께 갱신하세요.
   - 요구사항/스코프 변경 시 PRD 문서 + 이 필드 + `tasks.md` 태스크 태그를 함께 갱신하세요.

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

@@ -9,7 +9,7 @@
   - `approvalRequest.required=true`이면 CLI가 제공한 라벨 응답을 받은 뒤에만 태스크 상태를 변경합니다.
   - `approvalRequest.required=false`이면 별도 `OK` 승인 단계를 만들지 말고, 실제 완료/검증 후 상태를 갱신합니다.
   - 해당 태스크의 `Checklist`에 unchecked 항목이 남아 있으면 `task-complete`는 `[DONE]` 전환을 거부합니다.
-- **PRD 매핑(권장)**: 각 태스크 라인에 `[PRD-FR-001]` 같은 PRD 요구사항 ID 태그를 추가하거나, PRD와 무관한 태스크는 `[NON-PRD]`로 표시하세요.
+- **PRD 매핑(권장)**: 각 태스크 라인에 `[PRD-FR-001]` 또는 `[PRD-SCOPE-V1-DESKTOP-EDITOR]` 같은 기존 PRD 요구사항 ID 태그를 추가하거나, PRD와 무관한 태스크는 `[NON-PRD]`로 표시하세요.
   - 단, `tasks.md`에서 PRD ID를 임의로 만들지 마세요. `docs/prd` 또는 상위 요구사항 문서에 먼저 정의된 ID만 참조해야 합니다.
   - 레거시 문서에 아직 PRD ID가 없다면, 먼저 원문 요구사항 문서에 ID를 backfill한 뒤 `spec.md`의 `PRD Refs`와 태스크 태그를 함께 맞추세요.
   - `[NON-PRD]`는 내부 구현 작업 전용입니다. 사용자 동작, acceptance criteria, 범위가 바뀌는 태스크라면 PRD를 먼저 backfill하고 `[PRD-...]`로 태깅하세요.
@@ -23,6 +23,9 @@
 - **레포**: {{projectName}}-{component}
 - **Issue**: #{이슈번호}
 - **브랜치**: `feat/{이슈번호}-{기능명}`
+- **대기 중 변경 요청**: -
+  - 구현 중 새로 수용한 사용자 요청을 잠시 표시하는 sync marker입니다
+  - 요청을 `tasks.md`와 관련 문서에 반영한 뒤 값을 비우세요
 - **PR**: -
   - 예: `#123` 또는 PR URL
 - **PR 상태**: -
@@ -57,7 +60,7 @@
     - [ ] (서브 태스크)
 ```
 
-> 위 예시의 `PRD-FR-001`은 이미 PRD 원문에 존재하는 ID를 뜻합니다. 아직 정의되지 않았다면 태스크에 먼저 넣지 마세요.
+> 위 예시의 `PRD-FR-001`은 가능한 `PRD-*` key 중 하나일 뿐입니다. 아직 PRD 원문에 정의되지 않았다면 태스크에 먼저 넣지 마세요.
 > 처음엔 탐색/내부 작업이었더라도 제품 요구사항 변경으로 이어졌다면, `NON-PRD`로 두지 말고 PRD를 먼저 갱신한 뒤 `[PRD-...]`로 재태깅하세요.
 
 ---
@@ -66,7 +69,7 @@
 
 > 아래에 태스크를 추가하세요. **최소 1개가 필요**합니다.
 > 태스크는 하나의 순차 리스트로 유지하고, 위에서 아래 순서 자체를 실행 우선순위로 취급하세요.
-> 새 태스크는 가급적 `npx lee-spec-kit task add <feature-ref> --title "..." --ref NON-PRD|PRD-FR-001`로 추가하세요. 필요하면 `--acceptance`, `--check`로 바로 구체 항목을 함께 적을 수 있습니다.
+> 새 태스크는 가급적 `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 하세요.
 

package/templates/ko/common/ideas/README.md

@@ -17,7 +17,7 @@ Feature로 발전하기 전의 아이디어 / To-do / 실험 기록을 모아두
   - `Idea ID` (`I###` 형식의 indexed idea인 경우)
   - 목적/배경
   - 대략 범위(뭘 할지/안 할지)
-  - PRD Refs(권장): `PRD-FR-001, PRD-US-002` (PRD와 무관하면 `NON-PRD` 명시)
+  - PRD Refs(권장): `PRD-FR-001, PRD-US-002` 또는 `PRD-SCOPE-V1-DESKTOP-EDITOR` (PRD와 무관하면 `NON-PRD` 명시)
   - 대상 컴포넌트(필요 시): `api` / `app` / `worker` / `all`
   - 상태: `Active | Featureized | Dropped`
   - Feature: 승격되면 `F###-slug`
@@ -32,7 +32,7 @@ Feature로 발전하기 전의 아이디어 / To-do / 실험 기록을 모아두
 3. `--idea`를 사용하면 새 Feature의 `spec.md`에 source idea 경로가 자동 기록됩니다
 4. 승격 후에도 다음은 직접 채워야 합니다
    - `spec.md`의 `PRD Refs`
-   - `tasks.md` 태스크 라인의 PRD ID 태그(`[PRD-FR-001]` 등)
+   - `tasks.md` 태스크 라인의 PRD ID 태그(`[PRD-FR-001]`, `[PRD-SCOPE-V1-DESKTOP-EDITOR]` 등)
 5. 아이디어 문서는 삭제하지 말고 `Status: Featureized`, `Feature: F00X-...`로 남기는 것을 권장합니다
 
 > 💡 source idea 문서를 남겨두면 “왜 이 Feature가 생겼는지” 추적하기 쉽습니다.

package/templates/ko/common/prd/README.md

@@ -28,9 +28,9 @@ PRD에서 시작한 작업이라면, 이후 문서에서도 `PRD Refs`와 태스
 
 PRD의 “어느 요구사항이 구현됐는지”를 CLI가 집계할 수 있도록, 요구사항에 **안정적인 ID**를 부여하세요.
 
-- 형식: `PRD-FR-001`, `PRD-US-002`, `PRD-NFR-003`
+- 안정적인 `PRD-*` key를 사용하세요. `PRD-FR-001`, `PRD-US-002`, `PRD-NFR-003` 같은 numeric ID와 `PRD-SCOPE-V1-DESKTOP-EDITOR` 같은 semantic key를 모두 사용할 수 있습니다.
 - 같은 줄(헤더/불릿) 안에 ID만 포함되어 있으면 됩니다.
-- Feature의 `tasks.md` 태스크 라인에 `[PRD-FR-001]`처럼 **대괄호 태그**로 참조하세요.
+- Feature의 `tasks.md` 태스크 라인에 `[PRD-FR-001]` 또는 `[PRD-SCOPE-V1-DESKTOP-EDITOR]`처럼 **대괄호 태그**로 참조하세요.
 - PRD와 무관한 태스크는 `[NON-PRD]` 태그로 표시하세요.
 - 중요한 점: `tasks.md`나 `spec.md`에서 PRD ID를 임의로 만들지 않습니다. 항상 이 폴더나 상위 요구사항 원문에 먼저 정의한 뒤 참조하세요.
 - 레거시 PRD/요구사항 문서에 아직 ID가 없다면, 먼저 원문 문서에 ID를 backfill한 뒤 Feature의 `PRD Refs`와 태스크 태그를 맞추세요.