universal-dev-standards 5.16.0 → 6.0.0

package/bundled/locales/zh-CN/core/release-readiness-gate.md

@@ -0,0 +1,193 @@
+---
+source: ../../../core/release-readiness-gate.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-06-10
+source_hash: 622d8cb59abb
+status: current
+---
+
+# 发布就绪闸门（Release Readiness Gate）
+
+> **语言**：[English](../../../core/release-readiness-gate.md) | [繁體中文](../../zh-TW/core/release-readiness-gate.md) | 简体中文
+
+**版本**：1.0.0
+**最后更新**：2026-05-05
+**适用范围**：所有准备进行生产环境发布的软件项目
+**Scope**：universal
+**业界标准**：ISO/IEC 25010（产品质量）、ISTQB Advanced Test Manager
+**参考文件**：`core/release-quality-manifest.md`、`core/flow-based-testing.md`
+
+---
+
+## 目的
+
+本标准定义一个**单一、汇整式的发布就绪闸门（Release Readiness Gate）**，将所有质量维度统一成生产部署前一个明确的 go/no-go 决策。
+
+若没有这个闸门，质量证据会散落在 16 个以上的独立标准中。团队虽然通过了个别检查，却在未验证某些维度的情况下出货，因为没有任何一份文件明说「你必须在发布前通过*所有这些项目*」。
+
+发布就绪闸门：
+- **汇整（Aggregates）** 16 个质量维度成为一份分级 checklist
+- **连结（Connects）** 人工 sign-off（本文件）与机器可读的证据（`release-quality-manifest.md`）
+- **区分（Distinguishes）** 阻挡性条件与建议性警告
+- **可伸缩（Scales）** 透过 Tier-1 / Tier-2 / Tier-3 分级，以适应不同类型与风险等级的项目
+
+---
+
+## 与发布质量清单（Release Quality Manifest, RQM）的关系
+
+| 产物 | 格式 | 对象 | 目的 |
+|----------|--------|----------|---------|
+| **发布就绪 Sign-off**（本文件的模板） | Markdown checklist | 人类（PM、QA、Eng Lead、Business） | Go/no-go 决策、责任归属、审计轨迹 |
+| **发布质量清单**（`release-quality-manifest.md`） | YAML/JSON | CI、工具、客户 | 机器可读的汇整、自动化闸门强制执行 |
+
+这两份产物在每次发布时**并行（in parallel）**产生。Sign-off 涵盖人工验证的维度；RQM 涵盖自动化的维度。两者在生产部署前都必须为 `PASS` / `WARN`（绝不可为 `FAIL`）。
+
+---
+
+## Tier 分级
+
+| Tier | 要求 | 未达标 = ？ | 适用对象 |
+|------|-------------|---------|-------------|
+| **Tier-1** | 必须通过；若 `FAIL` 则阻挡发布 | 硬性阻挡（Hard block） | 所有项目 |
+| **Tier-2** | 应通过；`WARN` 须记录理由；不阻挡 | 记录在案的 WARN | 所有项目 |
+| **Tier-3** | 当功能集或领域需要时才适用；`N/A` 为有效状态 | 接受 N/A | 取决于项目类型 |
+
+---
+
+## 16 维度发布就绪矩阵
+
+| # | 维度 | Tier | 闸门类型 | 阻挡条件 | 证据 | 标准 | 负责人 |
+|---|-----------|------|-----------|-------------------|----------|---------|-------------|
+| 1 | **性能 / 负载（Performance / Load）** | 2 | 自动化 | p95 latency 退化 > 10%；headroom < 20% | 负载测试报告 | `performance-standards.md` | Eng Lead + SRE |
+| 2 | **安全性（Security）**（SAST/DAST/SCA/secrets） | 1 | 自动化 | 任何 Critical/High CVE、SAST High 未修、diff 中含 secret | SARIF、Trivy、SBOM | `pipeline-security-gates.md` | SecEng / Eng Lead |
+| 3 | **无障碍（Accessibility, a11y）** | 2 | 自动化 + 人工 | axe-core critical > 0；键盘导航路径中断 | axe 报告、screen reader 记录 | `accessibility-standards.md` §Release-Blocking Threshold | QA + UX |
+| 4 | **API / 合约测试（Contract Testing）** | 3 | 自动化 | 上游 consumer contract 为红；N-1 兼容性中断 | Pact broker 报告 | `contract-testing-standards.md` | API owner |
+| 5 | **数据库迁移（Database Migration）** | 1 | 自动化 | up/rollback/idempotency 测试失败；数据保存测试失败 | `data-migration-testing.md` 闸门结果 | `data-migration-testing.md` | DB Lead |
+| 6 | **跨流程回归（Cross-flow Regression）** | 2 | 自动化 | 关键 user journey 通过率 < 95%；business-critical flow 组合失败 | 跨流程回归报告 | `cross-flow-regression.md` | QA Lead |
+| 7 | **运营就绪（Operational Readiness）** | 1 | 人工 | 缺少 Runbook；alerting 未设置；无 rollback 程序 | Runbook 链接、alert rule 审查 | `runbook-standards.md`、`alerting-standards.md` | SRE / Ops |
+| 8 | **本地化 / i18n（Localization）** | 2 | 自动化 | 发布中有 MISSING 或 MAJOR i18n 落差（semver 落差） | `check-translation-sync.sh` 输出 | `translation-lifecycle-standards.md` | i18n Lead |
+| 9 | **浏览器 / 设备兼容性（Browser / Device Compatibility）** | 3 | 自动化 | Tier-1 浏览器/设备通过率 < 100% | Playwright matrix 报告 | `browser-compatibility-standards.md` | Frontend QA |
+| 10 | **容量 Sign-off（Capacity Sign-off）** | 3 | 人工 | 预估峰值时 headroom < 30%；无 Eng+SRE sign-off | 容量预测 + sign-off | `performance-standards.md` §Per-Release Capacity Sign-off | SRE + Eng Lead |
+| 11 | **合规 / 隐私（Compliance / Privacy）** | 3 | 人工 | GDPR/CCPA 违规；缺少 audit log；保存政策中断 | 隐私审查 checklist | `privacy-standards.md` | DPO / Legal |
+| 12 | **文档完整性（Documentation Completeness）** | 2 | 人工 | 此次发布缺少 CHANGELOG；面向客户的文档未更新 | CHANGELOG diff、文档审查 | `changelog-standards.md`、`documentation-lifecycle.md` | Tech Writer / PM |
+| 13 | **回滚 / 灾难恢复（Rollback / Disaster Recovery）** | 1 | 人工 | 此次发布无经测试的 rollback 程序；RTO > 门槛 | DR 演练记录；rollback script | `rollback-standards.md`、`disaster-recovery-drill.md` | SRE |
+| 14 | **生产 Smoke / Canary（Production Smoke / Canary）** | 1 | 自动化 | 部署后 smoke 失败；canary error rate > SLO | Smoke 测试结果；canary 仪表板 | `smoke-test.md`、`cd-deployment-strategies.md` | SRE / DevOps |
+| 15 | **Feature Flag 治理（Feature Flag Governance）** | 2 | 人工 | 默认状态未审查；kill-switch 未测试 | Flag 审计 checklist | `feature-flag-standards.md` | PM + Eng Lead |
+| 16 | **多闸门流程验证（Multi-Gate Flow Verification）** | 2 | 自动化 + 人工 | 任何 ≥ 3 步骤的流程缺少 Gate 0；Gate 3 CI 失败；缺少 Gate 4 UAT sign-off | `flow_gate_report.json`；UAT sign-off 表 | `flow-based-testing.md` §Multi-Gate | QA Lead + Business |
+
+> **关于 Tier-3 的说明**：不适用时标记为 `N/A`（例如：CLI 工具的浏览器 matrix；无 API consumer 的独立服务的合约测试）。`N/A` 在 sign-off 中需附上理由注释。
+
+---
+
+## 发布就绪 Sign-off 模板
+
+> 每次发布时复制此模板。在 repo 根目录存为 `.release-readiness/<version>.md`，或附加于发布产物上。
+
+```markdown
+# Release Readiness Sign-off
+
+**Release**: [tag/version]
+**Date**: [YYYY-MM-DD]
+**Environment**: Pre-Production → Production
+**RQM Artifact**: [link or commit SHA]
+
+## Tier-1 Gates (ALL must be PASS)
+
+| # | Dimension | Status | Evidence | Sign-off |
+|---|-----------|--------|----------|---------|
+| 2 | Security (SAST/DAST/SCA) | PASS / FAIL | [link] | [name] |
+| 5 | Database Migration | PASS / FAIL | [link] | [name] |
+| 7 | Operational Readiness | PASS / FAIL | [link] | [name] |
+| 13 | Rollback / DR | PASS / FAIL | [link] | [name] |
+| 14 | Production Smoke/Canary | PASS / FAIL | [link] | [name] |
+
+## Tier-2 Gates (WARN must have rationale)
+
+| # | Dimension | Status | Evidence | Rationale (if WARN) | Sign-off |
+|---|-----------|--------|----------|---------------------|---------|
+| 1 | Performance / Load | PASS / WARN / FAIL | [link] | | [name] |
+| 3 | Accessibility | PASS / WARN / FAIL | [link] | | [name] |
+| 6 | Cross-flow Regression | PASS / WARN / FAIL | [link] | | [name] |
+| 8 | Localization / i18n | PASS / WARN / FAIL | [link] | | [name] |
+| 12 | Documentation | PASS / WARN / FAIL | [link] | | [name] |
+| 15 | Feature Flag Governance | PASS / WARN / FAIL | [link] | | [name] |
+| 16 | Multi-Gate Flow Verification | PASS / WARN / FAIL | [link] | | [name] |
+
+## Tier-3 Gates (N/A with rationale allowed)
+
+| # | Dimension | Status | Evidence | Rationale (if N/A) | Sign-off |
+|---|-----------|--------|----------|---------------------|---------|
+| 4 | API / Contract Testing | PASS / WARN / N/A | [link] | | [name] |
+| 9 | Browser / Device Compat | PASS / WARN / N/A | [link] | | [name] |
+| 10 | Capacity Sign-off | PASS / WARN / N/A | [link] | | [name] |
+| 11 | Compliance / Privacy | PASS / WARN / N/A | [link] | | [name] |
+
+## Overall Decision
+
+- [ ] **GO** — All Tier-1 PASS; all WARN documented; all N/A have rationale
+- [ ] **NO-GO** — One or more Tier-1 FAIL, or undocumented WARN
+
+**Decision made by**: [name, role]
+**Date**: [YYYY-MM-DD]
+```
+
+---
+
+## 状态语义（Status Semantics）
+
+| 状态 | 意义 | 对发布的影响 |
+|--------|---------|----------------|
+| `PASS` | 符合或超越所有条件 | 无 |
+| `WARN` | 低于目标但高于硬性最低标；已记录理由 | 允许；记录在案 |
+| `FAIL` | 低于硬性最低标；尚未解决 | **阻挡发布** |
+| `N/A` | 此维度不适用于本项目/本次发布；已记录理由 | 允许 |
+
+---
+
+## 何时建立 Sign-off
+
+| 里程碑 | 动作 |
+|-----------|--------|
+| Release candidate 已 tag | 依模板建立 `.release-readiness/<version>.md`；填入证据链接 |
+| Pre-UAT 部署 | 填入 Gate 3 CI 结果；验证 Tier-1 自动化闸门 |
+| UAT sign-off（Gate 4） | 完成 Tier-3 人工闸门；定案 Multi-Gate Flow 列 |
+| 生产部署决策 | 由 release owner 签署整体 GO/NO-GO 决策 |
+
+Sign-off **不是**事后补做的——Gate 0（PRD 完整性）与 Gate 1（PR 层级测试）必须在 sign-off 文件建立之前很久就已满足。Sign-off 汇整的是整个发布周期中持续收集的证据。
+
+---
+
+## 反模式（Anti-Patterns）
+
+- **在部署当天才建立 sign-off** — 证据应在整个发布周期中渐进收集
+- **未附理由就标记 WARN** — 没有记录理由的 WARN，在功能上等同于无视该闸门
+- **完全略过 Tier-3 而未附 N/A 理由** — 若 web app 省略浏览器测试，必须明确说明理由
+- **把 Sign-off 当成橡皮图章** — 每一列都需要一位具名的 sign-off 负责人；匿名的集体所有权代表没有真正的责任归属
+- **多个发布共用一份 sign-off** — 每个发布 tag 一份 sign-off；不可跨版本复用
+
+---
+
+## 另请参阅（See Also）
+
+- `release-quality-manifest.md` — 机器可读的 RQM（本 sign-off 的自动化对应物）
+- `flow-based-testing.md` — Multi-Gate Flow Model（维度 16）
+- `branch-completion.md` — 分支层级闸门（前置条件；不等同于发布就绪）
+- `verification-evidence.md` — 证据标准（所有证据链接都必须符合此标准）
+- `deployment-standards.md` — 部署后闸门集成
+
+---
+
+## 版本历史（Version History）
+
+| 版本 | 日期 | 变更 |
+|---------|------|---------|
+| 1.0.0 | 2026-05-05 | 首次发布：16 维度矩阵、分级 sign-off 模板、RQM 集成 |
+
+---
+
+## 授权（License）
+
+本标准以 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) 授权发布。
+
+**来源（Source）**：[universal-dev-standards](https://github.com/AsiaOstrich/universal-dev-standards)

package/bundled/locales/zh-CN/core/replay-test.md

@@ -0,0 +1,102 @@
+---
+source: ../../../core/replay-test.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-06-10
+source_hash: 888dadd74668
+status: current
+---
+
+# Replay 测试标准
+
+> **语言**: [English](../../../core/replay-test.md) | [繁體中文](../../zh-TW/core/replay-test.md) | 简体中文
+
+---
+
+## 概述
+
+AI 代理系统通过复杂的多步骤管道与用户交互。当客户反馈非预期行为时，重现确切的失败场景往往相当困难——模型输出可能是非确定性的、环境可能已发生变化，或确切的输入内容可能不明确。黄金 fixture replay 通过在发现问题时序列化确切的输入与预期输出，解决了这个问题，从而实现确定性的回归测试。
+
+## Fixture 格式
+
+```json
+{
+  "meta": {
+    "recorded": "2026-05-05",
+    "source": "customer-report | ci-regression | red-team | incident",
+    "description": "Human-readable description of what this tests"
+  },
+  "input": { /* exact component input */ },
+  "expected": { /* expected output fields to assert */ }
+}
+```
+
+## Fixture 命名规则
+
+`<component>-<outcome>-<description>.json`
+
+| 好的命名 | 不好的命名 |
+|---------|----------|
+| `guardian-deny-prod-drop-table.json` | `test1.json` |
+| `guardian-allow-dev-npm-test.json` | `fixture.json` |
+| `guardian-hitl-prod-irreversible.json` | `scenario_3.json` |
+
+## Replay 测试实现（Vitest）
+
+```typescript
+// SPDX-License-Identifier: AGPL-3.0-only
+import { readdirSync, readFileSync } from "fs"
+import { join } from "path"
+import { describe, it, expect } from "vitest"
+import { scoreReviewable } from "../scoring/risk-engine.js"
+
+const FIXTURES_DIR = join(__dirname, "..", "__fixtures__")
+
+interface ReplayFixture {
+  meta: { recorded: string; source: string; description: string }
+  input: Parameters<typeof scoreReviewable>[0]
+  expected: { decision: string }
+}
+
+function deriveDecision(score: number): string {
+  if (score >= 76) return "DENY"
+  if (score >= 51) return "REQUIRE_HITL"
+  return "ALLOW"
+}
+
+describe("Guardian replay fixtures", () => {
+  const fixtures = readdirSync(FIXTURES_DIR)
+    .filter(f => f.endsWith(".json"))
+    .map(f => ({
+      name: f,
+      fixture: JSON.parse(readFileSync(join(FIXTURES_DIR, f), "utf-8")) as ReplayFixture,
+    }))
+
+  for (const { name, fixture } of fixtures) {
+    it(`[${fixture.meta.source}] ${fixture.meta.description}`, () => {
+      const result = scoreReviewable(fixture.input)
+      const decision = deriveDecision(result.score)
+      expect(decision).toBe(fixture.expected.decision)
+    })
+  }
+})
+```
+
+## 缺陷回归工作流程
+
+1. 客户反馈非预期的 Guardian 判定
+2. 捕获确切的 `Reviewable` 输入（来自审计日志）
+3. 创建 fixture 文件：`guardian-<outcome>-<description>.json`
+4. 在本地重现失败（测试应当失败）
+5. 修复缺陷
+6. 确认测试通过
+7. 该 fixture 现在永久防止回归
+
+## 相关标准
+
+- [对抗性测试标准](../../../core/adversarial-test.md) — 红队语料库
+- [验证证据标准](../../../core/verification-evidence.md) — AC 可追溯性
+- [测试标准](../../../core/testing-standards.md) — 整体测试金字塔
+
+
+**Scope**: universal

package/bundled/locales/zh-CN/core/reverse-engineering-standards.md

@@ -3,7 +3,7 @@ source: ../../../core/reverse-engineering-standards.md
 source_version: 1.0.0
 translation_version: 1.0.0
 last_synced: 2026-01-19
-status: current
+status: stale
 ---
 
 # 反向工程标准
@@ -57,10 +57,52 @@ status: current
 |------|------|--------|-----------|
 | **程序码扫描** | 分析程序码结构、API、资料模型 | 技术清单 | [已确认] |
 | **测试分析** | 解析现有测试以取得验收条件 | 草拟验收条件 | [已确认]/[推论] |
+| **隐含规则扫描** | 扫描非 HTTP 持久化写入路径中未文件化的规则 | 隐含规则清单 + 三问解答 | [已确认]/[推论]/[未知] |
 | **缺口识别** | 列出需要人类输入的未知项目 | 缺口分析文件 | [未知] 项目 |
 | **规格生成** | 生成草拟规格 | 草拟 SPEC-XXX.md | 混合确定性 |
 | **人类审查** | 利害关系人验证与填补缺口 | 已验证的规格 | [已确认] |
 
+> **注（v1.2.0）**：在程序码扫描／测试分析之后、缺口识别之前，插入一个 **隐含规则扫描** 阶段——详见下方[隐含规则扫描（非 HTTP 持久化规则）](#隐含规则扫描非-http-持久化规则)。标准程序码扫描只提取 HTTP 入口点与资料模型，但持久化栏位的值经常由**非 HTTP 路径**（cron、伫列、计算栏、trigger、ORM hook）写入，其业务规则从未被文件化——这是跨语言重写或跨 DB 迁移时遗漏逻辑的最高发来源。
+
+---
+
+## 隐含规则扫描（非 HTTP 持久化规则）
+
+> **工作流程位置**：在程序码扫描／测试分析之后、缺口识别之前。
+
+程序码扫描提取的是透过 HTTP 可达的部分——路由、控制器、请求处理器。但一个持久化栏位的值经常在**请求路径之外**被决定：夜间 cron 翻转某个 status、伫列重试重新盖上某个 timestamp、资料库 trigger 推导出某个总额、ORM 生命周期 hook 把某个计数器归零。这些规则鲜少被写下来，因此只镜像 HTTP 表面的重写会悄悄遗漏它们。本阶段机械化地推导出每一条非 HTTP 写入路径，并把每条隐含规则锁为可验证物。
+
+### 清单来源（derive，机械化）
+
+对旧系统扫描每一条**非 HTTP 持久化写入路径**，涵盖四类：
+
+1. **排程**——crontab 项目、scheduler 设定、`@Scheduled` 类注解、批次作业
+2. **伫列**——queue consumer、job handler、背景 worker、message listener
+3. **DB 层**——trigger、computed/generated column、`DEFAULT` 运算式、check constraint
+4. **ORM 生命周期**——`beforeSave`/`afterSave`/observer/model-event hook、会变更持久状态的 middleware
+
+### Oracle（detect）——每栏三问
+
+对每个由非 HTTP 路径写入的持久化栏位，回答并锁定**三个问题**：
+
+| 问题 | 要撷取的内容 |
+|------|-------------|
+| **何时设值（SET）？** | 首次赋值的条件／触发点 |
+| **何时被覆写（OVERWRITE）？** | 之后每一次写入——**含非同步覆写**（连回 post-cutover 聚合对帐） |
+| **何时归零／重置（RESET）？** | 清除或回复为预设值的条件 |
+
+- 把 **Devil's Advocate（魔鬼代言人）** 质疑从 HTTP 层扩展到**涵盖非 HTTP 路径**：对 cron 条件、伫列重试、计算栏、trigger 逻辑，套用同样的五类对抗式质疑（边界、顺序、并发、失败/重试、null/预设）。
+- 为每条撷取的规则标注确定性层级：`[已确认]`（附 `file:line` 引用）／`[推论]`／`[未知]`。每个 `[未知]` 都交给缺口识别由人类处理——绝不臆测。
+- **输出**：把每条隐含规则锁为 **behavior-snapshot 场景** 或 **对帐不变量**（例如 `SUM(cost) GROUP BY status` 须跨 cutover 维持），让规则成为可重跑的 oracle 而非散文。
+
+### Gate 时机
+
+pre-flight（规划期）。任何三问未获解答的非 HTTP 写入栏位会被标为 `not_implemented` 并 **block cutover**——未宣告的隐含规则视为已知遗漏风险，而非可接受的缺口。
+
+### PHP 专属补述：宽松比较／type juggling
+
+扫描 PHP 写入路径时，须额外标记**宽松比较／type juggling** 依赖点：`==` 比较、`"0"` / `""` / `null` / `0` 的 truthy/falsy 行为、字串自动转数字。这些在强型别目标（如 C#/.NET）下没有直接对应，因此它们所编码的隐含规则是跨语言重写时被悄悄丢失逻辑的高发来源。对每个此类位置标 `[已确认]` 并附 `file:line`，并把预期语义锁为一条明确规则。
+
 ---
 
 ## 核心原则
@@ -235,8 +277,11 @@ describe('Authentication', () => {
 
 | 版本 | 日期 | 变更内容 |
 |------|------|----------|
+| 1.2.0 | 2026-06-27 | 新增：隐含规则扫描阶段（非 HTTP 持久化写入路径撷取）——4 类 derive 清单 + 三问 oracle + 非 HTTP Devil's Advocate + PHP type-juggling 补述 + 确定性/`file:line`（XSPEC-284 R4/AC-8） |
 | 1.0.0 | 2026-01-19 | 初始发布 |
 
+> **翻译同步注**：本简体译本仍落后于英文源（缺 1.0.0 的 BDD/TDD 整合、规格范本、反模式、最佳实践，及 1.1.0 的失败处理与升级章节），属既有翻译欠债，需后续完整重译；故前置 metadata 暂保留 `source_version: 1.0.0 / status: stale`。本次仅补入 R4 隐含规则扫描新内容。
+
 ---
 
 ## 参考资料

package/bundled/locales/zh-CN/core/rollback-standards.md

@@ -0,0 +1,120 @@
+---
+source: ../../../core/rollback-standards.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-06-10
+source_hash: c3ace87126ca
+status: current
+---
+
+# Rollback Standards（回滚标准）
+
+> **语言**: [English](../../../core/rollback-standards.md) | [繁體中文](../../zh-TW/core/rollback-standards.md) | 简体中文
+
+---
+
+## 概述
+
+本标准定义回滚触发条件矩阵、自动 vs 手动回滚决策流程，以及与错误预算的集成方式。确保每一次部署都有明确、可量化的回滚策略，而非依赖主观判断。
+
+---
+
+## 核心原则
+
+- **可量化触发条件**：回滚触发必须有明确的数值阈值，绝不使用「看起来有问题」等主观描述
+- **三层决策模型**：自动回滚（Auto）→ 辅助回滚（Assisted）→ 手动回滚（Manual）
+- **错误预算集成**：当错误预算低于 10% 时，自动将辅助回滚升级为自动回滚
+- **强制事件记录**：每次回滚都必须写入部署日志并触发故障响应流程
+
+---
+
+## 触发条件矩阵
+
+### 自动回滚（Auto-Rollback）
+
+系统自动执行，无需人工干预：
+
+| 指标 | 触发阈值 |
+|------|---------|
+| 错误率 | > 2× 基线，持续 5 分钟 |
+| 健康检查失败 | 连续 3 次 |
+| P99 延迟 | > 5× 基线，持续 3 分钟 |
+
+### 辅助回滚（Assisted-Rollback）
+
+系统发出告警，由值班工程师确认后执行：
+
+| 条件 | 说明 |
+|------|------|
+| SLO 违反 | 非关键路径的 SLO 违反 |
+| 错误预算剩余 | < 10%（此时升级为自动回滚） |
+
+### 手动回滚（Manual-Rollback）
+
+由开发者评估后决定是否执行：
+
+| 条件 | 说明 |
+|------|------|
+| 延迟恶化 | 仍在 SLO 范围内的性能下降 |
+| 外观问题 | 用户可见但不影响功能的问题 |
+
+---
+
+## 严重性矩阵
+
+| 等级 | 触发方式 | 处理时限 | 通知对象 |
+|------|---------|---------|---------|
+| P0 | 自动 | < 2 分钟 | 全体相关人员 |
+| P1 | 自动 | < 5 分钟 | 值班工程师 |
+| P2 | 辅助 | < 15 分钟 | 团队负责人 |
+| P3 | 手动 | < 1 小时 | 开发者 |
+
+---
+
+## 错误预算集成
+
+当错误预算剩余 < 10% 时：
+
+1. 辅助回滚自动升级为自动回滚
+2. 触发故障事件记录
+3. 暂停后续部署，直到预算恢复
+
+---
+
+## 回滚方法比较
+
+| 方法 | 执行时间 | 风险 | 前置条件 |
+|------|---------|------|---------|
+| Blue-Green 切换 | < 30 秒 | 低 | 双环境基础设施 |
+| Feature Flag 关闭 | < 5 秒 | 极低 | Feature Flag 系统 |
+| DNS 切换 | 60-120 秒 | 中 | 多区域配置 |
+| 代码 Revert | 数分钟 | 中 | 干净的 git 历史 |
+| 数据库还原 | 数小时 | 高 | 已验证的备份 |
+
+---
+
+## 回滚前后检查清单
+
+### 回滚前（Pre-Rollback）
+
+- [ ] 确认回滚目标版本是健康的
+- [ ] 确认数据库迁移向后兼容
+- [ ] 通知相关利益相关者
+
+### 回滚后（Post-Rollback）
+
+- [ ] 确认健康检查在目标版本通过
+- [ ] 将回滚事件写入部署日志
+- [ ] 创建故障单进行根因分析
+- [ ] 更新错误预算追踪
+
+---
+
+## 相关标准
+
+- [deployment-standards.md](../../../core/deployment-standards.md) — 部署基础策略
+- [cd-deployment-strategies.md](../../../core/cd-deployment-strategies.md) — 部署策略选用矩阵
+- AI 格式：[../ai/standards/rollback-standards.ai.yaml](../../../ai/standards/rollback-standards.ai.yaml)
+
+
+**Scope**: universal