# Consecutive failed releases (WJ-022)

The real-H2 rollback harness accepts `--failures 2`. It stages two distinct
candidate manifests B and C descending from known-good A. Each candidate
contains an additional Liquibase migration that persists a schema change and
then fails. The real deployment implementation must restore A and its fresh
database snapshot after each failure.

An identifiable work entry is inserted after A first becomes ready. After B
has failed and A is restored, the fixture writes another entry before C is
deployed. Both entries must survive C's rollback. This detects accidental reuse
of B's older snapshot as well as publication of either failed candidate.

Every round independently verifies partial migration, process termination,
restored database checksums, the selected executable and deployed manifest,
schema and migration history, and maintenance until readiness. The resulting
report contains a separate record for each candidate and restored commit.
The unchanged local service/HTTP boundaries and notification isolation are
described in `migration-rollback-acceptance.md`.

WJ-022 runs in `productionAcceptance` alongside WJ-020 and WJ-021. Its report is
`build/reports/production/two-failures.json`; its JVM logs are in the sibling
`two-failures-logs` directory, separate from the WJ-021 logs.

Verification: the standalone two-failure probe passed, then all three
production Gherkin scenarios / 16 steps passed together on 0.1.81-SNAPSHOT in
2m 18.682s. The targeted Gradle invocation excluded the already-tested JVM
suite; the normal CI pipeline retains that mandatory stage. The completion
push increments the version to 0.1.82-SNAPSHOT. CI verification of WJ-022 is
pending.