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

DE proceedings: one combined timeline per type (Verletzungsverfahren = LG→OLG→BGH, Nichtigkeitsverfahren = BPatG→BGH) #41

New Issue
Open
opened 2026-05-18 15:09:56 +00:00 by mAi · 0 comments
mAi commented 2026-05-18 15:09:56 +00:00
Collaborator
Copy Link

Surfaced by: t-paliad-207 interactive session (fermi, 2026-05-18, parent of Path A label-consistency fix on the same branch).

m's vision

If I selected Verletzungsverfahren, it would show LG > OLG > BGH in one long sequence. So maybe we have 'Verletzungsverfahren' separate from the sub-parts of the complete procedure. For Nichtigkeitsverfahren it would be BPatG > BGH.

Today's 5 DE tiles model each instance as a standalone proceeding-type with no chain-through. Per-instance entry remains useful (a user joining at the appeal stage shouldn't have to walk LG first), but the top-level mental model should be the type (Verletzung / Nichtigkeit) with the instance chain rendered as one combined timeline.

Why this isn't just a UI fix — three intertwined sub-decisions

1. Spawn rules for DE (corpus, parallels mig 095's UPC pattern)

Verified via SQL 2026-05-18: zero of 39 active DE rules have is_spawn=true or spawn_proceeding_type_id set. Selecting a single 'Verletzungsverfahren' tile today would only ever show LG's rules — there is no rule-data chain to OLG/BGH. The 3 spawn rules to add (mirroring inf.appeal_spawn / rev.appeal_spawn from mig 095):

New rule Parent Duration Legal source Spawns into
de.inf.lg.berufung_spawn de.inf.lg.urteil 1 Monat DE.ZPO.517 de.inf.olg (id 25)
de.inf.olg.revision_spawn de.inf.olg.urteil_olg 1 Monat DE.ZPO.548 de.inf.bgh (id 26)
de.null.bpatg.berufung_spawn de.null.bpatg.urteil 1 Monat DE.PatG.111.1 de.null.bgh (id 27)

All three would be priority='optional' + is_spawn=true + always-fire (no condition_expr) — same shape m blessed for UPC in t-paliad-203 F2.3 ("appeal is always a possibility").

2. De-duplication call

The rule corpus today seeds the same act from two angles:

  • de.inf.lg.berufung (deadline TO appeal, anchored on LG-urteil, 1mo)
  • de.inf.olg.berufung (Berufungsschrift AS the first step of the appeal proceeding)

Same for de.inf.lg.beruf_begr ↔ de.inf.olg.begruendung and the BPatG → BGH analogue. In a unified chain, ONE side has to go. Cleanest choice:

  • Source side (de.inf.lg.*) keeps the spawn rule — represents "deadline you face if you're running the LG case".
  • Receiving side (de.inf.olg.*) loses its .berufung + .begruendung roots — its real root becomes urteil_lg (the trigger event = service of LG judgment); the appeal-window deadlines were already covered by the spawn rule firing from the source.

Alternative: keep both, but mark one set as priority='informational' so save-modal doesn't double-write. m's call.

3. Multi-instance UI

The spawn chain renders correctly via projection_service on the SmartTimeline (Akte-bound) path. The standalone /tools/fristenrechner + /tools/verfahrensablauf abstract-browse calls go through FristenrechnerService.Calculate which loads rules WHERE proceeding_type_id = <pt> — it does NOT follow spawn_proceeding_type_id. Two options:

  • Option B-UI-1: teach Calculate to follow spawn FKs when the caller opts in (new CalcOptions.ChainSpawn bool). Wire the Verletzungsverfahren combined tile to set it. Per-instance tiles default off.
  • Option B-UI-2: keep per-instance tiles as-is; only the SmartTimeline (Akte-bound) renders the chain. The picker still gets the type→instance hierarchy from Path A, but no "one combined tile".

B-UI-1 is the literal answer to m's vision; B-UI-2 is the lighter-footprint compromise.

Other UX consequences if B-UI-1 ships

  • Court picker becomes multi-court (LG + OLG + BGH simultaneously, or one picker per instance) — the current single-select dropdown isn't built for this. Could default to: ask for LG only, infer OLG by jurisdiction (the OLG above the LG), infer BGH (Karlsruhe, fixed).
  • Trigger-event label ('Auslösendes Ereignis' in step 2) becomes ambiguous when the user re-anchors mid-chain. Solution: the label always reads off the FIRST root rule (Klageerhebung for Verletzung, Nichtigkeitsklage for Nichtigkeit); the OLG / BGH chain segments anchor off their preceding urteil automatically.
  • Timeline rendering wants instance markers — a section header inside the timeline body ("--- OLG-Verfahren ---" / "--- BGH-Verfahren ---") between chain segments so users see where one instance ends and the next begins. Cosmetic but important for legibility once chains get long.

Scope split

  • Slice 1 — mig: 3 spawn rules + deactivate the 4 duplicate roots on the receiving side (call from #2 above). Idempotent guards.
  • Slice 2 — FristenrechnerService.Calculate spawn-follow opt-in (Option B-UI-1) + tests.
  • Slice 3 — UI: top-level type tiles ('Verletzungsverfahren' / 'Nichtigkeitsverfahren'), instance markers in timeline render, multi-court picker shape. Path A's sub-group headers stay alongside as the drill-down for per-instance entry.

Each slice independently shippable; Slice 1 alone unblocks the SmartTimeline path even if Slice 2/3 take longer.

Dependencies / related

  • mig 095 (internal/db/migrations/095_fristen_gap_fill.up.sql) — the UPC pattern the DE spawn rules would mirror.
  • mig 097 (joule, t-paliad-210) — legal-citation backfill; the new spawn rules want legal_source set from the start.
  • t-paliad-207 / Path A — sub-group headers + parallel labels — landing in parallel on mai/fermi/interactive-session. Path A holds even if Path B never ships.
**Surfaced by:** t-paliad-207 interactive session (fermi, 2026-05-18, parent of Path A label-consistency fix on the same branch). ## m's vision > If I selected Verletzungsverfahren, it would show LG > OLG > BGH in one long sequence. So maybe we have 'Verletzungsverfahren' separate from the sub-parts of the complete procedure. For Nichtigkeitsverfahren it would be BPatG > BGH. Today's 5 DE tiles model each instance as a standalone proceeding-type with no chain-through. Per-instance entry remains useful (a user joining at the appeal stage shouldn't have to walk LG first), but the top-level mental model should be the **type** (Verletzung / Nichtigkeit) with the instance chain rendered as one combined timeline. ## Why this isn't just a UI fix — three intertwined sub-decisions ### 1. Spawn rules for DE (corpus, parallels mig 095's UPC pattern) Verified via SQL 2026-05-18: zero of 39 active DE rules have `is_spawn=true` or `spawn_proceeding_type_id` set. Selecting a single 'Verletzungsverfahren' tile today would only ever show LG's rules — there is no rule-data chain to OLG/BGH. The 3 spawn rules to add (mirroring `inf.appeal_spawn` / `rev.appeal_spawn` from mig 095): | New rule | Parent | Duration | Legal source | Spawns into | |---|---|---|---|---| | `de.inf.lg.berufung_spawn` | `de.inf.lg.urteil` | 1 Monat | `DE.ZPO.517` | `de.inf.olg` (id 25) | | `de.inf.olg.revision_spawn` | `de.inf.olg.urteil_olg`| 1 Monat | `DE.ZPO.548` | `de.inf.bgh` (id 26) | | `de.null.bpatg.berufung_spawn` | `de.null.bpatg.urteil`| 1 Monat | `DE.PatG.111.1` | `de.null.bgh` (id 27) | All three would be `priority='optional'` + `is_spawn=true` + always-fire (no `condition_expr`) — same shape m blessed for UPC in t-paliad-203 F2.3 ("appeal is always a possibility"). ### 2. De-duplication call The rule corpus today seeds **the same act from two angles**: - `de.inf.lg.berufung` (deadline TO appeal, anchored on LG-urteil, 1mo) - `de.inf.olg.berufung` (Berufungsschrift AS the first step of the appeal proceeding) Same for `de.inf.lg.beruf_begr` ↔ `de.inf.olg.begruendung` and the BPatG → BGH analogue. In a unified chain, ONE side has to go. Cleanest choice: - **Source side (`de.inf.lg.*`) keeps the spawn rule** — represents "deadline you face if you're running the LG case". - **Receiving side (`de.inf.olg.*`) loses its `.berufung` + `.begruendung` roots** — its real root becomes `urteil_lg` (the trigger event = service of LG judgment); the appeal-window deadlines were already covered by the spawn rule firing from the source. Alternative: keep both, but mark one set as `priority='informational'` so save-modal doesn't double-write. m's call. ### 3. Multi-instance UI The spawn chain renders correctly via `projection_service` on the SmartTimeline (Akte-bound) path. The standalone `/tools/fristenrechner` + `/tools/verfahrensablauf` abstract-browse calls go through `FristenrechnerService.Calculate` which loads rules WHERE `proceeding_type_id = <pt>` — it does NOT follow `spawn_proceeding_type_id`. Two options: - **Option B-UI-1:** teach `Calculate` to follow spawn FKs when the caller opts in (new `CalcOptions.ChainSpawn bool`). Wire the Verletzungsverfahren combined tile to set it. Per-instance tiles default off. - **Option B-UI-2:** keep per-instance tiles as-is; only the SmartTimeline (Akte-bound) renders the chain. The picker still gets the type→instance hierarchy from Path A, but no "one combined tile". B-UI-1 is the literal answer to m's vision; B-UI-2 is the lighter-footprint compromise. ### Other UX consequences if B-UI-1 ships - **Court picker** becomes multi-court (LG + OLG + BGH simultaneously, or one picker per instance) — the current single-select dropdown isn't built for this. Could default to: ask for LG only, infer OLG by jurisdiction (the OLG above the LG), infer BGH (Karlsruhe, fixed). - **Trigger-event label** ('Auslösendes Ereignis' in step 2) becomes ambiguous when the user re-anchors mid-chain. Solution: the label always reads off the FIRST root rule (Klageerhebung for Verletzung, Nichtigkeitsklage for Nichtigkeit); the OLG / BGH chain segments anchor off their preceding `urteil` automatically. - **Timeline rendering** wants instance markers — a section header inside the timeline body ("--- OLG-Verfahren ---" / "--- BGH-Verfahren ---") between chain segments so users see where one instance ends and the next begins. Cosmetic but important for legibility once chains get long. ## Scope split - **Slice 1** — mig: 3 spawn rules + deactivate the 4 duplicate roots on the receiving side (call from #2 above). Idempotent guards. - **Slice 2** — `FristenrechnerService.Calculate` spawn-follow opt-in (Option B-UI-1) + tests. - **Slice 3** — UI: top-level type tiles ('Verletzungsverfahren' / 'Nichtigkeitsverfahren'), instance markers in timeline render, multi-court picker shape. Path A's sub-group headers stay alongside as the drill-down for per-instance entry. Each slice independently shippable; Slice 1 alone unblocks the SmartTimeline path even if Slice 2/3 take longer. ## Dependencies / related - mig 095 (`internal/db/migrations/095_fristen_gap_fill.up.sql`) — the UPC pattern the DE spawn rules would mirror. - mig 097 (joule, t-paliad-210) — legal-citation backfill; the new spawn rules want `legal_source` set from the start. - t-paliad-207 / Path A — sub-group headers + parallel labels — landing in parallel on `mai/fermi/interactive-session`. Path A holds even if Path B never ships.
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
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: m/paliad#41
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?