How a Code thread works

A Code thread is a conversation about one piece of work; each change you ask for in it runs as a task. This page explains the states a task goes through, how each one ends, and what is kept. For how to steer a task while it runs, see Steering and saved points.

The rule#

Ysra does what you asked, at the size you asked for, and says plainly what it ran. A small ask gets a small change, with no tests or setup you didn't ask for. Nothing you or Ysra did is thrown away in any end state.

Is it a question or a change?#

Every message in a thread is read first, and only a change starts paid work.

When it's unclear, Ysra treats the message as a question. Starting paid work in a thread needs your OK once; after that, changes in the same thread start directly.

Task states#

Continue on Didn't work, Stopped with a problem or Stopped starts a new task from where the last one stopped.

How a task ends#

Every ending has one plain receipt line that says what Ysra ran to check the work, and how it went:

Ran: `npm test` (passed).
Ran: `npm test` (failed); a look in the browser (desktop and phone).
Ran: nothing.
Ran: nothing (you asked me not to).

The same line goes into a pull request Ysra opens for the work.

When you say “no tests” or “just the code”#

“No tests”, “don't install anything”, “don't run anything” or “just the code” is respected from start to finish: Ysra writes the change, installs nothing, runs nothing to check it, and ends with “Ran: nothing (you asked me not to).”

Small asks get small changes#

Ysra sizes the work to the ask. Renaming a function or fixing a typo doesn't come with new tests, a new project layout or a running preview. Ask for tests or a check when you want them, and Ysra runs them and reports them in the receipt.

What happens when …#

A check fails#

Ysra reads the failure and repairs the change, then runs the checks again. It stops repairing when a fix no longer changes the result: trying again the same way wouldn't help.

If the project's checks still fail after that, the task ends Didn't work and says what failed. The change is kept; you can still use or deliver it.

Ysra stops making progress#

If a task keeps re-reading files without changing anything, or the same check keeps failing in the same way, the task ends and says what blocks it instead of spending more.

A step runs too long#

If a step can't finish, the task stops and says why in plain words. Your work is always saved: Continue picks up from there.

Credits run out#

Before each paid step, the task checks the balance. With none left it pauses: "I stopped at the limit set for this work. Your changes and what I checked are kept; add credits or raise the limit, then tell me to continue."

You set a limit on the task#

A task can have a time, credit or step limit. When it reaches one, it stops cleanly and says so; it never takes more on its own.

You stop it#

A queued or waiting task stops at once. A working task finishes its current step, then stops: "Stopped at your request." The changes made so far are kept.

The machine is lost#

If the machine running a task disappears, the task is picked up again automatically. If it keeps happening, it stops and says so: "I used up my automatic recovery attempts."

What is kept#

Undo changes… (for a folder on your computer) puts changed files back and removes the files the task created. If you edited one of those files yourself since, it undoes nothing and says so, so your own work is never overwritten. In the cloud, go back to a saved point instead; see Steering and saved points.

How to continue#

Limits#

Related#

• Plans and criteria — what "required checks" are and where they come from.
• Review and verification — reading the evidence before you deliver.
• Previews — seeing the app while it runs.
• Limits and costs — credits, cloud time and every cap.