Appearance
Dashboard
The Dashboard is your home view — a single page that answers "what is the orchestrator doing right now, and how did recent runs go?" Every row in its table is a record: one ticket the orchestrator picked up and worked (or is working) through the workflow. If you only keep one page open, it's this one.
Use the Dashboard to:
- Check what's running right now and how far along each run is.
- Spot failures quickly and jump into the details.
- Find a past run by ticket title, id, Lane, or state.
- Start a new Lane (the New Lane button, top right).
The stat cards
Four cards across the top give you the orchestrator's pulse:
| Card | What it shows |
|---|---|
| Active | Runs in progress — anything that hasn't finished yet (Picked Up through Notifying). |
| Completed | Runs that finished successfully (state Done). |
| Success rate | Done ÷ all finished runs (Done + Failed + Cancelled). Shows — until at least one run has finished. |
| Total spend | Combined cost (USD) reported by the runs loaded on this page. Metered runs report real bills; subscription-auth runs report an API-equivalent estimate (what the run would have cost on a key — not a bill). The card sums both kinds together; for metered-only spend totals, use Analytics. |
The cards summarize the records loaded into the page (the most recent 100) — they don't change when you apply filters below.
The records table
One row per record, newest activity first:
| Column | Meaning |
|---|---|
| Lane | The Lane that picked up the ticket. |
| Ticket | The ticket's title and external id (e.g. the GitHub issue number). |
| State | Where the run is in the workflow — see the state guide below. |
| Model | The Claude model the run used (e.g. Opus 4.8, Haiku 4.5). |
| Updated | The last time anything happened on this record, in your local time. |
| Duration | Total wall-clock time. Still counting for active runs; final time for finished ones. |
Click any row to open the Record Detail view — live logs, the phase stepper, the event timeline, generated artifacts (PRD, design, QA report), PR links, and the Cancel / Rerun actions. The Dashboard is the overview; Record Detail is where you investigate one run.
The run page (Record Detail)
Click any row to open the run's own page. Top to bottom:
The action row. Cancel (in-flight runs), Rerun (finished runs — a preflight first live-checks the previous PR's real state and clears stale lifecycle labels, offering one-click fixes for anything blocking), Resolve (only on runs whose PR conflicts with a newer merge — one scoped agent pass over the conflicting hunks, cheaper than a re-run; see When work overlaps), and Delete (removes the run from every list; it still counts toward monthly usage).
Ticket snapshot. The frozen copy of the ticket exactly as the run saw it — title, labels, description, and the comment thread (a thread outcome outranks the description).
The phase stepper. Where the run is in the workflow. A failed run marks the phase it died in; phases that were skipped by configuration show a neutral glyph.
Model & route. Which model actually ran, its reasoning effort, and why that model — the route shows whether a per-type rule, the Lane's pin, or your account default decided it.
Cost telemetry. Per-run token and cost figures. Tokens are always real; dollar figures under subscription auth are API-equivalent estimates, not a bill.
Live Output (opt-in). Press Go live to stream the run as it happens — phase transitions, lifecycle events, and the runner's own output, line by line. Idle by default (it costs nothing when off); the buffer keeps the most recent lines and says when it trims.
Artifacts. The run's working documents, rendered: requirements (PRD), design notes, the tests manifest, the developer's summary, and the QA report with its verdict and confidence. On finished runs, Download all grabs the set.
Repos & PRs. Per repo: the branch the run pushed and the PR it opened, with live PR state. A conflict badge appears here if a later merge made the PR conflict.
Events. The run's full lifecycle log — every state change, notification, and intervention, timestamped.
Ticket types
Next to a ticket's id you may see a small ticket-type chip — derived from the tag on the ticket (its tracker type, a recognized label, or a [type] prefix in the title). A chip comes in two flavors:
- Mapped — a filled, colored chip showing a display name you configured (e.g. a
feattag rendered as a pink Feature chip). - Verbatim — a neutral outlined chip showing the raw tag as-is, because no rule maps it yet.
Configure the mapping in Settings → Ticket types: a flat table of user tag → display tag, each display tag owning a color. Rows that share a display name collapse into one type and share its color. On a single run, the Record Detail header lets you override the type manually (or set it back to Automatic).
Seed taxonomy
New tenants start with a seven-type default table (the Restore defaults button re-adds any you've deleted without touching your own rows):
| Type | Color | Tags folding in |
|---|---|---|
| Bug | #FBBF24 | bug, defect |
| Feature | #34D399 | feature, feat, enhancement |
| Refactor | #22D3EE | refactor, refactoring, tech-debt, techdebt |
| Spike | #A78BFA | spike, research |
| Risk | #F87171 | security, risk, hardening |
| Chore | #60A5FA | chore, maintenance |
| Docs | #F472B6 | docs, documentation |
Seeding is tracked per tenant so upgrades add only the new rows once, and a default row you delete is never silently re-seeded.
Auto-add and the delete-returns rule
Any tag Tenbi extracts that no rule covers is added automatically — a row named exactly the raw tag, with the next color from a fixed rotation. Auto-added rows are ordinary: remap, recolor, or delete them like any other. Because auto-add re-checks on every extraction, deleting a row whose tag still appears in incoming tickets re-adds it (with a fresh color) on the next run — remap it instead of deleting live vocabulary.
GitHub label policy
For GitHub tickets (native tracker types and title [type] prefixes are unaffected), labels become a type through four layers:
- Workflow labels are excluded. Your Lane's pickup/redo/lifecycle labels (e.g.
ai-eligible,ai-in-progress,ai-redo) are never used for typing — even if a mapping rule names one. Such a row shows a warning in the pane. - Recognized labels are the seed taxonomy above (plus
fix) together with every tag named by one of your rules. - The first recognized label wins, by seed-table row order (Bug tags first, then Feature, …), then your rule tags.
- If no label is recognized, Tenbi falls back to the title
[type]prefix.
Understanding states
The colored pill in the State column tells you where a run is:
| State | What's happening | Anything to do? |
|---|---|---|
| Picked Up | The ticket matched a Lane and a record was created. | No — it advances on its own. |
| Queued | Waiting for a free run slot (concurrency caps), or — on an Optimize Lane — for artifacts to be ready. | No — it's admitted as slots free up. |
| Starting | Workspace and runner are being provisioned. | No. |
| Planning | The PM agent is turning the ticket into a requirements doc (PRD). | No — but you can watch live in Record Detail. |
| Coding | Design, tests, and implementation. Usually the longest state. | No. |
| Reviewing | The QA agent is adversarially reviewing the work. | No. |
| Finalizing | Committing, pushing, and opening the PR. | No. |
| Notifying | Posting the ticket comment / notifications. | No. |
| Done | Finished — a PR is open and waiting for you. | Yes — review the PR. |
| Failed | The run stopped with an error. | Open the record: the failure callout explains why, and Rerun retries it. See Troubleshooting. |
| Cancelled | Someone cancelled the run. | Rerun it if it was cancelled by mistake. |
A run normally flows top to bottom through this list. The orchestrator keeps the human checkpoint at the end: Done means "ready for your code review," not "merged."
Finding a run
Three filters sit above the table and combine with each other:
- Lane — show only one Lane's records.
- State — show only records in one state. Tip: filter on Failed for a quick triage pass.
- Search — type any part of the ticket title or its id.
Clear a filter with the small ✕ in its field.
Data freshness
The Dashboard loads when you open it and updates when you press Refresh (top right) — it does not auto-update. So if you're waiting on an active run, either press Refresh now and then, or open the record itself: Record Detail streams live, with logs and state changes appearing as they happen.
Common questions
A ticket I labeled isn't showing up. The orchestrator checks for new tickets about every 30 seconds, so give it a moment and press Refresh. If it still doesn't appear, walk the checklist in Troubleshooting → No tickets picked up.
A run shows Failed — now what? Click the row. The red callout at the top of Record Detail states the reason (for example, a missing Anthropic credential points you to Settings), and the logs show exactly where it stopped. Fix the cause, then press Rerun — reruns re-fetch the ticket, so edits you made to the ticket are picked up. The triage order is in Troubleshooting.
Duration keeps growing but the state hasn't changed. Coding is genuinely long on real tickets (often many minutes). If a run sits in one state far longer than usual, open the record and check the live log — a stuck run is eventually failed automatically by the orchestrator's watchdog.
Total spend looks off. Subscription-auth runs' cost figures are estimates, not bills; the card only adds up what the API reports. Per-run cost lives in Record Detail, and trends live in Analytics.