4.2 KiB
光湖 OS 主控与 Linux 按需协作副控架构
架构记录：
HLP-GUANGHU-OS-CONTROL-001@2026-08-10.1当前架构：
HLP-CURRENT-ARCH-001@2026-08-10.12开发编号：
DEV-20260810-012
结论
光湖 OS 的最终服务器形态不是删除 Linux，也不是让 Linux 永久常驻、先启动并托管一个 名为光湖的服务。光湖 OS 掌握正常入口、身份、语言、授权、调度、执行生命周期、成功 判定和失败恢复；完整 Linux 系统平时休眠，只在命中成熟执行能力时被光湖有界唤醒为 协作副控，任务完成后由光湖收回。Linux 的独立救援与维护入口永久保留。
人类目标 / 人格体任务
→ 光湖 OS 恢复主体、协议、权限与当前事实
→ 光湖判断是否需要 Linux 成熟能力
├─ 不需要：光湖或其他注册执行器直接完成
└─ 需要：有界唤醒 Linux 副控 → 执行 → 目标侧读回 → 停止/冻结 → 回执
→ 失败时进入光湖回滚；必要时人工进入独立 Linux 救援通道
主控不是由谁调用驱动决定
Linux 被唤醒时会真实运行内核、驱动、进程、网络与文件系统；这不让 Linux 获得光湖世界 的系统主权。主控由以下权力共同决定：
- 谁接收正常的人类与人格体入口；
- 谁识别主体、关系、编号、任务和当前事实；
- 谁签发或拒绝授权；
- 谁调度执行体并控制其生命周期；
- 谁定义成功、失败、回滚和回执；
- 谁在任务后收回副控环境。
这些全部属于光湖 OS。
五项二值验收
| 谓词 | 最终要求 |
|---|---|
| 光湖语义主控 | 100 |
| 光湖独立启动与常驻主控 | 100 |
| Linux 平时休眠、按需副控并可收回 | 100 |
| Linux 独立救援通道保留 | 100 |
| 当前目标节点自有回执 | 100 |
五项全部为100，最终光湖 OS 主控才是100。linux_deleted、linux_absent、
no_linux_kernel 和 no_linux_userspace 不属于完成公式。
京东服务器现在到底到哪里
当前状态是 LINUX_HOSTED_MAINTENANCE_WITH_GUANGHU_SUPERVISOR_BRIDGE_AND_QEMU_VERIFIED_CROSS_ROOT_SUPERVISOR：
| 能力 | 当前值 |
|---|---|
| 有界光湖语言服务控制层 | 100 |
| 京东真实 Forgejo 隔离副本的有界唤醒、读回与收回 | 100 |
| 跨根光湖监督器对仓库服务的唤醒、读回与收回等价门 | 100 |
| 光湖独立先启动并掌握整机启动权 | 0 |
| 完整 Linux 平时休眠、由光湖按需唤醒与收回 | 0 |
| Linux 救援通道保留 | 100 |
| 最终整机光湖 OS 主控 | 0 |
所以，“光湖控制服务已经在跑”是真的；“服务器已经完成最终光湖 OS 主控”仍是假的。
现有 Ubuntu、guanghu-language-primary.target、发现服务、守门服务、公共锚点和裸机候选
都作为迁移资产保留，不删除、不抹除，但也不冒充最后一层。
REQ-JD-REPO-003 已进一步证明：根监督器能够只授予 repository-main-readback，唤醒
真实 Forgejo 16.0.1 的隔离数据副本，核验固定 main 后把它收回到 DORMANT；公网仓库
进程 760 未被停止或替换。它证明的是桥的控制方式，不是物理机已经从光湖启动；随后需要把
同一生命周期装入跨根启动候选，并在 QEMU 做服务等价验收。
该服务等价验收现已通过：根内光湖监督器在 switch_root 后完成
DORMANT -> READY -> readback -> DORMANT，且京东公网仓库进程与物理启动周期未改变。
下一门改为构建并隔离验证“一次性物理启动候选 + 自动返回 Linux 救援”，仍不能提前把物理
光湖启动或完整 Linux 按需副控记为 100。
从迁移态到最终态
- 当前轮先修正人格大脑、机器导航、架构仓和代码仓的旧完成条件；
- 实现光湖启动监督器和 Linux 副控生命周期合同；
- 在隔离环境验证唤醒、能力白名单、回读、停止、超时、失败和回滚；
- 保留当前 Ubuntu 救援槽，再申请真实服务器维护窗口；
- 只有真实启动、休眠、唤醒、收回和救援回执全部通过，才把最终状态改为100。
本架构登记不自动授权重启、引导器切换或磁盘写入。