lee-spec-kit 0.9.13 → 0.9.14

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "lee-spec-kit",
-  "version": "0.9.13",
+  "version": "0.9.14",
   "description": "Document-centered harness engineering toolkit for AI agent development",
   "type": "module",
   "bin": {
@@ -15,6 +15,18 @@
     "resources",
     "THIRD_PARTY_NOTICES.md"
   ],
+  "scripts": {
+    "build": "tsup",
+    "dev": "tsup --watch",
+    "lint": "eslint src",
+    "lint:test": "eslint tests",
+    "typecheck": "tsc --noEmit",
+    "typecheck:test": "tsc -p tsconfig.tests.json --noEmit",
+    "test": "pnpm build && vitest run",
+    "test:race": "pnpm build && vitest run tests/race.test.mjs",
+    "format": "prettier --write .",
+    "prepublishOnly": "pnpm build"
+  },
   "keywords": [
     "docs",
     "template",
@@ -56,15 +68,5 @@
     "typescript": "^5.9.3",
     "vitest": "^4.0.18"
   },
-  "scripts": {
-    "build": "tsup",
-    "dev": "tsup --watch",
-    "lint": "eslint src",
-    "lint:test": "eslint tests",
-    "typecheck": "tsc --noEmit",
-    "typecheck:test": "tsc -p tsconfig.tests.json --noEmit",
-    "test": "pnpm build && vitest run",
-    "test:race": "pnpm build && vitest run tests/race.test.mjs",
-    "format": "prettier --write ."
-  }
-}
+  "packageManager": "pnpm@10.7.0"
+}

package/templates/en/common/README.md

@@ -66,9 +66,9 @@ Keep product roadmaps in `prd/`, but manage implementation sequencing and work p
 
 Every Plan must complete `Curated Documentation Impact`, including explicit `NONE` decisions. Every `UPDATE` or `ADD` target must be attached to at least one task through its `Docs` list and committed with the active Feature scope before completion. This propagation rule applies whether OpenWiki is enabled or not.
 
-Schema 2 keeps four common surfaces in the core assessment and uses `Additional Curated Impacts` only for typed project-specific surfaces such as security, API/data contracts, design systems, release operations, observability, or agent policy. At completion, lee-spec-kit reconciles recognized curated files changed in the actual Feature diff against the declared targets before OpenWiki generation or Feature review. This prevents silent changes; it does not decide whether an unchanged document is semantically stale. After adoption, perform one manual baseline reconciliation of existing PRD, architecture, onboarding, operations, design, and agent-policy docs.
+Schema 2 keeps four common surfaces in the core assessment and uses `Additional Curated Impacts` only for typed project-specific surfaces such as security, API/data contracts, design systems, release operations, observability, or agent policy. At completion, lee-spec-kit reconciles recognized curated files changed in the actual Feature diff against the declared targets before Feature review; OpenWiki generation follows integration separately. This prevents silent changes; it does not decide whether an unchanged document is semantically stale. After adoption, perform one manual baseline reconciliation of existing PRD, architecture, onboarding, operations, design, and agent-policy docs.
 
-When `experimental.openwiki` is `true`, task checkpoints are followed by required Knowledge setup/sync/commit stages and a Feature review. Missing or `false` adds none of those stages. Use `lee-spec-kit knowledge sync`; never hand-edit generated pages or invoke OpenWiki directly from the workflow.
+When `experimental.openwiki` is true, local workflows publish an isolated, revision-bound Knowledge artifact after verified integration and before cleanup. GitHub uses the base-branch push CI scaffolded by `knowledge ci`. Feature commits and review do not contain generated Wiki. Use the returned `knowledge publish` command and inspect failures with `knowledge status`.
 
 OpenWiki is an external agent, not a sandboxed renderer. Enable it only for trusted repositories in an appropriately isolated runtime, and keep local or ignored secrets outside its accessible environment.
 
@@ -156,7 +156,7 @@ The OpenWiki experiment is controlled separately with the single `--openwiki tru
 - `docsRepo` ("embedded" | "standalone"): How docs are managed
 - `pushDocs` (boolean, optional): Only written when `docsRepo: "standalone"` (whether to push to remote)
 - `docsRemote` (string, optional): Only written when `pushDocs: true` (remote repo URL)
-- `experimental.openwiki` (boolean): one switch for the complete required OpenWiki Knowledge flow; missing/`false` disables it, and `true` requires Node.js 22+, OpenWiki `>=0.5.0 <1.0.0`, Knowledge sync/receipt/commit, and Feature review
+- `experimental.openwiki` (boolean): enables post-integration Knowledge artifacts; requires Node.js 22+ and OpenWiki `>=0.5.0 <0.6.0`. No generated Knowledge commit or forced Feature review.
 - `workflow.agentExecution.task` (object): task implementation delegation settings
   - `enabled`: delegates each `task_execute` action to a subagent; new projects default to `true`, while projects created before this setting existed keep it disabled until explicitly enabled
   - `type`: currently only `"subagent"` is supported
@@ -296,3 +296,30 @@ New projects delegate task implementation and enable Plan review by default. Exi
   }
 }
 ```
+
+
+### Feature check configuration (0.9.14)
+
+`workflow.featureChecks` is the executable project baseline for local completion.
+An empty list requires configuration; it does not mean that tests passed.
+Use `npx lee-spec-kit config --checks-detect` to print read-only Node script suggestions,
+then save a reviewed JSON array with `config --checks-file <path>`.
+Use `--project-root <path>` for discovery when the project root is ambiguous.
+Include build when the project produces build artifacts. If a selected test already
+runs build, document that coverage in the Plan and omit the duplicate command.
+Discovery does not infer nested script coverage or execute scripts.
+For projects without executable checks, use `config --checks-skip-reason <reason>`.
+Use `--component <name>` with the configuration commands for component overrides
+(`workflow.featureChecksByComponent`); otherwise the common baseline applies.
+
+Legacy `postMergeChecks` are read as Feature checks only when `featureChecks` is
+absent. `update` migrates that list without adding commands or overwriting an
+existing Feature list. Invalid entries remain visible and cause a validation error.
+Changing checks invalidates verification for pending integration. Completed,
+cleaned Features retain their historical completion state.
+
+The Plan's Verification Contract must reference the effective baseline and list
+Feature-specific extra checks in the executable configuration before verification.
+Record manual/UI evidence separately. Update the configuration before final review
+and verification, not after verification. Local base synchronization happens before
+checks; this does not fetch remote branches.

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

@@ -56,8 +56,8 @@ This document defines workflow policy, not a custom runtime loop.
 - Human-owned architecture, onboarding, operations, design, and agent-policy docs are authoritative for curated project-wide explanations and policy. Executable claims in them must agree with tracked code, schemas, migrations, and configuration; tests provide verification evidence.
 - OpenWiki is derived onboarding and code-navigation evidence, never a source of requirements, policy, or runtime truth.
 - Complete `Curated Documentation Impact` in every Plan, including explicit `NONE` decisions. Link every `UPDATE` or `ADD` target from at least one task `Docs` entry and commit the target with the active Feature scope.
-- `experimental.openwiki` is one switch: missing or `false` adds no OpenWiki behavior; `true` makes Knowledge setup, sync, a dedicated Knowledge commit, and Feature review mandatory.
-- When enabled, run repository Knowledge generation and updates only through `npx lee-spec-kit knowledge sync <featureRef> --json`. The read-only `openwiki visualize ./openwiki` command may be invoked directly to inspect generated output, but do not hand-edit generated pages.
+- `experimental.openwiki=true` publishes Knowledge after integration: local workflows run the returned `knowledge publish` action after verified merge and before cleanup; GitHub workflows use the post-push CI created by `knowledge ci`. Missing or false disables this lifecycle.
+- Generate in an isolated worktree and publish revision-bound artifacts outside the source branch. Do not add generated Wiki or receipts to Feature commits or Feature review required documents. Keep curated PRD/architecture updates in the Feature.
 
 ## Optional UI/UX Design Policy
 
@@ -81,12 +81,12 @@ This document defines workflow policy, not a custom runtime loop.
 - Do not interrupt, replace, or abandon a running subagent solely because it has been quiet or has not changed files. Stop it only after an explicit user request, a terminal failure/cancellation, or an unrecoverable runtime status.
 - `workflow.agentReview.maxRounds` is the maximum number of fresh reviews for each Plan/task/Feature gate. A `changes_requested` decision on the final allowed review is remediated once, but the changed target is not reviewed again; preserve remaining findings and the post-review target change as residual risks and automatically complete the gate without asking for a user review-approval token. For example, `maxRounds=1` means review round 1, remediate once, then continue with no round 2. A `blocked` decision never auto-completes.
 - Treat spec/plan/tasks approval, issue creation, and branch creation as hard gates before implementation.
-- Follow `knowledge_setup`, `knowledge_sync`, and `knowledge_commit` exactly when returned. Commit only the verified Knowledge surface with the exact returned subject before Feature review.
+- Follow the post-integration `knowledge_sync` action (`knowledge publish`). Failures leave the verified merge and last good publication intact; inspect `knowledge status` and retry. `knowledge sync` is a legacy in-place tool, not the Feature workflow.
 - In standalone mode, do not hand-write `git worktree add`; run the exact `nextAction.command` from `workflow-stage` so the managed workspace path, stale directory cleanup, and `.env`/`.env.*` copy step stay consistent.
 - In local mode, do not stop after implementation approval. Follow the exact `local verify`, `local merge`, and `local cleanup` commands returned by `workflow-stage` until verified integration and cleanup produce `done`. A `feature_remediation` stage explicitly permits fixes in the Feature worktree.
 - In a `local-ff` or `local-squash` workflow, keep implementation approval and local merge approval distinct when `local_merge` is required: the first accepts the implementation, and the second authorizes the configured integration strategy, post-merge checks, and local cleanup.
 - Keep docs synced with code changes in the same turn whenever behavior or scope changes.
-- Use `npx lee-spec-kit commit-audit --json` before `git commit`; Feature-scoped commits use `#123` when an Issue is linked and the stable Feature ID such as `F027` for issue-less local workflows.
+- Use `npx lee-spec-kit commit-audit --json` before `git commit`; Feature-scoped commits use `#123` when an Issue is linked and the stable Feature ID such as `K7M2Q9RX4DAB` for issue-less local workflows.
 - Use `npx lee-spec-kit workflow-audit --json` as the default end-of-turn docs sync check.
 
 ## Approval Rules

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

@@ -65,11 +65,11 @@ Examples:
 ```text
 feat(#123): implement user auth
 docs(#123): clarify auth spec
-feat(F027): implement notification settings
-docs(F027): update notification docs
+feat(K7M2Q9RX4DAB): implement notification settings
+docs(K7M2Q9RX4DAB): update notification docs
 ```
 
-For local Features, the scope is the stable Feature ID (`F027`), not the full folder ref (`F027-notification-settings`). Feature-scoped commits without a scope, such as `docs: F027 ...`, are not canonical.
+For local Features, the scope is the stable Feature ID (`K7M2Q9RX4DAB`), not the full folder ref (`K7M2Q9RX4DAB-notification-settings`). Feature-scoped commits without a scope, such as `docs: K7M2Q9RX4DAB ...`, are not canonical.
 
 ### Type List
 
@@ -110,14 +110,7 @@ Run the returned `nextAction.command` instead of hand-writing the worktree path.
 that are no longer registered Git worktrees, and copies existing `.env`/`.env.*` files
 from the project root into the new worktree when the target file is absent.
 
-```bash
-# Embedded fallback only: create dedicated worktree + branch
-mkdir -p .worktrees
-git worktree add -b feat/{issue-number}-{feature-name} .worktrees/feat-{issue-number}-{feature-name}
-
-# If branch already exists, attach worktree only
-git worktree add .worktrees/feat-{issue-number}-{feature-name} feat/{issue-number}-{feature-name}
-```
+For new embedded Features, follow `workspace_checkpoint` before branch creation. It commits only that Feature's planning docs. Then use the returned worktree command and continue from its workingDirectory. Do not manually create a worktree from a HEAD that lacks the Feature docs.
 
 > Continue implementation from the worktree path returned by `workflow-stage`.
 
@@ -132,17 +125,17 @@ git worktree add .worktrees/feat-{issue-number}-{feature-name} feat/{issue-numbe
 
 #### Standalone Mode Commit Guide
 
-Use the scope selected by the workflow: `#123` when an Issue is linked, otherwise the local Feature ID such as `F027`.
+Use the scope selected by the workflow: `#123` when an Issue is linked, otherwise the local Feature ID such as `K7M2Q9RX4DAB`.
 
 1. **Project Commit** (If code changed)
 
    ```bash
-   git commit -m "feat(F027): implement feature"
+   git commit -m "feat(K7M2Q9RX4DAB): implement feature"
    ```
 
 2. **Docs Commit** (If docs changed - **Run in Docs Repo**)
    ```bash
-   git commit -m "docs(F027): update feature docs"
+   git commit -m "docs(K7M2Q9RX4DAB): update feature docs"
    ```
 
 > 💡 **Core Rule**: At task completion, **all changed repositories** must be committed.
@@ -179,3 +172,11 @@ Use the scope selected by the workflow: `#123` when an Issue is linked, otherwis
 
 - [ ] Auto-delete head branches
 - [ ] Squash merging only
+
+## Feature isolation and integration
+
+New GitHub Feature IDs come from Issues selected before SDD planning; new local IDs are 12-character random values. Existing F-number documents remain compatible. One Feature has one owner and one active task; different Features can proceed independently.
+
+New standalone Features keep the primary docs checkout on its base branch and use `workspace prepare` for their docs worktree. Commit seed docs first and work from the returned docsDirectory. Project and docs integration are separate. In local mode, verify code integration, merge docs, publish OpenWiki when enabled, then clean up. GitHub publication runs independently on code base-branch pushes. The docs receipt is an empty Git commit and survives a docs clone. Use `workspace sync-docs` when the base advances and revalidate conflicts before integration. Failed integration never implies completion.
+
+Use task claim/status/transition/release for explicit task IDs, with the current tasks hash and session token. Legacy task lines without IDs retain document transitions. Run feature-audit in CI; review sharedDocumentationWarnings for shared curated targets. PR merge retries do not automatically rebase or force-push.

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

@@ -8,10 +8,7 @@ This guide defines how to start or continue a feature in the Codex-native lee-sp
 
 1. Run `npx lee-spec-kit detect --json`.
 2. If detected, read `npx lee-spec-kit docs get agents --json` and any unread follow-up docs.
-3. If the feature folder does not exist yet:
-   - preserve an explicit Idea ref only when the user actually named one (`I001`, `I001-slug`, or `docs/ideas/...`)
-   - create the feature with `npx lee-spec-kit feature <name> --idea <ref>` only for that explicit ref
-   - otherwise create it with `npx lee-spec-kit feature <name> -d "<description>"`
+3. If the Feature folder does not exist, use `feature <name> --issue <number>` in GitHub mode. Create an Issue first only after sharing its title/body and receiving authorization (`--create-issue --desc "<summary>" --confirm OK`). In local mode, use `feature <name> -d "<description>"`; a random ID is generated. Add `--idea <ref>` only when the user explicitly named that Idea. Never allocate a new F-number.
 4. Resolve the active feature and read its docs: `spec.md`, `plan.md`, `tasks.md`, `decisions.md`.
 5. Run `npx lee-spec-kit workflow-stage <feature-ref> --json` before taking the next workflow action.
 
@@ -36,3 +33,11 @@ This guide defines how to start or continue a feature in the Codex-native lee-sp
 1. Do not invent issue/PR numbers or status transitions.
 2. Do not skip required doc updates when scope, behavior, or evidence changed.
 3. Do not treat unmanaged docs artifacts as the active workflow SSOT until they are normalized into the feature folder or allowlisted.
+
+## 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/en/common/agents/skills/create-issue.md

@@ -1,11 +1,13 @@
+> New Features: create/select the GitHub Issue before generating Feature docs. Use `npx lee-spec-kit feature <slug> --issue <number> --owner <email>`, or share the title/body and use `--create-issue --desc <body> --confirm OK`. The legacy `github issue F001` flow below remains for existing F-number Features. Issue creation is intake, not implementation approval.
+
 # GitHub Issue Creation Process
 
 Guide for creating GitHub Issues.
-Execution-state SSOT is the feature-local `issue.md`.
+For the legacy flow below, execution-state SSOT is the feature-local `issue.md`. New Features use Issue intake before SDD planning; the following completed-SDD prerequisites do not apply to intake.
 
 ---
 
-## Prerequisites
+## Legacy F-number workflow prerequisites
 
 - [ ] `spec.md` completed
 - [ ] `plan.md` completed
@@ -15,7 +17,7 @@ Execution-state SSOT is the feature-local `issue.md`.
 
 ---
 
-## Steps
+## Legacy steps
 
 ### 1. Prepare `issue.md` Draft
 

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

@@ -60,3 +60,7 @@ Do not close a discovered documentation discrepancy with a decisions.md note alo
 2. Do not rewrite `[DONE]` tasks.
 3. Do not treat unmanaged docs artifacts as active workflow state until they are normalized or allowlisted.
 4. Do not start implementation while the workflow is still blocked on issue creation, branch creation, or any earlier stage gate.
+
+## Session and state commands
+
+For tasks with explicit IDs, the main agent claims the Feature with `task claim <id> --json`, reads `task status <id> --json`, and calls `task transition <id> <task-id> --from <state> --to <state> --session <token> --expected-hash <hash> --json`. Use the task selected by workflow-stage. Update acceptance/checklist/review evidence first, then read a fresh hash for the transition. Stale hashes, other owners, and competing sessions block mutations. Release with `task release <id> --session <token>` at handoff. These commands do not add approval boundaries. Legacy lines without explicit task IDs continue using document edits under the existing workflow gates.

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

@@ -59,7 +59,7 @@ Use the returned `stage`, `nextAction`, and `implementationAllowed` values as th
 
 Before Plan review or approval, complete Schema 2 `Curated Documentation Impact`. Assess all four core surfaces, and use typed `Additional Curated Impacts` only for applicable project-specific surfaces; an explicit additional `NONE` proves that no extra category applies. Every `UPDATE` or `ADD` target must appear under `Docs` in at least one task and in the committed Feature diff. Existing projects require one manual baseline reconciliation before per-Feature checks can keep the curated layer current.
 
-When `experimental.openwiki=true`, all completed task checkpoints advance through required `knowledge_setup`, `knowledge_sync`, and `knowledge_commit` stages before Feature review. The Feature reviewer receives `openwiki/index.md`, the verified receipt, and every Plan-declared curated target; use the claim-specific authority matrix in `docs/README.md` rather than treating generated Knowledge as authoritative. The Knowledge surface includes a final lee-spec-kit protection block in `.openwikiignore`.
+With `experimental.openwiki=true`, Feature review receives the Plan-declared curated targets and checks them against code and product intent. Generated Wiki and receipts are not required inputs. After verified local integration, `knowledge_sync` invokes `knowledge publish` before cleanup. GitHub publishes revision-bound artifacts through the integration-branch CI scaffolded by `knowledge ci`. Generation failure preserves the code merge and last good artifact.
 
 With Plan review enabled, planning follows `plan Review → fresh read-only Plan review → plan approval`. The review is bound to the returned `specHash` and `planHash`; changing either document's content invalidates the prior evidence. The reviewer checks the Verification Contract and test decisions without editing docs.
 

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

@@ -69,7 +69,7 @@ Do not close a discovered documentation discrepancy with a decisions.md note alo
 - **Reason**: -
 - **Targets**: -
   - Use comma-separated `docs:<path>` and `project:<path>` targets when any decision is UPDATE or ADD.
-  - Every target must be linked from a task `Docs` list and committed with the active Feature scope before Knowledge sync or Feature review.
+  - Every target must be linked from a task `Docs` list and committed with the active Feature scope before Feature review.
 
 ---
 
@@ -93,6 +93,9 @@ Each `DECLARED` row uses `UPDATE` or `ADD` and a `docs:<path>` or `project:<path
 
 ## Verification Contract
 
+Reference the effective workflow.featureChecks baseline, including component overrides. Register additional automatic checks in the executable configuration. State build coverage, reasons for avoiding duplicate builds, and manual verification evidence.
+
+
 ### Change Classification
 
 - **Type**: COPY | REFACTOR | BUG_FIX | NEW_BEHAVIOR | HIGH_RISK

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/execute-task.md

@@ -60,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/plan.md

@@ -69,7 +69,7 @@ src/
 - **Reason**: -
 - **Targets**: -
   - UPDATE 또는 ADD가 하나라도 있으면 쉼표로 구분한 `docs:<path>`와 `project:<path>` 대상을 기록합니다.
-  - 모든 대상은 task `Docs` 목록에 연결하고 Knowledge 동기화 또는 Feature 리뷰 전에 활성 Feature scope로 커밋합니다.
+  - 모든 대상은 task `Docs` 목록에 연결하고 Feature 리뷰 전에 활성 Feature scope로 커밋합니다.
 
 ---
 
@@ -93,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`이며, 검사 생략은 통과로 기록하지 않고 명시적인 사유를 남깁니다.