Quality tiers and review gates

The idea: pick how much checking you want

More checking means higher quality and more tokens. Less checking means a faster, cheaper run with fewer safety nets. Rather than force one answer, Castforge lets you choose per project with a quality tier, and the tier decides which review gates run.

There are three tiers, and three gates. This guide covers all three.

The three quality tiers

You pick a tier when you create a project (the Quality tier control in the setup step), and Standard is selected by default. The choice is a project-level default; an individual phase can carry its own tier when the plan sets one, and that per-phase value takes precedence for that phase.

Put plainly: Draft is code only, Standard adds plan-check and verification, and Max adds research and testing.

Cost bands

Before a run, Castforge can show a one-line notice with the rough token band for the active tier, so a bigger bill is never a surprise. The bands are approximate expectations, not billing promises:

• Draft: roughly 500 to 1,500 tokens per phase (plan and code only).
• Standard: roughly 1,500 to 3,500 tokens per phase (plan-check and verification included).
• Max: roughly 3,500 to 8,000 tokens per phase (research and full gate stack included).

Actual usage varies with the size of the work. A small change costs far less than a large feature at the same tier. You can dismiss the notice for a run.

Honest "skipped by tier" provenance

When a tier turns a gate off, Castforge says so rather than pretending the gate passed. On the gate panel you see a "Skipped (Draft tier)" chip with a tooltip explaining why, and the decision ledger records a matching "Skipped (tier)" entry with an amber accent. A gate that did not run is never shown as a silent pass. The fail-safe direction is to keep gates on: an unrecognized tier value leaves the gates enabled rather than disabling them.

The Lead Plan-Check Gate

The first gate runs before any code is written. When the Lead produces a plan, it also critiques that plan against the work's acceptance criteria, and the result appears as a plan-check panel on the plan card in chat. The point is to catch a weak or incomplete plan early, when fixing it is cheap.

The panel reads one of three ways:

• Plan check passed (mint): the plan looks sound. Nothing more is needed.
• Plan check found issues (amber): the panel opens to a list of findings. A Revise plan button sends those findings back to the Lead for one capped revision round.
• Plan check skipped (muted): the check could not run, or the tier turned it off. You can still approve the plan.

This gate is assistive, not a hard stop. It surfaces its findings above the plan's action row, but it never blocks you from approving the plan yourself. If you also have plan approval turned on, you still get the Approve, Edit, and Reject controls described in "Your AI dev team."

The Goal-Backward Verification Gate

The second gate runs at the other end, when the work settles. Instead of asking "did the tasks run," it works backward from the goal: it checks the delivered work against the acceptance criteria the team set out to meet. The Reviewer performs this goal-check, and the result surfaces as a goal verification panel in the workspace.

The panel only appears when there is something for you to decide, that is, when the check finds gaps:

• Goal check found gaps (amber): the panel lists the unmet criteria. You get two actions.
  • Re-run sends the work back for another pass (capped at one round).
  • Accept as-is dismisses the gate and lets the run settle as delivered.
• On a clean pass or a tier-skip, the panel stays out of your way (a pass needs no action, and a tier-skip shows the small skipped chip so it is never silent).

The framing is deliberately assistive: it says "found gaps," not "failed," because the goal is to help you close the last mile, not to grade the team.

The Phase Verification Gate

The third gate runs when a whole phase finishes, that is, when every card in the phase is marked done. Rather than trusting that each card passed on its own, Castforge runs a verification turn that actually exercises the phase as a whole: it runs the project's build, runs its test suite, and works through the key flows the phase's cards deliver, checking that the pieces integrate and not just that each one passed in isolation. This is the Tester seat's job.

The outcome decides what happens next:

• Pass: the phase is recorded as verified, with the evidence behind it (the commands that were run and a trimmed excerpt of their output), and the run advances to the next phase.
• Fail: the phase is held, and Castforge automatically creates fix cards in that same phase, one per problem the verification found, so the team can address them and the phase is checked again once they are done. This can repeat for up to two fix rounds. If the phase still has not passed after the second round, the run pauses with a summary of what is still unmet so you can step in, rather than looping without end.

Because the fail path loops back into the same phase and re-verifies once the fix cards are done, a phase that needs a couple of passes heals itself; because the loop is capped at two rounds, it can never run away.

Like the other gates, this one honors the quality tier. On the Draft tier the phase verification gate is skipped and the record always reads "skipped (tier)", never a pass. A project that has no build or no test setup to run is skipped loudly as "skipped (infrastructure)" and keeps moving, again never shown as a pass. Every pass, fail, and skip is written to the project's verification.md artifact and to the decision ledger, so the evidence is durable and never silent. For the artifact itself, see "Project memory and the decision ledger."

Clarify before planning

Planning a new phase or milestone starts from the request you give the Lead. When that request has genuine gray areas, real ambiguity about what you want, the Lead asks you a few structured multiple-choice questions first and plans from your answers, so it builds the right thing instead of guessing. In Autonomous mode there is no one to ask, so the Lead decides for itself and records every assumption it made in the project's decisions log and in the plan, so you can see exactly what it chose and why. A clear, unambiguous request skips the questions entirely and goes straight to planning, so you are never slowed down by friction you did not need.

When Castforge right-sizes a run

Not every change needs the full stack. When a plan resolves to exactly one task, and that task is a build task, and nothing in the plan reads as correctness-critical, Castforge runs it without the test leg and without the review round. A one-line fix gets treated like a one-line fix, instead of paying for a Tester turn and a review pass it does not need.

The condition is deliberately narrow, and the doubt runs one way: toward keeping the gates on.

• Two or more tasks keeps both gates. So does a single task that is not a build task.
• Anything that reads as correctness-critical keeps both gates: money and payments, sign-in and permissions, credentials and secrets, database migrations and schema changes, and anything the plan frames as a data-integrity concern.
• If Castforge cannot read the plan cleanly, or cannot tell how large it is, it keeps both gates. An unclear answer is treated as a reason to run them.

The asymmetry is the whole point. Skipping the right-sizing on a plan that qualified costs you a test turn you did not strictly need. Applying it to a plan that did not qualify would ship work with nobody checking it. Those are not the same size of mistake, so the rule only fires on the plans it is certain about.

This is not a silent skip. The board shows the cards that will actually run, so a right-sized plan simply shows fewer of them, and you can see before the work starts that no test card and no review round are queued.

How the verdict badges read in chat

Both gates use the same visual language, so you can read them at a glance without learning two systems:

• Mint with a check icon means a check passed.
• Amber with an alert icon means a check found something worth your attention (plan issues, or goal gaps).
• Muted with a neutral icon means a check was skipped, with a tooltip that says why.

The same outcomes are recorded in the decision ledger as gate-outcome entries, so you can revisit any verdict later in Project Memory. See "Project memory and the decision ledger" for that history.

Choosing a tier

• Reach for Draft on throwaway work, spikes, and quick experiments where you want speed and low cost and will eyeball the result yourself.
• Keep Standard (the default) for most real work: you get the plan-check before you commit to a plan and the goal verification when it settles, at a balanced cost.
• Step up to Max when the work is important enough to warrant research up front and testing on top of the full gate stack.

You set the tier at project creation, and a plan can raise or lower it for a given phase, so you are never locked into one level of rigor for the whole project.

Common questions

Do the gates block my work? No. Both are assistive. The plan-check surfaces findings but never stops you approving a plan, and the goal-check gives you Re-run or Accept as-is rather than refusing to settle. You stay in control.

What is the difference between the plan-check and the goal-check? The plan-check runs before work starts and critiques the plan. The goal-check runs at settlement and verifies the delivered work against its acceptance criteria. One guards the input, the other guards the output.

Why did a gate say "skipped"? Either the check could not run, or your quality tier turned that gate off (Draft turns both off). The panel and the ledger both record the reason so it is never a silent pass.

Can I change the tier after creating the project? The tier is chosen at project setup and defaults to Standard, and a plan can set a different tier for a specific phase, which takes precedence for that phase.

How many times will it re-run or revise? Every gate caps its loop so it can never iterate without end: one plan revision after a failed plan-check, one re-run after a goal-check that found gaps, and up to two fix rounds on the phase verification gate before the run pauses for you.

What happens when a review loop keeps asking for changes and hits its limit? All three review loops, the code review, the visual review and automated testing, are capped the same way the other gates are. If one reaches its limit while still asking for changes, Castforge ends that loop so the run stays moving instead of stalling, but it does not record the work as approved. You get a notice saying the loop hit its change-request limit without being approved and the requested changes are still unresolved, and the same outcome is written to the decision ledger. Treat it as work to look at, not as a check that passed. In an interactive tier you are asked to decide instead, so a loop only ends this way when there is no one available to answer.

My run stopped dead after the tests kept failing. Why did nothing happen? That was a bug, and it is fixed. When the test loop ran out of rounds it always asked a person what to do next, even on an autonomous run where nobody was there to answer, so the run sat waiting forever with no prompt and no error. The test loop now behaves like the other two: on an autonomous run it ends the loop so the rest of the board keeps moving, and it records the outcome as unresolved rather than as a passing suite. On an interactive tier you are still asked to decide, exactly as before.

My run went quiet right after the last round of review changes. Why?

That was a bug, and it is fixed. A review loop that had used up its last allowed round looked, to the part of Castforge that decides what runs next, exactly like a loop that had stopped to ask you a question. So while the final round of changes was being made, the run treated itself as waiting on you and stopped picking up new tasks. Nothing was actually waiting on you, and nothing said so, which is what made it hard to spot: the board simply sat there with a task ready to start and no one working on it.

Castforge now tracks whether a loop is genuinely waiting on your decision, rather than guessing from how many rounds it has used. A loop that is on its last allowed round keeps the run moving; a loop that has actually stopped to ask you something still holds the run, exactly as before, until you answer. Choosing Send back also lets the run continue through the round you granted, instead of leaving it stuck until the next verdict.

A review loop keeps repeating itself. Does it just burn through the limit? No. Before starting another round, Castforge checks whether anything the review depends on actually moved since the last one: the code in your working folder, including edits you have not committed yet, and the state of the board it reviews. If nothing changed, another round can only reach the same answer, so the loop ends there instead of spending the remaining rounds. It ends exactly the same way a loop that ran out of rounds does: not as an approval, recorded as still unresolved, and handed to you to decide when you are on an interactive tier. If Castforge cannot tell whether anything changed, it runs the round as normal.

This check now covers all three review loops, the code review, the visual review and automated testing, not just the visual one. Each loop keeps its own history, so a code review round is only ever compared against the previous code review round. For automated testing the check only applies after two failing runs in a row against identical code, because a run that passes in between ends the loop anyway.

A role said a task was done but its own review blocked it. Which one wins? The review. If a role marks its own task complete and in the same turn reports it cannot finish that task, the completion is dropped and the task stays open on the board. The conflict is logged and recorded so you can see it happened. Reviews are what the run is routed on, so a role cannot mark its own work finished past its own objection.

This also covers the tidy-up Castforge does at the end of a visual review. That step used to close the reviewing role's own task no matter what the review said, including when the review blocked. Now a blocking review holds that task open instead of closing it, and the hold is written to the decision ledger so you can see why the task is still showing as in progress. A later passing round closes it normally.

A small change ran with no test card and no review round. Is that a bug? No, that is right-sizing, described above. It only applies when the plan is a single build task with nothing correctness-critical in it. Anything larger, and anything touching money, sign-in, credentials, migrations or data integrity, keeps both gates. The board shows you the cards that will run before the work starts, so you can always see which legs a plan is getting.

Where do I see past verdicts? In the Project Memory tab. Every plan-check and goal-check outcome is written to the decision ledger, where you can filter to gate outcomes and expand any one for its findings.