Release gates and evidence

Each release has independent gates for source hygiene, contracts, dependency resolution, browser demo, documentation, WordPress publication and native artifact verification. A gate result must specify its target environment and required evidence.

Documentation gate

• Every owned source file gets a Code reference page. Every module gets a module overview.
• Architectural decisions explain reasons, alternatives, benefits, operating costs, risks and deferred work.
• User guides distinguish demonstrative operations from live API and device functionality.
• All page IDs, paths and source hashes match the publication manifest.
• Edited modules require changed documentation. Unchanged text cannot be blessed merely by updating a timestamp.

Publication gate

Documentation is built and checked locally first. Publishing to WordPress is a separate stage. The publisher checks existing paths for HSLG ownership; a collision blocks instead of overwriting someone else's page. Activation and release updates run automatically using WP page APIs, require unlimited revision history, retain page IDs and record last-applied bundle checksums. They never delete or bulk-replace tables. A local pass never means WordPress publication happened.

Native gate

An Android source scaffold is not an APK. An APK signature is not proof of Capacitor plugin operation. A backend test double is not proof of email delivery or real MariaDB migration. iOS needs an Xcode/macOS build and signing evidence. Money-related flows require real test-mode provider reconciliation.

Why this project uses multiple gates

A one-person project cannot rely on remembering every previous incident when producing a release. HSLG has independent failure modes: a WordPress documentation page can be replaced incorrectly, a native app can include simulated payment code, MariaDB can reject a migration, a third-party image can lack commercial rights, and Virtualmin can be damaged by a global PHP change. A single 'tests passed' flag hides these differences. Release evidence must be scoped to what each test actually proves.

Source and dependency gates

The source gate validates architecture boundaries, shared UI versus demonstration adapters, approved asset inventory and native-only imports. The dependency gate checks allowed packages, versions and lockfiles rather than assuming that manually uploaded tarballs include all nested requirements. An Android Gradle Plugin JAR is one piece of a Maven dependency graph. A build with missing libraries is blocked, even if a browser-only preview compiles. Do not lower native requirements to make a ZIP appear releasable.

Documentation quality gate

Documentation must be written for a human who did not participate in development. An architecture page explains the decision, alternatives, trade-offs, operational cost, exact current state and failure/recovery path. A User Guide describes the user's action, what the system does, success and failure meanings and current limitations. A Code page explains module ownership, inputs/outputs, significant side effects, authorization and relevant tests. A list of pathnames, hashes or function names alone is an index, not a completed guide.

Quantitative checks can catch obvious failures—missing sections, very short substantive pages, unchanged pages after significant source changes, duplicated text and non-existent source links—but cannot prove that a paragraph is useful. A separate human review of a representative sample and every changed high-risk module is necessary. The release report must state which pages were actually read, which source files informed them and what is still unknown. Do not satisfy a word-count gate with repeated generic sentences.

History, disaster recovery and licensing

Every release adds concise, numbered entries to the append-only development chronology; previous rows must not be rewritten. Changed recovery commands, PHP settings, build dependencies or deployment process trigger a new disaster-recovery review. The licensing register tracks exact packages and media hashes, evidence and unresolved permissions; code compilation is not proof that images/fonts may be commercially redistributed. These gates remain independent of a successful WordPress publication event.

WordPress publication gate

The source Markdown and generated HTML are checked before packaging. The documentation publisher must preserve HSLG-owned page IDs and normal WordPress revisions through wp_update_post(), skip unchanged pages and block collisions/manual-edit conflicts. Local publisher tests are not evidence that media.hslg.uk has actually imported every page. After upload the operator verifies page count, representative content, post IDs, revisions and any admin notice. Never delete/recreate pages simply to make a publisher update pass.

Native and backend release gates

API releases require staged MariaDB migrations, authorization tests, email delivery and rollback planning. Mobile releases require locked JS/Maven dependencies, compiled native assets, Capacitor sync, signed APK/IPA and real hardware evidence. The presence of adapter source or a scaffolding directory is insufficient. Financial success requires server-owned pricing, approved merchant configuration and reconciled provider events. The presenter may progress while native checkout stays blocked, but its success screens must remain explicitly demonstrative.

What happens when a gate fails

A failed gate stops the associated release tier. Record the exact command, output, source hash, affected environment and remediation. Do not mute tests, change baselines to hide defects or relabel an incomplete build as production. If the failure comes from stale documentation, correct the canonical source and rebuild the publisher. If the issue is a live server discrepancy, repair it at the narrowly scoped Virtualmin site boundary after a backup and diagnostic review.

Integrity of the release seal itself

The history seal docs/history/RELEASE-BOUNDARY.json is an output of an explicit source-and-history approval, not a file that an individual author edits as application source. The history validator checks its current chronology ID, every earlier row digest, and the full owned source-tree hash. Writing that seal after reviewing the source necessarily changes the seal's bytes. If the mirrored AGENTS.md inventory included those bytes, acknowledging the seal would invalidate the inventory, and resealing would invalidate the acknowledgement again. The agent inventory therefore excludes only this exact seal file and continues to track docs/history/CHRONICLE.md, the CSV journal, SSH command references and actual application source. The separate history gate still requires the release seal and blocks changes to its protected source inputs. The change is tested against a fake seal and against ordinary history files to ensure only the self-referential output is exempted. This is a dependency ordering correction, not permission to modify earlier entries or bypass reviews.