Ysra Docs

How Ysra works

Every job has the same shape — your outcome, your boundary, visible work, evidence, and your decision. Here is what happens inside each stage, and why you can trust the result.

On this page

Ysra doesn't run every job through one fixed pipeline. It keeps the same shape around every job, so you always know where the work stands and who decides what happens next.

Five stages, every time#

You give Ysra the outcome#

A sentence, a detailed brief, a bug report — plus the repository, any files or screenshots, and acceptance criteria if you have them. Describe what should be true when the work is done; Ysra works out the steps.

You set the boundary#

Budget, quality level, what Ysra may do on its own, and what must wait for your approval. The boundary is fixed when the work starts: changing your settings later never changes a job that is already running. See Autonomy policy.

You watch the work#

The conversation, the plan, live activity, the changes and a running preview share one durable session. You can steer, answer a question, pause or stop at any point — from the portal or your phone.

You review the evidence#

Before anything leaves the workspace you see what changed, which checks ran and what they returned, what the browser showed, and what is still unproven. See Evidence and verification.

You choose what happens next#

Deliver a pull request, ask for changes, rewind to an earlier checkpoint, or stop. Nothing is published without your policy or your click.

Inside the work: one loop, owned end to end#

A single engineering worker owns each change from first read to final candidate. Around it, the platform enforces the rules the worker cannot bend.

flowchart TB
    goal([Your outcome]) --> plan[Understand and plan]
    plan --> edit[Edit an isolated copy]
    edit --> check[Run your checks]
    check -->|fail| fix[Fix exactly what failed]
    fix --> check
    check -->|pass| review[Independent review]
    review -->|real defect| fix
    review -->|pass, or gaps named| ready([Candidate with evidence])
    fix -.->|no progress| stop([Stop and explain])

Understand before touching anything. Ysra reads the repository the way a new engineer would — structure, conventions, how it is installed, tested and built — without running untrusted code to find out. Your requirements are turned into explicit acceptance criteria that the rest of the job is held to.

Plan, then work in isolation. The plan is visible and updates as Ysra learns. All edits happen in an isolated copy of your repository at an exact revision. Your default branch is never touched.

Your checks decide. The commands your project already trusts — install, lint, type-check, test, build — run against the exact change. If a command cannot run, that is a failure, not a pass. Tests that were already failing before the change are reported separately, so they are neither blamed on Ysra nor quietly "fixed".

Independent review. A separate review, which did not write the code, checks each acceptance criterion against the exact change and the evidence produced for it. Interactive behaviour needs to be exercised in a real browser to count as proven; reading the source is not enough.

Narrow repair. When something concrete fails, the fix is scoped to that failure. Unrelated code is left alone, and only the checks the fix could affect run again.

Honest stopping. If the same failure keeps coming back with no progress, Ysra stops, keeps the work, and tells you what is blocking it — instead of spending your budget in a loop. An infrastructure hiccup is never reported as a code defect, and a missing check is never reported as a pass.

What stays true on every job#

  • Evidence is tied to the exact change

    Every check, screenshot and review attaches to one specific version of the work. Evidence for an earlier version can never approve a later one.

  • Progress is saved as it happens

    Checkpoints are taken along the way. An interruption resumes where it left off, and you can rewind to any earlier checkpoint exactly.

  • Budgets are hard limits

    Ysra stops before it would exceed your budget and asks. Extending it is your decision.

  • Delivery is separate from "done"

    A finished candidate is not a published one. Pushing, opening a pull request and deploying each follow your policy.

See it on a real job

Walkthrough: a full-stack store follows one session — a storefront and back office built from one brief — including how it honestly reported its own result.

YsraDocs