| name | arch-check |
| description | 架构与实现审查 —— 基于「概念建模 → 职责划分 → 机制/策略分离 → 因果与不变量 → 属性建模 → 模块化 → SOLID → GRASP → YAGNI」的全维度审查，带置信度门控与假阳性抑制（对抗"过度工程建议"这类 AI slop）。触发于：要求 review/审查架构、检查目录结构/依赖关系/职责划分、重构前评估、技术债盘点、判断是否过度设计，或问「这个设计合理吗 / 该怎么拆 / 有没有循环依赖 / 这个改动架构上 OK 吗」。一律按最高强度审查。用法：`arch-check [范围] [--fix|--plan]`。范围可为目录/文件/PR；缺省审当前分支相对基线的全部变更。 |
Arch Check —— 架构与实现审查
把架构审查做成与代码审查相同的操作流程，而不是一份让人逐条挑刺的清单。核心纪律：只报有把握、有实质影响的问题；架构审查最常见的失败是"建议加更多抽象"——这本身就是要被滤掉的 AI slop。
调用解析
从用户输入里解析两件事（缺省值见下）：
- 范围 (scope)：目录 / 文件 / PR 号 / 「当前分支变更」。
- 动作：缺省出报告；
--plan 出可勾选的重构任务清单；--fix 直接应用低风险重构。
强度恒定：始终按最高强度审——全部 lens（A–E）、fan-out 并行子 agent、依赖图/环检测、对每条 finding 做对抗式复核。不存在"轻审"模式。
两种作用域模式
| 模式 | 何时用 | 审什么 |
|---|
| diff（分支变更） | 在 git 仓库里且用户没给路径 | 当前分支相对基线的全部变更的架构影响：新概念是否放对位置、职责归属、是否引入新耦合/环、是否把策略硬编码进机制、是否破坏既有不变量 |
| audit（全量） | 用户给了目录/文件/模块，或明确要"审整个 X" | 该范围的完整架构体检（下方全部维度） |
diff 范围 = 当前分支相对基线的所有变更（不是只看未提交的）。取变更集：
BASE=$(git merge-base HEAD origin/main 2>/dev/null || git merge-base HEAD main 2>/dev/null || git merge-base HEAD master)
git diff --stat $BASE...HEAD # 已提交的分支变更
git diff --stat # 叠加未提交的工作区改动
git diff $BASE...HEAD # 完整 diff
基线优先级：origin/main → main → master →（都没有则问用户或退回 HEAD~N）。在 base/main 分支本身上、无分叉时，退回审未提交改动；仍为空则提示无变更可审。
缺省判定：给了路径 → audit；没给路径、在 git 仓库 → diff（当前分支全部变更）；不在仓库且没给路径 → 询问要审的范围。
审查 lens（对应 references/，按需加载——不要一次性全读）
审查时只读当前 lens 对应的 reference 文件，不要把全部 reference 一次性读进上下文。
| Lens | 关注 | Reference |
|---|
| A. 概念建模 | 概念识别/命名、抽象质量、封装、实体关系 | references/concept-modeling.md |
| B. 职责与因果 | 职责划分、机制/策略分离、因果与不变量、属性三分(identity/value/derived) | references/responsibility-causality.md |
| C. 结构与依赖 | 目录结构、模块化、依赖方向、循环依赖 | references/structure-modularity.md |
| D. 经典原则 | SOLID、GRASP、YAGNI | references/solid-grasp-yagni.md |
| E. 时间/churn | 共变更耦合、变更热点（上帝文件）、不稳定抽象（仅 git 仓库） | references/cochange-churn.md |
优先级（冲突/取舍时的让步顺序，前者压过后者）：
概念正确性 > 职责归属 > 因果与不变量 > 属性建模 > 依赖方向/环 > 模块内聚 > 文件大小/命名风格
（Lens E 的发现不单独成档，归并到它指向的问题：共变更→概念边界/耦合，热点→职责过载，不稳定抽象→依赖方向。）
接地原则（反幻觉，最高优先）
结构性断言必须先 grep 再下结论，并在 finding 里附 file:line 证据；写不出证据 = 幻觉，不报（置信度封顶 25）。 适用于：依赖/跨层、循环依赖、single-writer/多写者、概念散落、derived 无 invalidation、上帝文件、职责扩散。各语言的依赖/环/写入点探测命令见 references/evidence-and-detection.md。
工作流程
被显式调用即视为值得审，直接开审，不做"值不值得"的门控。
- 采集上下文 + 接地：读取范围内的
AGENTS.md、CLAUDE.md 或仓库提供的等价指令文件（仅记录路径与要点）、列出范围内文件；用 references/evidence-and-detection.md 里的命令实跑依赖/环检测、写入点定位、文件体量。优先用真实工具输出，别凭空想象结构。
- （仅 audit + 大范围）map-first 分诊：先建模块地图，按"最大 / in-degree 最高 / churn 最高"挑出热点，只对热点深挖全 lens，其余轻扫。避免在大仓库里平均用力淹死。
- 按 lens 审查：走全部 lens A–E（E 仅 git 仓库），按优先级顺序，按需加载对应 reference。每个 lens 派一个并行子 agent，各自返回 findings；并发槽不足时分批 fan-out，保持每个 lens 的上下文独立，不得因此跳过 lens。
- 置信度评分 + 复核：对每条 finding 用下方 0–100 细则打分，滤掉 < 80 分的（无证据的结构性断言封顶 25，自动出局）。每条再派独立子 agent 对抗式复核（默认倾向"假阳性"）；并发不足时分批复核。
- 排序：按
严重度 × 置信度 排序。没有过线 finding 就如实说"未发现实质架构问题"。
- 产出：见「输出」。
置信度评分细则（逐条打分，给子 agent 时原样传递）
- 0 — 毫无把握：经不起推敲的假阳性，或是范围外/改动未触及的既有结构。
- 25 — 略有把握：可能是真问题，但无法验证；或是纯风格偏好、团队并未要求的"理想模式"。
- 50 — 中等把握：已确认是真问题，但相对整个范围不重要，或很少在实践中触发。
- 75 — 较高把握：已复核，很可能在实践中造成可维护性/正确性损害；现有结构确实不足。
- 100 — 完全确定：已复核并有直接证据，必然造成问题（如确凿的循环依赖、多写者破坏不变量、概念被实现散落到多处导致改一处漏三处）。
只保留 ≥ 80 分。
严重度定义（决定 🔴/🟡/🟢，与置信度正交）
置信度回答"是不是真的"，严重度回答"有多要紧"——两者独立。
- 🔴 严重：会造成 bug（多写者/竞态/derived 读旧值/破坏不变量），或挡住已知的下一步改动，或正在扩散（concept 已散落多处、churn 热点持续恶化）。
- 🟡 建议：拖慢开发的摩擦——耦合偏高、职责轻微错位、目录与依赖不一致，但暂不致命。
- 🟢 打磨：锦上添花，命名/小重构，不修也能正常演进。
假阳性清单（架构审查专属——这些一律不报）
- 「再加一层抽象会更好」：没有 ≥2 个真实实现/真实变化点的抽象建议 = YAGNI 违规，不报。
- 命名洁癖：不会造成真实歧义的改名建议。
- 团队没要求的"理想架构"：把 DDD/六边形/Clean 架构强加到一个并不需要的项目上。
- pre-existing：diff 模式下，问题在用户没改的行/模块里。
- linter/编译器/类型检查能抓的：import、类型、格式。
- 风格偏好冒充架构问题：除非造成耦合/职责/不变量的实质损害。
- 资深工程师不会拎出来说的吹毛求疵。
- 看着像问题但其实是有意为之、且与本次改动方向一致的设计选择。
输出
默认（报告）：简短、引用 file:line、按严重度分组。不要堆砌通过项；聚焦真问题 + 可操作修复。范围较大或用户要"完整报告"时用 references/report-format.md 的大模板；范围小用下面的精简格式即可。
精简版格式：
## 架构审查（<范围>）
发现 N 个问题（已滤除 <M> 个低置信/假阳性）：
🔴 严重
1. <一句话问题> — `path/to/file.ts:120`
影响：<对可维护性/扩展性/正确性的实质影响>
证据：<关键 file:line 或工具输出片段，可一键核对>
修复：<具体步骤>
🟡 建议
2. ...
✅ 健康：<一句话说哪些维度是好的，可选>
--plan：把上面每条 finding 转成可勾选的重构任务清单（使用当前客户端可用的任务或清单机制；不可用时输出 Markdown checklist），按 Phase（概念澄清 → 结构重组 → 依赖治理）分组，标工作量 S/M/L。
--fix：仅对 🟢/🟡 中低风险、机械、不改公共契约的项直接改（如改名、移动文件归位、提取明显的策略参数）。🔴 概念/职责级重构不自动改——这类需要人确认设计意图，只在报告里给方案。改完逐条说明改了什么。
重要提示
- 先 grep 再下结论：结构性断言（依赖/环/写入点/概念散落）必须有真实代码证据，否则是幻觉，不报。
- 概念优先于结构：先问"概念识别对不对"，再谈文件怎么放。
- 过度工程 = YAGNI 同样危险：审查者的天职不是推销抽象。建议加抽象前先证明有 ≥2 个真实变化点。
- 每条 finding 必须带
file:line、实质影响、证据，否则不报。
- 平衡理想与现实：考虑团队现状和项目阶段，不要拿理想架构碾压可用代码。
