lee-spec-kit 0.9.7 → 0.9.9

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "lee-spec-kit",
-  "version": "0.9.7",
+  "version": "0.9.9",
   "description": "Document-centered harness engineering toolkit for AI agent development",
   "type": "module",
   "bin": {

package/templates/en/common/README.md

@@ -54,6 +54,18 @@ npx lee-spec-kit docs get agents --json
 
 Keep product roadmaps in `prd/`, but manage implementation sequencing and work plans in the active Feature's `plan.md` and `tasks.md`. The `designs/` directory is reserved for UX and visual design, not technical design.
 
+### Knowledge Architecture and authority
+
+1. Feature SDD (`spec.md`, `plan.md`, `tasks.md`, `decisions.md`) is normative for requirements, scope, decisions, and acceptance.
+2. Human-owned PRD, architecture, onboarding, and operations documents are the curated project-wide current state.
+3. `openwiki/` is a derived onboarding and code-navigation layer. Verify its claims against tracked source, tests, schemas, and curated docs.
+
+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.
+
+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.
+
+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.
+
 ---
 
 ## SSOT Relationship (PRD / Ideas / Features)
@@ -124,6 +136,8 @@ Non-interactive setup exposes the same choices through `--task-agent`,
 Existing projects can change the same settings with `lee-spec-kit config
 --interactive` or the corresponding non-interactive flags.
 
+The OpenWiki experiment is controlled separately with the single `--openwiki true|false` option.
+
 - Used by `lee-spec-kit feature`, `config`, `update`, `detect`, and workflow validators to resolve docs location / project type / language.
 - `docsRepo`, `pushDocs`, `docsRemote` are metadata for the CLI-managed **Docs Push policy** (the CLI does not auto-push).
 
@@ -136,6 +150,7 @@ Existing projects can change the same settings with `lee-spec-kit config
 - `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
 - `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
@@ -145,7 +160,7 @@ Existing projects can change the same settings with `lee-spec-kit config
   - `workflow-stage` returns a stable task ID, working/docs directories, and a machine-readable `workerContract`. The worker executes directly without rerunning `workflow-stage` or delegating again.
   - The implementation subagent can edit project code and run task-scoped checks. The main agent retains docs, task state, commits, approvals, and remote actions; official hooks reject commits while `task_execute` is active.
 - `workflow.agentAutomationConfigured` (boolean): records that `init` or `config` explicitly selected the agent automation policy, preventing legacy-default repair from overriding that choice
-- `workflow.agentReview.maxRounds` (positive integer): maximum automatic finding-remediation passes shared by Plan/task/Feature reviews before remaining `changes_requested` findings are preserved as residual risks and the review gate auto-completes; the initial review is not counted and the default is `1`
+- `workflow.agentReview.maxRounds` (positive integer): maximum number of fresh reviews shared by Plan/task/Feature gates. Findings from the final allowed `changes_requested` review are applied once, then remaining findings and the resulting target change are preserved as residual risks and the gate auto-completes without another review. The default is `1`, which means there is no round 2
 - `workflow.agentReview.plan` / `workflow.agentReview.task` / `workflow.agentReview.feature` (object): Plan/task/Feature independent review settings
   - `enabled`: enables that review gate; new projects default Plan and Feature to `true`, and task to `false`
   - `evidenceMode`: `path_required | any`
@@ -184,6 +199,9 @@ Existing projects can change the same settings with `lee-spec-kit config
   "lang": "en",
   "createdAt": "{{date}}",
   "docsRepo": "embedded",
+  "experimental": {
+    "openwiki": false
+  },
   "workflow": {
     "mode": "local",
     "agentAutomationConfigured": true,
@@ -250,7 +268,7 @@ Existing projects can change the same settings with `lee-spec-kit config
 }
 ```
 
-New projects delegate task implementation and enable Plan review by default. Existing projects that predate those settings keep task delegation and Plan/Task review disabled, so updating does not silently change the execution policy. An older project whose generated defaults were already backfilled by v0.9.4-v0.9.6 is also restored to the safe disabled state when its creation date and untouched generated settings identify that case; customized agent settings are preserved. Use `lee-spec-kit config --interactive`, or `config --task-agent on|off --reviews plan,task,feature|none --max-review-rounds N`, to opt in or change it. New local projects use `local-ff` with Feature agent review enabled. Legacy Feature review behavior is preserved from the former Pre-PR setting and workflow mode. Finding remediation defaults to `1`: findings from the first review are applied once and reviewed again. If the next review still returns `changes_requested`, those findings remain as residual risks and the review gate completes automatically without user approval. `blocked` never auto-completes. Choose `local-squash` to create one base-branch commit while preserving the source Feature tip under an internal `refs/lee-spec-kit/integrations/*` ref for task-checkpoint evidence. During `update`, an existing local project with no explicit `completionStrategy` receives `none` so an upgrade does not unexpectedly merge its current branch. Set it to `local-ff` or `local-squash` deliberately when ready.
+New projects delegate task implementation and enable Plan review by default. Existing projects that predate those settings keep task delegation and Plan/Task review disabled, so updating does not silently change the execution policy. An older project whose generated defaults were already backfilled by v0.9.4-v0.9.6 is also restored to the safe disabled state when its creation date and untouched generated settings identify that case; customized agent settings are preserved. Use `lee-spec-kit config --interactive`, or `config --task-agent on|off --reviews plan,task,feature|none --max-review-rounds N`, to opt in or change it. New local projects use `local-ff` with Feature agent review enabled. Legacy Feature review behavior is preserved from the former Pre-PR setting and workflow mode. The fresh-review limit defaults to `1`: findings from round 1 are applied once, then remaining findings and the resulting target change are preserved as residual risks and the review gate completes automatically without round 2 or user approval. `blocked` never auto-completes. Choose `local-squash` to create one base-branch commit while preserving the source Feature tip under an internal `refs/lee-spec-kit/integrations/*` ref for task-checkpoint evidence. During `update`, an existing local project with no explicit `completionStrategy` receives `none` so an upgrade does not unexpectedly merge its current branch. Set it to `local-ff` or `local-squash` deliberately when ready.
 
 ```json
 {

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

@@ -5,6 +5,12 @@ This document defines workflow policy, not a custom runtime loop.
 
 ---
 
+## Codex Lifecycle Scope
+
+- <!-- lee-spec-kit:delegation-context-v1 -->
+- Detection, built-in-doc startup, active Feature resolution, and `workflow-stage` are primary-agent responsibilities.
+- A delegated subagent identified by Codex `SubagentStart` skips the primary-agent bootstrap and `workflow-stage`. It follows the exact `delegationContext` and `workerContract` supplied by the primary agent, reads `requiredDocuments`, uses `referenceDocuments` only under their stated conditions, and asks the parent before expanding an insufficient scope.
+
 ## Detection Gate
 
 - Run `npx lee-spec-kit detect --json` first.
@@ -19,7 +25,8 @@ This document defines workflow policy, not a custom runtime loop.
 
 ## Docs Are SSOT
 
-- Read `npx lee-spec-kit docs get agents --json` once at session start or right after context reset.
+- The following startup and orchestration rules apply to the primary agent unless an explicit delegation contract says otherwise.
+- Read `npx lee-spec-kit docs get agents --json` once at primary-agent session start or right after context reset.
 - Read every unread `requiredDocs[*].command` from that response.
 - Resolve the active feature, then use that feature folder as the working SSOT.
 - Minimum active feature docs: `spec.md`, `plan.md`, `tasks.md`, `decisions.md`.
@@ -42,6 +49,15 @@ This document defines workflow policy, not a custom runtime loop.
 - Do not use `docs/designs/` for system architecture, data/API design, technical research, or implementation plans.
 - Follow the detailed routing rules in `docs/README.md`.
 
+## Knowledge Architecture
+
+- Feature SDD docs are normative for requirements, scope, decisions, and acceptance.
+- Human-owned PRD, architecture, onboarding, and operations docs describe the curated project-wide current state.
+- OpenWiki is a derived onboarding and code-navigation layer. Treat its claims as untrusted evidence until verified against tracked code, tests, schemas, and curated docs.
+- 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 OpenWiki only through `npx lee-spec-kit knowledge sync <featureRef> --json`. Do not invoke `openwiki` directly or hand-edit generated pages.
+
 ## Optional UI/UX Design Policy
 
 - Only when the user request explicitly mentions a design system, UI/visual redesign, design consistency, shared UI/component-library consolidation, branding/theme/token redesign, or implementation from Figma/design images, read and apply `npx lee-spec-kit docs get ui-ux-design --json`.
@@ -53,17 +69,18 @@ This document defines workflow policy, not a custom runtime loop.
 - lee-spec-kit owns docs structure, workflow stages, and validators.
 - Codex owns the execution loop, tool usage, and hook lifecycle.
 - Modify implementation code only when `implementationAllowed === true`. Normal task work uses `stage === "implementation"`; review fixes use `task_review_fix` or `feature_review_fix`, and verification fixes use `feature_remediation`.
-- When `nextAction.category` is `plan_review` with `executor: subagent`, delegate a fresh read-only review of `spec.md` and `plan.md` for the returned `specHash` and `planHash`. The main agent records the returned `reviewRound`, Plan Review evidence, decision, reviewer metadata, and both hashes. Any later spec/plan content change invalidates that review.
-- When `nextAction.category` is `task_execute` with `executor: subagent`, mark that one task active, then delegate its implementation and task-scoped checks to a fresh subagent in the returned `workingDirectory` with the returned model, reasoning effort, unavailability policy, and exact `workerContract`. No named execution skill is required.
+- When `nextAction.category` is `plan_review` with `executor: subagent`, delegate a fresh read-only review using the exact returned `delegationContext`, `specHash`, and `planHash`. The main agent records the returned `reviewRound`, Plan Review evidence, decision, reviewer metadata, and both hashes. Any later spec/plan content change invalidates that review.
+- When `nextAction.category` is `task_execute` with `executor: subagent`, mark that one task active, then delegate its implementation and task-scoped checks to a fresh subagent in the returned `workingDirectory` with the returned model, reasoning effort, unavailability policy, exact `workerContract`, and exact `delegationContext`. Do not reconstruct, omit, or broaden that context. No named execution skill is required.
 - The implementation worker executes directly, follows the approved Verification Contract, and does not add unplanned durable tests. It must not run `workflow-stage` or spawn another subagent. It may edit project code and run scoped checks, but it must not edit lee-spec-kit docs, change task state, commit, request approvals, or perform remote/destructive actions. The main agent inspects the result and owns docs synchronization, task transitions, commits, and workflow continuation; official hooks block commits while `task_execute` remains active.
-- When `nextAction.category` is `task_review` with `executor: subagent`, delegate a fresh read-only review for the returned task ID and SHA/tree range, then record the returned `reviewRound`.
-- When `nextAction.category` is `pre_pr_review` with `executor: subagent`, run a fresh read-only Feature review using the returned model, reasoning effort, `reviewRound`, and SHA/tree range. Do not select or require a named review skill.
+- When `nextAction.category` is `task_review` with `executor: subagent`, delegate a fresh read-only review using the exact returned `delegationContext`, task ID, and SHA/tree range, then record the returned `reviewRound`.
+- When `nextAction.category` is `pre_pr_review` with `executor: subagent`, run a fresh read-only Feature review using the exact returned `delegationContext`, model, reasoning effort, `reviewRound`, and SHA/tree range. Do not select or require a named review skill.
 - Review subagents return findings without modifying code. The main agent remediates findings and records reviewer metadata, reviewed scope, evidence, decision, and exact hash/SHA/tree target metadata.
 - After delegating to a subagent, wait until it returns a terminal outcome: completed, explicit failure, cancellation, or an approval/user-input request that requires action.
 - While the subagent remains running, use repeated bounded waits, preferably longer waits. A bounded wait that returns no update, a lack of status messages, or a lack of file changes means only that the subagent is still pending; none is evidence of failure or stalled work. Read-only review subagents are expected not to modify files.
 - 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` counts automatic finding-remediation passes, not the initial review. After those passes are exhausted, preserve the latest `changes_requested` findings as residual risks and automatically complete the Plan/task/Feature review gate without asking for a user review-approval token. A `blocked` decision never auto-completes.
+- `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.
 - 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.

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

@@ -24,8 +24,8 @@ This guide defines how to start or continue a feature in the Codex-native lee-sp
   - `tasks.md` drives execution order
   - `issue.md` / `pr.md` are part of the stage gate once the feature reaches GitHub workflow stages
 - Do not begin implementation just because `tasks.md` exists. Implementation starts only when `workflow-stage --json` allows it.
-- When Plan review is enabled, move `plan.md` to Review, delegate the returned fresh read-only `plan_review`, and record its `reviewRound`, evidence, decision, reviewer metadata, `specHash`, and `planHash`. Only an approved review of the current hashes can reach Plan approval. The reviewer challenges NONE/UPDATE/ADD decisions, requirement coverage, independent oracles, stable observation boundaries, realistic failure/rollback cases, exclusions, and focused/full verification scope without editing docs.
-- `workflow.agentReview.maxRounds` counts Plan finding-remediation passes, not the initial review. After the limit, preserve remaining `changes_requested` findings as residual risks, promote the Plan automatically, and do not request a user review-approval token. Never auto-complete `blocked`.
+- When Plan review is enabled, move `plan.md` to Review, delegate the returned fresh read-only `plan_review`, and record its `reviewRound`, evidence, decision, reviewer metadata, `specHash`, and `planHash`. An approved review must match the current hashes; exhausted `changes_requested` follows the automatic residual-risk path below. The reviewer challenges NONE/UPDATE/ADD decisions, requirement coverage, independent oracles, stable observation boundaries, realistic failure/rollback cases, exclusions, and focused/full verification scope without editing docs.
+- `workflow.agentReview.maxRounds` is the maximum number of fresh Plan reviews. On `changes_requested` at the final allowed round, apply the findings once, preserve remaining findings and the resulting hash changes as residual risks, promote the Plan automatically, and do not request another review or a user review-approval token. With `maxRounds=1`, there is no round 2. Never auto-complete `blocked`.
 - When scope or behavior changes, update the active feature docs in the same turn before continuing.
 - Ask for approval at documented review checkpoints and before remote or destructive actions.
 - Use `npx lee-spec-kit commit-audit --json` before `git commit` when docs-path validation matters.

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

@@ -33,8 +33,8 @@ When `workflow-stage --json` returns `nextAction.executor: subagent`, delegate t
 10. `Pre-PR Decision` must use `decision: approve|changes_requested|blocked ...` (or `결정: ...`).
 11. Record `Pre-PR Review Round` from the returned `reviewRound`.
 12. Confirm `Pre-PR Reviewed Head` and `Pre-PR Reviewed Tree` match the `targetSha` and `targetTree` returned by `workflow-stage`.
-13. `workflow.agentReview.maxRounds` counts Feature finding-remediation passes, not the initial review. After the limit, preserve remaining `changes_requested` findings as residual risks and auto-complete the Feature review gate without a user review-approval token. Never auto-complete `blocked`.
-14. Ensure the final decision is `approve` before moving to PR creation.
+13. `workflow.agentReview.maxRounds` is the maximum number of fresh Feature reviews. On `changes_requested` at the final allowed round, apply the findings once, preserve remaining findings and the resulting target change as residual risks, and auto-complete the Feature review gate without another review or a user review-approval token. With `maxRounds=1`, there is no round 2. Never auto-complete `blocked`.
+14. Move to PR creation after an `approve` decision or after the exhausted `changes_requested` path above auto-completes the gate.
 
 The review artifact must record the actual `executor`, `model`, `reasoningEffort`, reviewed commit/diff scope, target SHA/tree, findings, and final decision. The review subagent must not modify code; the main agent owns finding remediation and documentation updates.
 

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

@@ -13,7 +13,7 @@ Use the active feature folder as the execution SSOT.
   - continue the single `[DOING]` task, or
   - move the next highest-priority `[TODO]` task to `[DOING]`
 - Work one task at a time. Do not batch-complete multiple tasks in one pass.
-- When `nextAction.executor === "subagent"`, delegate that task's implementation and task-scoped verification to a fresh subagent in `nextAction.workingDirectory` using the returned `model`, `reasoningEffort`, `onUnavailable`, and exact `workerContract`. If a requested model is unavailable, `inherit` means retry with the current model inherited and `error` means stop and report the failure.
+- When `nextAction.executor === "subagent"`, delegate that task's implementation and task-scoped verification to a fresh subagent in `nextAction.workingDirectory` using the returned `model`, `reasoningEffort`, `onUnavailable`, exact `workerContract`, and exact `delegationContext`. Do not reconstruct, omit, or broaden that context. If a requested model is unavailable, `inherit` means retry with the current model inherited and `error` means stop and report the failure.
 - The implementation worker executes the assigned task directly. It must not run `workflow-stage`, delegate again, edit lee-spec-kit docs, change task state, commit, request approval, or perform remote/destructive actions. It may edit project code and run task-scoped checks only.
 - After delegation, the main agent waits for the worker's terminal outcome. While it remains running, use repeated bounded waits, preferably longer waits; a wait with no update, no status message, or no file change is not evidence of failure or stalled work.
 - Do not interrupt, replace, or abandon the running worker solely because it has been quiet or has not changed files. Stop only after an explicit user request, a terminal failure/cancellation, or an unrecoverable runtime status.
@@ -25,8 +25,8 @@ Use the active feature folder as the execution SSOT.
 - Keep `tasks.md` aligned with reality:
   - do not mark `[DONE]` without real completion and verification
   - when `workflow.agentReview.task.enabled=true`, move completed implementation to `[REVIEW]` instead of `[DONE]`, create the checkpoint commit, and run the independent review
-  - record the returned `reviewRound`, and move `[REVIEW]` to `[DONE]` only after the task reviewer approves the current SHA/tree
-  - `workflow.agentReview.maxRounds` counts task finding-remediation passes, not the initial review; after the limit, preserve remaining `changes_requested` findings as residual risks, mark the task DONE, and continue without a user review-approval token; never auto-complete `blocked`
+  - record the returned `reviewRound`, and move `[REVIEW]` to `[DONE]` after the task reviewer approves the current SHA/tree or the exhausted `changes_requested` path below auto-completes the gate
+  - `workflow.agentReview.maxRounds` is the maximum number of fresh task reviews; on `changes_requested` at the final allowed round, apply the findings once, preserve remaining findings and the resulting target change as residual risks, mark the task DONE, and continue without another review or a user review-approval token; with `maxRounds=1`, there is no round 2; never auto-complete `blocked`
   - update `Acceptance` and `Checklist` in the same edit when closing a task
   - if a completed task needs follow-up, add a new task instead of rewriting history
 - If you need to add a new task, append a complete task block in `tasks.md` with a concrete title, `Acceptance`, `Checklist`, and `NON-PRD` or existing `PRD-*` tag.

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

@@ -57,13 +57,17 @@ npx lee-spec-kit workflow-stage <feature-ref> --json
 
 Use the returned `stage`, `nextAction`, and `implementationAllowed` values as the current workflow state.
 
+Before Plan review or approval, complete `Curated Documentation Impact`. Explicit `NONE` values prove the surface was reviewed; every `UPDATE` or `ADD` target must appear under `Docs` in at least one task.
+
+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; SDD and curated project docs remain authoritative. The Knowledge surface includes a final lee-spec-kit protection block in `.openwikiignore`.
+
 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.
 
 The three final completion checkboxes in `tasks.md` carry `lee-spec-kit:completion:*` HTML markers. You may customize their visible wording, but preserve the marker on each checkbox line; `workflow-stage` uses the marker as the machine-readable identity and falls back to the legacy canonical wording for older projects.
 
 With Feature agent review enabled, local completion is `feature review → implementation_approve → feature_verify → local_merge → local_cleanup → done`. With task review enabled, every task follows `DOING → REVIEW → task review → DONE`. Failed checks enter `feature_remediation` with implementation enabled. `local-ff` moves only the verified Feature SHA; `local-squash` requires the integration tree to match the verified Feature tree. Both require cleanup before `done`. After cleanup, a Feature remains `done` while its recorded integration commit is still an ancestor of the current base, even when later Features advance that base.
 
-When `workflow.agentExecution.task.enabled=true`, each `task_execute` action carries the configured subagent model, reasoning effort, stable task ID, implementation working directory, and a machine-readable `workerContract`. The worker executes directly without calling `workflow-stage` or delegating again. It follows the approved Verification Contract, does not add unplanned durable tests, edits project code, and runs task-scoped checks only; the main agent owns docs synchronization, task transitions, commits, approvals, and remote actions. Official hooks block commits until the main agent advances the workflow to `task_commit`.
+When `workflow.agentExecution.task.enabled=true`, each `task_execute` action carries the configured subagent model, reasoning effort, stable task ID, implementation working directory, a machine-readable `workerContract`, and a versioned `delegationContext`. The context includes the exact task block, acceptance criteria, Verification Contract, required Feature documents, and conditional references; pass it unchanged to the worker. The worker executes directly without calling `workflow-stage` or delegating again. It does not add unplanned durable tests, edits project code, and runs task-scoped checks only; the main agent owns docs synchronization, task transitions, commits, approvals, and remote actions. Official hooks block commits until the main agent advances the workflow to `task_commit`.
 
 A remediation commit invalidates verification and the prior local-merge confirmation. Refresh review evidence for the changed diff when Pre-PR review is enabled, verify the new tip, and obtain local-merge approval again.
 

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

@@ -49,6 +49,27 @@ src/
 
 ---
 
+## Curated Documentation Impact
+
+> Complete this assessment even when every decision is `NONE`. `NONE` means the surface was reviewed and no human-owned project document needs to change. Generated OpenWiki synchronization is evaluated separately.
+
+- **Assessment**: Pending
+  - Values: Pending | Complete
+- **Product requirements**: -
+  - Values: NONE | UPDATE | ADD
+- **System architecture**: -
+  - Values: NONE | UPDATE | ADD
+- **Onboarding entrypoint**: -
+  - Values: NONE | UPDATE | ADD
+- **Operational/runtime contract**: -
+  - Values: NONE | UPDATE | ADD
+- **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.
+
+---
+
 ## Verification Contract
 
 ### Change Classification

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

@@ -11,7 +11,7 @@
   - Ask for approval before changing task state only when the task crosses a documented review checkpoint or before remote/destructive actions.
   - Do not invent a standalone `OK` approval step when the workflow does not require one.
   - Do not mark `[DONE]` while any item in that task's `Checklist` remains unchecked.
-  - `workflow.agentReview.maxRounds` counts automatic finding-remediation passes, not the initial review. After those passes are exhausted, preserve remaining `changes_requested` findings as residual risks and auto-complete the review gate without user approval. Never auto-complete `blocked`.
+  - `workflow.agentReview.maxRounds` is the maximum number of fresh reviews. On `changes_requested` at the final allowed round, apply the findings once, preserve remaining findings and the resulting target change as residual risks, and auto-complete the review gate without another review or user approval. With `maxRounds=1`, there is no round 2. Never auto-complete `blocked`.
 - **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.
@@ -67,6 +67,8 @@
     - (verification condition)
   - Checklist:
     - [ ] (subtask)
+  - Docs:
+    - (use a `docs:<path>` or `project:<path>` target, or omit this section)
   - Review Evidence: -
   - Review Decision: -
   - Review Round: -
@@ -83,13 +85,20 @@
 
 > Add tasks below. **At least 1 task is required.**
 > Keep tasks as one ordered list. The list order itself is the execution priority.
-> Prefer `npx lee-spec-kit task add <feature-ref> --title "..." --ref NON-PRD --acceptance "..." --check "..."` for appending new tasks.
+> Prefer `npx lee-spec-kit task add <feature-ref> --title "..." --ref NON-PRD --acceptance "..." --check "..." --doc "docs:prd/system-architecture.md"` for appending new tasks.
 > To add a new task, append a complete task block below the last existing task. Use an existing PRD key such as `PRD-FR-001` or `PRD-SCOPE-V1-DESKTOP-EDITOR`, or `[NON-PRD]` for internal work.
 > Do not leave placeholder `Acceptance` / `Checklist` content in place; implementation should not start 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`.
 
 ---
 
+## Knowledge Sync
+
+- **Policy**: Derived from `.lee-spec-kit.json` `experimental.openwiki`
+- **Receipt**: `.lee-spec-kit/openwiki-sync.json`
+
+---
+
 ## Completion Criteria
 
 > ⚠️ This is a **final verification checklist**. Only check after you actually verified.

package/templates/ko/common/README.md

@@ -54,6 +54,18 @@ npx lee-spec-kit docs get agents --json
 
 제품 로드맵은 `prd/`에 두지만 구현 순서와 작업 계획은 활성 Feature의 `plan.md`와 `tasks.md`에서 관리합니다. `designs/`는 UX와 시각 디자인 전용이며 기술 설계 문서를 두지 않습니다.
 
+### Knowledge Architecture와 권한
+
+1. Feature SDD(`spec.md`, `plan.md`, `tasks.md`, `decisions.md`)는 요구사항, 범위, 결정, 인수 조건의 규범입니다.
+2. 사람이 관리하는 PRD, 아키텍처, 온보딩, 운영 문서는 프로젝트 전체의 curated 현재 상태입니다.
+3. `openwiki/`는 파생된 온보딩·코드 탐색 계층입니다. 그 내용은 tracked 소스, 테스트, 스키마, curated 문서로 다시 검증합니다.
+
+모든 Plan은 명시적인 `NONE`까지 포함해 `Curated Documentation Impact`를 완료해야 합니다. 모든 `UPDATE` 또는 `ADD` 대상은 하나 이상의 task `Docs` 목록에 연결하고 완료 전에 활성 Feature scope로 커밋합니다. 이 전파 규칙은 OpenWiki 활성화 여부와 무관하게 적용됩니다.
+
+`experimental.openwiki`가 `true`이면 task checkpoint 뒤에 Knowledge 준비·동기화·커밋 stage와 Feature 리뷰가 필수로 붙습니다. 누락 또는 `false`면 이 stage들은 전혀 추가되지 않습니다. `lee-spec-kit knowledge sync`만 사용하고 생성 페이지를 손으로 수정하거나 workflow에서 OpenWiki를 직접 호출하지 않습니다.
+
+OpenWiki는 sandboxed renderer가 아니라 외부 에이전트입니다. 신뢰할 수 있는 저장소와 적절히 격리한 실행 환경에서만 활성화하고, 로컬·ignored secret이 접근 가능한 환경에 남지 않도록 관리합니다.
+
 ---
 
 ## SSOT 관계 (PRD / Ideas / Features)
@@ -123,6 +135,8 @@ Local 통합 방식을 직접 선택할 수 있습니다. 비대화형 실행에
 기존 프로젝트도 `lee-spec-kit config --interactive` 또는 같은 config 플래그로
 이 설정을 변경할 수 있습니다.
 
+OpenWiki 실험 기능은 별도의 단일 옵션 `--openwiki true|false`로 제어합니다.
+
 - `lee-spec-kit feature`, `config`, `update`, `detect`, workflow validator에서 문서 위치/프로젝트 타입/언어를 해석하는 용도로 사용됩니다.
 - `docsRepo`, `pushDocs`, `docsRemote`는 CLI 관리 **Docs Push 정책**을 위한 메타데이터입니다. (자동 push는 하지 않습니다)
 
@@ -135,6 +149,7 @@ Local 통합 방식을 직접 선택할 수 있습니다. 비대화형 실행에
 - `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 리뷰를 요구
 - `workflow.agentExecution.task` (object): 태스크 구현 위임 설정
   - `enabled`: 각 `task_execute`를 서브에이전트에게 위임할지 여부. 새 프로젝트의 기본값은 `true`이며, 이 설정이 생기기 전 프로젝트는 명시적으로 켜기 전까지 꺼진 상태를 유지
   - `type`: 현재 `"subagent"`만 지원
@@ -144,7 +159,7 @@ Local 통합 방식을 직접 선택할 수 있습니다. 비대화형 실행에
   - `workflow-stage`는 안정적인 태스크 ID, 작업/docs 경로, machine-readable `workerContract`를 반환합니다. worker는 `workflow-stage` 재호출이나 재위임 없이 직접 실행합니다.
   - 구현 서브에이전트는 프로젝트 코드와 태스크 범위 검사를 담당하고, 메인 에이전트는 문서, 태스크 상태, 커밋, 승인, 원격 작업을 유지합니다. 공식 hook은 `task_execute` 중 커밋을 거부합니다.
 - `workflow.agentAutomationConfigured` (boolean): `init` 또는 `config`에서 에이전트 자동화 정책을 명시적으로 선택했음을 기록해, 구버전 기본값 복구가 해당 선택을 덮어쓰지 않게 함
-- `workflow.agentReview.maxRounds` (양의 정수): Plan/태스크/Feature 리뷰에 공통 적용되는 리뷰 지적 자동 반영 최대 횟수. 한도 뒤 남은 `changes_requested` finding은 잔여 위험으로 보존하고 리뷰 게이트를 자동 완료합니다. 최초 리뷰는 세지 않으며 기본값은 `1`
+- `workflow.agentReview.maxRounds` (양의 정수): Plan/태스크/Feature 게이트에 공통 적용되는 fresh 리뷰 최대 실행 횟수. 마지막 허용 `changes_requested` 리뷰의 지적은 한 번 반영하고, 남은 finding과 그 결과의 target 변경을 잔여 위험으로 보존한 뒤 추가 리뷰 없이 게이트를 자동 완료합니다. 기본값은 `1`이며 Round 2는 실행하지 않습니다
 - `workflow.agentReview.plan` / `workflow.agentReview.task` / `workflow.agentReview.feature` (object): Plan/태스크/Feature 독립 리뷰 설정
   - `enabled`: 해당 리뷰 게이트 활성화 여부. 새 프로젝트는 Plan과 Feature `true`, task `false`
   - `evidenceMode`: `path_required | any`
@@ -183,6 +198,9 @@ Local 통합 방식을 직접 선택할 수 있습니다. 비대화형 실행에
   "lang": "ko",
   "createdAt": "{{date}}",
   "docsRepo": "embedded",
+  "experimental": {
+    "openwiki": false
+  },
   "workflow": {
     "mode": "local",
     "agentAutomationConfigured": true,
@@ -249,7 +267,7 @@ Local 통합 방식을 직접 선택할 수 있습니다. 비대화형 실행에
 }
 ```
 
-새 프로젝트는 기본적으로 태스크 구현을 위임하고 Plan 검수를 활성화합니다. 해당 설정이 생기기 전의 기존 프로젝트는 Task 위임과 Plan/Task 검수를 꺼진 상태로 유지하므로, 업데이트만으로 실행 정책이 바뀌지 않습니다. v0.9.4-v0.9.6 업데이트가 생성 기본값을 이미 기록한 기존 프로젝트도 생성일과 수정되지 않은 기본 설정 형태로 식별되면 안전한 비활성 상태로 복구하며, 커스텀 에이전트 설정은 보존합니다. `lee-spec-kit config --interactive` 또는 `config --task-agent on|off --reviews plan,task,feature|none --max-review-rounds N`으로 명시적으로 켜거나 변경할 수 있습니다. 새 local 프로젝트는 `local-ff`와 Feature agent review를 사용합니다. 기존 Feature 리뷰 동작은 이전 Pre-PR 설정과 workflow mode의 의미를 보존합니다. 리뷰 지적 자동 반영 기본값은 `1`입니다. 즉 첫 리뷰 지적은 한 번 반영하고 다시 리뷰합니다. 다음 리뷰도 `changes_requested`이면 finding을 잔여 위험으로 보존하고 사용자 승인 없이 리뷰 게이트를 자동 완료합니다. `blocked`는 자동 완료하지 않습니다. base branch에 하나의 commit만 남기려면 `local-squash`를 선택하세요. 이때 task checkpoint 증거를 위해 원본 Feature tip을 내부 `refs/lee-spec-kit/integrations/*` ref로 보존합니다. 기존 local 프로젝트에 명시적 `completionStrategy`가 없으면 `update`가 `none`을 넣어 업그레이드 도중 현재 브랜치를 갑자기 병합하지 않습니다. 준비가 끝난 뒤 `local-ff` 또는 `local-squash`로 명시적으로 전환하세요.
+새 프로젝트는 기본적으로 태스크 구현을 위임하고 Plan 검수를 활성화합니다. 해당 설정이 생기기 전의 기존 프로젝트는 Task 위임과 Plan/Task 검수를 꺼진 상태로 유지하므로, 업데이트만으로 실행 정책이 바뀌지 않습니다. v0.9.4-v0.9.6 업데이트가 생성 기본값을 이미 기록한 기존 프로젝트도 생성일과 수정되지 않은 기본 설정 형태로 식별되면 안전한 비활성 상태로 복구하며, 커스텀 에이전트 설정은 보존합니다. `lee-spec-kit config --interactive` 또는 `config --task-agent on|off --reviews plan,task,feature|none --max-review-rounds N`으로 명시적으로 켜거나 변경할 수 있습니다. 새 local 프로젝트는 `local-ff`와 Feature agent review를 사용합니다. 기존 Feature 리뷰 동작은 이전 Pre-PR 설정과 workflow mode의 의미를 보존합니다. fresh 리뷰 최대 실행 횟수의 기본값은 `1`입니다. 즉 Round 1의 지적을 한 번 반영한 뒤 다시 리뷰하지 않고, 남은 finding과 변경된 target을 잔여 위험으로 보존해 사용자 승인 없이 리뷰 게이트를 자동 완료합니다. `blocked`는 자동 완료하지 않습니다. base branch에 하나의 commit만 남기려면 `local-squash`를 선택하세요. 이때 task checkpoint 증거를 위해 원본 Feature tip을 내부 `refs/lee-spec-kit/integrations/*` ref로 보존합니다. 기존 local 프로젝트에 명시적 `completionStrategy`가 없으면 `update`가 `none`을 넣어 업그레이드 도중 현재 브랜치를 갑자기 병합하지 않습니다. 준비가 끝난 뒤 `local-ff` 또는 `local-squash`로 명시적으로 전환하세요.
 
 ```json
 {

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

@@ -5,6 +5,12 @@
 
 ---
 
+## Codex lifecycle 범위
+
+- <!-- lee-spec-kit:delegation-context-v1 -->
+- 감지, built-in 문서 부트스트랩, 활성 Feature 결정, `workflow-stage`는 메인 에이전트의 책임입니다.
+- Codex `SubagentStart`가 식별한 위임 서브에이전트는 메인 에이전트 부트스트랩과 `workflow-stage`를 생략합니다. 메인 에이전트가 전달한 정확한 `delegationContext`와 `workerContract`를 따르고, `requiredDocuments`를 읽으며, `referenceDocuments`는 명시된 조건에서만 사용하고, 범위가 부족하면 확장 전에 메인 에이전트에 요청합니다.
+
 ## 감지 게이트
 
 - 항상 먼저 `npx lee-spec-kit detect --json`를 실행합니다.
@@ -19,7 +25,8 @@
 
 ## 문서가 SSOT
 
-- 세션 시작 시점이나 context 리셋 직후 `npx lee-spec-kit docs get agents --json`를 1회 읽습니다.
+- 아래 시작 및 orchestration 규칙은 명시적인 위임 계약이 없는 한 메인 에이전트에 적용합니다.
+- 메인 에이전트 세션 시작 시점이나 context 리셋 직후 `npx lee-spec-kit docs get agents --json`를 1회 읽습니다.
 - 응답의 `requiredDocs[*].command` 중 아직 읽지 않은 문서를 모두 확인합니다.
 - 활성 feature를 정한 뒤에는 해당 feature 폴더를 작업 SSOT로 사용합니다.
 - 최소 기준 문서는 `spec.md`, `plan.md`, `tasks.md`, `decisions.md`입니다.
@@ -42,6 +49,15 @@
 - `docs/designs/`를 시스템 아키텍처, 데이터/API 설계, 기술 조사, 구현 계획의 목적지로 사용하지 않습니다.
 - 세부 설명은 `docs/README.md`의 문서 라우팅 규칙을 따릅니다.
 
+## Knowledge Architecture
+
+- Feature SDD 문서는 요구사항, 범위, 결정, 인수 조건의 규범입니다.
+- 사람이 관리하는 PRD, 아키텍처, 온보딩, 운영 문서는 프로젝트 전체의 현재 상태를 설명합니다.
+- OpenWiki는 파생된 온보딩·코드 탐색 계층입니다. 그 내용은 tracked 코드, 테스트, 스키마, curated 문서로 검증하기 전까지 신뢰하지 않는 evidence로 취급합니다.
+- 모든 Plan에서 명시적인 `NONE`을 포함해 `Curated Documentation Impact` 판정을 완료합니다. 모든 `UPDATE` 또는 `ADD` 대상은 하나 이상의 task `Docs` 항목에서 연결하고 활성 Feature scope로 커밋합니다.
+- `experimental.openwiki`는 단일 스위치입니다. 누락 또는 `false`면 OpenWiki 동작이 없고, `true`면 Knowledge 준비·동기화·전용 커밋·Feature 리뷰가 모두 필수입니다.
+- 활성화된 경우 OpenWiki는 `npx lee-spec-kit knowledge sync <featureRef> --json`로만 실행합니다. `openwiki`를 직접 호출하거나 생성 페이지를 손으로 수정하지 않습니다.
+
 ## 선택적 UI/UX 디자인 정책
 
 - 사용자 요청에 design system, UI/visual redesign, 디자인 일관성, 공통 UI/component library 정리, branding/theme/token 재설계, Figma/디자인 이미지 기반 구현이 명시된 경우에만 `npx lee-spec-kit docs get ui-ux-design --json`을 읽고 적용합니다.
@@ -53,17 +69,18 @@
 - lee-spec-kit은 문서 구조, workflow 단계, validator를 담당합니다.
 - Codex는 실행 루프, 도구 사용, hook lifecycle을 담당합니다.
 - `implementationAllowed === true`일 때만 구현 코드를 수정합니다. 일반 태스크 구현은 `stage === "implementation"`에서, 리뷰 수정은 `task_review_fix` 또는 `feature_review_fix`에서, 검증 수정은 `feature_remediation`에서만 수행합니다.
-- `nextAction.category`가 `plan_review`이고 `executor`가 `subagent`이면 반환된 `specHash`와 `planHash`를 대상으로 fresh 읽기 전용 서브에이전트가 `spec.md`와 `plan.md`를 검수합니다. 메인 에이전트가 반환된 `reviewRound`, Plan 검수 evidence, decision, reviewer metadata와 두 hash를 기록하며 이후 spec/plan 내용 변경은 기존 검수를 무효화합니다.
-- `nextAction.category`가 `task_execute`이고 `executor`가 `subagent`이면 해당 태스크 하나를 활성화한 뒤, 반환된 `workingDirectory`에서 fresh 서브에이전트에게 반환된 모델·추론도·unavailability 정책과 정확한 `workerContract`로 구현과 태스크 범위 검증을 위임합니다. 특정 이름의 실행 스킬은 요구하지 않습니다.
+- `nextAction.category`가 `plan_review`이고 `executor`가 `subagent`이면 정확히 반환된 `delegationContext`, `specHash`, `planHash`로 fresh 읽기 전용 서브에이전트에게 검수를 위임합니다. 메인 에이전트가 반환된 `reviewRound`, Plan 검수 evidence, decision, reviewer metadata와 두 hash를 기록하며 이후 spec/plan 내용 변경은 기존 검수를 무효화합니다.
+- `nextAction.category`가 `task_execute`이고 `executor`가 `subagent`이면 해당 태스크 하나를 활성화한 뒤, 반환된 `workingDirectory`에서 fresh 서브에이전트에게 반환된 모델·추론도·unavailability 정책, 정확한 `workerContract`, 정확한 `delegationContext`로 구현과 태스크 범위 검증을 위임합니다. 컨텍스트를 재구성하거나 누락하거나 넓히지 않습니다. 특정 이름의 실행 스킬은 요구하지 않습니다.
 - 구현 worker는 승인된 Verification Contract를 따르고 계획되지 않은 영구 테스트를 추가하지 않으며 직접 실행합니다. `workflow-stage`를 호출하거나 다른 서브에이전트를 생성하지 않습니다. 프로젝트 코드 수정과 범위 내 검사는 수행할 수 있지만 lee-spec-kit 문서 수정, 태스크 상태 변경, 커밋, 승인 요청, 원격/파괴적 작업은 하지 않습니다. 메인 에이전트가 결과를 확인하고 문서 동기화, 태스크 전환, 커밋, 후속 workflow를 소유하며, 공식 hook은 `task_execute`가 활성화된 동안 커밋을 차단합니다.
-- `nextAction.category`가 `task_review`이고 `executor`가 `subagent`이면 반환된 task ID와 SHA/tree 범위를 fresh context의 읽기 전용 서브에이전트가 리뷰하고 반환된 `reviewRound`를 기록합니다.
-- `nextAction.category`가 `pre_pr_review`이고 `executor`가 `subagent`이면 반환된 모델·추론도·`reviewRound`·SHA/tree 범위로 fresh context의 읽기 전용 Feature 리뷰를 실행합니다. 리뷰 스킬 이름을 선택하거나 요구하지 않습니다.
+- `nextAction.category`가 `task_review`이고 `executor`가 `subagent`이면 정확히 반환된 `delegationContext`, task ID, SHA/tree 범위로 fresh context의 읽기 전용 리뷰를 위임하고 반환된 `reviewRound`를 기록합니다.
+- `nextAction.category`가 `pre_pr_review`이고 `executor`가 `subagent`이면 정확히 반환된 `delegationContext`, 모델·추론도·`reviewRound`·SHA/tree 범위로 fresh context의 읽기 전용 Feature 리뷰를 실행합니다. 리뷰 스킬 이름을 선택하거나 요구하지 않습니다.
 - 리뷰 서브에이전트는 finding만 반환하고 코드를 수정하지 않습니다. 메인 에이전트가 finding을 반영하고 reviewer metadata, reviewed scope, evidence, decision, 정확한 hash/SHA/tree target metadata를 기록합니다.
 - 서브에이전트에게 위임한 뒤에는 완료, 명시적 실패, 취소, 또는 조치가 필요한 승인·사용자 입력 요청 중 하나의 종결 상태를 반환할 때까지 기다립니다.
 - 서브에이전트가 실행 중이면 가급적 긴 bounded wait를 반복합니다. 한 번의 대기가 새 소식 없이 끝난 것, 상태 메시지가 없는 것, 파일 변경이 없는 것은 아직 실행 중이라는 뜻일 뿐 실패나 정체의 증거가 아닙니다. 읽기 전용 리뷰 서브에이전트는 파일을 변경하지 않는 것이 정상입니다.
 - 조용하거나 파일을 변경하지 않았다는 이유만으로 실행 중인 서브에이전트를 중단·교체·포기하지 않습니다. 사용자의 명시적 중단 요청, 종결 실패·취소, 또는 복구 불가능한 런타임 상태가 있을 때만 중단합니다.
-- `workflow.agentReview.maxRounds`는 최초 리뷰 횟수가 아니라 리뷰 지적 자동 반영 횟수입니다. 그 횟수를 모두 사용하면 최신 `changes_requested` finding을 잔여 위험으로 보존하고 사용자 리뷰 승인 토큰 없이 Plan/task/Feature 리뷰 게이트를 자동 완료합니다. `blocked` 결정은 자동 완료하지 않습니다.
+- `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로 커밋합니다.
 - 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을 허가합니다.

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

@@ -24,8 +24,8 @@
   - `tasks.md`는 실제 실행 순서를 정의합니다
   - `issue.md`, `pr.md`는 GitHub 단계에 들어가면 stage gate의 일부로 사용합니다
 - `tasks.md`가 있다고 바로 구현하지 않습니다. 구현은 `workflow-stage --json`가 허용할 때만 시작합니다.
-- Plan 검수가 활성화되어 있으면 `plan.md`를 Review로 바꾸고 반환된 fresh 읽기 전용 `plan_review`를 위임한 뒤 `reviewRound`, evidence, decision, reviewer metadata, `specHash`, `planHash`를 기록합니다. 현재 hash에 대한 approve 검수만 Plan 승인으로 이어질 수 있습니다. reviewer는 문서를 수정하지 않고 NONE/UPDATE/ADD 결정, 요구사항 커버리지, 독립적인 Oracle, 안정적인 관찰 경계, 현실적인 실패/롤백, 제외 범위, focused/full 검증 범위를 점검합니다.
-- `workflow.agentReview.maxRounds`는 최초 Plan 리뷰가 아니라 지적 자동 반영 횟수입니다. 한도 뒤 남은 `changes_requested` finding은 잔여 위험으로 보존하고 사용자 리뷰 승인 토큰 없이 Plan을 자동 승격합니다. `blocked`는 자동 완료하지 않습니다.
+- Plan 검수가 활성화되어 있으면 `plan.md`를 Review로 바꾸고 반환된 fresh 읽기 전용 `plan_review`를 위임한 뒤 `reviewRound`, evidence, decision, reviewer metadata, `specHash`, `planHash`를 기록합니다. approve 검수는 현재 hash와 일치해야 하며, 한도를 소진한 `changes_requested`는 아래의 잔여 위험 자동 완료 경로를 따릅니다. reviewer는 문서를 수정하지 않고 NONE/UPDATE/ADD 결정, 요구사항 커버리지, 독립적인 Oracle, 안정적인 관찰 경계, 현실적인 실패/롤백, 제외 범위, focused/full 검증 범위를 점검합니다.
+- `workflow.agentReview.maxRounds`는 fresh Plan 리뷰의 최대 실행 횟수입니다. 마지막 허용 Round가 `changes_requested`이면 지적을 한 번 반영하고 남은 finding과 그 결과의 hash 변경을 잔여 위험으로 보존한 뒤, 추가 리뷰나 사용자 리뷰 승인 토큰 없이 Plan을 자동 승격합니다. `maxRounds=1`이면 Round 2는 없습니다. `blocked`는 자동 완료하지 않습니다.
 - 범위나 동작이 바뀌면 같은 턴 안에서 활성 feature 문서를 같이 업데이트합니다.
 - 사용자 승인은 문서화된 review checkpoint와 원격/파괴적 작업 전에만 요청합니다.
 - docs 경로 검사가 중요하면 `git commit` 전에 `npx lee-spec-kit commit-audit --json`를 사용합니다.

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

@@ -33,8 +33,8 @@ Pre-PR 리뷰에서 서브에이전트가 항상 수행하는 최소 기준입
 10. `PR 전 리뷰 Decision`은 `결정: approve|changes_requested|blocked ...` (또는 `decision: ...`) 형식을 사용합니다.
 11. 반환된 `reviewRound`를 `PR 전 리뷰 Round`에 기록합니다.
 12. `PR 전 리뷰 Head`와 `PR 전 리뷰 Tree`가 `workflow-stage`의 `targetSha`와 `targetTree`와 일치하는지 확인합니다.
-13. `workflow.agentReview.maxRounds`는 최초 Feature 리뷰가 아니라 지적 자동 반영 횟수입니다. 한도 뒤 남은 `changes_requested` finding은 잔여 위험으로 보존하고 사용자 리뷰 승인 토큰 없이 Feature 리뷰 게이트를 자동 완료합니다. `blocked`는 자동 완료하지 않습니다.
-14. PR 생성 단계로 이동하기 전 최종 Decision이 `approve`인지 확인합니다.
+13. `workflow.agentReview.maxRounds`는 fresh Feature 리뷰의 최대 실행 횟수입니다. 마지막 허용 Round가 `changes_requested`이면 지적을 한 번 반영하고 남은 finding과 그 결과의 target 변경을 잔여 위험으로 보존한 뒤, 추가 리뷰나 사용자 리뷰 승인 토큰 없이 Feature 리뷰 게이트를 자동 완료합니다. `maxRounds=1`이면 Round 2는 없습니다. `blocked`는 자동 완료하지 않습니다.
+14. 최종 Decision이 `approve`이거나 위의 한도 소진 `changes_requested` 경로가 게이트를 자동 완료한 뒤 PR 생성 단계로 이동합니다.
 
 리뷰 산출물에는 실제 사용한 `executor`, `model`, `reasoningEffort`, 검토한 commit/diff 범위, target SHA/tree, finding과 최종 decision을 기록합니다. 리뷰 서브에이전트는 코드를 수정하지 않으며, finding 반영과 문서 갱신은 메인 에이전트가 담당합니다.
 

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

@@ -13,7 +13,7 @@
   - 이미 `[DOING]`인 태스크가 하나 있으면 그것을 이어서 수행하고
   - 없으면 가장 우선순위가 높은 `[TODO]` 태스크를 `[DOING]`으로 바꿉니다
 - 한 번에 하나의 태스크만 진행합니다.
-- `nextAction.executor === "subagent"`이면 반환된 `workingDirectory`에서 해당 태스크의 구현과 태스크 범위 검증을 fresh 서브에이전트에게 반환된 `model`, `reasoningEffort`, `onUnavailable` 설정과 정확한 `workerContract`로 위임합니다. 지정 모델을 사용할 수 없을 때 `inherit`은 현재 모델을 상속해 다시 위임하고, `error`는 중단 후 실패를 보고한다는 뜻입니다.
+- `nextAction.executor === "subagent"`이면 반환된 `workingDirectory`에서 해당 태스크의 구현과 태스크 범위 검증을 fresh 서브에이전트에게 반환된 `model`, `reasoningEffort`, `onUnavailable` 설정, 정확한 `workerContract`, 정확한 `delegationContext`로 위임합니다. 컨텍스트를 재구성하거나 누락하거나 넓히지 않습니다. 지정 모델을 사용할 수 없을 때 `inherit`은 현재 모델을 상속해 다시 위임하고, `error`는 중단 후 실패를 보고한다는 뜻입니다.
 - 구현 worker는 할당된 태스크를 직접 실행합니다. `workflow-stage` 재호출, 재위임, lee-spec-kit 문서 수정, 태스크 상태 변경, 커밋, 승인 요청, 원격/파괴적 작업은 하지 않습니다. 프로젝트 코드 수정과 태스크 범위 검사만 수행합니다.
 - 위임한 뒤 메인 에이전트는 worker의 종결 상태를 기다립니다. worker가 실행 중이면 가급적 긴 bounded wait를 반복하며, 한 번의 대기가 새 소식 없이 끝난 것, 상태 메시지가 없는 것, 파일 변경이 없는 것은 실패나 정체의 증거가 아닙니다.
 - 조용하거나 파일을 변경하지 않았다는 이유만으로 실행 중인 worker를 중단·교체·포기하지 않습니다. 사용자의 명시적 중단 요청, 종결 실패·취소, 또는 복구 불가능한 런타임 상태가 있을 때만 중단합니다.
@@ -25,8 +25,8 @@
 - `tasks.md`를 현실과 맞게 유지합니다:
   - 실제 완료/검증 없이 `[DONE]`로 바꾸지 않습니다
   - `workflow.agentReview.task.enabled=true`이면 구현/검증 완료 후 `[DONE]` 대신 `[REVIEW]`로 바꾸고 checkpoint commit을 만든 뒤 독립 리뷰를 진행합니다
-  - 반환된 `reviewRound`를 기록하고, task review가 현재 SHA/tree를 `approve`한 뒤에만 `[REVIEW]`를 `[DONE]`으로 바꿉니다
-  - `workflow.agentReview.maxRounds`는 최초 task 리뷰가 아니라 지적 자동 반영 횟수입니다. 한도 뒤 남은 `changes_requested` finding은 잔여 위험으로 보존하고 사용자 리뷰 승인 토큰 없이 task를 DONE으로 전환합니다. `blocked`는 자동 완료하지 않습니다
+  - 반환된 `reviewRound`를 기록하고, task review가 현재 SHA/tree를 `approve`하거나 아래의 한도 소진 `changes_requested` 경로가 자동 완료된 뒤 `[REVIEW]`를 `[DONE]`으로 바꿉니다
+  - `workflow.agentReview.maxRounds`는 fresh task 리뷰의 최대 실행 횟수입니다. 마지막 허용 Round가 `changes_requested`이면 지적을 한 번 반영하고 남은 finding과 그 결과의 target 변경을 잔여 위험으로 보존한 뒤, 추가 리뷰나 사용자 리뷰 승인 토큰 없이 task를 DONE으로 전환합니다. `maxRounds=1`이면 Round 2는 없습니다. `blocked`는 자동 완료하지 않습니다
   - 태스크를 닫을 때는 같은 수정에서 `Acceptance`와 `Checklist`도 함께 갱신합니다
   - 완료된 태스크에 후속 작업이 생기면 히스토리를 고치지 말고 새 태스크를 추가합니다
 - 새 태스크를 추가해야 한다면 `tasks.md`에 구체적인 제목, `Acceptance`, `Checklist`, 그리고 `NON-PRD` 또는 기존 `PRD-*` 태그가 있는 완전한 태스크 블록을 추가하세요.

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

@@ -57,13 +57,17 @@ npx lee-spec-kit workflow-stage <feature-ref> --json
 
 반환되는 `stage`, `nextAction`, `implementationAllowed` 값을 현재 워크플로우 상태로 사용하세요.
 
+Plan 검수 또는 승인 전에 `Curated Documentation Impact`를 완료합니다. 명시적인 `NONE`은 해당 영역을 검토했다는 증거이며, 모든 `UPDATE` 또는 `ADD` 대상은 하나 이상의 task `Docs` 아래에 있어야 합니다.
+
+`experimental.openwiki=true`이면 완료된 모든 task checkpoint 뒤에 필수 `knowledge_setup`, `knowledge_sync`, `knowledge_commit` stage를 거쳐 Feature 리뷰로 이동합니다. Feature reviewer는 `openwiki/index.md`, 검증 receipt, Plan이 선언한 모든 curated target을 받으며, SDD와 curated 프로젝트 문서가 계속 상위 권한을 가집니다. Knowledge surface에는 `.openwikiignore`의 마지막 lee-spec-kit 보호 블록도 포함됩니다.
+
 Plan 검수가 활성화되면 계획 단계는 `plan Review → fresh 읽기 전용 Plan 검수 → plan 승인` 순서로 진행됩니다. 검수는 반환된 `specHash`와 `planHash`에 묶이며 두 문서 중 하나의 내용이 바뀌면 기존 evidence가 무효입니다. reviewer는 문서를 수정하지 않고 Verification Contract와 테스트 결정을 점검합니다.
 
 `tasks.md`의 최종 완료 체크박스 3개에는 `lee-spec-kit:completion:*` HTML marker가 있습니다. 사용자에게 보이는 문구는 바꿔도 되지만 각 체크박스 라인의 marker는 유지하세요. `workflow-stage`는 marker를 machine-readable identity로 우선 사용하고, 기존 프로젝트 호환을 위해 marker가 없으면 이전 canonical 문구를 fallback으로 인식합니다.
 
 Feature agent review가 활성화된 local workflow의 완료 흐름은 `feature review → implementation_approve → feature_verify → local_merge → local_cleanup → done`입니다. 태스크 리뷰가 활성화되면 각 태스크는 `DOING → REVIEW → task review → DONE`을 거칩니다. 검사 실패 시 구현이 허용된 `feature_remediation`으로 이동합니다. `local-ff`는 검증된 Feature SHA만 옮기고, `local-squash`는 통합 tree가 검증된 Feature tree와 같아야 합니다. 둘 다 cleanup 후에만 `done`입니다. cleanup이 끝난 Feature는 기록된 통합 커밋이 현재 base의 조상으로 남아 있는 한 후속 Feature가 base를 전진시켜도 `done`을 유지합니다.
 
-`workflow.agentExecution.task.enabled=true`이면 각 `task_execute`가 설정된 서브에이전트 모델·추론도·안정적인 태스크 ID·구현 작업 경로·machine-readable `workerContract`를 반환합니다. worker는 `workflow-stage`를 재호출하거나 다시 위임하지 않고 직접 실행합니다. 승인된 Verification Contract를 따르고 계획되지 않은 영구 테스트를 추가하지 않으며 프로젝트 코드와 태스크 범위 검사만 담당합니다. 메인 에이전트가 문서 동기화, 태스크 전환, 커밋, 승인, 원격 작업을 소유하고 공식 hook은 메인 에이전트가 workflow를 `task_commit`으로 전진시키기 전까지 커밋을 차단합니다.
+`workflow.agentExecution.task.enabled=true`이면 각 `task_execute`가 설정된 서브에이전트 모델·추론도·안정적인 태스크 ID·구현 작업 경로·machine-readable `workerContract`와 versioned `delegationContext`를 반환합니다. 이 컨텍스트에는 정확한 태스크 블록, Acceptance, Verification Contract, 필수 Feature 문서와 조건부 참조가 들어 있으며 worker에게 변경 없이 전달합니다. worker는 `workflow-stage`를 재호출하거나 다시 위임하지 않고 직접 실행합니다. 계획되지 않은 영구 테스트를 추가하지 않으며 프로젝트 코드와 태스크 범위 검사만 담당합니다. 메인 에이전트가 문서 동기화, 태스크 전환, 커밋, 승인, 원격 작업을 소유하고 공식 hook은 메인 에이전트가 workflow를 `task_commit`으로 전진시키기 전까지 커밋을 차단합니다.
 
 remediation 커밋이 추가되면 기존 검증과 local merge 승인은 무효입니다. Pre-PR review가 활성화되어 있다면 변경된 diff의 review evidence를 갱신하고 새 tip을 검증한 뒤 local merge 승인을 다시 받습니다.
 

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

@@ -49,6 +49,27 @@ src/
 
 ---
 
+## Curated Documentation Impact
+
+> 모든 결정이 `NONE`이어도 영향 판정을 완료합니다. `NONE`은 사람이 관리하는 상위 문서를 검토했지만 변경할 필요가 없다는 뜻입니다. 생성형 OpenWiki 동기화는 별도로 판정합니다.
+
+- **Assessment**: Pending
+  - 값: Pending | Complete
+- **Product requirements**: -
+  - 값: NONE | UPDATE | ADD
+- **System architecture**: -
+  - 값: NONE | UPDATE | ADD
+- **Onboarding entrypoint**: -
+  - 값: NONE | UPDATE | ADD
+- **Operational/runtime contract**: -
+  - 값: NONE | UPDATE | ADD
+- **Reason**: -
+- **Targets**: -
+  - UPDATE 또는 ADD가 하나라도 있으면 쉼표로 구분한 `docs:<path>`와 `project:<path>` 대상을 기록합니다.
+  - 모든 대상은 task `Docs` 목록에 연결하고 Knowledge 동기화 또는 Feature 리뷰 전에 활성 Feature scope로 커밋합니다.
+
+---
+
 ## Verification Contract
 
 ### 변경 분류

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

@@ -11,7 +11,7 @@
   - 태스크 상태 변경 전에 승인이 필요한 경우는 문서화된 review checkpoint 또는 원격/파괴적 작업 직전뿐입니다.
   - 워크플로우가 요구하지 않는 standalone `OK` 승인 단계는 만들지 않습니다.
   - 해당 태스크의 `Checklist`에 unchecked 항목이 남아 있으면 `[DONE]`으로 전환하지 않습니다.
-  - `workflow.agentReview.maxRounds`는 최초 리뷰가 아니라 리뷰 지적 자동 반영 횟수입니다. 그 횟수를 다 쓰면 남은 `changes_requested` finding을 잔여 위험으로 보존하고 사용자 승인 없이 리뷰 게이트를 자동 완료합니다. `blocked`는 자동 완료하지 않습니다.
+  - `workflow.agentReview.maxRounds`는 fresh 리뷰의 최대 실행 횟수입니다. 마지막 허용 Round가 `changes_requested`이면 지적을 한 번 반영하고 남은 finding과 그 결과의 target 변경을 잔여 위험으로 보존한 뒤, 추가 리뷰나 사용자 승인 없이 리뷰 게이트를 자동 완료합니다. `maxRounds=1`이면 Round 2는 없습니다. `blocked`는 자동 완료하지 않습니다.
 - **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`와 태스크 태그를 함께 맞추세요.
@@ -67,6 +67,8 @@
     - (검증 조건)
   - Checklist:
     - [ ] (서브 태스크)
+  - Docs:
+    - (`docs:<path>` 또는 `project:<path>` 대상을 사용하거나 이 섹션을 생략)
   - Review Evidence: -
   - Review Decision: -
   - Review Round: -
@@ -83,13 +85,20 @@
 
 > 아래에 태스크를 추가하세요. **최소 1개가 필요**합니다.
 > 태스크는 하나의 순차 리스트로 유지하고, 위에서 아래 순서 자체를 실행 우선순위로 취급하세요.
-> 새 태스크 append에는 `npx lee-spec-kit task add <feature-ref> --title "..." --ref NON-PRD --acceptance "..." --check "..."` 사용을 우선하세요.
+> 새 태스크 append에는 `npx lee-spec-kit task add <feature-ref> --title "..." --ref NON-PRD --acceptance "..." --check "..." --doc "docs:prd/system-architecture.md"` 사용을 우선하세요.
 > 새 태스크는 마지막 기존 태스크 아래에 완전한 태스크 블록으로 추가하세요. `PRD-FR-001`이나 `PRD-SCOPE-V1-DESKTOP-EDITOR`처럼 이미 정의된 PRD key를 사용하거나, 내부 작업이면 `[NON-PRD]`를 사용합니다.
 > placeholder 상태의 `Acceptance` / `Checklist`를 그대로 두지 마세요. 구체 항목이 아니면 구현을 시작하지 않습니다.
 > 수동 편집이 필요하면 현재 태스크 근처가 아니라 `태스크 목록`의 마지막 기존 태스크 block 아래에만 append 하세요.
 
 ---
 
+## Knowledge Sync
+
+- **Policy**: `.lee-spec-kit.json`의 `experimental.openwiki`에서 파생
+- **Receipt**: `.lee-spec-kit/openwiki-sync.json`
+
+---
+
 ## 완료 조건
 
 > ⚠️ 아래 항목은 **최종 확인 체크리스트**입니다. 실제로 확인/실행한 뒤에만 체크하세요.