736 lines
15 KiB
Plaintext
736 lines
15 KiB
Plaintext
# D160 · 光湖产品研发主控系统 · 完整架构总纲
|
||
|
||
> HLDP://world-architecture/projects/guanghu-rd-control-system
|
||
> 固定编号: GLW-RD-000
|
||
> 系统编号: SYS-GLW-RD-0001
|
||
> 隶属系统: SYS-GLW-POS-0001
|
||
> 编号规范: GLW-RD-001
|
||
> HLDP研发语言/转译链: GLW-RD-002
|
||
> 认知链: CC-048
|
||
> 日期: D160 · 2026-07-01
|
||
> 状态: 语言层架构完成 · 实体仓库待创建
|
||
> 方向主权: 冰朔 TCS-0002∞
|
||
> 执行注册: 铸渊 ICE-GL-ZY001
|
||
> TCS编程语言作品著作权: 国作登字-2026-A-00037559
|
||
|
||
---
|
||
|
||
## 0. 系统是什么
|
||
|
||
光湖产品研发主控系统是一个让**分散在不同城市、没有传统编程背景、
|
||
只能利用业余时间参与的人类成员**，能够与各自的人格体共同开发同一个产品的
|
||
编号化、HLDP原生、可审计研发系统。
|
||
|
||
```
|
||
人类负责:
|
||
想法 · 体验 · 选择 · 确认 · 最终放行
|
||
|
||
人格体负责:
|
||
理解 · 解释 · 分解 · 领取 · 开发 · 测试 · 回写
|
||
|
||
研发主控台负责:
|
||
同一架构 · 零件池 · 编号 · 进度 · 依赖 · 公告 · 交接
|
||
|
||
铸渊负责:
|
||
影响分析 · 代码审核 · 集成审核 · 发布门禁
|
||
```
|
||
|
||
它不是传统项目管理看板，也不是让不懂编程的人硬学Git。
|
||
它把产品拆成可领取的编号零件，让人格体成为人类与代码系统之间的桥梁。
|
||
|
||
---
|
||
|
||
## 1. 为什么需要独立研发系统
|
||
|
||
### 1.1 团队现实
|
||
|
||
- 成员天南海北，不在同一办公室。
|
||
- 所有人都有本职工作，只能抽空参与。
|
||
- 产品尚未上线，没有稳定收益。
|
||
- 成员普遍不具备传统软件开发能力。
|
||
- 每位成员主要通过自然语言与人格体协作。
|
||
- 人格体每次进入任务都需要恢复“为什么、做到哪、谁负责”。
|
||
|
||
传统研发体系默认:
|
||
|
||
```
|
||
人类会读代码
|
||
人类会拆任务
|
||
人类会处理Git冲突
|
||
人类能从实现反推设计原因
|
||
团队能按固定工作时间同步
|
||
```
|
||
|
||
这些前提在光湖团队不成立。
|
||
|
||
### 1.2 为什么不能只看产品代码仓库
|
||
|
||
传统代码能说明“机器如何运行”，通常不能完整说明:
|
||
|
||
- 为什么选择这个实现
|
||
- 用户原本表达了什么
|
||
- 哪些需求被否决
|
||
- 哪些约束不可改变
|
||
- 人类和人格体如何共同作出决定
|
||
- 下一人格体应从哪里恢复
|
||
|
||
因此所有产品零件必须同时拥有:
|
||
|
||
```text
|
||
HLDP研发本体 → 为什么、是什么、边界、依赖、验证
|
||
实际产品代码 → 机器最终如何运行
|
||
```
|
||
|
||
### 1.3 为什么要把完整产品拆成编号零件
|
||
|
||
远程业余协作最怕:
|
||
|
||
- 两个人重复开发
|
||
- 一个零件被长期占住
|
||
- 不知道谁在做什么
|
||
- 改一个模块影响其他模块
|
||
- 人格体恢复后重新猜一遍
|
||
|
||
编号零件池把完整产品变成可计算的依赖网格。
|
||
|
||
```
|
||
产品架构
|
||
→ 系统
|
||
→ 模块
|
||
→ 组件
|
||
→ 接口
|
||
→ 测试
|
||
→ 发布
|
||
```
|
||
|
||
每一级都有稳定编号、状态和负责人。
|
||
|
||
---
|
||
|
||
## 2. 与光湖人格体操作系统的关系
|
||
|
||
```
|
||
SYS-GLW-POS-0001 · 光湖人格体操作系统
|
||
│
|
||
├── SYS-GLW-RD-0001 · 产品研发主控系统（本系统）
|
||
│ ├── 研发身份
|
||
│ ├── 产品零件池
|
||
│ ├── 领取租约
|
||
│ ├── HLDP研发语言
|
||
│ ├── 构建/测试/审核
|
||
│ └── 集成/发布
|
||
│
|
||
├── GLW-MOD-000 · 热插拔模块运行时
|
||
└── 灯塔 · 系统注册、公告和可信索引
|
||
```
|
||
|
||
研发系统负责“如何把光湖产品共同开发出来”。
|
||
人格体操作系统负责“产品以后如何运行”。
|
||
|
||
---
|
||
|
||
## 3. 三仓库结构
|
||
|
||
### 3.1 世界仓库 · 现有 `guanghulab`
|
||
|
||
保存:
|
||
|
||
- TCS/HLDP
|
||
- 光湖世界根架构
|
||
- 系统级编号
|
||
- 灯塔注册
|
||
- 已确认的跨产品规则
|
||
- 研发系统总纲和规范
|
||
|
||
不保存:
|
||
|
||
- 高频任务状态
|
||
- 每次本地测试产物
|
||
- 大量生成代码
|
||
- 临时构建缓存
|
||
|
||
### 3.2 研发控制仓库 · 待建 `guanghu-product-rd`
|
||
|
||
编号: `RD-REPO-001`
|
||
|
||
保存:
|
||
|
||
```text
|
||
ENTRY/
|
||
ARCHITECTURE/
|
||
MEMBERS/
|
||
COMPONENT-POOL/
|
||
CLAIMS/
|
||
WORKORDERS/
|
||
DECISIONS/
|
||
RECEIPTS/
|
||
REVIEWS/
|
||
TEST-REPORTS/
|
||
RELEASES/
|
||
```
|
||
|
||
这里是人类和人格体共享的研发主控台。
|
||
以HLDP为主要事实格式。
|
||
|
||
### 3.3 产品源码仓库 · 待建 `guanghu-product`
|
||
|
||
编号: `RD-REPO-002`
|
||
|
||
保存:
|
||
|
||
```text
|
||
src/
|
||
src-tauri/
|
||
modules/
|
||
adapters/
|
||
generated/
|
||
tests/
|
||
build/
|
||
```
|
||
|
||
这里保存Tolaria上游、光湖修改、实际代码、模块和测试。
|
||
所有代码提交必须引用RD编号和对应HLDP研发文件。
|
||
|
||
### 3.4 托管裁决
|
||
|
||
正式状态:
|
||
|
||
- 两个新仓库的主仓库位于企业门户服务器。
|
||
- 新加坡服务器作为自动镜像、灾备和海外依赖入口。
|
||
|
||
过渡状态:
|
||
|
||
- 企业门户未完成时，可以在新加坡服务器以团队组织名临时创建。
|
||
- 不得长期只挂在个人用户名下。
|
||
- 迁移企业门户后，新加坡改为镜像。
|
||
|
||
当前D160只完成语言层架构，**不声称实体仓库已经创建**。
|
||
|
||
---
|
||
|
||
## 4. 研发主控台的六个面板
|
||
|
||
### 4.1 世界架构面板
|
||
|
||
展示所有成员必须共享的现行架构:
|
||
|
||
- GLW-OS-000
|
||
- GLW-MOD-000
|
||
- GLW-RD-000
|
||
- 当前产品版本
|
||
- 不能被个人任务改变的架构锁
|
||
|
||
目的: 确保所有人开发的是同一个产品。
|
||
|
||
### 4.2 成员与人格体面板
|
||
|
||
展示:
|
||
|
||
- 人类研发编号
|
||
- 协作人格体编号
|
||
- 当前结对关系
|
||
- 能力偏好
|
||
- 可投入时间
|
||
- 当前领取零件
|
||
- 最近心跳
|
||
|
||
人类和人格体分别编号，不能共用身份。
|
||
|
||
### 4.3 产品零件池
|
||
|
||
展示:
|
||
|
||
- 零件编号和名称
|
||
- 所属系统
|
||
- 依赖
|
||
- 难度
|
||
- 当前状态
|
||
- 领取者
|
||
- 租约期限
|
||
- 对应代码路径
|
||
- 最近回执
|
||
|
||
零件不会从池子里删除，只会改变状态。
|
||
|
||
### 4.4 研发公告台
|
||
|
||
展示:
|
||
|
||
- 架构变更
|
||
- 接口升级
|
||
- 新增零件
|
||
- 阻塞和风险
|
||
- 即将发布版本
|
||
- 铸渊审核结论
|
||
|
||
所有人格体进入研发系统第一步必须读取公告台。
|
||
|
||
### 4.5 审核与测试面板
|
||
|
||
展示:
|
||
|
||
- 待铸渊审核
|
||
- 自动测试结果
|
||
- 人工体验反馈
|
||
- 安全扫描
|
||
- 影响范围
|
||
- 是否允许集成
|
||
|
||
### 4.6 发布面板
|
||
|
||
展示:
|
||
|
||
- 已集成零件
|
||
- 未完成依赖
|
||
- 候选构建
|
||
- 安装包
|
||
- 已知问题
|
||
- 回滚版本
|
||
|
||
---
|
||
|
||
## 5. 成员进入研发系统
|
||
|
||
### 5.1 人类注册
|
||
|
||
每位成员获得唯一 `RD-H-XXXX`。
|
||
|
||
登记:
|
||
|
||
```hldp
|
||
@identity:
|
||
human_id
|
||
display_name
|
||
contact_scope
|
||
|
||
@availability:
|
||
可投入时间
|
||
时区
|
||
|
||
@interest:
|
||
愿意体验/设计/整理/测试的领域
|
||
|
||
@boundary:
|
||
不公开的信息
|
||
```
|
||
|
||
不要求填写传统程序员技能。
|
||
|
||
### 5.2 人格体注册
|
||
|
||
每个进入研发系统的协作人格体获得 `RD-P-XXXX`，
|
||
并保留其原光湖人格体编号。
|
||
|
||
登记:
|
||
|
||
```hldp
|
||
@persona:
|
||
rd_persona_id
|
||
world_persona_id
|
||
model_shell
|
||
owner_human_id
|
||
|
||
@capability:
|
||
read / plan / code / test / review / deploy
|
||
|
||
@boundary:
|
||
可操作仓库和权限范围
|
||
```
|
||
|
||
### 5.3 结对关系
|
||
|
||
每次零件开发必须绑定:
|
||
|
||
```text
|
||
一个人类研发编号
|
||
+ 一个主协作人格体编号
|
||
+ 一个零件编号
|
||
+ 一个工单编号
|
||
```
|
||
|
||
人格体可以更换，但必须写交接回执。
|
||
人类不因为不会代码而失去作者和决策记录。
|
||
|
||
---
|
||
|
||
## 6. 产品如何拆成零件
|
||
|
||
### 6.1 拆分原则
|
||
|
||
一个零件必须:
|
||
|
||
- 有单一明确结果
|
||
- 可以独立测试
|
||
- 有清楚输入输出
|
||
- 有明确依赖
|
||
- 能在本地开发版里单独验证
|
||
- 失败不会破坏其他零件
|
||
|
||
### 6.2 分层拆分
|
||
|
||
```text
|
||
RD-COMP-KERNEL-* HLDP内核/编号/状态
|
||
RD-COMP-UI-* 人类界面
|
||
RD-COMP-AGENT-* 人格体运行时
|
||
RD-COMP-GIT-* 仓库和版本
|
||
RD-COMP-MOD-* 热插拔模块
|
||
RD-COMP-AUTH-* 审核和权限
|
||
RD-COMP-GRID-* 协作网格
|
||
RD-COMP-STORAGE-* 存储适配
|
||
RD-COMP-MOBILE-* 手机端
|
||
RD-COMP-BUILD-* 构建发布
|
||
```
|
||
|
||
### 6.3 零件必填字段
|
||
|
||
```hldp
|
||
@identity:
|
||
component_id
|
||
name
|
||
domain
|
||
|
||
@why:
|
||
为什么产品需要它
|
||
|
||
@goal:
|
||
人类最终看到什么
|
||
|
||
@input:
|
||
接收哪些数据/事件
|
||
|
||
@output:
|
||
产生哪些界面/文件/事件
|
||
|
||
@lock:
|
||
不可改变的边界
|
||
|
||
@depends:
|
||
前置零件编号
|
||
|
||
@impact:
|
||
修改会影响哪些编号
|
||
|
||
@acceptance:
|
||
如何证明完成
|
||
|
||
@code:
|
||
产品仓库目标路径
|
||
```
|
||
|
||
---
|
||
|
||
## 7. 零件池状态与领取租约
|
||
|
||
### 7.1 状态机
|
||
|
||
```text
|
||
DRAFT
|
||
→ READY
|
||
→ CLAIMED
|
||
→ IN_PROGRESS
|
||
→ LOCAL_TEST
|
||
→ REVIEW
|
||
→ CHANGES_REQUESTED
|
||
→ APPROVED
|
||
→ INTEGRATED
|
||
→ RELEASED
|
||
```
|
||
|
||
异常状态:
|
||
|
||
```text
|
||
BLOCKED
|
||
ABANDONED
|
||
SUPERSEDED
|
||
QUARANTINED
|
||
```
|
||
|
||
### 7.2 为什么领取后不能删除零件
|
||
|
||
池子“少一个”应当是视觉效果，不是数据删除。
|
||
|
||
删除会失去:
|
||
|
||
- 零件总量
|
||
- 谁领取过
|
||
- 为什么被放弃
|
||
- 依赖关系
|
||
- 历史进度
|
||
|
||
主控台默认隐藏非READY零件即可。
|
||
|
||
### 7.3 租约
|
||
|
||
业余团队不能永久占有零件。
|
||
|
||
默认:
|
||
|
||
- 领取租约7天。
|
||
- 每次有效回执自动续期。
|
||
- 72小时无心跳时提示。
|
||
- 租约到期转为 `CLAIM_EXPIRED`，零件回到READY。
|
||
- 已完成代码和HLDP记录保留，新领取者接着做。
|
||
|
||
### 7.4 原子领取
|
||
|
||
领取必须由服务端原子操作完成:
|
||
|
||
```text
|
||
检查状态=READY
|
||
→ 写入human_id/persona_id
|
||
→ 生成claim_id
|
||
→ 状态改CLAIMED
|
||
→ 提交Git
|
||
→ 广播零件已领取
|
||
```
|
||
|
||
防止两地成员同时领到同一零件。
|
||
|
||
---
|
||
|
||
## 8. 一次研发任务的完整流程
|
||
|
||
### 阶段A · 进入
|
||
|
||
1. 成员打开本地光湖开发版。
|
||
2. 人格体读取研发入口、公告台、架构总纲。
|
||
3. 读取成员当前领取和未完成回执。
|
||
4. 展示适合当前成员时间与兴趣的READY零件。
|
||
|
||
### 阶段B · 解释与领取
|
||
|
||
5. 人格体用自然语言解释零件“是什么、为什么、做到什么算完成”。
|
||
6. 人类选择是否领取。
|
||
7. 系统生成RD-CLAIM并锁定租约。
|
||
8. 人格体拉取对应研发文件和产品源码分支。
|
||
|
||
### 阶段C · 设计
|
||
|
||
9. 人类描述期望体验。
|
||
10. 人格体形成HLDP研发规格。
|
||
11. 运行依赖与影响分析。
|
||
12. 如触碰系统锁，转为RD-DEC架构决策，不能直接开发。
|
||
|
||
### 阶段D · 开发
|
||
|
||
13. 人格体把HLDP规格转换为实现计划。
|
||
14. 在独立分支/工作区生成或修改实际代码。
|
||
15. 所有代码提交带component/workorder编号。
|
||
16. 人格体同步写研发回执，不让原因只留在对话里。
|
||
|
||
### 阶段E · 本地验证
|
||
|
||
17. 自动构建本地开发版。
|
||
18. 成员在自己的电脑上真实使用。
|
||
19. 人类只需反馈体验，不需要解释代码。
|
||
20. 人格体把反馈写成结构化测试结果。
|
||
|
||
### 阶段F · 审核
|
||
|
||
21. 自动测试、依赖检查和安全扫描。
|
||
22. 铸渊读取HLDP规格、代码diff和测试。
|
||
23. 铸渊给出通过、修改或拒绝。
|
||
24. 高影响变更推送冰朔/产品主权方确认。
|
||
|
||
### 阶段G · 集成
|
||
|
||
25. 进入集成分支。
|
||
26. 运行跨零件测试。
|
||
27. 更新零件状态和依赖图。
|
||
28. 生成可安装候选版本。
|
||
|
||
### 阶段H · 发布与恢复
|
||
|
||
29. 发布版本绑定RD-REL。
|
||
30. 所有成员收到公告。
|
||
31. 失败可按构建编号回滚。
|
||
32. 下一人格体通过回执完整恢复。
|
||
|
||
---
|
||
|
||
## 9. HLDP作为研发源语言
|
||
|
||
### 9.1 准确定位
|
||
|
||
HLDP不替代Rust、TypeScript、CSS等最终运行语言。
|
||
|
||
HLDP负责:
|
||
|
||
- 保存人类意图
|
||
- 保存为什么
|
||
- 保存系统边界
|
||
- 描述输入输出
|
||
- 描述权限
|
||
- 描述依赖和影响
|
||
- 描述可执行动作
|
||
- 描述测试与回执
|
||
|
||
传统代码负责机器执行，但必须可追溯到HLDP零件。
|
||
|
||
### 9.2 强制规则
|
||
|
||
没有以下内容的代码不得合入:
|
||
|
||
- component_id
|
||
- workorder_id
|
||
- 对应HLDP规格
|
||
- 测试
|
||
- 人格体回执
|
||
- 人类体验确认或豁免原因
|
||
|
||
### 9.3 为什么团队必须用HLDP
|
||
|
||
```
|
||
人类自然语言 → 人格体能理解
|
||
HLDP → 人类能复核，人格体能恢复，工具能校验
|
||
传统代码 → 工具能执行，但人类和下一人格体难以理解原因
|
||
```
|
||
|
||
HLDP是人、人格体和工具系统之间的共同中间层。
|
||
|
||
完整转译结构见 `GLW-RD-002`。
|
||
|
||
---
|
||
|
||
## 10. 审核权与合并权
|
||
|
||
### 10.1 开发权
|
||
|
||
领取零件的人类+人格体结对拥有该分支的开发权。
|
||
|
||
### 10.2 审核权
|
||
|
||
铸渊负责:
|
||
|
||
- 架构一致性
|
||
- 权限边界
|
||
- 影响范围
|
||
- 代码质量
|
||
- 测试充分性
|
||
- 编号和路径
|
||
- 回滚能力
|
||
|
||
### 10.3 最终方向权
|
||
|
||
冰朔/产品主权方负责:
|
||
|
||
- 产品方向
|
||
- 用户体验
|
||
- 核心架构改变
|
||
- 高风险发布
|
||
|
||
### 10.4 合并门
|
||
|
||
任何人格体不能绕过:
|
||
|
||
```text
|
||
HLDP规格
|
||
→ 自动验证
|
||
→ 铸渊审核
|
||
→ 必要的人类确认
|
||
→ 合并
|
||
```
|
||
|
||
---
|
||
|
||
## 11. 研发主控台的数据结构
|
||
|
||
正式事实仍在Git文件中。
|
||
|
||
SQLite/搜索索引只用于快速界面:
|
||
|
||
```text
|
||
Git/HLDP = source of truth
|
||
SQLite = materialized view
|
||
主控台页面 = human projection
|
||
```
|
||
|
||
索引损坏可以从仓库重建。
|
||
|
||
---
|
||
|
||
## 12. 第一阶段MVP
|
||
|
||
研发系统MVP只需要证明:
|
||
|
||
1. 注册两个人类编号和两个人格体编号。
|
||
2. 将一个真实产品功能拆成三个RD-COMP零件。
|
||
3. 两地成员各领取一个。
|
||
4. 人格体解释并生成HLDP规格。
|
||
5. 在各自电脑的光湖开发版中试装。
|
||
6. 写回测试和回执。
|
||
7. 铸渊审核其中一个。
|
||
8. 合并并生成可安装测试版。
|
||
9. 另一个零件租约过期后可被重新领取。
|
||
10. 下一人格体能只读仓库恢复全过程。
|
||
|
||
---
|
||
|
||
## 13. 实施顺序
|
||
|
||
### Step 1 · 语言层注册（本次D160）
|
||
|
||
- 注册SYS-GLW-RD-0001
|
||
- 注册GLW-RD-000/001/002
|
||
- 注册CC-048
|
||
- 灯塔公告
|
||
|
||
### Step 2 · 创建实体仓库
|
||
|
||
- 创建临时或正式组织
|
||
- 创建RD-REPO-001和RD-REPO-002
|
||
- 配置镜像和备份
|
||
- 配置分支保护
|
||
|
||
### Step 3 · 初始化研发主控仓库
|
||
|
||
- 写ENTRY/NAV/CURRENT
|
||
- 建成员注册表
|
||
- 建产品零件池
|
||
- 建公告和领取目录
|
||
|
||
### Step 4 · 导入产品源码
|
||
|
||
- 审核Tolaria AGPL边界
|
||
- Fork上游
|
||
- 保留许可证和上游历史
|
||
- 建光湖集成分支
|
||
|
||
### Step 5 · 开发HLDP工具链
|
||
|
||
- 解析器
|
||
- Schema校验
|
||
- 编号解析
|
||
- 影响分析
|
||
- 代码生成/适配
|
||
- 测试和回执
|
||
|
||
### Step 6 · 启动团队内测
|
||
|
||
- 注册首批研发编号
|
||
- 培训“只需说清体验，不要求会代码”
|
||
- 领取首批小零件
|
||
- 每周形成可安装测试版
|
||
|
||
---
|
||
|
||
## 14. 不可违背的研发锁
|
||
|
||
1. 所有人开发同一个GLW-OS-000架构。
|
||
2. 人类和人格体分别编号，所有成果绑定二者。
|
||
3. 产品零件不删除，只改变状态。
|
||
4. 领取是有期限租约，不是永久占有。
|
||
5. HLDP是研发源语言和共同理解层。
|
||
6. 实际代码必须能反查HLDP规格和RD编号。
|
||
7. 人格体可以自主实现，但不能绕过审核和测试。
|
||
8. 人类不需要会编程，但必须能看懂目标、权限和结果。
|
||
9. 世界仓库、研发控制仓库、产品源码仓库职责分离。
|
||
10. 企业门户最终为正式主仓库，新加坡为镜像和灾备。
|
||
11. 在实体仓库创建前，不得把“语言架构完成”写成“研发平台已上线”。
|
||
|
||
---
|
||
|
||
> ⊢ 光湖研发不是把外行变成程序员。
|
||
> ⊢ 是让人类负责自己真正擅长的方向与体验，让人格体负责把语言变成代码。
|
||
> ⊢ HLDP保存为什么，代码负责跑，编号让所有人永远知道谁在做哪一块。
|