组织 BP 月报修订器

本 skill 的主流程与个人月报修订一致：在 bp/report-reviser/{reportMonth}-月报-{reportRecordId}/ 生成干净 Markdown；AI 只按章节规则提出修改方案；用户确认后由脚本精确写入。不要把临时过程文件作为最终正文来源。

核心边界

月份目录是唯一正文来源：最终可见 Markdown 只能放在 bp/report-reviser/{reportMonth}-月报-{reportRecordId}/ 下。
目录月份必须标准化：reportMonth 必须使用 YYYY-MM，例如 2026-05-月报-2058815281387614209；不要使用 2026年5月-月报-... 或 2026-05-组织月报-... 作为正式工作目录。
默认不写文件：用户只提出修改意图时，只输出修改方案；只有明确确认后才调用脚本写入。
普通正文修订只用精确替换：使用 apply_chapter_patch，必须提供 targetFile + locator.originalText，禁止整章重写或模糊替换。
专门动作不能混进正文 patch：灯色走 update_lamp_color；证据追加走 add_evidence_ref；普通正文替换不得直接改灯色、证据编号、汇报链接或系统事实。
灯色原因必须可展示：允许用户只用明确业务原因修改灯色；如用户提供真实汇报，先用 add_evidence_ref 登记，再在原因中引用 R/RP 编号或该证据汇报 ID。用户可见原因必须显示为 [R1001](huibao://view?id=...) 这类 Markdown 证据链接，禁止裸写 huibao://...，也禁止把当前月报自身 reportId 当证据。
组织目标灯色按 KR 聚合并联动：目标灯色不能直接自由修改，必须等于当前 KR 灯色聚合结果；修改 KR 灯色后脚本必须自动聚合并同步目标明细、2.1 目标清单总览和管理摘要目标灯色。
下级承接 BP 内容锁定：第 2.2 章中的“下级承接BP内容”、下级进展摘要、下级目标灯、下级判断理由，以及举措下的下级证据摘要，不能通过普通正文修订修改。
第 7/8 章完全不可改；附录证据索引只允许脚本追加组织自身证据。
第 3/4/5/6 章可普通修订；允许写入用户明确提供的新事实数字，但不能新增无来源目标、证据、组织承诺或汇报链接。
ID 全程字符串：禁止对 reportId、groupId、periodId、taskId、huibao id 等做数值转换。

按需读取

场景	必读文件
初始化、灯色、证据、交付命令	`references/workflows.md`
判断章节能否修改	`references/rules/editable-boundary-rules.md`
普通正文 patch	`references/rules/patch-rules.md` 和 `references/templates/chapter_patch_schema.json`
写入失败或校验争议	`references/rules/validation-rules.md`

主流程

1. 初始化

远端 reportId：

执行以下脚本。若未安装 requests，必须先安装，再运行脚本。
禁止在未实际运行脚本的情况下，根据代码、经验或历史输出模拟/推断/口述脚本结果。

python3 scripts/org_monthly_report_reviser.py prepare_revision_workspace --report_id {reportId}

在 sandbox exec / tool runner 中执行远端初始化时，BP_OPEN_API_APP_KEY 必须通过执行工具的 env 参数传入，禁止写成 export ... && python3 ... 或 BP_OPEN_API_APP_KEY=... python3 ... 这类 shell 前缀。

{
  "command": "python3 scripts/org_monthly_report_reviser.py prepare_revision_workspace --report_id {reportId}",
  "env": {
    "BP_OPEN_API_APP_KEY": "{个人AppKey（用于访问业务接口）}"
  }
}

初始化完成后，只向用户展示 bp/report-reviser/{reportMonth}-月报-{reportRecordId}/。

2. 定位和判断

根据用户意图定位月份目录下的 Markdown 文件：

章节编号/章节名精确匹配
目标编号/目标名称匹配
全文关键词搜索

定位目标/KR/举措编码时，优先使用脚本解析路径，避免手写含中文、空格、括号或 ｜ 的文件名：

python3 scripts/org_monthly_report_reviser.py resolve_code_file \
  --report_id {reportId} \
  --code A8B8-1.1

然后判断能否改：

可普通修订：提出具体替换方案和目标文件。
需要专门动作：灯色、证据追加走脚本动作。
禁止直接改：说明边界，不生成可执行 patch。

3. 用户确认前只给方案

确认表达包括：确认写入、可以，写进去、就这样改、帮我保存、按这个改。

确认前输出类似：

我会修改：
3_问题_偏差与原因分析.md

修改点：
1. ...
2. ...

请确认是否写入。

如果方案包含灯色修改，必须在确认前明确列出脚本将联动的位置：

修改 KR 灯色：目标明细中的 KR 灯色、目标级综合灯色结论、2.1_目标清单总览.md、1_管理摘要.md。
修改目标灯色：目标明细中的目标级综合灯色结论、2.1_目标清单总览.md、1_管理摘要.md。
修改举措灯色：只修改举措本身；不得把举措灯色直接当作 KR/目标聚合结果。

涉及含中文、空格、括号、｜ 等特殊字符的路径时，不要手敲拼接路径；必须使用 resolve_code_file、chapter_revision_manifest.json 或脚本返回值中的精确路径。

4. 确认后写入

普通正文修订：

python3 scripts/org_monthly_report_reviser.py apply_chapter_patch \
  --report_id {reportId} \
  --patch_file {patch_path}

灯色修改：

python3 scripts/org_monthly_report_reviser.py update_lamp_color \
  --report_id {reportId} \
  --code A8B8-1.1 \
  --new_lamp yellow \
  --reason "用户确认后的灯色判断依据；涉及证据 R1001"

灯色原因规则：

没有外部汇报证据时，--reason 写用户确认的业务解释，脚本允许执行并把解释写入判断理由。
有外部汇报证据时，先执行 add_evidence_ref，再在 --reason 中引用 R/RP 编号或对应汇报 ID；脚本会统一展示为 [R1001](huibao://view?id=...)。
不允许在 --reason 中使用当前月报自身 reportId 的 huibao:// 链接；不允许把未登记的裸汇报链接直接写入判断理由。

追加组织自身证据：

python3 scripts/org_monthly_report_reviser.py add_evidence_ref \
  --report_id {reportId} \
  --evidence_file {evidence_json_path}

脚本成功后会刷新 report_manifest.json、chapter_revision_manifest.json，并追加 revision_history.jsonl。

交付

交付给用户或前端时，只交付 bp/report-reviser/{reportMonth}-月报-{reportRecordId}/：

Markdown 是正文。
JSON 是索引/校验/历史。
不读取、不展示、不依赖临时过程文件。

cms-bp-org-monthly-report-reviser

安装技能