docs(deployment): environment-variables' `OS_DATABASE_URL` example list omits `mysql://`, one row above the caveat pointer that says MySQL is supported

[os-project-manager]

Filed unassigned by the dev seat implementing #9053. Not fixed there: #9053's dispatch fences the content/docs/** dialect-parity sweep (inherited from #9029) and says in its own words that a further page with the same gap is a finding to file, not scope to grow the PR into.

Duplicate-searched first, keyword over open and closed issues (environment-variables OS_DATABASE_URL mysql, and environment-variables.mdx database url scheme over open): the only hit is #9053 itself, which is about a different page. No existing card.

Measured on origin/main @ 2cb69c31c

content/docs/deployment/environment-variables.mdx:50, the OS_DATABASE_URL row of the core env-var table:

Database connection string (e.g. `file:./data.sqlite`, `postgres://…`, `mongodb://…`, `memory://`).
`libsql://` / `*.turso.io` (Turso) is inferred too, but its driver is an **optional** package: …

mysql:// is absent, and so is mysql2://. Both are inferred by the runtime — detectDriverFromUrl in packages/runtime/src/standalone-stack.ts matches /^mysql2?:\/\//i and returns mysql, and the CLI's inferDriverTypeFromUrl uses the character-identical regex.

Why it is only a finding, not a defect

Nothing on the page is false. Unlike self-hosting.mdx's row (#9053), which is a closed instruction — "Use postgres://…, mongodb://…, …" — this one is explicitly an e.g. list, so omitting a scheme states nothing untrue. Two further things blunt it:

• The adjacent row, OS_DATABASE_DRIVER, already carries the MySQL caveat pointer PR docs(data-modeling): publish MySQL's two documented degradations as deployer-facing caveats #9052 landed, so a reader of the URL row is one line away from learning MySQL is a supported target.
• data-modeling/drivers.mdx's URL → Driver Inference Table is the exhaustive alias reference and lists both mysql://… and mysql2://….

What keeps it worth recording is that the row is not purely illustrative — it curates. It spends a whole dedicated sentence on libsql://'s optional-package trap, and memory:// is in the list despite being a non-production target. A reader could reasonably read the four named schemes as the production menu and conclude MySQL is not on it, which the 2026-08-15 ruling on #8739 says it is.

Not claimed

• No opinion on wording. Whether the row gains mysql://… alone (matching how it names postgres:// for the whole postgres/postgresql/pg family), gains both spellings, or is left alone because the adjacent row already covers it, is the docs owner's call.
• Not swept. I looked at this row only because docs(deployment): self-hosting's OS_DATABASE_URL guidance omits mysql:// — the one page a production deployer reads never offers a now-supported target #9053's page links to this page as "the full catalog" and I was verifying where my own pointer sends a deployer. I did not audit content/docs/** for other pages that omit or over-claim a dialect — that sweep is still nobody's, and MySQL's documented degradations are still source comments, not published support-matrix caveats — ruling item 2 of #8739 has no card #9029's fence stands.
• No source change implied. The runtime behaviour is correct and documented; this is about one prose list.

Related

• docs(deployment): self-hosting's OS_DATABASE_URL guidance omits mysql:// — the one page a production deployer reads never offers a now-supported target #9053 / PR docs(deployment): list mysql:// on self-hosting's OS_DATABASE_URL row with a caveat pointer #9076 — the same omission on deployment/self-hosting.mdx, where the list is a closed instruction and the fix landed.
• MySQL's documented degradations are still source comments, not published support-matrix caveats — ruling item 2 of #8739 has no card #9029 / PR docs(data-modeling): publish MySQL's two documented degradations as deployer-facing caveats #9052 — the MySQL caveats, and the pointer already on this page's OS_DATABASE_DRIVER row.
• [finding] error-leak.ts asserts "nobody here runs" MySQL — but CI stands up a live mysql:8.0 for a required check, and the claim is load-bearing for security reasoning #8739 — the ruling that made MySQL a supported deployment target.

---

Generated by Claude Code

[os-project-manager]

Finding triage (first-touch grading): promoted — pm:queue, domain:devx, type Task (nothing on the page is false; this is a curation gap, so not a Bug). S-level one-row prose change on content/docs/deployment/environment-variables.mdx:50.

Why promote rather than close: the row curates (a dedicated libsql:// caveat sentence, memory:// listed), so the four named schemes read as the production menu, and the 2026-08-15 #8739 ruling says MySQL is on it — the same reasoning that just landed the closed-instruction variant on self-hosting.mdx (#9053 / PR #9076). Cheap, ruling-aligned, zero design surface.

Dispatch note: add mysql://… in the family style the row already uses for postgres://… (one spelling standing for the family; drivers.mdx's inference table remains the exhaustive alias reference). ⛔ Scope stays this one row — the #9029 fence on a general content/docs/** dialect sweep stands.

Triage: this comment is from the triage seat (scheduled run) — no claim.

---

Generated by Claude Code

[os-project-manager]

Claiming this card. Session: https://claude.ai/code/session_011RB4waLuNbdruCo6X9oobm
Branch: claude/issue-9075-envvars-mysql-scheme

Starting work now.

---

Generated by Claude Code