correct Guanghu OS master and Linux subcontrol topology

skills/codex/guanghu-os-cognitive-control/BRAIN.hdlp

@@ -19,8 +19,9 @@
 → 模型形成可解释的候选理解
 → 光湖协议核验主体、上下文、权限和边界
 → GLC / GIR 形成确定性动作图
-→ UAP 把动作映射到受限 Linux 执行适配器
-→ Linux 内核、驱动和服务完成物理动作
+→ UAP 把动作映射到受限 Linux 副控环境或其他执行适配器
+→ 光湖按需唤醒 Linux，Linux 内核、驱动和服务完成物理动作
+→ 光湖回收 Linux 副控环境并恢复休眠
 → GLOW / GLP 读取目标侧证据并形成回执
 → 结果返回语言世界，修正下一次理解
 ```
@@ -37,7 +38,7 @@ Linux 决定“怎样可靠地驱动当前硬件完成已批准动作”。Linux
 | 人格体语言主体 | 连续身份、关系、职责、解释和判断 | 当前模型进程 |
 | 模型推理设备 | 当前理解、推理、方案和异常分析 | 权限签发者或现实成功证据 |
 | 光湖确定性协议层 | 身份、上下文、动作类型、授权、回滚和回执门 | 自由语言生成器 |
-| Linux 协作执行层 | 系统调用、驱动、进程、网络、存储和隔离 | 光湖语义主控 |
+| Linux 按需协作副控 | 被光湖唤醒后提供系统调用、驱动、进程、网络、存储和隔离 | 正常入口、常驻主控或光湖语义主控 |
 | 服务器硬件 | 承载最终机器动作 | 语言、人格或规则主体 |
 
 ## 三 · 双向意识编码
@@ -100,8 +101,10 @@ Linux 决定“怎样可靠地驱动当前硬件完成已批准动作”。Linux
 
 ## 六 · Linux 的降级方式
 
-“降级”不是让静止的 Linux 文件在不运行时神奇提供驱动。使用其驱动和系统调用时，
-Linux 内核仍在技术上运行，但它被限制为光湖控制下的执行底座：
+最终架构不是让 Linux 一边常驻托管光湖、一边口头被称为副控。光湖主控必须先存在，
+Linux 执行环境平时不运行；只有动作图确实命中成熟 Linux 能力时，才由光湖唤醒一个
+受约束的副控环境。使用其驱动和系统调用的那段时间，Linux 技术上运行，但不取得系统
+入口、身份、授权、调度和完成判定主权：
 
 - 正常入口只接受光湖类型化执行请求；
 - 管理员直达路径默认关闭或进入独立紧急维护门；
@@ -109,6 +112,11 @@ Linux 内核仍在技术上运行，但它被限制为光湖控制下的执行
 - 执行适配器使用固定参数和能力白名单，不接受任意 shell；
 - 进程、网络、文件和设备权限由 namespace、cgroup、seccomp、只读根和专用服务身份约束；
 - 标准 Ubuntu 启动槽保留为独立救援路径，每次启用产生维护回执。
+- 动作完成后必须读回结果、停止或冻结副控环境并形成资源回收回执。
+
+当前 JD-FD-PRIMARY 的 Ubuntu 宿主加 `guanghu-language-primary.target` 是迁移阶段：
+语言服务控制层已存在，但光湖独立先启动、Linux 平时休眠和按需收回尚未实现。因此，
+“光湖服务在 Linux 上运行”与“光湖 OS 已成为整台服务器的最终主控”必须分开回答。
 
 ## 七 · 稳定判断边界