> For the complete documentation index, see [llms.txt](https://fleet.hackmap.win/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://fleet.hackmap.win/guides/dashboard.md).

# Dashboard

A minimal operator UI served at `/` from the master. Single HTML page; no build step. The admin token is requested via `localStorage` on first load and reused for every fetch.

## Layout

A tab strip across the top. The first tab is always **graph**; one tab per registered automation follows. Each tab opens a pane.

```
+-----------------------------------------------------+
|  fleet               3 automations installed        |
+-----------------------------------------------------+
| [graph] [url-pinger] [cf-cookie-harvester] [hello]  |
+-----------------------------------------------------+
| (pane for the active tab)                           |
+-----------------------------------------------------+
```

## graph tab

Renders the catalog as a mermaid `flowchart LR`:

* One node per automation (highlighted in the accent colour).
* A queue node for any `BatchAutomation` (drawn as a parallelogram).
* A stream node for any automation with `Output` (drawn as a cylinder).
* A pool node for every entry in `Pools` (drawn as a hexagon). Pool nodes are de-duplicated when shared across automations.

Edges:

* queue → automation, labelled `consume`.
* automation → stream, labelled `publish`.
* automation ↔ pool, labelled `claim/put` (because automations both put items into pools and claim them).

Backed by `GET /api/v1/catalog`. Loaded lazily on first activation. See feature 7.1.

## automation pane

Each pane has six sections, top to bottom.

### Workers

A live table of every worker registered for this type. Columns: `worker`, `state` (IDLE/RUNNING/ERROR/DRAINING), `gen` (config\_gen), `slots` (current slot count from the latest Stats frame), `last seen` (HH:MM:SS local).

Auto-refreshes every 5 seconds while the pane is visible. Backed by `GET /api/v1/automations/{type}/workers`.

### Submit task

If the automation is a `BatchAutomation`, a form generated from the published `TaskPayload` JSON Schema:

* Each top-level property becomes an input, typed by `type` (number / checkbox / text / json textarea) and `enum` (select).
* `$ref` / `$defs` are resolved so nested model references render their real description and type instead of `$ref: #/...`.
* A collapsible **options** section adds the optional submit knobs: `priority`, `max_attempts`, `ttl_seconds`, `idempotency_key`.
* Submit POSTs to `/api/v1/automations/{type}/tasks`. The raw response is shown inline so duplicates (`{"duplicate": true}`), rate-limit 429s, and schema-validation 422s are visible.

For `ContinuousAutomation` types this section displays "this automation does not accept tasks (no TaskPayload declared)." See feature 7.3.

### Queue

`length` + first 20 pending tasks, refresh button. Backed by `GET /api/v1/automations/{type}/queue?n=20`. The peek is non-destructive; it doesn't drain the queue.

### Dead-letter queue

Same as queue but for failed tasks. Adds a **drain** button (with a `confirm()` prompt) that calls `DELETE /api/v1/automations/{type}/dead`. Use this carefully — the drained items are gone for good.

To re-enqueue DLQ items instead of dropping them, use `POST /api/v1/automations/{type}/dead/replay` from the CLI; the dashboard doesn't expose that today.

### Pools

For every pool declared in `Pools`, a card with `size` + first 20 items. Each item shows its id, tags, resolved payload, `expires_at`, and `in_use_until`. Refresh button per pool.

`in_use_until` is the most useful field here — entries with `in_use_until > now` are claimed by a slot. If you see entries stuck claimed long past their hold window, a slot crashed without releasing; use the worker drain endpoint to recycle it.

Backed by `GET /api/v1/pools/{name}`. See feature 7.2.

### Config schema

The raw JSON Schema of the automation's `Config`. Useful when you want to write a CI script that PATCHes config and need to know the fields without reading the plugin's Python.

## Securing the dashboard

Behind admin auth (`FLEET_ADMIN_TOKEN`). The token is held in `localStorage` so a stolen client also leaks it — don't paste it on a shared machine.

For multi-team setups, prefer the scoped-token model (`FLEET_TOKEN_SCOPES`) and a custom UI that prompts for a specific token: every per-automation endpoint already enforces scope at the master, and the catalog endpoint `/api/v1/catalog/{type}` is scope-gated too. The bundled dashboard is admin-only because it walks the unscoped `/api/v1/catalog` endpoint to discover types.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://fleet.hackmap.win/guides/dashboard.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
