Verify a plan with /test

What it is for

A plan is agreed in one conversation and built in another. /test is what the planning conversation runs when the building one reports back: it opens your application in your real browser, walks what the plan promised point by point, and hands you a table and a verdict. When something failed, it writes the correction — into the plan itself when the plan is saved in your project's documents, as a prompt for you to take back when it is not.

It verifies and nothing else. It does not build, does not fix what it finds, and does not commit. It runs no automated test — not the suite, not a single case — because a suite coming back green says nothing about whether the plan was met on the screen. And it does not check the code against the standards: the build step already did, and /review is the command for that.

You rarely have to type it. Saying "check that what we planned works" in the planning conversation is enough, and inside the queue /next runs it for you.

What it needs before it starts

• The plan. It takes it from the conversation. A saved plan is checked whole, with every correction already written into it. A plan pasted into your message works too, with any correction prompts written on top of it.
• The right branch. It names the repository and the branch, and asks you before going on when they do not match the work the plan describes.
• A local environment, a browser and the application running. It confirms the environment is local before writing anything, reaches your browser, and starts the development server — on a free port when the usual one is taken.

It stops before testing anything in three cases: there is no plan, the plan never says what to look at, or the branch does not match and you have not settled it. It says which one and what would unblock it.

How it walks the plan

The plan becomes a numbered list of what it promised, and that list is what the table reports, row by row. The first row is always the original problem: reproduced, and confirmed gone. Nothing is added to the list from reading the code; the only rows added later are the defects described below.

Each row is checked in every state the plan says it has to work in — an empty list and a full one, an account with a subscription and one without — and the ux-designer agent reviews the experience of the screens it tested.

Every screen a row is tested on gets the same checks, beside the states the plan names:

• each language your product serves, with no raw translation key and no text left in another language;
• a phone, a tablet and a laptop width — 375, 768 and 1280 pixels;
• with no records and with some, when the screen lists them;
• a loading indicator while an action you wait on runs;
• after each save, the page reloaded to confirm the value stayed and the success message told the truth;
• a create form sent empty, which answers with its validation and never with an error page;
• a name a screen reader can read on every button that shows only an icon.

A defect on a tested screen fails a row. Whatever goes wrong there — found by these checks, by the ux-designer review or without looking for it — fails the row that covers it, or a row added for it that names the defect, the screen and the state. Those are the only rows added after the list is made, and they come from what was seen, never from the code. A defect there that needs a decision only you can take fails no row: it is named under the verdict as a question the plan has not answered.

The plan's technical risks are tested from the first check. A risk the plan's technical plan names that shows on a screen — a width a line has to fit at, data that already exists — is checked as one more state of the point it bears on, not as a new row. A risk no screen shows, such as the order a provider's notices arrive in, is named under the verdict, and so is a risk state the check cannot reach — as not covered, without pausing the run.

A plan with an approved drawing is compared against it. When you approved a drawing while planning, each screen it draws is held up against it: a difference in the layout, the components or the states fails the point that shows it. Its sample data is not compared.

When something gets in the way, it works on it first. In a confirmed local environment it creates the records a state needs, signs in as a seeded account, runs missing migrations, installs a missing validation dependency and starts what the flow needs, such as a queue worker. A record that existed before is never deleted, and one it changed is put back before it finishes. What an install wrote, such as a lockfile, is named in the report and left as it is, not committed.

When that fails, it pauses. It tells you what is stuck and what would unblock it, hands back no table and no verdict, and names any record it changed that is still waiting to be put back. When you answer, it carries on from where it stopped, and the report still covers the whole plan.

Reading the table and the verdict

The report is a table and a verdict, with nothing above them.

A row tested in several states still has one result: it fails if it failed in any of them, and the states column says which. There is no "not tested": every point either was tested, or the run paused before writing the report.

Under the table, one line: Pass or Does not pass. It reads Does not pass when any row failed. There is no partial pass.

Below the verdict come short lines that do not change it:

• Defects noticed close to what was tested, but outside the screens and flows the rows were tested on.
• What ux-designer proposed, split into what can be written up now and what needs its own planning.
• Anything the plan itself left contradictory or undefined, a defect on a tested screen that needs your decision included.
• Behavior nobody sees on a screen, such as a job or a command, and the plan's technical risks no screen shows. A browser cannot prove them, so they are named here and never as a row.
• The checks it could not make, as not covered: a width the browser could not be set to, a language the screen could not be switched to, a loading indicator it could not slow the request down enough to see, or an empty state only a separate test database could reach.
• What an install left in your working tree.

/test creates no document of its own. When another command called it, a defect noticed outside the tested screens is handed to that command for your project's Pending findings; run on its own, it is only named here.

The correction

When the verdict is Does not pass, /test writes the correction itself, without asking you anything new: what failed was already planned, and it has just watched the failure happen.

When the plan is saved in your project's documents, the correction goes into that same plan, in a section called Validations at the end, and no new document is created. Each failed attempt adds one numbered entry:

• What was built or changed in that attempt.
• Which points were tested, on which screen and in which state, and which passed.
• Why it failed, said as behavior, with how it was reproduced.
• What it owes, as the plan already says it.
• The solutions considered, the one chosen and why.
• Anything it corrected in the plan, as before and now.
• Whether the failure repeats an earlier attempt.

When several failures share a cause, or a point fails again, the entry adds a rethinking: the pattern across attempts, the questions about the plan nobody has answered yet, and a different approach. On the third failure the rethinking is always there, first, because it is what /plan-prompt reads when the plan goes back to it.

/test may correct a fact the plan got wrong — a screen's name, how a flow behaves today — and the entry records what it said before and what it says now. It never changes what the plan asks for: when the contradiction reaches that, the entry names it, chooses no solution, and the plan goes back to /plan-prompt.

When the plan was never saved — pasted into the conversation — the correction comes as a prompt with the same shape as one from /plan-prompt, opening with the line Origen: escrito por /test.. Take it to the building conversation. When something that plan argued from proves untrue, there is no prompt: the claim and the evidence go back to /plan-prompt, and you still get the table and the verdict.

Before the correction goes out, the analyst agent checks it against the code. A doubt only you can settle comes to you as the finding first and the question second, and the correction's choice waits for your answer.

Run /test again once the correction is built. A second run tests the whole plan again, not only what failed, because a correction can break something that was passing.

When the verdict is Pass and ux-designer proposed something that touches only a screen it tested and needs no decision you have not taken, you are asked once whether you want a prompt for it, or for some of it. The other proposals are named, each with why it needs its own planning. When the verdict is Does not pass, the proposals are only named: the question comes on the run that passes. One run never writes two corrections.

After a pass, the next step is /finish.

Inside the queue

When /next runs /test over the plans it built, nothing is asked: a question is handed back to /next, which writes it into the plan. A plan built in the queue is checked without the ux-designer review and without the analyst check on the correction. The correction goes into the plan's Validations section, and the queue builds the same plan from it and checks it again, three attempts at most. That cycle is in Run the queue with /next.

Next

• Planning before building — where the plan /test checks against comes from.
• How a task travels — the browser check the build step already runs before /test ever sees the work.
• What each command does — /test beside /review and the rest.