决策讨论:为什么 IHUI-AI 是 17 个 pre-commit 守门钩子?

[IHUI-INF-AI]

💬 决策讨论:为什么 IHUI-AI 是 17 个 pre-commit 守门钩子?

本 Issue 对应 README 故事章节「附录 · 技术决策背后的故事 · 决策 4」
链接:https://github.com/IHUI-INF-AI/IHUI-AI/blob/main/README.md#决策-4--为什么是-17-个-pre-commit-守门钩子

背景

一个独立开发者,没有 code review,没有 QA,没有 CI 团队——如何保证代码质量?

IHUI-AI 的选择

17 个 pre-commit + post-commit + 11 个迁移审计 + 9 个 PowerShell 启动脚本

理由

• 机器代替人 review:17 个守门钩子覆盖 API key 泄露、i18n 键完整性、zh-TW 简体字残留、ko 中文残留、ja 残留、en 破碎机翻、schema drift、dist 陈旧、UTF-8 BOM、API 路由一致性、safeParse 静默忽略、依赖碎片化、skipResponseSanitization、圆角违规、交付报告一致性、grok-build 整合、迁移完整性、CSS 颜色 token 嵌套、原生 title tooltip、staged 污染预警
• 机器代替人 audit:11 个迁移审计脚本 + post-commit 自动 push 钩子,让"commit 后忘记 push"这种协作事故从机制上杜绝
• 机器代替 DevOps:9 个 PowerShell 启动脚本让"启动项目"从"记不住 8 条命令"变成"1 条命令"

代价

钩子偶尔误报,但宁可误报不可漏报。

完整守门清单

#	脚本	用途
1	check-api-key-leak.mjs	API key 泄露
2	check-i18n-keys.mjs	i18n 键完整性
2b	scan-i18n-zh-residue.mjs zh-TW	zh-TW 简体字残留 (opencc 字形转换)
2c	scan-i18n-zh-residue.mjs ko	ko.json 中文残留 (字符范围检测)
2d	scan-i18n-zh-residue.mjs ja	ja.json 中文残留 (warn-only,不阻塞)
2e	check-i18n-broken-en.mjs	en.json 破碎机翻英文
3	check-db-schema-drift.mjs	schema drift
4	check-stale-dist.mjs	packages 陈旧 dist
4b	check-dist-encoding.mjs	packages/*/dist UTF-8 BOM 守门
4c	check-api-client-utf8.mjs	api-client 源码字节级 UTF-8 完整性
5	lint-staged	eslint + prettier
6	check-sanitizer-bypass.mjs	skipResponseSanitization
7	check-dedupe.mjs	依赖碎片化
8	check-api-routes.mjs	前后端路由一致性
9	check-safe-parse.mjs	safeParse 静默忽略(warn-only)
11	check-rounded-full.mjs	容器圆角违规
12	check-delivery-report-consistency.mjs	交付报告一致性
13	check-grokbuild-integration-completeness.mjs	grok-build 整合完整性
13b	check-project-plan-size.mjs	PROJECT_PLAN.md 体积(<50KB)
13c	check-project-plan-archive.mjs	PROJECT_PLAN.md 已完成任务条目防误删
15	check-api-migration-completeness.mjs	迁移完整性
17	check-input-border-var.mjs	CSS 颜色 token 嵌套
18	check-native-title-tooltip.mjs	原生 title tooltip 违规
19	check-staged-pollution.mjs	staged 污染预警(warn-only,跨 ≥ 4 目录)

想听你说

我们愿意被说服。如果你认为守门钩子太多/太少/方向不对,请说明:

1. 哪个钩子该删:具体哪个钩子你认为不应该存在?为什么?
2. 缺哪个钩子:你设想的 IHUI-AI 还应该有什么守门?
3. 误报处理:你如何处理守门钩子误报?(目前策略:宁可误报不可漏报)
4. CI 替代:这些守门是否应该移到 CI 而非 pre-commit?

相关代码

• .husky/pre-commit — pre-commit 钩子入口
• .husky/post-commit — post-commit 自动 push 钩子
• scripts/check-*.mjs — 17 个守门脚本
• scripts/git-push-guard.mjs — post-commit push 守门

---

Labels: discussion architecture ci guardrails