## Summary

`omarchy-powerprofiles-set` fails with exit code 1 on every AC-detection udev event during boot, so the CPU power profile is never applied on AC. The system stays on whatever profile power-profiles-daemon defaulted to (e.g. `power-saver` from a battery session), so the CPU is throttled even while plugged in.

## Environment

- Omarchy 4.0.0-1 (package; `/usr/share/omarchy/version` reports `4.0.0.alpha`)
- power-profiles-daemon 0.30-1
- Kernel 7.1.8-arch1-3
- CPU: 11th Gen Intel Core i7-11800H (Acer Nitro)
- Last package update: Aug 21 2026

## Symptoms

- `journalctl` shows the udev-driven profile setter failing with exit code 1 at every AC event during boot.
- `powerprofilesctl get` does not show the intended AC profile (`performance`) after boot.

## Evidence

Journal (today, 3 boots):

```
Aug 25 11:01:56 acer-nitro (udev-worker)[770]: ACAD: Process '/usr/bin/systemd-run --no-block --collect --unit=omarchy-power-profile --property=After=power-profiles-daemon.service /home/abhay/.local/share/omarchy/bin/omarchy-powerprofiles-set' failed with exit code 1.
Aug 25 11:01:57 acer-nitro (udev-worker)[758]: ucsi-source-psy-USBC000:001: Process '/usr/bin/systemd-run --no-block --collect --unit=omarchy-power-profile --property=After=power-profiles-daemon.service /home/abhay/.local/share/omarchy/bin/omarchy-powerprofiles-set' failed with exit code 1.
Aug 25 11:02:01 acer-nitro systemd[1]: Starting Power Profiles daemon...
Aug 25 12:27:52 acer-nitro (udev-worker)[774]: ACAD: Process '...omarchy-powerprofiles-set' failed with exit code 1.
Aug 25 13:11:44 acer-nitro (udev-worker)[760]: ACAD: Process '...omarchy-powerprofiles-set' failed with exit code 1.
```

Note the ordering: the udev event fires (11:01:56) *before* power-profiles-daemon starts (11:02:01), so `powerprofilesctl set` fails because the daemon isn't up.

## Root cause

`/etc/udev/rules.d/99-power-profile.rules`:

```
SUBSYSTEM=="power_supply", ATTR{type}=="Mains", RUN+="/usr/bin/systemd-run --no-block --collect --unit=omarchy-power-profile --property=After=power-profiles-daemon.service /home/abhay/.local/share/omarchy/bin/omarchy-powerprofiles-set"
```

- `systemd-run --no-block` does not wait for the transient unit; the `After=power-profiles-daemon.service` ordering only applies when both units are part of the same transaction, which is not guaranteed here because udev fires the RUN program directly and the daemon may not be started yet at boot.
- Result: the script races the daemon and loses; `powerprofilesctl set` exits 1; the AC profile (default `performance`) is never applied.
- User state confirms the asymmetry: `~/.local/state/omarchy/powerprofiles/` contains only `battery: power-saver` (no `ac` file), so on AC the intended profile comes from the default fallback in the script — which is never reached when the daemon is down.

## Expected behavior

The AC/battery power profile should be applied reliably on every power-source event, including during boot, even if power-profiles-daemon starts after the udev event.

## Suggested fix directions

- Drop `--no-block` (or add `--wait`) so the ordering actually synchronizes, or
- Have the script itself wait/retry for the daemon (e.g. loop on `powerprofilesctl` or `busctl` up to N seconds), or
- Trigger the setter from a systemd service with proper `After=power-profiles-daemon.service` / `Requires=` ordering instead of a udev RUN program.

## Steps to reproduce

1. On battery, let the profile settle to `power-saver` (state file written).
2. Reboot while unplugged, then plug in AC (or reboot with AC attached).
3. Observe `journalctl --since boot | grep omarchy-powerprofiles-set` → exit code 1.
4. `powerprofilesctl get` will not show the AC profile (`performance`).

## Impact

The CPU profile is not switched to `performance` on AC as intended, so the CPU stays throttled (e.g. in `power-saver`) while plugged in. This is a functional bug in profile application; the performance impact on this machine was CPU-level only.

### Note (out of scope for this bug)

Initial investigation surfaced a concurrent symptom — slow HDD writes (~12 MB/s) on this machine — which was initially assumed to be related. It was subsequently determined to be independent: power-profiles-daemon on this system manages only the CPU (no disk/APM handling), and the drive's aggressive head parking is a firmware characteristic (WD IntelliPark, 63k load cycles over 11k power-on hours). That is a drive-firmware matter, not an Omarchy bug.