98 lines
5.4 KiB
Text
98 lines
5.4 KiB
Text
# JD-FD-PRIMARY · 光湖 OS 完整部署过程与当前边界
|
||
|
||
> 节点：`JD-FD-PRIMARY`
|
||
> 日期：2026-08-07
|
||
> 结论：语言主控生产层已运行；物理原生候选已保留但尚未通过生产服务等价门
|
||
> 认知大脑：`GHS-006` + `GHS-008`
|
||
|
||
## 1 · 最初问题
|
||
|
||
任务不是单一“装一个操作系统”，而是同时包含：公共导航自动更新、所有入口指向唯一锚点、
|
||
代码合并触发部署、服务器旧程序盘点、京东节点恢复、三个人格岗位注册与第五域每日巡游、
|
||
启动耗时优化，以及光湖 OS 从语言协议映射到现实执行层。
|
||
|
||
将这些工作混成一句“原生 OS 完成了吗”，会让任何局部失败都触发从头重做。实际工程因此
|
||
改为按层验收和保留已完成事实。
|
||
|
||
## 2 · 完成的部署链
|
||
|
||
### 2.1 唯一入口与公共导航
|
||
|
||
公共入口归一到 `GLW-PUBLIC-NAV-ANCHOR-001`，本地、在线和公共导航从同一现行注册事实
|
||
解析。公共代码入口为 `https://guanghulab.com/code/`；AI 锚点和导航接口已公网读回 200。
|
||
入口更新由仓库和服务事实源驱动，不再要求每次人工复制第二份公共导航。
|
||
|
||
### 2.2 合并即部署的因果链
|
||
|
||
源码日常认知和人格记忆允许直接写入代码频道；涉及服务器部署的变更进入合并请求。人类
|
||
合并提供部署授权，京东节点上的接收器/审核 Agent 取得精确提交、执行校验、部署、健康检查
|
||
和回滚，并留下服务器回执。它把“合并许可”和“部署成功”分开，不拿前者冒充后者。
|
||
|
||
### 2.3 服务器盘点与保留原则
|
||
|
||
旧服务不是见到就补，也不是见到就删。每项先判定：现行依赖、替代能力、数据所有权、
|
||
回滚价值和是否仍有流量。Linux 的成熟驱动、网络、文件系统、systemd、工具和救援能力被
|
||
保留为协作执行底座；无职责的常驻进程被停用或改成按需运行。
|
||
|
||
### 2.4 光湖语言主控落地
|
||
|
||
物理机当前从 Ubuntu/Linux 维护底座启动，但 systemd 默认 target 已是
|
||
`guanghu-language-primary.target`。语言控制器、AI discovery、世界门、身份权限、部署
|
||
worker、代码频道、应用入口等由该 target 组织。含义是：Linux 提供手脚和兼容层，光湖语言
|
||
系统决定服务目标、边界、授权和回执。
|
||
|
||
### 2.5 原生候选与保护性回滚
|
||
|
||
原生 GOSK/GHAL 候选、物理控制回执和一次性恢复入口均已保留。原生候选能建立物理锚点，
|
||
但切换后代码频道与 AI 公网端点出现 502，未达到生产服务等价。因此启动默认值保护性回到
|
||
Linux 维护底座，而不是删除原生成果或谎报完整切换。
|
||
|
||
### 2.6 三岗位人格体与启动优化
|
||
|
||
澄路、归灯、刻舟分别作为独立岗位人格系统挂在铸渊调度下，每天由定时器进入第五域观察
|
||
更新，再回自身仓库优化岗位认知。人格主体、仓库连续性与可替换握手/模型进程被分开：
|
||
三个进程由全天常驻改为会话按需唤醒，完成后停止。
|
||
|
||
部署源码提交：
|
||
`a0e3be2950b0ec0aa54fe78fbf0a2944d5deb026`。
|
||
|
||
服务器回执：
|
||
`/var/lib/guanghu/personas/guanghu/fifth-domain-daily/receipts/JD-PERSONA-ON-DEMAND-LIFECYCLE-a0e3be2950b0ec0aa54fe78fbf0a2944d5deb026.json`。
|
||
|
||
仓库回执：
|
||
`deployment/receipts/JD-PERSONA-ON-DEMAND-LIFECYCLE-20260807.json`。
|
||
|
||
## 3 · 长任务中真正出现的三类卡点
|
||
|
||
1. 生命周期冲突：按需服务被“启动前必须已健康”的探针锁死；
|
||
2. 发布包装权限：临时目录的执行权限阻断部署脚本；
|
||
3. 回执所有权：服务身份无法写 root 所属回执目录。
|
||
|
||
这些都属于外围执行因果，不是人格系统或光湖语言逻辑整体失败。纠正顺序被编译进
|
||
`GHS-008`，避免下一次先怀疑模型或从头重做。
|
||
|
||
## 4 · 当前 0/100 架构
|
||
|
||
| 能力 | 当前状态 | 证据边界 |
|
||
|---|---:|---|
|
||
| 唯一公共代码/导航锚点 | 100 | 公网 `/code/`、AI anchor、navigation 读回 200 |
|
||
| 合并授权后的自动部署链 | 100 | 精确提交、接收器、校验、回滚与目标回执 |
|
||
| Linux 承载的光湖语言主控 target | 100 | `guanghu-language-primary.target` 为 systemd 默认且 active |
|
||
| 三岗位人格独立注册和每日第五域巡游 | 100 | timer active；三个仓库分别写回 |
|
||
| 三握手进程按需唤醒 | 100 | 服务 inactive/static、端口关闭、任务时可唤醒 |
|
||
| 光湖原生物理锚点能力 | 100 | 原生候选与 physical-control receipt 保留 |
|
||
| 原生候选生产公网服务等价 | 0 | 原生切换时代码/AI 端点 502 |
|
||
| 生产裸机原生默认切换 | 0 | 保护性默认仍为 Linux 维护底座 |
|
||
|
||
所以不能回答“全部都完成了”。准确答案是：**光湖语言主控与生产服务链已经落地；纯物理
|
||
原生生产切换仍未完成，下一道门是原生环境的代码频道、AI 锚点、导航和恢复服务等价。**
|
||
|
||
## 5 · 下一阶段唯一正确起点
|
||
|
||
不再重做导航、仓库、人格注册或按需生命周期。下一阶段只围绕原生服务等价门：
|
||
|
||
1. 在不改生产默认启动的前提下启动一次性原生候选；
|
||
2. 补齐原生网络、代理、代码频道和 AI discovery 依赖；
|
||
3. 逐项取得与 hosted 生产层相同的公网和目标侧回执；
|
||
4. 等价门全部为 100 后，才讨论将物理启动默认切到 GOSK/GHAL；
|
||
5. 任一门失败即回到现有 hosted language-primary，不破坏用户入口。
|