fix(verfahrensablauf): m/paliad#58 — UPC CCR roadmap (EN label + spawn-as-standalone) #68

Open

mAi wants to merge 1 commits from mai/darwin/roadmap-ccr-en into main

Author	SHA1	Message	Date
mAi	13fc8fb2f2	fix(verfahrensablauf): m/paliad#58 — UPC CCR roadmap (EN label + spawn-as-standalone) m's 2026-05-20 14:08 reports on /tools/verfahrensablauf: 1. "There seems to be a lacking english term here" — picking UPC CCR shows "Trigger event: Widerklage auf Nichtigkeit" on EN. 2. "Nothing shows in the roadmap" — the timeline is empty because upc.ccr.cfi has no native rules (it's an illustrative peer that normally runs as a sub-track of upc.inf.cfi with with_ccr). Root cause for (1): UIResponse.proceedingName was DE-only. When a proceeding had no root rule the frontend fell back to that field, so EN users saw the DE label. The DB already has bilingual names; this was pure plumbing. Root cause for (2): the upc.ccr.cfi proceeding-type row exists for the picker (mig 096) but ResolveCounterclaimRouting — the helper that maps it to upc.inf.cfi with the with_ccr flag — was defined but never called. Calculate queried rules directly off upc.ccr.cfi and got an empty list. Fix: * Add ProceedingNameEN, ContextualNote, ContextualNoteEN to UIResponse. Frontend triggerEventLabelFor now consults the EN name on EN, falling back to DE only if the EN field is empty. * New SubTrackRouting registry in proceeding_mapping.go and a LookupSubTrackRouting lookup — single source of truth for the "this proceeding has no native rules, route to a parent with flags + show a contextual note" pattern. Today's only entry is upc.ccr.cfi → upc.inf.cfi + with_ccr; the pattern generalises to other sub-tracks via data-only additions. * Calculate consults the registry at the top: when a hit, the proceeding type is re-resolved to the parent for rule lookup, the default flags are merged into the user's flag set (user flags win on conflict), and the response identity (Code/Name/NameEN) stays on the user-picked proceeding so the page header still reads "Counterclaim for Revocation". The bilingual note surfaces in ContextualNote{,EN}. * Frontend renderResults paints a lime-accent banner above the timeline body when the response carries a note (.timeline-context-note). escHtml already exported from views/verfahrensablauf-core — imported here for the banner. No DB migration: SELECTs against paliad.proceeding_types, paliad.deadline_rules, and paliad.trigger_events confirm every active row already has a non-empty name_en / name. The bug was the API + frontend never reading the EN columns through the proceedingName fallback path. Tests: TestSubTrackRoutings pins the registry shape (every entry has matching key/value, non-empty parent+flags, bilingual notes; CCR's exact shape is asserted; non-sub-tracks miss). The existing TestResolveCounterclaimRouting continues to pass because the helper now consults the registry but the CCR semantics are unchanged.	2026-05-20 14:51:55 +02:00

Author

SHA1

Message

Date

mAi

13fc8fb2f2

fix(verfahrensablauf): m/paliad#58 — UPC CCR roadmap (EN label + spawn-as-standalone)

m's 2026-05-20 14:08 reports on /tools/verfahrensablauf:

  1. "There seems to be a lacking english term here" — picking
     UPC CCR shows "Trigger event: Widerklage auf Nichtigkeit" on EN.
  2. "Nothing shows in the roadmap" — the timeline is empty because
     upc.ccr.cfi has no native rules (it's an illustrative peer that
     normally runs as a sub-track of upc.inf.cfi with with_ccr).

Root cause for (1): UIResponse.proceedingName was DE-only. When a
proceeding had no root rule the frontend fell back to that field, so
EN users saw the DE label. The DB already has bilingual names; this
was pure plumbing.

Root cause for (2): the upc.ccr.cfi proceeding-type row exists for
the picker (mig 096) but ResolveCounterclaimRouting — the helper
that maps it to upc.inf.cfi with the with_ccr flag — was defined
but never called. Calculate queried rules directly off upc.ccr.cfi
and got an empty list.

Fix:

  * Add ProceedingNameEN, ContextualNote, ContextualNoteEN to
    UIResponse. Frontend triggerEventLabelFor now consults the EN
    name on EN, falling back to DE only if the EN field is empty.
  * New SubTrackRouting registry in proceeding_mapping.go and a
    LookupSubTrackRouting lookup — single source of truth for the
    "this proceeding has no native rules, route to a parent with
    flags + show a contextual note" pattern. Today's only entry is
    upc.ccr.cfi → upc.inf.cfi + with_ccr; the pattern generalises
    to other sub-tracks via data-only additions.
  * Calculate consults the registry at the top: when a hit, the
    proceeding type is re-resolved to the parent for rule lookup, the
    default flags are merged into the user's flag set (user flags win
    on conflict), and the response identity (Code/Name/NameEN) stays
    on the user-picked proceeding so the page header still reads
    "Counterclaim for Revocation". The bilingual note surfaces in
    ContextualNote{,EN}.
  * Frontend renderResults paints a lime-accent banner above the
    timeline body when the response carries a note
    (.timeline-context-note). escHtml already exported from
    views/verfahrensablauf-core — imported here for the banner.

No DB migration: SELECTs against paliad.proceeding_types,
paliad.deadline_rules, and paliad.trigger_events confirm every
active row already has a non-empty name_en / name. The bug was
the API + frontend never reading the EN columns through the
proceedingName fallback path.

Tests: TestSubTrackRoutings pins the registry shape (every entry
has matching key/value, non-empty parent+flags, bilingual notes;
CCR's exact shape is asserted; non-sub-tracks miss). The existing
TestResolveCounterclaimRouting continues to pass because the
helper now consults the registry but the CCR semantics are
unchanged.

2026-05-20 14:51:55 +02:00

fix(verfahrensablauf): m/paliad#58 — UPC CCR roadmap (EN label + spawn-as-standalone) #68

1 Commits