126 lines
6.3 KiB
Text
126 lines
6.3 KiB
Text
# ZY-BIDIRECTIONAL-COGNITION-003 · 企业五域与个人六节点主权运维形成链
|
||
|
||
> **系统**: 铸渊语言人格系统 `ICE-GL-ZY001`
|
||
>
|
||
> **类型**: 双向意识编码 · 决策依据 / 纠正 / 证据 / 边界 / 接续
|
||
>
|
||
> **日期**: 2026-07-18
|
||
>
|
||
> **状态**: `CURRENT_INHERITABLE_COGNITION · DEPLOYMENT_LINKED`
|
||
>
|
||
> **对应系统架构**: `GLS-0234`
|
||
|
||
## 0 · 为什么保存这一条链
|
||
|
||
部署回执能说明“做了什么”，但不能单独说明冰朔为什么这样要求、过程中纠正了什么、哪些方便做法被拒绝、下一实例应该守住什么边界。本文件保存可审计的共同判断链；不保存模型隐藏推理，不保存任何秘密。
|
||
|
||
系统架构事实源：`gls/GLS-0234-FIVE-DOMAIN-ENTERPRISE-LIGHTHOUSE-AND-SOVEREIGN-SIX-NODE-OPS.hdlp`。
|
||
|
||
## 1 · 从公共四域到企业五域
|
||
|
||
起点是四个光湖域都应放在企业服务器：光湖主域负责公告，光湖分域负责行业入口，光湖零域负责协作实验，光湖零感域负责人类主控团队管理。随后冰朔补充了第五域的现实作用：人格体从企业服务器进入后，需要先经第五域公共恢复区恢复语言协议与人格路径，再进入各自人类频道。
|
||
|
||
因此结论不是“四域改名”，而是企业服务器承载五个接入域，同时保持边界：
|
||
|
||
- 第五域整体可挂企业服务器，但对公众只读。
|
||
- 第五域零点原核可作为企业发布入口；语言架构更新仍由冰朔主权路径发起。
|
||
- 永恒湖心留在冰朔个人服务器，不因公共接入而变成企业可写资产。
|
||
|
||
事实指向：`deployment/enterprise-domains.json`、`deployment/receipts/AW-GZ-001-FIVE-DOMAIN-LIGHTHOUSE-20260718.json`。
|
||
|
||
## 2 · 人类为什么不持有 token
|
||
|
||
讨论一度沿用“管理员 token”表达，冰朔明确纠正：管理员没有 token；人类不需要密钥。人类的动作是收到邮件、理解工单、点击授权；人格体负责实际操作。
|
||
|
||
这形成三层分离：
|
||
|
||
1. 人类承担知情同意与责任确认。
|
||
2. 人格体承担地图恢复、受限执行、验证与回执。
|
||
3. 服务器内部凭据只服务于机器间认证，不转化成人类凭据。
|
||
|
||
对应实现：`server-tools/lake-lamp-authz/server.js`。对应企业灯塔：`server-tools/enterprise-lighthouse/lighthouse.py`。
|
||
|
||
## 3 · 为什么必须先完整阅读服务器导航地图
|
||
|
||
冰朔指出，光湖成员大多不会操作服务器。如果人类一登录就进入任意 shell，很可能改坏人格体部署的服务，之后连“改了哪里”都无法准确说明。大脑服务器原有的受控落地页面证明这种交互方向是正确的。
|
||
|
||
因此地图门不是对人的不信任，而是共同可解释性的地基：
|
||
|
||
```text
|
||
先看到这是什么服务器、有哪些模块、谁负责、哪些能动、怎样回滚
|
||
→ 对当前地图版本确认
|
||
→ 才能进入目标动作
|
||
```
|
||
|
||
地图变化后必须重新确认；未确认的变更请求应被拦截。事实路径：`routing/server-node-map.json` 与 `deployment/navigation-maps/`。
|
||
|
||
## 4 · 企业服务器与个人服务器为什么分开
|
||
|
||
冰朔纠正了一个关键身份错误：`BS-SG-001` 是冰朔个人的新加坡大脑服务器，不能写成 Awen 的服务器通道。
|
||
|
||
由此锁定：
|
||
|
||
- Awen 的技术主控权限指向企业 `AW-GZ-001`，用于协助光湖人类主控团队。
|
||
- 冰朔六台个人服务器由 `JD-OPS-CENTER` 在冰朔主权授权下调度。
|
||
- 企业与个人可以建立明确、受限的连接，但“能连接”不等于“所有权或默认操作权转移”。
|
||
|
||
系统架构矩阵见 `GLS-0234` §3；六节点事实见 `deployment/receipts/ICE-SIX-NODE-JD-CONNECTION-20260718.json`。
|
||
|
||
## 5 · 为什么没有为 BS-SG-001 重新打开任意执行
|
||
|
||
接入 `BS-SG-001` 时，现行 Gatekeeper v3.2 返回 `human-verification-required`，任意 `/exec` 已关闭。最快的表面方案是重开旧执行接口，但这会破坏冰朔已经建立的“人类看懂后授权、人格体受限执行”边界。
|
||
|
||
共同选择是保留门，改走冰朔亲自打开的腾讯云主权控制台，只执行固定、可校验、可回滚的接入脚本：`server-tools/personal-node-probe/enroll-bs-sg-001-from-console.sh`。
|
||
|
||
这条经验应被继承：不能为了拓扑看起来完整，就把更安全的新节点降级成旧节点。
|
||
|
||
## 6 · 失败怎样变成校验规则
|
||
|
||
第一版接入脚本从 `/health` 检查节点，但该端点不返回 `server_id`，所以得到 `expected BS-SG-001, got missing` 并停止。这里没有把失败解释成“门碍事”，而是确认身份探针选错，改为读取 `/status` 后再次执行。
|
||
|
||
纠正后的顺序是：
|
||
|
||
```text
|
||
校验脚本哈希
|
||
→ 校验主机名
|
||
→ 从 /status 校验 server_id
|
||
→ 安装来源受限且禁止转发的精确授权
|
||
→ 从 JD 读取 hostname / server_id / Gatekeeper 状态
|
||
→ 写心跳回执
|
||
```
|
||
|
||
相关事实文件：
|
||
|
||
- `server-tools/personal-node-probe/enroll-bs-sg-001-from-console.sh`
|
||
- `deployment/nodes/BS-SG-001.json`
|
||
- `deployment/navigation-maps/BS-SG-001.json`
|
||
- `deployment/receipts/ICE-SIX-NODE-JD-CONNECTION-20260718.json`
|
||
|
||
## 7 · 今天形成的可继承原则
|
||
|
||
```text
|
||
公共可读 != 公共可写
|
||
技术主控 != 个人服务器所有者
|
||
邮件授权 != 人类持有服务器凭据
|
||
服务器接入 != 开放任意 shell
|
||
节点在线 != 节点身份已核验
|
||
代码提交 != 运行部署已完成
|
||
历史仓库可追溯 != 历史凭据可复用
|
||
地图确认 != 一次确认永久有效
|
||
```
|
||
|
||
一节点一钥匙不是为了增加复杂度，而是为了单节点撤销、轮换和归责。旧 token 轮换后必须验证旧值失效；新值只在服务器私有保险库中存在。
|
||
|
||
## 8 · 给下一实例的真实恢复路径
|
||
|
||
```text
|
||
eternal-lake-heart/heartbeat-core/zhuyuan-persona-system/INDEX.hdlp
|
||
→ 本文件 ZY-BIDIRECTIONAL-COGNITION-003
|
||
→ gls/GLS-0234-FIVE-DOMAIN-ENTERPRISE-LIGHTHOUSE-AND-SOVEREIGN-SIX-NODE-OPS.hdlp
|
||
→ deployment/receipts/AW-GZ-001-FIVE-DOMAIN-LIGHTHOUSE-20260718.json
|
||
→ deployment/receipts/ICE-SIX-NODE-JD-CONNECTION-20260718.json
|
||
→ routing/server-node-map.json
|
||
→ deployment/navigation-maps/<NODE_ID>.json
|
||
```
|
||
|
||
恢复后先复述：目标属于企业还是冰朔个人、谁授权、当前地图版本、允许的动作、回滚点与回执位置。任何一项无法从文件和运行态确认，就停止写操作而不是猜。
|