Hardware, platform and safety
How Simca is designed: local database, sync between devices, crash safety, isolation of logistics, the packaging builder
Status labels: Built in the repository (checked files or developer tooling, not an app feature) Designed in a document, no code yet Planned: listed in the catalog, not built Not decided Not in the catalog yet (a gap) No claim made
Designed C0205
The shop must keep selling without internet. Every sale is written locally first. Plan for: power loss mid-sale; clock errors; disk full. It is designed in a document and no code exists.
Not decided C0206
The recommended stack uses SQLite with write-ahead logging; a spike to confirm has not been done. Plan for: corruption recovery; migration; file locks. It is not decided.
Not decided C0207
The repo recommends a Rust core with a Flutter UI. It is a recommendation, not a decision, and no spike was done. Plan for: platform coverage; printer plugins; team skills. It is not decided.
Planned C0208
Devices in one shop sync over the local network. The sync engine is catalogued. Plan for: conflicts; clock drift; late devices. In the catalog it is a plan and nothing is built.
Planned C0209
Several tills sharing one database or syncing peer to peer. Plan for: leader device fails; split network; duplicate numbers. In the catalog it is a plan and nothing is built.
Planned C0210
Hybrid logical clocks are listed as a way to order events without perfect clocks. Plan for: device clock jumps; daylight saving; time zones. In the catalog it is a plan and nothing is built.
Planned C0211
Atomic writes and journaling so a failure never loses a completed sale. Plan for: printer prints but sale lost; half-written receipt; battery drains. In the catalog it is a plan and nothing is built.
Designed C0212
The ARCH module keeps logistics separate from the core POS so a fault in one cannot corrupt the other. Plan for: contract versioning; independent rollback; process isolation (not decided). It is designed in a document and no code exists.
Built (repo) C0213
Per ADR-0001 and ADR-0002, Simca Packaging is a server-side or developer-side engine that assembles and signs a package from a package spec. It is not a website builder. Milestone 1 exists in the repository as a Rust library and the simca-pack tool, with artifacts that are still stubs; it does not yet produce an installable bundle. Plan for: spec validation; reproducible output; dependency resolution. It exists only as a file in the repository, not as a product feature.
Planned C0214
The README says reliability over speed; the catalog lists performance targets as items. Plan for: old hardware; large catalogs; report speed. In the catalog it is a plan and nothing is built.
Built (repo) C0215
The logistics subproject has a draft SQLite schema that executes; it is a file, not a product. Plan for: schema changes; contract evolution; constraints. It exists only as a file in the repository, not as a product feature.
Not decided C0216
The README says buy once with an optional yearly fee for updates and the co-op. ADR-0002 adds that users start free and a flat quarterly fee applies only after a locally measured profit threshold. The mechanics are not specified and the threshold is not decided. Plan for: updating offline; licence keys; downgrade. It is not decided.
Planned C0217
English and Spanish, local number and date formats, accessible UI. Plan for: translation quality; right-to-left; currency symbols. In the catalog it is a plan and nothing is built.
Planned C0218
Logs stay on the device and are shared only on request. Plan for: support without telemetry; log size; privacy of logs. In the catalog it is a plan and nothing is built.
Designed C0219
The one download. Per ADR-0001 and ADR-0002 it installs, starts and updates Simca, runs fully offline, shows a plain-sight Offline/Online toggle and is the only place to pick, add or remove elements. Designed in docs/facets/LAUNCHER.md; no launcher code exists. Plan for: windows first; ios must match other platforms with apple limits checked later; safe mode on failed update. It is designed in a document and no code exists.
Designed C0220
An explicit mode in which the launcher and app make no network request at all, like a game launcher's offline mode. Plan for: clock skew; expired manifests cannot be detected offline; mixed online and offline devices. It is designed in a document and no code exists.
Designed C0221
Updates are signed packages, applied only when the user asks, from a static server manifest or a file passed by USB or messenger. No background service, no silent check, no telemetry. Plan for: power loss mid-update; rollback; wrong-platform package. It is designed in a document and no code exists.
Built (repo) C0222
A small JSON file written by the launcher that lists the chosen elements. A v1 draft schema and an example exist in the repo, and the milestone-1 packaging tool validates and hashes the example; the launcher that would write it does not exist. Plan for: dependencies added automatically; pinned versions; no identity data in the spec. It exists only as a file in the repository, not as a product feature.
Designed C0223
Only features that inherently need the online network need a sign-in: Tap to Pay, the co-op price counter, referral validation and the Logistics board relay. Selling never requires sign-in. Plan for: sign-in method not decided; disclosure screen; offline-first fallback. It is designed in a document and no code exists.
Designed C0224
ADR-0001 removed separate role builds. One product, many elements; unselected elements are not compiled in. Presets such as store, bodega or driver are only pre-ticked selections. Plan for: menu entries only from included elements; free pricing class; permissions inside the app are ordinary permission sets. It is designed in a document and no code exists.
Built (repo) C0225
ADR-0002: every element is built first in Simca Packaging (thin manifest, prebuilt artifact, dependency links) and then immediately in Simca or Simca Logistics. The packaging tool refuses an element that claims an app build without a prebuilt artifact. Plan for: thin manifests with no business logic; acyclic dependency links; registry drift from the catalog. It exists only as a file in the repository, not as a product feature.
Built (repo) C0226
ADR-0002: packages are assembled from per-element prebuilt pieces and cached by spec hash; nothing is recompiled per customer and identical specs give identical builds. The spec hash, cache and manifest build exist in milestone 1; the pieces are stubs. Plan for: cache integrity on every read; no timestamps in manifests; real artifacts not yet built. It exists only as a file in the repository, not as a product feature.
Designed C0227
ADR-0002: the launcher shows a plain-sight toggle. Offline uses a local device-bound key and PIN with no registration; online uses cloud credentials, and registration is required only for online use. Designed, with no code. Plan for: lost device key; mode shown at all times; sign-in never blocks selling. It is designed in a document and no code exists.
Designed C0228
ADR-0002: an offline user is offered updates only when a connection exists, as a visible, dismissible notice. There is no hidden polling. Whether one disclosed request on start is allowed is not decided. Plan for: passive connectivity state only; dismissed until a newer version is known; notice sends no packet. It is designed in a document and no code exists.
Not decided C0229
ADR-0002: users start free, and a flat quarterly fee applies only after the business reaches a profit threshold measured locally from its own books, with nothing reported. The threshold value, the definition of profit and whether it applies to free logistics are open. No amount is shown here. Plan for: selling never stops because of the fee; paying by importing a licence code offline; definition of profit and currency. It is not decided.
Designed C0230
ADR-0002: the iOS launcher must look and work like the other platforms; Apple rule limits are checked later and recorded as per-feature exceptions instead of being designed around now. Plan for: replacing app files; loading code; per-feature exceptions. It is designed in a document and no code exists.
Built (repo) C0231
A test in the packaging crate fails the build if network crates, sockets, URLs, process spawning or URL/token environment variables appear, or if a denied crate enters the lockfile. It passed when we ran the suite. It guards the packaging tool only, not the future app. Plan for: new dependencies need an allowlist entry; applies to the tool, not the app; passing today says nothing about later commits. It exists only as a file in the repository, not as a product feature.