refresh sidebar, intro, dimOS branding

docs/.mintignore

@@ -1,2 +1,5 @@
 # Ignore dependency trees under the docs workspace (would otherwise be scanned as pages).
 node_modules/
+**/node_modules/**
+package-lock.json
+package.json

docs/capabilities/agents/index.md

@@ -1,7 +1,8 @@
 ---
 title: "Agents"
+sidebarTitle: "Overview"
 ---
-LLM agents run as native DimOS modules. They subscribe to camera, LiDAR, odometry, and spatial memory streams and they control the robot through skills.
+LLM agents run as native dimOS modules. They subscribe to camera, LiDAR, odometry, and spatial memory streams and they control the robot through skills.
 
 ## Architecture
 

docs/capabilities/manipulation/a1z.md

@@ -88,7 +88,7 @@ dimos hardware a1z doctor
 
 The A1Z has no brakes or hardware e-stop button; the PSU switch is the hardware
 kill switch. Support the arm and clear its workspace before starting or
-stopping DimOS. Disabling the motors makes the arm fall.
+stopping dimOS. Disabling the motors makes the arm fall.
 
 ```bash
 dimos run keyboard-teleop-a1z

docs/capabilities/manipulation/a750.md

@@ -32,7 +32,7 @@ Pro tip: run this in a separate terminal while plugging in the arm to verify tha
 dmesg -w
 ```
 
-If the device appears but DimOS gets a permission error when opening it, you may need to add yourself to the `dialout` group:
+If the device appears but dimOS gets a permission error when opening it, you may need to add yourself to the `dialout` group:
 
 ```bash
 sudo usermod -aG dialout "$USER"
@@ -97,10 +97,10 @@ It supports:
 | Joint position commands | Sends six joint positions plus a velocity ratio |
 | Enable/disable | Starts and stops the `a750_control` control loop |
 | Gripper reads/commands | Reads and commands gripper position in meters |
-| Cartesian hardware commands | Stubbed; Cartesian motion is handled through DimOS IK |
+| Cartesian hardware commands | Stubbed; Cartesian motion is handled through dimOS IK |
 | Force/torque reads | Not currently implemented |
 
-The `a750_control` package starts a separate thread with real-time priority for its hardware control loop. That loop sends commands and reads back joint state at 1 kHz. The DimOS `read_joint_positions`, `read_joint_velocities`, and `read_joint_efforts` calls return the most recent data cached by that loop rather than synchronously querying the robot, so returned joint data may be up to 1 ms stale. The USB connection also adds roughly 1 ms of latency.
+The `a750_control` package starts a separate thread with real-time priority for its hardware control loop. That loop sends commands and reads back joint state at 1 kHz. The dimOS `read_joint_positions`, `read_joint_velocities`, and `read_joint_efforts` calls return the most recent data cached by that loop rather than synchronously querying the robot, so returned joint data may be up to 1 ms stale. The USB connection also adds roughly 1 ms of latency.
 
 The adapter requires the optional manipulation dependency:
 
@@ -142,7 +142,7 @@ The A-750 teleop command uses the same keyboard controls as the other manipulato
 
 ## Known Limitations
 
-- Joint limits are currently approximate: `[-pi, pi]` for each arm joint, with max velocity `pi rad/s` in the DimOS adapter.
-- EEF twist commands are integrated and solved by the DimOS coordinator task, not by a native Cartesian mode in the hardware adapter.
+- Joint limits are currently approximate: `[-pi, pi]` for each arm joint, with max velocity `pi rad/s` in the dimOS adapter.
+- EEF twist commands are integrated and solved by the dimOS coordinator task, not by a native Cartesian mode in the hardware adapter.
 - Force/torque data is not exposed yet.
 - Real hardware mode depends on the external `a750_control` package and a reachable serial device.

docs/capabilities/manipulation/adding_a_custom_arm.md

@@ -1,11 +1,11 @@
 ---
 title: "How to Integrate a New Manipulator Arm"
 ---
-This guide walks through integrating a new robot arm with DimOS, from writing the hardware adapter to creating blueprints for planning and control.
+This guide walks through integrating a new robot arm with dimOS, from writing the hardware adapter to creating blueprints for planning and control.
 
 ## Architecture Overview
 
-DimOS uses a **Protocol-based adapter pattern** — no base class inheritance required. Your adapter wraps the vendor SDK and exposes a standard interface that the rest of the system consumes:
+dimOS uses a **Protocol-based adapter pattern** — no base class inheritance required. Your adapter wraps the vendor SDK and exposes a standard interface that the rest of the system consumes:
 
 ```
 ┌──────────────────────────────────────────────────────────────┐
@@ -72,7 +72,7 @@ Below is a complete annotated adapter. Implement each method by wrapping your ve
 """YourArm adapter — implements ManipulatorAdapter protocol.
 
 SDK Units: <describe your SDK's native units here>
-DimOS Units: angles=radians, distance=meters, velocity=rad/s
+dimOS Units: angles=radians, distance=meters, velocity=rad/s
 """
 
 from __future__ import annotations
@@ -177,7 +177,7 @@ class YourArmAdapter:
     def set_control_mode(self, mode: ControlMode) -> bool:
         """Set control mode.
 
-        Map DimOS ControlMode enum values to your SDK's mode codes.
+        Map dimOS ControlMode enum values to your SDK's mode codes.
         Return False for modes your arm doesn't support.
         """
         if not self._sdk:
@@ -389,7 +389,7 @@ print(adapter_registry.available())  # Should include "yourarm"
 
 ## Step 3: Create Your Robot Folder and Blueprints
 
-Each robot in DimOS gets its own folder under `dimos/robot/`. This is where you define all blueprints for your arm — coordinator, planning, perception, etc. This follows the same pattern as Unitree robots (`dimos/robot/unitree/`).
+Each robot in dimOS gets its own folder under `dimos/robot/`. This is where you define all blueprints for your arm — coordinator, planning, perception, etc. This follows the same pattern as Unitree robots (`dimos/robot/unitree/`).
 
 ### 3a. Create the robot directory
 
@@ -482,9 +482,9 @@ to your robot's own `blueprints.py`.
 Place your URDF/xacro files under LFS data so they can be resolved via `LfsPath`. `LfsPath` is a `Path` subclass that lazily downloads LFS data on first access — this avoids downloading at import time when the blueprint module is loaded.
 
 If the planning blueprint selects the RoboPlan TOPP-RA trajectory
-parametrizer, DimOS currently pins RoboPlan to `0.5.1`. Every movable joint in
+parametrizer, dimOS currently pins RoboPlan to `0.5.1`. Every movable joint in
 each selected planning group must provide finite, positive velocity limits.
-Authored extended acceleration limits take precedence; when absent, DimOS
+Authored extended acceleration limits take precedence; when absent, dimOS
 temporarily inserts a global `2.0 rad/s²` acceleration fallback during RoboPlan
 model composition:
 
@@ -503,9 +503,9 @@ model composition:
 
 RoboPlan loads both limits from its scene model. If either is absent, zero,
 negative, or non-finite, plan materialization fails before preview or execution
-and identifies the affected joint. DimOS does not substitute
+and identifies the affected joint. dimOS does not substitute
 `RobotModelConfig.max_velocity`, `velocity_limits`, or `max_acceleration` for
-this backend. Formal per-joint DimOS overrides will be added separately.
+this backend. Formal per-joint dimOS overrides will be added separately.
 
 ```python skip
 from dimos.utils.data import LfsPath

docs/capabilities/manipulation/index.md

@@ -117,7 +117,7 @@ request. For example, `planner.backend=roboplan` requires
 `world_backend=drake`.
 
 Trajectory parametrization is a separate startup choice. Joint-space planners
-normally return an untimed geometric path; DimOS accepts the plan only after
+normally return an untimed geometric path; dimOS accepts the plan only after
 the selected backend converts that path to a validated timed trajectory:
 
 ```bash
@@ -267,7 +267,7 @@ Safety behavior for unsupported RoboPlan features:
 - Planning-critical unsupported inputs fail loudly before planning. Examples
   include unsupported obstacle geometry, unavailable robot loading APIs, or
   unavailable collision query APIs. RoboPlan worlds generate a minimal SRDF from
-  the DimOS robot config, including configured collision-exclusion pairs.
+  the dimOS robot config, including configured collision-exclusion pairs.
 - Unverified non-critical query methods raise explicit `NotImplementedError`.
   In particular, signed minimum-distance semantics are not implemented for
   RoboPlan until a safe equivalent is verified.

docs/capabilities/manipulation/piper_integration.md

@@ -1,6 +1,6 @@
 ---
 title: "Piper Integration"
-description: "Connect and run a Piper arm with DimOS manipulation and teleoperation blueprints."
+description: "Connect and run a Piper arm with dimOS manipulation and teleoperation blueprints."
 ---
 
 ## Optional SLCAN setup
@@ -18,7 +18,7 @@ the Piper adapter already exposes a native SocketCAN interface.
 ## Bring up a native Piper CAN interface
 
 Piper uses SocketCAN at 1,000,000 bit/s. For the default vendor setup, use
-the DimOS CLI to configure an existing CAN interface and bring it up:
+the dimOS CLI to configure an existing CAN interface and bring it up:
 
 ```bash
 dimos piper can-activate can0

docs/capabilities/manipulation/planning_groups.md

@@ -1,4 +1,6 @@
-# Manipulation Planning Groups
+---
+title: "Planning Groups"
+---
 
 Planning groups are named, selectable kinematic chains used by manipulation
 planning. They let APIs target a specific part of a robot, such as an arm or
@@ -28,7 +30,7 @@ Robot configs can provide planning groups explicitly with
 does not run discovery or synthesize groups in `model_post_init`; callers must
 pass explicit `planning_groups` there.
 
-When code uses the discovery helper instead of explicit config, DimOS discovers
+When code uses the discovery helper instead of explicit config, dimOS discovers
 groups in this order:
 
 1. Explicit `srdf_path` provided to the helper.
@@ -56,7 +58,7 @@ Supported SRDF group forms:
 Unsupported SRDF forms are skipped with warnings: link groups, nested group
 references, mixed group declarations, branching or non-serial groups, and SRDF
 `<end_effector>` metadata. A chain group's `tip_link` is its pose target frame.
-An ordered joint-list group can be pose-targeted only when DimOS can validate a
+An ordered joint-list group can be pose-targeted only when dimOS can validate a
 unique serial target frame.
 
 ## Fallback behavior

docs/capabilities/memory/index.md

@@ -1,3 +1,8 @@
+---
+title: "Spatial Memory"
+sidebarTitle: "Overview"
+---
+
 <details>
 <summary>Python</summary>
 

docs/capabilities/navigation/index.md

@@ -1,5 +1,6 @@
 ---
 title: "Go2 Navigation Overview"
+sidebarTitle: "Overview"
 description: "Live column-carving navigation and premap relocalization for the Unitree Go2."
 ---
 

docs/capabilities/navigation/relocalization.md

@@ -7,7 +7,7 @@ Relocalization lets a Go2 navigate on a previously built map instead of only on
 
 ![relocalize on the live go2 and nav_to a point in the premap](https://raw.githubusercontent.com/dimensionalOS/dimos-docs-assets/main/capabilities/navigation/assets/reloc_and_nav_to.webp)
 
-> **Note:** Requires DimOS v0.0.13 or newer for PGO loop closure and `dimos map` export.
+> **Note:** Requires dimOS v0.0.13 or newer for PGO loop closure and `dimos map` export.
 
 This guide takes four steps:
 
@@ -16,7 +16,7 @@ This guide takes four steps:
 3. Test relocalization in replay, no robot needed
 4. Deploy on the live Go2
 
-Throughout this guide, `{DB_NAME}` is the stem of your recording, for example `recording_go2` for `recording_go2.db`. For `map_file`, pass the same stem and DimOS appends `.pc2.lcm` automatically.
+Throughout this guide, `{DB_NAME}` is the stem of your recording, for example `recording_go2` for `recording_go2.db`. For `map_file`, pass the same stem and dimOS appends `.pc2.lcm` automatically.
 
 ## 1. Record a run
 
@@ -175,7 +175,7 @@ for example `--relocalizationmodule.map-file=…`.
 
 | Field | Default | Description |
 |-------|---------|-------------|
-| `map_file` | `None` (module disabled) | Premap stem or path. DimOS appends `.pc2.lcm` automatically |
+| `map_file` | `None` (module disabled) | Premap stem or path. dimOS appends `.pc2.lcm` automatically |
 | `fitness_threshold` | `0.45` | Minimum ICP fitness to accept a relocalization (0 to 1) |
 | `publish_loaded_map` | `false` | Republish raw premap on `loaded_map` every 2 s |
 | `use_carving` | `true` | Column-carve when merging premap and live scan |

docs/capabilities/teleoperation/hosted.md

@@ -1,9 +1,10 @@
 ---
 title: "Remote Teleop"
+sidebarTitle: "dimTELE Remote Teleop"
 description: "Drive robots from anywhere in the world, with low latency, from a browser, phone, or VR headset."
 ---
 
-**dimTELE** is hosted teleoperation for DimOS robots: operate them remotely
+**dimTELE** is hosted teleoperation for dimOS robots: operate them remotely
 from any browser or Quest headset over WebRTC.
 The robot dials out to a hosted broker
 ([teleop.dimensionalos.com](https://teleop.dimensionalos.com)), so you don't