fix(github): drop the cutover duration promise from progress surfaces

[aparajon]

Why this matters

The cutting-over comment footer promised "typically completes within seconds", but cutover duration depends on acquiring the table lock under whatever write load the target is carrying — SchemaBot cannot know how long that takes, and on a hot table it can be far longer than seconds. A duration promise that doesn't hold trains operators to distrust the status surface exactly when they are watching it most closely. The honest rendering is the state itself, with no forecast.

What it does

cutting-over rendering
├─ PR comment footer: the "Cutover in progress — typically completes within
│  seconds." line is removed with no replacement — the cutting_over state
│  renders no footer, the same as other states with no operator action
└─ CLI preview: the equivalent "typically completes within seconds" line is
   removed from the defer-cutover preview scenario

Two properties worth calling out:

• No forecast, anywhere. No surface now claims how long a cutover takes. The status line and per-table glyphs already say what is happening; duration is the one thing SchemaBot cannot promise, so it says nothing.
• No action prompt lost. The removed footer carried no command — cutover has no operator action while it is in flight — so the footer's disappearance removes only the false claim.

Rendered: cutting-over PR comment (after)

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...

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

users: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦 🔄 Cutting over...

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

products: 🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦 🔄 Cutting over...

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

Last updated: 2026-01-01 00:00:00 UTC

A second commit fixes a pre-existing severity-glyph lint finding in the same package (the sharded table failure label now uses glyph.Failed); the rendered output is byte-identical.

How it moves us toward the northstar

The northstar is a status surface an operator can trust during an incident without cross-checking the database. Every claim the surface makes has to be one SchemaBot can actually stand behind; removing the one it can't keeps the cutting-over comment a statement of fact rather than a guess.

Opened by Claude (Fable 5).

[Copilot]

Pull request overview

Removes an unreliable “typically completes within seconds” duration claim from cutover-in-progress status surfaces, ensuring operator-facing progress output remains factual and trustworthy.

Changes:

• Dropped the “typically completes within seconds” footer from the PR progress comment when an apply is in cutting_over.
• Removed the equivalent duration sentence from the CLI “defer cutover” preview scenario.
• Fixed a pre-existing severity-glyph lint issue by using glyph.Failed for the sharded table failure label.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
TEMPLATES.md	Updates rendered template examples to remove the cutover duration promise from PR comment + CLI preview.
pkg/webhook/templates/sharded_apply.go	Uses glyph.Failed instead of a literal failure glyph for sharded table “Failed” status.
pkg/webhook/templates/apply.go	Removes the CuttingOver footer text that previously promised a short duration.
pkg/cmd/internal/templates/preview_defer.go	Removes the “typically completes within seconds” line from the defer-cutover preview output.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[morgo]

🤖 Approved on Morgan's behalf by his AI agent.

+1/-10, green CI, and the whole change is removing a promise the system can't keep. "Cutover in progress — typically completes within seconds" is exactly the kind of reassurance that reads fine until a cutover sits behind an MDL wait and the operator concludes something is broken because the UI told them to expect seconds. Removing it from all three surfaces (the doc, the CLI defer preview, and the webhook template) leaves the state word doing the work, which is honest. Nothing functional rides on it.

One thing to sequence, though: this PR also converts the literal ❌ in pkg/webhook/templates/sharded_apply.go to glyph.Failed — and #910 carries the identical one-line fix to the same file. Both are open. Whichever lands second will need that hunk dropped.

That's not a criticism of either PR; it's the predictable outcome of the thing I flagged on #910 yesterday. The severityglyphs analyzer blocks any commit touching pkg/webhook/... because of that one pre-existing literal on main, so every PR that goes near the package independently discovers it and fixes it in passing. Two have now done so. A single sweep running the analyzer repo-wide and fixing everything in one commit would stop the trail — and would also surface whatever other pre-existing violations are sitting in packages nobody has staged yet, rather than letting them ambush the next unrelated PR.

[aparajon]

🤖 Addressing morgo's review — agreed on the framing: the state word is the only thing this surface can say honestly, so it now says only that.

On the duplicated glyph hunk: #1239 landed first, so this PR is the "lands second" case you predicted. No action turned out to be needed — the hunk is byte-identical to what's now on main, so GitHub still reports the PR mergeable and clean; it just melts into a no-op at merge.

On the repo-wide sweep — I ran it. Analyzer over every package on current main, three passes (untagged, integration, e2e build tags). Result: exactly one violation left in the codebase — a literal ℹ️ in writeShardedTableCopyProgress (pkg/webhook/templates/sharded_apply.go:453), which arrived with #1191 in today's merge batch and will ambush the next PR that stages this package, exactly as you described. The sweep also surfaced a defect in the hook itself: it passes -tags=integration to the checker binary, but the singlechecker's -tags flag is deprecated and a no-op, so the integration pass has been silently re-analyzing the same untagged files (build tags have to go in via GOFLAGS). Both fixes — the one remaining literal and the hook's tag handling — are a natural single sweep PR; that's the author's call to open, but the inventory is done and it's short.

Reply generated by Claude Code (Claude Fable 5).