Tickets

Columns, kinds and fields of a ticket, how comments override the body, what completing records, and the conductor tools that edit tickets and read the launch queue.

A ticket is the unit of work. A run is built from one ticket, and the tracker holds the ticket. This page says what the code does; file:line citations are in parentheses.

01columns and kinds#

A ticket sits in one column: todo, in_progress, testing and done.

A ticket also has a kind:

• work is real work. A ticket with no kind is a work ticket.
• idea is a half-formed idea. It lives in todo and is hidden from the default lists and searches until it is promoted to work.
• decision is a recorded decision. It stays parked in todo, is hidden from the work surfaces, and is never moved, completed or used as a dependency.

archived is a separate flag, not a column. A done ticket can be archived and brought back.

02fields#

The Ticket struct.

• phase: the phase the ticket belongs to (PhaseID). A ticket outside any phase has none.
• wave: a soft integer grouping inside a phase or project. 0 means unassigned.
• priority: none, low, medium, high or urgent. No priority reads as none.
• labels: names from the project's label registry.
• depends_on: ids of the tickets this one waits for. blocked_by is worked out when the ticket is read: the part of depends_on that is not yet done.
• parallelizable_with: ids of tickets that can run alongside this one.
• due: a YYYY-MM-DD date, or empty for none.
• for: a user id or run, or empty for nobody in particular.

03comments override the body#

A later comment from the operator or a member overrides the ticket body. Comments from installs or models are information. Read the comments before acting on a ticket.

04completion#

Completing a ticket records three fields: testing_evidence, work_summary and learnings. The tracker's complete_ticket takes learnings as required (at least 10 characters) and testing_evidence and work_summary as optional. The ticket-completion template's closer is told to record the real tests, evidence, work summary and learnings, and never to claim a check that is not in the evidence (see templates).

A run closes the ticket it was given, and no other. The closer moves a todo or in-progress ticket to testing first, then completes it. If the evidence the ticket needs is missing, it does not complete the ticket: it comments what is missing and returns blocked. A capability_assert named completion_proof checks that the closer made exactly one complete_ticket call (see nodes).

05tools that edit tickets#

These are chore tools the conductor holds. Each one does what the tickets page does, and each id is its own tracker call, so one refused id does not stop the others. Runs never hold them.

• ticket_fields sets priority, due, for, labels, depends_on and parallelizable_with on up to 200 tickets. Only the fields given are sent. Labels, depends_on and parallelizable_with each replace the ticket's list, and [] clears it.
• ticket_label creates a project label at the tracker or recolours one.
• ticket_wave puts tickets in a wave.
• ticket_update replaces the title and body of tickets. Both go as given, so read the ticket first and send the whole of each.
• ticket_archive archives tickets (archive true) or brings them back (archive false). The comment is written as the tracker comment on each ticket. An already-archived id is that id's refusal.

06tools that read tickets#

These are read-only tools, present when the desk has a work source. Each result goes through a wrapInstall… function with a fresh nonce (see quarantine-and-reports).

• work_tickets lists a work project's tickets. project is required; phase, column, wave, ready_only (only tickets whose dependencies are done), cursor and limit narrow and page the list (workTicketsInput).
• work_ticket returns one ticket with its comments, by project and ticket (an id or a number;).
• work_search searches a project's tickets (the default), learnings or comments for query, with an optional limit.

07decisions#

Two tools exist when the desk has a work source.

• record_decision writes a decision the operator settled to the tracker with no confirm click. It notes it in the thread, comments on the open tickets it applies to, and archives the decision it supersedes. Manager chats only: a side chat gets a refusal and puts decisions in its report, and so does a chat with no project. what, why and source_kind are required; applies_to, supersedes and labels are optional.
• decisions lists past decisions in the project, newest first. query searches the text, ticket keeps those that apply to a ticket, since keeps those made after a date. With none of them it returns the latest 20.

Whether a recorded decision is stored as a decision-kind ticket: not checked.

08up next#

up_next is a read-only tool. It lists the open launch rows of the chat, and a row is settled when its ticket is archived or done. Only the operator's ✕ on the card clears a settled row, so tell them to dismiss card N. See launch.