# 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 > 通用研发技能大脑: SK-DEV-001 > 桌面视觉见证器: GLW-VIS-000 > 认知链: 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. 下一人格体通过回执完整恢复。 ### 8.1 人类可见最小增量锁 产品可见开发必须额外执行 `SK-DEV-001`: ```text RD-TASK完整目标 → 拆成多个RD-VSTEP人类可见步骤 → 每个RD-VSTEP下面再拆RD-ISTEP内部技术任务 → 内部开发/测试/安全审核 → 安装到真实桌面软件 → GLW-VIS-000生成RD-EVD → 人类只体验可见功能并选择符合预期/需要修改 → 通过后解锁下一RD-VSTEP ``` 人类不验收代码和内部实现。 人类看到的是“软件真实长到了第几步”。 --- ## 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保存为什么，代码负责跑，编号让所有人永远知道谁在做哪一块。