aimship 0.1.0-preview.20 → 0.1.0-preview.22

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 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.
+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 5 and protocolVersion is 2; 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.
 
@@ -73,8 +73,8 @@ 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, 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.
+- **Single batch:** selected-order export with exact nonnegative safe-integer totals, a stable business batch, separate batch and overall reviews, and independent normal/error assertions. The original synthetic request remains unchanged; current progress is generated into the plan and test/review summaries.
+- **Multiple batches:** shared price validation and quoting, each batch reviewed separately. A known rounding fault fails overall review, and the harness asserts that formal verification cannot start. A maintainer probe preserves its actual failed assertion without labeling it a formal RUN. A separate overall repair and matching recheck then permit formal verification; the repair adds an execution record, not a business batch. Exact source hashes bind the reviewed and tested objects; failure evidence remains available.
 
 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

@@ -7,7 +7,7 @@
 Aimship is for developers who own the result, from a small fix to a feature spanning several repositories. Bring a goal and whatever materials you already have. The agent clarifies requirements, prepares designs, plans implementation batches, reviews the changes and records independent verification. You review the key documents and decisions before dependent work proceeds.
 
 - **Understand the proposal before code changes:** requirements and acceptance criteria connect to the design, tasks and tests.
-- **See what is actually finished:** `status.md` summarizes delivery stages; the plan tracks batch/task progress, reviews track findings, and tests retain actual results.
+- **See what is actually finished:** saved state supplies the delivery stages and current batch, review and test summaries; the documents retain the work definitions, findings and evidence.
 - **Continue without reconstructing the conversation:** saved documents, decisions and state give the next session a starting point. Changes return to the affected design and review.
 
 Aimship manages the delivery process. The agent still needs to investigate, self-check and correct its work; you judge the content and acceptance. Model and AI-tool behavior can vary. **Currently in Preview**; installation or passing tool tests is not proof that every tool/model combination works.
@@ -45,7 +45,7 @@ The [first-use guide](docs/guide.md#start) covers tool activation, access and th
 | --- | --- |
 | `prd.md` | REQ-001: export only selected orders; AC-001: selecting two permitted orders yields exactly those two rows. |
 | `tech-design.md` / applicable contracts | Explain permission enforcement, export limits and error behavior before implementation. |
-| `plan.md` | TASK-001 implements selection and permission checks; its execution status is maintained as batches finish. |
+| `plan.md` | TASK-001 defines selection and permission work in B-001; a generated table shows the batch's implementation and review progress. |
 | `review.md` | Record the reviewed code baseline, findings, impact, fixes and recheck conclusion. |
 | `testing.md` | TC-001 checks AC-001. Execution remains “not run” until a RUN records actual assertions and evidence. |
 | `status.md` | Show the stable delivery stages, current review stop and next action; batch detail stays in the plan. |
@@ -56,6 +56,8 @@ The [first-use guide](docs/guide.md#start) covers tool activation, access and th
 <a id="delivery-workflow"></a>
 A normal delivery follows **requirements → design and applicable contracts/SQL → test design → plan → implementation with batch reviews → overall review → independent verification → acceptance**. Documents are produced as needed. An applicable supplied PRD can be adopted; original materials are retained. A prototype is optional. Key approvals apply to the current content, and completion, passing tests and your acceptance remain separate facts.
 
+Each batch includes its review and authorized repairs, then stops. After the last batch closes, Aimship recommends a new session for the existing overall-review stage; you can explicitly request it in the current session. Formal testing follows overall review, with the agreed test environment prepared by you. This adds no deployment stage or automatic deployment.
+
 See the [guided example](docs/guide.md#start) and [delivery directory reference](docs/guide.md#delivery-structure). Contributors can also [run synthetic deliveries](CONTRIBUTING.md#executable-examples) with actual local assertions; those checks do not establish AI-host behavior.
 
 <a id="update"></a>
@@ -70,9 +72,9 @@ Save current work, then use the same installation command:
 npx aimship@latest install
 ```
 
-Existing tool registrations, configuration, custom content and delivery files are retained. Repeat neither `--host` nor `--data-root` for an ordinary update. There is no background updater. After upgrading, start a new session or refresh the tool's rules, activate Aimship and resume the same delivery directory.
+Existing tool registrations, configuration, custom content and delivery files are retained. Repeat neither `--host` nor `--data-root` for an ordinary update. There is no background updater. After a compatible update, start a new session or refresh the tool's rules, activate Aimship and resume the same delivery directory.
 
-Compatible delivery protocols can continue without rewriting old documents or invalidating unchanged approvals. Legacy Preview 17/18 states are supported by an exact protocol mapping; older unverified states are not assumed compatible. Software installation itself does not change delivery records. For a breaking or unverified protocol switch, the installer explains the impact and stops before changing the active installation. Strongly prefer finishing ongoing deliveries first; explicit risk acceptance is an [advanced recovery option](#installation-troubleshooting), not permission to write unsupported state. The npx download prompt is separate from that decision.
+This workflow uses **state schema 5 / delivery protocol 2**. It does not continue or migrate protocol-1 states, including Preview 17–20 deliveries. Their documents remain readable and installation preserves their files; finish ongoing deliveries with their supported version before upgrading, or start a new delivery under the new workflow. For a breaking or unverified protocol switch, the installer explains the impact and stops before changing the active installation. Explicit risk acceptance is an [advanced option](#installation-troubleshooting), not permission to write unsupported state. The npx download prompt is separate from that decision.
 
 <a id="add-a-host"></a>
 <a id="add-an-ai-development-tool"></a>

package/README.zh-CN.md

@@ -7,7 +7,7 @@
 Aimship 面向对交付结果负责的开发者，适用于小型修复，也适用于跨多个仓库的功能。你提供目标和已有材料，Agent 澄清需求、准备设计、安排实施批次、审查改动并记录独立验证；依赖这些方案的工作推进前，由你审核关键文档与决定。
 
 - **改代码前看懂方案：** 需求与验收标准关联到设计、任务和测试。
-- **看清实际完成情况：** `status.md` 汇总交付阶段，计划维护批次/任务进度，审查记录问题，测试保留真实结果。
+- **看清实际完成情况：** 保存的状态提供交付阶段及当前批次、审查、测试摘要，文档保留工作定义、问题与详细证据。
 - **换会话有据可接：** 保存的文档、决定和状态给下个会话提供起点；需求变化回到受影响的方案和审核。
 
 Aimship 管理交付过程。Agent 仍须调查、自检和修正，你判断内容与验收结果。不同模型和 AI 工具的表现会有差异。**目前处于 Preview 体验阶段**；安装成功或程序测试通过，不代表所有工具/模型组合都已验证。
@@ -45,7 +45,7 @@ npx aimship@latest install --host codex
 | --- | --- |
 | `prd.md` | REQ-001：仅导出选中订单；AC-001：选择两条有权限的订单时，结果恰好包含这两行。 |
 | `tech-design.md`／适用契约 | 实施前解释权限校验、导出限制及错误处理。 |
-| `plan.md` | TASK-001 实现选择与权限检查，批次完成后维护其执行状态。 |
+| `plan.md` | TASK-001 定义 B-001 中的选择与权限工作，生成表展示该批实施与审查进度。 |
 | `review.md` | 记录审查代码基线、问题、影响、修复和复查结论。 |
 | `testing.md` | TC-001 检查 AC-001；RUN 记录实际断言与依据前，执行状态保持“未执行”。 |
 | `status.md` | 展示稳定交付阶段、当前审核停点与下一步；批次明细留在计划中。 |
@@ -56,6 +56,8 @@ npx aimship@latest install --host codex
 <a id="交付流程"></a>
 正常交付依次经过 **需求 → 技术设计及适用契约/SQL → 测试设计 → 计划 → 实施与批次审查 → 整体审查 → 独立验证 → 验收**。按实际需要产出文档；完整适用的已有 PRD 可直接采用，原件保留，原型按需选择。关键批准对应当前内容，阶段完成、测试通过与你的验收保持独立。
 
+每批包含本批审查及授权内修复，闭环后停下。最后一批闭环后，Aimship 建议新开会话执行已有的整体审查阶段；你也可明确要求当前会话执行。整体审查后再正式测试，由你准备约定测试环境，不增加部署阶段或自动部署。
+
 可查看[引导示例](docs/guide.zh-CN.md#start)及[交付目录参考](docs/guide.zh-CN.md#delivery-structure)。开发者还可[运行合成交付](CONTRIBUTING.md#executable-examples)，其中有真实本地断言，但不代表 AI 工具行为已验证。
 
 <a id="update"></a>
@@ -70,9 +72,9 @@ npx aimship@latest install --host codex
 npx aimship@latest install
 ```
 
-已有工具登记、配置、自定义内容和交付文件都会保留。普通更新无需重复 `--host` 或 `--data-root`，没有后台自动升级。升级后新建会话或刷新工具规则，启用 Aimship，继续原交付目录。
+已有工具登记、配置、自定义内容和交付文件都会保留。普通更新无需重复 `--host` 或 `--data-root`，没有后台自动升级。兼容更新后新建会话或刷新工具规则，启用 Aimship，继续原交付目录。
 
-兼容的交付协议可以继续使用，不重写旧文档，也不使未变内容的有效审批失效。Preview 17/18 旧状态通过精确协议映射接续，不推定更早的未验证状态兼容。安装本身不修改交付记录。破坏性或未确认兼容的切换会说明影响，并在修改活动安装前停止。强烈建议先完成进行中的交付；明确接受风险是[高级恢复选项](#installation-troubleshooting)，不代表允许写入不支持的状态。npx 的下载确认与此独立。
+本轮流程使用 **状态 schema 5／交付协议 2**，不接续或迁移协议 1 的状态，包括 Preview 17–20 的交付。旧文档仍可阅读，安装也会保留文件；请先用原支持版本完成进行中的交付，或按新流程新建交付。破坏性或未确认兼容的切换会说明影响，并在修改活动安装前停止。明确接受风险是[高级选项](#installation-troubleshooting)，不代表允许写入不支持的状态。npx 的下载确认与此独立。
 
 <a id="添加宿主"></a>
 <a id="添加-ai-开发工具"></a>

package/docs/cli.md

@@ -32,7 +32,7 @@ node '<stable-launcher>' bind
 node '<fixed-cli>' init '<delivery-dir>' --rules-version '<bound-version>' --input '<init.json>'
 ```
 
-init uses schema 4 and delivery protocol 1, 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, protocolVersion and 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.
+init uses schema 5 and delivery protocol 2, 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, protocolVersion and 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 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.
 
@@ -47,15 +47,38 @@ node '<fixed-cli>' check '<delivery-dir>' --all --rules-version '<bound-version>
 node '<fixed-cli>' resume '<delivery-dir>' --rules-version '<bound-version>'
 ```
 
-Objects merge, arrays replace entirely; null is literal, not deletion. `--input -` accepts stdin JSON. A revision conflict requires rereading and reconciling, not guessing a revision. Keep one writing session per delivery.
+Ordinary metadata objects merge; ordinary arrays replace. Controlled facts (`batches`, `stageRuns`, `reviewHistory`, `openChanges`, `outcome`, `currentRun`) are updated only through an `operations` array. `--input -` accepts stdin JSON. A revision conflict requires rereading and reconciling, not guessing a revision. Keep one writing session per delivery. Init admits empty domain facts, planned runs and active requirement intake; it cannot import completed runs, batches or approvals.
 
-Implementation runs may carry `workType: "batch"|"repair"`; a repair may record `repairOf: ["preceding-run-id"]`. Corrections inside a failed current batch update that batch’s existing implementation checkpoint/evidence and retain its batch purpose; save a new recheck and keep the failed REV. Separate repair work after completed batches is recorded with its actual repair basis. These optional fields describe the actual work unit for display/advice and never remove implementation from review/verification dependencies. Old states need no eager rewrite: untyped work before overall review follows legacy batch meaning when unambiguous; work after overall review or an unresolved review stays unclassified until its actual basis is checked. Never classify by a business ID or name. Reconcile known purpose through an ordinary revision-checked update, preserving documents and approvals.
+### Domain operations
 
-A saved implementation can return advisory session action `continue-implementation-review` and a failed batch review `continue-batch-repair`, both `stop:false` for the current authorized work unit. The next business batch remains stopped until its review passes. Overall review saves its own stop before formal verification; a review request does not execute the test plan. Missing approval, scope clarification, permission, changed documents or failed view saving keep their existing stop. `canProceed` still describes structural forward readiness; a repair hint is not permission to advance a failed dependency. Protocol1/schema4/policy1 and approval fingerprints remain unchanged.
+The agent submits actual facts; the tool evaluates relationships and renders current views. These are internal JSON actions, not new commands users must learn.
 
-When a repair has no recorded review-scope basis, `inspect-review-scope` returns `reviewScope:null`, `nextRun:null` and `stop:false`: inspect the existing plan/original review within the current work unit before selecting batch or overall recheck. Omitting optional `repairOf` remains valid. Neither the next scheduled review nor a non-review basis establishes the original responsibility; this inspection adds no user approval gate.
+| Action | Minimal payload | Purpose |
+| --- | --- | --- |
+| `register-batches` | `batches: [{id,definitionRef,taskRefs,dependsOn}]` | Register stable business B definitions from the current approved plan. The tool binds `planBasis`; started definitions require a revised approved plan and scoped impact. |
+| `record-run` | `run: {id,stage,scope,progress,inputRefs,outputRefs,...}` | Add actual execution or update unfinished work. Completed records remain immutable. Started facts precede future planned entries; a planned run starts in actual execution order. |
+| `remove-planned-run` | `runId` | Remove an unstarted, unreferenced arrangement; started history cannot be removed. |
+| `record-review` | `record: {id,kind,document,version,digest,sourceRef,summary,...}` | Append a current-content self-check, explicit approval, feedback or editorial reconciliation. |
+| `record-change` | `change: {id,ref,status,impactRef?,affectedRefs?}` | Preserve change history and scoped impact; closing a change does not make affected work current. |
+| `record-outcome` | `outcome: {goal?,acceptance?,...}` | Record actual goal conclusion and user acceptance separately. |
+| `set-current` | `runId` | Select an existing run. |
+| `set-applicability` | `runId,applicability,forObjectKey?,assessmentRef?,coverageRefs?` | Reassess actual applicability. Recovery to current binds an explicit object digest and readable assessment; coverageRefs identifies any specifically reassessed test coverage. |
 
-Stage runs are ordered `{id,stage,scope,progress,inputRefs,outputRefs}`. currentRun refers to one ID or null. Progress: planned/active/blocked/done; result: passed/failed/not-run/unknown/mixed; applicability: current/needs-review/unknown. Done requires a precise resultRef. Preserve past results in priorResultRef/historyResultRefs; do not delete started runs. Shared files never complete two runs automatically. Plan must complete before implementation. For standard delivery, review requires completed implementation coverage, verify requires a passing overall review with resolved preceding reviews, and handoff requires passing verification (or a passing rerun retaining earlier results). These required predecessors cannot be removed by empty dependsOn/inputRefs. Actual execution, coverage quality and approval authenticity still require Agent judgment.
+Example after plan approval:
+
+```json
+{"operations":[{"type":"register-batches","batches":[{"id":"B-001","definitionRef":"plan.md#B-001","taskRefs":["plan.md#TASK-001"],"dependsOn":[]}]}]}
+```
+
+Business B identity is separate from execution records. Started implementation requires `workType: "batch"|"repair"`; business work names a registered `batchId`. A repair is a new run for the same B, or an explicitly scoped independent repair, and retains `repairOf`/historical result references. Repairs do not add business batches. A completed engineering run (`implement`, `review`, `verify`) records `objectKey`, a SHA-256 digest of the actual reviewed/executed object basis; a branch name is insufficient. This digest binds recorded facts, not proof that an agent performed the work.
+
+Review records explicitly use `reviewScope: "batch"|"overall"` and `reviewOf` implementation IDs. A batch review covers its actual implementation and repair work; overall review covers all actual implementation including independent repairs. Preserve unsuccessful REV records and link their disposition through `historyResultRefs`. Narrow batch review cannot clear an overall failure. Each batch includes automatic batch review and authorized fixes/recheck, then stops. After the last batch recommend a new session for the existing overall-review stage; explicit user authorization can continue it here. Overall review stops before formal verification.
+
+Formal verify records declare `coverageRefs` against approved TC definitions (or explicitly registered `coverageRefs` on a reused testing document). Optional `coverageResults: [{ref,result}]` records mixed results; otherwise the run result applies to its declared coverage. Later retests link old result references and replace only matching coverage on the currently reviewed object. Prior passing coverage on another object needs a target-bound applicability assessment or a new run. No last-RUN-wins rule; unknown, mixed or untested coverage does not become passed. Development compilation/local self-checks are not formal RUNs.
+
+Progress is `planned|active|blocked|done`; result is `passed|failed|not-run|unknown|mixed`; applicability is `current|needs-review|unknown`. These dimensions remain separate from document approval and user acceptance. `approvalBasis`, `planBasis` and coverage invalidation metadata are tool-managed. Material changes use a current document version plus CHG impact to mark affected work for reassessment; unaffected historical results and approvals remain recorded. New work still needs current prerequisite approvals.
+
+A saved implementation can return `continue-implementation-review`; a failed batch review can return `continue-batch-repair` within existing authorization. Neither starts the next batch. A repair without a known responsibility returns `inspect-review-scope`; inspect its actual basis rather than guessing from a scheduled review. Session advice does not execute work or grant authorization. Explicit limited-scope commissions retain their actual boundary without fabricated full-delivery work.
 
 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.
 
@@ -76,16 +99,16 @@ node '<fixed-cli>' render '<delivery-dir>' --revision '<saved-revision>' --rules
 node '<fixed-cli>' render '<delivery-dir>' --revision '<saved-revision>' --rules-version '<bound-version>' --preserve-edits
 ```
 
-The delivery identity, view digest and state revision are stored in `.aimship/view.json`; identity and revision must both match for a view to be current. Missing/stale views can be regenerated; modified or untrusted existing status is preserved in place by default. --preserve-edits first saves its full bytes to `.aimship/status-edits-<id>.md`, then rebuilds. Inspect the preserved intent and update formal authority separately. View text does not authorize acceptance, scope changes or publication. render does not increment state revision.
+Status and the finite generated H3 areas in new plan/testing/review documents share one state snapshot. AI maintains design, findings, full RUN/REV evidence and execution notes outside those areas. The delivery identity, view digests and state revision are stored in `.aimship/view.json`; identity and revision must both match for a view to be current. Missing/stale views can be regenerated; modified or untrusted existing status is preserved in place by default. --preserve-edits first saves its full bytes to `.aimship/status-edits-<id>.md`, then rebuilds. Finite areas are protected separately; missing or duplicate current-template areas are reported without guessing a legacy layout. Approval evidence is never overwritten by generation. Inspect the preserved intent and update formal authority separately. View text does not authorize acceptance, scope changes or publication. render does not increment state revision.
 
 `recover <dir> --revision <backup-revision> --rules-version <bound-version>` restores only over missing/corrupt state, preserves corrupt bytes and advances revision. It refuses a valid or unknown state. Inspect actual effects afterward, never automatically repeat them. Remove only a stale task lock after confirming no writer exists.
 
 ## Rule updates
 
 
-Bind the active tool and reload its rules before work. The session's `--rules-version`, executing tool and active installation must match exactly. `protocolVersion` separately identifies compatible state, approval and stage semantics; schema/policy validation still applies. Package metadata declares `aimship.protocolVersion`. Current protocol 1 precisely recognizes states from `0.1.0-preview.17` and `0.1.0-preview.18` without a protocol field. No other missing-field version is inferred compatible.
+Bind the active tool and reload its rules before work. The session's `--rules-version`, executing tool and active installation must match exactly. `protocolVersion` separately identifies compatible state, approval and stage semantics; schema/policy validation still applies. Package metadata declares `aimship.protocolVersion`. Current delivery protocol 2 requires schema 5. Historical Preview 17/18 mappings remain fixed at protocol 1 for compatibility identification; they are not promoted to the current protocol. Schema4/protocol1 deliveries cannot be continued or re-rendered with this tool. Preserve their files and complete them with their supported tool before switching, or start a new delivery under the new contract. There is no migration, old-format inference or version-field rewrite.
 
-`rulesVersion` records the last saving tool. Reads/checks/resume and render do not rewrite state or adopt metadata. The next ordinary revision-checked update, or explicit recovery of a supported backup, records protocol 1 and the current saving tool; it preserves documents, delivery identity, progress and approval validity for unchanged content. A schema/policy/protocol mismatch or unrecognized legacy version blocks writes (`PROTOCOL_MISMATCH`); a mixed session/tool/active installation blocks writes (`VERSION_MISMATCH`). Old tools may reject records saved by a newer tool: downgrading is not a document migration or a guarantee of reverse compatibility.
+`rulesVersion` records the last saving tool. Reads/checks/resume and render do not rewrite facts or adopt metadata. A schema/policy/protocol mismatch blocks writes (`PROTOCOL_MISMATCH`); a mixed session/tool/active installation blocks writes (`VERSION_MISMATCH`). Installation confirmation does not permit unsupported state writes. Downgrading does not migrate new records to an older protocol.
 
 The installer compares source/target package declarations, not user deliveries. Compatible switches proceed normally. Breaking or unverified switches return `UPGRADE_CONFIRMATION_REQUIRED` before pending-manifest, entry or active-pointer writes. The JSON includes versions, compatibility, actual impact and recovery; it does not claim to know which deliveries are ongoing. There is no interactive prompt. To explicitly accept the reported installation risk, rerun the same target package's `install --accept-upgrade-risk`. `npx --yes` is only npm's package-download/run consent. Acceptance does not bypass unsupported delivery writes. Interrupted accepted installs record that acceptance in the pending manifest and resume using the same exact package. Reinstalling the active version needs no new protocol decision. Legacy targets with exact software-version guards can still block continuation despite matching semantic protocol.
 
@@ -95,15 +118,15 @@ Goal changes need a new goal.decisionRef; prior goals/outcomes are retained. A m
 
 ## Document review protocol
 
-Schema 4 requires `reviewPolicy: 1`, append-only `reviewHistory` and `deliveryPolicy: {version: 1}`. Document approvals remain bound to document version/content; business item numbers do not replace them.
+Schema 5 requires `reviewPolicy: 1`, append-only `reviewHistory` and `deliveryPolicy: {version: 1}`. Document approvals remain bound to document version/content; business item numbers do not replace them.
 
-Each record has `{id, kind, document, version, digest, sourceRef, summary}`. Kinds are `self-check`, `approved`, `changes-requested`, and `editorial`. `self-check` requires `result: "passed"` or `"failed"`; only a passing self-check can support approval. `approved` additionally requires `decision: "explicit-approval"`; `editorial` requires `previousDigest`. Use unique local review-record IDs (for example `approval-1`); these are state record identifiers, not a replacement for REQ/AC/CHG. Send the complete preserved history plus new records through revision-checked `update`. Existing records cannot be edited, removed or reordered. The tool records `sourceDigest` from readable local or repo-relative evidence; keep it unchanged when sending history back. Evidence files are versioned/immutable: changed or missing evidence produces evidence-changed and does not release dependencies; preserve the original bytes and add new decisions in new evidence files. Evidence fragments locate unique ordinary headings or numbered records, not HTML anchors. A remote source must have a local preserved decision excerpt with its original locator and date.
+Each record has `{id, kind, document, version, digest, sourceRef, summary}`. Kinds are `self-check`, `approved`, `changes-requested`, and `editorial`. `self-check` requires `result: "passed"` or `"failed"`; only a passing self-check can support approval. `approved` additionally requires `decision: "explicit-approval"`; `editorial` requires `previousDigest`. Use unique local review-record IDs (for example `approval-1`); these are state record identifiers, not a replacement for REQ/AC/CHG. Append new records through `record-review` in a revision-checked `update`. Existing records cannot be edited, removed or reordered. The tool records `sourceDigest` from readable local or repo-relative evidence; keep it unchanged when sending history back. Evidence files are versioned/immutable: changed or missing evidence produces evidence-changed and does not release dependencies; preserve the original bytes and add new decisions in new evidence files. Evidence fragments locate unique ordinary headings or numbered records, not HTML anchors. A remote source must have a local preserved decision excerpt with its original locator and date.
 
 `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.
 
 Nonblocking questions remain in their formal document with impact and resolution timing. Use `next.questionRef` only for a current blocker; approving a document does not resolve every question.
 
-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.
+Production `progress: done` may be saved while approval is pending. Starting/completing dependent runs is blocked until prerequisite completion and document approval are current. Design runs default to the preceding applicable design responsibility, not a later execution run during rework; engineering work uses the domain relationships (business dependencies, reviewOf, formal coverage and reviewed object), with explicit `dependsOn` for actual additional prerequisites. 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.
 
@@ -121,7 +144,7 @@ An explicit limited-scope decision (including no cases and testing) is reference
 
 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.
+Reviews identify their actual implementation coverage with `reviewOf: [implementationRunId, ...]`; overall review uses `reviewScope: "overall"`; batch review uses `reviewScope: "batch"` with its business batchId. They remain separate responsibilities and records. 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` remains advisory context, not permission to cross stages. Each user-visible work unit finishes its work/self-check, saves artifacts and stops; implementation/review checkpoints inside one batch follow the scoped continuation advice above: `session.action` is await-review for required approval or await-continue for a completed stage awaiting continuation; `stop` and `suggestNewSession` make that advice explicit. `suggestNewSession` is true only at major work boundaries: requirements to design, design/applicable contracts to test design, plan to implementation, batch review to the next batch/overall review, and overall review to independent verification. Pending review remains the current task; a suggestion never skips it. 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”.
 

package/docs/examples.md

@@ -3,3 +3,7 @@
 The synthetic examples are developer checks. Their instructions and coverage now live in [Contributing](../CONTRIBUTING.md#executable-examples).
 
 For everyday use, see the [Guide](guide.md) or [中文使用指南](guide.zh-CN.md).
+
+The guide's sign-up/login walkthrough and the README's order-export excerpts are illustrative. A real batch ends after implementation, batch review and authorized repairs; overall review is a separate saved scope after all batches close, followed by formal testing in the prepared environment.
+
+Current-work summaries in `status.md` and the limited generated sections of `plan.md`, `review.md` and `testing.md` come from saved state. Task definitions, findings and execution evidence remain in the document body. The current workflow uses schema 5 / protocol 2; historical protocol-1 documents remain readable but their states are not migrated or continued by the new tool. See [upgrade guidance](guide.md#guide-upgrade).

package/docs/guide.md

@@ -147,7 +147,7 @@ The AI rechecks access to the same delivery directory, reads its state and confi
 
 **User actions:** Supply the project location and known test conditions. Open the design, check password protection, login state, access control and data changes, then approve or give feedback.
 
-**AI processing:** Reads the project, checks technical conditions and designs the implementation and risk handling. It resolves missing essential facts and prepares interfaces/SQL after design approval.
+**AI processing:** Reads the relevant current project behavior and applicable project conventions, then designs the implementation and risk handling. A project without convention files proceeds normally. The AI investigates discoverable facts itself; only decisions that need your judgment are raised, with nonblocking questions left until they are needed. Applicable interfaces and SQL follow design approval.
 
 **Outputs:** `tech-design.md` explains the implementation and tradeoffs. It plans later SQL; finished SQL is not required at this point.
 
@@ -158,7 +158,7 @@ The AI rechecks access to the same delivery directory, reads its state and confi
 
 **User actions:** For the interface review, check requests, responses, errors and authentication. For SQL, check the target database, structure, change order and execution conditions. Approve or request changes separately.
 
-**AI processing:** Prepares applicable documents from the approved design, self-checks each and waits for review. Test design follows their approval. Existing authoritative contracts are reused; no relevant change means no file, and multiple databases have separate SQL.
+**AI processing:** Prepares applicable documents from the approved design, relevant existing contracts and project conventions, self-checks each and waits for review. Test design follows their approval. Existing authoritative contracts are reused; no relevant change means no file, and multiple databases have separate SQL.
 
 **Outputs:** This example's `openapi.yaml` defines HTTP interfaces; `database.sql` describes single-database changes. **Document approval does not authorize SQL execution or changes to migration mechanisms.**
 
@@ -191,18 +191,20 @@ The AI rechecks access to the same delivery directory, reads its state and confi
 
 **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 one batch, performs appropriate local checks, reviews it and repairs/rechecks within the authorized scope. Implementation and review are saved separately; the AI reports and stops at batch closure, not between those internal steps. Continuation advances only after blocking issues are resolved. All batches are followed by overall review, then verification. Requirement changes return to the relevant review.
+**AI processing:** Implements one batch, performs appropriate local checks, automatically reviews the batch and repairs/rechecks within the authorized scope. Implementation and review are saved separately; the AI reports and stops at batch closure, without starting the next batch. Compilation and type checks are development checks; they do not replace review or formal testing, and a complete test suite is not required after every batch. Requirement changes return to the relevant review.
 
-**Outputs:** Project code, one maintained batch progress table (including review status) in the plan execution section, and findings/repairs in `review.md`. Development checks are brief notes and evidence references; formal test results belong to later verification.
+For independent work with useful separation and no conflicting writes, the AI may use the host's existing subagent tools. It supplies relevant approved designs, contracts and project conventions, collects the results and checks integration before the batch review. Small work or hosts without delegation proceed serially; no extra plugin or setup is required.
+
+**Outputs:** Project code, a state-generated batch progress table (including review status) in the plan execution section, and findings/repairs in `review.md`. Development checks are brief notes and evidence references; formal test results belong to later verification. After the last batch closes, the AI summarizes implementation and recommends a new session for overall review. It continues overall review in the same session only when you explicitly request it.
 
 <a id="guide-overall"></a>
 <a id="19-review-the-complete-change"></a>
 
 ### 1.8 Review the complete change
 
-**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.
+**User actions:** Start the recommended new session for overall review, or explicitly ask to perform it in the current session. Read the findings and remaining issues, pointing out omissions if needed. Review records do not need a separate document approval.
 
-**AI processing:** Checks all actual changes and connections across sign-up, login, logout and home-page access. It records findings and the reviewed object, saves the conclusion and stops before verification; an overall-review request alone does not run a full test suite. Authorized repairs return for recheck. 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, including requirement/design/contract consistency and logic, transaction and exception defects. It records findings and the reviewed object, saves the conclusion and stops before formal testing. Authorized repairs return for recheck. This is the existing code-review stage, not an added phase. Even for one batch, batch review and overall review have separate saved scopes and the batch stop remains in place.
 
 **Outputs:** Overall conclusions appended to `review.md`. Code review does not replace running tests.
 
@@ -211,9 +213,9 @@ The AI rechecks access to the same delivery directory, reads its state and confi
 
 ### 1.9 Run verification and handle failures
 
-**User actions:** Provide the agreed isolated test environment, read execution results and supply reproduction details or missing conditions. Separately authorized operations need an explicit target and action.
+**User actions:** After overall review passes, prepare the agreed isolated test environment, including deployment to it when the project needs that. Read execution results and supply reproduction details or missing conditions. Aimship does not add a deployment stage or deploy automatically; separately authorized operations need an explicit target and action.
 
-**AI processing:** Runs cases against reviewed code, distinguishing passed, failed and unexecuted checks. It reviews fixes and retests while retaining failure history; requirement/design issues return to the relevant materials.
+**AI processing:** Runs formal cases against the reviewed object in the agreed environment, distinguishing passed, failed and unexecuted checks. It reviews fixes and retests while retaining failure history. A partial retest updates only its actual coverage; other results need to remain applicable or be checked again. Requirement/design issues return to the relevant materials. Local development checks do not become formal results merely because they ran earlier.
 
 **Outputs:** Actual code, environment, results and evidence appended to the same `testing.md`. Missing necessary verification is reported, not marked passed.
 
@@ -256,13 +258,15 @@ The AI rechecks access to the same delivery directory, reads its state and confi
 
 ### 2.1 When to switch sessions
 
-Consider a new session after requirements before technical design, after design and applicable contracts before test design, after the plan before implementation, after each batch and its review, and after overall review before independent verification. Combine coinciding boundaries. Resume pending review before advancing; directory creation and small steps within a stage need no session change.
+Consider a new session after requirements before technical design, after design and applicable contracts before test design, after the plan before implementation, after each batch and its review, and after overall review before independent verification. After the final batch, a new session is recommended for overall review; continuing that review here needs your explicit request. Combine coinciding boundaries. Resume pending review before advancing; directory creation and small steps within a stage need no session change.
 
 Review open questions with their document, including impact, recommendation and when an answer is needed. Nonblocking questions can remain open; document approval does not answer every question.
 
 At each completed stage, follow the stop in `status.md`: approve or give feedback on pending documents, or ask to continue completed work. Changing sessions is optional; “continue” does not approve a pending document. The page prioritizes current actions and shows future stages as not started, not current defects.
 
-`status.md` summarizes stable delivery stages; batch reviews belong to implementation, with overall review shown separately. Read `plan.md` for current batch/task status and remaining implementation, `review.md` for findings, repairs and rechecks, and `testing.md` for cases, execution records and the latest verification conclusion. Routine progress updates preserve approval of unchanged plans/cases. Formal artifacts are linked from status; detailed internal evidence is available where a document references it.
+`status.md` and the limited generated sections in new native `plan.md`, `review.md` and `testing.md` use the same saved state. The plan's generated table shows business batches, implementation and batch review; review's generated summary shows current batch/overall conclusions; testing's generated summary shows effective results and coverage still to check. The AI maintains task definitions, detailed findings, full RUN evidence and explanations in the surrounding document sections. You do not maintain a second status table by hand. Adopted document formats are preserved rather than rewritten to add these sections.
+
+Batch reviews belong to implementation; status shows one overall-review phase. Routine progress or generated-section updates preserve approval of unchanged plan/test definitions. Material changes are assessed for their actual impact, retaining unaffected work and historical results. Editing a generated summary does not record a completion or approval; modified generated content is preserved for reconciliation. A failed view refresh is repaired from saved state without repeating the recorded review or test.
 
 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.
 
@@ -402,7 +406,7 @@ For duplicate entries, check their sources and versions while preserving custom
 
 Save current work before [upgrading through the README](../README.md#update). Activate Aimship again afterward and check the actual bound version and delivery state; installation itself does not update delivery records.
 
-Compatible protocol updates preserve existing documents and approvals of unchanged content; the next normal save records the current software version. Preview 17/18 states have a verified mapping. Unknown protocols remain blocked. If installation reports a breaking or unverified switch, finish ongoing deliveries before upgrading; accepting that risk never bypasses delivery-state protection. Use ordinary Markdown and searchable numbers, preserve actual test records and inspect the impact of substantive changes.
+This workflow requires state schema 5 / delivery protocol 2. It does not continue or migrate protocol-1 deliveries, including Preview 17–20 states. Their documents remain readable and installation preserves them. Finish ongoing work with its supported version before upgrading, or start a new delivery under this workflow; do not edit version fields to force continuation. The installer reports a breaking or unverified switch and stops by default before changing the active installation. Accepting installation risk does not permit unsupported state writes.
 
 <a id="45-installation-and-maintenance-references"></a>
 <a id="installation-and-maintenance-references"></a>

package/docs/guide.zh-CN.md

@@ -145,7 +145,7 @@ AI 重新核对同一交付目录的访问，读取状态并确认下一步技
 
 **用户操作**：提供工程位置及已知测试条件；打开方案，检查密码保护、登录状态、访问控制和数据变更，明确通过或反馈。
 
-**AI 处理**：读取工程，核对技术条件，设计实现方式及风险处理；缺少关键事实先补齐，方案批准后准备接口与 SQL。
+**AI 处理**：读取相关工程现状和适用项目约定，设计实现方式及风险处理；项目没有规范文件也正常推进。能调查的事实自行查清，只有需要你实质判断的决定才提问，不影响下一步的问题可留到需要时解决。方案批准后准备适用接口与 SQL。
 
 **输出产物**：`tech-design.md` 说明怎样实现及取舍。此时设计后续 SQL，不要求 SQL 文件已经完成。
 
@@ -156,7 +156,7 @@ AI 重新核对同一交付目录的访问，读取状态并确认下一步技
 
 **用户操作**：接口送审时检查请求、响应、错误与登录要求；SQL 送审时检查目标库、结构、变更顺序及执行条件，分别通过或要求修改。
 
-**AI 处理**：依据已批准方案准备适用文档，逐份自检并等待审核；全部通过后进入测试设计。已有权威契约复用，无对应变更不生成文件，多数据库分别提供 SQL。
+**AI 处理**：依据已批准方案、相关现有契约和适用项目约定准备文档，逐份自检并等待审核；全部通过后进入测试设计。已有权威契约复用，无对应变更不生成文件，多数据库分别提供 SQL。
 
 **输出产物**：本例 `openapi.yaml` 约定 HTTP 接口，`database.sql` 描述单库变更。**文档批准不授权执行 SQL 或修改迁移机制。**
 
@@ -189,18 +189,20 @@ AI 重新核对同一交付目录的访问，读取状态并确认下一步技
 
 **用户操作**：查看改动和进度，有偏离及时指出，如“注册成功后的跳转与原型不一致”。无需逐条批准执行日志；阶段结束查看结果后可要求继续。
 
-**AI 处理**：完成一批实现、按风险做必要本地检查，接着本批审查及授权内修复复查。实现和审查分别保存，在批次闭环后再报告停下，不在内部衔接处多等一次继续；实际依赖受阻时停在该问题。全部批次完成后安排整体审查，再统一验证；需求变化回到相应审核。
+**AI 处理**：完成一批实现、按风险做必要本地检查，自动执行本批审查及授权内修复复查。实现和审查分别保存，在批次闭环后报告停下，不自动开始下一批；实际依赖受阻时停在该问题。编译和类型检查属于开发自检，不代替审查或正式测试，也不要求每批跑完整测试集。需求变化回到相应审核。
 
-**输出产物**：工程代码；`plan.md` 执行区维护唯一批次进度表（含review状态），`review.md` 记录问题与修复；开发自检仅简记并引用证据，正式测试结果留后续验证。
+存在适合独立分工且写入不冲突的工作时，AI 可使用宿主已有子 agent 工具，提供相关批准设计、契约和项目约定，收齐结果并核对集成后完成批次审查。小任务或宿主不支持委派时正常串行，无需额外插件或设置。
+
+**输出产物**：工程代码；`plan.md` 执行区由状态生成批次进度表（含 review 状态），`review.md` 记录问题与修复；开发自检仅简记并引用证据，正式测试结果留后续验证。最后一批闭环后，AI 汇总实施结果，建议新开会话执行整体审查；只有你明确要求，才在当前会话继续整体审查。
 
 <a id="guide-overall"></a>
 <a id="19-整体-review"></a>
 
 ### 1.8 整体 review
 
-**用户操作**：查看整体结论和遗留问题，必要时指出遗漏；不需要为审查记录另做文档批准，查看结论后可要求继续。
+**用户操作**：按建议新开会话执行整体审查，或明确要求在当前会话执行。查看结论和遗留问题，必要时指出遗漏；不需要为审查记录另做文档批准。
 
-**AI 处理**：检查全部实际改动及注册、登录、退出、首页访问的跨批衔接，记录问题和当前对象，保存结论并停下；仅请求整体审查不会自动执行全面测试，授权修复后回到复查，之后才是正式验证。单批可用一份 review 明确覆盖批内及整体范围。
+**AI 处理**：检查全部实际改动及注册、登录、退出、首页访问的跨批衔接，包括需求/设计/契约一致性以及逻辑、事务和异常缺陷，记录问题和当前对象，保存结论后停下，不自动进入正式测试。授权修复后回到复查。这就是已有代码审查阶段，不是新增阶段。即使只有一批，批次审查和整体审查也分别保存范围，仍保留批次停点。
 
 **输出产物**：`review.md` 追加整体审查结论。代码审查不能代替运行测试。
 
@@ -209,9 +211,9 @@ AI 重新核对同一交付目录的访问，读取状态并确认下一步技
 
 ### 1.9 执行验证并处理失败
 
-**用户操作**：提供约定的隔离测试环境，查看执行结果，补充复现信息或缺失条件；另需授权的操作先明确目标与动作。
+**用户操作**：整体审查通过后，准备约定的隔离测试环境；工程需要部署到该环境时，由你先完成准备。查看执行结果，补充复现信息或缺失条件。Aimship 不增加部署阶段或自动部署；另需授权的操作先明确目标与动作。
 
-**AI 处理**：对已 review 的代码执行用例，分别记录通过、失败、未执行。缺陷修复后审查并复测，保留失败历史；需求或设计问题回到相应材料。
+**AI 处理**：在约定环境中对已审查对象正式执行用例，分别记录通过、失败、未执行。缺陷修复后审查并复测，保留失败历史；局部重测只更新实际覆盖的部分，其他结果需仍适用或重新核对。需求或设计问题回到相应材料。先前做过的开发自检不会直接变成正式测试结果。
 
 **输出产物**：同一 `testing.md` 追加实际代码、环境、结果与证据。缺少必要验证时如实列出，不写成通过。
 
@@ -258,9 +260,11 @@ AI 重新核对同一交付目录的访问，读取状态并确认下一步技
 
 每阶段完成后按 `status.md` 的停点处理：AI 产出待审则批准或反馈，有具体疑问则回答问题，已完成则要求继续。无需每次都换会话；“继续”不替代待审材料的批准。进度页先展示当前操作，尚未开始的后续阶段不会当作当前缺项。
 
-`status.md` 汇总稳定交付主阶段，批次审查归入实施，整体审查单独显示。当前批次、任务状态和剩余实施看 `plan.md`；问题、修复和复查看 `review.md`；用例、执行记录和最新验证结论看 `testing.md`。普通进度更新保留未变计划和用例的有效批准。status 链接正式成果，详细内部证据在相关文档需要时引用。
+`status.md` 和新原生 `plan.md`、`review.md`、`testing.md` 中有限的生成区使用同一份已保存状态。计划生成表展示业务批次、实施和批审进度；审查生成摘要展示当前批次/整体结论；测试生成摘要展示有效结果及待测、待核对覆盖。AI 在其余正文中维护任务定义、详细问题、完整 RUN 证据和说明，不再手工维护另一份状态表。采用的已有文档保留原格式，不为添加生成区而重写。
+
+批次审查归入实施，总阶段表只显示一个整体审查阶段。普通执行记录或生成区刷新保留未变计划/用例定义的有效批准；实质变更按实际影响复核，保留未受影响的工作与历史结果。手改生成摘要不等于记录完成或批准，修改内容会先保留再协调；视图刷新失败时从已保存状态补生成，不重复记录审查或测试。
 
-建议在需求完成进入技术设计、设计及适用契约完成进入测试、计划完成进入实施、每批实施及审查完成、整体审查完成进入独立验证时换会话。重合的节点只提示一次；待审时先接续审核，单独创建目录或阶段内的小步骤不需要换窗。
+建议在需求完成进入技术设计、设计及适用契约完成进入测试设计、计划完成进入实施、每批实施及审查完成、整体审查完成进入独立验证时换会话。最后一批后建议新会话执行整体审查，明确要求后也可当前继续。重合的节点只提示一次；待审时先接续审核，单独创建目录或阶段内的小步骤不需要换窗。
 
 新会话操作见[演示中的续接示例](#guide-session-example)。同一交付只保留一个写入会话；可信记录可直接定位，找不到或有多个候选才询问。交付语言沿用已保存设置。首次保存前就要切换时，携带未保存诉求、计划位置及未完成操作。
 
@@ -400,7 +404,7 @@ AI 只能核对已知且可访问的交付，不会自动锁定或调度其他
 
 升级前保存当前工作，再按 README [升级](../README.zh-CN.md#update)。升级后重新启用 Aimship，核对实际绑定版本和交付状态；安装本身不会更新交付记录。
 
-兼容协议更新保留已有文档及未变内容的有效审批，下一次正常保存才记录当前软件版本。Preview 17/18 状态有已验证映射，未知协议仍会受阻。安装提示破坏性或未确认兼容时，先完成进行中的交付再升级；明确接受安装风险也不放开交付状态保护。继续使用普通 Markdown 和可搜索编号，保留实际测试记录，实质变更仍核对影响。
+本轮流程要求状态 schema 5／交付协议 2，不接续或迁移协议 1 的交付，包括 Preview 17–20 的状态。旧文档仍可阅读，安装会保留文件。请先用原支持版本完成进行中的交付，或按新流程新建交付，不手改版本字段强行接续。安装器会说明破坏性或未确认兼容的切换影响，默认在更改活动安装前停止；接受安装风险不代表允许写入不支持的交付状态。
 
 <a id="45-安装与维护参考"></a>
 <a id="安装与维护参考"></a>