# Milestone 15 evidence: diagnosable systemd restart

Validated 2026-10-27T22:19:58+02:00 on the native
`x86_64-unknown-linux-gnu` development host. All behavioral checks below use
synthetic fixtures or fake service/unit APIs. No system D-Bus or host service
was invoked.

## Cause, change, and limits

The source-level diagnostic loss was confirmed: `Application` mapped every
unsuccessful service outcome to `ServiceFailed`. The report now retains the
typed `RestartFailure`, an explicit operation phase, and the configured unit;
the terminal renders a readable category and phase with the unit escaped for
terminal safety. Raw D-Bus error messages and service output are not included.

The [official systemd Manager D-Bus API](https://freedesktop.org/software/systemd/man/latest/org.freedesktop.systemd1.html)
confirms `GetUnit` fails if the named unit has not yet been loaded and `LoadUnit`
loads it from disk if possible. The previous adapter called `GetUnit`; it now
calls `LoadUnit`, requires `LoadState == loaded`, and reads canonical `Id` for
job-event matching while requesting restart with the configured name. This is
a confirmed API mismatch for existing unloaded units, but its role in the
user's specific host failure is a hypothesis until a disposable-VM run provides
real systemd/D-Bus evidence. Missing or nonloaded units stop at resolution.

The preexisting service adapter could understate uncertainty if the manager
owner changed during a pending restart request. That path now reports possible
submission, possible later completion and manual recovery. Synthetic tests
cover connection, subscription, permission, resolution, request and job
failures; alias identity; unloaded and missing unit load flows; and readable
TUI status for every typed failure. They also assert failure does not mark the
state applied. Existing tests cover mandatory backup, confirmation, generation,
complete runtime match, and durable applied-state boundaries. No shell restart
path was introduced.

Independent GPT-6-Luna/high review found M15-R1 (P2, request owner-change
uncertainty) and M15-R2 (P2, unloaded-unit adapter test gap). A separate
GPT-6-Luna/high repairer addressed both. The reviewer rechecked the actual
repair and closed both findings with no further scoped issue.

## Commands and source identity

Pinned `rustc`/Cargo 1.97.1, rustfmt 1.9.0 and Clippy 0.1.97 were verified.
Commands ran from the repository root on the repaired revision:

- `cargo test --locked service::dbus::tests::`: 13 passed.
- `cargo test --locked app::tests::application_report_preserves_every_service_failure_and_operation_phase`: 1 passed.
- `cargo fmt --all -- --check`: exit 0.
- `cargo clippy --locked --all-targets -- -D warnings`: exit 0.
- `cargo test --locked`: 364 passed, 3 explicitly ignored, 0 failed, including 2 documentation tests. The selected Docker daemon test was not run.
- `cargo build --locked --release`: exit 0.
- `git diff --check`: exit 0.

Base commit: `86c28a35b559f70cb08365a7cdf0d5961e5570ea`. Dirty Rust inputs
at validation and their SHA256 values:

- `src/service.rs`: `83a6089a4db019918178d7d97346e104180d63eb3ccc8a025bda91939720e02e`
- `src/service/dbus.rs`: `79ebc8c91db6dd08163ee0a6484359c2a8e7623e33081c9088c4d97d507d1816`
- `src/app.rs`: `2c3f6822a48dd5ec92faad9fbfd05a5be8723057d23aaba7f92e7899891cbefb`
- `src/tui/terminal.rs`: `48835132a30b1d5243a6076abfe06f6e98fb9419b0c4433c540406767715bae3`
- `src/container_driver.rs`: `9f6b27bff93d4face72ef8980a5d8e2db418bdb079c501a885d2c419fcfd6964`

Native release artifact `target/release/wireguard-admin` SHA256:
`18dd2ce2dcc9f93272440d45491b5f83da82a7b9ed392986a8eaf059b76bf593`.

No Alpine rerun, disposable systemd VM, or production operation was performed.
The actual systemd/D-Bus acceptance required by M9 remains incomplete and
unclaimed. An operator can now use the specific safe category and phase to
distinguish a unit-resolution problem from connection, subscription, access,
request, or job failure without exposing raw service details.