The factory is where you land after signing in. It opens on what your factory delivered and what it cost, then what needs you; every task and plan reads as the story of how it went. Tasks, lanes, plans, automations and reports are all reachable from it, so you have one place to answer "what did we get, and what needs me?".
What it is for
The factory answers "what was delivered, what did it cost, and what needs me?". Mission Control, one click away, answers "what is running right now?".
The distinction matters when you have more than a couple of tasks in flight. The factory is where you decide; Mission Control is where you watch.
The overview
Choose this week or this month, and every project or one, under the title.
- Three figures: pull requests merged, work finished and money spent, each compared with the period before ("4 more than last week"). Merged counts every pull request merged in your connected repositories, whoever opened it, and says how many Coroid made ("11 by Coroid"). Choose a figure to see it over the last eight weeks or months; the cost per pull request Coroid merged sits under the chart. The figures come from records, never from a model.
- Needs you lists only decisions someone must take: a plan to approve, work to review or merge, a test issue no task owns, a request to accept, and work that failed or is blocked. Its heading counts them; the first five show, and Show more adds the rest. Open a row for its one action, or set it aside with "Not now".
- Projects shows one row per project with work in the period, most merged first. Open a row for the project's own figures, its work under way, whether what shipped is healthy in production, and how the work went: how often QA passed it the first time, and how long work takes from request to delivery. Projects with nothing in the period fold into one row ("4 projects are idle").
- Finished this week lists the outcomes, newest first; routine automation runs fold into one line.
- All work opens the full list of tasks, lanes, plans, automations and reports, by status.
When the work is merged, use Releases to follow the selected commit through readiness, deployment attempts, and environment health. A completed task or promoted lane is not a deployment result.
- Upgrade uuid (breaking change) is blockedcoroid-expo · 2 days ago
- Pin our GitHub Actions and let Dependabot keep them current stoppedcoroid-expo · 4 days ago
- Pin our GitHub Actions and let Dependabot keep them current stoppedcoroid-expo · 4 days ago
- coroid-expo9 merged · 7 finished · US$17.41 · 10 waiting for you
The Factory overview: the week in three figures and a chart, what needs you, and one row per project. Illustrative data.
Clearing many decisions at once
When old work piles up in Needs you, choose rows together: hover a row and its dot becomes a checkbox, or use Select beside the heading (on a phone). Select all chooses every row. Then:
- Not now sets the rows aside for you until their work changes. Others still see them.
- Close for everyone (owners and admins) archives the plans, cancels the tasks waiting for review, and dismisses the rest (failed work, test issues, requests) for the whole organisation until their work changes. Coroid asks first, and nothing is deleted.
Deciding a merge
A plan that is ready to merge opens at its decision: how long it has waited, what merging does ("Merging puts it on coroid-expo's main branch."), a line of facts (its tasks, its checks, the pull request), and closed sections for what changes, anything worth knowing, the evidence and how it got here. Approve and merge asks once more before merging; Other options holds Request changes, Ask about this, the pull request and the branch name.
How a piece of work went
Open a task and it reads as its thread: one sentence of what happened (or what is happening now), a line of facts (criteria passed, time, cost, QA rounds), a tracker through Asked, Planned, Built, Checked and Delivered, and the messages that got it there: the request, each work order, what the Developer and QA reported, your team's replies, and how it ended. When QA sent the work back, those rounds fold into one line you can open.
Choose a message to see its record: the work order, the checks, and the run with its model, tokens and time, with a way into the full trail. "About this work" holds the specification, who asked, the plan, quality and cost.
A plan reads the same way: its phases as the map, each task with how it went, and how many tasks QA passed the first time.
Work that stopped says so in red, with what is safe ("Safe: main is unchanged."), why it stopped (its last messages and the recorded failure) and Retry now.
At the end of a thread you can:
- Reply, and mention people with @; they are notified with a link.
- Ask the assistant about the work. It reads the thread to answer ("Why was it sent back?") and links to what it found.
- Share it with people in your organisation; they get a notification with its link. Nobody outside your organisation can open it.
- Copy as brief: a short summary with the outcome, the facts and the link, to paste anywhere.
Watching a task run
Open a running task to follow it live: the steps taken, tools called, files touched, and test output as it accumulates.
This is worth doing a few times early on. Watching two or three tasks end to end teaches you more about how to write a good specification than any amount of documentation — you see exactly where an agent had to guess.
After that, stop watching. Notifications will tell you when something needs you.
Intervening
You can pause, cancel or send a running task back with comments. See When a task gets stuck or fails for when each is right.
Automation
Work does not only start from someone typing a description:
- Automations start work on a schedule or when something happens, such as a pull request opening. They are listed under Automations.
- Schedules run work on a recurring basis.
- Hooks react to platform events.
- Reports summarise what happened, on a schedule.