aimship 0.1.0-preview.14 → 0.1.0-preview.16

package/CONTRIBUTING.md

@@ -21,7 +21,7 @@ Validate public links and the shared stage/template mapping with `npm run check:
 <a id="local-source-trial"></a>
 ## Local source trial without installation
 
-To try unreleased initialization changes, open a session with access to the checkout and a separate disposable materials directory. Explicitly ask to use the checkout's `skills/aimship/SKILL.md`, read its core, and run `node bin/aimship.mjs bind` from this package root. Verify the returned releaseRoot/corePath/cliPath all point into that checkout and schemaVersion is 3; a version string alone is insufficient when local code retains the published version. Then provide a concrete synthetic request, the trial materials path, and the desired stop. Do not load the installed launcher or run install.
+To try unreleased initialization changes, open a session with access to the checkout and a separate disposable materials directory. Explicitly ask to use the checkout's `skills/aimship/SKILL.md`, read its core, and run `node bin/aimship.mjs bind` from this package root. Verify the returned releaseRoot/corePath/cliPath all point into that checkout and schemaVersion is 4; a version string alone is insufficient when local code retains the published version. Then provide a concrete synthetic request, the trial materials path, and the desired stop. Do not load the installed launcher or run install.
 
 In the next session, explicitly request that same source Skill and bind again, then provide the original delivery directory and ask to resume. Check its saved deliveryId, revision, review status and next action. This exercises source rules and local tooling without replacing global entries. Whether a specific host automatically discovers a checkout Skill is separate and must be tested rather than promised. Check `test/initialization.test.mjs` for deterministic initialization, interruption and approval-bypass regressions; their synthetic decisions are not real AI-host evidence.
 
@@ -63,7 +63,7 @@ Inspect the JSON results: installation should activate the package version; the
 <a id="executable-examples"></a>
 ## Executable examples
 
-The harness records explicitly labeled synthetic self-checks and approvals, exercises review stops before automatic continuation, and preserves CHG/reapproval history. These are deterministic tool checks, not real user decisions or host E2E evidence.
+The harness records explicitly labeled synthetic self-checks and approvals, exercises review stops and explicitly requested continuation, and preserves CHG/reapproval history. These are deterministic tool checks, not real user decisions or host E2E evidence.
 
 From a source checkout, run:
 
@@ -74,7 +74,7 @@ node scripts/run-examples.mjs <new-output-directory>
 The output directory must not exist. The harness creates isolated code and delivery folders, exercises real functions with Node assertions, and saves readable documents, state and evidence. It does not install Aimship, touch user deliveries, access the network or publish anything. Do not use a real delivery as the output. The scripts are source-checkout tools, not installed user commands.
 
 - **Authored, single batch:** a line-normalization PRD, plan before implementation, one review covering batch/overall scope, and independent normal/empty/error assertions. Execution updates the same plan; cases and RUN results share the testing document.
-- **Adopted, multiple batches:** preserved catalog PRD/prototype inputs, Scope mappings, shared price validation and quoting with each batch reviewed. A discount change updates the testing document while keeping stable case IDs, records document reapproval and earlier review applicability, and binds exact code hashes. A known rounding fault fails overall review; the example asserts that starting verification is rejected without changing state. A separate maintainer probe preserves six real assertions (five pass, rounding fails) in `negative-probe.json`; it is not a formal verification stage or RUN. After fixing the code and recording a matching passing repair review, formal verification runs all six assertions successfully. Failed review and probe evidence remain available. Shared business rules, role restrictions and performance requirements have independent identities and acceptance.
+- **Adopted, multiple batches:** preserved catalog PRD/prototype inputs, an iteration PRD with source references, shared price validation and quoting with each batch reviewed. A discount change updates the testing document while keeping stable case IDs, records document reapproval and earlier review applicability, and binds exact code hashes. A known rounding fault fails overall review; the example asserts that starting verification is rejected without changing state. A separate maintainer probe preserves six real assertions (five pass, rounding fails) in `negative-probe.json`; it is not a formal verification stage or RUN. After fixing the code and recording a matching passing repair review, formal verification runs all six assertions successfully. Failed review and probe evidence remain available. Shared business rules, role restrictions and performance requirements have independent identities and acceptance.
 
 These examples check local document/state behavior. They do not establish automatic Skill discovery, real cross-host continuation, UI interaction or HTTP acceptance. Run output records assertions and limitations. Results from older schemas do not establish current behavior.
 

package/README.md

@@ -36,14 +36,14 @@ Choose `codex`, `cursor` or `claude-code`. To connect several tools, repeat the
 npx aimship@preview install --host codex --host claude-code
 ```
 
-The npx package prompt confirms downloading and running the package; `install` performs the Aimship installation or upgrade. `@preview` selects the published preview channel; an exact published version, such as `@0.1.0-preview.14`, can be used instead. The preview channel is experimental and does not imply a stable release.
+The npx package prompt confirms downloading and running the package; `install` performs the Aimship installation or upgrade. `@preview` selects the published preview channel; an exact published version, such as `@0.1.0-preview.16`, can be used instead. The preview channel is experimental and does not imply a stable release.
 
 ### A specific version or local package
 
 To install an exact published version, for example:
 
 ```sh
-npx aimship@0.1.0-preview.14 install --host codex
+npx aimship@0.1.0-preview.16 install --host codex
 ```
 
 If you already have an Aimship `.tgz` package, replace `VERSION` with its actual version and run from the directory containing it:
@@ -82,7 +82,7 @@ npx aimship@preview install
 
 After upgrading, we recommend restarting your AI tool and opening a new session, then activating Aimship to reload the updated rules. Existing sessions may still retain older rules.
 
-Installation and upgrades use the same `install` command. Existing tool registrations, configuration, custom content and deliveries are retained. The installer reports previous/target versions, results and conflicts; no background updater or resident process runs. To upgrade to a specific version, for example, run `npx aimship@0.1.0-preview.14 install`. Existing installations do not need `--host` or `--data-root` repeated.
+Installation and upgrades use the same `install` command. Existing tool registrations, configuration, custom content and deliveries are retained. The installer reports previous/target versions, results and conflicts; no background updater or resident process runs. To upgrade to a specific version, for example, run `npx aimship@0.1.0-preview.16 install`. Existing installations do not need `--host` or `--data-root` repeated.
 
 <a id="add-a-host"></a>
 <a id="add-an-ai-development-tool"></a>

package/README.zh-CN.md

@@ -36,14 +36,14 @@ AI 工具可选 `codex`、`cursor` 或 `claude-code`。连接多个 AI 工具时
 npx aimship@preview install --host codex --host claude-code
 ```
 
-npx 的获取包提示只确认下载并运行该包；执行 `install` 才会安装或升级 Aimship。`@preview` 表示已发布的预览通道，也可以替换为明确版本号，例如 `@0.1.0-preview.14`。预览通道用于实验性版本，不代表稳定版。
+npx 的获取包提示只确认下载并运行该包；执行 `install` 才会安装或升级 Aimship。`@preview` 表示已发布的预览通道，也可以替换为明确版本号，例如 `@0.1.0-preview.16`。预览通道用于实验性版本，不代表稳定版。
 
 ### 指定版本或本地包
 
 安装指定的已发布版本，例如：
 
 ```sh
-npx aimship@0.1.0-preview.14 install --host codex
+npx aimship@0.1.0-preview.16 install --host codex
 ```
 
 如果已有 Aimship 的 `.tgz` 安装包，将 `VERSION` 替换为实际版本号，在包所在目录执行：
@@ -82,7 +82,7 @@ npx aimship@preview install
 
 升级完成后，建议重启 AI 工具并新建会话，再启用 Aimship，以便重新加载更新后的规则。已有会话可能仍保留旧规则。
 
-安装和升级使用同一个 `install` 命令。已有 AI 工具登记、配置、自定义内容和交付资料都会保留。安装器报告旧／目标版本、结果及冲突；没有后台自动升级或常驻进程。更新到指定版本时，例如运行 `npx aimship@0.1.0-preview.14 install`。已有安装无需重复填写 `--host` 或 `--data-root`。
+安装和升级使用同一个 `install` 命令。已有 AI 工具登记、配置、自定义内容和交付资料都会保留。安装器报告旧／目标版本、结果及冲突；没有后台自动升级或常驻进程。更新到指定版本时，例如运行 `npx aimship@0.1.0-preview.16 install`。已有安装无需重复填写 `--host` 或 `--data-root`。
 
 <a id="添加宿主"></a>
 <a id="添加-ai-开发工具"></a>

package/docs/cli.md

@@ -32,9 +32,9 @@ node '<fixed-cli>' init '<delivery-dir>' --rules-version '<bound-version>' --inp
 
 init uses schema 4, allocates deliveryId and revision 0, creates `.aimship/state.json`, and generates `status.md`. Add that ID to the document information at the next save point. Identity/version/timestamps, documentDigests are managed; never supply them in a patch. `writeResult` is return metadata, not state input. Its receipt contains actual identity, directory/state/status paths, bound version, current stage and next action; statusPath is null when view repair is needed. Verify the saved files before presenting the user receipt. Repeated init returns ALREADY_EXISTS; read/resume the same delivery and render a missing view instead of replaying creation.
 
-`documentPolicy.authority`: null while the requirement authority is undecided; authored → prd.md; adopted → scope.md; editable → an explicitly authorized existing PRD containing this commission's complete scope/authorization/endpoint. `interaction`, `prototypeCovered`, `interface` (none/http/other) and target `databases` IDs record artifact conditions. They do not select a preset route. Register the first real PRD/Scope and switch goalRef in the same update; this reference-only transition does not need a fabricated goal decision. Actual goal/endpoint changes still require goal.decisionRef. Early frame/requirements/scope work can be active without the draft; done requires it. Design requires approved requirements and an agreed endpoint, but may analyze unknown technical conditions. Resolve those conditions before completing design or starting dependent contract/cases/plan/implementation. Required document approvals remain checked even when producer runs are absent; existing stage ordering and review semantics are unchanged.
+`documentPolicy.authority`: null while the requirement authority is undecided; authored → prd.md; adopted → the registered retained PRD file in source/ (mode input); editable → an explicitly authorized existing PRD. All three use kind prd and goalRef points to its actual path. `interaction`, `prototypeCovered`, `interface` (none/http/other) and target `databases` IDs record artifact conditions. They do not select a preset route. Prototype coverage is descriptive; a prototype is optional unless selected in stageRuns, in which case its completion and applicable input check or AI-output approval remain required. Register the first real PRD and switch goalRef in the same update; this reference-only transition does not need a fabricated goal decision. Actual goal/endpoint changes still require goal.decisionRef. Early frame/requirements work can be active without the draft; done requires it. Design requires adopted, checked input requirements or approved AI-authored requirements and an agreed endpoint, but may analyze unknown technical conditions. Resolve those conditions before completing design or starting dependent contract/cases/plan/implementation. Required document approvals remain checked even when producer runs are absent; existing stage ordering and review semantics are unchanged.
 
-Register documents as `{kind,path,mode,version,assetRefs?}`. List local/repository prototype images, scripts and other review-relevant assets in assetRefs so their bytes participate in the document fingerprint; the Agent must identify the complete asset set. Kinds: prd, scope, tech-design, plan, testing, review, diagnosis, handoff, change-log, prototype, contract, sql, source. New formal Markdown follows the artifact map's root filename and ordered ordinary Markdown headings. Reused files additionally need `basisRef` recording location/version/coverage/gaps and editability; unsupported content is explicitly not checked. New HTML prototype is prototype/index.html; register other agreed formats. HTTP contracts use openapi.yaml unless reused. SQL filenames follow database count. Source files are immutable adopted versions by workflow, not OS access controls.
+Register documents as `{kind,path,mode,version,assetRefs?}`. List local/repository prototype images, scripts and other review-relevant assets in assetRefs so their bytes participate in the document fingerprint; the Agent must identify the complete asset set. Kinds: prd, tech-design, plan, testing, review, diagnosis, handoff, change-log, prototype, contract, sql, source. New formal Markdown follows the artifact map's root filename and ordered ordinary Markdown headings. Modes: new for AI-authored files, reused for existing reviewable outputs, input for unchanged supplied PRD/prototype. Input basisRef preserves the actual user request to deliver from that material; mere file existence is insufficient. Inputs need a current self-check and become adopted, without an approved record. An unresolved question uses next.questionRef pointing to an existing concrete question/options/impact; the current run stays blocked. Clear it with null after resolving the question. No new approval is recorded for that clarification. Reused files additionally need `basisRef` recording location/version/coverage/gaps and editability; unsupported content is explicitly not checked. New HTML prototype is prototype/index.html; register other agreed formats. HTTP contracts use openapi.yaml unless reused. SQL filenames follow database count. Source files are immutable adopted versions by workflow, not OS access controls.
 
 ## Update and inspect
 
@@ -51,7 +51,7 @@ Stage runs are ordered `{id,stage,scope,progress,inputRefs,outputRefs}`. current
 
 New Markdown uses the ordinary headings in the artifact map and searchable business IDs. Checks reject missing or duplicate definitions and unresolved ID references. Results use section keys or unique record IDs as search locators; no HTML anchors, embedded definition metadata, item versions or hidden traceability index are required. These structural checks do not establish semantic completeness.
 
-Bare IDs resolve against current local definitions, including readable IDs in an explicitly registered editable Markdown requirement authority. File-qualified Markdown record citations check the actual source file and a unique substantive record; missing, duplicate or unreadable sources fail. Reused documents retain their outline and separately reported unchecked content. B/TASK/TC definitions belong in batch/task/case design sections; execution sections may cite those IDs without defining new obligations. Delivery `language` is required for all current states.
+Bare IDs resolve against current local definitions, including readable IDs in an explicitly registered reused Markdown requirement authority. File-qualified Markdown record citations check the actual source file and a unique substantive record; missing, duplicate or unreadable sources fail. Reused documents retain their outline and separately reported unchecked content. B/TASK/TC definitions belong in batch/task/case design sections; execution sections may cite those IDs without defining new obligations. Delivery `language` is required for all current states.
 
 References stay delivery-root-relative despite state being internal, or use `repo:<id>/<path>` / HTTP(S). Repository records `{id,path,role}` name actual absolute checkout/worktree roots. A branch is not a code version. Paths cannot escape roots through traversal or symlinks. check defaults to current inputs; --all adds registered history/decisions/outcomes. Exact fragments in registered new Markdown are checked; reused/remote/unsupported ones return not-checked. That does not establish semantics or passing verification.
 
@@ -87,27 +87,31 @@ Each record has `{id, kind, document, version, digest, sourceRef, summary}`. Kin
 
 `read`, `check`, and `resume` return `review.documents` with current `path`, `version`, `digest`, `selfCheck`, `approval` and status. First append a self-check of those exact bytes; after presenting the document and receiving explicit approval, append an approved record binding the same version/digest and the actual user message. Questions, silence, and “show the result” cannot be recorded as approval. A hash/source reference validates the record's content basis, **not user identity or authenticity**. Never synthesize a real approval to make an update pass.
 
-Production `progress: done` may be saved while approval is pending. Starting/completing dependent runs is blocked until prerequisite completion and document approval are current. Runs default to depending on their predecessor; explicit `dependsOn: [preceding-run-ids]` supports recorded independent branches, while input/output producers and earlier selected development prerequisites also apply. The initial applicable development order is requirements/Scope, technical design, interface/SQL, test-design, plan, implement. Unselected stages are not created. Contract can produce only SQL when no interface change applies; technical design no longer requires SQL files before completion.
+Production `progress: done` may be saved while approval is pending. Starting/completing dependent runs is blocked until prerequisite completion and document approval are current. Runs default to depending on their predecessor; explicit `dependsOn: [preceding-run-ids]` supports recorded independent branches, while input/output producers and earlier selected development prerequisites also apply. The initial applicable development order is requirements, technical design, interface/SQL, test-design, plan, implement. Unselected stages are not created. Contract can produce only SQL when no interface change applies; technical design no longer requires SQL files before completion.
 
 For new `plan.md` and `testing.md`, fingerprints cover the content before the ordinary headings mapped to `execution` and `runs` respectively. Append implementation and RUN/conclusion evidence after those boundaries. Reused formats and other documents use whole-file content; remote/binary or linked-asset semantic inspection still belongs to the host/Agent. `done`, matching hashes and structural checks do not prove semantic quality.
 
+When the PRD authority path changes, retain the prior registered file as kind source (mode reused), register one current prd, and preserve the old result reference in the requirement run. Use the real goal decision and an open CHG for a change to approved requirements or adopted inputs; affected input checks and AI-output reviews must be reassessed before dependent work continues. This changes current material, not historical approval records.
+
 A material change needs an open CHG with impact/decision evidence, a revised document version, a new self-check and explicit reapproval. Old review records remain. Affected producer/dependent runs become `needs-review`; update currentRun/next to the re-review stop and restore applicability after evidence-backed rechecking in dependency order. Independent branches are preserved. An `editorial` record carries a prior approval only after a same-version self-check explains a formatting/typo change and references its previous digest; it is not a new user approval. Do not hide changed design in excluded result sections. Final `outcome.acceptance` stays independent.
 
-See the [Agent review workflow](../skills/aimship/references/document-review.md) for presentation, automatic continuation after approval and compatibility responsibilities.
+See the [Agent review workflow](../skills/aimship/references/document-review.md) for presentation, stage stops and approval responsibilities.
 
 ## Standard completeness and session suggestions
 
-New state defaults to `deliveryPolicy: {version: 1}`. The standard main sequence is requirements/acceptance, technical and applicable contract/interaction artifacts, cases, plan, implementation with batch review, overall review, verification, handoff/acceptance. Do not present stageRuns as an arbitrary menu of core stages. Preserve existing materials and inspect them before adoption; reuse does not imply approval.
+New state defaults to `deliveryPolicy: {version: 1}`. The standard main sequence is requirements/acceptance, technical and applicable contract/interaction artifacts, cases, plan, implementation with batch review, overall review, verification, handoff/acceptance. Do not present stageRuns as an arbitrary menu of core stages. Preserve existing materials and inspect them before adoption. Mode input records supplied PRD/prototype with actual adoption intent and a current self-check; it is not an approved AI output.
 
-An explicit limited-scope decision (including no cases and testing) is referenced by `deliveryPolicy.partialRef` in existing PRD/Scope/change material. Such a scope may reach `outcome.goal: met` and have a real acceptance decision, but derived `completion.status` remains `partial-scope`, never `standard-complete`. Adding/changing/removing this basis needs a new goal.decisionRef, preserving goal history; set partialRef to null to restore standard scope. Standard goal completion checks recorded stages/approvals, passing batch and overall review, passing independent verification, handoff and resolvable evidence; standard-complete additionally requires recorded acceptance. These checks cannot prove actual execution or semantic quality. Failed or omitted checks must never be labeled passed.
+An explicit limited-scope decision (including no cases and testing) is referenced by `deliveryPolicy.partialRef` in existing PRD/change material. Such a scope may reach `outcome.goal: met` and have a real acceptance decision, but derived `completion.status` remains `partial-scope`, never `standard-complete`. Adding/changing/removing this basis needs a new goal.decisionRef, preserving goal history; set partialRef to null to restore standard scope. Standard goal completion checks recorded stages/approvals, passing batch and overall review, passing independent verification, handoff and resolvable evidence; standard-complete additionally requires recorded acceptance. These checks cannot prove actual execution or semantic quality. Failed or omitted checks must never be labeled passed.
 
 Independent review, verify-only work or limited handoff can omit standard upstream work only with a nonempty readable local partialRef (including a resolvable ordinary heading or record if supplied). The tool checks the evidence reference, not whether a user actually authorized its contents. Declared dependencies and applicable document approvals remain in force. Planned future work and draft materials may be saved before entry conditions are met; active/done transitions are checked. Existing records remain readable and report unresolved entry conditions rather than automatically acquiring a scope exception.
 
 Reviews identify their actual implementation coverage with `reviewOf: [implementationRunId, ...]`; overall review has `overall: true`. For a single batch one review may explicitly cover both. An unresolved failed review prevents standard completion even if an earlier overall review passed. A passing repair review or retest may list the superseded review/RUN result references in its existing `historyResultRefs`, preserving old failures; the Agent must verify that it actually resolves or covers them on current objects. Verification must follow the applicable overall review. Merely setting a link is not semantic evidence.
 
-`run.sessionGroup` is an advisory group ID persisted when a new policy-enabled run is saved: requirements; technical/contract/prototype; cases; plan; each implementation batch with its batch review; overall review; each verify batch. Adjusting groups does not change document approval, add a stage, or block work. `read/check/resume` expose `session.action`, groups and a concise continuation entry; pending review and unconfirmed saves do not return a next-stage entry. `writeResult.session` becomes reconcile-save with no entry if view saving fails, even when stateSaved is true. Repair at the returned revision; do not repeat the approval update. At a confirmed saved group boundary, the Agent suggests a new session without executing the next group in that response. A user request to continue here proceeds with the normal authorized update.
+`run.sessionGroup` remains advisory context, not permission to cross stages. Each stage finishes its work/self-check, saves artifacts and stops: `session.action` is await-review for required approval or await-continue for a completed stage awaiting continuation; `stop` and `suggestNewSession` make that advice explicit. A new session is recommended, not mandatory. Approval and continuation may be expressed together. This is agent interaction guidance, not interception of general-purpose tools or a new approval for non-review stages. `read/check/resume` and `writeResult.session` use the same rule. Unconfirmed saves return reconcile-save with no continuation; repair the view at the saved revision without replaying approval. Pending review never becomes approval through resume or “continue”.
 
 `read` and `resume` accept optional `--delivery-id <known-id>` to reject a wrong directory binding. A directory remains required; no implicit latest-delivery lookup exists. Resume is read-only and inspects actual state, approval/content versions, references and view diagnostics; old prompts grant no approval. The Agent must additionally inspect relevant complete formal documents, actual artifacts and unfinished effects before acting.
 
 
 Review run `ready` describes a completed, current record; `releaseReady` additionally requires a usable passing review before releasing dependent work. Failed review records remain saved. A later passing repair review must preserve the old result reference and cover the affected implementation scope; unrelated passing reviews do not clear the failure. Session suggestions distinguish exhausting registered work from completing the agreed goal: an unfinished goal with no next run requires arranging the next authorized work, not declaring finished.
+
+The generated status page prioritizes current work, self-check and approval, user action, actual directory and continuation stop. Future standard stages are not started, not current defects; unknown contract applicability remains pending design. Final completion diagnostics remain enforced and are shown at handoff. Engineering details and generation metadata follow the user summary.

package/docs/guide.md

@@ -59,7 +59,7 @@ The delivery directory contains these materials:
     └── handoff.md                 # Results and handoff instructions
 ```
 
-Materials develop gradually and are kept as needed. Search readable REQ, AC and TC numbers across documents; corresponding numbers stay consistent without requiring anchor links. `scope.md` adopts authoritative external requirements, `change-log.md` records important changes, and `diagnosis.md` is for standalone investigations. Open `status.md` for progress; tell the AI directly about requirement changes or acceptance decisions.
+Materials develop gradually and are kept as needed. Search readable REQ, AC and TC numbers across documents; corresponding numbers stay consistent without requiring anchor links. A complete applicable PRD is adopted directly; partial adoption produces this iteration’s `prd.md`. `change-log.md` records important changes, and `diagnosis.md` is for standalone investigations. Open `status.md` for progress; tell the AI directly about requirement changes or acceptance decisions.
 
 <a id="1-start-and-proceed"></a>
 <a id="start"></a>
@@ -76,7 +76,7 @@ Materials develop gradually and are kept as needed. Search readable REQ, AC and
 
 Follow sign-up and login from requirements to acceptance. **This is fictional practice; wording and business choices need not be copied.** The example later supplies a project and isolated test database, with prototype review after requirements and before technical design. Actual prototype placement follows the delivery's needs.
 
-Use one Aimship entry within a session, then continue after approval as arranged; no invocation is needed at every stage. When your review is required, the AI presents one item at a time and waits for a clear decision. Revisions return for review.
+Use one Aimship entry within a session; no invocation is needed at every stage. After completing and self-checking a stage, the AI saves its results, reports the stop and pauses. A new session is recommended, not required. AI-authored or substantively revised reviewable documents await approval; concrete unresolved questions await clarification; other completed stages await continuation. You may say “approved, continue” once. Work within a stage stays continuous.
 
 <a id="11-prepare-a-workspace"></a>
 <a id="12-activate-aimship-and-describe-the-request"></a>
@@ -98,9 +98,9 @@ Use one Aimship entry within a session, then continue after approval as arranged
 
 > Use Aimship for username/password sign-up, login, logout and a home page requiring login. Complete development and local verification, without deployment; I will supply code later.
 
-For existing prototypes, PRDs or other documents, supply their original locations; originals stay in place and you need not copy them manually. Following the source rules, the AI retains copies of the formally adopted versions and necessary dependencies under this delivery's `source/` and records the adoption basis. Materials consulted only as background need not be copied in full. Before later revisions, identify the editable artifact; new versions do not overwrite earlier evidence.
+For existing prototypes, PRDs or other documents, supply their original locations; originals stay in place and you need not copy them manually. Following the source rules, the AI retains copies of the formally adopted versions and necessary dependencies under this delivery's `source/` and records the adoption basis in the existing source record. Materials consulted only as background need not be copied in full. Before later revisions, identify the editable artifact; new versions do not overwrite earlier evidence.
 
-**AI processing:** Determines the delivery directory and checks access, preserves the request, creates or resumes the delivery, and reports the actual saved directory, current work and next action. If access is unavailable, it asks you to add that directory or grant access; it does not relocate the delivery into the workspace.
+**AI processing:** Determines the delivery directory and checks access, preserves the request, creates or resumes the delivery, and reports the actual saved directory, current work and next action. It starts requirement intake on the standard sequence without a full-delivery/design-only/init-only choice; explicit limits or pauses are respected. If access is unavailable, it asks you to add that directory or grant access; it does not relocate the delivery into the workspace.
 
 **Outputs:** `source/request.md` preserves your words; `status.md` shows progress. For a new delivery, the AI saves your preferred language, or otherwise the language of the current conversation. Status and new documents use that language; filenames, IDs, original sources and existing documents remain unchanged.
 
@@ -124,11 +124,11 @@ For existing prototypes, PRDs or other documents, supply their original location
 - No PRD/prototype: describe features and expected behavior, such as “Usernames must be unique; after logout, the home page must require login again.”
 - Existing materials: provide the PRD/prototype location, version and adopted scope. Say what is available even if it is incomplete.
 
-Open the presented requirements document and applicable prototype separately. Check scope, acceptance criteria and page behavior; approve the current item or identify what needs changing.
+When you provide a complete applicable PRD/prototype and ask to deliver from it, the AI adopts it unchanged without asking you to review the source again. Source copies and management records do not require individual review. Clarification is needed only for specific questions affecting progress. Review requirements or prototypes the AI writes, narrows or substantively changes: check scope, acceptance criteria and page behavior, then approve or give feedback. Valid approval of the current output content is reused.
 
-**AI processing:** Clarifies gaps, preserves authoritative external originals and reuses sufficient prototype coverage. Without materials, it writes requirements first, then creates the needed prototype after approval in this example's arrangement. No interaction change means no new prototype. It self-checks, submits, records approval and continues one item at a time.
+**AI processing:** Adopts a complete applicable PRD without rewriting or renumbering. For partial adoption, it writes this iteration’s PRD with sources, inclusions, exclusions and acceptance, retaining source IDs where possible. Without a PRD, discussion produces one. Prototypes are optional; adequate existing ones are reused. It self-checks, confirms and saves each selected document, preserving originals.
 
-**Outputs:** `prd.md` states requirements and acceptance criteria, or `scope.md` records the adopted scope. This example creates `prototype/index.html` for pages and feedback states. A prototype is not implemented authentication; interaction checks not performed remain unverified.
+**Outputs:** The newly authored `prd.md` or retained PRD in `source/` is the requirement authority, without a separate Scope. This example selects `prototype/index.html` for pages and feedback states. A prototype is not implemented authentication; interaction checks not performed remain unverified.
 
 <a id="guide-session-example"></a>
 
@@ -187,9 +187,9 @@ The AI rechecks access to the same delivery directory, reads its state and confi
 
 ### 1.7 Implement batches and review each batch
 
-**User actions:** Inspect changes and progress; point out deviations, such as “The post-sign-up redirect differs from the prototype.” No line-by-line approval of execution logs is needed.
+**User actions:** Inspect changes and progress; point out deviations, such as “The post-sign-up redirect differs from the prototype.” No line-by-line approval of execution logs is needed; inspect the saved stage result and ask to continue.
 
-**AI processing:** Implements the plan, reviews each batch and resolves blocking issues before the next. After all batches, it performs the overall review before verification. Requirement changes return to the relevant review.
+**AI processing:** Implements the plan and reviews each batch, saving and stopping after implementation and after review. Continuation advances only after blocking issues are resolved. All batches are followed by overall review, then verification. Requirement changes return to the relevant review.
 
 **Outputs:** Project code, execution progress appended to `plan.md`, and batch findings and repairs in `review.md`.
 
@@ -198,9 +198,9 @@ The AI rechecks access to the same delivery directory, reads its state and confi
 
 ### 1.8 Review the complete change
 
-**User actions:** Read the overall findings and remaining issues, pointing out omissions if needed. Each review entry does not need a separate document approval.
+**User actions:** Read the overall findings and remaining issues, pointing out omissions if needed. Review records do not need a separate document approval; inspect the conclusion and ask to continue.
 
-**AI processing:** Checks all actual changes and connections across sign-up, login, logout and home-page access. It resolves issues blocking independent verification. A single-batch review can explicitly cover both batch and overall scope.
+**AI processing:** Checks all actual changes and connections across sign-up, login, logout and home-page access. It resolves issues blocking independent verification, saves the conclusion and stops before continuing to verification. A single-batch review can explicitly cover both batch and overall scope.
 
 **Outputs:** Overall conclusions appended to `review.md`. Code review does not replace running tests.
 
@@ -254,7 +254,7 @@ The AI rechecks access to the same delivery directory, reads its state and confi
 
 ### 2.1 When to switch sessions
 
-Follow suggestions in `status.md` between requirements, technical design/applicable contracts, cases, plan, implementation batches, overall review and verification batches, or stay in the same session. Grouping does not change individual document reviews.
+At each completed stage, follow the stop in `status.md`: approve or give feedback on pending documents, or ask to continue completed work. A new session is recommended but optional; “continue” does not approve a pending document. The page prioritizes current actions and shows future stages as not started, not current defects.
 
 See the [new-session example](#guide-session-example). Keep one writing session per delivery. Trusted records can locate it directly; missing or ambiguous matches prompt clarification. The saved delivery language carries over. If switching before the first save, carry the unsaved request, intended location and pending operations.
 
@@ -289,7 +289,7 @@ Manual progress-page edits are preserved first; conflicts need coordination. Do
 
 ### 3.1 Existing materials or discussion
 
-Provide the PRD, prototype or screenshot locations, versions and scope to use. The AI checks them as described in [Confirm requirements](#guide-requirements). Explicitly request direct maintenance of an existing PRD if needed; the AI checks the goal and endpoint before submitting it for review. An existing file is not an approval.
+Provide the PRD, prototype or screenshot locations, versions and scope to use. The AI checks them as described in [Confirm requirements](#guide-requirements). A complete applicable PRD is adopted directly; partial adoption produces an iteration PRD without changing the original. Explicitly request edits to the original if needed. File presence alone does not establish intent to use it. A clear request to deliver from unchanged supplied material establishes adoption, without a repeated source review; review AI-written changes instead.
 
 For prior discussion, say “Use Aimship to continue the requirements we just discussed.” The AI organizes visible requests, decisions and open questions. Supply history it cannot see; suggestions are not approvals.
 
@@ -304,7 +304,7 @@ For prior discussion, say “Use Aimship to continue the requirements we just di
 
 ### 3.2 Change approved content
 
-Explain what changes, why, and what stays the same; identify any documents you edited yourself. The AI records important changes in `change-log.md`, resubmits affected documents and holds dependent work until confirmed. Unaffected work, earlier approvals and test history remain.
+Explain what changes, why, and what stays the same; identify any documents you edited yourself. The AI records important changes in `change-log.md`. Newly supplied unchanged inputs are checked and adopted; affected AI outputs are resubmitted for review before dependent work continues. Unaffected work, earlier approvals and test history remain.
 
 Record new requests in requirements and the change log, without overwriting `source/request.md`. Restore accidental edits from a reliable original; if none exists, pause to resolve the gap. Typos and formatting need no full re-review. Small fixes can continue the same delivery; a new goal or major redesign gets a separate delivery linked to the original.
 
@@ -347,6 +347,8 @@ For defects, provide expected behavior, the problem and reproduction steps or lo
 
 Keep each delivery separate and identify shared code, interfaces, databases or environments. Analysis can run concurrently; sequence edits to the same code, or use separate working directories and plan the merge.
 
+Pre-existing edits from other requests are not added to this requirement or cleaned merely because the working tree is dirty. Engineering baselines stay in engineering records, not the business PRD.
+
 The AI checks only known, accessible deliveries; it does not lock or schedule other sessions. Describe other ongoing changes and check the merged result afterward.
 
 <a id="4-problems-and-references"></a>

package/docs/guide.zh-CN.md

@@ -59,7 +59,7 @@ AI 工具项目空间
     └── handoff.md                 # 成果与交接说明
 ```
 
-这些材料逐步形成，按需保留。正文中的 REQ、AC、TC 等编号可直接搜索，跨文档沿用对应编号，不要求锚点跳转。外部权威需求由 `scope.md` 承接，重要变更记入 `change-log.md`，独立调查才使用 `diagnosis.md`。查看进度先打开 `status.md`；需求修改或验收意见直接告诉 AI。
+这些材料逐步形成，按需保留。正文中的 REQ、AC、TC 等编号可直接搜索，跨文档沿用对应编号，不要求锚点跳转。完整适用的已有 PRD 直接采用，部分采用时编写本次 `prd.md`，重要变更记入 `change-log.md`，独立调查才使用 `diagnosis.md`。查看进度先打开 `status.md`；需求修改或验收意见直接告诉 AI。
 
 <a id="1-开始与推进"></a>
 <a id="start"></a>
@@ -76,7 +76,7 @@ AI 工具项目空间
 
 以登录注册功能演示从需求到验收。**这是虚构实践参考，措辞和业务方案无需照抄。** 本例稍后提供工程和隔离测试数据库，约定需求后确认原型，再做技术设计；实际原型安排按交付需要确定。
 
-同一会话沿用一个 Aimship 入口，批准后按安排继续，无需逐阶段调用。需要你审核时，AI 会逐份展示材料并等待明确结论；修改后重新送审。
+同一会话沿用一个 Aimship 入口，无需逐阶段调用。每阶段完成并自检后，AI 保存成果、说明停点并停下，建议新会话，也可原会话继续。AI 新产出或实质修改的需审文档等待批准，具体疑问等待确认，其他已完成阶段等待继续；可以一次说“通过并继续”。阶段内部不逐小步暂停。
 
 <a id="11-准备工作位置"></a>
 <a id="12-启用-aimship-并说明需求"></a>
@@ -98,9 +98,9 @@ AI 工具项目空间
 
 > 使用 Aimship，做用户名密码注册、登录、退出和登录后首页。完成开发与本地验证，不部署；代码稍后提供。
 
-已有原型、PRD 或其他文档时，提供原位置即可，原件保留，用户无需手动复制。AI 按来源规则将正式采用的版本及必要依赖资源留存为本次交付 `source/` 中的副本，并记录采用依据；仅作背景参考的材料无需全量复制。后续修改先明确编辑对象，新版不覆盖旧依据。
+已有原型、PRD 或其他文档时，提供原位置即可，原件保留，用户无需手动复制。AI 按来源规则将正式采用的版本及必要依赖资源留存为本次交付 `source/` 中的副本，并在已有来源记录中注明采用依据；仅作背景参考的材料无需全量复制。后续修改先明确编辑对象，新版不覆盖旧依据。
 
-**AI 处理**：确定交付目录并核对访问，保留诉求，建立或续接交付，告知实际保存目录、当前工作和下一步。若无法访问，提示你添加该原目录或授权；不会改存到项目空间。
+**AI 处理**：确定交付目录并核对访问，保留诉求，建立或续接交付，告知实际保存目录、当前工作和下一步；默认按主流程承接需求，不先让你选择完整交付、仅设计或仅初始化。你主动要求暂停或限定范围时按要求处理。若无法访问，提示你添加该原目录或授权；不会改存到项目空间。
 
 **输出产物**：`source/request.md` 保存原话；`status.md` 显示进度。新建交付时，AI 优先按明确偏好，否则按当前交流语言保存本次交付语言；状态和新文档沿用，文件名、编号、来源原文及已有文档不变。
 
@@ -124,11 +124,11 @@ AI 工具项目空间
 - 没有 PRD／原型：说明功能和预期行为，如“用户名不能重复，退出后再进首页必须登录”。
 - 已有材料：给出 PRD／原型的位置、版本和本次采用范围；只有部分材料也直接说明。
 
-分别打开送审的需求文档和适用原型，核对范围、验收标准及页面行为。每次对当前一份明确通过，或指出要修改的内容。
+你明确提供完整适用的 PRD／原型并要求据此交付时，AI 原样接纳，不要求重审原文；来源副本和管理记录也不逐份送审。只有存在影响推进的具体疑问才请你确认。需要你审核的是 AI 新写、裁剪或实质修改的需求与原型：查看范围、验收标准和页面行为，明确通过或反馈。已有当前内容的有效批准直接沿用。
 
-**AI 处理**：澄清缺口；外部权威原件保留，覆盖充分的原型复用。无材料时先写需求，批准后按本例安排制作所需原型；无交互变化则不新增。逐份自检、送审，批准后保存再继续。
+**AI 处理**：完整适用的 PRD 直接采用，不重写或重新编号；仅采用部分时编写本次 PRD，写清来源、纳入、排除及验收，尽量沿用原编号；没有 PRD 时讨论后生成。原型可选，已有原型充分则复用。逐份自检、确认并保存，原件保留。
 
-**输出产物**：`prd.md` 说明需求与验收标准，或 `scope.md` 记录外部材料的采用范围；本例新建 `prototype/index.html` 展示页面与反馈状态。原型不代表认证已实现，未实际检查的交互仍标明未验证。
+**输出产物**：新写的 `prd.md` 或 `source/` 中正式采用的已有 PRD 作为需求依据，不另建 Scope。本例选择新建 `prototype/index.html` 展示页面与反馈状态。原型不代表认证已实现，未实际检查的交互仍标明未验证。
 
 <a id="guide-session-example"></a>
 
@@ -187,9 +187,9 @@ AI 重新核对同一交付目录的访问，读取状态并确认下一步技
 
 ### 1.7 分批实施与批内 review
 
-**用户操作**：查看改动和进度，有偏离及时指出，如“注册成功后的跳转与原型不一致”。无需逐条批准执行日志。
+**用户操作**：查看改动和进度，有偏离及时指出，如“注册成功后的跳转与原型不一致”。无需逐条批准执行日志；阶段结束查看结果后可要求继续。
 
-**AI 处理**：按计划写代码，每批完成后审查并处理阻碍推进的问题，再进入下一批。全部批次完成后做整体审查，再统一验证；需求变化回到相应审核。
+**AI 处理**：按计划写代码，每批实施、批内审查分别完成后保存并停下，收到继续指令再推进；存在阻碍时先修复。全部批次完成后安排整体审查，再统一验证；需求变化回到相应审核。
 
 **输出产物**：工程代码；`plan.md` 追加执行进度，`review.md` 记录本批问题与修复。
 
@@ -198,9 +198,9 @@ AI 重新核对同一交付目录的访问，读取状态并确认下一步技
 
 ### 1.8 整体 review
 
-**用户操作**：查看整体结论和遗留问题，必要时指出遗漏；不需要为每条审查记录另做文档批准。
+**用户操作**：查看整体结论和遗留问题，必要时指出遗漏；不需要为审查记录另做文档批准，查看结论后可要求继续。
 
-**AI 处理**：检查全部实际改动及注册、登录、退出、首页访问的跨批衔接，处理阻碍验证的问题后进入独立验证。单批可用一份 review 明确覆盖批内及整体范围。
+**AI 处理**：检查全部实际改动及注册、登录、退出、首页访问的跨批衔接，处理阻碍验证的问题后保存结论并停下，收到继续指令再进入独立验证。单批可用一份 review 明确覆盖批内及整体范围。
 
 **输出产物**：`review.md` 追加整体审查结论。代码审查不能代替运行测试。
 
@@ -254,7 +254,7 @@ AI 重新核对同一交付目录的访问，读取状态并确认下一步技
 
 ### 2.1 何时换会话
 
-按 `status.md` 的建议在需求、技术与适用契约、用例、计划、实施批次、整体 review、验证批次之间换会话，也可继续当前会话；分组不改变逐份审核。
+每阶段完成后按 `status.md` 的停点处理：AI 产出待审则批准或反馈，有具体疑问则回答问题，已完成则要求继续。建议此时换会话，也可继续当前会话；“继续”不替代待审材料的批准。进度页先展示当前操作，尚未开始的后续阶段不会当作当前缺项。
 
 新会话操作见[演示中的续接示例](#guide-session-example)。同一交付只保留一个写入会话；可信记录可直接定位，找不到或有多个候选才询问。交付语言沿用已保存设置。首次保存前就要切换时，携带未保存诉求、计划位置及未完成操作。
 
@@ -289,7 +289,7 @@ AI 重新核对同一交付目录的访问，读取状态并确认下一步技
 
 ### 3.1 已有资料或讨论
 
-提供 PRD、原型或截图的位置、版本和本次使用范围，AI 按[确认需求](#guide-requirements)核对。若要直接维护已有 PRD，请明确说明；AI 核对本次目标和完成范围后送审，已有文件不等于已批准。
+提供 PRD、原型或截图的位置、版本和本次使用范围，AI 按[确认需求](#guide-requirements)核对。完整适用的 PRD 直接采用；部分采用形成迭代 PRD，原件不改。若要修改原件，请明确说明。文件存在本身不等于采用意图。你明确要求据此交付时，原样材料作为输入接纳，无需重复审核；AI 新写或实质修改的文档再正常送审。
 
 已有讨论可说：“使用 Aimship 继续刚才讨论的需求。”AI 整理可见的诉求、决定和待确认问题；看不到的历史请补充，建议不算批准。
 
@@ -304,7 +304,7 @@ AI 重新核对同一交付目录的访问，读取状态并确认下一步技
 
 ### 3.2 修改已批准内容
 
-说明改什么、为什么改、哪些保持不变；自行改过文档时指出文件。AI 在 `change-log.md` 记录重要变化，将受影响文档重新送审，相关工作待确认后继续。未受影响的工作、旧批准和测试历史保留。
+说明改什么、为什么改、哪些保持不变；自行改过文档时指出文件。AI 在 `change-log.md` 记录重要变化。新提供的原样材料重新核对并记录采用；受影响的 AI 产出重新送审，相关工作审核通过后继续。未受影响的工作、旧批准和测试历史保留。
 
 新诉求写入需求文档和变更记录，不覆盖 `source/request.md`。原始诉求被误改时，从可靠原件恢复；找不到就暂停核对。错字或排版无需全部重审。交付后的小修可继续原交付；新目标或大幅重设计另建交付，并注明与原交付的关系。
 
@@ -347,6 +347,8 @@ AI 重新核对同一交付目录的访问，读取状态并确认下一步技
 
 每个需求使用独立交付目录，并说明共用的代码、接口、数据库或环境。可以同时分析；修改同一份代码时安排先后，或使用独立工作目录并安排合并。
 
+其他需求的未提交改动不会自动纳入本次需求，也不因工作树不干净而要求清理；工程基线保存在工程记录中，不粘贴到业务 PRD。
+
 AI 只能核对已知且可访问的交付，不会自动锁定或调度其他会话。请说明其他正在进行的修改，各自完成后仍需检查合并结果。
 
 <a id="4-常见问题与参考"></a>

package/lib/approvals.mjs

@@ -103,14 +103,17 @@ export async function reviewStatus(directory, state) {
     let digest = null;
     try { digest = await reviewFingerprint(directory, state, doc); } catch { /* Missing input remains blocked. */ }
     const { approved, checked, latest } = decisionFor(state, doc, digest);
-    documents.push({ path: doc.path, version: doc.version, digest, selfCheck: checked?.id ?? null, approval: approved?.id ?? null, status: !digest ? 'unavailable' : approved && (evidenceIssues.includes(approved.id) || (checked && evidenceIssues.includes(checked.id))) ? 'evidence-changed' : approved ? 'approved' : latest?.kind === 'changes-requested' ? 'changes-requested' : latest?.kind === 'self-check' && latest.result === 'failed' ? 'self-check-failed' : checked ? 'pending' : 'self-check-required' });
+    let inputBasis=false;
+    if(doc.mode==='input') { try { await evidence(directory,state,doc.basisRef); inputBasis=true; } catch { /* The adoption request must be readable. */ } }
+    const status=!digest ? 'unavailable' : (checked && evidenceIssues.includes(checked.id)) || (approved && evidenceIssues.includes(approved.id)) ? 'evidence-changed' : doc.mode==='input' && !inputBasis ? 'input-basis-required' : latest?.kind==='changes-requested' ? 'changes-requested' : latest?.kind==='self-check' && latest.result==='failed' ? 'self-check-failed' : doc.mode==='input' ? checked?'adopted':'self-check-required' : approved?'approved':checked?'pending':'self-check-required';
+    documents.push({ path: doc.path, version: doc.version, digest, selfCheck: checked?.id ?? null, approval: doc.mode==='input'?null:approved?.id ?? null, input:doc.mode==='input', status });
   }
   let limitedScope=false;
   if(state.deliveryPolicy?.partialRef) {
     try { await evidence(directory,state,state.deliveryPolicy.partialRef); limitedScope=true; }
     catch { /* Report an unavailable scope basis; never silently grant an exception. */ }
   }
-  const runs = [], requirement = state.documentPolicy?.authority === 'adopted' ? 'scope' : 'prd';
+  const runs = [], requirement = 'prd';
   for (const [i, run] of state.stageRuns.entries()) {
     const spec = map.stages[run.stage];
     let required = [];
@@ -120,7 +123,7 @@ export async function reviewStatus(directory, state) {
     }
     const declared = run.dependsOn ?? (i ? [state.stageRuns[i - 1].id] : []);
     const producers = state.stageRuns.slice(0, i).filter(r => r.outputRefs.some(out => run.inputRefs.some(input => out.split('#')[0] === input.split('#')[0]))).map(r => r.id);
-    const development = ['requirements','scope','tech-design','contract','test-design','plan','implement'];
+    const development = ['requirements','tech-design','contract','test-design','plan','implement'];
     const prerequisites = development.includes(run.stage) ? state.stageRuns.slice(0,i).filter(r=>development.includes(r.stage) && development.indexOf(r.stage)<development.indexOf(run.stage)).map(r=>r.id) : [];
     const gated=state.deliveryPolicy?.version===1 && ['review','verify','handoff'].includes(run.stage);
     const entrance=gated && !limitedScope ? standardEntry(state,run,i,runs) : {dependsOn:[],issues:[]};
@@ -144,13 +147,13 @@ export async function reviewStatus(directory, state) {
         if (state.documentPolicy.interface !== null && state.documentPolicy.interface !== 'none') needs.push('contract');
         if (state.documentPolicy.databases?.length) needs.push('sql');
       }
-      if (run.stage === 'implement' && state.documentPolicy.interaction && !state.documentPolicy.prototypeCovered) needs.push('prototype');
+      if (run.stage === 'implement' && state.stageRuns.some(r=>r.stage==='prototype')) needs.push('prototype');
       for (const kind of needs) {
         const inputs = (state.documents ?? []).filter(d=>d.kind === kind);
-        if (!inputs.length || inputs.some(d=>documents.find(r=>r.path===d.path)?.status !== 'approved')) blockedBy.push(`approval:${kind}`);
+        if (!inputs.length || inputs.some(d=>!['approved','adopted'].includes(documents.find(r=>r.path===d.path)?.status))) blockedBy.push(`approval:${kind}`);
       }
     }
-    const waiting = required.filter(file => documents.find(d => d.path === file)?.status !== 'approved');
+    const waiting = required.filter(file => !['approved','adopted'].includes(documents.find(d => d.path === file)?.status));
     const ready = run.progress === 'done' && !['needs-review','unknown'].includes(run.applicability) && !blockedBy.length && !waiting.length && (!spec?.humanReview || required.length > 0);
     const releaseReady = ready && (run.stage !== 'review' || run.result === 'passed');
     runs.push({ id: run.id, stage: run.stage, progress: run.progress, applicability: run.applicability, documents: required, waiting, dependsOn, blockedBy, ready, releaseReady });
@@ -167,7 +170,7 @@ export async function reviewStatus(directory, state) {
   const pending = runs.filter(r => r.progress !== 'planned').flatMap(r => r.waiting.map(document => ({ run: r.id, document, status: documents.find(d => d.path === document)?.status })));
   const nextRun = runs.find(r => !r.ready);
   const nextStage = current ? runs[runs.indexOf(current) + 1]?.stage ?? null : nextRun?.stage ?? null;
-  return { compatibility: 'current', documents, runs, pending, evidenceIssues, currentRun: current?.id ?? null, nextRun: nextRun?.id ?? null, nextStage, canProceed: current ? !current.blockedBy.length && !(current.progress === 'done' && !current.releaseReady) && current.progress !== 'blocked' && !['needs-review','unknown'].includes(current.applicability) : !pending.length && !runs.some(r=>r.progress==='blocked' || (r.progress === 'done' && !r.releaseReady) || (r.progress !== 'planned' && r.blockedBy.length) || ['needs-review','unknown'].includes(r.applicability)), identity: 'Record validation only; user identity, intent and source authenticity are not authenticated.' };
+  return { compatibility: 'current', documents, runs, pending, evidenceIssues, currentRun: current?.id ?? null, nextRun: nextRun?.id ?? null, nextStage, canProceed: !state.next.questionRef && (current ? !current.blockedBy.length && !(current.progress === 'done' && !current.releaseReady) && current.progress !== 'blocked' && !['needs-review','unknown'].includes(current.applicability) : !pending.length && !runs.some(r=>r.progress==='blocked' || (r.progress === 'done' && !r.releaseReady) || (r.progress !== 'planned' && r.blockedBy.length) || ['needs-review','unknown'].includes(r.applicability))), identity: 'Record validation only; user identity, intent and source authenticity are not authenticated.' };
 }
 async function evidence(directory, state, ref) {
   if (!text(ref) || ref.includes('\\') || ref.split('#')[0].split('/').includes('..') || ref.startsWith('/') || (/^[a-zA-Z]:/.test(ref) && !ref.startsWith('repo:'))) reject('Review evidence must stay inside a registered root.');
@@ -181,13 +184,23 @@ async function evidence(directory, state, ref) {
 export async function enforceReviews(directory, state, previous) {
   validateReviewState(state);
   if (state.reviewPolicy !== 1) reject('Invalid review policy.');
+  for(const doc of state.documents.filter(d=>d.mode==='input')) await evidence(directory,state,doc.basisRef);
+  if(state.next.questionRef) await evidence(directory,state,state.next.questionRef);
   const oldHistory = previous?.reviewHistory ?? [];
-  for (const old of previous?.documents ?? []) if (oldHistory.some(r=>r.document===old.path) && !state.documents.some(d=>d.path===old.path && d.kind===old.kind)) reject(`Preserve reviewed document registration ${old.path}.`);
+  const previousPrd=previous?.documents.find(d=>d.kind==='prd'), currentPrd=state.documents.find(d=>d.kind==='prd');
+  const replacedPrd=previousPrd && currentPrd && previousPrd.path!==currentPrd.path;
+  for (const old of previous?.documents ?? []) {
+    const retained=state.documents.some(d=>d.path===old.path && (d.kind===old.kind || (replacedPrd && old===previousPrd && d.kind==='source' && d.mode==='reused')));
+    if(oldHistory.some(r=>r.document===old.path) && !retained)reject(`Preserve reviewed document registration ${old.path}.`);
+  }
+  const revisedApprovedPrd=replacedPrd && oldHistory.some(r=>r.document===previousPrd.path && (['approved','editorial'].includes(r.kind) || (previousPrd.mode==='input' && r.kind==='self-check' && r.result==='passed')));
+  if(revisedApprovedPrd && !state.openChanges.some(c=>c.status==='open'))reject('Record the requirement authority change and impact in an open CHG.');
   if (state.reviewHistory.length < oldHistory.length || !oldHistory.every((r, i) => isDeepStrictEqual(r, state.reviewHistory[i]))) reject('Preserve review history unchanged and in order.');
   const prefix = { ...state, reviewHistory: [...oldHistory] };
   for (const r of state.reviewHistory.slice(oldHistory.length)) {
     const doc = state.documents.find(d => d.path === r.document);
     if (!doc || r.version !== doc.version || r.digest !== await reviewFingerprint(directory, state, doc)) reject(`${r.id}: review must bind the current registered document version and content.`);
+    if(doc.mode==='input' && ['approved','editorial'].includes(r.kind)) reject('Supplied inputs use their adoption basis and self-check, not a fabricated document approval.');
     const prior = decisionFor(prefix, doc, r.digest);
     if (r.kind === 'approved' && !prior.checked) reject(`${r.id}: self-check the same content before recording approval.`);
     if (r.kind === 'editorial' && (!prior.checked || !decisionFor(prefix, doc, r.previousDigest).approved)) reject(`${r.id}: editorial reconciliation needs a self-check and the previous approval at the same version.`);
@@ -195,20 +208,19 @@ export async function enforceReviews(directory, state, previous) {
     prefix.reviewHistory.push(r);
   }
   // Only the initial selected development sequence is ordered; later rework can recur.
-  const order = ['requirements','scope','tech-design','contract','test-design','plan','implement'];
+  const order = ['requirements','tech-design','contract','test-design','plan','implement'];
   const first = stage => state.stageRuns.findIndex(r => r.stage === stage);
   for (let i = 0; i < order.length; i++) for (let j = i + 1; j < order.length; j++) {
     const a = first(order[i]), b = first(order[j]);
-    if (order[i] === 'requirements' && order[j] === 'scope') continue;
     if (a >= 0 && b >= 0 && a > b && !previous?.stageRuns.some(r => r.id === state.stageRuns[b].id && r.progress !== 'planned')) reject(`${order[i]} must precede ${order[j]} in the initial development arrangement.`);
   }
   const restoring = new Set(state.stageRuns.filter(r=>r.applicability === 'current' && previous?.stageRuns.some(old=>old.id===r.id && old.applicability==='needs-review')).map(r=>r.id));
   let status = await reviewStatus(directory, state);
   // Invalidate only registered producer/dependency paths. Independent branches retain their facts.
-  const affected = new Set();
+  const affected = new Set(revisedApprovedPrd ? status.runs.filter(r=>r.stage==='requirements' && r.progress!=='planned').map(r=>r.id) : []);
   for (const doc of state.documents) {
     const oldDoc = previous?.documents?.find(d => d.path === doc.path);
-    const latest = oldHistory.filter(r => r.document === doc.path && ['approved','editorial'].includes(r.kind)).at(-1);
+    const latest = oldHistory.filter(r => r.document === doc.path && (['approved','editorial'].includes(r.kind) || (oldDoc?.mode==='input' && r.kind==='self-check' && r.result==='passed'))).at(-1);
     const now = status.documents.find(d => d.path === doc.path);
     if (!oldDoc || !latest || !now) continue;
     const changed = latest.digest !== now.digest || latest.version !== doc.version;
@@ -216,7 +228,7 @@ export async function enforceReviews(directory, state, previous) {
     const requested = state.reviewHistory.slice(oldHistory.length).some(r=>r.document===doc.path && (r.kind==='changes-requested' || (r.kind==='self-check' && r.result==='failed')));
     if ((!changed && !requested) || editorial) continue;
     if (changed && !state.openChanges.some(c => c.status === 'open')) reject(`${doc.path}: record the material change and impact in an open CHG, or self-check an editorial reconciliation.`);
-    if (changed && now.status === 'approved' && doc.version === latest.version) reject(`${doc.path}: a material revision needs a new document version; use editorial only for unchanged meaning.`);
+    if (changed && ['approved','adopted'].includes(now.status) && doc.version === latest.version) reject(`${doc.path}: a material revision needs a new document version; use editorial only for unchanged meaning.`);
     for (const r of status.runs.filter(r => r.documents.includes(doc.path) && r.progress !== 'planned')) affected.add(r.id);
   }
   for (const r of status.runs) if (r.dependsOn.some(id => affected.has(id))) affected.add(r.id);

package/lib/cli.mjs

@@ -30,7 +30,7 @@ const HELP = {
     schemaVersion: SCHEMA_VERSION,
     documentReview: {reviewPolicy:1, reviewHistory:'Append-only {id,kind,document,version,digest,sourceRef,summary}. self-check requires result: passed|failed; approved requires decision: explicit-approval; editorial requires previousDigest. Read review.documents for current digests. Tools validate records, not user identity. See docs/cli.md#document-review-protocol.'},
     deliveryPolicy: 'New states default to {version:1}; partialRef identifies an explicitly limited scope, null restores standard scope with a new goal decision. Completion is derived separately from goal/acceptance.',
-    sessions: 'run.sessionGroup is an advisory context group, auto-filled for new runs; reviewOf names implementation runs and overall:true identifies overall review. read/check/resume expose session/completion; writeResult.session is withheld on failed view saving. No session gate or automatic execution.',
+    sessions: 'run.sessionGroup is an advisory context group, auto-filled for new runs; reviewOf names implementation runs and overall:true identifies overall review. read/check/resume expose session/completion. Supplied PRD/prototype mode input uses the actual request basisRef and self-check, not human approval. next.questionRef identifies a concrete question on a blocked stage (clear with null). Completed stages return stop with await-review, await-clarification or await-continue, even within one group; suggestNewSession is advisory. Failed view saving returns reconcile-save. No new approval or automatic execution.',
     stages: STAGES,
     progress: ['planned', 'active', 'blocked', 'done'],
     result: ['passed', 'failed', 'not-run', 'unknown', 'mixed'],
@@ -40,7 +40,7 @@ const HELP = {
     references: 'delivery-relative/path#optional-fragment, repo:<registered-id>/<repo-relative-path>#fragment, or HTTP(S) URL. Local paths cannot escape their root. Repository registration: {id, path: absolute-path, role}.',
     topLevel: {
       managed: 'schemaVersion, revision, deliveryId, rulesVersion, createdAt, updatedAt, goalHistory, documentDigests, writeResult. Do not supply these in init/update.',
-      requiredInit: 'language: en|zh-CN and goal: {summary, endpoint?}; save a nonempty source/request.md before init. Defaults: endpoint null, goalRef source/request.md, empty documents, and null documentPolicy conditions/authority. Register PRD/Scope and switch goalRef when drafted; no empty templates.',
+      requiredInit: 'language: en|zh-CN and goal: {summary, endpoint?}; save a nonempty source/request.md before init. Defaults: endpoint null, goalRef source/request.md, empty documents, and null documentPolicy conditions/authority. Register PRD and switch goalRef when drafted; no empty templates.',
       language: 'en or zh-CN from explicit user preference, otherwise this delivery conversation. Required in current state; retained on update/render/resume.',
       storage: 'Init-only {mode: explicit, decisionRef: delivery-relative-readable-file} for a user-selected location. Otherwise a strict child of configured dataRoot. Returned dataRoot is managed; ordinary workspace/material location is not a choice.',
       stageRuns: 'Ordered array of stageInstance objects, default []. Every ID is unique; currentRun must match one of these IDs or be null. Stage types may repeat with distinct IDs.',