Files
codex-app-server/docs/arch-conformance-metrics.md
T
host ace7503515 feat: audit-of-audit sampling rules (golden set and critical paths)
- cloud/audit_sampling.py (pure, stdlib): mandatory sampling (1.0)
  for rebuild cases and for third-failure near-complete cases whose
  continuation round still failed; random sampling for the rest
  (normal 0.10, critical-path 0.50, ceil so small groups are never
  rounded to zero, seed required and recorded for reproducibility).
- Wrong-verdict handling: correct the original conclusion and
  retrigger the corresponding flow (wrong pushback ->
  cancel_pushback_and_rerun_audit; wrong rebuild ->
  halt_rebuild_and_restore; wrong pass -> reopen_audit_and_pushback;
  unknown original -> escalate_to_human); every result, correct or
  corrected, is appended to the audit-of-audit record.
- Golden-set approval checklist: list reviewed, criteria defined,
  sample exclusion, approver+timestamp -- all human-confirmed before
  approval; sample entries (sample=True or sample- ids) are dropped
  and counted, never counted as golden.
- metrics.build_report gains an optional sampling_plan section;
  without a plan it states sampling is pending, never implying the
  audit was re-examined.
2026-11-04 20:55:49 +00:00

96 lines
7.0 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 架构一致性进 CI 与指标闭环(审计加固第 5 步)
实现:`cloud/arch_conformance.py`(纯检查,标准库)、`cloud/metrics.py`
(纯计算,标准库)、端点 `GET /metrics-report`(`cloud/server.py`,
与 `/metrics` 同款认证与成员范围)。测试失败即 CI 失败:现有
`host-verify` 工作流已跑 `discover -s cloud/tests`,本轨未改任何
workflow——第 2 轨拥有 lint/类型/安扫,本轨不碰。
## 架构一致性检查(规则、理由、测试)
| 检查 | 规则 | 理由 | 测试 |
|---|---|---|---|
| 合同版本 | 冻结后版本只能 +1,且须有协调员批准的变更记录(声明向后兼容、列出受影响客户端;破坏性变更须有回归任务) | 契约静默漂移是并行线程分叉的根源;协议是唯一合法路径,检查执行协议而非只记录协议 | `test_arch_conformance.py::TestContractVersion`(正向:等值/批准+1/破坏性+回归任务;负向:未批准、无记录、跳号、不可解析) |
| 禁目录 | 任务只能写自有目录;`..` 与符号链接逃逸在解析后判定 | 跨目录写会 corrupt 他人 worktree | `TestDirectoryGuard`(正向:目录内;负向:`..`、symlink、混合写只报违规项)。口径复用已有定义,不另造:控制面 = 租户 work 目录(`worker._tenant_dirs` 的 `work`),技能项目 = `apps/<client>/` |
| 禁 import | 基础层(db/models/queue/logging_config)不 import 编排层;执行层(sandbox)不 import 持久化/编排层;除 db/backup/migrations 外任何 cloud 模块不得直接 `sqlite3.connect` 或 import `psycopg*`(服务层走 `cloud.db.connect` 或 Store) | 基础层上引是循环依赖前兆;执行器须可换、可假 runner 测试;驱动直连绕过 sqlite/postgres 唯一分发点 | `TestLayerImports`(每项正向+负向)+ 仓库级 `TestRepoLevelScan`(当前主线零违规,未来违规即 CI 失败)。有意不禁:`server.py` 的 `sqlite3.Row`/异常类型适配(那是在 `cloud.db` 连接上的适配,不是绕过;禁它会在基线误报) |
| 技术栈冻结 | G2 冻结表变更/删除须有批准的变更记录;新增客户端是新增不是换栈,通过 | 共享核心按冻结表构建,中途换栈使其静默失效 | `TestFrozenStack`(正向:不变/新增;负向:换栈/删除无批准) |
技能项目一键版:`check_skill_project` 把合同版本、冻结栈、目录写
三项合在一起验,`TestSkillProjectFixture` 用合成项目目录正向/负向
各验一次。静态 AST 扫描看不到 `importlib` 动态导入——这是已知
边界,不声称覆盖。
## 指标采集与报告
端点:`GET /metrics-report`(需 X-API-Key,成员范围)。报告格式
见 `cloud/metrics.py::build_report`:`golden_set`、`decision_ready`、
`metrics`、`thresholds` + `thresholds_source`、`feedback_actions`、
`feedback_consumers`。
指标口径(`compute_metrics`):
- 首过绿灯率 = 首过成功任务 / 已知 attempts 的终态任务;缺陷率 =
有缺陷任务 / 已知 defects 的终态任务;返工率 = attempts>1 任务 /
已知 attempts 的终态任务。终态 = completed/merged/failed/
merge-failed;`interrupted` 不算终态(平台中断自动重跑,算失败
是罚平台事件)。
- 每任务成本复用 #212 双列口径:有价 USD micros 与无价 actual
token 分列;成本不完整(无成本行或有无价 token)时
`total_usd_micros` 为 `None`,有价部分只以
`priced_usd_micros_partial` 出现——无价永不记 0、永不折进总额。
- 未知率回 `None` + `*_known: false`,绝不报 0。
当前诚实边界(端点实测):tasks 表无 attempts/defects 列,端点
传 `None`,首过/缺陷/返工率恒为 `None`;金任务集未经人工审定,
报告恒为 `pending_human_approval`、`decision_ready: false`。接真实
输入需两项前置(见待审定清单),本轨不编造。
## 回流与审计标准迭代(可测试规则,非口号)
`evaluate_feedback` 是纯函数,只产出 `auto_apply: false` 的行动
记录,不自动改路由、不自动改标准;行动由两处消费:
- 路由:`tighten_check`(某类缺陷率 > 阈值)→ 该类任务路由时加
一道审计门;`route_with_extra_audit`(首过率 < 下限)→ 全量加
审计门。消费动作本身须经协调员/人工确认后才生效。
- 审计标准:`tighten_check` / `recalibrate_check`(某检查的违规被
复核推翻率 > 阈值)各开一条标准复核项;标准文档本身的版本
变更走同一合同变更协议(`check_contract_version`,批准 +1),
测试 `TestGoldenSetAndStandardsLoop` 钉住“无批准改标准失败、
有批准通过”。误报复核规则:推翻率高只触发“复核阈值”行动,
绝不让检查自动放宽自己。
默认阈值(`DEFAULT_THRESHOLDS`:缺陷率 0.20、首过下限 0.50、
推翻率 0.30)只是测试用初值,报告标注
`thresholds_source: "default_unapproved"`;生产阈值须人工拍板后
以 `thresholds_source: "human_approved"` 传入,见待审定清单。
## 审计的审计:抽查口径(`cloud/audit_sampling.py`,纯函数)
审计结论本身要被人工抽查,抽查规则可测试、可核查,不留
“定期复核”口号:
- **必抽(比例 1.0)**:推倒重做案例必抽;第三次失败根因判为
接近完成、续轮仍 fail 的案例必抽。接近完成但续轮成功的、
第 1/2 次失败接近完成的,均不属必抽(阈值就是第三次)。
- **随机抽查**:其余案例按组抽取,普通案例默认 0.10,关键路径
案例默认 0.50;小数组 ceil 取整,绝不因四舍五入抽到 0。
抽取须带 seed(`select_sample` 无 seed 即报错),seed 记入
抽查计划,抽取结果可复现、可事后核查。
- **抽查结果处理**:抽查判审计正确 → 只记一条审计的审计记录,
原结论不动;判错 → 纠正原结论并重新触发相应流程:错发推回
→ `cancel_pushback_and_rerun_audit`;错发推倒 →
`halt_rebuild_and_restore`(旧实现按推倒规则保存在 git 历史,
可恢复);错放行 → `reopen_audit_and_pushback`;原结论未知
→ `escalate_to_human`,绝不编造触发动作。每条结果(无论对错)
都须记入审计的审计记录,未记入即视为未发生。
- **金任务审定清单**(`golden_approval_checklist`):任务清单人工
复核、每任务验收标准人工定义、样本排除、审定人+时间记录,
四项全 done 且至少留一个非样本任务才算批准;样本任务
(`sample=True` 或 id 以 `sample-` 开头)一律从金任务集中剔除
并计数,示例文件永远不算金任务。报告的 `sampling` 段在无抽查
计划时明写 pending,不暗示审计已被复核。
待人工项(单独列):金任务集审定清单的四项人工确认;抽查 seed
的记录与保管;生产抽查比例拍板(默认值 0.10/0.50 只是测试初值)。