Flowness 工程进展：从需求到交付 · 阅读系列导读 →
设想你要给一个已有服务增加权限检查，同时补齐测试、旧数据迁移方案和运行说明。这项工作可能跨几个工作日，中间会有会话换手，也可能要暂停，把资源让给另一项急事。几天后收到“执行成功”的消息，你仍要判断：哪些成果已保存，哪些进入了主干，哪些真正通过验收？
安排这种工作，先要把任务、执行它的会话、已经交付的成果分开。会话退出后，任务可以接续；代码合入后，任务也可能待复查。Flowness 的操作记录和实现提供了这几种状态的具体处理方式。下面以这项假设的权限改造为例，说明你在交出工作、接班、暂停和收货时，应当留下什么。
交出去之前，把完成条件写到能检查
起始说明要让执行者知道要改变哪个行为、可以动哪些范围，以及遇到什么分叉由谁判断。在这个例子里，可以明确本轮改权限判断与测试，提交迁移方案；是否执行真实迁移、是否上线，则另行约定何时做、由谁确认。这样，执行者遇到旧数据无法直接兼容时，能判断该补方案、提请裁定，还是继续改代码。
随后，把“权限改造完成”拆成可复核的条件：未授权访问在指定用例中被拒绝，旧行为的兼容性有比对，测试请求确实经过新增检查的调用入口，迁移方案写清执行条件与回退方式。如果目标包含上线，启用新路径与真实使用留痕也应单列。条件要针对补丁和预期行为，避免拿当时的机器负载、活跃会话数等外部波动当作完成标准。
这些内容要进入持久任务材料：需求简报、当前任务包、读写范围、前置依赖、完成条件，以及产物的位置和版本。拆分权限逻辑、测试、迁移方案时，依赖应落到具体任务：谁要读谁的成果，哪一步必须等上一项通过。仅写“第一期结束再做第二期”，接班者仍不知道真正挡住下一步的是什么。
代码修改保存在隔离工位里，工位的归属要能对应到任务与执行身份。报告、探针和复核结果也应落在可持续读取的位置。临时目录中的文件，在回收工位后可能消失；交付前要实际核对已转存的文件及其引用，而不能只写一句“已备份”。这些产物使下一位接手者能从已完成的部分开始。
图 1 将三条进度分开：任务在推进，会话可能已经换手，成果则还在审计或验收。
换手时，先核具体任务的承接者
接班先读最新交接单，再读当前状态和有约束力的决定。交接单写清：哪些任务在途，谁在做哪一步，已有哪份产物，卡点是什么，下一步等什么结果。当前状态记录要写明今天谁负责协调、哪些检查仍在运行。旧报告可以解释来历，当前任务包和最新状态决定接下来怎么做。
接班者还要逐项核对引用。任务包是否仍是当前版本，分支是否确实存在，报告能否读到，关键决定是否已被后来的决定替代？引用失效时，先补齐资料或重写交接单，不凭印象硬续。实现中的交棒快照会检查悬空引用；当前形态由人明确触发，自动触发仍受回放实验前置门约束。谁接手、接着做什么，仍应写清。
核归属时，粒度必须到具体任务。知道“权限改造这条线有人值班”，不足以判断某个测试任务能否接手。应对照任务标识、执行会话、工位归属与已有产物，确认原承接者是否仍在动同一份工作。否则，新会话可能在旧会话仍执行时又做一份，形成孪生劳动。
判活同样不能只读面板上的 busy，也不能把一段沉默当作死亡。当前分类器融合完成或半成品记录、近期真实活动、有效锁和进程状态。活动要属于承担这条任务的会话；记录文件存在本身不证明做过工作。若已有半成品且本轮尚未明确终止，应优先接续；信息不足则保留“未知”。有确凿终止证据时，也要查本次运行是否已经交给重规划路径，清理旧席不等于另派一份相同任务。
在权限改造的设想中，假如接班者看到一份已提交补丁、两项未完成测试，应先读取补丁与验证记录，再确定续做范围。这样交出去的是剩下的工作，而不是把整项需求重新从头描述一次。
暂停时，分别处理入口与在途工作
“暂停”需要说明停在哪个层次。协调会话停止巡检，后台执行入口仍可能继续派活；停止新执行派发，复审与修复也可能继续。先把这些选择说清，系统才知道哪些动作仍在授权范围内。
| 暂停维度 | 需要明确的选择 | 必须保留的信息 |
|---|---|---|
| 新执行派发 | 停止哪些任务的新派发 | 停哪些任务、怎样恢复 |
| 在途执行 | 立即停手，或做完当前一节 | 具体归属、已保存成果、停下位置 |
| 复审与修复 | 继续，或另外暂停 | 排队状态、阻塞项与承接者 |
| 协调巡检 | 哪位协调者停，哪些检查保留 | 当前值班状态和到达信号 |
2026 年 9 月 15 日的一次实际暂停，就是分层处理的例子。当时为了腾出资源，选择让两个在途执行席做完当前一节，同时把新执行派发归零。复审、修复等非执行车道仍然开启。次日核对记录时，新增的一次派发是复审席，符合当时设置。若使用者希望这些工作也停，就需要另行明确它们的暂停范围。
这个实例说明，暂停后仍有结果到达可以是预期行为。暂停记录要写下每个在途任务的收尾约定和后续责任。对权限改造，可以允许当前测试批次结束并保存结果，停止新迁移任务启动，保留独立复核；若要全部冻结，也应把这几项一起写明。
恢复前，先收现有结果
恢复先重读交接单与当前状态，再核暂停期间到达的成果。原来的两项测试可能已经跑完，复审可能已提出新问题，某个分支也可能已被合入。把新结果写回对应任务后，再决定哪些派发恢复、哪一步继续、哪个阻塞要先处理。直接恢复所有派发，容易重复启动已经有人承接的工作。
检查仍要落到具体任务：它是否已有完成记录或半成品，当前谁正在做，工位是否有新改动，是否已经进入返修或重规划。原会话可以续做时，接回已有成果；需要换承接者时，交代下一步，并指明要接着修改的版本。旧分支已经合过，并不说明工位里没有后续改动，也不能据此回收它。
失败后的重派预算、旧执行者的写入资格和信号重放，分别见有界重派、世代号写入隔离和游标最后推进。恢复操作要利用这些约束，并把这次接手的范围落实到任务和产物上。
收货之后，还要形成验收证据
9 月 15 日留下的两项在途工作，后来给出了两个不同结果。一项执行者报告完工，代码已由当时的落地通道合入 main，随后却被复查打回；另一项留下执行结果 success，当时分支尚未合入 main，复审正在进行。收货、合入和复查验收在这份记录中是三个不同的事实。
这份 9 月 15 日记录中的旧路径是先合入、再复查。9 月 19 日的手册修订明确规定：先独立审计分支 tip，合格后受控合入，再以合入后的主干版本形成闭合证据。当前操作应采用这个次序。tip 指该分支此次交付的具体提交；审计要看这份版本，而不能只引用一份更早的绿报告。合入后的复查结论和 audit-closure 证据，也要对应到新的主干版本。
收货时，把执行回报与实际改动、点名的验证结果、独立复核结论逐项对上。在上述设想中，权限检查的测试绿了，还要看它是否进入约定的调用路径；若迁移方案或上线仍是另一项任务，就保留对应状态和承接者。复查不合格则转返修，已合入这一事实仍照实记录。需要使用者签收的部分，把成果、未完项和相应证据交给负责签收的人。
每次收货，都在当轮保存该席的产物与证据，完成抽验后关闭已收工的执行会话，后续独立复查可以继续。工位若有未保存的改动或证据，先转存并核实，确认不再需要时再回收。最终验收结论应能回答：接收的是哪一版成果，满足了哪些预定条件，谁进行了独立核验，还剩什么由谁继续。长任务因此可以跨会话接续，也可以按范围暂停；交接保留已有工作，验收确认工作达到了约定的终点。