A fired rule reaches the exit status, and includes reaches the parser

[rmichaelthomas]

Found while a downstream consumer (commongage) was string-matching Liminate's stdout to learn a verdict. Three things, all small, all in one area.

1. A violated forbid exited 0

record_result classified ERROR_PARSE, ERROR_SEMANTIC, ERROR_RUNTIME and PACK_VERB_FAILURE as had_any_error. PROHIBITION_VIOLATED and REQUIREMENT_NOT_MET were in neither list.

Measured before:

forbid violated →  Error: Prohibition violated: anchor is no.
                   this line still runs          exit=0
cite failed     →  Error: The text 'absent text' was not found in 's'.
                   this line still runs          exit=1

A pack verb was more consequential to a shell than the language's own deontic core. So every consumer matched the string Prohibition violated to get the verdict — and one that forgot reported a denial as an admission.

Exit status only. Execution still continues past a fired rule, so a program reports every violation rather than the first. That is the more useful behaviour — the case that prompted this reports two prohibitions — and is why this is not a halt.

2. where <field> includes <value> never reached the parser

The parser already builds op="includes" / op="not_includes" for that form, and analyzer.py accepts them explicitly as list-membership. Only the reorderer's two-token gate refused it:

second_ok = (second.type is TokenType.OPERATOR and second.value == "is")

includes is a CONNECTIVE, so the one stage that does no parsing reported the condition as unparseable. The gate had already been widened once, for the v25 extrema head; this is the same shape of change.

What it unlocks works and was unreachable — filtering records by a field that holds a list:

remember an order called order1 with total as 75 and tags as roof-tags
filter the orders where tags includes "urgent"    → 1 of 2 records remain

The boundary is tested, not left to be found later. each is an item, and includes over a non-list operand is false by decision (test_includes_with_scalar_left_operand_is_false), so where each includes "x" empties the list. This does not make includes a substring test — text-contains is still not in the language, and the new test says so in place.

3. A comment claimed a halt that does not happen

run.py justified running contradiction detection up front "even if a later require/forbid halts the run before reaching the conflicting statement." Neither halts. Running it up front is still right; the reason was not.

Verified

• 1742 passed, 2 skipped, 0 failures
• Reverting the gate fails five of the new tests
• forbid now exits 1, a satisfied forbid/require still exits 0

🤖 Generated with Claude Code

https://claude.ai/code/session_01E6qcDj1e1dEYvc8jLnpGZy