I3.10.2offline-capable core operations设计
本地优先能让核心操作在完全无网络时依然可用而不仅是可查看
别名: 离线可写 · 不只是只读 · core offline · 无网也能做
概念解释
没有无线电时，人仍能完成产品之所以存在的那些动作：写字、勾任务、改结构、录音、把卡片从这列拖到那列。只能翻已经下载的只读副本，那是离线浏览，不是本地优先。核心操作在完全无网络时依然可用把「可用」定义成能改变权威副本，而不只是能看见它。
核心是产品承诺的那几件，不是每一个带网关的按钮。搜索全库、拉别人刚写的评论、付款，可以在无网时停下。停下的应是外围，不是主循环。
机制
只读离线把本地当缓存：缓存命中则能看，未命中则空洞，任何写入都要等网。主循环一旦包含「创造或改变」，缓存模型就不够。创造需要在本地分配身份、写入结构、让随后的读打到这份新结构上——这正是权威副本要干的活。若无网时新建按钮还在、点下去却只得到「需要网络」，核心操作在入口层撒谎。
「完全无网络」是比弱网更硬的测试。弱网还能碰巧打成一次请求，把半套本地优先掩盖过去。完全无网逼出真实依赖：分析 SDK、头像、权限校验、字体，任何被写进主路径的在线往返都会在这一刻把核心卡住。可用意味着主路径上没有这样的往返。
边界
多人实时的房间（通话、共同光标）在无网时没有对端，核心若被定义成「一起编辑此刻的同一光标」，本地优先帮不上。应把核心降级为「编辑我这一份，连通后再交换」。没有本地数据的对象（从未打开过的云端表）无网时不可用，这是范围问题，不是核心定义失败——核心应对已经在这台设备上的工作成立。硬件能力不在（无麦克风却要录音）也不是网络问题。游戏反作弊、库存扣减必须在线裁决的，核心里根本不应包含「离线扣库存」。
怎么落地
- 列出五件用户认为「这个产品就是干这个的」操作，在飞行模式下走一遍。应能完成并在本地看见结果。
- 新建对象在无网时分配本地身份，随后的编辑、删除、列表都认这个身份。
- 把权限校验、分析、装饰性资源移出主路径；无网时用已缓存的权限决策，不要为一次打点堵住保存。
- 验证：飞行模式冷启动（不是先在线打开再断网）。做一次新建、一次编辑、一次结构改变。三件都应成功。再打开一份从未缓存的云端对象：允许失败，但失败不得把已经在本地的那几件也拖成只读。对照只读离线阅读器：它应在这条上明确不合格，而不是被说成本地优先。