Steering and checkpoints

A session isn't fire-and-forget. While it runs — and after it finishes — you can redirect it at any point, from the portal or your phone.

Everything you can do to a session#

Action	When to use it	What happens
Steer	The work is heading the wrong way, or you know something Ysra doesn't.	Your message is queued and applied at the next checkpoint, without restarting.
Answer	Ysra asked you a question and is waiting.	The answer unblocks exactly that question. Answers are kept separate from steering, so they never change the scope by accident.
Interrupt / resume	You need it to stop for now.	Work pauses at a safe point and resumes from the last checkpoint.
Cancel	You no longer want the result.	The session ends; the work so far stays inspectable.
Continue / retry	A session stopped on a boundary — budget, time, a transient failure.	It resumes with the same goal and the same candidate, not a fresh start.
Extend budget	It stopped at its ceiling and the work is worth finishing.	The ceiling rises by what you choose; the session continues.
Update permissions	It asked to install a package or use the network.	Approve once, or change the repository's policy.
Ask about the evidence	You want to understand a result.	Ysra answers from the session's recorded evidence — "why did the test fail?" — without doing new work.
Rewind	A later change made things worse.	The candidate returns to an exact earlier checkpoint.
Preview	You want to click through it.	See Previews.

Steering well#

Steering works best when it is specific and early:

Use the existing DateRange type rather than a new one.

Don't touch the checkout module — the bug is in the cart.

Up to three steering messages can wait in the queue at once. Each is marked applied only once a checkpoint has recorded it, so nothing you said can be silently lost to a restart.

Checkpoints#

A checkpoint is a saved, exact version of the work: the candidate, the plan, what has been checked, and the conversation so far. Sessions create them as they go — after implementation steps, after verification, after review.

Checkpoints are what make Ysra safe to interrupt:

Resuming after an interruption continues from the latest checkpoint with everything already established — it doesn't start over or forget.
Long jobs run in slices; each slice ends at a checkpoint and the next picks up from it.
Crashes are recoverable: another worker resumes from the checkpoint, not from memory.

Rewinding#

Open the checkpoint list for a session to see each version, labelled by what happened there — implementation, verification, review — with its diff.

When you rewind:

The exact candidate from that checkpoint is restored, byte for byte. Ysra never "re-creates" old work from a description.
The restored version becomes the newest version, and is marked unverified — the checks and reviews that ran later described different code, so they no longer count.
Continue from there: steer, re-run checks, or deliver.

Some checkpoints can't be rewound to — for example, a task inside a Project that has already been integrated with others. The list tells you why.

When a session stops by itself#

A session stops rather than loop when:

the budget is reached — it asks before the next paid step;
the same failure repeats with no progress — it keeps the candidate and explains what is blocking it;
it needs a decision only you can make;
something outside the code failed — a revoked permission, an unreachable service. It waits for the outside change instead of rewriting working code.

In every case the candidate, the checkpoints and the evidence are kept. A materially different instruction from you is usually all it takes to continue.