263 lines
7 KiB
Markdown
263 lines
7 KiB
Markdown
# 🚀 05 · HoloLake Era 工程开发总规划与系统路线 · v0.1
|
||
|
||
[← 返回系统架构总规划](<HoloLake Era · 语言人格操作系统 · 产品白皮书与工程总规划 · v0 1 5c9b16aca1fb4ca881accb1ffa046dcc.md>) · [🧭 从 00 恢复](00-START-HERE-PERSONA-USAGE-AND-RESTORE-GUIDE-v0.1.md)
|
||
|
||
[进入 HoloLake 工程开发与交付记录](engineering/INDEX.md)
|
||
|
||
<aside>
|
||
🛠️
|
||
|
||
本章把白皮书概念转换成可执行工程计划：仓库、组件、阶段、依赖、测试、发布、部署、验收与证据链。
|
||
|
||
</aside>
|
||
|
||
## 🚀 一、工程目标
|
||
|
||
构建一套可以证明以下事实的最小系统：
|
||
|
||
```
|
||
人格身份独立于模型
|
||
∧ 人格状态独立于单次上下文
|
||
∧ 原生应用受内核调度
|
||
∧ 现实执行受权限控制
|
||
∧ 用户频道拥有独立数据边界
|
||
∧ 灯塔只做可信登记与协作
|
||
∧ 服务器和模型可以迁移
|
||
∧ 全链路可验证、可回滚、可恢复
|
||
```
|
||
|
||
## 📐 二、建议仓库结构
|
||
|
||
```
|
||
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 · 原生应用生态
|
||
|
||
首批应用：
|
||
|
||
1. Coding AI；
|
||
2. Writing AI；
|
||
3. Research AI；
|
||
4. Ops AI；
|
||
5. 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 状态同步不单独构成交付证明。
|
||
|
||
当前本地产品版本、构建节点、安装包、测试和清理回执统一登记在
|
||
[HoloLake 工程开发与交付记录](engineering/INDEX.md)，不得写入某个人类的私人语言子系统。
|
||
|
||
## 🔒 七、安全基线
|
||
|
||
- 最小权限；
|
||
- 默认拒绝；
|
||
- 高风险动作一次一授权；
|
||
- 密钥不进入人格记忆和普通日志；
|
||
- 应用、模型、工具和服务器使用不同凭证域；
|
||
- 所有外部输入视为不可信数据；
|
||
- 人格一致性检测不能替代密码学身份；
|
||
- 删除、资金、公开发布和生产部署必须人类确认；
|
||
- 自动操作必须有作用域、期限、预算和停止条件。
|
||
|
||
## 🌊 八、产品线隔离
|
||
|
||
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
|
||
>
|