Testing and reporting a bug
Record the application version, device/OS or browser, venue, screen, actions, expected result and actual result. Include a screenshot without account tokens or personal payment details. Distinguish the WordPress presenter demo from the real Capacitor APK in every report.
A passed browser test is not a successful physical Android/iOS test. A PHP unit test is not a real MariaDB migration. The current native release gate remains blocked until complete Capacitor dependencies and device evidence exist.
Identify exactly what was tested
HSLG has distinct artifacts: source archive, WordPress presenter ZIP, WordPress API ZIP, documentation publisher ZIP, a signed Android APK and eventually an iOS IPA. They are not substitutes. A presenter can exercise design and fictional customer journeys; an API test can exercise PHP contracts; only a genuine native build on hardware can verify the Capacitor camera, haptics, keyboard and OS app links. Every result must name the artifact and environment.
Reproduce a customer fault
Record the app/plugin version, venue, starting page, actions in order, expected response and actual response. Include the phone model, Android version, app package ID and whether internet/API reachability changed. For the browser presenter include the browser, viewport width and whether the scenario was a demo simulation. Reproduce once if safe; do not repeat payments or account recovery codes recklessly. Remove secrets, customer records and card information before sharing screenshots or logs.
Before a documentation release
Verify the three primary documentation trees, licensing hierarchy, devlog and single disaster-recovery page. The generated bundle must match reviewed Markdown exactly, source files must map to Code references, and substantive pages must pass a depth/coverage check. Install the documentation publisher by WordPress's normal upload/replace flow and confirm automatic publication, stable post IDs and revisions. Manually edited or unowned pages must block rather than being overwritten.
Before an API release
Verify independent plugin packaging, database migration compatibility, site-scoped configuration, authentication/authorization, rate limits, verified email transport and order idempotency on actual staging MariaDB. Backups, failure recovery and schema rollback implications must be documented. A PHP mock does not prove MySQL/MariaDB constraints or email deliverability.
Before a native mobile release
Resolve pinned JavaScript/Maven dependencies, compile the shared native entry, sync Capacitor, build/sign the APK, inspect the installed bridge/plugins and test a physical phone. Deny/allow camera permission, scan correct/invalid QR codes, open HTTPS app links, rotate the screen, show the keyboard, change network state and test session persistence when its secure vault exists. Missing evidence means the release remains blocked, not silently downgraded to another WebView preview.
Complete the evidence trail
Append each action to the project chronology and reference saved commands for infrastructure steps. Update the relevant Code, Architecture, User Guide and disaster-recovery text for any changed behaviour. Record commercial licensing status for added media or dependencies. Publish a release report listing passes, failures, skipped tests and known outstanding work. Do not declare production readiness solely because the packaging script exited successfully.