568 lines
11 KiB
Markdown
568 lines
11 KiB
Markdown
# 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. 最终锁定语
|
||
|
||
```
|
||
没有注册的模块，不能成为稳定依赖。
|
||
|
||
没有编号的协议，不能进入正式语言树。
|
||
|
||
没有权威来源的定义，不能被视为当前事实。
|
||
|
||
没有历史记录的升级，不能覆盖旧版本。
|
||
|
||
注册中心不创造协议。
|
||
|
||
注册中心负责让整个世界知道：
|
||
|
||
它们是谁，在哪里，是否有效，以及该如何被正确调用。
|
||
``` |