---
title: Plans and acceptance criteria
sidebar_title: Plans & criteria
description: How Ysra turns a brief into a scope, acceptance criteria and a plan — what each one controls, what can and can't change it, and how progress is measured.
---

Before writing code, Ysra turns your brief into three things. Knowing which is
which explains most of what you see in a session.

| | Built from | Controls | Can't do |
|---|---|---|---|
| **Scope** | Your brief, your criteria, an approved spec | What to deliver, what to leave alone, required technology | Grow on its own. Review feedback can't add deliverables. |
| **Acceptance criteria** | The scope, plus Ysra's quality baseline | What the result is checked against at the end | Rewrite your objective. |
| **Plan** | Ysra, while working | The order of steps for this piece of work | Change the scope. |

## Scope: what you asked for, frozen

The scope records your deliverables, anything you told Ysra to leave alone, the
parts of the repository the work applies to, and any technology choice you made
explicit. It is fixed when the session starts.

- **Exclusions are constraints, not tasks.** "Don't change the API" is checked,
  never counted as something to build.
- **Silence isn't permission.** If you didn't name a module, Ysra doesn't assume
  it may change the whole repository — it narrows scope to what the work
  actually touches.
- **Mentions aren't mandates.** Only explicit technology requirements are
  binding. "A or B" stays a choice.

## Acceptance criteria: what "done" means

Each criterion records where it came from and how it must be proven:

- **Source** — *yours* (from your brief or ticket), *derived* (Ysra inferred it
  from your goal), or *quality baseline* (standard expectations, such as not
  breaking the build).
- **Applicability** — required, conditional, or not applicable to this change.
- **Severity** — blocker, major or minor.
- **Proof required** — for example a repository command, a unit or integration
  test, an API contract check, a browser workflow, a state check, a visual or
  accessibility check, a security scan, a deployment smoke test.
- **Negative cases** — what must *not* happen ("an invalid week number is
  rejected") is tested, not assumed from the happy path.

Proof is chosen by kind of work. A web criterion needs browser proof; an API
criterion needs contract and integration checks; stored data needs a check of
the stored state. An admin feature isn't accepted because a page exists — it
has to change something, and that change has to be observable.

Your criteria always win: when you provide them, Ysra reviews against yours.
If a brief is too thin to yield any real criterion, Ysra still creates a
meaningful one rather than passing an empty checklist.

## Plans: how the work is ordered

The plan appears in the **Plan** panel as a numbered list of steps, each with
its status. It is Ysra's working checklist:

- It is **revised as Ysra learns** — a revision number shows how many times.
- Ysra may complete, block or reorder its own steps, but **cannot add product
  scope** through the plan.
- **Plan progress is not a verdict.** "10 of 10 steps complete" means the work
  was done, not that it was proven — that is what
  [review](review.md) is for.

![The Plan panel: the goal restated in full, an Agent mode note, and the task plan at 10 of 10 complete with each step marked completed](../assets/screens/plan.webp){ width="500" height="902" }

### Deliverables are tracked separately

Every requested deliverable is tracked as *delivered*, *partial* or *not
started*. A session can't be reported as successful while something you asked
for was never started — you'll see an explicit gap instead of a hopeful summary.

## Plan-first mode

In **Plan first** mode, Ysra writes a specification before running any code:
work items, their order and dependencies, milestones, the deliverables each one
covers, and anything it thinks you didn't ask for. A separate critique pass
checks the spec for overloaded items, missing deliverables and unrequested scope.

You review it and approve (or ask for a revision). Only then does work begin —
and the approved spec becomes the fixed scope that progress is measured against.

On the phone, a plan waiting for you appears as a review gate; approve it or ask
for a revision.

<div class="phones" markdown>

![A plan on mobile: seven steps — connect, inspect, edit, run the checks, prove it in a browser (in progress), ask you, report](../assets/screens/mobile/plan.webp){ width="585" height="1266" }
/// caption
A plan on the phone, four of seven steps done.
///

</div>

For work too large for one session, see [Projects](projects.md).