Working with your squad

Reviewing history

A single round tells you what's broken today. The ledger tells you whether you're getting better — and whether that regression is real, or just your tester having a different day. Say “how did the round go?” or “show me the ledger.” With the SQUAT plugin, /review starts this workflow; a bare-MCP client can use the review prompt or the same request in plain language.

The ledger summary

Choose a project by name before reviewing its history. SQUAT keeps that project in context for the current task, so its rounds, scenarios, artifacts, Round Summaries, and Research Reports stay together until you switch projects.

The ledger has two views because scored tests and qualitative research answer different questions.

Scored UAT rounds

| Round                                         | Completed            | Pass | Fail | Blocked | Inconsistency | Regressions | Findings   |
|-----------------------------------------------|----------------------|------|------|---------|-------|-------------|------------|
| Checkout baseline (round-2026-07-15-1)        | 2026-07-15T14:02:00Z |  8   |  2   |   0     |  1    |     0       | S1:1 S2:2  |
| Checkout regression check (round-2026-07-17-1)| 2026-07-17T09:11:00Z |  9   |  1   |   0     |  0    |     1       | S1:2       |

Alongside the counts, rows carry the product build tested, a severity summary of findings, a (backfill) marker on imported history, and a ⊘ marker with the reason on anything invalidated.

Qualitative panels

| Panel                                      | Completed            | Reactions | Build | Invalidated |
|--------------------------------------------|----------------------|-----------|-------|-------------|
| Gallery audience reaction (panel-sunrise)  | 2026-07-28T18:10:00Z |    12     |   -   |      -      |

Panels show completion and panelist-reaction coverage. They do not show pass, fail, inconsistency, findings severity, or regressions, and they never enter scored trend math.

Review views lead with the round, project, squad member, and scenario names plus the date and build. Stable IDs remain available as secondary metadata for precise follow-up; rich views provide a copy control beside each displayed ID.

Round Summaries, Research Reports and UAT Reports

A Round Summary is the saved, versioned analysis of one round. It keeps the observations, differences, implications, and evidence references for that specific round together. The project view shows which named valid rounds have a summary and which still need one.

You see it before it is saved. When a round completes, the next move on offer is Draft round summary, not Save. Your AI prepares the summary and shows it to you; you read it, ask for changes, ask follow-up questions about the findings, and only then tell it to save. Saving is what makes a version permanent, so it is the last step rather than the first. Once a draft is in front of you, you can keep revising it until you are satisfied.

Your draft is saved for you. Once a draft exists it is stored against the round, so closing the session no longer loses it — come back tomorrow and ask for the draft, and it is there as you left it. A draft is working material: saving again simply replaces it, and there is no draft history, because a draft is the thing you are still changing. History starts when you save the summary, which is what turns it into a permanent version.

The Round Summary card is derived by SQUAT. It reads the persisted draft or saved version and labels itself SQUAT authoritative. The counts are deliberately separate: Persona results cited is the number of result records used, Summary findings is the analysis written into the summary, and Result finding occurrences is the raw number of findings on those cited results, with its own severity distribution. A view assembled by an AI from other context is still useful, but it is visibly labeled Agent-composed view instead.

Record cards now come from the record. Workspace, dossier, round, issue, UAT Report, Research Reports, playbook, artifact-library, and messages cards accept only the record identity or a bounded page filter. SQUAT reads the authorized data, chooses the applicable actions, and builds the rich card and complete text fallback itself. Only the Steward working view and the Steering menu remain explicitly labeled Agent-composed view.

Saving the summary promotes the draft and clears it, so you are never left with two versions of the same analysis drifting apart. If a save fails, your draft is untouched. And if you decide a draft is not worth keeping, you can discard it outright — that only ever removes working material, never a summary you have already saved.

A Research Report combines selected Round Summaries into a larger study or decision readout. Start with one or more summaries, then add more rounds in a later report version as the research continues. Earlier versions keep their original selection.

A UAT Report is the third analysis artifact, and it has a different job from the other two. A Round Summary says what happened in one round. A Research Report answers a question. A UAT Report assigns work — it gathers a run's findings into something you, or your AI, can pick up and fix.

The difference shows in how it is built. A UAT Report cites findings rather than restating them: each one stays on its own issue, with its severity, its history and its evidence, and the report records which issues were in scope and what state they were in when it was generated. It also snapshots severity and status, because that is what makes it a record of a moment rather than a live view.

It always tells you what it is not showing. A report shows a bounded set — the worst findings first — and states the true total beside them: “twelve of forty-six”, never twelve with no total. That is deliberate. A reader who believes they have seen everything stops looking, and the findings nobody saw are the ones nobody works.

Where a report suggests a next step on a finding, that step is a new verification round — never an edit to the finding's status. Marking something fixed is a claim; a round that passes is a result. Re-verify in a new round that names the issue, rather than by completing the round that found it: that round is your evidence the bug existed, and finishing it spends that evidence permanently.

Cards show the Round Summary, Research Report or UAT Report name, version, coverage, and source counts. Choose the review action to open the full Markdown analysis. Save actions always name the summary or report they apply to.

Correcting an inaccurate panel reaction

The structured panel reaction is an index to the panelist’s complete exchange, not a replacement for it. If that reaction misstates the dialogue, an owner or admin can append an operator-approved correction. SQUAT keeps the original as version 0, derives the complete set of that panelist’s answers—including follow-ups and redirects—and makes the newest version the current view. The canonical dialogue is never rewritten.

Invalidating a Research Report

If a Research Report was built from an obsolete or invalid source contract, an owner or admin can invalidate it without deleting its history. It stops counting as current project coverage and cannot receive another revision. Its title, versions, and invalidation reason remain visible. If an older report body cannot be verified under the current evidence contract, SQUAT shows metadata only rather than presenting unverified analysis as current.

Comparing two rounds

To answer “what changed since last week?” or “did the fix work?”, ask for a round diff. It compares a baseline round against a later one and reports:

• Which persona×scenario pairs flipped pass → fail (regressions) and fail → pass (fixes).
• Counts by status, side by side.
• The change in findings by severity (e.g. “S0:+1 S2:−2”).
• When you ask for it, whether the product build or testing environment changed between the two — the attribution question, below.

Optional attribution analysis

When you specifically ask whether a scored result changed because of the product or the testing environment, SQUAT can compare the recorded client, model, plugin, persona version, and optional product build. Ordinary ledger reviews do not volunteer this detail.

SQUAT names the concrete difference and the limit it creates. Without a recorded build, the round remains valid but product-change attribution is less certain. This analysis applies to comparable scored rounds, not qualitative panels.

What a good review surfaces

Beyond the raw table, a SQUAT review synthesizes:

• Regressions, by name. The specific persona×scenario pairs that flipped to fail, with their failure class. An app-classified regression is the headline; it leads.
• The priority list. Where rounds carry structured findings, the review leads with the computed worst-first list — severity × personas affected × core-loop weight. See Findings & scores.
• Inconsistency, called out. Any result that may be transient or unreliable is named as needing a re-run before it is trusted and is kept separate from the fail count.
• Persistent failures. A pair that's failed three or more consecutive rounds with the same failure class is flagged as a known, unaddressed issue — different news from a fresh regression.
• The issues queue. For “what's broken?” (as opposed to “how did this round go?”), the tracked-issues view leads — sorted worst-alarm-first, with regressed issues (a claimed fix that didn't hold) always on top.
• Persona tensions. When observed behavior conflicts with a claim, motivation, or prior pattern, the review preserves both in context. It compares pinned persona/briefing/range/compiler versions and whether the run used a governed provenance-excluding bundle before attributing the shift to the product.

Every review closes with a plain-language readout: trending better or worse, on what evidence, the one thing to look at first, and what needs a re-run before it's trusted.

When one round or issue is the focus, SQUAT may present that readout as a rich card through standard MCP Apps. Clients without that render surface receive the same tally, verdicts, metadata, and actions as Markdown. The card contains computed status and safe operational summaries — never the protected dialogue, screenshots, or evidence behind them.

Set aside from product findings

Not every failure is your product's fault. When a result fails because of the testing agent itself — a harness limitation, a scaffolding gap, or a model shortcoming rather than a real defect in what you're testing — SQUAT sets it aside into a separate agent-artifact queue instead of counting it against your product. These set-aside items never enter the issues ledger, never affect the priority list, and never move your pass/fail trend: they're kept apart precisely so a tester's bad day doesn't masquerade as a regression in your product.

They aren't discarded, though. Each set-aside item carries a disposition — for example harness-limitation, model-limitation, or needs-rerun — and stays visible in its own triage view. If you look at one and conclude it was filed there by mistake — it really is a genuine product defect — an operator can disposition it as misclassified to promote it back into product findings, where it joins the issues queue with its occurrence history carried over. Ask to “show the set-aside queue” to review what's been held back and why.

Backfilled history

Rounds you imported from before SQUAT appear in the ledger at their original dates, interleaved chronologically with live rounds, each marked (backfill). They count fully in every trend — distinguishable, never second-class. The one caveat a review will flag: a backfilled round's tester and build provenance reflects whatever the original historical run recorded, so when a trend spans the backfill boundary, that's called out — but the finding is never discounted for it.

Closing the loop on a mission

If a round carried a mission — your specific question for that round — the review addresses it explicitly: did we learn what we sent them for? Reports record only that a mission existed, never its text, so the loop closes without protected mission text appearing in a summary.