feat: 完成P13治理收尾并创建P14执行合同（Issue: P13-1,P13-2,P13-3,P13-4,P13-5,P13-6,P13-7,P13-8,P14-0）

docs/ops/ci-regression-reporting.md

@@ -0,0 +1,38 @@
+# CI 回归报告归档说明（P13-6）
+
+更新时间：2026-02-12
+
+## 目标
+
+在 `ci-regression` 流水线中产出并归档结构化回归报告，确保每次回归可追溯到具体 `run_id` 与 `commit SHA`。
+
+## 产物
+
+- 回归脚本输出：`/tmp/hyb-oa-regression/report.json`
+- Artifact 名称：`regression-report-<run_id>-<sha>`
+- JSON 契约：`schema_version = "1.0"`
+
+## 字段约定
+
+报告包含以下关键字段：
+
+- `schema_version`
+- `generated_at`
+- `git.sha`
+- `git.branch`
+- `overall.status | duration_ms | passed | failed | skipped | total`
+- `steps[]`：`id | name | enabled | status | exit_code | duration_ms | started_at | ended_at | command`
+
+## 回归命令
+
+在 CI 中使用：
+
+```bash
+RUN_AUDIT_REGRESSION=1 RUN_OCR_REGRESSION=1 ./scripts/regression-all.sh --json-report /tmp/hyb-oa-regression/report.json
+```
+
+## 排障建议
+
+- 回归失败时优先下载 artifact，检查 `overall.failed` 与 `steps[].status="failed"`。
+- 若报告未生成，检查回归步骤是否在脚本启动前失败（例如服务未就绪）。
+- 若报告字段缺失，优先比对 `server/scripts/lib/regression-report.sh` 与 schema 版本。

docs/ops/dora-metrics.md

@@ -0,0 +1,49 @@
+# DORA 指标（CFR）落地说明（P13-7）
+
+更新时间：2026-02-12
+
+## 指标口径
+
+- `run_cfr = failed_runs / total_runs`
+- `commit_cfr = failed_commits / total_commits`
+- `failed_commit` 判定：
+  1. 对应回归 run 失败；或
+  2. 该 commit 在回归时间后 24 小时内出现热修记录。
+
+## 数据输入
+
+- 回归 JSON：来自 `server/scripts/regression-all.sh --json-report`
+- 可选热修 CSV：`commit_sha,occurred_at`
+
+## 生成命令
+
+```bash
+python3 scripts/cfr_report.py \
+  --input-dir artifacts/regression \
+  --window 7d,30d \
+  --output-json /tmp/cfr.json \
+  --output-md /tmp/cfr.md
+```
+
+带热修记录：
+
+```bash
+python3 scripts/cfr_report.py \
+  --input-dir artifacts/regression \
+  --window 30d \
+  --hotfix-csv data/hotfix-events.csv \
+  --output-json /tmp/cfr.json
+```
+
+## 输出结构（JSON）
+
+- `generated_at`
+- `input_dir`
+- `reports_scanned`
+- `hotfix_events`
+- `windows.<Nd>.{total_runs,failed_runs,run_cfr,run_cfr_pct,total_commits,failed_commits,commit_cfr,commit_cfr_pct}`
+
+## 使用建议
+
+- 周报使用 `7d`，月报使用 `30d`。
+- 当 `commit_cfr_pct` 持续高于阈值（例如 15%）时，暂停高风险灰度并补回归样本。

docs/ops/non-functional-baseline.md

@@ -1,6 +1,6 @@
-# 非功能基线（P10.5）
+# 非功能基线（P10.5/P13）
 
-更新时间：2026-02-11
+更新时间：2026-02-12
 
 ## 安全基线
 - 使用 `server/scripts/security-baseline.sh` 检查关键安全配置与核心路由语法。
@@ -20,6 +20,14 @@
   - 平均响应（avg）< 500ms
   - 最大响应（max）< 1500ms
 
+## SLI/SLO 与错误预算（P13）
+- 详细定义见：`docs/ops/slo.md`
+- 首版目标：
+  - 可用性（30天）>= 99.9%
+  - 核心 Dashboard API P99 < 500ms
+  - Feature Flag 更新成功率 >= 99.5%
+- 告警规则文件：`deploy/prometheus/alerts-slo.yml`
+
 ## 回滚原则
 - 若非功能指标异常，先执行配置回滚而非代码回滚：
   1. 将 `erp_sync` 和 `invoice_verification` 设为 `force_off`。

docs/ops/slo.md

@@ -0,0 +1,101 @@
+# SLI / SLO 与错误预算（P13）
+
+更新时间：2026-02-12
+
+## 1. 范围与目标
+
+本版聚焦 P11/P13 治理链路（Feature Flags、ERP 同步、验真开关）和核心可观测接口，建立可执行的 SLI/SLO 与错误预算基线。
+
+- 环境范围：生产环境（`NODE_ENV=production`）
+- 统计窗口：滚动 30 天
+- 目标用途：发布评审、变更放行、故障复盘
+
+## 2. SLI 定义
+
+### SLI-1：API 可用性（Availability）
+
+- 指标定义：
+  - 分子：`http_server_requests_total{status!~"5.."}`
+  - 分母：`http_server_requests_total`
+- 统计口径：按所有 `/api/*` 请求聚合
+- 采样周期：5 分钟
+
+### SLI-2：核心接口延迟（Latency P99）
+
+- 指标定义：`histogram_quantile(0.99, rate(http_server_request_duration_seconds_bucket[5m]))`
+- 核心接口：
+  - `/api/dashboard/expense-overview`
+  - `/api/dashboard/trends`
+  - `/api/dashboard/top-categories`
+  - `/api/dashboard/approval-efficiency`
+
+### SLI-3：治理开关变更成功率（Feature Flag Update Success）
+
+- 指标定义：
+  - 分子：`/api/system/feature-flags/:key` 返回 2xx 的次数
+  - 分母：`/api/system/feature-flags/:key` 总调用次数
+- 目标：验证治理入口稳定性，避免灰度期管理面不稳定
+
+## 3. SLO 目标
+
+### SLO-A（可用性）
+
+- 目标：30 天可用性 >= 99.90%
+- 对应最大不可用预算：0.10%
+- 换算：
+  - 每 30 天预算约 43 分钟
+  - 每 7 天预算约 10 分钟
+
+### SLO-B（延迟）
+
+- 目标：核心 Dashboard 接口 P99 < 500ms
+- 兜底上限：P99 不得持续超过 1500ms 超过 15 分钟
+
+### SLO-C（治理变更稳定性）
+
+- 目标：Feature Flag 更新成功率 >= 99.5%
+- 说明：若低于目标，暂停高风险灰度变更（ERP/验真）
+
+## 4. 错误预算策略
+
+### 预算分级
+
+- 正常区：剩余预算 > 50%
+  - 允许常规迭代与灰度
+- 预警区：剩余预算 20% ~ 50%
+  - 限制非必要发布频率，增加回归样本
+- 保护区：剩余预算 < 20%
+  - 冻结非紧急变更，仅允许故障修复
+
+### 预算消耗触发动作
+
+- 可用性预算触发：
+  1. 立即复核最近 24h 发布与配置变更
+  2. 执行 `erp_sync` 与 `invoice_verification` 的 `force_off` 预案
+- 延迟预算触发：
+  1. 优先检查 Dashboard 聚合查询与数据库负载
+  2. 降级非关键统计刷新频率
+
+## 5. 监控与告警接入
+
+- Prometheus 告警规则：`deploy/prometheus/alerts-slo.yml`
+- 非功能脚本：
+  - `server/scripts/benchmark-dashboard.sh`
+  - `server/scripts/security-baseline.sh`
+- 发布前最小检查：
+  - `./scripts/check-minimal.sh`
+  - `cd server && ./scripts/regression-feature-flags.sh`
+
+## 6. 回滚与变更约束
+
+- 一级回滚（业务可用优先）：
+  - 将 `erp_sync`、`invoice_verification` 置 `force_off`
+- 二级回滚（系统保护）：
+  - env 硬闸：`ERP_SYNC_ENABLED=false`、`INVOICE_VERIFICATION_ENABLED=false`
+- 说明：保留审计与历史开关记录，不做 destructive 数据回滚
+
+## 7. 后续演进（P13-5+）
+
+- 将 `regression-all.sh` 结构化结果纳入 SLO 评审输入
+- 形成 Change Failure Rate 周报/月报（DORA 指标）
+- 将 SLO 预算状态纳入发布门禁