feat(github): say how much a rollout's targets agree this round

[aparajon]

An environment whose members are distinct targets plans each one against its own live schema, so the members are free to run different work. The plan comment said exactly that and nothing else:

each target holds its own schema, so their plans are not expected to match

That is true of the contract and silent about the round in front of the reviewer. Targets that are free to differ usually do not, and the shape a fleet rolling out over several PRs actually has — some targets changed, the rest already there — was invisible.

This groups the members by the plan each would run and says what came out.

What changes for the reader

A production fleet of three targets, where two still need the reviewed change and one already has it:

Before                                   After

✅ Planned separately for all 3 targets   ✅ Planned separately for all 3 targets
   (t1, t2, t3) — each target holds         (t1, t2, t3) — 2 need this change,
   its own schema, so their plans           1 is already at this schema.
   are not expected to match.

   ▲                                        ▲
   │ says what the config permits           │ says what this round does
   │ identical on every PR, forever         │ changes as the fleet converges
   ✗ a reviewer cannot tell whether
     this apply touches 3 targets or 2

The wording, by case:

The round	What the comment says
Every target needs the same change	every target needs the same change.
Some are already there	2 need this change, 1 is already at this schema.
Targets need different changes	2 distinct plans. Each target applies its own.
Different changes, some already there	2 distinct plans across the 3 targets that change; 2 are already at this schema.
The whole fleet is already there	every target is already at this schema.
Members were not grouped	the prior contract sentence, unchanged

Divergence renders on the success glyph. Under a targets list, targets holding different schemas is the contract rather than a problem, so calling it out with the attention glyph would send an operator to reconcile a fleet that is behaving correctly.

Where grouping applies

Members group on the plan fingerprint, so they share a group exactly when their plans are the same work. Two cases deliberately stay ungrouped:

• A blocked rollup. Grouping describes the targets that were planned, so it is only meaningful once every one of them was. A blocked rollup still lists each member on its own: the operator's next step is the target that could not be planned, not the plans of an apply that cannot run. This upholds MG-1.
• Mirrored members. A clean mirrored rollup has already proved they are one group. Saying so again, in the vocabulary of a fleet free to diverge, would read as an outcome rather than the requirement that let the check pass.

A group with no statements and no vschema rewrite is "already at this schema" — a plan in its own right, not a missing one. A plan that only rewrites the vschema runs no DDL and is still work, so it is not folded in with the targets that have nothing to do.

Each group carries its plan

A group holds the changes its own members would run, converted into the same shape the comment already renders the reviewed plan in, rather than a summary of it. A sharded namespace keeps both views of its changes and a satisfied shard stays visible, so the next change can render a group's plan through the code that renders the plan a reviewer has already read, instead of a second renderer that agrees until it does not.

Not in this change

The per-group DDL blocks. The comment states how many distinct plans there are but still renders the reviewed plan's DDL once, unattributed to a group. That change carries the preview fixtures for these renderings, so TEMPLATES.md shows the finished output rather than a half-rendered intermediate.

Opened by Claude (Claude Opus 5).

🤖 Generated with Claude Code