HSLG Media

build_docs.py

build_docs.py

Source file: tools/docs/build_docs.py

Module: tools-docs

Size: 542 lines

SHA-256: 9daa5de656b3a5eccdc07c4c5e868a36d74b80e54a0051c41d437f79a0361729

Responsibility

Implements this named HSLG source responsibility; inspect its declarations and tests before changing behaviour.

Declared entry points

  • slug — source line 19.
  • module_for — source line 22.
  • can — source line 188.
  • discover_sources — source line 388.
  • source_detail — source line 398.
  • mk_doc — source line 419.
  • declarations — source line 424.
  • render — source line 436.
  • inline — source line 455.
  • handbook — source line 463.
  • run — source line 467.
  • add — source line 469.

Imports and dependencies

  • Line 8: import hashlib, html, json, re

Behaviour and audit locations

  • Line 43: 'backend-services':'Implements business operations with domain-specific idempotency, authentication and payment rules.',
  • Line 44: 'backend-payment-modules':'Holds payment adapter seams; Stripe remains fail-closed until reviewed live configuration.',
  • Line 48: 'tools-build':'Compiles shared/browser sources and stages genuine Capacitor inputs.',
  • Line 88: - Virtualmin already hosts PHP, MariaDB, HTTPS and site-level permissions; using that infrastructure avoids provisioning a separate always-on service for the MVP.
  • Line 90: - wp_mail() respects active WordPress mail-transport plugins, reducing custom SMTP configuration.
  • Line 126: Use MariaDB on existing hosting with HSLG-owned business tables. A customer has a stable random UUID. Every customer-field save inserts a separate row with another UUID.
  • Line 138: - More records consume disk, indexes, backups and privacy-retention capacity; the owner accepts larger databases.
  • Line 141: - Do not use latest-write-wins for passwords, sessions, payment status, stock or orders. Those require transactional state and idempotency.

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.