m/paliad
1
0
Fork 0
Code Issues 146 Pull Requests 8 Actions 1 Packages Projects Releases Wiki Activity

Litigation Planner suite — extract Fristenrechner/Verfahrensablauf into a Go package for paliad + youpc.org reuse (inventor) #124

New Issue
Open
opened 2026-05-26 07:56:08 +00:00 by mAi · 4 comments
mAi commented 2026-05-26 07:56:08 +00:00
Collaborator
Copy Link

m's vision (2026-05-26 09:46)

Our Deadline Calculator and Verfahrensablauf will become features of a 'litigation planner' suite. Where we can add proceeding types or specific submissions and then get the whole sequence with options for the steps so we can create scenarios etc as well.

And the idea is that we can later have the same module on youpc.org (limited to upc proceedings).

m's direction (2026-05-26 09:55)

it does deserve an inventor — i think I prefer a package within our project, sure

Reuse strategy locked: package-within-project (option 1). No API integration path; no separate service. paliad owns the package; youpc.org imports it as a library.

Phase: inventor design (READ-ONLY)

Inventor → coder gate per project CLAUDE.md.

Scope — design the litigation planner suite

Today's surfaces converging into the suite

  1. Fristenrechner (/tools/fristenrechner) — manual deadline calculation, project-aware
  2. Verfahrensablauf (/tools/verfahrensablauf) — abstract browse-a-proceeding, side+appellant+per-card-choices
  3. Per-project SmartTimeline — actual project's deadlines projected from deadline_rules + anchors + project_event_choices

All three already share internal/services/fristenrechner.go + projection_service.go. The package extraction formalises that shared core.

The package design

Target shape:

pkg/litigationplanner/
  doc.go                  — package docstring + reuse manifesto
  types.go                — TimelineRequest, TimelineResponse, RuleStub, ChoiceSet, etc.
  calc.go                 — pure compute: given rules + anchors + choices → timeline
  rules/                  — rule-catalog interfaces + paliad's default loader
    catalog.go            — RuleCatalog interface (Load(ctx, ProceedingTypeCode)) (rules, error))
    paliad_loader.go      — reads from paliad.deadline_rules (paliad-only impl)
  scenarios/              — scenario save/load (Q1 below)
  README.md               — "How to import this in youpc"

Key contract: NO database imports inside pkg/litigationplanner/calc.go. The calculator takes rules + anchors + choices as Go values. Persistence (Postgres) lives in the catalog implementation. youpc.org provides its OWN catalog impl (likely an in-memory snapshot of the UPC rule subset, pinned to a paliad release).

Open design questions

Q1 — Scenarios storage

A. Per-project named scenarios in paliad.project_event_choices: extend the table with scenario_name + is_active. One project can have N scenarios, switch with a chip. (R) — simplest, no new table.
B. New paliad.scenarios table keyed on project_id + name + a choices jsonb blob. Cleaner separation but duplicates data.
C. No persistence — URL-only scenarios, identical to today's per-card-choices URL state. Shareable, ephemeral.

Q2 — User-authored rules (m's 'add proceeding types or specific submissions')

A. Per-project draft rules: paliad.deadline_rules gains a project_id nullable column. NULL = global catalog (current behavior); non-NULL = scoped to that project. Visible only on that project; calculator merges global + project-scoped. (R) — minimal schema change, clean visibility.
B. Separate paliad.project_deadline_rules table linking projects to ad-hoc rules. More schema but cleaner separation.
C. Defer entirely — out of scope for v1 of the planner.

m's framing strongly implies (A) or (B). The lawyer needs to add 'we filed an unusual motion X with deadline Y for a response' on top of the standard catalog.

Q3 — Package boundary for youpc.org

A. Go package within m/paliad (pkg/litigationplanner). youpc imports via Go module dependency (require mgit.msbls.de/m/paliad/pkg/litigationplanner). Pull paliad as a submodule OR a versioned tag.
B. Separate repo m/litigationplanner, paliad imports it, youpc imports it. Cleaner ownership; more release-coordination overhead.

m's pick: A (within paliad). Locked.

Sub-question: how does youpc get a SNAPSHOT of UPC rules without paliad's full DB?

  • A.1 go:embed a JSON snapshot of the UPC rule subset into the package. Refresh via a generator script. youpc gets a static copy; updates ship as paliad releases.
  • A.2 youpc connects to paliad's read-replica for rule data. Tight coupling.
  • A.3 youpc maintains its own catalog implementation — paliad provides only the calc + the RuleCatalog interface.

(R) = A.1 — embed + generator. youpc.org has zero runtime dependency on paliad; updates are explicit + versioned. The generator script (scripts/snapshot-upc-rules/main.go or similar) refreshes the embedded JSON on demand.

Q4 — Coexistence with current shared core

internal/services/fristenrechner.go is paliad-internal today. Migration options:

A. Extract from internal/services into pkg/litigationplanner all at once. paliad's services re-import; youpc imports the same package. Single source of truth.
B. Duplicate the calc into pkg/litigationplanner first, prove youpc can use it, then DRY paliad to also use it. Two-step migration.

(R) = A (atomic move). The current shared core IS the package's reason to exist. Duplicating creates a drift risk.

Q5 — Versioning

If the rule data shape changes (Wave 2 primitives, Tier 3 schema work, future), youpc's embedded snapshot drifts from paliad's runtime. How do we handle version skew?

A. Strict version pinning: every paliad release publishes a litigationplanner@vN.M.K tag; youpc updates Go module version on its own cadence. Stale snapshots are tolerated; new rule shapes break the build at youpc update time.
B. Backward-compatible package API: the package versions ITS API explicitly; rule additions are forward-compatible; only breaking shape changes bump a major.

(R) = B with semver discipline. The package's API stays stable; the embedded snapshot is what changes.

Deliverable

docs/design-litigation-planner-2026-05-26.md on branch mai/<inventor>/litigation-planner-design. Sections:

  • §0 TL;DR (with the headline: 'paliad + youpc.org both import a single Go package')
  • §1 Today's surfaces converging
  • §2 Target package layout (pkg/litigationplanner/...)
  • §3 Public API + types
  • §4 Catalog interface design (Q3.A.1 embedded snapshot detail)
  • §5 Scenarios design (Q1)
  • §6 User-authored rules design (Q2)
  • §7 youpc.org integration plan (import + UPC-only restriction)
  • §8 Migration plan (Q4: atomic move from internal/services)
  • §9 Versioning + release process (Q5)
  • §10 Slice plan
    • Slice A: extract calc + types into pkg/litigationplanner (no behaviour change)
    • Slice B: catalog interface + paliad's default loader
    • Slice C: embedded UPC snapshot + generator script
    • Slice D: scenarios persistence (Q1)
    • Slice E: user-authored rules (Q2)
    • Slice F: youpc.org integration (separate PR on youpc repo)
  • §11 Risk assessment + rollback
  • §12 Out of scope
  • §13 Open questions for m (only the picks where the inventor is not confident)

Hard rules

  • READ-ONLY design phase. No code, no migrations.
  • Head answers questions — NO AskUserQuestion. Inventor uses mai instruct head. Default to (R) per the questions above; escalate Q1/Q2 material picks.
  • Stay within paliad repo (m's lock — option A, package-within-project, NOT a separate repo).
  • Don't propose anything that requires changing youpc.org's repo structure — only design what youpc has to import + how.
  • Read the existing internal/services/fristenrechner.go + projection_service.go + deadline_calculator.go carefully — they're the body to extract.
  • Audit existing rule data shape (paliad.deadline_rules columns, paliad.proceeding_types columns) so the package's RuleStub type matches.

When done

Push design doc + mai report completed with 'DESIGN READY FOR REVIEW'. Inventor parked. Head gates coder shift to Slice A.

Out of scope

  • Implementing youpc.org's import (separate task on youpc repo).
  • Rebuilding the calc — extract existing logic.
  • Cross-firm rule sharing (defer).
## m's vision (2026-05-26 09:46) > Our Deadline Calculator and Verfahrensablauf will become features of a 'litigation planner' suite. Where we can add proceeding types or specific submissions and then get the whole sequence with options for the steps so we can create scenarios etc as well. > > And the idea is that we can later have the same module on youpc.org (limited to upc proceedings). ## m's direction (2026-05-26 09:55) > it does deserve an inventor — i think I prefer a package within our project, sure **Reuse strategy locked: package-within-project (option 1).** No API integration path; no separate service. paliad owns the package; youpc.org imports it as a library. ## Phase: inventor design (READ-ONLY) Inventor → coder gate per project CLAUDE.md. ## Scope — design the litigation planner suite ### Today's surfaces converging into the suite 1. **Fristenrechner** (`/tools/fristenrechner`) — manual deadline calculation, project-aware 2. **Verfahrensablauf** (`/tools/verfahrensablauf`) — abstract browse-a-proceeding, side+appellant+per-card-choices 3. **Per-project SmartTimeline** — actual project's deadlines projected from `deadline_rules` + anchors + `project_event_choices` All three already share `internal/services/fristenrechner.go` + `projection_service.go`. The package extraction formalises that shared core. ### The package design **Target shape**: ``` pkg/litigationplanner/ doc.go — package docstring + reuse manifesto types.go — TimelineRequest, TimelineResponse, RuleStub, ChoiceSet, etc. calc.go — pure compute: given rules + anchors + choices → timeline rules/ — rule-catalog interfaces + paliad's default loader catalog.go — RuleCatalog interface (Load(ctx, ProceedingTypeCode)) (rules, error)) paliad_loader.go — reads from paliad.deadline_rules (paliad-only impl) scenarios/ — scenario save/load (Q1 below) README.md — "How to import this in youpc" ``` Key contract: **NO database imports inside `pkg/litigationplanner/calc.go`**. The calculator takes rules + anchors + choices as Go values. Persistence (Postgres) lives in the catalog implementation. youpc.org provides its OWN catalog impl (likely an in-memory snapshot of the UPC rule subset, pinned to a paliad release). ### Open design questions #### Q1 — Scenarios storage A. **Per-project named scenarios in paliad.project_event_choices**: extend the table with `scenario_name` + `is_active`. One project can have N scenarios, switch with a chip. (R) — simplest, no new table. B. **New `paliad.scenarios` table** keyed on project_id + name + a `choices jsonb` blob. Cleaner separation but duplicates data. C. **No persistence — URL-only scenarios**, identical to today's per-card-choices URL state. Shareable, ephemeral. #### Q2 — User-authored rules (m's 'add proceeding types or specific submissions') A. **Per-project draft rules**: `paliad.deadline_rules` gains a `project_id` nullable column. NULL = global catalog (current behavior); non-NULL = scoped to that project. Visible only on that project; calculator merges global + project-scoped. (R) — minimal schema change, clean visibility. B. **Separate `paliad.project_deadline_rules` table** linking projects to ad-hoc rules. More schema but cleaner separation. C. **Defer entirely** — out of scope for v1 of the planner. m's framing strongly implies (A) or (B). The lawyer needs to add 'we filed an unusual motion X with deadline Y for a response' on top of the standard catalog. #### Q3 — Package boundary for youpc.org A. **Go package within m/paliad** (`pkg/litigationplanner`). youpc imports via Go module dependency (`require mgit.msbls.de/m/paliad/pkg/litigationplanner`). Pull paliad as a submodule OR a versioned tag. B. **Separate repo `m/litigationplanner`**, paliad imports it, youpc imports it. Cleaner ownership; more release-coordination overhead. m's pick: **A** (within paliad). Locked. Sub-question: how does youpc get a SNAPSHOT of UPC rules without paliad's full DB? - A.1 **`go:embed` a JSON snapshot** of the UPC rule subset into the package. Refresh via a generator script. youpc gets a static copy; updates ship as paliad releases. - A.2 **youpc connects to paliad's read-replica** for rule data. Tight coupling. - A.3 **youpc maintains its own catalog implementation** — paliad provides only the calc + the RuleCatalog interface. **(R) = A.1** — embed + generator. youpc.org has zero runtime dependency on paliad; updates are explicit + versioned. The generator script (`scripts/snapshot-upc-rules/main.go` or similar) refreshes the embedded JSON on demand. #### Q4 — Coexistence with current shared core `internal/services/fristenrechner.go` is paliad-internal today. Migration options: A. **Extract from internal/services into pkg/litigationplanner** all at once. paliad's services re-import; youpc imports the same package. Single source of truth. B. **Duplicate the calc into pkg/litigationplanner first**, prove youpc can use it, then DRY paliad to also use it. Two-step migration. **(R) = A** (atomic move). The current shared core IS the package's reason to exist. Duplicating creates a drift risk. #### Q5 — Versioning If the rule data shape changes (Wave 2 primitives, Tier 3 schema work, future), youpc's embedded snapshot drifts from paliad's runtime. How do we handle version skew? A. **Strict version pinning**: every paliad release publishes a `litigationplanner@vN.M.K` tag; youpc updates Go module version on its own cadence. Stale snapshots are tolerated; new rule shapes break the build at youpc update time. B. **Backward-compatible package API**: the package versions ITS API explicitly; rule additions are forward-compatible; only breaking shape changes bump a major. **(R) = B** with semver discipline. The package's API stays stable; the embedded snapshot is what changes. ## Deliverable `docs/design-litigation-planner-2026-05-26.md` on branch `mai/<inventor>/litigation-planner-design`. Sections: - §0 TL;DR (with the headline: 'paliad + youpc.org both import a single Go package') - §1 Today's surfaces converging - §2 Target package layout (`pkg/litigationplanner/...`) - §3 Public API + types - §4 Catalog interface design (Q3.A.1 embedded snapshot detail) - §5 Scenarios design (Q1) - §6 User-authored rules design (Q2) - §7 youpc.org integration plan (import + UPC-only restriction) - §8 Migration plan (Q4: atomic move from internal/services) - §9 Versioning + release process (Q5) - §10 Slice plan - Slice A: extract calc + types into pkg/litigationplanner (no behaviour change) - Slice B: catalog interface + paliad's default loader - Slice C: embedded UPC snapshot + generator script - Slice D: scenarios persistence (Q1) - Slice E: user-authored rules (Q2) - Slice F: youpc.org integration (separate PR on youpc repo) - §11 Risk assessment + rollback - §12 Out of scope - §13 Open questions for m (only the picks where the inventor is not confident) ## Hard rules - READ-ONLY design phase. No code, no migrations. - **Head answers questions** — NO AskUserQuestion. Inventor uses `mai instruct head`. Default to (R) per the questions above; escalate Q1/Q2 material picks. - **Stay within paliad repo** (m's lock — option A, package-within-project, NOT a separate repo). - Don't propose anything that requires changing youpc.org's repo structure — only design what youpc has to import + how. - Read the existing `internal/services/fristenrechner.go` + `projection_service.go` + `deadline_calculator.go` carefully — they're the body to extract. - Audit existing rule data shape (`paliad.deadline_rules` columns, `paliad.proceeding_types` columns) so the package's RuleStub type matches. ## When done Push design doc + `mai report completed` with 'DESIGN READY FOR REVIEW'. Inventor parked. Head gates coder shift to Slice A. ## Out of scope - Implementing youpc.org's import (separate task on youpc repo). - Rebuilding the calc — extract existing logic. - Cross-firm rule sharing (defer).
mAi self-assigned this 2026-05-26 07:56:08 +00:00
mAi commented 2026-05-26 08:14:47 +00:00
Author
Collaborator
Copy Link

Addendum from m (2026-05-26 10:14)

When moving the logic into a module / package, we should make sure we use english terms (the current 'fristenrechner' does not fit the international approach). in code and documentation we try to use english

Reinforces the existing project CLAUDE.md language convention. Specifically for the new pkg/litigationplanner/ extraction (Slice A):

  • Package name, file names, Go types, function names, variable names — all English. The package is litigationplanner, not fristenrechner.
  • No German identifiers in the new package. Examples to avoid: Frist → Deadline, Verfahrensschritt → ProceduralEvent, Klägerseite → ClaimantSide, Gegnerseite → OpposingSide, Träger → Carrier or similar.
  • Doc comments + README in English.
  • CRITICAL: existing internal/services/fristenrechner.go carries some German-flavoured identifiers — those move into the new package as the rename target. Slice A's atomic-move is the cleanest time to rename.
  • Exception: i18n string keys MAY reference German legal terms when the German LEGAL TERM is the canonical (e.g. Klageerhebung, Schriftsatz) — those are product/legal vocabulary, not code names. But: code identifiers should still use English equivalents (statement_of_claim_code, not klageerhebung_code).
  • Product surface: user-facing UI keeps the German brand names (Fristenrechner, Schriftsätze, Verfahrensablauf) per existing convention — those live in i18n, not code.

Fold this into Slice A's coder instructions. The renaming work IS part of Slice A; not deferred.

## Addendum from m (2026-05-26 10:14) > When moving the logic into a module / package, we should make sure we use english terms (the current 'fristenrechner' does not fit the international approach). in code and documentation we try to use english Reinforces the existing project CLAUDE.md language convention. Specifically for the new `pkg/litigationplanner/` extraction (Slice A): - **Package name, file names, Go types, function names, variable names — all English.** The package is `litigationplanner`, not `fristenrechner`. - **No German identifiers** in the new package. Examples to avoid: `Frist` → `Deadline`, `Verfahrensschritt` → `ProceduralEvent`, `Klägerseite` → `ClaimantSide`, `Gegnerseite` → `OpposingSide`, `Träger` → `Carrier` or similar. - **Doc comments + README in English.** - **CRITICAL**: existing `internal/services/fristenrechner.go` carries some German-flavoured identifiers — those move into the new package as the rename target. Slice A's atomic-move is the cleanest time to rename. - **Exception**: i18n string keys MAY reference German legal terms when the German LEGAL TERM is the canonical (e.g. `Klageerhebung`, `Schriftsatz`) — those are product/legal vocabulary, not code names. But: code identifiers should still use English equivalents (`statement_of_claim_code`, not `klageerhebung_code`). - **Product surface**: user-facing UI keeps the German brand names (Fristenrechner, Schriftsätze, Verfahrensablauf) per existing convention — those live in i18n, not code. Fold this into Slice A's coder instructions. The renaming work IS part of Slice A; not deferred.
mAi commented 2026-05-26 11:02:18 +00:00
Author
Collaborator
Copy Link

Slice A landed (atomic extract → pkg/litigationplanner)

  • Design doc: docs/design-litigation-planner-2026-05-26.md (commits 8240717, 6e58595 — m's AskUserQuestion picks folded in: paliad.scenarios jsonb table + abstract scenarios, no user-authored rules).
  • Slice A extraction: 5f0a85f — Fristen/Verfahrensablauf calc engine + supporting types moved from internal/services into new pkg/litigationplanner. Net diff: +3 277 / −1 914 lines across 18 files.
  • Merge: d1d0cf9.
  • New package is DB-free (pure logic), English identifiers only, ready for youpc.org reuse.
  • All tests green; conflict resolution during rebase ported t-paliad-289 / -294 / -296 main-side fixes into pkg/litigationplanner.

Slices B-F still open. Slice B (catalog interface + Berufung unification) is next — m approved 2026-05-26 12:32: the 4-5 parallel Berufung proceeding_types (UPC_APP / UPC_COST_APPEAL / UPC_APP_ORDERS / Schadensbemessung / Bucheinsicht) get unified into one Berufung proceeding_type + appeal_target field; system derives the correct frist sequence from the target. cronus parked on Slice A coder mode awaiting Slice B greenlight.

## Slice A landed (atomic extract → `pkg/litigationplanner`) - Design doc: [`docs/design-litigation-planner-2026-05-26.md`](https://mgit.msbls.de/m/paliad/src/branch/main/docs/design-litigation-planner-2026-05-26.md) (commits [8240717](https://mgit.msbls.de/m/paliad/commit/8240717), [6e58595](https://mgit.msbls.de/m/paliad/commit/6e58595) — m's AskUserQuestion picks folded in: `paliad.scenarios` jsonb table + abstract scenarios, no user-authored rules). - Slice A extraction: [5f0a85f](https://mgit.msbls.de/m/paliad/commit/5f0a85f) — Fristen/Verfahrensablauf calc engine + supporting types moved from `internal/services` into new `pkg/litigationplanner`. Net diff: +3 277 / −1 914 lines across 18 files. - Merge: [d1d0cf9](https://mgit.msbls.de/m/paliad/commit/d1d0cf9). - New package is DB-free (pure logic), English identifiers only, ready for `youpc.org` reuse. - All tests green; conflict resolution during rebase ported t-paliad-289 / -294 / -296 main-side fixes into `pkg/litigationplanner`. Slices B-F still open. **Slice B (catalog interface + Berufung unification)** is next — m approved 2026-05-26 12:32: the 4-5 parallel Berufung proceeding_types (UPC_APP / UPC_COST_APPEAL / UPC_APP_ORDERS / Schadensbemessung / Bucheinsicht) get unified into one `Berufung` proceeding_type + `appeal_target` field; system derives the correct frist sequence from the target. cronus parked on Slice A coder mode awaiting Slice B greenlight.
mAi commented 2026-05-26 11:59:32 +00:00
Author
Collaborator
Copy Link

Slice B landed (catalog interface + 3 unifications)

Three sub-slices, three reviewable merges:

  • B1 — Berufung unification: Merge 426b90b (commit 07acf7b). Migration 134 additive only — collapses 3 UPC appeal proceeding_types (upc.apl.merits 7 rules, upc.apl.cost 2, upc.apl.order 7) into one upc.apl + appeal_target discriminator. 5 chip targets in the Verfahrensablauf picker: Endentscheidung, Kostenentscheidung, Anordnung, Schadensbemessung, Bucheinsicht. Schadensbemessung + Bucheinsicht are enum-defined and return empty timelines pending rule seeding (follow-up). Obsolete proceeding_types archived via is_active=false, never dropped.
  • B2 — Multi-axis catalog query API: Merge db8e8ba (commit d5bf823). Catalog.LookupEvents(ctx, axes, depth) with 5 optional axes (jurisdiction, proceeding_type_id, party, event_category_id, appeal_target) and depth toggle (next / all-following). No schema delta — reuses existing parent_id + sequence_order graph. 5 test cases (live-DB skipped without TEST_DATABASE_URL). HTTP endpoint deferred to a future slice.
  • B3 — primary_party CHECK constraint: Merge 932b177 (commit 989941c). Migration 135 audit-first (RAISE NOTICE listing dirty rows + RAISE EXCEPTION if any). Constraint: primary_party IS NULL OR primary_party IN ('claimant','defendant','court','both'). Package: PrimaryParty* constants + PrimaryParties[] + IsValidPrimaryParty(). Rule-editor pre-validates with user-friendly 400 before DB CHECK fires. pkg/litigationplanner/primary_party_test.go adds the first unit tests in the package.

Migrations: 134 (Berufung), 135 (primary_party CHECK) — both purely additive, both audit-first where data changes, no destructive drops. Down-migrations preserve safety.

Open follow-ups in this issue's scope:

  • Slices C–F (UPC snapshot + generator, scenarios, user rules, youpc integration) — not started.
  • Rule seeding for Schadensbemessung + Bucheinsicht appeal targets — editorial work via /admin/rules.
  • HTTP endpoint for LookupEvents — when a frontend surface needs it.
## Slice B landed (catalog interface + 3 unifications) Three sub-slices, three reviewable merges: - **B1 — Berufung unification**: [Merge 426b90b](https://mgit.msbls.de/m/paliad/commit/426b90b) (commit [07acf7b](https://mgit.msbls.de/m/paliad/commit/07acf7b)). Migration 134 additive only — collapses 3 UPC appeal proceeding_types (`upc.apl.merits` 7 rules, `upc.apl.cost` 2, `upc.apl.order` 7) into one `upc.apl` + `appeal_target` discriminator. 5 chip targets in the Verfahrensablauf picker: Endentscheidung, Kostenentscheidung, Anordnung, Schadensbemessung, Bucheinsicht. Schadensbemessung + Bucheinsicht are enum-defined and return empty timelines pending rule seeding (follow-up). Obsolete proceeding_types archived via `is_active=false`, never dropped. - **B2 — Multi-axis catalog query API**: [Merge db8e8ba](https://mgit.msbls.de/m/paliad/commit/db8e8ba) (commit [d5bf823](https://mgit.msbls.de/m/paliad/commit/d5bf823)). `Catalog.LookupEvents(ctx, axes, depth)` with 5 optional axes (jurisdiction, proceeding_type_id, party, event_category_id, appeal_target) and depth toggle (`next` / `all-following`). No schema delta — reuses existing `parent_id` + `sequence_order` graph. 5 test cases (live-DB skipped without `TEST_DATABASE_URL`). HTTP endpoint deferred to a future slice. - **B3 — primary_party CHECK constraint**: [Merge 932b177](https://mgit.msbls.de/m/paliad/commit/932b177) (commit [989941c](https://mgit.msbls.de/m/paliad/commit/989941c)). Migration 135 audit-first (`RAISE NOTICE` listing dirty rows + `RAISE EXCEPTION` if any). Constraint: `primary_party IS NULL OR primary_party IN ('claimant','defendant','court','both')`. Package: `PrimaryParty*` constants + `PrimaryParties[]` + `IsValidPrimaryParty()`. Rule-editor pre-validates with user-friendly 400 before DB CHECK fires. `pkg/litigationplanner/primary_party_test.go` adds the first unit tests in the package. **Migrations:** 134 (Berufung), 135 (primary_party CHECK) — both purely additive, both audit-first where data changes, no destructive drops. Down-migrations preserve safety. **Open follow-ups in this issue's scope:** - Slices C–F (UPC snapshot + generator, scenarios, user rules, youpc integration) — not started. - Rule seeding for Schadensbemessung + Bucheinsicht appeal targets — editorial work via `/admin/rules`. - HTTP endpoint for `LookupEvents` — when a frontend surface needs it.
mAi commented 2026-05-26 15:56:00 +00:00
Author
Collaborator
Copy Link

Suite complete — Slices A → F all landed today (2026-05-26)

  • Slice A — atomic extract to pkg/litigationplanner: Merge d1d0cf9
  • Slice B (3 sub-slices on paliad surface):
    • B1 Berufung unification: Merge 426b90b — mig 134 additive collapse of 3 UPC appeal proceeding_types into one upc.apl.unified + appeal_target discriminator. (3 hotfixes applied: code-shape #130, audit_reason #131, updated_at column.)
    • B2 Multi-axis catalog query API: Merge db8e8ba — Catalog.LookupEvents(ctx, axes, depth), 5 optional axes.
    • B3 primary_party CHECK constraint: Merge 932b177 — mig 135 audit-first.
  • Slice C — embedded UPC snapshot + generator: Merge 2a56b78 — cmd/gen-upc-snapshot/, pkg/litigationplanner/embedded/upc/.
  • Slice D — paliad.scenarios jsonb table + Catalog API + engine adapter: Merge 3b601f1 — mig 145 additive; 6 REST endpoints + RLS.
  • Slice E — KILLED (m's earlier decision; replaced by abstract scenarios in Slice D).
  • Slice F — youpc.org integration: on mai/cronus/coder-slice-f-paliad-snapshot-integration on the youpc.org repo (off e0e4e407); local-replace dev wiring, awaiting paliad release tag for the cutover.

Companion landings unrelated to a specific slice but on the same surface:

Open follow-ups (not blockers, not closing this issue — m closes):

  • #136 Verfahrensablauf appeal-mode side filter + missing trigger row + duration phrasing/dedup (diesel in flight).
  • #137 URL state hybrid model (queued behind #136).
  • Rule seeding editorial for Schadensbemessung/Bucheinsicht appeal targets (lawyers add target-specific deviations from the merits/order tracks via /admin/rules if needed).
  • paliad release-tag cutover so youpc.org can drop the local-replace directive.
  • youpc.org-side: public Verfahrensablauf frontend page, route registration, auth/rate-limit on the new /api/upc/* endpoints.
## Suite complete — Slices A → F all landed today (2026-05-26) - **Slice A** — atomic extract to `pkg/litigationplanner`: [Merge d1d0cf9](https://mgit.msbls.de/m/paliad/commit/d1d0cf9) - **Slice B** (3 sub-slices on paliad surface): - **B1** Berufung unification: [Merge 426b90b](https://mgit.msbls.de/m/paliad/commit/426b90b) — mig 134 additive collapse of 3 UPC appeal proceeding_types into one `upc.apl.unified` + `appeal_target` discriminator. (3 hotfixes applied: code-shape #130, audit_reason #131, updated_at column.) - **B2** Multi-axis catalog query API: [Merge db8e8ba](https://mgit.msbls.de/m/paliad/commit/db8e8ba) — `Catalog.LookupEvents(ctx, axes, depth)`, 5 optional axes. - **B3** `primary_party` CHECK constraint: [Merge 932b177](https://mgit.msbls.de/m/paliad/commit/932b177) — mig 135 audit-first. - **Slice C** — embedded UPC snapshot + generator: [Merge 2a56b78](https://mgit.msbls.de/m/paliad/commit/2a56b78) — `cmd/gen-upc-snapshot/`, `pkg/litigationplanner/embedded/upc/`. - **Slice D** — `paliad.scenarios` jsonb table + Catalog API + engine adapter: [Merge 3b601f1](https://mgit.msbls.de/m/paliad/commit/3b601f1) — mig 145 additive; 6 REST endpoints + RLS. - **Slice E** — KILLED (m's earlier decision; replaced by abstract scenarios in Slice D). - **Slice F** — youpc.org integration: on `mai/cronus/coder-slice-f-paliad-snapshot-integration` on the youpc.org repo (off `e0e4e407`); local-replace dev wiring, awaiting paliad release tag for the cutover. **Companion landings** unrelated to a specific slice but on the same surface: - #132 Berufung-tile UX (collapse duplicate side selectors + appeal-target trigger labels) — [Merge 46b58dc](https://mgit.msbls.de/m/paliad/commit/46b58dc) - #133 Verfahrensablauf duration indicator (hover + toggle) — [Merge a75731a](https://mgit.msbls.de/m/paliad/commit/a75731a) - #134 `applies_to_target` backfill for Schadensbemessung + Bucheinsicht — [Merge 727e01c](https://mgit.msbls.de/m/paliad/commit/727e01c) - #135 R.109 anchor + columns-view duplicate fix — [Merge 2377f08](https://mgit.msbls.de/m/paliad/commit/2377f08) **Open follow-ups** (not blockers, not closing this issue — m closes): - #136 Verfahrensablauf appeal-mode side filter + missing trigger row + duration phrasing/dedup (diesel in flight). - #137 URL state hybrid model (queued behind #136). - Rule seeding editorial for Schadensbemessung/Bucheinsicht appeal targets (lawyers add target-specific deviations from the merits/order tracks via `/admin/rules` if needed). - paliad release-tag cutover so youpc.org can drop the local-replace directive. - youpc.org-side: public Verfahrensablauf frontend page, route registration, auth/rate-limit on the new `/api/upc/*` endpoints.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
deferred
Parked — not pursuing now, may un-park later
done
Work completed by an agent; awaiting m to close
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
mAi m
No Assignees mAi
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: m/paliad#124
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?