diff --git a/docs/getting_started/installation.md b/docs/getting_started/installation.md
index 3e8cb02..75b991d 100644
--- a/docs/getting_started/installation.md
+++ b/docs/getting_started/installation.md
@@ -78,12 +78,12 @@ platforms = ["linux-64", "linux-aarch64"]
 # ROS 2 CLI + launch + runtime (ros2 launch / run / pkg). The bar packages
 # declare their library deps but not the CLI tooling, so pull a ROS base
 # yourself. Use ros-jazzy-desktop instead if you want the RViz-based
-# `view` / `viz` launches.
+# viewers (`hc viz urdf`, `view_lite.launch.py`).
 ros-jazzy-ros-base = "*"
 # The whole Lite bringup: humanoid_controllers (ONNX-enabled), humanoid_control_msgs,
 # lite_description, humanoid_devices_robstride, humanoid_drivers_socketcan, humanoid_control_common, humanoid_control_policy.
 ros-jazzy-humanoid-control-bringup-lite = "*"
-# Optional: the `hc` diagnostic CLI (run via `ros2 run humanoid_control_cli hc ...`).
+# Optional: the `hc` toolbox CLI — lands on PATH (hc viz / hc bus ping / ...).
 ros-jazzy-humanoid-control-cli = "*"
 ```
 
@@ -113,14 +113,14 @@ pixi run ros2 launch humanoid_bringup_lite real.launch.py
 RoboStack ROS core — no build step. Everything the packages ship (launch files,
 URDFs, meshes, controller YAMLs, console executables) lands on the ament index,
 so `ros2 launch …` / `ros2 run …` work inside `pixi shell` (or via
-`pixi run …`). The `hc` diagnostic CLI is a package executable — run it as
-`ros2 run humanoid_control_cli hc …`.
+`pixi run …`). The `hc` toolbox CLI installs a `bin/` shim, so `hc` itself
+is on `PATH` inside `pixi shell` (or via `pixi run -- hc …`).
 
 ```sh
 pixi shell
 ros2 pkg list | grep '^humanoid_control_'                              # the humanoid_control_* packages you pulled in
 ros2 launch humanoid_bringup_lite real.launch.py --show-args   # dry-parse the launch (no hardware)
-ros2 run humanoid_control_cli hc bus discover --iface can0 --scan-to 32   # read-only CAN scan, e.g.
+hc bus discover --iface can0 --scan-to 32              # read-only CAN scan, e.g.
 ```
 
 :::note[What the channel ships today]
@@ -186,7 +186,7 @@ reproducible solve.
 ### 3. Pull third-party sources
 
 ```sh
-vcs import --input src/humanoid_control/bar.repos src
+pixi run setup    # = vcs import --skip-existing --input src/humanoid_control/humanoid_control.repos src
 ```
 
 This brings in the three `mujoco_*` packages and `ethercat_driver_ros2` under
@@ -207,16 +207,23 @@ on the host, then drop the `--packages-skip-regex` filter.
 
 ```sh
 pixi shell
-colcon build --symlink-install --packages-skip-regex 'ethercat.*|humanoid_bringup_prime'
+colcon build --packages-skip-regex 'ethercat.*|humanoid_bringup_prime'
 ```
 
-`pixi shell` sources the conda env and `humanoid_control_ws/install/setup.bash` once it
-exists, so `ros2`, `colcon`, and every console script land on `PATH`. The build
+(Equivalently, from any terminal: `pixi run build` — it chains the cached
+`setup` from step 3, so steps 3–4 are really one command. `--symlink-install`
+and the compile-commands export come from `config/colcon-defaults.yaml` via
+`COLCON_DEFAULTS_FILE`, so the manual invocation behaves identically.)
+
+`pixi shell` sources the conda env and (via `scripts/activate.sh`) the
+`install/setup.sh` overlay once it exists, so `ros2`, `colcon`, `hc`, and every
+console script land on `PATH`. The build
 covers the Lite path (every Humanoid Control + Pianist package plus the three `mujoco_*`
 deps). `--symlink-install` means edits to launch / config / Python files are
 picked up without rebuilding. After the first successful build the install
 overlay is on `AMENT_PREFIX_PATH` automatically — pixi's `[activation]` block
-re-sources `install/setup.bash` whenever you enter `pixi shell`.
+re-sources the overlay whenever you enter `pixi shell`. Then run
+`pixi run doctor` to verify the workspace end-to-end.
 
 ### 5. Sanity-check
 
@@ -262,6 +269,6 @@ RViz, run a mock bringup, then run the same controllers against MuJoCo physics.
 (The MuJoCo steps need the source build above, until `mujoco_*` lands in the
 channel.)
 
-If you'd like to know what the `pixi run launch-mujoco` / `pixi run build`
-shortcuts you'll see in some scripts and READMEs actually do, jump to
+If you'd like to know what the `pixi run sim` / `pixi run build` commands
+you'll see in scripts and READMEs actually do, jump to
 [How-to → Workspace shortcuts with pixi](../how_to/use_pixi_tasks.md).
diff --git a/docs/getting_started/lite_101.md b/docs/getting_started/lite_101.md
index 1693f94..10c1384 100644
--- a/docs/getting_started/lite_101.md
+++ b/docs/getting_started/lite_101.md
@@ -23,8 +23,8 @@ cd humanoid_control_ws && pixi shell
 ```
 
 Stay in that shell for the rest of the lesson. If you ever want
-shorter shortcuts (e.g. `pixi run launch-mujoco`) the equivalent
-aliases live in [How-to → Workspace shortcuts with
+shorter shortcuts (e.g. `pixi run sim`) the equivalent
+tasks live in [How-to → Workspace shortcuts with
 pixi](../how_to/use_pixi_tasks.md); the canonical `ros2 launch`
 form is what's shown below.
 
diff --git a/docs/how_to/promote_python_to_cpp.md b/docs/how_to/promote_python_to_cpp.md
index 22e932b..9efa2fb 100644
--- a/docs/how_to/promote_python_to_cpp.md
+++ b/docs/how_to/promote_python_to_cpp.md
@@ -65,7 +65,7 @@ First, in one terminal, bring up the controller_manager (sim or
 hardware):
 
 ```bash
-pixi run launch-mujoco        # or: pixi run launch-real
+pixi run sim                  # or: pixi run real
 ```
 
 Then, in a second terminal (inside `pixi shell`), prepare + load the
diff --git a/docs/how_to/use_pixi_tasks.md b/docs/how_to/use_pixi_tasks.md
index 12d67b3..f21425a 100644
--- a/docs/how_to/use_pixi_tasks.md
+++ b/docs/how_to/use_pixi_tasks.md
@@ -1,140 +1,182 @@
 ---
 id: use_pixi_tasks
-title: Workspace shortcuts with pixi
-sidebar_label: Workspace shortcuts (pixi)
+title: Workspace commands (pixi tasks + hc)
+sidebar_label: Workspace commands (pixi + hc)
 ---
 
-# Workspace shortcuts with pixi
+# Workspace commands (pixi tasks + hc)
 
 The rest of this site documents commands in canonical `ros2 launch …` /
 `ros2 run …` form. Those work everywhere — Jetson, workstation, CI.
 
-The workspace also ships a thin **alias layer** in
-`humanoid_control_ws/pixi.toml` so you can shorten the most common command lines
-to `pixi run <name>`. This page documents that layer end-to-end:
-what each alias maps to, when to reach for it, and how to add your
-own.
-
-`pixi.toml` lives at the **workspace level** (`humanoid_control_ws/pixi.toml`),
-*not* inside `Humanoid Control` or `pianist_ros2`. That's intentional — the
-file pins ROS 2 Jazzy, the colcon toolchain, every Python dep, and
-the activation script that auto-sources `install/setup.bash`. Those
-are workspace concerns; both `Humanoid Control` and `pianist_ros2` consume them.
-
-:::tip[Why have aliases at all]
-A single `pixi run launch-mujoco` is shorter than
-`ros2 launch humanoid_bringup_lite mujoco.launch.py`, but the bigger win
-is that **every alias runs inside the pixi-managed environment** —
-ROS 2 Jazzy, the colcon overlay, the visualiser PyPI deps, and the
-right `RCUTILS_CONSOLE_OUTPUT_FORMAT` are all sourced automatically.
-Calling `pixi run …` from a vanilla terminal works without an
-explicit `pixi shell` first.
+On top of that, every Humanoid Control workspace exposes the same
+standardized command interface, organized in **three levels**:
+
+| Level | Commands | What it is |
+|---|---|---|
+| **1 — lifecycle tasks** | `setup` `build` `test` `clean` `doctor` | pixi tasks with reserved names *and* meanings — identical in every workspace |
+| **2 — product toolbox** | `hc bus` / `hc motor` / `hc viz` / `hc calibrate` | a packaged CLI on `PATH` — ships with the code, identical everywhere the stack is installed |
+| **3 — scenario tasks** | `sim` `real` `policy` (+ variants) | pixi tasks with reserved *names* — each workspace defines their scope |
+
+Discovery is built in: bare `pixi run` (or `pixi task list`) prints the
+workspace's task menu with descriptions, and bare `hc` prints the
+toolbox menu. This page explains each level and how to extend them.
+
+:::tip[Why this layer exists]
+`pixi run build` is shorter than the colcon invocation it wraps, but the
+bigger win is that **every task runs inside the pixi-managed
+environment** — ROS 2 Jazzy, the colcon overlay, the visualiser PyPI
+deps, and the right `RCUTILS_CONSOLE_OUTPUT_FORMAT` are sourced
+automatically. Calling `pixi run …` from a vanilla terminal works
+without an explicit `pixi shell` first.
 :::
 
-## Build / setup aliases
+## Day one: one command
 
-| Alias | Equivalent | Why |
-|---|---|---|
-| `pixi install` | (the pixi install itself) | Solve and materialise the conda + PyPI env into `humanoid_control_ws/.pixi/`. Run once per clone and after every `pixi.toml` change. |
-| `pixi shell` | (the pixi shell itself) | Drop into an interactive shell with the env active. Equivalent to `source install/setup.bash` over a sourced ROS 2 Jazzy install. |
-| `pixi run setup` | `vcs import --input src/humanoid_control/bar.repos src` | Clone the third-party `mujoco_*` + `ethercat_driver_ros2` sources listed in `bar.repos` into `src/`. |
-| `pixi run build` | `colcon build --symlink-install --packages-skip-regex 'ethercat.*\|humanoid_bringup_prime'` | Build the Lite path (skips the EtherCAT-linked Prime lane that has no conda recipe). |
-| `pixi run build-all` | `colcon build --symlink-install` | Same, but includes `humanoid_bringup_prime` and `ethercat_driver_ros2`. Requires `libethercat` installed on the host. |
-| `pixi run build-pkg <name>` | `colcon build --symlink-install --packages-select <name>` | Targeted rebuild of one package — fastest edit-loop while iterating. |
-| `pixi run test` | `colcon test --packages-skip-regex 'ethercat.*\|humanoid_bringup_prime\|mujoco_.*' --ctest-args -LE linter --event-handlers console_cohesion-` | Run humanoid_control-owned tests; skips the vendored `mujoco_*` packages and the CMake-registered linters (which RoboStack ships at newer versions than apt-jazzy, so they'd diverge from the industrial_ci-on-Humanoid Control source of truth). |
-| `pixi run test-lint` | Same as `test`, but keeps the linters. | Use when you specifically want to see uncrustify / cpplint output locally. |
-| `pixi run test-results` | `colcon test-result --verbose` | Print the per-package test summary after `pixi run test`. |
-| `pixi run clean` | `rm -rf build install log` | Wipe the colcon overlay (leaves the source tree and `.pixi/` env alone). Handy after a package rename. |
-
-## Launch aliases — Humanoid Control
-
-Each alias just wraps a `ros2 launch <pkg> <file>` invocation; any
-extra arguments after the alias are forwarded unchanged.
-
-| Alias | Equivalent | Side |
-|---|---|---|
-| `pixi run view` | `ros2 launch humanoid_bringup_lite view_lite.launch.py` | dev — URDF inspector |
-| `pixi run launch-mujoco` | `ros2 launch humanoid_bringup_lite mujoco.launch.py` | dev — full Lite controller stack in MuJoCo |
-| `pixi run launch-real` | `ros2 launch humanoid_bringup_lite real.launch.py` | robot — real-hardware Lite bringup |
-| `pixi run launch-viz` | `ros2 launch humanoid_bringup_lite viz.launch.py` | host — live URDF + joint-state viewer (`viewer:=viser\|rerun`) |
-| `pixi run calibrate` | `ros2 launch humanoid_bringup_lite calibrate.launch.py` | dev — calibration bringup; writes `calibration.yaml` on Ctrl+C |
-| `pixi run launch-policy` | `ros2 launch humanoid_control_policy lite_policy.launch.py` | robot — runs `prepare` (resolve ONNX, motion → `.mcap`) then loads the in-process `rl_policy_controller`. Pass `checkpoint_file:=` or `wandb_run_path:=`. |
-| `pixi run launch-policy-tracking` | `… lite_policy.launch.py` | robot — pass-through alias (back-compat shortcut) |
+```sh
+pixi run build     # installs the locked env, imports sources, builds
+pixi run doctor    # verifies the result; prints what to fix if unhealthy
+```
 
-### Per-tool / CLI aliases
+`pixi run` self-heals the environment (like `uv run`), and `build`
+chains the `setup` task, which is idempotent and **cached**: it only
+re-executes when `humanoid_control.repos` changes or after a `clean`, so
+daily builds never touch the network. Nothing else auto-chains — in
+particular, **no scenario task ever triggers a build** (a hardware
+bringup must never start with a surprise rebuild; `doctor` is the
+staleness check).
 
-| Alias | Equivalent |
-|---|---|
-| `pixi run hc …` | `bar …` (the `humanoid_control_cli` console script) |
-| `pixi run robstride-ping` | `ros2 run humanoid_devices_robstride robstride_ping` |
-| `pixi run robstride-discover` | `ros2 run humanoid_devices_robstride robstride_discover` |
-| `pixi run mit-slider-gui` | `ros2 run humanoid_devices_robstride mit_slider_gui` |
-| `pixi run rerun-viz` | `ros2 run humanoid_bringup_lite rerun_viz` |
-| `pixi run viser-viz` | `ros2 run humanoid_bringup_lite viser_viz` |
+## Level 1 — lifecycle tasks
 
-## Launch aliases — pianist_ros2
+Reserved names with identical semantics in every workspace
+(`humanoid_control_ws`, the `*-Deployment` repos):
 
-Piano-task aliases wrap launches that live in the sibling
-`pianist_ros2` repo (the alias still lives at the workspace level —
-`pianist_ros2` only ships the launches and Python entry points).
+| Task | Meaning |
+|---|---|
+| `pixi run setup` | fetch/prepare sources beyond pixi itself (`vcs import --skip-existing`); idempotent, cached |
+| `pixi run build` | build the workspace's default lane (chains `setup`) |
+| `pixi run test` | run the workspace's tests (linters excluded — see `lint`) |
+| `pixi run clean` | wipe `build/ install/ log/`; never touches `src/` or `.pixi/` |
+| `pixi run doctor` | health check: root, env, `/opt/ros` contamination, sources, overlay |
+
+Workspaces add local extras at the same level — in `humanoid_control_ws`:
+`build-all` (include the EtherCAT/Prime lane), `test-result`, `lint`
+(the version-stable ament linters), `check` (`test` + `lint`, the local
+pre-push gate), `gen-dds`, `test-dds`. Colcon *style* flags
+(`--symlink-install`, compile-commands) live in
+`config/colcon-defaults.yaml` via `COLCON_DEFAULTS_FILE`, so a manual
+`colcon build` inside `pixi shell` behaves identically to
+`pixi run build`.
+
+## Level 2 — the `hc` toolbox
+
+Diagnostics, viewers, and calibration ship **with the code** as the
+`hc` CLI (`humanoid_control_cli`), not as per-workspace tasks — it is on
+`PATH` in any environment that has the stack, whether built from source
+or installed from the `berkeley-humanoids` binary channel:
+
+| Command | What it does |
+|---|---|
+| `hc bus ping` | single-actuator GetDeviceId ping (no Enable) |
+| `hc bus discover` | scan a CAN bus for Robstride device ids |
+| `hc bus probe` / `hc bus probe-report` | link RTT/jitter probe + report |
+| `hc motor slider` | live MIT-mode slider GUI against one motor |
+| `hc viz` | live state viewer of a running robot (`viewer:=viser` default, `viewer:=rerun`) |
+| `hc viz urdf` | static URDF/kinematic inspector — sliders + RViz, no robot needed |
+| `hc calibrate` | calibration bringup (writes `calibration.yaml`) |
+
+Every verb `execvp`s into the canonical `ros2 run` / `ros2 launch`
+command, so signals and trailing arguments pass straight through
+(`hc bus ping --iface can0 --id 11`). Run `hc help` for the menu.
+
+The scope rule: `hc` carries only commands whose **meaning is invariant
+across workspaces**. Anything whose scope depends on the workspace
+(`sim`, `real`, `policy`) is a task, level 3.
+
+## Level 3 — scenario tasks
+
+Reserved *names*; each workspace defines their scope. Grammar:
+`scenario[-qualifier]`, **at most one qualifier**, where the
+unqualified name is the workspace's default target. The qualifier
+encodes only the *primary* task variant; every secondary parameter
+(robot, backend, checkpoint, scene, …) stays a ROS launch argument:
 
-| Alias | Equivalent | Side |
-|---|---|---|
-| `pixi run launch-mujoco-piano` | `ros2 launch pianist_bringup mujoco.launch.py` | dev — composes Lite + piano scene in MuJoCo |
-| `pixi run launch-policy-piano` | `ros2 launch pianist_policy piano_policy.launch.py` | robot — runs `prepare` (song → key-state `.mcap`) then loads the in-process `rl_policy_controller`. Pass `checkpoint_file:=` or `wandb_run_path:=`. |
+```sh
+pixi run sim-piano robot:=prime policy:=latest    # right
+pixi run sim-prime-piano-latest                   # wrong — name explosion
+```
+
+In `humanoid_control_ws` (scope = the base control stack; unqualified =
+Lite):
 
-The USB-MIDI driver launch doesn't have a dedicated alias — invoke it
-as `ros2 launch pianist_policy midi_keyboard_driver.launch.py` (or
-add an alias yourself, see below).
+| Task | Wraps |
+|---|---|
+| `pixi run sim` | `ros2 launch humanoid_bringup_lite mujoco.launch.py` |
+| `pixi run real` | `ros2 launch humanoid_bringup_lite real.launch.py` |
+| `pixi run sim-prime` / `real-prime` | the `humanoid_bringup_prime` equivalents |
+| `pixi run sim-piano` | `ros2 launch pianist_bringup mujoco.launch.py` |
+| `pixi run policy` | `ros2 launch humanoid_control_policy lite_policy.launch.py` |
+| `pixi run policy-piano` | `ros2 launch pianist_policy piano_policy.launch.py` |
+
+In a deployment workspace (e.g.
+[Lite-Deployment](https://github.com/Berkeley-Humanoids/Lite-Deployment)),
+`sim` / `real` mean **the full task stack** — bringup plus policy in one
+command — because that is the workspace's reason to exist. The task
+`description` always states the scope; `pixi task list` shows it.
 
 ## Forwarding arguments
 
-`pixi run <alias> arg1 arg2 …` forwards the trailing args to the
-underlying command verbatim, so launch-file overrides work the same
-way they do under raw `ros2 launch`:
+Scenario tasks are thin, argument-less wrappers, so trailing launch
+arguments forward verbatim, the same way they do under raw
+`ros2 launch`:
 
 ```sh
-pixi run launch-real enable_gamepad:=false
-pixi run launch-real joy_dev:=/dev/input/js1
-pixi run launch-viz  viewer:=rerun
-pixi run launch-policy checkpoint_file:=$HOME/model.onnx
-pixi run launch-policy-piano wandb_run_path:=entity/project/run-id
+pixi run real enable_gamepad:=false
+pixi run real hardware_config:=$HOME/lite_hardware.jetson.yaml
+pixi run policy checkpoint_file:=$HOME/model.onnx
+pixi run policy-piano wandb_run_path:=entity/project/run-id
 ```
 
-## Adding a new alias
-
-Edit `humanoid_control_ws/pixi.toml`'s `[tasks]` block — that's the only file you
-need to touch:
+## Adding a new command
+
+Decision rule, in order:
+
+1. **Invariant meaning everywhere** (a diagnostic, viewer, calibration
+   tool) — add an `hc` verb in `humanoid_control_cli`, never a task.
+2. **Scenario or workspace-local script** — add a task in that
+   workspace's `pixi.toml`, using the reserved scenario vocabulary
+   where it applies (`sim`, `real`, `policy`, plus at most one
+   `-qualifier` for the primary variant; secondary parameters stay
+   launch args), free kebab-case otherwise. Give it a `description` —
+   `pixi task list` is the menu.
+3. **Operates on the workspace** (fetch, build, verify) — lifecycle
+   task, universal names only.
+4. **Needs root or mutates host state** (CAN buses, kernel) — a script
+   under `scripts/`, run explicitly with `sudo`, never a task.
+5. **Rarely used** — no alias at all; document the canonical
+   `ros2 …` command.
 
 ```toml
-[tasks]
-my-thing = "ros2 launch my_pkg my_launch.py"
+[tasks.my-scenario]
+cmd = "ros2 launch my_pkg my_launch.py"
+description = "One line explaining scope and key launch args"
 ```
 
-Then `pixi run my-thing` works immediately; no rebuild needed.
-
-If the alias should live next to the launch file conceptually
-(e.g. it's a piano-specific helper), the convention today is to
-still register it at the workspace level — `Humanoid Control` and
-`pianist_ros2` are pure ROS 2 source trees and don't try to expose
-a workspace-shell-shortcut layer of their own.
-
 ## Tradeoffs vs. plain `ros2 launch`
 
-When to use the aliases:
+When to use the tasks and `hc`:
 
 - One-off interactive bringups where you'll type the command often.
-- Operator runbooks — `pixi run launch-real` reads more cleanly
-  than the full launch path.
-- CI scripts that need the pixi-managed env (the alias inherits it
+- Operator runbooks — `pixi run real` reads more cleanly than the full
+  launch path.
+- CI scripts that need the pixi-managed env (a task inherits it
   automatically, no `pixi shell` wrapping needed).
 
 When to reach for plain `ros2 launch …`:
 
-- Inside a sourced `pixi shell` — the alias adds nothing here, and
-  the canonical form is what you'll see in launch-file docstrings
-  and in this site.
+- Inside a sourced `pixi shell` — the canonical form is what launch-file
+  docstrings and this site document.
 - When porting commands into another shell, an SSH cheatsheet, or a
   service unit on a machine that doesn't have pixi installed.
-- When the surface you're documenting is the launch file itself
-  (the alias is a workspace-level shortcut, not a launch feature).
+- When the surface you're documenting is the launch file itself (the
+  task is a workspace-level shortcut, not a launch feature).
diff --git a/docs/reference/launch_args.md b/docs/reference/launch_args.md
index c7f324e..68a58f1 100644
--- a/docs/reference/launch_args.md
+++ b/docs/reference/launch_args.md
@@ -165,8 +165,8 @@ in their own repos and register their own launch (see
 
 ## `humanoid_control_policy/launch/lite_tracking.launch.py` (alias)
 
-Thin pass-through wrapper around `lite_policy.launch.py`, kept for the
-`launch-policy-tracking` pixi alias and existing scripts.
+Thin pass-through wrapper around `lite_policy.launch.py`, kept for
+existing scripts that reference it by name.
 
 ## `pianist_policy/launch/piano_policy.launch.py`
 
diff --git a/docs/reference/packages.md b/docs/reference/packages.md
index 8810101..44733cd 100644
--- a/docs/reference/packages.md
+++ b/docs/reference/packages.md
@@ -198,13 +198,16 @@ See [Controllers reference](controllers.md).
 
 ### `humanoid_control_cli`
 
-The unified verb/noun CLI surface (`hc bus ping`, `hc bus discover`,
-`hc motor slider`, `hc viz rerun`, `hc viz viser`). An ament_python
-package that thin-wraps the underlying executables shipped by
-`humanoid_devices_robstride` and `humanoid_bringup_lite`. Invoke as `bar <verb> <noun> …`
-once `install/setup.bash` is sourced. (`pixi run hc …` is the
-workspace-level shortcut — see
-[Workspace shortcuts with pixi](../how_to/use_pixi_tasks.md).)
+The packaged product toolbox: a unified verb/noun CLI surface
+(`hc bus ping`, `hc bus discover`, `hc motor slider`, `hc viz`,
+`hc viz urdf`, `hc calibrate`). An ament_python package that thin-wraps
+the underlying executables shipped by `humanoid_devices_robstride` and
+`humanoid_bringup_lite`, and installs a `bin/` shim so `hc` is on `PATH`
+in any sourced overlay or conda env — invoke it directly once the
+workspace env is active. Scope: only verbs whose meaning is invariant
+across workspaces; scenario commands (`sim`, `real`, `policy`) are pixi
+tasks in each workspace — see
+[Workspace commands](../how_to/use_pixi_tasks.md).)
 
 ### `humanoid_control_policy`
 
diff --git a/docs/reference/quick_reference.md b/docs/reference/quick_reference.md
index ef2bb78..fc8f1c8 100644
--- a/docs/reference/quick_reference.md
+++ b/docs/reference/quick_reference.md
@@ -12,9 +12,9 @@ Every link points at the page with the full details.
 
 All commands below assume you've entered the workspace env (e.g.
 `cd humanoid_control_ws && pixi shell`) so `ros2`, `colcon`, and the Humanoid Control console
-scripts are on `PATH`. Looking for one-line aliases (`pixi run
-launch-mujoco`, `pixi run build`, …)?  See
-[How-to → Workspace shortcuts with pixi](../how_to/use_pixi_tasks.md).
+scripts are on `PATH`. Looking for the workspace tasks (`pixi run sim`,
+`pixi run build`, …) or the `hc` toolbox?  See
+[How-to → Workspace commands](../how_to/use_pixi_tasks.md).
 
 ## Launch invocations
 
diff --git a/docs/tutorials/tracking_policy.md b/docs/tutorials/tracking_policy.md
index 446ce3c..cda6c3f 100644
--- a/docs/tutorials/tracking_policy.md
+++ b/docs/tutorials/tracking_policy.md
@@ -129,7 +129,7 @@ ros2 launch humanoid_control_policy lite_policy.launch.py \
 
 The task family is selected by the ONNX `task_type` metadata — there is
 no `task:=` argument. (`lite_tracking.launch.py` is kept as a thin
-pass-through alias for the `launch-policy-tracking` pixi task.)
+pass-through alias for existing scripts that reference it by name.)
 
 What happens behind the scenes: