m/paliad

Fork 0

Files

History

mAi 9d688459e3

Paliad CI gate / build (push) Has been cancelled

Details

Paliad CI gate / test-go (push) Has been cancelled

Details

Paliad CI gate / deploy (push) Has been cancelled

Details

feat(db): mig 153 — proceeding_types kind discriminator + ProjectService hardening

Adds a `kind` column to paliad.proceeding_types (proceeding / phase /
side_action / meta) so the Mode B R3 Fristenrechner wizard, the
projects.proceeding_type_id binding, and the pkg/litigationplanner
snapshot can filter to primary proceedings only.

Implements the ratified design from docs/design-proceeding-types-
taxonomy-2026-05-26.md (m greenlit 2026-05-27 09:57 after the 11-question
AskUserQuestion round-trip).

Mig 153 is purely additive — ADD COLUMN with a safe DEFAULT, UPDATEs
reclassify 23 non-primary rows (4 phase + 10 side_action + 9 meta), and
a BEFORE INSERT/UPDATE trigger on paliad.projects backstops the new
invariant. Pre-mig audit (Supabase MCP, 2026-05-27) confirmed zero
downstream pressure on the 23 reclassified rows.

- internal/db/migrations/153_proceeding_types_kind.up.sql + .down.sql
  - snapshot to paliad.proceeding_types_pre_153 in the same TX
  - set_config('paliad.audit_reason', …) defensively
  - DO-block asserts 23 reclassified rows before the trigger ships
  - Q9 carve-out: is_active=false on every phase/side_action/meta row
  - new trigger paliad.projects_proceeding_type_kind_check on
    paliad.projects.proceeding_type_id

- internal/services/project_service.go
  - extend validateProceedingTypeCategory to also enforce
    kind='proceeding' AND is_active=true; new typed error
    ErrInvalidProceedingTypeKind
  - single SELECT picks up category + kind + is_active

- internal/services/project_service_test.go
  - TestProjectService_ProceedingTypeKindGuard covers service-layer
    rejection, the active-but-non-proceeding edge, mig 153 trigger
    backstop, and the kind='proceeding' happy path

- cmd/gen-upc-snapshot/main.go
  - filter proceeding_types query to kind='proceeding' for forward-
    compat (the embedded UPC snapshot JSON regen requires DATABASE_URL
    access and will land in a follow-up; the current placeholder is
    already empty of non-primary rows)

t-paliad-325 / m/paliad#147

2026-05-27 10:09:33 +02:00

main.go

feat(db): mig 153 — proceeding_types kind discriminator + ProjectService hardening

2026-05-27 10:09:33 +02:00

README.md

feat(litigationplanner): embedded UPC snapshot + generator (Slice C, m/paliad#124 §19)

2026-05-26 15:11:07 +02:00

README.md

gen-upc-snapshot

Regenerates the embedded UPC snapshot consumed by pkg/litigationplanner/embedded/upc. Slice C of the litigation-planner extraction (m/paliad#124 §19). See docs/design-litigation-planner-2026-05-26.md §19 for the full design.

When to regenerate

After any change that affects the public UPC rule corpus:

new rules merged via the admin rule-editor
a deadline-rule migration that touches UPC rows
a paliad.holidays update (new public holidays / vacation runs)
a paliad.courts update (new UPC LD opens, etc.)
a paliad.proceeding_types change for jurisdiction = 'UPC'

The snapshot is operator-controlled — there is no CI regeneration in v1.

How to regenerate

make snapshot-upc

or directly:

DATABASE_URL=postgres://...  go run ./cmd/gen-upc-snapshot

Flags:

Flag	Default	Purpose
`-output`	`./pkg/litigationplanner/embedded/upc`	directory to write JSON files into
`-version`	auto-derived (`YYYY-MM-DD-N`)	override the snapshot version
`-source-label`	empty	text label written to `meta.json` (`paliad-prod`, `paliad-dev`, …)

The generator:

Applies pending migrations against DATABASE_URL (snapshot always matches schema HEAD).
SELECTs UPC active proceeding_types + their published+active rules + referenced trigger_events + DE/UPC holidays + UPC courts.
Writes pretty-printed JSON to <output>/{proceeding_types,rules,trigger_events,holidays,courts,meta}.json.

Idempotence

Running twice with the same DB state produces the same JSON (modulo meta.generated_at). Diff-friendly in git.

Versioning

meta.json.version uses YYYY-MM-DD-N where N starts at 1 and increments on same-day regenerations. The generator reads the existing meta.json and bumps automatically.

After regeneration

Review the diff: git diff pkg/litigationplanner/embedded/upc/.
Run tests: go test ./pkg/litigationplanner/embedded/upc/....
Commit with a message like chore(snapshot): regenerate UPC snapshot (<reason>).
Notify any downstream consumer (youpc.org) that a new paliad release is available.