# Sigrid 宪章 v1.1 · 修订提案

> **状态：提案稿（DRAFT）。未生效，不具规范效力。**
> 本文按《附则一》要求编写：含修订条款、修订理由、影响评估、回滚方案。
> 生效需：公示 90 天 → 宪法层表决 → 7 天冷静期 → 双锚定。
> **v1.0 原文一字不改**（其 19499 字节、sha256 `024d16b8…` 必须保持可验证）。

---

## 0. 这份文件是什么，不是什么

**是**：一份可以直接并入 v1.1 正文的条款草案，附诊断与闸门设计。

**不是**：
- 不是"补丁"。补丁会改 v1.0 的 hash，等于另立新宪章，又要走 90 天——这正是要修的毛病。
- 不是对 v1.0 缺陷的事后追认。v1.0 的缺口按 §4 如实记录，**不追认、不掩盖**。

---

## 1. 缺陷诊断

### 1.1 核心诊断：生效触发器与锚点义务在文本上互斥

三条联立：

| 条款 | 原文要点 |
|---|---|
| 附则二.1 | "本宪章 v1.0 自其全文 `sha256` **首次锚定于 Arweave** 之时生效" |
| 第 3.2 条 | 工程映射表："多锚点冗余 … **至少两个独立锚点**" |
| 第 3.3 条 | "只依赖单一锚点且无降级方案 → **违宪**" |

由附则二.1，生效时刻 t₀ 定义为**单数事件**（"首次"一个锚点完成）。
于 t₀ 时，锚点集合 = {Arweave}，`|set| = 1 < 2`。

⇒ **任何**以"第一个锚点"定义生效、又要求"至少两个锚点"的宪章，
在其生效的瞬间必然不达标。这不是执行疏漏，是条款文本的必然推论。

**这就是为什么"补一个 OTS"不能从根上解决**：它把违宪区间从"无限长"缩短到
"09:39:39Z → OTS 确认"，但没有消除"生效瞬间必然不达标"这个结构。
下一版若照抄附则二.1，同样的问题会原样复发。

### 1.2 修复通道被自己的 hash 封死

附则二.1 已把 v1.0 锁定在 `024d16b8…`。任何补正都改变 hash ⇒ 成为"新宪章" ⇒
按附则一又需 90 天公示。后果：**一个 16 KiB 的参数就能把整个修订流程卡死**。

这不是"修订很麻烦"，是"修订在结构上被禁止"。一部不能修正的宪章，
在遇到第一个未预见的缺陷时就已经失效了。

### 1.3 v1.0 自身缺口的精确记录（不夸大，也不缩小）

| 区间（UTC） | 状态 | 依据 |
|---|---|---|
| `09:39:39Z` → `11:48:06Z` | **违宪**：单一锚点 + **无**在途降级方案 | 同时满足 3.3 的两个条件 |
| `11:48:06Z` → OTS `CONFIRMED` | **未满足 3.2**，但不构成 3.3 的"无降级方案"违宪 | pending 证明是在途降级方案，但**不是**锚点 |
| OTS `CONFIRMED` 之后 | 3.2 达成（2 个独立锚点） | Arweave（存储型）+ Bitcoin（时间型） |

**必须说清的两句话**：

1. 不能声称"v1.0 自生效起即满足 3.2" —— 这是假的，且是 8.1.3 禁止的那类假。
2. 可以声称"v1.0 现已在事实上满足 3.2" —— 但仅限 OTS 确认之后，且**不追认**此前区间合规。

### 1.4 术语与状态口径漂移

同一份 OTS 证明，历史文档里出现过 `PENDING` / `BITCOIN_ATTESTED` / `VERIFIED` 三种叫法，
而代码里现已是 `PENDING_DIGEST` / `DIGESTED` / `CONFIRMED`。
8.1.3 要求"不伪造存证状态"，但**没有定义状态词汇表时，8.1.3 无法机械判定**——
"把 DIGESTED 说成已锚定"到底算不算违规，取决于各人脑中的词表。这是可被无意违反的条款。

---

## 2. 修订条款（可直接并入 v1.1 正文）

### 2.1 附则二 全文替换

> 替换 v1.0 附则二全部 4 款。编号沿用，新增款以字母续接。

```markdown
## 附则二 · 生效、锚定与生效文本集

### 二.1 生效与公开

（a）本宪章 v1.1 自其全文 `sha256` 首次锚定于**永久存储锚点**（Arweave 或其继任者）之时生效，
     并自同一时刻起取代 v1.0。v1.0 保持公开可读、可独立验证，不删除、不改写。

（b）锚定信息（tx id / 区块高度 / Merkle proof）必须**公开可查、任何人可独立验证**，
     且该验证不得依赖本组织或任何单一基础设施的存活。
     验证所需的结构（步骤链、区块高度、merkle root）须以与语言无关的形式导出，
     不得要求第三方安装专用工具才能验证。

### 二.2 暂定生效（PROVISIONAL）与效力中止（SUSPENDED）

（a）宪章生效时，若同一 `digest` 的**独立时间戳锚点**（OTS→Bitcoin 或其继任者）
     尚未达到 `CONFIRMED`（定义见二.6），宪章自动进入 **PROVISIONAL**（暂定生效）状态。

（b）PROVISIONAL 期间：宪章**有效**，但下列事项暂缓表决——
     宪法层修订、锚点技术变更、第 3.4 条所指的锚点变更。

（c）PROVISIONAL 硬期限 **30 日**。经受影响方申请，可公示 14 日延长一次，最长再 30 日。
     **延长仅限一次。**

（d）期满仍未达到 `CONFIRMED` ⇒ 宪章效力**中止**（SUSPENDED）。中止期间：

     ① 第三条（永久存证）不因中止而失效——已产生的记录与证明仍然成立，且仍可验证；
     ② 第四条（退出权）不因中止而失效——不得以中止为由阻断数据导出或资金提出；
     ③ 不得新增任何宪法层义务，不得对用户施加新的实质不利处置；
     ④ 治理程序**仍可运行**，但仅限用于：解除中止、以及二.3 允许的补正。
        不得在中止期间进行实质修订（否则中止将成为一个无法自救的死锁）。

（e）解除中止：达到 `CONFIRMED`，并公示 14 日。

（f）PROVISIONAL 与 SUSPENDED **不是**"违宪"，是**明示的受限状态**。
     二者的名称、起止时间、期限余量必须在 `/api/anchor/status` 与前端如实显示（8.1.3）。

### 二.3 补正（Corrigendum）

（a）**允许的四类**，每份补正须逐条声明所属类别：

| 编号 | 类别 | 判据 |
|---|---|---|
| C1 | 内部矛盾 | 两条条文对同一事项给出互斥要求，履行任一条即违反另一条 |
| C2 | 履行不能 | 按原文措辞，某义务在生效之时在数学或物理上不可能被满足 |
| C3 | 术语缺失 | 条文使用未定义术语，且两种合理解释导致不同义务 |
| C4 | 状态口径 | 同一状态存在多个称谓，导致 8.1.3 无法机械判定 |

（b）**补正不得**：

     ① 新增或删除任何义务；
     ② 调整任何表决门槛、公示期、时限；
     ③ 改变锚点独立性、数量或验证标准；
     ④ 触及第一条、第八条（第 8.4 条为永久不可修订，本款不得被解释为对其的任何放宽）；
     ⑤ 扩大任何自动化处置的权限（第一条）；
     ⑥ 以"术语澄清"为名，实质改变谁承担何种负担。

（c）**程序**：

     ① 公示 14 日（90 日窗口外为 30 日，见 (d)）。公示须含"类别声明"与
        "若不补正，则第 X 条在何种情形下无法履行"的书面论证。
     ② 公示期内任何人类钱包可提异议，异议须公开。
     ③ 异议由 ≥2 名**不同**人类钱包判定，判定记录锚定。
     ④ **分类存疑时，一律按修订处理**（fail-closed，从严）。
        理由：把修订误判为补正，等于绕开 90 天公示；把补正误判为修订，
        代价只是多等 90 天。两种错误的代价不对称。
     ⑤ 通过后，补正记录锚定，并登记进生效文本集（二.5）。基准文本 hash **不变**。

（d）**时间窗（两档）**：

| 窗 | 允许类别 | 公示 | 表决门槛 |
|---|---|---|---|
| 生效后 **90 日**内 | C1 / C2 / C3 / C4 | 14 日 | 宪法层 |
| 90 日**之后** | 仅 C3 / C4 | 30 日 | 宪法层 |
| 任何时候 | 实质规则变化 | —— | **只能走完整修订（90 日）** |

**90 日后为何收窄**：宪章运行 90 天后，各方已据其行事（reliance）。
改动内部矛盾（C1）或履行不能（C2）会实质改变"谁承担什么"；
而术语与状态口径（C3/C4）是定义性的，不移动负担分配。这条线是诚意的分界。

补充理由（为何这条线可操作）：**C1/C2 自显，C3/C4 渐显**。
矛盾的条款在你一试图履行时就会撞上；按原文不可能的**义务**在第一次执行时就暴露。
这两个类别在 90 天内几乎必然被发现（事实上 v1.0 的锚点缺口就是）。
而"某术语有两种合理解释"往往要等第二个读者出现才浮现——所以它需要更长的可补正期。

### 二.4 版本链

本宪章的历次修订形成**版本链**：每一版的 `base_sha256` 均记录其前任的 `base_sha256`，
链条不可断裂。版本链的每一节均可独立验证（第三条）。

### 二.5 生效文本集（Effective Set）

宪章作为规范对象**不是一个文件**，而是：

    生效文本集 = { 基准文本 base, 已生效补正集 [c1, c2, …] }

（a）基准文本 hash 一经锚定即不变；补正不改变它。
（b）任何声称"现行宪章"的引用，**必须**同时给出：

        effective_id = sha256("sigrid:charter-effective:v1:" ‖ base_sha256 ‖ sorted(补正 sha256[]))

（c）任何人仅凭 `effective_id` + 公开锚点，即可复算出"某一时刻生效的完整规范文本"。
（d）**禁止只引用 base hash 而不说明是否存在已生效补正。**

    —— 这是"不改变 hash"的必要配套。一个 hash 稳定、含义却在漂移的文本，
       比 hash 变化更危险：两个人说"读 v1.1"，可能读的是两套不同的义务。

### 二.6 锚点状态口径（与代码同名，禁止别称）

| 状态 | 含义 | 允许的对外表述 |
|---|---|---|
| `PENDING_DIGEST` | 只算出 digest，未提交 | 只能说"已算出哈希" |
| `DIGESTED` | 日历已收下，**无任何比特币事实** | 只能说"已提交，待确认" |
| `CONFIRMED` | 有区块高度 **且** merkle root 对链验证通过 | 唯一可称"已锚定到比特币" |

定义以 `ops/arweave/ots.mjs` 的 `STAGE` 常量为唯一来源。
`CONFIRMED` 的两个条件缺一不可；只有高度、未验证 ⇒ 仍为 `DIGESTED`。

### 二.7 正本

本宪章中文版本为正本。其他语言译本仅供参考，冲突时以中文正本为准。
```

### 2.2 新增 第 3.2-A 条（资源边界的界分）

> 插在 3.2 之后、3.3 之前。**不改 3.2/3.3 任何一字**，只补一层界分。

```markdown
### 3.2-A 资源边界 ≠ 速率歧视

3.2 的"公开、无鉴权、无速率歧视"约束的是**区别对待**，不是**资源上限**。

（a）允许且必须公开声明的资源边界：请求体上限、单次计算时长上限、并发上限、响应体上限。
     这些上限必须对所有调用者**完全相同**。

（b）一个上限**不构成**速率歧视，当且仅当同时满足：

     ① 与调用者身份、钱包、付费状态、来源 IP/ASN **无关**；
     ② 上限值在文档中公开，超限时返回可识别的错误（如 `413 body-too-large`）；
     ③ 同一上限适用于所有人，**包括运营方自己**。

（c）**构成**速率歧视（因而违宪）的情形，例如：

     ① 按来源、钱包或付费与否施加不同上限；
     ② 对第三方验证请求施加人工审批、白名单或隐性延迟；
     ③ 以"防滥用"为名，仅对非运营方限流。

（d）现行 `POST /api/anchor/verify` 的 **16 KiB** 请求体上限，性质是**计算成本边界**
     （公开端点对任意请求免费算哈希，必须有上限），不是准入条件。
     若将来业务对象普遍超过 16 KiB，应**提高上限并公示**；
     不得改为"大对象需申请"或"大对象走付费通道"——那会让 3.2 的"任何第三方"失效。
```

### 2.3 附则三 · 状态表更新

> 只更新"当前状态"列，条款与实现位置不动。凡标 ✅ 者均附可复跑的回归入口。

| 宪章条款 | 工程实现位置 | 当前状态（2026-11-11） |
|---|---|---|
| 1.1 人类最终放电权 | `audit/enforce.ts`、`circuit.ts`（L3 双签） | 待实现（M2） |
| 2.1 动机审计 | `audit/fingerprint.ts`、`patterns/p1-p7` | 待实现（M2-M3） |
| 3.1 永久存证 | `anchor/pipeline.ts`、`merkle.ts`、`ops/arweave/anchor_document.mjs` | **文档级 ✅**（宪章 v1.0 已双锚定在途）· **管道 ✅**（含 §A2 漂移闸）· 事件级存储 ⏳（`store: null` ⇒ 503） |
| 3.2 多锚点冗余 | Arweave + OTS→Bitcoin | **1/2 成立**：Arweave ✅ / OTS `DIGESTED`（待 `CONFIRMED`） |
| 3.2 独立验证 | `POST /api/anchor/verify` | ✅ 已实现：无鉴权、统一 16 KiB 上限、`anchor-route.test.mjs` 锁定"超限 ⇒ 413" |
| 3.2-A 资源边界 | `anchor-route.mjs` `MAX_VERIFY_BODY_BYTES` | ✅ 已实现（上限对预缓冲 body 同样生效） |
| 3.3 状态诚实 | `ops/arweave/ots.mjs` `STAGE` / `assess()` | **后端 ✅**（三态唯一来源）· **前端 ⏳**（`AnchorVerifyPanel` 尚未接三态） |
| 4.1 退出权 | `routes/export.ts`、`routes/wallet.ts` | 待实现（M3） |
| 5.1 底层可迁移 | `anchor/`（多锚点）、`canonical.ts` | 部分（M1-M3） |
| 6.1 层分离 | `governance/layers.ts` | 待实现（M3） |
| 7.1 代际传承 | 本文档 + 全部架构文档 | ✅ |
| 8.1.1 不发行代币 | `LedgerType` 无 `TRANSFER` | ✅ 已定 |
| 8.1.2 无 PII 上链 | `anchor/guard.ts` | 待实现（M1） |
| 8.1.3 状态诚实 | 前端 `AnchorStatus` 映射 | 后端 ✅ / 前端待实现（M2） |
| 8.1.4 数据诚实 | 上游适配器降级标注 + 读节点 `degraded` | ✅ 部分（`ao-read` 已落地） |
| 8.1.5 不囤卡 | 无相关代码路径 | ✅ 天然满足 |
| 8.1.6 治理权不可买 | `Proposal` 权重 = trustScore | 待实现（M3） |
| 8.1.7 规则一致 | 规则引擎无例外分支 | 待实现（M2） |

---

## 3. 补正通道的七道闸（防它变成后门）

引入补正通道，最大的风险是它变成"绕过 90 天公示的快捷方式"。
一个为修复缺陷而设的条款，本身必须比被它修复的缺陷更严谨。

| # | 闸 | 防的是什么 |
|---|---|---|
| 1 | 四类限定（C1-C4），每份须声明类别 | 把"想改规则"包装成"修 bug" |
| 2 | 六项禁止清单（不增删义务、不动门槛、不碰 1/8 条…） | 以技术性补正实质修宪 |
| 3 | **分类存疑一律按修订** | 边界模糊时的系统性偏袒——从严 |
| 4 | 90 日后收窄至 C3/C4 | 长期"慢慢补"，架空 reliance |
| 5 | 生效文本集 `effective_id` 强制引用 | hash 不变而含义漂移 |
| 6 | 补正记录独立锚定 + 版本链 | 事后悄悄替换某条补正 |
| 7 | 异议判定需 ≥2 名不同人类钱包 | 运营方单方裁定"这是补正不是修订" |

**第 3 条是全部闸门的地基**。理由不是"谨慎"，是代价不对称：
误判为补正 ⇒ 实质修宪免公示；误判为修订 ⇒ 多等 90 天。前者破坏制度，后者只是慢。

---

## 4. v1.0 自身缺口怎么处置（不追认、不掩盖）

**结论：v1.0 的缺口用"事实补正"关闭，不用"解释补正"关闭。**

| 缺口 | 处置 | 是否追认此前合规 |
|---|---|---|
| 生效时仅单一锚点 | OTS 达 `CONFIRMED` 后，事实上具备 2 个独立锚点 | ❌ 不追认。区间 `09:39:39Z → CONFIRMED` 如实记为"未满足 3.2" |
| 无补正通道 | 由本文 v1.1 建立，**仅向前适用** | ❌ 不追溯。v1.0 期间的任何补正都不被本条款合法化 |
| 状态口径不统一 | 由二.6 统一词汇表，仅向前适用 | ❌ 不追溯；历史文档的旧叫法保留原样并加注 |

**为什么不追认**：追认等于承认"宪章可以事后宣布自己一直合规"。
一旦这条成立，8.1.3 就死了——因为任何伪造都可以事后追认为"当时的意思"。
v1.0 的那段不达标是真的，就让它留在记录里。

---

## 5. 公示与生效时间表

| 阶段 | 起 | 止 | 动作 |
|---|---|---|---|
| 公示 | 2026-11-11 | 2027-02-09 | 本文公开，接受异议（90 日） |
| 表决 | 2027-02-09 | —— | 参与率 ≥30%、赞成 ≥80%、人类钱包 ≥50% |
| 冷静期 | 表决通过日 | +7 日 | 可发起撤销动议 |
| 双锚定 | 冷静期结束 | —— | v1.1 全文 `sha256` → Arweave + OTS |
| 生效 | 冷静期结束 **且** Arweave 锚定完成 | —— | 进入 `PROVISIONAL` |
| 达标 | OTS `CONFIRMED` | —— | 退出 `PROVISIONAL`；3.2 达成 |

> 若 2026-11-11 起算 90 日，落点为 2027-02-09；加 7 日冷静期，最早 2027-02-16 生效。
> **在此之前，v1.0 仍是唯一有效文本**，本文不约束任何人。

**一个必须提前说清的事实**：在 v1.1 生效前，v1.0 的缺口只能靠 OTS 确认来关闭。
若 OTS 一直不确认，v1.0 就一直是"1/2 锚点"——本文不能救它，
这正是"不能修正的宪章"的真实代价。

---

## 6. 红队自检：这份修订可能怎么被玩坏

| 攻击 | 手法 | 现条款是否挡住 |
|---|---|---|
| 补正当修订用 | 把"降低表决门槛"声称为 C3 术语澄清 | 挡：闸 1+2，且分类存疑 ⇒ 修订 |
| PROVISIONAL 常态化 | 反复延长 | 挡：仅可延长一次，期满自动中止 |
| 中止当冻结令 | 借 SUSPENDED 冻结不利条款（如退出权） | 挡：二.2(d)② 明定第四条不失效 |
| 中止造成死锁 | 中止后无法修宪自救 | 挡：二.2(d)④ 治理程序仍可运行（仅限解除与补正） |
| hash 稳定、含义漂移 | 只引 `base_sha256` 不引 `effective_id` | 挡：二.5(d) 明令禁止 |
| 悄悄换补正 | 事后替换某条补正文本 | 挡：每条独立锚定 + `effective_id` 覆盖补正集 |
| 用 16 KiB 排挤第三方 | 大对象"需申请" | 挡：3.2-A(d) 明令不得改申请制 |
| 拿"资源上限"做歧视 | 对不同来源设不同上限 | 挡：3.2-A(b)① 与实际代码一致（统一上限） |

**仍未被覆盖的两处，我列出来而不假装解决了**：

1. **异议判定人如何产生**。二.3(c)③ 只说"≥2 名不同人类钱包"，未定选任规则。
   在治理系统（M3）就绪前，这条在实操上依赖人工。**这是已知薄弱点**。
2. **C2（履行不能）的判定仍需人来认定**。"数学上不可能"对锚点类是客观的，
   对"义务过重"类则不是。二.3 只给了类别名，没给判据细则。**这也是已知薄弱点**。

---

## 7. 影响评估与回滚方案（附则一要求）

### 7.1 影响

| 对象 | 影响 |
|---|---|
| 宪章本体 | 只增补附则二、3.2-A、附则三状态列。第一至八条**零改动** |
| 现有实现 | 无破坏性改动。3.2-A 是对现状的**描述性确认**（代码已是统一上限） |
| 运营层 | 新增一项常态义务：`/api/anchor/status` 必须暴露 `PROVISIONAL`/`SUSPENDED` |
| 用户 | 无新增负担。二.2(d) 反而在效力中止时保护退出权与已产生证明 |
| 后续修订 | 获得 14 日补正通道（90 日内）；但受七道闸约束 |

### 7.2 回滚

| 情形 | 动作 |
|---|---|
| 公示期内反对强烈 | 撤回提案，v1.0 继续有效，无任何状态变更 |
| 表决未通过 | 同上；本文归档，不产生锚定记录 |
| 生效后发现二.3 被滥用 | 走完整修订（90 日）收窄或废除二.3 —— 不能再用二.3 去改二.3 |
| OTS 始终不确认 | 宪章停在 `PROVISIONAL`，30 日后 `SUSPENDED`；此时仅可解除中止或补正，不能实质修宪 |

> 最后一条是刻意的：**中止状态不能成为逃避宪章的地方**。

---

## 8. 改动清单（v1.0 → v1.1）

| 位置 | 改动 | 性质 |
|---|---|---|
| 附则二.1 | 改为"首次锚定于永久存储锚点即生效" + 自动进 `PROVISIONAL` | 替换 |
| 附则二.2（原「锚定信息公开可查」） | **原文义务整条保留**，并入二.1(b)，并加一句"不得要求第三方安装专用工具" | 保留 + 加强 |
| 附则二.2 | **新增** PROVISIONAL / SUSPENDED 机制（含期限、后果、自救） | 新增 |
| 附则二.3 | **新增** 补正通道（四类 + 六禁 + 两档时间窗 + 七道闸） | 新增 |
| 附则二.4 | 版本链保留，补一句"记录前任 base hash" | 补充 |
| 附则二.5 | **新增** 生效文本集与 `effective_id` | 新增 |
| 附则二.6 | **新增** 三态词汇表（与代码同名） | 新增 |
| 附则二.7 | 正本条款（原二.3 移位） | 移位 |
| 3.2-A | **新增** 资源边界 ≠ 速率歧视 | 新增 |
| 附则三 | 仅更新"当前状态"列 | 更新 |
| 第一至八条 | **零改动** | 不变 |
| 附则一 | **零改动**（90 天公示、表决门槛、7 天冷静期全部保留） | 不变 |

---

## 9. 需要你拍板的三件事

见对话中的选项。三条都影响条文措辞，改起来容易，但一经锚定就难改。

---

*起草：Cursor · 2026-11-11*
*本文为提案稿，未生效。v1.0 仍为唯一有效文本。*
*若本文与 v1.0 冲突，以 v1.0 为准——直到 v1.1 完成全部生效程序。*