分析构建系统拓扑，识别独立构建单元、多产物风险和版本漂移隐患。
The final gatekeeper. Audits RFCs to reject over-engineering, unnecessary dependencies, and resume-driven development.
使用三维框架（系统设计、运行模拟、工程实现）系统性审查架构和系统设计文档。产出按严重度分级的发现，关联到具体文档段落。
分析 Git 历史，发现"逻辑耦合"（总一起改的文件）和"热点"（高频修改的复杂模块）。基于 Adam Tornhill 的《Your Code as a Crime Scene》方法论。
综合 Scout 阶段所有分析（build-inspector, runtime-inspector, git-forensics, concept-modeler），生成决策就绪的系统风险报告。
分析运行时行为、进程边界和 IPC 机制，检测"协议漂移"风险和进程生命周期问题。
| name | concept-modeler |
| description | 从模糊的用户需求中提取领域概念——实体、流程和"暗物质"（用户没说的）。基于 DDD（领域驱动设计）方法论。 |
"如果你描述不清楚，你就造不出来。" —— Eric Evans
本技能将用户的"感觉词"转化为实体 (Entities)、数据流 (Flows) 和暗物质 (Missing Components)。
[!IMPORTANT] 在执行任何分析之前，你必须调用
sequential thinking工具，视情况进行 3—5 步推理。 思考内容例如：
- "用户说的'同步'是单向还是双向？实时还是批量？"
- "这个'列表'在代码里对应什么？
Wishlist还是ShoppingCart？"- "用户只描述了 Happy Path——如果 X 失败了怎么办？"
- "这个功能需要新的数据库表吗？需要新的 API 端点吗？"
- "有没有隐藏的安全/性能/可靠性问题用户没提？"
从用户的自然语言需求中提取：
Wishlist？ShoppingCart？TodoList？| 类别 | 追问 |
|---|---|
| 错误处理 | 如果 X 失败了怎么办？ |
| 持久化 | 数据存哪里？需要备份吗？ |
| 认证授权 | 谁能访问？如何验证身份？ |
| 日志监控 | 如何知道系统状态？如何调试？ |
| 配置管理 | 硬编码还是外部配置？ |
| 限流熔断 | 高并发时如何保护系统？ |
build-inspector 发现的构建根关联起来。你必须使用 write_to_file 保存到 genesis/v{N}/concept_model.json，格式如下：
{
"entities": [
{ "name": "Wishlist", "type": "数据", "necessity": "必须", "description": "用户的愿望清单" }
],
"flows": [
{ "from": "User", "action": "添加", "to": "Wishlist", "data": "Product ID" }
],
"missing_components": [
{ "component": "错误重试", "category": "错误处理", "priority": "高", "reason": "API 可能超时" }
],
"questions_for_user": [
"同步是实时的还是批量的？"
]
}
scripts/glossary_gen.py --path src/: 从代码中提取候选领域词汇。prompts/GLOSSARY_PROMPT.md: 领域词汇对齐提示词。references/ENTITY_EXTRACTION_PROMPT.md: 完整的实体提取提示词模板（含 Few-Shot 示例）。build-inspector 和 runtime-inspector 揭示了系统是什么。spec-writer 定义系统将变成什么。