youpc.org/deadlines was rolling a deadline "from 2027-01-02 (UPC Winter
Vacation)" — i.e. across the UPC judicial vacation as if it were a
public holiday. Paliad-side t-paliad-121 already decided vacations are
informational only (the Court keeps running through them, RoP / UPC AC
decision-on-judicial-vacation 2023-05-26), and `HolidayService.Is
NonWorkingDay` in `internal/services/holidays.go` is correct. The
embedded snapshot consumed by youpc.org via Go-module replace had
drifted: `pkg/litigationplanner/embedded/upc/holidays.go:74` blocked on
both `isClosure()` AND `isVacation()`.
This commit aligns the embedded calendar with the paliad-side semantics
and ships a fresh holiday set so the existing 2026/2027 fix actually
takes effect downstream.
Code changes (`holidays.go`):
- `IsNonWorkingDay`: drop the `|| h.isVacation()` branch — only weekends
and `isClosure()` rows trigger the roll. Godoc rewritten to mirror
the paliad-side rationale (Court keeps operating, RoP cites,
vacation rows kept for informational labels).
- `isClosure()`: accept both `"public_holiday"` and `"closure"`. Live
paliad DB rows use the `public_holiday` value; the placeholder
snapshot shipped with the original Slice C used `closure` as a
hand-crafted synonym. Reconciles with
`internal/services/holidays.go:132` which already does the same
union. Required to make the regenerated JSON (full of
`public_holiday`) keep blocking DE national holidays after the
regeneration in this commit.
- Type-level godoc updated: `SnapshotHolidayCalendar` now documents
vacation-is-informational, and the `AdjustForNonWorkingDaysWithReason`
precedence note explains that `vacation` kind only fires when a
vacation row overlaps a weekend or closure that's already doing the
rolling.
Data refresh (`holidays.json`):
- Regenerated from paliad prod (postgres @ 100.99.98.201:11833,
paliad schema). 55 rows for 2026 + 2027: 22 DE public_holiday +
33 UPC vacation (25 Summer Vacation Jul 27–Aug 28, 8 Winter
Vacation Dec 24/28–31 + Jan 4–6). The previous placeholder shipped
only 5 rows (3 Sommerpause + Neujahr + Tag der Arbeit, no Winter
Vacation at all) — which is why a date landing in late Dec / early
Jan landed inside an unmodeled gap on the consumer side.
- `meta.json` bumped: version → `2026-05-27-1-holidays-only`,
`holiday_count` 5 → 55, `source_db_label` flags that only
holidays.json was refreshed (see friction note below).
Regression test (`snapshot_test.go::TestSnapshotHolidayCalendar`):
- 2026-08-04 (Tue, UPC Summer Vacation) — `IsNonWorkingDay` must be
false; `AdjustForNonWorkingDays` must NOT mutate the date.
- 2027-01-02 (Sat, m's flagged scenario) — must roll forward through
Sat/Sun, then STOP on Mon 2027-01-04 (UPC Winter Vacation, no longer
blocking). Pre-fix this rolled all the way to Thu 2027-01-07.
Cross-repo: youpc.org imports `pkg/litigationplanner` via Go-module
replace; the regenerated snapshot ships on its next rebuild. No
separate youpc.org commit needed — paliad is the source of truth.
Friction note: `cmd/gen-upc-snapshot/main.go` itself is incompatible
with the current paliad schema. Migration 140 (`140_drop_deadline_rules`)
dropped `paliad.deadline_rules`, but the generator still SELECTs from
it (main.go ~L162). Running the tool against prod fails on the rules
step. I bypassed the broken path and generated `holidays.json` directly
from the DB via psql + jq (same JSON shape that `EmbeddedHoliday`
expects, nulls filtered for `omitempty`). The other snapshot files
(rules.json, proceeding_types.json, trigger_events.json, courts.json)
remain at their pre-existing placeholder state — re-flagged in
meta.json's `source_db_label`. Refitting the generator for the post-
mig-140 schema is a separate task.
go vet + go test ./... clean (256+ Go tests pass, including the new
regression cases).
mAi
39353d49ed