lee-spec-kit 0.9.11 → 0.9.14

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

@@ -92,10 +92,11 @@
 
 ---
 
-## Knowledge Sync
+## Knowledge Publication
 
 - **Policy**: Derived from `.lee-spec-kit.json` `experimental.openwiki`
-- **Receipt**: `.lee-spec-kit/openwiki-sync.json`
+- **Lifecycle**: After verified local integration, follow `knowledge publish` before cleanup. GitHub uses explicitly configured base-branch push CI (`knowledge ci`). With local completion strategy `none`, no automatic publication runs.
+- **Receipt**: Stored inside the returned publication artifact; do not add generated Wiki or receipts to Feature commits or reviews.
 
 ---
 
@@ -115,3 +116,5 @@
 | Command | Last Run (Local, YYYY-MM-DD) | Result |
 | --- | --- | --- |
 | `{test command you ran}` | `-` | `{PASS/FAIL summary}` |
+
+Completion evidence includes all planned checks (build, typecheck, lint, tests) and manual verification. The executable baseline is workflow.featureChecks. Record an explicit skip reason instead of claiming unexecuted checks passed.

package/templates/ko/common/README.md

@@ -66,9 +66,9 @@ npx lee-spec-kit docs get agents --json
 
 모든 Plan은 명시적인 `NONE`까지 포함해 `Curated Documentation Impact`를 완료해야 합니다. 모든 `UPDATE` 또는 `ADD` 대상은 하나 이상의 task `Docs` 목록에 연결하고 완료 전에 활성 Feature scope로 커밋합니다. 이 전파 규칙은 OpenWiki 활성화 여부와 무관하게 적용됩니다.
 
-Schema 2는 자주 쓰는 네 영역을 기본 판정으로 유지하고, 보안·API/데이터 계약·디자인 시스템·릴리스 운영·관측성·에이전트 정책 같은 프로젝트별 문서만 `Additional Curated Impacts`에 유형을 지정해 선언합니다. 완료 시 lee-spec-kit은 실제 Feature diff에서 바뀐 주요 curated 파일을 선언 대상과 대조한 뒤 OpenWiki 생성 또는 Feature 리뷰로 넘어갑니다. 이 검사는 조용히 바뀐 문서를 잡지만, 변경되지 않은 문서가 의미상 낡았는지 판단하지는 않습니다. 도입 시 기존 PRD·아키텍처·온보딩·운영·디자인·에이전트 정책 문서를 한 번 수동으로 기준선 점검해야 합니다.
+Schema 2는 자주 쓰는 네 영역을 기본 판정으로 유지하고, 보안·API/데이터 계약·디자인 시스템·릴리스 운영·관측성·에이전트 정책 같은 프로젝트별 문서만 `Additional Curated Impacts`에 유형을 지정해 선언합니다. 완료 시 lee-spec-kit은 실제 Feature diff에서 바뀐 주요 curated 파일을 선언 대상과 대조한 뒤 Feature 리뷰로 넘어갑니다. OpenWiki 생성은 별도로 통합 후 실행합니다. 이 검사는 조용히 바뀐 문서를 잡지만, 변경되지 않은 문서가 의미상 낡았는지 판단하지는 않습니다. 도입 시 기존 PRD·아키텍처·온보딩·운영·디자인·에이전트 정책 문서를 한 번 수동으로 기준선 점검해야 합니다.
 
-`experimental.openwiki`가 `true`이면 task checkpoint 뒤에 Knowledge 준비·동기화·커밋 stage와 Feature 리뷰가 필수로 붙습니다. 누락 또는 `false`면 이 stage들은 전혀 추가되지 않습니다. `lee-spec-kit knowledge sync`만 사용하고 생성 페이지를 손으로 수정하거나 workflow에서 OpenWiki를 직접 호출하지 않습니다.
+`experimental.openwiki`가 true이면 local은 통합 검증 후 cleanup 전에 revision별 Knowledge artifact를 게시합니다. GitHub는 `knowledge ci`로 준비한 기준 브랜치 push CI에서 생성합니다. 생성 Wiki는 Feature 커밋·리뷰에 포함하지 않습니다. 반환된 `knowledge publish`를 실행하고 실패는 `knowledge status`로 확인합니다.
 
 OpenWiki는 sandboxed renderer가 아니라 외부 에이전트입니다. 신뢰할 수 있는 저장소와 적절히 격리한 실행 환경에서만 활성화하고, 로컬·ignored secret이 접근 가능한 환경에 남지 않도록 관리합니다.
 
@@ -155,7 +155,7 @@ OpenWiki 실험 기능은 별도의 단일 옵션 `--openwiki true|false`로 제
 - `docsRepo` ("embedded" | "standalone"): Docs 관리 방식
 - `pushDocs` (boolean, optional): `docsRepo: "standalone"`일 때만 생성 (원격 push 여부)
 - `docsRemote` (string, optional): `pushDocs: true`일 때만 생성 (원격 레포 URL)
-- `experimental.openwiki` (boolean): 완전한 필수 OpenWiki Knowledge 흐름을 켜는 단일 스위치. 누락/`false`면 비활성화되고, `true`면 Node.js 22+, OpenWiki `>=0.5.0 <1.0.0`, Knowledge 동기화·receipt·커밋·Feature 리뷰를 요구
+- `experimental.openwiki` (boolean): 통합 후 Knowledge artifact 게시를 활성화합니다. Node.js 22+, OpenWiki `>=0.5.0 <0.6.0`가 필요합니다. 생성물 커밋이나 별도의 Feature 리뷰를 강제하지 않습니다.
 - `workflow.agentExecution.task` (object): 태스크 구현 위임 설정
   - `enabled`: 각 `task_execute`를 서브에이전트에게 위임할지 여부. 새 프로젝트의 기본값은 `true`이며, 이 설정이 생기기 전 프로젝트는 명시적으로 켜기 전까지 꺼진 상태를 유지
   - `type`: 현재 `"subagent"`만 지원
@@ -295,3 +295,29 @@ OpenWiki 실험 기능은 별도의 단일 옵션 `--openwiki true|false`로 제
   }
 }
 ```
+
+
+### Feature 완료 검사 설정 (0.9.14)
+
+`workflow.featureChecks`는 로컬 완료 시 실행할 프로젝트 공통 검사입니다.
+빈 목록은 검사 통과를 뜻하지 않으며, 완료 전에 설정해야 합니다.
+`npx lee-spec-kit config --checks-detect`로 Node 프로젝트의 검사 후보를 확인하고,
+검토한 JSON 배열을 `config --checks-file <path>`로 저장합니다.
+프로젝트 경로가 모호하면 감지 시 `--project-root <path>`를 지정합니다.
+감지는 파일만 읽으며 스크립트를 실행하지 않습니다.
+
+빌드 결과물을 만드는 프로젝트는 build를 포함합니다. test가 이미 build를 실행한다면
+Plan에 근거를 기록하고 중복 명령을 제외합니다. 중첩된 스크립트의 실행 범위는 자동 추정하지 않습니다.
+실행할 검사가 없는 프로젝트는 `config --checks-skip-reason <reason>`으로 사유를 명시합니다.
+컴포넌트별 설정은 `--component <name>`으로 저장합니다(`workflow.featureChecksByComponent`).
+별도 설정이 없는 컴포넌트는 공통 검사를 사용합니다.
+
+`featureChecks`가 없을 때만 구형 `postMergeChecks`를 완료 전 검사로 읽습니다.
+`update`는 기존 목록을 이전하며 명령을 추가하거나 기존 Feature 검사 목록을 덮어쓰지 않습니다.
+잘못된 항목은 삭제하지 않고 검증 오류로 드러냅니다. 검사 설정을 변경하면 통합 전 Feature는
+재검증해야 합니다. 정리까지 끝난 Feature의 과거 완료 상태는 유지합니다.
+
+Plan의 Verification Contract에는 실제 적용되는 공통 검사와 추가 검사를 적습니다.
+추가 자동 검사는 실행 설정에도 등록하고 수동/UI 검증은 별도 증거를 기록합니다.
+설정 변경은 최종 리뷰와 검증 전에 완료합니다. 로컬 main 동기화는 검사 전에 수행하며,
+이 단계가 원격 브랜치를 자동 fetch하는 것은 아닙니다.

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

@@ -56,8 +56,8 @@
 - 사람이 관리하는 아키텍처·온보딩·운영·디자인·에이전트 정책 문서는 프로젝트 전체 설명과 정책의 기준입니다. 실행 가능한 사실은 tracked 코드·스키마·마이그레이션·설정과 일치해야 하며, 테스트는 검증 증거입니다.
 - OpenWiki는 파생된 온보딩·코드 탐색 증거이며 요구사항·정책·런타임 사실의 기준이 아닙니다.
 - 모든 Plan에서 명시적인 `NONE`을 포함해 `Curated Documentation Impact` 판정을 완료합니다. 모든 `UPDATE` 또는 `ADD` 대상은 하나 이상의 task `Docs` 항목에서 연결하고 활성 Feature scope로 커밋합니다.
-- `experimental.openwiki`는 단일 스위치입니다. 누락 또는 `false`면 OpenWiki 동작이 없고, `true`면 Knowledge 준비·동기화·전용 커밋·Feature 리뷰가 모두 필수입니다.
-- 활성화된 경우 저장소 Knowledge 생성·갱신은 `npx lee-spec-kit knowledge sync <featureRef> --json`로만 실행합니다. 생성된 결과를 확인하는 read-only `openwiki visualize ./openwiki`는 직접 실행할 수 있지만 생성 페이지를 손으로 수정하지 않습니다.
+- `experimental.openwiki=true`이면 통합 후 Knowledge를 게시합니다. local은 머지 검증 후 cleanup 전에 반환된 `knowledge publish`를 실행하고, GitHub는 `knowledge ci`로 준비한 기준 브랜치 push CI에서 실행합니다. 누락 또는 false이면 이 흐름을 사용하지 않습니다.
+- 별도 worktree에서 생성하고 코드 revision별 artifact로 저장합니다. 생성 Wiki와 receipt를 Feature 커밋이나 Feature 리뷰 필수 문서에 추가하지 않습니다. PRD·아키텍처 등 사람이 관리하는 문서는 Feature에서 함께 수정합니다.
 
 ## 선택적 UI/UX 디자인 정책
 
@@ -81,12 +81,12 @@
 - 조용하거나 파일을 변경하지 않았다는 이유만으로 실행 중인 서브에이전트를 중단·교체·포기하지 않습니다. 사용자의 명시적 중단 요청, 종결 실패·취소, 또는 복구 불가능한 런타임 상태가 있을 때만 중단합니다.
 - `workflow.agentReview.maxRounds`는 Plan/task/Feature 게이트별 fresh 리뷰의 최대 실행 횟수입니다. 마지막 허용 리뷰가 `changes_requested`이면 지적을 한 번 반영하지만 변경된 target을 다시 리뷰하지 않으며, 남은 finding과 리뷰 이후 target 변경을 잔여 위험으로 보존하고 사용자 리뷰 승인 토큰 없이 게이트를 자동 완료합니다. 예를 들어 `maxRounds=1`이면 Round 1 리뷰와 지적 반영 후 Round 2 없이 계속합니다. `blocked` 결정은 자동 완료하지 않습니다.
 - spec / plan / tasks 승인, issue 생성, branch 생성은 구현 전 하드 게이트로 취급합니다.
-- `knowledge_setup`, `knowledge_sync`, `knowledge_commit`이 반환되면 그대로 수행합니다. Feature 리뷰 전에 검증된 Knowledge surface만 반환된 정확한 subject로 커밋합니다.
+- 통합 후 `knowledge_sync` action의 `knowledge publish` 명령을 따릅니다. 생성 실패 시 검증된 머지와 마지막 정상 게시본을 유지합니다. `knowledge status`로 확인하고 재시도합니다. `knowledge sync`는 기존 in-place 호환 명령이며 Feature workflow에서 사용하지 않습니다.
 - standalone 모드에서는 `git worktree add`를 직접 만들지 말고 `workflow-stage`의 정확한 `nextAction.command`를 실행해 managed workspace 경로, stale 디렉터리 정리, `.env`/`.env.*` 복사 단계가 일관되게 유지되도록 합니다.
 - local 모드에서는 구현 승인 직후 종료하지 않습니다. `workflow-stage`가 반환하는 정확한 `local verify`, `local merge`, `local cleanup` 명령을 따라 검증·통합·정리가 확인되어 `done`이 될 때까지 진행합니다. `feature_remediation` 단계에서는 Feature worktree 수정이 명시적으로 허용됩니다.
 - `local-ff` 또는 `local-squash` workflow에서 `local_merge` 승인이 필요하면 구현 승인과 local merge 승인을 구분합니다. 첫 번째 승인은 구현 결과를 수락하고, 두 번째 승인은 설정된 통합 전략, post-merge 검사, local cleanup을 허가합니다.
 - 동작이나 범위가 바뀌는 코드 변경이 있으면 같은 턴 안에서 feature 문서를 같이 동기화합니다.
-- `git commit` 전에 `npx lee-spec-kit commit-audit --json`를 사용합니다. Feature-scoped commit은 Issue가 연결되어 있으면 `#123`, Issue 없는 local workflow에서는 `F027` 같은 안정적인 Feature ID를 scope로 사용합니다.
+- `git commit` 전에 `npx lee-spec-kit commit-audit --json`를 사용합니다. Feature-scoped commit은 Issue가 연결되어 있으면 `#123`, Issue 없는 local workflow에서는 `K7M2Q9RX4DAB` 같은 안정적인 Feature ID를 scope로 사용합니다.
 - 기본 docs sync 검사는 `npx lee-spec-kit workflow-audit --json`를 사용합니다.
 
 ## 승인 규칙

package/templates/ko/common/agents/git-workflow.md

@@ -65,11 +65,11 @@ Feature scope는 아래 canonical 형식 중 하나만 사용하며, 에이전
 ```text
 feat(#123): 사용자 인증 구현
 docs(#123): 인증 스펙 명확화
-feat(F027): 알림 설정 구현
-docs(F027): 알림 문서 업데이트
+feat(K7M2Q9RX4DAB): 알림 설정 구현
+docs(K7M2Q9RX4DAB): 알림 문서 업데이트
 ```
 
-local Feature의 scope는 안정적인 Feature ID(`F027`)입니다. 전체 폴더 ref인 `F027-notification-settings`를 scope로 사용하지 않으며, `docs: F027 ...`처럼 Feature scope를 생략한 커밋도 canonical 형식이 아닙니다.
+local Feature의 scope는 안정적인 Feature ID(`K7M2Q9RX4DAB`)입니다. 전체 폴더 ref인 `K7M2Q9RX4DAB-notification-settings`를 scope로 사용하지 않으며, `docs: K7M2Q9RX4DAB ...`처럼 Feature scope를 생략한 커밋도 canonical 형식이 아닙니다.
 
 ### Type 목록
 
@@ -109,14 +109,8 @@ worktree 경로를 직접 만들지 말고 반환된 `nextAction.command`를 실
 아래에 worktree를 만들고, Git에 등록되지 않은 이전 managed 디렉터리를 정리하며,
 새 worktree에 대상 파일이 없을 때 프로젝트 루트의 기존 `.env`/`.env.*` 파일을 복사합니다.
 
-```bash
-# embedded fallback 전용: 전용 worktree + 브랜치 생성
-mkdir -p .worktrees
-git worktree add -b feat/{issue-number}-{feature-name} .worktrees/feat-{issue-number}-{feature-name}
+새 embedded Feature는 `workspace_checkpoint` 안내에 따라 해당 Feature의 계획 문서를 먼저 커밋합니다. 이후 반환된 worktree 생성 명령을 실행하고 지정된 작업 경로에서 이어갑니다. Feature 문서가 없는 HEAD에서 worktree를 직접 만들지 않습니다.
 
-# 이미 브랜치가 존재하면 worktree만 연결
-git worktree add .worktrees/feat-{issue-number}-{feature-name} feat/{issue-number}-{feature-name}
-```
 
 > 이후 작업은 `workflow-stage`가 반환한 worktree 경로에서 진행하세요.
 
@@ -131,17 +125,17 @@ git worktree add .worktrees/feat-{issue-number}-{feature-name} feat/{issue-numbe
 
 #### Standalone 모드 커밋 가이드
 
-workflow에 따라 scope를 선택합니다. Issue가 연결되어 있으면 `#123`, Issue 없는 local Feature라면 `F027` 같은 Feature ID를 사용합니다.
+workflow에 따라 scope를 선택합니다. Issue가 연결되어 있으면 `#123`, Issue 없는 local Feature라면 `K7M2Q9RX4DAB` 같은 Feature ID를 사용합니다.
 
 1. **Project 커밋** (코드 변경사항이 있는 경우)
 
    ```bash
-   git commit -m "feat(F027): 기능 구현"
+   git commit -m "feat(K7M2Q9RX4DAB): 기능 구현"
    ```
 
 2. **Docs 커밋** (문서 변경사항이 있는 경우 - **Docs 레포에서 실행**)
    ```bash
-   git commit -m "docs(F027): 기능 구현 문서 업데이트"
+   git commit -m "docs(K7M2Q9RX4DAB): 기능 구현 문서 업데이트"
    ```
 
 > 💡 **Core Rule**: 태스크 완료 시점에는 **변경된 모든 레포지토리**가 커밋되어야 합니다.
@@ -178,3 +172,11 @@ workflow에 따라 scope를 선택합니다. Issue가 연결되어 있으면 `#1
 
 - [ ] Auto-delete head branches
 - [ ] Squash merging only
+
+## Feature 격리와 통합
+
+새 GitHub Feature는 SDD 계획 전에 선택한 Issue 번호를 ID로 사용합니다. local ID는 12자리 무작위 값이며 기존 F번호 문서는 호환됩니다. 한 Feature는 한 담당자가 한 Task씩 진행하고, 다른 Feature끼리는 병렬로 개발할 수 있습니다.
+
+새 standalone Feature는 초기 문서를 커밋한 뒤 `workspace prepare`가 반환한 docsDirectory에서 문서를 작성합니다. 기본 문서 체크아웃은 base 브랜치를 유지합니다. local은 코드 통합 검증 → 문서 통합 → 활성화된 경우 OpenWiki 발행 → 정리 순서를 따릅니다. 문서 통합 기록은 내용 변경 없는 Git 커밋으로 남아 문서 저장소 clone 후에도 복원됩니다. base가 앞서가면 `workspace sync-docs`로 반영하고 충돌을 재검증합니다. 중간 실패를 완료로 처리하지 않습니다.
+
+명시적 Task ID에는 task claim/status/transition/release와 최신 해시·세션 토큰을 사용합니다. ID 없는 레거시 Task는 문서에서 상태를 변경합니다. CI에서 feature-audit를 실행하고 sharedDocumentationWarnings의 공통 문서 수정 대상을 검토합니다. PR 병합 재시도 중 자동 rebase·force-push를 하지 않습니다.

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

@@ -8,10 +8,7 @@
 
 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 "<설명>"`으로 생성합니다
+3. Feature 폴더가 없다면 GitHub 모드에서는 `feature <name> --issue <number>`로 Issue를 먼저 연결합니다. 새 Issue가 필요하면 제목·본문을 공유하고 승인받은 뒤 `--create-issue --desc "<요약>" --confirm OK`로 생성합니다. local 모드는 `feature <name> -d "<설명>"`으로 무작위 ID를 생성합니다. 사용자가 Idea를 명시한 경우에만 `--idea <ref>`를 추가합니다. 새 F번호를 배정하지 않습니다.
 4. 활성 feature를 정하고 `spec.md`, `plan.md`, `tasks.md`, `decisions.md`를 읽습니다.
 5. 다음 workflow 액션을 시작하기 전에 `npx lee-spec-kit workflow-stage <feature-ref> --json`를 실행합니다.
 
@@ -36,3 +33,11 @@
 1. 이슈/PR 번호나 상태를 임의로 만들지 않습니다.
 2. 범위, 동작, evidence가 바뀌었는데 필요한 문서 업데이트를 건너뛰지 않습니다.
 3. unmanaged docs 산출물은 feature 폴더로 정규화하거나 allowlist하기 전까지 active workflow SSOT로 취급하지 않습니다.
+
+## Single-owner collaboration
+
+- Select the Feature by ID or an unambiguous branch; never choose by recency or numeric order.
+- New Features use code worktrees. For standalone docs, commit the seed and follow `workspace prepare`; work from the returned docsDirectory. Follow returned docs integration/cleanup steps after code integration.
+- Claim one owner session with `task claim`; use `task status` or workflow-stage's tasksHash and `task transition --session <token> --expected-hash <hash>`. Release the session at handoff. Never run two DOING/REVIEW tasks in one Feature.
+- Run `feature-audit --enforce --json` alongside workflow-audit; use `--base-ref <fetched-base>` in CI to check immutable identity. Resolve sharedDocumentationWarnings against the latest base.
+- If the base advances, sync it explicitly in the Feature worktree and reverify/review. Never automatically rebase and force-push during merge retries.

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

@@ -1,11 +1,13 @@
+> 새 Feature는 SDD 문서보다 GitHub Issue를 먼저 생성하거나 선택합니다. `feature <slug> --issue <number> --owner <email>`을 사용합니다. 새 Issue가 필요하면 제목·본문을 공유하고 승인받은 뒤 `--create-issue --desc <본문> --confirm OK`로 생성합니다. 아래 절차는 기존 F번호 Feature 전용이며, Issue 생성은 구현 승인이 아닙니다.
+
 # GitHub Issue 생성 프로세스
 
 GitHub Issue를 생성할 때 따르는 가이드입니다.
-실행 상태 SSOT는 Feature 폴더의 `issue.md`입니다.
+아래 레거시 절차의 실행 상태 SSOT는 Feature 폴더의 `issue.md`입니다. 새 Feature의 Issue 접수에는 아래 SDD 작성 완료 조건을 적용하지 않습니다.
 
 ---
 
-## 사전 조건
+## 기존 F번호 Feature의 사전 조건
 
 - [ ] `spec.md` 작성 완료
 - [ ] `plan.md` 작성 완료
@@ -15,7 +17,7 @@ GitHub Issue를 생성할 때 따르는 가이드입니다.
 
 ---
 
-## 단계
+## 기존 Feature의 단계
 
 ### 1. `issue.md` 초안 준비
 

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

@@ -19,6 +19,8 @@ Pull Request를 생성할 때 따르는 가이드입니다.
 
 Pre-PR 리뷰에서 서브에이전트가 항상 수행하는 최소 기준입니다. 리뷰 스킬 이름에 의존하지 않습니다.
 
+Curated Documentation Impact의 NONE을 포함한 근거를 검토합니다. 발견한 불일치마다 수정 완료 또는 실제 후속 task/Feature/issue 연결을 확인하고 문서 경로·근거·미해결 질문·보류 이유를 점검합니다. 잔여 위험 문구만으로는 후속 추적이 아닙니다. 처리 누락은 finding으로 보고하며 코드나 파생 Knowledge로 제품 의도를 추정하지 않습니다. 기존 리뷰 횟수와 승인 정책은 그대로 적용합니다.
+
 `workflow-stage --json`의 `nextAction.executor`가 `subagent`이면 fresh context의 읽기 전용 서브에이전트에게 리뷰를 위임합니다. `model: inherit`은 현재 모델을 상속한다는 뜻이며, 그 외 값은 서브에이전트 생성 시 모델 override로 사용합니다. 지정 모델을 사용할 수 없으면 `onUnavailable` 정책(`inherit` 또는 `error`)을 따릅니다.
 
 1. `spec.md` / `plan.md` / `tasks.md` 기준으로 변경 범위 정합성을 확인하고, 구현이 원래 목적에 맞는지 점검합니다.

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

@@ -34,6 +34,8 @@
 
 ## 3. 문서 동기화
 
+발견한 문서 불일치는 `decisions.md`에만 남기고 종료하지 않습니다. 현재 사실의 명백한 오류가 승인 범위 안에 있으면 `UPDATE`/`ADD`와 task `Docs`로 연결합니다. 제품 의도 확인이나 범위 확장이 필요하면 충돌한 문서 경로·근거, 확인할 질문, 보류 이유와 실제 후속 task/Feature/issue 참조를 기록합니다. 없는 번호나 승인을 만들지 않습니다. 추적 항목 생성에 승인이 필요하면 사용자 확인 전 해결된 것으로 기록하지 않습니다. `NONE`의 근거에는 알려진 불일치가 없거나, 남은 불일치가 해당 후속 항목으로 추적되고 있음을 설명합니다. 코드나 OpenWiki에 맞추기 위해 미구현 PRD 요구를 삭제하지 않습니다.
+
 - `spec.md`: 사용자-visible scope 또는 acceptance criteria가 바뀌면 갱신합니다
 - `plan.md`: 아키텍처, 파일 구조, 테스트 전략이 바뀌면 갱신합니다
 - `decisions.md`: 비자명한 결정, 트레이드오프, 호환성 처리, 사용자 요청으로 바뀐 동작을 기록합니다
@@ -58,3 +60,7 @@
 2. `[DONE]` 태스크를 다시 쓰지 않습니다.
 3. unmanaged docs 산출물은 정규화하거나 allowlist하기 전까지 active workflow 상태로 취급하지 않습니다.
 4. issue 생성, branch 생성, 그 이전 단계가 막혀 있으면 구현을 시작하지 않습니다.
+
+## 세션과 상태 변경 명령
+
+명시적 Task ID가 있으면 메인 에이전트가 `task claim <id> --json`으로 세션을 확보하고 `task status <id> --json`으로 문서 해시를 읽습니다. `task transition <id> <task-id> --from <상태> --to <상태> --session <토큰> --expected-hash <해시> --json`으로 workflow-stage가 선택한 Task의 상태를 변경합니다. Acceptance·Checklist·리뷰 근거를 먼저 기록하고 변경 후 해시를 다시 읽습니다. 오래된 해시, 담당자 불일치, 다른 활성 세션은 변경을 차단합니다. 인계 시 `task release <id> --session <토큰>`을 실행합니다. 별도 승인 단계를 추가하지 않습니다. 명시적 ID가 없는 레거시 Task는 기존 workflow 게이트에 따라 문서에서 상태를 수정합니다.

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

@@ -59,7 +59,7 @@ npx lee-spec-kit workflow-stage <feature-ref> --json
 
 Plan 검수 또는 승인 전에 Schema 2 `Curated Documentation Impact`를 완료합니다. 네 기본 영역을 모두 판정하고, 프로젝트별 추가 영역이 적용될 때만 typed `Additional Curated Impacts`를 사용합니다. 추가 영역의 명시적인 `NONE`은 해당 범주가 없음을 검토했다는 증거입니다. 모든 `UPDATE` 또는 `ADD` 대상은 하나 이상의 task `Docs`와 커밋된 Feature diff에 함께 있어야 합니다. 기존 프로젝트는 Feature별 검사를 신뢰하기 전에 한 번의 수동 baseline reconciliation을 수행합니다.
 
-`experimental.openwiki=true`이면 완료된 모든 task checkpoint 뒤에 필수 `knowledge_setup`, `knowledge_sync`, `knowledge_commit` stage를 거쳐 Feature 리뷰로 이동합니다. Feature reviewer는 `openwiki/index.md`, 검증 receipt, Plan이 선언한 모든 curated target을 받으며, 생성된 Knowledge를 기준으로 삼지 않고 `docs/README.md`의 주장 유형별 권한 표를 따릅니다. Knowledge surface에는 `.openwikiignore`의 마지막 lee-spec-kit 보호 블록도 포함됩니다.
+`experimental.openwiki=true`여도 Feature 리뷰에는 Plan이 선언한 curated target을 전달하고 코드·제품 의도와 대조합니다. 생성 Wiki와 receipt는 필수 입력이 아닙니다. local은 통합 검증 후 cleanup 전에 `knowledge_sync`의 `knowledge publish`를 실행합니다. GitHub는 `knowledge ci`로 준비한 기준 브랜치 CI에서 revision별 artifact를 게시합니다. 생성 실패 시 코드 머지와 마지막 정상 게시본을 유지합니다.
 
 Plan 검수가 활성화되면 계획 단계는 `plan Review → fresh 읽기 전용 Plan 검수 → plan 승인` 순서로 진행됩니다. 검수는 반환된 `specHash`와 `planHash`에 묶이며 두 문서 중 하나의 내용이 바뀌면 기존 evidence가 무효입니다. reviewer는 문서를 수정하지 않고 Verification Contract와 테스트 결정을 점검합니다.
 

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

@@ -12,6 +12,7 @@ canonical docs surface 밖의 unmanaged docs 산출물(예: `docs/plans/*`, `doc
 기록 원칙:
 
 - 새 ADR 생성에는 `npx lee-spec-kit decision add <feature-ref> --title "..." --context "..." --decision "..." --rationale "..." --evidence "..."` 사용을 우선하세요.
+- 수동 작성도 마지막 ADR 뒤에 추가해 D001 → D002 순서를 유지하세요. 문서 안내문 앞에 삽입하거나 기존 ID를 재번호화하지 마세요. 같은 결정의 재실행·검증 결과는 해당 ADR의 Trace/Evidence를 갱신하고, 새 선택이나 범위 변경일 때만 새 ADR을 만드세요.
 - 모든 ADR은 **Decision(무엇을 선택했는가)** + **Trace(어떻게 고민했고 무엇을 확인했는가)** 를 함께 남깁니다.
 - 작성 타이밍을 고정합니다.
   - 태스크 시작(`[TODO] -> [DOING]`): `Context/Constraints`와 `Trace(초기 가설)`를 1~3줄로 먼저 기록

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

@@ -51,6 +51,8 @@ src/
 
 ## Curated Documentation Impact
 
+발견한 문서 불일치는 `decisions.md`에만 남기고 종료하지 않습니다. 현재 사실의 명백한 오류가 승인 범위 안에 있으면 `UPDATE`/`ADD`와 task `Docs`로 연결합니다. 제품 의도 확인이나 범위 확장이 필요하면 충돌한 문서 경로·근거, 확인할 질문, 보류 이유와 실제 후속 task/Feature/issue 참조를 기록합니다. 없는 번호나 승인을 만들지 않습니다. 추적 항목 생성에 승인이 필요하면 사용자 확인 전 해결된 것으로 기록하지 않습니다. `NONE`의 근거에는 알려진 불일치가 없거나, 남은 불일치가 해당 후속 항목으로 추적되고 있음을 설명합니다. 코드나 OpenWiki에 맞추기 위해 미구현 PRD 요구를 삭제하지 않습니다.
+
 > 모든 결정이 `NONE`이어도 영향 판정을 완료합니다. `NONE`은 사람이 관리하는 상위 문서를 검토했지만 변경할 필요가 없다는 뜻입니다. 생성형 OpenWiki 동기화는 별도로 판정합니다.
 
 - **Schema**: 2
@@ -67,7 +69,7 @@ src/
 - **Reason**: -
 - **Targets**: -
   - UPDATE 또는 ADD가 하나라도 있으면 쉼표로 구분한 `docs:<path>`와 `project:<path>` 대상을 기록합니다.
-  - 모든 대상은 task `Docs` 목록에 연결하고 Knowledge 동기화 또는 Feature 리뷰 전에 활성 Feature scope로 커밋합니다.
+  - 모든 대상은 task `Docs` 목록에 연결하고 Feature 리뷰 전에 활성 Feature scope로 커밋합니다.
 
 ---
 
@@ -91,6 +93,9 @@ src/
 
 ## Verification Contract
 
+Feature 완료 전 검사는 실제 `workflow.featureChecks`(컴포넌트 override 포함)를 기준으로 작성합니다. 추가 자동 검사는 실행 설정에도 등록하세요. build 포함 여부와 중복 생략 근거, 수동 검증 증거를 명시하세요.
+
+
 ### 변경 분류
 
 - **유형**: COPY | REFACTOR | BUG_FIX | NEW_BEHAVIOR | HIGH_RISK

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

@@ -92,10 +92,11 @@
 
 ---
 
-## Knowledge Sync
+## Knowledge Publication
 
 - **Policy**: `.lee-spec-kit.json`의 `experimental.openwiki`에서 파생
-- **Receipt**: `.lee-spec-kit/openwiki-sync.json`
+- **Lifecycle**: local은 통합 검증 후 cleanup 전에 `knowledge publish`를 실행합니다. GitHub는 `knowledge ci`로 별도 준비한 기준 브랜치 push CI를 사용합니다. local completion strategy가 `none`이면 자동 발행하지 않습니다.
+- **Receipt**: 반환된 게시 artifact 안에 저장합니다. 생성 Wiki와 receipt를 Feature 커밋·리뷰에 넣지 않습니다.
 
 ---
 
@@ -115,3 +116,5 @@
 | 명령어 | 마지막 실행(로컬, YYYY-MM-DD) | 결과 |
 | --- | --- | --- |
 | `{실행한 테스트 명령어}` | `-` | `{PASS/FAIL 요약}` |
+
+완료 기록에는 테스트뿐 아니라 build·typecheck·lint 등 Plan에서 정한 검증과 수동 검증 증거를 포함합니다. 자동 검사의 기준은 실제 `workflow.featureChecks`이며, 검사 생략은 통과로 기록하지 않고 명시적인 사유를 남깁니다.