refactor(litigationplanner): extract Fristen/Verfahrensablauf calc into pkg/litigationplanner (Slice A, t-paliad-298 / m/paliad#124)
Some checks failed
Paliad CI gate / build (push) Has been cancelled
Paliad CI gate / test-go (push) Has been cancelled
Paliad CI gate / deploy (push) Has been cancelled

Atomic extraction of the deadline-rule compute engine + types from
internal/services into a new pkg/litigationplanner package that paliad
+ youpc.org can both import. No behaviour change — every existing test
passes against the post-move shape.

Package contents (~1850 LoC):
- doc.go              package docstring + reuse manifesto
- types.go            Rule, ProceedingType, NullableJSON, AdjustmentReason,
                      HolidayDTO, CalcOptions, CalcRuleParams, Timeline,
                      TimelineEntry, RuleCalculation*, FristenrechnerType,
                      ProjectHint, sentinel errors
- catalog.go          Catalog interface (proceeding + rule lookups)
- holidays.go         HolidayCalendar interface
- courts.go           CourtRegistry interface + DefaultsForJurisdiction +
                      country/regime constants
- expr.go             EvalConditionExpr + HasConditionExpr +
                      ExtractFlagsFromExpr (jsonb gate evaluator)
- durations.go        ApplyDuration + AddWorkingDays (pure compute)
- subtrack.go         SubTrackRouting + LookupSubTrackRouting registry
- legal_source.go     FormatLegalSourceDisplay + BuildLegalSourceURL
- proceeding_mapping.go  MapLitigationToFristenrechner + code constants
                      (CodeUPCInfringement, CodeDEInfringementLG, ...)
- engine.go           Calculate + CalculateRule + the trigger-event
                      branch + applyRuleOverrides (the big move)

paliad side (~1900 LoC net deletion):
- internal/services/fristenrechner.go shrinks from 1505 → ~290 lines
  (thin paliad Catalog adapter + type aliases for back-compat).
- internal/models/models.go: DeadlineRule, ProceedingType, NullableJSON
  become type aliases to litigationplanner.* — every sqlx scan and
  every projection_service caller compiles unchanged.
- internal/services/holidays.go: AdjustmentReason + HolidayDTO become
  aliases to lp.* (canonical definitions now in the package).
- internal/services/proceeding_mapping.go: rewritten as thin re-exports
  of lp constants + helpers.
- internal/services/deadline_search_service.go: FormatLegalSourceDisplay
  + BuildLegalSourceURL replaced with delegating wrappers to lp.

Catalog interface satisfaction:
- DeadlineRuleService → paliadCatalog adapter (wraps the existing
  service, replicates the original SELECT shapes).
- HolidayService → satisfies lp.HolidayCalendar directly (compile-
  time assertion at end of fristenrechner.go).
- CourtService → satisfies lp.CourtRegistry directly.

Wire shape is byte-identical. JSON tags on Rule / ProceedingType /
Timeline / TimelineEntry / RuleCalculation match the historical
UIResponse / UIDeadline shape; the frontend reads the same bytes.

Slice B (Catalog interface + paliad loader cleanup) is folded into
this commit since Slice A already needs the interfaces to call
Calculate across the boundary. Slice C (embedded UPC snapshot +
generator) is the next coder shift; the Berufung unification m
called out lands in Slice B/C per head's brief.

Refs: docs/design-litigation-planner-2026-05-26.md
This commit is contained in:
mAi
2026-05-26 12:52:59 +02:00
parent 6e585951ee
commit 5f0a85fa83
18 changed files with 2491 additions and 2262 deletions

View File

@@ -1,191 +1,63 @@
package services
// proceeding_mapping bridges the two proceeding-type vocabularies in the
// codebase: the **litigation** conceptual category (INF / REV / APP /
// CCR / AMD / APM / ZPO_CIVIL) used by the historical project-binding
// + Pipeline-A rules, and the **fristenrechner** code category
// (upc.inf.cfi / de.inf.lg / epa.opp.opd / …) used by the Determinator
// cascade + rule engine. Post-Phase-3-Slice-5 (t-paliad-186) projects
// bind to fristenrechner codes directly, but the litigation→fristenrechner
// mapping is still needed for the ~40 Pipeline-A rules that remain on
// litigation proceedings and for any other surface that thinks in
// litigation terms.
//
// The mapping table here is the single source of truth — see
// docs/design-determinator-row-cascade-2026-05-13.md §4.2 for the
// design rationale + ambiguity notes, and
// docs/design-proceeding-code-taxonomy-2026-05-18.md for the
// lowercase dot-separated naming convention applied by mig 096
// (t-paliad-206). **Never silent FK promotion**: every ambiguous case
// returns ok=false so callers can degrade gracefully ("no narrowing")
// instead of guessing.
import lp "mgit.msbls.de/m/paliad/pkg/litigationplanner"
// Stable code constants — the strings landed by mig 096. Use these
// throughout the codebase so a future rename only needs to touch this
// file. The id-anchored FKs (deadline_rules.proceeding_type_id,
// projects.proceeding_type_id) are unaffected by the rename.
// proceeding_mapping bridges the two proceeding-type vocabularies in
// the codebase. The canonical implementations now live in
// pkg/litigationplanner — this file keeps the existing service-level
// names alive as re-exports so the rest of internal/services + tests
// compile without an import-rewrite.
//
// See pkg/litigationplanner/proceeding_mapping.go for the logic +
// docs/design-determinator-row-cascade-2026-05-13.md §4.2 for the
// design rationale.
// Stable code constants — re-exported from the package so existing
// services / handlers can keep using the bare names.
const (
CodeUPCInfringement = "upc.inf.cfi"
CodeUPCRevocation = "upc.rev.cfi"
CodeUPCCounterclaim = "upc.ccr.cfi"
CodeUPCPreliminary = "upc.pi.cfi"
CodeUPCDamages = "upc.dmgs.cfi"
CodeUPCDiscovery = "upc.disc.cfi"
CodeUPCAppealMerits = "upc.apl.merits"
CodeUPCAppealOrder = "upc.apl.order"
CodeUPCAppealCost = "upc.apl.cost"
CodeDEInfringementLG = "de.inf.lg"
CodeDEInfringementOLG = "de.inf.olg"
CodeDEInfringementBGH = "de.inf.bgh"
CodeDENullityBPatG = "de.null.bpatg"
CodeDENullityBGH = "de.null.bgh"
CodeEPAGrant = "epa.grant.exa"
CodeEPAOpposition = "epa.opp.opd"
CodeEPAOppositionAppeal = "epa.opp.boa"
CodeDPMAOpposition = "dpma.opp.dpma"
CodeDPMAAppealBPatG = "dpma.appeal.bpatg"
CodeDPMAAppealBGH = "dpma.appeal.bgh"
CodeUPCInfringement = lp.CodeUPCInfringement
CodeUPCRevocation = lp.CodeUPCRevocation
CodeUPCCounterclaim = lp.CodeUPCCounterclaim
CodeUPCPreliminary = lp.CodeUPCPreliminary
CodeUPCDamages = lp.CodeUPCDamages
CodeUPCDiscovery = lp.CodeUPCDiscovery
CodeUPCAppealMerits = lp.CodeUPCAppealMerits
CodeUPCAppealOrder = lp.CodeUPCAppealOrder
CodeUPCAppealCost = lp.CodeUPCAppealCost
CodeDEInfringementLG = lp.CodeDEInfringementLG
CodeDEInfringementOLG = lp.CodeDEInfringementOLG
CodeDEInfringementBGH = lp.CodeDEInfringementBGH
CodeDENullityBPatG = lp.CodeDENullityBPatG
CodeDENullityBGH = lp.CodeDENullityBGH
CodeEPAGrant = lp.CodeEPAGrant
CodeEPAOpposition = lp.CodeEPAOpposition
CodeEPAOppositionAppeal = lp.CodeEPAOppositionAppeal
CodeDPMAOpposition = lp.CodeDPMAOpposition
CodeDPMAAppealBPatG = lp.CodeDPMAAppealBPatG
CodeDPMAAppealBGH = lp.CodeDPMAAppealBGH
)
// MapLitigationToFristenrechner returns the fristenrechner code +
// condition flags implied by a (litigationCode, jurisdiction) pair.
//
// Inputs are case-sensitive — pass the canonical upper-snake form
// (e.g. "INF", "UPC"). Unrecognised codes or genuinely ambiguous
// combinations (APP+DE, ZPO_CIVIL+DE) return ok=false with a zero
// fristenrechner code; callers should treat that as "no narrowing"
// and leave the cascade wide-open rather than auto-pick.
//
// Condition flags are returned as a slice so callers can apply them
// alongside the fristenrechner code (CCR+UPC → upc.inf.cfi + with_ccr,
// AMD+UPC → upc.inf.cfi + with_amend). An empty slice means no flag
// context applies.
// Delegates to litigationplanner.MapLitigationToFristenrechner.
func MapLitigationToFristenrechner(litigationCode, jurisdiction string) (fristenrechnerCode string, conditionFlags []string, ok bool) {
switch litigationCode {
case "INF":
switch jurisdiction {
case "UPC":
return CodeUPCInfringement, nil, true
case "DE":
return CodeDEInfringementLG, nil, true
}
case "REV":
switch jurisdiction {
case "UPC":
return CodeUPCRevocation, nil, true
case "DE":
return CodeDENullityBPatG, nil, true
}
case "CCR":
// Counterclaim revocation — UPC fold-in is structural (the
// counterclaim lives inside an upc.inf.cfi proceeding with the
// with_ccr flag). DE Nichtigkeit is conceptually the same
// adversarial-validity test, no separate flag.
switch jurisdiction {
case "UPC":
return CodeUPCInfringement, []string{"with_ccr"}, true
case "DE":
return CodeDENullityBPatG, nil, true
}
case "AMD":
// Amendment-application bundled into upc.inf.cfi via with_amend.
// No DE / EPA / DPMA analogue today.
if jurisdiction == "UPC" {
return CodeUPCInfringement, []string{"with_amend"}, true
}
case "APP":
// Appeal is ambiguous in DE (OLG vs BGH) and the project
// model doesn't carry the instance hint we'd need to
// disambiguate. UPC is unambiguous — upc.apl.merits covers
// the merits appeal track for inf/rev/ccr/damages.
if jurisdiction == "UPC" {
return CodeUPCAppealMerits, nil, true
}
case "APM":
// Preliminary injunction / urgency procedure — UPC-only
// concept in the fristenrechner taxonomy.
if jurisdiction == "UPC" {
return CodeUPCPreliminary, nil, true
}
case "OPP":
// Opposition — primarily EPA. DPMA has dpma.opp.dpma but it
// doesn't surface from the litigation vocabulary today.
if jurisdiction == "EPA" {
return CodeEPAOpposition, nil, true
}
}
return "", nil, false
return lp.MapLitigationToFristenrechner(litigationCode, jurisdiction)
}
// ResolveCounterclaimRouting handles the determinator's
// upc.ccr.cfi illustrative-peer route: the code exists in the dropdown
// for taxonomic completeness, but no rules are attached to it. When the
// cascade resolves to upc.ccr.cfi we route the rule lookup back to
// upc.inf.cfi with a default with_ccr=true flag — see
// docs/design-proceeding-code-taxonomy-2026-05-18.md §0.3 sub-decision S1.
//
// `code` is the proceeding code the cascade resolved to. If it's
// upc.ccr.cfi, the function returns (CodeUPCInfringement,
// []string{"with_ccr"}, true). For any other code the function returns
// (code, nil, false) and callers proceed with the code unchanged. The
// boolean signals "routing was applied"; the caller can surface the hint
// "Regeln liegen auf upc.inf.cfi (with_ccr=true); wir leiten Sie dorthin
// weiter." in the UI.
// ResolveCounterclaimRouting handles the determinator's upc.ccr.cfi
// illustrative-peer route. Delegates to
// litigationplanner.ResolveCounterclaimRouting.
func ResolveCounterclaimRouting(code string) (effectiveCode string, defaultFlags []string, routed bool) {
if route, ok := SubTrackRoutings[code]; ok {
return route.ParentCode, route.DefaultFlags, true
}
return code, nil, false
return lp.ResolveCounterclaimRouting(code)
}
// SubTrackRouting describes a proceeding type that has no native rules
// of its own and is normally rendered inside a parent proceeding's flow
// with one or more condition flags enabled. The Procedure Roadmap
// (verfahrensablauf) routes calc requests for these codes to the parent
// proceeding + default flags, but preserves the user-picked code/name
// in the response identity and surfaces a contextual note explaining
// the framing — see m/paliad#58 and the design doc cited above.
//
// Adding a new sub-track is a data-only change here: extend
// SubTrackRoutings with the (code, parent, flags, note) tuple and the
// renderer picks it up automatically. The note copy lives in this file
// because it's semantic to the routing, not UI chrome.
type SubTrackRouting struct {
// Code is the user-picked proceeding code (e.g. "upc.ccr.cfi").
Code string
// ParentCode is the proceeding whose rules to use (e.g. "upc.inf.cfi").
ParentCode string
// DefaultFlags are merged into the user's flag set so the
// gated rules render. Order is preserved.
DefaultFlags []string
// NoteDE / NoteEN are the contextual banner above the timeline,
// explaining that the proceeding type is normally a sub-track.
// Plain text — the frontend renders them as a banner.
NoteDE string
NoteEN string
}
// SubTrackRoutings — single-source-of-truth registry. Today: just CCR.
// The pattern generalises to other "sub-track" proceeding types (e.g.
// R.30 application to amend the patent as a standalone roadmap, R.46
// preliminary objection) once they have a proceeding-type code of their
// own. New entries here are picked up by the spawn-as-standalone
// renderer in FristenrechnerService.Calculate without further wiring.
var SubTrackRoutings = map[string]SubTrackRouting{
CodeUPCCounterclaim: {
Code: CodeUPCCounterclaim,
ParentCode: CodeUPCInfringement,
DefaultFlags: []string{"with_ccr"},
NoteDE: "Die Nichtigkeitswiderklage läuft normalerweise innerhalb eines UPC-Verletzungsverfahrens mit aktiver Nichtigkeitswiderklage. Diese Zeitleiste zeigt das Verletzungsverfahren mit gesetztem with_ccr-Flag.",
NoteEN: "The counterclaim for revocation normally runs inside a UPC infringement action with the counterclaim flag set. This timeline shows the infringement action with with_ccr automatically enabled.",
},
}
// SubTrackRoutings exposes the sub-track routing registry. SubTrackRouting
// is aliased in fristenrechner.go.
var SubTrackRoutings = lp.SubTrackRoutings
// LookupSubTrackRouting returns the sub-track routing for a proceeding
// code, or (zero, false) if the code is not a sub-track. Used by the
// fristenrechner Calculate path to spawn the parent flow with the sub-
// track's default flags.
// code, or (zero, false) if the code is not a sub-track. Delegates to
// litigationplanner.LookupSubTrackRouting.
func LookupSubTrackRouting(code string) (SubTrackRouting, bool) {
r, ok := SubTrackRoutings[code]
return r, ok
return lp.LookupSubTrackRouting(code)
}