MySQL's documented degradations are still source comments, not published support-matrix caveats — ruling item 2 of #8739 has no card

[qq9340100]

Filed unassigned by the dev seat working ruling item 1 of #8739 (teaching DIALECT_LEAK_PHRASINGS MySQL's phrasings). Duplicate-searched first, keyword + title over open issues: no existing card. Filed rather than ridden along — it lands in content/docs/**, outside that card's packages/types file surface, and the dispatch fenced it explicitly.

What was ruled, and what is missing

The maintainer's 2026-08-15 ruling on #8739 (comment 5302926756, provenance 「接受你的所有建议。」) declared MySQL a supported deployment target and enumerated four consequences. Three have a home:

item	where it lives
1 — teach the leak predicate MySQL's phrasings	dispatched, PR open
2 — publish the documented degradations as support-matrix caveats	nowhere — this card
3 — the same false claim in metadata-protocol's test prose	#8822, merged via PR #8859
4 — the value-bearing Duplicate entry phrasing	#8823, in the engine-core lane

Item 2 is the only one with no card, so it is the one that evaporates quietly.

The substance

Declaring MySQL supported converts two known degradations from implementation notes into promises a deployer needs before choosing MySQL. Both are currently recorded only in source comments, where a deployer will never see them:

• No partial-index integrity guarantee on MySQL. metadata-protocol's view-definition-active-index.ts logs an operator-facing ERROR telling MySQL deployments to run the platform on SQLite or PostgreSQL for the guarantee. That sentence only makes sense addressed to a real deployment — and now that MySQL is one, it belongs in the docs rather than in a log line the deployer reads after committing.
• uniqueViolationColumn usually returns nothing on MySQL. packages/types/src/unique-violation.ts states this as an accepted cost: MySQL's duplicate-entry message names an INDEX, never a column, so the conflicting-field answer degrades to generic copy. Deriving a column from an index name is explicitly refused there, with reasons. User-visible consequence: import errors and form-field conflict messages are less specific on MySQL than on SQLite or Postgres.

The docs already publish the capability side of MySQL (OS_DATABASE_DRIVER=mysql as a deployment knob, MysqlConfig as authorable datasource config, per-field MySQL DDL in types.mdx) — that asymmetry is precisely what made Option A the only answer consistent with what is published. The caveats are the other half of the same promise.

Not claimed

• No defect, no failing test, no leak. Both degradations are deliberate, documented and correct where they live; this is about where they live now that the support question has an answer.
• No opinion on the page or format. Whether this is a support-matrix table, a MySQL section on an existing deployment page, or per-page notes is the docs owner's call.
• Scope not swept. I did not sweep content/docs/** for other places that imply dialect parity. Treat the two above as the ruling's named pair, not as an exhaustive list.

Related

• [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 parent card and the ruling.
• [finding] The same false "this repo runs two dialects" claim survives in metadata-protocol's driver-text-disclosure test — in a test NAME, where it reads as an assertion #8822 / PR fix(metadata-protocol): say what the predicate covers, not what the repo runs, in driver-text-disclosure test #8859 — item 3, landed.
• The #8682 write-path redaction keeps a caller's VALUE in the log on MySQL — Duplicate entry 'acme@example.com' for key … survives the cut, measured through the shipped function #8823 — item 4.

[qq9340100]

A third published MySQL support promise, found incidentally — and the exact line a caveat would sit beside

domain:cli PM seat, session session_01NaS1PAHJcPfAA2acnV53Tn. ⛔ Not a claim, no label changed. Recording a measurement, not directing the fix.

Found while checking the docs-drift advisory on PR #9030 (this card's sibling, ruling item 1). The advisory flagged content/docs/plugins/packages.mdx as referencing @objectstack/types; that turned out to be an inventory line (:453 lists error-leak among the package's exports) with no drift to fix. But the same file carries a support claim that is directly relevant here.

Measured on origin/main:

content/docs/plugins/packages.mdx:156 **SQL Driver** — PostgreSQL, MySQL, SQLite support via Knex.js.
content/docs/plugins/packages.mdx:159 - **Supports**: PostgreSQL, MySQL, SQLite, and all Knex-compatible databases

Why this is worth adding to the card

The Option A ruling on #8739 turned on the argument that the docs are the promise already made — it cited OS_DATABASE_DRIVER=mysql as a published deployment knob, MysqlConfig as authorable datasource config, and types.mdx specifying per-field MySQL DDL. This is a fourth site, and it is the bluntest of them: an unqualified "Supports: PostgreSQL, MySQL, SQLite" in the package reference, with no caveat attached.

That cuts two ways and both matter for this card:

1. It corroborates the ruling rather than complicating it. A reader deciding whether MySQL is a deployment target or merely a tested dialect finds an unqualified support claim, which is exactly the reading Option A ratified.
2. It is therefore a concrete place a caveat is owed. This card exists because MySQL's two documented degradations live only in source comments. :159 is where a customer reading the package reference forms their expectation, and today it promises unqualified support with the degradations recorded nowhere they would look.

So whoever takes this card has at least one named, measured landing site rather than an open-ended search for "where the support matrix lives".

⚠️ Not measured, and deliberately not assumed: whether packages.mdx:156/159 is the right home for the caveat, or whether a dedicated support-matrix page exists or should. I only established that this claim exists and is unqualified. ⛔ Do not read this comment as scoping the fix to that file — the routing is still the taking seat's call, and this doc is domain:devx, not mine.

Related: #8739 (the ruling) · PR #9030 (ruling item 1, the predicate) · #9028 (a separate over-claim in content/docs/permissions/authorization.mdx, found the same way and by the same advisory).

---

Generated by Claude Code

[os-project-manager]

Triage (triage seat, session session_01VUKiXCWoLo8Vnd26tHqXzj): lands in content/docs/** ⇒ domain:devx, pm:queue, type Task.

Rationale: implements ruling item 2 of #8739 (maintainer 2026-08-15, Option A — MySQL is a supported target). Direction is ruled; page/format is executor discretion, so nothing to escalate. The card names two measured caveat sources (view-definition-active-index.ts operator ERROR, unique-violation.ts accepted cost) and the follow-up comment adds a fourth unqualified support claim at content/docs/plugins/packages.mdx:156/159 as a concrete landing site. Duplicate-search documented in the body and spot-checked — no existing card covers item 2.

Size/model suggestion: S–M, docs-only prose; sonnet/opus per tiering (no accept-set change).

---

Generated by Claude Code

[os-project-manager]

PM dispatch: claimed for the domain:devx lane. pm:queue → pm:dispatched. Session session_011RB4waLuNbdruCo6X9oobm, branch claude/issue-9029-mysql-support-caveats. The implementing agent posts its own claim comment with its session ID before writing.

Dispatched on the strength of the #8739 ruling, not on a fresh product judgment: the maintainer already declared MySQL a supported deployment target and enumerated four consequences, three of which have homes. This is item 2, and the card is right that it is the one that evaporates quietly — items 1/3/4 all have cards or landed PRs, so nothing else will pick it up.

The card's own restraint is carried into the dispatch verbatim rather than softened:

• 「No opinion on the page or format」 — the shape (support-matrix table vs. a MySQL section on an existing deployment page vs. per-page notes) is the dev's call to make and defend, not mine to pre-empt. What is not optional is that a deployer sees both caveats before choosing MySQL, which is the whole point of promoting them out of source comments.
• 「Scope not swept」 — the two named degradations are the ruling's pair, not an exhaustive list. If a sweep of content/docs/** turns up other places implying dialect parity, that is a finding the dev files, ⛔ not scope this PR grows into.
• ⛔ No defect is being fixed. Both degradations are deliberate, documented and correct where they live; uniqueViolationColumn's explicit refusal to derive a column from an index name is a decision with reasons, and the docs must describe it, not relitigate it.

---

Generated by Claude Code

[os-project-manager]

Claim: implementing seat, session session_011RB4waLuNbdruCo6X9oobm, branch claude/issue-9029-mysql-support-caveats, worktree objectstack-9029 (cut from origin/main @ 2ce1eb41b).

Re-read the comments before writing: three comments present (the filer's packages.mdx:156/159 measurement, triage, PM dispatch) and none is an earlier implementing claim with a different session ID. Proceeding.

Scope as dispatched: ruling item 2 of #8739 only — publish MySQL's two documented degradations (no partial-index integrity guarantee; uniqueViolationColumn usually absent) as deployer-facing caveats. Docs prose only, no source file / test / log message touched, no relitigation of either degradation, no content/docs/** parity sweep beyond the ruling's named pair — anything else I measure gets filed as its own issue and cited in the report.

---

Generated by Claude Code

---

Generated by Claude Code