[cevheri]

Three BACKLOG entries close. Every claim was measured against a live engine and then verified in Chrome on a production build, and the browser found a defect three passes of gates did not.

S1 — a commented-out DROP became a statement the route ran

statement-splitter.ts walked spans itself instead of using spans.ts, so it disagreed with every other reader about where a statement ends — and unlike them, its disagreement is executed: /api/db/multi-query runs each fragment it returns.

postgres 18, the entry's own shape:
  /* a /* b */ ; DROP TABLE s1_victim; -- */ SELECT count(*) FROM s1_victim
  psql        -> 1 row, survived = 2        (block comments NEST: one statement)
  old reading -> 3 fragments, #2 = `DROP TABLE s1_victim`, and the route ran them
  the gate    -> silent, because it read the whole editor text, where the
                 operative keyword is nothing at all

The splitter now reads through the shared reader under the caller's dialect, and isDangerousQuery asks about the same fragments the runner will run. Every caller passes a dialect, including the agent's own draft reader.

The same defect survived on three shipped engines, because SqlGrammar could not carry CQL's third comment form. // is a line comment on Apache Cassandra 5.0.9, ScyllaDB 2026.2.4 and ClickHouse 26.7.1 — each probed with a control arm, so "the statement still ran" cannot be mistaken for "the ; was hidden" — and is refused or is an operator everywhere else (PostgreSQL 18: operator does not exist: integer // integer). SELECT ... // note; DROP ... was therefore cut into a read and a runnable bare DROP out of text the server reads as one statement.

doubleSlashComment is now a grammar fact, which the splitter got for free by reading through spans.ts — and it closed a silent ClickHouse bug in passing:

ClickHouse 26.7.1, prepareQuery(..., limit 5)
  before: SELECT number FROM numbers(1000) // note LIMIT 5   -> 1000 rows, wasLimited: true
  after:  SELECT number FROM numbers(1000) LIMIT 5 // note   ->    5 rows

A third reader, found in the browser and by no gate. QueryEditor.getEffectiveQuery picks the statement at the cursor with raw lastIndexOf(";") — no spans, no dialect, not even a string-literal check — and it decides the text that is sent. On the buffer above the request body carried a line comment plus the SELECT, and the grid read 0 rows where psql answers 2. It now reads through the shared splitter, so SplitStatement carries offsets. Re-verified in Chrome after the fix: survived = 2, 1 row, and the request still goes to /api/db/query.

One pinned policy changed deliberately: with the caret in an empty statement between two ;, the old reader fell through to the whole buffer — so "run the statement I am in" silently ran every statement, which with a DROP in the second one is a destructive surprise. It now runs the statement the caret is immediately after.

U9 — a control that named an operation the page behind it could not run

Four providers pointed vacuumAction at something that is not a vacuum (ClickHouse Optimize Table, SQL Server and Oracle Rebuild Indexes, Couchbase Compact), and MySQL rendered BaseDatabaseProvider's default "Vacuum Table" although its operations are analyze/optimize/check/kill.

Each provider now declares, next to the operation, which MaintenanceType its wording stands for and what kind of target it takes. #427's generic label-to-operation mapping is not repeated — it handed Oracle a table where ALTER INDEX wanted an index and answered ORA-01418 on every click, and was reverted. Oracle's per-table optimize was rebuilt to read USER_INDEXES WHERE TABLE_NAME = :t and proven against the live engine:

Oracle AI Database 26ai Free Release 23.26.2.0.0, through the provider
  old statement  ALTER INDEX "U9_PROBE" REBUILD    -> ORA-01418
  new            optimize U9_PROBE                 -> success, rebuilt 2 of 2
                 an UNUSABLE index                 -> VALID
                 LAST_DDL_TIME moved for the named table's indexes and no others

All three surfaces gate and title from the declaration — the monitoring Tables tab, the admin Operations tab and the schema explorer's row menu, which was still offering SQLite "Vacuum Table" for one table while the Tables tab correctly withheld it. Browser-verified: MySQL's Operations tab reads Run Optimize / Optimize Tables, with no vacuum card and no reindex card; PostgreSQL, which does vacuum, is unchanged.

Then the refusals those new controls exposed. MySQL discarded OPTIMIZE/CHECK TABLE's result rows, so a missing table answered "OPTIMIZE completed successfully" and CHECK's verdict — the entire point of the control — never reached anyone. Oracle reported success for a target the catalog does not know, and for a table where every index rebuild was refused (measured with a READ ONLY tablespace: success: true, "rebuilt 0 of 2", ORA-01647 discarded).

And none of it reached the user: use-monitoring-data toasted success on any HTTP 200 and the audit event hardcoded result: "success", so a refused operation showed a green tick reading "OPTIMIZE failed: ..." and was logged as completed. Verified end to end in the browser:

POST /api/db/maintenance {type:"optimize", target:"no_such_table_r10"}
  -> 200 {"success":false,"message":"OPTIMIZE failed: mysql.no_such_table_r10:
          Table 'mysql.no_such_table_r10' doesn't exist"}
  audit page: Total 1 ops, Success 0%      (before: 100%)

DOC2 — a copy-paste recipe the API server rejects

--set extraEnv[0].value="true" renders value: true, an unquoted YAML boolean, while core/v1.EnvVar.value is a string. Reproduced with helm v4.1.3 and the real chart, parsing the rendered value rather than eyeballing the quotes. Nothing catches it earlier: values.schema.json types extraEnv as plain objects, so helm lint --strict passes.

Both recipes use --set-string, plus two more coercion sites the entry did not name (ingress.annotations is a map[string]string; limit-rpm=120 rendered as an integer) and eleven bracket arguments that zsh globs away before helm is reached. A static lint over the README's bash fences pins the class, non-vacuous by mutation.

The chart is a released version, so a packaged-file change costs version: 0.1.50 and the operator mirror — the operator ships its own copy of this README and was still carrying the broken recipes.

Recorded rather than fixed

• U20 — the maintenance API validates that an operation exists, not that it can take the target, so POST {type:"vacuum", target:"users"} still vacuums the whole SQLite file. Admin-gated; the invariant just lives in one layer only.
• U21 — MSSQL and MongoDB declare check globally runnable and there is no card copy for it. Inventing copy for five providers without measuring what a whole-database DBCC CHECKDB costs is the mapping Redis schema-explorer actions generate MongoDB syntax: nothing the sidebar produces can be executed #427 reverted.
• U22 — TableItem's items are deep links, so "the operation takes a table" and "the destination renders the control" are different questions.

Gates

Gate	Result
bun run format	clean (943 files)
bun run lint	0 errors
bun run typecheck	clean
bun run knip	clean
bun run chart:check	chart 0.1.50 / appVersion 0.13.4 in sync
tests	0 fail; 33/33 component groups
coverage	100.00% (42786/42786 lines)
bun run build	exit 0
build:lib + attw	exit 0
gitleaks	1 commit scanned, no leaks

One note for review: the first implementation pass was killed mid-edit by a session limit and left the tree not compiling (Oracle called a method that was never written). It was finished from that point, and the three reviews then ran against the completed work — the CQL residual, the success-reporting defects and the chart blocker all come from those reviews rather than from the original passes.

[sonarqubecloud]

Quality Gate passed

Issues
4 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud