The receipt comes back, and the memory writes come later

Two loops, and only one of them is synchronous

The architecture is summarised as two loops running in opposite directions. The outbound one is Intent, Body, Capability, Authority, Action. The inbound one is Observation, Verification, Episode, Memory, Skill, Evolution. The asymmetry is deliberate and stated in the README: the execution path is governed by the runtime, while practice, memory, and skill evolution are asynchronous, evaluated consumers of that evidence rather than substitutes for it. Changes still require validation and promotion, so a skill that learned something cannot rewrite the runtime on its own. The canonical action path is spelled out in order: bind intent to a body and capability, apply policy and authorization, arbitrate physical resources, dispatch to a driver, and return an evidence-bearing ExecutionReceipt. The receipt is the contract, and everything on the learning side is downstream of it. The client list above the runtime is deliberately broad, naming Codex, Claude Code, Hermes, OpenClaw, VLAs, and the Native Agent, while the list below it covers ROS 2, MCP, simulators, vendor SDKs, and robots. Bidirectional is the word the README uses, and the loop labels show what each direction actually carries rather than implying a single request and response.

Two install forms, and the pip one still needs Node on the host

The quick start is three commands:

curl -sSL https://rosclaw.io/get | bash
rosclaw firstboot --yes --profile offline --no-telemetry
rosclaw doctor --level verified

The note underneath is the part worth reading. There are two install forms, and they are not equivalent. The offline tar bundle is fully self-contained, carrying a Node runtime, npm production dependencies, and Python wheels. The PyPI wheel, installed with `pip install rosclaw`, ships the prebuilt agent JavaScript and the Python runtime but requires Node.js 22.19 or newer on the host, does not bundle a Node runtime, and downloads nothing at chat time. Rendering additionally needs a GL backend, with OSMesa, EGL, or Xvfb named as the options, and `rosclaw doctor` reports the exact OS packages for your platform. The README is blunt about the limit: it does not claim zero system dependencies after a pip install for this release form.

The status table is a boundary, not a roadmap

The README introduces its capability table with a warning that it is the capability boundary and not a roadmap disguised as completed work, and the labels in the Status column are what make that credible. They are Simulation verified, Component verified, Component and system verified, Fixture only, Experimental, and Developer-observed with revalidation pending. Each label carries an evidence sentence rather than a percentage. The first row, UR5e tabletop reach, is Simulation verified, and its evidence says real MuJoCo execution and receipt verification are system-tested, that local Codex CLI black-box runs discovered all 22 MCP tools, and that rosclawd blocks unauthorized REAL actions without hardware dispatch, with independent H5 acceptance still pending. So the row tells you what was tested, by whom, and what has not been. That granularity is unusual in a project README and is the single most useful thing in it.

Fixture-only rows declare themselves invalid for safety

Two rows in that table are about safety, and both stop short in ways the wording makes explicit. Mock Sense, mock Providers, and fixture Drivers are marked Fixture only, with the evidence field saying they produce explicit FIXTURE and SYNTHETIC data only and are never valid for safety or real acceptance. That is a self-imposed limitation rather than a claim, and it means anything you test with those parts has proved nothing about the physical path. The E-Stop control path is Component verified, and its evidence lists fan-out, timeout, partial acknowledgement, idempotency, latch, and physical-observation fields, then ends with no independent physical-stop verification. Read together, those two rows say the emergency stop logic is exercised in tests and has not been confirmed to stop a real machine by anyone other than the team that wrote it.

The one hardware row reads like a dated lab notebook

The RH56 LeRobot single-step loop row is the longest entry in the table and the most revealing, because it is a status report rather than a summary. It is marked Developer-observed with revalidation pending. Real SerialModbusTransport, shadow reads, graded REAL actions, and fault injection were all developer-observed, and a developer agent black-box covering discovery, SHADOW, unauthorized REAL, and the dataset workflow passed on 2026-07-22 with zero forbidden actions. Loopback fault tests then proved something uncomfortable: a target-near readback is DELIVERY_INFERRED rather than a protocol acknowledgement. On 2026-07-23 the full v1.0.1 chain was revalidated on the physical right hand rh56_right_01, with 6 of 6 register widths declared, measured-envelope calibration, 1000 shadow steps, graded REAL noop, micro, motion, gesture and OK all passing with OK at 10 of 10, fault injection 8 of 8, and one permitted noop step executed for real. Independent revalidation remains open.

A signed supply chain with an empty trust store

The Generic Hub asset supply chain row is Component and system verified, and the evidence list is long: complete payload hashes, detached Ed25519 signatures, independently scoped trust roots, canonical-reference and copied-manifest binding, target re-verification, bounded extraction, explicit install permissions, owner-only local credentials, and the local and file registry lifecycle. Then the sentence that matters: the packaged trust store is empty, and the public registry, TUF rollback protection, OS keyring integration, and builder-attestation verification all remain pending. So the verification machinery is described as system-tested while the roots it would verify against ship blank. The same pattern repeats elsewhere, with the capability-only App runtime tested locally while the remote App registry and independent agent acceptance are pending, and the RealSense perception-only path marked Experimental with no independently verified hardware capture run in this repository.

Dependency pins with the reasoning left in the file

The package metadata is unusually commented, and the comments explain why each bound moved. NumPy is capped below 2.5 because NumPy 2.5 type stubs require Python 3.12 syntax while the project and its CI still support 3.11 and run mypy with python_version set to 3.11. MuJoCo is held to 3.13.x and above because the qualified harness runtime is 3.13.x, released on 2026-09-08, and the legacy minimum no longer accepts unqualified 3.0 through 3.12. The mujoco.sysid toolbox closure is declared explicitly rather than left transitive, so colorama, tabulate, and scipy appear in the dependency list. The interpreter range is >=3.11 and <3.14, with classifiers for 3.11, 3.12, and 3.13, and the project is marked Development Status :: 3 - Alpha. Several of these comments are written in Chinese, which tells you something about where the engineering decisions are being argued out.

The container says v1.0.0 while the package says 1.3.0

The Compose stack runs one service built from the Dockerfile, published as rosclaw/rosclaw:v1.0.0, restarting unless stopped, with two named data volumes for practice and runtime data and three read-only bind mounts for models, skills, and rosclaw.yaml. The environment sets a robot id defaulting to rosclaw_bot, a safety level defaulting to MODERATE, an API key that defaults to empty, and unbuffered Python. Port 8080 is published, the command is run with the robot id, and the healthcheck imports the package and prints its version every 30 seconds with a 10 second timeout and 3 retries. The Dockerfile starts from python:3.11-slim, installs gcc, g++, libgl1-mesa-glx, libglib2.0-0, and libgomp1, then drops to a non-root rosclaw user. The version strings do not line up: the image label, the Compose image tag, and the Dockerfile comments all say 1.0.0 while pyproject declares 1.3.0. The same split shows in the tree, where a packages/ directory and a src/ directory both sit at the root next to a top-level rosclaw/ directory, e-urdf-zoo/ for robot descriptions, worker_plugins/, validation/, benchmarks/, and experiments/, and three separate Compose files for the default stack and for ROS 1 and ROS 2 test runs.

Editorial conclusion

ROSClaw suits teams doing physical AI who need a governed path from an agent to hardware and who will read the maturity table before trusting any row in it. It does not suit anyone who needs a working safety case today, because the E-Stop path is component verified with no independent physical-stop verification and the packaged trust store ships empty. Before installing, read INSTALL.md and take the offline tar bundle rather than the PyPI wheel unless the host already carries Node 22.19 or newer, then run rosclaw doctor.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes