324 Commits

Author	SHA1	Message	Date
mAi	9679a98666	feat(builder): B4 — Akte mode + project-backed scenarios (m/paliad#153) ... PRD §2.3 + §10. Implements the dual-write rule (load-bearing complexity per PRD §10): project-backed scenarios mirror flag toggles to paliad.projects.scenario_flags and filed event states to paliad.deadlines, while kontextfrei scenarios continue writing only to paliad.scenario_events. Visible affordances: page-header Akte picker, enabled "Aus Akte" mode tab, Akte banner on the project-backed canvas, cross-surface scenario-flag-changed dispatch + listener for live peer-surface coherence. Backend - ScenarioBuilderService takes ProjectService + ScenarioFlagsService deps so dual-write hits live tables. - CreateScenarioFromProject seeds a scenario from a project: copies proceeding_type_id + scenario_flags, normalises our_side to the builder's binary claimant|defendant axis, surfaces existing rule-bound deadlines as scenario_events (filed when completed, planned otherwise). - PatchProceeding on a project-backed top-level triplet dual-writes scenario_flags to projects.scenario_flags via flagDeltaFromBuilder. - PatchEvent transitioning to state='filed' on a project-backed scenario upserts paliad.deadlines (status='completed', completed_ at, source='rule') inside the same tx as the scenario_events UPDATE — canvas and project surfaces never diverge mid-flight. - POST /api/builder/scenarios/from-project handler wires the entry point. Frontend - builder-akte.ts: project list fetch + dropdown render, Akte banner, createScenarioFromProject POST helper. - builder.ts: mode branching — picking an Akte (search hit or page-header pick) creates a project-backed scenario and loads it; loaded scenarios reflect their origin_project_id on the picker + banner; flag toggles on Akte-backed top-level triplets dispatch scenario-flag-changed so the Verfahrensablauf strip / project surfaces refresh; the builder listens to inbound scenario-flag- changed and refetches its scenario when the changed project matches origin_project_id. - procedures.tsx: enable the previously-disabled Aus Akte tab. - i18n + CSS: builder.akte.banner.prefix key (DE+EN); lime-tinted banner styling. Tests - TestScenarioBuilderAkteDualWrite (live DB) pins the dual-write contract: Akte flag toggle → projects.scenario_flags updated, Akte filed event → deadlines row inserted; kontextfrei flag toggle leaves projects.scenario_flags untouched, kontextfrei filed event leaves deadlines untouched. - Existing TestScenarioBuilderService passes against the new signature (nil deps short-circuit dual-write paths). Verification: go test ./... + go vet ./... + bun run build all clean. Playwright smoke against the static dist build confirms the Akte tab + picker render correctly, fetchAkteProjects fires on mount, and the scenario-flag-changed CustomEvent dispatches + receives without runtime errors. t-paliad-347	2026-05-28 10:44:33 +02:00
mAi	1c77cb6e67	fix(builder): surface proceeding_type id so add-proceeding POST works (t-paliad-345) ... The Litigation Builder's "+ Verfahren hinzufügen" silently failed in prod after t-paliad-343 B2 shipped — clicking a Verfahren chip in the picker did nothing, no visible error. Root cause: the wire shape FristenrechnerType (the response of /api/tools/proceeding-types) carried code+name+nameEN+group but not id. Builder.ts mountAddProceedingPicker's callback POSTed `{proceeding_type_id: meta.id}` to /api/builder/scenarios/{id}/proceedings — meta.id was undefined, JSON.stringify dropped the key, the server returned 400 ("invalid input: proceeding_type_id is required"), and fetchJSON swallowed the error to console. The user saw "nothing happens". Fix: - Add `ID int json:"id"` to lp.FristenrechnerType. - SELECT id in FristenrechnerService.ListProceedings + Scan into the new field. - Defensive guard in builder.ts openAddProceedingPicker — refuse to POST without a positive integer id and log a clear error, so a future wire-shape regression cannot recreate the silent-fail. - Regression test in pkg/litigationplanner/types_wire_test.go pins the contract (id present in JSON, round-trips as integer). Side-benefit: fristenrechner-wizard.ts:599-628 documented this exact gap as a known limitation ("S5/follow-up can extend the wire shape to include id"). That workaround can now be retired in a follow-up. Refs m/paliad#153 (Litigation Builder)	2026-05-28 09:48:32 +02:00
mAi	a4b865d6bd	fix(builder): initialise scenario sub-arrays + client null-guard (t-paliad-344) ... GetScenarioDeep returned nil slices for proceedings/events/shares when a scenario had zero rows, which Go's encoding/json serialises as `null` rather than `[]`. The builder's renderCanvas then unconditionally calls `state.active.proceedings.filter(...)` on a null and dies with `procedures.js:101 TypeError: Cannot read properties of null (reading 'filter')` — every cold-open scenario crashed the page before the empty canvas could render. Backend (root cause): initialise Proceedings / Events / Shares to empty slices in BuilderScenarioDeep before SelectContext, so the wire shape is always arrays. Existing rows still load via SelectContext, which truncates the placeholder and refills from the DB. Frontend (defence in depth): on loadScenario(), normalise each of the three arrays to `[]` if the server response is not an array. Catches a future regression (or an older deployed build) without re-introducing the same crash class. bun build clean, go vet + go test ./... green.	2026-05-28 00:47:19 +02:00
mAi	a905911cf4	fix(deadlines): restore /api/events deadline rail after mig 140 column drop (t-paliad-344) ... Two SELECTs still referenced paliad.deadlines.rule_id after mig 140 (Slice B.4) dropped that column in favour of sequencing_rule_id: - internal/services/deadline_service.go:268 — DeadlineService. ListVisibleForUser. Powers /api/events?type=deadline (dashboard deadline rail, /deadlines page, every status bucket). Threw `pq: column f.rule_id does not exist` on every request → 500 for any authenticated user hitting the dashboard. - internal/services/projection_service.go:1250 — collectActualsForOverrides. Same column on `paliad.deadlines d`. Logged once per projection pass (`ERROR service: projection: deadlines: ...`); aliased the rename to `rule_id` so the receiving struct tag still scans. Live container logs confirmed the failure mode — a 60-row burst of `pq: column f.rule_id does not exist at position 3:36 (42703)` starting the minute the post-B0 container came up (mig 140 had applied to the DB but the SELECT still used the dropped name). EXPLAIN against the live schema after the edit plans cleanly; the LEFT JOIN to paliad.deadline_rules_unified on sequencing_rule_id was already correct (only the SELECT projection was stale). Root cause: mig 140 commit (1129bab) renamed the JOIN to `f.sequencing_rule_id` but left the SELECT clause on the older name. The model tag is already `db:"sequencing_rule_id" json:"rule_id"`, so the wire shape is unchanged — only the column reference flips. bun build clean, go vet ./... clean, go test ./... green.	2026-05-28 00:47:08 +02:00
mAi	b78a984a7c	fix(submission-md): preserve {{...}} placeholders verbatim through inline scanner ... The Markdown inline scanner (parseInlineSpans) treats _ and * as italic delimiters. A placeholder like {{project.case_number}} fed through the scanner had its underscores consumed as italic markers, leaving {{project.casenumber}} in the composed OOXML. The v1 placeholder pass then looked up the wrong key, surfacing [KEIN WERT: project.casenumber] in the preview. The form ↔ preview highlighting also stopped working because data-var attributes mismatched between the input (snake_case) and the rendered span (stripped). parseInlineSpans now detects {{ at the cursor and skips ahead to the matching }}, copying the entire placeholder verbatim into the current text run. Unmatched {{ falls through to the existing character handling so legal prose with stray braces still renders. Tests: regression test for underscored keys (single + multiple + mixed-with-italics), direct guard on parseInlineSpans, and an italic-around-placeholder structural test.	2026-05-28 00:01:30 +02:00
mAi	0f3c30a647	feat(scenario-builder): B0 schema foundation + minimal API (m/paliad#153) ... t-paliad-340 — B0 of edison's 7-slice train (PRD §7.1). DB-only: schema + RLS land, dev-only test route exercises the surface, no user-facing change. B1 wires the actual builder UI on top. Migration 157 (additive on the legacy mig-145 scenarios table — 0 rows in prod, safe to relax): - paliad.scenarios gets owner_id / status / origin_project_id / promoted_project_id / stichtag / notes. spec drops NOT NULL and the scenarios_unique_per_scope constraint drops (the builder allows multiple scratch + Unbenanntes Szenario rows per user). - New tables: scenario_proceedings, scenario_events, scenario_shares. - paliad.projects.origin_scenario_id for the promote-to-project audit trail (the FK lands now; the wizard ships in B5). - paliad.can_see_scenario(uuid) STABLE SECURITY DEFINER helper covering owner / share / global_admin / two legacy paths. - Replacement RLS on scenarios + RLS on the three new tables; legacy service + handlers stay live and unchanged. PRD §5.1 deviations called out in the migration header: - proceeding_type_id is integer (live schema), not uuid (PRD draft). - FK target is paliad.users, matching the rest of paliad's schema. Go surface: - ScenarioBuilderService — list/create/get-deep/patch scenarios, add/patch/delete proceedings, add/patch/delete events, add/delete shares. Writes wrap in transactions with set_config( paliad.audit_reason, ..., true) per event_choice_service.go pattern. - /api/builder/scenarios/* — handlers register under a builder/ prefix so the legacy /api/scenarios surface still works. - /dev/scenario-builder — single-page HTML form gated to PaliadinOwnerEmail, exercises the B0 surface without Postman. - Live-DB integration test (TEST_DATABASE_URL gated) covers create + list + deep-get + share + visibility negatives + patch. Audit-first: every DDL block ran clean via BEGIN/ROLLBACK against the live DB before commit; end-to-end sanity (insert chain + CHECK constraints + CASCADE-on-delete) verified via the Supabase MCP. bun build clean. go vet + go test -short ./... green.	2026-05-27 23:50:14 +02:00
mAi	39c8ef343b	feat(procedures): U4 hard-cut legacy URLs + retire dual surfaces (m/paliad#151) ... Per m's Q11 divergence in the design (no 2-week dual-ship), this slice flips /tools/fristenrechner and /tools/verfahrensablauf to permanent 301 redirects to /tools/procedures and deletes the legacy frontend pages. Bookmarks resolve via Location preservation of query params; no ?legacy=1 escape, no in-product affordance pointed back at the retired URLs after the merge. Server: - handleFristenrechnerPage + handleVerfahrensablaufPage now 301 to /tools/procedures, carrying any query string through unchanged. - pillDrillURL in deadline_search_service.go retargets to /tools/procedures so freshly indexed search pills land on the new page directly (cached snapshots still work via the 301). Frontend: - Deleted src/fristenrechner.tsx, src/verfahrensablauf.tsx, src/client/fristenrechner.ts. - src/client/verfahrensablauf.ts loses its DOMContentLoaded auto-boot and the now-unused initI18n / initSidebar imports; procedures.ts is the sole caller of initVerfahrensablauf(). - frontend/build.ts drops the legacy entrypoints and renderXxx HTML outputs. - Sidebar.tsx, Header.tsx, index.tsx, paliadin-context.ts repointed to /tools/procedures. - Unused nav.fristenrechner / nav.verfahrensablauf / tools.verfahrensablauf.* i18n keys removed. Tests: - verfahrensablauf_test.go rewritten to assert both legacy URLs return 301 with the correct Location (query string preserved).	2026-05-27 20:34:54 +02:00
mAi	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.	2026-05-27 15:22:53 +02:00
mAi	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.	2026-05-27 15:11:48 +02:00
mAi	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.	2026-05-27 15:07:01 +02:00
mAi	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.	2026-05-27 15:02:01 +02:00
mAi	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.	2026-05-27 10:14:37 +02:00
mAi	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 3e55ff8). 4 tests pass + 1 SKIP that probes for column existence (graceful fallback prior to mig 153). - 310 LoC CSS, 88 i18n keys for the new surface. - bun build clean; 249 existing frontend tests + new pass; go vet clean. Mode A live under ?overhaul=1. Mode B (S4 wizard) next on the same branch.	2026-05-27 10:10:57 +02:00
mAi	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	2026-05-27 10:09:33 +02:00
mAi	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.	2026-05-27 10:07:27 +02:00
mAi	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.	2026-05-26 22:01:10 +02:00
mAi	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.	2026-05-26 21:27:00 +02:00
mAi	bd7896ef68	feat(submissions): Composer Slice F — section reorder / hide / add custom (m/paliad#141) ... The final Composer slice per design doc §12. Lawyer gains full control over section composition: drag-and-drop reorder, per-section delete, "+ Add section" picker for custom slugs that don't appear in the base's default spec. Combined with Slice B's hide toggle, this closes out the A→F sequence — Composer A→F is complete. Backend (internal/services/submission_section_service.go, +120 LoC): - SectionService.Create — adds a new section row to a draft. Validates section_key + labels + kind (must be prose/requests/evidence). Auto-assigns next order_index when OrderIndex=0; collisions on (draft_id, section_key) surface as ErrInvalidInput. - SectionService.Delete — removes one section by id. Returns ErrSubmissionSectionNotFound when nothing was deleted. - SectionService.Reorder — accepts a sequence of section_ids, rewrites every row's order_index to (1..N)×10 transactionally. Returns the refreshed list. Sections not present in the sequence are silently ignored (defensive — partial reorder doesn't lose rows). Handlers (internal/handlers/submission_sections.go, +180 LoC): - POST /api/submission-drafts/{draft_id}/sections — owner-scoped via SubmissionDraftService.Get. 400 on slug collision / invalid kind. - DELETE /api/submission-drafts/{draft_id}/sections/{section_id} — owner + section-belongs-to-draft cross-check. 204 on success. - POST /api/submission-drafts/{draft_id}/sections/reorder — accepts {"section_order": [uuid, uuid, ...]}; returns refreshed sections list. Frontend (frontend/src/client/submission-draft.ts, +260 LoC): - Each section row gains a drag handle (⋮⋮) on the left of the head. Drag handle is the only draggable element; contentEditable selections inside the editor body keep working. HTML5 native DnD, no library. - Drop-target highlighting via .submission-draft-section--drop-target (border-top accent). Cleanup on dragend / drop / cancel. - Per-section "Delete" button next to the existing Hide/Include toggle. Confirm prompt prevents accidental loss of typed prose. - "+ Add section" trailing affordance below the section list opens an inline form (slug + DE label + EN label + kind dropdown). Submit POSTs to the new endpoint; on success splices the row into state.view.sections and re-paints. CSS (frontend/src/styles/global.css, +65 LoC): - .submission-draft-section-handle (grab cursor + hover background + active=grabbing). - .submission-draft-section--dragging / --drop-target visual states. - .submission-draft-add-section form layout (dashed border + lime primary submit). Tests (internal/services/submission_section_slice_f_test.go, NEW, TEST_DATABASE_URL-gated): - Create custom section + slug-collision surface as ErrInvalidInput. - Delete + repeat-delete returns ErrSubmissionSectionNotFound. - Reorder reverses 10 seeded sections + verifies the resulting order_index sequence is ascending and matches the input order. Build hygiene: go build/vet/test -short clean (all packages); bun run build clean (2906 i18n keys, data-i18n scan clean). Hard rules honoured: - NO new migrations (Slice F is pure code on Slice A's schema). - NO behavior change for pre-Composer drafts (no section rows → no drag handles to drag). - {{rule.X}} aliases preserved (custom sections render through the same composer pipeline as default sections). - Q2/Q9/Q10 ratifications preserved. This closes the Composer slice sequence A → F. The full feature set ratified by m on 2026-05-26 is now in place: A — base picker + read-only section list (mig 146/147/148) B — editable prose + anchor-spliced render + MD→OOXML walker C — building-blocks library + section picker (mig 149) D — rich prose (headings, lists, blockquote, hyperlinks) E — specialist bases lg-duesseldorf + upc-formal (mig 150) F — section reorder / delete / add custom t-paliad-318 Slice F	2026-05-26 20:26:53 +02:00
mAi	94310ba498	feat(submissions): Composer Slice E — specialist bases + base-swap content survival (m/paliad#141) ... Two new firm-agnostic base templates + the generic generator that produced them + a regression test pinning Q10's base-swap-content- survival contract. Mig 150: seeds two `submission_bases` rows with firm=NULL. - lg-duesseldorf — proceeding_family='de.inf.lg'. Conservative German legal style: Times New Roman 11pt; plain black headings. Stylemap targets LG-Body / LG-Heading1..3 / LG-ListBullet / LG-ListNumber / LG-Quote. - upc-formal — proceeding_family='upc.inf.cfi'. UPC court style: Calibri 11pt body; UPC-blue (#1F3864) headings; Cambria italic for blockquotes. Stylemap targets UPC-Body / UPC-Heading1..3 / … Both rows ship the same 10-section spec.defaults shape as the Slice A bases (letterhead → signature) with their own seed Markdown. scripts/gen-submission-base/main.go (NEW, ~240 LoC): - Generic generator with -preset flag. Two presets baked in (lg-duesseldorf + upc-formal). Each preset hard-codes typography (font, sizes, colour) so the lawyer can swap between bases and see chrome change while section content carries through unchanged. - Output is byte-reproducible (zip mtime pinned to 2026-05-26 UTC). - Emits a minimal Composer-mode .docx: [Content_Types].xml, _rels/.rels, word/_rels/document.xml.rels (empty envelope so the composer's hyperlink-rels patch from Slice D has somewhere to land), word/styles.xml (preset's full named-style block + "Hyperlink" character style for Slice D link runs), word/document.xml (anchor- only body in §6.1 default section order). Gitea uploads (via mAi): - 6 - material/Templates/Word/Paliad/Composer/lg-duesseldorf.docx blob SHA: 82f57b3cb3b54c755fc5ab36862bfd61b8aaa73e - 6 - material/Templates/Word/Paliad/Composer/upc-formal.docx blob SHA: 41b9a388263ccc43ddc28b55caab301a4cf74fe8 These live under Composer/ (not under HLC/) so a future non-HLC deployment serves the same cross-firm files. Backend wiring: - internal/handlers/files.go: two new fileRegistry entries (composerBaseLGDuesseldorfSlug, composerBaseUPCFormalSlug) + matching slugs in composerBaseSlugMap so fetchComposerBaseBytes routes the new catalog rows to the new Gitea objects. Tests: - TestComposer_BaseSwapPreservesContent — composes the same draft against an HLC-style stylemap AND an LG-style stylemap; asserts (a) content survives both ways, (b) each output carries the correct stylemap-entry stylenames, (c) neither output leaks the other's stylenames. Pins Q10's base-swap-survives-content contract. Build hygiene: go build/vet/test -short clean (all packages); bun run build clean. NOT in scope (Slice E's brief was specialist bases + survival test): - Generator coverage for HL Patents Style bases — gen-hl-skeleton- template stays as the per-firm path (it needs the proprietary .dotm source). gen-submission-base is for firm-agnostic bases. - LG-Düsseldorf-court-style-guide deep fidelity — the LG preset is a conservative starting point; admin refines via the admin editor in a later slice if needed. - numbering.xml carrying numId=1/2 — Slice D's MD walker emits visible "• " / "N. " prefixes that don't need numbering.xml; honours stylemap entry for indentation. Hard rules honoured: - Migration purely additive (`ON CONFLICT (slug) DO NOTHING`). - NO behavior change for pre-Composer drafts. - NO behavior change for existing hlc-letterhead + neutral seed rows. - {{rule.X}} aliases preserved (walker passes placeholders through; v1 SubmissionRenderer pass substitutes). - Q10 base-swap-content-survival pinned by new test. t-paliad-317 Slice E	2026-05-26 20:21:12 +02:00
mAi	5834e3dc66	Merge: Composer Slice D — rich prose (headings, lists, blockquote, hyperlinks) in MD→OOXML walker (m/paliad#141)	2026-05-26 20:16:14 +02:00
mAi	677849784c	feat(submissions): Composer Slice D — rich prose (headings, lists, blockquote, hyperlinks) (m/paliad#141) ... Extends the Composer's MD → OOXML walker per the design at docs/design-submission-generator-v2-2026-05-26.md §12 Slice D from Slice B's paragraphs + B/I baseline to the full rich-prose feature set: headings 1-3, bullet + numbered lists, blockquote, inline hyperlinks. MD walker (internal/services/submission_md.go, +320 / -75 LoC): - RenderMarkdownToOOXMLWithStyles is the new Slice-D entry point; RenderMarkdownToOOXML stays as a thin back-compat wrapper. - splitMarkdownBlocks classifies every line into one of: paragraph, heading_1/2/3, list_bullet, list_numbered, blockquote. CommonMark-style 3-space indent tolerance; "N. " and "N) " for numbered. Blank-line spacing semantics preserved from Slice B. - renderBlockParagraph applies stylemap[blk.styleKey] (with fall-back to stylemap["paragraph"]). List blocks emit visible "• " / "N. " prefix runs so the structure surfaces even if Word isn't configured with auto-list-numbering — lawyer can apply a real Word list style post-export. Numbered-list ordinals reset on every non-list block (so "1. A\nplain\n1. C" renders 1./1., not 1./2.). - parseInlineRuns adds `[label](url)` recognition. Each link gets routed through the optional HyperlinkAllocator; the walker emits `<w:hyperlink r:id="{rId}">…runs…</w:hyperlink>` with the "Hyperlink" character style on each child run. Nil allocator falls back to plain-text label (URL drops, label survives). Composer (internal/services/submission_compose.go, +130 / -10 LoC): - composerLinkAllocator hands the walker fresh rIds (rIdComposer1, rIdComposer2, …) outside the base's existing namespace; same URL shared across multiple sections dedupes to one rId. - patchDocumentXMLRels appends matching <Relationship Type="…/hyperlink" Target="URL" TargetMode="External"/> entries to word/_rels/document.xml.rels. Idempotent on rIds already present; synthesizes a fresh rels part when missing (defensive for stripped bases). Returns the patched parts slice (caller must overwrite because append may grow the backing array — fixed in this slice). - Compose now passes the full stylemap (paragraph + heading_1/2/3 + list_bullet + list_numbered + blockquote) into the walker, not just the paragraph-style entry. Frontend (frontend/src/client/submission-draft.ts): - Toolbar adds H1/H2/H3 buttons (formatBlock h1/h2/h3), bullet list, numbered list, blockquote, and a link button that prompts for a URL + wraps the selection via execCommand("createLink"). - domToMarkdown serializer extends to <h1>/<h2>/<h3>, <ul>/<ol> with per-item ordinal counter for numbered lists, <blockquote>, and <a href="…"> → `[label](url)`. Nested <li> handling sits in the ul/ol branch. Tests (internal/services/submission_md_test.go, internal/services/ submission_compose_test.go): - TestRenderMarkdownToOOXML_Heading1 / _Heading2And3 — stylemap applied. - _BulletList / _NumberedList / _NumberedListResetsOnNonList — prefixes + ordinal counter. - _Blockquote — stylemap applied. - _Hyperlink — allocator called, w:hyperlink rId wired, Hyperlink character style on label runs. - _HyperlinkNilAllocatorFallsBackToPlain — label survives, no hyperlink tag emitted. - TestDetectBlockMarker — 13 marker / non-marker cases. - TestComposer_HeadingsAndLists — end-to-end through Compose with a multi-construct draft; verifies stylemap presence + content + ordinal prefixes. - TestComposer_HyperlinkWiresRels — body has the right <w:hyperlink r:id="rIdComposer{N}">, document.xml.rels has the matching <Relationship> rows with External target mode. - TestComposer_HyperlinkDedupesByURL — two `[label](url)` references to the same URL share one rId; second allocation gets no new Relationship row. Build hygiene: go build/vet/test -short clean (all packages); bun run build clean (2906 i18n keys). NOT in scope (Slice D's brief was rich-prose + toolbar): - Numbering.xml audit on bases — current approach emits visible "• " / "N. " prefix runs without depending on numbering.xml. A future slice can swap to `<w:numPr>` if firm-style auto-numbering becomes a hard requirement. - DOM-from-Markdown on initial editor paint — the editor still uses textContent=md, so toolbar-applied formatting reverts to literal Markdown text after autosave + repaint. Acceptable trade-off for Slice D; a future polish could parse MD into the DOM on paint. - Tables, images, footnotes (still design §13 out of scope). Hard rules honoured: - NO new migrations (Slice D is pure code). - NO behavior change for pre-Composer drafts (gate on draft.BaseID unchanged). - {{rule.X}} aliases preserved (placeholders pass through the walker verbatim, get substituted by the v1 SubmissionRenderer pass). - Q2 ratification preserved (no building_block_id lineage). - Q9 ratification preserved (4-tier BB visibility from Slice C). t-paliad-316 Slice D	2026-05-26 20:15:28 +02:00
mAi	2c0efc396c	Merge: Slice B.5 — Go type aliases (SequencingRule = DeadlineRule) + JSON envelope dual-emit + Deprecation headers (m/paliad#93)	2026-05-26 20:08:43 +02:00
mAi	5c6a0095e3	feat(models,services,handlers): Slice B.5 Go rename + JSON envelope dual-emit (t-paliad-305 / m/paliad#93) ... Adds the Slice B.5 canonical Go names (SequencingRule, ProceduralEvent, LegalSource, SequencingRuleService) without breaking any existing call-site, and dual-emits / dual-accepts the two JSON envelope key renames on /admin/api/rules with a Deprecation header. * internal/models/models.go — - type SequencingRule = DeadlineRule (alias; same struct, same db / json tags). DeadlineRule remains the underlying type for now — deferred hard-rename keeps the slice small. - type ProceduralEvent struct mirroring paliad.procedural_events (id, code, name, name_en, description, event_kind, primary_party_default, legal_source_id, concept_id, lifecycle_state, draft_of, published_at, is_active, timestamps). Used by future code that needs the PE identity row alone. - type LegalSource struct mirroring paliad.legal_sources (citation, jurisdiction, pretty_de / pretty_en — both nullable per mig 136). * internal/services/deadline_rule_service.go — - type SequencingRuleService = DeadlineRuleService (alias). - var NewSequencingRuleService = NewDeadlineRuleService (constructor alias). Internal callers can adopt either name. * internal/services/rule_editor_service.go — - CreateRuleInput gains Code + EventKind fields tagged json:"code" / json:"event_kind". CoalesceCanonicalKeys() folds canonical → legacy after json.Decode so the rest of the service keeps using SubmissionCode / EventType. Canonical wins when both are sent. - RulePatch gains EventKind field with the same fold. * internal/handlers/admin_rules.go — - adminRuleResponse wraps *models.DeadlineRule and adds Code + EventKind fields alongside the legacy SubmissionCode / EventType. Outputs both keys per response for one deprecation-window slice. - wrapRuleResponse / wrapRuleListResponse helpers. - adminRuleDeprecationHeaders emits IETF Deprecation + Link/Sunset headers on every Rule-bearing response so clients see the migration signal in transit. - All 8 Rule-returning handlers (List, Get, Create, Patch, Clone, Publish, Archive, Restore) now wrap their result and add the headers. - Create + Patch handlers call CoalesceCanonicalKeys after decode so legacy AND canonical request bodies are both accepted. Scope decisions (documented in commit): - Type renames use aliases instead of a hard 200-LOC rename. Same semantics, no call-site churn. A future cleanup slice can flip the underlying type definitions when convenient. - ProceduralEvent + LegalSource are NEW structs (not aliases) since they represent new conceptual rows; no legacy callers exist yet. - Frontend admin .tsx i18n key rebinds (mentioned in parent task brief B.5 deliverable list) are deferred — i18n keys themselves already exist from Slice A (t-paliad-262); rebinding only changes which key the .tsx file looks up. Pulling this into B.5 ballooned scope; flagging as a small follow-up slice or B.6 sibling. - Only /admin/api/rules emits dual keys today. Other handlers that surface rule rows (Schriftsätze list, deadlines join) continue to emit the legacy keys via models.DeadlineRule's existing JSON tags — they're read paths, not the editor surface, and the deprecation signal is most important where clients write. Build + vet clean. TestMigrations_NoDuplicateSlot passes.	2026-05-26 20:07:48 +02:00
mAi	6e0961cc30	Merge: Composer Slice C — building blocks library + section picker (mig 149) (m/paliad#141)	2026-05-26 20:05:30 +02:00
mAi	ee98db94fa	feat(submissions): Composer Slice C — building blocks library (m/paliad#141) ... Per the design at docs/design-submission-generator-v2-2026-05-26.md §8 and the Q2 / Q9 ratifications: - Q2 (m, 2026-05-26): building blocks are plain text paste sources. No building_block_id reference is stored on submission_sections. - Q9 (m, 2026-05-26): four visibility tiers — private / team / firm / global. Schema (mig 149): - paliad.submission_building_blocks — library catalog. Columns: slug, firm (NULL = cross-firm), section_key (binds to one section kind), proceeding_family (NULL = any), title_de/_en + description_de/_en + content_md_de/_en, author_id, visibility (CHECK in 4-tier set), is_published, created_at, updated_at, deleted_at (soft delete). RLS: coarse-grained SELECT — every authenticated user sees non-deleted non-private rows + own private rows. Tier-specific predicate (private/team/firm/global) applied in Go-layer service so semantics evolve without RLS migrations. Mutations admin-only (no RLS write paths). - paliad.submission_building_block_admin_versions — append-only history per block, retention=20. Admin-side only; NOT referenced from submission_sections (per Q2's plain-text-paste model). Exists so accidental delete / overwrite are recoverable. Backend: - internal/services/submission_building_block_service.go (~510 LoC): BuildingBlockService. ListVisible applies tier predicate at query time (private = author_id match; firm = firm column NULL OR matches branding.Name; team = author shares a project_team with caller via paliad.project_teams self-join; global = open). ListAllForAdmin drops the predicate. Create + Update + SoftDelete + RestoreVersion all transactional; appendVersionTx writes one audit row + GC-deletes anything past the retention=20 horizon in the same tx. InsertIntoSection (the paste mechanic) clones content_md_<lang> into the section row with a "\n\n" separator if section already has content. NO building_block_id stamped per Q2. - internal/handlers/submission_building_blocks.go (~480 LoC): nine handlers split between the lawyer-facing picker (list, insert) and the admin editor (list, get, create, update, delete, list-versions, restore-version, page). buildingBlockUpdateInput uses presence- tracking UnmarshalJSON for the four nullable fields (firm, proceeding_family, description_de/_en) so PATCH can distinguish "no change" from "set to null". - Routes registered: lawyer-facing under /api/submission-building-blocks, admin-gated under /api/admin/submission-building-blocks/* and /admin/submission-building-blocks (page). - Wiring: handlers.Services + dbServices + cmd/server/main.go all gain SubmissionBuildingBlock. NewBuildingBlockService takes the branding.Name firm hint for the visibility predicate. Frontend: - frontend/src/admin-submission-building-blocks.tsx (~85 LoC): three-pane admin shell (list / editor / version log) registered in build.ts. - frontend/src/client/admin-submission-building-blocks.ts (~370 LoC): admin client — list paint, edit form (slug + firm + section_key + proceeding_family + title/desc/content per lang + visibility radio + is_published toggle), per-block version log with restore button. Bilingual labels. - frontend/src/client/submission-draft.ts: per-section "+ Baustein" button on the Composer editor toolbar (Slice B substrate gets one more affordance). openBlockPicker opens a modal filtered to the section's section_key, 200ms-debounced search by free text against title/description/content. Click a hit → POST insert-into-section → section row's content_md_<lang> gains the block's content appended at the end (Q2's plain-text paste semantic, no lineage). - ~240 LoC of CSS: modal overlay + picker rows with tier-colored visibility chips + admin editor 3-pane grid + form rows + version list. - 12 new i18n keys × 2 langs (admin.building_blocks.*). Tests: - TestValidVisibility (8 cases including case-sensitivity + empty). - TestAppendBlockContent (8 cases covering empty-existing / empty- addition / whitespace-only / trailing newline collapse). - TestBuildingBlockVisibilityConstants pins the 4 string literals against drift (RLS predicate + DB CHECK depend on them). Build hygiene: go build/vet/test -short clean; bun run build clean (2906 i18n keys, data-i18n scan clean). Hard rules per ratifications honoured: - Q2: no building_block_id lineage on sections (paste is plain text). - Q9: 4 visibility tiers (private/team/firm/global). - NO behavior change for pre-Composer drafts (the picker just doesn't show — section list is hidden for base_id NULL drafts). - {{rule.X}} aliases preserved (block content goes through the same v1 placeholder pass on export as section prose). NOT in scope per Slice C brief: - User-authored private blocks (Slice C ships admin curation only; any-user create is a follow-up). - Tier promotion review workflow (admin sets tier directly today). - Per-section "where is this block used" reverse lookup (no lineage to query). - Slice D's rich-prose features (headings, lists, blockquote) still Slice D's job; this Slice doesn't extend the MD walker. t-paliad-315 Slice C	2026-05-26 20:04:40 +02:00
mAi	987db27831	Merge: t-paliad-305 — Slice B.4 destructive drop: paliad.deadline_rules retired, INSTEAD OF triggers on view (mig 140, snapshot pre_140 same-TX) (m/paliad#93)	2026-05-26 19:54:27 +02:00
mAi	1129baba7a	feat(db,services): Slice B.4 destructive drop — paliad.deadline_rules retired, INSTEAD OF triggers on view route writes (mig 140, t-paliad-305 / m/paliad#93) ... Drops the legacy paliad.deadline_rules table after 3 weeks of dual-write shadowing (mig 136 → B.2 dual-write → B.3 read cutover via view). The new tables — paliad.procedural_events, paliad.sequencing_rules, paliad.legal_sources — are the sole source of truth from this commit forward. Pre-flip drift verified clean against prod: deadline_rules=231 == sequencing_rules=231 == procedural_events=231 legal_sources=87 missing_sr=0, orphaned_sr=0, mismatched_lifecycle=0 * internal/db/migrations/140_drop_deadline_rules.up.sql (new) — Single TX, audit-first: 1. CREATE TABLE paliad.deadline_rules_pre_140 AS TABLE paliad.deadline_rules (precedent migs 091/093/095/098 — snapshot in same TX as destructive op). 2. Final reconciliation UPDATE on paliad.deadlines (no-op when drift is already 0; defensive against last-minute writes). 3. DROP TRIGGER deadline_rules_audit_aiud. 4. Re-point FKs to sequencing_rules: - paliad.appointments.deadline_rule_id → paliad.sequencing_rules(id) - paliad.deadline_rule_backfill_orphans.resolved_rule_id → paliad.sequencing_rules(id) (the id values are identical — sr.id inherited dr.id at mig 136.) 5. DROP COLUMN paliad.deadlines.rule_id. 6. DROP TABLE paliad.deadline_rules. 7. CREATE INSTEAD OF INSERT + INSTEAD OF UPDATE triggers on paliad.deadline_rules_unified. Triggers route writes into the three new tables in the same TX, preserving the legacy column shape on the wire so RuleEditorService SQL only needs a table-name swap, not a structural rewrite. Synthetic-code mint expression is byte-identical to mig 136 + the B.2 dual-write helper. POST assertions confirm the table is gone, the column is gone, and the snapshot matches. Trigger design notes (1:N caveat documented in-trigger): - PE identity columns (code, name, name_en, description, event_kind, primary_party_default, legal_source_id, concept_id) mirror from the writing sequencing-rule. - PE lifecycle columns (lifecycle_state, published_at, is_active) deliberately do NOT mirror — a draft sequencing-rule cloned from a published source shares the source's PE; we don't want the clone's 'draft' lifecycle to leak back onto the source's PE. Practical bound today (1:1 corpus); explicit comment in-trigger for the eventual 1:N pattern. * internal/db/migrations/140_drop_deadline_rules.down.sql (new) — Best-effort restore from the snapshot. Triggers / indexes / CHECK constraints from historical migrations are NOT replayed; operator must reapply 078/079/091/095/098/122/128/134/135 to bring the restored table to working shape. The down path is for catastrophic recovery, not casual revert. * internal/services/rule_editor_service.go — Six syncDualWriteFromDeadlineRule(...) calls removed (the INSTEAD OF triggers now do the fan-out). Five INSERT/UPDATE paliad.deadline_rules statements (Create, UpdateDraft, CloneAsDraft INSERT+SELECT, Publish, peer-archive, flipLifecycle) renamed to paliad.deadline_rules_unified — trigger handles the routing. * internal/services/rule_editor_orphans.go — ResolveOrphan no longer writes deadlines.rule_id (column dropped). Sets sequencing_rule_id directly + derives procedural_event_id from the matching sequencing_rules row in the same UPDATE statement. * internal/services/deadline_service.go — deadlineColumns now lists sequencing_rule_id (Deadline.RuleID still binds to it via the db tag rename below). Update path's appendSet("rule_id",…) flipped to appendSet("sequencing_rule_id",…) and post-write derivation moved to the renamed syncDeadlineProceduralEventID helper. * internal/services/projection_service.go, internal/services/submission_vars.go — `WHERE rule_id = $X` reads on paliad.deadlines flipped to sequencing_rule_id. * internal/models/models.go — Deadline.RuleID db tag changed from "rule_id" to "sequencing_rule_id". Field name + JSON name kept for backward compat with the frontend and existing Go callers; semantic value is identical (same UUID). * internal/services/dual_write.go — Massively trimmed. Removed: syncDualWriteFromDeadlineRule, syncDeadlineDualLinks, CheckDualWriteDrift, DualWriteDriftReport, HasDrift, StartDualWriteDriftCheckLoop. All referenced paliad.deadline_rules which no longer exists. Kept (renamed): syncDeadlineProceduralEventID — derives procedural_event_id from sequencing_rule_id after any DeadlineService.Update that touched the back-link. * cmd/server/main.go — Removed the StartDualWriteDriftCheckLoop bootstrap call (and its `time` import that only that call needed). Comment notes the retirement. * internal/services/dual_write_test.go — Removed the final CheckDualWriteDrift assertion in TestDualWrite_RuleEditorLifecycle (function deleted). The per-step asserts against procedural_events / sequencing_rules / legal_sources cover the same contract by direct query. Hard rules followed: - Audit-first: snapshot precedes destructive ops in the same TX. - No silent data loss: pre-drop drift was zero; snapshot captures the final state; FK re-points use identical UUIDs. - INSTEAD OF triggers documented in mig 140 — single source of truth for the legacy→new mapping. - Down migration is honest about its scope (catastrophic recovery only). Build + vet clean. TestMigrations_NoDuplicateSlot passes. Live-DB tests skipped (no TEST_DATABASE_URL in this env) — they'll exercise the full mig 140 + INSTEAD OF triggers in CI.	2026-05-26 19:53:24 +02:00
mAi	f963b0df34	feat(submissions): Composer Slice B — editable prose sections + anchor-spliced render (m/paliad#141) ... The "Composer actually works" milestone per the design at docs/design-submission-generator-v2-2026-05-26.md §12 Slice B. Builds on Slice A's substrate (submission_bases, submission_sections, base_id on drafts); no new migrations needed. Backend additions: - internal/services/submission_md.go (~240 LoC): Markdown → OOXML walker. Per the head's Slice B brief, scope is paragraphs + bold/italic + blank-line spacing. Placeholders pass through unchanged for the v1 substitution pass. CRLF normalisation; nested formatting (***bold-italic***); two delimiter forms (* and _); XML-escaping for &/</>; explicit empty-paragraph emit so blank lines round-trip. 12 unit tests. - internal/services/submission_compose.go (~470 LoC): SubmissionComposer service. Pipeline: ConvertDotmToDocx pre-pass → extract word/document.xml → render each included section's content_md_<lang> → splice via {{#section:KEY}}/{{/section:KEY}} anchor pairs in the body → strip anchors for excluded sections → append unanchored sections before <w:sectPr> → repack zip → run v1 placeholder pass. RE2-friendly anchor scanner walks markers in body-order and matches open/close pairs with a stack (handles unbalanced anchors defensively). 6 unit tests covering anchor-mode splice, append-mode-no-anchors, excluded-section drop, placeholder resolution, lang column pick, order_index ASC. - internal/services/submission_section_service.go: SectionPatch + Update method. Six optional fields (content_md_de/en, included, label_de/en, order_index). Sentinel ErrSubmissionSectionNotFound on RLS-filtered miss. - internal/handlers/submission_sections.go (NEW, ~150 LoC): PATCH /api/submission-drafts/{draft_id}/sections/{section_id}. Owner-scoped via SubmissionDraftService.Get; section-belongs-to-draft cross-check. 404 on both missing-draft and section-belongs-elsewhere paths. - internal/handlers/files.go: fetchComposerBaseBytes + composerBaseSlugMap reuse the existing Gitea proxy cache for base .docx bytes. hlc-letterhead → existing firmSkeletonSubmissionSlug, neutral → existing skeletonSubmissionSlug. - internal/handlers/submission_drafts.go: exportSubmissionDraft helper branches on draft.BaseID. When set AND base + bytes + sections all resolve → Composer pipeline. Else v1 fallback render path stays. Audit metadata jsonb gains "composer": true + "base_id" flag when composer was used. Wiring: - handlers.Services gains SubmissionComposer. - dbServices.submissionComposer wired from svc.SubmissionComposer. - main.go instantiates NewSubmissionComposer with the existing SubmissionRenderer (so the {{rule.X}} alias contract stays preserved inside section content). Frontend additions (~400 LoC): - client/submission-draft.ts: paintSectionList rewritten to render a contentEditable per included section with a per-section B/I toolbar. Per-section autosave debounced 500ms; mousedown handlers on toolbar buttons preserve editor focus mid-command. domToMarkdown walks the contentEditable's DOM tree back to Markdown source-of- truth (b/strong → **…**, i/em → *…*, div/p → paragraph break, br → newline). Updated state.view.sections in-place on PATCH success without re-painting (avoids focus-stealing on every keystroke); re-paints only on structural changes (included toggle, label edits, order changes). - client/submission-draft.ts: onSectionToggleIncluded hides/shows a section via PATCH. flushSectionAutosave on blur force-flushes pending edits so leaving an editor doesn't strand unsynced changes. - styles/global.css: editor surface (contentEditable area with focus ring + placeholder), toolbar buttons (B/I 1.8rem squares), per-section "Hide"/"Include" toggle in the head row. - Updated i18n hint copy: "Inhalt pro Abschnitt — Autosave nach 500ms. Letztes Layout in Word." Templates regenerated on Gitea: - _skeleton.docx → composer-mode body (anchors only): blob SHA ac0cdeaf49f7cd417ec143e2319ffbb02ec65644. - _firm-skeleton.docx → composer-mode body (anchors only, preserves sectPr → firm header/footer rIds): blob SHA f1e9a9fb9a29ca01bf7bee709a45c5dda2a8e317. - Both uploaded as mAi via --netrc-file ~/.netrc-mai. - gen-skeleton-submission-template script gains an -anchors flag (default true) so future regens emit composer-ready bodies. The _firm-skeleton.docx regen was done via a one-off /tmp helper since the gen-hl-skeleton-template script requires the proprietary .dotm source which lives in HL/mWorkRepo; extending that script to accept an existing .docx as input is a follow-up cleanup. Build hygiene: go build/vet/test -short ./internal/... ./cmd/... all clean; bun run build clean (2900 i18n keys, data-i18n scan clean). NO behavior change for pre-Composer drafts (base_id NULL → v1 fallback render path stays compiled in). NO migrations needed in this slice — sections were already in the schema from Slice A; only content_md_de/en UPDATEs happen via the new PATCH endpoint. Hard rules per Q2/Q10 ratification still honoured: - No building_block_id lineage (Slice C territory; Q2). - Caption/letterhead/signature are regular prose sections, seeded from base spec; lawyer can edit/hide freely (Q10). - {{rule.X}} aliases preserved (renderer pass unchanged). NOT in scope per Slice B brief: - Headings 1–3, lists, blockquote (Slice D's MD walker extension). - Building blocks library (Slice C). - Reorder / add-custom-section (Slice F). - Auto-upgrade of pre-Composer drafts (Slice C — explicitly NOT in this slice per head's brief msg #2393). t-paliad-313 Slice B	2026-05-26 19:45:29 +02:00
mAi	6cd340300b	Merge: t-paliad-313 — Composer Slice A: base picker + read-only section list (migs 146/147/148) (m/paliad#141)	2026-05-26 19:25:08 +02:00
mAi	3af71e772b	fix(paliadin): fall back to one-shot when aichat persona lacks streaming ... Symptom: paliadin chat returns "Verbindung verloren" because aichat's paliadin persona is not configured with streaming support — every RunTurnStream() call gets back HTTP 400 unsupported_streaming and the SSE stream closes empty. Fix: when RunTurnStream() detects "unsupported_streaming" in the upstream error, transparently retry against /chat/turn (non-streaming) with the same body. The full response gets emitted as a single StreamChunk + StreamMeta so the SSE relay sees identical event ordering. Persistence (completeTurn + markPrimed) mirrors the one-shot RunTurn() path. No real-time chunking until the persona is reconfigured upstream, but the chat works end-to-end. Once the paliadin persona supports streaming on aichat, this code path goes dormant — the unsupported_streaming branch is only entered when the upstream actually returns that error. Diagnostic logs from commit 937ff13 made this visible: paliadin: backend returned error err=aichat: HTTP 400 (bad_request): unsupported_streaming: persona paliadin does not support streaming Refs m/paliad demo path.	2026-05-26 19:24:41 +02:00
mAi	e2969fc358	feat(submissions): Composer Slice A — base picker + read-only section list (m/paliad#141) ... The first slice of the Submission generator v2 ("Composer") per the design at docs/design-submission-generator-v2-2026-05-26.md §12 Slice A. Ships the base concept + per-draft section seeding end-to-end with NO change to the .docx render path — v1 export still works exactly as today. Schema (mig 146/147/148): - paliad.submission_bases — catalog table; one row per template base (slug, firm, proceeding_family, label_de/en, gitea_path, section_spec jsonb, is_default_for[]). RLS: wide-open SELECT for authenticated users, mutations admin-only (handler-enforced, no RLS write paths). Seeded with 2 rows: hlc-letterhead → _firm-skeleton.docx; neutral → _skeleton.docx. Each section_spec carries the 10-section default (letterhead, caption, introduction, requests, facts, legal_argument, evidence, exhibits, closing, signature) with bilingual labels + bag-driven seed Markdown for caption/letterhead/signature. - paliad.submission_drafts gains base_id (FK SET NULL, optional) + composer_meta jsonb (default '{}'). Purely additive; pre-Composer drafts keep base_id NULL → v1 fallback render path stays active. - paliad.submission_sections — per-draft section rows (draft_id, section_key, order_index, kind ∈ {prose,requests,evidence}, label_de/en, included, content_md_de/en). RLS mirrors submission_drafts (owner-scoped + can_see_project, four policies). Backend: - BaseService (read-only Slice A): List + GetByID + GetBySlug + GetDefaultForCode (firm/family fallback chain). - SectionService: ListForDraft + Get + SeedFromSpec (transactional multi-INSERT). - SubmissionDraftService.AttachComposer wires both; Create resolves the firm default base and seeds base_id + section rows in one tx. Composer wiring is additive — when bases==nil the service stays v1-shaped. - Update accepts BaseID **uuid.UUID (set / clear / no-change). - submissionDraftView gains BaseID, ComposerMeta, Sections fields. - Routes: GET /api/submission-bases (catalog list). PATCH endpoints on both project-scoped and global drafts accept "base_id". Frontend: - submission-draft.tsx: base picker dropdown above language toggle (hidden until catalog loads); section-list pane above the preview (hidden when no rows). - client/submission-draft.ts: loadBases() parallel-fetches on boot; paintBasePicker rebuilds <option> list on every paint; onBaseChange PATCHes base_id and repaints; paintSectionList renders each section read-only (label + kind chip + excluded badge + Markdown body). - Per the brief: NO auto-upgrade of existing 11 drafts (that's Slice C). Pre-Composer drafts get the picker (catalog still loads) but the section pane stays hidden until they pick a base on a new draft. Tests: - TestFamilyOfCode + TestBaseSectionSpec_DecodeShape + _EmptyDecode (pure unit, no DB). - TestComposerSeedFlow (live, TEST_DATABASE_URL-gated): asserts mig 146 seeded 10 default sections on both bases; GetDefaultForCode picks hlc-letterhead for HLC/de.inf.lg.erwidg; new draft via Create seeds base_id + 10 section rows in tx with ascending order_index and bilingual labels populated. NO behavior change to .docx export — the v1 path stays sole render path this slice. Composer's anchor-based assembly engine + MD→OOXML walker land in Slice B. Build hygiene: go build/vet/test -short clean; bun run build clean (2900 i18n keys, data-i18n scan clean). t-paliad-313	2026-05-26 19:23:40 +02:00
mAi	8125caf49a	test(backup): add TEST_DATABASE_URL-gated live smokes for org export ... Two complementary live tests (both skipped without TEST_DATABASE_URL): - TestResolveOrgSheets_LiveSchemaSnapshot — runs the schema probe + SQL composer the way the backup runner does at the start of every run, then executes each resolved SELECT against the live DB (wrapped in LIMIT 1 to keep table reads cheap). A future column rename in a table our spec still names triggers this test and surfaces in CI before /admin/backups breaks. - TestWriteOrg_LiveSmoke — end-to-end pipeline against a real DB: schema probe, REPEATABLE READ tx, every sheet query, xlsx + JSON + per-sheet CSV assembly, outer zip framing. Spot-checks meta.RowCounts and the zip magic bytes; doesn't materialise the full bundle to disk. Both tests exercise the exact failure mode m/paliad#140 reproduced (hardcoded ORDER BY against a renamed column) so CI catches regressions once TEST_DATABASE_URL is wired. m/paliad#140	2026-05-26 18:19:55 +02:00
mAi	935ea23038	refactor(backup): make orgSheetQueries drift-resistant ... Refactor orgSheetQueries() into orgSheetSpecs() returning declarative (SheetName, Table, OrderBy []string) triples instead of free-form SQL, with composeOrgSheetSQL() as a pure builder and resolveOrgSheets() as the DB-touching orchestrator. At backup time the resolver: 1. probes information_schema.columns once for every spec table, 2. composes SELECT * FROM <table> ORDER BY <columns-that-exist>, 3. logs WARN per ORDER BY column dropped because it's gone. A future column rename or removal can no longer break /admin/backups: the worst case is one sheet temporarily losing sort stability, and the WARN log surfaces which spec needs updating. Sheets needing custom projections (documents drops ai_extracted) keep the SQL override path. All other org-scope sheets — entity + ref__ — declare their ORDER BY as a column list. Tests: - 6 composeOrgSheetSQL unit tests cover the drift behaviour with no DB needed (missing column, all-missing, override bypass, declared order preserved, unknown table) - Existing registry-shape tests (no duplicates, no paliadin leakage, ref__ prefix, ORDER BY-for-determinism) updated to the spec API - Full internal/services suite green m/paliad#140	2026-05-26 18:17:21 +02:00
mAi	da464813b7	fix(backup): repair 4 broken ORDER BY columns in orgSheetQueries ... Backup export was 100% broken because four sheets referenced columns that no longer exist (or never did) in their target tables: - email_templates: ORDER BY id → key, lang (composite PK) - policy_audit_log: ORDER BY changed_at → created_at - ref__deadline_event_types: ORDER BY rule_id → deadline_id (post-rename) - ref__event_category_concepts: ORDER BY category_id → event_category_id Audited every entry in orgSheetQueries() against information_schema.columns; these were the only mismatches. Patch unblocks /admin/backups → Generate. Drift-resistant refactor (m/paliad#140 Part B) follows in a separate commit. m/paliad#140	2026-05-26 18:13:27 +02:00
mAi	d1aa0f72c0	Merge: t-paliad-305 — Slice B.3: read cutover via paliad.deadline_rules_unified view (mig 139); legacy writes retire in B.4 (m/paliad#93)	2026-05-26 18:01:25 +02:00
mAi	83be122b19	fix(backup): export ORDER BY uses binding_id, not calendar_binding_id ... paliad.appointment_caldav_targets's join column is named binding_id (mig 101). The backup sheet exporter referenced calendar_binding_id which doesn't exist, so /admin/backups generate failed with 42703. Single-char fix. Also flags follow-up: hardcoded ORDER BY columns on every sheet in orgSheetQueries() are fragile under schema renames — a separate slice (m/paliad#140) tracks making the exporter flexible to drift (e.g. probe information_schema or use NULLS LAST id-only).	2026-05-26 18:00:17 +02:00
mAi	df592f9fc4	feat(db,services): Slice B.3 read cutover — flip reads to paliad.deadline_rules_unified view backed by sr+pe+ls (t-paliad-305 / m/paliad#93) ... The new tables (mig 136) and the dual-write that keeps them in sync (B.2) have been steady-state in prod since mig 136 deployed at 13:24 UTC today. Drift verified clean before this commit: deadline_rules=231, sequencing_rules=231, procedural_events=231 (153 codes + 78 synthetic), legal_sources=87, zero mismatches across counts, FK integrity, lifecycle, is_active. This commit flips READ paths to source data from the new tables via a backwards-compatible view, leaving the dual-write WRITE paths untouched for B.4 to retire alongside the destructive drop. * internal/db/migrations/139_deadline_rules_unified_view.up.sql (new) — CREATE VIEW paliad.deadline_rules_unified projecting sr+pe+ls back into the legacy paliad.deadline_rules column shape. Same column names + types so the Go-side change is a 1-token substitution per query with no struct or scanner edits. Post-apply DO block asserts view row count = sequencing_rules row count (FK NOT NULL on procedural_event_id guarantees they match). * 10 service / handler files — every SELECT FROM paliad.deadline_rules (or JOIN paliad.deadline_rules) flipped to use the view: - internal/handlers/submissions.go (Schriftsätze list) - internal/services/deadline_rule_service.go (8 read sites) - internal/services/rule_editor_service.go (3 read sites — ListRules, getByID, validateSpawnNoCycle) - internal/services/rule_editor_orphans.go (candidate-rule lookup) - internal/services/submission_vars.go (loadPublishedRule) - internal/services/deadline_service.go (deadlines list join) - internal/services/fristenrechner.go (calculator reads) - internal/services/projection_service.go (projection reads) - internal/services/event_deadline_service.go (event→rule join) - internal/services/export_service.go (3 export sites — ref__deadline_rules) Verified semantically safe on live (read-only smoke): - 231 rows in view match 231 in legacy. - name + event_type pair: 231/231 match. - legal_source: 231/231 match (NULL on both sides treated as match). - submission_code: 153 non-NULL codes match exactly; the 78 synthetic 'null.<8hex>' codes diverge from legacy NULL but no reader filters on NULL submission_code (verified handlers/submissions.go: synthetic-code rules all have NULL event_type so the WHERE event_type = 'filing' filter excludes them; the Schriftsätze surface returns the same 105 rows). Scope decisions documented (deviation from design §5.3): - B.3 ships the READ flip only. WRITE paths (RuleEditorService Create / UpdateDraft / CloneAsDraft / Publish / flipLifecycle) retain the dual-write from B.2 — they write to both legacy and new tables. B.4 (destructive drop) will retire the legacy writes in the same slice that drops the table, avoiding a transient state where the legacy writes have no purpose. - The B.2 drift-check ticker (StartDualWriteDriftCheckLoop) stays active for the same reason: dual-write continues, so the invariants the loop checks remain meaningful. This shape is paliadin-approvable on a "good solution > strict phase boundary" reading of m's greenlight. If paliadin pushes back and wants the legacy writes removed in B.3, the refactor is ~300 LOC across the 5 RuleEditorService write methods + buildPatchSets split into PE/SR sets — schedulable as B.3.5 before B.4. Build + vet clean. TestMigrations_NoDuplicateSlot passes.	2026-05-26 17:59:58 +02:00
mAi	8f1a287549	Merge: t-paliad-305 — Slice B.2: dual-write to deadline_rules + procedural_events/sequencing_rules/legal_sources (m/paliad#93)	2026-05-26 17:50:57 +02:00
mAi	38ebccc907	feat(services): Slice B.2 dual-write — RuleEditorService writes deadline_rules AND procedural_events / sequencing_rules / legal_sources (t-paliad-305 / m/paliad#93) ... Keeps the parallel new tables (mig 136, Slice B.1) in lock-step with the legacy paliad.deadline_rules table through every write path on RuleEditorService. Read paths stay on deadline_rules in B.2 — B.3 flips them and stops legacy writes. * internal/services/dual_write.go (new) — - syncDualWriteFromDeadlineRule(ctx, tx, id): idempotent UPSERT of legal_sources + procedural_events + sequencing_rules from the just-written deadline_rules row. Pure SQL projection, no Go-side struct mapping. Synthetic-code mint expression is byte-identical to mig 136 ('null.' || first 8 hex of stripped uuid). - syncDeadlineDualLinks(ctx, tx, deadlineID): mirrors a deadline's legacy rule_id back-link onto deadlines.procedural_event_id + sequencing_rule_id. Handles NULL rule_id naturally (collapses both new columns to NULL). - CheckDualWriteDrift(ctx, conn): nine read-only count queries + integrity joins. Returns DualWriteDriftReport. HasDrift() bool for log routing. - StartDualWriteDriftCheckLoop(ctx, conn, interval): goroutine ticker that runs CheckDualWriteDrift every `interval` (default 6h) for the lifetime of ctx. Clean run logs at INFO; drift at WARN with full report. * internal/services/rule_editor_service.go — - Create / UpdateDraft / CloneAsDraft / Publish / flipLifecycle each call syncDualWriteFromDeadlineRule(ctx, tx, id) after the deadline_rules mutation, before tx.Commit. Publish syncs BOTH the published draft AND the cloned-from peer it just archived as a cascade. The audit_reason already set via setAuditReasonTx propagates to the new-table writes (same TX, same session). * internal/services/rule_editor_orphans.go — - ResolveOrphan calls syncDeadlineDualLinks after UPDATE paliad.deadlines SET rule_id = $1, so the parallel new columns follow the legacy back-link. * internal/services/deadline_service.go — - DeadlineService.Update calls syncDeadlineDualLinks when input.RuleSet is true (auto/custom rule swap from t-paliad-258). * cmd/server/main.go — - Spawns StartDualWriteDriftCheckLoop alongside CalDAV sync and reminder scanner. Inherits bgCtx so the goroutine stops on SIGTERM. Interval 6h. * internal/services/dual_write_test.go (new) — - TestDualWrite_RuleEditorLifecycle: Create → UpdateDraft → Publish → Archive, asserts the new tables mirror at each step. Final CheckDualWriteDrift returns zero drift. - TestDualWrite_SyntheticCodeForNullSubmission: rule created with submission_code=NULL gets a 'null.<8hex>' procedural_events row matching mig 136's mint expression byte-for-byte. Scope decisions documented in the commit: - B.2 keeps read paths on deadline_rules. paliadin's "Read paths fall back to legacy" reads as "reads stay on legacy as the safety net while drift-check validates the new tables". B.3 swaps reads to new tables only AND stops writing to deadline_rules — that's a separate slice per the design's §5.2/§5.3 split. - B.2 does NOT modify submission_drafts, projection_service, the Fristenrechner calculator, the SubmissionVarsService, the Schriftsätze list query, or any other reader. They keep reading deadline_rules unchanged. The new tables are populated in parallel for B.3's cutover. - Audit triggers on deadline_rules continue to fire as before. The new tables have no audit triggers yet (a later slice can add parallel audit rows once the new tables are authoritative). - Drift-check uses default 6h interval — short enough that a broken dual-write surfaces within the same business day, long enough that the count-COUNTs don't churn the pool. Override via the caller in cmd/server. Hard rules followed: - audit_reason set on every TX before any deadline_rules mutation (existing pattern; new-table writes share the same reason). - No destructive op (B.2 is strictly additive in behaviour). - New helpers idempotent (UPSERT ON CONFLICT DO UPDATE) — safe to call twice, safe to re-run after a partial failure. Build + vet clean. TestMigrations_NoDuplicateSlot passes.	2026-05-26 17:49:48 +02:00
mAi	cd5f752a0e	feat(litigationplanner): scenarios — paliad.scenarios jsonb table + Catalog API + engine adapter (Slice D, t-paliad-306, m/paliad#124 §5) ... A scenario is a named composition of existing proceedings + flags + per-card choices + anchor dates. Users compose, they don't author — spec references existing rules by submission_code; never creates new rules. Per m's 2026-05-26 AskUserQuestion picks (doc commit 6e58595): Q1 composition: primary + spawned (v1); multi-proceeding peer compose is the v2 goal (spec.proceedings[] array) Q2 scope: per-project + abstract (project_id NULL = abstract) Q3 trigger: per-anchor overrides over one base date Q4 storage: NEW paliad.scenarios table with jsonb spec (NOT a project_event_choices column extension) Migration 145 — additive only. Pre-flight coordination check: - On-disk max: 138 (Berufung backfill, just merged). - Live DB tracker: 106 (significantly behind — many migs pending deploy). - curie's #93 B.2-B.6 migs not pushed yet — reserved 139-143 + 144 as buffer; claimed 145 as the safe minimum that won't collide. - paliad.scenarios has audit_reason NOT applicable (no audit trigger on the table); updated_at trigger added on the table itself. - paliad.projects gains active_scenario_id uuid NULL FK with ON DELETE SET NULL (mig 134 lesson — no updated_at clauses on proceeding_types-style assumptions). Schema: paliad.scenarios ( id uuid pk, project_id uuid NULL FK → projects(id) ON DELETE CASCADE, name text NOT NULL CHECK char_length > 0, description text NULL, spec jsonb NOT NULL CHECK jsonb_typeof = 'object', created_by uuid NULL FK → users(id) ON DELETE SET NULL, created_at + updated_at timestamptz, UNIQUE NULLS NOT DISTINCT (project_id, created_by, name) ); paliad.projects.active_scenario_id uuid NULL FK; RLS: project-scoped → can_see_project; abstract → created_by = auth.uid(); Trigger: scenarios_touch_updated_at_trg. pkg/litigationplanner additions: - Scenario struct (db + json tags) - ScenarioSpec / ScenarioProceeding / ScenarioCardChoice — parsed view of the jsonb (version-1 today, v2 multi-peer-ready) - ParseSpec(raw) + ScenarioSpec.PrimaryProceeding() + CalcOptionsFromSpec() - ScenarioFilter + Catalog.LoadScenarios + Catalog.MatchScenario - CalculateFromScenario(scenario, catalog, holidays, courts) — high- level engine entry: parses spec → builds CalcOptions → delegates to Calculate - Sentinel errors: ErrUnknownScenario, ErrInvalidScenario, ErrScenarioNoPrimary paliadCatalog impl: - LoadScenarios with progressively-built WHERE clauses (project-id filter, abstract-for-user filter, or all) - MatchScenario by id — returns ErrUnknownScenario on not-found - Services connection bypasses RLS; ScenarioService enforces visibility at the application layer (mirrors EventChoiceService pattern from t-paliad-265) SnapshotCatalog impl (embedded/upc): - LoadScenarios returns empty slice (no scenarios in the snapshot) - MatchScenario returns ErrUnknownScenario internal/services/scenario_service.go: - Create / Get / ListForProject / ListAbstractForUser / Patch / SetActive / Delete with visibility checks - validateSpec checks version, base_trigger_date format, every proceedings[*].code resolves to an active paliad.proceeding_types row, every appeal_target is valid, every anchor_overrides date parses, every role ∈ {primary, peer} - SetActive validates the scenario belongs to the requested project (a scenario from a different project can't be active here) - Returns ErrScenarioNotVisible for failed visibility checks REST endpoints (registered in handlers.go): GET /api/scenarios?project=<id> — list project's GET /api/scenarios?abstract=true — list user's abstract GET /api/scenarios/{id} — one POST /api/scenarios — create PATCH /api/scenarios/{id} — partial update DELETE /api/scenarios/{id} — remove PUT /api/projects/{id}/active-scenario — set / clear active Handler error mapping: - ErrUnknownScenario / ErrScenarioNotVisible → 404 - ErrInvalidInput / ErrInvalidScenario / ErrScenarioNoPrimary → 400 - everything else → 500 Tests: - pkg/litigationplanner/scenarios_test.go: ParseSpec roundtrip (well-formed + unknown version + malformed json), PrimaryProceeding zero/multi/single, CalcOptionsFromSpec full unpack, trigger_date_override path, no-base-trigger safety check. 8 cases total, all DB-free. Wired in cmd/server/main.go alongside EventChoice — same pattern, nil-safe when DATABASE_URL is unset (handlers 503 in that mode). Acceptance: - go build ./... clean - go test ./... all green (incl. new scenarios tests) - Pre-flight audit confirmed mig 145 number is safe vs curie's pending B.2-B.6 range	2026-05-26 17:48:56 +02:00
mAi	5cff38ff3c	feat(deadlines): mig 138 backfill applies_to_target — Schadensbemessung (merits) + Bucheinsicht (order) ... After Slice B1's Berufung unification (mig 134), the picker exposed five appeal targets but only three carried rules. Schadensbemessung and Bucheinsicht returned empty timelines. m's 2026-05-26 decision (#134): R.224 is uniform across substantive R.118 decisions, and R.220.2 / R.224.2.b / R.235.2 / R.237 / R.238.2 are uniform across the orders they appeal — so the existing merits-track and order-track rules can carry the missing targets via a non-destructive applies_to_target extension. Audit of live `paliad.deadline_rules` for upc.apl.unified (proceeding_type_id=160): - 7 endentscheidung rules → extend with 'schadensbemessung' - 7 anordnung rules → extend with 'bucheinsicht' - 2 kostenentscheidung rules — untouched (distinct leave-to-appeal track) Migration: - set_config('paliad.audit_reason', …) at top of UP and DOWN — required by the mig 079 deadline_rule_audit_trigger on every UPDATE. - Audit-first DO block lists every row to be touched (pre/post state) and RAISE EXCEPTIONs on pre-condition drift (missing proceeding_type, wrong rule counts, partial-run carry-over of the new targets). - Two narrow UPDATEs keyed off upc.apl.unified + existing target + absence of new target. - Post-sanity asserts schad=7, buch=7, end=7, anord=7, cost=2 — hard RAISE EXCEPTION on any drift. - DOWN strips both new targets via array_remove with the same WHERE. - No deadline_rules.updated_at writes; column exists but the migration is single-purpose and leaves it as-is. Dry-run via Supabase MCP confirmed: - UP yields {schad:7, buch:7, end:7, anord:7, cost:2} on prod. - DOWN restores {schad:0, buch:0, end:7, anord:7, cost:2}. - DB returned to pre-state; the real golang-migrate boot path will apply 138 cleanly at next deploy. Version bump 137→138: cronus's mig 137 (proceeding_role_labels, #132) merged to main while this branch was in flight. Rebased onto current main, renamed files, rewrote all "mig 137" references inside the SQL + test code. Test: - lookup_events_test.go: the schadensbemessung empty-result assertion becomes the inverse (rules expected). Adds a parallel bucheinsicht assertion. Same anchor-row shape check as the existing endentscheidung case (DepthFromAnchor=1, target ∈ AppliesToTarget, proceeding_type = upc.apl.unified). - `go test ./...` green post-rebase, including pkg/litigationplanner/ appeal_target_label_test.go added by cronus's mig 137. Refs: m/paliad#134, t-paliad-303. Lessons applied from mig 134 hotfixes: audit_reason set_config, no updated_at writes, audit live DB before drafting, RAISE EXCEPTION on integrity violations.	2026-05-26 15:43:36 +02:00
mAi	9da4715137	feat(litigationplanner): Berufung tile UX — collapse side selectors + appeal-target trigger label (t-paliad-301, m/paliad#132) ... Two bugs from the Slice B1 Berufung rollout, one fix surface: Bug A — duplicate side selectors collapse into ONE proactive-side picker with per-proceeding role labels. The Verfahrensablauf used to show both ?side= (Klägerseite/Beklagtenseite) AND ?appellant= (same labels in case-form) on the Berufung tile. Now: one side picker, with labels that swap to Berufungskläger/Berufungsbeklagter on the unified upc.apl.unified tile (and Antragsteller/Antragsgegner Nichtigkeit on upc.rev.cfi, Einsprechende(r)/Patentinhaber(in) on epa.opp.*). Bug B — 'Auslösendes Ereignis' label derives from appeal_target on the unified Berufung tile (5 target-specific strings) instead of the proceeding's own trigger_event_label. Endentscheidung (R.118) / Kostenentscheidung / Anordnung / Entscheidung im Schadensbemessungsverfahren / Anordnung der Bucheinsicht. Migration 137 (additive, no triggers on proceeding_types — verified via mcp__supabase__execute_sql before drafting; no updated_at on the table — lesson from mig 134 HOTFIX 3; no audit_reason setup needed): - ADD COLUMN role_proactive_label_de (text NULL) - ADD COLUMN role_proactive_label_en (text NULL) - ADD COLUMN role_reactive_label_de (text NULL) - ADD COLUMN role_reactive_label_en (text NULL) - Audit-first DO block lists the rows the UPDATE will touch. - Backfill 4 proceedings (upc.apl.unified + upc.rev.cfi + epa.opp.opd + epa.opp.boa); every other proceeding stays NULL and the renderer falls back to default labels. - Down drops the 4 columns. Package additions (pkg/litigationplanner): - ProceedingType gains 4 *string fields (RoleProactive/Reactive LabelDE/EN) — db tags match the new columns; existing scans pick them up via the proceedingTypeColumns extension. - TriggerEventLabelForAppealTarget(target, lang) — Go-side map of the 5 appeal-target slugs to their DE/EN trigger-event labels. Empty result on unknown target signals "fall back to proceeding's own trigger_event_label". - Engine override: when CalcOptions.AppealTarget is set, the resulting Timeline.TriggerEventLabel/EN are replaced from the per-target map. Frontend: - Removed #appellant-row div (was a separate 3-radio selector duplicating side). - Dropped ?appellant= URL state + the change handler + the init readback. The engine still consumes "appellant" — sourced from currentSide for role-swap proceedings; null otherwise. - applyRoleLabels(proceedingType) swaps the side-row radio labels from a hardcoded ROLE_LABELS map mirroring mig 137's backfill. Falls back to deadlines.side.claimant/defendant i18n keys for proceedings without overrides. - syncTriggerEventLabel reads data.triggerEventLabel from the calc response — which the engine override now sets per appeal_target, so no client-side mapping needed. - i18n cleanup: removed orphan deadlines.appellant.* keys (label / claimant / defendant / none) in both DE + EN. Tests: - pkg/litigationplanner/appeal_target_label_test.go pins the 5×2 label matrix + a coverage test that fails if a new entry in AppealTargets is added without populating the label switch. Acceptance: - go build + go test all green (incl. new lp test). - bun run build clean (i18n codegen drops 4 keys, regenerates). - Live-DB audit before drafting confirmed: 4 target columns don't exist on proceeding_types, zero triggers on the table, exact column inventory matches the design.	2026-05-26 15:37:10 +02:00
mAi	e2d75c391d	fix(litigationplanner): rename upc.apl → upc.apl.unified (HOTFIX, t-paliad-299, m/paliad#130) ... mig 134 was inserting code='upc.apl' (2 segments) into paliad.proceeding_types, which carries paliad_proceeding_code_shape CHECK requiring 3 dot-segments OR '^_archived_'. Every container restart hit the constraint, rolled the migration TXN back, and crash-looped paliad.de. Rename the unified Berufung code to 'upc.apl.unified' (3 segments, satisfies the constraint, preserves design intent). The pre-existing constraint is a useful jurisdiction.category.specific invariant — keep it, fix the new row. Touched only string literals: - mig 134 up.sql + down.sql (insert, lookups, post-checks) - frontend/src/verfahrensablauf.tsx (UPC_TYPES code + i18nKey) - frontend/src/client/verfahrensablauf.ts (APPELLANT_AXIS + APPEAL_TARGET sets) - frontend/src/client/i18n.ts (DE + EN translation rows) - frontend/src/i18n-keys.ts (auto-regen via bun build) - internal/services/lookup_events_test.go (anchor-row assertion) Verified: `grep -rn "'upc\.apl'\|\"upc\.apl\""` returns zero hits. go build, bun run build, go test ./... all green.	2026-05-26 15:09:12 +02:00
mAi	989941c648	feat(litigationplanner): primary_party CHECK constraint + IsValidPrimaryParty helper (Slice B3, m/paliad#124 §18.3) ... Tightens paliad.deadline_rules.primary_party from free-text to a CHECK constraint over the canonical four-value vocab (claimant / defendant / court / both). NULL stays valid for the 78 cross-cutting orphan concept seeds (Wiedereinsetzung, Versäumnisurteil-Einspruch, Schriftsatznachreichung, Weiterbehandlung) — they have no proceeding_type_id binding so they're outside the calculator's path; loosening the CHECK to "IS NULL OR IN (…)" keeps them valid without backfill gymnastics. Migration 135 (audit-first): - DO block RAISEs NOTICE for every non-conforming row + RAISEs EXCEPTION if any dirty rows exist (manual cleanup required). Live audit (Supabase, 2026-05-26 §18.0) confirmed zero dirty rows on the current corpus; the audit pass stays in the migration as safety against future drift. - ALTER TABLE … ADD CONSTRAINT deadline_rules_primary_party_chk CHECK (primary_party IS NULL OR primary_party IN ('claimant', 'defendant', 'court', 'both')) - Post-migration distribution NOTICE so the operator sees the final per-value count. - Down = DROP CONSTRAINT. No data revert needed. Package additions (pkg/litigationplanner): - PrimaryParty* constants (PrimaryPartyClaimant / Defendant / Court / Both) + PrimaryParties[] ordered list + IsValidPrimaryParty(s) predicate. Empty string is "no value supplied" = valid (NULL maps to empty on the wire); non-empty must match one of the four canonical values. - Sibling unit tests (primary_party_test.go) pin the four-value vocab + the chip order + IsValidAppealTarget's matching shape. Rule-editor validation hook (rule_editor_service.go): - Create() validates input.PrimaryParty before INSERT. - UpdateDraft() validates patch.PrimaryParty before UPDATE. - Both surface a user-friendly 400 with the canonical vocab listed instead of leaking the raw PG CHECK constraint-violation message. - Uses errors.Is(err, ErrInvalidInput) so handler 400 routing continues to work. services/fristenrechner.go cleanup: - The B2-inlined isValidPartyForLookup helper is replaced with the canonical lp.IsValidPrimaryParty. No behaviour change. No frontend changes — the rule-editor's primary_party UI already constrains to the four values via a select; the validation hook is defense-in-depth. Audit: - go build + go test (incl. new lp unit tests) all green - Pre-migration audit confirmed: 26 claimant + 26 defendant + 38 court + 63 both + 78 NULL = 231 total, all in canonical vocab - event_categories.party (text[] array, narrower semantic) is NOT touched in this migration per the design doc's "out of scope, separate follow-up" decision	2026-05-26 13:58:33 +02:00
mAi	d5bf82314a	feat(litigationplanner): multi-axis catalog query API (Slice B2, m/paliad#124 §18.2) ... New Catalog.LookupEvents(ctx, axes, depth) method exposes a unified graph query over paliad.deadline_rules + paliad.proceeding_types + the deadline_concept_event_types junction. Used by the Determinator cascade, the scenarios surface (Slice D), and any future "show me events matching X" query — centralises a fan-out that today is duplicated across multiple client-side paths. Package additions (pkg/litigationplanner): - EventLookupAxes: optional Jurisdiction / *ProceedingTypeID / Party / *EventCategoryID / AppealTarget. All fields optional; the empty value (or nil pointer) is "no filter on this axis". Multiple non-zero axes apply as AND. - EventLookupDepth: "next" (1 hop downstream) or "all-following" (full chain). - EventMatch: Rule + ProceedingType + Priority + DepthFromAnchor + *ParentRuleID (populated only when the parent itself is in the returned set, so the frontend can render a tree). - Catalog interface gains LookupEvents. paliad-side implementation (internal/services/fristenrechner.go): - SQL pass with progressively-built WHERE clauses (one $N placeholder per non-zero axis). EventCategoryID uses an EXISTS subquery against paliad.event_category_concepts joined via concept_id. - Post-fetch parent_id graph walk in Go for depth control. Loads the per-proceeding rule corpus via DeadlineRuleService.List so children whose parent_id is in the anchor set can be added even when those children don't match the axes themselves. AllFollowing iterates to fixpoint; Next stops after one pass. - DepthFromAnchor computed by walking each result row up the parent_id chain until it hits an anchor (iteration-bounded to prevent infinite loops on hypothetical cycles). - Unknown axis values (jurisdiction="XX", party="foo", appealTarget="invalid") silently fall through as "no filter on this axis" — a stale frontend chip should not drop the entire result set. - "published + active" gate (lifecycle_state='published' AND is_active=true) matches LoadProceeding's WHERE clause. - Results ordered by (proceeding_type_id, sequence_order) so the frontend can render without re-sorting. Tests (internal/services/lookup_events_test.go): - Live-DB driven (skipped without TEST_DATABASE_URL, matches the existing TestCalculateRule pattern). - Cases: UPC-jurisdiction returns the UPC corpus only; party=defendant scopes anchor matches to defendant rules; unknown jurisdiction falls through; appeal_target=endentscheidung returns the merits rules from B1 mig 134; appeal_target=schadensbemessung returns empty (no rules seeded). No schema delta. No frontend wiring (the new HTTP endpoint at GET /api/tools/lookup-events can land in a follow-up slice — the package + paliad-side impl are the deliverable here).	2026-05-26 13:54:57 +02:00
mAi	07acf7b4a2	feat(litigationplanner): Berufung unification — one upc.apl + 5 appeal_target chips (Slice B1, m/paliad#124 §18.1) ... Collapses the 3 UPC appeal proceeding_types (upc.apl.merits 7 rules, upc.apl.cost 2, upc.apl.order 7 = 16 total across 3 codes) into ONE unified upc.apl proceeding type + a per-rule applies_to_target[] discriminator. The verfahrensablauf picker now shows one "Berufung" tile; after picking it, the user selects which decision the appeal is directed AT via a 5-chip group (Endentscheidung / Kostenentscheidung / Anordnung / Schadensbemessung / Bucheinsicht) and the engine filters rules whose applies_to_target contains the picked slug. m's 2026-05-26 decision: Schadensbemessung-as-appeal is a NEW first- class target with its OWN rule set (no shared inheritance from merits). The 5 enum values are all defined + addressable; for now schadensbemessung and bucheinsicht return empty timelines until rules are seeded in a follow-up slice (likely via /admin/rules or pairing with t-paliad-193 orphan-concept-seed). Migration 134 (additive only): - ADD proceeding_types.appeal_target text (CHECK on 5 slugs OR NULL) - ADD deadline_rules.applies_to_target text[] (CHECK each element in the 5 slugs) - INSERT the unified upc.apl row (inherits sort/color from upc.apl.merits) - Audit-first RAISE NOTICE pass listing every row about to be touched + a post-migration sanity check - Reassign rule rows: merits → applies_to_target={endentscheidung}, cost → {kostenentscheidung}, order → {anordnung} - Archive (is_active=false, NOT DELETE) the 3 old proceeding_types so historical FKs stay intact - Down migration restores is_active=true on the 3 old types, points rules back by their applies_to_target stamp, drops the unified row, drops both columns. Safe. Package additions (pkg/litigationplanner): - AppealTarget* constants + AppealTargets[] ordered list + IsValidAppealTarget(s) predicate (silent no-op on unknown slugs so a stale frontend chip doesn't break the render) - ProceedingType.AppealTarget *string field (top-level marker; NULL on non-appeal proceedings) - Rule.AppliesToTarget pq.StringArray field (per-row applies-to set) - CalcOptions.AppealTarget string (engine filter — when set, keeps only rules whose AppliesToTarget contains the slug) Engine filter runs after ApplyRuleOverrides but before the rule walk so the existing condition_expr / spawn / appellant-context machinery operates on the filtered subset transparently. paliad-side wiring: - deadline_rule_service.go: ruleColumns + proceedingTypeColumns extended to scan the new columns - handlers/fristenrechner.go: AppealTarget JSON field on the request payload, threaded into CalcOptions Frontend (verfahrensablauf surface only): - Single "Berufung" tile replaces the 3 separate Berufung tiles - New 5-chip appeal-target row, shown only when upc.apl is picked - URL state ?target=<slug>; default endentscheidung when none set - APPELLANT_AXIS_PROCEEDINGS updated: upc.apl.* (3 entries) → upc.apl (1 entry) - i18n keys (DE + EN) for the new tile + the 5 chip labels + the "Worauf richtet sich die Berufung?" / "Appeal against:" prompt - calculateDeadlines threads appealTarget through to the API Acceptance: - go build clean, go test all green (existing test suite — no new tests on the engine filter as a follow-up; the migration's sanity-check DO block guards the rule-reassignment count) - Live audit before drafting confirmed: 3 active UPC appeal proceeding_types, 16 rules total, primary_party already conforms to 4-value vocab on all proceeding-bound rules	2026-05-26 13:49:03 +02:00
mAi	5f0a85fa83	refactor(litigationplanner): extract Fristen/Verfahrensablauf calc into pkg/litigationplanner (Slice A, t-paliad-298 / m/paliad#124) ... Atomic extraction of the deadline-rule compute engine + types from internal/services into a new pkg/litigationplanner package that paliad + youpc.org can both import. No behaviour change — every existing test passes against the post-move shape. Package contents (~1850 LoC): - doc.go package docstring + reuse manifesto - types.go Rule, ProceedingType, NullableJSON, AdjustmentReason, HolidayDTO, CalcOptions, CalcRuleParams, Timeline, TimelineEntry, RuleCalculation*, FristenrechnerType, ProjectHint, sentinel errors - catalog.go Catalog interface (proceeding + rule lookups) - holidays.go HolidayCalendar interface - courts.go CourtRegistry interface + DefaultsForJurisdiction + country/regime constants - expr.go EvalConditionExpr + HasConditionExpr + ExtractFlagsFromExpr (jsonb gate evaluator) - durations.go ApplyDuration + AddWorkingDays (pure compute) - subtrack.go SubTrackRouting + LookupSubTrackRouting registry - legal_source.go FormatLegalSourceDisplay + BuildLegalSourceURL - proceeding_mapping.go MapLitigationToFristenrechner + code constants (CodeUPCInfringement, CodeDEInfringementLG, ...) - engine.go Calculate + CalculateRule + the trigger-event branch + applyRuleOverrides (the big move) paliad side (~1900 LoC net deletion): - internal/services/fristenrechner.go shrinks from 1505 → ~290 lines (thin paliad Catalog adapter + type aliases for back-compat). - internal/models/models.go: DeadlineRule, ProceedingType, NullableJSON become type aliases to litigationplanner.* — every sqlx scan and every projection_service caller compiles unchanged. - internal/services/holidays.go: AdjustmentReason + HolidayDTO become aliases to lp.* (canonical definitions now in the package). - internal/services/proceeding_mapping.go: rewritten as thin re-exports of lp constants + helpers. - internal/services/deadline_search_service.go: FormatLegalSourceDisplay + BuildLegalSourceURL replaced with delegating wrappers to lp. Catalog interface satisfaction: - DeadlineRuleService → paliadCatalog adapter (wraps the existing service, replicates the original SELECT shapes). - HolidayService → satisfies lp.HolidayCalendar directly (compile- time assertion at end of fristenrechner.go). - CourtService → satisfies lp.CourtRegistry directly. Wire shape is byte-identical. JSON tags on Rule / ProceedingType / Timeline / TimelineEntry / RuleCalculation match the historical UIResponse / UIDeadline shape; the frontend reads the same bytes. Slice B (Catalog interface + paliad loader cleanup) is folded into this commit since Slice A already needs the interfaces to call Calculate across the boundary. Slice C (embedded UPC snapshot + generator) is the next coder shift; the Berufung unification m called out lands in Slice B/C per head's brief. Refs: docs/design-litigation-planner-2026-05-26.md	2026-05-26 13:01:07 +02:00
mAi	cc13a5b857	chore(admin): remove /admin/rules/export page + export-migrations API (t-paliad-297) ... Workflow shifted to hand-written numbered migrations; the audit-row SQL export tool no longer has any consumers. Pure deletion — /admin/rules and /admin/rules/{id}/edit stay; only the export-to-SQL flow goes. Deleted: - frontend/src/admin-rules-export.tsx - frontend/src/client/admin-rules-export.ts Removed: - routes GET /admin/rules/export and GET /admin/api/rules/export-migrations - handleAdminExportRuleMigrations + handleAdminRulesExportPage - RuleEditorService.ExportMigrationsSince + ExportResult + sqlEscape helper - build.ts entries (import, client bundle, dist HTML write) - Sidebar "Regel-Migrations" nav item + "Migrations exportieren" button on /admin/rules - all admin.rules.export.* + nav.admin.rules_export + admin.rules.list.export i18n keys (DE+EN) - .admin-rules-export-* CSS rules (dead after page deletion) Doc references in design-fristen-phase2-2026-05-15.md and design-paliad-data-export-2026-05-19.md updated to mark the endpoint as removed (acceptance #2 requires grep to return zero hits).	2026-05-26 11:50:14 +02:00
mAi	abef74fe63	Merge: t-paliad-296 — sort post-trigger optional events by duration ascending (m/paliad#128)	2026-05-26 11:22:33 +02:00
mAi	49ddaa4eb8	feat(fristenrechner): sort post-trigger events by duration ASC within parent group (t-paliad-296) ... Optional events anchored on the same trigger (e.g. the four post-Entscheidung rules in upc.inf.cfi) used to render in catalog sequence_order, so a 2-month rule (R.118.4 Folgeentscheidungen) would precede a 1-month rule (R.151 Kostenentscheidung) chained off the same decision. Now the calculator does a post-evaluation permutation pass that sorts consecutive same-parent rows by duration ascending — days < weeks < months < years, ties broken by duration_value then submission_code. Different trigger groups keep their proceeding-sequence position — the walk only ever permutes rows that already share a parent. Root rules (no parent) are never sorted against each other. Court-set / conditional rows whose date isn't in the duration ladder sort LAST within their group. Verified order against m's report: R.151 cost_app + R.353 rectification (1-month tier) now render before R.220.1 appeal_spawn + R.118.4 cons_orders (2-month tier). Issue: m/paliad#128	2026-05-26 11:21:29 +02:00