feat(github): show every target's plan, not just the reviewed one

TEMPLATES.md

@@ -1289,7 +1289,7 @@ schemabot apply -e production
 
 *Requested by @jackjackbits at 2026-01-01 00:00:00 UTC · planned from [`abcdef1`](https://github.com/block/schemabot/commit/abcdef1234567890abcdef1234567890abcdef12)*
 
-✅ **Same plan on all 3 deployments** (eu, au, us).
+✅ **Same plan on all 3 deployments** (`eu`, `au`, `us`).
 
 ```sql
 CREATE TABLE `users` (
@@ -1421,6 +1421,84 @@ ALTER TABLE `products` ADD INDEX `idx_category_price`(`category`, `price`);
 📋 **Plan**: **2** tables to create, **1** table to alter
 
 
+---
+
+▶️ **To apply** all schema changes from this PR, comment:
+```
+schemabot apply -e production
+```
+
+</details>
+
+<details>
+<summary><a name="targets-converging"></a><strong>Targets Converging</strong></summary>
+
+
+## Schema Change Plan — Production
+
+**Database**: `testapp` | **Type**: `MySQL` | **Schema Name**: `testapp`
+
+*Requested by @jackjackbits at 2026-01-01 00:00:00 UTC · planned from [`abcdef1`](https://github.com/block/schemabot/commit/abcdef1234567890abcdef1234567890abcdef12)*
+
+✅ **Planned separately for all 3 targets** (`primary/testapp_1`, `primary/testapp_2`, `primary/testapp_3`) — 2 need this change, 1 is already at this schema.
+
+**`primary/testapp_1` (primary), `primary/testapp_3`** — 1 DDL statement
+
+```sql
+ALTER TABLE `users` ADD COLUMN `email` varchar(255);
+```
+
+**`primary/testapp_2`** — already at this schema, nothing to apply.
+
+📋 **Plan**: 1 DDL statement on 2 of 3 targets
+
+
+---
+
+▶️ **To apply** all schema changes from this PR, comment:
+```
+schemabot apply -e production
+```
+
+</details>
+
+<details>
+<summary><a name="targets-diverging"></a><strong>Targets Diverging</strong></summary>
+
+
+## Schema Change Plan — Production
+
+**Database**: `testapp` | **Type**: `MySQL` | **Schema Name**: `testapp`
+
+*Requested by @jackjackbits at 2026-01-01 00:00:00 UTC · planned from [`abcdef1`](https://github.com/block/schemabot/commit/abcdef1234567890abcdef1234567890abcdef12)*
+
+✅ **Planned separately for all 3 targets** (`primary/testapp_1`, `primary/testapp_2`, `primary/testapp_3`) — 2 distinct plans. Each target applies its own.
+
+<details open>
+<summary><b>`primary/testapp_1` (primary), `primary/testapp_2` — 1 DDL statement</b></summary>
+
+```sql
+ALTER TABLE `users` ADD COLUMN `email` varchar(255);
+```
+
+</details>
+
+<details>
+<summary><b>`primary/testapp_3` — 2 DDL statements</b></summary>
+
+```sql
+ALTER TABLE `users` ADD COLUMN `email` varchar(255);
+
+ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
+```
+
+</details>
+
+⚠️ Applying runs each target's own plan, including the ones collapsed above.
+
+📋 **Plan**: 2 distinct plans on 3 targets
+
+
 ---
 
 ▶️ **To apply** all schema changes from this PR, comment:

docs/configuration.md

@@ -7,6 +7,7 @@
 - [Local Mode](#local-mode)
 - [gRPC Mode](#grpc-mode)
 - [Multi-Deployment Environments](#multi-deployment-environments)
+- [Multi-Target Environment (preview)](#multi-target-environment-preview)
 - [Environment Order](#environment-order)
 - [Hybrid Mode](#hybrid-mode)
 - [Drivers](#drivers)
@@ -266,6 +267,51 @@ A multi-deployment environment is gated on every deployment agreeing with one re
 Every deployment name in `deployment_order` must be lowercase; the server
 refuses to start otherwise.
 
+## Multi-Target Environment (preview)
+
+A database that lives on more than one target replaces the scalar `target` with a `targets` list. Each entry is one target the environment addresses, and rollout follows the listed order.
+
+> **MySQL only.** `targets` is rejected at startup on any other database type. Addressing N targets has to be represented on every operator-facing surface — the plan comment, progress, the terminal summary — and that presentation is built per engine, so the feature is enabled per engine as the work lands.
+
+> **Config surface only in this release.** `targets` resolves to one rollout member per target, but the plan and apply paths still treat every member of an environment the way they treat deployments.
+
+```yaml
+databases:
+  payments:
+    type: mysql
+    environments:
+      production:
+        deployment: payments-a
+        targets:
+          - payments-001
+          - payments-002
+```
+
+A `targets` list can also sit inside a `deployments` map entry, for a database whose targets are spread across several deployments:
+
+```yaml
+      production:
+        deployments:
+          payments-a:
+            targets:
+              - payments-001
+              - payments-002
+          payments-b:
+            target: payments-003
+```
+
+Rules:
+
+- `targets` requires `type: mysql`. Configuring it on a `vitess`, `strata`, or `postgres` database fails validation at startup.
+- `targets` is mutually exclusive with `target` at the same level, and with a local `dsn` / `dsn_from`.
+- An environment-level `targets` list is mutually exclusive with an environment-level `deployments` map, the same way an environment-level `target` is. A `targets` list inside a `deployments` entry is how the two combine.
+- The list MUST contain at least one entry, and no entry may be empty.
+- No entry may contain `/`. A deployment addressing several targets names each one in its members' operation keys, and `/` separates a key's components.
+- One deployment may not list the same target twice. A rollout member is identified by its deployment and target together, so the same target under two different deployments is two distinct members and is allowed.
+- Members resolve deployments outermost: every target of the first deployment, then every target of the next.
+
+`targets` and `deployments` both fan an environment out across several members, but they mean different things. The deployments of one environment are expected to hold the same schema, so a difference between them is drift to surface. The targets of one environment are each planned on their own, so a difference between them is ordinary.
+
 ## Environment Order
 
 Environment availability and promotion order are server-owned. Repository `schemabot.yaml` files identify the database and type; they do not list or opt into environments. SchemaBot resolves the environments for a database from server config:

docs/schema-intelligence.md

@@ -310,6 +310,80 @@ A clean audit returns `lint: []`; an omitted field means lint was not requested.
 Pull runs schema-shape rules only. Rules about proposed changes, such as unsafe
 drops, require a plan. See [lint and safety levels](lint-and-safety-levels.md#auditing-a-live-schema-pull---lint).
 
+### Databases that span several targets
+
+A database whose environment lists `targets` addresses several targets at once,
+and each holds its own schema. There is no single live schema to return, so a
+pull returns the primary target's — the one a caller materializes — plus a
+`targets` array naming every target the environment addresses and how each of
+the others differs from the primary.
+
+```sh
+schemabot pull -d shop -e production
+```
+
+```sql
+-- Target `shop-001` — primary target, whose schema is below
+-- Target `shop-002` — same schema as the primary target
+-- Target `shop-003` — 2 tables differ from the primary target
+--   shop.audit_log: differs
+--   shop.order_events: missing
+```
+
+<details>
+<summary>API equivalent</summary>
+
+```http
+POST /api/pull
+Content-Type: application/json
+
+{"database": "shop", "environment": "production"}
+```
+
+```json
+{
+  "database": "shop",
+  "type": "mysql",
+  "environment": "production",
+  "table_count": 4,
+  "namespaces": {
+    "shop": {"tables": {"…": "CREATE TABLE …"}}
+  },
+  "targets": [
+    {"deployment": "commerce-a", "target": "shop-001", "table_count": 4, "primary": true},
+    {"deployment": "commerce-a", "target": "shop-002", "table_count": 4},
+    {"deployment": "commerce-a", "target": "shop-003", "table_count": 3, "diverged_tables": [
+      {"namespace": "shop", "table": "audit_log", "difference": "differs"},
+      {"namespace": "shop", "table": "order_events", "difference": "only_on_primary"}
+    ]}
+  ]
+}
+```
+
+</details>
+
+Read the array as the environment's whole member set. Exactly one entry carries
+`"primary": true`, and it is the target whose schema is in `namespaces`; it
+never carries `diverged_tables`, because it is the baseline the others are
+compared against. A reconciling caller can take the member set straight from
+this array rather than deriving it from target names.
+
+`difference` is one of:
+
+| Value | Meaning |
+|---|---|
+| `differs` | both targets hold the table, with different DDL |
+| `only_on_primary` | only the primary target holds the table |
+| `only_on_target` | only this target holds the table |
+
+An empty `diverged_tables` means the two targets genuinely agree. It never means
+the comparison was skipped: a target that cannot be pulled, or whose DDL cannot
+be parsed, fails the whole pull rather than being reported as converged. Tables
+are compared by their canonical parsed form, so formatting differences are not
+divergence.
+
+An environment that does not list `targets` carries no `targets` array at all.
+
 ### Engine support
 
 The envelope differs by dialect:
@@ -497,7 +571,12 @@ from the server's build phase and its counters; it stays below 100 until the
 apply completes and holds its last value between phases (see
 [postgresql.md](postgresql.md)).
 Sharded engines can add per-shard progress, and multi-deployment applies list
-operations with their deployment, target, state, and cutover policy.
+operations with their deployment, target, state, and cutover policy. A rollout's
+table entries carry `deployment` and `target`, naming the member whose copy the
+row reports. Attribute a table by the pair, never by `deployment` alone: one
+deployment can address several targets, each running its own copy of the change,
+so several rows for the same table share a deployment and differ only in their
+target. Both fields are absent on an apply that runs against a single target.
 The top-level `metadata` object carries engine-specific display fields when the
 engine reports them: PostgreSQL applies report their position through `phase`,
 `step`, `steps_total`, and `statement`; PlanetScale applies report deploy
@@ -538,6 +617,54 @@ Response excerpt (illustrative values):
 
 </details>
 
+<details>
+<summary>Multi-target rollout response example</summary>
+
+```http
+GET /api/progress/apply/apply-example-75
+```
+
+Response excerpt (illustrative values):
+
+```json
+{
+  "apply_id": "apply-example-75",
+  "database": "shop",
+  "environment": "production",
+  "engine": "spirit",
+  "state": "running",
+  "operations": [
+    {"deployment": "commerce-a", "target": "shop-001", "state": "completed", "cutover_policy": "rolling"},
+    {"deployment": "commerce-a", "target": "shop-002", "state": "running", "cutover_policy": "rolling"}
+  ],
+  "tables": [
+    {
+      "table_name": "orders",
+      "deployment": "commerce-a",
+      "target": "shop-001",
+      "ddl": "ALTER TABLE `orders` ADD INDEX `idx_status` (`status`)",
+      "status": "completed",
+      "percent_complete": 100
+    },
+    {
+      "table_name": "orders",
+      "deployment": "commerce-a",
+      "target": "shop-002",
+      "ddl": "ALTER TABLE `orders` ADD INDEX `idx_status` (`status`)",
+      "status": "running",
+      "rows_copied": 2000000,
+      "rows_total": 8000000,
+      "percent_complete": 25
+    }
+  ]
+}
+```
+
+Both rows report the same table under the same deployment, and only `target`
+tells them apart.
+
+</details>
+
 <details>
 <summary>PostgreSQL response example</summary>