# Session handoff — 2026-05-22 (31)
Thirty-first handover. This session shipped, in order:
1. **Finished the advanced-mode completion interlude** left open by
handoff 30 — the **F5** core `walk_seq` fix, plus a follow-up
`walk_repeated` fix and a candidate-ordering reversal that grew
out of manual testing.
2. **Advanced ADR-0033 Phase 3 through sub-phases 3c, 3d, 3e** —
SQL `INSERT … SELECT`, `shortid` auto-fill, and SQL `UPDATE`.
The next session should **start sub-phase 3f** (`DELETE` +
cascade summary) — the largest remaining DML sub-phase — which is
why we're handing off first. See §4 for a key 3f heads-up.
## §1. State at handoff
**Branch:** `main`. **Tests: 1524 passing, 0 failing, 1 ignored.**
**Clippy:** clean (`cargo clippy --all-targets -- -D warnings`).
**Commits this session** (newest first). `origin/main` is at
`6ff9144` (3c), so the **last three are local-only**:
```
53808ed grammar+db: 3e — SQL UPDATE grammar + execution (ADR-0033 §2) (local)
18d34d0 db: 3d fix — don't let shortid auto-fill mask INSERT arity mismatch (local)
78ad476 db+grammar: 3d — shortid auto-fill for SQL INSERT (ADR-0033 §6) (local)
6ff9144 grammar: 3c — INSERT … SELECT row source (ADR-0033 §4) (origin/main)
7f68a53 walker+completion: surface list trailing-optionals + identifiers-first ordering (ADR-0022 Amendment 2)
43c49f4 walker: F5 — drop preceding-clause keywords from committed-child Incomplete sets
```
(Unpushed commits are a normal working state; pushing is the
user's step — do not prompt about it.)
## §2. THE process lesson (read this first)
This session's clearest signal is about **Devil's Advocate
discipline**, not code. Three times the lead produced a DA
"verdict" that merely restated the exit gate — and three times the
*user* had to prompt before a genuine adversarial pass happened.
Each real pass then found something concrete:
- "What about more than one shortid in a row?" → an **untested**
multi-shortid path (it worked, but had zero coverage).
- "Did you check with the DA?" → the **arity-masking bug** (3d
auto-fill silently dropped extra columns / could read out of
range). Real correctness bug; fixed in `18d34d0`.
- "Sounds like the DA had nothing to add." → the **untested render
guard** in 3e (`handle_dsl_update_success`).
**Takeaway for the next agent:** do the adversarial work
*proactively* and *in writing*, and make it produce a failing test
or a concrete change — not a paragraph that clears everything.
"The exit-gate tests pass" is not a DA review. Attack the code:
untested branches, edge cases the happy-path tests skip, behaviour
that diverges from the non-SQL path, things that only break when an
input is malformed. A clean PASS with no findings on a non-trivial
sub-phase should itself be suspicious.
## §3. Phase 3 — what shipped (3c / 3d / 3e)
Controlling docs (read both):
- `docs/adr/0033-sql-dml-grammar.md` — the decision (read
**Amendment 1** for the dispatch mechanism).
- `docs/plans/20260520-adr-0033-phase-3.md` — build order
(3a–3k), per-sub-phase exit + DA gates.
### 3c — `INSERT … SELECT` (`6ff9144`)
Grammar-only: the INSERT row source became a
`Choice(VALUES_CLAUSE, Subgrammar(&sql_select::SQL_SELECT_COMPOUND))`.
`SQL_SELECT_COMPOUND` is itself a `Choice` that admits a leading
`WITH`, so the R4 (WITH-prefixed) row source parses for free. No
worker change — `do_sql_insert` already executes the validated SQL
and the engine handles insert-from-query.
### 3d — `shortid` auto-fill (`78ad476`) + arity fix (`18d34d0`)
`Command::SqlInsert` gained `listed_columns` and `row_source`,
extracted in `build_sql_insert` from the matched path (the row
source is found by the **first `values`/`select`/`with` Word
token**, which is path-based so a string literal like `'select'`
can't be mistaken for the keyword). `plan_shortid_autofill`
(`db.rs`) implements the **user-chosen Option B**: when the column
list omits a `shortid` column, materialise the row source by
running it as a query, generate a distinct id per row via the
existing `generate_shortid_batch` (deduped against stored values),
and reconstruct a parameterised multi-row INSERT. Uniform for
VALUES and SELECT; handles multiple omitted shortids (one batch per
column). `serial` stays engine-filled via rowid. `history.log`
keeps the original line, never the rewrite (§11).
**Arity guard (`18d34d0`):** the auto-fill path read exactly
`listed_columns.len()` cells per row — a column/value arity
mismatch silently dropped extra columns or read out of range. Now:
if the materialised statement's `column_count() != listed_count`,
skip auto-fill and run verbatim so the engine reports the mismatch
(a friendly pre-flight is 3i).
Minor deviation from the plan: the plan's 3d step said "turn on
`writes_user_listed_column`". We did **not** flip that flag — the
worker only needs the column *names*, collected by role in
`build_sql_insert`. The flag drives completion-narrowing of VALUES
against the listed columns, which nothing needs yet. It remains
`false`; flipping it is a separate completion enhancement, not a
blocker.
### 3e — SQL `UPDATE` (`53808ed`)
New `src/dsl/grammar/sql_update.rs`: `SQL_UPDATE_SHAPE =
SET col = sql_expr (',' …)* [WHERE sql_expr] [';']`. No
`--all-rows` rail (ADR-0030 §12). `Command::SqlUpdate { sql,
target_table }`, `Request::RunSqlUpdate`, `do_sql_update` (execute
verbatim, re-persist target, history). 3e surfaces the
**affected-row count only**; precise rows are RETURNING (3g).
**Two findings that matter for later sub-phases:**
1. **Cross-cut diagnostics are NOT automatically free.** The
schema-existence + predicate-warning passes (`mod.rs`) build
their scope from Tables idents whose **role is `"table_name"`**
(the pre-pass at `schema_existence_diagnostics`). A bespoke role
(`update_target_table`) left the SET/WHERE columns unchecked
(`diag_keys` returned `[]`). Fix: the UPDATE target uses the
shared `"table_name"` role. **3f's DELETE target must do the
same** to get the predicate diagnostics on its WHERE for free.
2. **Render guard.** A column-less `UpdateResult` would render a
misleading `(no rows)` band. `handle_dsl_update_success` now
skips `render_data_table` when `result.data.columns.is_empty()`.
The DSL UPDATE always has columns, so it's unaffected. Covered
by app-level tests both ways.
`sql_select::WHERE_CLAUSE` is now `pub(crate)` so the DML
statements reuse the exact predicate clause.
## §4. Sub-phase 3f — the next job (DELETE + cascade)
Per the plan (`docs/plans/20260520-adr-0033-phase-3.md`, "Sub-phase
3f"): new `src/dsl/grammar/sql_delete.rs` (`DELETE FROM table
[WHERE] [';']`), `Command::SqlDelete` / `Request::RunSqlDelete` /
`do_sql_delete`, cascade-summary pre-count (ADR-0033 §7), the
`format_cascade_summary` formatter **shared** with the DSL
`do_delete`, and **multi-table persistence** (target + every
cascade-affected child).
**Heads-up — the WHERE-byte-extraction problem is tractable for
DELETE.** In 3e I worried that a flat token path can't distinguish
a statement-level WHERE from a subquery's WHERE (a `where` token
can appear before *or* after the statement one). That ambiguity
comes from UPDATE's `SET` clause possibly holding a subquery-with-
WHERE *before* the statement WHERE. **DELETE has no SET** — nothing
before the statement WHERE can contain a subquery — so the
statement WHERE is simply the **first `where` Word token after the
target table**, and the predicate text is `source[where_start..]`
(trim trailing `;`). The R2 invariant
(`DELETE … WHERE x IN (SELECT … WHERE …)`) is fine: the nested
subquery WHERE is *inside* the predicate, which is exactly what the
cascade pre-count wants to inject. So mirror the
`build_sql_insert` row_source / `build_sql_update` extraction: find
the first `where` token, capture the clause text into
`Command::SqlDelete`, and inject it into
`SELECT FROM ` for each child
pre-count. When there is no WHERE, the pre-count is unbounded
(all target rows).
Other 3f gotchas from the plan's DA gate: the cascade pre-count
must run **before** the DELETE (the rows being counted are the ones
about to vanish); cascade-affected child CSVs must all be
re-persisted; and the SQL path's per-relationship summary must
match the DSL path's on the same schema/data (shared formatter).
## §5. Established patterns (reuse these in 3f–3i)
- **Dev entry word per sub-phase.** SQL DML is isolated behind
`sqlinsert` / `sql_update` (and `sql_delete` next) entry words,
`CommandCategory::Advanced` in `REGISTRY`
(`src/dsl/grammar/mod.rs`). The `build_sql_*` ast-builder
reconstructs the real keyword (`insert`/`update`/`delete`) +
matched tail. **3j removes all dev words** and makes
`insert`/`update`/`delete` shared DSL/SQL entry words; 3j must
also de-dup the completion entry-word lists once a word appears
twice in `REGISTRY` (flagged in ADR-0033 Amendment 1).
- **`table_name` role for any target whose WHERE/SET columns need
schema diagnostics** (see §3e finding 1).
- **Static-vs-const in grammar files.** A `Node` referenced *by
value* in a `static [...]` array must be `const` (so it inlines);
a `Node` referenced via `&NODE` can be `static`. Getting this
wrong gives "cannot move out of a shared reference" (hit twice
in 3e).
- **Worker result + render.** SQL DML reuses the DSL
`CommandOutcome::{Insert,Update,Delete}` and the
`handle_dsl_*_success` renderers. Any new `Command` variant must
be added to: `command.rs` `verb()` + `target_table()`, the
`runtime.rs` dispatch, `app.rs` `build_translate_context`, and
the `tests/typing_surface/mod.rs` `command_kind_label` match
(all are non-exhaustive checks that will fail to compile until
covered — a useful forcing function).
## §6. Escalations settled this session (do not re-litigate)
- **Identifiers-first candidate ordering** (ADR-0022 Amendment 2):
schema identifiers sort *before* keywords, globally — the user
explicitly chose this over the handoff-14 keywords-first
invariant, after seeing that long SQL keyword runs pushed column
names off the single-row, window-scrolled candidate line. A
**two-line hint box** is recorded as a deferred follow-up.
- **3d SELECT shortid strategy = Option B** (materialise + dedup +
reinsert), user-confirmed.
- **`auto_column_overridden` WARNING stays INSERT-only** (the plan
default). 3e did not extend it to UPDATE; if 3f/3i wants to, the
plan says escalate.
## §7. Still deferred (tracked, not lost)
- **RETURNING** (3g) — precise DML row output; 3e/3f surface counts
(+ cascade summary) only until then.
- **UPSERT `ON CONFLICT`** (3h), **diagnostics** `insert_arity_mismatch`
/ `auto_column_overridden` / `not_null_missing` (3i),
**dispatch wiring / dev-word removal** (3j), **verification
sweep** (3k).
- **Old-project migration** (from handoff 30 §4) — the pre-
`check_expr` 3-column `__rdbms_playground_columns` schema; the
user deferred a migration story to "the end". Targeted fix when
the migration framework (ADR-0015 Iter 6) lands.
- **Two-line hint box** (ADR-0022 Amendment 2).
- **`writes_user_listed_column`** flag (see §3d) — VALUES-against-
listed-columns completion narrowing.
## §8. Process pins (unchanged, still binding)
- **Confirm every commit.** Propose the message and wait for the
go-ahead. No auto-commit at sub-phase gates.
- **Push is the user's step.** Never push; never prompt about it.
- **No AI attribution** in commits (global rule).
- **Test-first.** Reproduce a bug with a FAILING test before
fixing; for features, exit-gate tests before "done". This is
also how the real DA findings surfaced this session — write the
cross-cut/edge test and watch it fail.
- **Core walker changes** (`walk_seq` / `walk_choice` /
`walk_repeated`) need explicit user OK before coding. (F5 and the
3d-era `walk_repeated` change both went through this.)
- **Escalate ambiguity; never classify work out of scope without
user confirmation.**
## §9. How to take over
1. **Read, in order:** this file →
`docs/adr/0033-sql-dml-grammar.md` (esp. §7 cascade + §2
UPDATE, already shipped) →
`docs/plans/20260520-adr-0033-phase-3.md` "Sub-phase 3f" →
`CLAUDE.md`.
2. **Baseline:**
```
cargo test # expect 1524 passing / 0 failing / 1 ignored
cargo clippy --all-targets -- -D warnings # clean
```
3. **Start 3f** per §4. Mirror `sql_update.rs` for the grammar and
`do_sql_update` for the worker shell; the new work is the
cascade pre-count + the shared `format_cascade_summary` refactor
+ multi-table persistence. Use the `table_name` role for the
DELETE target. Capture the WHERE clause text via the first
`where` token (tractable for DELETE — §4).
4. **Do the DA pass for real** (§2). On a sub-phase this size,
expect to find at least one untested branch or edge case;
if you don't, look harder.
5. **Escalate** anything not settled in ADR-0033 / the plan.