面向复杂软件工作的闭环协调层
把专家路由 · 计划 · 执行 · 迭代 · Beta · Release · Feedback 收拢成一个可持续迭代的闭环工作流，并以工程约束门禁 · Worker/Verifier 对抗式验收 · 反熵治理 · 自优化循环保障交付质量。 适合接手"单个专家已经不够、单轮回答也不够"的复杂软件任务。
单点专家解决的是"换一个视角"，闭环协调层解决的是"如何把多视角收敛成可交付、可回滚、可验证的结果"。
跨域任务找不到唯一负责角色，前端、后端、安全、产品、发布各有立场，但缺少一个负责"谁主、谁辅、是否需要治理"的协调层。
复杂任务需要"计划 → 执行 → 验证 → 迭代"的闭环，而不是一次性建议。缺少基线、轮次记忆与回滚点的工作流很容易越改越乱。
决策黑箱，无法审计和回滚。一旦结果不对，难以追溯是哪个路由判断、哪一轮迭代、哪一次 fallback 引入的偏差。
每一层都有触发条件、核心机制与关键产物；只在任务确实需要时激活，不做无意义流程升级。
每次任务由一个 lead 主导，必要时附加 assistant 与 governance 轨道，避免角色堆叠与责任漂移。
JVM 生态深度执行
安全与架构守护
前端 / 后端 / 数据库三位一体
代码审计委员会
Git 流程与回滚守护
产品架构与 PRD
数据管道守护
API 契约与兼容性
不是简单"换几个角色回答"，而是覆盖路由、验证、迭代、发布、记忆与真实 runtime 的协调层。
默认手动模式适合高风险任务；显式 /auto 进入两阶段自动运行；单专家路由用于领域清晰的小切片。
不带 /auto，逐轮确认路由与执行路径，适合高风险任务和需要人工把关的发布决策。
# 接管重构并给出可执行分工 $virtual-intelligent-dev-team 帮我接管这次 重构，并给出可执行分工。
显式 /auto 进入 setup → go 两阶段协议，先建 automation state，再执行有界迭代。
# 项目级迁移：先建状态再执行 $virtual-intelligent-dev-team /auto setup 这个项目级迁移。 $virtual-intelligent-dev-team /auto go
领域清晰的小切片直接路由到对应专家，保留 quick slice brief 与完成证据。
# 邮箱验证小切片：路由到 Technical Trinity $virtual-intelligent-dev-team 实现用户登录功能的邮箱验证