GodexU 2.0 native multi-Agent workbench

[bigpowert25-del]

目标

把 codexU 从单一用量入口推进为 GodexU 2.0 本地多 Agent 工作台，同时保持本地优先、只读聚合和可回滚。

原生工作台重建

• 保留已有窗口、状态栏与灵动岛展示。
• 重建原生主窗口，加入持续存在的左侧导航、目标区、真实节点关系图、指标栏、项目续办、2×2 本机状态、节点状态条和本机任务包输入。
• “轻览 / 协同 / 指挥”不再只是换文字，而是三套不同的信息密度与模块结构。
• 五套皮肤覆盖完整工作台和全部导航页面，不再只更换按钮色。
• 项目卡打开准确项目；Agent 节点打开已保存的身份详情；指挥档读取真实保存身份。
• CPU、内存、macOS 热状态接入本机采样；没有可靠信号时明确显示 --。
• Codex / OpenClaw / Hermes 的来源、设备和可用状态继续分开标注。

Phase 2D：人工确认待投递箱

• 只有已经“本机就绪”的交接才能生成投递包，草稿会被拒绝。
• 用户必须再点击一次“生成本机投递包”；生成后只显示“待人工发送 / 尚未发送”。
• 每个交接 UUID 只有一个待投递包，同一版本重复操作保持幂等，新版本会替换旧包。
• 投递包使用确定性 SHA-256 校验，篡改、未知字段、非法信封和文件名不匹配全部失败关闭。
• 待投递目录与文件强制使用用户私有权限 0700 / 0600。
• 修改交接会使旧投递包失效；用户也可以只取消投递包而保留交接。
• 本阶段没有网络连接、NAS 写入、OpenClaw/Hermes 投递、重试或回执。

修正原因

上一版原生窗口仍是固定高度的旧仪表盘。档位只改变标签或隐藏少量内容，皮肤也只改变强调色与窗口外壳，因此与已确认的 GodexU 2.0 目标工作台在结构、信息密度和视觉层级上差距很大。

此外，直接把“本机就绪”解释成“已发送”会造成权限和状态误判。因此跨 Agent 投递先拆成可审核的本机待投递箱，再独立实现真实连接器与回执。

用户影响与边界

• 默认仍为“钛金工作室 + 协同”。
• 所有设置、草稿和待投递包只保存在本机。
• 本次不包含一键修复、NAS 写入、自动远程投递、Letta 部署、Windows 客户端、tag、Release 或 DMG 发布。
• 不接管任何 Agent；GodexU 只聚合、解释和准备投递。

验证

• 原生优化构建和严格签名检查通过。
• 原生工作台：17/17 回归命令通过；3/3 阶段、5/5 皮肤、6/6 导航页面完成真实 UI 验收。
• 待投递箱：新模型、校验、严格存储、草稿拒绝、幂等、改版替换、取消与私有权限自测通过。
• Project index、四类 Agent 解析器、MCP 合同/协议/helper 全部通过。
• 两轮原生工作台独立代码审查后：Critical 0 / Important 0；原始问题 8/8 关闭。
• git diff --check 通过。
• 本机 /Applications/codexU.app 安装后与构建二进制 SHA-256 完全一致。
• 版本保持 1.2.0，没有伪装成正式 2.0 发布。

证据

• 原生工作台记录：docs/superpowers/runs/2026-07-30-godexu-v2-native-workbench-parity.md
• 待投递箱记录：docs/superpowers/runs/2026-07-30-godexu-phase2d-human-confirmed-outbox.md
• 默认皮肤截图：docs/superpowers/runs/2026-07-30-godexu-v2-native-workbench-titanium-sync.png
• 其他阶段、皮肤和最小窗口截图位于同一目录。

[bigpowert25-del]

Phase 2E 只读核查已补充到 a6561d5：NAS 上 OpenClaw/Hermes 进程可观察，但当前没有同时受支持的任务投递入口。OpenClaw CLI 对现有 SSH 账号不可执行；Hermes 虽有带 idempotency_key 的 Kanban 结构，但直接写数据库会绕过自身校验与调度，因此明确拒绝。下一步采用“专用原子收件箱 + Agent 自己消费 + 校验回执”，SSH 上传成功不等同 Agent 已接收。研究记录与连接器设计已进入 docs/superpowers。未执行 NAS 写入，也未加入一键修复。