# Genre Contract: Execution Plan / 执行计划 (`workplace.execution_plan`)

## 体裁规则表（硬约束）

| 规则项 | 规则 |
|-|-|
| 写作风格 | 以交付和判断为单位，具体、紧凑、可推进；计划可信度来自依赖、产能和验收闭环，不来自章节数量或精确到没有依据的日期 |
| 内容逻辑 | 从已批准结果、成功标准、范围和约束出发，按“交付物 / 工作流 → 依赖与关键路径 → 带退出条件的里程碑 → owner / 接口 / 资源 → 风险触发与备选 → 治理、变更与验收”推进 |
| 事实 / 边界 | 区分已确认承诺、估算、假设和待定项；时间、owner、预算、产能、权限、依赖与验收方须可追溯且算术相容；未批准方向不得写成承诺，关键资源或安全前提未知时收窄计划或 `blocked` |
| 错误 | 任务清单冒充计划、活动无交付物 / 完成定义、里程碑只是日期、排期不服从依赖与产能、所有事项同优先级、接口或验收方缺失、风险无预警信号 / 动作 / owner、变更后不更新基线，任一出现即失败 |

## 适用与消歧

用于方向和目标已定后，组织一次性项目、迁移、发布、活动战役、专项治理或跨团队变更。主要任务仍是选择方向、申请预算 / 资源或授权时走 `proposal.md`；比较策略选项且不形成批准入口走 `business-analysis.md`；发布已授权规则 / 通知走 `formal-doc.md`；重复确定路径走 `sop-tutorial.md`；报当前状态走 `weekly-report.md`。

“项目计划、执行方案、实施计划、营销策划”只作召回词。营销策划若仍在决定打法或预算，按上述 Proposal / Business Analysis 消歧；只有已定打法的协同落地走本合同。

## 可执行性与证据

- 先写可验收结果、范围 / 非范围、约束和最迟决策点；再按交付物而非部门名称拆工作包。每个关键工作包说明 owner、输入 / 输出、依赖、完成定义和验收方。
- 标出关键路径、可并行项、阶段入口 / 退出条件与资源瓶颈；日期由依赖、产能和必要审批 / 制作 / 校准时间推导。无法推导时用相对时间、区间或具体占位，不补造精确排期。
- 风险写预警信号、影响、预防 / 响应动作、决策 owner 和备选路径；备选必须说明何时切换及切换后的安全或业务终态，不写“加强沟通”。
- 治理只保留会产生判断的节奏：接口、升级条件、决策权、范围 / 基线变更和重新验收。密集对应关系可用一张排期、依赖或责任表，但表格不能替代关键路径和取舍说明。

## 高质量写法

让每个目标能一路回链到交付物、里程碑和工作包，让每个日期能回链依赖与产能，让每个风险能回链触发后的动作。资源不足时缩范围、分阶段或设决策门，不用“全渠道、全覆盖、同步推进”制造伪可行性。