{"owner":"feschber","repo":"lan-mouse","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# Lan Mouse Agent Instructions\n\n## Overview\n\nLan Mouse is an open-source Software KVM sharing mouse/keyboard input across local networks. The Rust workspace combines a GTK frontend, CLI/daemon mode, and multi-OS capture/emulation backends for Linux, Windows, and macOS.\n\n## Core principles\n\n- **Scope discipline.** Only implement what was requested; describe follow-up work instead of absorbing it.\n- **Clarify OS behavior.** Ask when requirements touch OS-specific capture/emulation (they differ significantly).\n- **Docs stay current.** Update [README.md](README.md) or [DOC.md](DOC.md) when touching public APIs or platform support.\n- **Rust idioms.** Use `Result`/`Option`, `thiserror` for errors, descriptive logs, and concise comments for non-obvious invariants.\n\n## Terminology\n\n- **Client:** A remote machine that can receive or send input events. Each client is either _active_ (receiving events) or _inactive_ (can send events back). This mutual exclusion prevents feedback loops.\n- **Backend:** OS-specific implementation for capture or emulation (e.g., libei, layer-shell, wlroots, X11, Windows, macOS).\n- **Handle:** A per-client identifier used to route events and track state (pressed keys, position).\n\n## Architecture\n\n**Pipeline:** `input-capture` → `lan-mouse-ipc` → `input-emulation`\n\n- **input-capture:** Reads OS events into a `Stream<CaptureEvent>`. Backends tried in priority order (libei → layer-shell → X11 → fallback). Tracks `pressed_keys` to avoid stuck modifiers. `position_map` queues events when multiple clients share a screen edge.\n- **input-emulation:** Replays events via the `Emulation` trait (`consume`, `create`, `destroy`, `terminate`). Maintains `pressed_keys` and releases them on disconnect.\n- **lan-mouse-ipc / lan-mouse-proto:** Protocol glue and serialization. Events are UDP; connection requests are TCP on the same port. Version bumps required when serialization changes.\n- **input-event:** Shared scancode enums and abstract event types—extend here, don't duplicate translations.\n\n## Feature & cfg discipline\n\n- Feature flags live in root `Cargo.toml`. Gate OS-specific modules with the configs exported in build.rs (e.g., `cfg(layer_shell)`).\n- Prefer module-level gating over per-function cfgs to avoid empty stubs.\n- New backends: add feature in `Cargo.toml`, create gated module, log backend selection.\n\n## Async patterns\n\n- Tokio runtime with `futures` streams and `async_trait`. Model new flows as streams or async methods.\n- Avoid blocking; use `spawn_blocking` if needed. Prefer existing single-threaded stream handling.\n- `InputCapture` implements `Stream` and manually pumps backends—don't short-circuit this logic.\n\n## Commands\n\n```sh\ncargo build --workspace                                    # full build\ncargo build -p <crate>                                     # single crate\ncargo test --workspace                                     # all tests\ncargo fmt && cargo clippy --workspace --all-targets --all-features  # lint\nRUST_LOG=lan_mouse=debug cargo run                         # debug logging\n```\n\nRun from repo root—no `cd` in scripts.\n\n## Testing\n\n- Unit tests for utilities; integration tests for protocol behavior.\n- OS-specific backends: test via GTK/CLI on target OS or document manual verification.\n- Dummy backend exercises pipeline without real dependencies.\n- Verify `terminate()` releases keys on unexpected disconnect.\n\n## Workflow\n\n1. Clarify ambiguous requirements, especially OS-specific behavior.\n2. Implement minimal change; flag follow-up work.\n3. Add proportional tests; run `cargo test` on affected crates.\n4. Run `cargo fmt` and `cargo clippy --workspace --all-targets --all-features`.\n"},"files":{"AGENTS.md":"# Lan Mouse Agent Instructions\n\n## Overview\n\nLan Mouse is an open-source Software KVM sharing mouse/keyboard input across local networks. The Rust workspace combines a GTK frontend, CLI/daemon mode, and multi-OS capture/emulation backends for Linux, Windows, and macOS.\n\n## Core principles\n\n- **Scope discipline.** Only implement what was requested; describe follow-up work instead of absorbing it.\n- **Clarify OS behavior.** Ask when requirements touch OS-specific capture/emulation (they differ significantly).\n- **Docs stay current.** Update [README.md](README.md) or [DOC.md](DOC.md) when touching public APIs or platform support.\n- **Rust idioms.** Use `Result`/`Option`, `thiserror` for errors, descriptive logs, and concise comments for non-obvious invariants.\n\n## Terminology\n\n- **Client:** A remote machine that can receive or send input events. Each client is either _active_ (receiving events) or _inactive_ (can send events back). This mutual exclusion prevents feedback loops.\n- **Backend:** OS-specific implementation for capture or emulation (e.g., libei, layer-shell, wlroots, X11, Windows, macOS).\n- **Handle:** A per-client identifier used to route events and track state (pressed keys, position).\n\n## Architecture\n\n**Pipeline:** `input-capture` → `lan-mouse-ipc` → `input-emulation`\n\n- **input-capture:** Reads OS events into a `Stream<CaptureEvent>`. Backends tried in priority order (libei → layer-shell → X11 → fallback). Tracks `pressed_keys` to avoid stuck modifiers. `position_map` queues events when multiple clients share a screen edge.\n- **input-emulation:** Replays events via the `Emulation` trait (`consume`, `create`, `destroy`, `terminate`). Maintains `pressed_keys` and releases them on disconnect.\n- **lan-mouse-ipc / lan-mouse-proto:** Protocol glue and serialization. Events are UDP; connection requests are TCP on the same port. Version bumps required when serialization changes.\n- **input-event:** Shared scancode enums and abstract event types—extend here, don't duplicate translations.\n\n## Feature & cfg discipline\n\n- Feature flags live in root `Cargo.toml`. Gate OS-specific modules with the configs exported in build.rs (e.g., `cfg(layer_shell)`).\n- Prefer module-level gating over per-function cfgs to avoid empty stubs.\n- New backends: add feature in `Cargo.toml`, create gated module, log backend selection.\n\n## Async patterns\n\n- Tokio runtime with `futures` streams and `async_trait`. Model new flows as streams or async methods.\n- Avoid blocking; use `spawn_blocking` if needed. Prefer existing single-threaded stream handling.\n- `InputCapture` implements `Stream` and manually pumps backends—don't short-circuit this logic.\n\n## Commands\n\n```sh\ncargo build --workspace                                    # full build\ncargo build -p <crate>                                     # single crate\ncargo test --workspace                                     # all tests\ncargo fmt && cargo clippy --workspace --all-targets --all-features  # lint\nRUST_LOG=lan_mouse=debug cargo run                         # debug logging\n```\n\nRun from repo root—no `cd` in scripts.\n\n## Testing\n\n- Unit tests for utilities; integration tests for protocol behavior.\n- OS-specific backends: test via GTK/CLI on target OS or document manual verification.\n- Dummy backend exercises pipeline without real dependencies.\n- Verify `terminate()` releases keys on unexpected disconnect.\n\n## Workflow\n\n1. Clarify ambiguous requirements, especially OS-specific behavior.\n2. Implement minimal change; flag follow-up work.\n3. Add proportional tests; run `cargo test` on affected crates.\n4. Run `cargo fmt` and `cargo clippy --workspace --all-targets --all-features`.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# Lan Mouse Agent Instructions\n\n## Overview\n\nLan Mouse is an open-source Software KVM sharing mouse/keyboard input across local networks. The Rust workspace combines a GTK frontend, CLI/daemon mode, and multi-OS capture/emulation backends for Linux, Windows, and macOS.\n\n## Core principles\n\n- **Scope discipline.** Only implement what was requested; describe follow-up work instead of absorbing it.\n- **Clarify OS behavior.** Ask when requirements touch OS-specific capture/emulation (they differ significantly).\n- **Docs stay current.** Update [README.md](README.md) or [DOC.md](DOC.md) when touching public APIs or platform support.\n- **Rust idioms.** Use `Result`/`Option`, `thiserror` for errors, descriptive logs, and concise comments for non-obvious invariants.\n\n## Terminology\n\n- **Client:** A remote machine that can receive or send input events. Each client is either _active_ (receiving events) or _inactive_ (can send events back). This mutual exclusion prevents feedback loops.\n- **Backend:** OS-specific implementation for capture or emulation (e.g., libei, layer-shell, wlroots, X11, Windows, macOS).\n- **Handle:** A per-client identifier used to route events and track state (pressed keys, position).\n\n## Architecture\n\n**Pipeline:** `input-capture` → `lan-mouse-ipc` → `input-emulation`\n\n- **input-capture:** Reads OS events into a `Stream<CaptureEvent>`. Backends tried in priority order (libei → layer-shell → X11 → fallback). Tracks `pressed_keys` to avoid stuck modifiers. `position_map` queues events when multiple clients share a screen edge.\n- **input-emulation:** Replays events via the `Emulation` trait (`consume`, `create`, `destroy`, `terminate`). Maintains `pressed_keys` and releases them on disconnect.\n- **lan-mouse-ipc / lan-mouse-proto:** Protocol glue and serialization. Events are UDP; connection requests are TCP on the same port. Version bumps required when serialization changes.\n- **input-event:** Shared scancode enums and abstract event types—extend here, don't duplicate translations.\n\n## Feature & cfg discipline\n\n- Feature flags live in root `Cargo.toml`. Gate OS-specific modules with the configs exported in build.rs (e.g., `cfg(layer_shell)`).\n- Prefer module-level gating over per-function cfgs to avoid empty stubs.\n- New backends: add feature in `Cargo.toml`, create gated module, log backend selection.\n\n## Async patterns\n\n- Tokio runtime with `futures` streams and `async_trait`. Model new flows as streams or async methods.\n- Avoid blocking; use `spawn_blocking` if needed. Prefer existing single-threaded stream handling.\n- `InputCapture` implements `Stream` and manually pumps backends—don't short-circuit this logic.\n\n## Commands\n\n```sh\ncargo build --workspace                                    # full build\ncargo build -p <crate>                                     # single crate\ncargo test --workspace                                     # all tests\ncargo fmt && cargo clippy --workspace --all-targets --all-features  # lint\nRUST_LOG=lan_mouse=debug cargo run                         # debug logging\n```\n\nRun from repo root—no `cd` in scripts.\n\n## Testing\n\n- Unit tests for utilities; integration tests for protocol behavior.\n- OS-specific backends: test via GTK/CLI on target OS or document manual verification.\n- Dummy backend exercises pipeline without real dependencies.\n- Verify `terminate()` releases keys on unexpected disconnect.\n\n## Workflow\n\n1. Clarify ambiguous requirements, especially OS-specific behavior.\n2. Implement minimal change; flag follow-up work.\n3. Add proportional tests; run `cargo test` on affected crates.\n4. Run `cargo fmt` and `cargo clippy --workspace --all-targets --all-features`.\n","category":"root","tokens":919}]}