Hardware, platform and safety / Offline-first architecture
What goes wrong with “Offline guard tests” in a shop, thinking about new dependencies need an allowlist entry?
Built in the repository (checked files or tested library code; not a product you can run yet) C0248
Tests in the Rust workspaces fail the build if network crates, sockets, URLs, process spawning, demo keys, default network binding or remote asset loads appear. The workspaces' test suites passed when we ran them on 2026-10-04 (460 tests in total across packaging, core, Logistics and launcher). They guard the code in the repository, not a shipped app. Plan for: new dependencies need an allowlist entry; applies to the code, not a future ui; passing today says nothing about later commits. It exists only as a file in the repository, not as a product feature.
How to read this
The tag above says how real the answer is. Answers describe the plan in the repository and design documents. No app is released. Where an answer touches tax or law, treat it as a theme to verify with a qualified local adviser.
More in Offline-first architecture
- How does Simca approach “iOS launcher parity”, considering replacing app files?
- Where does “The launcher's one opening request” fit in Simca, in particular regarding network address visible to the host?
- Which edge cases come up around “The launcher has no account”, thinking about offline mode governs the app only?
- See it in context with the whole topic
- Search all answers