---
title: How Ysra works
description: 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.
---

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

<div class="steps" markdown>

### 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](../workspace/autonomy-policy.md).

### 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](../developer/review.md).

### 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.

</div>

## 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.

```mermaid
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

<div class="cards" markdown>

- **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.

</div>

!!! tip "See it on a real job"
    [Walkthrough: a full-stack store](../guides/walkthrough.md) follows one
    session — a storefront and back office built from one brief — including how
    it honestly reported its own result.