From the dashboard

After this page you can start a bee from the dashboard, attach files as context, watch the run live, answer the agent's questions from the browser, stop a run that has gone wrong, and find any past run. The contract holds here as everywhere: No human writes code. A human always reviews.

Run a bee from the dashboard: recipe tier, repo pick, and the skip-when-no-new-commits guard.

Getting in

The dashboard is behind Google OAuth. Sign in with your @3sidedcube.com Google account. No other domain is accepted, and there is nothing else to set up.

Starting a run

Go to Agents (/agents). The sidebar header has a Run a bee button; it opens a dialog with two levels:

• Swarm agent: the autonomous top level. Pick a project (a Hive Space), then either From Jira (pick a ticket from the Space's board, or type a key like PROJ-123 and hit Fetch to preview it) or From a request (describe the task in plain English). The repository field is optional and is scoped to the Space's GitHub Sources; leave it empty and the swarm agent resolves it from the ticket or project. Hit Dispatch swarm agent.
• Single recipe: drill into one specialised bee. Pick a recipe card (each card says what the bee does), then give it a Jira ticket or a freeform request plus a repository. A pre-flight strip checks GitHub access before you can submit (and Semgrep enrichment for tinfoil-bee). Cleaner-bee instead takes a repository and a commits-to-review count (1–50); if there are no new commits since its last successful run it's skipped, with a Run anyway override.

On success the dialog shows Deployed and the run appears at the top of the sidebar.

Attachments

The New job form at /trigger takes the same project + request fields plus optional attachments: images (PNG/JPEG/WEBP/GIF ≤ 10 MiB), PDF (≤ 25 MiB), or text (≤ 1 MiB), up to 5 files and 30 MiB total. Use it when the task needs a screenshot of a failing UI, a PDF spec, or a log excerpt. The agent reads them before it plans; their content is treated as untrusted context (it never changes the task itself), and each file adds to the run's token cost.

Watching the run

Clicking a run in the sidebar opens its Agent View (/agents/<pipelineId>). It updates live over server-sent events, so there is no refreshing. The header shows the run state in plain verbs: Working, Needs you, Done, Failed, Stopped.

The default Chat tab renders the run as a two-sided conversation: your request and replies as bubbles, the agent's markdown replies with a per-turn "Worked on this" disclosure, and every pause, block, and verdict as its own turn. A Conversation / Activity toggle flips to the raw event log. Alongside Chat sit Plan, Changes (the diff and any PRs), Test, and Logs tabs. Recipe bees read differently: a narrated Report tab instead of Chat, plus Changes, Findings, Config, and Ticket. When token streaming is enabled for the environment (SWARM_STREAM_TOKENS), the agent's text types in token by token.

Is it alive, and what is it doing?

While a run is Working, the status card at the bottom of the Chat tab shows the current plan step, the elapsed time, the tool the agent is using right now (the command it just ran, the file it just opened), and how recently it was last active ("active 12s ago", or "quiet 3m" if it has gone silent). The timeline gains a row for every tool call as it starts, so even a long step is never a black box.

If a run goes quiet for more than five minutes it is flagged as Stalled on its timeline, and the ops channel gets one alert. The moment activity resumes, a Recovered event clears the flag. A stall is a nudge to look, not a failure: the run keeps working and its state does not change.

Replying mid-run

Every run has a conversation composer at the bottom of its Chat tab. Send queues your message: if the agent is idle it goes immediately; if it's mid-turn, the message shows as a pending bubble and releases automatically when the turn finishes (Send now forces it). While queued you can still edit, cancel, or reorder messages. The composer also works on closed runs; sending reopens the same pipeline, exactly like replying in the Slack thread or on the Jira ticket.

Stopping a run

Any signed-in operator can stop a running run from its page: a Stop run button sits in the header whenever the run has a live task to stop. It opens a confirm dialog first, because a stop is final: the agent's task is killed, work in flight is abandoned, and it can't be undone. Once you confirm, every open viewer of that run sees Stopping... while the task drains, and the run then settles as Stopped.

Stopped is its own terminal state, in quiet grey, deliberately distinct from Failed: a run you chose to cancel should never read as a crash or poison the failure numbers. Who stopped the run, and why, is recorded on the run's timeline and in the audit log.

The stop cascades. Any child bee runs the agent dispatched are stopped with it and settle as Stopped too, and an in-flight E2E check is cancelled rather than left polling in the background.

Verification after Done

When the agent dispatches an end-to-end check (a real build-and-test pass of its change), the run itself settles as Done and the check keeps running in the background. The dashboard carries that tail so you never have to wonder whether Done was actually verified:

• A Verifying · E2E chip sits next to the run state, on the run header, the sidebar, and the runs list, until the check lands.
• One card in the Chat tab follows the whole lifecycle, Dispatched → Approval → Build → Result, updating in place. In flight it pulses and shows which stage it is on; once it lands it reads as a clear pass or fail, with the evidence (test report, build, preview) as links.
• A passed check goes quiet: the chip disappears and the card keeps the result.
• A failed check gets loud: the chip flips to E2E failed and the run moves to Needs you with an Approve / Deny ask. Approve retries the check (the retry raises a fresh approval card, so CI and device spend is still gated); Deny dismisses it.

Finding past runs

The sidebar is the run list: All / Awaiting me / Failed / Rejected tabs, a filter box for ticket keys, and a filter popover with a time range. You see the runs you requested, matched by your email whichever surface started them; admins get a toggle to view every user's runs (and an owner filter). Aggregate numbers live on Stats (/stats).

See it in action

Dispatching the swarm agent from the dashboard: project, scoped repo dropdown, free-text request.

A live run: request and agent panes, tool calls, the done banner, plan, and activity log.

The Bees directory, projects (created in Hive), and scheduled runs.

Needs-you: the agent pauses on an ambiguous ask, and your reply continues the run.

Stopping an in-flight run from its page: confirm, watch it drain, and the run settles as stopped.