Introduction

Ysra takes a request — a feature, a bug report, a sentence typed on your phone — and works on it in its own isolated machine. It reads your repository, plans, edits, runs your commands, and keeps going until your own checks pass or it can say precisely why they don't.

What makes it different from a chat assistant is that the backend owns durable state: projects, sessions, candidate revisions, checkpoints, findings, usage, approvals and audit evidence. You can leave, come back on another device, and pick up exactly where the work stands.

Where you use Ysra#

How a request becomes a pull request#

flowchart LR
    goal([Goal]) --> plan[Compile goal &<br/>acceptance criteria]
    plan --> work[Edit an isolated<br/>candidate]
    work --> verify{Native<br/>verification}
    verify -- fails --> repair[Bounded repair]
    repair --> work
    verify -- passes --> review[Independent<br/>review]
    review --> deliver([Deliver within<br/>your policy])

1. You describe the outcome. Ysra derives acceptance criteria when you don't give any, and snapshots your autonomy policy so later edits never change a running session's contract.
2. It works on a candidate, never on your default branch, and records a checkpoint you can rewind to.
3. Your repository's own commands decide whether the work passes. See Verification.
4. Delivery is separate from completion. A verified candidate is only pushed, opened as a pull request or deployed when your policy allows it.

Next steps#