# 任务：评估「kms仓(KMC) + kap仓(KAP) 是否应添加 CI 硬门槛」——深度审计报告

你是资深 DevOps/质量工程顾问。Kai 在考虑给两个仓添加 CI 硬门槛，列了三层候选门槛（见下）。
你的任务：**基于两个仓的真实现状，逐项评估每一层每一项该不该上、怎么上、代价多大**，
产出一份带证据的评估报告。这是评估任务，不是实施任务。

## 候选门槛清单（Kai 原案）

**基础底线（所有项目必配）**
1. 编译/构建通过
2. 自动化测试（单元+集成）全部通过
3. Lint/静态检查零错误（风格类可降级为警告）
4. 类型检查通过（TypeScript/mypy 等，强类型项目适用）

**质量红线（防越写越烂）**
5. 圈复杂度上限（单函数 ≤10，超了必须拆）
6. 测试覆盖率下限（总覆盖率渐进提升 + 增量代码 ≥70%）
7. 重复代码率上限
8. 文档-代码一致性检查（接口/参数/配置变了文档必须同步）

**安全防线**
9. 依赖漏洞扫描（Dependabot/Trivy/npm audit，高危直接拦）
10. 敏感信息泄露检查（gitleaks/trufflehog）

## 背景：Hermes 侦查已确认的事实（你需要用证据复核，不要盲信；若发现不符必须指出）

| # | 事实 | 待你验证 |
|---|------|---------|
| F1 | KMC仓 = /data/workspace/kais-hermes-skills（git: github.com/kaiger666888/kais-hermes-skills, branch master）。管线代码 skills/kais-movie-pipeline/pipeline/ 下 63 个 .py 共 ~48.5K LOC | 抽样核实文件数与 LOC |
| F2 | KMC 测试：skills/kais-movie-pipeline/tests/ 下 227 个 test_*.py。仓根无 pytest.ini/pyproject.toml/setup.cfg，无 .github/ → 完全没有 CI | pytest --collect-only 能否干净收集？实际可收集数是多少 |
| F3 | KMC 有自定义检查脚本 scripts/check_manifest_no_bare_except.py、scripts/verify_skill_references.py 等 | 还有哪些 check/verify 脚本？各自做什么 |
| F4 | KAP仓 = /data/workspace/kais-aigc-platform（origin: github.com/kaiger666888/kais-aigc-platform.git, upstream=Toonflow fork, branch master）。src/ 下 294 个 .ts | 核实 |
| F5 | KAP 已有 3 个 workflow：.github/workflows/{debug.yml(构建测试,多平台构建), release.yml, hermes-integration-test.yml} | 逐个读内容：各自触发条件、覆盖什么、是否真正门禁（会不会 continue-on-error/仅 artifact） |
| F6 | KAP package.json：lint=tsc --noEmit（类型检查当 lint 用）、build:server=esbuild 打包、~30个 verify:phase-* 契约脚本、playwright ^1.61.1 在 deps | npm run lint 当前是否零错误（实测，记录耗时）；verify:* 脚本抽测 2-3 个能否跑通 |
| F7 | KAP Makefile 的 test-unit/test-integration 只覆盖 docker/hermes-agent（vendored 源码），src/ 自身 TS 代码未发现任何单测（504 个 *.test.ts 全部在 docker/hermes-agent/_hermes_source/ 内） | 复核：src/ 与根目录 crew-integration-test.js 之外还有没有针对 src/ 的测试 |
| F8 | 两仓都无 git hooks（.git/hooks 只有 sample）；两仓都有 GitHub origin → GitHub Actions 可用 | 确认 |

其他背景（供判断，不必逐条验证）：
- 两仓的日常迭代模式 = Hermes/GLM 老司机批量改码后 commit，历史上出现过「假成功」「桥诚实化止血」类回归（delivered=false 假成功已被修）。评估门槛价值时可引用这类模式。
- KMC 是 skills(markdown)+python管线 混合仓，plugins/ 下还有 6 个子目录（review_gates/kais_aigc 等），注意盘点 plugins 里有没有需要门禁的代码。
- 部分测试可能依赖本地服务(GPU/ComfyUI/KAP:10588)或网络——CI 里跑不了的东西要识别出来并分类。
- 本机可用工具自查：gitleaks/trufflehog/radon/ruff/mypy/jscpd 是否本机已有（which 一下），没有的话评估安装成本即可，不要大装特装。

## 分主题要求

### A. 两仓现状盘点（CI 就绪度基线）
每仓给出：构建命令及当前是否通过（实测+耗时）、测试资产规模与当前通过率（抽样实测，
别全跑 227 个，抽样 15-25 个有代表性的，记录 pass/fail/error/skip 及原因分类）、
静态检查现状、现有 CI 资产盘点、依赖清单规模。

### B. 逐门槛评估（核心，10 项 × 2 仓 = 逐项给结论）
每项统一格式：
- **结论先行**：GO / GO但降级 / NO-GO(暂缓) + 一句话理由
- **现状证据**：file:line 或命令输出摘录
- **落地方式**：具体工具+配置要点+预计工作量（人时）
- **误伤风险**：这个门槛在这仓里会拦住什么正常工作流？（如：管线 py 大量动态构造、
  TS 里 verify 脚本的 any、skills markdown 与代码的双维护成本）
- **对 48K LOC 存量代码的冲击测算**：复杂度/重复率/类型检查这类「红线型」门槛，
  必须实测存量违规量级（如 radon 扫 pipeline 全量给分布直方图数据；tsc 错误计数；
  重复率用抽样估算），给出「全量修复 vs ratchet 渐进」的建议数字

### C. 工具链与运行环境决策
- GitHub Actions vs 本地 hooks(pre-commit) vs 两者组合：结合两仓迭代模式
  （老司机批量 commit、单机开发为主、GitHub 只是备份远端？）给出推荐拓扑。
  关键问题：如果 CI 只在 GitHub 上跑而开发者从不看 PR，硬门槛是否形同虚设？
  local pre-commit + push 后 Actions 兜底的组合是否更符合实际？
- 运行时长预算：每个推荐 gate 预计耗时，能否接受。
- 密钥扫描的 baseline 策略：历史 commit 里已有的旧密钥怎么办（这仓历史上放过 API key 吗？
  可用 gitleaks 对最近 N 个 commit 快速扫一遍给实测答案——只读操作允许）。

### D. 分阶段路线图 + 最终建议
- Phase 0（本周可落）：零风险高收益项清单
- Phase 1：ratchet 型红线项（含基线数字怎么定）
- Phase 2：文档一致性这类高成本项值不值得做、替代方案（如 CLAUDE.md 约定+抽查）
- 明确回答 Kai 的问题：「该不该加」——分层给 verdict，允许结论是「基础底线该上、
  质量红线部分该上、XX 不值得」，不要为了讨好而全 GO。

## 硬性证据约束

- 所有结论必须带证据：命令+输出摘录 或 文件:行号。禁止无证据推断。
- 数字必须实测（LOC、错误数、耗时、违规分布），禁止拍脑袋。不确定标「待验证」。
- 你可以运行只读命令、pytest 收集/抽样执行、tsc --noEmit、npx/pipx 临时工具
  （radon/ruff/gitleaks 允许 pip install --user 或 npx 临时拉取）。
- 禁止：修改两仓任何文件、git push、删除东西、改动全局环境（--user 安装除外）、
  启动常驻服务、占用 GPU。

## 输出契约

完整报告写入 `/tmp/glm-ci-gates-eval.md`（结构清晰，表格优先）。
最后 stdout 输出 ≤400 字中文摘要：两仓各一句话基线 + 三层各自的 verdict +
Phase 0 清单 + 你最有把握的 3 条和最没把握的 3 条。