lee-spec-kit 0.6.12 → 0.6.13

package/dist/index.js

@@ -134,7 +134,7 @@ var I18N = {
       "context.checkPolicyHint": "\u2139\uFE0F  \uC0AC\uC6A9\uC790 \uD655\uC778 \uC815\uCC45\uC740 \uC138\uC158 \uC2DC\uC791(\uB610\uB294 context \uC555\uCD95/\uB9AC\uC14B \uC9C1\uD6C4)\uC5D0 1\uD68C \uD655\uC778\uD558\uACE0, \uC774\uD6C4\uC5D0\uB294 \uC815\uCC45/\uC124\uC815 \uBCC0\uACBD \uB610\uB294 \uC0AC\uC6A9\uC790 \uC0C8\uB85C\uACE0\uCE68 \uC694\uCCAD \uC2DC\uC5D0\uB9CC \uC7AC\uD655\uC778\uD558\uC138\uC694. (git push/merge/merge commit \uD3EC\uD568) [\uD655\uC778 \uD544\uC694]\uAC00 \uC788\uC73C\uBA74 \uC0AC\uC6A9\uC790\uC5D0\uAC8C `<\uB77C\uBCA8>` \uB610\uB294 `<\uB77C\uBCA8> OK` (\uC608: `A`, `A OK`) \uC751\uB2F5\uC744 \uBC1B\uC740 \uB4A4 \uC9C4\uD589 (config: approval\uB85C \uC870\uC815 \uAC00\uB2A5)",
       "context.actionOptionHint": "\uC2B9\uC778 \uC751\uB2F5 \uD615\uC2DD: \uB77C\uBCA8 \uD1A0\uD070 \uD3EC\uD568 (\uC608: `A`, `A OK`, `A \uC9C4\uD589\uD574`)",
       "context.actionExplainHint": "\uC2B9\uC778 \uC694\uCCAD \uC804, \uAC01 \uB77C\uBCA8\uC774 \uBB34\uC5C7\uC744 \uC2E4\uD589/\uBCC0\uACBD\uD558\uB294\uC9C0 \uD55C \uC904 \uC694\uC57D\uACFC \uD568\uAED8 \uC124\uBA85\uD558\uC138\uC694.",
-      "context.finalLabelPrompt": "\uD604\uC7AC \uC120\uD0DD \uAC00\uB2A5\uD55C \uB77C\uBCA8: {labels}. \uB9C8\uC9C0\uB9C9 \uC751\uB2F5\uC740 `<\uB77C\uBCA8>` \uB610\uB294 `<\uB77C\uBCA8> OK` \uD615\uC2DD\uC73C\uB85C \uBC1B\uC73C\uC138\uC694. (\uC608: {example})",
+      "context.finalLabelPrompt": "\uD604\uC7AC \uC120\uD0DD \uAC00\uB2A5\uD55C \uB77C\uBCA8: {labels}. \uC751\uB2F5\uC740 `<\uB77C\uBCA8>` \uB610\uB294 `<\uB77C\uBCA8> OK` \uD615\uC2DD\uC73C\uB85C \uD574\uC8FC\uC138\uC694. (\uC608: {example})",
       "context.finalLabelCommandHint": "\uB77C\uBCA8\uC744 \uBC1B\uC73C\uBA74 \uC2B9\uC778 \uC120\uD0DD \uC2E4\uD589: {command}",
       "context.finalTicketCommandHint": "\uBA85\uB839 \uC2E4\uD589\uC740 \uC2B9\uC778 \uACB0\uACFC\uC758 \uD2F0\uCF13\uC73C\uB85C \uC2E4\uD589: {command}",
       "context.readBuiltinDocFirst": "\uC774\uBC88 \uC138\uC158\uC5D0 \uC544\uC9C1 \uC77D\uC9C0 \uC54A\uC558\uAC70\uB098 \uBCC0\uACBD \uAC00\uB2A5\uC131\uC774 \uC788\uC744 \uB54C\uB9CC \uD544\uC694\uD55C \uB0B4\uC7A5 \uBB38\uC11C\uB97C \uD655\uC778\uD558\uC138\uC694.",
@@ -530,7 +530,7 @@ var I18N = {
       "context.checkPolicyHint": "\u2139\uFE0F  Check user-approval policy once at session start (or right after context compression/reset); re-check only when policy/config changes or the user explicitly requests refresh. (includes git push/merge and merge commits). If you see [CHECK required], wait for `<label>` or `<label> OK` (e.g. `A`, `A OK`) before proceeding (config: approval can override)",
       "context.actionOptionHint": "Approval reply format: include a label token (e.g. `A`, `A OK`, `A proceed`)",
       "context.actionExplainHint": "Before requesting approval, explain what each label will run/change with a one-line summary.",
-      "context.finalLabelPrompt": "Available labels now: {labels}. End with a label request in `<label>` or `<label> OK` format. (e.g. {example})",
+      "context.finalLabelPrompt": "Available labels now: {labels}. Please reply in `<label>` or `<label> OK` format. (e.g. {example})",
       "context.finalLabelCommandHint": "When a label is provided, run approval selection: {command}",
       "context.finalTicketCommandHint": "Execute commands using the ticket from approval result: {command}",
       "context.readBuiltinDocFirst": "Read required built-in docs only if not read in this session yet or likely changed.",
@@ -5857,14 +5857,14 @@ async function runContext(featureName, options) {
           "actionOptions[].detail",
           "actionOptions[].approvalPrompt"
         ],
-        recommendation: "Before asking for approval, show only `actionOptions[].approvalPrompt` lines and `approvalRequest.finalPrompt` to the user. Keep `requiredDocs`, `checkPolicy`, and raw execution commands as internal guidance. For commit actions, include scope (`docs`/`project`) and commit message in the visible prompt. User replies should include the label token (e.g. `A`, `A OK`, `A proceed`, `A \uC9C4\uD589\uD574`). For command execution, require one-time `approvalTicket` only when the selected action has `requiresUserCheck=true`.",
+        recommendation: "Before asking for approval, show only `actionOptions[].approvalPrompt` lines and `approvalRequest.finalPrompt` to the user. Keep `requiredDocs`, `checkPolicy`, and raw execution commands as internal guidance. For commit actions, include scope (`docs`/`project`) and commit message in the visible prompt. User replies should include the label token (e.g. `A`, `A OK`, `A proceed`, `A \uC9C4\uD589\uD574`). For command execution, prefer one-shot `npx lee-spec-kit flow <featureRef> --approve <LABEL> --execute` to avoid session mismatch after context compression/reset. Use ticket-based `context --execute --ticket` only when explicitly needed.",
         oneApprovalPerAction: true,
         requireFreshContext: true,
         contextVersion: state.contextVersion,
         config: config.approval ?? { mode: "builtin" }
       },
       approvalRequest: {
-        guidance: "User-facing output must include only approval prompts (`A: ...`) and `finalPrompt`. Do not expose `requiredDocs`, `checkPolicy`, or raw `cmd` unless explicitly requested.",
+        guidance: "User-facing output must include only approval prompts (`A: ...`) and `finalPrompt`. Do not expose `requiredDocs`, `checkPolicy`, or raw `cmd` unless explicitly requested. For approved command actions, prefer one-shot `flow --approve <LABEL> --execute`.",
         finalPrompt: finalApprovalPrompt,
         userFacingLines: [
           ...state.actionOptions.map((o) => o.approvalPrompt),

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "lee-spec-kit",
-  "version": "0.6.12",
+  "version": "0.6.13",
   "description": "Project documentation structure generator for AI-assisted development",
   "type": "module",
   "bin": {

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

@@ -23,7 +23,7 @@ This document covers **policy only**.
 Approval flow:
 1. Share details first
 2. Wait for explicit approval (OK)
-3. Execute after approval
+3. Execute after approval (for command execution, default to `npx lee-spec-kit flow <featureRef> --approve <LABEL> --execute`)
 
 Prohibited:
 - Proceeding without user response
@@ -38,6 +38,7 @@ Prohibited:
 - Even when the user asks something else, append the same label block at the end if executable labels exist.
 - If no executable labels exist, print `Available labels: none` and guide re-check with `npx lee-spec-kit context`.
 - If user input does not contain a valid label, do not execute; request label selection again.
+- For approved command options, prefer one-shot `flow --approve <LABEL> --execute`; do not split `context --approve` and `context --execute --ticket` across turns/sessions.
 
 Output format:
 

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

@@ -26,6 +26,7 @@ For gated actions, proceed only after the user replies in **`<label>` or `<label
 - If the CLI asks for writing a file, write that file and follow the format.
 - If the CLI prints a command, **copy/paste and run it exactly**. (It may include repo-safe `git -C ...` commands and scopes like `project` vs `docs`.)
 - When requesting approval, present labels as `A: ...` using the exact CLI detail/cmd text. Do not paraphrase command options.
+- For approved command options, default to one-shot execution via `npx lee-spec-kit flow <slug|F001|F001-slug> --approve <LABEL> --execute` to avoid session mismatch.
 
 ### Step 3: Repeat
 

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

@@ -23,6 +23,7 @@ Execute exactly one option from `👉 Next Options (Atomic)` as printed by the C
 - Treat the task state/approval rules in `tasks.md` **"Task Rules"** as SSOT (e.g. when OK is required for `[TODO]→[DOING]`, `[DOING]→[DONE]`).
 - If the CLI prints commands, copy/paste them. (In standalone setups commands may include `git -C ...` and scopes like `project`/`docs`.)
 - Follow user-facing response format (including the final status/label block in every reply) from `agents.md` **"Label Response Contract (SSOT)"**.
+- For approved 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.
 
 ### Step 3: Update tasks.md (only what you did)
 
@@ -31,16 +32,7 @@ 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.
 
-### Step 3.25: Commit per task (important)
-
-- Complete **only one task at a time** (do not batch-finish multiple tasks in one commit).
-- After you share the outcome/verification and get approval (OK), mark the task `[DONE]` (and update any checklist items), then create commits (code commit + docs commit) so each task has its own history.
-- In `tasks.md` test logs, keep one entry per test command and update its timestamp/result on reruns (do not keep appending duplicates). Use `YYYY-MM-DD HH-MM` in local time.
-- If `context` shows `[CHECK required]`, for commits/push/merge, **share the commit message + included files and wait for explicit OK** before running the commands.
-- Once all tasks are `[DONE]`, share the "Completion Criteria" checklist with the user and get **final approval (OK)**, then check it (especially the **Final user approval (OK) received** item).
-  - Note: `Doc Status (Review→Approved)` is **progress approval (OK)**, while the completion checklist approval is **final approval (OK)**.
-
-### Step 3.5: Record decisions (strongly recommended, effectively required)
+### Step 3.25: Record decisions (strongly recommended, effectively required)
 
 To avoid “why did we implement it like this?” losing context, **record any non-obvious or tradeoff-heavy implementation choice** in `decisions.md`.
 
@@ -54,7 +46,27 @@ Record a decision if any of these apply:
 - You changed data shape, file structure, or CLI output rules
 - You expect future readers to ask “why this way?”
 
-Use the feature’s `decisions.md` template format. (Context/Options/Decision/Rationale/Consequences)
+Timing rules:
+
+- When moving a task to `[DOING]`, first add 1-3 lines for `Context/Constraints` and `Trace (initial hypothesis)`.
+- Before moving a task to `[DONE]`, finalize `Options/Decision/Rationale` and strengthen `Trace (final reasoning)`.
+- After PR merge, append 1-2 lines in `Trace (post-merge check)` with actual outcome/impact.
+
+Evidence rules:
+
+- Every ADR must include at least one Evidence link (commit, PR, or test/log evidence).
+- Prefer filling all three (`Commit`, `PR`, `Test/Log`); if not applicable, mark as `N/A`.
+
+Use the feature’s `decisions.md` template format as final SSOT. (Context/Constraints/Options/Decision/Rationale/Trace/Evidence/Consequences)
+
+### Step 3.5: Commit per task (important)
+
+- Complete **only one task at a time** (do not batch-finish multiple tasks in one commit).
+- After you share the outcome/verification and get approval (OK), mark the task `[DONE]` (and update any checklist items), then create commits (code commit + docs commit) so each task has its own history.
+- In `tasks.md` test logs, keep one entry per test command and update its timestamp/result on reruns (do not keep appending duplicates). Use `YYYY-MM-DD HH-MM` in local time.
+- If `context` shows `[CHECK required]`, for commits/push/merge, **share the commit message + included files and wait for explicit OK** before running the commands.
+- Once all tasks are `[DONE]`, share the "Completion Criteria" checklist with the user and get **final approval (OK)**, then check it (especially the **Final user approval (OK) received** item).
+  - Note: `Doc Status (Review→Approved)` is **progress approval (OK)**, while the completion checklist approval is **final approval (OK)**.
 
 ### Step 4: Repeat
 

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

@@ -65,4 +65,4 @@ npx lee-spec-kit status --write
 | `spec.md`      | **What and Why**          | Feature definition  |
 | `plan.md`      | **How** (technical)       | After spec approval |
 | `tasks.md`     | Specific work items       | After plan approval |
-| `decisions.md` | Technical decisions (ADR) | During development  |
+| `decisions.md` | Technical decisions + reasoning trace + evidence links (ADR) | During development (DOING start / before DONE / post-merge) |

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

@@ -7,12 +7,30 @@ Record technical decisions and their rationale.
 
 > Format: `D{number}: {Decision Title} ({YYYY-MM-DD})`
 
+Recording principles:
+
+- Every ADR must capture both **Decision (what was chosen)** and **Trace (how it was evaluated and validated)**.
+- Use fixed timing checkpoints:
+  - Task start (`[TODO] -> [DOING]`): add 1-3 lines for `Context/Constraints` and `Trace (initial hypothesis)`
+  - Right before task done (`[DOING] -> [DONE]`): finalize `Options/Decision/Rationale` and enrich `Trace`
+  - After PR merge: append 1-2 lines in `Trace (post-merge check)` with actual outcome/impact
+- Every ADR must include at least one **Evidence link** (commit, PR, or test/log evidence).
+
 ---
 
 ## D001: {Decision Title} ({YYYY-MM-DD})
 
 - **Context**: Problem situation or background
+- **Constraints**: Constraints (time/technical/operations/compatibility)
 - **Options**: Alternatives considered
 - **Decision**: Final choice
 - **Rationale**: Reason for choice
+- **Trace**:
+  - **At DOING start**: Initial reasoning/hypothesis
+  - **Before DONE**: Finalized reasoning behind the selected option
+  - **Post-merge check**: Actual outcome/impact observed
+- **Evidence**:
+  - **Commit**: Commit hash or link
+  - **PR**: PR link
+  - **Test/Log**: Test output/log/screenshot path
 - **Consequences**: Results and impact (optional)

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

@@ -23,7 +23,7 @@
 확인 절차:
 1. 작업 내용을 먼저 공유
 2. 명시적 승인(OK) 대기
-3. 승인 후 실행
+3. 승인 후 실행 (명령 실행은 기본적으로 `npx lee-spec-kit flow <featureRef> --approve <LABEL> --execute`를 사용)
 
 금지:
 - 사용자 응답 없이 임의 진행
@@ -38,6 +38,7 @@
 - 사용자가 다른 질문을 하더라도, 실행 가능한 라벨이 있으면 응답 마지막에 동일 블록을 다시 표시합니다.
 - 실행 가능한 라벨이 없으면 `선택 가능: 없음` + `npx lee-spec-kit context` 재확인을 안내합니다.
 - 사용자 입력에 유효 라벨이 없으면 실행하지 말고 라벨 선택을 다시 요청합니다.
+- 승인된 command 옵션 실행은 `flow --approve <LABEL> --execute` 1회 호출을 기본으로 하며, `context --approve`와 `context --execute --ticket`를 턴/세션 사이로 분리하지 않습니다.
 
 출력 형식:
 

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

@@ -27,6 +27,7 @@ CLI가 출력하는 **`👉 Next Options (Atomic)` 목록에서 단 하나의
 - CLI가 이슈 생성을 지시하면 이슈를 생성합니다.
 - CLI가 명령어를 출력하면 **그대로 복사해 실행**합니다. (standalone 환경에서도 레포 경로가 포함될 수 있습니다)
 - 승인 요청 시 라벨 옵션은 `A: ...` 형식으로 **CLI가 출력한 원문(detail/cmd) 그대로** 공유합니다. 요약/의역하지 않습니다.
+- 승인된 command 옵션을 실행할 때는 세션 불일치 방지를 위해 `npx lee-spec-kit flow <slug|F001|F001-slug> --approve <LABEL> --execute`를 기본으로 사용합니다.
 
 ### 3단계: 반복
 

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

@@ -25,6 +25,7 @@ CLI가 가리키는 **Active Task** 또는 **`👉 Next Options (Atomic)`의 단
 - 태스크 상태 전환/승인 규칙은 `tasks.md`의 **"태스크 규칙"** 섹션을 SSOT로 따릅니다. (예: `[TODO]→[DOING]`, `[DOING]→[DONE]` 시점의 OK)
 - CLI가 명령어를 출력하면 **그대로 복사해 실행**합니다. (standalone 환경에서도 레포 경로가 포함될 수 있습니다)
 - 사용자 응답 포맷(매 응답 말미의 상태/라벨 표시 포함)은 `agents.md`의 **"라벨 응답 계약 (SSOT)"** 을 따릅니다.
+- 승인된 command 옵션 실행은 `npx lee-spec-kit flow <slug|F001|F001-slug> --approve <LABEL> --execute`를 기본으로 사용하고, `context --approve`와 `context --execute --ticket` 분리 실행은 지양합니다.
 
 ### 3단계: 기록 및 반복 (Record & Loop)
 
@@ -42,7 +43,18 @@ CLI가 가리키는 **Active Task** 또는 **`👉 Next Options (Atomic)`의 단
 - 데이터 구조/파일 구조/CLI 출력 규칙이 바뀌었다
 - “나중에 보면 헷갈릴 것 같은” 결정이 있었다
 
-작성 형식은 Feature의 `decisions.md` 템플릿을 따르세요. (Context/Options/Decision/Rationale/Consequences)
+작성 시점 규칙:
+
+- 태스크를 `[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) 태스크/체크리스트 업데이트 + 커밋
 

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

@@ -65,4 +65,4 @@ npx lee-spec-kit status --write
 | `spec.md`      | **무엇을, 왜** 만드는지    | 기능 정의 시   |
 | `plan.md`      | **어떻게** 만드는지 (기술) | 스펙 승인 후   |
 | `tasks.md`     | 구체적인 작업 목록         | 계획 승인 후   |
-| `decisions.md` | 기술 결정 기록 (ADR)       | 개발 중 수시로 |
+| `decisions.md` | 기술 결정 + 판단 근거(Trace) + 증거 링크(ADR) | 개발 중 수시로 (DOING 시작 / DONE 직전 / 머지 후) |

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

@@ -7,12 +7,30 @@
 
 > 형식: `D{번호}: {결정 제목} ({YYYY-MM-DD})`
 
+기록 원칙:
+
+- 모든 ADR은 **Decision(무엇을 선택했는가)** + **Trace(어떻게 고민했고 무엇을 확인했는가)** 를 함께 남깁니다.
+- 작성 타이밍을 고정합니다.
+  - 태스크 시작(`[TODO] -> [DOING]`): `Context/Constraints`와 `Trace(초기 가설)`를 1~3줄로 먼저 기록
+  - 태스크 완료 직전(`[DOING] -> [DONE]`): `Options/Decision/Rationale`를 최종화하고 `Trace`를 보강
+  - PR 머지 후: 실제 결과/영향을 `Trace(머지 후 확인)`에 1~2줄 추가
+- 모든 ADR에는 최소 1개 이상의 **Evidence 링크**(커밋/PR/테스트 로그 중 하나 이상)를 남깁니다.
+
 ---
 
 ## D001: {결정 제목} ({YYYY-MM-DD})
 
 - **Context**: 문제 상황 또는 배경
+- **Constraints**: 제약 조건 (시간/기술/운영/호환성)
 - **Options**: 고려한 대안들
 - **Decision**: 최종 선택
 - **Rationale**: 선택 이유
+- **Trace**:
+  - **DOING 시작 시점**: 초기 판단/가설
+  - **DONE 전 확정 시점**: 선택 근거 최종화
+  - **머지 후 확인**: 실제 결과/영향
+- **Evidence**:
+  - **Commit**: 커밋 해시 또는 링크
+  - **PR**: PR 링크
+  - **Test/Log**: 테스트 결과/로그/스크린샷 경로
 - **Consequences**: 결과 및 영향 (선택사항)