从哪来 · 为什么 · 怎么做
玖衍 Q4 问「训练模式和实战模式有何不同」。本节把 opMode 差异写成可对照的配置表，而非口头约定。
同一壳、不同风险
早期把 train 与 live 做成两套前端，导致教学演示与实战验收行为不一致——学员在 train 里习惯的「一键自动打击」，到 live 却需要完全不同的操作路径。指挥员无法建立肌肉记忆，verify 也无法用同一套脚本覆盖两种场景。
OpenNexus 收敛为：Brain COP + Gradio 参谋 + 杀伤链面板 UI 不变，仅 opMode 切换后端策略——executor、ATO 状态机、BDA 解锁逻辑随之分叉。
LVC 职责分离
Live Virtual Constructive 要求：构造态（train）可快速迭代、允许 stub 映射与自动执行；实战态（live）强制异构 executor、人审 pending 队列、JUDGE 裁决 BDA。职责分离不是「两个系统」，而是同一管道的 Gate 策略差。
教学价值在于对比：同一 fusedId、同一 atomic_task，切换 opMode 即可看到「自动通过 vs 人工卡点」——这比两套独立 Demo 更有说服力。
opMode 策略表
executor：train → cmo 自动执行；live → ygxt 异构席 + pending 队列。
ATO：train → 自动生成并下发；live → pending 等人审后 dispatch。
BDA：train → force-unlock 教学用强制解锁下一目标；live → 必须等 JUDGE 回写 strikeResult 才能进入飞轮下一目标。
train / live 双模式分叉
联调验收时：同一想定、同一 fusedId，切换 opMode 观察 executor 与 ATO 状态机差异——这是 LVC 教学的核心对比实验。
opMode 策略对照表
executor：cmo vs ygxt
train 模式下，atomic_tasks 经 MultiLLMCoordinator 合并后直接路由至 cmo executor——Command 仿真自动实例化 Mission，用于课堂演示「从参谋建议到仿真动作」的全链路。live 模式下，同结构任务进入 ygxt（异构推演席）pending 队列，指挥员必须在 Brain COP 上逐条批准；未批准任务 WPF :5000 写口拒绝执行。两套 executor 共享同一 JSON schema，差异仅在 Gate 策略。
ATO 状态机：auto vs pending
杀伤链 Step③ 生成 LvFlightPlanV1 后，train 模式 ATO 模块自动 dispatch 至 Command；live 模式标记为 pending，等待指挥员 HITL 确认。这保证了 live 场景下每一发 ATO 都有人工背书，审计链完整。禁止 dual-push：同一 plan_id 不得同时出现在 auto 与 pending 通道。
BDA 飞轮：force-unlock vs JUDGE
train 模式为加速教学节奏，BDA 模块允许 force-unlock——即使 JUDGE 尚未回写毁伤评估，也可手动进入下一 fusedId 目标，用于讲解 OODA 循环结构。live 模式严格等待 JUDGE 回写 strikeResult（命中/未命中/毁伤等级）后，Brain 才解锁杀伤链飞轮的下一目标。这是 live 验收的硬 Gate。
门户 ACL 与 opMode 绑定
门户统一认证（9060 Auth API）将会话 opMode 与角色绑定：访客默认 train；admin / 授权指挥员可切换 live。SSO 桥确保跨子域（cmo / brain / gradio）opMode 一致——避免「Brain 在 live、CMO 还在 train」的分裂态。