fix(core): harden bitemporal interval runtime integrity

[seonghobae]

Verified protected-main defect

Protected develop@9e3e4847510e1e612b48474ba42b177b8ed824df accepts caller-controlled subclasses at the shared HRIS bitemporal interval boundary. Python date/datetime subclasses can participate in effective-time and recorded-time visibility decisions, and RecordedInterval previously treated non-null tzinfo as sufficient even when no usable UTC offset existed. A custom timezone implementation could also regain control during later comparisons after an initial validation call.

RED → root-cause repair

• RED f425c3878b923e6e626d79617d82377ebf77d235 requires exact built-in temporal primitives for stored bounds and query coordinates.
• Strengthened RED 2b37ad4e8ac2cb6337d8e2e69f9ca39175d0d207 proves a non-null tzinfo whose utcoffset() is None is still invalid system-time evidence.
• Root-cause repair 827342a9a1ff102942584a574c81ca4b61bb0c31 introduces exact primitive validation and usable-offset validation at the shared interval boundary.
• e0e4e677dffd4285dea39bdd51509d599085d100 proves hostile timezone exceptions normalize to stable IntervalError rather than leaking arbitrary provider behavior.
• Strengthened RED 99095287bfa7ebf421f776d6f823a6b2dc448525 proves interval subclasses themselves and a one-shot custom timezone can regain control after validation unless the boundary detaches executable timezone behavior.
• Root-cause hardening ee0f5410c19468e71291f77053da1017704ed438 makes DateInterval/RecordedInterval non-subclassable, requires exact interval operands for overlap, and copies validated recorded timestamps onto fixed built-in timezone objects before storing/comparing them.
• Coverage strengthening/current exact head 7a4fd263546a5c1790a046fbb9b6ff60ba160960 exercises non-interval overlap operands plus non-zero fixed-offset canonicalization for the repository's exact statement/branch coverage contract.
• Primary-source and state traceability are recorded under docs/doctoring/bitemporal-interval-runtime-references.md and docs/traceability/bitemporal-interval-runtime-integrity.md without changing canonical documents owned by PR docs: reconcile canonical protected product truth #51.

The accepted model remains unchanged: business/effective time and system-recorded time are separate, intervals are half-open, and retroactive corrections remain correction-not-rewrite.

Exact-current-head evidence

Current exact head: 7a4fd263546a5c1790a046fbb9b6ff60ba160960.
Fresh live protected base: develop@9e3e4847510e1e612b48474ba42b177b8ed824df.
GitHub reports the PR open, ready-for-review, and mergeable.

Fresh exact-head hosted workflows are terminal GREEN on this unchanged head:

• Recovery Rehearsal Quality 32512260373 — success
• Job-Analysis API Quality 32512260506 — success
• People API Quality 32512260433 — success
• SAST Semgrep 32512260486 — success
• Security Scan 32512260761 — success
• Workforce Intelligence Quality 32512260652 — success
• Foundation CI 32512260470 — success

Fresh review verification finds no submitted reviews and no review threads. No qualifying formal independent non-author APPROVE is present.

Scope

Orgmetra-only HRIS-kernel repair. No dedicated-writer dependency repository, source, ref, workflow, PR state, credential or application table is modified.

Merge discipline

The unchanged exact head has terminal applicable GREEN hosted evidence, mergeability is freshly resolved, and no valid unresolved review finding exists, so this lane is ready for qualifying independent review. Ready-for-review is not approval and does not authorize merge. Immediately before merge refetch exact head/base/reviews/threads/rules/checks and use expected-head protection. Do not self-approve, weaken a gate, or reuse predecessor evidence.

[coderabbitai]

Warning

Review limit reached

@seonghobae, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 52 seconds

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

Wait for the limit to reset, then comment @coderabbitai review or push new commits to the PR.

An organization admin can change what happens after included review limits in Billing.

How do review limits work?

CodeRabbit enforces per-developer PR review limits within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 78dbd230-633e-42ec-ac39-17ae775ab635

📥 Commits

Reviewing files that changed from the base of the PR and between 9e3e484 and 7a4fd26.

📒 Files selected for processing (4)

• docs/doctoring/bitemporal-interval-runtime-references.md
• docs/traceability/bitemporal-interval-runtime-integrity.md
• packages/hris-kernel/src/orgmetra_hris_kernel/intervals.py
• packages/hris-kernel/tests/test_interval_runtime_integrity.py

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[devin-ai-integration]

Devin Review found 3 potential issues.

[seonghobae]

@opencode-agent Please review the current unchanged head against protected develop. Local exact-head verification: all owned package suites pass at 100% statement/branch coverage.