Plans and acceptance criteria
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.
On this page
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 is for.
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.
A plan on the phone, four of seven steps done.
For work too large for one session, see Projects.