docs(plans): settle Q-F — load-time lexical check + runtime PRAGMA backstop

Defence in depth: lexical scan rejects DML/DDL at load with recipe-aware error UX (fires in CI / pre-commit). PRAGMA query_only runtime backstop from PR #35 stays as the parser-proof safety net for what lexical can't catch (WITH clauses, multi-statement, attached DBs).

All 6 grill questions now settled — ready for tracer 1.

Author: SutuSebastian

docs/plans/recipes-content-registry.md

@@ -227,9 +227,11 @@ Estimated total: ~1 day across ~6 commits.
 - **Q-D. `actions` for project-local recipes?** ✅ **YAML frontmatter on `<id>.md`, hand-rolled parser (~30 LOC).** Project recipes feel first-class — same `actions` template surface bundled recipes have. Frontmatter co-locates the action with its prose description (one editor open vs two file creates). Hand-rolled parser handles only the shallow shape codemap needs (key / list / string / bool); strict, clear errors, zero supply-chain surface. Rejected (i) skip-for-v1 — would make project recipes second-class ("missing a feature" feels worse than "we don't have evidence yet" for an open registry). Rejected `gray-matter` / `js-yaml` — too much surface (~50KB of full YAML 1.2 spec) for our shallow needs. Rejected (iii) sibling `<id>.actions.json` — three files per actions-bearing recipe is more cognitive overhead than one with optional frontmatter; JSON files separate the action from its prose explanation, which is the wrong factoring.
 - **Q-E. Conflict resolution loud or quiet?** ✅ **Silent at runtime + `shadows: true` flag in catalog discovery + agent-skill prompt update.** Three layers: (1) project wins silently — `--recipe fan-out` runs the project version with no stderr noise (user code wins; matches ESLint / npm overrides / `tsconfig` extends conventions). (2) Catalog responses (`--recipes-json`, `codemap://recipes`, `codemap://recipes/{id}`) carry `shadows: true` on project entries that override a bundled id of the same name. (3) Bundled `templates/agents/skills/codemap/SKILL.md` instructs agents to read `codemap://recipes` at session start and check `shadows` so they know when a recipe behaves differently from the documented bundled version. Per-execution response shape stays unchanged (preserves plan § 4 uniformity contract — `shadows` lives at discovery time, not per-call). Rejected (ii) one-time stderr warning — MCP servers log to stderr per spec but agent hosts don't surface those logs to the model, so warnings land nowhere useful for agent traceability. Rejected (iii) `--allow-shadow` flag — hostile to the legitimate-override case (every team that wants to override has to wire the flag through their tooling) for the rare-mistake case. Loader cost: ~5 LOC for the shadow-flag check.
 
+- **Q-F. Validation strictness?** ✅ **Both — load-time lexical check + retain run-time `PRAGMA query_only` backstop.** Load-time gives recipe-aware error UX (e.g. "Project recipe `<id>` at `.codemap/recipes/<id>.sql` starts with `DELETE` — recipes must be read-only. Use `--save-baseline` for capturing rows.") and fires in CI / pre-commit hooks so bad recipes never reach main. Lexical scan: strip `--` line comments, find first identifier-shaped token, deny-list `INSERT` / `UPDATE` / `DELETE` / `DROP` / `CREATE` / `ALTER` / `ATTACH` / `DETACH` / `REPLACE` / `TRUNCATE` / `VACUUM` / `PRAGMA` (~20 LOC, same shape as the empty-recipe check). The PR #35 `PRAGMA query_only=1` runtime backstop **stays** as the parser-proof safety net for anything lexical scans can't catch (multi-statement payloads, `WITH` clauses with mutating sub-queries, attached databases). Different jobs: lexical = good UX for common mistakes; backstop = correctness no matter what passes lexical. Rejected (i) load-time only — incomplete (`WITH foo AS (DELETE FROM …) SELECT …` slips through); shouldn't claim safety we don't have. Rejected (ii) run-time only — error fires after parse with a less-clear message and no recipe-aware framing.
+
 ### Still open
 
-- **Q-F. Validation strictness.** Reject project recipes that contain DML / DDL at load time (mirrors the `PRAGMA query_only` defence we shipped in PR #35), or let them fail at run time? Load-time rejection is more agent-friendly (fails fast on save_baseline-style misuse); run-time falls back to the engine's existing safeguard. Bias toward load-time — same lexical sanity check that's already proposed for empty-file detection.
+_None — all 6 questions settled. Ready to start tracer 1._
 
 ## 10. Non-goals (v1)