From ed47dbd59ba7f62c6c6a67fc44550f906d314c14 Mon Sep 17 00:00:00 2001 From: Justin Diclemente <69400476+logohere@users.noreply.github.com> Date: Tue, 1 Sep 2026 19:08:48 -0400 Subject: [PATCH 1/2] docs: expand Leash site from current product surface --- leash.html | 103 ++++++++++++++++++++++++++++------------------------- 1 file changed, 55 insertions(+), 48 deletions(-) diff --git a/leash.html b/leash.html index 8367f6e..072d096 100644 --- a/leash.html +++ b/leash.html @@ -4,16 +4,16 @@
Safe robot control from the CLI, HTTP, and MCP.
-Leash is an open-source Rust runtime for controlling robots. Start in simulation. Connect real hardware when you're ready.
+Leash is an open-source Rust runtime for controlling robots from humans, apps, and AI agents. Start in simulation, replay real runs, then connect hardware behind the same safety boundary.
cargo install leash-harness
leash run sim-http
-
Then, in another terminal:
-leash health --url http://127.0.0.1:8000
curl -s http://127.0.0.1:8000/telemetry | jq
-
-This runs entirely in simulation. It cannot move physical hardware.
- +This is simulation only. It cannot move physical hardware.
For MCP:
-leash run sim-mcp
-Leash owns the final command sent to the robot.
- -A planner, ROS 2 node, model, app, or agent can ask Leash to do something. It cannot write to the motors directly.
- -Physical motion is off by default. Hardware commands pass authorization, approval, sensor freshness, deadman, collision, distance-limit, Stop, and E-Stop checks before reaching the robot.
- -Agents can request motion. Leash decides whether motion is allowed.
- -Leash can keep agent sessions across runs and expose bounded robot capabilities through the same safety path used by other clients.
+leash agent run "summarize current health" --session demo
+leash agent sessions list
+leash agent headful --no-open
+The browser console is useful for observing sessions and invoking safe capabilities. Physical motion still has to pass the normal Leash checks.
+ +Human / app / agent → CLI / HTTP / MCP → Leash → safety checks → robot adapter
+Planners, models, ROS 2 nodes, CUDA jobs, and web apps can provide requests or evidence. Leash remains the final writer to the robot.
+ +Goal-level navigation lets clients submit bounded missions without owning a motor refresh loop. The API supports goal submission, status, cancellation, and verified stop.
+Sensor-processing jobs can run asynchronously on CPU or qualified CUDA. GPU output is advisory; parity and fallback keep CPU behavior authoritative.
++ Navigation API · + Compute API +
-The current hardware implementation is the Waveshare UGV stack.
+Leash owns the final command sent to the robot.
+Physical motion is off by default. Depending on the operation, Leash checks caller authorization, pilot ownership, approval, deadman state, sensor freshness, localization quality, collision clearance, speed and distance limits, Stop, and the latching E-stop.
+If a required condition disappears during motion, the operation is cancelled and zero output is commanded. Simulation and replay never actuate hardware.
-Robot-specific device paths, calibration, deployment, rollback, and field evidence stay outside the reusable core. ROS 2 can provide mapping, localization, and navigation data; Leash remains the motor owner.
+The current hardware implementation is the Waveshare UGV stack. Robot-specific adapters, calibration, deployment, rollback, field proof, and physical-navigation tooling stay outside the reusable core crates.
+ROS 2 can supply mapping, localization, and planning data through a provider boundary. Leash keeps final actuation authority.
git clone https://github.com/specdog/leash.git
cd leash
npm ci
cargo build
cargo run -- run sim-http
-
-Work from current main on a branch. Keep hardware changes feature-gated and test the simulation path without hardware.
Work from current main on a branch. Keep hardware changes feature-gated and use simulation for normal development.
Start with the repository's AGENTS.md. Project structure is available through the compiled DotDog graph:
- +Start with AGENTS.md. Project structure is available through the compiled DotDog graph:
npm ci
npx dotdog serve
-
Agents query specs/leash/leash.dag. Humans own the .dog source.
GitHub · README · + Demo · Docs · Issues
From 76d0bb08cf8ee499a238a59a69de751ccec774fa Mon Sep 17 00:00:00 2001 From: Justin Diclemente <69400476+logohere@users.noreply.github.com> Date: Tue, 1 Sep 2026 19:10:47 -0400 Subject: [PATCH 2/2] docs: tighten Leash landing page --- leash.html | 103 ++++++++++++++++++----------------------------------- 1 file changed, 34 insertions(+), 69 deletions(-) diff --git a/leash.html b/leash.html index 072d096..af918db 100644 --- a/leash.html +++ b/leash.html @@ -4,27 +4,24 @@Safe robot control from the CLI, HTTP, and MCP.
-Leash is an open-source Rust runtime for controlling robots from humans, apps, and AI agents. Start in simulation, replay real runs, then connect hardware behind the same safety boundary.
+Open-source Rust runtime for simulation, replay, agents, navigation, ROS 2, CUDA, and real robots — with one safety boundary before motion.
cargo install leash-harness
leash run sim-http
-Then, in another terminal:
leash health --url http://127.0.0.1:8000
curl -s http://127.0.0.1:8000/telemetry | jq
-This is simulation only. It cannot move physical hardware.
-For MCP:
-leash run sim-mcp
+This runs entirely in simulation. No robot required.
-Leash can keep agent sessions across runs and expose bounded robot capabilities through the same safety path used by other clients.
-leash agent run "summarize current health" --session demo
-leash agent sessions list
-leash agent headful --no-open
-The browser console is useful for observing sessions and invoking safe capabilities. Physical motion still has to pass the normal Leash checks.
+Leash owns the final command sent to the robot. Agents, planners, ROS 2 nodes, CUDA jobs, and apps can request work or provide evidence; they do not become another motor writer.
+Physical motion is off by default and passes authorization, approval, freshness, deadman, collision, distance, Stop, and E-stop checks. Simulation and replay never actuate hardware.
-Human / app / agent → CLI / HTTP / MCP → Leash → safety checks → robot adapter
-Planners, models, ROS 2 nodes, CUDA jobs, and web apps can provide requests or evidence. Leash remains the final writer to the robot.
- -Goal-level navigation lets clients submit bounded missions without owning a motor refresh loop. The API supports goal submission, status, cancellation, and verified stop.
-Sensor-processing jobs can run asynchronously on CPU or qualified CUDA. GPU output is advisory; parity and fallback keep CPU behavior authoritative.
-- Navigation API · - Compute API -
- -Leash owns the final command sent to the robot.
-Physical motion is off by default. Depending on the operation, Leash checks caller authorization, pilot ownership, approval, deadman state, sensor freshness, localization quality, collision clearance, speed and distance limits, Stop, and the latching E-stop.
-If a required condition disappears during motion, the operation is cancelled and zero output is commanded. Simulation and replay never actuate hardware.
- -The current hardware implementation is the Waveshare UGV stack. Robot-specific adapters, calibration, deployment, rollback, field proof, and physical-navigation tooling stay outside the reusable core crates.
-ROS 2 can supply mapping, localization, and planning data through a provider boundary. Leash keeps final actuation authority.
+git clone https://github.com/specdog/leash.git
cd leash
npm ci
cargo build
cargo run -- run sim-http
-Work from current main on a branch. Keep hardware changes feature-gated and use simulation for normal development.
Start with AGENTS.md. Project structure is available through the compiled DotDog graph:
-npm ci
-npx dotdog serve
-Agents query specs/leash/leash.dag. Humans own the .dog source.
MIT licensed. Human contributors start with CONTRIBUTING.md; coding agents start with AGENTS.md.
-