跳转至

AgentMeshOS 项目整合总计划

总体目标

在不破坏既有 101/RR 剥离边界的前提下，将 101 项目控制面、RR 生产面、GitHub 发布面、Docs 文档面和 Console 节点面统一为可验证的事实来源，并先完成 GitHub Organization 级共享 Self-hosted Runner 的可行性验证与迁移。

当前执行状态（2026-09-06）

状态口径说明：本文件下方 2026-08-31 及更早条目是历史执行记录，不再作为当前完成度判断依据。当前状态以本节和整改后续计划为准。已完成的 Auth 业务门禁、多项目组织迁移、101 双 Runner 并发验收和 Node 24 Actions 升级均不得再标记为“待完成”。

  • 当前生产模型通道只允许已通过真实 Smoke 的通道：OmniRoute 为系统默认；Codex 使用已验证的 managed-7c31463f3b1c46c3b779c0dfc9743b40；Claude 使用已验证的 managed-46404ae625604c90aea8fa3217def1e1。未通过 Smoke 的限量通道已关闭，不参与调度。
  • 组织 agentmeshos 当前已包含已迁移项目；每个项目的通用 Linux Workflow 使用 AGENTMESHOS_RUNNER_LABEL 并保留 ubuntu-latest 回退，Windows/Android/特殊硬件 Workflow 保持托管 Runner。
  • 101 独立备份盘仍需在每次写入前用 findmnt 核验为 /dev/sda1；RR /backup 仍是系统盘，不作为独立备份盘。

最新执行复核（2026-08-31）

  • Organization 共享 Runner 阶段已完成真实调度验收：agentmeshos/AgentMeshOS 的构建、测试、Release bundle 和 RR 部署均由 101 的 pcdell-101-agentmeshos 执行；GitHub API 显示 Runner online，不可用时仍保留 Workflow 的 ubuntu-latest 回退。
  • 无状态发布阶段已完成最新闭环：提交 2478ef67f1a0f35344d034656557da312e37cdb5 的 Docs、Console、Status、API Workflow 全部成功，RR 四个容器均运行相同组织 GHCR SHA 镜像且 healthy，公网健康入口均返回 HTTP 200。RR 发布 JSONL 已确认包含非空 previous_image、健康结果、回滚结果和失败字段。
  • Stateful 门禁复核已完成：Auth、AI Runtime、CLI Gateway 的静态门禁与契约测试通过；AI Runtime 的生产库/恢复副本读取、边界检查和 CLI Gateway 独立回滚演练已有证据。三者继续保持人工发布，不接入生产自动升级。
  • Stateful 尚未全部放行的唯一业务项是 Auth 生产账户的登录、登出、密码重置和会话恢复；必须在用户授权的真实测试账户窗口执行，不能用伪造凭据或静态测试替代。

  • 最终验收仍需持续记录 RR 单节点恢复演练、容量归档策略和远端工作区状态；RR /backup 是系统盘，101 独立备份盘必须继续以 /dev/sda1 为来源核验。

  • 已完成并实测：多项目 Actions 监控器支持 owner/repository + 完整 40 位 SHA，并逐个核验 Workflow、Job、Step；提交 51ed48a627ad105932a1f2f73437f02df752e0f2 的相关工作流全部成功。

  • 已完成并实测：RR 的 Docs、Console、Status、API 四个无状态容器已统一运行 sha-51ed48a627ad105932a1f2f73437f02df752e0f2，容器健康检查和公网端点均通过。
  • 已完成并实测：API 节点职责目录、Console 节点字段、101/RR/103/jj 边界、RR Release 资产校验、发布锁和告警闭环。
  • 已完成基础门禁证据但未完成 Stateful 全量放行：RR Auth/AI Runtime 数据库 PRAGMA quick_check=ok，环境文件为 root:root 0600，CLI Gateway 为只读根文件系统且丢弃全部 Linux capabilities；真实业务对话、旧数据读取、恢复演练仍待执行，因此 Auth、AI Runtime、CLI Gateway 不接入生产自动升级。
  • Organization 共享 Runner 已完成注册前置：此前个人账号阶段 Organization Runner API 不可用；现已建立 Organization 并注册 101 Runner，仍保留 AGENTMESHOS_RUNNER_LABEL 显式选择和 ubuntu-latest 回退。
  • 2026-08-31 Organization Runner 迁移进展：已建立免费 Organization agentmeshos，michaellab7284 与 hhtbing 均为 Owner；AgentMeshOS 已从个人命名空间转移到 agentmeshos/AgentMeshOS，本地 origin 已同步。101 已注册 Organization Runner pcdell-101-agentmeshos，标签为 self-hosted、Linux、X64、agentmeshos-ci，systemd 服务 active，GitHub API 状态为 online；组织变量 AGENTMESHOS_RUNNER_LABEL=agentmeshos-ci 已设置。待 push 工作流完成一次真实调度后，才能将 Runner 阶段标记为完成。
  • 2026-08-31 Runner 真实调度已通过：为 agentmeshos/AgentMeshOS 设置仓库级 AGENTMESHOS_RUNNER_LABEL=agentmeshos-ci 后，探针工作流运行成功，日志显示 runner_name=pcdell-101-agentmeshos、Linux/X64、Docker 29.6.1、Python 3.14.4。组织变量保留作为其他授权仓库的共享配置；仓库变量用于确保当前私有仓库在免费 Organization 下明确解析该标签。
  • 存储证据：101 /srv/codex-hub-backup 当前由 /dev/sda1 提供；RR /backup 位于 RR 系统盘，只作为已记录的历史备份路径，不视为独立备份盘。
  • 2026-08-31 Stateful 快照演练证据：RR /backup/agentmeshos/stateful-gates-20260831T074729Z/auth.db 的 SHA-256 为 97ab6b014568c44dc3cbc14c0322cc86e220425bcf07be226e3bb46e875f1635，runtime.db 的 SHA-256 为 71c3813316391044707b0fd6acdd01b35e6db2fc09f6231dac1bdfc443ea6bf4；两份快照 PRAGMA quick_check=ok。该路径位于 RR 系统盘，仅作恢复演练证据，不替代 101 独立备份盘。
  • 2026-08-31 CLI Gateway 实际对话测试证据：AgentRouter/Codex CLI 的 deepseek-v4-flash（managed-1a5e243bcb854e3b872d84ac52d48ee1）和 AgentRouter/Claude CLI 的 deepseek-v4-flash（managed-46404ae625604c90aea8fa3217def1e1）均通过一次最短测试对话，接口返回 status=passed。测试接口仅返回放行状态和 usage，不持久化或输出对话正文；限量模型未以本次偶发结果替代长期可用性结论。
  • 2026-08-31 组织迁移后的 Docs 发布失败已完成根因修复：失败 Run 33377543860 的首次执行因 RR 仍使用个人命名空间镜像而失败并自动回滚；已将组织版本的 RR 发布控制器和 Docs 部署脚本同步到 RR，远端哈希分别为 4aa88f5d3405438b082872250f086b17bc99a213ce78919226d4719f6c2f2155 与 78ee8c93d0de5c34eeeae3867ee8f2a9c2cf1daa658d9553e11e4b54a750ab93，权限均为 root:root 0755，bash -n 通过。该 Run 重跑后的 build Job 99450612533 与 deploy Job 99451272492 全部成功，部署在 pcdell-101-agentmeshos 执行；RR Docs 实际运行 ghcr.io/agentmeshos/agentmeshos-docs:sha-63a68e5f18cbf7a0ca8fdd1f15f9b27d021a1ac1 且 healthy。
  • 2026-08-31 API 工作流在 101 Runner 首次失败的根因是工作流调用了主机不存在的 python 命令（后续确认系统 python3 也没有 pip）；已加入 actions/setup-python@v5 固定 Python 3.12，并统一使用 python3。修复提交 6620706964d00a888f394f8b88fcd443bed075fd 的 API Run 33382265736 全部成功。
  • 2026-08-31 无状态服务最终统一验收：以提交 6620706964d00a888f394f8b88fcd443bed075fd 分别完成 Docs Run 33382801731、Console Run 33382803050、Status Run 33382801873 和 API Run 33382265736，每个 Workflow 的 build、Release bundle、RR deploy Job/Step 均成功；RR 四个容器均运行对应 ghcr.io/agentmeshos/*:sha-6620706964d00a888f394f8b88fcd443bed075fd 且 healthy。公网 https://docs.yohan.fun/healthz、https://console.yohan.fun/、https://status.yohan.fun/healthz、https://api.yohan.fun/health 均返回 HTTP 200。
  • 2026-08-31 Auth 门禁推进：RR 执行 stateful-release-drill.sh auth-site 的静态门禁通过，生成认证数据库快照、SHA-256、SQLite quick_check=ok、Schema 与表计数，环境文件保持 root:root 0600；公网 https://auth.yohan.fun/login 返回 HTTP 200。使用 temp/auth-test/venv 安装项目固定依赖与 pytest 后，tools/auth-site/tests/test_auth.py 共 14 项全部通过。真实生产登录、登出、密码重置和会话恢复尚未放行，原因是生产账户密码未注入自动化环境；不得猜测或伪造凭据，待明确的凭据窗口执行后再关闭该门禁。
  • 2026-08-31 AI Runtime 门禁推进：确认容器实际挂载 /var/lib/agentmeshos/ai-runtime，空的 /var/lib/agentmeshos/runtime.db 不是生产库；RR 实际库只读 quick_check=ok，快照与恢复副本验证通过。生产库读取基线为 conversations=34、messages=177、tasks=102、deliverables=71，恢复副本计数完全一致；证据目录为 /backup/agentmeshos/stateful-gates-runtime-20260831T111948Z-recovery/，恢复库 SHA-256 为 b2ff37245a2f8baba59160f0accfcbd4b12bc23e9918b983b836c293b1f29175。门禁盘点脚本已修复对 vec0 等虚拟表的兼容性，Schema 保留、不可加载的虚拟表不执行误导性的 count(*)；回归测试通过。AI Runtime 本地全量测试在隔离环境中 210 passed。Runtime 历史业务读取与恢复数据验证仍需在受控业务入口完成，未将静态/副本验证冒充完整生产放行。
  • 2026-08-31 CLI Agent Gateway 门禁推进：RR 容器健康，ReadonlyRootfs=true、CapDrop=[ALL]、PidsLimit=128、只加入 agentmeshos-ai-runtime 私有网络且不发布宿主机端口；环境文件为 root:root 0600。隔离环境中的 Gateway 测试共 29 passed。通过内部管理接口对生产两个长期 deepseek-v4-flash 自定义通道执行一次实际最短对话，Codex 通道 managed-1a5e243bcb854e3b872d84ac52d48ee1 与 Claude 通道 managed-46404ae625604c90aea8fa3217def1e1 均返回非空结果、status=passed，并保持 enabled=true、available=true；限量模型未用偶发结果替代长期供应结论。CLI Gateway 独立回滚演练仍需在不影响 Runtime 主链路的受控窗口完成。
  • 2026-08-31 多项目共享 Runner 审计：Organization agentmeshos 的 Default Runner Group 当前可见范围为 all，但组织仓库列表目前只有 agentmeshos/AgentMeshOS。/root/project 中 OwlMonitor_app、ota、pose-radar-ti、owlFront_mock、AWRL6844EVM_J5_link_WT99P4C5-S1_J4 等仓库仍分别属于个人命名空间，不能直接调度 Organization Runner；其现有 Workflow 仍使用 ubuntu-latest/windows-latest。本次不擅自迁移或改写这些仓库，待明确授权后按项目逐一转入组织、设置 AGENTMESHOS_RUNNER_LABEL 和 GitHub-hosted fallback，并分别监控完整 SHA。该边界不影响 AgentMeshOS 当前 101 Runner 已验证的执行链路。
  • 2026-08-31 节点小文件交换规则已统一：全局执行入口及当前有效架构文档允许通过 Tailnet/SSH 等节点控制链路临时传输小于 1 MiB 的脚本、配置、凭据和紧急交换文件，必须核验来源/目标与 SHA-256，凭据为 0600、脚本为 0755，完成后清理；镜像、安装包、构建产物、业务数据和大量文件仍走公网 HTTPS 云盘或直连数据面，不经节点中转。历史归档事实未改写。
  • 2026-08-31 CLI Gateway 回滚演练完成：首次演练发现脚本错误地强制从 Registry 拉取仅存在于 RR 本地缓存的 rollback tag，随后修复为“本地镜像优先、缺失时再拉取、两者都不可用则明确失败”。修复提交 233c7da13ec890a56aceb026111c5605e9ee27e9 的 CLI 工作流首次又因 101 上不可执行的 /usr/bin/claude 链接未被探测器捕获而失败，改为捕获 OSError 后提交 747b1cc6a3de669fd47e643a7b567e943448c632，CLI 工作流全部成功，本地测试 30 passed。最终使用校验后的脚本在 RR 完成 rollback 容器健康检查和原镜像恢复，两个阶段 Runtime 均保持 ghcr.io/michaellab7284/agentmeshos-ai-runtime:sha-c650a07|healthy，Gateway rollback 与恢复均 healthy，确认不影响 Runtime 主链路。
  • 2026-08-31 CLI Gateway 最终门禁复核：在项目 temp/cli-gateway-venv 隔离环境补齐 pytest、httpx 和项目依赖后，tests/test_gateway.py 为 30 passed；RR 现场再次确认 ReadonlyRootfs=true、CapDrop=[ALL]、PidsLimit=128、无宿主机发布端口且只连接 agentmeshos-ai-runtime 私有网络。最近 200 行 Gateway 日志未命中 API key、Bearer、密码或 token 的凭据模式。该复核与已完成的独立回滚演练共同构成 CLI 本轮可执行门禁证据，仍不将该服务加入自动生产升级。
  • 2026-08-31 RR 存储与容量核验：101 /srv/codex-hub-backup 确认为 /dev/sda1（440G，总使用 31%，可用约 288G）；RR /backup 确认为系统盘 /dev/vda2（57G，总使用 58%，可用约 24G），不作为独立备份盘。RR 当前 Docker 镜像 36 个、活跃容器 10 个、镜像占用约 6.5G；生产四个无状态容器均保留组织 SHA 镜像与 rollback 镜像。未执行任何删除或清理，容量告警阈值和长期归档策略仍需在最终恢复包中明确。
  • 2026-08-31 AI Runtime 正式业务入口读取：通过 RR 本机 http://127.0.0.1:39170 的 Boss 认证接口只读取摘要，/health 返回 ok，/boss/v1/conversations 返回 30 个对话，/boss/v1/tasks 返回 102 个任务，/boss/v1/deliverables?limit=1 返回总数 76，并成功读取已完成任务摘要；未输出对话正文、成果内容或凭据。恢复副本尚未切换线上入口，保留为后续受控恢复验收项。
  • 2026-08-31 AI Runtime 恢复副本业务读取：使用固定镜像 ghcr.io/michaellab7284/agentmeshos-ai-runtime:sha-c650a07 启动一次性隔离 bridge 容器，挂载恢复快照并关闭 Nomad、自动执行、P5/P6 及外部 Provider；/health 返回 ok，Boss 认证接口读取对话 30 条、任务 102 条和成果分页 1 条均返回 HTTP 200。首次 401/503 分别由错误认证头和临时关闭 P4 读取开关造成，已二次验证并修正；容器及临时目录已清理，生产 Runtime 未修改。
  • 2026-08-31 AI Runtime 生产边界复核：容器状态 healthy，/health 返回 ok；从 Runtime 私有网络访问 OmniRoute、CLI Agent Gateway 和 Operations Bridge 的健康接口均返回 HTTP 200，Nomad Agent API 返回 ok；Cloudreve WebDAV 公网入口返回预期的 HTTP 401 认证挑战。此次仅验证边界和健康状态，未调用模型、提交 Nomad 任务或修改生产数据。
  • 2026-08-31 最终无状态一致性验收：以提交 189c23978868b0a50168a5db0e5853c68f1bdc21 手动触发 Docs、Console、Status、API 四个正式 Workflow（Run 33411025851、33411030486、33411035798、33411041362），完整 SHA 监控器确认所有最新 Workflow、Job 与 Step 均成功且无 failure、cancelled 或 timed_out。RR 四个无状态容器均运行相同 SHA 的组织镜像并为 healthy，公网 Docs、Console、Status、API 入口均返回 HTTP 200；101 Organization Runner 为 online、空闲。API 公共状态同时确认 RR 为生产部署节点、101 为项目控制与发布协调节点、103 为通用计算 Worker、jj 为受限计算 Worker。
  • 2026-08-31 Stateful 最终状态：AI Runtime 与 CLI Agent Gateway 的本轮门禁和演练证据完整，仍不将二者接入自动生产升级。Auth 静态门禁、数据库完整性、权限与本地测试均通过，但真实生产登录、登出、密码重置和会话恢复缺少明确的生产账户凭据窗口；该唯一未完成门禁必须在获得用户授权的测试账户/凭据窗口后执行，不能用伪造账户或静态检查替代。
  • 2026-08-31 Actions 失败闭环补充：统一 SHA 87cf2d1e4ad341600e53984d655f30553aacf3ad 时，Console Run 33413482505 首次在 Docker Hub 拉取 nginx:1.27-alpine 元数据阶段发生 TCP 超时，RR deploy 被正确跳过。失败日志已保存；从 101 二次验证 Registry 返回预期认证响应且镜像元数据可读取后，重跑同一 Run 成功。随后对该 SHA 的 Docs、Console、Status、API 四个最新 Workflow 重新执行完整监控，均成功；RR 四个无状态容器和公网端点均已统一复核。
  • 2026-08-31 Actions 失败闭环记录：计划提交 63a1fa22221c0a1c28d148efea35a2eb8ccfe0b5 的 Docs 构建首次因 101 Runner 在 Docker buildx 阶段访问 Docker Hub 基础镜像元数据超时而失败，deploy 未执行；二次验证确认 Docker Hub 可达且基础镜像有本地缓存，随后重跑同一 Run 后完整 Workflow 成功。失败日志已由 scripts/ci/monitor-github-actions.sh 保存，根因、重跑结果和成功覆盖关系已记录，未将首次失败误报为完成。
  • 2026-08-31 最终无状态一致性复核：为消除计划记录提交后造成的 SHA 分散，重新触发 Docs、Console、Status、API 四个 Workflow，全部以提交 4cecc87b2303e02b87f7ef74f131824eee83ac1f 成功完成（Run 分别为 33394255131、33394933529、33394935821、33394934419）。RR 四个生产容器均运行对应组织 GHCR sha-4cecc87... 镜像且 healthy；公网端点均返回 HTTP 200。101 Organization Runner 仍 online，工作区与远端 main 一致。
  • 2026-08-31 最新一致性复核：提交 53d407102b2aa2e81cca3c1053dea5329cd7d713 的 Docs、Console、Status、API 四个 Workflow 均已成功；补发后 RR 四个生产容器全部统一运行对应组织 GHCR sha-53d4071... 镜像且 healthy。Console 首次补发因 Docker Hub nginx:1.27-alpine 元数据请求瞬时超时失败（Run 33396497019），二次网络验证正常后重跑成功；失败日志、根因和成功覆盖关系已保留。公网 Docs、Console、Status、API 健康入口及 API 节点接口复核通过。
  • 2026-08-31 RR 备份与容量策略审计：新增只读脚本 scripts/maintenance/agentmeshos-rr-backup-capacity-audit.sh 及契约测试。通过 ssh rr 现场复核确认 /backup 为 /dev/vda2 系统盘，根分区使用率 58%、可用约 23.9G；默认保留周期 14 天、80% 告警线、90% 停止线和禁止清理对象已固化。该证据只确认本地审计与边界，不将 RR 本地盘冒充独立备份，也未执行任何删除。

最新验收记录（2026-08-31）：提交 60e87dfa2bf25ed135b7ff7833fb7120a7557d21 的 Docs、Console、Status、API 四个 Workflow 均成功完成；RR 四个无状态容器均运行该完整 SHA 的组织 GHCR 镜像且 healthy；公网健康检查全部返回 HTTP 200；101 Organization Runner pcdell-101-agentmeshos 保持 online。

最新执行复核（2026-08-31，提交 df125d125df5e0470a25c0585845e8d3151f5891）：Docs、Console、Status、API 四个 Workflow 均已完成且结论为 success，完整 SHA 监控结果为 runs=4 active=0 failed_or_cancelled=0。RR 的 agentmeshos-docs、agentmeshos-console-site、agentmeshos-status-site 和 agentmeshos-api-gateway 均运行对应组织 GHCR 的 sha-df125d... 镜像，四个容器均为 healthy；https://docs.yohan.fun/healthz、https://console.yohan.fun/、https://status.yohan.fun/healthz 和 https://api.yohan.fun/health 均返回 HTTP 200。RR 发布日志已记录该提交的部署开始、健康通过和 rollback_result=not_needed；同一日志也保留此前失败/重试记录，未覆盖历史证据。RR /backup 现场仍为系统盘 /dev/vda2（约 60% 使用率），101 /srv/codex-hub-backup 仍为独立 /dev/sda1（约 33% 使用率）；未执行清理或删除。

第六阶段恢复与容量复核（2026-08-31）：本计划引用 DETACH-09 维护窗口证据，而不重复制造生产中断。该窗口已实际验证 RR 整机重启后的物理与 Tailnet SSH 双入口、Bridge/Nomad 恢复、生产容器健康和 Docs 公网健康；也已验证 Bridge 服务级恢复、Docs rollback 镜像回滚及恢复正式版本。恢复顺序固定为：先恢复 RR 主机物理网络、系统 DNS 与 SSH 双入口，再恢复 Tailnet/Bridge/Nomad 和 Runtime，随后恢复无状态生产容器与公网 HTTPS；Cloudreve 仍由 dd 独立恢复，Project 仅由 101 权威工作区和 GitHub 恢复，不在 RR 恢复链路内。凭据不随镜像、Release bundle 或 Project 复制，继续仅保留在各自主机的 root-only 边界。RR 整机不可用期间不存在接管生产节点，Docs、Console、Status、API 不能保证持续服务；系统正式声明为“单节点生产、可恢复、非高可用”。容量策略由只读脚本 scripts/maintenance/agentmeshos-rr-backup-capacity-audit.sh 固化为 14 天保留、80% 告警、90% 停止非必要操作，并明确禁止清理运行容器、rollback 镜像、卷、生产数据、凭据和 Codex 系统数据；归档只能转至独立或远端副本，不将 RR /backup 误作独立备份。

Auth 业务门禁复核（2026-08-31）：生产 agentmeshos-auth-site 容器为 running/healthy，公网 https://auth.yohan.fun/health 返回 HTTP 200；auth-site.env 存在，但系统服务未配置 AUTH_SMOKE_* 专用测试变量，环境文件也未保留初始账户密码字段。非破坏性脚本 scripts/ci/auth-site-smoke.sh 已具备真实登录、会话读取、账户页、登出和登出后会话拒绝检查；本地回归 tools/auth-site/tests/test_auth.py 为 14 passed，覆盖密码重置后的旧会话撤销和会话恢复契约。生产登录、登出、密码重置和会话恢复仍必须在用户明确授权的专用测试账户窗口执行；不得从生产凭据文件猜测密码、创建未授权账户或把本地测试替代生产业务验收。

多项目 Runner 迁移核验（2026-08-31）：OwlMonitor_app、ota、pose-radar-ti、owlFront_mock 和 AWRL6844EVM_J5_link_WT99P4C5-S1_J4 的本地目录均已先完整备份至 101 独立盘 /srv/codex-hub-backup/project-runner-migration-20260831T175216Z，该盘现场确认来源为 /dev/sda1。当前 michaellab7284 的 GitHub API 与 HTTPS Git 两次验证均无法读取 hhtbing/* 个人私有仓库；本机亦不存在 hhtbing 的 Git 凭据，因此不能把该结果误判为仓库已删除。为预留恢复目的地，已创建五个同名的私有 agentmeshos/* 空仓；保留历史推送经两次试验均被各本地仓库的缺失 Git 对象阻止，且远端没有写入有效提交。恢复前必须取得原个人仓库的读取/转移访问，或明确批准以已备份工作树建立新的无历史恢复基线；在此之前不改写原目录远端、不提交用户未提交状态，也不将这些空仓声明为已接入 101 Runner。

多项目 Runner 再次审计（2026-08-31）：101 Runner pcdell-101-agentmeshos 当前 online 且空闲；Organization 中五个同名私有仓库仍无默认分支，证明它们仍为空恢复目的地。只读本地 Git 完整性统计显示 OwlMonitor_app、ota、pose-radar-ti、owlFront_mock 仍指向 hhtbing，其中 OwlMonitor_app、pose-radar-ti、owlFront_mock 分别有 1277、85、291 条未提交路径；四个目录的 Git 对象库均有不可忽略的 git fsck 输出。AWRL6844EVM_J5_link_WT99P4C5-S1_J4 缺少可验证的本地提交历史。故下一步只能是取得原个人仓库的读取/转移权限后保真迁移，或由用户明确批准以 101 独立盘备份建立无历史恢复基线；在任一条件满足前，禁止向空 Organization 仓推送、修改项目工作树或将其声明为共享 Runner 已接入。

Actions 失败闭环（2026-08-31，提交 1b2c08f4b3bbf4ee4ae5be4f4be7edca886a732d）：Docs Run 33446534228 的首次 build 在解析 Docker Hub python:3.12-slim 元数据时连接 registry-1.docker.io:443 发生瞬时 TCP 超时，Release bundle 与 RR deploy 均被正确跳过。随后在 101 对 python:3.12-slim、nginx:1.27-alpine 执行 docker buildx imagetools inspect 均成功，Registry API 返回预期认证挑战，确认不是 Dockerfile、基础镜像、GHCR 或 Runner 配置故障。重跑同一 Run 后 build、Release bundle 与 deploy Job/Step 全部成功；RR Docs 实际运行该完整 SHA 的组织镜像且 healthy，公网 /healthz 返回 HTTP 200。首次失败日志、根因、二次验证和成功重跑 URL 均关联到同一 Run，未以最后绿色步骤覆盖失败证据。

Auth 业务门禁补充（2026-09-01）：用户已提供控制台里的生产测试 API Key amk_...。使用该凭据完成非破坏性生产链路验证：https://auth.yohan.fun/health 返回 HTTP 200，/api-key-login 返回 HTTP 200，/session 返回 API Key 管理员身份、role=admin、auth_method=api_key，/account 返回 HTTP 200，/logout 返回 HTTP 204，登出后 /session 返回 HTTP 401。该项证明控制台 API Key 登录、会话读取、账户页访问和登出失效链路正常；因 API Key 会话按设计不能修改本地账户密码，密码修改、密码重置和用户名密码会话恢复仍需要另行使用控制台本地测试账号执行，不得用 API Key 结果冒充本地密码门禁。

hhtbing 多项目凭据复核（2026-09-01）：101 当前 GitHub 身份为 michaellab7284，可访问 agentmeshos/AgentMeshOS。按用户要求只读检查 Home 主机后，确认 Home 身份为 Home\\administrator，Git 全局用户名/邮箱为 hhtbing-wisefido/hhtbing@wisefido.com，GitHub CLI 配置文件存在但 gh auth status 显示 hhtbing-wisefido 的 token 已失效，gh api user 返回 HTTP 401；cmdkey 未发现可直接复用的 GitHub 凭据。对 hhtbing/OwlMonitor_app、hhtbing/ota、hhtbing/pose-radar-ti、hhtbing/owlFront_mock 和 hhtbing/AWRL6844EVM_J5_link_WT99P4C5-S1_J4 的仓库可见性查询因认证失效无法验证。该结果只说明 Home 暂无可用 hhtbing GitHub 登录态，不说明仓库不存在；多项目保真迁移仍需用户在 Home 重新 gh auth login 或提供可访问这些仓库的新凭据后继续。

固定边界：

  • 101 只负责项目源码、资料、GitHub、CI/CD、共享 Runner 和 RR 发布协调；Runner 是执行资源，不改变 101 的项目控制角色。
  • RR 只负责生产 Runtime、Bridge、生产容器、Nomad 和生产数据。
  • 103 是标准计算 Worker。
  • jj 是受限计算 Worker，不是 Runner 后备节点。
  • 101 是长期 Self-hosted Runner。101 暂时不可用时，仅回退到 GitHub-hosted Runner，不切换到其他项目节点。
  • Auth、AI Runtime、CLI Gateway 本轮只完成门禁和真实演练，不接入生产自动升级。
  • 每次 GitHub 推送后，必须等待目标完整提交 SHA 的所有最新 Actions 工作流完成；failure、cancelled、timed_out 必须定位、修复、重跑，全部成功后才能进入下一项。

第 0 阶段：Organization 级共享 Self-hosted Runner

0.1 可行性验证门槛

在迁移前验证 101 的 CPU、内存、磁盘、Docker、网络、并发、构建缓存和长期运行能力，并用一个最小示例工作流完成依赖安装、源码分析、单元测试、Docker 构建和结果上传。验证结果必须记录真实日志、耗时、资源峰值和失败原因；不可用结论必须经过最小化二次验证。

0.2 Runner 安装和隔离

  • 在 GitHub Organization 注册一个共享 Runner，固定标签为 self-hosted、linux、x64、agentmeshos-ci。
  • 使用专用 Runner 账户、独立工作目录和最小文件权限，不读取 /root/.codex，不接管 Codex 系统服务。
  • Runner 工作目录、缓存、临时产物和清理策略独立于项目源码；多项目执行统一使用 Runner 专用临时目录，项目自身的临时文件仍按各项目规则放在对应项目的 temp/，任务结束后清理。
  • 101 的项目控制职责与 Runner 执行职责保持边界：Runner 可以执行授权 Job，但不运行生产 Runtime、System Operations Bridge 或云盘后端。
  • RR 发布凭据按既定方案长期放在 101 的 root-only 文件中，由受控发布脚本读取；普通构建 Job、Pull Request（尤其是 fork）和未受保护分支无权读取。只有受保护分支通过审批门禁后，专用发布 Job 才能调用该脚本。

0.3 多项目接入模型

所有获授权且满足 101 执行环境要求的 GitHub Actions Job 默认由该共享 Runner 执行，包括依赖安装、源码分析、单元测试、Docs 构建、Docker 构建、镜像推送、Release、RR 部署协调、公网验收、回滚和 Actions 失败监控。需要 GitHub 托管环境、特殊硬件或无法在 101 执行的 Job 必须显式标注并使用 GitHub-hosted Runner，不得被强行调度到 101。至少纳入当前 /root/project 下的 AgentMeshOS、OwlMonitor_app、ota、pose-radar-ti、owlFront_mock、AWRL6844EVM_J5_link_WT99P4C5-S1_J4 及其他独立仓库。

Organization Runner 按项目授权接入。项目仍独立保留自己的仓库、Workflow、Run ID、日志、镜像、Release 资产和失败记录；共享 Runner 只提供执行资源，不合并项目控制权。每个项目的 Workflow 通过标签选择 Runner，并保留必要的 GitHub-hosted fallback 配置。

0.4 Actions 状态监控和放行

  • GitHub 继续负责 Workflow 编排、状态、Job/Step 日志、Secrets、Environment 和审计。
  • 状态必须从 GitHub Workflow、Job、Step 和日志 API 获取；101 本地 Runner 日志只补充 Runner 离线、磁盘不足、Docker 异常等执行环境信息。
  • 每次推送后用完整 40 位 SHA 查询该提交的全部最新工作流，记录 run URL、run ID、Job、Step、结论和失败日志。
  • failure、cancelled、timed_out 或 Runner 离线均不得放行下一阶段。先定位根因，修复后重新推送并再次监控。
  • Runner 暂时不可用时，由 Workflow 的显式标签和条件切换到 GitHub-hosted Runner；不得静默改用其他项目节点。恢复后再验证 101 Runner，不将 jj 或其他节点作为后备 Runner。

0.5 Runner 阶段验收

验证共享 Runner 可被多个授权项目选择；符合条件的 Job 默认在 101 执行，例外 Job 和 Runner 不可用时能按显式配置回退 GitHub-hosted；构建产物、镜像、Release 和部署协调的 commit SHA 一致；GitHub 页面仍可直接查看进度和状态；失败工作流可被监控、修复和重跑；101/RR 角色边界、凭据隔离和 Codex 系统服务边界均未被破坏。通过后，边迁移、边执行、边验收后续阶段。

第一阶段：统一 101/RR 角色和文档事实

1. 修正控制台中的旧角色描述

修改 tools/console-site/src/index.html：

  • 删除“101 / 103 承载 Batch Worker”的合并描述。
  • 101 显示为“项目控制与发布协调节点”。
  • 103 显示为“通用计算 Worker”。
  • 明确 101 不运行生产 Runtime 或 System Operations Bridge。
  • 明确 101 可以执行受控、可替换的 Nomad 无状态任务，但这不是它的主角色。

补充 Console 浏览器契约：101 不得被渲染为普通 Worker；103 可以被渲染为计算 Worker；101 的职责、节点类型和部署限制必须来自 API 返回值，不得在前端重新推断。

2. 修正当前有效架构文档

只修改当前有效文档，不改写历史证据的原始事实：

  • docs/architecture/00_项目交接说明.md
  • docs/architecture/03_总体架构设计.md
  • docs/architecture/04_核心模块设计.md
  • docs/architecture/08_AI协作规范.md
  • docs/architecture/10_系统总结.md
  • docs/architecture/05_存储架构规划.md
  • docs/node-role-capability.md

统一术语：

节点 类型 主职责 不承担
101 项目控制节点 代码、资料、GitHub、CI/CD、共享 Runner、RR 发布协调 生产 Runtime、Bridge、云盘后端
RR 生产部署节点 Runtime、Bridge、生产容器和 Nomad 项目源码控制、Project 同步和共享 Runner
103 通用计算 Worker Nomad Client、无状态计算任务、遥测 生产控制面和云盘
jj 受限计算 Worker 受限 Nomad 任务 自动 Batch、共享 Runner，除非重新验收

旧的 DETACH 历史证据保留原文，但在文件顶部增加“历史证据，不代表当前运行状态”的标识，避免把历史快照当成现状。

3. 更新 Docs 站点导航和文档状态

建立三种文档状态：当前有效规范、已完成归档、历史兼容入口。处理重复或过时的计划入口，特别是“最终重启/清理门未完成”“RR 项目控制链路仍在运行”“101 是普通 Worker”和重复的阶段七、阶段八入口。

验收：Docs 首页、架构入口、节点角色页、部署规范页内容一致；Console 的 Docs iframe 与公网 Docs 页面显示相同版本信息；历史证据不删除，也不继续放在“当前规范”导航下。文档必须补充 101 Runner 角色、Organization 共享 Runner、多项目接入、GitHub-hosted 回退和 101/RR 边界。

第二阶段：建立统一节点角色清单

4. 新增版本化节点角色目录

在 API Gateway 使用单一节点目录作为职责来源，至少包含：

id、mesh_name、host_name、address、platform、system_family、node_type、role、is_worker、batch_allowed、production_node、auto_deploy_allowed、nomad_profile。

固定事实：pcdell-101 为项目控制节点，is_worker=false、batch_allowed=false，不允许普通 Worker 自动部署；pcdell-103 为标准计算 Worker，is_worker=true，允许标准无状态任务；jj 为受限 Worker，batch_allowed=false；main/RR 为生产控制节点，不作为普通计算 Worker；dd 为存储节点；nas-sz 为 NAS；Windows、macOS、Android、iOS 为管理终端或移动客户端。

Nomad、Tailnet inventory 和 metrics 只能补充在线状态、系统信息和遥测，不得覆盖目录中的职责定义。

5. API 输出统一能力字段

扩展 /api/status、/api/public/status 和管理员节点接口。公共接口只输出脱敏后的角色和类型；管理接口额外输出 batch_allowed、auto_deploy_allowed、production_node 和 nomad_profile。所有接口使用同一节点目录计算职责分类，禁止前端仅根据 system_family == Linux 判断可部署性。

6. Console/Status 增加职责筛选

Status 页面保留操作系统筛选，同时新增：全部节点、项目控制节点、计算 Worker、受限 Worker、存储节点、NAS、公网边缘节点、管理终端、移动客户端。Console 节点管理页显示节点类型、节点角色、是否 Worker、是否允许 Batch、是否允许自动部署和当前管理状态。

验收：Linux 分类不会把所有 Linux 节点误当作 Worker；101 不出现在普通计算 Worker 列表；职责统计总数与节点总数一致；全部节点、操作系统筛选和职责筛选数量可交叉验证。

第三阶段：独立 Release bundle 与无状态 CD

7. 把部署脚本从 Docs 网站解耦

GitHub Actions 在镜像构建成功后生成版本化 Release bundle，字段为 service、commit_sha、deploy_script、rollback_script、sha256、created_at。bundle 上传到 GitHub Release 资产或等价版本化发布目录。RR 只接受完整 40 位 SHA，下载对应资产，校验 manifest 和 SHA-256 后执行。Docs 继续提供人工下载入口，但不再是生产 CD 的唯一依赖；资产不可用直接失败，不静默降级。

为 bundle 下载、部署、健康检查和回滚分别设置超时；增加 bundle 不存在、SHA 不匹配、资产版本不一致测试。验收 Docs 暂不可用时 RR 仍能发布，错误 bundle 不执行，Action、Release 资产和 RR 镜像 SHA 一致。

8. 增加发布锁、超时和审计

发布入口增加同一生产环境并发锁、镜像拉取超时、容器启动超时、公网健康检查超时和 rollback 超时。每次发布记录：

service、commit_sha、image、previous_image、deploy_started_at、deploy_finished_at、health_result、rollback_result、failure_stage、failure_reason。

9. 增加完整公网验收

四个无状态服务 CD 完成后验证 Docs /healthz 和首页；Console 首页、认证回源和 Docs iframe；Status /healthz、节点列表和 101 角色；API /health、/api/status、/api/public/status；外部 HTTPS、容器健康状态和实际运行镜像一致。早期失败或取消的工作流保留原因，后续成功运行明确覆盖。

第四阶段：发布失败告警和 Console 闭环

10. 统一发布事件和告警

统一发布事件字段：service、commit_sha、image、previous_image、deploy_started_at、deploy_finished_at、health_result、rollback_result、failure_stage、failure_reason。RR 在部署失败、健康检查失败、回滚成功和回滚失败时发送签名告警。

API Gateway 增加发布事件契约、重复事件去重和恢复事件关联测试。Console 告警中心展示真实失败阶段、失败原因和回滚状态，不再只显示“部署失败”。记录失败工作流 URL、Action run ID 和修复后的成功工作流 URL，形成同一提交的审计链。同一故障重复上报不得产生重复活动事件，真实恢复后告警可正确关闭。

第五阶段：分组接入 Stateful 服务门禁与演练

11. Auth Site

备份认证数据库并保存 SHA-256；检查数据库完整性、凭据文件权限和镜像兼容性；执行登录、登出、密码重置、会话恢复实际对话/请求验证；验证失败时镜像可回滚且认证数据库不回滚。只生成独立 Auth 发布报告，不接入生产自动 CD。所有门禁成功才允许生成“可考虑自动发布”状态。

12. AI Runtime

对 SQLite、WAL、SHM 执行一致性快照，执行 PRAGMA quick_check，对迁移前后表结构和关键计数做差异检查，验证旧任务、旧对话和旧成果可读取，验证 Runtime、OmniRoute、Nomad、Cloudreve 边界，演练镜像和数据库快照恢复，恢复后重新验证公网入口和任务读取。门禁未完成前继续人工发布，不自动升级生产。

13. CLI Agent Gateway

验证凭据不进入镜像、日志和构建产物；三个 CLI 通道分别执行真实对话测试；验证只读根文件系统、能力限制、进程数和网络边界；验证 Gateway 与 Runtime 版本兼容；演练 Gateway 独立回滚，确认不影响 Runtime 主链路。通过后再接入独立 CD，不与 Runtime 共用回滚事务。

共同验收：所有门禁成功才允许生成“可考虑自动发布”状态；本阶段不新增生产自动部署工作流；任一门禁失败必须保留日志、修复后重跑。

第六阶段：最终生产、容量和远端验收

14. RR 单节点限制与恢复演练

自动部署不等于高可用。RR 明确为“单节点生产、可恢复、非高可用”。评估并记录 RR 整机不可用时的接管节点、公网 DNS/入口切换、Runtime 数据恢复、凭据恢复边界、Cloudreve 与生产载荷恢复顺序，以及单节点故障期间 Console、Docs、API 的最低可用性。当前不把 jj 或其他项目节点作为 Runner 后备。

15. RR 磁盘和备份策略

结合最新备份策略核对 /backup 是否仍与 RR 系统盘共用；101 独立备份盘是否持续挂载在 /dev/sda1；RR 历史备份保留周期；生产镜像、rollback 镜像和系统 Codex 数据不可误删；容量告警阈值和归档策略。101 备份写入前用 findmnt 确认 /srv/codex-hub-backup 来源为 /dev/sda1。

16. 全链路远端验收

使用固定 commit SHA 验证 Docs、Console、Status、API 的公网 HTTPS、/healthz 或 /health、首页、认证回源、Docs iframe、API 节点职责字段、实际运行镜像和容器健康状态。验证 RR 四个无状态服务镜像与成功 Action 提交一致，发布日志包含部署、健康、回滚和告警记录，Action 历史失败均有根因说明且后续成功运行明确覆盖，101 /srv/codex-hub-backup 来源为 /dev/sda1，远端 main 可见且工作区干净。

多项目 Actions 统一监控规范

共享 Runner 不改变监控入口。任何授权项目更新后，监控器按 owner/repository + full_commit_sha 查询该提交关联的所有 Workflow Run，再展开 Job、Step 和日志；不得只看最后一个绿色步骤。每个项目独立记录失败 URL、run ID、失败阶段、根因、修复提交和成功覆盖 URL。Runner 本地监控用于补充执行节点健康，不替代 GitHub 的工作流事实来源。

测试和验收命令

本地静态检查：

git diff --check
bash -n scripts/deploy/**/*.sh
node --check tools/console-site/src/app.js
node --check tools/status-site/src/app.js
python3 scripts/ci/agentmeshos-plan-state-check.py

API 测试覆盖 101 角色和类型、103 Worker、batch_allowed、auto_deploy_allowed、节点职责统计、操作系统与职责筛选交叉统计和公共接口脱敏。Console/Status 测试覆盖 101 不显示为普通 Worker 或可自动部署节点、Linux 与 Worker 筛选独立、数量交叉一致、Docs/Status iframe 与 API 版本一致。

每个无状态服务至少执行正常构建、正常 RR 部署、公网健康检查、人工健康失败、自动 rollback、rollback 后健康检查以及发布日志和告警核对。Stateful 门禁必须保留失败日志并修复后重跑。

固定提交和放行规则

每个阶段均按以下顺序执行：

  1. 本地静态检查和针对性测试。
  2. 提交并推送 GitHub。
  3. 使用完整 commit SHA 运行 Actions 监控脚本。
  4. 收集并保存失败日志。
  5. 失败则定位根因、修复、重新推送和重新监控。
  6. 只有全部最新工作流成功，才进入下一阶段。
  7. 最终同时确认 GitHub、RR、API、Console、Status、Docs 和共享 Runner 的事实一致。

默认决策和明确不做事项

  • 默认使用 GitHub Organization 级共享 Runner，长期运行在 101；101 不可用时按 Workflow 显式配置回退 GitHub-hosted Runner。
  • 默认使用 GitHub Release 资产；Stateful 服务只做门禁和真实演练，不自动升级生产。
  • 不恢复 RR Project 同步；镜像、安装包、构建产物和业务数据不经 Tailnet 传输。小于 1 MiB 的受控配置、凭据和紧急脚本允许临时经 Tailnet 传输，但必须校验来源、目标、SHA-256、权限并清理临时文件。
  • 不把 101 重新定义为普通 Worker，不把 jj 作为 Runner 后备。
  • 不引入 Kubernetes、Argo CD、自建 Runner 集群或第二套调度器；本计划中的 Runner 是 GitHub Organization 共享执行节点。
  • 不修改历史证据原始事实，只在当前导航和文档中标注其历史状态。

成功标准：当前有效文档、API、Console、Status、RR 生产容器、GitHub 发布记录和 101 共享 Runner 对 101/RR/103/jj 的定义完全一致；授权项目的 Actions 可在 101 执行并被统一监控；无状态服务自动发布可重复、可回滚、可审计；Stateful 服务只有在各自数据和凭据门禁完成后才允许考虑自动发布。