Draft: Investigate #1219 row-boolean WHERE validation gap

[lmeyerov]

Summary

Investigation-only draft for #1219:

• Adds a GFQL design note documenting the row-boolean WHERE validation gap (OR/NOT/XOR), risk surface, solution options, and staged recommendation.
• Links the investigation doc from the GFQL assistant docs index.

Files

• ai/docs/gfql/issue-1219-row-boolean-validation.md
• ai/docs/gfql/README.md

Why this PR

#1219 identifies a static-validation gap after Earley parsing broadened accepted row-boolean shapes. This PR creates shared implementation guidance before code changes.

Next Steps (human-gated)

1. Human selects implementation scope (Option A/B/C/D or hybrid).
2. Implement chosen scope with targeted parser/binder/pushdown tests.
3. Run review workflow (/review ... mode=findings fixes=deferred) during implementation and validation phases.
4. Keep merge manual; no auto-merge.

Refs #1219

[lmeyerov]

Update based on maintainer guidance:

I propose splitting delivery into 2 PRs:

1. Phase 1 / PR1: test + validation hardening only

• Add a positive/negative row-boolean shape matrix.
• Add corresponding TCK audit + implementation checks for accepted/rejected behavior.
• No disjunction support expansion in this PR.

2. Phase 2 / PR2: behavior expansion (conditional)

• Expand OR/NOT/XOR support only where Phase 1 evidence confirms correctness envelope.
• Add targeted planner/pushdown/null-extension safeguards and tests.

Human gates remain:

• human approval before PR1 scope start
• human review of PR1 results before PR2 scope
• manual merge only (no auto-merge)

[lmeyerov]

Superseded by stacked implementation PRs for #1219 on top of #1217:\n- Phase 1 (tests/audit): #1223\n- Phase 2 (implementation): #1224\n\nKeeping #1222 out of the merge path to avoid duplicate review scope.

[lmeyerov]

Closing in favor of the new #1219 stack (#1223 -> #1224).