your first ticket, all the way to main

follow one ticket from the tracker to a launch card, through a run and its gate, to a landed commit and a sync onto your branch, and learn which press is yours at each step.

this follows one ticket from start to finish. at every step something waits for you, and nothing reaches your main branch until you say so.

01the ticket#

a ticket is the unit of work, and a run is built from exactly one ticket (or, for a batch, a few small ones). it sits in a column, one of todo, in_progress, testing and done. most tickets are plain work tickets. an idea stays in todo and stays out of the default lists until it's promoted.

changed your mind about what you asked for? leave a comment. a later comment from the operator or a member overrides the ticket body, while comments from installs or models are only information. see comments override the body, and tickets for the fields.

02the launch card#

you talk it through with the conductor, and when it's ready it drafts a launch card. the card is one ask: the tickets it names, one template and a reason for the template. drafting starts nothing. the desk previews each run when the card is drafted, and you press go to start them. the conductor never presses go. see draft, card, go.

the conductor recommends the template:

• quick-fix for a small, well-specified fix.
• ticket-completion when the ticket needs a plan or a review.
• batch for several small related tickets as one run.

that list is in choosing a template.

go starts what the last preview showed. it fixes the preset (quick, balanced, thorough or max, and a blank choice is balanced), the versions of any assets plugged in, and the digest of the preview. if the digest has changed by the time you press, go is refused and the card offers go with the new plan. that's under what go freezes.

if the project has no checks, go refuses unless you tick "run without checks". see draft and go.

before a run builds, go lines the work clone up with the branch it tracks, so the run starts from where your branch is. see lineup.

03the run#

the run builds in a work clone of its own, not in your checkout. the ticket-completion template takes a ticket from intake through plan, work, checks, review and a human gate to a landed, closed ticket. the nodes behind that are on nodes and builtins, and the template itself on templates.

04the gate#

a human gate holds the run until you decide. review has graded the run's acceptance list, one verdict per item, and the gate is where you see that. you have three presses:

• approve, which lands the work. it is refused while an area that holds the gate has files you haven't ticked as looked at.
• send back, with a reason. the reason is required, and the next pass reads it. the planner isn't re-run, and work resumes with your reason among its inputs.
• reject, which ends the run as rejected with nothing landed. the ticket goes back to todo with your reason as a comment.

you can also edit the acceptance list at the gate: keep an item, reword it, drop it, move it to another ticket, or add your own. review then grades only the edited list. prose at the gate doesn't change the list, and only an edit does. a send back reason is read next to the list, and it never becomes a new graded item. all of this is in approve, send back and reject and the acceptance list.

05landing#

approve and the run lands its sealed handoff. that means commits in the work clone, one commit per ticket. land refuses a workspace that has moved since the handoff was sealed, so what lands is what review saw and you approved. see land.

when the run lands, the ticket closes behind it. a run closes the ticket it was given, and completing records testing_evidence, work_summary and learnings. see completion.

06syncing#

a landed run is not on main yet. a sync carries the commits from the work clone to the project's checkout and origin. the conductor drafts a sync card, and nothing starts until you press it. see propose_sync and the sync.

when you press, the sync works in a worktree of its own, so uncommitted work in your checkout is neither blocked nor touched. it applies the commits, runs the project's checks on exactly what will be pushed, and pushes to origin. a failing check stops the sync, nothing is pushed, and the branch stays where it was. the steps are under the click.

a project with no origin remote skips the push, and the card says "no remote: main moved locally, nothing pushed". a project in pr mode opens or updates a pull request instead of pushing to the branch, and the checkout's branch never moves until you accept it. see push mode and pr mode.

07where to go next#

gates and the acceptance list, launch cards and landing and syncing work hold the detail.