该模式在 domain 模块中定义一组仓库返回值封装类型，与返回它们的仓库接口放在一起，使实现方与调用方无需相互依赖即可引用这些类型。
用途 面向仓库边界的三类情况各设一种封装：Resource 用于远端两态结果（Success、Error）；LocalResource 用于本地读取，额外包含 Loading 状态；NoResponseResource 用于只返回消息、无数据载荷的操作，同样含 Success、Error、Loading。Error 可选携带 data，使部分结果或缓存结果能与失败信息一同返回，界面可同时展示旧内容与提示。
主要能力 wrap 侧为每种形状提供辅助函数：wrapDataResource 先发出 Loading，在指定调度器上执行 block，并把成功或失败转为对应封装；另有面向仅确认消息操作的 wrapMessageResource 和面向已返回 Result 的 wrapResultResource。flowOn 置于辅助函数内部，调用方无需决定执行线程。collect 侧为每种封装提供 collect 与 collectLatest 两个版本，后者避免界面重入时任务堆叠。
使用方式 仓库实现内部以 internal 扩展函数完成传输模型到领域模型的映射，例如 internal fun ServiceDto.toTrack(): Track，映射不放在封装类型或 ViewModel 中；封装应携带领域类型而非传输类型。仓库方法只写业务操作，由 wrap 辅助函数统一包装。
适用场景 适用于 Kotlin 多平台、Clean Architecture 风格的仓库层，尤其是需要区分本地与远端读取、并统一加载与错误处理的场景。
限制与陷阱 需在辅助函数和手写仓库方法中重新抛出 CancellationException，避免 runCatching 吞掉结构化并发的取消信号；辅助函数只有在仓库实际使用时才有价值，可通过统计 wrap 调用数与手写 runCatching 数量对比验证；每种封装都应配套 collect 辅助函数，避免调用点手写分支；Success 的载荷应在子类中声明为非空，避免消费者被迫判空；挂起函数返回单个封装值不可能是 Loading，该状态只属于返回 Flow 的操作；message 为字符串会抹平失败类型，若需按失败种类分支，应补充类型化原因。
验证方法 可用 grep 检查封装文件中 Flow 返回类型是否误用裸 Resource<T>，并统计 CancellationException 出现次数；还可检查 domain 仓库接口的 import 是否混入集成模块类型。原文给出的检查结果显示，取消异常修复在该代码库中尚未落地，且存在一处 androidx.paging.PagingData 导入。