abelien-harness 0.10.0 → 0.11.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +6 -6
- package/package.json +2 -1
- package/skills/abelien-guide/SKILL.md +2 -2
- package/skills/abelien-harness/references/workflow-spec.md +1 -3
- package/skills/abelien-harness/scripts/ab.mjs +5 -16
- package/skills/abelien-workspace/SKILL.md +9 -16
- package/skills/abelien-workspace/assets/journey-stage-plan.json +2 -2
- package/skills/abelien-workspace/domain.json +2 -2
- package/skills/abelien-workspace/references/hardware-journey-orchestration.md +3 -3
- package/skills/abelien-workspace/references/harness-binding.md +23 -17
- package/skills/abelien-workspace/references/journey-stage-plan.md +185 -0
- package/skills/abelien-workspace/references/user-journey.md +11 -7
- package/skills/abelien-workspace/workflows/definitions/0852e4949f5a6246880c1a26bf5ccaa42f8cda06b960e7c7ce234a0a176878f9.json +0 -229
- package/skills/abelien-workspace/workflows/definitions/1179e62586cf6d88c6820022a933f719b3b4eb3c0df0856fb7a0cc6341a9d630.json +0 -1
- package/skills/abelien-workspace/workflows/definitions/1a9afef5463f53e58222b3476c0002aa9703b5ced16f531e3224beb14a28f9a3.json +0 -229
- package/skills/abelien-workspace/workflows/definitions/32ed16198839c06c36b43acbada5ba74403e37b2d351058bd7ad3d5269f76722.json +0 -1
- package/skills/abelien-workspace/workflows/definitions/399ef372790b7330d0ef88ce5096e7f69943d4793de97b2ed6c25165a332612f.json +0 -230
- package/skills/abelien-workspace/workflows/definitions/748a70482fb2f775f6e5fd942c7873534cf3e59614c77381f812a9710d479743.json +0 -1
- package/skills/abelien-workspace/workflows/definitions/b780bf280d61596b43eb6dbc6a417cf8df1ec9a7ae79a6de10f048da9ed58729.json +0 -229
- package/skills/abelien-workspace/workflows/definitions/c1b5c6c653f0c4761d51efee923aafbbeea05512e7f35c60f7f7d36ec49fc1d1.json +0 -229
- package/skills/abelien-workspace/workflows/definitions/df147960a3f7c4d631f66a6b91a7891f8a37d25a50322cf09bdc9304195963b0.json +0 -1
- package/skills/abelien-workspace/workflows/user-journey-hardware-algorithm.json +0 -230
- package/skills/abelien-workspace/workflows/user-journey.json +0 -391
package/README.md
CHANGED
|
@@ -127,7 +127,7 @@ tool-receipt successor 与已有可信 runtime decision 也可以取得后续 co
|
|
|
127
127
|
现行入口不再维护独立的“主控业务提示词”。宿主指令只交代身份、skills 的用途、读取／调用方式与授权边界；具体对话调度放在 guide，作品旅程与业务规则放在 workspace，领域工作放在对应 skill。它们可以由同一个宿主 Agent 执行，不需要额外的主控 Agent；旧 controller 文档仅作历史参考，不与 skills 流程重复注入。
|
|
128
128
|
|
|
129
129
|
- 对话调度与沟通由 [abelien-guide](skills/abelien-guide/SKILL.md) 负责：组织上下文、调用领域 skill、呈现问题和结果；阶段、版本和确认条件统一读取 workspace。
|
|
130
|
-
- 作品规则由 [abelien-workspace](skills/abelien-workspace/SKILL.md) 维护：完整 A1–C
|
|
130
|
+
- 作品规则由 [abelien-workspace](skills/abelien-workspace/SKILL.md) 维护：完整 A1–C、采用与版本、组合检查、确认和交付恢复。作品推进没有 workflow：宿主持有作品状态，A1 通过之后的阶段与规则取 `workspace.journey-next`；产品服务的实际接入边界见 workspace 调用说明。
|
|
131
131
|
- 需求澄清为 [abelien-clarify](skills/abelien-clarify/SKILL.md)：把用户原话整理成 requirements、区分用户事实与系统假设、只问阻塞当前操作的问题，附只读校验脚本；共用表达规则随 guide 的 references 分发。两者自 2026-10-11 起以本仓为唯一编辑源，直接在 `skills/abelien-clarify/` 与 `skills/abelien-guide/references/` 修改，见下文「快照来源」。
|
|
132
132
|
- 各 bundle 均为标准 `SKILL.md`（含 name/description/license/compatibility，
|
|
133
133
|
兼容 claude-code / hermes / pi），agent 按 description 触发词路由；claude-code 与
|
|
@@ -142,19 +142,19 @@ tool-receipt successor 与已有可信 runtime decision 也可以取得后续 co
|
|
|
142
142
|
|
|
143
143
|
## 产品旅程与 PRD
|
|
144
144
|
|
|
145
|
-
完整规则统一维护在 [workspace 用户旅程](skills/abelien-workspace/references/user-journey.md)
|
|
145
|
+
完整规则统一维护在 [workspace 用户旅程](skills/abelien-workspace/references/user-journey.md)，旅程规则只有两处来源：正文维护 A1–C 判定与产品规则；A1 通过之后到交付首版的阶段顺序、逐阶段规则与允许动作只在[阶段计划](skills/abelien-workspace/assets/journey-stage-plan.json)维护，正文 §5 的一览由 `npm run render:journey-plan` 从它生成、测试比对。作品推进没有 workflow：任何宿主都持有自己的作品状态，按 `workspace.journey-next` 取下一阶段，再运行该阶段需要的领域 workflow；workflow 只承载单一领域内的多步流程，不替宿主判定作品完成。具体做法及旧实例处理见 [调用说明](skills/abelien-workspace/references/harness-binding.md)。
|
|
146
146
|
|
|
147
147
|
```bash
|
|
148
|
-
node skills/abelien-harness/scripts/ab.mjs --workdir <作品工作目录>
|
|
149
|
-
#
|
|
148
|
+
node skills/abelien-harness/scripts/ab.mjs --workdir <作品工作目录> capability run workspace.journey-next --input '{"intent":"create","artifacts":{"reference_final":true}}'
|
|
149
|
+
# → 下一阶段、goal、directives 与 actions；宿主按它执行，硬件阶段再运行 user-journey-hardware
|
|
150
150
|
```
|
|
151
151
|
|
|
152
152
|
### PRD 随需求对话维护
|
|
153
153
|
|
|
154
154
|
PRD 以用户指定的飞书模板 revision 191 为结构依据，保留七块总览、逐条需求清单与图片引用；从 A1 起每轮登记／修改／撤回需求，保留 ID、来源与历史，选型和检查回来后再更新关联行。定义与写入语义集中在 [PRD 契约](skills/abelien-workspace/references/prd-contract.md)，模板随 workspace 安装。产品写入／回读接口尚未接入，不能把规则声明说成自动写入已实现。
|
|
155
155
|
|
|
156
|
-
`user-journey-mock`、专属 workspace mock 能力和 draft／quote 样例状态机已移除，旧记录与 [MVP 实录](docs/mvp/journey.md) 仅用于历史核对，不再提供运行入口。当前 eval
|
|
157
|
-
基础需求足够后推进首版；guide 在宿主实际展示条件满足时通过可选选择题卡片邀请交互细化并告知可“随时收尾”。PRD 从已保存需求起可读，不强制展开或增加文档确认关卡。收尾切入同一作品的[成果体验](skills/abelien-workspace/references/user-journey.md#result-experience)：收起全部编辑面板，有可运行仿真就进入仿真，否则按真实播放器能力提供 Three.js 状态动作演示；保留 PRD
|
|
156
|
+
`user-journey-mock`、`user-journey`、`user-journey-hardware-algorithm`、专属 workspace mock 能力和 draft／quote 样例状态机已移除，旧记录与 [MVP 实录](docs/mvp/journey.md) 仅用于历史核对，不再提供运行入口。当前 eval 共四条场景：`user-journey-hardware-cancelled` 验证取消是**终态**（在硬件分类暂停点取消，落 `cancelled` 后 `advance` 与再次 `cancel` 都被拒）；`user-journey-hardware-verified` 与 `user-journey-hardware-pending-confirmation` 经**场景 http 桩**端到端驱动硬件阶段的接线（Agent 槽位真的进了请求体、选型资源落库、draft 记下 id 与 status）与门禁（`verified` 过门落 `selected`；`needs_confirmation` 不再被拒——不执行算法，以 `selected_pending_confirmation` 正常完成，仍不宣称 `verified`；`failed`／`unknown` 依旧 `GUARD_FAILED`）；`user-journey-hardware-candidates` 驱动**候选提案**路径（本地 `hardware.search` 按受控三级路径读 OSS，`hardware.finalize` 归一化为提案），三条实况断言锁 Catalog／索引／Wiki 各被真实读一次，且 draft 不带 `hardwareSelectionId`（候选不产生正式选型）。桩是评估进程内的假服务，**不**证明选型质量，也**不**证明服务端已就位。
|
|
157
|
+
基础需求足够后推进首版；guide 在宿主实际展示条件满足时通过可选选择题卡片邀请交互细化并告知可“随时收尾”。PRD 从已保存需求起可读，不强制展开或增加文档确认关卡。收尾切入同一作品的[成果体验](skills/abelien-workspace/references/user-journey.md#result-experience)：收起全部编辑面板，有可运行仿真就进入仿真，否则按真实播放器能力提供 Three.js 状态动作演示；保留 PRD 查看／草稿或确认版导出及返回编辑入口。展示模式与方案确认独立，不能用收尾、演示状态或草稿导出代替确认。宿主 UI／播放器仍须实际接入，历史入口测试不证明体验已实现。
|
|
158
158
|
|
|
159
159
|
### 真实硬件阶段
|
|
160
160
|
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "abelien-harness",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.11.0",
|
|
4
4
|
"description": "npx-installable multi-agent skill harness: generic kernel + pluggable domain packs",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"engines": {
|
|
@@ -20,6 +20,7 @@
|
|
|
20
20
|
"scripts": {
|
|
21
21
|
"test": "node --test",
|
|
22
22
|
"eval": "node eval/run.mjs",
|
|
23
|
+
"render:journey-plan": "node tools/render-journey-plan.mjs",
|
|
23
24
|
"prepare": "node scripts/install-hooks.mjs",
|
|
24
25
|
"branch:new": "node scripts/new-branch.mjs",
|
|
25
26
|
"sync": "node scripts/sync.mjs",
|
|
@@ -20,7 +20,7 @@ compatibility:
|
|
|
20
20
|
2. **取得当前上下文。** 按 workspace 的[领域模型](../abelien-workspace/references/domain-model.md)及[调用与恢复说明](../abelien-workspace/references/harness-binding.md)恢复作品、事件、任务和证据。已有运行先恢复，读取失败交回具体缺口。
|
|
21
21
|
3. **按需调用 clarify。** 新增、修改、撤回需求或影响需求的答复需要整理时，读取其入口，提供同版原话、当前完整需求、本次操作、相关方案、授权与会话约束；答卡附原题和真实答复事件；工具结果中的用户原文仍按 user 来源处理，只采明确子集，不用生成的聊天 message 冒充回答事件。纯确认或仅工具回传不机械重跑 clarify。
|
|
22
22
|
4. **承接需求建议。** clarify 返回 `result / questions / note`；按其契约复核语义与结构，再按 workspace 的采用规则交给实际服务。没有 result 时沿用当前需求。需求变更按 workspace 的 [PRD 契约](../abelien-workspace/references/prd-contract.md)在本轮登记／修改／撤回条目并回读，不等最终确认；只调度该契约，不在 guide 复制模板或登记逻辑。必要问题结合当前上下文呈现，不把问题提出或用户回答当作方案已修改。
|
|
23
|
-
5. **选择下一步。** 依据 workspace 的[完整旅程](../abelien-workspace/references/user-journey.md)
|
|
23
|
+
5. **选择下一步。** 依据 workspace 的[完整旅程](../abelien-workspace/references/user-journey.md)核对推进条件。A1 通过之后到交付首版这一段，下一阶段与该阶段的规则、允许动作一律取 `workspace.journey-next` 的返回，不凭记忆或旅程摘要自排阶段；再按能力绑定选择领域 skill、领域 workflow 或产品服务。目标旅程先复用符合需求的真实 CAD；没有现成 CAD 时按阶段计划生成概念图并自动选型、绑定原图、构建 CAD／审查；实际安装版本不支持时报告能力缺口，不调用未注册工具。必要问题只调用宿主已注册的 `publish_agent_card(kind=question)`，持久绑定原模型调用后结束执行，用户独立提交后以原调用的工具结果承接原任务；不等待 HTTP／Worker、不先把 card_id 返回为最终答案、不继续执行依赖答案的工具批次。可选交互邀请遵守宿主实际展示门（核对实际版本的 3D 加载与适用审查），不得因需求足够就抢先覆盖必要问题卡；按旅程 §4.1 的通用目标告知随时可收尾，不插入需求版 PRD 展示关卡。点击“随时收尾”后按 §4.2 调用宿主成果体验模式，核对仿真或 Three.js 行为演示能力，并保留 PRD 查看／导出入口。调用前读对应 skill；能力不存在时报告具体缺口。实际能力返回后回到当前事实重判，不自行选择型号、算法或编造工程结论。
|
|
24
24
|
6. **向用户交代结果。** 根据真实产物说明本次变化、当前缺口和下一步，区分 PRD 已登记的需求与仍待实现／检查的方案；没有写入回执就明确尚未保存。首版展示、必要取舍及确认邀请的时机均采用 workspace 规则；表达方式采用共用表达规则。
|
|
25
25
|
|
|
26
26
|
图片、链接或“做同款”仍走同一入口，不自动开启另一条整机还原流程。入口按本轮意图调度：还原现成产品（restore）、创造新产品（create）或基于现成产品修改（modify）共用同一旅程，差别只在首先展示什么、参考资料怎么用、哪些特征锁定，依据是原话而不是输入形式，详见[意图路由](../../docs/architecture/intent-routing.md)。还原与改现成先识别产品，展示原产品图及来源后继续；新创先参考相似产品再出概念图，用户已有明确设计图时直接沿用。意图、目标深度与识别结果在首版之前不单独发问：按推断继续，作为系统假设展示并可随时修改；型号识别冲突时保留候选，用户切换即视为需求修订。改轮廓、颜色、材质、表面语言或参考匹配时调用 [appearance](../abelien-appearance/SKILL.md)；空间约束、布局、装配、Build123d 或几何检查调用 [structure](../abelien-structure/SKILL.md)。外壳形状同时涉及两者时，由 appearance 定义目标、structure 实现并回传实际渲染、appearance 做视觉验收。只把必须由用户决定的差异交回用户，不让内部视觉审查成为额外的必答关卡。
|
|
@@ -41,6 +41,6 @@ compatibility:
|
|
|
41
41
|
|
|
42
42
|
原生答卡按[问题工具接续契约](../../docs/architecture/question-card.md)消费：选项 ID 和自由原文走原 toolCallId 的 tool 结果，不能包装成新 User 消息。旧卡缺可信原调用时只走明确旧协议或说明缺口；不伪造调用，不把答卡、暂停追问或物理接续 run 当作品确认。可选交互邀请沿用非阻塞接口，不使用必要问题的等待机制。
|
|
43
43
|
|
|
44
|
-
workflow 的恢复、advance、cancel
|
|
44
|
+
领域 workflow 的恢复、advance、cancel 按 workspace 的运行约定执行；作品推进与确认后的交接由宿主回执决定，不推进任何 workflow。guide 只消费真实回执，不把工具成功、需求建议或自己的总结当成作品已采用、已确认或已交付。
|
|
45
45
|
|
|
46
46
|
用户看到的是方案、变化、问题和产物；内部阶段编号、HTTL、cursor 与资源 ID 留在工作上下文。
|
|
@@ -32,8 +32,7 @@ create 输入为 `schemaVersion:1, creationOperationId, inputRevision:0, manifes
|
|
|
32
32
|
`args` 支持 `{{expr}}` 插值
|
|
33
33
|
- `executor: "agent"`：`instruction` 必填；运行到此暂停（`awaiting_agent`），
|
|
34
34
|
instruction 随实例返回给 agent
|
|
35
|
-
-
|
|
36
|
-
- `main(argv,{verifyCompletion})`、底层 workflow deps 接受该回调。内核不解释业务 guard 名称。当前 user-journey 声明 `workspace.confirmed-snapshot`；产品检查／同版确认／快照服务未接时禁止 done。未声明 guard 的一般工作流行为不变。
|
|
35
|
+
- **范围：** 一条 workflow 只承载单一领域内的多步流程——`capability.run` 步骤只调用同一个能力命名空间（如全是 `hardware.*`），不跨领域串接。作品推进、采用、确认与交付由宿主持有，不写成 workflow；`completionGuard` 已移除，定义里出现即 `WORKFLOW_INVALID`。随包定义由 `test/workflow-scope.test.mjs` 把守。
|
|
37
36
|
|
|
38
37
|
## 运行实例（`.abelien/workflows/<runId>.json`）
|
|
39
38
|
|
|
@@ -188,7 +187,6 @@ abelien-harness receipt get --wait <waitId> --digest <resultDigest> --workdir <
|
|
|
188
187
|
| `WORKFLOW_INVALID` | 步骤定义非法（id 重复、action/instruction 缺失等） |
|
|
189
188
|
| `WORKFLOW_RUN_NOT_FOUND` | runId 不存在 |
|
|
190
189
|
| `WORKFLOW_STATE` | 状态机非法转移（如 cancel 已终态的 run） |
|
|
191
|
-
| `WORKFLOW_COMPLETION_REQUIRED` | 缺可信宿主完成校验或回读未通过；保持暂停 |
|
|
192
190
|
| `WORKFLOW_DRIFTED` | 历史步骤形状与现行定义不同；只读恢复 |
|
|
193
191
|
| `VALIDATION` | 必填 input 缺失 |
|
|
194
192
|
| `RECEIPT_INVALID` / `RECEIPT_SIZE` | envelope 不符合 v1／超过大小边界 |
|
|
@@ -205,7 +205,7 @@ export function createStore(workdir) {
|
|
|
205
205
|
// doctor must report the shipped package version, never a frozen constant (0.2.3 drifted across
|
|
206
206
|
// six releases). The npm tree always ships package.json at the skill root; standalone skill copies
|
|
207
207
|
// fall back to FALLBACK_VERSION, which scripts/release-check.mjs pins to package.json.
|
|
208
|
-
const FALLBACK_VERSION = "0.
|
|
208
|
+
const FALLBACK_VERSION = "0.11.0";
|
|
209
209
|
export let VERSION = FALLBACK_VERSION;
|
|
210
210
|
try {
|
|
211
211
|
VERSION = String(JSON.parse(fs.readFileSync(new URL("../../../package.json", import.meta.url), "utf8")).version || FALLBACK_VERSION);
|
|
@@ -390,7 +390,7 @@ export async function main(argv, opts = {}) {
|
|
|
390
390
|
io.out.write(canonicalJson({ ok: true, data: { usage: USAGE_TEXT } }) + "\n");
|
|
391
391
|
return 0;
|
|
392
392
|
}
|
|
393
|
-
const data = await dispatch(argv, { io, workdir, env, fetchImpl: opts.fetchImpl, spawnImpl: opts.spawnImpl, modulePorts: opts.modulePorts, readEvidence: opts.readEvidence
|
|
393
|
+
const data = await dispatch(argv, { io, workdir, env, fetchImpl: opts.fetchImpl, spawnImpl: opts.spawnImpl, modulePorts: opts.modulePorts, readEvidence: opts.readEvidence });
|
|
394
394
|
io.out.write(canonicalJson({ ok: true, data }) + "\n");
|
|
395
395
|
return 0;
|
|
396
396
|
} catch (e) {
|
|
@@ -844,9 +844,8 @@ function validateWorkflow(def, name) {
|
|
|
844
844
|
if (s.executor === "agent" && s.replySchema !== undefined && (typeof s.replySchema !== "object" || s.replySchema === null || Array.isArray(s.replySchema))) {
|
|
845
845
|
issues.push(`step ${s.id}: replySchema must be an object`);
|
|
846
846
|
}
|
|
847
|
-
|
|
848
|
-
|
|
849
|
-
}
|
|
847
|
+
// Product completion (adoption, confirmation, delivery) belongs to the host, never to a workflow step.
|
|
848
|
+
if (s.completionGuard !== undefined) issues.push(`step ${s.id}: completionGuard was removed; product completion is decided by the host, not by a workflow`);
|
|
850
849
|
if (s.completeWhen !== undefined && (s.executor !== "cli" || typeof s.completeWhen?.path !== "string" || !Object.hasOwn(s.completeWhen, "equals") || !s.completionResult)) issues.push(`step ${s.id}: completeWhen requires a CLI step, path, equals and completionResult`);
|
|
851
850
|
if (s.executor !== "cli" && s.executor !== "agent") issues.push(`step ${s.id}: executor must be cli|agent`);
|
|
852
851
|
}
|
|
@@ -1040,15 +1039,6 @@ export function createWorkflowStore(workdir) {
|
|
|
1040
1039
|
// 引步之前比对定义：cursor 在两份序列上必须指向同一步，否则不落盘、不执行。
|
|
1041
1040
|
assertDefinitionMatches(instance, def);
|
|
1042
1041
|
const step = instance.steps[instance.cursor];
|
|
1043
|
-
const guard = def.steps[instance.cursor].completionGuard;
|
|
1044
|
-
if (guard) {
|
|
1045
|
-
if (typeof deps.verifyCompletion !== "function") throw fail("WORKFLOW_COMPLETION_REQUIRED", "trusted host completion verifier is unavailable", { guard });
|
|
1046
|
-
const original = canonicalJson(instance);
|
|
1047
|
-
const verified = await deps.verifyCompletion({ guard, instance: JSON.parse(original), result: JSON.parse(canonicalJson(result)) });
|
|
1048
|
-
if (verified?.ok !== true) throw fail("WORKFLOW_COMPLETION_REQUIRED", "trusted host did not verify completion", { guard });
|
|
1049
|
-
if (canonicalJson(load(runId)) !== original) throw fail("WORKFLOW_STATE", "workflow changed during completion verification");
|
|
1050
|
-
step.completionReceipt = verified.receipt ?? null;
|
|
1051
|
-
}
|
|
1052
1042
|
step.result = result;
|
|
1053
1043
|
step.status = "done";
|
|
1054
1044
|
step.finishedAt = nowIso();
|
|
@@ -1206,7 +1196,6 @@ async function workflowCmd(pos, flags, deps) {
|
|
|
1206
1196
|
env: deps.env,
|
|
1207
1197
|
fetchImpl: deps.fetchImpl,
|
|
1208
1198
|
readEvidence: deps.readEvidence,
|
|
1209
|
-
verifyCompletion: deps.verifyCompletion,
|
|
1210
1199
|
modulePorts: deps.modulePorts,
|
|
1211
1200
|
});
|
|
1212
1201
|
const wfs = createWorkflowStore(deps.workdir);
|
|
@@ -1271,7 +1260,7 @@ if (isMain) {
|
|
|
1271
1260
|
// 语义零变化；main() 若异常拒绝，未处理拒绝与原 TLA 拒绝同为打印后 exit 1。
|
|
1272
1261
|
main(process.argv.slice(2)).then(async code => {
|
|
1273
1262
|
// process.exit() 不等待管道异步写刷盘：单行 JSON payload 较大时（实测 ~8KB 起截断，
|
|
1274
|
-
//
|
|
1263
|
+
// 如硬件 workflow 的 status/advance 回执），超出首笔写入的部分会被静默丢弃。
|
|
1275
1264
|
// 追加一次空写作为刷盘屏障——流按写入顺序回调，空写回调触发即代表此前全部字节
|
|
1276
1265
|
// 已交给 OS——随后再退出；写错误（如 EPIPE）仍由回调吞掉，保持既有静默语义。
|
|
1277
1266
|
await Promise.all([
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: abelien-workspace
|
|
3
|
-
description: Abelien 作品旅程与业务契约：维护 PRD 定义与逐轮条目登记、A1–C
|
|
3
|
+
description: Abelien 作品旅程与业务契约：维护 PRD 定义与逐轮条目登记、A1–C 推进条件、可选交互细化与收尾成果体验、作品上下文、采用与版本、检查、同版确认及交付恢复规则，提供按意图推进的阶段计划（workspace.journey-next）。用于判断作品如何推进或启动、恢复创作；guide 按本包规则调度，clarify 提供需求建议，实际写入由已接产品服务完成。
|
|
4
4
|
license: MIT
|
|
5
5
|
compatibility:
|
|
6
6
|
- claude-code
|
|
@@ -14,9 +14,9 @@ compatibility:
|
|
|
14
14
|
|
|
15
15
|
## 读取入口
|
|
16
16
|
|
|
17
|
-
- 判断阶段、修改回流或确认资格：先核对 OSS CAD 优先和Studio 产品要求与宿主版本边界，再读[完整用户旅程](references/user-journey.md)
|
|
17
|
+
- 判断阶段、修改回流或确认资格：先核对 OSS CAD 优先和Studio 产品要求与宿主版本边界，再读[完整用户旅程](references/user-journey.md)，这是产品规则的唯一正文（A1 通过之后到交付首版的逐阶段规则在阶段计划，见下文）；交互细化邀请见 §4.1，点击“随时收尾”后的成果体验、仿真／Three.js 行为演示与 PRD 入口见 §4.2。
|
|
18
18
|
- 核对作品上下文、需求建议与采用结果：读[领域模型与职责交接](references/domain-model.md)。
|
|
19
|
-
-
|
|
19
|
+
- 推进作品、恢复、调用领域流程或提交结果：读[调用与能力映射](references/harness-binding.md)，领域 workflow 另读其实际定义。
|
|
20
20
|
- 在已采用设计上做 CAD 局部修改或候选返工：按[调用与能力映射](references/harness-binding.md#adopted-design-revision-loop)使用受信 Studio broker；候选和采用版本必须分开。
|
|
21
21
|
- 初次建立或随需求变更维护 PRD：读[PRD 定义与逐轮维护契约](references/prd-contract.md)，按[模板快照](assets/prd-template.json)定位字段与稳定行 ID。
|
|
22
22
|
|
|
@@ -26,20 +26,13 @@ compatibility:
|
|
|
26
26
|
|
|
27
27
|
## 产品入口
|
|
28
28
|
|
|
29
|
-
[
|
|
30
|
-
|
|
31
|
-
```bash
|
|
32
|
-
node <skills目录>/abelien-harness/scripts/ab.mjs --workdir <作品工作目录> workflow run user-journey --input '{"prompt":"..."}'
|
|
33
|
-
# 新创作才启动；已有运行先按调用说明恢复
|
|
34
|
-
# awaiting_agent@drive-product-journey：继续在同一步骤内消费宿主输入与真实任务
|
|
35
|
-
```
|
|
29
|
+
作品推进没有 workflow：宿主持有作品事实、版本与任务，任何宿主（Web、Claude Code、Codex）都按同一套规则推进。A1 之前与 A1–C 的判定读[完整用户旅程](references/user-journey.md)；A1 通过之后到交付首版的阶段与逐阶段规则由 `workspace.journey-next` 给出（见下节）；领域内的多步流程（如硬件选型 `user-journey-hardware`）各跑自己的 workflow。逐步做法见[调用与能力映射](references/harness-binding.md#host-driven-journey)。
|
|
36
30
|
|
|
37
31
|
- 阶段、采用、版本及确认条件以本包规则为准。clarify 的结构校验和领域阶段成功不替代作品确认条件。
|
|
38
|
-
- 当前引擎是顺序 workflow v1，不解释 `journey` 分支，也不校验 `input.optional`、`replySchema` 或 B3。业务规则由 Agent 按真实证据执行；产品服务仍须提供实际写入与验证契约。
|
|
39
32
|
- 必要问题的工具等待与回答结果见[卡片调用契约](../../docs/architecture/question-card.md)：宿主持久原调用后结束执行，独立答卡请求接上原 tool 结果，不构造 User 答案；真实用户原文仍保留 user 来源。
|
|
40
|
-
-
|
|
41
|
-
- 收尾／返回编辑是同一作品的展示模式切换；成果体验中的 machine states 只驱动行为演示，不替代 A1–C
|
|
42
|
-
-
|
|
33
|
+
- 首版展示、普通进度、必要问题和等待任务时停止本轮、说明下一步，等新事实到来再判断；不为“保持位置”启动或挂起任何 run。
|
|
34
|
+
- 收尾／返回编辑是同一作品的展示模式切换；成果体验中的 machine states 只驱动行为演示，不替代 A1–C 或确认条件。
|
|
35
|
+
- 需求、采用方案、版本、决定与任务每轮从宿主／产品回读，缺接口就说明缺口。
|
|
43
36
|
|
|
44
37
|
## 阶段计划与 journey-next
|
|
45
38
|
|
|
@@ -50,7 +43,7 @@ node <skills目录>/abelien-harness/scripts/ab.mjs --workdir <作品工作目录
|
|
|
50
43
|
--input '{"intent":"restore","artifacts":{"reference_final":true}}'
|
|
51
44
|
```
|
|
52
45
|
|
|
53
|
-
它是纯计算，返回下一阶段、目标、`directives` 与 `actions`。宿主先跑完自己的守卫，再把 `directives` 原样附在自己的执行说明（工具名、字段）之后；`actions` 是该阶段允许的动作（取自计划的 `action_catalog`），宿主把它们映射成自己的工具，只放行这些。restore 默认锁定外形；锁定时，CAD 阶段的规则会写明不得放大外壳；未锁定时只允许在 appearance 认可的外观容差内调整外壳，超出容差换件或交用户取舍。意图的划分见 [意图路由](../../docs/architecture/intent-routing.md)。阶段计划是[
|
|
46
|
+
它是纯计算，返回下一阶段、目标、`directives` 与 `actions`。宿主先跑完自己的守卫，再把 `directives` 原样附在自己的执行说明（工具名、字段）之后；`actions` 是该阶段允许的动作（取自计划的 `action_catalog`），宿主把它们映射成自己的工具，只放行这些。restore 默认锁定外形；锁定时，CAD 阶段的规则会写明不得放大外壳；未锁定时只允许在 appearance 认可的外观容差内调整外壳，超出容差换件或交用户取舍。意图的划分见 [意图路由](../../docs/architecture/intent-routing.md)。阶段计划是 A1 通过之后到交付首版这一段（及其旁路）阶段顺序、目标、规则与允许动作的唯一来源；「[阶段计划一览](references/journey-stage-plan.md)」由 `npm run render:journey-plan` 从它生成；[完整用户旅程](references/user-journey.md#journey-stage-plan)维护 A1–C 判定与产品规则，两者不得冲突。本能力在[能力映射](references/harness-binding.md#当前能力映射)中登记。
|
|
54
47
|
|
|
55
48
|
本包定义作品事实之间的关系，不表示已实现完整的产品后台。现有可用能力和未接入项集中维护在[能力映射](references/harness-binding.md)，不使用旧 `workspace.*` mock 顶替。
|
|
56
49
|
|
|
@@ -60,4 +53,4 @@ node <skills目录>/abelien-harness/scripts/ab.mjs --workdir <作品工作目录
|
|
|
60
53
|
|
|
61
54
|
## 已移除的旧样例
|
|
62
55
|
|
|
63
|
-
`user-journey-mock`、其 8 个 `workspace.*` mock 能力和 draft／quote 样例 FSM
|
|
56
|
+
`user-journey-mock`、其 8 个 `workspace.*` mock 能力和 draft／quote 样例 FSM 已移除；作品推进 workflow `user-journey`（单步 `drive-product-journey` 与其 `journey` 判定契约）和跨领域的 `user-journey-hardware-algorithm` 也已退役，规则只在旅程正文与阶段计划中维护。保留真实硬件阶段使用的 draft 资源类型。现行产品入口不生成假 PRD、报价或确认。旧运行及评估报告原样保留，仅查看原始 status；不要对旧实例取 HTTL 或 advance。处理方法见调用说明。
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"schema": "abelien.journey-stage-plan.v1",
|
|
3
|
-
"plan_version": "2026-10-14.
|
|
4
|
-
"description": "
|
|
3
|
+
"plan_version": "2026-10-14.3",
|
|
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 判定与产品规则，本计划不得与之冲突。改动本计划须升 plan_version、在 test/journey-next.test.mjs 的 HISTORY 追加一行，并重新生成一览。",
|
|
5
5
|
"artifacts": ["reference_final", "concept_image", "hardware", "appearance_baseline", "cad_candidate", "review"],
|
|
6
6
|
"orders": {
|
|
7
7
|
"create": ["reference", "concept", "hardware", "real_image", "cad", "review"],
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "abelien-workspace",
|
|
3
|
-
"version": "
|
|
4
|
-
"description": "作品旅程、PRD
|
|
3
|
+
"version": "2.0.0",
|
|
4
|
+
"description": "作品旅程、PRD 与业务契约；作品推进由宿主按 workspace.journey-next 的阶段计划进行，不是 workflow；draft 供真实硬件阶段使用；不声明假 PRD、确认、报价或支付能力",
|
|
5
5
|
"resources": [
|
|
6
6
|
"draft"
|
|
7
7
|
],
|
|
@@ -6,7 +6,7 @@
|
|
|
6
6
|
|
|
7
7
|
- 没有已验证硬件方案、要形成正式初选：运行 `user-journey-hardware`。Agent 先做需求到三级槽位分类，再调用同级 `abelien-hardware-selection` 的 `hardware.select`；只有返回的 `hardware-selection` 通过门禁后才算完成正式硬件阶段。
|
|
8
8
|
- 只需要研究 OSS 候选、暂不形成正式初选：运行 `user-journey-hardware-candidates`。Agent 先调用 `hardware.search` 从 OSS 分类索引读取 Top-K 最新候选 Wiki，再比较 `adapt_system` 或 `assemble_new` 并由 `hardware.finalize` 保存 `hardware-proposal`；这个提案不能通过正式硬件门，也不能直接开始算法阶段。
|
|
9
|
-
-
|
|
9
|
+
- 同一次任务还要完成算法选型：硬件阶段门通过后，由宿主另起 `user-journey-algorithm`（同级 `abelien-algorithm`），输入已验证硬件与完整 reactions。硬件与算法是两个领域，不在同一个 run 里串接。
|
|
10
10
|
- 已有已验证方案，用户明确修改其中一项：运行 `user-journey-hardware-revise`。输入只包含当前 draft ID、基线选型 ID/版本和最新变更请求；不要把整段对话塞入硬件服务。
|
|
11
11
|
- 用户改变了产品目标或大量功能，而不是局部部件：形成新的需求版本，再运行新建流程，不把它伪装成局部修订。
|
|
12
12
|
|
|
@@ -16,13 +16,13 @@ OSS Wiki 读取由 `abelien-hardware` 的本地 module adapter 实现，通用
|
|
|
16
16
|
|
|
17
17
|
## 完整智能体
|
|
18
18
|
|
|
19
|
-
|
|
19
|
+
作品推进由宿主持有，按 `workspace.journey-next` 取阶段，再按阶段运行各领域自己的 workflow；workflow 只承载单一领域内的多步流程，不跨领域串接，也不替宿主判定作品完成（`test/workflow-scope.test.mjs` 把这条钉成门禁）。每阶段读取上游已验证资源并产出版本化资源；变更后只把依赖图中受影响的下游阶段标为 stale。例如电池尺寸变化通常使供电和结构验证失效，算力/接口未变化时不应重跑算法选型。
|
|
20
20
|
|
|
21
21
|
待内核确有跨 workflow 调用、条件边和有界重试需求时，再设计 workflow v2；必须同时定义最大迭代次数、每次迭代记录、幂等键、取消语义和恢复行为。在这些执行语义落地前，由前端 Agent 根据终态和资源状态选择下一 workflow，不能把业务路由伪装成已由内核保证。
|
|
22
22
|
|
|
23
23
|
## Library review and online supplement
|
|
24
24
|
|
|
25
|
-
|
|
25
|
+
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.
|
|
26
26
|
|
|
27
27
|
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.
|
|
28
28
|
|
|
@@ -11,7 +11,7 @@ node "$AB" --workdir "$WD" doctor
|
|
|
11
11
|
node "$AB" --workdir "$WD" domain list
|
|
12
12
|
node "$AB" --workdir "$WD" capability list
|
|
13
13
|
node "$AB" --workdir "$WD" workflow list
|
|
14
|
-
# 已有 runId：先取原始 status
|
|
14
|
+
# 已有 runId：先取原始 status，识别当前硬件运行还是已退役的旧实例
|
|
15
15
|
node "$AB" --workdir "$WD" workflow status <runId>
|
|
16
16
|
# 确认为当前定义的 awaiting_agent 步骤后，才读取 HTTL
|
|
17
17
|
node "$AB" --workdir "$WD" workflow status <runId> --httl
|
|
@@ -30,13 +30,13 @@ skills/
|
|
|
30
30
|
abelien-workspace/SKILL.md 作品业务契约入口
|
|
31
31
|
abelien-workspace/references/ 完整旅程、PRD 契约、领域模型与本调用说明
|
|
32
32
|
abelien-workspace/domain.json 作品域、真实硬件阶段 draft 资源与 workspace.journey-next 声明
|
|
33
|
-
abelien-workspace/assets/ 按意图的阶段计划 journey-stage-plan.json
|
|
33
|
+
abelien-workspace/assets/ 按意图的阶段计划 journey-stage-plan.json（自动段阶段与逐阶段规则的唯一来源）
|
|
34
34
|
abelien-workspace/scripts/ journey-next.mjs（阶段计划解释器，纯计算）
|
|
35
|
-
abelien-workspace/workflows/
|
|
35
|
+
abelien-workspace/workflows/ 硬件领域内的线性工作流；作品推进不是 workflow
|
|
36
36
|
abelien-hardware-selection/SKILL.md 真实硬件阶段的分类与服务指引
|
|
37
37
|
```
|
|
38
38
|
|
|
39
|
-
guide 与 clarify 自身不声明新资源、适配器或实体状态机，故不增加空 `domain.json`。clarify 正文与共用表达规则自 2026-10-11 起以 harness 仓为唯一编辑源，直接在本包修改，不再从 abelienwebapplication 同步。它作为 `abelien-*` bundle 随安装器分发，真实调用复用已发现域包。workspace 维护 A1–C 业务条件，guide 按这些条件组织调用和对话，clarify
|
|
39
|
+
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，每条只调用一个领域的能力，不替宿主判定作品完成。
|
|
40
40
|
|
|
41
41
|
| 需要的事实 | 读取位置／含义 |
|
|
42
42
|
| --- | --- |
|
|
@@ -55,11 +55,11 @@ stdout 的 `ok:true` 表示命令取得了回执。workflow 调用还必须检
|
|
|
55
55
|
|
|
56
56
|
| 用户旅程所需能力 | 当前 Harness 对应与限制 |
|
|
57
57
|
| --- | --- |
|
|
58
|
-
| 按意图的下一阶段与阶段规则 | `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
|
|
58
|
+
| 按意图的下一阶段与阶段规则 | `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)」由它生成 |
|
|
59
59
|
| clarify 需求整理 | 同级 `abelien-clarify`：以当前操作和同版上下文换取 `result / questions / note`，不是 CLI capability，不写资源；结构可用其 `scripts/check_result.py` 校验。共用表达规则在同级 guide 的 references，由 guide 读一次注入。已移除旧 workspace.brief，不提供假澄清 |
|
|
60
60
|
| 硬件候选检索与提案 | `user-journey-hardware-candidates` → `abelien-hardware`：`hardware.search`（OSS 检索）→ agent 比较整机与零部件候选 → `hardware.finalize`（保存 `hardware-proposal`）。提案不创建正式 `hardware-selection` 门，也不能直接开始算法阶段 |
|
|
61
|
-
| 正式硬件选型 | `user-journey-hardware`
|
|
62
|
-
| 算法与行为实现 |
|
|
61
|
+
| 正式硬件选型 | `user-journey-hardware` → `abelien-hardware-selection` → `hardware.select`；本地模块回读真实召回并校验 Agent 判断，返回 hardware-selection；证据不足不可用候选提案代替 |
|
|
62
|
+
| 算法与行为实现 | 正式硬件过门后，宿主另行启动 `user-journey-algorithm` → `abelien-algorithm`：agent 按官方资料优先联网研究，`algorithm.finalize` 本地保存。输入为已验证硬件与 clarify Requirements 的 `reaction[]` 原样；硬件与算法不在同一个 run 里串接 |
|
|
63
63
|
| 外观／ID editing 与视觉审查 | 同级 `abelien-appearance`：维护轮廓、比例、CMF、部位与参考匹配目标，实际查看 structure 的本版渲染。没有注册 `appearance.*` 产品 capability；宿主须具备真实图片读取／编辑能力，不能把旧外观 mock 当成现行实现 |
|
|
64
64
|
| 结构与装配 | 同级 `abelien-structure`：空间约束、CAD复用、Build123d与几何检查。通用CLI未注册structure.*产品能力；Web宿主另有隔离Worker和structure_submit/status/cancel，生成与基础检查不代表视觉/完整装配/采用 |
|
|
65
65
|
| 图生 3D | 同级 `abelien-3dgen` 的真实 provider 命令通常供 appearance 按需调用，再把候选网格交 structure 作为工程参考；生成网格不等于参数化 CAD、视觉 pass、结构采用或装配验证 |
|
|
@@ -69,32 +69,38 @@ stdout 的 `ok:true` 表示命令取得了回执。workflow 调用还必须检
|
|
|
69
69
|
| 可选交互邀请卡片 | 按旅程 §4.1 呈现继续细化／先收尾两个选项；宿主须支持非阻塞操作选择，不能直接套用必要 question 的 pending 门禁或完成 handoff 前提。尚未绑定时不声称已弹卡，不虚构 kind／action key |
|
|
70
70
|
| 产品问题工具接续与引导 | 见 [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，由用户点击 |
|
|
71
71
|
| 逐轮 PRD 条目维护 | 通用CLI不内置产品写库；Web从已持久facts派生现行七块模板PRD/BOM、来源/假设/未知，不能可靠映射的实现保留同版附录。缺宿主时只交接待登记差异 |
|
|
72
|
-
| 版本采用、确认及 PRD 导出 | Web product_adopt只接真实同版候选，确认仅用户版本绑定concept命令；租约事务保存私有不可变快照、授权JSON/Markdown
|
|
72
|
+
| 版本采用、确认及 PRD 导出 | Web product_adopt只接真实同版候选，确认仅用户版本绑定concept命令；租约事务保存私有不可变快照、授权JSON/Markdown导出，确认与交付回执由宿主核对，不经任何 workflow。原生CLI缺宿主仍失败关闭；旧workspace.getPrd/confirmPlan不可替代 |
|
|
73
73
|
|
|
74
74
|
以后新增绑定时，以实际 `domain.json`、workflow、输入／输出契约为准，再更新本表；不能凭名称相近推定等价。
|
|
75
75
|
|
|
76
76
|
`user-journey-mock` 及全部 workspace mock 已移除。`abelien-hardware` 仍有独立示例能力，仅在明确演示时使用，不能替代产品能力；“继续修改”不等于 `cancel`。
|
|
77
77
|
|
|
78
|
-
|
|
78
|
+
<a id="host-driven-journey"></a>
|
|
79
79
|
|
|
80
|
-
|
|
80
|
+
## 作品推进：宿主持有状态，按 journey-next 取阶段
|
|
81
|
+
|
|
82
|
+
作品推进没有 workflow。任何宿主（Web、Claude Code、Codex）都按同一套做法推进，旅程规则只有正文与阶段计划两处来源：
|
|
83
|
+
|
|
84
|
+
1. **回读作品事实。** 从宿主／产品服务取需求（含 clarify 保存的 `intent`）、已保存产物、采用版本、待答卡与任务。上一轮的推断不当作当前事实；缺产品写入接口时只交接待登记差异，不另存第二份作品状态。
|
|
85
|
+
2. **A1 之前。** 按[完整旅程](user-journey.md) §4 与 clarify 整理需求，A1 的判定按正文。
|
|
86
|
+
3. **A1 通过后到交付首版。** 把已保存产物映射为 `artifacts` 调用 `workspace.journey-next`；旁路阶段（重选、取舍、保底、修复、首版后合并提问）由宿主守卫按真实结果决定后以 `stage` 传入。按返回的 `goal` 与 `directives` 执行，只用 `actions` 对应的工具或能力；领域多步流程运行各自的 workflow（硬件见下文「硬件阶段实际驱动」）。
|
|
87
|
+
4. **首版之后。** B1／B2／B3／C 按正文；修改、必要问题与确认都由宿主保存，不推进任何 workflow。
|
|
81
88
|
|
|
82
89
|
```bash
|
|
83
|
-
node "$AB" --workdir "$WD"
|
|
84
|
-
node "$AB" --workdir "$WD" workflow status <runId> --httl
|
|
90
|
+
node "$AB" --workdir "$WD" capability run workspace.journey-next --input '{"intent":"create","artifacts":{"reference_final":true}}'
|
|
85
91
|
```
|
|
86
92
|
|
|
87
|
-
|
|
93
|
+
首版展示、必要问题、普通修改、待任务或缺能力时，停止本轮并说明下一步，等新事实到来再按上面的顺序重新判断；不为“保持位置”启动或挂起任何 run。
|
|
88
94
|
|
|
89
95
|
Studio 修改与首次创建均不设固定修复次数。沿用同一个 operation、根预算和上游身份，由剩余预算、有效租约、超时、用户取消及确定的冲突报告控制继续执行；同一父候选不得重复发起同一步修复。`repairCount` 是非负整数，非空 `repairOrdinal` 为正整数且不得大于计数。解析回执不代表授权执行，也不代表目标数据库已升级；预算预占与原子计数仍由 Web 负责。
|
|
90
96
|
|
|
91
|
-
|
|
97
|
+
点击“随时收尾”由宿主切换成果体验并收起编辑面板，不取消作品。真实任务与确认条件独立保留；后续结果不自动恢复面板或追问。返回编辑、播放／重置演示、查看或导出草稿都不重新开始推进、不升产品版本。
|
|
92
98
|
|
|
93
|
-
必要答卡等待只属于宿主工具生命周期：保存原 assistant 调用及私有检查点后结束 HTTP／Worker，收到用户决定后以匹配的 tool 结果发起下一次模型请求。原任务／toolCallId 不随后继物理 run
|
|
99
|
+
必要答卡等待只属于宿主工具生命周期：保存原 assistant 调用及私有检查点后结束 HTTP／Worker，收到用户决定后以匹配的 tool 结果发起下一次模型请求。原任务／toolCallId 不随后继物理 run 改变；发卡与答卡都不改变任何 workflow 的状态。完整 wire、幂等、部分回答、旧卡与安装边界见 Agent Card 协议 §5–§8。
|
|
94
100
|
|
|
95
|
-
同版确认事件经 B3
|
|
101
|
+
同版确认事件经 B3 复核、快照真实保存且真实交付状态已交代后，才算交接完成。PRD/BOM／分享／视频分别注明已就绪、进行中、失败或未接入及依据；预订不是必经步骤。若产品已接 `publish_agent_card(handoff)`，可在完成回执后引导用户主动点击“去保存与预约”；未接时只给普通入口，不伪造卡片。页面打开不等于预约、订单或支付成功。确认、当前版本、组合检查、快照与交付状态都以宿主回执为准，普通 resource.put 和模型自填引用不能代替回执；内核不再提供 workflow 完成门。完成仍不代表制造或实物交付通过。C 后修改按真实产品新工作版继续。
|
|
96
102
|
|
|
97
|
-
|
|
103
|
+
**旧运行：** 已退役的 `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`。
|
|
98
104
|
|
|
99
105
|
<a id="adopted-design-revision-loop"></a>
|
|
100
106
|
|
|
@@ -0,0 +1,185 @@
|
|
|
1
|
+
# 阶段计划一览
|
|
2
|
+
|
|
3
|
+
本页是[阶段计划](../assets/journey-stage-plan.json)的可读视图：A1 通过之后到交付首版这一段，按意图的阶段顺序、各阶段的目标、领域规则与允许的动作。由 `npm run render:journey-plan` 生成，测试比对两边一致，不要手改；要改就改计划、升 `plan_version` 并重新生成。A1–C 判定与产品规则见[完整用户旅程](user-journey.md#journey-stage-plan)，计划的规则不得与之冲突。
|
|
4
|
+
|
|
5
|
+
<!-- journey-stage-plan:begin 由 tools/render-journey-plan.mjs 从 assets/journey-stage-plan.json 生成，勿手改 -->
|
|
6
|
+
|
|
7
|
+
#### 阶段计划一览（plan_version 2026-10-14.3）
|
|
8
|
+
|
|
9
|
+
| 意图 | 主线顺序 |
|
|
10
|
+
| --- | --- |
|
|
11
|
+
| 新创（create） | reference → concept → hardware → real_image → cad → review |
|
|
12
|
+
| 还原（restore） | identify → hardware → real_image → cad → review |
|
|
13
|
+
| 改现成（modify） | identify → concept → hardware → real_image → cad → review |
|
|
14
|
+
| 二创（remix） | concept → real_image → cad → review |
|
|
15
|
+
|
|
16
|
+
旁路阶段由宿主按真实结果触发：hardware_reselect、hardware_decision、fallback、repair、questions。还原（restore）默认锁定外形，其他意图默认不锁定。
|
|
17
|
+
|
|
18
|
+
**identify**：识别用户要的现成产品，并取得规格与拆解资料
|
|
19
|
+
|
|
20
|
+
完成标志：宿主已保存 `reference_final`。
|
|
21
|
+
|
|
22
|
+
允许的动作：`reference.research`（收集识别、拆解资料或相似产品的检索证据）、`reference.page`（读取已收集页面的正文，挑选逐字引用）、`reference.finalize`（提交识别或借用判断，定稿参考证据）。
|
|
23
|
+
|
|
24
|
+
规则：
|
|
25
|
+
|
|
26
|
+
1. 调用 reference.research 执行识别与拆解资料检索（用途 identify / teardown；用户给了链接时先读链接），再读取证据，用 reference.finalize 提交识别判断。
|
|
27
|
+
2. 识别不确定时按最可能的候选继续，保留其他候选供用户切换；首版之前默认不向用户提问。
|
|
28
|
+
3. 例外：用户的硬要求缺少取值、无法合理默认，且按默认继续会做出错误结果（例如要求放进某个卡槽却没给尺寸）时，可以在首版之前发一张问题卡；整个首版之前至多一张，最多三题、每题最多三个选项；其余未定项一律按默认处理。
|
|
29
|
+
4. 完成后展示识别出的原产品图并注明来源（页面与站点），再用一两句话说明识别为哪款产品、依据是什么，以及比例核对结果。
|
|
30
|
+
|
|
31
|
+
**reference**：检索相似产品，作为尺寸、结构、器件与实现方式的参考
|
|
32
|
+
|
|
33
|
+
完成标志：宿主已保存 `reference_final`。
|
|
34
|
+
|
|
35
|
+
允许的动作：`reference.research`（收集识别、拆解资料或相似产品的检索证据）、`reference.page`（读取已收集页面的正文，挑选逐字引用）、`reference.finalize`（提交识别或借用判断，定稿参考证据）。
|
|
36
|
+
|
|
37
|
+
规则：
|
|
38
|
+
|
|
39
|
+
1. 调用 reference.research 检索相似产品（用途 similar），再读取证据，用 reference.finalize 提交借用什么、为什么合适、哪些不照搬。
|
|
40
|
+
2. 找不到完整的相似产品时，按声学、供电、交互等子系统分别参考，不硬凑数量；首版之前默认不向用户提问。
|
|
41
|
+
3. 相似产品只作参考，不成为可编辑模板，也不自动采用其 BOM。
|
|
42
|
+
4. 例外：用户的硬要求缺少取值、无法合理默认，且按默认继续会做出错误结果（例如要求放进某个卡槽却没给尺寸）时，可以在首版之前发一张问题卡；整个首版之前至多一张，最多三题、每题最多三个选项；其余未定项一律按默认处理。
|
|
43
|
+
|
|
44
|
+
**concept**：生成第一张概念图
|
|
45
|
+
|
|
46
|
+
完成标志：宿主已保存 `concept_image`。
|
|
47
|
+
|
|
48
|
+
允许的动作：`studio.prepare`（保存外观目标，冻结本次创建的来源）、`image.generate`（生成概念图）。
|
|
49
|
+
|
|
50
|
+
规则：
|
|
51
|
+
|
|
52
|
+
1. 按外观目标生成第一张概念图；需求没说到的外观细节按常见做法补全，首版之前默认不向用户提问。
|
|
53
|
+
2. 出图后用一两句话告诉用户并结束本轮，硬件选型在下一阶段进行。
|
|
54
|
+
3. 例外：用户的硬要求缺少取值、无法合理默认，且按默认继续会做出错误结果（例如要求放进某个卡槽却没给尺寸）时，可以在首版之前发一张问题卡；整个首版之前至多一张，最多三题、每题最多三个选项；其余未定项一律按默认处理。
|
|
55
|
+
|
|
56
|
+
改现成（modify）改用：
|
|
57
|
+
|
|
58
|
+
1. 以识别出的原产品图为输入生成修改后的图，只改用户要求修改的部分，保留清单中的特征。
|
|
59
|
+
2. 出图后用一两句话说明改了什么、保留了什么，并结束本轮；硬件选型在下一阶段进行。
|
|
60
|
+
|
|
61
|
+
**hardware**：为当前需求选型并登记
|
|
62
|
+
|
|
63
|
+
完成标志：宿主已保存 `hardware`。
|
|
64
|
+
|
|
65
|
+
允许的动作：`component.search`（检索组件库）、`hardware.guide`（按分类读取硬件选型指引）、`hardware.wiki`（读取候选型号的 Wiki 资料）、`hardware.resource`（读取已保存的硬件选型资源）、`hardware.workflow`（启动、查询、推进或恢复硬件选型工作流 user-journey-hardware）、`hardware.web-extract`（在网页证据暂停点，从已保存的网页中逐字抽取候选）、`hardware.prepare`（把通过校验的硬件选型登记为创建来源）。
|
|
66
|
+
|
|
67
|
+
规则：
|
|
68
|
+
|
|
69
|
+
1. 主要元器件选定即可；供电、电池、联网方式等用户没说的未定项按推荐默认值选型，并作为待确认项登记，首版之前默认不向用户提问。
|
|
70
|
+
2. 不要修改需求，也不要出图。
|
|
71
|
+
3. 登记后用一两句话说明选了什么、哪些按默认值处理，然后结束本轮；待确认项在首版之后合并成一张问题卡统一询问。
|
|
72
|
+
4. 例外：用户的硬要求缺少取值、无法合理默认，且按默认继续会做出错误结果（例如要求放进某个卡槽却没给尺寸）时，可以在首版之前发一张问题卡；整个首版之前至多一张，最多三题、每题最多三个选项；其余未定项一律按默认处理。
|
|
73
|
+
|
|
74
|
+
还原（restore）改用：
|
|
75
|
+
|
|
76
|
+
1. 以参考证据中的来源产品规格与拆解资料为对照逐项选择替代件，区分原件、替代件与未知；主要元器件选定即可，未定项按推荐默认值登记为待确认项，首版之前默认不向用户提问。
|
|
77
|
+
2. 不要修改需求，也不要出图。
|
|
78
|
+
3. 登记后用一两句话说明替代关系与默认值，然后结束本轮；待确认项在首版之后合并成一张问题卡统一询问。
|
|
79
|
+
4. 例外：用户的硬要求缺少取值、无法合理默认，且按默认继续会做出错误结果（例如要求放进某个卡槽却没给尺寸）时，可以在首版之前发一张问题卡；整个首版之前至多一张，最多三题、每题最多三个选项；其余未定项一律按默认处理。
|
|
80
|
+
|
|
81
|
+
**hardware_reselect**（旁路）：当前硬件放不下用户的硬尺寸上限或锁定分区时重新选型
|
|
82
|
+
|
|
83
|
+
允许的动作：`question.card`（发布一张问题卡，等待用户回答）、`component.search`（检索组件库）、`hardware.guide`（按分类读取硬件选型指引）、`hardware.wiki`（读取候选型号的 Wiki 资料）、`hardware.resource`（读取已保存的硬件选型资源）、`hardware.workflow`（启动、查询、推进或恢复硬件选型工作流 user-journey-hardware）、`hardware.web-extract`（在网页证据暂停点，从已保存的网页中逐字抽取候选）、`hardware.prepare`（把通过校验的硬件选型登记为创建来源）。
|
|
84
|
+
|
|
85
|
+
规则：
|
|
86
|
+
|
|
87
|
+
1. 沿用当前需求的尺寸上限与尺寸检查重新选型，选择能装下的更小型号并登记；不要放宽用户尺寸，不要修改其他需求，不要出图。
|
|
88
|
+
2. 旧选型只作来源证据，不能原样重新登记。
|
|
89
|
+
3. 没有能装下的候选时，发一张问题卡，让用户在“换件”和“放宽尺寸”之间选择。
|
|
90
|
+
|
|
91
|
+
外形已锁定（`locks.shape=true`）时插入为第 2 条：外形已锁定：槽位的 locked 分区（fit_envelope）同样不得放宽。没有能装下的候选时，先由结构在锁定外形内调整骨架（分区、层高、朝向）并给出新的 fit_envelope 后再选，仍装不下才发问题卡；此时“放宽尺寸”就是改外形，记为外观偏差。
|
|
92
|
+
|
|
93
|
+
**hardware_decision**（旁路）：硬尺寸上限下没有能装下的候选，交用户取舍
|
|
94
|
+
|
|
95
|
+
允许的动作：`question.card`（发布一张问题卡，等待用户回答）。
|
|
96
|
+
|
|
97
|
+
规则：
|
|
98
|
+
|
|
99
|
+
1. 本轮不重新选型、不修改需求、不出图；只发一张问题卡，让用户在“换件”和“放宽尺寸”之间选择，然后结束本轮。
|
|
100
|
+
|
|
101
|
+
**real_image**：把外观基准图与当前硬件绑定
|
|
102
|
+
|
|
103
|
+
完成标志：宿主已保存 `appearance_baseline`。
|
|
104
|
+
|
|
105
|
+
允许的动作：`studio.prepare`（保存外观目标，冻结本次创建的来源）。
|
|
106
|
+
还原（restore）改为：`studio.prepare`（保存外观目标，冻结本次创建的来源）、`image.import`（把识别出的真实产品图（没有时用用户上传图）结算为外观基准图）。
|
|
107
|
+
|
|
108
|
+
规则：
|
|
109
|
+
|
|
110
|
+
1. 将可复用的概念图绑定当前硬件，作为外观基准；缺少可用图片时回到概念图阶段，不在绑定阶段生图。
|
|
111
|
+
2. 用户明确要求重画时，在用户回合准备新的图片版本，保留原产物。
|
|
112
|
+
3. 不要修改需求；待答的问题卡保持原样，不代用户回答。
|
|
113
|
+
|
|
114
|
+
还原（restore）改用：
|
|
115
|
+
|
|
116
|
+
1. 将参考证据中识别出的真实产品图绑定当前硬件，作为外观基准；还原路径不生成概念图。
|
|
117
|
+
2. 用户明确要求重画时，在用户回合准备新的图片版本，保留原产物。
|
|
118
|
+
3. 不要修改需求；待答的问题卡保持原样，不代用户回答。
|
|
119
|
+
|
|
120
|
+
**cad**：形成可旋转的首版 CAD
|
|
121
|
+
|
|
122
|
+
完成标志：宿主已保存 `cad_candidate`。
|
|
123
|
+
|
|
124
|
+
允许的动作：`cad.build`（构建 CAD 候选，含几何检查与实际渲染）。
|
|
125
|
+
|
|
126
|
+
规则：
|
|
127
|
+
|
|
128
|
+
1. 优先快速形成可旋转的首版，结合外观基准图与真实硬件重建。
|
|
129
|
+
2. 不缩放任何原生元器件；组件优先复用可信 CAD 的原生比例，只有缺少真实资产的项才明确标为包络；缺失的尺寸不要当作已知值。
|
|
130
|
+
3. 坐落件相对结构骨架的基准面放置，不为每个组件手填独立的绝对坐标。
|
|
131
|
+
4. 保留外观基准图的轮廓、长宽厚比例、圆角、屏幕和按钮相对位置及材质，按匹配的参考视角输出实际渲染，不用通用方盒替代。
|
|
132
|
+
5. 失败就按回执诊断修正后重试；同一错误连续出现时换一种实现方式。
|
|
133
|
+
6. 不要重新登记硬件、不要修改需求或重新出图；视觉审查在下一阶段进行；待答的问题卡保持原样，不代用户回答。
|
|
134
|
+
|
|
135
|
+
外形未锁定（`locks.shape=false`）时插入为第 2 条：外形未锁定：硬件放得下优先，但外壳只能在 appearance 认可的外观容差内调整尺寸与比例，并记录调整量及依据；超出容差时换件（交回硬件）或把取舍交给用户，不得自行放大外壳。
|
|
136
|
+
|
|
137
|
+
外形已锁定（`locks.shape=true`）时插入为第 2 条：外形尺寸与比例已锁定：不得放大或缩小外壳；装不下时停止建模，先交回硬件换件，仍不行再调整结构骨架，改外形必须由用户决定。
|
|
138
|
+
|
|
139
|
+
**fallback**（旁路）：建模没有产出可展示的 CAD 时，由宿主生成标注清楚的简化草模
|
|
140
|
+
|
|
141
|
+
允许的动作：`cad.build`（构建 CAD 候选，含几何检查与实际渲染）。
|
|
142
|
+
|
|
143
|
+
规则：
|
|
144
|
+
|
|
145
|
+
1. 宿主按冻结的硬件尺寸生成一份已明确标注的简化草模；本轮不调用模型，不进行视觉审查。
|
|
146
|
+
|
|
147
|
+
**review**：审查这一版的实际渲染
|
|
148
|
+
|
|
149
|
+
完成标志：宿主已保存 `review`。
|
|
150
|
+
|
|
151
|
+
允许的动作：`visual.review`（按契约审查这一版的实际渲染）。
|
|
152
|
+
|
|
153
|
+
规则：
|
|
154
|
+
|
|
155
|
+
1. 按契约审查这一版，审查对象全部取自 CAD 回执，不要猜；然后用一两句话向用户说明结果。
|
|
156
|
+
2. 不要重新建模、不要重新出图、不要修改需求；待答的问题卡保持原样，不代用户回答。
|
|
157
|
+
|
|
158
|
+
还原（restore）改用：
|
|
159
|
+
|
|
160
|
+
1. 以识别出的真实产品图为基准，按契约审查这一版，审查对象全部取自 CAD 回执，不要猜；然后用一两句话说明与原产品的差异。
|
|
161
|
+
2. 不要重新建模、不要重新出图、不要修改需求；待答的问题卡保持原样，不代用户回答。
|
|
162
|
+
|
|
163
|
+
**repair**（旁路）：只修正检查发现的问题
|
|
164
|
+
|
|
165
|
+
允许的动作：`cad.build`（构建 CAD 候选，含几何检查与实际渲染）。
|
|
166
|
+
|
|
167
|
+
规则：
|
|
168
|
+
|
|
169
|
+
1. 只修改检查报告或几何分诊指出的冲突部位与实例，逐项保留其余实例；需要整体重建时按缺失的硬件与冲突证据完整重建。
|
|
170
|
+
2. 尽量保留外观基准图的轮廓、比例、特征位置与材质；不缩放原生元器件。
|
|
171
|
+
3. 不要修改需求、重新选型或重新出图；先完成轻量预览，视觉复检在下一阶段进行；待答的问题卡保持原样，不代用户回答。
|
|
172
|
+
|
|
173
|
+
**questions**（旁路）：首版之后合并询问按默认处理的事项
|
|
174
|
+
|
|
175
|
+
允许的动作：`question.card`（发布一张问题卡，等待用户回答）。
|
|
176
|
+
|
|
177
|
+
规则：
|
|
178
|
+
|
|
179
|
+
1. 首版之后，读取已登记的硬件选型与系统假设，把首版之前按默认处理、至今仍按默认处理的事项合并成一张问题卡：最多三题，每题最多三个可直接选的方案，第一个选项写首版当前采用的默认值并注明“（首版已按此）”。
|
|
180
|
+
2. 这张卡每次按当前状态重新生成，不是保存的问题队列：用户已改掉或已不再适用的默认不再出现，首版之前按例外问过并已答复的事项不重复询问。
|
|
181
|
+
3. 意图、目标深度或型号识别仍有疑问时，可以作为其中一题，第一个选项写首版采用的判断。
|
|
182
|
+
4. 没有待确认项就不发卡，一两句话说明后结束本轮。
|
|
183
|
+
5. 不要修改需求、重新选型、建模或出图；用户的答复作为对首版的修订处理。
|
|
184
|
+
|
|
185
|
+
<!-- journey-stage-plan:end -->
|