wireguard-admin/docs/evidence/milestone-15.md

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 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.