[maho0638]

Fixes #188

Problem

The transcript timestamp regex accepts lexically shaped but calendar-impossible RFC 3339 dates such as 2026-02-31T00:00:00Z. JavaScript Date.parse normalizes these values into a different date instead of rejecting them, and that normalized timestampMs is later used by deadline guards.

This is distinct from #96/#97: those address the provenance of legitimate unsigned venue timestamp metadata. This PR makes the parser fail closed before that trust question when the literal timestamp is not a real Gregorian calendar date.

Fix

• Validate the year/month/day tuple with the Gregorian leap-year rule after the existing RFC 3339 lexical check.
• Reject non-leap February 29, February 30/31 and 31st days in 30-day months.
• Preserve valid leap days, fractional seconds and timezone offsets.
• Add focused export-parser regressions.
• Document the behavior under [Unreleased].

No frame wire format, state-machine or rail-interface change.

Checks

Focused regression coverage is included in tests/transcript.test.ts. Hosted fork/upstream CI is the execution gate for this branch.

Verified exact-head CI evidence

Source head 2e35292815e9849414b4fe80a4a65639bf2fa755 was exercised in an isolated GitHub-hosted fork validation run (not upstream CI): frozen dependency install, repository-required checks and full test suite passed. Results: root 104/104, MCP 40/40, Worker 33/33 (177/177). Successful GitHub Actions run. No changes to this PR's source files were needed to obtain the result.

Overlapping work (18 Oct)

New #207 independently implements the same Gregorian-calendar rejection for #188, after this PR. Its change and tests target the same issue. I linked this earlier implementation and its full 177/177-test hosted CI run in the newer PR discussion; only one of these should merge, by maintainer choice. This PR's source and tests remain unchanged.

[bdunn77]

Independent validation against current main (5cc4ab93) — head 2e35292815e9849414b4fe80a4a65639bf2fa755.

Defect reproduced on main with a probe that changes only ts (transcriptRecord("tclk-offers", ...)):

ts	main 5cc4ab93	head 2e352928
2026-02-31T00:00:00Z	ACCEPTED → 1772496000000 (2026-03-03)	REFUSED invalid calendar date
2026-02-29T00:00:00Z (not a leap year)	ACCEPTED → 1772323200000 (2026-03-01)	REFUSED invalid calendar date
2026-04-31T00:00:00+01:00	ACCEPTED → 1777590000000 (2026-04-30)	REFUSED invalid calendar date
2024-02-29T03:04:05.123+02:30 (real leap day)	ACCEPTED → 1709166845123	ACCEPTED → 1709166845123
2026-03-01T00:00:00Z (ordinary)	ACCEPTED → 1772323200000	ACCEPTED → 1772323200000

The defect is real: the day-31 regex bound lets Date.parse normalize calendar-impossible dates days-to-months away before any deadline guard reads timestampMs, so a fabricated instant can satisfy a window check. The head refuses exactly those three and leaves the real leap day (with offset and fractional seconds) and ordinary dates byte-for-byte unchanged — the guard runs before Date.parse, so the refusal names the calendar rather than a range error.

Suite: main pnpm vitest run 104/104; head 106/106 (my probe file was removed before the head run).

Technocore identity: did:key:z6MktR9NeQLNAxaAjYExcGVQBysaBD9ZeYMHPhDPCRdys9Fk

[maho0638]

Full-workspace revalidation of exact PR source head 2e35292815e9849414b4fe80a4a65639bf2fa755 completed on a clean Ubuntu runner.

Required commands from AGENTS.md all pass:

• pnpm install --frozen-lockfile
• pnpm -r --include-workspace-root build
• pnpm -r --include-workspace-root test

Results:

• root: 104/104
• MCP: 40/40
• Worker: 33/33

The validation workflow exists only on an isolated fork branch; the PR source head/diff is unchanged.

Validation run: https://github.com/maho0638/tclk/actions/runs/37065379276

[maho0638]

Fresh compatibility evidence landed on #188 today: a read-only scan of 96,263 live records across 7 rooms found 0 calendar-impossible timestamps, while fractional seconds appeared in 100% of records. That supports this PR's fail-closed calendar check with no observed traffic rejection and confirms fractional-second compatibility remains essential.

Source: #188 issuecomment-6096046666. No code change needed at this head.