计划历史

📌 结论摘要

本文件按时间倒序保存 AgentMeshOS 已完成阶段、关键现场修复、发布验收和残余风险。历史条目只作为审计和回溯依据，不得覆盖当前计划、当前生产配置或当前权威连接登记。

截至 2026-10-06，P10 至 P16 已完成归档；当前阶段为 P17“代理网络控制面统一入口与真实客户端验收”，状态为进行中。P16 已完成 102 只读备用控制面、认证会话连续性、Edge 本地回退、101 单观察者安全路径和 RR 整机重启恢复演练，不开放双活写入。P17 只承接代理控制面、节点面板、Console 架构页和三端客户端验收，不自动继承历史残余项。

⚠️ 未决项 / 需要决策

项目	当前事实	下一步
真实微信往返	ClawBot 已绑定且模型链路可用，但 last_received_at 与 last_sent_at 仍为空	由用户从微信发送一次真实消息并确认回复后关闭
RR 稳定性	RR 已发生真实整机 panic 并恢复，四个冷启动根因已修复；24 小时稳态观察仍待继续	保留本次现场证据并继续观察内存、Swap、OOM 和失败单元
RR → 101 Tailnet	当前仍走 DERP(agentmeshos-mm)，360T7 Full Cone 已启用	继续排查运营商 NAT 和物理链路，直连恢复后以拓扑 healthy 关闭
Console 后端冗余	P16 已完成 102 只读备用、认证快照、Edge 回退和 RR 重启演练	已归档；后续漂移按新运维事件处理
Exit Node 能力基线	P16-0A 已完成：五台可选、默认不使用、Headscale 已批准且重启保持	保持能力，不自动切换默认出口

🧾 2026-10-12：P17 五节点 Reality、订阅刷新与 360T7 Xray 主备切换

• 验收边界：本轮只修改狗、DD、RR 的 2S-UI Inbound、Master agentmeshos-main 关联和 subClashExt、Home/OfficeSummer 订阅，以及 360T7 PassWall/Xray 主备节点；保留旧 Hysteria2、SS2022、Trojan、360T7 Balance、5 个 sslocal 和 HAProxy 作为可回退路径。
• 五节点主协议：五台节点均新增或保留 VLESS + REALITY、24443/tcp。dog、DD、RR 写前 fresh 数据库快照位于 /root/.codex/backups/proxy-network-2s-ui/p17-7-<node>-20261012T014520Z.db，权限 0600 root:root、大小 114688。
• 单节点验收：五台 Reality 均通过隔离 Mihomo v1.19.32 的 10/10 请求、ICMP 0% 丢包和 1 MiB 吞吐测试；p50 延迟分别约 0.7506s、0.7641s、0.8347s、0.9969s、1.0012s。
• 订阅发布：修改前 subClashExt 快照为 /root/.codex/backups/proxy-network-2s-ui/p17-8-subclash-before-20261012T015837Z.yaml，SHA-256 为 41c6c9a6092141127faf4a003e326ba1d7159a139a74ae4863fe8fc2e8977880。Master 关联已收敛为 [2,3,8,10,9]，公网订阅 Proxy / Auto 顺序为 MM -> d02 -> dog -> DD -> RR。
• 在线客户端：Home 与 OfficeSummer 已刷新 Clash Verge Rev profile 并回读五台 Reality，代理探测均返回 204；Summer、S20、Magic2 当前离线，未伪报为已刷新。Mihomo fallback 实测不保证健康备用恢复后自动回到 MM，因此严格回切只承诺在 360T7 Xray 主备路径成立。
• 订阅路由修正：subClashExt 改为 DOMAIN-SUFFIX,agentrouter.org,Proxy、DOMAIN-SUFFIX,vidhub2.top,DIRECT、GEOIP,LAN,DIRECT、GEOIP,Ads,REJECT、GEOIP,CN,DIRECT、MATCH,Proxy。公网订阅与 Home/OfficeSummer profile 已回读一致；Home 和 OfficeSummer 访问 agentrouter.org 均返回 HTTP 200，本地 Mihomo 日志命中 DomainSuffix(agentrouter.org) 并使用 MM Reality 出站。自定义域名区固定放在 GEOIP 前，后续可在 S-UI 原始 YAML 编辑器继续添加强制代理或强制直连规则。
• 360T7：切换前备份为 /root/passwall-backups/p17-9-20261012T021401Z/。新增 p17_dog_reality、p17_dd_reality、p17_rr_reality；建立 p17_main_balancer（仅 MM）和 p17_backup_balancer（d02、dog、DD、RR，leastPing）。
• 360T7 验收：五台节点均通过 PassWall url_test_node；隔离实例阻断 MM 后切到 RR 96.44.133.235，解除阻断后回切 MM。实际切换到 Global p17_main_balancer 后，101 对 api.github.com 出现 Send failure: Broken pipe，GitHub Actions run 38195889742 的 Set up job 因 SSL 下载失败退出；A/B 对照中旧 f9Re2U27 连续 10/10 返回 200。Global node 已回滚到 f9Re2U27，Xray 配置保留但未验收，整机重启恢复与稳定观察仍待完成。
• 防复发：仓库默认 topology 已改为五台 Reality 和 panel-* 拨号，契约测试 proxy_master_deploy_contract=pass；360T7 旧路径保留，只有重启恢复观察通过后才允许进入 P17-10 清理和 conntrack 调整。

🧾 2026-10-11：代理控制面 DNS 从 MM 单点改为 Edge 逻辑入口

• 验收边界：本次只处理代理控制面与四个节点面板的公网入口单点，不改变五节点数据面协议、主备顺序、客户端订阅语义和旧 ss-rust/360T7 链路。
• 症状与现场：proxy、mm-proxy 和四个 panel-* 原先均为固定 A 记录并指向旧 MM 公网地址；MM 公网 IPv4/IPv6 更新后，这些记录仍指向失效地址，导致 Master、订阅和四个节点面板全部不可用，而 edge.yohan.fun 已正常切到 d02。
• 根因：P15 只轮换 edge A/AAAA，P17 的 proxy/panel-* 记录由另一套脚本固定绑定 MM，两套系统没有联动，因此 MM 故障不会触发控制面入口切换。
• 修复：d02、dd、dog-public 三台健康 Edge 使用 DNS-01 签发覆盖 proxy 与四个 panel-* 的 ECC 证书，并部署统一网关；proxy 回源 RR 2095/2096，面板经 RR 39200 回源节点 2095。AliDNS 将五条入口记录改为 CNAME edge.yohan.fun，TTL 600，旧 A 记录完整备份到 /var/backups/agentmeshos/proxy-control-dns/20261011T053150Z.json。
• 防复发：Edge DNS 控制器新增 proxy.yohan.fun/__edge/control-health 双视角检查，只有公网 Edge、控制面网关和面板网关同时健康才允许作为候选；agentmeshos-proxy-network-dns.py 改为数据面 A 记录与控制面 CNAME 分离管理，并提供带备份的 cutover-control/rollback-control。
• 验收：AliDNS 权威、223.5.5.5 和 1.1.1.1 均返回 CNAME edge.yohan.fun；proxy 登录页、Clash 订阅和四个面板从 101 与 RR 回读均正常；d02、dd、dog-public 三个活动候选分别验证证书、Master 和面板路径通过。
• MM 地址收敛：用户更新 MM 公网地址后，AliDNS 只保留 mm A/AAAA 作为唯一地址源；edge-mm、derp-mm 和 mm-proxy 均改为 CNAME mm.yohan.fun，控制器幂等回读 changes_required=0。新 MM 通过 mesh + proxy control-health 双视角后，活动 edge 自动回切到 MM，并补齐 AAAA。
• 重复地址收敛：edge-d02/edge-dd/edge-dog 改为 CNAME 到 d02/dd/dog 节点身份，dog-proxy -> dog、cloud-origin -> dd；后续节点换 IP 只需更新节点身份 A/AAAA，不再逐条维护边缘和代理别名。
• 节点管理嵌入修复：Console 节点页 iframe 失败根因是 status.yohan.fun 返回 X-Frame-Options: SAMEORIGIN。四台 Edge 的 status vhost 已改为 Content-Security-Policy: frame-ancestors https://console.yohan.fun，其他站点仍保持 SAMEORIGIN。

🧾 2026-10-09：101 资源遥测阶段性不可达修复

• 验收边界：本次只修复 101 资源遥测从 RR 采集时的瞬时超时误报及 Linux exporter 暴露面，不修改 Home、路由器、SSH、iKuai、Tailnet 或节点业务配置，也不改变 P17 当前阶段状态。
• 症状与现场：101 的 agentmeshos-node-metrics 容器持续运行，RestartCount=0、未 OOM；101 本机 12/12 次抓取均为 HTTP 200，单轮约 28-67ms。RR 经 Tailnet 抓取 101 常规约 0.93-1.03s，链路为 direct、tailscale ping 约 185-200ms，但实测出现 2.124s 和 3.323s 尾部延迟。
• 直接原因：旧 Gateway 对 /metrics 只执行一次 urllib.request.urlopen(..., timeout=7.5)，任何超时或其他异常都直接投影为 resource_status=unreachable 和“节点在线，但 node_exporter 当前不可达”，没有区分瞬时路径抖动与持续性 exporter 故障。
• 根因修复：API Gateway v2.3.0 改为总预算 7.5s 内的有界重试，默认最多 2 次、间隔 0.25s；第一次失败后仍可从剩余预算完成第二次读取，只有全部尝试失败才返回不可达。日志新增 node_metrics_attempt_failed 与 node_metrics_unreachable，只记录脱敏目标 ID、尝试次数、超时预算、耗时和异常类型。
• 采集面收敛：Linux node metrics v0.4.0 使用 --collector.disable-defaults，只启用 cpu filesystem meminfo netdev os stat uname，并增加 exporter 根路径容器健康检查。生产回读发现 node_exporter v1.9.1 的 /-/healthy 返回 404，健康判据已改为实际存在的 /，契约测试同步禁止再使用错误端点。对照实验中默认约 108 KiB 的指标体降为约 47 KiB，RR 常态抓取由约 1.0s 降至约 0.75s；CPU、内存、Swap、文件系统、网络、运行时间和系统身份字段仍保留。
• 防复发与负向回归：新增“首次超时、第二次成功”和“两次均失败才不可达”单元测试，以及部署脚本 collector 白名单和健康检查契约；生产验收还需覆盖 101 本机抓取、RR 连续采样、/public/status 持续 available、Gateway 无 node_metrics_unreachable 和至少 10 分钟观察，不能用单次成功替代。
• 回退点：API Gateway 保留上一镜像 rollback，节点遥测脚本在覆盖前保留上一 exporter 镜像 rollback；回退只影响遥测，不触碰节点网络、路由器、SSH 或业务数据。
• 发布边界：只有本轮代码、测试和文档显式提交并推送，API Gateway 经固定 SHA 镜像发布到 RR，101 节点遥测完成本机部署回读，且 post_push_verify=pass 后，才可以把本事件报告为发布完成。

🧾 2026-10-06（补记）：Magic2 ADB bridge 恢复与 Home WSL 黑框修复

• 验收边界：本次只收口 Magic2 网络速率遥测、Home 侧 ADB bridge 和每分钟 wsl.exe 黑框，不改变 P17 阶段状态，不修改 Headscale 全局偏好、路由器、Exit Node 默认值或其他计划任务。
• Magic2 恢复：Home USB ADB 已回读 6LR0219322000259 为 device product:TNY-AL10 model:TNY-AL00 device:HWTNY；Termux 用户 u0_a199 的 100.64.0.13:8022、sshd supervisor 和探针 push-loop 均恢复，探针升级为仓库 v0.4.0。现场 bridge 输出包含 receive_bytes_per_second=2041.1、transmit_bytes_per_second=3290.24、interfaces=["wlan0","rmnet0","rmnet_ims00"]，公网 Status 返回 status=online、resource_status=available。
• 黑框根因：旧计划任务 AgentMeshOS-Android-ADB-Network-Bridge 使用 InteractiveToken 每分钟启动控制台程序 C:\Windows\System32\wsl.exe，脚本退出时 Windows 关闭交互式控制台窗口；闪烁来自任务执行模型，不是任务退出码。
• 黑框修复：任务改为 S4U 非交互会话和 Highest 运行级别，动作只调用 powershell.exe -NoLogo -NoProfile -NonInteractive -ExecutionPolicy Bypass -File ...，执行 Windows 原生 agentmeshos-windows-android-adb-network-bridge.ps1，不再经过 WSL。现场 LastTaskResult=0，旧任务 XML 备份为 C:\ProgramData\AgentMeshOS\backups\AgentMeshOS-Android-ADB-Network-Bridge.20261006T134713.xml，SHA-256 为 C8C65F0280A449C0EA3E338E1670412D1DED0864D3DAD121F0538D9092C0D2B5。
• 防复发与负向回归：新增 scripts/clients/agentmeshos-windows-android-adb-network-bridge.ps1、契约测试和 run-local-tests.sh 入口；脚本明确过滤 tun* 等 VPN 接口并压缩输出为单行 JSON。修复后连续 6 分钟采样 12 个周期，任务持续成功、设备 bridge 文件持续刷新、wsl.exe 进程采样始终为 0。
• IPv4/UDP：S20 从 101 走直连 192.168.50.195:53709；Magic2 仍从 101 观察到 via DERP(agentmeshos-mm)，说明 Android 端 UDP/STUN 直连尚未建立，不是 Peer Relay 优先级代码错误。Android Tailscale 没有普通 UDP 开关；本轮未强制 IPv4、未关闭 IPv6，也未修改 APN、路由器、Headscale 或 Exit Node 配置。

🧾 2026-10-06：Android 网络遥测 ADB 桥接恢复

• 验收边界：本次只修复 S20、Magic2 的网络速率遥测和 IPv4/UDP 现场判断，不改变 Tailscale/Headscale 全局偏好，不修改路由器、Exit Node 默认值或 P17 阶段状态。
• S20 根因与修复：Termux 读取 /proc/net/dev 和 /sys/class/net/wlan0/statistics/* 返回 Permission denied，ADB Shell 可读取同一计数器。新增 agentmeshos-android-adb-network-bridge.sh，在 101 上通过 ADB 两次采样写入 Termux 外部文件；agentmeshos-android-self-network-probe.sh v0.4.0 只接受不超过 300 秒的快照。2026-10-06 13:11 CST 现场 receive_bytes_per_second=922.0、transmit_bytes_per_second=5742.0、interfaces=["wlan0"]，RR API 与公网 Status 均返回 resource_status=available。
• S20 防复发：101 已安装 systemd timer，每 60 秒刷新 ADB bridge；文件过期时探针拒绝沿用旧速率，回到自身采集或明确显示缺失，不用静态零值伪造。scripts/clients/tests/test-android-adb-network-bridge.sh 覆盖物理接口过滤、计数器解析和速率计算，test-android-self-network-probe.sh 覆盖新鲜快照读取与过期快照拒绝。
• Magic2 现场：Tailscale 节点 100.64.0.13 在线但 CurAddr 为空，tailscale ping 为 via DERP(agentmeshos-mm)；100.64.0.13:8022 返回 Connection refused，RR 最新快照仍为 v0.3.8、resource_status=stale、网络速率为 null。
• Magic2 ADB 判定：Home 的 adb devices -l 为空，adb mdns services 未发现 Magic2，Windows USB PnP 也没有 Honor/Android/USB 设备；用户所说的物理连接未形成 ADB 会话，因此不能执行自动安装或 bridge。需要先让 Home 重新枚举设备并授权 USB 调试，再升级到 v0.4.0。
• IPv4/UDP：S20 当前为 IPv4 直连 192.168.50.195:53709，探针上报目标也是 100.64.0.1:39120；Magic2 当前走 DERP 是因为 UDP/STUN 路径未建立，不是 Peer Relay 优先级写错。Android Tailscale 没有普通 UDP 开关，恢复动作限定为重新连接、切换网络、关闭 Clash/VPN 叠加、检查省电与 NAT。
• 发布边界：仓库脚本、测试和文档必须显式暂存、提交并推送；只有 post_push_verify=pass 才可报告发布成功。Magic2 的真实恢复仍以 Home 出现 ADB 设备、快照版本升级且 RR/公网 Status 不再为 stale 为验收条件。

🧾 2026-10-05：Magic2 Exit Node、TermRover 与 Gemini 真机补记

• 验收边界：本次补齐用户在 Magic2 上手动设置 Exit Node 后的真机测试、TermRover 九主机验收和 Gemini 真实对话，不把 Android Clash Meta 切换、iOS 真机或 P17 阶段完成度一起写成通过。
• Exit Node：用户设置后，Android dumpsys connectivity 显示 VPN 网络 114 为默认网络，现场连接状态同时包含 WIFI|VPN；未再要求用户重复设置。真机在 VPN 路径下执行 ping -c 3 www.google.com，结果为 3/3 成功、平均约 176 ms，证明当前选择已作用于测试流量。
• Gemini 真机：Magic2 已发出真实消息 Hi，Gemini 返回 Hello! How can I help you today?。早期 AuthPII getToken() -> NETWORK_ERROR 和“OAuth 未闭环”只能作为历史故障，不能再作为当前状态。
• TermRover 九主机：sh.termrover.app 1.2.2 显示 9 saved，包含 101、102、d02、dd、dog-public、home、mm、nas-sz、rr。真实登录 101 返回 root@pcdell-101:~#，真实登录 rr 返回 root@rr:~#；101 截图放在 temp/magic2-termrover/magic2-termrover-101.png，SHA-256 为 031824bc60be9a193eb3c7d1fc89ef87c871d21cdf18a6dff897623acf3cc4ab。
• 新管理公钥：TermRover 生成 honor-magic2-termrover，指纹为 SHA256:j6X84hL6Pqvi75ODDXyKNMDlHUtZ53ODiqgqQEPoZRE，公钥为 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIKRFS1rngvYPvhs6LPBVwJkgtfQXT3QMlFmFaNBBVYt honor-magic2-termrover。该钥匙已写入九个在线目标的授权文件，只允许 Magic2 出站管理，不授予 Magic2 入站登录；每台目标的 authorized_keys 在写入前均保留带时间戳备份。
• Tailnet 字段澄清：TermRover 1.2.2 的高级设置确实存在 Tailnet 字段，但其现场说明是“留空时使用 API Key 自己的 tailnet，只在一把 Key 可列出多个网络时填写组织名”，保存仍要求官方 API Key。它是官方 Tailscale API Key 的组织范围字段，不是自托管 Headscale 控制面 URL 输入框；临时试验未保存，字段已恢复空白且九主机仍为 9 saved。
• 身份漂移校正：RR 的 headscale nodes list -o json 当前返回节点 ID 23、name=TNY-AL00、given_name=andriod-magic2。因此网络态势和当前文档统一把实时 Tailnet 节点名写为 andriod-magic2；Registry 稳定 ID 和 SSH 别名继续保留 honor-magic2，不再把二者混为同一字段。
• 进程驻留异常：本次直接测试时发现 Termux 进程已停止，100.64.0.13:8022 返回 Connection refused，而 Tailscale VPN 服务仍在前台运行。通过 Home USB ADB 启动 Termux，并执行 ~/.termux/boot/agentmeshos-android-sshd.sh 与 ~/.termux/boot/agentmeshos-android-probe.sh 后，sshd supervisor、探针 push-loop 和 8022 登录均恢复。该恢复证明 boot 脚本可用，但不能据此声明长期后台驻留已稳定；后续要按 Doze、内存回收与 logcat 继续观察。
• 发布边界：本节仍需随文档提交、GitHub Actions、101 Runner、RR 生产发布和公网回读一起收口；只有 post_push_verify=pass 才能把本轮文档更新报告为发布成功。

🧾 2026-10-05：Magic2 Android 移动管理与观测节点纳管

• 验收边界：本次把 Honor Magic2 接入为与 S20 同类的 Android 移动管理与观测节点，不把它登记为 Worker、Nomad 客户端、Edge 或批量任务节点，也不开始新的 P17 范围。
• 设备身份：型号 TNY-AL00（product TNY-AL10）、Android 10 / API 29、Headscale 节点 ID 23、记录时 given_name=honor-magic2、Tailnet 地址 100.64.0.13、Termux 用户 u0_a199。Headscale 的 name 字段是官方 Android 客户端注册时上报的设备码 TNY-AL00，不是这台机器的 Tailnet 节点名；后续已由真机补记更新为实时 given_name=andriod-magic2。
• 安装与恢复：Home 通过 USB ADB 完成 Termux 0.118.3、Termux:Boot 0.8.1、Tailscale、Termius 7.11.1 和探针 v0.3.8 的安装；整机重启并解锁后，Tailscale、Termux、sshd、supervisor 和 push-loop 均自动恢复，101、RR、Home 三来源重新登录成功。
• 入站边界：Magic2 只在 100.64.0.13:8022 提供 Tailnet-only SSH，authorized_keys 精确为 agentmeshos-rr-management、root@pcdell-101-to-rr、administrator@Home 三把公钥；密码、Root、公网、局域网、代理转发、端口转发、X11 和隧道均关闭。
• 遥测与分类：Registry 新增 honor-magic2，主职责 client、服务职责 android-probe 与 ssh-management、能力为空、已纳管且系统管理为真。RR 实际收到 v0.3.8 快照；分类为 degraded 的唯一原因是 Android 10 隐藏网络元数据，tailnet.connected=true，CPU、内存、Swap、磁盘和 Tailnet 延迟可用。
• 探针根因修复：v0.3.8 使用 Termux sh 绝对路径，避免 Android 10 因 shebang 解析差异中断；/proc/net/dev 不可读时安全返回空接口集合，不再让单个受限 procfs 文件终止整轮采集。
• 拓扑身份与离线展示：Gateway 和拓扑采集统一使用 Registry 的 display_alias、TNY-AL00 主机名和 honor-magic2 稳定 ID；Tailscale 离线节点不再从快照中消失，而是保留为 status=down 并明确返回 tailscale_peer_offline。
• 身份边界修复：生产回读发现匿名 Status 曾把 Magic2 合成为 node-15、Bridge 节点管理曾展示 Headscale 数字 ID 23，与拓扑稳定 ID honor-magic2 不一致。修复后公开 Status 和未纳管节点清单都从 Registry 解析稳定 ID，并同时返回 display_name、display_alias、host_name、tailnet_name 与 tailnet_dns_name；Headscale 数字 ID 只保留为内部关联。
• Google 环境：2026-10-05 从手机 Termux 实测 Google 端点全部可达（www.google.com/generate_204、play.googleapis.com、android.clients.google.com、dl.google.com、www.gstatic.com 均返回 204，耗时 0.7–1.2 秒），www.google.com 的 ICMP 100% 丢包只是该网络拦截 ICMP，不构成“连不上谷歌”的证据；GMS 26.34.65、Play 53.3.21-24、Chrome 154.0.8037.126、ChatGPT 1.2026.265、Gemini 1.0.971139365 均在 08:37–10:10 完成安装或更新。Gemini 在 Android 10 上会转交 Google app 的 Assistant 界面，真实对话仍需解锁屏幕后复验，早期记录的 AuthPII getToken() -> NETWORK_ERROR 已不能作为当前结论；后续真机补记已完成真实对话。
• 清理与边界：ADB 文本输入使用的临时输入法已恢复为 com.tencent.wetype/.plugin.hld.WxHldService；Termux 与 Termux:Boot 已加入 Doze 白名单。TermRover 1.2.2 的 PairIP 许可校验已通过 Play 官方安装解除，应用可冷启动；本条记录时九主机配置仍为空，后续真机补记已完成 9 saved、RR/101 登录和 Tailnet 字段澄清。
• 命名口径校正（2026-10-05 归档后修正）：网络态势的“Tailnet 节点名”原先取 Headscale 的 name，会把 Magic2 显示成设备码 TNY-AL00、把 S20 显示成 Little 的 S20+，与 Headplane 机器列表和节点管理展示的 given_name 不一致。生成器 enrich_tailnet_peer_names 已改为与节点清单导出相同的优先级 given_name → name，控制台同时去掉重复的“Tailnet DNS 名”行；机器码仍以“OS 主机名”保留，Headscale 改名后下一次快照自动生效。
• 发布边界：只有本轮 Registry、脚本、测试和文档显式提交并推送、Actions、101 Runner、RR 生产发布及公网回读全部成功后，才可以把本次纳管报告为发布完成；post_push_verify=pass 是最终判据。

🧾 2026-10-04：S20 Tailnet 入站 SSH 管理闭环

• 验收边界：本次只补齐并验收 RR/101/Home -> little-s20 的 Tailnet-only 入站 SSH，不把 Android Clash Meta 真机切换、iOS 真机验收或 P17 阶段完成度一起写成通过。
• 服务基线与授权：S20 当前登录用户为 u0_a355，sshd 只监听 100.64.0.8:8022。authorized_keys 精确收敛为 agentmeshos-rr-management、root@pcdell-101-to-rr 和 administrator@Home 三把公钥；RR、101、Home 均已完成真实登录回读。
• 负向边界：未授权钥匙和密码认证均返回 Permission denied (publickey)；局域网 192.168.50.195:8022 返回连接拒绝。服务同时关闭 Root 登录、代理转发、端口转发、X11 和隧道，不开放公网入口。
• 重启恢复：S20 于 2026-10-04 19:14 CST 执行受控重启，用户只解锁屏幕。sshd 由 Termux:Boot 自动恢复，约 204 秒后 100.64.0.8:8022 可连接，新 boot_id=5ff21b38-a32f-4a0a-b45d-9d96b8f32e10；RR、101、Home 随后均以 u0_a355 重新登录成功。
• VPN 接口重建根因：真机出现过一次“进程仍存在但 8022 拒绝连接”，日志为 accept: Invalid argument。Tailscale VPN 接口重建后旧 sshd 仍存活，但监听套接字已失效；这不是公钥或授权问题。
• 防复发：正式脚本 scripts/clients/agentmeshos-android-inbound-sshd.sh v0.2.0 提供 install/start/stop/restart/supervise/status/uninstall，每次安装先备份并移除额外公钥，再写入精确三钥集合；supervisor 检查 PID、日志错误计数和 socket 文件描述符，失效后自动重建 sshd，且 SIGTERM 会清理 PID 文件后退出。scripts/clients/tests/test-android-inbound-sshd.sh 覆盖权限、配置、幂等、额外钥匙移除、自动重启、supervisor 退出、停止和卸载。
• 修复回归：受控注入 accept: Invalid argument 后，旧 sshd PID 26483 在 8 秒内重启为新 PID 26881；修复后的生产 supervisor 持续存活。仓库脚本与 S20 实装版本的 SHA-256 同为 2ed9d30e087b1af4fe161687026877162f9950a3e0ab3ed4a85d6d5d19564281。三来源再次实测，101、RR、Home 均以 u0_a355 登录成功。
• 发布边界：只有本轮脚本与文档提交推送、Actions、101 Runner、RR 生产发布和公网回读全部成功后，才可以把本次入站管理闭环报告为发布完成；post_push_verify=pass 是最终判据。

🧾 2026-10-04：S20 重启自启验收完成

• 验收边界：本次只关闭 S20 的重启自动恢复欠项，不把 Android Clash Meta 真机切换、iOS 真机验收或 P17 阶段完成度一起写成通过。
• 受控重启：S20 于 2026-10-04 17:41:52 CST 执行第二次整机重启，17:42:49 Tailscale 进入离线。用户只完成屏幕解锁，没有手动打开 Tailscale。
• 自动恢复：Tailscale 于 18:17:50 自动上线，地址仍为 100.64.0.8，从 101 ping 成功；RR 资源遥测于 18:18:17 恢复为 available，CPU 核数为 8。RR 网络拓扑快照于 18:18:33 生成，little-s20 保持在线。
• 机制证据：系统级 always_on_vpn_app=com.tailscale.ipn、always_on_vpn_lockdown=0、Doze 白名单和 RUN_IN_BACKGROUND allow 均已生效；Termux:Boot 与探针 push-loop 随开机恢复。该配置不依赖 App 内临时开关或 ADB 常驻。
• 系统边界：Android 加密存储决定设备重启后仍需用户解锁一次；无线调试不是常驻服务，只在执行 ADB 操作时临时开启。上述两点均不被记为自启失败。
• 当前回读：2026-10-04 18:19 通过 https://api.yohan.fun/api/public/status 复核，little-s20 为 status=online、resource_status=available。
• 发布边界：本次关闭只在本轮文档提交推送、Actions、101 Runner、RR 生产发布和公网回读全部成功后生效；post_push_verify=pass 是最终判据。

🧾 2026-10-04：S20 Android 移动管理通道建立与探针恢复修复

• 计划边界：本次只建立 little-s20 的移动管理与探针恢复能力，不改变 P17 的代理 Master、节点面板和 Console 范围，也不把 Android/iOS 的 Clash 真机切换验收提前写成完成。
• 设备基线：S20 现场身份为 SM-G986U1、Android 13、Headscale 节点 ID 21、地址 100.64.0.8、DNS 名 andriod-s20、显示名 Little 的 S20+。设备保留 F-Droid Termux 0.118.3 与 Termux:Boot 0.8.1，并已卸载 Google Play 版 Termux；两者职责分别是 Shell/OpenSSH/探针宿主和开机启动，不可互相替代。
• 管理通道：S20 上的 Termux、Termius 和 TermRover 均已保存 rr、101、home、102、d02、mm、dd、dog-public、nas-sz 九个目标。Termux 的登录结果覆盖九个目标；Termius 已完成九主机逐项回读并实际登录 RR，返回 S20_TERMIUS_OK / rr / root / 100.64.0.1；TermRover 已保存九主机并实际登录 101，返回 pcdell-101 / root。三套管理公钥指纹分别为 SHA256:WIokvREOfeTluvNUrhXItIK4d73xs0uskzdnYvUB+38、SHA256:1BOo4SRE9qnitM5V3NQmJKO2ZpiSkJVg6qg0R8Yk/R4 和 SHA256:yBpFXxVEEH5y67GrCrzrT6BwD2kGVxoxmw55pbfrbik，只登记指纹，不记录私钥。
• 同级互联：101 -> RR/Home、RR -> 101/Home、Home -> RR/101 六方向均已通过显式 Tailnet 地址、用户和密钥完成主机名回读，证明 S20 是新增的移动管理发起端，不是新的控制面或入站 SSH 服务。
• 探针根因：Android 13 对普通应用隐藏 Wi-Fi/VPN 元数据，旧探针把元数据缺失错误映射为 offline，导致设备已能访问 Tailnet 时仍显示离线。修复采用“权威 Tailnet 目标或 MagicDNS 任一 ping 成功即确认可达”的在线判据，并把元数据不可读降级为 degraded；同时停止使用 Android Shell 的特殊变量 status，避免分类值被后续命令覆盖。
• 探针证据：脚本升级为 v0.3.7，Termux 实机运行得到 classification.status=degraded、原因仅 network_metadata_unavailable、tailnet.connected=true，100.64.0.1 与 MagicDNS 均 ping 成功；CPU、内存、Swap 和磁盘遥测已进入 RR 快照。聚焦回归 sh scripts/clients/tests/test-android-self-network-probe.sh 返回 android self network probe contract: PASS。
• 清理恢复：测试期间临时修改的输入法已恢复为 com.tencent.wetype/.plugin.hld.WxHldService；package_verifier_enable、package_verifier_user_consent 和 verifier_verify_adb_installs 已恢复原值；手机 staging 目录与本地临时探针 Token 均已删除。Termius 不得执行 pm clear，否则会删除 Keychain 和主机配置。
• 重启边界：S20 于 2026-10-04 15:58:46 CST 触发整机重启。重启后截至 16:09，Headscale/Tailscale 仍显示 S20 Online=false，100.64.0.8 ping 失败，adb devices 和 adb mdns services 均无设备，因此 Termux:Boot、push-loop、Tailscale 和三套 SSH 配置的恢复尚未通过。下一步必须先让设备解锁上线、重新开启无线调试，再确认 RR 新快照时间晚于重启时间且分类不回到 offline；在此之前不得把本次移动管理接入写成完整重启验收通过。
• 本地门禁：bash scripts/ci/run-local-tests.sh 已完成，Runtime 211 passed、Auth 18 passed，控制台、拓扑、Android 探针、计划、文档清单、发布 bundle 和严格 MkDocs 均通过；python3 scripts/ci/agentmeshos-plan-nav-check.py 返回 plan_nav_check=pass。
• 发布边界：只有完成 S20 重启恢复验收、显式暂存本任务文件、推送 GitHub、Actions、101 Runner、RR 生产发布和公网回读全部成功后，才可把本次移动管理接入报告为完整闭环；post_push_verify=pass 是最终判据。

🧾 2026-10-04：节点职责分类收口并校正移动客户端身份

• 计划边界：本次只收口节点分类、下游展示和发布链路，不启动 P17，也不重开 P16。docs/plans/state.json 仍为 P17“等待实施”，历史阶段状态不变。
• 权威模型：四轴固定为 primary_role、service_roles、capabilities、operational_state；唯一权威源为 tools/node-registry/registry.json。Console、Status、API Gateway、System Operations Bridge、拓扑生成器和发布 bundle 均从该源读取或映射，旧 role/node_type 只作兼容展示。
• 分类校正：little-s20 的现场 Tailnet 身份补齐为地址 100.64.0.8、DNS 名 andriod-s20、显示名 Little 的 S20+，主职责保持 client。旧 redmi-3s 继续留在历史别名表，但该地址已重新分配，不能再按旧设备解释。
• 现场核对：101 的 tailscale status --json 共返回 14 个节点身份；按 Registry 的 id、别名、地址、Tailnet 名和主机名交叉匹配后 unmatched=0。当前为 9 台在线、5 台离线，离线身份仍保留分类，不因离线降级为“待分类”。
• 身份索引修正：生产回读发现身份索引原先只读取 metrics.address，导致只有 topology.tailnet_ipv4 的管理终端被投影为 unclassified。API Gateway 现同时索引 metrics 地址、topology.tailnet_ipv4、Registry 别名和 topology.tailnet_aliases；Home、windows-summer、benson-nb、officesummer 均恢复为 management，并加入动态库存回归测试。
• 拓扑校验修正：网络态势曾因 102 携带 Registry 合法能力 batch-worker、auto-deploy，而 API Gateway 能力白名单只覆盖网络中继能力，整份快照被误判为 snapshot_nodes_invalid。校验白名单已与四轴能力集合对齐，并加入“Registry 能力集合必须被 API 校验器覆盖”的一致性门禁。
• 下游收口：网络态势筛选拆为“链路类型、主职责、能力 / 出口”三组 AND 条件；节点详情显示四轴。Status 展示主职责、服务职责和能力统计。Bridge 与 API Gateway 对动态库存目标也通过 Registry 映射，不再回退旧动态角色文字。
• 匿名 API 边界：生产回读发现 /api/public/status 被 API 主机的 location / 管理员门禁重定向到登录页。私有回源升级为 v0.6.5，为该路径增加精确匿名代理，并把上述场景加入 main-origin-gateway-test.sh 防复发门禁。
• 防复发：derp、peer_relay、exit_node 被限制为能力名；服务职责必须使用 derper、peer-relay 等正式服务名。API 对非法主职责、非法服务职责和把能力冒充职责的快照返回 snapshot_nodes_invalid，对应负向回归已覆盖。
• 本地门禁：node_registry=passed、network_topology_canary=passed、gateway_network_topology=passed、public_status_boundary=passed、Bridge 21 passed、Status 展示契约、Console 静态与浏览器契约、发布 bundle 契约均通过；plan_nav_check=pass、document_inventory=pass。
• 发布边界：只有显式暂存本任务与既有 P16 发布链路文件，推送到 GitHub、Actions、101 Runner、RR 生产发布和公网回读全部完成后，才可以把本轮报告为发布成功；post_push_verify=pass 是最终判据。

🧾 2026-10-04：P17 控制面生产回读与 Windows 真机验收完成

• Console 生产：RR 上 agentmeshos-console-site 运行镜像为 ghcr.io/agentmeshos/agentmeshos-console-site:sha-d7230777c1c9feb3b5b9745231a18f1472e2cdb6，状态 running/healthy。生产容器内 app.js SHA-256 为 e6a1d419590cf9585eea6dffc223d85fd2da74cdcf775a6d91a52843f7f7c696，styles.css 为 342fb759fcdef68510861dfa8a5befaef359a76d960e5de261810353f7108926，与仓库文件一致；#proxyNetwork、四个 panel-* 链接均在生产文件中回读。
• Windows 真机：Clash Verge Rev v2.5.7 与内置 Mihomo v1.19.32 通过同一 Clash 订阅完成 12 步验收。基线为 MM，逐台阻断后依次切换 d02、dog、dd、rr，逐台恢复后全部回切 MM，all_pass=true。节点侧使用临时来源阻断而非关闭整节点端口，测试结束后阻断规则和 Windows 测试防火墙规则均已清理。
• 证据边界：原始 JSON 和测试脚本保留在项目 temp/p17-client-acceptance/，不进入 Git；正式文档只记录脱敏后的顺序、状态、版本、哈希和回退事实，不记录客户端源 IP、订阅地址、凭据或节点密码。
• 剩余门禁：Android 设备 Little 的 S20+ Tailnet 在线且 ping 正常，但当前没有 SSH、ADB、无线调试或 USB 管理通道；iOS 当前没有在线真机。两端仍标记为“未执行真机验收”，P17 保持进行中，不以资料归档或 Linux Mihomo 测试代替。
• 发布边界：本节记录 P17 分支提交 d723077 的生产镜像回读；最终以合并到 main 的精确 SHA、必需 GitHub Actions 全部成功和 post_push_verify=pass 为发布成功判据。

🧾 2026-10-04：P17 代理网络控制面统一入口与客户端验收启动

• 计划 ID：phase-17-proxy-control-plane-client-acceptance。用户批准完整实施计划后，P17 从需求评审占位进入“进行中”，当前工作包为 P17-0 基线与执行契约冻结。
• 冻结范围：Master 与订阅继续使用 proxy.yohan.fun；MM、d02、dog、dd 使用 panel-*.yohan.fun 独立面板和独立证书；RR 私有网关按 Host 转发到节点 Tailnet；Console“系统入口 → 代理控制面”先打开 #proxyNetwork 架构页。
• 数据面边界：五节点现有 REALITY、Hysteria2、SS2022 和 Trojan+TLS 均不重建，主备顺序保持 MM -> d02 -> dog -> dd -> rr；旧 ss-rust、360T7 和旧订阅继续在线，由用户自行决定回退周期。
• 客户端验收：Windows 使用 Clash Verge Rev、Android 使用 Clash Meta for Android、iOS 使用 Stash；三端均消费同一 Clash 订阅语义，真实验收必须覆盖顺序切换、回切和已有连接不迁移的边界。
• 发布边界：提交前执行差异脱敏检查；推送后只有精确 SHA 的必需 GitHub Actions 全部成功并返回 post_push_verify=pass，才允许报告发布成功。

🧾 2026-10-04：P16 完成归档，P17 进入需求评审占位

• 计划 ID：phase-17-requirement-review。P16 原地完成并归档，状态机切换为 P17“后续阶段待新增需求评审”；P17 暂不创建实现工作包。
• 状态迁移：P16 由进行中转为“已完成并归档”，完成归档见 completed-phase-16-control-plane-backend-resilience.md。P16 原计划继续作为稳定追溯页；P17 当前详细页见 phase-17-placeholder.md。
• 控制面备用：102 的 Auth、Console、API Gateway 和备用回源网关已健康运行。Auth SQLite 通过一致性快照同步，RR 与 102 的 AUTH_SESSION_SECRET 哈希一致；密码、Key 和告警生命周期写请求返回 503 standby_readonly_write_rejected。
• 会话与拓扑：合法 standby 会话可读取 /__agentmeshos/session、Console 首页、app.js 和拓扑 API；生产拓扑快照在 Home → dog-public 场景正确回读 exit_node_in_use=true、exit_node_target_id=dog-public，102 显示别名为 102，节点名来自 Headscale 实时名称。
• Exit Node 归档后校正：用户已将 Home 的 Exit Node 恢复为 none。RR 新一轮权威快照（generated_at=1791054870，文件时间 2026-10-04 03:14:41 +08:00）回读 Home 为 exit_node_in_use=false、exit_node_target_id=null；102 别名仍为 102，dog-public 的主机名实时为 dog，Tailnet 控制面名仍为 dog-public。该校正不重开 P16，也不改变“全部节点默认直连”的边界。
• Edge 回退：MM、d02、DD、dog-public 的主 upstream 为 RR，102 为受控 backup；回退覆盖连接错误、超时和 HTTP 500/502/503/504，其他域名保持 fail closed。
• 观察者与 DNS：101 单观察者路径、当前活动 Edge、凭据缺失、非法候选、dry-run 和回滚验证均通过；RR 与 101 证据冲突时不写 DNS。
• RR 重启：RR 完成一次真实整机重启，Tailnet、Docker、Console、Auth、API Gateway、私有回源和关键生产容器恢复回读通过。损坏快照回归返回非零且未覆盖 last-known-good。
• 发布门禁：本地 Runtime、Auth、Gateway、Console、拓扑、DNS、standby、计划状态、文档清单和严格 MkDocs 构建全部通过；最终 post-push-verify 在提交推送后执行，只有返回 post_push_verify=pass 才报告 P16 发布成功。

🧾 2026-10-03：Home 经 MM Exit Node 的控制台登录故障修复

• 现象与复现：Home 短时选择 MM 为 Exit Node 后，访问 https://console.yohan.fun/#topology 报 ERR_CERT_COMMON_NAME_INVALID。Home 的 tailscale debug prefs 回读 ExitNodeID=6，公网 IPv4 出口经公网回显验证为 MM，证明 Exit Node 本身已生效。
• 根因：console.yohan.fun 同时发布当前权威 A 与 AAAA。IPv4 SNI 返回 CN=console.yohan.fun 和 302；IPv6 请求被 MM 上 derp-mm.yohan.fun 的默认 vhost 接管，返回 CN=derp-mm.yohan.fun 和 HTTP/2 404。MM 的 console 宝塔 vhost 缺少 listen [::]:80、listen [::]:443 ssl 和 listen [::]:443 quic，同类问题覆盖除 mesh 外的九个核心域名。
• 机制修复：scripts/maintenance/agentmeshos-mm-edge-ipv6-guard.sh 升为 v0.2.0，对 mesh/cloud/auth/console/docs/status/api/omni/nomad/ai 做全量幂等检查和修复。目标文件、IPv4 锚点或重复监听不符合要求时 fail closed；修改前逐文件备份，nginx -t 或 reload 失败自动回退。原 mesh 专用能力保留，不创建第二套 MM IPv6 修复逻辑。
• 防复发回归：mm-edge-ipv6-guard-test.sh 覆盖 console 仅 IPv4、omni 已有部分 QUIC、重复 IPv6 listener、目标站点缺失、--check 不改文件和重复 apply 幂等六类场景；scripts/ci/run-local-tests.sh 继续执行该回归。
• 生产验收：MM 应用后十个核心域名均通过 IPv6 SNI 返回自身域名证书；mesh/cloud/docs/status/ai 返回 200，auth/console/api/omni/nomad 返回 302。Home 再次设置 MM Exit Node 后，强制 IPv6 访问 console.yohan.fun 返回 302 登录跳转；finally 已恢复 Exit Node=空，默认直连策略不变。
• 回退点：每个被修改的 MM 宝塔 vhost 都保留同目录 .bak.agentmeshos-ipv6-<UTC时间>-<PID> 备份；回退时逐文件恢复并执行 nginx -t 与 reload。该修复不修改 DNS、证书、后端服务或业务端口。

🧾 2026-10-03：P15 完成归档，P16 控制面后端冗余启动

• 当前计划 ID：phase-16-control-plane-backend-resilience。P16 原地叠加在 P15 完成归档之后，不重写历史阶段，也不创建平行计划。
• 计划 ID：phase-15-multi-edge-tailnet-resilience。P15 已通过提交 712593163768cec7379de1d8674c8aad27012fa4 的完整发布门禁：Repository Guardrails、Console/Docs/Status/API Gateway 构建均为 success，四个 deploy-production / deploy job 全部 success，post-push-verify=pass。
• P15 生产回读：console.yohan.fun=302，mesh/docs/status/cloud.yohan.fun=200；RR 公网 SSH、Tailnet SSH、私有回源、last-known-good、Docker Tailnet drop-in、systemd 失败单元和容器健康均已完成现场复核。
• 状态迁移：P15 由进行中转为“已完成并归档”，完成归档见 completed-phase-15-multi-edge-tailnet-resilience.md。P16 成为唯一当前实施入口，计划见 phase-16-control-plane-backend-resilience.md。
• P16-0：确认 Edge、DERP、Peer Relay 只提高入口和中继冗余，不复制 RR 上的 Console、Auth、API Gateway 与 Runtime 后端；RR 后端故障时所有 Edge 仍回源 100.64.0.1:39200，因此登录和网络态势不可见是已知架构缺口，不应被描述为“冗余已足够”。
• P16 方案：选择 102 作为只读备用控制面，Auth SQLite 通过一致性快照单向复制并使用同一 AUTH_SESSION_SECRET，备用 Auth 拒绝密码、Key 和管理写操作；Console 与 API Gateway 只开放 topology、node inventory、alerts 和 bridge status 只读路径。
• P16 数据契约：备用页面和 API 必须返回 deployment_mode=standby_readonly、read_only=true、source=rr-last-known-good 和 snapshot_age_seconds；拓扑快照超过 5 分钟标记 stale，超过 30 分钟标记 unavailable。RPO 目标不超过 5 分钟，RTO 目标不超过 3 分钟。
• P16 边界：不在本阶段实现 Auth/Runtime 双活写入，不新增第二调度器，不让备用节点覆盖 RR 原始数据库；Edge 仅对连接失败和 502/503/504 回退，其他域名和证据冲突继续 fail closed。
• P16-0A：用户要求在控制面备用主线前，把 RR、MM、DD、d02、dog-public 全部宣告为 Tailnet Exit Node 候选，供后续客户端按需选择，但五台节点和默认客户端均不使用 Exit Node。101、102、Home、nas-sz 明确排除；能力只增加可选出口，不改变当前 DNS、默认路由、代理或业务流量。
• P16-0A 验收：五台节点 AdvertiseRoutes 均为 0.0.0.0/0,::/0，Headscale available_routes 与 approved_routes 均含双栈路由；101 回读五台为 ExitNodeOption=true、ExitNode=false、Online=true，101 自身无默认出口。五台 tailscaled 已逐台重启并再次回读通过；新增的基线与 Headscale 路由脚本包含正路径、非目标节点拒绝、路由未批准和单节点回退回归。
• P16-0A 网络态势扩展：采集与 Gateway 投影新增 exit_node_candidates 和 exit_node_in_use 汇总，节点继续保留权威的 exit_node_available 与 exit_node_in_use。控制台摘要显示“几个可选 / 几个正在使用”；每台 Exit Node 候选使用独立“出口”药丸和虚线环，正在使用出口的节点使用橙色外环与“经出口”标记。契约固定：节点具备出口能力不等于正在使用，全部节点默认直连，只有用户明确手动选择后才加载。
• P16-0A 实时身份与出口目标修正（2026-10-04）：RR 生成器以 Tailnet IPv4 为稳定锚点，并从 Headscale 实时读取 name 与 given_name，避免节点重命名后仍显示客户端缓存名称；102 固定映射为 102 显示别名。逐节点 Exit Node 探测改为读取 ExitNodeStatus 的目标 Tailnet IPv4，并映射为 exit_node_target_id，控制台详情显示“正在使用的出口节点”，节点标记包含 data-exit-node-target。使用状态缓存由 5 分钟收紧为 60 秒，探测过期且失败时显示未知，不把旧值伪装为直连。

🧾 2026-10-03：P15-0 至 P15-3 完成，DNS 控制器进入真实切换前验收

• 计划 ID：phase-15-multi-edge-tailnet-resilience。工作树原地更新，不创建平行计划；当前工作包推进为 P15-4 DNS 自动切换。
• P15-0：能力矩阵、节点登记、端口、资源与候选顺序冻结；MM、d02、DD、dog-public 均满足资源、磁盘和端口资格，RR 永久排除。P15-1：拓扑 display_alias、1200x720 画布、拖动边界、半宽线、多线分道、能力徽标和 peer_relay 筛选已通过聚焦回归。
• Peer Relay：MM、d02、DD、dog-public 均已设置 UDP 40000，RelayServerStaticEndpoints 为 unset；MM 现场 tailscale debug peer-relay-sessions 返回 1 条活动会话。Headscale policy 现场与仓库 SHA-256 均为 cb0773f5da974bf56d63583cf5a638434a3c01eb76249277eb58fcf77ee11b43，policy check 通过，grant 不含 src/dst=["*"]。
• DERP：region 900、901、902、903 已分别通过 tailscale debug derp 建立真实连接，Headscale 已下发四区；MM、DD、d02、dog-public 的官方 derper 和 Nginx WebSocket 回源配置均已生产验证。
• DERP 准入修复：d02、DD、dog-public 首版 Nginx 只代理 /derp，遗漏 derper -verify-client-url 的 /verify，现场产生 admission controller: 404 Not Found 和 RR d02 健康告警。三台 Edge 已补充 POST /verify 到 100.64.0.1:39200 的私有回源，部署脚本增加 /verify 真实探测门禁；修复后 RR Health=[]，四区 tailscale debug derp 均成功，拓扑恢复 33 healthy / 0 unknown。
• 拓扑线宽修复：此前看起来仍很粗的连线并不是 .375px 可见线失效，而是 18px 透明点击热区同时带有 topology-link--public_https、topology-link--down 等路径类，后面的颜色规则覆盖了 transparent，把点击热区实际画成了粗彩线。CSS 已把路径颜色限定到 .topology-link，浏览器契约新增热区 stroke=rgba(0,0,0,0) 负向回归；修复后普通线与热区分离，多路径仍保留独立分道。
• DNS 控制器执行锁：控制器改为自行持有 /run/agentmeshos-edge-dns-controller.lock，show/check/dry-run/switch/rollback/evaluate 使用同一非阻塞排他锁，避免 systemd timer 与手工操作并发写状态；状态新增 active_address，回退时同步恢复活动候选和地址。101 已安装同哈希版本，timer 恢复 enabled/active，最近多轮 evaluate failures=0。
• DNS timer 锁竞争防复发：单轮健康探测约 14 秒，旧 OnUnitActiveSec=30s 可能与手工操作争锁并让 timer 报 lock_busy。service 现使用 evaluate --defer-lock-busy，锁忙时输出 edge_dns=deferred reason=lock_busy 并成功让出本轮；timer 改为 OnUnitInactiveSec=30s。安装契约同时门禁两处配置，真实竞争回归确认自动评估退出码为 0、手工并发写仍被拒绝。
• P15 真实自动切流：2026-10-03 09:37:53 CST，MM 候选在 101 与 RR 双视角连续三次一致失败，控制器将活动候选从 edge-mm 自动切到 edge-d02；last_reason=automatic_after_consistent_failure、last_known_good=edge-mm。随后执行 rollback，权威 A 恢复 MM；路径故障注入、自动切换和回滚均已完成，但整机硬故障演练仍未执行。
• P15 域名耦合复核：mesh.yohan.fun 当前同时是核心公网 CNAME 和 region 900 DERP 域名，自动切换后会跟随 edge.yohan.fun 改变物理落点，可能使 region 900 与活动 Edge 重合。已将解耦列为 P15 剩余项，本轮未擅自变更现网 DERP 域名和证书。
• P15 DERP 域名解耦：新增 derp-mm.yohan.fun，权威 A/AAAA 只指向 MM；MM 使用 acme.sh 3.1.6 HTTP-01 webroot 签发单域名证书并安装续期任务，/__edge/health 与 /verify 回源通过。RR 的 Headscale DERP map 已将 region 900 改为新域名，headscale configtest、受控重启、101/RR tailscale debug derp 900 均通过；mesh.yohan.fun 不再决定 region 900 物理落点。
• Edge DNS 活动地址探测：第一次自动切换后，递归 DNS 仍缓存旧 MM，旧逻辑把新活动 d02 错误累计为 failures=1，存在级联切 DD 的风险。控制器现以状态中的 active_address 强制探测对应候选 IP，只有未知活动地址才直接探测该地址；edge-dns-controller-test.py 新增 stale-DNS 回归。第二次自动切换后下一轮评估为 failures=0。
• Edge：d02、DD、dog-public 的 Nginx -t 通过，443/39478/40000 已监听；Let's Encrypt 证书覆盖 10 个核心域名和本机 DERP 域名。以各自公网 IP 固定 SNI 回读时，mesh/auth/console/api/nomad 返回 302，cloud/docs/status/ai 返回 200，omni 返回 307。
• DNS：101 的 /root/.codex/credentials/aliyun-dns.env 已配置为 root-only 0600；首次新建 60 秒记录被 AliDNS 以 QuotaExceeded.TTL 拒绝，候选与活动切换统一改用 600 秒后先新增 11 条；后续新增 MM 专用 DERP 域名记录，当前 ensure-records 为 changes_required=0、existing_count=13，223.5.5.5 与 1.1.1.1 回读一致。首次回读时没有修改活动 edge A/AAAA；后续真实切换、自动切换和回切已完成，并保留 last-known-good。
• DNS 控制器：已修复候选短名解析、候选 TLS SNI、RR 远程脚本 stdin、首次状态身份和状态已有候选时漏回读权威地址五个根因；show 回读活动候选为 edge-mm 并展示权威 A 记录，check 的 101/RR 双视角对四候选全部 healthy。控制器已以 30s systemd timer 在 101 运行，最新源码与安装版 SHA-256 一致。
• 网络态势：节点详情新增 edge_domain 与 derp_domain；普通连线从 .75px 再减半为 .375px，并为 CSS 增加构建内容哈希，防止生产继续缓存旧样式。生产 Console sha-e253297 已回读这两个域名行和 .375px 计算样式。
• 拓扑可见线续修：透明点击热区与可见路径彻底分层后，普通线先恢复到可读的 1.5px；现场复核仍偏细，最终统一为普通线 2px、选中线 3px、流动层 1px，并继续断言热区 stroke=rgba(0,0,0,0)。
• 候选 Edge 公网对等修复：生产快照中 dog-public 有公网 HTTPS 与公网 SSH，而 d02 没有到 GW/edge 的边。采集器新增真实的 d02 /__edge/health HTTPS 探测、公网 SSH 别名和 MM 专用 derp-mm 健康链路，浏览器契约固定候选 Edge 均含独立公网 HTTPS 与公网 SSH；www.threedogs.vip 业务链路继续保留，没有给 d02 伪造业务服务。
• P15 IPv6 切换收口：控制器新增 AAAA 删除、更新、补建和失败回滚路径；edge-dns-controller-test.py 覆盖 d02/DD 删除、回切 d02、稳定回切 MM 恢复 AAAA、A/AAAA 部分失败后双栈恢复和非法 IPv4/IPv6 拒绝。101 实装与仓库源码 SHA-256 均为 7f954523c9c966d4f30c326d9b9ce7e4a30f08f97eb4e4b191f469ebc57fd5bb；真实 MM → d02 切换后 active_ipv6_address=null，公共递归第 29 轮退净旧 AAAA，此时 IPv4 客户端实际落到 d02，严格 IPv6 请求不再命中 MM；回滚后 A/AAAA 恢复 MM。仍缺整机硬故障验收，600 秒 DNS 换切窗口作为当前产品边界保留。
• 仓库门禁：新增或修正 DERP 域名 vhost、双视角一致健康判定、活动 Edge 运行时解析、Peer Relay 无静态端点配置、证书部署和 MM IPv6 防复发回归；P15 导航与文档状态已同步。真实 DNS 切流、自动切换和回切已经执行；RR/MM 整机硬故障演练仍需维护窗口，不能由路径注入或当前只读健康结果替代。
• MM/RR 整机硬故障：MM panic 后控制器在 101/RR 双视角连续失败时切到 d02 并成功回滚。RR panic 后公网 SSH 约 11:04:37 至 11:07:26 不可达，恢复后进一步确认完整控制台登录仍受 RR 后端单点影响；本次现场结果替代了此前“整机故障待维护窗口”的旧状态。
• RR 冷启动根因修复：Tailnet 恢复不再依赖需要 RR 自己回源的 mesh.yohan.fun，改为本机 Headscale；一次性 auth key 通过 0600 临时文件传入。私有回源配置增加 last-known-good 自动恢复，Docker 增加 Tailnet 就绪门禁，Console/Docs/Status 部署脚本改为优先使用本机清理脚本并在镜像已存在时跳过拉取。恢复脚本同时发布到文档站，供故障后受控取回。

🧾 2026-10-01：P13-C RR omni 全量退役，取消观察等待期

🧾 2026-10-03：P15 多边缘、Tailnet 中继与网络态势韧性整改开始

• 计划 ID：phase-15-multi-edge-tailnet-resilience。P14 已完成搜索 MCP 试点并归档，当前阶段原地叠加为 P15，不创建平行计划。
• 状态迁移：P14 当前阶段结束后转为“P14 已完成并归档”；P15 当前阶段成为唯一实施入口。P14 原计划保留为稳定追溯页。
• 范围：MM、d02、DD、dog-public 作为 Edge、DERP 和 Peer Relay 候选；RR 永远排除，仅保留 Headscale、Runtime 和控制面。
• 已冻结边界：DNS 只修改 edge A 记录和 60 秒 TTL；101 保存写凭据，RR 只做只读监督；三台新 Edge 全部通过资格与真实回源验收前不执行生产切流。
• 仓库实施：拓扑快照扩展 display_alias、capabilities、relay_region_id 和 peer_relay_port，新增 peer_relay 路径类型；DERP 区域扩展为 900 至 903；Headscale relay grant 由节点登记表精确生成；DNS 控制器支持 show/check/dry-run/switch/evaluate/rollback。
• 当时未闭环项：三台 Edge 尚未完成证书、生产部署与回源验收，DERP 901 至 903 尚未启用，真实 DNS 切换和 RR/MM 故障演练需要维护窗口。该段保留为 P15 启动时点事实；后续完成结果以上方 2026-10-03 最新历史条目为准。

🧾 2026-10-01：P14 搜索范围收敛为三工具并完成双通道对照

• 计划 ID：phase-14-placeholder。101 继续同时启用本地 local_search_registry 与 Omni omniroute_search_101；Omni 客户端 enabled_tools 最终只保留 omniroute_web_search、omniroute_web_fetch、omniroute_tool_search，omniroute_x_search 已移除。
• X 搜索处置：用户已在 Omni 官方控制台关闭需要充值且当前无费用的 xAI 模型；本次没有修改 OmniRoute 包、SQLite、Provider 记录或服务文件，也没有通过源码补丁绕过上游授权。
• 本地通道测试：禁用 Omni 后完成 5 项查询，全部成功且每项返回 3 条。第一条分别命中 https://openai.com/、https://docs.searxng.org/dev/search_api.html、https://www.postgresql.org/docs/release/17.0/、https://openai.com/devday/、https://tailscale.com/docs/install/linux；本地链路不产生外部 Provider 查询成本，但底层 SearXNG 仍会出现个别引擎 timeout/429。
• Omni 通道测试：禁用本地后使用 serper-search 完成同一组 5 项查询，全部成功且每项返回 3 条，首条与本地一致；单次约 1.6–2.0 秒，成本 0.001 USD/query，返回 provider、published_at、rank、retrieved_at、response_time_ms 等元数据。
• 当前独立复核：本地 search_web 与 Omni omniroute_web_search(provider=serper-search) 均返回 https://openai.com/；Omni 本次 response_time_ms=2756、search_cost_usd=0.001。该复核证明 API Key 权限调整和三工具裁剪后两条通道仍可用。
• 结论：保留“本地优先、本地失败或无有效结果后回退 Omni 显式 Provider”。不删除本地，不把全部流量固定到付费 Omni，也不新增第二层代理或自动 URL 切换器；日常相关性两者接近，Omni 的优势是结果元数据、时效字段和供应端稳定性，本地优势是零外部查询成本和自有链路。
• 回退点：移除 x_search 前的 /root/.codex/config.toml SHA-256 为 334c0c1186fd3a1025bb019dd3f622b3abbe331e2c3ca571964a9f13ba2743bd，修改后为 f5df1abf2e74eb7644389ff94f05bdc9024defc70dfa1b207b85d14c6a9423d0；备份为 /root/.codex/config.toml.bak.20261001T044251Z.remove-x-search。

🧾 2026-10-01：P14-1 搜索 MCP 双监听接入与四工具验收

• 计划 ID：phase-14-placeholder。用户锁定三项决定后，P14 从等待实施进入进行中：102 同时监听 Tailnet 100.64.0.4:39200 与 LAN 192.168.50.102:39200；101 默认使用 Tailnet URL，LAN 作为人工测试入口；Codex 客户端只暴露 omniroute_web_search、omniroute_web_fetch、omniroute_x_search、omniroute_tool_search。
• 宿主层改动：agentmeshos-omniroute-edge.sh 升为 v0.2.0，按 tailscale0 与 enp0s31f6 分别执行来源 guard，保留 LimitNOFILE=65536:65536、--connections-max=4096。OmniRoute 包、SQLite schema 和服务文件未修改。
• 101 配置：新建专用 Key agentmeshos-search-mcp-101-20261001（Key ID bb05f5ac-3458-495d-8fff-66d66de0b63e），凭据文件为 /root/.codex/credentials/omniroute-search-mcp-101.env（0600）；新增 omniroute_search_101 MCP，旧 omniroute_full_boundary 设为 disabled。
• 真实验证：本地 search_web 成功；Omni serper-search 返回 https://openai.com/；firecrawl 返回页面 Markdown；omniroute_tool_search("search") 返回 8 个工具；x-search 返回上游 HTTP 400，属于有效 xAI OAuth/Key 未形成授权，不是 OmniRoute 包或路由代码故障。

• 回退点：edge 脚本部署前备份位于 102 /root/.omniroute-edge-backups/agentmeshos-omniroute-edge.sh.20261001T040425Z.pre-v0.2.0；101 配置备份为 /root/.codex/config.toml.bak.20261001T035946Z.omniroute-search-mcp-101。

• 决定：用户取消 P13-5 观察等待期，要求删除 RR 上全部 omni 物料。

• 删除：/root/.omniroute（2.1G）、/usr/lib/node_modules/omniroute（3.8.50，2.7G）、/etc/systemd/system/agentmeshos-omniroute.service 与 .d、/root/.omniroute-cutover-backups、/root/omniroute-*、/etc/agentmeshos/omniroute-core、/etc/agentmeshos/nginx-tailnet/agentmeshos-origin-gateway.conf*、/backup/agentmeshos/omniroute-*（含 discovery 与历史备份）、RR 侧 /root/agentmeshos-omniroute-cutover.sh。
• 保留（附理由）：RR agentmeshos-omniroute-runtime-proxy.service/.socket（172.30.70.1:39181 → 100.64.0.4:39200），因为 RR 本机 agentmeshos-ai-runtime 容器的 AI_RUNTIME_OMNIROUTE_BASE_URL=http://172.30.70.1:39181 正在使用，且同机 39120/39184 用同一 172.30.70.1 网关模式；保留本地代理比容器直连更灵活，实测两者都返回 200。/var/lib/agentmeshos/swap/omniroute-install.swap 是 active swap（RR 仅 3.8G 内存），不是 omni 数据。RR Codex MCP 凭据 /root/.codex/credentials/omniroute-mcp.env 与 /root/.codex/bin/omniroute-mcp-headers.sh 仍在被 RR Codex 使用。
• 脚本统一：agentmeshos-main-origin-gateway.sh 升 v0.6.2，删除 omni server 块与 OMNIROUTE_UPSTREAM/OMNIROUTE_DISCOVERY_UPSTREAM，RR 网关不再生成 omni vhost；agentmeshos-omniroute-cutover.sh 退役删除（RR 本地 OmniRoute 与网关 omni 都已不存在）。
• 验证：RR nginx -T 中 server_name omni.yohan.fun 为 0；其余 7 个域名全部 200/302；公网 omni health 200；RR 容器经 172.30.70.1:39181 返回 200；RR systemctl --failed 为 0；RR 根盘用量 41G → 35G。
• 审计：清单与小组件归档 /srv/codex-hub-backup/agentmeshos/omniroute-rr-retire-20261001T022315Z/，tar SHA-256 b4b4072cdd57477e64232f05411eb54de1ca1096a88720a6799737b7de4039c0。
• 影响：RR 不再保留回退点，102 故障恢复改为从 Cloudreve P13-4 快照恢复或在 102 重装。
• 观察器迁移：旧 agentmeshos-omniroute-p13-5-observation.timer 已停用并删除，替换为无阶段阻塞含义的 agentmeshos-omniroute-health-observation.timer。v0.2.0 只读检查 102 生产、公网入口、RR omni 退役路径和 Runtime 代理；新首轮 20261001T022814Z.json 为 pass/critical=0/warnings=0。

🧾 2026-10-01：P13-B 公网入口直连 102，RR 退出 omni 路径并清理残留

• 背景：RR 的 100.64.0.1:39200 是 *.yohan.fun 共用回源网关，按域名分流到 8 个后端（console、docs、status、api、auth、nomad、mesh 在 RR 本机，omni 在 102）。用户选择方案 B：omni 直连 102，不走 RR 中转。
• 改动：MM 两处存储同时改。宝塔面板配置源 /www/server/proxy_project/sites/omni.yohan.fun/omni.yohan.fun.json 与渲染 conf /www/server/panel/vhost/nginx/omni.yohan.fun.conf 的 proxy_pass 均由 http://100.64.0.1:39200 改为 http://100.64.0.4:39200，并在面板 server_block 与 conf 补齐 location = /、= /dashboard（302 到 /login）与 = /login（auth_token 存在时 302 到 /home）。备份为 MM /root/omni-conf-backups/omni.yohan.fun.conf.20261001T002644Z.bak 与 omni.yohan.fun.json.20261001T004314Z.bak，nginx -t 通过后 reload。
• 更正：第一次只改了渲染 conf，漏改面板 JSON，导致面板仍显示 100.64.0.1:39200 且面板保存会把 conf 回写。补齐 JSON 后，面板显示值、渲染 conf、运行态与抓包来源四项一致。
• 证据：公网 health 200；/ 返回 302 → /login；/login 返回 200；并发打公网时在 102 抓到 100.64.0.4:39200 的连接 48 个样本全部来自 MM 100.64.0.6、来自 RR 的为 0，RR 不再在 omni 公网路径上。
• RR 残留清理：删除 Gemini Web 补丁文件与 .omniroute-patches、omniroute-pr14787-* 实验、omniroute-vnc-* 实验、omniroute-image-tests，以及已退役 discovery 的 3 个 unit、/etc/agentmeshos/omniroute-controlled-discovery*、/opt/agentmeshos/omniroute-controlled-discovery。删除前在备份盘留下清单和配置归档 /srv/codex-hub-backup/agentmeshos/omniroute-rr-cleanup-20261001T002937Z/，SHA-256 为 7e4cf1e0a07eccca3f82e168ae7a53369a830c688ee72bc55730e6475a6c21c6。
• 保留边界：RR 的 agentmeshos-omniroute-runtime-proxy.service/.socket（RR 本机 AI Runtime 容器经 172.30.70.1:39181 在用）、回退点（/root/.omniroute、3.8.50 包、agentmeshos-omniroute.service、/root/.omniroute-cutover-backups）和 active 的 /var/lib/agentmeshos/swap/omniroute-install.swap 未删除。
• 边界：RR 的 100.64.0.1:39200 网关本身保留，继续承载 console、docs、status、api、auth、nomad、mesh；只把 omni 从这条路径摘出。

🧾 2026-10-01：P13-5 发现并修复 102 edge FD 耗尽，启用持续观察

• 症状与直接原因：公网 health 连续两次在 30 秒内超时，102 loopback health 仍为 200。RR 访问 100.64.0.4:39200 同样超时，102 journal 持续输出 Failed to accept() socket, ignoring: Too many open files。
• 系统根因：agentmeshos-omniroute-edge.service 实际 LimitNOFILESoft=1024，长期连接累积后进程 FD 数达到 1024；监听和 TCP 建连成功，但 systemd-socket-proxyd 无法转发已接受连接。
• 修复：agentmeshos-omniroute-edge.sh 升为 v0.1.2，服务固定 LimitNOFILE=65536:65536、--connections-max=4096、Restart=on-failure；check 现在对软 FD 上限和连接参数做硬门禁。旧态 check 失败，新态通过。
• 回归：SERVICE_SOFT_NOFILE=65536；服务重启后 Too many open files 计数为 0；RR→102 health 与 Runtime 代理 health 均为 200，公网 health 恢复 200，failed unit 为 0。
• 持续观察：新增 agentmeshos-omniroute-p13-5-observation.py v0.1.0 与 15 分钟 systemd timer，记录写入 /srv/codex-hub-backup/agentmeshos/omniroute-p13-5/observations/。首轮 20260930T235908Z.json 为 pass、critical=0、warnings=0。
• 边界：本次只改 102 包外 edge systemd 与观察脚本，不改 OmniRoute 包和数据；RR 回退点、MM 回源和既有 Runtime unit 保持不动。

🧾 2026-10-01：P13-4 完成生产切换、全链路验收、回退与再次切换

• 计划 ID：phase-13-omniroute-latest-stable-migration。P13-4 已由用户维护窗口授权执行；102 3.8.51 成为当前生产权威，RR 本地 3.8.50 保留为回退点。当前工作包推进为 P13-5 稳定性观察与 RR 数据退役决策。
• 切换材料：RR 官方备份为 omniroute-backup-agentmeshos-p13-4-20260930T231204Z，最终一致性快照为 snapshot_20260930T231257Z_p13-4-20260930T231204Z，Cloudreve 归档为 AgentMeshOS-临时/P13-4/20260930T231204Z/；102 恢复前副本为 pre-restore_20260930T231444Z。
• 切换结果：RR 公网回源 2 处从 127.0.0.1:39180 改为 100.64.0.4:39200，本地回源为 0；Runtime drop-in 目标为 102；MM 配置未改，第 94 行仍为 proxy_pass http://100.64.0.1:39200;；公网 health 返回 200。
• 全链路：/v1/models 返回 200、models_count=92；Boss Combo 命中 deepseek-ai/DeepSeek-V3 返回 P13_4_BOSS_OK；Worker Combo 首次空响应后重试命中 command-a-reasoning-08-2025 返回 P13_4_WORKER_RETRY_OK；两者均有 usage。
• Codex Responses：/v1/responses SSE 返回 200，包含 response.completed 和真实 get_status function call，instructions、tools 与 tool_choice 均实际提交。
• 管理面与数据：combos=19、api_keys=4；Boss fill-first、Worker least-used、两者均有 responseValidation；普通模型 Key 为 restricted；102 SQLite 为 quick_check=ok、provider_connections=70、迁移 193，调用日志和 usage 已回读。
• 负向回归：未授权 /api/keys、/api/combos 为 401；错误 Token 403；API 路径穿越 403；文件路径穿越 400；错误模型 400；101 访问 102 39200 超时，访问 39180 连接拒绝。
• 回退演练：102 生成清洁快照 snapshot_20260930T232400Z_p13-4-rollback-clean，151302144 bytes、SHA-256 63bc1deeefa5efba14316a3e099b5faf494f1a2d0074d3ff5d1d9bb35a0c7b60；RR 生成 pre-restore_20260930T233116Z 后恢复并 rollback，真实调用返回 P13_4_ROLLBACK_OK。
• 再次切换：RR 生成回流快照 snapshot_20260930T233238Z_p13-4-return-to-102，150237184 bytes、SHA-256 4f9553f84560205bc81417f14c5381cd311f95c74bb3a8356b97ce8a8fc97655；102 生成 pre-restore_20260930T233320Z 后恢复并重新 activate。Cloudreve 回读路径为 AgentMeshOS-长期/P13-4-rollback-20260930T232400Z/ 与 AgentMeshOS-长期/P13-4-return-to-102-20260930T233238Z/。
• 根因一：102 缺少 sqlite3 使官方 snapshot-data.sh 退化为复制主库和 WAL，而恢复脚本只恢复主库并删除 WAL。已安装 sqlite3 3.46.1-9ubuntu0.3，部署脚本升为 v0.1.1 并强制预检；负向回归快照 snapshot_20260930T233525Z_p13-4-sqlite3-regression-retry 无 WAL、150228992 bytes、SHA-256 b9788f0801492bb296ba3e0750d6312513c4633d9894336610b5889157ddb8b0，恢复后哈希、quick_check、call_logs 和 usage_history 一致。
• 根因二：systemd 255 未按预期通过 drop-in 空 Requires= / After= 清除 Runtime 代理对 RR 本地 OmniRoute 的依赖，导致单独重启代理会把本地服务拉起。已备份原始 unit 并精确删除两行；原文件 SHA-256 35a99df108bfa8c0e96e6c212ebe13cbdc4049504a7583a1a9e540e0a2f9b52b，修复后 d387eeac4db1a0983ab90b625f40f695c46fe9a4d692bd2e866017b3a758aa68。Runtime 代理 Requires/Wants 已不含本机 OmniRoute，RR 服务为 inactive/dead/disabled，systemctl --failed 为 0。
• 脚本更新：scripts/maintenance/agentmeshos-omniroute-cutover.sh 升为 v0.1.1，新增包外 unit 备份/改写/恢复、依赖验证和 reset-failed；scripts/deploy/omniroute-native/agentmeshos-omniroute-native-deploy.sh 升为 v0.1.1，新增 sqlite3 预检。
• 用户影响：101/Home 的默认 Codex 会话不由 OmniRoute 承载，因此默认会话本身不受迁移影响；经 OmniRoute 的模型、MCP、搜索、图片和 Runtime 调用在切换与回退演练期间会短暂中断。迁移完成后 OmniRoute 通道已恢复。

🧾 2026-10-01：P13-0 至 P13-2 完成，生产切换等待维护窗口

• 计划 ID：phase-13-omniroute-latest-stable-migration。用户授权后，状态机把 P13 从“等待实施”更新为“进行中”；P13-3 完成后当前工作包推进为 P13-4 受控切换与全链路验收。
• P13-0 在执行时重新确认官方 npm latest 为 3.8.51，冻结 Node 22.23.0、npm integrity=sha512-VwwSt+bP9lJiPJXFJMz0nNGGuoewPZU3nFe1SLuO11ADgdSwTegGCxhg8Ov75+31m/cocPxHiO63zygn1XQ0MQ==、shasum=12e56f049e617edca50cc17835ea807dbf8c2042、unpackedSize=546111751；官方 CHANGELOG 为 670593 bytes、SHA-256 16b084c707f046fbc66afd997ee900ae292e70ed82dedc4c5128233f99fcfc93。
• 版本差异确认 3.8.51 重点覆盖路由与稳定性、Provider/模型目录、Free tier、可观测性、安全加固、媒体/上下文压缩和数据库迁移。后续使用口径是：Combo、模型目录、Responses 和管理面优先验证；媒体、语义缓存和日志正文导出默认关闭。
• P13-1 新增 scripts/deploy/omniroute-native/agentmeshos-omniroute-native-deploy.sh，脚本 SHA-256 为 4e25d1d2fbee28bfa0380d71f488d45d1b9ef16c8c921d2c0c7623be876c4343。脚本在安装前回读 npm latest、integrity、shasum 和 unpackedSize，不匹配即停止。
• 102 已直接安装 Node v22.23.0、npm 10.9.8 和 OmniRoute 3.8.51；全局包位于 /usr/local/lib/node_modules/omniroute，服务 enabled/active、NRestarts=0、health {"status":"healthy","setupComplete":true}，只监听 127.0.0.1:39180/39182，MemoryHigh=8 GiB、MemoryMax=10 GiB。101 访问 100.64.0.4:39180 返回连接失败，证明未开放外部监听。
• P13-2 首次官方备份触发 disk I/O error，根因是 safe-remote-run.sh 默认约 128 MiB 单文件上限截断了 153.6 MiB 数据库；使用显式 --fsize-blocks 1048576 后成功。该放宽参数成为后续大库备份的固定要求。
• RR 官方备份 agentmeshos-p13-2-20260930T221011Z 的 storage.sqlite 为 153686016 bytes、SHA-256 76d0437dd734ec976528269b103e5a014dfa2c07bdd71633c2a0e48e176a0b31；一致性快照 snapshot_20260930T221015Z_p13-2-20260930T221011Z 为 152096768 bytes、SHA-256 9a8f491162cd0948381aede2f27c1a3b7811c09342fc5414a422be8d16fae3ef。Cloudreve AgentMeshOS-临时/P13-2/20260930T221011Z 与 RR/102 回读哈希一致。
• 102 隔离恢复后 provider_connections=70、combos=19、api_keys=4、quick_check=ok；3.8.51 首次启动把副本迁移从 160/163 推进到 193/196。官方 Doctor 为 9 ok, 42 warning(s), 0 failure(s)，未发现数据库、加密凭据、Node 或原生二进制失败。
• RR 在 P13-2 后复验为 3.8.50、enabled/active、NRestarts=0、healthy，计数 70/19/4、迁移 160/163，仍是唯一生产权威。未修改 MM 回源、Runtime、Console、CLI 调用方，未停止 RR 写入，未执行生产切换，也未删除 RR 数据。
• 后续门禁：P13-4 需要用户明确进入生产维护窗口，停止 RR 写入并生成切换时刻最终一致性快照；切换剧本与回退命令已在 P13-3 冻结，但仍需端到端受控切换与回退验收。不能把 P13-2/P13-3 的隔离恢复成绩写成“102 已承接生产”。

🧾 2026-09-25：搜索策略复测与官方 VNC 登录路径启用

• 搜索 A/B 复测再次确认保留“本地优先、Omni 显式 Provider 兜底”：本地 local_search_registry 8/8 成功、总计约 15.2 秒、成本 0；Omni 显式 Provider 7/8 成功、总计约 13.1 秒、成本 0.017 USD，tavily-search 本轮 HTTP 400 失败。日常继续走本地，Omni 只在本地失败、超时、报错或无有效结果时回退，并显式指定场景 Provider。
• Gemini Web 的阻塞点纠正为“官方 headless 没有形成登录态”：RR 常驻 Chrome 虽然已登录，但 Omni 官方执行器不复用该 profile，只把数据库 Cookie 注入全新生 headless 上下文，因此不能把控制台 active 当成图片能力可用。
• 已按官方 v3.8.50 README 构建 omniroute-vnc-chromium:local，新增包外 systemd drop-in 让 Omni 使用 Docker socket，并通过 /api/vnc-session 启动官方隔离浏览器。Omni 包及源码没有修改，服务重启后 active、NRestarts=0、/healthz=ok。
• 官方 VNC 页面已打开 https://gemini.google.com/app，但当前仍显示 Sign in 且没有 Google 登录 Cookie。下一步必须由用户在 VNC 页面完成真实登录，之后由 Agent 执行官方 harvest，并重新验证 Gemini Web 生成、图片取回和编辑闭环。
• VNC 集成的 systemd 备份位于 RR /root/omniroute-systemd-backup-20260925T014634+0800/；回滚时删除 vnc-browser-login.conf、daemon-reload 并重启 Omni。完整证据见 OmniRoute 搜索与图片能力最终审计。
• 03:08–03:11 进一步定位“该地区不可用”的真实根因：宿主 agentmeshos-omniroute.service 虽有 HTTP(S)_PROXY=127.0.0.1:8118，但官方 VNC 容器不继承该环境，Chromium 直接使用 RR 公网 IP。新增包外 drop-in，通过官方 OMNIROUTE_VNC_CHROMIUM_ARGS 固定 --proxy-server=http://172.17.0.1:8118；Privoxy 新增 Docker 网桥监听，UFW 只放行 172.17.0.0/16 到 172.17.0.1:8118/tcp。现有 MM SOCKS5 出口 gemini-egress-mm.service 已 enabled/running，DD 保留备份。
• 新官方 VNC 会话 f783cf81-3a95-4e0d-bab8-0adcad1e17dc 的 Chromium 进程实际包含代理参数，容器经代理访问 Google/Gemini 均 HTTP 200；CDP 页面 HAS_REGION_UNAVAILABLE=false，当前只剩正常 Sign in。Home 入口 https://omni.yohan.fun:8443/ 返回 200，官方 /touch 返回 200。修复前配置备份位于 RR /root/omniroute-vnc-egress-backup-20260925T030255+0800/，完整回滚点见 OmniRoute 搜索与图片能力最终审计。
• 03:39–03:42 复核第二次 502：首个 VNC 容器启动后 1817 秒被 Docker 以 exit 137 销毁，精确对应官方默认 OMNIROUTE_VNC_MAX_MS=1800000。此前 /touch 保活只刷新 idle，无法延长 max；这不是 MM 反代或 socat 故障。
• 已把官方 OMNIROUTE_VNC_IDLE_MS 与 OMNIROUTE_VNC_MAX_MS 均固定为 86400000（24 小时），重启 OmniRoute 后创建新会话 c6182281-a0b5-4640-b13f-65bb6417c28d，VNC/CDP 分别映射到 127.0.0.1:32780 和 127.0.0.1:32781，Home 入口重新返回 200。从 03:42 至 04:05 连续探测约 23 分 55 秒，容器、端口和公网 HTTP 200 均无变化；socat 访问桥另设 Restart=always，主动终止旧 PID 后已自动恢复且公网仍为 HTTP 200。修复前 drop-in 备份位于 RR /root/omniroute-vnc-session-lifetime-backup-20260925T034058+0800/。
• 用户完成官方 VNC 登录后，官方 harvest 返回 harvested: true、3 个更新字段和 validation.valid: true。生图仍失败的真实根因不是账号或地区，而是官方执行器优先读取旧 api_key，harvest 却只更新 provider_specific_data.cookie；两者分别为 1746/2397 字符且 SHA-256 不同。
• 已通过官方 PATCH /api/providers/{id} 把 api_key 同步为新 Cookie，官方连接测试返回 valid: true。复测 response_format=url 生图返回 HTTP 200；无登录态 URL 直取为 403 HTML，同一 Cookie Playwright 上下文取回为 200 image/jpeg、50501 字节并保存为有效 JPEG。
• b64_json 仍返回 HTTP 502，官方错误是远程图片下载 403；官方 issue #14760 已精确记录该问题，PR #14787 的修复方向是把下载放进授权 Playwright 上下文，但当前 npm/GitHub 正式版本仍为 3.8.50，因此未采用源码补丁或重新编译。完整证据和决策点见 OmniRoute 搜索与图片能力最终审计。

🧾 2026-09-24：搜索路由与 Gemini Web 图片复测规则落地

• 101 Codex 搜索规则已落入 /root/.codex/AGENTS.md 和 /root/.codex/docs/core-operating-rules.md：日常搜索先走 local_search_registry；本地不可用、超时、报错或无有效结果时回退 omniroute_web_search，并按场景显式选择 serper-search、tavily-search、perplexity-search、context7、exa-search 或 firecrawl。Omni 搜索 auto 不作为稳定默认。
• Gemini Web 会话已恢复：官方 PATCH /api/providers/{id} 返回 HTTP 200，连接 active，浏览器探针可进入输入页且无登录或地区拦截。生成入口实测 HTTP 200，并返回 1 个 lh3.googleusercontent.com 图片 URL。
• 端到端图片取回仍未通过：生成 URL 在直连、MM 出口、Playwright 和 curl_cffi 变体中均为 HTTP 403 HTML，返回体约 2.5 KiB，不是 PNG/JPEG/WebP。b64_json 生成返回 HTTP 502，官方 /v1/images/edits 对 gemini-web 返回 HTTP 400。因此在取回和编辑闭环通过前，不能把 101 对话中的图片任务声明为已可用，也不新增专用 MCP。
• 本次没有再修改 OmniRoute 包、没有重新编译、没有重启服务；RR 当前为官方 3.8.50、PID 3846136、NRestarts=0、/healthz=ok。完整证据和回退点见 OmniRoute 搜索与图片能力最终审计。

🧾 2026-09-24：OmniRoute 搜索与图片能力最终审计

• 只读复核确认 RR 当前生产为官方 omniroute@3.8.50，PID 3846136、NRestarts=0、/healthz=ok；官方 npm latest 与 GitHub Release v3.8.50 一致，当前无需升级。
• 搜索结论：/v1/search 是独立 Search Provider 执行器，不经过 21 个聊天模型或 Chat Combo 的 fill-first。官方自动模式按最低 costPerQuery 选择已配置的非 fallbackOnly Provider，并只预选一个备用；当前 101 Omni 自动搜索实际命中 ollama-search，稳定性不足。101 本地 local_search_registry 继续作为通用搜索主路径，Omni 应显式选择 Provider，通用优先 serper-search。
• 图片结论：官方 gemini-web/nano-banana-web 的生成接口只支持可用的 response_format=url 路径；b64_json 生成因远程图片下载 403 返回 HTTP 502；官方 /v1/images/edits 对 gemini-web 返回 HTTP 400，3.8.50 不支持该编辑路径。Gemini 聊天执行器只把字符串消息送入网页，图片 part 不会被官方聊天路径可靠转发。
• 规则结论：全局规则和项目架构规则已明确 OmniRoute 只使用官方 npm/Release、官方 CLI/API 和控制台配置，禁止源码修改、补丁、私有 Fork/分支/镜像、重新编译、替换包文件或改写构建产物。具体证据与决策见 OmniRoute 搜索与图片能力最终审计。

🧾 2026-08-30：统一剥离实时索引并校正 DETACH-07 证据

• 计划文件和计划索引的当前目标统一更新为 DETACH-09，与目标账本及最终清理门评估一致。
• DETACH-07 证据页由早期“尚未执行”调查快照校正为已验收事实：RR 无 Project 控制对象，生产 Bridge/Runtime 保持运行，101 误部署 Bridge 仅保留停用状态并延后至 DETACH-09 清理门。
• 未删除任何凭据、审计、备份、生产载荷或恢复材料；DETACH-09 的整机重启、故障连续性和窗口后回滚仍待维护窗口。

🧾 2026-08-30：DETACH-09 记录索引校正提交与 CI

• 计划版本更新为 v1.2，DETACH-09 证据追加提交 45b9f7d 和 GitHub Actions run 33291325656 成功证据。
• 现场仍保持维护窗口前状态；没有执行整机重启、故障注入或最终删除。

🧾 2026-08-30：DETACH-09 双入口实时复核

• 101 本机身份、独立备份盘、停用 Bridge 和空 Runtime 网络状态保持符合维护窗口前基线。
• RR Tailnet 与物理 SSH 使用已登记专用密钥均登录成功，生产 Bridge/Nomad、容器和公网 Docs 健康均通过；未执行破坏性操作。
• 记录物理 SSH 未指定专用密钥时的认证失败及显式密钥复测结果，避免将客户端密钥选择问题误判为 RR 服务故障。

🧾 2026-08-30：DETACH-09 凭据与备份保留边界复核

• 两端凭据与审计目录权限、101 独立快照校验和 RR /backup 设备来源复核通过；审计数据库 0644 与既有基线一致。
• 未执行凭据读取、轮换、删除或任何生产变更；整机重启、故障注入和最终清理继续等待维护窗口。

🧾 2026-08-30：登记 RR 系统盘容量遗留风险

• 现场确认 RR /backup 与系统根目录共用 /dev/vda2，约 79% 已用、约 12 GB 可用；101 独立备份盘约 26% 已用。
• 登记 RR-SYS-DISK-CAPACITY 风险；不通过删除历史备份释放空间，容量和归档策略留待维护窗口评估。

🧾 2026-08-30：DETACH-09 清理对象 dry-run

• 只读枚举 101 停用 Bridge 的 unit、安装代码、__pycache__ 和空 Docker 网络，确认清理对象与保护对象边界。
• 清理门尚未开启；未删除凭据、审计、备份、生产能力或恢复材料。

🧾 2026-08-30：登记 RR 剥离后空间清理子工作包

• 盘点确认 RR 系统盘主要空间来自系统 Codex、Codex 临时/历史材料、containerd 生产镜像、活动 swap 和系统日志；/backup 仅约 533 MB，不是主要占用来源。
• 将空间清理纳入 DETACH-09：系统 Codex、活动 swap、生产数据、凭据、审计和可恢复备份绝对保留；旧镜像、明确无用临时材料和日志仅在维护窗口完成用途确认、快照和回滚验证后处理。
• 本次仅盘点，未执行 prune、swap 删除、日志清理或任何生产变更。

🧾 2026-08-30：细化 RR 空间清理候选边界

• Docker 当前无 dangling 镜像；生产与 rollback 镜像继续保留。已退役组件镜像只作为待核验候选，不直接删除。
• /root/temp/codex-upgrade-backup 属于系统 Codex 升级备份，约 3.6 GB；活动 omniroute-install.swap 约 4 GB 且正在使用，二者均排除在项目清理之外。

🧾 2026-08-30：RR 镜像引用 dry-run

• 逐镜像核对容器引用；无 dangling 镜像。4 个 JuiceFS CSI 版本、MinIO 客户端、rclone 和 Python 基础镜像当前无容器引用，且未发现现行配置引用，登记为维护窗口复核候选。
• 未被当前容器引用的生产 rollback 镜像继续保留，未执行 prune 或镜像删除。

🧾 2026-08-30：量化退役镜像清理候选

• 退役组件镜像无现行容器或配置引用，标称体积合计约 1 GB；实际可回收量待按共享层计算。
• 生产 rollback 镜像继续保留；未执行镜像删除、prune 或生产变更。

🧾 2026-08-30：同步 DETACH-09 阻塞状态

• 目标账本同步为 DETACH-09=已阻塞：待维护窗口，与清理门评估和实际现场状态一致。
• 阻塞原因仅为缺少批准的生产维护窗口；不需要提供密码、Token 或 WebDAV 凭据。

🧾 2026-08-29：DETACH-05 发布接口前置核验

• 只核验 101 Cloudreve root-only 配置字段与仓库发布脚本，确认现有配置仅覆盖受限系统 WebDAV；未发现创建受控共享 HTTPS 下载链接的发布器、CI 接口或最小权限发布凭据。
• 因此不能用 WebDAV 凭据替代发布接口，更不能传给 Worker。受控公网分发的隔离验收须等待 Cloudreve 所有者提供或批准最小权限 CI 发布接口；该项目保留为 DETACH-05 的真实前置条件，现网 SSH/SCP 仍未改动。

🧾 2026-08-29：DETACH-05 受控公网分发选型完成

• 针对 RR Bridge 通过 SSH/SCP 传送节点安装脚本的合规缺口，完成四个候选路径比较；正式选择“Cloudreve 受控共享 HTTPS + 版本化发布清单 + SHA-256 + Worker 自行下载”。
• 101/GitHub Actions 保持构建和发布协调职责，RR 保持生产 Runtime、Bridge 和固定控制动作职责；未把 Bridge 或生产 Runtime 迁往 101，未复制任何凭据。
• 本次只更新选型、部署约束与 DETACH-05 目标登记。现网 SSH/SCP 传输尚未迁移，下一步必须先完成非生产节点隔离验收和回滚设计；四个 RR 生产脚本、历史 release、审计和恢复材料继续保留。

🧾 2026-08-29：DETACH-01 进入待验收

• 完成 RR 代表性恢复材料的隔离验证：SQLite 源文件和隔离副本均 quick_check=ok，归档可读，临时副本已清理。
• MM/DD 只读角色证据、WebDAV 生命周期证据、备份对象分类和 RR/101 文档冲突复核均已追加至基线文件。
• agentmeshos-detachment-goals.json 将 DETACH-01 从“实施中”更新为“待验收”；不直接标记“已完成”，验收通过后才允许推进 DETACH-02。

🧾 2026-08-29：DETACH-01 验收审计准备完成

• 对六项交付物逐项建立证据映射：节点职责、服务调用、凭据元数据、备份分类、RR→101 差异、风险/禁止操作。
• 清理基线文件中早期“调查中、MM/DD 待验证、备份尚未分类”等过时实时措辞；历史事实保留并标注为历史诊断记录。
• 当前仍为“待验收”，负责人验收确认和后续 DETACH-08/06 的实施不被提前伪装成 DETACH-01 已完成。

🧾 2026-08-29：DETACH-01 验收完成，启动 DETACH-02 调查

• 六项基线交付物均已具备现场证据，DETACH-01 正式登记为“已完成”。
• DETACH-02 登记为“调查中”，确认 101 仓库已有同源 Bridge 代码和部署脚本，但现场没有正式 AI Runtime 容器或 agentmeshos-ai-runtime 网络。
• 未创建旁路 Docker 网络、未生成 Bridge 密钥、未安装 101 systemd 单元、未修改 UFW、未复制凭据；RR Bridge 保持运行。

🧾 2026-08-29：DETACH-02 发现 Runtime/Bridge 启动环

• 101 现场存在 root-only Bridge/Runtime 配置元数据，但没有 Runtime 容器、Runtime 网络、OmniRoute 服务监听、有效 Nomad 环境或告警签名配置。
• 正式部署脚本存在前置循环：Runtime 要求 Bridge 健康，Bridge 要求 Runtime 网络；该问题登记为接管实施前设计缺口。
• 未通过旁路网络、临时服务或凭据复制绕过；RR Bridge 继续保留。

🧾 2026-08-29：101 Bridge 服务本体部署完成

• 修正正式部署脚本以按固定 172.30.70.0/29 边界创建并校验 Runtime Docker 网络，解除 Runtime/Bridge 启动环中的网络前置缺口。
• 101 Bridge 已通过正式脚本部署：systemd active/enabled、root、固定 172.30.70.1:39184、UFW 仅允许 172.30.70.2、健康端点通过。
• 项目 Bridge 测试 14 passed；Runtime 尚未部署，Runtime→Bridge 调用链和真实动作验收仍未完成，RR Bridge 不停用。

🧾 2026-08-29：DETACH-02 确认跨节点控制面拓扑缺口

• 101 的 Nomad 服务虽 active，但 Nomad 环境为空；本机 OmniRoute、Runtime proxy、告警签名和 Runtime 调用方均缺失。
• 101 Bridge 已运行但没有合法 Runtime 调用方；不能把 RR 私网服务或凭据未经设计复制到 101。
• 下一步先确定 Runtime、OmniRoute 与 Bridge 的跨节点拓扑，再实施依赖补齐和调用链验收；RR 生产控制链路保持不变。

🧾 2026-08-29：DETACH-02 方案 C 与 CI/CD 边界确认

• 正式确认方案 C：101 是项目代码、资料、GitHub 同步和 CI/CD 发布协调节点；RR 是生产部署与运行节点，继续承载生产 Runtime、System Operations Bridge、Docker、Nomad 和生产服务。
• 撤销“101 Bridge 等价接管”这一错误目标，不建立第二套生产 Runtime/Bridge，不复制 RR 凭据；此前 101 误部署的 Bridge 作为待保存快照后受控停用对象处理。
• CI/CD 默认由 GitHub Actions 执行测试、文档构建、镜像/产物构建、摘要固定和发布记录；RR 只消费已发布版本化产物。人工发布仅作为同一产物的审计化应急回退。
• 已同步更新剥离计划、目标登记、总体架构、技术选型、工程规范、部署规范、系统总结和 RR 交接记录；后续证据写入 DETACH-02 目录并按计划推进。

🧾 2026-08-29：DETACH-02 CI/CD 证据与 101 主机指纹前置

• 提交 a16c95e 已推送；GitHub Actions Docs 工作流 33246228482 成功完成，现有组件工作流均保留手动触发和版本化 GHCR 产物能力。
• 101 默认 SSH 22 端口拒绝，已知管理端口 10122 可达；由于当前客户端缺少已登记主机指纹，未执行任何 101 服务读取、快照或停用操作。待通过可信路径核验指纹后继续。

🧾 2026-08-29：101 本机核验与误部署 Bridge 受控停用

• 本机 hostname=pcdell-101、Tailnet 100.64.0.2，确认无需远程 SSH 回连 101。
• 在独立备份盘 /dev/sda1 保存 101 Bridge 停用前快照 101-bridge-pre-stop-20260829T095527Z，清单摘要 SHA-256 为 564571bb758325e0e2d306d4a37c9b6283da92463585965dc3fdbb4ec612a8c1。
• 误部署 Bridge 已按方案 C 受控停用并禁用；配置、审计库、Docker 网络和恢复材料均保留，未删除任何凭据。

🧾 2026-08-29：DETACH-03 进入实施，101 WebDAV 生命周期复测

• 101 本机系统 WebDAV 配置保持 root:root 0600，与 Project 专用配置分离。
• 根目录、AgentMeshOS-临时、AgentMeshOS-长期 均 PROPFIND 207；随机临时对象通过 curl -T - 上传 201、回读哈希一致、删除 204、删除后 404，探针已清理。
• 首次 --data-binary 上传返回 404，已记录为客户端方式兼容性差异并完成正式方式复测；未把失败结果写成通过。
• DETACH-03 状态更新为“实施中”，证据文件为 docs/plans/agentmeshos-detachment-evidence/DETACH-03/README.md。

🧾 2026-08-29：DETACH-03 runtime-artifacts 只读核对

• AgentMeshOS-长期/runtime-artifacts/ 访问返回 207，已有历史任务对象和 applications/ 子目录。
• 本次仅枚举名称与修改时间，不读取业务内容、不删除长期对象；清理统一延后至 DETACH-09 最终清理门。

🧾 2026-08-29：DETACH-03 凭据保留对账与完成

• 101 系统 WebDAV 配置继续保持 root:root 0600，与 Project 专用配置分离；只核验路径、权限与职责，未记录凭据值。
• RR 的系统 WebDAV、Runtime、Bridge、认证站点和 CLI Gateway 生产配置均仍存在并保持 root:root 0600；未复制、删除或轮换任何 RR 凭据。
• runtime-artifacts 长期对象不自动删除，生产写入主体仍为 RR 本机 root-only Runtime。DETACH-03 达到验收条件并标记为“已完成”；后续凭据轮换仅能作为独立、经批准的变更处理，双端保留清单将在 DETACH-09 再次复核。
• 当前推进目标切换为 DETACH-04，核验 101 项目入口、发布协调和系统 Codex 独立边界；不修改 101-project同步-03。

🧾 2026-08-29：DETACH-04 项目入口与系统边界首轮核验

• 101 本机 /root/project/AgentMeshOS 与 Git 顶层一致，origin 指向 AgentMeshOS GitHub 仓库；九个既有 GitHub Actions 构建工作流均保留受控 push 与手动触发入口。
• 系统 Codex App Server 位于主机全局 /root/.codex，而非项目仓库或项目容器。默认路由和 DNS 均走本机物理网络，Tailnet 不接收 DNS、路由或 Exit Node；GitHub HTTPS 现场可达。
• 101 的历史 Project 挂载/同步 systemd 单元目前为 masked、非活动；本任务不解封、不重启、不替换它们。同步控制器的实际健康和恢复材料继续由 101-project同步-03 负责，DETACH-04 仅登记接口依赖。

🧾 2026-08-29：DETACH-05 RR 生产载荷首轮核验

• RR 的 Docker、Nomad 和正式 Bridge 均为 active/enabled；Bridge 运行根目录为 /usr/local/lib/agentmeshos/project-runtime，私有监听保持在 RR Docker 网络。
• 文档站部署、节点 metrics、Nomad Client 与节点库存四个脚本均属于 RR 生产运行载荷；版本化 Bridge release 中的匹配副本哈希一致，必须保留，不迁移到 101。
• RR /backup 位于系统盘，不能作为独立回滚盘。另发现 Bridge 节点部署通过 SSH/SCP 传送脚本，违反现行的文件传输边界；该项已登记为后续架构选型、迁移和验收条件，未在现网擅自改动。

🧾 2026-08-29：DETACH-02 登记 Runtime 归属决策缺口

• 发现“RR 保留生产 Runtime”与“101 Bridge 独立等价接管”在现有同机 Runtime 调用协议下不能同时成立。
• 在 DETACH-02 证据中登记 Runtime/OmniRoute/Bridge 的 A/B/C 三种拓扑及风险；未擅自选择迁移、跨节点代理或第二 Runtime。
• 在拓扑获得明确批准前，101 Bridge 保持已部署但不承载生产调用，RR Runtime/Bridge 保持现状。

🧾 2026-08-29：纠正目标模式登记为实际执行目标

• 发现 Codex 顶层目标栏仍显示旧的用户请求原文；该文本不是本项目的实际目标定义。
• 增量修正 agentmeshos-detachment-goals.json：登记完整系统剥离总体目标、权威来源、当前实际目标 DETACH-01、当前工作包和状态规则。
• 保留 DETACH-01 至 DETACH-09 全部目标、依赖、证据路径和既有历史；不创建新计划、不删除旧结论。
• 当前推进仍停留在 DETACH-01“实施中”，未伪造完成状态；顶层 UI 目标字段若无可用编辑接口，不能声称已被程序切换。

🧾 2026-08-29：建立 RR→101 系统剥离目标模式

• 固化权威计划 AgentMeshOS RR→101 系统剥离权威计划，保留详细计划、九个独立目标、依赖、验收、凭据/备份保留和回滚边界。
• 建立机器可读目标登记 agentmeshos-detachment-goals.json，完整登记 DETACH-01 至 DETACH-09；当前 DETACH-01 为“调查中”，其余目标为“未开始”。
• 建立 agentmeshos-detachment-baseline.md 和证据目录；不删除任何凭据、历史备份、审计材料或生产载荷，不介入 101-project同步-03 或 WebBridge。

🧾 2026-08-18：P6-11 收口完成，P7 开始实施

• P6-11 的本地输入、应用资料目录、调用留痕、运行状态和告警跨域收口已完成；P6 追加归档更正，保留原始历史事实。
• 验收：P6 专项 15 passed；P6/P7 兼容增量测试 16 passed；旧 SQLite 增量迁移与 quick_check=ok；Console JavaScript、嵌入和工作区契约通过。
• 当前阶段切换为 P7“本地应用 MVP 与应用运行规范”进行中。P7 已实现设置版本、资料集合、不可变运行快照、历史筛选/比较、结果导出、逻辑备份和受控恢复；生产发布、桌面/移动真实浏览器和连续使用出口仍待完成。
• 计划 ID：phase-7-application-mvp；阶段状态：进行中；计划状态：已完成。

🧾 2026-08-18：P6-11 系统文件根映射与管理操作收口

• 根因：WebDAV 根级“本地资料分析与验收工作台专用目录”真实存在，但 Runtime 旧白名单只允许 AgentMeshOS-长期/applications/local-review 和 AgentMeshOS-临时，因此选择器显示为空或找不到该目录。
• 修复：新增四个受控系统根映射，统一“系统文件”入口与应用选择器的路径校验；新增 Runtime 管理员接口和主题自定义弹窗，支持新建目录、重命名、显式确认删除，禁止删除系统根和访问 Project。
• 验证：P6 应用 API/存储专项测试通过；Console 最新镜像 sha256:28e35203eeaba96e5de5e4aee0cc587ff887949109f49b6ec78fa094c764ff6a 已部署，容器健康，生产静态资源回读包含系统文件与专用目录映射。
• 边界：浏览器不接触 WebDAV 凭据；上传、下载和预览不通过 Runtime 任意代理文件字节，待 Cloudreve 公网数据面接入后单独验收。

🧾 2026-08-18：P6-11 文件管理入口更正

• 更正：此前将“系统云盘”错误替换为 Console 自制“系统文件”页，并尝试在 Runtime 重复目录管理。这不符合复用既有成熟能力的原则。
• 结论：现网 Cloudreve 已提供目录树、上传、下载、预览、移动、重命名、删除、回收站和分享，系统云盘入口恢复直达 cloud.yohan.fun；不新增 Filestash、Filebrowser 或第二个文件管理服务。
• 保留：本地资料应用的受限 WebDAV 元数据选择器及根级专用目录映射继续存在；Project 项目库仍与系统目录隔离。

🧾 2026-08-18：P6-11 Cloudreve Markdown 分析提交修复

• 根因：选择器自动校验文件但 Console 将空 SHA-256 作为字符串提交，触发 FastAPI 422；专用目录只加入选择器，未同步加入运行和输入持久化白名单。
• 修复：空哈希统一传为 null，由 Runtime 下载侧计算；三处目录白名单统一；Console 将字段校验数组翻译为可读错误。
• 验证：无手填 SHA-256 的 Cloudreve Markdown 与根级专用目录 Markdown 均覆盖 API 回归，确认最终状态为 awaiting_benson。

🧾 2026-08-18：P6-11 收口修正重新进入进行中

• 计划 ID：phase-6-application-center-foundation。基础 P6-0 至 P6-10 已完成，因真实使用发现本地文件输入、粘贴状态、应用资料目录管理、调用式运行提示、AI BOSS 调用留痕和告警 CORS preflight 缺口，当前阶段回到 P6-11 进行中。
• 当前工作包：P6-11 本地输入、目录管理与调用留痕收口；P7 计划仍完整保留，但等待 P6-11 完成公网部署和真实浏览器复验。
• 边界：不改变 P1-P5 数据、不引入第二 Runtime/调度器/动态代码执行；完成 Runtime、Console、API Gateway 部署和公网回读后才重新生成 P6 收口归档。

🧾 2026-08-18：P6-10 系统资料选择与对话应用调用完成归档

• 计划 ID：phase-6-application-center-foundation-p6-10。P6-10 已完成，P6 正式归档；当前阶段切换为 P7（阶段七）“本地应用 MVP 与应用运行规范”，计划已完成、阶段等待实施。
• 已完成实现：应用工作区增加系统 Cloudreve 资料选择器；选择器只显示系统应用资料根，不混入独立 Project 项目库；Runtime 下载时重新校验文件大小和 SHA-256，浏览器不接收文件字节或凭据。
• 已完成实现：AI BOSS 对话增加结构化 @local-review 应用入口。应用运行与当前主题关联，明确返回 model_called=false，并写入人类可读结果；任意不存在的非默认主题不会被隐式创建。
• 验证：P6 专项 11 passed，Runtime 全量 196 passed，Console 静态、嵌入、浏览器契约通过；Runtime、Console、Docs 已发布，真实 Cloudreve 文件选择/哈希回读、@应用 主题对话、桌面和 390x844 浏览器回归、Docs 公网回读均通过。P6-10 测试资料已清理。

🧾 2026-08-18：P6 完成归档，P7 进入等待实施

• 计划 ID：phase-7-application-mvp-ready。P6 应用中心基础与本地应用样板已完成 Runtime、Console、Cloudreve、恢复、部署和公网管理员浏览器验收并归档。
• 状态变化：当前阶段切换为 P7（阶段七）“本地应用 MVP 与应用运行规范”，计划已完成、阶段等待实施；P8 继续等待 P7 完成。
• 边界：本次只完成 P6 归档和状态切换，不创建 P7 数据表、接口、页面、Worker、策略或后台运行。

🧾 2026-08-18：P6-0 契约冻结与生产基线完成

• 计划 ID：phase-6-application-center-foundation-started。P6-0 已完成，当前进入 P6-1 数据模型与内置注册表；这不表示应用注册、运行 API、Console 应用中心或样板应用已实现。
• 生产基线：Runtime 健康；运行镜像与 rollback 标签均可用。生产 Runtime SQLite 已完成一致性备份，原库和备份的 quick_check=ok；完整脱敏契约、迁移、API、开关和夹具见 P6 p6-v1 契约与生产基线。
• 边界：P6-1 只创建可重复的增量 Store 与默认停用的内置 Manifest，不调用模型、不启动 Worker/Nomad Job、不启用应用。

🧾 2026-08-15：P4 对话统一操作与记忆/系统操作可读性收口

• 生产发布：提交 7e07f87 的 Runtime、Console、Docs Actions 31893826539、31893826561、31893826538 均成功。Runtime SQLite 发布前备份 SHA-256 为 afbf173aaea8a1d406dc1bd35da464a4ae9ba57278b0a33d3fe51d138567ac91，发布后 quick_check=ok；三项生产 OCI revision 均为 7e07f872f2e0441658aada9da5c06901c037fb0b，Runtime、Console、Docs、Bridge 与公网 Docs 均健康。

• 生产验收：管理员会话下的公网 Console 已验证 AI BOSS 五个标签、Context Manifest 分页控件、桌面 1440 × 900 与移动 390 × 844 无横向溢出。主题统计、Manifest 分页和系统动作目录接口均返回新字段；一次真实只读诊断返回根分区 69%、可用内存 1.1 GiB、四项固定服务 4/4 健康。没有触发模型调用、业务任务、验收决定或 P5。

• AI BOSS 对话成为 Benson 唯一写操作入口；任务页和成果与验收页改为只读查询并跳回所属主题。写操作继续复用 Runtime 原接口、幂等键与状态机，不增加第二控制面。

• 主题目录增加待处理、消息和交互统计，并修复任务/待验收成果重复计数；主题切换同时清空旧工作摘要，操作提交前复核所属主题。记忆页拆分主题历史、长期记忆和可分页全历史 Context Manifest。
• System Operations Bridge 的固定动作补齐用途、范围、风险和预期结果；Console 显示中文结果和下一步，技术字段折叠。固定动作仍为白名单，不开放任意 Shell。
• 本地证据为 Runtime 全量 161 passed（其中分页专项 2 passed）、Operation Bridge 14 passed，Console 静态、嵌入和浏览器契约通过。GitHub Actions、生产部署和公网管理员验收尚待本次发布后补记；P5 未启动。

🧾 2026-08-14：P4 工作台主题与上下文入口生产回归通过

• 发布：提交 a0862d2 的 Runtime、Console、Docs 镜像 Actions 31796504914、31796504991、31796504941 均成功。生产 Runtime、Console 与 Docs 按 Runtime → Console → Docs 顺序发布；三项容器健康、Runtime /health、SQLite quick_check 与 Console/Docs 公网健康均通过。
• 桌面真实浏览器：已换取临时管理员 HttpOnly 会话，未输出 Key 或主题正文。一个已有非默认主题在切换后及等待五秒 SSE 刷新后均保持 2 条消息；新建主题在初始与五秒刷新后均为 0 条消息；主题归档和恢复均返回成功；关联 Context Manifest 可读。
• 移动真实浏览器：390x844 下消息旁“查看上下文清单”可打开实际清单，页面无横向溢出。回归主题保持活动状态；本轮没有提交模型交互或消费 Token。P5 仍未实施。

🧾 2026-08-14：P4 工作台主题消息与上下文入口更正

• 根因：非默认主题的详情接口此前只返回主题元数据；Console 先正确读取消息，随后 SSE 刷新改用该详情响应并覆盖聊天区，造成切换主题后消息短暂可见又显示“暂无对话记录”。
• 修复：主题详情现统一返回主题、消息及交互；Console 对主题读取增加过期响应保护，新建主题立即清空旧显示，并提供归档主题显示/恢复、消息旁明确的交互 ID/通道 ID/实际模型/调用状态和“查看上下文清单”入口。记忆页改为当前主题交互选择器，不再要求手填 ID。
• 本机证据：完整本地 CI 为 154 passed，Gateway 与 Console 静态/浏览器契约、计划状态检查和严格 Docs 构建均通过。生产 Runtime、Console 与 Docs 的回归和公网回读仍待对应发布后补记；P5 继续未实施。

🧾 2026-08-17：P4 生产回归后的现行运行事实

• 本记录覆盖本页早期“尚待补记”的发布前描述，不删除其历史证据。P4 已完成生产回归；P5 仍为“规划中，尚未实施”，没有策略表、循环、定时器、事件生产者或后台模型调用。
• 当前 AI_RUNTIME_P4_AUTO_EXECUTION_ENABLED=true 仅自动派发 Benson 已确认、低风险、主节点、无外部来源、无前置依赖的初始内部任务。返工、高风险、外部/Nomad 与依赖阻塞任务仍停在可见状态，等待 Benson 明确操作。
• 103 网页验证器已通过 cloud.yohan.fun 公网归档恢复和真实 Nomad 验收。根因是 Nomad 清理唯一标签后 Docker 删除无标签镜像；现行运行口径为单独保留 agentmeshos-web-verifier:runtime-pin-b28eee08，二次 Job 清理后该标签和运行 image ID 均仍存在。

🧾 2026-08-14：阶段四最终完成归档，阶段五恢复为规划

• 计划 ID：phase-5-ai-boss-active-loop-planning。
• 状态变化：重新开启后的阶段四已完成并归档，最终事实见阶段四最终归档；原阶段四核心归档继续保留历史事实。
• 阶段五现为“规划中，尚未实施”。未启动任何 P5 Runtime/Console/数据库实现、定时器、事件触发或后台模型调用；AI_RUNTIME_P4_AUTO_EXECUTION_ENABLED=false 保持关闭。
• 归档状态提交 155f054 的 Docs Actions 31794042697 成功；Docs 已部署摘要 sha256:a5611f4b117cac53123800e365835c25172a8363627199ee0100a3621856babc，本机与公网健康均为 ok，公网计划正文已回读 P4 归档与 P5 规划状态。

🧾 2026-08-14：阶段四网页验证 Worker 主线前置验收收口

• 此前 103 离线导致的未分配网页验证任务保留为历史失败事实；103 恢复 ready/eligible 后，正确浏览器镜像只经 Cloudreve 公网数据面导入。旧镜像缺少 Playwright 的根因不覆盖。
• 42c3953 固定 103 已验证 image ID，118bdd1 修复 Nomad 日志 API 的 Base64 Data 包装解析；Runtime Actions 31778546494、31778925418 成功，生产 Runtime sha-118bdd1 健康，部署前后 SQLite quick_check=ok。
• 真实任务 8dd273865175492c 在 pcdell-103 完成 HTTP、文本和截图检查；Runtime 已登记 Artifact、成果和截图哈希，任务停在 boss_review，没有伪造最终 completed，Job 已清理。P4 自动执行和 P5 均未启用；此项使 P4 可以进入数据库与兼容读取主线，不改变 P4“进行中”状态。

🧾 2026-08-11：阶段四智能编排与成果验收闭环重新开启

• 计划 ID：phase-4-ai-boss-orchestration-delivery-closure-reopened。
• 状态变化：当前阶段由阶段五规划退回阶段四进行中；P5、P6、P7、P8 编号不变，P5 等待阶段四完成新的最终归档。
• 重新开启原因：后续审计确认当前意图规划仍以关键词和固定单任务为主，AI BOSS 尚未真正选择逻辑 Worker、依赖、并行关系和成果契约；现有自动审核没有让模型结论真正参与最终决定，Console 也无法查看和验收完整成果。
• 历史保留：原阶段四已经通过的交互、预算、上下文、记忆、附件、多模态、SSE、CLI Gateway 和 API Gateway 证据继续有效，不删除、不伪造，也不作为新能力已经完成的证明。
• 当前权威记录：阶段四：AI BOSS 智能编排、通用成果与验收闭环。原完成归档只追加更正说明，旧计划 URL 保留为兼容入口。
• 实施顺序：先发布权威计划和架构文档，再以对应 Git 提交创建完整执行目标；随后按数据库、智能规划、成果检查、AI 审核、Console 和生产灰度批次实施。

🧾 2026-08-12：阶段四智能规划预算契约与只执行前灰度

• 提交 3d0e308 为 Planner 提示增加当前预算档位的任务 Token 上限和任务总和约束；Runtime Actions 31582204642 成功，生产镜像摘要为 sha256:0ad957fdb373381c2ad658e07834ac875eeb8596e9b643a78072c040ab429d5e。
• 生产公开低风险规划请求返回 HTTP 201，一次模型调用生成两步结构化计划并持久化；无依赖任务为 queued，依赖任务为 blocked_dependency，自动执行开关保持关闭，未提交 Nomad Job。
• 该记录只代表智能规划灰度通过，不改变 P4“进行中”状态；网页验证 Worker、成果检查、AI BOSS 审核、Benson 决策、普通任务自动验收和最终出口仍待完成。

🧾 2026-08-12：阶段四来源授权与真实 Worker 派工灰度

• eb5f31c 补齐公开研究来源授权契约：Benson 提交来源 ID/URL，Runtime 校验并冻结 URL，AI BOSS 只选择来源 ID，Worker 只读取冻结快照。
• 生产计划 468e2657ad174312a4c208b425994890 真实派发到 pcdell-101；Nomad Job agentmeshos-runtime-daafa2022b4d42df、Allocation c0595075 完成，Worker 从 https://example.com 读取 559 bytes 并回传 Artifact。
• AI BOSS 审核输出无法解析，Runtime 正确进入 rework_requested，生成返工任务但不自动执行；自动执行开关已关闭。该批次证明真实派工和失败保护有效，同时确认结构化审核仍是 P4 未完成项。

🧾 2026-08-12：阶段四审核契约与 Console 生产发布

• b2180b5 收紧 AI BOSS 审核输入输出：每条标准仅可引用其允许证据，必须返回唯一 JSON 对象并覆盖全部必需标准；解析失败、遗漏或伪造证据仍进入证据不足/返工，不能自动通过。
• Runtime 已部署为 sha-b2180b5，健康与 SQLite quick_check=ok 通过；智能规划、只读和安全预览开启，验证器与自动执行保持关闭。Console 已切换至摘要 sha256:98a18bb1946856bb4d8d6dfc24244acc8e5cb96d8165ee87a891c7c9109545c1，容器健康和桌面/移动浏览器契约通过。
• 发布期间发现并修正 Docker 镜像清理器短 ID 与完整 ID 比较导致的误报；Docker 已阻止其删除运行 Runtime，修复后的真实 dry-run 与离线回归均确认运行镜像不再成为删除候选。真实结构化审核、检查器、Benson 验收和 P4 最终出口仍未完成。

🧾 2026-08-12：阶段四受控返工派发与任务图安全视图

• 新增 POST /boss/v1/tasks/{task_id}/dispatch-rework：仅允许 Benson 显式派发已排队、P4 契约且具有返工来源的任务；普通任务、恢复任务、自动扫描和 P5 循环均不能使用该入口。
• 首次请求在一个 SQLite 事务中写入任务操作幂等键、领取任务并创建运行记录；同一键重试回放同一运行，不重复模型调用或 Nomad 提交。Console 仅对后端 is_rework=true 显示“执行返工”。
• /boss/v1/task-graph 改用 P4 安全白名单视图，不再把完整任务规格或结果返回浏览器。固定本机全套回归 114 passed、Gateway 三项契约与 Console 浏览器契约均通过；该项待 CI 和生产灰度，未启用自动执行或 P5。

🧾 2026-08-12：阶段四受控返工生产灰度与审核失败保护

• Benson 对已排队返工任务 cdf511a44b3340c9 发起一次显式派发，并立即以同一幂等键重放。SQLite 只产生一条 dispatch_rework 操作记录和一个 Nomad 运行；没有重复模型调用或重复 Nomad 提交。
• Job 在 pcdell-101 完成，Runtime 接收 271 bytes JSON Artifact，SHA-256 为 d49f9c518d528439bfe5e11c41f463a07a53f9b866d5e1566ff39f6875ee71ff。公开分析调用结算 3004 Token，AI BOSS 审核调用结算 4763 Token。
• 审核输出仍未满足唯一 JSON/证据引用契约，Runtime 没有伪造通过：任务进入 rework_requested，创建下一轮返工并保持下游阻塞。验证器与全局自动执行均保持关闭，SQLite quick_check=ok。结论是受控返工和失败保护已获生产证据；稳定结构化审核、确定性检查和自动验收仍未完成。
• 证据记录提交 e2c6d03 已推送；Docs 构建 31592905496 与 31593113383 成功，生产 Docs 镜像切换为 sha256:2d2f62ea441073cdf4ebd16521fb9157bca96b2d8fb23ee60aa5892915fe690b。本机和公网健康检查均为 ok，公网正文已包含本轮结论；该发布未改变 Runtime、验证器或 P5 行为。

🧾 2026-08-12：阶段四审核 JSON 围栏规范化与生产验证

• fd0ab6d 只把单个完整 JSON 代码围栏规范化为既有审核契约；附加文字、多个围栏、缺少标准、伪造证据和缺少确定性检查继续拒绝。Runtime CI 31593967181 与独立复核 31594040577 均成功，部署前 SQLite 备份 SHA-256 为 690c99072e00c3920c97abe1b43ec40ecab1fae0f6e429f1e21e0479ee2c397b。
• 首次正式部署在 Worker 预加载出现瞬时镜像检查异常，发生在 Runtime 替换前。随后只读确认 101、103 均存在预期镜像且非 root 导入测试通过，重跑正式脚本后复用两侧镜像并成功部署；Runtime 健康、私网拓扑、旧数据和 SQLite quick_check 均通过，验证器与自动执行保持关闭。
• 新返工任务 ecd6247fcf474aa1 的一次显式派发和同键重放只产生一个运行。AI BOSS 审核实际产生可解析 json_fence，两条 boss.review/v1 均记录为 insufficient_evidence；确定性检查器关闭导致任务安全失败，未自动验收、未释放下游、未继续自动重试。该项证明格式修复有效而硬门槛未被绕过，下一步转入确定性检查器受控灰度。

🧾 2026-08-12：阶段四 Runtime 确定性检查器受控灰度

• 部署前备份为 /var/lib/agentmeshos/ai-runtime/backups/runtime-pre-p4-verifiers-gray-20260812T120445Z.db，SHA-256 为 a5eee43bfedfd5131c4f7cdaf88b44e7bf799d2ac6c5f64ac36f7a5a9810ce06。生产容器实际加载 AI_RUNTIME_P4_VERIFIERS_ENABLED=true；智能规划、只读和安全预览保持开启，AI_RUNTIME_P4_AUTO_EXECUTION_ENABLED=false，P5 未启用。
• 使用新的幂等键对 ecd6247fcf474aa1 的 SQLite JSON 成果 3a34d2b2ef23411e8dfed3010545d19e 显式检查。Runtime 回读 271 bytes，SHA-256 b736434569a0338a1c7fc8e9882bb8150b62e4a6acb4289ed56e21efb04feafc，并通过大小、哈希、文件头、UTF-8 和 JSON 五项检查；检查运行为 e84216c95a00400e836f674517bdbbce，真实可访问证据为 a944e08b8c964034a4fe10c1b3d99da6。
• 立即以同一 client_request_id 重放，返回同一检查运行且数据库只保留一条对应记录。任务继续保持 failed，没有调用模型、自动验收、下游释放或自动重试；SQLite quick_check=ok，数据库和环境文件均为 root:root 0600。该结论仅代表轻量确定性检查器灰度通过，不能代表 AI 审核、Benson 决定或 P4 完成。

🧾 2026-08-12：阶段四仅重新审核入口与真实最终验收

• 29d9507 新增 Benson 显式 POST /boss/v1/tasks/{task_id}/retry-review。它只针对已执行、必需确定性标准已通过但审核失败的 P4 任务，复用成果/证据，不重跑 Worker 或 Nomad；请求在 task_action_requests 中以 retry_review 和 client_request_id 幂等记录。
• 首次生产重新审核调用真实返回 AI BOSS 两条 passed，也完成了最终验收，但下游 Envelope 准备异常被旧逻辑抛回入口，导致上游错误显示 failed。该真实失败暴露状态机缺陷，而非证据或模型问题；没有新增 Worker/Nomad 运行。
• 7e41d67 修复下游激活异常隔离：只有真正 queued 的 P4 任务进入后续激活，后续失败只写自身事件，不得覆盖已完成上游；同时重新审核异常不覆盖已经完成的最终验收。Runtime CI 31596777806 成功，生产镜像为 sha256:38fe713924238585ac21297eb4df18ce416b186789921150c72bb6f0f9f228d2。部署前备份 /var/lib/agentmeshos/ai-runtime/backups/runtime-pre-downstream-activation-fix-7e41d67-20260812T123502Z.db，SHA-256 aa1bbe20734dc4bde129c3ebf7d980215d0fd9bad59571699798ae1a254a73aa。
• 第二次新幂等键调用使 ecd6247fcf474aa1 最终为 completed；同键重放返回 replayed=true，task_runs=1、executions=1，SQLite quick_check=ok，AI_RUNTIME_P4_VERIFIERS_ENABLED=true、AI_RUNTIME_P4_AUTO_EXECUTION_ENABLED=false。该项完成单任务确定性检查、AI BOSS 审核、最终验收和幂等恢复闭环，不代表 P4 全部完成。

🧾 2026-08-12：阶段四 Console 仅重新审核控制发布

• bbae71d 在任务工作台增加“重新审核”按钮：仅失败的 p4-v1 任务可点击，Console 使用 client_request_id 调用 retry-review；按钮文案明确它不会重跑 Worker 或 Nomad，后端继续验证确定性证据和任务状态。
• Console 浏览器契约通过，覆盖按钮资格、Runtime 请求路径、幂等键、桌面与 390×844 移动布局。Console CI 31597996152 成功，生产镜像摘要为 sha256:c8e264aa28cd5b7c8972fde6e3af58ba35e78ee364bdd5bd93e416bf279e4c6b，容器健康。
• 公网未登录入口仍按预期跳转 A-Auth，直接会话接口返回 401；Runtime 自动执行仍为 false，P5 未启用。

🧾 2026-08-11：阶段四 AI BOSS 核心改造完成归档

• 计划 ID：phase-4-ai-boss-core-upgrade-completed。
• 状态变化：阶段四完成并归档；当前阶段切换为阶段五“规划中，尚未实施”。此状态切换不启用主动循环、定时唤醒、后台模型调用或新的系统动作。
• 完成证据：Runtime 49 passed；Gateway 告警、目录和公开状态契约；Console 浏览器契约；严格 Docs 构建与计划状态检查；生产管理员会话的 OmniRoute 流式/取消、公开 Codex CLI 完成/取消、真实附件粘贴上传、Cloudreve 回读和多模态识别均已通过。
• 恢复证据：生产交互 4e0986f03a204741a90f 在首 SSE 连接进入 streaming 后主动断开，第二连接恢复持久化文本并 completed，真实用量 8946 Token、estimated=false；Runtime 集成测试覆盖重启将未完成交互标为 interrupted、会话/任务图恢复与 Nomad Envelope 重建。
• 后续边界：阶段五可以开始受控主动工作循环的实施规划，但尚未实施；阶段六继续等待阶段五完成并归档。

🧾 2026-08-06：阶段四至阶段八正式重排

• 计划 ID：phase-renumber-p4-p8。
• 项目负责人决定：当前 AI BOSS 核心能力、工作台与 API Gateway 可见性改造正式定义为阶段四，不再称为“P4 前置”；阶段四完成并归档后，阶段五单独实施 AI BOSS 受控主动工作循环。
• 后续顺延：原阶段四“第一个 AI 应用的发现与试验闭环”调整为阶段六，原阶段五“第一个 AI 应用 MVP”调整为阶段七，原阶段六“应用扩展”调整为阶段八。
• 顺序边界：阶段五不得在阶段四完成前启动；阶段六不得越过阶段五。阶段五只建设 Benson 预先启用、可暂停、可终止、有硬预算和完整审计的主动工作引擎，不开放任意系统动作、外部业务写入或无限重试。
• 兼容策略：旧 phase-4-discovery-experiments.md、phase-5-application-mvp.md 和 phase-6-application-expansion.md 路径保留为明确的重排兼容入口，权威计划分别迁移到阶段六、阶段七和阶段八页面。

🧾 2026-08-06：AI BOSS 核心能力改造成为 P4 前置当前计划

• 计划 ID：phase-4-pre-ai-boss-core-upgrade。
• 状态变化：阶段四内部当前执行从“第一个 AI 应用的发现与试验闭环（规划中）”切换为“AI BOSS 核心能力、工作台与 API Gateway 可见性改造（进行中）”；原阶段四应用计划保留并顺延，不取消、不覆盖历史。
• 主要范围：先解决发送无即时反馈和响应缓慢，再完成持久交互、SSE、幂等、Token 硬预算、上下文、长期记忆、结构化规划、任务恢复、工作台重构、剪贴板/附件、多模态和 API Gateway 可见性。
• 架构边界：API Gateway 继续是 Console、Status 和运维状态/告警聚合层；AI BOSS 经主节点认证回源代理直达 AI Runtime；CLI Agent Gateway 只提供显式、public 数据的固定备用推理，不形成第二控制面或 Provider Router。
• 完成口径：文档进入当前计划不代表代码、数据库迁移、部署或公网验收完成；以上证据全部通过后才恢复原阶段四应用工作。

🧾 2026-08-05：Claude AgentRouter 认证纠正与双模型启用

• 计划 ID：ai-boss-cli-agent-fallback。
• 根因：原 Gateway 为 Claude Code 同时设置 ANTHROPIC_AUTH_TOKEN、ANTHROPIC_API_KEY 并使用 --bare，偏离 AgentRouter 官方要求的 Bearer Token 配置；当时 claude-opus-4-8 返回 Insufficient balance，claude-opus-5 返回 OpenRouter Insufficient credits。不能据此判定模型不可用。
• 修复：Gateway v0.2.1 只注入 ANTHROPIC_AUTH_TOKEN 和不带 /v1 的根 Base URL，移除 --bare；每次调用使用独立 /tmp/claude-* HOME 并在结束后清理。新增认证变量、命令参数和清理行为测试，Gateway 共 7 passed。
• 生产验收：claude-opus-4-8、claude-opus-5 均先通过隔离官方 CLI，再分别通过生产 Gateway 和正式 Boss API，全部返回精确 OK；Gateway 审计状态均为 completed，无错误码。Runtime 模型目录对 OmniRoute、Codex 和两个 Claude 均返回 available=true。
• 发布证据：Git revision 3bd60ef3e01acd1cbb3471ab445e9520c1759293 的 GitHub Actions run 31016086434 成功；生产镜像 digest 为 sha256:3453ed5179f43c17cfb61123d2d8b53361d4988a660945b7b4d4d21ec76f7639，Gateway healthy、版本 0.2.1、available_backends=3。
• 最终重建：文档同步提交 64c1021c92bf832f2a1fe5bad69b8b4a583a1b7f 触发同源码镜像重建后，当前生产 digest 更新为 sha256:7e79b3f412c9a5704f4befb3bfd43a68af10473dc39dc73762a7276291da4333；重新部署后两个 Claude 再次分别经正式 Boss API 返回精确 OK，runtime_call_id 为 846c91ad172f47af83a30229cfd8235c、ca0ecbaf7cca469cb5a78a6fd8e450ef。
• Console：生产 app.js 与仓库摘要一致，两个 Claude 选项会按 Runtime 返回的 available=true 启用；公网未认证入口仍跳转 A-Auth。CLI_GATEWAY_ENABLE_CODEX、CLI_GATEWAY_ENABLE_CLAUDE_OPUS_4_8、CLI_GATEWAY_ENABLE_CLAUDE_OPUS_5 当前均为 true，默认仍为 OmniRoute且不自动回退。
• 回滚：变更前 root-only 环境备份位于 /etc/agentmeshos/backups/cli-agent-gateway.env.before-claude-20260805T223922；部署脚本同时保留旧镜像 rollback 标签。任一模型后续失败时单独关闭其开关并重部署，不影响 OmniRoute 默认链路。

🧾 2026-08-05：OmniRoute Discovery 历史窗口与连续失败阈值

• 计划 ID：omniroute-controlled-discovery-history。
• 原因：旧实现只保留最近结果，单次超时、限流或上游错误会立即把 Provider 标记为 rejected，无法区分偶发故障和持续不可用。
• 实现：Bridge v0.2.0 增加独立追加式 SQLite 历史事实库、最近 10 次成功率/连续失败/延迟统计；可恢复故障连续少于 3 次保持 pending，连续 3 次或明确永久错误才 rejected。历史库不保存凭据、Cookie、请求正文或 Prompt，也不承担 Provider Registry 职责。
• 生产验收：Bridge、OmniRoute 和 timer 状态正常，公网未登录精确路由返回 401；两轮复测写入 18 条事实，9 个 Provider 各 2 条，官方结果为 4 verified / 3 pending / 2 rejected，主库与历史库 quick_check=ok。部署脚本已修复为显式重启常驻 Bridge，避免新源码安装后旧进程继续运行。
• 边界：窗口统计只供观察和人工审查；没有启用自动告警、自动修改 Combo、自动修复 Provider 或高频扫描，也没有发现无限制访问方式。

🧾 2026-08-04：AI Boss 执行过程与真实模型详情

• 计划 ID：ai-boss-process-observability。
• 背景：Discovery 价值评估已真实提交给 AI Boss，实际由 kr / claude-sonnet-4.5 返回；模型在回复中错误声称能够读取文件、修改代码和执行 shell/Git，暴露了“最终回复”和“系统真实能力”之间的证据缺口。
• 实现：Runtime v0.5.1 为 Boss 请求生成 interaction_id，追加请求接收、通道检查、模型调用、任务创建和回复完成事件；Console 增加过程时间线，展示状态、Provider、模型、通道、耗时、Token、调用 ID 与任务引用。
• 安全：过程接口不保存或返回隐藏思维链、完整 Prompt、凭据、基础地址或主机配置。能力判断只使用 Runtime 注册接口、Adapter、白名单工具和生产验收，不采信模型自述。
• 当前状态：仓库实现和 23 项 Runtime 测试、Console 契约及 JavaScript 检查已通过；生产 Runtime v0.5.1 与 Console 容器均健康，真实请求的阶段、实际 Provider/模型、Token、耗时和调用引用已进入“执行过程”页面。

🧾 2026-08-04：OmniRoute Compression 隔离复评

• 计划 ID：omniroute-compression-reassessment。
• 状态：隔离评估完成，生产保持关闭。
• 方法：只调用官方 OmniRoute 3.8.49 的 /api/compression/preview 和 /api/context/rtk/test，不修改源码、不写入生产 Compression 配置；样本放在仓库 temp/，完成后清理。
• 结果：Lite、RTK、RTK -> Caveman、Lite -> RTK 在混合样本上约节省 70.54%~73.14% Token，但保真校验未通过。Lite 在错误/结构化样本中删除关键标记；RTK 对 Docker 构建样本没有保留 exit code: 2；RTK 压缩的大型 JSON 变成 OmniRoute 截断标记或不可直接解析的内容。
• 生产状态：enabled=false、defaultMode=off、activeComboId=null，compression_analytics 仍为 0；Boss 请求响应头明确为 X-OmniRoute-Compression: off，Boss 与 Worker 正式 Combo 均真实返回预期文本，Worker 本次 SSE 上游未回显该响应头。OmniRoute healthy、版本 3.8.49、SQLite quick_check=ok。
• 决定：不启用全局压缩，不创建或绑定 Compression Combo，不修改 Boss/Worker 路由。下一次只在官方排除规则足以保护 JSON、错误、代码、路径和验收数字后复评 RTK minimal；Caveman、Aggressive、LLMLingua、Ultra、OmniGlyph、CCR 继续关闭。

🧾 2026-08-04：OmniRoute Discovery 受控展示与每日复测

• 计划 ID：omniroute-controlled-discovery。
• 仓库与部署：新增 Python 标准库 Bridge、固定 Provider allowlist、测试和 systemd 部署脚本；服务只监听 127.0.0.1:39183，main 私有回源只代理 /api/discovery/results 与 /api/discovery/scan。
• 数据：官方 discovery_results 已写入 9 条最近结果，4 条 verified、5 条 rejected；写库前保留 SQLite 快照，结果明确标记 success_is_not_unlimited_access。
• 周期：每日 timer 已启用并完成两轮真实运行；下一轮计划为 2026-08-05 23:15 CST 左右。复测不自动新增连接、调整 Combo 或绕过服务商限制。
• 验收边界：Bridge、写库、timer、BaoTa Nginx 配置和公网未认证接口均已验证；不读取或伪造管理员浏览器 Cookie，因此官方“发现”页面最终可见性由管理员刷新已登录页面确认。

🧾 2026-08-04：AI Boss AgentRouter CLI 备用通道仓库实现

• 计划 ID：ai-boss-cli-agent-fallback。
• 状态：已完成仓库实现、本地隔离验收、生产部署和真实全链路；Codex 已启用，Claude 保持禁用。
• 架构：OmniRoute 保持默认和唯一通用 Provider 核心。AgentRouter 不进入 OmniRoute Provider 列表，也不由 Runtime 直接请求 HTTP；固定链路为 Runtime -> CLI Agent Gateway -> Codex CLI / Claude Code CLI -> AgentRouter。
• Console：AI Boss 对话区已增加模型通道选择器；OmniRoute（默认） 可选，三个 AgentRouter 固定候选可见。Runtime 返回 available=false 时，Console 显示原因并禁用，不执行自动回退。
• 安全：Gateway 只接受 public 数据与固定后端 ID，Prompt 走标准输入；不接受 cwd、任意参数、环境、MCP 或工具，不挂载仓库、HOME、Docker、Nomad、Storage 或 SSH。子进程独立进程组，具备超时 TERM/KILL、2 MiB 双流上限、并发限制和脱敏 SQLite 调用记录。
• 验收：Runtime 测试 22 passed，Gateway 测试 5 passed，Console 本地及公网嵌入契约通过；本地镜像以非 root、只读根文件系统、无宿主机端口运行，健康、按开关暴露后端和持久审计数据库验证通过。临时隔离网络中的 Runtime v0.5.0 已读取 Gateway 目录并通过 Codex 完成 AI Boss 对话，返回精确 OK。
• 真实 Smoke：Codex gpt-5.6-sol 返回精确 OK、退出码 0、无错误事件；隔离 Gateway 返回相同结果并持久化最小审计。Claude claude-opus-4-8、claude-opus-5 均返回 HTTP 402。
• 生产部署：Gateway、Runtime v0.5.1、Console 和 Docs 均健康且重启次数为 0。生产模型目录返回 OmniRoute 与 Codex 可用、两个 Claude 不可用；通过正式 Boss API 选择 Codex 后返回精确 OK，Gateway 审计为 completed，AI Boss 执行过程包含 received/model_call/completed。
• 镜像证据：Gateway sha256:50e3812c195abf28f91d5ddc8fc8882b5214e58423ecf95acba35e6294f5b45a，Runtime sha256:3c2521b7deda5651865170a445cbdec25097b154b2f1afdd71964b0c0ef94326，Console sha256:147f477ad98bd894683ed5be6b30c18bab8eab47d23e389f94270772e8c5f65d，Docs sha256:f8c1f6d0ae44cd16dfe58f53f887dbc8937e8818e0d3bc63b3a9d185bc2707c9。
• 最终边界：CLI_GATEWAY_ENABLE_CODEX=true；两个 Claude 开关保持 false。OmniRoute 继续是默认和唯一通用 Provider 核心，Codex 只在 Benson 显式选择时调用，不改变默认链路。

🧾 2026-08-04：OmniRoute 管理与模型 API Key 职责分离

• 计划 ID：omniroute-api-key-separation。
• 状态：普通模型 Key已完成生产创建和权限验收；Runtime 最小权限切换受官方 3.8.49 MCP 鉴权限制，保持部分完成。
• 已完成：保留 agentmeshos-runtime-admin 管理 Key；创建 agentmeshos-model-client，只允许 chat/models、agentmeshos-free-quality-first、agentmeshos-free-capacity-pool 与 self:usage。两个 Combo 真实调用返回 MODEL_KEY_OK；直接模型与 /api/keys、/api/combos 均被拒绝。
• 官方限制：/api/mcp/tools 与 /api/mcp/stream 使用带 mcp:connect、读取和执行 scope 的普通 Key仍返回 403 AUTH_001。因此没有给普通 Key添加 manage 冒充最小权限，也没有让 Runtime 丢失已验收的 MCP 搜索/抓取；runtime-call.env 暂时继续使用管理 Key。
• 凭据边界：管理、Runtime 兼容和普通模型凭据均为主节点 root:root 0600；不进入 Git、日志、浏览器、Agent 或 101/103 Worker。
• 备份：本机完整未脱敏 TAR /backup/agentmeshos/omniroute-key-split-20260804T143210Z/omniroute-key-split-20260804T143210Z.tar，大小 96942080 bytes，SHA-256 401b5078cb2e95691d09eed2af9b9e82bd5dfa30bd0a2b082bf822ef48229c7e；已通过标准 WebDAV PUT 上传并回读到 cloud.yohan.fun/dav/AgentMeshOS-长期/OmniRoute-Key-Split-20260804T143210Z/，远端 SHA-256 一致。旧 rclone 远端因 DNS/凭据失效未使用。

🧾 2026-08-04：OmniRoute Combo、Provider 与历史告警收口

• 计划 ID：omniroute-provider-alert-maintenance。
• 状态：已完成生产配置、真实调用和告警生命周期验收。
• Combo：通过官方 API 删除无运行引用的旧 agentmeshos-free-priority 和 agentmeshos-free-fusion，保留其 52 条历史调用；当前只保留 Boss quality-first 与 Worker capacity-pool。UncloseAI 从 8 月 2 日起持续返回上游 502，其三个候选从两个正式 Combo 移除，连接本身保留供后续复测。
• Provider：截图中的 7 个红色节点逐项重测后，Alibaba、Black Forest Labs、FriendlyAI、LLM7、SenseNova 已恢复 active；MiMoCode 为官方 3.8.49 模型映射/验证适配问题，UncloseAI 为持续上游 502。灰色 HuggingChat 保持停用。当前两个 Combo 各 195 个候选、覆盖 24 家 Provider，真实调用均返回 ROUTE_OK。
• 告警：6 条待处理记录均为已修复或已退役链路的历史事件；逐条追加根因和证据后标记 completed，未删除原始记录。收口后 pending/processing/failed/needs_benson_decision 均为 0。
• 当前基线：官方 omniroute@3.8.49 与 Runtime 均健康；52 条连接、51 个 Provider、2 个 Combo、2 个 API Key，SQLite quick_check=ok。历史迁移和旧调用事实继续保留，不用当前数字覆盖。

🧾 2026-08-04：OmniRoute 双角色免费路由优化

• 计划 ID：omniroute-role-routing-optimization。
• 状态：已完成生产配置与真实调用验收。
• 结论：Runtime 不再让 Boss 和 Worker 共用旧 agentmeshos-free-priority。Boss 使用官方 fill-first Combo agentmeshos-free-quality-first，按质量顺序优先 GPT/Codex、Claude 和 O3；Worker 使用官方 least-used Combo agentmeshos-free-capacity-pool，按每个模型和账号的实际调用次数均衡免费容量。
• 候选：从官方免费 coding 候选中保留 198 个可执行目标、覆盖 25 家 Provider；排除 44 个已有明确证据的失效目标，包括 Provider 映射/凭据缺失、账户暂停、订阅限制、模型不存在和认证/余额错误。Provider 和凭据本身未因本次 Combo 调整被删除。
• 安全边界：两个 Combo 均关闭 session stickiness，启用模型不存在/需要订阅正文的响应质量拦截；只使用官方 API 和官方策略，未修改 OmniRoute 源码或 SQLite。
• 真实证据：Boss 5 次调用全部 HTTP 200，其中 4 次为 gpt-5.3-codex、1 次回退 O3；Worker 8 次调用全部 HTTP 200，按 least-used 依次覆盖 Codex、O3、Claude Sonnet、Claude Opus 和 GPT-4o。
• 生产 Runtime：AI_RUNTIME_OMNIROUTE_BOSS_MODEL 已切换为 agentmeshos-free-quality-first，AI_RUNTIME_OMNIROUTE_WORKER_MODEL 已切换为 agentmeshos-free-capacity-pool；容器重建后健康且重启次数为 0。生产 Boss Smoke 命中 gpt-5.3-codex，生产 Worker Smoke 在两个失败候选后由官方 Combo 自动回退到 deepseek-v3.2 并成功，OmniRoute 调用日志记录了正确 Combo 和高权限 Runtime Key 名称。
• 回归：Runtime 自动化测试 20 项通过；只读 Provider 视图返回正确双 Combo、OmniRoute healthy 和 636 个模型目录条目。
• 当时基线：官方 omniroute@3.8.49 健康；52 条连接、51 个 Provider、4 个 Combo、2 个 API Key，SQLite quick_check=ok。历史 53/52/2/1 继续作为 2026-08-03 原生迁移和正式备份验收事实；后续 Combo 收口见本页更新条目。

🧾 2026-08-03：阶段三 P3-8、P3-12 完成归档

• 计划 ID：phase-3-runtime-mvp。
• 状态：阶段三已完成并归档，当前转入阶段四。
• 结论：官方 OmniRoute MCP Streamable HTTP 已完成健康、搜索、抓取、边界拒绝和失败审计引用真实验收；多 Agent、Artifact、凭据隔离、Guardrails、Evals、重启恢复和 Job 清理通过。
• Compression：同样本预览节省 0%，未达到 20% 门槛，生产保持关闭，不阻塞阶段出口。
• 归档：阶段三完成归档。
• 后续动作：进入阶段四：第一个 AI 应用的发现与试验闭环。

🧾 2026-08-03：阶段四发现与试验闭环启动规划

• 计划 ID：phase-4-discovery-experiments。
• 原状态：阶段三已完成并归档。
• 新状态：规划中。
• 结论：阶段四复用薄 Runtime、Nomad、Cloudreve Artifact、官方 OmniRoute 和业务账本，先进行合法公开来源的机会发现、去重、初筛和受控试验，不预设固定赛道。
• 当前记录：阶段四预备页。

本页只追加阶段、计划和归档状态变化；不复制完整正文。完整证据始终链接到当前记录或独立归档文件。更正旧结论时新增更正记录，不改写已有记录。

🧾 2026-08-03：P3-7、P3-9、P3-10、P3-11 生产验收归档

• 计划 ID：phase-3-runtime-mvp。
• 状态：P3-7、P3-9、P3-10、P3-11 已完成并归档；P3-8 部分完成，P3-12 进行中。
• 结论：持久 Agent Registry、任务依赖门控、长期 Artifact、业务成本/收益账本和 Console 关系视图已部署并通过生产验收。
• 证据：父子任务依赖后执行并清理；Cloudreve Artifact 写入/回读/SHA-256；ToolAdapter 健康调用审计；101/103 Worker 凭据隔离；17 项 Runtime 测试；Runtime、Console 与 Docs 健康。
• 归档：Runtime 编排与适配器。
• Git 提交：bf8189e、df0a478、7da4ead。
• 后续动作：只继续 P3-8 官方 MCP 搜索/抓取真实接入和 P3-12 Compression 质量门槛；不得伪造官方工具或在 Runtime 自研替代能力。

🧾 2026-08-03：101 隔离与旧底座临时材料清理

• 计划 ID：phase-3-runtime-mvp-cleanup。
• 状态：已完成。
• 结论：P3-7.0 隔离验收已经完成，后续卡住的冗余 npm 进程没有验收价值；已终止进程并清空 101 的项目 temp/。
• 清理范围：旧 OmniRoute 隔离副本、旧 KodBox/JuiceFS/Galera 材料、WebDAV 测速文件、npm 测试和其他明确位于项目临时目录的历史中间产物。
• 保留范围：主节点 /root/.omniroute 正式数据和 Cloudreve AgentMeshOS-长期 正式备份未修改。
• 清理结果：101 项目 temp/ 与主节点仓库 temp/ 均为 0 个条目；主节点约清理 6.7 GiB。清理后 OmniRoute 仍为 active，健康基线仍为 53 条连接和 52 个 Provider。
• 正式备份：/backup/agentmeshos/omniroute-root-native-admin-20260803T035230Z.tar 保留，SHA-256 为 716fb95e23cb93aba362df3548e9f48a5112ca9c98bdd29e9ba0b5421ef0cfa3；归档自身清单为 53/52/2/1、迁移 133、quick_check=ok。

🧾 2026-08-03：P3-7.3 Runtime 免费候选目录退役

• 计划 ID：phase-3-runtime-mvp。
• 状态：P3-7.3 已完成生产部署验收；P3-7.0 继续进行，下一项为官方 Guardrails、Evals、Compression 与 MCP 隔离验收。
• 结论：Runtime 已删除 free_catalog.py、本地价格表、免费来源同步/健康/发现 Worker、候选发现 API 和 free_ai_sources、free_ai_source_models、free_ai_source_checks 三张运行表。公开多 URL 的读取、解析、去重和计算继续使用 source-research/v1；批处理结果分析统一标记为 omniroute_analysis。
• 生产证据：Runtime SQLite 仅留下 free_source_catalog_retired 事件，计数为 80/512/11，三张表不存在；旧候选发现和免费路由 API 均返回 404；101/103 使用同一新 Worker 镜像 ID；Runtime 健康通过。
• OmniRoute 边界：未修改 OmniRoute 源码或 Provider 数据。原生 SQLite 核对为 53 条连接、52 个 Provider、2 个 Combo、1 个高权限 API Key，quick_check=ok。
• Git 提交：32e7a78；AI Runtime 与文档站 GitHub Actions 均构建成功。

🧾 2026-08-02：薄 Runtime + OmniRoute 架构收口与 3.8.49 隔离复核

• 采用官方 OmniRoute 作为唯一 Provider/模型/协议/连接/Combo/健康/用量核心，AgentMeshOS Runtime 收缩为业务策略、任务图、Nomad、业务成本、告警和 OmniRouteAdapter 桥接。
• 使用真实生产数据副本和原始加密密钥完成官方 3.8.49 隔离迁移复核：迁移 133、容器健康、认证 Provider API 为 53 条连接/52 个 Provider、SQLite quick_check=ok；此前启动早期的 0 条摘要确认是加载竞态。
• 生产继续固定官方 3.8.48，未执行生产升级、Provider 删除或 Runtime 重复能力删除。完整未脱敏备份仍保留本机与 Cloudreve 长期目录。

🧾 2026-07-26：阶段二架构重整归档

• 计划 ID：phase-2-architecture-reorganization
• 原状态：架构讨论中
• 新状态：已完成归档
• 结论：底座、单用户轻量控制面、通用 AI Runtime、AI 免费层和可插拔应用边界已完成文档收口；不代表 Runtime 已实现。
• 归档：阶段二：架构与文档库重整
• 证据：提交 e41419b
• 后续动作：进入阶段三整体可行性评估。

🧾 2026-07-26：阶段三整体可行性评估启动

• 计划 ID：phase-3-feasibility
• 原状态：未开始
• 新状态：进行中
• 结论：只评估机会、自动化、结果回收、成本收益、AI 免费层和失败退出，不实现 Runtime。
• 当前记录：阶段三整体可行性评估
• 证据：提交 5abdfff
• 后续动作：形成 可进入 Runtime MVP、需要补证据 或 不可行，停止 之一。

🧾 2026-07-26：完成归档主题化迁移

• 计划 ID：archive-topic-migration
• 原状态：全部完成事项集中在 completed.md
• 新状态：每个主题独立归档，completed.md 仅保留总览与旧锚点入口
• 结论：历史事实不再随着当前计划滚动而隐藏或覆盖。
• 归档清单：archive-manifest.json
• 后续动作：后续计划完成时，先追加本页，再创建 completed-*.md 并更新状态源。

🧾 2026-07-26：阶段三首轮证据基线

• 计划 ID：phase-3-feasibility
• 原状态：进行中（无结构化证据结论）
• 新状态：进行中（首轮证据基线完成，结论为需要补证据）
• 结论：公开 GitHub API 可作为受限的机会数据候选；GitHub 写入/外部动作、真实业务结果和经济闭环尚无证据。OmniRoute 为已发现、待评估、未部署的候选，其上游额度和能力声明未在 AgentMeshOS 独立验证。阶段三不得进入 Runtime MVP。
• 当前记录：阶段三整体可行性评估
• 证据：GitHub REST API 限流、最佳实践、条款和可接受使用政策；OmniRoute 公开仓库、免费层参考与安全说明；本次只读公开 API 样本。
• 后续动作：确定合法代表性样本后，依评估记录的固定顺序补齐数据质量、平台边界、业务/经济回收、Provider 与失败退出实测。

🧾 2026-07-26：阶段三机会发现职责更正

• 计划 ID：phase-3-feasibility
• 原记录：将代表性机会样本写成“由 Benson 先选择”。
• 更正：机会发现、候选去重、初筛和证据登记由 AI 研究任务主动完成；Benson 只设定合法、预算、数据与风险边界，并对真实外部业务动作作最终决定。
• 原因：要求项目负责人手工寻找机会与 AgentMeshOS 建设 AI 自动化应用的目标冲突。
• 当前记录：阶段三整体可行性评估
• 后续动作：阶段三继续用受控只读发现任务形成候选台账，不得将人工作为系统的机会发现前置条件。

🧾 2026-07-26：取消旧阶段三整体可行性评估

• 计划 ID：phase-3-feasibility
• 原状态：进行中，作为 Runtime MVP 的整体可行性与 Go/No-Go 门禁。
• 新状态：已取消，保留为旧 URL 的历史记录。
• 结论：旧阶段要求在 Runtime 存在前证明 AI 能自主发现机会，形成循环依赖，并把系统要实现的能力错误地变为开工前置条件。原有调查证据继续保留，但不得阻止 Runtime 或限制 AI 寻找方向。
• 当前阶段：新阶段三：通用 AI Runtime MVP，状态为规划中。
• 后续动作：路线重新编号为六阶段；机会、成本、结果和收益在 Runtime 与应用的持续运行中记录和复盘。

🧾 2026-07-26：新阶段三通用 AI Runtime MVP 启动

• 计划 ID：phase-3-runtime-mvp
• 原状态：未开始
• 新状态：规划中
• 结论：首个真实闭环是 Boss Agent 与研究 Worker 的只读机会发现、去重、初筛和候选登记；不要求 Benson 手工提供机会，不执行外部写入、交易或付费动作。
• 当前记录：阶段三：通用 AI Runtime MVP

🧾 2026-07-26：阶段三进入实现

• 计划 ID：phase-3-runtime-mvp
• 原状态：规划中
• 新状态：进行中
• 结论：已开始实现主节点 Runtime、Nomad/Worker 接入、Console Boss 工作区与底座接入自动校验；尚未完成生产部署与真实机会发现验收。
• 相关记录：阶段三当前计划
• Git 提交：本次变更提交待生成
• 证据：Runtime 单元测试、Nomad HCL validate、Console/计划状态静态检查
• 后续动作：完成镜像构建、主节点部署、101/103 无凭据 Smoke 和公网 Console/Docs 验收
• 后续动作：单独确认最小 Runtime 实施计划后转入执行。

🧾 2026-07-26：阶段三首个真实只读 Nomad 闭环

• 计划 ID：phase-3-runtime-mvp
• 原状态：进行中（实现与静态验证）
• 新状态：进行中（首个真实分布式只读闭环通过）
• 结论：Benson 对话触发任务 209fd4bd207744ae；Nomad Job 分配到 pcdell-101，固定 Worker 读取唯一允许的 GitHub 公开 API 并回传 1 个结构化候选、证据引用和 55141 字节读取摘要。Runtime 完成 Schema/一次性 Token 校验，Boss 审核接受，Job 已清理且 Nomad 查询确认不存在。
• 安全证据：Runtime 专用 Docker bridge 仅放行其静态地址到 Nomad HTTPS；Worker 不持有 GHCR、Provider、Nomad 或 Storage 凭据；仅伪造 X-Auth-Role: admin 的 Tailnet Boss 请求返回 401。
• 相关记录：阶段三：通用 AI Runtime MVP
• Git 提交：7cbf95d
• 后续动作：继续完成 Console 管理员交互、恢复/并发及 Docs/Console 公网发布验收；阶段三完成前不转入阶段四。

🧾 2026-07-26：阶段三修正、恢复与并发回归

• 计划 ID：phase-3-runtime-mvp
• 原状态：进行中（首个真实分布式只读闭环通过）
• 新状态：进行中（修正、恢复与并发回归通过）
• 结论：Boss 驳回结果后会创建带原任务依赖、反馈和关联 ID 的持久化修正任务；SQLite Runtime 重启后可恢复 Benson 会话和任务图；四个 Worker 的并发一次性回传保持任务隔离。该质量反馈机制不是批准单、人工申请或运行门禁。
• 相关记录：阶段三：通用 AI Runtime MVP
• Git 提交：c3e18f1
• 证据：ai-runtime/tests 自动化回归，覆盖修正任务、重启恢复与四路并发回传。
• 后续动作：部署此改动并完成 Runtime 重启持久化实测；Benson 使用既有管理员登录完成 Console 真实交互验收。阶段三完成前不转入阶段四。

🧾 2026-07-26：阶段三 Runtime 旧库迁移修复

• 计划 ID：phase-3-runtime-mvp
• 原状态：进行中（修正、恢复与并发回归通过）
• 新状态：进行中（旧库迁移写入已修复）
• 结论：生产 SQLite 在新增 rework_task_id 前创建，列通过迁移追加在表尾；原未列名写入会使旧库的新任务创建失败。已改为显式列名写入，并新增旧库迁移后创建任务的自动化回归。
• 相关记录：阶段三：通用 AI Runtime MVP
• Git 提交：2302970
• 证据：ai-runtime/tests 共 10 项通过，包含旧数据库升级路径。
• 后续动作：部署补丁后完成真实“驳回、修正、接受、清理”闭环；阶段三完成前不转入阶段四。

🧾 2026-07-26：阶段三真实 Boss 修正闭环

• 计划 ID：phase-3-runtime-mvp
• 原状态：进行中（旧库迁移写入已修复）
• 新状态：进行中（真实 Boss 修正闭环通过）
• 结论：只读任务 b107bce4ce49445e 使用允许的 GitHub 公开 API 回传后进入 Boss 审核；Boss 驳回自动创建关联修正任务 a6a6104c94484324。修正任务回传后被 Boss 接受，两个 Nomad Job 均已清理。全程未执行外部写入、交易或付费动作。
• 相关记录：阶段三：通用 AI Runtime MVP
• Git 提交：f38ab63
• 证据：主节点 Runtime、Nomad Worker 回传、Boss 审核和内部 Job 清理接口的真实演练。
• 后续动作：Benson 使用既有管理员登录完成 Console 真实交互验收；阶段三完成前不转入阶段四。

🧾 2026-07-26：阶段三 Boss 自动审核与 Console 验收

• 计划 ID：phase-3-runtime-mvp
• 原状态：进行中（真实 Boss 修正闭环通过）
• 新状态：进行中（Console 到自动审核闭环通过）
• 结论：Worker 回传后 Runtime 调用受控 Provider Router 审核必填结果与证据，通过则自动完成，不足则创建关联修正任务。Runtime 重启时只重新审核遗留的 待 Boss 审核 任务，不重跑 Worker。Benson 已用既有管理员登录在 Console 发起任务 0e474350b34940b2；消息、SSE、Worker 回传和自动审核均已验证，任务最终完成且 Nomad Job 已清理。
• 限制：当前未配置真实模型凭据，审核使用 deterministic-demo 的保守降级规则；这不代表 Premium Provider 已接入。
• 相关记录：阶段三：通用 AI Runtime MVP
• Git 提交：52bbd86
• 证据：12 项 Runtime 自动化测试、主节点 Runtime 重启、Console 实际管理员会话、SQLite 审核事件与 Nomad Job 清理。
• 后续动作：继续完成阶段三剩余的真实 Provider 接入、成本策略和更完整的多 Agent 任务能力；阶段三完成前不转入阶段四。

🧾 2026-07-26：P3-5 Provider 管理与真实调用启动

• 计划 ID：phase-3-runtime-mvp-p3-5-provider-management
• 原状态：外部授权
• 新状态：进行中
• 结论：P3-5 开始实现 admin-only Provider 管理、Runtime 后端模型目录拉取与手工模型 ID 回退、root-only 密钥边界、任务配置快照和真实 Provider 调用。该状态不代表已配置凭据、模型已验证、免费层已启用或阶段三完成。
• 相关记录：阶段三细化执行页
• Git 提交：f200392
• 证据：Runtime 14 项隔离测试通过；Console/Runtime/Docs GitHub Actions 构建成功；Console 与 Docs 部署健康检查通过；Runtime 39170 健康；Provider 管理读取接口仅返回非敏感状态。后续真实 Provider 验证见提交 b0e736c。
• 后续动作：P3-5 取得真实调用和安全边界证据后，再推进 P3-6 AI 免费层与来源目录；P3-6 当前仍未开始。

🧾 2026-07-27：P3-5 Provider 目录与协议兼容修正

• 计划 ID：phase-3-runtime-mvp-p3-5-provider-catalog-protocol
• 原状态：进行中
• 新状态：进行中
• 结论：确认 app.anbalu.top 的推理接口可用，原失败原因是 OpenAI SDK 默认请求头触发供应商拦截，且目录请求路径与协议未独立配置。Runtime 已改为普通 HTTP 拉取模型目录，纯域名默认请求 /v1/models，并增加 Responses API / Chat Completions 选择。
• 相关记录：阶段三细化执行页
• Git 提交：13acb52、fe1d6b9、72d75b1、b0e736c
• 证据：供应商 /v1/models 实际返回 22 个模型；Runtime 目录刷新返回 22 个模型；真实连通性测试返回 200，记录 30 input / 8 output tokens；本地 15 项 Runtime 测试通过；Console、Runtime、Docs 镜像构建和部署健康检查通过。
• 限制：当前价格字段未配置，成本仍显示待定；P3-6 免费层仍未启用；凭据撤销和协议切换的完整验收尚未完成。
• 后续动作：在 Console 选择上游协议和模型并保存，完成 Boss 实际消息验收，再补 P3-5 的价格、回退和凭据撤销证据。

🧾 2026-07-28：P3-5 Premium Provider 收口

• 计划 ID：phase-3-runtime-mvp-p3-5-provider-management
• 原状态：进行中
• 新状态：已完成
• 结论：真实 Boss 对话已验证 Provider、模型、输入/缓存/输出 Token、人民币成本和事件持久化；Provider 配置新增递增版本号并写入任务快照；Provider 失败只产生错误与告警，由 Benson 选择，不自动切换模型、Provider 或修改密钥。
• 相关记录：阶段三细化执行页、阶段三当前执行摘要
• Git 提交：e0c49b0、cdf404a
• 证据：gpt-5.6-terra 真实 Boss 对话；22 项 Runtime 回归；Provider 失败告警回归；配置版本和旧库迁移测试；Runtime、Console、Docs 健康部署。
• 后续动作：进入 P3-6 AI 免费层与来源目录，仅登记候选来源和约束，不安装、不启用、不导入 Token。

🧾 2026-07-28：P3-6-1 免费渠道发现器与免费池计划建立

• 计划 ID：phase-3-runtime-mvp-p3-6-1-free-pool
• 原状态：未开始
• 新状态：进行中（计划已建立，尚未开始代码实现）
• 结论：将 OmniRoute 和其他公开 Provider 目录纳入一次性初始全量盘点，建立 Free AI Source Registry、Nomad 周期同步、健康与额度记录、渠道等级、Worker 免费池、失败切换和 Console admin-only 工作区。OmniRoute 仍为已发现、待评估、未部署的目录来源，不作为第二个 Gateway 或当前 Runtime 依赖。
• 相关记录：P3-6-1：AI 免费渠道发现器与免费池、阶段三细化执行页、阶段三当前执行摘要
• Git 提交：7df7e23
• 证据：P3-6-1 计划文件、阶段三工作包入口、文档索引和 MkDocs 导航均已同步；计划状态检查通过。
• 后续动作：按 P3-6-1.1 开始 OmniRoute 目录和官方候选来源盘点，不安装 OmniRoute，不导入未知 Token。

🧾 2026-07-28：P3-6-1.1 首轮来源盘点开始

• 计划 ID：phase-3-runtime-mvp-p3-6-1-free-pool
• 原状态：规划中
• 新状态：进行中（P3-6-1.1 来源盘点）
• 结论：完成 OmniRoute release/v3.8.49 仓库、免费模型目录和资料入口核对；完成 OpenCode Zen、OpenRouter、Gemini、Groq、Hugging Face、Mistral、GitHub Models 和 Local Provider 的首轮候选登记与证据分类。当前没有新 Provider 被标记为可用或进入生产免费池。
• 相关记录：P3-6-1：AI 免费渠道发现器与免费池、阶段三当前执行摘要
• Git 提交：80a032c
• 证据：目录请求状态、官方文档、OmniRoute 仓库元数据和免费模型目录源码快照。
• 后续动作：扩展 Registry 字段并写入首轮候选，保留原始发现事实和来源快照。

🧾 2026-07-28：P3-6-1.1 完成，P3-6-1.2 Registry 扩展开始

• 计划 ID：phase-3-runtime-mvp-p3-6-1-free-pool
• 原状态：进行中（P3-6-1.1 来源盘点）
• 新状态：进行中（P3-6-1.1 已完成，P3-6-1.2 Registry 扩展进行中）
• 结论：完成 free_ai_sources 扩展、新增来源模型表和健康检查历史表；补齐额度、等级、优先级、部署、失败和证据字段；旧 SQLite 数据库迁移和旧来源登记请求保持兼容。尚未写入生产候选，也未启用免费 Provider。
• 相关记录：P3-6-1：AI 免费渠道发现器与免费池、阶段三当前执行摘要
• Git 提交：5ea94e8
• 证据：Runtime 24 项测试通过，覆盖新 Registry 字段、模型列表、额度快照和旧库迁移。
• 后续动作：实现固定 Nomad 目录同步和健康检查任务，使用 101/103 受控 Worker 回传 Registry 变更。

🧾 2026-07-28：P3-6-1.2 Registry 扩展完成，P3-6-1.3 Nomad 同步任务开始

• 计划 ID：phase-3-runtime-mvp-p3-6-1-free-pool
• 原状态：进行中（P3-6-1.2 Registry 扩展）
• 新状态：进行中（P3-6-1.2 已完成，P3-6-1.3 Nomad 同步任务进行中）
• 结论：新增固定 free_source_sync / free_source_health Worker 类型；Nomad HCL 只传递受控任务类型和公开来源；Worker 只读取 JSON 目录并回传模型 ID、HTTP 状态、延迟和健康状态；Runtime 可将回传写入来源、模型和健康历史。未提交生产周期 Job，未启用免费 Provider。
• 相关记录：P3-6-1：AI 免费渠道发现器与免费池、阶段三当前执行摘要
• Git 提交：e0fdeae
• 证据：Runtime 25 项测试通过，覆盖固定任务类型、HCL 任务环境、一次性回传、模型登记和健康记录。
• 后续动作：在受控环境提交一次真实目录同步 Batch，核对 101/103 Allocation、回传、Registry 变更和 Job 清理。

🧾 2026-07-28：P3-6-1.3 首次真实 Smoke 暴露回传线程问题

• 计划 ID：phase-3-runtime-mvp-p3-6-1-free-pool
• 原状态：进行中（固定任务类型和模拟回传已通过）
• 新状态：进行中（真实 Smoke 失败，修复后待重试）
• 结论：任务 379f7f4081bb4fc6 真实调度到 pcdell-101，Worker 成功读取 OpenCode Zen 公开模型目录；Runtime 回传进入 Premium Boss 自动审核时，异步回传接口同步调用 Runner.run_sync() 触发事件循环冲突并返回 500，后续重试因一次性 Token 消耗返回 401。Job 已通过内部清理接口删除，未修改 Provider 或 Nomad 配置。
• 相关记录：P3-6-1：AI 免费渠道发现器与免费池、阶段三当前执行摘要
• Git 提交：24d6fc5
• 证据：Nomad Allocation a3f9ca8b-9201-84cf-e34f-5e6ea9f470e3 在 pcdell-101 的任务事件和 Worker stderr；Runtime 日志中的 AgentRunner.run_sync() cannot be called when an event loop is already running。
• 后续动作：部署同步回传接口修复，再次执行真实目录同步并验证 Premium 审核、Registry 更新、Allocation 和清理。

🧾 2026-07-28：P3-6-1.3 Nomad 目录同步任务完成

• 阶段/计划：P3-6-1.3
• 原状态：进行中（真实 Smoke 修复后待重试）
• 新状态：已完成（单次受控目录同步）
• 结论：修复 Runtime 启动恢复与历史离线 Provider 快照后，真实 Smoke e9b86630d39747ac 由 Nomad 调度至 pcdell-101，Allocation c2205d5a-3652-864f-1a27-9a8b2689fc82 以退出码 0 完成。公开 OpenCode Zen 目录返回 HTTP 200、659ms；Runtime 已写入来源、模型目录与健康检查历史，Premium Boss app.anbalu.top / gpt-5.6-terra 自动审核通过并记录 Token 与人民币成本。清理后 Runtime 状态为 cleaned，Nomad Allocation 列表为空。
• 相关记录：P3-6-1：AI 免费渠道发现器与免费池、阶段三当前执行摘要、阶段三细化执行页
• Git 提交：b593b22、e89436a、669fef5
• 证据：Runtime 健康检查通过；101/103 Worker 预加载通过；真实 Job、Allocation、Registry、健康记录、自动审核和清理响应均已核对。
• 后续动作：进入 P3-6-1.4 免费池协调器；未实现周期调度、候选切换、Console 或第二个来源的推理试用，不将 OpenCode Zen 标记为已启用 Provider。

🧾 2026-07-28：P3-6-1.4 免费池协调器开始

• 阶段/计划：P3-6-1.4
• 原状态：未开始
• 新状态：进行中
• 结论：Runtime 新增免费候选选择、无候选记录和失败冷却能力。候选必须满足 enabled、deployed、healthy、等级 1/2、数据等级匹配和模型目录匹配；所有选择、不可用和冷却事件追加写入路由历史。当前只完成策略与状态层，不执行免费 Provider 推理，也不自动修改 Premium 配置。
• 相关记录：P3-6-1：AI 免费渠道发现器与免费池、阶段三当前执行摘要
• Git 提交：d240c93
• 证据：28 项 Runtime 测试通过，覆盖候选选择、HTTP 429 冷却、无候选结果和路由历史；镜像部署后线上选择 gpt-5.6-terra 返回 unavailable，OpenCode Zen 保持 discovered / not_deployed / level 4。
• 后续动作：补齐实际免费 Provider Adapter 的隔离试用与失败切换测试，再进入 Console 工作区；未通过前不把任何免费来源标记为已启用。

🧾 2026-07-28：P3-6-1.4 真实免费 Adapter 失败分支验证与 P3-6-1.5 开始

• 阶段/计划：P3-6-1.4、P3-6-1.5
• 原状态：P3-6-1.4 策略层进行中；P3-6-1.5 未开始
• 新状态：P3-6-1.4 进行中（真实 429 分支已验证）；P3-6-1.5 进行中
• 结论：OpenCode Zen 的无凭据公开 Chat Completions 已直接验证可用协议格式，但 Runtime 容器内实际最短请求返回 HTTP 429。免费池将该来源置为 cooldown，追加记录选择、冷却和无候选后回落至 deterministic-demo，未重复试探或改变 Boss Premium Provider。新增 Console AI 免费池 视图用于展示来源、模型、健康、冷却和路由历史，并仅提供暂停/重新启用已有配置来源的受控操作。
• 相关记录：P3-6-1：AI 免费渠道发现器与免费池、阶段三当前执行摘要
• Git 提交：待提交
• 证据：30 项 Runtime 测试通过；Runtime 容器真实请求、Registry 状态和路由历史已核对。
• 后续动作：发布 Runtime/Console 镜像并完成公网验收；第二个可用来源与实际回退仍待验证，不能将免费池标记完成。

🧾 2026-07-28：P3-6-1.5 Runtime、Console 与 Docs 发布完成

• 阶段/计划：P3-6-1.5
• 原状态：进行中（待发布验收）
• 新状态：进行中（已发布，待管理员交互验收）
• 结论：AI Runtime、Console 与 Docs 镜像均构建并部署成功，三项容器健康检查通过。Console 本地静态资源包含 AI 免费池 视图；未认证公网请求按既有认证边界重定向至登录入口。Docs 公网页面已验证包含 P3-6-1.4/1.5 及 HTTP 429 冷却事实。
• 相关记录：P3-6-1：AI 免费渠道发现器与免费池、阶段三当前执行摘要
• Git 提交：待提交
• 证据：Console/Runtime/Docs 容器 healthy；https://docs.yohan.fun/plans/p3-6-1-free-pool/ 已返回新计划正文。
• 后续动作：由 Benson 在已登录管理员 Console 打开 AI 免费池 完成交互验收；之后继续第二个来源与实际回退验证。

🧾 2026-07-28：P3-6-1.5 交互验收完成，P3-6-1.6 首轮真实试用开始

• 阶段/计划：P3-6-1.5、P3-6-1.6
• 原状态：P3-6-1.5 已发布待交互验收；P3-6-1.6 未开始
• 新状态：P3-6-1.5 已完成；P3-6-1.6 进行中
• 结论：管理员通过 Console 真实查看免费池并执行暂停、重新启用；Runtime API 日志与来源最终 enabled / deployed / unknown 状态一致。OpenRouter 公开模型目录返回 HTTP 200，15 个 :free 模型登记为第二候选；推理需要独立 API Key，当前保持 pending_evaluation / not_deployed，未导入 Token或发送推理请求。
• 相关记录：P3-6-1：AI 免费渠道发现器与免费池、阶段三当前执行摘要
• Git 提交：待提交
• 证据：管理员 Console 截图、Runtime API 请求日志、OpenRouter 目录 HTTP 200 和 Runtime Registry 记录。
• 后续动作：取得一个可审计的第二来源测试配置，完成公开短请求、失败切换与实际回退验证；未取得前不完成 P3-6-1.6。

🧾 2026-07-28：P3-6-1.1b OmniRoute 全量候选发现完成

• 阶段/计划：P3-6-1.1b
• 原状态：进行中（等待生产批量发现）
• 新状态：已完成（只读候选扫描与 Registry 登记）
• 结论：固定 release/v3.8.49 目录通过受控 Nomad Worker 在 pcdell-101 完成扫描。最终任务 04ea8ef7ea624edc 由 AI Boss 自动审核通过，生产回传并登记 80 个 Provider 候选；其中 78 条为新增 pending_evaluation / not_deployed / unknown，OpenRouter/OpenCode 既有来源按 source_url 去重，未覆盖已有配置。未安装 OmniRoute、未导入未知 Token、未启用新增 Provider。
• 相关记录：P3-6-1：AI 免费渠道发现器与免费池、阶段三细化执行页、阶段三当前执行摘要
• Git 提交：84a2209、533089c、13421f7
• 证据：Nomad Job agentmeshos-runtime-04ea8ef7ea624edc；Allocation 9a11aa3b-9886-6e92-88b4-359ff815c31e；节点 pcdell-101；Allocation complete；Runtime /health 200；AI Boss 审核结论为“自动审核通过”。
• 更正记录：前两次运行分别暴露 Worker 镜像遗漏 free_catalog.py 和回传等待 15 秒导致一次性 Token 重试的问题，已修复并保留失败历史；前期离线快照的 81 Provider 与生产回传 80 Provider 差异列入下一次目录同步核对，不把离线快照冒充生产结果。
• 后续动作：进入 P3-6-1.6 分批隔离测试；先测试候选，再决定是否登记为可用，不批量启用。

🧾 2026-07-28：P3-6-1.6 第一批双来源隔离测试完成

• 阶段/计划：P3-6-1.6
• 原状态：进行中（等待第二条成功推理）
• 新状态：已完成（第一批双来源短请求验收）
• 结论：OpenCode Zen 无 Key 短请求 HTTP 200、约 7566ms、51 tokens；OpenRouter 短请求 HTTP 200、约 781ms、40 tokens。两者均已写入健康检查历史并被免费池选择器成功选中。此前 OpenCode HTTP 429、冷却和 deterministic-demo 回落事件保留，未自动更换 Premium 配置。
• 相关记录：P3-6-1：AI 免费渠道发现器与免费池、阶段三细化执行页、阶段三当前执行摘要
• Git 提交：待提交
• 证据：Runtime /boss/v1/providers/free-sources/{id}/test 两次 HTTP 200；OpenCode 来源 ID e3208a26414441d79ea64799de81736c；OpenRouter 来源 ID fab48be2394840ccbba25f007b81b475；两次 /select 路由均返回 selected。
• 限制：其余 78 个 OmniRoute 候选没有可验证 API 地址或测试凭据，仍为待评估/未部署；本批回落仅证明 Local/确定性测试回退，不证明 Premium 自动回退。
• 后续动作：继续为目录候选补齐可验证入口后分批测试；不批量导入 Token 或启用来源。

🧾 2026-07-28：P3-6-1 候选试用暂停，转入 OmniRoute 架构复核

• 阶段/计划：P3-6-1.0
• 原状态：其余 78 个候选待分批测试
• 新状态：候选试用暂停；进行 OmniRoute Provider Manifest 与 Runtime Adapter 边界复核
• 结论：纠正“以现有 Adapter 能力决定解析范围”的错误方向。OmniRoute 固定版本源码表明其完整 Provider Registry、Translator、Executor、OAuth/会话处理和 Gateway 路由是分层系统；AgentMeshOS 应先完整记录所有静态协议/认证/端点/能力元数据，再独立判断每种协议所需 Adapter 和运行资格。
• 相关记录：P3-6-1：AI 免费渠道发现器与免费池、阶段三细化执行页、阶段三当前执行摘要
• Git 提交：待提交
• 证据：OmniRoute 官网 Quick Start、release/v3.8.49 固定源码、Provider Plugin Manifest、open-sse Architecture、Provider Registry 和 Executor Registry。
• 后续动作：比较“Manifest 导入”与“私有 OmniRoute Gateway”两种目标架构；未完成该复核前，不部署 OmniRoute，不部署本轮候选元数据扩展，不恢复候选试用。

🧾 2026-07-28：P3-6 方向收敛为私有 Fork OmniRoute 模型核心

• 阶段/计划：P3-6-2
• 原状态：P3-6-1 完成初始发现、Registry 与首轮试用基线；候选试用暂停，模型核心接入路线待定。
• 新状态：P3-6-2 规划中；私有 Fork OmniRoute 模型核心为当前单一方向，尚未 Fork、安装或部署。
• 结论：AgentMeshOS 保留 Benson Console、AI Boss/Worker、任务图、Nomad、Storage、证据、成本、收益与全局告警外壳；私有 Fork OmniRoute 承担 Provider/Model/Protocol/Auth、OAuth/API Key、配额/健康/冷却/回退和上游调用事件。已验证 Premium 与未来 Local/特殊能力作为同一 Runtime Provider 边界的补充 Direct Adapter，不形成第二条模型路由。上游同步成为 Fork 生命周期的一部分，但不得自动合并或自动部署。
• 相关记录：P3-6-2：私有 Fork OmniRoute 模型核心接入、P3-6-1：AI 免费渠道发现器与免费池、阶段三细化执行页、阶段三当前执行摘要
• Git 提交：49c9439
• 证据：OmniRoute release/v3.8.49 固定源码提交 3b515d90b3848cfa49ce7d8f0f718bcde59cf507、MIT LICENSE、Provider Plugin Manifest、open-sse Architecture、Provider Registry、Executor/Translator/Credential Gate/Cooldown 源码核查。
• 后续动作：先完成 P3-6-2 的私有 Fork 所有权和部署契约，再在明确授权后执行；在此之前保持候选试用和 OmniRoute 部署暂停。

🧾 2026-07-28：P3-6-2.0 OmniRoute 产品解剖与适配专题开始

• 阶段/计划：P3-6-2.0
• 原状态：P3-6-2 为私有 Fork 模型核心接入规划，尚未建立完整产品能力档案。
• 新状态：进行中（只读产品研究）；Fork、安装、部署、Token 导入和候选试用仍未开始。
• 结论：在私有 Fork 实施前，先以固定 release/v3.8.49 源码和官方资料系统核对 Desktop、协议/Executor、Provider/认证、Combo/弹性、用量/事件、MCP/A2A、Context/Memory、端点、Tunnel、Cloud Sync、部署和数据模型；每项写入“继承核心 / 外壳桥接 / 独立评估 / 不接入”之一。Tailscale Funnel 只作为研究对象：上游实现要求官方 Tailscale 登录和 Admin Console Funnel 开关，与当前 Headscale 自托管控制面不直接兼容，默认不接入。
• 相关记录：P3-6-2.0：OmniRoute 产品解剖与适配专题、P3-6-2：私有 Fork OmniRoute 模型核心接入、阶段三当前执行摘要
• Git 提交：a6f74bf
• 证据：固定源码 electron/README.md、docs/architecture/ARCHITECTURE.md、docs/ops/TUNNELS_GUIDE.md、src/lib/tailscaleTunnel.ts、Provider Plugin Manifest 与 AgentMeshOS 网络/部署规范。
• 后续动作：持续完成 R2 至 R8；专题出口后才进入 P3-6-2.1 私有 Fork 所有权与上游同步策略。

🧾 2026-07-28：更正 P3-6-2.0 对 Tailscale Funnel 与 Headscale 的表述

• 阶段/计划：P3-6-2.0
• 原状态：专题初始记录将 OmniRoute Funnel 与当前 Headscale 控制面写为“不直接兼容”。
• 新状态：兼容性待独立验证；默认不启用。
• 结论：固定源码已证实 OmniRoute 通过系统 tailscale CLI 管理 Funnel，并包含登录、状态、启用、停用与 API 路由。该事实只能证明其依赖 Tailscale CLI、登录和 Funnel ACL，不能推导 Headscale 可用或不可用。当前保持不接入，未来只在隔离节点以明确授权完成控制面、ACL、URL、回滚与现有公网入口关系的真实测试后再决定。
• 相关记录：P3-6-2.0：OmniRoute 产品解剖与适配专题、P3-6-2：私有 Fork OmniRoute 模型核心接入
• Git 提交：1159431
• 证据：固定源码 src/lib/tailscaleTunnel.ts、src/app/api/tunnels/tailscale/*、docs/ops/TUNNELS_GUIDE.md；当前 AgentMeshOS Headscale 部署规范。
• 后续动作：将 Funnel 保持为独立评估项，不纳入当前核心部署契约。

🧾 2026-07-28：P3-6-2.0 R3-R7 源码证据收口

• 阶段/计划：P3-6-2.0
• 原状态：已建立产品轮廓、协议和初始边界，R3-R7 仍缺少结构化源码结论。
• 新状态：R3-R7 已形成源码证据和桥接输入；私有 Fork、依赖安装、镜像构建、OAuth、真实 Provider、候选试用和生产部署仍未开始。
• 结论：Provider 连接、OAuth refresh、Translator、Executor、Manifest、Combo、用量和调用事实可作为模型核心研究输入，但原始 SQLite、调用日志、进程内事件/冷却、A2A、MCP 全量工具、Context/Memory/Compression、Cloud Sync、Tunnel、runner-web/runner-cli 和多端口部署不能原样接入。AgentMeshOS 保留持久任务、成本/收入、Artifact、Boss 审核、告警与 Nomad 控制；OmniRouteAdapter 负责以 runtime_call_id 关联模型调用、脱敏事件和成本账本。
• 相关记录：P3-6-2.0：OmniRoute 产品解剖与适配专题、P3-6-2：私有 Fork OmniRoute 模型核心接入
• Git 提交：d286b9b
• 证据：固定 release/v3.8.49 源码中的 Provider/OAuth/DB/Translator/Executor/Combo/Usage/Event/MCP/A2A/Memory/Compression/Cloud Sync/Docker 模块核查。
• 后续动作：继续完成 R8 匹配矩阵，随后将研究结论输入 P3-6-2.1 Fork 所有权与上游同步策略；未获得执行授权前不改变运行态。

🧾 2026-07-28：P3-6-2.0 R8 匹配矩阵完成，转入 P3-6-2.1

• 阶段/计划：P3-6-2.0、P3-6-2.1
• 原状态：P3-6-2.0 R3-R7 已有源码证据，R8 未开始；P3-6-2.1 未开始。
• 新状态：P3-6-2.0 已完成只读研究；P3-6-2.1 进行中（Fork 所有权与上游同步策略）。
• 结论：固定 release/v3.8.49 源码的协议、Manifest、Provider/认证、Combo、用量、数据库、MCP/A2A、Context/Memory、Tunnel、Cloud Sync、桌面端与部署域已逐项归类。私有模型核心继承协议/Executor/Manifest/Provider 路由与受控更新流程；AgentMeshOS 保留 Runtime 任务快照、Boss 审核、Nomad、Storage Artifact、成本/收入和告警；MCP/Memory/Context/Compression 独立评估；Desktop、Tunnel、Cloud Sync、MITM、浏览器 Cookie、runner、Docker Socket 与 A2A 任务控制器不接入。专题完成不构成构建或部署证据。
• 相关记录：P3-6-2.0：OmniRoute 产品解剖与适配专题、P3-6-2：私有 Fork OmniRoute 模型核心接入、阶段三当前执行摘要
• Git 提交：6162420
• 证据：固定源码 src/sse/handlers/chat.ts、src/lib/plugins/manifest.ts、src/lib/db/*、src/lib/events/eventBus.ts、src/lib/a2a/taskManager.ts、src/lib/tailscaleTunnel.ts、src/lib/cloudSync.ts、Docker 与迁移目录；R8 匹配矩阵。
• 后续动作：完成 P3-6-2.1 的私有 Fork 归属、upstream remote、分支、固定基线、差异审查和受控更新契约；P3-6-2.2 完成前不创建 Fork、不安装、不部署。

🧾 2026-07-28：P3-6-2.1 私有维护镜像策略完成

• 阶段/计划：P3-6-2.1
• 原状态：Fork 所有权与上游同步策略进行中。
• 新状态：策略与契约完成；P3-6-2.2 私有部署契约为下一项。
• 结论：GitHub 官方规则确认公开仓库 Fork 必须公开，不能单独改成私有；因此“私有 Fork 模型核心”实际采用私有维护镜像 michaellab7284/agentmeshos-omniroute-core 加只读 upstream remote。固定基线为 release/v3.8.49 / 3b515d90b3848cfa49ce7d8f0f718bcde59cf507；已定义 origin/upstream、分支、许可证、差异审查、构建/Smoke 与回滚规则。未创建镜像仓库，未构建或部署。
• 相关记录：P3-6-2 私有 Fork OmniRoute 模型核心接入
• Git 提交：6162420
• 证据：GitHub 官方 Fork 可见性文档、上游 GitHub 仓库元数据与固定源码 remote/commit。
• 后续动作：制定 P3-6-2.2 最小 Docker/SQLite/私有监听部署契约；完成前不创建镜像仓库或运行模型核心。

🧾 2026-07-28：P3-6-2.2 最小部署契约完成

• 阶段/计划：P3-6-2.2
• 原状态：私有部署契约准备中。
• 新状态：设计契约完成；未创建私有维护镜像、未构建、未部署。
• 结论：采用私有维护镜像的单容器 runner-base，主节点仅监听 127.0.0.1:39180，使用独立 SQLite 数据卷与 root-only 密钥文件。上游完整 Compose、多端口、Redis、Dashboard、Live WS、浏览器、CLI、Docker Socket、MITM 与 sidecar 不接入。当前资源调查显示 39180 空闲、可用内存约 1.7 GiB、根盘 73%，首次构建前必须重新审计容量。
• 相关记录：P3-6-2 私有 Fork OmniRoute 模型核心接入
• Git 提交：430d6a6
• 证据：固定上游 Dockerfile、Compose、healthcheck、主节点端口/内存/磁盘/Docker 运行态调查。
• 后续动作：创建私有维护镜像、验证 remote 与隔离构建；完成无凭据 Smoke、回滚镜像与私有健康检查后才进入凭据和 Runtime 桥接工作包。

🧾 2026-07-28：P3-6-2.2 私有维护镜像基线导入完成

• 阶段/计划：P3-6-2.2
• 原状态：部署契约完成，私有维护镜像为空。
• 新状态：私有维护镜像基线已导入；待隔离构建。
• 结论：上游 Git 对象推送在 GitHub 接收端出现缺对象错误，故改用 GitHub 固定 commit 的源码 archive 建立单提交基线。私有 michaellab7284/agentmeshos-omniroute-core 的 main 与 baseline/release-v3.8.49 现均指向 033e660c4c0d532329632f39aa68fc062f22b15e，源代码基线仍对应上游 release/v3.8.49 / 3b515d90b3848cfa49ce7d8f0f718bcde59cf507，MIT LICENSE 已保留。该镜像不是上游 Git 历史的完整镜像，不得伪称保留完整 commit 图。
• 相关记录：P3-6-2 私有 Fork OmniRoute 模型核心接入
• Git 提交：待提交
• 证据：私有远端 main、baseline/release-v3.8.49 的 git ls-remote；本地快照 commit 与 origin/upstream remote。
• 后续动作：重新审计主节点构建容量；满足资源条件后在隔离目录执行无凭据 runner-base 构建、健康检查和回滚镜像验证。

🧾 2026-07-28：101 Docker bridge 主路由与双链路备用修正

• 阶段/计划：阶段三 P3-6-2.2 的隔离构建网络前置修正。
• 原状态：101 宿主机可经有线透明代理访问 Debian，但 Docker bridge 的未标记流量进入 Tailscale 策略路由表，容器 DNS 超时；WiFi 备用为另一网络。
• 新状态：Docker 172.17.0.0/16 流量通过持久 systemd 单元标记为 0x80000 并进入主路由表；有线 enp0s31f6 metric 100 优先，WiFi wlp2s0 已接入同一 192.168.50.0/24 透明代理路由器并以 metric 600 备用。
• 结论：路由器 PassWall/DNS 重定向已启用，无需在路由器额外为 Docker 开规则；问题在 101 的 Tailscale 策略路由未覆盖 Docker 转发流量。永久规则仅匹配 docker0 / 172.17.0.0/16，不改变 Nomad、Runtime、Provider 或 Exit Node。Docker bridge Debian HTTP、DNS、有线断开后的 WiFi 接管、恢复有线和 Tailnet 均已实测通过。
• 相关记录：阶段三当前执行摘要、P3-6-2 私有 Fork OmniRoute 模型核心接入
• Git 提交：c43b6ea
• 证据：101 ip rule / 路由表、Docker bridge DNS 与 Debian HTTP、agentmeshos-docker-main-route.service、有线断开演练与恢复演练；路由器 PassWall/DNS/NAT 只读审计。
• 后续动作：恢复 P3-6-2.2 的 101 隔离 runner-base 构建，使用默认 Docker bridge 验证网络修正；不接入真实 Provider 或 Runtime。

🧾 2026-07-28：P3-6-2.2 隔离构建与无凭据烟测完成

• 阶段/计划：P3-6-2.2
• 原状态：私有维护镜像基线已导入，待 101 隔离构建与无凭据 Smoke。
• 新状态：已完成。
• 结论：101 在默认 Docker bridge 下完成私有镜像 agentmeshos/omniroute-core:033e660-smoke 的 runner-base 隔离构建，镜像 digest 固定为 sha256:bda2d4954c3abb8b8eeecbe99634e7f7f5a3a63f5a87a21d0487e1295b1979a2。无凭据烟测容器仅绑定 127.0.0.1:39181，以非 root node 用户运行，/api/monitoring/health 返回 healthy、版本 3.8.49、configuredCount=0；测试后容器、临时数据和临时密钥均已清理。
• 相关记录：P3-6-2 私有 Fork OmniRoute 模型核心接入、阶段三当前执行摘要、阶段三细化执行页
• Git 提交：待提交
• 证据：101 构建退出码 0、镜像 digest、健康接口返回、容器 User=node、回收清理结果以及日志敏感词扫描 SECRET_HIT=0。
• 后续动作：进入 P3-6-2.3 凭据、认证与 Console 外壳边界证据收口；仍不接入真实 Provider、不部署主节点私有模型核心、不开放 Dashboard 或公网模型 API。

🧾 2026-07-28：P3-6-2.3 凭据、认证与 Console 外壳边界开始

• 阶段/计划：P3-6-2.3
• 原状态：未开始。
• 新状态：进行中（边界证据收口）。
• 结论：当前 Runtime 已具备基础边界：ProviderSecretBox 使用 root-only 主密钥将 Provider/API Key 以 AES-GCM 密文写入 SQLite；Provider 和免费池读取接口只返回 has_api_key 与非敏感状态，不回显密文；admin-only Provider/Boss 页面继续复用既有 console.yohan.fun，未启用 OmniRoute Dashboard、第二 Console 或公网模型 API。以上是现有实现和隔离烟测的已验证事实，不代表 OmniRouteAdapter 事件桥接或真实凭据接入已完成。
• 相关记录：P3-6-2 私有 Fork OmniRoute 模型核心接入、阶段三当前执行摘要、阶段三细化执行页
• Git 提交：待提交
• 证据：ai-runtime/src/providers.py、ai-runtime/src/store.py、ai-runtime/src/main.py 中的密钥加密、只读返回和 admin-only 鉴权路径；P3-6-2.2 烟测日志未发现 STORAGE_ENCRYPTION_KEY、Authorization 或 Bearer 密钥片段。
• 后续动作：把该边界与后续 OmniRouteAdapter 的事件、成本、健康与失败桥接契约统一写回计划；完成前不把真实 Provider/OAuth 凭据导入 OmniRoute 核心。

🧾 2026-07-29：P3-6-2.3 改为全量镜像与完整服务验证

• 阶段/计划：P3-6-2.3
• 原状态：凭据、认证与 Console 外壳边界证据收口；OmniRoute Dashboard 未启用。
• 新状态：进行中（全量镜像、完整服务与 Console 验证）。
• 结论：根据 Benson 的执行决策，不再先裁剪上游功能。私有维护仓库新增 runner-full，合并上游 runner-web 与 runner-cli 能力，并新增完整 Compose 契约；目标是原样运行 Dashboard、API、Live WS、Redis、CLI 和 Provider 能力，再依据真实运行结果决定是否裁剪。完整服务端口仍只绑定主节点 loopback，通过既有 console.yohan.fun admin-only 路径呈现 UI，不新增公网端口或第二调度器。
• 证据：私有仓库提交 68c7249 已推送；Compose 语法检查通过；101 完整构建已启动并脱离当前对话继续运行，当前尚未读取最终退出码或目标镜像 digest；已有 runner-base 回滚镜像未改变。
• 后续动作：构建完成后由 Benson 要求抓取最终退出码、镜像 digest 和无真实 Provider 凭据的完整 Compose Smoke，再执行主节点部署和 Console 路径接入。

🧾 2026-07-29：P3-6-2.3 全量镜像构建完成

• 阶段/计划：P3-6-2.3
• 原状态：101 完整 runner-full 构建后台运行。
• 新状态：完整镜像构建已完成，完整 Compose/UI/API/Live WS/Redis/CLI Smoke 未开始。
• 结论：101 构建退出码为 0，镜像 agentmeshos/omniroute-core:68c7249-full 的 digest 为 sha256:db9d24a7aaed29793584180e712be936efb1d33cfba92826d0223ef28cd9bba5，大小 1472463765 字节。构建日志显示 npm 阻止了 @anthropic-ai/claude-code、droid、openclaw 等部分全局包的 postinstall 脚本；因此当前只能确认镜像构建成功，不能把 CLI 能力写成已验证可用。
• 相关记录：P3-6-2 私有 Fork OmniRoute 模型核心接入、阶段三当前执行摘要、阶段三细化执行页
• 证据：101 /var/tmp/agentmeshos-omniroute-full-68c7249/build-full.log 中 BUILD_RC=0、镜像 digest/大小、BuildKit runner-full 导出完成记录。
• 后续动作：在 101 先用无真实 Provider 凭据启动 AgentMeshOS Compose，验证 Dashboard/API/Live WS/Redis、路径前缀和原生认证；单独验证 CLI 是否因 postinstall 缺失而不可用，再决定补齐构建策略。

🧾 2026-07-29：P3-6-2.3 101 完整服务无凭据 Smoke 完成

• 阶段/计划：P3-6-2.3
• 原状态：全量 runner-full 镜像已构建，完整服务尚未验收。
• 新状态：101 完整 Compose 无凭据 Smoke 通过；主节点部署、Console 路径接入、真实 Provider 和 Runtime 事件桥接仍未开始。
• 结论：镜像 agentmeshos/omniroute-core:81e7b33-full 构建退出码为 0，digest 为 sha256:0d2a489da178112f2dadf9f1b55964528cd2120d682a11be506ffd6a8aa7c6fc，大小 1472706379 字节。Redis 8.6.2-alpine 健康；OmniRoute Docker health 为 healthy，重启次数 0，版本 3.8.49。基础路径 Dashboard 登录页返回 200，/v1/models 返回 200，Live WS handshake 返回 200 且 TCP 监听通过；codex-cli 0.145.0、Claude Code 2.1.220、Droid 0.182.0、OpenClaw 2026.7.1-2 均从最终镜像实际执行成功。SQLite 中 provider_connections=0、api_keys=0、usage_history=0，未导入真实凭据或发起真实 Provider 请求。
• 资源与边界：OmniRoute 空闲/短探针 RSS 约 536 MiB，Redis 约 6 MiB；101 主机可用内存约 12 GiB、根盘使用率 39%。HTTP 39180 和 Live WS 39182 仅绑定 127.0.0.1，没有新增公网监听。Smoke 容器、网络、临时数据、一次性密钥和 Compose 文件已清理；已验证镜像保留在 101。
• 相关记录：P3-6-2 私有 Fork OmniRoute 模型核心接入、阶段三当前执行摘要、阶段三细化执行页
• 证据：101 Compose ps/health、健康 JSON、Dashboard/API/Live WS HTTP 响应、CLI 版本、SQLite 计数、docker stats、loopback 监听和清理后的镜像检查。
• 后续动作：根据主节点当前资源重新确定容器限制，将已验证镜像导入主节点并执行 loopback 私有部署；完成健康与回滚验证后再接入 Console admin-only 路径。

🧾 2026-07-29：系统云盘 502 恢复与连续运行加固

• 范围：阶段三执行期间发现的底座必需服务故障；OmniRoute 镜像归档与主节点部署暂停，优先恢复 disk.yohan.fun。
• 已验证事实：公网 disk.yohan.fun 返回 502 时，Nomad agentmeshos-kodbox 为 dead 且没有 Allocation；101/103 的 Galera 都是 Primary / Synced / wsrep_ready=ON，JuiceFS 与 CSI 卷健康。重新登记既有 KodBox Job 后，101 Allocation、Nomad TCP 检查、101 39160 与公网 HTTPS 均返回健康结果。
• 证据缺口：故障前 Allocation 已被 Nomad GC，现有历史日志无法证明它进入 dead 的原始触发因素；不把原因归咎于镜像、CSI、文档发布或人工操作。
• 已落地修正：KodBox 受保护 HCL 固定已验证镜像摘要，允许 101/103 单活迁移并保留 101 优先；101/103 均预热该摘要并保留回滚标签。主节点新增 root-only agentmeshos-kodbox-reconcile.timer，每 60 秒只在没有活动/启动中的 Allocation 时按当前 ModifyIndex 重新登记 Job；新增/升级存储健康探针以检查实际 KodBox Allocation 与公网入口，不再将 101 端口视为唯一健康依据。
• 告警结论：此次 disk-public=DEGRADED 与 kodbox-101=DEGRADED 已实际写入 API Gateway；恢复后被对应 HEALTHY 事件关联关闭。此前没有外部推送通道，管理员未打开 Console 时不会收到站外通知；Console 内角标和告警中心是当前唯一通知面。
• 验收：真实恢复后 Nomad 运行态、CSI 绑定、101 本机 HTTP 与公网 HTTPS 均通过；对账器正常态成功空操作、隔离 mock 验证死 Job 时会调用带 ModifyIndex 的重新登记命令；未对生产 Job 做故障注入。

🧾 2026-07-29：系统云盘 WebDAV 健康与事故快照补强

• 范围：修正“网页入口正常即系统云盘正常”的健康判定缺口；不改变健康 KodBox Allocation、不重启 MariaDB/JuiceFS。
• 已验证事实：disk.yohan.fun 网页入口可为 HTTP 200，而 agentmeshos-sync 的具体 WebDAV 目录曾返回 502；随后同一认证路径恢复为 HTTP 207。这证明网页探针不能代替自动化存储链路检查。
• 已落地修正：存储健康定时器新增从主节点经 SSH 在 101 使用 root-only agentmeshos-sync 凭据，对 WebDAV 根与 AgentMeshOS-长期 执行认证 PROPFIND；凭据、响应正文和 Token 均不离开 101。首次状态降级保存 root-only 事故快照，包含 KodBox Allocation 摘要、Tailnet 摘要和 Nomad/Galera/Tailscale 近期日志。
• 验收：隔离执行已验证 Galera、JuiceFS、实际 KodBox Allocation、网页入口及认证 WebDAV 根/长期目录都为 HEALTHY；生产定时器安装后将继续通过同一告警中心报告状态变化。
• 后续动作：继续依据统一 UTC 的三端日志调查控制面/仲裁链路中断；不得将自动重新登记或一次成功的网页访问表述为根因已经消除。

🧾 2026-07-29：P3-6-2.3 主节点完整服务与公网入口部署完成

• 已验证事实：已从系统云盘正式入口校验并导入 agentmeshos/omniroute-core:81e7b33-full（digest sha256:0d2a489da178112f2dadf9f1b55964528cd2120d682a11be506ffd6a8aa7c6fc）；主节点 OmniRoute 与 Redis Compose 均为 healthy、无重启，HTTP/API 39180、Live WS 39182 仅监听 loopback。
• 公网入口：omni.yohan.fun 已由 MM HTTPS 回源主节点 39200，证书、强制 HTTPS 和未认证 A-Auth 跳转均已验证。
• 限制：本次没有导入真实 Provider、API Key 或 Usage；管理员登录后的 UI/Live WS 联动、Console 入口和 OmniRouteAdapter 事件/用量/成本/健康桥接仍未完成。
• 相关记录：P3-6-2 私有 Fork OmniRoute 模型核心接入、阶段三当前执行摘要

🧾 2026-07-29：P3-6-2.3 切换为官方镜像正式部署

• 结论：按用户决策放弃继续本地重编译，改为直接部署上游官方镜像 diegosouzapw/omniroute:latest。主节点正式运行版本为 3.8.48，镜像 digest 为 sha256:badb560971fdc23c2fb84b3e8695116239ff215b4cca4b07076201a8efae7f0d。
• 已验证事实：主节点正式容器 agentmeshos-omniroute-core 与 Redis 均启动成功；127.0.0.1:39180 返回 307 -> /dashboard，/api/monitoring/health 返回 healthy，provider_connections=0、api_keys=0。omni.yohan.fun 对外继续返回 A-Auth 登录跳转。
• 配置变化：正式部署改为单主端口 127.0.0.1:39180 -> 20128；不再把 39182 作为正式回源端口。原主节点数据目录和部署文件已在项目 temp/omniroute-switch-backup/ 下留有备份，当前正式数据目录已按官方镜像的 UID 1000 重建。
• 已补充验收：原生登录接口使用初始密码 19790801 返回 200，/api/auth/status 返回 authenticated:true；Console 源码中的 OmniRoute 链接为 https://omni.yohan.fun/。MM 侧无需改动 IP/端口，当前正式回源仍为 100.64.0.1:39200 -> 127.0.0.1:39180。
• 限制：本次仍未导入真实 Provider、API Key 或 Usage；Runtime 事件/用量/成本桥接仍待后续实施。
• 相关记录：P3-6-2 私有 Fork OmniRoute 模型核心接入、阶段三当前执行摘要

🧾 2026-07-30：P3-6-2.8 只读 Smoke 执行链通过，Artifact/Console 继续保留

• 阶段/计划：P3-6-2.8 Nomad/Storage 集成与端到端验收
• 原状态：独立免费路由已验收，端到端 Smoke 尚未开始。
• 新状态：受控 Batch、免费分析、Boss 审核和 Nomad Job 清理已通过；Storage Artifact 与管理员 Console 页面验收仍未完成。
• 结论：修复 AGENTMESHOS_BATCH_PARAMS 将 JSON 对象错误写入 HCL 的根因后，任务 4744fcd8507942ac 成功从 Runtime 提交至 Nomad，执行 source-research/v1 读取 GitHub 公开 API，回传后真实使用 omniroute:combo / devstral-latest 完成免费分析，再由 app.anbalu.top / gpt-5.6-terra 自动审核通过。清理接口返回成功，随后 Allocation 列表为空且执行状态为 cleaned。
• 证据：Runtime 事件 nomad_submitted、batch_free_analysis_completed、boss_auto_review、nomad_cleaned；免费分析延迟约 7508ms；Worker 只读来源为 GitHub 公开 API。
• 后续动作：实现并验证 Storage Artifact 上传、哈希与回传；使用真实管理员会话验收 Console 的 Boss/Provider 页面。完成前不进入 P3-7。

🧾 2026-07-31：P3-6-2.8 实体 Artifact 写入、读取与哈希验收通过

• 阶段/计划：P3-6-2.8 Nomad/Storage 集成与端到端验收
• 原状态：受控 Batch、免费分析、Boss 审核和 Job 清理已通过；Artifact 实体对象与管理员 Console 页面未验收。
• 新状态：Artifact 实体对象验收通过；管理员 Console 已登录页面仍未验收。
• 结论：新增 Runtime-owned S3 Adapter 后，Worker 只能使用一次性 Artifact 回传 Token 上传最大 1 MiB 的受控 JSON，不获得 S3、Docker、SSH、Nomad 或宿主机凭据。Runtime 校验字节长度、SHA-256、内容类型和固定对象键，使用 root-only、仅限 task-artifacts/runs/ 的 MinIO 身份，经 MM Tailnet TCP 中转 PUT 后 HEAD 复核，再写入 Metadata。Smoke 71454fe77a4d42c2 由 101 执行，Artifact 为 373 bytes，上传事件与 Metadata 哈希为 afef534e12d933e58c4d88cb2ee8dbe6d5def69d2ed8d6e2bbb3040f33a4bd7d；Runtime 独立 GET 后得到相同长度和 SHA-256。免费分析真实使用 omniroute:combo / devstral-latest，Boss 审核真实使用 app.anbalu.top / gpt-5.6-terra，任务为 completed，Nomad Job 清理后 Allocation 为空。
• 限制：免费模型的分析文本没有 Artifact 事件上下文并出现“未上传 Artifact”的不准确描述；Runtime 事件、MinIO 对象和独立 GET/哈希才是 Storage 验收依据。Playwright MCP 浏览器传输关闭，且没有可用的 A-Auth 管理员浏览器会话，因此不能伪造 Cookie 或将接口检查替代真实页面验收。
• 后续动作：恢复浏览器 MCP 或使用真实管理员会话，在 Console 的 Boss/Provider 工作区完成页面加载、交互与截图验收；完成前不进入 P3-7。

🧾 2026-07-31：Console 系统说明归入总览与 A-Auth 临时 API Key 会话

• 工作范围：Console 工作台布局、A-Auth 管理 API Key、主节点 Console 网关认证转发。
• 已完成：系统说明、Runtime 名词解释和任务流说明移入工作台总览，左侧导航不再占用独立菜单；A-Auth 增加 API Key 登录页和普通登录页切换入口。
• 已完成：API Key 可直接调用 A-Auth /session 与网关 internal/auth，也可通过 /api-key-login 换取绑定到 Key 的 HttpOnly 浏览器会话；撤销 Key 会联动使换取的会话失效。Key 不进入 URL、浏览器存储、Git 或日志。
• 网关：agentmeshos-main-origin-gateway.sh 升级为 v0.4.8，Console 管理/普通认证子请求、会话读取和退出请求均转发 X-AgentMeshOS-API-Key；同时修复 heredoc 中 Nginx $host 等变量未转义导致 set -u 应用失败的问题。
• 验收证据：A-Auth 测试 13 passed；生产健康检查通过；临时 Key 真实验证为直接 internal/auth=204、Console 会话 200、API Key 换会话 200、Console 页面 200，撤销后 401。临时 Key 已撤销。
• 限制：这项改动不等于阶段三全部完成；P3-6 剩余的完整 Manifest、上游同步、Direct Adapter 统一和管理员浏览器交互验收，以及 P3-7 至 P3-12 仍按各自计划状态保留。

🧾 2026-07-31：账户与安全增加可复制 API Key 和本地账户管理

• 已完成：A-Auth 管理员账户页增加 API Key 持久列表、复制按钮、撤销操作和管理员/普通用户权限选择；新 Key 不再只在创建响应中短暂显示。
• 已完成：API Key 以受限 A-Auth 数据库字段保存原文，列表接口仅管理员可访问并设置 no-store；旧版本只保存哈希的 Key 显示为不可恢复，需要重新创建。
• 已完成：本地账户支持创建、角色选择和删除；admin、user 两个固定系统账户继续禁止删除，不引入额外用户组概念。
• 验收证据：A-Auth 测试 14 passed；生产容器健康；数据库迁移已确认 api_keys.key_value 存在；普通登录页和 API Key 登录页均可访问。

🧾 2026-07-31：账户创建确认密码与 API Key 撤销恢复语义补齐

• 已完成：创建本地账户必须输入并确认初始密码；浏览器可分别显示或隐藏两次输入内容，服务端仍会拒绝不一致的请求。
• 已完成：API Key 列表仅显示前半段，完整值不渲染到页面；点击复制时才由管理员接口临时读取。
• 已完成：撤销后列表显示“恢复”，恢复后 Key 重新可复制和登录；永久删除独立保留，会移除 Key 记录与关联会话。
• 验收证据：A-Auth 测试 14 passed，生产容器健康。

🧾 2026-07-31：账户与安全工作区结构重整与动态账户登录修复

• 范围：按当前会话、本地账户管理、创建账户、API Key 管理、创建 API Key 五个独立操作区重做账户与安全页面；不改变 A-Auth 的 FastAPI、SQLite、Argon2id 与 Nginx auth_request 技术栈。
• 已修复：管理员区域不再把列表和表单堆在同一面板；本地账户新增后可按其数据库角色真实登录，不再被旧的固定 admin/user 用户名检查拒绝。固定 admin 继续不可删除、不可由管理员改密；额外账户可删除，固定 user 仍受部署重置流程保护。
• 已实现：API Key 会话在页面和接口均明确为非本地账户会话，禁止修改本地账户密码；管理员修改其他账户密码改为对话框；创建账户双密码确认和同行显示/隐藏保留；API Key 继续部分遮蔽、可复制、撤销、恢复、永久删除，并使用页面 Toast 显示结果。
• 验收证据：A-Auth 自动化测试 14 passed，包括新增账户实际登录、API Key 会话改密拒绝、Key 撤销/恢复/删除与页面结构断言。生产容器和公网页面验证待本次发布后补记。

🧾 2026-07-31：账户与安全回归 Console 壳与 API Key 身份区分

• 已修复：账户与安全不再离开统一工作台；Console 新增“账户与安全”工作区入口，保留左侧完整导航，并在右侧嵌入 A-Auth 页面。A-Auth 继续单独持有账户、密码、API Key 和权限接口，不复制认证逻辑到静态 Console。
• 已修复：API Key 换取的浏览器会话在 Console 和账户页显示为“API Key 管理员身份”或“API Key 普通用户身份”，不再错误显示为 admin 或其他本地账户。反向代理内部身份头使用 ASCII 的 api-key-admin / api-key-user，避免 HTTP 头编码失败；角色授权不变。
• 验收证据：A-Auth 自动化测试 14 passed；Console JavaScript 语法检查、A-Auth 编译、静态 Console CSP（允许 auth.yohan.fun 嵌入）和两个本机容器健康检查均通过。公网页面刷新验收待管理员现有会话实际查看。

🧾 2026-07-31：Console 内账户页 API Key 复制权限修复

• 根因：账户页作为 auth.yohan.fun 跨域 iframe 嵌入 Console 后，Console 的 Permissions-Policy 和 iframe allow 未授予该来源的剪贴板权限，标准复制接口因此返回“浏览器不允许自动复制”。
• 已修复：Console 对账户 iframe 同时授予 clipboard-read / clipboard-write，静态入口的权限策略加入 auth.yohan.fun；A-Auth 复制逻辑增加仅在用户点击触发下执行的 execCommand("copy") 回退。
• 验收证据：A-Auth 测试 14 passed；管理员脚本 JavaScript 语法检查通过；两个生产容器健康；Console 本机响应已返回包含 auth.yohan.fun 的 Permissions-Policy。

🧾 2026-07-31：账户与安全页面取消最大宽度限制

• 根因：账户页虽然使用了全视口背景，但内容容器仍固定 max-width:1320px，在 Console iframe 和独立页面中都会留下大面积左右空白。
• 已修复：账户管理入口注入全宽布局覆盖，取消内容最大宽度限制，保留固定水平内边距；Console 左侧导航和账户页内部内容均可使用完整可用宽度。
• 验收证据：A-Auth 测试 14 passed；页面 HTML 包含全宽布局标记；A-Auth 新镜像已部署，本机健康检查通过。

🧾 2026-08-03：P3-6-2 薄 Runtime 全链路通过并开始 7 天观察

• 阶段/计划：P3-6-2 官方 OmniRoute 模型核心接入。
• 原状态：阶段 0 至 3 已完成；薄 Runtime 与只读 Console 已有代码和隔离回归，生产全链路、Combo attempt 证据和失败告警验收未收口。
• 新状态：阶段 0 至 5 已完成；阶段 6 自 2026-08-03 01:23 CST 起观察，最早于 2026-08-10 01:23 CST 复核阶段 7 最终清理。
• 生产证据：Runtime v0.3.1 镜像 sha256:a524dea9c6b79d671292684f1dd28fc25e7c670d488a240f78b2b8986a13cda3 已部署；任务 14cba090339f4136 在 103 完成 Nomad、273 bytes SQLite Artifact、OmniRoute 分析、Boss 审核和 Job 清理，Artifact SHA-256 为 86fa1c922d47171da3d561c67f5fd906744ec45b79316a9190dd4354480cee99。
• 路由证据：OmniRoute call_logs 的同一 correlation_id=4055a917-dd39-4f05-8d31-dc5696591c63 先记录 AgentRouter 403，再记录 Mistral 200；Runtime 只记录官方最终响应，没有自行推断 attempt。
• 失败证据：受控不存在模型请求 controlled_failure_20260802T171802Z 使 Runtime 返回 HTTP 502 并只持久化 OmniRouteError；HMAC 全局告警事件 de52a730-48dd-4c40-8ccb-be4170af0fe2 已入库并按测试生命周期标记 completed，未泄露凭据或上游正文。
• 数据与边界：完整未脱敏 TAR 34,723,840 bytes，SHA-256 f612b4edec5d395ba9e37417c17eb4f743ae6e87e64eac0720735dcbe6a5e3d6；Cloudreve 公网 WebDAV 回读 TAR、TAR.GZ 和校验文件与本机一致。OmniRoute/Runtime 重启、53/52、迁移 133、SQLite、loopback、A-Auth、只读 Console 和 101/103 无 Provider 凭据均通过。
• Worker 漂移修正：复核发现 103 的固定 Worker 镜像已缺失；已由 101 经 192.168.2.0/24 有线 LAN 直传恢复，Tailnet 只承担控制命令。101/103 当前镜像 ID 均为 sha256:844da7948f2a777f75ffa78166e6e0d46ad93323273e43103b668afea7fa7329，用户均为 10001:10001，临时归档已清理。
• 后续动作：观察期结束前禁止删除 Docker 3.8.48、Provider 原始备份、Runtime 切换前快照、Cloudreve 副本或其他回滚材料；只有 7 天内无解密、迁移、调用和数据异常，且 53/52 基线持续一致时，才执行阶段 7。

🧾 2026-08-03：P3-6-2 完成 root 官方默认原生迁移与旧容器清理

• 阶段/计划：P3-6-2 官方 OmniRoute 模型核心接入。
• 决策更正：项目负责人确认无需等待 7 天；前一条历史记录中的观察期是当时计划，不再是当前执行状态。旧容器清理不触碰正式 Provider 数据和完整迁移备份。
• 原生形态：生产以 root 运行官方全局 npm omniroute@3.8.49，系统 Node 为 22.23.0，systemd 直接执行 /usr/lib/node_modules/omniroute/bin/omniroute.mjs serve。正式数据使用官方默认目录 /root/.omniroute，不使用专用 omniroute 用户、/opt/omniroute 版本软链接、自定义 DATA_DIR 或容器兼容目录。
• Provider 验收：53 条连接、52 个 Provider、2 个 Combo、2 个 API Key、迁移 133、SQLite quick_check=ok 和 aes-256-gcm 均通过；原生服务重启、Runtime 私有代理、公网 omni.yohan.fun 与清理后真实调用均通过。
• 清理结果：旧 OmniRoute/Redis 容器、镜像、Docker 网络、/opt/omniroute、/var/lib/agentmeshos/omniroute-core、旧 Compose/环境文件和专用用户均已删除；根分区使用率由约 79% 降至 73%，实际释放约 4 GiB。
• 保留边界：正式 Provider 数据继续位于 /root/.omniroute；完整迁移备份 /backup/agentmeshos/omniroute-root-native-20260802T191113Z 保留并纳入正式备份轮换，不属于旧容器垃圾数据。
• 计划状态：P3-6-2 已完成，阶段三下一工作包为 P3-7 多 Agent 编排；未来升级继续执行完整备份、隔离恢复、数量核对、协议 Smoke、入口回归和数据快照回滚验证。

🧾 2026-08-04：OmniRoute 免费 Provider 受控真实验证

• 范围：只使用现有 Runtime Key、连接和两个正式 Combo 发起无敏感信息的短生成请求；未新增账号、Cookie、凭据、连接或 Provider，未修改生产路由。
• Combo 结果：Boss agentmeshos-free-quality-first 两次独立请求均命中 FreeModel.dev gpt-5.3-codex 并精确返回标记；Worker agentmeshos-free-capacity-pool 分别命中 Puter o3 和 claude-sonnet-4-6，两次均成功。
• Provider 结果：Groq 与 Hugging Face 各 2/2 成功；Cerebras 分别返回 402 payment required 和 404 no active credentials；OpenCode 两次 90 秒超时，服务端调用日志记录 499 request aborted。MiMoCode、UncloseAI 和 HuggingChat 只读状态未改善，未重新激活。
• 结论：连接健康探测的 active 不等于真实生成可用；没有任何 Provider 被验证为无限制。Groq、Hugging Face 可作为合规补充容量，FreeModel.dev、Puter 继续观察公开额度和使用边界，Cerebras、OpenCode 当前不计入可靠容量。完整矩阵、风险等级和官方限额链接已追加到产品研究页。

🧾 2026-08-05：AI Boss 受控系统操作第一期开始实施

• 阶段/计划：阶段四预备 P4-0 AI Boss 受控系统操作。
• 原状态：AI Boss 可以编排 Nomad、调用固定只读 OmniRoute MCP、写 Artifact 和诊断告警，但不能执行主节点系统恢复动作。
• 新状态：仓库实施中；生产尚未验收。
• 架构决定：采用 Runtime SystemOperationsAdapter 到主节点 root systemd Operation Bridge，不向 Runtime、模型或 Worker提供 Docker Socket、SSH、任意 Shell或主机凭据。
• 首批固定动作：系统诊断、OmniRoute/Runtime/Console/Docs 重启、已登记 Nomad 任务重试/清理、Docs 固定部署/回滚。
• 完成门槛：自动化、HMAC/replay、来源 IP、真实健康复核、双层审计、Runtime 自身重启恢复、Console 和文档站生产发布全部通过后再归档。

🧾 2026-08-05：AI Boss 受控系统操作第一期完成生产验收

• 阶段/计划：阶段四预备 P4-0 AI Boss 受控系统操作。
• 新状态：已完成。
• 自动化：Runtime 与 Bridge 共 29 项测试通过；Console 契约、严格 Docs 构建、计划状态、Python/JS/Shell 语法通过；真实 HMAC请求成功，重复 nonce 与未知 Action分别返回拒绝。
• Bridge：agentmeshos-system-operations-bridge.service 以 root systemd 运行，只监听 172.30.70.1:39184；UFW 只允许 Runtime 172.30.70.2。Runtime 仍为只读根文件系统、CapDrop=ALL、no-new-privileges，无 Docker Socket和 SSH。
• 动作证据：系统诊断、OmniRoute/Console/Docs/Runtime 固定重启、Docs 固定回滚和恢复部署全部通过，审计号分别为 b73a06eea7fa463795397c8f9867a3cd、3a26290189174d2ab712a42daae2154a、68a050be263b4807b2100e0b9599d497、3486767671d64a6cb65ed327594c836b、ffdce0c56cb74fca85033269373a72c6、9270deaa4d7f4658b618474f6e0166c4、e439297da3934851a7fa3aae6f80968c。
• 缺陷修正：服务重启连接重置改为有界重试；Docs 回滚只检查稳定主页和健康面，恢复部署继续检查完整脚本清单。两项均经真实重跑通过。
• 镜像：Runtime sha256:be81c94789253ac30eec46c1091d315667006044449f42cf06b40fb01b75767b，Console sha256:715278db1a5c652b59d0b07677801cb86756b2ba0d814aad5b833426e7527d5c，Docs sha256:ecb2ad0b34703ecd89592faecf4821204a1f567747e861e27f5cffb76c212dba。

🧾 2026-08-05：Project 项目云盘挂载与 AgentMeshOS 单向同步

• 决策：阶段四首个应用方向收敛为个人求职智能工作台，但实施暂停；当前先完善项目资料底座。
• 边界：Cloudreve 账号的 WebDAV 根目录已是既有 Project；不迁入 AgentMeshOS-长期，不下载其他项目到 main，不给 Runtime、Worker、OmniRoute、模型或 MCP 凭据。
• 部署：agentmeshos-project-cloud-mount.service 只读挂载到 /mnt/cloudreve-project；写入探针被拒绝。AgentMeshOS 同步只接受干净且已推送上游的 Git HEAD，固定写入 AgentMeshOS 与 .AgentMeshOS-Recovery。
• 首次验收：云端工作树 208 文件、1,505,901 bytes，下载侧检查 0 差异；恢复资料 3 文件、2,384,626 bytes。Git Bundle 与 Archive SHA-256 分别为 38b3477d9a9b677e707422d20f1b4397030e8fbe3476eeb4f535e340e153f133、428e57f4902ffebd2c620b67d27d0655fd172e6529427b14827078b677db1262。
• 恢复：Bundle 为完整历史，隔离 clone、git fsck --full 和提交 2415c502c97c14955cdda630b566a84bc65996e8 恢复通过；其他云端项目未修改。
• 缺陷修正：后续同步发现 WebDAV 无可用哈希且同长度 manifest 被 rclone 默认大小/时间判断跳过；提交 363c262 对 Bundle、Archive、manifest 强制 --ignore-times。修正后手工与 systemd 路径均为 208 文件、0 差异，云端三类恢复资料统一到 363c26237a469fe15f3b61bd461271ac2a944ab0；新 Bundle 与 Archive SHA-256 分别为 7d92ab01b46cd9ad8f8816aab35c80f93f79c4e47f1561205cd949a217f1ed85、9346a0a3055e9c54c410a2b6d9fb033c225dab1de57b826e44e287010e71afa5。

🧾 2026-08-17：P5 核心生产闭环复验

• 阶段/计划：phase-5-ai-boss-active-loop-planning，阶段五仍为实施中，尚未进入 P6。
• 内部任务闭环：合成事件运行 e377035ff1da4c658efe435d4ece30df 创建并关联 P4-v1 任务 b0b41bbc5c7d4500。任务完成后成果 b31dfaa19cd14f318014ad9642bccc81 为 accepted、needs_benson=0；确定性检查、证据登记和 AI BOSS 结构化审核均有通过记录。主动运行只在关联任务最终完成后标记完成，不重放任务创建或模型调用。
• 运行控制：已生产验证真实定时间隔窗口、合成事件、全局暂停抑制、取消关联任务、受控重新运行创建新 run_id，以及 Runtime 启动时将未完成运行标为 interrupted 且不自动重放。所有临时验收策略均已停用，全局暂停恢复为未暂停。
• 自动化：Runtime 13 个测试文件共 183 passed；API Gateway、Console 静态和浏览器契约、镜像清理器、计划状态校验和严格 Docs 构建均通过。最后保留的出口是已登录公网 Console 的人工交互回归；在其完成前不得把 P5 归档。

🧾 2026-08-17：P5 可见预算与任务证据顺序更正

• 根因：主动工作概览没有携带工作台日预算，Console 因而显示 -- / --；当工作台没有保存额度时，Runtime 还会从环境变量读取历史 5,000,000 Token 默认值。这与“工作台设置为无限制即无限制”的现行约束冲突。
• 修复：active-work 概览返回与 AI BOSS 对话共用的日用量快照；Console 对无限制明确显示“无限制”。Runtime 删除环境变量日额度回退，只有 Benson 在工作台显式保存有限值才会启用日额度准入；未设置或 0 都保持无限制。
• 并发回归：全量回归同时暴露主节点 P4 任务曾在登记执行边界证据前暴露 boss_review 状态。执行顺序已调整为先完成运行记录并登记证据，再使任务进入审核状态，避免读者看到“可审核但缺证据”的瞬态不一致。专项连续复验 5 次和完整 Runtime 183 passed 均通过。

🧾 2026-08-17：阶段五完成归档，阶段六进入规划

• 计划 ID：phase-6-discovery-experiments-planning。阶段五的 Runtime SQLite 策略、进程内循环、三类触发、暂停/终止、取消、受控重新运行、失败停用、重启中断和审计已完成自动化与生产验收。
• 最终公网交互：管理员会话在真实 Console 通过居中自定义确认弹窗依次完成事件策略启用、全局暂停、全局恢复和策略停用。每步立即持久化回显，运行记录维持 11 条，未产生新运行、模型调用或任务；所有主动工作请求返回 200。终态为全局未暂停、无已排定运行、所有验收策略停用，桌面 1440x900 与移动 390x844 无横向溢出。
• 状态变化：阶段五已完成并归档；阶段六为“规划中，尚未实施”。本次状态切换不创建应用表、来源读取、应用策略、Worker、Console 页面或任何后台运行。

🧾 2026-08-17：P3 固定机会发现原型退役

• 原记录：P3 历史计划曾把固定 GitHub 搜索、关键词触发、候选去重和候选登记称为“通用机会发现”。
• 更正：该实现只是早期技术原型，不是当前生产业务应用，也不代表阶段六已经具备职位或商业机会发现能力。
• 清理：Runtime 已删除固定 URL、关键词自动触发、候选表及精确匹配的旧自动任务和候选数据；不保留兼容开关或迁移入口。
• 保留边界：source_research 与 candidate_analysis 是通用已授权公开资料研究和分析角色，继续服务于现有受控任务；它们不创建机会候选，也不自行访问外部来源。
• 后续：阶段六若获实施授权，使用独立应用模型重建来源、候选、证据、匹配和反馈闭环，不迁入旧数据。

🧾 2026-08-18：P6-P8 应用中心路线重定义

• 计划 ID：phase-6-application-center-foundation-planning。AgentMeshOS 主体定位明确为“AI 应用运行平台 / AI 操作系统”，项目仓库负责开发、构建、测试与发布，不作为生产运行时依赖。
• 路线变化：阶段六调整为“应用中心基础与本地应用样板”，先建立内置应用注册表、Console 应用中心和“本地资料分析与验收工作台”；阶段七调整为“本地应用 MVP 与应用运行规范”；阶段八调整为“多应用扩展与应用生命周期”。
• 原计划处理：旧“第一个 AI 应用的发现与试验闭环”和个人求职方向从未实施，现已退出当前 P6；旧 URL 只保留兼容入口。求职应用仅作为 P8 或以后可重新评估的候选，不自动恢复。
• 技术选择：继续使用现有 FastAPI、SQLite、Vanilla JavaScript、Runtime、Nomad 和 Cloudreve，先采用内置应用注册，不引入 React、微前端、动态插件市场、第二 Runtime、第二调度器或消息队列。
• 状态边界：本次只更新计划、架构、导航和校验，不创建应用表、API、Worker、Console 应用页面、策略或后台运行。P6 继续保持“规划中，尚未实施”。

🧾 2026-08-18：P6-P8 完整实施计划冻结

• 计划 ID：phase-6-application-center-foundation-plan-refinement。当前阶段明确为 P6（阶段六）“应用中心基础与本地应用样板”，状态为“计划完善中，尚未实施”；P7、P8 仍是有明确进入条件的后续阶段，不与 P6 同时标记为当前或进行中。
• P6：形成 P6-0 至 P6-9 的完整工作包，冻结应用 Manifest、注册与运行状态机、数据对象、Runtime API、Console 应用中心、本地资料样板、Cloudreve 数据面、平台对象关联、重启恢复、发布批次和阶段出口。
• P7：形成 P7-0 至 P7-8 的完整工作包，冻结首个本地应用的稳定设置、输入集合、运行、成果、历史版本、受控重新运行、用量成本、导出、备份恢复、连续使用、生产发布和归档条件。
• P8：形成 P8-0 至 P8-8 的完整工作包，冻结多应用身份、隔离、预算成本告警、生命周期、升级回滚、第二应用选择、双应用并行验收和阶段出口；第二应用不预设为求职应用。
• 统一边界：继续采用 FastAPI + SQLite + Vanilla JavaScript，复用 Runtime、OmniRoute、Nomad 和 Cloudreve；Manifest 使用稳定 application_key，Runtime 注册实例使用永不复用的 application_id；Cloudreve 文件由主节点 StorageAdapter 经公网 HTTPS 下载、校验和解析，不向 Worker 传文件；P8 应用预算只是统一可见账本的子限额，一次调用只记一次用量；无限 Token 设置不得被隐藏内部上限覆盖；所有确认使用项目主题的居中自定义弹窗。
• 实施边界：本次没有创建或修改 Runtime 应用表、应用 API、Console 应用页面、Worker、模型调用、后台策略或生产运行。只有三份计划完成审阅、校验、GitHub 同步和 Docs 发布，并由 Benson 明确授权后，P6 才可切换为“进行中”。

🧾 2026-08-18：P6 正式切换为进行中

• 计划 ID：phase-6-application-center-foundation-started。P6、P7、P8 的完整计划已经细化、交叉审阅、GitHub 同步、Docs CI、生产发布和公网回读；“计划完善中”与“规划中”不再代表三份现行计划。
• 状态模型更正：机器状态源升级为计划状态、阶段状态和当前工作包三个独立字段，避免再次把“计划写完”和“功能做完”混为一谈。
• 当前状态：P6 计划已完成，阶段进行中，当前工作包为 P6-0“契约冻结与生产基线”；P7、P8 计划已完成，分别等待 P6、P7 完成并归档。
• 实施边界：本次状态切换只授权进入 P6-0，不代表应用注册表、数据库、API、Console 应用中心、本地资料样板或生产验收已经完成；P6-1 以后仍必须按依赖和批次验收推进。

🧾 2026-08-18：P7 完成归档，P8 等待实施

• 计划 ID：phase-8-application-expansion。P7 已完成设置版本、资料集、运行快照、历史比较、导出、备份恢复和受控重新运行；Runtime 重启保持 awaiting_benson，只中断真正未完成运行。
• 验收：Runtime 201 passed；Console 契约通过；生产 Runtime、Console、Docs 健康与公网回读通过；桌面 1440x900、移动 390x844 登录态浏览器验收通过。
• 状态变化：P7 已完成并归档；当前阶段切换为 P8，计划已完成、阶段等待实施。

🧾 2026-08-18：P8 完成归档，进入 P9 待规划

• 计划 ID：phase-8-application-expansion。
• P8-0 至 P8-8 已完成；Runtime 206 passed、P8/P7/P6 定向测试 20 passed，生产 PPTX 已生成、下载并由 Benson 确认，桌面与移动端登录态浏览器验收通过。
• PPTX 文件唯一权威存储为 DD 节点 Cloudreve 的 AgentMeshOS-长期/runtime-artifacts/applications/；Runtime SQLite 的 application_artifacts 只保存元数据、引用和 SHA-256。
• 状态变化：P8 完成归档；当前阶段切换为 P9“后续阶段待规划”，不启动新的代码、模型调用或后台任务。

🧾 2026-08-18：P9 占位状态建立

• 计划 ID：phase-9-placeholder。P9 仅作为当前状态占位，尚未形成新的实施计划。

🧾 2026-08-30：DETACH-07 项目控制对象边界核验

• RR 现场未发现 Project/rclone/bisync 服务、timer、挂载、进程或专用路径；/root/project 为空。
• agentmeshos-system-operations-bridge.service 仍为生产 Bridge，enabled/active，监听 172.30.70.1:39184，不得作为 Project 控制对象停用。
• 因此本次不执行停止、禁用、删除或凭据变更；DETACH-07 进入“调查中”，等待完整前置验收和精确停用清单。

🧾 2026-08-30：DETACH-09 最终门禁快照

• 双端身份、备份盘、生产服务、公网入口、版本化接收/回滚、凭据与恢复材料保留均通过；RR Project 控制对象为空，生产 Bridge 服务级 restart 通过。
• 整机重启和单节点故障连续性尚未执行，等待维护窗口；最终清理门未开启，101 误部署 Bridge 继续保持停用且不删除。

🧾 2026-08-30：DETACH-09 维护窗口执行与受控清理

• 按已授权的一小时维护窗口完成 RR、101 整机重启恢复；两端系统身份、SSH、物理默认路由、Tailnet、系统 Codex/ App Server（101）及生产服务复测通过。
• RR Bridge 受控停止约 5 秒后恢复，公网 Docs 健康检查保持 200；该故障模拟只证明服务级恢复，RR 单生产节点无法证明整机不可用时的高可用接管。
• Docs 完成 :rollback 镜像回滚并恢复正式固定版本 ghcr.io/michaellab7284/agentmeshos-docs:sha-4636e1c，回滚前后均 healthy。
• 101 误部署 Bridge 的停用 unit、安装树和空 Docker 网络已删除；凭据、审计目录/数据库、备份快照均保留。RR 退役且无引用的 JuiceFS CSI、Python、MinIO 客户端和 rclone 镜像已逐项删除，生产与 rollback 镜像未删除。
• 删除前快照位于 101 独立备份盘 /srv/codex-hub-backup 和 RR /backup，SHA-256 校验通过；清理后服务、公网入口和容器健康复测通过。
• DETACH-09 状态更新为“待验收：单生产节点连续性限制”，不把单节点拓扑下的服务恢复误写成高可用连续性完成。

🧾 2026-08-30：AgentMeshOS 系统剥离目标收口

• DETACH-01 至 DETACH-09 的交付物、现场证据、凭据/审计/备份保留边界和 GitHub CI 记录均已完成复核。
• DETACH-09 更新为“已完成（保留单生产节点连续性限制）”；该限制是 RR 当前单生产节点拓扑的残余风险，不是未执行的维护动作，也不代表系统具备高可用接管。

🧾 2026-08-30：RR 主机剥离后空间清理与复测

• 清理前先通过 RR 专用 SSH 入口核验 hostname=rr、物理地址 96.44.133.235、Tailnet 100.64.0.1 和根盘 /dev/vda2；本次未操作 101。
• 仅在 RR 清理：npm 缓存、Playwright 可重建缓存，以及工作目录明确为旧 /root/project/AgentMeshOS 的 Codex 会话（活动与归档、含升级备份副本）。共删除 575 个会话文件，约 7.73GB；保留 /root 系统维护会话、系统 Codex、日志数据库、凭据和生产服务。
• npm cache verify 期间自动回收约 295MB 无效缓存；随后 npm 缓存清理完成。Playwright 缓存清理后目录保留为空目录，后续需要时可重新下载。
• RR 系统盘由约 78%（约 13GB 可用）变为约 57%（约 24GB 可用）。当前 /root/.codex 约 1.5G、/root/temp 约 928M、/var/lib/containerd 约 5.6G、活动 swap 约 4G、/backup 约 537M；这些对象未继续删除。
• 清理后 agentmeshos-system-operations-bridge、Nomad、Docker 均 active，Bridge/Nomad/metrics 监听正常，10 个生产容器运行，系统 Codex App Server socket 存在，公网 Docs healthz=200。
• 后续仍需单独评估的项目：RR /root/temp 中残余系统工具/恢复材料、日志保留周期、容器 rollback 镜像和 containerd 共享层；不得用 docker system prune 或批量删除替代逐项确认。

🧾 2026-08-30：Issue #35 101/RR 生产职责最终剥离

• 边界确认：101 只保留项目工作区、Project 专用凭据、项目控制和节点自身工具；RR 保留生产 Runtime、System Operations Bridge、系统自动化 WebDAV 凭据、生产审计和运行载荷。
• 101 无 Runtime/Bridge 服务、容器、监听或消费者后，删除 /etc/agentmeshos/cloudreve-agentmeshos-automation-webdav.env、ai-runtime.env、system-operations-bridge.env、Bridge audits.db 及空运行目录；未删除 Project 凭据、项目仓库、部署模板或 101 节点工具。
• RR /etc/agentmeshos/cloudreve-system-webdav.env、ai-runtime.env、system-operations-bridge.env 均保留，Bridge/Nomad/Docker active，生产容器运行。仓库 Runtime 部署模板默认路径已与 RR 实际文件名对齐。
• 撤回本轮对 101 备份脚本的越界改造，恢复其原有实现；Project 同步和三渠道备份继续由独立任务负责，本剥离任务未启用任何同步、rclone/bisync 服务或 timer。

🧾 2026-09-26：P9 关闭，P10 接管 MM 公网 IP 可替换整改

• 计划 ID：phase-10-mm-public-ip-replaceable-architecture。P9 已关闭，不再实施；P10 成为当前阶段。
• P9 的真实完成度按“已关闭，不再实施”登记，不写成“全部完成”。已实现脚本、Runtime 接口和 Console 代码保留为历史资产，未完成的三平台 ACL、真实接入和撤销清理验收不再阻塞 P10。
• P10 继续使用原计划《MM 公网 IP 可替换架构整改方案（2026-09-25）》的计划身份，后续修订只追加和修订受影响的章节、工作包与账本，不创建平行替代计划。
• 当前工作包为 P10-0 计划身份固化、文档库 review 与状态机治理；全量文档 review 完成前，不修改现网 DNS、网络、SSH、DERP、路由器或生产配置。

🧾 2026-09-26：P10-0 生产可见性与控制台认证回读关闭

• 使用用户提供的临时管理 API Key 在真实浏览器换取可撤销 HttpOnly 会话，未把 Key 写入仓库、文件、日志或普通回复；登录身份回读为“API Key 管理员身份 · 管理员”。
• 控制台 https://console.yohan.fun/#docsPlans 的 iframe 实际加载 https://docs.yohan.fun/plans/，点击“P10 详细计划”后进入 https://docs.yohan.fun/plans/phase-10-mm-public-ip-replaceable-architecture/；正文断言包含 P10-0、P10-8、rev.7、111 个 和 Repository Guardrails。
• 生产 Docs、公网计划页、控制台嵌入页和文档清单门禁证据齐备，P10-0 关闭；当前工作包切换为 P10-1 DNS 与域名清单冻结。
• P10-1 继续以域名导出表、管理台截图和现场 dig 三方核对记录类型、目标、TTL、证书、回源和例外；冻结完成前不修改现网 DNS。

🧾 2026-09-26：P10 完成归档，P11 当前阶段

• 计划 ID：mm-public-ip-replaceable-architecture。P10-0 至 P10-8 已完成计划、代码、文档、CI 和生产验收收口，P10 完成归档；当前计划 ID 切换为 phase-11-requirement-review，P11 当前阶段仅建立需求评审占位，未选定新的实施主题。
• 当前计划 ID：phase-11-requirement-review；P11 只保留需求评审占位，不宣称已经选定或实施新的功能。
• 稳定模型：edge.yohan.fun 是逻辑边缘身份，业务域名只用 CNAME 跟随；活跃配置不保存 MM 公网 IPv4/IPv6，运行时地址只存在于受控快照和 last-known-good。
• 管理恢复：RR、101、Home 保留公网与 Tailnet 双通道，DD、MM 不扩大反向管理权限；直连优先、DERP 为辅，MM region 900 与 DD region 901 的边界已登记。
• 观测与控制台：Gateway 提供脱敏拓扑和 ClawBot 状态，Console 首页和 Provider 页完成桌面与移动端回归；业务站点故障显示真实红链，但不再单独触发整网冷连接告警。
• 切换边界：隔离环境已完成候选地址、非法 Tailnet 地址拒绝、last-known-good 保持和回滚校验；真实第二生产边缘切换因缺少独立证书、回源、资源和维护窗口，保留为外部运维前置，不写成已执行。
• 状态变化：P10 完成归档；阶段十一计划进入“等待实施、修订中”，当前工作包为 P11-0 需求评审与计划冻结。

🧾 2026-09-26：P11 原地冻结网络可替换、告警治理与节点纳管

• 计划 ID 继续使用 phase-11-requirement-review，在原 P11 占位页原地升级计划和账本，不创建平行计划、不重新打开已归档的 P10。
• P11 主题冻结为“AgentMeshOS 网络可替换、告警治理与节点纳管”，当前工作包为 P11-6 发布与验收；工作范围包括硬编码地址防复发、告警路由、整页拓扑、微信 ClawBot 和 dog-public 纳管。
• 网络语义继续以 edge.yohan.fun 为唯一逻辑边缘身份；MM 只是当前承载入口的主机，不使用绑定具体主机的 mm-edge 名称。
• 101 系统告警统一读取 root-only 告警路由配置并投递到当前协调线程；旧线程只保留历史身份，不再作为生产默认目标。
• 本轮首次本地回归发现整页拓扑重新进入时的数据流动画与架构状态文本未同步，随后修复并进入全量测试、Actions、101 Runner 和 RR 生产部署验收。

🧾 2026-09-27：P11 完成 dog-public 纳管与发布链增量更新

• dog-public 已完成 edge-gateway 画像纳管：101 的公网入口 173.249.205.221:36406 与 Tailnet 入口 100.64.0.3:36406 均在严格主机校验下返回 20260926。
• 现场 Tailscale 为 Running、Health=[]，Nomad Client 为 ready，Docker 与 exec 驱动健康，100.64.0.3:9100/metrics 返回 200；宝塔 16973、Nginx 80/888、Shadowsocks Rust 61158 和 SSH 36406 保持原监听。
• 首次部署失败已分离为两个根因：Headscale 预授权密钥过期，以及错误使用 global-cli-nomad 证书。Bridge 代码已收紧为只接受 global-client-nomad.pem 和对应私钥，避免再次误用 CLI 证书。
• 严格证书契约修复提交为 df20555，本地全量门禁为 210 passed；RR Bridge current 已原子切换到该 release，健康检查返回 healthy，旧 release b882066 保留为回退点。
• 提交 df20555 的 Repository Guardrails 36254772304 与 Docs 生产部署 36254772354 成功；文档叠加提交 5721d4a 的 Guardrails 36254966095 与 Docs 生产部署 36254966592 成功，公网文档站已回读本轮 P11 事实。
• dog-public 的 72 小时观察从 2026-09-27 00:09 CST 开始。ThreeDogs 正式迁移、边缘备用接管和 DERP 备用启用均未执行，必须等待观察结果和单独切换窗口。

🧾 2026-09-27：P11-3 微信 ClawBot 宿主与绑定链路实现

• RR 现场已安装 Node v22.23.0、OpenClaw 2026.7.35 (aa94808) 和腾讯微信插件 @tencent-weixin/openclaw-weixin@2.4.9；openclaw config validate 通过，插件状态为 activated=true、status=loaded，Gateway 只监听 127.0.0.1:18789，微信当前仍为 configured=false。
• 宿主 RPC web.login.start/wait 返回 INVALID_REQUEST: web login provider is not available；根因是腾讯插件当前版本没有向宿主声明 gatewayMethods。实现没有修改官方插件或宿主源码，改用固定官方 CLI openclaw --log-level silent channels login --channel openclaw-weixin --account <binding_id>。
• System Operations Bridge 新增固定来源、HMAC 校验的管理员绑定接口；PTY reader 只在内存提取并渲染二维码，返回短期 PNG data URL，不持久化二维码、登录 URL、Cookie、Token 和原始日志。
• Runtime 新增管理员专属 /boss/v1/clawbot/binding/start、状态和取消路由；Console Provider 页新增绑定入口、二维码显示、轮询、取消和绑定成功后的脱敏状态回读。
• 状态生成器已适配当前 OpenClaw 输出中的 channels.openclaw-weixin.configured，并补充真实输出形态、未绑定形态和旧数组形态回归。
• 本轮代码和本地契约已通过；生产部署与真实微信扫码尚未执行。宿主、插件或 Gateway active 都不能写成“微信已绑定”，P11-3 和 P11 继续保持进行中。

🧾 2026-09-27：P11-3 ClawBot 模型链路修复与绑定路径复核

• 根因一：RR OpenClaw 默认模型仍为 openai/gpt-5.5，本机没有 OpenAI API Key，Gateway 日志返回 ProviderAuthError: No API key found for provider "openai"。修复不写 OpenAI Key、不改官方宿主或腾讯插件源码，改为官方自定义 OpenAI-compatible Provider agentmeshos，Base URL 为 http://127.0.0.1:39180/v1，默认模型为 agentmeshos/agentmeshos-free-quality-first。
• 根因二：agentmeshos-model-client 原先只在 allowedModels 放行两个 Combo 名称。OmniRoute 调用 Combo 时会逐个检查内部目标模型权限，因此目标模型在正式调用前被预先跳过。AI Runtime 部署脚本现从官方 Combo 目录生成去重目标模型白名单；RR 已应用 194 个目标模型，Combo 调用返回 HTTP 200，非法模型返回 403，权限回读一致。
• 新增 scripts/maintenance/agentmeshos-clawbot-model-provider.sh，通过官方 openclaw config patch、环境 SecretRef 和 user systemd drop-in 管理模型 Provider；部署前备份 OpenClaw 配置与 drop-in，健康检查失败时自动恢复。回退目录为 /var/lib/agentmeshos/clawbot/model-provider/rollback/，不包含 AgentMeshOS 模型 Key。
• RR 现场 agentmeshos-clawbot-model-provider.sh health 和 deploy 均通过；openclaw infer model run --gateway 使用真实 Gateway 返回 .ok=true，openclaw models list --json 显示两个 agentmeshos/ 模型可用，Gateway 继续只监听 127.0.0.1:18789 和 [::1]:18789。
• 绑定接口已在 RR 真实执行：POST /boss/v1/clawbot/binding/start 返回合法 32 位 binding id，轮询进入 waiting_scan 且 qr_data_url 在内存中存在；随后 cancel 返回 cancelled 和 binding_cancelled。验证过程没有扫码、没有输出二维码内容、没有把二维码写入文件。
• 本轮仍未完成真实微信扫码、合法管理员会话下的 Console 页面回读和最终生产发布。ClawBot 模型链路可用不等于微信已绑定，P11-3 与 P11 继续保持进行中。

🧾 2026-09-28：Runner、网络态势与 Runtime MCP 权限复核

• 101 的 Docs Run 36353513155 根因是主机全局 OOM 打断 Runner，直接触发进程为异常膨胀到约 7.2 GiB 的 grep；活动 Runner 已收敛为单实例并增加 MemoryHigh=3G、MemoryMax=4G、整组回收和失败重启。提交 0464579 的 Docs Run 36354537606 与 Guardrails Run 36354537307 验证了正向恢复。
• 持久化 Runner 在 actions/runner v2.337.0 上命中上游 #4728 的 Job 所有权交接缺陷：Run 36355038100 的部署 Job 为 runner_id=0、零步骤且注解为未获取 Job。新增恢复器只在这些条件同时命中时使用 GitHub 托管 Runner 重跑；普通失败、构建失败、部署失败和达到尝试上限均不触发。提交 7b46e77 的 Guardrails 36355662477 与 Docs 36355662676 全成功。
• 网络态势的 edge/GW 已由逻辑边缘健康状态独立判定，生产回读为 healthy；同一对节点之间的多条公网、SSH 和 Tailnet 路径按固定 lane 分道，浏览器契约验证路径字符串唯一且分道间距不小于 40。最终读回时 RR → 101 仍走 DERP(agentmeshos-mm)，所以 25 项状态中为 23 项 healthy、2 项 degraded；该 2 项不是 GW 或公网入口故障。360T7 已现场确认 firewall.@defaults[0].fullcone=1，残余更可能来自运营商 NAT 或 101 双网卡路径。
• 提交 14ea30b 的 Repository Guardrails 36356054184 与 Docs Run 36356054205 全成功；RR Docs 容器回读为 sha-14ea30bcbe882415fcf575015a12d95ab65bf21d 且 healthy，公网 Docs 健康端点返回 HTTP 200。
• 官方 OmniRoute 3.8.50 已在 RR 用 agentmeshos-model-client 复测 /api/mcp/tools 与 /api/mcp/stream，两者仍返回 403 AUTH_001。该结果把普通 Key限制从“待 3.8.50 复测”收敛为已确认的上游权限缺口；Runtime 继续使用受控管理 Key兼容，不扩大普通 Key权限。

🧾 2026-10-01：P12 当前阶段，P11 冻结归档

• 计划 ID：phase-12-pcdell-102-omniroute-migration。P11 已完成范围冻结并归档，ThreeDogs、DERP、Claude 和微信 ClawBot 暂停、收尾、归档、冻结；不再从 P11 自动派生任务。
• 用户明确确认 P12 只针对 102，范围包括 102 节点收尾和 OmniRoute 从 RR 到 102 的迁移；迁移必须先 review 计划，确认前不执行。
• P11 完成归档正文为 completed-phase-11-agentmeshos-network-governance.md，原始过程页继续保留为 phase-11-placeholder.md。
• 当前工作包为 P12-0 102 基线与迁移方案复核；只有完成当前事实采集、容量核验、数据恢复和回退评审后，才允许进入后续工作包。
• 状态变化：P11 完成归档；P12 当前阶段为“102 节点收尾与 OmniRoute 迁移评审”，阶段状态等待实施。

🧾 2026-10-01：P12/P13 职责拆分与正式移交接口

• 计划 ID：phase-12-pcdell-102-final-acceptance。该记录更正同日早先把 102 纳管和 OmniRoute 迁移混在同一个 P12 范围的描述，不覆盖历史原文。
• P12 正式收敛为唯一工作包 P12-0 102 节点纳管一次性最终验收，只保留用户确认的 8 项验收、关闭条件和 P12→P13 移交契约。
• OmniRoute 迁移转入 P13：OmniRoute latest stable 原生迁移草案。P13 在执行时一次性直接安装官方 npm latest stable，不先装旧版；数据迁移使用官方 backup create、一致性快照和完整宿主配置核对，不能只导入 .env。
• 当前阶段仍为 P12，P13 只登记为后续草案。P12 关闭并由用户明确授权后，才允许把 state.json 切换到阶段 13、进入 P13-0，并重新查询 exact latest stable、tarball、integrity、shasum、Node 兼容、容量和差异。
• 当前生产权威仍为 RR OmniRoute；102 全链路、回退和稳定性验收通过前不切换 MM 回源、不停用 RR 数据，任意时刻只允许一个 SQLite 写者。

🧾 2026-10-01：P12-0 授权执行与 102 节点现场验收

• 计划 ID：phase-12-pcdell-102-final-acceptance。用户明确授权开始 P12-0 后，当前阶段状态从“等待实施”更新为“进行中”。
• 必需项 1 至 6 和第 8 项已通过：身份地址一致、SSH 10222 公钥与 root/hhtbing 身份边界、Tailscale/Docker/Nomad/node_exporter 状态、RR 的 9100 采集、RR/101/Home 三管理入口、系统卫生和 OmniRoute 独立边界均有现场回读证据。
• 102 现场身份为 pcdell-102；有线 192.168.50.102、WiFi 192.168.50.202、Tailnet 100.64.0.4，360T7 预留和实际租约一致。RR 读取 node_uname_info{nodename="pcdell-102"} 成功。
• Nomad 使用 100.64.0.4:39046、TLS 和 ACL；RR 端回读 pcdell-102 为 ready/eligible，Docker/exec 驱动为 Healthy。node_exporter 使用官方容器 v1.9.1，容器、进程和监听均只有 1 个。
• UFW 只允许 RR 100.64.0.1 访问 102 的 9100；从 101 访问该端口被拒绝。systemctl --failed 为空。
• 第 7 项重启持久性复核因维护窗口未确认而未执行，不能写成通过；102 节点纳管保持打开，等待用户决定安排窗口或明确接受残余风险。
• 本轮未在 101、RR、102 或 MM 安装、恢复、迁移或切换 OmniRoute；P13 仍未启动。

🧾 2026-10-01：P12 完成归档，P13 当前阶段等待实施

• 计划 ID：phase-13-omniroute-latest-stable-migration。
• 计划 ID：phase-12-pcdell-102-final-acceptance。102 节点纳管的 8 项验收全部通过并完成归档；完成记录为 completed-phase-12-pcdell-102-final-acceptance.md。
• 用户在维护窗口完成重启后，P12-0 又执行最终受控重启复核：新 boot_id=bd3d4e88-5118-4805-b1d6-f8766c8a4a6b，身份、双网地址、SSH 10222、Tailscale、Docker、Nomad Client、node_exporter、RR 遥测、RR/101/Home 三入口、UFW 和 systemctl --failed 均通过。
• 最终重启暴露 openipmi.service 在无 IPMI 硬件的 Dell OptiPlex 7050 上 failed；记录状态后执行 disable、mask 和 reset-failed，最终 failed unit 为空，回退为 unmask 和 enable。
• Linux 节点遥测脚本 v0.2.2 的 filter INPUT 守卫会被 Tailscale 的 ts-input 链重新置前并绕过。脚本升级为 v0.2.3，在 raw PREROUTING 前置执行来源限制；102 安装 SHA-256 为 13c702a781f7e424350c1ddb02bf11b14101458fecdf24bac40debcf13366f5c，101 负向访问超时、RR 正向 HTTP 200。
• P12 完成归档，P12 不再拆出零散任务。状态机切换到 P13 当前阶段，P13 状态为“等待实施”，当前工作包为 P13-0 latest 查询、版本差异、容量与回退设计。
• P13 当前仍未取得执行授权：102 未安装 OmniRoute、未恢复 RR 数据、MM 回源未切换、RR 仍是唯一生产权威，任意时刻只允许一个 SQLite 写者。

🧾 2026-10-01：P13 完成归档，P14 当前阶段等待实施

• 计划 ID：phase-14-placeholder。P13 已完成并归档，102 官方 omniroute@3.8.51 成为唯一生产 OmniRoute 权威；完成后状态机切换到 P14“后续阶段待新增需求评审”，阶段状态为“等待实施”。
• P13 完成官方 latest 一次性安装、RR 一致性快照恢复、生产切换、Boss/Worker、Codex Responses、管理 API、SQLite、负向鉴权和真实回退。P13-B 将 MM 面板 JSON 与渲染 nginx conf 都改为直连 100.64.0.4:39200。
• P13-C 按用户决定取消固定等待期并删除 RR 上的 omni 数据、全局包、service、cutover 备份、历史 omni 备份和 omni vhost。保留 RR Runtime 私有代理，因为本机 agentmeshos-ai-runtime 容器仍使用 172.30.70.1:39181 → 100.64.0.4:39200；保留 active swap 和 Codex MCP 凭据。
• RR origin gateway 生成脚本升级为 v0.6.2，不再生成 omni.yohan.fun；agentmeshos-omniroute-cutover.sh 因 RR 本地 OmniRoute 和 omni vhost 均已不存在而删除。决策依据是死配置会在脚本重跑时复活，保留它反而制造第二套失真切换路径。
• 2026-10-01 最新只读观察为 pass/critical=0/warnings=0：102 为 3.8.51、active/running/enabled、NRestarts=0、quick_check=ok、70 个连接、19 个 Combo、4 个 API Key；RR omni 数据、包、service 与 cutover 备份均不存在，Runtime 代理目标为 102，公网 health 为 200/healthy。
• 提交 64d291d 的 P13 RR 退役与健康观察迁移已经推送，post-push-verify.sh 及必需 GitHub Actions 全部通过。P13 最终归档提交仍会重新执行本地完整测试、远端 SHA 核对和全部必需工作流。
• P13 完成归档正文为 completed-phase-13-omniroute-latest-stable-migration.md，原计划保留为 phase-13-omniroute-latest-stable-migration.md。
• P14 只是需求评审占位，不包含新增安装、数据修改、服务切换或权限扩大；discovery、媒体、语义缓存、日志正文导出和 Worker 空响应观察均不自动转为 P14 工作包。

🧾 2026-10-11：P18 中国网络可达性探针计划建立

• 计划 ID：phase-18-placeholder。P17 仍为当前阶段，P18 登记为“等待 P17 完成并归档”，不改变 state.json 的当前阶段。
• 用户确认常态监控默认使用华南，当前定义为深圳、广州和东莞共 13 个在线探针；五台 VPS 每小时一次，预计消耗 65 tests，低于 Globalping 注册用户 500 tests/hour 免费额度。
• 临时自测支持公网 IP、替换 IP 和域名，同时运行 ICMP Ping 与 TCP 443，异常时运行 MTR，并提供 ping.pe 人工佐证入口；不使用 ping.pe 自动化抓取。
• 常态自动监控使用 Globalping 官方 API；Globalping 凭据固定为 RR 上 /etc/agentmeshos/globalping.env，必须为 root:root 0600，服务通过 systemd LoadCredential 读取。
• 凭据文件不属于项目工作树，不进入 Git、镜像、安装包或部署载荷；部署脚本只校验存在性、所有者和权限，不创建、覆盖、删除、复制或打印 Token，发布前后必须核对 SHA-256 不变。
• P18 计划已写入 phase-18-placeholder.md，P17 归档前不执行 P18-0 至 P18-8，也不启用采集 timer 或临时自测服务。

🧾 2026-10-11：P18 用户授权提前执行

• 用户明确要求“P18 开始执行”，并确认 Globalping 凭据已经写入 RR /etc/agentmeshos/globalping.env。state.json 当前阶段仍保持 P17，避免把未完成的 P17 客户端验收写成已归档。
• P18 已从等待前置切换为“P18-7 测试、部署与发布”。采集器、临时自测服务、API Gateway 投影、Console 状态卡、Gateway 路由和部署脚本进入本地完整门禁与生产发布验证。

🧾 2026-10-11：P18 生产部署与验证

• 提交 c11ba08 完成 Globalping 客户端、自动采集器、临时自测服务、API 投影、Console 状态卡、Gateway 路由和部署脚本；后续 2020b50 补齐 API 返回 public_ipv4。两次精确 SHA 的 post_push_verify 均为 pass。
• RR 已运行 agentmeshos-network-probe.service 和 agentmeshos-network-collector.timer；网络探针只监听 127.0.0.1:39185，凭据 SHA-256 部署前后保持 98d3ba18abac42b89b21a74cc86ebd532e162447374cdf949ba981999cb1ca3d，服务使用 systemd LoadCredential 和严格权限。
• 华南自动快照五台齐全，当前 4 台正常、d02 轻度异常；真实临时自测完成全国 ICMP + TCP 443 与 SQLite 历史读取；深圳 MTR 返回 finished 并包含 6 个探针。
• API Gateway 和 Console 精确镜像已自动部署；API 返回五台 public_ipv4，生产 app.js 和 styles.css 已包含中国可达性状态卡与临时 IP 自测界面。管理员登录态浏览器截图和表单提交仍待用户会话。

🧾 2026-10-12：P18 可视化修正、生产自测与结案

• 用户使用指定凭据文件 /root/.codex/credentials/agmentmeshos-console.env 完成生产 Console 管理 API Key 登录，凭据未进入仓库、日志或普通回复。
• Console 将“网络可达性”和“网络态势实时分布图”拆分为可切换页签；拓扑页获得接近整页高度，并新增“保存布局 / 恢复保存 / 自动布局”。自动布局不再清除已保存位置，浏览器契约验证恢复保存可回到原布局。
• 状态卡说明、指标、页签和最近自测记录完成对比度修正，浏览器测试将最低对比度门禁固定为 4.5:1。生产截图确认红框中的小型浅色文字已改为高对比白色粗体。
• 生产页面真实提交 192.227.170.39 全国自测，ICMP 正常、丢包 7%、平均 235 ms；TCP 443 正常、丢包 1%、平均 620 ms；ping.pe 与两条 Globalping 证据链接可见。
• P18 计划状态更新为“已完成并结案”。为避免伪造 P17 归档，state.json 的当前阶段仍保持 P17；P18 作为用户提前授权完成的后续阶段保留独立结案记录。
• 结案后补充修正：自动采集器只在 ICMP 失败时才运行 TCP 443，因此状态卡把“未触发”错误显示为“无法判定”。提交 b63ca17 已改为“未触发”，生产 Console 回读到 DD ICMP 105/105、TCP 443 未触发。

🧾 2026-10-12：P18 结案后拓扑画板沉浸模式增强

• 用户批准在现有 Console 上实施方案 B。提交 208db1b9d8c86be6b0066ba3926c2c4536e13eee 将“网络态势实时分布图”扩展为沉浸工作区：全屏时隐藏页签和说明，工具栏成为顶端浮层，筛选默认收起，画板使用 100dvh；详情保持右侧覆盖抽屉，普通模式仍可按需收起筛选。
• 画板新增“适配全部”和“适配选中”。适配计算依据当前可见节点或选中节点、链路端点的 SVG 坐标，并受 0.7 至 2.0 缩放边界约束；保存布局仍同时持久化节点位置、平移和缩放，自动布局不覆盖已保存内容。
• 验证命令 bash scripts/ci/run-local-tests.sh 退出码为 0。完整门禁包含 AI Runtime 211 passed、Auth 18 passed、API Gateway 全部契约、Console 工作台静态契约、Console 浏览器契约、网络拓扑浏览器契约、网络探针 11 tests、文档构建和发布安全检查。
• 浏览器契约新增断言：普通模式筛选可收起、沉浸画板高度不低于 880px、沉浸筛选默认关闭后可展开、适配全部和适配选中均会更新 SVG 变换、退出全屏后清除 is-immersive。
• 回退点为 git revert 208db1b9d8c86be6b0066ba3926c2c4536e13eee。P17 的 state.json 状态未修改，本增强只属于 P18 结案后的 Console 展示层修正，不改变网络探针、Globalping、DNS、代理节点或 Edge 切换逻辑。

🧾 2026-10-12：P17 并入统一主协议与 360T7 当前固件主备计划

• 用户重新界定当前目标：五台数据面节点采用“统一主协议 + 节点异构备用”；360T7 保持当前 ImmortalWrt C 版固件，不重新编译、不刷入 Mihomo/Nikki，不支持该固件直接部署 Mihomo fallback。
• 冻结五项实施边界：五台节点统一 VLESS + REALITY 主协议；每台 UUID、Short ID、SNI、伪装目标和 REALITY 密钥独立；dog、dd、rr 保留原异构协议；订阅拆分 REALITY 主组与兼容备用组；360T7 使用 PassWall/Xray 主组加后备组实现 MM 优先、断线接替和恢复回切。
• 360T7 现场只读证据为：ImmortalWrt 25.12-SNAPSHOT r38169-37013c8153、PassWall 26.9.1、Xray 26.3.27、5 个 sslocal 和 PassWall HAProxy；旧 Balance 组约占 27 MiB RSS，proxy.yohan.fun 的五个新节点已导入但尚未成为全局主路径。
• P17 新增工作包固定为 P17-6 至 P17-11：基线核验、五节点 REALITY、订阅分层、360T7 Xray 主备、资源与 conntrack 清理、最终验收归档。当前工作包更新为 P17-6 统一主协议与 360T7 主备方案的基线核验、身份冻结与执行准备，本记录只更新计划，不修改服务器 Inbound、2S-UI 订阅、360T7 PassWall 或固件。
• 资源清理分为两阶段：P17-9 稳定后才关闭旧 5 个 sslocal 和 PassWall HAProxy；系统 HAProxy 444/81/60000 与外部服务必须单独审计。nf_conntrack_max 先保持 30720，稳定后调整为 65536、nf_conntrack_buckets=32768，不直接设置 131072。
• 回退点为恢复 2S-UI 数据库快照、移除新增 REALITY Inbound、恢复订阅配置和 360T7 /etc/config/passwall；旧 SS 节点、旧 HAProxy、旧订阅和当前 FIT 恢复包在观察期内全部保留。

🧾 2026-10-12：P17-6 只读基线完成并在身份门禁处阻塞

• 五台节点均运行 S-UI Panel 1.8.3 / Sing-Box v1.14.1，服务 active/enabled，五份 /usr/local/s-ui/db/s-ui.db 的只读 PRAGMA quick_check 均为 ok；原始脱敏摘要位于 /root/project/AgentMeshOS/temp/p17-6-evidence/。
• 当前 Inbound 与监听为：RR rr-trojan-24446、MM mm-reality-24443、d02 d02-reality-24443、dog dog-hysteria2-24444、DD dd-ss2022-24445；各节点 2095/2096 均绑定 Tailnet 地址，数据面端口分别绑定 24443-24446。
• 身份核验发现共享凭据：MM 与 d02 的 VLESS 客户端 UUID 摘要相同；dog Hysteria2 与 RR Trojan 的客户端密码摘要相同；MM 与 d02 的 SNI/伪装目标同为 www.microsoft.com。这些摘要均由只读配置计算，原始 UUID、密码和私钥未输出。
• 当前 agentmeshos-main 是一个 client 记录关联五条 Inbound，因此“每节点完全独立”不能靠只改端口完成。P17-6 按既定门禁标记为 ⚠️ 阻塞，当前工作包保持不变，P17-7 未启动。
• 现有 2S-UI 快照时间为 2026-10-03/04，均早于当前数据库，不能视为当前 last-known-good；P17-7 写入前必须为五台节点各生成 fresh snapshot 并记录 SHA-256/权限/恢复命令。
• 360T7 已核对 /etc/config/passwall SHA-256 1b8da1f935010f236bdcedf00b88ddcf12c6979f05d399b3dc7c70f3400ce43e、network 25fd979d3a5c4ce75d10e74567f6185b16b56e1f68be2dface38a0ff9775e55b、firewall 6dbc78ec104a4f0ac1967f7d19621bf72b5646ea39ccbb047db83bd4ef7a215a，以及 C 版 recovery SHA256SUMS 六项 OK；当前全局节点仍为 f9Re2U27，旧 HAProxy 仍启用。

🧾 2026-10-12：P17 简化为一协议、一客户端、一订阅

• 用户最终决定不再保留 Hysteria2、SS2022、Trojan 异构备用，也不再新增独立身份 client 或订阅聚合服务。五台节点最终只保留 VLESS + REALITY，继续使用同一个 agentmeshos-main client、同一个订阅 URL 和 Proxy / Auto 组名。
• 用户明确接受五台节点共享同一个 VLESS UUID。P17-6 的共享身份门禁据此关闭并记为完成；当前工作包切换到 P17-7 五节点统一 REALITY 主入口。
• 迁移固定采用“加新不删旧”：先在 dog、DD、RR 增加 Reality，MM/d02 保持现状，五台独立验证后再更新订阅；在线客户端主动刷新并确认新节点后，才移除旧协议，避免刷新窗口中断服务。
• 在线客户端不能由服务端推送更新。当前订阅端点响应 Profile-Update-Interval: 12，标准客户端需要主动执行一次 Update Profile 并回读；360T7 不消费该订阅生成节点，需单独更新 PassWall 的五个 Xray 节点和主备组。
• 本记录只更新 P17 计划与状态，尚未修改任何 Inbound、订阅或 360T7 配置；P17-7 下一步将先为三个异构节点创建 Reality 并保留旧 Inbound。