qqq-android/docs/CI-FIXTURE.md

Hosted scanner fixture

The source pins and complete Maven commands live in Scanner Android. The fixture uses core commit ecf0f550a0357cec6387c2b54efca128a405a629 and scanner server commit 10416938724c9663d66f7848ff2b1a63fe635794. The core includes the UI API 1.9 native authentication contract, credential log redaction, explicit JSON null handling, the Guava 33.7.2-jre security update, portable SPA filesystem paths, and automatically allocated spec-test ports. The scanner includes the canonical UTC H2 migration, the demo BOM import that aligns all transitive QQQ dependencies with the selected version, and the additive mobile-scanners1.2 capture-mode contract. The normal operator server remains a separately qualified runtime; a CI source pin does not replace it.

Each job creates a fresh Maven repository under the runner's temporary directory. Core is built as 4.1.0-ci.<full-core-SHA>; the scanner and demo receive that exact version through qqq.version. This 49-character value retains the full commit identity and fits the core's 50-character help-bundle version limit. Nothing installs into the runner's shared Maven repository, substitutes a published artifact, or restores a cached QQQ snapshot. The scanner's own fixture snapshot is built from its checked source in that same fresh repository. This is an isolated CI source qualification, not publication of a production release or adoption by an operator server. The optional Record Files integration has its own dependency qualification.

The core reactor includes the BOM and middleware API with their required upstream modules. It runs every test in that dependency closure, Checkstyle, JaCoCo coverage checks, SpotBugs and PMD through the full clean install lifecycle. The scanner and demo then run their full verification suites before Maven writes the demo's runtime classpath, dependency tree and effective POM. The standard jar tool and Node SHA-256 implementation inspect that resolved classpath: every runtime JAR must belong to the private repository, every backend QQQ module must use the unique core version, required modules must exist, exactly H2 2.2.224 and Guava 33.7.2-jre must occur, and QQQ-owned JARs must not duplicate backend classes. The pinned frontend distribution keeps its independent version.

fixture-provenance.json records all resolved runtime JAR hashes, both source commits, the core revision and the unique QQQ class count. The dependency tree, effective POM and test evidence accompany the emulator artifacts. These checks inspect the selected runtime closure; they do not promise reproducible byte-for-byte Java builds or validate a published release.

For a local reproduction, check out both exact commits into disposable source directories and run the workflow's Maven commands with a new empty private repository path. Use Java 21, the checked-in wrappers, two active processors and a 768 MiB heap. Windows PowerShell uses mvnw.cmd and quoted -D arguments. Never point maven.repo.local at the shared .m2 repository or reuse an operator database. Run verify-fixture-provenance.mjs with the server directory, private repository path, core SHA and server SHA, then run the emulator entry point as described in EMULATOR.md.

The local Windows qualification adds -Dexec.skip=true only to the core command because Maven's inline sh -c coverage-summary formatting fails Windows argument quoting. The inspected dependency closure has only that cosmetic exec-plugin execution. This exception retains all tests, coverage checks and static analyses; the hosted Ubuntu command keeps the summary enabled. Do not use a focused test selector with the full lifecycle: its coverage thresholds apply to the complete module suites.

Preserve the full native runner. In particular, admin-forms submits an actual optional null reason through the native session-ending form and guards the prior HTTP 500 failure. session-monitor separately verifies screen viewing, remote termination and fresh login; its administrative helper alone does not exercise that nullable form. TABLE_BASED fixture metadata must not advertise OAuth2-only native login support. Actual configured identity-provider acceptance remains a separate gate.