module_explanations.py
Source file: tools/docs/module_explanations.py
Module: tools-docs
Size: 263 lines
SHA-256: 94652711b32eb1df82626151ba505f24cd87753a6adf04bc77c76d49d1aff631
Responsibility
Implements this named HSLG source responsibility; inspect its declarations and tests before changing behaviour.
Declared entry points
to— source line 30.and— source line 53.of— source line 150.and— source line 217.is— source line 227.shape— source line 247.
Imports and dependencies
No direct import declarations detected in this file.
Behaviour and audit locations
- Line 15:
These are local tests, not proof that cron, WP-CLI, PHP-FPM permissions or Gradle work on a freshly upgraded Virtualmin site. Run a real HSLG release upload, inspect the - Line 34:
Do not place REST route permissions, secret keys or cross-tenant database settings in the bootstrap. Extend a contract or a focused service and adapt it at the WordPress - Line 52:
New customer fields receive fresh UUID record identifiers and an originating MariaDB written_at default. SQL latest selection orders by original timestamp and record UU - Line 55:
The payment module has a gateway interface, an explicit unconfigured implementation, and Stripe-specific gateway/webhook-verifier classes. This structure prevents busines - Line 59:
Only the server can hold secret Stripe credentials, compute allowed amounts and verify signed provider events. The mobile app should send an intended basket and display c - Line 66:
CustomerProfileReader.php reads approved customer-field values through a repository. OrderLifecycle.php defines conservative order transitions and unknown outcomes. - Line 74:
Exercise allowed/forbidden transitions, duplicates, missing identity, changed product prices and unverified payment evidence. A server-side unit test may establish the lo - Line 85:
For a new capability, define how cancellation, timeout, missing permission and unavailable backend are represented. Update both runtime adapters and all related contract
Relationship to the system
This page is the file-level source reference, not the architecture rationale. Read the module explanation, the corresponding architecture decision and user guide before changing behaviour. Names and line locations above are extracted from this exact source version; they are reference points, not proof that an external service or a phone feature works.
Change verification
Review the entry points and errors in this file, then run the module’s associated tests, source dependency gate, history gate and documentation coverage check. If the file changes an API response, user interaction, data model, deployment or third-party dependency, revise those human explanations and disaster recovery/licensing when relevant. Do not infer actual native or external API operation from source presence.