# Compatibility

The backend uses Python 3 standard-library APIs only and degrades when battery telemetry, `/proc` fields, `powerprofilesctl`, or other optional interfaces are absent. The existing `scripts/power-audit`, `scripts/power-measure`, and `scripts/power-action` commands remain available for compatibility with earlier plugin users. `power-action inspect` remains a read-only probe; its legacy apply/rollback forms now refuse mutation so they cannot bypass the backend transaction model.

On Omarchy Quattro, `UPowerLive.qml` uses Quickshell's optional UPower singleton. It is loaded through `Loader`, so a missing module or device leaves the bar on its explicit-backend fallback rather than starting a polling daemon. UPower supplies live presentation; sysfs remains the diagnostic source. Power Profile state remains backend-authoritative because Quickshell exposes no positive daemon-connection signal.

The plugin follows the installed first-party `service` + `bar-widget` contract
with `Service.qml`, `BarWidget.qml`, and `keepLoaded: true`. The widget uses the
injected service or `bar.shell.serviceFor("oma.juicemaxx")` and otherwise falls
back to one fixed-argv local process per explicit operation for older hosts. Agent results
use a watched local marker plus a manual single-check fallback; there is no backend
poller. If an older host still reports a service-loader filename
case error, remove the service kind locally and use the documented fallback;
that host limitation is not treated as successful service loading.

The UPower component is optional and lazily loaded. Hosts without
`Quickshell.Services.UPower` continue to use the explicit backend fallback for
diagnostics; no import failure is allowed to disable the widget. UPower's
`percentage`, `state`, and `changeRate` are presentation-only live hints. The
Power Profiles enum is not used for live UI state: its default can be `Balanced`
before the daemon connects, so the UI relies on the last explicit backend
result and shows unknown when unavailable. Direct `/sys/class/power_supply` remains the
diagnostic source. Assistant completion uses a local `FileView` marker with a
manual Check fallback, so there is no second backend poller.