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

Conditional rendering: wrong parent — R.262(2) shows 'abhängig von Klageerhebung' instead of 'abhängig von Vertraulichkeitsantrag' #126

New Issue
Open
opened 2026-05-26 09:09:24 +00:00 by mAi · 0 comments
mAi commented 2026-05-26 09:09:24 +00:00
Collaborator
Copy Link

m's report (2026-05-26 11:08)

Erwiderung auf Vertraulichkeitsantrag
abhängig von Klageerhebung
UPC RoP R.262(2)
Frist 14 Tage ab Zustellung des Vertraulichkeitsantrags der Gegenseite (R.262.2).

That is wrong - it is not abhängig from klageerhebung but from an actual confidentiality application.

Root cause hypothesis

knuth's #121 conditional-rendering picks 'abhängig von ' where <parent> is the rule's parent_id resolved to its name. For R.262(2):

  • The rule has parent_id pointing at the proceeding root (Klageerhebung)
  • BUT the actual semantic trigger is the opposing party's Vertraulichkeitsantrag, which is itself an OPTIONAL event in the catalog
  • Resolution: the conditional label should use the rule's trigger_event (or legal_source-implied event) — NOT the parent_id's name

What to do

  1. Audit how the conditional label resolves the parent name in knuth's code (probably internal/services/fristenrechner.go near the IsConditional block).
  2. Replace the lookup chain:
    • Preferred: rule's trigger_event_id → trigger event's display name (this is the actual semantic anchor)
    • Fallback: rule's notes / description if there's a specific event mentioned
    • Last resort: parent_id (current behavior, wrong for R.262(2))
  3. For R.262(2) specifically, the trigger event is the opposing party's Vertraulichkeitsantrag (R.262 application for confidentiality). Verify there's a trigger_event row for this — if not, the audit doc (curie's #94) may have flagged it as a missing piece.
  4. Add a regression test asserting R.262(2)'s conditional label reads 'abhängig von Vertraulichkeitsantrag' (or whatever the canonical event name is in DE/EN).

Files most likely touched

  • internal/services/fristenrechner.go — IsConditional label resolution
  • internal/services/projection_service.go
  • internal/services/fristenrechner_test.go
  • Possibly a small i18n addition if 'Vertraulichkeitsantrag' isn't yet a canonical event name
  • paliad.trigger_events data check: does the row exist?

Hard rules

  • Don't change the conditional-state visual treatment (knuth #121's CSS stays).
  • Don't change the projection of NON-conditional rules.
  • Same fix should generalise: any rule with a real trigger_event_id should use THAT name, not the parent_id name.
  • go build ./... && go test ./internal/... && cd frontend && bun run build clean.
  • Branch: mai/<worker>/conditional-parent-trigger-event.

Out of scope

  • Adding new trigger_event rows for missing optional events (separate task if R.262(2)'s anchor is genuinely missing).
  • Reworking the IsConditional detection itself.

Reporting

mai report completed with branch + SHAs + UX path: open UPC inf project → confirm R.262(2) conditional row reads 'abhängig von Vertraulichkeitsantrag' (or equivalent). Audit a few other conditional rules to make sure the change doesn't regress them.

## m's report (2026-05-26 11:08) > Erwiderung auf Vertraulichkeitsantrag > abhängig von Klageerhebung > UPC RoP R.262(2) > Frist 14 Tage ab Zustellung des Vertraulichkeitsantrags der Gegenseite (R.262.2). > > That is wrong - it is not abhängig from klageerhebung but from an actual confidentiality application. ## Root cause hypothesis knuth's #121 conditional-rendering picks 'abhängig von <parent>' where `<parent>` is the rule's `parent_id` resolved to its name. For R.262(2): - The rule has `parent_id` pointing at the proceeding root (Klageerhebung) - BUT the **actual semantic trigger** is the opposing party's Vertraulichkeitsantrag, which is itself an OPTIONAL event in the catalog - Resolution: the conditional label should use the rule's `trigger_event` (or `legal_source`-implied event) — NOT the `parent_id`'s name ## What to do 1. Audit how the conditional label resolves the parent name in knuth's code (probably `internal/services/fristenrechner.go` near the IsConditional block). 2. Replace the lookup chain: - **Preferred**: rule's `trigger_event_id` → trigger event's display name (this is the actual semantic anchor) - **Fallback**: rule's notes / description if there's a specific event mentioned - **Last resort**: `parent_id` (current behavior, wrong for R.262(2)) 3. For R.262(2) specifically, the trigger event is the **opposing party's Vertraulichkeitsantrag** (R.262 application for confidentiality). Verify there's a trigger_event row for this — if not, the audit doc (curie's #94) may have flagged it as a missing piece. 4. Add a regression test asserting R.262(2)'s conditional label reads 'abhängig von Vertraulichkeitsantrag' (or whatever the canonical event name is in DE/EN). ## Files most likely touched - `internal/services/fristenrechner.go` — IsConditional label resolution - `internal/services/projection_service.go` - `internal/services/fristenrechner_test.go` - Possibly a small i18n addition if 'Vertraulichkeitsantrag' isn't yet a canonical event name - `paliad.trigger_events` data check: does the row exist? ## Hard rules - Don't change the conditional-state visual treatment (knuth #121's CSS stays). - Don't change the projection of NON-conditional rules. - Same fix should generalise: any rule with a real trigger_event_id should use THAT name, not the parent_id name. - `go build ./... && go test ./internal/... && cd frontend && bun run build` clean. - Branch: `mai/<worker>/conditional-parent-trigger-event`. ## Out of scope - Adding new trigger_event rows for missing optional events (separate task if R.262(2)'s anchor is genuinely missing). - Reworking the IsConditional detection itself. ## Reporting `mai report completed` with branch + SHAs + UX path: open UPC inf project → confirm R.262(2) conditional row reads 'abhängig von Vertraulichkeitsantrag' (or equivalent). Audit a few other conditional rules to make sure the change doesn't regress them.
mAi self-assigned this 2026-05-26 09:09:24 +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#126
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?