docs: add visual guidance to onboard manual

internal/ui/assets/README.md

@@ -60,3 +60,11 @@ CDN dependencies.
 Copied from `../site/public/favicon.svg` so Beacon uses the same browser icon
 as the Open Ships site while still serving all UI assets from the embedded
 binary.
+
+## manual/
+
+Screenshots and explanatory SVG diagrams used by the onboard manual. The PNGs
+are captures of a running Beacon instance, not static UI mockups. The SVGs use
+the product tokens from `DESIGN.md` and keep routing, checkpoint, replay, and
+troubleshooting concepts legible at any display density. All manual visuals
+are embedded and served locally with the rest of the UI.

internal/ui/docs/01-getting-started.md

@@ -3,9 +3,10 @@
 This example reads NMEA 2000 messages from one CAN bus and publishes them at
 an SSE endpoint.
 
-```text
-SocketCAN can0 --> connector --> SSE /events
-```
+[![SocketCAN can0 through a connector with CEL filters and a durable buffer to SSE /events](/assets/manual/routing-topology.svg)](/assets/manual/routing-topology.svg)
+
+_The connector is the policy and durability boundary between one source and
+one sink._
 
 ## Before you start
 
@@ -58,6 +59,11 @@ Open `http://localhost:2112` in a browser.
 7. Enable the connector.
 8. Save the connector.
 
+[![Beacon dashboard showing one running source fanning out through two connector routes to two sinks](/assets/manual/dashboard.png)](/assets/manual/dashboard.png)
+
+_The dashboard traces every configured route from left to right. Dotted lines
+connect shared endpoints without hiding which connector owns each route._
+
 ## Read the SSE stream
 
 Connect to the data port:

internal/ui/docs/02-sources.md

@@ -21,6 +21,11 @@ must refer to the source.
 
 All sources also have `id`, `name`, `type`, and `enabled` settings.
 
+[![Beacon Add source dialog filled out for an enabled SocketCAN interface named can0](/assets/manual/source-dialog.png)](/assets/manual/source-dialog.png)
+
+_Choose the source type first; Beacon then shows only the fields that apply to
+that endpoint._
+
 ## SocketCAN source
 
 Set `interface` to a Linux CAN network-interface name, such as `can0` or

internal/ui/docs/04-connectors.md

@@ -58,6 +58,12 @@ For example, accept Vessel Heading, PGN 127250:
 msg.pgn == 127250
 ```
 
+[![Beacon connector editor showing source and sink selection, semantic bridge mode, a validated CEL navigation filter, and buffer limits](/assets/manual/connector-dialog.png)](/assets/manual/connector-dialog.png)
+
+_The editor keeps route selection, bridge behavior, filtering, and retention
+in one place. A green `filters OK` result means the expression compiles; it
+does not mean matching traffic has arrived._
+
 Use the Filters page for variables, optional fields, raw values, and more
 examples.
 

internal/ui/docs/05-concepts.md

@@ -110,6 +110,11 @@ The inspector is best effort and does not block a connector queue. The browser
 keeps the latest 200 messages in the current tab. The captured count continues
 for the full browser session.
 
+[![Beacon source stream inspector actively capturing JSONL messages with filter, display, export, and copy controls](/assets/manual/stream-inspector.png)](/assets/manual/stream-inspector.png)
+
+_The inspector observes future messages at one component boundary. It is a
+browser-local diagnostic view, not another connector or delivery queue._
+
 ## Display and export formats
 
 - **JSONL** shows one compact `payload` object on each line.

internal/ui/docs/07-delivery-and-replay.md

@@ -12,6 +12,11 @@ that gives the guarantee that your application needs.
 | Best effort | Plain TCP | Dispatch completes; Beacon does not know if the client received the message |
 | Observe only | `observe` bridge mode | Local inspection completes without a sink call |
 
+[![Message flow through a CEL filter and SQLite route buffer to a sink boundary, followed by checkpoint advancement](/assets/manual/delivery-checkpoint.svg)](/assets/manual/delivery-checkpoint.svg)
+
+_Persist first, deliver second, checkpoint last. A failed delivery leaves the
+message pending so the connector can retry it._
+
 At-least-once delivery can produce duplicates. A consumer of a confirmed sink
 must tolerate duplicate messages.
 
@@ -191,6 +196,12 @@ endpoint-specific configuration and no external effect.
 
 ## Replay cursor
 
+[![Queue timeline showing retained messages 101 through 105, pending messages 106 through 108, checkpoint 105, and replay beginning after cursor 103](/assets/manual/replay-window.svg)](/assets/manual/replay-window.svg)
+
+_The checkpoint separates acknowledged history from pending delivery. A
+replay cursor can still address acknowledged messages while retention keeps
+them available._
+
 Beacon identifies a replay position with `connector:sequence`. The connector
 ID is necessary because one sink can serve multiple connectors.