Compartment principle (core and Logistics fail separately)
ARCH-0001 Planned Lite and Pro CoreA fault, update or rollback in Simca Logistics must never crash or corrupt Simca core, and vice versa
Catalog section · ARCH
15 planned items in Compartmentalization: Core/Logistics Isolation, Contracts & Independent Delivery.
A fault, update or rollback in Simca Logistics must never crash or corrupt Simca core, and vice versa
Simca Logistics lives in its own top-level folder with its own source, tests and docs
Depends on: ARCH-0001
Shared code is limited to immutable, versioned libraries (e.g. crypto, money type) vendored per side; no shared mutable modules
Depends on: ARCH-0001
Each side owns its tables; no cross-side joins, triggers or foreign keys
Depends on: ARCH-0001
Logistics data in its own SQLite database file (WALWrite-ahead logging, a SQLite journaling mode the stack recommendation uses for durability. Glossary, synchronous=FULL), never inside the core DB file
Depends on: ARCH-0001
Logistics owns its schema version and forward-only migrations with tested rollback copies
Depends on: ARCH-0001
Automatic snapshot before any migration, restore path on failure
Depends on: ARCH-0001
Logistics has its own MAJOR.MINOR.PATCH version independent from core
Depends on: ARCH-0001
Core keeps its own versioning; Logistics never reads core internals
Depends on: ARCH-0001
Separate build, lint and package steps per compartment
Depends on: ARCH-0001
Separate unit, integration and property tests per compartment
Depends on: ARCH-0001
Separate release notes, signing and artifacts per compartment
Depends on: ARCH-0001
Core must run fully with Logistics absent
Depends on: ARCH-0001
Static check that forbids imports across the boundary except the contract package
Depends on: ARCH-0001
Document who owns which tables, files, logs and keys
Depends on: ARCH-0001