m/paliad
1
0
Fork 0
Code Issues 151 Pull Requests 4 Actions 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 · 1 comment
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
mAi commented 2026-07-29 16:33:25 +00:00
Author
Collaborator
Copy Link

Sweep verdict, corrected (2026-07-29): ALREADY DONE.

An earlier version of my sweep recorded this as STILL TRUE. That was wrong and I have corrected it in docs/findings-issue-sweep-2026-07-29.md (commit 3b20c2c).

What is actually true. pkg/litigationplanner/engine.go:415-425 overrides the user-facing dependency identity whenever a rule carries a trigger_event_id, and names this issue in the comment:

Trigger-event override on the user-facing dependency identity (m/paliad#126 / t-paliad-294). When a rule has a real trigger_event_id, that catalog event is the actual semantic anchor — not the parent_id node, which is only the calc-time arithmetic anchor.

So ParentRuleName is replaced with the trigger event's name before projection_service.go:984 reads it. For upc.inf.cfi.confidentiality_response (trigger 25) the chip resolves to "Antrag auf Vertraulichkeit gegenüber der Öffentlichkeit" — what m asked for.

Pinned by internal/services/fristenrechner_test.go:600-612, which asserts the trigger anchor and carries a negative guard that fails if ParentRuleName == "Klageerhebung". It passes. Migration 183 restored trigger_event_id=25 after a 2026-05-31 admin edit nulled it.

The model, for the next reader. parent_id and trigger_event_id are two different anchors and are meant to differ — parent_id is the calc-time arithmetic anchor, trigger_event_id the semantic one. Migration 184's header states this, and 184 deliberately created such a disagreement for translations_lodge. A row whose parent and trigger name different events is the designed pattern.

Measured: 196 active sequencing rules, 112 with a parent, 39 with a trigger, 9 with both. Exactly one of the nine has them naming different events — this row — and it is correct.

Not closing — only m closes issues.

**Sweep verdict, corrected (2026-07-29): ALREADY DONE.** An earlier version of my sweep recorded this as STILL TRUE. That was wrong and I have corrected it in `docs/findings-issue-sweep-2026-07-29.md` (commit 3b20c2c). **What is actually true.** `pkg/litigationplanner/engine.go:415-425` overrides the user-facing dependency identity whenever a rule carries a `trigger_event_id`, and names this issue in the comment: > Trigger-event override on the user-facing dependency identity (m/paliad#126 / t-paliad-294). When a rule has a real `trigger_event_id`, that catalog event is the actual semantic anchor — not the `parent_id` node, which is only the calc-time arithmetic anchor. So `ParentRuleName` is replaced with the trigger event's name **before** `projection_service.go:984` reads it. For `upc.inf.cfi.confidentiality_response` (trigger 25) the chip resolves to "Antrag auf Vertraulichkeit gegenüber der Öffentlichkeit" — what m asked for. Pinned by `internal/services/fristenrechner_test.go:600-612`, which asserts the trigger anchor **and** carries a negative guard that fails if `ParentRuleName == "Klageerhebung"`. It passes. Migration 183 restored `trigger_event_id=25` after a 2026-05-31 admin edit nulled it. **The model, for the next reader.** `parent_id` and `trigger_event_id` are two different anchors and are **meant** to differ — `parent_id` is the calc-time arithmetic anchor, `trigger_event_id` the semantic one. Migration 184's header states this, and 184 deliberately created such a disagreement for `translations_lodge`. A row whose parent and trigger name different events is the designed pattern. Measured: 196 active sequencing rules, 112 with a parent, 39 with a trigger, **9 with both**. Exactly one of the nine has them naming different events — this row — and it is correct. Not closing — only m closes issues.
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?