core::asc re-exports ApplicationSpecificConfiguration, AscApplicationRules and AscApplicationRulesOrSchema from komorebi-config; the local copy (60 lines) is removed. AscApplicationRules is now the union with the five Windows-only rule kinds: KDE only reads and writes its own, the others are None and skipped when written.
A derived schema of the union would carry the Windows-only kinds and the x-komorebi-platforms markers, so the places that print or answer the applications schema ask for the KDE view instead: komorebic (application-specific-configuration-schema; komorebic gains the komorebi-config dependency, a two-line change in the arm) and the daemon's socket answer (same view, array form as before). This is the minimum change to komorebic that keeps its output; step 4 owns the rest of the file.
Verified: KDE cargo check --workspace --all-targets: no warnings; cargo test -p komorebi --lib: 289 passed, 0 failed; --test schemas: 5 passed; komorebic regeneration: schema.asc.json byte-identical to the checked-in file (git: no diff against wip-main), schema.json only differs by the earlier description-only converge revisions.
core::asc re-exports ApplicationSpecificConfiguration, AscApplicationRules and AscApplicationRulesOrSchema, and config_generation re-exports ApplicationOptions and ApplicationConfiguration, from komorebi-config. The From<Vec<ApplicationConfiguration>> conversion that komorebic uses moved with them (orphan rule). The YAML generator stays. 215 lines removed.
AscApplicationRules is now the union, so komorebic's application-specific-configuration-schema prints the Windows view of it (komorebic gains the komorebi-config dependency; a three-line change in the arm, the minimum that keeps its output equal to schema.asc.json; step 4 owns the rest of the file). The daemon's own socket answer for this message is a different schema (Vec<ApplicationConfiguration>) and is untouched.
Verified: Windows cargo clippy --workspace --locked --all-targets -D warnings: clean (tier 2). Not verified: running komorebic.exe; the oracle test proves the Windows view equals schema.asc.json byte for byte.
ApplicationSpecificConfiguration, AscApplicationRulesOrSchema and AscApplicationRules are code-identical in the trees except that AscApplicationRules differs in its rule kinds: five Windows-only kinds, titleless and tabbed on KDE and macOS. The crate holds the union (declaration order floating-first as before; the platform-only fields carry x-komorebi-platforms, so a view prunes them) and, for the Windows From<Vec<ApplicationConfiguration>> conversion that the orphan rule keeps next to its types, ApplicationOptions and ApplicationConfiguration (data only: the YAML generator stays in the Windows daemon). The crate gains the color-eyre dependency.
The oracle test builds the view of ApplicationSpecificConfiguration for Windows, KDE and macOS and compares it with each tree's checked-in schema.asc.json byte for byte: all three are identical. This is the first proof that per-platform views of one union reproduce the checked-in files exactly (D17/D18); the three trees still use their own copies.
Verified: native cargo test -p komorebi-config: 4 unit + 6 schemas passed, 0 failed (tier 1).
schema::view prunes the schema of a type to what one platform reads: properties whose x-komorebi-platforms list does not name the platform are dropped (and removed from required), the markers are stripped, and the definitions that nothing refers to any more are removed, in the original order. Descriptions that komorebi-protocol writes differently per compile target (ApplicationIdentifier::Class, PathBuf, FocusFollowsMouseImplementation) are set per platform from a table, so a view is the same on every host. The approach is the one of D17/D18; the next revision proves it on the applications schema.
Verified: native cargo test -p komorebi-config compiles (tier 1); exercised by the next revision's test.
window and animation re-export the three types from komorebi-config; the local definitions and their imports are removed, so no call site changes.
Verified: macOS fake-CC cargo check --locked --target aarch64-apple-darwin --workspace --all-targets: finished, 0 errors, no warnings in komorebi (tier 2). Not verified: macOS unit tests.
window and animation re-export the three types from komorebi-config; the local definitions (82 lines) and their imports are removed, so no call site changes.
Verified: KDE cargo check --workspace --all-targets: no warnings; cargo test -p komorebi --lib: 289 passed, 0 failed; --test schemas: 5 passed; komorebic regeneration: schema.json and schema.asc.json byte-identical to the checked-in files.
window re-exports AspectRatio and PredefinedAspectRatio and animation re-exports PerAnimationPrefixConfig from komorebi-config; the local definitions are removed (87 lines) with the imports they needed, so no call site changes. cargo fmt also drops two stray blank lines left by the previous revision in border_manager and core.
Verified: Windows cargo clippy --workspace --locked --all-targets -D warnings: clean (tier 2). schema.json untouched.
AspectRatio and PredefinedAspectRatio (with the Default and width_and_height impls) and the generic PerAnimationPrefixConfig<T> have identical code in the three trees and, after the previous converge revisions, identical docs; the crate takes the Windows copy. The trees keep their copies until the next revisions.
The oracle gains a check that the generated AspectRatio and PredefinedAspectRatio definitions equal those of all three checked-in schema.json files. PerAnimationPrefixConfig has no check of its own: its definitions are numbered per instantiation, so the AnimationsConfig move covers it.
Verified: native cargo test -p komorebi-config: 4 unit + 5 schemas passed, 0 failed (tier 1).
Same two variant docs as in the KDE revision before: 'A predefined aspect ratio' and 'A custom W:H aspect ratio' become the Windows 'Predefined aspect ratio' and 'Custom W:H aspect ratio'.
Schema: komorebi-for-mac/schema.json cannot be regenerated on this host, so the two description lines were edited to the text of the doc comments; the file equals the old one after deleting every description (jq walk), so description-only. The next revisions compare the generated definitions of the shared crate with this file.
Verified: jq description-only comparison (4 changed lines). Doc comments only: no compile needed, not run.
The two variant docs said 'A predefined aspect ratio' and 'A custom W:H aspect ratio' in KDE and macOS and 'Predefined aspect ratio' and 'Custom W:H aspect ratio' in Windows; the code of AspectRatio and PredefinedAspectRatio is identical in all three trees, so the docs are what stops one shared copy.
Schema: komorebi-for-kde/schema.json regenerated with the real komorebic: 2 description lines change, and the file equals the old one after deleting every description (jq walk), so description-only. schema.asc.json unchanged.
Verified: KDE komorebic build and regeneration (tier 1).
core re-exports WindowContainerBehaviour, FloatingLayerBehaviour, Placement, CrossBoundaryBehaviour and WindowHidingPosition from komorebi-config; the local definitions and impls are removed, so no call site changes.
Verified: macOS fake-CC cargo check --locked --target aarch64-apple-darwin --workspace --all-targets: finished, 0 errors, no new warnings (tier 2). Not verified: macOS unit tests.
core re-exports WindowContainerBehaviour, FloatingLayerBehaviour, Placement, CrossBoundaryBehaviour and WindowHidingPosition from komorebi-config; the local definitions and impls are removed, so no call site changes.
Verified: KDE cargo check --workspace --all-targets clean; cargo test -p komorebi --lib: 289 passed, 0 failed; --test schemas: 5 passed; komorebic static-config-schema and application-specific-configuration-schema regenerated: schema.json and schema.asc.json unchanged (byte-identical, no diff).
core re-exports WindowContainerBehaviour, FloatingLayerBehaviour, Placement, CrossBoundaryBehaviour and WindowHandlingBehaviour, and border_manager re-exports ZOrder, from komorebi-config; the local definitions and their impls (including From<ZOrder> for isize, which the orphan rule requires to move with the type) are removed, so no call site changes.
Verified: Windows cargo clippy --workspace --locked --all-targets -D warnings: clean (tier 2). schema.json untouched.
WindowContainerBehaviour, FloatingLayerBehaviour (with should_float), Placement (with should_center and should_resize), CrossBoundaryBehaviour, WindowHidingPosition (KDE and macOS), WindowHandlingBehaviour and ZOrder (with its From<ZOrder> for isize; Windows) in behaviour.rs. The text is the KDE copy for the five that all trees share (identical to the Windows and macOS copies after the previous converge revision) and the Windows copy for the two Windows-only enums. A platform-only enum is defined here without a cfg: the daemon that does not read the key says so at load time. The trees keep their copies until the next revisions. The crate gains the clap dependency (ValueEnum) and the three Cargo.lock files the package entry.
The oracle gains a check that the generated definition of each enum equals the $defs entry of every checked-in schema.json that has it (all three trees for four of them, KDE and macOS for WindowHidingPosition, Windows for the other two).
Verified: native cargo test -p komorebi-config: 4 unit + 4 schemas passed, 0 failed (tier 1).
WindowContainerBehaviour, FloatingLayerBehaviour, Placement, CrossBoundaryBehaviour and WindowPlacement said 'behavior' in KDE and 'behaviour' in Windows and macOS (the doc text is otherwise identical), so one copy in komorebi-config can be moved only after they agree. Same choice as the step 2 payload enums.
Schema: komorebi-for-kde/schema.json regenerated with the real komorebic (5 description lines, 10 changed lines); equal to the old file after deleting every description (jq walk), so description-only. schema.asc.json is unchanged. Windows and macOS schemas are untouched (they already said 'behaviour').
Verified: KDE cargo build -p komorebic and regeneration (tier 1). Not done: komorebi-for-kde/nix/komorebi-options.nix still carries the old text and an old schema-sha256 header (already out of date since step 2); no schemars-nixgen here, refreshed by substitution at the end of the step.
komorebi depends on komorebi-config (workspace dependency with the schemars feature, like komorebi-protocol) and core::config_generation re-exports the five matching types from it, so no call site changes. 84 duplicated lines are removed. Cargo.lock gains the komorebi-config package.
Verified: macOS fake-CC cargo check --locked --target aarch64-apple-darwin --workspace --all-targets: finished, 0 errors (tier 2, type-check only). Not verified: macOS unit tests (cannot run).
komorebi depends on komorebi-config (workspace dependency with the schemars feature, like komorebi-protocol) and core::config_generation re-exports the five matching types from it, so no call site changes. 159 lines are removed: the five types and, with them, the four unit tests that now run in the crate.
Verified: KDE cargo check --workspace --all-targets: clean; cargo test -p komorebi --lib: 289 passed, 0 failed (was 293 before: the 4 tests moved to komorebi-config); --test rules, transparency, rule_commands: 6, 1, 6 passed. Full workspace test run follows at the end of the stage.
komorebi depends on komorebi-config and core::config_generation re-exports MatchingRule, WorkspaceMatchingRule, IdWithIdentifier, MatchingStrategy and IdWithIdentifierAndComment from it, so no call site changes. The 84 duplicated lines (five types and the From impl) are removed; ApplicationOptions, ApplicationConfiguration and the generator stay.
Verified: Windows cargo clippy --workspace --locked --all-targets -D warnings: clean (tier 2, persistent target). Schema files untouched.
MatchingRule, WorkspaceMatchingRule, IdWithIdentifier, MatchingStrategy and IdWithIdentifierAndComment (with the From impl) are byte-identical, docs included, in config_generation.rs of the three trees apart from imports. The crate takes the KDE copy (module docs and its four tests) with ApplicationIdentifier from komorebi-protocol. The trees still carry their own copies; they switch in the next revisions.
The oracle test gains a check that the generated definitions of MatchingRule, IdWithIdentifier and MatchingStrategy equal the $defs of all three checked-in schema.json files (ApplicationIdentifier is the protocol crate's and differs per platform by design).
Verified: native cargo test -p komorebi-config: 4 unit + 3 schemas passed, 0 failed (tier 1).
tests/schemas.rs reads schema.json and schema.asc.json of the Windows tree, komorebi-for-kde and komorebi-for-mac by path and checks that every file is in the canonical form the generator prints (so a regenerated schema compares with == on text) and that each keeps today's keys: 53/37/33 properties, 60/52/47 definitions, the six definitions of the applications schema. Nothing is generated from the crate yet, so at this point the test guards the three files against accidental edits; each following stage adds a comparison of the types it moves with these definitions.
Verified: native cargo test -p komorebi-config: 2 passed, 0 failed (tier 1). The three checked-in files were byte-identical to their regenerated forms before this stage (Windows 141169/5945 bytes, KDE 127164/5051, macOS 120057/5051; S/step3/regen.sh).
Add crates/komorebi-config (edition 2024, root workspace member) with the feature-gated schema module that prints a schema the way komorebic does (pretty JSON plus a newline). No type has moved yet: the crate depends on komorebi-layouts, komorebi-themes and komorebi-protocol, which every type that follows needs.
Verified: native cargo test -p komorebi-config compiles (tier 1). Cargo.lock gains only the new package. Windows, KDE and macOS trees do not depend on the crate yet.
The root flake got the code of komorebi-for-kde and komorebi-for-mac through two locked path inputs (kfde, kfm), so the root flake.lock pinned the content of those directories and needed 'nix flake update kfde kfm' after any edit under them; a stale pin gave 'attribute lib missing'.
Now the root imports komorebi-for-kde/flake.nix and komorebi-for-mac/flake.nix as plain files and calls their outputs/lib.mkOutputs with inputs declared in the root under the names kfde-* and kfm-* (nixpkgs, nixpkgs-lib, flake-compat, flake-parts, crane, rust-overlay, treefmt-nix, git-hooks-nix, and gitignore for kfm), pinned by revision in the URL to exactly the revisions of each nested flake.lock, with the same follows structure. The nested flakes are unchanged and still have their own locks. The kfde and kfm nodes are gone from flake.lock. When a nested flake.lock is bumped, update the revisions of the matching kfde-*/kfm-* inputs by hand.
Verified (tier 2): derivation paths unchanged before and after for kfde fmt, deny, nextest, schema-fresh, the Windows workspace clippy check, kfde-komorebic and kfm-komorebic (aarch64-darwin, eval only); every narHash of the nested locks is present in the root lock; nix flake check --no-build passes on x86_64-linux; nixosModules, overlays, darwinModules evaluate; kfde-vm has 34 suites.
Merge revision: wip-main (history merges, fixes, step 0 path dependencies, step 1 komorebi-collections, KDE A3 fixes, flake phase 2) and wip-step2 (the komorebi-protocol crate, goldens and the unified SocketMessage used by all three trees). Conflicts in the root Cargo.toml members line, the trees' Cargo.toml dependency tables and the Cargo.lock files are resolved in this revision by keeping both sides' additions.
The root flake.lock pins the content of komorebi-for-kde and komorebi-for-mac (D14 of the flake phase 2 work: the root passes its own self to the nested mkOutputs, and the lock records the nested directories). Their trees changed with the step 1 crate and the crates directory in the source filter, so the pins are updated with nix flake update kfde kfm. Only flake.lock changes.
Delete macOS's SocketMessage, as_bytes and FromStr and its now unused imports, and re-export the crate's SocketMessage from core. process_command stays an exhaustive match: the 41 variants macOS does not handle (33 Windows only, 6 Windows and KDE, 2 KDE only) get one explicit or-pattern arm that writes the 'not supported on this platform' reply and returns before anything else happens. Behaviour change: those variants used to fail to parse on macOS and now parse and are answered that way.
Verified: fast-check macOS (fake CC) cargo check --workspace --all-targets: PASS (0 errors, only the existing komorebi-bar warnings). macOS tests not run (cannot).
The nested flakes cut the repository down to their own tree and the root crates they depend on by path (rootCrates). Step 1 added crates/komorebi-collections, which both trees now depend on, so crates/ must be in that list or the root flake cannot build kfde (and kfm cannot evaluate its sources). Listing the directory rather than each crate means later shared crates (protocol, config, ...) are picked up without another flake change. Verified: see the following progress entry.
Two tests against the fake desktop: ForceFocus, StackbarMode and ToggleTitleBars (Windows only) are answered with 'X is not supported on this platform', and a message KDE handles (Retile) is not.
Verified: cargo test -p komorebi --test unsupported_messages in komorebi-for-kde: 2 passed, 0 failed.
Merge revision: wip-main (history merges, fixes, step 0 path dependencies, step 1 komorebi-collections, KDE A3 fixes) and wip-flake (the root flake builds the KDE package with the whole repository as source, the macOS package evaluates the same way, the root flake no longer requires dirtyRev). The root flake.lock pins the content of the nested flakes, so it is relocked in the next revision.
Delete KDE's SocketMessage, as_bytes and FromStr and its now unused imports, and re-export the crate's SocketMessage from core. process_command stays an exhaustive match: the 34 variants KDE does not handle (33 Windows only, plus PanGesture which only Windows and macOS have) get one explicit or-pattern arm that writes the 'not supported on this platform' reply and returns before anything else happens (no notification to subscribers). Behaviour change: those variants used to fail to parse on KDE and now parse and are answered that way. The doctest of SocketMessage lives in the crate now.
Verified: cargo check --workspace --all-targets in komorebi-for-kde: 0 errors, no warnings; cargo test -p komorebi --lib --test schemas --test rule_commands: 302 + 5 + 6 passed, 0 failed; komorebic static-config-schema byte-identical to schema.json. Full workspace run at the end of the stage.
Merge revision on the integration line: wip-step1 (the komorebi-collections crate and its wiring in all three trees, on top of the step 0 path dependencies) and wip-a3-kde (the KDE path-coupling, test-isolation, dirtyRev and lock-order fixes). No file needed manual resolution. Verification of this merge: not run separately; each side passed its own gates (step 1: Windows clippy, KDE 885 tests, macOS type-check; KDE A3: 895 tests three times).
The root flake no longer re-exports the nested flakes' own outputs. It keeps them as inputs for their pinned nixpkgs, crane and rust-overlay (inputs.<name>.inputs), but calls their lib.mkOutputs with the whole repository (self) as the source, a nested self carrying the root rev, dirtyRev and inputs, and the tree's directory, then re-exports packages, checks (without vm-*), legacyPackages.kfde-vm, nixosModules, overlays and darwinModules from those. flake.lock is updated for the changed nested flakes: the lock pins their content, so it needs 'nix flake update kfde kfm' whenever a file under komorebi-for-kde or komorebi-for-mac changes.
Verified (Linux, x86_64): nix build -L of packages.kfde-komorebic and kfde-komorebi succeed and both binaries run with --help (exit 0); checks kfde-schema-fresh, nix-options-validation, keybindings-fixtures, komorebi-bridge-js, nixos-module-eval, plasma-guests-eval, run-kde-dry-run, run-kde-doctor, komorebi-workspace-fmt, -deny and -nextest build; kfde-komorebi-workspace-toml-fmt FAILS because komorebi-for-kde/Cargo.toml itself is not taplo-formatted (same result running taplo on the file directly; not caused by this change). nix eval of aarch64-darwin kfm-komorebic and kfm-komorebi drvPath print .drv paths (evaluated, not built). Windows clippy and default drvPaths are identical to those before this revision. nix flake check --no-build passes for x86_64-linux. Not verified: any darwin build, kfde clippy/doc, the VM suites.
Delete the Windows SocketMessage, its as_bytes and FromStr (now in the crate) and re-export komorebi_protocol::message::SocketMessage from core, so komorebi::SocketMessage and komorebi_client::SocketMessage keep working. process_command stays an exhaustive match: the two KDE-only variants (ReloadHotkeys, HotkeysState) get one explicit arm that writes the 'not supported on this platform' reply (SocketMessage::not_supported_reply) and returns before anything else happens, so subscribers are not notified either. Behaviour change: those two used to fail to parse on Windows and now parse and are answered that way.
Verified: Windows clippy --workspace --locked --all-targets -D warnings clean; native cargo test -p komorebi-protocol passes. Windows unit tests and e2e not run (cannot on Linux).
Deletes the KDE copies, adds the komorebi-collections path dependency via the workspace table, re-exports ring and lockable_sequence from lib.rs, #[macro_use] extern crate for impl_ring_elements!, and forwards the schemars feature. Cargo.lock updated.
Verified: fast-check KDE cargo check, --lib tests and schemas test: PASS.
The e2e core was vendored twice (komorebi/e2e/lib and the KDE VM lib), synced by a script. The script now checks the KDE copy against ../e2e/lib in the root, treating the root as the single source, as the plan's A3 requires. Verified: running the script reports the copies in sync.
A path flake (a jj workspace without .git) has neither rev nor dirtyRev, so the commit stamp default in mkKomorebiPackages failed to evaluate. It now falls back to "unknown", as the nested flakes do.
Verified: nix eval --raw .#checks.x86_64-linux.komorebi-workspace-clippy.drvPath now prints z9nb5j12qlfp1j8d71ykp9qnafk553ra-komorebi-workspace-clippy-0.1.0.drv (it failed before); .#packages.x86_64-linux.default.drvPath is cq0i40300hgsm0ih2llcdjpkcg9sfqaf-komorebi-workspace-0.1.0.drv. Neither was built.
message.rs holds the one SocketMessage with the 197 variants of the three trees: the Windows enum verbatim (195 variants, in its order, with ApplyState(StateBlob) and DebugWindow(i64) as converged in the previous revisions) plus the two KDE-only variants (ReloadHotkeys, HotkeysState) at the end, as_bytes and FromStr. platforms.rs has Platform, Platforms and SocketMessage::platforms(), one exhaustive match generated from tests/golden/variants-table.tsv (155 on all three, 33 Windows only, 6 Windows and KDE, 1 Windows and macOS, 2 KDE only). No tree uses it yet.
The golden test now runs the real enum: every golden instance of each platform is accepted with identical wire text (path-expansion instances only with STRICT_PATHS=1, which is meaningful on the target platform only; ApplyState on Windows by tag), every variant of every platform is in the unified schema and every generated instance round-trips, and platforms() matches each platform's variant list both ways.
Verified: native cargo test -p komorebi-protocol: 5 unit + 6 golden + 2 doctests passed, 0 failed. Not run: STRICT_PATHS=1 (fails on Linux for the Windows goldens by design).
Deletes the macOS copies, adds the komorebi-collections path dependency via the workspace table, re-exports ring and lockable_sequence from lib.rs, #[macro_use] extern crate for impl_ring_elements!, and forwards the schemars feature. Cargo.lock updated.
Verified: fast-check macOS fake-CC cargo check --workspace --all-targets: PASS. Not run: tests.
window.rs and static_config.rs locked the float, manage and other rule lists in conflicting orders, which deadlocked KDE tests and could in the daemon. Both now take the locks in one order. Found by test hangs during the merge work. The Windows and macOS trees have the same pattern by reading and were not changed. Verified: the KDE test suite no longer hangs; the VM tier was not re-run.
Same change as for the KDE flake: lib.mkOutputs takes inputs, self, the repository source and the tree's directory; the crane source is the macOS tree plus komorebi-layouts, -scrolling, -themes and the root Cargo.toml; cargoLock, cargoToml and postUnpack point into the tree. The nested flake's own outputs call it with ./. and keep evaluating, but cannot build the Rust workspace on their own.
Verified: nix eval --raw of packages.aarch64-darwin.komorebic.drvPath on the nested flake prints a .drv (evaluated only; nothing darwin was built).
ApplyState(State) becomes ApplyState(StateBlob) (D15): the handler reads the blob into State with serde_json::from_value and applies it as before. Wire bytes for a valid state are unchanged. Behaviour difference: a state that does not parse used to make the whole message fail to parse at the socket; now it is an error returned by the handler (logged). Nothing in this repository sends ApplyState.
Verified: Windows clippy --workspace --locked --all-targets -D warnings clean.
Moves the identical ring.rs and lockable_sequence.rs out of komorebi/src into the crate (rename). Necessary edits: lib.rs with pub use Lockable and a hidden pastey re-export; #[macro_export] on impl_ring_elements! using $crate::pastey::paste!; the doc test now says komorebi_collections::ring::Ring. The Windows tree gets the path dependency, re-exports (pub use komorebi_collections::{ring, lockable_sequence, Lockable}, #[macro_use] extern crate), forwards its schemars feature, and drops pastey again. Windows is bundled here because it is the tree the files move out of.
Verified: fast-check native, Windows clippy --all-targets -D warnings, KDE and macOS checks: PASS.
A path-input flake has no dirtyRev attribute, so evaluation failed. Falls back to "unknown" via self.dirtyRev or. An earlier same-derivation comparison was a false positive because both sides printed the same error; this fix came from retracting it. Verified: the KDE package evaluates and builds from the root flake.
The KDE flake's outputs become a function (lib.mkOutputs) of inputs, self, the repository source and the tree's directory in it. The flake's own outputs still call it with ./. and no directory, so everything evaluates standalone, but the Rust workspace can no longer be built from the nested flake alone: since step 0 it depends on ../komorebi-layouts, -scrolling and -themes, which a nested path input cannot see.
The crane source is now the repository cut down to the KDE tree, those three root crates and the root Cargo.toml (their inherited workspace dependencies come from it). cargoLock and cargoToml point into the tree and postUnpack enters it.
Verified: nix eval of packages.x86_64-linux.komorebic.drvPath on the nested flake prints a .drv; the real build is verified through the root flake (see the revision that wires it). Reindentation by nixfmt makes the diff large; the logic change is the mkOutputs wrapper, the src filter and three commonArgs attributes.
A transparent wrapper of serde_json::Value with a hand written schema (an object, named State), so that SocketMessage can carry ApplyState without the crate knowing the daemon's State type (D15/D16). On the wire it is exactly the state JSON.
Verified: native cargo test -p komorebi-protocol: 5 unit + 3 golden + 1 doctest passed, 0 failed.
New crates/komorebi-collections (edition 2024; deps pastey, serde, optional schemars feature, dev serde_json_lenient) added to the root workspace members, with an empty lib.rs. Cargo.lock for this revision alone is not refreshed (it is in the next revision).
Verified: cargo test -p komorebi-collections --offline built (0 tests yet).
Tests in komorebi/tests/schemas.rs shared one socket path and raced when run in parallel. Each test now gets its own. Verified: cargo test --workspace in the KDE tree.
Empty merge revision joining the step 0 line (path dependencies on the root layouts, scrolling and themes crates) with the KDE A3 line (path-coupling fixes). No file changes of its own, so each parent's content is kept as written. Verified: all three trees type-check on the combined line.
DebugWindow(i64) as in the unified SocketMessage (D15); the comparison with the accessibility window id widens the u32 side, so behaviour for valid ids is unchanged (a negative or oversized id now parses and matches no window).
Verified: fast-check macOS (fake CC) cargo check --workspace --all-targets: PASS.
macOS ring.rs becomes the KDE copy (doc comments, unit tests, std path in the macro; pastey was already used). After this the three ring.rs and lockable_sequence.rs files are byte-identical (cmp).
Verified: fast-check macOS fake-CC cargo check --workspace --all-targets: PASS. Not run: tests (macOS cannot run).
compare-gen.py defaulted to sibling checkouts of the old repos. It now defaults to the Windows tree and macOS tree that sit beside komorebi-for-kde/ in this repository. Verified: runs and finds both trees.
LGUG2Z