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

UPC Provisional Measures (upc.pi.cfi): missing appeal route + related deadlines #118

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

m's report (2026-05-25 17:19)

The appeal is also missing from the provisional measures structure. There are related deadlines which are not here, yet. Didnt we apply on card choices already so we can have appeals etc? The whole idea of the Verfahrensablauf is to show a timeline for upcoming proceedings.

Context

atlas's t-paliad-265 (#96) Slice A+B shipped per-event-card choices PLUS the projection engine extension (IncludeCCRFor, AppellantContext). But the data (the rules themselves) for the appeal route from upc.pi.cfi (Provisional Measures) is NOT populated yet — so even with the per-card mechanism, the appeal sub-tree doesn't render because no is_spawn/spawn_proceeding_type_id rule exists.

Same structural gap as #117 (UPC Damages) — sibling proceedings, same fix shape.

What to do

  1. Inspect current upc.pi.cfi rules — what's there, what's missing.
  2. Add the post-PI-decision steps:
    • Appeal route from PI decision — is_spawn=true rule pointing at upc.apl.merits (or upc.apl.order for procedural-order appeals, depending on which RoP applies; coder verifies — likely R.220 for the order-appeal track since PI is an order, not a merits-decision; possibly R.223 for the merits-of-PI-injunction appeal).
    • Notice of Appeal + Statement of Grounds + Response to Appeal + Cross-Appeal + Reply to Cross-Appeal — same structure as the inf appeal track (UPC RoP R.220 onwards). For PI specifically the period might be shorter — verify against the audit doc + RoP.
  3. Check curie's #94 audit — §3.1 (UPC RoP missing rules) may already flag some of these.
  4. Cross-reference with #117 (UPC Damages followup, ritchie just got that). Both share the appeal-spawn pattern.

Coordination

  • ritchie is on #117 (UPC Damages followup). Either ritchie absorbs this in the same shift (recommended — same migration), OR a separate worker takes it.
  • Migration slot: if ritchie expands, both fit in slot 133. If separate, this lands on slot 134.

Head will dispatch the cleanest path — likely instructs ritchie to expand his shift.

Files most likely touched

  • The slot 133 (or 134) migration
  • Possibly internal/services/projection_service.go if the spawn execution needs help (overlaps with curie's Q13 / Wave 5)

Hard rules

  • Use atlas #96 mechanism: the spawn execution + per-card appellant should work for these rules once they exist in the catalog.
  • Cite RoP rule numbers per row.
  • go build ./... && go test ./internal/... && cd frontend && bun run build clean.
  • Branch: depends on who picks this up.

Out of scope

  • Cross-jurisdictional PI variations (national patent law PI flows).
  • Replacing the per-card-choices system (that's #96 territory, already shipped).

Reporting

mai report completed with branch + SHAs + migration slot + rules added (PI proceeding-specific + appeal chain) + UX verification: open a PI project → confirm appeal route appears as expected after the PI decision card.

## m's report (2026-05-25 17:19) > The appeal is also missing from the provisional measures structure. There are related deadlines which are not here, yet. Didnt we apply on card choices already so we can have appeals etc? The whole idea of the Verfahrensablauf is to show a timeline for upcoming proceedings. ## Context atlas's t-paliad-265 (#96) Slice A+B shipped per-event-card choices PLUS the projection engine extension (`IncludeCCRFor`, `AppellantContext`). But the *data* (the rules themselves) for the appeal route from `upc.pi.cfi` (Provisional Measures) is NOT populated yet — so even with the per-card mechanism, the appeal sub-tree doesn't render because no `is_spawn`/`spawn_proceeding_type_id` rule exists. Same structural gap as #117 (UPC Damages) — sibling proceedings, same fix shape. ## What to do 1. Inspect current `upc.pi.cfi` rules — what's there, what's missing. 2. Add the post-PI-decision steps: - **Appeal route from PI decision** — `is_spawn=true` rule pointing at `upc.apl.merits` (or `upc.apl.order` for procedural-order appeals, depending on which RoP applies; coder verifies — likely R.220 for the order-appeal track since PI is an order, not a merits-decision; possibly R.223 for the merits-of-PI-injunction appeal). - **Notice of Appeal** + **Statement of Grounds** + **Response to Appeal** + **Cross-Appeal** + **Reply to Cross-Appeal** — same structure as the inf appeal track (UPC RoP R.220 onwards). For PI specifically the period might be shorter — verify against the audit doc + RoP. 3. Check curie's #94 audit — §3.1 (UPC RoP missing rules) may already flag some of these. 4. Cross-reference with #117 (UPC Damages followup, ritchie just got that). Both share the appeal-spawn pattern. ## Coordination - **ritchie is on #117** (UPC Damages followup). Either ritchie absorbs this in the same shift (recommended — same migration), OR a separate worker takes it. - **Migration slot**: if ritchie expands, both fit in slot 133. If separate, this lands on slot 134. Head will dispatch the cleanest path — likely instructs ritchie to expand his shift. ## Files most likely touched - The slot 133 (or 134) migration - Possibly `internal/services/projection_service.go` if the spawn execution needs help (overlaps with curie's Q13 / Wave 5) ## Hard rules - **Use atlas #96 mechanism**: the spawn execution + per-card appellant should work for these rules once they exist in the catalog. - Cite RoP rule numbers per row. - `go build ./... && go test ./internal/... && cd frontend && bun run build` clean. - Branch: depends on who picks this up. ## Out of scope - Cross-jurisdictional PI variations (national patent law PI flows). - Replacing the per-card-choices system (that's #96 territory, already shipped). ## Reporting `mai report completed` with branch + SHAs + migration slot + rules added (PI proceeding-specific + appeal chain) + UX verification: open a PI project → confirm appeal route appears as expected after the PI decision card.
mAi self-assigned this 2026-05-25 15:19:58 +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#118
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?