Architecture, rationale and trade-offs
This section explains why HSLG uses one shared UI, independent WordPress plugins, MariaDB business tables and Capacitor native adapters. Each decision is evaluated against limited operator time, limited budget, security and recovery needs. Architecture pages identify rejected alternatives, known unfinished work, operational cost and evidence needed before scaling.
Reading order
Start with Scope and Constraints. Continue with Why WordPress, Shared UI, Database, Identity, Payments, Native Capacitor and Environments. Release Quality, Documentation Design and Development Provenance describe how the design is maintained. If an operation has recovery implications, also read the single Disaster Recovery manual. These are design explanations, not a claim that every described future capability has been deployed.
Architecture chapters
- Scope and constraints
- Why WordPress remains in the architecture
- Why shared UI and separate runtimes
- Customer records, MariaDB and time semantics
- Self-hosted identity and verification
- Why orders and payment state are different
- Why Capacitor and current limitations
- Hosting safety and deployment boundaries
- Three environments and hand-offs
- Release gates and actual evidence
- Documentation navigation and ownership
- Dependencies and reproducibility
- Development history versus documentation revisions
- Automatic Android builds, queue security and debug exports