{"owner":"metalbear-co","repo":"mirrord","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# mirrord\n\n## Overview\n\nmirrord is a tool that lets developers run local processes in the context of their Kubernetes cloud environment.\n\n### Core Crates\n\n- `mirrord-layer`: gets loaded into the user's process via `LD_PRELOAD`/`DYLD_INSERT_LIBRARIES`. Intercepts libc\ncalls (files, networking, DNS, env, ...) and turns them into protocol messages sent to the intproxy.\n- `mirrord-intproxy`: a local process spawned by the CLI that bridges N layers and 1 agent. Matches requests to\nresponses, handles reconnects, and routes messages to the right feature proxy.\n- `mirrord-agent`: the in-cluster component of mirrord. Runs in the target pods' context and network namespace. Does the\nactual I/O work requested by the layers.\n- `mirrord-protocol`: defines the shared messages (`ClientMessage`, `DaemonMessage`) sent between layer/intproxy/agent.\n- `mirrord-config`: config types and validation. Used by the CLI and layer to decide what features are enabled and what\ntarget to use.\n- `mirrord`: the CLI that resolves configuration, creates or connects to the agent, starts the intproxy, and launches\nthe user's local process with the mirrord layer loaded.\n\n## Command Reference\n\n### Compiling\n\n```bash\n# check the entire workspace at once\n# always use when a change spans multiple crates instead of checking each crate individually\ncargo clippy --all-targets --all-features --keep-going -- --deny warnings\n\n# check a specific crate\n# the agent is linux only\ncargo clippy -p mirrord-agent --target x86_64-unknown-linux-gnu --keep-going -- --deny warnings\n\n# layer and cli bundled with the new layer\n# use only when a fresh mirrord + layer binary is needed for testing\ncargo xtask build-cli\n```\n\nUse `--keep-going` to surface all errors at once. Use `clippy` instead of `check` to lint + compile simultaneously.\n\n### Testing\n\n```bash\n# integration tests\n# requires building the cli first with `xtask build-cli`\ncargo xtask test-integration\n\n# filtered integration tests\ncargo xtask test-integration -- outgoing_udp --nocapture\n\n# unit tests\ncargo xtask test-ut\n\n# filtered unit tests\ncargo xtask test-ut -- resolve_url_happy_path -- --nocapture\n```\n\n### Styling\n\n```bash\n# Formatting\ncargo fmt\n```\n\n## Simplicity and Reuse\n\nmirrord is actively maintained by dozens of people, it is not a greenfield project. When adding or changing things,\nmaximize simplicity. Reuse existing abstractions and codepaths instead of introducing new ones. Every new path is\nsomething someone has to understand, maintain, and keep compatible.\n\n## Comments and Documentation\n\nDon't write comments explaining what code does, the code should speak for itself. Instead, focus on _why_ something\nexists: doc comments that explain the problem a function or struct solves and how it fits into the bigger picture are\nfar more valuable than ones that restate the type signature. Module-level doc comments that give a high-level overview\nof what a file is responsible for are also very helpful, as they give readers the context to understand the code below.\nmirrord has a lot of moving pieces and stability is critical, so document tricky or non-obvious behavior clearly.\n\nWrite comments for readers of the resulting code, not reviewers of the patch. Comments must stand alone after merge and\ndescribe the current behavior, intent, invariant, or non-obvious tradeoff. Don't narrate the edit or use patch-relative\nlanguage such as `the existing implementation`, `the new approach`, `now`, `previously`, `this change`, or\n`we added/removed`. Include historical context only when it is necessary to explain why the current code deliberately\ndiffers from an otherwise-obvious alternative.\n\n## Style Guideline\n\n- Keep imports at file top (no function-local `use`).\n- Prefer `to_owned` for `&str` → `String`.\n- Always use `foo.rs` instead of `foo/mod.rs` for module roots.\n- Run styling commands after every edit.\n"},"files":{"AGENTS.md":"# mirrord\n\n## Overview\n\nmirrord is a tool that lets developers run local processes in the context of their Kubernetes cloud environment.\n\n### Core Crates\n\n- `mirrord-layer`: gets loaded into the user's process via `LD_PRELOAD`/`DYLD_INSERT_LIBRARIES`. Intercepts libc\ncalls (files, networking, DNS, env, ...) and turns them into protocol messages sent to the intproxy.\n- `mirrord-intproxy`: a local process spawned by the CLI that bridges N layers and 1 agent. Matches requests to\nresponses, handles reconnects, and routes messages to the right feature proxy.\n- `mirrord-agent`: the in-cluster component of mirrord. Runs in the target pods' context and network namespace. Does the\nactual I/O work requested by the layers.\n- `mirrord-protocol`: defines the shared messages (`ClientMessage`, `DaemonMessage`) sent between layer/intproxy/agent.\n- `mirrord-config`: config types and validation. Used by the CLI and layer to decide what features are enabled and what\ntarget to use.\n- `mirrord`: the CLI that resolves configuration, creates or connects to the agent, starts the intproxy, and launches\nthe user's local process with the mirrord layer loaded.\n\n## Command Reference\n\n### Compiling\n\n```bash\n# check the entire workspace at once\n# always use when a change spans multiple crates instead of checking each crate individually\ncargo clippy --all-targets --all-features --keep-going -- --deny warnings\n\n# check a specific crate\n# the agent is linux only\ncargo clippy -p mirrord-agent --target x86_64-unknown-linux-gnu --keep-going -- --deny warnings\n\n# layer and cli bundled with the new layer\n# use only when a fresh mirrord + layer binary is needed for testing\ncargo xtask build-cli\n```\n\nUse `--keep-going` to surface all errors at once. Use `clippy` instead of `check` to lint + compile simultaneously.\n\n### Testing\n\n```bash\n# integration tests\n# requires building the cli first with `xtask build-cli`\ncargo xtask test-integration\n\n# filtered integration tests\ncargo xtask test-integration -- outgoing_udp --nocapture\n\n# unit tests\ncargo xtask test-ut\n\n# filtered unit tests\ncargo xtask test-ut -- resolve_url_happy_path -- --nocapture\n```\n\n### Styling\n\n```bash\n# Formatting\ncargo fmt\n```\n\n## Simplicity and Reuse\n\nmirrord is actively maintained by dozens of people, it is not a greenfield project. When adding or changing things,\nmaximize simplicity. Reuse existing abstractions and codepaths instead of introducing new ones. Every new path is\nsomething someone has to understand, maintain, and keep compatible.\n\n## Comments and Documentation\n\nDon't write comments explaining what code does, the code should speak for itself. Instead, focus on _why_ something\nexists: doc comments that explain the problem a function or struct solves and how it fits into the bigger picture are\nfar more valuable than ones that restate the type signature. Module-level doc comments that give a high-level overview\nof what a file is responsible for are also very helpful, as they give readers the context to understand the code below.\nmirrord has a lot of moving pieces and stability is critical, so document tricky or non-obvious behavior clearly.\n\nWrite comments for readers of the resulting code, not reviewers of the patch. Comments must stand alone after merge and\ndescribe the current behavior, intent, invariant, or non-obvious tradeoff. Don't narrate the edit or use patch-relative\nlanguage such as `the existing implementation`, `the new approach`, `now`, `previously`, `this change`, or\n`we added/removed`. Include historical context only when it is necessary to explain why the current code deliberately\ndiffers from an otherwise-obvious alternative.\n\n## Style Guideline\n\n- Keep imports at file top (no function-local `use`).\n- Prefer `to_owned` for `&str` → `String`.\n- Always use `foo.rs` instead of `foo/mod.rs` for module roots.\n- Run styling commands after every edit.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# mirrord\n\n## Overview\n\nmirrord is a tool that lets developers run local processes in the context of their Kubernetes cloud environment.\n\n### Core Crates\n\n- `mirrord-layer`: gets loaded into the user's process via `LD_PRELOAD`/`DYLD_INSERT_LIBRARIES`. Intercepts libc\ncalls (files, networking, DNS, env, ...) and turns them into protocol messages sent to the intproxy.\n- `mirrord-intproxy`: a local process spawned by the CLI that bridges N layers and 1 agent. Matches requests to\nresponses, handles reconnects, and routes messages to the right feature proxy.\n- `mirrord-agent`: the in-cluster component of mirrord. Runs in the target pods' context and network namespace. Does the\nactual I/O work requested by the layers.\n- `mirrord-protocol`: defines the shared messages (`ClientMessage`, `DaemonMessage`) sent between layer/intproxy/agent.\n- `mirrord-config`: config types and validation. Used by the CLI and layer to decide what features are enabled and what\ntarget to use.\n- `mirrord`: the CLI that resolves configuration, creates or connects to the agent, starts the intproxy, and launches\nthe user's local process with the mirrord layer loaded.\n\n## Command Reference\n\n### Compiling\n\n```bash\n# check the entire workspace at once\n# always use when a change spans multiple crates instead of checking each crate individually\ncargo clippy --all-targets --all-features --keep-going -- --deny warnings\n\n# check a specific crate\n# the agent is linux only\ncargo clippy -p mirrord-agent --target x86_64-unknown-linux-gnu --keep-going -- --deny warnings\n\n# layer and cli bundled with the new layer\n# use only when a fresh mirrord + layer binary is needed for testing\ncargo xtask build-cli\n```\n\nUse `--keep-going` to surface all errors at once. Use `clippy` instead of `check` to lint + compile simultaneously.\n\n### Testing\n\n```bash\n# integration tests\n# requires building the cli first with `xtask build-cli`\ncargo xtask test-integration\n\n# filtered integration tests\ncargo xtask test-integration -- outgoing_udp --nocapture\n\n# unit tests\ncargo xtask test-ut\n\n# filtered unit tests\ncargo xtask test-ut -- resolve_url_happy_path -- --nocapture\n```\n\n### Styling\n\n```bash\n# Formatting\ncargo fmt\n```\n\n## Simplicity and Reuse\n\nmirrord is actively maintained by dozens of people, it is not a greenfield project. When adding or changing things,\nmaximize simplicity. Reuse existing abstractions and codepaths instead of introducing new ones. Every new path is\nsomething someone has to understand, maintain, and keep compatible.\n\n## Comments and Documentation\n\nDon't write comments explaining what code does, the code should speak for itself. Instead, focus on _why_ something\nexists: doc comments that explain the problem a function or struct solves and how it fits into the bigger picture are\nfar more valuable than ones that restate the type signature. Module-level doc comments that give a high-level overview\nof what a file is responsible for are also very helpful, as they give readers the context to understand the code below.\nmirrord has a lot of moving pieces and stability is critical, so document tricky or non-obvious behavior clearly.\n\nWrite comments for readers of the resulting code, not reviewers of the patch. Comments must stand alone after merge and\ndescribe the current behavior, intent, invariant, or non-obvious tradeoff. Don't narrate the edit or use patch-relative\nlanguage such as `the existing implementation`, `the new approach`, `now`, `previously`, `this change`, or\n`we added/removed`. Include historical context only when it is necessary to explain why the current code deliberately\ndiffers from an otherwise-obvious alternative.\n\n## Style Guideline\n\n- Keep imports at file top (no function-local `use`).\n- Prefer `to_owned` for `&str` → `String`.\n- Always use `foo.rs` instead of `foo/mod.rs` for module roots.\n- Run styling commands after every edit.\n","category":"root","tokens":968}]}