neurion-ai/maas

# MAAS MAAS 是一个 Codex 优先的控制平面，用于监督自主工作。 它存在于"代理可以完成工作"和"操作员可以安全地信任一个常驻系统"之间的空白地带。MAAS 将目标转化为问题清单，在受治理的执行循环中运行 Codex，使审查和恢复保持明确，提升可复用记忆，并通过运行、日志、追踪和事件使整个控制流变得可观测。 ## 它是什么 MAAS 不是通用的仪表板，也不是轻量级的 Codex 封装器。当前的产品方向是： - `Codex` 作为 MVP 执行运行时 - `Goal`、`Issue`、`Run`、`Agent`、`Event` 和 `Incident` 作为核心控制对象 - 一个操作员监督执行，而不是手动驱动每个任务 - 围绕自主工作的明确审查、恢复、记忆和交付循环 ## 为什么存在它 只有当周围的控制循环可信时，自主执行才能变得有用。MAAS 旨在回答： - 系统现在在做什么？ - 什么需要操作员判断？ - 为什么进度被阻止？ - Codex 实际上产生了什么输出？ - 什么记忆、检查和恢复规则改变了结果？ ## 核心对象 - `Goal` - `Issue` - `Run` - `Agent` - `Event` - `Incident` ## 操作员界面 - `Command`：现在需要判断什么 - `Theater`：一个问题所有权、运行状态和分支血缘的执行图谱 - `Work`：问题的共享 `List | Board` 视图以及详情和执行历史 - `Issues`：审批、阻塞的工作、失败的运行、分组审查和恢复操作 - `Agents`：活动所有权、执行线程、生成的工作和健康状态 - `Runs`：实时和历史执行真相 - `System`：日志、指标、队列状态和机器健康 - `Projects`：创建、导入、克隆、归档、删除和状态管理 ## 与众不同之处 - 项目级自动驾驶，而不是手动"运行周期"值守 - 一流的运行历史、追踪和实时执行真相 - 明确的审查策略和分组审查数据包 - 恢复剧本而不是原始失败队列 - 基于检索的项目记忆，包含提升、归属和有用性追踪 - 交付准备、GitHub 草稿 PR 同步和验证门控交接 ## 当前状态 今天 MAAS 是一个围绕以下构建的实质性本地原型： - Python/FastAPI 后端，使用 SQLite 作为状态存储 - 用于 Command、Theater、Work、Issues、Agents、Runs、System 和 Projects 的 React 控制平面 - 目标摄入、问题合成、自动驾驶、审查、恢复、检索、交付准备和 GitHub 同步流程 - 基于协调的真相检查和修复，用于过时的运行、任务、代理和交付关联 - 重试安全的外部效果，用于通知、提供商任务、git 工作区和 GitHub PR 同步 - 带有确定性故障注入和可重放事件证据的持久化信任运行 - 用于追踪问题、PR 和审查状态的 GitHub 项目驱动执行工作流 - 带操作员可见日志、追踪和产物的实时和模拟 Codex 执行路径 实现历史很长，因为产品已经多次调整。 above is the one that matters now; the detailed historical roadmap is still preserved below for implementation tracking. ## 快速开始 安装后端和前端依赖项，然后在本地启动 API 和 Web 应用： ``` python3 -m venv .venv source .venv/bin/activate pip install -e . cd web npm install cd .. ./scripts/maas-dev up ./scripts/maas-dev status ``` 托管的本地预览工作流： - 创建或重用 `/tmp/maas-dev/workspace` 下的演示工作区 - 将此仓库作为棕地项目导入该工作区 - 在 `0.0.0.0:8000` 上启动 API，在 `0.0.0.0:5173` 上启动 Web 应用 - 将 pid 文件和日志保存在 `/tmp/maas-dev` 下 - 记住上次选择的工作区和端口设置在 `/tmp/maas-dev/dev-config.json` 中 使用以下命令停止或重启堆栈： ``` ./scripts/maas-dev down ./scripts/maas-dev restart ``` 运行带有确定性故障注入的持久化本地信任沉浸测试： ``` PYTHONPATH=src ./scripts/maas-trust-run --project-root /tmp/maas-dev/workspace --cycles 12 --sleep-seconds 60 ``` 如果您的机器上 `:8000` 或 `:5173` 已被占用，传递明确的覆盖值，例如 `./scripts/maas-dev --web-port 5183 up` 或 `./scripts/maas-dev --api-port 8001 --web-port 5183 up`。 `status`、`restart` 和 `down` 重用 `/tmp/maas-dev/dev-config.json` 中的上次选择设置。 如果您想要本地主机绑定而不是 LAN 暴露，传递 `--api-host 127.0.0.1 --web-host 127.0.0.1`。 您仍然可以根据需要从 CLI 手动引导和运行 MAAS： ``` PYTHONPATH=src python3 -m maas init --project-root . PYTHONPATH=src python3 -m maas db migrate --project-root . PYTHONPATH=src python3 -m maas api --project-root . cd web && npm run dev ``` ## 产品方向 相关的设计和路线图文档： - [自主组织转型](docs/implementation/09-autonomous-organization-pivot.md) - [UI 重置](docs/implementation/10-ui-reset.md) - [Codex MVP 形态](docs/implementation/11-codex-mvp-shape.md) - [Codex MVP 集成计划](docs/implementation/12-codex-mvp-integration-plan.md) - [Codex MVP 强化计划](docs/implementation/13-codex-mvp-hardening-plan.md) - [Codex MVP 下一批计划](docs/implementation/14-codex-mvp-next-batch-plan.md) - [Codex MVP 自治规模计划](docs/implementation/15-codex-mvp-autonomy-scale-plan.md) - [Codex MVP 自动驾驶和记忆计划](docs/implementation/16-codex-mvp-autopilot-memory-plan.md) - [Codex MVP 控制循环强化计划](docs/implementation/17-codex-mvp-control-loop-hardening-plan.md) - [Codex MVP 医生、规划和交付循环计划](docs/implementation/18-codex-mvp-doctor-delivery-loop-plan.md) - [Codex MVP 交付执行和验证计划](docs/implementation/19-codex-mvp-delivery-execution-verification-plan.md) - [Codex MVP 可解释性、审查和记忆计划](docs/implementation/20-codex-mvp-explainability-review-memory-plan.md) - [Codex MVP 控制循环治理和可观测性计划](docs/implementation/21-codex-mvp-control-loop-governance-observability-plan.md) - [Codex MVP 棕地深度通道](docs/implementation/22-codex-mvp-brownfield-depth-pass.md) - [Codex MVP 棕地执行杠杆](docs/implementation/23-codex-mvp-brownfield-execution-leverage.md) - [Codex MVP 棕地漂移、刷新和信任](docs/implementation/24-codex-mvp-brownfield-drift-refresh-trust.md) - [执行剧场基础](docs/implementation/26-execution-theater-foundation.md) - [执行剧场领域和代理运动](docs/implementation/27-execution-theater-field-agent-motion.md) - [执行剧场分支、工作树和 PR 血缘](docs/implementation/28-execution-theater-branch-worktree-pr-lineage.md) - [执行剧场内部生产就绪](docs/implementation/29-execution-theater-internal-production-readiness.md) - [本地开发生命周期脚本](docs/implementation/30-local-dev-lifecycle-scripts.md) - [无人值守本地信任 v1：不变量和协调](docs/implementation/31-unattended-local-trust-invariants-reconciliation.md) - [无人值守本地信任 v1：幂等副作用和重试安全](docs/implementation/32-unattended-local-trust-idempotent-side-effects.md) - [无人值守本地信任 v1：停止状态和操作员真相](docs/implementation/33-unattended-local-trust-stop-states-operator-truth.md) - [无人值守本地信任 v1：隔夜沉浸和故障注入](docs/implementation/34-unattended-local-trust-soak-fault-injection.md) - [无人值守本地信任 v1：最终关闭和信任门控](docs/implementation/35-unattended-local-trust-final-closure-gate.md) 当前方向还有一个独立的产品原型，见 [mockups/maas-codex-mvp/README.md](mockups/maas-codex-mvp/README.md)。 ## 执行工作流 主动规划和执行现在在 GitHub 上进行，而不是在编号的实现文档中。 - 执行层：[MAAS 交付与执行](https://github.com/orgs/neurion-ai/projects/4) - 当前真相文档：[README.md](README.md)、[docs/implementation/STATUS.md](docs/implementation/STATUS.md) 和 [docs/implementation/WORKFLOW.md](docs/implementation/WORKFLOW.md) - 历史/参考文档：[docs/implementation](docs/implementation/) 下的编号实现文档 每个追踪的任务或路线图项目使用一个 GitHub 问题，保持项目字段真实，并在代码工作开始后链接 PR。协调现在还会为此仓库自己的 GitHub 项目修复过时的已合并状态卡片，当追踪的问题已被合并的 PR 关闭时。 对于无人值守的本地使用，依赖 System 界面的信任门控而不是 README 文本。MAAS 现在暴露了一个明确的无人值守模式门控，只有在新的信任沉浸测试通过、干净的真相协调和健康的启动状态后才启用。 ## 路线图和实现历史 本 README 的其余部分追踪已交付的实现和编号的交付历史作为存档/参考。 ## 实现快照 图例： - `[x]` 在当前编号交付序列中已完成 - `[ ]` 在当前编号交付序列中尚未完成 使用下面的堆叠分支引用来查看已完成的项目是在 `main` 上还是仅存在于堆叠分支上。 `main` 上方的历史堆叠开发链： - `#82` 存在于 `codex/project-aware-supervisor-orchestration` - `#83` 存在于 `codex/brownfield-file-backed-planning` - `#84` 存在于 `codex/recovery-circuit-breakers` `#85` 存在于 `codex/project-isolated-provider-runtime` - `#86` 存在于 `codex/provider-job-queue` - `#87` 存在于 `codex/provider-job-queue` - `#88` 存在于 `codex/file-linked-task-scopes` - `#89` 存在于 `codex/brownfield-runbook-command-catalog` - `#90` 存在于 `codex/brownfield-runbook-command-catalog` - `#91` 存在于 `codex/brownfield-runbook-command-catalog` - `#92` 存在于 `codex/queue-capacity-controls` - `#93` 存在于 `codex/session-runner-envelopes` - `#94` 存在于 `codex/policy-driven-self-healing-v2` - `#95` 存在于 `codex/brownfield-onboarding-review-v2` - `#96` 存在于 `codex/remote-executor-worker-pool` - `#97` 存在于 `codex/cross-project-scheduler-fairness` - `#98` 存在于 `codex/repo-grounded-plan-synthesis` - `#99` 存在于 `codex/verification-runners-evidence-capture` - `#100` 存在于 `codex/git-aware-task-workspaces` - `#101` 存在于 `codex/cross-project-command-center` - `#102` 存在于 `codex/queue-worker-capacity-governance` - `#103` 存在于 `codex/queue-worker-capacity-governance` - `#104` 存在于 `codex/queue-worker-capacity-governance` - `#105` 存在于 `codex/queue-worker-capacity-governance` - `#106` 存在于 `codex/queue-worker-capacity-governance` - `#107` 存在于 `codex/ux-product-redesign` - `#108` 存在于 `codex/ux-product-redesign` - `#109` 存在于 `codex/ux-product-redesign` - `#110` 存在于 `codex/ux-product-redesign` - `#111` 存在于 `codex/ux-product-redesign` - `#112` 存在于 `codex/ux-product-redesign` - `#113` 存在于 `codex/ux-product-redesign` - `#114` 存在于 `codex/ux-product-redesign` - `#115` 存在于 `codex/ux-product-redesign` - `#116` 存在于 `codex/ux-product-redesign` - `#117` 存在于 `codex/linear-vibekanban-cockpit` - `#118` 存在于 `codex/linear-vibekanban-cockpit` - `#119` 存在于 `codex/linear-vibekanban-cockpit` - `#120` 存在于 `codex/linear-vibekanban-cockpit` - `#121` 存在于 `codex/linear-vibekanban-cockpit` - `#122` 存在于 `codex/linear-vibekanban-cockpit` - `#123` 存在于 `codex/linear-vibekanban-cockpit` - `#124` 存在于 `codex/linear-vibekanban-cockpit` - `#125` 存在于 `codex/linear-vibekanban-cockpit` - `#126` 存在于 `codex/linear-vibekanban-cockpit` - `#127` 存在于 `codex/linear-vibekanban-cockpit` - `#128` 存在于 `codex/linear-vibekanban-cockpit` - `#129` 存在于 `codex/linear-vibekanban-cockpit` - `#130` 存在于 `codex/linear-vibekanban-cockpit` - `#131` 存在于 `codex/linear-vibekanban-cockpit` - `#132` 存在于 `codex/linear-vibekanban-cockpit` - `#133` 存在于 `codex/linear-vibekanban-cockpit` - `#134` 存在于 `codex/linear-vibekanban-cockpit` - `#135` 存在于 `codex/linear-vibekanban-cockpit` - `#136` 存在于 `codex/linear-vibekanban-cockpit` - `#137` 存在于 `codex/linear-vibekanban-cockpit` - `#138` 存在于 `codex/linear-vibekanban-cockpit` - `#139` 存在于 `codex/linear-vibekanban-cockpit` - `#140` 存在于 `codex/linear-vibekanban-cockpit` - `#141` 存在于 `codex/linear-vibekanban-cockpit` - `#142` 存在于 `codex/linear-vibekanban-cockpit` - `#143` 存在于 `codex/linear-vibekanban-cockpit` - `#144` 存在于 `codex/linear-vibekanban-cockpit` - `#145` 存在于 `codex/linear-vibekanban-cockpit` - `#146` 存在于 `codex/linear-vibekanban-cockpit` - `#147` 存在于 `codex/linear-vibekanban-cockpit` - `#148` 存在于 `codex/linear-vibekanban-cockpit` - `#149` 存在于 `codex/linear-vibekanban-cockpit` - `#150` 存在于 `codex/linear-vibekanban-cockpit` - `#151` 存在于 `codex/linear-vibekanban-cockpit` - `#161` 存在于 `codex/codex-mvp-shell-integration` - `#162` 存在于 `codex/codex-mvp-shell-integration` - `#163` 存在于 `codex/codex-mvp-shell-integration` - `#164` 存在于 `codex/codex-mvp-shell-integration` - `#165` 存在于 `codex/codex-mvp-shell-integration` - `#166` 存在于 `codex/codex-mvp-shell-integration` - `#167` 存在于 `codex/codex-mvp-shell-integration` - `#168` 存在于 `codex/codex-mvp-shell-integration` - `#169` 存在于 `codex/codex-mvp-shell-integration` - `#170` 存在于 `codex/codex-mvp-shell-integration` - `#171` 存在于 `codex/codex-mvp-hardening` - `#172` 存在于 `codex/codex-mvp-hardening` - `#173` 存在于 `codex/codex-mvp-hardening` - `#174` 存在于 `codex/codex-mvp-hardening` - `#175` 存在于 `codex/codex-mvp-hardening` - `#176` 存在于 `codex/codex-mvp-hardening` - `#177` 存在于 `codex/codex-mvp-hardening` - `#178` 存在于 `codex/codex-mvp-hardening` [docs/implementation/14-codex-mvp-next-batch-plan.md](docs/implementation/14-codex-mvp-next-batch-plan.md) 中的当前操作员价值和能力序列现在在 `codex/codex-mvp-operator-scale` 上实现。它添加了真实的队列状态、就绪感知启动策略、共享的 `Work`/`Issues` 范围、一流的运行详情读取、更强的代理/系统执行诊断、验证驱动的自动审批和更干净的新项目生命周期控制。 [docs/implementation/15-codex-mvp-autonomy-scale-plan.md](docs/implementation/15-codex-mvp-autonomy-scale-plan.md) 中的当前自治规模序列现在在 `codex/codex-mvp-autonomy-scale` 上实现。它添加了一流的 `Runs`、后端拥有的异常分组、跨问题/运行/产物的检索、克隆新运行的项目生命周期、更强的过时运行诊断、`Projects` 中的跨项目监督以及带可选桌面通知的异步注意力循环。 [docs/implementation/16-codex-mvp-autopilot-memory-plan.md](docs/implementation/16-codex-mvp-autopilot-memory-plan.md) 中的当前自动驾驶和记忆序列现在在 `codex/codex-mvp-autopilot-memory` 上实现。它添加了项目模板、项目级自动驾驶、记忆提升和基于检索的 Codex 提示、后端拥有的批量审查以及跨 `Command`、`Issues`、`System` 和问题详情的更强执行状态真相。 [docs/implementation/17-codex-mvp-control-loop-hardening-plan.md](docs/implementation/17-codex-mvp-control-loop-hardening-plan.md) 中的当前控制循环强化序列现在在 `codex/codex-mvp-control-loop-hardening` 上实现。它添加了持久的自动驾驶租约状态、后端拥有的操作员收件箱生命周期安全的克隆状态重置、分组审查数据包真相、通知失败集成和更新的执行记忆归属。 [docs/implementation/18-codex-mvp-doctor-delivery-loop-plan.md](docs/implementation/18-codex-mvp-doctor-delivery-loop-plan.md) 中的当前医生、规划和交付循环序列现在在 `codex/codex-mvp-doctor-delivery-loop` 上实现。它添加了环境医生、一流的目标创建和合成、交付候选读取以及 PR 草稿准备、更强的自动驾驶治理门控、目标范围的审查数据包和有用性感知的执行记忆。 `codex/linear-vibekanban-cockpit` 上的当前产品建模序列涵盖了驾驶舱转型（`#127-#136`）、Linear/Vibekanban 灵感的工作流清理（`#137-#146`）以及明确的驾驶舱/看板角色分离（`#147-#151`）。 `codex/codex-mvp-shell-integration` 上的当前 Codex-MVP 集成序列将产品重置带入真实应用，带有新 shell、规范化问题身份、问题详情和代理详情读取模型，以及集成的 `Command` / `Work` / `Issues` / `Agents` / `System` 界面。 `codex/codex-mvp-hardening` 上的当前强化序列使集成的 MVP 在实时使用中真实：明确的运行周期与启动状态控制、审查优先的问题详情、模拟/实时警告、项目删除和新工作区创建，以及更严格的生命周期回归。 ### 当前项目状态 - [x] MAAS 现在是一个实质性的单一项目、绿.operation监督原型。 - [x] 核心循环从头到尾存在：引导、看板、主管、提供商执行、失败处理、隔离、恢复和产物检查。 - [x] 对于当前的原型形态，仓库大约完成了 `85-90%`。 - [ ] 对于更广泛的路线图愿景，仓库仍然明显不完整。 ### 已在 `main` 上交付 - [x] 带种子目标、任务、代理、警报和会话的绿地引导 - [x] 优先看板 API 和 React 控制室 - [x] 就绪队列刷新、接受评估和第一轮空闲代理分配 - [x] 审查、重新优先、重新分配、暂停/恢复和停止的转向控制 - [x] 风险转向审批的升级队列 - [x] 失败记忆日志、隔离可见性、重复失败警报、事件特定警报操作和失败阻塞工作的任务恢复 - [x] 失败阻塞任务的手动恢复和重新排队 - [x] 超时和失败会话的自动重试，带追踪的重试状态 - [x] 明确的调度器评分、看板可见的调度器理由和自适应重计划指导 - [x] 手动重计划队列和耗尽重试工作的死信路由 - [x] 隔离队列工作流，带恢复、忽略、重新打开和恢复+重新排队操作 - [x] 处于 `error` 状态的代理恢复 - [x] 明确的提供商配置后的真实本地 Claude Code CLI 集成 - [x] 明确的提供商配置后的真实本地 OpenAI Codex CLI 集成 - [x] 提供商状态可见性，带有效模式、运行时控制、配置警告、预检就绪、近期运行历史、手动运行控制、模式切换和可编辑设置 - [x] 产物浏览器和控制室中的产物状态可见性 - [x] 产物浏览器支持预览、受保护的下载、比较、血缘/来源透视和任务/会话导出包 - [x] 产物浏览器操作员操作，对隔离产物进行恢复、恢复+重新排队、忽略和重新打开 - [x] 带 websocket、SSE 和轮询回退状态的共享实时传输在控制室 shell 中 ### 在 `main` 上仍需完成 - [ ] 产品 UX 简化、更清晰的心智模型和更强的首次运行指导 - [ ] 视觉强大的双明/暗主题和真正的设计系统，而不是当前的 admin-tool 感觉 - [ ] 更广泛的自动重启、重试、退避和自愈工作流，超出当前 DLQ 路径 - [ ] 更广泛的外部提供商覆盖，超出当前的本地 CLI 路径 - [ ] 更高层的产物保留策略自动化，超出当前的浏览器、来源和导出流程 - [ ] 更深的棕地引导和多项目执行支持 - [ ] 更强的沙盒和隔离保证 - [ ] 项目感知的背景编排，超出当前的多项目读取范围 ### 当前编号交付序列 - [x] `#80` 提供商运行时预检和就绪检查 - [x] `#81` 多项目写入路径和项目生命周期 - [x] `#82` 项目感知主管和背景编排 - [x] `#83` 棕地文件支持的计划和仓库导航 - [x] `#84` 策略驱动的自愈和断路器 - [x] `#85` 每个项目的沙盒化提供商运行器 - [x] `#86` 超出本地 CLI 路径的远程或排队提供商执行 - [x] `#87` 棕地重新扫描和漂移检测 - [x] `#88` 文件链接的任务范围和接受标准 - [x] `#89` 棕地手册和命令目录 - [x] `#90` 跨项目组合视图 - [x] `#91` 背景编排守护进程 - [x] `#92` 提供商作业队列之上的队列和运行器容量管理 - [x] `#93] 更强的运行器沙盒封装，超出当前的项目级运行时隔离 - [x] `#94` 策略驱动的自愈 v2 - [x] `#95` 棕地引导审查 v2 - [x] `#96` 远程执行器或运行器池 - [x] `#97` 跨项目调度器公平性和容量策略 - [x] `#98` 基于仓库的计划合成和刷新 - [x] `#99] 验证运行器和证据捕获 - [x] `#100` Git 感知任务工作区和差异审查 - [x] `#101` 跨项目命令中心 - [x] `#102` 队列和运行器容量控制 - [x] `#103] 策略驱动的审批和风险路由 - [x] `#104` 成本、运行时和配额控制 - [x] `#105` 通知和出站集成 - [x] `#106` 事件时间线和重放 - [x] `#107] 信息架构重置和导航折叠 - [x] `#108` 设计系统和双明/暗主题基础 - [x] `#109] 带推荐操作的主命令中心 - [x] `#110] 引导引导和首次运行体验 - [x] `#111] 统一工作界面，用于看板、计划和任务详情 - [x] `#112] 统一运行界面，用于代理、提供商、验证和输出 - [x] `#113] 统一事件界面，用于失败、警报、恢复和时间线 - [x] `#114] 组合和项目管理 UX 重新设计 - [x] `#115] 命令面板、上下文操作、空状态和内联指导 - [x] `#116] 可访问性、响应性和视觉优化 - [x] `#117] Shell 密度重置 - [x] `#118] 默认控制室布局 - [x] `#119] 紧凑看板重新设计 - [x] `#120] 代理名册和交互视图 - [x] `#121] 策划实时提要 - [x] `#122] 目标/子目标/任务关系浏览器 - [x] `#123] 事件轨道和剧本 - [x] `#124] 证据和验证抽屉 - [x] `#125] 项目状态和组合命令栏 - [x] `#126] 移除遗留的英雄 UX 和最终密集视觉优化 - [x] `#127] Seraph 风格驾驶舱 shell 转型 - [x] `#128] 面板工作区和窗口组合 - [x] `#129] 驾驶舱命令栏和遥测条 - [x] `#130] 密集代理轨道 - [x] `#131] 中心看板工作区重写 - [x] `#132] 右侧操作轨道用于事件和提要 - [x] `#133] 检查器和证据工作区 - [x] `#134] 项目、提供商和设置的实用抽屉 - [x] `#135] 驾驶舱字体和主题系统 - [] `#136] 移除遗留页面界面并完成驾驶舱交互模型 - [x] `#137] 引导引导接管 - [x] `#138] 紧凑问题卡和检查器优先转向 - [x] `#139] 看板优先工作流默认值 - [x] `#140] 导入和创建抽屉 - [x] `#141] 项目下一步工作流 - [x] `#142] 策划实时运营优先级 - [x] `#143] Linear/Vibekanban 灵感看板优化 - [x] `#144] 实用程序和设置降级 - [x] `#145] 密集字体和暗主题清理 - [x] `#146] 移除剩余的内联控制混乱 - [x] `#147] 明确的驾驶舱和看板角色 - [x] `#148] 引导棕地审查/启动流程 - [x] `#149] 统一运行操作和高级控制降级 - [x] `#150] 意图优先项目设置流程 - [x] `#151] 检查器可见的看板交互模型 ### 当前堆叠分支进度 - [x] `#81` 已在 `main` 上交付 - [x] `#82` 在 `codex/project-aware-supervisor-orchestration` 上实现 - [x] `#83` 在 `codex/brownfield-file-backed-planning` 上实现 - [x] `#84` 在 `codex/recovery-circuit-breakers` 上实现 - [x] `#85` 在 `codex/project-isolated-provider-runtime` 上实现 - [x] `#86` 在 `codex/provider-job-queue` 上实现 - [x] `#87` 在 `codex/provider-job-queue` 上实现 - [x] `#88` 在 `codex/file-linked-task-scopes` 上实现 - [x] `#89` 在 `codex/brownfield-runbook-command-catalog` 上实现 - [x] `#90` 在 `codex/brownfield-runbook-command-catalog` 上实现 - [x] `#91` 在 `codex/brownfield-runbook-command-catalog` 上实现 - [x] `#92` 在 `codex/queue-capacity-controls` 上实现 - [x] `#93` 在 `codex/session-runner-envelopes` 上实现 - [x] `#94` 在 `codex/policy-driven-self-healing-v2` 上实现 - [x] `#95` 在 `codex/brownfield-onboarding-review-v2` 上实现 - [x] `#96` 在 `codex/remote-executor-worker-pool` 上实现 - [x] `#97` 在 `codex/cross-project-scheduler-fairness` 上实现 - [x] `#98` 在 `codex/repo-grounded-plan-synthesis` 上实现 - [x] `#99` 在 `codex/verification-runners-evidence-capture` 上实现 - [x] `#100` 在 `codex/git-aware-task-workspaces` 上实现 - [x] `#101` 在 `codex/cross-project-command-center` 上实现 - [x] `#102` 在 `codex/queue-worker-capacity-governance` 上实现 - [x] `#103` 在 `codex/queue-worker-capacity-governance` 上实现 - [x] `#104` 在 `codex/queue-worker-capacity-governance` 上实现 - [x] `#105` 在 `codex/queue-worker-capacity-governance` 上实现 - [x] `#106` 在 `codex/queue-worker-capacity-governance` 上实现 - [x] `#107` 在 `codex/ux-product-redesign` 上实现 - [x] `#108` 在 `codex/ux-product-redesign` 上实现 - [x] `#109` 在 `codex/ux-product-redesign` 上实现 - [x] `#110` 在 `codex/ux-product-redesign` 上实现 - [x] `#111` 在 `codex/ux-product-redesign` 上实现 - [x] `#112` 在 `codex/ux-product-redesign` 上实现 - [x] `#113` 在 `codex/ux-product-redesign` 上实现 - [x] `#114` 在 `codex/ux-product-redesign` 上实现 - [x] `#115` 在 `codex/ux-product-redesign` 上实现 - [x] `#116` 在 `codex/ux-product-redesign` 上实现 - [x] `#117` 在 `codex/linear-vibekanban-cockpit` 上实现 - [x] `#118` 在 `codex/linear-vibekanban-cockpit` 上实现 - [x] `#119` 在 `codex/linear-vibekanban-cockpit` 上实现 - [x] `#120` 在 `codex/linear-vibekanban-cockpit` 上实现 - [x] `#121` 在 `codex/linear-vibekanban-cockpit` 上实现 - [x] `#122` 在 `codex/linear-vibekanban-cockpit` 上实现 - [x] `#123` 在 `codex/linear-vibekanban-cockpit` 上实现 - [x] `#124` 在 `codex/linear-vibekanban-cockpit` 上实现 - [x] `#125` 在 `codex/linear-vibekanban-cockpit` 上实现 - [x] `#126` 在 `codex/linear-vibekanban-cockpit` 上实现 当前的 `#81-#126` 序列在 `main` 上方的堆叠分支链上完全实现。 ### 在堆叠分支上实现的 UX 和产品设计序列 - [x] `#107` 信息架构重置和导航折叠： 将当前顶层控制室精简为更少的主要界面，使用更清晰的用户语言标签和更强的心智模型。 - [x] `#108` 设计系统和双明/暗主题基础： 引入语义颜色、间距、字体和elevation标记，以及持久的明/暗模式，使 UI 不再像内部 admin 工具。 - [x] `#109] 带推荐操作的主命令中心： 用"需要关注什么 / 我接下来应该做什么"的着陆体验替换当前过载的概览状态。 - [x] `#110] 引导引导和首次运行体验： 添加创建/导入/设置流程，解释 MAAS 在做什么、项目状态意味着什么以及下一步安全步骤是什么。 - [x] `#111] 统一工作界面，用于看板、计划和任务详情： 将看板、目标树和基于仓库的计划合并到具有更丰富任务详情和证据抽屉的单一执行工作区。 - [x] `#112] 统一运行界面，用于代理、提供商、验证和输出： 不再将执行状态分割到单独的筒仓中，呈现一个连贯的操作员视图，展示活动工作和产生的证据。 - [x] `#113] 统一事件界面，用于失败、警报、恢复和时间线： 将事件响应变成一个带有明确剧本的引导工作台，而不是四个单独的机制繁重的页面。 - [x] `#114] 组合和项目管理 UX 重新设计： 改进项目切换、生命周期操作、跨项目健康和多项目监督，而不将用户埋没在策略表单中。 - [x] `#115] 命令面板、上下文操作、空状态和内联指导： 使高级功能可被发现，而不淹没默认 UI。 - [x] `#116] 可访问性、响应性和视觉优化： 用移动/平板行为、键盘优先交互、更强的层次结构和可用性 QA 完成重新设计。 ### 在堆叠分支上实现的密集操作员控制室序列 - [x] `#117] Shell 密度重置： 移除过大的着陆页 shell，用更紧凑的顶部条、更紧密的导航和更小的控件替换。 - [x] `#118] 默认控制室布局： 使着陆屏幕成为密集的三窗格操作员驾驶舱，左侧是代理，中间是看板，右侧是运营上下文。 - [x] `#119] 紧凑看板重新设计： 用紧凑的执行卡替换过大的卡片，一目了然地显示负责人、目标、证据信号和失败压力。 - [x] `#120] 代理名册和交互视图： 将代理变成具有状态、当前工作、心跳和快速钩子的一等可见参与者。 - [x] `#121] 策划实时提要： 添加密集的有意义事件提要，使系统感觉生动，而不变成原始遥测垃圾邮件。 - [x] `#122] 目标/子目标/任务关系浏览器： 在单个检查器中显示所选任务的目标血缘、兄弟工作、仓库计划匹配和最近任务特定历史。 - [x] `#123] 事件轨道和剧本： 直接在右侧轨道显示可操作的事件，而不是强迫操作员通过单独的 admin 页面寻找。 - [x] `#124] 证据和验证抽屉： 将验证状态、git 差异、产物和任务历史放在所选任务旁边。 - [x] `#125] 项目状态和组合命令栏： 将项目选择、健康、警报负载和传输/运行时状态移入紧凑顶部命令条。 - [x] `#126] 移除遗留的英雄 UX 和最终密集视觉优化： 在整个控制室中缩小字体、卡片高度和按钮比例，使产品读起来像运营驾驶舱而不是着陆页。 - [ ] `#127] Seraph 风格驾驶舱 shell 转型： 用固定高度的驾驶舱 shell、紧凑的顶部条、内部滚动区域和明确的操作、专注和审查等工作区模式替换页面和卡片 shell。 - [ ] `#128] 面板工作区和窗口组合： 将默认体验重组为持久的左轨道、中心工作区和右轨道面板，带有面板范围的溢出而不是堆叠部分。 - [ ] `#129] 驾驶舱命令栏和遥测条： 将导航、项目切换、实时传输状态、运行控制和快速命令折叠到一个密集的操作员条中。 - [ ] `#130] 密集代理轨道： 将代理可见性重建为带有状态、当前工作、最近有意义事件和快速干预钩子的紧凑实时轨道。 - [ ] `#131] 中心看板工作区重写： 使看板成为具有更密集卡片、更少空 lanes、范围化积压访问和更好操作/专注/审查模式的主要工作区。 - [ ] `#132] 右侧操作轨道用于事件和提要： 将策划提要、审批、警报和事件快捷方式合并到一个紧凑的操作轨道中，而不是单独的仪表板块。 - [ ] `#133] 检查器和证据工作区： 将所选任务上下文变成真正的检查器，带有目标路径、仓库范围、验证、git 差异、产物和历史在单个持久面板中。 - [ ] `#134] 实用抽屉用于项目、提供商和设置： 将生命周期表单、提供商设置、配额和策略编辑器从主要工作区移出到抽屉和高级实用窗口中。 - [ ] `#135] 驾驶舱字体和主题系统： 用更密集的 mono-forward 驾驶舱系统替换当前的通用卡片样式，灵感来自 Seraph 的 shell 而不复制其游戏风格。 - [ ] `#136] 移除遗留页面界面并完成驾驶舱交互模型： 删除或降级旧的仪表板/页面

标签：AI运维, API集成, Codex, DevOps工具, SRE工具, 事件管理, 人机协作, 代理监督, 任务编排, 可观测性, 审计日志, 工作流管理, 控制平面, 故障恢复, 日志追踪, 自主代理, 自主系统, 自动化执行, 运行时管理, 逆向工具, 问题跟踪