第 36-39 篇分别补了每日运行请求、运行结果、归档索引和失败动作策略。第 40 篇把这几块组合成一个每日运行计划。到这里系统已经不只是一些独立函数而是有了一个清晰的运行入口形状。运行计划包含什么DailyRunPlan把四类对象放在一起字段来源request第 36 篇的每日运行请求result第 37 篇的运行结果failure_actions第 39 篇的失败处理动作action_summary失败动作汇总这不是最终的交易执行器但已经足够作为 CLI 或定时任务的返回对象。计划对象第 40 章新增app/daily_run_plan.py。dataclass(frozenTrue) class DailyRunPlan: request: DailyRunRequest result: DailyRunResult failure_actions: tuple[FailureAction, ...] action_summary: str计划对象里保留 request是为了排查时能看到当时的输入。不要只保存结果否则很多生产问题会丢上下文。组合计划组合逻辑复用前面两章的函数。def build_daily_run_plan(*, request: DailyRunRequest, checklist: OpsChecklist) - DailyRunPlan: result build_daily_run_result(requestrequest, checklistchecklist) actions build_failure_actions(result) return DailyRunPlan( requestrequest, resultresult, failure_actionsactions, action_summaryfailure_action_summary(actions), )这里没有重新实现任何检查逻辑。运行计划只做编排不把业务规则复制一遍。什么情况下可以执行plan_can_execute()比result_is_actionable()更严格。def plan_can_execute(plan: DailyRunPlan) - bool: return plan.result.status readydry_run_ready可以继续生成报告但不能执行真实动作。因此它是 actionable却不是 executable。当前联动运行结果第 40 篇收口这条命令uv run python -m scripts.chapter_examples paper-run-plan这次运行计划因为data_gaps被阻断输出里的can_executeFalse是最关键的结论。它说明当前计划可以被记录、展示和归档但不能进入真实执行阶段。后续接 CLI 或定时任务时入口层可以直接围绕这个布尔结果决定是否继续。测试三种计划运行本章测试uv run pytest tests/test_daily_run_plan.py tests/test_failure_policy.py tests/test_run_result.py tests/test_ops_checklist.py tests/test_run_request.py测试覆盖ready计划可以执行且不需要失败动作。blocked计划返回wait_next_window和repair_market_data等动作。dry_run_ready可以继续观察但plan_can_execute()返回 false。当前全量测试也通过251 passed, 2 warnings本章更新与代码仓库本章更新内容新增app/daily_run_plan.py。实现DailyRunPlan。组合每日请求、运维检查清单、运行结果和失败动作。实现plan_can_execute()。增加paper-run-plan联动示例展示 blocked 计划如何阻止真实执行。补充 actionable、executable 和can_execute的入口层语义。新增tests/test_daily_run_plan.py覆盖 ready、blocked 和 dry-run-ready。完成第 36-40 篇阶段 review。代码仓库https://github.com/ax2/zi-quant-platform本章代码git clone https://github.com/ax2/zi-quant-platform.git cd zi-quant-platform git checkout chapter-40 uv sync --extra dev uv run pytest tests/test_daily_run_plan.py tests/test_failure_policy.py tests/test_run_result.py tests/test_ops_checklist.py tests/test_run_request.py第 40 章提交为f19a07dtag 为chapter-40。当前全量测试通过251 passed只有既有 FastAPI deprecation warning。第 36-40 篇阶段 review第八组五篇把前面散落的运维能力组合成了每日运行入口。第 36 篇新增每日运行请求把交易日、生成时间、必需股票和 dry-run 收进一个对象。第 37 篇新增运行结果把检查清单转换成ready、dry_run_ready或blocked。第 38 篇给日报归档建立索引让历史报告能被稳定列出和查询。第 39 篇把失败检查项映射成处理动作让 blocked 状态变得可操作。第 40 篇把请求、检查清单、运行结果和失败动作组合成每日运行计划。这一组和前一组是连续的第 31-35 篇先补前置检查第 36-40 篇把检查结果组织成入口层。后面再接 CLI 或定时任务时不需要重新发明运行状态只要围绕DailyRunPlan往外包一层执行即可。当前主线代码也补了一个跨章节命令uv run python -m scripts.chapter_examples paper-run-plan它把第 36-40 篇串成一次可运行演示构造每日请求、读取归档索引、生成 blocked 结果、映射失败动作并组合出最终每日运行计划。这个命令刻意保留一个缺行情场景用来说明计划对象如何把 no-go 原因带到入口层。本篇小结每日运行计划是模拟盘生产化入口的雏形。第 40 篇之后系统已经能把一次运行拆成输入、检查、结果、失败动作和可执行判断。下一步可以把它接到真实命令行入口让每天的模拟盘流程用同一套计划对象驱动。