An impossible date is a violation, and the day is judged where a regex cannot judge it

`xsd:date` and `xsd:dateTime` were checked by a regex alone, so "2026-02-31"
satisfied `sh:datatype` on both evaluation paths. Decision 0018 recorded that as
engine defect E1 and deferred the fix until the conformance baseline had been
measured. This is that fix.

A syntactic pattern cannot express "this day exists in this month" without
encoding leap years, and a regex that tried would be unreadable and wrong at the
century boundary. So the regex stays what it is good at and becomes a
PRE-FILTER: it returns every form it cannot vouch for, well formed ones
included, and the day is judged in Rust afterwards. A row the pre-filter returns
is therefore a candidate and not yet a verdict.

The leap rule is Gregorian, so 1900 is not a leap year and 2000 is, and a test
pins both because that is the pair any century shortcut gets wrong.

The pre-filter is keyed by its own test text, which is unique per datatype, so a
node shape carrying two datatype constraints keeps them apart.

Measured rather than assumed. The W3C conformance baseline did not move: the
file diff is zero bytes and all four ratchet tests pass. The Lean evaluator has
always checked the day against the days in the month, so Lean and Rust
disagreed here; they now agree on the fixtures where they diverged, and
`tests/shacl_verified_tool_test.rs` carries that agreement.

The E1 test in the adversarial corpus recorded the defect as an expectation.
Decision 0018 said that when the lexical space was implemented the test would
fail, and that the right response was to correct the expectation and amend the
record rather than weaken the test. Both were done.

Every gate was watched failing: an early return in `calendar_violation` reddens
three of the six new tests and two in the adversarial corpus, and the three that
survive it are testing other things, which is why they do not move.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: fabio-rovai