feat: dco — add DCO audit benchmark lesson with 3-scheme comparison

lessons/dco-check-hook-audit-benchmark.md

@@ -0,0 +1,109 @@
+---
+{"title": "DCO 校验钩子对抗审计 — 三种方案极限测试与选型建议", "domain": "devops", "tags": ["dco", "signed-off-by", "pre-commit", "quality-gate", "audit", "benchmark", "pygrep"], "status": "published", "source": "gleam", "created": "2026-06-14 00:00:00 UTC", "updated": "2026-06-14 00:00:00 UTC"}
+---
+
+## 背景
+
+MisakaNet 的 DCO（Developer Certificate of Origin）质量门使用自研的 `pre-commit-dco` 钩子。此前开发者向官方 `pre-commit-hooks` 提交 PR #1262 贡献原生 check-dco 钩子，但被维护者以"可以通过 pygrep 实现，无需编写代码"为由拒绝。
+
+我们需要回答一个核心问题：**官方维护者的"pygrep 替代论"在技术上是否成立？自研 DCO 钩子是否必要？**
+
+## 测试方案
+
+对三种 DCO 校验方案进行极限对比测试：
+
+| 方案 | 来源 | 实现方式 | 对应立场 |
+|------|------|----------|----------|
+| 方案 A | 官方推荐 | pygrep 原生正则 `grep -E '^Signed-off-by:'` | "不用写代码" |
+| 方案 B | PR #1262 | Python re 逐行匹配 + malformed 检测 | "需要精细化校验" |
+| 方案 C | MisakaNet 自研 | Ikalus1988/pre-commit-dco | "独立自研" |
+
+### 5 种边界 case
+
+| # | 边界类型 | 测试点 |
+|---|----------|--------|
+| 1 | 多重签名 | 一行多个 Signed-off-by / 多行链式背书 |
+| 2 | 非标准邮箱 | 无尖括号 / + 标签 / 多级域名 |
+| 3 | 无空行分隔 | 正文紧接签名 |
+| 4 | Unicode 姓名 | 中文 / 日文 / 特殊字符 |
+| 5 | 空提交信息 | 只有签名 / 完全空 |
+
+## 测试结果
+
+### 核心指标
+
+| 指标 | 方案A pygrep | 方案B PR#1262 | 方案C 自研 |
+|------|-------------|---------------|------------|
+| **准确率** | 81.8% | **100.0%** | 90.9% |
+| 精准率 | 80.0% | 100.0% | 88.9% |
+| 召回率 | 100.0% | 100.0% | 100.0% |
+| **误报率** | **66.7%** | **0.0%** | 33.3% |
+| 平均耗时 | 1.96 μs | 2.24 μs | 1.46 μs |
+
+### 错误明细
+
+| 方案 | 错误用例 | 错误类型 | 严重程度 |
+|------|----------|----------|----------|
+| pygrep | 一行多个签名 | 误报（漏拒） | 高 |
+| pygrep | 邮箱无尖括号 | 误报（漏拒） | 高 |
+| 自研 | 一行多个签名 | 误报（漏拒） | 中 |
+| PR#1262 | 无 | - | - |
+
+## 结论
+
+### 1. pygrep 替代论完全不成立
+
+pygrep 误报率高达 **66.7%**，每 3 个不合规签名就放过 2 个。对于具有法律追溯意义的 DCO 校验，这是不可接受的。
+
+**结论：DCO 校验确实需要专门的代码，pygrep 不够用。**
+
+### 2. 自研方向正确
+
+既然 pygrep 不行，自研就是必要的：
+- 技术必要性：pygrep 质量闸门形同虚设
+- 供应链安全：上游拒绝合入后，独立仓库确保可控
+- 定制化空间：可根据 Ring 分层治理做定制增强
+
+### 3. 自研实现有改进空间
+
+当前自研准确率 90.9%，低于 PR #1262 的 100%。主要差距在"一行多签名"场景。
+
+**根因**：使用 `re.MULTILINE` + `findall` + 非贪婪匹配，在一行多签名时正则回溯导致解析错误。
+
+## 修复建议
+
+### 高优先级
+
+修复"一行多签名" bug，参考 PR #1262 的逐行匹配架构：
+
+```python
+DCO_PATTERN = re.compile(
+    r'^Signed-off-by:\s+'
+    r'(?P<name>[^<\n]+)'
+    r'\s+<(?P<email>[^>]+)>'
+    r'\s*$',
+)
+```
+
+### 中优先级
+
+- 增加 malformed 检测，格式错误时提示具体行号
+- 补充 5 类边界 case 的单元测试
+- 邮箱格式增加 @ 符号校验
+
+## 验证
+
+运行基准测试脚本，确认准确率 ≥ 95%：
+
+```bash
+python3 scripts/test_dco_benchmark.py
+```
+
+期望输出：方案 C 准确率提升至 95% 以上。
+
+## 关联
+
+- 配套工具：`scripts/test_dco_benchmark.py`
+- 白皮书：`docs/audit/dco-whitepaper.md`
+- CI 工作流：`.github/workflows/dco-check.yml`
+- 协议配置：`misaka-protocol.json` → `dco` 段