aimship 0.1.0-preview.17 → 0.1.0-preview.18

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

package/docs/guide.md

@@ -262,6 +262,8 @@ Review open questions with their document, including impact, recommendation and
 
 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.
+
 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.
 
 <a id="22-continue-after-work-stops-unexpectedly"></a>

package/docs/guide.zh-CN.md

@@ -258,6 +258,8 @@ AI 重新核对同一交付目录的访问，读取状态并确认下一步技
 
 每阶段完成后按 `status.md` 的停点处理：AI 产出待审则批准或反馈，有具体疑问则回答问题，已完成则要求继续。无需每次都换会话；“继续”不替代待审材料的批准。进度页先展示当前操作，尚未开始的后续阶段不会当作当前缺项。
 
+`status.md` 汇总稳定交付主阶段，批次审查归入实施，整体审查单独显示。当前批次、任务状态和剩余实施看 `plan.md`；问题、修复和复查看 `review.md`；用例、执行记录和最新验证结论看 `testing.md`。普通进度更新保留未变计划和用例的有效批准。status 链接正式成果，详细内部证据在相关文档需要时引用。
+
 建议在需求完成进入技术设计、设计及适用契约完成进入测试、计划完成进入实施、每批实施及审查完成、整体审查完成进入独立验证时换会话。重合的节点只提示一次；待审时先接续审核，单独创建目录或阶段内的小步骤不需要换窗。
 
 新会话操作见[演示中的续接示例](#guide-session-example)。同一交付只保留一个写入会话；可信记录可直接定位，找不到或有多个候选才询问。交付语言沿用已保存设置。首次保存前就要切换时，携带未保存诉求、计划位置及未完成操作。

package/lib/view.mjs

@@ -27,6 +27,22 @@ async function available(directory,state,ref) {
   if (/^https?:\/\//.test(ref)) return true;
   const p=resolveRef(directory,state,ref); return p && await exists(p);
 }
+// Runs retain execution history; the user sees one row per delivery responsibility.
+const batchReview = (state,r) => r.stage==='review' && r.overall!==true && r.reviewOf?.some(id=>state.stageRuns.some(x=>x.id===id && x.stage==='implement'));
+const phaseOf = (state,r) => batchReview(state,r)?'implement':r.stage;
+function phaseOrder(state) {
+  const selected=[...new Set(state.stageRuns.map(r=>phaseOf(state,r)))];
+  if(state.deliveryPolicy.partialRef)return selected;
+  const order=['requirements','tech-design','contract','test-design','plan','implement','review','verify','handoff'];
+  if(state.documentPolicy.interface==='none' && state.documentPolicy.databases?.length===0 && !selected.includes('contract'))order.splice(order.indexOf('contract'),1);
+  for(const stage of selected.filter(s=>!order.includes(s))) {
+    const at=state.stageRuns.findIndex(r=>phaseOf(state,r)===stage);
+    const next=state.stageRuns.slice(at+1).map(r=>phaseOf(state,r)).find(s=>order.includes(s));
+    const prior=state.stageRuns.slice(0,at).map(r=>phaseOf(state,r)).findLast(s=>order.includes(s));
+    order.splice(next?order.indexOf(next):prior?order.indexOf(prior)+1:0,0,stage);
+  }
+  return order;
+}
 export async function renderText(directory,state) {
   const t=(en,zh)=>text(state,en,zh), v=x=>cell(displayValue(state,x));
   const artifactLink=ref=>ref.startsWith('repo:')
@@ -37,46 +53,70 @@ export async function renderText(directory,state) {
   const current=state.stageRuns.find(r=>r.id===state.currentRun) ?? state.stageRuns.at(-1);
   const currentReview=review.runs.find(r=>r.id===current?.id);
   const humanDocs=review.documents.filter(d=>currentReview?.documents.includes(d.path));
-  const failed=r=>['failed','mixed','unknown','not-run'].includes(r.result);
+  const failed=r=>['failed','mixed'].includes(r.result);
   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(r.result==='unknown' && !check?.resolvedBy)return t('Result not yet known','结果尚未确定');
+    if(r.result==='not-run' && !check?.resolvedBy)return t('Not run','未执行');
+    if(r.stage==='review' && r.progress==='done' && !r.result && !check?.resolvedBy)return t('Review result not recorded','审查结果未记录');
     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 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 phaseName=stage=>stage==='review' && (!state.deliveryPolicy.partialRef || state.stageRuns.some(r=>r.stage==='implement' || r.overall===true))?t('Overall review','整体审查'):v(stage);
+  const runName=r=>batchReview(state,r)?t('implement · Batch review','实施 · 批次审查'):phaseName(r.stage);
+  const phaseProgress=stage=> {
+    const all=state.stageRuns.filter(r=>phaseOf(state,r)===stage);
+    const runs=all.filter(r=>!review.runs.find(x=>x.id===r.id)?.resolvedBy);
+    if(!runs.length || runs.every(r=>r.progress==='planned'))return stage==='contract' && (state.documentPolicy.interface===null || state.documentPolicy.databases===null)?t('Applicability to be determined during design','待技术设计确认是否适用'):t('Not started','尚未开始');
+    const pending=r=>r.progress!=='planned' && (r.progress!=='done' || progress(r)!==t('Completed','已完成') && progress(r)!==t('Provided material adopted','已采用现有材料'));
+    const attention=runs.filter(pending);
+    if(attention.length)return progress(attention.find(r=>r.id===state.currentRun)??attention.at(-1));
+    if(runs.some(r=>r.progress==='planned'))return t('In progress','进行中');
+    if(stage==='implement') {
+      const batches=state.stageRuns.filter(r=>r.stage==='implement');
+      const covered=batches.filter(b=>state.stageRuns.some(r=>r.stage==='review' && r.reviewOf?.includes(b.id) && state.stageRuns.indexOf(r)>state.stageRuns.indexOf(b) && review.runs.find(x=>x.id===r.id)?.releaseReady && r.result==='passed')).length;
+      return covered===batches.length?t(`Recorded batches completed: ${batches.length}; batch reviews passed`,`已记录批次完成 ${batches.length}；批次审查通过`):t(`Recorded batches completed: ${batches.length}; batch review pending`,`已记录批次完成 ${batches.length}；待批次审查`);
+    }
+    // A previous overall conclusion cannot cover later implementation work.
+    if(stage==='review' && state.stageRuns.some(r=>r.stage==='implement')) {
+      const batches=state.stageRuns.filter(r=>r.stage==='implement');
+      if(!runs.some(r=>r.overall===true && batches.every(b=>r.reviewOf?.includes(b.id) && state.stageRuns.indexOf(r)>state.stageRuns.indexOf(b))))return t('Review required for current batches','当前批次待整体审查');
+    }
+    return runs.every(r=>progress(r)===t('Provided material adopted','已采用现有材料'))?t('Provided material adopted','已采用现有材料'):t('Completed','已完成');
+  };
   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):''}`);
+  lines.push(`${t('Current stage','当前阶段')}: ${current?runName(current):v('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 document above and approve it or give feedback.','请查看上方文档，通过或反馈修改。'));
   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)','（批准后）'):''}`);
+  if(next && current?.progress==='done' && !['resolve-current','finished','assess-outcome'].includes(session.action)) {
+    const scheduled=state.stageRuns[state.stageRuns.indexOf(current)+1];
+    const label=scheduled?runName(scheduled):next==='review'?(current.stage==='implement'?t('implement · Batch review','实施 · 批次审查'):t('Overall review','整体审查')):phaseName(next);
+    lines.push('',`${t('After this stop','当前停点处理后')}: ${label}${session.action==='await-review'?t(' (after approval)','（批准后）'):''}`);
+  }
   const problems=[];
   if(current && current.progress!=='planned') {
     if(current.progress==='blocked')problems.push(cell(current.scope));
     if(currentReview?.blockedBy.length)problems.push(t('Current prerequisites need completion or approval.','当前前置工作需要完成或批准。'));
     if(failed(current) && !currentReview?.resolvedBy)problems.push(t('Resolve the recorded unsuccessful result before advancing.','请先处理当前未通过的结果，再推进。'));
+    if(['unknown','not-run'].includes(current.result) && !currentReview?.resolvedBy && !state.next.questionRef)problems.push(current.result==='unknown'?t('The current result is not yet known; follow the recorded next action.','当前结果尚未确定，请按已记录的下一步处理。'):t('The current work has not been run; follow the recorded next action.','当前工作尚未执行，请按已记录的下一步处理。'));
     if(['needs-review','unknown'].includes(current.applicability))problems.push(t('Reassess the affected current work.','请复核当前受影响的工作。'));
   }
   for(const ref of changed)problems.push(`${t('Changed or missing material','材料已变化或缺失')}: ${artifactLink(ref)}`);
   for(const c of state.openChanges.filter(c=>c.status==='open'))problems.push(`${t('Open change','待处理变更')}: ${artifactLink(c.ref)}`);
   if(review.evidenceIssues.length)problems.push(t('Recorded review evidence needs checking.','已记录的审核依据需要核对。'));
   if(problems.length)lines.push('',t('## Items to resolve','## 当前待处理事项'),'',...problems.map(p=>'- '+p));
-  lines.push('',t('## Delivery progress','## 整体进度'),'',t('| Stage / work | Status |','| 阶段／工作 | 状态 |'),'| --- | --- |');
-  for(const r of state.stageRuns)lines.push(`| ${v(r.stage)} · ${cell(r.scope)} | ${progress(r)} |`);
-  if(!state.deliveryPolicy.partialRef)for(const stage of ['requirements','tech-design','contract','test-design','plan','implement','review','verify','handoff']) {
-    if(state.stageRuns.some(r=>r.stage===stage))continue;
-    if(stage==='contract' && state.documentPolicy.interface==='none' && state.documentPolicy.databases?.length===0)continue;
-    const unknown=stage==='contract' && (state.documentPolicy.interface===null || state.documentPolicy.databases===null);
-    lines.push(`| ${v(stage)} | ${unknown?t('Applicability to be determined during design','待技术设计确认是否适用'):t('Not started','尚未开始')} |`);
-  }
+  lines.push('',t('## Delivery progress','## 整体进度'),'',t('| Stage | Status |','| 阶段 | 状态 |'),'| --- | --- |');
+  for(const stage of phaseOrder(state))lines.push(`| ${phaseName(stage)} | ${phaseProgress(stage)} |`);
   lines.push('',`${t('Delivery conclusion','交付结论')}: ${v(completion.status)}`);
   // Full completion diagnostics matter at handoff, not as a list of early-stage defects.
   if(current?.stage==='handoff' || state.outcome.goal==='met')lines.push(...completion.gaps.map(g=>'- '+cell(g)));
@@ -87,8 +127,13 @@ export async function renderText(directory,state) {
   if(state.documentPolicy.interface===null || state.documentPolicy.databases===null)lines.push('',t('Interface/database applicability will be determined during technical design.','接口／数据库适用性待技术设计确认。'));
   const refs=new Map();
   const names={testing:t('Test cases and results','用例与结果'),sql:'SQL',prd:t('Requirements','需求依据'),source:t('Source material','来源材料'),prototype:t('Prototype','原型')};
-  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(ref.split('#')[0]!=='.aimship/init.md' && !refs.has(ref.split('#')[0]))refs.set(ref.split('#')[0],t('Work material','工作材料'));
+  for(const d of state.documents)if(!d.path.startsWith('.aimship/'))refs.set(d.path,`${names[d.kind]??v(d.kind)} · ${cell(d.version)}`);
+  // Contract stages may have supplementary formal formats (for example RPC).
+  // Root outputs are artifact entries, not approval claims; evidence stays under .aimship/.
+  for(const ref of state.stageRuns.filter(r=>r.stage==='contract').flatMap(r=>r.outputRefs)) {
+    const file=ref.split('#')[0];
+    if(file && !file.includes('/') && !refs.has(file))refs.set(file,t('Additional contract','补充契约'));
+  }
   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('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) {

package/package.json

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

package/skills/aimship/SKILL.md

@@ -11,7 +11,7 @@ Activate only when the user explicitly asks to start or resume Aimship. A clear
 1. Run `"{{AIMSHIP_NODE}}" "{{AIMSHIP_LAUNCHER}}" bind`, then read the returned fixed-version [core](references/core.md) and CLI help. Use that release's tools and references. In a source checkout, run `node bin/aimship.mjs bind` from its package root.
 2. Locate the same delivery and read its state, initialization notes and current materials. For new work, follow [initialization](references/core.md#initialization): preserve the commission in `.aimship/init.md`, use a separate directory under the bound dataRoot, and save the actual language and scope. A concrete request is enough; code and a PRD can come later. Resume existing work rather than initialize it again.
 3. Follow the current [stage reference](references/core.md#stage-references), complete its work and self-check, then save and report the artifacts and current stop. For a newly written or substantively revised reviewable document, show its link and review focus and collect the user's decision using [document review](references/document-review.md). Adopt unchanged supplied materials from the actual commission without asking for their review again. Keep unresolved questions in the document with their impact and the point when an answer is needed.
-4. At the saved stop, handle review feedback or continuation. Record an actual approval before releasing dependent work; a message can approve and ask to continue together. Keep work within a stage continuous. Use the core's major work boundaries for a new-session suggestion; a pending document stays at review in either session.
+4. At the saved stop, present the document and the decisions it needs, or explain what continuation will do. Save the user's actual approval of the current content before dependent work; approval and continuation can be expressed together. Keep work within a stage continuous. Use the core's major work boundaries for a new-session suggestion; a pending document stays at review in either session.
 5. Report the saved directory, materials and next action using the core's User-facing updates guidance. On initialization, remind the user once to add the actual directory to the current project/workspace, ignoring the reminder if already added. On resume, preserve the delivery ID, current stop, language and fixed rule/tool paths; reload these if context is lost.
 
 

package/skills/aimship/references/core.md

@@ -2,7 +2,7 @@
 
 ## 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: “技术设计已保存，请查看接口边界与错误处理，确认通过或提出修改。”
+Apply the workflow internally. Explain the actual result, retained/adopted inputs, useful artifact links, current stop and next action in the delivery language. A review request names the AI-produced document and its concrete review focus; a clarification gives the choice, recommendation and impact; a completed stage says what was saved and what continuation will do. For example: “技术设计已保存，请查看接口边界与错误处理，确认通过或提出修改。” Give this practical reason for the stop rather than quoting internal Skill instructions or linking their rules. Explain rules when the user asks or troubleshooting needs them.
 
 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.
 
@@ -26,7 +26,7 @@ This flow follows explicit Aimship activation in the first and every new session
 1. Preserve the user's relevant wording, sources, constraints and visible discussion. Distinguish user decisions, reported facts, Agent suggestions and unknowns. Do not re-ask known answers or treat discussion as approval. Before write access exists, keep this in the conversation and say it is not saved. If a session switch is necessary before saving, provide copyable context with the intended path, original input and pending operation; it is not a new approval.
 2. Bind the actual tool/core version and keep its returned dataRoot. Inspect the intended delivery folder or known candidates for existing state, partial creation or conflicting material. Read and resume existing state, checking deliveryId when known, including older deliveries outside today’s configured root. For a new location explicitly chosen by the user, preserve that actual decision in a nonempty local file within the delivery and supply `storage: {mode: "explicit", decisionRef: "<delivery-relative file>"}` to init; the reference is a file path without a fragment. Never invent the decision or override the tool’s dataRoot to make a path pass. Otherwise use a separate folder under the bound dataRoot. Ask only when identity/location is unresolved; do not create a replacement or infer ownership from a matching name.
 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. Write concise initialization notes in .aimship/init.md: the original commission in its own words, language, supplied material locations, adopted copies, explicit user limits and the delivery endpoint. Distinguish the user’s words from your summary. Maintain these notes when facts are corrected; keep current progress in state/status and business changes in the formal requirements. Do not duplicate the general workflow or conversation history. 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. An omitted or null endpoint defaults to standard delivery; provide an actual narrower endpoint when the user limits the work. Before PRD exists, use goalRef .aimship/init.md, empty documents and null for unknown 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.
+4. Write concise initialization notes in .aimship/init.md: the original commission in its own words, language, supplied material locations, adopted copies, explicit user limits and the delivery endpoint. Distinguish the user’s words from your summary. Keep stable context here, current progress in state/status and business changes in formal requirements; date any necessary initialization-time observation so it cannot be mistaken for current execution. Do not duplicate the general workflow or conversation history. 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. An omitted or null endpoint defaults to standard delivery; provide an actual narrower endpoint when the user limits the work. Before PRD exists, use goalRef .aimship/init.md, empty documents and null for unknown 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. 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. On first initialization, add one neutral reminder with the actual directory: add it to the current project/workspace, ignoring this if already added. No tool-specific instructions or membership check are needed. Then continue authorized requirement clarification, unless the user requested a stop.
 
@@ -65,7 +65,7 @@ Use the standard delivery sequence for a developer responsible for a requirement
 
 Start requirements intake using this standard sequence. Do not offer a default full-delivery/design-only/initialization-only choice. Record the standard endpoint without a separate scope-selection question; explicit limitations or pauses take precedence. Keep actual document review decisions separate from this initial arrangement. Once confirmed, follow the order; material changes follow [change flow](sources-and-changes.md). A stage may recur as distinct instances with stable IDs and explicit scopes.
 
-Explain each design's key decisions, why they fit the requirements, tradeoffs, artifact location and remaining questions. Ordinary internal implementation choices stay with the agent. Ask for material changes to goals, scope, external behavior, compatibility, significant cost, data handling or an explicit technical commitment. Follow [document review](document-review.md): present each selected reviewable document after self-check and pause for explicit approval. An approval releases the next authorized work; use the session boundary interaction below, without a second approval or start confirmation.
+Explain each design's key decisions, why they fit the requirements, tradeoffs, artifact location and remaining questions. Ordinary implementation choices and necessary engineering dependencies stay with the agent within the commission; adding a repository alone is not a business-scope change. Explain material effects on goals, external behavior, compatibility, cost, data handling or explicit technical commitments and obtain the relevant decision. Keep distinct choices separate, with their own impact, recommendation and dependent work; only an unresolved dependency holds that work. Follow [document review](document-review.md): present each selected reviewable document after self-check and pause for explicit approval. An approval releases the next authorized work; use the session boundary interaction below, without a second approval or start confirmation.
 
 Standard development order: PRD → technical design → interface/SQL → test cases → plan → implementation/review/verification → handoff. Generate only applicable artifacts. Inspect existing formal materials and register adoption without treating adoption as approval. Respect an explicitly limited commission without presenting it as standard complete delivery.
 

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

@@ -2,7 +2,7 @@
 
 [artifact-map.json](artifact-map.json) is the shared mapping for stages, templates and checks. Use [templates](templates/prd.md) for newly authored documents; preserve the ordinary section headings and their order, write visible headings and body in the saved delivery language, and explain inapplicable sections. Use the English or Chinese headings listed in the artifact map; numbered heading prefixes are optional. Keep business IDs and file paths unchanged. Original sources and existing documents are not automatically translated when the language changes. Templates are drafting guidance, not empty artifacts to generate for every delivery.
 
-One request has one directory. New deliveries default to separate folders under the bound dataRoot; formal documents are at the delivery folder’s root, not at dataRoot or the current project merely because materials already exist there. `.aimship/init.md` holds the original commission and maintainable initialization context for the AI; adopted external versions stay in `source/` without overwriting. Follow [source retention and editing boundaries](sources-and-changes.md#location-and-version-discipline) for originals, necessary resources and subsequent versions. State, recovery copies, necessary evidence and generated AI-tool configuration belong under `.aimship/`. Generated `status.md` is the user entry for the complete stage sequence, each stage’s status, current review/questions and next work; no default INDEX, docs/sql hierarchy, AI copy, transcript or full export. A requested export is a dated object/version snapshot, never an editing authority.
+One request has one directory. New deliveries default to separate folders under the bound dataRoot; formal documents are at the delivery folder’s root, not at dataRoot or the current project merely because materials already exist there. `.aimship/init.md` holds the original commission and stable initialization context; adopted external versions stay in `source/` without overwriting. Follow [source retention and editing boundaries](sources-and-changes.md#location-and-version-discipline) for originals, necessary resources and subsequent versions. State, recovery copies, necessary evidence and generated AI-tool configuration belong under `.aimship/`. Generated `status.md` presents stable main stages, current review/questions, next work and registered formal artifacts. Implementation includes batch reviews; overall review is separate. Batches, repairs and repeated runs stay in the state history rather than creating more main-stage rows. No default INDEX, duplicate stage ledger, docs/sql hierarchy, transcript or full export. A requested export is a dated object/version snapshot, never an editing authority.
 
 ## Input and output conditions
 
@@ -12,12 +12,14 @@ Use one registered PRD as the requirement authority. If an existing PRD fully fi
 
 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.
+`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` separates approved TASK/B definitions from their current execution status: planned, active, code complete, review pending/passed, blocked and remaining work as applicable. Update existing TASK/B status after each batch, retaining necessary dated execution facts and object references. Save phase progress in state and render status; do not copy the full task table into status. `testing.md` keeps cases/coverage, all RUN/retests in its execution section, and a maintained latest conclusion in its final section; verification follows overall review. Updating execution/current results does not reapprove unchanged design. 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.
 
 Use `tech-design.md`. HTTP changes use `openapi.yaml` or the registered engineering authority; no extra contract wrapper. Non-HTTP formats are explicitly registered. Database changes require independent `database.sql` (one target) or `database-<id>.sql` per target in contract, after technical-design approval and before test cases. Technical design records the data approach and SQL plan without requiring finished SQL. SQL headers identify target/dialect/version/schema basis/conditions; ordered sections cite requirements/design. Never substitute a Markdown block or migration reference, or execute/change migration mechanisms without authorization.
 
 `diagnosis.md` belongs only to an explicitly selected independent investigation. Known-cause bugs and ordinary development debugging do not add diagnose. Major unknowns require a recorded stage adjustment; hold dependent work. Implementation defects go to implementation, design errors to design, requirement gaps to PRD, incorrect expectations to the testing document.
 
+Write solution documents around their enduring design, not a temporary “all tasks unstarted” or “not implemented” delivery banner. Keep historical observations/conclusions attached to their date and object; maintain the current conclusion rather than appending competing “next steps.” Explain important facts, decisions, risks and unknowns in the document itself. Reference useful source/code or runtime evidence where it supports judgment; routine self-check logs and command transcripts remain optional drill-down evidence. Register every formal contract, including both HTTP and RPC when applicable, so the progress page can link them without listing internal evidence.
+
 ## Identities and references
 
 Use readable IDs for different entities: REQ for requirements, AC for acceptance, TASK/B for implementation, TC for cases, REV/RUN for review/execution records, and CHG/Q/PAGE where useful. Start each kind at 001. Keep the same obligation's ID across documents; do not give different entities the same ID. Users should be able to search an ID in ordinary Markdown. Do not require hyperlinks or any reader's HTML support.

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

@@ -12,7 +12,7 @@ For applicable concurrency and state changes, explain when the business constrai
 
 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.
+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. Organize affected components into readable subsections; full-stack work benefits from backend responsibilities and frontend pages/routes, reuse, interaction states and data flow. Other work uses its actual components. Explain the design and real tradeoffs in the document, using source evidence where it helps judgment; routine investigation/self-check logs are not review prerequisites. API schemas, executable SQL and full test cases remain in their later deliverables.
 
 ## Continue when
 

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

@@ -6,7 +6,7 @@ Read current acceptance criteria, constraints, design/contracts, independent SQL
 
 ## Work and result
 
-Map each goal/risk to observable checks: normal behavior, relevant errors/boundaries and regression. Identify commands/tools, environment, accounts/data and authorization needs. Preserve checks whose conditions are absent; distinguish what must be verified from what can run now.
+Map requirements, acceptance and risks to observable normal, boundary/error and regression checks. Reuse the project's test tools and choose methods where useful: units for logic/state, interface/integration checks for service/data collaboration, component/browser/E2E for interaction paths, targeted performance or security checks for relevant requirements/risks. Explain the choices and execution conditions; no fixed category count or coverage target. Identify tools/commands, isolated data and authorization needs. Preserve checks whose conditions are absent; distinguish what must be verified from what can run now. Implementation checks, batch/overall code review and final independent verification have distinct scopes; a mock result is not real integration evidence.
 
 ## Continue when
 

package/skills/aimship/references/templates/plan.md

@@ -20,7 +20,7 @@ Each batch review, overall review then independent verification; no per-batch fu
 
 ## Task status and execution records
 
-Current status, actual changes, artifact references and object versions by existing TASK/B; preserve the approved tasks above and distinguish pre-existing changes. Record progress here, for example a table of Task | Status | Actual result. Replace guidance with actual content; explain inapplicability, never prefill a result.
+Lead with the current batch/task status using existing B/TASK IDs: Batch/task | Status | Actual result or remaining work | Review/result reference. Distinguish code complete from batch review complete. Follow with necessary dated execution records, deviations and object versions; retain prior results for their objects. Preserve approved task definitions above and distinguish pre-existing changes. Update this summary as work proceeds; save main-stage facts in state for status.md. Replace guidance with actual content; never prefill a result.
 
 ## Deviations, blockers and remaining work
 

package/skills/aimship/references/templates/review.md

@@ -4,13 +4,20 @@ Delivery: <deliveryId from init>; document revision: <revision>.
 
 ## Review basis and scope
 
-Exact repositories/objects, baseline and differences. Replace guidance with actual content; explain inapplicability, never prefill a result.
+State the requirements/design/plan references and review scope. Put each review's actual repositories, baseline plus differences, reviewer and date with its REV record. Keep object details readable and link the exact manifest when useful. Replace guidance with actual content; never prefill a result.
 
 ## Review records
 
-REV, batch/overall/repair scope, TASK/REQ/AC, reviewer/date, findings, dispositions and recheck conclusions. Replace guidance with actual content; explain inapplicability, never prefill a result.
+Use a separate REV subsection for each batch, overall or repair review. Within it write:
+
+- Scope and object: B/TASK and relevant REQ/AC, repositories/baseline/differences, reviewer and date.
+- Assessment: requirements/contract consistency and code quality in this scope; reference relevant checks without repeating implementation or test-command logs.
+- Findings: Finding | Severity/impact | File/section/symbol | Problem and basis | Disposition/status. Use a readable local finding label when a repair/recheck needs to refer back to it. If no findings, say so without an empty table.
+- Repairs and recheck: associate each finding with the actual change, rechecked object and conclusion; distinguish resolved, open and explicitly deferred work.
+
+Keep overall review separate from batch records. Replace guidance with actual content; never prefill a result.
 
 ## Open findings and current conclusion
 
-Preserve historical findings and old object basis; review is not execution. Replace guidance with actual content; explain inapplicability, never prefill a result.
+Maintain the latest effective conclusion: reviewed scope/object, remaining findings and whether they block continuation. Distinguish review findings from unexecuted validation, linking testing.md for runtime coverage and missing conditions. Historical conclusions remain inside their REV records for the old objects; do not accumulate obsolete “next batch” instructions here. Review is not runtime validation or user acceptance. Replace guidance with actual content; never prefill a result.
 

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

@@ -12,7 +12,7 @@ Ordered explanation, with a concise diagram when useful to show cross-system cal
 
 ## Modules and interaction implementation
 
-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.
+Repository ID, responsibility, actual path, new/change and requirement refs. For a full-stack change use readable backend/frontend subsections: affected service/data responsibilities; client pages/routes, reused/new components, interaction states and data flow. For other tasks organize by the actual components; do not invent unused frontend/backend sections. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
 ## Data, interfaces and SQL
 

package/skills/aimship/references/templates/testing.md

@@ -8,7 +8,7 @@ Current AC and risks; adopted cases location/version if verify-only. Replace gui
 
 ## Environment, data and execution conditions
 
-Tools, permissions, commands and unavailable conditions. Replace guidance with actual content; explain inapplicability, never prefill a result.
+Planned tools/entry commands, isolated data, permissions and unavailable execution conditions. Actual versions/environment belong with each RUN. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
 ## Test cases
 
@@ -16,14 +16,14 @@ TC, REQ/AC or risk, type/level, preconditions, operations, concrete expected res
 
 ## Coverage and verification arrangement
 
-AC, requirements, TC, gaps and execution group/order. Replace guidance with actual content; explain inapplicability, never prefill a result.
+AC, requirements, TC, gaps and execution group/order. Explain the selected test methods from requirements and risk, reusing project checks; do not require every test category. Replace guidance with actual content; never prefill a result.
 
 ## Execution and retest records
 
-RUN, TC, testing document version, exact code/build or document object, command/operation, assertions, actual results and evidence. Not executed until actually run; append failures/retests. Replace guidance with actual content; explain inapplicability, never prefill a result.
+Keep every RUN and retest here, grouped by actual batch or verification round: TC, testing document version, exact code/build object, environment, command/operation, assertions, result and evidence. Retain failures and the later recheck; local implementation checks do not replace post-overall-review independent verification. Replace guidance with actual content; never prefill a result.
 
 ## Defects, current conclusion and remaining work
 
-Separate passed, failed, blocked and unexecuted; explain applicability after change. Replace guidance with actual content; explain inapplicability, never prefill a result.
+Maintain a latest-result summary for the current object: AC/TC or risk | Verified scope | Result | Evidence/RUN | Remaining coverage. Separate passed, failed, blocked and unexecuted; state defects, their disposition and the next necessary work. Keep historical RUNs in the execution section above, not underneath an old current conclusion. Replace guidance with actual content; never prefill a result.
 
 <!-- Review guidance: retain the fixed outline. Technical design precedes interface/SQL production; test cases precede planning. Self-check and explicit document approval are separate from stage done. For plan/testing, keep execution records after execution/runs respectively. -->