docs: ADR-0036 revised to surgical "validate-and-retain"; +X4/X5 open questions

Narrow ADR-0036 from "bind literals via the DSL path" to "validate literal
values (shared validators) + retain them; execute verbatim, keep auto-fill
and command identity mode-specific" — after a concrete auto-fill difference
(non-PK serial) confirmed the modes aren't identical even for single-row
literals. Augments (no longer supersedes) ADR-0030 §4 / ADR-0033 §10;
Amendment 3 stands. README + forward-notes on 0030/0033 updated. Records
requirements.md X4 (serial auto-fill — possible bug) and X5 (framework
cohesion / share-mechanics-not-commands).

docs/requirements.md

@@ -576,6 +576,38 @@ handoff-14 cleanup; 449 after B2/C2.)
 - [~] **X3** Accessibility: TUI screen-reader support is
   best-effort and not a v1 commitment; revisit if user need
   emerges.
+- [~] **X4** Auto-fill semantics differ between simple and advanced
+  mode — **possible bug, to investigate** (raised 2026-05-26). The
+  simple-mode insert (`do_insert`, `db.rs`) auto-fills an omitted
+  **non-PK `serial`** column with `MAX(col)+1` *and* generates
+  `shortid`s; the advanced-mode SQL insert (`plan_shortid_autofill`)
+  auto-fills **only `shortid`** and does **not** do non-PK `serial`
+  MAX+1. The `shortid` distinction is intentional; the non-PK-`serial`
+  gap looks unintended (no obvious reason advanced mode should skip
+  filling a `serial`). Decide whether advanced mode should match
+  simple mode's serial auto-fill (likely yes) or whether the
+  difference is deliberate, and align ADR-0018 accordingly. Left
+  untouched by the ADR-0036 value-validation work (which is surgical
+  and does not change auto-fill).
+- [~] **X5** Framework cohesion / restructuring — **strategic,
+  revisit later** (raised 2026-05-26). The grammar/execution
+  framework (lexer → walker `Node`s → unified grammar tree → typed
+  `Command`s → executors; ADR-0023/0024 and everything layered on
+  since) grew organically from the original grammar outline and now
+  reuses + mixes elements across many levels without a *cohesive
+  written specification* of what the framework comprises, which
+  elements are meant to be reusable, and where the boundaries sit for
+  the recurring "reuse vs create new" decision. A concrete symptom:
+  commands are coupled tightly enough to their execution that reusing
+  an *execution behaviour* tempts reusing the whole *command* (see the
+  ADR-0036 discussion — the temptation to emit `Command::Insert` from
+  the advanced path just to reuse `do_insert`). Desired end state
+  (user-stated): **unique commands for every unique case, with a clean,
+  documented structure for reusable mechanics** (so execution helpers
+  are shared as library functions, not by collapsing command
+  identity). Consider a dedicated specification + restructuring run
+  (its own ADR) to map the framework and set the reuse-boundary rules,
+  easing future maintenance and extension. Not scheduled.
 
 ---