Tickets & the thread

A ticket is the one unit of work in Typillar. There is no separate idea, note, or task — everything you ask for is a ticket: scoped, named, and tied to the commits it produced, so a project is a legible history rather than a black box.

What a ticket is

Type a change into the Build thread and it becomes a ticket immediately. Your words are the ticket — kept verbatim as its description, with the opening of your sentence as its name. Nothing rewrites your request first and nothing reviews it: the build agent starts on it.

Every ticket carries:

a status — backlog, active, done, failed, or archived. A ticket you type into the thread starts active; one you park for later sits in backlog.
a type — goal, epic, feature, fix, or chore. Goals and epics are structure: they hold other tickets and are never built directly.
a priority and an optional due date.
free-text labels, so you can group work however you actually think about it.

All of them are editable in the Plan tab, which is where the tree of tickets lives.

The ticket in the composer

Above the message box, the composer shows which ticket the thread is working on.

Attach one by picking it from the searchable list — the whole backlog is there, not just the last few.
Detach it with the X. The thread then runs without a ticket, and the next thing you type becomes a new one.
Otherwise it stays attached — the thread never detaches a ticket on its own, even once it’s done, failed, or archived. Send a new message on a backlog, failed, or done ticket and it reopens to active, so a follow-up continues that ticket instead of minting a new one.

Attaching a screenshot or a PDF

You can paste or drop an image or a PDF into the composer along with your message — a screenshot of a bug, a design to match, a document to read from. It travels with the ticket as an attachment. Not every model can see: if the one you have selected can’t read the file type you attached, it refuses rather than silently ignoring it, and points you to the model picker instead. See Your models for which models read images and PDFs.

With a ticket attached, what you type is a message about that ticket and the agent keeps iterating on it. With nothing attached, what you type is a new ticket. That is the whole rule.

What the agent leaves behind

When the agent finishes a ticket, it closes it with a note: the decisions it made — the calls it took and why, where it went against the ticket, what it knowingly left undone. The note is the agent’s, not yours: it appends under your description, and a rebuild adds to the log rather than overwriting it, so the ticket accumulates the reasoning behind the code instead of losing it to the thread.

The next build reads it too. When a ticket is referenced later, the agent sees what earlier builds decided about it — so a choice made once doesn’t get quietly undone.

Your requests build — no gate

When you ask for something, it builds. There’s no button to click first: you talk and it builds. That’s the point of the conversational model — you stay in the thread and steer as it goes, rather than pre-clearing each step.

What keeps you in control isn’t a gate before the build; it’s that the agent asks you when a decision is genuinely yours, and that nothing reaches your production URL until you Ship. (A build does land an automatic preview — see A ticket is not a deployment below.)

When the agent asks

Mid-build, if the agent hits a choice only you can make — a product decision, a trade-off, a missing detail — it asks in the thread and pauses. Your reply is the next message, and the build resumes from exactly where it stopped. It asks about the things that matter and keeps moving on the things that don’t.

A ticket is not a deployment

A finished ticket gives you commits and a preview. It does not put anything live. Ship is a separate, project-level action: it deploys the project as it now stands — every ticket built since the last one — and it takes no ticket of its own. See Deploys & rollback.

Why this keeps you in control

You control…	Because…
Direction	the agent asks you about the decisions that shape the project.
What goes to production	code reaches your production URL only when you Ship.
Reversibility	every change is a commit, so any version can be restored.

The Plan tab — shape larger work as a tree of tickets before building.
Agents & the control plane — who writes tickets and who writes code.
Deploys & rollback — what happens when you Ship.