2 Commits

Author	SHA1	Message	Date
ThearchyHelios	c8363206bd	发起时就定下的事件和运行记录同一个事务写进事件流：受管级别那条日志、目录变化、口径升版处置以前在 run_manager.start 返回之后另外写，这时运行已经建好、执行任务已经起了。其中任何一次写失败（库被锁超过等待时长之类），launch_run 抛出普通异常，运行却在执行；定时任务按「LaunchRefused 以外的异常记未能发起」会把一次正在执行的正式运行记成未能发起，封存范围里也少了受管级别那条日志（governed_formal 找不到它就退回看工作流现在的 status，中途改过画布的会按已发布级别出具）。另外这几条和执行抢先后，运行结束得快时可能落到封存之后。 ... - run_manager.start 加 notes：(类型, node_id, 数据) 的列表，先 flush 拿到运行的 id，和运行记录同一个事务提交，提交之后广播，最后才建执行任务。写不进去就不建运行，launch_run 抛出的任何异常都说明运行没有开始执行 - launch_run 在发起前把这几条事件备好交给 start，不再事后用 run_manager.note 写。顺序和以前实际落库的一样（日志、目录变化、口径升版处置，然后 run.started），现在是确定的 - 没有 notes 的发起（探索运行、问数据）和以前完全相同 没有照复核建议的「写失败就记日志、照常返回运行」：那样正式运行会在缺了受管级别记录的情况下照常出具，可能悄悄降成已发布级别。 测试：用触发器让口径升版处置那条写不进去，launch_run 抛出 IntegrityError、库里没有多出运行（旧代码留下一条正在执行的运行，这条变红）；服务发起的正式运行里，受管级别日志和口径升版处置排在 run.started 前面，都在封存范围里	2026-10-05 01:18:43 +08:00
ThearchyHelios	7820556ab6	发起运行的规则抽成 engine/launch.py 的 launch_run：以前全写在 api/runs.py 的 start_run 里、只认 HTTP 请求，后面的定时任务要用同一套规则发起正式运行，另抄一份迟早走样。正式运行只能从当前发布版本发起、口径升版未声明策略就拦、绑定的工具不存在就拦、发起后记受管级别那条日志和目录变化、口径升版处置，全部搬进服务；拒绝时抛 LaunchRefused(status_code, message, code)，start_run 只剩一层包装，把它换回和以前逐字相同的响应（带机器码的仍回 {detail, code}）。正式运行的快照图不成形，以前由 main.py 的 ValueError 兜底回 400，现在在服务里换成同样的 400 拒绝，调度器也拿得到明确的拒绝。node_setting、tool_bindings、missing_tools 跟着搬过去，runs.py 再导出，旧的导入路径照旧可用；runner 固定数据版本取绑定时改从 engine/launch 导入，不再依赖接口层。新测试先把 HTTP 的 17 种拒绝（含工具缺失的数据、工具、混合、超过 8 处四种说法）按原话写死、在旧代码上通过，再逐条比对直接调 launch_run 的结果；另测服务发起的正式运行照样写治理事件	2026-10-05 00:03:24 +08:00