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

Verfahrensablauf: per-event-card optional choices (appellant per decision, Nichtigkeitswiderklage on Klageerwiderung, skip optional events) — inventor #96

New Issue
Open
opened 2026-05-25 13:15:10 +00:00 by mAi · 0 comments
mAi commented 2026-05-25 13:15:10 +00:00
Collaborator
Copy Link

m's report (2026-05-25 15:12)

We still have no choice to say that a specific party appealed. We may need selections within the event cards on the timeline to change it? For example for a decision we could check Appeal by... or in Klageerwiderung we can chose to include a Nichtigkeitswiderklage. Or with any optional event we can select not to consider it (because someone decided not to file it)

Concept — per-event-card choices steer the projection

Today the Verfahrensablauf timeline is mostly read-only (column placement is the only user input — fixed at the page level via the side selector that t-paliad-257 / #88 shipped). m wants the timeline cards themselves to become state inputs for the projection:

  1. Appellant per decision — for any decision-type card, a checkbox / radio: "Appeal by: ☐ Claimant ☐ Defendant ☐ Both ☐ None". Selecting drives downstream appeal-deadline projection.
  2. Include Nichtigkeitswiderklage on Klageerwiderung — for a Klageerwiderung card, an optional toggle: "☐ Include Nichtigkeitswiderklage". Selecting splits the timeline to also project CCR/UPC ccr.cfi deadlines.
  3. Skip an optional event — for any rule marked optional (party-discretionary), a per-card toggle: "☐ Don't consider for this case". Hides downstream consequences of that event.
  4. (Implicit) Each card's choice persists per-project so reloading shows the same projection.

Phase: inventor design (READ-ONLY)

Inventor → coder gate per project CLAUDE.md.

Open design questions

Q1 — Where does the state live?

A. paliad.project_event_choices new table: (project_id, event_code, choice_kind, choice_value, …). Persisted, per-project, joined into the projection at render time. Survives reload, audit-logged.
B. URL query state like the side + appellant selectors today: ?event_choices=event_code:value,event_code:value,.... Ephemeral, shareable via URL, no persistence.
C. Both: persisted by default, URL-overridable for what-if scenarios.

(R) = A (persisted default; what-if exploration handled later as a URL-override on top). Most case-level choices are real, not exploratory.

Q2 — Affordance: inline-on-card vs popover-on-card-click?

A. Inline checkbox/radio on every relevant card. Risk: visual noise; most cards have no choices.
B. Caret/menu on each card (▾) that opens a popover with the available choices. Cleaner default, +1 click for power-use.
C. Card hover reveals the choices with click to commit. Risk: discoverability + touch-device pain.

(R) = B (caret/menu popover). Off-by-default visual, on-tap reveal.

Q3 — How does the rule system know which cards are "optional" or have choices?

A new column on paliad.deadline_rules: choices jsonb describing the choice-kinds applicable to that rule. Example:

{"appellant": ["claimant", "defendant", "both", "none"]}
{"include_ccr": [true, false]}
{"skip": [true, false]}

Projection consumes paliad.project_event_choices (Q1 table) joined against paliad.deadline_rules.choices. Default: when no choice set, treat as the catalog default (e.g. "both parties" or "include").

Q4 — Interaction with the project-level our_side / appellant selectors

t-paliad-257's project-level side selector + the existing appellant selector are the BROAD axis. Per-card choices are the FINE axis. Decide:

  • (R) The per-card appellant choice OVERRIDES the project-level appellant for THAT specific decision card. Useful when both parties appeal independently.
  • Alt: per-card choice INHERITS project-level unless explicitly set.

Matters for how the per-card UI defaults its display.

Q5 — Audit trail

Every project_event_choices row insert/update goes to paliad.events (audit feed) so the team can see who set which case-direction choice when. Standard.

Q6 — Scope of v1 vs follow-ups

Slice A (this design): appellant-per-decision + skip-optional-event. Two choice-kinds, well-bounded.
Slice B: include-Nichtigkeitswiderklage-on-Klageerwiderung (more complex — splits the projection into a cross-proceeding fan-out). Inventor flags this for separate inventor pass.
Slice C: any-other-choice-kinds the audit + lawyer feedback surface later.

Deliverable

docs/design-event-card-choices-2026-05-25.md on branch mai/<inventor>/event-card-choices-design. Sections per inventor template.

Hard rules

  • READ-ONLY design phase.
  • Reuse the URL-state plumbing from t-paliad-250 / 257 where it fits.
  • NO AskUserQuestion. mai instruct head for material picks.
  • Coordinate with #93 procedural-events model — if that lands first, the paliad.deadline_rules references become paliad.procedural_events. Inventor flags the join points but doesn't pre-empt the rename.

Out of scope

  • Implementing the choice flow (separate coder task per slice).
  • Cross-project propagation of choices (each project independent).
  • Versioning of choices over time ("the appellant changed mid-case") — defer to follow-up.

When done

Push design doc + mai report completed with "DESIGN READY FOR REVIEW". Inventor parked. Head gates coder shift.

## m's report (2026-05-25 15:12) > We still have no choice to say that a specific party appealed. We may need selections within the event cards on the timeline to change it? For example for a decision we could check Appeal by... or in Klageerwiderung we can chose to include a Nichtigkeitswiderklage. Or with any optional event we can select not to consider it (because someone decided not to file it) ## Concept — per-event-card choices steer the projection Today the Verfahrensablauf timeline is mostly read-only (column placement is the only user input — fixed at the page level via the side selector that t-paliad-257 / #88 shipped). m wants the timeline cards themselves to become **state inputs** for the projection: 1. **Appellant per decision** — for any decision-type card, a checkbox / radio: "Appeal by: ☐ Claimant ☐ Defendant ☐ Both ☐ None". Selecting drives downstream appeal-deadline projection. 2. **Include Nichtigkeitswiderklage on Klageerwiderung** — for a Klageerwiderung card, an optional toggle: "☐ Include Nichtigkeitswiderklage". Selecting splits the timeline to also project CCR/UPC ccr.cfi deadlines. 3. **Skip an optional event** — for any rule marked optional (party-discretionary), a per-card toggle: "☐ Don't consider for this case". Hides downstream consequences of that event. 4. **(Implicit) Each card's choice persists per-project** so reloading shows the same projection. ## Phase: inventor design (READ-ONLY) Inventor → coder gate per project CLAUDE.md. ## Open design questions ### Q1 — Where does the state live? A. **`paliad.project_event_choices`** new table: `(project_id, event_code, choice_kind, choice_value, …)`. Persisted, per-project, joined into the projection at render time. Survives reload, audit-logged. B. **URL query state** like the side + appellant selectors today: `?event_choices=event_code:value,event_code:value,...`. Ephemeral, shareable via URL, no persistence. C. **Both**: persisted by default, URL-overridable for what-if scenarios. **(R) = A** (persisted default; what-if exploration handled later as a URL-override on top). Most case-level choices are real, not exploratory. ### Q2 — Affordance: inline-on-card vs popover-on-card-click? A. **Inline checkbox/radio** on every relevant card. Risk: visual noise; most cards have no choices. B. **Caret/menu on each card** (`▾`) that opens a popover with the available choices. Cleaner default, +1 click for power-use. C. **Card hover reveals the choices** with click to commit. Risk: discoverability + touch-device pain. **(R) = B** (caret/menu popover). Off-by-default visual, on-tap reveal. ### Q3 — How does the rule system know which cards are "optional" or have choices? A new column on `paliad.deadline_rules`: `choices jsonb` describing the choice-kinds applicable to that rule. Example: ``` {"appellant": ["claimant", "defendant", "both", "none"]} {"include_ccr": [true, false]} {"skip": [true, false]} ``` Projection consumes `paliad.project_event_choices` (Q1 table) joined against `paliad.deadline_rules.choices`. Default: when no choice set, treat as the catalog default (e.g. "both parties" or "include"). ### Q4 — Interaction with the project-level our_side / appellant selectors t-paliad-257's project-level side selector + the existing appellant selector are the BROAD axis. Per-card choices are the FINE axis. Decide: - (R) The per-card appellant choice OVERRIDES the project-level appellant for THAT specific decision card. Useful when both parties appeal independently. - Alt: per-card choice INHERITS project-level unless explicitly set. Matters for how the per-card UI defaults its display. ### Q5 — Audit trail Every `project_event_choices` row insert/update goes to `paliad.events` (audit feed) so the team can see who set which case-direction choice when. Standard. ### Q6 — Scope of v1 vs follow-ups **Slice A (this design)**: appellant-per-decision + skip-optional-event. Two choice-kinds, well-bounded. **Slice B**: include-Nichtigkeitswiderklage-on-Klageerwiderung (more complex — splits the projection into a cross-proceeding fan-out). Inventor flags this for separate inventor pass. **Slice C**: any-other-choice-kinds the audit + lawyer feedback surface later. ## Deliverable `docs/design-event-card-choices-2026-05-25.md` on branch `mai/<inventor>/event-card-choices-design`. Sections per inventor template. ## Hard rules - READ-ONLY design phase. - Reuse the URL-state plumbing from t-paliad-250 / 257 where it fits. - NO AskUserQuestion. `mai instruct head` for material picks. - **Coordinate with #93 procedural-events model** — if that lands first, the `paliad.deadline_rules` references become `paliad.procedural_events`. Inventor flags the join points but doesn't pre-empt the rename. ## Out of scope - Implementing the choice flow (separate coder task per slice). - Cross-project propagation of choices (each project independent). - Versioning of choices over time ("the appellant changed mid-case") — defer to follow-up. ## When done Push design doc + `mai report completed` with "DESIGN READY FOR REVIEW". Inventor parked. Head gates coder shift.
mAi self-assigned this 2026-05-25 13:15:10 +00:00
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#96
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?