# One `komorebi`, one `komorebic`, one `komorebi-bar`

> **Status (the cutover stack, `wip-cutover`):** steps 0-8 done: one `komorebi` (`komorebi-daemon/`), `komorebic`, `komorebi-client` and `komorebi-bar` package, platform by `cfg(target_os)`; the cutover (shim packages deleted, final directories, one version 0.2.0) is done too; the one flake, CI and releases are open (see "What is left for the cutover" at the end). The older sections below are history and keep the names and paths of their time (`komorebic-linux`, `komorebi-for-kde/`, `komorebi-for-mac/`, `version-linux`, the versions 0.1.42 / 0.1.0 / 0.1.1, `kfde-*`/`kfm-*` flake attributes): in particular the note "never write `-p komorebi`" was true before step 8 and is wrong now; see [build-and-test.md](build-and-test.md) for current commands. Where the old directories were: `komorebi/` is now `komorebi-windows/`, `komorebi-for-kde/komorebi/` is `komorebi-linux/`, `komorebi-for-mac/komorebi/` is `komorebi-macos/`, the KDE and macOS docs, nix files and scripts are under `docs/`, `nix/` and `scripts/` in `linux/` and `macos/` subdirectories, and the schemas are in `schemas/{windows,linux,macos}/`.

Goal: three packages and three binaries that build on Windows, KDE (Linux) and macOS, the platform
chosen by `cfg(target_os)` (generics, `cfg_select!`, exhaustive `match`; no macros as a design tool).
This file records a spike (throwaway revisions on bookmark `wip-u-pkg-spike`, titled `spike:`; nothing
landed on `wip-main`), the layout it recommends, the migration order, the risks and the gates.

Measured on `wip-main` 633e7453 with the light gates only (`nice -n 19`, 3 jobs, persistent target
dirs, `COMMIT_HASH=dev`); no nix build, no e2e, no VM. macOS is type-checked with the fake CC only: it
was never linked or run.

## What the spike did

1. `spike: one root workspace ...` (rev `yuuyzssl`): the 10 KDE and macOS member crates became members
   of the root workspace. Their two `[workspace]` manifests were deleted, their `workspace = true`
   dependencies were written out, packages renamed (`komorebi-linux`, `komorebic-linux`,
   `komorebi-client-linux`, `komorebi-hotkeys-linux`, `version-linux`, and `-macos` for the macOS
   ones including `komorebi-bar-macos`); binary and lib names stayed (`[lib] name`, `[[bin]] name`) so
   no source file changed. One `Cargo.lock`.
2. `spike: unified komorebic package by #[path] includes`: the root `komorebic` package became the
   unified one. `src/main.rs` is a `cfg_select!` over `target_os` that includes the old Windows
   `main.rs` (moved to `windows.rs`) and, by `#[path]`, the KDE and macOS `main.rs` where they live.
   Dependencies are in `[target.'cfg(...)'.dependencies]` tables. Edits to the old files: `fn main`
   became `pub fn main`; `crate::HOME_DIR` became `super::HOME_DIR` in KDE `hotkeys.rs`.
3. `spike: target-gate the macOS daemon crate`: objc2 and friends under
   `[target.'cfg(target_os = "macos")'.dependencies]` plus `#![cfg(target_os = "macos")]` in
   `komorebi-macos`, to test `cargo check --workspace` on a foreign target.

The script that did step 1 is `S/pkg-spike.py` (scratchpad; rerunnable on a fresh `wip-main`).

## Results

| question | result |
|---|---|
| One lock resolves? | Yes. 859 packages (root) -> 900. All 859 Windows entries unchanged. The KDE lock had 644 and the macOS lock 786 entries, so +41 only. Crates with more than one version: 81 -> 95 (the `sysinfo` 0.38/0.39/0.40, `dirs` 6/7, `parking_lot` 0.12/0.13, `shadow-rs` 1/2, `netdev` 0.40/0.46 splits coexist; nothing needs unifying). |
| Locked versions kept? | Not exactly: crates that only KDE or macOS use were re-resolved to newest: `zbus`/`zbus_macros` 6.1 -> 6.2, `zbus_utils`, `zruntime`, `sysinfo` 0.40.0 -> 0.40.1, `libz-sys`, `unicode-width`. Pin with `cargo update zbus@6.2.0 --precise 6.1.0` (needs the `name@version` spelling) if the VM suites must see the old versions. |
| Windows `cargo check -p komorebic --target x86_64-pc-windows-msvc` (nix develop) | passes, 14.8 s wall warm (11.2 s compile); unified `komorebic` also passes, 7 s. |
| KDE native `cargo check -p komorebi-linux -p komorebic-linux` | passes; 1 m 38 s cold into a fresh lite target dir. Unified `komorebic` on Linux passes (1.4 s after touch) when openssl is available (see risk 2). |
| KDE tests unchanged | `cargo test -p komorebi-linux --lib`: 294 passed. `--test schemas -- --test-threads=1`: 5 passed. All four KDE packages, `--no-fail-fast`, 1 m 26 s warm: 879 passed, 1 failed. The failure is `tests/version.rs`: `komorebi-linux 0.1.0` instead of `komorebi 0.1.0` (clap takes the command name from `CARGO_PKG_NAME`); a renamed package needs `#[command(name = "komorebi")]`. Nothing else depends on the package name. |
| macOS fake-CC `cargo check --target aarch64-apple-darwin -p komorebi-macos -p komorebic-macos -p komorebi-bar-macos --all-targets --locked` | passes, 32 s warm (6 warnings in the bar, as before). Unified `komorebic` on macOS passes, 12 s. Type-check only. |
| Feature unification | Resolver 2 keeps `komorebi-layouts/darwin` off Windows: `cargo tree -p komorebic --target x86_64-pc-windows-msvc -e features -i komorebi-layouts` shows only `default`, the macOS package shows `darwin`. This holds only while the package that asks for `darwin` is not in the same build; `cargo ... --workspace` on one target selects them all (see risk 3). |
| `cargo check --workspace` for Windows (what clippy, fmt, nextest and crane do today) | FAILS in 52 s: `objc2 only works on Apple platforms`. With objc2 target-gated and `#![cfg(target_os = "macos")]`, `komorebi-macos` compiles empty on Windows (spike 3), so the fix is to gate every foreign-platform crate, not to exclude them. Done for one crate only. |
| Same dependency key, different path per target | REJECTED by cargo: `Dependency 'komorebi-client' has different source paths depending on the build target`. Same for `version`. So the unified package must use one key per platform (`komorebi-client-linux`, `komorebi-client-macos`, ...) and the platform module must alias it (`extern crate komorebi_client_linux as komorebi_client;` at the root, or `use komorebi_linux as komorebi;` at the top of each platform module). The spike used `extern crate`. |
| Compile time | No extra cost on a target: a build selects its own target's dependency tables, so Windows never sees zbus or objc2 and Linux never sees `windows`. The only added cost is resolution (`cargo metadata` 6.5 s with the network). |

## Option A or B

Measured size of what would have to move into `#[cfg(target_os)] mod` of one crate (Option B):
daemon `crate::` paths: Windows 669, KDE 447, macOS 587 (35,149 / 32,932 / 34,505 lines, 3 lib+bin
crates each with their own tests and a `komorebi-client` that re-exports them); bar 111 / 90 (7,710 /
5,551 lines); `komorebic` 0 (1,467 / 807 / 1,537 lines).

Recommendation:

- `komorebic`: B. One package `komorebic`, `src/main.rs` = `cfg_select!` choosing `mod windows`,
  `mod linux`, `mod macos` (each the present `main.rs`, `hotkeys.rs` for Linux), one clap command name,
  target-gated dependencies. Zero `crate::` rewrites, so the files move whole. This is what the spike
  built (with `#[path]` instead of the final moves).
- `komorebi-bar`: B, as `bar-unification.md` already plans (`src/bar/{mod,windows,macos}.rs`,
  `os/{windows,macos}.rs`); needs the bar stack integrated first.
- `komorebi` (daemon): A. Keep three library crates, rename to `komorebi-windows`, `komorebi-linux`,
  `komorebi-macos` (distinct lib names, `komorebi_windows` etc.), each gated to its OS
  (`#![cfg(target_os = ...)]`, target-gated dependencies, so `--workspace` works everywhere), each
  keeping its own `crate::` paths and its own tests (KDE's 881 run unchanged but for the name). One
  thin `komorebi` binary package: `src/main.rs` is a `cfg_select!` over the three daemons'
  `main` bodies (each daemon's present `main.rs` becomes `pub fn run()` of its library). Option B for
  the daemon would be a rewrite of about 1,700 `crate::` paths (669 + 447 + 587) for no behavioural gain, and it would
  put KDE's tests and the VM suites on a moving target.
- `komorebi-client`: one package with `src/{windows,linux,macos}.rs` (211 / 394 / 225 lines, almost all
  `pub use komorebi::...`), each starting with `use komorebi_windows as komorebi;` and so on.

## Migration order

Every revision keeps the three existing trees building with their present gates. "Gate" says what
must pass before it counts as landed: `C` compile (fast-check, the three checks), `S` the CLI oracle
(`S/step4/oracle-check.sh`, byte-identical for all three platforms; it reads `komorebic/src/main.rs`
of each tree, so it needs its paths updated in the revision that moves a file), `N` nix evaluation
(`nix flake show`), `NB` a nix build of the checks in an idle window, `E` Windows e2e, `V` KDE VM `fast`.

0. Prerequisites, no moves (any time, small): explicit `#[command(name = ...)]` on the three CLIs;
   `build.rs` of `komorebic` stops fetching `applications.json` over the network (the file is checked
   in; a build script that needs `reqwest`, and so openssl, on Linux is what stopped the unified
   package building natively); `pub fn main` and `crate::` -> `super::` in the `komorebic` files.
   Gates C, S. Not behaviour.
1. Package renames inside the present workspaces (KDE: `komorebi-linux` and so on; macOS the same;
   Windows daemon `komorebi-windows` last), with `[lib] name` and `[[bin]] name` unchanged. Gates C,
   N; the Windows daemon rename is `E` (the executable's inputs change).
2. Workspace merge: delete `komorebi-for-kde/Cargo.toml` and `komorebi-for-mac/Cargo.toml`, add their
   crates to the root members, write out the inherited dependencies, one lock (+41 packages), add
   `.cargo/config.toml` with `[env] COMMIT_HASH` (KDE's file moves from `komorebi-for-kde/.cargo`;
   cargo reads it from the working directory upward only). Same revision gates every foreign crate
   (`#![cfg(target_os)]`, target-gated dependencies) so `--workspace` works on all targets. Gates C on
   all three, plus KDE tests unchanged. Cargo-wise this is one revision (the spike's script); it must
   not be split without breaking `--locked`.
3. Flakes, same integration as 2 (nix cannot be half-merged): the root flake builds all three; the two
   nested flakes already take the whole repository as their source (`lib.mkOutputs`), so they become
   thin: `workspaceArgs` change from a subdirectory workspace to `-p <package>`. The KDE source filter
   must list the new member directories. Gates N, then `NB` (deps, clippy, nextest of each system),
   then `V`.
4. `komorebic` unified by `#[path]` (spike 2, minus the hacks): new `komorebic/src/main.rs`, target
   tables, aliases. The old `komorebic-linux`/`-macos` packages stay until step 5 so the old names
   work. Gates C, S, and `E` for `komorebic.exe` (the Windows main moves to `windows.rs`).
5. `komorebic` real moves, one platform per revision: `komorebi-for-kde/komorebic/src/*` to
   `komorebic/src/linux/`, the macOS one to `komorebic/src/macos/`, tests with them, then delete the old
   packages. Pure moves (jj does not follow moves, so each is a delete/modify conflict if another stack
   touches those files; today none does). Gates C, S, tests.
6. `komorebi-client` unified (modules per platform), same pattern. Gates C, E (Windows client is in the
   closure of `komorebi.exe`).
7. `komorebi-bar` unified after the bar stack integrates: `bar-unification.md` plan; Windows bar
   screenshot gate and the Mac hand check are owed by that stack.
8. Daemon: three libraries gated to their OS and one thin `komorebi` package with the `cfg_select!`
   `main`. KDE `main.rs` and the Windows `main.rs` become `run()` in their libraries. Gates C, `E`, `V`,
   Mac hand check.
9. Cutover: one flake output per binary, old per-platform package names, `justfile`, CI
   (`.github/workflows`), docs paths, release version (0.1.42 / 0.1.0 / 0.1.1 become one).

## Risks

1. One lock for three platforms: a `cargo update` for one platform moves the others; crane's dummy
   source includes every member's manifest and the lock, so any dependency change rebuilds the
   dependency derivation of all three systems (today a KDE-only lock change cannot touch Windows). The
   `COMMIT_HASH`-constant fix (flow finding 1) must be in first or every commit rebuilds ~1,000 crates.
2. `build.rs` fetching over the network is not usable in a unified package (openssl on Linux); see step 0.
3. `--workspace` commands (clippy, fmt, nextest, crane) select every member on every target: every
   foreign crate must compile empty (spike 3 shows it works for the daemon; only one crate was
   converted). Without it, feature unification would also turn `komorebi-layouts/darwin` on for
   Windows in a whole-workspace build.
4. The one-key-one-path rule forces distinct dependency keys and aliases per platform module.
5. `CARGO_BUILD_TARGET` is set by the root `nix develop` shell, so native Linux checks must run outside it
   (as `fast-check` does) or pass `--target x86_64-unknown-linux-gnu`.
6. Command names and `--version` text come from `CARGO_PKG_NAME`/the version crate: pin them or the KDE
   `version` test and the docs oracle change. `shadow-rs` major versions differ (2 on Windows, 1 on
   macOS); the unified `komorebic` build script can only use one.
7. The KDE VM suites rebuild on any change to the KDE closure: the merge is one full `V` run.
8. Tests that use `CARGO_BIN_EXE_*` or relative paths (`tests/schemas.rs` writes beside the manifest)
   must move with their package; not exercised beyond the spike.

## Gates by step, in short

Compile only: 0, 4 (but see `E`), 5, 6 at the Rust level; nix evaluation only: 3 until built. Needs
e2e (Windows guest): anything that changes an input of `komorebi.exe`, `komorebic.exe` or the client
(`tools/e2e-needed` says: 1 for the Windows daemon, 4, 6, 8). Needs the KDE VM: 2, 3, 8. Needs a Mac,
by hand: 4, 7, 8, 9.

Mac hand check (type-check proves none of it): `komorebic --version` and `--help` show the macOS
command set and the name `komorebic`; `komorebic start` finds and starts `komorebi`, `stop` stops it;
`komorebic docgen` unchanged; `komorebi --version`; the daemon starts, tiles and `komorebic state`
answers; `komorebi-bar` opens, `--schema` equals `komorebi-for-mac/schema.bar.json` [now `schemas/macos/schema.bar.json`];
the embedded `applications.json` is the macOS one;
`otool -L` of each binary lists no Windows or Linux-only library.

## Conflicts with the open stacks (sequence in a quiet period)

Paths touched by each bookmark relative to `wip-main`:

| bookmark | touches | moves in this plan that conflict |
|---|---|---|
| wip-u-kfw | `komorebi/src/**`, `crates/komorebi-backend/**` | daemon rename and any move of `komorebi/` (steps 1 Windows, 8) |
| wip-u-kfm | `komorebi-for-mac/komorebi/src/**`, `crates/komorebi-backend/**` | macOS daemon rename and moves (1, 8) |
| wip-u-kfde | `komorebi-for-kde/komorebi/{src,tests}/**` | KDE daemon rename (1) and moves (8); tests are edited |
| wip-u-bar | `Cargo.lock`, `komorebi-for-mac/Cargo.lock`, `komorebi-bar/src/**`, `komorebi-for-mac/komorebi-bar/src/**`, `crates/komorebi-bar-core` | step 2 (locks, manifests) and step 7 |
| wip-u-settings | `Cargo.toml`, `Cargo.lock`, `crates/komorebi-settings` | step 2 (root manifest and lock) |
| wip-u-nix | `flake.nix`, `komorebi-for-kde/flake.nix`, `komorebi-for-kde/nix/**` | step 3 |

Not touched by any open stack, so safe now: `komorebic/**` (all three), the `komorebic` tests, the
`version` crates, the `komorebi-client` crates (steps 0, 4, 5, 6 are free of conflicts except the lock
and root manifest lines of step 2/4). Hard conflicts: every `Cargo.lock` and the root `Cargo.toml`
`members` list (resolve by taking one side and running `cargo metadata`; never hand-merge a lock),
`flake.nix` lines for the extracted binaries. Suggested order: integrate kfw, kfm, kfde, bar, settings,
nix first; then steps 0 and 1; then 2 and 3 as one integration; the rest in any order, daemon (8)
last.

## What landed

Only this file. The spike revisions are on `wip-u-pkg-spike` and can be dropped or cherry-picked.
Step 0 and the renames were not landed because they only pay off with step 2, which edits the locks
and manifests that three open stacks edit.

## State of the migration (bookmark wip-u-pkg-mig, on wip-u-pkg-base)

Done, in this order (each revision keeps the three trees building; gates are in the revision messages):

0. `applications.json` committed (build.rs fetch gone), explicit clap names, the KDE closure list fixed.
1. KDE and macOS packages suffixed (`komorebi-linux`, `komorebic-macos`, ...); Windows daemon `komorebi-windows`.
2. One root workspace, one lock (901 packages), `default-members` is the Windows set.
3. `nix/workspace-src.nix`: each flake builds its platform's source plus stubs of every other member,
   `-p` per platform.
4. `komorebic` is one package with a `cfg_select!` over three CLI modules; the help text of each platform
   is a literal (it used to come from the package description).
5. The Linux and macOS CLI files moved into `komorebic/src/{linux,macos}` (pure moves, one per revision);
   the KDE `komorebic` tests are `komorebic/tests/linux_*.rs`. The old `komorebic-linux` and
   `komorebic-macos` packages are shims that include the moved files; they have no tests of their own.
6. `komorebi-client`: the three socket codes made equal (Connection on all), then one package whose
   `lib.rs` is a `cfg_select!` re-exporting `windows.rs`, `linux.rs` or `macos.rs`; old
   `komorebi-client-linux`/`-macos` are shims; `komorebic` uses the one client.

Measured by evaluation (no build): an edit of a Windows-only crate or of `komorebic/src/windows.rs` or
`komorebi-client/src/windows.rs` changes the Windows derivations and no kfde derivation; an edit of a Linux
file changes kfde and no Windows derivation; an edit of a macOS file changes neither. The cache isolation of
the three trees survived the merge and the unified packages.

Costs and limits found on the way:
- The stubbed source is a derivation that crane reads at evaluation (`readDir` in `mkDummySrc`), so
  evaluating another system's attributes needs a builder for that system (decision D-pkg-1).
  `nix flake show --all-systems` and aarch64-darwin drvPaths do not evaluate on a Linux host.
- cargo deny, cargo fmt and taplo run over the merged workspace: deny is called with
  `--workspace --exclude <the other platforms' packages>` and the tree's own deny.toml, fmt gets `-p`;
  none of them has been built.
- cargo allows one path per dependency key: the daemon crates keep distinct keys and the modules alias them
  (`extern crate komorebi_linux as komorebi`, `use crate::komorebi_linux as komorebi`). A dependency with
  no `package =` is named by its lib name, not by its key: write `package = "<same name>"` when the key
  must be the extern name.
- Building both `komorebic` and `komorebic-linux` in one cargo command writes the same binary name twice.
- Comments and docs that name `komorebic/src/main.rs`, `komorebic/tests/*.rs` or the KDE client paths
  (check.rs, ARCHITECTURE.md, scripts/compare-gen.py, the VM check suite) still carry the old paths; they
  are text in files whose change would rebuild the KDE derivations.

## Step 7 for the bar (B0-B3 executed, B4 not)

State: `crates/komorebi-bar-core` holds the shared code (config, widgets, `BarPlatform`, schema views); the
two shells are `komorebi-bar` (Windows) and `komorebi-for-mac/komorebi-bar` (package `komorebi-bar-macos`),
see `bar-unification.md` for what stays per platform. Both use `komorebi-bar-core` (one version) and
differ in `main.rs`, `bar.rs`, `os.rs`, `widgets/{komorebi,network,widget,mod}.rs`; Windows adds
`widgets/{keyboard,media,systray}.rs`. `crate::` occurs 111 times (Windows) and 90 (macOS).

B0. Prerequisite (done, step 6): one `komorebi-client`. In `komorebi-for-mac/komorebi-bar/Cargo.toml` change
    `komorebi-client = { package = "komorebi-client-macos", path = "../komorebi-client", ... }` to
    `komorebi-client = { path = "../../komorebi-client", default-features = false }`; the feature
    `schemars` already forwards to `komorebi-client/default`. Gate: macOS fake-CC check of
    `komorebi-bar-macos`; one revision.

B1. Windows bar becomes a module, in place. Create `komorebi-bar/src/windows/`; `git mv`/`jj` move
    `bar.rs config.rs os.rs widgets/` into it and `main.rs` to `windows/mod.rs` (`mod bar; mod config; mod
    os; mod widgets;` stay as they are, `fn main` becomes `pub fn main`). In the moved files replace
    `crate::` by `crate::windows::` (sed, 111 sites; do not touch `komorebi_bar_core::`). New
    `komorebi-bar/src/main.rs`: `mod windows; fn main() -> color_eyre::eyre::Result<()> { windows::main() }`.
    Pure move plus one mechanical edit, two revisions (move, then the paths). Gate: Windows clippy
    `-D warnings`; the bar screenshot gate (owed since the bar stack) and `e2e-needed` says NO for the bar.

B2. macOS bar the same, in its own package: `komorebi-for-mac/komorebi-bar/src/macos/`,
    `crate::` -> `crate::macos::` (90 sites), `main.rs` = `mod macos; fn main() { macos::main() }`. Gate:
    macOS fake-CC check; the Mac hand check.

B3. Merge into one package (one revision, with its flake edit):
    - Move `komorebi-for-mac/komorebi-bar/src/macos` to `komorebi-bar/src/macos`.
    - `komorebi-bar/src/main.rs`: `cfg_select! { target_os = "windows" => { mod windows; use windows as
      platform; } target_os = "macos" => { mod macos; use macos as platform; } }` and `fn main() { platform::main() }`.
    - `komorebi-bar/Cargo.toml`: common `[dependencies]` = what both manifests share (`komorebi-bar-core`,
      `komorebi-client`, `komorebi-themes`, `chrono`, `chrono-tz`, `clap`, `color-eyre`, `crossbeam-channel`,
      `dirs`, `dunce`, `eframe`, `egui-phosphor`, `font-loader`, `hotwatch`, `image`, `lazy_static`, `num*`,
      `parking_lot`, `random_word`, `reqwest`, `schemars`, `serde`, `serde_json`, `sysinfo`, `tracing*`);
      `[target.'cfg(windows)'.dependencies]`: `egui_extras`, `netdev = "0.46"`, `regex`, `systray-util`,
      `tokio`, `which`, `windows`, `windows-core`, both `windows-icons` revisions;
      `[target.'cfg(target_os = "macos")'.dependencies]`: `netdev = "0.40"`, `icns`, `objc2`,
      `objc2-app-kit` (the feature list of the macOS manifest), `raw-window-handle`. The dependency versions
      of the two manifests differ only for `netdev` (0.46 / 0.40), which cargo accepts per target.
    - Old package `komorebi-bar-macos` stays: `komorebi-for-mac/komorebi-bar/src/main.rs` is
      `#[path = "../../../komorebi-bar/src/macos/mod.rs"] mod macos; fn main() { macos::main() }`
      (the moved code names `crate::macos::`, which this root provides).
    - Flakes: the macOS flake `-p komorebi-bar` instead of `-p komorebi-bar-macos`, its source filter takes
      `komorebi-bar/{Cargo.toml,src/main.rs,src/macos/**}` and `isReal` `komorebi-bar`; the root filter
      leaves `komorebi-bar/src/macos` out and the KDE flake needs nothing (it never had a bar; the stub
      is the member's manifest). The `fmt`/`deny` lists drop `komorebi-bar` from the macOS exclusions.
    - Schemas: `schema.bar.json` and `komorebi-for-mac/schema.bar.json` stay; the oracle test in
      `komorebi-bar-core` reads both. `cargo run -p komorebi-bar -- --schema` prints the view of the target OS.
    Gates: Windows clippy, macOS fake-CC check of `komorebi-bar` and `komorebi-bar-macos`, the schema oracle
    (`cargo test -p komorebi-bar-core`), nix evaluation, the isolation test of the evaluation (an edit of
    `komorebi-bar/src/windows/` must not change a macOS derivation and the reverse). Owed: the Windows bar
    screenshot, the Mac hand check.

B4. Converge the remaining differences one revision each, each BEHAVIOUR on one platform and needing its
    screenshot or Mac check: `widgets/komorebi.rs` frame margins, `network.rs`, then the platform seams in
    `bar.rs`/`main.rs` behind `BarPlatform` hooks (list in `bar-unification.md`).

## Owed from the coordinator (heavy gates, idle host; everything below was evaluated, none built)

At bookmark `wip-u-pkg-mig`:

```
tools/gate-lock run --class heavy --label "pkg checks" --est 25 -- nix build -L --no-link \
  .#checks.x86_64-linux.komorebi-workspace-clippy .#checks.x86_64-linux.komorebi-workspace-deny \
  .#checks.x86_64-linux.komorebi-workspace-fmt .#checks.x86_64-linux.komorebi-workspace-toml-fmt \
  .#checks.x86_64-linux.komorebi-workspace-nextest
tools/gate-lock run --class heavy --label "pkg kfde checks" --est 40 -- nix build -L --no-link \
  .#checks.x86_64-linux.kfde-komorebi-workspace-{clippy,doc,deny,fmt,toml-fmt,nextest} \
  .#checks.x86_64-linux.kfde-schema-fresh .#packages.x86_64-linux.kfde-komorebic .#packages.x86_64-linux.kfde-komorebi
nix build -L .#packages.x86_64-linux.komorebic .#packages.x86_64-linux.komorebi
```

then the KDE VM `fast` suites (the KDE package derivations changed), and the Windows e2e gate
(`tools/e2e-needed` says YES: `komorebi-windows`, `komorebic` and `komorebi-client` changed); on a Mac or
a darwin builder `nix build -L .#packages.aarch64-darwin.kfm-komorebic .#packages.aarch64-darwin.kfm-komorebi
.#packages.aarch64-darwin.kfm-komorebi-bar` and the `kfm-` checks. By hand on a Mac: `komorebic --help`,
`--version`, `quickstart`, `start`, `stop`, `state`, `docgen`; `komorebi-bar` still builds from the old
package name. If deny, fmt or taplo fail in the merged workspace, the fix is in the `cargoDenyExtraArgs`,
`cargoExtraArgs` of the three flakes, not in the code.

### Bar: what was done and what was left

B0-B3 are done as revisions of `wip-u-pkg-mig` (client edge, Windows module, macOS module, merge). Edits
were mechanical: `crate::` to `crate::windows::` / `crate::macos::`, one more `../` in the `include_str!`
paths, the unused root re-export of `komorebi_bar_core::platform` dropped. `komorebi-bar-macos` remains as
a shim. The schema gate is `S/bar2/regen.sh` (now reads `src/windows` and `src/macos`): both bars' schema
files regenerate byte-identical on Linux. B4 was not done: the remaining differences are rendering
(frame margins in `widgets/komorebi.rs`), `network.rs` behaviour and the window seams in `bar.rs`/`main.rs`,
none of which can be shown to be mechanical without a screen.

## For the Mac Mini (aarch64-darwin, native)

Run on the revisions of `wip-u-pkg-mig` at or after the stated one, from the repository root:

```
cargo build --locked -p komorebic -p komorebi-macos -p komorebi-bar    # after "one komorebi-bar package"
# (the line that built the shims komorebic-macos, komorebi-bar-macos, komorebi-client-macos is gone: they were deleted)
cargo clippy --locked -p komorebic -p komorebi-client -p komorebi-bar -p komorebi-bar-core -p komorebi-macos --all-targets -- -D warnings
cargo test --locked -p komorebi-macos -p komorebic -p komorebi-client -p komorebi-bar-core -p komorebi-bar
target/debug/komorebic --help; target/debug/komorebic --version; target/debug/komorebic docgen --output /tmp/docs-mac
target/debug/komorebi-bar --schema | cmp - schemas/macos/schema.bar.json
```

Note: there is no package named `komorebi` yet: the daemon is `komorebi-macos` on macOS and `komorebi-windows` on Windows (binary name `komorebi` for both; the single `komorebi` package is step 8). Never write `-p komorebi` (history: step 8 below added it). The `komorebic-macos` shim no longer exists. The lint fix `fix(bar-core): WidgetConfig::supported as matches!` is needed for clippy to pass.
The macOS checks that matter by revision:
`refactor(komorebic): move the macOS CLI ...` (komorebic, quickstart, start, stop), `refactor(client): one
komorebi-client ...` (the client tests in `komorebi-client/src/macos.rs`), and `refactor(bar): one
komorebi-bar package ...` (the bar opens, `--schema`). Everything in `docs/dev/macos-handcheck.md` still applies. (The commands in this block are those of the time; the runbook with the current names is `docs/dev/macos-hand-check-plan.md`.)

## Step 8 done: one `komorebi`

`komorebi-daemon/` is the package `komorebi` (binary `komorebi`): a `main` that calls
`komorebi_windows::daemon::run()`, `komorebi_linux::daemon::run()` or `komorebi_macos::daemon::run()` by
`cfg_select!` on the target OS, through target-gated dependencies on the three libraries. The old `main.rs`
files are `daemon.rs` of those libraries (`komorebi::` became `crate::`), and the libraries have no binary:
`-p komorebi-windows`, `-p komorebi-linux` and `-p komorebi-macos` still build, as libraries; the binary is
`-p komorebi` on every platform. The features `deadlock_detection` and `schemars` are forwarded.
The KDE tests that run the binary moved to `komorebi-daemon/tests/linux_*.rs`.

So `cargo build -p komorebi`, `-p komorebic`, `-p komorebi-bar` and `cargo run -p komorebi-bar -- --schema` build and
run the right program on Windows, KDE Plasma and macOS.

### What is left for the cutover

Done in the cutover stack (`jj log -r 'wip-main..wip-cutover'`):

- the shim packages `komorebic-linux`, `komorebic-macos`, `komorebi-client-linux`, `komorebi-client-macos`,
  `komorebi-bar-macos` and their directories are deleted;
- `version-linux` and `version-macos` are one `crates/komorebi-version`; the workspace version is 0.2.0 for
  every package (0.1.42 / 0.1.0 / 0.1.1 above are history);
- the directories are the final ones (`komorebi-windows/`, `komorebi-linux/`, `komorebi-macos/`,
  `komorebi-hotkeys/`; `docs/{linux,macos}`, `nix/{linux,macos}`, `scripts/linux`, `schemas/*`), one `deny.toml`,
  `rustfmt.toml`, `rust-toolchain.toml`, `.gitignore`, `LICENSE.md` and `justfile`, and the comments and
  docs that named the old paths name the new ones;
- the libraries `komorebi-windows`, `komorebi-linux`, `komorebi-macos` stay: they are the daemons.

Still open:

- the three flakes becoming one: being written by the agent `flake-one`; the `kfde-*` and `kfm-*` attribute
  names in this file are the old ones until it lands;
- CI and release workflows: the old repositories' files are archived in `docs/dev/old-ci/` and nothing
  builds the Linux or macOS packages in CI;
- the site and repository URLs of the old projects, which are unchanged;
- `docs/linux/dev/COMPARE.md` and `scripts/linux/compare-gen.py` are stale.

Owed by the coordinator for this step (none was built): the heavy builds listed above, now also
`nix build -L .#packages.x86_64-linux.komorebi .#packages.x86_64-linux.kfde-komorebi`; the Windows e2e
(BEHAVIOUR: the Windows executable is linked from the library's `daemon::run`); the KDE VM `fast` suites.

### Mac Mini commands for the new package

```
cargo build --locked -p komorebi -p komorebic -p komorebi-bar
target/debug/komorebi --version            # prints komorebi 0.2.0 (it printed 0.1.0 at the time of step 8)
target/debug/komorebi --help | head -3
cargo clippy --locked -p komorebi -p komorebi-macos -p komorebic -p komorebi-client -p komorebi-bar -p komorebi-bar-core --all-targets -- -D warnings
cargo test --locked -p komorebi-macos -p komorebic -p komorebi-client -p komorebi-bar-core -p komorebi-bar
cargo build --locked --features deadlock_detection -p komorebi      # the feature is forwarded
```

`komorebi` is now a package name on every platform: `-p komorebi` builds the macOS daemon on a Mac. The libraries
build with `cargo build -p komorebi-macos` but have no binary. The daemon itself (start, tile, `komorebic state`) is
the hand check in `docs/dev/macos-handcheck.md`.