添加一条诊断规则：从发现故障模式到规则发布

规则库是 ConnProof 的心脏，往里加东西的门槛因此设得很清楚。这篇文档描述从"我发现了一类新故障"到"规则合并发布"的完整路径。

什么样的故障值得立规则

同时满足四条：

可复现：能用本地 fixture 或明确步骤稳定触发，不是一次性的玄学现象；
可判定：存在客观证据（错误码、状态码、时长模式）能把它与已有规则区分开；
有普遍性：不是某个客户端某个版本的孤立 bug（那应该报给客户端项目）；
未被覆盖：与现有 32 条规则的判定条件没有重叠——先搜错误库确认。

错误码分配

格式：分类-三位数字。分类从既有的 DNS/TCP/TLS/HTTP/WS/SUB/PROXY/SYS/ROUTE/LONG/CLIENT/REPORT 中选择；数字取该分类下一个未使用的编号，永不复用已发布过的编号（即使那条规则将来被废弃）。拿不准分类时在 Issue 里讨论，不要自创分类。

规则字段

规则定义在 packages/diagnostic-rules/src/rules/ 对应分类文件中，通过 defineRule 创建：

字段	要求
`code`	分配好的错误码，发布后不可变
`slug`	URL 友好、与文档文件名一致
`title` / `rawError`	用户真实看到的英文报错原文
`summary`	一句话中文结论，说清发生了什么
`severity`	info/low/medium/high/critical，按影响与紧急度
`likelyCauses`	至少两条，按概率排序
`recommendedActions`	至少两条，每条可执行
`applicablePlatforms`	只列真正适用的平台
`lastVerified`	你验证内容的日期（YYYY-MM-DD）
`ruleVersion`	新规则从 1 开始

docPath 不用写——由 slug 自动推导为 /errors/<slug>。

三件配套物，缺一不可

1. 检测逻辑（如适用）：如果规则需要 diagnostic-core 新增判定（比如新的错误分类映射），在对应检测器中添加，保持"证据 → 规则码"的映射清晰可读。

2. 文档页：docs/errors/<slug>.md，遵循错误页统一模板（结论前置、QuickConclusion/ApplicabilityBox/VerificationStamp 组件、分平台步骤、证据对照表），正文不少于 1400 个中文字符，且必须针对该错误设计——不是换个标题的模板复制。frontmatter 的 errorCode、severity、lastVerified 必须与规则逐字段一致（校验脚本会检查）。

3. 测试：规则库测试自动覆盖结构完整性（参数化遍历全部规则）；判定逻辑的测试放在 diagnostic-core，用 test-fixtures 的本地服务器构造触发场景——不允许依赖公网服务。

提交前自查

bash

pnpm lint && pnpm typecheck && pnpm test
pnpm validate:rules
pnpm validate:docs

三组命令全绿再提 PR。PR 描述里附上：触发场景的复现方法、你在哪些环境验证过、以及与相邻规则的区分依据。

内容红线

规则的 causes/actions 与配套文档必须遵守项目的表达规范：区分确定事实与需验证的猜测（"更可能是""仍需确认"而不是"一定是"）；不出现虚构数据；不提供绕过安全控制的方法。触碰红线的内容无论技术质量如何都不会合并。

添加一条诊断规则：从发现故障模式到规则发布 ​

什么样的故障值得立规则 ​

错误码分配 ​

规则字段 ​

三件配套物，缺一不可 ​

提交前自查 ​

内容红线 ​