## HDGP 项目治理草案（GOVERNANCE） 本文件描述 HDGP 治理体系的**角色分工、决策流程与变更管理原则**。 本治理模型将随项目演进而调整，当前为 **Genesis 草案**。 --- ## 一、项目愿景与边界 - HDGP 项目致力于构建一个 **公开透明、可审计、可演化** 的厚德归朴（HDGP）公开技术基线实现。 - 项目治理的首要目标是： - **确保 HDGP 的核心价值与规则不被悄然稀释或篡改**； - **同时允许在公开透明的前提下进行充分讨论与实验**。 治理层不直接干预各个下游应用怎么使用 HDGP，但会对以下方面负责： - 官方规范（Spec）的版本管理； - 官方参考实现（Implementation）的方向与质量； - “HDGP 认证 / 标识”的授予与撤销。 --- ## 二、角色与职责 > 角色可由具体个人或团队承担，未来可扩展为多方组织共同参与。 ### 1. 项目发起人与创始守护者（Project Founder / Founding Guardian） - 在 Genesis 阶段承担以下职责： - 设定 HDGP 的初始愿景与价值边界； - 指定首批维护者与规则审计员； - 在涉及**元章程核心原则修改、品牌/商标授权政策、项目许可证变更**等重大事项时，作为**必要同意方之一**参与决策（非单独否决权，须与 §6 多层治理流程配合）。 - 随项目成熟，发起人的权限可以通过社区共识逐步下放或限制；具体表述见第六节与 `docs/CHIP_PROCESS.md`。 ### 2. 核心维护者（Core Maintainers） - 职责： - 维护代码仓库与 CI/CD 流程； - 对日常 PR 进行 Review 与合并； - 管理 Issue、规划 Roadmap； - 在不触及核心条款的前提下，演进实现细节与架构。 - 权限： - 可在通过 CI 与至少 1 名维护者 Review 的前提下，合并 PR 至主分支； - 可发起 Minor 版本发布（如 `1.1.0` → `1.2.0`）。 ### 3. 规则审计员（Policy Auditors） - 职责： - 专门审查涉及 `policies/`、`spec/`、伦理框架的变更； - 评估合规测试套件覆盖度与质量； - 审核“规则包（Policy Bundle）”的发布与签名申请。 - 权限： - 对任何“降低安全阈值 / 放宽限制”的变更拥有否决权； - 可要求为特定变更增加额外测试与审计。 ### 4. 认证委员会（Certification Committee，规划中） - 在生态阶段成立，成员可来自： - 不同机构的技术/伦理专家； - 学界/产业界代表。 - 职责： - 维护 HDGP 合规测试的基线与升级策略； - 审议“HDGP Certified / Compatible”标识的授予与撤销； - 处理与 HDGP 名称/品牌相关的争议。 ### 5. 普通贡献者与用户（Contributors / Users） - 任何人都可以： - 提 Issue 与 PR； - 讨论规范与实现； - 在遵守许可证的前提下 Fork 与衍生。 - 对于规范与核心规则的修改建议，将通过公开讨论与上述角色的正式流程处理。 --- ## 三、决策类型与流程 ### 1. 日常技术变更（实现层） 示例：代码重构、性能优化、新增适配器、修复 Bug 等。 - 流程： 1. 提交 Issue / PR； 2. 通过自动化测试与合规测试（如适用）； 3. 至少 1 名核心维护者 Review 通过； 4. 合并至主分支或特性分支。 - 这类变更**不需要**规则审计员或认证委员会介入。 ### 2. 规则与策略变更（Policy / Spec 变更） 示例：调整熔断阈值、增删某些允许/禁止行为、修改伦理优先级等。 - 流程： 1. 在 Issue 中以“提案（Proposal）”形式阐述变更动机与影响； 2. 标记 PR 为 `policy-change` 或 `spec-change`； 3. 通过自动化测试 + 合规测试； 4. 至少 1 名规则审计员 Review 并确认： - 未削弱人类尊严/最终决策优先的保护边界； - 或者削弱之处已在规范层明确记录并经充分讨论； 5. 对于重大变更，可能需要延长公开讨论期后再合并。 ### 3. 重大方向调整（价值观 / 核心条款） 示例：修改“人类意识不可量化”的表述；改变“人类永远高于系统”的优先级；项目许可证变更；品牌/商标授权政策的根本调整等。 - 流程建议： - 标记为“基线原则修订提案（CHIP）”； - 详细流程见 **`docs/CHIP_PROCESS.md`**（含自检、责任方、公告与高门槛）； - 设定不少于 30 天的意见征集期； - 至少需要以下**全部**方的明确同意（创始守护者为必要同意方之一，非单独决定）： - **创始守护者**（项目发起人或其指定接班人）； - 多名规则审计员； - 认证委员会（成立后）代表； - 且满足第六节多层治理（系统自检、责任方、公告与高门槛）的全部要求； - 对通过的变更生成**新版本规范**（如 `HDGP-1.1`），旧版本保留但标注为“不再推荐”。 --- ## 四、规则包与发行版的发布流程 > 具体细节会在实现阶段写入相应技术文档，这里描述治理侧约束。 ### 1. 候选版本生成 - 通过 CI/CD 从指定分支构建： - 守门人服务/网关的二进制或镜像； - 规则包（Policy Bundle）的压缩包； - 合规测试报告与变更摘要。 ### 2. 审计与签名 - 审计员检查： - 与上一版本相比，规则/行为的差异； - 合规测试是否全部通过，若未通过，原因是否被接受； - 是否存在明显风险增加而缺乏对等防护。 - 对通过审计的规则包与发行版： - 使用受控密钥进行签名（**须为多签**，不得由单一自然人独立完成）； - 生成公开可验证的签名与指纹。 ### 3. 公告与撤销 - 每个正式版本会： - 在 Release 页面与文档中公告； - 标明适用的 HDGP 规范版本； - 提供签名验证方式。 - 若后续发现严重问题： - 可发布“撤销声明（Revocation Notice）”； - 将版本标记为“不安全 / 不再推荐”，必要时添加到黑名单列表。 --- ## 五、冲突与上诉机制 - 对规范、实现或认证决定有重大异议时，建议流程： 1. 在公开 Issue 或讨论区陈述具体问题； 2. 请求相关角色（维护者 / 审计员 / 认证委员会）给出书面回应； 3. 如分歧无法解决，可提议召开线上公开会议或工作组讨论； 4. 最终结论与决议需记录在公开文档中。 - 项目不鼓励“私下协定更改规则而不公开记录”的行为，这会破坏 HDGP 的可信度。 --- ## 六、伦理与基线原则变更的多层治理（堵住“两人共谋”漏洞） 为避免任何个人或少数人（包括两名同等权限者共谋）滥用对 HDGP 伦理的影响力，**仅靠“至少两名具相应权限的自然人共同签署”不作为唯一门槛**。涉及基线原则条款（A）、伦理基线、关键规则（P/R/B）及规则包签名的变更，须经以下**多层设计**，且基线原则与伦理基线作为最原始 meta 层，修改门槛最高。详见 `spec/HDGP_ETHICS_BASELINE.md` 第八节。 ### 6.1 第一层：系统自检（不得违背自身伦理） - 变更提案在提交人类审议**之前**，须经**系统自检**：以当前已生效的 HDGP 伦理基线与基线原则为参照，评估拟议变更是否与之一致。 - **若自检结论为“拟议变更违背 HDGP 自身伦理”**：提案**挂起**，不得进入后续签署或表决；由**提案发起人**在限定时间内补充修正或撤销；挂起原因须记入伦理变更日志。 - 自检通过后，提案方可进入下一层。 ### 6.2 第二层：实际负责人与法律后果 - 涉及**关键规则**（P/R/B）及规则包签名的变更，必须指定**实际负责人**——能**承担法律后果的自然人**（或法定主体）；若变更生效后发生极端事件或严重后果，须有可追溯的责任方。 - 审议中须完成**风险与漏洞评估**；若存在未评估的重大风险或漏洞，须在责任方参与下**修补或缓释**后方可进入后续流程。 ### 6.3 第三层：基线原则与伦理基线——公告、时间窗与高通过门槛 对**基线原则条款与伦理基线**的修改，须同时满足： - **公告与时间窗**：须**公告至少一个事先约定的时间窗口**；**全球用户可同步收悉**（官方渠道、邮件列表等），并可在窗口内**提出反馈与异议**。 - **公众参与与高门槛**：时间窗结束后可组织反馈汇总，并可选择**全民公投或等效广泛表决**；**仅“投票过半”不足以保证通过**，须设定更高门槛（如超多数、双重多数等，由治理细则规定），以稳固已确定条款并规避突发添乱或刻意干扰。 ### 6.4 多签（必要但不充分） - 在满足 6.1–6.3 的前提下，上述变更及规则包签名仍须**至少两名具相应权限的自然人共同签署**，任何单人无权单独生效。多签为必要条件，但不替代自检、责任方与公告/高门槛机制。 ### 6.5 紧急变更与事后复核 - 重大安全紧急情况下可执行临时变更，但须在预设时间窗内（如 7 天）提交正式复核，并**补走自检与责任方/风险评估**；未通过则自动回退，保留完整审计记录。 ### 6.6 伦理 Changelog 与个人操作日志 - 伦理变更日志须记录：变更内容、理由、影响、提案人、**自检结论、责任方**、审议与表决记录、生效时间与版本号。 - 具治理权限者的操作（提案、评论、投票、签名）须可审计记录，与自动化行为区分。 ### 6.7 不垄断、内部不留祸根 - HDGP 不声称符合所有人意愿；任何人有权不采纳、不合作；未来会有更多协议形式，我们不垄断。 - **内部治理**中不得留下可被少数人共谋或单点滥用的漏洞；多层设计旨在使基线原则与伦理基线的演进可审计、可问责、可受人类社会监督。 --- ## 七、违规行为与问责机制 为保护 HDGP 的信誉与被治理者的权益，任何参与治理的成员如有以下情形，应承担相应责任： - 故意绕开既定流程私自修改伦理条款或规则； - 隐匿、删除或篡改与伦理/规则决策相关的审计记录； - 接受贿赂、施加或接受威胁，以影响 HDGP 的治理决策； - 利用其权限为特定组织/个人获取不当的规则豁免或放宽。 **处理原则**： - 一经发现，立即暂停其在 HDGP 项目中的治理与管理权限； - 视情节轻重，采取以下一项或多项措施： - 内部独立调查与公开说明； - 撤销其在项目中的头衔与角色； - 将相关证据移交有管辖权的司法或监管机构； - **无人例外**，不因其历史贡献或原有职务而豁免。 --- ## 八、未来演进 本治理草案本身也会经过社区实践与时间检验。 在未来可能出现的演进方向包括： - 建立独立的 HDGP 基金会 / 非营利组织，承担部分治理职责； - 引入更多元的国际成员参与规则审计与认证； - 探索使用链上/多签等技术记录重要治理决策； - **开源与商业化过渡**：项目未来可能建立独立的商业实体（如认证、托管、企业服务），与开源项目在法律与治理上**明确区隔**——开源项目（HDGP-Core）保持 MIT 与社区治理，商业化通过认证、商标授权与服务实现；具体安排将随项目演进另行公告，确保透明与可审计。 任何对本治理文档的修改建议，欢迎通过 Issue / PR 提出。