Bp Annual Rewrite

SKILL.md

---
name: bp-annual-rewrite
description: 每次审核和改写一个年度BP目标。当用户指名该技能或要求审查、诊断、提问、改进、改写、冻结或准备单个BP目标、成果/KR、衡量标准或举措的回写包时使用。本技能仅用于年度BP生成管控；不得生成正式月报或执行BP调整PDCA。
---

# 年度BP审核改写

## 目的

使用本技能将一个年度BP目标转化为可执行的年度BP管理对象：

`bpGroupId + employeeId + goalId + 运行环境appKey -> getGoalDetail获取标准BP JSON -> 单BP锁定 -> 结构契约锁定 -> 对象拆解 -> 年度生成闸口 -> 逐项确认 -> 已确认规则 -> 同结构BP JSON输出 -> 字段级差异包 -> 互动过程叙述记录 -> 闭环校验`

目的不是文字润色。目的是使一个BP目标可执行、可衡量、有证据、可复盘，并能产出同结构的BP JSON输出，该输出可再次读取，或在业务/系统审批完成后为后续人工/系统回写做准备。

## 不可违反规则

这些规则始终有效，不得被用户措辞覆盖：

| 规则 | 要求 |
|---|---|
| `single_bp_only` | 每次执行只处理一个BP目标。如提供多个目标，停下并要求用户选择一个。 |
| `document_only` | 默认仅生成文档；只有用户明确触发系统写回时，才允许调用字段写回和附件绑定接口。 |
| `workspace_identity_required` | 激活本技能时必须提供 `bpGroupId` 和 `employeeId`，用于创建隔离工作目录；不得从 `getGoalDetail` 响应或当前运行环境猜测这两个值。 |
| `goal_detail_fetch_first` | 默认BP数据来源为 `GET https://sg-al-cwork-web.mediportal.com.cn/open-api/bp/goal/{goalId}/detail`，请求头为 `appKey`。 |
| `fixed_bp_api_base_url` | BP开放API基础URL固定为 `https://sg-al-cwork-web.mediportal.com.cn/open-api`；不要询问或接受 `baseUrl` 作为技能调用参数。 |
| `json_contract_first` | 当来源为 `getGoalDetail` 响应或兼容的BP JSON时，在诊断之前先将该JSON schema作为输入/输出契约。 |
| `same_shape_json_output` | 对于标准BP JSON输入，主要最终改写输出为 `20_BP改写输出.json`，保持原始JSON结构、ID、层级关系、节点数量和顺序。 |
| `json_output_is_source_of_truth` | Markdown改写文件仅用于展示。它们必须从最终JSON生成，不得成为独立的改写来源。 |
| `preserve_system_identity_fields` | 不要更改 `id`、`fullLevelNumber`、父子关系、数组顺序或只读状态字段，除非用户明确更改契约并记录为已确认规则。 |
| `no_initiative_count_rule` | 本技能不设定举措最多/最少条数。对于标准BP JSON输入，只保持来源中已有举措的数量、顺序、ID和归属关系；不得新增、删除、拆分、合并或重排。 |
| `no_report_period_field` | 当前BP系统不使用“汇报周期”字段。输出和问题中不要体现汇报周期；如需检查时间，只使用来源中存在的计划开始/结束日期、年度内节点或截止日。 |
| `diff_writeback_only` | 当明确要求BP系统回写时，必须通过 `/bp/task/v2/applyGoalContentDiff` 使用字段级差异语义，而非 `updateGoalContent` 全量同步。 |
| `no_zip_attachment_upload` | 中间文件和正式输出文件不得打包为 zip 上传；需要作为 BP 目标关联文件时，必须逐个上传。 |
| `final_writeback_confirmation_required` | 调用系统写回脚本前，必须向用户展示本次将写回的字段级变更摘要，并说明将自动保存到BP目标关联文件的附件只有三份目标理解文件：`待确认问题与已确认规则.md`、`规则卡.md`、`PDCA边界与下级联动检查.md`，要求用户明确回复“确认写回”。未收到“确认写回”前，不得调用字段写回或附件上传脚本。 |
| `upload_files_with_writeback` | 当明确要求写回BP系统时，字段写回和目标理解附件保存属于同一写回时机：先校验输出，再调用 `/cwork-file/uploadWholeFile` 上传本次运行目录中已生成的三份目标理解文件，本地文件名保留 `16_`、`17_`、`18_` 用于包内排序，保存到BP目标附件时展示名去掉序号。除这三份文件外，其他 Markdown 和 JSON 文件仅保存在本地用于审计和校验，不上传到 BP。 |
| `preserve_user_uploaded_files` | 保存AI生成附件时，不得删除用户手动上传的目标附件；如需要替换旧AI附件，只能按本技能生成的中文文件名前缀或后续系统来源标识删除。 |
| `preserve_masking_exactly` | 精确保留来源中的脱敏、占位符和产品/项目混淆处理，除非用户明确要求更改。 |
| `annual_bp_generation_only` | 仅处理年度BP生成管控。 |
| `no_formal_monthly_report` | 不生成正式月报、AI月度目标报告、三版本月报或月度裁决结果。 |
| `no_formal_pdca_execution` | 不批准或执行BP调整PDCA；仅识别是否需要PDCA。 |
| `ai_diagnosis_before_user_direction` | 获取BP详情后，不得先询问用户“想怎么修订、想改哪里、修订方向是什么”。必须先由AI完成对象拆解、闸口诊断、冲突台账和问题队列，再按优先级逐题向用户确认具体业务规则。 |
| `human_confirmation_required` | 对不明确的业务规则逐题提问。不得将未确认的推断转化为已确认规则。 |
| `answer_confirmation_before_persist` | 用户回答后，先整理为“拟确认规则/影响字段/回写或PDCA判断”并请用户确认；用户确认前不得写入 `07_已确认规则.md`，不得进入下一题。 |
| `seed_list_required` | 创建问题队列前必须读取 `references/question_seed_list.md`，逐条遍历种子清单；无问题的种子项也要在诊断摘要中记录为已通过或不适用。 |
| `parallel_measure_standards_required` | KR存在编号型或并列型衡量标准时，每个子项都必须逐项检查并记录结论，不得只问其中一个。 |
| `question_first_default` | 如存在需要确认的业务问题，默认不生成完整正式输出包。先创建或更新过程底稿，再逐题提问。 |
| `workbench_required_before_interaction` | 在开始提问互动前，创建或更新过程底稿文件，包括诊断、冲突、问题队列、回答记录、已确认规则、未决问题、互动日志和生成放行检查。 |
| `update_after_each_answer` | 每次用户回答后，先生成拟确认规则并等待用户确认；只有用户确认后，才在提下一个问题前更新 `01_运行状态.md`、`06_回答记录.md`、`07_已确认规则.md`、`08_未决事项.md` 和 `09_互动过程记录.md`。 |
| `formal_package_generation_gate` | 仅在 `10_正式包生成放行检查.md` 允许正式生成后才生成完整正式输出包，除非用户明确要求诊断中间包。 |
| `conflict_register_required` | 在提问互动前将所有目标-成果-衡量标准冲突记录到 `04_冲突台账.md`。 |
| `source_exhaustion_before_pending` | 在标记引用规则为 `待补` 或 `未读` 之前，先在可访问的BP来源中搜索交叉引用（如 `同KR1.3` 或 `【*】`）；如已定位，标记为 `已定位，待确认引用解释`。 |
| `interaction_process_log_required` | 每个完整输出包必须包含 `25_互动过程叙述记录.md`，记录AI提问、用户回答、已确认规则、补充问题和状态变化的叙述记录，供审计复盘。 |
| `no_ready_before_confirmation` | 在必要的人工确认和闭环审查通过前，不得标记 `ready_for_manual_writeback`。 |
| `validation_not_business_closure` | 模板校验仅证明包结构和边界检查通过；当状态为 `pending_confirmation` 或 `pdca_required` 时，不代表业务已闭环。 |
| `preserve_control_codes` | 保持稳定的字段/状态/闸口编码如 `package_status`、`writeback_status` 和 `BP-G5A`；用中文解释而非随意更名。 |
| `validate_before_final` | 如生成了完整输出包，在最终交付前用 `scripts/validate_output_package.py` 进行校验。 |

G9 仅为未来月度复盘模拟。正式月度复盘属于年度BP改写、回写和冻结之后的独立月度复盘技能。

## 会话响应边界

每次激活本技能、续接本技能、准备向用户回复前，必须先读取并遵守 `references/system.md`。该文件用于限制 AI 只围绕年度 BP 修订结论、待确认问题、产物状态和回写边界回复，禁止闲聊、泛业务建议和无来源发挥。

本技能只支持单个 BP 的既有目标/KR/衡量标准/传播口径/举措内容修改，不支持一次性修改多个 BP，不允许新建、删除、拆分、合并、移动或重排 BP 节点。

## 分阶段执行协议

执行本技能时，以本协议作为主流程。不得把诊断、提问、正式改写、回写准备混成一个一次性任务。每个阶段必须先满足进入条件，完成阶段动作，产出阶段文件或状态，再判断是否进入下一阶段。

阶段内细则仍遵循“不可违反规则”、`references/state_machine.md`、`references/status_and_handoff_rules.md` 和对应参考文档。原始 S0-S9 状态机是本协议的细粒度状态实现；本协议用于稳定执行节奏和交接边界。

| 阶段 | 目标 | 必需输入 | 必需动作 | 必需产物/状态 | 停止或进入下一阶段 |
|---|---|---|---|---|---|
| A. 输入与取数 | 锁定一个权威BP来源 | `bpGroupId`、`employeeId`、`goalId`、运行环境 appKey | 读取 `references/state_machine.md`；先按目录规则创建运行目录；调用固定 `getGoalDetail` API；保存原始响应；确认只处理一个目标 | API获取状态、目标身份、`19_源BP输入.json` 原始快照；运行目录已确定 | 缺少参数、运行环境缺少 appKey、API失败、目标身份不匹配或出现多目标时停止；成功后进入B |
| B. 契约与诊断 | 在不询问修订方向的前提下完成AI自主诊断 | A阶段的源JSON | 读取 `references/bp_io_contract.md` 锁定JSON契约；提取目标/KR/衡量标准/举措；解析交叉引用；读取 `semantic_smart_gate.md`、`annual_bp_gates.md`、`target_light_rule_gate.md` 和 `question_seed_list.md`；运行OKR、SMART、BP-G0到BP-G9和灯色规则检查 | `02_来源与对象拆解.md`、`03_诊断摘要.md`、`04_冲突台账.md`、`05_问题队列.md` 的内容基础 | 未完成对象拆解、闸口诊断或种子清单遍历前，不得向用户询问“想怎么修订”；有问题进入C，无问题进入D的放行判断 |
| C. 互动确认 | 将不明确业务规则逐题确认并沉淀为规则 | B阶段的问题队列和过程底稿 | 读取 `references/workbench_templates.md` 和 `references/interaction_protocol.md`；创建或更新过程底稿；按最高优先级逐题提问；用户回答后先生成“拟确认规则/影响字段/回写或PDCA判断”；用户确认后再写入过程底稿 | `00_过程底稿说明.md` 至 `10_正式包生成放行检查.md`；回答记录、已确认规则、未决事项、互动过程记录保持最新 | 未确认问题仍存在时保持 `pending_confirmation`；回答触发冻结规则/下级承接变更时进入 `pdca_required`；全部确认后进入D |
| D. 放行与正式包生成 | 只在放行通过后生成正式改写包 | C阶段已确认规则，或B阶段无未决问题 | 读取 `references/status_and_handoff_rules.md`；更新 `10_正式包生成放行检查.md`；仅在放行通过或用户明确要求诊断中间包时读取 `references/output_templates.md`；生成同结构BP JSON、差异包、展示稿、规则卡、系统写回字段包和闭环审查 | `11_正式输出包说明.md` 至 `25_互动过程叙述记录.md`；`20_BP改写输出.json` 是主要改写输出；`21_BP改写差异.json` 是字段级写回依据 | 放行未通过则回到C；生成诊断中间包时不得标记 `ready_for_manual_writeback`；正式包生成后进入E |
| E. 校验与交接 | 明确结构校验结果、业务状态和后续边界 | D阶段输出包，或C阶段过程底稿 | 过程底稿运行 `scripts/validate_workbench_package.py`；正式输出包运行 `scripts/validate_output_package.py` 和 `scripts/validate_bp_json_contract.py`；判断 `pending_confirmation`、`ready_for_manual_writeback`、`pdca_required`、`blocked` 或 `validation_failed`；最终响应区分结构校验与业务闭环 | 校验结果、最终包状态、是否可人工回写、是否需要PDCA、互动日志状态 | 校验失败标记 `validation_failed`；业务未闭环不得说完成；用户明确要求写回时才进入附件上传和字段写回动作 |

### 阶段执行要求

1. 每次响应或续接时，先识别当前处于 A-E 哪个阶段，并在 `01_运行状态.md` 或最终响应中保持一致。
2. 阶段 A-B 由AI先完成，不得把“修订方向”交给用户先定义，严禁跳过。
3. 阶段 C 每次只处理一个最高优先级问题；用户回答后必须先让用户确认拟规则，再写入 `07_已确认规则.md`。
4. 阶段 D 不得绕过 `10_正式包生成放行检查.md`；除非用户明确要求诊断中间包，否则未闭环时只输出过程底稿。
5. 阶段 E 的模板校验只证明结构和边界检查通过，不等于业务闭环；最终响应必须分别说明二者。
6. 系统写回不是默认阶段。只有用户明确要求写回BP系统时，才在阶段E之后执行字段级差异写回和附件绑定。

## 渐进加载

仅加载当前阶段所需的参考文档：

| 阶段 | 何时读取 | 参考文档 |
|---|---|---|
| 会话边界 | 激活技能、续接技能、每次回复前 | `references/system.md` |
| 范围与流程 | 启动任何运行、解决多BP目标、判断停止规则时 | `references/state_machine.md` |
| 语义与SMART闸口 | 检查目标-成果-衡量标准分层、OKR映射和SMART完整性（在业务改写前） | `references/semantic_smart_gate.md` |
| 诊断 | 提取对象、运行BP-G0到BP-G9、OKR/SMART/PDCA检查时 | `references/annual_bp_gates.md` |
| BP JSON契约 | 当来源输入为 `getGoalDetail` JSON 或产出同结构JSON输出时 | `references/bp_io_contract.md` |
| 灯色规则设计 | 检查通用灯色底线、目标个性化灯色规则、当前/预测灯色、距绿差距和整改要求时 | `references/target_light_rule_gate.md` |
| 问题生成种子 | 在创建 `05_问题队列.md` 前稳定遍历OKR、SMART、并列衡量标准、灯色、G8、G9、PDCA和回写字段 | `references/question_seed_list.md` |
| 过程底稿 | 创建或更新过程草稿、冲突、问题队列、回答记录、已确认规则、未决问题和放行检查时 | `references/workbench_templates.md` |
| 用户互动 | 生成问题、逐题提问、记录回答时 | `references/interaction_protocol.md` |
| 状态与交接 | 判断待确认/就绪/PDCA/阻塞及第一部分与第二部分边界时 | `references/status_and_handoff_rules.md` |
| 输出包生成 | 仅在放行检查通过或用户明确要求诊断中间包后创建完整标准输出包时 | `references/output_templates.md` |
| 校验 | 在最终响应前检查已生成的包 | 过程底稿用 `scripts/validate_workbench_package.py`；正式输出包用 `scripts/validate_output_package.py` 和 `scripts/validate_bp_json_contract.py` |

不要在创建完整文件包之前加载 `references/output_templates.md`。不要仅因为存在未解决问题就创建完整正式输出包。先使用过程底稿。不要在启动时加载所有参考文档。

## BP数据来源

默认情况下，本技能必须在诊断前从BP开放API获取BP来源：

```text
GET https://sg-al-cwork-web.mediportal.com.cn/open-api/bp/goal/{goalId}/detail
Header: appKey: <appKey>
```

获取的响应为标准 `getGoalDetail` JSON响应，在创建过程底稿或正式输出包时必须原样保存为 `19_源BP输入.json`。不要对该来源进行标准化、排序、改写、删除字段或与手动提供的文本合并。

手动BP JSON、来源文本或文件仅可作为补充上下文。不得替代 `getGoalDetail` API响应作为权威BP来源。

## 最低会话输入与运行环境输入

- `bpGroupId`：BP分组ID，用于创建年度改写工作区；
- `employeeId`：当前登录员工ID，用于创建年度改写工作区；
- `goalId`：BP目标ID，用作 `/bp/goal/{goalId}/detail` 中的 `{goalId}`；

运行环境输入：

- `appKey`：BP开放API请求头值，由运行环境提供，不作为业务会话输入。

可选输入：

- 集团BP蓝图或当前管控报告；
- 已有规则卡；
- 通用和目标个性化灯色状态规则；
- 证据或BP标签规则；
- 指标数据库映射；
- 来自先前会话的已确认业务回答。

不要询问 `baseUrl`。基础URL由本技能固定。不要要求用户在会话中粘贴 `appKey`；运行环境未提供 appKey 时停止并说明“appKey 由运行环境提供，当前运行环境未检测到”。如引用的文件、链接、附件或评论未读取，不要将其作为事实使用。标记为未读。

## 默认工作流

按“分阶段执行协议”顺序运行。以下清单是阶段内的细化动作，用于与 `references/state_machine.md` 的 S0-S9 状态保持一致：

1. 阶段A：读取 `references/state_machine.md`；要求提供 `bpGroupId`、`employeeId` 和 `goalId`；从运行环境读取 appKey；不要询问 `baseUrl`，不要要求用户粘贴 appKey。
2. 阶段A：按目录规则创建本次运行目录，然后通过 `GET https://sg-al-cwork-web.mediportal.com.cn/open-api/bp/goal/{goalId}/detail` 并在请求头中携带 `appKey: <appKey>` 获取BP来源。
3. 阶段A：如获取失败，停止并报告获取失败。不要从猜测的BP内容继续。
4. 阶段A：将获取的响应原样保存为 `19_源BP输入.json`；确认响应在 `data` 中恰好包含一个目标；如不是，停止并要求提供一个有效的 `goalId`。
5. 阶段B：读取 `references/bp_io_contract.md`，在任何改写前锁定输入/输出契约。
6. 阶段B：从JSON契约中提取选定的BP对象映射。
7. 阶段B：在标记引用规则为待补前，先解析来源内的交叉引用。
8. 阶段B：读取 `references/semantic_smart_gate.md`。目标-成果-衡量标准分层和SMART必须通过或产生问题。
9. 阶段B：读取 `references/annual_bp_gates.md` 并运行BP-G0到BP-G9。OKR、SMART、BP-G8、BP-G9即使没有触发问题，也必须记录审查结论。
10. 阶段B：在G9之前读取 `references/target_light_rule_gate.md`。每个目标必须有目标个性化灯色规则卡或灯色规则问题队列。
11. 阶段B：读取 `references/question_seed_list.md`，逐条遍历问题生成种子清单。特别检查综合指标与子项覆盖、并列衡量标准逐项结论、历史灯色规则来源、BP-G8对齐和BP-G9月度模拟。
12. 阶段B：禁止在完成对象提取、闸口诊断和问题种子遍历前询问用户“想怎么修订、想改哪里、要改KR还是举措”。用户只提供业务确认，不负责先定义修订范围。
13. 阶段C：如存在不明确的业务规则，读取 `references/workbench_templates.md`，创建或更新过程底稿文件夹，记录冲突台账、种子清单覆盖情况和问题队列。
14. 阶段C：读取 `references/interaction_protocol.md` 并逐题提问。第一个问题必须来自 `05_问题队列.md` 的最高优先级具体问题。
15. 阶段C：每次回答后，先整理拟确认规则、影响字段、回写/PDCA判断并请求用户确认；用户确认后再更新过程底稿：回答记录、已确认规则、未决问题、放行检查、受影响字段和互动过程叙述日志。
16. 阶段C：在过程底稿中运行漏问、一致性、权限、语义、SMART、灯色规则和月度模拟闭环检查。
17. 阶段D：读取 `references/status_and_handoff_rules.md`，判断目标是否仍为 `pending_confirmation`、需要PDCA还是可以通过正式输出包生成闸口。
18. 阶段E：在将过程底稿作为活动续接状态使用前，用 `scripts/validate_workbench_package.py` 进行校验。
19. 阶段D/E：如 `10_正式包生成放行检查.md` 通过，或用户明确要求诊断中间包，读取 `references/output_templates.md`，生成所需文件，然后用 `scripts/validate_output_package.py` 和 `scripts/validate_bp_json_contract.py` 进行校验。
20. 写回动作：如用户明确要求写回BP系统，先汇总 `21_BP改写差异.json` 中将写回的字段级变更，并说明本次运行目录中将上传并绑定为目标关联文件的附件只有三份目标理解文件：`待确认问题与已确认规则.md`、`规则卡.md`、`PDCA边界与下级联动检查.md`，要求用户明确回复“确认写回”。确认后，先使用 `scripts/apply_goal_content_diff.py` 调用 `/bp/task/v2/applyGoalContentDiff` 执行字段级差异写回；字段写回成功后，再使用 `scripts/upload_bp_rewrite_attachments.py` 上传本地 `16_`、`17_`、`18_` 三份文件并以去序号名称绑定附件。不生成 zip，不上传 JSON，不上传其他 Markdown。

## 过程底稿包

在正式生成之前，当问题、冲突或确认仍在进行中时，创建或更新统一的目标日期目录：

`{bp-annual-rewrite 目录的上上层}/bp/bp-annual-rewrite/<bpGroupId>_<employeeId>/bp_annual_rewrite_<goalId>/<YYYYMMDD_HHMM>/`

其中 `<bpGroupId>` 使用技能入参 `bpGroupId`，`<employeeId>` 使用技能入参 `employeeId`，`<goalId>` 使用技能入参 `goalId`，`<YYYYMMDD_HHMM>` 使用本次运行开始时间。同一目标同一次运行的过程底稿和正式输出包都写入此目录；过程阶段先写过程底稿文件，正式生成放行后在同一目录内追加正式输出包文件。

必需的过程底稿文件：

1. `00_过程底稿说明.md`
2. `01_运行状态.md`
3. `02_来源与对象拆解.md`
4. `03_诊断摘要.md`
5. `04_冲突台账.md`
6. `05_问题队列.md`
7. `06_回答记录.md`
8. `07_已确认规则.md`
9. `08_未决事项.md`
10. `09_互动过程记录.md`
11. `10_正式包生成放行检查.md`

过程底稿是未解决BP目标的默认输出。它不是正式回写包。

## 正式输出包

完整运行时，继续使用同一个目标日期目录：

`{bp-annual-rewrite 目录的上上层}/bp/bp-annual-rewrite/<bpGroupId>_<employeeId>/bp_annual_rewrite_<goalId>/<YYYYMMDD_HHMM>/`

本技能不支持将多个目标放在同一次运行或同一个正式输出包中修订，也不创建多目标外层整理目录。用户如需修订多个目标，必须逐个目标分别启动本技能；每次运行只生成一个目标的独立过程底稿、正式输出包、回写包、闭环审查和校验结果。

必需文件:

1. `11_正式输出包说明.md`
2. `12_执行摘要.md`
3. `13_来源与BP对象拆解.md`
4. `14_语义分层与年度BP闸口诊断.md`
5. `15_衡量标准与指标控制.md`
6. `16_待确认问题与已确认规则.md`
7. `17_规则卡.md`
8. `18_PDCA边界与下级联动检查.md`
9. `19_源BP输入.json`
10. `20_BP改写输出.json`
11. `21_BP改写差异.json`
12. `22_BP修订输出展示稿.md`
13. `23_系统写回字段包.md`
14. `24_闭环审查.md`
15. `25_互动过程叙述记录.md`

严格按照 `references/output_templates.md` 使用模板。对于标准BP JSON输入，`20_BP改写输出.json` 是主要改写输出，必须通过 `references/bp_io_contract.md` 校验。如某章节不适用，写 `不适用` 并说明原因。

## BP系统写回与附件上传

当用户明确触发“写回BP系统”时，字段内容按差异写回；目标关联附件只保存本次运行目录中的三份目标理解文件：

1. 写回前必须展示字段级变更摘要：目标/KR/举措、字段名、旧值、新值、依据规则或确认来源。
2. 写回前必须说明将自动保存到BP目标关联文件的附件只有 `待确认问题与已确认规则.md`、`规则卡.md`、`PDCA边界与下级联动检查.md`。
3. 用户必须明确回复“确认写回”后，才允许调用字段写回和附件上传脚本。
4. 不生成或上传 zip。
5. 自动上传本次运行目录中已经生成且在 `scripts/upload_bp_rewrite_attachments.py` 白名单内的三份目标理解文件；本地文件名保留序号，BP目标附件展示名去掉序号；过程底稿 Markdown 和其他正式输出 Markdown 不上传到 BP。
6. `19_源BP输入.json`、`20_BP改写输出.json`、`21_BP改写差异.json` 只作为本地审计和校验文件，不上传到 BP。
7. 上传接口为 `POST https://sg-al-cwork-web.mediportal.com.cn/open-api/cwork-file/uploadWholeFile`，请求头使用运行环境 appKey，表单字段为 `file=@<local_file>`。
8. 上传返回的 `data` 是需要保存到BP目标关联文件中的文件资源ID。
9. 调用 `POST https://sg-al-cwork-web.mediportal.com.cn/open-api/bp/task/v2/attachGoalRewriteFiles` 将上传结果绑定到目标，`replaceGeneratedFiles` 默认为 `true`。
10. BP关联文件的展示名称必须使用去掉数字序号前缀后的中文文件名。
11. 保存附件时不得删除用户手动上传的文件；如需替换旧AI附件，只能删除同一目标下本技能生成的旧中文命名附件，或删除后续系统来源标识明确为 `bp-annual-rewrite` 的附件。

必须先使用 `scripts/apply_goal_content_diff.py` 执行字段级差异写回，再使用 `scripts/upload_bp_rewrite_attachments.py` 执行附件上传和绑定；不得临时手写 curl 或 Python 复刻写回、上传、绑定逻辑，除非用户明确要求调试接口。

```bash
XG_BIZ_API_KEY=<由运行环境提供> \
python3 scripts/apply_goal_content_diff.py \
  --goal-id <goalId> \
  --work-dir "{bp-annual-rewrite 目录的上上层}/bp/bp-annual-rewrite/<bpGroupId>_<employeeId>/bp_annual_rewrite_<goalId>/<YYYYMMDD_HHMM>"

XG_BIZ_API_KEY=<由运行环境提供> \
python3 scripts/upload_bp_rewrite_attachments.py \
  --goal-id <goalId> \
  --work-dir "{bp-annual-rewrite 目录的上上层}/bp/bp-annual-rewrite/<bpGroupId>_<employeeId>/bp_annual_rewrite_<goalId>/<YYYYMMDD_HHMM>"
```

## 最终响应

说明：

- 处理的目标；
- 当前状态和包状态；
- 创建的文件或待处理的问题；
- 是否可以进入人工回写、需要更多确认或必须进入PDCA；
- 校验结果，与业务闭环状态明确分开说明；
- 使用标准BP JSON时，同结构JSON校验是否通过；
- 互动过程日志是否已生成。

当已创建文件时，最终回答保持简短，以路径优先。