v1.23.2

preg_match() returns false, not 0, on malformed UTF-8

references/type-safety.md gains the trap and the guard against it (@CybotTM in #124).

With the /u modifier PCRE validates the whole subject before matching, so an invalid byte fails the call rather than the match. Two of the three comparison shapes then misread the value, and they misread it differently:

• preg_match(…) === 1 — the match test — is false for false, so a byte-damaged subject reads as "no match" and travels on as if it were clean.
• !preg_match(…) conflates false with 0 and takes the same wrong branch.
• preg_match(…) === 0 — the no-match test — is also false, so neither arm runs and the error is skipped silently.

Only the first looks like a working guard, which is why it is the one that ships.

The section gives the check that separates the states — preg_match('//u', $value) !== 1, an empty pattern with the modifier, so no mbstring dependency — plus preg_last_error_msg() for the diagnosis.

Why it belongs at the boundary, not at the branch

A value that slips through keeps travelling. Symfony's UnicodeString constructor throws on invalid UTF-8 and AsciiSlugger builds one, so a single bad byte reaching a slugger aborts the entire run with an exception attributed to whatever called it — naming neither the input nor its origin. Validate where the value enters, and keep the raw value out of the log message: it is the one thing that cannot be written safely.

Dependencies

Pre-commit hook netresearch/skill-repo-skill to v2.1.0 and v2.1.1.

Full Changelog: v1.23.1...v1.23.2