Overview, Decisions and Activity

Today is the top group of the sidebar: Overview, Decisions, Activity and Tickets (see Tickets). Overview is the board, Decisions is the inbox, Activity is the list of agents at work.

Overview

The board is called Happening now. Its first row is five counters. Each one opens the view behind it.

Below the counters the board shows Needs attention (the six newest pending decisions, with All decisions →), Actors (running sessions and queued pipelines), Runner groups (groups with live instances or currently in error) and, when any exist, Actors ↔ runners (which actor is on which runner group, including a launch that is still pending).

Decisions

A decision is something an actor stopped to ask a person. The list column on the left holds the pending ones; the detail pane on the right shows the selected one. The list selects the first decision you can answer, and after you answer one it lands on the next.

Each row shows a state dot, the title, actor · kind · age, and a Not yours tag when it is addressed to someone else. If the platform returned more than the list holds, the footer says Newest N of M — the rest are in the staff inbox.

Kinds

The buttons are whatever the decision allows. Approve, Deny and Ignore have fixed labels; a decision can send its own labels, and a founder option reads Option A, Option B… unless the card names it. Hover a button to read what that answer does.

Answering

1. Select the decision. Read the body, the facts and What each answer does.
2. Type a note if you want one. The box stays pinned under the content so the answer is always reachable.
3. Press the answer. The decision leaves the list at once, a toast says Recorded "" (with your note, if any), and the app re-reads the pipelines.

If the platform refuses the answer, the banner says Could not record the decision with the reason, and the decision stays.

Plans

A Plan to review shows the plan's goal, its markdown, and the tickets approval would create, each with its repository, a size badge, its dependencies (After <key>, or Starts when you approve), acceptance, expected result, files and out-of-scope notes.

• Size. Before you answer, the app asks the platform to validate the plan (ticket.plan.validate) and badges each step that is too big for one coding session. Approving a plan with an oversized step would create nothing, so the notice offers to send it back to be split. A platform without that workflow shows no sizes.
• Repository readiness. A warning appears when a step targets a repository the coding lane cannot build yet: approved, it would park instead of being coded. Fix the repository under Coding, or deny with a note asking for a ready repository.
• Revision. The note box reads "What should change?". A revision request carries your note to the planner. See Agents and Coding for planning across repositories.

Who can answer

The app never guesses: the platform's can_decide per decision is the answer, and a missing value counts as answerable.

Founder decisions

A founder card is a question from the delivery desk about a ticket. The detail shows:

The list shows a founder decisions digest as one item per class per day. A digest allows only Ignore, which dismisses the summary; the real decisions are cards on the tickets.

Right-click a row

Open Session, Copy Question, Copy Envelope ID, Open Cockpit on the Web.

Activity

The list column holds Sessions (running agent sessions) and queued pipelines (the ones still waiting for a session). Selecting a session opens its inspector.

The header shows the status, the model, the session UUID, steps, tool calls (and how many failed), tokens and when it started, plus the compute it ran on.

Stop… asks the platform to stop an open session and prompts for an optional reason. The tag reads Stopping… while the runner winds down after its current tool call (or the platform forces it after a grace period), then Stopped. The inspector re-reads every 5 seconds while it stops. Older platforms mark the session cancelled at once.

Live updates

Notifications

Only decisions addressed to you notify. Each pending decision notifies once: the app remembers which it has already reported (up to 1000, kept between launches), so one that flaps out of a refresh and back does not alert twice.

Clicking a notification opens that decision. The app also keeps an attention badge in step with the pending decisions. To check that the operating system really shows alerts, use Send Test Notification from the command palette.