Backend Root module
This module owns a distinct part of the HSLG implementation.
Why a small bootstrap exists
backend/bootstrap.php prepares the core PHP business classes for runtime integration. It is deliberately smaller than a controller or repository. The server's choice of WordPress as initial host should be an adapter decision, not a requirement that every service import WordPress functions. This boundary keeps unit tests possible and leaves a migration path to a separate API service if hosting load or operational needs justify it.
Security and failure handling
A bootstrap should fail observably if required classes or services cannot be loaded. It must not register unreviewed public account routes, embed secret tokens, change Virtualmin global PHP settings or create business records during a simple source import. Authentication, authorization, schema migrations and provider calls belong to dedicated layers. Any changes to initialization order require both PHP contract tests and staging activation evidence.
Relationship to other modules
For account and order actions, trace the WordPress API entry into controllers, then business services and repositories. For payment operations, follow the separate gateway interface and server verification. For documentation publishing, use the independent WordPress publisher; this backend bootstrap is not its release mechanism.
Source files in this module
Maintenance and evidence
Check all affected file references and the matching human-readable user/architecture page when source changes. Run the module’s contract or governance checks; staging, payment and native hardware tests remain independent of source inventory coverage.