includes refuses a field the schema says is a scalar

[rmichaelthomas]

A defect #72 introduced, found while porting.

What happened

includes is a list-membership probe, and a non-list operand evaluates to false at runtime by decision — test_includes_with_scalar_left_operand_is_false pins it. That is right where the operand's type is whatever the value turned out to be.

It is wrong at analysis time, where the record schema has already said what the field holds:

filter the orders where title includes "roof"

validated clean, emptied a two-record list, and reported success.

Reachable only since #72 admitted includes after where. The refusal that change replaced was safe and described the wrong problem — "I couldn't parse the condition after 'where'" — and what replaced it described nothing and was wrong. A misleading refusal beats a silent wrong answer, so this is mine and this is the fix.

The rule

Answer where the type is known; defer where it is not.

• string / number / date → refused
• unknown → runtime, unchanged

A list-valued field is unknown statically, so filter the orders where tags includes "urgent" — the case #72 exists for — still works, and is tested alongside.

The message names what is absent

'includes' tests whether a list holds a value, and 'title' is text.
Liminate has no text-contains test.

That is the honest answer to a downstream consumer asking for contains, and it is the answer rather than a new word because v27 §56's locked meta-finding says so: the era of new verbs is ending; the era of new positions is beginning. between — the structurally identical case — was put on the operator-extensibility pack frontier by the same ruling, and packs today extend verbs and nouns only.

Verified

• 1748 passed, 2 skipped
• a corpus case pins the refusal, so the TypeScript port inherits it rather than the silence
• grammar projections regenerated

🤖 Generated with Claude Code

https://claude.ai/code/session_01E6qcDj1e1dEYvc8jLnpGZy