QA Changelog 4.0.1

The build measured coverage but never checked it: there was no jacocoTestCoverageVerification, so coverage could slip and nothing would say so. Add one at 0.81 instructions / 0.66 branches — just under the current 81.6% / 66.4%, so an honest refactor still builds while a silent regression does not. Verified both ways: raising the minimum to 0.99 fails the build with the expected message.

Also turn the XML report back on. CI and SonarQube read the XML, not the HTML, and with xml.required = false there was nothing for them to read — this report had to be generated through a side task to get at the numbers at all.

The dashboard in docs/ is generated from that XML and the JUnit results: 820 tests, 0 failures, coverage by domain and by package, and the gaps stated plainly — config at 7.3%, no integration tests against a live database or ACS (Testcontainers is unused, @SpringBootTest appears in two files), no E2E. For an integration layer, that last one is the gap worth planning around.

The minimums were set flush against the current numbers — 0.81 against 81.6% of instructions, 0.66 against 66.4% of branches. That leaves half a point of head- happened to add it.

A gate that fires on ordinary work does not survive its first deadline; it gets switched off, and then it protects nothing. Drop the minimums to 0.78 / 0.63 so the build fails when coverage drops meaningfully — tests deleted, a sizeable untested chunk merged — and stays out of the way otherwise.

Also fix the dashboard, which still said the gate did not exist and the XML report was off. Both were true when it was written and false by the time it was committed — in the same commit that changed them.

compose.yml handed the same .env to both containers while installation.adoc documented a two-layer model with provision-api/.env and provision-portal/.env, and the FT_DISK bundle ships those two files. The repository was the odd one out.

The split follows the boundary the file already had in its section comments, with one correction on top: the seven variables compose.yml references as ${…​} stay in the root .env whichever service they configure. Compose interpolates the compose file from the shell environment and the project-directory .env only, so a published port moved into a per-service file would have silently fallen back to its default.

Drops .env.bak.mysql and .env.bak.oracle, untouched backups from 2026-04-09, and fixes the doubled scheme in NORTHBOUND_API_URL.

Deployment Manager reads this file from the tip of this branch to know the service’s image, ports, volumes, clustering pattern and the variables an operator must fill in. It was previously vendored in ft-internal-tools (deployment-manager/catalogue/contracts/provision-api.yaml); this repository now owns it.

These are the application config files a generated Compose bundle mounts into this service’s container. They were vendored in ft-internal-tools (deployment-manager/catalogue/services/); this repository now owns them, and Deployment Manager reads them from the tip of this branch.

Private key material is deliberately NOT here: keys and keystores stay in the one place they already live and are laid over this tree at generation time, so the same private key does not gain a copy per repository.