aimship 0.1.0-preview.15 → 0.1.0-preview.16

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.15`, 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.15 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.15 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.15`。预览通道用于实验性版本，不代表稳定版。
+npx 的获取包提示只确认下载并运行该包；执行 `install` 才会安装或升级 Aimship。`@preview` 表示已发布的预览通道，也可以替换为明确版本号，例如 `@0.1.0-preview.16`。预览通道用于实验性版本，不代表稳定版。
 
 ### 指定版本或本地包
 
 安装指定的已发布版本，例如：
 
 ```sh
-npx aimship@0.1.0-preview.15 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.15 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 → the registered retained PRD file in source/ (mode reused); 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 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 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, 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
 
@@ -91,7 +91,7 @@ Production `progress: done` may be saved while approval is pending. Starting/com
 
 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 an approved requirement change; affected requirements/dependencies return to review. This changes current material, not historical approval records.
+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.
 
@@ -99,7 +99,7 @@ See the [Agent review workflow](../skills/aimship/references/document-review.md)
 
 ## 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/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.
 

package/docs/guide.md

@@ -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; 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. Reviewable documents await explicit approval; other stages await continuation. You may say “approved, continue” once. Work within a stage stays continuous.
+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>
@@ -124,7 +124,7 @@ 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 current requirements and any selected prototype. Check scope, acceptance criteria and page behavior; approve or give feedback. An evidenced existing approval of the current content is reused without asking again.
+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:** 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.
 
@@ -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). 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. Existing files are not approval; evidenced current approvals are reused.
+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.
 

package/docs/guide.zh-CN.md

@@ -76,7 +76,7 @@ AI 工具项目空间
 
 以登录注册功能演示从需求到验收。**这是虚构实践参考，措辞和业务方案无需照抄。** 本例稍后提供工程和隔离测试数据库，约定需求后确认原型，再做技术设计；实际原型安排按交付需要确定。
 
-同一会话沿用一个 Aimship 入口，无需逐阶段调用。每阶段完成并自检后，AI 保存成果、说明停点并停下，建议新会话，也可原会话继续。需审核的材料等待明确批准，其他阶段等待继续；可以一次说“通过并继续”。阶段内部不逐小步暂停。
+同一会话沿用一个 Aimship 入口，无需逐阶段调用。每阶段完成并自检后，AI 保存成果、说明停点并停下，建议新会话，也可原会话继续。AI 新产出或实质修改的需审文档等待批准，具体疑问等待确认，其他已完成阶段等待继续；可以一次说“通过并继续”。阶段内部不逐小步暂停。
 
 <a id="11-准备工作位置"></a>
 <a id="12-启用-aimship-并说明需求"></a>
@@ -124,7 +124,7 @@ AI 工具项目空间
 - 没有 PRD／原型：说明功能和预期行为，如“用户名不能重复，退出后再进首页必须登录”。
 - 已有材料：给出 PRD／原型的位置、版本和本次采用范围；只有部分材料也直接说明。
 
-打开当前需求材料及本次选用的原型，核对范围、验收标准和页面行为，明确通过或反馈。有可核实且对应当前内容的已有批准时直接沿用，不重复审批。
+你明确提供完整适用的 PRD／原型并要求据此交付时，AI 原样接纳，不要求重审原文；来源副本和管理记录也不逐份送审。只有存在影响推进的具体疑问才请你确认。需要你审核的是 AI 新写、裁剪或实质修改的需求与原型：查看范围、验收标准和页面行为，明确通过或反馈。已有当前内容的有效批准直接沿用。
 
 **AI 处理**：完整适用的 PRD 直接采用，不重写或重新编号；仅采用部分时编写本次 PRD，写清来源、纳入、排除及验收，尽量沿用原编号；没有 PRD 时讨论后生成。原型可选，已有原型充分则复用。逐份自检、确认并保存，原件保留。
 
@@ -254,7 +254,7 @@ AI 重新核对同一交付目录的访问，读取状态并确认下一步技
 
 ### 2.1 何时换会话
 
-每阶段完成后按 `status.md` 的停点处理：待审则批准或反馈，已完成则要求继续。建议此时换会话，也可继续当前会话；“继续”不替代待审材料的批准。进度页先展示当前操作，尚未开始的后续阶段不会当作当前缺项。
+每阶段完成后按 `status.md` 的停点处理：AI 产出待审则批准或反馈，有具体疑问则回答问题，已完成则要求继续。建议此时换会话，也可继续当前会话；“继续”不替代待审材料的批准。进度页先展示当前操作，尚未开始的后续阶段不会当作当前缺项。
 
 新会话操作见[演示中的续接示例](#guide-session-example)。同一交付只保留一个写入会话；可信记录可直接定位，找不到或有多个候选才询问。交付语言沿用已保存设置。首次保存前就要切换时，携带未保存诉求、计划位置及未完成操作。
 
@@ -289,7 +289,7 @@ AI 重新核对同一交付目录的访问，读取状态并确认下一步技
 
 ### 3.1 已有资料或讨论
 
-提供 PRD、原型或截图的位置、版本和本次使用范围，AI 按[确认需求](#guide-requirements)核对。完整适用的 PRD 直接采用；部分采用形成迭代 PRD，原件不改。若要修改原件，请明确说明。已有文件不等于已批准，已有有效批准则不重复索要。
+提供 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`。原始诉求被误改时，从可靠原件恢复；找不到就暂停核对。错字或排版无需全部重审。交付后的小修可继续原交付；新目标或大幅重设计另建交付，并注明与原交付的关系。
 

package/lib/approvals.mjs

@@ -103,7 +103,10 @@ 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) {
@@ -147,10 +150,10 @@ export async function reviewStatus(directory, state) {
       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,6 +184,8 @@ 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 ?? [];
   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;
@@ -188,13 +193,14 @@ export async function enforceReviews(directory, state, previous) {
     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));
+  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.`);
@@ -214,7 +220,7 @@ export async function enforceReviews(directory, state, previous) {
   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;
@@ -222,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. Completed stages return stop with await-review or await-continue, even within one group; suggestNewSession is advisory. Failed view saving returns reconcile-save. No new approval 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'],

package/lib/delivery.mjs

@@ -81,12 +81,13 @@ export function sessionAdvice(directory,state,review,{saved=true}={}) {
   const endAction=concluded?'finished':(current??last)?.stage==='handoff'?'assess-outcome':'await-continue';
   let action='continue-current';
   if (!saved) action='reconcile-save';
-  else if(pending) action='await-review';
+  else if(state.next.questionRef) action='await-clarification';
+  else if(pending) action=review.pending.some(p=>!review.documents.find(d=>d.path===p.document)?.input)?'await-review':'resolve-current';
   else if(!current && state.stageRuns.length && review.runs.every(r=>r.ready)) action=concluded?endAction:review.runs.some(r=>r.releaseReady===false)?'resolve-current':endAction;
   else if(current && ((!status?.resolvedBy && (['failed','mixed','unknown','not-run'].includes(current.result) || (current.stage==='review' && current.progress==='done' && !status?.releaseReady))) || current.progress==='blocked' || ['needs-review','unknown'].includes(current.applicability))) action=concluded && !next?'finished':'resolve-current';
   else if(status?.ready) action=!next?endAction:next.progress!=='planned'?'inspect-existing-work':'await-continue';
   if (saved && !pending && state.deliveryPolicy?.version === 1 && status?.ready && next && review.runs.find(r=>r.id===next.id)?.blockedBy.length) action='resolve-current';
-  const instruction=action==='await-continue'?text(state,'This stage is saved. Stop here and wait for the user to continue; a new session is recommended, not required. Approval and continuation may be expressed together.','本阶段已保存。请在此停下，等待用户继续；建议新会话，也可在当前会话继续。批准和继续可以一次表达。'):action==='assess-outcome'?text(state,'Review the handoff against the agreed goal and record the actual goal conclusion and acceptance; completed handoff alone does not end the delivery.','请对照约定目标审阅交付材料，记录实际目标结论和用户接受结果；完成交付文档不等于交付已结束。'):null;
-  const continuation=['reconcile-save','await-review','assess-outcome','finished'].includes(action)?null:text(state,`Use Aimship to continue delivery ${JSON.stringify(path.resolve(directory))}; first read its current state and relevant formal documents, then continue the recorded work.${instruction?' '+instruction:''}`,`使用 Aimship 继续交付「${path.resolve(directory)}」，先读取当前状态和相关正式文档再接续。${instruction??''}`);
+  const instruction=action==='await-clarification'?text(state,'Please answer the question listed below so this work can continue.','请回答下一步所列的具体问题，以便继续当前工作。'):action==='await-continue'?text(state,'This stage is saved. Say “continue” when ready; you can continue here or start a new session.','本阶段已保存。准备好后可说“继续”；也可以新开会话接续。'):action==='assess-outcome'?text(state,'Review the handoff against the agreed goal and record the actual goal conclusion and acceptance; completed handoff alone does not end the delivery.','请对照约定目标审阅交付材料，记录实际目标结论和用户接受结果；完成交付文档不等于交付已结束。'):null;
+  const continuation=['reconcile-save','await-review','await-clarification','assess-outcome','finished'].includes(action)?null:text(state,`Use Aimship to continue delivery ${JSON.stringify(path.resolve(directory))}; first read its current state and relevant formal documents, then continue the recorded work.${instruction?' '+instruction:''}`,`使用 Aimship 继续交付「${path.resolve(directory)}」，先读取当前状态和相关正式文档再接续。${instruction??''}`);
   return {action,stop:!['continue-current','inspect-existing-work'].includes(action),suggestNewSession:['await-review','await-continue'].includes(action),currentRun:current?.id??null,nextRun:next?.id??null,groups,continuation,instruction,advisory:true,note:text(state,'A session boundary is not a blocker or approval. Continue here when requested. Resolve the delivery identity, current approvals and unfinished effects on every resume; this text grants no approval.','会话边界不是阻塞或批准。用户要求时可在当前会话继续。每次续接都需核对交付身份、当前审批和未完成事项；本提示不授予权限。')};
 }

package/lib/documents.mjs

@@ -155,12 +155,12 @@ export async function inspectDocuments(directory, state) {
     if (text === null) { unchecked.push(`${doc.path}: remote or unavailable repository; inspect adopted version using host tools (${doc.basisRef ?? 'missing basisRef'}).`); continue; }
     digests[doc.path] = hash(text);
     if (!text.trim()) issues.push(`${doc.path}: empty document.`);
-    if (doc.mode === 'reused') {
+    if (doc.mode !== 'new') {
       // Reuse is a current input option, not a historical document protocol.
       // Read ordinary IDs from the explicitly registered requirement authority;
       // do not impose our outline or infer that arbitrary source formats passed.
       if (doc === find('requirement') && /\.md$/i.test(doc.path)) defs.push(...definitions(text,doc.path));
-      unchecked.push(`${doc.path}: reused format/content; human/Agent basis ${doc.basisRef}.`); continue;
+      unchecked.push(`${doc.path}: reused format/content; recorded basis ${doc.basisRef}.`); continue;
     }
     if (spec) {
       const records=sections(text,spec); let previous=-1;

package/lib/language.mjs

@@ -6,9 +6,9 @@ const labels = {
  technical:'技术与契约', unrecorded:'未分组', unavailable:'不可用', 'assess-outcome':'核对交付结论与接受结果', frame:'目标梳理', requirements:'需求', prototype:'原型', 'tech-design':'技术设计', contract:'接口与 SQL', 'test-design':'测试设计', plan:'实施计划', implement:'实施', review:'审查', verify:'验证', handoff:'交付验收', diagnose:'调查',
  planned:'待开始', active:'进行中', blocked:'受阻', done:'已完成记录', passed:'通过', failed:'失败', 'not-run':'未执行', mixed:'部分通过', current:'当前有效', 'needs-review':'待复核',
  'in-progress':'进行中', met:'已达成', 'not-met':'未达成', 'not-recorded':'未记录', accepted:'已接受', declined:'未接受',
- approved:'已批准', pending:'待审核', 'self-check-required':'待自检', 'self-check-failed':'自检失败', 'changes-requested':'需修改', 'evidence-changed':'审批依据已变化',
+ adopted:'已采用输入', 'input-basis-required':'采用依据待明确', approved:'已批准', pending:'待审核', 'self-check-required':'待自检', 'self-check-failed':'自检失败', 'changes-requested':'需修改', 'evidence-changed':'审批依据已变化',
  'partial-scope':'明确限定范围', 'standard-complete':'标准交付已完成', 'ready-for-acceptance':'待验收', incomplete:'未完成',
- 'continue-current':'继续当前工作', 'await-continue':'等待继续', 'inspect-existing-work':'检查已有工作', 'resolve-current':'先处理当前问题', 'await-review':'等待审核', 'reconcile-save':'核对保存结果', finished:'当前约定目标已结束', 'arrange-next':'确认并记录下一项工作',
+ 'continue-current':'继续当前工作', 'await-continue':'等待继续', 'inspect-existing-work':'检查已有工作', 'resolve-current':'先处理当前问题', 'await-review':'等待审核', 'await-clarification':'等待问题确认', 'reconcile-save':'核对保存结果', finished:'当前约定目标已结束', 'arrange-next':'确认并记录下一项工作',
  'requirements preparation':'需求准备', supported:'已启用', enforced:'已启用',
  interaction:'交互变化', prototypeCovered:'已有原型覆盖', interface:'接口变化', databases:'数据库变化'
 };

package/lib/state.mjs

@@ -42,10 +42,11 @@ export function validateState(state) {
       requireThat(Array.isArray(state.documents), 'documents must be an array.');
       const paths = new Set();
       for (const d of state.documents) {
-        requireThat(object(d) && ['prd','tech-design','plan','testing','review','diagnosis','handoff','change-log','prototype','contract','sql','source'].includes(d.kind) && ['new','reused'].includes(d.mode) && string(d.version), 'Invalid document registration.');
+        requireThat(object(d) && ['prd','tech-design','plan','testing','review','diagnosis','handoff','change-log','prototype','contract','sql','source'].includes(d.kind) && ['new','reused','input'].includes(d.mode) && string(d.version), 'Invalid document registration.');
         ref(d.path, 'documents.path'); requireThat(!d.path.includes('#') && !paths.has(d.path), 'Document paths must be unique and have no fragment.'); paths.add(d.path);
         if (d.assetRefs !== undefined) refs(d.assetRefs, 'documents.assetRefs');
-        if (d.mode === 'reused') { ref(d.basisRef, 'documents.basisRef'); }
+        if (d.mode !== 'new') { ref(d.basisRef, 'documents.basisRef'); }
+        if (d.mode === 'input') requireThat(['prd','prototype'].includes(d.kind) && (d.kind !== 'prd' || p.authority === 'adopted'), 'Input mode is for an unchanged supplied PRD or prototype; an input PRD uses adopted authority.');
       }
     }
   }
@@ -79,6 +80,10 @@ export function validateState(state) {
   if (['accepted', 'declined'].includes(state.outcome.acceptance)) requireThat(string(state.outcome.acceptanceRef), 'Acceptance requires a separate decision reference.');
   requireThat(object(state.next) && string(state.next.action), 'next.action is required.');
   if (state.next.inputRefs !== undefined) refs(state.next.inputRefs, 'next.inputRefs');
+  if (state.next.questionRef != null) {
+    ref(state.next.questionRef, 'next.questionRef');
+    requireThat(state.currentRun === null || state.stageRuns.find(r=>r.id===state.currentRun).progress === 'blocked', 'A current question keeps its stage blocked until clarified.');
+  }
   if (state.goalHistory !== undefined) requireThat(Array.isArray(state.goalHistory), 'goalHistory must be an array.');
   validateDelivery(state);
   if (state.deliveryPolicy?.partialRef) ref(state.deliveryPolicy.partialRef, 'deliveryPolicy.partialRef');
@@ -226,7 +231,7 @@ export async function recoverState(directory, revision, rulesVersion, runtime) {
 }
 export async function checkReferences(directory, state, all = false) {
   const current = state.stageRuns.find(x => x.id === state.currentRun);
-  const values = new Set([state.goalRef, ...(state.next.inputRefs ?? []), ...(current?.inputRefs ?? [])]);
+  const values = new Set([state.goalRef, ...(state.next.questionRef?[state.next.questionRef]:[]), ...(state.next.inputRefs ?? []), ...(current?.inputRefs ?? [])]);
   if (all) {
     for (const run of state.stageRuns) { for (const value of [...run.inputRefs, ...run.outputRefs, run.resultRef, run.priorResultRef, ...(run.historyResultRefs ?? [])].filter(Boolean)) values.add(value); }
     state.openChanges.forEach(x => values.add(x.ref)); state.closureRefs.forEach(x => values.add(x));
@@ -239,7 +244,7 @@ export async function checkReferences(directory, state, all = false) {
       add(history?.goalRef); add(history?.goal?.decisionRef); addOutcome(history?.outcome);
     }
     for (const r of state.reviewHistory ?? []) add(r.sourceRef);
-    for (const d of state.documents ?? []) for (const r of d.assetRefs ?? []) add(r);
+    for (const d of state.documents ?? []) { for (const r of d.assetRefs ?? []) add(r); if(d.mode==='input') add(d.basisRef); }
   }
   const results = [];
   for (const value of values) {

package/lib/view.mjs

@@ -41,17 +41,20 @@ export async function renderText(directory,state) {
   const progress=r=> {
     const check=review.runs.find(x=>x.id===r.id);
     if(r.progress==='planned')return t('Not started','尚未开始');
+    if(r.id===state.currentRun && state.next.questionRef)return t('Awaiting clarification','待确认具体问题');
     if(r.progress==='blocked' || check?.blockedBy.length || ['needs-review','unknown'].includes(r.applicability))return t('Needs attention','需要处理');
     if(failed(r) && !check?.resolvedBy)return t('Result needs resolution','结果待处理');
     if(check?.documents.some(file=>['self-check-failed','changes-requested','evidence-changed','unavailable'].includes(review.documents.find(d=>d.path===file)?.status)))return t('Needs revision or checking','需要修改或核对');
-    if(r.progress==='done' && check?.waiting.length)return t('Document prepared; awaiting review','文档已完成，待审核');
+    if(r.progress==='done' && check?.waiting.length)return check.waiting.every(file=>review.documents.find(d=>d.path===file)?.input)?t('Input check pending','输入材料待核对'):t('Document prepared; awaiting review','文档已完成，待审核');
+    if(r.progress==='done' && check?.documents.length && check.documents.every(file=>review.documents.find(d=>d.path===file)?.status==='adopted'))return t('Provided material adopted','已采用现有材料');
     return r.progress==='done'?t('Completed','已完成'):t('In progress','进行中');
   };
   const lines=[t('# Delivery progress','# 交付进度'),'',cell(state.goal.summary),'',t('## Current stage and your next action','## 当前阶段与用户操作'),''];
   lines.push(`${t('Current stage','当前阶段')}: ${v(current?.stage??'requirements preparation')}${current?' · '+progress(current):''}`);
   for(const d of humanDocs)lines.push(`- ${artifactLink(d.path)} ${cell(d.version)} · ${d.selfCheck?t('Self-check recorded as passed','自检记录通过'):t('Self-check pending','待自检')} · ${v(d.status)}`);
   lines.push('',`${t('Next action','下一步')}: ${cell(state.next.action)}`);
-  if(session.action==='await-review')lines.push('',t('Review the current document and explicitly approve it or give feedback. Do not start the next stage while review is pending.','请审核当前材料，明确通过或反馈修改；待审期间不进入下一阶段。'));
+  if(session.action==='await-review')lines.push('',t('Review the AI-authored or substantively revised document and explicitly approve it or give feedback.','请审核 AI 新产出或实质修改的文档，明确通过或反馈修改。'));
+  if(state.next.questionRef)lines.push('',`${t('Question and impact','问题与影响')}: ${artifactLink(state.next.questionRef)}`);
   if(session.instruction)lines.push('',cell(session.instruction));
   const next=suggestedNextStage(state);
   if(next && current?.progress==='done' && !['resolve-current','finished','assess-outcome'].includes(session.action))lines.push('',`${t('After this stop','当前停点处理后')}: ${v(next)}${session.action==='await-review'?t(' (after approval)','（批准后）'):''}`);
@@ -87,7 +90,7 @@ export async function renderText(directory,state) {
   for(const d of state.documents)refs.set(d.path,`${names[d.kind]??v(d.kind)} · ${cell(d.version)}`);
   for(const ref of state.stageRuns.flatMap(r=>[...r.outputRefs,r.resultRef].filter(Boolean)).concat(state.next.inputRefs??[]))if(!refs.has(ref.split('#')[0]))refs.set(ref.split('#')[0],t('Work material','工作材料'));
   for(const [ref,role] of refs)if(await available(directory,state,ref))lines.push(`- ${role}: ${artifactLink(ref)}`);
-  lines.push('',t('## Continue this delivery','## 接续本次交付'),'',`${t('Delivery directory','交付目录')}: ${cell(path.resolve(directory))}`,'',t('Explicitly activate Aimship in a new session, name this directory and read the saved state and current materials. Resume this stop; “continue” is not approval. A new session is recommended at stage boundaries, but you may continue here.','新会话明确启用 Aimship，指定此目录，读取已保存状态和当前材料，接续本页停点；“继续”不代表批准。阶段边界建议新会话，也可在当前会话继续。'));
+  lines.push('',t('## Continue this delivery','## 接续本次交付'),'',`${t('Delivery directory','交付目录')}: ${cell(path.resolve(directory))}`,'',t('You can continue here, or start a new session with “Use Aimship to continue this delivery” and this directory. The AI reads the saved state and materials and resumes the current stop.','可在当前会话继续；新会话请说“使用 Aimship 继续本次交付”并提供此目录。AI 会读取已保存状态和材料，接续本页停点。'));
   if(state.repositories.length) {
     lines.push('',t('## Associated engineering','## 关联工程'),'',t('| Object | Location | Role |','| 工程 | 位置 | 用途 |'),'| --- | --- | --- |');
     for(const r of state.repositories)lines.push(`| ${cell(r.id)} | ${cell(r.path)} | ${cell(r.role)} |`);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "aimship",
-  "version": "0.1.0-preview.15",
+  "version": "0.1.0-preview.16",
   "description": "Explicit, goal-driven delivery workflow for coding agents",
   "license": "MIT",
   "type": "module",

package/skills/aimship/SKILL.md

@@ -9,9 +9,9 @@ disable-model-invocation: true
 Activate only when the user explicitly asks to start or resume Aimship. A clear request such as “use Aimship to start/continue” is explicit activation; a passing mention of its name or opening a project is not. In each new session, explicitly activate it again. Ordinary conversation does not create a delivery. Once activated, continue the same delivery across turns without asking the user to invoke every stage.
 
 1. Run `"{{AIMSHIP_NODE}}" "{{AIMSHIP_LAUNCHER}}" bind` to resolve the installed version. Read the returned fixed-version core and that CLI’s help before using its state protocol; cached old-tool schema metadata is not the newly bound protocol. Use that fixed version's tools, carrying its rules version and the current state revision. If this is a source checkout rather than an installed entry, use `node bin/aimship.mjs bind` from the package root.
-2. Read the core at the path returned by `bind`. Resolve all supporting links below against that same fixed release, even if a cached entry mentions an older path. [The shared core](references/core.md) is the source-checkout reference. For an existing delivery, read its state and the current goal/PRD plus only the next step's required references. Do not create a replacement delivery, reset its plan, or infer a new goal from “continue”.
+2. Read the core at the path returned by `bind`. Follow its User-facing updates guidance: normally report concrete results and user actions, not internal rule quotations. Resolve all supporting links below against that same fixed release, even if a cached entry mentions an older path. [The shared core](references/core.md) is the source-checkout reference. For an existing delivery, read its state and the current goal/PRD plus only the next step's required references. Do not create a replacement delivery, reset its plan, or infer a new goal from “continue”.
 3. Follow the core's [initialization flow](references/core.md#initialization) for new work or interrupted creation. A concrete problem or intended change is enough; no PRD, code location, repository association or known technical conditions are required. Preserve the original request, resolve the same delivery and access, and use init only when state does not exist. New deliveries default to a separate folder under the bound dataRoot; the AI tool workspace or prototype location is not an explicit location choice. If access is needed, have the user add the actual delivery directory or grant access in the AI tool, without copying documents or claiming automatic folder addition. Save the delivery language from the user’s preference or current conversation, as the core specifies. Unknown endpoint/conditions remain unknown, never an inferred authorization or limited scope. Report actual save location, current work and next step. Repeated activation resumes; later code association retains the same delivery ID.
-4. Read the selected [stage reference](references/core.md#stage-references). Work continuously within that stage. On completion and self-check, save its artifacts, current stop and next action, report them and stop. Follow [document review](references/document-review.md): reviewable documents await explicit approval; other stage results await continuation, not a new approval. A user may approve and ask to continue in one message. “Continue”, questions and silence alone do not approve. Do not automatically cross a stage because its sessionGroup is unchanged.
+4. Read the selected [stage reference](references/core.md#stage-references). Work continuously within that stage. On completion and self-check, save its artifacts, current stop and next action, report them and stop. Follow [document review](references/document-review.md): AI-authored or substantively revised reviewable documents await approval; unchanged supplied inputs with clear adoption intent await no repeated review. Concrete unresolved questions await clarification; other completed stages await continuation, not a new approval. A user may approve and ask to continue in one message. “Continue”, questions and silence alone do not approve. Do not automatically cross a stage because its sessionGroup is unchanged.
 5. Recommend a new session at a saved stage boundary, without requiring it. On resume, uniquely locate the actual delivery and read its saved review/unfinished-work stop; never infer approval from a copied entry. Keep a compact binding: delivery ID, absolute directory, state path, current run, rules version and fixed core/tool paths. Reload these after compaction if absent. Default to the standard delivery sequence, not a full/design/init choice; respect explicit user limits or pauses.
 
 

package/skills/aimship/references/core.md

@@ -1,5 +1,11 @@
 # Shared delivery core
 
+## User-facing updates
+
+Apply the workflow internally. In normal delivery conversation, explain the actual result, which supplied materials were retained/copied, which outputs or records changed, their useful links, the current review/question/continuation stop and the next action. Use the delivery language and concrete facts. Do not justify a stop by quoting internal Skill instructions, protocol text or untranslated rule sentences, and do not link internal Skill files as the default reason. A review request names the AI-produced document and review focus; a clarification names the specific question, options and impact; a completed stage says what is saved and what continuation will do. For example: “技术设计已保存，请查看接口边界与错误处理，确认通过或提出修改。”
+
+This is presentation guidance, not permission to skip rules or hide facts. Keep useful PRD/business-source and artifact links, actual access limits, errors, unsaved work, required approvals and material risks visible. Translate a tool diagnostic into its concrete effect and next step without claiming success; include a relevant error/code when useful. Technical CLI JSON, rule paths and diagnostic notes remain available to the Agent and for troubleshooting, not a script to paste into every reply. When the user asks why, asks to inspect product rules or needs technical diagnosis, explain the relevant basis and link it as needed. Do not filter or rewrite saved user text to enforce this guidance.
+
 ## Start from the commission
 
 A delivery has one centralized material directory, a preserved original request, a state record, and a current PRD, authored or adopted as needed. The final endpoint may initially be unknown. Code stays in its existing locations. A single repository and several repositories use the same model; there is no project registration step, repository count limit, or route classification.
@@ -22,11 +28,11 @@ This flow follows explicit Aimship activation in the first and every new session
 3. Reuse the current workspace’s access to the intended materials path without changing that path. If access is missing, follow [AI tool access](hosts.md) with the exact required path; the user adds the original directory or grants the needed access. If the target does not exist, use its accessible existing parent to create it as part of saving this delivery, or explain which directory the user must create/open. No silent fallback into the workspace, unrelated probe files or global settings changes. Workspace names and “I added it” are not proof: normal reads establish read access only; actual saves establish write access for that operation. Do not report saved work before the result confirms it.
 4. Save the original input in source/request.md without replacing existing material. Set `language` to `zh-CN` or `en`: an explicit user preference takes precedence, otherwise use the language of this conversation. The Agent saves this delivery setting in init; it is not an installation setting or a command the user must learn. Use init to create state and its generated status.md. Before PRD exists, use goalRef source/request.md, empty documents and null for unknown endpoint and documentPolicy conditions/authority (schema 4). A requirements/frame run can be active without a draft; a done result still requires its formal artifact. Do not create empty templates or mark unknown conditions false/none/[] to pass init. Use next for the concrete pending questions/work; no parallel initialization ledger.
 5. Inspect stateSaved, revision and view from the actual result. Read back the saved state and status entry before reporting complete initialization. If the view failed, preserve the ID/revision and repair it with render; do not init again. If the response was lost, read before retrying. Source-only partial creation resumes at the same intended location after checking its ownership; stale locks require confirming the writer stopped.
-6. Give a concise receipt: initialized / resumed / incomplete, recognizable delivery, actual absolute directory and readable status link (only when available), saved materials, bound version, saved language, code association and checked access, current stage/work and next action. A repository registration alone does not prove access. Do not claim original initialization facts for an old delivery. Then continue authorized requirement clarification, unless the user requested a stop.
+6. Give a concise receipt: initialized / resumed / incomplete, recognizable delivery, actual absolute directory and readable status link (only when available), saved materials, bound version, saved language, code association and checked access, current stage/work and next action. A repository registration alone does not prove access. Do not claim original initialization facts for an old delivery. Separate existing materials retained or copied from documents newly authored or revised and delivery records newly created. Report “unchanged” only when supported by the actual operations and source evidence. For a complete unchanged supplied PRD with clear intent to deliver from it, report input adoption without requesting repeated source approval; clarify only actual uncertainties. Then continue authorized requirement clarification, unless the user requested a stop.
 
-Register the first substantive PRD, select its authority and change goalRef in the same update when drafting it. This reference transition alone does not alter the user's goal or require a fabricated approval; an actual endpoint/scope change still needs its decision source. Formal requirements and each subsequent selected reviewable document keep their existing self-check/explicit-approval stops. Write new formal headings/body and next-action text in the saved delivery language while retaining business IDs, machine keys and paths. Preserve source text and existing documents without automatic translation. Unknown technical conditions can be investigated during design, but must be resolved before completing design or advancing work that depends on them. Omitting a stage record cannot bypass its input document approvals. Initialization/check/resume readiness permits only the recorded current work, not all future stages.
+Register the first substantive PRD, select its authority and change goalRef in the same update when drafting it. This reference transition alone does not alter the user's goal or require a fabricated approval; an actual endpoint/scope change still needs its decision source. AI-authored or substantively revised requirements and subsequent selected reviewable outputs keep their self-check/explicit-approval stops. An unchanged supplied PRD/prototype uses mode input and its actual adoption-request basis; self-check makes it usable input, not human-approved AI output. Internal management records are not separately reviewed. Write new formal headings/body and next-action text in the saved delivery language while retaining business IDs, machine keys and paths. Preserve source text and existing documents without automatic translation. Unknown technical conditions can be investigated during design, but must be resolved before completing design or advancing work that depends on them. Omitting a stage record cannot bypass its input document approvals. Initialization/check/resume readiness permits only the recorded current work, not all future stages.
 
-“Clarify requirements first” describes current work, not a requirements-only endpoint or full development permission. Use null until the actual endpoint is known, then save the real decision before dependent work. Keep known conditions when available; false/none/[] mean explicitly not applicable, not unknown. Later changes use existing impact/re-review rules.
+“Clarify requirements first” describes current work, not a requirements-only endpoint or full development permission. The standard stage sequence is the default, not a choice to ask again in the receipt or next action. Clarify only a concrete unresolved scope or endpoint condition that affects the work; do not ask whether to follow the standard sequence. Use null until the actual endpoint is known, then save the real decision before dependent work. Keep known conditions when available; false/none/[] mean explicitly not applicable, not unknown. Later changes use existing impact/re-review rules.
 
 ### Associate code when needed
 
@@ -90,7 +96,7 @@ Read the reference for the current responsibility, not all stage references on e
 | verify | Executing the agreed checks and recording evidence | [verify](stages/verify.md) |
 | handoff | Delivering against the current goal or handing over incomplete work | [handoff](stages/handoff.md) |
 
-Each run records its scope, required inputs, results and progress. A result may be a section in a shared document. A `done` run records production completion, not human approval. Proceed when required document approvals match current content, this run's requirements are met, the next inputs exist, authorization covers it and no relevant unresolved issue blocks it. An issue blocks only dependent work; changing the order to continue other work is still an explicit plan change.
+Each run records its scope, required inputs, results and progress. A result may be a section in a shared document. A `done` run records completed work, not human approval. Adopted user input is distinct from reviewed AI output. Proceed when required AI-output approvals or adopted-input checks match current content, this run's requirements are met, the next inputs exist, authorization covers it and no relevant unresolved issue blocks it. An issue blocks only dependent work; changing the order to continue other work is still an explicit plan change.
 
 ## Implementation and evidence
 

package/skills/aimship/references/document-patterns.md

@@ -8,9 +8,9 @@ One request has one directory. New deliveries default to separate folders under
 
 Initialization may start with preserved source/request.md before a PRD is formed. Do not generate an empty template for init. Register the substantive requirement draft and switch goalRef when ready; before completing requirements or dependent work, use the existing formal artifact and approval rules below. Unknown artifact conditions stay null until determined, distinct from false/none/[] (not applicable).
 
-Use one registered PRD as the requirement authority. If an existing PRD fully fits this commission, retain its adopted version in source/ and register that file as kind prd, mode reused, authority adopted; keep its text, numbering and outline unchanged. If only part applies, author prd.md for this iteration with source/version, included and excluded work and acceptance; retain corresponding original business IDs. Without a PRD, clarify the request and write prd.md. There is no separate Scope document or approval. Existing approval is reusable only with actual evidence for the current content; otherwise confirm requirements. Adoption alone is not approval.
+Use one registered PRD as the requirement authority. If an existing PRD fully fits this commission, retain its adopted version in source/ and register that file as kind prd, mode input, authority adopted; keep its text, numbering and outline unchanged. If only part applies, author prd.md for this iteration with source/version, included and excluded work and acceptance; retain corresponding original business IDs. Without a PRD, clarify the request and write prd.md. There is no separate Scope document or approval. For supplied inputs, basisRef identifies the actual user request to use them for delivery; file presence alone does not establish this intent. Self-check these inputs without manufacturing human approval. Ask only concrete unresolved questions. AI-authored or substantively revised PRDs require review; an evidenced current-content approval of that output can be reused.
 
-A prototype is optional according to the work. Reuse adequate supplied material; create a prototype only when it helps clarify the agreed interaction and is selected for this delivery. Otherwise describe behavior in the PRD/design. A selected prototype keeps its document approval before implementation. New HTML uses `prototype/index.html`; other agreed formats may be registered.
+A prototype is optional according to the work. Reuse adequate supplied material; create a prototype only when it helps clarify the agreed interaction and is selected for this delivery. Otherwise describe behavior in the PRD/design. A selected prototype needs its current input check when supplied unchanged, or its document approval when AI-authored or substantively revised, before implementation. New HTML uses `prototype/index.html`; other agreed formats may be registered.
 
 `test-design` precedes `plan` in standard delivery; both reviewable documents need explicit approval. If the user explicitly excludes cases/testing, record the limited scope once and do not generate empty testing artifacts or call the result standard complete delivery. `plan` must finish before first implementation, even one small batch. `plan.md` holds both planned TASK/B records and actual execution, distinctly; state holds stage progress. `testing.md` holds cases/coverage and appended RUN records; verification follows overall review. Verify-only may register existing cases with version/coverage, without claiming test-design occurred. Review-only does not require implementation/tests. No arbitrary small-task merging, `implementation.md`, `test-plan.md`, `verification.md`, or `results.md` for new work.
 

package/skills/aimship/references/document-review.md

@@ -1,10 +1,14 @@
 # Review one document, then continue
 
-The selected development order is requirements intake / PRD → technical design → interface contract and independent SQL when applicable → test cases → implementation plan → implementation with batch and overall review → independent verification → handoff and acceptance. Test design precedes planning in the standard delivery. An explicitly limited scope can omit cases/verification, but is a partial handoff, not standard complete delivery. Keep the agreed endpoint: prototype and investigation have their own reviewable outputs; design-only stops at the commissioned design. Review-only and verify-only use their existing object/case basis without inventing implementation or uncommissioned upstream stages. Frame clarifies inputs; requirements provides the reviewed requirement authority. Do not generate empty stages or templates. When two responsibilities share the same already-approved current document, reuse that exact approval without asking twice.
+The selected development order is requirements intake / PRD → technical design → interface contract and independent SQL when applicable → test cases → implementation plan → implementation with batch and overall review → independent verification → handoff and acceptance. Test design precedes planning in the standard delivery. An explicitly limited scope can omit cases/verification, but is a partial handoff, not standard complete delivery. Keep the agreed endpoint: prototype and investigation have their own reviewable outputs; design-only stops at the commissioned design. Review-only and verify-only use their existing object/case basis without inventing implementation or uncommissioned upstream stages. Frame clarifies inputs; requirements establishes the adopted input or approved AI-authored requirement authority. Do not generate empty stages or templates. When two responsibilities share the same already-approved current document, reuse that exact approval without asking twice.
 
-For requirements, prototype, independent diagnosis, technical design, each interface/SQL document, test cases and implementation plan:
+Human review applies to AI-authored or substantively revised requirements, prototypes, independent diagnoses, technical designs, each interface/SQL document, test cases and implementation plans. It does not apply to unchanged user-supplied inputs or internal source, adoption, self-check and state records.
 
-1. Generate or revise the concrete document, preserving its fixed outline, identities and references. Self-check its content, coverage, consistency and actual entry. Mark production complete separately from this self-check.
+When the user supplies a complete applicable PRD/prototype and clearly asks to deliver from it, record the actual request as the adoption basis and register the unchanged document as mode input. Check its content and fit; do not invent an approved record or ask the user to approve the same source again. File presence alone is not adoption intent. If intent, scope or a conflict is genuinely unresolved, ask that specific question with its options and impact; use next.questionRef and a blocked current stage. Once answered, record the answer in the existing basis/work material and clear questionRef. No confirmation history or extra approval is needed. A partial-scope or substantively rewritten PRD is this delivery’s AI output and follows normal review.
+
+For reviewable AI outputs (mode new, or mode reused for an existing reviewable output):
+
+1. Write or revise the document while preserving its outline, identities and references. Self-check content, coverage, consistency and the actual entry. Keep work completion separate from self-check and user approval.
 2. Save the self-check record for that version/content. Give the user the document link, a short summary of decisions and unresolved questions, current stage/review status and review focus. Do not give the next-stage continuation prompt while review is pending. Stop for human review. For several interface/SQL files, name and present each document individually; do not ask approval of an unspecified supporting package or introduce a scope-selection interface.
 3. Record an explicit approval with its actual decision source and exact current document version/content. Existing approval of that same content may be recorded without asking again; check it rather than inferring from a file's presence. Save and inspect the result. Stop at the stage boundary; if the message also asks to continue, proceed without another confirmation. Within a multi-document stage, continue preparing the next applicable document after its prerequisite approval. Questions, silence, “continue” alone or “show me the results” are not approval.
 4. Answer questions while retaining the stop. For requested edits, record `changes-requested`, revise, self-check and present again. Neither `done`, an existing file, nor an Agent review substitutes for user approval. A prior explicit decision may be recorded if it really identifies this exact content; never manufacture one from general implementation permission.
@@ -17,10 +21,10 @@ New state has `reviewPolicy: 1` and append-only `reviewHistory`. Use the [CLI re
 
 For new plan/testing templates, approval covers content before the ordinary execution headings mapped to `execution`/`runs` respectively. Subsequent task execution and RUN/conclusion records belong in their later sections; moving changed design into result sections to evade review is forbidden. Other documents and reused formats use the whole registered file. For prototype assets and remotely adopted formats, preserve a readable local fixed-version review basis that identifies every relevant asset/version; report binary/remote inspection limits. Register local/repository linked assets in documents[].assetRefs to bind their bytes; the Agent must check that this set is complete. Do not claim entry-file hashing alone verifies all linked assets.
 
-Stage runs use the agreed array order; by default a run depends on its predecessor. `dependsOn` can state explicit preceding dependencies for independent work, and declared input/output producer links plus earlier selected development prerequisites also apply. Record the reason for changing an arrangement. A pending document holds dependent work; it does not authorize unrelated work outside the commission. `status.md` shows the current stage, pending document, review status and recorded next stage. While review is pending, chat presents only the current document/status and review focus; give the next-work suggestion after approval has been saved and checked. `resume` preserves the same stop and never automatically turns a question or old `done` into approval.
+Stage runs use the agreed array order; by default a run depends on its predecessor. `dependsOn` can state explicit preceding dependencies for independent work, and declared input/output producer links plus earlier selected development prerequisites also apply. Record the reason for changing an arrangement. A pending AI-output review or unresolved input question holds dependent work; it does not authorize unrelated work outside the commission. `status.md` shows the current stage, pending document, review status and recorded next stage. While review is pending, chat presents only the current document/status and review focus; give the next-work suggestion after approval has been saved and checked. `resume` preserves the same stop and never automatically turns a question or old `done` into approval.
 
 ## Changes and old states
 
-Use existing CHG records to explain semantic changes, affected requirements/documents/runs and the real decision source. Change the document version, keep old approvals and necessary old meaning/evidence, mark affected producer/dependent runs `needs-review`, and return to the corresponding document stage. An old approval cannot release new content. After renewed approval, recheck affected downstream work in dependency order and restore applicability with evidence; never clear every result or reset unaffected branches. Update `currentRun`/`next` to the actual re-review stop. Tools cannot infer all semantic dependencies: Agent impact analysis remains necessary.
+Use existing CHG records to explain semantic changes, affected requirements/documents/runs and the real decision source. Change the document version, keep old approvals and necessary old meaning/evidence, mark affected producer/dependent runs `needs-review`, and return to the corresponding document stage. An old approval cannot release new content. For a revised supplied input, record the actual updated adoption basis and check the new content without inventing approval; AI-authored or substantively rewritten outputs require renewed approval. Then recheck affected downstream work in dependency order and restore applicability with evidence; never clear every result or reset unaffected branches. Update `currentRun`/`next` to the actual re-review stop. Tools cannot infer all semantic dependencies: Agent impact analysis remains necessary.
 
-For a formatting/typo-only adjustment, self-check the new digest and append an `editorial` reconciliation that cites the previous approved digest and explains why meaning is unchanged. It carries the old approval without fabricating a new user decision. No full downstream re-review is needed. A changed requirement, case expectation or design choice is never editorial.
+For a formatting/typo-only adjustment to an approved output, self-check the new digest and append an `editorial` reconciliation that cites the previous approved digest and explains why meaning is unchanged. It carries the old approval without fabricating a new user decision. No full downstream re-review is needed. A changed requirement, case expectation or design choice is never editorial.

package/skills/aimship/references/sources-and-changes.md

@@ -4,9 +4,9 @@
 
 Preserve the original request once. If source/request.md changes after initialization, restore its original bytes before continuing state writes; an unrelated update must not adopt a new source digest. Record subsequent intent in the editable PRD and a CHG when meaning changes. If the original cannot be recovered reliably, preserve the conflicting material and report the blocker instead of replacing the recorded basis. Preserve external PRD, prototype, handover-note and image originals at their supplied locations. Retain the adopted versions as described under [location and version discipline](#location-and-version-discipline); neither storing files nor extracting text establishes visual or interaction validation.
 
-Use existing requirement IDs. If none exist, assign local IDs mapped to source sections, pages, prototype screens or short excerpts. A partial-iteration PRD records the current goal, inclusion/exclusion, sources, acceptance, constraints and decisions. A complete applicable PRD is adopted directly. Do not transcribe an entire adequate PRD or create a second one merely to fit a template.
+Use existing requirement IDs. If none exist, assign local IDs mapped to source sections, pages, prototype screens or short excerpts. A partial-iteration PRD records the current goal, inclusion/exclusion, sources, acceptance, constraints and decisions. A complete applicable supplied PRD is adopted directly as mode input when the user’s delivery intent is clear; basisRef preserves that actual request. Source snapshots and adoption/self-check records are not AI deliverable documents to ask the user to review. Do not transcribe an entire adequate PRD or create a second one merely to fit a template.
 
-A prototype and PRD can disagree; neither file type nor modification date automatically wins. Record the conflict and decision authority. Pause dependent work when a material answer is missing, while continuing independent authorized work. Do not contact the external author automatically. If a new version arrives, adopt it separately, assess relevant differences and retain the old basis. Indicate any external document still awaiting its author's correction.
+A prototype and PRD can disagree; neither file type nor modification date automatically wins. Record the conflict and decision authority. Pause dependent work when a material answer is missing, while continuing independent authorized work. Do not contact the external author automatically. If a new version arrives, adopt it separately, assess relevant differences and retain the old basis. A supplied unchanged version uses its actual adoption request and self-check; AI-authored affected outputs return to review, rather than asking for a source approval. Indicate any external document still awaiting its author's correction.
 
 ## Artifact boundaries
 

package/skills/aimship/references/stages/prototype.md

@@ -24,4 +24,6 @@ Use the registered prototype entry (new HTML: prototype/index.html). Follow [doc
 
 ## Human document review
 
-Apply [document review](../document-review.md): generate → self-check → present the concrete document entry, current review status and focus → wait. Record explicit user approval of this version/content, then follow the core session interaction: stop at this stage boundary and suggest a new session; continue here when requested. Approval and continuation may be expressed together. Questions or edit requests retain the stop; edits require self-check and re-review. Production `done` is separate from approval and final acceptance.
+For an unchanged supplied prototype with clear adoption intent, register mode input with the actual request basis, check the applicable content, then save and stop for continuation without a source approval. Report any unverified visual/interaction scope; a copied file is not newly designed or tested. Ask only concrete unresolved questions through next.questionRef.
+
+For AI-authored or substantively changed prototypes, apply [document review](../document-review.md): generate → self-check → present the concrete document entry, current review status and focus → wait. Record explicit user approval of this version/content, then follow the core session interaction: stop at this stage boundary and suggest a new session; continue here when requested. Approval and continuation may be expressed together. Questions or edit requests retain the stop; edits require self-check and re-review. Production `done` is separate from approval and final acceptance.

package/skills/aimship/references/stages/requirements.md

@@ -6,7 +6,7 @@ Read the preserved original input, problem findings, adopted material and curren
 
 ## Work and result
 
-Write the current requirements, important rules, normal/error/boundary behavior, constraints and observable acceptance criteria. Include context and scope, not just a checklist. Link sources; a complete applicable existing PRD is adopted directly without rewriting or renumbering. For partial adoption, write this iteration’s PRD with source, inclusions, exclusions and acceptance. Reuse an evidenced approval of the current content; otherwise ask for requirement confirmation.
+Write the current requirements, important rules, normal/error/boundary behavior, constraints and observable acceptance criteria. Include context and scope, not just a checklist. Link sources; a complete applicable existing PRD is adopted directly without rewriting or renumbering. For partial adoption, write this iteration’s PRD with source, inclusions, exclusions and acceptance. For unchanged supplied input, use the actual delivery request as the adoption basis; no repeated source approval is required. Review AI-authored or substantively revised requirements, reusing evidenced current-content approval when available. Ask only concrete unresolved questions.
 
 ## Continue when
 
@@ -24,4 +24,6 @@ Use the selected PRD requirement entry. For a new PRD preserve the ordinary temp
 
 ## Human document review
 
-Apply [document review](../document-review.md): generate → self-check → present the concrete document entry, current review status and focus → wait. Record explicit user approval of this version/content, then follow the core session interaction: stop at this stage boundary and suggest a new session; continue here when requested. Approval and continuation may be expressed together. Questions or edit requests retain the stop; edits require self-check and re-review. Production `done` is separate from approval and final acceptance.
+Apply [document review](../document-review.md). For unchanged user-supplied requirements with clear adoption intent, register mode input with the real request basis and self-check; report the retained input and newly created records, save and stop for continuation. Do not call it a newly authored PRD, ask for source approval or ask whether to use the standard flow. If a specific uncertainty affects progress, name the question, options and impact, retain a blocked stage and next.questionRef, and stop for clarification.
+
+AI-authored, partially adopted or substantively revised PRDs follow self-check and human review. Present what changed and wait for explicit approval; reuse actual current-content approval where applicable. Approval and continuation may be expressed together. Questions or edit requests retain the review stop. Production done, input adoption, self-check, human approval and final acceptance are distinct.

package/skills/aimship/references/stages/tech-design.md

@@ -8,6 +8,12 @@ Read current requirements, relevant engineering instructions, architecture, sche
 
 Choose an approach with concrete components, dependencies, errors/recovery, compatibility and tradeoffs. Link authoritative contracts instead of duplicating them. For database changes design the data change and the subsequent independent SQL deliverable; explain dialect/version, existing schema basis, conditions and sequence. Do not edit migration files or execute SQL without that commission.
 
+For applicable concurrency and state changes, explain when the business constraint is checked, what enforces it and any remaining window. Keep that guarantee distinct from excluded product interactions; if the requirements leave its meaning unresolved, ask the concrete question. For example, a stock reservation may check and decrement within one transaction; an earlier availability display alone does not guarantee stock at commit.
+
+For a material new database/RPC call on the critical path, describe its location, repeat calls within a request, timeout/failure behavior, cost basis and how feasibility will be checked. Distinguish observed facts, estimates and unknowns; verification should match the actual risk, without invented capacity targets.
+
+Use an ordered explanation for simple flows. Where cross-system calls are hard to follow, a concise architecture or sequence diagram can show transaction boundaries and cache/response order. Explain affected frontend component reuse and state/data flow. Detail the actual tradeoffs; API schemas, executable SQL and full test cases remain in their later deliverables.
+
 ## Continue when
 
 The design can guide the agreed next work and correctness-affecting issues have a clear disposition. Explain the approach and outstanding choices to the user.

package/skills/aimship/references/templates/tech-design.md

@@ -8,23 +8,23 @@ Current requirements and actual engineering constraints. Replace guidance with a
 
 ## Architecture and key flows
 
-Ordered explanation or diagram of the important flow. Replace guidance with actual content; explain inapplicability, never prefill a result.
+Ordered explanation, with a concise diagram when useful to show cross-system calls, transaction boundaries and cache/response order. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
 ## Modules and interaction implementation
 
-Repository ID, responsibility, actual path, new/change, requirement refs; entry/state/data flow for interaction. Replace guidance with actual content; explain inapplicability, never prefill a result.
+Repository ID, responsibility, actual path, new/change, requirement refs; entry/state/data flow and component reuse for affected interaction. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
 ## Data, interfaces and SQL
 
-Structures, indexes, consistency, contract authority, database type/version/schema basis, SQL order and execution boundary. Replace guidance with actual content; explain inapplicability, never prefill a result.
+Structures, indexes, consistency constraints and their decision time/enforcement boundary/remaining windows, contract authority, database type/version/schema basis, SQL order and execution boundary. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
 ## Errors and nonfunctional design
 
-Recovery, access, performance, observability, cache/messages when relevant. Replace guidance with actual content; explain inapplicability, never prefill a result.
+Recovery, access, performance, observability, cache/messages when relevant. For critical-path changes, show call placement/count, timeout/failure behavior, cost basis and a suitable verification method; distinguish facts, estimates and unknowns. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
 ## Tradeoffs and risks
 
-Reasons, alternatives, compatibility and technical risks. Replace guidance with actual content; explain inapplicability, never prefill a result.
+Reasons, meaningful alternatives, compatibility and remaining risks. Keep business guarantees distinct from product exclusions; explain any unresolved meaning as a concrete question. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
 ## Requirement coverage and questions