Train, monitor, manage · Lesson 1 of 6
How does Work track a ticket, and what is on the case file?
Published September 25, 2026
Work is home: one row per ticket, in three views. By stage is the map, Waiting on you is the queue, Latest is the log. Each row is the stage pie, the title, one sentence, the Agent, and an age. Open a row and its case file holds the whole record, with the decision it needs in the footer.
What is Work?
The first screen after you sign in, and the one you come back to. One row per ticket across every Team you can see, with a segmented control in the header for three views, carried in the address so a link opens the view it was copied from.
By stage is the map: sections in pipeline order, the tickets waiting on you first inside each. Waiting on you is the queue: grouped by the kind of ask, oldest first, and the case file’s Item N of M pager is how you walk it. Latest is the log: newest event first, a band for what happened since you last looked, then earlier today, then folded days.
What are the six stages?
The only stage words, on Work, on the Team page, in Slack, and in the code. Each is owned by the Agent whose craft it is.
| Stage | What it means | Who owns it |
|---|---|---|
| Proposed | Waiting for a person to say yes | Bailey |
| Plan | Someone said yes; a plan is being drafted or awaits approval | Reeve |
| Build | An approved plan is being implemented on a branch | Wright |
| Review | A pull request is open and under review | Proctor |
| QA | The change is being walked in a browser | Fletcher |
| Done | The pull request merged | A person |
An open ask decides the stage over anything else: a ticket with an unanswered Accept proposal reads Proposed even if planning began. An accepted ticket that nothing on its Team will start says so, “Plan · nothing will start this”, rather than sitting quietly. A finished ticket reads its outcome on the pie: green when it shipped, flat gray when it closed with no work landed, and a red wedge for a review or QA verdict with open findings.
What does a row say?
The same five things in every view: the stage pie, with its ring showing the state (waiting, working, stopped, queued, settled); the title, with the tracker key and the tracker assignee; one sentence naming what last acted and, when a person is waiting, who; the acting Agent’s mark; and an age whose meaning follows the view: time in stage, time waiting, or time since the event. A Proctor review of a pull request a human opened is its own row; a review or QA case of a Team-authored ticket folds onto that ticket.
What is on the case file?
Everything the ticket is, on one page: the proposal and its case, the plan with its questions answered inline and its revisions, Reeve’s check, every run and what it cost, the pull request, Proctor’s review with the findings it discarded readable behind it, Fletcher’s video and screenshots, the decisions a person answered and who answered them, and the Receipt that closed it. Each run opens to what the Agent read, what it changed, which Playbook rules applied, and which decisions it grounded itself on.
How do you answer a decision?
In the footer of the case file, which stays put while you read. It shows the label, one sentence of consequence, a secondary verb, and the primary verb rightmost. On a proposal: Doesn’t need work, or Start plan. On a plan: Send back with a note, or Approve plan, which counts the questions answered and waits until they all are. A build that stopped to ask for something only a person has reads Stopped to ask, and answering it resumes the run. On a ticket in Review with a pull request: Request changes with your notes, or Merge when your workspace has the in-app switch on, otherwise Merge on GitHub. After you act, the footer shows the stamp, Archive, and Next item. There is no “not now”: closing the page leaves the decision waiting, and the morning reminder covers it.
How do tickets get onto Work?
Three ways, each with its door. Add tickets opens a full-screen picker over the connected trackers, with search, source, status, assignee, priority, and sort; select several and Start N on your Team puts them in Plan. Bailey proposes from the Team’s backlog on its rhythm, and a Team on your own tickets lists them under Proposed with Start on each row. And the @yagni rail starts a ticket that is not filed yet: describe it, and it lands in the tracker and on Work in Plan. There is no form for writing a ticket.
What does the rail do here?
The right rail is @yagni, scoped to what is in the center. On the list it reads across your Teams and starts tickets. On a case file it knows the ticket, its plan, its review, and its decisions, so “why did Reeve flag this” comes back with the rule that fired and the ledger entry it read. It explains and it starts; it never replaces the footer. More in asking @yagni.
Common questions
How is a ticket on Work different from the ticket in my tracker?
The tracker's ticket stays in the tracker and stays the source of truth. The row on Work is YAGNI's record of what a Team did with it: the plan, the runs, the pull request, the review, the decisions a person answered, and the cost. The row keeps the tracker key and the assignee, and nothing is reassigned or closed until the merge.
Do I have to answer decisions on the case file?
No. A decision is one ask with several render points: the case file, and a Slack message to the person it is addressed to. Answering it in either place resolves it everywhere. There is deliberately no second approvals queue, and the tray never asks you to decide anything.
Can I see what a ticket cost?
Yes. Each run on the case file shows what the workspace was charged for it, and the case file totals the ticket. It is the same rate card developers using YAGNI Code bill on, so a ticket and an engineer's afternoon are comparable numbers, and Usage adds them up per Agent and per developer.
Who sees which tickets?
Your Work is composed for you: every ticket on a Team whose audience includes you, and nothing else. A Team seen by everyone is readable across the workspace; a members-only Team by its members; a Team on one person's own tickets by that person and admins. A sensitive scope can exist without leaking into everyone's view.