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

Verfahrensablauf: party selector goes AFTER proceeding-type selector (defines proceeding too; auto-filled when project data present) #111

New Issue
Open
opened 2026-05-25 14:40:24 +00:00 by mAi · 2 comments
mAi commented 2026-05-25 14:40:24 +00:00
Collaborator
Copy Link

m's report (2026-05-25 16:39)

in Verfahrensablauf, the selection of the party defines the proceeding a lot - therefore it should be defined after the type of proceedings. Because this is what we would not have to select when we have good project data, too -

Scope

Reorder the Verfahrensablauf 'Browse a proceeding' form so the user input flow matches the importance hierarchy of inputs:

  1. Proceeding type (first — defines which rules / tracks are even relevant)
  2. Party / side (second — defines whose perspective; auto-fills the columns)
  3. Appellant (for appeal-type proceedings only)
  4. Other knobs (date overrides, etc.)

Current form ordering puts party-side either above or alongside proceeding type. The desired ordering acknowledges that:

  • Without proceeding type, party-side is meaningless
  • With proceeding type chosen, party-side is the most defining next input
  • For projects WITH our_side set, party-side auto-fills (read-only display + 'override' affordance per t-paliad-257 / #88)

What to do

  1. Open the Verfahrensablauf 'Browse' page (likely frontend/src/verfahrensablauf.tsx + client/verfahrensablauf.ts).
  2. Find the form layout — the proceeding-type picker and the side/appellant selectors hermes shipped in #81 + #88.
  3. Move the side selector below the proceeding-type picker (visually + DOM order). Add a small dividing element between them so the dependency reads naturally.
  4. The appellant selector stays its own row, only visible when the proceeding type is appeal-flavored. Place it below the side selector.
  5. Project-auto-fill (when our_side is set on the project): show the side selector as already-resolved (read-only chip with the inferred side + 'Andere Seite wählen' link to override).
  6. Make sure URL state remains backward-compatible — ?side=... and ?appellant=... still work even if the form's render order changes.

Files most likely touched

  • frontend/src/verfahrensablauf.tsx
  • frontend/src/client/verfahrensablauf.ts
  • frontend/src/styles/global.css (small spacing tweaks if the new order changes the visual rhythm)

Hard rules

  • No backend / projection logic change — this is pure form ordering.
  • Mobile + desktop must both render the new order cleanly.
  • go build ./... && go test ./internal/... && cd frontend && bun run build clean.
  • Branch: mai/<worker>/verfahrensablauf-form-reorder.

Out of scope

  • Changing the side/appellant semantics (those are locked from #88).
  • Per-card overrides (that's #96).
  • Browse-a-proceeding picker styling beyond reorder.

Reporting

mai report completed with branch + SHAs + before/after layout description.

## m's report (2026-05-25 16:39) > in Verfahrensablauf, the selection of the party defines the proceeding a lot - therefore it should be defined after the type of proceedings. Because this is what we would not have to select when we have good project data, too - ## Scope Reorder the Verfahrensablauf 'Browse a proceeding' form so the user input flow matches the **importance hierarchy** of inputs: 1. **Proceeding type** (first — defines which rules / tracks are even relevant) 2. **Party / side** (second — defines whose perspective; auto-fills the columns) 3. Appellant (for appeal-type proceedings only) 4. Other knobs (date overrides, etc.) Current form ordering puts party-side either above or alongside proceeding type. The desired ordering acknowledges that: - Without proceeding type, party-side is meaningless - With proceeding type chosen, party-side is the most defining next input - For projects WITH `our_side` set, party-side auto-fills (read-only display + 'override' affordance per t-paliad-257 / #88) ## What to do 1. Open the Verfahrensablauf 'Browse' page (likely `frontend/src/verfahrensablauf.tsx` + `client/verfahrensablauf.ts`). 2. Find the form layout — the proceeding-type picker and the side/appellant selectors hermes shipped in #81 + #88. 3. Move the side selector below the proceeding-type picker (visually + DOM order). Add a small dividing element between them so the dependency reads naturally. 4. The appellant selector stays its own row, only visible when the proceeding type is appeal-flavored. Place it below the side selector. 5. Project-auto-fill (when `our_side` is set on the project): show the side selector as **already-resolved** (read-only chip with the inferred side + 'Andere Seite wählen' link to override). 6. Make sure URL state remains backward-compatible — `?side=...` and `?appellant=...` still work even if the form's render order changes. ## Files most likely touched - `frontend/src/verfahrensablauf.tsx` - `frontend/src/client/verfahrensablauf.ts` - `frontend/src/styles/global.css` (small spacing tweaks if the new order changes the visual rhythm) ## Hard rules - No backend / projection logic change — this is pure form ordering. - Mobile + desktop must both render the new order cleanly. - `go build ./... && go test ./internal/... && cd frontend && bun run build` clean. - Branch: `mai/<worker>/verfahrensablauf-form-reorder`. ## Out of scope - Changing the side/appellant semantics (those are locked from #88). - Per-card overrides (that's #96). - Browse-a-proceeding picker styling beyond reorder. ## Reporting `mai report completed` with branch + SHAs + before/after layout description.
mAi self-assigned this 2026-05-25 14:40:24 +00:00
mAi commented 2026-05-25 14:52:08 +00:00
Author
Collaborator
Copy Link

Done — t-paliad-279 / m/paliad#111 reorder shipped

Branch: mai/icarus/gitster-verfahrensablauf
Commit: a6d0acb

Before / after layout

Step 2 — Before (single "Ausgangsdatum eingeben" block):

┌─ 2  Ausgangsdatum eingeben ─────────────────┐
│  Auslösendes Ereignis: …                    │
│  Datum: [____]                              │
│  [Gericht: …]                               │
│  [☐ Mit Widerklage auf Nichtigkeit]         │
│  [Fristen berechnen]                        │
│                                             │
│  Seite: ○ Klägerseite ○ Beklagtenseite ⦿ Beide │  ← side at bottom
│  Berufung durch: …                          │
└─────────────────────────────────────────────┘

Step 2 — After ("Perspektive und Datum" — side first):

┌─ 2  Perspektive und Datum ──────────────────┐
│  Seite: ○ Klägerseite ○ Beklagtenseite ⦿ Beide │  ← side moved up
│  Berufung durch: …  (only for appeals)      │
│  ─────────────────────────────────────      │  ← divider
│  Auslösendes Ereignis: …                    │
│  Datum: [____]                              │
│  [Gericht: …]                               │
│  [☐ Mit Widerklage auf Nichtigkeit]         │
│  [Fristen berechnen]                        │
└─────────────────────────────────────────────┘

Matches the importance hierarchy in the scope: proceeding-type (step 1) → party-side → appellant → date / court / flags.

Project auto-fill (?project=)

When the page is opened with ?project=<id> and that project has our_side set, the side row renders as a read-only chip instead of the radio cluster:

Seite:  ┌── Aus Akte: Klägerseite  ( Andere Seite wählen ) ──┐
  • our_side maps onto the side axis the same way fristenrechner.ts does: claimant/applicant/appellant → claimant; defendant/respondent → defendant; everything else (third_party/other/NULL) → no auto-fill (stays at radio cluster).
  • URL wins over project: an explicit ?side= short-circuits the auto-fill so shared ?side= links never get clobbered by ?project=.
  • Override link swaps back to the radio cluster and drops ?project= from the URL (keeps ?side= so the user's pick survives reload).
  • Chip label is language-aware via onLangChange.

URL state — backward-compatible

  • ?side=claimant|defendant — unchanged, still drives the radio cluster + perspective column routing.
  • ?appellant=claimant|defendant — unchanged, still drives the appellant-row collapse.
  • ?project=<id> — new, opt-in. Pages without it behave identically to before.

Files touched (5, +274 / −48)

  • frontend/src/verfahrensablauf.tsx — DOM reorder, #side-radio-cluster wrap, #side-chip sibling, divider, step-2 heading swap.
  • frontend/src/client/verfahrensablauf.ts — ?project= reader, fetchProjectOurSide, ourSideToSide, applySidePrefill, renderSideChip, clearSidePrefill, lang-change hook for the chip label.
  • frontend/src/styles/global.css — .verfahrensablauf-step2-divider, .side-chip + tag / value / override styles (visual family with .proceeding-summary).
  • frontend/src/client/i18n.ts + frontend/src/i18n-keys.ts — 3 new keys (deadlines.step2.perspective, deadlines.side.from_project, deadlines.side.override) in DE + EN.

Verification

  • cd frontend && bun run build — clean.
  • cd frontend && bun test — 154 pass, 0 fail (verfahrensablauf-core column-routing tests still green: 14 pass, 35 expect).
  • go build ./... — clean.
  • go test ./internal/... — all packages pass.
  • No backend / projection logic touched (per hard rule).

Notes

  • Mobile + desktop both render the new order cleanly — .verfahrensablauf-perspective-row uses flex-wrap: wrap so the chip / radios drop to a new line on narrow viewports.
  • Per-card overrides remain out of scope (that's m/paliad#96).
## Done — t-paliad-279 / m/paliad#111 reorder shipped **Branch:** `mai/icarus/gitster-verfahrensablauf` **Commit:** [a6d0acb](https://mgit.msbls.de/m/paliad/commit/a6d0acbcb431576d6bdb850070a856d60cd85781) ### Before / after layout **Step 2 — Before** (single "Ausgangsdatum eingeben" block): ``` ┌─ 2 Ausgangsdatum eingeben ─────────────────┐ │ Auslösendes Ereignis: … │ │ Datum: [____] │ │ [Gericht: …] │ │ [☐ Mit Widerklage auf Nichtigkeit] │ │ [Fristen berechnen] │ │ │ │ Seite: ○ Klägerseite ○ Beklagtenseite ⦿ Beide │ ← side at bottom │ Berufung durch: … │ └─────────────────────────────────────────────┘ ``` **Step 2 — After** ("Perspektive und Datum" — side first): ``` ┌─ 2 Perspektive und Datum ──────────────────┐ │ Seite: ○ Klägerseite ○ Beklagtenseite ⦿ Beide │ ← side moved up │ Berufung durch: … (only for appeals) │ │ ───────────────────────────────────── │ ← divider │ Auslösendes Ereignis: … │ │ Datum: [____] │ │ [Gericht: …] │ │ [☐ Mit Widerklage auf Nichtigkeit] │ │ [Fristen berechnen] │ └─────────────────────────────────────────────┘ ``` Matches the importance hierarchy in the scope: proceeding-type (step 1) → party-side → appellant → date / court / flags. ### Project auto-fill (?project=<id>) When the page is opened with `?project=<id>` and that project has `our_side` set, the side row renders as a read-only chip instead of the radio cluster: ``` Seite: ┌── Aus Akte: Klägerseite ( Andere Seite wählen ) ──┐ ``` - our_side maps onto the side axis the same way fristenrechner.ts does: `claimant`/`applicant`/`appellant` → `claimant`; `defendant`/`respondent` → `defendant`; everything else (`third_party`/`other`/NULL) → no auto-fill (stays at radio cluster). - URL wins over project: an explicit `?side=` short-circuits the auto-fill so shared `?side=` links never get clobbered by `?project=`. - Override link swaps back to the radio cluster and drops `?project=` from the URL (keeps `?side=` so the user's pick survives reload). - Chip label is language-aware via `onLangChange`. ### URL state — backward-compatible - `?side=claimant|defendant` — unchanged, still drives the radio cluster + perspective column routing. - `?appellant=claimant|defendant` — unchanged, still drives the appellant-row collapse. - `?project=<id>` — new, opt-in. Pages without it behave identically to before. ### Files touched (5, +274 / −48) - `frontend/src/verfahrensablauf.tsx` — DOM reorder, `#side-radio-cluster` wrap, `#side-chip` sibling, divider, step-2 heading swap. - `frontend/src/client/verfahrensablauf.ts` — `?project=` reader, `fetchProjectOurSide`, `ourSideToSide`, `applySidePrefill`, `renderSideChip`, `clearSidePrefill`, lang-change hook for the chip label. - `frontend/src/styles/global.css` — `.verfahrensablauf-step2-divider`, `.side-chip` + tag / value / override styles (visual family with `.proceeding-summary`). - `frontend/src/client/i18n.ts` + `frontend/src/i18n-keys.ts` — 3 new keys (`deadlines.step2.perspective`, `deadlines.side.from_project`, `deadlines.side.override`) in DE + EN. ### Verification - `cd frontend && bun run build` — clean. - `cd frontend && bun test` — 154 pass, 0 fail (verfahrensablauf-core column-routing tests still green: 14 pass, 35 expect). - `go build ./...` — clean. - `go test ./internal/...` — all packages pass. - No backend / projection logic touched (per hard rule). ### Notes - Mobile + desktop both render the new order cleanly — `.verfahrensablauf-perspective-row` uses `flex-wrap: wrap` so the chip / radios drop to a new line on narrow viewports. - Per-card overrides remain out of scope (that's m/paliad#96).
mAi commented 2026-07-29 16:26:07 +00:00
Author
Collaborator
Copy Link

Sweep verdict (2026-07-29): SUPERSEDED.

The form this reorders no longer exists. /tools/verfahrensablauf hard-301s to /tools/procedures (internal/handlers/fristenrechner.go:20-38, U4 of #151), and /tools/procedures has no "Browse a proceeding" form — entry is via three builder modes (builder.mode.cold / .event / .akte, frontend/src/procedures.tsx:102-121).

This issue's own hard rule — "pure form ordering, no backend change" — is what makes it unrescuable: there is no such form to reorder.

Full sweep: docs/findings-issue-sweep-2026-07-29.md (commit 4c39886).

**Sweep verdict (2026-07-29): SUPERSEDED.** The form this reorders no longer exists. `/tools/verfahrensablauf` hard-301s to `/tools/procedures` (`internal/handlers/fristenrechner.go:20-38`, U4 of #151), and `/tools/procedures` has no "Browse a proceeding" form — entry is via three builder modes (`builder.mode.cold` / `.event` / `.akte`, `frontend/src/procedures.tsx:102-121`). This issue's own hard rule — "pure form ordering, no backend change" — is what makes it unrescuable: there is no such form to reorder. Full sweep: `docs/findings-issue-sweep-2026-07-29.md` (commit 4c39886).
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#111
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?