lee-spec-kit 0.7.1 → 0.7.2

package/package.json

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

package/templates/en/common/README.md

@@ -52,6 +52,8 @@ To avoid ambiguity, treat the following as the single source of truth (SSOT).
 - **Features (`docs/features/`)**: implementation scope/progress SSOT
   - `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]`
+    - 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.
   - `decisions.md`: record changes/trade-offs/requirement changes (why it changed) with evidence links
 
@@ -64,6 +66,10 @@ When requirements/scope change, the “what to update” must be explicit in doc
 2. **If still in Idea stage**:
    - `docs/ideas/*.md`: update `PRD Refs` and in/out scope
 3. **If already a Feature**:
+   - If the change started as a `[NON-PRD]` task but becomes a user-facing requirement/scope change, convert it into PRD-backed work:
+     1. backfill/update `docs/prd/*.md`
+     2. update `spec.md` `PRD Refs`
+     3. retag the task as `[PRD-...]` (or add a replacement task if needed)
    - `docs/features/.../spec.md`: update `PRD Refs` + reflect scope change summary
    - `docs/features/.../tasks.md`: add tasks for the change + tag each task as `[PRD-...]` or `[NON-PRD]`
    - `docs/features/.../plan.md`: update if architecture/testing strategy changed

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

@@ -64,6 +64,8 @@ npx lee-spec-kit status --write
 
 - 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]`.
+- 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.
 - Coverage report: `npx lee-spec-kit requirements` (alias: `npx lee-spec-kit prd`)
 
@@ -75,6 +77,10 @@ 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).
 - 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`
+  - Update `spec.md` `PRD Refs`
+  - Retag the task as `[PRD-...]` or add a replacement PRD-backed task
 - If the change impacts PRD/spec/plan, update these too:
   - `docs/prd/*.md` (add/update/deprecate requirement IDs)
   - `spec.md` (`PRD Refs`, scope/AC)

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

@@ -59,3 +59,4 @@
   - 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.
+  - If implementation discovers a better user-facing behavior and the shipped requirement changes, treat that as a PRD update, not a permanent `[NON-PRD]` exception.

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

@@ -10,6 +10,7 @@
 - **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]`.
   - 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-...]`.
 
 ---
 
@@ -60,6 +61,7 @@
 ```
 
 > `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.
+> 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-...]`.
 
 (Recommended) Requirement/scope change task:
 
@@ -74,6 +76,8 @@ Record mid-work changes as **new tasks**, and explicitly list which docs need up
     - decisions.md (why it changed + evidence)
 ```
 
+> Use `[NON-PRD][CHANGE]` only when the change stays internal and does not alter user-visible requirements.
+
 ---
 
 ## Completion Criteria

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

@@ -8,31 +8,32 @@ Core rule: once an idea becomes a Feature, the SSOT moves to `docs/features/`.
 
 ## Conventions
 
-- 1 idea = 1 file (kebab-case recommended)
-  - Example: `login-rate-limit.md`
-  - Example: `admin-dashboard-metrics.md`
+- 1 idea = 1 file
+  - CLI-generated ideas use indexed names like `I001-login-rate-limit.md`
+  - Legacy free-form names like `login-rate-limit.md` can still exist
 - Put at least these at the top:
+  - `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)
   - Target component (optional): `api` / `app` / `worker` / `all`
-  - Status (recommended): `Active | Converted | Dropped`
+  - Status: `Active | Featureized | Dropped`
+  - Feature: `F###-slug` when promoted
 - Only list IDs that already exist in the source PRD/requirements doc. If IDs do not exist yet, backfill the source first.
 
 ---
 
 ## Promotion / Cleanup (Idea → Feature)
 
-1. Create a Feature folder with `npx lee-spec-kit feature <name>`
-2. In the new Feature, record all of the following:
-   - Idea doc path in `spec.md` or `tasks.md` (example: `docs/ideas/login-rate-limit.md`)
-   - `PRD Refs` in `spec.md` (example: `PRD-FR-001, PRD-US-002`)
-   - PRD mapping tags in `tasks.md` task lines like `[PRD-FR-001]` (use `[NON-PRD]` for non-PRD tasks)
-3. Remove the idea from the active list (choose one):
-   - **Recommended**: move to `docs/ideas/archive/` and add `Status: Converted`, `Feature: F00X-...` on top
-   - Or: delete it (only if you don’t need history)
+1. Create an idea doc with `npx lee-spec-kit idea <name>` when you want traceable intake.
+2. Promote it with `npx lee-spec-kit feature <name> --idea I001`
+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]`.
+4. Keep the idea doc for history and update it to `Status: Featureized`, `Feature: F00X-...`
 
-> Tip: archiving is usually better than deleting for traceability (“why this feature exists”).
+> Tip: keeping the source idea doc is usually better than deleting it for traceability (“why this feature exists”).
 
 ---
 

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

@@ -0,0 +1,36 @@
+# Idea: {idea-name}
+
+---
+
+## Overview
+
+- **Idea ID**: {idea-id}
+- **Idea Name**: {idea-name}
+- **Created**: {YYYY-MM-DD}
+- **Status**: Active
+  - Values: Active | Featureized | Dropped
+- **Feature**: -
+- **PRD Refs**: -
+- **Component**: {component}
+
+---
+
+## Context
+
+{{description}}
+
+(Why is this idea worth exploring?)
+
+---
+
+## Rough Scope
+
+- In:
+- Out:
+
+---
+
+## Promotion Notes
+
+- What should stay true if this becomes a feature?
+- What risks or unanswered questions remain?

package/templates/ko/common/README.md

@@ -52,6 +52,8 @@ npx lee-spec-kit context --json-compact
 - **Features (`docs/features/`)**: 구현 범위/진행 SSOT
   - `spec.md`: 범위 정의 + `PRD Refs`(기능이 커버하는 PRD ID 목록)
   - `tasks.md`: 태스크 단위로 PRD ID를 태그(`[PRD-FR-001]`)로 매핑하거나, PRD 무관 태스크는 `[NON-PRD]`로 표시
+    - `[NON-PRD]`는 refactor, rename, tooling, 테스트, cleanup 같은 내부 작업에만 사용합니다.
+    - 태스크가 사용자 동작, acceptance criteria, 기능 범위를 바꾸게 되면 `[NON-PRD]`로 끝내지 말고 PRD를 backfill한 뒤 `[PRD-...]`로 연결합니다.
   - 레거시 문서에 PRD ID가 없다면, 먼저 원문 요구사항 문서에 ID를 backfill한 뒤 Feature 문서를 연결합니다.
   - `decisions.md`: 변경/트레이드오프/요구사항 변경(왜 바뀌었는지) 기록 + Evidence 링크
 
@@ -64,6 +66,10 @@ npx lee-spec-kit context --json-compact
 2. **Idea 단계라면**:
    - `docs/ideas/*.md`: `PRD Refs` 및 범위(포함/제외) 갱신
 3. **Feature 단계라면**:
+   - 시작은 `[NON-PRD]`였더라도, 진행 중 사용자 요구/동작/범위 변경으로 바뀌었다면 PRD 기반 작업으로 승격합니다:
+     1. `docs/prd/*.md` backfill/수정
+     2. `spec.md`의 `PRD Refs` 갱신
+     3. 해당 태스크를 `[PRD-...]`로 재태깅 (필요하면 대체 태스크 추가)
    - `docs/features/.../spec.md`: `PRD Refs` 갱신 + 스코프 변경 요약 반영
    - `docs/features/.../tasks.md`: 변경을 반영하는 새 태스크 추가 + 각 태스크에 `[PRD-...]` 또는 `[NON-PRD]` 태그 부여
    - `docs/features/.../plan.md`: 아키텍처/테스트 전략이 바뀌면 함께 갱신

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

@@ -64,6 +64,8 @@ npx lee-spec-kit status --write
 
 - PRD 문서(`docs/prd/*.md`)에 `PRD-FR-001` 같은 요구사항 ID를 부여하세요.
 - `tasks.md`의 각 태스크 라인에 `[PRD-FR-001]` 태그로 연결하세요. PRD와 무관한 태스크는 `[NON-PRD]`를 사용하세요.
+- `[NON-PRD]`는 refactor, 테스트 전용 작업, tooling, rename, cleanup 같은 내부 구현 작업에만 사용하세요.
+- 변경이 사용자 동작, acceptance criteria, 범위를 바꾸면 PRD를 먼저 갱신하고 태스크도 `[PRD-...]`로 다시 연결하세요.
 - 단, 태스크 문서에서 PRD ID를 임의 생성하지 않습니다. 먼저 PRD 원문에 정의하고, 레거시 문서는 원문 ID backfill 후 연결하세요.
 - 커버리지 리포트: `npx lee-spec-kit requirements` (alias: `npx lee-spec-kit prd`)
 
@@ -75,6 +77,10 @@ npx lee-spec-kit status --write
 
 - 변경은 **새 태스크로 추가**합니다. (`[DONE]` 태스크를 고치지 말고 새 태스크를 만드세요)
 - 변경 태스크에는 `[PRD-...]` 또는 `[NON-PRD]` 태그를 반드시 붙입니다. (권장: `[CHANGE]` 태그 추가)
+- 내부 검토로 시작했더라도, 최종적으로 사용자 요구/동작 변경이 되면 `[NON-PRD]`로 남기지 않습니다.
+  - `docs/prd/*.md`를 backfill/수정
+  - `spec.md`의 `PRD Refs` 갱신
+  - 태스크를 `[PRD-...]`로 재태깅하거나 대체 태스크 추가
 - 변경이 PRD/스펙/설계에 영향을 주면 아래도 함께 갱신합니다:
   - `docs/prd/*.md` (요구사항 ID 추가/수정/Deprecated)
   - `spec.md` (`PRD Refs`, 스코프/AC)

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

@@ -59,3 +59,4 @@
   - 이미 원문 요구사항 문서에 정의된 ID만 적으세요. `spec.md`나 `tasks.md`에서 임의로 PRD ID를 만들지 않습니다.
   - 레거시 요구사항 문서에 아직 PRD ID가 없다면, 먼저 원문에 ID를 backfill한 뒤 이 필드와 `tasks.md` 태스크 태그를 함께 갱신하세요.
   - 요구사항/스코프 변경 시 PRD 문서 + 이 필드 + `tasks.md` 태스크 태그를 함께 갱신하세요.
+  - 구현 중 더 나은 사용자 동작이 발견되어 최종 요구사항이 바뀌었다면, 이를 영구적인 `[NON-PRD]` 예외로 두지 말고 PRD 업데이트로 취급하세요.

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

@@ -10,6 +10,7 @@
 - **PRD 매핑(권장)**: 각 태스크 라인에 `[PRD-FR-001]` 같은 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-...]`로 태깅하세요.
 
 ---
 
@@ -60,6 +61,7 @@
 ```
 
 > 위 예시의 `PRD-FR-001`은 이미 PRD 원문에 존재하는 ID를 뜻합니다. 아직 정의되지 않았다면 태스크에 먼저 넣지 마세요.
+> 처음엔 탐색/내부 작업이었더라도 제품 요구사항 변경으로 이어졌다면, `NON-PRD`로 두지 말고 PRD를 먼저 갱신한 뒤 `[PRD-...]`로 재태깅하세요.
 
 (권장) 요구사항/범위 변경 태스크:
 
@@ -74,6 +76,8 @@
     - decisions.md (변경 사유 + Evidence)
 ```
 
+> `[NON-PRD][CHANGE]`는 내부 변경으로 끝날 때만 사용하세요. 사용자에게 보이는 요구사항 변경이면 PRD backfill이 먼저입니다.
+
 ---
 
 ## 완료 조건

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

@@ -8,31 +8,32 @@ Feature로 발전하기 전의 아이디어 / To-do / 실험 기록을 모아두
 
 ## 작성 규칙
 
-- 1 아이디어 = 1 파일 (kebab-case 권장)
-  - 예: `login-rate-limit.md`
-  - 예: `admin-dashboard-metrics.md`
+- 1 아이디어 = 1 파일
+  - CLI로 생성한 문서는 `I001-login-rate-limit.md` 같은 indexed 이름을 사용합니다
+  - 기존의 `login-rate-limit.md` 같은 자유 형식 파일도 유지할 수 있습니다
 - 상단에 최소한 아래 메타 정보를 둡니다:
+  - `Idea ID` (`I###` 형식의 indexed idea인 경우)
   - 목적/배경
   - 대략 범위(뭘 할지/안 할지)
   - PRD Refs(권장): `PRD-FR-001, PRD-US-002` (PRD와 무관하면 `NON-PRD` 명시)
   - 대상 컴포넌트(필요 시): `api` / `app` / `worker` / `all`
-  - 상태(권장): `Active | Converted | Dropped`
+  - 상태: `Active | Featureized | Dropped`
+  - Feature: 승격되면 `F###-slug`
 - `PRD Refs`에는 이미 원문 PRD/요구사항 문서에 정의된 ID만 적습니다. 아직 ID가 없다면 원문부터 backfill하세요.
 
 ---
 
 ## 승격/정리 규칙 (Idea → Feature)
 
-1. `npx lee-spec-kit feature <name>`로 Feature 폴더 생성
-2. 새 Feature에 아래를 모두 남깁니다
-   - `spec.md` 또는 `tasks.md`에 아이디어 문서 경로 (예: `docs/ideas/login-rate-limit.md`)
-   - `spec.md`의 `PRD Refs`(예: `PRD-FR-001, PRD-US-002`)
-   - `tasks.md` 태스크 라인에 `[PRD-FR-001]` 같은 PRD ID 태그 (PRD와 무관한 태스크는 `[NON-PRD]`)
-3. 아이디어 문서는 **목록에서 제거**합니다 (둘 중 하나 선택):
-   - **권장**: `docs/ideas/archive/`로 이동 후 상단에 `Status: Converted`, `Feature: F00X-...` 기록
-   - 또는: 완전히 삭제 (히스토리가 필요 없을 때만)
+1. 추적 가능한 intake가 필요하면 `npx lee-spec-kit idea <name>`로 아이디어 문서를 먼저 만듭니다
+2. Feature 승격 시 `npx lee-spec-kit feature <name> --idea I001`를 사용합니다
+3. `--idea`를 사용하면 새 Feature의 `spec.md`에 source idea 경로가 자동 기록됩니다
+4. 승격 후에도 다음은 직접 채워야 합니다
+   - `spec.md`의 `PRD Refs`
+   - `tasks.md` 태스크 라인의 PRD ID 태그(`[PRD-FR-001]` 등)
+5. 아이디어 문서는 삭제하지 말고 `Status: Featureized`, `Feature: F00X-...`로 남기는 것을 권장합니다
 
-> 💡 완전 삭제 대신 archive를 권장합니다: “왜 이 Feature가 생겼는지” 추적에 도움이 됩니다.
+> 💡 source idea 문서를 남겨두면 “왜 이 Feature가 생겼는지” 추적하기 쉽습니다.
 
 ---
 

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

@@ -0,0 +1,36 @@
+# Idea: {idea-name}
+
+---
+
+## 개요
+
+- **Idea ID**: {idea-id}
+- **Idea Name**: {idea-name}
+- **Created**: {YYYY-MM-DD}
+- **Status**: Active
+  - 값: Active | Featureized | Dropped
+- **Feature**: -
+- **PRD Refs**: -
+- **Component**: {component}
+
+---
+
+## 배경
+
+{{description}}
+
+(왜 이 아이디어를 검토할 가치가 있는지)
+
+---
+
+## 대략 범위
+
+- In:
+- Out:
+
+---
+
+## 승격 메모
+
+- Feature가 되어도 유지되어야 할 점은 무엇인가?
+- 아직 남아 있는 리스크나 미해결 질문은 무엇인가?