[fujibee]

What

SQLite 3.53.4 and 3.54.0's CLI broke two assumptions agmsg's storage layer made about the older CLI (#1645):

1. storage_init (scripts/drivers/storage/sqlite.sh) sent its whole schema transaction as a single multi-statement command-line argument, assuming -bail would stop at the first error before the trailing PRAGMA user_version stamp. On the newer CLI a failing statement no longer stops that argument form, so a broken init could still stamp the current revision. Fix: feed the same statements to sqlite3 on stdin instead (every top-level statement already ends its own physical line in this SQL, which is what the CLI's -bail honors reliably on every version tested).
2. A lock-timeout giveup reports exit code 1 instead of 5 on the newer CLI, bypassing agmsg_sqlite()'s busy-specific diagnostic. Fix: agmsg_sqlite() now also classifies busy by matching "database is locked" in stderr (the same text match the recording variant already used) and normalizes the return code to 5 when the raw exit code did not already say so.

Survey of other -bail call sites

Checked every -bail use under scripts/ for the same "single command-line argument carrying more than one statement" shape:

Site	Form	Affected?
sqlite.sh storage_init (line ~165)	was: multi-statement argv	yes — fixed here
sqlite.sh _sqlite_exec_stdin (line 73)	stdin, one statement per line	no
sqlite.sh storage_send (line ~337)	stdin, one statement per line	no
sqlite.sh storage_import (line ~618)	stdin, one statement per line	no
sqlite-sync.sh _sqlite_sync_commit_chunk (line 66)	stdin, one statement per line	no
sqlite-sync.sh ack/pull batch via _sqlite_exec_stdin (lines 959, 1652)	stdin, one statement per line	no
sqlite-sync.sh apply-page sql_file (lines 1419, 2021)	file piped on stdin, one statement per line	no

Also found 4 sites that build a multi-statement BEGIN IMMEDIATE ... COMMIT block and pass it as a single argv string without -bail at all (sqlite-sync.sh lines ~431, ~520, ~1829, ~1858 — schema migration and the resync/read-block/read-unblock assert blocks). These never relied on -bail's stop-at-first-error contract in the first place; they validate the outcome via a CHECK-constrained temp-table assert plus the exit code, a different design unaffected by this CLI change. Left as-is.

Testing

Existing tests/test_storage.bats cases only (no new tests):

• storage: a failing init batch leaves the OLD revision, never a new stamp over a broken schema (#1001)
• storage: a call that gives up after the busy timeout says so on stderr, and a quiet store says nothing (#1001)

Both confirmed green on this machine's SQLite 3.51.0 and, separately, on SQLite 3.53.4 (downloaded standalone from sqlite.org into a scratch directory and prepended to PATH only for that test run — nothing installed system-wide). Full tests/test_storage.bats (31 cases) also green on both versions.

[fujibee]

Updated per review: agmsg_sqlite() no longer uses mktemp/cat/rm to capture stderr (3 extra forked processes per call on this hot path). Rewritten with the standard fd-juggle (3>&1 outer, 1>&3/2>&1 inside the command substitution) — stdout streams straight through, stderr lands in a shell variable, no extra process beyond sqlite3/sed.

Verified:

• Existing 2 tests/test_storage.bats cases, and the full 31-case file, green on both SQLite 3.51.0 and 3.53.4 (same throwaway setup as before).
• Negative control: disabling just the busy-text normalization re-reds the busy test on 3.53.4 at the expected assertion.
• tests/test_watch_process_count.bats: 46 forked processes per idle poll cycle, identical to main (checked against a clean origin/main worktree) — no increase.

[fujibee]

Fixed the whole-line match gap: `agmsg_sqlite()`'s busy check now uses `_agmsg_sqlite_err_is_busy()`, matched against the exact whole lines sqlite3 itself emits for a real lock timeout (collected by reproducing one on both argv and stdin input, on both SQLite 3.51.0 and 3.53.4), instead of a bare substring test.

Counter-example checked by hand, not added as a test: a `SELECT` against a table literally named `database is locked` reports "no such table: database is locked" and stays rc=1 on both CLI versions after the fix (it previously misclassified as busy, rc=5).

Verified:

• Existing 2 tests/test_storage.bats cases, and the full 31-case file, green on both SQLite 3.51.0 and 3.53.4.
• The counter-example above reproduced by hand on both versions, rc=1 unchanged.

[fujibee]

Fixed: _agmsg_sqlite_err_is_busy()'s per-line patterns anchor on `$`, and Windows' sqlite3.exe ends stderr lines with \r\n, so the trailing \r sat between "locked" and the anchor and a real busy line went unmatched. Stripped with a builtin substitution (`${1//$'\r'/}`) used only for the match itself — no external command added, and the stderr re-emitted to the caller is untouched.

Checked by hand, no new test:

• plain LF busy line: matches
• the same line with a trailing \r (CRLF): matches
• the busy line embedded as one of several lines in a multi-line stderr (LF and CRLF): matches both
• the table-named-"database is locked" counter-example from the prior round: still does not match, with or without \r

Existing 2 tests/test_storage.bats cases, and the full 31-case file, still green on both SQLite 3.51.0 and 3.53.4.

[fujibee]

Fixed the CI red: storage_init's schema SQL now goes through a heredoc redirect (`<<SQL ... SQL`), not a `printf | agmsg_sqlite -bail` pipe. A pipe's right-hand side runs in a subshell, so the escape probe's memo dies with it — same as every other piped call in this codebase, which is why they all carry `agmsg_sqlite_warm` directly above their pipe. This one's warm sat ~100 lines above the actual pipe (before the SQL string began), so tests/test_remote_sync.bats's #462 scan (warm within two lines of a `| agmsg_sqlite`) counted it as unwarmed and both #462 cases went red.

A heredoc runs in the current shell, so there's no subshell to lose the memo to and no warm call needed at all — this removes the pipe (and the test's premise) rather than working around it. Delimiter is unquoted so `${_AGMSG_STORAGE_SCHEMA_REV}` still expands; confirmed nothing else in the block has a `$` or backtick for that to catch.

Verified:

• tests/test_remote_sync.bats Add cmd.gemini.md / cmd.antigravity.md skill templates and install.sh registration #47/Refactor delivery.sh into per-agent-type drivers #48 (the perf: agmsg_sqlite re-runs the -escape probe on every call (command substitution defeats the memo) — 2x sqlite3 spawns on every DB access #462 scan and its mutation control), green.
• The two tests/test_storage.bats SQLite CLI compatibility: failed init can stamp the new revision, and busy diagnostics expect an unavailable exit code #1645 cases, green on both SQLite 3.51.0 and 3.53.4.
• Full tests/test_storage.bats (31) and tests/test_remote_sync.bats (55), green.