abelien-harness 0.10.0 → 0.13.0

package/skills/abelien-workspace/assets/journey-stage-plan.json

@@ -1,7 +1,7 @@
 {
   "schema": "abelien.journey-stage-plan.v1",
-  "plan_version": "2026-10-14.1",
-  "description": "按意图的作品旅程阶段计划。orders 是自动推进的主线；side 阶段由宿主守卫按真实结果触发。每个阶段的 directives 是领域规则（宿主中立），宿主把它们附在自己的执行说明（工具名、字段）之后，不改写、不删减。每个阶段的 actions 是该阶段允许的动作，取自 action_catalog（宿主中立的动作目录），按意图不同时写在 action_variants；宿主把动作映射为自己的工具，自动阶段只放行这些工具和宿主自己的只读工具，不另维护工具白名单。旅程规则的唯一正文是 references/user-journey.md，本计划是其机读派生：orders 对应 A1 通过之后到交付首版（§2.4、§5），side 对应首版前后由真实结果触发的旁路（§5.3、§6、§7）；两处不一致时以正文为准，改正文后同步本计划并升 plan_version。",
+  "plan_version": "2026-10-14.4",
+  "description": "按意图的作品旅程阶段计划，是 A1 通过之后到交付首版这一段（及其旁路）的阶段顺序、阶段目标、领域规则与允许动作的唯一来源；Web、Claude Code、Codex 等所有宿主都经 workspace.journey-next 读取，不另维护阶段顺序或工具白名单。orders 是自动推进的主线；side 阶段由宿主守卫按真实结果触发。每个阶段的 directives 是领域规则（宿主中立），宿主把它们附在自己的执行说明（工具名、字段）之后，不改写、不删减。每个阶段的 actions 是该阶段允许的动作，取自 action_catalog（宿主中立的动作目录），按意图不同时写在 action_variants；宿主把动作映射为自己的工具，自动阶段只放行这些工具和宿主自己的只读工具。references/journey-stage-plan.md（阶段计划一览）由 tools/render-journey-plan.mjs 从本计划生成；references/user-journey.md 维护 A1–C 判定与产品规则，本计划不得与之冲突。gate 是环节结束后由宿主固定发出的确认卡（问题、选项与各选项的动作，动作取自 gate_actions；answers 是非继续动作的领域规则），waits_for 是该阶段开始前必须已答的确认卡所属阶段（按意图不同时写在 waits_for_variants），卡片不等人，只有声明了 waits_for 的阶段才停下等答复。改动本计划须升 plan_version、在 test/journey-next.test.mjs 的 HISTORY 追加一行，并重新生成一览。",
   "artifacts": ["reference_final", "concept_image", "hardware", "appearance_baseline", "cad_candidate", "review"],
   "orders": {
     "create": ["reference", "concept", "hardware", "real_image", "cad", "review"],
@@ -37,16 +37,33 @@
     "visual.review": "按契约审查这一版的实际渲染",
     "question.card": "发布一张问题卡，等待用户回答"
   },
+  "gate_actions": {
+    "continue": "确认这一环节的结果；等它的环节随即可以继续",
+    "regenerate": "需求不变，重新生成这一环节的结果，旧结果保留",
+    "revise": "把用户的回答整理成需求修改，形成新的需求版本，从受影响的环节重做"
+  },
   "stages": {
     "identify": {
       "goal": "识别用户要的现成产品，并取得规格与拆解资料",
       "directives": [
         "调用 reference.research 执行识别与拆解资料检索（用途 identify / teardown；用户给了链接时先读链接），再读取证据，用 reference.finalize 提交识别判断。",
         "识别不确定时按最可能的候选继续，保留其他候选供用户切换；首版之前默认不向用户提问。",
-        "例外：用户的硬要求缺少取值、无法合理默认，且按默认继续会做出错误结果（例如要求放进某个卡槽却没给尺寸）时，可以在首版之前发一张问题卡；整个首版之前至多一张，最多三题、每题最多三个选项；其余未定项一律按默认处理。",
-        "完成后展示识别出的原产品图并注明来源（页面与站点），再用一两句话说明识别为哪款产品、依据是什么，以及比例核对结果。"
+        "完成后展示识别出的原产品图并注明来源（页面与站点），再用一两句话说明识别为哪款产品、依据是什么，以及比例核对结果。",
+        "本环节结束后系统会固定发一张确认卡请用户确认，这张卡不由你发；正文不要另问用户是否满意、要不要继续。"
       ],
-      "actions": ["reference.research", "reference.page", "reference.finalize"]
+      "actions": ["reference.research", "reference.page", "reference.finalize"],
+      "gate": {
+        "question": "是不是这一款？",
+        "options": [
+          {"label": "是这款", "action": "continue"},
+          {"label": "换另一个候选", "action": "revise"},
+          {"label": "我直接说型号", "action": "revise"}
+        ],
+        "answers": {
+          "revise": "用户要换识别结果：把用户指定的型号或选中的其他候选整理成需求修改（连同 context 与 intent.keep），形成新的需求版本后系统重新识别；用户只选了“换另一个候选”、没说是哪一款时，先发一张问题卡问清楚。"
+        }
+      },
+      "waits_for": []
     },
     "reference": {
       "goal": "检索相似产品，作为尺寸、结构、器件与实现方式的参考",
@@ -54,24 +71,53 @@
         "调用 reference.research 检索相似产品（用途 similar），再读取证据，用 reference.finalize 提交借用什么、为什么合适、哪些不照搬。",
         "找不到完整的相似产品时，按声学、供电、交互等子系统分别参考，不硬凑数量；首版之前默认不向用户提问。",
         "相似产品只作参考，不成为可编辑模板，也不自动采用其 BOM。",
-        "例外：用户的硬要求缺少取值、无法合理默认，且按默认继续会做出错误结果（例如要求放进某个卡槽却没给尺寸）时，可以在首版之前发一张问题卡；整个首版之前至多一张，最多三题、每题最多三个选项；其余未定项一律按默认处理。"
+        "本环节结束后系统会固定发一张确认卡请用户确认，这张卡不由你发；正文不要另问用户是否满意、要不要继续。"
       ],
-      "actions": ["reference.research", "reference.page", "reference.finalize"]
+      "actions": ["reference.research", "reference.page", "reference.finalize"],
+      "gate": {
+        "question": "参考这几款可以吗？",
+        "options": [
+          {"label": "可以", "action": "continue"},
+          {"label": "换一批", "action": "revise"},
+          {"label": "我补充参考", "action": "revise"}
+        ],
+        "answers": {
+          "revise": "用户要换参考：把要避开的参考或要补充的参考产品整理成需求修改，形成新的需求版本后系统重新检索参考；用户只选了“我补充参考”、没说是哪款时，先发一张问题卡问清楚。"
+        }
+      },
+      "waits_for": []
     },
     "concept": {
       "goal": "生成第一张概念图",
       "directives": [
         "按外观目标生成第一张概念图；需求没说到的外观细节按常见做法补全，首版之前默认不向用户提问。",
         "出图后用一两句话告诉用户并结束本轮，硬件选型在下一阶段进行。",
-        "例外：用户的硬要求缺少取值、无法合理默认，且按默认继续会做出错误结果（例如要求放进某个卡槽却没给尺寸）时，可以在首版之前发一张问题卡；整个首版之前至多一张，最多三题、每题最多三个选项；其余未定项一律按默认处理。"
+        "本环节结束后系统会固定发一张确认卡请用户确认，这张卡不由你发；正文不要另问用户是否满意、要不要继续。"
       ],
       "variants": {
         "modify": [
           "以识别出的原产品图为输入生成修改后的图，只改用户要求修改的部分，保留清单中的特征。",
-          "出图后用一两句话说明改了什么、保留了什么，并结束本轮；硬件选型在下一阶段进行。"
+          "出图后用一两句话说明改了什么、保留了什么，并结束本轮；硬件选型在下一阶段进行。",
+          "本环节结束后系统会固定发一张确认卡请用户确认，这张卡不由你发；正文不要另问用户是否满意、要不要继续。"
         ]
       },
-      "actions": ["studio.prepare", "image.generate"]
+      "actions": ["studio.prepare", "image.generate"],
+      "gate": {
+        "question": "用这张图吗？",
+        "options": [
+          {"label": "就用这张", "action": "continue"},
+          {"label": "重新生成一张", "action": "regenerate"},
+          {"label": "调整方向", "action": "revise"}
+        ],
+        "answers": {
+          "regenerate": "需求不变，再生成一张概念图：用 studio.prepare 准备新的出图版本（这是用户要求的重画），再用 image.generate 生成；旧图保留。",
+          "revise": "用户要调整外观方向：把回答里的外观要求整理成需求修改，形成新的需求版本后系统重定外观目标再画；回答没说具体怎么调时，先发一张问题卡问清楚。"
+        }
+      },
+      "waits_for": [],
+      "waits_for_variants": {
+        "modify": ["identify"]
+      }
     },
     "hardware": {
       "goal": "为当前需求选型并登记",
@@ -79,17 +125,32 @@
         "主要元器件选定即可；供电、电池、联网方式等用户没说的未定项按推荐默认值选型，并作为待确认项登记，首版之前默认不向用户提问。",
         "不要修改需求，也不要出图。",
         "登记后用一两句话说明选了什么、哪些按默认值处理，然后结束本轮；待确认项在首版之后合并成一张问题卡统一询问。",
-        "例外：用户的硬要求缺少取值、无法合理默认，且按默认继续会做出错误结果（例如要求放进某个卡槽却没给尺寸）时，可以在首版之前发一张问题卡；整个首版之前至多一张，最多三题、每题最多三个选项；其余未定项一律按默认处理。"
+        "本环节结束后系统会固定发一张确认卡请用户确认，这张卡不由你发；正文不要另问用户是否满意、要不要继续。"
       ],
       "variants": {
         "restore": [
           "以参考证据中的来源产品规格与拆解资料为对照逐项选择替代件，区分原件、替代件与未知；主要元器件选定即可，未定项按推荐默认值登记为待确认项，首版之前默认不向用户提问。",
           "不要修改需求，也不要出图。",
           "登记后用一两句话说明替代关系与默认值，然后结束本轮；待确认项在首版之后合并成一张问题卡统一询问。",
-          "例外：用户的硬要求缺少取值、无法合理默认，且按默认继续会做出错误结果（例如要求放进某个卡槽却没给尺寸）时，可以在首版之前发一张问题卡；整个首版之前至多一张，最多三题、每题最多三个选项；其余未定项一律按默认处理。"
+          "本环节结束后系统会固定发一张确认卡请用户确认，这张卡不由你发；正文不要另问用户是否满意、要不要继续。"
         ]
       },
-      "actions": ["component.search", "hardware.guide", "hardware.wiki", "hardware.resource", "hardware.workflow", "hardware.web-extract", "hardware.prepare"]
+      "actions": ["component.search", "hardware.guide", "hardware.wiki", "hardware.resource", "hardware.workflow", "hardware.web-extract", "hardware.prepare"],
+      "gate": {
+        "question": "用这套硬件吗？",
+        "options": [
+          {"label": "用这套", "action": "continue"},
+          {"label": "换某个零件", "action": "revise"},
+          {"label": "改要求", "action": "revise"}
+        ],
+        "answers": {
+          "revise": "用户要改硬件：把要换的零件或新的要求整理成需求修改，形成新的需求版本后系统按新需求整套重新选型；回答没说换哪个零件、改成什么时，先发一张问题卡问清楚。"
+        }
+      },
+      "waits_for": [],
+      "waits_for_variants": {
+        "restore": ["identify"]
+      }
     },
     "hardware_reselect": {
       "goal": "当前硬件放不下用户的硬尺寸上限或锁定分区时重新选型",
@@ -129,6 +190,11 @@
       "actions": ["studio.prepare"],
       "action_variants": {
         "restore": ["studio.prepare", "image.import"]
+      },
+      "waits_for": ["concept", "hardware"],
+      "waits_for_variants": {
+        "restore": ["identify", "hardware"],
+        "remix": ["concept"]
       }
     },
     "cad": {
@@ -147,7 +213,8 @@
           "true": "外形尺寸与比例已锁定：不得放大或缩小外壳；装不下时停止建模，先交回硬件换件，仍不行再调整结构骨架，改外形必须由用户决定。"
         }
       },
-      "actions": ["cad.build"]
+      "actions": ["cad.build"],
+      "waits_for": []
     },
     "fallback": {
       "goal": "建模没有产出可展示的 CAD 时，由宿主生成标注清楚的简化草模",
@@ -168,7 +235,8 @@
           "不要重新建模、不要重新出图、不要修改需求；待答的问题卡保持原样，不代用户回答。"
         ]
       },
-      "actions": ["visual.review"]
+      "actions": ["visual.review"],
+      "waits_for": []
     },
     "repair": {
       "goal": "只修正检查发现的问题",
@@ -180,12 +248,13 @@
       "actions": ["cad.build"]
     },
     "questions": {
-      "goal": "首版之后合并询问按默认处理的事项",
+      "goal": "首版之后问用户这一版怎么样，并合并询问按默认处理的事项",
       "directives": [
-        "首版之后，读取已登记的硬件选型与系统假设，把首版之前按默认处理、至今仍按默认处理的事项合并成一张问题卡：最多三题，每题最多三个可直接选的方案，第一个选项写首版当前采用的默认值并注明“（首版已按此）”。",
+        "首版之后发一张问题卡，第一题固定问“这一版怎么样？”，选项依次为“就用这一版”“继续修改”“有问题要说明”；选“就用这一版”只是表态，采用仍要用户点「采用」。",
+        "其余最多两题：读取已登记的硬件选型与系统假设，把首版之前按默认处理、至今仍按默认处理的事项合并进这张卡，每题最多三个可直接选的方案，第一个选项写首版当前采用的默认值并注明“（首版已按此）”。",
         "这张卡每次按当前状态重新生成，不是保存的问题队列：用户已改掉或已不再适用的默认不再出现，首版之前按例外问过并已答复的事项不重复询问。",
         "意图、目标深度或型号识别仍有疑问时，可以作为其中一题，第一个选项写首版采用的判断。",
-        "没有待确认项就不发卡，一两句话说明后结束本轮。",
+        "没有待确认项时这张卡只有第一题。",
         "不要修改需求、重新选型、建模或出图；用户的答复作为对首版的修订处理。"
       ],
       "actions": ["question.card"]

package/skills/abelien-workspace/domain.json

@@ -1,13 +1,13 @@
 {
   "name": "abelien-workspace",
-  "version": "1.8.0",
-  "description": "作品旅程、PRD 与业务契约；user-journey 由 Agent 驱动，draft 供真实硬件阶段使用；不声明假 PRD、确认、报价或支付能力",
+  "version": "2.1.0",
+  "description": "作品旅程、PRD 与业务契约；作品推进由宿主按 workspace.journey-next 的阶段计划进行，不是 workflow；draft 供真实硬件阶段使用；不声明假 PRD、确认、报价或支付能力",
   "resources": [
     "draft"
   ],
   "capabilities": {
     "workspace.journey-next": {
-      "description": "按意图（create / restore / modify / remix）的阶段计划给出下一阶段与该阶段的领域规则；纯计算，不联网、不写资源。宿主先跑完自己的守卫，再把 directives 附在自己的执行说明之后；actions 是该阶段允许的宿主中立动作，宿主据此放行自己的工具",
+      "description": "按意图（create / restore / modify / remix）的阶段计划给出下一阶段与该阶段的领域规则；纯计算，不联网、不写资源。宿主先跑完自己的守卫，再把 directives 附在自己的执行说明之后；actions 是该阶段允许的宿主中立动作，宿主据此放行自己的工具；gate 是该阶段结束后宿主固定发出的确认卡，waits_for 是该阶段开始前必须已答的确认卡所属阶段",
       "adapter": {
         "type": "module",
         "path": "scripts/journey-next.mjs",
@@ -24,6 +24,7 @@
         "arrays": [
           "directives",
           "actions",
+          "waits_for",
           "order",
           "completed"
         ]

package/skills/abelien-workspace/references/hardware-journey-orchestration.md

@@ -6,7 +6,7 @@
 
 - 没有已验证硬件方案、要形成正式初选：运行 `user-journey-hardware`。Agent 先做需求到三级槽位分类，再调用同级 `abelien-hardware-selection` 的 `hardware.select`；只有返回的 `hardware-selection` 通过门禁后才算完成正式硬件阶段。
 - 只需要研究 OSS 候选、暂不形成正式初选：运行 `user-journey-hardware-candidates`。Agent 先调用 `hardware.search` 从 OSS 分类索引读取 Top-K 最新候选 Wiki，再比较 `adapt_system` 或 `assemble_new` 并由 `hardware.finalize` 保存 `hardware-proposal`；这个提案不能通过正式硬件门，也不能直接开始算法阶段。
-- 同一次任务还要完成算法选型：运行 `user-journey-hardware-algorithm`。硬件阶段门通过后，当前 run 自动进入算法研究和 `algorithm.finalize`，无需由前端另起第二个 workflow。
+- 同一次任务还要完成算法选型：硬件阶段门通过后，由宿主另起 `user-journey-algorithm`（同级 `abelien-algorithm`），输入已验证硬件与完整 reactions。硬件与算法是两个领域，不在同一个 run 里串接。
 - 已有已验证方案，用户明确修改其中一项：运行 `user-journey-hardware-revise`。输入只包含当前 draft ID、基线选型 ID/版本和最新变更请求；不要把整段对话塞入硬件服务。
 - 用户改变了产品目标或大量功能，而不是局部部件：形成新的需求版本，再运行新建流程，不把它伪装成局部修订。
 
@@ -16,13 +16,13 @@ OSS Wiki 读取由 `abelien-hardware` 的本地 module adapter 实现，通用
 
 ## 完整智能体
 
-完整产品智能体仍可使用“会话路由器 + 多个有阶段门的 workflow”；`user-journey-hardware-algorithm` 是硬件与算法这两个顺序阶段的组合入口，不取代局部修订等独立流程。每阶段读取上游已验证资源并产出版本化资源；变更后只把依赖图中受影响的下游阶段标为 stale。例如电池尺寸变化通常使供电和结构验证失效，算力/接口未变化时不应重跑算法选型。
+作品推进由宿主持有，按 `workspace.journey-next` 取阶段，再按阶段运行各领域自己的 workflow；workflow 只承载单一领域内的多步流程，不跨领域串接，也不替宿主判定作品完成（`test/workflow-scope.test.mjs` 把这条钉成门禁）。每阶段读取上游已验证资源并产出版本化资源；变更后只把依赖图中受影响的下游阶段标为 stale。例如电池尺寸变化通常使供电和结构验证失效，算力/接口未变化时不应重跑算法选型。
 
 待内核确有跨 workflow 调用、条件边和有界重试需求时，再设计 workflow v2；必须同时定义最大迭代次数、每次迭代记录、幂等键、取消语义和恢复行为。在这些执行语义落地前，由前端 Agent 根据终态和资源状态选择下一 workflow，不能把业务路由伪装成已由内核保证。
 
 ## Library review and online supplement
 
-All three new hardware definitions now share `review-hardware-candidates` -> `hardware.web-search` -> `extract-web-hardware` -> `hardware.web-merge` -> the existing comparison and formal select/proposal finalizer. Empty suitable-library unresolved lists cause no network calls. Every zero/all-unsuitable slot requires search, retaining user requirements and quantity. Persisted evidence is present in the extraction pause context. Formal select uses `merge-hardware-web.resource.id` and rereads original recall/evidence; Web preflight must provide these original completed-step resources from the same workdir. Network candidates stay needs_confirmation and envelope-only, with source/engineering unknowns. See [architecture](../../../docs/architecture/hardware-online-fallback.md). Existing running definitions are not edited; drift protection remains.
+Both new-selection hardware definitions (`user-journey-hardware` and `user-journey-hardware-candidates`) share `review-hardware-candidates` -> `hardware.web-search` -> `extract-web-hardware` -> `hardware.web-merge` -> the existing comparison and formal select/proposal finalizer. Empty suitable-library unresolved lists cause no network calls. Every zero/all-unsuitable slot requires search, retaining user requirements and quantity. Persisted evidence is present in the extraction pause context. Formal select uses `merge-hardware-web.resource.id` and rereads original recall/evidence; Web preflight must provide these original completed-step resources from the same workdir. Network candidates stay needs_confirmation and envelope-only, with source/engineering unknowns. See [architecture](../../../docs/architecture/hardware-online-fallback.md). Existing running definitions are not edited; drift protection remains.
 
 Prismer Parse pending holds the original search-hardware-web cursor as awaiting_external; no extract/merge/select runs. The controlled {runId} host resumes the same frozen args/resource with `workflow resume`; task progress uses fixed original-task GET, received synchronous POST results are reused and only undispatched original-plan operations may first POST. Unknown paid effects/failed terminal runs cannot restart. Running SIGKILL snapshots require same-ID latest-checkpoint/source/plan/fence-owner verification; see the hardware evidence architecture for exact fields.
 

package/skills/abelien-workspace/references/harness-binding.md

@@ -11,7 +11,7 @@ node "$AB" --workdir "$WD" doctor
 node "$AB" --workdir "$WD" domain list
 node "$AB" --workdir "$WD" capability list
 node "$AB" --workdir "$WD" workflow list
-# 已有 runId：先取原始 status，识别新入口、旧实例或子流程
+# 已有 runId：先取原始 status，识别当前硬件运行还是已退役的旧实例
 node "$AB" --workdir "$WD" workflow status <runId>
 # 确认为当前定义的 awaiting_agent 步骤后，才读取 HTTL
 node "$AB" --workdir "$WD" workflow status <runId> --httl
@@ -30,13 +30,13 @@ skills/
   abelien-workspace/SKILL.md             作品业务契约入口
   abelien-workspace/references/          完整旅程、PRD 契约、领域模型与本调用说明
   abelien-workspace/domain.json          作品域、真实硬件阶段 draft 资源与 workspace.journey-next 声明
-  abelien-workspace/assets/              按意图的阶段计划 journey-stage-plan.json（机读，派生自 user-journey.md）
+  abelien-workspace/assets/              按意图的阶段计划 journey-stage-plan.json（自动段阶段与逐阶段规则的唯一来源）
   abelien-workspace/scripts/             journey-next.mjs（阶段计划解释器，纯计算）
-  abelien-workspace/workflows/           已可执行的线性工作流
+  abelien-workspace/workflows/           硬件领域内的线性工作流；作品推进不是 workflow
   abelien-hardware-selection/SKILL.md     真实硬件阶段的分类与服务指引
 ```
 
-guide 与 clarify 自身不声明新资源、适配器或实体状态机，故不增加空 `domain.json`。clarify 正文与共用表达规则自 2026-10-11 起以 harness 仓为唯一编辑源，直接在本包修改，不再从 abelienwebapplication 同步。它作为 `abelien-*` bundle 随安装器分发，真实调用复用已发现域包。workspace 维护 A1–C 业务条件，guide 按这些条件组织调用和对话，clarify 仅提供需求建议。完整 A/B/C 回流由 `user-journey` 中的 `drive-product-journey` Agent 步骤承载。JSON 的 `journey` 只供 Agent 阅读；当前引擎顺序执行 `steps`，不解释该契约里的条件分支或 jump。
+guide 与 clarify 自身不声明新资源、适配器或实体状态机，故不增加空 `domain.json`。clarify 正文与共用表达规则自 2026-10-11 起以 harness 仓为唯一编辑源，直接在本包修改，不再从 abelienwebapplication 同步。它作为 `abelien-*` bundle 随安装器分发，真实调用复用已发现域包。workspace 维护 A1–C 业务条件，guide 按这些条件组织调用和对话，clarify 仅提供需求建议。作品推进不由 workflow 承载：宿主持有作品事实、版本与任务，A1 通过之后的自动段按 `workspace.journey-next` 取阶段与规则，A1–C 的判定按[完整旅程](user-journey.md)；领域内的多步流程（硬件选型等）各跑自己的 workflow，每条只调用一个领域的能力，不替宿主判定作品完成。
 
 | 需要的事实 | 读取位置／含义 |
 | --- | --- |
@@ -55,11 +55,11 @@ stdout 的 `ok:true` 表示命令取得了回执。workflow 调用还必须检
 
 | 用户旅程所需能力 | 当前 Harness 对应与限制 |
 | --- | --- |
-| 按意图的下一阶段与阶段规则 | `workspace.journey-next`（本包 `domain.json` 唯一的 capability，`ab capability run workspace.journey-next --input '{"intent":"restore","artifacts":{"reference_final":true}}'`）：读取[阶段计划](../assets/journey-stage-plan.json)，返回下一阶段、`goal`、`directives`、`actions`（该阶段允许的宿主中立动作，宿主据此放行自己的工具）、`order`、`completed`、`locks` 与 `plan_version`。纯计算，不联网、不写资源、不读宿主状态；不判断 A1–C，也不代替宿主的结算、计费、预算、保底与幂等守卫。`stage` 只接受本意图的主线阶段与 `side` 旁路阶段，`artifacts`／`locks` 不用时省略、不传 null。阶段计划派生自[完整旅程](user-journey.md)，规则以旅程正文为准 |
+| 按意图的下一阶段与阶段规则 | `workspace.journey-next`（本包 `domain.json` 唯一的 capability，`ab capability run workspace.journey-next --input '{"intent":"restore","artifacts":{"reference_final":true}}'`）：读取[阶段计划](../assets/journey-stage-plan.json)，返回下一阶段、`goal`、`directives`、`actions`（该阶段允许的宿主中立动作，宿主据此放行自己的工具）、`order`、`completed`、`locks` 与 `plan_version`。纯计算，不联网、不写资源、不读宿主状态；不判断 A1–C，也不代替宿主的结算、计费、预算、保底与幂等守卫。`stage` 只接受本意图的主线阶段与 `side` 旁路阶段，`artifacts`／`locks` 不用时省略、不传 null。阶段计划是这一段阶段顺序与逐阶段规则的唯一来源，Web、Claude Code、Codex 都经本能力读取；「[阶段计划一览](journey-stage-plan.md)」由它生成 |
 | clarify 需求整理 | 同级 `abelien-clarify`：以当前操作和同版上下文换取 `result / questions / note`，不是 CLI capability，不写资源；结构可用其 `scripts/check_result.py` 校验。共用表达规则在同级 guide 的 references，由 guide 读一次注入。已移除旧 workspace.brief，不提供假澄清 |
 | 硬件候选检索与提案 | `user-journey-hardware-candidates` → `abelien-hardware`：`hardware.search`（OSS 检索）→ agent 比较整机与零部件候选 → `hardware.finalize`（保存 `hardware-proposal`）。提案不创建正式 `hardware-selection` 门，也不能直接开始算法阶段 |
-| 正式硬件选型 | `user-journey-hardware` / `user-journey-hardware-algorithm` → `abelien-hardware-selection` → `hardware.select`；本地模块回读真实召回并校验 Agent 判断，返回 hardware-selection；证据不足不可用候选提案代替 |
-| 算法与行为实现 | `user-journey-hardware-algorithm`（正式硬件过门后同 run 继续）或独立 `user-journey-algorithm` → `abelien-algorithm`：agent 按官方资料优先联网研究，`algorithm.finalize` 本地保存。两者的 `reactions` 输入取 clarify Requirements 的 `reaction[]` 原样传入 |
+| 正式硬件选型 | `user-journey-hardware` → `abelien-hardware-selection` → `hardware.select`；本地模块回读真实召回并校验 Agent 判断，返回 hardware-selection；证据不足不可用候选提案代替 |
+| 算法与行为实现 | 正式硬件过门后，宿主另行启动 `user-journey-algorithm` → `abelien-algorithm`：agent 按官方资料优先联网研究，`algorithm.finalize` 本地保存。输入为已验证硬件与 clarify Requirements 的 `reaction[]` 原样；硬件与算法不在同一个 run 里串接 |
 | 外观／ID editing 与视觉审查 | 同级 `abelien-appearance`：维护轮廓、比例、CMF、部位与参考匹配目标，实际查看 structure 的本版渲染。没有注册 `appearance.*` 产品 capability；宿主须具备真实图片读取／编辑能力，不能把旧外观 mock 当成现行实现 |
 | 结构与装配 | 同级 `abelien-structure`：空间约束、CAD复用、Build123d与几何检查。通用CLI未注册structure.*产品能力；Web宿主另有隔离Worker和structure_submit/status/cancel，生成与基础检查不代表视觉/完整装配/采用 |
 | 图生 3D | 同级 `abelien-3dgen` 的真实 provider 命令通常供 appearance 按需调用，再把候选网格交 structure 作为工程参考；生成网格不等于参数化 CAD、视觉 pass、结构采用或装配验证 |
@@ -69,32 +69,38 @@ stdout 的 `ok:true` 表示命令取得了回执。workflow 调用还必须检
 | 可选交互邀请卡片 | 按旅程 §4.1 呈现继续细化／先收尾两个选项；宿主须支持非阻塞操作选择，不能直接套用必要 question 的 pending 门禁或完成 handoff 前提。尚未绑定时不声称已弹卡，不虚构 kind／action key |
 | 产品问题工具接续与引导 | 见 [Agent Card 协议](../../../docs/architecture/question-card.md)：clarify/ACL 不是工具。宿主原生 `publish_agent_card(kind=question)` 持久等待，用户独立 HTTP 提交后以原调用的 tool 结果接续，不包装成 User 答案。2026-10-12 本地 Web v3 接线与 Harness／外部宿主分别核验；当前 Harness broker 尚未注册，handoff 不在本地注册表，不能据文档调用 `ab capability` 或声称受控导航已实现。只在真实完成且宿主已接导航时选择注册 action key，由用户点击 |
 | 逐轮 PRD 条目维护 | 通用CLI不内置产品写库；Web从已持久facts派生现行七块模板PRD/BOM、来源/假设/未知，不能可靠映射的实现保留同版附录。缺宿主时只交接待登记差异 |
-| 版本采用、确认及 PRD 导出 | Web product_adopt只接真实同版候选，确认仅用户版本绑定concept命令；租约事务保存私有不可变快照、授权JSON/Markdown导出，主旅程通过可信verifyCompletion核对回执。原生CLI缺宿主仍失败关闭；旧workspace.getPrd/confirmPlan不可替代 |
+| 版本采用、确认及 PRD 导出 | Web product_adopt只接真实同版候选，确认仅用户版本绑定concept命令；租约事务保存私有不可变快照、授权JSON/Markdown导出，确认与交付回执由宿主核对，不经任何 workflow。原生CLI缺宿主仍失败关闭；旧workspace.getPrd/confirmPlan不可替代 |
 
 以后新增绑定时，以实际 `domain.json`、workflow、输入／输出契约为准，再更新本表；不能凭名称相近推定等价。
 
 `user-journey-mock` 及全部 workspace mock 已移除。`abelien-hardware` 仍有独立示例能力，仅在明确演示时使用，不能替代产品能力；“继续修改”不等于 `cancel`。
 
-## 产品旅程入口的驱动与恢复
+<a id="host-driven-journey"></a>
 
-新入口为本包的 [user-journey.json](../workflows/user-journey.json)。先读 [完整规则](user-journey.md) 及原 JSON 的 `journey`；后者不会自动进入 HTTL context。启动需要 prompt，已有真实作品可附 productContextRef，二创附来源版本与资产／授权引用；这些附加字段由 Agent 核对，不是内核校验器。
+## 作品推进：宿主持有状态，按 journey-next 取阶段
+
+作品推进没有 workflow。任何宿主（Web、Claude Code、Codex）都按同一套做法推进，旅程规则只有正文与阶段计划两处来源：
+
+1. **回读作品事实。** 从宿主／产品服务取需求（含 clarify 保存的 `intent`）、已保存产物、采用版本、待答卡与任务。上一轮的推断不当作当前事实；缺产品写入接口时只交接待登记差异，不另存第二份作品状态。
+2. **A1 之前。** 按[完整旅程](user-journey.md) §4 与 clarify 整理需求，A1 的判定按正文。
+3. **A1 通过后到交付首版。** 把已保存产物映射为 `artifacts` 调用 `workspace.journey-next`；旁路阶段（重选、取舍、保底、修复、首版后合并提问）由宿主守卫按真实结果决定后以 `stage` 传入。按返回的 `goal` 与 `directives` 执行，只用 `actions` 对应的工具或能力；领域多步流程运行各自的 workflow（硬件见下文「硬件阶段实际驱动」）。
+4. **首版之后。** B1／B2／B3／C 按正文；修改、必要问题与确认都由宿主保存，不推进任何 workflow。
 
 ```bash
-node "$AB" --workdir "$WD" workflow run user-journey --input '{"prompt":"用户本轮真实创作意图"}'
-node "$AB" --workdir "$WD" workflow status <runId> --httl
+node "$AB" --workdir "$WD" capability run workspace.journey-next --input '{"intent":"create","artifacts":{"reference_final":true}}'
 ```
 
-在 `drive-product-journey` 内按 A1–C 跨轮推进，按需运行真实子流程，不递归启动主入口。首版展示、必要问题、普通修改、待任务或缺能力都不 advance；从宿主恢复最新事件与采用版本，启动 input 不会随对话自动更新。必要条件未齐时保留 awaiting_agent 并停止本轮等待新事实。
+首版展示、必要问题、普通修改、待任务或缺能力时，停止本轮并说明下一步，等新事实到来再按上面的顺序重新判断；不为“保持位置”启动或挂起任何 run。
 
 Studio 修改与首次创建均不设固定修复次数。沿用同一个 operation、根预算和上游身份，由剩余预算、有效租约、超时、用户取消及确定的冲突报告控制继续执行；同一父候选不得重复发起同一步修复。`repairCount` 是非负整数，非空 `repairOrdinal` 为正整数且不得大于计数。解析回执不代表授权执行，也不代表目标数据库已升级；预算预占与原子计数仍由 Web 负责。
 
-点击“随时收尾”由宿主切换成果体验并收起编辑面板，不提交 workflow 完成，也不取消作品。真实任务与确认条件独立保留；后续结果不自动恢复面板或追问。返回编辑、播放／重置演示、查看或导出草稿都不重启主入口、不升产品版本。
+点击“随时收尾”由宿主切换成果体验并收起编辑面板，不取消作品。真实任务与确认条件独立保留；后续结果不自动恢复面板或追问。返回编辑、播放／重置演示、查看或导出草稿都不重新开始推进、不升产品版本。
 
-必要答卡等待只属于宿主工具生命周期：保存原 assistant 调用及私有检查点后结束 HTTP／Worker，收到用户决定后以匹配的 tool 结果发起下一次模型请求。原任务／toolCallId 不随后继物理 run 改变；答卡与发卡都保持 Harness awaiting_agent，不提交 advance。完整 wire、幂等、部分回答、旧卡与安装边界见 Agent Card 协议 §5–§8。
+必要答卡等待只属于宿主工具生命周期：保存原 assistant 调用及私有检查点后结束 HTTP／Worker，收到用户决定后以匹配的 tool 结果发起下一次模型请求。原任务／toolCallId 不随后继物理 run 改变；发卡与答卡都不改变任何 workflow 的状态。完整 wire、幂等、部分回答、旧卡与安装边界见 Agent Card 协议 §5–§8。
 
-同版确认事件经 B3 复核、快照真实保存且真实交付状态已交代后，按 replySchema 提交一次交接。PRD/BOM／分享／视频分别注明已就绪、进行中、失败或未接入及依据；预订不是必经步骤。若产品已接 `publish_agent_card(handoff)`，可在完成回执后引导用户主动点击“去保存与预约”；未接时只给普通入口，不伪造卡片。页面打开不等于预约、订单或支付成功。内核不解析业务语义或完整 replySchema，但 `completionGuard:workspace.confirmed-snapshot` 必须由可信宿主 `verifyCompletion` 回读确认、当前版本、组合检查、快照与交付状态。未接或未通过时返回 `WORKFLOW_COMPLETION_REQUIRED`，保持 awaiting_agent；普通 resource.put 和模型自填引用不能代替回执。done 仍不代表制造或实物交付通过。C 后修改按真实产品新工作版继续，已 done 的 run 不再 advance。
+同版确认事件经 B3 复核、快照真实保存且真实交付状态已交代后，才算交接完成。PRD/BOM／分享／视频分别注明已就绪、进行中、失败或未接入及依据；预订不是必经步骤。若产品已接 `publish_agent_card(handoff)`，可在完成回执后引导用户主动点击“去保存与预约”；未接时只给普通入口，不伪造卡片。页面打开不等于预约、订单或支付成功。确认、当前版本、组合检查、快照与交付状态都以宿主回执为准，普通 resource.put 和模型自填引用不能代替回执；内核不再提供 workflow 完成门。完成仍不代表制造或实物交付通过。C 后修改按真实产品新工作版继续。
 
-**迁移防误用：** 旧名 `user-journey` 的实例若仍含 25 步、review-views 或 review-plan，保留只读原始 status，不取新版 HTTL 或 advance。v1 重载同名最新定义，不冻结旧定义；不得手改 run 名或 cursor。此禁令**内核已强制**：advance 与 `status --httl` 比对实例记录的步序列与当前同名定义，不同构即报 `WORKFLOW_DRIFTED` 并拒绝（不落盘、不静默跳过未执行步骤）；只读 `status`／`list` 不比对，原始状态仍取得到。`user-journey-mock` 定义已删除，其实例也只读原始 status；不重放旧 mock，不改历史文件。真实作品从产品服务回读后按新入口接续。
+**旧运行：** 已退役的 `user-journey`（单步 `drive-product-journey` 与更早的 25 步）和 `user-journey-hardware-algorithm` 实例保留只读 `status`／`list`；`advance` 与 `status --httl` 被拒（定义已不随包分发时为 `WORKFLOW_NOT_FOUND`，冻结定义带已移除的完成门时为 `WORKFLOW_DRIFTED`），不落盘、不跳步。工作目录里冻结了原定义的 `user-journey-hardware-algorithm` 运行仍按原定义恢复。不得手改 run 名或 cursor；`user-journey-mock` 实例同样只读。新的工作按上面的做法从产品服务回读后接续：硬件用 `user-journey-hardware`，算法在硬件过门后另起 `user-journey-algorithm`。
 
 <a id="adopted-design-revision-loop"></a>
 

package/skills/abelien-workspace/references/journey-stage-plan.md

@@ -0,0 +1,220 @@
+# 阶段计划一览
+
+本页是[阶段计划](../assets/journey-stage-plan.json)的可读视图：A1 通过之后到交付首版这一段，按意图的阶段顺序、各阶段的目标、领域规则与允许的动作。由 `npm run render:journey-plan` 生成，测试比对两边一致，不要手改；要改就改计划、升 `plan_version` 并重新生成。A1–C 判定与产品规则见[完整用户旅程](user-journey.md#journey-stage-plan)，计划的规则不得与之冲突。
+
+<!-- journey-stage-plan:begin 由 tools/render-journey-plan.mjs 从 assets/journey-stage-plan.json 生成，勿手改 -->
+
+#### 阶段计划一览（plan_version 2026-10-14.4）
+
+| 意图 | 主线顺序 |
+| --- | --- |
+| 新创（create） | reference → concept → hardware → real_image → cad → review |
+| 还原（restore） | identify → hardware → real_image → cad → review |
+| 改现成（modify） | identify → concept → hardware → real_image → cad → review |
+| 二创（remix） | concept → real_image → cad → review |
+
+旁路阶段由宿主按真实结果触发：hardware_reselect、hardware_decision、fallback、repair、questions。还原（restore）默认锁定外形，其他意图默认不锁定。
+
+确认卡的动作：`continue`（确认这一环节的结果；等它的环节随即可以继续）、`regenerate`（需求不变，重新生成这一环节的结果，旧结果保留）、`revise`（把用户的回答整理成需求修改，形成新的需求版本，从受影响的环节重做）。卡片不等人，只有「开始前要等」列出的阶段才停下等用户答复。
+
+**identify**：识别用户要的现成产品，并取得规格与拆解资料
+
+完成标志：宿主已保存 `reference_final`。
+
+允许的动作：`reference.research`（收集识别、拆解资料或相似产品的检索证据）、`reference.page`（读取已收集页面的正文，挑选逐字引用）、`reference.finalize`（提交识别或借用判断，定稿参考证据）。
+
+规则：
+
+1. 调用 reference.research 执行识别与拆解资料检索（用途 identify / teardown；用户给了链接时先读链接），再读取证据，用 reference.finalize 提交识别判断。
+2. 识别不确定时按最可能的候选继续，保留其他候选供用户切换；首版之前默认不向用户提问。
+3. 完成后展示识别出的原产品图并注明来源（页面与站点），再用一两句话说明识别为哪款产品、依据是什么，以及比例核对结果。
+4. 本环节结束后系统会固定发一张确认卡请用户确认，这张卡不由你发；正文不要另问用户是否满意、要不要继续。
+
+环节结束后宿主发确认卡：「是不是这一款？」选项：是这款（`continue`）、换另一个候选（`revise`）、我直接说型号（`revise`）。
+- 选 `revise` 时：用户要换识别结果：把用户指定的型号或选中的其他候选整理成需求修改（连同 context 与 intent.keep），形成新的需求版本后系统重新识别；用户只选了“换另一个候选”、没说是哪一款时，先发一张问题卡问清楚。
+
+开始前要等：不等确认卡。
+
+**reference**：检索相似产品，作为尺寸、结构、器件与实现方式的参考
+
+完成标志：宿主已保存 `reference_final`。
+
+允许的动作：`reference.research`（收集识别、拆解资料或相似产品的检索证据）、`reference.page`（读取已收集页面的正文，挑选逐字引用）、`reference.finalize`（提交识别或借用判断，定稿参考证据）。
+
+规则：
+
+1. 调用 reference.research 检索相似产品（用途 similar），再读取证据，用 reference.finalize 提交借用什么、为什么合适、哪些不照搬。
+2. 找不到完整的相似产品时，按声学、供电、交互等子系统分别参考，不硬凑数量；首版之前默认不向用户提问。
+3. 相似产品只作参考，不成为可编辑模板，也不自动采用其 BOM。
+4. 本环节结束后系统会固定发一张确认卡请用户确认，这张卡不由你发；正文不要另问用户是否满意、要不要继续。
+
+环节结束后宿主发确认卡：「参考这几款可以吗？」选项：可以（`continue`）、换一批（`revise`）、我补充参考（`revise`）。
+- 选 `revise` 时：用户要换参考：把要避开的参考或要补充的参考产品整理成需求修改，形成新的需求版本后系统重新检索参考；用户只选了“我补充参考”、没说是哪款时，先发一张问题卡问清楚。
+
+开始前要等：不等确认卡。
+
+**concept**：生成第一张概念图
+
+完成标志：宿主已保存 `concept_image`。
+
+允许的动作：`studio.prepare`（保存外观目标，冻结本次创建的来源）、`image.generate`（生成概念图）。
+
+规则：
+
+1. 按外观目标生成第一张概念图；需求没说到的外观细节按常见做法补全，首版之前默认不向用户提问。
+2. 出图后用一两句话告诉用户并结束本轮，硬件选型在下一阶段进行。
+3. 本环节结束后系统会固定发一张确认卡请用户确认，这张卡不由你发；正文不要另问用户是否满意、要不要继续。
+
+改现成（modify）改用：
+
+1. 以识别出的原产品图为输入生成修改后的图，只改用户要求修改的部分，保留清单中的特征。
+2. 出图后用一两句话说明改了什么、保留了什么，并结束本轮；硬件选型在下一阶段进行。
+3. 本环节结束后系统会固定发一张确认卡请用户确认，这张卡不由你发；正文不要另问用户是否满意、要不要继续。
+
+环节结束后宿主发确认卡：「用这张图吗？」选项：就用这张（`continue`）、重新生成一张（`regenerate`）、调整方向（`revise`）。
+- 选 `regenerate` 时：需求不变，再生成一张概念图：用 studio.prepare 准备新的出图版本（这是用户要求的重画），再用 image.generate 生成；旧图保留。
+- 选 `revise` 时：用户要调整外观方向：把回答里的外观要求整理成需求修改，形成新的需求版本后系统重定外观目标再画；回答没说具体怎么调时，先发一张问题卡问清楚。
+
+开始前要等：不等确认卡。
+改现成（modify）改为：`identify` 的确认卡已答。
+
+**hardware**：为当前需求选型并登记
+
+完成标志：宿主已保存 `hardware`。
+
+允许的动作：`component.search`（检索组件库）、`hardware.guide`（按分类读取硬件选型指引）、`hardware.wiki`（读取候选型号的 Wiki 资料）、`hardware.resource`（读取已保存的硬件选型资源）、`hardware.workflow`（启动、查询、推进或恢复硬件选型工作流 user-journey-hardware）、`hardware.web-extract`（在网页证据暂停点，从已保存的网页中逐字抽取候选）、`hardware.prepare`（把通过校验的硬件选型登记为创建来源）。
+
+规则：
+
+1. 主要元器件选定即可；供电、电池、联网方式等用户没说的未定项按推荐默认值选型，并作为待确认项登记，首版之前默认不向用户提问。
+2. 不要修改需求，也不要出图。
+3. 登记后用一两句话说明选了什么、哪些按默认值处理，然后结束本轮；待确认项在首版之后合并成一张问题卡统一询问。
+4. 本环节结束后系统会固定发一张确认卡请用户确认，这张卡不由你发；正文不要另问用户是否满意、要不要继续。
+
+还原（restore）改用：
+
+1. 以参考证据中的来源产品规格与拆解资料为对照逐项选择替代件，区分原件、替代件与未知；主要元器件选定即可，未定项按推荐默认值登记为待确认项，首版之前默认不向用户提问。
+2. 不要修改需求，也不要出图。
+3. 登记后用一两句话说明替代关系与默认值，然后结束本轮；待确认项在首版之后合并成一张问题卡统一询问。
+4. 本环节结束后系统会固定发一张确认卡请用户确认，这张卡不由你发；正文不要另问用户是否满意、要不要继续。
+
+环节结束后宿主发确认卡：「用这套硬件吗？」选项：用这套（`continue`）、换某个零件（`revise`）、改要求（`revise`）。
+- 选 `revise` 时：用户要改硬件：把要换的零件或新的要求整理成需求修改，形成新的需求版本后系统按新需求整套重新选型；回答没说换哪个零件、改成什么时，先发一张问题卡问清楚。
+
+开始前要等：不等确认卡。
+还原（restore）改为：`identify` 的确认卡已答。
+
+**hardware_reselect**（旁路）：当前硬件放不下用户的硬尺寸上限或锁定分区时重新选型
+
+允许的动作：`question.card`（发布一张问题卡，等待用户回答）、`component.search`（检索组件库）、`hardware.guide`（按分类读取硬件选型指引）、`hardware.wiki`（读取候选型号的 Wiki 资料）、`hardware.resource`（读取已保存的硬件选型资源）、`hardware.workflow`（启动、查询、推进或恢复硬件选型工作流 user-journey-hardware）、`hardware.web-extract`（在网页证据暂停点，从已保存的网页中逐字抽取候选）、`hardware.prepare`（把通过校验的硬件选型登记为创建来源）。
+
+规则：
+
+1. 沿用当前需求的尺寸上限与尺寸检查重新选型，选择能装下的更小型号并登记；不要放宽用户尺寸，不要修改其他需求，不要出图。
+2. 旧选型只作来源证据，不能原样重新登记。
+3. 没有能装下的候选时，发一张问题卡，让用户在“换件”和“放宽尺寸”之间选择。
+
+外形已锁定（`locks.shape=true`）时插入为第 2 条：外形已锁定：槽位的 locked 分区（fit_envelope）同样不得放宽。没有能装下的候选时，先由结构在锁定外形内调整骨架（分区、层高、朝向）并给出新的 fit_envelope 后再选，仍装不下才发问题卡；此时“放宽尺寸”就是改外形，记为外观偏差。
+
+**hardware_decision**（旁路）：硬尺寸上限下没有能装下的候选，交用户取舍
+
+允许的动作：`question.card`（发布一张问题卡，等待用户回答）。
+
+规则：
+
+1. 本轮不重新选型、不修改需求、不出图；只发一张问题卡，让用户在“换件”和“放宽尺寸”之间选择，然后结束本轮。
+
+**real_image**：把外观基准图与当前硬件绑定
+
+完成标志：宿主已保存 `appearance_baseline`。
+
+允许的动作：`studio.prepare`（保存外观目标，冻结本次创建的来源）。
+还原（restore）改为：`studio.prepare`（保存外观目标，冻结本次创建的来源）、`image.import`（把识别出的真实产品图（没有时用用户上传图）结算为外观基准图）。
+
+规则：
+
+1. 将可复用的概念图绑定当前硬件，作为外观基准；缺少可用图片时回到概念图阶段，不在绑定阶段生图。
+2. 用户明确要求重画时，在用户回合准备新的图片版本，保留原产物。
+3. 不要修改需求；待答的问题卡保持原样，不代用户回答。
+
+还原（restore）改用：
+
+1. 将参考证据中识别出的真实产品图绑定当前硬件，作为外观基准；还原路径不生成概念图。
+2. 用户明确要求重画时，在用户回合准备新的图片版本，保留原产物。
+3. 不要修改需求；待答的问题卡保持原样，不代用户回答。
+
+开始前要等：`concept`、`hardware` 的确认卡已答。
+还原（restore）改为：`identify`、`hardware` 的确认卡已答。
+二创（remix）改为：`concept` 的确认卡已答。
+
+**cad**：形成可旋转的首版 CAD
+
+完成标志：宿主已保存 `cad_candidate`。
+
+允许的动作：`cad.build`（构建 CAD 候选，含几何检查与实际渲染）。
+
+规则：
+
+1. 优先快速形成可旋转的首版，结合外观基准图与真实硬件重建。
+2. 不缩放任何原生元器件；组件优先复用可信 CAD 的原生比例，只有缺少真实资产的项才明确标为包络；缺失的尺寸不要当作已知值。
+3. 坐落件相对结构骨架的基准面放置，不为每个组件手填独立的绝对坐标。
+4. 保留外观基准图的轮廓、长宽厚比例、圆角、屏幕和按钮相对位置及材质，按匹配的参考视角输出实际渲染，不用通用方盒替代。
+5. 失败就按回执诊断修正后重试；同一错误连续出现时换一种实现方式。
+6. 不要重新登记硬件、不要修改需求或重新出图；视觉审查在下一阶段进行；待答的问题卡保持原样，不代用户回答。
+
+开始前要等：不等确认卡。
+
+外形未锁定（`locks.shape=false`）时插入为第 2 条：外形未锁定：硬件放得下优先，但外壳只能在 appearance 认可的外观容差内调整尺寸与比例，并记录调整量及依据；超出容差时换件（交回硬件）或把取舍交给用户，不得自行放大外壳。
+
+外形已锁定（`locks.shape=true`）时插入为第 2 条：外形尺寸与比例已锁定：不得放大或缩小外壳；装不下时停止建模，先交回硬件换件，仍不行再调整结构骨架，改外形必须由用户决定。
+
+**fallback**（旁路）：建模没有产出可展示的 CAD 时，由宿主生成标注清楚的简化草模
+
+允许的动作：`cad.build`（构建 CAD 候选，含几何检查与实际渲染）。
+
+规则：
+
+1. 宿主按冻结的硬件尺寸生成一份已明确标注的简化草模；本轮不调用模型，不进行视觉审查。
+
+**review**：审查这一版的实际渲染
+
+完成标志：宿主已保存 `review`。
+
+允许的动作：`visual.review`（按契约审查这一版的实际渲染）。
+
+规则：
+
+1. 按契约审查这一版，审查对象全部取自 CAD 回执，不要猜；然后用一两句话向用户说明结果。
+2. 不要重新建模、不要重新出图、不要修改需求；待答的问题卡保持原样，不代用户回答。
+
+还原（restore）改用：
+
+1. 以识别出的真实产品图为基准，按契约审查这一版，审查对象全部取自 CAD 回执，不要猜；然后用一两句话说明与原产品的差异。
+2. 不要重新建模、不要重新出图、不要修改需求；待答的问题卡保持原样，不代用户回答。
+
+开始前要等：不等确认卡。
+
+**repair**（旁路）：只修正检查发现的问题
+
+允许的动作：`cad.build`（构建 CAD 候选，含几何检查与实际渲染）。
+
+规则：
+
+1. 只修改检查报告或几何分诊指出的冲突部位与实例，逐项保留其余实例；需要整体重建时按缺失的硬件与冲突证据完整重建。
+2. 尽量保留外观基准图的轮廓、比例、特征位置与材质；不缩放原生元器件。
+3. 不要修改需求、重新选型或重新出图；先完成轻量预览，视觉复检在下一阶段进行；待答的问题卡保持原样，不代用户回答。
+
+**questions**（旁路）：首版之后问用户这一版怎么样，并合并询问按默认处理的事项
+
+允许的动作：`question.card`（发布一张问题卡，等待用户回答）。
+
+规则：
+
+1. 首版之后发一张问题卡，第一题固定问“这一版怎么样？”，选项依次为“就用这一版”“继续修改”“有问题要说明”；选“就用这一版”只是表态，采用仍要用户点「采用」。
+2. 其余最多两题：读取已登记的硬件选型与系统假设，把首版之前按默认处理、至今仍按默认处理的事项合并进这张卡，每题最多三个可直接选的方案，第一个选项写首版当前采用的默认值并注明“（首版已按此）”。
+3. 这张卡每次按当前状态重新生成，不是保存的问题队列：用户已改掉或已不再适用的默认不再出现，首版之前按例外问过并已答复的事项不重复询问。
+4. 意图、目标深度或型号识别仍有疑问时，可以作为其中一题，第一个选项写首版采用的判断。
+5. 没有待确认项时这张卡只有第一题。
+6. 不要修改需求、重新选型、建模或出图；用户的答复作为对首版的修订处理。
+
+<!-- journey-stage-plan:end -->