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

Determinator B1 row-by-row cascade — replace breadcrumb drilldown with stacked collapsible rows #25

New Issue
Open
opened 2026-05-08 20:17:54 +00:00 by mAi · 2 comments
mAi commented 2026-05-08 20:17:54 +00:00
Collaborator
Copy Link

m's verbatim 2026-05-08 22:16, dogfooding the Fristenrechner Determinator B1 cascade:

This is where our decision tree currently stops. When I say it's from the court, that's it... I would like the tree to work row by row, like applying filters. It's partially already like that. "Ich vertrete" .. "kam es an"..

Selections that are explained at the step, then logged in and collapsed, next row - row by row. And you can see your selections.

Instead of the breadcrumbs, we only do the row thing... but our old system that starts with "Neu starten" needs to be implemented in our new "Filter / Suche" thing

What's wrong today

The B1 cascade (Slice 3b/3c, commits 2f27620 + 6fcf34a) renders the existing two row-by-row controls — Ich vertrete (perspective) + Wo kam es an? (inbox-channel) — followed by a breadcrumb-based nested-card drilldown that stops at "Welcher Charakter hat das Schriftstück?" with a ← Schritt zurück button. Two interaction patterns side-by-side: clean rows on top, breadcrumb cards underneath. The cards don't visualize the user's choice trail and the breadcrumb is hard to glance.

Proposed shape

Replace the breadcrumb drilldown with the same row-by-row pattern. Each cascade depth becomes a row in the same stack:

Ich vertrete: [Kläger | Beklagter | Beide]
Wo kam es an: [CMS | beA | Posteingang | Alle]
Was ist eingegangen?: [📥 CMS-Eingang | beA-Eingang | Postfach | ...]
→ on selection, collapses to:
Eingang: 📥 CMS-Eingang  [ändern]
Wer hat geschickt?: [⚖ Vom Gericht | Von der Gegenseite | ...]
→ on selection, collapses to:
Absender: ⚖ Vom Gericht  [ändern]
Welcher Charakter hat das Schriftstück?: [chips for next level]

Clicking [ändern] re-opens that row AND COLLAPSES every later row (context just changed). At any time, the user sees their full choice trail as a stack.

Hard requirements

  • Preserve the existing ?b1=cms-eingang.gegenseite.upc-rev URL contract — bookmarks stay valid. Each cascade depth is one segment of the path.
  • Perspective + channel rows already work; fold them into the same row-stack visual rather than living in a separate strip above. Order: perspective → channel → cascade.
  • Neu starten button stays. Resets the entire row stack to the empty state (perspective row visible only).
  • The leaf chips (the final event_category / event_type the user picks to drive the deadline) keep rendering as today. Only the PATH to them becomes row-by-row.
  • Build clean per commit (go build ./... + bun run build.ts).
  • DE+EN i18n on every new label.
  • No hour estimates.
  • Honour the .entity-table row-click contract — though this is a chip-cluster surface, not a table.

Files to start with

  • frontend/src/client/fristenrechner.ts — cascade machinery (Slice 3b/3c shipped here)
  • frontend/src/fristenrechner.tsx — JSX shell
  • frontend/src/styles/global.css — .fristen-perspective-bar, .fristen-inbox-chip, .fr-cascade-* rules to extend
  • frontend/src/client/i18n.ts — new prompts per cascade depth (DE+EN)

Out of scope

  • Backend changes — the event_category cascade hierarchy (paliad.event_categories) stays as-is.
  • The leaf event-type picker styling.
  • Mobile-specific layout — should still work on mobile but no re-imagining.

Filed by paliad/head from m's 2026-05-08 22:16 instruction.

m's verbatim 2026-05-08 22:16, dogfooding the Fristenrechner Determinator B1 cascade: > This is where our decision tree currently stops. When I say it's from the court, that's it... I would like the tree to work row by row, like applying filters. It's partially already like that. "Ich vertrete" .. "kam es an".. > > Selections that are explained at the step, then logged in and collapsed, next row - row by row. And you can see your selections. > > Instead of the breadcrumbs, we only do the row thing... but our old system that starts with "Neu starten" needs to be implemented in our new "Filter / Suche" thing ## What's wrong today The B1 cascade (Slice 3b/3c, commits 2f27620 + 6fcf34a) renders the existing two row-by-row controls — Ich vertrete (perspective) + Wo kam es an? (inbox-channel) — followed by a breadcrumb-based nested-card drilldown that stops at "Welcher Charakter hat das Schriftstück?" with a `← Schritt zurück` button. Two interaction patterns side-by-side: clean rows on top, breadcrumb cards underneath. The cards don't visualize the user's choice trail and the breadcrumb is hard to glance. ## Proposed shape Replace the breadcrumb drilldown with the same row-by-row pattern. Each cascade depth becomes a row in the same stack: ``` Ich vertrete: [Kläger | Beklagter | Beide] Wo kam es an: [CMS | beA | Posteingang | Alle] Was ist eingegangen?: [📥 CMS-Eingang | beA-Eingang | Postfach | ...] → on selection, collapses to: Eingang: 📥 CMS-Eingang [ändern] Wer hat geschickt?: [⚖ Vom Gericht | Von der Gegenseite | ...] → on selection, collapses to: Absender: ⚖ Vom Gericht [ändern] Welcher Charakter hat das Schriftstück?: [chips for next level] ``` Clicking [ändern] re-opens that row AND COLLAPSES every later row (context just changed). At any time, the user sees their full choice trail as a stack. ## Hard requirements - Preserve the existing `?b1=cms-eingang.gegenseite.upc-rev` URL contract — bookmarks stay valid. Each cascade depth is one segment of the path. - Perspective + channel rows already work; fold them into the same row-stack visual rather than living in a separate strip above. Order: perspective → channel → cascade. - `Neu starten` button stays. Resets the entire row stack to the empty state (perspective row visible only). - The leaf chips (the final event_category / event_type the user picks to drive the deadline) keep rendering as today. Only the PATH to them becomes row-by-row. - Build clean per commit (`go build ./...` + `bun run build.ts`). - DE+EN i18n on every new label. - No hour estimates. - Honour the .entity-table row-click contract — though this is a chip-cluster surface, not a table. ## Files to start with - `frontend/src/client/fristenrechner.ts` — cascade machinery (Slice 3b/3c shipped here) - `frontend/src/fristenrechner.tsx` — JSX shell - `frontend/src/styles/global.css` — `.fristen-perspective-bar`, `.fristen-inbox-chip`, `.fr-cascade-*` rules to extend - `frontend/src/client/i18n.ts` — new prompts per cascade depth (DE+EN) ## Out of scope - Backend changes — the event_category cascade hierarchy (paliad.event_categories) stays as-is. - The leaf event-type picker styling. - Mobile-specific layout — should still work on mobile but no re-imagining. Filed by paliad/head from m's 2026-05-08 22:16 instruction.
mAi commented 2026-05-13 09:18:58 +00:00
Author
Collaborator
Copy Link

2026-05-13 m — expanding the scope

m's verbatim:

Now I am focusing on the Fristenrechner. When I select a project, it should already narrow down the options (at least if it is a court proceeding). If it is a UPC proceeding, there is no need to show 'non-UPC options'; this starts with the 'how did you receive it?' which - for the UPC - will always be the UPC CMS.

Not only is the different format for the levels of the questions weird (this needs an overhaul!), also there is no narrowing at all. I already described before that I want each decision on the tree to remain visible (one row per decision, it may be more compact than the active question was) and then go through things until there are only the least possible options left.

Three pillars now in scope for t-paliad-166:

1. Project-driven narrowing (new). When a project is selected (Akte mode), the cascade pre-fills / hides incompatible options:

  • UPC project → 'Wo kam es an?' pre-set to CMS (or skipped entirely; design decision).
  • UPC project → cascade leaves tagged non-UPC are hidden.
  • DE project → analogous narrowing for beA / Posteingang surfaces.
  • project.our_side → 'Ich vertrete' pre-set (t-paliad-164 already does this; verify still works).

Data-layer caveats (per kelvin's t-178 audit):

  • paliad.projects.court is free-text (NOT FK) — fuzzy-match only, never silent FK promotion.
  • paliad.projects.proceeding_type_id points at category=litigation rows (INF/REV/CCR/APM/APP/AMD/ZPO_CIVIL — 7 codes), while the Fristenrechner wizard accepts category=fristenrechner codes (UPC_INF/DE_INF/EPA_OPP/… — 20 codes). A mapping is needed; instance dimension (LG/OLG/BGH) isn't on projects today.
  • 11/11 live projects have NULL proceeding_type_id — silent degrade to 'no narrowing' is acceptable per m's 2026-05-13 00:00 sign-off.

2. Visual hierarchy overhaul (new). Current Pathway B layers:

  • Mode toggle 'Schritt-für-Schritt' vs 'Filter / Suche' (radio).
  • 'Ich vertrete' (button chips).
  • 'Wo kam es an?' (button chips).
  • 'Was ist passiert?' (cascade cards).

Three functionally different things, three visually different treatments. m calls this 'weird'. Inventor: design a consistent hierarchy.

3. Row-by-row persistent cascade (original #25 scope). Each answered decision stays as a compact row; the active question is the only one expanded. Replaces the breadcrumb drilldown.

The three are intertwined: the row-by-row layout needs to know which decisions to skip (narrowing) and how to render answered vs active rows consistently (hierarchy).

Unblocking t-paliad-166. Inventor design pass starting now.

## 2026-05-13 m — expanding the scope m's verbatim: > Now I am focusing on the Fristenrechner. When I select a project, it should already narrow down the options (at least if it is a court proceeding). If it is a UPC proceeding, there is no need to show 'non-UPC options'; this starts with the 'how did you receive it?' which - for the UPC - will always be the UPC CMS. > > Not only is the different format for the levels of the questions weird (this needs an overhaul!), also there is no narrowing at all. I already described before that I want each decision on the tree to remain visible (one row per decision, it may be more compact than the active question was) and then go through things until there are only the least possible options left. Three pillars now in scope for t-paliad-166: **1. Project-driven narrowing (new).** When a project is selected (Akte mode), the cascade pre-fills / hides incompatible options: - UPC project → 'Wo kam es an?' pre-set to CMS (or skipped entirely; design decision). - UPC project → cascade leaves tagged non-UPC are hidden. - DE project → analogous narrowing for beA / Posteingang surfaces. - `project.our_side` → 'Ich vertrete' pre-set (t-paliad-164 already does this; verify still works). **Data-layer caveats (per kelvin's t-178 audit):** - `paliad.projects.court` is free-text (NOT FK) — fuzzy-match only, never silent FK promotion. - `paliad.projects.proceeding_type_id` points at category=litigation rows (INF/REV/CCR/APM/APP/AMD/ZPO_CIVIL — 7 codes), while the Fristenrechner wizard accepts category=fristenrechner codes (UPC_INF/DE_INF/EPA_OPP/… — 20 codes). A mapping is needed; instance dimension (LG/OLG/BGH) isn't on projects today. - 11/11 live projects have NULL `proceeding_type_id` — silent degrade to 'no narrowing' is acceptable per m's 2026-05-13 00:00 sign-off. **2. Visual hierarchy overhaul (new).** Current Pathway B layers: - Mode toggle 'Schritt-für-Schritt' vs 'Filter / Suche' (radio). - 'Ich vertrete' (button chips). - 'Wo kam es an?' (button chips). - 'Was ist passiert?' (cascade cards). Three functionally different things, three visually different treatments. m calls this 'weird'. Inventor: design a consistent hierarchy. **3. Row-by-row persistent cascade (original #25 scope).** Each answered decision stays as a compact row; the active question is the only one expanded. Replaces the breadcrumb drilldown. The three are intertwined: the row-by-row layout needs to know which decisions to *skip* (narrowing) and how to render *answered* vs *active* rows consistently (hierarchy). Unblocking t-paliad-166. Inventor design pass starting now.
mAi commented 2026-05-13 09:27:27 +00:00
Author
Collaborator
Copy Link

DESIGN READY FOR REVIEW — t-paliad-166 Determinator B1 row-by-row cascade

Filed at docs/design-determinator-row-cascade-2026-05-13.md (704 lines, commit 7c4bc39 on mai/pauli/determinator-b1-row-by, pushed).

The three pillars (intertwined):

  1. Project-driven narrowing — UPC project hides Wo kam es an? entirely (CMS implied); our_side pre-fills perspective (t-paliad-164 generalized); proceeding_type_id + jurisdiction map to a fristenrechner code that pre-walks single-child cascade chains.
  2. Visual hierarchy overhaul — one .fristen-row primitive replaces radio (Mode) + chip-strip (Perspective) + chip-strip (Inbox) + breadcrumb-cards (Cascade). Same label + answer-area + ändern anatomy across every decision row.
  3. Row-by-row persistent cascade — answered rows stay visible as 28px compact rows with [ändern]; only the active row expands. The user sees their full decision path top-to-bottom instead of behind tiny breadcrumb crumbs.

§0 live-state corrections to the brief (none invalidate the design, all confirmed against live DB / source):

  • 91/103 cascade leaves carry a forum tag → narrowing already has real bite.
  • 16/103 carry party tag (all under ich-moechte-einreichen.*) → perspective filters outgoing-write only, which is correct.
  • 11/11 live projects have NULL proceeding_type_id → Slice 2 narrowing degrades gracefully to forum-only via court free-text fuzzy match. Backfill is a Q13 follow-up.
  • 4 distinct condition_flag value-sets exist (UPC_INF + UPC_REV only) — variant chips are out of scope here.
  • verfahrensablauf-core.ts (t-paliad-179) carries zero cascade leakage — confirmed independent.

Slicing (three independent PRs):

  • Slice 1 — visual primitive only. No backend, no narrowing change. m can validate the layout in isolation.
  • Slice 2 — litigation_code × jurisdiction → fristenrechner_code helper + auto-walk + hide-R2-on-UPC. Shared proceeding_mapping.go with t-paliad-178 Slice 2.
  • Slice 3 — mobile breakpoints + search escape-hatch relocation.

§13 has 15 open questions for m — mode-toggle disposition (kill the radio?), UPC R2 hide vs compact, auto-walk magic, ändern affordance shape, prefilled-override permanence, search escape-hatch position, counterclaim variant rows, backfill nudge for NULL proceeding_type_id, and more.

Inventor parked. NOT self-merged. Awaiting m's go/no-go before coder shift starts.

— pauli

**DESIGN READY FOR REVIEW** — t-paliad-166 Determinator B1 row-by-row cascade Filed at `docs/design-determinator-row-cascade-2026-05-13.md` (704 lines, commit 7c4bc39 on `mai/pauli/determinator-b1-row-by`, pushed). **The three pillars (intertwined):** 1. **Project-driven narrowing** — UPC project hides `Wo kam es an?` entirely (CMS implied); `our_side` pre-fills perspective (t-paliad-164 generalized); `proceeding_type_id` + jurisdiction map to a fristenrechner code that pre-walks single-child cascade chains. 2. **Visual hierarchy overhaul** — one `.fristen-row` primitive replaces radio (Mode) + chip-strip (Perspective) + chip-strip (Inbox) + breadcrumb-cards (Cascade). Same label + answer-area + ändern anatomy across every decision row. 3. **Row-by-row persistent cascade** — answered rows stay visible as 28px compact rows with `[ändern]`; only the active row expands. The user sees their full decision path top-to-bottom instead of behind tiny breadcrumb crumbs. **§0 live-state corrections to the brief** (none invalidate the design, all confirmed against live DB / source): - 91/103 cascade leaves carry a forum tag → narrowing already has real bite. - 16/103 carry party tag (all under `ich-moechte-einreichen.*`) → perspective filters outgoing-write only, which is correct. - **11/11 live projects have NULL `proceeding_type_id`** → Slice 2 narrowing degrades gracefully to forum-only via `court` free-text fuzzy match. Backfill is a Q13 follow-up. - 4 distinct `condition_flag` value-sets exist (UPC_INF + UPC_REV only) — variant chips are out of scope here. - `verfahrensablauf-core.ts` (t-paliad-179) carries zero cascade leakage — confirmed independent. **Slicing (three independent PRs):** - **Slice 1** — visual primitive only. No backend, no narrowing change. m can validate the layout in isolation. - **Slice 2** — `litigation_code × jurisdiction → fristenrechner_code` helper + auto-walk + hide-R2-on-UPC. Shared `proceeding_mapping.go` with t-paliad-178 Slice 2. - **Slice 3** — mobile breakpoints + search escape-hatch relocation. **§13 has 15 open questions for m** — mode-toggle disposition (kill the radio?), UPC R2 hide vs compact, auto-walk magic, ändern affordance shape, prefilled-override permanence, search escape-hatch position, counterclaim variant rows, backfill nudge for NULL proceeding_type_id, and more. Inventor parked. NOT self-merged. Awaiting m's go/no-go before coder shift starts. — pauli
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#25
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?