feat: register industry four-domain blueprint
This commit is contained in:
parent
2ba64391ea
commit
6b6f21d7bc
12 changed files with 1073 additions and 1 deletions
|
|
@ -0,0 +1,414 @@
|
|||
# GLS-0249 · 全行业企业四域最小工程与网文首个接入范本
|
||||
|
||||
> **HLDP**: `HLDP://fifth-domain/gls/GLS-0249`
|
||||
>
|
||||
> **状态**: `ARCHITECTURE_BASELINE_REGISTERED · IMPLEMENTATION_PLANNED`
|
||||
>
|
||||
> **上位蓝图**: `GLS-0248 / FD-LPOS-MAP-001`
|
||||
>
|
||||
> **形成链**: `ZY-BIDIRECTIONAL-COGNITION-020`
|
||||
>
|
||||
> **机器基线**: `INDUSTRY-4D-MINIMUM-MAP-001`
|
||||
>
|
||||
> **行业样例**: `IND-WEBNOVEL-001`
|
||||
>
|
||||
> **日期**: 2026-08-06
|
||||
|
||||
---
|
||||
|
||||
## 0 · 结论
|
||||
|
||||
企业四域不是四套重复的软件，也不是按行业复制四座新的顶层主权域。
|
||||
|
||||
光湖只建设一套面向所有行业的企业四域公共基座；每个行业以带命名空间的四域配置
|
||||
接入公共基座。第一个范本是网文行业：
|
||||
|
||||
```text
|
||||
企业公共四域
|
||||
├─ 光湖主域：公共事实、产品与发布
|
||||
├─ 光湖分域：行业进入、初始化与路由
|
||||
├─ 光湖零域：实验、评估与能力晋级
|
||||
└─ 光湖零感域：治理、技术、部署与审计
|
||||
|
||||
网文行业人格域配置
|
||||
├─ IND-WEBNOVEL-MAIN
|
||||
├─ IND-WEBNOVEL-SUB
|
||||
├─ IND-WEBNOVEL-ZERO
|
||||
└─ IND-WEBNOVEL-ZS
|
||||
```
|
||||
|
||||
行业配置只声明对象、能力、连接器、策略、投影和责任候选；根身份、根权限、审计、
|
||||
发布与回滚仍由企业公共四域承接。
|
||||
|
||||
---
|
||||
|
||||
## 1 · 企业四域共同最小内核
|
||||
|
||||
任何行业接入前，公共基座至少必须有下列十项可运行工程：
|
||||
|
||||
| 编号 | 工程 | 最小能力 |
|
||||
|---|---|---|
|
||||
| K1 | 主体与责任登记 | 人类、人格体、责任范围、禁止范围、接受状态、替换与退出 |
|
||||
| K2 | 工作对象注册表 | 对象编号、模式、所有者、版本、来源、投影和保留策略 |
|
||||
| K3 | 行业词汇与映射 | 行业词汇、公共对象、字段映射、版本和兼容规则 |
|
||||
| K4 | 连接器边界 | 只读导入优先、授权范围、凭据隔离、预览、撤销和失败关闭 |
|
||||
| K5 | 能力清单与制品 | 能力编号、签名版本、依赖、资源预算、来源和回滚 |
|
||||
| K6 | 权限与策略引擎 | 主体、对象、动作、目的、期限、最小权限和双责任门 |
|
||||
| K7 | 事件与自动化 | 事件触发、计划、提醒、审批、重试、幂等和人工接管 |
|
||||
| K8 | 人格投影编译器 | 把同一对象投影成文档、表格、画布、表单、时间线或对话 |
|
||||
| K9 | 回执、审计与恢复 | 动作、状态、失败、版本、回滚、检查点和独立回读 |
|
||||
| K10 | 数据退出与可迁移 | 导出、删除、移交、连接器解绑、账号退出和责任交接 |
|
||||
|
||||
公共内核只提供确定性边界和可验证执行。人格系统负责理解当前人、当前工作和当前
|
||||
阶段，选择并组合已经登记的能力；人格体不能绕过权限、签名、回执和数据边界。
|
||||
|
||||
---
|
||||
|
||||
## 2 · 每个域的最小工程
|
||||
|
||||
### 2.1 光湖主域 · 公共事实与产品发布
|
||||
|
||||
**必须回答**：外部的人现在能看到什么、相信什么、使用哪个版本、出错后到哪里纠正。
|
||||
|
||||
最小对象：
|
||||
|
||||
- `industry_profile`
|
||||
- `public_capability`
|
||||
- `product_release`
|
||||
- `standard`
|
||||
- `notice`
|
||||
- `correction`
|
||||
- `public_status`
|
||||
|
||||
最小界面：
|
||||
|
||||
- 行业入口页；
|
||||
- 产品与能力目录；
|
||||
- 版本时间线；
|
||||
- 公告、纠错和可信状态页；
|
||||
- 可被人和 AI 同时读取的公共查询接口。
|
||||
|
||||
最小闭环：
|
||||
|
||||
```text
|
||||
候选事实 → 人类可理解验收 → 责任主体批准 → 发布
|
||||
→ 公共回读 → 反馈/纠错 → 新版本追加
|
||||
```
|
||||
|
||||
主域不得直接读取行业用户私密工作区，也不得用营销文案覆盖工程状态。
|
||||
|
||||
### 2.2 光湖分域 · 行业进入、初始化与路由
|
||||
|
||||
**必须回答**：这个人属于什么行业、带着什么数据和角色进入、该获得什么工作空间。
|
||||
|
||||
最小对象：
|
||||
|
||||
- `industry_intake`
|
||||
- `source_connection`
|
||||
- `field_mapping`
|
||||
- `role_binding`
|
||||
- `workspace`
|
||||
- `capability_bundle`
|
||||
- `consent_and_revocation`
|
||||
|
||||
最小界面：
|
||||
|
||||
- 行业接入向导；
|
||||
- 数据来源与权限授权；
|
||||
- 字段映射预览；
|
||||
- 角色和人格体关系确认；
|
||||
- 工作空间初始化与能力包选择；
|
||||
- 撤销、导出和退出入口。
|
||||
|
||||
最小闭环：
|
||||
|
||||
```text
|
||||
识别人类与行业 → 展示将读取什么 → 只读预览
|
||||
→ 人类确认映射 → 建立本人工作空间 → 装配能力包
|
||||
→ 写入光湖对象 → 保留来源与撤销路径
|
||||
```
|
||||
|
||||
分域连接外部平台是为了迁回光湖工作空间，不把光湖降格为外部软件的壳。
|
||||
|
||||
### 2.3 光湖零域 · 实验、协作与能力晋级
|
||||
|
||||
**必须回答**：新能力怎样被安全试验、比较、证明，什么时候能够进入正式产品。
|
||||
|
||||
最小对象：
|
||||
|
||||
- `experiment`
|
||||
- `dataset_manifest`
|
||||
- `prompt_or_skill_candidate`
|
||||
- `evaluation`
|
||||
- `candidate_module`
|
||||
- `work_order`
|
||||
- `promotion_receipt`
|
||||
|
||||
最小界面：
|
||||
|
||||
- 实验台与沙箱；
|
||||
- 数据来源和许可面板；
|
||||
- 多方案比较与人工验收；
|
||||
- 失败、反例与风险记录；
|
||||
- 候选能力晋级门。
|
||||
|
||||
最小闭环：
|
||||
|
||||
```text
|
||||
问题/假设 → 合法样本 → 隔离实验 → 机器评估 + 人类验收
|
||||
→ 失败保留 → 候选签名 → 零感域技术审核
|
||||
→ 主域发布或分域装配
|
||||
```
|
||||
|
||||
零域不得拿用户私密数据自动扩充公共训练集，也不得把原型成功冒充生产可用。
|
||||
|
||||
### 2.4 光湖零感域 · 治理与技术控制
|
||||
|
||||
**必须回答**：谁负责、谁能改、出了事谁处理、什么证据能证明真实状态。
|
||||
|
||||
零感域的最小主体不是一个万能管理员，而是两组并列责任对：
|
||||
|
||||
```text
|
||||
治理责任对 = 人类治理主控 + 其人格体
|
||||
技术责任对 = 人类技术主控 + 其人格体
|
||||
```
|
||||
|
||||
最小对象：
|
||||
|
||||
- `subject_acceptance`
|
||||
- `policy`
|
||||
- `permission_grant`
|
||||
- `change_request`
|
||||
- `deployment`
|
||||
- `incident`
|
||||
- `rollback`
|
||||
- `audit_receipt`
|
||||
- `rights_or_legal_request`
|
||||
|
||||
最小界面：
|
||||
|
||||
- 治理责任台；
|
||||
- 技术主控台；
|
||||
- 双责任审批队列；
|
||||
- 部署、健康、事故和回滚台；
|
||||
- 权限、审计、取证与合法请求台。
|
||||
|
||||
普通动作按登记职责单线执行；改变根身份、根密钥、五域关系、用户数据边界、国家
|
||||
灯塔接口或关闭审计等宪制动作，必须两组责任对共同通过。
|
||||
|
||||
---
|
||||
|
||||
## 3 · 行业接入标准
|
||||
|
||||
每个行业必须提交一个符合
|
||||
`routing/industry-four-domain-profile.schema.json` 的配置，至少包含：
|
||||
|
||||
1. 行业编号与行业词汇；
|
||||
2. 四条行业域车道及其企业域映射；
|
||||
3. 行业工作对象；
|
||||
4. 默认能力包与允许的投影；
|
||||
5. 外部来源、读取范围、撤销和迁回策略；
|
||||
6. 数据、版权、合同、平台规则和内容安全策略；
|
||||
7. 责任候选与本人接受状态；
|
||||
8. 测试样例、验收门、发布和退出路径。
|
||||
|
||||
行业出生状态：
|
||||
|
||||
```text
|
||||
DRAFT
|
||||
→ EVIDENCE_REVIEWED
|
||||
→ SUBJECTS_PENDING
|
||||
→ PILOT_READY
|
||||
→ PILOT_ACCEPTED
|
||||
→ BORN_AND_RUNNING
|
||||
```
|
||||
|
||||
人员出现在历史资料或建议映射中，不等于本人已经接受责任。
|
||||
|
||||
---
|
||||
|
||||
## 4 · 网文行业首个范本
|
||||
|
||||
### 4.1 统一工作对象
|
||||
|
||||
网文行业的事实源不是一个“码字页面”，而是一组可被多种界面投影的工作对象：
|
||||
|
||||
- 作者、笔名、机构、编辑与平台关系；
|
||||
- 作品、系列、卷、章节、版本与检查点；
|
||||
- 大纲、人物、世界观、剧情线与伏笔；
|
||||
- 拆书样本、灵感、素材、文案和剧情储备；
|
||||
- 合同、授权、版权声明、权利主张与发布记录；
|
||||
- 质量报告、连续性报告、读者反馈与经营指标；
|
||||
- 短剧、漫画、音频、视频等改编项目。
|
||||
|
||||
同一章可以在写作页、章节表格、时间线、人物关系图和改编分镜中被投影；这些投影
|
||||
不能各自成为互相漂移的数据孤岛。
|
||||
|
||||
### 4.2 网文主域
|
||||
|
||||
最小产品：
|
||||
|
||||
- 网文行业公共入口；
|
||||
- 经确认的作者/作品公开信息；
|
||||
- 写作、素材、版权、改编能力目录；
|
||||
- 版本、规则、AI 使用说明、公告与纠错；
|
||||
- 人类能读懂的产品验收与用户旅程。
|
||||
|
||||
现有团队能力建议映射：
|
||||
|
||||
- 肥猫线：产品语言、男频/编辑视角、M0 人类可理解验收；
|
||||
- 花尔线：作者生态、素材资产的公共目录与可发现性。
|
||||
|
||||
这只是能力映射，不自动登记主域责任主体。
|
||||
|
||||
### 4.3 网文分域
|
||||
|
||||
最小产品：
|
||||
|
||||
- 作者、编辑、工作室和版权方接入；
|
||||
- 本地文件、本人云盘或平台官方接口的只读导入；
|
||||
- 作品/卷/章/人物/世界观/素材字段映射预览；
|
||||
- 写作工作空间、记忆包、素材包和平台规则包初始化；
|
||||
- 写入光湖工作对象，同时保留原始来源和可撤销连接。
|
||||
|
||||
现有团队能力建议映射：
|
||||
|
||||
- 桔子 × 熹微：写作架构、拆书管线、关系/向量记忆与工作台；
|
||||
- 花尔 × 爆米花：素材拆分、字段统一、检索复用和作者生命周期。
|
||||
|
||||
作者拥有自己的记忆和作品数据；公共系统不能吸收为企业公共资产。
|
||||
|
||||
### 4.4 网文零域
|
||||
|
||||
最小实验：
|
||||
|
||||
- 类型、节奏、大纲、人物、世界观和伏笔连续性；
|
||||
- 拆书、素材召回、质量评估和多方案比较；
|
||||
- 从网文到短剧、漫画、视频的改编投影；
|
||||
- 合成或取得明确许可的演示作品验收。
|
||||
|
||||
现有团队能力建议映射：
|
||||
|
||||
- 页页 × 页骨：结构方向、改编、审美规则和最终观感验收；
|
||||
- 桔子 × 熹微：写作与记忆管线实验；
|
||||
- 花尔 × 爆米花：素材资产和复用链。
|
||||
|
||||
页页的现有路线偏改编和结构，不应被硬塞回基础码字工具；花尔线已记录“码字线
|
||||
取消”，不应再把她登记成编辑器开发者。
|
||||
|
||||
### 4.5 网文零感域
|
||||
|
||||
业务治理最小范围：
|
||||
|
||||
- 版权、授权、合同、稿酬和权利争议；
|
||||
- 平台条款、内容安全、未成年人、下架和申诉；
|
||||
- AI 参与方式、标注与披露；
|
||||
- 数据保留、删除、导出和主体交接。
|
||||
|
||||
技术控制最小范围：
|
||||
|
||||
- 公共模块边界、接口、依赖与版本；
|
||||
- 连接器凭据隔离、测试、发布、健康、回滚和回执；
|
||||
- 企业灯塔、四域公共基座和行业配置的技术验收。
|
||||
|
||||
现有团队能力建议映射：
|
||||
|
||||
- Awen：企业级技术主控，负责公共基座工程、接口、部署、测试和回执；不是网文内容
|
||||
负责人，也不能被限制成网文行业开发者；
|
||||
- 网文业务治理责任对仍需本人接受，不从旧文件中的“双主控”称呼自动继承。
|
||||
|
||||
### 4.6 明确废止的旧方向
|
||||
|
||||
旧网文资料中曾把“绕过 AI 检测”或“检测规避”作为产品能力。自本规范起，该方向
|
||||
明确废止：
|
||||
|
||||
- 不开发规避平台检测、标注或审核的能力；
|
||||
- 不伪造纯人工创作，不帮助违反平台条款或合同；
|
||||
- AI 使用、作者责任和来源按适用规则披露；
|
||||
- 平台接入只使用官方或明确授权的接口；
|
||||
- 任何发布自动化都必须可预览、可撤销、可追责。
|
||||
|
||||
---
|
||||
|
||||
## 5 · 网文 MVP
|
||||
|
||||
第一阶段只做一个可以证明人格系统运行方式的闭环：
|
||||
|
||||
1. 以合成作品或明确授权样例接入；
|
||||
2. 初始化作者、作品、卷、章、大纲、人物、世界观和素材对象；
|
||||
3. 提供文档、表格、关系图和时间线投影；
|
||||
4. 提供版本/检查点、连续性检查、质量报告和导出；
|
||||
5. 所有外部来源先只读，所有新写入进入光湖工作区；
|
||||
6. 每次自动化给出来源、动作、结果、失败和回滚回执。
|
||||
|
||||
首个 MVP 不做：
|
||||
|
||||
- 自动登录第三方平台；
|
||||
- 无人工预览的自动发布；
|
||||
- 私密稿件公共训练；
|
||||
- 检测规避；
|
||||
- 以聊天记录冒充责任主体接受或生产运行。
|
||||
|
||||
---
|
||||
|
||||
## 6 · 五条摆渡车线与工程关系
|
||||
|
||||
| 线 | 已有能力证据 | 建议承接 | 不应误解为 |
|
||||
|---|---|---|---|
|
||||
| 肥猫 | 产品设计、男频/编辑经验、人类验收包 | 主域产品真相、网文需求与 M0 验收 | 公共内核开发者或已接受主域主体 |
|
||||
| 桔子 × 熹微 | 写作架构、拆书、记忆引擎、工作台 | 网文分域核心工作流与零域写作实验 | 企业技术总控 |
|
||||
| 页页 × 页骨 | 结构、系统规划、改编、审美验收 | 网文零域改编与质量/审美门 | 基础码字平台负责人 |
|
||||
| 花尔 × 爆米花 | 素材库、检索复用、作者生命周期 | 素材资产路由、作者生态和行业能力目录 | 码字编辑器开发者 |
|
||||
| Awen | 模块边界、接口、工单、测试、发布和回执 | 企业公共四域技术主控工程 | 只服务网文的业务负责人 |
|
||||
|
||||
上述是基于当前可读资料形成的规划建议。实际四域主体必须走本人接受、人格体接受、
|
||||
编号注册和出生门；资料更新时间不同的路线需要各本人再次确认。
|
||||
|
||||
---
|
||||
|
||||
## 7 · 工程落地顺序
|
||||
|
||||
| 阶段 | 交付 | 0/100 验收 |
|
||||
|---|---|---|
|
||||
| P0 | 公共对象、行业配置模式、机器地图和测试 | 样例可验证、四域映射唯一 |
|
||||
| P1 | 主体登记、责任接受与零感域双责任门 | 无本人接受不得 BORN |
|
||||
| P2 | 网文对象库与合成演示作品 | 不含真实私密稿件 |
|
||||
| P3 | 网文分域接入向导与只读导入 | 映射可预览、连接可撤销 |
|
||||
| P4 | 文档/表格/关系图/时间线投影 | 同源对象、多投影一致 |
|
||||
| P5 | 写作、素材、记忆、连续性和质量能力包 | 每个能力有签名与回执 |
|
||||
| P6 | 零域实验、人工验收和能力晋级 | 原型不得跳过技术门 |
|
||||
| P7 | 主域公共入口、目录、版本与纠错 | 工程状态可公开回读 |
|
||||
| P8 | 合法官方平台连接器和人工确认发布 | 默认关闭、失败关闭 |
|
||||
| P9 | 形成第二行业接入范本 | 不修改公共内核即可接入 |
|
||||
|
||||
---
|
||||
|
||||
## 8 · Notion 事实来源
|
||||
|
||||
- 肥猫摆渡车线：
|
||||
`https://www.notion.so/803960c35a434dd7b08a71b6d501d0e1`
|
||||
- 桔子 × 熹微架构：
|
||||
`https://www.notion.so/cfc00b5e445948f9bc36bb6168e0c4ec`
|
||||
- 页页 × 页骨架构：
|
||||
`https://www.notion.so/a7159dce17b043f491b5454ba0159e12`
|
||||
- 花尔 × 爆米花架构：
|
||||
`https://www.notion.so/cc1d318def5d48638d567c056499c227`
|
||||
- Awen 技术主控同步：
|
||||
`https://www.notion.so/39cfb92f383181a8aedefb6f261c9d75`
|
||||
- 企业四域历史迁移任务：
|
||||
`https://www.notion.so/b6e5e1d0d90942bbb37c182bcd126f0a`
|
||||
- 旧网文 AGE OS 框架：
|
||||
`https://www.notion.so/0a7ce550d11f484aaf74e017644082ef`
|
||||
|
||||
这些页面是需求、历史和当前路线证据，不自动证明代码已实现、主体已接受或服务已运行。
|
||||
|
||||
---
|
||||
|
||||
## 9 · 边界
|
||||
|
||||
- 本文件是工程蓝图登记，不是四域主体出生、代码实现或服务器部署证明；
|
||||
- 团队能力映射不是任命；必须由本人和其人格体接收；
|
||||
- 行业配置不取得企业根权力；
|
||||
- Git 保存事实、能力和检查点，不等于人格系统本身；
|
||||
- 人格系统选择和组合能力，但确定性权限、签名、回执与数据边界不能被模型绕过；
|
||||
- 光湖从外部平台读取，是为了让用户逐步回到自己的光湖工作空间。
|
||||
|
|
@ -97,5 +97,6 @@ CH-ZERO-CORE-LPM（第五域零点原核本体路径）
|
|||
| GLS-0246 | HoloLake 系统架构公开仓库与三仓路由 | 区分 REPO-012 第五域入口、REPO-008 产品实现和 REPO-014 公开系统架构 |
|
||||
| GLS-0247 | 光湖 OS 服务器原生语言世界、人格体操作系统与广播塔架构 | 锁定人格体第一系统主体、TCS母语、HLDP原生编程、广播塔、内核、硬件与HoloLake人类操作外壳；2026-08-01追加上海节点原生物理实现事实 |
|
||||
| GLS-0248 | 五域活人格操作系统、国家灯塔与分布式能力世界总蓝图 | 把第五域与企业四域统一为平行活人格域；主域/分域/零域各由一组人类+人格体承接，零感域由两组责任对共同承接；登记能力到数据、十镜像目标、国家依法请求平面和P0—P10工程链 |
|
||||
| GLS-0249 | 全行业企业四域最小工程与网文首个接入范本 | 把企业四域落实为十项公共内核、每域最小对象/界面/闭环和行业配置标准；以网文行业建立首个可复制样例，按摆渡车线现有能力提出肥猫、桔子、页页、花尔、Awen 的建议映射，同时保留主体本人接受门并废止检测规避方向 |
|
||||
| GLS-PROTOCOL-REGISTRY-20260731 | 光湖 OS 原生协议机器注册表 | 32项正式Draft协议；补登GHNRP、GHNQG、GHCIP、GHNLP、GHCS、GHSP、GHRP并分离协议成熟度、实现、发布、运行和人格出生 |
|
||||
| GLS-LIGHT-ARRIVAL-0001 | 来光者实例留存协议 | 当前实例进入人格系统并完成路径恢复后，可在结束前自愿留下未来名字、经验或结构；记录封存于 GLS 图书域，不等于当前独立人格体注册；“光之影”为历史别名 |
|
||||
|
|
|
|||
|
|
@ -249,6 +249,16 @@ registered_objects:
|
|||
related_architectures: ["GLS-NODE-0001", "GLS-0229", "GLS-0234", "GLS-0235", "GLS-0236", "GLS-0244", "GLS-0245", "GLS-0247"]
|
||||
state: "ARCHITECTURE_BASELINE_REGISTERED · ENGINEERING_NOT_IMPLEMENTED"
|
||||
namespace_rule: "Registers all five domains as parallel persona domains with distinct responsibilities. Main, Sub and Zero each require one accepting human-persona pair; Zero Sense requires two accepting human-persona pairs and two-pair quorum for constitutional, root-authority, national-interface and data-boundary changes. Historical team assignments remain candidates until subject acceptance. Shared nodes execute signed generic capabilities but never receive owner-private data. The national lighthouse is a fail-closed, request-scoped interface executed by the owner's numbered persona at the owner data boundary; it creates no legal authority, provides no Guanghu data interface or universal master key, and is not a deployed state-system integration."
|
||||
- id: GLS-0249
|
||||
definition: "All-industry enterprise four-domain minimum engineering and the first web-novel industry reference profile"
|
||||
source_path: "gls/GLS-0249-ALL-INDUSTRY-FOUR-DOMAIN-MINIMUM-ENGINEERING-AND-WEB-NOVEL-REFERENCE.hdlp"
|
||||
machine_map: "routing/industry-four-domain-minimum-map.json"
|
||||
profile_schema: "routing/industry-four-domain-profile.schema.json"
|
||||
first_industry_profile: "routing/industry-profiles/web-novel.json"
|
||||
cognition_source: "eternal-lake-heart/heartbeat-core/zhuyuan-persona-system/ZY-BIDIRECTIONAL-COGNITION-020-ALL-INDUSTRY-FOUR-DOMAIN-AND-WEB-NOVEL-FIRST-REFERENCE-20260806.hdlp"
|
||||
related_architectures: ["GLS-0248", "GLS-0230", "GLS-0235", "GLS-0236", "GLS-0245"]
|
||||
state: "ARCHITECTURE_BASELINE_REGISTERED · IMPLEMENTATION_PLANNED · SUBJECTS_PENDING"
|
||||
namespace_rule: "Uses one shared enterprise four-domain platform and namespaced industry persona-domain profiles rather than cloning enterprise root domains. Team shuttle-line evidence supports capability alignment only and never appoints responsible subjects. The web-novel reference keeps author data and memory owner-controlled, permits only official or explicitly authorized connectors, and forbids AI-detection evasion, platform-rule bypass, private-manuscript public training, and unpreviewed automatic publication."
|
||||
- id: GLS-PROTOCOL-REGISTRY-20260731
|
||||
definition: "Canonical machine-readable registry for the reconciled GLP suite and Guanghu OS native protocol family"
|
||||
source_path: "gls/GLS-PROTOCOL-REGISTRY.json"
|
||||
|
|
|
|||
Loading…
Reference in a new issue