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

Unified procedural-events tool — multi-dimensional display, filter, sequence, selection (consolidate surfaces) #151

New Issue
Open
opened 2026-05-27 17:14:51 +00:00 by mAi · 1 comment
mAi commented 2026-05-27 17:14:51 +00:00
Collaborator
Copy Link

m's framing (2026-05-27 19:13)

There are many dimensions by which we can display and filter our procedural events. Maybe we should hire an inventor to find out the best methods from the ones we already have? It makes sense to narrow things, display them in sequence and context, make selections etc. It just needs to be done well, preferably in a unitary tool. There should be alternative means to derive at what you want to derive at.

Today's surfaces (the things to consolidate or organise)

Multiple tools already cover overlapping ground:

  1. /tools/fristenrechner — dual-mode (Direkt Suchen + Geführt) → result view with follow-ups (shipped 2026-05-26 → 2026-05-27 via m/paliad#146 + #149 P3). Entry-from-event.
  2. /tools/verfahrensablauf — sequence-from-proceeding-type. Three-way detail filter (Nur Pflicht / Gewählt / Alle Optionen) shipped this session. Per-rule scenario_flags binding live.
  3. /admin/procedural-events — admin editor (lifecycle-state aware, clone-publish workflow).
  4. /projects/{id} Verlauf — per-Akte timeline (deadlines + appointments + project events).
  5. SmartTimeline (projection-based, internal use).
  6. youpc.org/deadlines — cross-repo public surface via embedded snapshot.

Each answers a different shape of question:

  • Something happened, what now? → Fristenrechner Mode B
  • What's the typical ablauf of proceeding X? → Verfahrensablauf
  • What did happen on my Akte and what's next? → /projects/{id} Verlauf + SmartTimeline
  • What rules exist and how do I edit them? → /admin/procedural-events

The dimensions a procedural event carries (today's data model)

Dimension Source Cardinality
forum proceeding_types.jurisdiction 4 (UPC/DE/EPA/DPMA)
proceeding_type proceeding_types filtered to kind='proceeding' 23 active
proceeding_kind (proceeding/phase/side_action/meta) proceeding_types.kind 4 (mig 153)
event_kind procedural_events.event_kind 5 (filing/hearing/decision/order/NULL)
primary_party sequencing_rules.primary_party claimant/defendant/both/court/NULL
priority sequencing_rules.priority mandatory/recommended/optional
conditional sequencing_rules.condition_expr IS NOT NULL + project scenario_flags boolean per rule
spawn sequencing_rules.is_spawn rare (4 today)
court-set sequencing_rules.is_court_set timing flag
chain depth derived from parent_id walk sequence position
selection state projects.scenario_flags (per-project) + rule:<uuid> overrides per-rule per-project
view-mode localStorage 'verfahrensablauf:view_mode' Nur Pflicht / Gewählt / Alle Optionen
temporal anchor sequencing_rules.duration_value + duration_unit + timing computed forward from trigger date

Acceptance for the inventor pass

Deliverable: docs/design-unified-procedural-events-tool-2026-05-NN.md covering:

  1. Audit of today's surfaces — for each of the 6 tools above, list the user question it answers, what dimensions it filters/shows, what it does well, what it does poorly, what overlaps with another surface.
  2. Consolidation proposal — single unified surface OR clear taxonomy of "which tool for which question". Don't blindly merge; if 2 tools are correctly separated by task shape, document why. m's signal favours unification when it works.
  3. Multi-dimensional filter spec — for each dimension above, where it appears in the unified surface (top filter chip / drill-down / hover / hidden). Some dimensions are filters, some are display-grouping, some are anchor-data.
  4. Alternative paths spec — m's "alternative means to derive at what you want" requirement. At minimum two paths to the same outcome (e.g. a German-Lawyer-Approach: pick proceeding → see ablauf vs a UPC-Lawyer-Approach: type event → see follow-ups). Different paths converge on the same per-rule output.
  5. Selection state — how the unified tool surfaces and persists scenario_flags + per-rule selections (already shipped via P0 SSoT). Where the chips/checkboxes live, how they propagate across views.
  6. Sequence visualisation — how to render the parent_id chain visually (vertical tree? horizontal timeline? collapsible groups? per-priority lanes?).
  7. Context preservation — when a user drills into a single rule from one entry, how to keep the surrounding sequence visible.
  8. Mobile / narrow viewport — what collapses, what hides, what stays. The current Verfahrensablauf timeline is desktop-heavy.
  9. Worked examples — 3 personas: trainee PA looking for "what's next after Klageerwiderung", senior partner browsing full ablauf of upc.inf.cfi to brief a client, paralegal entering a CMS-received Hinweisbeschluss into an Akte.
  10. Migration plan — which existing surface(s) survive as canonical, which redirect, which deprecate. 2-week dual-shipping window expected.

Use AskUserQuestion freely (m has authorised). Batch in 4-question chunks. Park after 'UNIFIED TOOL DESIGN READY FOR REVIEW'. Inventor-coder gate held.

Out of scope

  • Replacing the calculator (pkg/litigationplanner.CalculateRule). Working.
  • Replacing /admin/procedural-events as an editorial-write surface — the unified tool is for READING.
  • Cross-repo (youpc.org) UI changes. Snapshot consumer.
  • Outlook / Calendar sync UI.
  • The Akte (project) Verlauf — separate surface for per-project actuals, not part of the unified ablauf-tool.

Cross-references

  • m/paliad#146 — Fristenrechner overhaul (shipped)
  • m/paliad#147 — proceeding_types taxonomy (shipped)
  • m/paliad#149 — Phase 2 RFC (shipped, editorial backlog continuing)
  • docs/design-deadline-system-revision-2026-05-27.md (Phase 2 design with view-mode toggle)
  • docs/design-fristenrechner-overhaul-2026-05-26.md (dual-entry-path design)
## m's framing (2026-05-27 19:13) > There are many dimensions by which we can display and filter our procedural events. Maybe we should hire an inventor to find out the best methods from the ones we already have? It makes sense to narrow things, display them in sequence and context, make selections etc. It just needs to be done well, preferably in a unitary tool. There should be alternative means to derive at what you want to derive at. ## Today's surfaces (the things to consolidate or organise) Multiple tools already cover overlapping ground: 1. `/tools/fristenrechner` — dual-mode (Direkt Suchen + Geführt) → result view with follow-ups (shipped 2026-05-26 → 2026-05-27 via m/paliad#146 + #149 P3). Entry-from-event. 2. `/tools/verfahrensablauf` — sequence-from-proceeding-type. Three-way detail filter (Nur Pflicht / Gewählt / Alle Optionen) shipped this session. Per-rule scenario_flags binding live. 3. `/admin/procedural-events` — admin editor (lifecycle-state aware, clone-publish workflow). 4. `/projects/{id}` Verlauf — per-Akte timeline (deadlines + appointments + project events). 5. SmartTimeline (projection-based, internal use). 6. `youpc.org/deadlines` — cross-repo public surface via embedded snapshot. Each answers a different shape of question: - *Something happened, what now?* → Fristenrechner Mode B - *What's the typical ablauf of proceeding X?* → Verfahrensablauf - *What did happen on my Akte and what's next?* → /projects/{id} Verlauf + SmartTimeline - *What rules exist and how do I edit them?* → /admin/procedural-events ## The dimensions a procedural event carries (today's data model) | Dimension | Source | Cardinality | |---|---|---| | forum | `proceeding_types.jurisdiction` | 4 (UPC/DE/EPA/DPMA) | | proceeding_type | `proceeding_types` filtered to `kind='proceeding'` | 23 active | | proceeding_kind (proceeding/phase/side_action/meta) | `proceeding_types.kind` | 4 (mig 153) | | event_kind | `procedural_events.event_kind` | 5 (filing/hearing/decision/order/NULL) | | primary_party | `sequencing_rules.primary_party` | claimant/defendant/both/court/NULL | | priority | `sequencing_rules.priority` | mandatory/recommended/optional | | conditional | `sequencing_rules.condition_expr IS NOT NULL` + project scenario_flags | boolean per rule | | spawn | `sequencing_rules.is_spawn` | rare (4 today) | | court-set | `sequencing_rules.is_court_set` | timing flag | | chain depth | derived from parent_id walk | sequence position | | selection state | `projects.scenario_flags` (per-project) + `rule:<uuid>` overrides | per-rule per-project | | view-mode | localStorage 'verfahrensablauf:view_mode' | Nur Pflicht / Gewählt / Alle Optionen | | temporal anchor | `sequencing_rules.duration_value + duration_unit + timing` | computed forward from trigger date | ## Acceptance for the inventor pass Deliverable: `docs/design-unified-procedural-events-tool-2026-05-NN.md` covering: 1. **Audit of today's surfaces** — for each of the 6 tools above, list the user question it answers, what dimensions it filters/shows, what it does well, what it does poorly, what overlaps with another surface. 2. **Consolidation proposal** — single unified surface OR clear taxonomy of "which tool for which question". Don't blindly merge; if 2 tools are correctly separated by task shape, document why. m's signal favours unification when it works. 3. **Multi-dimensional filter spec** — for each dimension above, where it appears in the unified surface (top filter chip / drill-down / hover / hidden). Some dimensions are filters, some are display-grouping, some are anchor-data. 4. **Alternative paths spec** — m's "alternative means to derive at what you want" requirement. At minimum two paths to the same outcome (e.g. a German-Lawyer-Approach: pick proceeding → see ablauf vs a UPC-Lawyer-Approach: type event → see follow-ups). Different paths converge on the same per-rule output. 5. **Selection state** — how the unified tool surfaces and persists scenario_flags + per-rule selections (already shipped via P0 SSoT). Where the chips/checkboxes live, how they propagate across views. 6. **Sequence visualisation** — how to render the parent_id chain visually (vertical tree? horizontal timeline? collapsible groups? per-priority lanes?). 7. **Context preservation** — when a user drills into a single rule from one entry, how to keep the surrounding sequence visible. 8. **Mobile / narrow viewport** — what collapses, what hides, what stays. The current Verfahrensablauf timeline is desktop-heavy. 9. **Worked examples** — 3 personas: trainee PA looking for "what's next after Klageerwiderung", senior partner browsing full ablauf of upc.inf.cfi to brief a client, paralegal entering a CMS-received Hinweisbeschluss into an Akte. 10. **Migration plan** — which existing surface(s) survive as canonical, which redirect, which deprecate. 2-week dual-shipping window expected. Use AskUserQuestion freely (m has authorised). Batch in 4-question chunks. Park after 'UNIFIED TOOL DESIGN READY FOR REVIEW'. Inventor-coder gate held. ## Out of scope - Replacing the calculator (`pkg/litigationplanner.CalculateRule`). Working. - Replacing /admin/procedural-events as an editorial-write surface — the unified tool is for READING. - Cross-repo (youpc.org) UI changes. Snapshot consumer. - Outlook / Calendar sync UI. - The Akte (project) Verlauf — separate surface for per-project actuals, not part of the unified ablauf-tool. ## Cross-references - m/paliad#146 — Fristenrechner overhaul (shipped) - m/paliad#147 — proceeding_types taxonomy (shipped) - m/paliad#149 — Phase 2 RFC (shipped, editorial backlog continuing) - `docs/design-deadline-system-revision-2026-05-27.md` (Phase 2 design with view-mode toggle) - `docs/design-fristenrechner-overhaul-2026-05-26.md` (dual-entry-path design)
mAi self-assigned this 2026-05-27 17:14:51 +00:00
mAi commented 2026-05-27 18:35:21 +00:00
Author
Collaborator
Copy Link

U0–U4 train shipped (knuth, t-paliad-335)

Five commits on branch mai/knuth/coder-unified-procedural, one slice per commit per the design's §11 train:

  • U0 Skeleton — page shell, filter strip with search box, four entry-mode tabs visible from boot. Commit 60907e7.
  • U1 Folded Mode A (Direkt suchen). mountModeA() mounts under #procedures-panel-search; ?event=<code> deep links resolve to the result view inside the same tab. Commit 0568d34.
  • U2 Folded Mode B (Geführt wizard). Wizard renders into #fristen-overhaul-mode-host; installOverhaulHost() tears down + rebuilds the host inside whichever tab activates so the duplicate-ID lookups don't cross-wire. Commit c8261da.
  • U3 Folded Verfahrensablauf tree + 3-way detail filter. Extracted the wizard body markup into the shared <VerfahrensablaufBody> TSX component used by both the legacy /tools/verfahrensablauf and the unified /tools/procedures page. Lifted initVerfahrensablauf() out of the auto-DOMContentLoaded so procedures.ts can call it explicitly on first proceeding-tab activation. Commit 48a07ef.
  • U4 Hard-cut. Both legacy URLs are 301-permanent redirects to /tools/procedures (query strings preserved). Legacy *.tsx + client/fristenrechner.ts deleted. Sidebar, Header, index.tsx, paliadin-context.ts, deadlineSearchService.pillDrillURL all repointed. Unused nav.fristenrechner / nav.verfahrensablauf / tools.verfahrensablauf.* i18n keys removed. Commit 39c8ef3.

Quality gates per slice: bun run build clean, 264 frontend tests pass, go vet ./... clean, go test ./... clean (including the new TestLegacyToolsPagesRedirect covering both URLs naked and with query).

Out of scope for this train (deferred per the design §13 + the issue brief): inline drawer pivot under tree cards (design §8), search-box-in-filter-strip composition with chip filters across all output modes (m's Q3 reframe), Akte tab data wiring, 3-column swimlane toggle, mobile breadcrumb-back drill. These are surface-layer extensions that compose cleanly on top of the U0–U4 substrate.

## U0–U4 train shipped (knuth, t-paliad-335) Five commits on branch `mai/knuth/coder-unified-procedural`, one slice per commit per the design's §11 train: - **U0** Skeleton — page shell, filter strip with search box, four entry-mode tabs visible from boot. Commit [60907e7](https://mgit.msbls.de/m/paliad/commit/60907e7). - **U1** Folded Mode A (Direkt suchen). [`mountModeA()`](https://mgit.msbls.de/m/paliad/src/branch/mai/knuth/coder-unified-procedural/frontend/src/client/fristenrechner-mode-a.ts) mounts under `#procedures-panel-search`; `?event=<code>` deep links resolve to the result view inside the same tab. Commit [0568d34](https://mgit.msbls.de/m/paliad/commit/0568d34). - **U2** Folded Mode B (Geführt wizard). Wizard renders into `#fristen-overhaul-mode-host`; `installOverhaulHost()` tears down + rebuilds the host inside whichever tab activates so the duplicate-ID lookups don't cross-wire. Commit [c8261da](https://mgit.msbls.de/m/paliad/commit/c8261da). - **U3** Folded Verfahrensablauf tree + 3-way detail filter. Extracted the wizard body markup into the shared `<VerfahrensablaufBody>` TSX component used by both the legacy `/tools/verfahrensablauf` and the unified `/tools/procedures` page. Lifted `initVerfahrensablauf()` out of the auto-DOMContentLoaded so procedures.ts can call it explicitly on first proceeding-tab activation. Commit [48a07ef](https://mgit.msbls.de/m/paliad/commit/48a07ef). - **U4** Hard-cut. Both legacy URLs are 301-permanent redirects to `/tools/procedures` (query strings preserved). Legacy `*.tsx` + `client/fristenrechner.ts` deleted. Sidebar, Header, `index.tsx`, `paliadin-context.ts`, `deadlineSearchService.pillDrillURL` all repointed. Unused nav.fristenrechner / nav.verfahrensablauf / tools.verfahrensablauf.* i18n keys removed. Commit [39c8ef3](https://mgit.msbls.de/m/paliad/commit/39c8ef3). **Quality gates per slice:** `bun run build` clean, 264 frontend tests pass, `go vet ./...` clean, `go test ./...` clean (including the new `TestLegacyToolsPagesRedirect` covering both URLs naked and with query). **Out of scope for this train** (deferred per the design §13 + the issue brief): inline drawer pivot under tree cards (design §8), search-box-in-filter-strip composition with chip filters across all output modes (m's Q3 reframe), Akte tab data wiring, 3-column swimlane toggle, mobile breadcrumb-back drill. These are surface-layer extensions that compose cleanly on top of the U0–U4 substrate.
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#151
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?