2026-08-17 16:36:25 +08:00
|
|
|
|
# GLS 原生协议运行层实施规划
|
|
|
|
|
|
|
2026-08-17 17:56:47 +08:00
|
|
|
|
状态:`P0_TO_P7_DESKTOP_PRODUCT_KERNEL_IMPLEMENTED · INSTALLED_RUNTIME_ACCEPTANCE_PENDING`
|
2026-08-17 16:36:25 +08:00
|
|
|
|
|
|
|
|
|
|
核验时间:2026-08-17(Asia/Shanghai)
|
|
|
|
|
|
|
|
|
|
|
|
线上事实源:
|
|
|
|
|
|
|
|
|
|
|
|
- 第五域代码频道:`bingshuo/guanghu-ice-heart`
|
2026-08-19 00:54:07 +08:00
|
|
|
|
- REPO-012 `main`:`d5b1111fcaccaccf025070e531631f2b3cbb00cd`
|
2026-08-17 16:36:25 +08:00
|
|
|
|
- Git tree:`5a09f084fffee56d90599e69038c8335871ea04f`
|
|
|
|
|
|
- 第五域节点:`JD-FD-PRIMARY`
|
|
|
|
|
|
- 公开远端 HEAD 与第五域 Forgejo 裸仓库 HEAD:一致
|
|
|
|
|
|
- 本规划只描述产品工程路线;协议登记、源码实现、构建制品、发布、部署、激活和健康分别验收
|
|
|
|
|
|
|
|
|
|
|
|
## 1. 线上注册事实
|
|
|
|
|
|
|
|
|
|
|
|
`gls/GLS-PROTOCOL-REGISTRY.json` 当前登记:
|
|
|
|
|
|
|
|
|
|
|
|
- `existing_registered`:19
|
|
|
|
|
|
- `registered_draft_protocols`:33
|
|
|
|
|
|
- 33 份草案中 `implementation: NOT_STARTED`:21
|
|
|
|
|
|
- 其余 12 份带实现证据,但证据多属于 BS-SH-005 的特定物理实验能力,不能直接推定 HoloLake 客户端或 JD-FD-PRIMARY 已运行
|
|
|
|
|
|
|
|
|
|
|
|
REPO-012 的 `gls/` 树中另有 75 个唯一编号 `.hdlp` 源。协议注册表、`GLS-ENTRY`、`SOURCE-MANIFEST`、架构目录和 routing 映射并未收敛为一份可执行注册真相:
|
|
|
|
|
|
|
|
|
|
|
|
- 注册表唯一编号:52
|
2026-08-17 16:49:39 +08:00
|
|
|
|
- 草案依赖涉及唯一编号:57
|
2026-08-17 16:36:25 +08:00
|
|
|
|
- 草案引用但未进入该注册表的依赖:19
|
|
|
|
|
|
- 草案引用但没有可直接定位的编号 `.hdlp` 正本:24
|
|
|
|
|
|
- 编号 `.hdlp` 存在但没有进入该协议注册表:31
|
|
|
|
|
|
|
|
|
|
|
|
因此,当前 `REGISTERED` 只能证明编号与文档登记,不能直接作为运行时激活条件。
|
|
|
|
|
|
|
|
|
|
|
|
## 2. 现有依赖图的阻塞问题
|
|
|
|
|
|
|
|
|
|
|
|
草案的 `depends` 同时混用了概念引用、类型引用、构建依赖、运行依赖、启动依赖和恢复依赖。若直接按包管理器依赖处理,会形成三个强连通环:
|
|
|
|
|
|
|
|
|
|
|
|
1. `GLS-0130 GLC ↔ GLS-0131 GIR`
|
|
|
|
|
|
2. `GLS-0310 / GLS-0803 / GLS-0819 / GLS-0827 / GLS-0840 / GLS-0841`
|
|
|
|
|
|
3. `GLS-0843 / GLS-0845 / GLS-0846 / GLS-0847 / GLS-0848 / GLS-0849`
|
|
|
|
|
|
|
|
|
|
|
|
处理规则:
|
|
|
|
|
|
|
|
|
|
|
|
- 将 `depends` 升级为带类型的边:`NORMATIVE_REFERENCE`、`SCHEMA_IMPORT`、`BUILD_REQUIRES`、`RUNTIME_REQUIRES`、`BOOT_REQUIRES`、`RECOVERY_REQUIRES`、`EVIDENCE_ONLY`。
|
|
|
|
|
|
- 只有 `RUNTIME_REQUIRES` 和所选运行目标相关的启动边进入激活拓扑。
|
|
|
|
|
|
- GIR 规范不运行依赖 GLC;GLC 只消费 HLDP-NP 并输出符合 GIR schema 的对象。
|
|
|
|
|
|
- 内核、硬件、调度、生命周期和广播塔先抽出稳定 capability interfaces,再由实现提供,避免对象层互相启动。
|
|
|
|
|
|
- 原生恢复、布局、内容仓、摄入、安全和回看拆成静态布局合同、摄入流水线、审查流水线和恢复服务四层。
|
|
|
|
|
|
- 未消除的运行环、缺失正本、冲突权威或漂移版本一律阻止激活。
|
|
|
|
|
|
|
|
|
|
|
|
## 3. 目标运行架构
|
|
|
|
|
|
|
|
|
|
|
|
```text
|
|
|
|
|
|
REPO-012 协议源
|
|
|
|
|
|
→ 注册对账与权威解析
|
|
|
|
|
|
→ 只读、固定提交、带摘要的 Protocol Bundle
|
|
|
|
|
|
→ Bootstrap Compiler 静态校验
|
|
|
|
|
|
→ 类型化 Contract IR
|
|
|
|
|
|
→ 原生适配器 / 状态机 / 路由表 / 守卫
|
|
|
|
|
|
→ HoloLake Protocol Kernel
|
|
|
|
|
|
→ 允许 / 拒绝 / 状态变更
|
|
|
|
|
|
→ GLP 可验证回执与 GLOW 只追加见证
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
运行时采用五类确定性器官:
|
|
|
|
|
|
|
|
|
|
|
|
1. `Schema/Codec`:验证消息、身份、上下文、工单、回执和模块制品。
|
|
|
|
|
|
2. `Guard/Policy`:返回 `ALLOW / DENY / AMBIGUOUS / UNVERIFIED` 与稳定 reason codes。
|
|
|
|
|
|
3. `Router`:根据已验证主体、目标、域、频道、能力和版本确定唯一去向。
|
|
|
|
|
|
4. `State Machine`:只允许协议声明的状态迁移,并保存前后状态与幂等键。
|
|
|
|
|
|
5. `Evidence/Receipt`:为每次裁决记录输入摘要、协议包摘要、适配器、决定、证据和目标侧核验。
|
|
|
|
|
|
|
|
|
|
|
|
自然语言原文和协议中任意代码永不在产品运行时直接执行。模型只能提交请求或生成候选计划,不能改写裁决、伪造权限或绕过状态机。
|
|
|
|
|
|
|
|
|
|
|
|
## 4. Bootstrap 与自举边界
|
|
|
|
|
|
|
|
|
|
|
|
第一版编译器必须由普通、可审计的 Rust/TypeScript 工程实现,不能要求尚未实现的 GLC 自己编译自己:
|
|
|
|
|
|
|
|
|
|
|
|
1. 解析编号、版本、状态、来源、权威、依赖和合同类型。
|
|
|
|
|
|
2. 校验文件摘要、唯一编号、来源提交、注册一致性和依赖闭包。
|
|
|
|
|
|
3. 将协议投影为受限 Contract IR,不接受自由脚本。
|
|
|
|
|
|
4. 生成 JSON Schema、Rust 类型、静态路由表、状态机表和测试向量。
|
|
|
|
|
|
5. 在 HLDP-NP、GLC、GIR 稳定后,再用同一黄金测试集完成自举一致性验证。
|
|
|
|
|
|
|
|
|
|
|
|
## 5. 分阶段实施
|
|
|
|
|
|
|
|
|
|
|
|
### P0 · 注册对账和可执行清单
|
|
|
|
|
|
|
|
|
|
|
|
- 建立 `GLS-RUNTIME-MANIFEST/v2`,合并协议注册表、`GLS-ENTRY`、`SOURCE-MANIFEST`、架构目录和 routing 的事实,但保留每条来源及冲突。
|
|
|
|
|
|
- 每个协议增加:`authority_source`、`maturity`、`contract_kind`、`dependency_edges`、`target_runtime`、`implementation_evidence`、`activation_state`。
|
|
|
|
|
|
- 状态严格区分:`DISCOVERED`、`REGISTERED`、`COMPILED`、`ADAPTED`、`TESTED`、`PUBLISHED`、`DEPLOYED`、`ACTIVE`、`HEALTHY`。
|
|
|
|
|
|
- 当前 75 份发现对象继续可见;未完成对账者保持 `INVENTORIED_NOT_EXECUTABLE`。
|
|
|
|
|
|
|
|
|
|
|
|
验收:零重复编号、零未分类依赖、零运行环、零缺失摘要;同一提交重复编译字节一致。
|
|
|
|
|
|
|
|
|
|
|
|
### P1 · 最小 GLP 合同内核
|
|
|
|
|
|
|
|
|
|
|
|
优先实现:
|
|
|
|
|
|
|
|
|
|
|
|
- `GLS-0301` Message Envelope
|
|
|
|
|
|
- `GLS-0302` Identity Reference
|
|
|
|
|
|
- `GLS-0303` Context
|
|
|
|
|
|
- `GLS-0306` Receipt
|
|
|
|
|
|
- 已有首批投影:`GLS-0250 / 0253 / 0262 / 0263`
|
|
|
|
|
|
|
|
|
|
|
|
交付:类型化 schema、严格 codec、身份与权限分离守卫、统一裁决 API、哈希链回执账本。
|
|
|
|
|
|
|
|
|
|
|
|
验收:缺字段、过期、错误域、身份冲突、未知权限、摘要漂移全部失败关闭;每次拒绝也必须产生回执。
|
|
|
|
|
|
|
|
|
|
|
|
### P2 · 会话、工单和在线状态
|
|
|
|
|
|
|
|
|
|
|
|
实现:
|
|
|
|
|
|
|
|
|
|
|
|
- `GLS-0307` Heartbeat
|
|
|
|
|
|
- `GLS-0309` Work Order
|
|
|
|
|
|
- `GLS-0842` HoloLake Live Session
|
|
|
|
|
|
- `GLS-0311` GLOW Witness 的最小只追加投影
|
|
|
|
|
|
|
|
|
|
|
|
验收:登记、测试、发布、部署分阶段;旧心跳不能证明当前健康;断联缓存不得冒充线上状态;工单提出者不能自批。
|
|
|
|
|
|
|
|
|
|
|
|
### P3 · 时间、记忆和状态一致性
|
|
|
|
|
|
|
|
|
|
|
|
实现:
|
|
|
|
|
|
|
|
|
|
|
|
- `GLS-0304` Memory Sync
|
|
|
|
|
|
- `GLS-0308` State Sync
|
|
|
|
|
|
- `GLS-0827` Persona Time Continuity
|
|
|
|
|
|
|
|
|
|
|
|
交付:单调事件序列、当前主实例租约、冲突保留、幂等重放、检查点与防双主写。
|
|
|
|
|
|
|
|
|
|
|
|
验收:并发状态不使用最后写入覆盖;租约过期回到未知;冲突双方版本均保留。
|
|
|
|
|
|
|
|
|
|
|
|
### P4 · 模块、生命周期和调度
|
|
|
|
|
|
|
|
|
|
|
|
实现:
|
|
|
|
|
|
|
|
|
|
|
|
- `GLS-0710` GMP immutable module backpack
|
|
|
|
|
|
- `GLS-0803` AGE execution-body lifecycle
|
|
|
|
|
|
- `GLS-0819` runway scheduler
|
|
|
|
|
|
- `GLS-0310` broadcast tower control plane
|
|
|
|
|
|
|
|
|
|
|
|
交付:签名不可变模块、完整生命周期状态机、资源轨道、唯一主控纪元、停止/清理/回滚闭环。
|
|
|
|
|
|
|
|
|
|
|
|
验收:人格主体与执行体进程分离;模块只能运行固定摘要;任务结束资源归零;跨频道读取被阻止。
|
|
|
|
|
|
|
|
|
|
|
|
### P5 · 外部适配、模型路由和临时能力
|
|
|
|
|
|
|
|
|
|
|
|
实现:
|
|
|
|
|
|
|
|
|
|
|
|
- `GLS-0709` UAP
|
|
|
|
|
|
- `GLS-0708` GMRP
|
|
|
|
|
|
- `GLS-0828` PEN
|
|
|
|
|
|
|
|
|
|
|
|
所有外部 API、CLI、MCP、数据库和模型先被 UAP 转译成 P1/P2 合同;模型只作为可替换推理设备;PEN 只在隔离环境产生临时能力,不能自动永久安装、发布或部署。
|
|
|
|
|
|
|
|
|
|
|
|
### P6 · 编译体系自举
|
|
|
|
|
|
|
|
|
|
|
|
实现:
|
|
|
|
|
|
|
|
|
|
|
|
- `GLS-0411` HLDP-NP
|
|
|
|
|
|
- `GLS-0130` GLC
|
|
|
|
|
|
- `GLS-0131` GIR
|
|
|
|
|
|
|
|
|
|
|
|
用 Bootstrap Compiler 的固定语料和黄金 IR 做双编译一致性验证。只有自举输出、原生适配器输出和回执一致,才允许 GLC 成为正式协议编译入口。
|
|
|
|
|
|
|
|
|
|
|
|
### P7 · 原生 OS 专用协议装配
|
|
|
|
|
|
|
|
|
|
|
|
`GLS-0836 / 0840–0849` 按节点能力装配,不在桌面端模拟原生物理证据:
|
|
|
|
|
|
|
|
|
|
|
|
- 桌面 HoloLake 只消费公开合同、会话、回执和健康投影。
|
|
|
|
|
|
- JD-FD-PRIMARY、BS-SH-005 或未来原生节点分别提供 capability implementation 和目标侧回执。
|
|
|
|
|
|
- 旧 BS-SH-005 物理回执只证明原节点与原版本的能力,不能自动迁移为 JD 或桌面健康。
|
|
|
|
|
|
|
|
|
|
|
|
## 6. 协议更新与激活
|
|
|
|
|
|
|
|
|
|
|
|
第五域只发布不可变、签名、固定提交的 Protocol Bundle。HoloLake 使用单向接收器:
|
|
|
|
|
|
|
|
|
|
|
|
```text
|
|
|
|
|
|
FETCH → VERIFY SIGNATURE → VERIFY HASH/SCHEMA → COMPILE → DRY RUN
|
|
|
|
|
|
→ COMPATIBILITY GATE → HUMAN IMPACT GATE → ATOMIC ACTIVATE → HEALTH
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
- 更新包不能携带任意可执行脚本。
|
|
|
|
|
|
- 激活前保存当前 bundle、状态快照和回滚点。
|
|
|
|
|
|
- 权利、隐私、数据、安装、费用或责任变化必须产生可见确认。
|
|
|
|
|
|
- 健康失败自动回到上一个已验证 bundle,并保留失败回执。
|
|
|
|
|
|
- 协议源更新权、产品实现权和现实执行授权继续分离。
|
|
|
|
|
|
|
|
|
|
|
|
## 7. 统一裁决回执
|
|
|
|
|
|
|
|
|
|
|
|
每次协议裁决至少记录:
|
|
|
|
|
|
|
|
|
|
|
|
```yaml
|
|
|
|
|
|
protocol_decision_receipt:
|
|
|
|
|
|
receipt_id:
|
|
|
|
|
|
request_id:
|
|
|
|
|
|
event_kind:
|
|
|
|
|
|
subject_id:
|
|
|
|
|
|
target_id:
|
|
|
|
|
|
protocol_bundle_commit:
|
|
|
|
|
|
protocol_bundle_sha256:
|
|
|
|
|
|
protocol_set:
|
|
|
|
|
|
adapter_id:
|
|
|
|
|
|
input_digest:
|
|
|
|
|
|
decision: ALLOW | DENY | AMBIGUOUS | UNVERIFIED
|
|
|
|
|
|
reason_codes: []
|
|
|
|
|
|
state_before_digest:
|
|
|
|
|
|
state_after_digest:
|
|
|
|
|
|
evidence_refs: []
|
|
|
|
|
|
time_authority:
|
|
|
|
|
|
idempotency_key:
|
|
|
|
|
|
signer:
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
没有目标侧证据时只能返回 `UNVERIFIED`;界面颜色、模型回答、命令退出码或单条日志均不构成完成证明。
|
|
|
|
|
|
|
|
|
|
|
|
## 8. 当前 HoloLake 分支的承接关系
|
|
|
|
|
|
|
2026-08-17 16:49:39 +08:00
|
|
|
|
`d6b1290` 完成了 75 份编号协议的确定性发现登记,并为 `GLS-0250 / 0253 / 0262 / 0263` 建立首批原生适配器。P0 随后已把运行清单升级为 v2:四份登记源分别固化摘要,75 份协议全部取得登记解释,旧依赖与显式运行依赖分离,三组旧环只进入审计面而不能进入执行图。
|
2026-08-17 16:36:25 +08:00
|
|
|
|
|
2026-08-17 17:56:47 +08:00
|
|
|
|
P1–P6 已按顺序实现为 HoloLake Rust 原生器官:统一裁决 API 对消息、身份、上下文、会话、心跳、工单、见证、时间、记忆、状态、模块、生命周期、资源轨道、广播主控、外部适配、模型路由、临时能力和 HLDP-NP/GIR 编译执行确定性守门;所有裁决进入用户侧 SQLite 哈希链。工单阶段、时间租约、不可变模块、人格执行体生命周期、隔离跑道与广播塔主控纪元和裁决回执在同一原子事务中推进;旧状态重放、租约内双主、越权释放和同编号换摘要都失败关闭,并发记忆/状态版本写入冲突集而非互相覆盖。GLC Bootstrap Compiler 对同一黄金程序执行双编译一致性检查,不解析自由自然语言、不执行生成代码。
|
|
|
|
|
|
|
|
|
|
|
|
P7 已实现桌面产品侧装配注册表,但没有伪造物理能力:GLS-0836 与 GLS-0840–0849 全部保留目标节点、来源证据节点和当前装配状态,`ACTIVE_HEALTHY` 数量固定为 0,直到目标节点自身给出版本绑定回执。协议合同、运行图、状态机和编译器通过 Rust 编入 HoloLake 应用;用户数据与裁决回执留在各自应用数据目录。
|
|
|
|
|
|
|
|
|
|
|
|
当前验收数字:75 份编号源、183 条已分型来源依赖、0 条未分类依赖、25 份可执行投影、50 份库存不可执行源、P1–P6 共 21 份新原生器官、P7 共 11 项失败关闭装配边界。
|
2026-08-17 16:36:25 +08:00
|
|
|
|
|
|
|
|
|
|
这保证“已注册”不会被误报为“系统正在运行”,也保证每次新增执行协议都有可重复编译、明确守卫和真实回执。
|