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

The tier's rough token band is a line in the workspace's right-hand panel, in the Quality tier section directly under Model strategy, shown for the project's quality tier. It stays in view while the panel is open, 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.

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 the verification's unmet findings are routed to the Lead, the same way any role's own raised work reaches the board (see "One writer to the board" in "Your AI dev team"): the gate does not add cards on its own. The Lead reviews the findings and mints fix cards in that same phase, one per problem worth addressing now, so the team can act on them and the phase is checked again once they are done. This can repeat for up to two fix rounds. If the Lead cannot be reached or declines to act on the findings, or 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 or dropping the findings silently.

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.

The handoff itself is a check

The three gates above look at whether a plan is sound and whether delivered work meets its goal. There is now a check underneath all of them too, at the point where one role's work is handed to the next: an outcome nobody confirmed has no way to be represented as work product. A turn a provider refused, or one that ended in a shape Castforge could not read, cannot travel forward disguised as the next role's starting point. Real work a turn produced before it stopped still hands off, labelled as partial rather than complete, so the receiving role knows exactly what it is building on. See "Recovery and troubleshooting" for what each of those outcomes looks like from your side.

Every handoff ends in one decision

Underneath all of the gates above, the hand-off from one role to the next now resolves to a single decision, and there are only three of them.

• Continue. The work goes to the next role. This is the ordinary turn, and it is most of them.
• Stop. The card does not advance, and Castforge writes down what stopped it.
• Stop and ask. The card does not advance, and Castforge names somebody who can clear it. The question arrives in the conversation and in the Waiting on you panel, and it stays answerable after the agent session that raised it has ended.

That third outcome is the one that did not exist before. Each check underneath a hand-off used to answer a fragment of the same question at its own point in the run, and a hand-off nobody could confirm had nowhere to land except forward. That is how a card could arrive at Done with nothing behind it.

A card that stops is not stuck and it is not lost, it is waiting. The reason is on the card itself, in the card body under the Blocked pill, and the run's own history in Project Memory records it alongside the rest of the run. Nothing else on the board halts: a stopped card holds back the work that depends on it, and the run carries on with everything else.

See Recovery and troubleshooting for the reasons you can actually meet and how to release each one, and The board: course, dispatcher, and milestones for how a stopped card reads next to the other kinds of blocked card.

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 board speaks the same language. Amber with an alert means a check left something for you to look at, on the board as well as in chat, and the board adds one more signal: a dashed edge marks a completion nothing verified. A done card whose last review wrote no verdict wears a dashed amber Unverified pill, a finished phase whose seat returned no verdict is a dashed amber circle on the phase strip, and a column holding such cards carries one amber banner with an alert icon. A dashed circle in the done colour on the phase strip means a finished phase with no check on record, and makes no claim either way. The Health tab's Trust ledger reads the same colour law on a third surface: a claim that Passed is solid mint, one that was Sent back is solid red, and one with No verdict is dashed amber, the same treatment the card pill and the phase circle already use for a completion nothing verified. The next section covers each of these.

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.

When a review ends without a written verdict

Every check hands back a short machine-readable line saying what it decided. Occasionally a check finishes its turn and never writes that line: it talked about the code in prose without stating a decision, or its output arrived in pieces that split the line in half. There is nothing wrong with the work it did. There is simply no decision to read.

When that happens, Castforge treats it as an approval so the run keeps going, and it records that the approval had no written verdict behind it. Until then the two were indistinguishable: a review that said nothing looked exactly like a review that said yes.

Why it still moves forward. The alternative is worse. A check that stopped the run every time it could not read a decision would leave an unattended run sitting there with nobody to answer it, which is the one failure mode you cannot recover from while you are asleep. So the run continues and the gap is written down, rather than the run halting and the gap becoming urgent.

This covers all three checks, not just the code review. The same handling applies to the automated test check and to the design check on your UI. A silent test check and a silent design check are recorded the same way a silent code review is, so you do not have to assume the other two behave differently.

Where you see it. In three indicators on the board, plus the run entry in Project Memory, with no file to open.

On the board card, the status pill itself changes. A done card whose last review ended without a written verdict reads Unverified, in amber with a dashed edge, where a verified card reads Done in mint, so you can tell the two apart at a glance without reading the card body. The pill is a mark, not a gate. The card's completion marker changes from Done to Unverified, and nothing else about the card does: its actions and its menu items are exactly the ones a verified done card has, so you decide what to do about it.

The note that used to sit under the card body now lives one click behind the Show the evidence control, which every done card carries. A card whose review went silent keeps that control after it leaves Done, when you re-run it, when it goes back for review or when it is blocked, so the record is never out of reach. Only the Unverified pill and the column banner are limited to done cards. It opens the card's detail with an Evidence section. On a card that went silent, that section opens with This card's last review left no verdict on record., says which kind of silence it was, gives the explanation Castforge stores alongside the card or says no reason given, and shows the value it was recorded as. On a card whose last review did write a verdict, it says so. On a card that carries no silence mark, it says Review evidence is unavailable for this card. and names no cause, because a missing mark can mean several different things, the most common being an ordinary review that did write its verdict. Only a card that went silent points you to the logs, because that is the only case with a log line to find. It shows the record Castforge kept, not the conversation at the moment the check ran.

On the phase strip under the board header, a finished phase whose seat returned no verdict draws a dashed amber circle with its number, in place of the filled check a verified phase gets. A finished phase whose check did not pass draws a solid red circle with its number, and never the filled check. A finished phase with no check on record draws a dashed circle in the done colour, so it reads neither as verified nor as not started. Each phase verdict in an open milestone also carries its own Show the evidence control, described in The board: course, dispatcher, and milestones.

At the top of a board column, one banner counts the Unverified cards in that column, reading for example 3 cards here finished without a recorded verdict., with a second line inviting you to open one and judge it yourself. It appears once per column however many cards it counts, and it counts only the cards the column is showing, so with Hide done on it goes away together with the cards it would have counted.

In Project Memory, the run's own "Run completed" entry carries the count. A run that had at least one silent review reads like "Run completed (1 of 4 reviews gave no written verdict)" right on the summary line, and expanding the entry shows the same fraction under "Reviews that ended with no written verdict". A run whose reviews all wrote a verdict reads "0 of 4", which is a real statement about a run that was measured. An older run, or one that was resumed partway through, shows no fraction at all, because nothing counted it and "not recorded" is the honest answer there. That is deliberately different from showing you a zero.

The logs are still the deeper trail, and they hold something the card does not. In the logs folder reachable from the log-folder link in the app, a line tagged verdict_provenance names which check was silent and quotes the tail of what it said instead. Start with the card and the run entry; go to that log line when you need to know which check it was and what it actually said.

The three kinds of silence, and what each one suggests. They look similar on the surface and they usually have different causes, so the card names which one it was.

• "The check produced nothing readable, so there was no output for a verdict to be in." Nothing came back to read at all. This points at the check itself rather than at your code, so re-running the card is the first thing worth trying.

• "The check produced output, but none of it carried a verdict line." The check did the work and talked about it without ever stating a decision. Re-running the card usually gets you a decision, and if it keeps happening it is worth a look at that role's instructions.

  If you saw this one on a long review, in v0.6.7-beta and earlier, that was a bug in Castforge and it is fixed. The review was writing its decision every time. Castforge was keeping only the opening stretch of a long review turn and dropping the rest, and since the decision is the last line a reviewer writes, a thorough review lost its decision precisely because it was thorough. Because an unreadable decision is treated as an approval, that also meant a review asking for changes could be recorded as an approval instead. Short reviews were never affected, which is why this showed up on your most detailed cards and not on the quick ones. Nothing is needed from you beyond updating, and it is worth re-running any long-review card that carried this note.

• "The check wrote a verdict line, but its value could not be read." The decision was written and arrived damaged, most often because the output came back in pieces that split the line in half. A re-run normally clears this one.

Two things the mark cannot tell you. Both are worth knowing before you go looking for them.

First, it does not say which of the three checks went silent. The card records that its last review ended without a verdict, not whether that was the code review, the test check or the design check. The log line above is where that detail lives.

Second, the mark stays on the card, and it is now a loud mark. It records the most recent review that ended without a verdict, and it is not cleared when a later review does write one, so a card you re-run and that is genuinely verified later keeps its Unverified pill. That used to be a muted paragraph under the card body. It is now a coloured pill at glance level, in the spot you read first, so a stale mark is as visible as a current one. A card reviewed twice keeps only the second review's record. If you re-run a card and it still reads Unverified, you have not hit a bug: you are looking at a record that has no clear step yet, and it keeps showing until Castforge ships one. Open Show the evidence to read what was recorded, and check Project Memory to see whether the newer run counted any silences at all.

When a card finishes on a commit that holds only Castforge's own files

Every card's work is supposed to land in a commit you can point at. Occasionally a card reaches done on a commit that turns out to hold nothing but Castforge's own internal bookkeeping files, the small housekeeping notes the app keeps for itself, with none of the source files the card was actually meant to produce. The card still shows as finished, but it now carries a note saying its completion could not be verified, because there is no work product behind it to point at.

This is not the same gap the sections above describe. A silent review still has a real commit behind it; this is a commit that landed cleanly and still carries no work. It is your phase check that catches the missing work and sends the card back, the same phase-boundary check described earlier in this guide, so a card can carry this note for a little while before anything acts on it.

Why Castforge marks the card rather than refusing to finish it. By the time this check runs, the card has already reached done, so there is no completion left to refuse. Marking it unverifiable, rather than reversing the flip, is also the deliberate choice on the merits: refusing risks wedging a card whose work genuinely lives outside git, in a file the check simply cannot see. A note you can act on is safer than a stuck card you cannot.

When the same card keeps getting sent back

A code review that asks for changes sends the card back to be reworked, and that is the loop working. Sometimes it is not working: the same card comes back, gets the same kind of objection, goes back again, and the third attempt looks a lot like the first. Nothing in that loop was learning anything, and every lap of it costs you time and quota.

Castforge now counts how many times each individual card has come back with no approval in between. When a card reaches the limit, it is not handed to the same seat again.

Two things count, and the second one is easy to miss. A review that asks for changes counts, which is the obvious one. A review that ends without writing a verdict at all counts too, and it counts for the same reason: nothing approved the card, so that lap got it no further than an objection would have. A card whose reviews keep going quiet is in the same loop as a card whose reviews keep objecting, and it costs you the same time and quota.

This is worth knowing because it used to work the other way. A review that ended without a verdict counted for nothing in either direction: it did not reset the card's history, but it did not add to it either. A card could cycle that way indefinitely and never approach the limit, which is exactly the loop the limit exists to stop. Both kinds of lap now land on the same count.

A third case does not count at all, and it looks identical to a quiet review from the board. A review that ran and ended with no verdict, described just above, still counts. A turn that did not complete a valid review, because it ended on the provider's side rather than because a reviewer said nothing, does not count in either direction: it does not add to the number, and it does not clear it either. Castforge says "did not complete a valid review" rather than "never reached a reviewer," because a turn in this class can have reached a reviewer and done real work before its provider ended it; what decides whether it counts is whether a review actually completed, not how far the turn got before it failed.

This is worth knowing because it used to work the other way too. Before this, a turn that failed on the provider's side was read the same way a quiet review is, and added to the count, so a card could approach the send-back limit through failures nobody ever reviewed. That was the wrong call: the limit exists to stop a loop that is not learning anything, and a turn that did not complete a valid review taught the loop nothing, so counting it against the card charged it for a lesson the loop never actually got.

The other half matters just as much, and it is easy to assume it if you only read the first: a turn that ended on the provider's side also cannot clear the count. A card that had already earned strikes does not have them erased by a failure that happens, from the board, to look like an approval.

Reading the number. Because both kinds count, the number on the card is not always a count of change-lists. A card showing three may have been sent back once and gone quiet twice. The card's own note says so, and so does the notice, so you are not left guessing which kind of lap you are looking at. If you go hunting for three sets of requested changes and find one, that is the reason.

What stops, and what does not. Two different things, and it is worth keeping them apart.

The re-dispatch stops, and so does the card. The card is parked with the reason written on it, the same way every other stopped hand-off is parked, and it reads Blocked on the board with a line saying it was sent back too many times with no approval, so it needs a look. That is deliberate: nothing else in the run is coming back for this card, so if it were left to advance it would advance unverified, and work nobody could get past a reviewer would be indistinguishable from work that passed.

The rest of the run does not stop. Nothing is waiting on you before other cards can move, nothing is holding a question open that you have to answer, and a project set to run unattended keeps going exactly as it did. What ends is the specific thing that was not working: handing the same work to the same seat one more time.

How to release it. Two ways, and either one clears the mark:

• Run it from the card. Right-click the card and run it. Use this once you have changed something, most often the model on that seat.
• Move it back to Up next yourself from the card, when you want it picked up on a later pass rather than now.

Asking the Lead to re-plan does not release this one by itself. That path releases cards a new plan reaches; a card parked on its own history is not one of them. Re-planning is still often the right move, for the reason in the list below, but move the card yourself or run it when you want it back.

"A card a handoff stopped, and how to release it" in the troubleshooting page covers the same parked state from the other stop reasons, and reads the same way for this one.

How you find out. Three places, and you do not need to go looking in any of them:

• A notice in the app says the card was sent back too many times and was not handed to the same seat again.
• The card keeps the count, so you can see how many attempts it took before the loop stopped.
• The run's history in Project Memory records the same thing, with the reason written down, so you can tell this apart from a review loop that simply ran out of rounds.

It is not an approval, and the card is not finished. The requested changes are still unimplemented. The count is there so you know the difference between work that passed and work that nobody could get past a reviewer.

What usually helps. Castforge deliberately does not pick for you, because the right move depends on what the reviews were actually saying:

• Read the last review yourself. When three reviews all object to the same thing, the objection is usually worth reading once carefully.
• Give the card a different model. A seat that has produced the same answer three times is unlikely to produce a fourth one that differs.
• Send it back to the Lead for a fresh plan. When a card is too large or too vaguely scoped, no amount of reworking fixes it; splitting it does.

The count resets on a real approval. Once a review approves the card, its history starts over and it gets a full budget of attempts again. A review that ended without a written verdict, described in the section above, does not reset it: a review that never stated a decision has not approved anything, and it does not clear the record of a card that keeps coming back.

This is separate from the review-round setting. The review-round limit in your handoff rules bounds one uninterrupted review loop inside a single run. This count follows the card itself, across restarts, across re-plans, and across a card that comes back later as part of new work. It sits above the round limit rather than replacing it, so a card still gets the full number of review rounds you configured before this ever applies.

The trust ledger

The Health tab's Trust ledger segment (next to Activity, see "The board: course, dispatcher, and milestones") lists every claim a role made during the current run, grouped by card, each one carrying one of three verdicts:

• Passed: the check ran and wrote an explicit approving decision.
• Sent back: the check ran and wrote an explicit decision asking for changes.
• No verdict: the check either produced nothing readable, or its silence resolved to the fail-safe approval described above. The trust ledger tells these apart from a real approval instead of folding a silence into a pass, which is the whole reason this ledger exists next to the pills above: a silent claim under the fail-safe approval used to look exactly like a claim that actually passed, everywhere except here.

Older checks are not counted. A check recorded before Castforge could tell a pass from a silence carries no provenance to read, so the ledger excludes it from the score and states how many it left out in a line of its own, rather than silently mixing an unreadable old record into today's numbers.

Phase checks are not in this ledger. A check that ran as part of a phase, not a card, is counted separately and named in its own sidebar line rather than folded into the card-by-card list above it. That line also carries a clause when it applies: some phase turns record no card-verdict line on their own turn, and that absence describes the TURN'S RECORD, not whether the phase check itself went unverified. Reading that clause as "these phase checks were never verified" gets the direction backwards.

Evidence opens the record, not the conversation. Each claim's evidence chip discloses the seat, the recorded time, the silence sentence when there is one, and the engine detail behind the claim, including the session and card the row belongs to. It does not jump to the conversation: a transcript deep link is not something this ledger has yet, and it says what it shows rather than promising what it cannot do.

Exporting the ledger. The sidebar's Save as markdown button writes the same claim rows, in the same order, with the same sidebar numbers, to a file you choose with your system's native save dialog. The file is meant to answer one question for someone who was not there: what the run claimed, and what nobody checked.

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.

Why did a card stop being reworked even though the review asked for changes? It had come back too many times with no approval in between, so Castforge stopped handing the same work to the same seat. Those laps are not all change-lists: a review that ended without writing a verdict counts toward the same limit, so some of them may have been reviews that simply went quiet. The run continued and nothing is blocked. See "When the same card keeps getting sent back" above for what usually helps.

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.

How do I tell whether a review actually said yes, or just said nothing? By the record. A check that finishes without writing its one-line decision is now logged as exactly that, on a verdict_provenance line in the app's logs, naming which check was silent. The run still treats it as an approval and keeps going, for the reason given above, but the silence is no longer invisible. If a card was approved and should not have been, that line is what tells you the approval had nothing behind it. It works the same way for the automated test check and the design check. See "When a review ends without a written verdict" above.