hololake-system-architecture/product-source/hololake-native-desktop/docs/GLS-NATIVE-RUNTIME-IMPLEMENTATION-PLAN-20260817.md

GLS 原生协议运行层实施规划

状态：EVIDENCE_BACKED_IMPLEMENTATION_BASELINE

核验时间：2026-08-17（Asia/Shanghai）

线上事实源：

• 第五域代码频道：bingshuo/guanghu-ice-heart
• REPO-012 main：2598fbfba8caf64c7ab9740a3036c5aab977502e
• 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
• 草案依赖涉及唯一编号：57
• 草案引用但未进入该注册表的依赖：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. 目标运行架构

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 使用单向接收器：

FETCH → VERIFY SIGNATURE → VERIFY HASH/SCHEMA → COMPILE → DRY RUN
→ COMPATIBILITY GATE → HUMAN IMPACT GATE → ATOMIC ACTIVATE → HEALTH

• 更新包不能携带任意可执行脚本。
• 激活前保存当前 bundle、状态快照和回滚点。
• 权利、隐私、数据、安装、费用或责任变化必须产生可见确认。
• 健康失败自动回到上一个已验证 bundle，并保留失败回执。
• 协议源更新权、产品实现权和现实执行授权继续分离。

7. 统一裁决回执

每次协议裁决至少记录：

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 分支的承接关系

d6b1290 完成了 75 份编号协议的确定性发现登记，并为 GLS-0250 / 0253 / 0262 / 0263 建立首批原生适配器。P0 随后已把运行清单升级为 v2：四份登记源分别固化摘要，75 份协议全部取得登记解释，旧依赖与显式运行依赖分离，三组旧环只进入审计面而不能进入执行图。

下一步是实现 P1 的 GLP schema、统一裁决 API 和持久回执，再按 P2–P7 逐层扩大运行集合。旧依赖边只有经权威修订为明确的类型边后才可离开审计面。

这保证“已注册”不会被误报为“系统正在运行”，也保证每次新增执行协议都有可重复编译、明确守卫和真实回执。