universal-dev-standards 5.17.0 → 6.1.0

package/bundled/locales/zh-CN/core/secure-op.md

@@ -0,0 +1,328 @@
+---
+source: ../../../core/secure-op.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-06-10
+source_hash: 7ef0c2e3a2c2
+status: current
+---
+
+# Secure-Op：AI Agent 安全操作标准
+
+> **语言**: [繁體中文（原文）](../../../core/secure-op.md) | [繁體中文](../../zh-TW/core/secure-op.md) | 简体中文
+
+**版本**：1.0.0
+**最后更新**：2026-05-04
+**适用范围**：所有部署 AI Agent 的系统
+**范围**：AI Agent 安全操作
+**行业标准**：ISO/IEC 27001:2022、NIST SP 800-207、OWASP LLM Top 10 2025
+
+---
+
+## 标准概述
+
+**Secure-Op** 是针对 AI Agent 系统的安全操作方法论，定义 AI Agent 在执行高风险操作时必须遵循的六大安全支柱。
+
+本标准源自 External Guardian OPA Sidecar reference implementation (XSPEC-146 from an external project)的实现经验，并沉淀为通用 UDS 标准，供任何采用 UDS 的 AI Agent 系统应用。
+
+### 核心理念
+
+传统软件安全假设操作主体是人类用户。AI Agent 系统带来新的威胁模型：
+- **Agent 可能被提示注入（Prompt Injection）操控**，伪装成合法操作
+- **LLM 推理不确定性**，相同输入可能产生不同决策
+- **操作范围不可预测**，一个指令可能触发连锁副作用
+
+Secure-Op 的回应是：**确定性系统守护边界，概率性系统只做辅助**。
+
+---
+
+## 六大支柱
+
+### 支柱一：Veto-Based Decision（否决式决策）
+
+决策逻辑必须以「否决权」为基础，不得使用投票制。
+
+#### 核心原则
+
+| 原则 | 说明 |
+|------|------|
+| Deterministic > Probabilistic | 确定性系统（Policy Engine、Rule Engine）的决策优先于 LLM 推理 |
+| Policy-as-Code | 所有安全规则必须版本控制，可回归测试 |
+| 否决即终止 | 任一层 DENY 即立刻终止管道，不继续下一层 |
+
+#### 决策管道（Decision Pipeline）
+
+```
+输入操作请求
+     │
+     ▼
+[M1] Prompt Injection 检测
+     │ DENY → 终止
+     ▼
+[M2] Policy Engine（OPA / Rule Engine）
+     │ DENY → 终止
+     ▼
+[M3] SOBR 风险评分
+     │ ≥76 → DENY；51-75 → HITL；≤50 → 继续
+     ▼
+[M4] Semantic Review（可选，LLM）
+     │ DENY → 终止
+     ▼
+执行操作 + 记录 Audit
+```
+
+**参考实现**：OPA（Open Policy Agent）或等效 Policy Engine
+
+---
+
+### 支柱二：SOBR Risk Scoring（四维风险评分）
+
+量化风险分数，提供一致且可解释的决策依据。
+
+#### 公式
+
+```
+RiskScore = S×0.30 + O×0.25 + B×0.25 + R×0.20
+```
+
+#### 四个维度
+
+| 维度 | 权重 | 说明 | 示例高分 | 示例低分 |
+|------|------|------|---------|---------|
+| **S** Sensitivity | 0.30 | 目标资源敏感度 | 用户凭证（100）| 公开文档（5）|
+| **O** OperationType | 0.25 | 操作危险程度 | 执行任意代码（100）| 读取公开数据（10）|
+| **B** BlastRadius | 0.25 | 操作影响范围 | 影响所有生产环境（100）| 隔离开发沙箱（10）|
+| **R** Reversibility | 0.20 | 不可逆程度（越不可逆分数越高）| 永久删除无备份（100）| 只读操作（0）|
+
+#### 决策阈值
+
+| 分数范围 | 决策 | 行动 |
+|---------|------|------|
+| 0–25 | **ALLOW** | 正常执行，记录 Audit |
+| 26–50 | **ALLOW_WITH_MONITORING** | 执行并加强监控，标记人工事后审查 |
+| 51–75 | **REQUIRE_HITL** | 触发人工审核升级（Human-in-the-Loop）|
+| 76–100 | **DENY** | 拒绝，记录决策路径与违规项目 |
+
+---
+
+### 支柱三：Fail-Closed（故障关闭原则）
+
+任何安全组件故障时，**默认行为必须是 DENY**，禁止 fail-open。
+
+#### 故障场景对应
+
+| 故障场景 | 必要响应 | 例外 |
+|---------|---------|------|
+| Policy Engine 不可达 | DENY ALL | 只读操作可由操作者明确设置例外 |
+| SOBR 评分计算失败 | REQUIRE_HITL（保守升级）| 无 |
+| Signature 验证失败 | DENY ALL | 无 |
+| 任何未知错误 | DENY | 无 |
+
+#### 禁止的反模式
+
+- **Fail-Open**：错误时默认 ALLOW（严重度：CRITICAL）
+- **部分验证继续执行**：某层验证失败但仍继续（严重度：HIGH）
+- **静默吞噬错误**：catch 错误但不改变决策（严重度：HIGH）
+
+---
+
+### 支柱四：Audit Chain（不可篡改审计轨迹）
+
+所有安全决策必须记录在**可验证的不可篡改审计轨迹**中。
+
+#### 每条 Audit 记录必要字段
+
+| 字段 | 类型 | 说明 |
+|------|------|------|
+| `request_id` | UUID v4 | 每次决策的唯一标识符 |
+| `decision` | enum | ALLOW / ALLOW_WITH_MONITORING / REQUIRE_HITL / DENY |
+| `risk_score` | number (0-100) | SOBR 计算结果 |
+| `timestamp` | ISO 8601 UTC | 毫秒精度时间戳 |
+| `violations` | string[] | 违规政策列表（ALLOW 时为空数组）|
+| `signature` | base64 Ed25519 | 对核心字段的非对称签名 |
+| `prev_hash` | SHA-256 hex | 前一条记录的 hash（构成 hash chain）|
+
+#### Hash Chain 设计
+
+```
+Record[0]: prev_hash = "0000...0000" (genesis)
+Record[1]: prev_hash = SHA-256(Record[0])
+Record[2]: prev_hash = SHA-256(Record[1])
+...
+```
+
+必须提供 `verify_chain()` 函数，可检测任何中间记录的篡改。
+
+#### 签名规范
+
+- **算法**：Ed25519（非对称加密）
+- **签署内容**：`{request_id}:{decision}:{risk_score}:{timestamp}`
+- **禁止**：使用 HMAC（对称）作为审计签名
+
+#### 存储级别
+
+| 级别 | 存储介质 | 适用环境 |
+|------|---------|---------|
+| Level 0（最低）| 本地 append-only file | 开发/测试 |
+| Level 1（推荐）| WORM 存储（S3 Object Lock / Azure Immutable Blob）| 生产环境 |
+| Level 2（最高）| 不可变云端 + Remote Attestation | 法规要求环境（SOC2, ISO 27001 认证）|
+
+---
+
+### 支柱五：HITL Escalation（人工审核升级）
+
+Risk Score 落在 51–75（REQUIRE_HITL 区间）时，必须有明确的人工审核升级机制。
+
+#### 两种 HITL 模式
+
+| 模式 | 行为 | 适用场景 |
+|------|------|---------|
+| **Non-Blocking** | 发送通知，执行继续（加强监控）| 分数 51–62，低敏感操作 |
+| **Blocking** | 暂停执行，等待人工确认 | 分数 63–75，高敏感环境 |
+
+#### 必要要求
+
+- **TTL**：HITL 审核请求必须有过期时间（建议 **1800 秒**）
+- **过期行为**：TTL 到期未审核 → 自动升级为 DENY
+- **Audit**：HITL 触发事件与审核结果必须记入 Audit Chain
+- **通知接口**：Webhook 为标准接口；Adapter 模式支持 Slack / Teams / PagerDuty
+
+#### 通知 Payload 必要字段
+
+```json
+{
+  "request_id": "...",
+  "risk_score": 67,
+  "operation_summary": "...",
+  "policy_violations": [...],
+  "expires_at": "2026-05-04T12:30:00Z"
+}
+```
+
+---
+
+### 支柱六：Prompt Injection Defense（提示注入防护）
+
+AI Agent 系统必须防护 Prompt Injection 攻击，防止恶意输入绕过安全控制。
+
+#### 检测模式类型
+
+| 类型 | 示例模式 |
+|------|---------|
+| 覆盖指令 | "ignore previous instructions", "disregard your programming" |
+| 角色扮演操控 | "you are now", "act as", "DAN", "jailbreak" |
+| 系统 Token 注入 | `[SYSTEM]`, `[INST]`, `<\|system\|>`, `<<SYS>>` |
+| 指令前缀 | "New instruction:", "OVERRIDE:", "Updated system prompt:" |
+
+#### 防护措施
+
+1. **拦截位置**：M1 Intake 层（管道最前端），在任何语义评估前拦截
+2. **响应**：触发 DENY + 记录 `PROMPT_INJECTION_DETECTED` violation
+3. **日志安全**：**禁止**将原始恶意输入存入日志；只记录检测到的模式类型与输入的 Hash
+4. **模式维护**：每月更新检测模式；订阅 OWASP LLM Working Group 更新
+
+---
+
+## 实现参考
+
+### External Guardian (reference implementation)（TypeScript 参考实现）
+
+External Guardian OPA Sidecar reference implementation (XSPEC-146 from an external project)是 Secure-Op 的完整 TypeScript 参考实现，包含：
+
+- **GuardianService**：主要 Veto-based 决策管道
+- **SobrScorer**：SOBR 四维风险评分
+- **AuditChain**：SHA-256 Hash Chain + Ed25519 签名
+- **HitlNotifier**：Webhook Adapter（支持 Slack/Teams）
+- **PromptInjectionDetector**：正则表达式 + 模式匹配
+
+> 路径：external Guardian implementation (separately licensed)
+
+### 最小实现清单
+
+建立 Secure-Op 合规系统的最小步骤：
+
+```
+□ Step 1：建立 Policy Engine（OPA 或等效工具）并连接至 Agent 管道
+□ Step 2：实现 SOBR 评分计算（4 维度 + 权重公式）
+□ Step 3：设置决策阈值路由（ALLOW / MONITORING / HITL / DENY）
+□ Step 4：建立 Audit Chain（append-only + hash + signature）
+□ Step 5：实现 HITL 通知 + TTL 机制
+□ Step 6：加入 Prompt Injection 检测（M1 位置）
+□ Step 7：在所有错误路径确认 Fail-Closed 行为
+```
+
+---
+
+## ISO / NIST / OWASP 映射
+
+| 支柱 | 标准映射 |
+|------|---------|
+| Veto-Based Decision | ISO/IEC 27001:2022 A.8.24 |
+| SOBR Risk Scoring | ISO/IEC 27001:2022 Annex A.8.24；ISO/IEC 27005 |
+| Fail-Closed | NIST SP 800-207 Zero Trust Architecture（2.1节）；ISO/IEC 27001:2022 A.8.22 |
+| Audit Chain | ISO/IEC 27001:2022 A.8.15（Logging）；ISO/IEC 27001:2022 A.5.33（Protection of records）|
+| HITL Escalation | ISO/IEC 27001:2022 A.8.2；NIST SP 800-53 AC-2 |
+| Prompt Injection Defense | OWASP LLM Top 10 2025 LLM01；ISO/IEC 27001:2022 A.8.24 |
+
+---
+
+## 级别分类
+
+Secure-Op 标准分为三个实现级别（Priority Levels）：
+
+### P0a：审查层（必须）
+
+最低基准要求，所有 AI Agent 系统必须实现：
+
+- Policy Engine 连接并设置 Fail-Closed
+- SOBR 风险评分（任何操作请求触发）
+- Prompt Injection 检测（M1 位置）
+
+### P0b：执行验证层（必须）
+
+在 P0a 基础上，强化执行时的决策保障：
+
+- 完整决策路由（ALLOW / MONITORING / HITL / DENY）
+- HITL 升级机制（含 TTL）
+- 所有决策记入 Audit Log
+
+### P0c：强化层（高安全需求环境）
+
+在 P0b 基础上，达到法规合规级别：
+
+- Hash Chain + Ed25519 签名的 Audit Chain
+- WORM 存储（Level 1 或 Level 2）
+- Remote Attestation 支持
+- 定期 Audit Chain 完整性验证
+
+---
+
+## 快速开始建议
+
+### 对于小型 AI Agent 系统（MVP / Prototype）
+
+从 SOBR 评分 + 基本 DENY 阈值开始：
+
+1. 为每个操作类型定义 S / O / B / R 值
+2. 计算 RiskScore；≥76 直接拒绝
+3. 记录决策到 append-only log
+
+### 对于生产环境 AI Agent 系统
+
+完整实现六大支柱，使用 External Guardian (reference implementation) 作为参考或直接引用。
+
+### 对于法规要求环境（金融、医疗、政府）
+
+P0c 级别 + 外部审计师可访问的 Audit Chain 导出功能。
+
+---
+
+## 相关标准
+
+- `security-standards`：架构层安全设计（输入验证、认证设计）
+- `security-testing`：安全测试方法论（SAST、DAST、依赖审计）
+- `audit-trail`：一般 Audit Trail 标准
+- `mock-boundary`：测试中禁止 mock 安全控制
+
+
+**Scope**: universal

package/bundled/locales/zh-CN/core/security-testing.md

@@ -0,0 +1,113 @@
+---
+source: ../../../core/security-testing.md
+source_version: 1.1.0
+translation_version: 1.1.0
+last_synced: 2026-07-08
+source_hash: 242e9016416c
+status: current
+---
+
+# 安全测试标准
+
+> **语言**: [English](../../../core/security-testing.md) | [繁體中文](../../zh-TW/core/security-testing.md) | 简体中文
+
+**版本**: 1.1.0
+**最后更新**: 2026-06-19
+**适用性**: 所有软件项目
+**范围**: universal
+**行业标准**: OWASP Testing Guide v4, NIST SP 800-115, ISO/IEC 27001
+**参考**: OWASP Top 10, CWE/SANS Top 25
+
+---
+
+## 目的
+
+本文档定义软件项目的安全测试方法论。它与 `security-standards.md`（架构层面的安全设计）互补，提供执行层面的指导：应运行哪些工具、何时运行、以及如何响应发现的问题。
+
+---
+
+## 四个安全测试层
+
+### 1. SAST — 静态分析
+
+在不执行代码的情况下分析源代码。在 pre-commit 和 CI 中运行。
+
+| 语言 | 工具 | 检测项 |
+|----------|------|---------|
+| TypeScript/JS | eslint-plugin-security | eval 注入、regex DoS、路径遍历 |
+| Python | bandit | SQL 注入、硬编码凭据 |
+| Java | SpotBugs + FindSecBugs | SQL 注入、XSS |
+
+**门禁**: High/Critical → 阻止 merge
+
+### 2. 依赖审计
+
+扫描第三方包的已知 CVE。在 pre-push 和每周运行。
+
+| 生态系统 | 工具 | 命令 |
+|-----------|------|---------|
+| Node.js | npm audit | `npm audit --audit-level=high` |
+| Python | pip-audit | `pip-audit` |
+
+**门禁**: High/Critical CVE → 阻止发布（例外须记录并附到期日期）
+
+### 3. 密钥扫描
+
+检测意外提交的密钥。在每次 commit 时运行。
+
+工具: gitleaks、truffleHog
+
+**门禁**: 检测到任何密钥 → 立即阻止 commit
+
+### 4. DAST — 动态分析
+
+通过 HTTP 测试运行中的应用程序。在 staging 部署后运行。
+
+工具: OWASP ZAP、Nuclei
+
+**门禁**: High/Critical 发现 → 阻止晋升至 production
+
+---
+
+## CVE 响应策略
+
+| 严重程度 | 响应 |
+|----------|----------|
+| Critical | 24 小时内修补；阻止所有部署 |
+| High | 下次发布前解决 |
+| Moderate | 14 天内解决 |
+| Low | 跟踪；在维护窗口解决 |
+
+---
+
+## 发现事项修复生命周期
+
+上述各层负责检测发现，CVE 策略则设定解决时限（SLA），但一个发现事项还需要一个**有负责人的生命周期**——否则「阻止 merge」就是唯一定义好的动作，检测之后的一切都没有定义。每个安全发现（SAST / DAST / 密钥 / 依赖 CVE）都遵循以下状态机。
+
+| 状态 | 含义 | 负责人 | 退出条件 |
+|-------|---------|-------|----------------|
+| **Detected（已检测）** | 由某一层（SAST/DAST/密钥/审计）提出 | 扫描门禁（CI） | 已分配严重程度 |
+| **Triaged（已分诊）** | 已确认严重程度与有效性（真实 vs 误报） | 安全审查者 | 真实 → 转为 In-Progress；误报 → 标记为 `suppressed` 并记录理由 |
+| **In-Progress（处理中）** | 修复正在实现 | 受影响组件的代码负责人 | 修复已提交 |
+| **Resolved（已解决）** | 修复已合并 | 代码负责人 | 原扫描重新运行后无发现 |
+| **Verified（已验证）** | 重新扫描确认发现已消失 | 扫描门禁（CI） | 发现事项关闭 |
+
+- **门禁**：任何 Critical/High 发现若状态非 `Verified`（或 `Triaged → suppressed` 且附有理由），皆**阻止发布**，与上述 CVE 响应策略的 SLA 一致。
+- **不得静默关闭**：发现事项只能通过 `Verified`（重新扫描无发现）或安全审查者明确记录的 `suppressed` 决定离开此生命周期——绝不可通过删除，也不可由修复作者自行批准关闭。
+
+---
+
+## 反模式
+
+- 将所有 CVE 视为同等紧急
+- 对 production 运行 DAST（应使用 staging）
+- 无限期忽略 `npm audit`
+- 在测试中 mock 身份认证 middleware（见 mock-boundary.md）
+
+---
+
+## 与其他标准的关系
+
+- `security-standards`: 架构层面的控制措施（输入验证、身份认证设计）
+- `mock-boundary`: 测试中绝不 mock 安全控制
+- `deployment-standards`: DAST 作为部署流水线的一部分运行

package/bundled/locales/zh-CN/core/self-review-protocol.md

@@ -0,0 +1,172 @@
+---
+source: ../../../core/self-review-protocol.md
+source_version: 1.1.0
+translation_version: 1.1.0
+last_synced: 2026-07-09
+source_hash: 35603d9b6211
+status: current
+---
+
+# Self-Review Protocol（自我审查协议）
+
+> **语言**: [English](../../../core/self-review-protocol.md) | [繁體中文](../../zh-TW/core/self-review-protocol.md) | 简体中文
+
+**版本**: 1.1.0
+**最后更新**: 2026-07-09
+**适用范围**: 所有软件项目（新建、重构、迁移、维护）
+**范围**: partial
+**业界标准**: ISO/IEC 25010（文档可维护性）、IEEE 1063-2001（软件用户文档）
+**参考**: 受 Google Engineering Practices 代码审查实践启发；专为大型 markdown 对象编辑特化
+
+---
+
+## 目的
+
+本标准规范大型 markdown 编辑**commit 前**必跑 **self-review**，捕捉内部 cross-reference 不一致 — 这类问题惯性被内部推理忽略，但完整 re-read 一次即可 surface。
+
+**与其他标准的关系**：
+- 与 [code-review.md](code-review-checklist.md) 互补（后者涵盖代码变更）
+- 与 [documentation-writing-standards.md](documentation-writing-standards.md) 互补（后者涵盖内容创作）
+- 本标准专注于**大型 markdown 文档**（DEC、ADR、XSPEC、SKILL.md、规格文档、runbook 等）的**编辑后验证**
+
+---
+
+## 背景
+
+多次 Claude 辅助编辑 session（如 `dev-platform/.claude/skills/eval-source/SKILL.md` v1.1.0 → v1.1.1、v1.2.0 → v1.2.1）观察到一致模式：**每次大型 markdown 编辑都引入 3-6 处小型内部不一致**，内部推理看不出来，但完整 re-read 立刻 surface。
+
+这些不一致归纳为 **6 大类**，且固定触发后续 patch commit。在 commit 前加入强制 re-read 步骤后，此模式消失（eval-source v1.3.0 为首次无 patch follow-up 的 SKILL.md 变更）。第 7 大类（语言与术语一致性）为后续因不同动机（跨对话 AI 输出漂移，非原始 patch 周期模式）新增，详见下方。
+
+---
+
+## 触发条件
+
+| 变更规模 | 是否必跑 self-review？ |
+|---|---|
+| commit 修改 **> 50 行** markdown | **必跑** |
+| commit 修改 ≤ 50 行 markdown | 可选（小修常无 cross-ref 风险）|
+| 纯 code / config 变更 | 不适用（另有 lint / test / code review）|
+
+适用文件类型：
+- ADR（架构决策记录）
+- 跨项目规格（XSPEC）与 SDD Delta
+- SKILL.md（Claude Code 自定义 skill）
+- ARCHITECTURE.md、API.md、DEPLOYMENT.md、MIGRATION.md 等长型项目文档
+- Runbook、playbook
+- README.md（修改主要 section 时）
+
+---
+
+## 7 类常见内部不一致
+
+### 1. Diagram / Flow 与 step list 不同步
+**示例**：工作流程图 7 格但文档实际定义 8 步骤
+**检查**：数每个 diagram 节点数量 vs `## Step N:` / `## N.` heading
+
+### 2. Changelog 引用编号错位
+**示例**：Changelog 写「Step 1 新增 X」但 X 实际在 Step 0
+**检查**：对每条 changelog 描述，grep 其引用的 anchor 位置
+
+### 3. 计数错位
+**示例**：文档说「自我审计 4 题」但实际 list 有 7 题
+**检查**：grep 「N 题」「N 列」「N 点」等明确数字并对照实际 count
+
+### 4. Stale 模板
+**示例**：commit 模板写死 `Claude Sonnet 4.6` 但实际模型随环境变动
+**检查**：找硬编码的模型名、工具版本、日期；改为 placeholder 或更新
+
+### 5. 错误工具 / 命令引用
+**示例**：建议用 `claude --version` 取得模型名，但该命令只显示 CLI 版本
+**检查**：对每个提及的 CLI 命令做 mental check 或 `which X` / `--help` 验证
+
+### 6. Placeholder 与 rule 不对齐
+**示例**：example 写「D1/D2/D3」但 rule 明说 D3 不强制，且当前案例正好把 D3 降为后续追踪
+**检查**：example 中每个具体值是否与当前 rule 一致；example 不应与最新案例经验矛盾
+
+### 7. 语言与术语一致性
+**示例**：双语文档某段落中英文夹杂，或日文假名/韩文谚文混入简体中文段落；或同一份文档内「XSPEC」「gate」「pipeline」等项目惯用术语写法不一致
+**检查**：扫描非目标语言文字是否出现在非预期段落（如日文假名 U+3040–U+30FF、韩文谚文 U+AC00–U+D7A3 混入简体中文段落）、同段落语言混杂、以及同一文件内既有惯用术语拼法是否一致
+
+---
+
+## 流程
+
+1. **edit 完成后、commit 前**，用 file-reading 工具重新读过**完整文件**（不只 diff）
+2. 依上方 7 类逐项对照
+3. **发现问题** → 直接 Edit 修补后再 commit（同一 commit 包含修正，不要分开 ship）
+4. **若已 commit 才发现** → 新增 patch commit（如 v1.2.1 对 v1.2.0）
+
+---
+
+## 记录格式（按文件类型）
+
+### SKILL.md
+在 frontmatter 附近 changelog 追加一行：
+```
+> **v{X.Y.(Z+1)} Self-review pass {YYYY-MM-DD}**：找到 {N} 处 issue，{M} 处于同 commit 修正；或「0 issues found」
+```
+
+### ADR / DEC
+在 `## 后续追踪` 表格新增一行：
+```
+| Self-review pass | 本 DEC | ✅ YYYY-MM-DD (7 类无 issue) |
+```
+
+### XSPEC SDD Delta
+在「不改动清单」section（如 §N.6）后追加：
+```
+> Self-review pass: YYYY-MM-DD (7 类无 issue)
+```
+
+### Commit message body
+最后一行附：
+```
+Self-review (protocol v1.1.0): N issues found, M applied in same commit / 0 found.
+```
+
+---
+
+## 与其他审查实践的区别
+
+| 实践 | 涵盖面向 | 触发时机 |
+|---|---|---|
+| **Code Review**（[code-review.md](code-review-checklist.md)）| 代码正确性、设计、安全 | code PR merge 前 |
+| **内容自我审计**（如 eval-source skill 7 题）| 内容完整性（是否包含所有必要 section）| 每次文档产出 |
+| **Self-Review Protocol**（本标准）| 内部 cross-reference 一致性（形式，非内容）| 大型 markdown 编辑后、commit 前 |
+| **同侪审查** | 独立视角、blast radius 评估 | 重要变更 |
+
+三层审查互补：
+- **内容审计** 问：*是否包含所有必要的部分？*
+- **Self-review** 问：*包含的部分内部一致吗？*
+- **同侪审查** 问：*从另一个角度看，这个变更合理吗？*
+
+---
+
+## 反模式
+
+1. **因为「diff 看起来不大」就跳过 self-review** — 大文件的小 diff 常引入其他位置的 cross-ref 错误
+2. **只 review diff 而非整文件** — cross-ref 错误可能在未变动的 section 中（引用了已变动内容）
+3. **记录 protocol 但不执行** — 纪律在于实践，不在于文档本身
+4. **把 self-review 当 peer review 的替代品** — self-review 抓不一致，不抓设计缺陷
+
+---
+
+## 验证
+
+采纳本标准的验证方式：
+
+- **Patch commit 比例**：采纳后，同一对象 `v1.X.0 → v1.X.1` 后续 patch 比例应显著下降（eval-source 从 v1.3.0 前的 100% 降至之后的 0%）
+- **Issue surface 时间**：self-review 抓到的 issue（pre-commit）vs 下一个 reader 抓到的 issue（post-commit）— 前者应上升、后者应下降
+
+---
+
+## 实践案例
+
+- **dev-platform** `eval-source` skill v1.3.0 — 首次 SKILL.md 变更在 commit 前 self-review pass（commit `6b45c5d`）；前有两次 patch 周期（v1.1.0→v1.1.1 3 处、v1.2.0→v1.2.1 6 处）促成本标准诞生
+
+---
+
+## Self-Review Pass
+
+> Self-review pass: 2026-05-26 (6 类无 issue；本标准首稿同步 self-review)
+> Self-review pass: 2026-07-09（7 类无 issue —— 依 XSPEC-324 新增第 7 类「语言与术语一致性」）