Menu
基于 knowledge-graph 模块依赖 + mvp-approach 边界条件 + task-graph 任务清单，生成可修改文件白名单和禁止触碰红区。防止 Agent 无意中修改核心模块。
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | implementation-map |
| description | 基于 knowledge-graph 模块依赖 + mvp-approach 边界条件 + task-graph 任务清单，生成可修改文件白名单和禁止触碰红区。防止 Agent 无意中修改核心模块。 |
| argument-hint | lock the boundary | show what I can modify | implementation map |
| dependencies | {"upstream":["mvp-approach","knowledge-graph","task-graph"],"downstream":["verification-loop","engineering-loop"]} |
代码修改前最后一道门。 在 Agent 动手写代码之前，本 skill 精确回答三个问题：
输出写入 .repo-loop-state.json 的 bound.implementationMap 字段。
[1] .repo-loop-state.json 中 observe.outputs.knowledgeGraph 非空？
NO → STOP. "❌ 需要先运行 knowledge-graph"
[2] .repo-loop-state.json 中 observe.outputs.mvpApproach 非空？
NO → STOP. "❌ 需要先运行 mvp-approach"
[3] .repo-loop-state.json 中 plan.taskGraph 非空？
NO → STOP. "❌ 需要先运行 task-graph"
从 task-graph 中汇总所有任务的目标文件：
遍历 plan.taskGraph.nodes[].title → 提取文件路径
去重 → 候选修改文件列表
对每个候选文件，查它在 knowledge-graph 中的位置：
查询:
- 所在模块的扇出 (fanOut) → 它依赖了多少模块
- 所在模块的扇入 (fanIn) → 多少模块依赖它
- 是否在循环依赖环上
- 是否在核心调用链上 (mvp-approach 🔴 路径)
判定:
fanIn ≥ 5 → ⚠️ 高风险（修改影响面大）
fanOut ≥ 7 → ⚠️ 高风险（模块职责可能过重，改动易引入副作用）
在循环依赖环上 → 🔴 禁止修改（除非本轮目标就是解环）
不在 task-graph 的任何任务中 → 不列入白名单
边界检查:
白名单文件数 ≤ mvp-approach 设定的文件数上限？
白名单预估总行数 ≤ mvp-approach 设定的行数上限？
超出 → 回到 mvp-approach 重新剪裁或拆分 Phase
以下文件/目录自动进入禁止触碰红区：
红区规则:
1. 扇入 ≥ 5 且不在本次任务的依赖链上 → 红区（公共模块，改动影响面大）
2. 扇出 ≥ 7 的模块 → 红区（除非本轮目标明确包含它）
3. 核心类型/接口定义文件 → 红区（破坏公共 API）
4. 构建配置文件 (Makefile/CMakeLists/package.json scripts) → 红区（除非本轮目标就是改构建）
5. 测试基础设施 (jest.config/vitest.config) → 红区（除非本轮目标就是改测试配置）
不是所有红区都能从 fanIn/fanOut 推出来。 很多项目的核心约束写在文档里——README、CONTRIBUTING、docs 中的"你不能在这里加逻辑""这个模块只做 thin adapter""公共 API 不可破坏"。这些是架构契约。
抽取方法：
1. 扫描以下文件:
README.md / README.rst → 搜索 "must" / "should not" / "不可" / "禁止" / "only"
CONTRIBUTING.md → 搜索 "never" / "do not" / "convention"
docs/*.md → 搜索 "contract" / "boundary" / "public API"
2. 提取以下模式:
"[模块] 只能做 X，不能做 Y" → architectureContract
"[路径] 不能新增 Z" → architectureContract
"public API [函数/类] 不可破坏" → architectureContract
"middleware is thin adapter only" → architectureContract
3. 每个契约转为红区规则:
{
"source": "README.md:45",
"rule": "middleware packages must remain thin adapters",
"paths": ["packages/middleware/*"],
"enforcement": "forbidden unless goal explicitly targets middleware contract"
}
示例（来自 mcp-sdk）：
{
"architectureContracts": [
{
"source": "packages/middleware/README.md:3",
"rule": "thin integration layer only — no MCP business logic",
"paths": ["packages/middleware/*"],
"enforcement": "forbidden unless goal explicitly targets middleware"
}
]
}
合并到红区： 架构契约路径自动合并到 forbiddenZones。
写入 .repo-loop-state.json → bound.implementationMap：
{
"implementationMap": {
"allowedFiles": [
{
"path": "src/auth/login.ts",
"reason": "新增登录端点 — task T-1-3",
"maxLines": 80,
"taskId": "T-1-3",
"module": "src/auth",
"fanIn": 1,
"fanOut": 2,
"risk": "低"
},
{
"path": "src/auth/jwt.ts",
"reason": "JWT 签发/验证 — task T-1-2",
"maxLines": 60,
"taskId": "T-1-2",
"module": "src/auth",
"fanIn": 0,
"fanOut": 0,
"risk": "低"
}
],
"forbiddenZones": [
{ "path": "src/db/", "reason": "用户约束：不修改现有数据库 schema" },
{ "path": "src/core/engine.ts", "reason": "核心引擎 — fanIn=8，修改影响面大" },
{ "path": "src/types/types-external.ts", "reason": "公共 API 类型定义 — fanIn=12" },
{ "path": "vitest.config.ts", "reason": "测试基础设施 — 红区规则 #5" }
],
"blastRadiusWarnings": [
{
"change": "修改 src/auth/login.ts 的 import",
"affectedModules": ["src/api", "src/middleware"],
"risk": "低",
"reason": "login.ts 是新文件，import 变更只影响自身"
},
{
"change": "修改 src/middleware/index.ts（挂载 authMiddleware）",
"affectedModules": ["src/api (所有路由)", "src/ui (登录页面)"],
"risk": "中",
"reason": "middleware/index.ts 的 fanIn=5，是请求管道的必经节点"
}
],
"summary": {
"allowedCount": 3,
"forbiddenCount": 4,
"warnings": 2,
"withinBounds": true,
"boundaryCheck": "3 文件 / 190 行 ≤ Web API 上限 (5 文件 / 500 行)"
}
}
}
| # | Agent 借口 | 反驳 |
|---|---|---|
| 1 | "这个文件就在旁边，顺便改一下" | 不在白名单 → 不允许。'顺便改'是 scope creep 的 #1 入口 |
| 2 | "红区里的文件我只加一行注释" | 红区 = 零触碰。注释也是修改，git blame 会记录 |
| 3 | "blast radius 只是警告，不影响执行" | 警告意味着修改前需要额外验证。忽略 → 事故 |
| 4 | "白名单太少了，加两个文件无所谓" | 白名单扩张 → 边界超限。回 mvp-approach 重新剪裁 |
.repo-loop-state.json → bound.implementationMap上下文园艺师 — 先读项目，再读 CLAUDE.md，逐层审计四层架构（CLAUDE.md → skills/ → hooks/ → memory/）。不做代码修改，只做审查、总结、归纳。生成建议报告，可视化花园输出。
将 repo-decompose 需求树 + mvp-approach 核心路径转化为分阶段可执行的交付计划。每个 Phase 有明确目标、任务清单、验收标准和依赖关系。
代码优化循环总控 — 12 阶段生命周期（2 前置门控 Detect+EnvReady，10 阶段优化闭环 Observe→Understand→Diagnose→Plan→Bound→Fix→Verify→SelfReview→Learn→Decide）。跨 Agent 自适应，环境自动就绪，任务驱动单流程。
代码知识图谱 — 四层递进分析（符号表→调用链→数据流→模块依赖），产出完整结构化 Markdown 技术文档供 Loop Agent 和开发者阅读。每个文件有详细分析、每段关键代码有决策解释、模块间有影响矩阵。
循环日志管理 — 每个阶段产出结构化 markdown 日志，记录完整分析过程，可追溯、可检索。自动保存到 .loop-log/，支持按阶段/日期/关键词检索。
最小可行性方案 — 基于已完成的全项目分析（repo-decompose + knowledge-graph + semantic-rag），设定最严格的最小边界条件，剪裁出刚好能跑的核心路径。