Forms: lookup fields — analyst page + developer guide (#962/#963)
New page: Forms-Lookup-Fields-Developer-Guide. The security surface
earned it its own guide rather than another section in the sections &
conditional-logic one — three gates, a scoping rule whose NULL means the
opposite of Knowledge's, and a bug that only showed up under a live run.
Forms.md gains a Lookup fields section (and the type count moves from
nine to ten, which the page had been getting right by hand).
What the dev guide records that the code cannot say for itself:
- Why one type with a source, not one per source. Same argument as the
date field's mode, and it will come up again for the next type:
field_type cannot change once a field exists.
- The registry IS the SQL whitelist — those column names are
interpolated, so they may only ever come from the constant. Four of
five column sets assumed while building were wrong, and a wrong column
name renders as "no matches" rather than an error, so a source can be
broken and look merely empty.
- Why contracts and software are absent, with the specific schema gap
each is waiting on.
- The three meanings of $tenantIds, since null / [] / [ids] are all
legitimate and confusing two of them is silent.
- ⚠️ NULL tenant means "the Default company's" here, the opposite of
Knowledge — and on a single-company install every row is NULL, so the
clause handling it is not an edge case, it is the feature working.
- The #963 post-mortem, because the generalisable part is not the fix:
a function_exists() guard around a security rule degrades silently,
and not necessarily toward the safer behaviour. Here it degraded
toward refusing legitimate answers.
- That adding a field type means five places, one of which is PROSE —
and that the prompt had already drifted, omitting datetime and section
for months without anything failing.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>