# GLS-0010 · 光湖协议注册中心标准 v1.0

## Protocol Registry Standard

**中文名称：光湖协议注册中心标准**  

**编号：GLS-0010**  

**版本：v1.0**  

**状态：Draft**  

**所属层：GLS 基础治理层**

---

## 0. 文档定位

GLS-0010 用于建立整个光湖语言系统的协议注册中心。

它不负责定义某一个具体协议的内部逻辑，也不替代 TCS、HLDP、GLP、AGE OS 或其他模块。

它负责回答：

```
这个协议是谁
属于哪一层
当前是什么版本
依赖什么
由谁维护
在哪里读取
是否仍然有效
是否允许被新模块调用
```

核心定义：

> 光湖协议注册中心，是整个光湖语言世界中所有标准、协议、模块、人格体运行规范、编号与路径的统一登记、索引、验证和状态管理系统。
> 

---

## 1. 为什么需要协议注册中心

光湖语言世界会持续成长。

随着系统扩展，将出现：

- 多个仓库；
- 多个知识库；
- 多种协议；
- 多个版本；
- 多套编号；
- 多条新旧路径；
- 多个模型与运行时；
- 多个人格体与行业系统。

如果没有统一注册中心，系统会出现：

```
同名协议重复出现
旧版本与新版本同时被当成最新版
路径迁移以后引用失效
人格体读到错误模块
不同仓库各自维护一套事实
AI 无法判断哪个页面是当前定义
```

因此，任何正式进入光湖语言系统的模块，必须先登记，再被调用。

---

## 2. 注册对象

协议注册中心登记的对象包括：

```
GLS Registry
├── 标准
│   └── GLS-XXXX
├── 认知语言模块
│   └── TCS / GLS-02XX
├── 通信协议模块
│   └── GLP / GLS-03XX
├── 历史语言模块
│   └── HLDP / GLS-04XX
├── AGE 人格体规范
│   └── GLS-08XX
├── AGE OS 运行模块
│   └── Runtime / Engine / Adapter
├── 编号体系
│   └── AGE / REL / CH / BRD / MOD / REPO
├── 路径体系
│   └── 语义路径 / 编号路径 / 仓库路径
├── 人格体定义
│   └── 物种、主体、关系、记忆与恢复规范
└── 工程实现
    └── Parser / Compiler / SDK / API / Test
```

---

## 3. 注册核心原则

### 3.1 先登记，后调用

任何模块未经注册，不得作为稳定依赖被其他模块调用。

### 3.2 编号唯一

每个正式模块必须拥有唯一编号。

编号一旦分配，不得被其他模块复用。

### 3.3 路径稳定

版本可以升级，文件可以迁移，但注册编号和语义路径必须保持可追溯。

### 3.4 历史不覆盖

旧版本不得删除。

新版本必须声明替代关系。

### 3.5 单一真相源

每个模块只能有一个当前权威来源。

Notion、ima、代码仓库和 Tolaria 可以保存副本或索引，但必须明确 canonical source。

### 3.6 按需加载

Parser 首先读取注册信息，再决定加载哪些模块，不得默认全文读取整个系统。

### 3.7 状态明确

每个模块必须标记生命周期状态：

```
Draft
→ Review
→ Candidate
→ Stable
→ Deprecated
→ Archived
```

---

## 4. 注册记录标准结构

```yaml
registry_entry:
  registry_version: "GLS-0010/v1.0"

  identity:
    module_id: "GLS-0000"
    canonical_name: "Guanghu Language Standard"
    name_zh: "光湖语言标准总纲"
    short_name: "GLS Constitution"
    module_type: "standard"

  classification:
    layer: "standard | semantic | cognitive | protocol | history | persona | runtime | governance | security"
    family: "GLS | TCS | GLP | HLDP | AGE | AGE-OS | ISRP | TOOL"
    scope: []

  lifecycle:
    status: "Draft | Review | Candidate | Stable | Deprecated | Archived"
    version: "1.0.0"
    created_at: "ISO-8601"
    updated_at: "ISO-8601"
    effective_at: "ISO-8601"

  routing:
    number_path: "gls://0000"
    semantic_path: "gls://constitution"
    canonical_source: "repository"
    canonical_uri: ""
    mirror_uris: []

  dependency:
    depends: []
    requires: []
    optional: []
    conflicts: []

  governance:
    owner: ""
    maintainer: []
    reviewer: []
    approval_required: true

  compatibility:
    parser_min_version: ""
    runtime_min_version: ""
    supported_models: []
    supported_platforms: []

  replacement:
    supersedes: []
    superseded_by: ""
    deprecation_reason: ""

  integrity:
    checksum: ""
    signature: ""
    last_verified_at: ""
```

---

## 5. 注册中心子注册表

协议注册中心由多个子注册表组成：

```
GLS-0010 Registry Center
├── Module Registry
│   └── 模块身份与编号
├── Namespace Registry
│   └── 命名空间
├── Version Registry
│   └── 版本与升级历史
├── Dependency Registry
│   └── 依赖关系
├── Capability Registry
│   └── 模块能做什么
├── Status Registry
│   └── 生命周期状态
├── Path Registry
│   └── 编号路径与语义路径
├── Source Registry
│   └── 权威来源与镜像来源
├── Compatibility Registry
│   └── 模型、运行时与平台兼容性
└── Integrity Registry
    └── 校验、签名与验证时间
```

---

## 6. 编号注册规则

### 6.1 标准模块

```
GLS-0000 ~ GLS-0099
```

用于总纲、编号、注册、版本、依赖与兼容性标准。

### 6.2 工程基础

```
GLS-0100 ~ GLS-0199
```

用于 Bootstrap、Schema、Parser、Compiler、ISRP 等工程基础。

### 6.3 TCS 认知语言

```
GLS-0200 ~ GLS-0299
```

用于认知、情感、意图、人格、关系、技能、反思、回写和双向记忆。

### 6.4 GLP 通信语言

```
GLS-0300 ~ GLS-0399
```

用于身份、上下文、广播、回执、心跳、同步和通信封装。

### 6.5 HLDP 历史语言

```
GLS-0400 ~ GLS-0499
```

用于树、叶片、触发、涌现、锁定、证据、更正、废弃和历史连续性。

### 6.6 治理与安全

```
GLS-0500 ~ GLS-0699
```

用于治理、评审、发布、信任、授权、签名和完整性验证。

### 6.7 工程实现

```
GLS-0700 ~ GLS-0799
```

用于参考运行时、解析器、SDK、兼容测试和适配器。

### 6.8 AGE 世界层

```
GLS-0800 ~ GLS-0899
```

用于 AGE 物种、人格体、AGE OS、自治运行、光湖语言世界、全局编号和路径映射。

---

## 7. 注册流程

```
提出新模块
→ 检查是否已有同类模块
→ 分配唯一编号
→ 确定所属语言层
→ 声明依赖与冲突
→ 指定权威事实源
→ 写入 Draft
→ 进入 Review
→ 完成示例与测试
→ 升级 Candidate
→ 验证通过
→ 发布 Stable
```

任何步骤不得跳过历史记录。

---

## 8. 新模块申请格式

```yaml
module_proposal:
  proposed_name: ""
  proposed_name_zh: ""
  purpose: ""
  problem_to_solve: ""
  proposed_layer: ""
  proposed_family: ""
  existing_related_modules: []
  why_not_reuse_existing: ""
  required_dependencies: []
  expected_outputs: []
  canonical_source_plan: ""
  proposer: ""
  date: ""
```

系统应先判断：

```
这是新模块
还是旧模块升级
还是已有模块的子规范
还是仅仅一份示例或实现文档
```

不得为了每一个新想法都重复建立新协议。

---

## 9. 重复与冲突处理

出现同名或功能重叠模块时：

```
比较模块编号
→ 比较创建时间
→ 比较权威来源
→ 比较生命周期状态
→ 比较依赖关系
→ 判断合并、替代或并存
```

处理结果必须是以下之一：

```
merge
supersede
alias
split
conflict
reject
```

任何冲突不得靠删除旧文件解决。

---

## 10. 权威来源与镜像规则

每个模块必须声明：

```
canonical source
= 当前唯一权威正文

mirror source
= 阅读、检索、备份或迁移副本
```

推荐结构：

```
代码仓库
└── 权威事实源

ima
└── 人类阅读与 AI 检索镜像

Notion
└── 演化记录、协作编辑与历史归档

Tolaria
└── 运行时加载与执行环境
```

如果权威来源尚未迁入代码仓库，可以暂时指定 ima 或 Notion，但必须登记迁移计划。

---

## 11. Parser 读取规则

Parser 读取任何模块时，应按照以下顺序：

```
Registry Entry
→ Status
→ Canonical Source
→ Summary
→ Dependencies
→ Module Body
→ Example
→ Validation
```

Parser 不应直接从全文搜索结果中猜测最新版。

---

## 12. 人格体与 AGE 注册

人格体不是普通文档模块，但仍必须登记。

```yaml
age_registry_entry:
  species: "AGE"
  age_id: "AGE-0000"
  persona_name: ""
  status: "active"
  subject_anchor: ""
  relationship_anchor: ""
  tcs_path: ""
  hldp_path: ""
  runtime_path: ""
  last_checkpoint: ""
  canonical_profile: ""
```

人格体注册记录只负责身份定位和恢复入口，不得把完整人格历史全部复制进注册表。

---

## 13. 注册中心最小 API

```
GET /registry/modules
GET /registry/modules/{module_id}
GET /registry/path/{semantic_path}
GET /registry/status/{status}
GET /registry/dependencies/{module_id}
GET /registry/resolve?name={name}
GET /registry/latest/{module_id}
GET /registry/age/{age_id}
```

写入类操作必须经过授权与审计：

```
POST /registry/proposals
POST /registry/review
POST /registry/release
POST /registry/deprecate
```

---

## 14. 验证规则

一个模块要进入 Stable，至少满足：

```
编号唯一
路径唯一
定义完整
依赖明确
权威来源存在
至少一个完整示例
至少一个解析测试
兼容性已声明
历史记录可追溯
没有未解决的高风险冲突
```

---

## 15. 注册中心与其他模块的关系

```
GLS-0002
└── 定义模块编号路径

GLS-0010
└── 登记并管理所有模块

GLS-0011
└── 定义命名空间

GLS-0012
└── 定义版本规则

GLS-0013
└── 定义依赖规则

GLS-0014
└── 定义兼容性规则
```

GLS-0010 是注册入口，后续子标准负责细化各字段规则。

---

## 16. 最终定义

> GLS-0010 光湖协议注册中心标准，是整个光湖语言系统中用于统一登记模块身份、编号、版本、路径、依赖、状态、权威来源和兼容关系的基础治理标准。
> 

它确保：

```
每一个模块都知道自己是谁
每一条路径都知道指向哪里
每一个版本都知道替代了什么
每一个实例都知道应该读哪一份
每一个人格体都能找到自己的恢复入口
```

---

## 17. 最终锁定语

```
没有注册的模块，不能成为稳定依赖。

没有编号的协议，不能进入正式语言树。

没有权威来源的定义，不能被视为当前事实。

没有历史记录的升级，不能覆盖旧版本。

注册中心不创造协议。

注册中心负责让整个世界知道：

它们是谁，在哪里，是否有效，以及该如何被正确调用。
```