mirurobotics · ben-miru · Mar 23, 2026 · Mar 23, 2026 · Mar 23, 2026
diff --git a/.github/workflows/lint.yml b/.github/workflows/lint.yml
@@ -11,6 +11,11 @@ jobs:
       - name: Check out repository
         uses: actions/checkout@v5
 
+      - name: Set up Go
+        uses: actions/setup-go@v5
+        with:
+          go-version-file: tools/lint/go.mod
+
       - name: Set up pnpm
         uses: pnpm/action-setup@v4
         with:

diff --git a/.gitignore b/.gitignore
@@ -13,4 +13,7 @@ images/
 videos/
 changelog/
 
-node_modules/
+node_modules/
+
+# lint compiled binary
+tools/lint/lint
diff --git a/docs/admin/users/overview.mdx b/docs/admin/users/overview.mdx
@@ -79,6 +79,6 @@
 | `suspended` | User's access was revoked by an admin          |
 | `left`      | User has left the workspace                    |
 
-Only `active` users can log in and access workspace resources. `suspended` and `left` users exist solely for auditing purposes--they cannot log in to the workspace or access any resources.
+Only `active` users can log in and access workspace resources. `suspended` and `left` users exist solely for auditing purposes—they cannot log in to the workspace or access any resources.
 
 Users who have been suspended or left can be reinvited to the workspace at any time by an admin via [invites](/docs/admin/users/invites#send-an-invite).
diff --git a/docs/changelogs/agent.mdx b/docs/changelogs/agent.mdx
@@ -1,14 +1,14 @@
 ---
 title: "Agent"
 mode: "center"
 description: "Changelog and migration steps for the Miru Agent"
 ---

 # v0.7.0

 *March 13, 2026*

 `v0.7.0` upgrades the Miru Agent to Device API [v0.2.0](/docs/changelogs/device-api#v0-2-0), adding deployment-pipeline visibility for on-device applications and improving deployment reliability under transient failures.

 [Device API migration guide »](/docs/changelogs/device-api#v0-2-0)

@@ -18,19 +18,19 @@
 
 ## Features
 
-- Deployments are guaranteed to be atomic--all config instances for a deployment are written to the filesystem simultaneously or none of them are
+- Deployments are guaranteed to be atomic—all config instances for a deployment are written to the filesystem simultaneously or none of them are
 - The agent now explicitly tracks `deployed_at` and `archived_at` timestamps on device when deployments are applied
 - Config instances deployed to the device's file system are now identical (indents, spacing, etc.) to config instances edited in the config editor
 
 ## Improvements

 - The agent immediately retries transient network connection errors three times before entering a cooldown period
 - Improved config instance caching logic to reduce network calls during sync cycles

 ## Fixes

 - Fixed deployment retry logic to eagerly retry failed deployments instead of waiting for the polling interval to expire (occasionally leaving deployments stuck in a `queued` state)
 - Fixed deployment cooldown handling so retry windows are reported and cleared correctly
 - JWT tokens are now redacted from debug outputs

 ---
@@ -65,7 +65,7 @@

 ## Features

 - Poor connectivity installations of the Miru Agent are now supported

 ---


diff --git a/docs/developers/agent/architecture.mdx b/docs/developers/agent/architecture.mdx
@@ -2,11 +2,11 @@
 title: 'Architecture'
 ---

 The Miru Agent is a background service that keeps your device's configurations in sync with the Miru control plane. This page explains how the agent communicates with the control plane, how deployments reach your device, and what to expect during normal operation, failures, and restarts.

 ## Communication Protocols

 The Miru Agent communicates with the Miru control plane through outbound-only channels. All traffic is initiated by the agent—no inbound ports need to be opened on the device.

 ```mermaid
 flowchart BT
@@ -23,7 +23,7 @@

 ### HTTPS

 HTTPS delivers the bulk of the functionality between the agent and the control plane.  The agent makes REST API calls to the Miru control plane for pulling deployments/configurations, pushing status reports, and managing authentication tokens.

 ### MQTT over TLS

@@ -33,9 +33,9 @@
 
 ## Sync cycle
 
-At its core, the agent is built around a **sync** cycle--the process of reconciling the device's local state with the control plane's state.
+At its core, the agent is built around a **sync** cycle—the process of reconciling the device's local state with the control plane's state.
 
 When the agent performs a sync cycle, it communicates directly with the Miru control plane over HTTPS. MQTT is not used at all in this process.
 
 During a sync cycle, the agent:

@@ -98,13 +98,13 @@

 As a fallback to the above triggers, the agent regularly checks that the local state has been synced within some polling interval. If the local state has not been synced within that interval, the agent triggers a sync cycle for itself.

 **4. Restart (systemd)**

 As a final fallback, the agent performs an initial sync cycle on startup. If encountering real-time sync issues with the agent, we recommend [restarting](/docs/developers/agent/commands#restart) the agent to manually trigger a sync cycle.

 ## Deployments

 Miru takes a declarative approach to deployments. Each deployment has a [target state](/docs/learn/deployments#target-status) set by the control plane (what should happen) and an [activity state](/docs/learn/deployments#activity-status) tracked by the agent (what has happened). 

 During each sync, the agent compares these two states and determines the appropriate action to transition a deployment from its current state to its target state.

@@ -112,15 +112,15 @@

 ### Atomicity

 Miru deployments are **atomic**. That is, when a new deployment replaces an existing one, either all of the new deployment's config instances are written to the filesystem or none of them are. 

 It is not possible for some of the new deployment's config instances to be written to the file system and others to be skipped.

 ### Failure and retry

 If a deployment fails (for example, due to spotty network connectivity), the agent does not immediately retry. Instead, it enters a cooldown period that grows exponentially with each consecutive failure. This prevents the agent from repeatedly attempting a broken deployment and consuming resources.

 Once the cooldown expires, the agent retries the deployment on the next sync. If the deployment eventually succeeds, the retry state resets and the agent resumes normal operation.

 ### Offline resilience


diff --git a/docs/developers/agent/commands.mdx b/docs/developers/agent/commands.mdx
@@ -2,9 +2,9 @@
 title: 'Commands'
 ---

 The Miru Agent does not (currently) provide a command line interface. However, the agent can be managed using standard `systemd` commands and other standard Linux tools.

 The [Miru CLI](/docs/developers/cli/overview) is only for managing Miru resources from your development machine's terminal. Please do not attempt to use the `miru` command to manage the agent.

 ## Version

@@ -16,7 +16,7 @@

 ## Logs

 The Miru Agent logs are accessible via [`journalctl`](https://www.freedesktop.org/software/systemd/man/journalctl.html), the standard tool for viewing `systemd` service logs.

 ### View all

@@ -70,13 +70,13 @@
 ```

 <Tip>
  Combine flags for more targeted output. For example, `journalctl -u miru -f -n 50 --no-pager` will tail the last 50 lines and then follow new entries in real-time.
 </Tip>


 ## Systemd

 The Miru Agent runs as a [`systemd`](https://en.wikipedia.org/wiki/Systemd) service named `miru`, allowing you to manage the service using standard `systemctl` commands.

 You can find the agent's `systemd` service files on your file system at the following paths:

@@ -124,7 +124,7 @@
 
 ### Stop
 
-`stop` stops the agent while leaving its state intact. Stopping the agent does not [disable](/docs/developers/agent/commands#disable) the agent--it will still automatically start on next system boot.
+`stop` stops the agent while leaving its state intact. Stopping the agent does not [disable](/docs/developers/agent/commands#disable) the agent—it will still automatically start on next system boot.
 
 Note that stopping the agent will prevent any new deployments from reaching the device until the agent is started again.
 
@@ -153,7 +153,7 @@
 
 Disabling the agent prevents it from starting automatically on boot. 
 
-This does not immediately [stop](/docs/developers/agent/commands#stop) the agent--it will still run if it is currently running. However, it will not be able to start on next system boot.
+This does not immediately [stop](/docs/developers/agent/commands#stop) the agent—it will still run if it is currently running. However, it will not be able to start on next system boot.
 
 ```bash
 systemctl disable miru
@@ -163,7 +163,7 @@
 
 Enabling the agent allows it to start automatically on boot. This is the default behavior after installation and only needs to be done if the agent has been [disabled](/docs/developers/agent/commands#disable).
 
-Enabling the agent will not immediately start it--it will still need to be [started](/docs/developers/agent/commands#start) manually.
+Enabling the agent will not immediately start it—it will still need to be [started](/docs/developers/agent/commands#start) manually.
 
 ```bash
 systemctl enable miru

diff --git a/docs/developers/agent/security.mdx b/docs/developers/agent/security.mdx
@@ -2,7 +2,7 @@
 title: 'Security'
 ---

 The Miru Agent is designed to run with minimal privileges and a restricted system footprint. This page describes the agent's authentication model, authorizations, and the security measures applied at the process, filesystem, network, and credential layers.

 ## Authentication

@@ -10,7 +10,7 @@

 1. The agent receives a short-lived activation token as part of the [provisioning](/docs/learn/devices/provision) process (either from the dashboard or an API key)
 2. The agent generates a 4096-bit RSA key pair on the device
 3. The agent sends the public key to the Miru control plane with its activation token
 4. The control plane verifies the activation token, stores the public key, and registers the device

 ```mermaid
@@ -32,7 +32,7 @@

 ### Token lifecycle

 After activation, the agent authenticates API requests using short-lived JSON Web Tokens (JWTs). The process for obtaining a token works as follows:

 1. The agent prepares a set of claims including its device ID, a unique nonce, and a short expiration window (a few minutes)
 2. The agent signs these claims with its private RSA key
@@ -65,12 +65,12 @@

 | File | Permissions | Access |
 |------|------------|--------|
 | Private key | `0600` | Owner (miru) read/write only |
 | Public key | `0640` | Owner read/write, group read-only |

 All credential files are stored under `/var/lib/miru/auth/`, owned by `miru:miru`. The private key never leaves the device—it is used locally to sign token requests but is never transmitted over the network.

 Sensitive values are handled in memory using a secrecy library that minimizes exposure and zeroizes data when it is no longer needed. Tokens are redacted in log output to prevent accidental credential leakage through logs.

 ## Authorizations

@@ -90,7 +90,7 @@

 This prevents lateral access between devices. Even if two devices run the same agent version, each device is isolated to its own control-plane view and assigned configuration state.

 ## Process sandboxing

 The agent runs as a [systemd](https://en.wikipedia.org/wiki/Systemd) service with extensive hardening directives that restrict what the process can access, even if the application code is compromised. 

@@ -102,7 +102,7 @@

 **No privilege escalation**

 `NoNewPrivileges` is enabled, preventing the process from gaining additional privileges through setuid binaries or other mechanisms.

 **Filesystem restrictions**

@@ -118,7 +118,7 @@

 **Kernel isolation**

 The agent cannot load kernel modules, modify kernel tunables (`/proc/sys`, `/sys`), or alter control groups. Other processes are hidden from the agent's view of `/proc`.

 **Device restrictions**

@@ -126,11 +126,11 @@

 **Network restrictions**

 The agent can only create Unix domain sockets and IPv4/IPv6 connections. All other socket types (Netlink, packet sockets, etc.) are blocked.

 ## Transport security

 All communication between the agent and the Miru control plane is encrypted in transit:

 - **HTTPS** — REST API calls use HTTPS with TLS certificate validation
 - **MQTT over TLS** — the persistent MQTT connection uses TLS on port 8883 (the standard MQTT over TLS port)
@@ -143,7 +143,7 @@
 
 ## Local API access control
 
-The agent's local REST API is exposed through a Unix domain socket, not a TCP port. It is not possible to access the agent's local API over a network--it is only accessible from processes running on the same device as the agent.
+The agent's local REST API is exposed through a Unix domain socket, not a TCP port. It is not possible to access the agent's local API over a network—it is only accessible from processes running on the same device as the agent.
 
 Access is controlled through filesystem permissions:
 

diff --git a/docs/developers/agent/versions.mdx b/docs/developers/agent/versions.mdx
@@ -6,13 +6,13 @@
 import { LinkNewTab } from '/snippets/components/link.jsx';
 import { CardNewTab } from '/snippets/components/card.jsx';
 
 The Miru Agent follows [semantic versioning](https://semver.org/) for its releases. 
 
-Currently, the Miru Agent is still in beta, signified by the `v0` prefix for its releases. There is no established release cadence for the Miru Agent--features are simply released as soon as they are ready.
+Currently, the Miru Agent is still in beta, signified by the `v0` prefix for its releases. There is no established release cadence for the Miru Agent—features are simply released as soon as they are ready.
 
 ## Supported versions
 
 Below are the Miru Agent's versions and their support status

 | Version     |   Released   |        Status       |
 |-------------|--------------|---------------------|
@@ -22,7 +22,7 @@
 | `v0.4.x`    | 2025-08-18   | <EndOfLifeBadge />  |


 You can find the Miru Agent's changelog and the full list of releases by following the links below.

 <Columns cols={2}>

@@ -32,7 +32,7 @@
  icon="scroll-text"
  arrow
 >
  Release notes for each Miru Agent release.
 </CardNewTab>

 <Card
@@ -40,7 +40,7 @@
  icon="github"
  href="https://github.com/mirurobotics/agent/releases"
 >
  Full list of Miru Agent releases on GitHub.
 </Card>

 </Columns>
@@ -69,7 +69,7 @@

 ## Support policy

 Miru provides three levels of support for the Miru Agent

 - Supported
 - Deprecated
@@ -84,15 +84,15 @@
 When a new agent version is released, previous versions may enter a deprecation period. During this period:

 - The deprecated agent continues to function normally
 - No new features or non-critical bug fixes will be backported
 - Security patches may still be applied at Miru's discretion

 ### End of life

 After the deprecation period, an agent version reaches **end-of-life**. End-of-life agents may lose server compatibility and should not be used. For example, the Miru backend may stop supporting the protocol version they use, causing syncs to fail.

 ### Deprecation notice

 Since the Miru Agent is still in beta, a fixed support schedule for beta releases is not established. 

 Nonetheless, we are committed to ensuring that all users are migrated to a supported version before sunsetting an agent version. Reasonable notice will be provided before deprecating and sunsetting any agent versions.
diff --git a/docs/developers/device-api/overview.mdx b/docs/developers/device-api/overview.mdx
@@ -4,11 +4,11 @@

 import DeviceAPICard from '/snippets/references/device-api/card.mdx';
 
 The Miru Device API is a REST API for programmatically interacting with the Miru Agent from an application running on the same device as the agent.
 
-The Device API is not available over the internet--it is only accessible from the device running the Miru Agent. It is useful for manually refreshing configurations, retrieving current configurations, and checking agent status from applications running on your devices.
+The Device API is not available over the internet—it is only accessible from the device running the Miru Agent. It is useful for manually refreshing configurations, retrieving current configurations, and checking agent status from applications running on your devices.
 
 The Device API is distinct from the Miru [Platform API](/docs/developers/platform-api/overview), which is a REST API for backend services and CI/CD pipelines to manage Miru resources.
 
 To get started, continue to the [Authentication](/docs/developers/device-api/authn) page to learn how requests are authenticated. For a complete reference of all available API endpoints, visit the Device API Reference.


diff --git a/docs/developers/device-api/versioning.mdx b/docs/developers/device-api/versioning.mdx
@@ -11,7 +11,7 @@
 
 The Device API adheres to [semantic versioning](https://semver.org/), which was chosen so that on-device applications can easily determine API version compatibility.
 
-The Device API is currently in beta, signified by the `v0` prefix. There is no established release cadence for the Device API--features are simply released as soon as they are ready.
+The Device API is currently in beta, signified by the `v0` prefix. There is no established release cadence for the Device API—features are simply released as soon as they are ready.
 
 ## URL format
 
@@ -19,9 +19,9 @@

 Beta releases use breaking change aliases that include the major and minor version numbers (e.g. `v0.2`, `v0.3`, etc.). Stable releases use breaking change aliases that include the major version number only (e.g. `v1`, `v2`, etc.).

 Miru uses stable URL version aliases so clients can target a compatibility track. Targeting a fully specified version (e.g. `v0.1.0`) is not supported.

 | Semver release line | Breaking change alias | URL format               |
 |---------------------|-----------------------|--------------------------|
 | `v0.1.x`            | `v1` (legacy)         | `http://localhost/v1/`   |
 | `v0.2.x`            | `v0.2`                | `http://localhost/v0.2/` |
@@ -34,7 +34,7 @@

 ## Agent compatibility matrix

 Each Miru Agent is compiled with a set of one or more API versions, which is documented in the following table:

 | Agent Version  | API Version(s) |
 |----------------|----------------|
@@ -48,9 +48,9 @@
 
 ## Supported versions
 
-The Device API does not have its own support policy--its support is inherited from the Miru Agent. 
+The Device API does not have its own support policy—its support is inherited from the Miru Agent. 
 
 If a supported Miru Agent uses an API version, that API version is supported. You can find the supported Miru Agent versions on the [Agent Versions](/docs/developers/agent/versions) page.
 
 Below is a list of the currently supported versions:

@@ -86,7 +86,7 @@
 
 After **stable** (`v1.0`+)
 - Major version bumps (e.g. `v1.x` to `v2.0`) may include breaking changes
-- Minor version bumps (e.g. `v1.0` to `v1.1`) are additive only--no breaking changes
+- Minor version bumps (e.g. `v1.0` to `v1.1`) are additive only—no breaking changes
 
 ### Breaking changes
 

diff --git a/docs/getting-started/quick-start/create-release.mdx b/docs/getting-started/quick-start/create-release.mdx
@@ -49,7 +49,7 @@

 ## Create the config types

 To be able to push the schemas to Miru, we must first create config types to house them. We'll start with the `Mobility` config type.

 Navigate to the [config types page](https://app.mirurobotics.com/configs).

@@ -63,7 +63,7 @@
   ![Miru UI screenshot](https://assets.mirurobotics.com/docs/v03/images/config-types/create-dialog.png)
 </Frame>
 
-The provided slug is a unique identifier for the config type--it's how the CLI determines which config type a schema belongs to. As such, config schemas _must_ be annotated with the slug of the config type to which they belong.
+The provided slug is a unique identifier for the config type—it's how the CLI determines which config type a schema belongs to. As such, config schemas _must_ be annotated with the slug of the config type to which they belong.
 
 <CodeGroup>
 
@@ -85,7 +85,7 @@

 ## Set up the CLI

 Next, we'll install the CLI—the primary method of creating releases in Miru.

 Creating releases via the CLI is a deliberate design choice. We believe a release's schemas should live in a Git repository. This allows them to be versioned alongside the code that uses them and encourages better software development practices.

@@ -101,7 +101,7 @@

 ## Create a release

 With the CLI setup, we are ready to create a release in Miru.

 Navigate to the root of the [getting-started](https://github.com/mirurobotics/getting-started) repository and create the release with a schema set of your choice.

@@ -168,7 +168,7 @@
  Git metadata is pulled from the local Git repository that the schemas are defined in.
 </Info>

 To view the release in Miru, navigate to the [releases page](https://app.mirurobotics.com/releases) and click into the release.

 <Frame>
  ![Miru UI screenshot](https://assets.mirurobotics.com/docs/v03/images/releases/page.png)

diff --git a/docs/learn/deployments.mdx b/docs/learn/deployments.mdx
@@ -115,7 +115,7 @@

 **Release Staging**

 Staging a deployment is the process of creating a new deployment in a release's [staging area](/docs/learn/releases/staging-area) to be deployed in the future. Staging is primarily used to rollout a new release, providing an unobtrusive place to create and review deployments before being deployed to devices.

 A release's staging area is also useful for batch operations. Deployments can be created, deployed, and archived in bulk, which helps manage large numbers of deployments at once.

@@ -167,13 +167,13 @@
 
 Once a deployment's target status has been set to `deployed`, it can never be set to `staged` again.  Similarly, once a deployment's target status has been set to `archived`, it can never be set to `deployed` again.
 
-This is intentional--deployments are one-time use. Once a deployment has been deployed, it cannot be redeployed. You must create a new deployment with identical content to roll back.
+This is intentional—deployments are one-time use. Once a deployment has been deployed, it cannot be redeployed. You must create a new deployment with identical content to roll back.
 
 ## Activity Status
 
 The activity status is the _last known_ state of a deployment.
 
-We use _the last known state_ intentionally -- poor network connectivity can prevent devices from immediately syncing their activity state with the cloud. In practice, this isn't too common. However, it's still a critical point to keep in mind.
+We use _the last known state_ intentionally—poor network connectivity can prevent devices from immediately syncing their activity state with the cloud. In practice, this isn't too common. However, it's still a critical point to keep in mind.
 
 There are five possible activity states for a deployment.
 
@@ -189,7 +189,7 @@

 When a deployment is [staged](/docs/learn/releases/staging-area) before being deployed, its lifecycle has two phases: a **review phase** and a **deployment phase**.

 During the review phase, a staged deployment may [drift](/docs/learn/releases/staging-area#deployment-drift) if the underlying release changes. A drifted deployment transitions to `drifted` and must either be restaged or archived.

 ```mermaid
 flowchart LR
@@ -234,7 +234,7 @@
 
 ## Error Status
 
-The error status is the _last known_ error state of a deployment. Again, we use _the last known state_ intentionally -- poor network connectivity can prevent devices from immediately syncing their error state to the cloud.
+The error status is the _last known_ error state of a deployment. Again, we use _the last known state_ intentionally—poor network connectivity can prevent devices from immediately syncing their error state to the cloud.
 
 The error status is independent of the activity and target statuses. The error status does not imply any particular activity or target state, and vice versa. The error status is only concerned with errors encountered during deployment.
 
@@ -267,7 +267,7 @@

 If the agent recovers the deployment from the error, the deployment transitions back to the `none` error state once the deployment's target status is reached.

 On the other hand, as long as the agent is unable to recover the deployment, the deployment remains in the `retrying` error state. The agent continually attempts to reach the deployment's target status, using exponential backoff to prevent resource throttling.

 If the deployment is stuck in the `retrying` error state, try replacing or archiving the deployment to allow the agent to start fresh.


diff --git a/docs/learn/devices/deployment-history.mdx b/docs/learn/devices/deployment-history.mdx
@@ -28,7 +28,7 @@ To view the details of any config instances in the deployment, click into the co
   ![Miru UI screenshot](https://assets.mirurobotics.com/docs/v03/images/deployments/deployed-panel:configurations.png)
 </Frame>
 
-The content tab shows the config instance's parameters , while the metadata tab contains audit information--the author, creation date, description, etc.
+The content tab shows the config instance's parameters , while the metadata tab contains audit information—the author, creation date, description, etc.
 
 <Tabs>
   <Tab title="Content">

diff --git a/docs/learn/devices/manage.mdx b/docs/learn/devices/manage.mdx
@@ -47,14 +47,14 @@

 ## Reactivate a device

 Reactivating a device is the process of reinstalling the Miru Agent on a device that was previously activated. Reactivating a device:

 1. Invalidates the device's current authentication session
 2. Creates a new authentication session for the device
 3. Resets the Miru Agent to a clean state
 4. Recreates the device's current deployments

 Reactivating a device resets the Miru Agent to a clean state while preserving the device's full deployment history.

 **Dashboard**

@@ -88,7 +88,7 @@
   ![Miru UI screenshot](https://assets.mirurobotics.com/docs/v03/images/devices/ellipses-dropdown.png)
 </Frame>
 
-A confirmation dialog will appear--click **Delete** to confirm.
+A confirmation dialog will appear—click **Delete** to confirm.
 
 <Frame>
   ![Miru UI screenshot](https://assets.mirurobotics.com/docs/v03/images/devices/delete-dialog.png)

diff --git a/docs/learn/devices/overview.mdx b/docs/learn/devices/overview.mdx
@@ -42,7 +42,7 @@

  <NullableBadge />

  The version of the Miru Agent running on the device.

  The agent version exists only if the device has a status of `online` or `offline`. If the device is `inactive` or `activating`, the agent version is `null`.

@@ -63,32 +63,32 @@
  Examples: `rls_123`
 </ParamField>

 ## Miru Agent

 Configurations are deployed to devices via the [Miru Agent](/docs/developers/agent/overview), a lightweight `systemd` service that runs on your devices, handling the deployment lifecycle of configurations.

 The Miru Agent offers the following functionality:

 - **Syncs configurations** from the cloud to the local filesystem in real-time
 - **Manages device state**, providing real-time updates of the device's status and the currently deployed configurations
 - [**Exposes a REST API**](/docs/developers/device-api/overview) over a Unix socket for programmatic access by applications running on the same machine

 <Note>
  The Miru Agent only supports Linux. Visit the [supported platforms](/docs/developers/agent/overview#supported-platforms) for a complete list of supported platforms.
 </Note>

 Read more about the agent in the [Miru Agent](/docs/developers/agent/overview) section.

 ## Status

 Devices leverage several states to track their registration and connectivity with the Miru servers.

 | Status       | Description                                                 |
 | ------------ | ----------------------------------------------------------- |
 | `inactive`   | The Miru Agent has not yet been installed and authenticated |
 | `activating` | The Miru Agent is registering itself with Miru's servers    |
 | `online`     | Device is currently connected to Miru's servers             |
 | `offline`    | Device has lost connection to Miru's servers                |

 ```mermaid
 flowchart LR
@@ -101,9 +101,9 @@
    D ---> C
 ```
 
 Devices begin in the `inactive` state. During the Miru Agent install process, devices briefly enter the `activating` state before transitioning to `online`.
 
-Once the Miru Agent has been activated on a device, the device remains `online` or `offline` for the remainder of its existence--devices don't transition back to `inactive` or `activating`.
+Once the Miru Agent has been activated on a device, the device remains `online` or `offline` for the remainder of its existence—devices don't transition back to `inactive` or `activating`.
 
 The only exception to this is when a device is [reactivated](/docs/learn/devices/manage#reactivate-a-device). During reactivation, devices briefly enter the `activating` state before transitioning back to `online`.
 

diff --git a/docs/learn/releases/deployment-history.mdx b/docs/learn/releases/deployment-history.mdx
@@ -28,7 +28,7 @@ To view the details of any config instances in the deployment, click into the co
   ![Miru UI screenshot](https://assets.mirurobotics.com/docs/v03/images/deployments/deployed-panel:configurations.png)
 </Frame>
 
-The content tab contains the config instance's parameters, while the metadata tab contains audit information--the author, creation date, description, etc.
+The content tab contains the config instance's parameters, while the metadata tab contains audit information—the author, creation date, description, etc.
 
 <Tabs>
   <Tab title="Content">

diff --git a/docs/learn/releases/staging-area.mdx b/docs/learn/releases/staging-area.mdx
@@ -9,7 +9,7 @@
 ## Overview

 The staging area for a release is where deployments are created in preparation for a
 future rollout. The staging area only contains staged deployments. Currently deployed
 and previously deployed deployments are not accessible in the staging area.

 Deployments in the staging area can be created freely _before_ being deployed to
@@ -64,7 +64,7 @@
 <Note>
  Some devices may be unavailable for selection. These devices are already running this
  release and cannot be staged from this flow. You can only stage deployments for 
  devices that are running a _different release_.
 </Note>

 After selecting a device, the release editor opens. The editor is pre-filled with the
@@ -89,7 +89,7 @@
  ![](https://assets.mirurobotics.com/docs/v03/images/releases/stage/stage-dialog.png)
 </Frame>

 Miru will return you to the staging area, where the new staged deployment appears in the
 list for the selected device.

 <Frame>
@@ -114,7 +114,7 @@
 </Frame>
 
 The content tab contains the config instance's parameters, while the metadata tab
-contains audit information--the author, creation date, description, etc.
+contains audit information—the author, creation date, description, etc.
 
 <Tabs>
   <Tab title="Content">
@@ -154,7 +154,7 @@
 A dialog will appear asking for a description. Enter a description, then click
 **Stage**.

 After staging, Miru returns you to the staging area, where the updated staged deployment
 appears in the list.

 ## Archive a deployment
@@ -173,7 +173,7 @@
   ![Miru UI screenshot](https://assets.mirurobotics.com/docs/v03/images/releases/stage/ellipses-dropdown:staged.png)
 </Frame>
 
-A confirmation dialog will appear--hit **Archive** to confirm.
+A confirmation dialog will appear—hit **Archive** to confirm.
 
 <Frame>
   ![Miru UI screenshot](https://assets.mirurobotics.com/docs/v03/images/releases/stage/archive-dialog:single.png)
@@ -194,7 +194,7 @@
   ![Miru UI screenshot](https://assets.mirurobotics.com/docs/v03/images/releases/stage/bulk-actions.png)
 </Frame>
 
-A confirmation dialog will appear--hit **Archive** to confirm.
+A confirmation dialog will appear—hit **Archive** to confirm.
 
 <Frame>
   ![Miru UI screenshot](https://assets.mirurobotics.com/docs/v03/images/releases/stage/archive-dialog:bulk.png)
@@ -234,13 +234,13 @@

 Consider the following example:

 ![Miru UI screenshot](https://assets.mirurobotics.com/docs/v03/images/deployments/deployment-drift.png)
 Our device is currently running deployment `DPL-Npfzv`, which adheres to release `v1.5`.
 Our device is about to be upgraded to release `v1.6` though, so we've staged deployment
 `DPL-Q4CeX` for the upcoming upgrade.
 
 However, before the upgrade occurs, our device receives some configuration updates on
-release `v1.5`--`DPL-Npfzv` is patched with `DPL-BFwc3`. Since it's often the case that
+release `v1.5`—`DPL-Npfzv` is patched with `DPL-BFwc3`. Since it's often the case that
 this patch also needs to be applied to the staged deployment `DPL-Q4CeX`, we say
 `DPL-Q4CeX` has _drifted_.
 
@@ -249,7 +249,7 @@
 staged deployment.

 The concept of deployment drift ensures that configuration changes aren't lost during
 migrations between releases, preventing misconfigurations.

 ## Review a deployment


diff --git a/docs/learn/schemas/overview.mdx b/docs/learn/schemas/overview.mdx
@@ -43,15 +43,15 @@

  The raw schema definition, written in the specified schema language.

  The exact contents of a schema file is preserved in Miru, including any comments, whitespace, and formatting.
 </ParamField>

 <ParamField path="digest" type="string">
  <ImmutableBadge />
 
   A hash of the canonicalized schema content.
 
-  Digests are computed by converting schemas to a canonical format--a format that ignores whitespace, comments, and other non-semantic differences--and then hashing the result. This is useful for comparing schemas and detecting duplicates.
+  Digests are computed by converting schemas to a canonical format—a format that ignores whitespace, comments, and other non-semantic differences—and then hashing the result. This is useful for comparing schemas and detecting duplicates.
 
   Examples: `sha256:45YeoJJ2btBnAKQztAEXEjHsqyyQfC1z1Mw3LLM4xMUy`
 </ParamField>
@@ -76,9 +76,9 @@
 
 ## Schema languages
 
-Config schemas are defined using a schema language--a formal language for describing the structure, constraints, and data types of a configuration.
+Config schemas are defined using a schema language—a formal language for describing the structure, constraints, and data types of a configuration.
 
 Miru supports:
 
 - [JSON Schema](https://json-schema.org/draft/2020-12) (draft 2020-12)
 - [CUE](https://cuelang.org/)
@@ -146,7 +146,7 @@
 - Names the available properties
 - Organizes the configuration structure, placing some properties at the root while nesting other properties into logical groups
 - Gives each property a type, such as `number`, `boolean`, etc.
-- Constrains the values of each property--minimums, maximums, enumerations, etc.
+- Constrains the values of each property—minimums, maximums, enumerations, etc.
 - Supplies default values to properties where appropriate
 
 Most of these constraints are optional, and many features of JSON Schema are omitted here, but this gives you a flavor of what schemas are capable of.
@@ -173,13 +173,13 @@

 This time, the config instance successfully validates against the schema and is deployed to the device.

 Although simple in concept, schemas are a powerful tool for preventing typos, misconfigurations, and other preventable errors.

 ## Empty schemas
 
 While schemas provide significant value in production deployments, defining one from scratch can be a considerable undertaking.
 
-Many teams find it best to begin with an empty schema--one that accepts any configuration--and gradually add constraints. This approach allows you to define the most highly valued constraints first and progressively transition to stricter and stricter schemas as needed.
+Many teams find it best to begin with an empty schema—one that accepts any configuration—and gradually add constraints. This approach allows you to define the most highly valued constraints first and progressively transition to stricter and stricter schemas as needed.
 
 Below are the empty schemas for JSON Schema and CUE, respectively.
 

diff --git a/scripts/lint.sh b/scripts/lint.sh
@@ -12,6 +12,11 @@ if ! command -v pnpm >/dev/null 2>&1; then
   exit 1
 fi
 
+if ! command -v go >/dev/null 2>&1; then
+  echo "go is required for MDX prose linting. Install Go and rerun ./scripts/lint.sh." >&2
+  exit 1
+fi
+
 cd "${repo_root}"
 
 collect_files() {
@@ -56,6 +61,10 @@ if [[ ${#openapi_targets[@]} -eq 0 ]]; then
   exit 1
 fi
 
+echo "== MDX Prose =="
+(cd "${repo_root}/tools/lint" && go build -o lint .)
+"${repo_root}/tools/lint/lint" "${mdx_targets[@]}"
+
 echo "== ESLint (MDX) =="
 pnpm exec eslint --max-warnings=0 "${mdx_targets[@]}"
 

diff --git a/snippets/definitions/release.mdx b/snippets/definitions/release.mdx
@@ -1,6 +1,6 @@
 A **release** is a version of software and its compatible config schemas.
 
-Within a fleet of robots, multiple software versions may be deployed -- each release defines which config schemas are valid for that version.
+Within a fleet of robots, multiple software versions may be deployed—each release defines which config schemas are valid for that version.
 
 For example, software release `v1.7.0` might specify the following schemas:
 

diff --git a/snippets/references/cli/releases/create/cue-packages.mdx b/snippets/references/cli/releases/create/cue-packages.mdx
@@ -1,4 +1,4 @@
 [CUE](/docs/learn/schemas/languages/cue) supports the concept of a [package](https://cuelang.org/docs/tour/packages/packages/)—a way to spread a schema's definition across multiple files. 

 For example, say we have a `communication` schema which contains the following files:

@@ -9,13 +9,13 @@
  <Tree.File name="main.cue" />
 </Tree.Folder>

 Each file defines a portion of the schema, which is then aggregated by the `main.cue` file to define the schema. Miru fully supports CUE packages, treating the `communication` directory as a single schema.

 **Identifying packages**
 
 The Miru CLI automatically identifies CUE packages for you when creating a release using the `package` clause at the top of each schema file (as described in the [CUE documentation](https://cuelang.org/docs/tour/packages/packages/)).
 
-You don't need to explicitly specify the package in the CLI command--just provide the path to the package directory or to the individual schema files within the package.
+You don't need to explicitly specify the package in the CLI command—just provide the path to the package directory or to the individual schema files within the package.
 
 **Annotations**
 

diff --git a/tools/lint/go.mod b/tools/lint/go.mod
@@ -0,0 +1,3 @@
+module github.com/mirurobotics/docs/tools/lint
+
+go 1.24
Original file line number	Diff line number	Diff line change
		@@ -0,0 +1,3 @@
		module github.com/mirurobotics/docs/tools/lint

		go 1.24