把上下文接到任务上：一次 Flowness 自开发实录

2026 年 6 月 1 日，Flowness 有一项很具体的自开发任务：把上下文胶囊接进生产会话。这个系统用于支持 Agent 开展工程工作，胶囊负责在一次运行开始时组织任务材料与约束。问题出在两层能力之间：内核已经能够汇编胶囊，提交门也已经能够检查范围和义务，生产入口却没有把它们连起来。

因此，提交顺利通过并不能证明范围检查生效了。检查需要知道这次运行拿到哪份胶囊、允许涉及哪些概念；入口交来的占位引用无法提供这些依据。一次调用经过提交门，和提交门实际执行了相应语义检查，存在一个必须查明的区别。

RUN-048 的任务合同把这一差别作为开发起点。这次工作沿合同核对前提、接入三个主入口、补齐调用参数，并用正反控制验证生产行为。材料组织和写入边界的机制已分别见上下文工作集与类型化事件；这里要追踪的是，一项改造任务怎样把已有能力变成生产路径上的实际约束。

下文运行结果来自2026年6月保存的报告，测试结构按当前源码核对。

合同专门纠正了“胶囊还是占位实现”的旧判断。已有汇编内核会产生真实的 CapsuleCompiled，即胶囊编译记录，包含相关概念邻域和审计指纹；它还会产生与该记录有因果关联的 ObligationActivated，表示本次应当维护的义务。范围漂移与义务覆盖检查也已有精确实现。继续重写这些内核，会花费成本，却未必碰到生产缺口。

核查把问题定位到会话起点：生产命令没有调用汇编，提交信封中硬填了占位胶囊引用。提交门按本轮 fork 标识回查时，找不到该轮真实胶囊，范围检查因缺少基准跳过，其他相关检查也可能降级。这里的标识用于关联一轮执行产生的胶囊与提交。范围控制在测试中成立，并不意味着每个生产入口都已经获得它的保护。

这个诊断改变了验收方式。交付不能只写“已调用汇编函数”，还要证明启动产生了真实胶囊、随后提交引用的是它，并且故意触碰范围外概念时，系统会留下范围漂移记录并拒绝提交。合同把数据、引用和行为分开核对，防止某一层的成功代替整条路径的证据。

合同还划出了工程决策的边界。主入口接线和调用签名补全可以在任务内完成；胶囊正文应该内嵌事件，还是按输入指纹存为独立工件，仍需负责人决定。前两项不依赖这项存储选择，开发便可以先推进。若后续检查确实依赖存储决策，再提交具体冲突，不能借接线任务顺便替负责人改定方案。

图一中的证据链也说明了任务如何收口：合同给出判断条件，实现改变调用关系，测试核对字段与引用，运行记录支持当时的验收结论。每份材料承担一个可指出的责任，不能因为它们都写着“支持”，就合并成一个含义不明的通过标记。

工作入口成为最先贯通的路径。启动时，调用方给出本轮 fork 标识和涉及的节点，汇编器据此生成胶囊及关联义务；会话保存该标识和胶囊引用。随后执行完成提交时，信封继承这两个值。提交门由 fork 标识回查胶囊，才能确认本次提交所依据的范围。

这里保存引用有实际作用。若启动生成了胶囊，完成提交却仍填占位值，改动只完成了生产者这一端。若信封中的 fork 标识与胶囊归属不对应，门也无法按预定路径找到它。开发需要保持启动记录、会话状态和提交来源之间的对应关系，不能只检查控制台多打印了一行胶囊消息。

因此，工作会话需要同时接好两端。规划与工程共识则先接会话起点：两类启动命令调用同一汇编辅助入口，并让起点的 checkpoint 提交引用真实胶囊。共享辅助入口减少了三处各自拼装参数的机会，但它没有自动覆盖这些会话后来发出的每一笔领域提交。

接线还暴露了调用接口中的信息损失。调用方可能知道一些事实、给出禁止事项，或者声明本轮准备写入的对象；原来的汇编入口却不能完整接收这些输入，声明写集在下游还被硬编码为空。即使胶囊已经生成，任务特有的约束也可能在参数边界消失。

签名补全让 known_facts 进入已知事实分区，让 must_not_do 进入禁止事项分区，并把它们纳入调用参数审计指纹。declared_write_set 则进入结构化任务范围 TaskScope，由汇编结果回传同一集合，供提交方填入信封写集。三项信息各有去向：给 Agent 阅读的事实和禁令，需要被保留；用于提交检查的写入边界，需要保持结构与对应关系。

字段进入胶囊不等于每句自然语言都会被程序自动证明。此次字段测试核对的是信息有没有到达正确分区，以及声明写集是否仍然可供下游使用。这一层证据与范围门实际拒绝违规提交的证据不同，两个层次都要保留。

更容易被低估的是义务声明。真实胶囊会激活本轮义务，义务覆盖检查因此开始要求信封说明它们的维护状态。规划和共识的起点若只换成真实胶囊引用，却仍交出空声明，就可能被拒绝。实现复用了从义务生命周期投影派生声明的路径，使新会话能够说明当前活动义务得到维护。这里声明的是维护状态，并没有替任务写下完成结论。

修复之后，最有判断力的观察是：检查会怎样处理一个故意越界的提交。只看正常调用获准，仍无法排除检查继续跳过；只看到一次拒绝，也可能是另一道检查报错，甚至是系统开始拒绝所有提交。

正反控制把这一点变成了可观察的差别。用脱敏概念 A、B 重写案例：胶囊范围只含 A，其他条件保持相同。一笔提交声明触碰 A，门接受提交，没有范围漂移；另一笔声明触碰 B，系统产生 DriftDetected，其类型明确为 scope，再产生 CommitRejected，拒绝记录引用前面的漂移记录。

漂移类型与引用关系使拒绝原因可以核对。范围内获准说明门没有恒拒，范围外拒绝说明这条范围检查没有继续空转。外层测试要求的是这些预期行为：负对照中的提交失败，测试本身应该通过；正对照中的 accepted 说明该提交获准，也不能单独证明整个任务成功。

现行集成测试还保留了无触碰声明时不误拦的案例，以及真实胶囊下遗漏义务声明会被拒绝的案例。它们帮助理解这次接线要守住哪些行为。

当时的交付把接线范围、字段传递、正反控制与回归结果归到同一份验收索引。工作路径贯通了启动与完成；规划、共识接入了会话起点。这些具体结果支持本次任务收口，而不是把“模块已存在”写成生产能力已经全面成立。

验收还把证据作者分开：代码改动说明接在哪里，测试工件说明断言检查什么，事件记录说明当时提交门作出了什么结果。合同安排不具备编辑和写入权限的独立复核，要求再查真实胶囊和越界拒绝，不能修改验收条件让实现过关。工程执行者可以在已授权范围内选择实现，却仍需交出别人能够核对的依据。自开发任务因此有了可审阅的终点，不必把开发者的完成陈述当成全部证据。

这次交付接通了工作启动与完成，规划和共识仅接会话起点。创建概念、增加关系、创建任务等会话中领域提交，当时留待后续逐笔接入同一胶囊与义务声明；其他入口也按路径推进，胶囊正文存储选择仍保留给负责人。

RUN-048 留下的工程价值，是一段能沿证据重建的过程：前提被纠正，生产断线被定位，启动和提交建立对应关系，新生效的义务得到处理，正反控制检验了边界。后来的问题类守卫讨论怎样长期保留此类反例；这次实录记录的是三个主入口各自推进到哪里，后续任务由此获得了明确起点。