m's UX bug (2026-05-17, paliad.de prod): clicking Genehmigen/Ablehnen/
Zurückziehen on a row the viewer can't act on alerted ("Eigengenehmigung
nicht zulässig.", "Sie haben nicht die erforderliche Rolle.") after the
POST round-trip. m's ask: "approval that i cannot grant should have the
'Genehmigen' button greyed out... that would be better than showing an
error when I try."
Backend (internal/services/approval_service.go):
- ApprovalRequestView gains viewer_can_approve + viewer_is_requester
booleans. Resolved server-side per caller — false on self-authored rows
(caller == requester), true when the eligibility predicate matches.
- Extract the eligibility EXISTS-block into approvalEligibilitySQL const
and reuse it in ListPendingForApprover (WHERE), PendingCountForUser
(WHERE), and the new viewer_can_approve SELECT expression. Single
source of truth for the gate, identical to canApprove.
- ListPendingForApprover, ListSubmittedByUser, and GetRequest all bind
$1 = callerID so the SELECT computes the flags inline (one query, no
N+1). GetRequest's signature grows a callerID arg; the handler passes
the authenticated user.
Frontend (frontend/src/client/views/shape-list.ts):
- ApprovalDetail picks up the two booleans (optional — falsy is safe:
it disables, never falsely enables).
- approvalActionBtn renders the button as before but flips
btn.disabled + sets a tooltip via disabledReasonFor: approve/reject
share the viewer_can_approve gate (self → self_approval tooltip;
unauthorized → not_authorized); revoke needs viewer_is_requester.
- All three buttons still render on every pending row so users see
what's possible — the disabled+tooltip combo explains what's not.
i18n + CSS:
- 3 new keys × DE/EN: approvals.disabled.{self_approval,
not_authorized,revoke_not_requester}.
- .inbox-row-action:disabled neutralises the .btn-primary/danger/
secondary variant via opacity + not-allowed + muted tokens.
Tests:
- internal/services/approval_service_test.go::TestApprovalService_ViewerFlags
is a 4-case table-driven live-DB test (skips without TEST_DATABASE_URL):
self-authored (false/true), eligible peer (true/false), non-eligible
viewer (false/false), global_admin (true/false). Also asserts the flags
on ListPendingForApprover + ListSubmittedByUser rows.
Defence-in-depth preserved: server still rejects illegal POSTs with the
same error contract, and the alert path stays in inbox.ts for the race
where state changes between render and click.
Two issues m hit and reported in one breath while adding a project:
1. **Internal error on POST /projects** (prod-only, surfaced at 10:23). Both
ProjectService.Create and CreateCounterclaim re-referenced the uuid
parameter `$1` as `$1::text` to fill the path placeholder. Postgres'
planner deduced conflicting types for `$1` (uuid in the id column,
text in the cast) and rejected the prepared statement with 42P08
"inconsistent types deduced for parameter". The path placeholder
value is irrelevant — paliad.projects_sync_path() (BEFORE INSERT
trigger from mig 018/021) always overwrites it from id and parent
path. Fix: replace `$1::text` with a literal '' in both INSERTs,
keeping the parameter list decoupled from the id column's type.
Same comment now anchors the rationale on both call sites.
2. **CM number length — 6 digits, not 7.** m's correction; mig 018's
`^[0-9]{7}$` CHECK on paliad.projects.client_number and
matter_number was wrong. Mig 094 snapshots affected rows to
paliad.projects_pre_094, NULL-s the 3 surviving 7-digit test
values (2 client_numbers, 1 matter_number), then swaps the legacy
`projekte_*_check` constraints from {7} to {6}. Frontend pattern,
maxLength, placeholder, labels, and i18n hint flipped from 7 → 6
on both DE and EN sides; format hint reads CCCCCC.MMMMMM now.
Dry-run against live DB (BEGIN..ROLLBACK):
- Fixed Create SQL: trigger populates path = id::text (36 chars). ✓
- Mig 094: 2 rows snapshotted, 0 clients/matters remain after clear,
0 rows violate the new 6-digit CHECK. ✓
go build, go test ./internal/..., bun run build all clean.
Lorenz's Slice 9 (t-paliad-195) deferred mig 093 because 40 active
paliad.deadline_rules still pointed at the 7 litigation-category
proceeding_types (INF, REV, CCR, APM, APP, AMD, ZPO_CIVIL). Phase 3
Slice 5 (mig 087/088) already retired the category from project-binding;
this migration retires it from the rule corpus.
PLAN CHOICE (audit-gated, paliadin-approved): archive-all-40 rather than
the original re-parent plan. The audit found that 23 of 40 Pipeline-A
rules share their `code` with an existing fristenrechner rule on the
proposed re-parent target (e.g. inf.oral exists on both INF and
UPC_INF). Re-parenting would leave two rules with identical
(proceeding_type_id, code), breaking the implicit per-proceeding
rule_code identity contract keyed off by projection / search /
rule_editor. The fristenrechner rules are clearly the production
version (proper German names, legal_source pinned to UPC.RoP citations,
full bilateral chains, intra-proceeding counterclaim handling); the
Pipeline-A rules are stubs (English-only, mostly NULL legal_source,
duration_value=0 for 28 of 40, no spawn_proceeding_type_id wiring).
Migration 093 sequence (atomic):
1. Snapshot proceeding_types_pre_093 + deadline_rules_pre_093 as
permanent audit anchors.
2. INSERT _archived_litigation pt (category='archived',
is_active=false, jurisdiction='UPC') to home the rules.
3. UPDATE all 40 rules → archive pt + lifecycle_state='archived' +
is_active=false. Captured in paliad.deadline_rule_audit via the
mig 079 trigger.
4. DELETE the 7 litigation rows from paliad.proceeding_types (now
safe — nothing references them).
5. Hard assertions: 0 litigation rows survive, exactly 40 rules on
the archive pt, every snapshot row matches a surviving rule by id.
Critical FK note: deadline_rules.proceeding_type_id is ON DELETE CASCADE
→ proceeding_types(id). A naive DELETE of the 7 litigation rows would
cascade-delete all 40 rules and break the FK from the 1 live deadline
("Lecker Frist", completed) that still references inf.rejoin/INF.
Re-homing the rules before deleting the pt rows is mandatory.
Verified via BEGIN..ROLLBACK against live DB: assertions pass, all 30
intra-litigation parent_id chains preserved, the live deadline FK
stays valid.
Test impact:
internal/services/project_service_test.go:72 used to look up
category='litigation' AND code='INF' to exercise the Slice 5 negative
case. Post-mig-093 that lookup returns NULL. Rewritten to fetch any
category <> 'fristenrechner' row (the _archived_litigation pt is the
canonical post-093 row); defence-in-depth coverage of both the Go
service guard and the mig 088 SQL trigger is preserved.
SURFACED FOR LEGAL REVIEW (4 coverage questions the audit found, to be
triaged as follow-up tasks):
1. inf.prelim (Preliminary Objection, RoP 19, 1 month) — not present
on UPC_INF. Possible coverage gap; legal review to decide whether
to add it to the fristenrechner ruleset.
2. inf.appeal / rev.appeal / ccr.appeal as cross-proceeding spawns
into UPC_APP (2 months, UPC.RoP.220.1) — fristenrechner UPC_APP
currently starts standalone with no spawn from UPC_INF/UPC_REV.
Possible UX gap; Pipeline-A versions had
spawn_proceeding_type_id=NULL so they weren't functional spawns
either.
3. ccr.amend / rev.amend (spawn rules) — superseded by
inf.app_to_amend / rev.app_to_amend on UPC_INF / UPC_REV. Safe to
drop; no action needed.
4. zpo.klage / zpo.vertanz / zpo.klageerw / zpo.berufung — no UPC
analogue; redundant with the DE_INF / DE_INF_OLG / DE_INF_BGH and
DE_NULL / DE_NULL_BGH chains. Safe to drop; no action needed.
Files:
internal/db/migrations/093_retire_litigation_category.up.sql (new)
internal/db/migrations/093_retire_litigation_category.down.sql (new)
internal/services/project_service_test.go (test rewrite)
EventDeadlineService.Calculate now reads source rows from
paliad.deadline_rules directly (WHERE trigger_event_id IS NOT NULL),
joining via UUID instead of title_de string. The legacy SELECTs against
paliad.event_deadlines + paliad.event_deadline_rule_codes are gone.
Migration 092:
- Snapshots both legacy tables into _pre_092 audit anchors.
- Adds paliad.deadline_rules.rule_codes text[] and backfills the 72
multi-code citations from event_deadline_rule_codes via the
sequence_order = 1000 + ed.id convention from mig 085 (70 of 77
Pipeline-C deadlines carry codes; 7 are codeless).
- Hard assertion ties source-junction-row count to backfilled
text[]-element count — any sequence_order mismatch aborts the drop.
- Drops the mig 086 read-only trigger (orphan once event_deadlines
goes away).
- Drops paliad.event_deadlines + paliad.event_deadline_rule_codes.
- Final assertion: >=77 active deadline_rules with trigger_event_id
NOT NULL — Slice 3 corpus must not have collapsed.
- audit_reason wrapper at top so the deadline_rules UPDATE row-trigger
records the reason in deadline_rule_audit.
Verified via BEGIN..ROLLBACK against the live paliad DB: 72 codes
backfilled into 70 rule_codes arrays, multi-code rules (RoP.029.a +
RoP.030 for ed_id=6) preserve their ordering, composite rules
(combine_op=max) remain intact, both tables drop cleanly, all
assertions pass.
Parity test rebound to deadline_rules — independent computation still
re-runs applyDuration against raw column values for date/composite
parity. EventDeadlineResult.ID stays int64 via the sequence_order -
1000 convention so the public /api/tools/event-deadlines wire shape
is unchanged.
Closes the Determinator cascade redesign. Three intertwined pieces:
1. The mode row is gone — the `🔍 Direkt suchen` icon at the top of the
row stack now toggles an inline search overlay over the cascade
instead of routing to the legacy B2 surface. Results render into the
same `#fristen-b1-results` container the cascade uses, so users see
one consistent concept-card layout regardless of whether they
reached the rule via cascade narrowing or free-text search. ESC
inside the input clears it on the first press and collapses on the
second; "← Zurück zum Entscheidungsbaum" restores cascade + state.
Deep-link `?mode=filter` still routes to the legacy B2 panel for
backwards-compatible shared URLs but is no longer exposed in the
cascade UI.
2. Mobile responsive per design §7. Three breakpoints layer onto the
`.fristen-row` primitive: <640px (phone — chips full-width single
column, ändern permanently visible, answer wraps to its own line),
<768px (tablet — head wraps so ändern moves down, chips
single-column), <1024px (small desktop / large tablet — chips drop
to 2-column auto-fill). Active row autoscrolls into view on every
render with 60px headroom; the helper is a no-op when the row is
already visible so desktop doesn't jitter.
3. Auto-walk tooltip polish: 200ms fade-in + slide-down via an
is-entering transition state; mobile (<640px) flips the insertion
point so the tip lands below the prefilled row rather than above;
any chip pick or ändern click counts as user-engagement and
dismisses the tip (in addition to the explicit × button).
Refs: docs/design-determinator-row-cascade-2026-05-13.md §6 + §7 + §10 Slice 3.
Wires the project context into the Determinator row stack so a UPC INF
matter doesn't need to be hand-walked through five obvious cascade picks.
Auto-walk descends single-option chains as `is-prefilled` rows, the inbox
row vanishes for UPC matters (CMS implied), and the first prefilled row
carries the project reference inline ("aus Akte: HL-2024-001").
Backend: `internal/services/proceeding_mapping.go` adds
MapLitigationToFristenrechner — single source of truth for bridging the
litigation conceptual codes (INF / REV / APP / CCR / AMD / APM / OPP) onto
fristenrechner codes (UPC_INF / DE_INF / EPA_OPP / …). Ambiguous combos
(APP+DE, ZPO_CIVIL, AMD+DE) return ok=false; callers degrade to "no
narrowing" instead of guessing. Table-driven test covers every documented
mapping plus the ambiguous-degrade cases.
Frontend: `buildRowStack` filters cascade children by project context
along the proceeding axis (kebab segment lookup against the project's
fristenrechner code); auto-walks while filtered scope narrows to one;
caps depth via `cascadeAutoWalkStopAfter` after an "ändern" on a prefilled
row so the user lands at an active chip set without the auto-walk
re-engaging. Result panel narrows on the post-auto-walk effective slug,
not the URL slug. A one-time inline tooltip ("Diese Schritte ergeben sich
aus Ihrer Akte") surfaces when ≥2 rows render prefilled — dismissal flag
persists in localStorage.
Narrowing is purely additive: an Akte without a fristenrechner code
(11/11 live projects pre-Slice-5 were NULL) degrades to today's
forum-only behaviour. Slice 3 (mobile polish + search relocation) follows.
Refs: docs/design-determinator-row-cascade-2026-05-13.md §10 Slice 2 + §4 + §5.
Replace the four-layer Pathway B mess (mode radio + perspective chip strip
+ inbox chip strip + breadcrumb cascade) with a single `.fristen-row`
primitive rendered in a top-down stack. Every decision — mode, perspective,
inbox, cascade depth N — now uses the same shape (label · picked answer ·
inline "ändern") and three states (is-active / is-answered / is-prefilled).
The user finally sees their full decision path at a glance instead of
chasing breadcrumb crumbs after each drill. Click on any answered row (or
its ändern affordance) re-actives it; ändern on a cascade depth drops the
descendants (same drop-descendants semantic as today's breadcrumb-click).
Reset link and `🔍 Direkt suchen` escape-hatch live at the top of the stack
per design §6 Option B; the mode-toggle radio is gone, routing to
?mode=filter now flows through the mode row.
Visual-only refactor — narrowing engine (inboxFilterAllowsForums +
perspectiveAllowsParty) is unchanged. Slice 2 will add project-driven
prefills + auto-walk; Slice 3 covers mobile polish and search relocation.
Refs: docs/design-determinator-row-cascade-2026-05-13.md §10 Slice 1.
Phase 3 Slice 9 frontend cleanup. The backend's UIDeadline wire
shape stopped emitting (isMandatory, isOptional) in this slice;
the matching legacy-fallback branch in priorityRendering is now
dead code. Drops:
- CalculatedDeadline TS interface: isMandatory + isOptional
fields removed. `priority` is required (not optional) since
every backend response now populates it.
- priorityRendering(): collapsed to a clean switch on `priority`.
Unknown priority falls back to "render as mandatory" (safe
default; never silently drop a rule) — the legacy
(isMandatory, isOptional) inference is gone.
- Save-modal optional-badge rendering in fristenrechner.ts now
reads `dl.priority === "optional"` directly (was previously
`dl.priority === "optional" || dl.isOptional`).
- Timeline row's optional-badge rendering in
verfahrensablauf-core.ts switched from `!dl.isMandatory` to
`dl.priority === "optional"`. Slightly different semantic —
pre-Slice-9 the badge fired on every non-mandatory row
(recommended + optional + informational); post-Slice-9 only
on opt-in rules (RoP.151 pattern). Recommended + informational
are surfaced via their own rendering tier (notice card for
informational) so the badge change tightens the meaning.
Frontend build clean; no i18n keys removed (the priority labels
shipped in Slice 8 stay live).
Phase 3 Slice 9 test cleanup. Seeds + assertions no longer touch
the legacy columns (mig 091 dropped them).
- projection_service_test.go (Slice 7 fixtures): INSERT seeds
drop the is_mandatory / is_optional columns from the
paliad.deadline_rules column list. Defaults are fine; the
spawn-graph test doesn't read those.
- rule_editor_service_test.go (Slice 11a fixtures): same drop
on the SLICE11A_PREVIEW seed.
- fristenrechner_test.go (Slice 8 wire-shape assertion): drops
the wireFlagsFromPriority round-trip check (the bool pair is
no longer on the wire). The enum-membership invariant
survives. evalConditionExpr table-driven test rewritten —
legacy condition_flag fallback cases removed (the fallback
is gone in Slice 9), pure-jsonb cases retained.
- deadline_rule_service_test.go (Slice 2 backfill integrity):
legacy-pair bucket assertion dropped; the priority-non-NULL
invariant still holds via the CHECK constraint. The
condition_flag cross-check now joins the pre-mig-091 snapshot
when present (a future cleanup slice drops the snapshot
along with this code path).
Build + tests green.
Phase 3 Slice 9 Go cleanup. With mig 091's column drops live, the
service layer stops reading + emitting the legacy shape:
- models.DeadlineRule: drop IsMandatory, IsOptional, ConditionFlag,
ConditionRuleID fields. Comment block flags Slice 9 as the
closeout slice.
- DeadlineRuleService.ruleColumns: SELECT no longer enumerates the
dropped columns. The post-Slice-9 schema is the live shape.
- FristenrechnerService.UIDeadline: drops IsMandatory + IsOptional
fields. Frontend reads `priority` directly post-Slice-8; the
legacy emit was kept "for one release" and that release is now.
- evalConditionExpr signature: drops the conditionFlag fallback
param. NULL / "null" expressions return true (unconditional);
the legacy text[] fallback was the only reason for the second
param. New helpers hasConditionExpr + extractFlagsFromExpr fill
the gaps (alt-swap guard + RuleCalculation.FlagsRequired list).
- FristenrechnerService.Calculate + calculateByTriggerEvent +
EventTriggerService.Trigger: switched to the new (single-arg)
evalConditionExpr; alt-swap guard now uses
hasConditionExpr(r.ConditionExpr) instead of the dropped
len(r.ConditionFlag) > 0 check.
- FristenrechnerService.CalculateRule: RuleCalculationRule.IsMandatory
derived from priority via wireFlagsFromPriority (kept for the
result-card panel TS contract). FlagsRequired walks the jsonb
gate tree to enumerate {"flag":"X"} leaves (replaces the
dropped condition_flag enumeration).
- RuleEditorService.Create + CloneAsDraft INSERT statements:
dropped is_mandatory / is_optional / condition_flag from the
column lists. Live shape only.
Test fixtures (projection_service_test.go, rule_editor_service_test.go,
fristenrechner_test.go) all updated to write the live shape on
seed; the evalConditionExpr table-driven test dropped its legacy
fallback cases (the fallback no longer exists) and now exercises
20 pure-jsonb scenarios across AND/OR/NOT compositions.
The deadline_rule_service_test backfill assertion lost its
(is_mandatory, is_optional) bucket cross-check (those columns are
gone); the priority-non-NULL invariant still holds via the CHECK
constraint. condition_flag cross-check now joins the pre-mig-091
snapshot table (when present) instead of the live row.
Phase 3 Slice 9 Step E (design §3.E, §9.1). m approved the
downtime window 2026-05-15 ("paliad ist nicht in use heute,
downtime ist egal") so the destructive drops can land.
Drops four superseded columns on paliad.deadline_rules:
is_mandatory → priority='mandatory' | other (Slice 2 mig 083)
is_optional → priority='optional' (Slice 2 mig 083)
condition_flag → condition_expr (Slice 2 mig 084)
condition_rule_id → DEAD (no live rows, Q13 m's approved drop)
Pre-drop snapshot: paliad.deadline_rules_pre_091 (id +
the four columns + snapshotted_at). Lets the down-migration
restore values to existing rows; a follow-up cleanup slice drops
the snapshot table once the rule editor's migration-export flow
has been used to roll any post-drop edits back into version
control.
Hard assertions at end:
- count(priority IS NULL) == 0 (Slice 2 mig 083 must have run).
- count(rule with pre-drop condition_flag but no condition_expr)
== 0 (Slice 2 mig 084 must have populated every row).
Both raise EXCEPTION on violation — fails the migration loudly
before legacy code paths get pulled out from under the unified
calculator.
Audit-reason wrapper set; ALTER TABLE DROP COLUMN doesn't fire
the mig 079 row-level trigger, but the wrapper is the standard
Phase 3 pattern.
Sibling drops deferred — see live-data audit in head ping:
- mig 092 (event_deadlines + trigger_events tables): SKIPPED.
trigger_events has 33 event_types FKs + 77 deadline_rules
FKs; event_deadlines + event_deadline_rule_codes still
consumed by EventDeadlineService.Calculate for the frontend's
"Was kommt nach…" tab (/api/tools/event-deadlines is still
in use post-Slice-3 delegate).
- mig 093 (retire litigation category): SKIPPED. 40 active
deadline_rules still reference litigation-category
proceeding_types (the Pipeline-A INF/REV/CCR/APM/APP/AMD/
ZPO_CIVIL rules; Slice 5 retired them from project-binding,
not from the rule corpus).
Both deferrals are tracked in the head ping; the litigation drop
can land after a focused slice that splits the Pipeline-A rules
off the litigation category onto a fristenrechner-side parent.
The event_deadlines drop needs EventDeadlineService.Calculate
to stop reading the source rows first.
The Dokploy compose .env file got the new vars during the operational
flip but the docker-compose.yml environment block didn't list them, so
docker-compose silently dropped them during container start.
Adds PALIADIN_BACKEND / AICHAT_URL / AICHAT_TOKEN / AICHAT_PERSONA to
the environment block with safe defaults (PALIADIN_BACKEND=legacy,
AICHAT_PERSONA=paliadin). Existing deployments without aichat envs set
keep the legacy path; flipping PALIADIN_BACKEND=aichat in Dokploy now
takes effect on next deploy.
Discovered while doing the aichat Phase B activation flip.
Per m's 2026-05-13 decision (m/mAi#207 §13 Q4): the paliadin SKILL.md
and references/sql-recipes.md are now owned by aichat. The aichat repo
already has the equivalents committed at skills/aichat/paliadin/ on
mai/darwin/issue-207-aichat (verified before this commit). Aichat's
own deploy doc handles installation on mRiver.
Deleted:
scripts/skills/paliadin/SKILL.md
scripts/skills/paliadin/references/sql-recipes.md
scripts/install-paliadin-skill
Legacy LocalPaliadinService / RemotePaliadinService still depend on
~/.claude/skills/paliadin/ being present on whichever host they run
against. Until those paths retire (Phase C / Q15), operators install
the skill manually from m/mAi/skills/aichat/paliadin/.
CLAUDE.md updated:
- PALIADIN_SESSION_PREFIX row points readers at m/mAi for the skill
SoT and notes the legacy paths still expect a manual install.
- New env-var rows for PALIADIN_BACKEND / AICHAT_URL / AICHAT_TOKEN /
AICHAT_PERSONA so the operator runbook for the Phase B flip is
self-contained.
Adds the Phase B paliad-side migration: a thin HTTP client of the
centralized aichat backend shipped in m/mAi#207 Phase A (darwin's
mai/darwin/issue-207-aichat branch). Implements the same services.Paliadin
interface as LocalPaliadinService / RemotePaliadinService — handler
plumbing is unchanged, the cutover is a single env-var flip.
internal/services/aichat_paliadin.go (~530 LoC):
- POST /chat/turn + POST /chat/reset + GET /chat/health via the aichat
JSON envelope (mirrors m/mAi internal/aichat/api/types.go verbatim;
no module import to keep paliad self-contained).
- Per-turn HS256 JWT mint (uses paliadin_jwt.go from the prior commit)
when SUPABASE_JWT_SECRET is configured. Aichat owns file write +
cleanup; we just sign and ship.
- Service-wide health-gate cache (10 s success window, no failure
cache — failures re-probe so recovery surfaces immediately).
- Per-user-window primer cache. Pulls up to MaxPrimerTurns prior
exchanges from paliad.paliadin_turns and ships them in TurnRequest.
Primer so a pane respawn (pane_spawned=true in response) doesn't
strand the user with a cold claude. Cleared on ResetSession +
pane_spawned response.
- Username from email_localpart per m's §13 Q2 pick (sanitized inside
aichat). Nil-DB fallback: "user-<uuid8>".
- Maps aichat's typed wire errors (auth_failed, persona_unknown,
mriver_unreachable, bootstrap_failed, timeout, shim_error) onto
paliad's existing audit-row codes — preserves the German i18n table
in paliadin.ts unchanged (no new strings needed per design §11).
cmd/server/main.go:
- PALIADIN_BACKEND env: "aichat" → AichatPaliadinService, anything
else → existing remote/local/disabled tree. Default = legacy, so
every existing deploy is byte-identical until flipped.
- buildAichatPaliadinConfig validates AICHAT_URL + AICHAT_TOKEN at
boot; AICHAT_PERSONA defaults to "paliadin". JWT secret threaded
in so per-user RLS is on by default.
Tests cover constructor defaults, health-gate caching + retry +
expiry, ResetSession wiring, error-envelope decoding + classifier,
HTTP-layer auth/JSON wiring via a roundTripper, JWT mint integration,
TurnContext → meta packing, and the env-gate helper. go test ./...
green. NOT self-merged — head owns the merge per task instructions.
Restored from mai/planck/paliadin-per-user-rls (parked, see m/paliad#12
cancel note). The aichat Phase B path (next commit) consumes mintTurnJWT
to sign a short-lived HS256 token per turn, scoped to the calling user
(sub=userID, role=authenticated, aud=authenticated, iss=paliad/paliadin).
Aichat passes the raw token through to the claude pane on mRiver via a
per-turn file (managed by aichat's runner, not paliad's transport). The
SKILL.md reads it and `SET LOCAL request.jwt.claims = …` before every
paliad.* query, which makes RLS evaluate as the user instead of as
service role.
TTL: 2 min default — covers aichat's 120 s persona timeout + HTTP slack,
short enough that a leaked JWT is uninteresting. Each turn mints fresh;
no caching.
No call sites yet — paliadin_remote.go / paliadin.go are unchanged on
this commit. The plumbing arrives with AichatPaliadinService.
Surfaces the Slice 11a admin API at /admin/rules so editors can drive
the rule lifecycle without curling. Three new pages, each gated by
adminGate on the route + sidebar reveal via /api/me:
/admin/rules — list page with filters (proceeding,
trigger event, lifecycle chips, fuzzy
search) and a second "Orphans" tab that
loads paliad.deadline_rule_backfill_orphans
via the new GET /admin/api/orphans
endpoint. Pick-chip on each candidate
fires the reason modal → POST resolve.
"+ Neue Regel" opens the same reason modal
with minimal required fields (name DE/EN
+ duration) and routes to the edit page
on success.
/admin/rules/{id}/edit — full form (37 columns grouped: identity /
proceeding / timing / party / display /
lifecycle / condition). Side panel hosts
the preview widget (trigger date + flags
→ GET .../preview, drafts only) and the
audit-log timeline (paginated, 20 per
page). Bottom action bar adapts to
lifecycle_state — save-draft + publish on
drafts, clone on published/archived,
archive on draft/published, restore on
archived. Every action opens the reason
modal with ≥10-char client-side guard per
Slice 11a edge case #4.
/admin/rules/export — minimal SQL preview + "Download as file"
/ "Copy to clipboard". Optional `since`
audit-id scopes the export window.
condition_expr ships with a raw JSON textarea + inline parse
validation; the tree-builder is out of scope for Slice 11b (raw JSON
is sufficient given the existing 172-row corpus and validates the
same grammar live). The dependency on document.querySelectorAll for
form binding follows the admin-event-types / admin-audit-log
playbook — no new component substrate needed.
Wiring:
- frontend/build.ts: 3 new entrypoints + 3 new HTML writes.
- frontend/src/admin.tsx: new "Regeln verwalten" card with ICON_TABLE.
- frontend/src/components/Sidebar.tsx: two new admin nav entries
(Regeln + Regel-Migrations).
- frontend/src/client/i18n.ts: 162 new keys (DE+EN), under
admin.rules.* and admin.rules.edit.* and admin.rules.export.*.
- frontend/src/styles/global.css: new admin-rules-* CSS block
appended (chips, pills, audit timeline, edit-grid, preview list,
orphan cards, export pre). Uses paliad's existing CSS tokens so
light/dark/auto themes inherit automatically.
Route registration:
- GET /admin/rules — list page shell
- GET /admin/rules/{id}/edit — edit page shell
- GET /admin/rules/export — export page shell
All routes adminGate + gateOnboarded, so non-admin users 404 before
the shell even loads. Backend audit and lifecycle invariants from
Slice 11a stay authoritative; the frontend never bypasses them.
Slice 11b backend addition for the orphan-resolution flow in the
/admin/rules UI. The Slice 10 fuzzy-match backfill (mig 089) staged
legacy paliad.deadlines rows the matcher could not bind to a unique
deadline_rule into paliad.deadline_rule_backfill_orphans. This adds
the two endpoints the editor needs to surface and resolve them:
GET /admin/api/orphans — unresolved staging rows,
hydrated with the candidate
rule rows in one round-trip.
POST /admin/api/orphans/{id}/resolve — picks a rule_id from the
candidate set, writes it onto
the deadline, and flips
resolved_at + resolved_rule_id
on the staging row in a single
tx.
The methods live on RuleEditorService because they share the same admin
surface and audit semantics; resolved_rule_id + resolved_at on the
staging row is the audit trail (mig 089 COMMENT). reason is captured
into paliad.audit_reason in the same tx so any future audit trigger on
paliad.deadlines picks it up automatically.
Typed errors:
ErrOrphanAlreadyResolved → 409 in handler
ErrOrphanCandidateMismatch → 400 in handler
Route ordering matches Slice 11a's pattern: the static path is
registered alongside the existing /admin/api/rules family inside the
adminGate block in handlers.go.
Live-DB tests (TEST_DATABASE_URL-gated) for Phase 3 Slice 11a:
TestRuleEditorService_Lifecycle — full create→update→publish→archive
→restore round-trip on synthetic fixtures (SLICE11A_TEST_PT
proceeding + rules). Asserts:
1. Create returns lifecycle_state='draft' with published_at=NULL.
2. UpdateDraft on a draft succeeds and lands the patch.
3. CloneAsDraft from a published row creates a new draft with
draft_of pointing at the source.
4. Publish flips draft → published, sets published_at, AND archives
the cloned-from peer (verified by re-reading the peer's
lifecycle_state post-publish).
5. Archive flips published → archived.
6. Restore flips archived → published.
7. ListAudit returns ≥ 3 rows newest-first with non-empty reason
strings (the mig 079 trigger captured them).
8. Empty audit_reason on UpdateDraft → ErrAuditReasonRequired.
9. UpdateDraft on a published row → ErrInvalidLifecycleState.
10. Restore on a non-archived row → ErrInvalidLifecycleState.
TestRuleEditorService_Preview — calculator override hook coverage
(SLICE11A_PREVIEW_PT proceeding + a published rule). Clone the
root rule, patch DurationValue 30 → 60 on the draft, call Preview
at trigger_date=2026-01-15. Asserts:
- Baseline Calculate (no overrides) returns the published rule's
dueDate (~30 days after trigger).
- Preview returns a DIFFERENT dueDate (substitutes the draft's
60-day duration via RuleOverrides) — sanity check that the
override pipeline reached the calculator and shifted the date.
- Both responses are non-empty (the rule is reachable).
Cleanup: WHERE name LIKE 'SLICE11A_TEST_%' / 'SLICE11A_PREVIEW_%'
AND code = 'SLICE11A_TEST_PT' / 'SLICE11A_PREVIEW_PT' so production
rules are untouched. audit_reason set on every seed / cleanup write
so the mig 079 trigger doesn't reject the seed transactions.
Build clean, full local test suite green; this test skips when
TEST_DATABASE_URL is unset.
Phase 3 Slice 11a admin endpoints under /admin/api/rules, all
gated through auth.RequireAdminFunc:
GET /admin/api/rules — paginated list with filters
GET /admin/api/rules/{id} — full row
POST /admin/api/rules — create draft
PATCH /admin/api/rules/{id} — update draft only
POST /admin/api/rules/{id}/clone-as-draft
POST /admin/api/rules/{id}/publish
POST /admin/api/rules/{id}/archive
POST /admin/api/rules/{id}/restore
GET /admin/api/rules/{id}/audit — paginated audit log
GET /admin/api/rules/{id}/preview — preview-on-trigger-date
GET /admin/api/rules/export-migrations — SQL blob for the
migration-export flow
Every write endpoint takes a `reason` body field; missing reason →
HTTP 400 (ErrAuditReasonRequired surfaced by the service). The
service writes the reason into paliad.audit_reason in the same tx
as the UPDATE so mig 079's trigger captures it.
writeRuleEditorError maps service-level typed errors to HTTP
statuses (404 for ErrRuleNotFound, 409 for ErrInvalidLifecycleState
+ ErrCyclicSpawn, 400 for ErrAuditReasonRequired + ErrInvalidInput).
dbServices gains a ruleEditor field; Services.RuleEditor in the
public bundle gets wired from main.go via NewRuleEditorService.
Route ordering: export-migrations is registered BEFORE the
{id}-shaped routes so the static path doesn't get captured by the
{id} placeholder. (Go 1.22+'s ServeMux requires the explicit
registration order for shadowing-resolution.)
Frontend (Slice 11b) will hire a new coder to surface the API in
an admin UI. Slice 11a ships the backend in isolation so the editor
can drive the lifecycle via curl / mai instructions today.
Phase 3 Slice 11a (m's Q5 option C: "I need to see these things,
admin only"). RuleEditorService owns the admin-only lifecycle for
paliad.deadline_rules:
Create → INSERT row with lifecycle_state='draft', published_at=NULL.
UpdateDraft → UPDATE WHERE id=$1 AND lifecycle_state='draft'.
Published or archived rows must clone-as-draft first
(ErrInvalidLifecycleState otherwise — 409).
CloneAsDraft → INSERT deep copy of source row (published OR archived)
as a new draft with draft_of pointing at the source.
Lets editors propose changes to live rules without
mutating the live row.
Publish → UPDATE lifecycle_state='published', set published_at.
When draft_of != NULL, also archives the cloned-from
peer so each rule has at most one live row.
Archive → UPDATE lifecycle_state='archived' (allowed from
published OR draft).
Restore → UPDATE lifecycle_state='published' (only from archived).
Preview → Calls FristenrechnerService.Calculate with the draft
as a RuleOverrides entry — pure simulation, no DB
write. If draft_of is set, the override substitutes
for the peer (matching ID); otherwise it's appended.
ListAudit → SELECT paliad.deadline_rule_audit rows for one rule,
newest-first, with offset/limit pagination. Joined
with paliad.users.display_name for the changed_by
column.
ListRules → Admin list view with filters (proceeding_type_id,
trigger_event_id, lifecycle_state, fuzzy q over
name / name_en / rule_code).
ExportMigrationsSince → SQL blob generator for the migration-export
admin flow (Q-H-5 pure SQL format). v1 emits one
statement per audit row in chronological order;
Slice 11b polishes the output (header comment,
collapse consecutive UPDATEs).
Audit-reason invariant: every write method requires a non-empty
reason string. setAuditReasonTx writes it into the session-local
paliad.audit_reason setting in the same transaction as the
INSERT/UPDATE, so mig 079's trigger captures the rationale
forever. Empty reason → ErrAuditReasonRequired (400 in the handler).
Spawn cycle guard: validateSpawnNoCycle pre-checks Create + UpdateDraft
edits that touch spawn_proceeding_type_id against the global rule
graph. Reuses the design §6 cycle-guard semantics — walks the
target proceeding's spawn rules transitively; raises ErrCyclicSpawn
if any reachable proceeding is the source. Slice 7's runtime guard
catches anything this misses; the editor surface catches it at
edit time so the editor sees a clear 409 instead of a silent
projection failure.
Typed errors:
ErrRuleNotFound → 404 in handler
ErrInvalidLifecycleState → 409 in handler
ErrAuditReasonRequired → 400 in handler
ErrInvalidInput → 400 (re-uses the existing services-wide error)
ErrCyclicSpawn → 409 (re-uses Slice 7's typed error)
RuleAuditEntry struct extends models.DeadlineRuleAudit with a
display_name for the admin UI; distinct from services.AuditEntry
(the cross-source union for the site-wide audit panel) so the two
read paths don't conflict.
Phase 3 Slice 11a calculator hook for the rule-editor preview
(design §4.5, Q-H-4 option (a)). CalcOptions gains RuleOverrides
[]models.DeadlineRule. When non-empty, FristenrechnerService.Calculate
substitutes any rule with matching .ID in the rule list with the
override row, and appends overrides whose ID doesn't match an
existing rule (net-new drafts the editor wants to preview).
Wired into:
- FristenrechnerService.Calculate (proceeding-tree path)
- FristenrechnerService.calculateByTriggerEvent (Pipeline-C path)
Helper: applyRuleOverrides(src, overrides) — small linear scan since
the override slice is 1 row in practice (the draft being previewed).
Empty overrides → pass-through (existing behaviour unchanged).
No DB writes; pure simulation. The editor's "what would this rule
do?" affordance uses this to preview the draft against the rest of
the proceeding's rules without mutating the live corpus.
Phase 3 Slice 10 Step I (design §3.I + m's Q10 ruling). Binds legacy
paliad.deadlines.rule_id to deadline_rules.id via priority-ordered
fuzzy matching; ambiguous + no-match rows log to the orphan staging
table (mig 089).
Matching strategies (highest priority first; first unique hit wins):
1. rule_code_and_tail — title's leading citation token AND its
post-separator name fragment match a rule. Handles
"RoP.023 — Klageerwiderung" where the bare code matches 2 rules
(DE Klageerwiderung + EN Statement of Defence); the tail picks
the right one.
2. rule_code only — bare rule_code from the title prefix. Handles
"RoP.029.a — Replik" where RoP.029.a maps to a single rule
regardless of suffix (the title's "Replik" doesn't match the
rule's actual name but the code is unique).
3. name_exact — full title equals rule.name or rule.name_en
(LOWER). Catches "Antrag auf Schadensbemessung" (1 unique
rule); ambiguous for shared names like Klageerwiderung (8
candidates).
4. concept_alias — title appears in deadline_concepts.aliases.
Thin coverage today; Slice 12 orphan-seed will populate it.
Per-deadline aggregation:
- Strategy with n_candidates = 1 wins. Priority chain rule_code_and_tail
> rule_code > name_exact > concept_alias.
- Ambiguous (≥2 across all strategies) → orphan reason='ambiguous'
with the full candidate_rule_ids list.
- 0 candidates → orphan reason='no_match'.
Predicted production outcome (verified via supabase MCP pre-write):
- 3 of 25 deadlines (12%) get a unique match:
"RoP.023 — Klageerwiderung" via rule_code_and_tail
"RoP.029.a — Replik" via rule_code
"Antrag auf Schadensbemessung" via name_exact
- 15 of 25 deadlines (60%) → orphan reason='ambiguous' (common
titles like Klageerwiderung × 4, Duplik × 4, Replik × 4 across
multiple proceedings).
- 7 of 25 deadlines (28%) → orphan reason='no_match' (free-text
titles like "Call me", "Schutzschrift", "Validierungsfrist EP→DE",
"Schriftsatz nach R.262 (Klageerwiderung)").
The 60% target the design § hinted at is unachievable on today's
corpus because all 11 projects have proceeding_type_id IS NULL post-
Slice-5 (the fristenrechner-side rebinding hasn't happened on
production data yet) — proceeding-narrowing would cut the
Klageerwiderung / Duplik / Replik ambiguity, but the column isn't
populated. The orphan-review UI in Slice 11 is the real path to
binding the long tail.
Defensive backup: paliad.deadlines_pre_089 snapshot taken before any
UPDATE. Down-migration restores rule_id from the snapshot + drops
unresolved orphan rows (resolved rows survive a rollback — those are
legal-review work that shouldn't disappear on a code revert).
Idempotency: WHERE rule_id IS NULL on the UPDATE; orphan INSERT
skips rows that already have an unresolved orphan entry. Re-running
on the same corpus produces no new rows.
Hard assertion: every NULL-rule_id deadline (with project) is either
resolved post-mig OR has an unresolved orphan row. RAISE EXCEPTION on
any unaccounted row — fails the migration loudly rather than
silently leaving a deadline un-matched + un-orphaned.
Audit-reason wrapper set; the mig 079 deadline_rules audit trigger
doesn't fire here (UPDATEs touch paliad.deadlines, not deadline_rules),
but the wrapper is the standard pattern.
Phase 3 Slice 10 staging table for the fuzzy-match orphans mig 090
produces (design §3.I + m's Q10 ruling). Each legacy deadline that
the matcher can't uniquely bind to a deadline_rule logs here with
the full candidate list so a legal-review pass can hand-link the
ambiguous tail without rerunning the match.
Schema:
- deadline_id FK to paliad.deadlines (ON DELETE CASCADE).
- title + project_id + proceeding_code denormalised so the admin
orphan-review UI groups + filters without re-joining.
- reason text CHECK in ('no_match', 'ambiguous', 'no_project',
'manual_unbound'). Mig 090 writes the first two; the editor
surface (Slice 11) may add the others.
- candidate_count + candidate_rule_ids carry the full list of
plausible rules so the legal-review UI can render "pick one"
chips from the matcher's actual output.
- resolved_at + resolved_rule_id flip when an editor binds the
row via the admin UI; the matching paliad.deadlines.rule_id
UPDATE happens at the same time. Both rows hold so the staging
table doubles as an audit trail of the legal-review pass.
Indexes:
- deadline_id for the per-deadline lookup the admin UI uses.
- unresolved_at DESC for the "open orphans" list (the only one
the legal-review UI typically lists).
RLS: admin-only read. The orphan list contains real deadline titles
+ project ids, so non-admins must not see it. Service-layer surfaces
(Slice 11) gate further.
Mig 089 ships the table; mig 090 does the fuzzy-match backfill +
populates this table. Numbering reflects the dependency order (the
backfill SELECTs INTO this table, so the table must exist first).
Phase 3 Slice 8 frontend wire-shape swap. Save-modal pre-check logic
moves from the legacy (isMandatory, isOptional) pair to the unified
priority enum via a new priorityRendering helper in
verfahrensablauf-core.ts:
- mandatory → pre-checked, save button visible
- recommended → pre-checked, save button visible
- optional → pre-unchecked, save button visible (RoP.151 pattern)
- informational → NO save button — renders as a notice card with a
"Hinweis" / "Note" label, distinct visual tier (no checkbox).
The visible UX win of Phase 3: the 18 F/F filing rules
(Berufungserwiderung, Replik, Duplik, R.19, R.116 EPÜ, etc.)
currently render as 'recommended'; once editorial review flips
them to 'informational' via the rule editor (Slice 11), this
branch lights up and they stop offering a save action that
would auto-create deadlines users didn't ask for.
priorityRendering falls back to the legacy (isMandatory, isOptional)
pair semantic when priority is missing (pre-Slice-8 backend
responses), so the cutover is bidirectional-safe. After Slice 9
drops the legacy fields, the fallback branch becomes unreachable.
CalculatedDeadline TS interface gains:
- priority: optional 4-way union literal type
- conditionExpr: optional unknown (rule editor reads this; the
save-modal doesn't need to interpret it)
i18n keys added (DE + EN both):
- deadlines.priority.mandatory/recommended/optional/informational
- deadlines.priority.informational.notice_label (Hinweis / Note)
- project.instance_level.first/appeal/cassation/unset
- verlauf.spawn.chip + verlauf.spawn.cycle_warning (reserved for
the SmartTimeline spawn-chip work, deferred to a focused
follow-up so this slice doesn't balloon)
Frontend build clean (2225 i18n keys, 11 new). The instance_level
pill group on the project-edit form is intentionally NOT shipped
in this slice — the project-edit form is large and the pill is
self-contained UI; the data field is exposed via the API and a
follow-up slice (or the rule editor work) can wire the picker
without blocking the wire-shape swap.
Phase 3 Slice 8 wire-shape swap. UIDeadline gains:
- Priority: 4-way enum (mandatory|recommended|optional|informational)
— the authoritative field the frontend reads after Slice 8 to drive
save-modal pre-check + notice-card rendering.
- ConditionExpr: jsonb gate predicate (design §2.4 long form),
emitted verbatim as json.RawMessage so the rule editor (Slice 11)
+ admin surfaces can render the gating shape.
Additivity invariant: the legacy IsMandatory / IsOptional pair stays
populated via wireFlagsFromPriority (mandatory→T/F, optional→T/T,
recommended|informational→F/F). Pre-Slice-8 frontends keep working;
Slice 9 drops the legacy fields once the frontend cutover is verified
in prod.
All three calculator paths populate the new fields:
- FristenrechnerService.Calculate (proceeding-tree, Pipeline A)
- FristenrechnerService.calculateByTriggerEvent (Pipeline C)
- EventTriggerService.Trigger (event-keyed endpoint, Slice 6)
Backend live-DB test asserts:
- Every UPC_INF rule's priority is in the unified enum.
- The wireFlagsFromPriority round-trip holds for every row.
- At least one rule carries a populated conditionExpr (the 17
with_ccr / with_amend / with_cci rules from mig 084).
Phase 3 Slice 8 part 1 — wire the instance_level data field (mig 080
column, shipped in Slice 1) through the project service + handler.
- CreateProjectInput / UpdateProjectInput gain InstanceLevel *string.
Empty string is the explicit "clear" sentinel.
- validateInstanceLevel + nullableInstanceLevel helpers mirror the
OurSide pattern. Allowed values per mig 080 CHECK: 'first' |
'appeal' | 'cassation' | NULL.
- Service rejects bad values with ErrInvalidInput (existing handler
error-mapping surfaces this as HTTP 400 with the standard message).
- projectColumns SELECT now includes instance_level so reads
populate the field; Project struct already has the field from
Slice 1.
- handleCreateProject accepts instance_level from the raw map; Update
handler uses the standard JSON decoder into UpdateProjectInput.
Live-DB test exercises:
- Create with instance_level='first' → roundtrips.
- Update to 'appeal' → roundtrips.
- Update to '' → NULL after the trip.
- Update to 'supreme' → ErrInvalidInput.
The DB CHECK on mig 080 is the defence-in-depth backstop should an
SQL-direct INSERT bypass the service.
Live-DB test for the Phase 3 Slice 7 spawn wiring. Seeds three
synthetic proceedings (SLICE7_TEST_A/B/C) + rules under them, with
audit-reason wrappers so the mig 079 trigger writes informative
audit rows during seed / cleanup. Three scenarios:
1. A → B single spawn. Expansion emits one spawned-into row whose
RuleCode matches B's root rule. DependsOnRuleCode references
A's spawn rule; DependsOnDate is parsed from the synthetic
UIDeadline date (2026-03-15); Track="spawn" so the frontend
boundary divider lights up. DeadlineRuleID points at B's
root rule UUID.
2. Cycle A → B → A. Adds a spawn rule on B back to A; rerun
expansion → ErrCyclicSpawn surfaces (errors.Is matches). The
visited-set guard catches the second-hop attempt to recurse
into A which is already in the chain. No infinite loop.
3. Multi-spawn defensive. Drops the cycle edge, adds a second
spawn rule on A targeting C. Expansion emits two spawned-into
rows (B's root + C's root); the test asserts both RuleCodes
appear in the output regardless of order.
Cleanup: WHERE name LIKE 'SLICE7_TEST_%' AND code LIKE
'SLICE7_TEST_%' so production rules are untouched. audit_reason
set before every INSERT/DELETE so the mig 079 trigger doesn't
reject the seed transactions.
Build clean, full local test suite green; this test skips when
TEST_DATABASE_URL is unset.
Phase 3 Slice 7 Step G (design §6). Closes the half-finished
projection_service.go:896-901 spawn-skip from the t-178 audit.
What lands:
- DeadlineRuleService.ListByProceedingTypeIDs(ids): bulk-load
rules for a set of spawn-target proceedings in one round-trip.
Skips hydrateConceptDefaultEventTypes (SmartTimeline doesn't
need concept-default event_types on spawned rows). Pre-sorted
by (proceeding_type_id, sequence_order) so callers pick the
target's root rule via the first slot per proceeding.
- ProjectionService.expandCrossProceedingSpawns: walks the spawn
graph rooted at the project's source proceeding. For each rule
with is_spawn=true AND a non-NULL spawn_proceeding_type_id,
resolves the target proceeding's root rule and emits a
spawned-into TimelineEvent with:
Kind="projected", Track="spawn", Status="predicted",
DependsOnRuleCode=<source.code>, DependsOnRuleName=<source.name>,
DependsOnDate=<source's computed due date when available>.
SpawnLabel on the source rule, if set, is appended to the
target title as "<target name> (<spawn_label>)".
- Cycle guard: visited-set DFS keyed by proceeding_type_id. The
source proceeding is seeded into `visited` before the walk;
when any spawn's target is already in `visited`, the helper
returns ErrCyclicSpawn with rule + proceeding context. The
caller (computeProjections) catches the error and degrades to
"no spawned rows" — better than failing the whole projection.
ProjectionMeta.SpawnCycleDropped surfaces the degradation so
the caller can log + show a "Spawn-Auflösung übersprungen"
banner.
- Recursion: expandCrossProceedingSpawns recurses into the
target proceeding's spawn rules (depth+1) so a chain
A → B → C surfaces every hop. maxSpawnDepth (4) is a safety
belt on top of the visited-set guard.
Live data semantics: the live corpus has 6 active is_spawn=true
rules — AMD.ccr.amend, AMD.rev.amend, APP.ccr.appeal,
APP.inf.appeal, APP.rev.appeal, CCR.ccr.counterclaim. ALL six have
spawn_proceeding_type_id IS NULL today, so the live SmartTimeline
emits zero spawned-into rows. Slice 7 wires the code path; the
backfill of spawn_proceeding_type_id on these 6 rules is a
separate concern (the design doc's mig 093 was deferred — the
litigation-category proceedings these rules sit in were retired
from project-binding in Slice 5).
Calculator stays scoped (Option A, design §6.2): the unified
FristenrechnerService.Calculate does NOT follow spawns. The
SmartTimeline projection service is the sole consumer that chains
across proceedings. UIResponse.Deadlines for a proceeding only
contains rules from that proceeding; spawn resolution happens at
the projection layer.
projection_service.go:896-901 comment updated to reflect the new
post-Slice-7 reality (calculator stays scoped; spawned rules
arrive via expandCrossProceedingSpawns, not via the calculator's
Deadlines list).
Live-DB test (TEST_DATABASE_URL-gated) for the Phase 3 Slice 6
endpoint covering:
1. Missing both event_type_id + concept_id → ErrInvalidInput.
2. Malformed trigger_date → ErrInvalidInput.
3. Unknown event_type_id → ErrInvalidInput.
4. event_type_id only → parity proxy against
EventDeadlineService.Calculate (Slice-3 legacy delegate). Both
code paths share the unified backend post-Slice-4 so the
returned rule-name multiset must be identical. Selects the
test fixture live: ANY event_type with a non-empty
trigger_event_id bridge to active deadline_rules.
5. concept_id only → returns rules linked by concept_id FK.
Picks the concept with the most rules so we exercise the
ordering path (proceeding_type_id NULLS LAST,
sequence_order). Spot-checks each rule's RuleID parses as UUID.
6. event_type_id + concept_id together → UNION dedupe. Today's
corpus has the two paths on disjoint rule sets so the
additive-count assertion holds; if a future seed links a
concept to a Pipeline-C rule, the dedupe branch fires and the
test logs (not fails) the count divergence for review.
7. Perspective filter — locates a concept with both claimant and
defendant rules (skips gracefully when the corpus lacks one)
and asserts the defendant-perspective response omits every
claimant-party rule.
Build clean, full local test suite green; this test skips when
TEST_DATABASE_URL is unset.
Phase 3 Slice 6 handler. Decodes JSON body (eventTypeId, conceptId,
triggerDate, flags, courtId, perspective), validates required
fields (triggerDate + at least one identifier), parses UUIDs (400
on malformed), delegates to EventTriggerService.Trigger, surfaces
ErrInvalidInput as 400 with the service's German user-facing
message.
Wiring:
- dbServices gains an eventTrigger pointer (handlers package
internal type) wired from handlers.Services.EventTrigger.
- handlers.Services.EventTrigger is the new exported field; the
bundle constructor in main.go fills it from
NewEventTriggerService(pool, rules, holidays, courts).
- Route registered as POST /api/tools/event-trigger on the
protected mux, sibling to the existing /api/tools/fristenrechner
and /api/tools/event-deadlines endpoints.
Returns 503 when DATABASE_URL is unset (matches every other
calculator endpoint's behaviour). Returns same JSON shape as
/api/tools/fristenrechner so the frontend can render with the
existing timeline renderer.
Phase 3 Slice 6 (design §5) — service-side implementation of the new
unified event-trigger entry point. Accepts (event_type_id?,
concept_id?, trigger_date, flags?, court_id?, perspective?) and
returns the same UIResponse the proceeding-tree calculator emits.
Rule discovery:
- event_type_id → SELECT paliad.event_types.trigger_event_id →
DeadlineRuleService.ListByTriggerEvent (Pipeline-C path, post-
Slice-3 unified backend).
- concept_id → DeadlineRuleService.ListByConcept (new method on
the rule service: SELECT deadline_rules WHERE concept_id = $1
AND is_active = true). Direct FK lookup; Pipeline-A cascade
leaf semantic.
- Both → UNION deduped by rule.id (seen-set in Go; small rule
sets, no SQL DISTINCT overhead).
- Validation: at least one of the two must be set;
ErrInvalidInput otherwise. Unknown event_type_id also bubbles
as ErrInvalidInput (404-style).
Math reuses the Slice-4 unified helpers verbatim:
- applyDuration(base, value, unit, timing, country, regime, holidays)
- evalConditionExpr(expr, condition_flag, flags) — long-form
jsonb gate with legacy AND-of-array fallback.
- wireFlagsFromPriority(priority) — derives IsMandatory + IsOptional
so the wire shape stays calibrated against /api/tools/fristenrechner.
Composite combine_op (max/min) + legacy alt-swap-on-flag are
applied in the same mutually-exclusive order the proceeding-tree
calculator uses (combine_op IS NULL ⊕ alt-swap-on-flag-met).
matchesPerspective filter is permissive: empty perspective →
pass-through; NULL party → pass-through; only drops on explicit
claimant↔defendant mismatch. Court / both / NULL rules always
render.
is_court_set rules surface IsCourtSet=true and clear the computed
date — matches the proceeding-tree calculator's "wird vom Gericht
bestimmt" rendering.
UIResponse.ProceedingType / ProceedingName stay empty (caller
already has the event-type / concept context); same contract
calculateByTriggerEvent uses.
DeadlineRuleService.ListByConcept: ORDER BY proceeding_type_id NULLS
LAST, sequence_order so a multi-proceeding concept doesn't
interleave its constituent rules in the timeline.
Live-DB test (TEST_DATABASE_URL-gated) for Phase 3 Slice 5 that
covers the full chain:
1. Migration smoke: post-mig 087, no project points at a
non-fristenrechner-category proceeding_types row.
2. ProjectService.Create with a litigation-category id returns
ErrInvalidProceedingTypeCategory (service-layer guard fires
before any DB write).
3. mig 088 trigger rejects a raw INSERT that bypasses the Go
service — defence-in-depth assertion. Errors on the trigger
raise; test asserts a non-nil error.
4. Fristenrechner-category id (UPC_INF) succeeds. The created
project carries the expected proceeding_type_id.
The four sub-assertions hit each layer of the guard chain (picker
filter → service guard → DB trigger) plus the migration smoke. Any
regression in the chain surfaces here before the deploy.
Tests + main build clean; live test skips when TEST_DATABASE_URL
is unset.
Phase 3 Slice 5 frontend. loadProceedingTypes() in projects-detail.ts
now fetches /api/proceeding-types-db?category=fristenrechner so the
project edit picker only ever shows the 19 fristenrechner codes,
never the 7 legacy litigation codes (INF / REV / CCR / APM / APP /
AMD / ZPO_CIVIL).
The Fristenrechner calculator page + Verfahrensablauf page are NOT
touched — they still need the full proceeding_types catalog (the
litigation codes have rule trees the calculator can render, per
design §3.F: "litigation codes stay … reachable via cascade leaves").
Only the project-binding picker is restricted.
Defence-in-depth: even if a future fetch bypasses this filter, the
server-side service guard (ErrInvalidProceedingTypeCategory) and
the mig 088 DB trigger both reject the write. The picker filter is
the UX layer of the chain — invisible bad-shape inputs.
projects-new.ts has no proceeding-type field today (the form lives
on the edit page only); no change needed there.
