PR 5305 — provisioning assessment (no code pushed)

Repository: https://github.com/pingdotgg/t3code
PR: https://github.com/pingdotgg/t3code/pull/5305
Branch: relay/provision-vitess-db
Original unchanged head: 394dead4323b923f2008703c8f01c3ac3760b0d6
Current-main schema/API comparison: 1451e7cb23034d29774338608368a15d8845df36

Scope: additive empty Vitess provisioning with complete current relay schema and
Alchemy migration bookkeeping; Worker and Hyperdrive remain on Postgres.
No production operation, cutover, resource reconciliation or replication occurred.

Focused test result: existing dbConfig.test.ts 1/1 passed; scoped db.ts lint passed.
Original PR tests: 0 tests/0 files -> unchanged 0/0. No invented definition tests.
Installed Alchemy beta80 API control: legacy migrationsDir/migrationsTable inputs
normalize to undefined; direct assertion fails. Current migrations:{dir,table}
control passes. Isolated TypeScript legacy/current exit codes 2/0, TS2561 for old
shape. This is compatibility drift from original beta65, not an original-beta65
failure and not a relay package-wide typecheck or actual provider run.
Current provider lazily imports mysql2/promise; resolution from installed Alchemy
fails MODULE_NOT_FOUND and current relay manifest omits the dependency.

Unchanged baseline SQL applied to disposable official MySQL 8.0.46, network none,
no published ports, private volume. Exact SQL probe failures:
- Current Android row including android_api_level and NULL ios_major_version:
  ERROR 1054 unknown android_api_level. NULL-iOS independently untested.
- Current 512-character activity thread_id: ERROR 1406 data too long.
- Scratch-only widening of that PK column: ERROR 1071 maximum key length 3072.
  utf8mb4 declared maximum (191+255+512)*4 = 3832 bytes.
Both activity/delivery columns need current full 512 width. Current baseline also
omits offline-webhook holding and endpoint recovery/origin/generation/tunnel-release
fields. PG text keys/tokens require a lossless representation decision; no bounds,
prefix-unique key, or ASCII assumption was introduced.

Baseline SQL git blob: 1a485112be4af5bd9f37e92acfe5017615697650
Snapshot git blob: 836b9414cc8b02f718e0be875e8e51362f4b96b7
These match the previously tested cutover baseline. Reused 24 scratch-evidence
SHA256 values remain unchanged. Prior local stock-MySQL case-sensitive identity
probe showed proof-A/proof-a collapse under default utf8mb4_0900_ai_ci; a controlled
binary-collation change distinguished them. Actual Vitess collation is unverified.
Cutover runtime INSERT IGNORE/token-race findings are not attributed to this
provisioning-only PR. The MySQL container and private volume were removed.

Minimum repair: rebuild only additive resource and synchronized SQL/snapshot on
current main, use current migration API, add compatible migration-driver deployment
dependency/lockfile, settle full-value identity capacity/equality. Preserve main PG
PS_80, Hyperdrive origin/limit40, runtime role and PG bindings. Actual Alchemy
history is id/hash/created_at/name/applied_at, keyed by baseline name/hash. Do not
assume editing an applied baseline reruns; DDL can auto-commit on partial failure.

External proof gate: a designated isolated empty Vitess database/branch, separate
Alchemy state and scoped authorized provisioning access were unavailable. A random
personal stage points at production PG; full stack also reconciles other resources.
Use an isolated provider-only harness with isolated physical names/state, then apply
and unchanged-reapply actual beta80 provider. Inspect all full-width fields and
identities, distinct-case equality and representative current rows,
relay_migrations name/hash/history/timestamps, no DDL replay/data loss/history churn,
and unchanged PG wiring. Broader boundary/lifecycle sweeps are optional.
No production deploy, Worker/Hyperdrive cutover, PG source or DMS is needed for that
narrow proof. Optional DMS-ready claims need designated isolated source/target/task,
DO_NOTHING/history exclusion before start, full-value load/CDC reconciliation.

One independent parallel review pair (Claude Opus 5.5, GPT-6 Sol) confirmed the
schema/API/dependency findings and supported BLOCKED/no-push. Opus additionally
verified deploy-relay.yml triggers deploy --stage prod on pushes to main. This
makes isolated proof necessary before any future merge; no merge happened here.
Whether the deployment bundles/typechecks before reconciliation was not tested,
so old props may fail loudly or omit migrations; neither path is readiness proof.
Review reconciliation: require maintainer key-representation decision followed by
provider-only isolated apply/reapply with schema/history dumps and representative
current rows. Broad Unicode/padding/long-prefix matrices and temporary-password
lifecycle sweeps are optional diagnostics, not additional mandatory gates.
DMS remains optional. No extra source changes were made after these reviews.

Outcome: BLOCKED/no push. Original open and unchanged. Assessment evidence only;
no corrected baseline, Vitess/provider idempotence or replication pass is claimed.
Tests: GPT-6 Astra; implementation assessment: GPT-6.1 Sol; independent reviews:
Claude Opus 5.5 and GPT-6 Sol. Codex/Claude harnesses in T3 Code.