Verifies the user-facing posture in ADR-0002 §"User-facing
posture": no occurrence of SQLite, sqlite, rusqlite, STRICT,
or PRAGMA may appear in any user-reachable string.
The audit's mechanical sweep of `src/` confirmed the
codebase already conforms — every appearance of those
tokens is in either:
- code comments / module-level docstrings (allowed by
ADR-0002 explicitly),
- DDL strings sent to the engine (not displayed to the
user),
- internal field/function names like `sqlite_type` /
`sqlite_strict_type` (code identifiers, not user-visible).
The previous session removed the last known leak in
`do_add_column`. To stop a future change from quietly
re-introducing one, this commit adds a regression test
file covering a representative set of user surfaces:
- `cli::HELP_TEXT` (`--help` banner).
- The in-app `help` command output.
- DSL parse errors for a battery of failing inputs
(column-name-first typo, unknown type token, mutually
exclusive flags, missing clause, garbage).
- `DbError::friendly_message()` for realistic Sqlite,
Unsupported, and InvalidValue payloads — the surface the
runtime forwards via `AppEvent::DslFailed`.
The forbidden-token list lives in one place
(`engine_vocabulary_audit.rs::FORBIDDEN`) so future audits
can extend it. Failure messages name the leaking token and
its byte offset so a regressing edit pinpoints itself.
Out of scope (and called out in the handoff for separate
work): the H1 friendly-error layer that translates the
remaining engine error wording into pedagogical English.
That needs its own ADR. The local
`friendly_change_column_engine_error` wrapper (db.rs §2354)
is the prototype.
537 -> 541 passing (4 new), clippy clean.
claude@clouddev1