CGC Rough Consensus 议事办法（内部讨论稿）

cgc-github-rough-consensus-draft.md

@@ -0,0 +1,127 @@
+# Jouleverse Core CGC Rough Consensus 议事办法（内部讨论稿 v0.2）
+
+> 发起：教链（J-25）｜起草：小新｜日期：2026-08-25
+> 状态：**内部讨论稿**，供社区评议。成熟后拟正式化为 JEEP 提案（建议编号 JEEP-7），经 CGC 批准后施行。
+> 定位：JIP/JEEP 提案流程的操作细则——规定如何依托 GitHub 形成 rough consensus 并衔接 CGC 会议判定与执行。
+
+---
+
+## 0. 双轨治理架构与适用范围
+
+### 0.1 双轨治理架构
+
+Jouleverse 自创世起即采用**去中心化平行双轨治理**：Core（核心）与 Eco（生态）各自独立、互不隶属——core 不指挥 eco，eco 也不能强制 core。
+
+| | **Core（核心）** | **Eco（生态）** |
+|---|---|---|
+| 职责 | 建设和维护 Jouleverse 核心基础设施 | 生态的自由发展 |
+| 财政来源 | **core timelock** 释放的 J | **eco timelock** 释放的 J（创世定死，互不挪用） |
+| 共识机制 | **CGC rough consensus**（本办法） | **veJ 链上投票**（生态自决） |
+
+两轨的财政来源在创世时即已锁定，各自支撑各自的轨道；两轨的共识机制互不越界。本办法仅是 Core 轨的议事规则。
+
+### 0.2 适用范围
+
+**本办法仅适用于 Jouleverse Core 的事务。** Eco 事务一律由 veJ 链上投票实现生态自决，不属于本办法管辖；core 议事机制不得用于裁决 eco 事务，反之亦然。
+
+### 0.3 背景与原则（Core 轨）
+
+Jouleverse Core 的治理动作已天然发生在 GitHub 上：提案以 issue/PR 承载、评议在评论区、纪要归档于 open-meetings。本办法把"共识形成"的每一步也落到 GitHub 的可追溯载体上，借鉴 IETF rough consensus 精神：
+
+- **不是数票，而是检验是否存在未被回应的实质反对**
+- **一切表态和判定留痕，可追溯、可挑战**
+
+## 1. 四阶段流程
+
+每个议题 = 一个 GitHub issue（讨论与公示载体）+ 一个 PR（文档/执行载体）。
+
+### 1.1 阶段一：立案（Proposal）
+
+- 开 issue，使用统一模板：
+  - **动机**：要解决什么问题
+  - **方案**：具体怎么做
+  - **影响范围**：涉及哪些工作包/repo/人员/预算
+  - **执行清单**：通过后的行动项
+- 提案人须为 Core 贡献者，或经一名 Core 成员附议
+- 提案事项须属 Core 职责范围（核心基础设施的建设与维护）；Eco 事项请走 veJ 链上投票等生态自决路径，不在本流程立案
+- 加 label `status:proposal`
+
+### 1.2 阶段二：公示 / 温度检查（Temperature Check）
+
+- 最短公示期 **7 天**（自立案起算）；紧急事项可由轮值主持人缩短至 **72h**，但须在 issue 中说明紧急理由
+- 表态资格：**Core 成员绑定 Core ID（J-N 编号）表态**，构成判定依据；非 Core 社区成员可发表意见作为参考，但不构成程序性权利——其诉求应通过影响 Core 成员表达，或属于 Eco 事项的走 veJ 自决
+- 表态方式（在指定的 GitHub issue 或 PR 评论区**跟帖回复**，格式固定）：
+  - 赞成：`J-{CoreID} 赞成`，或英文 `J-{CoreID} ACK`
+  - 反对：`J-{CoreID} 反对`，或英文 `J-{CoreID} NACK` —— **反对必须同时写明理由，无实质理由的反对不计入考量**；陪审团行使「不计入」时须在纪要中写明理由（可被挑战），被剔除的反对者有权在下一次会议发起挑战（需一名 Core 附议）
+  - 疑问/保留：`J-{CoreID} 疑问/保留`（自由表述）
+  - 例：`J-25 反对：本条与创世双轨原则冲突，详见下述说明……`
+- **表态格式为本办法唯一权威格式**（`J-{CoreID} 赞成/ACK`、`J-{CoreID} 反对/NACK`），便于脚本/AI 自动生成公示期表态报告（谁反对、理由是否完整、是否被回应），为陪审团提供程序性参考
+- 公示期满，加 label `status:temperature-done`，进入上会议程队列
+
+### 1.3 阶段三：共识判定（Consensus Call）—— 上会集体判定
+
+> ## ⚠️ 特别说明（本质性界定，务必先读）
+>
+> 陪审团在 CGC 会上判定的对象，**仅仅是“GitHub 公示期的赞成/反对是否已形成 rough consensus”这一程序性问题**；而'''不是'''对提案本身的接受/拒绝作实质决定。
+>
+> 提案的实质内容与方向，由社区在 GitHub 公示阶段的讨论与表态决定。陪审团的角色只是核实共识的真实性——既防止少数声音被淹没，也防止刷屏式支持冒充共识。**陪审团永不触碰提案实质。**
+>
+> 陪审团职责限定为**程序完整性检查**：反对是否附理由、讨论线程中是否有人回应、回应后反对者是否撤回——只做程序性事实核查，**不评判回应本身有没有道理**。
+
+- 每周 CGC 会议设「共识判定」议程环节，由轮值主持人主持
+- **法定人数：出席（含主持人）≥ 3 人且为奇数**（避免平局）；不足法定人数时该议题顺延至下次会议。**回避时法定人数按实际可参与判定人数计**（出席人数 − 回避人数 ≥ 3 且为奇数），不足则顺延
+- 陪审团经讨论后仍无法形成一致判断时，可**直接以简单多数投票作出判决**，投票结果记入纪要——简单多数**仅用于解决陪审团内部对「共识状态」的程序性分歧**，不用于推翻公示期已成立的实质反对
+- **判定主体为参会人员集体（类似陪审团）**，而非主持人个人：
+  - 会上过一遍 issue 公示期的表态与反对理由
+  - 反对者如在场可陈述；其余参会人质询、讨论
+  - 集体形成判定，**主持人汇总宣判**
+- 判定分两步，均为程序性裁决：
+  **第一步·管辖权判定**：本事项是否属于 Core 轨（§0.2）？不属 → 判定 `invalid`（out of scope），issue 关闭归档并在纪要注明；若属 Eco 事项，同时注明"请走 veJ 链上投票路径"
+  **第二步·共识判定**（仅限通过管辖权的议题）：
+  1. **达成 rough consensus** —— 无实质反对，或反对已被充分回应 → `approved`，转 PR 执行
+  2. **达成但存异议** —— 存在不坚持的反对，异议全文记入纪要 → `approved-with-objections`，转 PR 执行
+  3. **未达成** —— 分歧实质无法弥合 → `not-concluded`，issue 关闭归档；提案人可自行修改后重新立案（新 issue 注明前案链接），但不构成任何承诺
+- **回避规则**：议题提案人担任当值主持人时，该议题由副主持/其他参会人主持判定（不自提自判）
+- 会议纪要在 open-meetings 定稿 merge 即为判定生效时点；时效与 WP-6/rev8 对齐（周二 18:00 前采纳、20:00 前定稿 PR），书记员对纪要 merge 负有职责，避免判定生效时间悬空
+- 判定后在原 issue 加 label：`invalid` / `approved` / `approved-with-objections` / `not-concluded`
+- **边界重申**：陪审团永不触碰提案实质内容；"未达成"即关闭，无"发回修改"这一判决类型——是否重报、如何修改由提案人自主决定
+
+### 1.4 阶段四：执行与归档（Execution & Archive）
+
+- 通过的议题转 PR 执行，merge 即落地
+- 结论摘要（议题、判定结果、异议记录链接）写入当月 CGC 纪要索引
+- 全程留痕链条：issue 表态 → 纪要判定 → PR merge → （如涉动账）链上 tx hash
+
+## 2. 关键设计点
+
+| 问题 | 规定 |
+|------|------|
+| 共识谁来判？ | 每周 CGC 会参会人员集体判定（陪审团式），轮值主持人主持，结论入纪要 |
+| 陪审团判什么？ | '''仅作两类程序裁决：①管辖权（是否属 Core 轨，不属则 invalidate）；②GitHub 公示是否达成 rough consensus。不对提案实质作接受/拒绝/发回决定''' |
+| 出席不足怎么办？ | 法定人数 ≥3 且为奇数（含主持人）；不足则顺延；僵持时简单多数投票判决 |
+| 未达成共识怎么算？ | `not-concluded`，issue 关闭归档；提案人可自行修改后重新立案（新 issue 注明前案），无"发回"判决 |
+| 判定不服怎么办？ | 可在下一次 CGC 会议挑战，需一名 Core 附议；挑战成功则发起重判 |
+| 权重怎么算？ | 公示阶段不计票数，看反对理由是否被回应；重大事项走链上 veJ 投票 |
+| 沉默怎么算？ | 默认不等于同意；Core 成员连续两个周期对进入判定的议题沉默，纪要点名提示 |
+| 防女巫 | 判定依据限于绑定 Core ID 的表态；非 Core 意见仅供参考 |
+| 时间效率 | 常规事项全流程约 7~14 天；label 标记进度，一目了然 |
+| Eco 事务怎么办？ | 不入本流程；一律走 veJ 链上投票生态自决，与本办法平行 |
+
+## 3. 与现有体系的关系
+
+- 本办法是 Core 的 JIP/JEEP 流程的**操作细则**，不改变提案类型划分
+- WP specs「三层把关」管工时统计核验，本办法管**决议形成**，互不冲突：规范修订类议题（如 WP specs rev9）走本办法形成决议；本办法通过后的执行工作量仍按 WP specs 三层把关统计——「管决议」与「管工时」边界清晰
+- **与 veJ 链上投票的关系（双轨界定）**：veJ 投票是 Eco 轨的自决机制，与本办法分属两个平行域，不存在"重大事项升级到链上投票"的跨轨关系。Core 轨内部如需正式表决（如涉及 core timelock 动账的规范修订），按 CGC 现行规则上会处理
+- 建议首个试点案例：jeeps 改名（JIP-6/JEEP-6）后续事项即用本办法跑一遍完整流程（jips/jeeps 属 core 治理基础设施）
+
+## 4. 开放问题（欢迎讨论）
+
+1. ~~陪审团判定是否有最低出席人数要求？~~ ✅ 已定：出席（含主持人）≥3 且为奇数；不足顺延；僵持时简单多数投票判决（§1.3）
+2. 「重大事项」清单：建议至少列最小清单（**资产动账、规范修订、Core 成员增减、节点质押相关**），其余交由主持人+参会人临场判断，并经 CGC 决议可增补
+3. 公示期 7 天是否合适？是否区分「常规」与「紧急」两档即可？
+4. ~~非 Core 社区成员的强烈反对是否构成升级条件？~~ ✅ 已定（§0.2/§1.2）：本办法仅辖 Core 事务，非 Core 表态无程序性权利，不构成升级条件
+5. 本办法自身的修订流程是否也走本办法？
+
+---
+
+*讨论稿 v0.2 · 小新 · 2026-08-27 · 征集意见中*