abelien-harness 0.9.0 → 0.11.0

package/README.md

@@ -127,7 +127,7 @@ tool-receipt successor 与已有可信 runtime decision 也可以取得后续 co
 现行入口不再维护独立的“主控业务提示词”。宿主指令只交代身份、skills 的用途、读取／调用方式与授权边界；具体对话调度放在 guide，作品旅程与业务规则放在 workspace，领域工作放在对应 skill。它们可以由同一个宿主 Agent 执行，不需要额外的主控 Agent；旧 controller 文档仅作历史参考，不与 skills 流程重复注入。
 
 - 对话调度与沟通由 [abelien-guide](skills/abelien-guide/SKILL.md) 负责：组织上下文、调用领域 skill、呈现问题和结果；阶段、版本和确认条件统一读取 workspace。
-- 作品规则由 [abelien-workspace](skills/abelien-workspace/SKILL.md) 维护：完整 A1–C、采用与版本、组合检查、确认和交付恢复。其 `user-journey` 是单个 Agent 步骤，Harness 提供通用运行机制；产品服务的实际接入边界见 workspace 调用说明。
+- 作品规则由 [abelien-workspace](skills/abelien-workspace/SKILL.md) 维护：完整 A1–C、采用与版本、组合检查、确认和交付恢复。作品推进没有 workflow：宿主持有作品状态，A1 通过之后的阶段与规则取 `workspace.journey-next`；产品服务的实际接入边界见 workspace 调用说明。
 - 需求澄清为 [abelien-clarify](skills/abelien-clarify/SKILL.md)：把用户原话整理成 requirements、区分用户事实与系统假设、只问阻塞当前操作的问题，附只读校验脚本；共用表达规则随 guide 的 references 分发。两者自 2026-10-11 起以本仓为唯一编辑源，直接在 `skills/abelien-clarify/` 与 `skills/abelien-guide/references/` 修改，见下文「快照来源」。
 - 各 bundle 均为标准 `SKILL.md`（含 name/description/license/compatibility，
   兼容 claude-code / hermes / pi），agent 按 description 触发词路由；claude-code 与
@@ -142,19 +142,19 @@ tool-receipt successor 与已有可信 runtime decision 也可以取得后续 co
 
 ## 产品旅程与 PRD
 
-完整规则统一维护在 [workspace 用户旅程](skills/abelien-workspace/references/user-journey.md)。`user-journey` 是一个 Agent 驱动入口：A1–C 的判断与回流发生在 `drive-product-journey` 步骤内；必要答案、证据或能力未齐时保持暂停，真实同版确认快照保存并交代交付状态后才提交交接。JSON 的 `journey` 不由内核自动解释，`done` 不能证明产品确认。具体恢复及旧实例迁移见 [调用说明](skills/abelien-workspace/references/harness-binding.md)。
+完整规则统一维护在 [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)。
 
 ```bash
-node skills/abelien-harness/scripts/ab.mjs --workdir <作品工作目录> workflow run user-journey --input '{"prompt":"用户真实创作意图"}'
-# awaiting_agent@drive-product-journey → Agent 按 workspace 规则、通过 guide 调度，在同一步骤内跨轮推进
+node skills/abelien-harness/scripts/ab.mjs --workdir <作品工作目录> capability run workspace.journey-next --input '{"intent":"create","artifacts":{"reference_final":true}}'
+# → 下一阶段、goal、directives 与 actions；宿主按它执行，硬件阶段再运行 user-journey-hardware
 ```
 
 ### PRD 随需求对话维护
 
 PRD 以用户指定的飞书模板 revision 191 为结构依据，保留七块总览、逐条需求清单与图片引用；从 A1 起每轮登记／修改／撤回需求，保留 ID、来源与历史，选型和检查回来后再更新关联行。定义与写入语义集中在 [PRD 契约](skills/abelien-workspace/references/prd-contract.md)，模板随 workspace 安装。产品写入／回读接口尚未接入，不能把规则声明说成自动写入已实现。
 
-`user-journey-mock`、专属 workspace mock 能力和 draft／quote 样例状态机已移除，旧记录与 [MVP 实录](docs/mvp/journey.md) 仅用于历史核对，不再提供运行入口。当前 eval 共五条场景：`user-journey-entry` 只验证入口暂停，不表示产品 E2E 通过；`user-journey-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`（候选不产生正式选型）。桩是评估进程内的假服务，**不**证明选型质量，也**不**证明服务端已就位。
-基础需求足够后推进首版；guide 在宿主实际展示条件满足时通过可选选择题卡片邀请交互细化并告知可“随时收尾”。PRD 从已保存需求起可读，不强制展开或增加文档确认关卡。收尾切入同一作品的[成果体验](skills/abelien-workspace/references/user-journey.md#result-experience)：收起全部编辑面板，有可运行仿真就进入仿真，否则按真实播放器能力提供 Three.js 状态动作演示；保留 PRD 查看／草稿或确认版导出及返回编辑入口。展示模式与方案确认独立，不能用收尾、演示状态或草稿导出触发 workflow 完成。宿主 UI／播放器仍须实际接入，历史入口测试不证明体验已实现。
+`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`（候选不产生正式选型）。桩是评估进程内的假服务，**不**证明选型质量，也**不**证明服务端已就位。
+基础需求足够后推进首版；guide 在宿主实际展示条件满足时通过可选选择题卡片邀请交互细化并告知可“随时收尾”。PRD 从已保存需求起可读，不强制展开或增加文档确认关卡。收尾切入同一作品的[成果体验](skills/abelien-workspace/references/user-journey.md#result-experience)：收起全部编辑面板，有可运行仿真就进入仿真，否则按真实播放器能力提供 Three.js 状态动作演示；保留 PRD 查看／草稿或确认版导出及返回编辑入口。展示模式与方案确认独立，不能用收尾、演示状态或草稿导出代替确认。宿主 UI／播放器仍须实际接入，历史入口测试不证明体验已实现。
 
 ### 真实硬件阶段
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "abelien-harness",
-  "version": "0.9.0",
+  "version": "0.11.0",
   "description": "npx-installable multi-agent skill harness: generic kernel + pluggable domain packs",
   "type": "module",
   "engines": {
@@ -20,6 +20,7 @@
   "scripts": {
     "test": "node --test",
     "eval": "node eval/run.mjs",
+    "render:journey-plan": "node tools/render-journey-plan.mjs",
     "prepare": "node scripts/install-hooks.mjs",
     "branch:new": "node scripts/new-branch.mjs",
     "sync": "node scripts/sync.mjs",

package/skills/abelien-algorithm/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: abelien-algorithm
-description: 基于已验证的 Abelien 硬件型号，为产品 reaction 联网检索并选择有来源的端侧算法、模型、库或成熟云服务。优先读取硬件厂商官方资料，再检索模型官方资料、Hugging Face 和云服务官方文档；不用于硬件选型、代码实现或服务部署。
+description: 为产品 reaction 联网检索并选择有来源的端侧算法、模型、库或成熟云服务。需求明确后即可检索实现资料（与硬件选型并行），硬件登记后补查厂商资料并逐 reaction 绑定到已选型号；不用于硬件选型、代码实现或服务部署。
 license: MIT
 compatibility:
   - claude-code
@@ -12,25 +12,33 @@ metadata:
 
 # Abelien Algorithm
 
-本包只处理硬件型号已经验证后的算法与实现选型。输入必须引用 `status=verified` 的 `hardware-selection` 资源及其版本；如果资源不存在、版本不一致、`selected_models[]` 为空，或缺少识别硬件所需的厂商/型号信息，停止并返回具体缺口，不能根据类别名猜设备。
+本包分两步完成算法与实现选型（P2-03 算法并行车道，2026-10-14）：
+
+1. **研究（不依赖硬件）**：需求明确后就为每个 reaction 检索实现资料，与硬件选型同时进行；候选写明资源需求（算力、内存、接口、传感器、联网），不猜硬件型号。
+2. **绑定（硬件登记后）**：读取已登记的 `hardware-selection`（id 与 revision），补查已选型号的厂商资料，每个 reaction 绑定到具体 `component_id` 并复核兼容。硬件尚未 verified 也可以绑定，结果保持待确认。`selected_models[]` 为空或缺少厂商／型号时停止并返回具体缺口，不能根据类别名猜设备。
+
+车道在哪个阶段做哪一步由 workspace 的 `workspace.lanes-next` 决定（见[意图路由 §4.1](../../docs/architecture/intent-routing.md)）。
 
 与同级 [structure](../abelien-structure/SKILL.md) 可在各自依赖满足后分别推进：将摄像头视野、拾音／发声开口、散热、动作范围等有依据的结构要求交回；结构反馈遮挡、空间或运动冲突时重判受影响绑定。换硬件须回 hardware 并重新核对版本。算法选型成功不代表装配或设备行为已经实测通过。
 
 ## 渐进加载
 
 1. 每次研究先读[联网检索与排序规则](references/research-policy.md)。
-2. 准备提交候选时再读[算法选型服务契约](references/selection-service-contract.md)。
-3. 运行 `user-journey-algorithm` workflow；Agent 暂停步骤中读取硬件资源、联网检索并形成每个 reaction 的 `bindings[]`，随后由本地 `algorithm.finalize` 归一化保存。
+2. 准备提交候选或绑定时再读[算法选型服务契约](references/selection-service-contract.md)。
+3. 研究：`algorithm.research`（`purpose=implementation`，查询带 `reaction_id`）→ 读正文 → `algorithm.candidates` 提交每个 reaction 的候选（格式见 [algorithm-candidates.v1](schemas/algorithm-candidates.v1.json)），保存为 `status=proposed`。
+4. 绑定：`algorithm.research`（`purpose=hardware`，查询带 `component_id`）→ `algorithm.finalize`（`operation=bind`，`research` 格式见 [algorithm-bindings.v1](schemas/algorithm-bindings.v1.json)）。来源只写 `research_id` 与 `page_id`，回执由 Harness 从自己存下的正文填写。
+5. 宿主在每个阶段开跑前用只读的 `algorithm.lane-state` 查当前需求有没有已提议的候选、候选有没有绑定到当前硬件，映射成 `workspace.lanes-next` 的 artifacts。
+6. 已有的 `user-journey-algorithm` workflow（先有 verified 硬件再研究）保持可用，供不走车道的宿主使用。
 
 ## 核心边界
 
-- 检索顺序是硬件厂商官方资料 → 算法/模型官方资料 → Hugging Face → 云服务厂商官方资料。搜索结果页、博客和聚合文章只能用于发现线索，不能单独支持最终选择。
+- 研究步骤先看宿主给出的库内已适配算法（2026-09-16 决定：库内优先、库外再联网），再按算法/模型官方资料 → Hugging Face → 云服务厂商官方资料检索；绑定步骤先查已选型号的硬件厂商官方资料。搜索结果页、博客和聚合文章只能用于发现线索，不能单独支持最终选择。
 - 必须明确 `edge`、`cloud` 或 `hybrid`。离线、隐私、网络、延迟、费用或数据地域限制属于硬约束，不得为了找到候选而静默改成云端。
 - 端侧候选要核对处理器架构、OS/固件、runtime、算子、RAM、Flash/存储、加速器、输入输出格式及外设接口；没有精确设备实测时，不能承诺真实性能。
 - 交互类需求可以比较本地模型和云端 API，但“模型仓库存在”不等于“已有可调用云服务”，“当前 Agent 能调用模型”也不等于用户设备具备该能力。
 - 发现、兼容复核、集成、部署和实测是五种不同状态。本包只完成前两项并保存版本化选型结果。
 
-`algorithm.finalize` 不访问网络；它回读真实硬件基线，并要求可信宿主的来源读取凭据，检查完整 reaction、型号／版本绑定和硬约束覆盖。只有元数据或 Agent 自述“已回读”不会获得 `verified`；裸 CLI 没有宿主证据解析器时保持待确认。具体字段及回执边界见选型服务契约。旧 `algorithm.select` HTTP 能力为兼容已有部署保留。来源不可回读、候选版本不确定或存在阻塞未知项时，结果保持待确认，不伪造验证。
+`algorithm.finalize` 不访问网络；它回读真实硬件基线，并核对来源回执，检查完整 reaction、型号／版本绑定和硬约束覆盖。只有元数据或 Agent 自述“已回读”不会获得 `verified`。回执来自可信宿主注入的证据解析器，或（`operation=bind`）来自 `algorithm.research` 自己读取并按 sha256 存下的正文；检索摘要（`text_source=search_snippet`）只用于发现，永远不算证据。具体字段及回执边界见选型服务契约。旧 `algorithm.select` HTTP 能力为兼容已有部署保留。来源不可回读、候选版本不确定或存在阻塞未知项时，结果保持待确认，不伪造验证。
 
 ## Prismer source documents
 

package/skills/abelien-algorithm/domain.json

@@ -1,9 +1,58 @@
 {
   "name": "abelien-algorithm",
-  "version": "0.2.0",
-  "description": "基于已验证硬件进行官方资料优先的联网算法选型与兼容复核",
-  "resources": ["algorithm-selection"],
+  "version": "0.3.0",
+  "description": "算法域包：需求明确后即可检索实现资料（与硬件选型并行），硬件登记后补厂商资料并逐 reaction 绑定、复核兼容",
+  "requires": ["abelien-harness"],
+  "resources": ["algorithm-selection", "algorithm-research"],
   "capabilities": {
+    "algorithm.research": {
+      "description": "执行 Agent 的检索计划并保存证据：purpose=implementation 只凭需求检索实现资料（可与硬件选型并行），purpose=hardware 检索已选型号的厂商资料；Volc 检索（每次最多 5 条）与公开 HTTPS 页面安全直读，正文按 sha256 存证；每条付费检索先存 sent 再发送，重跑复用已完成检索、结果未知时要求对账而不重发；同一请求完成后重复运行直接返回已有结果",
+      "adapter": {
+        "type": "module",
+        "path": "scripts/research.mjs",
+        "export": "researchAlgorithms"
+      },
+      "input": { "from": "input" },
+      "resultContract": {
+        "nonEmptyStrings": ["id", "status", "schema", "request_digest", "purpose"],
+        "arrays": ["reactions", "searches", "pages", "unknowns"],
+        "statusValues": ["collected"]
+      },
+      "produces": "algorithm-research",
+      "checkpoint": true,
+      "checkpointContract": {
+        "nonEmptyStrings": ["id", "status", "schema", "request_digest", "purpose"],
+        "arrays": ["reactions", "searches", "pages", "unknowns"],
+        "statusValues": ["in_progress", "collected"]
+      }
+    },
+    "algorithm.candidates": {
+      "description": "核验 Agent 基于 implementation 研究为每个 reaction 提出的候选实现：引用须逐字出现在本次研究存下的正文，候选只能引用为自己 reaction 检索的页面，库内算法须来自研究输入的库清单；每个 reaction 要么有候选、要么写明未解决原因；保存为 status=proposed，不依赖硬件",
+      "adapter": {
+        "type": "module",
+        "path": "scripts/candidates.mjs",
+        "export": "proposeAlgorithmCandidates"
+      },
+      "input": { "from": "input" },
+      "resultContract": {
+        "nonEmptyStrings": ["id", "status", "schema", "collected_id"],
+        "arrays": ["candidates", "unresolved", "unknowns"],
+        "statusValues": ["proposed"]
+      },
+      "produces": "algorithm-research"
+    },
+    "algorithm.lane-state": {
+      "description": "只读：按本草稿已存的资源回答当前需求有没有已提议的候选（落点、reaction、limits 与研究时一致），以及这些候选有没有绑定到给定的硬件选型 id 与 revision；宿主把结果映射成 workspace.lanes-next 的 artifacts",
+      "adapter": {
+        "type": "module",
+        "path": "scripts/lane-state.mjs",
+        "export": "algorithmLaneState"
+      },
+      "input": { "from": "input" },
+      "resultContract": {
+        "nonEmptyStrings": ["requirements_digest"]
+      }
+    },
     "algorithm.select": {
       "description": "复核 Agent 联网研究证据，选择端侧、云端或混合实现并形成版本化算法选型",
       "adapter": {
@@ -29,7 +78,7 @@
       "produces": "algorithm-selection"
     },
     "algorithm.finalize": {
-      "description": "把 Agent 基于硬件型号和官方联网证据做出的算法绑定归一化为版本化选型资源",
+      "description": "把 Agent 基于硬件型号和官方联网证据做出的算法绑定归一化为版本化选型资源；operation=bind 时候选取自 algorithm.candidates，来源回执从 Harness 自己存下的研究正文解析，硬件基线尚未 verified 时结果固定为 needs_confirmation",
       "adapter": {
         "type": "module",
         "path": "scripts/finalize-selection.mjs",
@@ -56,7 +105,12 @@
       "initial": "researched",
       "states": ["researched", "selected"],
       "transitions": [
-        { "from": "researched", "to": "selected", "on": "confirmSelection", "guard": { "status": "verified" } }
+        {
+          "from": "researched",
+          "to": "selected",
+          "on": "confirmSelection",
+          "guard": { "status": "verified" }
+        }
       ]
     }
   },

package/skills/abelien-algorithm/references/research-policy.md

@@ -1,12 +1,18 @@
 # 联网检索与排序规则
 
-只在算法研究步骤中读取。研究对象是用户 reaction 在已验证硬件上的实现，不是泛泛推荐热门模型。
+只在算法研究与绑定步骤中读取。研究对象是用户 reaction 在本产品上的实现，不是泛泛推荐热门模型。
 
-## 输入门槛
+## 两个步骤的输入
+
+**研究（`algorithm.research` purpose=implementation，与硬件选型并行）**只需要需求：每个 reaction 的触发与反应、落点和 limits。不读取、不猜测硬件型号；候选的资源需求（算力、内存、存储、runtime、联网、接口、传感器）按来源原文记录，原文没写的填 null。离线、隐私、延迟、费用等硬约束从这一步就用来筛选。宿主给出的库内已适配算法优先，库外再联网。
+
+**绑定（`algorithm.research` purpose=hardware → `algorithm.finalize` operation=bind）**在硬件登记后进行，按下面的门槛读取硬件资源。硬件尚未 verified 时照常核对，结果保持待确认。
+
+## 绑定的输入门槛
 
 先通过 `ab resource get <hardwareSelectionId>` 读取完整资源，并逐项确认：
 
-- kind 为 `hardware-selection`，body.status 为 `verified`；
+- kind 为 `hardware-selection`；body.status 为 `verified`，否则（bind）结果只能是待确认；
 - 资源 revision 与 workflow 输入版本一致；
 - `selected_models[]` 给出稳定 `component_id`，并有足以查找官方资料的厂商和准确型号；
 - reaction 包含输入、期望输出、场景及离线、隐私、延迟、精度、功耗、成本等硬约束。
@@ -15,6 +21,8 @@
 
 ## 来源顺序
 
+研究步骤从第 2 项开始（尚无硬件）；绑定步骤先补第 1 项，再引用研究步骤已读的第 2–4 项。
+
 1. **硬件厂商官方资料**：产品页、datasheet、SDK/runtime 文档、官方 model zoo、官方示例和兼容矩阵。先确认硬件能够运行什么。
 2. **实现官方资料**：模型或算法维护方的版本化文档、发布记录、模型卡和许可。确认实现本身的 I/O、依赖与限制。
 3. **Hugging Face**：按任务标签、准确硬件/runtime 关键词和 reaction 关键词搜索。记录 repo ID、revision/commit、pipeline tag、framework、license、文件规模和模型卡声明；下载量或点赞只能作为次级排序信息。

package/skills/abelien-algorithm/references/selection-service-contract.md

@@ -2,6 +2,56 @@
 
 本文件只在向 `algorithm.finalize` 提交联网研究结果时读取。Harness 不实现搜索引擎、Hugging Face 或云厂商客户端；联网由宿主 Agent 使用获准工具完成，本地能力负责检查结果形状并保存稳定引用。旧 `algorithm.select` HTTP 能力只为兼容已有部署保留。
 
+## 并行车道：research → candidates → bind（P2-03，2026-10-14）
+
+宿主按 `workspace.lanes-next` 的步骤调用以下三项；全部是 `ab capability run`，不需要宿主注入证据解析器。Agent 提交的两份内容各有 schema，宿主可原样用作工具参数定义：[`schemas/algorithm-candidates.v1.json`](../schemas/algorithm-candidates.v1.json)（`algorithm.candidates` 去掉 `research_id`）与 [`schemas/algorithm-bindings.v1.json`](../schemas/algorithm-bindings.v1.json)（bind 的 `research`）。字段与脚本里的常量由测试保证一致。
+
+### `algorithm.research`
+
+```json
+{ "purpose": "implementation",
+  "requirements": { "context": {}, "reaction": [{ "id": "r1", "text": "…" }], "limits": [] },
+  "library": [{ "entry_id": "lib-1", "name": "microWakeWord", "category": "语音 · 唤醒词" }],
+  "plan": { "queries": [{ "reaction_id": "r1", "query": "offline wake word model microcontroller", "count": 5 }], "max_pages": 8 } }
+```
+
+- `purpose=implementation`：只凭 clarify 的需求；每条查询带一个需求里的 `reaction_id`，不带 `component_id`。`library` 是宿主给的库内已适配算法（可省略）。
+- `purpose=hardware`：另给 `hardware_selection_id` 与 `hardware_selection_revision`；每条查询带选型资源里的一个 `component_id`。硬件可以尚未 verified。
+- 产出 `algorithm-research`（schema `abelien.algorithm-research.v1`，`status=collected`）：`searches[]`、`pages[]`（`id`、`url`、`final_url`、`reaction_id`／`component_id`、`fetched_at`、`text_blob_ref`、`text_sha256`、`text_source`）和 `unknowns[]`。正文读不到的页面保留检索摘要，`text_source=search_snippet`，只用于发现。
+- 付费检索先存 sent 再发送；同一请求完成后重跑直接返回已有结果；停在 sent 而结果未知的检索以 `ALGORITHM_WEB_RECONCILIATION_REQUIRED` 要求对账，不重发。缺 `WEB_SEARCH_API_KEY` 时以 `ALGORITHM_WEB_CONFIG` 在任何发送前失败。
+
+### `algorithm.candidates`
+
+```json
+{ "research_id": "algorithm-research:alg-res-…",
+  "candidates": [{ "reaction_id": "r1", "implementation_ref": "microWakeWord", "implementation_version": "v2.1.0",
+    "implementation_type": "model", "execution_target": "edge", "library_entry_id": "lib-1", "summary": "本地唤醒词检测",
+    "needs": { "compute": "TensorFlow Lite Micro", "memory": "about 30 KB of RAM", "storage": null, "runtime": null, "network": null, "interfaces": ["I2S microphone"], "sensors": [] },
+    "quotes": [{ "page_id": "p1", "text": "needs about 30 KB of RAM on ESP32-S3 class chips" }] }],
+  "unresolved": [{ "reaction_id": "r2", "reason": "…" }], "unknowns": [] }
+```
+
+- 只接受 `status=collected`、`purpose=implementation` 的研究。引用规范化空白与全半角后须逐字出现在该页存下的正文（至少 8 字）；可以引用本次研究读到的任一页，同一份实现资料常常同时支撑几个 reaction。`library_entry_id` 须来自研究输入的库清单。不是库内算法时至少一条引用。
+- `implementation_ref` 是简短名称（≤80 字，不带网址和说明，说明写 `summary`），绑定与 PRD 原样引用；`implementation_version` 只写来源写明的确定版本，没写填 `null`，latest／main 等浮动值拒绝。
+- 每个 reaction 要么至少一个候选，要么写进 `unresolved` 并说明原因。
+- 一次提交里每个候选、每条 unresolved 的问题合并在同一个 `VALIDATION` 里返回（最多 8 条），Agent 一轮改完。
+- 产出 `status=proposed` 的 `algorithm-research`，带 `collected_id`、`candidates[]`（每项标 `evidence`：`page`／`library`／`search_snippet`）与 `unresolved[]`。
+
+### `algorithm.finalize` 的 `operation=bind`
+
+在下文 select 请求的字段之外给 `operation: "bind"` 与 `proposed_id`（上一步的 proposed 研究）。差别只有四处：
+
+1. `research.candidates` 可省略，默认取 proposed 研究里的候选。
+2. 来源只写 `research_id` 与 `page_id`：Harness 从自己存下的正文填写 `url`、`accessed_at`（该页 `fetched_at`）、`content_sha256` 与 `evidence_ref`（`algorithm-research:<研究 id>#<page_id>`），提交里的这四个字段一律丢弃，再按下文的确定性质量门比对。只认 proposed 研究的原研究，以及同一硬件选型 id 与 revision 的 `purpose=hardware` 研究；检索摘要页不算回执，指不到正文页的来源不带回执、保持未验证。宿主若另行注入 `readEvidence`，核对时以宿主为准。
+3. 每条 binding 的 `implementation_ref` 须是该 reaction 已提议的候选之一，否则记一条阻塞未知。
+4. 硬件基线可以不是 verified：照常核对，并追加一条阻塞未知，结果固定为 `needs_confirmation`。
+
+结果另带 `operation: "bind"` 与 `proposed_id`。select 请求的行为不变。
+
+### `algorithm.lane-state`（只读）
+
+输入 `{ requirements, hardware_selection_id?, hardware_selection_revision? }`，输出 `{ requirements_digest, proposed_id, selection_id, selection_status }`。`proposed_id` 是本工作目录里落点、reaction、limits 与当前需求相同（与 research 同一规范化规则）的最新 proposed 研究；`selection_id` 是绑定到这份候选、且硬件选型 id 与 revision 相同的最新 bind 结果。换硬件后候选仍可用、绑定作废；改了 reaction 或 limits 两者都作废。
+
 ## 请求
 
 本地 module adapter 接收：