The local dashboard: your workspace, as the agent sees it

The local dashboard is a small web app that shows your workspace the way your agent sees it: products, what the agent knows about each one, onboarding progress, every recorded submission state, the things that need you, and follow-up dates. It runs on your machine only, contacts no directory, and was added in the 15 September 2026 release listed on the changelog. This guide covers how to start it, what each screen is for, and the rules it enforces.

Starting it

On Windows, use py -3 instead of python3 in the commands below (or python if that is your Python 3.10+ command). Keep your workspace in a private local folder outside OneDrive or other sync folders.

python3 scripts/dashboard.py            # opens 127.0.0.1:8765 in your browser
python3 scripts/dashboard.py --demo     # explore a throwaway sample workspace
python3 scripts/dashboard.py --port 8790 --no-open

It is Python 3.10+ standard library: no dependencies, no build step. Run it from your private workspace, the folder scripts/init-workspace.py created. Started from the shared delivery checkout instead, it only offers to create that workspace. The easiest route is still the one-line start prompt from the three-step start guide: the agent creates the workspace, starts the server and hands you the link.

The overview

The first screen answers “what needs me?” before anything else: CAPTCHA and two-factor handoffs the agent could not complete, platforms marked blocked, overdue follow-ups and unfinished onboarding. Below that come your products with totals per state group — needs you, problems, in review, scheduled, live — and the workspace health read from workspace.json. If you only open the dashboard once a week, this is the page to look at.

The product page

Each product gets a readiness checklist produced by doctor.py, the last session summary, its submissions with filters, the onboarding checks, the product brief, identity, permissions and notes. An “agent view” lists which files are filled in and which are still empty — useful when a session ends early and you want to know what the next one will ask about. The state vocabulary shown here is the tracker’s; the listing status glossary entry explains what each state means.

Recording outcomes, catalog and prompts

The Record outcome form writes through scripts/record.py and applies exactly the command-line rules: one of the distinct states, no links or secrets in notes, a public URL plus your attestation for live, a launch date at or after the floor for scheduled, and an explicit replace when a row already exists. The outcome recording guide goes through each of those rules and why they exist.

New product creates a blank folder from templates/project and hands you either the onboarding prompt for your agent or the forms to fill yourself. Catalog lets you search and filter all platforms, read any playbook, overlay one product’s status and record directly from the list. Agent prompts and docs shows the agent prompts with copy buttons and renders the kit documentation in place, so you rarely need to open the markdown files by hand.

What it will never do

The boundaries are deliberate and worth knowing before you rely on it:

• It binds to 127.0.0.1 and rejects cross-site requests.
• It edits only the product JSON and markdown files the agent also edits. credentials.json is shown as platform, method and state; its values are never sent to the browser.
• It does not submit anything, does not control a browser and does not verify a listing. Recording a state is an operator statement, not evidence — the dashboard makes that statement easy to make and hard to make wrongly, nothing more.

Where the dashboard sits between the product, the agent and the directories is drawn out on the how-it-works page. If you want to try it with no workspace of your own, --demo is the way in.