Core actions must still work with the radio off, not just remain readable

What it is

With the radio off, people can still finish the acts the product exists for: write, tick, restructure, record, drag a card from this column to that. Being able only to flip already-downloaded read-only copies is offline browsing, not local-first. Core operations remain available with no network at all defines available as able to change the authoritative replica, not merely able to see it.

Core is the few things the product promises, not every button that has a gateway. Search of the whole corpus, pulling a comment someone just wrote, payment, may stop with no net. What should stop is the periphery, not the main loop.

Why it happens

Read-only offline treats local as a cache: a hit can be seen, a miss is a hole, every write waits for the net. Once the main loop includes “create or change”, a cache model is not enough. Create needs a local identity, a structure written, later reads hitting that new structure — which is exactly what an authoritative replica is for. If New still looks alive with no net and tapping it yields only “needs a network”, core operations lied at the door.

“No network at all” is a harder test than a weak link. A weak link can still land a request by luck and hide a half local-first. Total isolation forces the real dependencies: analytics SDK, avatars, permission checks, fonts. Any online round trip written into the main path will jam the core at this moment. Available means the main path has no such round trip.

Where it stops holding

A live multi-person room (a call, a shared cursor) has no counterpart with the radio off; if core is defined as “edit the same cursor together in this moment”, local-first cannot help. Core should degrade to “edit my copy, exchange when the link returns”. Objects with no local data (a cloud sheet never opened) are unavailable offline — a scope issue, not a failed definition of core. Core should hold for work already on this device. Missing hardware (no mic, but record is required) is not a network problem. Anti-cheat and stock deduction that must be judged online should never have included “decrement stock offline” in core.

Applying it

• List five operations users think “this product is for this”, and walk them in airplane mode. They should complete, with the result visible locally.
• New objects mint a local identity offline; later edit, delete, and lists all recognise that identity.
• Move permission checks, analytics, decorative assets off the main path. Offline, decide from cached permission; do not block save for a beacon.
• How to check: cold start in airplane mode (not online-then-cut). Create once, edit once, change structure once. All three should succeed. Then open a cloud object that was never cached: failure is allowed, but it must not drag the already-local items into read-only. Contrast a read-only offline reader: it should fail this leaf outright, not be called local-first.

Related

• Same group: I3.10.1 Local-first treats the device copy as authoritative; the network is optional · I3.10.3 Eventual consistency needs a graspable convergence story · I3.10.4 Long offline stretches explode into mass conflicts on reconnect
• Nearby: I3.03 Offline state · E6.14 Offline and Connectivity Notices
• Search terms: offline-capable · core operations · local-first write