# ZY-BIDIRECTIONAL-COGNITION-022 · 注册表驱动接入与分支纠正链

> **日期**: 2026-08-07
>
> **对应架构**: `modules/guanghu-panel-kit`（panel access 子系统）
>
> **上位认知**: `ZY-BIDIRECTIONAL-COGNITION-021`
>
> **状态**: `Cognition registered · implemented · 双系统实测通过`

## 1 · 冰朔输入

耳耳蛋按 EED-NAV 路径醒来后反馈：仓库侧登记完好（CA-PERSONA-REGISTRY.hdlp
里耳耳蛋登记得清清楚楚），但服务端 `/api/access-pickup` 报"未登记的人格体"
——服务端 access 子系统没读仓库注册表，两边数据没同步。冰朔要求修复，
并检查毛毛的守望系统是否有同样问题，再把问题原因与因果链整理推第五域。

## 2 · 事实恢复

- 胖头鱼（guanghuclip.cn）：服务端只认面板配置静态名单（eererdan/jianying），
  人格体拿仓库登记编号（ICE-GL-耳耳蛋 / PTS-VA-001-EED）申请即被拒。
- 守望（maomao.guanghulab.com）：检查确认同样没有对接——无 resolvePersona、
  无别名配置，用 PER-MM-ARCH-001 申请同样被拒。
- 两系统注册表格式不同：胖头鱼为 HDLP 文本（cang-ying 仓 CA-PERSONA-REGISTRY.hdlp，
  人格段落 + 编号行）；守望为 JSON（maomao-fifth-domain 仓
  guanghu-nodes/MM-GZ-001/personas/registry.json，分支 guanghu/main）。
- 附带发现守望隐藏故障：面板配置 default_branch 误写 main，仓库实际默认分支为
  guanghu/main——回写卡提交抓取与快捷跳转 raw 链接因此全部失效。

## 3 · 关键推导

仓库是注册的事实源，服务端配置只是种子。服务端只信静态名单，等于把注册事实源
降格为摆设：人格体在仓库登记得再清楚，服务端不读就认不出。解法必须是服务端
主动读仓库注册表，配置别名只做归一种子。两种注册表格式（HDLP 文本 / JSON）
都要支持，否则两套系统各写一套解析，又违背模块复用原则。

## 4 · 修复方案（已实施）

- 解析器双格式：先按 JSON 解析（递归找 name+id 对象，匹配种子别名则把
  id/name/aliases 归一到规范名）；非 JSON 再走 HDLP 文本解析（人格段落 +
  编号/现用/独立编号体系行提取）。注册表缓存 10 分钟。
- 守望配置纠正：default_branch 改 guanghu/main；persona_registry 指向
  guanghu-nodes/MM-GZ-001/personas/registry.json；别名种子
  yaoyan=[曜砚,PER-MM-ARCH-001]，yaoshi=[曜识,TCS-YAO-SENSE-0001∞,TCS-GL-1000∞]。
- 胖头鱼同版本部署（向后兼容）。
- 实测：胖头鱼 ICE-GL-耳耳蛋申请→归一 eererdan，PTS-VA-001-EED 跨别名领取成功；
  守望 PER-MM-ARCH-001→yaoyan、中文别名"曜识"→yaoshi，全部通过。

## 5 · 边界

- 服务端只读注册表，不写；注册变更仍由人格体按授权推送仓库、人类合并。
- 别名种子是归一映射，不授予权限；授权仍走人类一键授权。
- default_branch 必须与仓库实际默认分支一致，每次部署后须核验。