Uninstall is a placeholder — no privileged teardown

[malpern]

Tier: 2 (rough edge — incomplete critical flow)

From the pre-release feature-gap audit.

Problem

InstallerEngine.uninstall is a placeholder: it delegates to a legacy coordinator and returns failure if one isn't configured. The broker is "reserved for future privileged uninstall steps," so privileged cleanup (e.g., the VirtualHID driver, LaunchDaemon artifacts) is not implemented. Basic user-level uninstall works, but a clean teardown does not.

Evidence

• Sources/KeyPathInstallationWizard/Core/InstallerEngine.swift:604-617:

/// Execute uninstall via the existing coordinator (placeholder until uninstall recipes exist)
public func uninstall(deleteConfig: Bool, using broker: PrivilegeBroker) async -> InstallerReport {
    _ = broker // Reserved for future privileged uninstall steps
    ...
    guard let coordinator = WizardDependencies.createUninstallCoordinator?() else {
        return InstallerReport(success: false, failureReason: "Uninstall coordinator not configured")
    }

Impact

Uninstall may leave system artifacts behind; fails entirely if the coordinator isn't registered.

Suggested fix

Implement recipe-based uninstall including privileged steps via the broker, or document the current limitation clearly.

[malpern]

Validated — accurate, with a noteworthy nuance. Confirmed InstallerEngine.swift:604-617: _ = broker // Reserved for future privileged uninstall steps, delegates to WizardDependencies.createUninstallCoordinator?() and returns success: false, "Uninstall coordinator not configured" if unset. So the privileged-teardown gap is real. The user-facing uninstall path actually runs through UninstallKeyPathDialog.swift (which calls the coordinator and then NSApplication.shared.terminate) — worth tracing whether that path covers daemon/VHID cleanup before deciding how much of the InstallerEngine recipe work is release-blocking vs. deferrable.

---

Generated by Claude Code

[malpern]

Recommendation (Tier-2 triage — scope confirmation needed)

Traced both uninstall paths. The key finding: the user-facing uninstall is NOT broken — the InstallerEngine stub is a separate, unwired entry point.

What actually runs when a user uninstalls (UninstallKeyPathDialog → AppMenuCommands.swift:174 → UninstallCoordinator.uninstall()):

1. Unregisters SMAppService daemons first (UninstallCoordinator.swift:46)
2. Privileged-helper path (HelperService.performUninstallExceptSelfDestruct, :421-455): stops & unloads LaunchDaemons → removes daemon plists → removes system kanata binary → legacy config dir → logs → user data → app bundle
3. Script fallback with admin privileges if the helper isn't available (:96-133)

So privileged daemon/LaunchDaemon teardown is covered on the real path.

The gap in the issue (InstallerEngine.swift:604-617, _ = broker // Reserved for future privileged uninstall steps, returns success:false "Uninstall coordinator not configured" when the factory is unset) is a second, currently-unwired uninstall entry point on the Facade. It's not what users hit today.

One real nuance worth a decision: VHID driver teardown is a separate method (HelperService.uninstallVirtualHIDDrivers, :155) and does not appear in the standard uninstallKeyPath 7-step sequence (:421-455). So a normal uninstall leaves the Karabiner VirtualHID driver/daemon installed.

Recommendation — split into two, and only one is plausibly release-relevant:

• (A) Decide whether uninstall should also remove the VHID driver. Leaving it is arguably correct (it's a shared Karabiner component other tools may use), but if you want a clean removal, wire uninstallVirtualHIDDrivers() into the UninstallCoordinator flow (ideally opt-in: "Also remove the virtual keyboard driver"). This is the only part with user impact.
• (B) The InstallerEngine.uninstall() stub is a Facade-consistency / dead-code cleanup, not release-blocking — the working path bypasses it. Either wire it to delegate to UninstallCoordinator for a single source of truth, or remove the stub to avoid a misleading "success:false" surface.

Before I build anything, please confirm scope: (A) include VHID teardown? opt-in or always? and (B) wire vs. delete the InstallerEngine stub? I did not implement — this needs your call on what's release-blocking vs. deferrable.