---
name: rpa-dashboard-no-ai
description: Builds a working dashboard page for an RPA bot that does not use AI. It always includes a sidebar and top bar with a dark toggle and status dot, KPI cards, a batch status donut, a run panel with steps and a live log, and a report table with search and Excel export. The page is wired to the bot through one data contract, or runs on sample data when there is no bot yet. Supports a desktop path (PyQt6 with an embedded page) and a web path. Use when the user asks for an "RPA dashboard", "automation dashboard", "bot dashboard", a dashboard "without AI", or a status/run/report page for a bot. For bots that use an LLM or OCR extraction, use rpa-dashboard-ai instead.
---

# RPA dashboard (no AI)

Everything this skill needs is bundled in `templates/`. Never read the original
source projects.

**Paths:** `templates/...` is in this skill's own folder (the one holding this SKILL.md),
not in the user's project. Below, `<skill>` is that folder's absolute path: run the
scripts as `python <skill>/templates/<script>.py`, from the user's project.

| File | What it is |
|---|---|
| `templates/dashboard.html` | The single-file page: theme tokens, shell, KPI, donut, run panel, report, sample data. Works in PyQt (QWebChannel) or on the web (polling). |
| `templates/bridge.py` | Minimal PyQt6 host: the window, the bridge slots, and the saved dark-mode choice. |
| `templates/bot_runner.py` | The bot wiring, without Qt. It runs the bot as a child process, tails its output, and turns lines into step and log events. |
| `templates/contract.md` | The data contract: events the bot sends, actions the page sends. |
| `templates/themes.md` | Theme presets (Tebra Sky, Superbill Ember) and the custom-colour steps. |
| `templates/palette.py` | Derives a custom palette from one brand hex and checks contrast. |
| `templates/sections.py`, `templates/sections.md` | Keeps the chosen optional sections in the page and deletes the rest; what each section needs from the host. |
| `templates/frontend.md` | Existing frontend: detect it, report it, then keep or restyle. Shared with `rpa-dashboard-ai`. |
| `templates/detect_frontend.py` | Finds an existing frontend and prints its location, stack and token blocks. |
| `templates/reference/` | Raw Tebra extracts, for reference only. The optional sections are already in `dashboard.html`. |

Follow the steps in order. Ask one question at a time, and wait for the answer.
If the user's request already answers a question, don't ask it again.

## 1. Scan the project

Before asking anything, look at the project:
- **Frontend:** run `python <skill>/templates/detect_frontend.py <project root>`. It finds
  plain HTML, React/Vue/Angular/Svelte apps and PyQt web views, and prints each
  one's location, stack and colour tokens. `templates/frontend.md` says what it
  covers and what to do with its report.
- **Bot:** the entry point (for example `main.py`, a `__main__` module or a run
  script), what it prints (step markers, status and error lines), and how it starts.

## 2. Report the frontend, then ask keep or restyle

Follow `templates/frontend.md` sections 2 to 5. In short:
- **No frontend:** say "No existing frontend found." and go to step 3. Don't
  describe a frontend that isn't there.
- **Frontend found:** say "Frontend found at `<path>`, stack `<stack>`, colours
  `<main tokens>`." Then ask: **keep its look**, or **restyle** it?
  - Keep: skip step 3. Build the page with the project's own tokens and fonts, and
    change no existing file.
  - Restyle: go to step 3. In the existing files, change only the token blocks,
    never layout or logic, and show the user the diff.

## 3. Ask for colours

Skip this if the user chose to keep the existing look. Offer:
1. **Tebra Sky**: blue glass cards on a sky gradient.
2. **Superbill Ember**: flat surfaces with a red-orange brand gradient.
3. **Custom**: the user gives one brand hex colour.

## 4. Ask desktop or web

Ask only if there is no frontend. If there is one, use its stack.
Don't ask if the project already uses PyQt (`PyQt6` or `PyQt5` in its requirements,
`pyproject.toml` or imports): choose desktop and say so.
- **Desktop:** a PyQt6 window with the page embedded. The page talks to Python
  through a bridge, so no web server is needed.
- **Web:** the same page, served by a backend that it polls.

## 5. Ask which optional sections to build

Always built: the shell (sidebar, top bar, dark toggle, status dot), KPI cards,
the status donut, the run panel and the report table.

Ask which extras to add, as one multi-select question (choose any, or none):
- **Checkpoint tracker**: numbered boxes in the run panel that show each checkpoint as
  pending, in progress, done or stuck.
- **Admin/roles screen**: an Admin tab, for admins only, to give people admin or
  operator access.
- **Login page**: a sign-in screen in the dashboard's theme. It's UI only and hands
  off to the project's own auth.

Build only the chosen ones. In step 6, right after copying the page, run
`python <skill>/templates/sections.py <copied dashboard.html> <chosen: checkpoints admin login>`.
It deletes the unchosen sections completely (markup, script and style), so nothing
is left behind. Never cut the blocks by hand. Then follow `templates/sections.md` for
each kept section: what to fill, which events the bot sends, and which host actions
to answer.

## 6. Build

1. Copy `templates/dashboard.html` into the project:
   - Desktop: put it next to the host, for example `dashboard/dashboard.html`.
   - Web: put it in the backend's static folder. With no backend yet, use
     `dashboard/dashboard.html`.
   - Existing frontend: put it where `templates/frontend.md` section 3 says.

   Then run `python <skill>/templates/sections.py <copied dashboard.html> <chosen sections>` (step 5).
2. Fill every `{{...}}` placeholder:

   | Placeholder | Value |
   |---|---|
   | `APP_NAME`, `APP_SUBTITLE` | The project's name and a short tagline. |
   | `LOGO_SRC` | The logo's path, or empty if there is none. |
   | `STEPS_JSON` | The run steps as a JSON list, from the bot's real stages, for example `["Initializing","Login","Process items","Completed"]`. |
   | `REPORT_COLUMNS_JSON` | `[{"key":..., "label":...}]`. It must include a column with key `status`, which shows the bucket pill. |
   | `API_BASE` | Web only, for example `/api`. Leave it empty for desktop. |

3. Apply the theme by replacing the `body{...}` and `body.dark{...}` token blocks
   with the preset from `templates/themes.md`. For Ember, also add its font link.
   For a custom colour, run `python <skill>/templates/palette.py "<hex>"`, paste the
   tokens it prints, and show the user its contrast table. If the user chose keep,
   fill the blocks from the project's tokens instead (`templates/frontend.md`
   section 4).
4. Desktop: also copy `templates/bridge.py` and `templates/bot_runner.py` next to
   the page. Fill `{{ORG}}` and `{{APP_NAME}}` in `bridge.py`, and `{{BOT_MODULE}}` in
   `bot_runner.py` (with no bot yet, use the module the bot will have, for example `bot`).
5. Search the output for `{{`. None may be left.

## 7. Wire the data

The contract is in `templates/contract.md`: one envelope, `{event, data}`, in
both directions.
- **No bot yet:** keep `SAMPLE_DATA = true` and the `SAMPLE DATA` block. The page
  answers its own data actions, so it opens with sample batches and report rows,
  and Run plays a demo run. Tell the user which events their bot must send later.
- **Bot exists:** set `SAMPLE_DATA = false` and delete the `SAMPLE DATA` block. Then:
  - Desktop: all the wiring is in `bot_runner.py`.
    1. Get the bot's real output: run it once (for example `python -m bot`), or read
       its `print` and logging calls. Never invent lines it doesn't print.
    2. Set `BOT_CMD` to start the bot as a child process, and `BOT_CWD` to the folder
       it runs from.
    3. Set `STEPS_JSON` in the page to the bot's real stages. Fill `STEP_MARKERS` with
       `(substring, step label, pct)`: one specific substring per stage (for example
       `[step 3]`, never a bare word like `login`), each label exactly one of the
       page's STEPS, and pct rising to 100 on the bot's last line. The first match wins.
    4. Fill `FRIENDLY_RULES` with `(substring, plain-English message, type)` for the
       lines an operator should see. Unmatched lines are hidden, except error lines
       (any line with a word from `ERROR_WORDS`), which are always shown as they are.
       Add the bot's own failure words to `ERROR_WORDS` if it uses others.
    5. Dry run without the window: `python dashboard/bot_runner.py`. It prints each
       event the page would get. Check that the steps arrive in order and end at
       100, and that the bot's error lines appear as `error` log events.
  - Web: the backend serves `GET {API_BASE}/dashboard`, `GET {API_BASE}/run/status`
    (returning `{running, events[]}`) and `POST {API_BASE}/<action-with-dashes>`.
  - Apply the contract's derived rules: batch state from Pending plus date, and
    report buckets from status.

## 8. Verify

Open the page. On desktop run the host (`python dashboard/bridge.py`), click Run,
and check that the Run button stays disabled until the bot finishes, and that the
dark-mode choice is still set after you close and reopen the window. Otherwise
open the file or the served URL.
With sample data, opening the file in a browser is enough. Check:
- the light theme, the dark theme (use the toggle), and a window 820px wide or less;
- KPI cards, donut and legend, the run panel's steps and log, and the Report tab's
  rows and pills all show data;
- no `{{` placeholders are left and the console shows no script errors.

If Python Playwright is installed, take headless screenshots of each check and
look at them. Otherwise, ask the user to open the page. Finish by telling the user
where the files are, which theme and sections were built, and whether the page is
on sample data or wired to the bot.