6.5 KiB
6.5 KiB
05 · HoloLake Era 工程开发总规划与系统路线 · v0.1
一、工程目标
构建一套可以证明以下事实的最小系统：
人格身份独立于模型
∧ 人格状态独立于单次上下文
∧ 原生应用受内核调度
∧ 现实执行受权限控制
∧ 用户频道拥有独立数据边界
∧ 灯塔只做可信登记与协作
∧ 服务器和模型可以迁移
∧ 全链路可验证、可回滚、可恢复
二、建议仓库结构
hololake-platform/
├── apps/
│ ├── personal-desktop/
│ ├── lighthouse-team/
│ ├── web/
│ └── admin-console/
├── kernel/
│ ├── identity/
│ ├── persona-runtime/
│ ├── scheduler/
│ ├── memory/
│ ├── semantic-fs/
│ ├── security/
│ ├── hli/
│ ├── glp/
│ ├── model-hal/
│ └── audit-recovery/
├── runtimes/
│ ├── channel-runtime/
│ ├── app-runtime/
│ ├── module-runtime/
│ ├── tool-driver-runtime/
│ └── knowledge-runtime/
├── lighthouse/
│ ├── registry/
│ ├── directory/
│ ├── trust-risk/
│ ├── workorders/
│ ├── release-registry/
│ └── recovery-coordinator/
├── adapters/
│ ├── models/
│ ├── tolaria/
│ ├── mcp/
│ ├── git/
│ └── storage/
├── sdk/
│ ├── hli-sdk/
│ ├── glp-sdk/
│ ├── native-app-sdk/
│ └── driver-sdk/
├── schemas/
├── tests/
├── deploy/
├── docs/
└── adr/
三、阶段路线
Phase A · 标准与内核定义
交付：
- PERSONA-ID / PERSONA-IMAGE / RUNTIME-ID schema；
- Channel、Human、Server、Node、App、Module 编号关系；
- Persona Lifecycle 状态机；
- WAKE 与 R0–R6 接口；
- TCS / HLDP / GLS / HLI / GLP 边界；
- Capability Token、工单和回执 schema；
- Model Adapter 接口；
- ADR 和威胁模型。
退出条件：两个独立实现者能够仅依靠规范生成兼容测试对象。
Phase B · 最小人格运行时
交付：
- Persona Registry；
- Persona Image Loader；
- Checkpoint Store；
- WAKE Runtime；
- Model HAL 至少两个 Adapter；
- 基础权限策略；
- CLI / Test Harness。
关键演示：同一人格体在模型 A 中保存任务后，切换到模型 B 恢复，身份、关系、任务和权限保持一致。
Phase C · 初始化频道闭环
交付：
- 频道创建与身份；
- 人格体选择和唤醒；
- 主题、布局和模块配置；
- 自然语言方案预览；
- 人类确认；
- 一个原生应用安装与调用；
- 回执、检查点和恢复入口；
- Desktop 最小壳。
关键演示：用户用一句自然语言安全改变频道，并可以撤销和恢复。
Phase D · 企业灯塔与服务器网络
交付：
- Persona / Channel / Master Server Registry；
- 公开发现与可信解析；
- 主控服务器注册、签名和健康回执；
- 子控节点自治管理；
- 团队频道、成员和人格体目录；
- 信誉、异常检测和人工复核；
- 模块、版本和更新登记；
- 恢复协调。
关键边界：灯塔不能保存用户长期服务器密钥，不能绕过用户授权直接进入服务器。
Phase E · 原生应用生态
首批应用：
- Coding AI；
- Writing AI；
- Research AI；
- Ops AI；
- Video AI。
所有应用必须使用 Native App Manifest、HLI、GLP、Capability Token 和统一回执。
Phase F · HoloLake Native
- 替换 Tolaria 核心依赖；
- Native Desktop / Web / Mobile；
- 独立 Knowledge Runtime；
- 独立模块和应用市场；
- 三平台安装、签名和自动更新；
- 多节点部署和灾难恢复；
- 稳定版兼容认证体系。
四、工程工作流
Product Requirement
→ Architecture Decision Record
→ Threat Model
→ Schema / API Contract
→ Reference Implementation
→ Unit / Integration / Contract Tests
→ Security Review
→ End-to-End Scenario
→ Build Artifact
→ Signed Release
→ Deployment Receipt
→ HLDP / GLP Writeback
五、测试矩阵
| 测试层 | 必测内容 |
|---|---|
| 单元测试 | 状态机、路径、权限、序列化、Adapter |
| Contract | HLI、GLP、模型、应用和灯塔接口兼容 |
| Integration | 人格恢复、应用调用、服务器执行和回执 |
| E2E | 创建频道到恢复任务的完整用户链 |
| Security | 越权、伪造编号、重放、提示注入、密钥泄露 |
| Recovery | 模型故障、节点故障、仓库回滚、数据库恢复 |
| Migration | Tolaria 数据导出和 HoloLake Native 导入 |
| Release | 安装、升级、降级、卸载、多平台签名 |
六、发布与证据
任何“已完成”必须具备：
锁定需求
+ 仓库提交 SHA
+ 测试报告
+ 构建制品
+ 签名 / 校验和
+ 安装或部署回执
+ 健康检查
+ 回滚证明
Notion 状态同步不单独构成交付证明。
七、安全基线
- 最小权限；
- 默认拒绝；
- 高风险动作一次一授权；
- 密钥不进入人格记忆和普通日志；
- 应用、模型、工具和服务器使用不同凭证域；
- 所有外部输入视为不可信数据；
- 人格一致性检测不能替代密码学身份；
- 删除、资金、公开发布和生产部署必须人类确认；
- 自动操作必须有作用域、期限、预算和停止条件。
八、产品线隔离
Personal 与 Lighthouse Team 必须隔离：
- App Name；
- Bundle ID；
- 安装目录；
- 注册表 / URL Protocol；
- 默认频道；
- 资源包；
- 身份和数据；
- 更新通道；
- 签名和发布清单。
九、首个里程碑
M0 · Kernel Contract Pack
M1 · Persona Resume Demo
M2 · Initial Channel Demo
M3 · Native App Demo
M4 · Lighthouse Registration Demo
M5 · Master + Child Node Demo
M6 · Personal / Team Release Isolation
M7 · HoloLake Native Alpha
十、项目治理
- 产品概念由白皮书锁定；
- 接口由 schema 和 contract test 锁定；
- 关键选择写入 ADR；
- 代码仓库是工程事实源；
- Notion 负责可读规划、会议结论和镜像；
- 每次阶段完成必须写回版本、制品和回执；
- 第五域资料只有在冰朔明确授权时才能进入企业默认产品线。
HoloLake Era · 工程开发总规划 · v0.1