BP 目标体系全面审计 — 索引

本文件提供能力宪章 + 能力树 + 按需加载规则。详细审计规则见 references/，使用示例见 examples/。

当前版本: v3.5 (Write Support for Child KR/Action)

接口版本: 所有业务接口统一使用 /open-api/bp/* 前缀，自带 appKey Header 鉴权，不依赖网关。

审计执行核心原则（Mandatory）

1. 1. 问题与建议对齐：每次审计输出问题清单时，必须同时输出对应的修改建议（Action/Recommendation）。严禁只抛出问题而不给方案。
2. 灵活的向上承接：

- 允许创新目标：组织和个人 BP 均允许存在“非承接性”的目标（即无向上对齐的目标）。这被视为局部主动性或业务创新，不应判定为严重错误。 - 内容大于形式：组织和个人 BP 的内容范畴均允许大于上级要求的范畴。 - 审计动作：若发现无向上对齐的目标，仅需记录并提醒用户核实是否为有意为之，标注为“轻微：核实是否为自主创新/非承接项”。

1. 3. 内容穿透要求：虽然允许创新，但组织 BP 必须确保上级下达的任务在下级有明确 ID 承接。
2. 权重强制原则：所有审计输出（无论是组织还是个人 BP）必须包含建议权重（提供初始建议值）。即便系统中权重字段为空，也必须根据战略重要性给出建议权重。

审计模式核心差异：组织 BP vs. 个人 BP

为了确保审计深度符合管理要求，审计时必须根据被审计对象的类型（组织 vs. 个人）应用差异化规则：

1. 组织 BP (Organizational BP) — 侧重“战略闭环与责任分解”

• - 核心逻辑：组织 BP 是战略承接的载体。
• 输出要求：必须包括 BP 内容检查、向上对齐审计、向下承接审计、修改建议、建议权重（仅提供初始值）。
• 目标命名：必须是“组织状态”的静态定格（如：XX中心年度营收目标已达成）。
• 审计深度 (必检)：

- 向下承接闭环：组织目标的每一个 KR 和 Action 必须有对应的子部门或子组织负责人。严禁“悬空举措”（举措没人接）。 - 跨部门协同：涉及多部门的 Action，必须检查协作边界和主责部门。 - 战略覆盖率：必须检查上级（集团/中心）的核心要求是否在下级部门中被“全量承接”，不能漏项。

2. 个人 BP (Individual BP) — 侧重“个人承诺与因果逻辑”

• - 核心逻辑：个人 BP 是岗位职责与贡献的承诺。
• 输出要求：必须包括 BP 内容检查、向上对齐审计、修改建议、建议权重（仅提供初始值）。
• 目标命名：必须是“个人承诺状态”的静态定格（如：本人负责的XX项目交付已完成）。
• 审计深度 (必检)：

- 人责匹配 (Personnel Rule)：硬性校验「下级目标责任人 = 上级组织 Action 承接人」。 - G-R-A 因果律：审计 KI 是否真的能推导出 KR，KR 是否足以验证 Goal。拒绝“为了写而写”的废话举措。 - SMART 衡量标准：KR 必须具备可审计的数据源（SAP/CRM 等）和明确的正负偏差阈值。

五大审计板块

#	板块	说明	规则文档
1	基础合规性审计	BP 本身信息检查：结构完整性、内容质量、逻辑自洽性	INLINECODE6
2

向上对齐审计 | 我和上级的承接：对齐正确性、对齐完整性、人员匹配 | references/upward-check-rules.md | | 3 | 向下承接审计 | 下级跟我的承接：承接正确性、完整性、数值覆盖、协作约束 | references/downward-check-rules.md | | 4 | GAP 差异分析 | 拉通上下级差异：承接差、执行差、逻辑差 | references/gap-analysis-rules.md | | 5 | 数值对齐审计 | 从“提数字”到“定义数字”：数值定义、属性、算法、关联场景 | references/numerical-audit-rules.md |

板块一：基础合规性审计（BP 本身信息）

检查点	说明	严重等级
结构完整性	必须包含 G-R-A 三层结构，层级深度符合组织要求	严重
内容质量

描述是否具体、可衡量、有明确行动指向 | 一般 | | 逻辑自洽 | KI 是否能推导出 KR 的达成，KR 是否能验证 Goal 的完成 | 严重 | | 衡量标准 SMART | KR 衡量标准是否满足 SMART + 最小完备要求 | 严重 | | 汇报周期 | 举措周期 ≤ KR周期 ≤ 目标周期 | 一般 | | 举措颗粒度 | 举措是否具体可执行、可承接 | 一般 | | 语义定义 | 目标禁动词、KR 描述可验收状态、举措描述具体行动 | 一般 | | 必填项完整 | 责任人/承接人、起止时间、汇报周期是否填写 | 严重 |

板块二：向上对齐审计（我和上级的承接）

检查点	说明	严重等级
对齐正确性	完整结构是否支撑上级意图（严禁只看名称）	严重
衡量标准支撑

KR 衡量标准能否支撑上级要求的达成 | 严重 | | 行动方向一致 | KI 行动方向是否与上级意图吻合 | 一般 | | 人员匹配 | 下级目标责任人 = 上级举措承接人 | 严重 | | 对齐完整性 | 是否存在选择性承接 or 职责盲区 | 严重 | | 层级正确性 | 对齐路径是否符合层级规则（中心→集团KR，部门→中心KI，员工→部门KI） | 严重 |

板块三：向下承接审计（下级跟我的承接）

仅在有下级数据（向下承接 非空，即 Markdown 中非 向下承接：无）时执行。

检查点	说明	严重等级
承接正确性	下级目标完整结构是否正确承接本级任务	严重
承接身份匹配

上级举措承接人 = 下级目标责任人 | 严重 |
| 承接完整性 | 核心任务是否有人承接，是否存在悬空 | 严重 |
| 多承接协作 | 多部门承接时交付物边界是否明确 | 一般 |
| 冗余性 | 是否存在不合理的重复承接 | 轻微 |
| 数值指标覆盖 | 数值类指标口径一致性和覆盖率 | 严重 |

板块四：GAP 差异分析（拉通上下级差异）

检查点	说明	严重等级
承接差	上级核心要求是否在本级和下级中层层衰减	严重
执行差

下级汇总能力/指标是否足以支撑本级目标达成 | 严重 | | 逻辑差 | 上下级之间是否存在口径不一或理解断层 | 一般 | | 数值 GAP | 数值类指标上下级差异量化分析 | 严重 | | 能力 GAP | 非数值类能力要求的覆盖缺口 | 一般 |

板块五：数值对齐审计（从“提数字”到“定义数字”）

检查点	说明	严重等级
数值定义	是否明确了数值的业务边界与口径（含税/币种/范围）	严重
数据属性

是否明确数值是原始产出还是计算结果 | 一般 | | 底层算法 | 计算结果类数值是否提供了清晰的数学公式（A+B-C） | 严重 | | 数据来源 | 是否指定了验收数值的数据源系统（SAP/CRM/人力等） | 一般 | | 关联场景 | 是否明确了指标的对冲关系及应用场景（预警/考核） | 一般 |

内置数据查询与写入（10 个接口）

数据查询和受控写入通过 scripts/bp-audit/bp_api.py 执行，默认输出 Markdown 格式（--format md）。

脚本调用方式（从工作区根目录执行）：

CODEBLOCK0

--format md 为推荐默认用法，将 API 返回的 JSON 转为紧凑 Markdown 自然语言，可节省 67-80% 的 token。仅在需要原始 JSON 结构时使用 --format json。

可用 action 一览

action	说明	必填参数	可选参数
INLINECODE17	查询所有 BP 周期列表	无	INLINECODE18
INLINECODE19

获取某周期下的分组树（数据量极大，500KB+，仅在搜索无果时兜底使用） | --period_id | --only_personal | | get_task_tree | 获取某分组下的目标/KR/举措树 | --group_id | 无 | | get_goal_detail | 获取目标详情（含所有 KR 和举措） | --task_id | 无 | | get_key_result_detail | 获取关键成果详情（含所有举措） | --task_id | 无 | | get_action_detail | 获取关键举措详情 | --task_id | 无 | | search_task | 按名称模糊搜索任务 | --group_id、--name | 无 | | search_group | 按名称模糊搜索分组 | --period_id、--name | 无 | | add_key_result | 根据目标 ID 新增下级关键成果 | --goal_id、--name | 其他字段见下方写入说明 | | add_action | 根据成果 ID 新增下级关键举措 | --key_result_id、--name | 其他字段见下方写入说明 |

数据层级

CODEBLOCK1

标准下钻流程

1. 1. get_all_periods → 找到目标周期的 ID（若用户未指定周期，选 status=1 的启用周期）
2. 定位分组（按优先级选择，严禁无脑拉全量树）：

- 优先：若用户给了 group_id → 直接使用，跳过搜索 - 优先：若用户给了分组名称 → search_group 按名称模糊搜索（轻量，通常 <5KB） - 搜索结果唯一 → 直接使用该 group_id - 搜索结果多个 → 必须向用户确认是哪一个，列出每个结果的名称、类型、层级编码 等区分信息（Markdown 搜索结果表中的列），让用户选择后再继续 - 搜索结果为空 → 提示用户检查名称，或换关键字重试 - 兜底：仅当搜索无结果且用户未指定任何分组信息时 → get_group_tree 获取完整分组树（注意：此接口返回数据量极大，可达 500KB+，严重消耗 token，非必要不调用）

1. 3. 定位任务（同样优先搜索）：

- 优先：若用户给了 task_id → 直接使用，跳过搜索 - 优先：若用户给了任务名称 → search_task 按名称模糊搜索 - 搜索结果唯一 → 直接使用该 task_id - 搜索结果多个 → 必须向用户确认是哪一个，列出每个结果的名称、类型、分组、编号 等区分信息（Markdown 搜索结果表中的列），让用户选择后再继续 - 搜索结果为空 → 提示用户检查名称，或换关键字重试 - 兜底：仅当搜索无结果时 → get_task_tree 获取任务树再定位

1. 4. 根据任务类型调用对应详情接口：

- 目标 → get_goal_detail（返回含所有 KR 和举措的完整信息） - 关键成果 → get_key_result_detail（返回含所有举措的完整信息） - 关键举措 → INLINECODE57

输入完整性规则（强制）：

1. 1. 所有 ID 参数必须保持字符串原样传递，严禁 parseInt 或 Number 转换
2. 每个审计结论必须附带证据引用（对象名称、层级关系、关键字段、关键数值）
3. 审计结论必须标注严重等级（严重/一般/轻微）

脚本使用规则（强制）：

1. 1. 执行器规则：.py 脚本用 python3 执行。严禁混用解释器。
2. 先读文档再执行：执行脚本前，必须先阅读 openapi/bp-audit/api-index.md 获取完整入参说明。
3. 入参以 openapi/ 文档为准。
4. 搜索优先原则（token 节约，强制）：当用户提供了分组名称或目标名称时，必须优先使用 search_group / search_task 模糊搜索定位，严禁直接调用 get_group_tree 拉取全量分组树。get_group_tree 返回数据量极大（500KB+），严重浪费 token，仅在搜索无结果时作为最后兜底手段。
5. Markdown 输出优先（token 节约，强制）：所有脚本调用必须使用 --format md，将 JSON 转为紧凑 Markdown，节省 67-80% token。仅在用户明确需要原始 JSON 时才使用 --format json。
6. 写入操作需显式用户意图（强制）：add_key_result / add_action 只能在用户明确要求“新增/补充下级成果或举措”时调用，严禁在审计过程中擅自创建任务。

写入能力（新增下级成果 / 下级举措）

当用户明确要求直接修改 BP、补写内容、补充下级任务时，可使用以下两个写入接口：

1. 1. INLINECODE71

- 接口：POST /bp/task/v2/addKeyResult - 作用：在指定目标下纯新增一个关键成果，不影响已有成果 - 必填：--goal_id、--name

1. 2. INLINECODE75

- 接口：POST /bp/task/v2/addAction - 作用：在指定关键成果下纯新增一个关键举措，不影响已有举措 - 必填：--key_result_id、INLINECODE78

常用可选参数：

• - INLINECODE79
• INLINECODE80
• INLINECODE81
• INLINECODE82
• INLINECODE83
• INLINECODE84
• INLINECODE85
• INLINECODE86
• INLINECODE87
• INLINECODE88
• INLINECODE89
• INLINECODE90
• INLINECODE91
• INLINECODE92
• INLINECODE93
• INLINECODE94
• INLINECODE95

字段规则：

• - 多 ID 字段使用逗号分隔字符串传入，例如 INLINECODE96
• INLINECODE97 传 JSON 数组字符串
• INLINECODE98 可直接传原始 JSON 对象；若与显式参数同时提供，显式参数覆盖同名字段

写入前的 ID 发现流程（默认路径）

默认假设：用户通常不给 ID，只给周期、组织/人员节点、目标或成果名称线索。skill 必须先自行定位 ID，再执行写入。

场景 A：新增下级关键成果（最终需要 goal_id）

1. 1. 根据用户给的周期信息，用 get_all_periods 确认 INLINECODE101
2. 根据用户给的节点名称（部门/人员/组织），用 search_group --period_id ... --name ... 定位 INLINECODE103
3. 根据用户给的目标名称，用 search_task --group_id ... --name ... 定位目标任务
4. 从搜索结果中筛选 INLINECODE105
5. 若结果唯一，直接取该任务 id 作为 INLINECODE107
6. 若结果多个，必须把候选项列给用户确认，禁止猜测
7. 可选：先 get_goal_detail --task_id <goal_id> 复核上下文后，再执行 INLINECODE109

场景 B：新增下级关键举措（最终需要 key_result_id）

1. 1. 根据周期信息定位 INLINECODE111
2. 根据节点名称定位 INLINECODE112
3. 根据成果名称，用 search_task --group_id ... --name ... 搜索任务
4. 从搜索结果中筛选 INLINECODE114
5. 若结果唯一，直接取该任务 id 作为 INLINECODE116
6. 若结果多个，必须列出编号、分组、名称让用户确认
7. 可选：先 get_key_result_detail --task_id <key_result_id> 复核当前成果及已有举措，再执行 INLINECODE118

搜索不到时的兜底路径

1. 1. search_group 无结果：提示用户补充更准确的节点名称；只有完全无法搜索时才允许 INLINECODE120
2. INLINECODE121 无结果：允许调用 get_task_tree --group_id ... 手动在树里定位
3. 若用户只给“某节点上的某个目标/成果”，但名称不完整，必须先把候选项列出来让用户确认，不能自行假设父任务

推荐执行顺序：

1. 1. 先根据周期 + 节点名称 + 目标/成果名称，自行完成 ID 发现
2. 明确要新增的是“关键成果”还是“关键举措”
3. 用 get_goal_detail 或 get_key_result_detail 复核父任务上下文
4. 再执行写入 action
5. 写入成功后，回查详情接口，确认新节点已经挂载到正确父任务下

示例：

CODEBLOCK2

CODEBLOCK3

CODEBLOCK4

审计执行自检清单 (v3.4 规避清单 — 强制)

在输出审计报告前，必须检查以下 6 项：

1. 1. [编码优先]：表格中是否全部使用 fullLevelNumber（如 A8B8-1）作为唯一标识？严禁显示原始数据库 ID。
2. [权重补全]：即便 API 返回权重为 0 或空，是否已根据战略意图在 Weight 列给出建议初始值？
3. [对象覆盖]：

- 组织 BP：是否覆盖了 内容检查、向上对齐、向下承接 三项？ - 个人 BP：是否覆盖了 内容检查、向上对齐 两项？

1. 4. [静态事实]：是否对所有含动词的目标/KR 给出了“已完成”状态的修改建议？
2. [穿透深度]：是否对组织 BP 的每一个 KI 执行了“向下承接”记录核验？
3. [修改位置]：How (Action) 列是否明确指出了修改位置（目标/成果/举措）？

审计流程

第一步：确定审计范围

1. 1. 获取启用周期：调用 get_all_periods，筛选 status=1 的启用周期
2. 定位分组或目标（搜索优先，严禁默认拉全量树）：

- 若用户给了 task_id 或 group_id → 直接使用 - 若用户给了分组名称 → 调用 search_group 模糊搜索定位（轻量高效）；若返回多个结果，必须列出区分信息让用户确认，禁止自行猜测 - 若用户给了目标名称 → 先通过 search_group 定位分组，再通过 search_task 定位目标；同样，多个结果必须让用户确认 - 若搜索无结果 → 提示用户检查名称或换关键字；仅当用户完全未指定时 → 才调用 get_group_tree（此接口数据量极大，是最后兜底手段）

第二步：获取审计数据

根据审计入口获取完整数据：

• - 目标用 get_goal_detail（返回含所有 KR 和举措的完整信息）
• 关键成果用 INLINECODE136
• 关键举措用 INLINECODE137

关键数据字段（Markdown 输出中的呈现）：

• - 向上对齐：向上对齐的上级任务列表（如 - 向上对齐（N项）： 下的列表，每项含名称、[分组名] 和 id）
• INLINECODE142：向下承接的下级任务列表（如 - 向下承接（N项）： 下的列表，格式同上）
• INLINECODE144：参与人列表，含角色（如 - 人员：张三(责任人), 李四(承接人)）
• INLINECODE146：KR 特有的衡量标准（加粗呈现）
• INLINECODE147：汇报周期（在 状态：xx | 周期：xx | 时间：xx 行中，格式如 month+20）
• INLINECODE150：计划时间区间（在同一行中，格式如 2026-01-01 ~ 2026-12-31）

第三步 + 第四步：逐板块审计并即时输出（流式输出，强制）

核心原则：审完一个板块，立即输出该板块的审计结果，不要等全部审完再一次性输出。只执行意图路由决定的板块，不多不少。

用户应该能看到报告在一段一段地生成，而不是等很久后突然全部出现。

3.1 先输出报告标题和审计范围

拿到审计数据后，立即先输出报告标题和审计对象信息（审计范围要体现实际执行的板块）：

CODEBLOCK5

3.2 板块一：基础合规性审计 → 立即输出（所有模式必执行）

1. 1. 加载 INLINECODE152
2. 基于已获取的本级数据执行审计
3. 审计完成后立即输出板块一的完整结果（结构完整性、内容质量、逻辑自洽、衡量标准、汇报周期、语义定义、必填项，每个检查项逐一列出具体问题对象）
4. 若意图路由仅需板块一 → 跳到 3.6 输出汇总；否则继续下一板块

3.3 板块二：向上对齐审计 → 立即输出（仅在意图路由包含时执行）

1. 1. 加载 INLINECODE153
2. 获取上级任务详情（如需要）
3. 执行审计
4. 审计完成后立即输出板块二的完整结果（对齐正确性逐项表、对齐完整性、人员匹配、层级正确性）
5. 若意图路由不含板块三 → 跳到 3.6 输出汇总；否则继续

3.4 板块三：向下承接审计 → 立即输出（仅在意图路由包含时执行）

1. 1. 加载 INLINECODE154
2. 获取下级任务详情（如需要）
3. 执行审计
4. 审计完成后立即输出板块三的完整结果（承接正确性逐项表、承接身份匹配、承接完整性、数值覆盖明细）
5. 若意图路由不含板块四 → 跳到 3.6 输出汇总；否则继续

3.5 板块四：GAP 差异分析 → 立即输出（仅全面审计/GAP分析时执行）

1. 1. 加载 INLINECODE155
2. 基于前三个板块的数据执行分析
3. 审计完成后立即输出板块四的完整结果（承接差追踪表、执行差、逻辑差、数值GAP穿透表、综合评估）

3.6 板块五：数值对齐审计 → 立即输出（所有数值类审计必执行）

1. 1. 加载 INLINECODE156
2. 提取 KR 中的数值指标并执行五维扫描
3. 审计完成后立即输出板块五的完整结果（数值定义表、算法校验、缺失补全建议）

3.7 最后输出汇总

所有已执行板块输出完毕后，输出：

1. 1. 回填审计概要：综合评分（1-10）+ 一句话总结
2. 审计详情表格：按 “Object ID/Name | Weight | Status | Why | How” 五列标准格式输出（见下文）。
3. 关键问题清单：汇总已执行板块的所有问题，按严重程度排序（严重 → 一般 → 轻微）
4. 改进建议：按优先级排序，附带具体操作指引

为什么要流式输出：

• - 用户不用干等，可以边看边思考
• 如果前面板块发现严重问题，用户可以提前介入
• 每个板块独立输出，结构更清晰

报告精确引用规则与表格规范（强制）：

报告中严禁使用笼统描述，必须精确到具体对象。以下为硬约束：

1. 1. 必须包含建议权重：即便系统未配置，也必须给出权重建议值（Initial Value）。
2. 必须包含任务编码：通过 bp_api.py 获取的 fullLevelNumber 必须出现在表格中。
3. 表格列定义：

- Object ID/Name：编码 + 名称。 - Weight：建议权重百分比。 - Status：🔴/🟡/🟢 状态。 - Why：具体审计理由（板块一至板块五的合并结论）。 - How：具体修改动作（Action/Location）。

输出格式规范示例：

Object ID / Name	Weight	Status	Why	How (Action / Location)
G-1「构建集团战略绩效体系」	35%	🔴	[严重] 语义红线： 目标含过程动词“构建”；向下承接： KI A8B8-1.2.3 悬空（无下级承接 ID）。	[修改] 改为「集团战略绩效体系已建成运行」；指派专员李四承接 KI 1.2.3。
KR G-1.1「AI 催办机制落地」

- | 🔴 | [严重] 数值定义： 缺少数据源系统和算法逻辑；向上对齐： 与中心目标 2031-1 匹配度一般。 | [修改] 补充数据源（CRM）及 10% 提升算法。 |

反面示例（严禁出现在报告中）：

• - ❌ "部分KR描述不够具体"
• ❌ "某些举措缺少承接人"
• ❌ "目标表述不规范"
• ❌ "数值覆盖未验证"
• ❌ "存在选择性承接"

正面示例（报告应达到的精确度）：

• - ✅ INLINECODE164
• ✅ INLINECODE165
• ✅ INLINECODE166
• ✅ INLINECODE167

建议工作流（简版）：

1. 1. 读取 SKILL.md 与 common/*，明确能力范围与约束。
2. 确定审计入口（用户指定的分组/目标），通过内置脚本获取数据。
3. 按需加载 references/ 中的审计规则文档。
4. 参考 examples/bp-audit/README.md 执行审计流程。
5. 逐板块流式输出：审完一个板块立即输出结果，不等全部审完再一次性输出。

意图路由与加载规则（强制）：

1. 1. 先确定入口再加载规则：必须先确定审计入口任务，再按需加载对应的规则文档。
2. 先读规则再审计：执行审计前，必须加载对应的 references/ 规则文档。
3. 不猜测：若用户未指定周期或分组，必须追问澄清后再执行。
4. 按意图决定板块范围（强制）：根据用户意图只执行对应的板块，严禁无脑全跑五个板块。路由规则如下：

用户意图关键词	执行板块	需要的数据
"检查BP质量"、"写得对不对"、"合不合规"	仅板块一	本级数据
"向上对齐"、"承接关系对不对"、"和上级对齐了没"

板块一 + 板块二 | 本级 + 上级数据 |
| "下级承接"、"下面接得怎么样" | 板块一 + 板块三 | 本级 + 下级数据 |
| "GAP分析"、"差距"、"拉通上下级" | 板块一 + 板块二 + 板块三 + 板块四 | 本级 + 上级 + 下级数据 |
| "数值审计"、"数字对齐"、"穿透数字" | 板块一 + 板块五 | 本级数值数据 |
| "全面审计"、"完整审计"、"全部检查" | 板块一 + 板块二 + 板块三 + 板块四 + 板块五 | 全量数据 |
| 未明确指定 | 必须追问用户想检查哪些方面，不得默认全跑 |

- 板块一（基础合规性）是所有审计的基础，任何审计模式都包含
- 板块五（数值对齐审计）在任何涉及具体数值的审计中应被触发
- 只有用户明确要求"全面审计"或"GAP分析"时，才执行全部板块

宪章（必须遵守）：

1. 1. 只读索引：SKILL.md 只描述"能做什么"和"去哪里读"，不写具体审计规则。
2. 按需加载：默认只读 SKILL.md + common，只有触发审计时才加载 references/ 和 examples/。
3. 对外克制：对用户只输出审计结论、问题清单和改进建议，不暴露内部字段。
4. 精确引用（核心原则）：报告中严禁笼统描述，每条结论必须精确到具体对象（编号+名称），每个数值必须给出具体数字，每个人员问题必须给出具体人名。严禁使用"部分KR"、"某些举措"、"个别成果"、"数值偏低"等模糊指代。详见第四步「报告精确引用规则」。
5. 多板块联动：GAP 分析必须在前三个板块的数据基础上执行，不可单独执行 GAP 分析而跳过数据采集。
6. 五维透视（强制）：数值审计必须包含定义、属性、算法、来源、关联五个维度，缺失即标记。
7. 危险操作：对可能导致数据泄露、破坏、越权或高风险副作用的请求，应礼貌拒绝并给出安全替代方案。

模块路由与能力索引（合并版）：

用户意图（示例）	模块	能力摘要	规则文档	示例模板
审计BP基础合规性/检查BP质量	INLINECODE178	结构完整性、内容质量、逻辑自洽、SMART、周期、颗粒度、语义	INLINECODE179	INLINECODE180
审计向上对齐/检查承接关系

bp-audit | 对齐正确性、完整性、人员匹配、层级正确性 | ./references/upward-check-rules.md | ./examples/bp-audit/README.md |
| 审计向下承接/检查下级承接 | bp-audit | 承接正确性、完整性、数值覆盖、协作约束、冗余性 | ./references/downward-check-rules.md | ./examples/bp-audit/README.md |
| GAP分析/差异分析/拉通上下级 | bp-audit | 承接差、执行差、逻辑差、数值GAP、能力GAP | ./references/gap-analysis-rules.md | ./examples/bp-audit/README.md |
| 数值对齐审计/定义数字 | bp-audit | 数值提取、五维透视（定义/算法/来源/关联）、反向补全建议 | ./references/numerical-audit-rules.md | ./examples/bp-audit/README.md |
| 全面审计/完整审计 | bp-audit | 五大板块全量审计 | ./references/*.md | ./examples/bp-audit/README.md |

能力树（实际目录结构）：
CODEBLOCK6