60907e7153119734061ee7a7400362d460816e85
1261 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| 60907e7153 |
feat(procedures): U0 skeleton — /tools/procedures page shell (m/paliad#151)
First slice of the unified procedural-events tool train. Ships only the page chrome — route, sidebar/header, filter strip with search box, four entry-mode tabs (Verfahren wählen / Direkt suchen / Geführt / Aus Akte), and the host containers later slices mount their UI into. No data wiring. Per m's decisions (design §11.5): URL is English (/tools/procedures, not /tools/verfahren); all four tabs visible from boot (not a single-default landing); search box lives in the top filter strip and will compose with chip filters once U1+ wire them. U1 fills #procedures-panel-search (Mode A), U2 fills -wizard (Mode B), U3 fills -proceeding + #procedures-output-tree (Verfahrensablauf), U4 hard-cuts /tools/fristenrechner and /tools/verfahrensablauf to 301 redirects and drops the legacy pages. |
|||
| 66b08813c4 |
Merge: t-paliad-334 — unified procedural-events tool design (m/paliad#151)
cronus shipped 568-line design ratifying a single /tools/procedures page that folds Fristenrechner (Mode A + Mode B + result view) + /tools/verfahrensablauf into one surface with 4 entry tabs and tree+linear-drawer outputs.
12 m's decisions (9 on-recommendation, 3 divergent):
- Q (divergent): English URL '/tools/procedures' (over '/tools/verfahren')
- Q (divergent): all 4 entry tabs visible + search-in-filter-strip (over single default tab)
- Q (divergent): hard-cut 301 redirect (over 2-week dual-ship)
Stays separate (correctly different shape/audience):
- /admin/procedural-events (editorial write surface)
- /projects/{id} Verlauf (per-Akte actuals)
- SmartTimeline (internal projection)
- youpc.org/deadlines (cross-repo, embedded snapshot)
5-slice migration train U0-U4 (no DB mig — purely UX consolidation atop the shipped Phase 2 substrate).
Inventor parks. Head dispatches Sonnet coder per project memory directive (NOT cronus for impl).
|
|||
| 0aaa523494 |
design: fold m's 12 decisions into unified procedural-events doc (m/paliad#151)
- §11.5 m's decisions section (9 on-rec + 3 divergent) - diverged: Q2 /tools/procedures (English), Q3 all-tabs+search-in-filter-strip, Q11 hard cut no dual ship - §11.5.1 changes triggered by divergences (URL rename, all-tabs behaviour, U4 rewrite) - URL refs throughout body updated to /tools/procedures - U4 slice rewritten to 301 hard-cut per Q11 |
|||
| d49ff55c41 |
design: unified procedural-events tool (m/paliad#151 shift-1, draft)
- audit of 6 surfaces with question→dimension matrix - proposal: fold Fristenrechner + Verfahrensablauf into /tools/verfahren - 4 entry paths converge on tree + linear output shapes - mobile narrow-viewport rules + 3 worked personas - 5-slice migration train (U0-U4), no DB migration - 12 open questions in 3 batches for AskUserQuestion |
|||
| ae1c0b861d | Merge: fix admin-rules-edit URL parser regex (post B.6 rename hotfix) | |||
| c8999e2a8b |
fix(admin-rules-edit): accept /admin/procedural-events/{id}/edit in URL parser
Slice B.6 / S6 renamed the canonical edit URL from /admin/rules/{id}/edit
to /admin/procedural-events/{id}/edit. The backend handler + 301 redirect
landed, but the client-side regex in admin-rules-edit.ts:110 was missed —
it still only matches the legacy /admin/rules/.../edit shape. Result:
visiting the canonical URL from the list page shows 'Ungültige
Verfahrensschritt-ID in der URL.' even though the rule exists.
Fix: regex accepts both '/admin/procedural-events/{id}/edit' (canonical)
and '/admin/rules/{id}/edit' (legacy, kept for stale tabs / bookmarks
during the deprecation window).
m flagged 2026-05-27 17:57 on rule cc439590 (RoP.262.2, upc.inf.cfi).
|
|||
| 0365e84dd1 |
Merge: t-paliad-331 P2 + P4 partial — condition_expr validator + trigger_events partial deprecation (m/paliad#149)
ritchie shipped the final two slices of the Phase 2 train.
P2 — condition_expr write-validator:
- New internal/services/condition_expr_validator.go (136 LoC) — locks the grammar to {flag:<str>} OR {op:'and'|'or', args:[<leaf>|<composite>]} per design §4.1
- RuleEditorService.Create + Update reject non-conforming expressions
- 166-LoC test coverage; all 18 existing condition_expr rows validate
P4 (partial) — trigger_events deprecation (mig 156):
- NULLs out the 2 hybrid rules' trigger_event_id (parent_id is the canonical edge per §2.1)
- Adds 'Deprecated: see m/paliad#149' header on the legacy /api/tools/event-deadlines route
- Does NOT drop paliad.trigger_events nor the 5 read sites — those are gated on the editorial reparenting of the 73 orphan globals (NULL proceeding_type_id, served only via trigger_event_id). Editorial work is m's, not coder scope.
Comment on m/paliad#149 (issuecomment-10436) enumerates the exact next steps for the eventual follow-up coder once editorial reparenting completes.
Phase 2 train: P0 + S1+S1a + P1 + P3 + P2 + P4 partial — ALL shipped. Final P4 step waits on editorial.
|
|||
| d6a5dedb2b |
feat(deadline-system): P4 (partial) — partial trigger_events deprecation (m/paliad#149)
Phase 2 P4 partial-scope (head approved 2026-05-27 15:24). The full
drop of paliad.trigger_events + the legacy route + 5 read sites is
gated on an editorial backfill that's not in coder scope — 73 active
sequencing_rules carry proceeding_type_id IS NULL and are addressed
ONLY via trigger_event_id today. Dropping anything would break those
73 orphans.
What this lands:
1. Mig 156 — NULL out trigger_event_id on the 2 hybrid rules that
carry BOTH parent_id AND trigger_event_id. Per design §2.1 /
m's Q1, parent_id is the canonical predecessor link; the
hybrid trigger_event_id was redundant. The 2 rules' parent_id
chains keep the live edge. Live-DB verified post-apply: 0
active hybrid rules remain.
2. Deprecation + Link headers on POST /api/tools/event-deadlines
per RFC 8594 / RFC 9745. The route stays functional so the 73
orphans keep working until reparenting lands.
What this does NOT land (gated on editorial):
- DROP TABLE paliad.trigger_events
- DROP COLUMN paliad.sequencing_rules.trigger_event_id
- Remove the legacy /api/tools/event-deadlines handler
- Remove EventDeadlineService + ExportService::1680 sheet
- Remove deadline_rule_service.go:226 label-fallback path
- Remove event_type_service.go:40+414 reads (33 event_types still
reference trigger_event_id)
- Update cmd/gen-upc-snapshot/main.go:185-202 to skip trigger_events
- Drop the sequencing_rules_trigger_event_id_fkey FK
All of the above lands in a follow-up mig once the orphan count
hits zero. Comment to follow on m/paliad#149 with the editorial-
backlog list.
Verified: live-DB pre/post hybrid count (0 active hybrids remain);
mig idempotent; go vet clean.
Design: docs/design-deadline-system-revision-2026-05-27.md §2.1
(parent_id canonical), §3.4 (legacy route fate), §4.3 (table fate),
§5 (slice train P5 row). t-paliad-331.
|
|||
| 9940dd8216 |
feat(deadline-system): P2 — condition_expr write-validator (m/paliad#149)
Phase 2 P2 (design §4.1). Locks the condition_expr grammar to:
CondExpr := { "flag": "<known_flag>" }
| { "op": "and"|"or", "args": [<CondExpr>, ...] }
Where <known_flag> must exist in paliad.scenario_flag_catalog (today:
with_ccr / with_amend / with_cci; editorial adds via the catalog
table as needed).
Wire-time validation in RuleEditorService.Create and UpdateDraft —
the rule editor surfaces a 400 with a friendly message before the row
hits the DB. Empty / JSON null inputs pass through (the "no gate"
shape; stored as NULL column).
The validator:
* walks the JSON tree once, collecting every leaf flag name
* rejects mutually-exclusive shapes (leaf + composite in one node)
* rejects empty args, bad op values, empty flag strings
* does ONE batch lookup of the collected leaf names against the
catalog (regardless of expression depth)
Tests:
* 9 shape-only unit tests covering every reject path (no DB needed)
* TestValidateConditionExpr_LiveCatalog covers 6 good shapes + 2
unknown-flag cases against the live catalog
* TestConditionExpr_AllLiveRowsValidate runs the validator over
every active+published condition_expr in paliad.sequencing_rules
to enforce the §4.1 invariant on every deploy (today's 18 rows
all conform — verified via Supabase MCP pre-flight)
Live-DB tests skip cleanly when TEST_DATABASE_URL is unset (same
posture as sibling live tests in this package).
Design: docs/design-deadline-system-revision-2026-05-27.md §4.1
(grammar formalisation). t-paliad-331.
|
|||
| f6add95d0a |
Merge: t-paliad-331 P3 — Verfahrensablauf three-way detail filter (m/paliad#149)
ritchie shipped m's headline UX (paliadin priority signal 14:58): 'The new timeline filters for optional / mandatory / show only selected is what I am most waiting for. I want this to be consolidated for all our deadlines so we can simulate all proceedings.' Three-way detail-level filter above the Verfahrensablauf result panel: - Nur Pflicht — only priority='mandatory' rules - Gewählt (default) — mandatory + recommended + every explicit per-rule override in projects.scenario_flags - Alle Optionen — every rule, unselected ones rendered dotted-border + muted State persists per-user via localStorage['verfahrensablauf:view_mode']. Per-rule Aufnehmen/Entfernen chips wire to projects.scenario_flags via the P0 SSoT (rule:<uuid> entries). New files: verfahrensablauf-detail-mode.ts (125), verfahrensablauf-detail-mode.test.ts (96), filter wiring in verfahrensablauf.ts (+204) and views/verfahrensablauf-core.ts (+37). 63 LoC CSS (dotted-border treatment). bun build clean, 264 frontend tests pass (8 new), go vet clean. Ritchie continuing with P2 (condition_expr write-validator) then P4 (legacy deprecation). |
|||
| 480332a5f5 |
feat(deadline-system): P3 — three-way detail filter on Verfahrensablauf (m/paliad#149)
m's headline UX ask (2026-05-27 14:58, paliadin priority signal):
"The new timeline filters for optional / mandatory / show only
selected is what I am most waiting for. I want this to be
consolidated for all our deadlines so we can simulate all
proceedings."
Phase 2 P3. Adds a three-way detail-level filter above the result
panel on /tools/verfahrensablauf:
( ) Nur Pflicht — only priority='mandatory' rules
(•) Gewählt — mandatory + recommended (default) + every
explicit per-rule override the user has set
in projects.scenario_flags
( ) Alle Optionen — every rule, with unselected ones rendered
dotted-border + muted so the user sees what
they're NOT considering
State persists per-user via localStorage["verfahrensablauf:view_mode"].
The filter is pure client-side narrowing on the calc payload — flipping
the toggle re-renders instantly without a fresh backend call.
Per-rule selection (design §2.4a): every optional / recommended card
now carries an [Aufnehmen] / [Entfernen] chip. Clicking writes a
"rule:<uuid>" entry into the project's scenario_flags via the P0 SSoT
PATCH endpoint, recording only deviations from the priority default:
recommended + entfernen → rule:<uuid> = false (explicit deselect)
optional + aufnehmen → rule:<uuid> = true (explicit select)
flipping back to the default deletes the entry
Mandatory rules never expose the chip — they cannot be deselected.
Wire-shape change: CalculatedDeadline gains `ruleId` (the backend already
emits it as `ruleId` in TimelineEntry; only the frontend interface needed
to surface it).
Conditional handling: a conditional rule whose predicate doesn't fire
is treated as unselected in "Gewählt" mode (even when priority=
mandatory) — mandatory means "must be filed IF the predicate fires",
not "always render". The "Alle Optionen" view re-surfaces it so the
lawyer can see what scenario would unlock it.
Cross-surface coherence: hydrating ?project=<id> reads scenario_flags
from the SSoT and pre-fills the existing flag checkboxes (with_ccr /
with_amend / with_cci) so the page reflects the project's persisted
state on first paint. Every flag toggle + every per-rule chip click
PATCHes back. The page also listens for the scenario-flag-changed
CustomEvent fired by peer surfaces (Mode B Fristenrechner result-view)
and re-renders without a fresh fetch.
i18n: 5 new keys (deadlines.detail.{label,mandatory_only,selected,
all_options,optional_unselected_hint,aufnehmen,entfernen}) DE + EN.
CSS: dotted-border + muted treatment on .timeline-item-header--
unselected; .timeline-selection-chip with --add (lime accent) and
--remove (discreet muted) variants.
Tests: 8 new unit tests covering isRuleSelected (4 priority × 2 flag
state matrix) and filterByDetailMode (3 modes × default/override cases).
Verified: bun build clean, bun test 264/264 (8 new), go vet clean.
Design: docs/design-deadline-system-revision-2026-05-27.md §2.4a
(selection state model), §3.3a (view-mode toggle), §6 (Entry A spec).
t-paliad-331. Re-prioritised by m via paliadin 14:58.
|
|||
| 97d90ce651 |
Merge: t-paliad-331 — Phase 2 slices P0 + S1+S1a + P1 (m/paliad#149)
ritchie shipped three slices of the Phase 2 deadline-system revision train per design §5:
P0 — Scenario SSoT (mig 154):
- ALTER TABLE projects ADD COLUMN scenario_flags jsonb DEFAULT '{}'
- New paliad.scenario_flag_catalog table
- GET/PATCH /api/projects/{id}/scenario-flags endpoints
- Verfahrensablauf + result-view checkbox binding read+write through scenario_flags
- Per-rule selection state via 'rule:<uuid>' entries (generalises the with_ccr dropdown pattern, no new column on sequencing_rules)
- New scenario_flags_service.go (375 LoC), scenario-flags.ts client, i18n keys
S1+S1a — Cross-party display + spawn-only picker filter:
- FristenrechnerService.LookupFollowUps stops filtering by party server-side; returns all + primary_party
- UI groups: own-side checked-by-priority, cross-party annotated 'Gegenseitig' badge + unchecked
- SearchEvents SQL adds AND sr.is_spawn = false to filter spawn-only events as triggers
- lookup_events_test.go regression coverage
P1 — upc.apl re-split (m's Q5 divergence, mig 155):
- Reverts upc.apl.unified (id=160) back into upc.apl.merits / upc.apl.cost / upc.apl.order split
- Retargets 16 sequencing_rules to the appropriate split id
- Mig 155 applied to live DB per ritchie's report
Next per m's 14:58 priority signal: P3 (Entry A Verfahrensablauf tree UI with three-way view-mode toggle) — ritchie jumping straight there, then P2 + P4.
|
|||
| 3a4e99cb92 |
feat(deadline-system): P1 — upc.apl re-split into merits/cost/order (m/paliad#149)
Phase 2 P1 / m's Q5 divergence (2026-05-27, verbatim):
"Reverse the unification as suggested in 3. They are different
proceedings, I only wanted the approach to be unified in the
'determinator' — but they are actually different proceedings!"
Mig 155 reverts the mig-096 unification:
Before: id=160 upc.apl.unified active (16 rules), id=11/19/20 inactive
After: id=11 upc.apl.merits (7 rules), id=19 upc.apl.cost (2 rules),
id=20 upc.apl.order (7 rules) all active; id=160 inactive
The 16 rules under id=160 split cleanly by event_code prefix; all 10
parent_id edges among them are bucket-local (pre-flight audit), so
the tree shape survives the rebind unchanged.
Spawn FK retarget: pi.cfi.appeal_spawn flips from 11 (merits) → 20
(orders track) per design §3.1 — PI appeals land on orders, not
merits. The inf/rev/dmgs spawns keep target=11 (merits), now active.
Determinator routing layer (proceeding_mapping.go) keeps its single
"Berufung" front door per m's intent — only the data shape changes.
Pre-flight verified: 0 projects bound to id=160, 0 scenarios reference
upc.apl. Zero data migration on the project side.
Tests: lookup_events_test.go assertions on the three appeal_target
buckets updated to the new codes (endentscheidung → upc.apl.merits,
schadensbemessung → upc.apl.merits, bucheinsicht → upc.apl.order).
Same rule set, post-split coordinates.
Snapshot regen (pkg/litigationplanner/embedded/upc/) deferred: the
current snapshot only contains inf+rev so the apl re-split doesn't
shift its contents; regenerating would surface unrelated active PTs
and pollute this slice. Tracked as a follow-up.
Verified: go vet clean, go test ./internal/services/... -run
LookupEvents|proceeding_codes clean.
Design: docs/design-deadline-system-revision-2026-05-27.md §3.1
(re-split mig), §1.3 (spawn graph post-Q5). t-paliad-331.
|
|||
| 3533d79a25 |
feat(deadline-system): S1+S1a — cross-party display + spawn-only picker (m/paliad#149)
Phase 2 S1 + S1a (pre-ratified from t-paliad-327, folded into the
Phase 2 train).
S1 — Cross-party display:
- FristenrechnerService.LookupFollowUps stops filtering by party
server-side; queryFollowUpRows drops the perspective WHERE clause
and returns every published+active child.
- Server now computes is_cross_party per row (true only when
perspective ∈ {claimant,defendant} AND primary_party is the
opposite side; NULL/both/court is never cross-party).
- FollowUpRule wire shape gains the boolean.
- Frontend renderRule adds a "Gegenseitig" badge + is-cross-party
row class (muted styling, disabled checkbox affordance).
- defaultChecked returns false for cross-party rows.
- countSelected + submitWriteBack skip cross-party rows
unconditionally — even if a user manually checks the box, they
describe opposing-side filings and don't belong in our Akte set
(design §2.4 write-back exclusion).
- i18n: deadlines.overhaul.crossparty.badge / .tooltip (DE+EN).
- CSS: .fristen-overhaul-rule-crossparty + .is-cross-party row
modifier.
S1a — Spawn-only picker filter:
- SearchEvents WHERE now adds `sr.is_spawn = false` so spawn rules
(e.g. appeal_spawn, the inf.cfi → upc.apl.merits hop) no longer
surface as picker hits. Spawn rules are consequences, not
triggers — a lawyer searching "Berufung" wants the appeal-tree
root, not the inf.cfi spawn link.
- Terminal leaves (Duplik etc.) stay pickable per design §2.2's
carve-out: their own anchor is non-spawn, so they surface and
render an honest empty follow-up list.
Honest UX: hiding cross-party follow-ups lied about what the
workflow does next (cf. RoP.029.d falling off when perspective=
claimant on def_to_ccr — the workflow continues, just on the
defendant's docket). The fix makes the data legible without
contaminating the write-back path.
Verified: go vet clean, bun build clean, bun test 256/256,
go test ./internal/services/... -run LookupFollowUps... clean.
Design: docs/design-deadline-system-revision-2026-05-27.md §2.4
(cross-party) + §2.2 (spawn-only picker). t-paliad-331.
|
|||
| 2a69f7fc6c |
Merge: t-paliad-332 — UPC vacations no longer block deadlines (align with paliad t-paliad-121)
brunel aligned the embedded snapshot calendar with paliad-side policy from t-paliad-121: UPC vacation rows stay in the data for informational annotation but no longer trigger IsNonWorkingDay → AdjustForNonWorkingDays leaves dates intact. Changes: - pkg/litigationplanner/embedded/upc/holidays.go: IsNonWorkingDay now returns true only on closure (not vacation). Vacations still surface via AdjustForNonWorkingDaysWithReason for labelling. - pkg/litigationplanner/embedded/upc/holidays.json: regenerated from live paliad.holidays. Was 5 placeholders → now 55 holidays (33 vacation + 22 closures). Includes UPC Winter Vacation rows. - pkg/litigationplanner/embedded/upc/meta.json: snapshot version bump. - snapshot_test.go: +42 lines covering the vacation non-blocking behavior with regression cases. Affects youpc.org/deadlines (consumes pkg/litigationplanner via Go module replace) — picks up automatically on rebuild. |
|||
| 39353d49ed |
fix(litigationplanner): UPC vacations no longer block deadlines (align with paliad t-paliad-121)
youpc.org/deadlines was rolling a deadline "from 2027-01-02 (UPC Winter Vacation)" — i.e. across the UPC judicial vacation as if it were a public holiday. Paliad-side t-paliad-121 already decided vacations are informational only (the Court keeps running through them, RoP / UPC AC decision-on-judicial-vacation 2023-05-26), and `HolidayService.Is NonWorkingDay` in `internal/services/holidays.go` is correct. The embedded snapshot consumed by youpc.org via Go-module replace had drifted: `pkg/litigationplanner/embedded/upc/holidays.go:74` blocked on both `isClosure()` AND `isVacation()`. This commit aligns the embedded calendar with the paliad-side semantics and ships a fresh holiday set so the existing 2026/2027 fix actually takes effect downstream. Code changes (`holidays.go`): - `IsNonWorkingDay`: drop the `|| h.isVacation()` branch — only weekends and `isClosure()` rows trigger the roll. Godoc rewritten to mirror the paliad-side rationale (Court keeps operating, RoP cites, vacation rows kept for informational labels). - `isClosure()`: accept both `"public_holiday"` and `"closure"`. Live paliad DB rows use the `public_holiday` value; the placeholder snapshot shipped with the original Slice C used `closure` as a hand-crafted synonym. Reconciles with `internal/services/holidays.go:132` which already does the same union. Required to make the regenerated JSON (full of `public_holiday`) keep blocking DE national holidays after the regeneration in this commit. - Type-level godoc updated: `SnapshotHolidayCalendar` now documents vacation-is-informational, and the `AdjustForNonWorkingDaysWithReason` precedence note explains that `vacation` kind only fires when a vacation row overlaps a weekend or closure that's already doing the rolling. Data refresh (`holidays.json`): - Regenerated from paliad prod (postgres @ 100.99.98.201:11833, paliad schema). 55 rows for 2026 + 2027: 22 DE public_holiday + 33 UPC vacation (25 Summer Vacation Jul 27–Aug 28, 8 Winter Vacation Dec 24/28–31 + Jan 4–6). The previous placeholder shipped only 5 rows (3 Sommerpause + Neujahr + Tag der Arbeit, no Winter Vacation at all) — which is why a date landing in late Dec / early Jan landed inside an unmodeled gap on the consumer side. - `meta.json` bumped: version → `2026-05-27-1-holidays-only`, `holiday_count` 5 → 55, `source_db_label` flags that only holidays.json was refreshed (see friction note below). Regression test (`snapshot_test.go::TestSnapshotHolidayCalendar`): - 2026-08-04 (Tue, UPC Summer Vacation) — `IsNonWorkingDay` must be false; `AdjustForNonWorkingDays` must NOT mutate the date. - 2027-01-02 (Sat, m's flagged scenario) — must roll forward through Sat/Sun, then STOP on Mon 2027-01-04 (UPC Winter Vacation, no longer blocking). Pre-fix this rolled all the way to Thu 2027-01-07. Cross-repo: youpc.org imports `pkg/litigationplanner` via Go-module replace; the regenerated snapshot ships on its next rebuild. No separate youpc.org commit needed — paliad is the source of truth. Friction note: `cmd/gen-upc-snapshot/main.go` itself is incompatible with the current paliad schema. Migration 140 (`140_drop_deadline_rules`) dropped `paliad.deadline_rules`, but the generator still SELECTs from it (main.go ~L162). Running the tool against prod fails on the rules step. I bypassed the broken path and generated `holidays.json` directly from the DB via psql + jq (same JSON shape that `EmbeddedHoliday` expects, nulls filtered for `omitempty`). The other snapshot files (rules.json, proceeding_types.json, trigger_events.json, courts.json) remain at their pre-existing placeholder state — re-flagged in meta.json's `source_db_label`. Refitting the generator for the post- mig-140 schema is a separate task. go vet + go test ./... clean (256+ Go tests pass, including the new regression cases). |
|||
| d36cc9ee15 |
feat(deadline-system): P0 — per-project scenario_flags SSoT (m/paliad#149)
Phase 2 P0 of the deadline + procedural-events revision. Establishes
paliad.projects.scenario_flags (jsonb) + paliad.scenario_flag_catalog as
the single source of truth for per-project scenario state — replacing
the three fragmented stores athena flagged (project_event_choices,
scenarios.spec, DOM-only). All three were empty per the audit so no
data migration is needed.
The jsonb map carries two key shapes:
* named flags (whitelist via scenario_flag_catalog) — today
with_ccr / with_amend / with_cci
* per-rule selection deviations of shape "rule:<uuid>" — wired up
here for validation; the consumer UI lands in P3
Endpoints:
GET /api/projects/{id}/scenario-flags
PATCH /api/projects/{id}/scenario-flags
PATCH semantics: bool = write; null = delete (priority-driven default
returns); missing key = leave alone. The service validates every key
on write (catalog lookup + UUID rule-membership + mandatory-cannot-be-
deselected) before persisting, so a single bad key fails the whole
patch.
Frontend bind: new scenario-flags.ts client module + Mode B's flag
checkboxes (ccr-flag / inf-amend-flag / rev-amend-flag / rev-cci-flag)
now hydrate from / persist to the project's scenario_flags on every
toggle. Kontextfrei (no project) is unchanged. Cross-surface coherence
via a scenario-flag-changed CustomEvent (peer surfaces — Verfahrens-
ablauf strip, Mode B result-view — will subscribe in P3).
Mig 154 is audit-defensive (set_config of paliad.audit_reason); no
audit trigger fires on paliad.projects today but a future one will
inherit the reason. Seeds the three known flags. CHECK constraints
enforce the top-level shape (jsonb_typeof = 'object') and the
catalog key pattern (lowercase, not 'rule:%' prefix).
Verified against the live DB: 18 projects default to '{}', catalog
has 3 rows, applied_migrations advanced to 154.
Design: docs/design-deadline-system-revision-2026-05-27.md §2.3, §2.4a,
§4.1, §5 (P0 row). t-paliad-331.
|
|||
| a9fd979cdb |
Merge: t-paliad-330 — timeline view dark-mode CSS token migration
brunel converted hardcoded hex to existing design tokens for the .timeline-* classes (Verfahrensablauf at ?view=timeline). No new tokens introduced; 11 existing tokens reused. Layout/spacing untouched. Mirrors the t-paliad-326 playbook applied earlier to the Fristenrechner overhaul CSS, but on the separate timeline view that wasn't in scope then. |
|||
| c48fa93e3d |
fix(verfahrensablauf): dark-mode token migration for timeline view CSS
The /tools/verfahrensablauf?view=timeline page (and the columns-view mirror via `.fr-col-item--*` modifiers) had hardcoded light backgrounds that survived a dark-mode flip. Root cause: four undefined custom properties (`--color-bg-soft`, `--color-border-soft`, `--color-accent-bg`, `--brand-lime`) consumed by the `.timeline-*` and adjacent `.event-card-choices-*` rules, each with a hardcoded hex / RGBA fallback. Since neither :root nor :root[data-theme='dark'] defines those tokens, every consumer fell through to the light fallback in both themes — leaving the conditional-row bg, the popover surface, the option-button bg, the chip-skipped bg, and the popover block-separator border stuck on near-white in dark mode. Earlier t-paliad-326 covered the new Fristenrechner overhaul CSS only; the timeline view styles are a separate block (~L3337-3810 in `frontend/src/styles/global.css`) and were not touched. Migrate every consumer to the existing dual-theme tokens already used across paliad. Same approach m approved for t-paliad-326, no new tokens introduced (all reuse): - Card / popover surfaces (`.event-card-choices-popover`, `.event-card-choices-option`) → `--color-surface` (white light / card-tint dark) so the popover reads as raised above the body in both themes. - Subtle raised surface for conditional row, skipped chip, option hover (`.timeline-item--conditional .timeline-content`, `.fr-col-item--conditional`, `.event-card-choices-chip-part--skipped`, `.event-card-choices-option:hover/:focus-visible`) → `--color-surface-muted`. **This is the visible bug fix m flagged.** - Lime-tint backdrops (`.timeline-context-note` bg, `.event-card-choices-caret:hover/:focus-visible`) → `--color-bg-lime-tint` (lime-alpha 0.10 light / 0.12 dark). - Active-option chip bg (`.event-card-choices-chip-part`) → `--color-accent-soft-bg`. - Lime accent borders / fills (`.timeline-context-note` left border, `.timeline-date--overridden`, `.frist-date-edit-input`, `.event-card-choices-unhide-btn`, `.event-card-choices-option--active`) → `--color-accent` / `--color-accent-fg`. Drops the legacy `#c6f41c` fallback that doesn't match the current brand (`--hlc-lime: #BFF355`). - Neutral borders (`.event-card-choices-caret`, `.timeline-item--hidden .timeline-content`, `.fr-col-item--hidden`, `.timeline-item--conditional .timeline-content`, `.event-card-choices-popover`, `.event-card-choices-option`, `.event-card-choices-block + .event-card-choices-block`) → `--color-border` (warm cream-derived light / cream-alpha dark). - Popover shadow `rgba(0, 0, 0, 0.12)` → `var(--shadow-md)` (auto-deepens to `rgba(0, 0, 0, 0.45)` in dark). - Status red (`.event-card-choices-error`) → `--status-red-fg` (defined in both themes; old `#b00020` fallback unreachable). Zero new tokens introduced — every replacement uses a token already shipped in both :root and :root[data-theme='dark']. Verified by mounting `frontend/dist/assets/global.css` against a representative static DOM (context-note banner, every timeline-item variant — conditional / skipped / hidden / overridden-date / mandatory — popover with active/inactive options, unhide button, error message, all four party-badge stances) and toggling `data-theme` between light and dark: conditional row bg flips from grey to muted-cream-on- midnight, popover lifts off the body via `--shadow-md`, every chip and border stays legible in both themes. bun build + bun test (256 pass) + go vet clean. |
|||
| 5f7a66bbec |
Merge: t-paliad-329 — Phase 2 deadline + procedural-events full revision design (m/paliad#149)
atlas shipped the comprehensive Phase 2 design covering Option B (full revision absorbs t-paliad-327 narrow scope). 776 lines.
Spine: connection schema for all procedural events as ASCII trees per PT + Mermaid spawn graph. parent_id canonical, trigger_event_id deprecated.
Tier 1 (4 questions, all on-recommendation):
- parent_id canonical predecessor link
- Trigger discoverability via derived EXISTS check
- Scenario state SSoT in projects.scenario_flags jsonb (mig 154)
- Cross-party display contract
Tier 2 (4 questions, 1 divergent):
- Q5 m diverged: revert upc.apl.unified back into merits/cost/order split (mig P1 retargets 16 rules)
- Spawn-only events excluded from picker
- Entry A 'sequence-from-proceeding-type' view extends /tools/verfahrensablauf
- Legacy /api/tools/event-deadlines + paliad.trigger_events deprecated
Tier 3: condition_expr grammar formalised ({flag} / {op:and|or,args:[...]}), editorial backfill workflow on /admin/procedural-events parent-NULL filter, trigger_events table dropped.
Shift-2 additions (per m's 14:31-14:35 direction, folded in
|
|||
| 490c8a8c8c |
design(deadline-system): fold m's selection + view-mode + R.109 additions (t-paliad-329)
m's clarification at 14:40 reframed the original "rarity" framing: every
optional rule is a per-scenario selectable card; the Verfahrensablauf
gets a three-way detail-level filter (Nur Pflicht / Gewählt / Alle
Optionen). The CCR-dropdown pattern generalises to per-rule chips.
Three folded additions:
§2.4a — Selection state + detail-level filter. NO new column on
sequencing_rules (reverts the earlier is_edge_case strawman). Extends
projects.scenario_flags jsonb to carry both named flags (with_ccr etc.)
and per-rule entries (rule:<uuid>). Storage only carries deviations
from the priority default (recommended = default-selected,
optional = default-unselected). Whitelist accepts rule:<uuid> when the
UUID resolves to an active rule on the project's PT.
§3.3a — Verfahrensablauf view-mode toggle: three-way segmented control,
localStorage persistence, default "Gewählt". Mode B result view stays
single-purpose (no view-mode toggle there).
§4.2.1 — R.109 translation chain editorial worked example: R.109.1 stays
as optional anchor; R.109.4 reparents to R.109.1 with condition_expr
{flag: with_interpreter_denied} and primary_party=both (parties, not
court); R.109.5 reparents to R.109.1 with {flag: with_translation_granted}.
Introduces two new flags to scenario_flag_catalog.
§6 UI spec updated: two mocked tree states (Gewählt + Alle Optionen)
showing the dotted-border [Aufnehmen] chips, [Entfernen] on selected
optionals, greyed-with-hint on flag-gated conditionals, and the
subtree-hide-on-unselected-ancestor render logic.
§10.0a captures the additions; §10.1 notes they don't change the slice
train (P0 + P3 take the extended scope; no new mig).
|
|||
| b1c9e8dd97 |
design(deadline-system): Phase 2 revision — connection schema + 12 m's decisions (t-paliad-329)
Builds on athena's Phase 1 assessment (
|
|||
| 9aee9e4101 |
Merge: t-paliad-328 — Phase 1 assessment of the deadline + procedural-events system (m/paliad#149)
athena delivered the consultant audit per RFC m/paliad#149 Phase 1: - 738-line doc, read-only, no design proposals - §1 consumer audit: every service / handler / frontend / migration that touches sequencing_rules or procedural_events, cited file:line - §2 health-check: green / yellow / red / dead-code buckets - §3 corpus quality: parent_id 47% coverage, condition_expr keys, spawn distribution, primary_party by PT, court-set, trigger_event_id overlap - §4 editorial gap map per proceeding_type - §5 risk register: 11 items, severities marked - §6 recommendation: Tier 1 model decisions to grill first, Tier 2 surface decisions, Tier 3 editorial+cleanup Headline risks bumped from the RFC's framing: - R1 cross-party filter (high) — 39 rules dropped - R2 picker over-accepts (high) — only 67/222 events are real chain-anchors - R3 4 spawn rules target inactive proceeding_type id=11 (high) — dangling FK - R4 73 legacy globals with NULL PT (medium) — invisible to Mode B - R5 5 surfaces still read legacy trigger_events bigint table (medium) - R6 3 scenario stores, all empty but all live (medium) — clarified: paliad.scenarios.spec jsonb is mig 145, not projects.scenarios as the RFC misstated Phase 2 (inventor) gates on m's go. The inventor reads this + RFC + grills m on Tier 1 before sketching. |
|||
| 810b65463e |
docs(assessment): Phase 1 audit — deadline + procedural-events system (m/paliad#149)
t-paliad-328. Read-only audit of every consumer of paliad.sequencing_rules + paliad.procedural_events + the legacy paliad.trigger_events, plus the rules-corpus quality on the live database. No design — Phase 2 (inventor) gates on this landing. Highlights: - 226 active+published rules / 222 events (1:1 since mig 136) - parent_id chain vs trigger_event_id are functionally disjoint (2/226 overlap); 73 legacy globals own the trigger_event_id lane - 11 risk items captured with file:line; B1 (cross-party follow-up filter) and B2 (picker accepts spawn-only + leaves) confirmed from code at fristenrechner_followups.go:358-367 and :241-287 - 4 spawn rules still point at the inactive upc.apl.merits (id=11); the active appeal type is id=160 (upc.apl.unified) - 6 active proceeding_types are entirely unruled - 3 scenario stores wired (project_event_choices, scenarios table, DOM state); all currently empty, so divergence is dormant - 738 lines (under the 800 cap) Recommendation §6 sequences Tier 1 model decisions ahead of Tier 2 surface decisions and Tier 3 editorial cleanup for the inventor. |
|||
| 33c5fb2983 |
Merge: t-paliad-326 — dark-mode token migration for Fristenrechner overhaul CSS (m/paliad#146 follow-up)
brunel fixed m's bug ('Das CSS vom neuen Fristenrechner scheint wieder keinen Darkmode zu supporten') by migrating the 121 hardcoded hex colors knuth added in S2/S3/S4 to the project's design-token system.
Net: 161 inserts / 123 deletes in frontend/src/styles/global.css. 10 new tokens added to :root and :root[data-theme='dark'] for the few shades that didn't have an existing variable (group dividers, party-stance backgrounds, filter-pill subtle states). All 121 hex usages replaced with var(--color-*) references.
Verified visually via standalone harness: trigger card, 4 priority groups, per-rule rows (claimant/defendant/both/court), Mode A filter strip + result list, Mode B wizard with Filter/Qualifier badges, kontextfrei nudge, write-back footer, success/error toasts — all flip cleanly between light and dark. Layout/spacing/sizing untouched.
bun build + go vet clean.
|
|||
| 76d38c4c84 |
fix(fristenrechner): dark-mode token migration for overhaul CSS (m/paliad#146)
The Fristenrechner overhaul CSS shipped in S2/S3/S4 (commits |
|||
| 233547297c |
Merge: t-paliad-323 Slice S6 — Fristenrechner cleanup (m/paliad#146 SHIPPED)
knuth shipped S6, the final slice of the Fristenrechner overhaul: - frontend/src/client/fristenrechner.ts shrinks by 137 LoC (legacy Pathway-B neutralised; row-stack subtree wired off behind ?legacy=1). - internal/handlers/fristenrechner_event_categories.go dropped — the /api/tools/fristenrechner/event-categories endpoint is gone (route deregistered in handlers.go). - paliad.event_categories table stays for future tools (the hidden 'Ich möchte einreichen' forward-workflow), per design §7-S6. - Deferred follow-ups (knuth's scope discipline): drop the legacy concept-card response shape from /search + lift the dead-code row-stack subtree out of fristenrechner.ts in a separate cleanup PR. Filed as scope note on m/paliad#146 (issuecomment-10414). S1-S6 complete: - S1 |
|||
| ba3e0795f8 |
feat(fristenrechner): Slice S6 — drop cascade endpoint, neutralize legacy Pathway B (m/paliad#146)
Cleanup pass per design §7 / S6, executed as a measured first cut
that drops the cascade endpoint + neutralizes the legacy Pathway B
row-stack / cascade init without lifting the entire ~1500 LoC
subtree out of `fristenrechner.ts`. The dead helpers stay for one
follow-up that can lift them safely.
Backend:
* Deleted `internal/handlers/fristenrechner_event_categories.go`.
* Dropped the `GET /api/tools/fristenrechner/event-categories`
route from `handlers.go`. The `EventCategoryService` itself
stays — it still backs the legacy concept-card search's
`?event_category_slug=` filter, which dies in the same
follow-up that removes the concept-card response shape.
* `paliad.event_categories` TABLE is untouched per design §7
(kept for future tools).
Frontend:
* `loadEventCategoryTree()` reduced to a stub returning `[]` — the
endpoint it fetched no longer exists, and no overhaul surface
calls it.
* `initB1Cascade()`, `initForumFilter()`, `initInboxFilter()`
early-return. Their `DOMContentLoaded` registrations stay so
the bundle exports are stable, but no Pathway B cascade /
chip-strip / inbox-channel wiring fires in `?legacy=1` mode.
* The Pathway B markup in `fristenrechner.tsx` stays in place; it
renders inert when a user hits `?legacy=1&path=b`.
* `buildRowStack`, `renderRowStack`, `runB1Search`, and the row-
stack helper functions remain as unreachable code. Removing
them mechanically requires retiring the entire upper-half
Pathway B B2 search wiring (`runSearch` + `renderConceptCard`
+ `renderSearchResults` + `SearchResponse` types) which is
tangled with the legacy concept-card response shape — deferred
to a follow-up that lands together with the backend
concept-card removal.
Verified — bun build clean (2971 i18n keys unchanged), 256
frontend tests pass, go build + vet clean, live-DB tests
(TestListProceedings, TestSearchEvents, TestLookupFollowUps)
still green.
Follow-up scope tracked in design §7 S6 — pending the helper-tree
lift and the legacy concept-card response-shape removal from
/search.
|
|||
| 8dfdd77079 |
Merge: t-paliad-323 Slice S5 — flip overhaul default; legacy under ?legacy=1 (m/paliad#146)
knuth flipped the overhaul flag per design §7-S5: - isOverhaulMode() inverted: true unless ?legacy=1. - /tools/fristenrechner now lands on the new dual-mode (Direkt suchen + Geführt) by default. - Legacy row stack still reachable via ?legacy=1 for the 2-week deprecation window. - Existing ?overhaul=1 deep links continue to work (no-op pass-through). - Sidebar / header / outbound URLs unchanged — they point at bare /tools/fristenrechner so they pick up the new default automatically. S6 (drop buildRowStack + cascade reads) next on the same branch. |
|||
| 4571bd4980 |
feat(fristenrechner): Slice S5 — flip overhaul default; legacy under ?legacy=1 (m/paliad#146)
`isOverhaulMode()` now returns true unless the URL carries `?legacy=1`. The overhaul UI from S2-S4 (mode tabs + Mode A search + Mode B wizard + shared result view) becomes the default landing for /tools/fristenrechner; the legacy three-step wizard + Pathway A/B + cascade is reachable only via the explicit `?legacy=1` opt-out for the two-week deprecation window before S6 drops the legacy code paths entirely. The pre-existing `?overhaul=1` deep links from S2-S4 still resolve — the detector treats *absence* of `?legacy=1` as overhaul, so bookmarks stay valid. No sidebar / header / outbound link change needed: those all point at the bare `/tools/fristenrechner` URL, which now boots overhaul. Verified — bun build clean (2971 i18n keys unchanged), 256 frontend tests pass, go build + vet clean. |
|||
| 7584b4f428 |
Merge: t-paliad-323 Slice S4 — Fristenrechner Mode B wizard (m/paliad#146)
knuth shipped S4 of the Fristenrechner overhaul (design §3.2, §7-S4): - New frontend/src/client/fristenrechner-wizard.ts (711 LoC) — 5-row 'Geführt' wizard: - R1 event_kind (always asked, ~6 chips) - R2 forum (skipped when R1 narrows to a single forum) - R3 proceeding_type (auto-skipped when narrowed to a single candidate; EventKind EXISTS filter on the catalog) - R4 procedural_event (the landing question) - R5 perspective (async-probed after R4; only fires when the trigger event's follow-ups actually differ by primary_party) - Row Filter/Qualifier badges per §11.Q3 (R1/R2 = Filter, R3/R5 = Qualifier). - R5 has no 'Beide' option per §11.Q8 (qualifier mode in the file path). - Pre-fill+collapse from project: proceeding_type → R3+R2 and our_side → R5 with 'aus Akte' tag. - Backend ProceedingListOptions.EventKind added so R3's catalog query respects the chosen event_kind. - 6 live-DB tests pass — including the kind=proceeding regression check (upc.cfi.interim filtered out as a phase row). 256 frontend tests pass + 7 new for followUpsDifferByParty. Branch rebased on main (post-mig-153 + S3). S5 (flip ?overhaul=1 to default) next. |
|||
| 70985d88b0 |
feat(fristenrechner): Slice S4 — Mode B wizard (m/paliad#146)
Mode B "🧭 Geführt" — the guided 3-5 row wizard defined in
docs/design-fristenrechner-overhaul-2026-05-26.md §3.2. Lands the
user on a single procedural_event (the trigger), then transitions
to the shared §4 result view.
Frontend:
* `fristenrechner-wizard.ts` — row stack with R1..R5:
R1 Was ist passiert? (event_kind, always asked)
R2 Vor welchem Gericht? (jurisdiction, skip if R1 narrows)
R3 In welchem Verfahren? (proceeding_type, auto-skip when
narrowed pool has 1 option)
R4 Welches Schriftstück? (procedural_event, landing)
R5 Welche Seite vertreten Sie? (party, only when follow-ups
differ by primary_party)
Row badges per §11.Q3: R1+R2 = Filter, R3+R4+R5 = Qualifier.
R5 has NO "Beide" option per §11.Q8 — Mode B is the file-mode
where perspective is a qualifier.
* Project prefill — derives R3 + R2 jurisdiction from
project.proceeding_type, R5 from project.our_side. Annotates
pre-filled rows with "aus Akte" tag and implicit rows with
"implizit" tag per §11.Q10 ("erhalten" annotation when a pick is
carried across an upstream change).
* R4-to-result transition — after R4 the wizard fetches /follow-
ups (no dates) to inspect primary_party variance. If both
claimant and defendant rules exist AND R5 isn't already set,
swaps the loading row for the R5 chip picker. Otherwise jumps
straight to mountResultView.
* URL state — `?mode=wizard&kind=…&forum=…&pt=…&r4=…&party=…`
keeps deep-link / back-nav consistent (the launchResult step
sets `event=` so the result view picks up).
* `fristenrechner-result.ts` mountModeShell now dispatches the
"wizard" tab to the wizard module (was a coming-soon
placeholder).
* 18 i18n keys added (DE + EN parity), 145-line CSS block for the
wizard row stack with Filter / Qualifier badge styling and
"aus Akte" annotation chip.
Backend:
* `ProceedingListOptions.EventKind` adds an EXISTS subquery
filter on `paliad.sequencing_rules` ⨯ `paliad.procedural_events`
so Mode B R3 chips only show proceedings whose event roster
contains at least one event of the requested kind (design
§6.3). Endpoint param: `event_kind=` on
/api/tools/proceeding-types.
Test updates:
* `TestListProceedings` switched from SKIP-when-column-missing to
asserting the live filter — mig 153 has landed, `kind` column
is in place. New subtests: kind=proceeding includes
upc.inf.cfi and excludes the phase row upc.cfi.interim;
event_kind=filing narrows to proceedings with filing events.
* `fristenrechner-wizard.test.ts` covers
`followUpsDifferByParty` — the R5 trigger predicate. 7 cases:
asymmetric → true; uniform / both / court / empty → false.
Verified — bun build clean (2971 i18n keys), 256 frontend tests
pass (incl. 7 new), go build + vet clean, live-DB
TestListProceedings passes all 6 subtests against mig 153 data.
|
|||
| 06d6c7540e |
Merge: t-paliad-323 Slice S3 — Fristenrechner Mode A direct search (m/paliad#146)
knuth shipped S3 of the Fristenrechner overhaul (design §3.1, §7-S3):
- New frontend/src/client/fristenrechner-mode-a.ts (507 LoC) — 'Direkt suchen' UI per design §3.1: Filter strip (Forum · Verfahren · Was passierte · Partei) with section-split visual hierarchy per m §11.Q3, free-text search box, ranked result list of procedural_events with click-to-lock-as-trigger.
- Inbox channel as secondary 'Erweitert' chip per §3.3 with CMS→UPC / beA→DE forum nudge.
- Mode tabs pair (Direkt suchen / Geführt) under Step-0 per §11.Q2; wizard tab placeholder until S4.
- Backend ListProceedings(jurisdiction, kind) — kind='proceeding' filter targets mig 153's column (just merged in
|
|||
| 3e55ff8294 |
Merge: t-paliad-325 — mig 153 proceeding_types kind discriminator + ProjectService hardening (m/paliad#147)
ritchie shipped atlas's design (docs/design-proceeding-types-taxonomy-2026-05-26.md):
- mig 153 additive: ADD COLUMN kind text NOT NULL DEFAULT 'proceeding' CHECK in {proceeding,phase,side_action,meta}; UPDATE 4 phase + 10 side_action + 9 meta; per m's Q9 flips is_active=false on the same 23 rows in the same TX. CHECK trigger projects_proceeding_type_kind_check blocks projects.proceeding_type_id from pointing at non-proceeding kinds. Snapshot to paliad.proceeding_types_pre_153 in the same TX. set_config('paliad.audit_reason', ...) defensively.
- ProjectService.SetProceedingType hardened: new ErrInvalidProceedingTypeKind, single-SELECT validator checks category + kind + is_active before assigning.
- 4-angle test (TestProjectService_ProceedingTypeKindGuard) covers happy-path proceeding, rejected phase, rejected inactive, rejected wrong category.
- cmd/gen-upc-snapshot/main.go gains the AND kind='proceeding' filter; embedded snapshot JSON regen flagged as follow-up (needs DATABASE_URL at runtime).
Mode B R3 query now becomes WHERE is_active=true AND kind='proceeding' for a 23-row clean primary list. Phase/side_action/meta rows survive in the table for taxonomic reference but never surface in pickers.
|
|||
| 9d688459e3 |
feat(db): mig 153 — proceeding_types kind discriminator + ProjectService hardening
Adds a `kind` column to paliad.proceeding_types (proceeding / phase /
side_action / meta) so the Mode B R3 Fristenrechner wizard, the
projects.proceeding_type_id binding, and the pkg/litigationplanner
snapshot can filter to primary proceedings only.
Implements the ratified design from docs/design-proceeding-types-
taxonomy-2026-05-26.md (m greenlit 2026-05-27 09:57 after the 11-question
AskUserQuestion round-trip).
Mig 153 is purely additive — ADD COLUMN with a safe DEFAULT, UPDATEs
reclassify 23 non-primary rows (4 phase + 10 side_action + 9 meta), and
a BEFORE INSERT/UPDATE trigger on paliad.projects backstops the new
invariant. Pre-mig audit (Supabase MCP, 2026-05-27) confirmed zero
downstream pressure on the 23 reclassified rows.
- internal/db/migrations/153_proceeding_types_kind.up.sql + .down.sql
- snapshot to paliad.proceeding_types_pre_153 in the same TX
- set_config('paliad.audit_reason', …) defensively
- DO-block asserts 23 reclassified rows before the trigger ships
- Q9 carve-out: is_active=false on every phase/side_action/meta row
- new trigger paliad.projects_proceeding_type_kind_check on
paliad.projects.proceeding_type_id
- internal/services/project_service.go
- extend validateProceedingTypeCategory to also enforce
kind='proceeding' AND is_active=true; new typed error
ErrInvalidProceedingTypeKind
- single SELECT picks up category + kind + is_active
- internal/services/project_service_test.go
- TestProjectService_ProceedingTypeKindGuard covers service-layer
rejection, the active-but-non-proceeding edge, mig 153 trigger
backstop, and the kind='proceeding' happy path
- cmd/gen-upc-snapshot/main.go
- filter proceeding_types query to kind='proceeding' for forward-
compat (the embedded UPC snapshot JSON regen requires DATABASE_URL
access and will land in a follow-up; the current placeholder is
already empty of non-primary rows)
t-paliad-325 / m/paliad#147
|
|||
| 2a2c5b8033 |
feat(fristenrechner): Slice S3 — Mode A direct search (m/paliad#146)
Mode A "⚡ Direkt suchen" — the power-user entry path defined in docs/design-fristenrechner-overhaul-2026-05-26.md §3.1. Renders above the §4 result view; clicking a result row locks the trigger event and transitions to the shared result surface from S2. Frontend: * `fristenrechner-mode-a.ts` — filter strip (Forum / Verfahren / Was passierte / Partei) + free-text search input + result list. Section-split visual hierarchy per m §11.Q3: filter chips in a bordered "Filter (eingrenzen)" strip on top, result list below. Inbox channel chip lives behind an "Erweitert" details summary per §3.3; picking CMS / beA auto-nudges the Forum chip. Party chip retains a "Beide" option (Mode A is filter mode per §11.Q8; Mode B drops it in S4). * `fristenrechner-result.ts` — new `mountModeShell(activeTab)` renders the two mode tabs per §11.Q2 and lazy-imports Mode A. Mode B tab is a placeholder until S4 lands. * `fristenrechner.ts` boot — when `?overhaul=1` is set and `?event` is empty, mountModeShell takes over (default tab = search; `?mode= wizard` opens the wizard tab when S4 ships). With `?event=` the flow still jumps straight to the result view. URL state syncs forum / pt / kind / party / q on every chip click. * 28 i18n keys added (DE + EN parity), 310-line CSS block for the mode tabs + Mode A surface. Backend: * New `ProceedingListOptions { Jurisdiction, Kind }` + service method `ListProceedings(ctx, opts)`. Legacy `ListFristenrechnerTypes` keeps the no-filter signature for existing callers. Handler `/api/tools/proceeding-types` accepts `?jurisdiction=` and `?kind=` query params. * `kind=proceeding` filter targets the taxonomy column landed in mig 153 (parallel branch t-paliad-325, m/paliad#147). Sequenced per the taxonomy doc §7 option (c): mig 153 merges before S3 ships to main, so the filter is never false-positive (no phase / side_action / meta rows leak into the chip strip). Verified — bun build clean (2955 i18n keys, data-i18n attributes clean), 249 frontend tests pass, go build + vet clean. New TestListProceedings — 4 PASS (no-filter, jurisdiction=UPC, jurisdiction=DE, ListFristenrechnerTypes alias) + 1 SKIP for the kind=proceeding case that probes the column and skips when mig 153 hasn't landed yet. S1 + S2 live tests still green. |
|||
| 058a36976b |
Merge: t-paliad-324 — proceeding_types taxonomy design doc (docs only) (m/paliad#147)
atlas shipped the 580-line design ratifying Model 1 (kind discriminator) for the proceeding_types cleanup. All 11 PRDs answered by m in §10.
Final categorisation (46 active rows):
- 23 kind='proceeding' (18 with corpus + 5 unloaded primaries incl. upc.costs.cfi per m's Q2 carve-out)
- 4 phase (upc.cfi.interim/oral/decision + upc.default.cfi)
- 10 side_action (evidence/experiments/security/intervention/parties/optout/inspection/freezing/withdrawal/rehearing)
- 9 meta (case.mgmt, general.rop, service, language, representation, fees, legalaid, special, reestablishment)
Mig 153 sketch (per §3): ADD COLUMN kind text NOT NULL DEFAULT 'proceeding' CHECK in {proceeding,phase,side_action,meta}; 4 UPDATEs setting kind for the non-primary IDs; optional CHECK trigger blocking projects.proceeding_type_id from referencing non-proceeding kinds. No row moves, no FK churn — 0 downstream rules / projects / spawn FKs / concepts point at non-primary rows today (verified live, §0.1).
Sequencing (m's Q10): parallel-land with knuth's S3 of the Fristenrechner overhaul. The kind column makes Mode B R3's WHERE filter trivial; no need to serialize.
Coder gate held — atlas parks; head dispatches a fresh Sonnet coder for mig 153 + ProjectService.SetProceedingType hardening + youpc-go snapshot regen.
|
|||
| 3219bff4d4 |
design(taxonomy): proceeding_types kind discriminator + 11 m's decisions (t-paliad-324)
Live audit established that 28 of 46 active proceeding_types have zero downstream pressure (0 rules, 0 projects, 0 spawn FKs, 0 concepts). Mig plan is purely additive: ADD COLUMN kind text CHECK (...), four UPDATE statements to tag phase/side_action/meta rows, deactivate them, and add a BEFORE INSERT/UPDATE trigger on projects.proceeding_type_id to enforce kind='proceeding'. m's call on the 11 AskUserQuestion decisions: - Model 1 (kind discriminator) - Phases implicit via procedural_events.event_kind, EXCEPT upc.costs.cfi stays kind='proceeding' (standalone R.151 application) - Side-actions: kind='side_action', rules anchor on parent primary - Schutzschrift kind='proceeding' (own RoP filing) - DE inf + DE null + DE-vs-upc.apl unification: all keep discrete - upc.ccr.cfi: keep status quo per t-paliad-204 S1 - DB trigger on projects only (admin-only writes on sequencing_rules) - Deactivate non-primary rows (23 active post-mig, all kind='proceeding') - Parallel-land vs m/paliad#146 — knuth's S3 picks up the filter Final categorisation: 23 proceeding / 4 phase / 10 side_action / 9 meta. No code yet — coder gate held per inventor SKILL. Design only. Closes the inventor pass on m/paliad#147. |
|||
| 081b66ebc8 |
Merge: t-paliad-323 Slice S2 — Fristenrechner result view under ?overhaul=1 (m/paliad#146)
knuth shipped S2 of the Fristenrechner overhaul (design §4, §7-S2):
- New frontend/src/client/fristenrechner-result.ts (611 LoC) — renders the shared result view: trigger card (sticky header, inline date editor), 4 priority groups (Mandatory / Recommended / Optional / Conditional) with SPAWNED badge per §4.2, per-rule rows with checkbox + inline date override + party/citation badges, write-back footer conditional on project!=null (§11.Q7 — kontextfrei mode shows informational nudge instead).
- 72-LoC test suite covers groupFollowUps + defaultChecked semantics.
- Page wiring: ?overhaul=1 query param mounts the result view in place of the legacy renderProcedureResults; both coexist this slice. Deep-link shape: ?overhaul=1&event=<code>&trigger_date=…&project=… per §5.
- audit_reason wording in the bulk write-back call: 'Aus Fristenrechner — Trigger: {name} ({date})' per §11.Q12.
- 340 LoC of new CSS (entity-table extensions, group dividers, badge tokens).
- bun build clean; 249 existing frontend tests + 9 new pass; go build + vet clean; S1 live-DB tests still green.
PAUSED AT SEAM — knuth parked persistent. S3+ (Mode A/B wizard chips) waits for the proceeding_types taxonomy redesign (m/paliad#147, atlas in flight) to ratify the qualifier set that R3 picks from.
|
|||
| 9ab8dd8e0f |
feat(fristenrechner): Slice S2 — result view under ?overhaul=1 (m/paliad#146)
New `frontend/src/client/fristenrechner-result.ts` module renders the
shared result surface defined in
docs/design-fristenrechner-overhaul-2026-05-26.md §4:
* Sticky trigger card — event icon + name, proceeding/jurisdiction
chips, inline trigger-date input that re-fetches on change.
* Four follow-up groups — Mandatory / Recommended / Optional /
Conditional. SPAWNED rules fold into their priority bucket with
a `⇲ neues Verfahren` badge (§11.Q5). Conditional bucket holds
every rule with sr.condition_expr IS NOT NULL.
* Per-rule rows — title, duration phrase, party chip, legal-source
citation (with youpc.org link when available), pre-checked
checkbox driven by `defaultChecked(r)` (mandatory + recommended
on; conditional + court-set + optional off), inline ✏ Datum
override that re-renders.
* Write-back footer — conditional on `?project=<uuid>` per §11.Q7;
in kontextfrei mode the footer is hidden and an inline nudge
invites the user to pick an Akte. CTA submits to the existing
POST /api/projects/{id}/deadlines/bulk endpoint, stamping each
row with `audit_reason: "Aus Fristenrechner — Trigger: {name}
({date})"` per §11.Q12.
Mount + URL contract — when `?overhaul=1` is set in the URL,
`fristenrechner.ts` hides every legacy panel (`fristen-step1`,
`fristen-step2`, `fristen-pathway-a`, `fristen-pathway-b`,
`fristen-step3a`, the step-1 summary) and shows the overhaul root
instead. With `?overhaul=1&event=<code>&trigger_date=…` the surface
is deep-linkable end-to-end. Without `?event=` the empty-shell
nudge renders — S3+S4 will mount the entry-mode UIs onto this same
root.
Verified — bun build clean, 249 frontend tests pass (incl. 9 new
helper tests for groupFollowUps + defaultChecked), go build + vet
clean, S1 live-DB tests still green.
|
|||
| 4218d9cb52 |
Merge: t-paliad-323 Slice S1 — Fristenrechner backend endpoints (m/paliad#146)
knuth shipped S1 of the Fristenrechner overhaul (docs/design-fristenrechner-overhaul-2026-05-26.md §6, §7-S1): - GET /api/tools/fristenrechner/search?kind=events — returns procedural_events tuples with trigram ranking + follow-up counts (alongside the existing concept-card response). New service: services/fristenrechner_search_events.go (257 LoC). - GET /api/tools/fristenrechner/follow-ups — given trigger event + date + optional party qualifier, returns sequencing_rules anchored on the event with computed due dates via pkg/litigationplanner.CalculateRule. New service: services/fristenrechner_followups.go (404 LoC). - 6 live-DB integration tests (services/fristenrechner_followups_test.go, 205 LoC): SoC follow-ups, party narrowing, jurisdiction filters, event_kind filters, unknown-event sentinel. No schema changes — the unified sequencing_rules model already has every column needed. Knuth proceeds to S2 (result view under ?overhaul=1). |
|||
| 7ea415145f |
feat(fristenrechner): Slice S1 — backend ?kind=events + /follow-ups (m/paliad#146)
Two additive endpoints behind the Fristenrechner overhaul (design §6.1 + §6.2 in docs/design-fristenrechner-overhaul-2026-05-26.md): 1. GET /api/tools/fristenrechner/search?kind=events — returns procedural_events rows directly (not aggregated concept-cards), one hit per (event × proceeding_type) tuple. Trigram-ranked against name / name_en / code. Filters: jurisdiction, proc, event_kind, party. Powers Mode A's result list and Mode B's R4 landing chips. Default search shape unchanged. 2. GET /api/tools/fristenrechner/follow-ups?event=...&trigger_date=... — given a trigger event (by code or uuid) + date, returns the immediate follow-up sequencing rules with computed due dates via litigationplanner.CalculateRule. Each row carries priority / primary_party / is_court_set / is_spawn / has_condition / legal source / spawn target so the result view can group into Mandatory / Recommended / Optional / Conditional with the SPAWNED badge. party=claimant|defendant filters keep "both" rules visible. No schema changes — unified sequencing_rules already has every column needed. Live-DB tests cover the SoC follow-up shape, party narrowing, jurisdiction + event_kind filters, and the unknown- event sentinel. |
|||
| 109946edff |
Merge: t-paliad-322 — Fristenrechner overhaul design doc (docs only) (m/paliad#146)
553-line design doc documenting the complete Fristenrechner UX overhaul. Coder shift gated on m's go/no-go.
Two complementary entry paths into a shared result view:
- Mode A 'Direkt suchen' — search + filter chips (Forum · Proceeding · Event-Kind · Partei), result list of procedural_events, click locks a trigger.
- Mode B 'Geführt' — 3-5 row wizard (R1 event_kind → R2 forum → R3 proceeding_type → R4 procedural_event → R5 perspective), pre-filling + auto-skip from project context, row badges marking Filter vs Qualifier.
Shared result view groups follow-up sequencing_rules by Mandatory / Recommended / Optional / Conditional (SPAWNED folded with a 'neues Verfahren' badge). Trigger card sticks with inline-editable trigger date. Write-back via POST /api/projects/{id}/deadlines/bulk through a confirm-and-edit-dates modal. Kontextfrei mode hides the CTA entirely (m §11.Q7).
Filter vs Qualifier axis taxonomy ratified:
- forum, event_kind: filters
- proceeding_type, perspective (in file mode), procedural_event: qualifiers
- inbox channel: dropped from primary surface, kept as Mode A secondary chip
Backend deltas: extend /search to return events; new /follow-ups endpoint. No schema changes — the unified sequencing_rules model already has every column needed.
6-slice migration: S1 backend handlers → S2 result view (?overhaul=1) → S3 Mode A → S4 Mode B → S5 flip flag default → S6 drop buildRowStack + cascade reads. Procedure-mode (upper half of fristenrechner.tsx) untouched.
All 12 PRD questions ratified by m on 2026-05-26 via AskUserQuestion. 10/12 matched inventor recommendation; 2 diverged (Q3 section-split UX, Q7 hide kontextfrei CTA). Per-pick reasoning + design impact in §11.
Cronus parked on mai/cronus/inventor-fristenrechner. Coder shift held pending m's go.
|
|||
| 528fe35540 |
design(fristen): fold m's 12 decisions into Fristenrechner overhaul doc
All 12 questions answered via AskUserQuestion. 10/12 = inventor recommendation.
2 diverged:
Q3 (Filter-vs-qualifier UX): m picked section-split (Filter strip above,
result/qualifier strip below) instead of '(Pflichtangabe)' tag.
§3.1 Mode A layout rewritten with Filter strip header; §3.2 wizard
rows now carry Filter/Qualifier badges next to the row number.
Q7 (No-project mode): m picked 'Hide CTA entirely' instead of disabled-
with-hint. §4.4 footer renders only when project != null; an inline
'Tipp: Wähle oben eine Akte' nudge replaces the missing footer.
New §11 'm's decisions (2026-05-26)' anchors each pick with reasoning where
it diverges from the recommendation. §11.1 captures the two follow-on edits
to §3.1 and §4.4. Migration plan and backend contracts unchanged.
DESIGN READY FOR REVIEW pending head's coder gate.
|
|||
| 9c2788ed8c |
design: Fristenrechner complete UX overhaul (t-paliad-322)
Inventor shift-1 design pass for m/paliad#146. - Mode taxonomy (Direct-search A + Wizard B → shared result view) - Filter-vs-qualifier table ratified (forum/event_kind/inbox as filters; proceeding_type/perspective as qualifiers) - Wizard branching: R1 event_kind → R2 forum → R3 proceeding_type → R4 procedural_event → R5 perspective; rows prefill+collapse from project - Result view: 4 priority groups (mandatory/recommended/optional/conditional) with SPAWNED folded into priority + cross-proceeding badge - Project write-back via existing POST /api/projects/{id}/deadlines/bulk with confirm-and-edit-dates modal and audit_reason wording - Backend deltas: extend /api/tools/fristenrechner/search to return procedural_events; new /api/tools/fristenrechner/follow-ups - No schema changes — pure UX + handler shape - 6-slice migration plan from current buildRowStack to overhaul under ?overhaul=1 flag, then flip + cleanup - One worked example (LG Düsseldorf Hinweisbeschluss) - 12 open questions for m (3 batches of 4 via AskUserQuestion) |
|||
| c56859058d |
Merge: t-paliad-321 — mig 152 dedupe identical sequencing_rule clones + Proceeding column on admin list (m/paliad#144 follow-up)
mig 151 archived 5 of 6 duplicate procedural_events for 'Mängelbeseitigung / Zahlung' and reparented their sequencing_rules. The 6 sequencing_rules themselves were byte-for-byte clones (NULL proceeding/rule_code, 14d duration) — admin showed 6 indistinguishable rows for one legal concept.
Mig 152: full-signature partition over sequencing_rules, lowest UUID per group as canonical, archive the rest. Audit-first RAISE NOTICE pre-block surfaces every clone-group in deploy logs. Snapshot to paliad.sequencing_rules_pre_152. Reparents deadlines.sequencing_rule_id (renamed from rule_id in mig 140). Defensive set_config('paliad.audit_reason') even though sequencing_rules has no audit trigger live.
Expected outcome: 5 archived (just Mängelbeseitigung / Zahlung). Other name-groups (Antrag auf Patentänderung×4, Beginn des Hauptsacheverfahrens×2, Berufungs*-R.220.1×2) have distinct (proceeding_type_id, rule_code, duration, primary_party) signatures — legitimately different rules per proceeding, left alone.
UI: admin-rules-list gains a Proceeding column (proceeding_type.code, server-side join). Replaces the legacy Verfahrenstyp column which was broken for non-fristenrechner categories. One column for proceeding info instead of two; works for every category.
Build + vet clean. NoDuplicateSlot passes.
|
|||
| 6acb1167dd |
feat(admin): add proceeding-type column to /admin/procedural-events list (t-paliad-321 / m/paliad#144)
Surfaces the 3-segment proceeding code (e.g. upc.inf.cfi) on the admin
rules list so the 4 legitimately-distinct same-named groups are
visually disambiguated without opening each row's edit page.
Specifically helps with:
- "Antrag auf Patentänderung" × 4 (distinct proceeding_type_ids)
- "Beginn des Hauptsacheverfahrens" × 2
- "Berufungsbegründung-R.220.1" × 2
- "Berufungsschrift-R.220.1" × 2
(The 6× "Mängelbeseitigung / Zahlung" identical clones are dedup'd by
mig 152 in the sibling commit; this column lets m verify the dedupe
landed and confirms the remaining same-named groups are intentional.)
* internal/services/rule_editor_service.go —
- LoadProceedingTypeCodes(ctx, rows) — batch SELECT id, code FROM
paliad.proceeding_types WHERE id = ANY(...) for every distinct
non-NULL proceeding_type_id in rows. Returns id → code map.
Single round-trip, firm-wide reference data (no RLS / visibility
gate). Used only by the LIST endpoint; GetByID etc. don't need it.
* internal/handlers/admin_rules.go —
- adminRuleResponse gains ProceedingTypeCode *string field
(json:"proceeding_type_code,omitempty"). Populated by
wrapRuleListResponse from the id → code map.
- handleAdminListRules calls LoadProceedingTypeCodes after fetching
rows, passes the map to wrapRuleListResponse.
* frontend/src/admin-rules-list.tsx —
- Adds Proceeding column header in position 2 (between Submission
Code and Legal Citation) per paliadin's "Place between submission-
code and the existing columns" spec. Binds to canonical i18n
key admin.procedural_events.col.proceeding (added below).
- Drops the legacy Verfahrenstyp column at position 4 — the new
code-only column at position 2 replaces it; the old column
showed `code · name` which duplicates the new content.
* frontend/src/client/admin-rules-list.ts —
- Rule type gains proceeding_type_code?: string | null.
- New proceedingCodeCell(r) helper: prefers server-side
proceeding_type_code, falls back to dropdown-lookup
proceedingLabel for defense-in-depth on older API responses
(the old behaviour broke for rules whose proceeding_type_id
pointed at non-fristenrechner category proceedings; the new
column never has that bug because the join is server-side).
- Row rendering: new <td class="admin-rules-col-proceeding"><code>
proceedingCodeCell(r) </code></td> in column 2.
* frontend/src/client/i18n.ts —
- admin.procedural_events.col.proceeding alias added for DE +
EN ("Verfahren" / "Proceeding"). Mirror style of the other
canonical aliases from Slice A.
* frontend/src/i18n-keys.ts —
- Generated key union extended with
"admin.procedural_events.col.proceeding".
Build + vet clean. No new SQL — proceeding_types is firm-wide
reference data and the join uses an existing primary key.
|
|||
| 4cd28bc896 |
feat(db): mig 152 — dedupe identical sequencing_rule clones (5 archived) (t-paliad-321 / m/paliad#144 follow-up)
Mig 151 (t-paliad-319) archived 5 of 6 duplicate procedural_events for
"Mängelbeseitigung / Zahlung" and reparented their sequencing_rules
onto the canonical PE. The 6 sequencing_rules themselves were left
active — and they are byte-for-byte clones (proceeding_type_id=NULL,
rule_code=NULL, duration 14d, primary_party=NULL, condition_expr=NULL,
…). The admin shows six indistinguishable rows for one legal concept.
This migration archives 5 of 6, keeping the row with the
lexicographically lowest UUID as canonical.
Pre-write verification (Supabase MCP, 2026-05-26):
- Exactly 1 clone-group surfaces under the full-signature query
(procedural_event_id, proceeding_type_id, rule_code, duration_*,
primary_party, condition_expr::text, trigger_event_id, alt_*,
anchor_alt, combine_op, parent_id, is_spawn, spawn_*):
6 "Mängelbeseitigung / Zahlung" rows.
- 0 paliad.deadlines reference any of the 5 to-be-archived rows
(verified via deadlines.sequencing_rule_id JOIN; rule_id column
was dropped in mig 140 / Slice B.4).
- Other name-duplicates (Antrag auf Patentänderung×4, Beginn des
Hauptsacheverfahrens×2, Berufungsbegründung-R.220.1×2,
Berufungsschrift-R.220.1×2) do NOT collapse under this signature —
their proceeding_type_id / rule_code / duration / primary_party
differ. Legitimately distinct rules per proceeding. This mig
leaves them alone.
Migration shape (mirrors mig 151):
1. Build dedupe mapping (duplicate_id → canonical_id) into a
ROW_NUMBER() OVER (PARTITION BY full-signature ORDER BY
created_at, id::text) TEMP table.
2. PRE NOTICE: surface every clone-group with its canonical + dups
so the deploy log shows what's about to be touched (m may want
to spot-check).
3. Snapshot the duplicates into paliad.sequencing_rules_pre_152
(precedent pre_091/093/095/098/140/151).
4. Reparent paliad.deadlines.sequencing_rule_id duplicate → canonical
BEFORE archiving (defensive no-op today).
5. set_config('paliad.audit_reason', …) — defensive; sequencing_rules
has no audit trigger yet (mig 151 §scope verified), but a future
trigger would inherit the reason automatically.
6. UPDATE sequencing_rules SET is_active=false,
lifecycle_state='archived' WHERE id IN dups.
7. POST assertions: expected archive count met, zero clone groups
remaining in active+published, zero live deadlines pointing at
an archived sequencing_rule. RAISE EXCEPTION on any mismatch.
Down: best-effort revert (flips archived → published from snapshot).
Doesn't undo the deadlines reparent (live data didn't need one;
snapshot doesn't carry pre-state of deadlines).
Build + vet clean. TestMigrations_NoDuplicateSlot passes.
|
|||
| 568eac0aff |
Merge: t-paliad-320 — editorial seed cmd for 5 orphan deadline_concept drafts (4 concepts) (m/paliad#193)
darwin (researcher + /mai-lexy) staged 5 lifecycle_state='draft' sequencing_rules via services.RuleEditorService.Create() for the 4 remaining orphan deadline_concepts: - counterclaim-for-revocation → upc.ccr.cfi, RoP.025, 3 months (32aafb64) - versaeumnisurteil-einspruch → de.inf.lg, § 339 ZPO, 2 weeks Notfrist (eda1756a) - schriftsatznachreichung → de.inf.lg, § 283 ZPO, 3 weeks court-set (08b1682a) - weiterbehandlung (EPC) → epa.grant.exa, Art. 121 EPÜ + R. 135(1), 2 months (73674564) - weiterbehandlung (DPatG) → event-rooted (NULL proc), § 123a PatG, 1 month (16e262d2) Deliverable: cmd/seed-orphan-concept-drafts/main.go — runs against RuleEditorService in-process; idempotent; audit-reason flag. Editorial follow-up flagged in DPatG rule's deadline_notes: no dpma.grant.* proceeding_type exists yet; create dpma.grant.dpma and reassign rule 16e262d2 once added. Drafts ready for m's editorial review at /admin/procedural-events. |
|||
| 733d21c930 |
feat(seed): editorial cmd to stage drafts for orphan deadline_concepts (t-paliad-320)
Stages five lifecycle_state='draft' sequencing_rules — one per orphan deadline_concept — via services.RuleEditorService.Create(), the same service the POST /admin/api/procedural-events handler hits internally (audit trigger + INSTEAD-OF view trigger fan-out into procedural_events + sequencing_rules + legal_sources). No HTTP/auth shell, no raw SQL writes. Drafts (slug → proceeding): - counterclaim-for-revocation → upc.ccr.cfi, 3 months, RoP.025 - versaeumnisurteil-einspruch → de.inf.lg, 2 weeks Notfrist, § 339 ZPO - schriftsatznachreichung → de.inf.lg, 3 weeks court-set, § 283 ZPO - weiterbehandlung (EPC) → epa.grant.exa, 2 months, Art. 121 EPÜ + R. 135(1) EPÜ - weiterbehandlung (DPatG § 123a) → event-rooted (NULL proc), 1 month The DPatG variant is event-rooted because no dpma.grant.* proceeding_type exists yet — flagged in deadline_notes as editorial follow-up. Idempotent: refuses to insert if (concept, proceeding, rule_code) already exists. |
