dennydkt xb-plan：可执行计划
调用前先读 ../xbskill/references/interaction-settings.md，按用户已选调用强度和保存提示执行；明确指定其他技能或拒绝 XB 时退出。未初始化时只允许配置与说明，禁止代选或先执行后确认。
直调契约：还必须读取 ../xbskill/references/contracts.md 与 ../xbskill/references/resolution-standard.md；缺失时停止，不得把排期完成写成现实交付已经发生。
前置：读取 ../xbskill/references/goal-help-model.md、../xbskill/references/agency-model.md、../xbskill/references/context-protocol.md 与 ../xbskill/references/intellectual-capabilities.md。任一文件缺失时报告精确路径并停止本专科，不得凭记忆补造理论镜头。目标若不可验收或选择门尚未通过，不要用假目标或坏目标硬排期。G2/G5 计划必须加载相关公司权责与人物约束。岗位生命周期会改变工作包、接口或决定门时，再读取 ../xbskill/references/role-context-model.md 和 ../xbskill/references/data-work-specialties.md、../xbskill/references/product-rd-specialties.md、../xbskill/references/function-work-specialties.md 中的一套；不因职业名同时加载全部。
计划对象与成功定义
计划是一个在真实容量、依赖和决定权下仍能产生可验收中间结果的承诺系统，完整动作清单本身不足以构成计划。每个工作包必须回答：产生什么、谁唯一负责、依赖谁、最晚何时开始、谁验收、失败如何被看见、谁有权改范围。
至少区分五类时间：净工作时间、等待时间、返工缓冲、决策时间、风险储备。把等待和审批藏进“执行工期”，会得到表面精确、现实必延误的计划。
计划失效信号
| 信号 | 竞争解释 | 需要取得的证据 | 分支 |
|---|---|---|---|
| 所有任务都最优先 | 未做取舍、真实后果均高、决定权空缺 | 截止/后果/占用/卡人四列、可用容量、决定人 | 取舍确认，不继续塞排期 |
| 计划总延期 | 容量稳定不足、外部等待、估时偏差、目标漂移、一次异常 | 多周期计划/实际、等待、返工、变更记录 | 系统改动或局部兜底 |
| 做到一半才发现缺材料 | 依赖未显形、输入标准不清、责任接口断裂 | 前置输入、提供者、承诺日期、接受标准 | 建依赖门和未就绪停止条件 |
| 任务写得很细仍不动 | 没有可验收产物、动作不具备权限、容量/风险保护 | 第一处具体断点、执行权限、当前容量 | 改工作包或转 xb-action/边界 |
| 频繁救火 | 风险无预警、范围被静默追加、流程共同原因 | 事件序列、提前可见信号、变更来源 | 设触发阈值与变更门 |
流程
- 锁定最终交付、截止时间、资源、责任边界和已知约束；岗位任务命中纵深图谱时，同时锁定当前生命周期、上游/下游、决定 owner 与验收 owner。
- 以“可验收中间产物”拆工作包，不以空泛动词拆。
- 标出依赖、关键路径、外部等待、决策门和不可并行项。
- 每项写唯一负责人、协作者、完成标准和最晚开始时间。
- 加风险登记：概率、影响、预警信号、预防、兜底、升级人。
- 设置节奏：下一个 15 分钟动作、今日动作、里程碑检查、复盘点。
- 做容量和代价校验，明确删减、延期、求助或退出项；不把全部任务都标最高优先级，不用计划掩盖长期超载。
工作包与依赖规则
- 工作包以“可检查名词 + 状态”命名，如“口径表获业务确认”，不用“推进数据工作”。
- 依赖至少标明：输入依赖、决定依赖、资源依赖、权限依赖和前序产物；写
负责人 + 承诺日期 + 未到位动作。 - 只有同一资源不冲突、输入独立且输出可分别验收的工作才能并行。
- 最晚开始时间从截止反推：净工作 + 等待 + 必要复核 + 缓冲；无法估计时给区间和决定性未知，不伪造单点精度。
- 风险预案必须由可观察信号触发；“加强沟通、密切关注”不是预案。
- 变更必须写新版本、来源、影响和被挤出项；不允许在旧计划里静默堆叠。
行动表最小字段
工作包 / 可见产物：
唯一负责人 / 协作者：
验收者 / 完成标准：
输入、决定、资源与权限依赖：
净工作 / 等待 / 返工缓冲：
最晚开始 / 截止：
当前状态与证据：
预警信号 / 触发动作 / 升级人：
版本变化与被挤出项：
现实结果 / 回流日期：
决策分支
- 需求与验收仍不清：返回
xb-goal，只规划取得确认的动作，不规划假交付。 - 容量小于硬需求：明确保留、降级、延后、求助和退出，不生成“加速完成全部”的虚假方案。
- 新旧两个版本同时压进同一截止且容量不足：必须先交付一张
任务/版本、具体内容、估时、保留、降级、延后、被挤出页/深度/核验、取舍决定人表；示例容量必须标为假设，不能用“可审阅初稿”掩盖被挤出的具体内容。 - 用户无权承诺他人：把对方写为待确认依赖，不替其分配负责人或截止。
- 不可逆或高风险变更：先沙盒、演练或审批门；未授权不得进入生产动作。
- 关键等待超过阈值：按预先写好的替代、降级或升级动作走，不到截止日才暴露。
理论镜头落地
每题最多选择 1–2 个镜头。理论名必须落实为计划动作、字段和可观察失败信号。
| 理论镜头 | 具体动作 | 写入产物字段 | 失败信号 |
|---|---|---|---|
| 赫伯特·西蒙：有限理性/满意化 | 先写计划必须满足的硬门槛，再设方案搜索预算和停止规则；按关键路径优先找到第一个可交付方案，不为追求理论最优无限补任务。 | 硬约束、满意阈值、搜索范围、计划截止、停止规则、首个合格方案、未覆盖风险 | 计划未过硬门槛；持续加方案却不决定；新增信息价值低于延期成本仍继续搜索 |
| 戴明：共同原因/特殊原因 | 超载或延期时，比较多周期、多人和过程变更，先判断负荷是稳定超过容量、流程普遍制造等待，还是一次异常事件；分别安排系统改动或局部兜底。 | 容量基线、工作量分布、共同原因候选、特殊事件、过程改动、局部处置、验证窗口 | 只凭一次延期归因个人；多人多期都超载却只加个人效率动作；过程调整后分布不变仍坚持原归因 |
微型正例：团队每周稳定收到约 60 小时需求，但可用容量只有 40 小时。计划把 40 小时设为硬约束，保留关键交付，明确降级 12 小时、延后 8 小时，并把持续超载登记为共同原因待调整；不再给每个人追加“提高效率”任务。
微型反例：把 12 小时工作塞进 8 小时排期，所有事项都标为最高优先级，再把逾期写成负责人执行力不足。甘特图存在不等于计划可执行。
微型边界例：普通参会者可以为自己的交付承诺时间、提议纪要和标记待确认依赖，但不能在计划里替跨部门负责人接受截止；对方沉默仍是“未确认”，不是默认同意。
输出
交付树、行动表、依赖与关键路径、容量基线、保留/降级/延期及具体被挤出内容、取舍决定人、风险表、沟通节奏、变更规则、所选镜头及失败/推翻条件。
计划表、风险表和待确认项只是行动脚手架；只有负责人确认、资源进入、首个动作发生或里程碑产物出现后，才能报告对应现实进展。
现实回流比较计划与实际的净工作、等待、返工、变更和中断。若连续两个周期同一偏差超过预设容差，不继续要求“估准一点”，而是重开容量、流程共同原因或授权假设。
自检
每项是否有可见产物与唯一负责人？计划是否容纳等待和返工？是否超过真实容量？