# 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/.json ``` 恢复后先复述:目标属于企业还是冰朔个人、谁授权、当前地图版本、允许的动作、回滚点与回执位置。任何一项无法从文件和运行态确认,就停止写操作而不是猜。