docs(fleet): document the camera panel where its controls live

TODO.md

@@ -8,6 +8,7 @@ Open items for the docs site. WHAT, not HOW. Status: `[ ]` open, `[~]` in progre
 - [ ] Capture the route-solve screenshot for `solution/robot-deployment-toolbox/map-inspector.md` — "Testing that a route solves" has no figure because the running backend cannot find the pathfinding binary. It works standalone; the backend needs `TMG_PATHFINDING_BINARY=<wrdev_ws>/wra_topometric_graph/build/bin/pathfinding_query`. Verified by running the binary directly, which returned `{"found":true,…}`.
 - [ ] `solution/img/toolbox-load.png` is unreferenced. Left in place deliberately — an earlier unused-image sweep deleted `toolbox-finished-map.png` while `solution/intro.md` still used it and the build failed. Re-run the reference check immediately before deleting, not before the edit that changes references.
 - [ ] Open questions in `docs/design/release-pages-plan.md` §7: Toolbox/SDK delivery routes, R2026.08 labelling, component version visibility, WR SDK reference home.
+- [ ] Recapture `solution/img/fleet-stream-settings.png` against a robot that is reporting streams. The published capture was taken with none, so its **Enabled Streams** list is an empty heading and every Stream Assignment slot reads *None* — on `robot-dashboard.md` that figure now sits under prose about enabling streams, and the caption has to explain the gap. A capture with six streams listed and slots filled would carry the section on its own.
 
 - [ ] **Two Robot Management Toolbox capability claims need a product ruling before they go back.** The index claimed missions are **portable across sites** and that **duplication and revision comparison** let the next mission start from an existing one. Both existed only on `solution/robot-management-toolbox/index.md` (from `9587dae`), were absent from `mission-editing.md` which owns the feature, and were never seen by the `6abe51d`/`2e4b8ea` exposure passes. Removed in the index de-duplication pass rather than relocated, because relocating would have published them as verified. If the editor does offer either, they belong on `mission-editing.md` with the control named; if it does not, they stay out.
 - [ ] **`waypoint` vs `checkpoint` across the two toolboxes.** The index said a mission's checkpoint *is* a map waypoint plus a heading; `mission-editing.md` §2 gives three ways to place one (click the map, a saved location, the robot's pose) and never mentions waypoints, while the Deployment Toolbox defines waypoint as a kind of map node. The index no longer asserts the relationship, but the two vocabularies still need reconciling in one place. DEFER TO #38.

docs/LESSONS.md

@@ -140,3 +140,15 @@ Operational lessons for this repository, in Pattern / Correction / Context form.
 - **Pattern:** `9587dae` expanded the Robot Management Toolbox index's feature teasers "into real capability documentation" — 3-6 paragraphs each, against the sibling Deployment Toolbox index's one. Every later audit then went to the sub-pages: `6abe51d` and `2e4b8ea` (exposure passes) and `cfb043e` (authority corrections) rewrote `mission-editing.md`, `robot-dashboard.md` and `tenant-management.md` and **never opened the index**. Three defects followed from that one asymmetry. The E-Stop authority rule ended up stated **three times on the index and zero times on `robot-dashboard.md`**, the page that documents the button — so a reader on the owning page could not learn who may press it. `stop_safe`/`continue_mission` and a published default survived on `robot-dashboard.md` even though `cfb043e`'s own commit body ruled the behaviour "set on the robot rather than configured here", because that correction landed on the two *prose* sentences and not on the table-like bullet below them. And two capability claims — missions "portable across sites", "duplication and revision comparison" — existed **only** on the index, absent from `mission-editing.md`, so no exposure pass ever tested them. The pattern then demonstrated itself mid-repair: `83d98e3` landed on `mission-editing.md` correcting "a single correction applies everywhere it is used" (false for a mission a robot already holds), while the index was still publishing the same over-claim two files away.
 - **Correction:** An overview teaser gets purpose, the reason to open the page, an optional figure, and the link — nothing a sub-page owns. Give every load-bearing fact exactly one owning page and let the index point at it; where safety or orientation justifies a second mention, keep it to a clause and link the canonical one. When auditing a claim, grep the index **and** the sub-pages in the same pass: a correction applied to one is not a correction to the other, and the index is the copy that gets skipped because it reads like a summary rather than like documentation. The tell that a teaser has drifted is a specific number, an enum value or a role boundary appearing in it. `onBrokenAnchors` will not catch any of this — the pages stay perfectly linked while they disagree.
 - **Context:** Any docs section with an index plus owning sub-pages. This is the structural sibling of "A framing correction invalidates more than the sentence it lands on" — that one is about a correction missing a diagram, this one about a correction missing a whole page.
+
+### A highlight box drawn on a supplied screenshot is a pointer, not content to publish
+
+- **Pattern:** A screenshot arrived with a thick red rectangle around the control the request was about — *"include this portion"*. Publishing it as-is would have put the only annotated figure on a site whose 30-odd screenshots carry none, and forced the `alt` to describe a marker that is not part of the product. The red was the sender saying *which control*, and the figure is already about that control, so the annotation carried no information the caption did not.
+- **Correction:** Reconstruct the clean UI rather than crop around the marker or publish it. These captures are flat dark panels, so the geometry is recoverable: read the exact mask (`r>110 && r-g>50 && r-b>50` — the marker is hard-edged, the only pinkish pixels elsewhere are subpixel text fringes), then fill each band from the equivalent unmarked geometry — a sibling button's edge column at the same `y` for a button outline, a mirrored corner arc for a panel corner, the flat background shifted by the band width, and one redrawn 1px line where the marker sat over a border. Then assert **changed pixels == masked pixels** and look at the result at 4× before shipping. Ask for an unmarked capture only if the marker crosses text or artwork, where none of this recovers anything.
+- **Context:** `solution/img/fleet-stream-selection.png`, rebuilt from a marked-up capture. Sits beside "Verify the geometry after editing an image" and "Alt text must describe the image you publish" — same family, one step earlier: decide what the published file should contain before describing it.
+
+### A figure captures one moment of state, and prose written later can outrun it
+
+- **Pattern:** `fleet-stream-settings.png` was captured against a robot reporting no streams, so its **Enabled Streams** section is a heading with nothing under it and all four Stream Assignment slots read *None*. Nothing was wrong while the page only discussed layout. Moving the figure onto a section that teaches *enabling streams* made the empty region load-bearing, and a first draft of the caption said the dialog shows "which streams are enabled" — pointing the reader at blank space.
+- **Correction:** Before writing a caption or a sentence beside an existing figure, open the image file and check that the state it captured still supports what the new prose claims. Where it does not and a recapture is not available, say so in the caption in one clause and log the recapture in `TODO.md` — an acknowledged gap costs a reader nothing, an unacknowledged one costs them their confidence in the page. A figure that moves between sections is the moment to run this check; the image did not change, its job did.
+- **Context:** `solution/robot-management-toolbox/robot-dashboard.md`. The converse of the alt-text lesson: there the image changed under the text, here the text changed under the image.

solution/robot-management-toolbox/index.md

@@ -165,7 +165,7 @@ Opening a robot gives you that one machine on one screen: where it is on the sit
   framed
   caption="One robot on one screen: the site map, its cameras, what it is doing, its status, and the controls." />
 
-[Robot dashboard](/solution/robot-management-toolbox/robot-dashboard) covers the page in full: each panel, the telemetry readings and when a robot stops counting as reporting, the diagnostics view for a robot that is misbehaving, recovering localisation, taking control of a robot, and [what happens during a mission](/solution/robot-management-toolbox/robot-dashboard#what-happens-during-a-mission) as battery level and the link to the fleet change.
+[Robot dashboard](/solution/robot-management-toolbox/robot-dashboard) covers the page in full: each panel, the telemetry readings and when a robot stops counting as reporting, the diagnostics view for a robot that is misbehaving, recovering localisation, [arranging the camera view](/solution/robot-management-toolbox/robot-dashboard#arranging-the-view) and the audio that goes with it, taking control of a robot, and [what happens during a mission](/solution/robot-management-toolbox/robot-dashboard#what-happens-during-a-mission) as battery level and the link to the fleet change.
 
 ## Robot teleoperation
 
@@ -178,7 +178,7 @@ Beyond watching, an operator can intervene directly: drive the robot from the br
   framed
   caption="An assisted teleoperation view, on a robot fitted and configured for it: surround view, proximity zones, radar, and link quality." />
 
-[Robot teleoperation](/solution/robot-management-toolbox/robot-teleoperation) covers driving in full: keyboard and gamepad control, remapping and inverting the axes, speed and deadzone, arranging the camera views, audio, and the assisted view some robots present. The control panel itself — taking control, the E-Stop and who may release it — is on the [Robot dashboard](/solution/robot-management-toolbox/robot-dashboard#taking-control) page.
+[Robot teleoperation](/solution/robot-management-toolbox/robot-teleoperation) covers driving in full: keyboard and gamepad control, remapping and inverting the axes, speed and deadzone, speaking through the robot while driving, and the assisted view some robots present. The control panel itself — taking control, the E-Stop and who may release it — is on the [Robot dashboard](/solution/robot-management-toolbox/robot-dashboard#taking-control) page.
 
 ## Mission planning
 

solution/robot-management-toolbox/robot-dashboard.md

@@ -1,6 +1,6 @@
 ---
 sidebar_position: 1
-description: "The robot view in the Robot Management Toolbox: the navigation map, camera feeds, operations and telemetry panels, the control panel, and how battery and connection loss change a running mission."
+description: "The robot view in the Robot Management Toolbox: the navigation map, camera feeds and how to arrange them, audio, operations and telemetry panels, the control panel, and how battery and connection loss change a running mission."
 ---
 
 # Robot dashboard
@@ -35,6 +35,63 @@ One robot on one screen. The view is laid out so that judging a running mission
 
 Two things make it more likely to take. Put the pose where the robot physically is, as closely as you can judge — near enough in the right place is what it needs rather than an exact figure. And have the robot somewhere with clear, distinctive surroundings rather than a repetitive or bare one, because an aisle of identical bays gives it little to tell one position from another.
 
+## Arranging the view
+
+What the camera panel shows takes two separate decisions: **which of the robot's streams are running**, and **how the panes are arranged**. Both are set from the controls along the top of the panel, which appear when the camera feeds hold the main view area — switch **Map / Cameras** to Cameras if they are currently in the small one.
+
+### Which streams are running
+
+<Figure
+  src={require('../img/fleet-stream-selection.png').default}
+  alt="The controls along the top of the camera panel: an audio button reading Robot audio on, a Take Voice button, a camera button reading 6 / 6 with its Streams menu open beneath it, and a Settings button. The menu lists six streams — A2 Front Camera, A2 Rear Camera, A2 Left Camera, A2 Right Camera, A2 Gesture Camera and A2 Fence Detection 1 — each with a tick beside it"
+  size="md"
+  framed
+  caption="The Streams menu, opened from the camera count: every stream the robot offers, and which of them are running." />
+
+The camera control counts **the streams running against the streams the robot offers** — `6 / 6` when every one of them is up. Opening it lists them by name, and ticking one starts it. The same set appears as **Enabled Streams** in Stream Settings, with each stream's type beside it.
+
+**Ticking a stream asks the robot to start sending that camera.** It is not a filter over feeds already arriving, which is why a pane can be assigned correctly and still show nothing: a pane whose stream is not running reads **Waiting for stream…** instead. When a layout you have just set looks empty, check this count before changing the layout: assigning a pane starts nothing.
+
+**Streams are not restored when you come back.** A session opens with none of them running, and the ones you started are stopped when you leave the robot, so the panes fill as you turn feeds on rather than arriving populated. The arrangement around them is remembered.
+
+### How the panes are arranged
+
+**Stream Settings**, from the same row of controls, holds the arrangement, and it is remembered per robot.
+
+<Figure
+  src={require('../img/fleet-stream-settings.png').default}
+  alt="The Stream Settings dialog showing an audio mode of push-to-talk on hold-T, separate Dashboard and Teleop tabs, a layout picker with pane counts one to six and template thumbnails for two-by-two grid, focus left plus three and focus top plus three, a stream assignment list mapping slots A to D to cameras, and a grid fit choice between fill container and fixed aspect ratio"
+  size="md"
+  framed
+  caption="Stream Settings: audio mode, the layout and which camera sits in each pane, and how each view is fitted. Its enabled-stream list is empty here because the robot was reporting none." />
+
+**Layout is chosen in two steps** — first how many panes you want, from one to six, then which arrangement of that many. Four panes offers a 2×2 grid, one large pane with three small, or one across the top with three beneath; the thumbnails show each. **Stream assignment** then puts a named camera in each lettered slot.
+
+| Setting | Options |
+| --- | --- |
+| **Layout** | One to six panes, and from two panes up, several arrangements of each |
+| **Stream assignment** | Which camera goes in each lettered slot |
+| **Grid fit** | **Fill container**, which uses every pixel and may crop edges, or **fixed aspect ratio**, which keeps the whole frame |
+| **Primary stream** | The feed that fills the screen while driving |
+| **Picture-in-picture** | A stream pinned to a corner — top or bottom, left, centre or right — or switched off |
+| **Visible in teleop** | Which cameras appear while driving, which can be a smaller set than the dashboard shows |
+
+**Dashboard and teleop keep separate layouts**, on their own tabs, so the arrangement you want while monitoring need not be the one you want while driving. The dashboard tab holds the pane layout and the grid fit; the teleop tab holds the primary stream and what is pinned around it.
+
+Grid fit is the choice worth deliberate thought: filling the pane uses every pixel but crops the edges, and fixed aspect keeps the whole frame at the cost of letterboxing. For judging clearance beside a robot, seeing the whole frame usually matters more than filling the screen.
+
+## Audio
+
+Audio has two halves, and they are separate controls: hearing the robot, and speaking through it.
+
+**Hearing it** is the audio button on the camera panel — **Robot audio on** while it is live, **Robot audio muted** while it is not. Where the browser has not yet been allowed to play audio the same button reads **Click to enable audio**, and pressing it both unlocks playback and unmutes. It is an on-or-off control rather than a level: how loud the robot is comes from the computer's own volume.
+
+**Speaking through it** is claimed the way the robot's controls are — one person at a time. **Take Voice** takes the channel, and while you hold it the control offers the microphone and a button to release it. Anyone else sees **Voice:** and the name of whoever holds it, and a Site Admin can **Revoke** a channel left held by someone who has gone.
+
+**The voice channel is independent of the robot's controls.** Taking it does not take the robot, so an operator can speak to whoever is near a machine without touching anything that moves it — and someone else driving does not stop you. Taking the channel is an Operator action; an Observer cannot.
+
+Speaking is **push-to-talk** by default: hold to speak, release to stop — **`T`** on the keyboard, or the gamepad button bound to it while driving. **Always on**, set from **Audio Mode** in Stream Settings, leaves the microphone live and gives you a mute button instead. That suits an operator who needs both hands and does not suit a shared control room, where it carries whatever else is being said in the room to whoever is standing near the robot.
+
 ## Telemetry
 
 Telemetry answers "is this robot all right?" and is presented three ways: **realtime** for what is true now, **history** for how a reading has moved, and **activity** for what the robot has been doing.
@@ -127,7 +184,7 @@ Every other control on this panel is held under a **lease** — an exclusive cla
 **only one person commands it at a time**, and a second operator cannot take the controls until the
 lease is released. There is no ambiguity about who is responsible for a moving robot.
 
-Pressing **Teleop** starts a driving session in the main view area. Driving itself — keyboard and gamepad control, key mapping and axis inversion, speed and deadzone, arranging the camera views, and audio — is covered on [Robot teleoperation](/solution/robot-management-toolbox/robot-teleoperation).
+Pressing **Teleop** starts a driving session in the main view area. Driving itself — keyboard and gamepad control, key mapping and axis inversion, speed and deadzone — is covered on [Robot teleoperation](/solution/robot-management-toolbox/robot-teleoperation).
 
 Drive commands depend on the robot being on the map the fleet has activated. A robot that is behind has its dispatch and Go Home controls withdrawn until it catches up — see [Catching a robot up to the map](/solution/robot-management-toolbox/tenant-management#catching-a-robot-up-to-the-map).
 
@@ -188,7 +245,10 @@ after the restart, [contact Weston Robot support](/support/before-you-contact-us
 No. Control is held under a lease, and only one person holds it at a time.
 
 **The camera panel is empty**  
-The robot is not connected. Feeds are live, so there is nothing to show for a robot that is not reporting in. Check the heartbeat reading in telemetry.
+Check the stream count first, since a session starts with nothing running and an empty panel may simply be a panel with no feeds turned on. If streams are running and the panes are still empty, the robot is not connected — feeds are live, so there is nothing to show for a robot that is not reporting in, and the heartbeat reading in telemetry will say so.
+
+**I set a layout and the panes are still empty**  
+A pane shows its camera only while that stream is running, and setting the layout does not start anything. Open the stream count beside **Settings** and tick the cameras you want — see [Which streams are running](#which-streams-are-running).
 
 **Why did teleoperation stop on its own?**  
 Teleoperation stops the robot when the connection to the fleet degrades. That is deliberate — driving a robot you cannot see is worse than stopping it.