设想法院已有业务系统向 Zuno 提交一项合同争议分析。接口很快返回“已受理”，后台开始检查材料、检索证据并运行分析。十几分钟后计算已经结束，页面也拿到了一份草稿；专业人员随后修改其中一处事实，正式工作成果才真正形成。系统把成果发送给外围 Host，下午又补入一份关键证据，刚刚交付的版本因此需要复核，而外围 Host 此时恰好离线。
如果入口层只有一个 status=success，这条时间线很快就说不清了。请求被接受、后台计算结束、正式业务结果成立、结果当前允许展示、外围消费者已经收到，是在不同时间发生的事情，也可能由不同系统证明。
Application & Integration 负责把这些已经成立的内部事实翻译成稳定的产品行为。Web、法院 Host、批处理任务或 API Client 不需要理解九个责任域的状态机，但需要知道自己提交了什么、现在可以看到什么、结果还能不能使用，以及交付进行到了哪里。入口层组合这些事实，不重新裁决 Knowledge、Domain、Security 或现实 Effect。
简单问答没有必要承担这条完整生命周期。用户只问“合同第 8 条约定了什么”，访问范围明确、材料已经可用，也不需要长期正式成果时，一个普通应用服务调用检索和模型后就可以返回答案。Application 的复杂度从长任务、正式结果和跨系统交付出现以后才开始增加。
如果产品界面只围绕 Conversation History 组织，前面的事件抽取、冲突识别、证据关系和事实—法条对应最终仍会被压回一段段聊天文本。模型升级或重新分析以后，用户只能翻对话寻找“上一次 Agent 说过什么”，很难持续维护一宗案件已经形成的专业结构。
对多材料、需要反复复核的任务，更稳定的产品视图是 Matter / Case Workspace。专业人员进入案件后，应该能够看到当前材料范围与就绪状态、案件事件时间线、当事方陈述冲突、证据支持与反驳关系、事实—法律依据候选、尚未解决的问题、机器候选、人工判断、正式 WorkProduct 及其当前有效性。聊天框仍然可以用来提问、发起研究和修改任务，但它只是操作这些结构的一种入口。
01 不因此拥有新的业务事实。材料状态和候选结构来自 03，专业能力来源和资格来自 05，运行中的研究进度来自 04，正式 HumanDecision / WorkProduct 来自 02，当前授权来自 08，现实交付结果来自 06。Application 只把这些 Owner facts 组合成用户可理解的 Workspace projection，并提供稳定导航、查询和操作入口。
这也使 Agent Harness 可替换。今天用户可能通过对话触发“分析付款争议”，明天产品可能改成结构化任务面板或由外围 Host 直接调用 API；只要 Matter identity、候选结构、正式结果和状态语义不变，产品不需要因为换了一代 Agent UI 就迁移全部法律工作历史。
Workspace 也不意味着所有候选都永久保存。临时 query rewrite、模型思维过程、一次 rerank 分数和无长期价值的中间文本仍然留在运行或观测层。Application 展示的是当前任务真正需要复核、继续操作或长期引用的结构，不把“Agent 产生过的一切”升级成产品对象。
复杂请求常从一句“帮我分析这个案件”开始。对人来说已经足够，对一个可能运行几十分钟并在崩溃后恢复的系统却还缺少边界：分析哪个 Matter，使用哪些材料，目标是普通回答还是正式成果，谁发起请求，以及网络重试到来的第二个请求是不是同一次用户动作。
Application 先把这些外部表达整理成稳定任务上下文。用户后来把范围从合同扩大到“合同加全部聊天记录”，这不仅是页面筛选变化。Knowledge 需要重新判断新增材料是否就绪，Security 也要重新判断当前主体能否访问扩大的范围。后续模块只有引用同一份明确任务条件，才能在同一个业务世界里工作。
外部 Host 传来的 user id、tenant、role 或 matter id 也先只是 assertion。Adapter 可以完成认证协议、字段映射和 Host 兼容，但当前主体能否读取材料或执行动作，仍由 Security 根据可信身份和当前策略决定。这样 Web 请求、后台 Worker 和恢复流程不会因为脱离原始 HTTP session 就各自长出权限规则。
网络重试则要求一次用户动作有稳定身份。浏览器可能没有收到第一次响应，API Gateway 可能重放请求。如果入口每次都新建 Run，一次点击就可能变成多个后台任务，最终甚至重复交付。相同的逻辑调用和相同规范化输入应能够找到既有处理；同一个调用身份却携带不同内容时，系统应暴露冲突，而不是悄悄把两件事当成一件事。
任务上下文稳定以后，Application 才选择产品路径。简单问答走短路径；需要等待、并行、人工或长期恢复的任务交给 Runtime；需要成为长期法律成果的内容最终由 Domain 接纳。工程实现可以把这个路由结果记录成 InvocationDecision，但这个记录只说明产品选择了哪条路径，不因此获得下游事实的所有权。
长任务结束时，最容易写下的一句产品文案是“分析完成”。如果任务只需要一份临时草稿，这句话可能足够；如果用户期待的是正式工作成果，它就可能过早。
Runtime 能证明自己的计划与步骤已经结束。正式 WorkProduct 是否成立，要看 Domain 是否已经完成业务提交。普通答案即使已经生成，也还可能因为材料范围、引用或当前发布条件变化而不能展示。Application 需要把这些观察组合成用户能理解的状态，而不是让某一个内部 completed 替整条业务链做决定。
产品版本与运行计划也在这里分开。一次产品发布可以改变新请求默认使用的 Prompt、能力集合或路由策略；已经运行中的任务仍按自己绑定的计划前提解释。Application 记录用户调用的是哪一版产品能力，Runtime 继续拥有这次 Run 当前怎样执行。产品升级不能在后台把已经派发的工作悄悄改成另一套计划。
取消请求同样只影响还可以停止的未来。入口可以接受用户取消，要求 Runtime 停止新的工作，也可以阻止尚未开始的交付；已经正式成立的 Domain 事实、已经发生的模型费用和已经确认的现实 Effect 仍然属于历史。若业务需要撤销一个外部动作，需要产生新的受控动作，而不是用页面上的 CANCELLED 把过去抹掉。
上午形成的 WorkProduct V5 已经交付给外围法院系统。下午新证据进入，Domain 判断 V5 需要复核。这个变化应立即在 Zuno 内成立，不会因为外围系统离线而继续把 V5 当成当前有效成果。
Application 负责把这种变化传播给消费者。Push 可以降低通知延迟，却可能因为断线丢失；所以正式成果还需要提供 Pull 查询，让外部系统在真正使用结果时确认当前版本和有效性。网络通知只是传播已经成立的业务状态，不会反过来决定旧成果是否仍然有效。
交付本身也需要稳定产品身份。同一份成果可以发给多个目标，同一个目标又可能因为网络异常出现多次发送尝试。Application 保存“应该把哪一版成果、按照哪一版外部 Contract 交付给哪个消费者”的产品语义；真正改变外围系统状态的调用交给 Effects。
如果远端创建记录时连接在响应前断开，Application 不能因为自己看到 HTTP timeout 就宣布交付失败并重新 POST。远端可能已经成功。Effects 先确认现实动作究竟发生了什么，Application 再根据这份结果更新自己的交付观察。这样产品承诺和现实副作用不会被同一个 retry loop 混成一种状态。
即使远端返回 acknowledgement，Zuno 通常也只能证明对方接收了某次消息或请求。对方内部是否最终采用结果、某个远端页面是否已经展示，仍由那个外部系统自己证明。Integration 保存自己真实观察到的事实，不替不受 Zuno 控制的系统编造内部状态。
Web 可以同步等待几秒，法院 Host 可能异步提交后轮询，批处理只关心最终 artefact。REST、消息队列和 Host SDK 的传输方式不同，任务受理、草稿、正式结果、失效、取消和交付的含义不应该因此分裂成多套版本。
Adapter 负责协议转换、字段兼容和版本协商，产品状态仍然从相同的 Owner facts 组合出来。Runtime queue 或模型配额过载时，Application 也应把 queued、deferred、rate-limited 等真实背压传达给调用方，而不是无限受理后让所有请求一起超时。对外 Contract 的任务是稳定消费者预期，不是把内部每一个状态原样泄露出去。
如果 Zuno 只作为单体应用里的内部库使用，没有多 Host、长任务、异步交付和失效传播，Application 可以缩成很薄的一层函数调用。即使这些能力存在，它默认仍只是逻辑责任；只有协议隔离、吞吐、网络边界或独立生命周期形成真实需求以后，Adapter、Outbox、Queue 或独立服务才值得增加。
Target： 01 负责组合其他 Owner 已经成立的事实，形成稳定的 Matter / Case Workspace projection、请求受理、产品路径、普通答案发布、正式成果发布、Delivery、失效传播和外部 Contract 语义；Knowledge readiness、正式 Domain 状态、Authorization 和现实 Effect 仍由各自责任域决定。聊天、表单或 Host API 都只是访问这些语义的产品入口。
Current： 上述案件 Workspace、多 Host 生命周期、完整 Invocation / Delivery identity、Push + Pull 失效传播和复杂交付恢复属于 Target 设计。现有 Application、API、Host 集成或运行代码实际实现到哪一步，只以 docs/evidence/、代码和测试证据为准。
Gap： 仍需要真实案件 Workspace 的用户研究与界面验证、Host Contract、重复请求与断线重试测试、正式成果失效传播演练、外部交付边界、背压行为以及是否值得独立部署的容量证据。没有这些证据时，不把 Target 写成已验证产品能力。
工程 / Agent 精确参考与跨模块一致性规则见 reference.md。