TEMPLATES.md

<!-- Generated by scripts/update-templates.sh — do not edit manually -->
# SchemaBot Templates

All templates rendered with sample data.

## Plan & Status

### PR Comments

<details>
<summary><a name="mysql-plan"></a><strong>MySQL Plan</strong></summary>


## Schema Change Plan — Staging

**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)*

```sql
CREATE TABLE `users` (
    `id` bigint unsigned NOT NULL AUTO_INCREMENT,
    `email` varchar(255) NOT NULL,
    `created_at` timestamp DEFAULT current_timestamp(),
    PRIMARY KEY(`id`),
    INDEX `idx_email`(`email`)
) ENGINE InnoDB,
  CHARSET utf8mb4,
  COLLATE utf8mb4_0900_ai_ci;

CREATE TABLE `orders` (
    `id` bigint unsigned NOT NULL AUTO_INCREMENT,
    `user_id` bigint NOT NULL,
    `total_cents` bigint NOT NULL,
    `status` varchar(50) NOT NULL DEFAULT 'pending',
    PRIMARY KEY(`id`),
    INDEX `idx_user_id`(`user_id`)
) ENGINE InnoDB,
  CHARSET utf8mb4,
  COLLATE utf8mb4_0900_ai_ci;

ALTER TABLE `products` ADD INDEX `idx_category_price`(`category`, `price`);
```

⚠️ **Lint Warnings**:
- [users] Column "created_at" uses TIMESTAMP which overflows on 2038-01-19. Consider using DATETIME instead.
- [products] Index 'idx_category' on columns (category) is redundant - covered by index 'idx_category_price' on columns (category, price)

📋 **Plan**: **2** tables to create, **1** table to alter


---

💡 **To apply** all schema changes from this PR, comment:
```
schemabot apply -e staging
```

</details>

<details>
<summary><a name="mysql-plan-engineblocked-change"></a><strong>MySQL Plan (Engine-blocked Change)</strong></summary>


## Schema Change Plan — Staging

**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)*

```sql
ALTER TABLE `users`
    DROP PRIMARY KEY,
    ADD PRIMARY KEY(`id`, `tenant_id`);

ALTER TABLE `orders` ADD CONSTRAINT `fk_orders_user` FOREIGN KEY (`user_id`) REFERENCES `users`(`id`);

ALTER TABLE `orders` ADD COLUMN `notes` text;
```

⛔ **Cannot apply**: **2** changes not supported by the schema-change engine
- `users`: dropping primary key is not supported
- `orders`: adding foreign key constraints is not supported

An apply will fail on these statements. Rewrite them as a supported schema change, or contact your SchemaBot operators for help.

📋 **Plan**: **3** tables to alter


---

💡 **To apply** all schema changes from this PR, comment:
```
schemabot apply -e staging
```

</details>

<details>
<summary><a name="mysql-plan-directexecution-change"></a><strong>MySQL Plan (Direct-execution Change)</strong></summary>


## Schema Change Apply — Staging

**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)*

🔒 **Lock acquired by** `block/schemabot#42` at 2026-01-15 14:30:00 UTC

```sql
ALTER TABLE `users`
    DROP PRIMARY KEY,
    ADD PRIMARY KEY(`id`, `tenant_id`);

ALTER TABLE `orders` ADD COLUMN `notes` text;
```

⚙️ **Direct execution**: **1** change will run as native MySQL DDL
- `users`: dropping primary key is not supported; runs as native MySQL DDL on a table with ~1,240 rows

These statements run synchronously outside the schema-change engine: writes to each table are blocked while its statement runs, the change is **not revertible**, and `--defer-cutover` does not apply to it. Confirming the apply consents to this.

📋 **Plan**: **2** tables to alter


---

⚠️ **Automatic apply paused**: Plan contains direct-execution changes — review the disclosure and confirm manually

Review the plan above, then confirm manually:
```
schemabot apply-confirm -e staging
```

🔓 To discard this plan and unlock, comment:
```
schemabot unlock
```

</details>

<details>
<summary><a name="apply-rejected-engineblocked-changes"></a><strong>Apply Rejected (Engine-blocked Changes)</strong></summary>


## Schema Change Plan — Staging

**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)*

```sql
ALTER TABLE `users`
    DROP PRIMARY KEY,
    ADD PRIMARY KEY(`id`, `tenant_id`);

ALTER TABLE `orders` ADD COLUMN `notes` text;
```

📋 **Plan**: **2** tables to alter

---

**⛔ Apply rejected**: **1** planned change not supported by the schema-change engine
- `users`: dropping primary key is not supported; direct execution is enabled but the table has ~2,400,000 rows, above the configured limit of 1,000,000

Rewrite these statements as a supported schema change, or contact your SchemaBot operators for help.

</details>

<details>
<summary><a name="mysql-plan-tenant-target"></a><strong>MySQL Plan (Tenant Target)</strong></summary>


## Schema Change Plan — Staging

**Database**: `testapp` | **Type**: `MySQL` | **Schema Name**: `testapp` | **Tenant**: `alpha`

*Requested by @jackjackbits at 2026-01-01 00:00:00 UTC · planned from [`abcdef1`](https://github.com/block/schemabot/commit/abcdef1234567890abcdef1234567890abcdef12)*

```sql
CREATE TABLE `users` (
    `id` bigint unsigned NOT NULL AUTO_INCREMENT,
    `email` varchar(255) NOT NULL,
    `created_at` timestamp DEFAULT current_timestamp(),
    PRIMARY KEY(`id`),
    INDEX `idx_email`(`email`)
) ENGINE InnoDB,
  CHARSET utf8mb4,
  COLLATE utf8mb4_0900_ai_ci;

CREATE TABLE `orders` (
    `id` bigint unsigned NOT NULL AUTO_INCREMENT,
    `user_id` bigint NOT NULL,
    `total_cents` bigint NOT NULL,
    `status` varchar(50) NOT NULL DEFAULT 'pending',
    PRIMARY KEY(`id`),
    INDEX `idx_user_id`(`user_id`)
) ENGINE InnoDB,
  CHARSET utf8mb4,
  COLLATE utf8mb4_0900_ai_ci;

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 staging --tenant alpha
```

</details>

<details>
<summary><a name="mysql-plan-no-changes"></a><strong>MySQL Plan (No Changes)</strong></summary>


## Schema Change Plan — Staging

**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)*

✅ **No schema changes detected**

</details>

<details>
<summary><a name="no-managed-schema-changes"></a><strong>No Managed Schema Changes</strong></summary>


## ✅ No Managed Schema Changes

**Environment**: `staging`

*Requested by @jackjackbits at 2026-03-15 14:30:00 UTC*

This PR does not contain schema changes managed by SchemaBot. SchemaBot did not find any apply-owned state that requires live database reconciliation.

</details>

<details>
<summary><a name="no-managed-schema-changes-checks-refreshed"></a><strong>No Managed Schema Changes (Checks Refreshed)</strong></summary>


## ✅ No Managed Schema Changes

*Requested by @jackjackbits at 2026-03-15 14:30:00 UTC*

This PR does not contain schema changes managed by SchemaBot. The SchemaBot checks were refreshed as passing on `abcdef1234567890abcdef1234567890abcdef12`.

</details>

<details>
<summary><a name="no-managed-schema-changes-gated-on-tenants"></a><strong>No Managed Schema Changes (Gated On Tenants)</strong></summary>


## ✅ No Managed Schema Changes

*Requested by @jackjackbits at 2026-03-15 14:30:00 UTC*

This PR does not contain schema changes managed by this SchemaBot deployment, but it touches schema paths owned by tenant deployments. The SchemaBot check was refreshed on `abcdef1234567890abcdef1234567890abcdef12` and will pass once every tenant deployment's own check succeeds.

</details>

<details>
<summary><a name="reconciliation-required-in-progress"></a><strong>Reconciliation Required (In Progress)</strong></summary>


## ⚠️ Schema Change Reconciliation Required

**Database**: `testapp` | **Environment**: `staging` | **Apply ID**: `apply-09f8ba28fb67492e`

*Requested by @jackjackbits at 2026-03-15 14:30:00 UTC*

SchemaBot is still applying a schema change from this PR, but the current PR no longer contains that change.

The live database operation was already started and may continue independently of the current PR diff.

### What to do next

1. First, resolve the in-flight apply:
   - Wait for SchemaBot to post the final apply result, or
   - If stopping is supported for this database, comment:
     ```
     schemabot stop apply-09f8ba28fb67492e -e staging
     ```

2. Then reconcile the final live schema:
   - If the live schema change should remain, add the schema change back to the PR, then comment:
     ```
     schemabot plan -e staging -d testapp
     ```
   - If the live schema change should not remain, roll it back:
     ```
     schemabot rollback apply-09f8ba28fb67492e -e staging
     ```
     After rollback: push a no-op `schemabot.yaml` edit to trigger a fresh plan.
<!-- schemabot:offer-support-channel -->

> 💬 Support: [#schema-help](https://chat.example.com/schema-help).
</details>

<details>
<summary><a name="reconciliation-required-completed"></a><strong>Reconciliation Required (Completed)</strong></summary>


## ⚠️ Schema Change Reconciliation Required

**Database**: `testapp` | **Environment**: `staging` | **Apply ID**: `apply-09f8ba28fb67492e`

*Requested by @jackjackbits at 2026-03-15 14:30:00 UTC*

SchemaBot already applied a schema change from this PR, but the current PR no longer contains that change.

The live database was already updated and may no longer match the current PR schema files.

### What to do next

Choose one:

1. Keep the live schema change:
   - add the schema change back to the PR
   - comment:
     ```
     schemabot plan -e staging -d testapp
     ```

2. Undo the live schema change:
   - comment:
     ```
     schemabot rollback apply-09f8ba28fb67492e -e staging
     ```
   - after rollback: push a no-op `schemabot.yaml` edit to trigger a fresh plan
<!-- schemabot:offer-support-channel -->

> 💬 Support: [#schema-help](https://chat.example.com/schema-help).
</details>

<details>
<summary><a name="vitess-plan"></a><strong>Vitess Plan</strong></summary>


## Schema Change Plan — Staging

**Database**: `commerce` | **Type**: `Vitess`

*Requested by @jackjackbits at 2026-01-01 00:00:00 UTC · planned from [`abcdef1`](https://github.com/block/schemabot/commit/abcdef1234567890abcdef1234567890abcdef12)*

#### Keyspace: `commerce`
#### VSchema
```diff
--- a/commerce.json
+++ b/commerce.json
@@ -4,5 +4,8 @@
     "orders_seq": {
       "type": "sequence"
+    },
+    "address_seq": {
+      "type": "sequence"
     }
   }
 }
```

```sql
CREATE TABLE `address_seq` (
    `id` tinyint unsigned NOT NULL DEFAULT '0',
    `next_id` bigint unsigned,
    `cache` bigint unsigned,
    PRIMARY KEY(`id`)
) ENGINE InnoDB,
  CHARSET utf8mb4,
  COLLATE utf8mb4_0900_ai_ci,
  COMMENT 'vitess_sequence';
```

#### Keyspace: `commerce_sharded`
#### VSchema
```diff
--- a/commerce_sharded.json
+++ b/commerce_sharded.json
@@ -15,5 +15,16 @@
         }
       ]
     }
+    "addresses": {
+      "column_vindexes": [
+        {
+          "column": "customer_id",
+          "name": "hash"
+        }
+      ],
+      "auto_increment": {
+        "column": "id",
+        "sequence": "commerce.address_seq"
+      }
+    }
   }
 }
```

```sql
CREATE TABLE `addresses` (
    `id` bigint unsigned NOT NULL,
    `customer_id` bigint unsigned NOT NULL,
    `street` varchar(255) NOT NULL,
    `city` varchar(100) NOT NULL,
    PRIMARY KEY(`id`),
    INDEX `idx_customer_id`(`customer_id`)
) ENGINE InnoDB,
  CHARSET utf8mb4,
  COLLATE utf8mb4_0900_ai_ci;
```

📋 **Plan**: **2** tables to create, **2** vschema updates


---

💡 **To apply** all schema changes from this PR, comment:
```
schemabot apply -e staging
```

</details>

<details>
<summary><a name="schema-change-apply-locked--options"></a><strong>Schema Change Apply (Locked + Options)</strong></summary>


## Schema Change Apply — Staging

**Database**: `commerce` | **Type**: `Vitess`

*Requested by @jackjackbits at 2026-01-01 00:00:00 UTC · planned from [`abcdef1`](https://github.com/block/schemabot/commit/abcdef1234567890abcdef1234567890abcdef12)*

🔒 **Lock acquired by** `acme/myapp#42` at 2026-03-14 10:30:00 UTC

#### Keyspace: `commerce`
#### VSchema
```diff
--- a/commerce.json
+++ b/commerce.json
@@ -4,5 +4,8 @@
     "orders_seq": {
       "type": "sequence"
+    },
+    "address_seq": {
+      "type": "sequence"
     }
   }
 }
```

```sql
CREATE TABLE `address_seq` (
    `id` tinyint unsigned NOT NULL DEFAULT '0',
    `next_id` bigint unsigned,
    `cache` bigint unsigned,
    PRIMARY KEY(`id`)
) ENGINE InnoDB,
  CHARSET utf8mb4,
  COLLATE utf8mb4_0900_ai_ci,
  COMMENT 'vitess_sequence';
```

#### Keyspace: `commerce_sharded`
#### VSchema
```diff
--- a/commerce_sharded.json
+++ b/commerce_sharded.json
@@ -15,5 +15,16 @@
         }
       ]
     }
+    "addresses": {
+      "column_vindexes": [
+        {
+          "column": "customer_id",
+          "name": "hash"
+        }
+      ],
+      "auto_increment": {
+        "column": "id",
+        "sequence": "commerce.address_seq"
+      }
+    }
   }
 }
```

```sql
CREATE TABLE `addresses` (
    `id` bigint unsigned NOT NULL,
    `customer_id` bigint unsigned NOT NULL,
    `street` varchar(255) NOT NULL,
    `city` varchar(100) NOT NULL,
    PRIMARY KEY(`id`),
    INDEX `idx_customer_id`(`customer_id`)
) ENGINE InnoDB,
  CHARSET utf8mb4,
  COLLATE utf8mb4_0900_ai_ci;
```

📋 **Plan**: **2** tables to create, **2** vschema updates


**Options**: ⏸️ Defer Cutover | ⏩ Skip Revert

---

**Applying automatically**

</details>

<details>
<summary><a name="mysql-multischema-plan"></a><strong>MySQL Multi-schema Plan</strong></summary>


## Schema Change Plan — Staging

**Database**: `myapp` | **Type**: `MySQL`

*Requested by @jackjackbits at 2026-01-01 00:00:00 UTC · planned from [`abcdef1`](https://github.com/block/schemabot/commit/abcdef1234567890abcdef1234567890abcdef12)*

#### Schema Name: `app_primary`
```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);

ALTER TABLE `sessions` ADD COLUMN `device` varchar(100) DEFAULT '';
```

#### Schema Name: `app_analytics`
```sql
CREATE TABLE `metrics` (
    `id` bigint unsigned NOT NULL AUTO_INCREMENT,
    `name` varchar(255) NOT NULL,
    `value` double NOT NULL,
    `recorded_at` timestamp DEFAULT current_timestamp(),
    PRIMARY KEY(`id`),
    INDEX `idx_name_recorded`(`name`, `recorded_at`)
) ENGINE InnoDB,
  CHARSET utf8mb4,
  COLLATE utf8mb4_0900_ai_ci;
```

📋 **Plan**: **1** table to create, **2** tables to alter


---

💡 **To apply** all schema changes from this PR, comment:
```
schemabot apply -e staging
```

</details>

<details>
<summary><a name="multienv-plan-identical"></a><strong>Multi-env Plan (Identical)</strong></summary>


## Schema Change Plan

**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)*

### Staging & Production

<details>
<summary>Show SQL (3 statements)</summary>

```sql
CREATE TABLE `users` (
    `id` bigint unsigned NOT NULL AUTO_INCREMENT,
    `email` varchar(255) NOT NULL,
    `created_at` timestamp DEFAULT current_timestamp(),
    PRIMARY KEY(`id`),
    INDEX `idx_email`(`email`)
) ENGINE InnoDB,
  CHARSET utf8mb4,
  COLLATE utf8mb4_0900_ai_ci;

CREATE TABLE `orders` (
    `id` bigint unsigned NOT NULL AUTO_INCREMENT,
    `user_id` bigint NOT NULL,
    `total_cents` bigint NOT NULL,
    `status` varchar(50) NOT NULL DEFAULT 'pending',
    PRIMARY KEY(`id`),
    INDEX `idx_user_id`(`user_id`)
) ENGINE InnoDB,
  CHARSET utf8mb4,
  COLLATE utf8mb4_0900_ai_ci;

ALTER TABLE `products` ADD INDEX `idx_category_price`(`category`, `price`);
```

</details>

📋 **Plan**: **2** tables to create, **1** table to alter

---

💡 **To apply** these changes, start with the first environment:
```
schemabot apply -e staging
```

After verifying staging, apply to production:
```
schemabot apply -e production
```

</details>

<details>
<summary><a name="multienv-plan-different"></a><strong>Multi-env Plan (Different)</strong></summary>


## Schema Change Plan

**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)*

### Staging

✅ **No schema changes detected**

### Production

<details>
<summary>Show SQL (3 statements)</summary>

```sql
CREATE TABLE `users` (
    `id` bigint unsigned NOT NULL AUTO_INCREMENT,
    `email` varchar(255) NOT NULL,
    `created_at` timestamp DEFAULT current_timestamp(),
    PRIMARY KEY(`id`),
    INDEX `idx_email`(`email`)
) ENGINE InnoDB,
  CHARSET utf8mb4,
  COLLATE utf8mb4_0900_ai_ci;

CREATE TABLE `orders` (
    `id` bigint unsigned NOT NULL AUTO_INCREMENT,
    `user_id` bigint NOT NULL,
    `total_cents` bigint NOT NULL,
    `status` varchar(50) NOT NULL DEFAULT 'pending',
    PRIMARY KEY(`id`),
    INDEX `idx_user_id`(`user_id`)
) ENGINE InnoDB,
  CHARSET utf8mb4,
  COLLATE utf8mb4_0900_ai_ci;

ALTER TABLE `products` ADD INDEX `idx_category_price`(`category`, `price`);
```

</details>

📋 **Plan**: **2** tables to create, **1** table to alter

---

💡 **To apply** these changes, comment:
```
schemabot apply -e production
```

</details>

<details>
<summary><a name="multienv-plan-error"></a><strong>Multi-env Plan (Error)</strong></summary>


## Schema Change Plan

**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)*

### Staging

<details>
<summary>Show SQL (3 statements)</summary>

```sql
CREATE TABLE `users` (
    `id` bigint unsigned NOT NULL AUTO_INCREMENT,
    `email` varchar(255) NOT NULL,
    `created_at` timestamp DEFAULT current_timestamp(),
    PRIMARY KEY(`id`),
    INDEX `idx_email`(`email`)
) ENGINE InnoDB,
  CHARSET utf8mb4,
  COLLATE utf8mb4_0900_ai_ci;

CREATE TABLE `orders` (
    `id` bigint unsigned NOT NULL AUTO_INCREMENT,
    `user_id` bigint NOT NULL,
    `total_cents` bigint NOT NULL,
    `status` varchar(50) NOT NULL DEFAULT 'pending',
    PRIMARY KEY(`id`),
    INDEX `idx_user_id`(`user_id`)
) ENGINE InnoDB,
  CHARSET utf8mb4,
  COLLATE utf8mb4_0900_ai_ci;

ALTER TABLE `products` ADD INDEX `idx_category_price`(`category`, `price`);
```

</details>

📋 **Plan**: **2** tables to create, **1** table to alter

### Production


> ⚠️ **Error:** tern client: resolve DSN for testapp/production: connection refused

---

💡 **To apply** these changes, comment:
```
schemabot apply -e staging
```

⚠️ **Production** failed to plan. Resolve the error above and re-run:
```
schemabot plan -e production
```

</details>

<details>
<summary><a name="multienv-plan-lint-warnings"></a><strong>Multi-env Plan (Lint Warnings)</strong></summary>


## Schema Change Plan

**Database**: `testapp` | **Type**: `MySQL` | **Schema Name**: `testapp`

*Started at 2026-01-01 00:00:00 UTC · planned from [`abcdef1`](https://github.com/block/schemabot/commit/abcdef1234567890abcdef1234567890abcdef12)*

### Staging & Production

<details>
<summary>Show SQL (3 statements)</summary>

```sql
CREATE TABLE `users` (
    `id` bigint unsigned NOT NULL AUTO_INCREMENT,
    `email` varchar(255) NOT NULL,
    `created_at` timestamp DEFAULT current_timestamp(),
    PRIMARY KEY(`id`),
    INDEX `idx_email`(`email`)
) ENGINE InnoDB,
  CHARSET utf8mb4,
  COLLATE utf8mb4_0900_ai_ci;

CREATE TABLE `orders` (
    `id` bigint unsigned NOT NULL AUTO_INCREMENT,
    `user_id` bigint NOT NULL,
    `total_cents` bigint NOT NULL,
    `status` varchar(50) NOT NULL DEFAULT 'pending',
    PRIMARY KEY(`id`),
    INDEX `idx_user_id`(`user_id`)
) ENGINE InnoDB,
  CHARSET utf8mb4,
  COLLATE utf8mb4_0900_ai_ci;

ALTER TABLE `products` ADD INDEX `idx_category_price`(`category`, `price`);
```

</details>

⚠️ **Lint Warnings**:
- [users] Column "created_at" uses TIMESTAMP which overflows on 2038-01-19. Consider using DATETIME instead.
- [products] Index 'idx_category' on columns (category) is redundant - covered by index 'idx_category_price' on columns (category, price)

📋 **Plan**: **2** tables to create, **1** table to alter

---

💡 **To apply** these changes, start with the first environment:
```
schemabot apply -e staging
```

After verifying staging, apply to production:
```
schemabot apply -e production
```

</details>

<details>
<summary><a name="drop-column-blocked"></a><strong>Drop Column Blocked</strong></summary>


## Schema Change Plan — Staging

**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)*

```sql
ALTER TABLE `customers` DROP COLUMN `nickname`;
```

📋 **Plan**: **1** table to alter

---

**⛔ 1 Unsafe Change Detected:**
- `customers`: Unsafe operation detected: DROP COLUMN `nickname`

**Destructive drop guidance:**

Before allowing a destructive drop, first deploy application code that no longer reads from or writes to the dropped column.

**🚨 To proceed with these destructive changes, re-run with `--allow-unsafe`:**
```
schemabot apply -e staging --allow-unsafe
```
<!-- schemabot:offer-support-channel -->

</details>

<details>
<summary><a name="drop-index-blocked"></a><strong>Drop Index Blocked</strong></summary>


## Schema Change Plan — Staging

**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)*

```sql
ALTER TABLE `customers` DROP INDEX `idx_customers_email`;
```

📋 **Plan**: **1** table to alter

---

**⛔ 1 Unsafe Change Detected:**
- `customers`: Unsafe operation detected: DROP INDEX `idx_customers_email`

**Destructive drop guidance:**

Before dropping an index in MySQL, first make the dropped index invisible and verify application queries no longer rely on it for safe performance.

**🚨 To proceed with these destructive changes, re-run with `--allow-unsafe`:**
```
schemabot apply -e staging --allow-unsafe
```
<!-- schemabot:offer-support-channel -->

</details>

<details>
<summary><a name="schema-lint-errors-blocked"></a><strong>Schema Lint Errors Blocked</strong></summary>


## Schema Change Plan — Staging

**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)*

```sql
ALTER TABLE `orders` MODIFY COLUMN `id` int NOT NULL AUTO_INCREMENT;

ALTER TABLE `users` RENAME COLUMN `email` TO `email_address`;
```

📋 **Plan**: **2** tables to alter

---

**⛔ 2 Unsafe Changes Detected:**
- `orders`: Primary key column "id" has type "int"
- `users`: Column rename detected in table "users": "email" to "email_address". Renaming a column cannot be done atomically across application pods, and ORMs that generate column names at compile time (e.g. jOOQ) will break until code is recompiled

**🚨 To proceed with these destructive changes, re-run with `--allow-unsafe`:**
```
schemabot apply -e staging --allow-unsafe
```
<!-- schemabot:offer-support-channel -->

</details>

<details>
<summary><a name="help-comment"></a><strong>Help Comment</strong></summary>


## 📚 SchemaBot Help

| Command | Description |
|---------|-------------|
| `schemabot plan [-e <env>]` | Preview schema changes |
| `schemabot apply -e <env>` | Plan, lock, and apply after safety rechecks |
| `schemabot apply-confirm -e <env>` | Confirm a downgraded locked plan |
| `schemabot unlock` | Release lock and discard plan |
| `schemabot stop <apply-id> -e <env>` | Stop an in-progress deployment |
| `schemabot cancel <apply-id> -e <env>` | Permanently cancel an in-progress deployment |
| `schemabot start <apply-id> -e <env>` | Resume a stopped deployment |
| `schemabot release <apply-id> -e <env>` | Release a paused rollout to proceed |
| `schemabot cutover <apply-id> -e <env>` | Complete a deferred cutover |
| `schemabot volume <apply-id> -e <env> -v <level>` | Adjust schema change speed (1=slowest, 11=fastest) |
| `schemabot rollback <apply-id> -e <env> [-t <tenant>]` | Generate a rollback plan |
| `schemabot rollback-confirm -e <env> [-t <tenant>]` | Execute a rollback |

**Options**: `-e <env>` environment, `-d <db>` database, `-t, --tenant <name>` deployment routing, `--defer-cutover`, `--allow-unsafe`, `--skip-revert` (Vitess)

**Quick start**: `plan` → `apply`
<!-- schemabot:offer-support-channel -->

</details>

<details>
<summary><a name="support-channel-footer"></a><strong>Support Channel Footer</strong></summary>


### Invalid command

## ❌ Invalid Command

That command wasn't recognized. Available commands:

| Command | Description |
|---------|-------------|
| `schemabot plan [-e <env>]` | Preview schema changes |
| `schemabot apply -e <env>` | Plan, lock, and apply after safety rechecks |
| `schemabot apply-confirm -e <env>` | Confirm a downgraded locked plan |
| `schemabot unlock` | Release lock and discard plan |
| `schemabot stop <apply-id> -e <env>` | Stop an in-progress deployment |
| `schemabot cancel <apply-id> -e <env>` | Permanently cancel an in-progress deployment |
| `schemabot start <apply-id> -e <env>` | Resume a stopped deployment |
| `schemabot release <apply-id> -e <env>` | Release a paused rollout to proceed |
| `schemabot cutover <apply-id> -e <env>` | Complete a deferred cutover |
| `schemabot volume <apply-id> -e <env> -v <level>` | Adjust schema change speed (1=slowest, 11=fastest) |
| `schemabot rollback <apply-id> -e <env> [-t <tenant>]` | Generate a rollback plan |
| `schemabot rollback-confirm -e <env> [-t <tenant>]` | Execute a rollback |

**Options**: `-e <env>` environment, `-d <db>` database, `-t, --tenant <name>` deployment routing, `--defer-cutover`, `--allow-unsafe`, `--skip-revert` (Vitess)

**Quick start**: `plan` → `apply`
<!-- schemabot:offer-support-channel -->

> 💬 Support: [#schema-help](https://chat.example.com/schema-help).

### Apply failure

## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: Failed
<!-- schemabot:offer-support-channel -->

📊 1/3 complete · 1 failed · 1 cancelled

**Schema `testapp`**

**`users`**: 🟥🟥🟥🟥🟥🟥⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ ❌ Failed

```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```

**`orders`**: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Complete

```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`products`**: ⊘ Cancelled (not started)

```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```


> ⚠️ **Error:** lock wait timeout exceeded; try restarting transaction

---

To retry:
```
schemabot apply -e staging
```

> 💬 Support: [#schema-help](https://chat.example.com/schema-help).
</details>

<details>
<summary><a name="no-config-no-d-flag"></a><strong>No Config (No -d Flag)</strong></summary>


## ℹ️ No SchemaBot Configuration Found

**Environment**: `staging`

*Requested by @jackjackbits at 2026-01-15 14:30:00 UTC*

No `schemabot.yaml` configuration file was found in this repository.

### Setup Instructions
Create a `schemabot.yaml` file in your schema directory:

```yaml
database: your-database-name
type: mysql
```

### If you already have a config
Use the `-d` flag to specify which database to plan:

```
schemabot plan -e staging -d <database-name>
```
</details>

<details>
<summary><a name="multiple-databases"></a><strong>Multiple Databases</strong></summary>


## ⚠️ Multiple Databases Detected

**Environment**: `staging`

*Requested by @jackjackbits at 2026-01-15 14:30:00 UTC*

This repository has multiple `schemabot.yaml` configurations.

### Available Databases

- `testapp` (schema/testapp/schemabot.yaml)
- `payments` (schema/payments/schemabot.yaml)

### How to specify a database

Use the `-d` flag:

```
schemabot plan -e staging -d <database-name>
```
<!-- schemabot:offer-support-channel -->

</details>

<details>
<summary><a name="database-not-found"></a><strong>Database Not Found</strong></summary>


## ⚠️ Database Not Found

**Database**: `nonexistent-db` | **Environment**: `staging`

*Requested by @jackjackbits at 2026-01-15 14:30:00 UTC*

No `schemabot.yaml` configuration with `database: nonexistent-db` was found in this repository.

Check that your `schemabot.yaml` file has the correct `database` field matching the `-d` flag value.
<!-- schemabot:offer-support-channel -->

</details>

<details>
<summary><a name="invalid-config"></a><strong>Invalid Config</strong></summary>


## ⚠️ No Valid SchemaBot Configuration Found

**Environment**: `staging`

*Requested by @jackjackbits at 2026-01-15 14:30:00 UTC*

The `schemabot.yaml` file must include `database` and `type` fields:

```yaml
database: your-database-name
type: mysql
```

- **database** (required): The database name
- **type** (required): `vitess` or `mysql`
<!-- schemabot:offer-support-channel -->

</details>

<details>
<summary><a name="unmanaged-schema-configs-notice"></a><strong>Unmanaged Schema Configs Notice</strong></summary>


## ⚠️ Schema Changes Not Managed by SchemaBot

This PR changes schema under the following path(s), which this SchemaBot instance is not configured to manage:

- `services/inventory/schema` — declares database `inventory`

These schema changes will **not** be planned or applied, and the SchemaBot checks on this PR do not cover them.

If SchemaBot should manage them, ask a SchemaBot operator to add the directory to the database's `allowed_dirs` in the server config; otherwise remove these schema changes from this PR.
<!-- schemabot:offer-support-channel -->

> 💬 Support: [#schema-help](https://chat.example.com/schema-help).
</details>

<details>
<summary><a name="generic-error"></a><strong>Generic Error</strong></summary>


## ❌ Plan Failed

**Environment**: `staging`

*Requested by @jackjackbits at 2026-01-15 14:30:00 UTC*

### Error

> failed to fetch repository contents: API rate limit exceeded
<!-- schemabot:offer-support-channel -->

</details>

<details>
<summary><a name="autoplan-generic-error"></a><strong>Auto-plan: Generic Error</strong></summary>


## ❌ Plan Failed

**Environment**: `staging`

*Triggered automatically by a pull request update at 2026-01-15 14:30:00 UTC*

### Error

> failed to fetch repository contents: API rate limit exceeded
<!-- schemabot:offer-support-channel -->

</details>

<details>
<summary><a name="missing-e-flag"></a><strong>Missing -e Flag</strong></summary>


## ❌ Missing Argument

You'll need to specify which environment to target with the `-e` flag.

**Usage**: `schemabot plan -e <environment>`

**Example**:
```
schemabot plan -e staging
```
<!-- schemabot:offer-support-channel -->

</details>

<details>
<summary><a name="invalid-command"></a><strong>Invalid Command</strong></summary>


## ❌ Invalid Command

That command wasn't recognized. Available commands:

| Command | Description |
|---------|-------------|
| `schemabot plan [-e <env>]` | Preview schema changes |
| `schemabot apply -e <env>` | Plan, lock, and apply after safety rechecks |
| `schemabot apply-confirm -e <env>` | Confirm a downgraded locked plan |
| `schemabot unlock` | Release lock and discard plan |
| `schemabot stop <apply-id> -e <env>` | Stop an in-progress deployment |
| `schemabot cancel <apply-id> -e <env>` | Permanently cancel an in-progress deployment |
| `schemabot start <apply-id> -e <env>` | Resume a stopped deployment |
| `schemabot release <apply-id> -e <env>` | Release a paused rollout to proceed |
| `schemabot cutover <apply-id> -e <env>` | Complete a deferred cutover |
| `schemabot volume <apply-id> -e <env> -v <level>` | Adjust schema change speed (1=slowest, 11=fastest) |
| `schemabot rollback <apply-id> -e <env> [-t <tenant>]` | Generate a rollback plan |
| `schemabot rollback-confirm -e <env> [-t <tenant>]` | Execute a rollback |

**Options**: `-e <env>` environment, `-d <db>` database, `-t, --tenant <name>` deployment routing, `--defer-cutover`, `--allow-unsafe`, `--skip-revert` (Vitess)

**Quick start**: `plan` → `apply`
<!-- schemabot:offer-support-channel -->
</details>

### CLI Output

<details>
<summary><a name="plan-mysql"></a><strong>Plan (MySQL)</strong></summary>

```

╭─────────────────────────────────────────────╮
│  MySQL Schema Change Plan                   │
│                                             │
│  Database: testapp                          │
│  Environment: staging                       │
│  Schema name: testapp                       │
╰─────────────────────────────────────────────╯

     + users
       CREATE TABLE `users` (
           `id` bigint NOT NULL AUTO_INCREMENT,
           `email` varchar(255) NOT NULL,
           `created_at` timestamp DEFAULT current_timestamp(),
           PRIMARY KEY(`id`),
           INDEX `idx_email`(`email`)
       );

     + orders
       CREATE TABLE `orders` (
           `id` bigint NOT NULL AUTO_INCREMENT,
           `user_id` bigint NOT NULL,
           `total_cents` bigint NOT NULL,
           `status` varchar(50) NOT NULL DEFAULT 'pending',
           PRIMARY KEY(`id`),
           INDEX `idx_user_id`(`user_id`)
       );

     ~ products
       ALTER TABLE `products` ADD INDEX `idx_category_price`(`category`, `price`);

⚠️  Lint Warnings:
  - [orders] has_float: New column uses floating-point data type
  - [users] no_default: Column added without DEFAULT value

📋 Plan: 2 tables to create, 1 table to alter

Options: ⏸️ Defer Cutover

```
</details>

<details>
<summary><a name="plan-no-changes"></a><strong>Plan (No Changes)</strong></summary>

```

╭─────────────────────────────────────────────╮
│  MySQL Schema Change Plan                   │
│                                             │
│  Database: testapp                          │
│  Environment: staging                       │
│  Schema name: testapp                       │
╰─────────────────────────────────────────────╯

✓ No schema changes detected.


```
</details>

<details>
<summary><a name="plan-vitess"></a><strong>Plan (Vitess)</strong></summary>

```

╭─────────────────────────────────────────────╮
│  Vitess Schema Change Plan                  │
│                                             │
│  Database: commerce                         │
│  Environment: staging                       │
╰─────────────────────────────────────────────╯


  ── commerce ──

     ~ VSchema:
              "auto_increment": {
                "column": "id",
                "sequence": "orders_seq"
       +      },
       +      "column_vindexes": [
       +        { "column": "region", "name": "region_map" }
       +      ]
              }
            }
          }

     ~ orders
       ALTER TABLE `orders`
           ADD COLUMN `region` varchar(50) NOT NULL DEFAULT '',
           ADD INDEX `idx_region`(`region`);


  ── customer ──

     + addresses
       CREATE TABLE `addresses` (
           `id` bigint unsigned NOT NULL AUTO_INCREMENT,
           `customer_id` bigint NOT NULL,
           `street` varchar(255) NOT NULL,
           `city` varchar(100) NOT NULL,
           PRIMARY KEY(`id`),
           INDEX `idx_customer_id`(`customer_id`)
       ) ENGINE InnoDB,
         CHARSET utf8mb4,
         COLLATE utf8mb4_0900_ai_ci;

📋 Plan: 1 table to create, 1 table to alter


```
</details>

<details>
<summary><a name="multienv-plan-identical"></a><strong>Multi-env Plan (Identical)</strong></summary>

```

╭─────────────────────────────────────────────╮
│  MySQL Schema Change Plan                   │
│                                             │
│  Database: testapp                          │
│  Schema name: testapp                       │
╰─────────────────────────────────────────────╯

     + users
       CREATE TABLE `users` (
           `id` bigint NOT NULL AUTO_INCREMENT,
           `email` varchar(255) NOT NULL,
           `created_at` timestamp DEFAULT current_timestamp(),
           PRIMARY KEY(`id`),
           INDEX `idx_email`(`email`)
       );

     + orders
       CREATE TABLE `orders` (
           `id` bigint NOT NULL AUTO_INCREMENT,
           `user_id` bigint NOT NULL,
           `total_cents` bigint NOT NULL,
           `status` varchar(50) NOT NULL DEFAULT 'pending',
           PRIMARY KEY(`id`),
           INDEX `idx_user_id`(`user_id`)
       );

     ~ products
       ALTER TABLE `products` ADD INDEX `idx_category_price`(`category`, `price`);

📋 Plan: 2 tables to create, 1 table to alter


```
</details>

<details>
<summary><a name="multienv-plan-different"></a><strong>Multi-env Plan (Different)</strong></summary>

```

╭─────────────────────────────────────────────╮
│  MySQL Schema Change Plan                   │
│                                             │
│  Database: testapp                          │
│  Schema name: testapp                       │
╰─────────────────────────────────────────────╯

Staging
✓ No schema changes detected.

Production
     + users
       CREATE TABLE `users` (
           `id` bigint NOT NULL AUTO_INCREMENT,
           `email` varchar(255) NOT NULL,
           `created_at` timestamp DEFAULT current_timestamp(),
           PRIMARY KEY(`id`),
           INDEX `idx_email`(`email`)
       );

     + orders
       CREATE TABLE `orders` (
           `id` bigint NOT NULL AUTO_INCREMENT,
           `user_id` bigint NOT NULL,
           `total_cents` bigint NOT NULL,
           `status` varchar(50) NOT NULL DEFAULT 'pending',
           PRIMARY KEY(`id`),
           INDEX `idx_user_id`(`user_id`)
       );

     ~ products
       ALTER TABLE `products` ADD INDEX `idx_category_price`(`category`, `price`);

📋 Plan: 2 tables to create, 1 table to alter


```
</details>

<details>
<summary><a name="multienv-plan-lint-warnings"></a><strong>Multi-env Plan (Lint Warnings)</strong></summary>

```

╭─────────────────────────────────────────────╮
│  MySQL Schema Change Plan                   │
│                                             │
│  Database: testapp                          │
│  Schema name: testapp                       │
╰─────────────────────────────────────────────╯

     + users
       CREATE TABLE `users` (
           `id` bigint NOT NULL AUTO_INCREMENT,
           `email` varchar(255) NOT NULL,
           `created_at` timestamp DEFAULT current_timestamp(),
           PRIMARY KEY(`id`),
           INDEX `idx_email`(`email`)
       );

     + orders
       CREATE TABLE `orders` (
           `id` bigint NOT NULL AUTO_INCREMENT,
           `user_id` bigint NOT NULL,
           `total_cents` bigint NOT NULL,
           `status` varchar(50) NOT NULL DEFAULT 'pending',
           PRIMARY KEY(`id`),
           INDEX `idx_user_id`(`user_id`)
       );

     ~ products
       ALTER TABLE `products` ADD INDEX `idx_category_price`(`category`, `price`);

⚠️  Lint Warnings:
  - [orders] has_float: New column uses floating-point data type
  - [users] no_default: Column added without DEFAULT value

📋 Plan: 2 tables to create, 1 table to alter

```
</details>


## Aggregate Check — Details summary

<details>
<summary><strong>Aggregate Check — Details summary</strong></summary>

Apply in progress

| Database | Type | Change | Status |
|----------|------|--------|--------|
| `commerce` | vitess | 2 creates, 1 alter · 2 vschema updates | In progress |
| `orders` | mysql | 1 alter | Applied |

**Tenant deployments**

| Tenant | Status |
|--------|--------|
| `tenant-b` | Applied |
| `tenant-c` | In progress |

</details>

## Locking

### PR Comments

<details>
<summary><a name="unlock-success"></a><strong>Unlock Success</strong></summary>


## 🔓 Lock Released — Staging

**Database**: `testapp`

*Released by @jackjackbits at 2026-01-01 00:00:00 UTC*

The database is now available for schema changes.

</details>

<details>
<summary><a name="no-lock-found"></a><strong>No Lock Found</strong></summary>


## 🔒 No Lock Found — Staging

**Database**: `testapp`

No apply lock is held for this database. Run `apply` first to generate a plan and acquire the lock.

```
schemabot apply -e staging
```
</details>

### CLI Output

<details>
<summary><a name="lock-acquired"></a><strong>Lock Acquired</strong></summary>

```

🔒 Lock acquired for testapp (mysql)

```
</details>

<details>
<summary><a name="lock-conflict-pr"></a><strong>Lock Conflict (PR)</strong></summary>

```


❌ Apply Blocked: Database Locked

┌───────────────────────────────────┐
│  Database:   testapp (mysql)      │
│  Locked by:  block/schemabot#123  │
│  Since:      2 hours ago          │
│  PR:         block/schemabot#123  │
└───────────────────────────────────┘

Another schema change is in progress for this database.

Options:
  • Wait for the current schema change to complete
  • Ask the lock owner to release: schemabot unlock
  • Force unlock: schemabot unlock -d testapp --force


```
</details>

<details>
<summary><a name="lock-conflict-cli"></a><strong>Lock Conflict (CLI)</strong></summary>

```


❌ Apply Blocked: Database Locked

┌────────────────────────────────────────────────┐
│  Database:   testapp (mysql)                   │
│  Locked by:  cli:deploy@prod-host.example.com  │
│  Since:      45 minutes ago                    │
└────────────────────────────────────────────────┘

Another schema change is in progress for this database.

Options:
  • Wait for the current schema change to complete
  • Ask the lock owner to release: schemabot unlock
  • Force unlock: schemabot unlock -d testapp --force


```
</details>

<details>
<summary><a name="lock-released"></a><strong>Lock Released</strong></summary>

```

🔓 Lock released for testapp (mysql)

```
</details>

<details>
<summary><a name="force-release"></a><strong>Force Release</strong></summary>

```

⚠️  Force released lock for testapp (mysql)
   Previous owner: block/schemabot#123

```
</details>

<details>
<summary><a name="no-lock-found"></a><strong>No Lock Found</strong></summary>

```

No lock found for testapp (mysql)

```
</details>

<details>
<summary><a name="lock-exists-under-other-type"></a><strong>Lock Exists Under Other Type</strong></summary>

```

No lock found for testapp (mysql), but a vitess lock exists for this database.
Release it with: schemabot unlock -d testapp -t vitess

```
</details>

<details>
<summary><a name="unlock-not-owned"></a><strong>Unlock Not Owned</strong></summary>

```


⚠️  Cannot release lock

  Database:      testapp (mysql)
  Current owner: block/schemabot#123

You can only release locks that you own.
Use --force to release a lock owned by someone else.


```
</details>

<details>
<summary><a name="locks-list"></a><strong>Locks List</strong></summary>

```

🔒 Active Locks (2)

  1. testapp (mysql)
     Owner: cli:jackjackbits@macbook
     Since: 30 minutes ago
     Last activity: 5 minutes ago

  2. payments (vitess)
     Owner: block/payments-api#456
     Since: 3 hours ago
     PR:    block/payments-api#456

To release a lock:
  schemabot unlock -d <database> -t <type>
  schemabot unlock -d <database> -t <type> --force  # override ownership
```
</details>

<details>
<summary><a name="no-locks"></a><strong>No Locks</strong></summary>

```

No active locks.
```
</details>

## Apply Flow

### PR Comments

<details>
<summary><a name="schema-change-apply-automatic"></a><strong>Schema Change Apply (Automatic)</strong></summary>


## Schema Change Apply — Staging

**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)*

🔒 **Lock acquired by** `acme/myapp#42` at 2026-03-14 10:30:00 UTC

```sql
CREATE TABLE `users` (
    `id` bigint unsigned NOT NULL AUTO_INCREMENT,
    `email` varchar(255) NOT NULL,
    `created_at` timestamp DEFAULT current_timestamp(),
    PRIMARY KEY(`id`),
    INDEX `idx_email`(`email`)
) ENGINE InnoDB,
  CHARSET utf8mb4,
  COLLATE utf8mb4_0900_ai_ci;

CREATE TABLE `orders` (
    `id` bigint unsigned NOT NULL AUTO_INCREMENT,
    `user_id` bigint NOT NULL,
    `total_cents` bigint NOT NULL,
    `status` varchar(50) NOT NULL DEFAULT 'pending',
    PRIMARY KEY(`id`),
    INDEX `idx_user_id`(`user_id`)
) ENGINE InnoDB,
  CHARSET utf8mb4,
  COLLATE utf8mb4_0900_ai_ci;

ALTER TABLE `products` ADD INDEX `idx_category_price`(`category`, `price`);
```

📋 **Plan**: **2** tables to create, **1** table to alter


---

**Applying automatically**

</details>

<details>
<summary><a name="schema-change-apply-with-options"></a><strong>Schema Change Apply (With Options)</strong></summary>


## Schema Change Apply — Staging

**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)*

🔒 **Lock acquired by** `acme/myapp#42` at 2026-03-14 10:30:00 UTC

```sql
CREATE TABLE `users` (
    `id` bigint unsigned NOT NULL AUTO_INCREMENT,
    `email` varchar(255) NOT NULL,
    `created_at` timestamp DEFAULT current_timestamp(),
    PRIMARY KEY(`id`),
    INDEX `idx_email`(`email`)
) ENGINE InnoDB,
  CHARSET utf8mb4,
  COLLATE utf8mb4_0900_ai_ci;

CREATE TABLE `orders` (
    `id` bigint unsigned NOT NULL AUTO_INCREMENT,
    `user_id` bigint NOT NULL,
    `total_cents` bigint NOT NULL,
    `status` varchar(50) NOT NULL DEFAULT 'pending',
    PRIMARY KEY(`id`),
    INDEX `idx_user_id`(`user_id`)
) ENGINE InnoDB,
  CHARSET utf8mb4,
  COLLATE utf8mb4_0900_ai_ci;

ALTER TABLE `products` ADD INDEX `idx_category_price`(`category`, `price`);
```

📋 **Plan**: **2** tables to create, **1** table to alter


**Options**: ⏸️ Defer Cutover | ⏩ Skip Revert

---

**Applying automatically**

</details>

<details>
<summary><a name="schema-change-apply-downgraded"></a><strong>Schema Change Apply (Downgraded)</strong></summary>


## Schema Change Apply — Staging

**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)*

🔒 **Lock acquired by** `acme/myapp#42` at 2026-03-14 10:30:00 UTC

```sql
CREATE TABLE `users` (
    `id` bigint unsigned NOT NULL AUTO_INCREMENT,
    `email` varchar(255) NOT NULL,
    `created_at` timestamp DEFAULT current_timestamp(),
    PRIMARY KEY(`id`),
    INDEX `idx_email`(`email`)
) ENGINE InnoDB,
  CHARSET utf8mb4,
  COLLATE utf8mb4_0900_ai_ci;

CREATE TABLE `orders` (
    `id` bigint unsigned NOT NULL AUTO_INCREMENT,
    `user_id` bigint NOT NULL,
    `total_cents` bigint NOT NULL,
    `status` varchar(50) NOT NULL DEFAULT 'pending',
    PRIMARY KEY(`id`),
    INDEX `idx_user_id`(`user_id`)
) ENGINE InnoDB,
  CHARSET utf8mb4,
  COLLATE utf8mb4_0900_ai_ci;

ALTER TABLE `products` ADD INDEX `idx_category_price`(`category`, `price`);
```

📋 **Plan**: **2** tables to create, **1** table to alter


---

⚠️ **Automatic apply paused**: Schema changes differ from auto-plan — review and confirm manually

Review the plan above, then confirm manually:
```
schemabot apply-confirm -e staging
```

🔓 To discard this plan and unlock, comment:
```
schemabot unlock
```

</details>

<details>
<summary><a name="schema-change-apply-vitess--options"></a><strong>Schema Change Apply (Vitess + Options)</strong></summary>


## Schema Change Apply — Staging

**Database**: `commerce` | **Type**: `Vitess`

*Requested by @jackjackbits at 2026-01-01 00:00:00 UTC · planned from [`abcdef1`](https://github.com/block/schemabot/commit/abcdef1234567890abcdef1234567890abcdef12)*

🔒 **Lock acquired by** `acme/myapp#42` at 2026-03-14 10:30:00 UTC

#### Keyspace: `commerce`
#### VSchema
```diff
--- a/commerce.json
+++ b/commerce.json
@@ -4,5 +4,8 @@
     "orders_seq": {
       "type": "sequence"
+    },
+    "address_seq": {
+      "type": "sequence"
     }
   }
 }
```

```sql
CREATE TABLE `address_seq` (
    `id` tinyint unsigned NOT NULL DEFAULT '0',
    `next_id` bigint unsigned,
    `cache` bigint unsigned,
    PRIMARY KEY(`id`)
) ENGINE InnoDB,
  CHARSET utf8mb4,
  COLLATE utf8mb4_0900_ai_ci,
  COMMENT 'vitess_sequence';
```

#### Keyspace: `commerce_sharded`
#### VSchema
```diff
--- a/commerce_sharded.json
+++ b/commerce_sharded.json
@@ -15,5 +15,16 @@
         }
       ]
     }
+    "addresses": {
+      "column_vindexes": [
+        {
+          "column": "customer_id",
+          "name": "hash"
+        }
+      ],
+      "auto_increment": {
+        "column": "id",
+        "sequence": "commerce.address_seq"
+      }
+    }
   }
 }
```

```sql
CREATE TABLE `addresses` (
    `id` bigint unsigned NOT NULL,
    `customer_id` bigint unsigned NOT NULL,
    `street` varchar(255) NOT NULL,
    `city` varchar(100) NOT NULL,
    PRIMARY KEY(`id`),
    INDEX `idx_customer_id`(`customer_id`)
) ENGINE InnoDB,
  CHARSET utf8mb4,
  COLLATE utf8mb4_0900_ai_ci;
```

📋 **Plan**: **2** tables to create, **2** vschema updates


**Options**: ⏸️ Defer Cutover | ⏩ Skip Revert

---

**Applying automatically**

</details>

<details>
<summary><a name="apply-started"></a><strong>Apply Started</strong></summary>


## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

Schema changes are being applied. This comment will be updated with progress.

</details>

<details>
<summary><a name="apply-blocked-by-other-pr"></a><strong>Apply Blocked By Other PR</strong></summary>


## 🔒 Apply Blocked — Staging

**Database**: `testapp`

*Requested by @jackjackbits at 2026-01-01 00:00:00 UTC*

Another PR currently holds the lock for this database.

**Locked by**: [block/myapp#42](https://github.com/block/myapp/pull/42)
**Since**: 2026-03-15 12:30:00 UTC

Wait for the other PR to complete or ask the lock holder to run `schemabot unlock`.
<!-- schemabot:offer-support-channel -->

</details>

<details>
<summary><a name="apply-blocked-by-cli"></a><strong>Apply Blocked By CLI</strong></summary>


## 🔒 Apply Blocked — Staging

**Database**: `testapp`

*Requested by @jackjackbits at 2026-01-01 00:00:00 UTC*

A CLI session currently holds the lock for this database.

**Locked by**: `cli:jackjackbits@macbook.local`
**Since**: 2026-03-15 14:00:00 UTC

Ask the lock holder to run `schemabot unlock` from their CLI, or force-unlock with:
```
schemabot unlock -d testapp --force
```
<!-- schemabot:offer-support-channel -->

</details>

<details>
<summary><a name="apply-blocked-already-in-progress"></a><strong>Apply Blocked: Already In Progress</strong></summary>


## ⚠️ Apply Already In Progress — Staging

**Database**: `testapp`

*Requested by @jackjackbits at 2026-01-01 00:00:00 UTC*

An apply is already running for this PR (apply ID: `apply-a1b2c3d4e5f6`, state: `running`).

Wait for it to complete or stop it first.

</details>

<details>
<summary><a name="apply-blocked-pr-closed"></a><strong>Apply Blocked: PR Closed</strong></summary>


## ⛔ Apply Blocked: PR Is Closed — Staging


*Requested by @jackjackbits at 2026-01-01 00:00:00 UTC*

This PR is closed, so its schema changes can never merge. SchemaBot only applies schema changes from open PRs.

Reopen this PR, or open a new PR with the schema change, and apply from there.
<!-- schemabot:offer-support-channel -->

</details>

<details>
<summary><a name="apply-blocked-pr-merged"></a><strong>Apply Blocked: PR Merged</strong></summary>


## ⛔ Apply Blocked: PR Is Merged — Staging


*Requested by @jackjackbits at 2026-01-01 00:00:00 UTC*

This PR is already merged, so applies can no longer run from it. SchemaBot only applies schema changes from open PRs.

If the schema change still needs to be applied, open a new PR with it and apply from there.

</details>

<details>
<summary><a name="apply-blocked-base-schema-changed-since-pr-diverged"></a><strong>Apply Blocked: Base Schema Changed Since PR Diverged</strong></summary>


## ⚠️ Apply rejected — base schema is newer — Production

**Database**: `testapp`

The base branch contains newer changes to the schema directory `schema/testapp` that are not included in this PR. Applying this branch could revert those changes.

Merge or rebase the current base branch into this PR, review the updated plan, then run `apply` again.

_Requested by @jackjackbits_

</details>

<details>
<summary><a name="apply-blocked-schema-stale-new-commits"></a><strong>Apply Blocked: Schema Stale (New Commits)</strong></summary>


## ⚠️ Rejected — new commits since discovery — Staging

**Database**: `testapp`

Schema files were loaded at `0123456789abcdef0123456789abcdef01234567`, but the current PR HEAD is `abcdef1234567890abcdef1234567890abcdef12`. These files no longer match what is on the branch.

Re-run the command to use the current HEAD:

```
schemabot apply -e staging
```

_Requested by @jackjackbits_

</details>

<details>
<summary><a name="apply-blocked-confirmed-plan-stale"></a><strong>Apply Blocked: Confirmed Plan Stale</strong></summary>


## ⚠️ Rejected — the plan you confirmed is stale — Staging

**Database**: `testapp`

The confirmation plan was rendered at `0123456789abcdef0123456789abcdef01234567`, but the current PR HEAD is `abcdef1234567890abcdef1234567890abcdef12`. New commits have landed since the plan was posted, so the DDL you reviewed no longer matches what is on the branch.

Re-run `apply` to generate a fresh plan against the current HEAD:

```
schemabot apply -e staging
```

_Requested by @jackjackbits_

</details>

<details>
<summary><a name="apply-blocked-by-prior-env-pending"></a><strong>Apply Blocked By Prior Env (Pending)</strong></summary>


## ❌ Apply Blocked — Production

**Database**: `testapp`

Staging has pending changes. Apply staging first before applying to production.

```
schemabot apply -e staging
```
<!-- schemabot:offer-support-channel -->

</details>

<details>
<summary><a name="apply-blocked-by-prior-env-failed"></a><strong>Apply Blocked By Prior Env (Failed)</strong></summary>


## ❌ Apply Blocked — Production

**Database**: `testapp`

Staging failed. Fix the issue and re-apply staging before applying to production.

```
schemabot apply -e staging
```
<!-- schemabot:offer-support-channel -->

</details>

<details>
<summary><a name="apply-blocked-by-prior-env-in-progress"></a><strong>Apply Blocked By Prior Env (In Progress)</strong></summary>


## ⏳ Apply Blocked — Production

**Database**: `testapp`

Staging is currently in progress. Wait for it to complete before applying to production.

Once staging completes, retry:
```
schemabot apply -e production
```
<!-- schemabot:offer-support-channel -->

</details>

<details>
<summary><a name="apply-blocked-prior-env-check-missing"></a><strong>Apply Blocked: Prior Env Check Missing</strong></summary>


## ❌ Apply Blocked

SchemaBot could not find a completed `staging` check for this PR.

SchemaBot must verify `staging` before applying a later environment. Create the missing `staging` status with:
```
schemabot plan -e staging
```

If the plan finds changes, apply `staging` and wait for the SchemaBot check to succeed. Then retry this apply.
<!-- schemabot:offer-support-channel -->

</details>

<details>
<summary><a name="apply-blocked-prior-env-check-read-error"></a><strong>Apply Blocked: Prior Env Check Read Error</strong></summary>


## ❌ Apply Blocked

Could not verify staging status: failed to query check runs. Retry the apply command.

_See server logs for details._
<!-- schemabot:offer-support-channel -->

</details>

<details>
<summary><a name="apply-blocked-prior-env-check-untrusted"></a><strong>Apply Blocked: Prior Env Check Untrusted</strong></summary>


## ❌ Apply Blocked

A `staging` check named `SchemaBot (staging)` exists on this PR, but it was created by a GitHub App this SchemaBot deployment does not trust:

- `acme-automation`

SchemaBot only verifies `staging` through check runs created by trusted SchemaBot deployment Apps.

### Next steps
- If the App above is the SchemaBot deployment that owns `staging`, an operator must add its slug to `github.trusted-check-app-slugs` in this deployment's server config.
- If you do not recognize the App, do not trust it — the check may be impersonating SchemaBot.

Re-running `schemabot plan -e staging` will not resolve this.
<!-- schemabot:offer-support-channel -->

</details>

<details>
<summary><a name="apply-blocked-environment-not-in-promotion-order"></a><strong>Apply Blocked: Environment Not In Promotion Order</strong></summary>


## ❌ Apply Blocked — Development

`development` is not in the configured promotion order, so SchemaBot cannot determine which environments must be applied before it and cannot enforce staging-first ordering.

Configured promotion order: `staging` → `production`

Add `development` to `environment_order` (the server-wide list, or this database's override when it has one) so SchemaBot knows where it sits in the promotion sequence, then retry the apply.
<!-- schemabot:offer-support-channel -->

</details>

<details>
<summary><a name="apply-blocked-review-required"></a><strong>Apply Blocked: Review Required</strong></summary>


## Review Required

**Database**: `testapp` | **Environment**: `staging`

*Requested by @jackjackbits at 2026-01-01 00:00:00 UTC*

Schema changes require approval from an authorized reviewer before applying.

**Authorized reviewers**:
- @acme/schema-reviewers
- @jdoe

### Next steps
1. Request a review from an authorized reviewer above
2. Once approved, run `schemabot apply -e staging` again

</details>

<details>
<summary><a name="apply-blocked-review-gate-error-failclosed"></a><strong>Apply Blocked: Review Gate Error (Fail-closed)</strong></summary>


## ❌ Apply Failed

**Environment**: `staging`

*Requested by @jackjackbits at  UTC*

### Error

> Review gate check failed; see server logs for details. If approval is granted through a GitHub team, verify the GitHub App can read organization members and team membership.
<!-- schemabot:offer-support-channel -->

</details>

<details>
<summary><a name="apply-blocked-checks-not-passing"></a><strong>Apply Blocked: Checks Not Passing</strong></summary>


## ❌ Apply Blocked — Staging

Cannot apply while PR checks are not passing:

| Check | Status |
|-------|--------|
| `CI / unit-tests` | failure |
| `CI / lint` | timed_out |

Get the checks passing — fix failures and re-run cancelled or stale checks — then retry:
```
schemabot apply -e staging
```
<!-- schemabot:offer-support-channel -->

</details>

<details>
<summary><a name="apply-blocked-checks-in-progress"></a><strong>Apply Blocked: Checks In Progress</strong></summary>


## ⏳ Apply Blocked — Staging

Cannot apply while PR checks are still running:

| Check | Status |
|-------|--------|
| `CI / unit-tests` | in_progress |
| `CI / integration-tests` | queued |

Wait for checks to complete and retry:
```
schemabot apply -e staging
```
<!-- schemabot:offer-support-channel -->

</details>

<details>
<summary><a name="apply-blocked-check-status-read-error"></a><strong>Apply Blocked: Check Status Read Error</strong></summary>


## ❌ Apply Blocked — Staging

The SchemaBot GitHub App `schemabot-app` cannot read PR check statuses for this repository.

The diagnostic REST probes indicate the installation is missing or has not accepted:
- **Checks: Read**
- **Commit statuses: Read**

Grant or accept those permissions, then retry:
```
schemabot apply -e staging
```

</details>

<details>
<summary><a name="apply-blocked-actor-not-authorized"></a><strong>Apply Blocked: Actor Not Authorized</strong></summary>


## SchemaBot Command Not Authorized

**Database**: `orders` | **Environment**: `staging`

@mona is not authorized to run `schemabot apply` for this database.

A configured SchemaBot admin/database operator must run this command.
<!-- schemabot:offer-support-channel -->

</details>

<details>
<summary><a name="actor-authorization-unavailable"></a><strong>Actor Authorization: Unavailable</strong></summary>


## SchemaBot Authorization Check Failed

**Database**: `orders` | **Environment**: `production`
**Requested by**: @mona

SchemaBot could not verify authorization for `schemabot apply-confirm`. No schema change was started.

If access is granted through a GitHub team, verify the GitHub App can read organization members and team membership.

A configured SchemaBot admin/database operator should inspect SchemaBot authorization logs before retrying.
<!-- schemabot:offer-support-channel -->

</details>

<details>
<summary><a name="actor-authorization-database-not-configured"></a><strong>Actor Authorization: Database Not Configured</strong></summary>


## SchemaBot Command Not Authorized

**Database**: `payments`

`schemabot unlock` cannot run because database `payments` is not configured on this SchemaBot instance.

Verify the database name, or run the command against the SchemaBot instance that manages this database.
<!-- schemabot:offer-support-channel -->

</details>

<details>
<summary><a name="single-table-running"></a><strong>Single Table: Running</strong></summary>


## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: In Progress

**`users`**: 🟦🟦🟦🟦🟦🟦🟦🟦🟦⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ 48%

```sql
ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);
```
Rows: 3,500,000 / 7,200,000 · ETA: 5m 30s


---

To stop this schema change:
```
schemabot stop apply-a1b2c3d4e5f6 -e staging
```

_Last updated: <relative-time datetime="2026-01-01T00:00:00Z">2026-01-01 00:00:00 UTC</relative-time> (2026-01-01 00:00:00 UTC)_

</details>

<details>
<summary><a name="single-table-running-volume-tuned"></a><strong>Single Table: Running (Volume Tuned)</strong></summary>


## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: In Progress | Volume: 8/11

**`users`**: 🟦🟦🟦🟦🟦🟦🟦🟦🟦⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ 48%

```sql
ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);
```
Rows: 3,500,000 / 7,200,000 · ETA: 5m 30s


---

To stop this schema change:
```
schemabot stop apply-a1b2c3d4e5f6 -e staging
```

_Last updated: <relative-time datetime="2026-01-01T00:00:00Z">2026-01-01 00:00:00 UTC</relative-time> (2026-01-01 00:00:00 UTC)_

</details>

<details>
<summary><a name="single-table-completed"></a><strong>Single Table: Completed</strong></summary>


## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: Applied

**`users`**: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Complete

```sql
ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);
```


</details>

<details>
<summary><a name="single-table-failed"></a><strong>Single Table: Failed</strong></summary>


## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: Failed
<!-- schemabot:offer-support-channel -->

**`users`**: 🟥⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ ❌ Failed

```sql
ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);
```


> ⚠️ **Error:** lock wait timeout exceeded; try restarting transaction

---

To retry:
```
schemabot apply -e staging
```

</details>

<details>
<summary><a name="single-table-stopped"></a><strong>Single Table: Stopped</strong></summary>


## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: Stopped

**`users`**: 🟧🟧🟧🟧🟧🟧🟧⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ ⏹️ Stopped at 39%

```sql
ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);
```
Rows: 156,342 / 397,453


---

Paused — to resume from where it stopped:
```
schemabot start apply-a1b2c3d4e5f6 -e staging
```

</details>

<details>
<summary><a name="all-pending"></a><strong>All Pending</strong></summary>


## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: In Progress

📊 3 queued

**Schema `testapp`**

**`orders`**: ⏳ Queued

```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`users`**: ⏳ Queued

```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```

**`products`**: ⏳ Queued

```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```


---

To stop this schema change:
```
schemabot stop apply-a1b2c3d4e5f6 -e staging
```

_Last updated: <relative-time datetime="2026-01-01T00:00:00Z">2026-01-01 00:00:00 UTC</relative-time> (2026-01-01 00:00:00 UTC)_

</details>

<details>
<summary><a name="first-table-running"></a><strong>First Table Running</strong></summary>


## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: In Progress

📊 1 running (22%) · 2 queued

**Schema `testapp`**

**`orders`**: 🟦🟦🟦🟦⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ 22%

```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```
Rows: 321,450 / 1,466,232 · ETA: 5m 40s

**`users`**: ⏳ Queued

```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```

**`products`**: ⏳ Queued

```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```


---

To stop this schema change:
```
schemabot stop apply-a1b2c3d4e5f6 -e staging
```

_Last updated: <relative-time datetime="2026-01-01T00:00:00Z">2026-01-01 00:00:00 UTC</relative-time> (2026-01-01 00:00:00 UTC)_

</details>

<details>
<summary><a name="second-table-running"></a><strong>Second Table Running</strong></summary>


## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: In Progress

📊 1/3 complete · 1 running (62%) · 1 queued

**Schema `testapp`**

**`users`**: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦⬜⬜⬜⬜⬜⬜⬜⬜ 62%

```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```
Rows: 914,707 / 1,466,232 · ETA: 3m 15s

**`products`**: ⏳ Queued

```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```

**`orders`**: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Complete

```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```


---

To stop this schema change:
```
schemabot stop apply-a1b2c3d4e5f6 -e staging
```

_Last updated: <relative-time datetime="2026-01-01T00:00:00Z">2026-01-01 00:00:00 UTC</relative-time> (2026-01-01 00:00:00 UTC)_

</details>

<details>
<summary><a name="second-table-estimate-exceeded"></a><strong>Second Table Estimate Exceeded</strong></summary>


## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: In Progress

📊 1/3 complete · 1 running (finalizing copy) · 1 queued

**Schema `testapp`**

**`users`**: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦 Finalizing copy

```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```
- Rows copied: 145,000,000 so far
- ℹ️ _More rows than initially estimated, copying is still active and will continue_

**`products`**: ⏳ Queued

```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```

**`orders`**: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Complete

```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```


---

To stop this schema change:
```
schemabot stop apply-a1b2c3d4e5f6 -e staging
```

_Last updated: <relative-time datetime="2026-01-01T00:00:00Z">2026-01-01 00:00:00 UTC</relative-time> (2026-01-01 00:00:00 UTC)_

</details>

<details>
<summary><a name="second-table-checksumming"></a><strong>Second Table Checksumming</strong></summary>


## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: In Progress

📊 1/3 complete · 1 checksumming · 1 queued

**Schema `testapp`**

**`users`**: 🟦🟦🟦🟦⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ 🔍 Checksumming to verify data (21%)

```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```
Rows verified: 321,450 / 1,466,232

**`products`**: ⏳ Queued

```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```

**`orders`**: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Complete

```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```


---

To stop this schema change:
```
schemabot stop apply-a1b2c3d4e5f6 -e staging
```

_Last updated: <relative-time datetime="2026-01-01T00:00:00Z">2026-01-01 00:00:00 UTC</relative-time> (2026-01-01 00:00:00 UTC)_

</details>

<details>
<summary><a name="third-table-running"></a><strong>Third Table Running</strong></summary>


## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: In Progress

📊 2/3 complete · 1 running (17%)

**Schema `testapp`**

**`products`**: 🟦🟦🟦⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ 17%

```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```
Rows: 87,231 / 523,140 · ETA: 7m 0s

**`orders`**: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Complete

```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`users`**: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Complete

```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```


---

To stop this schema change:
```
schemabot stop apply-a1b2c3d4e5f6 -e staging
```

_Last updated: <relative-time datetime="2026-01-01T00:00:00Z">2026-01-01 00:00:00 UTC</relative-time> (2026-01-01 00:00:00 UTC)_

</details>

<details>
<summary><a name="sharded-shard-progress"></a><strong>Sharded: Shard Progress</strong></summary>


## Schema Change Status — Staging

**Database**: `commerce` | **Apply ID**: `apply-7aa13cf03496454b`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: In Progress

**Schema `commerce`**

**`users`**: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦⬜⬜⬜⬜⬜⬜⬜⬜ 62%

```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```
Rows: 914,707 / 1,466,232 · ETA: 3m 15s
  └ shards: ✓ -40 · ◐ 40-80 62% · ◐ 80-c0 31% · ⏳ c0-


---

To stop this schema change:
```
schemabot stop apply-7aa13cf03496454b -e staging
```

_Last updated: <relative-time datetime="2026-01-01T00:00:00Z">2026-01-01 00:00:00 UTC</relative-time> (2026-01-01 00:00:00 UTC)_

</details>

<details>
<summary><a name="sharded-many-shards-256"></a><strong>Sharded: Many Shards (256)</strong></summary>


## Schema Change Status — Staging

**Database**: `commerce` | **Apply ID**: `apply-7aa13cf03496454b`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: In Progress

**Schema `commerce`**

**`orders`**: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦⬜⬜⬜⬜⬜⬜ 70%

```sql
ALTER TABLE `orders` ADD COLUMN `region` varchar(32);
```
Rows: 4,200,000,000 / 6,000,000,000 · ETA: 1h 30m
  └ 256 shards: 200 ✓ · 52 ◐ copying · 4 ⏳ · slowest f7- 12%


---

To stop this schema change:
```
schemabot stop apply-7aa13cf03496454b -e staging
```

_Last updated: <relative-time datetime="2026-01-01T00:00:00Z">2026-01-01 00:00:00 UTC</relative-time> (2026-01-01 00:00:00 UTC)_

</details>

<details>
<summary><a name="all-completed"></a><strong>All Completed</strong></summary>


## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: Applied

📊 3/3 complete

**Schema `testapp`**

**`orders`**: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Complete

```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`users`**: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Complete

```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```

**`products`**: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Complete

```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```


</details>

<details>
<summary><a name="vitess-vschema-only"></a><strong>Vitess: VSchema Only</strong></summary>


## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: In Progress

### VSchema

**`myapp_sharded`**: Applying...

```diff
+ "xxhash": {"type": "xxhash"}
```


---

To cancel this schema change:
```
schemabot cancel apply-a1b2c3d4e5f6 -e staging
```

_Last updated: <relative-time datetime="2026-01-01T00:00:00Z">2026-01-01 00:00:00 UTC</relative-time> (2026-01-01 00:00:00 UTC)_

</details>

<details>
<summary><a name="vitess-ddl--vschema"></a><strong>Vitess: DDL + VSchema</strong></summary>


## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: In Progress

Deploy request: https://app.planetscale.com/acme/myapp/deploy-requests/42

**`users`**: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Complete

```sql
ALTER TABLE `users` ADD COLUMN `phone` varchar(20);
```


### VSchema

**`myapp_sharded`**: Applying...

```diff
+ "xxhash": {"type": "xxhash"}
```


---

To cancel this schema change:
```
schemabot cancel apply-a1b2c3d4e5f6 -e staging
```

_Last updated: <relative-time datetime="2026-01-01T00:00:00Z">2026-01-01 00:00:00 UTC</relative-time> (2026-01-01 00:00:00 UTC)_

</details>

<details>
<summary><a name="vitess-multikeyspace-vschema"></a><strong>Vitess: Multi-keyspace VSchema</strong></summary>


## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: In Progress

### VSchema

**`commerce`**: Applied

```diff
+ "lookup_orders": {"type": "lookup_hash"}
```

**`commerce_sharded`**: Applying...

```diff
+ "xxhash": {"type": "xxhash"}
```


---

To cancel this schema change:
```
schemabot cancel apply-a1b2c3d4e5f6 -e staging
```

_Last updated: <relative-time datetime="2026-01-01T00:00:00Z">2026-01-01 00:00:00 UTC</relative-time> (2026-01-01 00:00:00 UTC)_

</details>

<details>
<summary><a name="middle-table-retrying"></a><strong>Middle Table Retrying</strong></summary>


## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: Retrying

📊 1/3 complete · 1 queued · 1 retrying

**Schema `testapp`**

**`users`**: 🟧🟧🟧🟧🟧🟧⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ 🔄 Interrupted — retrying automatically (attempt 2/10)

```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```
> ⚠️ Last error: lock wait timeout exceeded; try restarting transaction

**`products`**: ⏳ Queued

```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```

**`orders`**: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Complete

```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```


---

An error interrupted this schema change. SchemaBot retries automatically and marks it failed if retries are exhausted. To stop retrying:
```
schemabot stop apply-a1b2c3d4e5f6 -e staging
```

_Last updated: <relative-time datetime="2026-01-01T00:00:00Z">2026-01-01 00:00:00 UTC</relative-time> (2026-01-01 00:00:00 UTC)_

</details>

<details>
<summary><a name="first-table-failed"></a><strong>First Table Failed</strong></summary>


## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: Failed
<!-- schemabot:offer-support-channel -->

📊 1 failed · 2 cancelled

**Schema `testapp`**

**`orders`**: 🟥⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ ❌ Failed

```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`users`**: ⊘ Cancelled (not started)

```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```

**`products`**: ⊘ Cancelled (not started)

```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```


> ⚠️ **Error:** Error 1061: Duplicate key name 'idx_user_id'

---

To retry:
```
schemabot apply -e staging
```

</details>

<details>
<summary><a name="middle-table-failed"></a><strong>Middle Table Failed</strong></summary>


## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: Failed
<!-- schemabot:offer-support-channel -->

📊 1/3 complete · 1 failed · 1 cancelled

**Schema `testapp`**

**`users`**: 🟥🟥🟥🟥🟥🟥⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ ❌ Failed

```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```

**`orders`**: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Complete

```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`products`**: ⊘ Cancelled (not started)

```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```


> ⚠️ **Error:** lock wait timeout exceeded; try restarting transaction

---

To retry:
```
schemabot apply -e staging
```

</details>

<details>
<summary><a name="failed-before-row-copy-preflight"></a><strong>Failed Before Row Copy (Preflight)</strong></summary>


## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: Failed
<!-- schemabot:offer-support-channel -->

📊 1 failed · 2 cancelled

**Schema `testapp`**

**`orders`**: ❌ Failed (before row copy started)

```sql
ALTER TABLE `orders` MODIFY COLUMN `status` enum('NEW','PENDING','SHIPPED','DELIVERED') NOT NULL;
```
> ⚠️ Last error: preflight enumReorder check failed: reordering existing ENUM values on column `status` is unsafe: retained values must keep their relative order and new values must be appended at the end

**`users`**: ⊘ Cancelled (not started)

```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```

**`products`**: ⊘ Cancelled (not started)

```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```


> ⚠️ **Error:** table orders failed: preflight enumReorder check failed: reordering existing ENUM values on column `status` is unsafe: retained values must keep their relative order and new values must be appended at the end

---

To retry:
```
schemabot apply -e staging
```

</details>

<details>
<summary><a name="stopped"></a><strong>Stopped</strong></summary>


## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: Stopped

📊 1/2 complete · 1 stopped

**Schema `testapp`**

**`users`**: 🟧🟧🟧🟧🟧🟧🟧🟧🟧🟧🟧🟧🟧🟧⬜⬜⬜⬜⬜⬜ ⏹️ Stopped at 72%

```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```
Rows: 1,055,687 / 1,466,232

**`orders`**: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Complete

```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```


---

Paused — to resume from where it stopped:
```
schemabot start apply-a1b2c3d4e5f6 -e staging
```

</details>

<details>
<summary><a name="resuming"></a><strong>Resuming</strong></summary>


## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: Resuming

**Schema `testapp`**

**`users`**: 🔄 Resuming…

```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```

**`orders`**: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Complete

```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```


_Last updated: <relative-time datetime="2026-01-01T00:00:00Z">2026-01-01 00:00:00 UTC</relative-time> (2026-01-01 00:00:00 UTC)_

</details>

<details>
<summary><a name="cancelled"></a><strong>Cancelled</strong></summary>


## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: Cancelled

📊 1/2 complete · 1 cancelled

**Schema `testapp`**

**`orders`**: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Complete

```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`users`**: ⊘ Cancelled (not started)

```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```


---

This schema change was cancelled and cannot be resumed. Open a new schema change to apply it again.

</details>

<details>
<summary><a name="waiting-for-cutover"></a><strong>Waiting For Cutover</strong></summary>


## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: Waiting for Cutover

**3/3** table(s) ready for cutover

📊 3 ready for cutover

**Schema `testapp`**

**`orders`**: 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 ✅ Ready for cutover

```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`users`**: 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 ✅ Ready for cutover

```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```

**`products`**: 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 ✅ Ready for cutover

```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```


---

To proceed with cutover:
```
schemabot cutover apply-a1b2c3d4e5f6 -e staging
```

_Last updated: <relative-time datetime="2026-01-01T00:00:00Z">2026-01-01 00:00:00 UTC</relative-time> (2026-01-01 00:00:00 UTC)_

</details>

<details>
<summary><a name="waiting-for-cutover-automatic"></a><strong>Waiting For Cutover (Automatic)</strong></summary>


## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: Waiting for Cutover

**3/3** table(s) ready for cutover

📊 3 ready for cutover

**Schema `testapp`**

**`orders`**: 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 ✅ Ready for cutover

```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`users`**: 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 ✅ Ready for cutover

```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```

**`products`**: 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 ✅ Ready for cutover

```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```


---

SchemaBot triggers cutover automatically — no action needed.

_Last updated: <relative-time datetime="2026-01-01T00:00:00Z">2026-01-01 00:00:00 UTC</relative-time> (2026-01-01 00:00:00 UTC)_

</details>

<details>
<summary><a name="cutting-over"></a><strong>Cutting Over</strong></summary>


## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: Cutting Over

📊 3 cutting over

**Schema `testapp`**

**`orders`**: 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 🔄 Cutting over...

```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`users`**: 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 🔄 Cutting over...

```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```

**`products`**: 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 🔄 Cutting over...

```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```


---

Cutover in progress — typically completes within seconds.

_Last updated: <relative-time datetime="2026-01-01T00:00:00Z">2026-01-01 00:00:00 UTC</relative-time> (2026-01-01 00:00:00 UTC)_

</details>

<details>
<summary><a name="revert-window"></a><strong>Revert Window</strong></summary>


## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: Revert Window | Closes in 28m 30s

Deploy request: https://app.planetscale.com/acme/myapp/deploy-requests/42

**Keyspace `testapp`**

**`orders`**: 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 Complete (revert window open)

```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`users`**: 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 Complete (revert window open)

```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```

**`products`**: 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 Complete (revert window open)

```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```


---

To skip revert and keep changes:
```
schemabot skip-revert apply-a1b2c3d4e5f6 -e staging
```

To revert:
```
schemabot revert apply-a1b2c3d4e5f6 -e staging
```

_Last updated: <relative-time datetime="2026-01-01T00:00:00Z">2026-01-01 00:00:00 UTC</relative-time> (2026-01-01 00:00:00 UTC)_

</details>

<details>
<summary><a name="skipping-revert"></a><strong>Skipping Revert</strong></summary>


## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: Skipping revert

Deploy request: https://app.planetscale.com/acme/myapp/deploy-requests/42

**Keyspace `testapp`**

**`orders`**: 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 Complete (revert window open)

```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`users`**: 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 Complete (revert window open)

```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```

**`products`**: 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 Complete (revert window open)

```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```


---

Skip-revert was requested — closing the revert window and making this schema change permanent. This can no longer be reverted.

_Last updated: <relative-time datetime="2026-01-01T00:00:00Z">2026-01-01 00:00:00 UTC</relative-time> (2026-01-01 00:00:00 UTC)_

</details>

<details>
<summary><a name="reverting"></a><strong>Reverting</strong></summary>


## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: Reverting

Deploy request: https://app.planetscale.com/acme/myapp/deploy-requests/42

**Keyspace `testapp`**

**`orders`**: 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 ↩️ Reverting

```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`users`**: 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 ↩️ Reverting

```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```

**`products`**: 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 ↩️ Reverting

```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```


_Last updated: <relative-time datetime="2026-01-01T00:00:00Z">2026-01-01 00:00:00 UTC</relative-time> (2026-01-01 00:00:00 UTC)_

</details>

<details>
<summary><a name="start-command-accepted"></a><strong>Start Command Accepted</strong></summary>


## Start Request Accepted

**Apply**: `apply-a1b2c3d4e5f67890`
**Environment**: `staging`
**Requested by**: @alice

Start request accepted. SchemaBot will resume this schema change; status remains available from the PR progress comment or CLI.

**Tasks selected for start**: 1 started, 0 skipped.

</details>

<details>
<summary><a name="start-command-already-pending"></a><strong>Start Command Already Pending</strong></summary>


## Start Request Accepted

**Apply**: `apply-a1b2c3d4e5f67890`
**Environment**: `staging`
**Requested by**: @alice

Start was already requested. SchemaBot will keep the existing start request pending until the operator owner finishes it.

**Tasks selected for start**: 1 started, 0 skipped.

</details>

<details>
<summary><a name="cutover-command-accepted"></a><strong>Cutover Command Accepted</strong></summary>


## Cutover Request Accepted

**Apply**: `apply-a1b2c3d4e5f67890`
**Environment**: `staging`
**Requested by**: @alice

Cutover request accepted. SchemaBot will complete this schema change; status remains available from the PR progress comment or CLI.

</details>

<details>
<summary><a name="cutover-command-already-in-progress"></a><strong>Cutover Command Already In Progress</strong></summary>


## Cutover Request Accepted

**Apply**: `apply-a1b2c3d4e5f67890`
**Environment**: `staging`
**Requested by**: @alice

Cutover is already in progress. SchemaBot will keep reporting progress from the existing apply.

</details>

<details>
<summary><a name="volume-command-accepted"></a><strong>Volume Command Accepted</strong></summary>


## Volume Request Accepted

**Apply**: `apply-a1b2c3d4e5f67890`
**Environment**: `staging`
**Requested by**: @alice

Volume change to 8 requested. SchemaBot will adjust the speed of this schema change shortly; once the new level takes effect, a fresh progress comment will track the schema change at the new volume.

</details>

<details>
<summary><a name="volume-command-invalid-level"></a><strong>Volume Command Invalid Level</strong></summary>


## Missing or Invalid Volume Level

Usage: `schemabot volume <apply-id> -e <environment> -v <level>`

The `-v` flag is required and must be a number between 1 (slowest) and 11 (fastest).
<!-- schemabot:offer-support-channel -->

</details>

<details>
<summary><a name="volume-command-missing-apply-id"></a><strong>Volume Command Missing Apply ID</strong></summary>


## Missing Apply ID

Usage: `schemabot volume <apply-id> -e <environment> -v <1-11>`

Use `schemabot status -e <environment>` to find the apply ID.
<!-- schemabot:offer-support-channel -->

</details>

<details>
<summary><a name="volume-changed-superseded-progress-comment"></a><strong>Volume Changed: Superseded Progress Comment</strong></summary>


⏩ Volume changed to **8/11** — progress continues in [a new progress comment](https://github.com/acme/testapp/pull/42#issuecomment-2222222222).

<details>
<summary>Progress before the volume change</summary>

## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: In Progress | Volume: 3/11

**`users`**: 🟦🟦🟦🟦🟦🟦⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ 32%

```sql
ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);
```
Rows: 2,300,000 / 7,200,000 · ETA: 13m 0s


---

To stop this schema change:
```
schemabot stop apply-a1b2c3d4e5f6 -e staging
```

_Last updated: <relative-time datetime="2026-01-01T00:00:00Z">2026-01-01 00:00:00 UTC</relative-time> (2026-01-01 00:00:00 UTC)_


</details>

</details>

<details>
<summary><a name="resumed-superseded-progress-comment"></a><strong>Resumed: Superseded Progress Comment</strong></summary>


▶️ Schema change resumed — progress continues in [a new progress comment](https://github.com/acme/testapp/pull/42#issuecomment-2222222222).

<details>
<summary>Progress before the stop</summary>

## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: Stopped

**`users`**: 🟧🟧🟧🟧🟧🟧⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ ⏹️ Stopped at 32%

```sql
ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);
```
Rows: 2,300,000 / 7,200,000


---

Paused — to resume from where it stopped:
```
schemabot start apply-a1b2c3d4e5f6 -e staging
```


</details>

</details>

<details>
<summary><a name="revert-superseded-progress-comment"></a><strong>Revert: Superseded Progress Comment</strong></summary>


Schema change reverting — the revert is tracked in [a new progress comment](https://github.com/acme/testapp/pull/42#issuecomment-2222222222).

<details>
<summary>Progress before the revert</summary>

## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: Revert Window

**`users`**: 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 Complete (revert window open)

```sql
ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);
```


---

To skip revert and keep changes:
```
schemabot skip-revert apply-a1b2c3d4e5f6 -e staging
```

To revert:
```
schemabot revert apply-a1b2c3d4e5f6 -e staging
```

_Last updated: <relative-time datetime="2026-01-01T00:00:00Z">2026-01-01 00:00:00 UTC</relative-time> (2026-01-01 00:00:00 UTC)_


</details>

</details>

<details>
<summary><a name="skip-revert-superseded-progress-comment"></a><strong>Skip Revert: Superseded Progress Comment</strong></summary>


Revert skipped — the schema change is finalizing in [a new progress comment](https://github.com/acme/testapp/pull/42#issuecomment-2222222222).

<details>
<summary>Progress before the revert was skipped</summary>

## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: Revert Window

**`users`**: 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 Complete (revert window open)

```sql
ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);
```


---

To skip revert and keep changes:
```
schemabot skip-revert apply-a1b2c3d4e5f6 -e staging
```

To revert:
```
schemabot revert apply-a1b2c3d4e5f6 -e staging
```

_Last updated: <relative-time datetime="2026-01-01T00:00:00Z">2026-01-01 00:00:00 UTC</relative-time> (2026-01-01 00:00:00 UTC)_


</details>

</details>

<details>
<summary><a name="cutover-complete-superseded-cutover-prompt"></a><strong>Cutover Complete: Superseded Cutover Prompt</strong></summary>


Cutover complete — progress continues in [a new progress comment](https://github.com/acme/testapp/pull/42#issuecomment-2222222222).

<details>
<summary>Cutover prompt</summary>

## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: Waiting for Cutover

**0/1** table(s) ready for cutover — waiting on 1

**`users`**: 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 Waiting for cutover

```sql
ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);
```


---

SchemaBot triggers cutover automatically — no action needed.

_Last updated: <relative-time datetime="2026-01-01T00:00:00Z">2026-01-01 00:00:00 UTC</relative-time> (2026-01-01 00:00:00 UTC)_


</details>

</details>

<details>
<summary><a name="retry-superseded-progress-comment-generic"></a><strong>Retry: Superseded Progress Comment (Generic)</strong></summary>


⏭️ Progress comment superseded — progress continues in [a new progress comment](https://github.com/acme/testapp/pull/42#issuecomment-2222222222).

<details>
<summary>Earlier progress</summary>

## Schema Change Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: Stopped

**`users`**: 🟧🟧🟧🟧🟧🟧⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ ⏹️ Stopped at 32%

```sql
ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);
```
Rows: 2,300,000 / 7,200,000


---

Paused — to resume from where it stopped:
```
schemabot start apply-a1b2c3d4e5f6 -e staging
```


</details>

</details>

<details>
<summary><a name="summary-completed"></a><strong>Summary: Completed</strong></summary>


## ✅ Schema Change Applied — Staging

**Database**: `testapp`


> Applied successfully — your schema changes are live!

<details><summary>Apply details (3 tables)</summary>

_Apply ID: `apply-a1b2c3d4e5f6`_


**`orders`**
```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`users`**
```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```

**`products`**
```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```

</details>

</details>

<details>
<summary><a name="summary-failed"></a><strong>Summary: Failed</strong></summary>


## ❌ Schema Change Failed — Staging

<!-- schemabot:offer-support-channel -->
**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6` | **Duration**: 8m

*Applied by @jackjackbits at 2026-03-15 14:22:00 UTC*

> ⚠️ **Error:** table users failed: schema change failed: unsafe warning: Field 'name' doesn't have a default value

1 of 3 tables completed before failure.

**`users`** — Failed at 30%
```sql
ALTER TABLE `users`
    DROP COLUMN `full_name`,
    MODIFY COLUMN `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
    ADD COLUMN `name` varchar(255) NOT NULL AFTER `id`,
    MODIFY COLUMN `created_at` datetime NOT NULL DEFAULT current_timestamp(),
    DROP INDEX `idx_created_at`,
    DROP INDEX `idx_email`,
    DROP INDEX `idx_full_name`,
    ADD UNIQUE `idx_email`(`email`);
```

**`orders`**
```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`products`** — Cancelled
```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```


---

To retry:
```
schemabot apply -e staging
```

<details>
<summary>Show logs (5 entries)</summary>

```text
2026-03-15 14:22:00 UTC [INF] Apply claimed by driver [queued -> running]
2026-03-15 14:22:15 UTC [INF] Task started: schema change on `users`
2026-03-15 14:25:00 UTC [WRN] Copy throttled by replication lag (1.2s)
2026-03-15 14:28:00 UTC [ERR] Task failed: unsafe warning: Field 'name' doesn't have a default value
2026-03-15 14:29:00 UTC [ERR] Apply failed [running -> failed]
```

</details>

</details>

<details>
<summary><a name="summary-stopped"></a><strong>Summary: Stopped</strong></summary>


## ⏹️ Schema Change Stopped — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6` | **Duration**: 45m

*Applied by @jackjackbits at 2026-03-15 13:45:00 UTC*

1 of 2 tables completed before stop.

**`users`** — Stopped at 72%
```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```

**`orders`**
```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```


---

Paused — to resume from where it stopped:
```
schemabot start apply-a1b2c3d4e5f6 -e staging
```

</details>

<details>
<summary><a name="summary-cancelled"></a><strong>Summary: Cancelled</strong></summary>


## 🚫 Schema Change Cancelled — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6` | **Duration**: 45m

*Applied by @jackjackbits at 2026-03-15 13:45:00 UTC*

1 of 2 tables completed before cancellation.

**`orders`**
```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`users`** — Cancelled
```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```


---

This schema change was cancelled and cannot be resumed. Open a new schema change to apply it again.

</details>

<details>
<summary><a name="summary-completed-large"></a><strong>Summary: Completed (Large)</strong></summary>


## ✅ Schema Change Applied — Staging

**Database**: `testapp`


> Applied successfully — your schema changes are live!

<details><summary>Apply details (8 tables)</summary>

_Apply ID: `apply-a1b2c3d4e5f6`_


**`orders`**
```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`users`**
```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```

**`products`**
```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```

**`payments`**
```sql
ALTER TABLE `payments` ADD INDEX `idx_order_id`(`order_id`);
```

**`addresses`**
```sql
ALTER TABLE `addresses` ADD INDEX `idx_user_id`(`user_id`);
```

**`sessions`**
```sql
ALTER TABLE `sessions` ADD INDEX `idx_expires_at`(`expires_at`);
```

**`audit_logs`**
```sql
ALTER TABLE `audit_logs` ADD INDEX `idx_created_at`(`created_at`);
```

**`notifications`**
```sql
ALTER TABLE `notifications` ADD INDEX `idx_user_status`(`user_id`, `status`);
```

</details>

</details>

<details>
<summary><a name="summary-vitess-ddl--vschema"></a><strong>Summary: Vitess DDL + VSchema</strong></summary>


## ✅ Schema Change Applied — Staging

**Database**: `testapp`


> Applied successfully — your schema changes are live!

<details><summary>Apply details (1 table, 1 VSchema update)</summary>

_Apply ID: `apply-a1b2c3d4e5f6`_

Applied by namespace:

- `testapp`: 1 table
- `myapp_sharded`: 1 VSchema update


**`users`**
```sql
ALTER TABLE `users` ADD COLUMN `phone` varchar(20);
```


### VSchema

**`myapp_sharded`**: Applied

```diff
+ "xxhash": {"type": "xxhash"}
```

</details>

</details>

<details>
<summary><a name="summary-vitess-vschema-only"></a><strong>Summary: Vitess VSchema Only</strong></summary>


## ✅ Schema Change Applied — Staging

**Database**: `testapp`


> Applied successfully — your schema change is live!

<details><summary>Apply details (1 VSchema update)</summary>

_Apply ID: `apply-a1b2c3d4e5f6`_


### VSchema

**`myapp_sharded`**: Applied

```diff
+ "xxhash": {"type": "xxhash"}
```

</details>

</details>

<details>
<summary><a name="summary-failed-large"></a><strong>Summary: Failed (Large)</strong></summary>


## ❌ Schema Change Failed — Staging

<!-- schemabot:offer-support-channel -->
**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6` | **Duration**: 3h 30m

*Applied by @jackjackbits at 2026-03-15 11:00:00 UTC*

> ⚠️ **Error:** Error 1062: Duplicate entry '12345' for key 'addresses.idx_user_id'

4 of 8 tables completed before failure.

**`addresses`** — Failed at 45%
```sql
ALTER TABLE `addresses` ADD INDEX `idx_user_id`(`user_id`);
```

**`orders`**
```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`users`**
```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```

**`products`**
```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```

**`payments`**
```sql
ALTER TABLE `payments` ADD INDEX `idx_order_id`(`order_id`);
```

**`sessions`** — Cancelled
```sql
ALTER TABLE `sessions` ADD INDEX `idx_expires_at`(`expires_at`);
```

**`audit_logs`** — Cancelled
```sql
ALTER TABLE `audit_logs` ADD INDEX `idx_created_at`(`created_at`);
```

**`notifications`** — Cancelled
```sql
ALTER TABLE `notifications` ADD INDEX `idx_user_status`(`user_id`, `status`);
```


---

To retry:
```
schemabot apply -e staging
```

<details>
<summary>Show logs (5 entries)</summary>

```text
2026-03-15 14:22:00 UTC [INF] Apply claimed by driver [queued -> running]
2026-03-15 14:22:15 UTC [INF] Task started: schema change on `addresses`
2026-03-15 14:25:00 UTC [WRN] Copy throttled by replication lag (1.2s)
2026-03-15 14:28:00 UTC [ERR] Task failed: Error 1062: Duplicate entry '12345' for key 'addresses.idx_user_id'
2026-03-15 14:29:00 UTC [ERR] Apply failed [running -> failed]
```

</details>

</details>

<details>
<summary><a name="summary-multinamespace-failed"></a><strong>Summary: Multi-namespace Failed</strong></summary>


## ❌ Schema Change Failed — Staging

<!-- schemabot:offer-support-channel -->
**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6` | **Duration**: 8m

*Applied by @jackjackbits at 2026-03-15 14:22:00 UTC*

> ⚠️ **Error:** table customers.addresses failed: Error 1205: Lock wait timeout exceeded

3 of 5 tables completed before failure.

### ❌ customers

**`addresses`** — Failed at 60%
```sql
ALTER TABLE `addresses` ADD INDEX `idx_zip`(`zip_code`);
```

**`users`**
```sql
ALTER TABLE `users` ADD COLUMN `phone` varchar(20);
```


### ✅ commerce

**`orders`**
```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`payments`**
```sql
ALTER TABLE `payments` ADD INDEX `idx_order_id`(`order_id`);
```


### ⊘ analytics

**`events`** — Cancelled
```sql
ALTER TABLE `events` ADD INDEX `idx_created_at`(`created_at`);
```


---

To retry:
```
schemabot apply -e staging
```

<details>
<summary>Show logs (5 entries)</summary>

```text
2026-03-15 14:22:00 UTC [INF] Apply claimed by driver [queued -> running]
2026-03-15 14:22:15 UTC [INF] Task started: schema change on `addresses`
2026-03-15 14:25:00 UTC [WRN] Copy throttled by replication lag (1.2s)
2026-03-15 14:28:00 UTC [ERR] Task failed: Error 1205: Lock wait timeout exceeded
2026-03-15 14:29:00 UTC [ERR] Apply failed [running -> failed]
```

</details>

</details>

<details>
<summary><a name="summary-multinamespace-completed"></a><strong>Summary: Multi-namespace Completed</strong></summary>


## ✅ Schema Change Applied — Staging

**Database**: `testapp`


> Applied successfully — your schema changes are live!

<details><summary>Apply details (5 tables)</summary>

_Apply ID: `apply-a1b2c3d4e5f6`_

Applied by namespace:

- `commerce`: 2 tables
- `customers`: 2 tables
- `analytics`: 1 table


### commerce

**`orders`**
```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`payments`**
```sql
ALTER TABLE `payments` ADD INDEX `idx_order_id`(`order_id`);
```


### customers

**`users`**
```sql
ALTER TABLE `users` ADD COLUMN `phone` varchar(20);
```

**`addresses`**
```sql
ALTER TABLE `addresses` ADD INDEX `idx_zip`(`zip_code`);
```


### analytics

**`events`**
```sql
ALTER TABLE `events` ADD INDEX `idx_created_at`(`created_at`);
```

</details>

</details>

<details>
<summary><a name="rollback-status-running"></a><strong>Rollback Status: Running</strong></summary>


## Rollback Status — Staging

**Database**: `testapp` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Status**: In Progress

**Schema `testapp`**

**`users`**: 🟦🟦🟦🟦🟦🟦🟦🟦🟦⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ 45%

```sql
ALTER TABLE `users` DROP INDEX `idx_email`;
```
Rows: 45,000 / 100,000


---

To stop this schema change:
```
schemabot stop apply-a1b2c3d4e5f6 -e staging
```

_Last updated: <relative-time datetime="2026-01-01T00:00:00Z">2026-01-01 00:00:00 UTC</relative-time> (2026-01-01 00:00:00 UTC)_

</details>

<details>
<summary><a name="summary-rollback-complete"></a><strong>Summary: Rollback Complete</strong></summary>


## ⏪ Rollback Complete — Staging

**Database**: `testapp`


> Rolled back successfully — the schema change has been reverted.

<details><summary>Apply details (1 table)</summary>

_Apply ID: `apply-a1b2c3d4e5f6`_


**`users`**
```sql
ALTER TABLE `users` DROP INDEX `idx_email`;
```

</details>

</details>

<details>
<summary><a name="rollback-plan-directexecution-change"></a><strong>Rollback Plan (Direct-execution Change)</strong></summary>


## Schema Rollback Plan — Staging

**Database**: `testapp` | **Type**: `MySQL`

*Requested by @jackjackbits at 2026-01-01 00:00:00 UTC*

```sql
ALTER TABLE `users`
    DROP PRIMARY KEY,
    ADD PRIMARY KEY(`id`);
```

⚙️ **Direct execution**: **1** change will run as native MySQL DDL
- `users`: dropping primary key is not supported; runs as native MySQL DDL on a table with ~1,240 rows

These statements run synchronously outside the schema-change engine: writes to each table are blocked while its statement runs, the change is **not revertible**, and `--defer-cutover` does not apply to it. Confirming the rollback consents to this.

> **Warning**: Rollback may include destructive changes (e.g., DROP INDEX, DROP COLUMN). These will be applied automatically.

📋 **Plan**: **1** table to alter

---

To confirm this rollback, comment:
```
schemabot rollback-confirm -e staging
```

To cancel, comment:
```
schemabot unlock
```

</details>

<details>
<summary><a name="rollback-rejected-engineblocked-changes"></a><strong>Rollback Rejected (Engine-blocked Changes)</strong></summary>


## Schema Rollback Plan — Staging

**Database**: `testapp` | **Type**: `MySQL`

*Requested by @jackjackbits at 2026-01-01 00:00:00 UTC*

```sql
ALTER TABLE `users`
    DROP PRIMARY KEY,
    ADD PRIMARY KEY(`id`);
```

📋 **Plan**: **1** table to alter

---

**⛔ Rollback rejected**: **1** planned change not supported by the schema-change engine
- `users`: dropping primary key is not supported; direct execution is enabled but the table has ~2,400,000 rows, above the configured limit of 1,000,000

Reconcile the target schema with a follow-up schema change PR instead, or contact your SchemaBot operators for help.
</details>

### CLI Output

<details>
<summary><a name="mysql-single-table-running"></a><strong>MySQL: Single Table Running</strong></summary>

```

Single table progress (default):

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Running              │
│  Started:   Jan 15 14:25:00 UTC  │
│  Duration:  5m                   │
└──────────────────────────────────┘


  ── testapp ──

     ~ users: 🟦🟦🟦🟦🟦🟦🟦🟦🟦⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ 48%
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);
       • Rows: 3,500,000 / 7,200,000 · ETA: 5m 30s


```
</details>

<details>
<summary><a name="mysql-single-table-completed"></a><strong>MySQL: Single Table Completed</strong></summary>

```

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Completed            │
│  Started:   Jan 15 14:18:00 UTC  │
│  Duration:  11m 30s              │
└──────────────────────────────────┘


  ── testapp ──

     ~ order_items: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `order_items` ADD INDEX `idx_product_id`(`product_id`);

     ~ users: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);

✓ Apply complete!

```
</details>

<details>
<summary><a name="mysql-single-table-failed"></a><strong>MySQL: Single Table Failed</strong></summary>

```

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Failed               │
│  Started:   Jan 15 14:22:00 UTC  │
│  Duration:  7m 50s               │
└──────────────────────────────────┘

  lock wait timeout exceeded; try restarting transaction


  ── testapp ──

     ~ users: ⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ ❌ Failed
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);


To recover: Fix the issue above, then run a new apply.
The new apply will only process tables that haven't completed.

```
</details>

<details>
<summary><a name="mysql-single-table-stopped"></a><strong>MySQL: Single Table Stopped</strong></summary>

```

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Stopped              │
│  Started:   Jan 15 14:27:00 UTC  │
│  Duration:  3m                   │
└──────────────────────────────────┘


  ── testapp ──

     ~ users: 🟧🟧🟧🟧🟧🟧🟧⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ ⏹️ Stopped at 39%
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);
       • Rows: 156,342 / 397,453

     ~ orders: ⏹️ Stopped (not started)
       ALTER TABLE `orders` ADD INDEX `idx_total_cents`(`total_cents`);


Stopped. Use 'schemabot start -e staging <apply_id>' to resume from checkpoint.

```
</details>

<details>
<summary><a name="mysql-single-table-waiting-for-cutover"></a><strong>MySQL: Single Table Waiting For Cutover</strong></summary>

```

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Waiting for cutover  │
│  Started:   Jan 15 14:20:00 UTC  │
│  Duration:  10m                  │
└──────────────────────────────────┘


  ── testapp ──

     ~ order_items: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦 Waiting for cutover
       ALTER TABLE `order_items` ADD INDEX `idx_product_id`(`product_id`);

     ~ users: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦 Waiting for cutover
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);

Row copy complete. All data has been copied and new writes
continue to be replicated to keep the shadow table in sync.

Press Enter to proceed with cutover (or Ctrl+C to detach): _

```
</details>

<details>
<summary><a name="if-detached-user-sees"></a><strong>If Detached, User Sees:</strong></summary>

```

Row copy complete. All data has been copied and new writes
continue to be replicated to keep the shadow table in sync.

To proceed: schemabot cutover -e staging <apply_id>
Watching for cutover... (Ctrl+C to detach)

```
</details>

<details>
<summary><a name="mysql-single-table-cutting-over"></a><strong>MySQL: Single Table Cutting Over</strong></summary>

```

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Cutting over         │
│  Started:   Jan 15 14:18:00 UTC  │
│  Duration:  12m                  │
└──────────────────────────────────┘


  ── testapp ──

     ~ order_items: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦 Cutting over...
       ALTER TABLE `order_items` ADD INDEX `idx_product_id`(`product_id`);

     ~ users: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦 Cutting over...
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);


```
</details>

<details>
<summary><a name="mysql-multitable-all-pending"></a><strong>MySQL: Multi-table All Pending</strong></summary>

```

Sequential mode: Just started (all tables pending)

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Pending              │
│  Started:   Jan 15 14:29:50 UTC  │
│  Duration:  10s                  │
└──────────────────────────────────┘


```
</details>

<details>
<summary><a name="mysql-multitable-first-table-running"></a><strong>MySQL: Multi-table First Table Running</strong></summary>

```

Sequential mode: First table running, others queued

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Running              │
│  Started:   Jan 15 14:25:00 UTC  │
│  Duration:  5m                   │
└──────────────────────────────────┘


     ~ users: 🟦🟦🟦🟦🟦🟦🟦⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ 35%
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);
       • Rows: 875,000 / 2,500,000 · ETA: 8m 30s

     ~ orders: ⏳ Queued
       ALTER TABLE `orders` ADD INDEX `idx_user_status`(`user_id`, `status`);

     ~ products: ⏳ Queued
       ALTER TABLE `products` ADD COLUMN `weight_grams` int DEFAULT 0;


```
</details>

<details>
<summary><a name="mysql-multitable-second-table-running"></a><strong>MySQL: Multi-table Second Table Running</strong></summary>

```

Sequential mode: First complete, second running

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Running              │
│  Started:   Jan 15 14:18:00 UTC  │
│  Duration:  12m                  │
└──────────────────────────────────┘


     ~ orders: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦⬜⬜⬜⬜⬜⬜⬜⬜ 60%
       ALTER TABLE `orders` ADD INDEX `idx_user_status`(`user_id`, `status`);
       • Rows: 3,000,000 / 5,000,000 · ETA: 12m 15s

     ~ products: ⏳ Queued
       ALTER TABLE `products` ADD COLUMN `weight_grams` int DEFAULT 0;

     ~ users: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);


```
</details>

<details>
<summary><a name="mysql-multitable-second-table-checksumming"></a><strong>MySQL: Multi-table Second Table Checksumming</strong></summary>

```

Sequential mode: First complete, second checksumming

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Running              │
│  Started:   Jan 15 14:05:00 UTC  │
│  Duration:  25m                  │
└──────────────────────────────────┘


     ~ orders: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦⬜⬜⬜⬜⬜⬜⬜⬜ 🔍 Checksumming to verify data (60%)
       ALTER TABLE `orders` ADD INDEX `idx_user_status`(`user_id`, `status`);
       • Rows verified: 3,000,000 / 5,000,000

     ~ products: ⏳ Queued
       ALTER TABLE `products` ADD COLUMN `weight_grams` int DEFAULT 0;

     ~ users: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);


```
</details>

<details>
<summary><a name="mysql-multitable-third-table-running"></a><strong>MySQL: Multi-table Third Table Running</strong></summary>

```

Sequential mode: First two complete, third running

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Running              │
│  Started:   Jan 15 14:10:00 UTC  │
│  Duration:  20m                  │
└──────────────────────────────────┘


     ~ products: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦⬜⬜⬜⬜ 80%
       ALTER TABLE `products` ADD COLUMN `weight_grams` int DEFAULT 0;
       • Rows: 160,000 / 200,000 · ETA: 2m 45s

     ~ users: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);

     ~ orders: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `orders` ADD INDEX `idx_user_status`(`user_id`, `status`);


```
</details>

<details>
<summary><a name="mysql-multitable-all-completed"></a><strong>MySQL: Multi-table All Completed</strong></summary>

```

Sequential mode: All tables completed successfully

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Completed            │
│  Started:   Jan 15 14:05:00 UTC  │
│  Duration:  24m 30s              │
└──────────────────────────────────┘


     ~ users: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);

     ~ orders: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `orders` ADD INDEX `idx_user_status`(`user_id`, `status`);

     ~ products: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `products` ADD COLUMN `weight_grams` int DEFAULT 0;

✓ Apply complete!

```
</details>

<details>
<summary><a name="mysql-multitable-first-table-failed"></a><strong>MySQL: Multi-table First Table Failed</strong></summary>

```

Sequential mode: First table failed (others cancelled)

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Failed               │
│  Started:   Jan 15 14:22:00 UTC  │
│  Duration:  7m 30s               │
└──────────────────────────────────┘

  lock wait timeout exceeded; try restarting transaction


     ~ users: 🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥⬜⬜⬜⬜⬜⬜⬜ ❌ Failed
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);

     ~ orders: ⊘ Cancelled (not started)
       ALTER TABLE `orders` ADD INDEX `idx_user_status`(`user_id`, `status`);

     ~ products: ⊘ Cancelled (not started)
       ALTER TABLE `products` ADD COLUMN `weight_grams` int DEFAULT 0;


To recover: Fix the issue above, then run a new apply.
The new apply will only process tables that haven't completed.

```
</details>

<details>
<summary><a name="mysql-multitable-middle-table-failed"></a><strong>MySQL: Multi-table Middle Table Failed</strong></summary>

```

Sequential mode: Middle table failed

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Failed               │
│  Started:   Jan 15 14:12:00 UTC  │
│  Duration:  17m 30s              │
└──────────────────────────────────┘

  Lost connection to MySQL server during query (MySQL error 2013)


     ~ orders: 🟥🟥🟥🟥🟥🟥🟥🟥🟥⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ ❌ Failed
       ALTER TABLE `orders` ADD INDEX `idx_user_status`(`user_id`, `status`);

     ~ users: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);

     ~ products: ⊘ Cancelled (not started)
       ALTER TABLE `products` ADD COLUMN `weight_grams` int DEFAULT 0;


To recover: Fix the issue above, then run a new apply.
The new apply will only process tables that haven't completed.

```
</details>

<details>
<summary><a name="mysql-multitable-stopped"></a><strong>MySQL: Multi-table Stopped</strong></summary>

```

Sequential mode: User stopped mid-apply

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Stopped              │
│  Started:   Jan 15 14:25:00 UTC  │
│  Duration:  5m                   │
└──────────────────────────────────┘


     ~ orders: 🟧🟧🟧🟧🟧🟧🟧🟧⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ ⏹️ Stopped at 42%
       ALTER TABLE `orders` ADD INDEX `idx_user_status`(`user_id`, `status`);
       • Rows: 112,045 / 266,383

     ~ products: ⏹️ Stopped (not started)
       ALTER TABLE `products` ADD COLUMN `weight_grams` int DEFAULT 0;

     ~ users: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);

Use 'schemabot start' to resume from checkpoint.

```
</details>

<details>
<summary><a name="vitess-preparing-branch"></a><strong>Vitess: Preparing Branch</strong></summary>

```

┌────────────────────────────────────┐
│  Apply ID:     apply-a1b2c3d4e5f6  │
│  Database:     myapp               │
│  Environment:  staging             │
│  State:        Preparing branch    │
└────────────────────────────────────┘


```
</details>

<details>
<summary><a name="vitess-refreshing-branch-branch"></a><strong>Vitess: Refreshing Branch (--branch)</strong></summary>

```

┌──────────────────────────────────────────┐
│  Apply ID:     apply-b7c8d9e0f1a2        │
│  Database:     myapp                     │
│  Environment:  staging                   │
│  State:        Refreshing branch schema  │
└──────────────────────────────────────────┘


```
</details>

<details>
<summary><a name="vitess-applying-branch-changes"></a><strong>Vitess: Applying Branch Changes</strong></summary>

```

┌───────────────────────────────────────────────────────────┐
│  Apply ID:     apply-a1b2c3d4e5f6                         │
│  Database:     myapp                                      │
│  Environment:  staging                                    │
│  State:        Applied keyspace myapp_sharded_003 (8/12)  │
└───────────────────────────────────────────────────────────┘


```
</details>

<details>
<summary><a name="vitess-validating-branch"></a><strong>Vitess: Validating Branch</strong></summary>

```

┌────────────────────────────────────┐
│  Apply ID:     apply-a1b2c3d4e5f6  │
│  Database:     myapp               │
│  Environment:  staging             │
│  State:        Validating branch   │
└────────────────────────────────────┘


```
</details>

<details>
<summary><a name="vitess-creating-deploy-request"></a><strong>Vitess: Creating Deploy Request</strong></summary>

```

┌─────────────────────────────────────────┐
│  Apply ID:     apply-a1b2c3d4e5f6       │
│  Database:     myapp                    │
│  Environment:  staging                  │
│  State:        Creating deploy request  │
└─────────────────────────────────────────┘


```
</details>

<details>
<summary><a name="vitess-validating-deploy-request"></a><strong>Vitess: Validating Deploy Request</strong></summary>

```

┌────────────────────────────────────────────────────────────────────────────────┐
│  Apply ID:        apply-a1b2c3d4e5f6                                           │
│  Database:        myapp                                                        │
│  Environment:     staging                                                      │
│  State:           Validating deploy request                                    │
│  Deploy Request:  https://app.planetscale.com/my-org/myapp/deploy-requests/42  │
└────────────────────────────────────────────────────────────────────────────────┘


```
</details>

<details>
<summary><a name="vitess-staging-schema-changes-0-with-shards"></a><strong>Vitess: Staging Schema Changes (0% With Shards)</strong></summary>

```

┌─────────────────────────────────────┐
│  Apply ID:     apply-a1b2c3d4e5f6   │
│  Database:     myapp                │
│  Environment:  staging              │
│  State:        Running              │
│  Started:      Jan 15 14:29:15 UTC  │
│  Duration:     45s                  │
└─────────────────────────────────────┘


  ── myapp_sharded ──

     ~ customers: ⏳ Starting copy...
       ALTER TABLE `customers` ADD INDEX `idx_created_at`(`created_at`);
       • Rows: 0 / 124,760,460
       • Shards: 2 (2 copying)
           ◉ -80: 0% (0/60,483,380 rows)
           ◉ 80-: 0% (0/64,277,080 rows)

```
</details>

<details>
<summary><a name="vitess-running"></a><strong>Vitess: Running</strong></summary>

```

┌────────────────────────────────────────────────────────────────────────────────┐
│  Apply ID:        apply-a1b2c3d4e5f6                                           │
│  Database:        myapp                                                        │
│  Environment:     staging                                                      │
│  State:           Running                                                      │
│  Deploy Request:  https://app.planetscale.com/my-org/myapp/deploy-requests/42  │
│  Started:         Jan 15 14:29:30 UTC                                          │
│  Duration:        30s                                                          │
└────────────────────────────────────────────────────────────────────────────────┘


  ── myapp_sharded ──

     ~ users: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦 Running...
       ALTER TABLE `users` ADD COLUMN `phone` varchar(20);


```
</details>

<details>
<summary><a name="vitess-completed"></a><strong>Vitess: Completed</strong></summary>

```

┌────────────────────────────────────────────────────────────────────────────────┐
│  Apply ID:        apply-a1b2c3d4e5f6                                           │
│  Database:        myapp                                                        │
│  Environment:     staging                                                      │
│  State:           Completed                                                    │
│  Deploy Request:  https://app.planetscale.com/my-org/myapp/deploy-requests/42  │
│  Started:         Jan 15 14:28:30 UTC                                          │
│  Duration:        1m 30s                                                       │
└────────────────────────────────────────────────────────────────────────────────┘


  ── myapp_sharded ──

     ~ users: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `users` ADD COLUMN `phone` varchar(20);


```
</details>

<details>
<summary><a name="vitess-multikeyspace-completed-watch"></a><strong>Vitess: Multi-keyspace Completed Watch</strong></summary>

```

┌───────────────────────────────────────────────────────────────────────────────────┐
│  Apply ID:        apply-19b23a035ad54ffb                                          │
│  Database:        commerce                                                        │
│  Environment:     production                                                      │
│  State:           Completed                                                       │
│  Deploy Request:  https://app.planetscale.com/my-org/commerce/deploy-requests/86  │
│  Started:         Jan 15 14:28:00 UTC                                             │
│  Duration:        2m                                                              │
└───────────────────────────────────────────────────────────────────────────────────┘


  ── commerce_sharded ──

     ~ events: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `events` ADD COLUMN `source_region_id` int(11) NULL AFTER `account_id`;


  ── commerce_sharded_006 ──

     ~ events: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `events` ADD COLUMN `source_region_id` int(11) NULL AFTER `account_id`;

✓ Apply complete!

```
</details>

<details>
<summary><a name="vitess-failed"></a><strong>Vitess: Failed</strong></summary>

```

┌────────────────────────────────────────────────────────────────────────────────┐
│  Apply ID:        apply-a1b2c3d4e5f6                                           │
│  Database:        myapp                                                        │
│  Environment:     staging                                                      │
│  State:           Failed                                                       │
│  Deploy Request:  https://app.planetscale.com/my-org/myapp/deploy-requests/42  │
│  Started:         Jan 15 14:29:00 UTC                                          │
│  Duration:        1m                                                           │
└────────────────────────────────────────────────────────────────────────────────┘

  deploy request #42 failed during preparation (state: error)
  [INVALID_VSCHEMA] vschema_error: table users has a changed column vindex (keyspace: myapp_sharded, table: users)


  ── myapp_sharded ──

     ~ users: ⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ ❌ Failed
       ALTER TABLE `users` ADD COLUMN `phone` varchar(20);


To recover: Fix the issue above, then run a new apply.
The new apply will only process tables that haven't completed.

```
</details>

<details>
<summary><a name="vitess-waiting-for-deploy"></a><strong>Vitess: Waiting For Deploy</strong></summary>

```

┌────────────────────────────────────────────────────────────────────────────────┐
│  Apply ID:        apply-a1b2c3d4e5f6                                           │
│  Database:        myapp                                                        │
│  Environment:     production                                                   │
│  State:           Waiting for deploy                                           │
│  Options:         ⏸️ Defer Deploy                                              │
│  Deploy Request:  https://app.planetscale.com/my-org/myapp/deploy-requests/50  │
│  Started:         Jan 15 14:29:30 UTC                                          │
│  Duration:        30s                                                          │
└────────────────────────────────────────────────────────────────────────────────┘


Deploy request created: https://app.planetscale.com/my-org/myapp/deploy-requests/50
⚡ This change will be applied using instant mode.

Press Enter to deploy or proceed via the PlanetScale console (ESC to detach)

```
</details>

<details>
<summary><a name="vitess-waiting-for-cutover"></a><strong>Vitess: Waiting For Cutover</strong></summary>

```

┌────────────────────────────────────────────────────────────────────────────────┐
│  Apply ID:        apply-a1b2c3d4e5f6                                           │
│  Database:        myapp                                                        │
│  Environment:     production                                                   │
│  State:           Waiting for cutover                                          │
│  Options:         ⏸️ Defer Cutover                                             │
│  Deploy Request:  https://app.planetscale.com/my-org/myapp/deploy-requests/49  │
│  Started:         Jan 15 14:27:00 UTC                                          │
│  Duration:        3m                                                           │
└────────────────────────────────────────────────────────────────────────────────┘


  ── myapp_sharded ──

     ~ orders: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦 Waiting for cutover
       ALTER TABLE `orders` ADD INDEX `idx_total`(`total_cents`);

       • Shards: 2 (2 ready for cutover)
           ● -80: ready for cutover
           ● 80-: ready for cutover

```
</details>

<details>
<summary><a name="vitess-cutting-over"></a><strong>Vitess: Cutting Over</strong></summary>

```

┌────────────────────────────────────────────────────────────────────────────────┐
│  Apply ID:        apply-a1b2c3d4e5f6                                           │
│  Database:        myapp                                                        │
│  Environment:     production                                                   │
│  State:           Cutting over                                                 │
│  Options:         ⏸️ Defer Cutover                                             │
│  Deploy Request:  https://app.planetscale.com/my-org/myapp/deploy-requests/49  │
│  Started:         Jan 15 14:26:00 UTC                                          │
│  Duration:        4m                                                           │
└────────────────────────────────────────────────────────────────────────────────┘


  ── myapp_sharded ──

     ~ orders: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦 Cutting over...
       ALTER TABLE `orders` ADD INDEX `idx_total`(`total_cents`);

       • Shards: 2 (2 cutting over)
           ● -80: cutting over
           ● 80-: cutting over

```
</details>

<details>
<summary><a name="vitess-cancelled"></a><strong>Vitess: Cancelled</strong></summary>

```

┌────────────────────────────────────────────────────────────────────────────────┐
│  Apply ID:        apply-a1b2c3d4e5f6                                           │
│  Database:        myapp                                                        │
│  Environment:     staging                                                      │
│  State:           Cancelled                                                    │
│  Deploy Request:  https://app.planetscale.com/my-org/myapp/deploy-requests/50  │
│  Started:         Jan 15 14:28:00 UTC                                          │
│  Duration:        2m                                                           │
└────────────────────────────────────────────────────────────────────────────────┘


  ── myapp_sharded ──

     ~ orders: 🟥🟥🟥🟥🟥🟥⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ ⊘ Cancelled at 30%
       ALTER TABLE `orders` ADD INDEX `idx_total`(`total_cents`);

       • Shards: 2 (2 cancelled)
           ○ -80: cancelled
           ○ 80-: cancelled

```
</details>

<details>
<summary><a name="vitess-large-shard-count-256-shards"></a><strong>Vitess: Large Shard Count (256 Shards)</strong></summary>

```

┌───────────────────────────────────────────────────────────────────────────────────┐
│  Apply ID:        apply-a1b2c3d4e5f6                                              │
│  Database:        commerce                                                        │
│  Environment:     production                                                      │
│  State:           Running                                                         │
│  Deploy Request:  https://app.planetscale.com/my-org/commerce/deploy-requests/28  │
│  Started:         Jan 15 14:18:00 UTC                                             │
│  Duration:        12m                                                             │
└───────────────────────────────────────────────────────────────────────────────────┘


  ── commerce_sharded ──

     ~ transactions: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦⬜⬜⬜⬜⬜⬜⬜⬜⬜ 57%
       ALTER TABLE `transactions` ADD COLUMN `region_id` int;
       • Rows: 110,573,340 / 193,280,000 · ETA: 4m 40s
       • Shards: 256 (30 ready for cutover, 226 copying)
           ● -01: ready for cutover
           ● 01-02: ready for cutover
           ● 02-03: ready for cutover
           ... 27 more ready for cutover
           ◉ ff-: 10% (101,000/1,010,000 rows) ETA 4m 40s
           ◉ fe-ff: 10% (100,800/1,008,000 rows) ETA 4m 40s
           ◉ fd-fe: 11% (110,660/1,006,000 rows) ETA 4m 38s
           ◉ fc-fd: 11% (110,440/1,004,000 rows) ETA 4m 38s
           ◉ fb-fc: 12% (120,240/1,002,000 rows) ETA 4m 36s
           ... 221 more copying shards

```
</details>

<details>
<summary><a name="vitess-many-keyspaces-33-keyspaces"></a><strong>Vitess: Many Keyspaces (33 Keyspaces)</strong></summary>

```

┌───────────────────────────────────────────────────────────────────────────────────┐
│  Apply ID:        apply-a1b2c3d4e5f6                                              │
│  Database:        commerce                                                        │
│  Environment:     production                                                      │
│  State:           Running                                                         │
│  Deploy Request:  https://app.planetscale.com/my-org/commerce/deploy-requests/29  │
│  Started:         Jan 15 14:22:00 UTC                                             │
│  Duration:        8m                                                              │
└───────────────────────────────────────────────────────────────────────────────────┘


  ── commerce_sharded ──

     ~ transactions: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦⬜⬜⬜⬜⬜⬜⬜ 67%
       ALTER TABLE `transactions` ADD COLUMN `region_id` int;
       • Rows: 29,435,000 / 43,360,000 · ETA: 2m 37s
       • Shards: 32 (12 ready for cutover, 20 copying)
           ● -08: ready for cutover
           ● 08-10: ready for cutover
           ● 10-18: ready for cutover
           ... 9 more ready for cutover
           ◉ f8-: 23% (347,300/1,510,000 rows) ETA 2m 37s
           ◉ f0-f8: 26% (390,000/1,500,000 rows) ETA 2m 34s
           ◉ e8-f0: 29% (432,100/1,490,000 rows) ETA 2m 31s
           ◉ e0-e8: 32% (473,600/1,480,000 rows) ETA 2m 28s
           ◉ d8-e0: 35% (514,500/1,470,000 rows) ETA 2m 25s
           ... 15 more copying shards

  ── commerce_001 ──

     ~ transactions: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ⚡ Applied instantly
       ALTER TABLE `transactions` ADD COLUMN `region_id` int;


  ── commerce_002 ──

     ~ transactions: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ⚡ Applied instantly
       ALTER TABLE `transactions` ADD COLUMN `region_id` int;


  ── commerce_003 ──

     ~ transactions: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ⚡ Applied instantly
       ALTER TABLE `transactions` ADD COLUMN `region_id` int;


  ── commerce_004 ──

     ~ transactions: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ⚡ Applied instantly
       ALTER TABLE `transactions` ADD COLUMN `region_id` int;


  ── commerce_005 ──

     ~ transactions: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ⚡ Applied instantly
       ALTER TABLE `transactions` ADD COLUMN `region_id` int;


  ... and 27 more keyspaces (all completed)

```
</details>

<details>
<summary><a name="vitess-vschema-only-update"></a><strong>Vitess: VSchema Only Update</strong></summary>

```

┌────────────────────────────────────────────────────────────────────────────────┐
│  Apply ID:        apply-a1b2c3d4e5f6                                           │
│  Database:        myapp                                                        │
│  Environment:     staging                                                      │
│  State:           Running                                                      │
│  Deploy Request:  https://app.planetscale.com/my-org/myapp/deploy-requests/43  │
│  Started:         Jan 15 14:29:50 UTC                                          │
│  Duration:        10s                                                          │
└────────────────────────────────────────────────────────────────────────────────┘

    ~ VSchema (myapp_sharded): Applying...
       + "xxhash": {"type": "xxhash"}


```
</details>

<details>
<summary><a name="vitess-multikeyspace-vschema"></a><strong>Vitess: Multi-keyspace VSchema</strong></summary>

```

┌────────────────────────────────────────────────────────────────────────────────┐
│  Apply ID:        apply-a1b2c3d4e5f6                                           │
│  Database:        myapp                                                        │
│  Environment:     staging                                                      │
│  State:           Running                                                      │
│  Deploy Request:  https://app.planetscale.com/my-org/myapp/deploy-requests/46  │
│  Started:         Jan 15 14:29:50 UTC                                          │
│  Duration:        10s                                                          │
└────────────────────────────────────────────────────────────────────────────────┘

    ~ VSchema (commerce): Applied
       + "lookup_orders": {"type": "lookup_hash"}
    ~ VSchema (commerce_sharded): Applying...
       + "xxhash": {"type": "xxhash"}


```
</details>

<details>
<summary><a name="vitess-multikeyspace"></a><strong>Vitess: Multi-keyspace</strong></summary>

```

┌────────────────────────────────────────────────────────────────────────────────┐
│  Apply ID:        apply-a1b2c3d4e5f6                                           │
│  Database:        myapp                                                        │
│  Environment:     staging                                                      │
│  State:           Running                                                      │
│  Deploy Request:  https://app.planetscale.com/my-org/myapp/deploy-requests/44  │
│  Started:         Jan 15 14:29:40 UTC                                          │
│  Duration:        20s                                                          │
└────────────────────────────────────────────────────────────────────────────────┘


  ── myapp_unsharded ──

     ~ orders_seq: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦 Running...
       CREATE TABLE `orders_seq` (
           `id` int unsigned NOT NULL DEFAULT '0',
           `next_id` bigint unsigned,
           `cache` bigint unsigned,
           PRIMARY KEY(`id`)
       ) ENGINE InnoDB;


  ── myapp_sharded ──

     ~ users: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `users` ADD COLUMN `phone` varchar(20);


```
</details>

<details>
<summary><a name="vitess-ddl--vschema"></a><strong>Vitess: DDL + VSchema</strong></summary>

```

┌────────────────────────────────────────────────────────────────────────────────┐
│  Apply ID:        apply-a1b2c3d4e5f6                                           │
│  Database:        myapp                                                        │
│  Environment:     staging                                                      │
│  State:           Running                                                      │
│  Deploy Request:  https://app.planetscale.com/my-org/myapp/deploy-requests/45  │
│  Started:         Jan 15 14:29:30 UTC                                          │
│  Duration:        30s                                                          │
└────────────────────────────────────────────────────────────────────────────────┘


  ── myapp_sharded ──

     ~ users: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `users` ADD COLUMN `phone` varchar(20);

    ~ VSchema (myapp_sharded): Applying...
       + "xxhash": {"type": "xxhash"}


```
</details>

<details>
<summary><a name="vitess-shard-progress"></a><strong>Vitess: Shard Progress</strong></summary>

```

┌────────────────────────────────────────────────────────────────────────────────┐
│  Apply ID:        apply-a1b2c3d4e5f6                                           │
│  Database:        myapp                                                        │
│  Environment:     staging                                                      │
│  State:           Running                                                      │
│  Deploy Request:  https://app.planetscale.com/my-org/myapp/deploy-requests/46  │
│  Started:         Jan 15 14:29:15 UTC                                          │
│  Duration:        45s                                                          │
└────────────────────────────────────────────────────────────────────────────────┘


  ── myapp_sharded ──

     ~ orders: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦⬜⬜⬜⬜⬜⬜ 70%
       ALTER TABLE `orders` ADD INDEX `idx_total`(`total_cents`);
       • Rows: 2,800,000 / 4,000,000 · ETA: 2m 0s
       • Shards: 2 (2 copying)
           ◉ -80: 95% (2,000,000/2,100,000 rows) ETA 10s
           ◉ 80-: 42% (800,000/1,900,000 rows) ETA 2m 0s

```
</details>

<details>
<summary><a name="vitess-cutover-retry"></a><strong>Vitess: Cutover Retry</strong></summary>

```

┌────────────────────────────────────────────────────────────────────────────────┐
│  Apply ID:        apply-a1b2c3d4e5f6                                           │
│  Database:        myapp                                                        │
│  Environment:     production                                                   │
│  State:           Running                                                      │
│  Deploy Request:  https://app.planetscale.com/my-org/myapp/deploy-requests/51  │
│  Started:         Jan 15 14:25:00 UTC                                          │
│  Duration:        5m                                                           │
└────────────────────────────────────────────────────────────────────────────────┘


  ── myapp_sharded ──

     ~ orders: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦 Waiting for cutover
       ALTER TABLE `orders` ADD INDEX `idx_total`(`total_cents`);

       • Shards: 2 (2 ready for cutover)
           ● -80: ready for cutover
           ● 80-: ready for cutover

```
</details>

<details>
<summary><a name="vitess-plan-ddl--vschema"></a><strong>Vitess: Plan (DDL + VSchema)</strong></summary>

```

Vitess plan: DDL + VSchema changes in a sharded keyspace
(schemabot plan -s examples/vitess/schema -e staging)

╭─────────────────────────────────────────────╮
│  Vitess Schema Change Plan                  │
│                                             │
│  Database: testapp-vitess                   │
│  Environment: staging                       │
╰─────────────────────────────────────────────╯


  ── testapp_sharded ──

     ~ VSchema:
          },
          "tables": {
            "users": {
       +      "column_vindexes": [
       +        {"column": "id", "name": "hash"}
       +      ]
       +    },
       +    "user_preferences": {
       +      "column_vindexes": [
       +        {"column": "user_id", "name": "hash"}
       +      ]
            }
          }
        }

     + user_preferences
       CREATE TABLE `user_preferences` (
           `id` bigint NOT NULL AUTO_INCREMENT,
           `user_id` bigint NOT NULL,
           `key` varchar(255) NOT NULL,
           `value` text,
           PRIMARY KEY(`id`),
           INDEX `idx_user_id`(`user_id`)
       );

     ~ users
       ALTER TABLE `users` ADD COLUMN `email_verified` tinyint(1) DEFAULT FALSE;

📋 **Plan**: 1 table to create, 1 table to alter, 1 VSchema change


```
</details>

<details>
<summary><a name="vitess-plan-vschema-only"></a><strong>Vitess: Plan (VSchema Only)</strong></summary>

```

Vitess plan: VSchema-only update (no table DDL changes)
(schemabot plan -s examples/vitess/schema -e staging)

╭─────────────────────────────────────────────╮
│  Vitess Schema Change Plan                  │
│                                             │
│  Database: testapp-vitess                   │
│  Environment: staging                       │
╰─────────────────────────────────────────────╯


  ── testapp_sharded ──

     ~ VSchema:
        {
          "sharded": true,
          "vindexes": {
       -    "hash": {"type": "hash"}
       +    "hash": {"type": "hash"},
       +    "lookup_email": {
       +      "type": "consistent_lookup",
       +      "params": {"table": "users_email_idx", "from": "email", "to": "user_id"}
       +    }
          },
          "tables": {

📋 **Plan**: 1 VSchema change


```
</details>

<details>
<summary><a name="vitess-plan-multikeyspace"></a><strong>Vitess: Plan (Multi-keyspace)</strong></summary>

```

Vitess plan: Multi-keyspace with DDL + VSchema across keyspaces
(schemabot plan -s examples/vitess/schema -e staging)

╭─────────────────────────────────────────────╮
│  Vitess Schema Change Plan                  │
│                                             │
│  Database: testapp-vitess                   │
│  Environment: staging                       │
╰─────────────────────────────────────────────╯


  ── testapp ──

     ~ VSchema:
        {
       -  "tables": {}
       +  "tables": {
       +    "users_email_idx": {},
       +    "users_seq": {"type": "sequence"},
       +    "orders_seq": {"type": "sequence"}
       +  }
        }

     + users_email_idx
       CREATE TABLE `users_email_idx` (
           `email` varchar(255) NOT NULL,
           `user_id` bigint NOT NULL,
           PRIMARY KEY(`email`, `user_id`)
       );


  ── testapp_sharded ──

     ~ VSchema:
          "vindexes": {
       -    "hash": {"type": "hash"}
       +    "hash": {"type": "hash"},
       +    "lookup_email": {
       +      "type": "consistent_lookup",
       +      "params": {"table": "users_email_idx", "from": "email", "to": "user_id"}
       +    }
          },

     ~ users
       ALTER TABLE `users` ADD COLUMN `email_verified` tinyint(1) DEFAULT FALSE;

     ~ orders
       ALTER TABLE `orders` ADD INDEX `idx_status_created`(`status`, `created_at`);

📋 **Plan**: 1 table to create, 2 tables to alter, 2 VSchema changes


```
</details>

<details>
<summary><a name="vitess-instant-ddl"></a><strong>Vitess: Instant DDL</strong></summary>

```

┌────────────────────────────────────────────────────────────────────────────────┐
│  Apply ID:        apply-a1b2c3d4e5f6                                           │
│  Database:        myapp                                                        │
│  Environment:     staging                                                      │
│  State:           Completed                                                    │
│  Deploy Request:  https://app.planetscale.com/my-org/myapp/deploy-requests/47  │
│  Started:         Jan 15 14:29:57 UTC                                          │
│  Duration:        3s                                                           │
└────────────────────────────────────────────────────────────────────────────────┘


  ── myapp_sharded ──

     ~ users: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ⚡ Applied instantly
       ALTER TABLE `users` ADD COLUMN `phone` varchar(20);


```
</details>

<details>
<summary><a name="vitess-revert-window"></a><strong>Vitess: Revert Window</strong></summary>

```

┌───────────────────────────────────────────────────────────────────────────────────┐
│  Apply ID:           apply-a1b2c3d4e5f6                                           │
│  Database:           myapp                                                        │
│  Environment:        production                                                   │
│  State:              Revert window                                                │
│  Deploy Request:     https://app.planetscale.com/my-org/myapp/deploy-requests/48  │
│  Started:            Jan 15 14:28:00 UTC                                          │
│  Duration:           30s                                                          │
│  Revert expires in:  28m 29s                                                      │
└───────────────────────────────────────────────────────────────────────────────────┘


  ── myapp_sharded ──

     ~ orders: 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 Complete (revert window open)
       ALTER TABLE `orders` ADD INDEX `idx_total`(`total_cents`);


```
</details>

<details>
<summary><a name="apply-watch-mode"></a><strong>Apply Watch Mode</strong></summary>

```

Apply watch mode: Running with footer controls
(schemabot apply -s ./schema -e staging)

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Running              │
│  Started:   Jan 15 14:22:00 UTC  │
│  Duration:  8m                   │
└──────────────────────────────────┘


  ── testapp ──

     ~ users: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦⬜⬜⬜⬜⬜⬜⬜⬜ 62%
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);
       • Rows: 914,707 / 1,466,232 · ETA: 3m 15s

     ~ products: ⏳ Queued
       ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);

     ~ orders: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);

ESC detach • s stop • v volume

```
</details>

<details>
<summary><a name="after-completion"></a><strong>After Completion:</strong></summary>

```

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Completed            │
│  Started:   Jan 15 14:18:00 UTC  │
│  Duration:  11m 30s              │
└──────────────────────────────────┘


  ── testapp ──

     ~ orders: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);

     ~ products: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);

     ~ users: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);

✓ Apply complete!

```
</details>

<details>
<summary><a name="stop-command"></a><strong>Stop Command</strong></summary>

```

Stop command: User runs 'schemabot stop -e staging <apply_id>'

⏸️  Schema change stopped

Database:    myapp
Environment: staging
Stopped:     2 table(s)
Skipped:     1 table(s) (already complete)

Checkpoint saved. Use 'schemabot start -e staging apply-a1b2c3d4e5f67890' to resume.

```
</details>

<details>
<summary><a name="after-stop-progress-shows"></a><strong>After Stop, Progress Shows:</strong></summary>

```

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Stopped              │
│  Started:   Jan 15 14:22:00 UTC  │
│  Duration:  8m                   │
└──────────────────────────────────┘


  ── testapp ──

     ~ users: 🟧🟧🟧🟧🟧🟧🟧⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ ⏹️ Stopped at 39%
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);
       • Rows: 156,342 / 397,453

     ~ products: ⏹️ Stopped (not started)
       ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);

     ~ orders: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);


```
</details>

<details>
<summary><a name="start-command"></a><strong>Start Command</strong></summary>

```

Start command: User runs 'schemabot start -e staging <apply_id>'

▶️  Schema change resumed

Database:    myapp
Environment: staging
Resumed:     2 table(s)
Skipped:     1 table(s) (already complete)

Resuming from checkpoint...

```
</details>

<details>
<summary><a name="then-progress-resumes"></a><strong>Then Progress Resumes:</strong></summary>

```

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Running              │
│  Started:   Jan 15 14:22:00 UTC  │
│  Duration:  8m                   │
└──────────────────────────────────┘


  ── testapp ──

     ~ users: 🟦🟦🟦🟦🟦🟦🟦🟦⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ 40%
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);
       • Rows: 158,000 / 397,453 · ETA: 8m 0s

     ~ products: ⏳ Queued
       ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);

     ~ orders: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);

ESC detach • s stop • v volume

```
</details>

<details>
<summary><a name="volume-mode"></a><strong>Volume Mode</strong></summary>

```

Volume mode: Interactive volume adjustment
(Press 'v' during apply to enter volume mode)

```
</details>

<details>
<summary><a name="in-volume-mode-default-4"></a><strong>In Volume Mode (Default 4):</strong></summary>

```

Volume: ████░░░░░░░ 4/11
↑↓ adjust • 1-9 direct • ESC done

```
</details>

<details>
<summary><a name="after-adjusting-to-8"></a><strong>After Adjusting To 8:</strong></summary>

```

Volume: ████████░░░ 8/11
↑↓ adjust • 1-9 direct • ESC done

```
</details>

<details>
<summary><a name="after-adjusting-to-2"></a><strong>After Adjusting To 2:</strong></summary>

```

Volume: ██░░░░░░░░░ 2/11
↑↓ adjust • 1-9 direct • ESC done

```
</details>

<details>
<summary><a name="status-list"></a><strong>Status List</strong></summary>

```

3 active schema changes

  APPLY ID      DATABASE   ENV         STATE                STARTED         CALLER
  apply_abc123  orders-db  staging     Running              15 minutes ago  
  apply_def456  users-db   production  Waiting for cutover  45 minutes ago  
  apply_ghi789  analytics  staging     Stopped              2 hours ago     

Use 'schemabot status <apply_id>' to view details

No active applies:

No recent schema changes

```
</details>

<details>
<summary><a name="status-for-deployment"></a><strong>Status For Deployment</strong></summary>

```

1 active schema change

  APPLY ID              EXTERNAL OP ID         DATABASE   ENV         DEPLOYMENT  STATE                STARTED        CALLER
  apply-multi-a1b2c3d4  remote-op-us-east-001  orders-db  production  us-east     Waiting for cutover  8 minutes ago  octocat

Use 'schemabot status <apply_id>' to view details

Multiple matching operations:

1 active schema change

  APPLY ID                EXTERNAL OP ID  DATABASE      ENV         DEPLOYMENT  STATE    STARTED        CALLER
  apply-sharded-d5e6f7g8  -               inventory-db  production  us-east     Running  4 minutes ago  octocat

Use 'schemabot status <apply_id>' to view details

```
</details>

<details>
<summary><a name="status-history"></a><strong>Status History</strong></summary>

```

Schema change history for orders-db

  APPLY ID      ENV         STATE      STARTED         DURATION  CALLER
  apply_abc123  staging     Completed  1 hour ago      15m       cli
  apply_def456  staging     Running    15 minutes ago  15m       PR 42
  apply_ghi789  production  Failed     3 hours ago     30m       PR 42
  apply_jkl012  production  Completed  1 day ago       30m       cli

Use 'schemabot status <apply_id>' to view details

Empty database:

No schema changes found for database 'new-db'
```
</details>


## Multi-Deployment Apply

### PR Comments

<details>
<summary><a name="barrier-rollout-in-progress"></a><strong>Barrier Rollout In Progress</strong></summary>


## Schema Change Status — Production

**Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @aparajon at 2026-01-01 00:00:00 UTC*

**Deployments**: 1 ready for cutover, 1 running, 2 waiting

---

To cut over `eu`:
```
schemabot cutover apply-a1b2c3d4e5f6 -e production
```

- 🟢 eu — ready for cutover — next in order
- 🔄 us — running table copy
- ⏳ au — waiting for us
- ⏳ ca — waiting for us

<details open>
<summary>🟢 eu — ready for cutover — next in order</summary>

**Database**: `payments_eu` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @aparajon at 2026-01-01 00:00:00 UTC*

**Status**: Waiting for Cutover

**3/3** table(s) ready for cutover

📊 3 ready for cutover

**Schema `testapp`**

**`orders`**: 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 ✅ Ready for cutover

```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`users`**: 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 ✅ Ready for cutover

```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```

**`products`**: 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 ✅ Ready for cutover

```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```


---

SchemaBot triggers cutover automatically — no action needed.

</details>

<details open>
<summary>🔄 us — running table copy</summary>

**Database**: `payments_us` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @aparajon at 2026-01-01 00:00:00 UTC*

**Status**: In Progress

📊 1/3 complete · 1 running (62%) · 1 queued

**Schema `testapp`**

**`users`**: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦⬜⬜⬜⬜⬜⬜⬜⬜ 62%

```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```
Rows: 914,707 / 1,466,232 · ETA: 3m 15s

**`products`**: ⏳ Queued

```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```

**`orders`**: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Complete

```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```


---

To stop this schema change:
```
schemabot stop apply-a1b2c3d4e5f6 -e production
```

</details>

<details>
<summary>⏳ au — waiting for us</summary>

_No details available yet._

</details>

<details>
<summary>⏳ ca — waiting for us</summary>

_No details available yet._

</details>

_Last updated: <relative-time datetime="2026-01-01T00:00:00Z">2026-01-01 00:00:00 UTC</relative-time> (2026-01-01 00:00:00 UTC)_

</details>

<details>
<summary><a name="halt-on-failure-one-deployment-failed"></a><strong>Halt On Failure (One Deployment Failed)</strong></summary>


## Schema Change Status — Production

**Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @aparajon at 2026-01-01 00:00:00 UTC*

**Deployments**: 1 completed, 2 halted, 1 failed

> ⚠️ **First failure:** <code>us</code> — lock wait timeout exceeded; try restarting transaction

---

To retry:
```
schemabot apply -e production
```

- ✅ eu — completed
- ❌ us — failed
- ⏸ au — halted — us failed
- ⏸ ca — halted — us failed

<details>
<summary>✅ eu — completed</summary>

**Database**: `payments_eu` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @aparajon at 2026-01-01 00:00:00 UTC*

**Status**: Applied

📊 3/3 complete

**Schema `testapp`**

**`orders`**: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Complete

```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`users`**: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Complete

```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```

**`products`**: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Complete

```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```


</details>

<details open>
<summary>❌ us — failed</summary>

**Database**: `payments_us` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @aparajon at 2026-01-01 00:00:00 UTC*

**Status**: Failed
<!-- schemabot:offer-support-channel -->

📊 1/3 complete · 1 failed · 1 cancelled

**Schema `testapp`**

**`users`**: 🟥🟥🟥🟥🟥🟥⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ ❌ Failed

```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```

**`orders`**: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Complete

```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`products`**: ⊘ Cancelled (not started)

```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```


> ⚠️ **Error:** lock wait timeout exceeded; try restarting transaction

---

To retry:
```
schemabot apply -e production
```

</details>

<details open>
<summary>⏸ au — halted — us failed</summary>

_No details available yet._

</details>

<details open>
<summary>⏸ ca — halted — us failed</summary>

_No details available yet._

</details>

</details>

<details>
<summary><a name="all-deployments-completed"></a><strong>All Deployments Completed</strong></summary>


## Schema Change Status — Production

**Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @aparajon at 2026-01-01 00:00:00 UTC*

**Deployments**: 3 completed

- ✅ eu — completed
- ✅ us — completed
- ✅ au — completed

<details>
<summary>✅ eu — completed</summary>

**Database**: `payments_eu` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @aparajon at 2026-01-01 00:00:00 UTC*

**Status**: Applied

📊 3/3 complete

**Schema `testapp`**

**`orders`**: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Complete

```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`users`**: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Complete

```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```

**`products`**: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Complete

```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```


</details>

<details>
<summary>✅ us — completed</summary>

**Database**: `payments_us` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @aparajon at 2026-01-01 00:00:00 UTC*

**Status**: Applied

📊 3/3 complete

**Schema `testapp`**

**`orders`**: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Complete

```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`users`**: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Complete

```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```

**`products`**: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Complete

```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```


</details>

<details>
<summary>✅ au — completed</summary>

**Database**: `payments_au` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @aparajon at 2026-01-01 00:00:00 UTC*

**Status**: Applied

📊 3/3 complete

**Schema `testapp`**

**`orders`**: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Complete

```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`users`**: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Complete

```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```

**`products`**: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Complete

```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```


</details>

</details>

<details>
<summary><a name="summary-all-deployments-completed"></a><strong>Summary: All Deployments Completed</strong></summary>


## ✅ Schema Change Applied — Production

**Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @aparajon at 2026-01-01 00:00:00 UTC*

**Deployments**: 3 completed

- ✅ eu — completed
- ✅ us — completed
- ✅ au — completed

<details>
<summary>✅ eu — completed</summary>

**Database**: `payments_eu`


> Applied successfully — your schema changes are live!

<details><summary>Apply details (3 tables)</summary>

_Apply ID: `apply-a1b2c3d4e5f6`_


### testapp

**`orders`**
```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`users`**
```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```

**`products`**
```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```

</details>

</details>

<details>
<summary>✅ us — completed</summary>

**Database**: `payments_us`


> Applied successfully — your schema changes are live!

<details><summary>Apply details (3 tables)</summary>

_Apply ID: `apply-a1b2c3d4e5f6`_


### testapp

**`orders`**
```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`users`**
```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```

**`products`**
```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```

</details>

</details>

<details>
<summary>✅ au — completed</summary>

**Database**: `payments_au`


> Applied successfully — your schema changes are live!

<details><summary>Apply details (3 tables)</summary>

_Apply ID: `apply-a1b2c3d4e5f6`_


### testapp

**`orders`**
```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`users`**
```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```

**`products`**
```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```

</details>

</details>

</details>

<details>
<summary><a name="summary-halt-on-failure-one-deployment-failed"></a><strong>Summary: Halt On Failure (One Deployment Failed)</strong></summary>


## ❌ Schema Change Failed — Production

<!-- schemabot:offer-support-channel -->
**Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @aparajon at 2026-01-01 00:00:00 UTC*

**Deployments**: 1 completed, 2 halted, 1 failed

> ⚠️ **First failure:** <code>us</code> — lock wait timeout exceeded; try restarting transaction

---

To retry:
```
schemabot apply -e production
```

- ✅ eu — completed
- ❌ us — failed
- ⏸ au — halted — us failed
- ⏸ ca — halted — us failed

<details>
<summary>✅ eu — completed</summary>

**Database**: `payments_eu`


> Applied successfully — your schema changes are live!

<details><summary>Apply details (3 tables)</summary>

_Apply ID: `apply-a1b2c3d4e5f6`_


### testapp

**`orders`**
```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`users`**
```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```

**`products`**
```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```

</details>

</details>

<details open>
<summary>❌ us — failed</summary>

<!-- schemabot:offer-support-channel -->
**Database**: `payments_us` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @aparajon at 2026-03-15 14:22:00 UTC*

> ⚠️ **Error:** lock wait timeout exceeded; try restarting transaction

1 of 3 tables completed before failure.

### ❌ testapp

**`users`** — Failed
```sql
ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
```

**`orders`**
```sql
ALTER TABLE `orders` ADD INDEX `idx_user_id`(`user_id`);
```

**`products`** — Cancelled
```sql
ALTER TABLE `products` ADD INDEX `idx_price`(`price_cents`);
```


---

To retry:
```
schemabot apply -e production
```

</details>

<details open>
<summary>⏸ au — halted — us failed</summary>

_No details available yet._

</details>

<details open>
<summary>⏸ ca — halted — us failed</summary>

_No details available yet._

</details>
</details>

## Sharded Apply

### PR Comments

<details>
<summary><a name="plan-divergent-shards"></a><strong>Plan: Divergent Shards</strong></summary>


## Schema Change Plan — Production

**Database**: `cdb_resolute` | **Type**: `Strata`

*Requested by @jackjackbits at 2026-01-01 00:00:00 UTC · planned from [`abcdef1`](https://github.com/block/schemabot/commit/abcdef1234567890abcdef1234567890abcdef12)*

#### Keyspace: `cdb_resolute_sharded`
Shards diverge — what applies where:

**shards `-40`, `80-c0`, `c0-`**

```sql
ALTER TABLE `mutes` ADD INDEX `created_at`(`created_at`);
```

**shard `40-80`**

```sql
ALTER TABLE `mutes`
    ADD INDEX `created_at`(`created_at`),
    ADD COLUMN `reason` varchar(255);
```

📋 **Plan**: **1** table to alter


---

💡 **To apply** all schema changes from this PR, comment:
```
schemabot apply -e production
```

</details>

<details>
<summary><a name="plan-partially-applied-shards"></a><strong>Plan: Partially Applied Shards</strong></summary>


## Schema Change Plan — Production

**Database**: `cdb_resolute` | **Type**: `Strata`

*Requested by @jackjackbits at 2026-01-01 00:00:00 UTC · planned from [`abcdef1`](https://github.com/block/schemabot/commit/abcdef1234567890abcdef1234567890abcdef12)*

#### Keyspace: `cdb_resolute_sharded`
Shards diverge — what applies where:

**shard `-40`**

_Already applied — no change._

**shards `40-80`, `80-c0`, `c0-`**

```sql
ALTER TABLE `mutes` ADD INDEX `created_at`(`created_at`);
```

📋 **Plan**: 1 DDL statement


---

💡 **To apply** all schema changes from this PR, comment:
```
schemabot apply -e production
```

</details>

<details>
<summary><a name="plan-unsafe-change-on-one-shard"></a><strong>Plan: Unsafe Change On One Shard</strong></summary>


## Schema Change Plan — Production

**Database**: `cdb_resolute` | **Type**: `Strata`

*Requested by @jackjackbits at 2026-01-01 00:00:00 UTC · planned from [`abcdef1`](https://github.com/block/schemabot/commit/abcdef1234567890abcdef1234567890abcdef12)*

#### Keyspace: `cdb_resolute_sharded`
Shards diverge — what applies where:

**shards `-40`, `80-c0`, `c0-`**

```sql
ALTER TABLE `mutes` ADD INDEX `created_at`(`created_at`);
```

**shard `40-80`**

```sql
ALTER TABLE `mutes`
    ADD INDEX `created_at`(`created_at`),
    DROP COLUMN `legacy_reason`;
```

⚠️ **Issues**: **1** unsafe change detected
- `mutes` (shard `40-80`): DROP COLUMN removes data and is irreversible

**Destructive drop guidance:**

Before allowing a destructive drop, first deploy application code that no longer reads from or writes to the dropped column.

📋 **Plan**: 2 DDL statements


---

💡 **To apply** all schema changes from this PR, comment:
```
schemabot apply -e production
```

</details>

<details>
<summary><a name="apply-in-progress"></a><strong>Apply In Progress</strong></summary>


## Schema Change Status — Production

**Database**: `cdb_resolute` | **Type**: `Strata` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Shards**: 1 running table copy, 3 waiting for -40

#### Keyspace `cdb_resolute_sharded`

| Shard | Status |
| --- | --- |
| `-40` | 🔄 running table copy |
| `40-80` | ⏳ waiting for -40 |
| `80-c0` | ⏳ waiting for -40 |
| `c0-` | ⏳ waiting for -40 |

_Last updated: <relative-time datetime="2026-01-01T00:00:00Z">2026-01-01 00:00:00 UTC</relative-time> (2026-01-01 00:00:00 UTC)_

</details>

<details>
<summary><a name="apply-failed-one-shard-failed"></a><strong>Apply Failed (One Shard Failed)</strong></summary>


## Schema Change Status — Production

**Database**: `cdb_resolute` | **Type**: `Strata` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Shards**: 1 failed, 3 halted

> ⚠️ **First failure:** shard <code>-40</code> — resolve shard primary for `-40`: context deadline exceeded

#### Keyspace `cdb_resolute_sharded`

| Shard | Status |
| --- | --- |
| `-40` | ❌ failed — resolve shard primary for `-40`: context deadline exceeded |
| `40-80` | ⏸ halted — -40 failed |
| `80-c0` | ⏸ halted — -40 failed |
| `c0-` | ⏸ halted — -40 failed |

---

To retry:
```
schemabot apply -e production
```

</details>

<details>
<summary><a name="apply-with-divergent-shards"></a><strong>Apply With Divergent Shards</strong></summary>


## Schema Change Status — Production

**Database**: `cdb_resolute` | **Type**: `Strata` | **Apply ID**: `apply-a1b2c3d4e5f6`

*Applied by @jackjackbits at 2026-01-01 00:00:00 UTC*

**Shards**: 1 running table copy, 2 waiting for -40

#### Keyspace `cdb_resolute_sharded`

Shards diverge — grouped by change:

**shards `-40`, `80-c0`**

| Shard | Status |
| --- | --- |
| `-40` | 🔄 running table copy |
| `80-c0` | ⏳ waiting for -40 |

**shard `40-80`**

| Shard | Status |
| --- | --- |
| `40-80` | ⏳ waiting for -40 |

_Last updated: <relative-time datetime="2026-01-01T00:00:00Z">2026-01-01 00:00:00 UTC</relative-time> (2026-01-01 00:00:00 UTC)_
</details>

## Multi-Deployment Apply (CLI)

<details>
<summary><a name="barrier-rollout-in-progress"></a><strong>Barrier Rollout In Progress</strong></summary>

```

┌───────────────────────────────────────────────────────────────┐
│  Apply ID:     apply-multi-a1b2c3d4                           │
│  Environment:  production                                     │
│  State:        running                                        │
│  Caller:       octocat                                        │
│  Started:      Jan 15 14:22:00 UTC                            │
│  Duration:     8m                                             │
│  Deployments:  1 ready for cutover · 1 running · 1 waiting    │
└───────────────────────────────────────────────────────────────┘

  Next: cut over us-east

🟢 us-east — ready for cutover — next in order (orders-us-east)

     ~ orders: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦 Waiting for cutover
       ALTER TABLE `orders` ADD COLUMN `source` varchar(32);


🔄 eu-west — running table copy (orders-eu-west)

     ~ orders: 🟦🟦🟦🟦🟦🟦🟦⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ 35%
       ALTER TABLE `orders` ADD COLUMN `source` varchar(32);
       • Rows: 42,000 / 120,000 · ETA: 4m 0s


⏳ ap-south — waiting for eu-west (orders-ap-south)

     ~ orders: ⏳ Queued
       ALTER TABLE `orders` ADD COLUMN `source` varchar(32);



```
</details>

<details>
<summary><a name="halt-on-failure-one-deployment-failed"></a><strong>Halt On Failure (One Deployment Failed)</strong></summary>

```

┌─────────────────────────────────────────────────────┐
│  Apply ID:     apply-multi-a1b2c3d4                 │
│  Environment:  production                           │
│  State:        failed                               │
│  Caller:       octocat                              │
│  Started:      Jan 15 14:22:00 UTC                  │
│  Duration:     8m                                   │
│  Deployments:  1 completed · 1 halted · 1 failed    │
└─────────────────────────────────────────────────────┘

  ⚠ First failure: eu-west — duplicate key name 'idx_orders_source'

  Next: review failure in eu-west

✅ us-east — completed (orders-us-east)

     ~ orders: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `orders` ADD COLUMN `source` varchar(32);


❌ eu-west — failed (orders-eu-west)
  duplicate key name 'idx_orders_source'

     ~ orders: ⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ ❌ Failed
       ALTER TABLE `orders` ADD INDEX `idx_orders_source`(`source`);


⏸ ap-south — halted — eu-west failed (orders-ap-south)

     ~ orders: ⊘ Cancelled (not started)
       ALTER TABLE `orders` ADD COLUMN `source` varchar(32);



```
</details>

<details>
<summary><a name="all-deployments-completed"></a><strong>All Deployments Completed</strong></summary>

```

┌──────────────────────────────────────┐
│  Apply ID:     apply-multi-a1b2c3d4  │
│  Environment:  production            │
│  State:        completed             │
│  Caller:       octocat               │
│  Started:      Jan 15 14:22:00 UTC   │
│  Duration:     7m                    │
│  Deployments:  3 completed           │
└──────────────────────────────────────┘

✅ us-east — completed (orders-us-east)

     ~ orders: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `orders` ADD COLUMN `source` varchar(32);


✅ eu-west — completed (orders-eu-west)

     ~ orders: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `orders` ADD COLUMN `source` varchar(32);


✅ ap-south — completed (orders-ap-south)

     ~ orders: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `orders` ADD COLUMN `source` varchar(32);


```
</details>


## Sequential Mode (CLI)

<details>
<summary><a name="pending-all-queued"></a><strong>Pending (All Queued)</strong></summary>

```

Sequential mode: Just started (all tables pending)

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Pending              │
│  Started:   Jan 15 14:29:50 UTC  │
│  Duration:  10s                  │
└──────────────────────────────────┘


```
</details>

<details>
<summary><a name="first-table-running"></a><strong>First Table Running</strong></summary>

```

Sequential mode: First table running, others queued

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Running              │
│  Started:   Jan 15 14:25:00 UTC  │
│  Duration:  5m                   │
└──────────────────────────────────┘


     ~ users: 🟦🟦🟦🟦🟦🟦🟦⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ 35%
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);
       • Rows: 875,000 / 2,500,000 · ETA: 8m 30s

     ~ orders: ⏳ Queued
       ALTER TABLE `orders` ADD INDEX `idx_user_status`(`user_id`, `status`);

     ~ products: ⏳ Queued
       ALTER TABLE `products` ADD COLUMN `weight_grams` int DEFAULT 0;


```
</details>

<details>
<summary><a name="second-table-running"></a><strong>Second Table Running</strong></summary>

```

Sequential mode: First complete, second running

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Running              │
│  Started:   Jan 15 14:18:00 UTC  │
│  Duration:  12m                  │
└──────────────────────────────────┘


     ~ orders: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦⬜⬜⬜⬜⬜⬜⬜⬜ 60%
       ALTER TABLE `orders` ADD INDEX `idx_user_status`(`user_id`, `status`);
       • Rows: 3,000,000 / 5,000,000 · ETA: 12m 15s

     ~ products: ⏳ Queued
       ALTER TABLE `products` ADD COLUMN `weight_grams` int DEFAULT 0;

     ~ users: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);


```
</details>

<details>
<summary><a name="third-table-running"></a><strong>Third Table Running</strong></summary>

```

Sequential mode: First two complete, third running

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Running              │
│  Started:   Jan 15 14:10:00 UTC  │
│  Duration:  20m                  │
└──────────────────────────────────┘


     ~ products: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦⬜⬜⬜⬜ 80%
       ALTER TABLE `products` ADD COLUMN `weight_grams` int DEFAULT 0;
       • Rows: 160,000 / 200,000 · ETA: 2m 45s

     ~ users: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);

     ~ orders: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `orders` ADD INDEX `idx_user_status`(`user_id`, `status`);


```
</details>

<details>
<summary><a name="all-completed"></a><strong>All Completed</strong></summary>

```

Sequential mode: All tables completed successfully

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Completed            │
│  Started:   Jan 15 14:05:00 UTC  │
│  Duration:  24m 30s              │
└──────────────────────────────────┘


     ~ users: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);

     ~ orders: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `orders` ADD INDEX `idx_user_status`(`user_id`, `status`);

     ~ products: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `products` ADD COLUMN `weight_grams` int DEFAULT 0;

✓ Apply complete!

```
</details>

<details>
<summary><a name="first-table-failed"></a><strong>First Table Failed</strong></summary>

```

Sequential mode: First table failed (others cancelled)

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Failed               │
│  Started:   Jan 15 14:22:00 UTC  │
│  Duration:  7m 30s               │
└──────────────────────────────────┘

  lock wait timeout exceeded; try restarting transaction


     ~ users: 🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥⬜⬜⬜⬜⬜⬜⬜ ❌ Failed
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);

     ~ orders: ⊘ Cancelled (not started)
       ALTER TABLE `orders` ADD INDEX `idx_user_status`(`user_id`, `status`);

     ~ products: ⊘ Cancelled (not started)
       ALTER TABLE `products` ADD COLUMN `weight_grams` int DEFAULT 0;


To recover: Fix the issue above, then run a new apply.
The new apply will only process tables that haven't completed.

```
</details>

<details>
<summary><a name="middle-table-failed"></a><strong>Middle Table Failed</strong></summary>

```

Sequential mode: Middle table failed

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Failed               │
│  Started:   Jan 15 14:12:00 UTC  │
│  Duration:  17m 30s              │
└──────────────────────────────────┘

  Lost connection to MySQL server during query (MySQL error 2013)


     ~ orders: 🟥🟥🟥🟥🟥🟥🟥🟥🟥⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ ❌ Failed
       ALTER TABLE `orders` ADD INDEX `idx_user_status`(`user_id`, `status`);

     ~ users: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);

     ~ products: ⊘ Cancelled (not started)
       ALTER TABLE `products` ADD COLUMN `weight_grams` int DEFAULT 0;


To recover: Fix the issue above, then run a new apply.
The new apply will only process tables that haven't completed.

```
</details>

<details>
<summary><a name="stopped-by-user"></a><strong>Stopped By User</strong></summary>

```

Sequential mode: User stopped mid-apply

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Stopped              │
│  Started:   Jan 15 14:25:00 UTC  │
│  Duration:  5m                   │
└──────────────────────────────────┘


     ~ orders: 🟧🟧🟧🟧🟧🟧🟧🟧⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ ⏹️ Stopped at 42%
       ALTER TABLE `orders` ADD INDEX `idx_user_status`(`user_id`, `status`);
       • Rows: 112,045 / 266,383

     ~ products: ⏹️ Stopped (not started)
       ALTER TABLE `products` ADD COLUMN `weight_grams` int DEFAULT 0;

     ~ users: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);

Use 'schemabot start' to resume from checkpoint.
```
</details>


## Defer Cutover (CLI)

<details>
<summary><a name="atomic-mode-running"></a><strong>Atomic Mode Running</strong></summary>

```

Atomic mode (--defer-cutover): All tables copy rows, then cutover together

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Running              │
│  Started:   Jan 15 14:22:00 UTC  │
│  Duration:  8m                   │
└──────────────────────────────────┘


     ~ orders: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦⬜⬜⬜⬜⬜⬜ 72%
       ALTER TABLE `orders` ADD INDEX `idx_user_status`(`user_id`, `status`);
       • Rows: 1,800,000 / 2,500,000 · ETA: 3m 15s

     ~ products: 🟦🟦🟦🟦🟦🟦🟦🟦🟦⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ 45%
       ALTER TABLE `products` ADD INDEX `idx_category`(`category`);
       • Rows: 450,000 / 1,000,000 · ETA: 6m 20s

     ~ users: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦⬜⬜⬜ 89%
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);
       • Rows: 6,400,000 / 7,200,000 · ETA: 1m 45s

All tables copy rows simultaneously. Cutover happens atomically
after all tables complete row copy.

```
</details>

<details>
<summary><a name="single-table-waiting"></a><strong>Single Table Waiting</strong></summary>

```

Defer cutover: Single table waiting
(--defer-cutover flag with single table)

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Waiting for cutover  │
│  Started:   Jan 15 14:20:00 UTC  │
│  Duration:  10m                  │
└──────────────────────────────────┘


     ~ users: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦 Waiting for cutover
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);

Row copy complete. All data has been copied and new writes
continue to be replicated to keep the shadow table in sync.

Press Enter to proceed with cutover (or Ctrl+C to detach): _

```
</details>

<details>
<summary><a name="multiple-tables-waiting-atomic"></a><strong>Multiple Tables Waiting (Atomic)</strong></summary>

```

Atomic mode (--defer-cutover): All tables waiting for cutover

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Waiting for cutover  │
│  Started:   Jan 15 14:15:00 UTC  │
│  Duration:  15m                  │
└──────────────────────────────────┘


     ~ orders: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦 Waiting for cutover
       ALTER TABLE `orders` ADD INDEX `idx_user_status`(`user_id`, `status`);

     ~ products: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦 Waiting for cutover
       ALTER TABLE `products` ADD INDEX `idx_category`(`category`);

     ~ users: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦 Waiting for cutover
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);

Row copy complete for all tables. New writes continue to be
replicated to keep shadow tables in sync.

Press Enter to proceed with cutover (or Ctrl+C to detach): _

```
</details>

<details>
<summary><a name="sequential-mode-waiting"></a><strong>Sequential Mode Waiting</strong></summary>

```

Defer cutover: Sequential mode, first complete, second waiting
(--defer-cutover flag with sequential execution)

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Waiting for cutover  │
│  Started:   Jan 15 14:18:00 UTC  │
│  Duration:  12m                  │
└──────────────────────────────────┘


     ~ orders: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦 Waiting for cutover
       ALTER TABLE `orders` ADD INDEX `idx_user_status`(`user_id`, `status`);

     ~ products: ⏳ Queued
       ALTER TABLE `products` ADD COLUMN `weight_grams` int DEFAULT 0;

     ~ users: 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✓ Complete
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);

Row copy complete for current table. Press Enter to cutover
and start the next table (or Ctrl+C to detach): _

```
</details>

<details>
<summary><a name="stopped-by-user"></a><strong>Stopped By User</strong></summary>

```

Defer cutover: Stopped by user (s)
(all tables show stopped state in atomic mode)

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Stopped              │
│  Started:   Jan 15 14:22:00 UTC  │
│  Duration:  8m                   │
└──────────────────────────────────┘


     ~ orders: 🟧🟧🟧🟧🟧🟧🟧🟧🟧🟧🟧🟧🟧🟧⬜⬜⬜⬜⬜⬜ ⏹️ Stopped at 72%
       ALTER TABLE `orders` ADD INDEX `idx_user_status`(`user_id`, `status`);
       • Rows: 1,800,000 / 2,500,000

     ~ products: 🟧🟧🟧🟧🟧🟧🟧🟧🟧⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ ⏹️ Stopped at 45%
       ALTER TABLE `products` ADD INDEX `idx_category`(`category`);
       • Rows: 450,000 / 1,000,000

     ~ users: 🟧🟧🟧🟧🟧🟧🟧🟧🟧🟧🟧🟧🟧🟧🟧🟧🟧⬜⬜⬜ ⏹️ Stopped at 89%
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);
       • Rows: 6,400,000 / 7,200,000

Use 'schemabot start -e staging <apply_id>' to resume.

```
</details>

<details>
<summary><a name="detached-state"></a><strong>Detached State</strong></summary>

```

Defer cutover: Detached state (user pressed Ctrl+C)

You have detached from the progress view.

The schema change is still running in the background.
Row copy is complete and the shadow table is kept in sync.

To check status:
  schemabot status <apply_id>

To proceed with cutover:
  schemabot cutover -e staging <apply_id>

To abort the schema change:
  schemabot stop -e staging <apply_id>

```
</details>

<details>
<summary><a name="cutting-over"></a><strong>Cutting Over</strong></summary>

```

Defer cutover: Cutting over in progress
(After user pressed Enter or ran `schemabot cutover`)

┌──────────────────────────────────┐
│  Apply ID:  apply-a1b2c3d4e5f6   │
│  State:     Cutting over         │
│  Started:   Jan 15 14:15:00 UTC  │
│  Duration:  15m                  │
└──────────────────────────────────┘


     ~ orders: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦 Cutting over...
       ALTER TABLE `orders` ADD INDEX `idx_user_status`(`user_id`, `status`);

     ~ products: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦 Cutting over...
       ALTER TABLE `products` ADD INDEX `idx_category`(`category`);

     ~ users: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦 Cutting over...
       ALTER TABLE `users` ADD INDEX `idx_email_created`(`email`, `created_at`);

Cutover in progress. This typically completes within seconds.
Tables are being renamed atomically...
```
</details>


## Lint & Unsafe (CLI)

<details>
<summary><a name="lint-warnings"></a><strong>Lint Warnings</strong></summary>

```

Lint violations: Non-blocking warnings during plan/apply

⚠️  Lint Warnings:
  - [orders] has_float: New column uses floating-point data type
  - [users] no_default: Column added without DEFAULT value


```
</details>

<details>
<summary><a name="unsafe-changes-blocked"></a><strong>Unsafe Changes Blocked</strong></summary>

```

Unsafe blocked: Destructive changes require --allow-unsafe

⛔ Unsafe Changes Detected:
  • users: DROP COLUMN email
  • orders: DROP TABLE
  • products:
      - MODIFY COLUMN price_cents: INT → SMALLINT (potential data loss)
      - DROP INDEX idx_category

🚨 To proceed with these destructive changes, re-run with --allow-unsafe:

  schemabot apply -s ./schema/testapp -e staging --allow-unsafe


```
</details>

<details>
<summary><a name="unsafe-changes-allowed"></a><strong>Unsafe Changes Allowed</strong></summary>

```

Unsafe allowed: Proceeding with --allow-unsafe flag


🚨 Unsafe Changes (--allow-unsafe enabled)

The following changes will permanently delete data:
  • users: DROP COLUMN email
  • orders: DROP TABLE

```
</details>


## Interactive TUI (CLI)

```
⣾ Running...

     ~ users: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦 Finalizing copy ⠋
       ALTER TABLE `users` ADD INDEX `idx_email`(`email`);
       • Rows copied: 145,250,000 so far
       • ℹ️ More rows than initially estimated, copying is still active and will continue


ESC detach • s stop • v volume
```


## Multi-Deployment Apply TUI (CLI)

```
⣾ running
1 ready for cutover · 1 running · 1 waiting
Apply ID: apply-multi-a1b2c3d4
Environment: production

🟢 us-east — ready for cutover — next in order (orders-us-east)
  External operation ID: remote-op-us-east-001
  External apply ID: remote-apply-us-east-001

     ~ orders: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦 Waiting for cutover
       ALTER TABLE `orders` ADD COLUMN `source` varchar(32);


🔄 eu-west — running table copy (orders-eu-west)
  External operation ID: remote-op-eu-west-001
  External apply ID: remote-apply-eu-west-001

     ~ orders: 🟦🟦🟦🟦🟦🟦🟦⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜⬜ 35%
       ALTER TABLE `orders` ADD COLUMN `source` varchar(32);
       • Rows: 42,500 / 120,000 · ETA: 4m 0s


⏳ ap-south — waiting for eu-west (orders-ap-south)

     ~ orders: ⏳ Queued
       ALTER TABLE `orders` ADD COLUMN `source` varchar(32);


ESC to detach
```


## Exit Context (CLI)

=== Exit Context: MySQL Detach ===

  Apply ID:  apply-8487c4ad
  Resume:    schemabot progress apply-8487c4ad -e staging


=== Exit Context: Vitess Detach ===

  Apply ID:  apply-9849818a9cec4ba7
  Deploy Request:  https://app.planetscale.com/square-production/inventory2/deploy-requests/109
  Resume:    schemabot progress apply-9849818a9cec4ba7 -e production


=== Exit Context: MySQL Connection Lost ===
Error: unexpected error: connection refused

  Apply ID:  apply-8487c4ad
  Resume:    schemabot progress apply-8487c4ad -e staging


=== Exit Context: Vitess Connection Lost ===
Error: unexpected error: connection refused

  Apply ID:  apply-9849818a9cec4ba7
  Deploy Request:  https://app.planetscale.com/square-production/inventory2/deploy-requests/109
  Resume:    schemabot progress apply-9849818a9cec4ba7 -e production