Resetting a Failed Installed-Conformance Attempt

This procedure resets the known Linux server no-go caused by a stale 0.3.14 server lifecycle publication. It preserves the failed candidate and sanitized evidence, removes the partial AHRI-TRE installation, activates the corrected candidate, and leaves Secret preparation to the existing preparation wizard. Neither wizard installs package files or invokes the conformance harness.

Use this procedure only for this exact failed attempt:

• failed candidate SHA-256: b39afb3b5457258e69dd571bb1514543c1a5f3af09303930ce7a1a2834041f1e;
• corrected candidate SHA-256: 2caf994b9cf3d72d4eacd4a6fdeb859440481d2a6fb4cd3f02a3437a84e6a1cd;
• fixed 0.3.12 predecessor SHA-256: 6f5555c25d96274d7772d1b46d4409bd36a42205f21c4c715de8df5179ab18ed;
• MinisForum host svrltreapcc02 at 192.168.31.75; and
• Deployment f2ef37c5-7430-468a-a439-b3ba1b0527c1, Datastore ahri-tre-test.

The failed and corrected archives have the same filename and kit version. The SHA-256 value, not the filename, identifies their immutable contents.

What is kept and what is reset

The incomplete predecessor directory is moved into the protected failed-attempt record rather than deleted. The failed public archive, checksum, and extracted public packages are also retired. Secret values are not copied into evidence.

Prerequisites

Run from the repository root in the ordinary WSL2 Ubuntu shell, not inside the development container. The repository must contain the executable reset and preparation wizards.

The corrected candidate pair must exist at:

dist/conformance-candidate-retry-output-0.3.14/
├── ahri-tre-test-datastore-deployment-kit-0.3.14.tar.gz
└── ahri-tre-test-datastore-deployment-kit-0.3.14.tar.gz.sha256

Verify it before connecting to the server:

cd /home/kobus/repos/ahri-tre-rs

cd dist/conformance-candidate-retry-output-0.3.14
sha256sum --check --strict \
  ahri-tre-test-datastore-deployment-kit-0.3.14.tar.gz.sha256
cd /home/kobus/repos/ahri-tre-rs

The result must be OK, and the archive digest must be the corrected digest shown above. Stop if the corrected pair is missing or differs.

The MinisForum must be reachable as sysadmin@192.168.31.75. Password prompts from ssh and remote sudo belong to sysadmin on the MinisForum. Local sudo prompts belong to the WSL2 account.

Step 1: preserve and reset the known no-go

Start the dedicated wizard:

cd /home/kobus/repos/ahri-tre-rs
./scripts/reset-failed-installed-conformance-wizard.sh

The wizard performs seven guarded stages:

1. It verifies WSL2, the required tools, and the fixed corrected archive and checksum.
2. It extracts the corrected archive into a protected temporary directory, verifies every internal checksum, checks the exact current server lifecycle, and confirms that the embedded harness and lifecycle share committed source.
3. It obtains the sanitized linux-server.json, verifies outcome=no-go and failed_stage=server.upgrade, and preserves it locally before cleanup.
4. After an explicit confirmation, it verifies the installed uninstaller against the failed archive, runs it, retires the incomplete predecessor and failed public inputs, and removes only the generated AHRI-TRE attempt state.
5. It moves the failed local archive and checksum into the protected retirement directory, activates the corrected pair, and destroys the failed root identity backup so that it cannot be reused.
6. It proves the host is again a clean foundation and displays UFW state for human review.
7. It stops at RESET READY and names the Secret-preparation command. It does not continue into conformance.

At the firewall prompt, approve only this retained policy:

• active UFW;
• default deny incoming;
• default allow outgoing;
• SSH allowed;
• TCP 443 allowed to 192.168.31.75 from 192.168.31.0/24; and
• TCP 5432 denied.

The failed local record is stored under:

/home/kobus/ahri-tre-conformance/retired/no-go-b39afb3b5457258e69dd571bb1514543c1a5f3af09303930ce7a1a2834041f1e/

The protected server-side record is stored under:

/var/backups/ahri-tre/failed-installed-conformance/b39afb3b5457258e69dd571bb1514543c1a5f3af09303930ce7a1a2834041f1e/

If the wizard is interrupted, run the same command again. Its guards recognize already-retired evidence, public inputs, and candidate files. Do not manually invent package-SHA256SUMS, delete evidence, or copy the corrected archive over an unverified active archive.

Step 2: create entirely fresh candidate-matching Secrets

After the reset wizard reports RESET READY, run:

cd /home/kobus/repos/ahri-tre-rs
./scripts/minisforum-conformance-preparation-wizard.sh

The preparation wizard re-verifies the corrected active archive and the fixed predecessor; transfers those exact public inputs; creates fresh PostgreSQL TLS, password, Runtime, OIDC, and Deployment root-identity projections; writes a new protected WSL2 root-identity backup; and proves the resulting permissions and candidate bindings.

The corrected candidate is already active at:

/home/kobus/ahri-tre-conformance/input/ahri-tre-test-datastore-deployment-kit-0.3.14.tar.gz
/home/kobus/ahri-tre-conformance/input/ahri-tre-test-datastore-deployment-kit-0.3.14.tar.gz.sha256

The fixed predecessor remains at the same input location. Do not substitute a different predecessor or regenerate it.

Enter the ORCID client Secret only when the preparation wizard requests it. The value is read without echo and transferred directly to a protected remote file; it is not stored in the repository or local .env file.

Required stopping boundary

Stop when the preparation wizard prints:

HOST READY
The conformance harness has not been invoked.
Press Enter to finish at the host-ready boundary.

Do not install package files by hand, do not run an individual package installer, and do not invoke the conformance harness as part of this reset and preparation procedure. The verified /run/secrets projections are ephemeral; do not reboot after HOST READY and before the later conformance run.