ultravisor 1.0.21 → 1.0.22

package/docs/features/beacons.md

@@ -14,24 +14,25 @@ bridge between Ultravisor's operation engine and the outside world.
 
 The Beacon system uses the same **WaitingForInput** pause/resume mechanism
 that powers interactive tasks like `value-input`. When a `beacon-dispatch`
-node executes, it does not block the engine — instead it enqueues a work
+node executes, it does not block the engine -- instead it enqueues a work
 item and returns `WaitingForInput`. The operation pauses at that node until
 a Beacon picks up the work, executes it remotely, and reports results.
 
 The full cycle looks like this:
 
-```
-┌──────────────────┐           ┌──────────────────────┐          ┌──────────────┐
-│  Operation Graph │           │  BeaconCoordinator   │          │    Beacon    │
-│                  │           │  (server-side)       │          │   (remote)   │
-│  beacon-dispatch │──enqueue──▶  Work Queue          │          │              │
-│  returns         │           │                      │◀──poll───│  poll loop   │
-│  WaitingForInput │           │  assign work item    │──work──▶ │  execute     │
-│       ⋮          │           │                      │          │  locally     │
-│  (paused)        │           │                      │◀─result──│  report back │
-│       ⋮          │           │  resumeOperation()   │          │              │
-│  graph continues │◀──resume──│                      │          │              │
-└──────────────────┘           └──────────────────────┘          └──────────────┘
+```mermaid
+sequenceDiagram
+    participant OG as Operation Graph
+    participant BC as BeaconCoordinator<br/>(server-side)
+    participant B as Beacon<br/>(remote)
+    OG->>BC: beacon-dispatch (enqueue)
+    Note left of OG: Returns WaitingForInput<br/>(graph paused)
+    B->>BC: poll loop
+    BC->>B: assign work item
+    B->>B: execute locally
+    B->>BC: report result
+    BC->>OG: resumeOperation()
+    Note left of OG: Graph continues
 ```
 
 ### Transport Agnostic
@@ -46,7 +47,7 @@ channel without changing the core dispatch logic.
 
 Many real-world pipelines require that related tasks execute on the same
 worker. For example, a video processing pipeline might split a file across
-multiple encoding passes — each pass needs access to the same local copy of
+multiple encoding passes -- each pass needs access to the same local copy of
 the source footage.
 
 The **AffinityKey** setting on `beacon-dispatch` nodes solves this.
@@ -55,7 +56,7 @@ The **AffinityKey** setting on `beacon-dispatch` nodes solves this.
 
 1. The first `beacon-dispatch` task with a given AffinityKey is claimed by
    whichever Beacon picks it up. The coordinator records a binding:
-   `AffinityKey → BeaconID`.
+   `AffinityKey -> BeaconID`.
 2. Subsequent tasks with the **same** AffinityKey are pre-assigned to that
    same Beacon. When the Beacon polls, it receives affinity-assigned items
    first.
@@ -102,7 +103,7 @@ Common capability names:
 | `MLInference` | Run machine-learning model inference |
 | `MediaProcessing` | Transcode video/audio, generate thumbnails |
 
-You can define any capability string you like — the coordinator treats them
+You can define any capability string you like -- the coordinator treats them
 as opaque labels for matching purposes.
 
 ## API Reference
@@ -437,7 +438,7 @@ these optional fields:
 
 | Field | Type | Description |
 |-------|------|-------------|
-| `Percent` | number | Completion percentage (0–100) |
+| `Percent` | number | Completion percentage (0-100) |
 | `Message` | string | Human-readable status message |
 | `Step` | number | Current step number |
 | `TotalSteps` | number | Total number of steps |
@@ -478,7 +479,7 @@ Report progress on an in-flight work item.
 
 | Field | Type | Required | Description |
 |-------|------|----------|-------------|
-| `Percent` | number | no | Completion percentage (0–100) |
+| `Percent` | number | no | Completion percentage (0-100) |
 | `Message` | string | no | Human-readable status message |
 | `Step` | number | no | Current step number |
 | `TotalSteps` | number | no | Total number of steps |
@@ -486,7 +487,7 @@ Report progress on an in-flight work item.
 
 **Response:** `{ Success: true }`
 
-Progress is fire-and-forget from the Beacon's perspective — failures to
+Progress is fire-and-forget from the Beacon's perspective -- failures to
 report progress do not affect work item execution.
 
 ## Running a Beacon

package/docs/features/case-study-retold-remote.md

@@ -64,26 +64,26 @@ sequenceDiagram
 
     RR->>UV: WebSocket: BeaconRegister<br/>{Name: "retold-remote", Contexts: {File: {BaseURL: "http://localhost:7827/content/"}},<br/>BindAddresses: [{IP: "127.0.0.1", Port: 7827}],<br/>Operations: [rr-image-thumbnail, rr-video-thumbnail, ...]}
     UV->>UV: Register beacon, store 9 operation definitions
-    UV->>UV: Probe: retold-remote ↔ orator-conversion = REACHABLE
+    UV->>UV: Probe: retold-remote <-> orator-conversion = REACHABLE
 
     Note over UV: Both beacons registered.<br/>14 beacon task types available.<br/>9 operations from retold-remote.<br/>Reachability: all pairs reachable.
 ```
 
 ### 3. Auto-Generated Operations
 
-retold-remote registers 9 operation definitions during beacon connection. These are complete operation graphs with nodes, connections, and state wiring — built programmatically by `_buildPipelineOperation()`:
+retold-remote registers 9 operation definitions during beacon connection. These are complete operation graphs with nodes, connections, and state wiring -- built programmatically by `_buildPipelineOperation()`:
 
 | Operation | Trigger Parameters | Pipeline |
 |-----------|-------------------|----------|
-| `rr-image-thumbnail` | ImageAddress, Width, Height, Format, Quality | resolve → transfer → resize → send-result |
-| `rr-video-thumbnail` | VideoAddress, Timestamp, Width | resolve → transfer → extract frame → send-result |
-| `rr-video-frame-extraction` | VideoAddress, Timestamp, Width | resolve → transfer → probe → extract → send-result |
-| `rr-audio-waveform` | AudioAddress, SampleRate, Samples | resolve → transfer → waveform → send-result |
-| `rr-audio-segment` | AudioAddress, Start, Duration, Codec | resolve → transfer → extract → send-result |
-| `rr-pdf-page-render` | PdfAddress, Page, LongSidePixels | resolve → transfer → render → send-result |
-| `rr-image-convert` | ImageAddress, Format, Quality | resolve → transfer → convert → send-result |
-| `rr-ebook-convert` | EbookAddress | resolve → transfer → ebook-convert → send-result |
-| `rr-media-probe` | MediaAddress | resolve → transfer → ffprobe → send-result |
+| `rr-image-thumbnail` | ImageAddress, Width, Height, Format, Quality | resolve -> transfer -> resize -> send-result |
+| `rr-video-thumbnail` | VideoAddress, Timestamp, Width | resolve -> transfer -> extract frame -> send-result |
+| `rr-video-frame-extraction` | VideoAddress, Timestamp, Width | resolve -> transfer -> probe -> extract -> send-result |
+| `rr-audio-waveform` | AudioAddress, SampleRate, Samples | resolve -> transfer -> waveform -> send-result |
+| `rr-audio-segment` | AudioAddress, Start, Duration, Codec | resolve -> transfer -> extract -> send-result |
+| `rr-pdf-page-render` | PdfAddress, Page, LongSidePixels | resolve -> transfer -> render -> send-result |
+| `rr-image-convert` | ImageAddress, Format, Quality | resolve -> transfer -> convert -> send-result |
+| `rr-ebook-convert` | EbookAddress | resolve -> transfer -> ebook-convert -> send-result |
+| `rr-media-probe` | MediaAddress | resolve -> transfer -> ffprobe -> send-result |
 
 Each pipeline follows the same pattern:
 
@@ -102,9 +102,9 @@ graph LR
 ```
 
 State connections wire outputs from earlier nodes into inputs of later nodes:
-- `resolve.URL` → `transfer.SourceURL`
-- `resolve.Filename` → `transfer.Filename`
-- `transfer.LocalPath` → `process.InputFile`
+- `resolve.URL` -> `transfer.SourceURL`
+- `resolve.Filename` -> `transfer.Filename`
+- `transfer.LocalPath` -> `process.InputFile`
 
 ## End-to-End: Image Thumbnail Generation
 
@@ -119,13 +119,13 @@ sequenceDiagram
 
     Browser->>RR: GET /content/preview/photo.jpg?w=400&h=300
 
-    Note over RR: Check cache → miss
+    Note over RR: Check cache -> miss
 
     RR->>UV: POST /Operation/rr-image-thumbnail/Trigger<br/>{Parameters: {ImageAddress: ">retold-remote/File/photo.jpg",<br/>Width: 400, Height: 300, Format: "webp", Quality: 80}}
 
     Note over UV: Start operation (sync mode)
 
-    UV->>UV: resolve-address<br/>>retold-remote/File/photo.jpg<br/>→ http://localhost:7827/content/photo.jpg
+    UV->>UV: resolve-address<br/>>retold-remote/File/photo.jpg<br/>-> http://localhost:7827/content/photo.jpg
 
     UV->>RR: HTTP GET http://localhost:7827/content/photo.jpg
     RR-->>UV: 200 OK (image bytes)
@@ -136,12 +136,12 @@ sequenceDiagram
     OC->>UV: POST /Beacon/Work/Poll
     UV-->>OC: WorkItem: {Action: "ImageResize",<br/>Settings: {InputFile: "/.../photo.jpg",<br/>OutputFile: "/.../thumbnail.jpg", Width: 400, ...}}
 
-    OC->>OC: Sharp: resize photo.jpg → thumbnail.jpg
+    OC->>OC: Sharp: resize photo.jpg -> thumbnail.jpg
     OC->>UV: POST /Beacon/Work/{hash}/Upload<br/>(raw binary: thumbnail.jpg)
     UV->>UV: Write to operation staging
 
     OC->>UV: POST /Beacon/Work/{hash}/Complete
-    UV->>UV: resumeOperation → send-result<br/>finds thumbnail.jpg in staging
+    UV->>UV: resumeOperation -> send-result<br/>finds thumbnail.jpg in staging
 
     UV-->>RR: 200 OK<br/>Content-Type: application/octet-stream<br/>Body: (thumbnail bytes)
 
@@ -184,9 +184,9 @@ this._dispatcher.triggerOperation('rr-image-thumbnail',
 orator-conversion handles arbitrarily large images (including 256MB+ scans):
 
 - **File-path mode**: Sharp receives the file path directly instead of loading the entire file into a buffer
-- **No pixel limit**: `sharp(filePath, { limitInputPixels: false })` — disables Sharp's default pixel limit
+- **No pixel limit**: `sharp(filePath, { limitInputPixels: false })` -- disables Sharp's default pixel limit
 - **Streaming**: File transfer uses Node.js streams, avoiding full-file buffering
-- **Binary upload**: Result files transfer as raw bytes over HTTP or WebSocket — no base64 encoding
+- **Binary upload**: Result files transfer as raw bytes over HTTP or WebSocket -- no base64 encoding
 
 ## Error Handling
 
@@ -197,9 +197,9 @@ flowchart TD
     A[Beacon processes work item] --> B{ExitCode == 0?}
     B -->|Yes| C[Upload output file]
     C --> D[Report completion]
-    D --> E[Operation resumes → send-result → binary stream]
+    D --> E[Operation resumes -> send-result -> binary stream]
     B -->|No| F[Report error]
-    F --> G[Operation resumes → Error event → End node]
+    F --> G[Operation resumes -> Error event -> End node]
     G --> H[Trigger returns JSON with Success: false]
     H --> I[retold-remote falls back to local processing]
 ```
@@ -215,9 +215,9 @@ npm start -- -u -l                     # orator-conversion-2026-03-21T...log
 ```
 
 Key log prefixes for tracing the pipeline:
-- `[TriggerOp]` — retold-remote dispatcher
-- `[Trigger]` — Ultravisor trigger endpoint
-- `[Engine]` — Ultravisor execution engine
-- `[Coordinator]` — Beacon coordinator (work queue, uploads)
-- `[OratorConversion]` — orator-conversion provider
-- `[Beacon]` — Beacon client (execution, upload, completion)
+- `[TriggerOp]` -- retold-remote dispatcher
+- `[Trigger]` -- Ultravisor trigger endpoint
+- `[Engine]` -- Ultravisor execution engine
+- `[Coordinator]` -- Beacon coordinator (work queue, uploads)
+- `[OratorConversion]` -- orator-conversion provider
+- `[Beacon]` -- Beacon client (execution, upload, completion)

package/docs/features/llm-model-setup.md

@@ -5,7 +5,7 @@ Each section covers installation, configuration, and verification for a
 specific backend.
 
 You do not need machine learning expertise to set this up. Each LLM
-provider has its own API that the Beacon wraps — you just need the
+provider has its own API that the Beacon wraps -- you just need the
 provider running and a configuration file pointing the Beacon at it.
 
 ## Prerequisites
@@ -64,7 +64,7 @@ Download the installer from https://ollama.com/download
 # Start the Ollama server (runs in background)
 ollama serve
 
-# Pull a model — this downloads the model weights (may take a few minutes)
+# Pull a model -- this downloads the model weights (may take a few minutes)
 ollama pull llama3.2
 
 # Verify it works
@@ -135,7 +135,7 @@ You should see:
 [Beacon CLI] Loaded config from /path/to/.ultravisor-beacon.json
 [LLM] Provider initialized: backend=ollama, model=llama3.2
 [LLM] Ollama server reachable at localhost:11434
-[ProviderRegistry] Registered "LLM" → LLM [ChatCompletion, Embedding, ToolUse]
+[ProviderRegistry] Registered "LLM" -> LLM [ChatCompletion, Embedding, ToolUse]
 [Beacon] Loaded 1 capability provider(s).
 [Beacon] Capabilities: LLM
 [Beacon] Registered as bcn-llm-ollama-...
@@ -144,12 +144,12 @@ You should see:
 
 ### Troubleshooting
 
-- **"Ollama server not reachable"** — Make sure `ollama serve` is running.
+- **"Ollama server not reachable"** -- Make sure `ollama serve` is running.
   Check with `curl http://localhost:11434/api/tags`.
-- **Slow responses** — First request after pulling a model is slower
+- **Slow responses** -- First request after pulling a model is slower
   (loading into memory). Subsequent requests are faster. On CPU-only
   machines, expect 5-30 seconds per response depending on model size.
-- **Out of memory** — Use a smaller model. `llama3.2:3b` or `phi3` work
+- **Out of memory** -- Use a smaller model. `llama3.2:3b` or `phi3` work
   well on machines with 8GB RAM. The 70B models need 48GB+ RAM or a GPU
   with equivalent VRAM.
 
@@ -166,7 +166,7 @@ an API key with billing set up.
 2. Create an account or sign in
 3. Navigate to API Keys
 4. Create a new key
-5. Copy the key — it starts with `sk-ant-`
+5. Copy the key -- it starts with `sk-ant-`
 
 ### Step 2: Set the API key as an environment variable
 
@@ -232,12 +232,12 @@ node source/beacon/Ultravisor-Beacon-CLI.cjs
 
 ### Troubleshooting
 
-- **"401 Unauthorized"** — Your API key is missing or invalid. Check
+- **"401 Unauthorized"** -- Your API key is missing or invalid. Check
   `echo $ANTHROPIC_API_KEY` to verify it's set.
-- **"429 Too Many Requests"** — You've hit rate limits. Anthropic has
+- **"429 Too Many Requests"** -- You've hit rate limits. Anthropic has
   per-minute and per-day limits that vary by plan. Reduce `MaxConcurrent`
   or add delays between requests.
-- **"400 max_tokens"** — Anthropic requires `max_tokens` on every
+- **"400 max_tokens"** -- Anthropic requires `max_tokens` on every
   request. The provider defaults to 4096 if not set, but some models
   support higher values.
 
@@ -250,7 +250,7 @@ node source/beacon/Ultravisor-Beacon-CLI.cjs
 1. Go to https://platform.openai.com/
 2. Sign in and navigate to API Keys
 3. Create a new secret key
-4. Copy the key — it starts with `sk-`
+4. Copy the key -- it starts with `sk-`
 
 ### Step 2: Set the API key
 
@@ -311,9 +311,9 @@ node source/beacon/Ultravisor-Beacon-CLI.cjs
 
 ### Troubleshooting
 
-- **"401" or "invalid_api_key"** — Check that `OPENAI_API_KEY` is set
+- **"401" or "invalid_api_key"** -- Check that `OPENAI_API_KEY` is set
   and has billing enabled. Free-tier keys have very limited access.
-- **"model_not_found"** — Make sure you have access to the model. Some
+- **"model_not_found"** -- Make sure you have access to the model. Some
   models require specific account tiers.
 
 ---
@@ -444,7 +444,7 @@ source/beacon/
       └── Ultravisor-Beacon-Provider-LLM.cjs
 ```
 
-These files have zero npm dependencies — they use only Node.js built-in
+These files have zero npm dependencies -- they use only Node.js built-in
 modules. Copy the `source/beacon/` directory to your remote machine,
 create a `.ultravisor-beacon.json` config file, and run:
 
@@ -482,7 +482,7 @@ Or use the CLI:
 node source/cli/Ultravisor-Run.cjs execute --operation llm-summarize
 ```
 
-Watch the Beacon terminal — you should see it pick up the work item,
+Watch the Beacon terminal -- you should see it pick up the work item,
 make the LLM API call, and report back.
 
 ---

package/docs/features/llm.md

@@ -1,8 +1,8 @@
 # LLM Integration
 
 Ultravisor can send requests to large language models (LLMs) through the
-Beacon system. An LLM Beacon wraps an API — OpenAI, Anthropic, a local
-Ollama instance, or any OpenAI-compatible endpoint — and exposes it as a
+Beacon system. An LLM Beacon wraps an API -- OpenAI, Anthropic, a local
+Ollama instance, or any OpenAI-compatible endpoint -- and exposes it as a
 capability that operation graphs can use like any other task.
 
 This means you can build workflows that read data, send it to an LLM for
@@ -13,29 +13,31 @@ Ultravisor operation graph.
 
 The LLM functionality has two layers:
 
-1. **Beacon Provider** (`LLM`) — runs on the Beacon worker, wraps the
+1. **Beacon Provider** (`LLM`) -- runs on the Beacon worker, wraps the
    actual HTTP calls to the LLM API. This is the "thin wrapper" that
    handles authentication, request formatting, and response normalization
    across different backends.
 
 2. **Graph Task Types** (`llm-chat-completion`, `llm-embedding`,
-   `llm-tool-use`) — run on the Ultravisor server, dispatch work to an
+   `llm-tool-use`) -- run on the Ultravisor server, dispatch work to an
    LLM Beacon, manage conversation history, and route results back into
    the operation state.
 
-```
-┌──────────────────────┐         ┌────────────────────┐        ┌──────────────┐
-│   Operation Graph    │         │  BeaconCoordinator │        │  LLM Beacon  │
-│                      │         │                    │        │              │
-│  llm-chat-completion │─enqueue─▶  Work Queue       │        │  LLM Provider│
-│  (builds messages,   │         │                    │◀─poll──│              │
-│   manages history)   │         │  assign work       │─work──▶│  HTTP call   │
-│                      │         │                    │        │  to LLM API  │
-│  WaitingForInput...  │         │                    │◀result─│  (OpenAI,    │
-│                      │         │  resumeOperation() │        │   Anthropic, │
-│  updates history,    │◀resume──│                    │        │   Ollama)    │
-│  writes to state     │         │                    │        │              │
-└──────────────────────┘         └────────────────────┘        └──────────────┘
+```mermaid
+sequenceDiagram
+    participant OG as Operation Graph
+    participant BC as BeaconCoordinator
+    participant LB as LLM Beacon
+    participant API as LLM API<br/>(OpenAI / Anthropic / Ollama)
+    OG->>BC: llm-chat-completion (enqueue)<br/>builds messages, manages history
+    Note left of OG: WaitingForInput...
+    LB->>BC: poll
+    BC->>LB: assign work
+    LB->>API: HTTP call
+    API-->>LB: response
+    LB->>BC: result
+    BC->>OG: resumeOperation()
+    Note left of OG: Updates history,<br/>writes to state
 ```
 
 ## Supported Backends
@@ -50,7 +52,7 @@ The LLM functionality has two layers:
 The provider normalizes differences between backends automatically. For
 example, Anthropic uses `x-api-key` headers and a different message
 format; Ollama puts parameters in an `options` object. You don't need to
-worry about these details — just set the `Backend` config value and
+worry about these details -- just set the `Backend` config value and
 provide your messages.
 
 ## Actions
@@ -157,7 +159,7 @@ The primary task for using LLMs in operation graphs.
 | Name               | Description                                              |
 |--------------------|----------------------------------------------------------|
 | UserPrompt         | User message text (builds Messages for you)              |
-| InputAddress       | State address to read context data from — appended to UserPrompt |
+| InputAddress       | State address to read context data from -- appended to UserPrompt |
 | Destination        | State address to write the completion content to         |
 | AffinityKey        | Route to a specific Beacon                               |
 | TimeoutMs          | Override timeout (default: 120000)                       |
@@ -184,8 +186,8 @@ stored in operation or global state.
 |----------------------------|--------------------------------------------------------|
 | ConversationAddress        | State address for the message history array            |
 | AppendToConversation       | Append this exchange to history (default: true)        |
-| ConversationMaxMessages    | Sliding window — keep only the N most recent messages  |
-| ConversationMaxTokens      | Token budget — trim oldest messages when exceeded      |
+| ConversationMaxMessages    | Sliding window -- keep only the N most recent messages  |
+| ConversationMaxTokens      | Token budget -- trim oldest messages when exceeded      |
 | PersistConversation        | Copy history to GlobalState on completion              |
 | ConversationPersistAddress | GlobalState address for cross-operation persistence    |
 
@@ -201,17 +203,17 @@ When `ConversationAddress` is set, the task:
 6. Appends the assistant response to the history
 7. Writes updated history back to the state address
 
-**Within a single operation** — use `Operation.` addresses:
+**Within a single operation** -- use `Operation.` addresses:
 
 ```
 llm-node-1 (ConversationAddress: "Operation.Chat")
-    → llm-node-2 (ConversationAddress: "Operation.Chat")
-    → llm-node-3 (ConversationAddress: "Operation.Chat")
+    -> llm-node-2 (ConversationAddress: "Operation.Chat")
+    -> llm-node-3 (ConversationAddress: "Operation.Chat")
 ```
 
 Each node sees the full conversation so far and adds to it.
 
-**Across operations** — use `Global.` addresses:
+**Across operations** -- use `Global.` addresses:
 
 Set `ConversationAddress: "Global.Sessions.MyAgent"` to store history in
 GlobalState, which persists across operation runs.
@@ -252,11 +254,11 @@ it up. Subsequent requests with the same key go to the same Beacon.
 
 Two example operations are included in `operation-library/`:
 
-- **llm-summarize.json** — Reads a file, sends it to an LLM for
+- **llm-summarize.json** -- Reads a file, sends it to an LLM for
   summarization, writes the result. Demonstrates single-turn usage with
   `InputAddress` and `Destination`.
 
-- **llm-multi-turn-analysis.json** — Three chained LLM calls sharing
+- **llm-multi-turn-analysis.json** -- Three chained LLM calls sharing
   a `ConversationAddress`: initial analysis, follow-up question, and
   final synthesis. Demonstrates multi-turn conversation with persistence
   to GlobalState.

package/docs/features/platform-cards.md

@@ -1,6 +1,6 @@
 # Platform Cards & Task Types
 
-Ultravisor's operation graphs are built from cards (task types). Platform cards handle the infrastructure layer — address resolution, file transfer, and result delivery. Extension cards handle beacon dispatch. Beacon cards are auto-generated from registered beacon capabilities.
+Ultravisor's operation graphs are built from cards (task types). Platform cards handle the infrastructure layer -- address resolution, file transfer, and result delivery. Extension cards handle beacon dispatch. Beacon cards are auto-generated from registered beacon capabilities.
 
 ## Platform Cards
 
@@ -52,7 +52,7 @@ Encode a staging file to a base64 string or decode a base64 string to a staging
 
 ### beacon-dispatch
 
-The generic card for dispatching work to beacon workers. Most users won't use this directly — catalog-generated beacon cards provide typed wrappers.
+The generic card for dispatching work to beacon workers. Most users won't use this directly -- catalog-generated beacon cards provide typed wrappers.
 
 | Setting | Type | Required | Description |
 |---------|------|----------|-------------|
@@ -79,7 +79,7 @@ When a beacon registers with action schemas, Ultravisor auto-generates typed tas
 ```mermaid
 flowchart LR
     A[Action Schema<br/>from beacon registration] --> B[_registerCatalogTaskTypes]
-    B --> C["Task type: beacon-mediaconversion-imageresize<br/>Settings: InputFile, OutputFile, Width, Height, Format, Quality<br/>Execute: beaconDispatch → enqueueWorkItem → WaitingForInput"]
+    B --> C["Task type: beacon-mediaconversion-imageresize<br/>Settings: InputFile, OutputFile, Width, Height, Format, Quality<br/>Execute: beaconDispatch -> enqueueWorkItem -> WaitingForInput"]
 ```
 
 The naming convention is: `beacon-{capability}-{action}` (lowercased, non-alphanumeric replaced with hyphens).
@@ -90,10 +90,10 @@ The naming convention is: `beacon-{capability}-{action}` (lowercased, non-alphan
 2. Coordinator's `_updateActionCatalog()` stores them persistently
 3. `_registerCatalogTaskTypes()` iterates the catalog and creates a task type config for each entry
 4. Each config gets an `Execute` function via `_createBeaconDispatchExecutor()` that:
-   - Coerces setting types (template-resolved strings → numbers/booleans per schema)
+   - Coerces setting types (template-resolved strings -> numbers/booleans per schema)
    - Calls `beaconDispatch()` helper to enqueue the work item
    - Returns `WaitingForInput` with `ResumeEventName: 'Complete'`
-5. Built-in task types take precedence — catalog types are only registered if no type with the same hash exists
+5. Built-in task types take precedence -- catalog types are only registered if no type with the same hash exists
 
 ### Current orator-conversion Actions
 
@@ -116,7 +116,7 @@ The naming convention is: `beacon-{capability}-{action}` (lowercased, non-alphan
 
 ## Binary Output Return
 
-When a beacon processes a work item that produces a file output, the result is transferred back to Ultravisor's staging directory as raw binary — no base64 encoding.
+When a beacon processes a work item that produces a file output, the result is transferred back to Ultravisor's staging directory as raw binary -- no base64 encoding.
 
 ```mermaid
 sequenceDiagram
@@ -129,17 +129,17 @@ sequenceDiagram
     Exec->>Exec: Download source file
     Exec->>Beacon: provider.execute(action, workItem, context)
     Beacon-->>Exec: { Outputs: { Result: outputPath }, Log }
-    Exec->>Exec: _collectOutputFiles → set OutputFilePath
+    Exec->>Exec: _collectOutputFiles -> set OutputFilePath
 
     alt HTTP Transport
         Client->>UV: POST /Beacon/Work/{hash}/Upload<br/>Content-Type: application/octet-stream<br/>X-Output-Filename: thumbnail.jpg<br/>Body: raw bytes
-        UV->>UV: recordResultUpload → write to operation staging
+        UV->>UV: recordResultUpload -> write to operation staging
     else WebSocket Transport
         Client->>UV: JSON: { Action: "WorkResultUpload", WorkItemHash, OutputFilename, OutputSize }
         Client->>UV: Binary frame: raw file bytes
-        UV->>UV: recordResultUpload → write to operation staging
+        UV->>UV: recordResultUpload -> write to operation staging
     end
 
     Client->>UV: JSON completion: { Outputs, Log }
-    UV->>UV: resumeOperation → send-result finds file in staging
+    UV->>UV: resumeOperation -> send-result finds file in staging
 ```

package/docs/features/reachability-matrix.md

@@ -50,23 +50,23 @@ sequenceDiagram
     UV->>UV: registerBeacon() stores BindAddresses
     UV->>UV: onBeaconRegistered("bcn-orator-conversion-...")
 
-    Note over UV: Probe orator-conversion → retold-remote
+    Note over UV: Probe orator-conversion -> retold-remote
     UV->>RR: HTTP GET http://127.0.0.1:7827/
     RR-->>UV: 200 OK (any response = reachable)
-    UV->>UV: Matrix: orator-conversion→retold-remote = REACHABLE (12ms)
+    UV->>UV: Matrix: orator-conversion->retold-remote = REACHABLE (12ms)
 
-    Note over UV: Probe retold-remote → orator-conversion
+    Note over UV: Probe retold-remote -> orator-conversion
     UV->>OC: HTTP GET http://127.0.0.1:8765/
     OC-->>UV: 200 OK
-    UV->>UV: Matrix: retold-remote→orator-conversion = REACHABLE (8ms)
+    UV->>UV: Matrix: retold-remote->orator-conversion = REACHABLE (8ms)
 ```
 
 ### Probe Details
 
 - **Method**: HTTP GET to the beacon's first BindAddress (`{Protocol}://{IP}:{Port}/`)
-- **Success criteria**: Any HTTP response (even 404) counts as reachable — we're testing network connectivity, not service correctness
+- **Success criteria**: Any HTTP response (even 404) counts as reachable -- we're testing network connectivity, not service correctness
 - **Timeout**: 5 seconds per probe
-- **Cache TTL**: 15 minutes — entries older than this are re-probed on next use
+- **Cache TTL**: 15 minutes -- entries older than this are re-probed on next use
 - **Trigger**: Probes fire on beacon registration and can be triggered manually via the API
 
 ### BindAddresses
@@ -79,7 +79,7 @@ BindAddresses: [
 ]
 ```
 
-These are IP addresses, not DNS hostnames — this avoids NAT/split-horizon DNS complications. The reachability service uses the first BindAddress to construct probe URLs.
+These are IP addresses, not DNS hostnames -- this avoids NAT/split-horizon DNS complications. The reachability service uses the first BindAddress to construct probe URLs.
 
 ## Matrix Storage
 
@@ -97,7 +97,7 @@ Value: {
 }
 ```
 
-Probing is **directional** — A reaching B doesn't guarantee B can reach A (asymmetric firewalls, NAT).
+Probing is **directional** -- A reaching B doesn't guarantee B can reach A (asymmetric firewalls, NAT).
 
 ## How resolve-address Uses the Matrix
 
@@ -107,7 +107,7 @@ When the resolve-address card receives a `RequestingBeaconID`, it consults the r
 flowchart TD
     A[resolve-address receives Address + RequestingBeaconID] --> B{Same beacon?}
     B -->|Yes| C["Strategy: local<br/>URL: context BaseURL"]
-    B -->|No| D{Check matrix:<br/>requesting → source}
+    B -->|No| D{Check matrix:<br/>requesting -> source}
     D -->|reachable| E["Strategy: direct<br/>URL: source BindAddress + context path"]
     D -->|unreachable / untested| F["Strategy: proxy<br/>URL: Ultravisor proxy endpoint"]
 ```
@@ -138,8 +138,8 @@ The Beacons screen includes a visual reachability map (SVG) showing:
 - Beacons as labeled circles arranged in a ring
 - Ultravisor as a center hub
 - Lines between beacon pairs, color-coded:
-  - **Green solid** — Direct connectivity confirmed
-  - **Red dashed** — Unreachable
-  - **Grey dotted** — Untested
+  - **Green solid** -- Direct connectivity confirmed
+  - **Red dashed** -- Unreachable
+  - **Grey dotted** -- Untested
 - Hover tooltip with latency and last probe time
 - "Probe All" button to trigger a fresh probe sweep