A query may contain a semicolon again. The multi-statement guard scanned the whole body for a bare ;, so WHERE text LIKE '%;%', SELECT 'a;b' and any query ending in a -- comment; with one came back as multi-statement — refused before the engine ever saw them.
Nothing was protected by that. The write barrier is ?mode=ro, and the guard exists to give a clear early error; a false refusal closed no hole and cost a valid question — on a real channel, the only query that finds the posts containing a semicolon. sqlite3.complete_statement now decides what terminates a statement: SQLite's own quote- and comment-aware answer, stdlib, so the query path stays importable without a client and grows no SQL parser of its own.
Still refused, unchanged: SELECT 1; DROP TABLE posts, and SELECT 'a;b'; DROP TABLE posts — a semicolon inside a literal hides nothing about the one after it.
slop-writer --version also answers now, reading the same string the MCP handshake reports and the skill's frontmatter copies.
A patch release: no tool argument, schema or skill file changed.
Fixes #57.