aimship 0.1.0-preview.19 → 0.1.0-preview.20

package/docs/cli.md

@@ -49,6 +49,12 @@ 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.
 
+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.
+
+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.
+
+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.
+
 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.
 
 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.
@@ -117,11 +123,11 @@ Independent review, verify-only work or limited handoff can omit standard upstre
 
 Reviews identify their actual implementation coverage with `reviewOf: [implementationRunId, ...]`; overall review has `overall: true`. For a single batch one review may explicitly cover both. An unresolved failed review prevents standard completion even if an earlier overall review passed. A passing repair review or retest may list the superseded review/RUN result references in its existing `historyResultRefs`, preserving old failures; the Agent must verify that it actually resolves or covers them on current objects. Verification must follow the applicable overall review. Merely setting a link is not semantic evidence.
 
-`run.sessionGroup` remains advisory context, not permission to cross stages. Each stage finishes its work/self-check, saves artifacts and stops: `session.action` is await-review for required approval or await-continue for a completed stage awaiting continuation; `stop` and `suggestNewSession` make that advice explicit. `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”.
+`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”.
 
 `read` and `resume` accept optional `--delivery-id <known-id>` to reject a wrong directory binding. A directory remains required; no implicit latest-delivery lookup exists. Resume is read-only and inspects actual state, approval/content versions, references and view diagnostics; old prompts grant no approval. The Agent must additionally inspect relevant complete formal documents, actual artifacts and unfinished effects before acting.
 
 
 Review run `ready` describes a completed, current record; `releaseReady` additionally requires a usable passing review before releasing dependent work. Failed review records remain saved. A later passing repair review must preserve the old result reference and cover the affected implementation scope; unrelated passing reviews do not clear the failure. Session suggestions distinguish exhausting registered work from completing the agreed goal: an unfinished goal with no next run requires arranging the next authorized work, not declaring finished.
 
-The generated status page prioritizes current work, self-check and approval, user action, actual directory and continuation stop. Future standard stages are not started, not current defects; unknown contract applicability remains pending design. Final completion diagnostics remain enforced and are shown at handoff. Engineering details and generation metadata follow the user summary.
+The generated status page puts current stage, actual blockers and concrete next action first, then Stage / artifact-or-result / status. It links formal results in that table instead of repeating a navigation inventory and omits conversational continuation instructions. The delivery directory and overall saved timestamp remain in saved information; no per-output timestamp is inferred. Future standard stages are not started, not current defects; unknown contract applicability remains pending design. Final completion diagnostics remain enforced and are shown at handoff. Engineering details and generation metadata follow the user summary.

package/docs/guide.md

@@ -76,7 +76,7 @@ Materials develop gradually and are kept as needed. Search readable REQ, AC and
 
 Follow sign-up and login from requirements to acceptance. **This is fictional practice; wording and business choices need not be copied.** The example later supplies a project and isolated test database, with prototype review after requirements and before technical design. Actual prototype placement follows the delivery's needs.
 
-Use one Aimship entry within a session; no invocation is needed at every stage. After completing and self-checking a stage, the AI saves its results, reports the stop and pauses. A new session is recommended at major work transitions, not after every stop. AI-authored or substantively revised reviewable documents await approval; questions affecting current work await clarification; other completed stages await continuation. You may say “approved, continue” once. Work within a stage stays continuous.
+Use one Aimship entry within a session; no invocation is needed at every stage. After completing and self-checking a user-visible work unit, the AI saves its results, reports the stop and pauses. One implementation batch includes its batch review and authorized repair/recheck, with separate internal saved records. A new session is recommended at major work transitions, not after every stop. AI-authored or substantively revised reviewable documents await approval; questions affecting current work await clarification; other completed stages await continuation. You may say “approved, continue” once. Work within a stage stays continuous.
 
 <a id="11-prepare-a-workspace"></a>
 <a id="12-activate-aimship-and-describe-the-request"></a>
@@ -191,9 +191,9 @@ 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 the plan and reviews each batch, saving and stopping after implementation and after review. Continuation advances only after blocking issues are resolved. All batches are followed by overall review, then verification. Requirement changes return to the relevant review.
+**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.
 
-**Outputs:** Project code, execution progress appended to `plan.md`, and batch findings and repairs in `review.md`.
+**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.
 
 <a id="guide-overall"></a>
 <a id="19-review-the-complete-change"></a>
@@ -202,7 +202,7 @@ The AI rechecks access to the same delivery directory, reads its state and confi
 
 **User actions:** Read the overall findings and remaining issues, pointing out omissions if needed. Review records do not need a separate document approval; inspect the conclusion and ask to continue.
 
-**AI processing:** Checks all actual changes and connections across sign-up, login, logout and home-page access. It resolves issues blocking independent verification, saves the conclusion and stops before continuing to verification. A single-batch review can explicitly cover both batch and overall scope.
+**AI processing:** Checks all actual changes and connections across sign-up, login, logout and home-page access. It 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.
 
 **Outputs:** Overall conclusions appended to `review.md`. Code review does not replace running tests.
 

package/docs/guide.zh-CN.md

@@ -76,7 +76,7 @@ AI 工具项目空间
 
 以登录注册功能演示从需求到验收。**这是虚构实践参考，措辞和业务方案无需照抄。** 本例稍后提供工程和隔离测试数据库，约定需求后确认原型，再做技术设计；实际原型安排按交付需要确定。
 
-同一会话沿用一个 Aimship 入口，无需逐阶段调用。每阶段完成并自检后，AI 保存成果、说明停点并停下。主要工作切换时建议新会话，也可原会话继续。AI 新产出或实质修改的需审文档等待批准，影响当前推进的问题等待确认，其他已完成阶段等待继续；可以一次说“通过并继续”。阶段内部不逐小步暂停。
+同一会话沿用一个 Aimship 入口，无需逐阶段调用。每个用户可见工作单元完成并自检后，AI 保存成果、说明停点并停下；一批实施包含本批审查及授权内修复复查，内部记录分别保存。主要工作切换时建议新会话，也可原会话继续。AI 新产出或实质修改的需审文档等待批准，影响当前推进的问题等待确认，其他已完成阶段等待继续；可以一次说“通过并继续”。阶段内部不逐小步暂停。
 
 <a id="11-准备工作位置"></a>
 <a id="12-启用-aimship-并说明需求"></a>
@@ -189,9 +189,9 @@ AI 重新核对同一交付目录的访问，读取状态并确认下一步技
 
 **用户操作**：查看改动和进度，有偏离及时指出，如“注册成功后的跳转与原型不一致”。无需逐条批准执行日志；阶段结束查看结果后可要求继续。
 
-**AI 处理**：按计划写代码，每批实施、批内审查分别完成后保存并停下，收到继续指令再推进；存在阻碍时先修复。全部批次完成后安排整体审查，再统一验证；需求变化回到相应审核。
+**AI 处理**：完成一批实现、按风险做必要本地检查，接着本批审查及授权内修复复查。实现和审查分别保存，在批次闭环后再报告停下，不在内部衔接处多等一次继续；实际依赖受阻时停在该问题。全部批次完成后安排整体审查，再统一验证；需求变化回到相应审核。
 
-**输出产物**：工程代码；`plan.md` 追加执行进度，`review.md` 记录本批问题与修复。
+**输出产物**：工程代码；`plan.md` 执行区维护唯一批次进度表（含review状态），`review.md` 记录问题与修复；开发自检仅简记并引用证据，正式测试结果留后续验证。
 
 <a id="guide-overall"></a>
 <a id="19-整体-review"></a>
@@ -200,7 +200,7 @@ AI 重新核对同一交付目录的访问，读取状态并确认下一步技
 
 **用户操作**：查看整体结论和遗留问题，必要时指出遗漏；不需要为审查记录另做文档批准，查看结论后可要求继续。
 
-**AI 处理**：检查全部实际改动及注册、登录、退出、首页访问的跨批衔接，处理阻碍验证的问题后保存结论并停下，收到继续指令再进入独立验证。单批可用一份 review 明确覆盖批内及整体范围。
+**AI 处理**：检查全部实际改动及注册、登录、退出、首页访问的跨批衔接，记录问题和当前对象，保存结论并停下；仅请求整体审查不会自动执行全面测试，授权修复后回到复查，之后才是正式验证。单批可用一份 review 明确覆盖批内及整体范围。
 
 **输出产物**：`review.md` 追加整体审查结论。代码审查不能代替运行测试。
 

package/lib/cli.mjs

@@ -32,7 +32,8 @@ const HELP = {
     protocolVersion: PROTOCOL_VERSION,
     documentReview: {reviewPolicy:1, reviewHistory:'Append-only {id,kind,document,version,digest,sourceRef,summary}. self-check requires result: passed|failed; approved requires decision: explicit-approval; editorial requires previousDigest. Read review.documents for current digests. Tools validate records, not user identity. See docs/cli.md#document-review-protocol.'},
     deliveryPolicy: 'New states default to {version:1}; partialRef identifies an explicitly limited scope, null restores standard scope with a new goal decision. Completion is derived separately from goal/acceptance.',
-    sessions: 'run.sessionGroup is an advisory context group, auto-filled for new runs; reviewOf names implementation runs and overall:true identifies overall review. read/check/resume expose session/completion. Supplied PRD/prototype mode input uses the actual request basisRef and self-check, not human approval. next.questionRef identifies a concrete question on a blocked stage (clear with null). Completed stages return stop with await-review, await-clarification or await-continue, even within one group; suggestNewSession is advisory. Failed view saving returns reconcile-save. No new approval or automatic execution.',
+    implementationWork: 'Optional implement-only workType: batch|repair and repairOf: preceding run IDs. They classify scope for display/advice, never omit implementation from review coverage. Without a purpose, pre-overall work retains legacy batch meaning; later work is unclassified until its actual basis is checked. No implicit state rewrite.',
+    sessions: 'run.sessionGroup is an advisory context group, auto-filled for new runs; reviewOf names implementation runs and overall:true identifies overall review. read/check/resume expose session/completion. Supplied PRD/prototype mode input uses the actual request basisRef and self-check, not human approval. next.questionRef identifies a concrete question on a blocked stage (clear with null). Completed work units stop with await-review, await-clarification or await-continue. Implementation checkpoints can return continue-implementation-review, and failed batch reviews continue-batch-repair within existing authorization, without starting the next batch. Overall review stops before verify; suggestNewSession is advisory. Failed view saving returns reconcile-save. No new approval or automatic execution.',
     stages: STAGES,
     progress: ['planned', 'active', 'blocked', 'done'],
     result: ['passed', 'failed', 'not-run', 'unknown', 'mixed'],

package/lib/delivery.mjs

@@ -2,6 +2,7 @@ import { text, completionMessage } from './language.mjs';
 import path from 'node:path';
 import { unknownConditions } from './documents.mjs';
 import { fail } from './io.mjs';
+import { implementationReviewScope, implementationType } from './execution.mjs';
 
 // Current delivery policy and completion checks.
 export function validateDelivery(state) {
@@ -9,6 +10,8 @@ export function validateDelivery(state) {
   if (!p || p.version !== 1) fail('INVALID_STATE', 'Unsupported delivery policy.', 'Preserve the state and use a compatible tool.');
   if (p.partialRef != null && (typeof p.partialRef !== 'string' || !p.partialRef.trim())) fail('INVALID_STATE', 'partialRef must identify the explicit scope decision.', 'Record the actual decision in the existing requirement or change record.');
   for (const r of state.stageRuns) {
+    if (r.workType !== undefined && (r.stage !== 'implement' || !['batch','repair'].includes(r.workType))) fail('INVALID_STATE','workType is batch or repair on implementation runs only.','Record the actual work purpose.');
+    if (r.repairOf !== undefined && (r.workType !== 'repair' || !Array.isArray(r.repairOf) || !r.repairOf.length || new Set(r.repairOf).size !== r.repairOf.length || !r.repairOf.every(id=>state.stageRuns.slice(0,state.stageRuns.indexOf(r)).some(prior=>prior.id===id)))) fail('INVALID_STATE','repairOf must name preceding work for an implementation repair.','Retain the actual repair basis; this does not replace review coverage.');
     if (r.overall !== undefined && (r.stage !== 'review' || typeof r.overall !== 'boolean')) fail('INVALID_STATE', 'overall is a review scope flag.', 'Identify the actual overall review.');
     if (r.sessionGroup !== undefined && (typeof r.sessionGroup !== 'string' || !r.sessionGroup.trim())) fail('INVALID_STATE', 'Invalid sessionGroup.', 'Use a nonempty advisory group ID.');
     if (r.reviewOf !== undefined && (r.stage !== 'review' || !Array.isArray(r.reviewOf) || !r.reviewOf.length || new Set(r.reviewOf).size !== r.reviewOf.length || r.reviewOf.some(id => !state.stageRuns.some(x => x.id === id && x.stage === 'implement')))) fail('INVALID_STATE', 'reviewOf must identify implementation runs.', 'Record the actual reviewed batches.');
@@ -99,9 +102,23 @@ export function sessionAdvice(directory,state,review,{saved=true}={}) {
   else if(current && ((!status?.resolvedBy && (['failed','mixed','unknown','not-run'].includes(current.result) || (current.stage==='review' && current.progress==='done' && !status?.releaseReady))) || current.progress==='blocked' || ['needs-review','unknown'].includes(current.applicability))) action=concluded && !next?'finished':'resolve-current';
   else if(status?.ready) action=!next?endAction:next.progress!=='planned'?'inspect-existing-work':'await-continue';
   if (saved && !pending && state.deliveryPolicy?.version === 1 && status?.ready && next && review.runs.find(r=>r.id===next.id)?.blockedBy.length) action='resolve-current';
+  // Internal checkpoints execute nothing and never release another batch.
+  let reviewScope=null;
+  if (saved && !concluded && !pending && !state.next.questionRef && status?.ready && current?.progress==='done' && !['needs-review','unknown'].includes(current.applicability)) {
+    if(current.stage==='implement' && !['failed','mixed','unknown','not-run'].includes(current.result)) {
+      reviewScope=implementationReviewScope(state,current);
+      const reviewed=state.stageRuns.some(r=>r.stage==='review' && state.stageRuns.indexOf(r)>state.stageRuns.indexOf(current) && r.reviewOf?.includes(current.id) && r.result==='passed' && review.runs.find(s=>s.id===r.id)?.releaseReady);
+      const selectedReview=next?.stage==='review' && next.reviewOf?.includes(current.id);
+      if(reviewScope && !reviewed && (!state.deliveryPolicy.partialRef || selectedReview))action='continue-implementation-review';
+      else if(!reviewScope && !reviewed && implementationType(state,current)==='repair')action='inspect-review-scope';
+    } else if(current.stage==='review' && !status.resolvedBy && current.overall!==true && current.reviewOf?.length && ['failed','mixed'].includes(current.result)) action='continue-batch-repair';
+  }
   const suggestNewSession=['await-review','await-continue'].includes(action) && majorSessionBoundary(state,current);
   let instruction=action==='await-clarification'?text(state,'Please answer the question listed below so this work can continue.','请回答下一步所列的具体问题，以便继续当前工作。'):action==='await-continue'?text(state,'This stage is saved. Say “continue” when ready.','本阶段已保存。准备好后可说“继续”。'):action==='assess-outcome'?text(state,'Review the handoff against the agreed goal and record the actual goal conclusion and acceptance; completed handoff alone does not end the delivery.','请对照约定目标审阅交付材料，记录实际目标结论和用户接受结果；完成交付文档不等于交付已结束。'):null;
+  if(action==='continue-implementation-review')instruction=text(state,'Review the saved implementation and repair findings within the authorized work unit before reporting its stop.','继续审查已保存的实现，并在已授权工作单元内修复、复查后报告停点。');
+  if(action==='inspect-review-scope')instruction=text(state,'Read the existing plan and original review to establish this repair’s batch or overall scope before selecting its recheck. The next scheduled review alone does not establish that scope.','先读取已有计划及原审查，核对本次修复对应的批次或整体范围，再选择复查；不能仅凭下一条已排审查推定范围。');
+  if(action==='continue-batch-repair')instruction=text(state,'Repair and recheck this batch within the existing authorization; stop for a scope, approval or permission dependency.','在已有授权内修复并复查本批；遇范围、审批或权限依赖时停在实际问题。');
   if(suggestNewSession) instruction=[instruction,action==='await-review'?text(state,'A new session is recommended to review this document; you can also review it here.','建议新开会话审阅本份文档，也可留在这里审核。'):text(state,'A new session is recommended for the next work; you can also continue here.','建议新开会话接续下一步，也可留在这里继续。')].filter(Boolean).join(' ');
   const continuation=['reconcile-save','await-review','await-clarification','assess-outcome','finished'].includes(action)?null:text(state,`Use Aimship to continue delivery ${JSON.stringify(path.resolve(directory))}; first read its current state and relevant formal documents, then continue the recorded work.${instruction?' '+instruction:''}`,`使用 Aimship 继续交付「${path.resolve(directory)}」，先读取当前状态和相关正式文档再接续。${instruction??''}`);
-  return {action,stop:!['continue-current','inspect-existing-work'].includes(action),suggestNewSession,currentRun:current?.id??null,nextRun:next?.id??null,groups,continuation,instruction,advisory:true,note:text(state,'A session boundary is not a blocker or approval. Continue here when requested. Resolve the delivery identity, current approvals and unfinished effects on every resume; this text grants no approval.','会话边界不是阻塞或批准。用户要求时可在当前会话继续。每次续接都需核对交付身份、当前审批和未完成事项；本提示不授予权限。')};
+  return {action,stop:!['continue-current','inspect-existing-work','continue-implementation-review','continue-batch-repair','inspect-review-scope'].includes(action),suggestNewSession,reviewScope,currentRun:current?.id??null,nextRun:action==='continue-implementation-review'?(next?.stage==='review' && next.reviewOf?.includes(current.id) && (reviewScope==='overall-recheck' ? next.overall===true : !next.overall)?next.id:null):['continue-batch-repair','inspect-review-scope'].includes(action)?null:next?.id??null,groups,continuation,instruction,advisory:true,note:text(state,'A session boundary is not a blocker or approval. Continue here when requested. Resolve the delivery identity, current approvals and unfinished effects on every resume; this text grants no approval.','会话边界不是阻塞或批准。用户要求时可在当前会话继续。每次续接都需核对交付身份、当前审批和未完成事项；本提示不授予权限。')};
 }

package/lib/documents.mjs

@@ -86,7 +86,8 @@ export function definitions(text, file, spec) {
     }
     const structured=/^\s*(?:\||#{1,6}\s+|[-*+]\s+)/.test(line);
     if(!structured && !new RegExp('^'+ID+'[:：]').test(line)) continue;
-    const candidate=line.trim().replace(/^\|\s*/, '').replace(/^(?:#{1,6}\s+|[-*+]\s+)/,'').replace(/^[*`]+/,'');
+    let candidate=line.trim().replace(/^\|\s*/, '').replace(/^(?:#{1,6}\s+|[-*+]\s+)/,'').replace(/^[*`]+/,'');
+    if(heading)candidate=candidate.replace(/^\d+(?:\.\d+)*[.)、]?\s+/, '');
     const match=new RegExp('^('+ID+')(?![A-Za-z0-9_-])(?:[*`]*)(?:\\s*[|:：—–-]\\s*|\\s+|$)(.*)$').exec(candidate);
     if(!match) continue;
     let body=match[2];

package/lib/execution.mjs

@@ -0,0 +1,27 @@
+// Advisory work classification. Every implementation still participates in review gates.
+export function implementationType(state, run) {
+  if (run.stage !== 'implement') return null;
+  if (run.workType) return run.workType;
+  const before = state.stageRuns.slice(0,state.stageRuns.indexOf(run));
+  const lastReview=before.findLast(r=>r.stage==='review');
+  return before.some(r=>r.stage==='review' && r.overall || ['verify','handoff'].includes(r.stage)) || lastReview && lastReview.result!=='passed' ? 'unclassified' : 'batch';
+}
+export function implementationSummary(state) {
+  const runs=state.stageRuns.filter(r=>r.stage==='implement');
+  return Object.fromEntries(['batch','repair','unclassified'].map(kind=>[kind,runs.filter(r=>implementationType(state,r)===kind)]));
+}
+export function resolvedRun(state, review, run) {
+  const recorded=review.runs.find(r=>r.id===run.id)?.resolvedBy;
+  if (recorded) return recorded;
+  if(run.stage!=='verify' || !run.resultRef) return null;
+  return state.stageRuns.slice(state.stageRuns.indexOf(run)+1).findLast(r=>r.stage==='verify' && r.result==='passed' && review.runs.find(s=>s.id===r.id)?.ready && r.historyResultRefs?.includes(run.resultRef))?.id ?? null;
+}
+export function implementationReviewScope(state,run) {
+  if(implementationType(state,run)==='batch')return 'batch';
+  if(implementationType(state,run)==='repair') {
+    const basis=(run.repairOf??[]).map(id=>state.stageRuns.find(r=>r.id===id));
+    if(basis.some(r=>r?.stage==='review' && r.overall===true))return 'overall-recheck';
+    if(basis.length && basis.every(r=>r?.stage==='review' && r.reviewOf?.length))return 'recheck';
+  }
+  return null;
+}

package/lib/view.mjs

@@ -1,5 +1,6 @@
 import { text, displayValue } from './language.mjs';
-import { completionStatus, sessionAdvice, suggestedNextStage } from './delivery.mjs';
+import { implementationSummary, resolvedRun } from './execution.mjs';
+import { completionStatus, sessionAdvice } from './delivery.mjs';
 import fs from 'node:fs/promises';
 import { reviewStatus } from './approvals.mjs';
 import path from 'node:path';
@@ -55,14 +56,14 @@ export async function renderText(directory,state) {
   const humanDocs=review.documents.filter(d=>currentReview?.documents.includes(d.path));
   const failed=r=>['failed','mixed'].includes(r.result);
   const progress=r=> {
-    const check=review.runs.find(x=>x.id===r.id);
+    const check=review.runs.find(x=>x.id===r.id), resolved=resolvedRun(state,review,r);
     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(failed(r) && !resolved)return t('Result needs resolution','结果待处理');
+    if(r.result==='unknown' && !resolved)return t('Result not yet known','结果尚未确定');
+    if(r.result==='not-run' && !resolved)return t('Not run','未执行');
+    if(r.stage==='review' && r.progress==='done' && !r.result && !resolved)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','已采用现有材料');
@@ -72,16 +73,17 @@ export async function renderText(directory,state) {
   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);
+    const runs=all.filter(r=>!resolvedRun(state,review,r));
     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 {batch:batches,repair,unclassified}=implementationSummary(state);
       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}；待批次审查`);
+      const label=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}；待批次审查`);
+      return label+(repair.length?t(`; repairs: ${repair.length}`,`；修复工作 ${repair.length}`):'')+(unclassified.length?t(`; work with unclassified purpose: ${unclassified.length}`,`；用途待核对工作 ${unclassified.length}`):'');
     }
     // A previous overall conclusion cannot cover later implementation work.
     if(stage==='review' && state.stageRuns.some(r=>r.stage==='implement')) {
@@ -96,27 +98,39 @@ export async function renderText(directory,state) {
   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)) {
-    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(failed(current) && !resolvedRun(state,review,current))problems.push(t('Resolve the recorded unsuccessful result before advancing.','请先处理当前未通过的结果，再推进。'));
+    if(['unknown','not-run'].includes(current.result) && !resolvedRun(state,review,current) && !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 | Status |','| 阶段 | 状态 |'),'| --- | --- |');
-  for(const stage of phaseOrder(state))lines.push(`| ${phaseName(stage)} | ${phaseProgress(stage)} |`);
+  const refs=new Map(), used=new Set();
+  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)if(!d.path.startsWith('.aimship/'))refs.set(d.path,`${names[d.kind]??v(d.kind)} · ${cell(d.version)}`);
+  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','补充契约'));
+  }
+  const kinds={frame:['prd'],requirements:['prd'],prototype:['prototype'],diagnose:['diagnosis'],'tech-design':['tech-design'],contract:['contract','sql'],'test-design':['testing'],plan:['plan'],implement:['plan'],review:['review'],verify:['testing'],handoff:['handoff']};
+  const artifacts=async stage=> {
+    const entries=new Map();
+    for(const d of state.documents.filter(d=>kinds[stage]?.includes(d.kind)))entries.set(d.path,d.path);
+    const runs=state.stageRuns.filter(r=>phaseOf(state,r)===stage && !resolvedRun(state,review,r));
+    for(const ref of runs.flatMap(r=>r.outputRefs))if(refs.has(ref.split('#')[0]))entries.set(ref.split('#')[0],ref);
+    const latest=runs.findLast(r=>r.progress==='done' && r.resultRef);
+    if(latest && refs.has(latest.resultRef.split('#')[0]))entries.set(latest.resultRef.split('#')[0],latest.resultRef);
+    const links=[];
+    for(const [file,ref] of entries)if(await available(directory,state,file)){used.add(file);links.push(artifactLink(file)+(ref.includes('#')?' · '+cell(ref.split('#')[1]):''));}
+    return links.join('; ') || t('Not yet recorded','尚未记录');
+  };
+  lines.push('',t('## Delivery progress','## 整体进度'),'',t('| Stage | Artifact or result | Status |','| 阶段 | 成果 | 状态 |'),'| --- | --- | --- |');
+  for(const stage of phaseOrder(state))lines.push(`| ${phaseName(stage)} | ${await artifacts(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)));
@@ -125,22 +139,12 @@ export async function renderText(directory,state) {
   if(state.outcome.deploymentRef)lines.push(`${t('Deployment record','部署记录')}: ${artifactLink(state.outcome.deploymentRef)}`);
   lines.push('',t('## Goal and adopted materials','## 目标与采用材料'),'',`${t('Endpoint','交付终点')}: ${cell(state.goal.endpoint??t('To be confirmed','待确认'))}`);
   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)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 会读取已保存状态和材料，接续本页停点。'));
+  for(const [ref,role] of refs)if(!used.has(ref) && await available(directory,state,ref))lines.push(`- ${role}: ${artifactLink(ref)}`);
   if(state.repositories.length) {
     lines.push('',t('## Associated engineering','## 关联工程'),'',t('| Object | Location | Role |','| 工程 | 位置 | 用途 |'),'| --- | --- | --- |');
     for(const r of state.repositories)lines.push(`| ${cell(r.id)} | ${cell(r.path)} | ${cell(r.role)} |`);
   }
-  lines.push('',t('## Saved information','## 保存信息'),'',`${t('Delivery','交付')}: ${state.deliveryId}`,`${t('State revision','状态修订')}: ${state.revision}`,`${t('Rules','规则版本')}: ${state.rulesVersion}`,`${t('State saved','状态保存时间')}: ${state.updatedAt}`,'',t('Generated from saved state and document checks. Update the formal records, not this page. Recorded results are not independent proof of execution.','由保存状态和文档检查生成；请更新正式记录，不手改本页。记录结果不等于独立验证了实际执行。'),'');
+  lines.push('',t('## Saved information','## 保存信息'),'',`${t('Delivery directory','交付目录')}: ${cell(path.resolve(directory))}`,`${t('Delivery','交付')}: ${state.deliveryId}`,`${t('State revision','状态修订')}: ${state.revision}`,`${t('Rules','规则版本')}: ${state.rulesVersion}`,`${t('State saved','状态保存时间')}: ${state.updatedAt}`,'',t('Generated from saved state and document checks. Update the formal records, not this page. Recorded results are not independent proof of execution.','由保存状态和文档检查生成；请更新正式记录，不手改本页。记录结果不等于独立验证了实际执行。'),'');
   return lines.join('\n');
 }
 export async function generateView(directory,state,preserveEdits=false) {

package/package.json

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

package/skills/aimship/SKILL.md

@@ -10,8 +10,8 @@ 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, 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.
+3. Use [routing](references/routing.md) to determine this turn's stage, actual scope and user-visible stop from the request and saved state. Load the selected [stage contract](references/core.md#stage-references), not every stage. Each has inputs, goal/scope, actions, outputs/result and completion/stop. Shared approval, change, source and recovery rules remain in their common references.
+4. Execute that work unit within the commission. One implementation batch includes local checks, batch review and authorized repair/recheck; keep separate internal runs but do not ask for continuation between them. Stop at batch closure, a real dependency, a required document review, or the selected overall-review/verification boundary. A request for overall review alone does not authorize full testing. Save actual content approval before dependent work; approval and continuation may be expressed together.
 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

@@ -79,7 +79,7 @@ Current completion claims require the recorded scope, approvals and actual resul
 
 ## Stage references
 
-Read the reference for the current responsibility, not all stage references on every turn.
+Use [routing](routing.md) to select the current work unit, then read its stage contract. Do not load all stages on every turn. Review dispatch selects a batch, overall or recheck contract; modules are instructions, not separate user commands, agents or isolated contexts.
 
 | Responsibility | Read when | Reference |
 | --- | --- | --- |
@@ -100,7 +100,7 @@ Each run records its scope, required inputs, results and progress. A result may
 
 ## Implementation and evidence
 
-For multiple batches: implement batch → review batch, repeat; after every batch is complete and reviewed, review the whole change, then independently verify within the agreed scope. For one batch, one review record may explicitly cover both batch and whole-change scopes. Do not create a complete testing gate after every batch. Planned tests can be written with implementation; writing them does not mean they passed.
+For multiple batches: complete one implementation work unit (implement → risk-based local checks → batch review → authorized repair/recheck), save and report its closure, then stop before the next batch. After all batches are complete and reviewed, perform an independent overall review, then the agreed formal verification. An overall-review-only request stops at that review conclusion, not automatic execution of the test plan. For one batch, one review record may explicitly cover both batch and whole-change scopes. Do not create a complete testing gate after every batch. Planned tests can be written with implementation; writing them does not mean they passed. Local units need no deployment. Keep brief development checks and evidence references in plan execution; formal RUN records and optional coverage-based verification groups belong to testing execution. Groups are not development batches, and retests are new RUNs, not new business batches.
 
 For standard delivery, registering review/verify/handoff as active or done requires their actual predecessors even when dependsOn or inputRefs are empty: review identifies completed implementation objects (an overall review covers all preceding batches), verification follows a passing overall review and resolved preceding reviews, and handoff follows passing verification or an evidenced passing rerun. Draft documents and planned work may be saved earlier. Independent review, verification or limited handoff requires the existing deliveryPolicy.partialRef to point to readable local evidence of the explicitly limited commission; an empty dependency list is not such authorization. Existing declared dependencies and document approvals still apply. These are state-tool checks, not interception of general-purpose file, test or deployment tools.
 
@@ -116,7 +116,7 @@ Use the installed tool's documented state protocol. Read the current revision be
 
 Important semantic changes retain historical review and test facts, mark affected conclusions for review and update the current editable authority. Do not overwrite external adopted sources. See [sources and change flow](sources-and-changes.md).
 
-At each stage boundary, save the completed work and self-check, show its artifacts, current stop and next suggestion, then stop. Recommend a new session at the major boundaries below, without requiring one. Work continuously inside a stage; do not pause after each small step. Existing sessionGroup is only contextual grouping, never permission to cross stages. Each implementation batch and its batch review retain their own results; overall review remains distinct. Do not create a session approval record or require proof of a changed session ID.
+At each user-visible work-unit boundary, save the completed work and self-check, show its artifacts, actual stop and next action, then stop. Implementation and batch review save separate runs as internal checkpoints in one authorized batch work unit; continue its review/repair before the batch stop. A real permission, scope, approval or technical dependency can stop that work earlier. Existing sessionGroup is contextual grouping, not authorization. Overall review and formal verification remain distinct stops. Recommend a new session at the major boundaries below without requiring one; no session approval record or changed-session-ID proof.
 
 Recommend switching after requirements are ready for technical design, after design and applicable contracts before test design, after the plan before implementation, after an implementation batch and its review, and after overall review before independent verification. Combine coinciding boundaries. Directory creation alone, individual documents inside a design group, test design before planning, and implementation before its batch review do not need another suggestion. For a pending document at a major boundary, recommend resuming its review, not starting the next stage. A failed review stays with its repairs.
 
@@ -124,7 +124,7 @@ For a reviewable draft, show only its current stage/status, document entry and r
 
 After explicit approval, in one handling of the message: preserve the actual decision source and exact reviewed version; update approval, current run and next work together as appropriate; inspect the returned saved revision and view result (reread when uncertain); then report the saved outcome and next suggestion. Do not ask the user separately to approve saving or the prompt. If state saving failed, do not claim success; if state saved but the view failed, repair the view at that revision without replaying the approval. Only give the handoff entry once the save is confirmed.
 
-After a stage is saved, wait for explicit approval where document review is required, or for continuation where it is not. An approval may include “continue”; record it and proceed without a second confirmation. Approval without a continuation request leaves a saved boundary. Never treat “continue” alone as document approval. Continuing in this session needs no session permission. Stage-internal work and authorized repair remain continuous; failures lead to repair/re-review rather than mechanical advancement. At final handoff do not invent a next-session task.
+After a user-visible work unit is saved, wait for explicit approval where document review is required, or for continuation where it is not. An approval may include “continue”; record it and proceed without a second confirmation. Approval without a continuation request leaves a saved boundary. Never treat “continue” alone as document approval. Continuing in this session needs no session permission. Stage-internal work and authorized repair remain continuous; failures lead to repair/re-review rather than mechanical advancement. At final handoff do not invent a next-session task.
 
 At a recommended session boundary or when the user requests continuation help, give current status, artifact and next suggestion, followed by one line in the saved delivery language using the actual absolute directory: “Use Aimship to continue delivery <actual directory>; first read the current state and relevant formal documents, then continue the recorded work.” In Chinese: “使用 Aimship 继续交付「实际目录」，先读取当前状态和相关正式文档再接续。” Do not output placeholders or long prompts at every stage. Full tasks, inputs, deliverable requirements, review stops and unresolved matters stay in existing state/formal documents/rules, not a new prompt or handoff file. A complete prompt may be generated when requested, without an arbitrary length limit.
 

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

@@ -1,6 +1,6 @@
 # Delivery documents and traceability
 
-[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.
+[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; new AI-authored formal Markdown uses an unnumbered document title and numbered body headings (1, 1.1, 1.1.1). This is writing guidance, not another validation gate. Preserve supplied PRDs/prototypes, OpenAPI, SQL and machine files; do not renumber old documents automatically. Pure editorial reconciliation follows the existing approval protocol, while substantive changes still require review. 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 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.
 
@@ -12,7 +12,7 @@ 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` 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.
+`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` retains approved goals, dependencies and TASK/B definitions in the design sections. Its execution section keeps one batch progress table with implementation/review/repair state, B/TASK/result references and remaining work, separating definitions from current 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 in its design part, formal RUN/retests and an optional coverage-based group table in execution, and one maintained current conclusion. Brief development checks stay in plan execution with evidence references; retests are new RUNs in the same verification scope, not new development batches; 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.
 

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

@@ -0,0 +1,7 @@
+# Shared review method
+
+Fix the reviewed object first: requirements/design/plan basis, repositories, commit plus relevant differences/untracked files, or document sections/digests. Inspect only the commissioned scope and its dependencies. Review checks requirement/contract consistency, defects, omissions and code quality; it is not execution of the full testing plan.
+
+Record a REV in review.md with scope/object, assessment and findings. A finding gives impact/severity, file/section/symbol, concrete problem, disposition and repair/recheck reference. If there are no findings, say so briefly; do not emit an empty issue table or implementation/test-command transcript. Reference existing evidence where it supports the conclusion.
+
+Keep historical REV conclusions for their original objects. A passing recheck names the repaired object and explicitly references the conclusion it replaces; a failed or unexecuted check stays failed or unknown. Maintain one current conclusion and saved next action for the applicable object, rather than appending competing old instructions. Existing document-content approvals remain separate from code-review records.

package/skills/aimship/references/reviews/batch.md

@@ -0,0 +1,21 @@
+# Review the current batch
+
+## Inputs
+
+The current B/TASK definitions, implemented run/object, applicable requirements/design/contracts and any repair/check evidence.
+
+## Goal and scope
+
+Examine this batch and its necessary interfaces before another business batch begins. This is part of the authorized implementation work unit.
+
+## Actions
+
+Apply the [shared review method](../review-method.md). Keep repairs inside the current business batch: update its existing implementation checkpoint and plan execution evidence, retain its batch purpose and prior object/result references, and save a separate review/recheck. A failed batch is not a new implementation batch. Repair findings within the existing commission and recheck the changed object; route requirement/design changes or missing permission to their actual decision. Do not expand a batch review into full formal verification or a repository-wide rewrite.
+
+## Outputs and result
+
+A batch REV with reviewOf naming the actual implementation/repair runs, no overall flag, and a concise finding/repair conclusion. Update the single plan execution table and references; keep review details here, not copied into plan/testing.
+
+## Completion and stop
+
+Keep implementation and review facts separate. Continue authorized repair/recheck inside this batch; report and stop after its passing review, or at an actual unresolved dependency. Next-batch continuation remains a user boundary. Merely having one batch does not silently replace an overall review.

package/skills/aimship/references/reviews/overall.md

@@ -0,0 +1,21 @@
+# Review the whole change
+
+## Inputs
+
+The current requirement/design/contract/plan, all completed batches and repairs, their passing reviews, and the actual combined object.
+
+## Goal and scope
+
+Find cross-batch consistency, shared-rule and integration defects that individual batch reviews cannot establish. An explicit overall-review request commissions review, not automatic full testing or deployment.
+
+## Actions
+
+Apply the [shared review method](../review-method.md) to the combined scope, including repair changes. Inspect requirement coverage, shared boundaries, omissions and unresolved findings. Reference local checks without claiming formal runtime verification. If a single-batch commission explicitly covers both review responsibilities, examine and record both scopes; do not infer that commission from batch count alone.
+
+## Outputs and result
+
+An independent overall REV, overall:true and reviewOf covering all current implementation runs, including repairs. Preserve earlier review conclusions and name the exact reviewed basis.
+
+## Completion and stop
+
+Save the overall conclusion and concrete next action, then stop. A passing overall review permits subsequent authorized formal verification; it does not execute it. A failing review retains its findings and awaits the actual repair work/decision, without inventing a test result.

package/skills/aimship/references/reviews/recheck.md

@@ -0,0 +1,21 @@
+# Recheck repaired work
+
+## Inputs
+
+The original REV/findings, actual repair basis, changed implementation object and applicable previous review coverage.
+
+## Goal and scope
+
+Determine whether those findings are resolved and whether the repair creates related defects; preserve the original batch or overall review responsibility.
+
+## Actions
+
+Apply the [shared review method](../review-method.md). Examine the repair and affected dependencies, not an uncommissioned full verification suite. Record open/deferred issues honestly. If the original review was overall, retain overall scope and cover the complete current implementation object.
+
+## Outputs and result
+
+A new REV with the actual reviewOf coverage and historyResultRefs pointing to the superseded review result. Keep old findings and attach the disposition/rechecked object. A correction within the current failed batch updates that batch’s existing implementation checkpoint and execution evidence; the new recheck retains the failed REV. Separate repair work after completed batches uses workType:repair and the actual repairOf basis; it is not a new business batch.
+
+## Completion and stop
+
+A batch recheck completes the batch work unit and stops there. An overall recheck saves its conclusion and stops before formal verification. Unresolved dependencies remain explicit; a new REV without actual examination cannot resolve a failure.

package/skills/aimship/references/routing.md

@@ -0,0 +1,16 @@
+# Route the current request
+
+The user activates one Aimship entry. Read the bound core, this routing guide and only the selected stage contract; modules organize instructions, not agents or isolated execution contexts. No host-specific nested Skill-call API is assumed.
+
+| Intent/current stop | Route and scope |
+| --- | --- |
+| New concrete request | Preserve the commission and locate/create the intended delivery using core initialization; begin requirement work. |
+| Continue a known delivery | Read its identity/state/current materials. Resume pending approval, clarification or unfinished effects before selecting subsequent work. |
+| A specified stage | Match the request to the saved arrangement and actual scope. Check prerequisites and current-content approvals; record a changed/limited commission where actually requested. A stage name is not permission to bypass its inputs. |
+| Implement the next authorized batch | Load [implement](stages/implement.md). Its work unit includes local checks, batch review and authorized repair/recheck; save separate internal runs, then stop at batch completion. |
+| Review | Load the [review dispatcher](stages/review.md) and its batch/overall/recheck module. Overall review alone does not commission full testing. |
+| Verify | Load [verify](stages/verify.md) after passing overall review; use the agreed coverage/groups and actual execution conditions. |
+
+Each stage contract has inputs, goal/scope, actions, outputs/result and completion/stop. Core owns the shared lifecycle; [document review](document-review.md), [source/change flow](sources-and-changes.md), [recovery](recovery.md) and [document patterns](document-patterns.md) own their respective shared rules. Do not copy the whole core into each module or load every stage on every turn.
+
+At a genuine ambiguous goal/location/scope, clarify only that gap. Module routing grants no new engineering permission, automation, deployment or approval.