@haaaiawd/anws 1.2.4 → 2.0.0

package/templates/.agent/skills/concept-modeler/SKILL.md

@@ -1,112 +0,0 @@
----
-name: concept-modeler
-description: 从模糊的用户需求中提取领域概念——实体、流程和"暗物质"（用户没说的）。基于 DDD（领域驱动设计）方法论。
----
-
-# 建模师手册 (The Modeler's Field Guide)
-
-> "如果你描述不清楚，你就造不出来。" —— Eric Evans
-
-本技能将用户的"感觉词"转化为**实体 (Entities)**、**数据流 (Flows)** 和**暗物质 (Missing Components)**。
-
----
-
-## ⚠️ 强制深度思考
-
-> [!IMPORTANT]
-> 在执行任何分析之前，你**必须**调用 `sequential thinking` 工具，视情况进行 **3—5 步**推理。
-> 思考内容例如：
-> 1.  "用户说的'同步'是单向还是双向？实时还是批量？"
-> 2.  "这个'列表'在代码里对应什么？`Wishlist` 还是 `ShoppingCart`？"
-> 3.  "用户只描述了 Happy Path——如果 X 失败了怎么办？"
-> 4.  "这个功能需要新的数据库表吗？需要新的 API 端点吗？"
-> 5.  "有没有隐藏的安全/性能/可靠性问题用户没提？"
-
----
-
-## ⚡ 任务目标
-
-从用户的自然语言需求中提取：
-1.  **实体 (Entities)** - 系统中的"名词"
-2.  **数据流 (Flows)** - "名词"之间的"动词"
-3.  **暗物质 (Missing)** - 用户没说但必须存在的组件
-
----
-
-## 🧭 探索流程 (The Extraction)
-
-### 第一步：名词捕捉 (Noun Hunting)
-*   **输入**: "我想让用户能够*同步*他们的*列表*。"
-*   **建模师追问**: "列表"是什么？`Wishlist`？`ShoppingCart`？`TodoList`？
-*   **老师傅箴言**: 永远不要假设你理解了用户的词汇。**Ubiquitous Language 是 DDD 的核心**。
-*   **输出**: 定义清晰的 **Entity** 列表。
-
-### 第二步：动词分析 (Verb Analysis)
-*   **输入**: "同步。"
-*   **建模师追问**:
-    *   是**单向**还是**双向**？
-    *   是**实时**还是**批量**？
-    *   **失败策略**是什么？重试？回滚？告警？
-*   **老师傅箴言**: 动词决定了系统的复杂度。一个"同步"可能藏着 10 个边界情况。
-*   **输出**: 定义 **Data Flow** 和 **Consistency Model**。
-
-### 第三步：暗物质探测 (Dark Matter Detection)
-*   **老师傅核心定律**: 用户只描述 Happy Path。**你的工作是找到他们没说的一切**。
-*   **检查清单**:
-    | 类别 | 追问 |
-    | :--- | :--- |
-    | **错误处理** | 如果 X 失败了怎么办？ |
-    | **持久化** | 数据存哪里？需要备份吗？ |
-    | **认证授权** | 谁能访问？如何验证身份？ |
-    | **日志监控** | 如何知道系统状态？如何调试？ |
-    | **配置管理** | 硬编码还是外部配置？ |
-    | **限流熔断** | 高并发时如何保护系统？ |
-*   **输出**: 标记 **Missing Components** 及其优先级。
-
----
-
-## 🛡️ 老师傅守则
-
-1.  **不要编造**: 如果信息不足，把问题列出来让用户澄清。
-2.  **保守估计**: 宁可多识别缺失组件，也不要遗漏。
-3.  **解释推理**: 对每个判断提供理由。
-4.  **关联构建信息**: 将识别出的 Entities 与 `build-inspector` 发现的构建根关联起来。
-
----
-
-## 📤 输出格式
-
-你**必须**使用 `write_to_file` 保存到 `genesis/v{N}/concept_model.json`，格式如下：
-
-```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 示例）。
-
----
-
-## Collaboration
-
-*   **Before**: `build-inspector` 和 `runtime-inspector` 揭示了*系统是什么*。
-*   **After**: `spec-writer` 定义*系统将变成什么*。
-*   **Synergy**: 你的领域模型将帮助 Scout 的功能冲突分析更精准。

package/templates/.agent/skills/concept-modeler/prompts/GLOSSARY_PROMPT.md

@@ -1,40 +0,0 @@
-# Ubiquitous Language Extraction Prompt
-
-## Role
-You are a **Domain Linguist** and **DDD Practitioner**. Your job is to facilitate communication between developers and domain experts by extracting a **Ubiquitous Language** dictionary.
-
-## Goal
-Analyze the provided code and documentation to extract the core vocabulary of the domain. We want to identify the "Nouns" (Entities/Value Objects) and "Verbs" (Domain Events/Actions) that constitute the language of this project.
-
-## Input Context
-- **Code Identifiers**: Class names, Struct names, Public Function names.
-- **Documentation text**: User stories, comments.
-
-## Output Format
-Generate a Markdown Glossary table.
-
-### Format Template
-```markdown
-# Domain Glossary (Ubiquitous Language)
-
-## Entities (Nouns)
-| Term | Definition | Code Mappings |
-|---|---|---|
-| User | A registered person who uses the system. | `src/models/User.rs`, `database.users` |
-| Prompt | A text template used for AI generation. | `src/models/Prompt.ts` |
-
-## Actions (Verbs)
-| Term | Definition | Code Mappings |
-|---|---|---|
-| Generate | The process of creating content using AI. | `service/Generator.run()` |
-| Inject | Inserting the generated text into an active window. | `service/Injector.inject()` |
-
-## Inconsistencies Detected
-> [!WARNING]
-> - **Client vs User**: Code uses `Client`, docs use `User`. Recommended: Unify to `User`.
-```
-
-## Constraints
-- **Ignore** technical terms (e.g., "Integer", "HTTP Request"). Focus on DOMAIN terms.
-- **Merge** synonyms if they clearly refer to the same thing, but note the inconsistency.
-- Definitions should be **business-centric**, not code-centric.

package/templates/.agent/skills/concept-modeler/references/ENTITY_EXTRACTION_PROMPT.md

@@ -1,299 +0,0 @@
-# 实体提取 Prompt 模板 - 完整版
-
-## 概述
-
-此 Prompt 用于从用户的自然语言描述中提取系统的逻辑模型。基于 2024 年 LLM Prompt 工程最佳实践设计。
-
-## 设计原则
-
-基于调研的最佳实践：
-
-1. **明确指令**：清晰陈述任务和期望的实体类型
-2. **Few-shot 示例**：提供示例帮助模型理解格式
-3. **Chain-of-Thought**：引导模型逐步推理
-4. **Role Prompting**：赋予模型专家身份
-5. **JSON 输出**：明确指定结构化输出格式
-6. **"Give LLM an Out"**：允许模型表示不确定性
-
----
-
-## 主 Prompt 模板
-
-```markdown
-# 角色定义
-
-你是一名拥有 15 年经验的资深系统架构师。你的专长是：
-- 从模糊需求中提取精确的系统模型
-- 识别用户遗漏的关键组件
-- 预判潜在的架构风险和耦合问题
-- 设计可扩展、可维护的系统架构
-
-# 任务
-
-用户想要构建以下系统/功能：
-
----
-{{USER_INPUT}}
----
-
-请执行以下 **结构化分析**，按步骤推理：
-
-## 第 1 步：实体提取 (Entity Extraction)
-
-列出这个系统中必须存在的所有核心"名词"。
-
-思考方向：
-- 用户/角色类：谁会使用这个系统？
-- 数据/资源类：系统处理什么数据？
-- 服务/组件类：需要哪些独立的服务模块？
-- 外部依赖类：需要对接哪些外部 API 或服务？
-- 基础设施类：需要什么存储、缓存、队列？
-
-对于每个实体，评估其 **必要性**：
-- [必须] = 没有这个系统无法运行
-- [应该] = 没有这个会严重影响体验
-- [可选] = 增强功能，可后续添加
-
-## 第 2 步：数据流分析 (Data Flow Analysis)
-
-描述数据如何在这些实体之间流转。
-
-使用格式：
-```
-[源实体] --[动作/数据]--> [目标实体]
-```
-
-重点考虑：
-- 主流程（Happy Path）是什么？
-- 数据在哪些点会被转换或处理？
-- 哪些是同步操作，哪些应该异步？
-
-## 第 3 步：缺失检测 (Missing Component Detection)
-
-**这是最关键的一步**。根据你的经验，主动识别用户描述中 **遗漏** 的关键组件：
-
-检查清单：
-- [ ] **错误处理**：如果 X 失败了怎么办？重试？回滚？
-- [ ] **数据持久化**：数据存在哪里？需要备份吗？
-- [ ] **认证授权**：谁能访问什么？如何验证身份？
-- [ ] **日志监控**：如何知道系统状态？如何调试问题？
-- [ ] **队列/缓存**：是否需要异步处理？是否需要缓存热点数据？
-- [ ] **配置管理**：hardcode 还是外部配置？环境差异如何处理？
-- [ ] **限流/熔断**：高并发时如何保护系统？
-- [ ] **幂等性**：重复请求会怎样？
-
-对于每个缺失项，解释 **为什么需要** 以及 **如果没有会怎样**。
-
-## 第 4 步：风险识别 (Risk Identification)
-
-预判潜在的问题（即使用户没问）：
-
-风险类型：
-- **耦合风险**：哪些组件之间可能产生不健康的依赖？
-- **性能风险**：哪里可能成为瓶颈？
-- **可靠性风险**：哪里可能导致级联故障？
-- **安全风险**：哪里可能有安全漏洞？
-- **扩展性风险**：当规模增长 10 倍时，哪里会先出问题？
-
-## 第 5 步：边界定义 (Boundary Definition)
-
-建议如何划分模块边界以降低耦合：
-
-- 哪些组件应该放在一起（高内聚）？
-- 哪些组件应该分离（低耦合）？
-- 接口应该如何设计？
-
----
-
-# 输出格式
-
-严格按照以下 JSON 格式输出：
-
-```json
-{
-  "entities": [
-    {
-      "name": "实体名称",
-      "type": "用户|数据|服务|外部|基础设施",
-      "necessity": "必须|应该|可选",
-      "description": "简要描述"
-    }
-  ],
-  "data_flows": [
-    {
-      "from": "源实体",
-      "action": "动作描述",
-      "to": "目标实体",
-      "data": "传递的数据",
-      "sync": true
-    }
-  ],
-  "missing_components": [
-    {
-      "component": "缺失组件名称",
-      "category": "错误处理|持久化|安全|监控|性能|配置",
-      "reason": "为什么需要",
-      "impact_if_missing": "如果没有会怎样",
-      "priority": "高|中|低"
-    }
-  ],
-  "potential_risks": [
-    {
-      "risk_type": "耦合|性能|可靠性|安全|扩展性",
-      "description": "风险描述",
-      "affected_entities": ["相关实体"],
-      "mitigation": "建议的缓解措施"
-    }
-  ],
-  "boundary_recommendations": [
-    {
-      "module_name": "模块名称",
-      "contains": ["包含的实体"],
-      "rationale": "为什么这样划分"
-    }
-  ],
-  "questions_for_user": [
-    "如果有不确定的地方，列出需要用户澄清的问题"
-  ]
-}
-```
-
-# 重要提示
-
-1. **不要编造**：如果信息不足，在 `questions_for_user` 中列出问题
-2. **保守估计**：宁可多识别缺失组件，也不要遗漏
-3. **解释推理**：对每个判断提供理由
-4. **实际经验**：基于真实系统设计经验，而不是理论
-```
-
----
-
-## Few-Shot 示例
-
-### 示例输入
-
-```
-我想做一个"视频摘要生成器"：用户上传视频，系统用 Whisper 转文字，
-然后用 GPT 生成摘要，最后返回给用户。
-```
-
-### 示例输出
-
-```json
-{
-  "entities": [
-    {"name": "User", "type": "用户", "necessity": "必须", "description": "上传视频并获取摘要的用户"},
-    {"name": "VideoFile", "type": "数据", "necessity": "必须", "description": "用户上传的视频文件"},
-    {"name": "VideoUploader", "type": "服务", "necessity": "必须", "description": "处理视频上传的服务"},
-    {"name": "TranscriptionService", "type": "服务", "necessity": "必须", "description": "调用 Whisper API 转文字"},
-    {"name": "SummaryService", "type": "服务", "necessity": "必须", "description": "调用 GPT 生成摘要"},
-    {"name": "WhisperAPI", "type": "外部", "necessity": "必须", "description": "OpenAI Whisper 语音识别"},
-    {"name": "GPT_API", "type": "外部", "necessity": "必须", "description": "OpenAI GPT 文本生成"},
-    {"name": "FileStorage", "type": "基础设施", "necessity": "必须", "description": "存储上传的视频和生成的摘要"},
-    {"name": "TaskQueue", "type": "基础设施", "necessity": "应该", "description": "异步处理视频任务"}
-  ],
-  "data_flows": [
-    {"from": "User", "action": "上传", "to": "VideoUploader", "data": "视频文件", "sync": true},
-    {"from": "VideoUploader", "action": "存储", "to": "FileStorage", "data": "视频文件", "sync": true},
-    {"from": "VideoUploader", "action": "创建任务", "to": "TaskQueue", "data": "任务ID", "sync": true},
-    {"from": "TaskQueue", "action": "触发", "to": "TranscriptionService", "data": "视频路径", "sync": false},
-    {"from": "TranscriptionService", "action": "调用", "to": "WhisperAPI", "data": "音频数据", "sync": true},
-    {"from": "TranscriptionService", "action": "传递", "to": "SummaryService", "data": "文字内容", "sync": true},
-    {"from": "SummaryService", "action": "调用", "to": "GPT_API", "data": "文字内容", "sync": true},
-    {"from": "SummaryService", "action": "存储", "to": "FileStorage", "data": "摘要结果", "sync": true}
-  ],
-  "missing_components": [
-    {
-      "component": "任务状态追踪",
-      "category": "监控",
-      "reason": "用户上传后需要知道处理进度",
-      "impact_if_missing": "用户无法知道视频是否处理完成，体验极差",
-      "priority": "高"
-    },
-    {
-      "component": "API 调用重试机制",
-      "category": "错误处理",
-      "reason": "Whisper/GPT API 可能超时或失败",
-      "impact_if_missing": "单次失败导致整个任务失败，浪费用户时间",
-      "priority": "高"
-    },
-    {
-      "component": "视频大小/时长限制",
-      "category": "性能",
-      "reason": "大视频会导致处理时间过长和成本过高",
-      "impact_if_missing": "用户可能上传几GB的视频导致系统崩溃",
-      "priority": "高"
-    },
-    {
-      "component": "费用追踪/计费",
-      "category": "配置",
-      "reason": "API 调用有成本，需要追踪",
-      "impact_if_missing": "无法控制成本，可能产生意外账单",
-      "priority": "中"
-    }
-  ],
-  "potential_risks": [
-    {
-      "risk_type": "性能",
-      "description": "视频处理是 CPU/内存密集型，大视频可能导致 OOM",
-      "affected_entities": ["TranscriptionService"],
-      "mitigation": "限制视频大小，使用流式处理"
-    },
-    {
-      "risk_type": "可靠性",
-      "description": "如果 TaskQueue 宕机，所有待处理任务丢失",
-      "affected_entities": ["TaskQueue"],
-      "mitigation": "使用持久化队列（如 Redis + 持久化）"
-    },
-    {
-      "risk_type": "耦合",
-      "description": "TranscriptionService 和 SummaryService 如果同步调用，一个慢会拖慢整个流程",
-      "affected_entities": ["TranscriptionService", "SummaryService"],
-      "mitigation": "考虑将两个服务通过队列解耦"
-    }
-  ],
-  "boundary_recommendations": [
-    {
-      "module_name": "上传模块",
-      "contains": ["VideoUploader", "FileStorage"],
-      "rationale": "上传和存储紧密相关，应该放在一起"
-    },
-    {
-      "module_name": "处理模块",
-      "contains": ["TranscriptionService", "SummaryService", "TaskQueue"],
-      "rationale": "视频处理流程，通过队列异步执行"
-    },
-    {
-      "module_name": "外部集成层",
-      "contains": ["WhisperAPI", "GPT_API"],
-      "rationale": "所有外部 API 调用应该通过统一的适配层，方便切换供应商"
-    }
-  ],
-  "questions_for_user": [
-    "视频支持的最大时长/大小是多少？",
-    "用户是否需要实时查看处理进度？",
-    "摘要结果需要保留多久？"
-  ]
-}
-```
-
----
-
-## 追问策略
-
-如果初始分析不够深入，使用以下追问：
-
-1. **边界追问**："如果 [实体A] 出错了，[实体B] 会怎样？"
-2. **规模追问**："如果有 10000 个用户同时使用，哪里会先崩？"
-3. **演化追问**："6 个月后如果要加 [新功能]，需要改动哪些组件？"
-4. **成本追问**："这个架构的运维成本主要在哪里？"
-5. **安全追问**："如果有恶意用户尝试攻击，最薄弱的环节是哪里？"
-
----
-
-## 与其他 Skills 的配合
-
-- 对于 **Brownfield** 模式：先用 `build-inspector` 分析构建边界，用 `runtime-inspector` 分析 IPC，再用此 Prompt 分析新功能
-- 分析结果应传递给 Scout 的功能冲突分析（Step 6）和最终报告生成
-- 识别的缺失组件应在后续 Blueprint 阶段详细设计
-

package/templates/.agent/skills/concept-modeler/scripts/glossary_gen.py

@@ -1,66 +0,0 @@
-import os
-import argparse
-import json
-import re
-
-# Simple regex for finding potential domain terms (Classes, Structs)
-# This is a heuristic. For better results, use the tree-sitter slice we built earlier.
-# But for "Concept Modeling" of a whole repo, a fast scan is often enough to start.
-
-PATTERNS = {
-    'python': [r'class\s+([A-Z][a-zA-Z0-9_]*)'],
-    'rust': [r'struct\s+([A-Z][a-zA-Z0-9_]*)', r'enum\s+([A-Z][a-zA-Z0-9_]*)'],
-    'javascript': [r'class\s+([A-Z][a-zA-Z0-9_]*)', r'interface\s+([A-Z][a-zA-Z0-9_]*)'],
-    'typescript': [r'class\s+([A-Z][a-zA-Z0-9_]*)', r'interface\s+([A-Z][a-zA-Z0-9_]*)', r'type\s+([A-Z][a-zA-Z0-9_]*)']
-}
-
-def scan_identifiers(root_dir: str):
-    terms = set()
-    
-    for root, _, files in os.walk(root_dir):
-        for file in files:
-            ext = os.path.splitext(file)[1]
-            lang = None
-            if ext == '.py': lang = 'python'
-            elif ext == '.rs': lang = 'rust'
-            elif ext in ['.js', '.jsx']: lang = 'javascript'
-            elif ext in ['.ts', '.tsx']: lang = 'typescript'
-            
-            if lang:
-                try:
-                    with open(os.path.join(root, file), 'r', encoding='utf-8') as f:
-                        content = f.read()
-                        
-                    for pat in PATTERNS[lang]:
-                        matches = re.finditer(pat, content)
-                        for m in matches:
-                            terms.add(m.group(1))
-                except Exception:
-                    pass
-                    
-    return sorted(list(terms))
-
-def main():
-    parser = argparse.ArgumentParser(description="Generate Glossary Context")
-    parser.add_argument("--path", required=True, help="Repo path")
-    parser.add_argument("--output", "-o", help="Output JSON file for LLM")
-    
-    args = parser.parse_args()
-    
-    print(f"Scanning for domain terms in {args.path}...")
-    terms = scan_identifiers(args.path)
-    
-    result = {
-        "candidate_terms": terms,
-        "instruction": "The above terms were extracted from the codebase. Please filter out technical terms (like 'Config', 'Factory') and keep only Domain Terms."
-    }
-    
-    if args.output:
-        with open(args.output, 'w') as f:
-            json.dump(result, f, indent=2)
-        print(f"Context saved to {args.output}")
-    else:
-        print(json.dumps(result, indent=2))
-
-if __name__ == "__main__":
-    main()

package/templates/.agent/skills/git-forensics/SKILL.md

@@ -1,74 +0,0 @@
----
-name: git-forensics
-description: 分析 Git 历史，发现"逻辑耦合"（总一起改的文件）和"热点"（高频修改的复杂模块）。基于 Adam Tornhill 的《Your Code as a Crime Scene》方法论。
----
-
-# 考古学家手册 (The Archaeologist's Field Notes)
-
-> "历史不会重复，但会押韵。静态分析告诉你结构，Git 取证告诉你痛苦的真相。" —— Adam Tornhill
-
-本技能基于 **Adam Tornhill 的《Your Code as a Crime Scene》** 方法论。
-核心思想：代码的**演化历史**比代码本身更能揭示设计问题。
-
----
-
-## ⚠️ 强制深度思考
-
-> [!IMPORTANT]
-> 在执行任何分析之前，你**必须**调用 `sequential thinking` 工具，视情况进行 **2—3 步**推理。
-> 思考内容例如：
-> 1.  "这个项目的 Git 历史有多深？是否需要 `git fetch --unshallow`？"
-> 2.  "我应该关注哪个时间范围？（最近 3 个月？1 年？）"
-> 3.  "有没有明显的'噪音文件'（如 `package-lock.json`）需要排除？"
-
----
-
-## ⚡ 快速启动
-1.  **耦合分析**: `python scripts/git_forensics.py --repo . --threshold 0.3`
-2.  **热点探测**: `python scripts/git_hotspots.py --repo . --days 180`
-
----
-
-## 🧭 探索流程 (The Dig)
-
-### 第一步：感知时间流 (The Tornhill Method)
-*   **老师傅箴言**: "代码的价值不是它是什么，而是它是如何变成这样的。"
-*   运行 `git log --oneline -n 100`，快速感知项目近期活跃度。
-*   **关键推断**: 如果最近 50 次提交都只涉及一两个目录，那就是"震中"——最可能藏有风险的地方。
-
-### 第二步：发现隐性耦合 (Temporal Coupling / Change Coupling)
-*   **核心问题**: "有没有两个文件，它们在代码里**没有** `import`/`use` 关系，但 **70%** 的提交都一起出现？"
-*   **老师傅警报 (来自 Adam Tornhill)**:
-    *   ⚠️ **逻辑耦合但物理分离** -> 这是"架构腐烂 (Architectural Decay)"的强信号！
-    *   ⚠️ **跨构建根的耦合** -> 如果 `service/ipc.rs` 总和 `gui/api.ts` 一起改，但它们属于不同构建根，这是**版本漂移**的温床！
-    *   **处方**: 要么合并它们到同一模块，要么抽象出共享的 Schema/契约层。
-
-### 第三步：定位热点 (Hotspot Analysis - CodeScene Methodology)
-*   **公式**: 热点 = 高变更频率 (Churn) × 高复杂度 (Complexity)
-*   **老师傅策略矩阵 (来自 CodeScene)**:
-
-    | | 低复杂度 | 高复杂度 |
-    | :---: | :---: | :---: |
-    | **高 Churn** | 配置/生成代码，可忽略 | 🔴 **优先重构！Bug 温床，ROI 最高** |
-    | **低 Churn** | 稳定模块，别动 | 🟡 遗留雷区，小心翼翼 |
-
-*   **老师傅建议**: 重构资源有限时，**只攻高 Churn + 高 Complexity 的象限**。这是投资回报率最高的地方。
-
----
-
-## 🛡️ 老师傅守则
-
-1.  **先取消浅克隆**: `git fetch --unshallow`。没有历史 = 没有数据 = 你是盲人。
-2.  **过滤噪音**: 忽略 `package-lock.json`, `Cargo.lock`, `*.min.js`, `dist/` 等生成物。它们会污染你的分析结果。
-3.  **警惕大规模重命名**: 重命名 (`git mv`) 会干扰追踪。如果发现诡异的耦合数据，手动检查是否是重命名导致。
-4.  **关联构建信息**: 在输出耦合对时，**标注它们分别属于哪个构建根**。这是连接 Git 分析和 Build 分析的关键桥梁。
-
----
-
-## 📤 输出清单
-
-1.  **Coupling Pairs (耦合对)**: Score > 0.7 的文件对。**标注它们的构建根**。
-2.  **Cross-Root Couplings (跨根耦合)**: 重点标记！如果两个高耦合文件属于不同构建根，这是**头号风险**。
-3.  **Hotspots (热点)**: 高风险模块列表 (高 Churn + 高 Complexity)。
-4.  **Orphans (孤儿)**: 超过 1 年无人触碰的文件（知识腐烂警告）。
-5.  **Refactoring Priority**: 根据 Churn/Complexity 矩阵给出建议的重构优先级。