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.
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).
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).
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.
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.
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).
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).
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 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).
StackbarMode, StackbarLabel, BorderStyle, BorderImplementation, HidingBehaviour and FocusFollowsMouseImplementation move verbatim from core/mod.rs to the end of crates/komorebi-protocol/src/types.rs, because the unified SocketMessage (stage 2e) carries them; they keep their platform-only status in the support table. The crate allows the deprecated HidingBehaviour::Hide that the derives touch. core re-exports all six.
Verified: Windows clippy --workspace --locked --all-targets -D warnings clean; native cargo test -p komorebi-protocol passes.
KDE's SubscribeOptions carried a doctest that used SocketMessage; it was dropped from the shared text so the three trees could converge before the move. The crate now has a doctest that checks the wire form of the options ({"filter_state_changes":true}) and the default. The SocketMessage example returns when SocketMessage moves (2e).
Verified: native cargo test -p komorebi-protocol: 4 + 3 passed, doctest 1 passed, 0 failed.
SubscribeOptions, StateQuery, WindowKind, ApplicationIdentifier, MoveBehaviour, MonocleFocusBehaviour and OperationBehaviour (text identical in the three trees after the converge revisions, checked with a per-item cmp) move from core/mod.rs to crates/komorebi-protocol/src/types.rs; core re-exports them, so komorebi::core::X and komorebi::X paths are unchanged. The five Windows-only payload enums and FocusFollowsMouseImplementation stay until SocketMessage moves (stage 2e).
Verified: Windows clippy --workspace --locked --all-targets -D warnings clean; native cargo test -p komorebi-protocol passes.
The converged core/animation.rs and animation/prefix.rs (identical in the three trees apart from KDE's QtCurve trait) become crates/komorebi-protocol/src/animation.rs and animation/prefix.rs; the Windows files keep their paths as one-line re-exports, so komorebi::core::AnimationStyle and komorebi::animation::prefix::AnimationPrefix are unchanged. The three serde unit tests now run in the protocol crate.
Verified: Windows clippy --workspace --locked --all-targets -D warnings clean; native cargo test -p komorebi-protocol: 4 + 3 passed, 0 failed.
Delete komorebi-for-kde/komorebi/src/core/pathext.rs (identical to the crate's copy) and re-export komorebi_protocol::pathext from core, so every existing path keeps working. komorebi-protocol becomes a workspace dependency of komorebi-for-kde (schemars feature on); the crate no longer lists dirs (unused until the client moves), so the root Cargo.lock loses that edge. KDE's Cargo.lock gains komorebi-protocol and cargo re-resolved one windows-sys entry.
Verified: cargo check --workspace --all-targets in komorebi-for-kde: 0 errors; cargo test -p komorebi --lib --test schemas: 305 + 5 passed, 0 failed. Full KDE workspace test run is done at the end of the stage.
Pure move of the converged pathext.rs (identical in all three trees, cmp checked) to crates/komorebi-protocol/src/pathext.rs. The Windows daemon depends on the crate (schemars feature forwarded) and re-exports it as komorebi::core::pathext, so every existing path keeps working. Cargo.lock gains the dependency edge.
Verified: Windows clippy --workspace --locked --all-targets -D warnings clean; native cargo test -p komorebi-protocol: 4 passed 0 failed, including the moved pathext unit test (unix branch). The Windows branch of that test cannot run on Linux (not verified).
Add tests/golden/{windows,kde,macos}/{variants.json,schema-variants.txt} (taken from each daemon's own SocketMessage before it moves, oracle D14), the support table variants-table.tsv (197 variants x windows/kde/macos) and the schema-driven generator tests/common/golden_gen.rs.
tests/golden.rs checks, until SocketMessage moves (stage 2e): every golden wire text parses to its golden value; each platform's golden variant set equals its column of the support table; the generator runs on a stand-in enum. Stage 2e swaps in the real enum and compares wire text and schema branches (subset check).
Verified: native cargo test -p komorebi-protocol, 3 passed 0 failed; Windows clippy --workspace --locked --all-targets -D warnings clean.
Add crates/komorebi-protocol (edition 2024, member of the root workspace) with empty modules message, platforms, types, animation and pathext. The client transport stays out of the crate (D16). Cargo.lock gains the new package only.
Verified: native cargo build -p komorebi-protocol succeeds. Windows, KDE and macOS gates not run for this revision (no tree depends on the crate yet).
LGUG2Z