RoboGuide

RoboGuide 是一套面向异构具身智能体协作的通用分布式具身智能操作系统架构。

当前架构 source of truth 是 docs/architecture/v2/README.md 及其引用的已接受 ADR。它们记录当前实现对应的职责、协议语义、关键闭环和架构约束；原始 RoboGuide_Architecture_Baseline_V2.docx 仅保留为最初 V2 基线快照，可能落后于后续演进。V1.1 作为历史基线保留。

V2 总体架构

独立原图位于 docs/images/roboguide-v2-overall-architecture.png，并已嵌入 V2 DOCX。仓库内的结构化摘要见 docs/architecture/v2/README.md。

系统目标

RoboGuide 统一感知系统状态、物理世界状态和具身能力状态，并联合调度 Capability、Compute、Space、Time，使机器人、感知设备、交互终端、边缘算力和基础设施节点能够持续完成复杂现实任务。

它不是单纯的多机器人 Scheduler，也不以中央控制替代节点本地自治。RoboGuide 持续管理资源抽象、状态、任务与执行生命周期、跨节点协调以及故障恢复。

State & Memory Plane 中，Memory Scope（语义消费边界）、Visibility（发现/交换策略）与 Placement（Node/provider 本地副本证据）彼此独立；例如 Local + Discoverable 允许共享目录发现， 但不允许跨 Node 消费内容。Artifact 引用只标识不可变 bytes，不代表本地 provider 已导入。

前期 MVP

MVP 方向是以普通多机异构任务验证领域无关的最小闭环：

• 节点发现、身份、Capability 声明、状态与健康更新；
• Mission、Task Graph 和 Execution Requirements；
• Capability Matching 与 Capability × Compute × Space × Time 联合调度；
• Assignment Proposal、共享资源协调与 Commit；
• Execution Group 创建、绑定、执行和释放；
• Observation、Shared Belief、Reconciliation 与分级恢复。

导盲是后续应用场景，不是核心架构或 MVP 的前置假设。该方向已经明确， 但具体 Mission、节点拓扑、故障矩阵、指标和退出条件尚未冻结。完整阶段边界 见 docs/project-goals-and-mvp.md，当前决策状态 见 docs/mvp-definition.md。

当前已批准首个实现切片：Node A 执行运输与算力角色，Node B 作为运输替代节点， Edge 提供共享算力；A 故障后保留 Execution Group 上下文，只重绑定失败角色并 继续执行。完整 MVP 仍未冻结。

开发基线与首个 Bootstrap

开发基线仍以 MVP Definition Draft 为约束，但首个可运行的 Rust core bootstrap 已经开始。它用于验证领域模型、端口、控制、运行时和确定性故障恢复的边界， 尚不代表完整 MVP 已经冻结或最终运行时已经完成：

• ADR-0001 提议由 Rust 负责 Domain、Control、Runtime 和 State 等长期核心；
• Python 承载 Mission Intelligence、模型、仿真和研究型 Adapter；
• 当前 mission/ 已提供文本 Mission Request 澄清闭环、source-aware Mission Grounding View、resolved GroundedIntent handoff、 确定性 Fixture Planner 和可配置的 Responses Interpreter/Planner/Reviewer/Repairer；Mission Request v0.4 持久化结构化 Dialogue、immutable Grounding snapshot 和独立 Review history，并将 repair、重新 clarification 与 不可修复 reject 分流；Interpreter 不读取 live Node inventory，当前无 provider 不再使合法 Mission 被 Mission Intelligence 拒绝；
• contracts/capability/v0.3/ 提供 deployment-independent Canonical Capability Catalog；Planner 与 Reviewer 获得同一 capability/operation 词汇表，确定性 admission 拒绝 unknown identity、 未知/缺失参数、约束属性和类型不匹配，但 Catalog membership 不代表当前存在 provider；
• Mission 输出使用 contracts/mission/v0.7/ 中的版本化合同；v0.2-v0.6 作为兼容输入；Mission Actor、ContextRole 与 TaskRole 已正规化，每个 TaskRole 可声明多个 exact Capability requirements、 Resource requirements 与独立 semantic ExecutionIntent；每个 Task 显式声明 expected effect 及 execution-report 或 verifier-evidence satisfaction policy；
• Planner/Reviewer/Repairer 共用 config/mission.toml 中显式的 satisfaction policy；其 ref/digest 随模型输入保留，生成的 verifier receive-age bound 必须匹配配置。当前五秒窗口是系统接受 策略，不是模型猜测、Task duration 或物理真值保证。可选的 deployment-owned terminal verifier ingress 只接纳启动时冻结的 source、精确 Task predicate 和当前物理 attempt；无证据时拒绝 verifier-backed 计划，见 ADR-0039 与 ADR-0048；
• B1 shared-world runner 默认使用 scenarios/e1-shared-world-episode-51/mission-config-b1.toml 的显式权威终态确认策略：MI 的每个 DAG 末端 Task 必须绑定完整冻结目标的 verifier contract/predicate。普通 config/mission.toml 保留原有可选 basis；此策略不改变 MissionPlan、节点选择或 Habitat 官方判定，见 ADR-0049；
• B1 自动归档另外生成可选的终态几何诊断，分别记录 Habitat 官方 pddl_success、按同一 阈值重建的三维 any_at 和忽略高度后的 X/Z 反事实结果；诊断缺失或与官方终态矛盾时 标记 unavailable，绝不改变 benchmark success 或 Formal admission。见 Eval Harness；
• 当前实现从模块化单体和确定性 Fake Nodes 起步；
• core/state 已实现 Shared Node State、Allocation State v0.1、source-aware State record、 通用/Spatial Memory catalog 和 SQLite WAL evidence envelope；Control 通过 transport-neutral Port 读取节点注册、能力、资源和最新健康事实；
• 核心 Rust 包按职责位于 core/，Mission 编排位于 core/orchestration/，可运行组合入口位于 apps/controller/ 和 apps/integration-server/；
• core/artifact-store 提供独立 filesystem artifact CAS infrastructure；apps/real-node-smoke 默认 probe formal Node Protocol v0.4，显式 --simulate-execute 经 Controller synthetic Mission 触发正式 dispatch 后只发送合成生命周期事实；
• Python 工具链由 uv 和项目级 pyproject.toml 管理；
• 目标目录、依赖方向和首个异构任务闭环见 docs/development/README.md；
• 每个 Rust fn 和 Python def/async def 都必须有有效文档注释，完整规则见 docs/development/coding-standards.md；
• Rust/Python 职责边界提案由 ADR-0001 记录，当前状态为 Proposed。
• DEAIOS 与本地 EAIOS/厂商运行时的语义边界由 ADR-0002 记录，当前状态为 Proposed for MVP Slice v0.1。
• 通用异构 EAIOS 接入、canonical capability contract 与 Local Skill 映射由 ADR-0006 记录。
• 当前 transport / Local Integration Engine ownership 与设备扩展 conformance 由 ADR-0021 记录；旧 HTTP adapter 退役和 Artifact Store 隔离由 ADR-0022 记录。
• Node Protocol Registered/Ack 只在 Controller authority 与 durable checkpoint 接受事实后 返回，见 ADR-0023。
• Capability profile、semantic ExecutionIntent 与显式版本兼容边界见 ADR-0035。
• Control-visible Operation Support 与 integrated operation provider baseline 见 ADR-0036。
• source-aware State federation 与 selective Memory ownership/exchange 见 ADR-0024；node-config/v0.6 provider backend、discover/export/import workflow 与 scope 边界见 ADR-0025。
• durable command outbox、两阶段 Mission cancellation、physical attempt history、Control-owned recovery composition 与 application timer 见 ADR-0028；离线故障证据见 runtime-reliability-fault-matrix.md。

完整 MVP 切片仍需单独冻结。后续目录按首次真实实现按需创建，不提交空目录， 不允许绕过已接受的模块边界。

V2 逻辑结构

Mission / Application

外部用户、Agent 或 Application 提供 Mission / Goal，但不直接操作具体设备。

Mission Intelligence

负责 Mission Understanding、Clarification、Task Planning、Task Graph 和 Execution Requirements，回答 What needs to be achieved?。外部用户只提交文本 instruction；仅当存在 阻止 Mission semantic commitment 的 open questions 时停在 NeedsClarification，不会创建 Execution Group。合理且不改变核心目标或 Task Graph 的解释进入 assumptions；provider、Node、 Resource、placement/readiness 属于 Control，路径、姿态、速度和硬件动作属于 Local EAIOS，均不 成为用户 clarification。无 blocking 歧义并通过 计划审查与部署风险策略后，Mission Intelligence 把完整 MissionPlan 交给 Orchestration。 Interpreter 不消费 live Node/Resource inventory；Plan Accepted 只表示语义和合同可进入系统 生命周期，不表示当前部署一定可调度。当前 provider、health、readiness 与资源证据只由 Control Matching/Scheduling/Commit 使用。实现可以使用 LLM、VLM、符号规划器或混合方法， 但不能直接进行跨节点资源绑定。该边界见 ADR-0018、 ADR-0030 与 ADR-0038。

Canonical Capability Catalog 回答“这个 contract 是否属于 RoboGuide 当前语义语言”；live Inventory 与 Capability Matching 回答“当前谁能执行”。Mission Intelligence 在 Reviewer 前 确定性校验 Catalog identity、scalar parameters 和 typed capability constraints，但不读取当前 provider。当前 v0.3 Catalog 已区分 Capability、Operation 及其 direct provider-level baseline requirements；integrated operation 不会把内部 Local How 展开为全局 requirements。它仍不 定义 embodiment taxonomy、结构化 entity schema 或动态 Catalog negotiation，见 ADR-0031 与 ADR-0034。

部署可额外提供启动时冻结的抽象能力类别摘要和带 episode/dataset 身份的环境静态事实。 MI 在同一不可变 Grounding Context 中保留已知事实和未知缺口；尚未 reset 才能确定的机器人 起点不可推测。能力类别不代表当前可用 Node，只有任务与世界证据支持时才声明 Role 的 typed constraint，最终匹配和资源承诺仍由 Control 决定。见 ADR-0044。

Mission Review 不再隐藏在 Planner 调用内部。Reviewer 对 exact draft 返回结构化 issue，Mission Request Engine 保存 revision/digest-bound review evidence；RepairPlan 最多自动修复两次， RequestClarification 返回用户对话，RejectDraft 或 repair budget exhausted 才失败。Repairer 不能补写 GroundedIntent 中不存在的用户事实，见 ADR-0032。Mission Request v0.3 使用带 speaker、kind、turn identity、reply identity 和 receive time 的 DialogueTurn；Planner draft、 Reviewer issue 与 Repair attempt 保留在独立、revision-bound 的内部 deliberation trace。成功的 Interpreter assessment 会在调用 Planner 前持久化，因此后续 provider failure 不会抹掉已完成的 objective、assumptions 或 open-questions evidence。Responses Planner/Repairer 使用内部 provider-only key/value entry DTO 满足 strict structured output；返回值先确定性还原为 canonical parameter map，再通过原始 MissionPlan v0.7、implementation 和 Catalog 校验。该 DTO 不是新的 Mission wire contract。

Mission Grounding v0.1 从既有只读 State/Memory facade capture 一份 digest-bound snapshot，供 Interpreter、Planner、Reviewer 与 Repairer 在同一 deliberation cycle 共同使用。它只包含部署 明确批准为全 Mission 可消费 payload schema 的、带完整 source/freshness/provenance 的 World State evidence，以及 Global Semantic/Experience/Spatial Memory manifest metadata；Memory bytes 尚未读取。Node health/liveness、capability/resource inventory、leases、reservations、calendar 和 Runtime attempts 不进入 LLM context。State/Memory 的可恢复 transport failure 会先经过配置有界 acquisition retry，最终失败才成为可审计 gap；gap 本身不是用户语义歧义，空 context 仍然合法。World object class 不等价于 visibility，schema admission 默认 fail-closed，嵌套 evidence 不能绕过 digest 原地修改。evidence、diagnostic 与最终 snapshot bytes 均有独立上限；HTTP body 中断不会阻止另一 source 的 capture。每份 context 按 digest 不可变保存并可通过 Mission Request API 回查，且进入模型前必须匹配当前 Dialogue input。 clarification answer 才触发下一份 snapshot；多问题 answer 不携带 question_id 时保持未定向， 不会被错误绑定到最后一个问题。不同 Mission Request 的慢 Grounding/model 调用不再持有全局 生命周期锁。边界见 ADR-0037 与 ADR-0038。

Control Plane

Control Plane 负责全局决策与协调：

1. Capability Matching 根据任务需求和 Shared System View 输出 Candidate Set；
2. Embodied Scheduler 联合考虑 Capability × Compute × Space × Time，输出 Assignment Proposal；
3. Shared Resource Coordination 处理竞争、Reservation、Negotiation 和 Commit，输出 Committed Plan；
4. Execution Group Manager 管理 Create、Bind、Activate、Adapt、Complete、Release 生命周期；
5. Reconciliation & Recovery 检测现实与计划偏差，并选择最小必要恢复层级。

当前下发前恢复流程使用 typed reason/action 与 digest-bound evidence，POST 前持久化 submission fence。提交结果不明时只核对原 Mission，不重复提交或改写计划；Controller 明确拒绝后可显式重交原稿。独立 observations v0.3 保持 Request v0.4 和 MissionPlan 不变；新增完整 HTTP body 绑定的权威接纳对账见 ADR-0055。 旧 status 查询或缺少原请求指纹时继续保留不确定性。操作进度通过已注册的只读 State export 区分工作、正常等待、阻塞及未知，只有明确提供的量度与策略才报告停滞，见 ADR-0056。显式执行恢复先确认当前 实例真实停止，再由 Control 部分释放、重新匹配和 Commit/Rebind，生成新的执行实例。 次数与时间预算不因重启或重复命令重置；Actor 保持原权威绑定。见 ADR-0057。自动停滞恢复和执行期 MI 重规划仍未实现；没有 progress observer 的部署明确返回 Unknown。 Habitat 的可选导航 observer 已接入同一 State export（ ADR-0058），区分真实 wait 和 既定目标的几何进展。观测不授权停止或重试；shared-world 取消仍影响整个联合执行。 单 Role 恢复还要求部署明确声明独立停止和原上下文重执行能力，dispatch 冻结且当前 注册不变，见 ADR-0059。缺失或 耦合声明会在 Cancel 前拒绝；Control 和 outbox 继续检查后续动作。当前 Habitat 如实声明 默认联合停止、不支持中断后重试；正常双 endpoint 和单 Actor 顺序 Task 不受此限制。

部署侧 retained-world continuation 已依 ADR-0060 实现默认关闭的本地路径： 联合取消后的新 attempts 复用原世界、观察与剩余步数，已完成端不再次调用模型。 有界的精确 session/intent/new-attempt 检查与重启 fencing 属于 Local EAIOS。 ADR-0061 增加独立的整组恢复命令： 冻结全部 current attempts 与逐操作重复授权，取得完整实际停止证明后，由 Control 重新 验证原绑定、物理身份和资源承诺；暂停不释放资源，完整新 attempts 持久化后才下发。 初版只支持同一 Execution Session 的 independent 原绑定续跑，默认部署仍关闭。 原世界续跑已有单 Actor 的真实物理验证；多 Actor 联合物理停机与续跑仍未验证。 现有单 Role 恢复仍拒绝联合停止，不存在自动停滞重试。 生产 B1 启动脚本通过 ROBOGUIDE_B1_RETAIN_STOPPED_SESSION=1 显式启用，默认关闭。 仅派生运行目录中的恢复声明，冻结 Node 配置摘要，并在注册前核对 Adapter 实际只读 能力。实际 Controller/Node 进程的零 Provider/Simulator 检查入口为 tools/quality/check_group_continuation_processes.py；该入口的合成结果不构成物理实验成绩。

Scheduler 的 Proposal 不是已生效分配。只有协调成功并 Commit 后，资源占用才成为系统认可的有效承诺。

当前实现 Control Plane — Embodied Scheduler v0.2: Bounded Joint Scheduling & Future Reservations。Capability Matching 先产生 exact Candidate Set 回答 Who can；无状态 BoundedJointScheduler 在固定搜索预算内联合选择所有 Role 的 Node、独占 Resource 与最早 可行时间区间，能够回溯稳定排序下的多 Role dead end。MissionPlan v0.5 以 resources[].kind/units 声明所选资源的最低 capacity，并以相对 durable Mission acceptance 的 timing 声明 start window、deadline 与 planning duration。

只有 DAG-Ready Task 进入 Scheduling。立即决策仍依次通过 Proposal、Commit、Bind；未来决策 由 Control calendar 持久化，应用 timer 到期后重新执行 Matching 和完整 authority validation。 Scheduled/Activated/Invalidated calendar record 不是第二份物理 reservation：实际 ownership 仍只由现有 Control reservations 在 Commit 后建立。运行超过 estimated end 时资源被视为 开放占用，冲突任务保持 Ready，不会抢占运行中的 Local EAIOS。Context-scoped binding 必须 精确复用原 Node/resource。所有 normal/recovery Commit 都会拒绝覆盖其他 Task 的 future interval；scheduled Task 只允许在所属 Group 中以 exact decision Commit。decision 的最迟激活 同时受 latest-start 和 completion deadline 约束，未完整绑定或过期的 Task 不得 Activate。 过期 interval 可在窗口内重排，window-missed 则按 Task 持久化去重并保持 Ready。Normal 与 上层 policy 确认前不再进入自动 timer dispatch。Normal 与 Recovery 共用 calendar-aware 的 确定性 Role/resource primitive，但当前 future reservation 只用于 normal Ready Task。

Orchestration 通过 typed scheduling disposition 区分 deployment 不足、reconciliation、 invalid contract 与内部故障；应用不再按错误文本决定重试。跨 Task distinct Actor 的当前 实体基数不足会保留 Ready 与持久化 deferral，其他 Mission 继续，补充部署证据后可重试。 详见 ADR-0041。 资源承诺入口还必须提供当前 State，逐项重验 selected ResourceId 的 Node/kind/capacity； 无 State 的 compatibility Commit 仅限零资源 proposal，见 ADR-0042。 registry 防回滚 watermark 独立持久化，恢复仍需部署供给当前 topology；旧 physical-binding checkpoint 缺 watermark 时拒绝自动迁移，见 ADR-0043。

本切片不声称 optimal，也未实现 divisible quota、priority/fairness、travel/traffic cost、 preemption、batching、auction、RL/LLM scheduling 或 multi-role joint recovery。完整决策见 ADR-0029。

当前实现 Control Plane — Reconciliation & Recovery Slice v0.1: Assigned Node Unavailability：Control 将 Active Group 的当前 assignment 作为 desired execution configuration，并通过 Shared Node State 检查 assigned node 是否仍满足与 Capability Matching 相同的 eligibility policy。Assessment 只产生 NoAction 或 RoleRecoveryNeed，不会立即修改 Group。

Observed node unavailable
  -> Recovery Need
  -> Blocked + partial role release
  -> role-scoped Recovery Candidate Set
  -> external bounded scheduler choice
  -> Recovery Assignment Proposal
  -> Resource Coordinate / Commit
  -> committed replacement rebind
  -> Adapted -> Active

Reconciler 不选择 replacement node，也不实现 Scheduler。Controller 通过 BoundedJointScheduler 在 role-scoped Candidate Set 上产生 selection，再通过 Control API 创建 proposal。Proposal 不写 reservation；Commit 阶段重新验证 node eligibility、Role capability、resource ownership/conflict、TaskRef/Group/Role identity 和 failed binding，并原子建立 existing Group 的 replacement reservation；Rebind 只接受 CommittedRecoveryAssignment。没有 candidate、没有 proposal 或 commit conflict 都只 表示 RecoveryPending，不等于 recovery exhausted，不会自动进入 Failed。

该实现形成 Recovery Reassignment Pipeline v0.2：Who can 属于 role-scoped Capability Matching，Who should 仍属于外部 Scheduler boundary，资源能否生效属于 Shared Resource Coordination/Commit，已经 committed 的协作变化才由 Execution Group Manager Rebind。Proposal 不等于 Commit，Commit 也不等于 Group Binding。

Recovery Commitment Lifecycle v0.3 显式管理 committed-but-not-rebound ownership：

Recovery Commit
  -> Control-owned Pending Recovery Commitment
     -> Consume through Rebind
     -> Abort and release replacement resources

Control 以 (ExecutionGroupId, RoleId) 保证同一 Role 至多一个 pending commitment； CommittedRecoveryAssignment 只是 handle，真正 authority 是 Control pending collection 与唯一的 reservations。Rebind Consume 后删除 pending entry，但保留已经成为 active binding 的 reservation；Abort 只释放本次 replacement resources，Group 保持 Blocked、 Role 保持 unbound。Terminal release_group 会交叉验证并清理 active bindings、pending commitments 及所有指向该 Group 的 reservations，确保 Released Group 不再拥有资源。

Pending commitment 不是 Execution Group lifecycle state，也不写入 Shared Node State。 Abort 不表示 recovery exhausted；它允许后续重新 Match/Propose/Commit。

本切片未实现 background reconciliation loop、跨 Node 的整组重匹配、 spatial/task-timeout recovery、Mission replanning、自动 Runtime re-execution 或 recovery exhaustion policy。

Heterogeneous EAIOS Integration Contract v0.3

ExecutionIntent 以独立 semantic objective、可扩展 OperationRef(namespace, name, version) 和稳定 scalar parameter map 表达 What to execute。它不使用 enum 固化 operation，也不携带 厂商 Skill、ROS action、SDK method 或 shell command。MissionPlan v0.7 将 intent 与每个 TaskRole 显式关联；Matching 与 Scheduler 不解析 intent，Runtime 只路由，节点侧声明式 Local Integration Engine 负责将 canonical What 映射为本地 HTTP、dynamic gRPC 或 MCP workflow。

正式 gRPC Node Protocol v0.4 支持一个 Node 聚合多个 Local System。显式协商的 Node Contract v0.6 通过 exact capability profiles 上报 readiness 与 typed feasibility attributes，通过独立 OperationSupport 声明 Node 可接收的 canonical operation，并通过 canonical invocation 原样传递 Operation、objective 和 scalar parameters。Capability profile 回答节点能够证明什么，operation support 回答是否能接收 semantic invocation，operation binding 决定哪个本地 workflow 接收 intent；三者保持分层，后者只存在于 Node config v0.7。所有 Capability、 Sensor、Resource、State export 和 Memory provider 都保留唯一 owner；Execute 携带 Control 已 Commit 的 resource IDs。它还承载带当前 session/management sequence 的 peer-channel readiness evidence；实际 peer transport 和高频控制仍完全属于 Local EAIOS。 Node config v0.7 可用固定、只读、owner-qualified 的 observer 周期读取 Local EAIOS 已建立端点； Local EAIOS 响应不能自行选择 local_system_id 或 TTL，采样失败由旧证据自然过期并 fence。 execution_id 绑定 invocation、workflow digest 和 resources，冲突或模糊 dispatch 不重放。 Execute/Cancel 还携带不可变 command_id；Node journal durable receipt 只证明命令已持久接受， 不替代有序 execution lifecycle fact。Controller 先 checkpoint intent 再发送，restart 后把非终态 physical attempt 保守恢复为 Unknown 并进入 reconciliation，而不是自动重放动作。

旧同步 HTTP NodeGateway、HTTP wire DTO 和早期 configured command backend 已全部退役；它们 不再是正式 Node Protocol 或生产节点执行路径。正式异步 lifecycle、配置驱动执行、SQLite journal、heartbeat/lease 与 session fencing 由 roboguide-node 和 core/integration/ Integration Server 实现，Controller 组合 bridge 位于 core/orchestration。Artifact bytes 则 由独立的 core/artifact-store filesystem CAS 提供，不参与设备执行生命周期。 当前合同与版本关系见 contracts/node/v0.9/ 和 contracts/node/README.md。Node config v0.7 为每个 exact canonical capability profile 提供固定 readiness observation 与 attributes，将 operation/workflow mapping 独立声明，并保留选择性的 State export、Memory provider、固定 discover/export/import workflow，以及可选的 peer-channel readiness observer；通过完整 RegistrationUpdate snapshot 更新后续 Matching 和 discovery。v0.5 provider 仍可作为 metadata-only 配置启动； v0.2-v0.6 配置仍作为原 combined capability/workflow 兼容输入； Node Protocol v0.2 endpoint 只返回明确迁移错误。

设备扩展的离线合同、真实配置样例和开发者路径见 docs/extensions/device-extension-conformance-v0.2.md。 可在不启动 Controller 或 Local EAIOS 的情况下运行：

cargo run -p roboguide-node -- --validate \
  scenarios/extension-conformance-v0.1/node.toml

cargo run -p real-node-smoke -- --endpoint http://127.0.0.1:50051
cargo run -p real-node-smoke -- --endpoint http://127.0.0.1:50051 \
  --simulate-execute --control-endpoint http://127.0.0.1:8080

该 smoke 工具注册合成 Node、验证 Welcome/Registered/Heartbeat/Ack，并可在显式模拟模式 下向 Controller 提交 synthetic Mission，经真实 Match/Commit/Dispatch 验证服务器下发的 Execute 生命周期。模拟使用会话唯一的 capability contract，不会匹配已有同类 Node；它不调用 Local EAIOS，也不能替代真实设备测试。

Embodied Execution Group

Execution Group 是进入实际执行阶段后由 Control/Runtime 承载的 Mission-level 长期分布式执行上下文。v0.x 默认一个 Mission 创建一个 Group，Group 本体跨多个节点并承载多个 Task；该默认策略不禁止未来拆分多个 Group。

• Members：参与执行的 Robot、Perception、Interaction、Compute 或 Infrastructure Node；
• Roles：成员在当前任务中的职责；
• Resource Bindings：已提交的 Space、Compute、Device、Time 占用；
• Shared Context：仅当前 Group 需要的上下文；
• TaskExecution：每个 Task 在 Group 内独立经历 Ready → Active → AwaitingSatisfaction → Completed，或进入 Blocked/Failed；
• Lifecycle：Group Create → Bind → Active → Adapt → Mission Complete/Failed → Release。

Blocked 是等待 Reconciliation & Recovery 的非终态，不等于 Group 已失败或应被销毁。 单个 Task 被明确满足时才释放该 Task 的临时 binding 和 reservation；单个 Role/Member/Resource Binding 失效时，Control 只 partial release 受影响 binding，保留 Group、其他 Task 和 有效 binding。恢复成功后经 Adapted → Active 继续执行。只有 Mission Completed，或 恢复明确耗尽后的 Failed，才能执行 whole-group Release。

Role 是 Task 内与具体 Node 解耦的职责槽位：Capability 是 Node 能否承担该 Role 的 依据，Assignment 指明当前承担者，Resource Binding 则记录已经提交的执行资源。 如果 Task 直接绑定 Node，节点故障通常需要重新规划整个 Task；通过 Role 间接绑定， 系统可以只替换失败 Role 的承担节点，同时保留其他已完成工作、有效 Binding 和 Execution Group 上下文。

Member 与 Resource Binding 必须区分：GPU Node 可以是 Member，GPU quota 是 Binding；走廊是 Spatial Binding，不是 Group Member。

State & Memory Plane

State & Memory 是横向基础设施，不是 Control → State → Runtime 的线性中间层。Nodes 和 Runtime 持续写入 Observation、Evidence 与运行状态，Control Plane 读取 Shared System View，并写入 committed desired state 和 allocation state。

Observe → Update → Fuse → Believe

Shared Belief 是带有 Source、Timestamp、Freshness、Uncertainty 和冲突信息的决策视图，不等于绝对 Ground Truth。Memory 按 Local、Execution Group、Global 三种作用域管理，不要求全部全局同步。

当前代码从 Shared Node State 起步，并已扩展为多个彼此分权的 slice：

Runtime / Local EAIOS facade observation -> Shared Node State -> Control decision

core/state 使用确定性内存实现保存 Node identity、Local EAIOS/runtime descriptor、 Capability/Resource declaration、Local EAIOS 最近上报的 health，以及 RoboGuide 观察到的 liveness。State 保存“观测到了什么以及何时观测”，Control 仍根据 reported health、 freshness、liveness、lease 和 requirement 决定是否可参与 matching。

当前同时实现 State & Runtime Integration — Slice v0.1: Node Observation Ingestion。NodeGateway 仍代表 Runtime/testkit 中的 legacy Local EAIOS / Vendor Runtime 边界； Runtime 从 NodeGateway.status() 形成 transport-neutral NodeHealthObservation，通过 SharedNodeStateWriter 写入 State。成功读取 gateway 是 Reachable 证据；lease expiry 只更新为 Unreachable，不会把 Local EAIOS 最后上报的 health 篡改成 Offline。

该路径只让新的事实可被后续 Control decision 读取，不会自动触发 Block、partial release、rebind 或其他 Reconciliation 行为。

当前进一步实现 State & Runtime Integration — Slice v0.2: Observation Time Semantics。NodeStatus.observed_at 明确表示 Local EAIOS 的 source-local observation time；NodeHealthObservation.received_at 表示 RoboGuide Runtime/Control 收到该事实的 本地时间。State 同时保留二者，但以 received_at 作为当前 bootstrap 的 health observation 接纳顺序，Control TTL/freshness 也只比较 RoboGuide-local receive time。 Liveness observation 与 Lease 时间继续属于 RoboGuide-local 时间域。

该策略没有解决跨节点 clock synchronization 或 global event ordering。Source time 仅作为未来 provenance、offset estimation 和冲突推理的证据保留；NTP/PTP、clock offset 和 distributed ordering 均延后。

当前同时实现 State & Memory Plane — Allocation State v0.1。Control 的 reservations 仍是 resource commitment 唯一 authority；allocation_snapshot() 将 authority 投影为完整 AllocationViewSnapshot，由独立 InMemoryAllocationState whole-view replace。View 只表达：

• Committed：正常资源已 Commit，尚未 Bind，group_id=None；
• Bound：资源属于当前 Execution Group assignment；
• RecoveryPending：replacement 已 Commit 到 existing Group，但 Role 尚未 Rebind。

Projection refresh 独立发生，可以暂时滞后；State write 失败不回滚 Control Commit，State 内容也不能授予、拒绝或释放 reservation。Projection builder 会拒绝 orphan、重复或同时 Bound/RecoveryPending 的 Group reservation。Scheduler v0.2 读取 Control 直接提供的 immutable calendar snapshot，不读取可能滞后的 Allocation View；Commit 仍重新检查 authority。该边界记录在 ADR-0005。

当前新增 Source-aware State v0.1。共同模型显式区分 Node、World、RoboGuide 对象，以及 Desired、Committed、Reported、Observed、Derived、Belief 语义；记录 保留 source、channel、payload schema、source-local time、RoboGuide receive time、TTL 和 可选 confidence。不同来源不会互相覆盖，State 不自动制造 Global Truth 或 Belief。

Controller 的 /v1/state/providers 与 /v1/state/records 是只读 federation：Desired 从 accepted MissionPlan 读取，Committed 从 Control 读取，Reported/Observed 从 Shared Node State 和声明 channel 读取，Derived 从 Runtime/Orchestration projection 读取。这个统一视图 不改变原 authority，也不提供通用写接口。Node Config v0.6 通过固定、只读 workflow 周期采样 选择性 State；失败只让旧值自然变 stale，不改变 health/readiness 或自动触发 recovery。

当前同时实现 Selective Memory Catalog v0.1。Execution、Spatial、Semantic、Experience、 Artifact 五类 immutable Memory revision 都可以发布和发现；owner 保持在本地系统或明确的 RoboGuide component。Discoverable 可只暴露 metadata，Exchangeable 必须引用现有 Artifact CAS 中通过 digest/size 校验的 bytes。Consumer 显式选择 revision 并记录 Staged/Imported/Rejected evidence；replica durable identity 保留 exact (MemorySelector, NodeId, ConsumerProviderId)，同一 Node 的多个 Local EAIOS 不会互相覆盖。 系统不做全量复制或 P2P。合同见 contracts/state/v0.1、 contracts/memory/v0.1 和 ADR-0024。

这仍不是完整 State & Memory Plane。可驱动 Control 的 Shared Belief/fusion policy、完整 Execution/Task/Group 历史 projection、多 Controller replication/HA、访问控制、retention/GC 以及面向具体 Mission 的 consumer selection/prefetch policy、Controller 到 Node 的 durable selective-import command 仍未实现。通用 Node Memory provider workflow、filesystem/JSONL 参考 backend 和显式 data-plane CAS exchange operation 已由 ADR-0025 实现；Node 不会因为 discovery 结果自动复制 Memory。

这里的 Local Memory Provider 是统一操作合同：配置的 HTTP/gRPC/MCP workflow 把调用交给真实 EAIOS，EAIOS 保留 Memory semantic 与 backend storage authority。Node 内部 FilesystemMemoryLedger 只保存用于幂等和发现的 immutable manifest，并由这些对象重建 JSONL index；只有未配置相应 workflow 时，它才作为 reference backend fallback 保留 payload bytes。 storage_directory 因此不是 EAIOS 数据库或厂商存储路径。

当前新增 State & Memory Plane — Distributed Spatial Memory v0.1：地图以不可变 MapId/MapRevisionId + SHA-256 digest manifest 形式记录在 Catalog projection，bytes 由 独立 content-addressed Artifact data plane 保存。任意 Mission 可按显式 revision pull，节点 在受控 cache 中校验后交给本地系统；A→B 与 B→A 使用同一接口。它不是 Runtime checkpoint、 Task handoff 或 Node Protocol payload。实现边界与非目标见 ADR-0016 和 contracts/spatial/v0.1。 强 localization verification 使用独立 evidence 合同，State 明确区分带完整 evidence 的 strong verification 与旧 has_map=true smoke fact；合同见 localization-evidence-v0.1。 双狗 Node Config 已迁移到 v0.5，Robonix deployment adapter 通过固定、只读 ROS service discovery command 分别观测 mapping/localization exact-contract readiness；这不等价于强 localization evidence，也不能替代全新真机故障注入。 用于 Artifact HTTP 寻址的 MapId/MapRevisionId 统一限制为 path-safe ASCII [A-Za-z0-9][A-Za-z0-9._:-]*；Domain 构造、serde 解码与 manifest schema 使用同一规则。 Artifact HTTP v0 将未完成 upload 限制为最多 32 个、合计 8 GiB；单个 Artifact 上限 4 GiB，空闲 15 分钟或请求体传输超过 5 分钟会 abort。调用 DELETE /v1/artifact-uploads/<upload-id> 可主动释放 staging；服务启动时也会删除上次 进程遗留、无法恢复增量 digest 状态的 .partial 文件。

Distributed Embodied Runtime

Runtime 是持续驱动已经 Commit 的分布式具身执行运行下去的执行环境。它承载 Mission-level Group 的 live execution context。当前 slice 已实现 TaskExecution 的 execution identity、事件顺序归约、checkpoint fencing、recovery-required evidence 和 lifecycle transition。Runtime 成功终态只形成 TaskExecutionCompleted，Task 先进入 AwaitingSatisfaction；Orchestration 按 MissionPlan v0.7 的 policy 接纳后才产生 TaskSatisfied、推进 DAG 和释放 Task-scoped ownership。execution-report 是兼容 bootstrap policy；verifier-evidence 要求 exact verifier contract/predicate、source-aware State evidence 和 RoboGuide receive-time freshness。后者仍不是全局物理真值或多源 belief fusion。MissionPlan v0.7 还允许 Context 声明 coupling mode、typed Execution Coordination Relation、选择性的 Group shared view 和 transport-neutral peer channel；端点是稳定的 (TaskId, RoleId) 逻辑槽，Runtime 将其解析到当前 attempt，归约 Dormant/Pending/Satisfied/Violated/Unknown，并以 relation fence 阻止未经满足证明的 target Task 成功。rebind 改变 Node/attempt 而不改变关系语义，restart 则保守恢复为 Unknown；高频 相对状态与安全控制仍由 Local EAIOS 负责。 当前 SupportedMechanismProfile 只允许已实现 reducer 的 requires-active 与 shared-spatial-reference 进入执行；后者由既有 strong localization evidence 证明当前双端 attempt 使用相同 immutable map revision/frame。其余合法 typed relation 会在 Group 创建前 fail-fast。Peer channel 只有在每个 committed ContextRole 的注册 Local EAIOS 对同一 channel instance/profile/schema 提供未过期确认后才 Ready，expiry、route loss、冲突或 restart 都会 Fence；等待确认的已绑定 Task 保持 durable Ready，不回滚 Mission。 Runtime-owned timer、取消状态与显式 resume/remote pause protocol 仍待后续实现。Matching、 Scheduling、Reservation、Commit 和 replacement selection 仍属于 Control；Node Protocol、Transport、Session 和 Router 属于 Integration；Node Service 的 声明式 workflow 负责 canonical intent 到本地 EAIOS How 的映射，Artifact Store 只服务 独立数据平面。

Local Embodied Systems & Physical World

Local System 保留 Navigation、Local Planning、Perception、Motion、Hardware Control 和即时 Safety。RoboGuide 下发目标、角色、约束和资源绑定，但不把本地系统降级为 dumb slave。

部署侧 Local EAIOS 适配器位于 integrations/；例如 integrations/robonix-map-service/ 只把 canonical ExecutionIntent 映射到本机 Robonix Mapping WebUI，并维护本地执行句柄与受控地图文件。 integrations/habitat-local-eaios/ 是 C1-S0 的真实 Habitat/EMOS bridge：它在独立 habitat 环境中保留一个 simulator process，并以独立 HTTP facade 持续响应 Node workflow，将既有 mobility.navigate@v1 的 semantic destination 映射到 EMOS 所用的 Habitat Oracle navigation action，并通过稳定 local handle 上报 ACCEPTED → RUNNING → terminal。Habitat/EMOS 依赖、 PDDL entity、agent selection、path 与 pose control 均不进入 RoboGuide Core。 Controlled deployment 只在 EMOS Stage1→Stage2 边界注入 Control 已 Commit 的 assignment， 运行原始 MultiLLMPolicy、HierarchicalPolicy 和 Oracle skill stack；已分配 endpoint 使用原始 CrabAgent 及模型决策。单 Actor 执行时，未分配 endpoint 临时使用无模型 idle policy 选择 EMOS 已有的 WaitSkillPolicy，执行段结束后恢复原始 agent；双 Actor 分配仍各自使用原始 Stage2。适配器不改写模型已选动作，也不维护 prompt、重试或 skill dispatcher 副本。单 Actor 的 idle 策略与原生 EMOS 的模型决策路径不同，配对比较须归档。 Habitat pddl_success、Local skill completion、episode termination 与 RoboGuide Mission outcome 作为四类独立证据记录，彼此不得推导。 独立原生 EMOS 对照可显式使用 python -m habitat_local_eaios.native_reset_observer --evidence-dir <new-dir> --run-id <id> --episode-id <id> -- <原生 evaluator 参数>，从原厂 environment factory 进入 worker 后观察其第一个真实 Env.reset 返回状态。它复用只读的 physical diagnostics 初态 reader，不修改原生源码、seed、动作或 multiprocessing mode；后续自动 reset 不能覆盖首次快照。缺失字段与未暴露的 simulator RNG 状态仍为 unavailable，不能因此 声称完整世界状态或 RNG 相同。默认原生入口不加载此观察器。 当前 shared-world deployment 根据 Controller 已接受计划的版本化 Execution Session 选择 双 Actor 双 endpoint 并发执行，或单 Actor 在同一 endpoint 上逐 Task 复用一次 Habitat reset。 Task readiness、资源释放与下一次 dispatch 仍由 Control 决定；适配器不按官方目标数量 虚构 Actor、assignment 或 benchmark success。边界见 ADR-0045。 该部署还在 run-local、digest-bound 的 Node 配置快照中保留跨楼层能力声明，并在 Habitat reset 后、Stage2 动作前读取起点与 PDDL 目标的空间证据。对于不在官方目标中的精确 实体目的地，现有部署保留“不同楼层且注册能力明确不支持跨楼层”的拒绝规则； 官方 any_at 这样的三维距离目标即使跨楼层也保留 unknown。位置未能唯一归属语义 区域时也记录 unknown， 不宣称可达，也不代替 Control 重新分配。见 ADR-0046 与 ADR-0050。 当前 shared-world B1 部署在 endpoint 就绪前完成唯一一次 reset，冻结实际起点与精确 operation/destination/Node 的负向候选证据，并为后续 Stage2 保留同一份 observations。 integrations/habitat-local-eaios/habitat_local_eaios/preassignment_feasibility.py 生成 版本化矩阵；evaluation/src/roboguide_eval/b1_deployment_feasibility.py 将它与冻结输入 及来源 digest 交叉绑定；apps/integration-server/src/application/deployment_feasibility.rs 在部署可选启用时核对证据并收窄 Control 候选。Control 仍独占实时匹配、调度和 Commit， 未知空间证据不冒充可达性，官方成败仍由 Habitat 判定。见 ADR-0047 与 ADR-0050。 它不拥有 Mission、Execution Group、State Catalog、Artifact publication 或 Node Protocol 生命周期。节点机器仍只运行一个 roboguide-node，适配器是其本地 配置声明的 Local EAIOS endpoint。

可选的 --goal-region-navigation deployment mode 只替换 Habitat Oracle 的 目标导航点解析：对于官方合取目标中明示的距离型 any_at 实体，优先保留原始导航点； 若它不在目标区域内或当前机器人专用导航网格无法到达，则在有界候选集中选取区域内 有路径的点。模型仍选择原实体工具调用，原始控制与官方 PDDL 判定不变。 模式、原始/选中点与路径查询另行归档；启用时的 Local How 与原生 EMOS 不同， 对照时须明确记录。见 ADR-0051。

另有默认关闭的 --reset-route-support 观测（B1 环境变量 ROBOGUIDE_B1_RESET_ROUTE_SUPPORT=1，需同时启用 goal-region navigation）。它在同一次 实际 reset 后，用隔离导航网格查询两个轻量候选，输出带源码/Local How/起点绑定的 evidence/reset-route-support.json。找到静态路径、有限搜索未找到、证据不可用分别记录， 不会更改 MI 输入、Control 候选、物理执行或 benchmark 判定。启动前由 evaluation/src/roboguide_eval/b1_reset_route_support.py 校验证据一致性。 实现与限制见 ADR-0052。

可另行启用 ROBOGUIDE_B1_INITIAL_CANDIDATE_PREFERENCES=1（要求上述 route observer 已启用）， 将正向静态路径证据转为 evidence/initial-operation-preferences.json。 Controller 对当前可行的初次并发候选组合优先比较正向证据覆盖，再比较成本； Scheduler 仅调整搜索顺序，未知候选、资源约束和 Actor 绑定规则保持不变。 偏好只用于新 Controller 的首个 Mission，启动后十分钟或首次 Bind 即失效， 不进入 checkpoint、不用于后续顺序任务或恢复。它是显式的部署调度策略， 不是可达性或 benchmark 成功证明；对照实验应记录开关与源摘要。 见 ADR-0053。

另行启用 ROBOGUIDE_B1_RESET_ROUTE_GEOMETRY=1 可在上述 reset observer 中增加有界的 完整起点连通区域检查（ADR-0062）。 它检查三角面内部及参考点偏移，输出 reset-route-support v0.2；读取失败、预算耗尽、 阈值接触保持 unknown。初次偏好 consumer 可优先减少静态不相交组合，再比较正向路径 覆盖与成本，仍保留所有原有候选。静态不相交不等于物理任务不可解，不能用于永久 Actor 排除、MI 输入、任务成功或 Formal admission。此开关默认关闭，不修改导航参数。

ROBOGUIDE_B1_STEP_AWARE_NAVMESH=1 是另一个默认关闭的 Local How 选项，要求启用 goal-region navigation。它细化独立导航网格的垂直分辨率，避免已声明的正台阶高度被 粗体素向下取整为零；机器人尺寸、爬阶/爬坡能力、目标、动作控制和官方成功规则保持 原有值。执行与 reset observer 共用复制配置，Local How v0.4 和实际网格证据记录该差异。 它会改变本地路线和移动可能性，对照原生 EMOS 时必须明示；静态路径仍不等于任务成功。 见 ADR-0063。

ROBOGUIDE_B1_SPATIAL_NAVIGATION_ARRIVAL=1 单独启用默认关闭的空间到达 Local How， 要求前两个执行 profile 已明确启用。它在三维接近选定导航点前继续沿 waypoint 移动， 接近后才朝向原实体并报告本地完成；不因 X/Z 重合就在不同楼层提前停止。保留原实体、 能力、速度、阈值与技能/仿真预算，每次调用只下发一次原 base action，路径失败不伪造 直线或成功。不编辑外部 EMOS；Local How v0.6 与 action evidence v0.4 明示控制差异， 官方 PDDL 与 Mission satisfaction 仍独立判定。见 ADR-0064。

该 profile 在联合 Gym step 前，按实际动作顺序准备全部导航目标、路径和控制指令。 有界路径失败时不进入该 step，保留具体 endpoint、Task/Role/attempt、搜索原因和已有 完成记录；第一次物理 step 前失败的官方执行结果为 unavailable，reset 指标另作诊断。 成功准备后仍只有一次原 Gym step 和每个动作一次原 base dispatch。准备会初始化原有 目标/网格缓存，并非只读观察；不保证任意仿真异常可以回滚，也不证明路径全局不可达。 版本与限制见 ADR-0065。

可独立启用 ROBOGUIDE_B1_INITIAL_SUPPORT_ASSESSMENT=1，要求上述 geometry、initial preferences 和 spatial-arrival profile 已启用。生产 MI 生成并审查计划后，Request Engine 通过 Controller 的只读 POST /v1/missions/assess-initial-support 查询初始支持度。 Controller 用现有 Control Matching 的私有副本检查受支持的初始组合，不提交 Mission， 不创建资源承诺，返回精确计划/来源/有效期绑定的中性 Task/Role 反馈。所有组合都含 完整的静态不相交证据时，或所要求的预检不可用时，Request 显式 Blocked；有限搜索 未找到与 unknown 本身不阻塞。该 hold 是声明的部署就绪策略，不是物理不可解证明。

默认零次模型恢复时，显式 retry 只重查同一份已审查计划和冻结 context；通过后才走原来的 唯一提交路径。中途重启恢复为可观察的 hold，不能偷偷重规划。真实预检失败仍计入 Formal population 的系统失败，官方物理结果 unavailable。默认关闭，不改 Prompt、 机器人能力、官方任务或控制动作；初次证据不用于后续顺序 Task、恢复或新的 world。 Schema、开关、时限及未验证边界见 ADR-0066 和 反馈契约 v0.2。新反馈记录当次 查询的首个 Control 排除原因计数，不暴露 Node/Resource inventory；之后健康不改写之前原因。

ROBOGUIDE_B1_DEPLOYMENT_RECOVERY_ATTEMPTS=1..3 可另外启用有界 MI 部署重检 agent， 默认 0，要求上述 initial-support preflight 已开启。复用生产 Responses Repairer，在 同一冻结任务/context/catalog/policy/profile 下，提议 recheck、revise_plan 或 wait_for_evidence。调用前持久化原始次数和不续期的时限；相同反馈、来源变化、 过期和重启不导致重复调用。修订必须重新通过完整校验、Reviewer、必要风险审批与 Control 预检。不能删目标、伪造能力、降低真实合作需求或直接选择物理执行器。 发生提交不明后只能接纳对账，不能返回模型重规划。Session 归档进入 observations v0.4， 公共 Request/Plan 与 Formal/benchmark 规则不变。理论调用预算单独归档，不自动增加 实验的 observation deadline。实现、版本及模型验证限制见 ADR-0067 和 恢复证据契约。

三条核心语义链

Plan → Match → Propose → Coordinate → Commit → Bind → Execute
Observe → Update → Fuse → Believe
Detect → Reconcile → Adapt

系统使用四类流表达这些关系：Decision / Control、Observation / State、Binding / Lifecycle、Adaptation / Recovery。

Recovery Escalation Ladder

层级	所有者	典型处理
L0	Local Autonomy	局部避障、短程重规划、motion retry、安全停机
L1	Runtime	短暂通信错误、调用失败、重连
L2	Execution Group	成员替换、re-bind、Group adaptation
L3	Scheduler / Coordination	重新 Propose、Coordinate、Commit
L4	Mission Intelligence	Task Graph 已无法实现 Mission 时重新规划

恢复目标不是盲目重放旧命令，而是在当前物理世界中恢复任务进展，并且只升级到必要层级。

启动 Node Protocol v0.4

Server 使用正式 gRPC bidirectional streaming：

cargo run -p integration-server -- 0.0.0.0:50051

Integration Server 还接受 controller evidence SQLite 路径、Control HTTP 地址、Artifact HTTP 地址和文件 CAS 根目录；后两者默认是 127.0.0.1:8090 与 roboguide-artifacts：

cargo run -p integration-server -- \
  0.0.0.0:50051 ./var/controller-events.sqlite3 127.0.0.1:8080 \
  127.0.0.1:8090 ./var/artifacts
curl http://127.0.0.1:8080/healthz
curl 'http://127.0.0.1:8080/v1/events?limit=100&after=0'
curl http://127.0.0.1:8080/v1/state/providers
curl 'http://127.0.0.1:8080/v1/state/records?object_class=world&include_stale=false'
curl http://127.0.0.1:8080/v1/memory/providers
curl http://127.0.0.1:8090/healthz
curl http://127.0.0.1:8090/v1/maps
curl http://127.0.0.1:8090/v1/memories
# 查询已接收的 execution 状态；取消只会发出 Node Cancel 请求
curl http://127.0.0.1:8080/v1/executions/<execution-id>
curl -X POST http://127.0.0.1:8080/v1/executions/<execution-id>/cancel

实验需要把 Mission Intelligence 中的逻辑 Actor 固定到两台真实节点时，可传入第六个、 显式的 placement JSON 路径：

cargo run -p integration-server -- \
  0.0.0.0:50051 ./var/controller-events.sqlite3 127.0.0.1:8080 \
  127.0.0.1:8090 ./var/artifacts \
  scenarios/distributed-spatial-memory-v0.1/actor-placement.json

文件格式是 roboguide.actor-placement/v0.1，每条记录包含 mission_id、actor_id 和 node_id。它是 Control 的部署约束，不会写入 MissionPlan，也不会提前制造 ActorBinding；匹配时仍会检查注册、lease、健康度、liveness、能力和 contract。省略该参数 则保留通用的确定性候选选择行为。只要该配置非空，Mission 提交就启用 strict coverage： 配置必须恰好覆盖该 MissionPlan 的全部 Actor，MissionId/ActorId 拼写错误或漏配会 fail-closed，不能悄悄退回通用 Matching。

MissionPlan v0.8 可选择性声明 Actor 的 admitted physical_entity，并在 Context 内声明 distinct-physical-entities 约束。当前 Node Protocol 只允许每个 Node 对应一个可独立寻址的 物理执行体；对于需要此语义的部署，可在上述 placement 路径之后再传入第七个可选参数， 即 roboguide.physical-entity-registry/v0.1 JSON 文件路径。文件声明 registry_id、 单调 revision、routing_profile: "one-routable-entity-per-node" 和 entities: [{"entity_id": "...", "node_id": "..."}]。它不是 MissionPlan、Node inventory 或第二套 reservation；重启时需要重新提供当前 registry，已绑定实体的路由若变化或 registry 缺失，服务拒绝以旧绑定继续启动。没有此约束的 v0.7 Mission 仍可照常使用。

Control HTTP 不绕过 Control 修改 reservation；独立 Artifact HTTP 只写不可变 CAS bytes 和 Memory catalog/replica evidence，不驱动 Task/Group lifecycle。身份认证与传输安全不在当前切片 范围内。若 SQLite 中存在与事件末尾一致的版本化 controller checkpoint，Integration Server 会恢复 Control/State/Runtime projection；Spatial evidence 会在同一事务中 carry-forward 该 checkpoint。非终态 execution 恢复为 Unknown 并等待 Reconciliation，不会直接判定 Mission 失败；live relation 同样保守重算并保留 coordination fence。缺少 checkpoint、schema 不支持、 relation registry 与 MissionPlan 不一致或序号不一致时 fail-closed。

当前 composition root 是单 writer：进程启动时会持有 controller SQLite 同目录下的 <database>.writer.lock，第二个指向同一数据库的 Integration Server 会立即启动失败，避免 形成两个不同步的 Catalog projection。这是单机一致性护栏，不是 Leader Election 或 HA。

节点侧复制并修改 config/node.toml 后启动常驻 Node Service：

cargo run -p roboguide-node -- config/node.toml

server_endpoint 是节点主动连接的可达地址，例如 http://192.168.1.10:50051。每台节点机器只运行一个 roboguide-node；配置可聚合多个 Local EAIOS/runtime，并用固定的 HTTP、dynamic gRPC 或 MCP workflow 描述能力、资源、 状态与取消。新增 Local EAIOS 只修改本地配置，不修改或重新编译 RoboGuide。

配置启动时整体校验并冻结。执行前写入 SQLite WAL journal；进程重启后无法确认是否已 触发的物理动作进入 ReconciliationRequired，绝不自动重放。Node 本地资源锁不取代 Control reservation authority。

当前开放问题

V2 仍保留七类架构问题：State Authority、Spatial Authority、Control Topology、Execution Group Authority、Scheduling vs Runtime Coordination、Temporal Assurance、Resource Commitment Semantics。它们记录在 docs/implementation-backlog.md；MVP 具体场景、拓扑和验收指标的草案记录在 docs/mvp-definition.md。

仓库内容

.
├── AGENTS.md
├── README.md
├── Cargo.toml
├── rust-toolchain.toml
├── pyproject.toml
├── config/
│   ├── mission.toml
│   ├── mission-service.toml
│   └── node.toml
├── contracts/
│   ├── capability/v0.1/ ... v0.3/
│   ├── mission/v0.2/ ... v0.7/
│   ├── mission/request-v0.1/ ... request-v0.4/
│   ├── mission/grounding-context-v0.1/
│   ├── mission/inventory-v0.1/
│   ├── node/v0.2/ ... v0.9/
│   ├── state/v0.1/
│   ├── memory/v0.1/
│   ├── spatial/v0.1/
│   └── spatial/localization-evidence-v0.1/
├── evaluation/
│   ├── specs/e1/           # 实验定义（E1 Mobility Smoke 等）
│   ├── src/roboguide_eval/ # Eval Harness：进程编排 + 可复现结果基础设施
│   └── tests/
├── mission/
│   ├── src/mission/
│   ├── prompts/v0/
│   └── tests/
├── scenarios/
│   ├── phase1-mission-v0.2/ + v0.3/
│   ├── extension-conformance-v0.1/
│   ├── execution-relations-v0.1/
│   └── distributed-spatial-memory-v0.1/
├── tools/
│   └── quality/
├── core/
│   ├── domain/              # core values + allocation/state/memory domain modules
│   ├── ports/               # transport-neutral core ports
│   ├── state/               # node/allocation/source-aware state/memory projections
│   ├── control/             # node/match/proposal/coordination/group/scheduler/recovery/allocation
│   ├── runtime/
│   ├── artifact-store/      # filesystem ArtifactBlobStore implementation
│   ├── integration/         # formal gRPC Node Protocol v0.4 wire/session/router
│   ├── orchestration/       # Controller Mission orchestration + IntegrationRuntimeBridge composition
│   ├── node-service/        # single service + declarative Local Integration Engine
│   └── testkit/
├── integrations/
│   ├── robonix-map-service/ # Robonix-specific Local EAIOS adapter, outside the core authority
│   └── habitat-local-eaios/ # C1-S0 real Habitat/EMOS local execution bridge
├── apps/
│   ├── controller/
│   ├── integration-server/
│   ├── mission-service/
│   ├── roboguide-node/
│   └── real-node-smoke/
├── console/               # Mission Console：只读任务旅程可视化（零依赖静态）
└── docs/
    ├── README.md
    ├── architecture/
    │   ├── README.md
    │   ├── v2/
    │   │   ├── README.md
    │   │   └── RoboGuide_Architecture_Baseline_V2.docx
    │   └── v1.1/
    │       ├── README.md
    │       └── Distributed_Embodied_AI_OS_总体架构详细设计说明书_V1.1.docx
    ├── project-goals-and-mvp.md
    ├── mvp-definition.md
    ├── implementation-backlog.md
    ├── development/
    │   ├── README.md
    │   └── coding-standards.md
    ├── decisions/
    │   ├── 0001-rust-core-python-edges.md
    │   ├── 0002-deaios-node-contract.md
    │   ├── 0003-mission-plan-contract.md
    │   ├── 0004-recovery-commitment-lifecycle.md
    │   ├── 0005-allocation-state-projection-authority.md
    │   ├── 0006-heterogeneous-eaios-integration-contract.md
    │   ├── 0007-mission-actor-continuity.md
    │   ├── 0008-integration-server-node-connector.md
    │   ├── 0009-node-service-grpc-protocol.md
    │   ├── 0010-single-node-service-local-integration-engine.md
    │   ├── 0011-event-evidence-codec.md
    │   ├── 0012-controller-checkpoint-recovery.md
    │   ├── 0013-mission-level-execution-group.md
    │   ├── 0014-phase1-mission-orchestration.md
    │   ├── 0015-runtime-execution-boundary.md
    │   ├── 0016-distributed-spatial-memory.md
    │   ├── 0017-canonical-capability-contract-identity.md
    │   ├── 0018-mission-intent-loop.md
    │   ├── 0019-capability-readiness-and-localization-evidence.md
    │   ├── 0020-execution-coordination-relations.md
    │   ├── 0021-device-extension-boundary-conformance.md
    │   ├── 0022-retire-legacy-adapters-and-isolate-artifact-store.md
    │   ├── 0023-application-accepted-node-protocol-facts.md
    │   └── 0024-federated-state-and-selective-memory.md
    ├── extensions/
    │   ├── device-extension-conformance-v0.1.md
    │   └── device-extension-conformance-v0.2.md
    ├── images/
    │   ├── README.md
    │   ├── roboguide-v2-overall-architecture.png
    │   └── distributed-embodied-ai-os-architecture-v1.1.png
└── website/               # MkDocs Material 技术文档站（Cloudflare Pages 部署）

技术文档站点由 website/ 提供：MkDocs Material 构建，部署于 Cloudflare Workers 静态资产（免费，静态请求量不限）。website/sync_docs.py 在构建时把仓库文档镜像到站点 （ADR 自动索引、内链重写、未镜像仓库路径回退到 GitHub），通过 Cloudflare Workers Builds Git 集成部署，每次推送 main 自动更新；本地预览命令见 AGENTS.md。

当前 V2 架构是有效基线；开发基线正在通过多个最小工程切片验证。Shared Node State、 Allocation State v0.1、source-aware State federation、selective Memory catalog、Node terminal execution 到 Group lifecycle 推进、SQLite evidence envelope 和 controller projection checkpoint restore 已实现，但完整 State & Memory Plane（Belief/fusion、Task/Group 历史 projection、跨 Controller 复制）和 MVP Definition 均未完成； 完整 MVP 的测试、适配器和仿真环境尚未完成。

双机器狗 Spatial Memory 的 Phase 1 真机验收定义现处于 In Review，见 scenarios/distributed-spatial-memory-v0.1/acceptance.md。 它要求 per-capability readiness 与强 localization evidence，不把旧的 process health 或 has_map=true 当作稳定成功证据。

Habitat shared-world 的可选物理诊断 v0.5 记录原始 Oracle 实际选中的导航点、 一次原始寻路调用的成败，以及通过 Habitat 语义区域包含关系可唯一确定的机器人和目标楼层；缺失或歧义明确标为 unavailable。它不重新寻路、不改变运动或官方 PDDL 成绩。旧 v0.4 终态证据仍可用于 独立的 B1 三维与 X/Z 反事实诊断。

Mission Intelligence 开发

Mission 配置位于 config/mission.toml，版本化 Prompt 位于 mission/prompts/。模型名、Provider、Prompt 版本、Responses 路径、推理强度、review 模型和存储策略均由配置提供；API Key 只从 OPENAI_API_KEY 读取。默认配置使用 gpt-5.6-luna，但远程明文 HTTP 会被安全 边界拒绝，生产与持续联调应使用 HTTPS 或 localhost 隧道。

外部文本入口由 apps/mission-service/ 提供，部署配置位于 config/mission-service.toml。默认 127.0.0.1:8070； Controller 继续在 127.0.0.1:8080 接受内部完整 MissionPlan，并提供只读 inventory 与 State federation；Artifact HTTP 默认在 127.0.0.1:8090 提供 Memory catalog。Mission Service 仅从 后两者构建受限 Mission Grounding snapshot，不把 live inventory 用于语义 admission。

uv sync --dev
uv run mission-service

curl --fail-with-body -X POST http://127.0.0.1:8070/v1/mission-requests \
  -H 'Content-Type: application/json' \
  -d '{"instruction":"让一只可建图的机器狗建立指定区域地图"}'

uv run mission validate \
  --input scenarios/mvp-slice-v0.1/mission-plan.json
uv run pytest -q

Eval Harness（实验驱动开发）

仓库进入实验驱动阶段后，evaluation/ 提供独立的 Eval Harness： 它不属于 Core、Runtime、Control Plane、State & Memory Plane 或 Local EAIOS， 不修改 Proposal / Commit / Binding / Runtime 语义，也不 import 或复制 EMOS/Habitat-MAS；外部系统只通过进程边界访问。第一版提供 ExperimentSpec 合同、 进程编排（超时/终止/日志持久化）、canonical metric schema、RunManifest 可复现 身份和 roboguide-eval CLI（doctor / run / summarize），并以 evaluation/specs/e1/mobility-smoke.yaml （E1 Habitat-MAS Mobility，EMOS vs RoboGuide）作为第一条 workload。机器相关的 Conda 环境、工作目录与凭据只来自 Git 忽略的 evaluation/local.yaml 或 ROBOGUIDE_EVAL_* 环境变量；真实 results 不提交 Git。详见 evaluation/README.md。

Mission Console（任务旅程可视化）

状态：开发中（experimental） —— 布局、功能与事件映射仍在快速演进， 尚未冻结；欢迎试用并反馈，但不要将其语义当作稳定契约。

console/ 提供只读的 Mission Journey 控制台：动态展示一个任务被 接受后，事件证据流经 Mission Intelligence → Control Plane → Execution Group → Runtime → Nodes 各层的真实效果（Match → Schedule → Propose → Commit → Bind → Execute 决策链、Observe → Update 观测链、Detect → Reconcile → Adapt 恢复链）。 支持多 Mission 并发与整机集群视图。它是零依赖静态前端，只消费既有 HTTP API， 不是新的架构权威：

python3 console/serve.py   # http://127.0.0.1:8095（默认演示回放模式）

「实时系统」模式连接真实 Integration Server/Controller：按 after 游标增量 轮询 /v1/events，刷新 /v1/inventory 节点卡，并可用 console/scenarios/ 中的版本化 MissionPlan 通过既有 POST /v1/missions 提交真实任务。细节见 console/README.md。