# Milestone 8 diagnostic record

This is a development investigation record for disposable Alpine fixtures. It
contains no production observations or secret fixture payloads. Current task
state and acceptance remain in [PLANS.md](../../PLANS.md).

## M8.5 restore fixture reservation mismatch

- Recorded: 2026-10-24T23:04:57+03:00.
- Symptom: the second password-free restore confirmed through `Application`,
  but its test driver failed a saved-state assertion. The first restore,
  explicit fixture Apply and renewed IPv4 traffic had already passed.
- Bounded reproduction: pinned musl driver built with
  `cargo test --locked --offline --lib --no-run --target x86_64-unknown-linux-musl`
  in the approved Rust Alpine builder; selected-daemon ignored test invoked as
  `cargo test --locked --test testcontainers_wireguard selected_daemon_wireguard_and_application_smoke -- --ignored --exact --test-threads=1`
  with the explicitly selected local Docker daemon and musl driver path.
- Discriminating observations: fixed redacted phase markers reached
  `application_confirmed` and `precautionary_contents_verified`. Settings,
  server bytes, vault bytes and target-client presence matched. The actual
  reservation count was two, the fixture expected one, and both contained the
  target IPv4 address.
- Cause: the fixture expected only the target IPv4 reservation when restoring
  an archive that removed a saved client with more than one address. Application
  retained both saved addresses as required while the live peer remained.
- Repair: derive the exact expected reservation set from every address on the
  removed saved client, preserve prior reservations, and filter addresses still
  saved in the restored set. Keep the IPv4 target membership assertion. This is
  saved-state bookkeeping; no IPv6 capability or traffic test was run.
- Verification: focused reservation-helper regression passed; rebuilt pinned
  musl driver; selected-daemon scenario passed 1/1 in 72.66s, including both
  restores and explicit applies. Exact-name test containers and network were
  absent afterward. Independent code review found no implementation defect;
  its plan-status finding closed on re-review. Final integrated gates remain.

Earlier failed diagnostic runs and superseded status are preserved in
[the pre-cleanup record](../history/milestone-8-before-workflow-cleanup.md).

## M8.7 transient execution prerequisites

- Recorded: 2026-10-25T20:40:51+03:00. The first post-review opt-in run failed
  before scenario startup because the sandbox denied Docker API access.
  Running the selected-daemon command with approved sandbox escalation then
  failed prerequisite inspection because the musl driver artifact under `/tmp`
  was absent. Exact-name test container/network listings were empty.
- A pinned builder rebuild with an empty `/tmp` Cargo cache and `--offline`
  failed dependency resolution for the already-approved `age` crate. The host's
  cached public Cargo registry contained it. Mounting that cache read-only into
  the pinned builder produced the same driver SHA256 as the prior passing run;
  no dependency or source change was needed.
- Three subsequent selected-daemon runs passed with fresh mutable fixtures.
  Their exact commands, source fingerprint, outcomes, and limits are recorded
  in [the evidence report](../evidence/milestone-8.md). These initial
  prerequisite failures are not counted as scenario passes.

## M8.5 failure fixture legacy-peer deletion

- Recorded: 2026-10-24T23:27:52+03:00.
- Symptom: the selected-daemon scenario passed real reader `NoDevice`/`Timeout`
  and deterministic Commit backup-failure checks, then stopped before restart
  backup-failure assertions.
- Bounded check: fixed secret-free driver markers localized the stop after
  parsing the baseline client's identity and before deletion completion. The
  selected-daemon command is the one recorded in
  [the evidence report](../evidence/milestone-8.md), with the current pinned
  musl driver rebuilt for each diagnostic revision.
- Cause: the fixture treated `Application::delete_client`'s Boolean as whether
  the peer was removed. It reports whether an encrypted vault record was
  removed. The synthetic legacy baseline peer had no such record, so `false`
  was correct even though the draft peer was deleted.
- Repair: assert the baseline identity is absent from the draft after deletion
  and report the vault-record outcome separately. A focused regression covers
  deletion of a legacy peer with no vault record.
- Verification: focused regression, formatting and Clippy passed; source
  fingerprint `656707eac2af28f2f3747687e73bb355c4df421663c142d4a7e91409763179b0`
  remained stable through a pinned musl build and selected-daemon run. That
  run passed 1/1 in 81.14s; exact-name containers and network were absent.
  Independent review and final integrated gates are still pending.