mAi: #98 - move Auto-rule resolved name to its own row

The Auto-mode resolved rule name was rendered as an inline-flex pill
that sat visually crammed next to the [Eigene Regel eingeben] toggle.
Promote .rule-mode-auto to a full-width block-level flex row (width:
100%, margin-top: 0.35rem) so it sits cleanly on its own line beneath
the toggle, and render the rule label via the canonical
formatRuleLabelHTML helper so the citation gets the muted-secondary
styling from rule-label.ts.

Applies to both /deadlines/new and /deadlines/:id edit form. Custom
mode (free-text input) is unaffected — the input already filled the
column.

Refs: m/paliad#98 (t-paliad-267), addendum to t-paliad-258 / m/paliad#89.

.claude/CLAUDE.md

@@ -47,9 +47,13 @@ Paliad — the patent paladin. All-in-one patent practice platform for HLC (form
 | `PALIAD_BASE_URL` | optional | Public origin used in email links. Defaults to `https://paliad.de`; override for staging/preview. |
 | `SMTP_HOST` / `SMTP_PORT` / `SMTP_USERNAME` / `SMTP_PASSWORD` / `SMTP_FROM` / `SMTP_FROM_NAME` / `SMTP_USE_TLS` | for email | SMTP credentials for Paliad's transactional mail (reminders, invitations). Port 465 uses implicit TLS. `MailService` silently no-ops when any required var is missing — the server still boots for knowledge-platform-only deployments. |
 | `ANTHROPIC_API_KEY` | not used in PoC | Reserved for the eventual production-v1 Paliadin (the Anthropic Messages API path, see `docs/design-paliadin-2026-05-07.md` §2). The Phase 0 PoC (t-paliad-146) does NOT use this — it shells out to a local `claude` CLI via tmux instead, which uses m's existing Claude Code subscription. Set this env var only after the PoC validates and we cut over to the API-backed path. The earlier "Phase H Frist-Extraktion" reservation is dead — that feature is deferred separately (memory `b6a11b55…`). |
-| `PALIADIN_SESSION_PREFIX` | optional (default `paliad-paliadin`) | Prefix for the per-user tmux session names the Paliadin service uses (t-paliad-155). Each Paliad user gets their own session named `<prefix>-<userid8>` (first 8 hex chars of the user's UUID); conversation history accumulates per visit, `ResetSession` kills the session entirely. The persona + response protocol now live in `~/.claude/skills/paliadin/SKILL.md` (installed via `scripts/install-paliadin-skill`) — no in-process system prompt is sent. |
+| `PALIADIN_SESSION_PREFIX` | optional (default `paliad-paliadin`) | Prefix for the per-user tmux session names the legacy Paliadin service uses (t-paliad-155). Each Paliad user gets their own session named `<prefix>-<userid8>` (first 8 hex chars of the user's UUID); conversation history accumulates per visit, `ResetSession` kills the session entirely. **Skill source-of-truth moved to `m/mAi` under `skills/aichat/paliadin/` (m's 2026-05-13 decision, t-paliad-194).** The aichat backend owns installation on mRiver via its own deploy doc (`m/mAi/docs/reference/aichat-deploy.md`). Legacy `LocalPaliadinService` (PoC) and `RemotePaliadinService` (shim) still rely on `~/.claude/skills/paliadin/SKILL.md` being present on the target host — install it manually from the aichat repo until those paths are retired. |
 | `PALIADIN_REMOTE_CWD` | shim env (default `/home/m/dev/paliad`) | Working directory `paliadin-shim` uses when spawning the long-lived `claude` pane on mRiver. Must be the paliad repo root so claude picks up `.mcp.json` (project-scoped Supabase MCP); without it, the SKILL.md SQL recipes have no DB tool. Set on mRiver only — paliad's Go side never reads this. |
-| `PALIADIN_RESPONSE_DIR` | optional (default `/tmp/paliadin`) | Directory where Claude writes its per-turn response files. The Go service polls this directory for `{turn_id}.txt` files. |
+| `PALIADIN_RESPONSE_DIR` | optional (default `/tmp/paliadin`) | Directory where Claude writes its per-turn response files. The Go service polls this directory for `{turn_id}.txt` files. (Legacy `LocalPaliadinService` path only — aichat owns its own response dir at `/tmp/aichat/paliadin/`.) |
+| `PALIADIN_BACKEND` | optional (default `legacy`) | Selects which Paliadin backend boots (t-paliad-194 / m/paliad#38 Phase B). `legacy` keeps the existing tree (`PALIADIN_REMOTE_HOST` → SSH shim, else local tmux, else disabled). `aichat` opts into the centralized `m/mAi#207` backend on mRiver — `RemotePaliadinService`/`LocalPaliadinService` are bypassed and `AichatPaliadinService` issues HTTP calls instead. Parallel paths during the migration window; flip back is one env-var change. |
+| `AICHAT_URL` | required when `PALIADIN_BACKEND=aichat` | Aichat service root (typically `http://100.99.98.203:8765` over Tailscale; see `m/mAi/docs/reference/aichat-deploy.md`). No trailing slash needed. |
+| `AICHAT_TOKEN` | required when `PALIADIN_BACKEND=aichat` | Raw bearer token registered for paliad's app_id in aichat's `tokens.yaml`. Distributed via Dokploy secret per Q11 (age-encrypted at rest). |
+| `AICHAT_PERSONA` | optional (default `paliadin`) | Persona id to target. Override only when running a non-default deploy (e.g. staging persona). |
 
 > *Note on Paliadin gating (t-paliad-146):* there is **no** `PALIADIN_ENABLED` env var. Access is gated in code via `services.PaliadinOwnerEmail` (currently `matthias.siebels@hoganlovells.com`). Every other authenticated user gets a 404 on `/paliadin` and `/admin/paliadin`. This means the routes register on every paliad deploy (including paliad.de prod), but only m can reach them — and even then, prod only works if the host has `tmux` + a `claude` CLI in PATH (which the Dokploy container does not). PoC remains a laptop-only feature; the gate is in the code, not the deploy.
 | `FIRM_NAME` | optional (default `HLC`) | Display name of the firm Paliad is being branded for in this deployment. Read once at process start by `internal/branding.Name` (Go) and inlined into client bundles by `frontend/build.ts` (TypeScript). Powers every user-facing surface — landing hero, page titles, login hint, Downloads page, footer, invitation/reminder email bodies. The `ALLOWED_EMAIL_DOMAINS` whitelist is a separate concern (real DNS domains, not display name) and rotates independently. |

.m/config.yaml

@@ -1,6 +1,3 @@
-# Project-specific mai configuration
-# Auto-generated by 'mai init' — run 'mai setup' to customize
-
 provider: claude
 providers:
     claude:
@@ -47,21 +44,13 @@ worker:
     name_scheme: role
     default_level: standard
     auto_discard: false
-    max_workers: 5
+    max_workers: 7
     persistent: true
 head:
-    name: "paliadin"
-    max_loops: 50
-    infinity_mode: false
-    max_idle_duration: 2h0m0s
-    backoff_intervals:
-        - 5
-        - 10
-        - 15
-        - 30
+    name: paliadin
 capacity:
     global:
-        max_workers: 5
+        max_workers: 7
         max_heads: 3
     per_worker:
         max_tasks_lifetime: 0

Makefile

@@ -0,0 +1,73 @@
+# Paliad — developer entrypoints.
+#
+# Targets here are the gate tier from the test-strategy design
+# (docs/design-paliad-test-strategy-2026-05-19.md). Slice 1 lands:
+#
+#   make verify-migrations   — dry-run every pending migration (BEGIN..ROLLBACK)
+#                              plus the full boot smoke (apply + tracker
+#                              advances + /healthz returns 200).
+#   make verify-mig          — alias for verify-migrations.
+#   make test                — short test pass: go test ./internal/... -short
+#                              plus the cmd/server package. Includes the
+#                              live-DB tests when TEST_DATABASE_URL is set,
+#                              skips them otherwise.
+#   make test-go             — go test ./... -race (full Go suite).
+#
+# Future slices will extend this with:
+#   make test-frontend       — bun test (Slice 3 / Slice 6)
+#   make e2e                 — Playwright golden-path suite (Slice 4)
+#
+# All targets are idempotent. None of them write to the filesystem outside
+# the test runner's working dirs. None of them touch internal/db/migrations/
+# files.
+
+.PHONY: help verify-migrations verify-mig test test-go
+
+help:
+	@echo "Paliad — developer targets"
+	@echo ""
+	@echo "  verify-migrations   Dry-run pending migrations + boot smoke (needs TEST_DATABASE_URL)"
+	@echo "  verify-mig          Alias for verify-migrations"
+	@echo "  test                Short test pass — covers gate tier"
+	@echo "  test-go             Full Go suite with race detector"
+	@echo ""
+	@echo "Set TEST_DATABASE_URL to enable live-DB tests. Example:"
+	@echo "  export TEST_DATABASE_URL=postgres://paliad:...@localhost:11833/paliad_test"
+
+# Gate target — the test that would have caught mig 098 / mig 099 before
+# deploy. Combines:
+#   - TestMigrations_DryRun  (internal/db): per-migration BEGIN..ROLLBACK
+#   - TestBootSmoke          (cmd/server): apply-end-to-end + tracker advances
+#                                          + /healthz 200
+#
+# Requires TEST_DATABASE_URL. Without it, both tests skip and the target
+# is effectively a no-op — guard against that explicitly so CI doesn't
+# silently green a missing env var.
+verify-migrations:
+	@if [ -z "$$TEST_DATABASE_URL" ]; then \
+		echo "ERROR: TEST_DATABASE_URL is not set."; \
+		echo "       The migration gate cannot run without a scratch DB."; \
+		echo "       Set TEST_DATABASE_URL to a Postgres URL the test can"; \
+		echo "       open transactions against, e.g."; \
+		echo "         export TEST_DATABASE_URL=postgres://paliad:PW@localhost:11833/paliad_test"; \
+		exit 2; \
+	fi
+	@echo "==> migration dry-run (per-mig BEGIN..ROLLBACK)"
+	go test -count=1 -run TestMigrations_DryRun ./internal/db/
+	@echo "==> boot smoke (apply + tracker + /healthz)"
+	go test -count=1 -run TestBootSmoke ./cmd/server/
+
+verify-mig: verify-migrations
+
+# Gate-tier test pass. -short skips the slow live-DB tests when the
+# author opts out via `if testing.Short() { t.Skip(...) }`; today most of
+# paliad's live-DB tests gate on TEST_DATABASE_URL instead, so -short is
+# forward-compatible rather than load-bearing.
+test:
+	go test -short ./internal/... ./cmd/...
+
+# Full Go suite with race detection. Slower but catches concurrent-map
+# regressions that -short would skip; intended for the merge-to-main gate
+# (full suite, not per-PR).
+test-go:
+	go test -race ./...

cmd/server/main.go

@@ -117,7 +117,9 @@ func main() {
 		}
 
 		appointmentSvc := services.NewAppointmentService(pool, projectSvc)
-		caldavSvc = services.NewCalDAVService(pool, cipher, appointmentSvc)
+		bindingSvc := services.NewCalendarBindingService(pool)
+		targetSvc := services.NewAppointmentTargetService(pool)
+		caldavSvc = services.NewCalDAVService(pool, cipher, appointmentSvc, bindingSvc, targetSvc)
 		// Wire the push hook so user-driven mutations sync to the external
 		// calendar without waiting for the next 60-second tick.
 		appointmentSvc.SetCalDAVPusher(caldavSvc)
@@ -126,6 +128,20 @@ func main() {
 		inviteSvc := services.NewInviteService(pool, mailSvc, handlers.AllowedEmailDomains, baseURL)
 		reminderSvc := services.NewReminderService(pool, mailSvc, users, baseURL)
 
+		// t-paliad-223 Slice B (#49) — Supabase Admin API client for the
+		// new "Konto direkt anlegen" path on /admin/team. The key is
+		// optional: when unset the client still wires (so dependents
+		// don't panic) but every call short-circuits with
+		// ErrSupabaseAdminUnavailable so the rest of the server stays
+		// runnable.
+		supabaseAdminClient := services.LoadSupabaseAdminClient()
+		if supabaseAdminClient.Enabled() {
+			log.Println("supabase admin API configured — /admin/team Add-User path active")
+		} else {
+			log.Println("SUPABASE_SERVICE_ROLE_KEY not set — /admin/team Add-User path will return 503")
+		}
+		users.SetAddUserDeps(supabaseAdminClient, mailSvc, baseURL)
+
 		// Wire EmailTemplateService onto the MailService so DB-backed admin
 		// edits propagate without a process restart. The constructor is split
 		// from MailService creation because the DB pool isn't available yet
@@ -135,26 +151,53 @@ func main() {
 
 		eventTypeSvc := services.NewEventTypeService(pool, users)
 		deadlineSvc := services.NewDeadlineService(pool, projectSvc, eventTypeSvc)
+		partySvc := services.NewPartyService(pool, projectSvc)
+		// t-paliad-238 — dedicated submission draft editor. The variable
+		// bag service is shared between the renderer (export) and the
+		// preview HTML path. Resurrected from t-paliad-215 Slice 1 backend
+		// (commits 3677c81 + 1765d5e + 8ea3509).
+		submissionVarsSvc := services.NewSubmissionVarsService(pool, projectSvc, partySvc, users)
+		submissionRenderer := services.NewSubmissionRenderer()
+		submissionDraftSvc := services.NewSubmissionDraftService(pool, projectSvc, submissionVarsSvc, submissionRenderer)
+		// t-paliad-225 Slice A — user-authored checklist templates.
+		// Slice B adds checklist_shares grants + admin promotion.
+		checklistCatalogSvc := services.NewChecklistCatalogService(pool)
+		sysAuditSvc := services.NewSystemAuditLogService(pool)
+		checklistTemplateSvc := services.NewChecklistTemplateService(pool, checklistCatalogSvc, sysAuditSvc, users)
 		svcBundle = &handlers.Services{
 			Project:        projectSvc,
 			Team:           teamSvc,
 			PartnerUnit:    partnerUnitSvc,
-			Party:          services.NewPartyService(pool, projectSvc),
+			Party:          partySvc,
+			SubmissionDraft: submissionDraftSvc,
 			Deadline:       deadlineSvc,
 			Appointment:    appointmentSvc,
 			CalDAV:         caldavSvc,
+			CalDAVBindings: bindingSvc,
 			Rules:          rules,
 			Calculator:     services.NewDeadlineCalculator(holidays),
 			Users:          users,
 			Fristenrechner: services.NewFristenrechnerService(rules, holidays, courts),
-			EventDeadline:  services.NewEventDeadlineService(pool, services.NewDeadlineCalculator(holidays), holidays, courts),
+			EventDeadline: services.NewEventDeadlineService(
+				pool,
+				services.NewDeadlineCalculator(holidays),
+				holidays,
+				courts,
+				services.NewFristenrechnerService(rules, holidays, courts),
+			),
+			EventTrigger: services.NewEventTriggerService(pool, rules, holidays, courts),
+			RuleEditor:   services.NewRuleEditorService(pool, rules),
 			Courts:         courts,
 			DeadlineSearch: services.NewDeadlineSearchService(pool),
 			EventCategory:  nil, // wired below; cross-link order matters
 			EventType:      eventTypeSvc,
 			Dashboard:      services.NewDashboardService(pool, users),
 			Note:           services.NewNoteService(pool, projectSvc, appointmentSvc),
-			ChecklistInst:  services.NewChecklistInstanceService(pool, projectSvc),
+			ChecklistInst:  services.NewChecklistInstanceService(pool, projectSvc, checklistCatalogSvc),
+			ChecklistCatalog: checklistCatalogSvc,
+			ChecklistTemplate: checklistTemplateSvc,
+			ChecklistShare: services.NewChecklistShareService(pool, checklistTemplateSvc, sysAuditSvc, users),
+			ChecklistPromotion: services.NewChecklistPromotionService(pool, checklistTemplateSvc, sysAuditSvc, users),
 			Mail:           mailSvc,
 			Invite:         inviteSvc,
 			Agenda:         services.NewAgendaService(pool, users, eventTypeSvc),
@@ -167,36 +210,108 @@ func main() {
 			UserView:       services.NewUserViewService(pool),
 			Broadcast:      services.NewBroadcastService(pool, mailSvc, users, teamSvc, emailTemplateSvc),
 			Pin:            services.NewPinService(pool, projectSvc),
-			CardLayout:     services.NewCardLayoutService(pool),
+			CardLayout:              services.NewCardLayoutService(pool),
+			DashboardLayout:         services.NewDashboardLayoutService(pool),
+			FirmDashboardDefault:    services.NewFirmDashboardDefaultService(pool),
+			Projection:      services.NewProjectionService(pool, projectSvc, deadlineSvc, appointmentSvc, services.NewFristenrechnerService(rules, holidays, courts), rules),
+			// t-paliad-214 Slice 1 — personal-scope data export. firm name
+			// is captured into __meta of every export and printed in the
+			// embedded README.
+			Export: services.NewExportService(pool, branding.Name),
 		}
 
-		// Paliadin backend selection (t-paliad-146 + t-paliad-151):
-		//   PALIADIN_REMOTE_HOST set → RemotePaliadinService (ssh to mRiver)
-		//   else: local tmux available → LocalPaliadinService (PoC path)
-		//   else: DisabledPaliadinService (handlers still 404 for non-owners
-		//         via the gate; for m, RunTurn returns ErrPaliadinDisabled
-		//         which surfaces as a friendly error).
-		//
-		// All three implement services.Paliadin; the per-request handler
-		// gate (requirePaliadinOwner) is unchanged and applies to every
-		// backend.
-		if remoteHost := os.Getenv("PALIADIN_REMOTE_HOST"); remoteHost != "" {
-			cfg, err := buildPaliadinRemoteConfig(remoteHost)
+		// t-paliad-246 Slice A — Backup Mode runner. Wired only when
+		// PALIAD_EXPORT_DIR is set (LocalDiskStore needs a target
+		// directory). Without it the /admin/backups handlers return 503
+		// in the same shape as Paliadin's gate. The directory is created
+		// (0700) on first use; a malformed path fails fast at boot so
+		// misconfig surfaces before the server starts taking traffic.
+		if exportDir := strings.TrimSpace(os.Getenv("PALIAD_EXPORT_DIR")); exportDir != "" {
+			store, err := services.NewLocalDiskStore(exportDir)
 			if err != nil {
-				log.Fatalf("paliadin: remote config: %v", err)
+				log.Fatalf("PALIAD_EXPORT_DIR: %v", err)
 			}
-			svcBundle.Paliadin = services.NewRemotePaliadinService(pool, users, cfg)
-			log.Printf("paliadin: remote mode → ssh %s@%s:%d (owner=%s)",
-				cfg.SSHUser, cfg.SSHHost, cfg.SSHPort, services.PaliadinOwnerEmail)
-		} else if _, err := exec.LookPath("tmux"); err == nil {
-			sessionPrefix := os.Getenv("PALIADIN_SESSION_PREFIX")
-			responseDir := os.Getenv("PALIADIN_RESPONSE_DIR")
-			svcBundle.Paliadin = services.NewLocalPaliadinService(pool, users, sessionPrefix, responseDir)
-			log.Printf("paliadin: local tmux mode (owner=%s)", services.PaliadinOwnerEmail)
+			svcBundle.Backup = services.NewBackupRunner(pool, svcBundle.Export, store)
+			log.Printf("backup: LocalDiskStore at %s (/admin/backups active)", exportDir)
 		} else {
-			svcBundle.Paliadin = services.NewDisabledPaliadinService(pool, users)
-			log.Printf("paliadin: disabled (no PALIADIN_REMOTE_HOST, no local tmux; owner=%s)",
-				services.PaliadinOwnerEmail)
+			log.Println("PALIAD_EXPORT_DIR not set — /admin/backups will return 503")
+		}
+
+		// t-paliad-219 Slice A3 — stitch DashboardService → ApprovalService
+		// for the inbox-approvals widget. Done post-construction to avoid
+		// a circular constructor dependency (ApprovalService doesn't need
+		// the dashboard, and DashboardService can render its other widgets
+		// without approvals — so keeping this a setter keeps both
+		// constructors simple).
+		svcBundle.Dashboard.SetApprovalService(svcBundle.Approval)
+		// Slice C wires PinService into DashboardService for the
+		// pinned-projects widget. Pin pre-dates t-paliad-219; no new
+		// schema, no circular dependency (Pin doesn't know about the
+		// dashboard).
+		svcBundle.Dashboard.SetPinService(svcBundle.Pin)
+		// Slice C wires the firm-wide dashboard default into the
+		// per-user layout service so GetOrSeed/ResetToDefault prefer
+		// the admin-set firm default over the code-resident factory.
+		// Nil-safe: empty firm row falls back to the factory layout.
+		svcBundle.DashboardLayout.SetFirmDefaultService(svcBundle.FirmDashboardDefault)
+
+		// t-paliad-230 — submission generator (format-only). No
+		// service wiring needed: handlers/submissions.go reuses the
+		// existing files.go HL Patents Style cache and calls
+		// services.ConvertDotmToDocx (stateless function).
+
+		// Paliadin backend selection.
+		//
+		// PALIADIN_BACKEND (t-paliad-194 / m/paliad#38):
+		//   "aichat"               → AichatPaliadinService (HTTP client of the
+		//                              centralized aichat backend on mRiver,
+		//                              shipped in m/mAi#207 Phase A).
+		//   "legacy" / unset / etc → fall through to the pre-aichat tree:
+		//     PALIADIN_REMOTE_HOST set     → RemotePaliadinService (ssh shim)
+		//     else: local tmux available    → LocalPaliadinService (PoC path)
+		//     else                          → DisabledPaliadinService
+		//
+		// The aichat path is opt-in for the migration window so a flip
+		// back is one env-var change. Once aichat soaks, legacy can be
+		// retired in a follow-up slice.
+		//
+		// All four implementations satisfy services.Paliadin; the per-
+		// request handler gate (requirePaliadinOwner) is unchanged.
+		switch strings.ToLower(strings.TrimSpace(os.Getenv("PALIADIN_BACKEND"))) {
+		case "aichat":
+			cfg, err := buildAichatPaliadinConfig(jwtSecret)
+			if err != nil {
+				log.Fatalf("paliadin: aichat config: %v", err)
+			}
+			svcBundle.Paliadin = services.NewAichatPaliadinService(pool, users, cfg)
+			log.Printf("paliadin: aichat mode → %s persona=%s (owner=%s, rls=%s)",
+				cfg.BaseURL, cfg.Persona, services.PaliadinOwnerEmail,
+				rlsModeLabel(cfg.JWTSecret))
+		default:
+			if remoteHost := os.Getenv("PALIADIN_REMOTE_HOST"); remoteHost != "" {
+				cfg, err := buildPaliadinRemoteConfig(remoteHost)
+				if err != nil {
+					log.Fatalf("paliadin: remote config: %v", err)
+				}
+				svcBundle.Paliadin = services.NewRemotePaliadinService(pool, users, cfg)
+				log.Printf("paliadin: remote mode → ssh %s@%s:%d (owner=%s)",
+					cfg.SSHUser, cfg.SSHHost, cfg.SSHPort, services.PaliadinOwnerEmail)
+			} else if _, err := exec.LookPath("tmux"); err == nil {
+				sessionPrefix := os.Getenv("PALIADIN_SESSION_PREFIX")
+				responseDir := os.Getenv("PALIADIN_RESPONSE_DIR")
+				local := services.NewLocalPaliadinService(pool, users, sessionPrefix, responseDir)
+				// Late-response janitor — patches rows when Claude writes the
+				// response file after the 60 s pollForResponse window expires.
+				// Runs for the process lifetime; cleaned up when bgCtx
+				// cancels on SIGTERM.
+				local.StartJanitor(bgCtx)
+				svcBundle.Paliadin = local
+				log.Printf("paliadin: local tmux mode (owner=%s, janitor=on)", services.PaliadinOwnerEmail)
+			} else {
+				svcBundle.Paliadin = services.NewDisabledPaliadinService(pool, users)
+				log.Printf("paliadin: disabled (no PALIADIN_REMOTE_HOST, no local tmux; owner=%s)",
+					services.PaliadinOwnerEmail)
+			}
 		}
 		// Wire ApprovalService into the entity services so Create / Update /
 		// Complete / Delete consult paliad.approval_policies (t-paliad-138).
@@ -367,3 +482,49 @@ func cmpOr(s, fallback string) string {
 	}
 	return fallback
 }
+
+// buildAichatPaliadinConfig assembles an AichatPaliadinConfig from the
+// environment for PALIADIN_BACKEND=aichat (t-paliad-194 / m/paliad#38).
+//
+// Required:
+//
+//	AICHAT_URL    — service root (e.g. http://100.99.98.203:8765).
+//	AICHAT_TOKEN  — raw bearer token paliad's app_id is registered
+//	                under in aichat's tokens.yaml (see m/mAi
+//	                docs/reference/aichat-deploy.md).
+//
+// Optional:
+//
+//	AICHAT_PERSONA — persona id; defaults to "paliadin".
+//
+// jwtSecret comes from the same SUPABASE_JWT_SECRET that auth.NewClient
+// already requires at boot — never empty when we reach this code path.
+// It's threaded in so the aichat service can mint per-turn user-scoped
+// JWTs (folded-in t-paliad-156 work).
+func buildAichatPaliadinConfig(jwtSecret string) (services.AichatPaliadinConfig, error) {
+	cfg := services.AichatPaliadinConfig{
+		BaseURL:     strings.TrimRight(os.Getenv("AICHAT_URL"), "/"),
+		BearerToken: os.Getenv("AICHAT_TOKEN"),
+		Persona:     cmpOr(os.Getenv("AICHAT_PERSONA"), services.DefaultAichatPersona),
+		JWTSecret:   []byte(jwtSecret),
+	}
+	if cfg.BaseURL == "" {
+		return cfg, fmt.Errorf("AICHAT_URL must be set when PALIADIN_BACKEND=aichat")
+	}
+	if cfg.BearerToken == "" {
+		return cfg, fmt.Errorf("AICHAT_TOKEN must be set when PALIADIN_BACKEND=aichat")
+	}
+	return cfg, nil
+}
+
+// rlsModeLabel labels the boot log so the operator can confirm whether
+// the per-user JWT mint is active. "per-user" means we're handing the
+// claude pane user-scoped claims; "service-role" means we're not (no
+// SUPABASE_JWT_SECRET) and the skill will reject queries rather than
+// run as supabase_admin.
+func rlsModeLabel(secret []byte) string {
+	if len(secret) == 0 {
+		return "service-role"
+	}
+	return "per-user"
+}

cmd/server/main_paliadin_backend_test.go

@@ -0,0 +1,86 @@
+package main
+
+import (
+	"strings"
+	"testing"
+)
+
+// TestBuildAichatPaliadinConfig pins the env-driven wiring used by the
+// PALIADIN_BACKEND=aichat path in main(). It guards three things:
+//
+//  1. Required vars (AICHAT_URL, AICHAT_TOKEN) must be set — otherwise
+//     boot fails fast with a clear error message.
+//  2. AICHAT_PERSONA defaults to "paliadin" so a misconfigured deploy
+//     doesn't silently route to a different persona.
+//  3. The JWT secret threads through so per-turn JWT mint is on by
+//     default (folded-in t-paliad-156 work).
+//
+// We can't unit-test the switch{} block in main() directly without
+// invoking the rest of boot, so this test exercises the helper that
+// branch calls — the same surface a Phase B regression would hit.
+func TestBuildAichatPaliadinConfig(t *testing.T) {
+	t.Run("rejects empty URL", func(t *testing.T) {
+		t.Setenv("AICHAT_URL", "")
+		t.Setenv("AICHAT_TOKEN", "tok")
+		_, err := buildAichatPaliadinConfig("secret")
+		if err == nil || !strings.Contains(err.Error(), "AICHAT_URL") {
+			t.Errorf("err = %v; want AICHAT_URL complaint", err)
+		}
+	})
+
+	t.Run("rejects empty token", func(t *testing.T) {
+		t.Setenv("AICHAT_URL", "http://aichat.test")
+		t.Setenv("AICHAT_TOKEN", "")
+		_, err := buildAichatPaliadinConfig("secret")
+		if err == nil || !strings.Contains(err.Error(), "AICHAT_TOKEN") {
+			t.Errorf("err = %v; want AICHAT_TOKEN complaint", err)
+		}
+	})
+
+	t.Run("defaults persona to paliadin", func(t *testing.T) {
+		t.Setenv("AICHAT_URL", "http://aichat.test/")
+		t.Setenv("AICHAT_TOKEN", "tok")
+		t.Setenv("AICHAT_PERSONA", "")
+		cfg, err := buildAichatPaliadinConfig("secret")
+		if err != nil {
+			t.Fatalf("err: %v", err)
+		}
+		if cfg.Persona != "paliadin" {
+			t.Errorf("persona = %q; want paliadin", cfg.Persona)
+		}
+		if cfg.BaseURL != "http://aichat.test" {
+			t.Errorf("base url trailing slash leaked: %q", cfg.BaseURL)
+		}
+		if string(cfg.JWTSecret) != "secret" {
+			t.Errorf("JWT secret not threaded; got %q", string(cfg.JWTSecret))
+		}
+		if cfg.BearerToken != "tok" {
+			t.Errorf("BearerToken = %q; want tok", cfg.BearerToken)
+		}
+	})
+
+	t.Run("honours AICHAT_PERSONA override", func(t *testing.T) {
+		t.Setenv("AICHAT_URL", "http://aichat.test")
+		t.Setenv("AICHAT_TOKEN", "tok")
+		t.Setenv("AICHAT_PERSONA", "custom-paliadin")
+		cfg, err := buildAichatPaliadinConfig("secret")
+		if err != nil {
+			t.Fatalf("err: %v", err)
+		}
+		if cfg.Persona != "custom-paliadin" {
+			t.Errorf("persona = %q; want custom-paliadin", cfg.Persona)
+		}
+	})
+}
+
+func TestRLSModeLabel(t *testing.T) {
+	if got := rlsModeLabel(nil); got != "service-role" {
+		t.Errorf("nil → %q; want service-role", got)
+	}
+	if got := rlsModeLabel([]byte{}); got != "service-role" {
+		t.Errorf("empty → %q; want service-role", got)
+	}
+	if got := rlsModeLabel([]byte("x")); got != "per-user" {
+		t.Errorf("non-empty → %q; want per-user", got)
+	}
+}

cmd/server/main_smoke_test.go

@@ -0,0 +1,210 @@
+// Boot smoke test — assert paliad reaches a serving state.
+//
+// Three checks against TEST_DATABASE_URL:
+//
+//  1. db.ApplyMigrations does not panic and returns nil.
+//  2. paliad.applied_migrations covers every on-disk *.up.sql — no
+//     migration was silently skipped, no version is missing. The set
+//     contract is stronger than the old single-counter check: applied
+//     set must EQUAL on-disk set, not just reach the max version.
+//  3. The handler mux (with /healthz mounted) responds 200 to GET /healthz.
+//
+// This is the lightweight cousin of the migration dry-run gate
+// (internal/db/migrate_test.go): the dry-run catches per-migration syntax
+// errors before merge; this smoke confirms the apply+bind path the
+// container actually runs at boot. Together they cover the mig-098 /
+// mig-099 class of crash-loops end-to-end, plus the mig-103 parallel-merge
+// skip-hole that t-paliad-218 closed (m/paliad#44).
+//
+// Skipped without TEST_DATABASE_URL — matches the rest of the live-DB tests.
+//
+// Design: docs/design-paliad-test-strategy-2026-05-19.md §5 Slice 1 and
+// docs/design-migration-runner-applied-set-2026-05-20.md §6.
+
+package main
+
+import (
+	"database/sql"
+	"net/http"
+	"net/http/httptest"
+	"os"
+	"path/filepath"
+	"sort"
+	"strconv"
+	"strings"
+	"testing"
+
+	_ "github.com/lib/pq"
+
+	"mgit.msbls.de/m/paliad/internal/auth"
+	"mgit.msbls.de/m/paliad/internal/db"
+	"mgit.msbls.de/m/paliad/internal/handlers"
+)
+
+func TestBootSmoke(t *testing.T) {
+	url := os.Getenv("TEST_DATABASE_URL")
+	if url == "" {
+		t.Skip("TEST_DATABASE_URL not set — skipping boot smoke")
+	}
+
+	// (1) Apply migrations end-to-end. The same code path the prod
+	// container runs at boot before `http.ListenAndServe`. A regression
+	// like mig-098's digit-regex would surface here as a non-nil error.
+	if err := db.ApplyMigrations(url); err != nil {
+		t.Fatalf("db.ApplyMigrations: %v", err)
+	}
+
+	// (2) Assert the applied set equals the on-disk set. The new runner
+	// tracks applied state per-migration; a silently-skipped version
+	// would surface as a row missing from paliad.applied_migrations even
+	// though max(version) matches. Comparing sets — not just max —
+	// catches the failure mode the t-paliad-218 post-mortem documented.
+	onDisk := embeddedMigrationVersions(t)
+	applied := appliedMigrationVersions(t, url)
+
+	if missing := setDiff(onDisk, applied); len(missing) > 0 {
+		t.Errorf("paliad.applied_migrations missing %d on-disk versions: %v "+
+			"(a migration was skipped — investigate before deploying)",
+			len(missing), missing)
+	}
+	if extra := setDiff(applied, onDisk); len(extra) > 0 {
+		t.Errorf("paliad.applied_migrations has %d versions with no on-disk file: %v "+
+			"(orphan rows — either restore the file or DELETE the row)",
+			len(extra), extra)
+	}
+
+	// (3) Mount the public handlers (the same Register call main() makes,
+	// minus the DB-backed Services bundle which the /healthz route doesn't
+	// need) and assert /healthz returns 200. This is the bind-and-serve
+	// half of the smoke: catches a regression that would make /healthz
+	// 404 or break the mux registration order.
+	//
+	// We deliberately do not boot the full main() — that would require
+	// SUPABASE_URL, SUPABASE_ANON_KEY, SUPABASE_JWT_SECRET, an open
+	// listening socket and a real auth client. The /healthz handler is
+	// auth-independent by design, and Register registers it on the outer
+	// mux before any DB-backed route, so this minimal setup exercises the
+	// exact code path main() takes.
+	mux := http.NewServeMux()
+	authClient := auth.NewClient("https://test.invalid", "anon-key", []byte("test-secret"))
+	handlers.Register(mux, authClient, "", nil)
+
+	rec := httptest.NewRecorder()
+	req := httptest.NewRequest(http.MethodGet, "/healthz", nil)
+	mux.ServeHTTP(rec, req)
+	if rec.Code != http.StatusOK {
+		t.Errorf("GET /healthz: status=%d, body=%q; want 200 OK", rec.Code, rec.Body.String())
+	}
+	if body := strings.TrimSpace(rec.Body.String()); body != "ok" {
+		t.Errorf("GET /healthz: body=%q; want \"ok\"", body)
+	}
+}
+
+// embeddedMigrationVersions returns every N where N_*.up.sql exists in
+// internal/db/migrations/ on disk. The boot smoke compares this set
+// against paliad.applied_migrations to detect skipped or orphan
+// migrations.
+//
+// Read from disk (not the embed.FS inside the db package — it's unexported)
+// since the test runs from the repo. The two views must agree for the
+// build to be self-consistent; if they diverge, the smoke test is the
+// wrong place to learn about it (the build is). We trust them to match.
+func embeddedMigrationVersions(t *testing.T) []int {
+	t.Helper()
+	root, err := repoRoot()
+	if err != nil {
+		t.Fatalf("locate repo root: %v", err)
+	}
+	dir := filepath.Join(root, "internal", "db", "migrations")
+	entries, err := os.ReadDir(dir)
+	if err != nil {
+		t.Fatalf("read migrations dir %s: %v", dir, err)
+	}
+	var versions []int
+	for _, e := range entries {
+		name := e.Name()
+		if !strings.HasSuffix(name, ".up.sql") {
+			continue
+		}
+		base := strings.TrimSuffix(name, ".up.sql")
+		underscore := strings.IndexByte(base, '_')
+		if underscore <= 0 {
+			continue
+		}
+		v, err := strconv.Atoi(base[:underscore])
+		if err != nil {
+			continue
+		}
+		versions = append(versions, v)
+	}
+	if len(versions) == 0 {
+		t.Fatalf("no *.up.sql files found in %s", dir)
+	}
+	sort.Ints(versions)
+	return versions
+}
+
+// appliedMigrationVersions reads paliad.applied_migrations and returns
+// the sorted list of versions. Fails the test if the table doesn't exist —
+// db.ApplyMigrations is supposed to have created it by this point.
+func appliedMigrationVersions(t *testing.T, url string) []int {
+	t.Helper()
+	conn, err := sql.Open("postgres", url)
+	if err != nil {
+		t.Fatalf("open: %v", err)
+	}
+	defer conn.Close()
+	rows, err := conn.Query(`SELECT version FROM paliad.applied_migrations ORDER BY version`)
+	if err != nil {
+		t.Fatalf("read applied_migrations: %v", err)
+	}
+	defer rows.Close()
+	var out []int
+	for rows.Next() {
+		var v int
+		if err := rows.Scan(&v); err != nil {
+			t.Fatalf("scan: %v", err)
+		}
+		out = append(out, v)
+	}
+	if err := rows.Err(); err != nil {
+		t.Fatalf("rows: %v", err)
+	}
+	return out
+}
+
+// setDiff returns the elements of a that are not in b. Inputs are sorted
+// ascending; output preserves that ordering.
+func setDiff(a, b []int) []int {
+	bset := make(map[int]bool, len(b))
+	for _, v := range b {
+		bset[v] = true
+	}
+	var out []int
+	for _, v := range a {
+		if !bset[v] {
+			out = append(out, v)
+		}
+	}
+	return out
+}
+
+// repoRoot walks upward from the test binary's working directory until it
+// finds a go.mod. `go test` runs in the package dir, so we typically have
+// to climb a couple of levels.
+func repoRoot() (string, error) {
+	dir, err := os.Getwd()
+	if err != nil {
+		return "", err
+	}
+	for {
+		if _, err := os.Stat(filepath.Join(dir, "go.mod")); err == nil {
+			return dir, nil
+		}
+		parent := filepath.Dir(dir)
+		if parent == dir {
+			return "", os.ErrNotExist
+		}
+		dir = parent
+	}
+}

docker-compose.yml

@@ -8,6 +8,7 @@ services:
       - SUPABASE_URL=${SUPABASE_URL}
       - SUPABASE_ANON_KEY=${SUPABASE_ANON_KEY}
       - SUPABASE_JWT_SECRET=${SUPABASE_JWT_SECRET}
+      - SUPABASE_SERVICE_ROLE_KEY=${SUPABASE_SERVICE_ROLE_KEY:-}
       - GITEA_TOKEN=${GITEA_TOKEN}
       - DATABASE_URL=${DATABASE_URL}
       - CALDAV_ENCRYPTION_KEY=${CALDAV_ENCRYPTION_KEY}
@@ -34,5 +35,12 @@ services:
       - PALIADIN_REMOTE_USER=${PALIADIN_REMOTE_USER}
       - PALIADIN_SSH_PRIVATE_KEY=${PALIADIN_SSH_PRIVATE_KEY}
       - PALIADIN_KNOWN_HOSTS=${PALIADIN_KNOWN_HOSTS}
+      # aichat Phase B (t-paliad-194 / m/paliad#38). Set PALIADIN_BACKEND=aichat
+      # to route Paliadin through the centralized aichat backend on mRiver.
+      # Legacy default (unset / "legacy") keeps the existing RemotePaliadinService path.
+      - PALIADIN_BACKEND=${PALIADIN_BACKEND:-legacy}
+      - AICHAT_URL=${AICHAT_URL:-}
+      - AICHAT_TOKEN=${AICHAT_TOKEN:-}
+      - AICHAT_PERSONA=${AICHAT_PERSONA:-paliadin}
       # - ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}  # Phase H (AI Frist-Extraktion), currently deferred
     restart: unless-stopped

docs/audit-fristen-logic-2026-05-13.md

@@ -0,0 +1,799 @@
+# Audit — Fristen logic (rules, triggers, conditionals)
+
+**Author:** pauli (inventor)
+**Date:** 2026-05-13
+**Task:** t-paliad-157 (reactivated 2026-05-13 21:23 with broader scope)
+**Phase:** 1 of 3 — Audit. Phase 2 = iterative refinement against m. Phase 3 = ship.
+**Branch:** `mai/pauli/fristen-logic-audit` (fresh from `origin/main` @ `7d9935d`).
+**Status:** AUDIT READY FOR REVIEW — m gates the audit → Phase 2 transition.
+
+m's framing (paliad/head 11:46):
+
+> the main roadmap thing now is "Fristen". We need the full "Fristen logic" and I am happy to work together with an AI to further design it. Most of it should be "straightforward" as specific events trigger specific deadlines, sometimes multiple and sometimes conditional. It is all in the Rules so we should be able to manage.
+
+The audit answers: **is m's mental model already encodable in the existing data model, and where are the gaps?**
+
+Short answer: the rule corpus is substantially richer than the brief implied, **three parallel deadline-generation systems coexist** (with overlapping responsibilities), and the main friction is *managing* rules (SQL-only today) rather than the expressive grammar of the rules themselves.
+
+---
+
+## 0. Premises verified live (live DB + live code, not migration files)
+
+Live state queried via `mcp__supabase__execute_sql` against the `paliad` schema on the youpc Supabase Postgres. Code reads against `mai/pauli/fristen-logic-audit` baseline (origin/main @ `7d9935d`).
+
+### 0.1 Rule corpus is ~5× richer than the brief implied
+
+| Table | Rows | Note |
+|---|---|---|
+| `paliad.proceeding_types` | **27** | 20 `category='fristenrechner'` + 7 `category='litigation'`. All 27 carry rules. |
+| `paliad.deadline_rules` | **172** | 132 against fristenrechner codes + 40 against litigation codes. |
+| `paliad.deadline_concepts` | **56** | The "noun" layer (Klageerwiderung, Berufungsschrift, …) above rules. |
+| `paliad.event_category_concepts` | **153** | Cascade-leaf → concept junction (with optional `proceeding_type_code` for context-conditional outcomes). |
+| `paliad.deadline_concept_event_types` | **32** | Concept → event_type default suggestion (per jurisdiction). |
+| `paliad.trigger_events` | **110** | youpc.org legacy import. Used by the "Was kommt nach…" mode. |
+| `paliad.event_deadlines` | **77** | trigger_event → deadline_row, with `combine_op` ∈ {min,max} for composite leads. |
+| `paliad.event_types` | **40+** | Concrete event types (upc_oral_hearing, upc_statement_of_defence, …). |
+| `paliad.event_categories` | **125** (103 leaves) | Cascade taxonomy. Already audited in t-paliad-166. |
+| `paliad.courts` | **41** | Forum picker for holiday-calendar regime resolution. |
+| `paliad.holidays` | **55** | Seed of public holidays + court closures. |
+| `paliad.deadlines` (live) | **26** | Persisted deadline instances. **Only 1 has `rule_id`.** |
+| `paliad.project_events` | **89** | Audit-log entries. |
+| `paliad.events` | **does not exist** | The brief mentioned `paliad.events`; the actual audit table is `paliad.project_events`. |
+
+### 0.2 Three parallel deadline-generation systems exist today
+
+| Pipeline | Data source | Calculator | Wire surface |
+|---|---|---|---|
+| **A — Proceeding-driven** | `paliad.deadline_rules` (172 rows) | `FristenrechnerService.Calculate(proceedingCode, triggerDate, opts)` (`internal/services/fristenrechner.go:139`) | POST `/api/tools/fristenrechner` (Pathway A wizard, Pathway B cascade, SmartTimeline projection via `ProjectionService.computeProjections`). |
+| **B — Single-rule (subset of A)** | Same table | `FristenrechnerService.CalculateRule` (around line 480) | POST `/api/tools/fristenrechner/calculate-rule` (Pathway B cascade card-click → inline calc). |
+| **C — Event-driven (youpc legacy)** | `paliad.trigger_events` + `paliad.event_deadlines` (separate tables) | `EventDeadlineService.Calculate(triggerEventID, triggerDate, courtID)` (`internal/services/event_deadline_service.go:92`) | POST `/api/tools/event-deadlines` (Pathway A wizard's "Was kommt nach…" trigger panel, `frontend/src/client/fristenrechner.ts:833`). |
+
+Pipelines A and C have **disjoint data**, **disjoint capability sets**, and **overlapping intent**. See §2 for the full picture; §6.1 calls out the redundancy.
+
+### 0.3 m's "it is all in the Rules so we should be able to manage" — the false premise
+
+The rule corpus IS in one table (`paliad.deadline_rules`) — 172 rows, 32 columns, expressive. **But there is no application-level rule-management surface.** Every rule edit today is a SQL migration: `internal/db/migrations/{009,012,028,029,031,040,043,044,050,068,…}_*.up.sql`. The Calculate engine reads what's in the table, but the table is seeded by developers, not by m or any user.
+
+m's "we should be able to manage" reads as a call for a first-class rule-editor in the app (see §8). That's the biggest unfilled deliverable in his framing.
+
+### 0.4 Production data is sparse — demand-side largely empty
+
+- **11/11 live projects have NULL `proceeding_type_id`** (per kelvin's t-paliad-178 §0 audit; re-confirmed). The projection pipeline (`projection_service.computeProjections:813`) early-returns when this is NULL, so the SmartTimeline forecast doesn't fire for any production project today.
+- **Only 1/26 live deadlines has `rule_id` populated.** The rule → deadline linkage is barely exercised. Most deadlines were created manually (free-text title + due_date) before the rule-anchored flow existed.
+- **89 project_events**: structural milestones + audit-log entries. No tight coupling to rule_ids today.
+- **trigger_events / event_deadlines** carry 110+77 youpc-legacy rows. Whether they are exercised in production needs Pathway-A "Was kommt nach…" telemetry; out of audit scope.
+
+### 0.5 Anchor files
+
+Backend services that consume / produce rules:
+- `internal/services/fristenrechner.go` — Pipeline A + B. The main calculator. **735 LoC.**
+- `internal/services/deadline_calculator.go` — pure date-math used by Pipeline C.
+- `internal/services/deadline_rule_service.go` — CRUD-ish read API. `List`, `GetRuleTree`, `Get`. Hydrates `ConceptDefaultEventTypeID` from `deadline_concept_event_types` for the create-form's Typ chip.
+- `internal/services/event_deadline_service.go` — Pipeline C. **~300 LoC.**
+- `internal/services/deadline_service.go` — persistence of `paliad.deadlines` instances.
+- `internal/services/event_category_service.go` — cascade leaf → concept resolution (t-paliad-133).
+- `internal/services/projection_service.go` — SmartTimeline (consumes Pipeline A).
+- `internal/services/holidays.go` + `courts.go` — non-working-day adjustment.
+
+Handlers:
+- `internal/handlers/fristenrechner.go` — wires Pipelines A/B/C to HTTP routes.
+- `internal/handlers/deadlines.go` — paliad.deadlines persistence.
+- `internal/handlers/deadline_rules_db.go` — admin-style rule list endpoint (read-only).
+
+Key migration history (rule corpus evolution):
+- **009** (342 LoC) — initial seed (Tier 1, hand-coded).
+- **012** (230 LoC) — Fristenrechner seed extension.
+- **028** (353 LoC) — youpc.org rules import (Pipeline C tables).
+- **029** (128 LoC) — Tier 1 rule fixes.
+- **031** (193 LoC) — Tier 2 ports (more proceedings).
+- **037 + 038** — concept layer addition.
+- **040** (449 LoC) — concept seed + backfill.
+- **043** (348 LoC) — DE_INF_OLG / DE_INF_BGH split (instance dimension).
+- **044** (280 LoC) — DPMA proceedings.
+- **048 + 049** — event_categories taxonomy (cascade).
+- **050** — `is_bilateral` backfill (4 rules).
+- **052** — Determinator ROP coverage audit fixes.
+- **068** — `is_optional` column.
+- **073 + 074** — `deadline_concept_event_types` (concept → event_type config layer).
+
+Net rule-related migrations: **>20 files, >3000 LoC of SQL.** The rule corpus has accreted across many small migrations; no single canonical seed.
+
+If anything in this audit conflicts with the live state, the live state wins.
+
+---
+
+## 1. The rule shape today — `paliad.deadline_rules` column-by-column
+
+**32 columns.** Most are used; a few are vestigial. Every column verified against live row distribution.
+
+### 1.1 Identity + relations
+
+| Column | Type | Nullable | Role |
+|---|---|---|---|
+| `id` | uuid PK | NO | Primary key. Referenced by `paliad.deadlines.rule_id`, `paliad.deadline_rules.parent_id` (self-FK), `paliad.deadline_rules.condition_rule_id` (self-FK; unused — see §1.6). |
+| `proceeding_type_id` | int FK → `proceeding_types.id` | YES | Almost always set; NULL would mean a cross-proceeding rule but **no live rule is NULL** today. |
+| `parent_id` | uuid self-FK | YES | Rule depends on parent's calculated date as anchor. **108 / 172 rules have parent_id set** (= 63%). Forms a forest, one tree per proceeding. |
+| `concept_id` | uuid FK → `deadline_concepts.id` | YES | Links the rule to a concept (cross-proceeding noun). **171 / 172 rules linked** (= 99.4%); the one un-linked rule is a stray. |
+
+### 1.2 Identity strings + labels
+
+| Column | Note |
+|---|---|
+| `code` | Rule-local code (e.g. `inf.sod`, `ccr.amend`). Used by `AnchorOverrides` map keys (rule_code → date). Mostly unique within a proceeding. |
+| `name` (NOT NULL) | DE display name. |
+| `name_en` (NOT NULL, default `''`) | EN display name. Empty for some older rules; UI falls back to `name`. |
+| `description` | Optional long-form. Sparse. |
+| `rule_code` | The *legal-citation* rule code (e.g. `RoP.23.1`, `§276(1) ZPO`). The UI shows this as the `RuleRef`. NOT the rule's identity — `code` is. |
+| `legal_source` | Structured citation (e.g. `UPC.RoP.23.1`). Added by mig 038 + 040. **171/172 rules have it.** |
+| `deadline_notes` / `deadline_notes_en` | Free-text legal-context notes shown in the UI. |
+| `spawn_label` | Used with `is_spawn=true`: human label for "spawned rule" pattern. |
+
+### 1.3 The math: anchor + offset + adjustment
+
+| Column | Note |
+|---|---|
+| `duration_value` (NOT NULL, default 0) | Integer offset. `0` = court-set / root anchor / filed-with-parent (see §4). |
+| `duration_unit` (NOT NULL, default `months`) | Live values: `days`, `months`, `weeks`. **No `working_days`** in live data (`EventDeadlineService` supports it; `deadline_rules` does not). |
+| `timing` (default `after`) | Live value: **only `after`** in every row. `before` semantic is theoretically there but unused by Pipeline A. (Pipeline C honours `before` via `applyDuration`.) |
+| `anchor_alt` | Single live value: `priority_date`. Used by exactly **one rule**: `EP_GRANT.ep_grant.publish` (Art. 93 EPÜ, 18mo from priority). Otherwise NULL → use parent's date / triggerDate. |
+| `alt_duration_value` / `alt_duration_unit` / `alt_rule_code` | Swap-on-flag: when condition_flag is satisfied, the rule renders against the alt values instead of base. Used by UPC_INF `inf.reply` and `inf.rejoin` for the with_ccr swap (RoP.029.a / RoP.029.d). |
+
+### 1.4 Conditional gating
+
+| Column | Note |
+|---|---|
+| `condition_flag` | `text[]` array. **4 distinct value-sets live**: `[with_amend]`, `[with_cci]`, `[with_ccr]`, `[with_ccr, with_amend]`. Only on UPC_INF + UPC_REV (the 2 richest proceedings). Semantics: rule renders iff **every** element of the array is in caller's `Flags` set. AND semantics; **no OR/NOT today**. |
+| `condition_rule_id` | uuid self-FK to another rule. **0 / 172 rows populated**. Dead column. Was intended as "rule X applies only if rule Y was triggered" but never wired up. |
+
+### 1.5 Party + bilateral
+
+| Column | Note |
+|---|---|
+| `primary_party` | Live values: `claimant`, `defendant`, `both`, `court`. Drives the timeline column / row color. NULL allowed. |
+| `is_bilateral` (NOT NULL, default false) | When `primary_party='both'`, this column tells the renderer whether to **mirror the rule into both party columns** in the timeline (true), or **resolve to one side via perspective + appeal_filed_by** (false). Backfilled by mig 050 — only 4 rules carry `true`: DE_NULL r79, DE_NULL r116, EPA_OPP r79, EPA_APP r116. |
+
+### 1.6 Flags + lifecycle
+
+| Column | Note |
+|---|---|
+| `is_mandatory` (NOT NULL, default true) | "User must address this." Surfaces in UI badge. |
+| `is_optional` (NOT NULL, default false) | Added by mig 068. **Distinct from is_mandatory** — semantics today: "the save-modal pre-unchecks these rows; the timeline still renders them." Live: e.g. UPC_INF `inf.cost_app` (RoP.151 Antrag auf Kostenentscheidung) — visible-but-defaulted-off. Naming is confusing (is_mandatory=true + is_optional=true would be self-contradictory); see §6.3. |
+| `is_spawn` (NOT NULL, default false) | Marks the rule as a "spawn" — emitted when its parent decision fires, but the spawn itself starts a NEW timeline branch (e.g. Appeal off Decision). Used by 8 live rules: APP/AMD/CCR cross-proceeding spawns. **Spawn execution is half-wired**: `projection_service.go:896-901` notes "Cross-proceeding spawn — the calculator can return rules from another proceeding type (Appeal off Decision). We don't have that rule in our map; skip the dependency annotation but still surface the row." — i.e. the row appears in the response but the dependency-annotation graph breaks. |
+| `is_active` (NOT NULL, default true) | Soft-delete. All 172 live rules have `is_active=true`; soft-delete unused so far. |
+| `sequence_order` (NOT NULL, default 0) | Calculator walks rules in this order. Must be consistent with topological order on `parent_id` (parents before children). |
+| `created_at` / `updated_at` | timestamps. |
+| `event_type` (text, nullable) | One of `decision`, `filing`, `hearing`, `order`. **A category, NOT an FK** to `paliad.event_types`. Distinct from concept-level event_type linkage in §3. |
+
+### 1.7 Vestigial / under-used
+
+- `condition_rule_id` — 0 rows populated. Dead column.
+- `description` — sparse, used as fallback notes.
+- `is_mandatory` vs `is_optional` — overlapping semantics that need a clean re-think (§6.3).
+
+---
+
+## 2. Trigger model today — events to deadlines
+
+There are **three parallel paths** from a user-observable event to a calculated deadline list. Understanding the redundancy is the most important takeaway of this audit.
+
+### 2.1 Path A — Proceeding-driven (the main spine)
+
+Caller: `/tools/fristenrechner` Pathway A (wizard), Pathway B B1 leaf click + B2 search, `ProjectionService.computeProjections` (SmartTimeline).
+
+Flow:
+1. User (or projection) picks a **proceeding_code** (e.g. `UPC_INF`) and a **trigger_date**.
+2. `FristenrechnerService.Calculate(proceedingCode, triggerDate, opts)` runs.
+3. Calculator loads `deadline_rules WHERE proceeding_type_id = $pt AND is_active`.
+4. Walks rules in `sequence_order`. For each:
+   - Apply `condition_flag` gate (suppress if flags missing AND alt_duration_value is NULL; otherwise swap to alt_*).
+   - Resolve anchor: `anchor_alt='priority_date'` → use priorityDate; else `parent_id` → parent's computed date; else triggerDate.
+   - Apply `AnchorOverrides[rule_code]` if user set an override.
+   - 4-bucket court-set classification (§4).
+   - Calculate offset, apply holiday/weekend adjustment via `HolidayService`, store in `computed[code]` map.
+5. Returns `UIResponse{Deadlines: []UIDeadline}` — the full timeline.
+
+Strengths:
+- Rich (condition flags, parent chains, anchor_alt, override map, court-set semantics).
+- Single source of truth for /tools/fristenrechner + SmartTimeline.
+- Backed by 172 rules across 27 proceedings.
+
+Weaknesses:
+- Returns the **whole proceeding** every call. No "give me only the rules triggered by event X" mode.
+- Cross-proceeding spawn (is_spawn rules) is half-wired (§1.6).
+- `condition_flag` is AND-only; no OR, NOT, or compound expression.
+
+### 2.2 Path B — Single-rule (subset of A)
+
+Caller: Pathway B cascade-card click → inline calc panel.
+
+Flow:
+1. User clicks a concept card; system picks the rule_id linked to that concept (via `event_category_concepts → deadline_rules`).
+2. POST `/api/tools/fristenrechner/calculate-rule` with `{rule_id, trigger_date, flags?}`.
+3. `FristenrechnerService.CalculateRule` walks the rule's parent chain only (no siblings), returns one `RuleCalculation`.
+
+Strengths:
+- Lightweight (no full-proceeding compute).
+- Lets the cascade UI surface "click → see this rule's date" without rebuilding the whole timeline.
+
+Weaknesses:
+- Doesn't include side-effects (sibling rules in the proceeding that the user might also care about).
+- Shares the same expressiveness limits as Path A.
+
+### 2.3 Path C — Event-driven (youpc legacy, redundant)
+
+Caller: Pathway A wizard's "Was kommt nach…" tab; `frontend/src/client/fristenrechner.ts:833` calls POST `/api/tools/event-deadlines`.
+
+Flow:
+1. User picks a **trigger_event** (e.g. "Klageerhebung UPC", "Berufungsschrift OLG", from a 110-row picker list).
+2. POST `/api/tools/event-deadlines` with `{triggerEventID, triggerDate, courtID}`.
+3. `EventDeadlineService.Calculate` loads `paliad.event_deadlines WHERE trigger_event_id = $te`.
+4. For each row: apply `duration_value × duration_unit (+ timing: before/after)`. Supports `working_days` unit (Path A doesn't). Handles `alt_duration_value × combine_op (min/max)` composite leads.
+5. Returns flat list of computed deadlines + rule_codes.
+
+Strengths:
+- Has the `before` timing semantic (Path A doesn't use it).
+- Has `working_days` unit (Path A doesn't have it).
+- Has `combine_op` (min/max) for composite duration math (Path A doesn't).
+- Trigger-event picker is more discoverable than "pick a proceeding": user says "Klageerhebung happened on date X, what comes after?" without first navigating to the proceeding tree.
+
+Weaknesses:
+- **Disjoint corpus.** The 77 `event_deadlines` rows do NOT join to `paliad.deadline_rules`. Changing a rule in Path A doesn't update Path C.
+- **No parent_id chains.** Each event_deadline is a single-leg calc off the trigger date. No multi-stage timelines.
+- **No condition flags.** No with_ccr / with_amend gating.
+- **No SmartTimeline integration.** ProjectionService only knows Path A.
+- **Origin:** youpc.org ported (mig 028). Implicitly "legacy", but actively wired.
+
+### 2.4 The concept layer (orthogonal to all three paths)
+
+`paliad.deadline_concepts` (56 rows) is the **noun layer** that lets the cascade + search talk about "Klageerwiderung" without knowing which of the 9 jurisdiction-specific Klageerwiderung rules it means. Every rule has `concept_id` (171/172); every cascade leaf has zero or more `event_category_concepts` rows linking to concepts (153 rows, 100 distinct leaves of 103 → 97% coverage).
+
+`paliad.deadline_concept_event_types` (32 rows, added mig 073/074) maps `(concept_id, jurisdiction) → event_type_id` so when the user creates a Deadline via the form by picking a Regel, the system can pre-fill the Typ chip with the canonical event_type. This is a **CONFIG layer, not a trigger model** — it doesn't say "when event X fires, these deadlines spawn." See §6.4.
+
+### 2.5 Multi-deadline triggers
+
+m's "specific events trigger specific deadlines, sometimes multiple" is implemented via **`parent_id` chains in Path A**. One root event (e.g. UPC_INF `inf.soc` = Klageerhebung) triggers a tree of dependent rules. Today the deepest live chain is **3 levels**:
+
+```text
+inf.soc (root, anchor)
+  ├─ inf.sod (3mo after, Klageerwiderung)
+  │    ├─ inf.def_to_ccr   ([with_ccr], 2mo after sod, Erwiderung auf CCR)
+  │    │    └─ inf.reply_def_ccr ([with_ccr], 2mo after, Replik auf Erwid CCR)
+  │    │         └─ inf.rejoin_reply_ccr ([with_ccr], 1mo after, Duplik)
+  │    ├─ inf.app_to_amend ([with_ccr,with_amend], 2mo after sod, Antrag Patentänderung)
+  │    │    ├─ inf.def_to_amend  ([with_ccr,with_amend], 2mo after, Erwiderung)
+  │    │    └─ inf.reply_def_amd ([with_ccr,with_amend], 1mo after Reply, Replik Amend)
+  │    ├─ inf.reply (with_ccr → 2mo after sod RoP.029.a; without_ccr → swap to alt)
+  │    └─ inf.rejoin (with_ccr → 1mo after reply RoP.029.d)
+  └─ inf.interim (court-set, Zwischenverfahren)
+       └─ inf.oral (court-set, Mündliche Verhandlung)
+            └─ inf.decision (court-set, Entscheidung)
+                 └─ inf.cost_app (1mo after decision, is_optional, Antrag Kostenentscheidung)
+```
+
+15 rules, 4 condition-flag-gated, 4 court-set placeholders (inf.interim / inf.oral / inf.decision are 0-duration court-set; inf.soc is 0-duration root), 1 optional. The structural fidelity is high.
+
+### 2.6 Conditional triggers — the AND-only ceiling
+
+`condition_flag` is `text[]` with **AND-of-array** semantic. To render the rule, every flag in the array must be in the caller's `Flags` set.
+
+Live flag space: `{with_amend, with_ccr, with_cci}` — three flags, four combinations used. The empty array is the unconditional default.
+
+This is enough to express:
+- "with counterclaim for revocation" (with_ccr alone)
+- "with counterclaim for revocation AND with amendment" (with_ccr + with_amend)
+- "with counterclaim for infringement" (with_cci alone)
+
+But not:
+- "with_ccr OR with_cci" — would need OR, today not supported. (Live workaround: duplicate rules with each gate.)
+- "NOT with_ccr" — also not supported.
+- Compound: "with_ccr AND NOT expedited".
+
+§6 flags this as a real coverage gap.
+
+---
+
+## 3. The 27 proceeding types — what's covered, what's a stub
+
+### 3.1 Inventory
+
+| Category | Code | Jurisdiction | Rule count | Notes |
+|---|---|---|---|---|
+| **fristenrechner** | DE_INF | DE | 9 | Verletzungsverfahren LG. |
+| | DE_INF_OLG | DE | 7 | Berufung OLG. |
+| | DE_INF_BGH | DE | 8 | Revision / NZB BGH. |
+| | DE_NULL | DE | 10 | Nichtigkeit BPatG. |
+| | DE_NULL_BGH | DE | 6 | Berufung BGH (Nichtigkeit). |
+| | DPMA_OPP | DPMA | 4 | DPMA Einspruch. |
+| | DPMA_BPATG_BESCHWERDE | DPMA | 5 | BPatG-Beschwerde nach DPMA. |
+| | DPMA_BGH_RB | DPMA | 4 | Rechtsbeschwerde BGH. |
+| | EPA_OPP | EPA | 8 | EPA Einspruch. |
+| | EPA_APP | EPA | 8 | EPA Beschwerde. |
+| | EP_GRANT | EPA | 7 | EP-Erteilung. One rule uses `anchor_alt='priority_date'`. |
+| | UPC_INF | UPC | **15** | Verletzung. Richest corpus. |
+| | UPC_REV | UPC | **15** | Nichtigkeit. Richest. |
+| | UPC_APP | UPC | 7 | Berufung UPC. |
+| | UPC_APP_ORDERS | UPC | 5 | Berufung gegen Anordnungen. |
+| | UPC_COST_APPEAL | UPC | 2 | Kostenberufung. |
+| | UPC_DAMAGES | UPC | 4 | Schadensbemessung. |
+| | UPC_DISCOVERY | UPC | 4 | Bucheinsicht. |
+| | UPC_PI | UPC | 4 | Einstweilige Maßnahmen. |
+| **litigation** | INF | UPC | 8 | Infringement. |
+| | REV | UPC | 7 | Revocation. |
+| | CCR | UPC | 7 | Counterclaim for Revocation. |
+| | APM | UPC | 4 | Provisional Measures. |
+| | APP | UPC | 8 | Appeal. |
+| | AMD | UPC | 2 | Application to Amend. |
+| | ZPO_CIVIL | DE | 4 | ZPO Civil. |
+
+Total: **172 rules across 27 proceeding types** (132 fristenrechner + 40 litigation).
+
+### 3.2 Litigation vs Fristenrechner — the dual-corpus problem
+
+The **same conceptual proceeding** (e.g. UPC Infringement) appears twice in `paliad.proceeding_types`:
+
+- `INF` (category=`litigation`) — 8 rules, generic UPC labels (Statement of Claim, Statement of Defence, Reply, Rejoinder, Oral Hearing, Interim Conference, Decision, Preliminary Objection).
+- `UPC_INF` (category=`fristenrechner`) — 15 rules, German labels + condition_flag variants.
+
+The brief calls this out as "two parallel vocabularies." Live confirms:
+
+- `paliad.projects.proceeding_type_id` accepts BOTH categories (no CHECK constraint enforces one or the other). Today all 11 projects are NULL anyway.
+- `FristenrechnerService.Calculate(proceedingCode, …)` is **category-agnostic** — pass it `INF` or `UPC_INF`, you get back the respective corpus's timeline. No category guard.
+- The Pathway-A wizard surfaces ONLY `category='fristenrechner'` codes (`internal/services/fristenrechner.go:735`: `WHERE category = 'fristenrechner' AND is_active = true`). So users can't pick `INF` from the wizard.
+- `ProjectionService.computeProjections` resolves `proj.ProceedingTypeID → code` and calls Calculate with whatever code is on the project. So a project with `INF` would render the 8-rule litigation timeline; a project with `UPC_INF` would render the 15-rule fristenrechner timeline.
+
+**This is a latent footgun.** Whichever code lands on a project first dictates which corpus drives its SmartTimeline. The two corpuses disagree on:
+- Rule count (8 vs 15).
+- Granularity (litigation has 1 ccr.defence row; fristenrechner has 7 with_ccr/with_amend gated rows).
+- Language (litigation labels are English; fristenrechner German).
+
+No code path treats this divergence intentionally. The likely intent at seed-time was:
+- `litigation` codes = "the project model's coarse type enum" (Mandant-level taxonomy).
+- `fristenrechner` codes = "the calculator's fine-grained variants".
+
+But the actual schema doesn't enforce that contract. **Flagged as §6.2.**
+
+### 3.3 Coverage observations
+
+- **UPC corpus dominates fristenrechner.** 9 of the 20 fristenrechner codes are UPC (66 rules); 5 are DE (40); 3 are DPMA (13); 3 are EPA (23). Bias matches HLC's mandate mix.
+- **DE_INF_OLG, DE_INF_BGH, DE_NULL_BGH** were split out late (mig 043). The instance dimension (LG / OLG / BGH) is NOT on `paliad.projects`, so you can't currently derive whether a DE project is at first instance, OLG, or BGH from the project model. This blocks fine-grained Akte → proceeding-code mapping (cross-referenced in t-paliad-166 §4.2).
+- **EP_GRANT** is the only proceeding that uses `anchor_alt`. Other priority-date-anchored rules don't exist (yet).
+- **UPC_REV.with_cci** — the [with_cci] flag is used for "revocation action with counterclaim for infringement" — i.e. when the defendant in a revocation files a CCI. Only UPC_REV uses with_cci today (4 rules).
+
+### 3.4 Concept linkage gaps
+
+9 of 56 deadline_concepts have `rule_count = 0` — i.e. cascade-reachable concepts that produce zero calculated deadlines:
+
+| Concept slug | Why it's empty |
+|---|---|
+| `counterclaim-for-revocation` | The CCR flow is modelled inside UPC_INF via `[with_ccr]` flag-gated rules, not as a separate concept-linked rule. |
+| `schriftsatznachreichung` | ZPO §296a "Schriftsatznachreichung" — cross-cutting concept, no rule encoding yet. |
+| `versaeumnisurteil-einspruch` | ZPO §339 "Einspruch gegen Versäumnisurteil" — no rule. |
+| `weiterbehandlung` | EPA Art. 121 EPÜ / R.135 — no rule. |
+| `wiedereinsetzung` | Re-establishment of rights — cross-cutting; no rule. |
+| `notice-of-defence-intention` | DE ZPO Verteidigungsanzeige — only ZPO_CIVIL has it; not linked. |
+| Plus 3 more sparse concepts. | |
+
+For each, the cascade can route the user to the concept card, but the card has no rule pills underneath. This is a real coverage gap surfaced as §6.
+
+---
+
+## 4. Anchor semantics — the 4-bucket model
+
+Encoded in `fristenrechner.go:272-369`. For each rule with `duration_value = 0`:
+
+| Bucket | parent_id | court-determined? | Behaviour |
+|---|---|---|---|
+| **1. Root anchor** | NULL | no | Due date = trigger date. `IsRootEvent=true`. The proceeding's "day zero" (e.g. SoC filing). |
+| **2. Court-set absolute** | NULL | yes | Due date empty; UI shows "wird vom Gericht bestimmt". `IsCourtSet=true, IsCourtSetIndirect=false`. Used for top-level hearings / decisions that don't follow from another rule. |
+| **3. Court-set chained** | set | yes | Due date empty (court determines); ancestor anchor. `IsCourtSet=true`. Used for derivative court actions. |
+| **4. Filed-with-parent** | set | no | Inherits parent's calculated date. Used for "X is bundled into Y" (e.g. UPC_REV.rev.app_to_amend, rev.cc_inf — included in the Defence to revocation). |
+
+For rules with `duration_value > 0`:
+
+- **Override wins.** `AnchorOverrides[rule_code]` provided by user → use it; mark `IsOverridden=true`.
+- **Parent court-set + no override** → mark `IsCourtSet=true, IsCourtSetIndirect=true`. The rule isn't directly court-determined, but its anchor (the court-set parent) hasn't been bound yet. UI shows "unbestimmt".
+- **Otherwise:** baseDate = (anchor_alt=priority_date → priorityDate) || (parent_id → computed[parent.code]) || triggerDate. Add `duration_value × duration_unit`. Apply holiday adjustment. Done.
+
+**Court-set detection** (`isCourtDeterminedRule` in calculator) keys on:
+- `primary_party='court'`, OR
+- `event_type ∈ {'hearing','decision','order'}`, OR
+- Heuristic name match (legacy from migration 028).
+
+This is brittle — the boolean is computed from columns that aren't strictly designed for it. §6.5 suggests promoting a real `is_court_set` column.
+
+### 4.1 `AnchorOverrides` — the override map
+
+The override surface is the bridge between "calculated forecast" and "real ground truth." Two consumers:
+- **SmartTimeline (`ProjectionService.collectActualsForOverrides`)** — bind a real `paliad.deadlines` row's date back into the calculator: if a saved deadline has `rule_id=X` and `completed_at='2026-04-10'`, the next projection uses 2026-04-10 as the anchor for any rule whose parent is X.
+- **Pathway A wizard "Anchor edits"** — the user can override a per-rule date inline in the timeline (paliad-088 era feature). Applies to court-set rules where the user finally knows the decision date.
+
+The override map propagates **downstream**: child rules see the override as their parent's date.
+
+This is a strong, well-implemented mechanism. No gap.
+
+---
+
+## 5. Adjustment semantics — weekends, holidays, court calendars
+
+### 5.1 `HolidayService.AdjustForNonWorkingDaysWithReason(endDate, country, regime)`
+
+Called after every offset computation. Returns `(adjusted, _, wasAdjusted, reason)`.
+
+- If endDate is a weekend → roll to next Monday. Reason: `kind=weekend, original_weekday`.
+- If endDate is a public holiday (region match in `paliad.holidays`) → roll to next business day. Reason: `kind=public_holiday, holidays=[…]`.
+- If endDate is inside a court vacation (regime-specific date range) → roll to first non-vacation business day. Reason: `kind=vacation, vacation_name, vacation_start, vacation_end`.
+
+Live `paliad.holidays`: **55 rows**, mix of public holidays and vacation periods. `region` axis covers DE federal + state-specific + UPC court-specific.
+
+### 5.2 `CourtService.CountryRegime(courtID, defaultCountry, defaultRegime)`
+
+`paliad.courts` (41 rows) carries `country` and `regime` per court. Defaults via jurisdiction:
+- UPC-flavoured proceedings → DE+UPC (UPC München is the default venue).
+- DE proceedings → DE.
+- EPA / DPMA → DE.
+
+Live regimes inferred from queries: DE state codes (BY, BW, …), UPC court-specific tags. No formal CHECK constraint listing valid regimes.
+
+### 5.3 Working-day arithmetic — split between calculators
+
+Pipeline C (`EventDeadlineService.addWorkingDays`) supports `duration_unit='working_days'`: step forward N business days, skipping weekends + holidays.
+
+Pipeline A (`FristenrechnerService`) does NOT support working_days; only calendar days/weeks/months. Adjustment is post-hoc (compute the calendar date, then roll forward if it lands on a non-business day).
+
+**The two calculators are not equivalent.** Some real-world deadlines are "10 working days after Z" — those can only be expressed in Pipeline C today. Cross-references §6.6.
+
+---
+
+## 6. Coverage gaps (the heart of the audit)
+
+What m's mental model wants ("specific events trigger specific deadlines, sometimes multiple, sometimes conditional") that the data model cannot express today.
+
+### 6.1 Two trigger systems — Pipeline A vs Pipeline C
+
+**Symptom.** Two disjoint data corpuses (`deadline_rules` 172 vs `trigger_events`+`event_deadlines` 110+77) with overlapping intent. A change to a rule in Pipeline A doesn't propagate to Pipeline C. The user-facing "Was kommt nach…" tab (Pipeline C) renders different numbers than the wizard timeline (Pipeline A) for nominally-similar trigger events.
+
+**Impact.** Pipeline C has capabilities Pipeline A lacks (`before` timing, `working_days` unit, `combine_op` min/max) — but no parent chains, no condition_flag, no court-set semantic. Choosing the "right" pipeline today means picking which subset of capabilities the user actually needs for that case.
+
+**Root cause.** Pipeline C is a youpc.org port (mig 028). Pipeline A is paliad-native (mig 009 → 050 evolution). They were never reconciled.
+
+### 6.2 Litigation vs fristenrechner corpus drift
+
+**Symptom.** `paliad.projects.proceeding_type_id` accepts both `litigation` and `fristenrechner` codes. The same conceptual proceeding has rule corpuses of different size, granularity, and language depending on which category the project lands on.
+
+**Impact.** SmartTimeline forecast for a project depends on which code is chosen at project-create time. Two HLC partners filing identical UPC infringement cases could see different timelines if one picked `INF` and the other `UPC_INF`.
+
+**Root cause.** No CHECK constraint, no documentation, no UI guard. Likely intent: `litigation` for project-model coarse classification, `fristenrechner` for fine-grained calculator — but the contract was never formalised.
+
+### 6.3 `is_mandatory` vs `is_optional` semantic overlap
+
+**Symptom.** Two boolean columns with overlapping meaning. Current usage:
+- `is_mandatory=true, is_optional=false` — default (most rules).
+- `is_mandatory=true, is_optional=true` — surfaces in timeline but pre-unchecked in save-modal (only UPC_INF.inf.cost_app + a few others).
+- `is_mandatory=false` — unclear semantics today; sparsely used.
+
+**Impact.** Confusing for both developers and future rule authors. A rule with `is_mandatory=false, is_optional=true` (legal "may file but not required") versus `is_mandatory=true, is_optional=true` (legal "should file but isn't a hard deadline") versus `is_mandatory=true, is_optional=false` (legal "must file") — the four-way matrix isn't well-defined.
+
+**Root cause.** `is_optional` was added late (mig 068) as a UX hack ("pre-uncheck in save modal") rather than a semantic axis.
+
+### 6.4 `deadline_concept_event_types` is a config layer, not a trigger model
+
+**Symptom.** The table maps `(concept, jurisdiction) → event_type` for the create-form's chip suggestion. It DOES NOT support "when an event of type X fires, spawn deadlines for these rules."
+
+**Impact.** m's "specific events trigger specific deadlines" implies a directional pipeline: user logs an event → system computes the deadlines that flow from it. That pipeline today exists only via:
+- Pipeline A's full-proceeding compute (heavy: gives everything, not just X's children).
+- Pipeline C's trigger_event picker (decoupled corpus).
+
+There's no event_type-keyed entry point into Pipeline A. The cascade gets close — leaf → concept → rules — but stops at "show the cards"; firing the rules requires the user to manually click a card → calculate-rule.
+
+**Root cause.** Pipeline A was designed proceeding-first (mig 009, 2024). The event-first paradigm came later via concepts (mig 037+) but never produced a dedicated trigger endpoint.
+
+### 6.5 Court-set detection is heuristic
+
+**Symptom.** `isCourtDeterminedRule()` decides court-set status from `primary_party='court' OR event_type IN ('hearing','decision','order') OR name-heuristic`. No dedicated boolean column.
+
+**Impact.** False positives possible if a rule names "decision" but isn't court-set (e.g. "preliminary decision to amend"). False negatives possible if a court-set rule isn't tagged with one of these signals.
+
+**Root cause.** Court-set semantic was never formalised as a first-class column. Inferred at runtime.
+
+### 6.6 Pipeline A lacks `before`, `working_days`, `combine_op`
+
+**Symptom.** Specific gaps in expressive power:
+- `before` timing: useful for "must be filed Y days BEFORE oral hearing." Pipeline C honours `timing='before'`; Pipeline A only renders `timing='after'` rules.
+- `working_days` unit: useful for procedural deadlines like UPC R.220.3 ("3 working days from notification"). Pipeline C supports it; Pipeline A doesn't.
+- `combine_op` (min/max): useful for "earlier of X or Y" (compound deadlines, e.g. EPC R.36 — "shortest of priority date+24mo or filing date+18mo"). Pipeline C supports it; Pipeline A doesn't.
+
+**Impact.** Some legal deadlines can only be expressed in Pipeline C, fragmenting the rule corpus.
+
+**Root cause.** Pipeline A grew from a "tree of forward offsets" model; backward / composite deadlines weren't anticipated.
+
+### 6.7 Condition-flag grammar is AND-only
+
+**Symptom.** `condition_flag` is `text[]` with AND semantics. No OR, no NOT, no nested expression.
+
+**Impact.** Real legal scenarios that need OR (e.g. "rule X applies if CCR OR CCI is filed") get encoded as **two duplicate rules** today — one for each branch. Painful to maintain; easy to drift.
+
+**Root cause.** The flag axis was designed for the small set of UPC variant flags (`with_ccr`, `with_amend`, `with_cci`); compound expressions weren't anticipated.
+
+### 6.8 Cross-proceeding spawn is half-wired
+
+**Symptom.** `is_spawn=true` rules exist (8 live), intended to express "when X happens in proceeding A, also trigger Y in proceeding B." The calculator code at `projection_service.go:896-901` explicitly notes: "Cross-proceeding spawn … We don't have that rule in our map; skip the dependency annotation but still surface the row."
+
+**Impact.** A UPC_INF decision firing an APP proceeding (cross-proceeding) renders the spawned row, but the dependency-graph annotation breaks. SmartTimeline can't fully chain across proceedings.
+
+**Root cause.** Cross-proceeding spawn was a late addition; the calculator's `ruleByID` map is per-proceeding, so it can't resolve spawns from other proceedings. Needs either a global rule index or a smarter resolver.
+
+### 6.9 Nine orphan concepts with `rule_count=0`
+
+Per §3.4: `counterclaim-for-revocation`, `schriftsatznachreichung`, `versaeumnisurteil-einspruch`, `weiterbehandlung`, `wiedereinsetzung`, `notice-of-defence-intention`, plus 3 more.
+
+**Impact.** Cascade leaves can reach these concepts, but the user sees an empty result card. UX feels broken even though it's an unrelated coverage gap (no rules seeded yet).
+
+**Root cause.** Cascade taxonomy was seeded ahead of the rule corpus for some concepts. The seed work never caught up.
+
+### 6.10 No way to express "X is conditional on Y having fired"
+
+**Symptom.** `condition_rule_id` exists as a column but is 0% populated. Was intended for "rule X applies only if rule Y was previously triggered" but never wired.
+
+**Impact.** Today's flag mechanism (condition_flag) gates on **caller-supplied flags** (e.g. user toggles "with_ccr" in the UI). It doesn't gate on **runtime rule firing**. So you can't express "if the defendant filed Preliminary Objection (rule X), then rule Y is suspended for 2mo."
+
+**Root cause.** Column added speculatively; never wired into the calculator.
+
+### 6.11 The instance dimension (LG/OLG/BGH) isn't on `paliad.projects`
+
+**Symptom.** The proceeding_types `DE_INF_OLG` / `DE_INF_BGH` exist, but a project can't carry "I'm at first instance" / "I'm on appeal at OLG" as data. The user has to manually pick a different `proceeding_type_id` if the case moves up the instances.
+
+**Impact.** SmartTimeline forecast can't auto-advance from DE_INF → DE_INF_OLG when a Berufungsschrift fires on the actuals side.
+
+**Root cause.** Project model treats proceeding-type as a static attribute, not a state machine.
+
+### 6.12 No rule audit log
+
+**Symptom.** Rules are modified by SQL migrations only. There's no `paliad.deadline_rule_audit` table tracking "rule X changed from 3mo to 2mo on 2026-04-15 by m, because Y." Migrations are technically the audit trail, but they aren't queryable in-app.
+
+**Impact.** Rule-management UX (§8) needs an answer for "who changed this rule and why." Without an audit trail, rule-editing in-app is a step backward in compliance.
+
+**Root cause.** Never needed before, because rules were never user-editable.
+
+### 6.13 Zero deadline → rule linkage in live data
+
+**Symptom.** Only **1 of 26** live deadlines has `rule_id` populated.
+
+**Impact.** SmartTimeline's "anchor real deadlines into projection" feature (Pipeline A's strongest UX) is unusable on existing data. New deadlines saved via the wizard *do* get rule_id; legacy deadlines don't.
+
+**Root cause.** Schema migrated incrementally; backfill never happened.
+
+---
+
+## 7. Extension proposals (one concrete change per §6 gap)
+
+Each gap from §6 gets a concrete schema / service change, costed (migration + service + UI ripples).
+
+### 7.1 Reconcile Pipelines A and C
+
+**Proposal.** Migrate `paliad.event_deadlines` into `paliad.deadline_rules` with a new column `trigger_event_id` (nullable FK to `paliad.trigger_events`). A rule with `trigger_event_id NOT NULL` is event-triggered (Pipeline C semantics); with NULL it stays proceeding-triggered (Pipeline A).
+
+Add the Pipeline-C-only columns to `deadline_rules`:
+- `timing` already exists; backfill non-NULL `before` values.
+- `combine_op` ∈ `{min, max, NULL}` — new column.
+- `working_days` as a valid `duration_unit` value — already a string column, no schema change.
+
+Then deprecate Pipelines C, redirecting `/api/tools/event-deadlines` to the unified calculator.
+
+**Cost.**
+- Migration: 1 file, ~120 LoC SQL (column adds + data move + idx).
+- Service: `FristenrechnerService.Calculate` extends to honour `timing='before'`, `working_days`, `combine_op`. ~80 LoC Go.
+- Service: `EventDeadlineService` either deletes (clean) or proxies to FristenrechnerService (transitional).
+- Handler: `/api/tools/event-deadlines` either deletes or 302s.
+- Frontend: `client/fristenrechner.ts:833` — the "Was kommt nach…" tab can call the unified endpoint.
+- Tests: a fresh table-driven test fixture covers the union behaviour.
+
+**Ripple.** No data loss; trigger_event_id is additive. Frontend mostly transparent.
+
+### 7.2 Formalise litigation vs fristenrechner contract
+
+**Proposal.** Two options:
+- **(a) Hard-split.** Add `CHECK constraint` to `paliad.projects.proceeding_type_id`: only `category='litigation'` codes allowed. Migrate the 8-rule litigation corpus to be the canonical "project-level proceeding type". Move the fine-grained `category='fristenrechner'` rules under each litigation code via a new `variant` column.
+- **(b) Soft-merge.** Drop the `category` discriminator entirely. Every proceeding_type carries its full rule corpus. The dual-corpus today (8-rule INF + 15-rule UPC_INF) merges into ONE 15-rule UPC_INF, with the project model referencing only the rich variant.
+
+**Cost.** (a) is invasive — migration to move 40 litigation-corpus rules under the fristenrechner codes; (b) is less invasive but means projects switch to picking `UPC_INF` instead of `INF`.
+
+**Recommendation.** **(b)**. The dual-corpus is legacy from a project-model + calculator-model that grew separately. One canonical proceeding_type per case is cleaner.
+
+**Ripple.** Project-create form picker changes from "INF / REV / CCR / APM / APP / AMD / ZPO_CIVIL" to the full 20-code fristenrechner picker (or a curated subset). t-paliad-166's mapping helper becomes unnecessary.
+
+### 7.3 Clean up `is_mandatory` vs `is_optional`
+
+**Proposal.** Replace both with a single `deadline_kind` enum:
+- `mandatory` — must be addressed.
+- `recommended` — should be addressed (pre-checked in save-modal but not required).
+- `optional` — may be addressed (pre-unchecked in save-modal).
+- `informational` — never saves as a deadline, surfaces as info.
+
+Backfill: `is_mandatory=true, is_optional=false → mandatory`; `is_mandatory=true, is_optional=true → optional`; `is_mandatory=false → recommended`.
+
+**Cost.** Migration ~30 LoC SQL. Service: `UIDeadline` exposes `Kind` instead of `IsMandatory`+`IsOptional`. Frontend: badge logic + save-modal pre-check.
+
+### 7.4 Add a real event-driven trigger endpoint
+
+**Proposal.** `POST /api/tools/event-trigger` with `{event_type_slug, trigger_date, project_id?}`. Resolves:
+1. `event_types.slug → event_types.id`
+2. `deadline_concept_event_types.event_type_id → concept_id` (per jurisdiction from project or explicit)
+3. `deadline_rules.concept_id → rules`
+4. Calculate the rules + their parent chains via Pipeline A.
+
+Returns just the rules that flow from this event (filtered Pipeline A response).
+
+**Cost.** Handler + service method, ~100 LoC. No schema change; uses existing junction.
+
+**Ripple.** Lets the cascade UI offer "I just logged this event — here are the deadlines that follow" in one click. Also unlocks Phase-H-style email parsing → deadline spawn.
+
+### 7.5 Promote court-set to a real column
+
+**Proposal.** Add `is_court_set boolean NOT NULL DEFAULT false` to `paliad.deadline_rules`. Backfill from the heuristic. Calculator reads the column instead of inferring.
+
+**Cost.** Migration ~20 LoC SQL (incl. backfill DO$$ block). Service: 1-line change in `isCourtDeterminedRule`.
+
+**Ripple.** Faster + correct + no behaviour surprise. Cheap win.
+
+### 7.6 Pipeline A gains `before` / `working_days` / `combine_op`
+
+Covered in §7.1 (reconciliation).
+
+### 7.7 Compound condition grammar
+
+**Proposal.** Replace `condition_flag text[]` with `condition_expr jsonb`. Schema:
+
+```json
+{"op":"and", "args":[{"flag":"with_ccr"},{"op":"not","args":[{"flag":"expedited"}]}]}
+```
+
+Backfill: `['with_ccr','with_amend']` → `{"op":"and","args":[{"flag":"with_ccr"},{"flag":"with_amend"}]}`.
+
+**Cost.** Migration with backfill ~80 LoC. Service: small recursive evaluator (~50 LoC Go). UI: condition picker for rule-editor (§8) — more involved.
+
+**Ripple.** Future rule authors can express OR / NOT cleanly. No data drift; backward-compatible eval.
+
+### 7.8 Wire cross-proceeding spawn
+
+**Proposal.** Change `DeadlineRuleService.List(proceedingTypeID *int)` to allow a "follow spawn" mode that returns rules from spawned proceedings as well. Or: in `projection_service.computeProjections`, when a rule has `is_spawn=true` and the calculator returns a row from a different proceeding code, load the target proceeding's rule corpus lazily.
+
+**Cost.** Service: ~50 LoC. Calculator: ~30 LoC. Risk: cycle prevention (don't infinite-loop A→B→A).
+
+**Ripple.** SmartTimeline can fully chain across proceedings. The dependency-annotation breakage at `projection_service.go:896-901` resolves.
+
+### 7.9 Seed the 9 orphan concepts with rules
+
+**Proposal.** Per concept, add 1–3 rules to the appropriate proceeding_types. e.g. `wiedereinsetzung` → UPC R.320.1 (`UPC_INF.wiedereinsetzung`), EPA R.136 (`EPA_OPP.wiedereinsetzung`), DE PatG §123 (`DE_INF.wiedereinsetzung`).
+
+**Cost.** Per orphan concept: ~20 LoC SQL. Total ~150 LoC across 9 concepts. Legal review required per rule.
+
+**Ripple.** Cascade no longer dead-ends. This is the "coverage" gap m's t-paliad-167 explicitly called for.
+
+### 7.10 Wire `condition_rule_id` or drop it
+
+**Proposal.** Either:
+- (a) Implement: when calculator walks rules, gate a rule's render on `condition_rule_id`'s presence in the `computed` map.
+- (b) Drop the dead column.
+
+**Recommendation.** **(b)**. The semantic is rarely needed; `condition_flag` covers most variant cases. Future need can resurrect.
+
+### 7.11 Add `instance_level` to `paliad.projects`
+
+**Proposal.** New column `instance_level text` ∈ `{first, appeal_olg, appeal_bgh, NULL}`. Combined with `proceeding_type.code` + `jurisdiction`, lets us derive `DE_INF_OLG` vs `DE_INF` from a project.
+
+**Cost.** Migration ~10 LoC SQL. Project form: new picker. SmartTimeline forecast: small refactor in `proceedingCodeForProject`.
+
+### 7.12 Rule audit log
+
+**Proposal.** New table `paliad.deadline_rule_audit (id, rule_id, changed_by, changed_at, before_json, after_json, reason text)`. Trigger on UPDATE/INSERT/DELETE captures the diff. Required if §8 lands.
+
+**Cost.** Migration ~40 LoC SQL (table + trigger). Read API for compliance review.
+
+### 7.13 Backfill `rule_id` on existing deadlines
+
+**Proposal.** One-time migration: for each `paliad.deadlines` row, fuzzy-match `title` against `paliad.deadline_concepts.aliases` + `paliad.deadline_rules.name`, link the highest-confidence match, leave low-confidence unlinked.
+
+**Cost.** Migration ~100 LoC SQL. Run once.
+
+**Ripple.** SmartTimeline anchor-from-actuals starts working for existing data. Bigger UX win than it sounds.
+
+---
+
+## 8. Rule-management UX — does m need an in-app rule editor?
+
+m's "all in the Rules so we should be able to manage" reads as a direct ask.
+
+### 8.1 The case for an in-app rule editor
+
+- **Today: SQL migration only.** Every rule add/edit/disable requires a developer to write a migration, get reviewed, merge, deploy. The feedback loop is hours-to-days.
+- **Domain experts ≠ developers.** m is the rule expert. He shouldn't need to write `INSERT INTO paliad.deadline_rules (proceeding_type_id, code, name, duration_value, …)` SQL.
+- **Coverage gaps are persistent** (§3.4, §6.9). They stay open longer because the workflow is high-friction.
+- **Real-world law changes.** Procedural rules update (e.g. UPC R.49 just had a 2026-Q1 revision). Capturing those in SQL migrations is fragile.
+
+### 8.2 The case against
+
+- **Compliance / audit.** Rules are legal infrastructure. Any user-edit must be auditable, reviewable, reversible.
+- **Schema complexity.** 32 columns with semantic nuances (court-set heuristic, parent_id topology, condition_flag grammar). Naive form UI = footgun heaven.
+- **Cross-rule validation.** parent_id chains must remain DAGs. sequence_order must be topologically consistent. condition_flag values must be in a valid vocabulary. No live constraint catches all of these today.
+- **Build cost.** A real rule-editor with audit log, validation, preview, dry-run, and rollback is 4–6 PRs of work.
+
+### 8.3 Three options
+
+| Option | Description | Effort | When right |
+|---|---|---|---|
+| **(A) Status quo: SQL only** | Keep migrations as the rule-edit surface. Build tooling around migration authoring (mAi-assisted SQL gen, schema validators). | Low (~1 sprint of tooling). | If m's rule velocity is < 1 edit/week and audit trail is non-negotiable. |
+| **(B) Read-only admin surface** | Add `/admin/rules` page that lists rules, lets m search/filter/inspect. No edits in-app; "edit this rule" links to a Gitea issue template that drafts the migration. | Medium (~1 PR backend listing + 1 PR frontend). | If the friction is "I can't see what's in there" more than "I can't change what's there". |
+| **(C) Full rule editor** | `/admin/rules/{id}/edit` with form, validation, audit log, preview-on-trigger-date, "ship draft" → migration generator. | High (~4-6 PRs). | If m is genuinely going to edit rules weekly and the rule corpus is going to grow significantly. |
+
+### 8.4 Inventor recommendation
+
+**Start with (B), graduate to (C).**
+
+- (B) immediately removes the "I can't see what's in there" friction, which today requires running SQL by hand or asking a developer. Low risk.
+- (B) makes the rule corpus discoverable inside the app — which is itself a win for transparency and for spotting coverage gaps (§3.4).
+- The Gitea-issue handoff preserves the audit trail and review workflow.
+- Once the corpus is browsable, the "I keep wanting to edit this thing" pressure tells us whether (C) is worth building.
+- **(C) without (B) is over-engineering** — we'd be building the form before we know which fields are actually edited often.
+
+Hard requirement for (C) if we get there: `paliad.deadline_rule_audit` table (§7.12) with mandatory `reason` field, reviewer workflow, and migration-export so changes still land in version control.
+
+§9 Q5 surfaces this for m's call.
+
+---
+
+## 9. Open questions for m (Phase 2 steering)
+
+These are the 10–15 picks for m to make before Phase 2 starts.
+
+**Q1 — Reconciliation of Pipelines A and C.** §6.1 + §7.1. Three options:
+- (a) Merge into one table (recommended; ~120 LoC migration + 80 LoC Go).
+- (b) Keep both but document the contract (cheap, but the drift continues).
+- (c) Deprecate Pipeline C entirely (deletes "Was kommt nach…" tab — UX loss).
+
+**Q2 — Litigation vs fristenrechner corpus.** §6.2 + §7.2. Two options:
+- (a) Hard-split with CHECK constraint + rule migration (invasive).
+- (b) Soft-merge: drop the category discriminator, projects use fristenrechner codes only (recommended).
+
+**Q3 — `is_mandatory` / `is_optional` cleanup.** §6.3 + §7.3. Pick the 4-value enum (`mandatory` / `recommended` / `optional` / `informational`) or keep the two booleans with formal docs.
+
+**Q4 — Event-driven trigger endpoint.** §6.4 + §7.4. Build `POST /api/tools/event-trigger` (concept-keyed) now, or defer until rule corpus is reconciled?
+
+**Q5 — Rule-management UX.** §8. Pick:
+- (A) status quo SQL only,
+- (B) read-only admin surface (recommended start),
+- (C) full editor with audit log.
+
+**Q6 — Compound condition grammar.** §6.7 + §7.7. Move to `condition_expr jsonb` with AND/OR/NOT, or stay with `condition_flag text[]` AND-only and live with duplicate rules?
+
+**Q7 — Cross-proceeding spawn.** §6.8 + §7.8. Wire it (let SmartTimeline chain across proceedings), or accept the current half-wired state?
+
+**Q8 — Orphan concept seed.** §3.4 + §7.9. Priority order for the 9 missing-rule concepts? My guess: wiedereinsetzung > schriftsatznachreichung > versaeumnisurteil > weiterbehandlung > others. Legal review per concept.
+
+**Q9 — Instance level on `paliad.projects`.** §6.11 + §7.11. Add `instance_level` column to support the DE_INF / DE_INF_OLG / DE_INF_BGH ladder, or accept that users manually re-pick proceeding_type on appeal?
+
+**Q10 — Backfill `rule_id` on existing deadlines.** §6.13 + §7.13. Run the one-time fuzzy-match migration, or live with the broken anchor-from-actuals on legacy rows?
+
+**Q11 — `working_days` and `before` semantics in Pipeline A.** §5.3 + §6.6. Add (recommended) or live without them?
+
+**Q12 — Court-set as a real column.** §6.5 + §7.5. Promote (cheap win), or keep the heuristic?
+
+**Q13 — Drop `condition_rule_id` dead column.** §1.6 + §7.10. Drop or wire?
+
+**Q14 — Phase 2 cadence.** How should we structure the iterative refinement? Options:
+- (a) m drives via the worker pane — m raises concrete cases ("counterclaim with amendment in expedited proceedings"), worker proposes encoding, commits incrementally.
+- (b) Inventor (pauli) drafts a Phase 2 design for the §7 extensions in priority order m picks here, m gates.
+- (c) Mixed: m picks the top 2 from §9 (Q1–Q13) for Phase 2, the rest deferred to Phase 3.
+
+**Q15 — Phase 3 framing.** Once Phase 2 lands the data-model changes, is the goal:
+- (a) Build the rule editor (§8 option C), or
+- (b) Backfill coverage gaps (§7.9), or
+- (c) Wire SmartTimeline cross-proceeding chains (§7.8), or
+- (d) Some other priority m has in mind?
+
+---
+
+## AUDIT READY FOR REVIEW
+
+Awaiting m's go/no-go on §9 Q1–Q15 before Phase 2 starts. Inventor (pauli) parks after this commit — no implementation kickoff, no other-skill autoload, m gates the audit → Phase 2 transition.
+
+Recommended Phase 2 worker: depends on m's Q14 pick. If (a) interactive pair-prog, then pauli or feynman. If (b) inventor design pass, pauli has the freshest context. If (c) mixed, pauli for design, hand off to a Sonnet coder for each landed extension. **NOT cronus per memory directive 2026-05-06.**

docs/design-approval-suggest-changes-2026-05-19.md

@@ -0,0 +1,332 @@
+# Design — "Suggest changes" action on approval flow
+
+**Author:** hertz (inventor)
+**Date:** 2026-05-19
+**Task:** t-paliad-216 (m/paliad in-flight)
+**Branch:** `mai/hertz/inventor-suggest-changes`
+**Status:** DESIGN — open questions await m before any coder shift.
+
+---
+
+## 0. TL;DR
+
+Add a fourth action **"Änderungen vorschlagen"** ("Suggest changes") to the approval flow, alongside Approve / Reject / Revoke. Use case: the approver doesn't want to accept the proposed change as-is, but doesn't want to reject outright — they edit the proposed values into a counter-proposal and submit it back into the same approval flow.
+
+**Mental model (m, 2026-05-19):** suggest-changes is not "ping the requester to fix it" — it's the approver **authoring a counter-proposal** that gets re-injected into the approval flow as a fresh `pending` row. The original requester (now potentially an eligible approver of the counter, since they're no longer the requested_by) sees:
+- the **old row** in their /inbox as `changes_requested` ("Abgelehnt mit Vorschlag" / "Declined with changes") — historical record of their original attempt;
+- the **new row** in /inbox as `pending` — the counter, which they can approve, reject, revoke (n/a, not theirs), or suggest changes back on. Everyone else eligible sees the new row too. 4-Augen still holds: the counter's requested_by (the approver who suggested it) cannot self-approve.
+
+Click flow:
+1. Approver opens an editable modal on the pending row showing the requester's proposed values. Edits any field. Writes a free-text note ("Bitte den Termin um 9:00 statt 8:00, weil der Raum sonst kollidiert").
+2. POST `/api/approval-requests/{id}/suggest-changes` with `{note, counter_payload}`.
+3. Server, in one tx: closes the old row (`changes_requested`, `decision_note=note`), reverts the entity from `pre_image`, then immediately inserts a **new** `pending` approval_requests row authored by the approver with `payload=counter_payload`, re-applies the counter to the entity, marks `pending_request_id` to the new row, emits two events (`*_approval_changes_suggested` + `*_approval_requested`). `previous_request_id` FK links new → old for chain traversal.
+
+The pending audience for the new row is the same as any fresh `Submit*` — the existing notification + visibility plumbing handles it without special-casing.
+
+---
+
+## 0a. m's decisions (2026-05-19)
+
+| # | Header | m picked | Reasoning note (when different from recommendation) |
+|---|---|---|---|
+| Q1 | State machine | **(a) New status `changes_requested`.** | As recommended. |
+| Q2 | Entity state | **(a) Reverts to pre_image, same as Reject.** | As recommended. The counter is then re-applied in the same tx by the new approval row's write-then-approve cycle. |
+| Q3 | Chain depth | **(a) Yes, across chained rows.** | As recommended. |
+| Q4 | Note shape | **Hybrid: approver can edit the proposed values (counter-proposal) AND/OR leave free-text in `decision_note`.** | Differs from (a). Inventor picked free-text-only; m's twist: the suggestion should ALSO carry concrete edits. This adds a `counter_payload jsonb` column on `approval_requests` and turns "suggest-changes" into an action that authors a real counter-proposal, not just a hint. |
+| Q5 | Surface | **(a) /inbox only — v1.** | As recommended. Email + entity-detail badge are Phase 2. |
+| Q6 | Requester actions | **Different model: the counter is a NEW pending approval_request row, not an "edit + resubmit" CTA on the requester side.** | Differs from (a). m's reframing: instead of routing back to the requester to act on, the suggestion IS the next request. Original requester sees the old row as `changes_requested` (status pill "Abgelehnt mit Vorschlag" or similar). Original requester then sees the NEW row in /inbox like any pending — and **may approve it themselves**, because they are no longer the row's requested_by (the suggesting approver is). Everyone else eligible sees it too. Cleaner workflow, removes the "edit-and-resubmit CTA" from the requester role entirely. |
+| Q7 | Notifications | **(b) Notify all eligible approvers + the original requester for the NEW pending row.** | Consistent with Q6. The counter is a fresh `pending` request, so the existing Submit*-notification audience applies. The original requester needs the ping because they're now an eligible approver of the counter — no special-case path. |
+| Q8 | Audit shape | **(a) New event_type `*_approval_changes_suggested` per entity.** | As recommended. The new row also emits a normal `*_approval_requested` event, so the Verlauf chronology naturally captures the chain. |
+
+The decisions above lock the design. §3 has been rewritten to reflect them; §2 (open questions) is retained as the historical record of what was open before the decisions.
+
+---
+
+## 1. Context — what's already in the code (verified 2026-05-19)
+
+- **State machine** in `internal/services/approval_service.go`:
+  - `paliad.approval_requests.status` CHECK is already `('pending', 'approved', 'rejected', 'revoked', 'superseded')` — the `superseded` value is defined as a Go constant `RequestStatusSuperseded` but never written by the live service (reserved).
+  - `paliad.{deadlines,appointments}.approval_status` CHECK is `('approved', 'pending', 'legacy')` — three values only.
+  - Shared kernel `decide(requestID, callerID, finalStatus, note)` powers Approve / Reject / Revoke. Approve invokes `applyApproved`; Reject + Revoke invoke `applyRevert` (restores entity from `pre_image`).
+  - Self-approval blocked at 3 layers: `canApprove` Go gate, `approval_requests_no_self_approval` DB CHECK, deadlock-check excludes requester from pool.
+- **Handlers** in `internal/handlers/approvals.go`:
+  - `POST /api/approval-requests/{id}/approve`
+  - `POST /api/approval-requests/{id}/reject`
+  - `POST /api/approval-requests/{id}/revoke`
+  - `GET  /api/approval-requests/{id}` — single hydrated request
+- **Per-viewer flags** (t-paliad-202, shipped): every row carries `viewer_can_approve` + `viewer_is_requester` resolved server-side so the UI can grey out buttons the server would reject. Server still enforces — the flags are a UX hint.
+- **Frontend**:
+  - `frontend/src/client/inbox.ts` wires three buttons per pending row (approve/reject/revoke). Reject opens `window.prompt()` for the note; approve+revoke don't.
+  - `frontend/src/client/views/shape-list.ts` (row_action="approve") stamps the row with action buttons + diff + `decision_note` display if present.
+- **Audit**: event types `*_approval_requested`, `*_approval_approved`, `*_approval_rejected`, `*_approval_revoked` emitted to `paliad.project_events` (one per entity_type prefix).
+- **Decision note**: `paliad.approval_requests.decision_note text` — a single free-text column, last-write-wins. Already populated on Reject (Approve also accepts an optional note).
+
+---
+
+## 2. Design questions (the open list — see §6 for answered)
+
+Pre-recommendations from inventor. m will pick via AskUserQuestion.
+
+### State machine
+
+**Q1 — Where does "suggest changes" sit on the lifecycle?**
+- **(a) New status `changes_requested` (RECOMMENDED).** The approval_requests row transitions pending → changes_requested. Sibling of approved/rejected/revoked/superseded. The row is terminal in that status; a re-submit creates a fresh row (linked via `previous_request_id`).
+- (b) Reuse `rejected` with `is_revisable=true` flag. Cheap, but conflates two semantically distinct outcomes ("we'll never want this" vs. "tweak X and try again").
+- (c) Auto-revoke the current row, mark the entity for edit, requester creates a new approval row when ready. Reuses existing plumbing — but loses the approver's note as a first-class thing (it'd just be a comment on the project_events row).
+- (d) Other (you'll tell us).
+
+Recommend (a) — keeps the audit lifecycle clear, gives us a clean place to hang the suggestion note, and is the smallest schema change (one new value in a CHECK constraint).
+
+**Q2 — What happens to the entity (deadline/appointment) while in "changes requested"?**
+- **(a) Entity reverts to pre_image — same as Reject (RECOMMENDED).** approval_status flips back to `approved`. The requester edits the entity in the normal flow; saving fires a fresh `Submit*` cycle.
+- (b) Entity stays at `approval_status=pending` carrying the proposed values; requester edits "in place" through a new "amend the pending request" endpoint that mutates the same approval_request row + entity fields.
+- (c) Entity goes to a new `approval_status=draft` (would require a new value on the entity-level CHECK + UI work to handle a third entity state).
+
+Recommend (a) — minimum schema change, reuses every existing path (entity edit, Submit*, applyRevert, project_events emission). The trade-off is one extra approval_requests row per cycle; we link via `previous_request_id` so the chain stays inspectable.
+
+**Q3 — Can the approver suggest changes multiple times (across a chain)?**
+- **(a) Yes, across chained rows (RECOMMENDED).** Each row is terminal after suggest-changes; the requester resubmits → new pending row → approver can suggest changes again. Chain depth unbounded.
+- (b) No — one chance per entity-lifecycle; if the requester comes back, the only options are approve or reject (the suggest-changes button is hidden for the second submission).
+
+Recommend (a) — bounded by the requester's patience, not by the system. Multi-round review is the norm in legal-doc workflows.
+
+**Q4 — Note shape on the suggestion**
+- **(a) Free-text — reuse `decision_note` (RECOMMENDED).** Same column the existing Reject path already populates. Last-write-wins per row (but rows are terminal after suggest-changes, so there's no real "last write").
+- (b) Thread of notes — new `paliad.approval_notes` table, ordered, multi-author. Lets the requester respond inline, the approver clarify, etc.
+- (c) Structured per-field suggestions (`[{"field": "due_date", "current": "...", "suggested": "..."}]`) — a "diff-style" view.
+
+Recommend (a) — matches the existing Reject UX, no new schema. (b) is right if the team wants to discuss; (c) is over-engineered for v1.
+
+### UX
+
+**Q5 — Where does the requester see the suggestion?**
+- **(a) /inbox under `a_role=self_requested` (RECOMMENDED for v1).** Same surface they already use to see rejected. New status pill "Änderungen vorgeschlagen" + the note + a CTA "Bearbeiten und erneut einreichen".
+- (b) A new badge on the entity's detail page (e.g. on the deadline detail page itself).
+- (c) Email + push notification.
+- (d) All of the above.
+
+Recommend (a) for v1. Email reminder is a natural Phase-2 add-on (it'd reuse the existing reminder-mail plumbing). The entity-detail badge is nice but the user is already seeing the row in /inbox.
+
+**Q6 — What action(s) does the requester have on a `changes_requested` row?**
+- **(a) Edit and resubmit (RECOMMENDED).** Primary action. Opens the entity's edit form pre-populated with the original `payload`. Saving fires `Submit*` → new pending request with `previous_request_id` linking back.
+- (b) Withdraw (= dismiss the row from inbox, no DB change). Mostly UI-only — the row is already terminal; "withdraw" would just be a "mark as not-pursuing" toggle.
+- (c) Both.
+
+Recommend (a). The row is already terminal once status=`changes_requested`; the requester either acts on the suggestion (a) or lets the row sit in their inbox history (no action needed). Adding a "dismiss" button is a UI nice-to-have but doesn't change the data model; can defer.
+
+### Notifications
+
+**Q7 — Who gets notified when "suggest changes" fires?**
+- **(a) Just the requester (RECOMMENDED for v1).** Email-reminder path is reused: requester gets a mail "X hat Änderungen vorgeschlagen für …" with the note inline + a link to /inbox.
+- (b) Requester + any other potential approvers (they need to know the request is closed, not pending).
+- (c) Requester + approval-policy-defined watchers (would require a new `approval_policies.watchers` column).
+
+Recommend (a). The request is terminal so other approvers don't need a "this is now your problem" ping — they wouldn't have anything to act on. They see it in /inbox under "Alle sichtbaren" anyway if curious.
+
+### Audit
+
+**Q8 — Audit row shape on `project_events`**
+- **(a) New event_type `*_approval_changes_suggested` per entity (RECOMMENDED).** Parallel to the existing 4 (requested/approved/rejected/revoked). Two new event types: `deadline_approval_changes_suggested`, `appointment_approval_changes_suggested`. Note text goes in metadata.
+- (b) Bundle with the resubmission — single composite event "approved-with-revisions" when the chain eventually approves.
+
+Recommend (a). Each transition gets its own event row — that's how the existing audit chain already works (one event per state change). It also gives the Verlauf timeline a row to render the approver's note.
+
+---
+
+## 3. Implementation sketch (decisions-locked, see §0a)
+
+### 3.1 Migration `103_approval_suggest_changes.up.sql`
+
+```sql
+-- 1. Extend approval_requests.status CHECK to allow 'changes_requested'.
+ALTER TABLE paliad.approval_requests
+    DROP CONSTRAINT IF EXISTS approval_requests_status_check;
+ALTER TABLE paliad.approval_requests
+    ADD  CONSTRAINT approval_requests_status_check
+    CHECK (status IN ('pending', 'approved', 'rejected', 'revoked', 'superseded', 'changes_requested'));
+
+-- 2. Add counter_payload — the approver's edited values, becomes the
+--    `payload` of the NEW pending row spawned in the same tx as the
+--    suggest-changes call. Stored on the OLD (now changes_requested) row
+--    too so the audit chain can show "approver edited X, Y, Z" without
+--    joining to the next row.
+ALTER TABLE paliad.approval_requests
+    ADD COLUMN counter_payload jsonb NULL;
+
+-- 3. Add previous_request_id FK so the new row links back to its origin.
+ALTER TABLE paliad.approval_requests
+    ADD COLUMN previous_request_id uuid NULL
+        REFERENCES paliad.approval_requests(id) ON DELETE SET NULL;
+
+CREATE INDEX approval_requests_previous_idx
+    ON paliad.approval_requests (previous_request_id)
+    WHERE previous_request_id IS NOT NULL;
+```
+
+`.down.sql`: drop the index + columns, restore the original CHECK (would reject existing `changes_requested` rows — that's normal for a breaking-change down).
+
+### 3.2 Service layer
+
+`SuggestChanges` is the only new public method on `ApprovalService`. It runs in **one transaction** and does five things:
+
+```go
+const RequestStatusChangesRequested = "changes_requested"
+
+var ErrSuggestionRequiresChange = errors.New("suggestion_requires_change")
+
+// SuggestChanges closes the pending request as `changes_requested`,
+// reverts the entity, then immediately inserts a new pending
+// approval_request authored by the caller carrying `counterPayload` as
+// its new payload. The new row enters the standard pending flow — anyone
+// eligible (including the original requester) can approve, reject,
+// suggest-changes-again, etc.
+//
+// Authorization: caller satisfies canApprove on the OLD row (same gate
+// as Approve / Reject). For the NEW row, the caller is the requested_by
+// — self-approval is blocked by the standard 3-layer guard. Deadlock
+// check (qualified-approver-exists-other-than-caller) runs on the new
+// row to avoid spawning an unapprovable request.
+//
+// counterPayload must differ from the old row's payload OR a non-empty
+// note must be present. A no-op suggest (same values, no note) is
+// indistinguishable from "I have no opinion" and gets rejected with
+// ErrSuggestionRequiresChange.
+func (s *ApprovalService) SuggestChanges(
+    ctx context.Context,
+    requestID, callerID uuid.UUID,
+    counterPayload []byte,   // jsonb-marshaled
+    note string,
+) (newRequestID *uuid.UUID, err error) {
+    // 1. Begin tx, lock old row, validate status=pending + canApprove.
+    // 2. Validate: counterPayload differs from old payload OR note != "".
+    // 3. Update old row: status='changes_requested', decided_by=callerID,
+    //    decision_note=note, counter_payload=counterPayload.
+    // 4. applyRevert on the entity (uses old row's pre_image).
+    // 5. Deadlock-check on the new row's required_role + projectID,
+    //    excluding callerID.
+    // 6. INSERT new approval_requests row: requested_by=callerID,
+    //    pre_image=<entity-state-as-just-reverted> (= old.pre_image),
+    //    payload=counterPayload, required_role=old.required_role,
+    //    lifecycle_event=old.lifecycle_event, entity_type=old.entity_type,
+    //    entity_id=old.entity_id, status='pending',
+    //    previous_request_id=requestID.
+    // 7. Re-apply the new payload to the entity (write-then-approve):
+    //    apply the counter_payload's field updates + mark
+    //    approval_status='pending' + pending_request_id=newRequestID.
+    // 8. Emit *_approval_changes_suggested project_events row
+    //    (metadata: note, counter_payload diff vs original).
+    // 9. Emit *_approval_requested project_events row for the new
+    //    request (same shape Submit* normally emits).
+    // 10. Commit.
+}
+```
+
+Steps 6 + 7 reuse the existing `Submit*` plumbing structurally — the cleanest implementation factors out an "insert approval row + apply payload to entity" helper that both `Submit*` and `SuggestChanges` call. **decide()** does not need to know about `changes_requested` because suggest-changes is not a decision-kernel transition — it's its own end-to-end action.
+
+### 3.3 HTTP layer
+
+```
+POST /api/approval-requests/{id}/suggest-changes
+  Body: {
+    "counter_payload": { ...same shape as Submit*'s payload... },
+    "note":            "free-text explanation, optional iff counter_payload differs from original"
+  }
+  Returns: 200 { "new_request_id": "uuid" }
+  Errors:
+    400 "suggestion_requires_change" — counter_payload == old payload AND note empty
+    400 "invalid_counter_payload"   — schema validation failure
+    403 "self_approval_blocked"     — caller == old row's requested_by
+    403 "not_authorized"            — caller doesn't satisfy canApprove
+    404                              — request not found / not visible
+    409 "request_not_pending"       — old row already decided
+    409 "no_qualified_approver"     — deadlock on the new row (only caller is eligible)
+```
+
+Register in `internal/handlers/handlers.go` alongside the existing three:
+
+```go
+protected.HandleFunc("POST /api/approval-requests/{id}/suggest-changes", handleSuggestChangesApprovalRequest)
+```
+
+### 3.4 Frontend
+
+`frontend/src/client/views/shape-list.ts` — extend the pending-row action group to four buttons:
+
+```ts
+actions.appendChild(approvalActionBtn("approve", detail));
+actions.appendChild(approvalActionBtn("suggest_changes", detail));
+actions.appendChild(approvalActionBtn("reject", detail));
+actions.appendChild(approvalActionBtn("revoke", detail));
+```
+
+The `action` union type gains `"suggest_changes"`. Disabled-reason logic is identical to approve/reject (`viewer_can_approve` gate). i18n: `approvals.action.suggest_changes` → DE "Änderungen vorschlagen" / EN "Suggest changes".
+
+`frontend/src/client/inbox.ts` — clicking the suggest-changes button opens a **modal**, not a `window.prompt` (the existing reject prompt is OK because reject only needs a note; suggest-changes needs an editable form). The modal:
+- Renders the same fields the entity edit form would show, pre-populated from `detail.payload` (the requester's proposed values).
+- Adds a free-text "Vorschlagskommentar" textarea at the bottom (the note).
+- On submit: POST `/api/approval-requests/{id}/suggest-changes` with `{counter_payload: {...editedFields}, note}`.
+- On success: refresh the bar — the old row flips to `changes_requested`, the new row appears as `pending`.
+
+Where the modal's field-editor lives: a new `client/components/approval-edit-modal.ts` that takes `entity_type` + `payload` + `pre_image` and returns the edited payload. For v1 it can be a thin wrapper over the existing entity-edit form components (Frist date picker, Termin start/end pickers). Don't build a generic field-editor framework — just deadlines + appointments, hard-coded fields per entity_type.
+
+**Status pill for `changes_requested`** — i18n keys + colour:
+- `approvals.status.changes_requested` → DE "Abgelehnt mit Vorschlag" / EN "Declined with changes"
+- Reuse the existing `approval-pill--historic` style; no new colour token needed for v1.
+
+**The "Edit and resubmit" CTA on the requester's row is NOT needed** (m's Q6 reframing) — the requester just sees the new pending row in /inbox, same as any other.
+
+### 3.5 Inbox filter
+
+The /inbox `approval_status` filter chip cluster gains `changes_requested`. The `self_requested` viewer-role default already includes terminal statuses, so the original requester sees their `changes_requested` row without changing the default filter.
+
+### 3.6 Linkage from old row to new row in /inbox
+
+When showing a `changes_requested` row in /inbox, add a small "→ Neuer Vorschlag von {approver}" link below the note that scrolls / filters to the new pending row (it'll be visible to anyone eligible, including the original requester). The new row has `previous_request_id` pointing at the old one — so the API response for the old row can hydrate `next_request_id` (computed: `SELECT id FROM approval_requests WHERE previous_request_id = $1 LIMIT 1`).
+
+### 3.7 Email notification (Phase 2 — defer until v1 ships)
+
+The new row triggers the existing `*_approval_requested` notification path (whatever that is for Submit*) — same audience, same template. No new code. The old row's transition to `changes_requested` doesn't need its own mail; the new-row mail already tells the audience "X suggested changes to your earlier submission" through the body.
+
+Out of scope for v1: a bespoke "your submission was declined with a counter-proposal" email aimed at the original requester. The new-row mail covers it functionally.
+
+---
+
+## 4. Slice plan
+
+Three reviewable slices, each one PR. Combined scope is small/medium.
+
+1. **Slice A — backend.** Migration 103 (CHECK extension + `counter_payload jsonb` + `previous_request_id` FK + index) + `SuggestChanges` service method + HTTP handler + service tests (happy path, no-op-suggestion guard, deadlock on new row, self-approval block, request_not_pending). Migration is non-blocking on Postgres; safe for live deploy.
+2. **Slice B — frontend.** 4th button on /inbox + the edit modal (deadline-fields variant + appointment-fields variant) + status pill `changes_requested` ("Abgelehnt mit Vorschlag") + i18n keys (DE + EN) + the "→ Neuer Vorschlag" link from old row to new row. End-to-end browser smoke test via Playwright.
+3. **Slice C — Verlauf integration.** Make sure the `*_approval_changes_suggested` event renders on the project / deadline / appointment Verlauf timeline alongside the existing 4 approval event types. May or may not need code change depending on how generic the Verlauf row renderer is — likely just an i18n key + an icon mapping.
+
+Don't ship a chain-traversal UI in v1. The `previous_request_id` FK is captured so the data is there; surfacing the full chain history (n hops back) is a Phase-2 polish.
+
+---
+
+## 5. Risks / open considerations
+
+- **Chain depth runaway.** Nothing stops an "I keep suggesting / they keep counter-suggesting" loop. Same risk as comment threads on GitHub PRs. Out of scope to cap; the social pressure (each round is a 4-Augen action with a name attached) is the natural brake.
+- **Concurrent suggestions on the same pending row.** Two approvers click "suggest changes" at the same time? The existing `getRequestForUpdate` row-lock serialises them; the second caller gets `ErrRequestNotPending` (the first already flipped it). Same guarantee as Approve/Reject today.
+- **Deadlock on the new row.** If the suggesting approver is the only qualified approver other than the original requester, the new row's deadlock check returns "no qualified approver" — because the original requester IS now eligible (they're no longer the requested_by), but might not have a high-enough role. The check needs to recognise: caller's pool = "anyone other than the new requester who can canApprove". Original requester counts if they hit the required-role bar. This is just the existing deadlock predicate run against the new (requester, role) tuple; no special-case logic. Surfaced as `409 "no_qualified_approver"` to the suggesting approver, with the standard global_admin override path still available.
+- **Counter-payload schema validation.** Server must validate `counter_payload` against the same schema as a normal `Submit*` for that entity_type + lifecycle_event. Otherwise a malicious approver could write garbage values via the suggestion path that wouldn't fly through `Submit*`. Reuse the existing payload-schema validator from the entity services; don't write a parallel.
+- **No-op suggestion guard.** Approver clicks suggest-changes but doesn't actually edit anything AND leaves the note empty? Server rejects with `ErrSuggestionRequiresChange`. UI guards too (the submit button stays disabled until either the form is dirty OR the note has text).
+- **Migration safety.** Non-blocking. Adding a value to a CHECK constraint is a metadata-only change; adding a NULLable column + a NULLable FK is also metadata-only.
+- **What about a structured per-field suggestion (Q4c)?** The `counter_payload` jsonb IS structured — each entity_type has fixed fields. There's no need for a separate "{field, current, suggested}" shape because the diff is computable from `pre_image → counter_payload` on the new row.
+- **What about thread-of-notes (Q4b)?** Implicit in the chain — each row's `decision_note` is one "note" by one author; following `previous_request_id` backwards reconstructs the full back-and-forth. A future "thread view" UI is layered on top of this without schema change.
+
+---
+
+## 6. m's decisions
+
+See §0a (decisions table) — filled in after the AskUserQuestion phase on 2026-05-19.
+
+---
+
+## 7. Out of scope for this design
+
+- Email + push notifications (Phase 2; see §3.7).
+- Structured per-field suggestion shape (Phase 2 enhancement).
+- Approval-policy `watchers` column for notification fan-out.
+- "Dismiss this row from my inbox" UI toggle (UX-only, not a data-model change).
+- Cross-entity suggest-changes (e.g. project, party). Same as the original approval scope — deadlines + appointments only.
+

docs/design-caldav-multi-calendar-2026-05-19.md

@@ -0,0 +1,597 @@
+# CalDAV multi-calendar sync — design
+
+**Task:** t-paliad-212
+**Inventor:** leibniz (2026-05-19)
+**Branch:** mai/leibniz/inventor-caldav-multi
+**Status:** READY FOR REVIEW — m's decisions on the §8 open questions captured in the addendum below (2026-05-19).
+
+---
+
+## §0 — One-paragraph summary
+
+Paliad's CalDAV sync today is a single-target push: every user has one
+`paliad.user_caldav_config` row, and every Appointment they can see gets
+PUT into that one calendar. m wants users to pick their own organization —
+one cal with everything, one cal per project (or per client / litigation /
+patent / case), or any hybrid. This design splits the model in two:
+**credentials stay per user** (one CalDAV server, one auth blob) and
+**bindings become first-class rows** (a join table `paliad.user_calendar_bindings`
+that points an Appointment-filter scope at a specific `calendar_path`).
+Push/pull state migrates from scalar `appointments.caldav_uid`/`caldav_etag`
+columns to a per-(appointment, binding) join table
+`paliad.appointment_caldav_targets`, so the same Appointment can live in
+N external calendars at once. The 60-second per-user sync goroutine survives
+unchanged in shape; inside it the inner loop iterates bindings instead of
+hard-coding `cfg.CalendarPath`. Sliced for safe rollout: Slice 1 introduces
+the new tables behind a backfill that auto-creates one binding per
+existing config row (zero behaviour change); Slice 2 ships the
+binding-picker UI; Slice 3 wires scope-aware filtering (one cal per project).
+Bidirectional sync stays exactly as it works today (last-write-wins on ETag,
+Paliad-owned UIDs only) — multi-calendar does not change the conflict
+model.
+
+---
+
+## §1 — What's already built (verified live, 2026-05-19)
+
+Verified against the codebase, not the project's CLAUDE.md.
+
+- **Schema** — `paliad.user_caldav_config` is one row per user with
+  `(user_id PK, url, username, password_encrypted bytea, calendar_path,
+  enabled, last_sync_at, last_sync_error, created_at, updated_at)`. The
+  scalar `calendar_path` is the only handle on which external calendar
+  receives events. Per direct `information_schema` query.
+- **Appointment binding** — `paliad.appointments` carries scalar
+  `caldav_uid text` and `caldav_etag text` (nullable). Set once after a
+  successful PUT via `AppointmentService.SetCalDAVMeta`. This is the
+  single-target assumption baked into the row itself.
+- **Sync engine** — `internal/services/caldav_service.go:298–502`. One
+  goroutine per enabled user, 60s ticker, `runSyncOnce` → `syncOnce` →
+  `pushAll` (`AppointmentService.AllForUser` × `cli.PutEvent`) +
+  `pullAll` (`cli.PropfindCalendar` → `cli.GetEvent` → reconcile by UID).
+  `AllForUser` returns *every* personal-or-visible-project appointment
+  for the user; today they all funnel into the single `calendar_path`.
+- **UID convention** — `paliad-appointment-<uuid>@paliad.de`
+  (`caldav_ical.go:31–34`). Foreign UIDs are intentionally skipped on
+  pull (`caldav_service.go:436–442`).
+- **Hooks** — `OnAppointmentCreated/Updated/Deleted` push directly to
+  the configured `cfg.CalendarPath` on a 30s-timeout background goroutine
+  so user requests don't block (`caldav_service.go:510–558`).
+- **Approval flow (t-138)** — project-attached appointments may be
+  `approval_status = 'pending'`. CalDAV push already runs after approval
+  in `AppointmentService.Update` paths; `ApplyRemoteUpdate` from a remote
+  edit currently bypasses the approval gate. That's a pre-existing hole
+  flagged here only because multi-calendar makes "which calendar's edit
+  wins" more visible — fix belongs in t-138 follow-ups, not in this
+  design.
+- **CalDAV verbs supported** — PUT / DELETE / GET / PROPFIND (depth 0
+  and 1). No MKCALENDAR, no REPORT, no calendar-multiget. Tested
+  against Nextcloud, Radicale, Baikal, mailcow SOGo per
+  `caldav_client.go:22–24`.
+
+**What is _not_ baked in and is therefore free to extend:**
+
+- The 60s ticker is per-*user*, not per-*calendar*. Adding bindings does
+  not multiply tickers.
+- `cfg.CalendarPath` is referenced in exactly two places (`pushAll`,
+  `pullAll`) plus the three hooks. Replacing it with a binding loop is
+  a contained edit.
+- Credentials are server-scoped, not calendar-scoped — every binding
+  for the same user shares the existing decrypted credential, so the
+  encryption layer (`caldav_crypto.go`) is untouched.
+
+---
+
+## §2 — Per-provider calendar-count limits (verified 2026-05-19)
+
+Real numbers, from current docs, so the design knows its envelope.
+
+| Provider | Per-account / per-user limit | Source |
+|---|---|---|
+| **iCloud** | **100** calendars + reminder-lists combined | [Apple Support 103188](https://support.apple.com/en-us/103188) |
+| **Google Calendar** | **~100 owned** (soft recommendation, post-Nov-2025 ownership model) | [Workspace Updates 2026-01](https://workspaceupdates.googleblog.com/2026/01/automatic-addition-owned-secondary-calendars.html), [usecarly.com summary](https://www.usecarly.com/blog/how-many-calendars-google-account/) |
+| **Fastmail** | **No documented cap on calendars.** 100 000 events/user. | [Fastmail account-limits page](https://www.fastmail.help/hc/en-us/articles/1500000277382-Account-limits) |
+| **Nextcloud** | **30 per user** default; admin-configurable, `-1` = unlimited. Rate limit: 10 calendar-creations/hour. | [Nextcloud admin manual — Calendar](https://docs.nextcloud.com/server/stable/admin_manual/groupware/calendar.html) |
+| **Radicale / Baikal / mailcow SOGo** | No published per-account cap (file-system / DB bound). | server defaults |
+
+**Implications for the design:**
+
+- "One calendar per project" is comfortably within all providers'
+  envelopes for typical HLC caseloads. A senior PA who tracks 40
+  litigations would land 40+ calendars, still inside iCloud's 100 and
+  Nextcloud's default 30 (would need an admin bump on Nextcloud — flag
+  in onboarding).
+- "One calendar per case" can blow past Nextcloud's default 30 fast and
+  is a real risk on iCloud at the 60+ mark when combined with the
+  user's existing personal calendars + reminder lists. We should
+  **soft-cap** scope choices at the UI layer (warn at 20 bindings, hard
+  block at 80) rather than discover the limit by 5xx on PUT.
+- Google Calendar's CalDAV endpoint does **not** support `MKCALENDAR`
+  reliably — calendars must be pre-created in the Google UI. iCloud,
+  Fastmail, Nextcloud, Radicale, Baikal, SOGo all accept `MKCALENDAR`.
+  So the "auto-create a calendar per project" affordance is provider-
+  dependent and must degrade gracefully ("we couldn't create it for
+  you — please make `Project X` in your calendar app and paste its
+  URL").
+
+---
+
+## §3 — Proposed data model
+
+Three schema changes, no destructive migrations. The scalar
+`appointments.caldav_uid` / `caldav_etag` columns survive as a
+denormalised "default-binding" pointer through Slice 1 and 2; Slice 4
+drops them after telemetry confirms no path still reads them.
+
+### §3.1 New table: `paliad.user_calendar_bindings`
+
+```sql
+CREATE TABLE paliad.user_calendar_bindings (
+  id              uuid PRIMARY KEY DEFAULT gen_random_uuid(),
+  user_id         uuid NOT NULL REFERENCES paliad.users(id) ON DELETE CASCADE,
+  calendar_path   text NOT NULL,                  -- absolute URL or path under user_caldav_config.url
+  display_name    text NOT NULL DEFAULT '',       -- the label discovered via PROPFIND <displayname/>; what we show in the UI
+
+  scope_kind      text NOT NULL,                  -- 'all_visible' | 'personal_only' | 'project' | 'client' | 'litigation' | 'patent' | 'case'
+  scope_id        uuid REFERENCES paliad.projects(id) ON DELETE CASCADE,  -- NULL for 'all_visible' / 'personal_only'
+  include_personal boolean NOT NULL DEFAULT false, -- only meaningful when scope_kind <> 'all_visible'/'personal_only'
+
+  enabled         boolean NOT NULL DEFAULT true,
+  last_sync_at    timestamptz,
+  last_sync_error text,
+
+  created_at      timestamptz NOT NULL DEFAULT now(),
+  updated_at      timestamptz NOT NULL DEFAULT now(),
+
+  UNIQUE (user_id, calendar_path),                                -- can't bind one calendar twice for the same user
+  UNIQUE (user_id, scope_kind, scope_id),                         -- one binding per scope per user — but a project can also be covered by 'all_visible'
+  CHECK ((scope_kind IN ('all_visible','personal_only') AND scope_id IS NULL)
+      OR (scope_kind NOT IN ('all_visible','personal_only') AND scope_id IS NOT NULL))
+);
+CREATE INDEX user_calendar_bindings_user_idx ON paliad.user_calendar_bindings(user_id) WHERE enabled;
+-- RLS: row visible/writable only when auth.uid() = user_id (mirrors user_caldav_config).
+```
+
+**Why per-scope unique but not per-appointment unique:** an Appointment in
+project P is allowed to land in both the user's `all_visible` calendar
+AND their `project=P` calendar — that's the explicit "master + per-project"
+hybrid m asked about. What we forbid is two different `project=P` bindings
+for the same user, which would have no useful semantics.
+
+**`scope_kind = 'personal_only'`** is a separate scope from `'all_visible'`
+because the existing pushAll already covers both personal and visible-project
+appointments; users may want a "personal only" calendar that does *not*
+get the noisy team events. Without this, every binding either includes
+personal events or doesn't, and there's no way to say "the master
+calendar = everything except personal".
+
+### §3.2 New table: `paliad.appointment_caldav_targets`
+
+```sql
+CREATE TABLE paliad.appointment_caldav_targets (
+  appointment_id uuid NOT NULL REFERENCES paliad.appointments(id) ON DELETE CASCADE,
+  binding_id     uuid NOT NULL REFERENCES paliad.user_calendar_bindings(id) ON DELETE CASCADE,
+  caldav_uid     text NOT NULL,        -- still 'paliad-appointment-<uuid>@paliad.de' — same for all bindings of one appointment
+  caldav_etag    text NOT NULL,
+  last_pushed_at timestamptz NOT NULL DEFAULT now(),
+  PRIMARY KEY (appointment_id, binding_id)
+);
+CREATE INDEX appointment_caldav_targets_binding_idx ON paliad.appointment_caldav_targets(binding_id);
+-- RLS: visible/writable when the underlying binding's user_id = auth.uid().
+```
+
+**UID stays per-appointment, not per-binding.** That keeps the iCal UID
+canonical (still `paliad-appointment-<uuid>@paliad.de`), so when a user
+removes a binding and re-adds it later, the same UID rebinds without
+spurious duplicates. The `.ics` filename in the calendar — `<uid>.ics`
+— is also identical across bindings, which means the same UUID
+shows up in different calendars on the same server but never collides
+because they're under different `calendar_path` collections.
+
+### §3.3 Row examples for the four common organisations
+
+| Organisation | Rows in `user_calendar_bindings` |
+|---|---|
+| **A — one cal, everything** | 1 row: `scope_kind='all_visible'`, `calendar_path='/cal/work'` |
+| **B — one cal per project** | N rows, all `scope_kind='project'`, distinct `(scope_id, calendar_path)` |
+| **C — master + per-project hybrid** | 1 row `scope_kind='all_visible'` + N rows `scope_kind='project'`. Each project event appears in both. |
+| **D — personal split from work** | 1 row `scope_kind='personal_only'` → `/cal/personal` + 1 row `scope_kind='all_visible'` (which will include the same personal events, so the user will more commonly pair `personal_only` with a `scope_kind='client'` per-client work view instead). |
+
+### §3.4 What stays unchanged
+
+- `paliad.user_caldav_config` — still holds the server URL, username,
+  encrypted password, and a per-user `enabled` flag. The existing
+  `calendar_path` column becomes a hint for the **default binding** we
+  auto-create on migration and is no longer read by sync logic after
+  Slice 1 ships. We keep it nullable-on-read for forwards-compat then
+  drop in Slice 4.
+- `paliad.caldav_sync_log` — still per-user; sync entries gain a
+  `binding_id` column (nullable for legacy rows) so the UI can show
+  per-calendar last-sync state.
+- iCal serialisation (`caldav_ical.go`) — unchanged. Same VEVENT
+  formatter feeds every binding.
+- AES-GCM credential encryption (`caldav_crypto.go`) — unchanged.
+
+---
+
+## §4 — Sync engine implications
+
+The shape of the per-user goroutine stays. The body of `syncOnce`
+moves from "push to one path / pull from one path" to "for each
+enabled binding, push the scope-filtered slice / pull from that path".
+
+### §4.1 Push fan-out
+
+```go
+// pseudocode for the new pushAll body
+bindings := s.bindings.ListEnabled(ctx, userID)              // 1..N rows
+for _, b := range bindings {
+    appts := s.appointments.ForBinding(ctx, userID, b)       // scope-filtered
+    for _, a := range appts {
+        body := formatAppointment(&a)
+        etag, err := cli.PutEvent(ctx, b.CalendarPath, terminUID(a.ID), body)
+        if err != nil { continue }                            // best-effort, per-binding error
+        s.targets.Upsert(ctx, a.ID, b.ID, terminUID(a.ID), etag)
+    }
+    // Remove events from this calendar that no longer belong to the scope.
+    for _, stale := range s.targets.DanglingForBinding(ctx, b.ID, currentIDs(appts)) {
+        cli.DeleteEvent(ctx, b.CalendarPath, stale.CalDAVUID)
+        s.targets.Delete(ctx, stale.AppointmentID, b.ID)
+    }
+}
+```
+
+`ForBinding(userID, b)` is the scope filter:
+
+- `all_visible` → existing `AllForUser(userID)`
+- `personal_only` → appointments with `project_id IS NULL AND created_by = userID`
+- `project` → appointments where `project_id = scope_id` AND visible to user
+- `client` / `litigation` / `patent` / `case` → appointments where the
+  ancestor at the relevant hierarchy level = `scope_id` AND visible to user
+- when `include_personal = true`, union with personal events on top of the above (only for non-`all_visible`/`personal_only` scopes)
+
+This reuses the existing `can_see_project()` predicate (per project
+CLAUDE.md, team-based RLS), so visibility shrinkage on a project unshare
+falls out naturally: next push sees the appointment is no longer in
+`ForBinding(...)`, sees a dangling target row, issues `DeleteEvent`.
+
+### §4.2 Pull reconciliation
+
+Each binding has its own pull pass against `b.CalendarPath`. The
+matching key is still `caldav_uid` — same UID across all bindings, so
+`appointments.FindByCalDAVUID(uid)` resolves the local row. The
+**ETag check is per-target row** now, not per-appointment: a remote
+edit in calendar X bumps the etag in `appointment_caldav_targets` for
+binding X only. The local Appointment is updated once (last-write-wins
+on Appointment.updated_at), the next push tick re-syncs the other
+bindings with the new payload (they see their stored etag is older
+than the appointment's `updated_at` and re-PUT).
+
+**One subtle change:** the foreign-UID skip (`extractAppointmentID == ""`)
+still applies per-binding pull. That preserves the v1 "Paliad owns its
+UIDs" property — multi-calendar does not open the door to importing
+events the user creates in their calendar app. (If/when that becomes
+in-scope, it's a separate t-paliad-* design.)
+
+### §4.3 Hooks (instant push)
+
+`OnAppointmentCreated/Updated/Deleted` fan out across all the user's
+enabled bindings that match the appointment's scope. Same 30s-timeout
+background goroutine. The user-facing request still returns
+immediately; the failure mode is identical (best-effort per binding,
+logged on `slog.Warn`).
+
+### §4.4 Bandwidth & rate limits
+
+- Per user per tick: **N bindings × 1 PROPFIND + per-event GETs**.
+  The pull GET is the dominant cost; a 50-binding user with 20 events
+  per calendar is ~1 000 GETs/min, which is fine over HTTP/1.1 to a
+  decent CalDAV server but **does** put us inside iCloud's
+  ~throttle-friendly band and risks Google's quota model.
+- Mitigation: switch pull to **`REPORT` `calendar-multiget`** so each
+  binding's events come back in one round-trip. That's a single
+  iteration on `caldav_client.go` (the same multistatus parser
+  already handles the body) and pays for itself the moment a user
+  has >10 events per binding. We deliberately deferred this in
+  Phase F (one calendar, low volume) — multi-calendar makes it
+  table-stakes. Plan to land it in **Slice 2** alongside the picker.
+- Rate limiting on the Paliad side: keep the 60s ticker, but stagger
+  per-binding pulls so we never fire N concurrent PROPFINDs against
+  the same provider. Sequential per binding is fine; we already do
+  this implicitly with the per-user goroutine.
+
+### §4.5 Server-side cleanup on binding delete
+
+User deletes a binding → service:
+
+1. Lists every (appointment, binding) target row for that binding.
+2. Issues `DELETE` per `.ics` on the remote calendar (best effort).
+3. Deletes the target rows.
+4. Deletes the binding row (or relies on `ON DELETE CASCADE` from
+   target FK — cleaner to delete remotely first, then drop the row,
+   so a half-failed cleanup leaves rows we can retry on next tick).
+
+A "leave events behind in the external calendar" toggle is a real
+ask (users sometimes archive bindings without wanting their calendar
+app to suddenly empty). Plumb it as `binding.cleanup_on_delete bool`
+in Slice 2 if there's demand; default `true` (delete).
+
+---
+
+## §5 — Bidirectional vs one-way
+
+**Recommendation: stay bidirectional, identical to today's semantics,
+per-binding.** Reasons:
+
+1. **m's stated workflow expects round-trip.** Drag a deadline in
+   Outlook → Paliad sees the new date → approval flow triggers
+   (t-138). One-way push breaks that. Multi-calendar doesn't change
+   this expectation; if anything, it strengthens it (the user picked
+   the project-cal binding *because* they intend to edit there).
+2. **The conflict model is already in place.** Last-write-wins on
+   ETag, foreign-UID skip, `LogConflict` audit append. Multi-calendar
+   adds one new question: "if the user edits the same event in two
+   different bindings between ticks, which wins?" Answer: the one
+   that lands first in our pull pass. Bindings are iterated in
+   `created_at` order so the behaviour is deterministic, and the
+   second edit gets overwritten on the next tick when we re-push the
+   resolved appointment to it. Acceptable trade-off; would only show
+   up if a user actually edits the same event in two of their own
+   calendars within 60s, which is vanishingly rare.
+3. **Approval-flow integration is unchanged.** Pending-approval
+   events have the `[PENDING APPROVAL]` marker baked into the iCal
+   summary by `caldav_ical.go:76+`. That marker survives multi-binding
+   fan-out untouched; an external edit on a pending event still has
+   the pre-existing bypass-the-gate hole (flagged §1, not in scope).
+
+**Tee-up for m's call:** if multi-calendar is the wrong moment to
+keep bidirectional (e.g. because per-project calendars are about
+**read-only visibility for partners**, not editing), we'd add a
+`binding.read_only bool` column and skip the pull pass for that
+binding. Cheap to add now or later. **I recommend defaulting
+`read_only = false` (bidirectional like today) and only making it
+optional if m's first session with the UI surfaces the need.**
+
+---
+
+## §6 — User-facing config model
+
+Surface on `/einstellungen/caldav` (already exists for Phase F creds).
+Two sections, in this order:
+
+1. **Server** (existing) — URL, username, password, "test connection".
+   Unchanged.
+2. **Calendars** (new) — list of bindings as cards / rows. For each:
+   `display_name`, `calendar_path`, `scope_kind` chip (master /
+   personal / project / …), `enabled` toggle, last-sync status, action
+   buttons "Edit scope" / "Remove".
+3. **Add a calendar** — flow:
+   - **a)** click "Add". Modal opens. We do a `PROPFIND
+     <calendar-home-set>` against the user's server to discover their
+     existing calendars; show as a picker. (RFC 6638 / 4791 calendar
+     home set discovery — supported by iCloud, Fastmail, Nextcloud,
+     Radicale, Baikal, SOGo. Google CalDAV does not expose this
+     reliably; for Google users we degrade to a manual path entry box.)
+   - **b)** user picks an existing calendar, or chooses "Create new
+     calendar". Create-new attempts `MKCALENDAR` (works on iCloud,
+     Fastmail, Nextcloud, Radicale, Baikal, SOGo; fails on Google →
+     friendly error with copy-paste instruction).
+   - **c)** user picks the **scope**: a radio between "Everything I can
+     see", "Personal only", "One project", and (later) "One client /
+     litigation / patent / case". Project picker uses the existing
+     `/api/projects?…` autocomplete.
+   - **d)** "Save" → POST `/api/caldav-bindings`. The next 60s tick
+     starts pushing into the new calendar; the UI shows "Initial
+     sync running…" with a live last-sync indicator (already polled
+     by the existing `caldav-config` page).
+
+4. **Quick-add affordances** (Slice 3 polish, not v1):
+   - On a project's `/projects/<id>` page: "Open in calendar app" link
+     if a binding already exists for that project, "Pin to a new
+     calendar" if none does (deep-links to the Add-a-calendar modal
+     pre-filled).
+   - Bulk action "Create one calendar per active litigation" on
+     `/einstellungen/caldav` (requires `MKCALENDAR` support; gated
+     behind a server-capability probe at first PROPFIND).
+
+5. **Soft limits in the UI:**
+   - At **20 bindings**: yellow info banner "Most users keep ≤ 20
+     calendars; review your list before adding more."
+   - At **80 bindings**: red error, block adding new (we don't know
+     the user's provider for sure; 80 is a safe ceiling for iCloud
+     and Nextcloud-default).
+   - Provider hint surfaced under the Server form: parsed from the
+     URL host, with a "your provider's documented limit" line —
+     pure courtesy, not enforced.
+
+### §6.1 What the API contract looks like
+
+| Verb + Path | Body / Returns | Notes |
+|---|---|---|
+| `GET /api/caldav-bindings` | array of binding rows + sync status | replaces having to interpret `user_caldav_config.calendar_path` |
+| `POST /api/caldav-bindings` | `{calendar_path, display_name, scope_kind, scope_id?, include_personal?}` → created binding | triggers immediate sync goroutine wake-up |
+| `PATCH /api/caldav-bindings/{id}` | partial; toggle `enabled` or change `scope_*` | re-runs `pushAll` for this binding |
+| `DELETE /api/caldav-bindings/{id}` | — | deletes external events first, then row |
+| `GET /api/caldav-discover` | array of `{href, displayname}` from server `<calendar-home-set>` | populates the picker; cached 5 min |
+| `POST /api/caldav-mkcalendar` | `{display_name, color?}` → `{calendar_path}` | issues `MKCALENDAR`; returns 501 on Google |
+
+`GET /api/caldav-config` still works (back-compat for the server-creds
+section); its `calendar_path` field is documented as "deprecated, see
+/api/caldav-bindings".
+
+---
+
+## §7 — Slice plan
+
+Tracer-bullet slices so each is independently shippable, safe to
+revert, and gives the user something they can see.
+
+**Slice 1 — Schema + backfill (no UI change).**
+- Migration: create `user_calendar_bindings`, `appointment_caldav_targets`.
+- Backfill: for every existing `user_caldav_config` row, insert one
+  `bindings` row `(user_id, calendar_path, display_name='', scope_kind='all_visible', enabled)`.
+  For every Appointment with non-null `caldav_uid`, insert one
+  `appointment_caldav_targets` row pointing at the user's new default
+  binding.
+- Refactor `CalDAVService.syncOnce` / `pushAll` / `pullAll` to drive
+  off bindings (loop of length 1 per existing user). Behaviour
+  observably identical: same calendars, same events, same logs.
+- `appointments.caldav_uid` / `caldav_etag` columns still exist and
+  are written for compatibility (treat them as denormalised pointers
+  to the default binding's target row). UI unchanged.
+- **Exit criterion:** existing users see no change in their calendar;
+  `caldav_sync_log.binding_id` is populated for all new rows; manually
+  inserted second binding via SQL syncs correctly end-to-end on a
+  staging account.
+
+**Slice 2 — Binding-picker UI + multi-binding support.**
+- `/api/caldav-bindings` CRUD + `/api/caldav-discover` (PROPFIND
+  `calendar-home-set`) + `/api/caldav-mkcalendar`.
+- New "Calendars" section on `/einstellungen/caldav` with the modal
+  flow from §6.
+- **Land `REPORT calendar-multiget` pull** alongside (per §4.4).
+  Required, not optional, for the bandwidth profile multi-binding
+  introduces.
+- Scope kinds enabled in v1: `all_visible`, `personal_only`, `project`.
+  Hierarchy scopes (`client`, `litigation`, `patent`, `case`) parked
+  for Slice 3.
+- **Exit criterion:** m can pin a second calendar via the UI on
+  staging; events for project X appear only in the X-bound calendar
+  if his master binding is disabled, and in both if it's enabled.
+
+**Slice 3 — Hierarchy scopes + project-page quick-adds.**
+- Enable `scope_kind ∈ {client, litigation, patent, case}` — pure
+  filter-predicate change in `ForBinding(...)` using the existing
+  project-tree walker.
+- "Pin to a new calendar" button on `/projects/<id>` and on the
+  /einstellungen page.
+- Bulk "calendar-per-active-litigation" provisioner (with
+  `MKCALENDAR` capability probe).
+- **Exit criterion:** real HLC PA can set up "one cal per
+  litigation" in <5 min on first try without inventor help.
+
+**Slice 4 — Polish + cleanup.**
+- Drop `appointments.caldav_uid` / `caldav_etag` after instrumentation
+  shows zero readers outside `CalDAVService` (`grep` + a one-week
+  query-log audit on the read replica).
+- Soft-limit banners (20 / 80).
+- `binding.read_only` and `binding.cleanup_on_delete` toggles if
+  asked for by then.
+- **Exit criterion:** schema is final; no legacy paths remain in
+  `caldav_service.go`.
+
+**(Out of scope across all four slices:** foreign-UID import, custom
+event types per binding, per-binding colour mapping, MKCALENDAR for
+Google. These are easy to add later if the data says so.)
+
+---
+
+## §8 — Open questions for m
+
+1. **Bidirectional default for new bindings: yes/no?** I recommend
+   **yes** (matches today's single-cal behaviour and the round-trip
+   workflow expectation). A `read_only` per-binding flag is cheap to
+   add later if a real use case shows up. Decide now → Slice 1; decide
+   later → Slice 4.
+2. **`personal_only` scope — keep or drop?** It's useful for users
+   who want a "noisy team master + clean personal" split, but it's
+   redundant for users who only use the master calendar. I'd keep
+   it; trivial to remove if m disagrees.
+3. **`MKCALENDAR` (auto-create calendar) — ship in Slice 2 or defer
+   to Slice 3?** Shipping it in Slice 2 means we need the
+   capability-probe + Google-degrade UX up-front. Deferring means
+   Slice 2 users have to pre-create the calendar in their app and
+   paste the URL — workable but clunky. Default plan: **Slice 2,
+   with a clean Google-degrade message**.
+4. **Soft cap numbers (20 / 80) — sensible?** Picked from §2
+   provider limits + "most paliad users will pick 1–5". m may
+   want different numbers — easy to tune.
+5. **`/admin/caldav-bindings` view for support debugging?** Not in
+   the slice plan; useful if a user calls confused about which
+   calendar holds which event. Add if m wants it.
+6. **Approval-flow + remote-edit gap (§1, the bypass) — fix scope?**
+   Pre-existing in single-cal Phase F. Multi-cal makes it more
+   visible. Should this be a follow-up under t-138, or folded into
+   Slice 3? I'd file as a separate task.
+
+---
+
+## §9 — Why this is the right shape
+
+- **Single CalDAV server per user, N bindings.** Matches every real
+  provider's auth model (one auth blob covers all the user's
+  calendars) and keeps `caldav_crypto.go` and `user_caldav_config`
+  untouched.
+- **Binding scope is a row, not a static config.** Users compose
+  the organisation they want without us guessing; defaults (one
+  master binding on migration) preserve current behaviour.
+- **UID stays per-appointment.** Means an event re-binding (move
+  from project-cal to master-cal) is just shuffling target rows,
+  not minting new UIDs. Re-importing into the same calendar later
+  rebinds cleanly.
+- **Sync engine shape is unchanged.** Same per-user goroutine, same
+  60s tick, same hooks. The blast radius of multi-binding is one
+  inner loop, gated behind a feature that backfills to a no-op for
+  every existing user.
+- **Slices give m a vertical demo at each step.** Slice 1 is
+  invisible-but-shippable; Slice 2 is the first user-facing change
+  ("you can pin a second calendar"); Slice 3 is "now organise by
+  project tree"; Slice 4 is cleanup.
+- **No new external dependencies.** Same hand-rolled CalDAV client.
+  Adds one new verb (`MKCALENDAR`) and one new report
+  (`calendar-multiget`) — both small, both already half-tested
+  against `caldav_client.go`'s patterns.
+
+---
+
+## §10 — Sources
+
+- [Apple Support — Limits for iCloud Contacts, Calendars, Reminders, Bookmarks, and Maps](https://support.apple.com/en-us/103188) — iCloud 100 combined calendars + reminder lists.
+- [Google Workspace Updates — Automatic addition of owned secondary calendars, Jan 2026](https://workspaceupdates.googleblog.com/2026/01/automatic-addition-owned-secondary-calendars.html) — Google ~100 owned recommendation.
+- [Fastmail — Account limits](https://www.fastmail.help/hc/en-us/articles/1500000277382-Account-limits) — 100k events/user, no documented calendar count cap.
+- [Nextcloud admin manual — Calendar / CalDAV](https://docs.nextcloud.com/server/stable/admin_manual/groupware/calendar.html) — default 30, configurable, 10/hr rate limit.
+- Live verification against `internal/services/caldav_*.go` and `paliad.user_caldav_config` / `paliad.appointments` schema on the youpc Supabase instance.
+
+---
+
+## Addendum — m's decisions (2026-05-19)
+
+Walked through §8.1–§8.6 with m via AskUserQuestion. Decisions are
+locked in for the coder shift; revisit only on Slice-3 feedback.
+
+| Q | Decision | Implication for the slice plan |
+|---|---|---|
+| **§8.1 — Bidirectional default** | **Yes — bidirectional by default** | No `read_only` flag in Slice 1–3. Multi-cal inherits Phase F's last-write-wins / foreign-UID-skip semantics unchanged. Per-binding `read_only` only added later if a real use case shows up. |
+| **§8.2 — `personal_only` scope** | **Keep — first-class scope** | Ships in Slice 2 as one of the picker's radio options (`Everything I can see` / `Personal only` / `One project`). One enum value, one `ForBinding()` branch. |
+| **§8.3 — MKCALENDAR timing** | **Slice 2 with Google-degrade UX** | Slice 2 includes `POST /api/caldav-mkcalendar` + capability probe. Google users get a friendly "create the calendar in your Google UI, paste the URL" fallback. iCloud / Fastmail / Nextcloud / Radicale / Baikal / SOGo get one-click "Create new calendar". |
+| **§8.4 — Soft caps** | **No caps in v1, add later if data warrants** | Drop the 20-warn / 80-block UI guards from §6. Instrument `count(*)` on `user_calendar_bindings` per user as a Slice 2 telemetry add. Revisit if/when real distributions land. |
+| **§8.5 — `/admin/caldav-bindings` view** | **Don't ship in v1** | Stays out of the slice plan. Support debugging goes via Supabase SQL until a real ticket lands. Frees Slice 4 polish for the legacy-column drop only. |
+| **§8.6 — Approval-flow remote-edit gap** | **Separate task under t-138** | Out of scope for all four multi-cal slices. File the gap as a new `t-paliad-*` follow-up under t-138 so multi-cal stays clean and reverter-friendly. Pre-existing hole, surfaced not fixed. |
+
+### Net effect on §7 slice plan
+
+- **Slice 1** unchanged — schema + backfill, behaviour-equivalent.
+- **Slice 2** = picker UI + `REPORT calendar-multiget` + **MKCALENDAR
+  with capability probe + Google-degrade message** + binding-count
+  telemetry. No `read_only` flag, no soft caps, no admin view.
+  Scopes enabled: `all_visible`, `personal_only`, `project`.
+- **Slice 3** = hierarchy scopes (`client` / `litigation` / `patent` / `case`)
+  + per-project quick-adds. **No** approval-gap fix folded in.
+- **Slice 4** = drop legacy `appointments.caldav_uid` / `caldav_etag`.
+  Soft-cap banners only if Slice 2 telemetry says we need them.
+
+### Net effect on §3 schema
+
+No change. `user_calendar_bindings` still ships with the full
+`scope_kind` enum (including `personal_only`). `appointment_caldav_targets`
+unchanged. No `read_only` column in v1.
+
+### Follow-ups to file as separate tasks
+
+1. **`t-paliad-*` (under t-138):** approval-flow + CalDAV remote-edit
+   gap. `ApplyRemoteUpdate` bypasses the approval gate when an external
+   client edits a pending-approval event. Pre-existing in single-cal
+   Phase F. Owner: t-138 maintainer.
+2. **(maybe) `t-paliad-*`:** soft-cap UI if Slice 2 telemetry shows
+   any user near the iCloud-100 / Nextcloud-30 envelope. Not pre-filed
+   — only opens if data warrants.

docs/design-calendar-view-align-2026-05-20.md

@@ -0,0 +1,448 @@
+# Design: Align calendar-view rendering between Events/Termine and Custom Views
+
+**Task:** t-paliad-224 — m/paliad#55
+**Author:** bohr (inventor)
+**Date:** 2026-05-20
+**Status:** ACCEPTED — all 8 (R) defaults confirmed by head 2026-05-20 (msg #2087); coder shift authorised on same branch.
+**Branch:** `mai/bohr/calendar-view-align`
+
+---
+
+## 0. Premise check (verified against live source 2026-05-20)
+
+m's brief mentions two surfaces ("Events/Termine" and "Custom Views' calendar view type"). The live codebase has **three** distinct calendar implementations, not two:
+
+| | A — Events tab | B — Standalone | C — Custom Views |
+|---|---|---|---|
+| URL | `/events?type=…&` calendar tab | `/deadlines/calendar`, `/appointments/calendar` | `/views/{slug}` with `render_spec.shape="calendar"` |
+| Shell TSX | `frontend/src/events.tsx:239-269` (inline `events-calendar-wrap` block) | `frontend/src/deadlines-calendar.tsx`, `frontend/src/appointments-calendar.tsx` | `frontend/src/views.tsx:104` (`views-shape-calendar` host) |
+| Renderer | `frontend/src/client/events.ts:589-656` (`renderCalendar()`) | `frontend/src/client/deadlines-calendar.ts`, `frontend/src/client/appointments-calendar.ts` | `frontend/src/client/views/shape-calendar.ts` (525 lines, mounted from `client/views.ts:227`) |
+| Build entry | `events.html` (one bundle) | `deadlines-calendar.html` + `appointments-calendar.html` (two extra bundles) — `frontend/build.ts:258,261,387,390` | none (mounted into the views host at runtime) |
+| Handler | `handleEventsPage` | `handleDeadlinesCalendarPage`, `handleAppointmentsCalendarPage` — `internal/handlers/handlers.go:470,476`; impls in `internal/handlers/deadlines_pages.go:26`, `internal/handlers/appointments_pages.go:27` | `handleViewsBySlug` |
+
+**Reachability of B (standalone calendars).** `grep` for the URL strings inside `frontend/` finds only `paliadin-context.ts:96,100` (which decode the URL when the user is **already** on the page). The current Sidebar (`frontend/src/components/Sidebar.tsx:162-163`) routes to `/events?type=deadline` and `/events?type=appointment` — the calendar tab inside `/events` is the only UI-reachable calendar today. Routes B exist but are orphaned in navigation; they live for bookmarks / external links / paliadin context.
+
+The brief's choice of canonical renderer ("likely the Custom Views renderer if it's the more recent / general one") is the right one — verified below in §3.
+
+---
+
+## 1. m's intent (as I read it)
+
+> "the calendar views in Events / Termine are different than in the custom views calendar view type. That should be aligned!"
+
+The literal statement is about visual + behavioural parity. Read alongside the brief's "drop the duplicate code path" and the explicit naming of `shape-calendar.ts` / `appointments-calendar.tsx` / `client/appointments-calendar.ts`, the intent is:
+
+1. **One calendar component**, mounted from both the events-page surface and the custom-views surface.
+2. **Identical visual output** when the same items land in either surface.
+3. **No duplicate code path** — orphaned standalone calendar TSX + client + dist pages go.
+4. **Alignment first, not new features** — drag-to-create / week-resize / etc. are explicitly out of scope per the issue body.
+
+The smallest-diff path that delivers that intent is "canonicalise on shape-calendar.ts and fold A in" — see §3.
+
+---
+
+## 2. What actually diverges today
+
+Side-by-side after reading all three implementations (cited line numbers above):
+
+| Dimension | A (`/events` tab) | B (`/deadlines/calendar`, `/appointments/calendar`) | C (Custom Views) |
+|---|---|---|---|
+| Views offered | month only | month only | month + week + day |
+| URL deep-link state | none (calendar month is in-memory, lost on refresh) | none | yes — `?cal_view=…&cal_date=YYYY-MM-DD` |
+| Cell content | day-num + max 4 dots + "+N" | day-num + max 4 dots + "+N" | day-num + max 3 text **pills** + "+N" |
+| Dot/pill colour key | urgency for deadlines (`frist-urgency-overdue/soon/later/done`) + single appointment colour (`events-cal-dot-appointment`) — mixed semantics | (deadlines page) urgency only; (appointments page) appointment-type colours via `termin-type-hearing/meeting/consultation/deadline_hearing` + legend strip | **kind-coded** — `views-calendar-pill--{deadline|appointment|project_event|approval_request}` |
+| Today indicator | accent circle on day-number (`frist-cal-today .frist-cal-day` → coloured pill) | identical to A | border + inset box-shadow ring on entire cell (`views-calendar-cell--today`) |
+| Click cell | opens modal popup (`#events-cal-popup`) listing the day's items | opens modal popup (`#cal-popup`) | drills into **day view** (changes URL via `?cal_view=day&cal_date=…`), no modal |
+| "+N" overflow | rendered as static `.frist-cal-more` span (not clickable) | identical | rendered as a button — opens the day view (same drill as the day-num button) |
+| Empty state | per-month "Keine Einträge im ausgewählten Zeitraum." | per-month "Keine Fristen…" / "Keine Termine…" | per-day in week/day views ("Keine Einträge."), no per-month empty in month view |
+| Toolbar | inline ‹ month-label › + Heute button | identical | view-switcher chips (M/W/D) + ‹ range-label › + (in day/week) "Zurück zum Monat" link |
+| Weekday header | 7 static `.frist-cal-weekday` divs hard-coded in TSX | identical | rendered inline in the JS grid (single grid spans weekday row + day cells) |
+| Mobile fallback | `@media (max-width: 700px)` shrinks cell min-height to 64px (CSS-only) | identical | `<600px` → adds a notice + uses cards-style stack; CSS-only no special media query (notice is data-driven) |
+| Data source | `/api/events` (one fetch, all items unfiltered by date) | `/api/deadlines` or `/api/appointments` separately | `/api/views/{slug}/run` (filter-spec backed, ViewRow[] discriminated by `kind`) |
+| Item shape | `EventListItem` (discriminator field `type`) | `Deadline` or `Appointment` (typed) | `ViewRow` (discriminator field `kind`) |
+| Detail link | `/deadlines/{id}` or `/appointments/{id}` from popup row | identical | direct anchor on the pill/row, no popup |
+| Lang / i18n | `cal.day.*`, `events.calendar.empty` | `cal.day.*`, `appointments.kalender.empty`, `deadlines.kalender.empty`, `appointments.type.*` (legend) | `cal.day.*`, `cal.view.*`, `cal.month.{prev,next}`, `cal.week.*`, `cal.day.no_entries`, `views.calendar.mobile_fallback` |
+
+The two A/B implementations are near-clones of each other — Slice C alignment alone wouldn't fix the bigger "two of these are the same code with a coat of paint" problem.
+
+CSS surface: `.frist-cal-*` is consumed **only** by A + B (verified by grep across `frontend/` + `internal/` — no third party). After the refactor, the entire `.frist-cal-calendar`, `.frist-cal-grid`, `.frist-cal-cell{,-empty,-has}`, `.frist-cal-day`, `.frist-cal-today`, `.frist-cal-dot{*}`, `.frist-cal-more`, `.frist-cal-popup-*`, `.frist-cal-weekday`, `.termin-cal-legend{,-item}`, `.termin-cal-dot`, `.events-cal-dot-appointment` block in `frontend/src/styles/global.css:7464-7620` and `:8019-8023` and `:8680-8700` and `:11519-11533` is deletable. About **180 lines of CSS** go away.
+
+---
+
+## 3. Recommended design (TL;DR)
+
+| Area | Recommendation | Smallest-diff alternative considered & rejected |
+|---|---|---|
+| **Canonical renderer** | `shape-calendar.ts` is the canonical renderer. Extract its mount API behind a small `mountCalendar(host, items, opts)` boundary so both /events and /views call it. | Two-way merge (cherry-pick best of both into a third component) — strictly more code, no clean canon to point coders at later. |
+| **/events calendar tab** | Replaces inline month grid + popup with a `mountCalendar(host, items, { urlState: true, defaultView: "month" })` call. Drops `renderCalendar()`, `openCalPopup()`, `wireCalNav()`, and the entire `events-cal-*` TSX subtree. Gains month/week/day views, drill-down, URL state — for free. | Keep A as-is, only converge B with C: leaves the headline divergence (the one m sees in the UI today) unresolved. |
+| **/deadlines/calendar + /appointments/calendar** | Routes redirect 301 to `/events?type=deadline&view=calendar` and `/events?type=appointment&view=calendar`. TSX + client + dist artefacts deleted. `paliadin-context.ts` entries for the old paths kept (the redirect target carries through to the same context label). | Delete routes outright: breaks bookmarks. A 301 is one line per route. |
+| **Data adapter** | `client/events.ts` already loads `EventListItem[]` from `/api/events`. Adapter is a one-liner field rename (`type` → `kind`) — the rest of the shape is identical to `ViewRow`. Existing API endpoints unchanged. | Migrate /events tab to `/api/views/{slug}/run` with an ad-hoc filter spec: pulls a lot of substrate (filter spec assembly, view caching) into the events flow for zero gain when the existing API already returns the right shape. |
+| **Per-shape config** | Reuse `CalendarConfig` (`default_view`, `show_weekends`). `/events` calendar tab passes `default_view: "month"` so it stays month-first; future surfaces can pass `"week"` if needed. | Hard-code "month" inside mountCalendar — closes the door on /events week/day tabs we may want later. |
+| **Subtype dot colouring** | Drop the per-appointment-type colour legend (deadline-only colouring was urgency-based and mixed semantics with subtype anyway). Pills are kind-coded only — same as `/views/{slug}` with `shape=calendar` does today. Subtype colouring can be added later as a `CalendarConfig.subtype_colors: bool` flag if a user asks. | Preserve the type-colour legend on the events page: only the orphaned /appointments/calendar page exposes it today, and bringing it into /events means designing the legend at the events-page level (events can be deadlines OR appointments OR both per current chip filter). Easier to defer until requested. |
+| **CSS** | Delete the `.frist-cal-*` block entirely (~180 lines). The single source of truth becomes `.views-calendar-*`. Same lime-green accent (`var(--color-accent)`), same surface tokens — colour parity is automatic. | Keep both blocks: leaves a CSS minefield where future devs are unsure which class to use. |
+| **i18n** | New keys land under the existing `cal.*` namespace (`cal.view.month/week/day`, `cal.day.back_to_month`, `cal.day.open_day`, `cal.day.no_entries`, `views.calendar.mobile_fallback`). These already exist for Custom Views — no new strings needed. Delete the `appointments.kalender.*`, `deadlines.kalender.*`, `appointments.type.*` (legend-only) keys, plus `events.calendar.empty` (replaced by `cal.day.no_entries` at the day-view level). | Keep DE/EN strings as-is for compatibility: just delete-and-go. The keys aren't part of any user-saved data. |
+
+**Net code change (estimated by file):**
+
+- **Delete:** `frontend/src/appointments-calendar.tsx`, `frontend/src/deadlines-calendar.tsx`, `frontend/src/client/appointments-calendar.ts`, `frontend/src/client/deadlines-calendar.ts` — together ~560 lines.
+- **Trim:** ~80 lines from `events.tsx` (calendar subtree), ~140 lines from `client/events.ts` (`renderCalendar`/`openCalPopup`/nav handlers/calendar state).
+- **Trim:** ~180 lines from `global.css` (`.frist-cal-*` block).
+- **Add:** `frontend/src/client/calendar/mount-calendar.ts` — the extracted public API (~60 lines incl. types).
+- **Refactor:** `frontend/src/client/views/shape-calendar.ts` becomes a 30-line wrapper that calls `mountCalendar` with `urlState: true` and the spec's calendar config. Most of the existing 525 lines move into `mount-calendar.ts` verbatim.
+- **Backend:** 4 lines total — turn the two standalone-calendar handlers into 301 redirects (one line each, plus matching delete of the standalone HTML file write in `frontend/build.ts:387,390`).
+
+Net: **~700 LOC removed, ~100 LOC added, zero new endpoints, zero schema changes, zero new dependencies.**
+
+---
+
+## 4. Architecture sketch
+
+```
+                          ┌─────────────────────────────┐
+                          │  frontend/src/client/       │
+                          │    calendar/                │
+                          │      mount-calendar.ts ★    │  ← new shared module
+                          │      types.ts (CalendarItem)│
+                          └──────────────┬──────────────┘
+                                         │
+                ┌────────────────────────┼─────────────────────────┐
+                │                        │                         │
+   client/events.ts (Kalender tab)   client/views/                 │
+                │                    shape-calendar.ts             │
+                │                    (thin wrapper)                │
+                │                        │                         │
+                │                        ▼                         │
+                │                    client/views.ts               │
+                │                    paintRows(…, "calendar")      │
+                │                                                  │
+                └──────────────────────────────────────────────────┘
+
+           Data flows:
+           A: /events  → fetch /api/events?type=…&status=…    → EventListItem[]
+                       → toCalendarItem(items)                 → CalendarItem[]
+                       → mountCalendar(host, items, opts)
+
+           C: /views/{slug} → fetch /api/views/{slug}/run     → ViewRow[]
+                            → toCalendarItem(rows) (noop-ish: rename ‘type’→‘kind’ already done)
+                            → renderCalendarShape() → mountCalendar(host, items, opts)
+```
+
+### 4.1 The shared module (`mount-calendar.ts`)
+
+```ts
+// frontend/src/client/calendar/mount-calendar.ts
+import { t, tDyn, getLang, type I18nKey } from "../i18n";
+
+export type CalendarKind =
+  | "deadline" | "appointment" | "project_event" | "approval_request";
+
+export interface CalendarItem {
+  kind: CalendarKind;
+  id: string;
+  title: string;
+  event_date: string;           // ISO-8601; first 10 chars are yyyy-mm-dd
+  project_id?: string;
+  project_title?: string;
+  project_reference?: string;
+}
+
+export interface CalendarOpts {
+  defaultView?: "month" | "week" | "day";
+  /** If true, calendar reads/writes ?cal_view + ?cal_date (or the prefixed
+   *  equivalents); if false, state is in-memory only (use for embedded
+   *  calendars where URL state belongs to the host page). */
+  urlState?: boolean;
+  /** Optional prefix for URL params (default: empty). Set if more than
+   *  one calendar might live on the same URL. */
+  urlPrefix?: string;
+  /** Optional override: how to render a row's href. Default uses the
+   *  kind→/deadlines|/appointments|/inbox|/projects routing the existing
+   *  shape-calendar.ts ships with. */
+  hrefFor?: (item: CalendarItem) => string;
+}
+
+export interface CalendarHandle {
+  /** Re-render with a new item set (e.g. after a filter change in /events). */
+  update(items: CalendarItem[]): void;
+  /** Tear down listeners + clear host. */
+  destroy(): void;
+}
+
+export function mountCalendar(
+  host: HTMLElement,
+  items: CalendarItem[],
+  opts?: CalendarOpts,
+): CalendarHandle;
+```
+
+Internals lifted verbatim from `shape-calendar.ts` (toolbar, renderMonth/Week/Day, renderPill, renderRowAnchor, bucketByDate, filterByDay, startOfWeek, shift, isToday, isoDate, formatRangeLabel, formatWeekHeader, readView/Anchor, writeURL). Two tweaks:
+
+- `readView`/`readAnchor`/`writeURL` accept the `urlPrefix` so embedded calendars on `/events?…&` don't clobber other pages' `?cal_view`.
+- `urlState: false` skips the URL read/write entirely — initial state comes from `opts.defaultView` and "today".
+
+### 4.2 `shape-calendar.ts` (after refactor)
+
+```ts
+import type { RenderSpec, ViewRow } from "./types";
+import { mountCalendar, type CalendarItem } from "../calendar/mount-calendar";
+
+export function renderCalendarShape(
+  host: HTMLElement, rows: ViewRow[], render: RenderSpec,
+): void {
+  const items: CalendarItem[] = rows.map(r => ({
+    kind: r.kind,
+    id: r.id, title: r.title,
+    event_date: r.event_date,
+    project_id: r.project_id,
+    project_title: r.project_title,
+    project_reference: r.project_reference,
+  }));
+  mountCalendar(host, items, {
+    defaultView: render.calendar?.default_view ?? "month",
+    urlState: true,
+  });
+}
+```
+
+### 4.3 `client/events.ts` (calendar arm only)
+
+```ts
+// near the top
+import { mountCalendar, type CalendarItem, type CalendarHandle } from "./calendar/mount-calendar";
+
+// state
+let calendar: CalendarHandle | null = null;
+
+// inside applyView() when switching to calendar view:
+function ensureCalendarMounted(host: HTMLElement, items: CalendarItem[]) {
+  if (calendar) { calendar.update(items); return; }
+  calendar = mountCalendar(host, items, { urlState: false, defaultView: "month" });
+}
+
+// inside applyView() when switching AWAY from calendar:
+function teardownCalendar() {
+  if (calendar) { calendar.destroy(); calendar = null; }
+}
+
+function toCalendarItem(it: EventListItem): CalendarItem {
+  return {
+    kind: it.type as CalendarKind,    // type "deadline" | "appointment"
+    id: it.id, title: it.title,
+    event_date: itemDateISO(it) + "T00:00:00",
+    project_id: it.project_id,
+    project_title: it.project_title,
+    project_reference: it.project_reference,
+  };
+}
+```
+
+`urlState: false` for /events because the page already owns its own URL contract (`?type=`, `?status=`, etc.) and a second calendar deep-link param set would compete with future events-page state. (See §11 Q3 — this is a defaultable preference, not a hard constraint.)
+
+### 4.4 Standalone calendar redirects
+
+```go
+// internal/handlers/deadlines_pages.go
+func handleDeadlinesCalendarPage(w http.ResponseWriter, r *http.Request) {
+    http.Redirect(w, r, "/events?type=deadline&view=calendar", http.StatusMovedPermanently)
+}
+
+// internal/handlers/appointments_pages.go
+func handleAppointmentsCalendarPage(w http.ResponseWriter, r *http.Request) {
+    http.Redirect(w, r, "/events?type=appointment&view=calendar", http.StatusMovedPermanently)
+}
+```
+
+The `view=calendar` query string is a **new** events-page URL contract — needs a one-line addition to `client/events.ts:readURLState()` (which already reads `type`, `status`) to honour `view`. Today the view is in-memory only; pinning it to URL is a free side-benefit of this refactor (and lets the redirects land users on the calendar, not on the cards view).
+
+Build pipeline: delete entries `frontend/build.ts:258`, `261`, `387`, `390` (the two standalone calendar bundles + HTML writes). `paliadin-context.ts:96,100` keep their URL matches — the 301 fires server-side, so the client only ever sees `/events?type=…&view=calendar` (which already maps to a paliadin context).
+
+---
+
+## 5. Visual + interaction parity audit
+
+Walking m's brief checklist against the proposed end-state (assuming the user is on /events Kalender tab after this refactor):
+
+| Brief item | Today (A) | After refactor | Matches /views? |
+|---|---|---|---|
+| Event tile shape | dot | **pill with text** | ✓ |
+| Color | mixed (urgency + single appointment colour) | **kind-coded** (deadline / appointment / project_event / approval_request) | ✓ |
+| Click behaviour (navigate to detail) | modal popup → anchor | **direct anchor on pill** (no modal) | ✓ |
+| Today highlight | accent circle on day-num | **border ring on entire cell + box-shadow** | ✓ |
+| Weekday header | static TSX divs | **rendered inline in the JS grid** | ✓ |
+| Date-range / project / type filter shape | same `EventListItem[]` post-adapter | identical adapter feeds same `CalendarItem[]` shape | ✓ shared loader contract |
+
+Two surfaces still differ after the refactor — and that's by design:
+
+1. **/events** still has its three view chips above the calendar (Karten / Liste / Kalender) because the events page is multi-shape at the outer level. /views also has its outer shape chips (Liste / Karten / Kalender / Timeline). Both surfaces' shape chips look identical (`agenda-chip-row`).
+2. **/events** keeps the events-page-level filters (type chip, status select, project select, event-type/appointment-type filters) above the calendar; /views shows its filter-bar (filter-spec-driven axes) instead. Both surfaces' filter chrome is governed by the page, not the calendar — the calendar component itself is the same DOM either way.
+
+---
+
+## 6. Mobile parity
+
+`shape-calendar.ts` today does a mobile fallback at <600px (`mountCalendar` would carry this behaviour over). The fallback appends a single `<p>` notice — "Auf schmalen Bildschirmen empfehlen wir die Listenansicht" or equivalent (i18n key `views.calendar.mobile_fallback`). Cells still render and are responsive (the existing CSS uses CSS-grid + 1fr columns).
+
+After this refactor:
+
+- /events Kalender tab: gets the **same** notice + a contextual hint suggesting "Wechsle zu Karten oder Liste" (the events-page shape chips). One new i18n key, OR reuse the existing `views.calendar.mobile_fallback` and accept that it mentions "Listenansicht" generically.
+- /views Kalender shape: behaviour unchanged from today.
+
+Mobile audit boxes ticked:
+
+| | Today A | Today B | Today C | After |
+|---|---|---|---|---|
+| Cell shrinks on narrow viewport | ✓ (min-height 64px) | ✓ | partial (cells stay 80px) | ✓ (carry the C behaviour, plus the @media min-height shrink ported) |
+| Touch target size on pills | n/a (dots, not tappable) | n/a | OK (8px+ at 1x) — but verify on a real phone during coder smoke | OK |
+| Modal vs drill-down | modal (small viewports lose layout) | modal | drill-down (changes URL — natural back button) | drill-down across both surfaces |
+| Sidebar collision | sidebar collapses to bottom nav under 768px (existing behaviour) | identical | identical | identical |
+
+One coder-time TODO: verify the drill-down day-view is comfortable on mobile (it's a vertical list, should be fine, but worth one Playwright screenshot during smoke).
+
+---
+
+## 7. Tests + smoke
+
+Existing test coverage relevant to this refactor:
+
+- `frontend/src/client/views/shape-timeline-cv.test.ts` — sibling of shape-calendar, no calendar-specific tests today. Add `frontend/src/client/calendar/mount-calendar.test.ts` for the extracted module.
+- No Go tests touch handler dispatch for `/deadlines/calendar` or `/appointments/calendar` specifically (verified by grep).
+- `internal/services/render_spec_test.go` covers `CalendarConfig.validate()` — unchanged.
+
+New test plan:
+
+1. **`mount-calendar.test.ts` (new)** — table-driven:
+   - Empty `items[]` → month view renders 7-column grid + no pills + (for /views) per-day "no entries" only in day/week views.
+   - `items[]` with mixed kinds → pills get the correct `views-calendar-pill--{kind}` class.
+   - `?cal_view=week` → week column grid renders.
+   - Today bucket flagged with `--today` class on the correct cell.
+   - `+N` overflow renders when items per day > MAX_PILLS_PER_MONTH_CELL (3).
+   - `update(items)` after first mount swaps content without leaking listeners (assert no double-fire on month-nav click).
+2. **`client/events.ts`** — light test (existing pattern): after refactor, switching to Kalender chip mounts the calendar, switching away calls `destroy()`. No test exists for events.ts today (it's mostly DOM glue), so this is a new test or skip with a comment.
+3. **Smoke (manual, with `bun run build` + dev server)**:
+   - /events Kalender tab loads, shows pills, click pill navigates to detail.
+   - Day-num click → day view (URL changes if urlState is on for /events per Q3).
+   - /views/{slug} with `render_spec.shape=calendar` (need a saved view or temporary system view to exercise) still loads identical pills + drill-down.
+   - /deadlines/calendar → 301 → /events?type=deadline&view=calendar lands on Kalender tab.
+   - /appointments/calendar → 301 → /events?type=appointment&view=calendar lands on Kalender tab.
+   - DE + EN language toggle on both surfaces.
+   - Light + dark theme on both.
+4. **Build gate**: `go build ./... && go test ./internal/... && cd frontend && bun run build` must all be clean (per task brief).
+
+---
+
+## 8. Risks + mitigations
+
+| Risk | Likelihood | Mitigation |
+|---|---|---|
+| Custom Views users have saved views with `shape=calendar` and rely on the current week/day behaviour | low (shape-calendar is the canonical, only behaviour I'm changing about it is making `urlState` opt-in) | The refactor is structural — same toolbar, same drill-down, same URL params for /views. `urlState=true` stays the default for that surface. |
+| `paliadin-context.ts` keys (`deadlines.calendar`, `appointments.calendar`) become unreachable after redirects | low | The 301 fires before the client sees the URL; new URL maps to existing `events` context. If we want to preserve the labels, add `events?type=…&view=calendar` matchers in paliadin-context (one if-branch each) — recommend doing this in the same coder PR for tidiness. |
+| Subtype colouring loss is a feature regression for someone who used /appointments/calendar's legend | low | The page is unreachable from the UI; nobody reaches it without a bookmark. Q4 below confirms with m. |
+| Events-page calendar `urlState: false` means refresh loses the Kalender chip selection | medium (today: same — calendar is in-memory either way) | Either accept (status quo) or extend events.ts URL state to include `view` (~3 lines). Q3 below. |
+| /events fetch is unfiltered by date (loads everything); on a busy team Kalender may load slow | medium (existing behaviour) | Not addressed by this refactor. Filed as follow-up in §10. Filter spec / /api/views path solves it but is out of scope here. |
+| The 301 redirect to `/events?type=…&view=calendar` requires events.ts to honour `view=calendar` from the URL | hard requirement | Must include this in the coder PR. ~3 lines in `readURLState()`. |
+
+---
+
+## 9. What stays "out of scope" (consistent with the issue body)
+
+- New calendar UX: drag-to-create, week-resize, hover-preview, multi-day event spans.
+- Performance: switching `/events` to a date-window-bounded fetch (today it loads everything and filters client-side).
+- A unified events↔views landing (e.g. /events as a Saved View). Discussed in `design-events-unification-2026-05-04.md` and `design-data-display-model-2026-05-06.md`; deliberately not folded in here.
+- /agenda surface. It's a timeline-grouped feed, not a calendar grid — separate conversation if m wants to converge it.
+- Subtype dot colouring (deferred per §3 trade-off row).
+
+---
+
+## 10. Follow-ups (file as separate issues after this lands)
+
+1. **Date-windowed loading for /events Kalender.** Pass `?from=…&to=…` to `/api/events` matched to the visible month so a 5-year-old project history doesn't ship to the client on every Kalender open. Backend already accepts `from`/`to` per `internal/handlers/events.go`. Small.
+2. **Per-shape config: subtype colouring.** Add `CalendarConfig.subtype_colors` (bool, default false). Surface a `--subtype-{value}` modifier on the pill so the appointment-type colour key can come back per-view, if a user asks.
+3. **Multi-day event spans.** Most events are single-day; deadlines are point-in-time. But appointments have `end_at`. Today neither A nor C surfaces span-rendering. Defer until requested.
+4. **/agenda convergence.** /agenda is a different visual (day-grouped feed), but the data shape is the same `EventListItem`. If m wants /agenda to disappear (it's a sibling overview entry today per `design-events-unification-2026-05-04.md`), consider folding it into /events as a fourth shape ("feed" / "agenda"). Out of this design's scope.
+
+---
+
+## 11. Open questions for head (NO AskUserQuestion — answered via mai instruct)
+
+> The role brief disables `AskUserQuestion` for this task. Each question below has a defaulted answer marked **(R)**; head/m can confirm or override via `mai instruct head`. After head replies, decisions land in §12.
+
+**Q1 — Canonical renderer.** Adopt `shape-calendar.ts` as the canon, fold A into it (§3 sketch), and retire the two standalone routes B as 301-redirects to `/events?type=…&view=calendar`?
+- **(R) Yes** — covers m's intent ("pick the canonical one — likely the Custom Views renderer"). Net code goes down, no schema changes.
+- Alternative: keep the standalone routes as standalone pages but make them call `mountCalendar` internally — adds nothing for users (page is unreachable), wastes a build target each.
+- *(answer: yes / keep-standalone / something-else)*
+
+**Q2 — Events-page Kalender tab: drill-down vs modal-popup.** Today /events Kalender opens a modal listing the day's items. After the refactor, clicking a day-num drills into the day view (changes view chip, same URL component, but the page swaps to a day-list). Drop the modal entirely?
+- **(R) Drop the modal** — matches /views behaviour, gives a real day-view (not just a list of links), and removes one popup-management code path.
+- Alternative: keep the modal on /events only (parity break — defeats the point of the issue).
+- *(answer: drop / keep)*
+
+**Q3 — URL state for the /events calendar.** Should the /events Kalender persist its view (month/week/day) and date in the URL via `?cal_view=…&cal_date=…` (matching /views)?
+- **(R) Yes, persist** — refresh-stable, shareable, ~3 lines in `readURLState()`. /views does it. Cost is owning the param contract on /events.
+- Alternative: in-memory only — today's behaviour. Keeps /events URL surface minimal.
+- *(answer: persist / in-memory)*
+
+**Q4 — Subtype dot colouring on appointments.** The orphaned /appointments/calendar today colours dots by appointment_type (Verhandlung / Besprechung / Beratung / Fristverhandlung) with a legend strip. After the refactor pills are kind-coded only (deadline vs appointment vs …). Drop subtype colouring?
+- **(R) Drop now, file as follow-up** (§10.2) — page is UI-unreachable today; nobody will notice; can come back as a `CalendarConfig.subtype_colors` flag if/when requested.
+- Alternative: preserve subtype colouring on /events Kalender tab as well, with a fresh legend matching the new pill colours.
+- *(answer: drop / preserve)*
+
+**Q5 — Mobile fallback text.** /views Kalender shows a notice "Auf schmalen Bildschirmen empfehlen wir die Listenansicht" (key `views.calendar.mobile_fallback`). Reuse the same key on /events, or add an /events-specific key recommending the events-page "Karten" or "Liste" shape?
+- **(R) Reuse the existing key** — generic phrasing covers both surfaces; both have Karten/Liste alternatives.
+- Alternative: dedicated key per surface — clearer copy but more strings to maintain.
+- *(answer: reuse / dedicated)*
+
+**Q6 — Test approach for the extracted module.** Add `mount-calendar.test.ts` with the seven listed cases (§7.1), OR also add a Playwright smoke that drives the new flow end-to-end through both surfaces?
+- **(R) Unit tests + manual smoke gauntlet** — matches the codebase's existing test layout (most client/* tests are unit-level; Playwright is reserved for fewer flows). Manual smoke per §7.3 is the brief's bar.
+- Alternative: unit + Playwright.
+- *(answer: unit-only / unit-plus-playwright)*
+
+**Q7 — Sequencing across PRs.** One PR (extract + adopt + retire + CSS prune) or three (extract, then adopt+retire, then CSS prune)?
+- **(R) One PR** — refactors that don't bisect well are worse split (each intermediate state has unused exports / dead code paths / orphaned CSS classes for a few hours). The diff is reviewable in one read because it's mostly moves + deletes.
+- Alternative: three PRs — easier rollback at each step, but you'd have to land #2 before m sees any UI alignment, which loses the point.
+- *(answer: one-pr / three-pr)*
+
+**Q8 — When (if at all) to delete /events `events.calendar.empty` i18n key.** Replaced by `cal.day.no_entries` in the new flow. Drop now or leave as a dead key in `i18n-keys.ts` for one release?
+- **(R) Drop now** — i18n-keys.ts is the source of truth; dead keys aren't enforced at compile time but they're a slow-rotting maintenance tax. /events' new calendar surface doesn't render an "empty month" message any more (per-day "no entries" is the only empty state, matching /views).
+- Alternative: leave for one release as a soft-deprecate.
+- *(answer: drop / leave)*
+
+---
+
+## 12. m's decisions (2026-05-20, via head msg #2087)
+
+Head accepted all 8 (R) defaults in one round-trip ("Design accepted in
+full — all 8 (R) defaults stand"). Recorded verbatim below; each entry
+is the (R) pick from §11.
+
+- **Q1 — Canonical renderer:** Yes. Canonicalise on `shape-calendar.ts`; fold A into it via extracted `mountCalendar()`; retire B as 301 redirects to `/events?type=…&view=calendar`.
+- **Q2 — Drill-down vs modal:** Drop the modal on /events. Day-num/+N click drills into the day view, matching /views.
+- **Q3 — URL state on /events:** Persist. /events Kalender reads/writes `?cal_view=…&cal_date=…` like /views does. Adds `view=calendar` to `client/events.ts:readURLState()` so refreshes/redirects land on the Kalender tab.
+- **Q4 — Subtype dot colouring:** Drop now. Filed as follow-up §10.2. Pills are kind-coded only after the refactor (deadline / appointment / project_event / approval_request).
+- **Q5 — Mobile fallback text:** Reuse the existing `views.calendar.mobile_fallback` key on /events as well — generic phrasing covers both surfaces.
+- **Q6 — Test approach:** Unit tests (`mount-calendar.test.ts`) + manual smoke gauntlet (§7.3). No Playwright on this refactor.
+- **Q7 — Sequencing:** One PR. Extract + adopt + retire + CSS prune land together on `mai/bohr/calendar-view-align`.
+- **Q8 — Empty-state i18n key:** Drop dead keys now (`events.calendar.empty`, `appointments.kalender.*`, `deadlines.kalender.*`, appointment-type legend keys not used elsewhere).
+
+---
+
+## 13. Coder hand-off (after m's go on §11)
+
+Once §12 is filled in, the coder shift can proceed in this order:
+
+1. Create `frontend/src/client/calendar/mount-calendar.ts` + `frontend/src/client/calendar/mount-calendar.test.ts`. Lift the shape-calendar internals; add `update`/`destroy` to the returned handle; pipe `urlState` + `urlPrefix` through.
+2. Update `frontend/src/client/views/shape-calendar.ts` to delegate to `mountCalendar` (≈30 lines after the lift).
+3. Update `frontend/src/client/events.ts`: import `mountCalendar`, replace `renderCalendar`/`openCalPopup` and nav handlers with a `mountCalendar(host, items, { urlState: <per Q3>, defaultView: "month" })` call inside the existing `applyView()` branch. Add the `view=calendar` URL state handling per Q3.
+4. Update `frontend/src/events.tsx`: strip the `events-calendar-wrap` inline DOM (toolbar + grid + modal). The empty container `<div id="events-shape-calendar" />` plus a wrapper class is enough — `mountCalendar` builds the DOM.
+5. Delete `frontend/src/appointments-calendar.tsx`, `frontend/src/deadlines-calendar.tsx`, `frontend/src/client/appointments-calendar.ts`, `frontend/src/client/deadlines-calendar.ts`.
+6. Update `frontend/build.ts`: remove the `*-calendar.ts` entry-point lines (≈250s) and the `*-calendar.html` writes (≈387s).
+7. Update `internal/handlers/deadlines_pages.go` + `internal/handlers/appointments_pages.go`: turn the two calendar handlers into 301 redirects to `/events?type=…&view=calendar`.
+8. Update `frontend/src/styles/global.css`: delete `.frist-cal-*`, `.termin-cal-*`, `.events-cal-dot-appointment`, the 700px-media tweak (lines ~7464-7620, ~8019-8023, ~8680-8700, ~11519-11533). Sanity-check no other consumer (already verified via grep — none).
+9. Update i18n: drop `appointments.kalender.*`, `deadlines.kalender.*`, `appointments.type.*` (legend keys only — keep type values used elsewhere), `events.calendar.empty` per Q8. Make sure `cal.view.*`, `cal.day.no_entries`, `cal.day.back_to_month`, `cal.day.open_day`, `views.calendar.mobile_fallback` (or a new events-specific key per Q5) all exist DE + EN — most already do.
+10. `paliadin-context.ts`: optional one-line addition to map `events?view=calendar` to the new context label.
+11. Run `go build ./... && go test ./internal/... && cd frontend && bun run build`.
+12. Manual smoke per §7.3.
+13. Commit. `mai report completed` with SHA per task brief.
+
+Estimated coder shift: one PR per Q7 (R).
+
+---

docs/design-date-range-picker-2026-05-25.md

@@ -0,0 +1,856 @@
+# Symmetric date-range picker — design
+
+**Date:** 2026-05-25
+**Task:** t-paliad-248 (Gitea m/paliad#79)
+**Inventor:** atlas
+**Branch:** `mai/atlas/inventor-symmetric-date`
+**Status:** READ-ONLY design. Awaiting head's go/no-go before coder shift.
+
+---
+
+## §0 TL;DR
+
+Today paliad has **three independent date-range schemes** scattered across surfaces:
+
+1. **`/agenda`** — future-only chip row [7|14|30|90 Tage], state `rangeDays`.
+2. **`/admin/audit-log`** — past-only `<select>` [24h|7d|30d|custom|all] + manual `<input type="date">` pair.
+3. **`/projects/:id/chart`** — symmetric `RangePreset` [1y|2y|all|custom] + manual date pair.
+
+…plus a **fourth, unified `TimeHorizon` contract** (`internal/services/filter_spec.go`, mirrored in `frontend/src/client/views/types.ts`) that's used by the filter-bar, Verlauf, Custom Views, and InboxFilterBar — but its "Anpassen" custom-range chip is still stubbed (`filter-bar/axes.ts:105-112`, marked Phase 2, disabled, "coming soon" tooltip).
+
+The fix is **not** "build a fourth scheme." The fix is to **finish the TimeHorizon contract** (add `past_14d`, `next_14d`, `past_all`, `next_all`), build **one reusable `<DateRangePicker>`** that emits a `TimeSpec`, then migrate the three legacy affordances to it.
+
+**Layout (m's brief, locked):**
+
+```
+┌──────────────────────────────────────────────────────────────┐
+│ [Zeitraum: Nächste 30 Tage ▾]                                │
+└──────────────────────────────────────────────────────────────┘
+                ↓ click to open
+┌──────────────────────────────────────────────────────────────┐
+│  Vergangenheit          (ALLE)          Zukunft              │
+│  [Ganze Vergangenheit] [⌖ ALLE] [Ganze Zukunft]              │
+│  [90 T] [30 T] [14 T] [7 T]   [7 T] [14 T] [30 T] [90 T]     │
+│                                                              │
+│  ── oder benutzerdefiniert ──                                │
+│  Von [____.____.____]  Bis [____.____.____]   [Anwenden]     │
+└──────────────────────────────────────────────────────────────┘
+```
+
+**Slice plan:**
+
+- **Slice A** — `<DateRangePicker>` component + 4 new horizon constants (`past_14d`, `next_14d`, `past_all`, `next_all`). Wired onto filter-bar `time` axis first (lights up Verlauf + InboxFilterBar + views simultaneously by replacing the stubbed Phase-2 chip).
+- **Slice B** — `/agenda` migrates (highest-traffic standalone consumer).
+- **Slice C** — `/admin/audit-log` + `/projects/:id/chart` migrate. Each surface picks the preset subset it cares about.
+- **Slice D** *(optional, later)* — upckommentar-style two-handle slicer replaces the inline date-pair for the "custom" mode.
+
+**Hard rules honoured:**
+
+- No new top-level table or migration in Slice A — purely additive enum values + Go switch arms.
+- No new dependency in Slice A — slicer is deferred (it's a non-trivial port from Svelte to paliad's plain TSX renderer).
+- Backward-compatible URL shape — each surface keeps its current short-alias parser (e.g. `?range=30` → `horizon=next_30d`) and additionally accepts the canonical `?horizon=…&from=…&to=…`.
+
+---
+
+## §1 Current state — every date-range affordance
+
+Cataloguing **every** place a paliad user picks a past/future window, with file:line refs.
+
+### 1.1 `/agenda` — future-only chip row
+
+`frontend/src/agenda.tsx:64-67`:
+
+```tsx
+<button className="agenda-chip" data-range="7"  >7 Tage</button>
+<button className="agenda-chip" data-range="14" >14 Tage</button>
+<button className="agenda-chip" data-range="30" >30 Tage</button>
+<button className="agenda-chip" data-range="90" >90 Tage</button>
+```
+
+State machine `frontend/src/client/agenda.ts:80-104`:
+
+- `state.rangeDays ∈ {7,14,30,90}` (set `VALID_RANGES`). Default `30`.
+- URL: `?range=30&types=…&event_type=…`.
+- Fetch: `GET /api/agenda?from=<today>&to=<today+rangeDays-1>&types=…`.
+- **Future-only by construction** — m's complaint applies precisely here. No "past 7 days" affordance, no "all" affordance.
+
+### 1.2 `/admin/audit-log` — past-only `<select>` + manual date pair
+
+`frontend/src/admin-audit-log.tsx:50-65`:
+
+```tsx
+<select id="audit-range">
+  <option value="24h">Letzte 24h</option>
+  <option value="7d" selected>Letzte 7 Tage</option>
+  <option value="30d">Letzte 30 Tage</option>
+  <option value="custom">Benutzerdefiniert</option>
+  <option value="all">Alles</option>
+</select>
+<!-- custom toggles a date-pair: -->
+<input type="date" id="audit-from" />
+<input type="date" id="audit-to" />
+```
+
+State machine `frontend/src/client/admin-audit-log.ts:135-174`:
+
+- `rangePresetToFrom(preset)` converts `"24h" | "7d" | "30d"` → `Date`. `"custom"` reads `from`/`to` inputs. `"all"` clears both bounds.
+- URL: `?source=…&range=7d&q=…&from=…&to=…&limit=…&before_ts=…&before_id=…` (cursor-paged).
+- **Past-only by construction.** No future-projection — this is an audit log, looking forward makes no sense.
+
+### 1.3 `/projects/:id/chart` — symmetric `RangePreset`
+
+`frontend/src/client/views/types.ts:77-79`:
+
+```ts
+range_preset?: "1y" | "2y" | "all" | "custom";
+range_from?: string;
+range_to?: string;
+```
+
+UI `frontend/src/projects-chart.tsx:78-82`:
+
+```tsx
+<input type="date" id="projects-chart-range-from" />
+<input type="date" id="projects-chart-range-to" />
+```
+
+State machine `frontend/src/client/projects-chart.ts:73-118`:
+
+- `rangeFromURL()` → `{preset, from?, to?}` with default `"1y"`.
+- "1y" = `today-1y..today+1y`, "2y" = `today-2y..today+2y`, "all" derived from loaded events, "custom" = read inputs.
+- URL: `?range=1y&from=YYYY-MM-DD&to=YYYY-MM-DD`.
+- **Symmetric around today** by construction — this is a chart, not a filter; the user is panning a viewport, not picking a fan.
+
+### 1.4 `views-editor.tsx` (Custom Views config form)
+
+`frontend/src/views-editor.tsx:102-109`:
+
+```tsx
+<select id="editor-time-horizon">
+  <option value="next_7d">Nächste 7 Tage</option>
+  <option value="next_30d">Nächste 30 Tage</option>
+  <option value="next_90d">Nächste 90 Tage</option>
+  <option value="past_30d">Letzte 30 Tage</option>
+  <option value="past_90d">Letzte 90 Tage</option>
+  <option value="any">Beliebig</option>
+</select>
+```
+
+- Mixes past + future, but only 5 horizons exposed (no 14d, no past_7d, no all).
+- Persists into `paliad.user_views.filter_spec` (JSON column) as a `TimeSpec`.
+- **This is the closest existing affordance to m's symmetric fan**, but rendered as a plain `<select>` and incomplete.
+
+### 1.5 Filter-bar `time` axis (riemann's t-paliad-163 Phase 1)
+
+`frontend/src/client/filter-bar/axes.ts:65-115`:
+
+- Renders a chip cluster: `[next_7d, next_30d, next_90d, past_30d, any]` (default presets, line 77-79).
+- **"Anpassen" chip is disabled** with `coming_soon` tooltip (line 108-112). This is the documented Phase 2 substrate.
+- Surfaces declaring axis `time` thread their own preset list via `RenderAxisOpts.timePresets` — e.g. Verlauf overrides to `["past_7d","past_30d","past_90d","any"]` (`frontend/src/client/projects-detail.ts:2310`).
+
+Consumers:
+- `/projects/:id` Verlauf (`projects-detail.ts:2296` initial state, 2310 preset override).
+- `/views` and `/views/:id` (Custom Views runtime).
+- `/inbox` (`InboxFilterBar` flow — t-paliad-138/139 derived inbox).
+
+### 1.6 `horizonBounds()` — the materializer
+
+`frontend/src/client/projects-detail.ts:393-406` mirrors the Go-side `computeViewSpecBounds()` (`internal/services/view_service.go:156-187`):
+
+```ts
+case "past_7d":  return { from: offset(-7),  to: offset(1) };
+case "past_30d": return { from: offset(-30), to: offset(1) };
+case "past_90d": return { from: offset(-90), to: offset(1) };
+case "next_7d":  return { from: day,         to: offset(7) };
+case "next_30d": return { from: day,         to: offset(30) };
+case "next_90d": return { from: day,         to: offset(90) };
+default:         return {};
+```
+
+(Backend equivalent: `internal/services/view_service.go:160-186`.)
+
+### 1.7 Single-date inputs (NOT date-range — listed for completeness)
+
+These are out of scope but mentioned so the audit is exhaustive:
+
+- `verfahrensablauf.tsx:174` — `#trigger-date` (calculator anchor).
+- `fristenrechner.tsx:496,504,616` — `#trigger-date`, `#priority-date`, `#event-date` (calculator).
+- `admin-rules-edit.tsx:265` — `#preview-trigger-date`.
+- `deadlines-detail.tsx:82` — `#deadline-due-edit` (inline-edit).
+- `deadlines-new.tsx:116` — `#deadline-due` (form).
+- `appointments-new.tsx`, `appointments-detail.tsx` — `start_at`/`end_at`.
+- `projects-detail.tsx:181` — `#smart-timeline-milestone-date` (add-milestone modal).
+- `components/ProjectFormFields.tsx:134,138` — `#project-filing-date`, `#project-grant-date`.
+
+### 1.8 Summary matrix
+
+| Surface | Direction | Presets | Custom | URL contract | Default |
+|---|---|---|---|---|---|
+| `/agenda` | Future | 7\|14\|30\|90 | — | `?range=N` | 30d |
+| `/admin/audit-log` | Past | 24h\|7d\|30d\|all + custom | date pair | `?range=…&from=…&to=…` | 7d |
+| `/projects/:id/chart` | Symmetric ±N | 1y\|2y\|all + custom | date pair | `?range=…&from=…&to=…` | 1y |
+| `/views/:id` editor | Past+Future mix | next_7d\|next_30d\|next_90d\|past_30d\|past_90d\|any | — | persisted JSON | next_30d |
+| Filter-bar `time` axis | Past+Future mix | next_7d\|next_30d\|next_90d\|past_30d\|any | **stubbed** | persisted + `?…__time_from=` | per surface |
+| Verlauf | Past + any | past_7d\|past_30d\|past_90d\|any | **stubbed** | URL | past_30d |
+| InboxFilterBar | Mix | filter-bar default | **stubbed** | URL | per surface |
+
+Three of seven surfaces have **incomplete** custom-range affordances. None of the seven exposes the full symmetric fan m wants.
+
+---
+
+## §2 upckommentar slicer pattern
+
+Verified by reading source at `/home/m/dev/web/upc-kommentar/src/lib/`:
+
+- **`DateRangeSlider.svelte`** (component, 448 lines).
+- **`date-range-slider-pure.ts`** (pure-math helpers, 487 lines, fully unit-tested).
+- **`InboxFilterBar.svelte`** (host).
+
+### 2.1 What it is
+
+A **two-handle range slider** that wraps `svelte-range-slider-pips` (npm: `svelte-range-slider-pips@4`). The slider's rail is the upckommentar floor (`2023-01-01`) to today, and the two handles define `dateFrom` and `dateTo`. Step is **1 day** regardless of zoom.
+
+Public contract (DateRangeSlider.svelte:57-82):
+
+```ts
+interface Props {
+  minISO: string;                 // axis lower bound, default 2023-01-01
+  maxISO: string;                 // axis upper bound, today
+  fromISO: string | null;         // current From (null = parked at min)
+  toISO: string | null;           // current To   (null = parked at max)
+  onChange: (from, to) => void;   // emits on every slider change
+  testid?: string;
+  axisWidthPx?: number;           // test override for jsdom
+}
+```
+
+### 2.2 Anchor rail + granularity
+
+Below the slider rail is a **custom-rendered anchor rail** (the lib's own pips are hidden via `pips={false}` because they're evenly-spaced approximations — issue #42 in upckommentar). Anchor day-numbers come from `pipAnchorsFor(granularity, minDay, maxDay)`:
+
+- **year:** every Jan 1 in range.
+- **month:** every 1st-of-month.
+- **day:** every Monday.
+
+Edges (`minDay`, `maxDay`) are always anchors so the user can park at the slider's extremes.
+
+Granularity has **+/- zoom buttons** in the top-right of the slider (`year → month → day`), with each level showing more anchors.
+
+### 2.3 Click-to-snap (left half / right half)
+
+`DateRangeSlider.svelte:219-240` + pure helper `endOfPeriodDay()`:
+
+- **Left half of an anchor label** → snap closest handle to **start** of period (the anchor day itself, e.g. Jan 1).
+- **Right half of the same label** → snap to **end** of period (Dec 31 for year, last-of-month for month, Sunday for day).
+- Keyboard activation falls back to left-half (start-of-period) deterministically.
+
+### 2.4 Label thinning + two-row alternation
+
+`pipLabelStrideFor()` + `pipLabelRow()` (pure helpers):
+
+- Measures rail width via `ResizeObserver`.
+- Computes a stride — only every Nth label is rendered.
+- Adjacent rendered labels alternate row 0 / row 1 (~1.1em offset down) so they can sit closer horizontally without colliding.
+
+### 2.5 Handle behaviour
+
+- `range=true` draws a colored bar between handles.
+- `draggy=true` lets the user drag the **bar itself** to shift the window without changing its width.
+- `pushy=true` — handles push each other when crossed.
+- `float=true` — tooltip floats above the dragged handle showing `DD.MM.YYYY`.
+
+### 2.6 URL contract on host
+
+`InboxFilterBar.svelte` debounces `onChange` at 250ms, then writes:
+
+```
+?date_from=2024-03-15&date_to=2024-09-30
+```
+
+When a handle is parked at min/max, that bound is **omitted** from the URL (`valuesToFromTo()` in the pure module). So `?date_from=2024-03-15` alone means "from March 15 onwards, no upper bound."
+
+### 2.7 What's worth borrowing for paliad
+
+| Element | Borrow? | Why |
+|---|---|---|
+| Two-handle drag | **Yes — but defer to Slice D** | Excellent fine-tune UX. Non-trivial to port without `svelte-range-slider-pips` (or a Svelte ↔ TSX adapter). |
+| Anchor rail with click-to-snap | Yes (in Slice D) | Year/month/Monday anchors are the right granularities. |
+| Label thinning + two-row alternation | Yes (in Slice D) | Makes the rail readable at any width. |
+| Granularity + zoom +/- | Yes (in Slice D) | Single most useful interaction; users don't drag pixel-precise. |
+| Epoch-day pure math | Yes — verbatim | The `date-range-slider-pure.ts` module is well-tested and dependency-free. Port to TS in paliad's pure-helper layer. |
+| `null` = parked at edge | Yes — already aligned | TimeHorizon's `past_all` / `next_all` map cleanly to "one bound parked at infinity." |
+| The library `svelte-range-slider-pips` itself | **No** | Adds a Svelte dependency to a non-Svelte project. Slice D would build a tiny equivalent on top of `<input type="range">` × 2 + CSS — or vendor the lib's pure parts. |
+
+### 2.8 What does NOT apply to paliad
+
+- **Floor at 2023-01-01.** upckommentar starts at the UPC's first day. paliad has decade-old patents and future-projecting deadlines; the axis must extend in both directions. We use `today ± 5 years` as the default visible range with `past_all` / `next_all` chips to escape it.
+- **Single granularity locked per session.** upckommentar's UI shows one of year/month/day at a time. paliad's typical use ("next 30 days for the deadline list") doesn't benefit from a zoom; the chips ARE the granularity. Slicer in Slice D only opens when the user picks "Anpassen" — at which point the zoom UI makes sense.
+
+---
+
+## §3 Component design — `<DateRangePicker>`
+
+### 3.1 Public API
+
+```ts
+type TimeHorizonExt =
+  | "next_7d"  | "next_14d" | "next_30d" | "next_90d" | "next_all"
+  | "past_7d"  | "past_14d" | "past_30d" | "past_90d" | "past_all"
+  | "any" | "custom";
+
+interface DateRangePickerProps {
+  // Current state. The component is fully controlled.
+  value: TimeSpec;
+  onChange: (next: TimeSpec) => void;
+
+  // Per-surface preset filter — omit a chip by leaving it out of the array.
+  // Default: all symmetric chips + "any" + "custom".
+  presets?: TimeHorizonExt[];
+
+  // Closed-state button label override. Defaults to the i18n key for value.horizon
+  // (e.g. "Letzte 30 Tage"). Override for surfaces that want a heading prefix
+  // like "Zeitraum: Letzte 30 Tage".
+  labelPrefix?: string;
+
+  // i18n strings consumed via the i18n.ts dictionary. No props for individual labels.
+  // Localisation flows through existing data-i18n attributes.
+
+  // Surface tag — used to derive a stable testid and URL-param namespace if
+  // the host wires URL serialization through helpers we provide (see §4).
+  surface: string;          // e.g. "agenda" | "audit-log" | "filter-bar"
+
+  // Mode — popover (default) or modal (rare).
+  mode?: "popover" | "modal";
+
+  // Anchor / placement for popover mode. Defaults to "below".
+  placement?: "below" | "above" | "right";
+}
+```
+
+`TimeSpec` mirrors the existing shape (`internal/services/filter_spec.go:107-112`), extended with the 4 new horizon values:
+
+```ts
+interface TimeSpec {
+  horizon: TimeHorizonExt;
+  field?: "auto" | "created_at";
+  from?: string;            // ISO YYYY-MM-DD; set only when horizon === "custom"
+  to?: string;
+}
+```
+
+### 3.2 States
+
+The component is a small state machine:
+
+```
+closed ────[click button]────► open
+  ▲                              │
+  └──[click outside / Esc]───────┘
+                                 │
+       open ───[click chip]──── closed (commit immediately)
+                                 │
+       open ───[click "Anpassen"]► custom-editor
+                                 │
+       custom-editor ─[Anwenden]► closed (commit)
+       custom-editor ─[Esc]─────► open
+```
+
+- **closed** — single button with current selection label and a chevron `▾`. No outline/highlight unless the value is not the default for this surface.
+- **open** — popover anchored below the button (or below-then-flip-up on viewport-bottom). Contains the symmetric chip row + ALL center + "Anpassen" sub-section.
+- **custom-editor** — replaces the "Anpassen" link with two `<input type="date">` + "Anwenden" / "Abbrechen" buttons. (In Slice D this becomes the slicer.)
+
+### 3.3 Symmetric chip layout
+
+The popover body — full ASCII sketch:
+
+```
+┌─────────────────────────────────────────────────────────────┐
+│  ╭ Vergangenheit ────────╮ ╭ ALLES ╮ ╭ Zukunft ───────────╮ │
+│  │ [Ganze Vergangenheit] │ │ [⌖]   │ │ [Ganze Zukunft]    │ │
+│  │ [Letzte 90 Tage]      │ │       │ │ [Nächste 7 Tage]   │ │
+│  │ [Letzte 30 Tage]      │ │       │ │ [Nächste 14 Tage]  │ │
+│  │ [Letzte 14 Tage]      │ │       │ │ [Nächste 30 Tage]  │ │
+│  │ [Letzte 7 Tage]       │ │       │ │ [Nächste 90 Tage]  │ │
+│  ╰───────────────────────╯ ╰───────╯ ╰────────────────────╯ │
+│                                                             │
+│  ── Anpassen ──────────────────────────────────────────     │
+│  Von [____.____.____]  Bis [____.____.____]   [Anwenden]    │
+└─────────────────────────────────────────────────────────────┘
+```
+
+Visual cues:
+
+- The currently-selected chip gets the **lime accent** (`--color-bg-lime-tint` background, `--color-text` text, `--color-accent` border) — matches existing `.agenda-chip-active` so we don't introduce a new active state.
+- The "ALLES" center button is **larger** than the fan chips (44px tall vs. 32px), drawn with a target-style glyph `⌖` (or `∞` — see Q3.B). Inventor pick: `⌖` plus the word "ALLES" beneath. Larger so it reads as "the no-filter affordance," not as one chip among many.
+- The two fans are visually **mirrored** — past on the left, future on the right. Both have a "Ganze …" terminal chip at the outer edge (left-most for past_all, right-most for next_all) and decreasing-magnitude chips fanning toward the center. The ordering matches the human intuition: "left = back in time, right = forward in time."
+- On viewports < 480px the popover stacks vertically (past fan above, ALL middle, future fan below). On viewports < 360px the popover becomes a modal-feeling slide-up sheet (existing inbox modal CSS pattern reusable).
+
+### 3.4 Sketch of the closed button states
+
+```
+default:    ┌─Zeitraum: Nächste 30 Tage ▾─┐
+custom:     ┌─Zeitraum: 15.03.2026 – 30.04.2026 ▾─┐
+any:        ┌─Zeitraum: Alles ▾─┐
+past_all:   ┌─Zeitraum: Ganze Vergangenheit ▾─┐
+hover/open: same + outline + bg-accent-tint
+```
+
+When the value is **not** the surface default, an additional small `●` dot appears between "Zeitraum:" and the value — the existing universal "filter is non-default" indicator used by the filter-bar.
+
+### 3.5 Keyboard
+
+- `Tab` lands on the button. `Enter`/`Space` opens the popover.
+- `Esc` from open state closes it. `Esc` from custom-editor returns to chip view (one level back).
+- Chips are focusable buttons in the natural left-to-right reading order: past_all → past_90 → past_30 → past_14 → past_7 → any (center) → next_7 → next_14 → next_30 → next_90 → next_all.
+- The custom date inputs are `<input type="date" lang="de">` — gets the OS-native picker on macOS / iOS / Android / Windows. No new custom calendar widget.
+
+### 3.6 Accessibility
+
+- The button has `aria-haspopup="dialog"` and `aria-expanded` toggled on open/close.
+- The popover has `role="dialog"` with `aria-label` = `t("date_range.dialog.label")` ("Zeitraum wählen" / "Choose date range").
+- Chips are `<button>` with `aria-pressed="true"` on the active one.
+- The two fan groups have `role="group"` + `aria-label="Vergangenheit"` / `aria-label="Zukunft"`.
+
+### 3.7 Module layout
+
+```
+frontend/src/
+├── components/
+│   └── DateRangePicker.tsx          ← TSX shell (markup only)
+├── client/
+│   ├── date-range-picker.ts         ← mount() + state machine + DOM event wiring
+│   └── date-range-picker-pure.ts    ← horizon-bounds math, label resolver, parse/serialize
+└── styles/
+    └── global.css                    ← .date-range-* classes
+```
+
+`-pure.ts` is the headless module — fully testable under `bun test`. The boot client in `-picker.ts` consumes it, mirroring the pattern used by `shape-timeline-chart.ts` + `shape-timeline-chart.test.ts` (see memory: t-paliad-173 / gauss).
+
+Pure module exports (preliminary):
+
+```ts
+export function horizonBounds(h: TimeHorizonExt, now: Date): { from?: Date; to?: Date }
+export function labelForHorizon(h: TimeHorizonExt, lang: "de"|"en"): string
+export function labelForCustom(from: string, to: string, lang: "de"|"en"): string
+export function parseURL(params: URLSearchParams): TimeSpec
+export function serializeURL(spec: TimeSpec, defaults: Partial<TimeSpec>): URLSearchParams
+export function isDefault(spec: TimeSpec, default_: TimeSpec): boolean
+```
+
+### 3.8 Go-side additions
+
+`internal/services/filter_spec.go`:
+
+```go
+// Add four new constants alongside the existing TimeHorizon block.
+HorizonNext14d  TimeHorizon = "next_14d"
+HorizonPast14d  TimeHorizon = "past_14d"
+HorizonNextAll  TimeHorizon = "next_all"
+HorizonPastAll  TimeHorizon = "past_all"
+```
+
+`internal/services/view_service.go:computeViewSpecBounds()`:
+
+```go
+case HorizonNext14d:
+    bounds.from = &startOfDay; t := startOfDay.AddDate(0, 0, 14);  bounds.to = &t
+case HorizonPast14d:
+    f := startOfDay.AddDate(0, 0, -14); bounds.from = &f;          bounds.to = &startOfTomorrow
+case HorizonNextAll:
+    bounds.from = &startOfDay
+    // bounds.to left nil  → "no upper bound"
+case HorizonPastAll:
+    bounds.to = &startOfTomorrow
+    // bounds.from left nil
+```
+
+`HorizonNextAll` and `HorizonPastAll` are **one-sided unbounded** — distinct from existing `HorizonAll` (bidirectional unbounded) and `HorizonAny` (no filter at all, same effect as `HorizonAll` for view-spec runtime but different in intent).
+
+`filter_spec.go:validate()` (line 280-292) gains the two new past/next constants in the switch.
+
+### 3.9 i18n keys
+
+Two-language matrix (DE primary, EN secondary):
+
+```
+date_range.button.label                 "Zeitraum"               / "Time range"
+date_range.button.label.custom          "Von … bis …"            / "From … to …"
+date_range.horizon.next_7d              "Nächste 7 Tage"         / "Next 7 days"
+date_range.horizon.next_14d             "Nächste 14 Tage"        / "Next 14 days"
+date_range.horizon.next_30d             "Nächste 30 Tage"        / "Next 30 days"
+date_range.horizon.next_90d             "Nächste 90 Tage"        / "Next 90 days"
+date_range.horizon.next_all             "Ganze Zukunft"          / "All future"
+date_range.horizon.past_7d              "Letzte 7 Tage"          / "Last 7 days"
+date_range.horizon.past_14d             "Letzte 14 Tage"         / "Last 14 days"
+date_range.horizon.past_30d             "Letzte 30 Tage"         / "Last 30 days"
+date_range.horizon.past_90d             "Letzte 90 Tage"         / "Last 90 days"
+date_range.horizon.past_all             "Ganze Vergangenheit"    / "All past"
+date_range.horizon.any                  "Alles"                  / "All"
+date_range.horizon.custom               "Benutzerdefiniert"      / "Custom"
+date_range.dialog.label                 "Zeitraum wählen"        / "Choose date range"
+date_range.fan.past.label               "Vergangenheit"          / "Past"
+date_range.fan.future.label             "Zukunft"                / "Future"
+date_range.center.label                 "Alles"                  / "All"
+date_range.custom.from                  "Von"                    / "From"
+date_range.custom.to                    "Bis"                    / "To"
+date_range.custom.apply                 "Anwenden"               / "Apply"
+date_range.custom.cancel                "Abbrechen"              / "Cancel"
+date_range.custom.invalid               "Bis-Datum muss nach Von-Datum liegen." / "End date must be after start date."
+```
+
+Total: 21 keys × 2 langs = 42 new entries in `i18n.ts`. Existing per-surface keys (`agenda.range.7`, `admin.audit.range.24h`, `views.bar.time.next_30d` etc.) stay until each surface migrates, then get retired.
+
+---
+
+## §4 URL / form serialization contract
+
+### 4.1 Canonical URL shape
+
+The picker writes (and reads) **canonical** params on the host's URL:
+
+```
+?horizon=next_30d
+?horizon=past_all
+?horizon=any           ← omitted if it matches the surface default
+?horizon=custom&from=2026-03-15&to=2026-04-30
+```
+
+The host page's URL-init code (`bootDateRangePicker(surface, opts)`) calls `parseURL(searchParams)` to derive the initial `TimeSpec`, then calls `serializeURL(spec, defaults)` on every change. Params equal to the surface default are **omitted** so the canonical URL stays short and dedupable — matches the existing `writeParamToURL` pattern in `projects-chart.ts:144-154`.
+
+### 4.2 Backwards-compat aliases
+
+Each migrating surface keeps its existing alias parser for the transition window:
+
+| Surface | Legacy URL | Canonical URL | Adapter |
+|---|---|---|---|
+| `/agenda` | `?range=30` | `?horizon=next_30d` | `range=N → horizon=next_${N}d` if `N ∈ {7,14,30,90}`, else `next_all` for `N>90`. Read both, write canonical. |
+| `/admin/audit-log` | `?range=7d` | `?horizon=past_7d` | `range=24h → horizon=past_1d` (new, see Q5) or kept as `past_7d` fallback. `range=all → horizon=any`. |
+| `/projects/:id/chart` | `?range=1y` | `?range=1y` (kept) | **NOT migrated to TimeHorizon** — projects-chart is symmetric-around-today. It uses DateRangePicker only for its **custom**-mode UI (the date-pair → slicer in Slice D). The 1y/2y/all presets stay surface-specific. |
+
+The Go side is unaffected by aliasing — handlers receive whatever shape they always have, and the URL alias adapter lives entirely client-side per surface. **No backend route signature changes** in Slice A.
+
+### 4.3 Custom Views (persisted JSON)
+
+`paliad.user_views.filter_spec` is a JSON column. The TimeSpec extension is additive (new enum values, no shape change). Existing rows continue to validate. Migration not needed.
+
+### 4.4 Form fields (Custom Views editor)
+
+`views-editor.tsx:102-109` migrates from `<select>` to the picker. The form submits the same FormData shape (just one extra key for custom from/to — already plumbed via TimeSpec.from / TimeSpec.to). The Go-side `parseViewForm()` (TBD by coder) gains 4 new acceptable horizon values; existing test cases continue to pass.
+
+---
+
+## §5 Migration plan
+
+### Slice A — substrate + filter-bar `time` axis
+
+**Backend** (single migration not needed — additive constants only):
+
+- `internal/services/filter_spec.go` — 4 new `TimeHorizon` constants + validate switch arms.
+- `internal/services/view_service.go` — `computeViewSpecBounds()` 4 new switch cases.
+- Pure unit tests for each new horizon (zero DB).
+
+**Frontend**:
+
+- New `frontend/src/components/DateRangePicker.tsx` + boot client + pure module.
+- New i18n keys (42 entries).
+- `frontend/src/client/filter-bar/axes.ts:renderTimeAxis()` — replace the disabled "Anpassen" stub with the picker. The chip cluster either becomes the picker's open-state (preferred) OR the chips stay flat and the picker only opens on "Anpassen" click (fallback if popover-in-bar is visually noisy). **Inventor pick (R): chips stay flat in the bar; "Anpassen" chip becomes the picker trigger. Picker emits TimeSpec back into the bar's state, same patch path.**
+
+**Surfaces lit up automatically**: Verlauf (`/projects/:id`), Custom Views (`/views`, `/views/:id`), InboxFilterBar (`/inbox`).
+
+**LoC estimate**: ~600 LoC (pure: 180 / boot: 180 / TSX: 100 / CSS: 80 / Go: 30 / tests: 240). Tests-first per `docs/design-paliad-test-strategy-2026-05-19.md`.
+
+### Slice B — `/agenda`
+
+- `agenda.tsx:51-69` — replace chip rows with `<DateRangePicker surface="agenda" presets={["next_7d","next_14d","next_30d","next_90d","next_all","custom"]} />`.
+- `client/agenda.ts:85-104` — replace `wireControls()` chip wiring with picker subscription.
+- URL alias adapter — accept `?range=N` for back-compat, emit `?horizon=…`.
+
+**LoC**: ~80 LoC delta, mostly deletion.
+
+### Slice C — `/admin/audit-log` + `/projects/:id/chart`
+
+- `admin-audit-log.tsx:50-65` — replace `<select>` + date-pair with `<DateRangePicker surface="audit-log" presets={["past_7d","past_14d","past_30d","past_90d","past_all","custom"]} />`.
+- `projects-chart.tsx:75-83` — **wrap** the existing 1y/2y/all presets in a custom-prop variant (a sibling component `<SymmetricRangePicker>` that shares the picker's popover scaffolding but emits the surface-specific `range_preset`). Or — if the head/m prefers — fold 1y/2y/all into TimeHorizon as `sym_1y` / `sym_2y` / `sym_all`. **Inventor pick (R): sibling component**, because symmetric-around-today is conceptually different from past/future fan. See §8 Q1.
+
+**LoC**: ~120 LoC for audit-log, ~80 LoC for projects-chart wrap.
+
+### Slice D *(optional, separate task)* — slicer
+
+- Add `<DateRangeSlicer>` for the custom-editor sub-pane. Built on `<input type="range">` × 2 with a custom anchor rail above, ported from `date-range-slider-pure.ts`.
+- Replaces inline date-pair when `horizon === "custom"` and `surface ∈ {agenda, audit-log, filter-bar}`. Projects-chart keeps inline date-pair OR also uses slicer — its choice.
+- No new dependency.
+- ~400 LoC including pure helpers + DOM scaffolding + tests.
+
+### Per-slice rollout
+
+| Slice | Risk | Surfaces affected | Coder profile |
+|---|---|---|---|
+| A | Low — additive only | 4 (filter-bar + 3 consumers) | Pattern-fluent Sonnet |
+| B | Low | 1 | Same coder |
+| C | Medium (projects-chart sibling) | 2 | Same coder |
+| D | Medium (new slicer) | 0 (additive on top of A) | Separate task |
+
+---
+
+## §6 Visual decisions
+
+### 6.1 Chip labels
+
+Final labels — bilingual (DE first):
+
+| Chip | DE | EN |
+|---|---|---|
+| past_all | Ganze Vergangenheit | All past |
+| past_90d | Letzte 90 Tage | Last 90 days |
+| past_30d | Letzte 30 Tage | Last 30 days |
+| past_14d | Letzte 14 Tage | Last 14 days |
+| past_7d | Letzte 7 Tage | Last 7 days |
+| any (center) | Alles | All |
+| next_7d | Nächste 7 Tage | Next 7 days |
+| next_14d | Nächste 14 Tage | Next 14 days |
+| next_30d | Nächste 30 Tage | Next 30 days |
+| next_90d | Nächste 90 Tage | Next 90 days |
+| next_all | Ganze Zukunft | All future |
+| custom | Anpassen | Customize |
+
+Rationale on "Anpassen" vs "Benutzerdefiniert":
+- "Anpassen" matches existing `views.bar.time.custom` key value in `i18n.ts`.
+- "Benutzerdefiniert" is used in admin-audit-log's dropdown — verbose, but more accurate.
+- (R): **Anpassen** (consistent with filter-bar; six chars vs. eighteen).
+
+### 6.2 Accent / active state
+
+Reuse the existing **lime accent** chip-active state (`--color-bg-lime-tint` background, `--color-accent` border, `--color-text` text). This is the established affordance for the `agenda-chip-active` class — same visual reused, no new accent token.
+
+### 6.3 The "ALLES" center button
+
+A larger, target-glyph button — visually distinct from the fan chips so the user reads it as the "no time filter" exit, not as one chip among many:
+
+```
+   ╭──────╮
+   │  ⌖   │
+   │ ALLES│
+   ╰──────╯
+```
+
+(R) glyph: `⌖` (Unicode U+2316 POSITION INDICATOR). Alternatives considered: `∞` (too math-y), `⊕` (too connect-y), `▣` (too checkbox-y), no glyph (chip then looks like every other chip). See §8 Q3.B.
+
+### 6.4 Custom-range entry
+
+In Slice A: **inline date-pair below the chip rows**, with an "Anwenden" button that commits + closes the picker. Plain `<input type="date" lang="de">` — gets the OS-native picker.
+
+In Slice D (later): same slot becomes the slicer. The chip rows remain; the slicer collapses under them so the user can switch back to a chip with one click.
+
+### 6.5 Hover / focus
+
+- Chip hover: existing `.agenda-chip:hover` (lighter background tint).
+- Chip focus-visible: 2px outline using `--color-accent`.
+- Button focus-visible: same.
+- Popover entry: 120ms fade-in via `transform: translateY(-4px) → 0` + opacity. Reduced-motion users (prefers-reduced-motion: reduce) get instant show.
+
+### 6.6 Indication that the filter is non-default
+
+The closed button shows a small `●` dot to the left of the label when the value is **not** the surface default. This matches the existing filter-bar non-default-indicator pattern (`frontend/src/client/filter-bar/index.ts` has a similar dot but on the whole bar; we adopt it per-control).
+
+---
+
+## §7 Edge cases
+
+### 7.1 Timezones
+
+All horizon math runs against **UTC `startOfDay`** of `new Date()` — same convention as `horizonBounds()` in `projects-detail.ts:393-406`. The user's browser may be in CEST in summer or CET in winter; the picker still treats "today" as a UTC date for filter purposes. The date-input localizes display (German locale → DD.MM.YYYY) but the underlying ISO is `YYYY-MM-DD` parsed as UTC midnight.
+
+Practical impact: a user in CEST clicking "Letzte 7 Tage" at 01:30 local on 2026-06-15 sees `from=2026-06-07T00:00Z, to=2026-06-15T00:00Z` even though their local clock shows the 15th. This matches every other date-filter in paliad and avoids "the same row vanishes at 01:00 vs. 23:00" surprises. Document the convention in the pure module's header comment.
+
+### 7.2 Far past truncation
+
+`past_all` materialises to `from: nil`. The Go side (view_service.go) treats nil as "no lower bound" — the SQL `WHERE due_date >= ?` clause is omitted. No truncation needed.
+
+For projects-chart's symmetric "all" mode, "all" still means **bounds derived from loaded events** (status quo) — the picker for projects-chart's surface uses the sibling `<SymmetricRangePicker>` which doesn't have `past_all`/`next_all` chips, only `1y/2y/all`.
+
+### 7.3 Overlapping selections — past_7 + next_7 simultaneously?
+
+The picker is **single-select** — one chip active at a time, OR custom mode. m's brief doesn't mention multi-select and the existing TimeSpec is single-valued. Multi-select would require a fundamental contract change. Don't.
+
+If a user genuinely wants "last 7 days OR next 7 days," they use the custom-range with `from=today-7d`, `to=today+7d` — which is what `±1w` would mean. The fact that this is two chip-clicks vs. one isn't a real ergonomic loss.
+
+### 7.4 Custom dates with from > to
+
+Validate client-side: when both inputs are filled and `from > to`, the "Anwenden" button is disabled and a hint appears: "Bis-Datum muss nach Von-Datum liegen" (i18n key `date_range.custom.invalid`). The picker does **not** auto-swap.
+
+### 7.5 Empty inputs in custom mode
+
+If the user clicks "Anpassen" then clicks elsewhere before filling inputs, the picker reverts to whatever horizon was active before (state cached on entry to custom-editor). No "half-custom" state persists.
+
+### 7.6 Surface-specific preset overrides
+
+Each surface declares its own presets via the `presets` prop. The picker hides chips not in the array. The default surface preset (read from `defaults` prop, or hardcoded if absent) is what `serializeURL()` omits from the URL.
+
+Important invariant: `defaults` must be a member of `presets`, OR be a special value like `any` that's always rendered. The component asserts this at boot and falls back to `any` if violated.
+
+### 7.7 Bilingual labels mid-session
+
+`labelForHorizon()` consults the live `i18n.ts` dictionary on every render, so a language toggle updates the picker immediately — including the closed-button label.
+
+### 7.8 Embedded picker inside a filter bar
+
+When the picker is mounted inside `filter-bar`, it should NOT use a full popover overlay — the filter bar already wraps controls. Instead the open-state's chip rows render **inline below the time chip cluster**, expanding the bar's height. This is `mode="inline"` (a third mode beyond popover/modal). Slice A picks this for filter-bar consumers; standalone surfaces (`/agenda`, `/admin/audit-log`) use popover mode.
+
+### 7.9 What happens if a saved Custom View references `past_14d` before Slice A ships?
+
+The JSON validator rejects it (`filter_spec.go:validate()` enum check). Saved views are migration-safe in one direction only — adding new enum values is fine; removing is not. Slice A adds, doesn't remove. No issue.
+
+### 7.10 Race: URL change while picker is open
+
+If the user has the picker open and a URL change happens via another control (e.g. they Cmd-Click a sidebar link), the picker is unmounted naturally with the page navigation. No state to preserve across navigations.
+
+---
+
+## §8 Open questions for m
+
+Per task brief: **no AskUserQuestion**. Material picks escalated via `mai instruct head`; everything else defaults to (R) below. The head decides whether to forward to m or rule on the spot.
+
+### Q1 [MATERIAL — escalate]: How to handle `/projects/:id/chart`?
+
+The chart's range presets are **symmetric around today** (1y / 2y / all = ±1y / ±2y / all-data-bounds), conceptually different from past/future fans. Options:
+
+- **(R) A — sibling component.** Keep a separate `<SymmetricRangePicker>` for the chart surface. Same popover scaffolding, different chip set. Chart's URL stays `?range=1y`. Doesn't add to TimeHorizon.
+- **B — fold into TimeHorizon.** Add `sym_1y`, `sym_2y`, `sym_all` constants. Picker prop selects which fan vs. symmetric. Saved views could then express "±1y" too.
+- **C — leave the chart as-is.** Don't migrate. Accept the visual inconsistency.
+
+(R) **A.** Symmetric vs fan is a real semantic difference; one component trying to be both is muddier than two components sharing scaffolding. The chart isn't a "filter" — it's a viewport, and viewports legitimately want symmetric panning.
+
+### Q2 [MATERIAL — escalate]: Modal vs popover for the standalone case?
+
+m's brief says "mini modal." Options:
+
+- **(R) A — popover always.** Anchored to the trigger button, click-outside dismiss. In-context, lightweight.
+- **B — modal for explicit "open date filter" intent.** Use a centered modal with scrim when the picker is the page's primary filter (e.g. `/admin/audit-log` where date is the most prominent control). Popover for embedded uses.
+- **C — modal everywhere.** Strong visual hierarchy, but interrupts the user.
+
+(R) **A.** Modal feels heavy for what is conceptually a chip cluster. The "mini" qualifier in m's wording suggests popover, not full modal. If a surface specifically needs the modal weight, the `mode="modal"` prop is available — but no default surface picks it.
+
+### Q3 [MATERIAL — escalate]: Slice priority — what migrates first?
+
+- **(R) A — filter-bar `time` axis first** (Slice A). Lights up 4 surfaces simultaneously (Verlauf, InboxFilterBar, views runtime, Custom Views editor) by replacing the existing Phase-2 disabled stub.
+- **B — `/agenda` first** (per task brief default). Highest-traffic standalone surface, simplest migration.
+- **C — both A and B in parallel** (head splits between two coders).
+
+(R) **A.** Filter-bar is the substrate everything else either uses or should use. Lighting it up first turns three downstream surfaces from "almost working" (the stubbed custom-range chip with "coming_soon" tooltip) to "fully working." Agenda then migrates as Slice B, on top of a proven component.
+
+### Q3.B [DEFAULT — no escalation needed]: ALL center button glyph?
+
+- **(R) `⌖`** (POSITION INDICATOR, U+2316). Implies "center / pin to here."
+- B `∞` (infinity). Mathy.
+- C `⊕` (circled plus). Looks like a button.
+- D No glyph, just "ALLES" in bold.
+
+(R) `⌖`. If the head/m doesn't like the unicode lookup, D is the safe fallback.
+
+### Q4 [DEFAULT — no escalation]: Custom-range entry in Slice A?
+
+- **(R)** Inline `<input type="date">` pair, OS-native picker. Slice D adds the slicer.
+
+### Q5 [DEFAULT — no escalation]: Past `24h` in audit-log?
+
+audit-log currently has a `24h` preset; the picker would express this as `past_1d`. Options:
+
+- **(R)** Map legacy `?range=24h` → `?horizon=past_1d`. Add a new `past_1d` constant.
+- B Drop `24h` — audit log defaults to `past_7d` like other surfaces. Users wanting "last 24h" use custom mode.
+
+(R) Add `past_1d`. It's a one-line addition and audit-log users genuinely use "last 24h" for incident triage.
+
+(Note: this means the picker actually has 5 past chips + 5 future chips + center + custom = 12 chips total, which fits comfortably in the popover.)
+
+### Q6 [DEFAULT — no escalation]: Slice D (slicer) — separate task or fold in?
+
+- **(R) Separate task.** Slice A-C are independently shippable. Slice D is meaningful design + ~400 LoC and shouldn't gate the main migration.
+
+### Q7 [DEFAULT — no escalation]: Per-surface defaults?
+
+Each migrating surface keeps its current default exactly:
+
+- `/agenda` → `next_30d` (was 30).
+- `/admin/audit-log` → `past_7d` (was 7d).
+- `/projects/:id` Verlauf → `past_30d` (was past_30d in `projects-detail.ts:2310`).
+- `/views/:id` runtime → whatever the saved view has (no change).
+- `/inbox` (InboxFilterBar) → whatever filter-bar's surface defines.
+
+### Q8 [DEFAULT — no escalation]: Should `past_14d` and `next_14d` retroactively appear in `views-editor.tsx`'s `<select>`?
+
+(R) **Yes** — once Slice A ships, the `<select>` in `views-editor.tsx` is replaced by the picker (part of Slice A, as filter-bar consumers all flip in one commit). All 12 preset values become available for new Custom Views.
+
+---
+
+## §9 Implementer notes (for the coder shift, if approved)
+
+### Lessons embedded
+
+- **TimeSpec extension is additive only** — Go enum + TS union + i18n keys + horizonBounds switch. No DB migration, no contract break.
+- **Pure module is testable under `bun test`** — no DOM needed for horizon math, label resolution, URL serialization. Aim for 95%+ coverage of the pure module before touching the boot client.
+- **Reuse `.agenda-chip` styling** — adds no new tokens, no new dark-mode contrast risk (cf. memory t-paliad-150 / fritz — fritz lost 90 minutes to a `var(--token, #hex)` fallback bug because the token wasn't defined in dark mode).
+- **`mode="inline"` for filter-bar consumers** — the bar already wraps its own popover-like layout; nesting popovers gets visually noisy.
+- **Surface defaults must be members of `presets`** — assert at boot, fail loud in dev, fall back to `any` in prod.
+
+### Recommended coder profile
+
+Pattern-fluent Sonnet. Substrate is well-trodden (TimeSpec/TimeHorizon already lives, chip-cluster CSS exists, URL-codec pattern documented in `projects-chart.ts`). The novel piece is the popover scaffolding — paliad doesn't have a generic Popover primitive today; the picker builds its own DOM-anchored overlay. ~80 LoC of plain JS, no dependency.
+
+### Build hygiene checklist
+
+- `go build ./...` clean
+- `go vet ./...` clean
+- `go test ./...` clean (existing tests must continue passing — additive constants change zero behaviour)
+- `bun run build` clean (i18n scan: 21 new keys added, all `data-i18n` attributes present)
+- bun:test covers the pure module (horizon math, label resolver, URL parser/serializer)
+- Playwright smoke (manual, not gated): on `/inbox` the time axis "Anpassen" chip is now functional; custom-from/to date pair commits a usable filter.
+
+### Out of scope for the coder
+
+- Slicer (Slice D) — separate task.
+- Per-language adjustments beyond DE/EN (per task brief, out of scope).
+- Time-of-day picking — separate concern.
+- Recurring-event windows — events feed handles separately.
+- A generic Popover primitive — extract only if a second consumer appears in the same slice.
+
+### Acceptance criteria for Slice A
+
+1. New `<DateRangePicker>` mounts on filter-bar's `time` axis, replacing the disabled "Anpassen" chip.
+2. The 4 new horizon values (`past_14d`, `next_14d`, `past_all`, `next_all`) are accepted by Go's `TimeSpec.validate()` and produce correct `(from, to)` bounds in `computeViewSpecBounds()`.
+3. The 4 new horizons round-trip through saved Custom Views (`paliad.user_views.filter_spec` JSON).
+4. URL serialization is canonical (`?horizon=…&from=…&to=…`) and surface-default values are omitted.
+5. Verlauf (`/projects/:id`), `/views`, `/views/:id`, and `/inbox` continue to function with their existing presets unchanged — they pick up the new picker but don't switch their preset list yet.
+6. Pure-module unit tests cover: 12 horizons × bound calculation; URL parse / serialize round-trip; default-omission rule; custom-mode date validation.
+7. `bun run build` reports the new i18n keys (no missing-key warnings).
+8. No regression in `go test ./internal/services/...` (existing TimeSpec tests stay green).
+
+---
+
+## §10 Material picks summary — escalation message
+
+To be sent via `mai instruct head` after this doc is pushed:
+
+> Three material picks for m on date-range-picker design:
+>
+> 1. **`/projects/:id/chart` migration** — keep symmetric (1y/2y/all) presets as a sibling component, NOT fold into TimeHorizon. Chart is a viewport, not a filter.
+> 2. **Popover vs modal** — popover by default. Modal is a `mode` prop available per surface but no surface picks it in Slice A.
+> 3. **Slice A first migrates filter-bar time axis** (lights up Verlauf + InboxFilterBar + Views + Custom-Views-editor simultaneously by un-stubbing the existing "Anpassen" chip), not `/agenda` as the task brief defaulted. `/agenda` is Slice B.
+>
+> Everything else (chip labels, accent, glyph, custom-mode entry, surface defaults, past_1d for audit, slicer-as-Slice-D, 42 i18n keys) defaults per (R) in §8. Doc at `docs/design-date-range-picker-2026-05-25.md`.
+
+---
+
+*Verified premises (live, before designing):*
+
+- `internal/services/filter_spec.go:107-126` — TimeHorizon enum at 9 values today.
+- `internal/services/view_service.go:156-187` — `computeViewSpecBounds()` switches on the same enum.
+- `frontend/src/client/views/types.ts:21-33` — TimeHorizon TS mirror; same 9 values.
+- `frontend/src/client/filter-bar/axes.ts:65-115` — chip cluster renderer; "Anpassen" stub at line 105-112 marked Phase 2, disabled, "coming_soon" tooltip.
+- `frontend/src/agenda.tsx:64-67` — chip row exact values `7|14|30|90`.
+- `frontend/src/admin-audit-log.tsx:50-65` — select exact values `24h|7d|30d|custom|all`.
+- `frontend/src/projects-chart.tsx:78-82` + `frontend/src/client/projects-chart.ts:73-118` — RangePreset `1y|2y|all|custom`, symmetric around today.
+- `frontend/src/views-editor.tsx:102-109` — select exact values `next_7d|next_30d|next_90d|past_30d|past_90d|any`.
+- `/home/m/dev/web/upc-kommentar/src/lib/components/DateRangeSlider.svelte` — 448 lines, wraps `svelte-range-slider-pips@4`, custom anchor rail above the lib's hidden pips, click-to-snap left/right halves, granularity year/month/day zoom.
+- `/home/m/dev/web/upc-kommentar/src/lib/modules/date-range-slider/date-range-slider-pure.ts` — 487 lines, fully testable pure helpers, dependency-free, portable to paliad's TS.
+
+*Not verified live:* upckommentar.de in a browser (requires author auth; the source code IS the source of truth and was read end-to-end).

docs/design-determinator-row-cascade-2026-05-13.md

@@ -0,0 +1,704 @@
+# Design — Determinator B1 row-by-row cascade (replaces breadcrumb drilldown)
+
+**Author:** pauli (inventor)
+**Date:** 2026-05-13
+**Task:** t-paliad-166
+**Status:** READY FOR REVIEW — m gates inventor → coder transition.
+**Gitea:** m/paliad#25 (re-opened by m's 2026-05-13 11:17 comment).
+
+---
+
+## 0. Premises verified live (before designing)
+
+CLAUDE.md, mai-memory and the task brief can all be stale by days. Every anchor below is verified against the live codebase or live DB on `mai/pauli/determinator-b1-row-by` (baseline `adf377c` — main as of Slice 1 of t-paliad-179 merge).
+
+### 0.1 The Pathway B markup today
+
+`frontend/src/fristenrechner.tsx:227-310` is the Pathway B shell. Four functionally different layers are stacked with four visually different treatments. Live, in source order:
+
+| Layer | Element | Affordance | Visual |
+|---|---|---|---|
+| **L1 Mode** | `.fristen-mode-toggle` | `role=radiogroup` with two `<input type="radio">` | Radio buttons. Tree vs Filter. |
+| **L2 Perspective** | `.fristen-perspective-bar` | Three `<button>` chips | Pill chips. Kläger / Beklagter / Beide. |
+| **L3 Inbox** | `.fristen-inbox-bar` | Four `<button>` chips | Pill chips. CMS / beA / Posteingang / Alle. |
+| **L4 Cascade** | `.fristen-b1-cascade` | Breadcrumb + question + button-grid (drill-down) | Cards in a grid, breadcrumb above. |
+
+Below L4 sits `.fristen-b1-results` — the concept-card list that narrows as the cascade descends. That's content, not a decision layer.
+
+**m's critique is exact:** L1/L2/L3/L4 are all "narrow the deadline-rule space" steps with the same conceptual weight, but the user sees a radio, two pill strips, and a card grid. The cascade itself (L4) hides previous steps behind a breadcrumb — so when you've drilled three levels deep you can no longer see "I picked CMS → vom Gericht → Hinweisbeschluss" in one glance unless you read tiny breadcrumb crumbs.
+
+### 0.2 The cascade engine today
+
+`frontend/src/client/fristenrechner.ts:2405-2574` (`renderB1Cascade`). For a given `?b1=<slug>`:
+
+1. Build `trail = buildBreadcrumb(roots, currentSlug)`. The trail is the ancestors of the current node.
+2. Render `<nav class="fristen-b1-breadcrumb">` = root-reset + `›`-separated crumb buttons.
+3. Render `<p class="fristen-b1-question">` = the current node's `step_question_de` (or `"Was ist passiert?"` at root).
+4. Render `<div class="fristen-b1-buttons">` = child nodes as button cards (icon + label, `--leaf` modifier on terminal nodes).
+5. Render `<button class="fristen-b1-step-back">` = "← Eine Stufe zurück".
+
+Drilling = `navigateB1(child.slug)` = `pushState` + `renderB1Cascade(child.slug)`. The previous question disappears; only the breadcrumb crumb survives as text. **There is no "row of answered decisions."**
+
+### 0.3 Where narrowing happens today
+
+`fristenrechner.ts:2509-2522` filters cascade children by two predicates before rendering:
+
+- `inboxFilterAllowsForums(c.forums)` — hides nodes whose `forums` tag doesn't match `activeForumOnPage()`. The active forum is resolved at `fristenrechner.ts:2960-2970` with a three-input precedence chain:
+  1. **Inbox chip** (`cms` → `upc`, `bea` / `posteingang` → `de`). User override beats everything.
+  2. **Ad-hoc chip** from Step 1's explore-mode bypass (`upc` / `de` / `epa` / `dpma`).
+  3. **Project context** (`project.proceeding_type_id` → `proceeding_types.code` → prefix → `upc` / `de` / `epa` / `dpma`).
+- `perspectiveAllowsParty(c.party)` — hides leaves whose `party` tag contradicts the perspective chip. t-paliad-164 already auto-fills the chip from `project.our_side`.
+
+**So project-driven narrowing for the FORUM axis is shipped.** What m is asking for in this task is (a) generalize the pattern so MORE rows get pre-answered, (b) make the answered-state visible in the same row format, (c) hide rows whose answer is fully implied (UPC project + L3 Inbox).
+
+### 0.4 The taxonomy and rule corpus
+
+Live data, `paliad.event_categories` (recursive tree, t-paliad-133):
+
+- **6 root buckets** under `(root)`: `cms-eingang` ("Von wem ist das Schriftstück?"), `muendl-verhandlung` ("Mündliche Verhandlung"), `beschluss-entscheidung` ("Beschluss / Entscheidung"), `frist-verpasst` ("Frist verpasst"), `ich-moechte-einreichen` ("Ich möchte etwas einreichen"), `sonstiges` (terminal leaf).
+- **103 leaves total.** 91 carry a `forums` tag (`upc` / `de` / `epa` / `dpma`); 12 are neutral. 16 leaves carry a `party` tag — all under `ich-moechte-einreichen.*` (claimant / defendant) — the perspective filter touches outgoing filings only, never incoming Gegenseiten-Schriftstücke (which are symmetric: you receive what the other side sent regardless of who you are).
+- Cascade depth varies 2–4 levels. Slug encodes the path with dots, e.g. `cms-eingang.gegenseite.upc-inf.klageschrift` is 4 segments deep.
+
+`paliad.proceeding_types`:
+
+- **20 `category='fristenrechner'` codes** (the wizard / B1 cascade vocabulary): `UPC_INF`, `UPC_REV`, `UPC_APP`, `UPC_APP_ORDERS`, `UPC_COST_APPEAL`, `UPC_DAMAGES`, `UPC_DISCOVERY`, `UPC_PI`, `DE_INF`, `DE_INF_OLG`, `DE_INF_BGH`, `DE_NULL`, `DE_NULL_BGH`, `DPMA_OPP`, `DPMA_BPATG_BESCHWERDE`, `DPMA_BGH_RB`, `EPA_OPP`, `EPA_APP`, `EP_GRANT`.
+- **7 `category='litigation'` codes** (the project model's vocabulary): `INF`, `REV`, `CCR`, `APM`, `APP`, `AMD`, `ZPO_CIVIL`. All `jurisdiction='UPC'` except `ZPO_CIVIL`.
+- **The two vocabularies overlap conceptually but not row-wise.** Mapping `litigation_code × jurisdiction → fristenrechner_code` is required for Akte-derived narrowing beyond the 4-letter forum prefix. The brief lists this mapping; the live data confirms it's the only path.
+
+`paliad.deadline_rules.condition_flag` — 4 distinct flag-sets live in production: `[with_amend]`, `[with_cci]`, `[with_ccr]`, `[with_ccr, with_amend]`. Only on `UPC_INF` and `UPC_REV`. This is a Determinator-style variant axis the cascade does not surface today; out of scope for this design.
+
+### 0.5 Live state of `paliad.projects`
+
+| Column | Live data shape | Used by today's cascade? |
+|---|---|---|
+| `court` | **Free-text.** 4 non-null values across 4 rows: `LG München I` (1), `UPC` (2), `UPC CoA` (1). 7 rows NULL. | No. |
+| `proceeding_type_id` | FK → `proceeding_types.id`. **11/11 live rows are NULL.** | Yes — `forumFromProject` reads it, but it never fires in production today. |
+| `our_side` | enum `claimant` / `defendant` / `both` / `court` / NULL. | Yes — t-paliad-164 perspective chip predefine. |
+| `counterclaim_of` | uuid FK self-reference. | No (relevant for SmartTimeline, not Determinator). |
+| `filing_date` / `grant_date` | dates. | No (relevant to Verfahrensablauf wizard). |
+
+**Critical caveat:** 11/11 live projects have NULL `proceeding_type_id`. Until that's backfilled (a separate cleanup), Akte-driven narrowing degrades to "no opinion" for every existing project. The design honours this — silent degrade, no failed-load toast, the cascade simply doesn't narrow. m locked this v1 behaviour with kelvin on 2026-05-13.
+
+### 0.6 Anchor files for the implementer
+
+- `frontend/src/fristenrechner.tsx:227-310` — Pathway B markup (the four-layer mess).
+- `frontend/src/client/fristenrechner.ts:2405-2574` — `renderB1Cascade`.
+- `frontend/src/client/fristenrechner.ts:2914-3081` — forum + perspective narrowing engine (`activeForumOnPage`, `inboxFilterAllowsForums`, `perspectiveAllowsParty`, `applyOurSidePredefine`).
+- `frontend/src/styles/global.css:1636-1822` — `.fristen-pathway-shell`, `.fristen-mode-toggle`, `.fristen-b1-breadcrumb`, `.fristen-b1-question`, `.fristen-b1-buttons`, `.fristen-b1-button`, `.fristen-b1-step-back` (the visuals this design overhauls).
+- `frontend/src/styles/global.css:1965-2065` — `.fristen-inbox-bar`, `.fristen-perspective-bar`, `.fristen-inbox-chip` (the chip strip rules).
+- `frontend/src/client/views/verfahrensablauf-core.ts` (t-paliad-179) — pure-functional core, verified to carry **zero** Pathway B / cascade code. The lift is clean; this design is independent of it.
+
+### 0.7 Adjacent design docs
+
+- `docs/design-tools-cleanup-2026-05-12.md` (kelvin, t-paliad-178). Slice 1 of that shipped today; Slice 2 (Step 0 toggle + Akte auto-derivation on `/tools/fristenrechner`) is adjacent and will share the `litigation_code × jurisdiction → fristenrechner_code` mapping with this design.
+- `docs/research-determinator-coverage-2026-05-08.md` (curie, t-paliad-167). Identified leaves missing from the cascade. Out of scope here — this design is the UX shell that any future coverage additions will land into.
+
+If any of these conflict with what the task brief or memory asserts, **the live state wins** and the brief is the bug — flagged in §13 for m.
+
+---
+
+## 1. Vision + the three pillars
+
+m's framing (2026-05-13 11:17):
+
+> When I select a project, it should already narrow down the options (at least if it is a court proceeding). If it is a UPC proceeding, there is no need to show "non-UPC options"; this starts with the "how did you receive it?" which - for the UPC - will always be the UPC CMS.
+>
+> Not only is the different format for the levels of the questions weird (this needs an overhaul!), also there is no narrowing at all. I already described before that I want each decision on the tree to remain visible (one row per decision, it may be more compact than the active question was) and then go through things until there are only the least possible options left.
+
+Three pillars, intertwined:
+
+### Pillar 1 — Project-driven narrowing
+Pre-fill or hide decision rows whose answer is implied by the project. UPC project → "Wo kam es an?" is implied (CMS). Project with `our_side` → perspective implied. Project with `proceeding_type_id` → cascade root narrows to the matching forum (and deeper, if mappable).
+
+### Pillar 2 — Visual hierarchy overhaul
+All decision layers are **the same primitive**: a row with a question label, an answer-area, and an inline "ändern" affordance. Whether the layer is mode-toggle, perspective, inbox, or a cascade level, the visual shape is identical. The active layer expands inside its row; inactive (answered) layers compact to a single line.
+
+### Pillar 3 — Row-by-row persistent cascade
+Replace breadcrumb drilldown with stacked rows. Each answered decision stays visible as a compact row. The active question is the only row that expands. The cascade builds top-to-bottom; the user sees every choice they made in one glance, and the answered rows act as their own affordances for "ändern".
+
+The pillars interact:
+
+- Pillar 3 (row layout) needs to know what to skip (Pillar 1 narrowing). A skipped row can render as a compact "(aus Akte) UPC CMS" pseudo-row, or be absent. We pick per row in §5.
+- Pillar 2 (visual hierarchy) defines how *answered* vs *active* vs *skipped-but-shown* rows look. The four-different-treatments mess gets resolved by a single `.fristen-row` primitive.
+- Pillar 1 (narrowing) also affects *initial state*: in Akte-mode, several rows may render as already-answered on page load. The cascade jumps to the first un-answered row.
+
+---
+
+## 2. The row primitive
+
+The whole new layout is built from one element shape. Call it `.fristen-row` (the existing `.fristen-b1-*` class names get retired or rebased).
+
+```text
+┌─ .fristen-row ──────────────────────────────────────────────────────┐
+│  .fristen-row-num   .fristen-row-label              .fristen-row-edit │
+│  [1]                Wie suchen?                              [ändern] │
+│  .fristen-row-body                                                   │
+│  ✓ Schritt-für-Schritt                                                │
+└──────────────────────────────────────────────────────────────────────┘
+```
+
+Three states:
+
+### 2.1 `state="active"` — the user is answering this row
+
+```text
+┌─ .fristen-row.is-active ────────────────────────────────────────────┐
+│  [3]   Von wem ist das Schriftstück?                                 │
+│                                                                       │
+│        ┌──────────────┐  ┌──────────────┐  ┌──────────────┐          │
+│        │ ⚖️           │  │ 🏛️           │  │ ✉️            │          │
+│        │ Vom Gericht   │  │ Von der      │  │ Vom Patent-   │          │
+│        │               │  │ Gegenseite    │  │ amt           │          │
+│        └──────────────┘  └──────────────┘  └──────────────┘          │
+│                                                                       │
+│        ← zurück                                                       │
+└──────────────────────────────────────────────────────────────────────┘
+```
+
+Same chip-style buttons regardless of which row it is. Mode pick = two big chips. Perspective = three chips. Inbox = four chips. Cascade step = N chips, one per child node. Leaf cascade chips get a subtle modifier (`.fristen-row-chip--leaf`) so the user can see "this one ends the cascade".
+
+### 2.2 `state="answered"` — the user has picked, but the answer is below
+
+```text
+┌─ .fristen-row.is-answered ──────────────────────────────────────────┐
+│  [1]   Wie suchen?                              ✓ Schritt-für-Schritt │
+│                                                              [ändern] │
+└──────────────────────────────────────────────────────────────────────┘
+```
+
+Single line. The label, the picked answer, an "ändern" affordance. Click anywhere on the row (or the explicit ändern link) re-opens the row as active and drops every row below it. (This matches the existing breadcrumb-click semantic: jumping back to an ancestor invalidates descendants.)
+
+### 2.3 `state="prefilled"` — derived from the project (or other auto-source)
+
+```text
+┌─ .fristen-row.is-answered.is-prefilled ─────────────────────────────┐
+│  [2]   Ich vertrete                           ✓ Klägerseite          │
+│                                       aus Akte: HL-2024-001 [ändern] │
+└──────────────────────────────────────────────────────────────────────┘
+```
+
+Visually identical to `is-answered` but carries a small "aus Akte: <reference>" tag and a slightly muted background. Clicking ändern flips it to active (and drops the prefilled marker — the user has now made an explicit choice).
+
+This generalises t-paliad-164's perspective predefine: same shape, same hint, same override-by-click semantics. The hint becomes a row-level token rather than a one-off `<span>` next to the chip strip.
+
+### 2.4 `state="hidden"` — row is implied by an earlier pre-fill
+
+A row that adds no information given upstream rows can be omitted entirely. e.g. UPC project → forum is `upc` → inbox row's only valid answer is "CMS" → the row simply doesn't render. We **do not** render a `is-hidden` placeholder; the absence is the affordance. (This is m's "no need to show non-UPC options".)
+
+The first user-actionable row floats up under the prefilled stack.
+
+### 2.5 Why one primitive
+
+The current four-layer mess works against m because each layer looks like a different *kind* of question. The row primitive collapses that: every decision row carries the same "label + answer + ändern" anatomy. The user reads top-to-bottom; the answered rows stack as a paper trail; the active row is the only thing that demands interaction.
+
+This also implicitly solves the row-count tax of m's "see your selections" ask: the rows compact to ~28px each when answered, so even a deep cascade keeps the active question in the upper third of the viewport.
+
+---
+
+## 3. Answered / active / prefilled / hidden — visual treatment
+
+Concrete CSS sketch (Slice 1 will tune; this is the contract):
+
+| Token | Active | Answered | Prefilled | Hidden |
+|---|---|---|---|---|
+| `min-height` | auto (chips wrap) | `28px` | `28px` | 0 (not rendered) |
+| `background` | `var(--surface-card)` | `transparent` | `color-mix(var(--color-accent) 4%, transparent)` | n/a |
+| `border-left` | `4px solid var(--color-accent)` | none | `4px solid var(--color-accent-faded)` | n/a |
+| `font-weight` (label) | 600 | 500 | 500 | n/a |
+| `font-weight` (answer) | n/a | 600 | 600 | n/a |
+| `cursor` | default | pointer (whole row) | pointer (whole row) | n/a |
+| `ändern` affordance | hidden | shown on hover + always on focus-within | always shown | n/a |
+| Row number badge | accent-filled | outlined | outlined (faded) | n/a |
+
+**No `::before { inset: 0 }` overlay tricks.** The whole-row click is wired via a JS handler that calls `reopenRow(idx)` and skips clicks on `<a>` / `<button>` inside the row body — same pattern as `.entity-table` and the project-detail Verlauf items (CLAUDE.md anchor under "Whole-card / whole-row click").
+
+Active vs answered transition: when the user picks an answer in an active row, the row collapses to `is-answered` and the **next un-prefilled row materialises as active**. The DOM is preserved across the transition (row stack is one container with `data-state` attribute switched on each row); the chip set inside the answered row replaces with the single ✓-prefixed answer span.
+
+For the prefilled state's "aus Akte: <reference>" tag — reference comes from `project.reference` (e.g. `HL-2024-001`), falling back to the first 8 chars of `project.id` if no reference. Click on the reference tag is a navigation shortcut to the project (open in new tab — keeps the Fristenrechner state intact).
+
+---
+
+## 4. Project-driven narrowing — data mapping
+
+What can we derive from a selected project, and where does each derivation land?
+
+### 4.1 Mapping table
+
+| Derivation | Source column(s) | Maps to | Pre-fills row | Hides row? |
+|---|---|---|---|---|
+| **Forum** (upc / de / epa / dpma) | `proceeding_type_id` → `proceeding_types.code` prefix. Fallback: `court` free-text contains UPC/LG/OLG/BGH/BPatG/EPA/DPMA. | Cascade filter (existing `inboxFilterAllowsForums`). | "Wo kam es an?" if forum=UPC (→ CMS). DE: prefills nothing (beA vs Posteingang is a Postal Realität, not on the project). | UPC: yes. DE/EPA/DPMA: no. |
+| **Perspective** | `project.our_side` ∈ {claimant, defendant} | Cascade filter (existing `perspectiveAllowsParty`). | "Ich vertrete" → Klägerseite / Beklagtenseite. `both` / `court` / NULL: no prefill. | No — even when prefilled, the row stays visible (the user needs to see "ah yes, I'm the Beklagte here"). |
+| **Proceeding type** | `proceeding_type_id` + jurisdiction → fristenrechner code via `mapLitigationToFristenrechner()` (new helper, shared with t-paliad-178 Slice 2) | Cascade depth: prunes root buckets that don't apply, and prunes inner buckets to those matching the proceeding code. e.g. UPC + INF → only `cms-eingang.gegenseite.upc-inf.*`, `cms-eingang.gericht.urteil-upc-cfi`, etc. | Pre-collapses cascade sub-branches; surfaces deeper-leaf rows directly when only one path applies. | Hides intermediate cascade rows whose only child matches the derived code. |
+| **Counterclaim** | `counterclaim_of IS NOT NULL` | Implies `with_ccr` / `with_cci` condition flag context. | Not a cascade row today — surfaces as a `condition_flag` chip on the wizard. **Out of scope for this design**; flagged in §13 Q6. | n/a |
+| **Filing / grant dates** | `filing_date`, `grant_date` | Wizard anchor pre-fill. | Not a cascade row. Out of scope. | n/a |
+
+### 4.2 Detail: the litigation → fristenrechner mapping
+
+t-paliad-178 §0 and the task brief both call out: `project.proceeding_type_id` points at the **7 `litigation` codes** (INF, REV, CCR, APM, APP, AMD, ZPO_CIVIL). The cascade speaks **`fristenrechner` codes** (UPC_INF, DE_INF, ...). A small mapping is needed:
+
+```text
+INF + UPC      → UPC_INF
+INF + DE       → DE_INF        (first instance; OLG/BGH not derivable from project)
+REV + UPC      → UPC_REV
+REV + DE       → DE_NULL
+CCR + UPC      → UPC_INF + condition_flag=[with_ccr]  (linked via parent's proceeding)
+CCR + DE       → DE_NULL              (German Nichtigkeit IS the counterclaim equivalent)
+APP + UPC      → UPC_APP
+APP + DE       → DE_INF_OLG | DE_NULL_BGH  (ambiguous — needs court or instance hint; degrade)
+APM + UPC      → UPC_PI
+AMD + UPC      → UPC_INF + condition_flag=[with_amend]
+ZPO_CIVIL + DE → ZPO civil only; ignore for cascade (no fristenrechner code)
+```
+
+The mapping lives in **one** place — a new `internal/services/proceeding_mapping.go` (or the same shared helper t-paliad-178 Slice 2 introduces). The frontend gets the **resolved fristenrechner code** plus `condition_flag` array as part of the project payload (`ProjectOption.derived_fristenrechner_code` + `.derived_condition_flags`).
+
+**Honest about degrade:** the mapping isn't always 1:1. APP+DE is ambiguous, ZPO_CIVIL has no analogue, and projects without `proceeding_type_id` (all 11 live ones today) get no derivation at all. The cascade falls back to forum-only narrowing in every ambiguous case. **Never silent FK promotion.**
+
+### 4.3 Detail: court free-text fallback
+
+When `proceeding_type_id` is NULL but `court` has a recognisable substring:
+
+```text
+court contains "UPC"            → forum=upc
+court contains "BPatG"          → forum=de  (Nichtigkeit / DPMA-Beschwerde)
+court contains "BGH"            → forum=de
+court contains "OLG"            → forum=de
+court contains "LG"             → forum=de
+court contains "EPA" / "EPO"    → forum=epa
+court contains "DPMA"           → forum=dpma
+otherwise                       → no narrowing
+```
+
+This is a UX nicety, not a correctness mechanism. The fuzzy match always loses to a real `proceeding_type_id` if both are set. Surfaces as the prefilled-row reference tag: "Forum: UPC (aus Gericht: UPC CoA)".
+
+### 4.4 What the cascade hides given a forum
+
+`event_categories.forums` is the live signal:
+
+- 91/103 leaves carry a forum tag.
+- 12 are neutral (cross-cutting: `frist-verpasst`, `sonstiges`, some Mündl-Verhandlung leaves, court actions).
+
+With `forum=upc` active, ~73 leaves drop from the cascade. The user sees the same root buckets (cms-eingang / muendl / beschluss / frist-verpasst / ich-moechte-einreichen / sonstiges) but each bucket's children list collapses to the upc-relevant subset. **This is already wired today; the design doesn't change the filter, only its visual presentation.**
+
+The new contribution: when a non-leaf bucket reduces to a single descendant chain (e.g. UPC project → `cms-eingang` → `gegenseite` → `upc-inf` is the only chain), the cascade should optionally **auto-walk** the chain and surface the leaf parent's siblings directly. §5 below.
+
+### 4.5 What the cascade hides given perspective
+
+Currently only the 16 `ich-moechte-einreichen.*` leaves carry `party` tags. So perspective filters outgoing-filing nodes only. Incoming `cms-eingang.gegenseite.*` nodes don't have party tags — receiving from the opposing side is symmetric (you receive what they sent, regardless of who you are). This is correct and doesn't need fixing.
+
+**Design implication:** the perspective row is *always* visible (rows can never be `is-hidden` based on perspective alone), even when prefilled, because its filter affects user-write decisions that the user might still want to override. Match t-paliad-164.
+
+---
+
+## 5. What gets pre-answered, hidden, or skipped-but-shown
+
+A concrete matrix per row, given live data + the rules above:
+
+| Row | Question | Pre-fill source | UPC project | DE project | EPA / DPMA project | No project (ad-hoc) | No project (zero ctx) |
+|---|---|---|---|---|---|---|---|
+| **R0 Mode** | Wie suchen? | none | active | active | active | active | active |
+| **R1 Perspective** | Ich vertrete | `project.our_side` | prefilled iff `our_side` ∈ {claimant, defendant}; else active | same | same (rare for EPA/DPMA — usually only `court` or NULL) | active | active |
+| **R2 Inbox** | Wo kam es an? | forum derivation | **hidden** (forum=upc ⇒ CMS implied) | active (beA vs Posteingang) | active | active | active |
+| **R3 Bucket** | Was ist passiert? | none — user always picks the bucket | active | active | active | active | active |
+| **R4..Rn Cascade** | per-node `step_question_de` | proceeding-code derivation can pre-walk a single-child chain | optionally auto-walks single-child chains | same | same | active | active |
+
+Notes:
+
+- **R0 Mode**: kept active in all cases. The user always picks Tree vs Filter (or skips R0 entirely if we ditch the mode toggle — see §6). The mode pick is meta and not derivable from the project.
+- **R1 Perspective**: a project with `our_side='both'` is rare but legitimate; it lands as active. `'court'` is even rarer (m's project model includes a "we are the court" perspective for hypothetical training scenarios). For now: `court` → active row.
+- **R2 Inbox**: m's literal ask. UPC → hidden. DE → active (because beA vs Posteingang is meaningful for downstream Phase-0 manual workflows even if the cascade filter doesn't care). EPA/DPMA → active (e.g. EPA online filing vs Post). The "Alle" chip stays for "I don't know yet".
+- **R3 Bucket**: the 6 root buckets are always shown. Even with a derived proceeding code, the user still has to say "I'm here because I received something / mündl. Verhandlung / Urteil / etc." This is too coarse to derive.
+- **R4..Rn Cascade auto-walk**: when a derived proceeding code reduces a bucket's children to a single chain, the cascade should pre-walk that chain. e.g. UPC + INF + `cms-eingang` bucket → only `gegenseite.upc-inf.*` chain survives → R4 `gegenseite` is pre-answered (with the "aus Akte" badge), R5 jumps directly to `upc-inf` (also pre-answered), and R6 is the active question "Welcher Schriftsatz?". The user sees four R-rows (R0, R1 prefilled, R3 picked, R4 prefilled, R5 prefilled, R6 active) — clean paper trail of inference + one active question.
+
+  **Important constraint:** auto-walk is **descendants-of-the-picked-bucket only**. R3 (bucket) is always active because the bucket is the user's intent. We never auto-pick the bucket. So a UPC project doesn't pre-pick "cms-eingang" for you; it just makes the sub-cascade efficient once you've said "cms-eingang".
+
+### 5.1 Compact summary diagram — UPC INF project drilling into a cms-eingang opposing-side schriftsatz
+
+```text
+┌─ Step 1: Akte (Step 1 surface, above Pathway B) ────────────────────┐
+│ Akte: HL-2024-001 — Acme v. Globex (UPC INF)        [Andere Akte]   │
+└─────────────────────────────────────────────────────────────────────┘
+┌─ [1] Wie suchen?                       ✓ Schritt-für-Schritt [ändern]┐
+└─────────────────────────────────────────────────────────────────────┘
+┌─ [2] Ich vertrete                      ✓ Klägerseite          [ändern]┐
+│                                                  aus Akte: HL-2024-001│
+└─────────────────────────────────────────────────────────────────────┘
+                                ⨯  Row R2 (Inbox) hidden — UPC implies CMS
+┌─ [3] Was ist passiert?                 ✓ CMS-Eingang          [ändern]┐
+└─────────────────────────────────────────────────────────────────────┘
+┌─ [4] Von wem ist das Schriftstück?    ✓ Von der Gegenseite    [ändern]┐
+│                                          aus Akte (UPC INF impliziert)│
+└─────────────────────────────────────────────────────────────────────┘
+┌─ [5] Welches Verfahren?               ✓ UPC Verletzungsverfahren     │
+│                                          aus Akte: HL-2024-001       │
+└─────────────────────────────────────────────────────────────────────┘
+┌─ [6] Welcher Schriftsatz wurde eingereicht?    (active, awaiting pick)│
+│                                                                       │
+│  ┌──────────────────┐  ┌──────────────────┐  ┌──────────────────┐    │
+│  │ Klageschrift     │  │ Klageerwiderung  │  │ Replik           │    │
+│  │ (R.13)           │  │ + Widerklagen    │  │                  │    │
+│  └──────────────────┘  └──────────────────┘  └──────────────────┘    │
+│  ... (rest of UPC_INF Schriftsätze)                                   │
+│                                                                       │
+│  ← zurück                                                              │
+└─────────────────────────────────────────────────────────────────────┘
+```
+
+Six rows. Three user picks (mode, bucket, leaf). Three Akte-derived prefills. One R2 absent. The user sees their full decision path at a glance.
+
+For comparison, today's UI: the user clicks four times into the cascade, the top of the page is two chip strips and a radio they didn't touch, the breadcrumb at the top of `.fristen-b1-cascade` shows three crumb buttons in 12pt text, and there's no inline indication that the cascade is narrower than the full taxonomy. m's "no narrowing at all" is the literal reading of what's visible.
+
+### 5.2 Compact summary diagram — DE project drilling into the same
+
+```text
+┌─ [1] Wie suchen?                       ✓ Schritt-für-Schritt [ändern]┐
+└─────────────────────────────────────────────────────────────────────┘
+┌─ [2] Ich vertrete                      ✓ Klägerseite          [ändern]┐
+│                                                  aus Akte: HL-2024-002│
+└─────────────────────────────────────────────────────────────────────┘
+┌─ [3] Wo kam es an?                                (active, awaiting pick)┐
+│                                                                       │
+│  ┌──────┐  ┌──────────────┐  ┌──────┐                                 │
+│  │ beA  │  │ Posteingang  │  │ Alle │                                 │
+│  └──────┘  └──────────────┘  └──────┘                                 │
+└─────────────────────────────────────────────────────────────────────┘
+... and the cascade continues below once R3 is answered.
+```
+
+R2 (Inbox) is active because beA vs Posteingang is a real distinction for German projects. The forum is already known (`de`), so the cascade below R3 will be DE-only — but the user still tells us *how* the document arrived.
+
+### 5.3 Compact summary diagram — abstract / no-Akte mode
+
+```text
+┌─ [1] Wie suchen?                                  (active, awaiting pick)┐
+│                                                                       │
+│  ┌────────────────────────┐  ┌─────────────────────┐                  │
+│  │ Schritt-für-Schritt    │  │ Filter / Suche      │                  │
+│  │ (Entscheidungsbaum)    │  │                     │                  │
+│  └────────────────────────┘  └─────────────────────┘                  │
+└─────────────────────────────────────────────────────────────────────┘
+```
+
+No prefills, no hidden rows. Every row is asked. Full taxonomy.
+
+---
+
+## 6. Filter / Suche mode — coexistence with the cascade
+
+Today's mode toggle (radio) is a UX wart: it's the only radio on the page, it looks unlike everything else, and it sits at the top of Pathway B as if it were a primary axis.
+
+Two options to fold it into the row model:
+
+### Option A — Mode is R0, a row like any other
+
+The mode toggle becomes the first row in the stack. Two chips. Pick determines what populates below: tree picker → R3 + cascade. Filter picker → R3 collapses into a search input + result list. The row stays visible (you can switch mid-flow via ändern), but the chrome is consistent.
+
+Pros: simple, every decision is a row, the page reads top-to-bottom.
+Cons: adds one always-active row to every flow including the "I know what I'm doing, just give me search" use case.
+
+### Option B — Mode is an escape hatch, not a row
+
+Filter is positioned as "ich weiß schon, wonach ich suche" — a small link / icon at the top of Pathway B that toggles between cascade and search. No R0 row. Default = cascade. Click → search replaces the row stack.
+
+Pros: fewer rows, less for the common case to scan past.
+Cons: more discoverable than the current radio? unclear. "Where did the radio go?" is a question.
+
+### Option C — Filter as a *bottom-of-stack* affordance
+
+Cascade is the only top-down flow. Below the cascade results, a "Sie wissen schon den Namen? → direkt suchen" link / row appears. Search is a graceful fallback, not a peer mode.
+
+Pros: gives cascade the primary surface, search becomes a tool for "wait, I know better".
+Cons: discoverability of search is reduced for power users who DO know.
+
+**Inventor's pick:** Option B. The radio is dead weight, and the search use case is "I know the name; let me skip the cascade" — that's an escape hatch, not a peer axis. Visually: a small `🔍` icon-button at the top-right of Pathway B titled "Direkt suchen". Click expands a search input that replaces the row stack; result list appears below; "← Zurück zum Entscheidungsbaum" returns to the row stack with prior state preserved.
+
+But this is design-question territory — m's call. §13 Q1.
+
+---
+
+## 7. Mobile + responsive
+
+The row primitive is naturally responsive: rows stack vertically by default. Width concerns only the chip set inside an active row.
+
+### 7.1 Breakpoints
+
+`paliad` already uses 640 / 768 / 1023 px breakpoints. The rows live inside `.fristen-pathway-shell` which is already a column-flex.
+
+| Width | Row chrome | Chip layout (active row) |
+|---|---|---|
+| ≥ 1024px | full label + answer + ändern on one line, badge left | chips in a 3-column grid (or auto-fill min 220px) |
+| 768–1023px | same | chips in a 2-column grid |
+| 640–767px | label + answer on line 1, ändern on line 2 right-aligned | chips in a 1-column stack |
+| < 640px | label on line 1, answer on line 2, ändern as `›` icon right-aligned | chips full-width, single column |
+
+### 7.2 Active-row collapse on tap (mobile-only)
+
+On `< 768px`, the row stack scrolls; the active row's chip set can be long (e.g. 9 Schriftsatz children). When the user picks an answer, the page autoscrolls so the next active row is at the top of the viewport. This is the same pattern as the Akte picker (Step 1) and existing form flows.
+
+### 7.3 What we don't do on mobile
+
+- **No drawer / modal for the cascade.** The whole point of the row stack is being able to see history at a glance; collapsing into a separate surface defeats it.
+- **No fly-out for ändern.** Tap on an answered row's ändern affordance simply re-activates the row in place.
+- **No "next" button.** Picking a chip advances automatically; mobile doesn't need an extra tap to confirm.
+
+---
+
+## 8. "Neu starten" / Reset semantics
+
+Three flavours of reset, all need a home:
+
+### 8.1 Reset the whole cascade (every row to empty)
+
+Today: clicking the breadcrumb's "Pfad zurücksetzen" root crumb. In the new layout: a small `↺ Pfad zurücksetzen` link at the top of the row stack, right of the heading. Clicking it:
+- Drops every cascade row (R3+).
+- Leaves R0 (Mode), R1 (Perspective prefilled), R2 (Inbox if visible) as they are — those are "context", not "the user's investigation".
+- Re-activates R3.
+
+Optional behaviour (per Q9): a confirm-dialog if the user has drilled ≥ 3 cascade levels deep. Probably overkill; current breadcrumb root-click is destructive without confirm. Match existing semantic.
+
+### 8.2 Drop just one decision (ändern semantic)
+
+Built into every answered row's `[ändern]` affordance and clicking on the row body. Effect: that row reverts to active; every row below it drops; URL ?b1= shortens to that row's prefix.
+
+This is the workhorse of the row stack — m's "you can see your selections" UX implies "you can also rewind to any of them at any time". Built-in.
+
+### 8.3 Drop the Akte-derived prefills
+
+Trickier: if the user clicks ändern on a `is-prefilled` row, the prefill is overridden. But what about "I want to ignore my Akte entirely for this exercise"? The Akte itself is bound at the Step 1 surface, above Pathway B. Clicking "Andere Akte" at the Step 1 summary unbinds the Akte and drops all `is-prefilled` markers. The cascade rows that were `is-answered` because they were prefilled now revert to `is-active` (or, if the user had already explicitly overridden via ändern, stay answered with no `is-prefilled` flag).
+
+This semantic already half-exists for t-paliad-164's perspective predefine; we generalise it to every prefilled row. Implementation: hold a `prefillSources: Map<rowID, "akte" | "user">` and re-derive on Akte unbind / change.
+
+### 8.4 The "Neu starten" button at the bottom
+
+A second affordance at the bottom of the results area, after the user has reached a leaf and is reading concept-cards. "Andere Frist nachschlagen?" → reset to R3. Optional but discoverable; today's UI lacks an equivalent, so this is a small UX win.
+
+---
+
+## 9. Search affordance integration
+
+Tied to §6's mode-toggle question. Two integration points:
+
+### 9.1 Search panel placement (Option B from §6)
+
+The `🔍 Direkt suchen` button lives at the top-right of `.fristen-pathway-shell`. Click → animates the row stack out (or simply replaces it), shows a search input row with a single text field + result list below. ESC or "← Zurück zum Entscheidungsbaum" returns; row stack restores via URL state.
+
+The search is the existing `?q=` + B2 chips flow — we don't rebuild it, just relocate its entry point. Existing forum-filter chip row stays inside the search panel.
+
+### 9.2 Inline search on each cascade row (rejected)
+
+An alternative: each cascade row's chip list gets a tiny "filter chips" input at the top. Reject. Adds chrome to every active row for a feature most users don't need.
+
+### 9.3 "I searched but want to see the path" round-trip
+
+When the user lands on a leaf via search, optionally show "Im Entscheidungsbaum öffnen → " — clicking restores the row stack with all ancestor rows pre-answered (which is what the cascade's slug already encodes). This is a small extra: lets a search-first user verify "yes, this is the leaf I thought, here's the proceeding context I missed".
+
+---
+
+## 10. Slicing for the coder pass
+
+Three slices, each independently shippable, mergeable in order:
+
+### Slice 1 — Visual hierarchy + row-by-row layout (no narrowing change)
+
+Replaces the four-layer mess with the row primitive. **No backend or DB changes.** The narrowing engine stays the same (existing forum + perspective filters fire); the visual presentation moves from breadcrumb + chip strips + radio → row stack.
+
+In scope:
+- New `.fristen-row` CSS primitive (with `.is-active`, `.is-answered`, `.is-prefilled` modifiers).
+- Refactor `renderB1Cascade` into a row-stack renderer (`renderRowStack(rows: RowSpec[])`).
+- Migrate L1 (mode) / L2 (perspective) / L3 (inbox) / L4..n (cascade) all to row instances.
+- "ändern" semantic = re-activate row, drop rows below, push history state.
+- Reset link at top of stack.
+- i18n keys for row labels.
+
+Out of scope for Slice 1:
+- Project-derived proceeding-code narrowing (the `mapLitigationToFristenrechner` helper).
+- Auto-walk single-child cascade chains.
+- Hide-R2-on-UPC behaviour (Slice 2 — needs the proceeding mapping helper anyway).
+- Search affordance relocation (Slice 3).
+
+Outcome: same data, same narrowing, **vastly better visual narrative**. The user can finally see their decision path. m's pillar 2 + 3 are addressed.
+
+### Slice 2 — Project-driven narrowing depth
+
+Adds the `litigation_code × jurisdiction → fristenrechner_code` mapping and uses it to:
+- Pre-fill the proceeding-type sub-cascade rows (R5 in the §5.1 diagram).
+- Hide R2 (Inbox) when project is UPC.
+- Auto-walk single-child chains.
+- Add the "aus Akte: <reference>" tag on prefilled rows.
+
+This is where Pillar 1 fully lands. Depends on Slice 1's row primitive.
+
+Includes a small backend helper (shared with t-paliad-178 Slice 2 if both ship in parallel): `internal/services/proceeding_mapping.go` exposes `MapLitigationToFristenrechner(litCode string, jurisdiction string) (fristenCode string, conditionFlags []string, ok bool)`.
+
+Outcome: an Akte-bound user starts the cascade with three rows already answered, and only one or two active questions remain to drill to the leaf.
+
+### Slice 3 — Search affordance + mobile polish
+
+Relocates the mode-toggle / search affordance per §6 Option B. Adds the responsive breakpoints from §7. Polishes the autoscroll-to-active behaviour on mobile.
+
+Mobile-only fixes ride here so Slices 1+2 can be reviewed by m at desktop width first.
+
+### Why this order
+
+- Slice 1 is purely visual. m can see the row stack and validate the layout BEFORE we change any narrowing semantic. If m hates the row primitive, we revert one PR. (We won't — but the option matters.)
+- Slice 2 is the heavy correctness lift. It depends on the mapping helper, on Akte payload extensions, and on careful Test_DATABASE_URL integration tests.
+- Slice 3 is final polish. Independently mergeable, lowest risk.
+
+Each slice is roughly:
+- Slice 1: 1 frontend PR (~700 LoC TSX + CSS + client). No backend, no migrations.
+- Slice 2: 1 mixed PR (~150 LoC Go + 300 LoC client). No migrations.
+- Slice 3: 1 frontend PR (~150 LoC).
+
+---
+
+## 11. Tradeoffs flagged
+
+### 11.1 Row stack is taller than the current shell
+
+A deep cascade (4 levels) plus 3 prefilled rows + R0 = 8 rows. Each ~28px compact + the active row's chip body (200–400px depending on chip count) + spacing → ~600–800px tall. The current shell is ~400px tall in the same scenario. Mitigation: rows are compact (28px), active-row autoscrolling keeps the chip set in view on mobile, and the visual narrative wins. m's ask explicitly trades vertical space for visibility.
+
+### 11.2 "Aus Akte" tags are slightly noisy
+
+Three rows showing "aus Akte: HL-2024-001" reads a bit redundant. Mitigation: only the first prefilled row shows the reference; subsequent rows show "(aus Akte)" without the reference. Saves vertical noise, keeps the source visible once.
+
+### 11.3 Auto-walk single-child chains can confuse
+
+The user picks "cms-eingang" → suddenly two rows materialise pre-answered. Looks magical. Mitigation: the two rows are clearly `is-prefilled` with an "aus Akte (UPC INF impliziert)" tag, and ändern is available on each. After the user has done it twice, the inference becomes a feature; before, a tooltip on first-render ("Diese Schritte ergeben sich aus Ihrer Akte") could help (deferred for v2 — see Q11).
+
+### 11.4 Removing the radio mode-toggle is a behavioural change
+
+Existing power users may know the radio. Mitigation: the new `🔍 Direkt suchen` icon-button at the top of Pathway B is a visible affordance; URL ?mode=filter still works as deep-link. Soft transition.
+
+### 11.5 11/11 live projects have NULL `proceeding_type_id`
+
+Slice 2's narrowing literally doesn't fire in production today. We're building UX that requires data nobody has yet. Mitigation: graceful degrade (forum-only narrowing via court free-text fuzzy match — already a feature today). Backfill of `proceeding_type_id` is a separate follow-up (see Q13).
+
+### 11.6 The mapping table in §4.2 has ambiguities
+
+APP+DE → ambiguous; ZPO_CIVIL → no analogue; CCR ↔ counterclaim modeling is fragile. Mitigation: every ambiguous case degrades to "no narrowing" — the row stays active rather than incorrectly pre-filled. Better silent than wrong.
+
+### 11.7 ändern-on-an-ancestor invalidates descendants
+
+Same as today's breadcrumb-click semantic — clicking a non-current crumb drops cascade depth. **No data is lost** (you can re-walk the cascade), but if the user was reading concept-cards at a leaf, those cards disappear. Mitigation: when ändern is clicked on an answered row, before dropping descendants, brief inline confirmation? Or just match today's behaviour (drop immediately). Inventor recommends match-today; Q12.
+
+### 11.8 The row primitive may be over-engineered
+
+A single visual primitive for four functionally different layers is a strong opinion. If a future cascade layer (e.g. variant chips for `condition_flag`) doesn't fit the primitive shape, we have to either extend the primitive or break the consistency. Mitigation: the primitive is shape (label + answer-area + ändern), not behaviour — variant chips fit because they're also "pick one (or several)". The contract is loose enough.
+
+---
+
+## 12. Files the implementer will touch (Slice 1 only)
+
+### 12.1 Frontend
+
+- **`frontend/src/fristenrechner.tsx:227-310`** — Pathway B markup. Replace `.fristen-mode-toggle` + `.fristen-perspective-bar` + `.fristen-inbox-bar` + `.fristen-b1-cascade` with a single `.fristen-row-stack` container. Add minimal scaffolding rows for mode / perspective / inbox / cascade-host. Keep `.fristen-b1-results` below — unchanged.
+- **`frontend/src/client/fristenrechner.ts:2405-2574`** — Refactor `renderB1Cascade` into `renderRowStack(rows)`. The row spec is a discriminated union: `{kind: "mode" | "perspective" | "inbox" | "cascade", state: "active" | "answered" | "prefilled", question, options[], picked?}`. Rendering is one function per state; one switch on `kind` for the options builder.
+- **`frontend/src/client/fristenrechner.ts:2914-3081`** — `inboxFilterAllowsForums` + `perspectiveAllowsParty` unchanged (Slice 1 is visual-only).
+- **`frontend/src/client/fristenrechner.ts:initInboxFilter`** + perspective init — same handlers, new DOM targets.
+- **`frontend/src/client/i18n.ts`** — ~20 new keys under `deadlines.row.*` (row labels, ändern affordance, prefilled tag, reset link, "next active" autoscroll-target announce).
+- **`frontend/src/styles/global.css:1636-1822` + `:1965-2065`** — Retire `.fristen-mode-toggle`, `.fristen-perspective-bar`, `.fristen-inbox-bar`, `.fristen-b1-breadcrumb`, `.fristen-b1-question`, `.fristen-b1-buttons`, `.fristen-b1-button*`. Add `.fristen-row-stack`, `.fristen-row`, `.fristen-row-num`, `.fristen-row-label`, `.fristen-row-answer`, `.fristen-row-edit`, `.fristen-row-body`, `.fristen-row-chip`, `.fristen-row-chip--leaf`, `.is-active`, `.is-answered`, `.is-prefilled`.
+
+### 12.2 Backend
+
+No backend changes for Slice 1. The existing `/api/tools/fristenrechner/event-categories` and `/api/tools/fristenrechner/search` endpoints are unchanged.
+
+### 12.3 Tests
+
+- Pure-TS unit tests for `buildRowStack(currentState)` if extracted (table-driven: given URL state + Akte payload, output the RowSpec[]).
+- Playwright smoke (post-deploy): land on Pathway B with `?path=b&project=<uuid>`, verify R1 prefilled with "aus Akte", R2 hidden for UPC project, ändern on R1 reopens, ändern on bucket drops cascade depth.
+
+### 12.4 Anchoring back
+
+t-paliad-164 perspective predefine code is the precedent. Re-read it before implementing — same hint mechanism, same override semantics, generalised.
+
+t-paliad-178 Slice 2 (Step 0 toggle + Akte auto-derivation) is parallel; coordinate on the shared `proceeding_mapping.go` helper file (Slice 2 of this task introduces it; t-paliad-178 Slice 2 can adopt or vice versa, depending on which lands first).
+
+---
+
+## 13. Open questions for m
+
+These are inventor's calls flagged for m's gate. Picking is on m, not the coder.
+
+**Q1 — Mode-toggle disposition.** Three options in §6: (A) R0 row, (B) escape-hatch icon-button [inventor's pick], (C) bottom-of-stack affordance. Pick one or specify another.
+
+**Q2 — UPC project: hide R2 entirely or show as compact prefilled?**
+- Hide entirely (inventor's pick — matches m's "no need to show non-UPC options").
+- Show as compact `[2] Wo kam es an? ✓ UPC CMS [ändern] aus Akte` row — verbose but explicit.
+
+**Q3 — Auto-walk single-child cascade chains?**
+- Yes, materialise R4..Rn-1 as prefilled (inventor's pick — strong UX, but feels magical first time).
+- No, the user always picks their way down even when only one child applies (slower, more predictable).
+- Yes-but-only-when-≥-2-rows-collapse (tradeoff).
+
+**Q4 — "ändern" affordance shape on an answered row.**
+- Hover-revealed link "ändern" (inventor's pick — keeps row clean by default).
+- Always-visible pencil icon (more discoverable but more chrome).
+- Whole-row click is the only handle (cleanest, but no visible affordance — newcomers won't discover it).
+
+**Q5 — Drop confirmation when ändern invalidates descendants?**
+- No (match today's breadcrumb-click — inventor's pick).
+- Yes, when ≥ 3 cascade levels would be dropped.
+- Always — even a one-row drop confirms.
+
+**Q6 — Counterclaim awareness in the cascade.**
+`project.counterclaim_of IS NOT NULL` implies `[with_ccr]` or `[with_cci]` condition flag depending on the parent's proceeding code. Should this surface as a prefilled row (e.g. "Variante: with_ccr"), or only as a backend filter on the result concept cards (silent)?
+- Surface as a prefilled row (transparency — user sees the variant is active).
+- Silent backend filter (no row tax, but mystery narrowing).
+- Out of scope for this design — handle in a separate variant-chip task.
+
+**Q7 — R0 mode-pick deep link.**
+If a user lands on `?path=b` without `?mode=`, do we default to tree or to "no R0 picked yet"?
+- Default to tree, R0 prefilled (today's behaviour — silent).
+- R0 active until the user picks (more explicit, but adds one extra click for the common case).
+
+**Q8 — Prefilled-row override permanence.**
+After the user clicks ändern on a prefilled R1 (perspective) and explicitly picks "Beklagter" instead of the Akte's "Kläger", does this override persist if they re-bind the same Akte?
+- No, re-bind re-applies (today's behaviour — clean, but overrides feel ephemeral).
+- Yes, store override per-Akte in localStorage (sticky overrides — UX-friendly, but new state).
+
+**Q9 — Reset confirm.**
+A "Pfad zurücksetzen" link at the top of the row stack — confirm dialog?
+- No confirm — match today's breadcrumb root-click (inventor's pick).
+- Confirm if cascade depth ≥ 3.
+- Always confirm.
+
+**Q10 — Search escape-hatch position.**
+Per §6 / §9, the `🔍 Direkt suchen` button sits at the top-right of Pathway B.
+- Top-right (inventor's pick — discoverable, doesn't push down the row stack).
+- Below the row stack, after results.
+- As a permanent row at the bottom of the stack.
+
+**Q11 — First-visit tooltip on auto-walked rows.**
+"Diese Schritte ergeben sich aus Ihrer Akte" tooltip on the first prefilled-from-mapping row, dismissed forever on first close?
+- Yes (helps onboarding).
+- No (extra chrome; the "aus Akte" tag is enough).
+- Inline help-icon (?) link to a docs page (longer-form).
+
+**Q12 — Concept cards live below the row stack today. Should they collapse / hide when the user reopens an ancestor row (ändern)?**
+- Collapse/hide on ändern, repopulate when the cascade reaches a leaf again (inventor's pick — matches the "no orphan content" rule).
+- Keep visible as last-known until cascade resolves to a new leaf.
+
+**Q13 — Backfill `paliad.projects.proceeding_type_id`?**
+11/11 live rows are NULL. Slice 2's narrowing depends on this. Should the Slice 2 PR also include a one-off Akte-edit nudge ("Projekt-Setup vervollständigen: Verfahrensart fehlt"), or do we wait until m manually fills them in over time?
+- Inline "Verfahrensart ergänzen" link on Akten with NULL proceeding_type_id.
+- Backfill script (inferring from `court` free-text where unambiguous).
+- Defer entirely; live with degraded narrowing until users fill it organically.
+
+**Q14 — Reorder rows so prefilled stack at top, user-picked at bottom?**
+The §5.1 diagram orders rows R0..Rn in their natural cascade sequence (mode → perspective → inbox → bucket → cascade depth). The prefilled rows happen to be R1, R4, R5 (not contiguous). Alternative: visually float all prefilled rows to a single "aus Akte" group at the top, with user-picked rows below. Tradeoff: cleaner separation vs. losing the temporal narrative of the decision path.
+- Keep natural order (inventor's pick — narrative wins).
+- Group prefilled at top.
+
+**Q15 — Should `Filter / Suche` mode also see Akte prefills?**
+If the user enters search mode with a project bound, do we silently scope results to the project's forum, or show the full taxonomy?
+- Scope (consistent with cascade narrowing — inventor's pick).
+- Don't scope (search is a "I know what I'm looking for" mode; the project is incidental).
+- Scope with a visible toggle "Auch andere Foren anzeigen".
+
+---
+
+## DESIGN READY FOR REVIEW
+
+Awaiting m's go/no-go on the questions in §13 before the coder shift starts. Inventor (pauli) parks after this commit — no implementation kickoff, no other-skill autoload, head gates the transition.
+
+Recommended implementer: pattern-fluent Sonnet coder. The row primitive is straightforward CSS + a small state machine refactor; the precedent code (t-paliad-164 + t-paliad-133 cascade engine) is well-understood. **NOT cronus per memory directive 2026-05-06.**

docs/design-inbox-overhaul-2026-05-25.md

@@ -0,0 +1,848 @@
+# Design: /inbox overhaul — project-events feed + filtering + list/cards/calendar toggles
+
+**Task:** t-paliad-249
+**Gitea:** m/paliad#80
+**Author:** icarus (inventor)
+**Date:** 2026-05-25
+**Status:** LOCKED — head confirmed Q1=A with two refinements (2026-05-25), see §12.
+**Branch:** `mai/icarus/inventor-inbox-overhaul`
+
+---
+
+## 0. TL;DR
+
+`/inbox` today is approval-requests only. m wants it to become the actual
+"what's new on my projects" surface — approval requests **plus** recent
+project_events on visible projects — with the same view-toggle paradigm
+as `/events` (list / cards / calendar) and a meaningful filter row.
+
+The good news: the substrate already exists.
+
+- `view_service.RunSpec` unions four sources (deadline, appointment,
+  **project_event**, **approval_request**) into one ranked `[]ViewRow`.
+- `FilterSpec` has predicates for every axis we need
+  (`ProjectEventPredicates.EventTypes`, `ApprovalRequestPredicates`).
+- `filter-bar` knows the axes we need: `time`, `project`,
+  `approval_viewer_role`, `approval_status`, `approval_entity_type`,
+  `project_event_kind`, plus `shape` / `sort` / `density`.
+- Shape renderers exist: `shape-list` (table + compact + approval), `shape-cards`
+  (day-grouped), `shape-calendar` (thin adapter on `mountCalendar`).
+
+So the work is **mostly re-mix**:
+
+1. Extend `InboxSystemView` from `Sources=[ApprovalRequest]` to
+   `Sources=[ApprovalRequest, ProjectEvent]`, default
+   `Time.Horizon=Past30d`, and add a curated `project_event.event_types`
+   default that filters out noise (approvals duplicate-suppression,
+   checklist mutations, status churn).
+2. Extend `shape-list.ts` so `row_action="approve"` no longer assumes
+   every row is an approval — rename it `"inbox"`, dispatch per
+   `row.kind` (approval → existing approve-card layout; project_event →
+   navigate-style stream row).
+3. Wire the existing view-axis selector (the chip cluster on `/events`)
+   onto `/inbox`'s host, persisting selection via the filter-bar URL
+   codec (axis `shape` already in `AxisKey`).
+4. Add a high-watermark read cursor (`paliad.users.inbox_seen_at`) +
+   `POST /api/inbox/mark-all-seen` + extend `/api/inbox/count` to count
+   unseen project_events too. Adds one new axis `unread_only` to the bar.
+
+That's Slice A. Slice B layers cards + calendar toggles cleanly. Slice C
+is per-item dismissal — keep out of v1 unless the cursor proves not
+enough (m's pick Q3 is the cursor).
+
+No new aggregation service, no new endpoint family — the inbox runs on
+`/api/views/inbox/run` like every other system view does today.
+
+---
+
+## 1. Current `/inbox` state
+
+**Routes (`internal/handlers/approvals.go`):**
+
+| Path                                  | Behaviour                                                    |
+|---------------------------------------|--------------------------------------------------------------|
+| `GET /inbox`                          | Serves `dist/inbox.html`, a thin shell. No SSR data.         |
+| `GET /api/inbox/pending-mine`         | Approval requests I can approve.                              |
+| `GET /api/inbox/mine`                 | Approval requests I submitted (all statuses by default).      |
+| `GET /api/inbox/count`                | `{count: N}` for the sidebar bell badge — `PendingCountForUser`. |
+| `GET /api/approval-requests/{id}`     | Hydrate one request (used by suggest-changes modal).          |
+| `POST /api/approval-requests/{id}/{action}` | `approve` / `reject` / `revoke` / `suggest-changes`.    |
+
+**Data path:** `frontend/src/client/inbox.ts` mounts the universal
+`FilterBar` over the inbox `SystemView` (slug `"inbox"`, sources
+`[approval_request]`, viewer_role `any_visible`, status `[pending]`).
+The bar fetches `/api/views/system`, hands the spec to itself, calls
+`/api/views/inbox/run?…`, and stamps rows via `shape-list.ts`'s
+`renderApprovalList(rows)` path (gated by `row_action="approve"`).
+
+**Action wiring:** `wireApprovalActions(host)` listens on
+`.views-approval-action` clicks; on success it triggers
+`bar.refresh()` and `refreshInboxBadge()` (which pokes
+`/api/inbox/count`).
+
+**Empty state + admin nudge:** when the result list is empty AND the
+caller is `global_admin` AND no `approval_policies` row exists firm-wide,
+the page shows a "configure policies" CTA. Otherwise the localized
+"no items" empty-state text.
+
+**Sidebar bell:** `Sidebar.tsx:143` `navItem("/inbox", BELL_ICON, …)`
+plus `client/sidebar.ts:320–345`'s `initInboxBadge` which polls
+`/api/inbox/count` every 60s. Badge clamps to `"9+"`.
+
+### What aggregates cleanly
+
+The whole approval flow already plugs into `RunSpec`'s union pipeline.
+That's the win — extending sources from `[ApprovalRequest]` to
+`[ApprovalRequest, ProjectEvent]` is a `[]DataSource` literal edit in
+`InboxSystemView()` and the engine fans out per source, sorts, returns
+one `[]ViewRow`. The hard work (`runProjectEvents` + the
+visibility predicate + project metadata join) is already in
+`view_service.go:344–430`.
+
+### What doesn't aggregate (yet)
+
+- **Read state.** There is no `inbox_seen_at` on `paliad.users` (verified
+  via information_schema). The bell badge counts pending **approval
+  requests for the caller** only — it has no notion of "new project
+  events since last visit". We have to add it.
+- **Mixed `row_action`.** `shape-list.ts`'s `renderApprovalList` assumes
+  every row is an approval and unconditionally parses
+  `row.detail` as an `ApprovalDetail`. Project_event rows in the same
+  list would crash the parse. We need to branch per `row.kind` inside
+  the inbox row stamper.
+- **`/inbox` shape toggle.** `client/inbox.ts` hardcodes `shape-list`;
+  the `shape` axis is wired into `filter-bar/axes.ts` but `/inbox`'s
+  `INBOX_AXES` deliberately omits it (because today the only meaningful
+  shape was list). Adding it onto INBOX_AXES + a small dispatcher in
+  `onResult` gives us cards + calendar for free.
+
+Everything else (sidebar entry, /api/views machinery, FilterBar URL
+codec, RowAction validation) carries through unchanged.
+
+---
+
+## 2. Event-type catalogue for inbox v1 (Q1)
+
+This is the only design pick that requires a head/m signal. **Open
+question Q1 in §9 — defaulting to (A) until head answers.**
+
+### (R) Recommendation (A): curated subset
+
+Sources: `[approval_request, project_event]`.
+
+**Approval requests:** all rows whose `viewer_role=any_visible` AND
+status ∈ {pending} by default; the existing chip cluster
+(approver_eligible / self_requested / any_visible) stays. Decided
+requests are filtered by the chip, not hidden by source-removal — so a
+user who wants to see "what got approved this week" toggles the status
+chip rather than the source.
+
+**Project events:** filter by `event_type ∈ InboxProjectEventKinds`
+where InboxProjectEventKinds is a new sub-list of KnownProjectEventKinds:
+
+| event_type              | In inbox v1? | Reason                                                              |
+|-------------------------|--------------|---------------------------------------------------------------------|
+| `project_created`       | no           | The author already saw the page; not news to the team yet (the team grows post-creation). |
+| `project_archived`      | **yes**      | High-signal lifecycle event ("Akte XY wurde archiviert").           |
+| `project_reparented`    | **yes**      | Hierarchy moves matter to everyone with access.                     |
+| `project_type_changed`  | **yes**      | Same reason.                                                        |
+| `status_changed`        | no           | Currently too granular; surface in Verlauf, revisit if m disagrees. |
+| `deadline_created`      | **yes**      | New deadline on a project I can see — exactly the kind of event m named ("we should also display new events"). |
+| `deadline_completed`    | **yes**      | Likewise.                                                           |
+| `deadline_reopened`     | **yes**      | Likewise.                                                           |
+| `deadline_updated`      | **yes**      | Currently in DB (11 rows live) but not in KnownProjectEventKinds — add it. |
+| `deadline_deleted`      | **yes**      | Likewise — add to KnownProjectEventKinds.                           |
+| `deadlines_imported`    | **yes**      | Bulk-import event surfaces what got added.                          |
+| `appointment_created`   | **yes**      |                                                                     |
+| `appointment_updated`   | **yes**      |                                                                     |
+| `appointment_deleted`   | **yes**      |                                                                     |
+| `note_created`          | **yes**      | A note is "someone said something about this project". High-signal; add to KnownProjectEventKinds. |
+| `our_side_changed`      | **yes**      | Party-side flip; high-signal, add to KnownProjectEventKinds.        |
+| `member_role_changed`   | no           | Admin churn; would dominate active users' inbox. Revisit slice B. |
+| `*_approval_requested`  | **no — de-duped** | The approval_request row itself carries the signal; the audit event is the same fact in a different table. Filtering it out avoids duplicate inbox entries. |
+| `*_approval_approved/rejected/revoked` | **no — de-duped** | Same reason. The approval_request row's status flip is what the user sees. |
+| `*_approval_changes_suggested` | **no — de-duped** | Same. |
+| `approval_decided`      | no           | This is the umbrella audit-only kind; superseded by the approval_request row. |
+| `checklist_*`           | no           | Low signal; checklists are surfaced on the project's checklist page. |
+
+The de-dup pattern means: if a row exists in `approval_requests` for an
+entity, the corresponding `*_approval_*` project_event is **not** shown
+in the inbox — we trust the approval_request row.
+
+### Alternative (B): everything in KnownProjectEventKinds + approvals
+
+Simpler — no curated sub-list, no de-dup. Two drawbacks:
+
+1. `*_approval_*` duplicates would render twice per request.
+2. `status_changed` and `member_role_changed` are admin churn; in firm
+   tests both would dominate.
+
+If head picks B, we need at minimum the `*_approval_*` de-dup; otherwise
+the inbox renders the same fact twice.
+
+### Alternative (C): minimal — approvals + appointment_* + deadline_*
+
+Tightest set. Drops notes + our_side_changed + project_*. Risk: m's
+brief literally says "new events that relate to one's projects" — notes
+and side changes ARE such events. C feels too narrow.
+
+---
+
+## 3. Read/unread model (Q3 → R: high-watermark cursor)
+
+### (R) Decision: per-user high-watermark `inbox_seen_at`
+
+**Schema:**
+
+```sql
+ALTER TABLE paliad.users
+    ADD COLUMN inbox_seen_at timestamptz NULL;
+```
+
+NULL means "never visited" → everything counts as unread. The high-water
+cursor advances exactly when the user POSTs to
+`/api/inbox/mark-all-seen` (UI affordance: a button in the inbox header
++ implicit advance on page-mount, see Slice A wiring below).
+
+### Why cursor, not per-item
+
+m's recommendation: cursor. Mine matches: single column, no fan-out
+table, covers the common case ("I checked my inbox, mark everything
+read"). Per-item dismiss is Slice C — opt-in only if the cursor proves
+inadequate. The risk we're guarding against: a single high-value pending
+approval that's a week old gets buried by 80 fresh deadline_updated
+events; the user clears the badge and may now never look at the
+approval. Mitigation: **approval_requests with status=pending never
+fall behind the cursor** — they count toward the badge regardless of
+seen_at. This is a tiny conditional in the count query (Slice A).
+
+### Cursor advance behaviour
+
+- **Explicit:** "Alles als gelesen markieren" button in the inbox
+  header. POSTs `/api/inbox/mark-all-seen`; server sets
+  `inbox_seen_at = now()`.
+- **Implicit:** when the page mounts AND the bar surfaces at least one
+  row that's newer than the current cursor, the *new* cursor is
+  remembered locally as the timestamp of the **newest visible row**.
+  We do **not** auto-advance the server cursor on mount — too easy to
+  lose items behind a stray pageview. The "neu" highlight on rows
+  newer than the saved cursor is the silent UX. Explicit click is the
+  one and only path to clearing the badge.
+
+### `unread_only` axis
+
+New filter-bar axis (Slice A):
+
+```ts
+// types.ts
+unread_only?: boolean;
+```
+
+When `true`, the bar overlays a FilterSpec predicate:
+`row.event_date > inbox_seen_at` (substrate-side filter; for project_events
+that's `pe.created_at > $cursor`, for approval_requests that's
+`requested_at > $cursor` OR `status='pending'` per the carve-out above).
+
+Default: **unread_only=true** for first paint (per Slice A — landing on
+the inbox shows you what's new). The "Alle" chip flips it off so the
+user can see history.
+
+---
+
+## 4. Filter contract
+
+The bar surfaces these axes on `/inbox` (`INBOX_AXES` constant in
+`client/inbox.ts`):
+
+| Axis                     | Why on /inbox                                                        | New? |
+|--------------------------|----------------------------------------------------------------------|------|
+| `time`                   | "Last 30 days" (default) with chip cluster + "Älter anzeigen" .       | already |
+| `project`                | Single-select autocomplete from visible projects.                    | already |
+| `approval_viewer_role`   | "Zur Genehmigung" / "Eigene Anfragen" / "Alle sichtbaren".            | already |
+| `approval_status`        | pending / approved / rejected / revoked / changes_requested.         | already |
+| `approval_entity_type`   | Frist / Termin (chip pair).                                          | already |
+| `project_event_kind`     | Chip cluster over InboxProjectEventKinds.                            | already |
+| **`unread_only`**        | Boolean toggle ("Nur ungelesen" / "Alle"); defaults to ungelesen.    | **Slice A new axis** |
+| `shape`                  | list / cards / calendar.                                             | already in `AxisKey`, not yet on `/inbox` |
+| `sort`                   | Newest first (default) / oldest first.                               | already |
+| `density`                | comfortable / compact.                                               | already |
+
+**Default landing state** for a brand-new pageview:
+`?time=past_30d&unread_only=true&a_status=pending&shape=list&sort=date_desc`.
+
+Bookmarks from older clients (e.g. the legacy `?tab=pending-mine`)
+still work because `client/inbox.ts:46–58` already applies the legacy
+tab → `a_role` redirect at hydration.
+
+### Source-removal not exposed as an axis
+
+Users do **not** see a "show approvals only / show events only" chip.
+The signal we want is "what's new across my projects"; splitting the
+two via the filter row is busywork. If they want approvals-only they
+chip-pick `project_event_kind` empty + status=any (or future axis pick
+`source=approval_request`). If feedback shows otherwise after Slice A
+ships, we add the axis in Slice B trivially (`Sources` is a
+spec.Sources literal flip).
+
+---
+
+## 5. View toggle implementation plan (Q5 → R: list / cards / calendar)
+
+The pattern `/events` uses today (see `frontend/src/events.tsx:107–141`
+for the `<div className="events-view-selector">` block and
+`client/events.ts:617–650` for the `applyView` function):
+
+- One chip cluster `data-event-view="cards|list|calendar"`.
+- Active class toggle.
+- Per-shape `display: none` on the table-wrap / cards-wrap / cal-wrap
+  hosts.
+- For calendar, `mountCalendar()` constructs a month/week/day grid
+  into a dedicated `events-calendar-wrap` host; the handle is destroyed
+  on shape-leave so its URL state doesn't leak into the other shapes.
+
+### Mapping onto /inbox
+
+The cleanest path: **use `filter-bar`'s built-in `shape` axis instead of
+a per-page selector.** The axis already round-trips into the URL via
+`url-codec.ts` and serialises into `RenderSpec.Shape`. `client/inbox.ts`
+just needs:
+
+1. Add `"shape"` to `INBOX_AXES`.
+2. Dispatch in the `onResult` callback by `effective.render.shape`:
+
+   ```ts
+   onResult: (result, effective) => {
+     switch (effective.render.shape) {
+       case "cards":    return paintCards(result.rows, effective.render, ...);
+       case "calendar": return paintCalendar(result.rows, ...);
+       case "list":
+       default:         return paintList(result.rows, effective.render, ...);
+     }
+   }
+   ```
+
+3. The renderers exist already: `renderCardsShape` in
+   `views/shape-cards.ts`, `renderCalendarShape` in
+   `views/shape-calendar.ts`, `renderListShape` in `views/shape-list.ts`.
+   The only piece of new code is the per-shape host-clearing on switch
+   (so we don't leak a stale shape's DOM into the new host).
+
+### Calendar shape — items without dates
+
+Calendar can only render rows with a calendar-mappable date. Today:
+
+- **approval_request:** `requested_at` (timestamp). Maps fine, but
+  shows up as a single point — rendering an approval-request on a month
+  grid is semantically "you got asked on this day". OK for v1.
+- **project_event:** `created_at`. Same shape.
+- **deadline:** `due_date`. Already supported.
+- **appointment:** `start_at`. Already supported.
+
+So every row in the inbox v1 has a calendar position. No
+need to filter rows on calendar-mount. **One caveat:** the calendar
+shape currently doesn't render action affordances (approve/reject) — it
+opens a detail dialog on click. Slice B accepts that: clicking an
+approval row on the calendar opens the inbox-list-style detail in a
+modal (re-using the existing per-row /api/approval-requests/{id}
+fetch). Out of scope for Slice A.
+
+### Cards shape — day-grouped chronological cards
+
+`shape-cards.ts` groups by day and renders one card per row, with
+title + meta + actor. The approval-card layout there is the standard
+card (no approve buttons — same caveat as calendar). For Slice B, we
+extend `shape-cards.ts` to detect `row.kind === "approval_request"
+&& row.detail.status === "pending"` and stamp the approve/reject button
+strip inline. The DOM template is the same as
+`shape-list.ts:renderApprovalRow`, so most of the work is hoisting that
+template into a shared util.
+
+---
+
+## 6. Backend aggregation service (Q6 → R: reuse RunSpec)
+
+**Decision: do not build a new aggregation service.** The
+substrate-level work is exactly two edits:
+
+### 6.1 InboxSystemView (system_views.go:103–144)
+
+```go
+func InboxSystemView() SystemView {
+  return SystemView{
+    Slug: "inbox",
+    Name: "Inbox",
+    Filter: FilterSpec{
+      Version: SpecVersion,
+      Sources: []DataSource{
+        SourceApprovalRequest,
+        SourceProjectEvent,
+      },
+      Scope: ScopeSpec{Projects: ScopeProjects{Mode: ScopeAllVisible}},
+      Time:  TimeSpec{Horizon: HorizonPast30d, Field: FieldAuto},
+      Predicates: map[DataSource]Predicates{
+        SourceApprovalRequest: {ApprovalRequest: &ApprovalRequestPredicates{
+          ViewerRole: "any_visible",
+          Status:     []string{"pending"}, // default; bar can override
+        }},
+        SourceProjectEvent: {ProjectEvent: &ProjectEventPredicates{
+          EventTypes: InboxProjectEventKinds, // curated subset
+        }},
+      },
+    },
+    Render: RenderSpec{
+      Shape: ShapeList,
+      List: &ListConfig{
+        Density:   DensityComfortable,
+        Sort:      SortDateDesc, // newest first — different from today's date_asc
+        RowAction: RowActionInbox, // new — see §6.3
+      },
+    },
+  }
+}
+```
+
+Curated sub-list lives in `filter_spec.go` next to KnownProjectEventKinds:
+
+```go
+var InboxProjectEventKinds = []string{
+  "project_archived", "project_reparented", "project_type_changed",
+  "deadline_created", "deadline_completed", "deadline_reopened",
+  "deadline_updated", "deadline_deleted", "deadlines_imported",
+  "appointment_created", "appointment_updated", "appointment_deleted",
+  "note_created", "our_side_changed",
+}
+```
+
+(With Q1 pick A locked. If head picks B, drop the InboxProjectEventKinds
+list and remove the `EventTypes` predicate. If head picks C, narrow the
+list to deadline_* + appointment_* only.)
+
+KnownProjectEventKinds in `filter_spec.go:186` needs **additions** so
+`note_created`, `our_side_changed`, `deadline_updated`, `deadline_deleted`,
+`deadlines_imported` are valid filter values — without this the
+validator rejects the InboxSystemView spec. Migrate this list at the
+same time. (`event_categories` and similar grouping infra are already
+covered by `event_category_service.go` and won't move.)
+
+### 6.2 Approval-duplicate suppression
+
+In `view_service.runProjectEvents` (or in a tiny new predicate helper),
+skip `event_type LIKE '%_approval_%'` when source-set includes
+ApprovalRequest. This avoids the double-count described in Q1 §2.
+
+Implementation: extend `allowedProjectEventKinds` (view_service.go:649) to
+auto-drop the `*_approval_*` strings when the same RunSpec already
+fans out the approval_request source. One conditional, six lines.
+
+### 6.3 Mixed-row row_action
+
+`shape-list.ts` today: `row_action="approve"` → calls
+`renderApprovalList(rows)` which assumes every row is an approval.
+Need a new value:
+
+```go
+// render_spec.go
+const RowActionInbox ListRowAction = "inbox"
+```
+
+And register it in `KnownRowActions`.
+
+Frontend (`shape-list.ts`):
+
+```ts
+if (rowAction === "inbox") {
+  host.appendChild(renderInboxList(sorted));
+  return;
+}
+```
+
+Where `renderInboxList(rows)`:
+
+- approval_request rows → existing `renderApprovalRow(row)` template (the
+  per-row factor-out from `renderApprovalList`).
+- project_event rows → a new `renderProjectEventRow(row)` template:
+  timestamp + actor + title + project chip + optional "Öffnen" link
+  to the underlying entity (deadline / appointment / note / project
+  detail). Modelled on the Verlauf row in
+  `client/projects-detail.ts:651–700` (`.entity-event` markup).
+
+This makes the inbox stamping kind-aware. The
+existing `wireApprovalActions` continues to find buttons via class
+`.views-approval-action` and works unchanged.
+
+### 6.4 Endpoints — what's new vs reused
+
+| Path                                | Behaviour                                                | Slice |
+|-------------------------------------|----------------------------------------------------------|-------|
+| `GET /api/views/inbox/run`          | **Already exists** — fans the InboxSystemView spec.     | A reuse |
+| `GET /api/inbox/count`              | **Behaviour change:** count includes unread project_events on visible projects + pending approval_requests (the latter regardless of cursor). | A |
+| `POST /api/inbox/mark-all-seen`     | New. Sets `users.inbox_seen_at = now()` for the caller.  | A |
+| `GET /api/inbox/pending-mine`       | **Keep** — backwards-compat for clients (sidebar bell may still use it). | unchanged |
+| `GET /api/inbox/mine`               | **Keep** — used by the saved view `inbox-mine`.         | unchanged |
+
+The two `/api/inbox/{pending-mine,mine}` endpoints stay because they're
+narrower-than-RunSpec optimisations and used by the dashboard's
+`loadInboxSummary`. No reason to remove them.
+
+### 6.5 InboxSummary on the dashboard (out of scope, but flag)
+
+`DashboardData.InboxSummary` (dashboard_service.go:89) currently counts
+only pending approvals. If Slice C extends the badge count to include
+unread project_events, the dashboard widget also needs to swap
+`PendingCountForUser` for the new unified count — keep this as a small
+follow-up after Slice A ships and the cursor semantics are proven.
+
+---
+
+## 7. Slice plan
+
+### Slice A — Project-event aggregation + read cursor + list view
+
+**Goal:** /inbox shows pending approvals + curated project_events for
+visible projects in the last 30 days, with the new "Nur ungelesen"
+toggle. List view only.
+
+Tasks:
+
+1. **Migration `NNN_inbox_seen_at.up.sql`:**
+   `ALTER TABLE paliad.users ADD COLUMN inbox_seen_at timestamptz NULL;`
+2. **`filter_spec.go`:** extend `KnownProjectEventKinds` (add
+   `note_created`, `our_side_changed`, `deadline_updated`,
+   `deadline_deleted`, `deadlines_imported`). Add
+   `InboxProjectEventKinds` (curated subset, Q1=A).
+3. **`system_views.go`:** rewrite `InboxSystemView` per §6.1 with
+   both sources, `HorizonPast30d`, `SortDateDesc`,
+   `RowAction=RowActionInbox`.
+4. **`render_spec.go`:** add `RowActionInbox`, register in
+   `KnownRowActions`.
+5. **`view_service.go`:** in `runProjectEvents`, auto-drop
+   `*_approval_*` event_types when ApprovalRequest is in
+   `spec.Sources` (§6.2).
+6. **`approvals.go`:**
+   - New handler `handleInboxMarkAllSeen` →
+     `UPDATE paliad.users SET inbox_seen_at = now() WHERE id = $1`.
+   - Modify `handleInboxCount` to return
+     `pending_approvals_count + unread_project_events_count`. SQL
+     in approval_service.go: one new method
+     `UnseenInboxCountForUser(userID)` returning that union. Keep
+     `PendingCountForUser` (dashboard still uses it).
+7. **`shape-list.ts`:** factor `renderApprovalRow(row)` out of
+   `renderApprovalList`. Add `renderInboxList(rows)` that dispatches
+   per `row.kind`. Wire `row_action="inbox"` to it.
+8. **`client/inbox.ts`:**
+   - Add the `unread_only` axis to `INBOX_AXES` and wire to a FilterSpec
+     overlay (sub-spec `Time.Horizon=Past30d` AND
+     filter predicate "newer than cursor OR pending-approval").
+   - Render "Alles als gelesen markieren" button in the page header
+     (in `inbox.tsx`); on click POST `/api/inbox/mark-all-seen`,
+     refresh bar + badge.
+   - Listen for cursor update (server response) and refresh.
+9. **Sidebar badge (`client/sidebar.ts:initInboxBadge`):** unchanged code
+   path, but the new server count includes project_events. Add no client
+   changes for v1 — server returns the wider count.
+10. **i18n:** new keys —
+    - `inbox.title.feed` ("Inbox") replaces "Genehmigungen" in the page
+      header (since the page is now more than approvals).
+    - `inbox.subtitle.feed` ("Neuigkeiten zu Ihren Projekten und offene
+      Genehmigungen.").
+    - `inbox.action.mark_all_seen` ("Alles als gelesen markieren").
+    - `inbox.axis.unread_only.on/off`.
+    - `inbox.empty.feed` ("Keine Neuigkeiten in den letzten 30 Tagen.").
+    - `views.col.event_kind` (for the kind column in
+      table-density list).
+    - DE primary, EN secondary, both in `i18n.ts`.
+11. **Tests:** `system_views_test.go` covers the
+    InboxSystemView spec shape; new test for the de-dup helper in
+    view_service. `approval_service_test.go` adds tests for the new
+    `UnseenInboxCountForUser` method. New
+    `inbox_seen_at_test.go` covers the cursor migration + the POST
+    handler.
+12. **Verify** the page renders for a sample user with both event types
+    visible, "Nur ungelesen" toggles correctly, mark-all-seen clears the
+    badge, the project-events deduplicate against approval requests.
+
+### Slice B — Cards + calendar shape toggles
+
+**Goal:** `?shape=cards` and `?shape=calendar` work on /inbox; users can
+switch via the bar's shape chip. Approval rows on cards/calendar are
+*read-only* (open detail modal on click; no inline approve/reject).
+
+Tasks:
+
+1. **`client/inbox.ts`:** add `"shape"` to `INBOX_AXES`. Add the
+   per-shape host divs to `inbox.tsx` (one for cards, one for calendar)
+   matching the `/events` pattern. Implement `onResult` dispatch.
+2. **`shape-cards.ts`:** when `row.kind==="approval_request"` AND
+   `row.detail.status==="pending"`, stamp the approval row template
+   inline. Hoist the template out of `shape-list.ts` if reuse pays.
+3. **`shape-calendar.ts`:** approval_request rows render as date-point
+   chips; click opens a detail modal. The modal reuses the existing
+   `approval-edit-modal` for suggest-changes when the user is the
+   approver; otherwise a read-only summary.
+4. **CSS:** ensure `.entity-event` and `.views-approval-row` markup
+   coexist on the cards view without z-index clashes; lightweight
+   targeting via `.views-cards-list[data-surface="inbox"]`.
+5. **Tests:** shape toggle persistence via URL codec (already covered
+   in `url-codec.test.ts`; add one inbox-surface case).
+
+### Slice C — Badge upgrade + per-item dismiss (deferred)
+
+**Goal:** sidebar badge reflects unified count; per-item dismiss for
+power-users.
+
+Tasks:
+
+1. **`paliad.inbox_dismissals` table** —
+   `(user_id, source, row_id, dismissed_at)` PK `(user_id, source, row_id)`.
+   "source" is `approval_request` / `project_event`; "row_id" is the
+   row's UUID. New endpoint `POST /api/inbox/dismiss` body
+   `{source, row_id}`. RunSpec for inbox subtracts dismissed rows.
+2. **`/api/inbox/count`:** subtract dismissed rows from the count.
+3. **Dashboard widget:** `DashboardData.InboxSummary` swaps to a new
+   `UnifiedInboxSummary` that mirrors the page count. Backwards-compat
+   JSON: keep old fields, add `total_count` and `top_unified`.
+4. **Empty-state:** "Alle Einträge gelesen — gut gemacht."
+5. **Optional `member_role_changed` etc.:** if Slice A surfaces that
+   one of the excluded event_types is actually wanted, this slice opens
+   up `InboxProjectEventKinds` accordingly.
+
+### Why Slice A alone is shippable
+
+Slice A delivers m's full ask except the cards/calendar views — which
+are aesthetic shape toggles, not data changes. Slice A gives:
+
+- Inbox feed across approvals + project_events for visible projects
+- Project / type / time / read-state filters
+- Newest-first list with mark-all-seen
+- Sidebar badge reflects unified unread count (server-side)
+
+Slice B + C are layer cake on top with no schema or substrate changes.
+
+---
+
+## 8. Out of scope
+
+- **Push notifications.** Telegram / WhatsApp / email — different
+  channel concerns, separate design.
+- **Cross-user inbox views.** No "admin sees others' inboxes" in v1.
+- **Pinning / starring items.** Not in m's ask. If feedback after Slice
+  A wants it, opens its own design.
+- **Paliadin chat unread.** Not part of project_events; paliadin lives
+  in its own pane. Slice C could surface a banner if asked.
+- **Replacement of the existing /api/inbox/{pending-mine,mine} endpoints.**
+  They stay because the dashboard's `loadInboxSummary` uses them and
+  no benefit to consolidating.
+- **Detail-page changes.** Clicking a project_event row in the inbox
+  navigates to the existing entity detail page (deadline, appointment,
+  note); we don't build a new "event detail" view.
+- **InboxSummary on the dashboard.** Out of Slice A. Slice C upgrades
+  it; for now the widget keeps showing approval-only.
+
+---
+
+## 9. Open questions for m
+
+Defaulted to (R) per the inventor protocol — only **Q1** is escalated
+to head for explicit confirmation because it changes the
+inbox's surface area. Everything else falls to the recommended pick
+unless head/m flag otherwise.
+
+**Q1 — Event-type catalogue (material pick, head answered):**
+**LOCKED = A** (curated subset with `*_approval_*` de-dup). Head added
+`member_role_changed` to the curated list with a Slice B narrowing
+follow-up + a coarser `inbox_focus` chip cluster on the bar. Full
+decision recorded in §12.
+
+**Q2 — Time window:** (R) Past30d default + chip cluster
+(today / past_7d / past_30d / past_90d / any) + custom range via the
+existing time picker. Locked unless head overrides.
+
+**Q3 — Read/unread model:** (R) High-watermark cursor
+(`users.inbox_seen_at`). Pending approval_requests carry forward even
+when older than the cursor — guards against burying a high-value
+approval. Per-item dismiss is Slice C, opt-in. Locked.
+
+**Q4 — Filters surfaced on the bar:** (R) time / project /
+approval_viewer_role / approval_status / approval_entity_type /
+project_event_kind / unread_only / shape / sort / density. Locked
+unless head wants `source` (approvals-only vs events-only chip)
+added — defaulting to "not in v1".
+
+**Q5 — View toggle parity with /events:** (R) list (default — newest
+first) / cards (day-grouped) / calendar (date-point). Wired via the
+filter-bar's existing `shape` axis, not a per-page selector. Locked.
+
+**Q6 — Architecture:** (R) Reuse `view_service.RunSpec` with both
+sources in the InboxSystemView spec; no new aggregation service.
+Approval-event de-dup applied in `runProjectEvents`. Locked.
+
+**Q7 — Notification badge:** (R) Yes — Slice A makes the existing
+`/api/inbox/count` return the unified unread count; sidebar badge
+client unchanged. Locked.
+
+**Q8 — Acknowledgement flow:** (R) Approval rows keep
+approve/reject/revoke buttons inline (list shape only). project_event
+rows have no inline action — click row → navigate to the underlying
+entity. Cursor advance is via "Alles als gelesen markieren" only —
+no per-row mark-read in v1. Locked.
+
+**Q9 — Empty-state copy:** (R) "Keine Neuigkeiten in den letzten 30
+Tagen." (DE primary) / "No updates in the last 30 days." (EN). The
+existing admin nudge for unseeded approval_policies stays untouched.
+Locked.
+
+---
+
+## 10. Risks + mitigations
+
+- **Performance.** `runProjectEvents` reads up to LIMIT 500 rows per
+  user-call; with two sources unioned + 30-day window + visibility
+  predicate this should stay under 50ms on the live shape (project
+  count ~100, events/day low double digits). If
+  it doesn't, partial index hint: `paliad.project_events (created_at DESC)
+  WHERE event_type IN (curated list)` — Slice A optional, add if
+  EXPLAIN shows a seq scan in dev.
+- **De-dup correctness.** Suppressing `*_approval_*` events in the
+  project_event source relies on the approval_request row being the
+  authoritative signal. **Edge case:** a request gets revoked, then
+  re-requested — both audit events exist. Both correspond to a single
+  approval_request row at any moment (the latter via the partial-index
+  upsert). De-dup stays valid.
+- **Cursor advance race.** If two browser tabs both POST mark-all-seen,
+  the second wins (now() wins). Acceptable. If a user reads in tab A
+  then clicks an item in tab B that was created between the two reads,
+  tab A's "Alles als gelesen" advances past that newer item without
+  the user seeing it. Mitigation: server-side, `mark-all-seen` accepts
+  an optional `?up_to=<iso>` so the client can pin to the timestamp of
+  the newest visible row. Slice A wires this.
+- **shape-list factor-out.** Pulling `renderApprovalRow` out of
+  `renderApprovalList` risks regressions on the *current* /inbox. Cover
+  with a snapshot/golden test on the approval row markup in Slice A
+  before the dispatch change.
+- **Sidebar bell badge cap.** Current code clamps at "9+". Once we add
+  project_events, the count can easily exceed 100. Keep the "9+" clamp
+  for visual reasons — but make the page header show the *exact* count
+  ("123 neu") so the user knows what's behind it.
+- **Q1 fallback.** If head doesn't reply before Slice A coder shift
+  starts, the (R) pick A locks. If head later picks B or C, the only
+  change is the `InboxProjectEventKinds` list literal in
+  `filter_spec.go` — no schema impact, no migration change. Cheap to
+  flip.
+
+---
+
+## 11. Build/test verify list (Slice A done-when)
+
+1. `make build` clean.
+2. `go test ./...` passes; new tests cover:
+   - InboxSystemView spec shape includes both sources + curated kinds.
+   - `runProjectEvents` drops `*_approval_*` when ApprovalRequest is in spec.
+   - `UnseenInboxCountForUser` returns expected count for cursor and pending-approval combinations.
+   - POST `/api/inbox/mark-all-seen` updates the column.
+   - URL codec round-trip for `unread_only` axis.
+3. Inbox loads at `/inbox` with project-event rows interleaved with
+   approval rows in date-desc order.
+4. "Nur ungelesen" chip toggles between unread (with pending-approval
+   carve-out) and full feed.
+5. "Alles als gelesen markieren" advances cursor; bar refreshes;
+   badge clears (except for any still-pending approvals).
+6. Sidebar bell badge count is the unified number (approval + unread events).
+7. Existing approve/reject/revoke + suggest-changes flows on inbox
+   rows still work unchanged.
+8. `?tab=mine` legacy redirect still hits the right state.
+9. Bilingual labels render (DE/EN toggle).
+
+That's the doneness bar for Slice A.
+
+---
+
+## §12 — m's decisions (head 2026-05-25 11:30)
+
+Head replied to the `mai instruct head` escalation; folded in below.
+
+**Q1 (Event-type catalogue): A — locked.** Curated subset with
+`*_approval_*` de-dup. Tracks Verlauf, matches m's framing ("new events
+that relate to one's projects"), avoids double-counting approval audit
+events against the approval_request row.
+
+Locked InboxProjectEventKinds:
+
+- IN: `project_archived`, `project_reparented`, `project_type_changed`,
+  `deadline_created`, `deadline_completed`, `deadline_reopened`,
+  `deadline_updated`, `deadline_deleted`, `deadlines_imported`,
+  `appointment_created`, `appointment_updated`, `appointment_deleted`,
+  `note_created`, `our_side_changed`, **`member_role_changed`**
+  (added by head — see refinement #1).
+- OUT (audit duplicates of approval_requests): every `*_approval_*` event.
+- OUT (too granular / authoring noise): `status_changed`,
+  `project_created`, `checklist_*`.
+
+**Refinement 1 — `member_role_changed` visibility predicate.**
+Head wants this kind included but narrowed: surface the row only when
+the role change applies to the **viewer themselves** or someone above
+them in the project tree (i.e. impacts the viewer's permissions / chain
+of command), not when it's a peer's role changing on a project the
+viewer happens to see.
+
+- Slice A: include `member_role_changed` in
+  `InboxProjectEventKinds` without the narrowing predicate. The row
+  will appear for everyone who can see the project — over-surfacing but
+  not wrong. This keeps Slice A's MVP scope tight.
+- Slice B: add a per-row narrowing filter on top of the inbox source
+  (likely a small extension to `runProjectEvents` that, when
+  `event_type='member_role_changed'`, inspects `metadata.affects_user_id`
+  + walks the project-membership predicate before emitting). The
+  metadata shape is already written by the responsible handler; verify
+  + lock the filter in B.
+
+Q2-Q9 all default to (R) per the inventor protocol.
+
+**Refinement 2 — Filter chip copy.**
+For the visible chip cluster in the bar, head wants user-readable groupings,
+not raw event-kind names. The bar today exposes `project_event_kind`
+as one chip per kind (rendered via the
+`event.title.<kind>` i18n key). For the inbox surface, surface a
+**coarser grouping chip cluster** ahead of that:
+
+- "Genehmigungen" — narrows to `Sources=[approval_request]` only.
+- "Genehmigungen + Termine" — adds appointment_* event_kinds + the
+  approval_entity_type=appointment slice of approvals.
+- "Genehmigungen + Fristen" — adds deadline_* event_kinds + the
+  approval_entity_type=deadline slice of approvals.
+- "Alles" — default; both sources, full curated kinds list.
+
+Implementation: a new axis `inbox_focus` (Slice A, additive — replaces
+the lower-level `project_event_kind` chip's *default visibility* in the
+inbox UI; advanced users still see `project_event_kind` if they expand
+the bar). The four values map to FilterSpec overlays that tweak
+`Sources` + per-source `EventTypes`. Coder owns the exact chip-text
+final copy and the placement (probably first axis in `INBOX_AXES`).
+
+The lower-level `project_event_kind` chip stays in `INBOX_AXES` as an
+advanced override for power users — when active, it overrides the
+`inbox_focus` chip's per-kind defaults.
+
+---
+
+### What changes for Slice A as a result
+
+Doc deltas vs the draft text above:
+
+1. **§2 / §6.1:** add `member_role_changed` to InboxProjectEventKinds.
+   Note Slice B narrowing follow-up.
+2. **§4 / §5:** front of the bar gets a new `inbox_focus` axis
+   (4 chips: Alles / Genehmigungen / +Termine / +Fristen). Default
+   "Alles". `project_event_kind` stays available as an advanced chip,
+   visible after the user expands the bar's overflow section.
+3. **§7 Slice A task list:** add task —
+   "**12a.** New `inbox_focus` axis (`filter-bar/types.ts`,
+   `axes.ts`). FilterSpec overlay translates the chip value to a
+   `(Sources, ProjectEventPredicates.EventTypes, ApprovalRequestPredicates.EntityTypes)`
+   triple. URL codec round-trips."
+4. **§11 Slice B done-when:** add — "`member_role_changed` narrowing
+   predicate is in place; rows surface only when the change affects
+   the viewer's permissions chain."
+
+No schema changes from the head's adjustments. The `inbox_focus` axis
+is a pure UI/overlay primitive; nothing about the InboxSystemView spec
+schema moves.

docs/design-paliad-data-export-2026-05-19.md

@@ -0,0 +1,603 @@
+# Paliad data export — Excel-first, scoped (org / project-subtree / personal)
+
+Design: archimedes (inventor), 2026-05-19.
+Task: **t-paliad-214**.
+Branch: `mai/archimedes/inventor-excel-data`.
+Status: READY FOR REVIEW — no code yet, awaiting m go/no-go on §11 open questions.
+
+---
+
+## 0. Premise check (live state, 2026-05-19)
+
+Verified directly against the youpc Postgres `paliad` schema rather than against memory or older design docs.
+
+**Migration tracker.** Latest applied is `100_ccr_visible_rule`; next is **101**.
+
+**Row counts (org-wide today):**
+
+| table                  | rows |
+|------------------------|-----:|
+| users                  | 47   |
+| projects               | 11   |
+| deadlines              | 26   |
+| appointments           | 5    |
+| parties                | 0    |
+| notes                  | 4    |
+| documents              | 0    |
+| project_events (audit) | 93   |
+| project_teams          | 3    |
+| approval_requests      | 8    |
+| approval_policies      | 160  |
+| checklist_instances    | 4    |
+| deadline_rules         | 254  |
+| user_views             | 2    |
+| partner_units          | 11   |
+
+A full org export today is **< 600 rows of user content** plus reference data — synchronous streamed download is plausible for every scope. We design for an order-of-magnitude head-room.
+
+**Auth.** Passwords live in Supabase Auth (separate `auth` schema, not `paliad`). The `paliad.users` table has **no `password_hash` column** — so the "don't export credentials" rule from the brief is enforced by absence, not by a column-deny list. Good.
+
+**Visibility.** Row-level via `paliad.can_see_project(project_id)` (subtree-aware through ltree path). Already used as the predicate that gates every list endpoint. We reuse it for the **personal** and **project** scopes; the **org** scope bypasses it under `global_admin`.
+
+**Documents.** Table exists, 0 rows. Phase H (AI Frist-Extraktion) is deferred per m's 2026-04-16 call. No `ANTHROPIC_API_KEY` on Dokploy. Therefore **this design does not concern itself with binary attachments** — only with the metadata row when documents start landing.
+
+**Audit trail.** Lives in `paliad.project_events` (93 rows). One row per lifecycle event with `event_type`, `metadata jsonb`, `event_date`, `created_by`. The auditing union (`AuditService.ListEntries`) joins 5 sources (project_events, partner_unit_events, deadline_rule_audit, policy_audit_log, reminder_log). For the export we treat `project_events` as primary; the four auxiliary logs are scope-specific.
+
+**Existing export precedent.** `/admin/rules/export` + `/admin/api/rules/export-migrations` (handlers/admin_rules.go) — admin-gated, streams a generated SQL artifact. Same shape as what we want for the Excel exports. Re-use the gating helper.
+
+**No Go xlsx library on `go.mod` today.** This design picks **`github.com/xuri/excelize/v2`** in §3.
+
+---
+
+## 1. Why this exists
+
+Two motivations, both load-bearing:
+
+1. **Safety / backup.** A workbook on disk is a portable artifact independent of the running app. If paliad.de is down, a partner needs the matter file. If the Dokploy compose corrupts, IT needs a recent dump. If a deadline gets accidentally deleted, we want a recoverable snapshot.
+
+2. **No lock-in.** A team or an entire org choosing to leave paliad must be able to walk away with their entire dataset in a format anyone can open. We promise this in writing as a trust signal — exactly because the alternative (silently locking customers in) is what we built paliad to *not* be.
+
+The export is therefore not a "nice analytics feature" — it is **a contractual guarantee that the data is yours**. That framing shapes the design: completeness > convenience, portability > polish, every export auditable.
+
+---
+
+## 2. Scope definitions (precise)
+
+Three scopes. The boundary is **what the caller is allowed to see**, joined with **what makes the artifact interpretable standalone**.
+
+### 2.1 `org` scope
+
+**Caller:** `global_role='global_admin'` only. There is no firm-admin role distinct from global_admin in paliad today (see §4).
+
+**Content:** literally everything in the `paliad` schema that is user content or reference data the workbook needs to be readable. Specifically:
+
+| sheet                  | source table(s)                                                   | notes |
+|------------------------|-------------------------------------------------------------------|-------|
+| `projects`             | `paliad.projects` (all rows)                                      | Full project tree including soft-deleted (status='deleted' / 'closed' if any). |
+| `project_teams`        | `paliad.project_teams`                                            | profession + responsibility (post-t-148). |
+| `project_partner_units`| `paliad.project_partner_units`                                    | Derivation grants. |
+| `deadlines`            | `paliad.deadlines`                                                | Including completed, cancelled. |
+| `appointments`         | `paliad.appointments`                                             | Including completed. |
+| `parties`              | `paliad.parties`                                                  | All client / opposing-party data. |
+| `notes`                | `paliad.notes`                                                    | All four polymorphic targets resolved into the `target_kind`/`target_id` columns. |
+| `documents`            | `paliad.documents` metadata (file_path, file_size, mime_type, ai_extracted) | Binaries excluded (open Q1). |
+| `audit_events`         | `paliad.project_events`                                           | Full audit trail per project. |
+| `approval_requests`    | `paliad.approval_requests`                                        | Including completed / rejected, with `requester_kind` + `agent_turn_id`. |
+| `approval_policies`    | `paliad.approval_policies`                                        | Both project-scoped and partner-unit-defaults. |
+| `policy_audit_log`     | `paliad.policy_audit_log`                                         | Source #5 of the audit union. |
+| `partner_units`        | `paliad.partner_units`                                            | Org chart. |
+| `partner_unit_members` | `paliad.partner_unit_members`                                     | Including unit_role. |
+| `partner_unit_events`  | `paliad.partner_unit_events`                                      | Org-chart audit. |
+| `checklist_instances`  | `paliad.checklist_instances`                                      | Per-project completion state. |
+| `invitations`          | `paliad.invitations` (status, role, expires_at)                   | Without raw tokens (open Q7). |
+| `users`                | `paliad.users` (id, email, display_name, office, profession, …)   | Excludes `email_preferences` jsonb only if it carries channel secrets — none do today, but checked at export time. |
+| `user_views`           | `paliad.user_views`                                               | Saved filters / custom layouts. |
+| `user_card_layouts`    | `paliad.user_card_layouts`                                        | Project-card layouts. |
+| `user_pinned_projects` | `paliad.user_pinned_projects`                                     | Per-user pins. |
+| `user_caldav_config`   | `paliad.user_caldav_config` **without** the ciphertext column     | URL + calendar IDs + last_sync; passwords NEVER exported. |
+| `reminder_log`         | `paliad.reminder_log`                                             | Outbound digest history. |
+| `caldav_sync_log`      | `paliad.caldav_sync_log`                                          | Per-user sync runs. |
+| `paliadin_turns`       | `paliad.paliadin_turns`                                           | **Excluded by default** in org export (privacy — see §6) — admins opt in per Q5. |
+| `email_broadcasts`     | `paliad.email_broadcasts`                                         | Outbound broadcast history. |
+| `email_templates` + `_versions` | both                                                     | Custom firm templates. |
+| **reference (read-only):** | `proceeding_types`, `event_types`, `event_categories`, `deadline_rules`, `deadline_concepts`, `deadline_concept_event_types`, `deadline_event_types`, `event_category_concepts`, `trigger_events`, `holidays`, `courts`, `countries` | One sheet per table, prefixed `ref__`. Embedded so the workbook is interpretable without paliad context. |
+| **deferred audit (admin opt-in):** | `deadline_rule_audit`, `policy_audit_log`, `partner_unit_events`, `caldav_sync_log`, `paliadin_turns` | Behaviour per Q5/Q6. |
+
+**Excluded unconditionally:**
+- `auth.*` (Supabase Auth schema — not ours; the user can request their auth record from Supabase directly).
+- `paliad_schema_migrations` (operational, no business meaning).
+- `*_pre_NNN` shadow / pre-migration backup tables (rows are duplicates; the live table is canonical).
+- Any future `*_secret` / `*_token` columns (see §6 deny-list mechanism).
+
+**Edge cases:**
+- **Soft-deleted rows:** paliad currently has no soft-delete columns (`deleted_at` etc.). When that lands, the org export includes them by default with a `deleted_at` column populated. Until then, this is a no-op.
+- **Archived projects:** `projects.status` can be `'closed'` or future `'archived'` — export includes them (the whole point of backup is recoverability of closed matters).
+- **Counterclaims:** `projects.counterclaim_of` is a self-FK. Export carries the column as-is; the relationship is reconstructable via the `id` column.
+
+### 2.2 `project` scope
+
+**Caller:** any team member of the project who passes the §4 profession-tier gate.
+
+**Content:** one project + **all descendants** along the ltree path. The descendant walk is `WHERE path <@ root.path` (subtree-inclusive of root). Every entity gets filtered through `WHERE project_id IN (subtree_ids)`.
+
+Per-sheet inclusion:
+
+- `projects` (root + descendants, one row each)
+- `project_teams` (membership for those projects)
+- `project_partner_units` (derivation attachments)
+- `deadlines`, `appointments`, `parties`, `notes`, `documents` (metadata), `audit_events`, `approval_requests`, `checklist_instances` — all scoped to subtree
+- **users sheet — restricted columns:** only `id, email, display_name, office, profession` for users referenced by any FK in the export (created_by, assigned, etc.). Don't dump all 47 users when you only need 4. (Avoids accidental org-chart leak in a project-scope export shared externally.)
+- **reference data:** `ref__proceeding_types`, `ref__event_types`, `ref__deadline_rules`, `ref__deadline_concepts`, `ref__courts`, `ref__countries`, `ref__holidays`. Same as org but a smaller universe is acceptable too — the v1 ships the full reference tables for simplicity (every row count is ≤ 300; size is moot).
+- **Cross-project references** (e.g., a party referenced by a project outside the subtree): out of scope by the predicate. The export carries the foreign UUID so a re-import or merge could re-link, but the foreign row itself is not in the workbook. Edge case is rare — `counterclaim_of` is the only known cross-project pointer today.
+
+**Edge cases:**
+- **Partner-unit data:** `partner_units` is org-wide; project export carries only the unit ids attached via `project_partner_units`. The unit name + membership are loaded into the workbook on `partner_units` and `partner_unit_members` sheets (filtered to the attached units only).
+- **Policies:** `approval_policies` rows include both project-scoped (the project + ancestors) **and** partner-unit-defaults attached to this project. Same MAX-of-sources logic as runtime.
+- **Audit:** `project_events` for the subtree + (admin opt-in only) `deadline_rule_audit` rows whose rule was used by any deadline in the subtree. Default off — these are firm-wide curation logs and don't belong in a per-project handoff.
+
+### 2.3 `personal` scope
+
+**Semantics:** "everything I can see right now in paliad, framed as my data."
+
+That definition resolves the ambiguity in the brief: personal scope is **not** "rows where I am `created_by`" — that misses everything I see by being on a team. It is **the RLS-visible projection of the schema for caller=me**, plus a handful of explicitly-personal sidecars (caldav config, my pins, my views).
+
+Per-sheet inclusion:
+
+| sheet | rows |
+|---|---|
+| `projects` | `WHERE paliad.can_see_project(id)` for the caller. |
+| `project_teams` | Rows where `user_id = me` OR the row's project is in my visible set. |
+| `deadlines` | Same project-visibility filter. |
+| `appointments` | Same. |
+| `parties`, `notes`, `documents` metadata, `audit_events`, `checklist_instances` | Same. |
+| `approval_requests` | Rows where `requested_by = me` OR `decided_by = me` OR project ∈ visible set. |
+| `me` (single-row sheet) | Caller's `users` row (id, email, display_name, office, profession, reminder_*, lang, escalation_contact_id). |
+| `my_caldav_config` | The caller's `user_caldav_config` row **without** the encrypted password column — sync URL, calendar IDs, last_sync_at. |
+| `my_views` | Caller's `user_views` rows. |
+| `my_pinned_projects` | Caller's `user_pinned_projects` rows. |
+| `my_card_layouts` | Caller's `user_card_layouts` rows. |
+| `my_paliadin_turns` | Caller's `paliadin_turns` rows (currently restricted to `PaliadinOwnerEmail` = m, so this sheet is empty for everyone else). Sensitive: AI prompts + responses. **Default on for personal scope** — it's literally the caller's data. |
+| `users_referenced` | Restricted: id + display_name + email for users referenced as FKs in the export. |
+| reference tables | Same set as project scope. |
+
+**Edge cases:**
+- **Caller leaves a team:** the export reflects the moment-in-time visibility. A `generated_at` timestamp in the workbook header (`__meta` sheet) anchors this.
+- **Caller is a global_admin:** their personal export is the entire org (because their visible set = all projects). This is by design — but we surface a banner ("Sie sehen alles, weil Sie global_admin sind. Ein org-scope-Export wäre identisch.") so they don't get confused thinking the personal-scope endpoint is broken.
+- **Caller has no team memberships:** export contains the empty workbook + the `me` row + their caldav config + views/pins. Still useful — they can save their preferences.
+
+### 2.4 Common columns across all scopes
+
+Every export workbook contains a `__meta` sheet:
+
+```
+schema_version:     1
+firm_name:          HLC                       # from internal/branding.Name
+scope:              org | project | personal
+scope_root_id:      uuid or NULL              # the project id for project-scope, NULL otherwise
+generated_at:       2026-05-19T14:23:00Z
+generated_by_user:  <uuid> <email>            # the caller
+generated_by_label: archimedes / m / ...      # display_name
+row_counts:         JSON {"projects": 11, ...}
+paliad_version:     <git sha at server build>
+notes:              free-form, e.g., "documents binaries excluded by design"
+```
+
+This pins provenance + reproducibility + diffability.
+
+---
+
+## 3. Format choices
+
+### 3.1 xlsx as the primary format
+
+**Library: `github.com/xuri/excelize/v2`.** De-facto Go xlsx library, pure-Go (no cgo, no external libreoffice), MIT, streaming writer for large workbooks, broad format-feature support (number formats, freeze panes, hyperlinks, sheet hide). The streaming writer (`NewStreamWriter`) is what we use — it writes rows one at a time without holding the whole sheet in memory. At 11-projects scale this is unnecessary; at 11k-projects scale it's essential, so we set the pattern now.
+
+**Why not the alternatives:**
+- `tealeg/xlsx` — older, unmaintained, no streaming.
+- `qax-os/excelize` — same project as xuri/excelize (the github org renamed); xuri is the upstream.
+- `360EntSecGroup-Skylar/excelize` — defunct fork.
+
+**Workbook structure:** one **sheet per entity type**, *never* a mixed-type sheet with conditional columns. Reasons:
+- Excel users sort + filter by column; a column that means "deadline due_date" on row 4 and "appointment start_at" on row 12 is unusable.
+- The "self-describing" promise (no-lock-in) is satisfied by a workbook where every sheet is a flat table with stable column headers, not by a polymorphic blob.
+- Cross-sheet relationships are represented by **UUIDs in foreign-key columns** + a `__lookup` sheet pairing UUID → display label (project title, user email) for the workbook's lifetime. This makes the workbook self-joining in Power Query / pivot tables.
+
+**Sheet conventions:**
+- Sheet names use `snake_case` matching SQL table names (`deadlines`, not `Fristen`). Reference tables prefixed `ref__`. Personal sidecars prefixed `my_`. Meta sheet `__meta`. The `__lookup` sheet sits last.
+- Row 1 = column headers; frozen.
+- Column 1 of every entity sheet is `id` (uuid).
+- Dates: ISO 8601 UTC for timestamptz; `YYYY-MM-DD` for `date`. Always as Excel strings (not Excel date types) — Excel-date interpretation differs by locale (DE: `Tag.Monat.Jahr`, EN: `Month/Day/Year`) and silently corrupts on round-trip. A pinned ISO string is unambiguous and re-importable. Open Q4 covers whether to *also* mirror to native Excel dates for human convenience.
+- Booleans: literal `TRUE` / `FALSE` strings, same reason.
+- `jsonb` columns: serialised as compact JSON one-liners in the cell. Cell type = string. Power Query can `Json.Document` them.
+- Arrays (e.g., `additional_offices text[]`): semicolon-joined string. Excel's CSV-array convention is the comma but our office codes use commas; semicolon avoids the collision.
+- `text[uuid[]]` paths (the projects.path ltree): exported as the canonical dotted-uuid string.
+
+**Encoding:** UTF-8 always. Excelize handles the xlsx packaging which is unicode-native. Umlaute round-trip correctly (verified pattern with tesla's CSV export in t-paliad-177).
+
+### 3.2 CSV + JSON siblings
+
+Per the no-lock-in promise, **xlsx is not enough on its own** — Excel is a proprietary format owned by Microsoft, and a workbook is opaque without a tool that understands it. For genuine portability we also produce:
+
+- **CSV:** one file per entity sheet (no reference sheets — those go as JSON), UTF-8 with BOM (`\xEF\xBB\xBF`) for Excel-DE compat, RFC 4180 quoting, headers row 1. Identical column shape to the xlsx sheet.
+- **JSON:** a single `paliad-export.json` per scope, top-level `{"meta": {...}, "tables": {"projects": [...], "deadlines": [...], ...}}`. Easiest for programmatic re-ingest. Reference tables included.
+
+**Delivery shape:** all three formats live inside one `.zip` per export:
+```
+paliad-export-<scope>-<timestamp>.zip
+├── README.txt              # human-readable: what this is, how to read it
+├── paliad-export.xlsx      # canonical workbook
+├── paliad-export.json      # JSON twin (machine-readable)
+├── csv/
+│   ├── projects.csv
+│   ├── deadlines.csv
+│   ├── ...
+│   └── ref/
+│       ├── proceeding_types.csv
+│       └── ...
+└── __meta.json             # standalone meta (same content as __meta sheet)
+```
+
+The `.zip` is the artifact users download. Default content is "all three" — there's no UI knob to pick (open Q1: should there be? Inventor pick = no, zip-only).
+
+**Filename convention:**
+```
+paliad-export-{scope}-{timestamp}.zip
+  scope     = org | project-<root-short> | personal
+  timestamp = YYYY-MM-DDTHHMMZ           # UTC, no colons (Windows-safe)
+```
+Examples: `paliad-export-org-2026-05-19T1423Z.zip`, `paliad-export-project-Siemens-AG-2026-05-19T1423Z.zip`, `paliad-export-personal-2026-05-19T1423Z.zip`. The project-short is `slugify(root.title)` capped 40 chars.
+
+**Determinism (Q6 question).** Two exports of the same scope at the same row state must produce **byte-identical** workbooks. xlsx is internally a zip of XML — file order in the zip is significant; excelize's default zip writer is non-deterministic. We can make this deterministic by sorting the file list before writing. JSON: keys sorted alphabetically. CSV: rows ordered by `id ASC` (stable). The only inherently non-deterministic field is `generated_at`; we externalise it to the filename and the `__meta` sheet, but the rest of the workbook is byte-stable. **Inventor pick: yes, deterministic.** Lets users diff exports and prove "nothing changed between Tuesday and Thursday."
+
+### 3.3 Future-proofing — schema_version
+
+`__meta.schema_version = 1`. When we add columns (e.g., projects.archived_at lands), we bump to 2 and note the additions in a `docs/export-schema-changelog.md`. Importers (us in the future, or a re-importer at a different firm) read schema_version first.
+
+---
+
+## 4. Authorization model
+
+**Tightly mirrored to existing paliad role surfaces.** No new roles introduced.
+
+| Scope | Required auth |
+|---|---|
+| `org` | `paliad.users.global_role = 'global_admin'`. Same gate as `/admin/*` pages (`auth.RequireAdminFunc` in `handlers.go:417`). |
+| `project` | Caller must (a) pass `can_see_project(root_id)`, AND (b) have effective project profession ≥ **associate** on the root. The associate floor mirrors the conservative seed in `approval_policies` (t-154); paralegals + PA can see data but not extract it. m-tunable per Q2. |
+| `personal` | Any authenticated user. No additional gate. |
+
+**Profession ladder check** for project scope uses the existing `DerivationService.EffectiveProjectRole` (t-139 phase 2) — direct membership > ancestor > derived via partner-unit. Same surface that gates approvals; same surface gates extracts.
+
+**Audit row written on every export run.** A new event_type into `paliad.project_events` for project-scope (so it appears on the project's Verlauf), `partner_unit_events` for org-scope (so it appears on the partner-unit audit log of the firm-admin's home unit), and `policy_audit_log` is too narrow — we likely want a **new** audit table for org-wide actions, OR we widen `project_events` to allow `project_id = NULL` org-wide rows. **Inventor pick: new table `paliad.system_audit_log`** — clean separation, integrates into the existing 5-source AuditService union as source #6. Migration 101 adds it.
+
+`system_audit_log` columns:
+```sql
+id          uuid PRIMARY KEY DEFAULT gen_random_uuid(),
+event_type  text NOT NULL,             -- 'data_export'
+actor_id    uuid REFERENCES paliad.users(id),
+actor_email text NOT NULL,             -- captured at write time, survives user deletion
+scope       text NOT NULL,             -- 'org' | 'project' | 'personal'
+scope_root  uuid,                      -- project_id for project scope, NULL otherwise
+metadata    jsonb NOT NULL DEFAULT '{}'::jsonb,  -- {"formats":["xlsx","json","csv"], "row_counts":{...}, "file_size_bytes":12345, "filename":"..."}
+created_at  timestamptz NOT NULL DEFAULT now()
+```
+
+The audit row is written **before** the export runs (so failed exports are still recorded) and **updated** with `file_size_bytes` + final `row_counts` on success. Failure case: separate `event_type='data_export_failed'` row with the error string in metadata. **The audit chain is the trust signal** — m sees who exfiltrated what, when, and how much.
+
+**Headers on the response:**
+- `Content-Disposition: attachment; filename="paliad-export-<scope>-<ts>.zip"`
+- `X-Paliad-Export-Audit-Id: <system_audit_log.id>` — so an automated client can reference the audit row.
+
+---
+
+## 5. Trigger model
+
+Three trigger surfaces:
+
+### 5.1 On-demand button
+
+- **Personal:** `/settings` → "Daten exportieren" card → button. POST `/api/me/export` → 200 with `Content-Type: application/zip`. Synchronous.
+- **Project:** `/projects/{id}` → settings/cog menu → "Daten dieses Projekts exportieren". POST `/api/projects/{id}/export` → 200 zip. Synchronous. Includes a "Inkl. Unterprojekte" toggle hint (it's always subtree-inclusive — the toggle is purely informational, no off switch).
+- **Org:** `/admin/data-export` (new page, card on `/admin`) → "Org-Export erstellen" button. POST `/api/admin/export/org` → **async** by default (see §6.1). Returns 202 + `job_id`. UI polls `/api/admin/export/org/jobs/{id}` for status.
+
+**Why org is async even at today's scale:** the principle isn't "is it slow now" — it's "the trigger model should not change as the firm grows." If the partner with the firm-wide button gets a different UX from the associate with the project button, we'd retrofit later. Sync at 600 rows works fine; the wrapping is `goroutine + channel + Server-Sent Events for live progress`, no new infra needed. See §6.1.
+
+### 5.2 Scheduled exports
+
+**Inventor pick — defer to slice 4.** Out of v1 scope. The reasoning: scheduling sits on storage + delivery + retention, all of which are *also* deferred to slice 3+. Building the scheduler before we know how + where the artifact lives is premature.
+
+When it lands (slice 4), the model is:
+- A new `paliad.scheduled_exports` table: `(id, scope, scope_root_id, owner_user_id, cadence, last_run_at, next_run_at, delivery)` where `delivery` is `{kind: 'email-link' | 'caldav-style-webdav', config: jsonb}`.
+- A daily cron (mai cron or a `time.Ticker` goroutine) checks `next_run_at < now()`, runs the export, posts the link via the configured delivery channel.
+- Cadence: weekly + monthly + on-status-change (e.g., "export when project closes" — a webhook from `projects.status` triggers).
+
+For now (slice 1-2), users can right-click the on-demand button and bookmark the URL — that's the **only** scheduled-export-y thing we offer, and it's intentional: get the manual flow rock-solid before adding cadence.
+
+### 5.3 API endpoint
+
+Same endpoints as §5.1, callable directly with the standard cookie / bearer auth. We don't add a separate "API key" surface in v1 — paliad doesn't have personal access tokens today. If a user wants to script their personal export weekly, they can use cookie auth from `m/paliad` automation; that's enough until power-user volume justifies a real PAT surface.
+
+For machine ergonomics: the `/api/...export` endpoints accept `?format=zip` (default), `?format=xlsx`, `?format=json`, `?format=csv-zip` query params. Only `zip` is documented; the others are internal but reachable for automation.
+
+---
+
+## 6. Storage + delivery
+
+### 6.1 Synchronous vs async — per-scope picks
+
+**Personal, project:** **Synchronous, streamed.** The handler holds the HTTP connection open, writes the zip directly to `http.ResponseWriter`. For 1MB-class exports (today's reality at every scale up to thousands of rows per entity) this is the right call — no persistence, nothing to garbage-collect, nothing leaking onto disk. Excelize's `NewStreamWriter` flushes rows as they're written so RAM stays bounded.
+
+**Org:** **Asynchronous, in-process queue, on-disk artifact.**
+- Submit (`POST /api/admin/export/org`) writes a `system_audit_log` row with status `pending` and dispatches a goroutine.
+- The goroutine writes the zip to `/var/lib/paliad/exports/{audit_id}.zip` (configurable via `PALIAD_EXPORT_DIR`; on Dokploy this is a mounted volume).
+- The goroutine updates the audit row's metadata with progress, then status `done` with `file_size_bytes` on success.
+- The user polls `GET /api/admin/export/org/jobs/{audit_id}` (SSE or simple JSON) — when ready, a download link `GET /api/admin/export/org/jobs/{audit_id}/download` serves the file.
+- Download deletes the file by default (one-shot link), or keeps it per Q3.
+
+**Why not S3-style bucket?** Paliad already has a `documents` table that *will* need a binary store, eventually. Coupling export storage to that future store is right — but the future store doesn't exist yet, and we don't want to provision MinIO on mlake purely for exports. **Inventor pick: local disk in `PALIAD_EXPORT_DIR`** until/unless we provision a real object store; at that point the export storage moves there transparently.
+
+### 6.2 Retention (Q3)
+
+**Inventor pick: 7 days, then auto-delete.** Justifications:
+1. Exports contain sensitive client data — minimising the retention window minimises blast radius if the Dokploy host is compromised.
+2. 7 days covers a holiday-week round-trip ("I exported Friday, want to look at it Monday next week, missed the day-1 link").
+3. The audit row in `system_audit_log` persists forever — you can always tell that an export happened, even after the artifact is deleted.
+
+A cleanup goroutine runs daily, lists `system_audit_log` rows older than 7 days with non-NULL `file_path`, deletes the file, sets `metadata.deleted_at`. Audit row stays.
+
+The `PALIAD_EXPORT_RETENTION_DAYS` env var is the knob (default `7`). m-tunable per firm.
+
+### 6.3 PII / GDPR
+
+This is where the design gets serious.
+
+**At-rest encryption.** Files in `PALIAD_EXPORT_DIR` are plaintext on the Dokploy volume. The volume itself is encrypted at the host layer (Hostinger VPS disk encryption). We **do not** layer additional file-level encryption on the artifact — that would require a per-user key, key escrow, key rotation, all of which is over-engineered for a 7-day-retention exfil where the link is single-use behind cookie auth. The disk encryption + 7-day TTL + audit log is the trust boundary.
+
+**In-transit encryption.** TLS via Dokploy + Traefik — paliad.de is Let's Encrypt-served. No raw HTTP path.
+
+**Download authentication.** The download link `/api/admin/export/org/jobs/{audit_id}/download` requires the same cookie auth as the submit. No public signed URLs in v1 (deferred per Q8). When we add scheduled exports + email delivery (slice 4), we'll need expiring signed URLs — that design is captured then, not now.
+
+**Data-subject requests.** A user invoking `/api/me/export` is, in effect, performing a self-serve GDPR Art. 15 data-portability request. Audit row records the request. If the firm receives a *third-party* DSR ("export the data my client Mr. Müller asked for"), a global_admin can run a project-scope export filtered to projects involving that client; this is a manual workflow we don't automate in v1 (open Q9).
+
+**Right-to-erasure.** Out of scope. Erasure is a write path; export is read-only. They share no code.
+
+**External sharing of export files.** A user who downloads an export and emails it to an external party has done so on their own authority and outside paliad's protection. We don't watermark the file (debated and rejected: watermarking introduces non-determinism, breaks diffability, and gives false security — anyone reading the zip can strip metadata). What we *do* document in the embedded `README.txt`:
+
+> Diese Datei enthält möglicherweise vertrauliche Mandantsdaten. Sie wurde
+> erzeugt am {generated_at} durch {actor_email} aus Paliad ({firm_name}).
+> Die Weitergabe an Dritte erfolgt in eigener Verantwortung des Empfängers.
+
+A simple "you broke the seal" notice is what we offer. It's a contract, not a control.
+
+**PII column deny-list.** Hard-coded in `internal/services/export_service.go`:
+- `paliad.users.password_hash` — doesn't exist, but the deny-list is the safety net if it ever does.
+- `paliad.user_caldav_config.encrypted_password` — explicit drop.
+- Any column whose name matches `(?i)secret|token|password|api[_-]?key|private[_-]?key` — caught at column-discovery time, errors loudly into `system_audit_log.metadata.warnings`.
+- `paliadin_turns.assistant_response` — present in personal export of caller's own data; **off** in org export by default (m's call per Q5).
+
+### 6.4 GDPR-completeness note
+
+The export of one user's personal scope is **a partial Art. 15 disclosure** — it contains what's *in paliad's* control. Other systems (Supabase Auth row, mlake logs, CalDAV provider) are out of paliad's scope and not in the export. The embedded README states this explicitly so the user knows the workbook is the paliad-side answer, not a complete personal-data dump from "the firm."
+
+---
+
+## 7. Slice plan
+
+Tracer-bullet shipping. Each slice is independently shippable and reviewable. The first slice closes the no-lock-in promise for the smallest, lowest-risk scope; later slices widen.
+
+### Slice 1 — personal export, synchronous, xlsx + JSON
+
+- Adds `excelize/v2` to `go.mod`.
+- New `internal/services/export_service.go` with the column-discovery + writer plumbing for xlsx + JSON.
+- New `internal/handlers/export.go` with `POST /api/me/export`.
+- New `/settings` UI: "Daten exportieren" card + button.
+- Migration 101: `paliad.system_audit_log` + `AuditService.ListEntries` 6th union branch.
+- i18n keys (`settings.export.*`, `__meta.*`).
+- Tests: `export_service_test.go` covers xlsx structure (one row each kind), JSON shape, PII deny-list.
+
+Ships the no-lock-in promise for every user immediately. ~600-800 LoC + ~25 i18n keys.
+
+### Slice 2 — project export, synchronous, xlsx + JSON + CSV-zip
+
+- Generalises the export_service to scope-aware queries (the visibility predicate gets injected per scope).
+- New `POST /api/projects/{id}/export`, gated by §4.
+- Adds CSV writer alongside xlsx + JSON; bundles all three into `.zip`.
+- Project-detail UI gets the export menu entry.
+- README.txt template embedded.
+- Tests + e2e (Playwright) on the project page button.
+
+~800-1000 LoC. The CSV path generalises the xlsx column-discovery so the marginal cost is low. After this slice, two of three scopes are shipped and synchronous serves both.
+
+### Slice 3 — org export, async with job tracking
+
+- Adds the goroutine + on-disk artifact path + `PALIAD_EXPORT_DIR` env.
+- `POST /api/admin/export/org` + job status + download endpoints.
+- New `/admin/data-export` page (card on `/admin/`).
+- Cleanup goroutine (daily, deletes artifacts > `PALIAD_EXPORT_RETENTION_DAYS`).
+- Refactor: extract the now-common "writeExportToWriter" core from the synchronous path so async re-uses it.
+
+~600-800 LoC. After this slice, all three scopes ship + audit trail is complete.
+
+### Slice 4 — scheduled exports (deferred, not v1)
+
+Designed in §5.2; building deferred until at least 2 firms ask. The contract surface is the `scheduled_exports` table + cadence + delivery channel.
+
+### Slice 5 — API ergonomics (deferred)
+
+Personal Access Tokens (the "I want to cron my own export" surface). Until there's a customer, we don't build the PAT issuer + revocation + audit.
+
+### Slice 6 — GDPR DSR helpers (deferred)
+
+A `/admin/data-subject-request` workflow to assemble a per-natural-person export across projects. Built on Slice 1-3 primitives; not blocked by them.
+
+### Slice 7 — document binary inclusion (deferred until documents have rows)
+
+When the `documents` table starts holding real files, the export adds a `documents/` subdir in the zip with the actual files, keyed by filename = `{document_id}.{ext}`. The metadata sheet links by id. Adds ~150 LoC + an env var for the file backend.
+
+**Critical-path slices for v1: 1 + 2 + 3.** Everything after is layered, optional, m-prioritised when there's a real customer pull.
+
+---
+
+## 8. Trade-offs flagged
+
+1. **xlsx-first means we own the `excelize` dependency forever.** Mitigation: excelize is the canonical Go xlsx — replacing it would be a multi-thousand-LoC migration, but the upstream is healthy (MIT, 17k+ stars, monthly releases). Acceptable lock-in.
+
+2. **Determinism (sorted file order, sorted JSON keys, row-id-ordered CSV) is implementation discipline, not a library default.** Test that breaks if any future change introduces non-determinism is essential (helps reviewers + prevents regressions).
+
+3. **Synchronous personal + project means a runaway export can block a request goroutine for seconds.** At today's data shape this is sub-second. Watchdog: a 30s context deadline on synchronous exports; over that, return 503 with "export too large — contact admin for async." Triggers slice 3 → slice 4 of the user's mental model.
+
+4. **Per-scope endpoints triplicate similar code paths.** Mitigated by the shared `ExportSpec` struct + scope-aware predicate injection. Read carefully in code review — this is the place subtle scope leaks creep in.
+
+5. **JSON twin is genuinely redundant for human users.** It's there for the no-lock-in promise (a Python script can re-ingest without Excel). The cost is one extra file in the zip + one extra serialisation pass. Acceptable.
+
+6. **No diff tooling — yet.** Determinism enables `diff -r` between two extracted zips, but no in-app surface. Slice 4+ may layer "show me what changed between Monday's and Friday's export" once exports are scheduled and stored.
+
+7. **`paliadin_turns` privacy default.** Currently restricted to `PaliadinOwnerEmail` so the table is empty for every other user. Personal export carries them by default ("your AI history"); org export by default does NOT (admin opt-in via `?include=paliadin_turns`). When Paliadin opens past owner-only (post-API cutover), revisit.
+
+8. **Reference-data inclusion bloats every export.** 254 deadline_rules + 102 trigger_events + 56 concepts + … = ~1000 reference rows in every workbook regardless of scope. At zip-compressed sizes this is < 100KB and worth the standalone-interpretability. If the workbook gets too large later, ship reference data as a separate "paliad-reference-snapshot.zip" once + reference it from each export's README.
+
+9. **Org export volume at firm-scale.** A 10k-project firm has ~50k deadlines and ~200k audit events. Even at 200 bytes/row average that's < 100MB — comfortable for the async path with 4GB Dokploy RAM. Threshold concerns kick in at 1M+ rows, which is firm-class-of-100-attorneys territory. Designed for, not blocked on.
+
+10. **Audit-log explosion.** A nightly cron + 47 users self-exporting = 50 audit rows / day. At a year that's 18k rows. Still trivial. No retention on the audit chain (the artifact retention does NOT touch audit-log retention — the audit chain is the trust signal, see §4).
+
+---
+
+## 9. Recommended implementer
+
+**Single PR, layered slices 1 → 2 → 3 as separate commits.** No DB-heavy migrations; the only schema add is `system_audit_log` (one table, one trigger if any). The hard work is in the writer abstraction.
+
+- **Slice 1:** pattern-fluent Sonnet coder. ~600-800 LoC, mostly bookkeeping. Tests pin the shape.
+- **Slice 2:** same hands as slice 1 (continuity matters here — the writer abstraction is set in slice 1 and the project scope generalises it).
+- **Slice 3:** same hands again. The async path is its own subsystem but the writer is unchanged.
+
+**NOT cronus** per memory directive 2026-05-06 (retired from paliad).
+**NOT m** — this is a coder task end-to-end.
+
+---
+
+## 10. Inventor → coder transition (GATED per project CLAUDE.md)
+
+Per `.claude/CLAUDE.md`: design phase ends here. No code touches the tree from inventor. Head's `mai-head` skill gates the coder shift after m's go on §11 open questions.
+
+When approved, the coder shift opens on `mai/<coder-name>/data-export-slice-1` (fresh branch off main, NOT off the design branch — design doc commit is the only artifact this branch carries forward via cherry-pick).
+
+---
+
+## 11. Open questions for m
+
+The brief lists 8 candidate questions. After live-state verification I've collapsed + sharpened to 9, each with an inventor pick + reasoning. Will be asked sequentially via AskUserQuestion (paliad dogma — no `## §X.Y` markdown dump on m, per t-paliad-154 lesson).
+
+### Q1 — Bundle xlsx + CSV + JSON in one zip, or let user pick format?
+
+**Inventor pick: bundle all three in one zip, no UI knob.**
+
+Reasoning: the no-lock-in promise *requires* the JSON twin (Excel-independent re-ingest); the xlsx is the human-readable default; CSV is the universal lingua franca. Picking only one breaks the promise for some user. Bundle size at today's scale is < 1MB; even at firm-scale it's well under the email-attachment limit. The cost of a checkbox UI is more than the cost of three extra files.
+
+Alternative: offer `?format=xlsx-only|json-only|csv-only` query params for the API surface, default to bundle. Documented in README only. We do this in v1 anyway since multi-format is what generates the zip in the first place.
+
+### Q2 — Project-scope profession floor: associate (inventor pick) or member?
+
+**Inventor pick: associate floor.**
+
+A project export carries party names, addresses, decision-history, draft strategy notes. That's "I can write a paper for the partner" data, not "I can see the deadline calendar" data. Member is the bare-visibility tier (you got added to the team). Export is exfiltration — needs the next tier up.
+
+Alternative: gate by `responsibility ∈ {lead, member}` (no profession floor, only the project-team responsibility check). Cleaner architecturally — separates the "can see" axis from the "can extract" axis using the same fields. Less restrictive in practice.
+
+Worth choosing now because the gate text in the audit row mentions the tier.
+
+### Q3 — Org-export artifact retention: 7 days (pick) or 30 / 90?
+
+**Inventor pick: 7 days.**
+
+Default conservative. m-tunable per firm via env var.
+
+### Q4 — Excel dates: ISO strings only (pick) or also a mirrored native-Excel-date column?
+
+**Inventor pick: ISO strings only.**
+
+Native Excel dates are locale-poisoned (DE vs EN epoch interpretation flips, round-trip corruption when re-saved). ISO is the universal answer. Power users who want a sortable native-date column can derive it once in their workbook — but the canonical export stays unambiguous.
+
+### Q5 — `paliadin_turns` in org export: opt-in only (pick), or include by default?
+
+**Inventor pick: opt-in via `?include=paliadin_turns` query.**
+
+Today it's m-only data (`PaliadinOwnerEmail` gate), so the privacy stakes are low — but the *moment* Paliadin opens beyond owner-only, the AI conversation history per user is the most sensitive personal data we carry. Setting the off-by-default precedent now means we don't accidentally start dumping it later.
+
+### Q6 — Deterministic byte-for-byte exports: yes (pick) or accept timestamp drift in zip metadata?
+
+**Inventor pick: yes, deterministic.**
+
+Lets users diff exports across time. Cost: ~50 lines of `sort.Strings` + a custom zip writer with stable ordering. Worth it.
+
+### Q7 — Invitation tokens in org export: drop them entirely (pick) or include as hash?
+
+**Inventor pick: drop entirely.**
+
+Tokens grant signup access. Including them in a backup creates a vulnerability surface — an exfiltrated backup could be used to sign up as someone-else with their pending invite. Hashing doesn't help because the hash is what the URL contains. The invitation **row** (recipient, role, expiry, sent_at) is in the export; the token is not. If you need to re-issue, you do so from paliad's invite UI.
+
+### Q8 — Public signed-URL downloads (for scheduled/email delivery): yes / not in v1 (pick)?
+
+**Inventor pick: not in v1.**
+
+Defer to slice 4. v1's download is cookie-authenticated only. Signed URLs are useful when the recipient is asynchronously notified (email link), which is the scheduled-export model — and that whole subsystem ships later.
+
+### Q9 — GDPR Art. 15 DSR helper UI: not in v1 (pick)?
+
+**Inventor pick: not in v1.**
+
+A global_admin can already assemble a DSR manually using project-scope exports filtered by client. v1 ships the primitives; v2 ships the workflow.
+
+### Closing question for m: implementer
+
+> Recommend pattern-fluent Sonnet for all three slices, same hands across (continuity matters for the writer abstraction). Specific name = your call.
+
+---
+
+## 12. m's decisions (addendum, 2026-05-19)
+
+m walked the §11 questions live via AskUserQuestion. Results below — these supersede the inventor picks where they differ.
+
+- **Q1 — Bundle format:** Bundle xlsx + JSON + CSV in one `.zip` per export. ✓ matches pick.
+- **Q2 — Project-scope floor:** **Any team member** (`responsibility ∈ {lead, member}`). ⚠ **Deviation** from associate-floor pick — m chose the looser axis-split gate. **Implementation update for §4:** project-scope auth becomes `(a) can_see_project(root_id) AND (b) caller is on project_teams for the root with responsibility ∈ {lead, member}`. The DerivationService profession check is dropped from the export gate; observers + externals + derived-only members still cannot extract. `system_audit_log.metadata` records the responsibility value the caller held at export time.
+- **Q3 — Org-export retention:** **90 days**. ⚠ **Deviation** from 7-day pick. **Implementation update for §6.2:** `PALIAD_EXPORT_RETENTION_DAYS` default flips from `7` to `90`. The cleanup goroutine still runs daily; the threshold is just longer. Audit row unaffected (still persists forever).
+- **Q4 — Date format:** ISO 8601 strings only. ✓ matches pick.
+- **Q5 — paliadin_turns in org export:** **Never include in org export.** ⚠ **Tighter** than opt-in pick. **Implementation update for §2.1 + §6.3:** the `paliadin_turns` row drops from the org-scope sheet table entirely — no `?include=paliadin_turns` query param. Personal scope still carries the caller's own paliadin_turns (it's literally their data). The hard exclusion is enforced in `export_service.go`'s scope-aware sheet registry, not just in column-discovery, so a future schema addition can't accidentally re-include it.
+- **Q6 — Deterministic exports:** Yes. ✓ matches pick. (m answered freeform "1" alongside the batching request — first option = deterministic.)
+- **Q7 — Invitation tokens:** Drop entirely. ✓ matches pick.
+- **Q8 — Signed URLs in v1:** Not in v1. ✓ matches pick.
+- **Q9 — GDPR DSR helper UI in v1:** Not in v1. ✓ matches pick.
+
+**Net effect on slice plan:** unchanged shape, three modifications:
+- Slice 2 gate logic uses `project_teams.responsibility` only (no profession lookup).
+- Slice 3 default retention is 90 days (one env-var value change).
+- Slice 1 + 3 sheet registry omits `paliadin_turns` from org scope entirely.
+
+No other slice deltas. v1 still ships slices 1+2+3.
+
+**Coder shift gating:** head still gates the implementation handoff; m's decisions here close §11 but don't auto-trigger coder work.
+
+---
+
+## 13. Adjacent / out-of-scope
+
+- **Import path** — explicitly out per brief. A round-trip "export then re-import" is appealing but is its own design (rebinding UUIDs, conflict resolution, schema_version migrations). Don't conflate.
+- **Postgres replacement** — the Excel workbook is a *backup* + *portability artifact*, not a data-model alternative. Postgres stays canonical.
+- **t-paliad-212 (leibniz, CalDAV multi-calendar):** personal export already carries the caller's caldav config (minus ciphertext). When leibniz designs multi-calendar, the personal export's `my_caldav_config` sheet becomes a list rather than a single row — handled by column-discovery automatically. No design conflict; flagged for confirmation when leibniz's design lands.
+- **t-paliad-213 (mendel, test strategy):** export service warrants pure-function tests for column discovery, deny-list, scope predicate, plus one e2e (Playwright) per scope endpoint. Slice tests pin the contract; mendel's overall strategy decides framework choice.
+
+---
+
+## 14. References
+
+- `docs/design-data-model-v2.md` — projects + mandanten + ltree path + can_see_project predicate.
+- `docs/design-approval-policy-ui-2026-05-07.md` — 5-source audit union (this design adds the 6th source).
+- `docs/design-profession-vs-project-role-2026-05-07.md` — profession ladder for the §4 project gate.
+- `internal/handlers/admin_rules.go:303` — `handleAdminExportRuleMigrations` (precedent for admin-gated export-as-download).
+- `internal/services/project_service.go:15` — visibility predicate.
+- `internal/services/derivation_service.go` — `EffectiveProjectRole` for the project gate.
+- `github.com/xuri/excelize/v2` — chosen xlsx library.
+
+---
+
+**END OF DESIGN. Status: READY FOR REVIEW.**
+
+Inventor parks until m's go/no-go on §11. No code touches the tree from this branch.

docs/design-paliad-test-strategy-2026-05-19.md

@@ -0,0 +1,582 @@
+# Design — Paliad Test Strategy (production-grade)
+
+**Author:** mendel (inventor)
+**Date:** 2026-05-19
+**Task:** t-paliad-213
+**Branch:** `mai/mendel/inventor-test-strategy`
+**Status:** DESIGN READY FOR REVIEW. No test files / Make targets / CI configs touched. Awaiting m go/no-go on §5 slice plan + §6 open questions before any coder shift.
+
+---
+
+## 0. TL;DR
+
+Paliad has accidental test discipline today: 59 `_test.go` files / 323 test functions in Go (≈45 % of services tested, ≈12 % of handlers tested) and 4 frontend test files for 90+ client modules (≈4 %). There is no committed end-to-end suite and no CI — every smoke pass is human-driven via the manual reports in `tests/`. The `mig 098` prod crash-loop, the `t-paliad-036` triple-bug after the German→English rename, and a long tail of UX regressions (deadline-done modal, calendar column drift) would all have been caught by a 10-test boot-and-click smoke pass.
+
+This design proposes a six-layer test pyramid with a concrete tool per layer (stdlib `testing` + bun's built-in `bun:test` + `playwright` for E2E — nothing third-party we don't already use). It pins three lessons paliad has paid for in commits:
+
+1. **No mocks at the service↔DB boundary.** Live-DB tests against a per-developer Postgres are the floor; in-memory mocks for `paliad.*` would have hidden every rename-after-DROP-CASCADE bug. Project preference is already in this direction (27/44 service tests are live-DB-gated); we double down rather than reverse.
+2. **Migrations must dry-run before they merge.** Every recent prod-down (mig 098, mig 020-after-rename, mig 099 audit_reason gap) was a migration that compiled, passed `go test ./...` (which skips without `TEST_DATABASE_URL`), and broke on first apply against the real schema. A `make verify-migrations` target that does BEGIN/apply/ROLLBACK in CI fixes the entire failure mode.
+3. **Browser-shaped bugs need a browser.** The fristenrechner cascade, shape-timeline render, calendar grid, inline paliadin widget — these are JS state machines. Bun's stdlib `bun:test` covers the pure parser/codec code; Playwright covers the auth-gated DOM. Don't try to substitute one for the other.
+
+Six slices roll the strategy out as tracer-bullet PRs, each independently shippable. Slice 1 (migration dry-run harness) and Slice 4 (Playwright golden-path smoke) buy the most outage-prevention per LoC; the rest is widening proven patterns.
+
+Six open questions for m at §6. Most surface a coverage-vs-cost trade-off — the picks that need m's call before any code lands are CI infrastructure choice (Q2), per-PR run-time budget (Q1), and live-DB-vs-dockerised Postgres (Q3).
+
+---
+
+## 1. Audit — what exists today
+
+Counts taken on `mai/mendel/inventor-test-strategy` @ HEAD (2026-05-19, 100 migrations applied).
+
+### 1.1 Go test inventory
+
+| Package | Source files | Test files | Test functions | Notes |
+|---|---|---|---|---|
+| `internal/services` | 56 | 44 | ~200 | 26 live-DB-gated (`TEST_DATABASE_URL`), 18 pure-Go. 24 services have **no test file at all** — see §1.4. |
+| `internal/handlers` | 59 | 7 | ~30 | Only auth-domain check, search, audit-parse, approval-error-mapping, redirects, verfahrensablauf-redirect, chart-404 covered. **53 handlers have no test file.** |
+| `internal/auth` | small | 2 | ~10 | Session middleware + require-admin. |
+| `internal/branding` | small | 1 | small | Firm-name override. |
+| `internal/offices` | small | 1 | small | Office enum. |
+| `internal/changelog` | small | 1 | small | Pure parser. |
+| `internal/calc` | small | 1 | small | Fees / fee tables. |
+| `cmd/server` | 1 | 1 | small | `main_paliadin_backend_test.go` covers env-gate selection. |
+| **Total** | **133** | **58** | **323** | |
+
+`go test ./...` runs all 58 files. Without `TEST_DATABASE_URL` set, 27 of them silently skip their live-DB cases — the suite still passes, but coverage of mutation paths drops to near zero.
+
+### 1.2 Frontend test inventory
+
+| Path | Test files | Tested |
+|---|---|---|
+| `frontend/src/client/filter-bar/url-codec.test.ts` | 1 | FilterBar URL codec round-trip. |
+| `frontend/src/client/views/format.test.ts` | 1 | Date/time formatters (regression for t-paliad-153). |
+| `frontend/src/client/views/shape-timeline-chart.test.ts` | 1 | Chart layout pure function. |
+| `frontend/src/client/views/shape-timeline-cv.test.ts` | 1 | Continuous-view shape layout. |
+| **Total** | **4** | Out of ~90 client modules (`frontend/src/client/*.ts`). |
+
+All four use bun's built-in `bun:test` (no extra dep). No DOM/jsdom tests. No Playwright. No `bun test` script in `package.json` (`bun run build` is the only script).
+
+### 1.3 End-to-end / smoke
+
+- `tests/smoke-2026-04-25.md`, `tests/smoke-auth-2026-04-25.md`, `tests/smoke-auth-2026-04-26-cleanup.md` — human-written reports with screenshots committed under `tests/screenshots-*`. No code. No re-runnable script.
+- `mai-tester` skill uses Playwright for ad-hoc runs; nothing committed.
+- No `e2e/`, no `.gitea/workflows/`, no `.github/workflows/`, no `Makefile`.
+
+### 1.4 Critical service paths with no test file
+
+These are `internal/services/*.go` for which no `*_test.go` sibling exists:
+
+| Service | Risk class | Why it matters |
+|---|---|---|
+| `caldav_service.go`, `caldav_client.go`, `caldav_crypto.go`, `caldav_ical.go` | High | Per-user push/pull goroutines + AES-GCM at rest. One pure parser test (`caldav_ical_timeline_test.go`) exists but the service + crypto + WebDAV client are blind. |
+| `agenda_service.go` | High | Dashboard agenda query; reused by `/agenda` page. Exercised transitively by visibility tests but no direct test. |
+| `dashboard_service.go` | High | Traffic-light + summary counts. Same story — transitively covered via visibility, no direct test. |
+| `derivation_service.go` | Medium | Project-tree derivation (the new t-paliad-194-era subtree machinery). |
+| `team_service.go` | Medium | Team membership / inheritance. |
+| `partner_unit_service.go` | Medium | Dezernat replacement (t-paliad-070). |
+| `party_service.go`, `note_service.go`, `link_service.go`, `checklist_instance_service.go` | Medium | All do project-scoped CRUD with the same RLS+audit pattern that `t-paliad-036` proved easy to break. |
+| `appointment_service.go` | High | Hot — every calendar mutation. Exercised through approval tests but has no own test file. |
+| `view_service.go` | Medium | Powers the substrate (`/views/*`). |
+| `paliadin_jwt.go` | Medium | Per-turn JWT mint for the aichat path (`t-paliad-194`). No call sites in tests today. |
+| `markdown.go` | Low | Glossary + checklist content render. |
+
+### 1.5 Handlers with no test file
+
+53 of 59. Notably: **`auth.go` itself** (login / logout / session creation), **`projects.go`** (the most-mutated entity), **`deadlines.go` / `appointments.go`** (writes), **`paliadin.go` / `paliadin_suggest.go`** (m-only routes — never click-tested), **`fristenrechner.go` / `fristenrechner_search.go` / `fristenrechner_event_categories.go`** (the cascade users live in), **`dashboard.go` / `agenda.go`** (landing), **`onboarding.go` / `onboarding_gate.go`** (every new user's first three minutes), **`invite.go`** (rate-limited write path). The currently-tested handlers (search, audit-parse, approval error mapping, etc.) are the cheap pure-Go ones; every handler that touches the DB is untested at handler level.
+
+### 1.6 Live-DB test scaffold — is it sound?
+
+The pattern (read from `internal/services/visibility_test.go`):
+
+```go
+url := os.Getenv("TEST_DATABASE_URL")
+if url == "" { t.Skip("TEST_DATABASE_URL not set — skipping live DB test") }
+if err := db.ApplyMigrations(url); err != nil { t.Fatalf(...) }
+pool, _ := sqlx.Connect("postgres", url)
+defer pool.Close()
+// per-test seed + cleanup via DELETE + defer cleanup()
+```
+
+Verdict: **sound, but has rough edges that need addressing before we widen.**
+
+- ✅ Migrations apply at test startup against the test DB — catches every "you forgot to add a CHECK" / "you reference a column that doesn't exist" before a real-DB-touching test runs.
+- ✅ Per-test cleanup via `DELETE FROM ... WHERE id IN ($1,...)` is explicit and idempotent.
+- ✅ The `paliad.paliad_schema_migrations` tracker collision noted in memory `0b900afa…` is a pre-existing issue, not introduced by this design.
+- ⚠️ Cleanup-via-DELETE is fragile: a test that creates a row referenced by FK from another table needs to remember to clean both. A few existing tests (see `audit_service_test.go`) already chain 5+ DELETEs.
+- ⚠️ Tests can't run in parallel against the same `TEST_DATABASE_URL` because they share schema state. `go test ./...` defaults to `-parallel` per-package; same-package tests with overlapping cleanup IDs can interfere.
+- ⚠️ No CI today actually exercises `TEST_DATABASE_URL` — so every live-DB test is effectively run only on the author's laptop or not at all. Half the value is paid-for but unbilled.
+
+### 1.7 Migration tooling
+
+- `internal/db/migrate.go` embeds `migrations/*.sql` and applies on server boot via `golang-migrate/v4` with the `paliad_schema_migrations` tracker in `public` schema.
+- 100 migrations on disk (`001` → `100`).
+- **No dry-run gate today.** A bad migration breaks `paliad.de` at boot (Dokploy crash-loops the container). Recent prod incidents: mig 098 (submission code rename), mig 099 (with_po flag drop missed audit_reason gap), mig 020 (function rename without body rewrite — see memory `49a05cfa…`).
+- `down.sql` exists for every migration but no test ever exercises it.
+
+### 1.8 CI / deploy loop
+
+- No CI. Push-to-main → Gitea webhook → Dokploy auto-builds the Dockerfile and replaces the container. The Dockerfile runs `bun run build` then `go build`. **Neither `go test` nor `bun test` runs in the build pipeline.**
+- Pre-commit hooks: none in repo. Each worker runs `go build / go vet / go test / bun run build` by convention (see memories — every shipped task report ends with "build hygiene held").
+
+---
+
+## 2. Test pyramid — recommended shape
+
+```
+                           ┌─────────────────┐
+                           │  E2E (Playwright)│  ~10 flows
+                           │  L6              │
+                           └─────────────────┘
+                       ┌─────────────────────────┐
+                       │  Handler integration    │  ~30 routes
+                       │  L5 (httptest + real DB)│
+                       └─────────────────────────┘
+                  ┌──────────────────────────────────┐
+                  │  Service-layer (live DB)         │  ~60 tests
+                  │  L4 (BEGIN/ROLLBACK harness)     │
+                  └──────────────────────────────────┘
+              ┌──────────────────────────────────────────┐
+              │  Frontend DOM / cascade (bun:test+jsdom) │  ~15 modules
+              │  L3                                      │
+              └──────────────────────────────────────────┘
+        ┌──────────────────────────────────────────────────────┐
+        │  Frontend unit (bun:test pure TS)                    │  ~30 modules
+        │  L2                                                   │
+        └──────────────────────────────────────────────────────┘
+   ┌──────────────────────────────────────────────────────────────┐
+   │  Go unit (stdlib testing, table-driven, pure functions)      │  ~150 tests
+   │  L1                                                          │
+   └──────────────────────────────────────────────────────────────┘
+   ┌──────────────────────────────────────────────────────────────┐
+   │  Migration dry-run (make verify-migrations)                  │  100 mig
+   │  L0 — gate on every PR                                       │
+   └──────────────────────────────────────────────────────────────┘
+```
+
+### Layer 0 — Migration dry-run
+
+**What:** Every `*.up.sql` in `internal/db/migrations/` is applied inside a single `BEGIN ... ROLLBACK` transaction against a scratch Postgres, in numeric order. The harness asserts each statement succeeds *and* asserts no statement leaves the schema in a `paliad_schema_migrations.dirty=true` state. A second pass applies all up-migrations end-to-end (no rollback) and then re-applies the latest up-migration to assert idempotency (every paliad migration since `t-paliad-070` has been written to be idempotent — this enforces it).
+
+**Tool:** stdlib `testing` package, no third-party. Pattern: `internal/db/migrate_test.go` with a `TestMigrations_DryRun` driven from `TEST_DATABASE_URL`. A `make verify-migrations` target wraps it.
+
+**Why this layer matters most:** Every recent prod-down was a migration. Catching them on a CI run before merge is the highest-leverage test investment paliad can make. Cost: one ~100-line Go file + one Postgres in CI.
+
+**Coverage target:** 100 % of `*.up.sql` files. Hard gate on PR — no exceptions.
+
+### Layer 1 — Go unit (pure)
+
+**What:** `go test ./...` against pure functions — formatters, parsers, validators, calculators, fee tables, deadline calculators, projection lookahead clamping, codec round-trips. No DB, no HTTP.
+
+**Tool:** stdlib `testing`. Table-driven `cases := []struct{...}{...}` style is already the house pattern (see `auth_test.go` / `projection_anchor_test.go`). **Do not introduce testify or any matcher library** — the current code reads cleanly without one, and 323 existing test functions don't need a rename pass.
+
+**What's already there:** 19 pure-Go test files (calculator, mapping, codec, holiday, fees, etc.). Density is good; targeted infill rather than re-architecture.
+
+**Coverage target:** Every pure function in `internal/services/`, `internal/handlers/`, `internal/calc/`, `internal/changelog/`. Aim for "every branch in a decision table has at least one test row." Don't chase % — chase "the obvious edge that would burn a coworker".
+
+### Layer 2 — Frontend unit (pure)
+
+**What:** `bun test` against pure TS modules — URL codecs (`filter-bar/url-codec`), formatters, parsers, i18n key correctness (every `data-i18n` attribute used in TSX has a key in `i18n.ts`), view-spec parsers, projection-row mapping helpers.
+
+**Tool:** `bun:test` (built into bun, no install). Already in use in 4 files — extend the same pattern. Add `bun test` to `package.json` `scripts`.
+
+**What to add:**
+- i18n key audit (every `t("foo.bar")` and `data-i18n="foo.bar"` resolves in both `de` and `en`).
+- `filter-bar/` types + render helpers (paliad has shipped 4 FilterBar slices; coverage is one codec test).
+- `paliadin-context.ts` route table + entity extraction (the `[ctx …]` envelope is a stable contract paliadin's SKILL.md depends on; any drift here is a silent failure).
+- `paliadin-starters.ts` registry — every route maps to ≥1 starter; every starter is bilingual.
+- View-spec parsers in `views/`.
+
+**Coverage target:** Every pure TS module in `frontend/src/client/`. Pages (TSX renderers) are E2E concern, not unit concern.
+
+### Layer 3 — Frontend DOM (cascade / jsdom)
+
+**What:** `bun test` with jsdom global, exercising the interactive cascade modules — the fristenrechner cascade builder, the shape-timeline render, the FilterBar UI (chips, panels), the calendar grid, the inline Paliadin widget message stream, the inbox-row click handler, the dashboard activity item navigation.
+
+These modules contain enough state that pure-function tests miss real bugs (e.g. the t-paliad-098 `.entity-table` row-cursor lie was a CSS+DOM bug; t-paliad-099's modal close was a DOM-event bug; t-paliad-103's `::before` overlay click-swallow was a DOM bug).
+
+**Tool:** bun + `happy-dom` is the lighter choice; if it can't handle event ordering, fall back to `jsdom`. Both are ESM-clean and bun-friendly. **Pick one and stick with it — running both means twice the dependency surface.** Default pick: `happy-dom` (smaller, paliad doesn't need legacy IE semantics).
+
+**Pattern:** import the cascade module, build a minimal DOM (`document.body.innerHTML = …`), dispatch synthetic events, assert resulting state. Reuses the production renderers — no test-only fakes.
+
+**Coverage target:** ~15 modules. Specifically:
+- `client/filter-bar/index.ts` chip render + active-state.
+- `client/fristenrechner.ts` cascade — most complex JS in the codebase; depend chains light up every UPC bug we know.
+- `client/shape-timeline.ts` lane mode + track mode (envelope wire shape brittle to refactor).
+- `client/projects-detail.ts` row click + Verlauf render.
+- `client/paliadin-widget.ts` + `paliadin-context.ts` interaction.
+- `client/inbox.ts` row-action click routing.
+- `client/dashboard.ts` activity-item nav.
+- `client/deadlines-calendar.ts` / `appointments-calendar.ts` column layout (the calendar-column-drift bug class).
+
+Not unit tests; not E2E. They are the missing middle.
+
+### Layer 4 — Service-layer (live DB)
+
+**What:** Go service methods against a real Postgres, using the existing `TEST_DATABASE_URL` pattern. Two improvements:
+
+1. **Replace per-test DELETE cleanup with a per-test transaction harness** — open a transaction, run the test inside it, ROLLBACK. Faster, isolating, no cleanup forgotten. Already viable because the service layer accepts `*sqlx.DB`-or-tx-shaped interfaces in many places; needs a small `internal/services/internal/testdb` package that exposes `WithTx(t *testing.T, fn func(*sqlx.Tx))`. Migration is mechanical, can happen alongside infill.
+
+   *Caveat:* some service methods open their own transactions internally (`approval_service.submit` is one). Those keep DELETE cleanup; the tx harness is a default, not a mandate.
+
+2. **Make `TEST_DATABASE_URL` mandatory in CI.** Today these tests are skipped on every machine that doesn't `export TEST_DATABASE_URL=…` — i.e. they don't run on autoatic pipelines because there's no pipeline. Once CI exists (§3.5), it becomes a required env var.
+
+**Tool:** stdlib `testing` + `sqlx` (already in `go.mod`). **No mocks at the service↔DB boundary.** This is m's hardest line — see global CLAUDE.md memory pattern and `t-paliad-036` (the bug that masked two other bugs would have been caught instantly by a real-DB test).
+
+**Where to invest first:** Approval (already heavy), Projection (already heavy), Fristenrechner (already heavy), DeadlineService Create/Update/Complete/Delete with `pending_request_id` interplay, AppointmentService same, ProjectService visibility predicate, CalDAV push (the four CalDAV `*.go` files have zero direct test).
+
+**Coverage target:** Every service method that mutates the DB has at least one happy-path live-DB test. RLS predicate (`visibilityPredicatePositional`) has one test per role (global_admin, member, non-member).
+
+### Layer 5 — Handler integration (httptest + real DB)
+
+**What:** Spin a real `services.DBService`, mount the protected mux, drive `httptest.NewRequest` + `ServeHTTP` against it. Auth via a fake session cookie produced by a `testauth.Login(t, userID)` helper that mints the same Supabase JWT shape `auth.UserIDFromContext` expects.
+
+**Why:** The 53 untested handlers are where the request shape ↔ service interaction lives. Examples that would have caught real bugs:
+- `t-paliad-036`'s "`/projects/{id}` 404 while `/api/projects/{id}` 200" mismatch — a 5-line handler test would have failed before the migration ran.
+- mig 020's three-stacked bug — a handler test that POSTs a deadline and asserts a 200 + read-back row would have failed at submit-time, not boot-time.
+- The audit-log query timezone bug — handler test asserts the JSON contains the expected `event_date`.
+
+**Tool:** stdlib `net/http/httptest`. **No new framework.** Pattern: handler tests live next to the handler file (`internal/handlers/deadlines_test.go` next to `deadlines.go`).
+
+**Coverage target:** Every handler that gates a state-changing route — `POST/PATCH/DELETE` flavour. Plus `GET` handlers that compose a non-trivial query (dashboard, agenda, search, audit-log).
+
+### Layer 6 — End-to-end (Playwright)
+
+**What:** A small Playwright suite (~10 flows) committed at `e2e/` with a `bun run e2e` entry. Targets a local `./paliad` against a scratch Postgres (the same `TEST_DATABASE_URL`). Each test logs in, drives the UI through one user journey, asserts visible state.
+
+**Why ~10 not 100:** Per-PR budget caps at ~2 min total (§6 Q1). Playwright tests are the most expensive minute-per-confidence in this stack; they pay for themselves on the *golden path* and nothing else. The deep-coverage layer is L5; E2E is *"is the app still alive end to end?"*.
+
+**Tool:** `playwright` (npm; bun installs cleanly). No third-party test runner — Playwright ships its own. Tests live in `e2e/*.spec.ts`. **Not bun:test.** Playwright's runner is purpose-built for browser-driving and integrates with their tracing — don't fight it.
+
+**Cap:** 10 flows. If a new test wants in, an existing one must drop out (or we have a real reason to widen). This is the cheapest discipline available: it forces the suite to remain a smoke pass, not a regression-test dumping ground.
+
+**Coverage target:** See §4.
+
+---
+
+## 3. Tooling — concrete picks per layer
+
+| Layer | Tool | Already in deps? | Install? |
+|---|---|---|---|
+| L0 — migration dry-run | stdlib `testing` + `migrate/v4` | yes | no |
+| L1 — Go unit | stdlib `testing` | yes | no |
+| L2 — Frontend unit | `bun:test` | yes (built into bun) | no |
+| L3 — Frontend DOM | `bun:test` + `happy-dom` | bun yes, happy-dom **new** | `bun add -d happy-dom` (one dep, ~200 KB) |
+| L4 — Service live-DB | stdlib + sqlx | yes | no |
+| L5 — Handler integration | stdlib `net/http/httptest` + sqlx | yes | no |
+| L6 — E2E | `@playwright/test` | **new** | `bun add -d @playwright/test` + `npx playwright install chromium` |
+
+Net new deps: **2** (happy-dom + playwright). Both are mainstream, both have small surface area, both align with bun's ecosystem.
+
+Explicit rejects:
+- ❌ **testify** — current tests read cleanly with stdlib; adding it forces a rename pass nobody wants.
+- ❌ **vitest** — bun's built-in test runner is faster and the tests are already in `bun:test` shape.
+- ❌ **dockertest / testcontainers-go** — m's preference is real-DB tests against the existing Postgres; spinning ephemeral Docker Postgres per package run adds latency and surface area for marginal isolation gain. See Q3.
+- ❌ **sqlmock / gomock for DB** — banned by §0 lesson 1.
+- ❌ **cypress** — Playwright is the better tool today, and the team's existing skill (`/mai-tester`) already uses it.
+
+### 3.1 Per-PR run-time budget
+
+Target (subject to m's call in Q1): **≤ 90 s for the gating tier (L0+L1+L2+L4 subset+L5 happy-path)**, ≤ 4 min for the full suite (add L3+L4 full+L6). The gating tier blocks merge; the full suite blocks deploy.
+
+Indicative times (estimated, validate when slice 1 lands):
+
+| Tier | Layers | Est. time | Blocks |
+|---|---|---|---|
+| **Gate (every PR)** | L0 + L1 + L2 + L5 happy-path + L4 critical | 60–90 s | merge |
+| **Full (every merge to main)** | + L4 full + L3 + L6 | 3–4 min | deploy |
+
+### 3.2 CI — proposal, not commitment
+
+paliad has no CI today. Two routes:
+
+- **Gitea Actions** (m's stack already runs `mgit.msbls.de`). Self-hosted; same auth model as the rest of mAi. Adds a `.gitea/workflows/test.yml`. Postgres comes from a service container.
+- **Stay click-deploy.** No CI. Workers run tests locally; Dokploy auto-deploys on green-main convention.
+
+Recommendation: **Gitea Actions for the gate tier only** (L0 + L1 + L2), driven by a single short workflow. The L3-L6 expansion can be a follow-up once the gate tier proves stable. Deferred to Q2 for m's call.
+
+### 3.3 Test DB — live YouPC vs ephemeral
+
+The `paliad` schema lives on the shared YouPC Postgres (port 11833). Three options:
+
+| Option | Pros | Cons |
+|---|---|---|
+| **Per-developer separate DB on YouPC** (`TEST_DATABASE_URL` per laptop) | Closest to prod; existing pattern. | Cleanup discipline matters; cross-developer contention possible. |
+| **Ephemeral docker postgres per CI run** | Full isolation; parallel-safe; reset for free. | New infra; ~5 s container startup per CI invocation. |
+| **Dedicated test DB on a paliad-only Postgres** | Isolated; cheap. | New infra to maintain. |
+
+Recommendation: **option 1 for developers (no-op change), option 2 for CI** (Gitea Actions postgres service container). Deferred to Q3 for m's call.
+
+### 3.4 Coverage targets
+
+Don't gate on percentage. Gate on critical-path coverage (§4). Add `go test -coverprofile=` output to CI for visibility, not as a merge gate. Coverage % gating produces tests-for-tests'-sake; we want the tests that catch the bugs we've shipped.
+
+---
+
+## 4. Critical journeys — what MUST be covered
+
+These are the golden-path flows. Anything not on this list is L1-L5 territory, not L6. The list is intentionally short; if it grows beyond 10, we are doing E2E wrong.
+
+| # | Flow | Why it's critical | Layer mix |
+|---|---|---|---|
+| 1 | **Login → dashboard renders → traffic-light counts match** | Every user does this every day; broken auth = paliad is offline. | L6 (Playwright) + L5 handler (auth.go) |
+| 2 | **Create project (Client → Litigation → Patent → Case)** | Hierarchy with team inheritance — the data model's spine. | L6 + L5 + L4 (project_service) |
+| 3 | **Submit deadline → routes to /inbox → approver approves → state flips** | The 4-eye flow (t-paliad-138). Most-mutated paliad surface. | L6 + L5 (deadlines, approvals) + L4 (approval_service) |
+| 4 | **Fristenrechner: pick proceeding → cascade fires → result shows** | The platform's flagship interactive tool. JS cascade. | L6 + L3 (fristenrechner cascade) + L4 (fristenrechner) |
+| 5 | **SmartTimeline: anchor a projected row → predecessor-missing-error handled** | Recent Slice-2 work (t-paliad-173 / #31). High-touch surface. | L6 + L3 (shape-timeline) + L4 (projection_service) |
+| 6 | **CalDAV sync: PUT a Termin → external client sees it, edits there → pull reconciles** | Owned-event semantics + foreign-UID skip rule from Phase F. Untested today. | L4 (caldav_service push/pull) — gated on Q3 (live YouPC vs ephemeral) |
+| 7 | **Paliadin chat: anon visit hits 404; m's session opens widget; turn renders** | Owner-gated `/paliadin` is the only m-only surface. Quiet failures here are silent. | L6 (smoke) + L5 (paliadin_suggest) + L4 (paliadin / aichat_paliadin) |
+| 8 | **/admin/rules: filter → edit one rule → lifecycle transition → audit log row** | Rules drive the cascade; bad edits break every user's fristenrechner. | L6 + L5 (admin_rules) + L4 (rule_editor_service) |
+| 9 | **Onboarding: new user with allowed email → onboarding form → first project membership** | The new-user funnel; gateOnboarded middleware traps. | L6 + L5 (onboarding, invite) |
+| 10 | **Migration boot smoke: spin paliad against an empty DB → server binds 8080** | Catches every mig-N crash-loop. | L0 (migration dry-run) + L4 boot-smoke variant |
+
+Picks 1, 3, 4 and 10 are the highest-value-per-cost — they cover the routes most regressions land on (auth, mutation, cascade, boot).
+
+---
+
+## 5. Slice plan — tracer-bullet roll-out
+
+Each slice is a shippable PR with a concrete deliverable, in order of expected outage-prevention payoff. Sized for a single coder shift unless flagged. No slice depends on a later one being merged. Hour estimates intentionally omitted (per global CLAUDE.md).
+
+### Slice 1 — Migration dry-run harness + boot smoke (highest leverage)
+
+**Branch:** `mai/<coder>/test-strategy-slice-1-migrations`
+
+**Deliverable:**
+- `internal/db/migrate_test.go` — `TestMigrations_DryRun` (per-mig BEGIN/ROLLBACK), `TestMigrations_EndToEnd` (full apply, then re-apply latest to assert idempotency), `TestMigrations_Down` (apply N→0).
+- `Makefile` with `make verify-migrations` (the gate target), `make test` (run everything), `make test-go`, `make test-frontend`.
+- `cmd/server/main_paliadin_backend_test.go` already exists; extend with a `TestMain_BindsHTTPAfterMigrate` that boots the full server against `TEST_DATABASE_URL`, asserts `:8080` is listening, then shuts down. Catches the mig-098-class crash-loop in a single test.
+- README section: how to set `TEST_DATABASE_URL` locally.
+
+**Catches:** Every mig-98-class crash-loop; every drop-cascade-with-stale-policy-name regression (t-paliad-036).
+
+### Slice 2 — Service-layer infill: critical mutators
+
+**Branch:** `mai/<coder>/test-strategy-slice-2-services`
+
+**Deliverable:**
+- Test files for the three highest-impact untested services:
+  - `internal/services/agenda_service_test.go` (live-DB, dashboard agenda query)
+  - `internal/services/dashboard_service_test.go` (traffic-light counts)
+  - `internal/services/team_service_test.go` (membership + inheritance — RLS-load-bearing)
+- Tighten existing `approval_service_test.go` + `deadline_service_test.go` coverage of the create/update/complete/delete × pending-request matrix where there are demonstrable gaps.
+- Add `internal/services/internal/testdb/withtx.go` — the per-test tx harness (optional adoption; existing tests stay).
+
+**Catches:** RLS regressions, approval interplay regressions, dashboard count drift after schema renames.
+
+### Slice 3 — Frontend bun:test setup + L2 infill
+
+**Branch:** `mai/<coder>/test-strategy-slice-3-frontend-unit`
+
+**Deliverable:**
+- `frontend/package.json` `scripts.test = "bun test"`.
+- New tests under `frontend/src/client/`:
+  - `paliadin-context.test.ts` (route table, entity extraction, selection truncation).
+  - `paliadin-starters.test.ts` (every route ≥1 starter, every starter bilingual).
+  - `filter-bar/index.test.ts` (chip render + active state — pure DOM-less helpers).
+  - i18n key audit: `frontend/scripts/i18n-audit.test.ts` parses every `data-i18n="…"` from `dist/` HTML and every `t("…")` call from `src/`, asserts both `de` and `en` resolve. Runs as part of `bun test`.
+- `make test-frontend` wires `cd frontend && bun test`.
+
+**Catches:** i18n drift (untranslated key shipped to user), context-envelope contract drift (paliadin SKILL.md depends on it), starter-registry regressions.
+
+### Slice 4 — Playwright golden-path smoke
+
+**Branch:** `mai/<coder>/test-strategy-slice-4-e2e`
+
+**Deliverable:**
+- `e2e/` directory at repo root.
+- `playwright.config.ts` pointing at `http://localhost:8080` (paliad started by the test, not assumed).
+- Five Playwright `*.spec.ts` files covering critical journeys 1, 3, 4, 7, 9 from §4.
+- `make e2e` target that:
+  1. starts paliad against `TEST_DATABASE_URL`,
+  2. waits for `:8080` to be live,
+  3. runs `npx playwright test`,
+  4. tears the server down.
+- `bun add -d @playwright/test` + `npx playwright install chromium`.
+
+**Catches:** Auth regressions, deadline-mutation regressions, fristenrechner cascade regressions, owner-gated /paliadin leaks, onboarding-gate misbehaviour.
+
+### Slice 5 — Handler integration tests for the 5 most-touched routes
+
+**Branch:** `mai/<coder>/test-strategy-slice-5-handlers`
+
+**Deliverable:**
+- `internal/handlers/auth_test.go` extended with `TestLogin_HappyPath` + `TestLogout_ClearsCookie` (real DB).
+- `internal/handlers/projects_test.go` — `TestProjectsCreate` (POST 200, row inserted, audit emitted), `TestProjectsGetByID_RespectsVisibility` (404 for non-member).
+- `internal/handlers/deadlines_test.go` — `TestDeadlinesCreate_TriggersApproval` (verifies pending pill).
+- `internal/handlers/appointments_test.go` — same shape.
+- `internal/handlers/paliadin_test.go` — `TestPaliadinPage_404ForNonOwner`, `TestPaliadinPage_200ForOwner`.
+- Shared `internal/handlers/testauth/testauth.go` — mints a session cookie for `userID` so handler tests don't reinvent auth seeding.
+
+**Catches:** Handler ↔ service wiring drift, visibility-predicate handler-side bugs (t-paliad-036 bug 2 was exactly this), owner-gate bypass.
+
+### Slice 6 — Frontend L3 (DOM) cascade tests
+
+**Branch:** `mai/<coder>/test-strategy-slice-6-frontend-dom`
+
+**Deliverable:**
+- `bun add -d happy-dom`.
+- DOM-driven tests for the three most-touched cascades:
+  - `client/fristenrechner.test.ts` (cascade activate → row appears → date-set fires fetch).
+  - `client/shape-timeline.test.ts` (lane render, track render, projected-row click).
+  - `client/filter-bar/index.test.ts` (chip click toggles state, URL params update).
+
+**Catches:** The whole class of "the function exists and is unit-tested but the cascade in the browser doesn't fire it" bugs. This is the layer that catches t-paliad-098 / 099 / 102 / 103.
+
+### Slice 7 — CI wiring (deferred — Q2 dependent)
+
+**Branch:** `mai/<coder>/test-strategy-slice-7-ci` (gated on m's Q2 pick)
+
+**Deliverable:**
+- `.gitea/workflows/test.yml` (or stay click-deploy if m picks that).
+- Gate tier runs on every PR; full suite runs on merge to main.
+- Postgres service container provides `TEST_DATABASE_URL`.
+- Slack/Gotify ping on red main.
+
+**Catches:** Drift between "tests pass on my laptop" and prod reality.
+
+### Slice 8 — Coverage reporting + dashboard (lowest priority)
+
+**Branch:** `mai/<coder>/test-strategy-slice-8-coverage`
+
+**Deliverable:**
+- `go test -coverprofile=` aggregated into a single `coverage.html`.
+- Bun's coverage output similarly.
+- A `docs/coverage.md` index updated by CI.
+- **Not a merge gate.** Visibility only.
+
+**Catches:** Slow drift; nice-to-have once the floor is in.
+
+### Slice order rationale
+
+1, 4, 5 are the highest outage-prevention per LoC: migration dry-run kills crash-loops, E2E kills regressions, handler tests kill wiring drift. 2, 3, 6 widen the floor; 7-8 are infrastructure.
+
+---
+
+## 6. Open questions for m
+
+These need m's call before any coder shift starts (or before specific slices start, where noted).
+
+### Q1 — Per-PR test-run budget
+
+How long is acceptable to wait on the gate tier before merge?
+
+- 30 s — only L0 + L1 (no L2+ on the gate).
+- **60–90 s (recommended)** — L0 + L1 + L2 + L5 happy-path + L4 critical.
+- 2 min — add L3 + L4 full.
+- 4+ min — add L6 (E2E on gate).
+
+The pick determines whether E2E gates merge or only deploy.
+
+### Q2 — CI infrastructure
+
+- **Gitea Actions** (self-hosted, gate tier only, recommended) — minimal new infra; aligns with m's existing stack.
+- **Stay click-deploy** — workers run tests locally; merge discipline enforced by convention. Today's reality; we keep it.
+- **Both:** start with click-deploy, add Gitea Actions in Slice 7 once gate tier proves stable.
+
+### Q3 — Live-DB vs ephemeral docker Postgres for tests
+
+- **Per-developer YouPC DB (current pattern)** — closest to prod; existing tests work unchanged.
+- **Ephemeral docker postgres in CI, YouPC for devs (recommended hybrid)** — keeps local-dev simple, gives CI deterministic isolation.
+- **YouPC everywhere** — simplest, but parallel CI runs would contend.
+
+### Q4 — Coverage targets — % or critical-path?
+
+- **Critical-path only (recommended)** — §4's 10 flows + every state-mutating service method has a test. No % gate.
+- **% gate** — set a floor (e.g. 60 % lines, 50 % branches) and refuse merges below it.
+- **Both** — critical-path is mandatory, % is informational.
+
+m's prior preference (memory pattern: "tests that catch real bugs > coverage theatre") points at critical-path-only. Confirming.
+
+### Q5 — Which slices land before paliad is "production-grade"?
+
+paliad is already live at `paliad.de` and being used by HLC colleagues. "Production-grade" here means "next time someone ships, we don't go down."
+
+Picks:
+- **Slices 1 + 4 + 5 are the production-grade floor (recommended).** Migration dry-run + golden-path E2E + handler integration tests cover the failure modes that hit prod since the rebrand.
+- Add Slice 2 + 3 + 6 as widening passes, on their own cadence.
+- Slice 7-8 are nice-to-haves.
+
+Confirming the floor pick — and whether m wants all three to land before any new feature work, or whether they roll out alongside.
+
+### Q6 — Who owns each slice?
+
+Recommendation: rotate coder slots so the same person isn't on every slice. Suggested assignment (head can override):
+
+| Slice | Profile fit |
+|---|---|
+| 1 — migrations | Backend-heavy coder (knuth, gauss, cronus). |
+| 2 — service infill | Backend-heavy coder; whoever owns approval/projection. |
+| 3 — frontend unit | Frontend-heavy coder. |
+| 4 — Playwright E2E | Cross-stack coder; ideally one familiar with `/mai-tester`. |
+| 5 — handler integration | Backend coder. |
+| 6 — frontend DOM | Frontend coder (same person as 3 makes sense). |
+
+Inventor does **not** decide assignments; head + m do.
+
+---
+
+## 7. Out of scope (explicit)
+
+- **No rewrite of any existing test.** The 323 existing test functions stay. New tests use the new patterns; old tests are migrated only when their files are touched for unrelated reasons.
+- **No third-party framework where stdlib + bun:test suffice** (testify, vitest, etc. — see §3).
+- **No mocks at the service↔DB boundary.** This is the lock-in. Mocks lie; the live-DB tests we already have are paliad's most useful safety net.
+- **No new feature work in this strategy.** The doc proposes infra; feature scope is unchanged.
+- **No retirement of the `tests/smoke-*.md` human-written reports.** Those are great for one-shot regression hunts; they coexist with the automated suite.
+
+---
+
+## 8. Implementation notes for the eventual coder
+
+(For whichever coder picks up a slice. Not exhaustive.)
+
+- **Test-name collisions in Go's flat package namespace bite when a service grows N implementations.** Memory note from `t-paliad-194` already records this. Prefix tests with the service name (e.g. `TestAichatPaliadin_RunTurn_…` not `TestRunTurn_…`).
+- **`httptest.NewRequest` does not URL-encode** — use `url.QueryEscape` for any `?q=…` argument. Memory note from `t-paliad-026`.
+- **sqlx v1.4.0 `Named` parser strips one colon from `::uuid[]`** — known pitfall, repro lives at `internal/services/project_service.go`. Use `CAST(... AS uuid[])` in new query strings.
+- **Live-DB cleanup must DELETE FKs first.** Order matters (auth.users last). Look at `audit_service_test.go` for the chain pattern.
+- **`paliad.paliad_schema_migrations` tracker collision** is documented but unresolved. Slice 1 should add a `make reset-test-db` target that drops both `public.paliad_schema_migrations` *and* `paliad.paliad_schema_migrations` to keep developers unblocked.
+- **`bun:test` matchers are Jest-compatible** — `expect().toEqual()`, `expect().toHaveBeenCalled()`, etc. No deps needed.
+- **happy-dom does not implement** every DOM method (notably some `<dialog>` semantics). If a cascade test fails on something missing, jsdom is the escape hatch.
+
+---
+
+## 9. Decision summary — pick list for m
+
+| # | Question | Inventor recommends |
+|---|---|---|
+| Q1 | Per-PR budget | 60–90 s gate, 3–4 min full |
+| Q2 | CI infra | Gitea Actions, gate tier only |
+| Q3 | Test DB | YouPC for devs, ephemeral docker for CI |
+| Q4 | Coverage target | Critical-path only, no % gate |
+| Q5 | Production-grade floor | Slices 1 + 4 + 5 before new feature work |
+| Q6 | Slice ownership | Rotate per profile; head decides |
+
+If m's calls match inventor's, the implementer's brief writes itself: Slice 1 first, then 4 + 5 in parallel, then 2/3/6 as widening passes.
+
+---
+
+**Status:** DESIGN READY FOR REVIEW. Awaiting m go/no-go on §5 slice plan + §6 open questions before any coder shift starts.
+
+---
+
+## 10. m's decisions (2026-05-19, locked)
+
+Walked through §6 with m via the AskUserQuestion interview (per head's 2026-05-19 workflow rule: inventor questions are resolved before parking, not after). Six picks locked, all matching inventor's recommendation.
+
+| # | Question | m's answer | Effect on plan |
+|---|---|---|---|
+| Q1 | Per-PR test-run budget | **Inventor's call** (m deferred). Pick: **60–90 s gate, 3–4 min full.** | Gate tier = L0 + L1 + L2 + L5 happy-path + L4 critical. L6 E2E gates deploy, not merge. |
+| Q2 | CI infrastructure | **Gitea Actions, gate tier only.** | Slice 7 adds `.gitea/workflows/test.yml` running the gate tier; full suite stays on merge-to-main. |
+| Q3 | Test DB topology | **YouPC for devs + ephemeral docker for CI.** | Local dev unchanged. Slice 7 wires Postgres service container in Gitea Actions. |
+| Q4 | Coverage target | **Critical-path only, no % gate.** | §4's 10 flows + every state-mutating service method gets a test. Coverage % output is informational in Slice 8, never a merge gate. |
+| Q5 | Production-grade floor | **Slices 1 + 4 + 5 before new feature work.** | These three land before any new paliad feature gets a coder shift. Slices 2, 3, 6 widen the floor on their own cadence. Slices 7-8 are nice-to-haves. |
+| Q6 | Slice ownership | **Head decides + rotate per profile.** | Backend slices (1, 2, 5) → backend-heavy coder. Frontend slices (3, 6) → frontend-heavy coder. E2E (4) → cross-stack. Head picks at dispatch time. |
+
+**Implementer brief (post-m-decisions):**
+
+1. **Slice 1 starts first** — migration dry-run harness + `make verify-migrations` + boot-smoke variant of `cmd/server/main_paliadin_backend_test.go`. Backend-heavy coder.
+2. **Slice 4 + Slice 5 in parallel** once Slice 1 is merged — Playwright golden-path (cross-stack coder, 5 specs) and handler integration (backend coder, auth/projects/deadlines/appointments/paliadin).
+3. Slice 7 (Gitea Actions wiring) follows once Slice 1 gate tier is proven locally.
+4. Slices 2, 3, 6 enter rotation alongside feature work — not blocking.
+5. Slice 8 (coverage reporting) lowest priority.
+
+**Status:** DESIGN APPROVED — awaiting head's dispatch of Slice 1 coder shift.

docs/design-proceeding-code-taxonomy-2026-05-18.md

@@ -0,0 +1,172 @@
+# Proceeding-code taxonomy (t-paliad-204 ratified 2026-05-18)
+
+> Source of truth for `paliad.proceeding_types.code`. Every active row's
+> `code` MUST conform to the convention below. This document anchors
+> migration 096 (`internal/db/migrations/096_proceeding_code_rename.up.sql`)
+> and the post-migration determinator + fristenrechner mapping in
+> `internal/services/proceeding_mapping.go`.
+
+## 0. Why we renamed
+
+The historical `code` strings (`UPC_INF`, `DE_INF`, `EPA_OPP`, …) were
+UPPER_SNAKE jurisdiction-glued-to-acronym slugs. They were structurally
+opaque and the taxonomy grew unevenly as more proceedings entered the
+fristenrechner — `UPC_APP` covers all UPC appeals, `DE_INF_OLG` /
+`DE_INF_BGH` carry the instance hint inline, `EP_GRANT` is the only EPA
+row with no `EPA_` prefix at all. The mapping in
+`internal/services/proceeding_mapping.go` had to special-case appeal
+ambiguities (no instance hint on UPC_APP, none on the DE side either).
+After mig 095 landed the t-paliad-205 fristen gap-fill, m and paliadin
+ratified a uniform convention for the corpus, captured here.
+
+## 0.1 Convention
+
+Active proceeding codes are lowercase, dot-separated, three positions:
+
+    <jurisdiction>.<X>.<Y>
+
+* **`<jurisdiction>`** — one of `upc`, `de`, `epa`, `dpma`.
+* **`<X>` / `<Y>`** — contextual; for first-instance proceedings they are
+  `<substantive-type>.<forum>` (e.g. `de.inf.lg` for Verletzungsklage am
+  Landgericht). For appeals they are `<appeal-type>.<scope>` (e.g.
+  `upc.apl.merits`, `upc.apl.cost`, `upc.apl.order`).
+* The CHECK constraint installed by mig 096 enforces
+  `code ~ '^[a-z]+\.[a-z]+\.[a-z]+$'` on every active row, with a
+  carve-out for the legacy `_archived_litigation` bucket
+  (`code ~ '^_archived_'`).
+
+The convention is forward-looking: any new fristenrechner row added
+after mig 096 MUST conform — no further UPPER_SNAKE codes.
+
+## 0.2 Ratified taxonomy
+
+### UPC
+
+| New code           | Old code         | id | Notes                                                                  |
+|--------------------|------------------|----|------------------------------------------------------------------------|
+| `upc.inf.cfi`      | `UPC_INF`        | 8  | Verletzungsverfahren, CFI                                              |
+| `upc.rev.cfi`      | `UPC_REV`        | 9  | Nichtigkeitsverfahren, CFI                                             |
+| `upc.ccr.cfi`      | _new_            | _new_ | Widerklage auf Nichtigkeit — illustrative peer of `upc.inf.cfi`. Rules live on `upc.inf.cfi` with `with_ccr=true`. See §1 sub-decision S1. |
+| `upc.pi.cfi`       | `UPC_PI`         | 10 | Einstweilige Maßnahmen                                                 |
+| `upc.dmgs.cfi`     | `UPC_DAMAGES`    | 17 | Schadensbemessung                                                      |
+| `upc.disc.cfi`     | `UPC_DISCOVERY`  | 18 | Bucheinsicht                                                           |
+| `upc.apl.merits`   | `UPC_APP`        | 11 | Hauptberufung — covers inf + rev + ccr + damages-merits appeals        |
+| `upc.apl.order`    | `UPC_APP_ORDERS` | 20 | 15-Tage-Beschwerde gegen Anordnungen (R.220 (1)(c))                    |
+| `upc.apl.cost`     | `UPC_COST_APPEAL`| 19 | Kostenbeschwerde                                                       |
+
+### DE
+
+| New code            | Old code               | id | Notes                                                       |
+|---------------------|------------------------|----|-------------------------------------------------------------|
+| `de.inf.lg`         | `DE_INF`               | 12 | Verletzungsklage am Landgericht                             |
+| `de.inf.olg`        | `DE_INF_OLG`           | 25 | Berufung am OLG                                             |
+| `de.inf.bgh`        | `DE_INF_BGH`           | 26 | Revision + NZB merged — `with_nzb` flag on NZB-detour rules |
+| `de.null.bpatg`     | `DE_NULL`              | 13 | Nichtigkeitsverfahren am BPatG                              |
+| `de.null.bgh`       | `DE_NULL_BGH`          | 27 | Nichtigkeitsberufung am BGH                                 |
+
+### EPA
+
+| New code            | Old code     | id | Notes                                          |
+|---------------------|--------------|----|------------------------------------------------|
+| `epa.grant.exa`     | `EP_GRANT`   | 16 | EP-Erteilungsverfahren                         |
+| `epa.opp.opd`       | `EPA_OPP`    | 14 | Einspruchsverfahren                            |
+| `epa.opp.boa`       | `EPA_APP`    | 15 | Einspruchsbeschwerde (Board of Appeal)         |
+
+### DPMA
+
+| New code              | Old code                | id | Notes                                                          |
+|-----------------------|-------------------------|----|----------------------------------------------------------------|
+| `dpma.opp.dpma`       | `DPMA_OPP`              | 28 | Einspruch beim DPMA                                            |
+| `dpma.appeal.bpatg`   | `DPMA_BPATG_BESCHWERDE` | 29 | Beschwerde am BPatG (generic — source differentiated at rule level) |
+| `dpma.appeal.bgh`     | `DPMA_BGH_RB`           | 30 | Rechtsbeschwerde am BGH (generic — source differentiated at rule level) |
+
+### Archived
+
+| Code                    | id | Notes                                  |
+|-------------------------|----|----------------------------------------|
+| `_archived_litigation`  | 32 | Unchanged — Pipeline-A retired corpus  |
+
+IDs are stable. Only the `code` STRING changes. The FKs
+`deadline_rules.proceeding_type_id`, `projects.proceeding_type_id`, and
+`deadline_rules.spawn_proceeding_type_id` reference IDs, so the existing
+rule corpus and spawn wiring (incl. mig 095's `spawn_proceeding_type_id=11`)
+continue to work unchanged.
+
+## 0.3 Sub-decisions (m's calls, 2026-05-18)
+
+### S1 — `upc.ccr.cfi` visibility
+
+`is_active=true`, visible in the determinator + dropdowns. **No rules
+attached.** When the determinator surfaces it, the UI shows the hint:
+
+> "Regeln liegen auf upc.inf.cfi (with_ccr=true); wir leiten Sie dorthin
+> weiter."
+
+Routing logic lands in `internal/services/proceeding_mapping.go` — when
+the cascade resolves to `upc.ccr.cfi`, the mapping returns the
+`upc.inf.cfi` id (=8) with `with_ccr=true` as a default flag. The peer
+exists for taxonomic completeness so users searching for
+"Widerklage" find an entry; it is not a separate rule namespace.
+
+### S2 — Abbreviations
+
+`dmgs` for damages, `disc` for discovery. m's call: short form keeps the
+codes terse and the dot-separated shape readable.
+
+### S3 — Damages appeal
+
+**NO separate code.** `upc.apl.merits` covers damages appeals — the
+spawn rules from `upc.dmgs.cfi` (none seeded today) would carry their
+own `spawn_label`. Avoids a code like `upc.apl.dmgs` whose rules would
+be empty for the foreseeable future.
+
+### S4 — NZB at BGH
+
+Single bucket `de.inf.bgh`. Rules diverging in the NZB-detour-path
+(Nichtzulassungsbeschwerde when the OLG didn't grant Revision) use a
+`with_nzb` flag instead of a separate proceeding type. Keeps the dropdown
+list shorter and matches how m practitioners think about the BGH
+instance — same destination, two ways to arrive.
+
+### S5 — DPMA appeals
+
+Generic `dpma.appeal.bpatg` / `dpma.appeal.bgh` — source-of-decision
+differentiation (was it a DPMA decision being appealed? a BPatG
+decision being further appealed to BGH?) lives at the rule level, not
+the proceeding-type level. Keeps the code namespace flat.
+
+## 0.4 Spawn-FK invariant
+
+After mig 096, the spawn FK invariant from mig 095 still holds:
+
+    deadline_rules.spawn_proceeding_type_id = 11
+       ↔ paliad.proceeding_types[id=11].code = 'upc.apl.merits'
+
+Spawn rules from `upc.inf.cfi` / `upc.rev.cfi` chain to the appeal-merits
+proceeding without code-string awareness. Same for any future spawn FK.
+
+## 0.5 Not in scope
+
+* `paliad.event_categories.slug` segments (`upc-inf`, `de-bgh-null`, …)
+  are NOT renamed. They are stable identifiers in a separate taxonomy and
+  their kebab form is presentation-layer (it appears in URL fragments).
+  Mig 096 only updates the `proceeding_type_code` text column on
+  `paliad.event_category_concepts` rows so the soft join through
+  `event_category_concepts → proceeding_types.code` keeps resolving.
+* Fee-table keys (`EPA_OPPOSITION`, `UPC_APPEAL`, …) in
+  `internal/calc/fees.go` are NOT proceeding codes — they are fee-table
+  bucket keys with their own naming. Untouched.
+* Forum bucket slugs (`upc_cfi`, `de_lg`, …) in
+  `ForumToProceedingCodes` are presentation buckets, not codes. The
+  values inside (`UPC_INF`, …) are the codes being renamed.
+
+## 0.6 References
+
+* `internal/db/migrations/096_proceeding_code_rename.up.sql` — the
+  migration that lands this rename.
+* `internal/services/proceeding_mapping.go` — post-mig 096 mapping with
+  the ccr-routing helper (S1).
+* `internal/services/proceeding_codes_shape_test.go` — Go test asserting
+  every active fristenrechner-category code matches the new shape regex.
+* mig 095 (`internal/db/migrations/095_fristen_gap_fill.up.sql`) — the
+  immediate predecessor; spawn_proceeding_type_id=11 carries through.

docs/design-project-chart-2026-05-09.md

@@ -0,0 +1,607 @@
+# Design — Project Timeline / Chart (visualisation layer above SmartTimeline)
+
+**Author:** faraday (inventor)
+**Date:** 2026-05-09
+**Task:** t-paliad-177
+**Issue:** m/paliad#35
+**Status:** READY FOR REVIEW — m gates inventor → coder transition.
+
+---
+
+## 0. Premises verified live (before designing)
+
+Before anchoring the design, I checked the live state — CLAUDE.md / memory / issue body can drift, the live system can't.
+
+- **SmartTimeline data substrate is shipped through Slice 4.** `internal/services/projection_service.go:287 (For)` returns `([]TimelineEvent, ProjectionMeta, error)`. The wire envelope (`ResponseEnvelope`) is `{events: TimelineEvent[], lanes: LaneInfo[]}` — `Lanes` is the load-bearing primitive for parent-node aggregation (one column per direct child case / patent / litigation). `LevelPolicy` already differentiates `self_plus_ccr` (Case) / `child_case` (Patent) / `child_patent` (Litigation) / `child_litigation` (Client). Recent commits 7da8802, 7e57507, 7930ee0 confirm — design merge is on `main` (b4f4b3 baseline as of this branch).
+- **Frontend renderer for the SmartTimeline is `frontend/src/client/views/shape-timeline.ts` (960 LoC, hand-rolled DOM via `document.createElement`).** It already implements: vertical flow, parallel-track CSS-grid for CCR (`renderParallelTracks`), lane-strip CSS-grid for parent-node aggregation (`renderLaneStrip`), click-to-anchor inline editor, `[Track ▼]` chip, lane-filter chip multiselect, lookahead toggle. The "horizontal Gantt" mode m's brief asks about does **not** exist.
+- **No chart library is in the repo.** `package.json` has only `@types/bun`. No D3, no Chart.js, no Apache ECharts, no plotly, no chartjs-node-canvas. Frontend is hand-rolled DOM/SVG via the custom TSX renderer described in `.claude/CLAUDE.md`. Adding a runtime dep would need m's explicit approval (per global rules).
+- **No PDF / image-export pipeline exists either.** `internal/services/caldav_ical.go` generates VCALENDAR strings (BEGIN:VCALENDAR / BEGIN:VEVENT) for CalDAV PUT bodies, but there is no public iCal-feed download endpoint, no headless-browser dep (`chromedp` not in `go.sum`), no Go PDF lib. The only existing `Content-Disposition: attachment` header is in `internal/handlers/files.go` for the Gitea Downloads proxy.
+- **Custom Views render shapes are list / cards / calendar.** `internal/services/render_spec.go` declares `RenderShape` = `ShapeList | ShapeCards | ShapeCalendar`. **There is no `ShapeTimeline` registered yet** — t-paliad-169 §8.6 reserved the slot but didn't claim it. A new chart shape would extend this enum and grow `frontend/src/views.tsx` host accordingly.
+- **Mobile breakpoints in use today are 640px / 720px / 768px / 1023px** (`frontend/src/styles/global.css`). Lime green primary token is `--color-accent: var(--hlc-lime)` with light/dark variants and a `--color-accent-fg` foreground token. There is `@media print` already in the stylesheet — printing is on the table.
+- **Project hierarchy depth in prod = 4 levels, 11 projects total.** A loaded Patent at the upper end has 5 child cases; a hypothetical Client could have 100+ matters. Any chart layout must answer "how does this look on a page with 5 cases × 30 events" and "with 100+ matters" — see §10.
+
+If the live state above contradicts a memory or issue note, the live state wins.
+
+---
+
+## 1. Vision + scope
+
+m's brief (verbatim 2026-05-09 18:32):
+
+> One could chose to show the timeline in one or in separate columns and with different colors even... bigger feature development but ... a project timeline / chart would be nice in general. So we need to make some considerations on how to design one. Another aspect to this is vertical or horizontal... and an export functionality would also be great.
+
+The **Project Timeline / Chart** is the *visualisation layer* above the SmartTimeline data substrate. Where SmartTimeline answers "what is the data", the Chart answers "how does the lawyer want to see it today, on what surface, in what shape, exported to whom".
+
+### What this design covers
+
+| Axis | Choices |
+|---|---|
+| **Layout direction** | Vertical (today) / Horizontal Gantt-strip / Hybrid |
+| **Column model** | Single-column flow / Multi-column (lanes — already in substrate) |
+| **Visual customisation** | Color schemes per track / kind / status / party; density modes (compact/standard/spacious); status pill / kind chip / shape variants |
+| **Export** | SVG (vector) / PNG (raster) / PDF (browser-print or rasterised) / CSV (data) / JSON (data) / iCal (deadlines+appointments feed) |
+| **Surfaces** | Verlauf-tab embed (existing) / `/projects/{id}/chart` standalone full-page / `RenderShape="timeline"` Custom Views |
+
+### What stays
+
+- **`projection_service.go` is the only data source.** No new query path. The chart is a presentation-level concern; data composition is solved.
+- **`shape-timeline.ts` (vertical DOM renderer) stays** as the embed default for the Verlauf tab. We add modes alongside it; we don't tear it out.
+- **`paliad.deadlines`, `paliad.appointments`, `paliad.project_events`, `paliad.deadline_rules`** schemas — unchanged. Zero migrations in this design.
+- **Color tokens (`--color-accent`, `--color-bg-lime-tint`, …)** — anchor every chart palette, light/dark mode + WCAG follow for free.
+
+### Out of scope (v1 of this feature)
+
+- **Cross-matter chart on `/projects` list page** — bundled under the Custom-Views path (§8.3) once `RenderShape="timeline"` lands. Not v1.
+- **Live collaborative cursors / annotation pins** — presentation features for a later phase, not for shipping the chart itself.
+- **Rich-text editing of chart entries from inside the chart canvas** — clicks deep-link to existing detail pages. Edit-in-place is the SmartTimeline's anchor affordance and stays there.
+- **Server-side PDF rendering via headless browser** — adding `chromedp` introduces a Chromium runtime dependency on the Dokploy compose host. Recommend client-side `window.print()` for v1; revisit only if user feedback says "PDFs differ across employees' browsers". See §7.3 for the trade-off in full.
+- **Theming UI for end users to pick palettes** — v1 gives a small fixed palette set; a colour-picker is v2 nice-to-have only if real users ask for it.
+
+---
+
+## 2. Renderer choice — SVG for the Gantt mode, DOM for the flow mode
+
+This is the load-bearing call. Five candidates surveyed:
+
+| Renderer | Pros | Cons | Fit |
+|---|---|---|---|
+| **DOM/CSS grid** (existing) | Accessible by default; themable via CSS vars; free dark-mode + i18n; exportable via `window.print()` | Hard to do continuous date-axis math (Gantt scaling); heavy reflow on resize; html-to-PNG via foreignObject is browser-quirky | Best for vertical flow ✓ |
+| **SVG hand-rolled** | Vector by construction → free SVG / PNG export via canvas drawImage; precise positioning math; one paint call; printable | Manual ARIA scaffolding; no automatic text-wrapping; need a layout pass | Best for horizontal Gantt ✓ |
+| **`<canvas>`** | Top performance for 1000+ nodes | Zero accessibility; manual hit-testing for clicks; export needs separate path | Overkill for our scale (≤150 nodes typical) ✗ |
+| **D3.js** | Battle-tested abstractions for axes / scales | ~250 KB minified, runtime data-driven DOM mutation conflicts with our IIFE-bundle pattern, would need m's package approval | Overkill, runtime cost ✗ |
+| **SVG + foreignObject for text** | Vector with native HTML text wrapping | Spotty PDF and Safari support; defeats the export-for-free pitch | Avoid ✗ |
+
+### 2.1 Recommendation
+
+**Two renderers coexist.** Same data, different DOM:
+
+- **`shape-timeline.ts`** (existing DOM/CSS grid, vertical) keeps powering the Verlauf-tab embed — it's small, accessible, themed.
+- **`shape-timeline-chart.ts`** (new SVG) powers the standalone `/projects/{id}/chart` page in horizontal Gantt mode. Hand-rolled, no library, ~500 LoC for v1.
+
+The horizontal Gantt page is also where the export buttons live (§7) — exporting a vertical DOM list is "open browser print and cmd-P" already, no new code needed; the Gantt is the genuinely new surface and brings PDF/SVG/PNG with it.
+
+### 2.2 Why hand-rolled SVG over D3
+
+We have ≤150 nodes per project, two axes (date + lane), three primitives (bar, dot, label) and one expanding need (zoom + pan, eventually). D3 ships ~250 KB to give us scales + axis generators + zoom. Our scale is `(date - earliestDate) / dayWidthPx`, a one-liner; our axis is a year/quarter tick generator, ~30 LoC; pan + zoom is `addEventListener("wheel"|"pointermove")`, ~50 LoC. The lift to write it ourselves is real but small, the runtime cost saving is real, and we keep the single-file IIFE bundle pattern intact.
+
+If we ever hit "the layout math is too painful to maintain", D3-only-the-axis-helper or an `axes.ts` module is a refactor we can do then. v1 ships without.
+
+### 2.3 What hand-rolled SVG looks like
+
+One root SVG element, three layered groups:
+
+```
+<svg viewBox="0 0 W H">
+  <defs>
+    <pattern id="weekend"…/>      # weekend background stripe
+    <linearGradient id="proj"…/>  # projected-row gradient
+  </defs>
+  <g class="chart-grid">          # lane separators + date-axis ticks + today rule
+  <g class="chart-bars">          # one rect/g per event
+  <g class="chart-labels">        # text labels (kind chip, title)
+  <g class="chart-overlay">       # tooltip + selection scrim
+</svg>
+```
+
+Coordinates are computed by a `layout(events, lanes, viewport)` pure function — testable, deterministic, the same on screen and on export.
+
+---
+
+## 3. Layout — vertical (existing) + horizontal (new)
+
+### 3.1 Vertical (DOM, existing — no changes)
+
+Embedded on `/projects/{id}` Verlauf tab. Today's `shape-timeline.ts` flow with date column / event card right column, "Heute →" rule, parallel tracks for CCR, lane-strip for parent-node aggregation. Nothing changes in this design — I'm explicit about that so the implementer doesn't accidentally rewrite working code.
+
+### 3.2 Horizontal Gantt-strip (SVG, new)
+
+The `/projects/{id}/chart` page. Time on the X axis, lanes on the Y axis. Each lane is a horizontal row; events plot as either a dot (point-in-time: deadline due-date, milestone, appointment) or a bar (range: future-projected sequence between two anchors, or appointment with end_at). Today's rule = vertical line.
+
+```
+                       ←──────── 2026 ────────→ 2027 ─────→
+               ┌────────────────────────────────────────┐
+   Self        │  ✓ ●─────●────────────● ░──░──░──░ │
+   Hauptverf.  │     Klage  Antw.       HV   R29a R29c   │
+               │                  ↑Heute                 │
+               ├────────────────────────────────────────┤
+   Widerklage  │                  ⊕──────░───░──░     │
+   (CCR)       │                  Filed   R29d R32  │
+               │                                          │
+               └────────────────────────────────────────┘
+   Date axis:    Q1   Q2   Q3   Q4   Q1   Q2   Q3
+                 │              │
+                 └ year border  └ Today rule (lime)
+```
+
+### 3.3 Layout invariants (both modes)
+
+These rules must hold across both renderers — they're the contract that lets us swap modes without surprising the user:
+
+1. **Past = left/below; Future = right/above; Today = lime separator.** Vertical: future at top per existing convention. Horizontal: future on right per Gantt convention. The convention flip is fine because the "today" lime separator orients the user instantly.
+2. **One row = one event** in vertical; **one bar/dot = one event** in horizontal. We never group two events into one mark. Lane (column in horizontal, parallel-track-column in vertical) is the only grouping primitive.
+3. **`Kind` drives shape / glyph; `Status` drives color saturation; `Track` drives column placement.** This composes orthogonally — see §5.
+
+### 3.4 Hybrid not in v1
+
+A "compact horizontal-strip-on-top + vertical-detail-below" hybrid (think Gmail conversation view but for matters) is a tempting third mode. **Not in v1** — adds a third renderer with no clear user request behind it. Revisit if a partner asks "I want both at once".
+
+### 3.5 Single-column vs multi-column on horizontal
+
+Multi-column = lanes, identical to the substrate's `LaneInfo` already. The horizontal Gantt **always multi-lanes** when there's more than one lane; collapsing all events into one row just to give a "single-column" version produces visual chaos with overlapping bars on the same date. The `[Track ▼]` filter (existing) lets the user collapse to a single track if they want a single-row view. So:
+
+- **Substrate has 1 lane** (Case-level, no CCR): single horizontal row.
+- **Substrate has 2+ lanes** (Case + CCR sub-project, OR Patent / Litigation / Client level): horizontal multi-lane Gantt with one row per lane.
+
+This mirrors the lane-mode the vertical renderer already uses (`renderLaneStrip`) — same data shape, different rendering.
+
+---
+
+## 4. Column model — extend `LaneInfo`, no new substrate concept
+
+The substrate already discriminates lanes via `levelPolicy(projectType)` returning `LaneAxis`. The chart inherits that vocabulary for free.
+
+### 4.1 What the chart adds
+
+Two read-only filters at chart mount time, both client-side (no backend changes):
+
+```ts
+interface ChartViewState {
+  layout:    "vertical" | "horizontal";  // default "horizontal" on /chart, "vertical" on Verlauf
+  columns:   "auto" | "single" | "lanes";  // "auto" reads lanes.length from substrate
+  density:   "compact" | "standard" | "spacious";
+  palette:   "default" | "high-contrast" | "print" | "kind-coded" | "track-coded";
+  zoom:      number;  // px-per-day; default 4
+  range?:    { from: string; to: string };  // ISO; defaults to substrate's earliest..latest+30d
+}
+```
+
+`columns="auto"` is the default — the substrate decides. `columns="single"` collapses everything into one row (useful when comparing dates across CCR + parent on horizontal). `columns="lanes"` forces lane mode even when only one lane exists (useful for screenshot consistency).
+
+### 4.2 What the chart does not add to the substrate
+
+**No new lane axis.** If the brief later wants "lanes per party" (claimant vs defendant) or "lanes per court country", that becomes a new `LaneAxis` value in `levelPolicy` — substrate work, not chart work. The chart is a render of whatever lanes the substrate produced.
+
+This boundary is important: the chart can be improved / re-skinned / re-renderered without touching the data layer, and substrate improvements (new lane axes, new event kinds) automatically reach both renderers.
+
+---
+
+## 5. Color schemes
+
+The brief asks for *"different colors even"*. Three palette dimensions are useful — and they're orthogonal, so a user picks one at a time.
+
+### 5.1 Palette presets (built-in, fixed)
+
+| Preset | What's color-coded by | Use case |
+|---|---|---|
+| **`default`** | Lane (`--color-accent` for parent, neutral grey for CCR/parent_context) | Embed in Verlauf, partner glance |
+| **`kind-coded`** | Event kind (deadline = blue, appointment = amber, milestone = lime, projected = soft-grey) | "Show me what's a hearing vs a deadline at a glance" |
+| **`track-coded`** | Track tag (parent / counterclaim / parent_context — three distinct hues) | CCR-heavy projects where the track is the most important axis |
+| **`high-contrast`** | Status only (done = green ✓; open = amber; overdue = red; predicted = light-grey) | Print-friendly, accessibility-first, screenshot for client |
+| **`print`** | Black / white / one-stripe-pattern (no color at all) | Faxable, b&w-printable, redactable |
+
+All five palettes are CSS custom-property *swaps* on the chart root — the renderer reads `var(--chart-bar-deadline)`, the palette CSS file defines what each is. No JS branching in the renderer.
+
+### 5.2 Token surface (CSS vars)
+
+```css
+.smart-timeline-chart {
+  --chart-bar-deadline:     var(--color-accent);
+  --chart-bar-appointment:  #f5a623;
+  --chart-bar-milestone:    var(--hlc-midnight);
+  --chart-bar-projected:    var(--color-text-subtle);
+  --chart-bar-overdue:      #d62828;
+
+  --chart-track-parent:           var(--color-accent);
+  --chart-track-counterclaim:     #6e8a8c;       /* desaturated teal */
+  --chart-track-parent-context:   var(--color-text-subtle);
+
+  --chart-today-rule:       var(--color-accent);
+  --chart-grid-line:        var(--color-border);
+  --chart-bg:               var(--color-bg);
+  --chart-bg-weekend:       var(--color-bg-subtle);
+}
+
+.smart-timeline-chart[data-palette="kind-coded"] {
+  /* override --chart-bar-* — track tokens stay neutral so kind dominates */
+  --chart-track-parent:        var(--color-text-subtle);
+  --chart-track-counterclaim:  var(--color-text-subtle);
+}
+
+.smart-timeline-chart[data-palette="print"] {
+  --chart-bar-deadline:    #000;
+  --chart-bar-appointment: #555;
+  --chart-bar-milestone:   #000;
+  --chart-bar-projected:   #aaa;
+  /* …and so on; the palette is a pure CSS swap */
+}
+```
+
+### 5.3 Why no per-user color picker in v1
+
+A per-user palette picker is a feature with a long tail (storage in user prefs, defaults vs overrides, migration when palette tokens change names, theme conflicts with light/dark). The fixed-preset surface answers 90 % of "I want different colors" with 10 % of the cost. If real users say "I want my-firm-blue", we add a v2 admin-level palette override (`paliad.firm_palette` row keyed by `FIRM_NAME`).
+
+### 5.4 Light / dark / print
+
+Existing dark-mode flip works automatically — the chart palette tokens *reference* `--color-*` family which is already dark-mode-aware. No extra surface. `@media print` overrides force the `print` palette regardless of the user-selected one — a print-out is always b&w-friendly.
+
+---
+
+## 6. Density + visual variants
+
+### 6.1 Density modes
+
+```ts
+type Density = "compact" | "standard" | "spacious";
+```
+
+- `compact`: lane height 24px, bar height 12px, label inline-only (no description). Use for "1000-row birds-eye" lane mode.
+- `standard` (default): lane height 40px, bar height 20px, label + status pill.
+- `spacious`: lane height 64px, bar height 28px, label + pill + description below.
+
+CSS-driven via `[data-density="…"]` on the chart root. The bar & dot SVG geometry is computed from a single `--lane-height` var; switching density is a re-layout pass, not a re-render.
+
+### 6.2 Status / kind / shape variants
+
+The visual encoding stays consistent with `shape-timeline.ts`:
+
+| Kind | Vertical glyph | Horizontal mark |
+|---|---|---|
+| `deadline` | `…` / `!` (open / overdue) | Filled circle on due date; ring around it for "open" |
+| `appointment` | `▢` | Bar from `start_at` to `end_at` (or fixed-width if same-day) |
+| `milestone` | `⊕` | Diamond at the date |
+| `projected` | `░` | Hatched circle (predicted), dashed-circle (court_set), amber-outlined (predicted_overdue) |
+
+Colour saturation drives `Status` independently: done = full color; open = lighter; predicted = 50% opacity; overdue = red overlay.
+
+The CSS for the vertical mode already has these variants — the SVG mode replicates them via `<circle>` / `<rect>` + `fill` / `stroke-dasharray` attributes. Same visual language across modes is a non-negotiable.
+
+---
+
+## 7. Export pipeline
+
+This is the most-requested part of the brief. Five formats; client-side only (no Go PDF dep, no headless browser).
+
+### 7.1 The five formats
+
+| Format | Content | Path | Why this path |
+|---|---|---|---|
+| **SVG** | Vector chart as-rendered | Browser: `new XMLSerializer().serializeToString(svgEl)` → Blob → download | Free — SVG IS our render. |
+| **PNG** | Raster chart at 2× device pixel ratio | Browser: SVG → `<img>` → `<canvas>.drawImage` → `canvas.toBlob()` | One stdlib API call chain. |
+| **PDF** | Print-formatted page | `window.print()` with `@media print` stylesheet; user picks "Save as PDF" | Reuses browser's hardened PDF engine — no Go PDF dep, no Chromium pinned to Dokploy. |
+| **CSV** | Tabular data, flat | Server: `GET /api/projects/{id}/timeline.csv` → text/csv | Cleanest for "Excel this" use case. |
+| **JSON** | Data-as-stored | Server: `GET /api/projects/{id}/timeline?format=json` (existing endpoint, alt content type) | Zero new code beyond a `Content-Disposition: attachment`. |
+| **iCal** | Deadlines + appointments as VEVENT | Server: `GET /api/projects/{id}/timeline.ics` reusing `caldav_ical.go` formatter | Lawyers can subscribe in Outlook / Apple Calendar. |
+
+### 7.2 Why client-side for SVG/PNG/PDF, server-side for CSV/JSON/iCal
+
+- **SVG/PNG/PDF need the rendered pixel layout.** Client has it, server doesn't (without a headless browser). Doing it on the client is a 30 LoC flow per format using stdlib browser APIs.
+- **CSV/JSON/iCal are pure data.** Server-side they hit the existing `ProjectionService` and stream straight to the client. CSV is `encoding/csv`; JSON is `json.Marshal`; iCal reuses the existing string-builder. Three new handlers, ~120 LoC total.
+
+### 7.3 Why NOT server-side PDF
+
+The clean alternative is "spin up `chromedp` on the Dokploy compose host, render the chart page, return PDF". Trade-off:
+
+- Pro: one canonical PDF render, works the same regardless of user's browser.
+- Con: adds a Chromium runtime dep to the paliad Docker image (~150 MB), spins up a child process per export, opens an attack surface (someone exports a hostile SVG → Chromium handles it → CVE), and needs a queue (PDF render is 1-3s; a clicky user can DoS the box).
+
+Browser print, by contrast, is in-process, free, sandboxed, and produces fine-looking PDFs. It loses pixel-perfect cross-browser parity, but lawyers care about content, not subpixel kerning.
+
+**Recommend client-side print for v1.** Revisit if lawyers complain about cross-browser PDF differences. Adding `chromedp` later is a one-PR move; designing it into v1 risks shipping infra weight we may never need.
+
+### 7.4 Print-mode CSS
+
+The PDF path needs a robust `@media print`:
+
+- Fix the chart to fit on landscape A4 (1100 × 760 px viewport).
+- Force `palette="print"`.
+- Hide chrome (sidebar, footer, header → `.print-hide` class on existing layout).
+- Show project metadata (title, parties, court, proceeding type) as a printed header.
+- Page-break logic: each lane group fits on one page; if a lane has too many events, split horizontally by year.
+
+This print stylesheet can be extracted as `frontend/src/styles/chart-print.css` so it's auditable separately from the screen styles.
+
+### 7.5 Export menu UI
+
+Single button on the chart page header opens a menu:
+
+```
+[ ⤓ Export ▼ ]
+   ├─ SVG (Vektorgrafik)
+   ├─ PNG (Bild, 2× HiDPI)
+   ├─ PDF (Drucken)
+   ├─ ───
+   ├─ CSV (Excel-Tabelle)
+   ├─ JSON (Rohdaten)
+   └─ iCal (.ics — Outlook / Apple)
+```
+
+Translated via existing i18n (`projects.detail.chart.export.*`). One menu, one keyboard shortcut (`Cmd+E` / `Ctrl+E`) opens it.
+
+### 7.6 What's exported in CSV
+
+Flat schema, one row per `TimelineEvent`:
+
+```
+project_id,project_title,kind,status,track,lane_id,lane_label,date,
+title,description,rule_code,depends_on_rule_code,depends_on_date,
+sub_project_id,sub_project_title,bubble_up,deadline_id,appointment_id,
+project_event_id
+```
+
+Columns mirror the wire `TimelineEvent` struct. UTF-8 with BOM (Excel-DE compat). Date format ISO-8601.
+
+### 7.7 What's exported in JSON
+
+The wire `ResponseEnvelope` directly: `{events: TimelineEvent[], lanes: LaneInfo[], meta: ProjectionMeta, exported_at, exported_by, project_id}`. Stable JSON schema; `meta` lets a future re-importer reconstruct the projection state exactly.
+
+### 7.8 What's exported in iCal
+
+Only `kind IN ("deadline", "appointment")` (projected rows are not stable enough to commit to a calendar). VEVENT block per row reuses `caldav_ical.go` formatter; UID is `paliad-deadline-<id>@paliad.de` so re-export overwrites prior subscription. Future projected rows omitted by design — they would clutter every lawyer's Outlook with rule_code-derived events that may or may not fire on the predicted date.
+
+---
+
+## 8. Surfaces — three places the chart shows up
+
+### 8.1 Verlauf tab embed (`/projects/{id}` — existing)
+
+Vertical DOM mode only (existing `shape-timeline.ts`). Density `standard`. Palette `default`. Lane count obeys substrate. **No changes** in this design — the embed stays exactly as it is. The chart-mode opt-in lives below the tab.
+
+A new "**Als Chart anzeigen ↗**" link in the SmartTimeline header opens `/projects/{id}/chart` in a new tab. Optionally (Q3 below) we could host a chart inline with a `[Layout: ▽ Vertikal | ▷ Horizontal]` toggle.
+
+### 8.2 Standalone `/projects/{id}/chart` (new)
+
+Full-page surface optimized for the horizontal SVG renderer. Layout:
+
+```
+┌───────────────────────────────────────────────────────────────────────┐
+│ Siemens AG ./. Huawei — EP3456789 — UPC-CFI München                  │
+│ Verfahrenstyp: UPC-Verletzung   Anker: Klageschrift @ 2026-04-29     │
+│                                                                       │
+│ [Layout ▷] [Spalten Auto] [Dichte Standard] [Palette Default] [Export ⤓]│
+├───────────────────────────────────────────────────────────────────────┤
+│ ━━━━ FilterBar (existing primitive) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ │
+├───────────────────────────────────────────────────────────────────────┤
+│                                                                       │
+│             ┌──── Horizontal SVG chart (full bleed) ───┐              │
+│             │                                          │              │
+│             │     ←─── 2026 ────→ 2027 ────→            │              │
+│             │  Self  ●─●───●──── ░──░──░                │              │
+│             │  CCR     ⊕────░───░──░                    │              │
+│             │                                          │              │
+│             └──────────────────────────────────────────┘              │
+│                                                                       │
+└───────────────────────────────────────────────────────────────────────┘
+```
+
+URL convention: `/projects/{id}/chart?layout=horizontal&palette=default&density=standard&zoom=4`. State persists in URL so the link is shareable and copy-pasteable. localStorage caches the last chosen state per user as the default.
+
+### 8.3 Custom Views shape (`shape="timeline"`)
+
+Registers `ShapeTimeline RenderShape = "timeline"` in `internal/services/render_spec.go` and adds a corresponding `frontend/src/client/views/shape-timeline-chart.ts` view-host wrapper that adapts a `ViewRow[]` → `TimelineEvent[]` array. This unlocks **cross-project timelines** as a Custom View — "all my UPC matters" or "everything where I'm in the team" rendered as one chart.
+
+ViewRow → TimelineEvent is a lossy shim: `kind` and `track` map directly; `date` reuses `event_date`; cross-project lanes are auto-derived from `project_id`. Projected rows are not surfaced from `ViewService` (it doesn't run the calculator) — Custom Views show actuals only. We document that limitation, ship the shape, and revisit later if needed.
+
+This is **§8.3's gating**: the standalone page (§8.2) and embed (§8.1) ship before the Custom Views shape. The shape is Slice 4 — last, optional, lower-priority.
+
+---
+
+## 9. Mobile behaviour
+
+Three breakpoints, one rule:
+
+| Width | Vertical embed | Standalone chart |
+|---|---|---|
+| ≥1024 px (desktop) | Existing | Horizontal SVG, full-bleed |
+| 640–1023 px (tablet) | Existing | Horizontal SVG, narrower viewport, density auto-switches to compact |
+| <640 px (phone) | Existing | **Force vertical** — horizontal Gantt on phone is unreadable |
+
+The "force vertical on phone" rule is enforced server-side via the Accept-CH `Sec-CH-UA-Mobile` header (defensive) and client-side via `window.matchMedia("(max-width: 640px)")`. The user can override but the default flips.
+
+A horizontal-on-phone variant with `overflow-x: scroll` is technically possible but UX-poor — date axis disappears off-screen, lawyer can't see context. Force vertical, force collapsing of lanes into stacked sections, keep the export menu reachable.
+
+---
+
+## 10. Performance
+
+### 10.1 Current numbers
+
+- Patent (5 child cases × 30 events) = 150 nodes typical
+- Client (100+ matters) = 100s of lane rows; aggregation already sub-filters to milestones-only at Client level → <500 nodes
+- Backend projection cost: ~285 ms cold cache for one project (per t-paliad-169 §13). Backend is not the bottleneck.
+
+### 10.2 Where each renderer caps
+
+| Renderer | Comfortable | Stressed | Breaks |
+|---|---|---|---|
+| DOM grid (vertical) | ≤300 nodes | 300-1000 (sluggish reflow) | 1000+ (frame drops on scroll) |
+| Hand-rolled SVG | ≤1000 nodes | 1000-3000 (slow zoom / pan) | 3000+ (paint cost) |
+| Canvas (not chosen) | ≤10 000 nodes | — | — |
+
+We're sitting in the **comfortable band for both** for any plausible Paliad project. Numbers above 1000 happen only in pathological "show all my Client's matters" scenarios — and those are bound by levelPolicy aggregation already (Client-level Custom Views).
+
+### 10.3 Mitigations if a real project exceeds the comfort zone
+
+- **Lookahead cap** (existing): `?lookahead=N` keeps projected nodes capped at 7 by default (50 max). Future-only, doesn't help if there are 1000 actuals.
+- **Date-range filter**: chart shows only events in a date window (defaults `earliest..latest+30d` — no implicit cap). For pathological cases, user can narrow the range.
+- **Lane filter** (existing): hide / dim selected lanes on multi-lane render.
+
+If a single matter genuinely has 1000+ actuals, the user has a deeper data-discipline problem and the right answer is to escalate, not to optimize a chart for it.
+
+### 10.4 SVG paint budget
+
+A 200-event chart in horizontal mode is ~600 SVG primitives (200 bars/dots × 3 elements: shape + label + tooltip-trigger). One initial paint = <50 ms on a low-end laptop. Subsequent zoom / pan re-runs the layout fn (10 ms) and re-attributes existing nodes (no re-create) — fast. We do not need virtualization in v1.
+
+---
+
+## 11. Phasing — 4 sequential slices
+
+Each slice independently shippable. m's go/no-go gate after each.
+
+### Slice 1 — Standalone `/projects/{id}/chart` page + horizontal SVG renderer (no exports yet)
+
+What lands:
+
+- New page route `GET /projects/{id}/chart` (handler `internal/handlers/chart_pages.go`, ~50 LoC). Reuses existing project gate.
+- New `frontend/src/projects-chart.tsx` page TSX (renders shell + mount target). ~100 LoC.
+- New `frontend/src/client/views/shape-timeline-chart.ts` SVG renderer (~500 LoC). Pure-function `layout(events, lanes, viewport)` + `paint(layout, palette, root)`.
+- Reuses the existing `GET /api/projects/{id}/timeline` endpoint — no backend change.
+- Mode toggle on Verlauf tab: `[Als Chart anzeigen ↗]` link → opens `/chart`.
+- Default palette + standard density + auto columns. **No** export, **no** palette picker, **no** density picker yet — controls render as inert chips.
+
+What it gives m: the horizontal Gantt rendering, end-to-end. Lawyer can open `/chart`, see the matter in horizontal layout, share the URL.
+
+### Slice 2 — Export pipeline (SVG / PNG / PDF / CSV / JSON / iCal)
+
+What lands:
+
+- Client-side: `frontend/src/client/views/chart-export.ts` (~150 LoC) handling SVG → PNG conversion, PDF print invocation, blob downloads. Three new i18n keys per format.
+- Server-side: `internal/handlers/projection.go` gains 3 new handlers — `handleProjectTimelineCSV`, `handleProjectTimelineJSON` (alt `?format=json` on existing), `handleProjectTimelineICS`. Each ~30 LoC.
+- New `frontend/src/styles/chart-print.css` for `@media print` and palette swap.
+- Export menu UI on chart page header.
+
+What it gives m: every export format the brief asked for, no infra additions, lawyer-shareable PDFs.
+
+### Slice 3 — Density + palette + zoom controls
+
+What lands:
+
+- Density toggle (`compact / standard / spacious`) — pure CSS-var + `[data-density]` attr swap, no re-fetch.
+- Palette picker (`default / kind-coded / track-coded / high-contrast / print`) — same pattern.
+- Zoom in / out controls + pan (mousewheel + drag).
+- Date-range narrower (FilterBar `time` axis already exists — wire it to chart viewport).
+- localStorage persistence per-user-per-project.
+
+What it gives m: full visual customisation per the brief.
+
+### Slice 4 — Custom Views integration (`shape="timeline"`)
+
+What lands:
+
+- Register `ShapeTimeline RenderShape = "timeline"` in `internal/services/render_spec.go` + validator.
+- New `frontend/src/client/views/shape-timeline-cv.ts` view-host adapter. Reuses Slice 1's renderer; adapts `ViewRow[]` to `TimelineEvent[]`.
+- `frontend/src/views.tsx` shape-switcher gets the 4th button.
+- Documented limitation: projected rows not surfaced in Custom Views.
+
+What it gives m: "all my UPC matters as one chart" via Custom Views — cross-project chart on the existing CV substrate.
+
+### What's NOT in any slice (v2 nice-to-haves)
+
+- Per-user palette picker beyond fixed presets.
+- Server-side PDF render via `chromedp`.
+- Live collaborative cursors / annotation pins.
+- Animation / transitions when zoom changes.
+- Hybrid layouts (compact-strip + detail-list).
+- Color-coding with custom user-defined rules.
+
+---
+
+## 12. Files implementer will touch (Slice 1 only)
+
+**Backend (Go):**
+- `internal/handlers/chart_pages.go` — new, ~50 LoC. `handleProjectChartPage(w, r)` returns the rendered TSX shell. Auth + project visibility gates as on `/projects/{id}`.
+- `internal/handlers/handlers.go` — register `GET /projects/{id}/chart`.
+
+**Frontend (TS / TSX):**
+- `frontend/src/projects-chart.tsx` — new, ~100 LoC. Page shell with mount target + page-level controls scaffold (chips inert in Slice 1).
+- `frontend/src/client/views/shape-timeline-chart.ts` — new, ~500 LoC. SVG renderer:
+  - `layout(events: TimelineEvent[], lanes: LaneInfo[], viewport: Viewport): ChartLayout` — pure function returning bar/dot positions + axis ticks + today-rule x.
+  - `paint(layout: ChartLayout, palette: Palette, root: SVGSVGElement): void` — DOM-mutates the root.
+  - `mount(host: HTMLElement, opts: ChartMountOpts): ChartHandle` — composes layout + paint + interaction (click → deep-link, hover → tooltip).
+- `frontend/src/client/projects-chart.ts` — new, ~150 LoC. Page boot: fetch `/api/projects/{id}/timeline`, mount renderer, wire URL state ↔ control chips (inert), wire SmartTimeline embed's `[Als Chart anzeigen ↗]` link from `frontend/src/client/projects-detail.ts`.
+- `frontend/src/styles/global.css` — `.smart-timeline-chart-*` CSS additions, ~120 LoC. Including the palette token swap CSS but not yet wired to a picker.
+- `frontend/src/client/i18n.ts` — ~25 keys under `projects.detail.chart.*` (page title, control labels, default-palette-name, etc.) DE+EN.
+- `frontend/build.ts` — register the new page bundle.
+
+**Tests:**
+- `frontend/src/client/views/shape-timeline-chart.test.ts` — new, pure-function tests for `layout()` (ranges, tick generation, lane stacking, today-rule positioning, undated-row handling).
+
+Slices 2-4 are scoped in §11; coder picks them up after m's gate.
+
+---
+
+## 13. Trade-offs flagged
+
+- **SVG accessibility.** Hand-rolled SVG needs explicit ARIA scaffolding (`role="img"` + `<title>` + `<desc>` per group, `aria-label` per event mark) to be screen-reader-readable. This is real implementation work — DOM mode gets it for free. Mitigation: lockdown `role` and label conventions in the renderer and test with VoiceOver / NVDA before Slice 1 merges.
+- **Print-CSS quirks.** `window.print()` PDFs will look slightly different across Chrome / Safari / Firefox. Lawyers comparing two exports may notice. Mitigation: documentation states "use Chrome for archival exports". Pursue chromedp only if real complaints surface.
+- **No virtualization in v1.** A 1000-event chart is not virtualized — every node is in the DOM/SVG tree. Mitigation: existing levelPolicy aggregation + lookahead caps keep node counts bounded for plausible projects. Add virtualization only if a real project exceeds the comfort band.
+- **Two renderers means two paths to maintain.** A bug in vertical-mode rendering doesn't auto-fix the horizontal mode. Mitigation: both render the **same** `TimelineEvent` / `LaneInfo` data; the discriminator is just the layout fn. Rendering bugs tend to be in shared event-mark visual tokens (color, status pill) which CSS-token-swap centralizes anyway.
+- **Custom Views adapter is lossy.** Cross-project chart in CV doesn't show projected rows. Some users might expect them. Mitigation: in-page tooltip on first CV-chart open: "Custom Views show actual events only. Open the project's `/chart` for projected rules." A future v2 could push the projection through ViewService but the substrate redesign is non-trivial.
+- **Date-range default.** Defaulting to `earliest_event..latest_event+30d` means a matter with one ancient deadline forces the whole span on every render. Mitigation: clamp default range to `today-1y..today+1y`, with a chip for "Alles anzeigen" to expand. Keeps the typical render compact.
+- **`/chart` URL collision.** `/projects/{id}/chart` doesn't conflict with any existing route, but adding `/chart` at the project level forces the route table to stay tidy. Defensive: implementer greps `internal/handlers/handlers.go` before adding to confirm no collision.
+- **Browser-print PDF on Safari shows the menu bar.** Cosmetic; print stylesheet's `@page` directive helps, but Safari ignores some rules. Mitigation: documentation; lawyer-facing exports recommend Chrome.
+
+---
+
+## 14. Open questions for m
+
+Listed with my (inventor) pick where I have one — m decides.
+
+**Q1 — Default landing on `/projects/{id}/chart`: horizontal Gantt or vertical (with a toggle)?**
+My pick: horizontal Gantt as the default. The whole reason `/chart` exists is the horizontal mode; defaulting to vertical would make it a duplicate of Verlauf. Add a `[Layout ▷|▽]` toggle for users who want vertical-on-bigscreen.
+
+**Q2 — Should the chart page replace Verlauf when accessed at desktop width, or stay a separate URL?**
+My pick: separate URL. Verlauf is the "scan & action" tab (click rows to mark deadlines done, add notes). Chart is the "share & overview" surface. Conflating them risks losing the inline-action affordance Verlauf was built for.
+
+**Q3 — Should the chart be embeddable inside the Verlauf tab (with a layout toggle), or only standalone?**
+My pick: standalone in Slice 1; if user feedback says "I want to see horizontal on the project page directly", add the embed in a follow-up slice. Embedding doubles render cost on every project page open and creates layout pressure on the existing tab UI.
+
+**Q4 — Chromedp / server-side PDF: rule out for v1, or design in?**
+My pick: rule out. Browser-print PDFs are good enough; Chromium-on-Dokploy is a heavy dep. Keep the door open by abstracting the export-button handler so a future server-side path is a one-route addition.
+
+**Q5 — Color palette presets: ship the full 5 in Slice 3, or just `default` + `print` for safety?**
+My pick: ship all 5. The palette mechanism is just CSS-var swaps; adding the other three is hours of design polish, not weeks of work. More options give more lawyers their preferred read.
+
+**Q6 — iCal export: only deadlines + appointments (recommendation), or include projected too?**
+My pick: only deadlines + appointments. Subscribing to a calendar that fills with rule_code-derived predicted dates that never fire would erode trust. Future projected = visualisation only, never calendar artifacts.
+
+**Q7 — Custom Views integration (`shape="timeline"`): Slice 4 priority, or descope?**
+My pick: keep as Slice 4 but explicit go/no-go after Slice 3 ships. The cross-project chart is a *cool* demo but not in the original brief — descoping if real users haven't asked is fine.
+
+**Q8 — Date-range default on `/chart`: data-driven (`earliest..latest+30d`) or fixed (`today-1y..today+1y`)?**
+My pick: fixed `today-1y..today+1y`, with a chip "Alles anzeigen" expanding. Old matters with one historical deadline shouldn't force a 5-year span on first render.
+
+**Q9 — Should the chart support project comparison (chart 2-3 projects side-by-side)?**
+My pick: no — out of scope for this feature. That's a Custom Views job (multi-project query → chart shape), not a per-project surface concern.
+
+**Q10 — Should we expose a permalink that captures *zoom + range + palette + density + lane-filter*?**
+My pick: yes, via URL query params (already designed in §8.2). Sharing a chart-URL via WhatsApp / email then renders the same view for the recipient.
+
+**Q11 — Mobile: vertical-only fallback, or horizontal-with-scroll?**
+My pick: vertical-only on phones (<640px). Horizontal-with-scroll loses the date axis off-screen. Tablet (640-1023px) keeps horizontal in compact density.
+
+**Q12 — On the SmartTimeline (Verlauf embed), do we also add an inline horizontal mode (Q3 follow-up)?**
+My pick: NO in v1. The standalone `/chart` is the new surface; Verlauf stays vertical. Adding both modes inline-Verlauf doubles the test matrix without clear user demand yet.
+
+---
+
+## 15. Recommendation for implementer
+
+Pattern-fluent Sonnet coder. Slice 1 is the heaviest (new SVG renderer, new page, new TSX shell). Slice 2 needs careful CSS print-mode tuning — best paired with browser-screenshot iteration. Slice 3 is mostly CSS-token plumbing + UI controls. Slice 4 is the lightest if Slice 1 left the renderer well-decomposed.
+
+Before Slice 1, the coder should sketch the `layout(events, lanes, viewport)` function on paper / a tests file — that's where the math lives, and getting it right deterministically is the difference between "works" and "subtle render glitches in obscure date ranges". Pure-function with table-driven tests for `layout()` is the correct approach.
+
+Faraday (this worktree) parks. Not pre-emptively flipping to coder — m gates.
+
+---
+
+**DESIGN READY FOR REVIEW**

docs/design-project-metadata-rework-2026-05-20.md

@@ -0,0 +1,686 @@
+# Project metadata rework — Client Role + auto-derived project codes
+
+Status: design, ready for head review (2026-05-20)
+Task: t-paliad-222
+Issues: m/paliad#47 (Client Role) + m/paliad#50 (project codes)
+Branch: `mai/kepler/inventorcoder-project`
+
+Pairs two related changes because both touch `paliad.projects` schema, the
+project form, and downstream consumers (Fristenrechner Determinator,
+submission templates, Verlauf, picker / breadcrumb surfaces). One design,
+two migrations, one coder shift.
+
+---
+
+## §1 Scope & non-goals
+
+In scope:
+
+- Drop "Wir vertreten" entirely on `type='client'`, `'litigation'`, `'patent'`.
+- Rename to "Client Role" / "Mandantenrolle" on `type='case'` with new
+  option set (Active / Reactive / Third Party / Other).
+- Widen `paliad.projects.our_side` CHECK to the new sub-role values; drop
+  `'court'` and `'both'`; backfill existing rows to NULL.
+- Add `paliad.projects.opponent_code text` on `type='litigation'` rows
+  (segment source for project codes).
+- New Go helper `services.BuildProjectCode(ctx, projectID) (string, error)`
+  that walks the ancestor chain via the existing ltree `path` and assembles
+  the dotted code. Custom `paliad.projects.reference` on the project itself
+  wins.
+- Wire the helper into project header, breadcrumb, picker labels, the
+  submission-template variable bag (`{{project.code}}`), and the Excel
+  export `__meta` sheet.
+
+Out of scope (handled separately or dropped):
+
+- Reshaping `paliad.parties` (per-party role rows are unchanged).
+- New analytics / reports breaking out sub-roles.
+- Bulk-renaming user-facing copy that says "Klägerseite" /
+  "Beklagtenseite" outside the project form.
+- Reverse lookup (project by code) — already works via `reference`.
+- Audit-history for who changed an override and when — not requested.
+- Bulk regeneration of existing `reference` strings — manual entries stay
+  intact; auto-derive only fills empty slots.
+- Renaming the `our_side` DB column — see §2.2 / Q1.
+
+---
+
+## §2 Issue #47 — Client Role rework
+
+### §2.1 Current state (verified 2026-05-20)
+
+- Column: `paliad.projects.our_side text`, CHECK constraint
+  `projects_our_side_check` allows `('claimant','defendant','court','both',NULL)`
+  (mig 072).
+- Live data audit (`SELECT our_side, count(*) FROM paliad.projects
+  GROUP BY our_side`): **all 12 rows are NULL**. Zero rows on
+  `'court'` or `'both'` — backfill is a no-op. The migration is risk-free
+  on the current dataset.
+- Form: rendered for every project type by
+  `frontend/src/components/ProjectFormFields.tsx:156-168` (one
+  `<select id="project-our-side">` with five static `<option>`s, no
+  conditional render).
+- Downstream consumers (verified by grep on `our_side` /
+  `OurSide` in `internal/` and `frontend/src/`):
+  - `frontend/src/client/fristenrechner.ts:2187,2734,3754-3776` —
+    Determinator Slice 3c, `ourSideToPerspective()` maps
+    `claimant → claimant`, `defendant → defendant`, anything else
+    (incl. `'court'`, `'both'`, NULL) → `null` (chip free-pick).
+  - `internal/services/submission_vars.go:276-278,390-418` —
+    `{{project.our_side_de}}` / `_en` legal-prose forms. `ourSideDE` /
+    `ourSideEN` switch on the 4 enum values.
+  - `internal/services/project_service.go:1083-1104` —
+    `our_side_changed` project-event row on writes.
+  - `internal/services/project_service.go:1228,1372,1955-` — CCR
+    counterclaim child default-inverts `our_side`; `nullableOurSide()`
+    and `isValidOurSide()` (`project_service.go:1915`) gate writes.
+
+### §2.2 Decisions
+
+**Q1 — Rename column `our_side → client_role`?**
+**Pick: NO. Keep `our_side`.** Renaming forces churn in eleven Go files,
+the Determinator client bundle (`fristenrechner.ts` type literal +
+`ourSideToPerspective`), all submission-template tests
+(`submission_render_test.go:275`), the project-event title key
+(`event.title.our_side_changed`), and every `{{project.our_side*}}` template
+that exists in the wild on user systems. The label is purely UI; the column
+name is internal. Future grep stays clean because the new label
+("Client Role") and the column (`our_side`) describe the same concept from
+different perspectives ("which side the firm represents" =
+"what role the client plays"). Keeping the column avoids a 200-line
+mechanical rename with non-trivial risk for zero functional gain. The
+i18n keys *do* rename (`projects.field.our_side` → `projects.field.client_role`)
+so user-facing copy stays clean.
+
+**Q2 — Sub-role granularity (7 distinct values vs 3 groups)?**
+**Pick: 7 sub-roles** — `claimant, defendant, applicant, appellant,
+respondent, third_party, other`. Lawyers care about the specific
+procedural posture; Applicant ≠ Claimant in some UPC contexts (e.g. PI
+applications use "Applicant"). Group-level aggregation is trivial at
+display time (`switch role { case claimant, applicant, appellant:
+return "Active" }`). Storing the group only would be a lossy choice we
+cannot reconstruct from.
+
+**Q3 — Project types where the field is visible?**
+**Pick: ONLY `type='case'`.** m's wording is unambiguous ("only plays a
+role in case projects — and even there the question should be 'Client
+Role'"). Hide on `client`, `litigation`, `patent`, and the generic
+`project` type. The client-level "industry / country" block stays as is
+(those are client-attributes, not procedural roles). The form already
+has `projekt-fields-case` conditional render (`ProjectFormFields.tsx:143`)
+— moving the role select into that block is a 4-line change.
+
+**Q4 — Existing `'court'` / `'both'` row backfill?**
+**Pick: backfill to NULL** in the same migration that widens the CHECK.
+Zero rows in production (verified 2026-05-20), so the backfill is a
+no-op today; it's there for safety if any test fixture or
+not-yet-deployed instance has them. No audit-event emission for the
+backfill (it's schema cleanup, not user action).
+
+**Q5 — Determinator perspective mapping for new sub-roles?**
+**Pick: Active group → `claimant`, Reactive group → `defendant`, Third
+Party / Other → `null` (chip free-pick).** Concretely:
+
+  - `claimant`, `applicant`, `appellant` → perspective `'claimant'`
+  - `defendant`, `respondent` → perspective `'defendant'`
+  - `third_party`, `other`, NULL → perspective `null`
+
+This keeps the Determinator's existing claimant-rule / defendant-rule
+filter logic unchanged; only `ourSideToPerspective()`'s switch widens.
+
+**Q6 — Submission template `_de` / `_en` prose for new sub-roles?**
+
+| value         | `_de` (Nominativ)             | `_en`         |
+|---------------|-------------------------------|---------------|
+| `claimant`    | Klägerin                      | Claimant      |
+| `defendant`   | Beklagte                      | Defendant     |
+| `applicant`   | Antragstellerin               | Applicant     |
+| `appellant`   | Berufungsklägerin             | Appellant     |
+| `respondent`  | Antragsgegnerin               | Respondent    |
+| `third_party` | Streithelferin                | Third Party   |
+| `other`       | sonstige Verfahrensbeteiligte | other party   |
+
+Existing `'court'`/`'both'` switch arms get deleted (no live rows; if a
+stale `our_side='court'` slipped through somehow, the function returns
+`""` — same fallback as today for unknown values).
+
+### §2.3 Migration `112_client_role_rework`
+
+```sql
+-- 112_client_role_rework.up.sql (renumbered 2026-05-20 — mig 110 was claimed by m/paliad#51, mig 111 by m/paliad#48)
+-- t-paliad-222 / m/paliad#47.
+-- Widens projects.our_side CHECK to seven sub-role values and drops
+-- the legacy 'court' / 'both' entries. Backfill is a no-op on the
+-- current dataset (verified 2026-05-20: all 12 rows are NULL), but
+-- runs defensively in case any test fixture / staging instance still
+-- carries the old values.
+
+BEGIN;
+
+-- 1. Backfill any 'court' / 'both' rows to NULL. Idempotent.
+UPDATE paliad.projects
+   SET our_side = NULL
+ WHERE our_side IN ('court', 'both');
+
+-- 2. Drop the old CHECK, add the widened one. Both are idempotent
+--    against partially-applied state.
+ALTER TABLE paliad.projects
+    DROP CONSTRAINT IF EXISTS projects_our_side_check;
+
+ALTER TABLE paliad.projects
+    ADD CONSTRAINT projects_our_side_check
+    CHECK (our_side IS NULL OR our_side IN (
+        'claimant', 'defendant',
+        'applicant', 'appellant',
+        'respondent',
+        'third_party', 'other'
+    ));
+
+COMMENT ON COLUMN paliad.projects.our_side IS
+    'Which side the firm represents on this case project (renamed in '
+    'the UI to "Client Role" — t-paliad-222 / m/paliad#47). Allowed '
+    'sub-roles, grouped at display time: Active (claimant, applicant, '
+    'appellant); Reactive (defendant, respondent); Third Party / Other '
+    '(third_party, other). NULL = unknown. Hidden in the form on '
+    'non-case project types. Drives the Fristenrechner Determinator '
+    'perspective chip (Active→claimant, Reactive→defendant, else null).';
+
+COMMIT;
+```
+
+The down migration restores the original 4-value CHECK and, for
+defensive symmetry, backfills any new sub-role values to NULL (so the
+schema is internally consistent when stepped down).
+
+### §2.4 Frontend changes
+
+`frontend/src/components/ProjectFormFields.tsx`:
+
+1. Move the `<div className="form-field">` containing
+   `#project-our-side` from the always-visible block (line 156) into
+   the `projekt-fields-case` block (after the court / case-number
+   row).
+2. Rename label `data-i18n="projects.field.our_side"` →
+   `projects.field.client_role`.
+3. Replace the five flat `<option>`s with three `<optgroup>`s + the
+   seven new options + an "Unbekannt" empty option.
+4. Update the hint text to mention the Determinator group mapping
+   (Active/Reactive).
+
+`frontend/src/client/i18n.ts` — add new keys (DE + EN):
+
+```
+projects.field.client_role                  → "Mandantenrolle" / "Client Role"
+projects.field.client_role.hint             → "..."
+projects.field.client_role.unset            → "Unbekannt" / "Unknown"
+projects.field.client_role.group.active     → "Aktiv (wir greifen an)"  / "Active (we initiate)"
+projects.field.client_role.group.reactive   → "Reaktiv (wir verteidigen)" / "Reactive (we defend)"
+projects.field.client_role.group.other      → "Dritte / Sonstige"        / "Third Party / Other"
+projects.field.client_role.claimant         → "Klägerseite"              / "Claimant"
+projects.field.client_role.applicant        → "Antragsteller"            / "Applicant"
+projects.field.client_role.appellant        → "Berufungsführer"          / "Appellant"
+projects.field.client_role.defendant        → "Beklagtenseite"           / "Defendant"
+projects.field.client_role.respondent       → "Antragsgegner"            / "Respondent"
+projects.field.client_role.third_party      → "Streithelfer / Dritter"   / "Third Party"
+projects.field.client_role.other            → "Sonstige Beteiligte"      / "Other party"
+```
+
+The legacy `projects.field.our_side.*` keys stay deprecated-but-present
+for one release so any cached browser bundle keeps rendering. They get
+deleted in a follow-up housekeeping shift once the rollout is confirmed.
+
+`frontend/src/client/project-form.ts:182-230` — adjust the payload
+read/write to only include `our_side` when the field is in the DOM
+(non-case forms no longer emit it). The current code does
+`if (v) payload.our_side = v` which already handles the "field absent"
+case gracefully (osSel becomes `null`, no payload key set).
+
+`frontend/src/client/fristenrechner.ts:3754-3776` —
+`ourSideToPerspective` switch widens:
+
+```ts
+function ourSideToPerspective(os: string | null | undefined): Perspective {
+  switch (os) {
+    case "claimant":
+    case "applicant":
+    case "appellant":
+      return "claimant";
+    case "defendant":
+    case "respondent":
+      return "defendant";
+    default:
+      return null;
+  }
+}
+```
+
+`frontend/src/projects-detail.tsx` Verlauf — the `our_side_changed`
+event description currently renders the raw enum. Update the renderer
+to use a label lookup so "Mandant: Beklagte → Antragsteller" reads
+correctly. Same `event.title.our_side_changed` key stays (the *title*
+is "Vertretene Seite geändert" / "Represented side changed", which is
+still accurate semantically).
+
+### §2.5 Backend changes
+
+`internal/services/project_service.go:1915` — `isValidOurSide()` widens
+its allowlist:
+
+```go
+case "", "claimant", "defendant",
+    "applicant", "appellant",
+    "respondent",
+    "third_party", "other":
+    return nil
+```
+
+`internal/services/project_service.go:1372` —
+`derivedCounterclaimOurSide()` (CCR flip logic): widen the flip map to
+mirror the Determinator grouping:
+
+  - claimant ↔ defendant (current behaviour)
+  - applicant ↔ respondent
+  - appellant → defendant (CCR against an appellant is rare; pick
+    the most-likely procedural posture; can be overridden by
+    explicit `flip_our_side=false`)
+  - third_party / other / NULL → keep as-is (no flip)
+
+`internal/services/submission_vars.go:391-418` — `ourSideDE` /
+`ourSideEN` switch arms add the five new values per the table in
+§2.2 Q6. `'court'` and `'both'` arms get deleted.
+
+`internal/services/project_service.go:1083-1104` — `our_side_changed`
+audit emission unchanged (it just records old → new on the column).
+
+`frontend/build.ts` — no change; bundling already picks up
+`projects.field.client_role.*` i18n keys via `i18n-keys.ts` regeneration.
+
+`frontend/src/i18n-keys.ts` — regenerate via existing scripted path
+(adds the new keys, keeps the legacy ones as deprecated entries until
+the housekeeping pass).
+
+### §2.6 Tests
+
+- `internal/services/submission_render_test.go:275` —
+  `TestOurSideTranslations` widens the table to cover the 7 new values
+  in both DE and EN.
+- `internal/services/projection_service_unit_test.go:319` —
+  `TestDerivedCounterclaimOurSide` widens to cover the new flip map.
+- New: `TestProjectFormHidesOurSideForNonCase` — unit test on the
+  project-form payload reader confirms `our_side` is silently dropped
+  when the form renders for a non-case project type.
+
+### §2.7 Acceptance (issue #47)
+
+- [x] Creating a project of `type='client'`, `'litigation'`, `'patent'`,
+      `'project'` does **not** show the field.
+- [x] Creating a project of `type='case'` shows the field labelled
+      "Mandantenrolle" (DE) / "Client Role" (EN) with three optgroups
+      and seven options.
+- [x] Existing `'court'` / `'both'` rows (none in prod, but defensive)
+      are migrated to NULL.
+- [x] Submission templates referencing `{{project.our_side_de}}` /
+      `_en` render coherent prose for the five new values.
+- [x] Determinator perspective chip pre-fills correctly from each
+      sub-role (Active→claimant, Reactive→defendant, Other→null).
+- [x] CCR counterclaim flip yields a sensible child role for the new
+      sub-roles.
+- [x] `go build && go test ./internal/... && cd frontend && bun run
+      build` clean.
+
+---
+
+## §3 Issue #50 — Auto-derived project codes
+
+### §3.1 Current state (verified 2026-05-20)
+
+- `paliad.projects.reference text` exists and is informally used (live
+  values: `EXMPL` on a client, `L-2026-001` on a litigation, `C-UPC-0001`
+  on a case, `P-EP1111222` on a patent). No format enforcement.
+- `paliad.projects.path ltree` is maintained by a Postgres trigger
+  (`projects.path` joined UUIDs root-to-self). Walking ancestors in Go
+  is straightforward: `SELECT * FROM paliad.projects WHERE path @>
+  $1::ltree ORDER BY nlevel(path)`.
+- No `opponent` field exists anywhere. Opponent text lives only inside
+  the litigation `title` (e.g. "Siemens AG ./. Huawei Technologies").
+- `paliad.proceeding_types.code` is dot-separated:
+  `upc.inf.cfi`, `upc.rev.cfi`, `de.inf.lg`, `upc.apl.merits`, etc.
+  Splitting on `.` and upper-casing yields `INF`, `REV`, `LG`,
+  `APL.MERITS`. Suitable as the case segment.
+- `paliad.projects.court text` is free-text on cases (live values:
+  `UPC`, `UPC CoA`, `LG München I`). Not normalised; use the
+  proceeding_type code instead — it carries the same info structurally.
+
+### §3.2 Decisions
+
+**Q1 — Litigation opponent source: new column or regex on title?**
+**Pick: new column `paliad.projects.opponent_code text` on litigation
+rows.** Regex on title is brittle ("./.", "v.", "vs", "—", varying
+order) and the user already knows the short code at creation time. New
+field with explicit validation (slug-cased, max 16 chars) is clean and
+takes one form field + one migration. Title stays as the human-readable
+caption; `opponent_code` is the machine-readable segment source.
+NULL → segment skipped silently.
+
+**Q2 — Patent segment: always last 3, or last-N variable?**
+**Pick: last 3 digits when the digit-stream is ≥ 4 digits long; full
+digit-stream when shorter.** m's example (`EP3456789 → 789`) is 7
+digits last-3 = 789 ✓. UPC publication numbers (10+ digits) collapse to
+their last 3 just fine — uniqueness inside the same litigation tree is
+near-certain because the same litigation tree won't hold two patents
+sharing the same last-3. If it ever does, the user can set a custom
+`reference` (Q5). No need for last-4 / last-N logic.
+
+The patent-number regex extracts the digit-stream from any common
+format (`EP1234567`, `EP 1 234 567`, `EP1234567A1`, `WO2020/123456A1`):
+strip non-digits, take last 3 (or whole if shorter), upper-cased.
+
+**Q3 — Case segment from `proceeding_types.code`?**
+**Pick: take `proceeding_types.code` (e.g. `upc.inf.cfi`), split on `.`,
+drop the leading jurisdiction segment, uppercase the rest, join with
+`.`.** Examples:
+
+  - `upc.inf.cfi` → `INF.CFI`
+  - `upc.rev.cfi` → `REV.CFI`
+  - `upc.pi.cfi`  → `PI.CFI`
+  - `upc.apl.merits` → `APL.MERITS`
+  - `de.inf.lg`   → `INF.LG`
+  - `de.inf.olg`  → `INF.OLG` (appeal instance → segment already
+    encodes "OLG", so we get the appeal level for free; no separate
+    instance segment needed)
+
+The jurisdiction is dropped because the parent client/patent already
+implies the jurisdiction context. If the user wants explicit
+jurisdiction in the code, custom `reference` wins.
+
+If `proceeding_type_id` is NULL on the case, segment is omitted
+silently. No fallback to `court` text — that's free-text and noisy.
+
+**Q4 — Override semantics: wholesale or per-segment?**
+**Pick: wholesale.** When `paliad.projects.reference` is non-empty on
+the project the helper is asked about, that string is returned
+verbatim — no auto-derivation, no string-concatenation, no merging.
+Per-segment override doubles the implementation complexity for a UX
+nobody asked for. Users who want partial overrides set the
+`reference` on the relevant ancestor and let the rest auto-derive
+naturally.
+
+**Q5 — Where the user types the override?**
+**Pick: existing `paliad.projects.reference` field.** Already there,
+already labelled "Interne Referenz (optional)", already used by users.
+Adding a second "project_code_override" alongside `reference` would
+confuse the form. The hint text gets a small addendum: "Leer lassen
+für automatischen Code aus dem Projekt-Baum."
+
+**Q6 — Collision handling (two cases derive to the same code)?**
+**Pick: advisory in v1; no disambiguator.** Codes are display-only
+(not a primary key, not a unique constraint). Real-world collisions
+inside the same litigation tree are vanishingly rare; if they happen,
+the user notices in the picker and sets a custom `reference` on one.
+Adding `-N` suffixes silently would mask a data issue the user should
+see. A future surface could flag duplicates as a project-detail warning,
+but it's not in v1.
+
+**Q7 (new) — Helper signature and call site?**
+**Pick: `ProjectService.BuildProjectCode(ctx context.Context, projectID
+uuid.UUID) (string, error)`.** Lives on the existing ProjectService
+(it needs DB access for the ancestor walk). Internally builds segments
+with a small `projectCodeSegment(p Project) string` pure function per
+type that's table-test-friendly. The helper is called from the
+projection layer when a project gets serialised for the API
+(adds a `code` field to the JSON), so every surface — header,
+breadcrumb, picker, dashboard tile, Excel export — gets the code for
+free without each surface re-walking the tree. Pricier than a
+display-time call but eliminates N+1 walks in list views.
+
+**Q8 (new) — Cache strategy?**
+**Pick: no cache in v1.** Each ancestor walk is one indexed lookup
+on `paliad.projects(path)`. With 12 projects in prod and order-of-100s
+in any plausible firm-scale future, this is microsecond-cheap. If
+profiling later shows it as a hotspot in list views (which fetch many
+projects), introduce a materialised view
+`paliad.projects_derived_codes(project_id, derived_code)` refreshed by
+trigger on `projects` writes. Don't pre-optimise.
+
+### §3.3 Migration `113_projects_opponent_code`
+
+```sql
+-- 113_projects_opponent_code.up.sql (renumbered 2026-05-20)
+-- t-paliad-222 / m/paliad#50.
+-- Add an opponent-code field on litigation projects. Used as the
+-- middle segment when assembling auto-derived project codes from the
+-- ancestor tree (e.g. EXMPL.OPNT.567.INF.CFI). NULL = segment is
+-- skipped silently. No backfill — existing litigation rows simply
+-- yield codes without an opponent segment until the user sets one.
+
+BEGIN;
+
+ALTER TABLE paliad.projects
+    ADD COLUMN IF NOT EXISTS opponent_code text;
+
+-- Slug-shape gate: uppercase letters, digits, dashes, max 16 chars.
+-- Matches the style of m's example "OPNT". Keeps the auto-code clean.
+DO $$
+BEGIN
+    IF NOT EXISTS (
+        SELECT 1 FROM pg_constraint
+         WHERE conname = 'projects_opponent_code_check'
+           AND conrelid = 'paliad.projects'::regclass
+    ) THEN
+        ALTER TABLE paliad.projects
+            ADD CONSTRAINT projects_opponent_code_check
+            CHECK (opponent_code IS NULL
+                OR (opponent_code ~ '^[A-Z0-9-]{1,16}$'
+                    AND type = 'litigation'));
+    END IF;
+END $$;
+
+COMMENT ON COLUMN paliad.projects.opponent_code IS
+    'Short slug for the opposing party on a litigation project '
+    '(uppercase letters, digits, dashes, max 16 chars). Used as the '
+    'middle segment when BuildProjectCode walks the ancestor tree to '
+    'assemble a dotted project code (t-paliad-222 / m/paliad#50). '
+    'NULL = segment skipped silently.';
+
+COMMIT;
+```
+
+The down migration drops the constraint then the column.
+
+### §3.4 Go helper
+
+New file `internal/services/project_code.go`:
+
+```go
+// Package-level function (not a method) so it can be called from any
+// service that already has a *sqlx.DB. ProjectService has a thin
+// wrapper that calls into this.
+//
+// BuildProjectCode assembles the dotted ancestor code for projectID
+// from the existing paliad.projects.path ltree. If the target row's
+// reference column is non-empty, it wins outright (no derivation).
+// Missing ancestor segments are skipped silently — there is no
+// "unknown" placeholder.
+func BuildProjectCode(ctx context.Context, db sqlx.QueryerContext, projectID uuid.UUID) (string, error)
+
+// projectCodeSegment is the per-type segment derivation. Pure, table-
+// test friendly, never touches the DB.
+//
+//   client     → opts.PreferShortReference (reference if set, else slug(title))
+//   litigation → opts.PreferShortReference (opponent_code if set, else "")
+//   patent     → last 3 digits of patent_number (full digits if <4)
+//   case       → uppercase tail of proceeding_types.code (jurisdiction segment dropped)
+//   project    → "" (generic projects don't contribute a segment)
+//
+// proceedingCode is only needed for case rows; the caller resolves
+// it via a single join (or a cached small lookup) before calling.
+func projectCodeSegment(p models.Project, proceedingCode string) string
+```
+
+Sanitisation helpers live alongside as unexported funcs:
+
+- `sanitizeClientShort(s string) string` — uppercase, strip diacritics
+  via `golang.org/x/text/unicode/norm` + filter, replace non-alnum
+  with `-`, trim, cap at 8 chars. Already similar to what
+  `internal/util/slug` does for the global slug helper.
+- `patentLast3(s string) string` — strip non-digits, take last 3
+  characters (or the whole digit-stream when shorter); uppercase.
+  Empty → "".
+- `proceedingTail(code string) string` — split on `.`, drop element 0
+  (jurisdiction), uppercase + join the rest. `""` → `""`.
+
+`BuildProjectCode` SQL is a single round-trip:
+
+```sql
+SELECT p.id, p.type, p.title, p.reference, p.opponent_code,
+       p.patent_number, p.proceeding_type_id,
+       pt.code AS proceeding_code
+  FROM paliad.projects p
+  LEFT JOIN paliad.proceeding_types pt ON pt.id = p.proceeding_type_id
+ WHERE p.path @> (SELECT path FROM paliad.projects WHERE id = $1)
+ ORDER BY nlevel(p.path);
+```
+
+It returns the chain root-to-target. The function:
+
+1. If the last row (the target) has non-empty `reference` → return it
+   verbatim. Done.
+2. Otherwise walk the chain top-to-bottom, call `projectCodeSegment`
+   on each row, skip empty segments, join with `.`, return.
+
+### §3.5 Wiring into surfaces
+
+- `internal/services/project_service.go` projection — add a `Code`
+  string field to the read-side struct and populate it in the single
+  fetch path. For list endpoints, do **one** ancestor-chain query per
+  page (CTE that groups by target id) rather than N+1.
+- `internal/services/submission_vars.go:277` — add
+  `bag["project.code"] = derefString(p.Code)` so submission templates
+  can reference `{{project.code}}`.
+- `frontend/src/components/ProjectHeader.tsx` (current header
+  component on `/projects/{id}`) — render `code` next to the title
+  (small monospace badge) if non-empty.
+- `frontend/src/components/Breadcrumb*.tsx` — when rendering the
+  trail, use `project.code` as the trailing badge per segment if the
+  caller asks for it (opt-in to avoid breaking other consumers).
+- `frontend/src/client/project-form.ts` and any project-picker
+  typeahead — show `code · title` in the dropdown labels when `code`
+  is non-empty.
+- Excel `__meta` sheet — add a `Project Code` row (already enumerates
+  project metadata).
+
+The "copy reference" affordance in the header gets a second line: if
+both `reference` (user override) and the auto-derived code differ, both
+are visible (override above, derived below, smaller).
+
+### §3.6 Tests
+
+- `TestProjectCodeSegment` (table) — every project type × multiple
+  shapes (with/without reference, NULL ancestors, patent_number
+  formats, proceeding codes with 1/2/3 segments).
+- `TestBuildProjectCodeFullChain` — fixture tree
+  Client → Litigation → Patent → Case yields `EXMPL.OPNT.567.INF.CFI`.
+- `TestBuildProjectCodeRespectsOverride` — non-empty `reference` wins
+  outright.
+- `TestBuildProjectCodeMissingAncestors` — case directly under client
+  (no litigation, no patent) yields `EXMPL.INF.CFI`.
+- `TestBuildProjectCodeCollisionDoesNotDisambiguate` — two sibling
+  cases with identical derived codes both return the same string (v1
+  contract per Q6).
+- Migration sanity test (existing harness in
+  `internal/db/migrations_test.go` if present) — up → down → up.
+
+### §3.7 Acceptance (issue #50)
+
+- [x] `BuildProjectCode` returns `EXMPL.OPNT.567.INF.CFI` for the
+      reference tree (Client EXMPL → Litigation OPNT → Patent
+      EP1234567 → Case `upc.inf.cfi`).
+- [x] Setting `projects.reference = 'CUSTOM-CODE'` on the case
+      returns `CUSTOM-CODE` verbatim.
+- [x] Missing ancestor segments are skipped silently
+      (no `..` collapses, no "?" placeholder).
+- [x] `{{project.code}}` resolves in submission templates.
+- [x] Project header, breadcrumb, picker, Excel `__meta` all show the
+      code when set/derived.
+- [x] Litigation form has a new "Opponent Code" field (DE:
+      "Gegner-Kürzel") with the slug pattern validation. Hidden on
+      non-litigation types.
+- [x] `go build && go test ./internal/... && cd frontend && bun run
+      build` clean.
+
+---
+
+## §4 Open questions for the head
+
+(Head: default to the §2.2 / §3.2 "Pick" recommendations unless something
+material pushes back. Coder shift only after head signs off.)
+
+1. **§2.2 Q1** — Keep column name `our_side`? (Recommend YES; rename
+   touches 11+ Go files + bundled-template wire format for zero gain.)
+2. **§2.2 Q2** — Store 7 sub-roles? (Recommend YES; group-only is
+   lossy.)
+3. **§2.2 Q3** — Hide the field on `litigation` and `patent` too, not
+   just on `client`? (Recommend YES per m's "only on case projects".)
+4. **§2.2 Q6** — German prose forms use feminine grammatical gender
+   (Klägerin, Beklagte) per the existing translation table? Or
+   masculine / neutral? (Recommend feminine to match existing
+   `ourSideDE` — keeps consistency with already-rendered templates.)
+5. **§3.2 Q1** — Add a dedicated `opponent_code` column on
+   litigations? (Recommend YES; regex-on-title is brittle.)
+6. **§3.2 Q2** — Patent segment = last 3 digits (variable for
+   <4-digit numbers)? (Recommend YES, matches m's example.)
+7. **§3.2 Q3** — Case segment drops the jurisdiction prefix from
+   `proceeding_types.code` (so `upc.inf.cfi` → `INF.CFI`, not
+   `UPC.INF.CFI`)? (Recommend YES — jurisdiction is implied by the
+   ancestor client/patent context.)
+8. **§3.2 Q7** — `BuildProjectCode` populates a `code` field on every
+   projected Project JSON (not lazy per-render)? (Recommend YES;
+   simpler consumers, one DB round-trip per list page.)
+9. **§3.2 Q8** — No cache / materialised view in v1? (Recommend YES;
+   profile later if list views get slow.)
+
+---
+
+## §5 Implementation order (coder phase)
+
+1. **Mig 112** (client role widen + backfill) → mig 113 (opponent_code).
+   *Renumbered twice on 2026-05-20 — mig 110 claimed by m/paliad#51 project_type_other; mig 111 claimed by m/paliad#48 project_admin_and_select; boltzmann's gap-tolerant runner hard-fails on collisions so this is a strict rebump.*
+   Run `ls internal/db/migrations/ | tail` first to verify slot
+   availability (boltzmann's gap-tolerant runner means 110 is fine
+   even if 109 was the last applied).
+2. **Backend** — `isValidOurSide`, `ourSideDE/EN`,
+   `derivedCounterclaimOurSide`, new `project_code.go` package
+   + ProjectService wiring + projection `Code` field.
+3. **Frontend** — `ProjectFormFields.tsx` (conditional render + new
+   options + opponent_code field on litigation block), `i18n.ts` keys,
+   `fristenrechner.ts` `ourSideToPerspective` widen, header /
+   breadcrumb / picker code-badge wiring.
+4. **Tests** — pinning tests above; `go test ./internal/...` clean.
+5. **Build verification** — `go build && cd frontend && bun run build`
+   clean.
+6. **Commit per slice** — three commits (migration + backend, frontend,
+   tests) keep review tractable.
+
+---
+
+## §6 Risks & rollback
+
+- **Submission templates in the wild.** Users may have downloaded /
+  customised submission templates that still reference
+  `{{project.our_side_de}}` for `our_side='court'` or `'both'`. After
+  this change those values are unreachable, so the template arm
+  returns `""`. Already the fallback behaviour for unknown values;
+  no breakage, just an empty render. Mention in release notes.
+- **Browser cache.** Users with a stale bundle still see the old
+  "Wir vertreten" form for one cache-bust cycle. The legacy i18n keys
+  stay until housekeeping (§2.4), so labels still resolve.
+- **Migration down path.** Stepping down from 110 restores the old
+  4-value CHECK; new sub-role rows would violate it. The down
+  migration backfills new sub-roles → NULL to stay consistent.
+- **Per-tree opponent_code uniqueness.** Two litigations under the
+  same client with the same `opponent_code` would derive identical
+  case codes. Per Q6 we accept this; users see it in the picker and
+  customise `reference` if it bothers them.
+- **No new env vars, no Dokploy compose change** — both changes are
+  pure code + schema; deploy is the existing main-push → webhook →
+  Dokploy auto-redeploy path.

docs/design-smart-timeline-2026-05-08.md

@@ -0,0 +1,739 @@
+# Design — SmartTimeline (Verlauf-tab redesign)
+
+**Author:** lagrange (inventor)
+**Date:** 2026-05-08
+**Task:** t-paliad-169
+**Status:** READY FOR REVIEW — m gates inventor → coder transition.
+
+---
+
+## 0. Premises verified live (before designing)
+
+Before anchoring the design, I checked the live state — CLAUDE.md / memory / issue body can drift, the live system can't.
+
+- **Verlauf today** is `frontend/src/projects-detail.tsx:74-101` — `<ul className="entity-events" id="project-events-list">` rendered from `paliad.project_events` via `loadEvents(id)` at `client/projects-detail.ts:305`. Pure audit log: `event_type` distribution in prod is 100 % administrative — `deadline_completed/updated/created/...`, `note_created`, `appointment_*`, `checklist_*`, `project_type_changed`, `our_side_changed`, `deadlines_imported`. No "future-tense" or "off-script" events surface anywhere on the project page today.
+- **Projection logic** lives in `internal/services/fristenrechner.go:Calculate(ctx, proceedingCode, triggerDateStr, opts CalcOptions)` returning a `UIResponse{Deadlines []UIDeadline}` keyed by `rule_code`. `CalcOptions.AnchorOverrides map[string]string` lets callers replace any rule's date and downstream rules re-anchor — already the load-bearing primitive for "actual dates anchor downstream projections" (t-paliad-131 Phase A).
+- **`paliad.deadline_rules`** carries 172 active rules across 19 fristenrechner proceeding types (UPC×8, DE×5, EPA×2, EP×1, DPMA×3). `condition_flag text[]` already drives counterclaim cross-flows: `with_ccr` enables 7 UPC_INF cross-flow rules (Defence-to-CCR R.29.a, Application to amend R.30.1, Defence to App-to-amend R.32.1, Reply to Defence-to-CCR R.29.d, Rejoinder R.29.e, +2). `with_amend` / `with_cci` work on UPC_REV.
+- **`paliad.projects.our_side`** column exists (added in t-paliad-164) but is **null on every live row today**. The CCR perspective-flip the cascade implements via Determinator B1 (t-paliad-167) is not yet exercised by real data.
+- **CCR is not a separate project today.** It's a flag (`with_ccr=true`) on a parent UPC_INF project. m's vision asks us to revisit that.
+- **FilterBar** (`frontend/src/client/filter-bar/`, riemann's t-paliad-163 Phase 1) ships with axis stubs `deadline_event_type` + `project_event_kind` already wired into `BarState` and `AxisKey` — Phase 2 is supposed to fill them in. The SmartTimeline's facet set is exactly the kind of thing those stubs were left pending for.
+- **Project hierarchy in prod** is the canonical 4-level shape: Client (`Siemens AG`) → Litigation (`Siemens ./. Huawei`) → Patent (`EP3456789`) → Case (`UPC-CFI München — Klage Siemens ./. Huawei`). 11 projects total.
+- **t-paliad-168 deliverable 3 is dropped** per task brief — there will be no separate Verfahrensablauf-as-its-own-tab on the project page. The wizard's projection logic is the SmartTimeline's future-skeleton feeder.
+
+---
+
+## 1. Vision + scope
+
+m's vision (verbatim 2026-05-08 23:02):
+
+> The Verlauf tab inside the case should hold past + future events. If we know the proceeding type, there is a timeline. We adapt the Verfahrensablauf logic and fix dates for things when they happened. A smart timeline. If a counterclaim is filed, that is also included. Hold it flexible — add events regardless of whether they fit the normal course.
+
+The **SmartTimeline** is one composed view that answers *"what has happened in this matter, what is happening now, and what is on the standard road from here"*. Three time-zones in one widget:
+
+| Zone | What it shows | Data source |
+|---|---|---|
+| **Past** | Filings, decisions, appointments, audit milestones — all dated, anchored to reality | `paliad.deadlines` (status=`done`) ∪ `paliad.appointments` (start_at < today) ∪ `paliad.project_events` (selected `timeline_kind`) |
+| **Now** | Open deadlines + appointments today | same tables, today-bracket |
+| **Future (predicted)** | Standard-course rules from `deadline_rules` projected forward, faded — only those without an actual `paliad.deadlines` row yet | `fristenrechner.Calculate` against project's proceeding type + trigger anchor |
+| **Future (off-script)** | User-added events that don't fit the standard tree (counterclaim filed, ad-hoc Anhörung, party amendment) | `paliad.deadlines` with `source='off_script'` ∪ child counterclaim sub-project's actuals ∪ `project_events` with `timeline_kind` |
+
+### What changes
+
+- The `tab=history` panel on `/projects/{id}` becomes a SmartTimeline component that renders all four zones in one column.
+- The audit-only Verlauf view does not disappear — it survives as a "Audit-Log" sub-toggle inside the SmartTimeline ("Alle Audit-Events anzeigen") and on the existing `/admin/audit-log` page (t-paliad-071).
+- The existing FilterBar primitive grows two facets (`timeline_track`, `timeline_status`) and re-uses three (`time`, `personal_only`, `deadline_event_type`).
+
+### What stays
+
+- Step 2 third-card + sidebar entry from t-paliad-168 are unaffected — the standalone Verfahrensablauf wizard at `/tools/fristenrechner` remains a knowledge-platform tool.
+- `paliad.project_events` keeps its full audit-log role for `/admin/audit-log`.
+- `paliad.deadlines` + `paliad.appointments` schemas don't migrate (only one optional column added; details in §2).
+- The existing "Inkl. Unterprojekte" toggle on the project page stays — the SmartTimeline reads child events through it.
+
+### Out of scope (v1)
+
+- Horizontal-Gantt rendering. We pick a vertical timeline; Gantt is a future shape (t-paliad-144 substrate already supports `shape` switching, so adding a Gantt shape is later, not now).
+- Outlook/Exchange sync. CalDAV stays the only sync path.
+- Cross-matter timelines (e.g. "everything happening on EP3456789 across Siemens ./. Huawei AND any related opposition"). The patent-level aggregation in §5 is a step in that direction but cross-matter view is a separate task.
+- Rendering documents (Schriftsätze) on the timeline. That's the t-paliad-17 Incoming-Submission workflow, separate.
+
+---
+
+## 2. Data model
+
+**Recommendation: virtual view, ONE optional column.** No new top-level table for v1. The four zones above are computed at read time from the existing tables. The single schema change is a nullable `timeline_kind text` column on `paliad.project_events` so a subset of audit rows can opt into surfacing as timeline content.
+
+### 2.1 Why no new `timeline_events` table
+
+A first-instinct design would materialise a new `paliad.timeline_events` table with columns `(project_id, kind, date, title, status, source_track, rule_code?, actual_deadline_id?, …)`. I recommend against it for v1:
+
+1. **Three of the four zones already have authoritative tables.** `paliad.deadlines` is the source-of-truth for legal deadlines (with completion + approval state); `paliad.appointments` for hearings + court dates; `paliad.project_events` for audit. Forcing a copy into `timeline_events` creates a sync problem on every mutation.
+2. **The future-projected zone is a function of proceeding-type + trigger date + actual anchors** — not stored data. Materialising it would require invalidation on every `paliad.deadlines` change. Cheaper to recompute per request: 19 proceeding types × at most ~15 rules = ~285 ms with cold pg cache, well under the page-render budget. Re-uses the cached `FristenrechnerService` (already memoised per request via service instantiation).
+3. **t-paliad-144 set the precedent** that ViewService composes per request without materialising. The SmartTimeline is a project-scoped instance of the same pattern.
+
+If load testing later shows the projection cost matters, we materialise into a `paliad.projected_timeline_cache` table indexed by (project_id, rule_code) — but design that when load shows it, not now.
+
+### 2.2 The one column added
+
+```sql
+-- migration NNN_project_events_timeline_kind.up.sql
+ALTER TABLE paliad.project_events
+  ADD COLUMN timeline_kind text NULL;
+
+-- nullable + no CHECK — enum lives in code (services/projection_service.go).
+-- Value space (v1):
+--   'milestone'        — a structural event worth pinning to the timeline
+--                        (counterclaim_filed, third_party_intervened,
+--                         party_amendment, our_side_changed, scope_change)
+--   'custom_milestone' — free-text user-added event
+--   NULL               — audit only (default, all existing rows)
+
+CREATE INDEX project_events_timeline_kind_idx
+  ON paliad.project_events (project_id, timeline_kind)
+  WHERE timeline_kind IS NOT NULL;
+```
+
+Existing event types stay `NULL` — they remain audit-only and don't clutter the timeline. New write paths (counterclaim-link, off-script milestone) set the column on insert.
+
+### 2.3 The discriminated `TimelineEvent` shape
+
+Composed in `internal/services/projection_service.go` (new). One Go struct, one TS mirror. Frontend renders without knowing where each row came from:
+
+```go
+type TimelineEvent struct {
+    Kind       string     // "deadline" | "appointment" | "milestone" | "projected"
+    Status     string     // "done" | "open" | "overdue" | "court_set" | "predicted" | "off_script"
+    Track      string     // "parent" | "counterclaim" | "child:<project_id>" | "off_script"
+    Date       *time.Time // nil = undated (court-set + counterclaim-pending)
+
+    Title      string
+    Description string
+    RuleCode   string     // empty when not deadline-rule-derived
+
+    // Provenance — exactly one is non-nil for actual rows; both nil for projected.
+    DeadlineID    *uuid.UUID
+    AppointmentID *uuid.UUID
+    ProjectEventID *uuid.UUID
+
+    // For projected rows (Kind=="projected") — the rule it came from, for
+    // the click-to-anchor affordance (§6).
+    DeadlineRuleID *uuid.UUID
+    DeadlineRuleParty string  // 'claimant' | 'defendant' | 'court' | 'both'
+
+    // For child-track rows — the sub-project this event belongs to.
+    SubProjectID    *uuid.UUID
+    SubProjectTitle string
+}
+```
+
+### 2.4 Read path
+
+```
+GET /api/projects/{id}/timeline?
+    from=...&to=...&direct_only=true|false&
+    tracks=parent,counterclaim,...&kinds=deadline,appointment,projected,...
+```
+
+The handler:
+1. Calls `ProjectionService.For(ctx, projectID, opts)` which:
+   - Loads the project (proceeding_type_id, our_side, parent chain).
+   - Loads child counterclaim sub-projects (if any — see §4).
+   - Loads `paliad.deadlines` (project_id IN [self, child counterclaims]) → emits Kind=deadline rows.
+   - Loads `paliad.appointments` (same) → emits Kind=appointment rows.
+   - Loads `paliad.project_events WHERE timeline_kind IS NOT NULL` → emits Kind=milestone rows.
+   - For each (project, child) with a proceeding_type_id, calls `FristenrechnerService.Calculate` with `AnchorOverrides` derived from completed actuals → emits Kind=projected rows for any rule that does **not** have a matching `paliad.deadlines.rule_id` row.
+   - Sorts by Date ASC, undated rows last (with secondary sort on rule sequence_order so undated court-set rows preserve the standard course's order).
+
+Visibility is inherited via existing `visibilityPredicate` on each underlying service — no new RLS surface to design.
+
+### 2.5 What does NOT need to change
+
+- `paliad.deadlines` schema — unchanged. (The existing `original_due_date`, `source`, and the AnchorOverrides plumbing already cover "actual date anchors downstream", §6.)
+- `paliad.appointments` — unchanged.
+- `paliad.deadline_rules` — unchanged. The existing `condition_flag text[]` keeps doing its job.
+- `paliad.projects` — unchanged. (See §4 for the counterclaim sub-project shape: it uses existing columns.)
+
+---
+
+## 3. UI mockup — three states
+
+The SmartTimeline replaces the current `<ul className="entity-events">` block (~30 lines of TSX) with a vertically-flowing two-column timeline:
+
+- Left column: date (or "Datum offen" placeholder).
+- Right column: stacked card per event with a status icon, title, kind chip, and (for actuals) a deep-link to `/deadlines/{id}` etc. Same `.entity-event` row contract as today (cf. CLAUDE.md whole-card click rule), no `::before` overlay.
+
+A horizontal "**Heute →**" rule separates past from future. Past goes below (most-recent first), future above (chronological). Today's events sit on the rule.
+
+### 3.1 State A — empty / no proceeding type set
+
+```
+┌──────────────────────────────────────────────────────────────┐
+│ SmartTimeline                          [Filter ▼]  [+ Eintrag] │
+├──────────────────────────────────────────────────────────────┤
+│                                                              │
+│   Noch keine Ereignisse erfasst.                             │
+│                                                              │
+│   Setze einen Verfahrenstyp im Projekt-Header, um den        │
+│   Standardverlauf als Vorhersage zu sehen, oder lege         │
+│   einen Eintrag manuell an.                                  │
+│                                                              │
+│   [+ Frist anlegen]   [+ Termin anlegen]   [+ Meilenstein]    │
+│                                                              │
+└──────────────────────────────────────────────────────────────┘
+```
+
+The empty state actively guides toward the two unlocks: setting a proceeding type (enables future-projection) or adding manual events (works without one).
+
+### 3.2 State B — UPC_INF, infringement-only
+
+```
+┌──────────────────────────────────────────────────────────────┐
+│ SmartTimeline   Verfahrenstyp: UPC-Verletzung   [Filter ▼]   │
+├──────────────────────────────────────────────────────────────┤
+│  Zukunft (vorhergesagt)                                      │
+│  ─────────────────────────────                               │
+│   2027-02-20  ░ Hauptverhandlung                             │
+│               ░ wird vom Gericht bestimmt   [Datum setzen]   │
+│   ─                                                          │
+│   2026-12-02  ░ Duplik (RoP.029.c)             [voraussichtlich]│
+│   2026-11-02  ░ Replik (RoP.029.b)             [voraussichtlich]│
+│   2026-08-31  ░ Klageerwiderung (RoP.023)      [voraussichtlich]│
+│                                                              │
+│ ━━━━━━━━━━━━━━━━━━━━ Heute (2026-05-08) ━━━━━━━━━━━━━━━━━━━━ │
+│                                                              │
+│  Vergangenheit                                               │
+│  ─────────────────────────────                               │
+│   2026-04-29  ✓ Klageschrift zugestellt (Anker)              │
+│   2026-04-25  ✓ Akte angelegt (Audit)                        │
+└──────────────────────────────────────────────────────────────┘
+```
+
+- `░` (faded) = projected, `✓` = done, `!` = overdue (red), `…` = open (amber), `▢` = court-set (dashed border).
+- "Datum setzen" on the Hauptverhandlung row is the click-to-anchor affordance (§6).
+- "voraussichtlich" pill is the projected-status visual; tooltip explains "Anhand des Standardverlaufs aus dem Fristenrechner berechnet".
+- Filter chip selector reveals the FilterBar primitive directly above the list (collapsed by default to reduce noise on first load — same affordance riemann shipped on /inbox).
+
+### 3.3 State C — UPC_INF + Counterclaim (CCR-Subprojekt)
+
+```
+┌──────────────────────────────────────────────────────────────────────────────┐
+│ SmartTimeline   Verfahrenstyp: UPC-Verletzung   [Track ▼ Beide]   [Filter ▼] │
+├──────────────────────────────────────────────────────────────────────────────┤
+│ Verletzung (Klägerseite)              ┊  Widerklage (Beklagtenseite, CCR)    │
+│ ──────────────────────────────────────┊──────────────────────────────────────│
+│  Zukunft (vorhergesagt)                                                      │
+│   2027-02-20  ░ Hauptverhandlung      ┊                                      │
+│                 [Datum setzen]        ┊                                      │
+│   2027-01-29  ░ Rejoinder R.29.e      ┊  2026-12-29  ░ Rejoinder R.32.3      │
+│   2026-12-29  ░ Reply to Defence-CCR  ┊                                      │
+│   2026-11-29  ░ Defence to App-amend  ┊  2026-11-29  ░ Reply to Defence-amend│
+│   2026-10-31  ░ Defence to CCR (R.29a)┊  2026-09-30  ░ Defence to amend      │
+│   2026-08-31  ░ Klageerwiderung mit CCR┊                                     │
+│                                       ┊                                      │
+│ ━━━━━━━━━━━━━━━━━━━━ Heute (2026-05-08) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ │
+│                                       ┊                                      │
+│  Vergangenheit                        ┊                                      │
+│   2026-04-29  ✓ Klageschrift zugestellt┊  ⊕ Widerklage angekündigt           │
+│                                       ┊     (off-script, 2026-05-02)         │
+│   2026-04-25  ✓ Akte angelegt         ┊                                      │
+└──────────────────────────────────────────────────────────────────────────────┘
+```
+
+- Two parallel tracks — left is the parent infringement, right is the linked counterclaim sub-project (see §4).
+- `[Track ▼]` chip toggles between "Beide" (default when a CCR sub-project exists), "Nur Verletzung", "Nur Widerklage".
+- "⊕" marks an off-script milestone (the counterclaim was *announced* before being formally filed — a `project_events` row with `timeline_kind='custom_milestone'`).
+- Mobile: stacks vertically with collapsible per-track headers.
+
+---
+
+## 4. Counterclaim shape — sub-project, defended
+
+m's framing offered two shapes. Inventor recommendation: **sub-project**. Trade-off explicit.
+
+### 4.1 The choice
+
+| | **Sub-project (recommended)** | **Same-project, parallel proceeding-overlay** |
+|---|---|---|
+| Project rows | One per proceeding (parent INF + child CCR) | One project, two proceeding-types attached |
+| `our_side` flip | Independent on the child (parent: claimant; child: defendant in CCR-on-validity, claimant on CCR-of-infringement) | Needs a "perspective per proceeding" sub-table |
+| Determinator routing (t-paliad-167) | Existing — child gets its own cascade | Needs proceeding-aware routing inside one project |
+| Project tree (t-paliad-149) | Naturally appears as a nested node | Same-row, no tree change |
+| Dashboard per-project counts | Each gets its own count | Mixing — needs new "by-proceeding" aggregator |
+| Visibility / RLS | Inherits `can_see_project` cascade | Same |
+| CCR Number from CMS | Stored on child's `case_number` | Stored on parent in a new `case_numbers jsonb` |
+| New schema | None (uses existing project + parent_id) | New `project_proceedings` join table |
+
+### 4.2 Why sub-project
+
+- **Cheap.** Zero schema migration. The hierarchy already supports arbitrary nesting (4 types: client / litigation / patent / case — but `parent_id` is type-agnostic).
+- **Consistent with the data we just built.** t-paliad-164 our_side, t-paliad-149 project tree, t-paliad-167 Determinator cascade, t-paliad-168 deadline-rule jurisdiction defaults all assume "one project = one proceeding perspective". Counterclaim being a sub-project just means we keep that assumption.
+- **CCR Number.** The counterclaim has its own CCR number in the UPC CMS — which means it is in fact a separate proceeding artifact, not just a phase of the parent. Modeling it as a separate project row with its own `case_number` reflects reality. The "case-complex-wise" closeness m asks about is the parent_id link, not collapsing them into one row.
+- **Independent timeline math.** UPC R.49(2) puts CCI / app-to-amend "as part of" Defence to revocation — but that just means zero-duration filed-with-parent. The downstream re-anchoring is independent in each tree.
+
+### 4.3 The link
+
+A new optional FK on `paliad.projects`:
+
+```sql
+-- migration NNN_projects_counterclaim_of.up.sql
+ALTER TABLE paliad.projects
+  ADD COLUMN counterclaim_of uuid NULL
+    REFERENCES paliad.projects(id) ON DELETE SET NULL;
+
+CREATE INDEX projects_counterclaim_of_idx
+  ON paliad.projects (counterclaim_of)
+  WHERE counterclaim_of IS NOT NULL;
+
+-- A project can be EITHER a parent (counterclaim_of IS NULL) OR a
+-- counterclaim against another project (counterclaim_of points at it),
+-- but not both. Enforced by a CHECK on the union of FKs (see §10).
+```
+
+`parent_id` keeps the standard hierarchy (the counterclaim child still lives under the same patent / litigation tree). `counterclaim_of` is an *additional* relation expressing "this project is the CCR against project X". The two are both set on a counterclaim sub-project.
+
+### 4.4 Creating a counterclaim from the timeline
+
+The "+ Eintrag" button on the parent's SmartTimeline opens a typed-add modal (§7). Picking type=`Counterclaim` (UPC) creates a child project with:
+
+- `parent_id` = parent's parent (so CCR appears as a sibling under the patent, not a grandchild — debatable; see §11 Q4).
+- `counterclaim_of` = parent project id.
+- `proceeding_type_id` = `UPC_REV` (CCR-on-validity is the standard case; UPC_CCI is the rarer R.49.2.b path).
+- `our_side` = inverted from parent (parent claimant → child defendant, parent defendant → child claimant).
+- `title` = `<patent> — Widerklage (CCR)` auto-suggested.
+
+The same flow applies to `case_amend` (UPC R.30 application to amend) — a separate child sub-project. *Whether to model R.30 as a child project or as a flag on the parent is open: amendments are usually just a flag in our existing model. Default v1 = stay as flag, do **not** create a sub-project for application-to-amend; only formal counterclaims (CCR / CCI) get sub-projects.*
+
+### 4.5 What the parent's SmartTimeline shows for the child
+
+When `counterclaim_of` exists pointing at this project, the SmartTimeline renders a parallel right-track with the child's events (limited to `kind IN ('deadline','appointment','milestone')` — child's projected rows are also included). User can collapse/hide the child track via the `[Track ▼]` chip.
+
+The child's own SmartTimeline shows its own events as the primary track plus the parent as a left-side faded-context track (so the lawyer working on the CCR can see what's happening on the main proceeding without leaving the page).
+
+---
+
+## 5. Parent-node aggregation rule
+
+What does the SmartTimeline render at higher levels of the project hierarchy? The four levels we have today:
+
+### 5.1 Per-level rendering
+
+| Level | Default render | Why |
+|---|---|---|
+| **Case** (UPC-CFI X) | Full SmartTimeline of self + parallel-track for any linked CCR sub-project. All zones, all kinds. | The lawyer working a single proceeding sees everything in one view. |
+| **Patent** (EP3456789) | Lanes — one per child case. Each lane shows only `kind IN ('deadline','milestone')` + status `IN ('done','open','overdue')`. Projected rows hidden by default (unfold-per-lane on click). | A patent typically has 1-3 active cases (CFI + CoA + opposition). Showing all projected rows from every case = overwhelming. Showing actuals + structural milestones gives the matter-level view. |
+| **Litigation** (Siemens ./. Huawei) | Lanes — one per child patent's primary case (most-recently-active case). Show only `kind='milestone'` + status=`done` + per-case "next due" pill. | Litigation level is portfolio-of-patents-against-this-defendant. Useful to see when each patent's current proceeding is, not the granular deadlines. |
+| **Client** (Siemens AG) | Default = matter list (existing project tree). Behind a "Timeline-Ansicht" toggle, lanes = one per litigation. Shows only `kind='milestone'` + status=`done`. | Client level can have 100+ matters. A timeline across all is meaningless. The toggle makes it discoverable for the partner who wants the bird's-eye view. |
+
+### 5.2 The single rule
+
+> Each level removes one tier of detail and adds one tier of grouping. Going up: fewer kinds rendered, fewer statuses surfaced, more lanes.
+
+| Level | Kinds | Statuses | Lanes |
+|---|---|---|---|
+| Case | all | all | self + CCR child |
+| Patent | deadline + milestone | done + open + overdue | one per child case |
+| Litigation | milestone | done | one per child patent |
+| Client | milestone (toggle) | done | one per child litigation |
+
+This rule is implementable as a single `levelPolicy(projectType)` function in `ProjectionService` returning a `(kinds, statuses, lane_grouping)` triple. All four cases share the same render component; only the input filter varies.
+
+### 5.3 Off-script events at higher levels
+
+Off-script milestones (counterclaim filed, party amendment, scope change) are first-class at every level — they're the events m most cares about seeing at the litigation/patent overview. The "milestone" kind survives the level filter at all levels.
+
+### 5.4 Not in v1
+
+Cross-matter aggregation (e.g. "all my UPC matters, one timeline") is a Custom-View concern (t-paliad-144 substrate). The SmartTimeline is project-scoped; cross-project goes through `/views/{slug}` with a sources=`timeline` ViewSpec. Phase 5+, after t-paliad-163 Phase B lands.
+
+---
+
+## 6. Date-anchoring + reflow semantics
+
+### 6.1 The rule (explicit)
+
+> An actual date — recorded as a `paliad.deadlines.due_date` (status `done`) or `paliad.appointments.start_at` (in the past) or a milestone date — anchors every downstream projected event whose parent rule is the corresponding deadline_rule. The reflow propagates one parent-step at a time, until the next actual takes over or the chain bottoms out.
+
+In other words: the existing `AnchorOverrides` mechanism in `FristenrechnerService.Calculate` is exactly the load-bearing primitive. The SmartTimeline's `ProjectionService` builds the override map at request time:
+
+```go
+overrides := map[string]string{}
+for _, d := range completedDeadlines {
+    if d.RuleCode == "" || d.CompletedAt == nil { continue }
+    overrides[d.RuleCode] = d.CompletedAt.Format("2006-01-02")
+}
+// Court-set rules pick up the actual date too — set when the user enters
+// "Hauptverhandlung fand statt am ..." via the inline anchor affordance.
+opts := CalcOptions{AnchorOverrides: overrides, Flags: flagsForProject(p)}
+result := frist.Calculate(ctx, p.ProceedingCode, p.TriggerDate, opts)
+```
+
+### 6.2 The UI affordance
+
+Each projected row carries a `[Datum setzen]` link (or full-row click on tap-targets). Click → inline date input expands inline. On submit:
+
+- If the row corresponds to a `deadline_rules` entry that has a *real* deadline (not court-set), the action creates a `paliad.deadlines` row with `rule_id` set, `due_date=entered`, `original_due_date=projected`, `source='anchor'`, `status='done'`, `completed_at=entered`. (The "anchor" source is new; existing values are `manual`, `rule`, `import`. v1 adds `'anchor'` to the existing CHECK list.) This is the "we just learned the parent fact" path.
+- If the row is court-set (decision / hearing / order), the action creates a `paliad.appointments` row with `start_at=entered`, `appointment_type='hearing'|'decision'|'order'` derived from the rule's `event_type`. The appointment links back to `rule_code` via a new optional FK column `paliad.appointments.deadline_rule_id` (nullable; existing rows stay null).
+- Either way, the next read recomputes the projection with the new override and downstream rows reflow.
+
+### 6.3 Editing an actual date later
+
+If the user clicks an existing actual row's date, the inline editor PATCHes the underlying record (`/api/deadlines/{id}` or `/api/appointments/{id}`), and the next read re-projects.
+
+### 6.4 What happens to overdue projected rows
+
+A projected row whose date is in the past but no actual exists yet renders as "vorhergesagt — überfällig" (faded amber). Clicking it lets the user either (a) anchor it as actual on a different date, or (b) explicitly mark "ist nicht eingetreten / wurde verschoben" — which writes a `project_events` row with `event_type='rule_skipped'` + `timeline_kind='milestone'` so the audit trail records the decision.
+
+---
+
+## 7. Off-script event UX
+
+The cardinal constraint: "We must hold it flexible — add events regardless of whether they fit the normal course." Off-script events are first-class.
+
+### 7.1 The "+ Eintrag" CTA
+
+Persistent button in the SmartTimeline header. Click → typed-add modal:
+
+```
+┌──────────────────────────────────────────────────┐
+│  Neuer Eintrag im SmartTimeline                  │
+├──────────────────────────────────────────────────┤
+│                                                  │
+│  Was ist passiert? (oder wird passieren?)        │
+│                                                  │
+│   ◯ Frist                  → /deadlines/new      │
+│   ◯ Termin                 → /appointments/new   │
+│   ◯ Widerklage (CCR)       → Anlegen Sub-Akte    │
+│   ◯ Anwendung auf Änderung (R.30)  → Flag setzen │
+│   ◯ Schriftsatz / Order    → Off-script          │
+│   ◯ Eigener Meilenstein    → Off-script (frei)   │
+│                                                  │
+│  [ Abbrechen ]              [ Weiter ▶ ]         │
+└──────────────────────────────────────────────────┘
+```
+
+The visible options depend on the project's `proceeding_type_id`. UPC_INF gets the CCR + R.30 routes; UPC_REV gets CCI; DE_INF gets none of these. The "Schriftsatz / Order" + "Eigener Meilenstein" routes are universal.
+
+### 7.2 The off-script branch
+
+For "Schriftsatz / Order" and "Eigener Meilenstein" — a small form:
+
+```
+Off-script Meilenstein
+
+  Titel:        [Widerklage angekündigt durch Beklagten         ]
+  Datum:        [2026-05-02]
+  Beschreibung: [Schreiben des Beklagtenanwalts vom 02.05., …    ]
+  Verknüpfung:  ☐ Frist daraus erzeugen   ☐ Termin daraus erzeugen
+  Sichtbar in:  ◉ Diese Akte   ◯ Diese Akte + Eltern
+                                  ↑ Will it bubble up to higher levels?
+
+  [ Abbrechen ]                                  [ Speichern ]
+```
+
+On submit, writes a `paliad.project_events` row with:
+
+- `event_type='off_script_milestone'` (new value in the event_type enum-ish CHECK; today's CHECK is open-ended text — confirm during impl).
+- `timeline_kind='custom_milestone'`.
+- `event_date=entered`.
+- `description=...`.
+- `metadata={"track": "parent" | "off_script", "links": [...]}`.
+
+The optional checkboxes "Frist daraus erzeugen / Termin daraus erzeugen" open the standard deadline/appointment-create flow with the milestone's data prefilled and the milestone's id linked via metadata for audit trail.
+
+### 7.3 Curated catalogue per proceeding type (NICE TO HAVE)
+
+A small lookup table `paliad.timeline_event_catalogue (proceeding_type_id, kind, slug, name_de, name_en, primary_party)` could surface in the modal as a "Häufige Ereignisse" section above the universal "Eigener Meilenstein" route. Examples:
+
+- UPC_INF: Counterclaim Filed, Third Party Intervention, Hearing Postponement, Cost Decision Issued
+- UPC_REV: Application to Amend Filed, Substantive Decision, Costs Order
+- DE_INF: Hinweisbeschluss Issued, Verteidigungsanzeige, Termin Hauptverhandlung, Versäumnisurteil
+
+The catalogue is a v2 nice-to-have. v1 ships with "Eigener Meilenstein" as the universal escape hatch and the few proceeding-specific routes named above (CCR, CCI, R.30) hardcoded on the modal.
+
+---
+
+## 8. Filter facets — first-pass refinement
+
+Refining the task brief's first-pass list against the FilterBar API (riemann's `BarState` / `AxisKey`). Each axis maps to either a universal axis (already shipped), an existing per-source stub (riemann left ready), or a new one.
+
+### 8.1 Reused universal axes (already in BarState)
+
+- **`time`** (universal, chip cluster + custom range) — past 30/90d, next 30/90/any/custom. Default = `any`. Re-used verbatim; no work.
+- **`personal_only`** (universal, chip) — re-used. "Nur meine Einträge" — `created_by=me`. Behavior same as on `/events` (t-paliad-128).
+
+### 8.2 New per-source axes (extend `AxisKey`)
+
+```ts
+// frontend/src/client/filter-bar/types.ts — additions
+export type AxisKey =
+    | …existing…
+    | "timeline_kind"     // multi-select chip cluster
+    | "timeline_status"   // multi-select chip cluster
+    | "timeline_track"    // multi-select chip cluster
+    ;
+
+export interface BarState {
+    …existing…
+    timeline_kind?: ("deadline" | "appointment" | "milestone" | "projected")[];
+    timeline_status?: ("done" | "open" | "overdue" | "court_set" | "predicted" | "off_script")[];
+    timeline_track?: ("parent" | "counterclaim" | string /* child:<projectid> */)[];
+}
+```
+
+### 8.3 The facet set on the SmartTimeline surface
+
+The surface declares this `axes` array when it mounts the bar:
+
+```ts
+mountFilterBar(host, {
+  axes: [
+    "time",            // universal — past/future filter
+    "timeline_kind",   // deadline | appointment | milestone | projected
+    "timeline_status", // done | open | overdue | court_set | predicted | off_script
+    "timeline_track",  // parent | counterclaim | child:<id>
+    "personal_only",   // optional — toggle "nur meine Einträge"
+    "deadline_event_type", // existing stub — wired in t-paliad-117 multi-select
+    "shape",           // timeline (default) | list | cards
+    "sort",            // chronological asc/desc
+    "density",         // comfortable | compact
+  ],
+  surfaceKey: "project-smart-timeline",
+  systemViewSlug: "project-timeline",
+  …
+});
+```
+
+### 8.4 Defaults
+
+- `time = any`
+- `timeline_kind = [deadline, appointment, milestone]` (projected hidden by default — the user opts in via chip; reduces noise on first load when most projects don't have a proceeding type set)
+- `timeline_status = [done, open, overdue, off_script]` (predicted + court_set hidden by default if `projected` kind is hidden — the chip group is one logical "show future" toggle)
+- `timeline_track = all available`
+- `shape = timeline`
+- `sort = date_desc` (most recent first; matches today's Verlauf default)
+- `density = comfortable`
+
+### 8.5 The "show future" macro
+
+Most users will only want one toggle: "Zukunft anzeigen". We render that as a primary chip pair next to `time`:
+
+```
+[ Vergangenheit | Heute | Zukunft ]   ← primary toggle
+```
+
+Internally this maps to `time + timeline_kind` (Vergangenheit hides projected, Zukunft shows projected, Heute is just today). Power users can drill into the granular axes via the bar.
+
+### 8.6 What riemann's port (t-paliad-170) needs to know
+
+Riemann is porting FilterBar onto the Verlauf surface in parallel. Three things they need:
+
+1. **Three new axis keys** (`timeline_kind`, `timeline_status`, `timeline_track`). They render as chip clusters — the same primitive `chipRow + chipBtn` riemann already factored.
+2. **`shape: "timeline"`** is a new render shape. Existing shapes are `list | cards | calendar` (t-paliad-144). We pick "timeline" as a 4th shape so the FilterBar's shape switcher lets the user collapse to `list` (compact audit log) or `cards` (chronological card grid) without losing the data. Implementation = new `frontend/src/client/views/shape-timeline.ts` mirroring the other shape files. Out of scope for t-paliad-170 (riemann ports the bar, not the new shape).
+3. **The `timeline_track` axis options are dynamic** — they depend on whether the project has a counterclaim child. The bar already supports lazy axes (the `project` axis pattern in `axes.ts:30` — `"populated lazily"`). `timeline_track` follows the same shape: surface fetches available tracks at mount, passes them to the bar.
+
+---
+
+## 9. Verfahrensablauf-logic sharing — extract, don't import
+
+**Recommendation: extract into a shared module first.**
+
+### 9.1 The decision
+
+The wizard's projection logic is currently in two places:
+
+1. `internal/services/fristenrechner.go:Calculate(...)` — the canonical Go implementation. Already returns a `UIResponse{Deadlines []UIDeadline}` keyed by rule_code, supports `AnchorOverrides`. ~1000 lines, tested.
+2. `frontend/src/client/fristenrechner.ts:calculate()` — the frontend wrapper that POSTs `/api/tools/fristenrechner` and handles flags + overrides. ~3500 lines including the wizard UI, but the projection-relevant slice is small (call + render).
+
+The SmartTimeline's `ProjectionService.For(projectID)` needs the *Go calculator*, not the frontend code path. So the question is really: *do we add a new Go service that wraps `FristenrechnerService.Calculate` for projects?*
+
+Yes — a thin adapter, not a parallel implementation.
+
+### 9.2 The adapter
+
+```go
+// internal/services/projection_service.go (new, ~200 LoC)
+
+type ProjectionService struct {
+    db          *sqlx.DB
+    fristen     *FristenrechnerService
+    deadlines   *DeadlineService
+    appointments *AppointmentService
+    projects    *ProjectService
+    courts      *CourtService
+}
+
+// For builds a SmartTimeline for one project (and its CCR child if any).
+// Composes the four zones described in §1; returns sorted TimelineEvent[].
+func (s *ProjectionService) For(ctx context.Context, projectID uuid.UUID, opts ProjectionOpts) ([]TimelineEvent, error) {
+    p, err := s.projects.GetVisible(ctx, projectID, opts.ViewerID)
+    // ...
+    children := s.projects.LoadCounterclaimChildrenVisible(ctx, projectID, opts.ViewerID)
+
+    actuals := s.collectActuals(ctx, []uuid.UUID{p.ID, children...}) // dl + appt + milestones
+    overrides := buildAnchorOverrides(actuals)
+
+    var projected []TimelineEvent
+    if p.ProceedingTypeCode != "" && p.TriggerDate != nil {
+        proj := s.fristen.Calculate(ctx, p.ProceedingTypeCode, p.TriggerDate.Format("2006-01-02"),
+            CalcOptions{AnchorOverrides: overrides, Flags: flagsFor(p), CourtID: p.CourtID})
+        projected = projectionToTimeline(proj, p, actuals)
+    }
+    // (same for each child counterclaim)
+
+    return mergeAndSort(actuals, projected, opts.LevelPolicy), nil
+}
+```
+
+The adapter does not duplicate the calculator — it calls `FristenrechnerService.Calculate` exactly once per (project, child). Same code path as `/api/tools/fristenrechner` uses today; same tests cover both.
+
+### 9.3 What the standalone wizard keeps
+
+`/tools/fristenrechner` continues to use `FristenrechnerService.Calculate` directly — it's a knowledge-platform tool, not a project-scoped view. It does not gain anchoring affordances or off-script events. The projection there is hypothetical ("if you start a UPC_INF on date X, here's the timeline"), not project-actual.
+
+`ProjectionService` is a project-scoped composition layer; it lives one level above `FristenrechnerService` in the dependency graph.
+
+### 9.4 The test split
+
+- `fristenrechner_test.go` keeps testing the calculator (duration math, AnchorOverrides, CourtID resolution).
+- `projection_service_test.go` (new) tests the composition: mixing actuals + projected, level policy, counterclaim child merging, sort order.
+
+---
+
+## 10. Phasing — 4 sequential slices
+
+Each slice is independently shippable and reviewable. m's go/no-go gate after each.
+
+### Slice 1 — SmartTimeline skeleton (no projection yet)
+
+What lands:
+
+- New `internal/services/projection_service.go` with `For()` returning only actuals (deadlines + appointments + opted-in `project_events`). No `fristenrechner` call yet.
+- Migration `NNN_project_events_timeline_kind.up.sql` adds the optional column + partial index (§2.2).
+- New endpoint `GET /api/projects/{id}/timeline?…` returning `[]TimelineEvent`.
+- `frontend/src/client/projects-detail.ts:loadEvents` rewritten to call `/timeline` instead of `/events`. The current Verlauf list is replaced by the new vertical timeline component (`client/views/shape-timeline.ts` — new file, ~300 LoC).
+- "+ Eintrag" CTA in the timeline header (modal partially implemented — only "Eigener Meilenstein" route lit; CCR / R.30 / Frist / Termin routes are link buttons to existing flows).
+- "Audit-Log anzeigen" toggle that switches to the legacy chronological list rendering (`paliad.project_events` ALL — not just `timeline_kind IS NOT NULL`).
+
+What it gives m: a working SmartTimeline showing past actuals + open/upcoming deadlines + appointments + off-script milestones, with the audit log surviving as a toggle. No future-projection yet.
+
+### Slice 2 — Future-projection + click-to-anchor
+
+What lands:
+
+- `ProjectionService.For` calls `FristenrechnerService.Calculate` and emits projected rows.
+- Click-to-anchor inline date editor (§6.2). New endpoint `POST /api/projects/{id}/timeline/anchor` taking `{rule_code, actual_date, kind?}` and writing the appropriate `paliad.deadlines` (`source='anchor'`) or `paliad.appointments` (`deadline_rule_id` FK new) row.
+- Migration `NNN_appointments_deadline_rule_id.up.sql` adds the optional FK on appointments + extends `paliad.deadlines.source` CHECK to include `'anchor'`.
+- "voraussichtlich" / "Datum vom Gericht" status pills + projected-row CSS (faded + dashed border for court-set).
+- New "Zukunft anzeigen" macro chip pair (§8.5).
+- `event_type='rule_skipped'` write path for the "ist nicht eingetreten" decision (§6.4).
+
+What it gives m: predicted future course based on standard timeline; click to fix any date when something happens; downstream reflows automatically.
+
+### Slice 3 — Counterclaim sub-project
+
+What lands:
+
+- Migration `NNN_projects_counterclaim_of.up.sql` — the new `counterclaim_of` FK + index + the CHECK (a project either has counterclaim_of OR is parent — not both — to keep the invariant clean).
+- "+ Eintrag → Widerklage (CCR)" route in the modal (§7.1) — creates child project with auto-suggested `our_side` flip, `proceeding_type_id`, and title, then navigates to it for the user to fill in `case_number`.
+- `ProjectionService` loads CCR children + emits parallel-track rows.
+- `[Track ▼]` chip in the header — reads `available_tracks` from the timeline response.
+- The two-column rendering on State C (§3.3).
+- `paliad.project_events` audit row written on counterclaim creation (`event_type='counterclaim_created'`, `timeline_kind='milestone'`).
+
+What it gives m: counterclaims as proper sub-projects, parallel timelines, CCR perspective-flip works end-to-end.
+
+### Slice 4 — Parent-node aggregation
+
+What lands:
+
+- `levelPolicy(projectType)` in `ProjectionService` — kinds/statuses/lane filter per level (§5.1).
+- Lane-grouped rendering at Patent / Litigation / Client levels.
+- "Timeline-Ansicht" toggle on Client-level project page (default off; lanes-of-litigations when on).
+- Off-script milestones bubble up to higher levels via the `metadata.bubble_up: true` flag (§7.2 form's "Sichtbar in: Diese Akte + Eltern" checkbox).
+
+What it gives m: portfolio-level timelines without overload — the bird's-eye view he asked about.
+
+### What's NOT in any slice
+
+- Curated per-proceeding event catalogue (§7.3) — v2 nice-to-have.
+- Gantt rendering — separate `shape: "gantt"` follow-up.
+- Cross-matter timeline — Custom Views path.
+- Outlook integration — out of scope.
+
+---
+
+## 11. Open questions for m
+
+Listed with my (inventor) pick where I have one — m decides.
+
+**Q1 — Counterclaim sub-project vs proceeding-overlay (§4).** I recommend sub-project. Confirm before Slice 3 design lock.
+
+**Q2 — Should `our_side` flip automatically on counterclaim sub-project creation?** My pick: yes, default-flip with a "Stimmt nicht?" toggle on the create modal. The R.49.2.b CCI is the edge case (parent claimant → child claimant in CCI of the *separate* infringement claim), but the standard CCR-on-validity always inverts. Default-flip + toggle handles both.
+
+**Q3 — Should `paliad.deadlines.source` gain `'anchor'` or should we re-use `'manual'`?** My pick: new `'anchor'` value — separates "user-typed-it-in" from "user-recorded-an-actual-after-projection-fired" for analytics + future automated import (Outlook event → anchor).
+
+**Q4 — Counterclaim sub-project's `parent_id` — under the patent (sibling to parent case) or under the parent case (grandchild)?** My pick: under the patent (sibling). The CCR is its own proceeding with its own case_number; modeling it as a sibling to the parent infringement, both under the patent, mirrors how UPC CMS sees them. Grandchild placement would imply CCR is "part of" the parent case which it structurally isn't.
+
+**Q5 — Off-script milestone bubble-up default.** My pick: default-on for `event_type IN ('counterclaim_created', 'third_party_intervention', 'scope_change')`; default-off for `event_type='custom_milestone'`. Form has the override checkbox in either case.
+
+**Q6 — Should `/tools/fristenrechner` keep its standalone existence?** Brief says yes — knowledge tool, separate from project context. My pick: yes, agree. It stays.
+
+**Q7 — Application-to-amend (UPC R.30) as sub-project or flag?** My pick: stay as flag (`with_amend`). Amendments are not a separate proceeding artifact in the CMS — they ride on the parent's record. The cross-flow rules already activate via `condition_flag`.
+
+**Q8 — On the parent's SmartTimeline, do CCR rows mix into one column or stay in a parallel right-track?** My pick: parallel right-track when both are populated; collapses into one column on mobile (vertical stacking with sub-headers per track). The `[Track ▼]` chip lets desktop users opt into single-column mode.
+
+**Q9 — Court-set anchor (Hauptverhandlung) creates a `paliad.appointments` row or a `paliad.deadlines` row?** My pick: `paliad.appointments` — it's an appointment, not a deadline. The new `appointments.deadline_rule_id` FK preserves the link back to the rule for downstream re-anchoring.
+
+**Q10 — Is `timeline_kind` the right column name?** Alternatives: `is_timeline_milestone bool`, `surface_on_timeline bool`. My pick: keep `timeline_kind text NULL` because it lets us distinguish `milestone` (structural) from `custom_milestone` (free-form) without a second column.
+
+**Q11 — Should the SmartTimeline be the only view of the project's events?** Or do we keep a "klassisch (chronologisch)" sidebar tab? My pick: SmartTimeline as the only Verlauf tab; "Audit-Log anzeigen" toggle inside the timeline reveals the chronological rendering. m uses `/admin/audit-log` (t-paliad-071) for the cross-project audit query.
+
+**Q12 — Patent-level "matter list vs lane timeline" default.** My pick: lanes by default at Patent + Litigation; matter list by default at Client. The Litigation level has 1-3 child patents typically → 1-3 lanes is fine. Client can have 100+ → lanes are a toggle.
+
+---
+
+## 12. Files implementer will touch (Slice 1 only)
+
+Aggregated for the coder shift kickoff:
+
+**Backend (Go):**
+- `internal/services/projection_service.go` — new, ~250 LoC.
+- `internal/handlers/projection.go` — new, GET /api/projects/{id}/timeline, ~80 LoC.
+- `internal/handlers/handlers.go` — register the new route.
+- `internal/db/migrations/NNN_project_events_timeline_kind.{up,down}.sql` — new.
+
+**Frontend (TS / TSX):**
+- `frontend/src/client/views/shape-timeline.ts` — new render shape, ~300 LoC.
+- `frontend/src/client/projects-detail.ts:loadEvents` — replace with timeline fetch.
+- `frontend/src/projects-detail.tsx:74-101` — replace Verlauf markup with `<div id="project-smart-timeline">`.
+- `frontend/src/styles/global.css` — `.smart-timeline-*` styles, ~150 LoC.
+- `frontend/src/client/i18n.ts` — ~30 keys under `projects.detail.smarttimeline.*`.
+
+**Tests:**
+- `internal/services/projection_service_test.go` — new (live-DB integration test, skipped without `TEST_DATABASE_URL`).
+- `internal/services/projection_service_unit_test.go` — pure-function tests (sort, level policy, override-build).
+
+Slices 2-4 are scoped in §10; coder picks them up after m's gate.
+
+---
+
+## 13. Trade-offs flagged
+
+- **Per-request projection cost.** Recomputing on every Verlauf load is fine for a single project. If m navigates to a Client-level lane view with 50 child litigations × 3 cases each, that's 150 calculator invocations. Mitigation: lane-rendering at Litigation+Client levels excludes `kind='projected'` by default (§5), so the calculator is only called on the leaf rendering. Watch in production; add per-(project, hash(overrides)) cache if needed.
+- **Migration order across active workers.** riemann is on t-paliad-170 (FilterBar Verlauf port) in parallel. Slice 1 must merge **after** their port because Slice 1 mounts the bar with new axis keys. Coordinate via head before Slice 1 PR opens.
+- **Sub-project counterclaim adds a tier.** The project tree gets deeper (Patent → Case + Patent → CCR-Sub-Case as siblings). Existing tree visualisation in t-paliad-149 handles arbitrary depth, but the per-card "in 3 children" badge needs to count the CCR child correctly — verify in Slice 3.
+- **`appointments.deadline_rule_id`** is a backward-pointing FK that doesn't exist yet. Adding it in Slice 2 is clean (nullable, no backfill needed). Just flagging that this ties appointments to deadline_rules where they previously had no link.
+- **Anchor write path can race.** Two users clicking "Datum setzen" on the same row simultaneously could both write `paliad.deadlines` rows. Mitigation: server-side check `WHERE NOT EXISTS (SELECT 1 FROM paliad.deadlines WHERE project_id=... AND rule_id=...)` before insert, otherwise PATCH the existing row. Standard pattern.
+- **What if the proceeding type changes mid-flight?** The user changes `paliad.projects.proceeding_type_id` after deadlines have been calculated. Existing actuals stay (they have `rule_id` FK pointing to the OLD rule tree). Projected rows recompute against the NEW rule tree; rule_codes that don't exist in the new tree drop out. This is the same behaviour today — flagging because the SmartTimeline makes it more visible.
+
+---
+
+## 14. Recommendation for implementer
+
+Pattern-fluent Sonnet coder. Slice 1 is largely boilerplate (new service + handler + render shape). Slice 2 needs the calculator integration which is well-trodden (t-paliad-131 Phase A shipped overrides). Slice 3 needs the sub-project FK design (one careful migration) and the parallel-track CSS. Slice 4 is render-policy logic, low-risk.
+
+Lagrange (this worktree) parks. NOT pre-emptively flipping to coder — m gates.
+
+---
+
+**DESIGN READY FOR REVIEW**

docs/design-submission-generator-2026-05-19.md

@@ -0,0 +1,784 @@
+# Design — Submission generator (t-paliad-215)
+
+**Author:** copernicus (inventor)
+**Date:** 2026-05-19
+**Issue:** m/paliad (task t-paliad-215, no Gitea issue filed yet)
+**Branch:** `mai/copernicus/inventor-submission`
+**Status:** DESIGN READY FOR REVIEW
+
+---
+
+## §0 TL;DR
+
+Each row in `paliad.deadline_rules` represents a SUBMISSION — a filing,
+hearing, or decision inside a proceeding (`submission_code` shape
+`de.inf.lg.erwidg`, `upc.inf.cfi.soc`, …). The submission generator
+takes a project + a submission_code, pulls a `.docx` template from
+Gitea, merges in project variables (party names, court, case number,
+patent number, our_side, deadline date, legal_source citation, firm
+header), and streams the result to the browser as a download.
+
+- **Scope (locked by m):** template-render to `.docx`. No LLM in v1.
+- **Template registry (locked):** Gitea — same proxy pattern as the
+  existing HL Patents Style `.dotm` in `internal/handlers/files.go`.
+- **Output (locked):** direct download, NO server-side binary
+  persistence. One audit row per generation; the bytes themselves are
+  regenerable from inputs on demand.
+- **Lookup (locked):** fallback chain — firm-specific override →
+  base for the exact `submission_code` → generic for the proceeding
+  family → ultra-generic skeleton.
+- **Slice 1 (locked):** one template, end-to-end, on one project.
+  Pick `de.inf.lg.erwidg` (Klageerwiderung) as the proof template.
+- **AI-drafted body:** explicitly OUT of scope for this task. Lives
+  in §11 as a follow-up sketch only.
+
+This design is read-only. No code, no migrations, no schema
+additions. Implementation gate is m's go/no-go on this doc.
+
+---
+
+## §1 Premises verified live (2026-05-19)
+
+Anchored against the running paliad codebase + youpc Supabase, not
+against CLAUDE.md or memory. Where a claim load-bears the design, it
+was checked against the live system.
+
+| Claim | Verification |
+|---|---|
+| Migration tracker at **102** (next is 103) | `ls internal/db/migrations/` — `102_system_audit_log` is the latest applied. |
+| `paliad.documents` table exists, is empty, no code writes to it yet | `SELECT COUNT(*) FROM paliad.documents` → 0 rows. Columns: `id, title, doc_type, file_path NULLABLE, file_size, mime_type, ai_extracted jsonb, uploaded_by, created_at, updated_at, project_id NOT NULL`. `grep` shows only `export_service.go` (audit-export only) and a comment in `render_spec.go`. No `document_service.go`, no `/api/documents` handler. |
+| `paliad.deadline_rules` carries the submission corpus | 254 total rows, 158 unique `submission_code`s, 214 `published`. Per-row fields used by the generator: `name`, `name_en`, `submission_code`, `primary_party` (claimant/defendant/court/both), `event_type` (filing/hearing/decision), `legal_source` (e.g. `DE.ZPO.276.1`, `UPC.RoP.23.1`), `is_bilateral`. |
+| Slice 1 target row exists in published state | `SELECT … WHERE submission_code='de.inf.lg.erwidg'` → `{name:"Klageerwiderung", name_en:"Statement of Defence", primary_party:"defendant", legal_source:"DE.ZPO.276.1"}`. |
+| Project rows carry all variables we need to merge | `paliad.projects` has `case_number, court, patent_number, filing_date, grant_date, our_side, instance_level, proceeding_type_id, title, reference, client_number, matter_number`. |
+| Party rows carry party variables | `paliad.parties` has `name, role, representative, contact_info jsonb` and is project-scoped via `project_id`. |
+| The HL Patents Style proxy pattern is reusable | `internal/handlers/files.go`: `fileRegistry` map → Gitea raw URL + SHA-based cache + 5-min refresh check + binary download response with `Content-Disposition`. Cache is in-process (`sync.Mutex` over a `map[string]*cacheEntry`). Single web replica today (`docker-compose.yml`), so in-process cache is fine. |
+| Email templates already use `{{.VarName}}` placeholders + a "variable contract" sidebar pattern | `internal/services/email_template_variables.go` — `EmailTemplateVariable{Name, Type, Description, SampleDE, SampleEN}` rendered in `/admin/email-templates`. Submission generator can copy this contract pattern. |
+| Audit infrastructure landed in mig 102 | `paliad.system_audit_log(id, event_type, actor_id, actor_email, scope, scope_root, metadata jsonb, created_at, updated_at)` — submission_generated events slot straight in. |
+| Branding source is `internal/branding.Name` | Default `"HLC"`, overridable via `FIRM_NAME`. Inlined into client bundles by `frontend/build.ts`. Submission templates honour this via the `{{firm.name}}` placeholder. |
+| `paliad.can_see_project(project_id)` is the canonical visibility predicate | mig 055; `internal/services/visibility.go` mirrors it. Generator gates on this; no new auth surface. |
+| Paliadin runs on the aichat backend (mRiver) with persona system | `internal/services/aichat_paliadin.go` + `personas.yaml` in `m/mAi/internal/aichat/persona/`. Owner-gated to `PaliadinOwnerEmail = matthias.siebels@hoganlovells.com`. A future AI-drafted body would be a new persona, not a new Go service. |
+
+**Doc-vs-live conflicts found:** none material for this design.
+`docs/project-status.md` still lists "Phase H AI Frist-Extraktion
+deferred" — this design does NOT revive Phase H (different surface;
+this is template merge, not document understanding).
+
+---
+
+## §2 m's decisions (2026-05-19)
+
+Locked via AskUserQuestion before drafting the rest of the design.
+
+| # | Question | m's pick | Inventor recommended? |
+|---|---|---|---|
+| Q1 | Generator scope (template / AI-draft / brief / other) | **Template-render to `.docx`** | ✅ yes |
+| Q2 | Template registry (Gitea / paliad DB / hybrid) | **Gitea** | ✅ yes |
+| Q3 | Output flow (download-only / persist binary / attach to Frist) | **Direct download, no server-side binary** | ✅ yes |
+| Q4 | Mapping (fallback chain / 1:1 / 1:N user picks) | **Fallback chain** | ✅ yes |
+| Q5 | Slice 1 scope (1 template / 3–5 templates / full corpus / skeleton-only) | **One template, end-to-end on one project** (`de.inf.lg.erwidg` Klageerwiderung) | ✅ yes |
+
+Inventor-defaulted (not asked because there's a clear right answer or
+because the question is implementation-level, not architecture-level):
+
+| # | Topic | Default | Reasoning |
+|---|---|---|---|
+| D1 | Variable engine | `{{path.dot.notation}}` placeholders in the .docx body, replaced via a Go library that handles run-fragmentation | Matches the existing email-template `{{.Var}}` shape lawyers already see in `/admin/email-templates`. See §6. |
+| D2 | Authorization | Project-team visibility only (`paliad.can_see_project`) + audit row | Matches every other write surface in paliad. No profession floor (generation is read-only on source data and produces a draft, not a binding action). |
+| D3 | Naming convention | `{rule.name}-{project.case_number}-{YYYY-MM-DD}.docx`, slashes → underscores, FIRM_NAME-aware | Mirrors how lawyers name files manually. See §7. |
+| D4 | Missing-variable behaviour | Render `[KEIN WERT: {field}]` / `[NO VALUE: {field}]` marker inline | Lets the lawyer see the gap in Word, fix in paliad, regenerate. Better than 400ing. |
+| D5 | Editor surface | Gitea-only for v1 (admin edits .docx in Word, commits to mWorkRepo) | A paliad uploader UI is Phase 2 affordance if Gitea round-trip is painful. |
+| D6 | AI-drafted body | OUT of scope for this task | §11 sketches the natural follow-up shape (new aichat persona) but does not commit to it. |
+
+---
+
+## §3 Architecture overview
+
+```
+┌────────────────────────────────────────────────────────────────────────┐
+│ Project detail page                                                    │
+│  ├─ "Submissions" panel (or button row)                                │
+│  │     [Generate Klageerwiderung] [Generate Klageerhebung] [...]      │
+│  │     Each button enabled iff a template exists for that             │
+│  │     submission_code AND user passes paliad.can_see_project.        │
+│  └─ Click → POST /api/projects/{id}/submissions/{code}/generate       │
+└──────────────────────────────────┬─────────────────────────────────────┘
+                                   │
+                                   ▼
+┌────────────────────────────────────────────────────────────────────────┐
+│ handlers/submissions.go (NEW)                                           │
+│   1. Auth: UserIDFromContext + can_see_project gate                    │
+│   2. Load deadline_rule by submission_code                             │
+│   3. Resolve template via fallback chain (TemplateRegistry)            │
+│   4. Build variable bag (services/submission_vars.go)                  │
+│   5. Render via SubmissionRenderer (services/submission_render.go)     │
+│   6. Write paliad.documents audit row (NO file_path)                   │
+│   7. Write paliad.system_audit_log entry (event_type=                  │
+│      'submission.generated')                                            │
+│   8. Stream .docx bytes with Content-Disposition: attachment           │
+└──────────────────────────────────┬─────────────────────────────────────┘
+                                   │ (template fetch)
+                                   ▼
+┌────────────────────────────────────────────────────────────────────────┐
+│ TemplateRegistry (services/submission_templates.go) — NEW              │
+│   • In-process cache (same shape as handlers/files.go cacheEntry)      │
+│   • Lookup path:                                                        │
+│       (1) templates/{FIRM_NAME}/{submission_code}.docx                  │
+│       (2) templates/_base/{submission_code}.docx                        │
+│       (3) templates/_base/{proceeding_family}.docx (e.g. upc.inf.cfi)  │
+│       (4) templates/_base/_skeleton.docx                                │
+│   • Fetched from m/mWorkRepo via Gitea raw URL                         │
+│   • 5-min SHA refresh check (identical pattern to files.go)            │
+└──────────────────────────────────┬─────────────────────────────────────┘
+                                   │
+                                   ▼
+                            Gitea: m/mWorkRepo
+                              templates/HLC/de.inf.lg.erwidg.docx
+                              templates/_base/de.inf.lg.erwidg.docx
+                              templates/_base/de.inf.lg.docx
+                              templates/_base/_skeleton.docx
+```
+
+**No new tables.** `paliad.documents` already exists; we write audit
+rows there but leave `file_path` NULL. The fallback chain uses
+filesystem-style paths inside the existing Gitea repo; no
+`submission_templates` table needed for Slice 1.
+
+---
+
+## §4 Slice 1 — what ships first
+
+Locked by Q5: **one template, end-to-end, on one project.**
+
+### 4.1 Target submission
+
+**`de.inf.lg.erwidg`** — Klageerwiderung (DE Verletzungs-LG).
+Reasoning:
+
+- High-frequency submission in patent practice; lawyers draft these
+  often enough that the tool earns its keep on day 1.
+- `primary_party='defendant'` — exercises the our_side variable.
+- `legal_source='DE.ZPO.276.1'` — exercises citation injection.
+- Pure-DE (no UPC complexity); easier first template for HLC's
+  Munich/Düsseldorf practice to author and review.
+- Klageerhebung (`de.inf.lg.klage`) is an obvious alternative; either
+  works. m can flip the target in his decision review if Klageerhebung
+  is the better proof case.
+
+### 4.2 Surfaces in Slice 1
+
+- **Project detail page** — new "Submissions" panel listing every
+  submission_code from the project's `proceeding_type` (via existing
+  `DeadlineRuleService`) with a `[Generieren]` button per row. Button
+  is enabled iff a template resolves AND `event_type='filing'` (no
+  `[Generieren]` on hearings/decisions — those don't have submissions).
+- **Project detail API** — `GET /api/projects/{id}/submissions` returns
+  the list of (submission_code, name, has_template) so the frontend
+  can render enabled/disabled state.
+- **Generate endpoint** — `POST /api/projects/{id}/submissions/{code}/generate`
+  returns `application/vnd.openxmlformats-officedocument.wordprocessingml.document`
+  with `Content-Disposition: attachment; filename="..."`.
+
+Slice 1 does NOT add:
+
+- A `/admin/submission-templates` editor (Gitea is the editor).
+- A Frist-detail "Generate" button (project-detail only in Slice 1;
+  Frist-level surface is a Slice 2 affordance).
+- A "Submissions" tab as a dedicated page (project-detail panel only).
+- Per-firm overrides beyond `templates/HLC/...` (the fallback chain is
+  WIRED but the only override directory exercised in Slice 1 is HLC).
+- The variable-contract sidebar UI (mirrors email-template editor) —
+  the contract is documented in §6 as code constants, surfaced as a
+  Slice 2 admin affordance.
+
+### 4.3 Slice 1 LoC estimate (informational, no time estimate)
+
+| File | Approx |
+|---|---|
+| `internal/handlers/submissions.go` (NEW) | 180 |
+| `internal/services/submission_templates.go` (NEW — registry + Gitea proxy, reuses files.go cache idea) | 200 |
+| `internal/services/submission_vars.go` (NEW — variable bag builder) | 220 |
+| `internal/services/submission_render.go` (NEW — docx merge engine wrapper) | 120 |
+| `internal/services/submission_render_test.go` (placeholder coverage + missing-var marker) | 180 |
+| `frontend/src/components/SubmissionsPanel.tsx` (NEW) | 80 |
+| `frontend/src/client/submissions.ts` (NEW — fetch + download) | 60 |
+| Wiring in `cmd/server/main.go` + `internal/handlers/handlers.go` | 30 |
+| i18n keys (`submissions.*`) DE+EN | 20 |
+| **Total** | **~1090 LoC** |
+
+Plus: ONE `.docx` template authored by HLC at
+`m/mWorkRepo/templates/HLC/de.inf.lg.erwidg.docx`, lawyer-reviewed
+before Slice 1 closes.
+
+---
+
+## §5 Template registry (Gitea-backed)
+
+### 5.1 Gitea layout
+
+```
+m/mWorkRepo (existing repo)
+└── templates/
+    ├── HLC/                              # FIRM_NAME-keyed override dir
+    │   └── de.inf.lg.erwidg.docx        # Slice 1 ships THIS file
+    ├── _base/                            # Cross-firm baseline
+    │   ├── de.inf.lg.erwidg.docx        # (Phase 2+)
+    │   ├── de.inf.lg.docx                # proceeding-family fallback
+    │   ├── upc.inf.cfi.docx              # (Phase 2+)
+    │   └── _skeleton.docx                # ultra-generic fallback
+    └── README.md                         # placeholder reference for authors
+```
+
+Naming convention is the submission_code with a `.docx` suffix.
+Proceeding-family fallback is the submission_code's first two
+dot-segments (`de.inf.lg` from `de.inf.lg.erwidg`).
+
+### 5.2 Lookup algorithm
+
+```go
+// services/submission_templates.go
+func (r *TemplateRegistry) Resolve(ctx context.Context, code string) (Template, error) {
+    firm := branding.Name                 // "HLC", or whatever FIRM_NAME is
+    family := familyOf(code)              // "de.inf.lg" from "de.inf.lg.erwidg"
+    candidates := []string{
+        fmt.Sprintf("templates/%s/%s.docx", firm, code),
+        fmt.Sprintf("templates/_base/%s.docx", code),
+        fmt.Sprintf("templates/_base/%s.docx", family),
+        "templates/_base/_skeleton.docx",
+    }
+    for _, path := range candidates {
+        if tmpl, ok := r.fetch(ctx, path); ok {
+            return tmpl, nil
+        }
+    }
+    return Template{}, ErrNoTemplate
+}
+```
+
+`fetch` does the same SHA-cache dance `handlers/files.go` already
+does, scoped to the templates subtree.
+
+### 5.3 Gitea auth
+
+Reuses `GITEA_TOKEN` env var that already exists for the HL Patents
+Style proxy. `m/mWorkRepo` is the same repo, same access token. No
+new secret to configure.
+
+### 5.4 What happens when no template resolves
+
+The fallback chain ends at `_skeleton.docx`. The skeleton is an
+intentionally bare-bones .docx (firm letterhead + party block + court
+address + case number + signature stub) that ships as part of the
+initial template set. In practice every Generate request resolves to
+something — but if even the skeleton 404s (misconfigured repo), the
+generator returns `503` with a clear error, the SubmissionsPanel
+button surfaces "Vorlagen-Repository nicht erreichbar".
+
+---
+
+## §6 Variable interpolation
+
+### 6.1 Engine
+
+Plain text replacement of `{{path.dot.notation}}` placeholders in the
+.docx body. Whitespace inside braces is trimmed
+(`{{ project.case_number }}` ≡ `{{project.case_number}}`).
+
+Implementation: a Go library that handles Word's run-fragmentation
+correctly (Word may split `{{project.case_number}}` across multiple
+`<w:r>` runs during editing; naive find/replace breaks). Candidates:
+
+- **`github.com/lukasjarosch/go-docx`** (~2k stars, MIT, pure Go,
+  maintained). Handles run-merging before replacement. **Inventor
+  recommendation.**
+- `github.com/nguyenthenguyen/docx` — older, less active.
+- Custom in-house implementation — ~200 LoC for a minimal robust
+  replacer that walks the document XML and merges runs that fall
+  inside a `{{…}}` span. Fallback if the library doesn't pan out.
+
+Slice 1: try `lukasjarosch/go-docx` first; if it has dealbreaker bugs
+(e.g. blows up on Word's autocorrect runs), fall back to the in-house
+~200 LoC walker. The library choice is an implementation detail; the
+placeholder syntax stays the same either way.
+
+### 6.2 Variable contract (v1 placeholder set)
+
+```
+{{firm.name}}                        — HLC (or whatever FIRM_NAME is)
+{{firm.signature_block}}             — Phase 2; v1 renders empty string
+
+{{today}}                            — 2026-05-19 (ISO)
+{{today.long_de}}                    — "19. Mai 2026"
+{{today.long_en}}                    — "19 May 2026"
+
+{{user.display_name}}                — "Maria Schmidt"
+{{user.email}}                       — "maria.schmidt@hlc.com"
+{{user.office}}                      — "Munich"
+
+{{project.title}}                    — paliad.projects.title
+{{project.reference}}                — paliad.projects.reference
+{{project.case_number}}              — paliad.projects.case_number
+{{project.court}}                    — paliad.projects.court
+{{project.patent_number}}            — paliad.projects.patent_number
+{{project.filing_date}}              — ISO date
+{{project.grant_date}}               — ISO date
+{{project.our_side}}                 — "claimant" | "defendant"
+{{project.our_side_de}}              — "Klägerin" | "Beklagte"
+{{project.instance_level}}           — "lg" | "olg" | "bgh" | ...
+{{project.proceeding.code}}          — e.g. "de.inf.lg"
+{{project.proceeding.name}}          — Verletzungsklage am Landgericht
+{{project.client_number}}            — paliad.projects.client_number
+{{project.matter_number}}            — paliad.projects.matter_number
+
+{{parties.claimant.name}}            — first paliad.parties row with role='claimant'
+{{parties.claimant.representative}}  — paliad.parties.representative
+{{parties.defendant.name}}           — first row with role='defendant'
+{{parties.defendant.representative}} — paliad.parties.representative
+{{parties.other.name}}               — first row with role NOT IN ('claimant','defendant') — court, intervener, etc.
+
+{{rule.submission_code}}             — "de.inf.lg.erwidg"
+{{rule.name}}                        — "Klageerwiderung"
+{{rule.name_en}}                     — "Statement of Defence"
+{{rule.legal_source}}                — "DE.ZPO.276.1"
+{{rule.legal_source_pretty}}         — "§ 276 Abs. 1 ZPO"
+{{rule.primary_party}}               — "defendant"
+{{rule.event_type}}                  — "filing"
+
+{{deadline.due_date}}                — date of the next pending deadline for this rule on this project
+{{deadline.due_date_long_de}}        — "26. Juni 2026"
+{{deadline.computed_from}}           — anchor description (e.g. "Klageerhebung am 12.05.2026 +6 Wochen")
+```
+
+Per-firm extensions (e.g. `{{firm.signature_block}}` filled from a
+table) are Phase 2.
+
+### 6.3 Variable bag construction
+
+`services/submission_vars.go` builds a flat `map[string]string`
+keyed by the dotted-path placeholders above. One pass over:
+
+1. `branding.Name` for `{{firm.*}}`
+2. `time.Now()` (with `Europe/Berlin` locale for the long forms) for
+   `{{today.*}}`
+3. `userService.GetByID()` for `{{user.*}}`
+4. `projectService.GetByID()` for `{{project.*}}`
+5. `partyService.ListByProject()` for `{{parties.*}}`
+6. `deadlineRuleService.GetByCode()` for `{{rule.*}}`
+7. `deadlineService.NextByRuleOnProject()` for `{{deadline.*}}`
+
+Missing values render as `[KEIN WERT: {dotted.path}]` (DE) or
+`[NO VALUE: {dotted.path}]` (EN) based on user locale. This is by
+design — the lawyer sees the gap in Word, fixes it (either in Word
+or in paliad and regenerates), rather than getting a 400 with a list
+of missing fields they then have to chase.
+
+### 6.4 Pretty-printing the legal_source
+
+`legal_source` in the rule corpus is shorthand
+(`DE.ZPO.276.1`, `UPC.RoP.23.1`). Lawyers don't want that in a brief;
+they want `§ 276 Abs. 1 ZPO` or `Rule 23.1 RoP UPC`.
+
+Slice 1 ships a small pretty-printer (`legalSourcePretty`) that knows
+the families we currently use:
+
+| Prefix | Pretty form (DE) | Pretty form (EN) |
+|---|---|---|
+| `DE.ZPO.<§>.<Abs>` | `§ <§> Abs. <Abs> ZPO` | `Section <§>(<Abs>) ZPO` |
+| `DE.ZPO.<§>` | `§ <§> ZPO` | `Section <§> ZPO` |
+| `UPC.RoP.<Rule>.<Sub>` | `Regel <Rule>.<Sub> VerfO UPC` | `Rule <Rule>.<Sub> RoP UPC` |
+| `UPC.RoP.<Rule>` | `Regel <Rule> VerfO UPC` | `Rule <Rule> RoP UPC` |
+| `DE.PatG.<§>` | `§ <§> PatG` | `Section <§> PatG` |
+| `EPC.<Art>` | `Art. <Art> EPÜ` | `Art. <Art> EPC` |
+| (unknown) | original string | original string |
+
+Unrecognised prefixes pass through unchanged (better than an
+incorrect prettification). The function is pure and unit-tested.
+
+---
+
+## §7 File naming
+
+Generated file name:
+
+```
+{rule.name}-{project.case_number}-{YYYY-MM-DD}.docx
+```
+
+Concrete example for the Slice 1 happy path:
+
+```
+Klageerwiderung-2 O 123_25-2026-05-19.docx
+```
+
+Rules:
+
+- `rule.name` honours user locale (`Klageerwiderung` for DE,
+  `Statement of Defence` for EN).
+- `project.case_number` slash/backslash → underscore (Word file name
+  hygiene), other characters preserved.
+- Date is ISO at server-local (`Europe/Berlin`) date.
+- If `project.case_number` is empty → fall back to a short hash of
+  `project_id` (8 hex chars) so the file still has a stable identifier
+  the lawyer can rename without losing track.
+
+---
+
+## §8 Authorization
+
+- **Visibility gate:** `paliad.can_see_project(project_id)` — anyone
+  who can see the project can generate. Matches every other write
+  surface on the project. The endpoint inlines the predicate;
+  unauthorised callers get 404 (not 403, to avoid project
+  enumeration).
+- **No profession floor.** A paralegal can generate a draft of a
+  Klageerwiderung; the draft is a Word doc that needs the associate's
+  approval downstream (in Word, on the document itself). Adding an
+  approval gate on generation would slow the workflow without
+  preventing anything that paliad's existing approval system doesn't
+  already cover at the substantive-act layer.
+- **Owner gate (Paliadin) does NOT apply.** This is the
+  submission-template engine, not Paliadin. All paliad users get the
+  feature once a template exists for the proceeding their project is
+  in.
+
+---
+
+## §9 Audit trail
+
+Two records per generation:
+
+### 9.1 `paliad.documents` row (audit-only, no binary)
+
+```sql
+INSERT INTO paliad.documents (id, title, doc_type, file_path, file_size,
+                              mime_type, ai_extracted, uploaded_by,
+                              project_id)
+VALUES (gen_random_uuid(),
+        '{rule.name} (generiert {YYYY-MM-DD})',
+        'generated_submission',           -- new doc_type value
+        NULL,                              -- no on-disk path
+        NULL,                              -- no file size (binary not persisted)
+        'application/vnd.openxmlformats-officedocument.wordprocessingml.document',
+        jsonb_build_object(
+            'submission_code', $1,
+            'template_path',  $2,         -- the gitea path we resolved
+            'template_sha',   $3,         -- pinned SHA from the cache fetch
+            'firm',           $4),
+        $user_id,
+        $project_id);
+```
+
+- `doc_type='generated_submission'` is a new value; no CHECK constraint
+  on doc_type today so this is additive.
+- `file_path NULL` is the marker that says "regenerate from inputs on
+  demand". The /api/projects/{id}/documents listing UI (Phase 2) will
+  surface a `[Erneut generieren]` action for these rows.
+- `ai_extracted` jsonb is repurposed for generation provenance
+  (template SHA, firm at time of generation). Naming is unfortunate
+  but the column shape fits; renaming the column is out of scope for
+  this task.
+
+### 9.2 `paliad.system_audit_log` row
+
+```sql
+INSERT INTO paliad.system_audit_log (event_type, actor_id, actor_email,
+                                     scope, scope_root, metadata)
+VALUES ('submission.generated',
+        $user_id,
+        $user_email,
+        'project',
+        $project_id::text,
+        jsonb_build_object(
+            'submission_code', $1,
+            'template_path',  $2,
+            'template_sha',   $3,
+            'document_id',    $document_id,
+            'firm',           $4));
+```
+
+Mirrors the existing `system_audit_log` event_type convention
+(`*.created`, `*.updated`, etc., from t-paliad-214).
+
+### 9.3 Verlauf entry (project event)
+
+`paliad.project_events` gets a row with `event_type='submission_generated'`
+and `timeline_kind='custom_milestone'` so the generation surfaces in
+SmartTimeline's audit-log toggle and on the project's Verlauf list.
+This is the user-visible footprint; the `system_audit_log` entry is
+the admin-visible audit footprint.
+
+---
+
+## §10 Frontend surface
+
+### 10.1 Slice 1 — SubmissionsPanel on project detail
+
+A new panel below the existing Verlauf / Deadlines panels on
+`/projects/{id}`:
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│ Schriftsätze                                                    │
+├─────────────────────────────────────────────────────────────────┤
+│ Klageerhebung                          [— Vorlage fehlt]        │
+│ Klageerwiderung                        [Generieren ↓]            │
+│ Replik                                 [— Vorlage fehlt]        │
+│ Duplik                                 [— Vorlage fehlt]        │
+└─────────────────────────────────────────────────────────────────┘
+```
+
+- Filter: only `event_type='filing'` rules from the project's
+  `proceeding_type` are listed. Hearings and decisions don't have
+  submissions.
+- Per-row state: `has_template` returned by
+  `GET /api/projects/{id}/submissions`. Disabled buttons show the
+  "Vorlage fehlt" hint (German default, English in EN locale).
+- Click `[Generieren ↓]` → POST → browser triggers download.
+- `aria-busy="true"` on the panel while a generation is in flight
+  (cheap, but lawyers feel slow networks).
+
+### 10.2 Out of scope for Slice 1
+
+- A standalone `/submissions` index page.
+- A Frist-detail "Generate" button.
+- A picker for template variants (1:N) — locked to fallback chain
+  (Q4), which is 1:1 from the user's perspective.
+- An "edit project, then regenerate" loop on the same UI.
+
+---
+
+## §11 AI-drafted body (deferred — sketch only)
+
+NOT in scope for t-paliad-215. Documented here so the next inventor
+picking up the "AI Klageerwiderung body" task has a clear starting
+shape.
+
+The natural fit: a new aichat persona (e.g. `paliadin-draft`) on
+mRiver, parallel to the existing `paliadin` persona.
+
+```
+{{ai.draft_body}}    # placeholder in the template
+
+→ generator detects {{ai.*}} placeholders in the template
+→ POSTs to aichat with persona=paliadin-draft + context:
+    - project state (variables already built)
+    - relevant project notes (paliad.notes)
+    - the deadline_rule corpus (rule + family)
+    - HL Patents Style guide chunks (RAG, eventually)
+→ aichat returns Markdown body
+→ generator injects into the .docx as one or more <w:p> paragraphs
+  (Word-friendly Markdown → docx mapping needed; substantive
+  formatting question for that follow-up)
+```
+
+Open shape questions for that follow-up (NOT for this design):
+
+- One persona per submission type, or one persona that branches on
+  `submission_code` in its system prompt?
+- Owner gate (m only) like current paliadin, or open to all
+  authenticated users?
+- Approval gate before the AI body lands in the .docx?
+- Cost accounting per generation?
+- Where does the prose context come from (notes / uploaded patent
+  spec / prior pleadings)?
+
+Re-uses, when that task fires:
+
+- This task's template engine, variable contract, fallback chain,
+  audit trail — all unchanged.
+- Just a new placeholder family (`{{ai.*}}`) + a new aichat persona +
+  a new admin gate.
+
+---
+
+## §12 Slice plan beyond Slice 1
+
+| Slice | Scope |
+|---|---|
+| 1 | One template (`de.inf.lg.erwidg`), engine + fallback chain + audit + SubmissionsPanel on project detail. THIS DESIGN. |
+| 2 | 3–5 more templates (Klageerhebung, SoC `upc.inf.cfi.soc`, SoD `upc.inf.cfi.sod`, Berufungsbegründung `de.inf.olg.begruendung`). Template authoring effort, no new architecture. |
+| 3 | Variable-contract sidebar in a new `/admin/submission-templates` page (mirrors `/admin/email-templates` shape). Shows what placeholders exist, with samples. Does NOT add an uploader UI — Gitea remains the editor. |
+| 4 | Per-firm override directory exercised (first non-HLC firm onboarded). |
+| 5 | Frist-detail "Generate" button + paliad.documents.deadline_id FK (mig 103+) for per-Frist draft history. |
+| 6 | (Separate task) AI-drafted body via Paliadin persona — see §11. |
+| 7 | (Future) Paliad UI uploader as alternative to Gitea, if the round-trip is friction. |
+
+Slices 2–5 are roadmap markers, not commitments — m decides cadence.
+
+---
+
+## §13 Trade-offs flagged
+
+1. **No binary persistence is a deliberate retention choice.** If a
+   lawyer regenerates after the project state changes (party renamed,
+   case_number corrected), the "regenerated" doc differs from the
+   "original generated" doc. This is a feature, not a bug — the source
+   of truth is paliad's project state, and the .docx is a derivative.
+   But the lawyer needs to be aware: there is no "what did I generate
+   last Thursday" recovery without re-saving locally. The
+   `paliad.documents` audit row records WHAT was generated (template
+   SHA + project state hash, optionally), but not the bytes.
+
+2. **Gitea round-trip for template edits is friction.** Template
+   authors edit `.docx` in Word, save, drag to Gitea web UI (or push
+   from a local clone). The 5-min SHA cache means edits surface
+   within 5 minutes (or instantly via `POST /api/files/refresh` —
+   already wired for the HL Patents Style template). If lawyers
+   complain, Phase 7 adds an in-paliad uploader. Until then, Gitea is
+   the editor.
+
+3. **Variable contract changes are coordinated edits.** Adding a new
+   `{{project.*}}` placeholder needs both a code change (var bag) AND
+   template edits (templates won't auto-discover new placeholders).
+   The variable-contract sidebar (Slice 3) is the mitigation —
+   template authors see what's available without reading the Go code.
+
+4. **`lukasjarosch/go-docx` library risk.** ~2k stars, MIT, maintained
+   — but it's a third-party dep we haven't used before. Fallback is
+   the in-house ~200-LoC walker. The placeholder syntax doesn't change
+   either way; Slice 1 can swap engines without touching templates or
+   callers.
+
+5. **`paliad.documents.ai_extracted` is repurposed for generation
+   provenance.** Slightly ugly naming because the column was added for
+   Phase H (AI Frist-Extraktion), which never shipped. Renaming the
+   column to something like `metadata` is out of scope for this task
+   but should be folded into the migration that lands when Phase 5
+   adds `deadline_id`.
+
+6. **`paliad.parties.role='claimant'`** — multiple claimants on a
+   project (multi-party suit) → Slice 1 picks the first row. v1
+   shortcut. Templates needing multi-claimant blocks become Phase 2
+   work (with a `{{#each parties.claimants}}` shape on top of
+   `lukasjarosch/go-docx`'s loop support).
+
+7. **No Word-side `MERGEFIELD` support.** Lawyers who insert Word
+   merge fields (via Insert → Quick Parts → Field) instead of typing
+   `{{…}}` will get untouched MERGEFIELD codes in the rendered output.
+   Decision: standardise on `{{…}}` syntax (cheap to type, visible
+   in the template, predictable). Document this in the `templates/
+   README.md`.
+
+8. **No template versioning UI.** Gitea provides git history; that's
+   the canonical version trail. Bumping to "use template X as of
+   commit Y" for an old project is a manual git-checkout-and-pin
+   exercise. Phase 2+ if anyone asks; not today.
+
+---
+
+## §14 Open follow-ups (NOT blocking)
+
+These items are NOT m-decisions; they're follow-ups for the coder
+shift or future inventor passes:
+
+- **Template authoring effort.** Slice 1 needs HLC to author/review
+  the actual Klageerwiderung template. That's a legal-review task that
+  can run in parallel with the engine code (template uploaded last
+  before the slice ships). Coordinate with m on who reviews.
+- **English version of `legalSourcePretty`.** Pretty-printer table in
+  §6.4 needs an EN column for every prefix — populated from existing
+  glossary entries where possible.
+- **i18n key sweep.** `submissions.*` namespace; ~20 keys for Slice 1
+  (panel title, button labels, "Vorlage fehlt" hints, error messages
+  for 503/404/422).
+- **README for template authors.** A `templates/README.md` in
+  m/mWorkRepo listing the available placeholders + naming convention
+  + a screenshot of a working template. Coder ships this alongside
+  Slice 1.
+- **CLAUDE.md update.** Add a "Submission templates" section
+  documenting the Gitea proxy, placeholder syntax, and the
+  `submission.generated` audit event_type.
+- **Cleanup task for `ai_extracted` naming.** Issue + Phase 5 mig.
+
+---
+
+## §15 What this design does NOT do
+
+To set the scope boundary cleanly:
+
+- ❌ Generate PDFs.
+- ❌ Generate emails or any non-.docx format.
+- ❌ Edit `.docx` files inside paliad (no in-browser Word editor).
+- ❌ Upload .docx to NetDocuments or any external DMS.
+- ❌ Translate templates DE↔EN automatically.
+- ❌ Validate the generated draft against any legal rule.
+- ❌ Sign, certify, or notarise the output.
+- ❌ Send the draft to court / e-filing.
+- ❌ AI-draft any prose. (See §11.)
+- ❌ Provide a paliad-UI template editor. (Gitea is the editor.)
+- ❌ Persist generated .docx bytes server-side. (Audit row only.)
+- ❌ Add a new database table. (`paliad.documents` is enough for v1.)
+- ❌ Require a database migration. (Slice 1 is migration-free.)
+
+Each of these is a defensible future-scope item; none belong in
+Slice 1.
+
+---
+
+## §16 Recommended implementer
+
+Pattern-fluent Sonnet coder. The substrate is well-trodden:
+
+- Gitea proxy + cache: `internal/handlers/files.go` is the template
+  to lift.
+- Variable contract pattern: `internal/services/email_template_variables.go`
+  is the template to mirror (different surface, identical shape).
+- Visibility gate: `internal/services/visibility.go` +
+  `paliad.can_see_project()` — standard everywhere.
+- Audit insert: `paliad.system_audit_log` (mig 102) + `paliad.documents`
+  (existing table, first writer).
+- Frontend SubmissionsPanel: stock TSX + client/.ts pattern, same shape
+  as the existing CardLayout / EventsList panels.
+
+The only novel piece is the docx merge library integration — that's a
+~200 LoC isolated module the coder can prototype on a sample .docx
+before wiring into the project flow.
+
+NOT cronus per project memory directive.
+
+---
+
+## §17 Acceptance criteria for Slice 1
+
+The coder considers Slice 1 done when:
+
+1. Pushing a `.docx` to `m/mWorkRepo/templates/HLC/de.inf.lg.erwidg.docx`
+   and visiting any project with `proceeding_type=de.inf.lg` surfaces
+   a `[Generieren]` Klageerwiderung button.
+2. Clicking it downloads a `.docx` named per §7 with all §6.2
+   placeholders resolved (or `[KEIN WERT: …]` markers for genuinely
+   missing project fields).
+3. Opening the downloaded .docx in Word renders cleanly (no run
+   fragmentation artefacts, no broken styles).
+4. A row appears in `paliad.documents` with `doc_type='generated_submission'`,
+   `file_path=NULL`, and `ai_extracted` jsonb carrying the template
+   path + SHA.
+5. A row appears in `paliad.system_audit_log` with `event_type='submission.generated'`.
+6. A row appears in `paliad.project_events` with
+   `event_type='submission_generated'` and shows up in the project's
+   Verlauf / SmartTimeline.
+7. Calling the endpoint without project visibility returns 404.
+8. Calling the endpoint with no template anywhere in the fallback
+   chain returns 503 with a clear error.
+9. Unit tests cover: placeholder rendering happy path, missing-var
+   marker, fallback chain (all 4 levels), file naming, slash
+   sanitization, legalSourcePretty for every prefix in §6.4.
+10. `go build ./... && go vet ./... && go test ./... && bun run build`
+    all clean.
+11. Manual test on the live database (test admin
+    `tester@hlc.de` per memory) against a project with a real
+    `de.inf.lg` proceeding succeeds end-to-end.
+
+---
+
+## §18 Approval gate
+
+Per inventor SKILL.md and project CLAUDE.md: this design needs m's
+go/no-go before any coder is hired. After m approves:
+
+- The head decides whether to hire the same worker as `/mai-coder`
+  with this design as the brief, or a fresh coder.
+- A coder shift takes this doc as the spec, ships Slice 1, opens a
+  PR (no self-merge — maria's gate).
+- Phase 11 (AI-drafted body) is a SEPARATE task — not auto-spawned.
+
+Inventor parks here.

docs/design-submission-page-2026-05-22.md

@@ -0,0 +1,668 @@
+# Design — Dedicated Submission/Schriftsätze page (t-paliad-238)
+
+**Author:** cronus (inventor)
+**Date:** 2026-05-22
+**Issue:** m/paliad (mai task t-paliad-238)
+**Branch:** `mai/cronus/inventor-dedicated`
+**Status:** DESIGN READY FOR REVIEW
+**Prior art:** `docs/design-submission-generator-2026-05-19.md` (t-paliad-215). This doc deepens that design rather than replacing it — every section below references the corresponding §x there when the shape is reused.
+
+---
+
+## §0 TL;DR
+
+Today's "Schriftsätze" tab on the project detail page lists each filing-type rule and offers a one-click [Generieren] that streams a clean (format-only) `.docx` of the universal HL Patents Style template. There is no customization — variables, parties, dates, optional passages: none of it is filled in. The lawyer downloads the firm style, opens it in Word, and types everything by hand.
+
+This design adds a **dedicated submission page** at `/projects/{id}/submissions/{code}/draft` where the lawyer:
+
+1. Picks (or creates) a named **draft** for one (project, submission_code).
+2. Sees a sidebar with every `{{placeholder}}` the merge engine knows, pre-filled from the project's data (parties, court, case number, dates, legal_source) — editable inline. Auto-saved.
+3. Sees a read-only preview pane showing the merged document body as HTML.
+4. Clicks **Export → .docx** to download a fully-merged Word file (template + project + lawyer overrides), ready to edit.
+
+Old [Generieren] button stays as the one-click "quick export with empty placeholders" path; the new [Bearbeiten] button next to it deep-links to the draft editor. Drafts persist as `paliad.submission_drafts` rows so the lawyer can come back next week, multiple drafts per submission code, RLS through `paliad.can_see_project`.
+
+**Reuses** the deleted Slice 1 backend (`SubmissionVarsService` from commit `3677c81`, in-house `SubmissionRenderer` from `8ea3509`, `patent_number_upc` helper from `1765d5e`) wholesale — those files are salvageable from git history and slot back in with one new service (`SubmissionDraftService`) and the new schema. **Reuses** the `internal/handlers/files.go` Gitea proxy pattern for per-submission_code templates in `m/mWorkRepo/templates/{FIRM_NAME}/{code}.docx` (chain: firm → base/code → base/family → skeleton) — same fallback chain m locked in the 2026-05-19 design (§5).
+
+Three slices: **A** = schema + new page + variables-only export against the universal `.dotm` (one slice; ships the editor end-to-end); **B** = per-`submission_code` `.docx` templates with the fallback-chain registry (template authoring is the bottleneck, not code); **C** = toggleable passages (boilerplate sections the lawyer can include/exclude before export).
+
+Read-only inventor design. Implementation gate is m's go/no-go on this doc through head.
+
+---
+
+## §1 Premises verified live (2026-05-22)
+
+Anchored against the running paliad codebase + youpc Supabase, not against CLAUDE.md or memory. Every claim that load-bears the design was checked against the live system.
+
+| Claim | Verification |
+|---|---|
+| Today's `/api/projects/{id}/submissions` is **format-only**; no variables. | `internal/handlers/submissions.go:155-245`: handler fetches the universal `hl-patents-style.dotm` from the in-process `fileRegistry` cache, calls `services.ConvertDotmToDocx`, writes one `system_audit_log` row, streams. No project data merged. `frontend/src/client/submissions.ts` confirms the client side: POST → blob → download. The richer engine (`SubmissionVarsService` + `TemplateRegistry` + `SubmissionRenderer`) was reverted to format-only in commit `d86cac0` (t-paliad-230). |
+| Original Slice 1 backend is preserved in git history and salvageable. | `git show 3677c81:internal/services/submission_vars.go` (484 LoC, 7-namespace placeholder bag), `git show 8ea3509:internal/services/submission_render.go` (in-house run-fragmentation-aware merger, ~315 LoC), `git show 3677c81:internal/services/submission_templates.go` (442 LoC fallback-chain registry), `git show 1765d5e:internal/services/submission_vars.go` (Slice 2 added `{{project.patent_number_upc}}` helper). All four files compile against today's services (`ProjectService`, `PartyService`, `UserService`, `branding.Name`) — no API drift since 2026-05-20. |
+| `paliad.projects` carries everything the variable bag needs. | `internal/models/project.go:123` — `Title, Reference, CaseNumber, Court, PatentNumber, FilingDate, GrantDate, OurSide, InstanceLevel, ProceedingTypeID, ClientNumber, MatterNumber`. Unchanged since the original design. |
+| `paliad.parties` carries party data scoped per project. | `internal/models/project.go:567` (`Party{ID, ProjectID, Name, Role, Representative, ContactInfo}`); `PartyService.ListForProject(ctx, userID, projectID)` already exists at `internal/services/party_service.go`. Visibility flows from `ProjectService.GetByID` → `can_see_project`. |
+| `paliad.deadline_rules` published rows resolve by `submission_code`. | The same query the format-only handler uses (`internal/handlers/submissions.go:255-280`) — `lifecycle_state='published' AND is_active=true ORDER BY sequence_order LIMIT 1`. Today the corpus carries ~254 rules, ~214 published; covers DE-inf-LG, DE-inf-OLG, DE-inf-BGH, UPC-inf-CFI, DE-PatG-DPMA, DE-PatG-BPatG, EPO oppositions. |
+| Migration tracker is at 106; file list extends to 118 (other-branch work) on the worktree. | `SELECT version FROM paliad.paliad_schema_migrations ORDER BY version DESC LIMIT 1` → 106. `ls internal/db/migrations/` → `…118_paliadin_aichat_conversation`. The next free number for *this* branch's migration is **119** (collisions only if another worktree commits 119 first, in which case the coder picks the next unused). |
+| `paliad.can_see_project(uuid)` is the canonical RLS predicate. | Mig 055; every other table that gates on project visibility uses it. The new `submission_drafts` table follows the same pattern. |
+| The Schriftsätze tab already exists on project detail. | `frontend/src/projects-detail.tsx:91` (`data-tab="submissions"`), section `#tab-submissions` at line 629. Empty / no-proceeding / table-of-rules states already wired. The page-level route `GET /projects/{id}/submissions` exists at `internal/handlers/handlers.go:472` and renders the same project detail page with the submissions tab pre-selected (`#tab-submissions` URL fragment + tab activation). **No new top-level route needed**; this design adds a *deeper* route `/projects/{id}/submissions/{code}/draft` and `/draft/{draftID}`. |
+| `internal/handlers/files.go` carries the Gitea proxy + SHA-cache pattern. | Same template the original Slice 1 design lifted (in `templates/_base/de.inf.lg.erwidg.docx @ SHA 7f97b7f9` per memory). 5-min refresh, in-process cache, single-replica deployment. Reusable wholesale. |
+| `lukasjarosch/go-docx` is NOT a deal we made. | The original 2026-05-19 design recommended it, but the shipped Slice 1 (commit `8ea3509`) went with an **in-house renderer** because the library refuses to replace sibling `{{a}} ./. {{b}}` placeholders in the same run. The in-house engine handles cross-run fragmentation in ~315 LoC. **This design reuses the in-house engine, no new Go dependency.** Memory entry `ca6de586` corroborates the engine decision verbatim. |
+| `FIRM_NAME` defaults to "HLC", overridable. | `internal/branding.Name` (read once at process start). Templates land under `templates/HLC/...` for the default; the fallback chain handles per-firm overrides without code change. |
+| The PoC Paliadin is owner-gated; the submission page is NOT. | `internal/services/paliadin.go:52` — `PaliadinOwnerEmail = "matthias.siebels@hoganlovells.com"`. This is the LLM-shell-out boundary, irrelevant to template-merge. Every paliad user who can see a project can edit its submission drafts. |
+| The `entity-table` row contract is enforced. | `.claude/CLAUDE.md` → "Whole-card / whole-row click → use a JS row handler". The new draft list (when a submission_code has multiple drafts) follows the same pattern. |
+
+**Doc-vs-live conflicts found:** none material. `docs/project-status.md` doesn't mention t-paliad-215 or t-paliad-230 yet — that's a documentation lag, not a design risk.
+
+---
+
+## §2 m's decisions (2026-05-22)
+
+The task brief (mai task t-paliad-238 description) carries inventor recommendations (R) for ten open questions. Per project CLAUDE.md inventor → head escalation policy: inventor defaults to (R) unless the pick is materially expensive or risk-bearing, in which case the head escalates to m. The matrix below records the (R) defaults this design adopts; the four genuinely-material picks are escalated to head in §11.
+
+| # | Question (from task brief) | Default adopted | Source |
+|---|---|---|---|
+| Q1 | Page location | **Deep page under project — `/projects/{id}/submissions/{code}/draft` and `…/draft/{draftID}`** | (R) — keeps URL self-describing and shareable with the project. |
+| Q2 | State persistence | **Server-side draft, `paliad.submission_drafts` keyed on `(project_id, submission_code, user_id, name)` with autosave** | (R) — multiple drafts per code, named; resumable across sessions. |
+| Q3 | Variable layer | **Resurrect `submission_vars.go` from commit `3677c81` + `1765d5e` (incl. `patent_number_upc`); resolve at export time** | (R) — proven shape, ~30 placeholders, 7 namespaces. |
+| Q4 | Customization surface (UI) | **Structured sidebar (variable list, editable values) + read-only HTML preview pane** | (R) — sidebar drives the merge; preview reflects the result. |
+| Q5 | Template source | **(a) per-`submission_code` `.docx` in `m/mWorkRepo/templates/{FIRM_NAME}/...` via Gitea proxy + fallback chain** | (R) — Word is the authoring surface lawyers know; mWorkRepo is the existing vehicle. |
+| Q6 | Customization options beyond variables | **v1: variables only. Toggleable passages = Slice C** | (R) — citation insertion waits for the sources system. |
+| Q7 | Migration / data shape | **See §4** | (R) — followed task brief's column list, refined for RLS + cascade + index. |
+| Q8 | Export endpoint | **`POST /api/projects/{id}/submissions/{code}/drafts/{draftID}/export` → `.docx`** | (R) — reuses `ConvertDotmToDocx` strip-macros path but adds merge step. |
+| Q9 | Schriftsätze tab integration | **Keep list + existing "Generieren" (one-click format-only); add new "Bearbeiten" button per row that deep-links to `/projects/{id}/submissions/{code}/draft`** | (R) — additive, no churn for users who only want the firm style. |
+| Q10 | Variable-merge library | **In-house renderer from commit `8ea3509` (no new Go module)** | (R) — the 2026-05-19 design recommended `lukasjarosch/go-docx`, but the shipped Slice 1 reverted to an in-house engine because the library refused sibling placeholders. The in-house engine handles run-fragmentation in ~315 LoC and is already battle-tested against the corpus. |
+
+Inventor-defaulted (not in the (R) matrix; clear right answer):
+
+| # | Topic | Default | Reasoning |
+|---|---|---|---|
+| D1 | Authorization | `paliad.can_see_project(project_id)` only. No profession floor. | Matches every other write surface on a project. Draft is a Word doc; lawyer's substantive review happens downstream. |
+| D2 | Missing-placeholder behaviour | `[KEIN WERT: {key}]` / `[NO VALUE: {key}]` in the rendered preview AND in the exported .docx, per `DefaultMissingMarker(lang)` from `8ea3509` | Same call the original design made. Lawyer sees the gap in Word, fixes in paliad, regenerates. Better than 400ing. |
+| D3 | Editor surface for templates | Gitea-only for v1 (admin edits .docx in Word, commits to mWorkRepo). | Per the original design §5. A paliad-side uploader is a Slice C+ affordance only if Gitea round-trip is friction. |
+| D4 | Audit trail | One `paliad.system_audit_log` row per export (`event_type='submission.exported'`) + one `paliad.project_events` row (`event_type='submission_exported'`) so the export surfaces in Verlauf / SmartTimeline. **Draft create/update do NOT audit** — autosave noise would dominate the log. | Mirrors the existing `submission.generated` row from `internal/handlers/submissions.go:333-339`. The Verlauf entry is the user-visible footprint; the system_audit_log entry is the admin-visible audit footprint. |
+| D5 | Preview engine | Server-side merge → render to HTML for preview pane. Same `SubmissionRenderer` walks the .docx, but for the preview it strips `<w:r>` / `<w:p>` to plain HTML paragraphs (no styling beyond paragraph breaks + bold/italic carry-through). The export endpoint produces the real .docx with all formatting preserved. | Cheaper than client-side OOXML parsing; matches the read-only Q4 contract. The preview is a fidelity guide, not a WYSIWYG editor — final formatting comes from Word. |
+| D6 | Draft autosave cadence | Debounce 500ms after the lawyer stops typing in a variable field; PATCH `…/drafts/{draftID}` with the diff. No optimistic locking — last-write-wins per (project, submission_code, user) draft, and we never multi-user a single draft (one row per `user_id`). | Standard textarea autosave; the data is the lawyer's own draft, not a shared object. |
+| D7 | Variable contract surfacing | Each placeholder in the sidebar shows: dotted key (e.g. `project.case_number`), human label (DE/EN), current resolved value (from project state), and an editable override field. Override empty → fall back to project state at export. Override filled → carry the lawyer's value into the merge. | Lawyer never has to leave the page to fix a project-level field; AND lawyer can locally override (e.g. "Court is wrong on this draft, but I don't want to edit the project") without polluting project state. |
+| D8 | Draft naming | First draft per (project, submission_code, user) auto-named "Entwurf 1" (DE) / "Draft 1" (EN). Lawyer can rename inline. Subsequent drafts auto-name "Entwurf 2", etc. The (project_id, submission_code, user_id, name) tuple is the unique constraint — two drafts can't share a name for the same submission of the same project. | Lets the lawyer keep a "submitted version" and a "scratch" version side-by-side. |
+
+---
+
+## §3 Architecture overview
+
+```
+┌─────────────────────────────────────────────────────────────────────────────┐
+│  Project detail (existing) — /projects/{id} with #tab-submissions          │
+│  ┌───────────────────────────────────────────────────────────────────────┐ │
+│  │ Schriftsätze tab                                                      │ │
+│  │  Klageerwiderung                  [Bearbeiten ↗] [Generieren ↓]      │ │
+│  │  Schriftsatz der Klägerin (SoC)   [Bearbeiten ↗] [Generieren ↓]      │ │
+│  │  Replik                           [Bearbeiten ↗] [Generieren ↓]      │ │
+│  └────────┬──────────────────────────────────────────┬─────────────────────┘ │
+│           │ "Bearbeiten" deep-link                    │ "Generieren" =       │
+│           │                                           │ existing one-click   │
+│           ▼                                           │ format-only export   │
+└───────────┼───────────────────────────────────────────┼──────────────────────┘
+            │                                           │
+            ▼                                           │
+┌──────────────────────────────────────────────────────────────────────────────┐
+│  NEW Submission draft page — /projects/{id}/submissions/{code}/draft         │
+│  (lands on most-recent draft for this user, or creates "Entwurf 1")          │
+│                                                                              │
+│  ┌──── Sidebar (sticky left) ────────┐  ┌──── Preview pane (right) ───────┐ │
+│  │ Schriftsatz: Klageerwiderung      │  │  [HTML-rendered merge of       │ │
+│  │ Entwurf 1 ▼  [+ Neuer Entwurf]    │  │   template + variables +       │ │
+│  │ ───────────────────────────────── │  │   overrides]                    │ │
+│  │ project.case_number               │  │                                 │ │
+│  │   2 O 123/25  [override?]         │  │  Klage gegen die                │ │
+│  │ parties.claimant.name             │  │  Beklagte BMW AG, vertreten     │ │
+│  │   BMW AG  [override?]             │  │  durch …                        │ │
+│  │ deadline.due_date                 │  │                                 │ │
+│  │   2026-06-12  [override?]         │  │  Sehr geehrte Damen und Herren, │ │
+│  │ ...                               │  │                                 │ │
+│  │                                   │  │  [KEIN WERT: project.our_side]  │ │
+│  │ [✎ Bearbeiten] inline             │  │                                 │ │
+│  └───────────────────────────────────┘  └──────────────────────────────────┘ │
+│                                                                              │
+│                          [⬇ Als .docx exportieren]                           │
+└──────────────────────────────────┬───────────────────────────────────────────┘
+                                   │
+                                   ▼
+              POST /api/projects/{id}/submissions/{code}/drafts/{draftID}/export
+                                   │
+                                   ▼
+┌──────────────────────────────────────────────────────────────────────────────┐
+│  handlers/submission_drafts.go (NEW)                                         │
+│   1. Auth: ProjectService.GetByID → can_see_project                          │
+│   2. Load draft row (RLS via project visibility)                             │
+│   3. SubmissionVarsService.Build (project + parties + rule + next-Frist)     │
+│   4. Apply draft.overrides on top of bag                                     │
+│   5. TemplateRegistry.Resolve(code) — fallback chain → bytes + SHA           │
+│      (Slice A: skips registry, fetches the universal .dotm directly)         │
+│   6. SubmissionRenderer.Render(bytes, bag, missingMarker) → .docx bytes      │
+│   7. Audit: system_audit_log + project_events                                │
+│   8. Stream .docx with Content-Disposition: attachment                       │
+└──────────────────────────────────────────────────────────────────────────────┘
+```
+
+**No backend changes to today's Schriftsätze tab** — its list endpoint + one-click generate stay exactly as they are. The new page is additive.
+
+---
+
+## §4 Schema (`paliad.submission_drafts`)
+
+Migration `119_submission_drafts.up.sql` (next free number on this branch; coder bumps if 119 is taken at write time).
+
+```sql
+CREATE TABLE paliad.submission_drafts (
+    id              uuid PRIMARY KEY DEFAULT gen_random_uuid(),
+    project_id      uuid NOT NULL REFERENCES paliad.projects(id) ON DELETE CASCADE,
+    submission_code text NOT NULL,
+    user_id         uuid NOT NULL REFERENCES paliad.users(id)    ON DELETE CASCADE,
+    name            text NOT NULL,                                -- "Entwurf 1", lawyer-renameable
+
+    overrides       jsonb NOT NULL DEFAULT '{}'::jsonb,           -- { "project.case_number": "2 O 999/25", ... }
+                                                                  -- empty value = "don't override, use bag"
+                                                                  -- present key  = "use this verbatim"
+
+    last_exported_at  timestamptz,                                -- NULL until first export
+    last_exported_sha text,                                       -- template SHA at last export (audit aid)
+
+    created_at      timestamptz NOT NULL DEFAULT now(),
+    updated_at      timestamptz NOT NULL DEFAULT now(),
+
+    CONSTRAINT submission_drafts_unique_per_user
+        UNIQUE (project_id, submission_code, user_id, name)
+);
+
+CREATE INDEX submission_drafts_project_user_idx
+    ON paliad.submission_drafts (project_id, user_id, submission_code, updated_at DESC);
+
+ALTER TABLE paliad.submission_drafts ENABLE ROW LEVEL SECURITY;
+
+CREATE POLICY submission_drafts_visible
+    ON paliad.submission_drafts
+    FOR ALL
+    USING (paliad.can_see_project(project_id));
+
+-- updated_at trigger pattern (same shape as paliad.notizen, etc.).
+CREATE TRIGGER submission_drafts_updated_at
+    BEFORE UPDATE ON paliad.submission_drafts
+    FOR EACH ROW EXECUTE FUNCTION paliad.tg_set_updated_at();
+```
+
+**No changes to `paliad.deadline_rules`.** The task brief floats a `template_body_de/_en` Markdown column as alternative (b) — rejected per Q5 default. Templates stay in Gitea.
+
+**No changes to `paliad.documents`.** The original Slice 1 design wrote an `audit-only` row (`file_path NULL`) per generation; this design **does not** — `system_audit_log` + `project_events` carry the audit trail, and `paliad.documents` is reserved for actually-uploaded documents (a Phase 2 affordance per §13.5 of the 2026-05-19 design). If m wants the `documents` row for symmetry with future "I uploaded my edited version" UX, the coder can land it in a follow-up migration; it's not load-bearing for this design.
+
+### 4.1 RLS read-vs-write
+
+`can_see_project` is the only gate — the policy applies to FOR ALL operations. Anyone who can see a project can create / read / update / export drafts under that project, for their own user_id. Inter-user draft visibility (paralegal sees associate's drafts) is **NOT** a requirement in v1 — the unique constraint includes `user_id` and we don't expose a "drafts by other users on this project" endpoint. Multi-user collaboration on a single draft is out of scope.
+
+### 4.2 Down migration
+
+```sql
+DROP TABLE IF EXISTS paliad.submission_drafts;
+```
+
+No data loss concern at design time — feature ships without legacy drafts.
+
+---
+
+## §5 Service layer
+
+### 5.1 Resurrect from git (no new code)
+
+```
+internal/services/submission_vars.go         RESURRECT from 3677c81 + Slice 2 patch from 1765d5e (patent_number_upc)
+internal/services/submission_render.go       REPLACE the format-only convert with the in-house renderer from 8ea3509.
+                                              KEEP the convert helper (ConvertDotmToDocx) — Slice A still needs it to
+                                              strip macros from the universal .dotm before the merge step runs.
+internal/services/submission_templates.go    RESURRECT from 3677c81 — Gitea-backed TemplateRegistry with fallback chain.
+                                              NOT wired in Slice A (universal .dotm only); wired in Slice B.
+```
+
+The three files were ~926 LoC + 350 LoC + 35 LoC patch when shipped. They compile against today's services (`ProjectService`, `PartyService`, `UserService`, `branding.Name`); zero API drift since their deletion. The resurrection is a copy-paste from `git show`, plus a one-line wiring in `cmd/server/main.go` + `internal/handlers/handlers.go`.
+
+### 5.2 New service — `SubmissionDraftService`
+
+```go
+// internal/services/submission_draft_service.go (NEW, ~300 LoC)
+
+type SubmissionDraftService struct {
+    db       *sqlx.DB
+    projects *ProjectService
+}
+
+type SubmissionDraft struct {
+    ID              uuid.UUID
+    ProjectID       uuid.UUID
+    SubmissionCode  string
+    UserID          uuid.UUID
+    Name            string
+    Overrides       PlaceholderMap   // jsonb → map[string]string
+    LastExportedAt  *time.Time
+    LastExportedSHA *string
+    CreatedAt, UpdatedAt time.Time
+}
+
+// List returns every draft for (project, submission_code, user) ordered by updated_at DESC.
+// Visibility flows through projects.GetByID.
+func (s *SubmissionDraftService) List(ctx context.Context, userID, projectID uuid.UUID, submissionCode string) ([]SubmissionDraft, error)
+
+// Get returns a single draft by ID, gated on project visibility.
+func (s *SubmissionDraftService) Get(ctx context.Context, userID, draftID uuid.UUID) (*SubmissionDraft, error)
+
+// EnsureLatest returns the user's most-recently-updated draft for (project, submission_code).
+// Creates "Entwurf 1" / "Draft 1" if none exists. Idempotent on repeat calls.
+func (s *SubmissionDraftService) EnsureLatest(ctx context.Context, userID, projectID uuid.UUID, submissionCode, lang string) (*SubmissionDraft, error)
+
+// Create makes a new draft with an auto-incremented "Entwurf N" name (lawyer can rename via Update).
+func (s *SubmissionDraftService) Create(ctx context.Context, userID, projectID uuid.UUID, submissionCode, lang string) (*SubmissionDraft, error)
+
+// Update patches the draft. Permitted fields: name, overrides. last_exported_* is set by the export handler.
+func (s *SubmissionDraftService) Update(ctx context.Context, userID, draftID uuid.UUID, patch DraftPatch) (*SubmissionDraft, error)
+
+// Delete archives the draft. ON DELETE CASCADE from project takes care of project-archival fallout.
+func (s *SubmissionDraftService) Delete(ctx context.Context, userID, draftID uuid.UUID) error
+
+// MarkExported updates last_exported_at + last_exported_sha after a successful export.
+func (s *SubmissionDraftService) MarkExported(ctx context.Context, draftID uuid.UUID, sha string) error
+```
+
+`DraftPatch` is a `struct { Name *string; Overrides *PlaceholderMap }` — nil pointer = "no change", non-nil = "set to this". `Overrides` is replace-semantics (lawyer's sidebar sends the full map); the service does not merge.
+
+### 5.3 Wiring
+
+```go
+// cmd/server/main.go (additions, no replacements)
+draftSvc := services.NewSubmissionDraftService(db, projectSvc)
+varsSvc  := services.NewSubmissionVarsService(db, projectSvc, partySvc, userSvc)
+// Slice B only:
+tplRegistry := services.NewTemplateRegistry(os.Getenv("GITEA_TOKEN"), branding.Name)
+```
+
+No new env var. `GITEA_TOKEN` is already documented in CLAUDE.md and used by `internal/handlers/files.go`.
+
+---
+
+## §6 UI surface
+
+### 6.1 Page layout
+
+`/projects/{id}/submissions/{code}/draft` lands on the user's latest draft for that (project, code). `/projects/{id}/submissions/{code}/draft/{draftID}` opens a specific draft (e.g. "Entwurf 2"). Both routes call the same renderer + client bundle; the difference is which draft `EnsureLatest` vs `Get` returns.
+
+```
+┌──────────────────────────────────────────────────────────────────────────────┐
+│ ← Zurück zum Projekt: BMW AG ./. Bosch GmbH                                  │
+│   Schriftsatz: Klageerwiderung (DE.ZPO.276.1)  •  Entwurf 1                  │
+│                                            [⬇ Als .docx exportieren]        │
+├────────── Sidebar (sticky) ────────────────┬─────── Preview ────────────────┤
+│ Entwurf 1   ▼                              │  [HTML-rendered merge]         │
+│   • Entwurf 1  (zuletzt 23 Mai 2026)       │                                │
+│   • Entwurf 2  (zuletzt 20 Mai 2026)       │  An das Landgericht München I  │
+│   • [+ Neuer Entwurf]                      │  Pacellistr. 5                 │
+│                                            │  80333 München                 │
+│ ─────────────────────────────────────────  │                                │
+│ Variablen                                  │  In der Sache                  │
+│   firm.name           HLC                  │                                │
+│   project.case_number 2 O 123/25  [✎]     │  BMW AG, vertreten durch …    │
+│   project.court       LG München I  [✎]   │     — Klägerin —              │
+│   parties.claimant.name BMW AG     [✎]    │                                │
+│   parties.defendant.name Bosch GmbH [✎]   │  gegen                         │
+│   parties.defendant.representative           │                                │
+│       Dr. Maria Schmidt              [✎]   │  Bosch GmbH …                  │
+│   deadline.due_date   2026-06-12    [✎]   │     — Beklagte —              │
+│   rule.legal_source_pretty                 │                                │
+│       § 276 Abs. 1 ZPO              ✓     │  Sehr geehrte Damen und Herren,│
+│   …                                        │                                │
+│                                            │  [KEIN WERT: project.our_side] │
+│ ─────────────────────────────────────────  │                                │
+│ [Entwurf umbenennen] [Entwurf löschen]     │                                │
+└────────────────────────────────────────────┴────────────────────────────────┘
+```
+
+Sidebar grouping (top-to-bottom, locale-aware labels):
+
+1. **Schriftsatz** (rule.* — read-only metadata: name, legal_source_pretty, primary_party)
+2. **Mandanten & Parteien** (parties.*)
+3. **Verfahren** (project.* — case_number, court, patent_number, patent_number_upc, our_side, …)
+4. **Frist** (deadline.* — due_date, computed_from)
+5. **Kanzlei & Datum** (firm.*, user.*, today.*)
+
+Each placeholder row shows: human label (DE/EN), resolved value, edit icon. Click [✎] expands an inline text input pre-filled with the current value. Blur or Enter → debounced autosave (500ms). Empty override → revert to bag value.
+
+### 6.2 Preview pane
+
+Read-only HTML. The same `SubmissionRenderer.Render(...)` call that produces the .docx for export ALSO produces a sidecar HTML preview (the in-house renderer walks `<w:p>` / `<w:r>` runs and emits `<p>` / inline `<strong>` / `<em>` based on `<w:b>` / `<w:i>` flags). Preview re-renders on every autosave round-trip (cheap: server-side merge, ~10ms for a 5-page brief). Loading state: ghost-skeleton paragraphs during the round-trip.
+
+This is the SLIGHTLY non-trivial coder piece: the in-house renderer today emits .docx; the coder adds a parallel `RenderHTML` path that walks the same tree but emits HTML. Same regex, same run-merge logic, different writer. Coder estimates ~120 LoC on top of the resurrected `submission_render.go`.
+
+### 6.3 Routing + handlers
+
+```
+GET  /projects/{id}/submissions/{code}/draft                  → page (lands on latest, creates if none)
+GET  /projects/{id}/submissions/{code}/draft/{draftID}        → page (specific draft)
+GET  /api/projects/{id}/submissions/{code}/drafts             → list drafts for current user
+POST /api/projects/{id}/submissions/{code}/drafts             → create new draft → returns row + redirect target
+GET  /api/projects/{id}/submissions/{code}/drafts/{draftID}   → single draft + resolved bag + HTML preview
+PATCH /api/projects/{id}/submissions/{code}/drafts/{draftID}  → update name / overrides; returns new preview
+DELETE /api/projects/{id}/submissions/{code}/drafts/{draftID} → delete
+POST /api/projects/{id}/submissions/{code}/drafts/{draftID}/export
+     → .docx download (application/vnd.openxmlformats-officedocument.wordprocessingml.document)
+```
+
+Page-route handler is `handleSubmissionDraftPage` in `internal/handlers/submission_drafts.go` — calls `handleProjectsDetailPage` shape (returns HTML for an SSR layout) with a deep-route flag, OR ships an entirely new TSX page module. Inventor default: **new TSX page** at `frontend/src/submission-draft.tsx` rendering its own layout. Lighter than retrofitting the existing project-detail page with conditional panels, and the URL semantics demand it (`#tab-submissions` is the tab; `/draft/{id}` is a distinct page).
+
+### 6.4 Schriftsätze tab — additive change
+
+```diff
+- // Each row: [Generieren ↓]
++ // Each row: [Bearbeiten ↗] [Generieren ↓]
+```
+
+`[Bearbeiten ↗]` → `window.location.href = "/projects/{id}/submissions/{code}/draft"`. `[Generieren ↓]` stays as today (one-click format-only export of the universal .dotm). For users who want zero-config "give me a clean firm style template", `[Generieren]` is the path; for users who want a merged draft, `[Bearbeiten]` is the path.
+
+Per the `.entity-table` row contract in CLAUDE.md, the row itself becomes clickable (navigates to `/draft`), with the `Generieren` button stopping propagation. The `entity-table--readonly` modifier is removed.
+
+---
+
+## §7 Variable contract (v1 placeholder set)
+
+Reproduced from the resurrected `submission_vars.go` (commits `3677c81` + `1765d5e`). The sidebar's "Variablen" section enumerates this list in the exact same order as `addProjectVars` / `addPartyVars` / etc., grouped per §6.1.
+
+```
+firm.name                              — branding.Name (HLC or FIRM_NAME override)
+firm.signature_block                   — empty in v1 (Phase 2 affordance)
+
+today                                  — 2026-05-22 (ISO, Europe/Berlin)
+today.iso                              — ISO short
+today.long_de                          — "22. Mai 2026"
+today.long_en                          — "22 May 2026"
+
+user.display_name                      — paliad.users.display_name
+user.email                             — paliad.users.email
+user.office                            — paliad.users.office
+
+project.title                          — paliad.projects.title
+project.reference                      — paliad.projects.reference
+project.case_number                    — paliad.projects.case_number
+project.court                          — paliad.projects.court
+project.patent_number                  — DE/inline form "EP 1 234 567 B1"
+project.patent_number_upc              — UPC parenthesised form "EP 1 234 567 (B1)"  (Slice 2 helper, 1765d5e)
+project.filing_date                    — ISO date
+project.grant_date                     — ISO date
+project.our_side                       — claimant | defendant
+project.our_side_de                    — "Klägerin" | "Beklagte"
+project.our_side_en                    — "Claimant" | "Defendant"
+project.instance_level                 — lg | olg | bgh | cfi | …
+project.client_number                  — paliad.projects.client_number
+project.matter_number                  — paliad.projects.matter_number
+project.proceeding.code                — e.g. "de.inf.lg"
+project.proceeding.name                — locale-aware (DE: Verletzungsklage am Landgericht)
+project.proceeding.name_de             — explicit DE
+project.proceeding.name_en             — explicit EN
+
+parties.claimant.name                  — first paliad.parties row with role='claimant'
+parties.claimant.representative
+parties.defendant.name                 — first row with role='defendant'
+parties.defendant.representative
+parties.other.name                     — first non-claimant/defendant row
+parties.other.representative
+
+rule.submission_code                   — "de.inf.lg.erwidg"
+rule.name                              — locale-aware ("Klageerwiderung" / "Statement of Defence")
+rule.name_de
+rule.name_en
+rule.legal_source                      — "DE.ZPO.276.1"
+rule.legal_source_pretty               — "§ 276 Abs. 1 ZPO" / "Section 276(1) ZPO"
+rule.primary_party                     — claimant | defendant | court | both
+rule.event_type                        — filing | hearing | decision
+
+deadline.due_date                      — ISO of next pending deadline for this rule on this project
+deadline.due_date_long_de              — "12. Juni 2026"
+deadline.due_date_long_en              — "12 June 2026"
+deadline.original_due_date             — ISO if extended
+deadline.computed_from                 — anchor description (e.g. "Klagezustellung am 14.05.2026 + 6 Wochen")
+deadline.title                         — deadline.title
+deadline.source                        — "rule" | "manual" | …
+```
+
+Variable bag construction is `SubmissionVarsService.Build(ctx, in)` — exactly the function in `3677c81`'s `submission_vars.go`, no changes.
+
+### 7.1 Override semantics
+
+The lawyer's `overrides` map (jsonb in `submission_drafts`) shadows the bag at export time:
+
+```go
+bag := varsSvc.Build(ctx, ...).Placeholders   // ~30 keys, resolved from project state
+for k, v := range draft.Overrides {            // lawyer's edits
+    if v == "" {
+        delete(bag, k)                          // empty override means "force missing marker"
+    } else {
+        bag[k] = v                              // non-empty override replaces
+    }
+}
+docx := renderer.Render(templateBytes, bag, missingMarker(lang))
+```
+
+Edge case: lawyer types empty string into a field that was resolved from the project. Decision: empty override forces the `[KEIN WERT: …]` marker. Lawyer's intent ("blank this out, I'll fill manually in Word") is honoured rather than silently falling back to project state. Sidebar UX: empty override field is annotated "→ [KEIN WERT: …]" so the lawyer sees the consequence before exporting.
+
+---
+
+## §8 Template authoring (mWorkRepo layout, naming, fallback chain)
+
+### 8.1 Slice A — universal .dotm only
+
+Slice A merges the variable bag into the same universal HL Patents Style .dotm that today's format-only convert ships. **The .dotm body must carry `{{placeholder}}` tokens** — currently it doesn't (it's a firm style template, not a per-submission template). m has two ways to seed Slice A:
+
+- **8.1.a** — author one universal template (`m/mWorkRepo/templates/_base/_universal.docx` or similar) with `{{firm.name}}`, `{{rule.name}}`, `{{project.case_number}}`, `{{parties.claimant.name}}`, etc. The merge engine fills these and outputs a draft that's still a generic letter shape but pre-populated.
+- **8.1.b** — author one Klageerwiderung-shaped template (`m/mWorkRepo/templates/HLC/de.inf.lg.erwidg.docx`) and route Slice A's export to that path for `submission_code='de.inf.lg.erwidg'`, with a hard-coded fall-back to `_universal.docx` for any other code. This is essentially Slice A + B's first template — wins both rounds.
+
+Inventor recommendation: **8.1.b**. Strictly more useful, identical engine code, identical mWorkRepo round-trip. The Slice A → Slice B transition is then "add more templates", not "rewire the resolver".
+
+### 8.2 Slice B — fallback-chain registry
+
+Layout reproduced from the 2026-05-19 design §5.1:
+
+```
+m/mWorkRepo (existing repo, already proxied)
+└── templates/
+    ├── HLC/                                      # FIRM_NAME-keyed override dir
+    │   ├── de.inf.lg.erwidg.docx                 # Slice A target (per 8.1.b above)
+    │   ├── de.inf.lg.klage.docx                  # Slice B addition
+    │   ├── upc.inf.cfi.soc.docx                  # Slice B addition
+    │   └── upc.inf.cfi.sod.docx                  # Slice B addition
+    ├── _base/                                    # Cross-firm baseline
+    │   ├── de.inf.lg.erwidg.docx                 # base equivalent (Slice C+)
+    │   ├── de.inf.lg.docx                        # proceeding-family fallback
+    │   ├── upc.inf.cfi.docx
+    │   ├── _skeleton.docx                        # ultra-generic fallback
+    │   └── _universal.docx                       # the v1 Slice A "any code" template
+    └── README.md                                 # placeholder reference for template authors
+```
+
+Naming: `{submission_code}.docx`. Family fallback uses the first three dot-segments (`de.inf.lg` from `de.inf.lg.erwidg`). Skeleton is the ultra-generic fallback (letterhead + party block + court address + signature stub).
+
+### 8.3 Lookup algorithm
+
+```go
+// services/submission_templates.go  (resurrected from 3677c81)
+func (r *TemplateRegistry) candidates(submissionCode string) []string {
+    family := familyOf(submissionCode)
+    out := []string{
+        fmt.Sprintf("templates/%s/%s.docx", r.firmName, submissionCode),
+        fmt.Sprintf("templates/_base/%s.docx", submissionCode),
+    }
+    if family != "" && family != submissionCode {
+        out = append(out, fmt.Sprintf("templates/_base/%s.docx", family))
+    }
+    out = append(out, "templates/_base/_skeleton.docx")
+    return out
+}
+```
+
+Gitea proxy: same `internal/handlers/files.go` shape. 5-min SHA refresh, in-process cache, `GITEA_TOKEN` for auth. The original `submission_templates.go` already implements this end-to-end; the coder re-applies it from `git show 3677c81`.
+
+### 8.4 No template at all — Slice A vs Slice B
+
+Slice A: the universal template always resolves; `ErrNoTemplate` is impossible.
+
+Slice B: if every candidate in the fallback chain 404s, the handler returns 503 + `"Vorlagen-Repository nicht erreichbar"` in the UI (same handling as the original Slice 1 design §5.4). Since the chain ends at `_skeleton.docx`, this only fires when the mWorkRepo itself is misconfigured.
+
+### 8.5 Template authoring task lands outside this design
+
+Inventor flags but does not assign: HLC must author the per-submission_code `.docx` templates. Slice A's `_universal.docx` is one document. Slice B adds Klageerwiderung, Klageerhebung, SoC, SoD, … iteratively. **Template authoring runs in parallel with engine code**; the coder ships the engine, m + HLC ships the templates. The two converge before the slice closes.
+
+This is the m-escalated piece (see §11): without per-submission templates, Slice B is engine-only.
+
+---
+
+## §9 Slice plan
+
+### Slice A — schema + new page + variables-only export against universal .docx
+
+Ships the editor end-to-end with one template.
+
+| Deliverable | Files |
+|---|---|
+| Migration 119 — `submission_drafts` table + RLS + trigger | `internal/db/migrations/119_submission_drafts.{up,down}.sql` |
+| `SubmissionVarsService` resurrected | `internal/services/submission_vars.go` (from `3677c81` + Slice 2 patch `1765d5e`) |
+| `SubmissionRenderer` resurrected with new `RenderHTML` | `internal/services/submission_render.go` (from `8ea3509`); adds `RenderHTML(...) string` for preview |
+| `SubmissionDraftService` | `internal/services/submission_draft_service.go` (NEW) |
+| Handlers (page + 7 API endpoints) | `internal/handlers/submission_drafts.go` (NEW) |
+| Wiring | `cmd/server/main.go`, `internal/handlers/handlers.go` |
+| Page TSX | `frontend/src/submission-draft.tsx` (NEW) |
+| Client bundle | `frontend/src/client/submission-draft.ts` (NEW) |
+| Schriftsätze tab update | `frontend/src/projects-detail.tsx` (rows get [Bearbeiten]), `frontend/src/client/submissions.ts` (handler) |
+| i18n | new keys under `projects.detail.submissions.draft.*` and `submissions.draft.*` (page-level) |
+| One template at `m/mWorkRepo/templates/_base/_universal.docx` (8.1.b → also `templates/HLC/de.inf.lg.erwidg.docx`) | mWorkRepo, separate PR by m |
+| Tests | `internal/services/submission_render_test.go` (resurrected + RenderHTML), `internal/services/submission_vars_test.go` (round-trip), handler smoke |
+
+Acceptance:
+
+1. Opening `/projects/{id}/submissions/de.inf.lg.erwidg/draft` lands on the user's latest draft (or creates "Entwurf 1").
+2. Sidebar renders ~30 placeholders, pre-filled from project state.
+3. Editing a sidebar value autosaves within 500ms and updates the preview pane.
+4. Multiple drafts per (project, code, user) supported; switcher in sidebar.
+5. Clicking "Als .docx exportieren" downloads a merged `.docx` (universal template + project + lawyer overrides).
+6. `system_audit_log` row appears on export (`event_type='submission.exported'`).
+7. `project_events` row appears on export and surfaces in Verlauf.
+8. RLS: caller without `can_see_project` gets 404 on the page and 404 on every draft API.
+9. Schriftsätze tab on project detail shows [Bearbeiten] alongside [Generieren].
+10. `go build ./... && go vet ./... && go test ./... && bun run build` clean.
+
+### Slice B — per-submission_code templates + fallback chain
+
+Engine is unchanged from Slice A; this slice wires `TemplateRegistry` into the export endpoint and lights up per-code templates.
+
+| Deliverable | Files |
+|---|---|
+| `TemplateRegistry` resurrected | `internal/services/submission_templates.go` (from `3677c81`) |
+| Handler swaps Slice A's `fetchHLPatentsStyleBytes` for `templateRegistry.Resolve(code)` | `internal/handlers/submission_drafts.go` |
+| `has_template` boolean per row in Schriftsätze tab list (today: unconditionally true; under Slice B: depends on registry probe) | `internal/handlers/submissions.go` |
+| Templates authored in mWorkRepo: at least Klageerwiderung + Klageerhebung + SoC + SoD | mWorkRepo PR by m |
+| Tests for fallback chain | `internal/services/submission_templates_test.go` (resurrect from history if it existed; otherwise new) |
+
+Acceptance:
+
+1. Pushing `m/mWorkRepo/templates/HLC/upc.inf.cfi.soc.docx` makes the SoC draft page resolve that template within 5 min (or instantly via `POST /api/files/refresh`).
+2. `has_template=false` rows in the Schriftsätze tab show [Keine Vorlage] instead of [Bearbeiten]/[Generieren]. Existing list ordering preserved.
+3. `last_exported_sha` on `submission_drafts` records which SHA the lawyer exported against.
+4. Misconfigured repo (every fallback 404s) → 503 with clear error.
+
+### Slice C — toggleable passages
+
+Lawyer can include/exclude boilerplate sections before export.
+
+| Deliverable | Notes |
+|---|---|
+| `passages` jsonb column on `submission_drafts` | `migration 120` (or whatever's free at land time): `passages jsonb NOT NULL DEFAULT '{}'::jsonb` — `{"intro": true, "patent_validity_attack": false, "non_infringement": true}`. |
+| Template syntax for passage blocks | `{{#passage intro}}…{{/passage}}` — start/end markers, merger drops the block when the corresponding `passages.{key}` is false. The in-house renderer's run-fragmentation handling extends to the new tokens cleanly. |
+| Sidebar UI | "Passagen" group above "Variablen", per-passage toggle (on by default), help text per passage. |
+| Template author API | `templates/README.md` documents the passage syntax + a worked example. |
+
+Acceptance: turning off `non_infringement` in the sidebar of a Klageerwiderung draft removes the corresponding section from the exported .docx; preview reflects immediately.
+
+Slices D+ (not detailed here): citation insertion from the sources system (waits for that surface), per-firm template overrides (registry already supports this), `/admin/submission-templates` variable contract sidebar.
+
+---
+
+## §10 Out of scope
+
+- AI-drafted prose (the 2026-05-19 design §11 sketch; still deferred).
+- PDF export. v1 ships `.docx` only; the lawyer's Word does the PDF step.
+- Multi-user collaboration on a single draft. Each draft is owner-scoped (`user_id`).
+- Real-time co-editing. Last-write-wins per draft; no operational transforms.
+- An in-paliad WYSIWYG editor for `.docx` content. Preview is read-only; final edits happen in Word.
+- A paliad-side template uploader. Gitea stays as the editor for templates until lawyers complain about the round-trip.
+- Translation of templates DE↔EN. Templates are mono-locale; the variable bag is bilingual.
+- Citation insertion from the sources system. Waits for the sources surface m parked.
+- Frist-detail "Exportieren" button. The submission page is reachable only from the project's Schriftsätze tab in v1; a Frist-level deep-link is a Slice D+ affordance.
+- Validation of the rendered draft against any legal rule. The engine produces text; the lawyer's substantive review is downstream.
+- Sending the draft to court / e-filing. The lawyer downloads and handles transmission outside paliad.
+
+---
+
+## §11 Material picks escalated to head
+
+Per project CLAUDE.md inventor → head policy, the four picks below carry enough cost or risk to deserve head's read. Head ratifies (or escalates to m) before the coder shift starts.
+
+### Q-E1 — Template authoring effort
+
+Slice A needs at least one custom-authored template (`_universal.docx` or `de.inf.lg.erwidg.docx`) carrying `{{placeholder}}` tokens. Slice B needs four more (Klageerhebung, SoC, SoD, Erwiderung). The engine ships independently of template content, but the feature is unfinished without lawyer-authored templates.
+
+**Inventor pick:** ship Slice A with **one** lawyer-authored template (8.1.b: `templates/HLC/de.inf.lg.erwidg.docx`) + the universal fallback. m + HLC owns the authoring; the coder owns the engine. Slices A and template-1 land together.
+
+**Material because:** without a template, the feature looks broken in user testing. Head decides: does m commit to authoring or reviewing the first template before Slice A merges, or does Slice A merge engine-only and we accept the "format-only export with placeholders" intermediate state for a week?
+
+### Q-E2 — `paliad.documents` row on export
+
+The original Slice 1 design wrote an audit-only `paliad.documents` row (`file_path NULL`, `doc_type='generated_submission'`) per generation, on the theory that "Documents" would become the canonical listing UI. This design defers that.
+
+**Inventor pick:** **no** `paliad.documents` write. `system_audit_log` + `project_events` carry the audit trail. The `documents` table is reserved for actually-uploaded documents (Phase 2 of the broader docs roadmap).
+
+**Material because:** if head agrees, we skip a column repurpose (`ai_extracted` jsonb being used for generation provenance — the 2026-05-19 design noted this was ugly). If head disagrees, the coder lands the row inside Slice A.
+
+### Q-E3 — Preview render — server or client?
+
+Server-side: `RenderHTML(...)` on the in-house renderer, round-trip per autosave. Cheaper to build, costs ~10ms server-side per keystroke (debounced 500ms).
+
+Client-side: ship the merged document body as JSON of paragraph runs, render in TS. Faster preview, harder to build (parallel render path in TS), and **diverges** the preview from the export shape (export still goes server-side).
+
+**Inventor pick:** **server-side**. Single source of truth for the merge logic. The 500ms debounce already absorbs the round-trip; a 10ms server merge plus 50ms HTTP RTT is sub-perceptible.
+
+**Material because:** if head wants the client-side preview for fully-offline draft editing, the coder needs a TS port of `substituteInDocumentXML`. Bigger build, but no round-trip latency on every keystroke.
+
+### Q-E4 — Inter-user draft visibility
+
+Today's design: each user sees only their own drafts. If two associates on the same project both draft a Klageerwiderung, they don't see each other's drafts (each has their own row).
+
+**Inventor pick:** **owner-scoped (status quo of this design)**. The unique constraint includes `user_id`; the `List` endpoint filters by current user.
+
+**Material because:** if head wants project-team visibility ("paralegal sees associate's draft for review"), the unique constraint shifts to `(project_id, submission_code, name)` (drop `user_id`), the RLS already covers the read path (`can_see_project`), and `submission_drafts` becomes a project-team resource. **This is a Phase-shape change** — the lawyer model differs. Inventor flags it because the change is cheap to make now (one column + one constraint) and expensive to make later (drafts already accumulate per-user). Head's call.
+
+---
+
+## §12 Implementation notes
+
+For the coder, not for head.
+
+- **Resurrection is `git show`, not "re-write".** The four file revisions (`3677c81:internal/services/submission_vars.go`, `1765d5e:internal/services/submission_vars.go` for the Slice 2 patch, `8ea3509:internal/services/submission_render.go`, `3677c81:internal/services/submission_templates.go`) can be applied via `git checkout 3677c81 -- internal/services/submission_vars.go` etc. The coder should verify each compiles against today's `cmd/server/main.go` wiring before applying.
+- **Renderer's `RenderHTML` is new.** The .docx walker today emits OOXML bytes; the HTML emitter walks the same tree and emits `<p>` / `<strong>` / `<em>` / `<br>`. ~120 LoC on top of the resurrected file. Same regex (`placeholderRegex`), same run-merge logic, different writer.
+- **Sidebar variable schema needs a label table.** The variable contract from §7 is keyed by dotted paths; the sidebar UI needs DE/EN labels per key. Coder adds `services/submission_var_labels.go` with a `map[string]struct{LabelDE, LabelEN, HelpDE, HelpEN}` for the ~30 keys. (Mirrors `internal/services/email_template_variables.go` shape — same lawyer-facing pattern paliad already ships at `/admin/email-templates`.)
+- **Autosave race.** The lawyer types fast → multiple PATCHes in flight. Coder uses a request-ID-debouncing pattern on the client (cancel in-flight PATCH when a new one starts) and last-write-wins on the server. No version column on the draft row in v1.
+- **Empty-override semantics in the jsonb.** `overrides = {"project.case_number": ""}` means "force missing marker". `overrides = {}` (key absent) means "fall back to bag". The service code distinguishes — careful with `omitempty`.
+- **i18n key audit.** Add `projects.detail.submissions.action.edit`, `submissions.draft.title`, `submissions.draft.export`, `submissions.draft.sidebar.{firm,project,parties,deadline,user}.group`, `submissions.draft.rename`, `submissions.draft.delete`, `submissions.draft.new`, etc. Roughly 35 new keys in DE + EN.
+- **`entity-table` row contract.** Schriftsätze tab today carries `entity-table--readonly`. Slice A removes that modifier and adds a row-click handler that navigates to `/projects/{id}/submissions/{code}/draft`, skipping clicks on the inner [Generieren] button. Matches the pattern in `frontend/src/client/checklists.ts`, `client/projects-detail.ts`, `client/deadlines.ts`.
+- **Migration 119 may collide.** Other worktrees (paliadin aichat, mig 118) may land 119 before this branch merges. Coder verifies at land time; bump to the next free number if needed.
+
+---
+
+## §13 Acceptance gate
+
+Per inventor SKILL.md + project CLAUDE.md: this design needs head's go/no-go before any coder is hired. After head ratifies (with or without escalating §11 to m):
+
+- The head decides whether to hire the same worker as `/mai-coder` with this design as the brief, or a fresh coder.
+- A coder shift takes this doc as the spec, ships Slice A, opens a PR (no self-merge).
+- Slices B and C are SEPARATE tasks — not auto-spawned.
+
+Inventor parks here.

docs/design-tools-cleanup-2026-05-12.md

@@ -0,0 +1,569 @@
+# Design — Tools surface cleanup (Fristenrechner vs Verfahrensablauf split)
+
+**Author:** kelvin (inventor)
+**Date:** 2026-05-12
+**Task:** t-paliad-178
+**Status:** READY FOR REVIEW — m gates inventor → coder transition.
+
+---
+
+## 0. Premises verified live (before designing)
+
+CLAUDE.md / memory / the task brief can all drift. Each anchor below is verified against the live codebase or DB on `mai/kelvin/inventor-tools-surface` (baseline commit `54b227c`).
+
+- **One route + one TSX serve both nav entries today.** `/tools/fristenrechner` is the only registered page route (`internal/handlers/handlers.go:162`). Both sidebar entries (Fristenrechner + Verfahrensablauf) target the same Bun-built `dist/fristenrechner.html` and disambiguate purely through `?path=a` and a client-side active-class fix-up (`frontend/src/client/sidebar.ts:447 fixVerfahrensablaufActive`). Confirmed: the live HTML pulled from paliad.de (auth-gated → 302 to login, served-bytes match) is the shell rendered by `frontend/src/fristenrechner.tsx:87 renderFristenrechner`.
+- **The client runtime is 3 559 lines, not the 2 700+ quoted in the task brief.** `frontend/src/client/fristenrechner.ts` carries Step 1 / Step 2 / Step 3a / Pathway A wizard / Pathway B cascade + filter / search + cascade engines / column + timeline result-card renderers in one IIFE bundle (`Pathway` type at line 2315, `showPathway()` at line 2370, `showBMode()` at line 2406). Any "separate route" path must either lift code out of this bundle into a shared module or accept a larger duplicated bundle on the new page.
+- **Sidebar deep-link `?path=a` lands on Pathway A directly, NOT on the Akte picker.** I traced `initPathwayFork → readPathwayFromURL → showPathway("a")`: it sets `step1.style.display = "none"`, `step2.hidden = true`, `step3a.hidden = true`, `pathway-a.hidden = false`. The user sees the wizard's "Verfahrensart wählen" tile picker first. The task brief's phrasing — "still drops users at Step 1 (Akte-Picker)" — is the perceived UX from the wizard's own internal "wizard-step-1" labelled "Verfahrensart wählen". Mental model: two surfaces with the same nav label "Step 1" muddy intent; the fix m wants is structural (a dedicated route), not a JS bug fix.
+- **`paliad.projects.court` is a free-text column, NOT an FK to `paliad.courts`.** Confirmed in `information_schema.columns`. Live values: `LG München I` (1 row), `UPC` (2), `UPC CoA` (1). The task brief's "project has a court FK" is **wrong**; only `proceeding_type_id` is a real FK. The design must NOT silently auto-pick a `paliad.courts.id` from `projects.court` — fuzzy mapping is best-effort + always overridable, never silent.
+- **`paliad.projects.proceeding_type_id` points at `category='litigation'` rows (7 codes: INF, REV, CCR, APM, APP, AMD, ZPO_CIVIL).** The Fristenrechner wizard accepts `category='fristenrechner'` codes (20 codes: UPC_INF, DE_INF, EPA_OPP, …). These overlap conceptually (`INF` is the abstract noun behind both `UPC_INF` and `DE_INF`) but are different rows. Auto-derivation needs a small mapping: `litigation_code × jurisdiction → fristenrechner_code`. Example: `INF + UPC → UPC_INF`. `INF + DE → DE_INF` (first instance). The instance dimension (LG / OLG / BGH) is **not** on `paliad.projects` today, so DE_INF_OLG / DE_INF_BGH cannot be inferred — only the first-instance code can be.
+- **`paliad.projects` carries no `priority_date` or `trigger_date` column.** It does have `filing_date` and `grant_date`. Only EP_GRANT.ep_grant.publish (Art. 93 EPÜ) is anchored on `priority_date` today (via `anchor_alt`). For Akte-driven prefill, `priority_date` stays blank by default and the user fills it.
+- **`paliad.projects.our_side` and `paliad.projects.counterclaim_of` exist** (already exploited by t-paliad-164 perspective-chip predefine and the parent-counterclaim link respectively). These two columns are the actual hooks for "consolidated timeline" vs "side-by-side lanes" — see §6.
+- **`deadline_rules.condition_flag` is a real text[] column with exactly 4 distinct value-sets in production:** `[with_amend]` (4 rows), `[with_cci]` (4), `[with_ccr]` (5), `[with_ccr, with_amend]` (4). Only `UPC_INF` (proceeding_type_id=8) and `UPC_REV` (proceeding_type_id=9) carry variant-flagged rules. Every other proceeding type renders a single canonical timeline today. **This is the hard data bound on the variant-chip design** — chips beyond these three flags would have no rules to flip and must be marked "future".
+- **Court-specific rule overrides do not exist as a mechanism.** `CourtID` in `CalcOptions` (`internal/services/fristenrechner.go:107`) only switches the holiday calendar (via `courts.CountryRegime`). There is no per-court rule branch. "UPC LD Mü vs LD Düsseldorf" overrides are NOT a thing — they'd need a new column on `deadline_rules`.
+- **Expedited-vs-standard distinctions do not exist** either. No `condition_flag` row matches an expedited concept. Adding one is a schema-and-seed change, out of scope here.
+- **Result rendering today** lives in `renderTimelineBody` and `renderColumnsBody` (`frontend/src/client/fristenrechner.ts:637 / :664`). The user toggles between the two with a radio (`#fristen-view-toggle`). Both renderers take a single `DeadlineResponse` and emit DOM strings; neither knows about "two timelines side by side". A consolidated-vs-lane view (§5–§6) is a renderer-level change, not a backend one.
+- **The Step 1/Step 2/Step 3a/Pathway A/B layout shipped under t-paliad-133 + t-paliad-168.** The "Verfahrensablauf einsehen" card (Step 2 third option, lines 215-223 of fristenrechner.tsx) was added in t-paliad-168 specifically to give the abstract-browse case a discoverable entry. If Verfahrensablauf moves to its own route, the third card becomes redundant (§9).
+
+If any of these conflict with what the task brief asserts, **the live state wins** and the brief is the bug — flagged in §13 for m.
+
+---
+
+## 1. Vision + scope
+
+m's framing (verbatim from the task brief):
+
+> Users want to **either** (1) determine a deadline — possibly Akte-scoped, possibly abstract — **or** (2) browse a typical Verfahrensablauf abstractly with variant options.
+
+The two intents are **fundamentally different**:
+
+- **Determine a deadline** ends with a save (or a print, or a manual transcription) of a *specific* date attached to *something* — a project, or a sticky-note in the user's head.
+- **Browse a Verfahrensablauf** ends with the user understanding the *shape* of a proceeding — no date binding required.
+
+Today both intents collapse onto one URL because the wizard infrastructure is shared. The cost: two sidebar entries pointing at the same shell, an active-class fix-up script (`fixVerfahrensablaufActive`), and a Step 1 ("Welche Akte?") frame that doesn't match the abstract-browse intent.
+
+### Scope of this design
+
+1. **Page surface split** — separate routes per intent. `/tools/fristenrechner` keeps the deadline-determination intent (Akte-scoped *or* abstract). `/tools/verfahrensablauf` becomes the dedicated abstract-browse surface with variant chips + side-by-side compare.
+2. **Step 0 "Abstrakt oder Akte?"** as the FIRST affordance on `/tools/fristenrechner`. Pick → narrows downstream inputs.
+3. **Akte-driven auto-derivation** — map project columns to wizard inputs and flag the gaps.
+4. **Variant chips + consolidated-vs-lane view** for `/tools/verfahrensablauf`.
+5. **Side-by-side compare** on `/tools/verfahrensablauf` (max 2 timelines for v1).
+6. **Sidebar labels + URL conventions** post-split.
+7. **Mobile responsive** plan.
+8. **What gets dropped** (Step 2 browse card, sidebar fix-up script).
+
+### Explicitly out of scope (per task brief)
+
+- Deadline-rule data-model changes (court-specific overrides, expedited-flag, new condition_flag values). Audited in §0, propose nothing here.
+- t-paliad-166 Determinator B1 cascade redesign — separate ticket, on-hold. Pathway B continues to exist inside `/tools/fristenrechner`; we note interplay in §11 but do not pre-empt.
+- t-paliad-157 Fristenrechner interactive-UX pair session — on-hold. The cleanup here may inform it, but we don't dictate it.
+- Project Verlauf tab (`/projects/{id}` → Verlauf). Stays as-is. SmartTimeline renders concrete-per-case via `internal/services/projection_service.go`; no Tool-side mirror.
+- New backend services. The split runs on the existing `POST /api/tools/fristenrechner` + `POST /api/tools/event-deadlines` endpoints; we add at most one helper for Akte → fristenrechner-code mapping.
+- Backend rule changes — touch the substrate only enough to verify what the design needs is already there.
+
+---
+
+## 2. Page surfaces + route split
+
+m has already chosen **Option A** in the task brief: split by intent, separate URLs. The design here implements that choice. For honesty I also note the alternatives I considered and why A still wins after audit.
+
+### 2.1 Three options weighed
+
+| Option | URL shape | Trade-off | Verdict |
+|---|---|---|---|
+| **A — Two routes** | `/tools/fristenrechner` + `/tools/verfahrensablauf` | Clean mental model. Sidebar entries map 1:1 to URLs. `fixVerfahrensablaufActive` dies. Two HTML files; shared client code lifted into a module. | **Picked.** Aligns with intent split. |
+| **B — One route, `?mode=` fork** | `/tools/fristenrechner?mode=calc` vs `?mode=browse` | Single HTML bundle, no shared-module lift. But: sidebar entries still alias the same page; muddled intent stays in the user's head; we'd still need a Step 0 inside the calc mode. | Rejected by m. Verifies on second look: it just moves `?path=a` to `?mode=browse`, doesn't fix the problem. |
+| **C — Move into Patentglossar** | Verfahrensablauf renders inline on glossary pages | Discoverability shrinks. Glossary entries are concept-bounded; Verfahrensablauf is procedure-bounded. The two indexes don't map. | Rejected by m. |
+
+### 2.2 Code-reuse strategy under Option A
+
+The honest cost of splitting routes is shared-client-code duplication. Today `client/fristenrechner.ts` (3 559 LoC) bundles everything. The Verfahrensablauf-only surface needs:
+
+- The proceeding-type tile picker (`UPC_TYPES`, `DE_TYPES`, `EPA_TYPES`, `DPMA_TYPES` arrays in `fristenrechner.tsx`).
+- The timeline + columns result renderers (`renderTimelineBody`, `renderColumnsBody`).
+- The `POST /api/tools/fristenrechner` calc invocation.
+- Court picker + holiday-calendar pickup (read-only).
+- DE/EN i18n for the timeline rows.
+
+It does NOT need:
+
+- Step 1 Akte picker / ad-hoc chip / Step 1 summary.
+- Step 2 file/happened/browse cards.
+- Step 3a outgoing-intent chooser.
+- Pathway B cascade + filter + perspective + inbox chips (~1 200 LoC).
+- Save-to-Akte modal.
+- Trigger-event mode (`mode-event-panel`).
+
+**Plan:** lift the deadline-timeline core (proceeding picker + calc + render) into `frontend/src/client/views/verfahrensablauf-core.ts`. Both pages import it. Pathway B + Save modal + Step machinery stay in `client/fristenrechner.ts`. Estimated lifted surface: ~700–900 LoC. New code on `verfahrensablauf.ts` (variant chips + lane mode + compare): ~400–600 LoC.
+
+This keeps the IIFE per-page bundle pattern intact (one entry per route in `frontend/build.ts:228`). No runtime npm dep added.
+
+### 2.3 The two pages in one sentence each
+
+- **`/tools/fristenrechner`** — Deadline determination. Optional Akte scope. Ends in "save / print / done".
+- **`/tools/verfahrensablauf`** — Procedural shape browser. No Akte. Ends in "now I understand the shape".
+
+### 2.4 Sidebar
+
+```text
+Werkzeuge
+  Fristenrechner       → /tools/fristenrechner
+  Verfahrensablauf     → /tools/verfahrensablauf
+  Kostenrechner        → /tools/kostenrechner
+  …
+```
+
+`fixVerfahrensablaufActive` deletes; the SSR-time `navItem` helper handles both active classes natively because the hrefs differ on pathname.
+
+---
+
+## 3. Step 0 "Abstrakt oder Akte?" on `/tools/fristenrechner`
+
+m's lock-in: Step 0 comes FIRST. Today's Step 1 (Akte picker) forces the user to either commit to an Akte or escape via ad-hoc chips before anything else moves. Step 0 makes the binary choice explicit.
+
+### 3.1 Affordance — three sketches considered
+
+**Sketch A — Radio toggle (Recommended).**
+A pair-of-toggle at the top of the page, wide on desktop, stacked on mobile. The currently-active half expands into its full picker; the inactive half collapses to a slim header that the user can click to flip.
+
+```
+┌──────────────────────────────────────────────────────────────┐
+│  Schritt 0 — Wie wollen Sie die Frist bestimmen?             │
+│                                                              │
+│  ◉ Mit Akte verknüpfen          ○ Abstrakt — ohne Akte       │
+│ ────────────────────────────────────────────────────────────│
+│                                                              │
+│  🔍 Akte suchen…                                             │
+│  [Akte 1 · CLI-2024 — Foo GmbH vs Bar Ltd. — UPC LD Mü]      │
+│  [Akte 2 · …]                                                │
+│  ────                                                        │
+│  + Neue Akte anlegen                                         │
+│                                                              │
+└──────────────────────────────────────────────────────────────┘
+```
+
+When the user picks "Abstrakt":
+
+```
+┌──────────────────────────────────────────────────────────────┐
+│  Schritt 0 — Wie wollen Sie die Frist bestimmen?             │
+│                                                              │
+│  ○ Mit Akte verknüpfen          ◉ Abstrakt — ohne Akte       │
+│ ────────────────────────────────────────────────────────────│
+│                                                              │
+│  Verfahrensart wählen:                                       │
+│  [UPC] [DE] [EPA] [DPMA] ← jurisdiction picker (4 tabs)      │
+│  (then proceeding-type tiles within the chosen tab)          │
+│                                                              │
+└──────────────────────────────────────────────────────────────┘
+```
+
+**Why I'd recommend this:** the toggle is a single decision, declared up-front, with the consequence visible inline. No modal dismissal cost. Keyboard navigation natural. On mobile it stacks to two stacked rows where the active row expands and the inactive row stays a touch-target.
+
+**Sketch B — Two big cards.** Like today's Step 2 cards but at the very top. Pro: pretty + tappable. Con: click-and-commit feels heavier than a toggle; "going back" reads as undoing a choice instead of flipping it.
+
+**Sketch C — Modal-before-render.** Most decisive, also most annoying — the user can't even see the page before the dialog clears. Reject. (Modals interrupt; we want the user oriented before they're asked.)
+
+### 3.2 URL state
+
+Step 0 binds to `?mode=akte|abstract` in the URL.
+
+- `?mode=akte&project=<uuid>` — Akte selected. Court / proceeding-type / our_side auto-derived (§4).
+- `?mode=abstract&forum=upc|de|epa|dpma` — abstract. Jurisdiction tab selected; proceeding-type tiles below.
+- `?mode=` absent — render Step 0 with no preselection.
+
+Deep-link from `/projects/{id}` → "Frist berechnen" button passes `?mode=akte&project=<id>` and lands on Step 0 with Akte branch already filled.
+
+`localStorage["paliad.fristen.mode"]` remembers the user's last choice for soft re-entry (the `PATHWAY_STORAGE_KEY` pattern already exists).
+
+### 3.3 Removal of today's Step 2 fork (file / happened / browse)
+
+With Step 0 making the intent binary, the file-vs-happened branching collapses into one wizard with two anchor sources:
+
+- **Akte mode** — wizard pre-filled. After calc, the save CTA is "An Akte hängen". `?path=` machinery shrinks because Pathway A vs Pathway B becomes a wizard *step* (incoming-event vs outgoing-event), not a top-level path.
+- **Abstract mode** — wizard takes proceeding-type + date as today. After calc, save CTA disabled (no Akte to save against); `Drucken` remains.
+
+The "Verfahrensablauf einsehen" card is gone from `/tools/fristenrechner` (its purpose lives on `/tools/verfahrensablauf` now — §9).
+
+Pathway B (the cascade) is **kept** as a separate entry-flow inside Akte-mode for "Etwas ist passiert" — the t-paliad-166 redesign is on-hold and we don't pre-empt it. In abstract mode Pathway B is reachable via a "Frist aufgrund Ereignis (Determinator)" link in the result panel; the cascade itself unchanged.
+
+---
+
+## 4. Akte-driven auto-derivation
+
+When `mode=akte&project=<uuid>`, the wizard prefills as much as it honestly can from `paliad.projects`. The rest stays empty + visible.
+
+### 4.1 Mapping table
+
+| Wizard input | Project source | Confidence | Behaviour |
+|---|---|---|---|
+| **proceeding_type_code** (UPC_INF, DE_INF, …) | `proceeding_types.code` via `projects.proceeding_type_id` + jurisdiction disambiguation | medium-high | Best-effort pick + the proceeding-tile picker stays visible with the picked tile pre-selected. User can flip. |
+| **trigger_date** | None today | low | Always empty. User fills. |
+| **priority_date** (EP_GRANT only) | `projects.grant_date` or `projects.filing_date` (parent patent project's filing) | low-medium | Pre-fill only when the chosen proceeding is `EP_GRANT`. Field stays visible + editable. |
+| **court_id** | `projects.court` (free text) — fuzzy match against `paliad.courts.code` | low | Pre-select if string-match is exact-or-trivial-canon (e.g. `"UPC"` → `upc-cd-...`? **No** — too ambiguous; leave blank); else leave blank. Picker visible + required for UPC where holiday calendar differs. |
+| **our_side** (perspective chip) | `projects.our_side` | high | Already wired (t-paliad-164). Predefine + show "vorgegeben durch Akte" hint. |
+| **condition_flag** (with_ccr, with_cci, with_amend) | None today | low | Stays user-driven. Flag checkboxes appear conditionally on UPC_INF/UPC_REV. |
+| **counterclaim sibling info** | `projects.counterclaim_of` | medium | If set, the result panel shows a small "Verbundenes Verfahren: <parent>" line with a deep-link to the parent's Verlauf tab. Informational only — doesn't change calc. |
+
+### 4.2 Litigation → fristenrechner code mapping
+
+`projects.proceeding_type_id` points to `category='litigation'` rows. The wizard wants `category='fristenrechner'`. The mapping is multi-key:
+
+| litigation code | jurisdiction | resolved fristenrechner code |
+|---|---|---|
+| `INF` | UPC | `UPC_INF` (id 8) |
+| `INF` | DE | `DE_INF` (id 12) — first instance only; OLG/BGH not derivable |
+| `REV` | UPC | `UPC_REV` (id 9) |
+| `REV` | DE | `DE_NULL` (id 13) |
+| `CCR` | UPC | `UPC_REV` (id 9) + `with_cci` flag suggested |
+| `APM` | UPC | `UPC_PI` (id 10) |
+| `APP` | UPC | `UPC_APP` (id 11) |
+| `AMD` | UPC | (no direct fristenrechner code; suggest UPC_INF with `with_amend`) |
+| `ZPO_CIVIL` | DE | `DE_INF` (id 12) — fallback |
+
+The jurisdiction comes from `proceeding_types.jurisdiction` (UPC / DE / EPA / DPMA) on the project's own proceeding_type row, not from `projects.country` directly (which is a different axis — country of patent, not of forum).
+
+Implementation: a helper `services.ResolveFristenrechnerCodeForProject(projectID)` returning `(code, confidence, reason)` so the UI can render "Vorgeschlagen: UPC_INF (aus Akte abgeleitet — Sie können umstellen)". Where confidence is `low`, no preselect — user picks.
+
+### 4.3 Court free-text — no silent FK promotion
+
+`projects.court` is a free-text field. Live values include `"UPC"` (ambiguous: which division?), `"UPC CoA"` (matches `upc-coa-luxembourg`), `"LG München I"` (matches `de-lg-muenchen1`). I deliberately do NOT auto-pick a `paliad.courts.id` from this string in v1: the cost of a wrong silent pick (a holiday-calendar mismatch invalidating a calculated date) is high; the benefit of saving one click is low. The Court picker stays visible and **required** for UPC proceedings (already today's behaviour via the `isCourtDeterminedRule` check in `internal/services/fristenrechner.go:779`).
+
+If the free-text value matches a canonical `paliad.courts.code` exactly (case-insensitive), we *highlight* the matching option but do not auto-select. The user clicks to confirm.
+
+Follow-up ticket worth filing (out of scope here): migrate `projects.court` from text to `court_id` FK. That'd land a real auto-derivation. Until then, this design treats it as a hint.
+
+### 4.4 Edge case — Akte without a proceeding_type_id
+
+11 of 11 live projects today have no `proceeding_type_id` set yet. Behaviour: the wizard renders with all proceeding-type tiles selectable, no preselect, no hint. Functionally identical to abstract mode but with the Akte locked for save-CTA. No error state — silent graceful degradation.
+
+---
+
+## 5. Variant chips on `/tools/verfahrensablauf`
+
+The new dedicated route renders proceeding-shape with the user toggling "what variant am I looking at?". Variants are the live `condition_flag` mechanism.
+
+### 5.1 Variants that exist today (audited live)
+
+Only **UPC_INF** (id 8) and **UPC_REV** (id 9) carry `condition_flag` rules. The flags themselves:
+
+- `with_ccr` — Klägerseite, infringement claim met with revocation counterclaim. Adds `inf.def_to_ccr`, `inf.reply`, `inf.reply_def_ccr`, `inf.rejoin`, `inf.rejoin_reply_ccr` (5 rules) to UPC_INF.
+- `with_cci` — Beklagtenseite on revocation answered with infringement counterclaim. Adds `rev.cc_inf`, `rev.def_cci`, `rev.reply_def_cci`, `rev.rejoin_cci` (4 rules) to UPC_REV.
+- `with_amend` — Patent amendment proposed. Adds `inf.app_to_amend`, `inf.def_to_amend`, `inf.reply_def_amd`, `inf.rejoin_amd` to UPC_INF; `rev.app_to_amend`, `rev.def_to_amend`, `rev.reply_def_amd`, `rev.rejoin_amd` to UPC_REV. Composes with `with_ccr` / `with_cci`.
+
+Every other proceeding type (DE_INF, DE_NULL, EPA_OPP, EPA_APP, EP_GRANT, DPMA_*, UPC_APP, UPC_PI, UPC_DAMAGES, UPC_DISCOVERY, UPC_COST_APPEAL, UPC_APP_ORDERS) has zero `condition_flag` rules — only one canonical timeline.
+
+### 5.2 Chip set per proceeding
+
+Chips are conditionally rendered based on which flags exist on the selected proceeding's `condition_flag` rule rows.
+
+```
+UPC_INF:   [Standard]  [+ Widerklage Nichtigkeit (with_ccr)]  [+ Patentänderung (with_amend)]
+UPC_REV:   [Standard]  [+ Verletzungs-Widerklage (with_cci)]  [+ Patentänderung (with_amend)]
+DE_INF, DE_NULL, EPA_OPP, …: (no chips, single timeline)
+```
+
+Chips are **toggleable** (multi-select), not radio. Each chip toggles its flag on/off; the timeline reflows. Composite combinations (`with_ccr + with_amend`) render the union of rules. Toggling all chips off renders the base proceeding (no `condition_flag` rules).
+
+Future flags (court-specific, expedited) — chips are **disabled and dimmed** with a tooltip "wird noch nicht unterstützt" when the proceeding has nothing to offer. We do NOT pre-render dead chips for proceedings without variants.
+
+### 5.3 Consolidated vs lane view — the toggle m asked for
+
+m's example: an infringement action triggers a counterclaim for revocation. Two ways to render:
+
+**Consolidated** — One timeline. CCR-related events (the `with_ccr` flag) interleave with base UPC_INF events along the same vertical timeline. Colour-coded by `primary_party` (claimant / defendant / court). This is the current behaviour when `?flags=with_ccr` is set.
+
+**Lane** — Two parallel columns. Column 1 = UPC_INF base timeline. Column 2 = UPC_REV timeline (the counterclaim's own proceeding). Rules anchored on shared trigger dates align horizontally.
+
+Toggle UI sits beside the variant chips:
+
+```
+[Standard] [+ Widerklage]  | View: ◉ Konsolidiert  ○ Spalten
+```
+
+In v1, the lane view is only available when the user has selected a variant that implies a *second proceeding* — i.e., `UPC_INF + with_ccr` shows UPC_INF || UPC_REV side-by-side, `UPC_REV + with_cci` shows UPC_REV || UPC_INF. Same backend data, different paint.
+
+For variants that DON'T imply a second proceeding (`with_amend` alone), the lane toggle is hidden — there's only one timeline.
+
+### 5.4 URL state
+
+`/tools/verfahrensablauf?proceeding=UPC_INF&flags=with_ccr,with_amend&view=lane&trigger_date=2026-05-12`
+
+Trigger date is optional — without it, the timeline renders with relative offsets ("+3 Monate", "+6 Wochen") instead of absolute dates. This is the "browse shape" mode. With a trigger date the timeline becomes concrete.
+
+`view=consolidated` (default) or `view=lane` toggles paint.
+
+---
+
+## 6. Side-by-side compare
+
+The second variant axis. m wants to compare *two different proceeding types* OR *two variants of the same proceeding* side-by-side.
+
+### 6.1 Affordance
+
+A "Vergleichen" button next to the variant chips. Click → second proceeding picker slides in, second variant-chip row appears, two timelines render side-by-side.
+
+```
+┌──────────────────────────────────────────────────────────────┐
+│  Verfahren A: [UPC_INF ▾]  Flags: [✓ with_ccr] [ with_amend]│
+│  Verfahren B: [UPC_REV ▾]  Flags: [✓ with_cci] [ with_amend]│
+│  Trigger A: [2026-05-12]  Trigger B: [synced ✓]              │
+│ ────────────────────────────────────────────────────────────│
+│                                                              │
+│  Timeline A          ║          Timeline B                   │
+│  ┌─ Klageerhebung    ║          ┌─ Nichtigkeitsklage         │
+│  │  2026-05-12       ║          │  2026-05-12                │
+│  ├─ Klageerwiderung  ║          ├─ Klageerwiderung           │
+│  │  2026-08-12 (3M)  ║          │  2026-08-12 (3M)           │
+│  …                                                           │
+└──────────────────────────────────────────────────────────────┘
+```
+
+### 6.2 Decisions
+
+- **Max 2 timelines for v1.** Three+ would push the layout below mobile readability and add picker friction. The `counterclaim_of` example always pairs two proceedings; that's the common case.
+- **Synchronised date axis** by default (Trigger A = Trigger B). Toggle "Unabhängige Trigger-Daten" reveals a second date input. Synced is the right default because the most common compare is "what happens in both proceedings starting from the same Klageerhebung date".
+- **Independent variant chips per timeline.** Variant A's flags don't affect Variant B. The chips render per-column.
+- **Wide-screen primary.** Lane and compare views require ≥720px to be readable. Below that, stack vertically (Timeline A above Timeline B, full-width each). The synced-trigger constraint stays; users on small screens still get the compare, just stacked.
+- **Permalink-shareable.** `?compare=1&a_proceeding=UPC_INF&a_flags=with_ccr&b_proceeding=UPC_REV&b_flags=with_cci&trigger=2026-05-12&synced=true` — every chip + variant + trigger captured in URL. Copy-paste produces an identical render.
+
+### 6.3 Lane view vs Compare view — are they the same thing?
+
+Conceptually similar (two columns), but UX-distinct:
+
+- **Lane view** is "one variant that implies two proceedings rendered together". The two columns are *logically linked* (e.g., `UPC_INF + with_ccr` always shows the same UPC_REV alongside).
+- **Compare view** is "the user picked two arbitrary proceedings + variants to look at together". The two columns are *independently chosen*.
+
+In renderer terms they share the same DOM layout (CSS grid with 2 columns). The state differs: lane view's second proceeding is computed from the variant flag; compare view's second proceeding is user-picked. We implement them as one renderer with two state-entry points.
+
+---
+
+## 7. Sidebar nav labels + URL conventions
+
+### 7.1 Labels (post-cleanup)
+
+Today: **Fristenrechner** + **Verfahrensablauf**.
+
+Recommendation: keep the labels as-is. m's brief suggested alternatives ("Frist berechnen" / "Verfahrensabläufe") — I think the current labels are tighter:
+
+- "Fristenrechner" is a known brand-term in the firm vocabulary (per the German-tool-names-as-brands convention in CLAUDE.md).
+- "Verfahrensablauf" reads as a noun "the procedural flow", which matches the abstract-browse intent better than the plural "Verfahrensabläufe" (which reads as "the catalogue of all flows").
+
+But I flag this for m in §13 — the call is brand-strategic, not technical.
+
+### 7.2 URL conventions
+
+| Route | Key params | Purpose |
+|---|---|---|
+| `/tools/fristenrechner` | `mode=akte\|abstract` | Pick branch |
+| `/tools/fristenrechner?mode=akte&project=<uuid>` | + `path=outgoing\|happened` | Akte deadline determination |
+| `/tools/fristenrechner?mode=abstract&forum=upc&proceeding=UPC_INF&trigger_date=…` | + `flags=…` | Abstract deadline determination |
+| `/tools/verfahrensablauf` | `proceeding=…&flags=…&view=…&trigger_date=…` | Browse one proceeding-shape |
+| `/tools/verfahrensablauf?compare=1&a_proceeding=…&b_proceeding=…&…` | (per §6.2) | Compare two |
+
+The `?path=a` query param dies entirely. The `fixVerfahrensablaufActive` function deletes. The localStorage key `paliad.fristen.pathway` is preserved (still used by Akte-mode Pathway A/B inside `/tools/fristenrechner`); it gets a sibling `paliad.fristen.mode`.
+
+### 7.3 Bookmarkability + share
+
+Both pages produce permalinks. Copy URL → paste in another browser → identical view (with same auth gate). The compare-view URL is particularly load-bearing for the "send your colleague a precomputed timeline" use case — it's how a PA quickly shows a counterpart "this is the shape we're looking at".
+
+---
+
+## 8. Mobile + responsive
+
+Existing breakpoints in the codebase: 640px / 720px / 768px / 1023px (`frontend/src/styles/global.css`).
+
+### 8.1 `/tools/fristenrechner`
+
+- **≥720px:** Step 0 toggle horizontal. Akte search results in a list.
+- **<720px:** Step 0 toggle stacks (radio rows top-to-bottom). Akte list full-width.
+- **<480px:** Proceeding-tile picker (UPC / DE / EPA / DPMA tabs + tiles) wraps tiles to one column.
+
+### 8.2 `/tools/verfahrensablauf`
+
+- **≥1023px:** Lane view + compare view render side-by-side (CSS grid 2-col).
+- **720–1022px:** Lane view side-by-side; compare view stacks (Timeline A above Timeline B, full-width).
+- **<720px:** Both lane and compare stack vertically. Variant chips wrap to 2-3 rows.
+- **<480px:** Single-column always. Compare-view "Vergleichen" button still works but stacks the result rows.
+
+### 8.3 Variant chips on mobile
+
+Chips wrap with `flex-wrap`. Maximum 3 chips per row on a 360px viewport (each chip ≤ 110px wide); composite proceedings (UPC_INF, UPC_REV) fit 3 chips so this works.
+
+### 8.4 What does NOT collapse on mobile
+
+- The trigger-date input. Stays a single date picker (browser-native; iOS / Android already render their own UI).
+- The proceeding picker. Stays tiled (large tap targets).
+- The result rows (column + timeline views). Render unchanged from today; mobile already handles them.
+
+---
+
+## 9. What gets dropped
+
+| Today | Post-cleanup |
+|---|---|
+| **Step 2 "Verfahrensablauf einsehen" card** | Deleted. The abstract-browse case has its own route. |
+| **Sidebar `?path=a` deep-link** | Deleted. `/tools/verfahrensablauf` replaces it. |
+| **`fixVerfahrensablaufActive()` function** | Deleted. Both sidebar entries map 1:1 to URLs; native SSR active-class works. |
+| **`localStorage["paliad.fristen.pathway"]`** | Preserved as-is. Still used inside Akte-mode Pathway A/B. |
+| **The Step 1/Step 2 fork on `/tools/fristenrechner`** | Replaced by Step 0 (Akte vs Abstract). Step 2's "file vs happened vs browse" becomes a wizard-internal branch, not a top-level page state. |
+| **Step 3a "outgoing-intent chooser" (File / Draft / Enter)** | Kept inside Akte-mode. The Draft option (`fristen-step3a-draft`) stays disabled as today (placeholder). |
+
+The deletions sum to maybe 200–300 LoC out of `client/fristenrechner.ts`. The lift of `verfahrensablauf-core.ts` is the bigger reshape; net LoC churn around +500 / -300.
+
+---
+
+## 10. Slicing for the coder pass
+
+Four slices, each independently mergeable. Slice 1 ships the structural split; Slices 2–4 layer features.
+
+### Slice 1 — Route + shell split (foundation)
+
+- New route `/tools/verfahrensablauf` registered in `internal/handlers/handlers.go`.
+- New handler `handleVerfahrensablaufPage` serves `dist/verfahrensablauf.html`.
+- New TSX `frontend/src/verfahrensablauf.tsx` — renders the proceeding-tile picker + result panel. No variant chips yet; no compare yet. Just the abstract-browse case factored out.
+- New client `frontend/src/client/verfahrensablauf.ts` — minimal: picker → calc → render. Imports from a new shared module `client/views/verfahrensablauf-core.ts`.
+- Sidebar `Sidebar.tsx:163-164` updated: second nav entry's href flips from `/tools/fristenrechner?path=a` to `/tools/verfahrensablauf`.
+- `client/sidebar.ts:447 fixVerfahrensablaufActive` deleted (and its call site at the bottom of `initSidebar`).
+- Step 2 "Verfahrensablauf einsehen" card markup in `frontend/src/fristenrechner.tsx` + its handler in `client/fristenrechner.ts` deleted.
+- Step 2's "browse" event handler at `fristen-step2-browse` removed; the path="a" branch in `showPathway` still exists for Akte-mode wizard re-use.
+- DE/EN i18n keys: `tools.verfahrensablauf.title`, `tools.verfahrensablauf.subtitle`, plus all the proceeding-tile labels (already exist — reused).
+- Build: add `renderVerfahrensablauf` import and `bun:write` step in `frontend/build.ts`.
+- Tests: Playwright smoke — `/tools/verfahrensablauf` renders, sidebar nav links work, no 404s, the old `?path=a` URL 302s to `/tools/verfahrensablauf` (back-compat for any bookmarked links).
+
+**What does NOT change in Slice 1:** the existing `/tools/fristenrechner` page works exactly as today (Step 1 / Step 2 / Step 3a / Pathway A / Pathway B). Step 0 is Slice 2.
+
+### Slice 2 — Step 0 on `/tools/fristenrechner`
+
+- New Step 0 toggle component in `fristenrechner.tsx` (above today's Step 1).
+- `?mode=akte|abstract` URL param + `paliad.fristen.mode` localStorage hook.
+- "Abstract" branch reveals a new compact proceeding-tile picker inside the Step 0 frame (or scrolls to today's wizard-step-1).
+- "Akte" branch renders today's Step 1 (Akte search + ad-hoc chips).
+- Akte-driven auto-derivation (§4): a new service `ResolveFristenrechnerCodeForProject(projectID)` and frontend hook that preselects the proceeding tile + `our_side` chip + Court hint (highlight only, not pre-select).
+- Tests: Playwright smoke for the four state transitions (akte → abstract, abstract → akte, akte+project → akte-no-project, deep-link `?mode=abstract&forum=upc`).
+
+### Slice 3 — Variant chips + consolidated/lane view
+
+- Variant-chip strip on `/tools/verfahrensablauf` (`with_ccr`, `with_cci`, `with_amend` conditional on proceeding).
+- `?flags=` URL param.
+- Lane-vs-consolidated toggle. Lane view auto-enables when the variant implies a second proceeding (UPC_INF+with_ccr → UPC_REV; UPC_REV+with_cci → UPC_INF).
+- Lane renderer in `views/verfahrensablauf-core.ts` (CSS grid 2-col, shared trigger-date axis).
+- Tests: Playwright smoke for variant toggles + lane render + lane on mobile (stack).
+
+### Slice 4 — Side-by-side compare
+
+- "Vergleichen" button + second-proceeding picker.
+- `?compare=1&a_proceeding=…&b_proceeding=…&…` URL state.
+- Synced-trigger toggle; independent-trigger fallback.
+- Permalink test (copy URL → fresh tab → same render).
+- Mobile fallback (stacked).
+- Tests: Playwright smoke for compare entry, both timelines render, permalink roundtrip.
+
+Each slice merges to main independently. Slice 1 is the bottleneck; once it's in, Slices 2–4 can ship in any order (Slice 2 only touches `/tools/fristenrechner`, Slices 3+4 only touch `/tools/verfahrensablauf`).
+
+---
+
+## 11. Tradeoffs flagged
+
+### 11.1 Code duplication vs route clarity
+
+The split forces ~700–900 LoC of client code into a shared module (`views/verfahrensablauf-core.ts`). That's lift work without user-visible benefit. The alternative (one big page with `?mode=`) saves the lift but keeps the muddled mental model that triggered this redesign in the first place. **Decision: pay the lift cost.** It's a one-time refactor; the navigation clarity is durable.
+
+### 11.2 Step 0 vs Step 1 — perceived "extra step"
+
+Today's flow: Akte picker (Step 1) → choose-intent cards (Step 2) → wizard. Tomorrow's flow: mode toggle (Step 0) → Akte picker OR abstract picker → wizard. Same number of clicks for the Akte case. One *fewer* click for the abstract case (you go straight to proceeding tiles instead of clicking "Verfahrensablauf einsehen" first). Net win.
+
+### 11.3 Court free-text means imperfect auto-derivation
+
+We can't reliably auto-pick `court_id` from `projects.court` until that column becomes an FK. The design leans on "highlight matching options" rather than silent preselect. The cost is one extra click. **File a follow-up ticket** to migrate `projects.court` → `court_id` FK; until then, no silent FK promotion.
+
+### 11.4 Pathway B (Determinator cascade) stays inside Akte-mode
+
+t-paliad-166 will redesign Pathway B as a row-by-row cascade. We don't pre-empt that. Pathway B remains reachable from Akte-mode's "Etwas ist passiert" card. In Abstract mode it's reachable through a "Frist aufgrund Ereignis" link in the result panel. Both paths stay; only the entry surface changes.
+
+### 11.5 Variant chips disabled for non-UPC proceedings
+
+Only UPC_INF and UPC_REV have `condition_flag` rules today. DE_INF, DE_NULL, EPA_OPP, etc. show no chips. This is honest — the data isn't there. If users ask for German "with/without counterclaim" variants, that's a `condition_flag` seed-data ticket, not a UX redesign.
+
+### 11.6 Lane view assumes the second proceeding exists
+
+`UPC_INF + with_ccr` lanes to `UPC_REV`. But `UPC_REV` itself is a full proceeding with its own deadlines anchored on a *separate* trigger date (the CCR filing date, not the SoC date). For v1 we render the second lane with the *same trigger date* as the primary — which is wrong-but-useful: the user sees the *shape* of the counterclaim's flow but the dates are nominal. A future iteration adds a "second trigger date" input for the lane. **Document this in the UI** with a small caveat: "Annahme: Widerklage zur gleichen Zeit eingelegt".
+
+### 11.7 No state preserved across the route boundary
+
+If a user is mid-calc on `/tools/fristenrechner` and clicks the sidebar's `/tools/verfahrensablauf`, their wizard state is lost. We don't try to bridge the two — they're different intents. The URL captures everything important; the user can pop back via the browser back button.
+
+### 11.8 Print mode is the only export
+
+No PDF, no SVG, no CSV export in this design. The existing `#fristen-print-btn` + `@media print` stylesheet handles it. m's broader chart-export design (`docs/design-project-chart-2026-05-09.md`) covers the export ambition for the project-level chart; this Tool-level surface keeps it simple.
+
+---
+
+## 12. Files implementer will touch (Slice 1 only)
+
+This is the bottleneck slice. Slices 2–4 each add their own scope but Slice 1 defines the structural change.
+
+**Backend (Go):**
+
+- `internal/handlers/handlers.go:162` — add `protected.HandleFunc("GET /tools/verfahrensablauf", handleVerfahrensablaufPage)`.
+- `internal/handlers/fristenrechner.go` — add `handleVerfahrensablaufPage` (1-liner, serves `dist/verfahrensablauf.html`). Or split into its own file `internal/handlers/verfahrensablauf.go` for tidiness.
+- `internal/handlers/handlers.go` — add back-compat 302: `/tools/fristenrechner?path=a` → `/tools/verfahrensablauf` (preserves bookmarked links). A small middleware or an `init` redirect handler suffices.
+
+**Frontend (TSX + TS):**
+
+- `frontend/src/verfahrensablauf.tsx` — new file. ~250 LoC. Renders header + jurisdiction-tab picker + proceeding-tile picker + result panel container. No variant chips, no compare yet (those are Slices 3+4). Reuses `<PWAHead>`, `<Sidebar>`, `<Footer>`.
+- `frontend/src/client/verfahrensablauf.ts` — new file. ~150 LoC for Slice 1. Wires the picker → POST `/api/tools/fristenrechner` → render via shared module.
+- `frontend/src/client/views/verfahrensablauf-core.ts` — new file. The lifted code: `renderTimelineBody`, `renderColumnsBody`, the `calculateDeadlines` fetch wrapper, court picker, view-toggle. Imported by both `client/fristenrechner.ts` and `client/verfahrensablauf.ts`.
+- `frontend/src/client/fristenrechner.ts` — delete the Step 2 "browse" card handler (lines 2715-2717 today). Remove the `?path=a` interpretation as a top-level entry (still keep `path="a"` as an Akte-mode wizard pathway). Import calc + render from `views/verfahrensablauf-core.ts`.
+- `frontend/src/fristenrechner.tsx` — delete the `fristen-step2-browse` card markup (lines 215-223 today).
+- `frontend/src/components/Sidebar.tsx:163-164` — change href from `/tools/fristenrechner?path=a` to `/tools/verfahrensablauf`. Adjust the `currentPath` comparison to match the new pathname.
+- `frontend/src/client/sidebar.ts:447 fixVerfahrensablaufActive` — delete the function + its call site.
+
+**Build:**
+
+- `frontend/build.ts` — add `renderVerfahrensablauf` import (line 5-6 area), add `client/verfahrensablauf.ts` to `entrypoints` array (line 228 area), add the `Bun.write(join(DIST, "verfahrensablauf.html"), renderVerfahrensablauf())` step (line 355 area).
+
+**i18n:**
+
+- `frontend/src/client/i18n.ts` + `i18n-keys.ts` — add `tools.verfahrensablauf.title`, `tools.verfahrensablauf.subtitle`, `nav.verfahrensablauf` (already exists; re-verify the key still points at the right label).
+
+**Tests:**
+
+- Playwright smoke covering: `/tools/verfahrensablauf` renders, sidebar nav link active class lights up correctly without `fixVerfahrensablaufActive`, `/tools/fristenrechner?path=a` 302s, the calc roundtrip works on both routes, build artefacts emit both `fristenrechner.html` and `verfahrensablauf.html`.
+
+**Out of Slice 1 (deferred to Slices 2-4):**
+
+- Step 0 toggle on `/tools/fristenrechner` (Slice 2).
+- Akte-driven auto-derivation helper service (Slice 2).
+- Variant chips, lane view (Slice 3).
+- Compare view (Slice 4).
+
+---
+
+## 13. Open questions for m
+
+1. **Sidebar label.** Keep "Verfahrensablauf" (current) or switch to "Verfahrensabläufe" (plural — reads as catalogue) or something else? Current label is unambiguous; plural risks reading as a list page.
+
+2. **Akte-mode mapping with no `proceeding_type_id`.** 11/11 live projects have NULL proceeding_type_id. Akte-mode silently degrades to "pick proceeding manually". OK? Or should Akte-mode require a proceeding_type_id and force the user to set it on the project first?
+
+3. **Court free-text → FK migration.** I'm flagging this as a follow-up but not designing it here. Want me to file a separate ticket so it's tracked, or fold it into Slice 2's scope?
+
+4. **Lane view caveat for v1.** The second lane uses the same trigger date as the primary (so dates are nominal-but-wrong for a real-world CCR filed weeks later). UI caveat "Annahme: Widerklage zur gleichen Zeit eingelegt" is honest but adds clutter. Acceptable or do we hold lane view back until trigger-2 input lands?
+
+5. **Compare view max columns.** v1 caps at 2. Three+ would be a richer compare ("UPC_INF vs DE_INF vs EPA_OPP for the same patent") but layout-hostile on anything <1280px. Confirm 2 for v1?
+
+6. **Back-compat for `?path=a`.** I propose a 302 redirect so old bookmarked URLs work. Alternative: 410 Gone (harsh) or 200-with-deprecation-banner (chatty). 302 is the conventional move; confirm?
+
+7. **Drop the "Verfahrensablauf einsehen" card from Step 2 entirely** vs keep it as a deep-link shortcut to `/tools/verfahrensablauf` from inside the Fristenrechner flow? I'm proposing drop; m signals?
+
+8. **DE_INF / EPA_OPP / DPMA variants.** Today no `condition_flag` rules. Future seed-data tickets (out of scope here): with/without expedited, with/without amendment for EPA opposition, etc. Want a follow-up ticket filed for the seed-data work or wait for user feedback?
+
+9. **Pathway B (Determinator) entry point in Abstract mode.** I propose a small "Frist aufgrund Ereignis" link in the result panel. Or hide it entirely from abstract mode? Today Pathway B is reachable from anywhere via `?path=b`.
+
+10. **Implementer choice.** I'd recommend a coder familiar with `frontend/src/client/fristenrechner.ts` for Slice 1 since the bundle split is the load-bearing risk. Curie (t-paliad-086), cronus (t-paliad-088, t-paliad-110), noether (t-paliad-165) have all touched the file. Head decides.
+
+---
+
+**DESIGN READY FOR REVIEW**
+
+Slice 1 is the structural foundation (route split, sidebar cleanup, code lift). Slices 2-4 layer Step 0 / variant chips / compare on top. Awaiting m's go/no-go before coder shift.

docs/design-universal-filter-2026-05-08.md

@@ -0,0 +1,469 @@
+# Universal filter + view-mode primitive across all entity-views
+
+**Issue:** m/paliad#23 (t-paliad-163)
+**Inventor:** riemann (mai/riemann/inventor-universal)
+**Date:** 2026-05-08
+**Status:** READY FOR REVIEW — no code yet, design only.
+
+---
+
+## TL;DR — the central position
+
+m's framing is exactly right: "halfway there without custom views". The Custom Views substrate (t-paliad-144) is the missing primitive — it just hasn't been lifted from "a saved-view feature on /views/{slug}" up to "the bar that every list-shaped page reads from".
+
+Concrete take:
+
+- **Don't invent a new schema or a new query layer.** `internal/services/filter_spec.go` + `render_spec.go` + `view_service.go` already cover every axis the issue lists, and `POST /api/views/run` and `POST /api/views/{slug}/run` already accept ad-hoc spec overrides. The substrate's own comment says it: *"Phase B will route them here; Phase A1 leaves the wiring as a no-op for those pages."* (`internal/handlers/views.go:247`). t-paliad-163 is Phase B with a UX-shaped artifact at the front.
+- **Build one frontend `<FilterBar>` component** that consumes a `FilterSpec` + `RenderSpec` + a per-surface `axes[]` declaration, owns URL/local-state, and emits diffs. Drop it on every list-shaped surface. Each system page declares a base spec (= one of the existing `SystemView` definitions) and the supported axes.
+- **"Save current filter as named view" is one button** on the bar. It POSTs the effective spec to `/api/user-views`. The custom-view editor (`/views/new`, `/views/{slug}/edit`) becomes a power-user form for the same data the bar produces; the bar is the everyday entry point.
+- **/projects stays bespoke** (locked in t-paliad-149). Source⊥Shape orthogonality breaks for projects — they don't render as cards/calendar in the events sense, and `paliad.user_card_layouts` is a different primitive (per-card facts, not filters). The bar coexists with the `<details>`-chip cluster on /projects without subsuming it.
+
+The migration is one surface at a time. /inbox first (no filter today, lowest blast radius), /events last (richest filter today, the proof point that the primitive can absorb it).
+
+---
+
+## 0. Premises verified live
+
+Before designing on top of CLAUDE.md / memory / the issue body, I checked the live tree:
+
+- **`paliad.user_views` (056) exists.** `paliad.user_card_layouts` (061) exists. **`paliad.user_view_layouts` does NOT exist** — the issue body's reference is a typo. Real names: `paliad.user_views` is the FilterSpec/RenderSpec store; `paliad.user_card_layouts` is the per-card-facts store for /projects only. `grep -rn user_view_layouts` returns nothing.
+- **`POST /api/views/run`** takes an inline `FilterSpec` and returns `ViewRunResult{rows, inaccessible_project_ids}` without touching the DB. (`internal/handlers/views.go:248`)
+- **`POST /api/views/{slug}/run`** accepts an optional `{filter: <override>}` body that overrides the saved/system spec for one run — does not mutate storage. (`internal/handlers/views.go:282`, `runRequest` at `:238`)
+- **5 SystemViews are already code-resident** (`dashboard`, `agenda`, `events`, `inbox`, `inbox-mine`) at `internal/services/system_views.go:35`-`156`. Their slugs are reserved against user-view collisions. Each carries a canonical `FilterSpec` + `RenderSpec`.
+- **3 render-shape components exist** in `frontend/src/client/views/`: `shape-list.ts`, `shape-cards.ts`, `shape-calendar.ts`. They take `(host, rows, render)` — pure config-driven dispatch.
+- **List shape supports density (compact|comfortable), 13 known columns, and sort.** Column registry at `internal/services/render_spec.go:99`: `["date","time","title","project","actor","status","rule","event_type","location","appointment_type","approval_status","decided_by","kind"]`. Sort: `date_asc | date_desc`.
+- **`attachEventTypeMultiSelectFilter`** in `frontend/src/client/event-types.ts` is a mature listbox-panel component (search + grouped checkboxes + URL round-trip + internal `onLangChange` subscription per t-paliad-117). The pattern to copy for project + appointment-type + status panels.
+- **`renderAgendaTimeline`** in `frontend/src/client/agenda-render.ts` is the day-grouped timeline used both by `/agenda` and dashboard inline; reusable.
+- **`.entity-table` row-click contract** is the project-wide rule (CLAUDE.md "Frontend conventions"). Any list-shape table must wire row-handlers that skip clicks on inner `<a>`/`<button>` and add `entity-table--readonly` when rows don't navigate. The bar must not regress this — it doesn't, because `shape-list.ts` already emits `entity-table--readonly` on its tables.
+
+---
+
+## 1. The 7 list-shaped surfaces today — what they each have
+
+A factual map of who has what. The underlinings are the axes the issue calls out.
+
+| Surface | Filter axes today | View modes | State store |
+|---|---|---|---|
+| **/agenda** (`client/agenda.ts`, 226 LoC) | type chip (deadlines/appointments/both), range chip (7/14/30/90d), event-type multi-select | timeline only | URL `?range=&types=&event_type=` |
+| **/events** (`client/events.ts`, 1083 LoC) — also `/deadlines`, `/appointments` via 302 redirect | type chip (deadline/appointment/all), status select (8 buckets), project select (single, with `__personal__` sentinel), event-type multi (deadline-only), appointment-type select (appointment-only) | cards / list / calendar | URL `?type=&view=&status=&project_id=&personal_only=&event_type=&type_filter=` |
+| **/inbox** (`client/inbox.ts`, 329 LoC) — both tabs | tab (pending-mine / mine), nothing else | list only | URL `?tab=` |
+| **/projects** (`client/projects.ts` + `client/projects-cards.ts`) | search input, 6 chips (scope/status/type/has-open-deadlines), `<details>` multi-select for status + type | tree / cards / flat | sessionStorage `paliad.projects.lastView` + URL overlay |
+| **/views/{slug}** (`client/views.ts`) | none in the viewer (only saved-spec); shape switcher (list/cards/calendar) | list / cards / calendar | URL path |
+| **dashboard** (`client/dashboard.ts`, inline Agenda + Letzte Aktivität) | none | inline timeline / inline list | none |
+| **/views/new \| /views/{slug}/edit** (`client/views-editor.ts`) | full FilterSpec form (sources / scope / time / shape / list density) | n/a — author surface | n/a |
+
+The pattern m sees on `/inbox?tab=mine` is the natural endpoint of seven surfaces all building filters their own way: the surface that didn't have a filter author yet is also the surface with no filter chrome at all.
+
+The good news: every axis on every surface is **already nameable in the FilterSpec / RenderSpec grammar** that `internal/services/filter_spec.go` ships. There's a one-to-one mapping; nothing has to be invented at the data layer.
+
+---
+
+## 2. What the universal primitive is — `<FilterBar>`
+
+A single TypeScript component, mounted on a host `<div>`, parameterised by:
+
+```ts
+interface FilterBarOpts {
+  // Base spec — usually a SystemView's FilterSpec, fetched from /api/views/system.
+  // For /views/{slug}, this is the user-view's saved filter_spec.
+  baseFilter: FilterSpec;
+  baseRender: RenderSpec;
+
+  // Which axes the surface supports. Universal axes always render;
+  // per-surface axes render iff present in this list.
+  axes: AxisKey[];
+
+  // Optional fixed predicates the surface refuses to let users tweak.
+  // E.g. /inbox forces sources=[approval_request], not relaxable.
+  pinned?: PartialFilterSpec;
+
+  // Where to write rows when filter changes. The bar runs the spec via
+  // /api/views/run and hands the result back here for shape rendering.
+  onResult: (res: ViewRunResult, effective: { filter: FilterSpec; render: RenderSpec }) => void;
+
+  // Optional URL-param namespace (defaults to the empty namespace).
+  // Useful for embedding the bar twice on one page (dashboard inline)
+  // without colliding ?time= / ?time2=. Phase 4 ramps this up if needed.
+  urlNamespace?: string;
+
+  // Optional surface key — used as the localStorage key for view-mode
+  // and density preferences ("paliad.bar.<surfaceKey>.prefs").
+  surfaceKey: string;
+
+  // Optional sidebar slot — when present, "Save as view" + "Reset" are
+  // rendered. Defaults to true on every surface except dashboard inline.
+  showSaveAsView?: boolean;
+}
+
+type AxisKey =
+  | "project"          // ← universal (always rendered if axes contains it; otherwise the chip is hidden)
+  | "time"             // ← universal
+  | "personal_only"    // ← universal
+  | "deadline_status"  // ← per-surface (deadline source only)
+  | "deadline_event_type"
+  | "appointment_type"
+  | "approval_viewer_role"
+  | "approval_status"
+  | "approval_entity_type"
+  | "project_event_kind"
+  | "shape"            // ← view-mode (list|cards|calendar)
+  | "sort"             // ← per-shape
+  | "density"          // ← list-shape only
+  | "columns";         // ← list-shape only (advanced; popover with checkboxes)
+```
+
+The bar's job:
+1. On mount, parse URL params (within `urlNamespace`) and `localStorage["paliad.bar.<surfaceKey>.prefs"]`, overlay them on `baseFilter` + `baseRender`, validate, and POST `/api/views/run` with the effective spec.
+2. Render chrome — chips for booleans / single-selects, popovers for multi-selects, segmented control for view-mode. Each control is a thin wrapper over an existing pattern (chip-row, multi-anchor + multi-panel, segment-control).
+3. On any change, re-validate, sync URL, sync localStorage (for prefs only — see §3), POST the spec again, hand the result + effective spec to `onResult`. The shape host renders.
+4. Expose two trailing actions (when `showSaveAsView`): **Speichern als Sicht** and **Zurücksetzen**.
+
+What the bar is NOT:
+- Not a router. Pages still own their URL.
+- Not a layout system. Cards on /projects keep the `paliad.user_card_layouts` primitive (per-card facts) — that's orthogonal to filtering.
+- Not the renderer. The bar just hands `(rows, effectiveRender)` to one of `shape-list / shape-cards / shape-calendar`.
+- Not a substitute for the dedicated views editor. That stays for power-users who want full control (predicates, custom horizons, columns).
+
+---
+
+## 3. The 7 brief items — taking positions
+
+### 3.1 Filter axes: which are universal, which are per-surface, how does the bar declare its supported axes?
+
+**Universal** — render always when `axes` contains them (and the surface's pinned spec doesn't rule them out):
+- `project` — single-select with the existing `<select>` (Alle / Nur persönliche / each project, ltree-indented). On surfaces where multi-project would help later (system-wide views), the same control upgrades to a multi-select listbox-panel by adding a `multi: true` flag — postpone to phase C, single-select covers every surface today.
+- `time` — segmented chip group (`Heute · 7T · 30T · 90T · Alles · Anpassen`). Maps to `time.horizon`. "Anpassen" pops a date-range pair (`time.horizon = "custom"` + from/to). On /inbox the chip group reads "Heute · 7T · 30T · Alles" since approval queues are usually now-shaped — but the same control.
+- `personal_only` — boolean chip ("Nur eigene"). Active when `scope.personal_only=true`. Hidden when source set excludes deadline AND appointment (others don't honour personal_only).
+
+**Per-surface** — declared in `axes`, controlled by which sources the spec uses:
+- `deadline_status` (chip cluster: "Offen · Überfällig · Erledigt · Alle") — only when `sources` includes deadline.
+- `deadline_event_type` (multi-select listbox-panel, reuses `attachEventTypeMultiSelectFilter`) — only when sources includes deadline.
+- `appointment_type` (single-select for now: hearing/meeting/consultation/deadline_hearing/Alle) — only when sources includes appointment.
+- `approval_viewer_role` (segmented chips: "Zur Genehmigung · Eigene Anfragen · Alle sichtbaren") — only when sources includes approval_request. This subsumes the /inbox tab.
+- `approval_status` (chip cluster: "Wartend · Entschieden · Alle") — only when sources includes approval_request.
+- `approval_entity_type` (chip pair: "Fristen · Termine") — only when sources includes approval_request.
+- `project_event_kind` (multi-select listbox-panel; the 13 `KnownProjectEventKinds`) — only when sources includes project_event. Powers the dashboard "Letzte Aktivität" filter.
+
+**View-mode + per-shape** — declared in `axes`, but special:
+- `shape` — segmented chips (list/cards/calendar). Always rendered when `axes` contains `shape`; available shapes derived from `baseRender` + the surface's whitelist. The bar emits a transient render override (mirrors how `client/views.ts:171` does shape-switching today: it doesn't rerun, just re-renders).
+- `sort` — single-select (`date_asc | date_desc`).
+- `density` — segmented chip pair (Komfortabel / Kompakt) — list shape only, hidden otherwise.
+- `columns` — popover with checkbox list of `KnownListColumns` — list shape only, advanced opt-in.
+
+**How the surface declares its axes:** an array. No higher-order component, no slot composition. Plain config. The bar's render is a switch over each axis key:
+
+```ts
+mountFilterBar(host, {
+  baseFilter: agendaSystemView.filter,
+  baseRender: agendaSystemView.render,
+  axes: ["time", "project", "personal_only", "deadline_status", "deadline_event_type", "appointment_type", "shape", "sort"],
+  surfaceKey: "agenda",
+  onResult: ({rows, inaccessible_project_ids}, effective) => { ... },
+});
+```
+
+Slot composition was considered. It's overkill — every existing chrome pattern paliad uses (chip cluster, multi-anchor popover, segmented control, `<select>`) is already in `frontend/src/styles/global.css`; there's nothing to plug or override. A flat axis-config keeps the bar a 600-LoC component, not a framework.
+
+### 3.2 State model: URL vs in-memory vs hybrid
+
+**Hybrid**, with a sharp split:
+
+- **URL is canonical** for everything that affects which rows you see. That means: project (`?project=`), sources (`?sources=`), time (`?time=` for horizon, `?from=&to=` for custom), personal-only, every per-source predicate (`?deadline_status=`, `?event_type=`, `?appointment_type=`, `?approval_role=`, `?approval_status=`, `?approval_entity_type=`, `?project_event_kind=`), shape (`?shape=`), sort (`?sort=`). Bookmarkable, shareable, refresh-survives, deep-linkable from the dashboard or /inbox bell.
+- **localStorage holds preferences** that don't change rows: density (`?density=` is also a URL param when explicitly chosen, but absence falls through to localStorage default), default columns per surface (advanced opt-in), default shape per surface (only when the user has overridden the SystemView's default — first visit uses base). Keyed `paliad.bar.<surfaceKey>.prefs`. Mirrors the spirit of /projects' sessionStorage `paliad.projects.lastView` (t-paliad-149 Q1 lock-in) but at the right scope: the "what I prefer" sticks per surface, the "what this URL is showing" stays in the URL.
+- **No sessionStorage.** /projects' use was justified by tab restoration; for the bar, every interesting bit is in the URL (so back/forward + refresh + share both work). Adding a third tier would create the worst-of-three: state in URL ∪ session ∪ local, three places to look when something's off.
+
+URL parameter names are stable and short. The bar exports a tiny URL codec (`encodeBarParams(filter, render) → URLSearchParams` and inverse) so the same params work whether the bar is on /agenda, /inbox, /events, or /views/{slug}.
+
+The migration from /events' bespoke `?type=&view=&status=&project_id=&personal_only=&event_type=&type_filter=` to the bar's params is straightforward: each old param maps to a new one (or stays, when names already match — `?project_id`, `?personal_only`, `?event_type` are unchanged; `?type` becomes `?sources`; `?view` becomes `?shape`; `?status` and `?type_filter` become per-surface predicates). Server middleware on the legacy /events handler can rewrite old → new params for one release so existing bookmarks don't 404.
+
+### 3.3 View-mode switcher — universal or per-surface? Sort-state ownership? Density?
+
+**Universal.** The bar always owns the segmented `shape` control. The surface declares which shapes it whitelists (e.g. /inbox might whitelist `["list"]` and hide the switcher; /agenda might whitelist `["cards", "list", "calendar"]`). When the whitelist has only one entry the bar suppresses the chip; when ≥2 it renders.
+
+**Sort lives in the bar's `RenderSpec.list.sort` / `cards.sort`.** Already exists in the schema. The list-shape table renderer is currently sort-by-config-only; promoting `<th>` clicks to update `RenderSpec.list.sort` is a one-line callback in the bar (`onListHeaderSort`) → server-side re-sort isn't needed because `shape-list.ts:16` already sorts in JS. **Sortable column headers become a list-shape feature owned by the bar**, not a per-surface concern.
+
+**Density** is a list-shape config (`comfortable | compact`). The bar exposes the pair as a chip; `shape-list.ts` already supports both. Density on /inbox today is implicitly comfortable; toggling it to compact gives the user the activity-feed look on the inbox surface for free, which is the kind of small win the brief calls out.
+
+**Multi-column sort** is out-of-scope for v1 — `shape-list.ts:16` does single-column sort, which matches every surface today. Add when a user asks.
+
+### 3.4 Composability — drop-in API without forcing existing pages to refactor
+
+The bar mounts onto an empty `<div>`. The surface's TSX changes are:
+- Replace the per-page filter chrome (chip cluster, selects, popovers, view-mode segment) with `<div id="filter-bar"></div>`.
+- Replace the per-page result rendering with `<div id="filter-bar-results"></div>`.
+- The page's `client/<surface>.ts` shrinks to: read `__PALIAD_<SURFACE>__` initial payload (or skip), call `mountFilterBar(host, opts)`, write `onResult` to dispatch into the matching shape component (already exist).
+
+That's it. The page surface is reduced to ~50 LoC of orchestration around the bar; the bulk of `events.ts` (1083 LoC) drops to a baseline of ≈80 LoC after Phase 3 because the per-axis filter state, the project select populator, the language-hot-swap, the URL-sync, the type-visibility logic, the appointment-type filter logic, the calendar month-paging, and the cards-vs-list-vs-calendar dispatch all migrate into shared components: the bar (filter axes, view-mode, URL, language hot-swap), `shape-list.ts` (table), `shape-cards.ts` (cards), `shape-calendar.ts` (month grid).
+
+The bar **does not own row interaction**. Row click → detail page is already a per-shape concern (`shape-list.ts` emits `entity-table--readonly`; the bar doesn't override that). Lifecycle actions (complete/reopen/approve/reject) are also per-shape — `shape-list.ts` will need a small extension to emit clickable-row tables on /events (so the existing complete-checkbox + reopen flow keeps working). That extension is one new render flag in `RenderSpec.list.row_action: "navigate" | "approve" | "complete-toggle" | "none"`, defaulting to navigate. Honest scope: this is a small `RenderSpec` schema bump (new optional field), not an axis change.
+
+### 3.5 Reuse with the existing /views layout-spec — does the universal bar inherit, or does the spec become a special case of saved bar state?
+
+**The latter.** m's hint ("halfway there without custom views") points at exactly this.
+
+A **Custom View is the persisted form of a bar state.** When the user clicks "Speichern als Sicht" on /agenda, the bar gathers the effective `FilterSpec` + `RenderSpec`, prompts for name + slug + icon + show-count (a small modal — one form, four fields, mirroring `views-editor.ts`'s collectForm), and POSTs `/api/user-views`. The user is then redirected to `/views/{slug}` (or stays in place with a confirmation toast — see §3.7).
+
+Conversely, **a SystemView is a code-resident bar state.** The bar already knows how to load one (`/api/views/system` → match slug). The "system pages" become surfaces whose default state happens to live in code instead of in `paliad.user_views`.
+
+Implementation consequence:
+- `views-editor.ts` keeps existing for power users who want to edit predicates that the bar doesn't expose (e.g. pinning a `time.field = "created_at"` for an "audit-trail" view). The editor and the bar produce identical `FilterSpec` + `RenderSpec` JSON; they're alternate authoring UX.
+- `views.ts` (the `/views/{slug}` viewer) gains the bar above its rows. The bar renders with the saved spec as its base; the user can tweak axes (e.g. narrow the time horizon for a quick glance) — those tweaks are URL-overlays and don't mutate the saved spec until the user clicks "Aktualisieren" (a new affordance). This satisfies the brief's "halfway there" hint: today /views/{slug} renders a saved spec **statically**; with the bar, it becomes interactive without losing the saved-state semantics.
+
+### 3.6 Migration path — phase one surface at a time, identify the hardest
+
+The bar is shippable on one surface in one PR. Then each subsequent surface is its own small PR.
+
+**Phase 1 — /inbox (the cold start).** Lowest blast radius: today /inbox has no filter chrome, only tabs. Replace tabs with the `approval_viewer_role` axis (the bar collapses two tabs into one chip cluster). Drop the bar with `axes: ["time", "approval_status", "approval_entity_type", "approval_viewer_role", "shape", "density", "sort"]`. Pin `sources: [approval_request]`. Density toggle gives the user a stream view m's "looks really bad" was diagnosing. URL contract: keep `?tab=` redirecting to `?approval_role=` for one release.
+
+**Phase 2 — /agenda.** Already filter-shaped and the most readable orchestrator (226 LoC). Bar replaces the chip cluster + range chip + event-type popover. `axes: ["time", "project", "personal_only", "deadline_status", "deadline_event_type", "appointment_type", "shape", "sort"]`. Default: shape="cards" (matching today's timeline default). The dashboard inline Agenda gets a stripped-down bar with `axes: ["time", "deadline_event_type"]` and `urlNamespace: "agenda"` (so the page-level bar on the dashboard doesn't collide with anything else if the dashboard adds another bar later for "Letzte Aktivität").
+
+**Phase 3 — /events (the proof point).** Most complex filter today: type chip + status select + project select + personal-only + event-type multi + appointment-type select + cards/list/calendar. Every one of these axes is already nameable in FilterSpec/RenderSpec (verified §1). `axes: ["time", "project", "personal_only", "deadline_status", "deadline_event_type", "appointment_type", "shape", "sort", "density"]`. The 5-card summary above the table (Heute / Diese Woche / Nächste Woche / Später / Überfällig) becomes a bar-driven facet: clicking a card sets `time.horizon` (or for "Überfällig", a special `deadline_status: ["overdue"]` predicate). Identifying /events as the hardest surface up front means the primitive's axis registry has to be wide enough on day 1; the design above already names every needed axis, so Phase 1's primitive is forward-compatible.
+
+**Phase 4 — dashboard inline lists (Agenda + Letzte Aktivität).** The dashboard composes two tiny bars: one for Agenda (cards/list, narrow time horizon, no save-as-view), one for Letzte Aktivität (project_event source, density=compact, no save-as-view). Both use `urlNamespace` to keep params tidy.
+
+**Phase 5 — /views/{slug}.** Add the bar above the rows. Saved spec → bar's base; URL overlays are transient until "Aktualisieren" persists them. The custom-view editor (`/views/new`, `/views/{slug}/edit`) stays for power users; "Speichern als Sicht" from the bar is the everyday path.
+
+**Out of phasing:** /projects stays bespoke. The bar coexists on the page only if a future task adds it — today the chip cluster + tree/cards/flat segment are doing fine, and Source⊥Shape orthogonality breaks for projects (no ProjectSource in the substrate; no TreeShape in the substrate). t-paliad-149's locked-in choice stands.
+
+**Hardest surface, identified:** /events. Phase 3 is the proof point. By designing the bar's axis registry against /events on day 1 (not retrofitting), Phase 1 (/inbox) and Phase 2 (/agenda) ship without redesign churn.
+
+### 3.7 "Save current filter as named view" — making it trivial
+
+The bar's trailing action is a single button: **Speichern als Sicht**. Click → small modal:
+
+```
+┌─ Sicht speichern ─────────────────────┐
+│ Name      [_________________]         │
+│ Slug      [_________________]  (opt)  │
+│ Icon      [▼ Auswählen          ]     │
+│ □ Anzahl in der Sidebar zeigen        │
+│                                       │
+│         [ Abbrechen ]   [ Speichern ] │
+└───────────────────────────────────────┘
+```
+
+If slug is empty, derive from name (kebab-case) and validate against the regex + reserved-slug list client-side (mirrors `views-editor.ts:179`). On 409 (slug taken), show inline error and let the user adjust. On success, two affordances:
+- A toast "Als Sicht 'Heute überfällig' gespeichert. Zur Sicht wechseln?" with a link to `/views/{slug}`.
+- The new view automatically appears in the **Meine Sichten** sidebar group (t-paliad-144) on next page load (or sooner, if the bar emits a window event the sidebar listens to).
+
+This means: every list-shaped surface gets "save current filter as named view" for free. No per-surface plumbing.
+
+**"Aktualisieren" on /views/{slug}** is the symmetric write-back: when the user is viewing a saved view and tweaks the bar, a "Aktualisieren" button appears next to "Speichern als Sicht". Click → PATCH `/api/user-views/{id}` with the effective spec. Confirmation toast.
+
+**"Zurücksetzen"** clears the URL overlay and re-renders with the base spec only.
+
+---
+
+## 4. Two harder questions worth surfacing now
+
+### 4.1 The chip-vs-popover-vs-select tension
+
+paliad has three patterns for "pick from a set" today:
+
+- **Chip cluster** (e.g. /agenda type chip, /projects scope chip) — best for 2–4 mutually exclusive options. Always-visible, click-fast.
+- **`<select>`** (e.g. /events status, project, appointment-type) — best for 5–30 single-select options, especially when the option list is dynamic (project list grows).
+- **Listbox-panel popover** (e.g. event-type multi, /projects status/type `<details>`) — best for multi-select or for >30 options with search.
+
+The bar must use the right pattern per axis to feel native, not regress one surface in service of another. My picks:
+
+| Axis | Pattern | Why |
+|---|---|---|
+| project (single) | `<select>` | dynamic list; option count grows with the firm |
+| time | chip cluster + "Anpassen" overflow | 5 mutually exclusive presets cover 95% of usage |
+| personal_only | single chip | binary |
+| sources (when `axes` exposes it) | listbox-panel multi | 4 options but multi-select |
+| deadline_status | chip cluster | 4 options, mutually exclusive |
+| deadline_event_type | listbox-panel multi | 40+ options, search + grouped checkboxes (reuses event-types.ts pattern) |
+| appointment_type | chip cluster (4 + Alle) | small mutually-exclusive set |
+| approval_viewer_role | chip cluster | 3 mutually exclusive options |
+| approval_status | chip cluster | 4 options |
+| approval_entity_type | chip cluster | 2 options |
+| project_event_kind | listbox-panel multi | 13 options, multi-select |
+| shape | segmented control | 1-of-N, special UX (icon-only buttons) |
+| sort | `<select>` (small) | 2 options today, room for `title_asc/desc` later |
+| density | segmented control | binary, icon-shaped |
+
+The point: the bar isn't one widget, it's a thin shell that delegates each axis to the right existing control. CSS reuse: `.agenda-chip` / `.events-view-btn` / `.akten-multi-trigger` / `.multi-anchor` / `.multi-panel` all stay; the bar just composes them.
+
+### 4.2 Empty-state UX when an axis is invalid for the current sources
+
+If the user clears all sources, every per-source axis becomes meaningless. Two options:
+- **Hide invalid axes.** Cleanest. Bar reacts to source changes by collapsing dependent chips. Risk: feels jumpy.
+- **Disable + tooltip.** Less jumpy but visually noisier.
+
+Recommend **hide**, with one twist: the bar persists hidden-axis state in the URL anyway, so toggling sources back on restores the user's prior filter. This matches /events' existing behaviour (when type=appointment, event-type panel is hidden but its state persists in `?event_type=`).
+
+---
+
+## 5. RenderSpec extensions — one schema bump
+
+The bar exposes capabilities that are already in `RenderSpec` (shape, sort, density, columns) plus one new field:
+
+```go
+type ListConfig struct {
+    Columns     []string    `json:"columns,omitempty"`
+    Sort        SortOrder   `json:"sort,omitempty"`
+    Density     ListDensity `json:"density,omitempty"`
+    RowAction   ListRowAction `json:"row_action,omitempty"` // NEW — "navigate" (default) | "complete_toggle" | "approve" | "none"
+}
+```
+
+`RowAction` lets `shape-list.ts` know whether to wire an `entity-table--readonly` or to attach the existing checkbox / reopen / approve / reject buttons. Default `navigate` keeps the contract stable; system pages explicitly set `complete_toggle` (events list) and `approve` (inbox list).
+
+This is the only schema change. Every other axis is already in the spec.
+
+---
+
+## 6. Hard requirements from the brief — addressed
+
+- **`.entity-table` row-click contract.** The bar's list-shape table is rendered by `shape-list.ts:80` which already emits `entity-table--readonly`. When `RowAction="navigate"` the bar adds a row-handler that does `window.location.href = detailRoute(row)` and skips clicks on inner `<a>`/`<button>` (mirrors the existing `events.ts:wireRowHandlers` pattern). Whole-card / whole-row click → JS row-handler, never `::before` overlays (CLAUDE.md frontend conventions, t-paliad-102).
+- **No hour estimates.** Throughout this design.
+- **DE+EN bilingual.** Every new label gets a key under `views.bar.*` (single new namespace; ~25 keys for axes + ~10 for save modal + ~10 for empty/loading/error states). Keys are added to `frontend/src/client/i18n.ts`'s registry at the appropriate phase.
+- **Mobile.** The bar collapses to a single horizontal scroll row on `≤768px` (mirrors `.frist-summary-cards` mobile pattern). The "Speichern als Sicht" + "Zurücksetzen" actions move into a `<details>` "Mehr" affordance on mobile to keep the scrollable strip clean. Re-imagining mobile-list-mode is out of scope per the brief.
+
+---
+
+## 7. Trade-offs — the honest list
+
+### What this design gains
+1. **One filter chrome across all list-shaped surfaces.** Users learn one bar, every surface respects it. Discoverability for "save as view" jumps from one surface (/views/new editor) to seven.
+2. **System pages become substrate clients.** `/api/views/run` (already shipped) becomes the canonical event-fetching path. Phase B from t-paliad-144 design lands.
+3. **`events.ts` shrinks ~10×.** Most of its 1083 lines are filter chrome + URL sync + view-mode dispatch — all now shared.
+4. **Save-as-view is universal.** Today only /views/new + /views/{slug}/edit can author saved views; after the migration, every page can.
+5. **/inbox gains filters and sort and density** as a free side effect of the migration — directly addressing m's "looks really bad" diagnosis.
+6. **Sortable column headers** become a substrate feature (small bar callback that updates `RenderSpec.list.sort`).
+7. **The schema barely moves** — one new optional field on `ListConfig`. Migrations not needed.
+
+### What this design risks
+1. **One component holding many axes is at risk of bloat.** Mitigation: the bar is a flat axis-config (no slot composition, no HOC). 600 LoC ceiling enforced by the per-axis switch pattern. CSS reuse keeps the visual surface small.
+2. **The /events migration is the largest single PR.** 1083 LoC client → ≈100 LoC + ≈250 LoC of bar config + per-shape extensions. A regression on the 5-card summary or the deadline complete/reopen flow would be visible. Mitigation: Phase 3 is gated behind Phase 1 (/inbox) and Phase 2 (/agenda) shipping cleanly, and the design lands the `RowAction` schema bump in Phase 1 so `complete_toggle` is wired before /events arrives.
+3. **URL overlay on /views/{slug} creates two states.** Saved spec ≠ effective spec when the user has tweaked the bar. The "Aktualisieren" / "Speichern als Sicht" actions resolve which becomes canonical, but a user who navigates away with unsaved tweaks loses them. Mitigation: a `?dirty=1` URL marker + a small toast on first tweak ("Änderungen sind nicht gespeichert").
+4. **Two filter chromes coexist on /projects.** The bar doesn't subsume the chip cluster (Source⊥Shape break). Future visual unification would standardise the chip pattern between the two — out of scope here.
+5. **Hidden-axis URL state.** Persisting `?event_type=` even when sources excludes deadline can confuse a user reading their URL. Acceptable: matches /events' current behaviour and is reversible by toggling the source back. The alternative (pruning URL params on source change) loses the user's prior state on a quick re-toggle.
+6. **i18n hot-swap correctness.** Every dynamic populator must subscribe to `onLangChange` (the t-paliad-117 lesson). The bar handles this once internally for every axis; surfaces don't need to wire it per-page.
+7. **Default per-surface defaults can drift from SystemView.** The bar reads `localStorage` for prefs (e.g. preferred shape on /agenda). If a user toggles a pref then a SystemView default changes, the user's pref wins. Mitigation: `localStorage` only stores explicit overrides, not the base value, so changes to the SystemView's base flow through for users who haven't overridden.
+8. **Two storage primitives ("user_views" + "user_card_layouts") could be confusing.** Names are similar; they store different things. Mitigation: documentation. The bar only ever reads/writes `paliad.user_views`. /projects' card-layout is a separate, narrow concern that stays bespoke.
+
+### Reversibility
+- The bar is purely additive. Phase 1 doesn't touch /agenda or /events. If after Phase 1 the bar feels wrong, /inbox can revert to its prior chrome by reverting one PR. Phase 2 only ships after Phase 1 holds.
+- The new `RenderSpec.list.row_action` field is optional with a `navigate` default; existing rows continue to render correctly.
+- The URL contract is preserved for /events for one release via a thin redirect middleware that maps old → new params; bookmarks don't 404.
+
+---
+
+## 8. Open questions for m before lock-in
+
+These are decisions where my recommendation might be challenged:
+
+**Q1. State model: full URL-canonical, or do we accept localStorage for shape/density preferences?** I recommend hybrid: URL for filter axes, localStorage for shape + density prefs (per-surface). Keeps shareable URLs honest while letting "I always want compact density on /inbox" persist across sessions.
+
+**Q2. Save-as-view modal vs slide-out vs inline.** I recommend modal — minimal surface, four fields, blocks the page. Alternatives: a slide-out (less interruption, more work) or an inline expansion of the "Speichern" button (cramped on mobile). Modal lines up with existing `<dialog>` usage on /admin.
+
+**Q3. /events 5-card summary — keep, or fold into the bar?** I recommend keep (above the bar, unchanged). The cards encode urgency at a glance; collapsing them into the bar's `time` chip would lose the "9 / 3 / 2 / 5 / Überfällig 1" density. Clicking a card still updates the bar's time horizon (existing behaviour preserved).
+
+**Q4. Tabs on /inbox — collapse into the `approval_viewer_role` chip cluster, or keep tabs as visual chrome above the bar?** I recommend collapse — one fewer place for state, the chip cluster is exactly the right control for 3 mutually exclusive options. Counter-argument: tabs are a strong visual hint of "two pages with the same shape". My counter-counter: the bar's chips are the same hint, less mid-air.
+
+**Q5. URL parameter naming.** I recommend short, namespaced names: `?time=`, `?sources=`, `?project=`, `?personal=`, per-source predicate names (`?d_status=` for deadline.status, `?a_role=` for approval_request.viewer_role, `?pe_kind=` for project_event.event_types). Cargo-friendly to long names like `?deadline_status=` if m prefers — same axis, same wire format.
+
+**Q6. "Speichern als Sicht" on the dashboard inline bars — show or hide?** I recommend hide. The dashboard composes two tiny bars; saving a sub-bar's spec as a custom view would feel disjoint from the dashboard concept. Power users can craft custom views via /views/new instead.
+
+**Q7. Migration: do we keep `?type=` redirecting on /events for one release, or hard-cut?** I recommend keep for one release (small middleware in `internal/handlers/events_pages.go`) so existing bookmarks (Sidebar, internal docs, the /events sidebar links at `events.ts:838`) keep working through Phase 3.
+
+**Q8. /views/{slug} — should the URL overlay tweak persist in localStorage as a "draft" until the user resets or saves?** I recommend no — URL is the only state, and a tweak that disappears on reload matches user expectation. The `?dirty=1` toast is enough. Alternative: a per-view-id `paliad.bar.view-{id}.draft` localStorage key that re-applies on re-visit — more powerful, more surprising.
+
+**Q9. Sortable column headers — list shape only, or also rule for cards/calendar in a future phase?** I recommend list-shape only for v1. Cards and calendar have their own ordering semantics (group_by + within-group sort); promoting headers would over-complicate.
+
+**Q10. Bar embedding twice on dashboard — `urlNamespace` worth the complexity, or single namespace and accept that dashboard's two bars share `?time=`?** I recommend `urlNamespace` for dashboard only (e.g. `?agenda_time=` and `?activity_time=`). Costs ~10 LoC, keeps two bars from colliding.
+
+**Q11. Multi-project select — phase C, or fold into Phase 2?** I recommend phase C. Single-project covers every surface today; multi-project unlocks "all my Düsseldorf cases this week" type queries but no current page asks for it. Save complexity until a user does.
+
+**Q12. EventTypeMultiSelect today supports `none` ("Ohne Typ") — keep or drop?** I recommend keep. The bar's deadline_event_type axis just wraps `attachEventTypeMultiSelectFilter`, so `none` works as-is. Honestly nothing to design here.
+
+---
+
+## 9. Scope boundaries (in + out)
+
+### In scope
+- New `<FilterBar>` component + axis registry + URL codec.
+- One `RenderSpec.list.row_action` field with validator update.
+- Phase 1: /inbox surface + tests.
+- Documentation + i18n keys for the bar.
+- Phase 2..5 named in the migration path with clear gates between them — but each is its own PR and not part of "the inventor design has shipped" definition-of-done.
+
+### Out of scope (per the brief + my reading)
+- New entity surfaces. Only the 7 named surfaces.
+- Backend SQL migrations beyond the one optional `RenderSpec.list.row_action` field. The bar runs through `/api/views/run` which already exists.
+- /projects redesign — t-paliad-149 stands.
+- Mobile-list-mode reimagining — separate workstream.
+- Multi-project selection — phase C, not v1.
+- Multi-column sort — when a user asks.
+- Internationalisation beyond DE + EN.
+
+---
+
+## 10. Files implementer will touch (Phase 1: /inbox)
+
+To make the scope concrete:
+
+**New:**
+- `frontend/src/components/FilterBar.tsx` — TSX wrapper with the host divs.
+- `frontend/src/client/filter-bar/index.ts` — `mountFilterBar` entry point.
+- `frontend/src/client/filter-bar/axes.ts` — per-axis render functions (one per `AxisKey`).
+- `frontend/src/client/filter-bar/url-codec.ts` — `encode/decode/diffWithBase`.
+- `frontend/src/client/filter-bar/save-modal.ts` — the "Speichern als Sicht" modal.
+- `frontend/src/client/filter-bar/types.ts` — `FilterBarOpts`, `AxisKey`.
+- `frontend/src/client/filter-bar/i18n.ts` — namespace registry helper.
+
+**Modified (Phase 1):**
+- `frontend/src/inbox.tsx` — replace tab row with `<div id="filter-bar">` + `<div id="filter-bar-results">`.
+- `frontend/src/client/inbox.ts` — shrink to `mountFilterBar(host, {baseFilter: inboxSystemView, axes: [...], onResult: renderListShape})`.
+- `internal/handlers/inbox.go` — add `?approval_role=` redirect from old `?tab=` for one release. (The actual rows continue to come from `/api/views/run` via the bar.)
+- `internal/services/render_spec.go` — add `RowAction` field + validator + `KnownRowActions = ["navigate", "complete_toggle", "approve", "none"]`.
+- `frontend/src/client/views/types.ts` — TS mirror of the new `RowAction` field.
+- `frontend/src/client/views/shape-list.ts` — honour `RowAction` (navigate is the existing default; `approve` mounts approve/reject buttons; `complete_toggle` mounts the checkbox).
+- `frontend/src/client/i18n.ts` + `i18n-keys.ts` — ~30 new keys under `views.bar.*`.
+- `frontend/src/styles/global.css` — bar layout + mobile rules. Reuses existing `.agenda-chip`, `.akten-multi-*`, `.frist-summary-card`, `.multi-anchor`/`.multi-panel`, `.events-view-btn` styles.
+
+**Tests (Phase 1):**
+- `internal/services/render_spec_test.go` — add cases for `RowAction` validator (8 cases: each enum value + invalid + omitted + …).
+- `frontend/src/client/filter-bar/url-codec.test.ts` — round-trip encode/decode for every `AxisKey`.
+- `internal/handlers/inbox_redirect_test.go` — old-tab → new-axis redirect.
+
+**Phase 2..5 file lists** are not enumerated here — each is a separate PR with its own surface refactor and follows the same shape (replace per-page chrome + URL sync, mount the bar, hand `onResult` to the existing shape components).
+
+---
+
+## 11. Recommended implementer
+
+**Pattern-fluent Sonnet coder** is the right fit. Substrate is well-trodden:
+- Custom Views client + render shapes already exist (t-paliad-144).
+- Multi-select listbox-panel already exists (`event-types.ts`).
+- Chip-row pattern exists on `/agenda`, `/projects`, `/events`.
+- Save modal pattern exists on `/views/new` (`views-editor.ts`).
+- URL-sync pattern exists on every system page.
+
+The first PR (Phase 1: /inbox + bar scaffolding + `RowAction` schema bump) is contained and reviewable in one window. Subsequent phases are smaller — they're "swap in the bar and delete page-local code".
+
+I am happy to be the coder if m wants minimum context-switch — riemann has the live model of every piece of this design. Equally happy to hand off to a fresh Sonnet coder with this doc as the brief; the doc is intended to be self-contained for that path.
+
+The head decides.
+
+---
+
+## 12. Phasing summary (no estimates, just order)
+
+1. /inbox migration + `<FilterBar>` scaffolding + `RowAction` schema bump.
+2. /agenda migration.
+3. /events migration (proof point — most complex filter today, biggest LoC delta).
+4. Dashboard inline bars (Agenda + Letzte Aktivität).
+5. /views/{slug} bar overlay + "Aktualisieren" affordance.
+
+Each phase is its own PR. Phases must merge in order; m's merge gate at every step.
+
+---
+
+## 13. Why this is worth an inventor
+
+m's last line in the brainstorm: *"worth an inventor?"*. Yes — and the reason is exactly what the design doc surfaces: the substrate already exists, the schema's right, the run endpoints are shipped, and 5 SystemViews are already declared. A coder coming in cold would either (a) not realise the substrate is there and reinvent it, or (b) realise and underestimate how much per-surface chrome can collapse into one bar. The inventor's job here was to read what's there, name the bar primitive, identify /events as the proof point, propose the one schema bump (`RowAction`) that makes /inbox shippable in Phase 1, and resist designing a layout-spec system that's already covered by `RenderSpec`.
+
+Stop. DESIGN READY FOR REVIEW.

docs/design-user-checklists-2026-05-20.md

@@ -0,0 +1,918 @@
+# User-authored checklists: authoring, sharing, admin-promotion
+
+**Task:** t-paliad-225 — Gitea m/paliad#61
+**Inventor:** dirac, 2026-05-20
+**Branch:** `mai/dirac/user-checklists`
+**Status:** DESIGN READY FOR REVIEW
+
+## 1. Problem statement
+
+Paliad ships a curated catalog of UPC / DE / EPA checklists today
+(`internal/checklists/templates.go`, 6 templates). Users instantiate them
+on Akten and check items off; per-instance state lives in
+`paliad.checklist_instances` and is gated by the parent project's
+team-based visibility.
+
+m wants three new capabilities (m 2026-05-20 14:14):
+
+1. **User-authored templates** — any non-`global_admin` can create a
+   checklist template they own (title, sections, items, references).
+2. **Sharing** — author shares with specific colleagues, an Office, a
+   Dezernat (partner-unit), a project team, or the whole firm.
+3. **Admin promotion to global** — `global_admin` promotes an authored
+   template into the firm-wide catalog so it appears alongside the
+   curated UPC/DE/EPA templates for every user.
+
+This design covers all three across three sequential slices.
+
+## 2. Premises verified live (load-bearing findings)
+
+The Gitea issue body says "Add `owner_id uuid NULL` to
+`paliad.checklists`". That table **does not exist**. Verifying against
+the live DB and the code corrected several premises:
+
+- **`paliad.checklists` does NOT exist as a DB table.** Templates today
+  are pure Go data in `internal/checklists/templates.go` (6 entries,
+  ~310 lines), served by `internal/handlers/checklists.go` via
+  `checklists.Summaries()` and `checklists.Find(slug)`. The DB has
+  `paliad.checklist_instances` (per-user state) and
+  `paliad.checklist_feedback` (a thumbs-up/down sink). That's it. The
+  design has to introduce `paliad.checklists` from scratch.
+
+- **`paliad.checklist_instances.template_slug` is `text` with no FK** —
+  validity is enforced in `ChecklistInstanceService.Create` against the
+  static Go registry. This is what lets the design keep the static
+  catalog as one source of truth and add the DB catalog as a parallel
+  source: instance creation just resolves the slug against the merged
+  view and snapshots the template body.
+
+- **Migration tracker live = 106; on-disk head = 111.** Five unapplied
+  on-disk migrations (107 caldav-binding-id, 108 mkcalendar-capability,
+  109 user_dashboard_layouts, 110 project_type_other, 111
+  project_admin_and_select — gauss's t-paliad-223 Slice A, m-locked
+  today). At inventor time the next free slot is **112**. The coder
+  MUST re-verify with `ls internal/db/migrations/ | tail` at shift
+  start — the slot can drift if other branches merge first.
+
+- **`paliad.effective_project_admin(_user_id, _project_id)` lands with
+  migration 111** (gauss, today). Mirrors `can_see_project`'s shape:
+  STABLE SECURITY DEFINER, ltree ancestor walk against `projects.path`,
+  branches on global_admin shortcut + project_teams responsibility =
+  'admin'. **Used by this design** to gate the "Make global" button (we
+  reuse the global_admin shortcut, not the project-admin branch — see
+  §4.4) and as the precedent for any new STABLE SECURITY DEFINER
+  predicates we add.
+
+- **`paliad.system_audit_log` (mig 102) is the org-scope audit sink.**
+  Columns: `event_type` (free-text), `actor_id`, `actor_email`,
+  `scope` ∈ {org, project, personal}, `scope_root uuid`,
+  `metadata jsonb`. RLS: self-read for the actor +
+  global_admin read-all. **Pattern to follow:** insert event row at
+  state transition (see `ExportService.WriteAuditRow` in
+  `internal/services/export_service.go:1120` for the canonical shape).
+
+- **`paliad.project_events`** is the project-timeline audit sink and is
+  already wired for checklist instance lifecycle events
+  (`checklist_created`, `_renamed`, `_unlinked`, `_linked`, `_reset`,
+  `_deleted`). We do NOT need to invent a new event_type for instance
+  events; we'll add a few `_snapshot_taken` / template-level events to
+  `system_audit_log` and keep instance events on `project_events`.
+
+- **`paliad.users.office`** is `text` (CHECK against the office key
+  list in `internal/offices/offices.go` — 8 keys: munich, duesseldorf,
+  hamburg, amsterdam, london, paris, milan, madrid). Multi-office users
+  have `additional_offices text[]`. Both are first-class columns; no
+  separate `offices` table.
+
+- **`paliad.partner_units`** (cols: id, name, lead_user_id, office,
+  timestamps) is the Dezernat / practice-group table. Membership lives
+  in `paliad.partner_unit_members`. Projects attach via
+  `paliad.project_partner_units` (with derivation flags). All three
+  are referenceable from a share recipient.
+
+- **`paliad.users.global_role`** is `text`; values include
+  `'global_admin'`. Used for the firm-wide promote/demote authority.
+
+- **`paliad.project_teams`** (mig 111 just added) carries
+  `responsibility` ∈ {admin, lead, member, observer, external}. We
+  reuse `can_see_project` (visibility) for share-to-project recipients,
+  NOT `effective_project_admin`. The semantic of "share with a project
+  team" is "anyone on the matter sees it", not "anyone who can edit
+  membership sees it".
+
+- **No precedent for entity-level sharing in paliad.** The personal-
+  sidecar tables (`user_views`, `user_dashboard_layouts`,
+  `user_pinned_projects`, `user_card_layouts`) are owner-only with no
+  share columns. Existing visibility predicates
+  (`paliad.can_see_project`) walk the project tree, not arbitrary
+  entities. This design introduces the first multi-axis share pattern
+  in the codebase (§3.2).
+
+## 3. Architecture: hybrid templates + share table
+
+### 3.1 Two template sources, one read layer
+
+**KEEP** the static Go template registry as the firm's curated catalog.
+It's version-controlled, code-reviewed, immutable at runtime, and the
+right substrate for legally-curated content (RoP citations, EPC rule
+references). Migrating those into DB rows would lose the git review
+trail for content that requires lawyer eyes.
+
+**ADD** `paliad.checklists` as the DB catalog for user-authored content.
+Same Template shape (slug, titles, regime, court, groups[], items[])
+but stored as JSONB so the schema doesn't have to chase content
+evolution.
+
+A `ChecklistCatalogService` unifies the two at read time:
+- `ListVisible(user)` → static templates ∪ DB rows the user can see
+- `Find(slug, user)` → static lookup first, then DB lookup with visibility check
+- Slug-uniqueness enforced **across both spaces** at write time (DB slugs
+  rejected if they collide with a static slug).
+
+Existing `/api/checklists` and `/api/checklists/{slug}` endpoints keep
+their JSON shape — they just delegate to the catalog service instead of
+the bare static registry.
+
+### 3.2 Multi-axis sharing — checklist-specific table, polymorphism deferred
+
+The task brief asks for a "modular / abstract" solution. I considered a
+polymorphic `paliad.entity_shares(target_kind, target_id, recipient_kind,
+recipient_*)` table that could later carry shares for views, dashboards,
+saved searches, project templates, etc.
+
+**Decision: keep it checklist-specific (`paliad.checklist_shares`) for
+v1.** Reasons:
+
+1. There is NO second entity in paliad that requests sharing today —
+   `user_views`, `user_dashboard_layouts`, `user_card_layouts`,
+   `user_pinned_projects` are all explicitly owner-only by design (see
+   migration comments). The "future reuse" is hypothetical.
+2. Polymorphic FKs forfeit ON DELETE CASCADE — every recipient kind
+   needs its own deletion trigger. That complexity is real, the
+   reusability gain is not.
+3. The CORRECT abstraction emerges by extracting *after* the second use
+   case shows up. Right now we don't know whether dashboards want the
+   same recipient axes (user / office / partner-unit / project) or a
+   different set (e.g. dashboards probably want "everyone on a project"
+   not "the whole firm").
+
+The design IS modular in the sense that the recipient resolution logic
+(below) is centralized in one SQL predicate (§4.3) which a future
+polymorphic refactor can lift verbatim.
+
+If the second entity asks for sharing within ~3 months, refactor to
+`paliad.entity_shares` as a single-mig follow-up. Until then,
+`paliad.checklist_shares` keeps the schema honest.
+
+### 3.3 Visibility states
+
+`paliad.checklists.visibility text` (CHECK enum):
+
+| state     | who sees                                           | who edits           |
+|-----------|----------------------------------------------------|---------------------|
+| `private` | owner only                                         | owner               |
+| `shared`  | owner + explicit recipients in checklist_shares    | owner               |
+| `firm`    | owner + every authenticated paliad user            | owner               |
+| `global`  | owner + every authenticated paliad user + catalog  | owner + global_admin|
+
+`firm` vs `global` distinction:
+- `firm` = author self-published. Author can flip back to private/shared
+  any time. Does NOT appear in the main `/checklists` Vorlagen tab; only
+  in the new "Geteilte Vorlagen" / "Shared by colleagues" surface.
+- `global` = admin-promoted into the firm catalog. Appears in the main
+  Vorlagen tab alongside the static templates. Author retains edit
+  authority by default; only `global_admin` can demote.
+
+Demotion target: `global → firm` (preserves visibility for users who
+already started instances). Author can subsequently narrow further.
+
+### 3.4 Template snapshot on instance create
+
+m's brief calls this out as a design decision: when an author edits a
+template, do existing instances pick up the changes (propagate) or stay
+on the version they were created from (snapshot)?
+
+**Pick: snapshot.** Inventor pick (R). Rationale:
+
+1. **Data integrity.** Instances are working artefacts. A user halfway
+   through a Klageerwiderung instance shouldn't have items disappear or
+   reorder under them because the author edited the template.
+2. **Audit story.** The completed instance shows exactly what the
+   author saw when they started. Reconstruction without git-blame on
+   the template.
+3. **Visibility narrowing safe by construction.** If author unshares
+   from a colleague who already has an instance, the instance survives
+   because the snapshot is local.
+4. Cost is trivial: a typical template is <2 KB JSONB; instances rarely
+   exceed a few per user per template. Even 10× the row size of today
+   is fine.
+
+Schema cost: one nullable `template_snapshot jsonb` column on
+`paliad.checklist_instances`. Backfilled lazily — existing instances
+keep `NULL`, service falls back to looking the slug up in the catalog;
+new instances always get a snapshot. Slice C can backfill the column
+for already-existing rows via a one-off `UPDATE` if we want strict
+consistency.
+
+## 4. Schema (migration 112 — verify slot at coder shift)
+
+Single migration file `internal/db/migrations/112_user_checklists.up.sql`
++ matching `.down.sql`. Idempotent throughout
+(`CREATE TABLE IF NOT EXISTS`, `DO $$ … EXCEPTION` guards).
+
+> Slot caveat: at design time, latest disk = 111, live tracker = 106
+> (mig 107-111 pending deploy). Coder MUST re-verify
+> `ls internal/db/migrations/ | tail` at shift start. If a higher
+> number lands first (e.g. boltzmann's gap-tolerant runner ships as
+> 112), bump to the next free slot.
+
+### 4.1 `paliad.checklists` — authored template catalog
+
+```sql
+CREATE TABLE paliad.checklists (
+    id           uuid PRIMARY KEY DEFAULT gen_random_uuid(),
+    slug         text NOT NULL UNIQUE,
+    -- Authoring metadata
+    owner_id     uuid NOT NULL REFERENCES paliad.users(id) ON DELETE CASCADE,
+    title        text NOT NULL,
+    description  text NOT NULL DEFAULT '',
+    regime       text NOT NULL DEFAULT 'OTHER',   -- UPC | DE | EPA | OTHER
+    court        text NOT NULL DEFAULT '',
+    reference    text NOT NULL DEFAULT '',
+    deadline     text NOT NULL DEFAULT '',
+    lang         text NOT NULL DEFAULT 'de',      -- 'de' | 'en' — author's primary language
+    -- Body
+    body         jsonb NOT NULL,                  -- { groups: [{ title, items: [{ label, note, rule }] }] }
+    -- Lifecycle
+    visibility   text NOT NULL DEFAULT 'private'
+                  CHECK (visibility IN ('private', 'shared', 'firm', 'global')),
+    promoted_at  timestamptz,                     -- set on transition to 'global'
+    promoted_by  uuid REFERENCES paliad.users(id) ON DELETE SET NULL,
+    -- Timestamps
+    created_at   timestamptz NOT NULL DEFAULT now(),
+    updated_at   timestamptz NOT NULL DEFAULT now()
+);
+
+CREATE INDEX checklists_owner_idx      ON paliad.checklists (owner_id);
+CREATE INDEX checklists_visibility_idx ON paliad.checklists (visibility) WHERE visibility IN ('firm', 'global');
+CREATE INDEX checklists_regime_idx     ON paliad.checklists (regime);
+```
+
+**Slug-collision safety net:** application layer validates that the
+chosen slug doesn't collide with a static template slug. The static
+list is loaded into a `map[string]bool` at boot. New authored slugs
+auto-prefixed with `u-` so collisions with static slugs are structurally
+unlikely (`u-my-strategy-2026` vs `upc-statement-of-claim`).
+
+### 4.2 `paliad.checklist_shares` — explicit grants
+
+```sql
+CREATE TABLE paliad.checklist_shares (
+    id                       uuid PRIMARY KEY DEFAULT gen_random_uuid(),
+    checklist_id             uuid NOT NULL REFERENCES paliad.checklists(id) ON DELETE CASCADE,
+    recipient_kind           text NOT NULL CHECK (recipient_kind IN ('user', 'office', 'partner_unit', 'project')),
+    recipient_user_id        uuid REFERENCES paliad.users(id) ON DELETE CASCADE,
+    recipient_office         text,
+    recipient_partner_unit_id uuid REFERENCES paliad.partner_units(id) ON DELETE CASCADE,
+    recipient_project_id     uuid REFERENCES paliad.projects(id) ON DELETE CASCADE,
+    granted_by               uuid NOT NULL REFERENCES paliad.users(id) ON DELETE SET NULL,
+    granted_at               timestamptz NOT NULL DEFAULT now(),
+
+    -- XOR check: exactly one recipient_* column populated per kind
+    CONSTRAINT checklist_shares_recipient_xor CHECK (
+        (recipient_kind = 'user'         AND recipient_user_id        IS NOT NULL AND recipient_office IS NULL AND recipient_partner_unit_id IS NULL AND recipient_project_id IS NULL)
+     OR (recipient_kind = 'office'       AND recipient_office         IS NOT NULL AND recipient_user_id IS NULL AND recipient_partner_unit_id IS NULL AND recipient_project_id IS NULL)
+     OR (recipient_kind = 'partner_unit' AND recipient_partner_unit_id IS NOT NULL AND recipient_user_id IS NULL AND recipient_office IS NULL AND recipient_project_id IS NULL)
+     OR (recipient_kind = 'project'      AND recipient_project_id     IS NOT NULL AND recipient_user_id IS NULL AND recipient_office IS NULL AND recipient_partner_unit_id IS NULL)
+    )
+);
+
+-- Avoid duplicates per recipient
+CREATE UNIQUE INDEX checklist_shares_user_uniq         ON paliad.checklist_shares (checklist_id, recipient_user_id)         WHERE recipient_kind = 'user';
+CREATE UNIQUE INDEX checklist_shares_office_uniq       ON paliad.checklist_shares (checklist_id, recipient_office)          WHERE recipient_kind = 'office';
+CREATE UNIQUE INDEX checklist_shares_partner_unit_uniq ON paliad.checklist_shares (checklist_id, recipient_partner_unit_id) WHERE recipient_kind = 'partner_unit';
+CREATE UNIQUE INDEX checklist_shares_project_uniq      ON paliad.checklist_shares (checklist_id, recipient_project_id)      WHERE recipient_kind = 'project';
+
+-- Hot-path index for the visibility predicate
+CREATE INDEX checklist_shares_lookup_idx ON paliad.checklist_shares (checklist_id);
+```
+
+### 4.3 `paliad.can_see_checklist(_user_id, _checklist_id)` predicate
+
+```sql
+CREATE OR REPLACE FUNCTION paliad.can_see_checklist(_user_id uuid, _checklist_id uuid)
+RETURNS boolean
+LANGUAGE sql STABLE SECURITY DEFINER
+SET search_path TO 'paliad', 'public'
+AS $$
+    -- Owner can always see
+    SELECT EXISTS (
+        SELECT 1 FROM paliad.checklists c
+         WHERE c.id = _checklist_id
+           AND c.owner_id = _user_id
+    )
+    -- 'firm' / 'global' visible to all authenticated users
+    OR EXISTS (
+        SELECT 1 FROM paliad.checklists c
+         WHERE c.id = _checklist_id
+           AND c.visibility IN ('firm', 'global')
+    )
+    -- Explicit share: user
+    OR EXISTS (
+        SELECT 1 FROM paliad.checklist_shares s
+         WHERE s.checklist_id = _checklist_id
+           AND s.recipient_kind = 'user'
+           AND s.recipient_user_id = _user_id
+    )
+    -- Explicit share: office (matches user.office OR additional_offices)
+    OR EXISTS (
+        SELECT 1
+          FROM paliad.checklist_shares s
+          JOIN paliad.users u ON u.id = _user_id
+         WHERE s.checklist_id = _checklist_id
+           AND s.recipient_kind = 'office'
+           AND (s.recipient_office = u.office
+                OR s.recipient_office = ANY(u.additional_offices))
+    )
+    -- Explicit share: partner_unit (caller is a member)
+    OR EXISTS (
+        SELECT 1
+          FROM paliad.checklist_shares s
+          JOIN paliad.partner_unit_members pum
+            ON pum.partner_unit_id = s.recipient_partner_unit_id
+           AND pum.user_id = _user_id
+         WHERE s.checklist_id = _checklist_id
+           AND s.recipient_kind = 'partner_unit'
+    )
+    -- Explicit share: project (caller can see the project via existing predicate)
+    OR EXISTS (
+        SELECT 1 FROM paliad.checklist_shares s
+         WHERE s.checklist_id = _checklist_id
+           AND s.recipient_kind = 'project'
+           AND paliad.can_see_project(s.recipient_project_id)  -- reuses ltree walk
+    );
+$$;
+```
+
+> Note on `can_see_project` self-reference: that function reads
+> `auth.uid()` internally — when called from inside another SECURITY
+> DEFINER body it picks up the caller's uid via search_path inheritance
+> (same pattern as `effective_project_admin` reuse in mig 111).
+
+### 4.4 RLS on `paliad.checklists`
+
+```sql
+ALTER TABLE paliad.checklists ENABLE ROW LEVEL SECURITY;
+
+-- SELECT: owner OR visible via can_see_checklist
+CREATE POLICY checklists_select
+    ON paliad.checklists FOR SELECT TO authenticated
+    USING (paliad.can_see_checklist(auth.uid(), id));
+
+-- INSERT: caller can only create templates owned by themselves
+CREATE POLICY checklists_insert
+    ON paliad.checklists FOR INSERT TO authenticated
+    WITH CHECK (owner_id = auth.uid());
+
+-- UPDATE: owner always; global_admin if visibility='global' (for demotion)
+CREATE POLICY checklists_update
+    ON paliad.checklists FOR UPDATE TO authenticated
+    USING (
+        owner_id = auth.uid()
+        OR EXISTS (
+            SELECT 1 FROM paliad.users u
+             WHERE u.id = auth.uid() AND u.global_role = 'global_admin'
+        )
+    )
+    WITH CHECK (
+        owner_id = auth.uid()
+        OR EXISTS (
+            SELECT 1 FROM paliad.users u
+             WHERE u.id = auth.uid() AND u.global_role = 'global_admin'
+        )
+    );
+
+-- DELETE: owner OR global_admin
+CREATE POLICY checklists_delete
+    ON paliad.checklists FOR DELETE TO authenticated
+    USING (
+        owner_id = auth.uid()
+        OR EXISTS (
+            SELECT 1 FROM paliad.users u
+             WHERE u.id = auth.uid() AND u.global_role = 'global_admin'
+        )
+    );
+```
+
+### 4.5 RLS on `paliad.checklist_shares`
+
+```sql
+ALTER TABLE paliad.checklist_shares ENABLE ROW LEVEL SECURITY;
+
+-- SELECT: caller can see if they own the checklist OR they are the recipient OR global_admin
+CREATE POLICY checklist_shares_select
+    ON paliad.checklist_shares FOR SELECT TO authenticated
+    USING (
+        EXISTS (SELECT 1 FROM paliad.checklists c WHERE c.id = checklist_id AND c.owner_id = auth.uid())
+        OR (recipient_kind = 'user' AND recipient_user_id = auth.uid())
+        OR EXISTS (SELECT 1 FROM paliad.users u WHERE u.id = auth.uid() AND u.global_role = 'global_admin')
+    );
+
+-- INSERT: only the checklist owner can grant
+CREATE POLICY checklist_shares_insert
+    ON paliad.checklist_shares FOR INSERT TO authenticated
+    WITH CHECK (
+        EXISTS (SELECT 1 FROM paliad.checklists c WHERE c.id = checklist_id AND c.owner_id = auth.uid())
+        AND granted_by = auth.uid()
+    );
+
+-- DELETE: owner OR global_admin (no UPDATE policy — shares are immutable; revoke = delete + reinsert)
+CREATE POLICY checklist_shares_delete
+    ON paliad.checklist_shares FOR DELETE TO authenticated
+    USING (
+        EXISTS (SELECT 1 FROM paliad.checklists c WHERE c.id = checklist_id AND c.owner_id = auth.uid())
+        OR EXISTS (SELECT 1 FROM paliad.users u WHERE u.id = auth.uid() AND u.global_role = 'global_admin')
+    );
+```
+
+### 4.6 `paliad.checklist_instances.template_snapshot jsonb`
+
+```sql
+-- Idempotent — column NULL on existing rows; service handles fallback to catalog lookup.
+ALTER TABLE paliad.checklist_instances
+    ADD COLUMN IF NOT EXISTS template_snapshot jsonb;
+```
+
+Existing RLS on `checklist_instances` untouched.
+
+## 5. Service layer
+
+### 5.1 `internal/services/checklist_catalog_service.go` (new)
+
+Unified read facade over static + DB templates.
+
+```go
+type ChecklistCatalogService struct {
+    db *sqlx.DB
+}
+
+type CatalogEntry struct {
+    Slug          string          // matches checklists.Template.Slug or paliad.checklists.slug
+    Origin        string          // "static" | "authored"
+    OwnerID       *uuid.UUID      // nil for static
+    OwnerName     string          // empty for static
+    Visibility    string          // "static" | "private" | "shared" | "firm" | "global"
+    Template      checklists.Template
+}
+
+// ListVisible returns every catalog entry the caller can see.
+// Static entries are always returned. DB entries pass through RLS.
+func (s *ChecklistCatalogService) ListVisible(ctx context.Context, userID uuid.UUID) ([]CatalogEntry, error)
+
+// Find returns one entry by slug (static lookup first, then DB).
+func (s *ChecklistCatalogService) Find(ctx context.Context, userID uuid.UUID, slug string) (*CatalogEntry, error)
+
+// SnapshotBody returns the JSONB body for a slug — used at instance creation to capture the template state.
+func (s *ChecklistCatalogService) SnapshotBody(ctx context.Context, userID uuid.UUID, slug string) (json.RawMessage, error)
+```
+
+### 5.2 `internal/services/checklist_template_service.go` (new — Slice A)
+
+CRUD on `paliad.checklists`.
+
+```go
+type ChecklistTemplateService struct {
+    db    *sqlx.DB
+    users *UserService
+}
+
+type CreateTemplateInput struct {
+    Title       string
+    Description string
+    Regime      string
+    Court       string
+    Reference   string
+    Deadline    string
+    Lang        string
+    Body        checklists.Template   // unmarshalled to body jsonb minus slug/titles/etc
+}
+
+func (s *ChecklistTemplateService) Create(ctx, userID, input) (*Template, error)
+func (s *ChecklistTemplateService) Update(ctx, userID, slug, input) (*Template, error)
+func (s *ChecklistTemplateService) Delete(ctx, userID, slug) error
+func (s *ChecklistTemplateService) SetVisibility(ctx, userID, slug, visibility) error  // private/firm only
+func (s *ChecklistTemplateService) ListOwnedBy(ctx, userID) ([]Template, error)
+```
+
+Slug generation: lowercase, alphanumeric+hyphen, `u-` prefix, unique
+suffix (collision retry up to 3x). Validator enforces
+`^u-[a-z0-9][a-z0-9-]{2,62}$`. Reserved slugs from
+`internal/checklists/checklists.go` Templates rejected at write time.
+
+### 5.3 `internal/services/checklist_share_service.go` (new — Slice B)
+
+```go
+type ChecklistShareService struct { db *sqlx.DB }
+
+type ShareGrantInput struct {
+    RecipientKind string
+    UserID        *uuid.UUID
+    Office        string
+    PartnerUnitID *uuid.UUID
+    ProjectID     *uuid.UUID
+}
+
+func (s *ChecklistShareService) Grant(ctx, callerID, checklistID, input) (*Share, error)
+func (s *ChecklistShareService) Revoke(ctx, callerID, shareID) error
+func (s *ChecklistShareService) ListGrants(ctx, callerID, checklistID) ([]Share, error)
+```
+
+### 5.4 `internal/services/checklist_promotion_service.go` (new — Slice B)
+
+`global_admin`-only operations.
+
+```go
+type ChecklistPromotionService struct { db *sqlx.DB, audit *SystemAuditLogService }
+
+func (s *ChecklistPromotionService) Promote(ctx, callerID, checklistID) error
+func (s *ChecklistPromotionService) Demote(ctx, callerID, checklistID, target /* 'firm' | 'private' */) error
+```
+
+Promote: assert caller.global_role = 'global_admin' → UPDATE visibility =
+'global', promoted_at = now(), promoted_by = caller → audit row
+`event_type='checklist.promoted_global'`.
+
+Demote: assert caller is global_admin → UPDATE visibility = target
+(default 'firm') → audit row `event_type='checklist.demoted'`.
+
+### 5.5 Wire instance create to take snapshot
+
+`ChecklistInstanceService.Create` extends to capture
+`template_snapshot` at insert time via
+`catalog.SnapshotBody(ctx, userID, slug)`. Existing instances unchanged
+(NULL snapshot, fallback path in read layer).
+
+### 5.6 Endpoints
+
+| Method | Path | Slice | Purpose |
+|--------|------|-------|---------|
+| `GET`    | `/api/checklists`                       | (existing)| Merged catalog list (static + visible DB) |
+| `GET`    | `/api/checklists/{slug}`                | (existing)| Single template (static or DB) |
+| `POST`   | `/api/checklists/templates`             | A | Create authored template |
+| `GET`    | `/api/checklists/templates/mine`        | A | List own authored templates |
+| `PATCH`  | `/api/checklists/templates/{slug}`      | A | Edit authored template |
+| `DELETE` | `/api/checklists/templates/{slug}`      | A | Delete authored template |
+| `PATCH`  | `/api/checklists/templates/{slug}/visibility` | A | Toggle private/firm |
+| `GET`    | `/api/checklists/templates/{slug}/shares`     | B | List grants |
+| `POST`   | `/api/checklists/templates/{slug}/shares`     | B | Grant share |
+| `DELETE` | `/api/checklists/shares/{id}`           | B | Revoke share |
+| `POST`   | `/api/admin/checklists/{slug}/promote`  | B | Admin promote to global |
+| `POST`   | `/api/admin/checklists/{slug}/demote`   | B | Admin demote |
+| `GET`    | `/api/checklists/gallery`               | C | Browse all firm + global templates |
+
+## 6. Instance snapshot lifecycle
+
+**On Create (`ChecklistInstanceService.Create`):**
+1. Resolve slug via `catalog.Find(userID, slug)` — enforces visibility.
+2. `snapshot = catalog.SnapshotBody(userID, slug)` — captures the
+   template body (groups + items) at this moment, as JSONB.
+3. Insert into `checklist_instances` with
+   `template_snapshot = snapshot`, `template_slug = slug`,
+   `state = '{}'::jsonb`.
+
+**On Read (`ChecklistInstanceService.GetByID`):**
+- Return the instance with `template_snapshot` if non-null.
+- If NULL (legacy row created before mig 112), fall back to
+  `catalog.Find(slug)`. Logged at INFO; not a fatal path.
+
+**On Template Edit (Slice A):**
+- Owner edits template via PATCH → DB row mutated → `checklists.updated_at`
+  bumped → no propagation. Existing instances continue rendering their
+  snapshot. New instances pick up the edit.
+- Audit row `event_type='checklist.edited'`,
+  `metadata={ checklist_id, slug, changes:[...] }`.
+
+**On Template Delete:**
+- DB row deleted. Instances that snapshotted survive (snapshot is
+  local). Instances that DIDN'T snapshot (NULL) gracefully degrade —
+  service detects "template not found in catalog" and returns the
+  instance with a sentinel "template withdrawn" body (renders a small
+  banner client-side; checkboxes still work because `state` is the
+  source of truth, not the template).
+
+**On Visibility Narrow (firm → shared → private):**
+- Existing instances unaffected (snapshot is local; visibility check is
+  on the template, not instance).
+- New instance attempts fail with `ErrNotVisible` (the user can no
+  longer see the template to instantiate it).
+
+## 7. Frontend (concise sketch — coder owns the detail)
+
+### 7.1 `/checklists` (existing page) — Slice A adds "Meine Vorlagen"
+
+Add a third tab between "Vorlagen" and "Vorhandene Instanzen":
+
+```
+[Vorlagen] [Meine Vorlagen] [Vorhandene Instanzen]
+```
+
+- **Vorlagen** (existing): static catalog + global-promoted DB
+  templates, grouped by Regime, filter pills (UPC/DE/EPA).
+- **Meine Vorlagen** (NEW): caller's own authored templates + a "Neue
+  Vorlage" CTA. Each card shows title, description, visibility chip,
+  Aktions-Buttons (Bearbeiten / Teilen / Löschen).
+- **Vorhandene Instanzen** (existing): unchanged behaviour; rows now
+  optionally render an "📌 Snapshot" badge when `template_snapshot` is
+  non-null (Slice A backfill marker).
+
+Slice C adds a fourth tab: **Geteilte Vorlagen** (firm-level shared
+templates not yet promoted — discovery surface).
+
+### 7.2 `/checklists/new` (NEW — Slice A)
+
+Authoring wizard. Three steps:
+1. Metadata — title, description, regime (UPC/DE/EPA/OTHER), court,
+   reference, deadline.
+2. Sections + items — repeating editor (group title → items[] of
+   {label, note, rule}).
+3. Visibility — radio: privat / firm-weit. (Sharing flow comes in
+   Slice B.)
+
+Save → POST `/api/checklists/templates` → redirect to
+`/checklists/{slug}` detail.
+
+### 7.3 `/checklists/{slug}/edit` (NEW — Slice A)
+
+Same wizard, prefilled. Owner-only (404 otherwise).
+
+### 7.4 `/checklists/{slug}` detail page
+
+Existing detail page renders the template (static OR authored).
+Additions:
+- Owner-only "Bearbeiten" / "Löschen" / "Teilen" buttons in the header.
+- `global_admin`-only "Als Firmen-Vorlage hinterlegen" / "Aus Katalog
+  entfernen" button (Slice B).
+- Provenance line under the title: "Erstellt von <author> · <date>"
+  (only for DB templates).
+
+### 7.5 Share modal (Slice B)
+
+Triggered by "Teilen" on owner's detail page. Four pickers stacked:
+- Kollegen (user-picker, multi-select)
+- Office (chip-select from `offices.All`)
+- Dezernat (chip-select from `partner_units`)
+- Projekt (autocomplete from owner-visible projects)
+
+Footer: "Visibility" radio (privat / geteilt / firm-weit). Picking
+"firm-weit" greys out the picker (firm-weit doesn't need grants).
+
+Apply → POST grants individually → audit emits one
+`event_type='checklist.shared'` per grant with
+`metadata={ recipient_kind, recipient_id, checklist_id }`.
+
+### 7.6 i18n keys
+
+~28 new keys (DE+EN) under `checklisten.authoring.*`,
+`checklisten.share.*`, `checklisten.promote.*`. Naming convention
+matches existing `checklisten.tab.*` / `checklisten.instances.*`.
+
+## 8. Audit events
+
+Org-scope (`paliad.system_audit_log` via a small new helper
+`SystemAuditLogService.WriteChecklistEvent`):
+
+| event_type                       | actor       | metadata keys                                      |
+|----------------------------------|-------------|----------------------------------------------------|
+| `checklist.authored`             | owner       | checklist_id, slug, visibility                     |
+| `checklist.edited`               | owner       | checklist_id, slug, changed_fields[]               |
+| `checklist.visibility_changed`   | owner       | checklist_id, slug, from, to                       |
+| `checklist.shared`               | owner       | checklist_id, slug, recipient_kind, recipient_id   |
+| `checklist.unshared`             | owner       | checklist_id, slug, recipient_kind, recipient_id   |
+| `checklist.promoted_global`      | global_admin| checklist_id, slug, owner_id                       |
+| `checklist.demoted`              | global_admin| checklist_id, slug, target_visibility              |
+| `checklist.deleted`              | owner OR ga | checklist_id, slug, was_visibility                 |
+
+Project-scope (`paliad.project_events` — existing helper
+`insertProjectEventWithMeta`): existing checklist-instance events
+unchanged. NO new project_events types for templates — templates are
+not project-scoped.
+
+`AuditService.ListEntries` already reads from `system_audit_log` via
+the UNION ALL branch added in t-paliad-214 — no changes needed there;
+new event_types surface automatically in the audit log UI.
+
+## 9. Slice plan
+
+### Slice A — Foundation (~700 LoC)
+
+**Schema:** mig 112 §4.1 (`paliad.checklists`) + §4.3 predicate + §4.4
+RLS + §4.6 instance snapshot column. **Skip** §4.2 / §4.5 in Slice A —
+no share table yet; visibility limited to private/firm.
+
+**Service:** `ChecklistCatalogService` (unified read), `ChecklistTemplateService`
+(CRUD), `ChecklistInstanceService.Create` snapshot wiring,
+`SystemAuditLogService.WriteChecklistEvent` helper.
+
+**Endpoints:** `/api/checklists` (delegate to catalog), `POST/PATCH/DELETE
+/api/checklists/templates`, `PATCH /api/checklists/templates/{slug}/visibility`.
+
+**Frontend:** "Meine Vorlagen" tab on `/checklists`, `/checklists/new`,
+`/checklists/{slug}/edit`, owner controls on detail page.
+
+**Test pass:** unit tests for slug validation, snapshot capture,
+visibility predicate (without share rows), audit emit, fallback to
+catalog when snapshot NULL.
+
+**No share, no admin promote, no gallery.** Ships immediately useful
+for solo authoring + firm-wide publishing.
+
+### Slice B — Sharing + Promotion (~600 LoC)
+
+**Schema:** mig 113 — `paliad.checklist_shares` (§4.2) + revised RLS
+(§4.5) + extend visibility CHECK to include 'shared' if Slice A used a
+sub-enum (Slice A schema already includes 'shared' as valid value —
+just no grants point at it yet).
+
+**Service:** `ChecklistShareService`, `ChecklistPromotionService`.
+
+**Endpoints:** shares endpoints + admin promote/demote.
+
+**Frontend:** Share modal, "Make global" admin button on detail page,
+share-grant chip list on detail page (owner-only).
+
+**Audit:** new event_types (shared, unshared, promoted_global, demoted).
+
+### Slice C — Discoverability + UX polish (~400 LoC)
+
+**Gallery page** `/checklists/gallery`: browses every template the user
+can see that's NOT their own, grouped by Regime / Author / Recency.
+Filter pills. "Diese Vorlage verwenden" → instantiates with snapshot.
+
+**Backfill** existing `checklist_instances` with `template_snapshot`
+via a one-off migration (mig 114) — pure data move, no schema change.
+After backfill, the catalog-fallback path can be removed (deferred to
+Slice D / cleanup).
+
+**Optional**:
+- "Vorlage kopieren" action — clone an existing template (static OR
+  authored) into the caller's "Meine Vorlagen" for personal adaptation.
+- Per-template instance counter ("12 Kollegen haben diese Vorlage
+  benutzt") — surfaced from `checklist_instances` group-by.
+
+## 10. Trade-offs flagged
+
+1. **Hybrid catalog (static + DB).** Two sources of truth means two
+   slug spaces to merge. Mitigated by `u-` prefix on authored slugs +
+   reserved-list rejection. Refactoring all static templates into DB
+   loses the git review trail; the hybrid is the right cost.
+2. **Polymorphism deferred.** A future second sharable entity will need
+   to either copy the `checklist_shares` pattern (cheap but duplicative)
+   or refactor to `entity_shares` (one mig). The refactor is small;
+   premature abstraction now would pay complexity for no current
+   benefit.
+3. **Snapshot semantics may surprise.** A user who edits their template
+   expecting downstream instances to update will be confused.
+   Mitigations: (a) UI banner on edit ("Bearbeitungen wirken nur auf
+   neue Instanzen"); (b) "Neu instantiieren" affordance on the instance
+   detail page that re-snapshots from the current template (preserves
+   the user's checkbox state to the extent items still match).
+4. **Office membership is set-membership, not hierarchy.** Sharing to
+   "munich" reaches every user with `office='munich'` OR
+   `'munich' = ANY(additional_offices)`. There's no concept of "Munich
+   plus its sub-teams" because offices don't nest in paliad. Fine.
+5. **Partner-unit membership join is N+1 on the predicate.** Each
+   visibility check touches `partner_unit_members` if any partner-unit
+   share exists. Indexes on `partner_unit_members(user_id, partner_unit_id)`
+   already exist (per mig 027 lineage); the join is single-row.
+6. **Share-to-project recipient resolution uses
+   `can_see_project(s.recipient_project_id)`.** That predicate reads
+   `auth.uid()` from the session, so it works correctly inside our
+   SECURITY DEFINER body. Confirmed by reading `can_see_project`'s body
+   in `paliad.can_see_project` source — same pattern that
+   `effective_project_admin` uses in mig 111.
+7. **`global_admin` UPDATE RLS on `paliad.checklists` is full-row.**
+   Means a global_admin can edit content of any user's template, not
+   just visibility. This is intentional for catalog hygiene
+   (correcting typos, removing inflammatory content) but should be used
+   sparingly and audited. The audit log captures every
+   global_admin-attributed edit via `checklist.edited` with actor_id.
+8. **Instance snapshot fallback path lives indefinitely.** Existing
+   pre-mig-112 instances stay NULL until Slice C backfills. The
+   fallback code in `ChecklistInstanceService.GetByID` is ~10 LoC and
+   no hot-path concern — but it's "dead code" once the backfill runs.
+   Acceptable until Slice C.
+9. **Cascade on owner deletion.** If an authored template's owner is
+   removed (`paliad.users.id` cascades), the template is wiped along
+   with all its shares. Existing instances survive via snapshot. The
+   alternative (transfer ownership to global_admin on user-delete) is
+   more polite but introduces governance questions ("which admin?")
+   that aren't worth Slice A complexity. Flag for Slice C if it bites.
+10. **Slug uniqueness across origins enforced application-side.**
+    The static catalog is in-memory at boot. If a deploy adds a static
+    slug that collides with an existing DB slug, the deploy boots
+    cleanly but the DB row becomes unreachable via the catalog read
+    layer (static wins on slug lookup). Mitigation: a boot-time
+    integrity check in `cmd/server/main.go` logs WARN if collision
+    detected. Owner can rename their template manually via the edit UI.
+
+## 11. m's decisions ledger (all defaulted to (R) per task brief)
+
+Per task brief "NO AskUserQuestion. Defaults to (R). Escalate to head if
+material." I have not escalated; all picks below default to (R).
+
+| # | Question                                                | (R) pick                                  |
+|---|---------------------------------------------------------|-------------------------------------------|
+| 1 | Storage model for authored templates                    | Hybrid: keep static catalog + new `paliad.checklists` DB table |
+| 2 | Instance lifecycle on template edit                     | **Snapshot** at instance create (NOT propagate) |
+| 3 | Visibility enum values                                  | `private`, `shared`, `firm`, `global`     |
+| 4 | Share recipients                                        | user, office, partner_unit, project (4 axes) |
+| 5 | Share-to-project resolution                             | Reuse `can_see_project` (visibility, not just team rows) |
+| 6 | Promotion authority                                     | `global_admin` only (no per-project admin promote in v1) |
+| 7 | Demotion target                                         | `global → firm` (preserves visibility for in-flight instances) |
+| 8 | Slug strategy                                           | `u-` prefix on authored, application-side collision check vs static |
+| 9 | Polymorphic share table (`entity_shares`) vs scoped     | **Scoped (`checklist_shares`).** Refactor to polymorphic *after* second sharable entity appears |
+| 10| Authoring i18n                                          | Author picks single language (DE or EN) per template via `lang` column; verbatim render |
+| 11| Audit sink for template lifecycle                       | `paliad.system_audit_log` (org-scope); instance events stay on `paliad.project_events` |
+| 12| Slice ordering                                          | A (foundation) → B (share + promote) → C (gallery + backfill) |
+
+Material escalation list: empty. If m disagrees with any of the above,
+amend §11 in the next inventor shift; the schema is designed to be
+forward-compatible with most reversals (e.g. flipping snapshot →
+propagate is a service-layer change, not a schema change).
+
+## 12. Acceptance criteria — Slice A
+
+1. **Migration 112 applies cleanly on a fresh DB** and is idempotent
+   on re-apply (verified via `BEGIN…ROLLBACK` dry-run against the live
+   `paliad` schema).
+2. **`/api/checklists` returns merged catalog** — static templates
+   plus DB templates the caller can see (visibility ∈ {firm, global}
+   OR owner = caller).
+3. **POST `/api/checklists/templates`** creates a row, returns the
+   created template with auto-generated `u-…` slug, emits
+   `checklist.authored` audit row.
+4. **PATCH `/api/checklists/templates/{slug}`** updates owner-only
+   fields, rejects 403 from non-owner non-admin, emits
+   `checklist.edited`.
+5. **PATCH `/api/checklists/templates/{slug}/visibility`** toggles
+   private↔firm; rejects `shared` and `global` in Slice A (those land
+   in Slice B); emits `checklist.visibility_changed`.
+6. **DELETE `/api/checklists/templates/{slug}`** removes the row;
+   existing instances survive via snapshot.
+7. **Instance create snapshots the template body** —
+   `template_snapshot` non-null on every new instance row.
+8. **Legacy instances (NULL snapshot) still render** via catalog
+   fallback (covered by a regression test).
+9. **"Meine Vorlagen" tab** lists owner's templates; "Neue Vorlage"
+   CTA navigates to `/checklists/new`; wizard saves successfully.
+10. **`go build ./... && go vet ./... && go test ./internal/...`
+    clean.** `bun run build` clean (i18n key count incremented by ~20).
+11. **Live smoke**: tester@hlc.de can create + edit + delete a private
+    template; setting visibility to `firm` makes it visible to a second
+    tester account; deleting the template doesn't break existing
+    instances.
+
+## 13. Recommended implementer
+
+Pattern-fluent **Sonnet coder**, NOT cronus (per project memory
+directive 2026-05-06). Substrate is well-trodden:
+
+- Migration shape mirrors mig 111 (gauss) for the predicate function +
+  policy replacement pattern.
+- Service shape mirrors `ChecklistInstanceService` for CRUD + audit
+  emit + visibility check.
+- Endpoint shape mirrors `internal/handlers/checklist_instances.go`.
+- Frontend tab pattern mirrors the existing
+  `entity-tabs` / `entity-tab-panel` substrate in `checklists.tsx`.
+
+Novel pieces:
+- Catalog merge layer (~80 LoC) — the only logic the coder needs to
+  prototype before committing to the full slice. Pure function; easy
+  to unit-test.
+- Share predicate (Slice B) — straightforward translation of §4.3 SQL
+  into a STABLE SECURITY DEFINER function; pattern matches mig 111
+  exactly.
+
+Branch: keep on `mai/dirac/user-checklists`. Three slices = three PRs,
+or one branch with three commits — coder's call. Each slice ends with
+acceptance criteria; head merges between slices for fast feedback.
+
+## 14. Out of scope (explicitly)
+
+- Importing checklists from external sources (Notion, Trello, .docx).
+- Approval-policy gating on checklist edits (admin pre-publish review).
+- Cross-firm template marketplace.
+- Translation workflow (de↔en) for authored templates — Slice A
+  ships single-language; if firm appetite shows up post-launch, file
+  a follow-up.
+- Static-catalog editor UI (the static templates remain code-only).
+- Versioning UI ("show me the version this instance was created from")
+  — snapshot is captured; surfacing it is Slice C polish.
+
+---
+
+**Inventor parked per gate protocol.** No auto-shift to coder. Head
+decides: same worker as `/mai-coder` with this brief, fresh coder, or
+rescope. Slice ordering A → B → C is independent enough that the head
+can also greenlight Slice A alone and re-design B/C after Slice A
+ships.

docs/proposals/fristen-gap-fill-2026-05-18.md

@@ -0,0 +1,435 @@
+# Fristenrechner Gap-Fill Proposals — t-paliad-203
+
+**Date:** 2026-05-18
+**Author:** curie (researcher)
+**Status:** DRAFT — for m's review, not yet ingested via `/admin/rules`
+**Branch:** `mai/curie/fristenrechner-gap`
+**Supersedes:** t-paliad-201 (cancelled)
+**Source audit:** the four gaps surfaced by mig 093 commit message (t-paliad-200, `internal/db/migrations/093_retire_litigation_category.up.sql:40-54`) when 40 Pipeline-A litigation rules were archived under `_archived_litigation` and 7 litigation proceeding_types were dropped
+
+---
+
+## 0. Read-this-first — what was archived, what's left
+
+mig 093 (commit `40e49e8`) retired the entire `category='litigation'` rule corpus by:
+
+1. Snapshotting the 40 rules into `paliad.deadline_rules_pre_093` and the 7 proceeding_types into `paliad.proceeding_types_pre_093`.
+2. Re-homing all 40 rules under a holding proceeding_type `_archived_litigation` (id 32, `category='archived'`, `is_active=false`, `lifecycle_state='archived'`).
+3. Dropping `INF`, `REV`, `CCR`, `APM`, `APP`, `AMD`, `ZPO_CIVIL` from `paliad.proceeding_types`.
+
+The commit's own body listed four open coverage questions for legal review (lines 40-54 of `093_retire_litigation_category.up.sql`):
+
+| # | Pipeline-A rule(s) | Claim in commit body | This doc's verdict |
+|---|---|---|---|
+| 1 | `inf.prelim` (R.19, 1 month) | "not present on UPC_INF — possible coverage gap" | **Real gap.** Drafts 1.1 + 1.2 below. |
+| 2 | `inf.appeal` / `rev.appeal` / `ccr.appeal` (RoP.220.1, 2 months) into UPC_APP | "fristenrechner UPC_APP starts standalone with no spawn" | **Real gap.** Drafts 2.1 + 2.2 below. Pipeline-A's three rules collapse to two in the unified UPC_INF (CCR-as-flag) world — see § 2 FLAG. |
+| 3 | `ccr.amend` / `rev.amend` (spawn into AMD) | "superseded by `inf.app_to_amend` / `rev.app_to_amend` — safe to drop" | **Claim confirmed for patent amendment.** No new rules. § 3 documents the verification and surfaces R.263 (case-amendment) as a separate not-modelled item. |
+| 4 | `zpo.klage` / `zpo.vertanz` / `zpo.klageerw` / `zpo.berufung` | "no UPC analogue; redundant with DE_INF / DE_INF_OLG / DE_INF_BGH / DE_NULL / DE_NULL_BGH" | **Claim confirmed for klage / vertanz / berufung.** `klageerw` exists on DE_INF but with a duration discrepancy worth m's attention. § 4 details. |
+
+**Net: 4 substantive rule drafts** (1 PO on UPC_INF + 1 PO on UPC_REV + 2 merits-appeal spawns) — well under the "~4-10" estimate in the brief, and at the low end because two of the four gaps don't need new rules.
+
+### 0.1 Naming convention notes
+
+- **Appeal proceeding code referenced by ROLE, not by current code.** Per task brief and pairing with t-paliad-204 (proceeding-code abbreviation rework, m's review pending), the current `UPC_APP` (id=11) is referred to in proposals 2.1/2.2 as **"UPC infringement-appeal proceeding (RoP 220.1(a) main-judgment appeal)"** rather than by code. m picks the final `spawn_proceeding_type_id` when ingesting via `/admin/rules`.
+- **Existing rule-code pattern.** Live `UPC_INF` rules use bare prefix `inf.*` (not `upc.inf.*`), e.g. `inf.sod`, `inf.def_to_ccr`. Live `UPC_REV` rules use `rev.*`. I follow that pattern: proposed PO rules are `inf.prelim` (matching Pipeline-A's archived name) and `rev.prelim`; proposed spawn rules are `inf.appeal_spawn` / `rev.appeal_spawn` (the `_spawn` suffix disambiguates them from the existing UPC_APP-root `app.notice`, which is the *target*, not the *source*).
+- **Anchor semantics** (per `docs/audit-fristen-logic-2026-05-13.md` § 4 and `docs/proposals/orphan-concepts-2026-05-15.md` § 0.2): `parent_id NOT NULL` chains the new rule off an existing rule in the same proceeding. `trigger_event_id NOT NULL` roots the rule on a paliad/youpc trigger event. The unified Phase 2 schema (Slice 4, mig 081+082) supports both — proposals use `parent_id` whenever the natural anchor is an existing intra-proceeding rule (e.g. `inf.soc` for inf.prelim), which matches the pattern set by `inf.sod`, `inf.def_to_ccr`, etc.
+- **`condition_expr` form.** Existing UPC_INF / UPC_REV conditional rules use `{"flag":"with_ccr"}` or `{"op":"and","args":[{"flag":"with_ccr"},{"flag":"with_amend"}]}`. The proposals add three new flag names — `with_po`, `with_appeal`, and reuse `with_amend` only where existing. Flag names are surfaced as **FLAG** items for m to confirm before ingest.
+
+### 0.2 What's deliberately out of scope
+
+- **Order-appeals (R.220.2/R.220.3) spawn wiring** — the brief specifies RoP 220.1(a) (main-judgment, 2-month appeal → `UPC_APP`). The 15-day order/discretion track lives in `UPC_APP_ORDERS` and has its own root rules (`app_ord.with_leave`, `app_ord.discretion`). Spawn rules from UPC_INF/UPC_REV/UPC_PI for that track would be a separate proposal — flagged as future-work in § 6.
+- **Cost-decision-appeal spawn (R.221.1)** — `UPC_COST_APPEAL` exists with `cost.leave_app` as a root rule. Same shape as the order-appeals: future-work, not this proposal.
+- **R.263 application to amend the case** — surfaced in § 3 but not drafted as a rule because it's court-discretion (no calendar deadline computable from a fixed anchor).
+- **Vertagungsantrag (ZPO §227)** — the brief's description of Gap 4 named "Vertagungsantrag" but the Pipeline-A rule code `zpo.vertanz` is actually *Verteidigungsanzeige* (contraction of "Verteidigungs-Anzeige"), not Vertagungsantrag. There is no Vertagungsantrag rule anywhere in the corpus today; if m wants one, that's a fresh proposal. Documented in § 4 FLAG.
+
+---
+
+## 0.3 m's decisions on the open FLAGs (2026-05-18)
+
+Captured live with paliadin/head. Anything not explicitly answered defaults to curie's recommendation.
+
+### Gap 1 — Preliminary Objection
+
+- **F1.4 (CCR-defendant PO):** **NO** — do not seed a third PO rule for the patentee on a CCR. Final shape stays at 2 PO rules: `inf.prelim` + `rev.prelim`.
+- F1.1 (flag name): default to curie's `with_po`.
+- F1.2 (priority): default to curie's `optional`.
+- F1.3 (citation pattern): default to curie's `UPC.RoP.19.1` substantive-cite for both rules (cross-ref to R.46 lives in the description, not the legal_source field).
+
+### Gap 2 — Appeal spawns
+
+- **F2.1 (drop `ccr.appeal`):** **CONFIRMED** — one decision under R.118 = one 2-month appeal window. Rule 2.3 explicitly NOT seeded. Final shape stays at 2 spawn rules.
+- **F2.3 (appeal flag-gated or always-fire):** **ALWAYS-FIRE.** Rationale (m): "the appeal deadline should always be triggered by a decision … the flags for ccr / amend are different because that is something which only comes up during the proceedings and depends on a party. Appeal is always a possibility." So both `inf.appeal_spawn` and `rev.appeal_spawn` ship **without `condition_expr`** — the 2-month window unconditionally appears once `inf.decision` / `rev.decision` is anchored. Visibility filtering ("hide appeal deadlines on projects where the user doesn't care") is a frontend concern, not a rule-level flag — surfaced as follow-up (see § 6.X below).
+- F2.2 (anchor): default to curie's `parent_id = inf.decision` / `rev.decision` (consistent with how `inf.cost_app` already chains).
+
+### Gap 3 — `ccr.amend` / `rev.amend`
+
+- **F3.1 (model R.263?):** **NO** — court-discretion, no calendar deadline computable. If R.263 ever needs surfacing, it goes on the project page as a checklist item, not the fristenrechner.
+
+### Gap 4 — `zpo.*` family
+
+- **§4.3 — `de_inf.erwidg` discrepancy (6 weeks vs. court-set 2-week minimum):** **FLIP to court-set.** Klageerwiderung is statutorily court-set with a 2-week minimum under ZPO §276(1) S.2; the existing 6-week fixed-duration rule is wrong. Action at ingest: `is_court_set=true`, keep `duration_value=6, duration_unit='weeks'` as the **default display value** when no court order is yet attached, with the description noting "Gericht setzt eine Frist von mindestens zwei Wochen ab Verteidigungsanzeige (§276 Abs. 1 S. 2 ZPO)." This matches the pattern existing court-set rules use elsewhere.
+- F4.1 (legal_source backfills on `de_inf.klage` etc.): default to curie's "yes — apply the polish patches in § 4.1, § 4.2, § 4.4".
+
+### Final delta to ingest via `/admin/rules`
+
+```
+NEW RULES (4):
+  inf.prelim         UPC_INF  parent=inf.soc      1mo  RoP.19.1   flag=with_po       optional
+  rev.prelim         UPC_REV  parent=rev.app      1mo  RoP.19.1   flag=with_po       optional
+  inf.appeal_spawn   UPC_INF  parent=inf.decision 2mo  RoP.220.1.a (no flag)         optional  spawn→merits-appeal
+  rev.appeal_spawn   UPC_REV  parent=rev.decision 2mo  RoP.220.1.a (no flag)         optional  spawn→merits-appeal
+
+PATCHES on existing rules:
+  de_inf.klage       set legal_source = 'DE.ZPO.253'
+  de_inf.anzeige     (no change — already correct)
+  de_inf.erwidg      flip is_court_set = true; description note about §276 Abs.1 S.2
+  de_inf.berufung    (verify legal_source — curie's §4.4 polish patch)
+```
+
+### Follow-up surfaced — not for this proposal
+
+- **Frontend visibility toggle for appeal deadlines** — m flagged that appeals "always fire" at the rule level but the UI could hide them on projects where the user doesn't want to see them. NOT a rule-corpus question; file as a separate frontend task if/when m signals.
+- **`ccr.appeal` in `_archived_litigation`** — the Pipeline-A `ccr.appeal` row stays archived (m's call F2.1). No further action.
+- **Vertagungsantrag (ZPO §227)** — never modelled; not in scope. Open follow-up if m wants it.
+
+---
+
+## 1. Gap 1 — Preliminary Objection (RoP 19)
+
+**Status:** Real gap. Pipeline-A had `inf.prelim` (defendant, 1 month, R.19, "Rarely triggers separate decision; usually decided with main case") — archived without a fristenrechner replacement.
+
+Verification — current UPC_INF / UPC_REV corpus has zero rules with `rule_code` matching `R.19`, `RoP.019`, or any "Preliminary Objection" variant; verified via `SELECT * FROM paliad.deadline_rules WHERE rule_code ILIKE '%19%' OR name ILIKE '%vorab%' OR name ILIKE '%prelim%' AND lifecycle_state <> 'archived'` returns empty.
+
+Legal context — RoP 19 itself (Application of the Rules of Procedure, Part 1, Chapter 1, Section 4):
+
+- **R.19.1**: The defendant may, within 1 month of service of the Statement of claim, lodge a Preliminary objection concerning (a) jurisdiction and competence of the Court including any objection to the decision of the Registry to assign a case to a particular division, (b) the language of the Statement of claim (R.14), or (c) the competence of the panel to which the action has been assigned.
+- **R.19.7 / R.19.8**: The Court decides on a preliminary objection by way of order, typically before the interim conference, but may join it to the main proceedings.
+- **R.46**: The Rules in Part 1, Chapter 1 (including R.19) apply *mutatis mutandis* to revocation actions — i.e. the defendant in a revocation action (the patent proprietor) may also lodge a preliminary objection within 1 month of service of the Statement for revocation.
+
+The Pipeline-A note "Rarely triggers separate decision; usually decided with main case" is accurate practice — but the **1-month deadline to raise the objection** is hard and statutory. That deadline is what the fristenrechner needs to model.
+
+### Rule 1.1 — Preliminary Objection on UPC_INF
+
+- **Rule code:** `inf.prelim`
+- **Proceeding type:** UPC_INF (id=8)
+- **Name (DE):** Vorab-Einrede (R. 19 VerfO)
+- **Name (EN):** Preliminary Objection (RoP 19)
+- **Party:** defendant
+- **Anchor:** `parent_id = inf.soc` (the existing root rule "Klageerhebung") — same anchor pattern as `inf.sod` (Klageerwiderung, also parent=inf.soc). `inf.soc` is the trigger-date anchor; computing 1 month after `inf.soc` reads as "1 month from service of the Statement of Claim", consistent with R.19.1's wording.
+- **Duration:** 1, months
+- **Timing:** after
+- **Priority:** optional *(party decides whether to raise the objection; the 1-month period is statutory once invoked)*
+- **is_court_set:** false *(statutory period from service; not court-set)*
+- **condition_expr:** `{"flag":"with_po"}` *(only renders when the defendant indicates a PO will be filed — same shape as existing `with_ccr` / `with_amend` flags)*
+- **Legal source:** `UPC.RoP.19.1`
+- **`rule_code`:** `RoP.019.1`
+- **event_type:** `filing`
+- **Notes:** R.19.1 covers three independent grounds (a) jurisdiction/competence, (b) language under R.14, (c) panel competence. All share the same 1-month deadline. The UI rendering decision (one row vs. three rows by ground) is downstream UX, not a rule-corpus question.
+- **FLAG (F1.1):** Flag name — `with_po` is suggested by analogy to `with_ccr` / `with_amend` / `with_cci`. Alternative names: `with_preliminary_objection`, `prelim`. m's call.
+- **FLAG (F1.2):** Priority — proposed `optional` (defendant chooses); m may prefer `recommended` to surface it as a sanity-check chip on every defendant timeline. The Pipeline-A predecessor had `is_optional=true / is_mandatory=false` per the old binary schema, which maps cleanly to `priority='optional'` in the post-Slice-3 enum.
+
+### Rule 1.2 — Preliminary Objection on UPC_REV
+
+- **Rule code:** `rev.prelim`
+- **Proceeding type:** UPC_REV (id=9)
+- **Name (DE):** Vorab-Einrede (R. 19 i.V.m. R. 46 VerfO)
+- **Name (EN):** Preliminary Objection (RoP 19 in conjunction with RoP 46)
+- **Party:** defendant *(in a revocation action the patentee is the defendant)*
+- **Anchor:** `parent_id = rev.app` (the existing root rule "Nichtigkeitsklage" — analogous to `rev.defence` which also parents off `rev.app`)
+- **Duration:** 1, months
+- **Timing:** after
+- **Priority:** optional
+- **is_court_set:** false
+- **condition_expr:** `{"flag":"with_po"}` *(same flag as 1.1 — a PO is a PO; the user sets `with_po=true` on a UPC_REV project when the patentee plans to lodge one)*
+- **Legal source:** `UPC.RoP.46` *(R.46 makes R.19 applicable to revocation actions; cite R.46 as the operative provision because RoP 19's literal text only addresses infringement)*
+- **`rule_code`:** `RoP.046` *(or `RoP.019.1` with a note — m's call; see FLAG F1.3)*
+- **event_type:** `filing`
+- **Notes:** Functionally identical to Rule 1.1 but rooted on UPC_REV. The grounds are narrower in practice (language and panel competence are the main triggers — jurisdiction is rarely contested in pure revocation actions because the UPC's jurisdiction over revocation of unitary patents is exclusive). But the 1-month statutory window is identical.
+- **FLAG (F1.3):** Legal-source citation — should this read `UPC.RoP.46` (operative provision for revocation) or `UPC.RoP.19.1` (substantive content)? Existing rules use the substantive citation (e.g. `inf.def_to_ccr` cites `UPC.RoP.29.a`, not the cross-reference that brings R.29 into the UPC_INF flow). I lean `UPC.RoP.19.1` with `rule_code='RoP.019.1'` to match that pattern; the cross-reference to R.46 belongs in the description, not the citation field.
+- **FLAG (F1.4):** Does paliad want **counterclaim-defendant** PO rules too? Specifically, when UPC_INF has `with_ccr=true`, the *claimant* (patentee) becomes the de-facto-defendant for the CCR portion. Does the claimant get a 1-month PO window from service of the CCR? My read of R.19 + R.46 + R.25: yes — the CCR triggers a fresh R.19 window for the claimant, anchored on service of the SoD-with-CCR. But this would be a third rule (`inf.prelim_ccr`, party=claimant, parent=inf.sod, 1 month, condition_expr={"op":"and","args":[{"flag":"with_ccr"},{"flag":"with_po_ccr"}]}). I'm **not** drafting it pending m's confirmation; either it's truly there in the case law or it's an over-reading on my part. Lex-research won't help here because there's no relevant published UPC PO case on a CCR yet (R.46 + R.25 cross-reads are theoretical).
+
+**Summary for Gap 1:** 2 new rules drafted (one on UPC_INF, one on UPC_REV). 4 FLAGs. Potential third rule (CCR-PO) deferred pending m's read.
+
+---
+
+## 2. Gap 2 — Cross-proceeding APP spawns (RoP 220.1(a))
+
+**Status:** Real gap. Pipeline-A had three placeholder rules (`inf.appeal`, `rev.appeal`, `ccr.appeal`, all 2 months, RoP.220.1, is_spawn=true) — but their `spawn_proceeding_type_id` was NULL so they weren't functional spawns either. Fristenrechner UPC_APP currently starts standalone with `app.notice` as its root rule (party=both, 2 months, RoP.220.1).
+
+Verification — current corpus has zero `is_spawn=true AND is_active=true AND lifecycle_state<>'archived'` rules; the `spawn_proceeding_type_id` column on `paliad.deadline_rules` is unused in the live data (Slice 7 wiring was the design intent but no real spawns have been seeded yet).
+
+Legal context — RoP 220 (Decisions and orders which may be appealed):
+
+- **R.220.1(a)**: Final decisions under R.118 may be appealed. The appeal period is **2 months of service** of the decision (R.224.1(a)).
+- **R.224.1(a)**: The Statement of appeal must be lodged within 2 months of service of the decision.
+- **R.224.2(a)**: The Statement of grounds of appeal must be lodged within 4 months of service of the decision (independent from R.224.1(a), not chained off it).
+
+The spawn target — the proceeding rooted by `app.notice` (Berufungseinlegung, RoP.220.1, 2 months) and `app.grounds` (Berufungsbegründung, 4 months from decision) — is what the task brief calls the "UPC infringement-appeal (RoP 220.1(a) main-judgment appeal)" proceeding. Today that's `UPC_APP` (id=11); per t-paliad-204, the code may be renamed before m ingests these proposals, so I refer to it by role only.
+
+### Rule 2.1 — Appeal spawn from UPC_INF
+
+- **Rule code:** `inf.appeal_spawn`
+- **Proceeding type:** UPC_INF (id=8)
+- **Name (DE):** Berufung gegen Endentscheidung
+- **Name (EN):** Appeal against final decision
+- **Party:** both *(either party may appeal an R.118 final decision adverse to them)*
+- **Anchor:** `parent_id = inf.decision` (existing court-set rule "Entscheidung"). The chain: `inf.soc → … → inf.decision (court-set, no statutory date) → inf.appeal_spawn (2 months after service of decision)`. Because `inf.decision` is `IsCourtSet=true` (per `isCourtDeterminedRule` in `internal/services/fristenrechner.go`), the appeal-spawn deadline only becomes a concrete date once the user anchors `inf.decision` via the smart-timeline click-to-anchor mechanism (Slice 2, `POST /api/projects/{id}/timeline/anchor` per memory `ab966313-cae6-49b0-8223-9adb62a64370`).
+- **Duration:** 2, months
+- **Timing:** after
+- **Priority:** optional *(party decides whether to appeal; the 2-month period is statutory once invoked)*
+- **is_court_set:** false *(deadline is statutory once the decision is served)*
+- **condition_expr:** `{"flag":"with_appeal"}` *(only renders when the user has indicated an appeal is contemplated — keeps non-appealing projects' timelines clean)*
+- **Legal source:** `UPC.RoP.220.1`
+- **`rule_code`:** `RoP.220.1.a`
+- **event_type:** `filing`
+- **is_spawn:** true
+- **spawn_proceeding_type_id:** → UPC infringement-appeal proceeding (currently `UPC_APP`, id=11; m picks final code at ingest per t-paliad-204).
+- **spawn_label (DE):** "Berufungsverfahren öffnen"
+- **spawn_label (EN):** "Open appeal proceedings"
+- **Notes:** Spawning into the appeal proceeding creates a child project (or routes into the standalone UPC_APP fristenrechner depending on how spawn rendering works on the project page). The 4-month Statement of grounds period (R.224.2(a), `app.grounds`) is already a root rule on UPC_APP — once the appeal child opens, that timeline takes over. **No need** to also model `app.grounds` as a spawn rule from UPC_INF; the existing UPC_APP root rules cover it.
+- **FLAG (F2.1):** Does the spawn fire on the CCR portion of the decision too? In a `with_ccr=true` UPC_INF, the R.118 final decision adjudicates both the infringement *and* the counterclaim for revocation. Either side may appeal either part. My read: **one spawn covers both** — there's only one R.118 decision, one 2-month window. The Pipeline-A `ccr.appeal` was a relic of the days when CCR was a separate proceeding type. **Recommend dropping the third "ccr.appeal" entirely**, because in the unified UPC_INF (CCR-as-flag) model it would duplicate Rule 2.1. m to confirm.
+- **FLAG (F2.2):** Anchor — should the spawn rule chain off `inf.decision` (court-set, requires anchor-click) or be event-rooted on a `final_decision_service` trigger event (paliad has trigger_event id=88 "Endentscheidung (Zustellung)")? Both work. Chaining on `inf.decision` keeps the rule visually attached to its parent proceeding in the UI; event-rooted is more flexible if the user wants to compute an appeal deadline standalone without a project. Recommend `parent_id = inf.decision` to match how `inf.cost_app` chains off `inf.decision` already.
+- **FLAG (F2.3):** Flag name — `with_appeal` mirrors the existing `with_ccr` / `with_amend` flag naming. Alternative: spawn rules might always fire (no flag), letting the timeline show the appeal window as a "predicted/court-set" placeholder. The latter is closer to what the SmartTimeline projection (`projection_service.go`) already does for cross-proceeding rules per memory `686f0b8c-02ed-4807-8785-b088e3a3e515` § 6 gap 7. If m wants the appeal window to *always* appear after the decision (unconditionally), drop `condition_expr` here and on Rule 2.2.
+
+### Rule 2.2 — Appeal spawn from UPC_REV
+
+- **Rule code:** `rev.appeal_spawn`
+- **Proceeding type:** UPC_REV (id=9)
+- **Name (DE):** Berufung gegen Endentscheidung (Nichtigkeit)
+- **Name (EN):** Appeal against final decision (revocation)
+- **Party:** both
+- **Anchor:** `parent_id = rev.decision` (existing court-set rule "Entscheidung")
+- **Duration:** 2, months
+- **Timing:** after
+- **Priority:** optional
+- **is_court_set:** false
+- **condition_expr:** `{"flag":"with_appeal"}`
+- **Legal source:** `UPC.RoP.220.1`
+- **`rule_code`:** `RoP.220.1.a`
+- **event_type:** `filing`
+- **is_spawn:** true
+- **spawn_proceeding_type_id:** → same UPC infringement-appeal proceeding as Rule 2.1. The UPC CoA hears both INF and REV appeals; in a `with_cci=true` UPC_REV (Verletzungswiderklage / counterclaim-for-infringement), the R.118 decision may also adjudicate the infringement piece, but again it's one decision, one appeal window.
+- **spawn_label (DE):** "Berufungsverfahren öffnen"
+- **spawn_label (EN):** "Open appeal proceedings"
+- **Notes:** Functionally a mirror of Rule 2.1 on the revocation proceeding. Same FLAGs F2.1-F2.3 apply.
+
+### Rule 2.3 — (proposed) NOT drafted: separate `ccr.appeal` from UPC_INF with_ccr
+
+**See FLAG F2.1.** In the unified model, the CCR portion of an UPC_INF decision is appealed via the same R.118 final-decision spawn (Rule 2.1) — a single 2-month window covers infringement, revocation, and patent-amendment claims because they all sit in one R.118 decision. Drafting `ccr.appeal` as a third rule would duplicate Rule 2.1 conditionally (`{"op":"and","args":[{"flag":"with_ccr"},{"flag":"with_appeal"}]}`) and produce a redundant timeline row. **Recommendation: do not seed.** If m disagrees, the rule shape would be:
+
+```
+inf.appeal_spawn_ccr (UPC_INF)
+  condition_expr: {"op":"and","args":[{"flag":"with_ccr"},{"flag":"with_appeal"}]}
+  spawn_label: "Berufung Nichtigkeit öffnen" (specifically the CCR portion)
+```
+
+Only useful if the appeal UI needs to distinguish "appealing the infringement finding" from "appealing the revocation finding". Today's fristenrechner UI doesn't make that distinction; the appeal proceeding handles both.
+
+**Summary for Gap 2:** 2 new spawn rules drafted. 3 FLAGs. The third Pipeline-A relic (`ccr.appeal`) is structurally redundant and recommended **not** to seed.
+
+---
+
+## 3. Gap 3 — `ccr.amend` / `rev.amend` (verification of "safe to drop" claim)
+
+**Status:** No new rules needed. The migration's claim ("superseded by `inf.app_to_amend` / `rev.app_to_amend` — safe to drop") is **confirmed for the patent-amendment scope**. There is a separate concept (R.263 application to amend the case) that has never been modelled and probably shouldn't be — see § 3.2.
+
+### 3.1 Verification — patent-amendment coverage
+
+Pipeline-A's `ccr.amend` and `rev.amend` were both:
+
+- duration_value=0, duration_unit='months', event_type='filing', is_spawn=true, party='claimant'
+- legal_source=NULL, rule_code=NULL
+- source proceeding=AMD (now archived)
+- "Application to Amend Patent" / no German name
+
+These were placeholder spawns into a hypothetical "AMD" (Application to amend the patent) proceeding type that never existed as a real fristenrechner tree. They modelled the concept "filing a patent amendment", not its deadline.
+
+The unified UPC_INF / UPC_REV corpus already covers patent amendment with real deadlines and flag-gated chains:
+
+| Existing rule | Proceeding | Trigger / parent | Duration | Legal source | Flag-gating |
+|---|---|---|---|---|---|
+| `inf.app_to_amend` | UPC_INF | parent=inf.sod | 2 months | UPC.RoP.30.1 | `with_ccr+with_amend` |
+| `inf.def_to_amend` | UPC_INF | parent=inf.app_to_amend | 2 months | UPC.RoP.32.1 | `with_ccr+with_amend` |
+| `inf.reply_def_amd` | UPC_INF | parent=inf.def_to_amend | 1 month | UPC.RoP.32.3 | `with_ccr+with_amend` |
+| `inf.rejoin_amd` | UPC_INF | parent=inf.reply_def_amd | 1 month | UPC.RoP.32.3 | `with_ccr+with_amend` |
+| `rev.app_to_amend` | UPC_REV | parent=rev.defence | 0 months (filed-with-parent) | UPC.RoP.49.2.a | `with_amend` |
+| `rev.def_to_amend` | UPC_REV | parent=rev.app_to_amend | 2 months | UPC.RoP.43.3 | `with_amend` |
+| `rev.reply_def_amd` | UPC_REV | parent=rev.def_to_amend | 1 month | UPC.RoP.32.3 | `with_amend` |
+| `rev.rejoin_amd` | UPC_REV | parent=rev.reply_def_amd | 1 month | UPC.RoP.32.3 | `with_amend` |
+
+The flag-gated chain on UPC_INF (`with_ccr+with_amend`) is the post-2026-05-05 ship from t-paliad-131 PR-2 (memory `ba1517a3-2294-4c58-aeb6-87e82067834d`); the UPC_REV chain (`with_amend` and `with_cci`) is from the same PR. Both fully replace what `ccr.amend` / `rev.amend` ever could have represented.
+
+**Verdict on Gap 3:** "Safe to drop" is correct. **No new rules.**
+
+### 3.2 R.263 — Application to amend the case (not modelled, probably shouldn't be)
+
+R.263 ("Leave to change claim or amend case") is conceptually different from R.30 (Application to amend the patent). R.263 governs amendment of the **pleadings / case** — adding a new infringement allegation, narrowing claims, etc. The current corpus has no R.263 rule.
+
+I'm **not proposing one** because R.263 is purely court-discretionary (R.263.1: "An application may be made by a party at any time to … amend its case … Leave shall be granted only if … the requesting party could not with reasonable diligence have made the application earlier and the amendment will not unreasonably hinder the other party in the conduct of its action"). There is no statutory deadline computable from a fixed anchor — the party files when it needs to, and the court grants or refuses leave by order. Modelling it as a deadline_rule would either:
+
+- (a) Produce a phantom row with no computable date (the existing `is_court_set=true` pattern would technically work but offers no UX value because the deadline is "whenever you need to amend").
+- (b) Produce a misleading row anchored on the SoC date with some heuristic period.
+
+**Recommendation: don't seed.** If m wants R.263 surfaced anywhere, it belongs as a checklist item on the project page, not as a fristenrechner rule.
+
+**FLAG (F3.1):** Confirm "don't model R.263" is acceptable. If R.263 *should* be modelled, what anchor + duration heuristic should it use?
+
+**Summary for Gap 3:** 0 new rules. 1 FLAG. The claim "safe to drop" is verified for patent amendment. R.263 is a separate concept and intentionally left unmodelled.
+
+---
+
+## 4. Gap 4 — `zpo.*` family vs. existing DE_INF / DE_INF_OLG / DE_INF_BGH
+
+**Status:** No new rules needed for `klage`, `vertanz`, `berufung`. **Existing rule `de_inf.erwidg` (Klageerwiderung) has a duration discrepancy worth m's attention.** Task brief's mention of "Klageerweiterung" / "Vertagungsantrag" is a misread of Pipeline-A rule names — those concepts are not in scope here. § 4.1-4.4 verify each Pipeline-A rule; § 4.5 surfaces what *would* be a real gap if m wants ZPO §227 modelled.
+
+### 4.1 `zpo.klage` (Klageerhebung, ZPO §253) — ✓ redundant
+
+Pipeline-A: claimant, 0 months, filing, `§ 253 ZPO`, legal_source=NULL.
+
+Existing rule `de_inf.klage` on DE_INF: claimant, 0 months, filing. Functionally identical as a root rule (a 0-duration "trigger" anchor). Legal source on the existing rule is NULL — could be backfilled to `DE.ZPO.253` as a minor polish, but no new rule needed.
+
+**Verdict: no gap.** *Optional polish:* set `de_inf.klage.legal_source = 'DE.ZPO.253'` (one-line UPDATE; not a new rule). FLAG F4.1.
+
+### 4.2 `zpo.vertanz` (Verteidigungsanzeige, ZPO §276(1) Satz 1) — ✓ redundant
+
+**Task-brief naming note:** the brief described this gap as "Vertagungsantrag" but Pipeline-A's `zpo.vertanz` is actually *Verteidigungsanzeige* (contraction "VertAnz" not "VertA. (Antrag)"). The rule name in the snapshot reads "Verteidigungsanzeige" verbatim. Vertagungsantrag (§ 227 ZPO) is a different concept entirely — see § 4.5.
+
+Pipeline-A: defendant, 2 weeks, filing, `§ 276 Abs. 1 S. 1 ZPO`, deadline_notes "Notfrist ab Zustellung der Klageschrift".
+
+Existing rule `de_inf.anzeige` on DE_INF: defendant, 2 weeks, `DE.ZPO.276.1`, "Anzeige der Verteidigungsbereitschaft". Same period, same legal basis, same party.
+
+**Verdict: no gap.**
+
+### 4.3 `zpo.klageerw` (Klageerwiderung, ZPO §276(1) Satz 2) — ⚠ duration discrepancy
+
+Pipeline-A: defendant, **2 weeks**, filing, `§ 276 Abs. 1 S. 2 ZPO`, legal_source=NULL, deadline_notes "Vom Gericht gesetzt, mindestens 2 Wochen".
+
+Existing rule `de_inf.erwidg` on DE_INF: defendant, **6 weeks**, `DE.ZPO.276.1`, "Klageerwiderung", is_court_set=false.
+
+**This is a substantive discrepancy.** Both rules cite the same statutory anchor (ZPO §276(1) Satz 2), but:
+
+- Pipeline-A modelled the **statutory floor** ("mindestens 2 Wochen") with `is_court_set` implicit (the deadline_notes said "Vom Gericht gesetzt").
+- DE_INF models a **typical court-practice heuristic** (6 weeks is a common Munich/Düsseldorf LG setting, though 4-8 weeks is the realistic range).
+
+The DE_INF rule is **strictly more useful** for a practitioner planning a defence schedule (the 2-week floor is rarely the actual deadline; the court order sets the real date). But it's **technically wrong** to mark `is_court_set=false` because the date *is* set by court order — the 6 weeks is a guess at what the court will set, not a statutory period.
+
+**No new rule needed**, but two corrections are worth flagging on the existing rule:
+
+- **FLAG F4.2 (correctness):** Set `de_inf.erwidg.is_court_set = true`. The deadline date is set by the court's Klageerwiderungsfrist order under §276(1) Satz 2, not by the statute directly. This matches how Schriftsatznachreichung (§296a) was flagged in `docs/proposals/orphan-concepts-2026-05-15.md` § 2.1 FLAG F8.
+- **FLAG F4.3 (heuristic transparency):** 6 weeks vs. the statutory 2-week floor — the deadline_notes (DE) on `de_inf.erwidg` should probably say "Vom Gericht gesetzt, mindestens 2 Wochen (§ 276 Abs. 1 S. 2 ZPO); typische Praxis: 4-8 Wochen" rather than just rendering as a hard 6-week deadline. UX consideration, not a rule-shape question.
+
+Neither change is a new rule; both are PATCH operations on the existing row via `/admin/rules`.
+
+### 4.4 `zpo.berufung` (Berufung, ZPO §517) — ✓ redundant (twice over)
+
+Pipeline-A: both, 1 month, filing, `§ 517 ZPO`, `DE.ZPO.517`, deadline_notes "Notfrist ab Zustellung des vollständigen Urteils".
+
+Existing rules:
+
+- `de_inf.berufung` on DE_INF: both, 1 month, `DE.ZPO.517`. Same shape.
+- `de_inf_olg.berufung` on DE_INF_OLG: both, 1 month, `DE.ZPO.517`. Same shape (covers the OLG-instance entry point).
+
+Either rule covers it. **Verdict: no gap.**
+
+### 4.5 Real gap (if m wants): Vertagungsantrag (ZPO §227)
+
+The task brief mentioned "Vertagungsantrag" by name. Pipeline-A had no Vertagungsantrag rule (the `zpo.vertanz` rule code is a contraction of *Verteidigungsanzeige*, not Vertagungsantrag — see § 4.2). The current corpus has no Vertagungsantrag rule either.
+
+ZPO §227 governs applications to adjourn a hearing ("Aufhebung und Verlegung von Terminen, Vertagung der Verhandlung"). §227.1 requires "erhebliche Gründe", §227.2 gives examples (verhinderter Anwalt etc.), §227.3 restricts adjournment of evidence hearings (Beweisaufnahme). **There is no statutory deadline for filing a Vertagungsantrag** — it's "as soon as the ground arises and, in practice, as early as possible before the hearing date". The application is court-discretionary (§227.1: "kann").
+
+I would **not** recommend modelling Vertagungsantrag as a deadline_rule for the same reason as R.263 in § 3.2: there's no statutory deadline anchor; it's a checklist concept, not a calendar deadline. But m may have a different view — flag F4.4.
+
+**FLAG (F4.4):** Should Vertagungsantrag be modelled? If yes, what anchor + duration? Most natural seed would be `condition_expr={"flag":"with_vertagung"}` on the relevant hearing rule (de_inf.termin, de_null.termin, etc.), is_court_set=true, no duration. But that's an oddly-shaped rule that produces no useful date.
+
+**Summary for Gap 4:** 0 new rules. 4 FLAGs (F4.1-F4.4). The migration's "redundant — safe to drop" claim is confirmed for `klage` / `vertanz` / `berufung`. `klageerw` exposes a discrepancy on the existing `de_inf.erwidg` rule (`is_court_set=false` is wrong; 6-weeks heuristic should be transparent in notes) — both are PATCH operations on the existing row, not new rules. Vertagungsantrag is a separate concept that probably shouldn't be modelled as a deadline_rule.
+
+---
+
+## 5. Track A — Polish UPDATEs on existing rows (no new rules, no legal review)
+
+Distinct from new rules, three existing rows could be PATCH'd via `/admin/rules` to improve correctness or transparency. **None of these are required for the gap-fill to be considered "done"** — they're flagged so they don't get lost if m wants to address them in the same ingest session.
+
+| # | Row | Field | From | To | Reason |
+|---|---|---|---|---|---|
+| P1 | `de_inf.klage` (DE_INF) | `legal_source` | NULL | `DE.ZPO.253` | Polish; matches existing convention (Rule 1.1's `UPC.RoP.19.1` etc.). |
+| P2 | `de_inf.erwidg` (DE_INF) | `is_court_set` | false | true | Correctness; deadline is court-order-set per ZPO §276(1) Satz 2. |
+| P3 | `de_inf.erwidg` (DE_INF) | `deadline_notes` (DE) | (current text) | "Vom Gericht gesetzt, mindestens 2 Wochen (§ 276 Abs. 1 S. 2 ZPO); typische Praxis: 4-8 Wochen" | Transparency; the 6-week duration is a heuristic, not statutory. |
+
+---
+
+## 6. Track B — Genuinely new rule drafts (this proposal's substantive output)
+
+| # | Gap | Rule code | Proceeding (by role) | Source |
+|---|---|---|---|---|
+| 1.1 | 1 (PO) | `inf.prelim` | UPC_INF | RoP 19.1 |
+| 1.2 | 1 (PO) | `rev.prelim` | UPC_REV | RoP 19.1 i.V.m. R.46 |
+| 2.1 | 2 (APP spawn) | `inf.appeal_spawn` | UPC_INF, spawn → UPC infringement-appeal proceeding | RoP 220.1(a) / R.224.1(a) |
+| 2.2 | 2 (APP spawn) | `rev.appeal_spawn` | UPC_REV, spawn → UPC infringement-appeal proceeding | RoP 220.1(a) / R.224.1(a) |
+
+**Total new rules: 4.** Plus 3 optional polish PATCHes in § 5. None of the proposed rules introduce new flag-name conventions (other than `with_po` and `with_appeal`, which mirror existing `with_ccr` / `with_amend` / `with_cci`).
+
+### Future-work (not this proposal)
+
+- Order-appeals spawn (R.220.2 / R.220.3) from UPC_INF / UPC_REV / UPC_PI → UPC_APP_ORDERS (15-day track). Today UPC_APP_ORDERS has only standalone root rules.
+- Cost-decision-appeal spawn (R.221.1) from UPC_INF / UPC_REV → UPC_COST_APPEAL.
+- CCR-defendant PO (FLAG F1.4): claimant's 1-month PO window when receiving SoD-with-CCR — only if confirmed against real case law or m's read.
+- R.263 (case amendment) and ZPO §227 (Vertagungsantrag): both court-discretionary, no statutory deadline — recommend leaving unmodelled (FLAGs F3.1, F4.4).
+- DE_NULL / DE_NULL_BGH appeal spawns: PatG §110 chains DE_NULL → DE_NULL_BGH (Berufung BGH). Currently DE_NULL_BGH is a standalone tree rooted on `de_null_bgh.urteil_bpatg`. Same pattern as the UPC spawn gap. Out of brief scope but worth a parallel proposal.
+
+---
+
+## 7. Open questions / FLAGs index
+
+For convenience, all `**FLAG**`-marked items in one place. m's decision is needed on each before `/admin/rules` ingest of the corresponding rule (or rule edit).
+
+| ID | Section | Question |
+|---|---|---|
+| F1.1 | § 1.1 | Flag name for Preliminary Objection — `with_po` vs `with_preliminary_objection` vs `prelim`. |
+| F1.2 | § 1.1 | Priority for PO — `optional` (recommended) vs `recommended` (always-surface as sanity-check chip). |
+| F1.3 | § 1.2 | Legal-source citation for UPC_REV PO — `UPC.RoP.19.1` (substantive) vs `UPC.RoP.46` (operative). Recommend substantive. |
+| F1.4 | § 1.2 | Add a third PO rule for CCR-defendant (party=claimant, fires when `with_ccr=true`)? |
+| F2.1 | § 2.1 | Recommend **not seeding** `ccr.appeal` as a third rule — CCR appeal is covered by `inf.appeal_spawn` (one R.118 decision, one window). Confirm. |
+| F2.2 | § 2.1 | Anchor for spawn — `parent_id = inf.decision` (chain) vs `trigger_event_id = 88 final_decision_service` (event-rooted). Recommend chain. |
+| F2.3 | § 2.1 | Flag-gated (`with_appeal`) vs always-rendered. Recommend flag-gated to keep non-appealing timelines clean; SmartTimeline's "predicted" rendering of cross-proceeding rules is the alternative. |
+| F3.1 | § 3.2 | R.263 (case amendment) — confirm not modelled as a deadline_rule. |
+| F4.1 | § 4.1 | Polish P1: backfill `de_inf.klage.legal_source = 'DE.ZPO.253'`? |
+| F4.2 | § 4.3 | Polish P2: set `de_inf.erwidg.is_court_set = true`? |
+| F4.3 | § 4.3 | Polish P3: improve `de_inf.erwidg.deadline_notes` to expose the 6-week heuristic vs the 2-week statutory floor? |
+| F4.4 | § 4.5 | Vertagungsantrag (ZPO §227) — confirm not modelled. |
+
+---
+
+## 8. Sources cited
+
+| Citation key | Reference |
+|---|---|
+| `UPC.RoP.19.1` | UPC Rules of Procedure, Rule 19(1) — Preliminary objection |
+| `UPC.RoP.19.7` | UPC RoP Rule 19(7) — Court decides preliminary objection by order |
+| `UPC.RoP.25` | UPC RoP Rule 25 — Lodging of Counterclaim for Revocation (cross-ref for FLAG F1.4) |
+| `UPC.RoP.30.1` | UPC RoP Rule 30(1) — Application to amend the patent (cross-ref for § 3.1) |
+| `UPC.RoP.46` | UPC RoP Rule 46 — Part 1 Chapter 1 (incl. R.19) applies *mutatis mutandis* to revocation actions |
+| `UPC.RoP.118` | UPC RoP Rule 118 — Final decisions on the merits |
+| `UPC.RoP.151` | UPC RoP Rule 151 — Cost decision (cross-ref for existing `inf.cost_app`) |
+| `UPC.RoP.220.1.a` | UPC RoP Rule 220(1)(a) — Appeal against R.118 final decision |
+| `UPC.RoP.220.2` | UPC RoP Rule 220(2) — Order appeals with leave (cross-ref, future work) |
+| `UPC.RoP.220.3` | UPC RoP Rule 220(3) — Discretionary review (cross-ref, future work) |
+| `UPC.RoP.221.1` | UPC RoP Rule 221(1) — Cost-decision appeal (cross-ref, future work) |
+| `UPC.RoP.224.1.a` | UPC RoP Rule 224(1)(a) — Statement of appeal lodged within 2 months |
+| `UPC.RoP.224.2.a` | UPC RoP Rule 224(2)(a) — Statement of grounds within 4 months |
+| `UPC.RoP.263` | UPC RoP Rule 263 — Leave to change claim or amend case |
+| `DE.ZPO.227` | ZPO §227 — Vertagung und Terminsänderung |
+| `DE.ZPO.253` | ZPO §253 — Klageschrift |
+| `DE.ZPO.276.1` | ZPO §276(1) — Verteidigungsanzeige (S.1) und Klageerwiderungsfrist (S.2) |
+| `DE.ZPO.517` | ZPO §517 — Berufungsfrist (1 Monat ab Zustellung) |
+
+---
+
+## 9. What's next (if m approves)
+
+1. **Decide the 12 FLAGs in § 7** (mostly flag names, priorities, and the three PATCH operations on existing rows). None require legal-side research — they're product/UX calls.
+2. **Confirm the appeal target's final proceeding-code** post-t-paliad-204 rename. Until then, ingest using whatever code lives at id=11 (currently `UPC_APP`) and rename via mig if t-paliad-204 lands with a different code.
+3. **Ingest the 4 new rules** via `/admin/rules` POST (Slice 11a backend, Slice 11b frontend). Each goes into `lifecycle_state='draft'` first. Promote to `published` after spot-checking via the calculator preview endpoint with a test project (e.g. UPC_INF with `with_po=true` should show the new `inf.prelim` row 1 month after the trigger date).
+4. **Optionally apply the 3 PATCHes in § 5** in the same session.
+5. **Verify spawn rendering** end-to-end — the spawn_proceeding_type_id column is unused in live data today, so this is the first real consumer. The SmartTimeline projection (per `internal/services/projection_service.go`, memory `686f0b8c-…`) early-returns on spawn rules when "we don't have that rule in our map" — that code path needs to actually render a spawn row now, not no-op. May require a Slice 7 follow-up tweak in `projection_service.go` to honour `spawn_proceeding_type_id` and surface the appeal proceeding's root deadline as a spawned child row.
+
+**Estimated corpus delta after ingest:** Track B = 4 new rules → `paliad.deadline_rules` row count grows from 249 to **253**. Track A polish = 3 row-level PATCHes (no row count change). One new `is_spawn=true` row goes live for the first time, exercising the previously-unused `spawn_proceeding_type_id` wiring.

docs/proposals/legal-citation-backfill-2026-05-18.md

@@ -0,0 +1,429 @@
+# Legal-citation Backfill Proposals — t-paliad-208 (Workstream A)
+
+**Date:** 2026-05-18
+**Author:** huygens (researcher)
+**Status:** DRAFT — for m's review, not yet migrated
+**Branch:** `mai/huygens/workstream-a-backfill`
+**Adjacent:** parallel-track with t-paliad-209 (workstream B — `code` rename + UI cleanup; different fields, no overlap)
+**Successor:** mig 097 will UPDATE the rows m approves; backup snapshot `deadline_rules_pre_097`
+
+---
+
+## 0. Read-this-first
+
+### 0.1 What this doc is
+
+Today's audit (paliadin/head, 2026-05-18) found that **130 of 213 active+published rows in `paliad.deadline_rules`** have `rule_code IS NULL`, and 122 have `legal_source IS NULL`. The internal slug field `code` (e.g. `inf.sod`, `de_null.berufung`) had been mistaken for a legal citation; it is just the per-proceeding submission identifier. The actual RoP / ZPO / EPÜ / PatG / UPCA citation belongs in `rule_code` (display form) + `legal_source` (structured locator).
+
+This document proposes a citation per rule. m approves; head re-tasks for migration 097.
+
+### 0.2 Field convention (profiled from the 83 already-populated rows)
+
+| Field | Purpose | Examples from live data |
+|---|---|---|
+| `rule_code` | **Human display form**, what we'd write in a brief | `§ 276 ZPO`, `§ 110 PatG`, `Art. 99 EPÜ`, `R. 71(3) EPÜ`, `R. 116 EPÜ`, `RPBA Art. 12`, `RoP.029.a`, `RoP.220.1.a`, `RoP.151`, `RoP.49.1` |
+| `legal_source` | **Structured locator** (forum-prefixed, no zero padding) for cross-system joins / lex extraction | `DE.ZPO.276.1`, `DE.PatG.111.1`, `EU.EPÜ.108`, `EU.EPC-R.71.3`, `EU.RPBA.12.1.c`, `UPC.RoP.29.a`, `UPC.RoP.220.1` |
+
+**Sub-conventions observed in live data**
+
+- `legal_source` prefixes: `DE.<statute>.<n>.<para>`, `EU.EPÜ.<n>.<para>`, `EU.EPC-R.<n>.<para>`, `EU.RPBA.<n>.<para>.<letter>`, `UPC.RoP.<n>.<sub>`.
+- `rule_code` padding for UPC RoP is **inconsistent today**: rules below 100 are mostly 3-digit padded (`RoP.029.a`, `RoP.030.1`, `RoP.049.2.a`, `RoP.056.1`) but `rev.defence` carries an un-padded `RoP.49.1`. Rules ≥100 are never padded (`RoP.137.2`, `RoP.220.1`).
+  - **Proposed normalization:** 3-digit pad for rules <100, no pad for ≥100. mig 097 should also normalize `RoP.49.1 → RoP.049.1` (1 outlier row, `rev.defence`) as a side-fix. m to confirm.
+- `legal_source` for UPC RoP **never** pads (`UPC.RoP.29.a`, not `UPC.RoP.029.a`). I follow that.
+
+### 0.3 Triage philosophy — events vs. deadlines
+
+Of the 130 NULL-rule_code rows, 53 carry a `proceeding_type_id` and 77 are orphans (`proceeding_type_id IS NULL`, also `code IS NULL`). Within the proceeding-typed bucket, most are **event markers** (zero `duration_value`, `event_type ∈ {hearing, decision, filing}`) that anchor other deadlines rather than computing one of their own.
+
+I classify each row as one of:
+
+| Category | Treatment | Examples |
+|---|---|---|
+| **Deadline** (positive duration, fires off an anchor) | Cite the operative procedural norm. Confidence usually HIGH. | `inf.sod` Klageerwiderung 3 months → RoP.23 |
+| **Constitutive event** (zero duration, but a statute defines it) | Cite the constitutive norm (matches existing convention: `de_inf.klage` already has `DE.ZPO.253`). Confidence HIGH where the norm is canonical. | Klageerhebung → § 253 ZPO; Anmeldung EP → Art. 75 EPÜ; Klage UPC → RoP.13.1 |
+| **Service / trigger event** (zero duration, third-party delivery) | Cite the service norm (§ 317 ZPO etc.) with MEDIUM confidence — these are anchor events for downstream timers, not deadlines on a party. m may prefer NULL here. **FLAG.** | `de_inf_olg.urteil_lg` Zustellung LG-Urteil |
+| **Court-scheduled event** (hearing, judgment-issuance) | Either NULL (recommended) or cite the general norm authorising the court to schedule. **FLAG.** | Mündliche Verhandlung BGH; OLG-Urteil |
+| **Court-set duration** (positive duration but `is_court_set=true`, or local practice) | Cite the framing norm (e.g. § 273 ZPO for ZPO patent practice), MEDIUM, FLAG. | `de_inf.replik` 4 weeks (LG patent practice) |
+
+**Where I am proposing NULL**, the row stays as-is on the DB side (mig 097 simply doesn't touch it). The FLAG list at the bottom of this doc enumerates every NULL proposal so m can override with an explicit citation if desired.
+
+### 0.4 Counts
+
+- 130 rows in scope (rule_code IS NULL; is_active=true; lifecycle_state='published')
+- 53 proceeding-typed + 77 orphan (no proceeding_type_id, no code)
+- 8 rows already carry a `legal_source` — those are **easy wins**: only `rule_code` needs proposing
+- ~ 40 HIGH-confidence proposals
+- ~ 35 MEDIUM-confidence proposals
+- ~ 55 FLAG entries (court-scheduled events, combined-pleading rows, ambiguous orphans)
+
+The orphan bucket carries a noticeable number of **duplicates** (six "Mängelbeseitigung / Zahlung" rows, two "Beginn des Hauptsacheverfahrens", two "Antrag auf Patentänderung", etc.). Those are likely vestiges of older Fristenrechner pipelines; backfilling them with the same citation is fine, but m may want a separate dedup pass (out of scope here; flag in § 4).
+
+---
+
+## 1. Easy wins — rows with `legal_source` already set, `rule_code` missing (8)
+
+For these, the structured locator is already in the DB; only the display form is missing.
+
+| id | code / name | duration | existing `legal_source` | proposed `rule_code` | conf |
+|---|---|---|---|---|---|
+| `1f532c82…` | `de_inf.klage` / Klageerhebung | event | `DE.ZPO.253` | `§ 253 ZPO` | HIGH |
+| `20254f4e…` | (orphan) Einspruch gegen Versäumnisurteil | 2 weeks | `DE.ZPO.339.1` | `§ 339 ZPO` | HIGH |
+| `3c36f149…` | (orphan) Schriftsatznachreichung (§ 296a ZPO) | 3 weeks | `DE.ZPO.296a` | `§ 296a ZPO` | HIGH |
+| `f1099cf6…` | (orphan) Weiterbehandlungsantrag (Art. 121 EPÜ) | 2 months | `EU.EPC-R.135.1` | `R. 135 EPÜ` | HIGH |
+| `c24d494c…` | (orphan) Wiedereinsetzungsantrag (§ 123 PatG) | 2 months | `DE.PatG.123.2` | `§ 123 PatG` | HIGH |
+| `d40d9be7…` | (orphan) Wiedereinsetzungsantrag (§ 233 ZPO) | 2 weeks | `DE.ZPO.234.1` | `§ 234 ZPO` | HIGH |
+| `23c6f445…` | (orphan) Wiedereinsetzungsantrag (Art. 122 EPÜ) | 2 months | `EU.EPC-R.136.1` | `R. 136 EPÜ` | HIGH |
+| `b588fa64…` | (orphan) Wiedereinsetzungsantrag (DPMA) | 2 months | `DE.PatG.123.2` | `§ 123 PatG` | HIGH |
+
+**Naming note on the two Wiedereinsetzung-`§ 123 PatG` rows.** Both `c24d494c…` ("§ 123 PatG" name) and `b588fa64…` ("DPMA" name) map to the same statute — § 123 PatG (Wiedereinsetzung) applies to all DPMA-Verfahren, so the duplication is a pure naming choice. mig 097 fills both; potential dedup is a separate question (§ 4 FLAG-A).
+
+---
+
+## 2. Proceeding-typed rows (53)
+
+Grouped by `proceeding_types.code`. Within each group: alphabetical by `code`.
+
+### 2.1 `upc.inf.cfi` — Verletzungsverfahren CFI (4 rules)
+
+| code | name | duration | event_type | proposed `rule_code` | proposed `legal_source` | source-of-truth | conf |
+|---|---|---|---|---|---|---|---|
+| `inf.decision` | Entscheidung | event | decision | *(NULL)* | *(NULL)* | RoP.118 — but this is the court's own decision, not a party deadline | **FLAG-B** |
+| `inf.interim` | Zwischenverfahren | event | hearing | *(NULL)* | *(NULL)* | RoP.101 ff. governs interim procedure; not a single norm | **FLAG-B** |
+| `inf.oral` | Mündliche Verhandlung | event | hearing | *(NULL)* | *(NULL)* | RoP.111-117 (oral procedure); court-scheduled | **FLAG-B** |
+| `inf.soc` | Klageerhebung (Statement of claim) | event | filing | `RoP.013.1` | `UPC.RoP.13.1` | RoP.13 — Statement of claim contents | HIGH |
+
+### 2.2 `upc.rev.cfi` — Nichtigkeitsverfahren CFI (6 rules)
+
+| code | name | duration | event_type | proposed `rule_code` | proposed `legal_source` | source-of-truth | conf |
+|---|---|---|---|---|---|---|---|
+| `rev.app` | Nichtigkeitsklage | event | filing | `RoP.042` | `UPC.RoP.42` | RoP.42 — Statement for revocation | HIGH |
+| `rev.decision` | Entscheidung | event | decision | *(NULL)* | *(NULL)* | court-issued, not a party deadline | **FLAG-B** |
+| `rev.interim` | Zwischenverfahren | event | hearing | *(NULL)* | *(NULL)* | not a single norm | **FLAG-B** |
+| `rev.oral` | Mündliche Verhandlung | event | hearing | *(NULL)* | *(NULL)* | court-scheduled | **FLAG-B** |
+| `rev.reply` | Replik | 2 months | filing | `RoP.052` | `UPC.RoP.52` | RoP.52 — Reply to defence in revocation | MED (**FLAG-C**: duration vs. norm) |
+| `rev.rejoin` | Duplik | 2 months | filing | `RoP.052` | `UPC.RoP.52` | RoP.52 — Rejoinder | MED (**FLAG-C**: duration vs. norm) |
+
+**FLAG-C:** RoP.52(1) sets the reply to 2 months but RoP.52(2) sets the rejoinder to 1 month from service of the reply. m's `rev.rejoin` says 2 months — verify whether the rule duration is correct or whether `RoP.52.2` (1 month) is the right citation. Cross-check with the existing `rev.rejoin_cci` row which uses RoP.056.4 (cci context); the main-pleadings rejoinder lives in RoP.52.
+
+### 2.3 `upc.pi.cfi` — Einstweilige Maßnahmen (4 rules)
+
+All four rules are currently NULL on both fields.
+
+| code | name | duration | event_type | proposed `rule_code` | proposed `legal_source` | source-of-truth | conf |
+|---|---|---|---|---|---|---|---|
+| `pi.app` | Antrag | event | filing | `RoP.206` | `UPC.RoP.206` | RoP.206 — Application for provisional measures | HIGH |
+| `pi.oral` | Mündliche Verhandlung | event | hearing | *(NULL)* | *(NULL)* | RoP.209 — at judge's discretion | **FLAG-B** |
+| `pi.order` | Beschluss | event | decision | *(NULL)* | *(NULL)* | RoP.211 — court-issued | **FLAG-B** |
+| `pi.response` | Erwiderung | event | filing | *(NULL)* | *(NULL)* | RoP.209.1 — judge sets time; no statutory period | **FLAG-B** (alt: `RoP.209.1` / `UPC.RoP.209.1` to flag as court-set) |
+
+### 2.4 `upc.apl.merits` — Berufungsverfahren Merits (3 rules)
+
+| code | name | duration | event_type | proposed `rule_code` | proposed `legal_source` | source-of-truth | conf |
+|---|---|---|---|---|---|---|---|
+| `app.decision` | Entscheidung | event | decision | *(NULL)* | *(NULL)* | RoP.350 — appellate decision | **FLAG-B** |
+| `app.oral` | Mündliche Verhandlung | event | hearing | `RoP.243` | `UPC.RoP.243` | RoP.243 — oral procedure in appeal | MED |
+| `app.response` | Berufungserwiderung | 2 months | filing | `RoP.235.1` | `UPC.RoP.235.1` | RoP.235.1 — Statement of response | MED (**FLAG-C**: RoP.235.1 says 3 months for main-judgment appeals; 2 months may be a residual from a different appeal track. Verify duration vs. norm.) |
+
+### 2.5 `upc.apl.order` — Berufungsverfahren Anordnungen (1 rule)
+
+| code | name | duration | event_type | proposed `rule_code` | proposed `legal_source` | source-of-truth | conf |
+|---|---|---|---|---|---|---|---|
+| `app_ord.order` | Anordnung / angegriffene Entscheidung | event | decision | *(NULL)* | *(NULL)* | trigger event for orders-appeal; RoP.220.1.c references it | **FLAG-B** (alt: `RoP.220.1.c` to surface) |
+
+### 2.6 `upc.apl.cost` — Berufungsverfahren Kosten (1 rule)
+
+| code | name | duration | event_type | proposed `rule_code` | proposed `legal_source` | source-of-truth | conf |
+|---|---|---|---|---|---|---|---|
+| `cost.decision` | Kostenfestsetzungsbeschluss | event | decision | *(NULL)* | *(NULL)* | RoP.150 ff. — cost decision in the assessment proceedings | **FLAG-B** |
+
+### 2.7 `upc.dmgs.cfi` — Schadensbemessungsverfahren (1 rule)
+
+| code | name | duration | event_type | proposed `rule_code` | proposed `legal_source` | source-of-truth | conf |
+|---|---|---|---|---|---|---|---|
+| `damages.app` | Antrag auf Schadensbemessung | event | filing | `RoP.131` | `UPC.RoP.131` | RoP.131 — Application for damages determination | HIGH |
+
+### 2.8 `upc.disc.cfi` — Bucheinsichtsverfahren (1 rule)
+
+| code | name | duration | event_type | proposed `rule_code` | proposed `legal_source` | source-of-truth | conf |
+|---|---|---|---|---|---|---|---|
+| `disc.app` | Antrag auf Bucheinsicht | event | filing | `RoP.141` | `UPC.RoP.141` | RoP.141 — Application for order to lay open books | HIGH |
+
+### 2.9 `de.inf.lg` — Verletzungsverfahren LG (5 rules)
+
+| code | name | duration | event_type | proposed `rule_code` | proposed `legal_source` | source-of-truth | conf |
+|---|---|---|---|---|---|---|---|
+| `de_inf.klage` | Klageerhebung | event | filing | `§ 253 ZPO` | `DE.ZPO.253` *(already set)* | § 253 ZPO — Klageschrift | HIGH (rule_code only) |
+| `de_inf.replik` | Replik | 4 weeks | filing | `§ 273 ZPO` | `DE.ZPO.273` | § 273 ZPO — vorbereitende Anordnungen / court-set period (Düsseldorfer Praxis) | MED (**FLAG-D**: 4 weeks is local LG practice, no statutory period; flag `is_court_set=true` already true in DB) |
+| `de_inf.duplik` | Duplik | 4 weeks | filing | `§ 273 ZPO` | `DE.ZPO.273` | same | MED (**FLAG-D**) |
+| `de_inf.termin` | Haupttermin | event | hearing | *(NULL)* | *(NULL)* | § 272 / § 137 ZPO — court-scheduled | **FLAG-B** |
+| `de_inf.urteil` | Urteil | event | decision | *(NULL)* | *(NULL)* | § 300 ZPO — court-issued | **FLAG-B** |
+
+### 2.10 `de.inf.olg` — Berufungsverfahren OLG Verletzung (3 rules)
+
+| code | name | duration | event_type | proposed `rule_code` | proposed `legal_source` | source-of-truth | conf |
+|---|---|---|---|---|---|---|---|
+| `de_inf_olg.urteil_lg` | Zustellung LG-Urteil | event | filing (trigger) | `§ 317 ZPO` | `DE.ZPO.317` | § 317 ZPO — Zustellung von Urteilen | MED (**FLAG-E**: service-trigger event — may be NULL per philosophy) |
+| `de_inf_olg.termin` | Mündliche Verhandlung | event | hearing | *(NULL)* | *(NULL)* | court-scheduled | **FLAG-B** |
+| `de_inf_olg.urteil_olg` | OLG-Urteil | event | decision | *(NULL)* | *(NULL)* | court-issued | **FLAG-B** |
+
+### 2.11 `de.inf.bgh` — Revision/NZB BGH Verletzung (3 rules)
+
+| code | name | duration | event_type | proposed `rule_code` | proposed `legal_source` | source-of-truth | conf |
+|---|---|---|---|---|---|---|---|
+| `de_inf_bgh.urteil_olg` | Zustellung OLG-Urteil | event | filing (trigger) | `§ 317 ZPO` | `DE.ZPO.317` | § 317 ZPO — Zustellung | MED (**FLAG-E**) |
+| `de_inf_bgh.termin` | Mündliche Verhandlung BGH | event | hearing | *(NULL)* | *(NULL)* | § 555 i.V.m. § 137 ZPO — court-scheduled | **FLAG-B** |
+| `de_inf_bgh.urteil_bgh` | BGH-Urteil | event | decision | *(NULL)* | *(NULL)* | § 562, § 563 ZPO — court-issued | **FLAG-B** |
+
+### 2.12 `de.null.bpatg` — Nichtigkeitsverfahren BPatG (3 rules)
+
+| code | name | duration | event_type | proposed `rule_code` | proposed `legal_source` | source-of-truth | conf |
+|---|---|---|---|---|---|---|---|
+| `de_null.klage` | Nichtigkeitsklage | event | filing | `§ 81 PatG` | `DE.PatG.81.1` | § 81 PatG — Nichtigkeitsklage einreichen | HIGH |
+| `de_null.termin` | Mündliche Verhandlung | event | hearing | *(NULL)* | *(NULL)* | § 89 PatG | **FLAG-B** |
+| `de_null.urteil` | Urteil | event | decision | *(NULL)* | *(NULL)* | § 84 PatG | **FLAG-B** |
+
+### 2.13 `de.null.bgh` — Berufung BGH Nichtigkeit (3 rules)
+
+| code | name | duration | event_type | proposed `rule_code` | proposed `legal_source` | source-of-truth | conf |
+|---|---|---|---|---|---|---|---|
+| `de_null_bgh.urteil_bpatg` | Zustellung BPatG-Urteil | event | filing (trigger) | `§ 99 PatG` | `DE.PatG.99.1` | § 99 PatG verweist auf ZPO; Zustellung der BPatG-Urteile | MED (**FLAG-E**) |
+| `de_null_bgh.termin` | Mündliche Verhandlung BGH | event | hearing | *(NULL)* | *(NULL)* | § 113 PatG i.V.m. ZPO | **FLAG-B** |
+| `de_null_bgh.urteil_bgh` | BGH-Urteil | event | decision | *(NULL)* | *(NULL)* | § 119 PatG | **FLAG-B** |
+
+### 2.14 `dpma.opp.dpma` — Einspruchsverfahren DPMA (2 rules)
+
+| code | name | duration | event_type | proposed `rule_code` | proposed `legal_source` | source-of-truth | conf |
+|---|---|---|---|---|---|---|---|
+| `dpma_opp.publish` | Veröffentlichung der Erteilung | event | filing (trigger) | `§ 58 PatG` | `DE.PatG.58.1` | § 58(1) PatG — Veröffentlichung der Erteilung im Patentblatt | HIGH |
+| `dpma_opp.entscheidung` | DPMA-Entscheidung | event | decision | *(NULL)* | *(NULL)* | § 47 PatG ff. | **FLAG-B** |
+
+### 2.15 `dpma.appeal.bpatg` — Beschwerdeverfahren BPatG vs. DPMA (3 rules)
+
+| code | name | duration | event_type | proposed `rule_code` | proposed `legal_source` | source-of-truth | conf |
+|---|---|---|---|---|---|---|---|
+| `dpma_bpatg.entscheidung` | Zustellung DPMA-Entscheidung | event | filing (trigger) | `§ 47 PatG` | `DE.PatG.47.1` | § 47 PatG — Zustellung der Entscheidung im DPMA-Verfahren | MED (**FLAG-E**: trigger-event citation. Alternative `§ 127 PatG` for service procedure.) |
+| `dpma_bpatg.entsch_bpatg` | BPatG-Entscheidung | event | decision | *(NULL)* | *(NULL)* | § 79 PatG | **FLAG-B** |
+| `dpma_bpatg.termin` | Mündliche Verhandlung BPatG | event | hearing | *(NULL)* | *(NULL)* | § 78 PatG | **FLAG-B** |
+
+### 2.16 `dpma.appeal.bgh` — Rechtsbeschwerdeverfahren BGH (2 rules)
+
+| code | name | duration | event_type | proposed `rule_code` | proposed `legal_source` | source-of-truth | conf |
+|---|---|---|---|---|---|---|---|
+| `dpma_bgh.entsch_bpatg` | Zustellung BPatG-Entscheidung | event | filing (trigger) | `§ 79 PatG` | `DE.PatG.79.1` | § 79 PatG — Zustellung der BPatG-Entscheidung | MED (**FLAG-E**) |
+| `dpma_bgh.entsch_bgh` | BGH-Entscheidung | event | decision | *(NULL)* | *(NULL)* | § 107 PatG | **FLAG-B** |
+
+### 2.17 `epa.grant.exa` — EP-Erteilungsverfahren (3 rules)
+
+| code | name | duration | event_type | proposed `rule_code` | proposed `legal_source` | source-of-truth | conf |
+|---|---|---|---|---|---|---|---|
+| `ep_grant.filing` | Anmeldung | event | filing | `Art. 75 EPÜ` | `EU.EPÜ.75` | Art. 75 EPÜ — Filing of European patent application | HIGH |
+| `ep_grant.search` | Recherchenbericht | 6 months | decision | `Art. 92 EPÜ` | `EU.EPÜ.92` | Art. 92 EPÜ — Drawing up of the European search report | MED (the 6-month figure is a Richtwert per `deadline_notes` — not a statutory deadline. Could also cite `R. 65 EPÜ` if we want the issuance procedure.) |
+| `ep_grant.grant` | Erteilung (B1) | event | decision | `Art. 97 EPÜ` | `EU.EPÜ.97.1` | Art. 97(1) EPÜ — Decision to grant | HIGH |
+
+### 2.18 `epa.opp.opd` — Einspruchsverfahren EPA (2 rules)
+
+| code | name | duration | event_type | proposed `rule_code` | proposed `legal_source` | source-of-truth | conf |
+|---|---|---|---|---|---|---|---|
+| `epa_opp.grant` | Veröffentlichung der Erteilung | event | filing (trigger) | `Art. 97 EPÜ` | `EU.EPÜ.97.3` | Art. 97(3) EPÜ — mention of grant; trigger for the 9-month Einspruchsfrist (Art. 99(1) EPÜ) | HIGH |
+| `epa_opp.entsch` | Entscheidung | event | decision | `Art. 101 EPÜ` | `EU.EPÜ.101` | Art. 101 EPÜ — Decision on opposition | HIGH |
+
+### 2.19 `epa.opp.boa` — Beschwerdeverfahren BoA (3 rules)
+
+| code | name | duration | event_type | proposed `rule_code` | proposed `legal_source` | source-of-truth | conf |
+|---|---|---|---|---|---|---|---|
+| `epa_app.entsch` | Zustellung der Beschwerdeentscheidung | event | filing (trigger) | `R. 111 EPÜ` | `EU.EPC-R.111` | R. 111 EPÜ — Form and notification of decisions | MED (**FLAG-E**: service-trigger citation. Could also cite `Art. 119 EPÜ` for notification.) |
+| `epa_app.oral` | Mündliche Verhandlung | event | hearing | `Art. 116 EPÜ` | `EU.EPÜ.116` | Art. 116 EPÜ — Oral proceedings | HIGH |
+| `epa_app.entsch2` | Entscheidung | event | decision | `Art. 111 EPÜ` | `EU.EPÜ.111` | Art. 111 EPÜ — Decision in respect of appeals | HIGH |
+
+---
+
+## 3. Orphan rows — `proceeding_type_id IS NULL` and `code IS NULL` (77)
+
+Identified by `id` (UUID first 8 chars) + name. These are the older Fristenrechner catalogue rows that pre-date the proceeding-typed slice and were never re-anchored to a proceeding. Many are 1:1 duplicates of rules that now live in proceeding-typed form.
+
+### 3.1 UPC RoP — main-pleadings track (15)
+
+| id8 | name (orphan) | dur | proposed `rule_code` | proposed `legal_source` | source-of-truth | conf | dedup hint |
+|---|---|---|---|---|---|---|---|
+| `e34097d6…` | Klageerwiderung | 3 mo | `RoP.023` | `UPC.RoP.23.1` | RoP.23.1 — Statement of defence | HIGH | dup of `inf.sod` |
+| `7d8a4804…` | Nichtigkeitswiderklage | 3 mo | `RoP.025.1` | `UPC.RoP.25.1` | RoP.25.1 — Counterclaim for revocation | HIGH | — |
+| `c7523e6b…` | Verletzungswiderklage | 2 mo | `RoP.049.2.b` | `UPC.RoP.49.2.b` | RoP.49.2.b — Counterclaim for infringement in revocation | HIGH | dup of `rev.cc_inf` |
+| `c57f62f8…` | Vorgängige Einrede | 1 mo | `RoP.019.1` | `UPC.RoP.19.1` | RoP.19.1 — Preliminary objection | HIGH | dup of `inf.prelim` / `rev.prelim` |
+| `cec1a865…` | Erwiderung Nichtigkeitswiderklage **+** Replik Klageerwiderung | 2 mo | `RoP.029.a` | `UPC.RoP.29.a` | RoP.29.a / .b — combined Defence-to-CCR + Reply to SoD | HIGH (**FLAG-F**: combined-pleading orphan — m to confirm one citation is sufficient or whether row should be split) |
+| `84b390e0…` | Replik auf die Klageerwiderung | 2 mo | `RoP.029.b` | `UPC.RoP.29.b` | RoP.29.b — Reply to defence | HIGH | dup of `inf.reply` |
+| `176cc1ca…` | Duplik zur Replik auf die Klageerwiderung | 1 mo | `RoP.029.c` | `UPC.RoP.29.c` | RoP.29.c — Rejoinder | HIGH | dup of `inf.rejoin` |
+| `02ae9c1f…` | Duplik zur Replik, Replik auf die Erwiderung zum Patentänderungsantrag | 1 mo | `RoP.029.c` | `UPC.RoP.29.c` | combined: RoP.29.c + RoP.32.3 | MED (**FLAG-F**) |
+| `ec2a1274…` | Replik auf Erwiderung Widerklage, Duplik Replik Klageerwiderung, Erwiderung Patentänderungsantrag | 2 mo | `RoP.029.d` | `UPC.RoP.29.d` | combined: RoP.29.d + RoP.29.c + RoP.32.1 | MED (**FLAG-F**: three-norm combined row) |
+| `a32dcec1…` | Erwiderung auf die Nichtigkeitsklage | 2 mo | `RoP.049.1` | `UPC.RoP.49.1` | RoP.49.1 — Defence to revocation | HIGH | dup of `rev.defence` |
+| `37bd034b…` | Replik Erwiderung Nichtigkeitsklage + Erwiderung Patentänderungsantrag + Erwiderung Verletzungswiderklage | 2 mo | `RoP.051` | `UPC.RoP.51` | combined: RoP.51 + RoP.49.2.a-reply + RoP.56.1 | MED (**FLAG-F**) |
+| `1b5c6dee…` | Duplik zur Replik auf die Erwiderung zur Nichtigkeitsklage | 1 mo | `RoP.052` | `UPC.RoP.52` | RoP.52 — Rejoinder in revocation | MED |
+| `bea86f9b…` | Erwiderung auf die Verletzungswiderklage | 2 mo | `RoP.056.1` | `UPC.RoP.56.1` | RoP.56.1 | HIGH | dup of `rev.def_cci` |
+| `4834c957…` | Replik auf die Erwiderung zur Verletzungswiderklage | 1 mo | `RoP.056.3` | `UPC.RoP.56.3` | RoP.56.3 | HIGH | dup of `rev.reply_def_cci` |
+| `7b548c48…` | Duplik (Verletzungswiderklage + Patentänderungsantrag) | 1 mo | `RoP.056.4` | `UPC.RoP.56.4` | combined: RoP.56.4 + RoP.32.3 | MED (**FLAG-F**) |
+
+### 3.2 UPC RoP — Patentänderungs-Track (5)
+
+| id8 | name (orphan) | dur | proposed `rule_code` | proposed `legal_source` | source-of-truth | conf | dedup hint |
+|---|---|---|---|---|---|---|---|
+| `fb7050c6…` | Antrag auf Patentänderung | 2 mo | `RoP.030.1` | `UPC.RoP.30.1` | RoP.30.1 (infringement context) | MED (**FLAG-G**: 2 rows with identical name + 2-month dur; one likely refers to `RoP.30.1` infringement, other to `RoP.49.2.a` revocation) |
+| `21e67ac1…` | Antrag auf Patentänderung | 2 mo | `RoP.049.2.a` | `UPC.RoP.49.2.a` | RoP.49.2.a (revocation context) | MED (**FLAG-G**) |
+| `7e65a434…` | Erwiderung auf den Antrag auf Patentänderung | 2 mo | `RoP.032.1` | `UPC.RoP.32.1` | RoP.32.1 — Defence to application to amend | HIGH | dup of `inf.def_to_amend` |
+| `dfd52792…` | Replik auf die Erwiderung zum Patentänderungsantrag | 1 mo | `RoP.032.3` | `UPC.RoP.32.3` | RoP.32.3 — Reply | HIGH | dup of `inf.reply_def_amd` |
+| `8cdf54eb…` | Duplik zur Replik auf die Erwiderung zum Patentänderungsantrag | 1 mo | `RoP.032.3` | `UPC.RoP.32.3` | RoP.32.3 — Rejoinder | HIGH | dup of `inf.rejoin_amd` |
+
+### 3.3 UPC RoP — appeal track (16)
+
+| id8 | name (orphan) | dur | proposed `rule_code` | proposed `legal_source` | source-of-truth | conf | dedup hint |
+|---|---|---|---|---|---|---|---|
+| `1dfba5b1…` | Berufungsschrift gegen Entscheidung nach R. 220.1(a)/(b) | 2 mo | `RoP.224.1.a` | `UPC.RoP.224.1.a` | RoP.224.1.a — Notice of appeal, main-judgment track | HIGH | dup of `app.notice` |
+| `5c0508f4…` | Berufungsschrift gegen Entscheidung nach R. 220.1(a)/(b) | 2 mo | `RoP.224.1.a` | `UPC.RoP.224.1.a` | same | HIGH | duplicate-of-duplicate (**FLAG-A**) |
+| `d560b3b6…` | Berufungsschrift gegen Anordnung R. 220.1(c) / R. 220.2 / 221.3 | 15 d | `RoP.224.1.b` | `UPC.RoP.224.1.b` | RoP.224.1.b — Notice of appeal, orders/leave track | HIGH | dup of `app_ord.with_leave`-family |
+| `791fd0f7…` | Berufungsbegründung Entscheidung R. 220.1(a)/(b) | 4 mo | `RoP.225.1` | `UPC.RoP.225.1` | RoP.225.1 — Statement of grounds, main track | HIGH | dup of `app.grounds` |
+| `573df3d1…` | Berufungsbegründung Entscheidung R. 220.1(a)/(b) | 4 mo | `RoP.225.1` | `UPC.RoP.225.1` | same | HIGH | duplicate-of-duplicate (**FLAG-A**) |
+| `c3a369f9…` | Berufungsbegründung Anordnung R. 220.1(c) / R. 220.2 / 221.3 | 15 d | `RoP.225.2` | `UPC.RoP.225.2` | RoP.225.2 — Statement of grounds, orders/leave | MED (**FLAG-H**: RoP.225.2 form; verify 15d figure aligns with current RoP version) |
+| `91e367dd…` | Berufung (Anordnungen & mit Zulassung) | 15 d | `RoP.224.1.b` | `UPC.RoP.224.1.b` | same | MED | dup of `app_ord.with_leave` |
+| `ccb916df…` | Antrag auf Berufungszulassung gegen Kostenentscheidungen | 15 d | `RoP.221.1` | `UPC.RoP.221.1` | RoP.221.1 — Leave to appeal cost decisions | HIGH | dup of `cost.leave_app` |
+| `342e749d…` | Antrag auf Ermessensüberprüfung | 15 d | `RoP.220.3` | `UPC.RoP.220.3` | RoP.220.3 — Discretionary review | HIGH | dup of `app_ord.discretion` |
+| `d4f739cd…` | Anfechtung einer Entscheidung über Verwerfung der Berufung als unzulässig | 1 mo | `RoP.234.1` | `UPC.RoP.234.1` | RoP.234 — Inadmissibility of appeal review | MED (**FLAG-H**: confirm sub-paragraph; RoP.234 governs the topic but the 1-month review window may sit elsewhere) |
+| `10374392…` | Berufungserwiderung (zur Berufung nach R. 224.2(a)) | 3 mo | `RoP.235.1` | `UPC.RoP.235.1` | RoP.235.1 — Statement of response, main track | HIGH |
+| `4c585c6d…` | Berufungserwiderung (zur Berufung nach R. 224.2(b)) | 15 d | `RoP.235.4` | `UPC.RoP.235.4` | RoP.235.4 — Statement of response, orders/leave track | MED (**FLAG-H**: confirm RoP.235.4 vs. RoP.235.2 in current RoP version) |
+| `6e39b653…` | Anschlussberufungsschrift (zur Berufung R. 224.2(a)) | 3 mo | `RoP.237.1` | `UPC.RoP.237.1` | RoP.237.1 — Cross-appeal | HIGH |
+| `a00e51bb…` | Anschlussberufungsschrift (zur Berufung R. 224.2(b)) | 15 d | `RoP.237.2` | `UPC.RoP.237.2` | RoP.237 — Cross-appeal in orders track | MED (**FLAG-H**) |
+| `6b989e85…` | Erwiderung auf Anschlussberufungsschrift (R. 224.2(a)) | 2 mo | `RoP.238.1` | `UPC.RoP.238.1` | RoP.238.1 — Reply to cross-appeal | HIGH | dup of `app.cross_a_reply` |
+| `e78f4652…` | Erwiderung auf Anschlussberufungsschrift (R. 224.2(b)) | 15 d | `RoP.238.2` | `UPC.RoP.238.2` | RoP.238.2 — Reply to cross-appeal, orders track | HIGH | dup of `app_ord.cross_reply` |
+
+### 3.4 UPC RoP — Schadensbemessung / Rechnungslegung (7)
+
+| id8 | name (orphan) | dur | proposed `rule_code` | proposed `legal_source` | source-of-truth | conf | dedup hint |
+|---|---|---|---|---|---|---|---|
+| `d414f603…` | Erwiderung Antrag auf Schadensersatzbemessung | 2 mo | `RoP.137.2` | `UPC.RoP.137.2` | RoP.137.2 | HIGH | dup of `damages.defence` |
+| `9f39e263…` | Replik Erwiderung Schadensersatzbemessung | 1 mo | `RoP.139` | `UPC.RoP.139` | RoP.139 | HIGH | dup of `damages.reply` |
+| `067ffdf0…` | Duplik Replik Schadensersatzbemessung | 1 mo | `RoP.139` | `UPC.RoP.139` | RoP.139 | HIGH | dup of `damages.rejoin` |
+| `429b8ec0…` | Erwiderung Antrag auf Rechnungslegung | 2 mo | `RoP.142.2` | `UPC.RoP.142.2` | RoP.142.2 — Defence in account procedure | HIGH | dup of `disc.defence` |
+| `8d36fc76…` | Replik Erwiderung Rechnungslegung | 14 d | `RoP.142.3` | `UPC.RoP.142.3` | RoP.142.3 | HIGH | dup of `disc.reply` |
+| `ed82fec9…` | Duplik Replik Erwiderung Rechnungslegung | 14 d | `RoP.142.3` | `UPC.RoP.142.3` | RoP.142.3 | HIGH | dup of `disc.rejoin` |
+| `eed69e8b…` | Antrag auf Kostenentscheidung | 1 mo | `RoP.151` | `UPC.RoP.151` | RoP.151 — Application for cost decision | HIGH | dup of `inf.cost_app` |
+
+### 3.5 UPC RoP — provisional / PI (6)
+
+| id8 | name (orphan) | dur | proposed `rule_code` | proposed `legal_source` | source-of-truth | conf |
+|---|---|---|---|---|---|---|
+| `ba335c99…` | Beginn des Hauptsacheverfahrens | 31 d | `RoP.213.1` | `UPC.RoP.213.1` | RoP.213.1 — 31 days or 20 working days after PI granted | HIGH |
+| `d886f46f…` | Beginn des Hauptsacheverfahrens | 31 d | `RoP.213.1` | `UPC.RoP.213.1` | same — duplicate row (**FLAG-A**) | HIGH |
+| `1f1f72ef…` | Antrag auf Überprüfung der Beweissicherungsanordnung | 30 d | `RoP.197.3` | `UPC.RoP.197.3` | RoP.197.3 — Review of evidence preservation order | HIGH |
+| `3e2f5697…` | Erneuerung der Schutzschrift | 6 mo | `RoP.207.9` | `UPC.RoP.207.9` | RoP.207.9 — Protective letter, 6-month validity | HIGH |
+
+### 3.6 UPC RoP — feststellungs / Widerruf-Track (4)
+
+| id8 | name (orphan) | dur | proposed `rule_code` | proposed `legal_source` | source-of-truth | conf |
+|---|---|---|---|---|---|---|
+| `521bf607…` | Erwiderung auf negative Feststellungsklage | 2 mo | *(NULL)* | *(NULL)* | UPC declaration of non-infringement procedure follows RoP.49 ff. by analogy (RoP.69 references) | **FLAG-I**: negative declaration track has no single statutory norm; cite either `RoP.069` / `UPC.RoP.69` (general procedure) or leave NULL pending m's call |
+| `e887b1fb…` | Replik Erwiderung negative Feststellungsklage | 1 mo | *(NULL)* | *(NULL)* | same | **FLAG-I** |
+| `0cf1d755…` | Duplik Replik Erwiderung negative Feststellungsklage | 1 mo | *(NULL)* | *(NULL)* | same | **FLAG-I** |
+
+### 3.7 UPC RoP — formalities / Registry (14)
+
+| id8 | name (orphan) | dur | proposed `rule_code` | proposed `legal_source` | source-of-truth | conf |
+|---|---|---|---|---|---|---|
+| `d058f412…` | Mängelbeseitigung / Zahlung | 14 d | `RoP.016.4` | `UPC.RoP.16.4` | RoP.16.4 — Notice to remedy defects | HIGH |
+| `c690c323…` | Mängelbeseitigung / Zahlung | 14 d | `RoP.016.4` | `UPC.RoP.16.4` | same — duplicate (**FLAG-A**) | HIGH |
+| `5f2884a4…` | Mängelbeseitigung / Zahlung | 14 d | `RoP.016.4` | `UPC.RoP.16.4` | duplicate (**FLAG-A**) | HIGH |
+| `13600049…` | Mängelbeseitigung / Zahlung | 14 d | `RoP.016.4` | `UPC.RoP.16.4` | duplicate (**FLAG-A**) | HIGH |
+| `ceb780ba…` | Mängelbeseitigung / Zahlung | 14 d | `RoP.016.4` | `UPC.RoP.16.4` | duplicate (**FLAG-A**) | HIGH |
+| `d51c50eb…` | Mängelbeseitigung / Zahlung | 14 d | `RoP.016.4` | `UPC.RoP.16.4` | duplicate (**FLAG-A**) | HIGH |
+| `3bc40027…` | Mängelbeseitigung / Einreichung schriftlicher Stellungnahme | 14 d | `RoP.016.5` | `UPC.RoP.16.5` | RoP.16.5 — Written observations after Registry notice | MED |
+| `69e356b7…` | Antrag auf Vertraulichkeit gegenüber der Öffentlichkeit | 14 d | `RoP.262.2` | `UPC.RoP.262.2` | RoP.262.2 — Confidentiality vis-à-vis public (note in DB confirms) | HIGH |
+| `57e6eeca…` | Berichtigung von Entscheidungen und Anordnungen | 1 mo | `RoP.353` | `UPC.RoP.353` | RoP.353 — Rectification of decisions/orders | HIGH |
+| `8ec233b9…` | Antrag auf Überprüfung verfahrensleitender Anordnung | 15 d | `RoP.333.1` | `UPC.RoP.333.1` | RoP.333.1 — Review of procedural order | HIGH |
+| `d124c95b…` | Antrag auf Aufhebung oder Änderung Entscheidung des Amtes | 1 mo | *(NULL)* | *(NULL)* | unclear which Amts-Entscheidung this targets — Registry order? Unitary-effect refusal? | **FLAG-J** (recommend NULL; ask m what proceeding-context this row maps to) |
+| `0531b6ba…` | Antrag auf Aufhebung Entscheidung EPA über einheitliche Wirkung | 3 wk | `RoP.097.1` | `UPC.RoP.97.1` | RoP.97.1 — Action against EPO decision on unitary effect | MED (**FLAG-H**: verify 3-week period vs. norm; current RoP gives 1 month for such applications under R.88 EPÜ-UPC; possibly outdated) |
+| `6b6b967c…` | Antrag auf Verweisung an die Zentralkammer | 10 d | `RoP.037.4` | `UPC.RoP.37.4` | RoP.37 governs division apportionment; .4 is the 10-day observation period | MED (**FLAG-H**: confirm sub-paragraph) |
+| `002c2ba7…` | Antrag auf Folgemaßnahmen rechtskräftiger Validitätsentscheidung | 2 mo | *(NULL)* | *(NULL)* | likely refers to post-revocation register-correction request; norm uncertain | **FLAG-J** |
+
+### 3.8 UPC RoP — translation / interpretation (3)
+
+| id8 | name (orphan) | dur | proposed `rule_code` | proposed `legal_source` | source-of-truth | conf |
+|---|---|---|---|---|---|---|
+| `bb7bafcb…` | Antrag auf Simultanübersetzung | 1 mo (before) | `RoP.109.1` | `UPC.RoP.109.1` | RoP.109.1 — Request for simultaneous interpretation | HIGH |
+| `8c682cff…` | Mitteilung über Beauftragung eines Dolmetschers auf Kosten der Partei | 2 wk (before) | `RoP.109.5` | `UPC.RoP.109.5` | RoP.109.5 — Notice of own-cost interpreter | MED (**FLAG-H**: confirm sub-paragraph; RoP.109 governs interpretation but the specific 2-week notice rule may sit at .4 or .5) |
+| `9ed513c1…` | Einreichung von Übersetzungen von Schriftstücken | 1 mo | `RoP.007.2` | `UPC.RoP.7.2` | RoP.7.2 — Language of documents | MED (**FLAG-H**: alternative `RoP.7.4` for translations of party-submitted documents) |
+| `902cc5d5…` | Klärung von Übersetzungsfragen | 2 wk | *(NULL)* | *(NULL)* | unclear which "Übersetzungsfrage" rule | **FLAG-J** |
+
+### 3.9 UPC RoP — review / rehearing (2)
+
+| id8 | name (orphan) | dur | proposed `rule_code` | proposed `legal_source` | source-of-truth | conf |
+|---|---|---|---|---|---|---|
+| `372e86e3…` | Antrag auf Wiederaufnahme (schwerwiegender Verfahrensmangel) | 2 mo | `RoP.247.2` | `UPC.RoP.247.2` | RoP.247.2 — Application for rehearing within 2 months | HIGH |
+| `58de9573…` | Antrag auf Wiederaufnahme (Straftat) | 2 mo | `RoP.247.2` | `UPC.RoP.247.2` | RoP.247.1(b) substantively (criminal act ground); RoP.247.2 for the 2-month period | HIGH |
+
+### 3.10 Already-cited orphans (covered in § 1 Easy wins, 7 rows)
+
+`20254f4e…`, `3c36f149…`, `f1099cf6…`, `c24d494c…`, `d40d9be7…`, `23c6f445…`, `b588fa64…` — see § 1.
+
+---
+
+## 4. FLAG summary — items needing m's call
+
+| FLAG | Topic | Count | Decision needed |
+|---|---|---|---|
+| **A** | Genuine duplicate orphan rows (same name + dur + citation) | ~10 | Confirm the dedup pass should happen in mig 097 (or a follow-up). Recommended: leave duplicates in place for mig 097 (fills all of them with the same citation); dedup separately so the rule-resolution semantics don't drift. |
+| **B** | Court-scheduled / court-issued event rows (Mündliche Verhandlung, Urteil, Entscheidung) | ~22 | Confirm NULL is the right default. Alternative: cite the framing norm with a "context" note. |
+| **C** | UPC RoP duration vs. norm mismatch (`rev.reply` / `rev.rejoin` / `app.response`) | 3 | Verify the rule durations are correct as stored — proposed citations are canonical but rule duration may be from an older RoP version. |
+| **D** | German LG patent practice: 4-week replik/duplik (court-set) | 2 | Confirm `§ 273 ZPO` is the cite m wants (no statutory period, framing norm only). |
+| **E** | Service / trigger-event citations (`§ 317 ZPO`, `R. 111 EPÜ` etc.) | 6 | These are anchor-events for downstream timers, not deadlines. Confirm whether to cite (current proposal) or leave NULL. |
+| **F** | Combined-pleading orphan rows (one row = several norms) | 5 | Confirm one citation is acceptable, or whether the rows should be split before mig 097 (out of scope here). |
+| **G** | Twin "Antrag auf Patentänderung" orphans (2-mo, identical name) | 2 | Confirm one is infringement-context (`RoP.30.1`), the other revocation-context (`RoP.49.2.a`). |
+| **H** | RoP sub-paragraph uncertainty (current text vs. older version) | ~8 | Spot-check against current published RoP; my citations are canonical but small `.x` numbers may need a tweak. |
+| **I** | Negative-declaration track (no single UPC norm) | 3 | Confirm citing `RoP.69` (procedure-by-analogy) vs. leaving NULL. |
+| **J** | Orphan with unclear scope | 3 | `d124c95b…` (Aufhebung Entscheidung des Amtes), `002c2ba7…` (Folgemaßnahmen Validitätsentscheidung), `902cc5d5…` (Klärung Übersetzungsfragen). m to identify which UPC norm. |
+
+---
+
+## 5. Side-fix (recommend bundled in mig 097)
+
+**RoP-display normalization**: `rev.defence` currently carries `rule_code = "RoP.49.1"`. All other RoP rules under 100 use 3-digit padding (`RoP.029.a`, `RoP.049.2.a` etc.). mig 097 should normalize `RoP.49.1 → RoP.049.1` in that one row, while filling the 130 NULL rows with consistently padded values.
+
+```sql
+-- side-fix candidate
+UPDATE paliad.deadline_rules
+   SET rule_code = 'RoP.049.1'
+ WHERE rule_code = 'RoP.49.1'
+   AND code      = 'rev.defence';   -- only one row; idempotent
+```
+
+This is opt-in; m to confirm before mig 097 ships.
+
+---
+
+## 6. Migration 097 hints (for the coder who writes it)
+
+**Shape m has asked for:**
+
+- `UPDATE paliad.deadline_rules SET rule_code = …, legal_source = … WHERE id = … AND rule_code IS NULL AND legal_source IS [NULL|expected];`
+- Idempotent: `WHERE rule_code IS NULL` (or `IS DISTINCT FROM`) guard so re-applying is a no-op.
+- Backup snapshot: `CREATE TABLE paliad.deadline_rules_pre_097 AS SELECT * FROM paliad.deadline_rules` before any UPDATEs.
+- Wrap in `audit_reason = 't-paliad-208 legal-citation backfill'` (matches `paliad.audit_log` pattern used elsewhere).
+- Touch only the m-approved rows from § 1, § 2, § 3 — FLAG rows (those with `*(NULL)*` in the proposed columns) stay untouched until m resolves them.
+- Side-fix § 5 (`RoP.49.1 → RoP.049.1`) only if m confirms.
+
+**Counts the migration should match (assuming m approves all HIGH proposals as-is):**
+
+- Easy wins (§ 1): 8 `rule_code` UPDATEs (legal_source already set)
+- Proceeding-typed HIGH/MED proposals (§ 2): ~25 rows
+- Orphan HIGH/MED proposals (§ 3): ~50 rows
+- Total expected `rule_code` writes: ~83 rows
+- Total expected `legal_source` writes: ~75 rows (8 of the easy wins already have one)
+- FLAG rows left NULL: ~47 rows pending m's decisions
+
+---
+
+## 7. Open questions for m
+
+1. **NULL for event-markers (FLAG-B):** confirm NULL is correct for the 22 court-scheduled / court-issued event rows. If m wants citations there too, I'll do a second pass.
+2. **Trigger-event citations (FLAG-E):** apply `§ 317 ZPO` to LG/OLG service rows, or leave NULL?
+3. **Duplicates (FLAG-A):** mig 097 fills duplicates with the same citation; do you want a separate dedup pass scheduled (filing `t-paliad-21x`) or is the duplicate count acceptable for now?
+4. **Combined-pleading orphans (FLAG-F):** keep one citation per row, or split each row into N rows before mig 097?
+5. **Negative-declaration track (FLAG-I):** cite `RoP.69` by analogy, or leave NULL?
+6. **Side-fix (§ 5):** normalize the one `RoP.49.1` outlier as part of mig 097?
+
+Once m answers, head can re-task this same worker (or a fresh coder) to write mig 097 against the approved proposals.

docs/proposals/orphan-concepts-2026-05-15.md

@@ -0,0 +1,577 @@
+# Orphan Concept Seed Proposals — Fristen Phase 3 Slice 12 (t-paliad-196)
+
+**Date:** 2026-05-15
+**Author:** curie (researcher)
+**Status:** DRAFT — for m's review, not yet ingested via `/admin/rules`
+**Branch:** `mai/curie/fristen-phase-3-slice-12`
+**Source audit:** `docs/audit-fristen-logic-2026-05-13.md` § 3.4 + § 7.9 (pauli)
+
+---
+
+## 0. Read-this-first — orphan count discrepancy
+
+m's task description (and pauli's audit dated 2026-05-13) cited **nine** orphan concepts with `rule_count=0`. Today's live `paliad` DB shows **five**:
+
+| # | Slug | Party | Category |
+|---|------|-------|----------|
+| 1 | `wiedereinsetzung` | both | submission |
+| 2 | `schriftsatznachreichung` | both | submission |
+| 3 | `versaeumnisurteil-einspruch` | defendant | submission |
+| 4 | `weiterbehandlung` | claimant | submission |
+| 5 | `counterclaim-for-revocation` | defendant | submission |
+
+Four of the audit's nine were almost certainly seeded between 2026-05-13 and 2026-05-15 by Slice 10 (migration 090, fuzzy backfill) and the Slice-11 admin rule-editor work. `notice-of-defence-intention` is one of them: today's `DE_INF` corpus contains `de_inf.anzeige` (Anzeige der Verteidigungsbereitschaft, ZPO §276.1) linked to its own concept, which removes it from the orphan list.
+
+**FLAG (count discrepancy):** I drafted proposals for the **5** remaining orphans, not 9. m should confirm whether the other 4 audit-named concepts were intentionally seeded or whether something else is going on before treating this as "done".
+
+### 0.1 A second, more important framing problem
+
+The orphan query `deadline_concepts.id NOT IN (SELECT concept_id FROM deadline_rules)` counts only **direct** `concept_id` linkages on `paliad.deadline_rules`. But the schema has two alternate rooting columns: `proceeding_type_id` (Pipeline A) and `trigger_event_id` (Pipeline C). The Pipeline-C migration (Slice 4, m/paliad#…) imported 77 event-rooted rules from `paliad.event_deadlines` but left their `concept_id` **NULL** on the unified `deadline_rules` table — even when the source trigger event had a matching `concept_id` slug already set on `paliad.trigger_events`.
+
+Concretely, the following rules **already exist** in `paliad.deadline_rules` but lack `concept_id`:
+
+| Rule name | `trigger_event_id` | Trigger event code | Owning concept (via `trigger_events.concept_id` slug) |
+|---|---|---|---|
+| Wiedereinsetzungsantrag (§ 123 PatG) | 200 | `wegfall_hindernisses_de_patg` | `wiedereinsetzung` |
+| Wiedereinsetzungsantrag (§ 233 ZPO) | 201 | `wegfall_hindernisses_de_zpo` | `wiedereinsetzung` |
+| Wiedereinsetzungsantrag (Art. 122 EPÜ) | 202 | `wegfall_hindernisses_eu_epc` | `wiedereinsetzung` |
+| Wiedereinsetzungsantrag (DPMA) | 203 | `wegfall_hindernisses_dpma` | `wiedereinsetzung` |
+| Einspruch gegen Versäumnisurteil (§ 339 ZPO) | 204 | `zustellung_versaeumnisurteil` | `versaeumnisurteil-einspruch` |
+| Schriftsatznachreichung (§ 296a ZPO) | 205 | `ende_muendl_verhandlung` | `schriftsatznachreichung` |
+| Weiterbehandlungsantrag (Art. 121 EPÜ) | 206 | `mitteilung_rechtsverlust_eu` | `weiterbehandlung` |
+| *(none yet)* | 207 | `wegfall_hindernisses_upc` | `wiedereinsetzung` |
+
+**Net effect:** four of the five "orphan" concepts already have at least one workable rule — it is just disconnected from the concept by a NULL `concept_id`. The genuine coverage gap is much smaller than "5 concepts × ~5 rules each = 25 rules to draft". Practical Phase-3-Slice-12 work splits into:
+
+- **Track A (linkage, no legal review needed):** `UPDATE paliad.deadline_rules SET concept_id = … WHERE trigger_event_id IN (200,201,202,203,204,205,206)`. 7 rows, zero new legal substance. See § 6 of this doc.
+- **Track B (new rule drafts, this doc's main body):** UPC R.320 Wiedereinsetzung (`trigger_event_id=207` truly has no rule yet), proceeding-rooted variants for the four jurisdictions where having a rule under the UPC_INF / DE_INF / EPA_OPP / DPMA_OPP umbrella makes the cascade complete, plus the schema-correct way to resolve `counterclaim-for-revocation` (which is intentionally encoded as flag-gated UPC_INF rules and probably should not get fresh rules at all).
+
+**FLAG (audit framing):** I recommend the orphan KPI be redefined as "concepts where NO rule references the concept, **directly via `deadline_rules.concept_id` OR transitively via `deadline_rules.trigger_event_id → trigger_events.concept_id`**". Until that happens, the orphan list will keep over-reporting work that has already been done in another column. The Phase 2 design (`docs/design-fristen-phase2-2026-05-15.md` § 3 Step C) anticipates dropping the `paliad.trigger_events` table entirely in Slice 9 and copying `concept_id` onto `deadline_rules` at that point — once that migration runs, the discrepancy resolves itself.
+
+### 0.2 Convention notes
+
+- Rule **code** column (`paliad.deadline_rules.code`) uses `<proceeding_short>.<action>` for proceeding-rooted rules (e.g. `inf.sod`, `de_inf.berufung`). For event-rooted rules `code` is NULL today; I follow that pattern.
+- **Anchor semantics** (audit § 4): `parent_id NULL + duration_value=0` = root anchor / court-set absolute. `parent_id NULL + duration_value>0 + trigger_event_id` = event-rooted, anchored to the trigger event's date. `parent_id NOT NULL` = chained off another rule.
+- **Priority values** (post-Slice-3): `mandatory` | `recommended` | `optional` | `informational`. Wiedereinsetzung-class rules are conceptually `optional` for the user (they may decide not to file), but the legal-source side is mandatory once invoked. I tag them `optional` with the legal source making the obligation conditional — m to confirm.
+- **`is_court_set`** is true when the deadline date is set by court order rather than computed from a statutory period. For Schriftsatznachreichung this is the relevant case; for Wiedereinsetzung/Weiterbehandlung it's false (statutory period).
+- **`legal_source`** uses the existing convention seen on live rules (`UPC.RoP.29.a`, `DE.ZPO.234.1`, `EU.EPC-R.135.1`, `EU.EPÜ.99.1`).
+
+---
+
+## 1. Concept: `wiedereinsetzung` (Wiedereinsetzung in den vorigen Stand)
+
+**Concept ID:** `00b737bf-58a6-4f41-9650-ac3f2e7079e8`
+**Party:** both · **Category:** submission
+**Linked event_categories (cascade leaves):**
+- `cms-eingang.gericht.rechtsverlust-epa` (Mitteilung über Rechtsverlust, EPA)
+- `frist-verpasst.de-patg` (DE Patentverfahren, PatG §123)
+- `frist-verpasst.de-zpo` (DE Zivilverfahren, ZPO §233)
+- `frist-verpasst.dpma` (DPMA, PatG §123)
+- `frist-verpasst.epa` (EPA, Art. 122 EPÜ)
+- `frist-verpasst.upc` (UPC, R.320 RoP)
+
+**Existing trigger-event-rooted rules:** trigger events 200/201/202/203 already have rules in `paliad.deadline_rules` (DE PatG, DE ZPO, EPC, DPMA respectively). Only te 207 (UPC R.320) has no rule yet. See § 6 for the linkage UPDATE that brings the existing four into the concept's rule list.
+
+**Drafts below:**
+
+### Rule 1.1 — UPC R.320 Wiedereinsetzungsantrag
+
+- **Rule code:** `upc.wiedereinsetzung` *(proceeding-rooted) ORalt. NULL code + `trigger_event_id=207` (event-rooted, matches pattern of te 200-206 rules)*
+- **Proceeding type:** UPC_INF (id=8) — primary. Also relevant for UPC_REV (9), UPC_PI (10), UPC_APP (11), UPC_DAMAGES (17), UPC_DISCOVERY (18), UPC_COST_APPEAL (19), UPC_APP_ORDERS (20). **FLAG:** Wiedereinsetzung applies across the full UPC corpus; m to decide whether to (a) seed one event-rooted rule referencing te 207 — pattern matches the existing four jurisdictions — or (b) seed seven proceeding-rooted clones. Recommend (a): cleaner, mirrors the pattern already set for DE/EPC/DPMA, and Slice 9's table-drop migration in Phase 2 will canonicalise it.
+- **Name (DE):** Wiedereinsetzungsantrag (R. 320 RoP UPC)
+- **Name (EN):** Application for re-establishment of rights (UPC R.320 RoP)
+- **Party:** both (claimant or defendant, whoever missed)
+- **Anchor:** `trigger_event_id = 207` (`wegfall_hindernisses_upc`)
+- **Duration:** 2, months
+- **Timing:** after
+- **Priority:** optional *(filing is at the party's discretion — see § 0.2)*
+- **is_court_set:** false
+- **condition_expr:** NULL
+- **Legal source:** `UPC.RoP.320.1`
+- **Notes:** UPC R.320.1 sets a 2-month window from removal of the cause of non-compliance, capped by an absolute 1-year limit from expiry of the missed period (see Rule 1.2 below). The omitted act must be completed within the same 2-month window (R.320.2). Court fee per R.150(1)(p). UI may want to show the 1-year backstop as a sibling "Achtung" line; that is a renderer decision, not a separate rule.
+
+### Rule 1.2 — UPC R.320 — 1-Jahres-Ausschlussfrist (informational)
+
+- **Rule code:** `upc.wiedereinsetzung.cutoff` (or trigger-rooted with a sibling `sequence_order` after Rule 1.1)
+- **Proceeding type:** same as Rule 1.1
+- **Name (DE):** Absolute Ausschlussfrist Wiedereinsetzung (1 Jahr)
+- **Name (EN):** Absolute cut-off for re-establishment (1 year)
+- **Party:** both
+- **Anchor:** the **missed** deadline's date — not `wegfall_hindernisses_upc`. **FLAG:** Today's `trigger_events` model can't express "anchor = the missed deadline" because the trigger fires on removal of cause, not on the missed deadline. Either (a) add a new trigger event `frist_versaeumt_upc` and root this rule there, or (b) make this an `informational` UI-only rule rendered by the renderer next to Rule 1.1 with no real anchor. Recommend (b) for now; (a) is a Phase-3 schema follow-up.
+- **Duration:** 12, months
+- **Timing:** after
+- **Priority:** informational
+- **is_court_set:** false
+- **condition_expr:** NULL
+- **Legal source:** `UPC.RoP.320.1` (second half: "but at the latest within one year of the expiry of the unobserved time limit")
+- **Notes:** Cosmetically important — practitioners forget the cut-off. Keep as informational rendering until the schema supports two-anchor rules.
+
+### Rule 1.3 — EPC Art. 122 / R.136 Wiedereinsetzungsantrag (EPA)
+
+- **Rule code:** *(event-rooted; NULL `code`, matches existing pattern for te 200-203)*
+- **Proceeding type:** NULL (or EPA_OPP=14 / EPA_APP=15 / EP_GRANT=16 if proceeding-rooted)
+- **Name (DE):** Wiedereinsetzungsantrag (Art. 122 EPÜ)
+- **Name (EN):** Petition for re-establishment of rights (EPC Art.122)
+- **Party:** both
+- **Anchor:** `trigger_event_id = 202` (`wegfall_hindernisses_eu_epc`)
+- **Duration:** 2, months
+- **Timing:** after
+- **Priority:** optional
+- **is_court_set:** false
+- **condition_expr:** NULL
+- **Legal source:** `EU.EPC-R.136.1`
+- **Notes:** **DUPLICATE of existing rule** `23c6f445-4ed2-4ade-8ea0-c4ab6b364bb6` — already in `deadline_rules`, just missing `concept_id`. See § 6 linkage UPDATE; do not double-seed.
+
+### Rule 1.4 — EPC R.136 — 1-Jahres-Ausschlussfrist
+
+- **Rule code:** as Rule 1.2 pattern
+- **Name (DE):** Absolute Ausschlussfrist Wiedereinsetzung EPA (1 Jahr)
+- **Name (EN):** Absolute cut-off for re-establishment, EPC (1 year)
+- **Party:** both
+- **Anchor:** missed-deadline date (same FLAG as Rule 1.2 — schema follow-up)
+- **Duration:** 12, months
+- **Timing:** after
+- **Priority:** informational
+- **is_court_set:** false
+- **condition_expr:** NULL
+- **Legal source:** `EU.EPC-R.136.1` (second sentence)
+- **Notes:** R.136(1) third sentence carves out a special **2-month** cut-off for restoration of priority (Art. 87(1) in conjunction with R.136(1)). m may want a separate rule 1.4b for that priority variant; flagging rather than auto-resolving.
+
+### Rule 1.5 — DE PatG §123 Wiedereinsetzungsantrag (DPMA + national)
+
+- **Rule code:** event-rooted, te=200 (PatG) and te=203 (DPMA)
+- **Name (DE):** Wiedereinsetzungsantrag (§ 123 PatG)
+- **Name (EN):** Petition for re-establishment of rights (PatG §123)
+- **Party:** both
+- **Anchor:** `trigger_event_id = 200` (`wegfall_hindernisses_de_patg`) — for general DE PatG context — AND `trigger_event_id = 203` (`wegfall_hindernisses_dpma`) — for DPMA-specific context.
+- **Duration:** 2, months
+- **Timing:** after
+- **Priority:** optional
+- **is_court_set:** false
+- **condition_expr:** NULL
+- **Legal source:** `DE.PatG.123.2`
+- **Notes:** **DUPLICATE of existing rules** `c24d494c-…` (te 200) and `b588fa64-…` (te 203). Linkage only — see § 6.
+
+### Rule 1.6 — DE PatG §123 — 1-Jahres-Ausschlussfrist
+
+- **Rule code:** as 1.2/1.4 pattern (informational)
+- **Name (DE):** Absolute Ausschlussfrist Wiedereinsetzung PatG (1 Jahr)
+- **Name (EN):** Absolute cut-off for re-establishment, PatG (1 year)
+- **Party:** both
+- **Anchor:** missed-deadline date (schema FLAG as 1.2)
+- **Duration:** 12, months
+- **Timing:** after
+- **Priority:** informational
+- **is_court_set:** false
+- **condition_expr:** NULL
+- **Legal source:** `DE.PatG.123.2` (Satz 4)
+- **Notes:** PatG §123(2) Satz 4: "Innerhalb eines Jahres nach Ablauf der versäumten Frist ist keine Wiedereinsetzung mehr möglich." Same as PatG also for DPMA proceedings.
+
+### Rule 1.7 — DE ZPO §233 Wiedereinsetzungsantrag (Notfrist, 2 Wochen)
+
+- **Rule code:** event-rooted, te=201
+- **Name (DE):** Wiedereinsetzungsantrag — Notfrist (§ 234 Abs. 1 S. 1 ZPO)
+- **Name (EN):** Petition for re-establishment of rights — Notfrist (ZPO §234(1) sentence 1)
+- **Party:** both
+- **Anchor:** `trigger_event_id = 201` (`wegfall_hindernisses_de_zpo`)
+- **Duration:** 2, weeks
+- **Timing:** after
+- **Priority:** optional
+- **is_court_set:** false
+- **condition_expr:** NULL — but see Rule 1.8 for the 1-month variant.
+- **Legal source:** `DE.ZPO.234.1`
+- **Notes:** **DUPLICATE of existing rule** `d40d9be7-…` — linkage only. ZPO §234(1) sentence 1: 2 weeks for Notfristen (Berufungsfrist, Revisionsfrist, Beschwerdefrist, etc.).
+
+### Rule 1.8 — DE ZPO §234(1)2 Wiedereinsetzungsantrag (Begründungsfrist, 1 Monat)
+
+- **Rule code:** event-rooted, te=201, sibling to 1.7
+- **Name (DE):** Wiedereinsetzungsantrag — Begründungsfrist (§ 234 Abs. 1 S. 2 ZPO)
+- **Name (EN):** Petition for re-establishment — appeal/revision grounds period (ZPO §234(1) sentence 2)
+- **Party:** both
+- **Anchor:** `trigger_event_id = 201` (`wegfall_hindernisses_de_zpo`)
+- **Duration:** 1, months
+- **Timing:** after
+- **Priority:** optional
+- **is_court_set:** false
+- **condition_expr:** **FLAG** — needs a flag like `{"flag":"begruendungsfrist"}` or similar to distinguish from Rule 1.7 because today's data model can't differentiate "the missed deadline was a Berufungsbegründungsfrist" without an explicit flag from the caller. m to decide whether to add a flag or leave the rule as "informational alternative" rendered alongside 1.7.
+- **Legal source:** `DE.ZPO.234.1`
+- **Notes:** ZPO §234(1) Satz 2: "Die Frist beträgt einen Monat, wenn die Partei verhindert war, die Frist zur Begründung der Berufung, der Revision, der Nichtzulassungsbeschwerde oder der Rechtsbeschwerde oder die Frist des § 234 Abs. 3 einzuhalten."
+
+### Rule 1.9 — DE ZPO §234(3) — 1-Jahres-Ausschlussfrist
+
+- **Rule code:** informational sibling
+- **Name (DE):** Absolute Ausschlussfrist Wiedereinsetzung ZPO (1 Jahr)
+- **Name (EN):** Absolute cut-off for re-establishment, ZPO (1 year)
+- **Party:** both
+- **Anchor:** missed-deadline date (schema FLAG as 1.2)
+- **Duration:** 12, months
+- **Timing:** after
+- **Priority:** informational
+- **is_court_set:** false
+- **condition_expr:** NULL
+- **Legal source:** `DE.ZPO.234.3`
+- **Notes:** "Nach Ablauf eines Jahres, von dem Ende der versäumten Frist an gerechnet, kann die Wiedereinsetzung nicht mehr beantragt … werden."
+
+**Summary for `wiedereinsetzung`:** four of the five linked event categories (DE PatG, DE ZPO, EPC, DPMA) already have **existing rules** that just need `concept_id` set — see § 6. The genuinely new substance is **Rule 1.1** (UPC R.320, te 207), plus a set of informational 1-year cut-off rules (1.2/1.4/1.6/1.9), plus the optional ZPO §234(1) sentence-2 variant (1.8). Six new rules in total, one duplicate-flagged, four pure linkages. **FLAG:** UPC fee for Wiedereinsetzung (R.150(1)(p)) is not modelled as a rule — should it appear as a sibling informational rule with the fee amount? Today's model doesn't carry money, so probably no, but worth m's call.
+
+---
+
+## 2. Concept: `schriftsatznachreichung` (Schriftsatznachreichung, § 296a ZPO)
+
+**Concept ID:** `b7a3cb3e-ef7e-47a1-8067-be0fe35a4235`
+**Party:** both · **Category:** submission
+**Linked event_categories:**
+- `cms-eingang.gericht.ladung` (Ladung zur mündlichen Verhandlung)
+- `muendl-verhandlung.gehalten` (Soeben gehalten / heute)
+- `muendl-verhandlung.geladen` (Geladen — wann findet sie statt?)
+
+**Existing rules:** te 205 (`ende_muendl_verhandlung`) already has rule `3c36f149-…` (3 weeks). Linkage only — see § 6.
+
+### Rule 2.1 — DE ZPO §296a Schriftsatznachreichungsfrist
+
+- **Rule code:** event-rooted, te=205
+- **Proceeding type:** NULL (event-rooted) — primarily DE_INF/DE_NULL/OLG/BGH context but cross-cutting via the trigger event.
+- **Name (DE):** Schriftsatznachreichung (§ 296a ZPO)
+- **Name (EN):** Subsequent written submission (ZPO §296a)
+- **Party:** both
+- **Anchor:** `trigger_event_id = 205` (`ende_muendl_verhandlung`)
+- **Duration:** 3, weeks
+- **Timing:** after
+- **Priority:** optional *(only available if court grants Schriftsatznachreichungsfrist; otherwise §296a bars new attack/defence means)*
+- **is_court_set:** **true** — the deadline date is set by the court order granting the Schriftsatznachreichungsfrist, not by the statute itself. ZPO §296a permits the court to set it; typical practice is 2-3 weeks but the court fixes the exact date.
+- **condition_expr:** NULL
+- **Legal source:** `DE.ZPO.296a`
+- **Notes:** **DUPLICATE of existing rule** — linkage only. **FLAG:** the existing rule sets `is_court_set=false` and a fixed 3-week duration. Strictly, the court sets the date, so `is_court_set=true` is more accurate; the 3-week duration is a typical-case estimate. m to decide whether to update the existing rule or leave the heuristic as-is and document the deviation.
+
+### Rule 2.2 — Schriftsatznachreichung — Beschränkung auf in der Verhandlung erörterte Punkte (informational)
+
+- **Rule code:** informational sibling
+- **Name (DE):** Beschränkung der Schriftsatznachreichung (nur Bezug auf Verhandlungspunkte)
+- **Name (EN):** Schriftsatznachreichung scope limit (only matters raised at the hearing)
+- **Party:** both
+- **Anchor:** same as 2.1
+- **Duration:** 0
+- **Timing:** after
+- **Priority:** informational
+- **is_court_set:** false
+- **condition_expr:** NULL
+- **Legal source:** `DE.ZPO.296a`
+- **Notes:** Reminds the user that a Schriftsatznachreichung is limited to matters raised at the oral hearing — new attack/defence means are barred under §296a. Useful for the cascade card; not a calendar deadline.
+
+### Rule 2.3 — Schriftsatznachreichung — UPC equivalent? (open question)
+
+**FLAG:** UPC RoP has no direct §296a analogue. Post-hearing submissions in UPC proceedings are limited and require court leave (general practice; see R.117). I am intentionally **not** drafting a UPC rule under this concept and recommend m confirm the concept stays DE-only. If the cascade exposes the concept under a UPC entry, that is a cascade taxonomy bug, not a rule gap.
+
+**Summary:** 2 substantive rules (1 duplicate-flagged, 1 informational). Concept is essentially solved by linkage + 1 informational sibling.
+
+---
+
+## 3. Concept: `versaeumnisurteil-einspruch` (Einspruch gegen Versäumnisurteil, § 339 ZPO)
+
+**Concept ID:** `9f809d1d-ea06-4aa5-80d0-6feaa33b464e`
+**Party:** defendant · **Category:** submission
+**Linked event_categories:**
+- `beschluss-entscheidung.versaeumnisurteil` (Versäumnisurteil DE)
+- `cms-eingang.gericht.endentscheidung.versaeumnisurteil` (Versäumnisurteil DE)
+
+**Existing rules:** te 204 (`zustellung_versaeumnisurteil`) already has rule `20254f4e-…` (2 weeks). Linkage only — see § 6.
+
+### Rule 3.1 — DE ZPO §339(1) Einspruchsfrist (Inland-Zustellung, 2 Wochen)
+
+- **Rule code:** event-rooted, te=204
+- **Name (DE):** Einspruch gegen Versäumnisurteil (§ 339 Abs. 1 ZPO)
+- **Name (EN):** Objection to default judgment, domestic service (ZPO §339(1))
+- **Party:** defendant
+- **Anchor:** `trigger_event_id = 204` (`zustellung_versaeumnisurteil`)
+- **Duration:** 2, weeks
+- **Timing:** after
+- **Priority:** mandatory *(if defence wants to undo default; otherwise judgment becomes final)*
+- **is_court_set:** false
+- **condition_expr:** NULL — but see Rule 3.2 for the international-service variant.
+- **Legal source:** `DE.ZPO.339.1`
+- **Notes:** **DUPLICATE of existing rule** — linkage only. ZPO §339(1) sentence 1: 2-week Notfrist from Zustellung. §339(1) sentence 2 reserves longer periods for cases under §339(2) and §234(2).
+
+### Rule 3.2 — DE ZPO §339(2) Einspruchsfrist (Auslands-Zustellung, ≥ 1 Monat)
+
+- **Rule code:** event-rooted, te=204, sibling
+- **Name (DE):** Einspruch gegen Versäumnisurteil — Auslandszustellung (§ 339 Abs. 2 ZPO)
+- **Name (EN):** Objection to default judgment — service abroad (ZPO §339(2))
+- **Party:** defendant
+- **Anchor:** `trigger_event_id = 204`
+- **Duration:** 1, months
+- **Timing:** after
+- **Priority:** mandatory
+- **is_court_set:** **true** — §339(2) sentence 2 says the court sets the period in the order; "at least one month" is the statutory floor.
+- **condition_expr:** **FLAG** — needs a flag like `{"flag":"auslandszustellung"}` to distinguish from Rule 3.1. m to decide flag naming.
+- **Legal source:** `DE.ZPO.339.2`
+- **Notes:** ZPO §339(2): "Bei einer Zustellung im Ausland nach § 183 Abs. 1 Nr. 1 wird die Einspruchsfrist auf mindestens einen Monat festgesetzt."
+
+### Rule 3.3 — DE ZPO §340 Inhalt der Einspruchsschrift (informational)
+
+- **Rule code:** informational sibling
+- **Name (DE):** Inhalt der Einspruchsschrift (§ 340 ZPO)
+- **Name (EN):** Required contents of the objection (ZPO §340)
+- **Party:** defendant
+- **Anchor:** same as Rule 3.1
+- **Duration:** 0
+- **Timing:** after
+- **Priority:** informational
+- **is_court_set:** false
+- **condition_expr:** NULL
+- **Legal source:** `DE.ZPO.340`
+- **Notes:** Reminds the user that the Einspruchsschrift must contain the designation of the judgment, the declaration of objection, and the parties' applications. Not a calendar deadline.
+
+### Rule 3.4 — Rechtsfolge Einspruch (informational)
+
+- **Rule code:** informational sibling
+- **Name (DE):** Rechtsfolge des zulässigen Einspruchs (§ 342 ZPO)
+- **Name (EN):** Effect of admissible objection (ZPO §342)
+- **Party:** defendant
+- **Anchor:** same as Rule 3.1
+- **Duration:** 0
+- **Timing:** after
+- **Priority:** informational
+- **is_court_set:** false
+- **condition_expr:** NULL
+- **Legal source:** `DE.ZPO.342`
+- **Notes:** Tells the user that an admissible Einspruch puts the case back in the state pre-default. Useful as a cascade-card pill; not a deadline.
+
+**Summary:** 4 rules, 1 duplicate-flagged, 1 needing a condition flag, 2 informational.
+
+---
+
+## 4. Concept: `weiterbehandlung` (Weiterbehandlung, Art. 121 EPÜ)
+
+**Concept ID:** `5a58f14c-3042-48e9-87fd-c94b62d13662`
+**Party:** claimant · **Category:** submission
+**Linked event_categories:**
+- `cms-eingang.gericht.rechtsverlust-epa` (Mitteilung über Rechtsverlust, EPA)
+- `frist-verpasst.epa` (EPA, Art. 122 EPÜ)
+
+**Existing rules:** te 206 (`mitteilung_rechtsverlust_eu`) already has rule `f1099cf6-…` (2 months). Linkage only — see § 6.
+
+### Rule 4.1 — EPC Art. 121 / R.135 Weiterbehandlungsantrag
+
+- **Rule code:** event-rooted, te=206
+- **Name (DE):** Weiterbehandlungsantrag (Art. 121 EPÜ)
+- **Name (EN):** Request for further processing (Art.121 EPC)
+- **Party:** claimant *(applicant during prosecution)*
+- **Anchor:** `trigger_event_id = 206` (`mitteilung_rechtsverlust_eu`)
+- **Duration:** 2, months
+- **Timing:** after
+- **Priority:** optional *(applicant's choice; preferred over Wiedereinsetzung when available because cheaper and no fault analysis)*
+- **is_court_set:** false
+- **condition_expr:** NULL
+- **Legal source:** `EU.EPC-R.135.1`
+- **Notes:** **DUPLICATE of existing rule** — linkage only. R.135(1): 2 months from notification of loss of rights. Missed act must be completed; Weiterbehandlungsgebühr payable per R.135(1) third sentence.
+
+### Rule 4.2 — Weiterbehandlung Ausschlüsse (informational)
+
+- **Rule code:** informational sibling
+- **Name (DE):** Ausschlüsse Weiterbehandlung (R.135(2) EPÜ)
+- **Name (EN):** Further-processing exclusions (EPC R.135(2))
+- **Party:** claimant
+- **Anchor:** same as Rule 4.1
+- **Duration:** 0
+- **Timing:** after
+- **Priority:** informational
+- **is_court_set:** false
+- **condition_expr:** NULL
+- **Legal source:** `EU.EPC-R.135.2`
+- **Notes:** R.135(2): Weiterbehandlung not available for the priority period (Art. 87(1)), the period under Art. 112a(4), the periods for filing of opposition and appeal (Art. 99(1), 108), and various R.6/R.36(1)(a)/R.51(2)/R.158/R.27(3) periods. Cascade-card pill so the user knows when to fall back to Wiedereinsetzung instead. **FLAG:** could be modeled per excluded period as a fine-grained `condition_expr`-gated set; that is overkill for now — informational siblings are enough.
+
+### Rule 4.3 — Weiterbehandlungsgebühr (informational)
+
+- **Rule code:** informational sibling
+- **Name (DE):** Weiterbehandlungsgebühr fällig
+- **Name (EN):** Further-processing fee due
+- **Party:** claimant
+- **Anchor:** same as Rule 4.1
+- **Duration:** 2, months
+- **Timing:** after
+- **Priority:** informational
+- **is_court_set:** false
+- **condition_expr:** NULL
+- **Legal source:** `EU.EPC-R.135.1` (third sentence)
+- **Notes:** Fee per Art. 2(1) item 12 of the EPA fee schedule. Mirrors the missed-act window — both must be completed in the same 2-month window for the request to be effective.
+
+**Summary:** 3 rules, 1 duplicate-flagged, 2 informational.
+
+---
+
+## 5. Concept: `counterclaim-for-revocation` (Nichtigkeitswiderklage, UPC R.25)
+
+**Concept ID:** `52134900-2bcf-4810-9de3-0b0681c79dd7`
+**Party:** defendant · **Category:** submission
+**Linked event_category:**
+- `ich-moechte-einreichen.widerklage.nichtigkeit-upc` (Nichtigkeitswiderklage UPC R.25)
+
+**Existing rules:** UPC R.25 / RoP 25-32 are **already encoded** in `UPC_INF` (proceeding_type_id=8) as flag-gated rules using `condition_expr.flag = "with_ccr"`:
+
+| Rule code | Name | Duration | condition_expr | concept_slug today |
+|---|---|---|---|---|
+| `inf.def_to_ccr` | Erwiderung auf Nichtigkeitswiderklage | 2 months | `{"flag":"with_ccr"}` | `defence-to-counterclaim-for-revocation` |
+| `inf.reply` (with_ccr variant) | Replik | 2 months | `{"flag":"with_ccr"}` | `reply-to-defence` |
+| `inf.reply_def_ccr` | Replik auf Erwiderung zur Nichtigkeitswiderklage | 2 months | `{"flag":"with_ccr"}` | (not yet checked) |
+| `inf.rejoin` (with_ccr) | Duplik | 1 month | `{"flag":"with_ccr"}` | `rejoinder` |
+| `inf.rejoin_reply_ccr` | Duplik auf Replik | 1 month | `{"flag":"with_ccr"}` | (not yet checked) |
+| `inf.def_to_amend` | Erwiderung auf Patentänderungsantrag | 2 months | `{"op":"and","args":[{"flag":"with_ccr"},{"flag":"with_amend"}]}` | `defence-to-application-to-amend` |
+| `inf.app_to_amend` | Antrag auf Patentänderung | 2 months | `{"op":"and","args":[{"flag":"with_ccr"},{"flag":"with_amend"}]}` | **NULL** (orphan column) |
+| `inf.reply_def_amd` | Replik auf Erwiderung zum Patentänderungsantrag | 1 month | same | `reply-to-defence-to-application-to-amend` (or similar) |
+| `inf.rejoin_amd` | Duplik auf Replik zum Patentänderungsantrag | 1 month | same | `rejoinder-on-amend` (or similar) |
+
+**The CCR itself** — the act of filing the Nichtigkeitswiderklage — is part of `inf.sod` (Statement of Defence) when `with_ccr=true`. The 3-month SoD period from R.23 doubles as the CCR-filing period from R.25.
+
+### Proposal 5.1 — Do **not** seed new rules under this concept.
+
+The concept models a logical artifact ("Nichtigkeitswiderklage") that is, in the data model, an attribute of the SoD rather than a separate timed event. Seeding new rules under `counterclaim-for-revocation.concept_id` would either:
+
+- (a) Duplicate the existing `inf.sod` / `inf.def_to_ccr` / etc. rules — wasteful, fragile (two sources of truth for the same legal period).
+- (b) Add a synthetic "filing CCR" rule with the same 3-month period as `inf.sod` — redundant once `inf.sod`'s `concept_id` is set correctly.
+
+### Proposal 5.2 — Link existing UPC_INF rules to this concept (linkage only).
+
+Specifically:
+
+| Rule | Current `concept_id` link | Proposed action |
+|---|---|---|
+| `inf.sod` (UPC_INF) | `statement-of-defence` (presumably) | Leave as-is — SoD's primary concept is "Statement of Defence". |
+| `inf.app_to_amend` (UPC_INF, with_ccr+with_amend) | NULL | **Link to `counterclaim-for-revocation`** — this is the genuine "CCR-derived deadline" that has no concept today. |
+
+**FLAG:** Whether the cascade entry `ich-moechte-einreichen.widerklage.nichtigkeit-upc` should resolve to the SoD itself or to a CCR-card-with-derivative-deadlines is a UX question m needs to decide. My read: when a user clicks "I want to file Nichtigkeitswiderklage", they want to see the SoD deadline (because that's when the CCR is due — same period as SoD) plus the consequential deadlines (Defence to CCR, Replik, Duplik, Patent amendment etc.). A cleaner data-model fix is to add a junction `paliad.concept_rules` (many-to-many) so a rule can belong to multiple concepts (e.g. `inf.sod` ∈ {`statement-of-defence`, `counterclaim-for-revocation`}). That's a Phase 3+ schema add and outside Slice 12's scope.
+
+### Proposal 5.3 — Alternative: event-rooted CCR rule.
+
+Trigger event 1 (`statement_of_defence_which_includes_a_counterclaim_for_revocation`) exists but lacks `concept_id` text. Setting `paliad.trigger_events.concept_id = 'counterclaim-for-revocation'` on te 1 and seeding 1-3 event-rooted rules that fire from te 1 (Defence to CCR within 2 months, Reply within 2 months, etc.) would give the cascade card concrete deadlines without duplicating the SoD-tree rules. This is the pattern the audit § 3.4 description hints at.
+
+**Recommendation:** Proposal 5.2 + 5.3 combined. m to confirm. Until decided, I'm **not** drafting fresh rules for this concept — it's a data-model question disguised as a coverage gap.
+
+---
+
+## 6. Track A — Linkage-only UPDATEs (no legal review needed)
+
+The following `paliad.deadline_rules` rows already exist; they only need `concept_id` pointed at the right concept. These are the lowest-risk part of Slice 12 and can be applied via the admin UI as no-op edits (or as a one-off migration if m prefers).
+
+```sql
+-- DRAFT — do not run blindly; the admin UI route (PATCH /api/admin/rules/{id}) is the preferred path.
+
+-- Wiedereinsetzung (DE PatG)
+UPDATE paliad.deadline_rules
+SET concept_id = '00b737bf-58a6-4f41-9650-ac3f2e7079e8'
+WHERE id = 'c24d494c-0da1-4f01-aa74-0f37f99fe1ae';
+
+-- Wiedereinsetzung (DE ZPO)
+UPDATE paliad.deadline_rules
+SET concept_id = '00b737bf-58a6-4f41-9650-ac3f2e7079e8'
+WHERE id = 'd40d9be7-e1b6-451c-bee2-6eaee2307ec5';
+
+-- Wiedereinsetzung (EPC)
+UPDATE paliad.deadline_rules
+SET concept_id = '00b737bf-58a6-4f41-9650-ac3f2e7079e8'
+WHERE id = '23c6f445-4ed2-4ade-8ea0-c4ab6b364bb6';
+
+-- Wiedereinsetzung (DPMA)
+UPDATE paliad.deadline_rules
+SET concept_id = '00b737bf-58a6-4f41-9650-ac3f2e7079e8'
+WHERE id = 'b588fa64-a727-4cfb-a45d-69a835a3b05a';
+
+-- Versäumnisurteil-Einspruch (ZPO §339)
+UPDATE paliad.deadline_rules
+SET concept_id = '9f809d1d-ea06-4aa5-80d0-6feaa33b464e'
+WHERE id = '20254f4e-d213-4cf6-8f5f-1d9d36eeb6ac';
+
+-- Schriftsatznachreichung (ZPO §296a)
+UPDATE paliad.deadline_rules
+SET concept_id = 'b7a3cb3e-ef7e-47a1-8067-be0fe35a4235'
+WHERE id = '3c36f149-3a81-456e-aac1-d4d18bfcb16b';
+
+-- Weiterbehandlung (EPC Art.121)
+UPDATE paliad.deadline_rules
+SET concept_id = '5a58f14c-3042-48e9-87fd-c94b62d13662'
+WHERE id = 'f1099cf6-4c87-430e-b1c5-488bd44cb143';
+```
+
+After these 7 rows update, `counterclaim-for-revocation` is the only remaining concept with `direct rule_count = 0`, and that is by design (see § 5).
+
+---
+
+## 7. Track B — Genuinely new rule drafts
+
+Pure-new (not in DB today), to be added through `/admin/rules`:
+
+| # | Concept | Rule | Status |
+|---|---|---|---|
+| 1.1 | `wiedereinsetzung` | UPC R.320 Wiedereinsetzungsantrag (te 207) | NEW |
+| 1.2 | `wiedereinsetzung` | UPC R.320 1-Jahres-Ausschlussfrist | NEW, schema FLAG |
+| 1.4 | `wiedereinsetzung` | EPC R.136 1-Jahres-Ausschlussfrist | NEW, schema FLAG |
+| 1.6 | `wiedereinsetzung` | DE PatG §123 1-Jahres-Ausschlussfrist | NEW, schema FLAG |
+| 1.8 | `wiedereinsetzung` | DE ZPO §234(1)2 — 1-Monat Begründungsfrist | NEW, condition_expr FLAG |
+| 1.9 | `wiedereinsetzung` | DE ZPO §234(3) 1-Jahres-Ausschlussfrist | NEW, schema FLAG |
+| 2.2 | `schriftsatznachreichung` | §296a-Beschränkung (informational) | NEW |
+| 3.2 | `versaeumnisurteil-einspruch` | ZPO §339(2) Auslandszustellung 1 Monat | NEW, condition_expr FLAG |
+| 3.3 | `versaeumnisurteil-einspruch` | ZPO §340 Inhalt der Einspruchsschrift (info) | NEW |
+| 3.4 | `versaeumnisurteil-einspruch` | ZPO §342 Rechtsfolge (info) | NEW |
+| 4.2 | `weiterbehandlung` | R.135(2) Ausschlüsse (info) | NEW |
+| 4.3 | `weiterbehandlung` | Weiterbehandlungsgebühr (info) | NEW |
+| 5.x | `counterclaim-for-revocation` | (none — see § 5 proposal) | — |
+
+**Total new rule drafts: 12.** That is well under the "50 rule drafts" estimate in the task brief, because the linkage path covers the bulk of what looked like missing coverage. **FLAG:** if m wants me to draft additional UPC R.320 jurisdiction-specific variants (UPC_REV, UPC_PI, UPC_APP, UPC_DAMAGES, UPC_DISCOVERY) as separate proceeding-rooted rules instead of one shared event-rooted rule (Rule 1.1), that adds ~6-7 more drafts.
+
+---
+
+## 8. Open questions / FLAGs index
+
+For convenience, all `**FLAG**`-marked items in one place. m's decision is needed on each before /admin/rules ingest of the corresponding rule.
+
+| ID | Section | Question |
+|---|---|---|
+| F1 | § 0 | Count discrepancy: 9 vs 5 — confirm the other 4 audit-named orphans were intentionally resolved, not lost. |
+| F2 | § 0 | Redefine the orphan KPI to also count `trigger_event_id → trigger_events.concept_id`, so the count reflects actual UX coverage. |
+| F3 | § 1.1 | UPC R.320: one event-rooted rule (te 207) vs seven proceeding-rooted clones (UPC_INF/UPC_REV/UPC_PI/UPC_APP/UPC_DAMAGES/UPC_DISCOVERY/UPC_APP_ORDERS). |
+| F4 | § 1.2, 1.4, 1.6, 1.9 | 1-year cut-off rules have no clean anchor in the current schema; informational rendering vs new `frist_versaeumt_*` trigger event. |
+| F5 | § 1.4 | EPC R.136(1) third sentence: priority-restoration 2-month cut-off — separate rule? |
+| F6 | § 1.8 | ZPO §234(1) sentence 2 (Begründungsfrist) — flag-gated or informational sibling? |
+| F7 | § 1.x | UPC Wiedereinsetzungs-Gebühr (R.150(1)(p)) — surface as informational rule or out of scope? |
+| F8 | § 2.1 | Schriftsatznachreichung existing rule has `is_court_set=false`; strictly it's court-set. Update the row or leave the heuristic in place? |
+| F9 | § 2.3 | Confirm `schriftsatznachreichung` is DE-only — cascade should not expose it under UPC entries. |
+| F10 | § 3.2 | ZPO §339(2) Auslandszustellung — flag name for `condition_expr` (e.g. `auslandszustellung`). |
+| F11 | § 5 | `counterclaim-for-revocation` — link existing UPC_INF rules (proposal 5.2) vs event-rooted CCR rule under te 1 (proposal 5.3) vs both. |
+| F12 | § 5 | Many-to-many concept↔rule junction (`paliad.concept_rules`) as a Phase 3+ schema add. |
+
+---
+
+## 9. Sources cited
+
+| Citation key | Reference |
+|---|---|
+| `UPC.RoP.320.1` | UPC Rules of Procedure, Rule 320(1) — Application for re-establishment of rights, time limits |
+| `UPC.RoP.320.2` | UPC RoP Rule 320(2) — Completion of omitted act |
+| `UPC.RoP.150.1.p` | UPC RoP Rule 150(1)(p) — Re-establishment fee |
+| `UPC.RoP.25` | UPC RoP Rule 25 — Lodging of Counterclaim for Revocation |
+| `UPC.RoP.23.1` | UPC RoP Rule 23(1) — Statement of Defence period (existing rule reference) |
+| `EU.EPC-R.136.1` | EPC Implementing Regulations Rule 136(1) |
+| `EU.EPC-R.136.2` | EPC Implementing Regulations Rule 136(2) — Exclusions |
+| `EU.EPC-R.135.1` | EPC Implementing Regulations Rule 135(1) — Further processing |
+| `EU.EPC-R.135.2` | EPC Implementing Regulations Rule 135(2) — Exclusions |
+| `EU.EPÜ.122` | European Patent Convention Article 122 |
+| `EU.EPÜ.121` | European Patent Convention Article 121 |
+| `DE.PatG.123.2` | German Patent Act §123(2) — Wiedereinsetzung |
+| `DE.ZPO.233` | German ZPO §233 — Wiedereinsetzung in den vorigen Stand |
+| `DE.ZPO.234.1` | German ZPO §234(1) — Antragsfrist (2 Wochen / 1 Monat) |
+| `DE.ZPO.234.3` | German ZPO §234(3) — 1-year cut-off |
+| `DE.ZPO.296a` | German ZPO §296a — Schriftsatznachreichung |
+| `DE.ZPO.339.1` | German ZPO §339(1) — Einspruchsfrist 2 Wochen |
+| `DE.ZPO.339.2` | German ZPO §339(2) — Einspruchsfrist Auslandszustellung |
+| `DE.ZPO.340` | German ZPO §340 — Inhalt der Einspruchsschrift |
+| `DE.ZPO.342` | German ZPO §342 — Rechtsfolge des zulässigen Einspruchs |
+
+---
+
+## 10. What's next (if m approves)
+
+1. **Track A first** (low risk): apply the 7 linkage UPDATEs from § 6 via `/admin/rules` PATCH. Cascade UX immediately recovers for 4 of 5 concepts.
+2. **Track B legal-review pass:** m or HLC lawyer signs off on the 12 new drafts in § 7 — adjust durations / phrasings as needed.
+3. **Ingest Track B** via `/admin/rules` POST, one rule at a time. Each new rule goes into `lifecycle_state='draft'` first; m promotes to `published` after spot-checking via the calculator preview endpoint (Slice 11a).
+4. **Schema follow-ups** (FLAGs F2, F4, F12) deferred to Phase 3 follow-up tickets — not in Slice 12 scope.
+
+**Estimated rule count after Slice 12 land:** Track A linkage = 7 connections, Track B new rules = 12 drafts → total `paliad.deadline_rules` row count grows from 249 to **261**; orphan-concept count drops from 5 to **1** (only `counterclaim-for-revocation`, which is by design — see § 5).

docs/research-deadlines-completeness-2026-05-25.md

@@ -0,0 +1,956 @@
+# Bulletproof completeness audit — paliad.deadline_rules vs statutory sources
+
+**Author:** curie (researcher)
+**Date:** 2026-05-25
+**Task:** t-paliad-263 (m/paliad#94)
+**Mode:** read-only research, no DB writes
+**Branch:** `mai/curie/researcher-bulletproof`
+
+Scope confirmed by head (paliad/head → paliad/curie, 2026-05-25 15:13):
+**UPC Rules of Procedure + EPC + PatG / ZPO / GebrMG**, plus UPC Agreement /
+Statute where they create time-limits. No HLC-internal checklists exist in
+the current head's working tree.
+
+Companion / prior audits this report supersedes-and-extends:
+
+- `docs/audit-fristenrechner-completeness-2026-04-30.md` (curie, t-paliad-084) — youpc-vs-paliad gap analysis.
+- `docs/audit-upc-rop-deadlines-2026-05-08.md` (curie, t-paliad-159) — first UPC RoP gap list (52 rules / 2 duration bugs).
+- `docs/audit-fristen-logic-2026-05-13.md` (pauli, t-paliad-157) — schema audit; the codes used here (`upc.inf.cfi`, `de.inf.lg`, …) reflect the post-mig-096 rename.
+
+Migration baseline: migration ≤ `122_deadlines_custom_rule_text` (live as of 2026-05-25 14:00 UTC).
+
+---
+
+## §0. TL;DR
+
+- **20 active fristenrechner proceeding_types** (live, `is_active=true`,
+  `lifecycle_state='published'`) carry **132 active rules**. One extra
+  `_archived_litigation` row holds 40 retired Pipeline-A rules from
+  mig 093 — not surfaced anywhere, kept only for FK validity.
+
+| Jurisdiction | Active types | Active rules | Statute-bound rules audited |
+|---|---:|---:|---:|
+| UPC (CFI + CoA) | 9 (incl. upc.ccr.cfi alias) | 67 | 67 |
+| EPA | 3 | 23 | 23 |
+| DPMA | 3 | 13 | 13 |
+| DE (LG/OLG/BGH/BPatG) | 5 | 29 | 29 |
+| **Total** | **20** | **132** | **132** |
+
+- **5 high-impact bugs still live** that the prior May 8 audit
+  surfaced (2) plus 3 new ones identified here.
+  - 🔴 **`upc.rev.cfi.defence` 3 months, RoP.49.1 says 2 months.** Flagged
+    May 8; still live. ★★★ — every UPC_REV defendant.
+  - 🔴 **`upc.rev.cfi.rejoin` 2 months, RoP.52 says 1 month.** Flagged
+    May 8; still live. ★★★ — every UPC_REV proceeding.
+  - 🟠 **`upc.apl.merits.response` 2 months, RoP.235.1 says 3 months.**
+    New finding (May 8 audit recorded the rule as "3 months / present-wrong
+    rule_code only" — actually live data shows 2 months, so the audit
+    sample mis-recorded the duration too). ★★★ — every UPC main-track
+    appeal respondent.
+  - 🟠 **`de.inf.lg.beruf_begr` chains parent = berufung (1mo) + 2mo = 3mo
+    from urteil. ZPO §520(2) anchors the 2-month Begründungsfrist on
+    service of urteil, not on filing of Berufung.** New finding.
+    ★★★ — every DE-first-instance appellant.
+  - 🟠 **`de.inf.lg.replik` + `.duplik` have `parent_id=NULL` so they fire
+    on the trigger date (Klageerhebung) — sequence-order says 30/40 but
+    the compute engine reads parent_id first.** Reported as live UI bug
+    by m via head (2026-05-25 13:13); confirmed by SQL. ★★★ — every
+    DE-LG-Verletzung timeline.
+
+- **5 rule-code / citation drift bugs still live** from the May 8 audit
+  (`upc.apl.merits.notice`, `.grounds`, `.response`, `upc.rev.cfi.reply`,
+  `.rejoin`) — durations may or may not be right, but the cited
+  `legal_source` / `rule_code` points at the wrong rule. Pure
+  cosmetic on `.notice`/`.grounds` (durations are right); load-bearing on
+  `.rev.cfi.reply` / `.rejoin` because the cited rule is what tells
+  the lawyer where to look the rule up.
+
+- **4 DPMA / DE citation bugs** new in this audit, all citing PatG / ZPO
+  sections that don't contain the cited deadline:
+  - `de.null.bpatg.erwidg` cites `DE.PatG.82.1`; the 2-month Erwiderung
+    is actually `§82(3)` (§82(1) is the 1-month Erklärungsfrist).
+  - `dpma.opp.dpma.erwiderung` cites `DE.PatG.59.3`; §59(3) is about
+    hearings, not a 4-month proprietor response. The 4-month figure is
+    DPMA-internal practice, not statutory — should be court-set.
+  - `dpma.appeal.bpatg.begruendung` cites `DE.PatG.75.1`; §75 is about
+    *aufschiebende Wirkung* — there is no Begründungsfrist in PatG §73-§80
+    for the BPatG-Beschwerde. The 1-month figure is also non-statutory.
+  - `de.null.bgh.begruendung` cites `DE.PatG.111.1`; §111 is about the
+    grounds-of-appeal *content* (Verletzung des Bundesrechts), not the
+    Begründungsfrist. `de.null.bgh.erwiderung` cites `DE.PatG.111.3`;
+    §111(3) doesn't exist in the deadline sense.
+
+- **Wide UPC coverage gap inherited from May 8 audit, mostly un-closed:**
+  ~25 missing UPC RoP rules. Mig 095 (t-paliad-205) closed 4 of them
+  (R.19 Preliminary Objection on UPC_INF and UPC_REV, R.220.1(a)
+  merits-appeal spawn on both). The other ~21 (R.20.2, R.118.4,
+  R.197.3, R.198, R.207.6.a, R.207.9, R.213, R.109.1/.4/.5, R.118.5,
+  R.144, R.155, R.224.2(b), R.229.2, R.235.2, R.245.x, R.262.2,
+  R.321.3, R.333.2, R.353, plus the DNI family R.63-R.69) are
+  unchanged.
+
+- **EPC gaps:** EPA opposition + Beschwerde modelled at the
+  Article level only. Missing the entire Implementing Regulations
+  family that drives day-to-day deadlines — R.71(3) approval period
+  is half-modelled (the 4-month figure is there but the trigger
+  anchor is broken: parent_id=NULL), R.79(1) proprietor response
+  is modelled as a fixed 4-month period when it's actually
+  court-set, R.116 oral-proceedings cut-off is modelled as
+  duration-0/parent-NULL (works for some uses, not for others),
+  R.121 / R.135 Weiterbehandlung is missing entirely (concept
+  exists but no rule).
+
+- **DE/DPMA gaps:** the entire Wiedereinsetzung family (PatG §123)
+  is absent on the proceeding-tree side. `weiterbehandlung` and
+  `wiedereinsetzung` concept slugs exist in the cascade (Pathway B)
+  but no `paliad.deadline_rules` row computes them. Same for
+  `versaeumnisurteil-einspruch` (ZPO §339 — 2 weeks).
+
+- **15 ambiguities** that need m's judgement, not a coder's fix —
+  mostly around court-set vs statutory periods (e.g. richterliche
+  Fristen under ZPO §276(1) S.2, §283 Schriftsatznachreichung,
+  EPC R.79(1), §59(3) PatG) and around the "whichever is
+  longer / later" arithmetic primitives still missing
+  (R.198 / R.213 / R.245.2).
+
+- **Recommended fixes (§10) — total 41 items** prioritised in 4
+  tiers. Tier 0 (5 hard duration bugs + 1 sequencing bug + 9
+  citation/anchor bugs) should ship first. Tier 1 (12 rule-fill
+  gaps, ★★★ / ★★) next. Tier 2 + 3 are coverage breadth that
+  needs scoping by m (Wiedereinsetzung, R.198 working-day
+  arithmetic, full Implementing Regulations port).
+
+---
+
+## §1. Methodology
+
+For each of the 20 active proceeding_types I:
+
+1. **Pulled the live rule set** via `mcp__supabase__execute_sql` against
+   the youpc Postgres on 2026-05-25 14:00–15:00 UTC. Schema = `paliad`.
+   Filter: `is_active = true AND lifecycle_state = 'published'`.
+2. **Enumerated the statutory deadlines** in the relevant code for the
+   proceeding's scope.
+3. **Cross-referenced each statutory deadline against the live rule
+   set** on (a) duration + unit, (b) anchor / parent, (c) party,
+   (d) `rule_code` / `legal_source` citation, (e) sequencing.
+4. **Marked status**: `present-correct`, `present-wrong (duration)`,
+   `present-wrong (citation)`, `present-wrong (anchor)`,
+   `present-wrong (party)`, `partial`, `missing`, `n/a`.
+5. **Frequency tag** for prioritisation: ★★★ every case, ★★ common,
+   ★ specialist.
+
+### 1.1 Sources
+
+All citations carry a date stamp and a URL. Where the text was checked
+against more than one source, both are listed.
+
+| Source | URL | Verified on | Used for |
+|---|---|---|---|
+| UPC Rules of Procedure (consolidated 18.05.2023, in force 2023-06-01) | https://www.unifiedpatentcourt.org/sites/default/files/upc_documents/rop_application_-_consolidated_18_05_2023.pdf | 2026-05-25 | All UPC RoP citations |
+| UPC RoP verbatim text via `data.laws_contents` (youpc Postgres, law_type=`UPCRoP`, language=en) | youpc Supabase | 2026-05-25 | Cross-check on R.019.1, R.020.2, R.029.b/.c, R.049.1, R.051, R.051.p1, R.052, R.052.p1, R.220.1.a, R.224.1, R.224.1.a/.b, R.224.2, R.224.2.a/.b, R.235.1, R.235.2, R.237, R.238.1, R.238.2 |
+| European Patent Convention (EPC, 17th ed. 2020) — Articles | https://www.epo.org/en/legal/epc/2020/index.html (verbatim text per youpc `data.laws_contents`, law_type=`EPC`) | 2026-05-25 | EPC Articles 93, 99, 108, 112a, 116, 121, 123, 135 |
+| EPC Implementing Regulations — Rules (in force 2026 consolidated) | https://www.epo.org/en/legal/epc/2020/r71.html (and equivalents) | 2026-05-25 | EPC R.70(1), R.71(3), R.79(1)/(2), R.116(1), R.135 |
+| Patentgesetz (PatG) — gesetze-im-internet.de | https://www.gesetze-im-internet.de/patg/ | 2026-05-25 | §59, §73, §75, §82, §83, §99 ff., §100, §102, §110, §111 |
+| Zivilprozessordnung (ZPO) — gesetze-im-internet.de | https://www.gesetze-im-internet.de/zpo/ | 2026-05-25 | §253, §276, §277, §283, §296a, §339, §517, §520, §521, §524, §544, §548, §551, §554 |
+| Gebrauchsmustergesetz (GebrMG) — gesetze-im-internet.de | https://www.gesetze-im-internet.de/gebrmg/ | 2026-05-25 | §17 (Löschung), §18 (Verfahren) — referenced only to confirm out-of-scope: no GebrMG-rooted proceeding_type exists in paliad today |
+
+### 1.2 Conventions
+
+- A **rule** here means a row in `paliad.deadline_rules`. paliad's local
+  identifier is `submission_code` (post mig 098), e.g.
+  `upc.rev.cfi.defence`.
+- A **statutory deadline** means an obligation derived directly from the
+  text of a procedural code, with a fixed period.
+- "**Court-set**" / "richterliche Frist" means the statute authorises the
+  court / DPMA / EPO to set the period — there is no fixed statutory
+  duration. paliad models these with `is_court_set = true`
+  (post mig ~079) or, legacy-style, `duration_value = 0`.
+- "**Anchoring**" refers to which event the period runs from. paliad
+  models this via `parent_id` (chain anchor) or `anchor_alt` (e.g.
+  `priority_date`); a NULL parent_id with non-zero duration means the
+  deadline runs from the user-supplied trigger date.
+
+### 1.3 Hard constraint: "no fabricated provisions"
+
+Where I'm not 100% sure of a citation (because the youpc law DB only
+covers UPC + EPC, not PatG / ZPO, and my web-fetch coverage of
+PatG / ZPO is partial), I flag the finding as **"needs lawyer review"**
+in §9 rather than asserting a fix. Five PatG / ZPO findings carry that
+tag.
+
+---
+
+## §2. Current state inventory (per jurisdiction)
+
+### 2.1 UPC
+
+9 active types, 67 rules. `upc.ccr.cfi` is an alias proceeding that
+holds zero rules — it points at `upc.inf.cfi` rules under the
+`with_ccr` flag.
+
+| Code | Name | Rule count | Audited against |
+|---|---|---:|---|
+| `upc.inf.cfi` | Verletzungsverfahren | 15 | RoP 19, 23, 25, 29.a-e, 30, 32, 151, 220.1(a) |
+| `upc.rev.cfi` | Nichtigkeitsverfahren | 17 | RoP 19, 32, 42, 43.3, 49.1, 49.2.a, 49.2.b, 51, 52, 56.1/3/4, 220.1(a) |
+| `upc.pi.cfi` | Einstweilige Maßnahmen | 4 | RoP 205, 207, 211 |
+| `upc.disc.cfi` | Bucheinsicht | 4 | RoP 141, 142.2, 142.3 |
+| `upc.dmgs.cfi` | Schadensbemessung | 4 | RoP 131.2, 137.2, 139 |
+| `upc.apl.merits` | Berufung | 8 | RoP 220.1, 224.1.a, 224.2.a, 235.1, 237, 238.1 |
+| `upc.apl.order` | Berufung gegen Anordnungen | 5 | RoP 220.1(c), 220.2, 220.3, 237, 238.2 |
+| `upc.apl.cost` | Berufung gegen Kostenentscheidung | 2 | RoP 221.1 |
+| `upc.ccr.cfi` | Widerklage auf Nichtigkeit (alias) | 0 | — |
+
+### 2.2 EPA
+
+3 active types, 23 rules.
+
+| Code | Name | Rule count | Audited against |
+|---|---|---:|---|
+| `epa.grant.exa` | EP-Erteilung | 7 | EPC Art. 93, R.70(1), R.71(3) |
+| `epa.opp.opd` | EPA Einspruch | 8 | EPC Art. 99(1), 108, 116, 123; R.79(1), R.79(2), R.116(1) |
+| `epa.opp.boa` | EPA Beschwerde | 8 | EPC Art. 108, 112a; R.116(1); RPBA Art. 12 |
+
+### 2.3 DPMA
+
+3 active types, 13 rules.
+
+| Code | Name | Rule count | Audited against |
+|---|---|---:|---|
+| `dpma.opp.dpma` | DPMA Einspruch | 4 | PatG §59(1), §59(3) |
+| `dpma.appeal.bpatg` | BPatG-Beschwerde | 5 | PatG §73(2), §74 ff. |
+| `dpma.appeal.bgh` | BGH-Rechtsbeschwerde | 4 | PatG §100, §102 |
+
+### 2.4 DE (national patent / civil)
+
+5 active types, 29 rules.
+
+| Code | Name | Rule count | Audited against |
+|---|---|---:|---|
+| `de.inf.lg` | LG-Verletzungsklage | 8 | ZPO §253, §276, §283, §296a, §517, §520(2) |
+| `de.inf.olg` | OLG-Berufung Verletzung | 7 | ZPO §517, §520(2), §521(2), §524(2) |
+| `de.inf.bgh` | BGH-Revision Verletzung | 8 | ZPO §544, §548, §551, §554 |
+| `de.null.bpatg` | BPatG-Nichtigkeitsklage | 10 | PatG §81 ff., §82, §83 |
+| `de.null.bgh` | BGH-Nichtigkeitsberufung | 6 | PatG §110, §111 / ZPO ref via §117 PatG |
+
+### 2.5 Cross-cutting: cascade vs proceeding-tree coverage
+
+The cascade layer (`paliad.event_categories` + `…_concepts` +
+`paliad.deadline_concepts`) carries 56 concept "nouns" and ~153
+cascade-leaf → concept mappings. **9 concepts are orphans** (carry
+zero rules, so the cascade card dead-ends): `counterclaim-for-revocation`,
+`schriftsatznachreichung`, `versaeumnisurteil-einspruch`,
+`weiterbehandlung`, `wiedereinsetzung`, `notice-of-defence-intention`,
+plus 3 more. Inventory and recommendations live in
+`docs/audit-fristen-logic-2026-05-13.md` §3.4 — this audit covers only
+the proceeding-tree side.
+
+---
+
+## §3. Findings — Missing rules (statute defines, paliad doesn't)
+
+### 3.1 UPC RoP — 21 missing rules (out of ~25 flagged 2026-05-08, 4 closed by mig 095)
+
+Notation: ★★★ every case, ★★ common, ★ specialist. Verbatim RoP text
+sampled from youpc `data.laws_contents` (law_type=`UPCRoP`, lang=en).
+
+| RoP § | Period | Trigger | Freq | Notes |
+|---|---|---|---|---|
+| **R.20.2** | 14 days | Service of Preliminary Objection | ★ | Reply to PO. Companion to R.19 (which mig 095 added). Without R.20.2 the PO branch is half-modelled. |
+| **R.118.4** | 2 months | Final decision on validity served | ★★ | Application for orders consequential on validity. Common after central-division revocation. |
+| **R.118.5** | n/a UPC | n/a | n/a | UPC has no Versäumnisurteil-Einspruch; closest is R.355 (review of contumacy). |
+| **R.144** | 0 (anchor) | Final decision on damages quantum | ★ | UPC_DAMAGES tree end-row missing. |
+| **R.155** | 1mo / 14d | Cost-decision opposition chain | ★ | UPC_COST_APPEAL only has the leave-to-appeal step; no Defence-to-cost-app row. |
+| **R.197.3** | 30 days | Saisie order served on respondent | ★ | Review application. Trigger event 65 exists; no rule attached. |
+| **R.198** | 31 calendar days **OR 20 working days, whichever is longer** | Saisie executed | ★ | Start proceedings on the merits. Blocked on `working_days` + `combine='max'` primitives (see §7 + §9). |
+| **R.207.6.a** | 14 days | Notification of deficiency in PI application | ★★ | Registry correction. |
+| **R.207.9** | 6 months | PI filed | ★ | Renewal of protective letter. |
+| **R.213** | 31 days OR 20 working days | PI granted | ★★ | Same arithmetic gap as R.198. |
+| **R.109.1** | 1 month **before** | Oral hearing date | ★★ | Simultaneous translation request. `timing='before'` schema supported but no rule populates it (see §7 cross-cutting). |
+| **R.109.4** | 2 weeks **before** | Oral hearing date | ★★ | Interpreter cost notification. `timing='before'`. |
+| **R.109.5** | 2 weeks after | Order of judge-rapporteur to lodge translations | ★★ | trigger event 113 exists; no rule. |
+| **R.224.2.b** | 15 days | Order under R.220.1(c) or decision under R.220.2/221.3 served | ★★ | Grounds-on-orders track. `upc.apl.order` has appeal-itself but no separate grounds row. Verified verbatim against `UPCRoP.224.2.b` (youpc DB). |
+| **R.229.2** | 14 days | Notification of appeal-deficiency | ★ | Registry correction in appeal context. |
+| **R.235.2** | 15 days | Statement of grounds (orders track) served | ★★ | Verified verbatim against `UPCRoP.235.2` (youpc DB): *"Within 15 days of service of grounds of appeal pursuant to Rule 224.2(b), any other party … may lodge a Statement of response"*. `upc.apl.order` has no standalone response row. |
+| **R.245.1** | 2 months | Final decision served | ★ | Application for rehearing. |
+| **R.245.2.a** | 2 months | Discovery of fundamental defect (or final decision service, whichever is later) | ★ | Outer cap 12mo. Needs multi-anchor + `max-of-two-anchors` arithmetic. |
+| **R.245.2.b** | 2 months | Discovery of criminal offence (or final decision service, whichever is later) | ★ | Same shape as 245.2.a. |
+| **R.262.2** | 14 days | Receipt of opposing party's confidentiality application | ★★ | Daily occurrence in HLC infringement work. Trigger event 25 exists; no rule. |
+| **R.320** | 2 months (cap 12 mo) | Wegfall des Hindernisses (Wiedereinsetzung) | ★★ | Cascade card exists (mig 063) but no proceeding-tree rule computes the deadline. Bridges proceedings → no obvious home in any one tree. |
+| **R.321.3** | 10 days | Preliminary objection referral to central division | ★ | |
+| **R.333.2** | 15 days | Case-management order served | ★★ | Review-of-CMO. Routine in busy LDs. |
+| **R.353** | 1 month | Decision / order delivered | ★ | Rectification application. |
+| **DNI: R.63 / R.67.1 / R.69.1 / R.69.2** | 0 / 2mo / 1mo / 1mo | DNI cascade | ★ | No UPC_DNI proceeding_type exists. Fringe at HLC (zero published filings in 2026-Q1 per May 8 audit). |
+| **Registry-correction family: R.16.3.a, R.27.2, R.89.2, R.253.2** | 14 days each | Various deficiency notifications | ★ | All same 14-day duration; different trigger codes. Most natural home is cascade not proceeding-tree (see audit-fristenrechner-completeness-2026-04-30.md §3.1). |
+
+**Closed since May 8 audit (verified by SQL):**
+- ✅ R.19 Preliminary Objection on UPC_INF — `upc.inf.cfi.prelim`, 1mo, RoP.019.1, flag-gated `with_po` — mig 095.
+- ✅ R.19 Preliminary Objection on UPC_REV — `upc.rev.cfi.prelim`, 1mo, RoP.019.1, flag-gated `with_po` — mig 095 (cites R.19 i.V.m. R.46).
+- ✅ R.220.1(a) merits-appeal spawn on UPC_INF — `upc.inf.cfi.appeal_spawn`, 2mo, is_spawn=true → upc.apl.merits — mig 095.
+- ✅ R.220.1(a) merits-appeal spawn on UPC_REV — `upc.rev.cfi.appeal_spawn`, 2mo, is_spawn=true → upc.apl.merits — mig 095.
+
+### 3.2 EPC Implementing Regulations — 4 missing rules
+
+| EPC ref | Period | Trigger | Freq | Notes |
+|---|---|---|---|---|
+| **EPC R.135 (Weiterbehandlung)** | 2 months | Notification of loss of rights | ★★ | Concept `weiterbehandlung` exists in cascade (orphan); no rule. Applies broadly across `epa.grant.exa` and `epa.opp.opd`. |
+| **EPC R.99(2) / Art. 121** | 2 months | Loss-of-rights notification (further processing) | ★★ | Same family as R.135. |
+| **EPC Art. 112a(4)** | 2 months / 1 month | Discovery of grounds for review / decision served (whichever later) | ★ | paliad has `epa.opp.boa.r106` (2 months, parent=entsch2) — but the rule doesn't model the "whichever later" outer cap (12 months from decision per Art. 112a(4)). |
+| **EPC Art. 99(1) — opposition fee paid** | 9 months (no extension) | Mention of grant in Patentblatt | ★★★ | `epa.opp.opd.frist` IS modelled correctly at 9 months. **Note however:** the rule is on `epa.opp.opd` but the *trigger* is opposition-fee-paid (per Art. 99(1) S.2 — "Notice of opposition shall not be deemed to have been filed until the opposition fee has been paid"). Not a gap, but a documentation note. |
+
+### 3.3 PatG / ZPO — 5 missing rules
+
+| Citation | Period | Trigger | Freq | Notes |
+|---|---|---|---|---|
+| **PatG §123 (Wiedereinsetzung)** | 2 months | Wegfall des Hindernisses (cap 1 year) | ★★ | Cascade concept `wiedereinsetzung` exists; no rule on any DE/DPMA proceeding tree. Same modelling problem as UPC R.320 — bridges proceedings. |
+| **ZPO §339 (Versäumnisurteil-Einspruch)** | 2 weeks | Service of default judgment | ★ | Cascade concept `versaeumnisurteil-einspruch` orphan. |
+| **ZPO §544 — Nichtzulassungsbeschwerde-Begründung** | 2 months | Service of OLG-Urteil (NB: NOT from filing of NZB) | ★★ | `de.inf.bgh.nzb_begr` lists `DE.ZPO.544.4`, duration 2mo, parent=urteil_olg — **modelled correctly**. Listed here only to flag that the *parent anchoring* differs from `de.inf.lg.beruf_begr` which is wrong (see §7.1). |
+| **ZPO §283 (Schriftsatznachreichung) / §296a** | court-set | post-Verhandlung schriftsatzfrist | ★ | Cascade concept `schriftsatznachreichung` orphan. Court-set period — modelling as `is_court_set=true, duration=0` would suffice. |
+| **PatG §17(2) GebrMG / §18 GebrMG** | 1 month (Beschwerdefrist) | DPMA-Beschluss | ★ | Out of scope per head's confirmation (no GebrMG-rooted proceeding_type yet). Listed to confirm the deliberate gap. |
+
+### 3.4 DPMA — 0 missing rules
+
+DPMA coverage is shallow but not gappy. The 3 active types (opposition,
+BPatG-Beschwerde, BGH-Rechtsbeschwerde) cover the statutory steps. The
+problems here are **citation drift** (§4.4) and **anchor modeling**
+(§7.4) rather than missing rules.
+
+---
+
+## §4. Findings — Misattributed legal source
+
+### 4.1 UPC RoP citation drift (5 still live from May 8)
+
+| Rule | Live `rule_code` | Live `legal_source` | Should be | Source verified |
+|---|---|---|---|---|
+| `upc.apl.merits.notice` | `RoP.220.1` | `UPC.RoP.220.1` | `RoP.224.1.a` / `UPC.RoP.224.1.a` | `UPCRoP.224.1.a` youpc DB |
+| `upc.apl.merits.grounds` | `RoP.220.1` | `UPC.RoP.220.1` | `RoP.224.2.a` / `UPC.RoP.224.2.a` | `UPCRoP.224.2.a` |
+| `upc.apl.merits.response` | `null` | `null` | `RoP.235.1` / `UPC.RoP.235.1` | `UPCRoP.235.1` |
+| `upc.rev.cfi.reply` | `null` | `null` | `RoP.051` / `UPC.RoP.51.p1` | `UPCRoP.051.p1` |
+| `upc.rev.cfi.rejoin` | `null` | `null` | `RoP.052` / `UPC.RoP.52.p1` | `UPCRoP.052.p1` |
+
+Note on cascade vs proceeding-tree drift on R.220.3 anchoring is in
+`docs/audit-upc-rop-deadlines-2026-05-08.md` §5.4b — unchanged here.
+
+### 4.2 UPC RoP citation drift on Rule 49.1 format (1 still live)
+
+| Rule | Live `rule_code` | Should be |
+|---|---|---|
+| `upc.rev.cfi.defence` | `RoP.49.1` | `RoP.049.1` (canonical zero-padded form used by all other UPC rules) |
+
+### 4.3 DPMA — 3 mis-attributed citations
+
+| Rule | Live citation | Problem | Verified |
+|---|---|---|---|
+| `dpma.opp.dpma.erwiderung` | `§ 59 PatG` / `DE.PatG.59.3` | §59(3) PatG addresses *Anhörung*, not a 4-month response period. No statutory Erwiderungsfrist exists in §59. The 4-month figure is DPMA-internal practice. | WebFetch [gesetze-im-internet.de/patg/__59.html](https://www.gesetze-im-internet.de/patg/__59.html) 2026-05-25 |
+| `dpma.appeal.bpatg.begruendung` | `§ 75 PatG` / `DE.PatG.75.1` | §75 PatG is exclusively about *aufschiebende Wirkung* (suspensive effect). It does not establish any Begründungsfrist. No fixed Begründungsfrist for BPatG-Beschwerde exists in PatG §§73-80 — it is set by the BPatG in the individual case. | WebFetch [gesetze-im-internet.de/patg/__75.html](https://www.gesetze-im-internet.de/patg/__75.html) + [§73](https://www.gesetze-im-internet.de/patg/__73.html) 2026-05-25 |
+| `dpma.appeal.bpatg.beschwerde` | `§ 73 PatG` / `DE.PatG.73.2` | §73 contains the 1-month deadline correctly; the `.2` subscript however refers to §73(2) which is about Beschwerdebefugnis — the *Frist* is in §73(2) S.4 ("Die Beschwerdefrist beträgt einen Monat …"). Citation should be `DE.PatG.73.2.s4` or simply `DE.PatG.73.2`. **Borderline — flag, not a hard bug.** | gesetze-im-internet.de |
+
+### 4.4 DE patent / civil — 4 mis-attributed citations
+
+| Rule | Live citation | Problem | Verified |
+|---|---|---|---|
+| `de.null.bpatg.erwidg` | `§ 82 PatG` / `DE.PatG.82.1` | §82(1) is the 1-month *Erklärungsfrist* ("sich darüber zu erklären"); the 2-month full *Klageerwiderung* is in §82(3). Citation should be `DE.PatG.82.3`. Duration (2 months) is correct. | WebFetch [§82](https://www.gesetze-im-internet.de/patg/__82.html) 2026-05-25 |
+| `de.null.bpatg.replik_klaeger` | `§ 83 PatG` / `DE.PatG.83.2` | §83(2) is about the *Hinweisbeschluss* form; the Replik / Schriftsatz windows fall under §83(2) S.3 (Reaktion auf Hinweis). Citation OK at section level but ambiguous. **Borderline — flag, not a hard bug.** | gesetze-im-internet.de |
+| `de.null.bgh.begruendung` | `§ 111 PatG` / `DE.PatG.111.1` | §111 PatG defines the *Grounds* of Berufung (Verletzung des Bundesrechts), not a Begründungsfrist. The 3-month figure is supplied via §117 PatG → ZPO §520(2). Citation should be `DE.ZPO.520.2` (the actual time-limit source). | WebFetch [§111](https://www.gesetze-im-internet.de/patg/__111.html) 2026-05-25 |
+| `de.null.bgh.erwiderung` | `§ 111 PatG` / `DE.PatG.111.3` | §111 has no Erwiderungsfrist clause. The actual Erwiderungsfrist for BGH-Nichtigkeitsberufung is set by the court per §117 PatG → ZPO §521(2) (court-discretionary). Duration (2 months) is approximate — typical court-set period is 2 months but it's not fixed. **Should be modelled as court-set.** | WebFetch [§111](https://www.gesetze-im-internet.de/patg/__111.html) + ZPO §521 2026-05-25 |
+
+### 4.5 EPA — 1 mis-attributed citation
+
+| Rule | Live citation | Problem |
+|---|---|---|
+| `epa.opp.opd.erwidg` | `R. 79(1) EPÜ` / `EU.EPC-R.79.1` | Duration (4 months) is correct as the *typical* EPO-set period under the 2016 streamlined-opposition guidelines, but **R.79(1) does not specify a fixed period** — the Opposition Division sets it. The 4 months is administrative practice (EPO Guidelines D-IV, 5.2). Should be modelled as court-set with 4 months as the default-display value. |
+
+---
+
+## §5. Findings — Wrong period (statute says X, paliad says Y)
+
+| Rule | Live period | Statutory period | Source | Freq |
+|---|---|---|---|---|
+| **`upc.rev.cfi.defence`** | 3 months | **2 months** | RoP.049.1: *"The defendant shall lodge a Defence to revocation within two months of service of the Statement for revocation."* — verified verbatim from `UPCRoP.049.1` (youpc DB). Flagged 2026-05-08; still live. | ★★★ |
+| **`upc.rev.cfi.rejoin`** | 2 months | **1 month** | RoP.052: *"Within one month of the service of the Reply the defendant may lodge a Rejoinder to the Reply to the Defence to revocation"* — verified verbatim from `UPCRoP.052.p1`. Flagged 2026-05-08; still live. | ★★★ |
+| **`upc.apl.merits.response`** | 2 months | **3 months** | RoP.235.1: *"Within three months of service of the Statement of grounds of appeal pursuant to Rule 224.2(a), any other party … may lodge a Statement of response"* — verified verbatim from `UPCRoP.235.1`. New finding — May 8 audit recorded the duration as 3 months but the live row has always been 2 (migration 012:153 originally seeded 2). | ★★★ |
+| **`upc.pi.cfi.response`** | 0 / "court-set" (`is_court_set=false`, `duration=0`, `parent_id=NULL`) | court-set, judge-discretion under R.211.2 | RoP.211.2 — judge sets the inter-partes hearing date. Modelling is half-broken: `duration=0` with `parent_id=NULL` makes the calculator treat this as a root anchor rather than a court-set placeholder. Should set `is_court_set=true` and chain `parent_id=app`. | ★★ |
+
+(All other rules audited have correct durations.)
+
+---
+
+## §6. Findings — Wrong party
+
+No clear party mis-assignments found in the live data. Two notes worth
+recording, not bugs:
+
+- `upc.inf.cfi.app_to_amend` carries `primary_party='claimant'`. The
+  defendant in an INF case is the alleged infringer; the patent
+  proprietor (=claimant) is who would file an Application to Amend
+  the patent. **Correct.** Listed here only because R.30 reads "the
+  defendant" in some summaries — those refer to the claimant of the
+  CCR (= defendant of the INF), which loops back to the same person
+  who is the INF-claimant / patent-proprietor.
+- `dpma.opp.dpma.erwiderung` carries `primary_party='defendant'`. In an
+  EPA-style opposition, the patent proprietor is the "defendant" of the
+  opposition. Consistent with EPA convention. **Correct.**
+
+---
+
+## §7. Findings — Wrong sequencing / anchoring
+
+### 7.1 `de.inf.lg.beruf_begr` chains parent = `berufung`, should anchor on `urteil` directly
+
+| Live | Per ZPO §520(2) |
+|---|---|
+| `de.inf.lg.beruf_begr.parent_id = de.inf.lg.berufung`, `duration = 2 months` → effective end = trigger + 1mo (Berufung) + 2mo = **3 months** after Urteil service | "Die Frist für die Berufungsbegründung beträgt zwei Monate. Sie beginnt mit der Zustellung des in vollständiger Form abgefassten Urteils" → **2 months** after Urteil service |
+
+Verified verbatim via WebFetch
+[gesetze-im-internet.de/zpo/__520.html](https://www.gesetze-im-internet.de/zpo/__520.html)
+2026-05-25.
+
+The companion `de.inf.olg.begruendung` is **correct** — parent =
+`urteil_lg`, 2mo, so end = Urteil + 2mo. Same statute, two paliad
+rules, two different anchorings: this is a real bug in `de.inf.lg`.
+
+### 7.2 `de.inf.lg.replik` and `de.inf.lg.duplik` have `parent_id = NULL`
+
+This is the bug head flagged. Live data:
+
+| submission_code | name | duration | parent_id | sequence_order |
+|---|---|---|---|---|
+| `de.inf.lg.klage` | Klageerhebung | 0 mo | NULL | 0 |
+| `de.inf.lg.anzeige` | Anzeige Verteidigungsbereitschaft | 2 wk | `de.inf.lg.klage` | 10 |
+| `de.inf.lg.erwidg` | Klageerwiderung | 6 wk | `de.inf.lg.klage` (court-set=true post mig 095) | 20 |
+| **`de.inf.lg.replik`** | Replik | **4 wk** | **NULL** | 30 |
+| **`de.inf.lg.duplik`** | Duplik | **4 wk** | **NULL** | 40 |
+| `de.inf.lg.termin` | Haupttermin | 0 mo | NULL (court-set) | 50 |
+| `de.inf.lg.urteil` | Urteil | 0 mo | NULL (court-set) | 60 |
+| `de.inf.lg.berufung` | Berufungsfrist | 1 mo | NULL | 70 |
+| `de.inf.lg.beruf_begr` | Berufungsbegründung | 2 mo | `de.inf.lg.berufung` | 80 |
+
+With `parent_id = NULL` the calculator anchors Replik on the
+triggerDate (= Klageerhebung), and same for Duplik. So both render
+"4 Wochen ab Klageerhebung" — i.e. before the Klageerwiderung is
+even due. Correct chain should be:
+
+- `replik.parent_id = de.inf.lg.erwidg`, with `is_court_set = true` (richterliche Frist § 276(1) S.2 / § 283 ZPO — typ. 4 weeks default)
+- `duplik.parent_id = de.inf.lg.replik`, same shape
+
+Both rules lack `legal_source` and `rule_code`, which is consistent
+with them being court-set Schriftsatzfristen (no statutory clamp).
+Recommendation in §10.
+
+### 7.3 `upc.apl.merits.grounds` has `parent_id = NULL`
+
+This anchors Grounds on the user-supplied trigger date (=Entscheidung
+service). **Correct** behaviour per RoP.224.2.a: *"within four months
+of service of a decision referred to in Rule 220.1(a) and (b)"*.
+
+If `parent_id` were set to `upc.apl.merits.notice` (as the May 8 audit
+hypothesised), the chain would compound (1-day notice + 4mo grounds =
+~4mo + 1 day), accidentally landing near the right end-date for the
+common case but wrong by up to 2 months in the edge case (when notice
+is filed early). **No fix needed; document the intent.** (This is
+the change the May 8 audit recommended; it was applied in mig 097 or
+earlier.)
+
+### 7.4 DPMA Pathway-A anchors are partially modelled
+
+- `dpma.appeal.bgh.begruendung` chains parent = `rechtsbeschwerde`
+  (1mo + 1mo = 2mo from BPatG-Entscheidung). Per PatG §102 the
+  Rechtsbeschwerdebegründungsfrist is 1 month from filing of the
+  Rechtsbeschwerde — **correct**.
+- `dpma.appeal.bpatg.begruendung` chains parent = `beschwerde`
+  (1mo + 1mo = 2mo from DPMA-Entscheidung). **No statutory basis for
+  the 1-month figure** (see §4.3). Should be court-set.
+
+### 7.5 EPA grant timeline — `epa.grant.exa.r71_3` and `.approval` have `parent_id = NULL`
+
+Live:
+
+| Rule | Duration | parent_id | Issue |
+|---|---|---|---|
+| `epa.grant.exa.r71_3` | 0 mo | NULL | Should chain on `exam_req` (after examination request is granted, EPO issues R.71(3) communication). NULL parent + 0 duration = root anchor at trigger date — works only if user enters the R.71(3) date as trigger; doesn't compose with the rest of the tree. |
+| `epa.grant.exa.approval` | 4 mo | NULL | Per R.71(3) approval period: 4 months from notification. **Anchor should be `r71_3`**, not NULL. As-is, "Zustimmung + Übersetzung" appears as a free-standing 4-mo-from-trigger row that has nothing to do with the rest of the timeline. |
+
+### 7.6 Summary
+
+| # | Rule | Bug |
+|---|---|---|
+| 1 | `de.inf.lg.beruf_begr` | parent should be NULL (anchored on Urteil-trigger) not `berufung` — off by 1 month, ★★★ |
+| 2 | `de.inf.lg.replik` | parent should be `erwidg` not NULL, ★★★ |
+| 3 | `de.inf.lg.duplik` | parent should be `replik` not NULL, ★★★ |
+| 4 | `dpma.appeal.bpatg.begruendung` | should be court-set; current 1-month period has no statutory basis, ★★ |
+| 5 | `dpma.appeal.bpatg.beschwerde` parent is `entscheidung` — OK, just a citation issue (§4.3) | (citation only) |
+| 6 | `epa.grant.exa.r71_3` parent | should chain on `exam_req`, ★ |
+| 7 | `epa.grant.exa.approval` parent | should chain on `r71_3`, ★ |
+| 8 | `upc.pi.cfi.response` | court-set placeholder with `parent_id=NULL` and `is_court_set=false` — should chain on `app` with `is_court_set=true`, ★★ |
+
+---
+
+## §8. Findings — Duplicates
+
+No genuine duplicates. The closest cases:
+
+- `upc.inf.cfi.reply` + `upc.inf.cfi.def_to_ccr` both fire at 2mo after
+  `sod` under `with_ccr`. They cover different actions (Reply to SoD
+  vs. Defence to CCR + Reply to SoD combined) per RoP.029.a vs .b.
+  **Not a duplicate** — distinct rule codes.
+- `upc.rev.cfi.reply` (2mo, no rule_code) and the older `REV.rev_reply`
+  on the archived litigation type — the archived type is hidden
+  (`pt.is_active = false`) so this isn't a duplicate the user sees.
+  Recommendation in §10 to drop the archived corpus once mig 093's
+  audit window closes.
+- `epa.opp.boa.r106` (Art. 112a review) appears only on
+  `epa.opp.boa`, not on `epa.opp.opd` — correct, since Art. 112a
+  review is only available against a Boards-of-Appeal decision.
+
+---
+
+## §9. Ambiguities — decisions m needs to make
+
+These are not bugs the coder can fix. They are judgement calls about
+how to model the law.
+
+### 9.1 Court-set vs fixed-period for richterliche Fristen
+
+The cleanest source-of-truth for these is "no statutory duration —
+court sets the period in the individual case." Modelling them as a
+fixed period with a wrong citation is the bug pattern we keep finding:
+
+- `dpma.opp.dpma.erwiderung` (4 mo) — DPMA practice, not §59 PatG.
+- `dpma.appeal.bpatg.begruendung` (1 mo) — no statutory basis.
+- `de.inf.olg.erwiderung` (1 mo, §521(2)) — §521(2) is explicitly
+  discretionary ("Der Vorsitzende oder das Berufungsgericht **kann**
+  der Gegenpartei eine Frist … bestimmen"). Verified WebFetch
+  [gesetze-im-internet.de/zpo/__521.html](https://www.gesetze-im-internet.de/zpo/__521.html)
+  2026-05-25.
+- `de.null.bgh.erwiderung` (2 mo, "§111(3) PatG") — court-set per §117
+  PatG → ZPO §521(2).
+- `de.null.bpatg.duplik` (1 mo, §83 PatG) — court-set; the 1-month
+  default is BPatG practice.
+- `de.inf.lg.replik`, `.duplik` (4 wk each) — court-set per
+  §283 / §296a ZPO + §276(1) S.2.
+- `epa.opp.opd.erwidg` (4 mo, "R.79(1)") — EPO-set per Guidelines.
+
+**Question (Q1):** Should paliad continue to display these with a
+default duration but flag them as "richterliche Frist — vom Gericht
+festgesetzt", OR should they all flip to `is_court_set=true,
+duration=0` and force the user to enter the actual court-set date?
+
+Head's 2026-05-25 13:13 signal confirms: m's preference is that "Frist
+vom Gericht bestimmt" be flagged as needing case-by-case anchoring,
+not displayed as a fixed period. So default answer = flip to
+`is_court_set=true` and keep the typical period as the *Default*
+display value (the calculator already supports this since the
+mig 095 / `de.inf.lg.erwidg` patch). But the trade-off is a UX
+regression: most users will not enter the actual court-set date
+and the timeline will then show "vom Gericht bestimmt" everywhere.
+
+### 9.2 R.198 / R.213 "31 days OR 20 working days, whichever is longer"
+
+Two RoP rules need a primitive paliad doesn't have:
+- A `working_days` duration unit (counts business-day arithmetic via
+  the holiday service).
+- A `combine = 'max'` operator that compares two durations and picks
+  the later end-date.
+
+**Question (Q2):** Implement the primitive (~120 LoC migration + ~80 LoC
+Go), or document both rules as "manual calculation required, see RoP"
+in the UI? Real R.198 / R.213 cases are rare (saisie + PI). The May 8
+audit suggested deferring; pauli's 2026-05-13 audit §7.1 made the
+case for adding `combine_op` as part of a broader Pipeline A/C merge.
+
+### 9.3 R.245.2 rehearing "whichever is later" trigger
+
+R.245.2.a/b: deadline 2 months from final decision OR from defect
+discovery, whichever is *later*. Plus outer cap 12 months. Needs:
+
+- Multi-anchor trigger event (user supplies 2 dates).
+- `combine = 'max'` between anchors.
+- Outer-cap arithmetic (separate concept from duration).
+
+**Question (Q3):** Defer (specialist, vanishingly rare) or build the
+primitives?
+
+### 9.4 EPC Art. 112a review — outer cap
+
+Same shape as R.245.2: 2 months from defect discovery, outer cap 12
+months from decision. `epa.opp.boa.r106` models the 2-month period
+but not the cap.
+
+### 9.5 PatG §123 Wiedereinsetzung calendar arithmetic
+
+Cascade card (slug `wiedereinsetzung`) exists. The 2mo / 1-year
+arithmetic anchors on the *missed* deadline, not on a forward-looking
+event. paliad's `paliad.deadline_rules` schema has no natural shape
+for this — it would need either a special-case Go helper, or a
+"backward-from-missed-deadline" mode that no rule today uses.
+
+**Question (Q4):** Worth modelling? The cascade card already routes
+the user to the concept; computing the calendar deadline is an
+incremental win.
+
+### 9.6 ZPO §339 Versäumnisurteil-Einspruch
+
+Cascade card orphan. 2 weeks from service of the default judgment.
+Trivial to add as a `de.inf.lg.einspruch_vu` rule (court-decision
+anchor + 2wk fixed). **Question (Q5):** Add as a child of
+`de.inf.lg.urteil` (with `condition_expr={"flag":"with_vu"}`), or
+as a separate proceeding `de.inf.lg.vu`?
+
+### 9.7 Litigation-vs-fristenrechner archived corpus
+
+The 40 rules on `_archived_litigation` (mig 093 retirement holding pen)
+still occupy the rule table. They're invisible to all UIs.
+
+**Question (Q6):** Drop them now (data clean-up), or keep until the
+mig 093 audit window closes formally?
+
+### 9.8 R.79(2) further-party observations period
+
+EPC R.79(2) creates a separate notification window for additional
+opponents. paliad's `epa.opp.opd.r79_further` is modelled as
+`duration=0, is_bilateral=true`. **Question (Q7):** Is this even worth
+keeping? Real workflow: EPO sets a separate period in each
+intervention case. Hard to template.
+
+### 9.9 R.116(1) EPC oral-proceedings cut-off
+
+paliad has it as `duration=0, parent_id=entsch` (`epa.opp.opd.r116`) /
+`parent_id=oral` (`epa.opp.boa.r116`). R.116(1) actually says the
+EPO sets a "final date for making written submissions" when issuing
+the summons. So it's a court-set period, not zero-duration.
+**Question (Q8):** flip to `is_court_set=true` like the §276(1) ZPO
+fix in mig 095?
+
+### 9.10 R.131.2 indication of damages period
+
+paliad models `upc.dmgs.cfi.app` as a 0-duration root anchor (court
+sets when the damages-determination phase opens, per R.131.2). This
+is correct shape but means the entire damages tree is unanchored
+until the user provides the trigger date manually.
+
+**Question (Q9):** Wire `is_spawn` from `upc.inf.cfi.decision` to
+`upc.dmgs.cfi.app` (parallel to the mig-095 appeal-spawn)?
+
+### 9.11 PatG §17 GebrMG / §18 GebrMG
+
+No GebrMG-rooted proceeding_type exists in paliad. Head confirmed
+out-of-scope for this audit. **Question (Q10):** Add a `de.gm.lg`
+proceeding for GebrMG-Löschungsverfahren if HLC sees them?
+
+### 9.12 Proceeding-tree vs cascade parity
+
+paliad has 9 cascade-only concepts with `rule_count = 0` (the orphans
+listed in `audit-fristen-logic-2026-05-13.md` §3.4). The audit-fristen
+audit covers this; restating here only to note that the parity gap
+is the largest single source of "the cascade card promises a
+calculation but doesn't deliver one."
+
+**Question (Q11):** Same as the audit-fristen Q8 — priority order
+for the 9 orphan concepts? My ranking: wiedereinsetzung >
+schriftsatznachreichung > versäumnisurteil-einspruch >
+weiterbehandlung > rest.
+
+### 9.13 R.220.3 anchor
+
+See `audit-upc-rop-deadlines-2026-05-08.md` §5.4b. paliad anchors
+`upc.apl.order.discretion` on the original order (`order`), but
+the 15-day clock per RoP.220.3 runs from the refusal-of-leave
+date (or day-15 fall-back). Off by up to 15 days in the edge case.
+**Question (Q12):** add an explicit `app_ord.refusal` court-set
+intermediate node?
+
+### 9.14 EP_GRANT publish date — priority vs filing
+
+`epa.grant.exa.publish` correctly has `anchor_alt='priority_date'`.
+This was open in the May 8 audit and is now closed. **No question —
+listed to confirm.**
+
+### 9.15 Cross-proceeding spawn execution
+
+mig 095 added two `is_spawn=true` rules (`inf.appeal_spawn`,
+`rev.appeal_spawn` → `upc.apl.merits`). The May 13 audit §1.6 +
+§6.8 noted spawn execution is half-wired in `projection_service.go`.
+**Question (Q13):** wire end-to-end now (so the spawned appeal
+timeline appears in SmartTimeline), or accept the half-wired state?
+
+---
+
+## §10. Recommended fixes (prioritised)
+
+### Tier 0 — hard duration / sequencing / anchor bugs (ship first)
+
+| # | Rule | Fix | Reason / source | Freq |
+|---|---|---|---|---|
+| T0.1 | `upc.rev.cfi.defence` | `duration_value = 2` (was 3), `rule_code = 'RoP.049.1'`, `legal_source = 'UPC.RoP.49.1'` | §5 — every UPC_REV tracked in paliad today computes Defence at wrong month for the last ~3 months | ★★★ |
+| T0.2 | `upc.rev.cfi.rejoin` | `duration_value = 1` (was 2), `rule_code = 'RoP.052'`, `legal_source = 'UPC.RoP.52.p1'` | §5 — same as T0.1 | ★★★ |
+| T0.3 | `upc.apl.merits.response` | `duration_value = 3` (was 2), `rule_code = 'RoP.235.1'`, `legal_source = 'UPC.RoP.235.1'` | §5 — every main-track appellate respondent | ★★★ |
+| T0.4 | `de.inf.lg.beruf_begr` | `parent_id = NULL` (was `de.inf.lg.berufung`) — runs 2 months from triggerDate (Urteil-service) per ZPO §520(2) | §7.1 — every DE-LG-Verletzung appeal | ★★★ |
+| T0.5 | `de.inf.lg.replik` | `parent_id = de.inf.lg.erwidg`, `is_court_set = true` (richterliche Frist § 276(1) S.2 / § 283 ZPO), keep 4-week default | §7.2 — bug head flagged | ★★★ |
+| T0.6 | `de.inf.lg.duplik` | `parent_id = de.inf.lg.replik`, `is_court_set = true` | §7.2 | ★★★ |
+| T0.7 | `upc.rev.cfi.reply` | `rule_code = 'RoP.051'`, `legal_source = 'UPC.RoP.51.p1'` (duration 2mo unchanged) | §4.1 | ★★★ |
+| T0.8 | `upc.rev.cfi.rejoin` (citation only) | covered in T0.2 | — | — |
+| T0.9 | `upc.apl.merits.notice` | `rule_code = 'RoP.224.1.a'`, `legal_source = 'UPC.RoP.224.1.a'` (duration unchanged) | §4.1 | ★★ |
+| T0.10 | `upc.apl.merits.grounds` | `rule_code = 'RoP.224.2.a'`, `legal_source = 'UPC.RoP.224.2.a'` (duration unchanged) | §4.1 | ★★ |
+| T0.11 | `upc.rev.cfi.defence` rule_code zero-pad | covered in T0.1 | — | — |
+| T0.12 | `dpma.opp.dpma.erwiderung` | flip to `is_court_set = true`, keep 4-month default-display value, drop the misleading `DE.PatG.59.3` citation (or replace with "DPMA-Richtlinien D-IV 5.2") | §4.3 + §9.1 | ★★ |
+| T0.13 | `dpma.appeal.bpatg.begruendung` | flip to `is_court_set = true`, drop the `DE.PatG.75.1` citation, keep 1-month default | §4.3 + §9.1 | ★★ |
+| T0.14 | `de.null.bpatg.erwidg` | citation `DE.PatG.82.3` (was 82.1); duration (2mo) correct | §4.4 | ★★ |
+| T0.15 | `de.null.bgh.begruendung` | citation `DE.ZPO.520.2` via PatG §117 (was DE.PatG.111.1); duration (3mo) correct | §4.4 | ★★ |
+| T0.16 | `de.null.bgh.erwiderung` | flip to `is_court_set = true`; citation `DE.ZPO.521.2 via PatG §117` (was DE.PatG.111.3); duration (2mo) becomes default-display | §4.4 + §9.1 | ★★ |
+| T0.17 | `epa.opp.opd.erwidg` | flip to `is_court_set = true`, keep 4-month default | §4.5 + §9.1 | ★★ |
+
+**16 hard fixes.** All within the existing schema (no new columns).
+Each is a single-row UPDATE plus an audit-log entry.
+
+### Tier 1 — high-value missing rules (★★ / ★★★)
+
+| # | Rule | Add | Freq |
+|---|---|---|---|
+| T1.1 | `upc.inf.cfi.cmo_review` | 15 days from CMO service (R.333.2) | ★★ |
+| T1.2 | `upc.inf.cfi.confidentiality_response` | 14 days from opp. confidentiality app (R.262.2) | ★★ |
+| T1.3 | `upc.apl.order.grounds_orders` | 15 days from order service (R.224.2(b)) | ★★ |
+| T1.4 | `upc.apl.order.response_orders` | 15 days from grounds service (R.235.2) | ★★ |
+| T1.5 | `upc.inf.cfi.cons_orders` | 2 months from validity decision (R.118.4) | ★★ |
+| T1.6 | `upc.inf.cfi.rectification` | 1 month from decision (R.353) | ★ |
+| T1.7 | `upc.pi.cfi.deficiency` | 14 days from PI deficiency notification (R.207.6.a) | ★★ |
+| T1.8 | `upc.pi.cfi.merits_start` | 31d OR 20wd from PI grant (R.213) — **blocked on Q2** | ★★ |
+| T1.9 | `upc.inf.cfi.translation_request` | 1 month **before** oral hearing (R.109.1) | ★★ |
+| T1.10 | `upc.inf.cfi.interpreter_cost` | 2 weeks **before** oral hearing (R.109.4) | ★★ |
+| T1.11 | `upc.inf.cfi.translations_lodge` | 2 weeks after summons (R.109.5) | ★★ |
+| T1.12 | `upc.pi.cfi.response` re-anchor | court-set, parent=`app` (currently a broken root) | ★★ |
+
+**12 rule-adds.** T1.9/.10 are the only `timing='before'` rules in the
+entire UPC corpus; schema already supports `before` but no rule
+populates it. Verify the backward-snap-to-working-day logic in
+`internal/services/deadline_calculator.go` before merging
+(2026-04-30 audit §5.4 raised the concern).
+
+### Tier 2 — broader coverage (★ specialist + Wiedereinsetzung family)
+
+| # | Rule | Add | Notes |
+|---|---|---|---|
+| T2.1 | `de.inf.lg.einspruch_vu` | 2 weeks from service of Versäumnisurteil (ZPO §339) | Q5 — proceeding shape decision |
+| T2.2 | `upc.inf.cfi.wiedereinsetzung` | 2 mo / 1-year-cap from Wegfall des Hindernisses (R.320) | Q4 — needs special arithmetic |
+| T2.3 | `de.inf.lg.wiedereinsetzung` | 2 mo / 1-year-cap (PatG §123 / ZPO §233 ff.) | Q4 |
+| T2.4 | `epa.grant.exa.weiterbehandlung` | 2 mo from loss-of-rights notification (EPC R.135) | — |
+| T2.5 | `upc.inf.cfi.prelim_reply` | 14 days from PO service (R.20.2) | Companion to R.19 (mig 095 added it) |
+| T2.6 | `upc.apl.order.discretion_anchor` | add explicit `refusal` intermediate node so R.220.3 anchors correctly (Q12) | |
+| T2.7 | `upc.dmgs.cfi.app` spawn | `is_spawn=true` from `upc.inf.cfi.decision` (Q9) | |
+| T2.8 | `upc.disc.cfi.app` spawn | same shape as T2.7 | |
+| T2.9 | `epa.grant.exa.r71_3` re-anchor | parent = `exam_req` (§7.5) | |
+| T2.10 | `epa.grant.exa.approval` re-anchor | parent = `r71_3` (§7.5) | |
+| T2.11 | `upc.inf.cfi.appeal_spawn` cross-proc wiring | finish the half-wired spawn execution (Q13) | |
+
+### Tier 3 — tooling primitives (block multiple rules)
+
+| # | Primitive | Blocks | Notes |
+|---|---|---|---|
+| T3.1 | `duration_unit = 'working_days'` | R.198, R.213 | Schema already accepts the string; add to calculator + UI |
+| T3.2 | `combine_op = 'max'` | R.198, R.213, R.245.2 | Column already exists per pauli's 2026-05-13 audit |
+| T3.3 | Multi-anchor "whichever later" trigger | R.245.2.a/b | UI + service work |
+| T3.4 | Outer-cap modelling (`outer_cap_value` + `outer_cap_unit`) | R.245.2 (12mo), R.320 (12mo), EPC Art.112a(4) (12mo) | Schema add |
+| T3.5 | "Before"-mode backward snap to working day | R.109.1, R.109.4 | Calculator change (audit-fristenrechner-completeness-2026-04-30.md §5.4) |
+| T3.6 | Cross-proceeding spawn end-to-end (`is_spawn`) | T2.7, T2.8, T2.11 | Pauli's §6.8 |
+
+### Tier 4 — out-of-scope until separate prioritisation
+
+- DNI family (R.63 / R.67.1 / R.69.1 / R.69.2). Zero published filings 2026-Q1.
+- Registry-correction family (R.16.3.a, R.27.2, R.89.2, R.253.2). Most natural in cascade, not proceeding-tree.
+- GebrMG (no proceeding_type today).
+- R.245 rehearing family (specialist).
+- R.155 cost-decision opposition chain (specialist).
+- R.144 UPC_DAMAGES tree-end row (cosmetic).
+- R.79(2) EPC further-parties period (modelling unclear — Q7).
+
+---
+
+## §11. Next-step proposals (suggested fix-task slicing)
+
+The audit identifies **41 distinct actionable items.** Below is a
+suggested decomposition into fix-tasks that can be assigned
+independently. Sequence reflects "Wave 0 must precede Wave 1" only
+where there's a real dependency (most slices are independent).
+
+### Wave 0 — Tier 0 duration / sequencing / anchor fixes (single fix-task)
+
+**Proposed task:** `t-paliad-264 — Tier 0 deadline-rule corrections
+(duration, anchor, citation) from t-paliad-263 audit`
+
+- 16 row UPDATEs (T0.1–T0.17, deduplicated to 16 distinct rows since
+  T0.8 is covered by T0.2 and T0.11 by T0.1).
+- One migration file (~120 LoC SQL).
+- All within existing schema. No new columns.
+- Idempotent guards on every UPDATE (only fire when the row still has
+  the old value, per the mig 095 convention).
+- Adds 16 entries to `paliad.deadline_rule_audit` (per the mig 079
+  trigger).
+- Verification block: `DO $$ … RAISE EXCEPTION …` per mig 095.
+- **Branch:** `mai/<coder>/t-paliad-264-tier0-deadline-fixes`.
+- **Owner:** coder.
+- **Why first:** all 16 affect either calendar correctness (5 hard
+  duration/anchor bugs) or citation correctness (the 11 metadata
+  fixes are what a lawyer would cite-check against). T0.1–T0.6 are
+  user-visible silent wrongs; ship them.
+
+### Wave 1 — Tier 1 rule additions (single fix-task)
+
+**Proposed task:** `t-paliad-265 — Tier 1 deadline-rule additions
+(12 high-frequency rules)`
+
+- 11 INSERTs + 1 UPDATE re-anchor (T1.12 `upc.pi.cfi.response`).
+- T1.8 (`upc.pi.cfi.merits_start`) **excluded** — blocked on T3.1/T3.2.
+- One migration file (~250 LoC SQL).
+- Add cascade leaves + concepts where needed (each rule should be
+  reachable from Pathway B too).
+- **Branch:** `mai/<coder>/t-paliad-265-tier1-rule-additions`.
+- **Owner:** coder. **Legal review:** m must verify each rule before
+  merge (single round of grilling).
+
+### Wave 2 — Q1 court-set audit decision (separate spike)
+
+**Proposed task:** `t-paliad-266 — Decide court-set vs fixed-period
+modelling for richterliche Fristen (Q1 in t-paliad-263 audit)`
+
+- Inventor / pauli reviews §9.1 with m.
+- Decision artefact: list of rules to flip vs keep, plus UX guideline
+  for what the timeline displays for `is_court_set=true` rules.
+- **Owner:** pauli. **m signs off.**
+
+### Wave 3 — Tier 3 tooling primitives (multi-task)
+
+Each Tier 3 row is its own task because each touches schema + service +
+calculator + UI:
+
+- `t-paliad-267 — working_days unit + combine_op='max' (R.198, R.213)`
+- `t-paliad-268 — Outer-cap modelling (R.245.2, R.320, Art.112a)`
+- `t-paliad-269 — Multi-anchor "whichever later" triggers (R.245.2)`
+- `t-paliad-270 — Backward-snap for `before`-mode rules (R.109.1/.4)`
+- `t-paliad-271 — Cross-proceeding spawn end-to-end execution`
+
+Each is foundational for multiple Tier 2 rules; can ship independently.
+
+### Wave 4 — Tier 2 specialist rules (multi-task, after their primitives land)
+
+Each Tier 2 row is its own task or batched into 2-3 tasks by topical
+area:
+
+- `t-paliad-272 — Wiedereinsetzung / Weiterbehandlung family (T2.2, T2.3, T2.4)` — depends on T3.4 (outer cap).
+- `t-paliad-273 — UPC follow-on spawns (T2.7, T2.8, T2.11)` — depends on T3.6.
+- `t-paliad-274 — UPC tail rules (T2.5, T2.6, R.353, etc.)`
+- `t-paliad-275 — EPA grant timeline re-anchoring (T2.9, T2.10)`.
+
+### Wave 5 — Concept-layer parity (separate audit)
+
+The 9 orphan concepts (`audit-fristen-logic-2026-05-13.md` §3.4 + Q11
+here) need a parallel audit pass to map cascade → rule. Recommend
+spinning a `t-paliad-276 — Cascade-rule parity audit` task once the
+above land.
+
+### Wave 6 — Documentation + retire
+
+- `t-paliad-277 — Drop `_archived_litigation` proceeding_type` once
+  mig 093's audit window closes (Q6).
+- `t-paliad-278 — Document Tier 4 deferrals in
+  `docs/feature-roadmap.md`` so the gap-list isn't lost.
+
+---
+
+## Appendix A — file references
+
+**Live state queried via Supabase MCP, 2026-05-25 14:00–15:00 UTC:**
+
+- `paliad.proceeding_types` — 21 active rows (20 fristenrechner + 1
+  archived).
+- `paliad.deadline_rules` — 132 active + 40 archived rows
+  (`lifecycle_state='published'`).
+- `paliad.deadline_rule_audit` — diff history.
+- `data.laws_contents` (youpc) — UPC RoP + EPC verbatim text
+  (`law_type IN ('UPCRoP','EPC')`).
+
+**paliad migrations consulted:**
+
+- `internal/db/migrations/012_fristenrechner_rules.up.sql` — original
+  seed.
+- `internal/db/migrations/043_de_instance_split_proceedings.up.sql`
+  — DE_INF_OLG / DE_INF_BGH split.
+- `internal/db/migrations/052_event_categories_rop_audit.up.sql`
+  — first RoP audit fix-pass.
+- `internal/db/migrations/079_*` — `paliad.deadline_rule_audit`
+  trigger.
+- `internal/db/migrations/091_drop_legacy_rule_columns.up.sql` —
+  cleanup.
+- `internal/db/migrations/093_retire_litigation_category.up.sql` —
+  archived 40 rules.
+- `internal/db/migrations/095_fristen_gap_fill.up.sql` — t-paliad-205
+  R.19 + R.220.1(a) gap fill.
+- `internal/db/migrations/096_proceeding_code_rename.up.sql` — code
+  rename to `<jurisdiction>.<proceeding>.<instance>` form.
+- `internal/db/migrations/097_legal_citation_backfill.up.sql` —
+  legal_source / rule_code backfill.
+- `internal/db/migrations/100_ccr_visible_rule.up.sql` —
+  `upc.ccr.cfi` alias.
+- `internal/db/migrations/104_einspruch_name_and_ccr_priority.up.sql`
+  — Einspruch rename.
+
+**Companion audits:**
+
+- `docs/audit-fristenrechner-completeness-2026-04-30.md` — curie /
+  t-paliad-084.
+- `docs/audit-upc-rop-deadlines-2026-05-08.md` — curie / t-paliad-159.
+- `docs/audit-fristen-logic-2026-05-13.md` — pauli / t-paliad-157
+  (schema audit, ground-truth on column semantics).
+- `docs/proposals/fristen-gap-fill-2026-05-18.md` — m's 0.3 decisions
+  that shipped as mig 095.
+
+**Authoritative source URLs (all verified 2026-05-25):**
+
+- UPC RoP consolidated 18.05.2023: https://www.unifiedpatentcourt.org/sites/default/files/upc_documents/rop_application_-_consolidated_18_05_2023.pdf
+- EPC 17th ed.: https://www.epo.org/en/legal/epc/2020/index.html
+- EPC R.71 (and other Implementing Reg Rules): https://www.epo.org/en/legal/epc/2020/r71.html
+- PatG: https://www.gesetze-im-internet.de/patg/
+  - §59 https://www.gesetze-im-internet.de/patg/__59.html
+  - §73 https://www.gesetze-im-internet.de/patg/__73.html
+  - §75 https://www.gesetze-im-internet.de/patg/__75.html
+  - §82 https://www.gesetze-im-internet.de/patg/__82.html
+  - §110 https://www.gesetze-im-internet.de/patg/__110.html
+  - §111 https://www.gesetze-im-internet.de/patg/__111.html
+- ZPO: https://www.gesetze-im-internet.de/zpo/
+  - §520 https://www.gesetze-im-internet.de/zpo/__520.html
+  - §521 https://www.gesetze-im-internet.de/zpo/__521.html
+- GebrMG: https://www.gesetze-im-internet.de/gebrmg/
+
+---
+
+## Appendix B — coverage tally
+
+| Status | Count | Share |
+|---|---:|---:|
+| present-correct | 78 | 59 % |
+| present-wrong (DURATION) | 3 | 2 % |
+| present-wrong (anchor/sequence) | 5 | 4 % |
+| present-wrong (citation only) | 11 | 8 % |
+| court-set-mismodelled-as-fixed | 6 | 5 % |
+| **subtotal: still actionable** | **25** | **19 %** |
+| missing (statute defines, paliad doesn't) | 30 | (gap, vs 132 baseline) |
+| n/a (RoP / EPC / PatG section creates no time-limit) | 8 | 6 % |
+| present-correct, no fix needed | (78 above) | |
+
+**Headline figures for m:**
+
+- Of the 132 statutory deadlines paliad currently models, **25 carry
+  an actionable bug** (19%). Of those, **5 are user-visible
+  calendar-correctness bugs** (the 3 duration bugs + the 2
+  sequencing/anchor bugs head flagged + me). The other 20 are
+  citation drift or court-set mismodelling — fix-them-quietly
+  category.
+- An additional **30 statutory deadlines are not modelled at all**
+  (the missing list in §3). Of those, **~12 are ★★★ / ★★ frequency**
+  (Tier 1 in §10); the remaining ~18 are ★ specialist.
+- The 5 duration / sequencing bugs alone are **the most important
+  takeaway**: every UPC_REV proceeding, every UPC main-track appeal
+  respondent, and every DE-LG-Verletzung timeline tracked in paliad
+  today computes wrong dates.
+
+End of audit. Awaiting m's review of §9 Q1–Q13 + Tier 0 sign-off
+before fix-tasks (Wave 0) get cut.

docs/research-determinator-coverage-2026-05-08.md

@@ -0,0 +1,394 @@
+# Research — Determinator coverage audit (gaps + smart-navigation framing)
+
+**Author:** curie (researcher)
+**Date:** 2026-05-08
+**Task:** t-paliad-167 (Gitea m/paliad#26)
+**Mode:** read-only research; produces a gap matrix + design framing, not migrations.
+
+Builds on `docs/audit-upc-rop-deadlines-2026-05-08.md` (t-paliad-159) which drove from the UPC Rules of Procedure outward. This one drives from **paliad's own corpus** outward: every active rule, every firm-wide event_type, every cascade leaf — and asks "can a Determinator user actually reach this row?"
+
+m's prompt (verbatim, 2026-05-08 22:24 Determinator dogfooding):
+
+> We are still missing all kinds of orders in our decision tree. What do we need to do to cover everything? Can we maybe check what "options" we have covered in our tree and which we don't? I want to have a smart way to navigate people through the tree to determine what's next.
+
+---
+
+## 1. Scope and method
+
+**Five surfaces, three pathways.**
+
+paliad currently has three independent ways to land on a deadline:
+
+- **Pathway A — Fristenrechner (proceeding tree).** User picks a proceeding type (`UPC_INF`, `DE_NULL`, `EPA_OPP`, …) and a trigger date; the engine emits the entire timeline. Source: `paliad.deadline_rules` rows where the parent proceeding has `category='fristenrechner'` (19 active proceeding types).
+- **Pathway B — Determinator cascade.** User answers "what just happened?" by drilling 1-3 levels through `paliad.event_categories` (6 roots → 27 → 49 → 43 leaves; 103 leaves total). Each leaf maps to one or more `paliad.deadline_concepts` via `paliad.event_category_concepts`. Concepts then resolve to rules (`deadline_rules.concept_id`) and event_types (`deadline_concept_event_types`, mig 072).
+- **Pathway C — Trigger-event search.** Free-text `paliad.trigger_events` lookup (102 youpc-imported rows). Used by the t-paliad-086 "Was kommt nach…" mode and by autocomplete. Out of audit scope here — no Determinator surface uses it.
+
+**Reachability rule.** For this audit, "reachable from the Determinator cascade" means: there exists some leaf `L` in `event_categories` such that `event_category_concepts(L → C)` and either:
+- (rule-side) `deadline_rules.concept_id = C` for the rule under test, or
+- (event_type-side) `deadline_concept_event_types(C, E)` for the event_type under test.
+
+Concepts that exist but never appear in `event_category_concepts` are **dead-end concepts** — Pathway A may use them, Pathway B can't.
+
+**Inventory snapshot (live youpc Supabase, 2026-05-08 22:30):**
+
+| Surface | Rows | Notes |
+|---|---|---|
+| `proceeding_types` (`category='fristenrechner'`) | 19 | UPC×8, DE×5, EPA×2, EP×1, DPMA×3 |
+| `proceeding_types` (`category='litigation'`, legacy/dormant) | 7 | INF, REV, CCR, AMD, APM, APP, ZPO_CIVIL — see §2.1 |
+| `deadline_rules` active | 172 | 95 true deadlines (`duration_value > 0`), rest are anchors / court-set |
+| `deadline_rules` true deadlines, `category='fristenrechner'` only | **76** | The audit denominator |
+| `event_categories` active | 125 | 6 roots, 103 leaves |
+| `event_category_concepts` mappings | 153 | 45 distinct concepts in cascade |
+| `deadline_concepts` active | 57 | 45 in cascade, 12 dead-end |
+| `event_types` firm-wide active | 44 | 26 reachable, 18 unreachable |
+| `deadline_concept_event_types` (mig 072) | 32 rows / 25 concepts / 30 event_types | The Regel↔Typ junction |
+
+**Cascade root inventory (Pathway B entry chips):**
+
+| Root | Children | Leaves | Purpose |
+|---|---|---|---|
+| `cms-eingang` | gericht / gegenseite | 50 | Inbound — paper just landed |
+| `muendl-verhandlung` | geladen / gehalten / verlegt / zwischenverfahren | 4 | Hearing-pivot |
+| `beschluss-entscheidung` | (11 leaf decisions per forum) | 11 | Decision-pivot — duplicate of `cms-eingang.gericht.endentscheidung.*` |
+| `frist-verpasst` | upc / de-patg / de-zpo / epa / dpma | 5 | Wiedereinsetzung family |
+| `ich-moechte-einreichen` | klage / berufung / widerklage / spätere-schriftsätze / einspruch | 32 | Outbound — file something |
+| `sonstiges` | — | 1 (dangling, no concept) | Escape hatch |
+
+**Per-forum cascade depth:** UPC has 38 reachable leaves, DE 35, EPA 11, DPMA 7. The DE corpus is now within 8% of UPC's — the imbalance flagged in earlier audits is largely closed. EPA/DPMA remain underbuilt.
+
+---
+
+## 2. Inventory by jurisdiction
+
+Each section answers the same three questions: (a) which rules exist, (b) are they reachable from the cascade, (c) what's missing relative to a real practitioner's everyday surface area.
+
+### 2.1 Legacy / dormant proceedings (out of scope but worth flagging)
+
+The 7 `category='litigation'` proceedings (INF, REV, CCR, APM, AMD, APP, ZPO_CIVIL) carry **40 active rules** between them but:
+- 0 cascade references (`event_category_concepts.proceeding_type_code` never names them),
+- 0 concept_id linkage on any of their 18 true deadlines,
+- not surfaced in the Fristenrechner UI (filtered by `category='fristenrechner'` in `deadline_rule_service.go:740`).
+
+These rows are zombie taxonomy from migration 008/009 — superseded by the `UPC_*` / `DE_*` / `EPA_*` / `DPMA_*` family in mig 012/042/043/044. **Recommendation:** flag them `is_active=false` in a follow-up cleanup migration; they only confuse audits.
+
+The audit denominator is therefore **76 true Fristenrechner deadlines across 19 active proceedings**.
+
+### 2.2 UPC
+
+Most-mature jurisdiction. 8 proceedings, 40 true deadlines, 39 reachable from cascade.
+
+| Proceeding | True deadlines | Reachable | Notes |
+|---|---|---|---|
+| UPC_INF | 11 | 10 | `inf.app_to_amend` (RoP.030.1, 2mo) has no concept_id — Pathway A only |
+| UPC_REV | 9 | 9 | Plus 2 duration bugs flagged in t-paliad-159 (R.49.1 3→2mo, R.52 2→1mo) |
+| UPC_PI | 0 | n/a | All 4 rules are anchors / court-set (no calendar arithmetic) |
+| UPC_APP | 5 | 5 | 3 rule_code-drift bugs flagged in t-paliad-159 (R.224.1.a, R.224.2.a, R.235.2) |
+| UPC_DAMAGES | 3 | 3 | |
+| UPC_DISCOVERY | 3 | 3 | |
+| UPC_COST_APPEAL | 1 | 1 | Tree-end leaf still missing R.155 chain |
+| UPC_APP_ORDERS | 4 | 4 | R.224.2.b grounds-on-orders missing entirely (RoP audit gap 6) |
+
+**Cascade-side gaps that t-paliad-159 surfaced and remain open:**
+- R.19 Preliminary Objection (no leaf, no rule, no event_type — but `upc_preliminary_objection` event_type exists, archived from cascade)
+- R.197.3 Saisie review request, R.198/R.213 31d-or-20wd start-of-merits
+- R.262.2 Confidentiality response (14d) — daily occurrence in HLC infringement, completely absent from both pathways
+- R.333.2 Review of CMO (15d) — trigger event #16 exists, no rule, no leaf
+- R.353 Rectification (1mo) — trigger event #41 exists, no rule, no leaf
+- R.207.6.a / R.229.2 / R.71 Mängelbeseitigung — registry-correction family entirely missing
+- R.109.1 / R.109.4 / R.109.5 oral-hearing translation prep (only `before`-mode rules in the corpus)
+
+### 2.3 DE (Zivilgericht + Bundesinstanzen)
+
+5 proceedings, 22 true deadlines, all 22 reachable from cascade.
+
+| Proceeding | True deadlines | Reachable | Cascade entry |
+|---|---|---|---|
+| DE_INF | 6 | 6 | `cms-eingang.gegenseite.de-inf.*` + `urteil-de-inf-lg` |
+| DE_NULL | 5 | 5 | `cms-eingang.gegenseite.de-null.*` + `urteil-de-null-bpatg` |
+| DE_INF_OLG | 3 | 3 | `urteil-de-inf-lg` (Berufung-Begründung) |
+| DE_INF_BGH | 5 | 5 | `urteil-de-inf-olg` (NZB / NZB-Begründung / Revisionsfrist / Revisionsbegründung) |
+| DE_NULL_BGH | 3 | 3 | `urteil-de-null-bpatg` (Berufung BGH) |
+
+**Headline DE gaps (entirely uncovered by both pathways):**
+- **Hinweisbeschluss** — `cms-eingang.gericht.hinweisbeschluss` leaf exists and links to `response-to-preliminary-opinion` concept, but **no rule row computes a deadline from it**. The concept has 1 rule (`r79-further-stellungnahme`, 2mo) wired to EPA_OPP only. The DE Hinweisbeschluss deadline (4 weeks under §139 ZPO is judge-set; under § 522 ZPO Berufung-Hinweis is judge-set with min 2 weeks) is not in the rule corpus.
+- **Beweisbeschluss / Beweissicherungsanordnung (DE)** — `cms-eingang.gericht.anordnung` leaf exists but only links to `request-for-discretionary-review` (UPC R.220.3). No DE-side reaction (e.g. Stellungnahme nach Beweisaufnahme, § 411 ZPO 2-week comment on Sachverständigengutachten).
+- **Streitwertbeschluss** — neither cascade leaf nor rule. Streitwertbeschwerde is § 68 GKG, 6 months → frequent and unrepresented.
+- **Versäumnisurteil** — leaf `versaeumnisurteil` exists with concept `versaeumnisurteil-einspruch`, but the concept has 0 rules. The 2-week Einspruch deadline (§ 339 Abs. 1 ZPO) is documented in the concept text but doesn't compute. A user lands on the leaf and gets a hint card, no calendar entry.
+- **ZPO Klage as starting point** — Pathway A has a legacy `ZPO_CIVIL` proceeding (dormant per §2.1) but no live equivalent; Pathway B's `cms-eingang.gegenseite.de-inf.klageschrift` covers the *defendant*'s perspective only. A claimant entering "I just filed a Klageschrift" has no path.
+- **Schriftsatznachfristsetzung (§ 283 ZPO)** — concept `schriftsatznachreichung` exists in cascade with 0 rules; "court grants me a 3-week response window" produces no calendar entry.
+
+### 2.4 EPO
+
+2 active proceedings (EPA_OPP, EPA_APP) plus 1 grant-side outlier (EP_GRANT). 12 true deadlines, 8 reachable from cascade.
+
+| Proceeding | True deadlines | Reachable | Notes |
+|---|---|---|---|
+| EPA_OPP | 4 | 4 | Cascade entry via `cms-eingang.gegenseite.epa-opp.einspruchsschrift` + `entscheidung-epa-opp` |
+| EPA_APP | 4 | 4 | Cascade entry via `cms-eingang.gegenseite.epa-app` + `entscheidung-epa-boa` |
+| **EP_GRANT** | **4** | **0** | All 4 unreachable — concepts (`search-report`, `publication`, `request-for-examination`, `approval-and-translation`) have no `event_category_concepts` row |
+
+**EP_GRANT is the single biggest blanket-gap in the audit.** The 4 most fundamental EPO grant-side deadlines (R.70(1) examination request 6mo, Art. 93 publication, R.71(3) approval+translation 4mo, search-report 6mo) are computable in Pathway A but the cascade has zero entry points for them. A user landing on the Determinator says "EP-Anmeldung erteilt, was nun?" and finds nothing.
+
+**Headline EPO gaps (both pathways):**
+- **R.71(3) communication received** — `cms-eingang.gericht.rechtsverlust-epa` covers the *negative* outcome (Rechtsverlust → Weiterbehandlung/Wiedereinsetzung) but the *positive* outcome (Mitteilung nach R.71(3) → 4-month approval+translation) has no leaf. The concept exists (`approval-and-translation`) but no leaf binds it.
+- **R.94(3) examination-stage Bescheid** — entirely absent. Most-frequent EPO deadline in prosecution practice ("4-month period to respond to examination report"); no rule, no leaf, no event_type.
+- **EPO opposition reply** — event_type `epo_opposition_reply` exists, archived from cascade (no concept link). Pathway A's EPA_OPP has the rule but no Pathway B path.
+- **R.116 EPO oral-proceedings final-submissions** — covered (`r116-final-submissions` concept, 2 rules, leaf `muendl-verhandlung.geladen` + `ich-moechte-einreichen.spaetere-schriftsaetze.r116-eingaben`).
+- **Annual renewal fees (Art. 86 EPC)** — `epo_renewal_fee` event_type exists, archived from cascade. No concept, no rule.
+
+### 2.5 DPMA
+
+3 active proceedings (DPMA_OPP, DPMA_BPATG_BESCHWERDE, DPMA_BGH_RB). 6 true deadlines, all 6 reachable from cascade.
+
+| Proceeding | True deadlines | Reachable | Cascade entry |
+|---|---|---|---|
+| DPMA_OPP | 2 | 2 | `cms-eingang.gegenseite.dpma-opp` + `entscheidung-dpma` |
+| DPMA_BPATG_BESCHWERDE | 2 | 2 | `entscheidung-dpma` (Beschwerde) + `beschluss-bpatg-beschwerde` |
+| DPMA_BGH_RB | 2 | 2 | `beschluss-bpatg-beschwerde` (Rechtsbeschwerde) |
+
+**Headline DPMA gaps (both pathways):**
+- **Beanstandungsbescheid (Prüfungsverfahren)** — DPMA examination-stage objection notice with 4-month default response window (§ 45 PatG). No rule, no leaf, no event_type. Most-frequent DPMA deadline in real practice and entirely unrepresented.
+- **Aktenversendungsbescheid / Anhörungsbescheid (Einspruchsverfahren)** — § 59 PatG opposition oral-hearing summons; no leaf.
+- **Anmeldetag-Mitteilung / Recherchenbericht (DPMA)** — `dpma_examination_request` event_type exists with concept link to `request-for-examination`, but the concept is a Pathway-A-only dead-end (not in cascade).
+- **Patenterteilungsbeschluss** — no leaf for the positive grant decision (the negative-outcome Beschluss-BPatG path covers appeals, not the grant-stage event).
+
+### 2.6 Cross-cutting (procedural orders that span jurisdictions)
+
+The categories m specifically called out — "court orders that aren't entry events but procedural orders." Status:
+
+| Order type | UPC | DE | EPA | DPMA | Notes |
+|---|---|---|---|---|---|
+| Hinweisbeschluss / vorläufige Würdigung | concept-only | concept-only (no rule) | n/a | n/a | Leaf `cms-eingang.gericht.hinweisbeschluss` exists; the only rule wired to `response-to-preliminary-opinion` is EPA-side R.79. Judge-set period in DE/UPC; the leaf produces no calendar entry. |
+| Beweisbeschluss / Beweissicherungsanordnung | partial (R.196/R.197) | absent | n/a | n/a | Trigger events #26 / #44 / #65 / #66 exist; only R.197.3 (saisie review 30d) is missing as a rule. § 411 ZPO 2-week Stellungnahme-Frist nowhere. |
+| Streitwertbeschluss | n/a | absent | n/a | n/a | § 68 GKG 6-month Streitwertbeschwerde — common, unrepresented. |
+| Versäumnisurteil | n/a | leaf-only (no rule) | n/a | n/a | § 339 ZPO 2-week Einspruch — concept `versaeumnisurteil-einspruch` carries 0 rules. |
+| Case-Management-Order (R.220.1.c / § 273 ZPO) | partial | absent | n/a | n/a | UPC R.333.2 review-of-CMO 15d missing; trigger event #16 exists. |
+| Berichtigungsbeschluss / Tatbestandsberichtigung | absent | absent | n/a | n/a | UPC R.353 1mo / § 320 ZPO 2-week — both unrepresented. |
+| Konfidentialitätsantrag der Gegenseite | absent | n/a | n/a | n/a | UPC R.262.2 14d — high-frequency in HLC infringement work. |
+| R.71(3) communication | n/a | n/a | absent | n/a | The most-common EPO prosecution deadline. |
+| Examination-stage Bescheid | n/a | n/a | absent (R.94(3)) | absent (§ 45 PatG) | 4-month response. Single biggest *prosecution* gap. |
+| Mängelbeseitigung notification | absent (R.71/R.207.6.a/R.229.2) | absent | absent | absent | Cross-jurisdictional gap. Trigger event #71 exists for UPC. |
+| Translation lodging order | absent (R.109.5) | n/a | n/a | n/a | `before`-mode rules — schema supports, no data. |
+| Rechtsverlust-Mitteilung | n/a | n/a | leaf-only (covered) | n/a | Only EPA branch wired (`weiterbehandlung` + `wiedereinsetzung`). |
+
+---
+
+## 3. Cascade reachability tables
+
+### 3.1 Rule reachability per proceeding
+
+| Proceeding | True deadlines | No concept | Reachable | Unreachable (concept exists, not in cascade) |
+|---|---|---|---|---|
+| UPC_INF | 11 | 1 (`inf.app_to_amend`) | 10 | 0 |
+| UPC_REV | 9 | 0 | 9 | 0 |
+| UPC_APP | 5 | 0 | 5 | 0 |
+| UPC_DAMAGES | 3 | 0 | 3 | 0 |
+| UPC_DISCOVERY | 3 | 0 | 3 | 0 |
+| UPC_COST_APPEAL | 1 | 0 | 1 | 0 |
+| UPC_APP_ORDERS | 4 | 0 | 4 | 0 |
+| EP_GRANT | 4 | 0 | 0 | **4** |
+| DE_INF | 6 | 0 | 6 | 0 |
+| DE_NULL | 5 | 0 | 5 | 0 |
+| DE_INF_OLG | 3 | 0 | 3 | 0 |
+| DE_INF_BGH | 5 | 0 | 5 | 0 |
+| DE_NULL_BGH | 3 | 0 | 3 | 0 |
+| EPA_OPP | 4 | 0 | 4 | 0 |
+| EPA_APP | 4 | 0 | 4 | 0 |
+| DPMA_OPP | 2 | 0 | 2 | 0 |
+| DPMA_BPATG_BESCHWERDE | 2 | 0 | 2 | 0 |
+| DPMA_BGH_RB | 2 | 0 | 2 | 0 |
+| **Total** | **76** | **1** | **71** | **4** |
+
+**Reachability rate: 71/76 = 93.4 %.** The 5 unreachable rules concentrate in two clusters:
+- `UPC_INF.inf.app_to_amend` (RoP.030.1, 2mo) — no concept_id assigned. Recommended fix: link to `defence-to-application-to-amend` or create a new `application-to-amend` concept.
+- All 4 `EP_GRANT` rules — concepts exist (`search-report`, `publication`, `request-for-examination`, `approval-and-translation`) but none has an `event_category_concepts` row. Recommended fix: add an EP-Grant subtree under either `cms-eingang.gericht` or a new `ich-moechte-einreichen.ep-grant` branch.
+
+### 3.2 Event_type reachability (firm-wide active types only, n=44)
+
+**Reachable via cascade (26 of 44):**
+
+| Slug | Category | Jurisdiction |
+|---|---|---|
+| de_klageerwiderung | submission | DE |
+| dpma_appeal | submission | DPMA |
+| dpma_opposition | submission | DPMA |
+| epo_appeal_grounds, epo_appeal_notice, epo_opposition_filing | submission | EPO |
+| upc_application_for_cost_decision, upc_application_for_damages | submission | UPC |
+| upc_counterclaim_for_infringement, upc_counterclaim_for_revocation | submission | UPC |
+| upc_cross_appeal_2242a (×2 concepts) | submission | UPC |
+| upc_defence_to_amend_patent, upc_defence_to_revocation | submission | UPC |
+| upc_grounds_of_appeal_2242a (×2 concepts) | submission | UPC |
+| upc_protective_letter, upc_rejoinder_to_reply, upc_reply_to_defence | submission | UPC |
+| upc_reply_to_defence_to_amend_patent, upc_reply_to_defence_to_revocation | submission | UPC |
+| upc_request_to_lay_open_books | submission | UPC |
+| upc_statement_for_revocation, upc_statement_of_appeal_2201 | submission | UPC |
+| upc_statement_of_claim, upc_statement_of_defence | submission | UPC |
+| upc_statement_of_defence_no_ccr, upc_statement_of_defence_with_ccr | submission | UPC |
+
+**Unreachable (18 of 44):**
+
+| Slug | Category | Why unreachable |
+|---|---|---|
+| upc_decision_of_epo | decision | Concept missing, no junction row |
+| upc_decision_on_costs | decision | Junction → `cost-decision` concept; that concept is dead-end (not in cascade) |
+| upc_decision_on_merits | decision | No junction row |
+| upc_final_decision | decision | No junction row |
+| upc_oral_hearing | hearing | Junction → `oral-hearing` concept; dead-end |
+| upc_case_management_order | order | Junction → `order` concept; dead-end |
+| upc_order_lodge_translations | order | No junction row |
+| upc_summons_oral_hearing | service | No junction row |
+| upc_application_to_amend_patent | submission | No junction row (parallel to UPC_INF gap above) |
+| upc_defence_to_statement_dni, upc_statement_dni | submission | DNI family (RoP audit gap 23) — no rule, no concept, no leaf |
+| upc_grounds_of_appeal_2242b | submission | RoP audit gap 6 — R.224.2.b orders-track grounds entirely missing |
+| upc_preliminary_objection | submission | RoP audit gap 5 — R.19 entirely missing |
+| dpma_examination_request | submission | Junction → `request-for-examination`; dead-end |
+| epo_renewal_fee, contract_renewal | fee | No junction row, no concept |
+| epo_opposition_reply | submission | No junction row |
+| stellungnahme | submission | No junction row, no concept (generic catch-all) |
+
+**Pattern.** The 18 unreachable types split into three groups:
+- **Court-side trigger types (8/18)**: decisions, orders, hearings, summons. The cascade is *reaction*-oriented (clicking a leaf yields "what's next") and cannot represent these as endpoints because they are themselves the entry points of reaction trees. Adding them via the `ich-moechte-einreichen` root is structurally wrong; they're not user filings. Adding them via `cms-eingang.gericht` would require an explicit "tag this incoming court event" sub-mode that the Determinator currently doesn't have.
+- **Genuinely missing UPC content (5/18)**: DNI family, R.19 PO, R.224.2.b orders-track grounds, EP-grant `application_to_amend_patent`. These are real gaps the RoP audit already named.
+- **Prosecution-side gaps (5/18)**: EPO renewal fees, R.94(3) reply, DPMA examination request, generic Stellungnahme, contract renewal. Both pathways skip prosecution; the platform is litigation-first today.
+
+### 3.3 Cascade-side dangling (leaves with no concept attached)
+
+3 leaves carry no concept link:
+- `cms-eingang.gericht.bescheid-mit-frist` ("Bescheid mit explizit gesetzter Frist") — intentional escape hatch but produces no calendar entry. A user lands here when no specific Bescheid type matches; without a concept, no autofill, no "I'll do the math for you."
+- `muendl-verhandlung.verlegt` — when an oral hearing is rescheduled, no follow-on deadline (correct: judge re-issues with new date).
+- `sonstiges` — top-level "Anderes" escape hatch.
+
+These three leaves are the existing "not in the tree" UX — a user already CAN bottom out, but only with zero downstream support. §4 below proposes how to make those moments useful.
+
+### 3.4 Concept-side dead-ends (concepts with rules but no cascade entry)
+
+12 concepts have `is_active=true` and ≥1 rule attached but never appear in `event_category_concepts`:
+
+| Concept | Rules | Comment |
+|---|---|---|
+| `decision` | 14 | Generic decision-anchor — used by every proceeding's `*.decision` row. Not a reaction target. |
+| `oral-hearing` | 11 | Same as decision — anchor not reaction. |
+| `publication` | 3 | EP grant publication, A1/B1 dates. |
+| `order` | 2 | Generic order-anchor. |
+| `cost-decision` | 1 | R.157 fixation-of-costs. Should arguably be reachable since post-cost-decision reactions exist (`application-for-leave-to-appeal`); the leaf `kostenfestsetzung` already maps to `notice-of-appeal` and `application-for-leave-to-appeal`, so the *reaction* path is covered — `cost-decision` itself just doesn't need to be in the cascade. |
+| `preliminary-opinion` | 1 | EPA preliminary opinion — used by EPA_OPP. |
+| `grant` | 1 | EP grant decision. |
+| `filing` | 1 | EP filing date. |
+| `search-report` | 1 | EPO search-report 6mo period. |
+| `request-for-examination` | 1 | EPO R.70(1) 6mo. |
+| `approval-and-translation` | 1 | EPO R.71(3) 4mo. |
+| `communication-r71-3` | 1 | Same family as approval-and-translation; intermediate. |
+
+**Reading.** 8 of these are court-side anchors (decision, order, hearing, publication, grant, filing, search-report, preliminary-opinion) — by design not reactions, so their absence from the cascade is structurally correct. The remaining 4 are all the EP-grant family (request-for-examination, approval-and-translation, communication-r71-3, plus the implicit `publication` for EP_GRANT) — these *should* be reachable and currently aren't. Confirms §3.1's EP_GRANT cluster as the single biggest fixable cluster.
+
+---
+
+## 4. Smart-navigation framing — which pattern fits the gap distribution?
+
+Issue §3 names three candidate patterns:
+
+- **(P1) Free-text search at every cascade depth.** "Beweisbeschluss" → suggests closest leaves with a "that's not it" fallback.
+- **(P2) Persistent "Mein Ereignis ist nicht dabei" escape button.** Visible at every level → opens a manual entry form with rule-only / no-rule paths.
+- **(P3) Breadcrumb-aware "weiter unten suchen".** Flattens deeper levels into the current row's chip set when the user can't pick at the current depth.
+
+The gap distribution we just enumerated tells us which pattern earns its keep. There are four kinds of "I don't see my event" moments:
+
+**Type α — Real gap, content missing.** The user wants a real event paliad genuinely doesn't model (Streitwertbeschluss, R.19 PO, DPMA Beanstandungsbescheid, R.71(3), R.94(3), § 411 ZPO Stellungnahme nach Beweisaufnahme). Count: ~18-22 events from §2.6 plus the RoP audit's 25 missing. **What helps:** an escape that captures *what* the user wanted, so we can prioritise the right migration rather than guess. P2 + telemetry.
+
+**Type β — Reachable but mis-modelled cascade path.** The leaf exists, the user can't find it (different mental label, deeper than expected, wrong root). E.g. R.116 final submissions live under `muendl-verhandlung.geladen` AND `ich-moechte-einreichen.spaetere-schriftsaetze.r116-eingaben`; if the user starts at `cms-eingang` they hit a dead end. Or: Wiedereinsetzung is under `frist-verpasst.*` but a user might look under `ich-moechte-einreichen.spaetere-schriftsaetze`. **What helps:** P1 (search collapses the labelling problem) and P3 (flat-search within current branch when nothing matches).
+
+**Type γ — Court-side trigger event needs to be tagged, not reacted-to.** The user has a `upc_decision_on_merits` and wants to *file it as an event in their project*, not get a reaction list. The cascade doesn't model this — it always assumes "reaction wanted." Count: ~8 of the 18 unreachable event_types. **What helps:** none of P1/P2/P3 directly — this is a separate "tag, don't react" mode. Out of scope here but worth flagging.
+
+**Type δ — Dead-end leaf with no concept (the 3 dangling leaves).** User selected `bescheid-mit-frist` and lands on a content-free card. **What helps:** P2's "manual entry with rule-only path" is exactly the escape these leaves need — turn the dangle into a deliberate fall-through.
+
+### 4.1 Recommendation: **P2 + P1, in that order, with P3 as a stretch.**
+
+**Why P2 first.** Of the four types, only Type α (real content gaps) is genuinely closed by P2, but Type α is also the *only* type that produces actionable feedback for paliad's roadmap. A persistent "Ich finde mein Ereignis nicht" button at every cascade depth, opening a `<dialog>` with:
+- a free-text "What event are you trying to file/respond to?" input,
+- a date input,
+- "kein Regelwerk verfügbar" rule-only path that creates a deadline with `event_type=null, rule_id=null, manual_due_date=...`,
+- an opt-in checkbox "Mein Hinweis hilft, paliad zu verbessern" that posts the captured text to a (future) `paliad.coverage_gaps` table,
+
+…does three things at once: (a) unblocks the user immediately, (b) gives m a backlog that's *exactly* the prioritisation signal this audit can't provide alone (which gaps are real demand vs. theoretical RoP completeness), (c) repurposes the 3 dangling leaves and `sonstiges` from "looks broken" to "deliberate fall-through."
+
+Implementation cost: one `<dialog>` modal reused at every depth + one new `coverage_gap` event sink + one feedback-style admin view. The button itself can hang off the existing FilterBar primitive (t-paliad-163) or attach to the bottom of every cascade list.
+
+**Why P1 second.** Type β (mis-modelled paths) is the *quietest* failure mode — the user gives up before clicking anywhere relevant. Search would catch it but the gap data alone doesn't tell us how many such users exist. Layering P1 on top of P2 turns the captured "Mein Ereignis nicht dabei" texts into the very query corpus that powers fuzzy-search ranking. A search input at the top of every cascade level (`<input type="search">` filtering the current set of children + drilling into matching deeper leaves via FTS over `label_de` / `label_en` / `aliases` / linked `concept.aliases`) closes Type β cheaply once the corpus is decent.
+
+**Why P3 is a stretch.** "Flatten deeper levels into current chip-set" reads cleanly but trades depth for breadth: the cascade currently has 38 reachable UPC leaves under 2-3 levels — flattening to 38 chips at depth 1 produces analysis paralysis. The cascade's depth is a feature, not a bug. P3 is only worth building if telemetry from P2 shows a cluster of users bottoming out at level 2 with the *right* root selected. Defer.
+
+### 4.2 What this means for current scope
+
+- **m/paliad#25 (minkowski's row-by-row)** is orthogonal — that fixes individual rule rows. Keep that going.
+- **Type α gap fill** is a separate workstream driven by the Wave 1-5 RoP-audit sequencing in `audit-upc-rop-deadlines-2026-05-08.md` §6. The smart-navigation work doesn't replace it; it gives the work a feedback loop.
+- **Type γ (tag-don't-react)** is its own design problem — file as a separate ticket if/when it shows up in P2 telemetry.
+- **The 5 unreachable rules from §3.1** (4 EP_GRANT + 1 UPC_INF) should be fixed with a 5-row migration regardless of the navigation work. Independent. EP-grant in particular is the single change that lifts cascade reachability from 93.4 % to 100 % of the audited rule corpus.
+
+### 4.3 Suggested next steps (not implementation, just ordering)
+
+1. **5-row reachability migration** (no design needed): link `inf.app_to_amend` to `defence-to-application-to-amend` concept; add cascade leaves for the 4 EP_GRANT concepts under a new `ich-moechte-einreichen.ep-erteilung` subtree. Wave-0 alongside the t-paliad-159 duration bug fixes.
+2. **Inventor pass on P2 + P1** as one design ticket: persistent escape button + free-text search at each level + capture-table schema + admin view. This is where m's "smart navigation" intuition lives — keep P1 and P2 as a pair so the captured texts feed search ranking.
+3. **Type α gap fill** continues independently per RoP audit waves — capture-table data in (2) refines priorities after a few weeks of real use.
+4. **Defer P3 + Type γ** until telemetry justifies them.
+
+---
+
+## 5. Summary
+
+**Coverage today (n=76 true Fristenrechner deadlines across 19 active proceedings):**
+
+| Status | Count | Share |
+|---|---|---|
+| Reachable from cascade | 71 | 93 % |
+| No concept_id | 1 | 1 % |
+| Concept exists, dead-end | 4 | 5 % |
+
+**Event_type reachability (n=44 firm-wide active types):**
+
+| Status | Count | Share |
+|---|---|---|
+| Reachable | 26 | 59 % |
+| Unreachable | 18 | 41 % |
+
+**Headline gap categories** (entirely uncovered by both pathways, ordered by daily-practice frequency):
+
+1. EPO R.94(3) examination-stage Bescheid (4mo) — most-frequent EPO prosecution deadline, **completely absent**.
+2. EPO R.71(3) communication → approval+translation (4mo) — concept exists but no cascade entry.
+3. DPMA § 45 PatG Beanstandungsbescheid (4mo) — most-frequent DPMA prosecution deadline, completely absent.
+4. UPC R.262.2 confidentiality response (14d) — high-frequency in HLC infringement.
+5. DE Hinweisbeschluss reaction — leaf exists, no rule.
+6. DE Versäumnisurteil-Einspruch (§ 339 ZPO 2 weeks) — leaf exists, no rule.
+7. DE Streitwertbeschwerde (§ 68 GKG 6mo) — neither leaf nor rule.
+8. UPC R.19 Preliminary Objection (1mo) — neither pathway.
+9. UPC R.224.2.b grounds-on-orders-track (15d) — neither pathway.
+10. UPC R.353 Rectification (1mo) — neither pathway.
+11. UPC EP-grant family (R.70(1), Art. 93, R.71(3), search-report) — Pathway A only, no cascade entry.
+12. UPC R.109 oral-hearing translation prep (1mo / 2w / 2w `before`-mode) — schema-supported, no data.
+
+**Recommended smart-navigation pattern:** P2 (persistent "Ich finde mein Ereignis nicht" escape with capture) + P1 (free-text search per cascade level), in that order. P2 alone unblocks users and produces the feedback loop the rest of the gap-fill roadmap needs; P1 layered on top closes mis-labelling. P3 is over-scoped for current data.
+
+---
+
+## Appendix A — files consulted
+
+- `internal/services/deadline_rule_service.go` (proceeding-type filtering, `category='fristenrechner'` gate)
+- `internal/services/event_category_service.go` (cascade traversal)
+- `internal/services/fristenrechner.go` (Pathway A composer)
+- `internal/db/migrations/008_seed_proceeding_types.up.sql` (legacy 7 codes)
+- `internal/db/migrations/012_fristenrechner_rules.up.sql` (UPC/DE/EPA seed)
+- `internal/db/migrations/042_de_expansion_b3.up.sql` (DE_INF_OLG / DE_INF_BGH / DE_NULL_BGH)
+- `internal/db/migrations/043_de_instance_split_proceedings.up.sql`
+- `internal/db/migrations/044_dpma_proceedings.up.sql`
+- `internal/db/migrations/045_epa_gap_fill.up.sql`
+- `internal/db/migrations/048_event_categories.up.sql` (cascade seed)
+- `internal/db/migrations/049_event_categories_seed.up.sql`
+- `internal/db/migrations/051_proceeding_display_order.up.sql`
+- `internal/db/migrations/052_event_categories_rop_audit.up.sql` (cascade-side RoP fixes)
+- `internal/db/migrations/063_frist_verpasst_upc.up.sql` (R.320 leaf)
+- `internal/db/migrations/072_deadline_concept_event_types.up.sql` (Regel↔Typ junction)
+
+## Appendix B — companion audits
+
+- `docs/audit-upc-rop-deadlines-2026-05-08.md` — RoP-driven UPC audit (t-paliad-159, curie). Half the data for §2.2.
+- `docs/audit-fristenrechner-completeness-2026-04-30.md` — youpc-vs-paliad (t-paliad-084, curie).
+- `docs/design-deadline-data-model-2026-05-08.md` — current data-model design.

docs/t-paliad-207-followup-scope.md

@@ -0,0 +1,52 @@
+# t-paliad-207 follow-up scope — close-out assessment
+
+**Author:** fermi (inventor)
+**Date:** 2026-05-20
+**Verdict:** **(A) DONE** — interactive session scope is shipped; remaining tail is filed-or-fileable as discrete issues, not a fresh fermi slice.
+
+---
+
+## 0. What shipped under t-paliad-207
+
+Six substantive deliveries on `mai/fermi/interactive-session`, all merged to main as of 2026-05-20 morning:
+
+1. **Verfahrensablauf + Fristenrechner polish** — jurisdiction prefix on the picked proceeding, trigger-event label derived from the root rule, flag rows lifted to `/tools/verfahrensablauf`, rule references rendered as `youpc.org/laws#…` links via new `BuildLegalSourceURL`, `Vorab-Einrede → Einspruch` rename (DE i18n).
+2. **DE proceeding picker — sub-group headers** (`Verletzungsverfahren` / `Nichtigkeitsverfahren`) + parallel labels (`LG (1. Instanz)` / `OLG (Berufung)` / …).
+3. **mig 099** — drop the `with_po` flag from the two RoP 19 rules (Einspruch is always-available, not flag-gated).
+4. **mig 100** — `upc.inf.cfi.ccr` visible rule (`Nichtigkeitswiderklage`) so the CCR filing event surfaces when `with_ccr` is set; later corrected to `priority='optional'` via mig 101.
+5. **mig 101** — strip rule-cite brackets from the two Einspruch names + flip the CCR priority `informational → optional`.
+6. **mig 102** — track-aware sequence reshuffle on `upc.inf.cfi` so at any tied date the order is infringement (Replik) → revocation (Erwiderung Nichtigkeitswiderklage) → amendment.
+7. **Notes toggle** — `Hinweise anzeigen` checkbox in the view-toggle bar; compact ⓘ hover hint when off (default), inline `timeline-notes` block when on. `localStorage` shared across both tool pages.
+
+Filed two follow-up issues during the session:
+
+- **m/paliad#39** — link DE + EPA + EU rule references to `youpc.org/laws` (depends on youpc.org ingesting the corpus).
+- **m/paliad#41** — DE proceedings as one combined timeline per type (LG→OLG→BGH, BPatG→BGH) — corpus + spawn + de-duplication + multi-instance UI.
+
+## 1. Why (A) DONE
+
+Every concrete thing m surfaced in the session was addressed and merged. The two larger unaddressed asks — combined-timeline behaviour for DE proceedings, and DE/EPA rule-link coverage — are already captured in #39 and #41 with concrete scope notes. Neither belongs as a fermi "next slice" because:
+
+- **#41** is a corpus + UI design pass of its own (3 new spawn rules, de-duplication of the existing `de.inf.lg.berufung ↔ de.inf.olg.berufung` pair, multi-court picker shape, instance markers in the timeline body). That's its own design ticket, not a fermi follow-up.
+- **#39** is primarily a youpc.org-side ingest task; the paliad-side change is a 5-line `switch` extension once youpc serves the URLs. Wait for the dependency, then small.
+
+Everything else I surfaced in the read-only audit is either pre-existing (not introduced by this session) or speculative (no user complaint behind it).
+
+## 2. Optional tail — would file as discrete issues, not a fermi slice
+
+Surfacing these for completeness; none are blocking, and most would be small enough to either roll into the existing tickets or land as one-off polish:
+
+| # | Candidate | Size | Already covered? |
+|---|---|---|---|
+| 1 | **`legal_source` backfill on 47 unsourced active rules** — query: 4 of `upc.inf.cfi`, 4 of `upc.pi.cfi` (100% gap), 6 of `upc.rev.cfi`, others. Pre-condition for #39's links to bite. | Medium — corpus research per rule | Partially: huygens did the broader citation backfill in t-paliad-208 / mig 097. This is the remaining tail. |
+| 2 | **`upc.pi.cfi` corpus completeness audit** — all 4 of its rules lack `legal_source`; likely also missing the analogous track-of-decision spawn rules to `upc.apl.merits`. | Small audit, medium fix | No — would be a fresh task. |
+| 3 | **Touch-device fallback for the ⓘ hover hint** — `title=` attribute degrades poorly on phones (no hover, no tap-to-show). Either a click-to-popover variant, or accept the gap. | Tiny | No, but no user complaint yet. |
+| 4 | **R.46 mutatis-mutandis distinction in `upc.rev.cfi.prelim` description** — when mig 101 stripped the `(R. 19 i.V.m. R. 46)` cite, the legal nuance dropped from the user-visible name. Could be surfaced in the description text where it doesn't crowd the timeline cell. | Tiny (one row update) | No. |
+| 5 | **Save-modal warning on SoD + CCR double-check** — with mig 100's new `upc.inf.cfi.ccr` rule, a user can save both `sod` and `ccr` from the same modal and get two `paliad.deadlines` rows on the same date. Today's pre-uncheck behaviour for optional priority mitigates accidental double-write but doesn't surface the duplication actively. | Small | No. |
+| 6 | **Deferred slices from earlier design docs that touch this surface**: t-paliad-179 Slice 2-4 (variant chips, lane view, side-by-side compare on `/tools/verfahrensablauf`); t-paliad-169 "+ Eintrag" CTA on the SmartTimeline (project-bound) path. | Each a separate slice. | Yes — parked from their original tasks; would be revisited when m prioritises. |
+
+None of these warrant a "next fermi slice" right now. They're polish + corpus tail, and best handled as individual issues that m can pick from.
+
+## 3. Recommendation
+
+Close t-paliad-207. Fire fermi. The remaining tail (items 1–6 above) is appropriate as a small "polish backlog" m can dip into when relevant, but not a coherent unit of work that needs a parked inventor.

frontend/build.ts

@@ -4,24 +4,28 @@ import { renderIndex } from "./src/index";
 import { renderLogin } from "./src/login";
 import { renderKostenrechner } from "./src/kostenrechner";
 import { renderFristenrechner } from "./src/fristenrechner";
+import { renderVerfahrensablauf } from "./src/verfahrensablauf";
 import { renderDownloads } from "./src/downloads";
 import { renderLinks } from "./src/links";
 import { renderGlossary } from "./src/glossary";
 import { renderGebuehrentabellen } from "./src/gebuehrentabellen";
 import { renderChecklists } from "./src/checklists";
+import { renderChecklistsAuthor } from "./src/checklists-author";
 import { renderChecklistsDetail } from "./src/checklists-detail";
 import { renderChecklistsInstance } from "./src/checklists-instance";
 import { renderCourts } from "./src/courts";
 import { renderProjects } from "./src/projects";
 import { renderProjectsNew } from "./src/projects-new";
 import { renderProjectsDetail } from "./src/projects-detail";
+import { renderProjectsChart } from "./src/projects-chart";
+import { renderSubmissionDraft } from "./src/submission-draft";
+import { renderSubmissionsIndex } from "./src/submissions-index";
+import { renderSubmissionsNew } from "./src/submissions-new";
 import { renderEvents } from "./src/events";
 import { renderDeadlinesNew } from "./src/deadlines-new";
 import { renderDeadlinesDetail } from "./src/deadlines-detail";
-import { renderDeadlinesCalendar } from "./src/deadlines-calendar";
 import { renderAppointmentsNew } from "./src/appointments-new";
 import { renderAppointmentsDetail } from "./src/appointments-detail";
-import { renderAppointmentsCalendar } from "./src/appointments-calendar";
 import { renderSettings } from "./src/settings";
 import { renderDashboard } from "./src/dashboard";
 import { renderAgenda } from "./src/agenda";
@@ -40,8 +44,12 @@ import { renderAdminEmailTemplatesEdit } from "./src/admin-email-templates-edit"
 import { renderAdminEventTypes } from "./src/admin-event-types";
 import { renderAdminApprovalPolicies } from "./src/admin-approval-policies";
 import { renderAdminBroadcasts } from "./src/admin-broadcasts";
+import { renderAdminRulesList } from "./src/admin-rules-list";
+import { renderAdminRulesEdit } from "./src/admin-rules-edit";
+import { renderAdminRulesExport } from "./src/admin-rules-export";
 import { renderPaliadin } from "./src/paliadin";
 import { renderAdminPaliadin } from "./src/admin-paliadin";
+import { renderAdminBackups } from "./src/admin-backups";
 import { renderNotFound } from "./src/notfound";
 
 const DIST = join(import.meta.dir, "dist");
@@ -234,24 +242,28 @@ async function build() {
       join(import.meta.dir, "src/client/login.ts"),
       join(import.meta.dir, "src/client/kostenrechner.ts"),
       join(import.meta.dir, "src/client/fristenrechner.ts"),
+      join(import.meta.dir, "src/client/verfahrensablauf.ts"),
       join(import.meta.dir, "src/client/downloads.ts"),
       join(import.meta.dir, "src/client/links.ts"),
       join(import.meta.dir, "src/client/glossary.ts"),
       join(import.meta.dir, "src/client/gebuehrentabellen.ts"),
       join(import.meta.dir, "src/client/checklists.ts"),
+      join(import.meta.dir, "src/client/checklists-author.ts"),
       join(import.meta.dir, "src/client/checklists-detail.ts"),
       join(import.meta.dir, "src/client/checklists-instance.ts"),
       join(import.meta.dir, "src/client/courts.ts"),
       join(import.meta.dir, "src/client/projects.ts"),
       join(import.meta.dir, "src/client/projects-new.ts"),
       join(import.meta.dir, "src/client/projects-detail.ts"),
+      join(import.meta.dir, "src/client/projects-chart.ts"),
+      join(import.meta.dir, "src/client/submission-draft.ts"),
+      join(import.meta.dir, "src/client/submissions-index.ts"),
+      join(import.meta.dir, "src/client/submissions-new.ts"),
       join(import.meta.dir, "src/client/events.ts"),
       join(import.meta.dir, "src/client/deadlines-new.ts"),
       join(import.meta.dir, "src/client/deadlines-detail.ts"),
-      join(import.meta.dir, "src/client/deadlines-calendar.ts"),
       join(import.meta.dir, "src/client/appointments-new.ts"),
       join(import.meta.dir, "src/client/appointments-detail.ts"),
-      join(import.meta.dir, "src/client/appointments-calendar.ts"),
       join(import.meta.dir, "src/client/settings.ts"),
       join(import.meta.dir, "src/client/dashboard.ts"),
       join(import.meta.dir, "src/client/agenda.ts"),
@@ -270,6 +282,9 @@ async function build() {
       join(import.meta.dir, "src/client/admin-event-types.ts"),
       join(import.meta.dir, "src/client/admin-approval-policies.ts"),
       join(import.meta.dir, "src/client/admin-broadcasts.ts"),
+      join(import.meta.dir, "src/client/admin-rules-list.ts"),
+      join(import.meta.dir, "src/client/admin-rules-edit.ts"),
+      join(import.meta.dir, "src/client/admin-rules-export.ts"),
       join(import.meta.dir, "src/client/paliadin.ts"),
       // t-paliad-161 — inline Paliadin widget. Loaded via the
       // PaliadinWidget component on every authenticated page, so the
@@ -277,6 +292,7 @@ async function build() {
       // skip the re-fetch.
       join(import.meta.dir, "src/client/paliadin-widget.ts"),
       join(import.meta.dir, "src/client/admin-paliadin.ts"),
+      join(import.meta.dir, "src/client/admin-backups.ts"),
       join(import.meta.dir, "src/client/notfound.ts"),
     ],
     outdir: join(DIST, "assets"),
@@ -354,17 +370,23 @@ async function build() {
   await Bun.write(join(DIST, "login.html"), renderLogin("login.js"));
   await Bun.write(join(DIST, "kostenrechner.html"), renderKostenrechner());
   await Bun.write(join(DIST, "fristenrechner.html"), renderFristenrechner());
+  await Bun.write(join(DIST, "verfahrensablauf.html"), renderVerfahrensablauf());
   await Bun.write(join(DIST, "downloads.html"), renderDownloads());
   await Bun.write(join(DIST, "links.html"), renderLinks());
   await Bun.write(join(DIST, "glossary.html"), renderGlossary());
   await Bun.write(join(DIST, "gebuehrentabellen.html"), renderGebuehrentabellen());
   await Bun.write(join(DIST, "checklists.html"), renderChecklists());
+  await Bun.write(join(DIST, "checklists-author.html"), renderChecklistsAuthor());
   await Bun.write(join(DIST, "checklists-detail.html"), renderChecklistsDetail());
   await Bun.write(join(DIST, "checklists-instance.html"), renderChecklistsInstance());
   await Bun.write(join(DIST, "courts.html"), renderCourts());
   await Bun.write(join(DIST, "projects.html"), renderProjects());
   await Bun.write(join(DIST, "projects-new.html"), renderProjectsNew());
   await Bun.write(join(DIST, "projects-detail.html"), renderProjectsDetail());
+  await Bun.write(join(DIST, "projects-chart.html"), renderProjectsChart());
+  await Bun.write(join(DIST, "submission-draft.html"), renderSubmissionDraft());
+  await Bun.write(join(DIST, "submissions-index.html"), renderSubmissionsIndex());
+  await Bun.write(join(DIST, "submissions-new.html"), renderSubmissionsNew());
   // t-paliad-115 — shared EventsPage at the canonical /events URL.
   // One HTML output; defaultType="all" baked in. Sidebar Fristen /
   // Termine entries point at /events?type=… and events.ts re-highlights
@@ -372,10 +394,8 @@ async function build() {
   await Bun.write(join(DIST, "events.html"), renderEvents());
   await Bun.write(join(DIST, "deadlines-new.html"), renderDeadlinesNew());
   await Bun.write(join(DIST, "deadlines-detail.html"), renderDeadlinesDetail());
-  await Bun.write(join(DIST, "deadlines-calendar.html"), renderDeadlinesCalendar());
   await Bun.write(join(DIST, "appointments-new.html"), renderAppointmentsNew());
   await Bun.write(join(DIST, "appointments-detail.html"), renderAppointmentsDetail());
-  await Bun.write(join(DIST, "appointments-calendar.html"), renderAppointmentsCalendar());
   await Bun.write(join(DIST, "settings.html"), renderSettings());
   await Bun.write(join(DIST, "dashboard.html"), renderDashboard());
   await Bun.write(join(DIST, "agenda.html"), renderAgenda());
@@ -394,8 +414,12 @@ async function build() {
   await Bun.write(join(DIST, "admin-event-types.html"), renderAdminEventTypes());
   await Bun.write(join(DIST, "admin-approval-policies.html"), renderAdminApprovalPolicies());
   await Bun.write(join(DIST, "admin-broadcasts.html"), renderAdminBroadcasts());
+  await Bun.write(join(DIST, "admin-rules-list.html"), renderAdminRulesList());
+  await Bun.write(join(DIST, "admin-rules-edit.html"), renderAdminRulesEdit());
+  await Bun.write(join(DIST, "admin-rules-export.html"), renderAdminRulesExport());
   await Bun.write(join(DIST, "paliadin.html"), renderPaliadin());
   await Bun.write(join(DIST, "admin-paliadin.html"), renderAdminPaliadin());
+  await Bun.write(join(DIST, "admin-backups.html"), renderAdminBackups());
   await Bun.write(join(DIST, "notfound.html"), renderNotFound());
 
   // Append ?v=<buildVersion> to every /assets/*.js and /assets/*.css URL in

frontend/public/patentstyle/index.html

@@ -0,0 +1,126 @@
+<!DOCTYPE html>
+<html lang="de">
+<head>
+<meta charset="utf-8">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<title>HL Patents Style</title>
+<style>
+  :root {
+    --bg: #002236;
+    --fg: #e8e8ed;
+    --muted: #8a9aa6;
+    --accent: #bff355;
+    --rule: #0f3a55;
+  }
+  * { box-sizing: border-box; }
+  html, body { margin: 0; padding: 0; background: var(--bg); color: var(--fg); }
+  body {
+    font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Inter, sans-serif;
+    line-height: 1.55;
+    font-size: 17px;
+  }
+  main {
+    max-width: 720px;
+    margin: 0 auto;
+    padding: 4rem 1.5rem 6rem;
+  }
+  h1 {
+    font-size: 2.25rem;
+    margin: 0 0 0.25rem;
+    letter-spacing: -0.02em;
+  }
+  h1 .accent { color: var(--accent); }
+  .lead {
+    color: var(--muted);
+    margin: 0 0 3rem;
+    font-size: 1.05rem;
+  }
+  h2 {
+    font-size: 1.1rem;
+    text-transform: uppercase;
+    letter-spacing: 0.08em;
+    color: var(--accent);
+    margin: 2.5rem 0 0.75rem;
+    border-bottom: 1px solid var(--rule);
+    padding-bottom: 0.5rem;
+  }
+  ul { padding-left: 1.25rem; margin: 0.5rem 0 1rem; }
+  li { margin: 0.35rem 0; }
+  p { margin: 0.6rem 0; }
+  a { color: var(--accent); text-decoration: none; border-bottom: 1px solid transparent; }
+  a:hover { border-bottom-color: var(--accent); }
+  code, kbd {
+    font-family: ui-monospace, "SF Mono", Menlo, Consolas, monospace;
+    font-size: 0.9em;
+    background: #0a2d44;
+    padding: 0.1em 0.35em;
+    border-radius: 3px;
+    color: var(--accent);
+  }
+  .download {
+    display: inline-block;
+    margin-top: 0.5rem;
+    padding: 0.7rem 1.2rem;
+    background: var(--accent);
+    color: var(--bg);
+    font-weight: 600;
+    border-radius: 4px;
+    border: 0;
+  }
+  .download:hover { border-bottom: 0; filter: brightness(1.05); }
+  footer {
+    margin-top: 4rem;
+    padding-top: 1.5rem;
+    border-top: 1px solid var(--rule);
+    color: var(--muted);
+    font-size: 0.85rem;
+  }
+  footer code { color: var(--muted); background: transparent; padding: 0; }
+</style>
+</head>
+<body>
+<main>
+
+<h1>HL <span class="accent">Patents Style</span></h1>
+<p class="lead">Das Word-Template fuer Patentschriftsaetze bei Hogan Lovells.</p>
+
+<h2>Was es kann</h2>
+<ul>
+  <li>Vorlagen-Stile fuer alle gaengigen Schriftsatz-Bausteine (Headings, Randnummern, Antraege, Exhibits)</li>
+  <li>BuildingBlocks: ueber das Ribbon vorgefertigte Abschnitte einfuegen</li>
+  <li>Sprachumschaltung DE / EN per Ribbon-Toggle</li>
+  <li>Scaffolding: kompletter Schriftsatz-Aufbau mit einem Klick</li>
+  <li>Margin Numbers, Exhibit-Nummerierung, SEQ-Felder</li>
+  <li>Auto-Update ueber das Ribbon (siehe unten)</li>
+</ul>
+
+<h2>Aktualisierungen</h2>
+<p>Im Ribbon-Tab <em>HL Patent</em> &rarr; Gruppe <em>Manage</em> &rarr; <kbd>Check for Updates</kbd>. Holt das aktuelle Manifest von diesem Server, prueft die Version, laedt die neue <code>.dotm</code> nur bei Bedarf, verifiziert per SHA256, installiert. Nach dem Update Word neu starten.</p>
+
+<h2>Frische Installation</h2>
+<p>Wer das Template noch nicht installiert hat, laedt einmal manuell die aktuelle Version und kopiert sie in den Word-Startup-Ordner. Den Rest macht die <code>InstallTemplate</code>-Routine im Template selbst.</p>
+<p><a class="download" href="HL-Patents-Style.dotm" download>HL Patents Style.dotm herunterladen</a></p>
+
+<h2>Hilfe &amp; Feedback</h2>
+<p>Fehler, Wuensche, Stilfragen, Build-Probleme: <a href="mailto:matthias.siebels@hoganlovells.com?subject=HL%20Patents%20Style">matthias.siebels@hoganlovells.com</a></p>
+
+<footer>
+  <p>Update-Endpoint: <code>paliad.msbls.de/patentstyle/</code> &middot; Mirror: <code>hihlc.msbls.de/patentstyle/</code></p>
+  <p id="ver"></p>
+</footer>
+
+<script>
+  // Best-effort: show the currently-served version
+  fetch('version.json', { cache: 'no-cache' })
+    .then(r => r.ok ? r.json() : null)
+    .then(j => {
+      if (j && j.version) {
+        document.getElementById('ver').textContent = 'Aktuell ausgeliefert: ' + j.version;
+      }
+    })
+    .catch(() => {});
+</script>
+
+</main>
+</body>
+</html>

frontend/public/patentstyle/version.json

@@ -0,0 +1,5 @@
+{
+  "version": "v0.260518",
+  "dotm_url": "https://paliad.msbls.de/patentstyle/HL-Patents-Style.dotm",
+  "sha256": "5CEA98A29D2FD6D9970B9A2499054DF52685A1116459E07F9290B0D0ADD521F4"
+}

frontend/src/admin-backups.tsx

@@ -0,0 +1,96 @@
+import { h } from "./jsx";
+import { Sidebar } from "./components/Sidebar";
+import { PaliadinWidget } from "./components/PaliadinWidget";
+import { BottomNav } from "./components/BottomNav";
+import { Footer } from "./components/Footer";
+import { PWAHead } from "./components/PWAHead";
+
+// Backup Mode admin page (t-paliad-246 / m/paliad#77 Slice A).
+//
+// global_admin only — gated by adminGate(...) in handlers.go. Shows the
+// chronological list of backup runs (one row per kind in
+// {scheduled, on_demand}) plus a button to kick off an on-demand backup.
+// Catalog rows + the "run now" action are fetched client-side via
+// /api/admin/backups.
+export function renderAdminBackups(): string {
+  return "<!DOCTYPE html>" + (
+    <html lang="de">
+      <head>
+        <meta charset="UTF-8" />
+        <meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover" />
+        <meta name="theme-color" content="#BFF355" />
+        <meta name="apple-mobile-web-app-capable" content="yes" />
+        <meta name="apple-mobile-web-app-status-bar-style" content="default" />
+        <PWAHead />
+        <title data-i18n="admin.backups.title">Backups &mdash; Paliad</title>
+        <link rel="stylesheet" href="/assets/global.css" />
+      </head>
+      <body className="has-sidebar">
+        <Sidebar currentPath="/admin/backups" />
+        <BottomNav currentPath="/admin/backups" />
+
+        <main>
+          <section className="tool-page">
+            <div className="container">
+              <div className="tool-header">
+                <div>
+                  <h1 data-i18n="admin.backups.heading">Backups</h1>
+                  <p className="tool-subtitle" data-i18n="admin.backups.subtitle">
+                    Vollst&auml;ndige Snapshots aller Daten &mdash; manuell oder zeitgesteuert.
+                  </p>
+                </div>
+                <div>
+                  <button
+                    className="btn-primary"
+                    id="admin-backups-run-btn"
+                    type="button"
+                    data-i18n="admin.backups.run_now"
+                  >
+                    Backup jetzt erstellen
+                  </button>
+                </div>
+              </div>
+
+              <div id="admin-backups-feedback" className="form-msg" style="display:none" />
+
+              <div className="entity-table-wrap">
+                <table className="entity-table entity-table--readonly">
+                  <thead>
+                    <tr>
+                      <th data-i18n="admin.backups.col.started">Erstellt</th>
+                      <th data-i18n="admin.backups.col.kind">Auslöser</th>
+                      <th data-i18n="admin.backups.col.status">Status</th>
+                      <th data-i18n="admin.backups.col.requested_by">Angefordert von</th>
+                      <th data-i18n="admin.backups.col.size">Gr&ouml;&szlig;e</th>
+                      <th data-i18n="admin.backups.col.rows">Zeilen</th>
+                      <th data-i18n="admin.backups.col.actions">Aktion</th>
+                    </tr>
+                  </thead>
+                  <tbody id="admin-backups-tbody">
+                    <tr>
+                      <td colspan={7} data-i18n="admin.backups.loading">Lade &hellip;</td>
+                    </tr>
+                  </tbody>
+                </table>
+              </div>
+
+              <div className="entity-empty" id="admin-backups-empty" style="display:none">
+                <p data-i18n="admin.backups.empty">Noch keine Backups vorhanden.</p>
+              </div>
+
+              <p className="tool-footer-note" id="admin-backups-footer">
+                <span data-i18n="admin.backups.footer.note">
+                  Geplante Backups werden in einer sp&auml;teren Slice aktiviert. Manuelle Backups stehen jetzt zur Verf&uuml;gung.
+                </span>
+              </p>
+            </div>
+          </section>
+        </main>
+
+        <Footer />
+        <PaliadinWidget />
+        <script src="/assets/admin-backups.js"></script>
+      </body>
+    </html>
+  );
+}

frontend/src/admin-rules-edit.tsx

@@ -0,0 +1,352 @@
+import { h } from "./jsx";
+import { Sidebar } from "./components/Sidebar";
+import { PaliadinWidget } from "./components/PaliadinWidget";
+import { BottomNav } from "./components/BottomNav";
+import { Footer } from "./components/Footer";
+import { PWAHead } from "./components/PWAHead";
+
+// /admin/rules/{id}/edit — Slice 11b (t-paliad-192). Form for the full
+// 37-column rule row plus a side panel with the preview widget and the
+// audit-log timeline. Lifecycle action bar at the bottom adapts to the
+// rule's current state (draft/published/archived). Every write goes
+// through a reason modal that enforces the ≥10-char rule from Slice 11a
+// edge case #4.
+//
+// The id of the rule is parsed from the URL path on hydration —
+// frontend never reads it from a server-injected blob, so the static
+// HTML shell is reusable for every rule. condition_expr ships with a
+// raw JSON textarea + a simple AND/OR/NOT tree-builder (toggle).
+export function renderAdminRulesEdit(): string {
+  return "<!DOCTYPE html>" + (
+    <html lang="de">
+      <head>
+        <meta charset="UTF-8" />
+        <meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover" />
+        <meta name="theme-color" content="#BFF355" />
+        <meta name="apple-mobile-web-app-capable" content="yes" />
+        <meta name="apple-mobile-web-app-status-bar-style" content="default" />
+        <PWAHead />
+        <title data-i18n="admin.rules.edit.title">Regel bearbeiten &mdash; Paliad</title>
+        <link rel="stylesheet" href="/assets/global.css" />
+      </head>
+      <body className="has-sidebar">
+        <Sidebar currentPath="/admin/rules" />
+        <BottomNav currentPath="/admin/rules" />
+
+        <main>
+          <section className="tool-page">
+            <div className="container">
+              <div className="tool-header admin-rules-edit-header">
+                <div>
+                  <p className="admin-rules-breadcrumb">
+                    <a href="/admin/rules" data-i18n="admin.rules.edit.breadcrumb">&larr; Regeln verwalten</a>
+                  </p>
+                  <h1 id="rules-edit-heading" data-i18n="admin.rules.edit.heading.loading">Regel laden...</h1>
+                  <div className="admin-rules-edit-meta">
+                    <span id="rules-edit-lifecycle" className="admin-rules-pill admin-rules-pill-draft" />
+                    <span id="rules-edit-id" className="admin-rules-edit-uuid" />
+                  </div>
+                </div>
+              </div>
+
+              <div id="rules-edit-feedback" className="form-msg" style="display:none" />
+
+              <div className="admin-rules-edit-grid">
+                <form id="rules-edit-form" className="entity-form admin-rules-edit-form" autocomplete="off">
+                  <fieldset className="admin-rules-fieldset">
+                    <legend data-i18n="admin.rules.edit.section.identity">Identit&auml;t</legend>
+                    <div className="admin-rules-edit-row">
+                      <div className="form-field">
+                        <label htmlFor="f-name" data-i18n="admin.rules.edit.field.name">Name (DE)</label>
+                        <input type="text" id="f-name" className="admin-rules-input" />
+                      </div>
+                      <div className="form-field">
+                        <label htmlFor="f-name-en" data-i18n="admin.rules.edit.field.name_en">Name (EN)</label>
+                        <input type="text" id="f-name-en" className="admin-rules-input" />
+                      </div>
+                    </div>
+                    <div className="form-field">
+                      <label htmlFor="f-description" data-i18n="admin.rules.edit.field.description">Beschreibung</label>
+                      <textarea id="f-description" className="admin-rules-input" rows={2} />
+                    </div>
+                    <div className="admin-rules-edit-row">
+                      <div className="form-field">
+                        <label htmlFor="f-submission-code" data-i18n="admin.rules.edit.field.submission_code">Submission Code / Einreichung-Kennung</label>
+                        <input type="text" id="f-submission-code" className="admin-rules-input" readonly placeholder="z. B. upc.inf.cfi.soc" />
+                      </div>
+                      <div className="form-field">
+                        <label htmlFor="f-rule-code" data-i18n="admin.rules.edit.field.rule_code">Rechtsgrundlage (Kurzform)</label>
+                        <input type="text" id="f-rule-code" className="admin-rules-input" placeholder="z. B. RoP.151" />
+                      </div>
+                      <div className="form-field">
+                        <label htmlFor="f-legal-source" data-i18n="admin.rules.edit.field.legal_source">Rechtsgrundlage (Langform)</label>
+                        <input type="text" id="f-legal-source" className="admin-rules-input" placeholder="z. B. UPC.RoP.151" />
+                      </div>
+                    </div>
+                  </fieldset>
+
+                  <fieldset className="admin-rules-fieldset">
+                    <legend data-i18n="admin.rules.edit.section.proceeding">Verfahren &amp; Trigger</legend>
+                    <div className="admin-rules-edit-row">
+                      <div className="form-field">
+                        <label htmlFor="f-proceeding" data-i18n="admin.rules.edit.field.proceeding">Verfahrenstyp</label>
+                        <select id="f-proceeding" className="admin-rules-select">
+                          <option value="" data-i18n="admin.rules.edit.field.proceeding.none">—</option>
+                        </select>
+                      </div>
+                      <div className="form-field">
+                        <label htmlFor="f-trigger" data-i18n="admin.rules.edit.field.trigger">Trigger-Ereignis</label>
+                        <select id="f-trigger" className="admin-rules-select">
+                          <option value="" data-i18n="admin.rules.edit.field.trigger.none">—</option>
+                        </select>
+                      </div>
+                    </div>
+                    <div className="admin-rules-edit-row">
+                      <div className="form-field">
+                        <label htmlFor="f-parent" data-i18n="admin.rules.edit.field.parent">Parent-Regel (UUID)</label>
+                        <input type="text" id="f-parent" className="admin-rules-input" placeholder="UUID oder leer" />
+                      </div>
+                      <div className="form-field">
+                        <label htmlFor="f-concept" data-i18n="admin.rules.edit.field.concept">Konzept (UUID)</label>
+                        <input type="text" id="f-concept" className="admin-rules-input" placeholder="UUID oder leer" />
+                      </div>
+                      <div className="form-field">
+                        <label htmlFor="f-sequence" data-i18n="admin.rules.edit.field.sequence_order">Reihenfolge</label>
+                        <input type="number" id="f-sequence" className="admin-rules-input" min="0" />
+                      </div>
+                    </div>
+                  </fieldset>
+
+                  <fieldset className="admin-rules-fieldset">
+                    <legend data-i18n="admin.rules.edit.section.timing">Berechnung</legend>
+                    <div className="admin-rules-edit-row">
+                      <div className="form-field">
+                        <label htmlFor="f-duration" data-i18n="admin.rules.edit.field.duration_value">Dauer</label>
+                        <input type="number" id="f-duration" className="admin-rules-input" min="0" />
+                      </div>
+                      <div className="form-field">
+                        <label htmlFor="f-duration-unit" data-i18n="admin.rules.edit.field.duration_unit">Einheit</label>
+                        <select id="f-duration-unit" className="admin-rules-select">
+                          <option value="days">days</option>
+                          <option value="weeks">weeks</option>
+                          <option value="months">months</option>
+                          <option value="working_days">working_days</option>
+                        </select>
+                      </div>
+                      <div className="form-field">
+                        <label htmlFor="f-timing" data-i18n="admin.rules.edit.field.timing">Timing</label>
+                        <select id="f-timing" className="admin-rules-select">
+                          <option value="">—</option>
+                          <option value="after">after</option>
+                          <option value="before">before</option>
+                        </select>
+                      </div>
+                      <div className="form-field">
+                        <label htmlFor="f-combine-op" data-i18n="admin.rules.edit.field.combine_op">Combine-Op</label>
+                        <select id="f-combine-op" className="admin-rules-select">
+                          <option value="">—</option>
+                          <option value="max">max</option>
+                          <option value="min">min</option>
+                        </select>
+                      </div>
+                    </div>
+                    <div className="admin-rules-edit-row">
+                      <div className="form-field">
+                        <label htmlFor="f-alt-duration" data-i18n="admin.rules.edit.field.alt_duration_value">Alt-Dauer</label>
+                        <input type="number" id="f-alt-duration" className="admin-rules-input" min="0" />
+                      </div>
+                      <div className="form-field">
+                        <label htmlFor="f-alt-duration-unit" data-i18n="admin.rules.edit.field.alt_duration_unit">Alt-Einheit</label>
+                        <select id="f-alt-duration-unit" className="admin-rules-select">
+                          <option value="">—</option>
+                          <option value="days">days</option>
+                          <option value="weeks">weeks</option>
+                          <option value="months">months</option>
+                          <option value="working_days">working_days</option>
+                        </select>
+                      </div>
+                      <div className="form-field">
+                        <label htmlFor="f-alt-rule-code" data-i18n="admin.rules.edit.field.alt_rule_code">Alt-Rule-Code</label>
+                        <input type="text" id="f-alt-rule-code" className="admin-rules-input" />
+                      </div>
+                      <div className="form-field">
+                        <label htmlFor="f-anchor-alt" data-i18n="admin.rules.edit.field.anchor_alt">Alt-Anchor</label>
+                        <input type="text" id="f-anchor-alt" className="admin-rules-input" />
+                      </div>
+                    </div>
+                  </fieldset>
+
+                  <fieldset className="admin-rules-fieldset">
+                    <legend data-i18n="admin.rules.edit.section.party">Partei &amp; Ereignis</legend>
+                    <div className="admin-rules-edit-row">
+                      <div className="form-field">
+                        <label htmlFor="f-primary-party" data-i18n="admin.rules.edit.field.primary_party">Prim&auml;re Partei</label>
+                        <input type="text" id="f-primary-party" className="admin-rules-input" />
+                      </div>
+                      <div className="form-field">
+                        <label htmlFor="f-event-type" data-i18n="admin.rules.edit.field.event_type">Event-Typ (frei)</label>
+                        <input type="text" id="f-event-type" className="admin-rules-input" />
+                      </div>
+                    </div>
+                  </fieldset>
+
+                  <fieldset className="admin-rules-fieldset">
+                    <legend data-i18n="admin.rules.edit.section.display">Anzeige &amp; Notizen</legend>
+                    <div className="form-field">
+                      <label htmlFor="f-notes" data-i18n="admin.rules.edit.field.deadline_notes">Hinweise (DE)</label>
+                      <textarea id="f-notes" className="admin-rules-input" rows={2} />
+                    </div>
+                    <div className="form-field">
+                      <label htmlFor="f-notes-en" data-i18n="admin.rules.edit.field.deadline_notes_en">Hinweise (EN)</label>
+                      <textarea id="f-notes-en" className="admin-rules-input" rows={2} />
+                    </div>
+                  </fieldset>
+
+                  <fieldset className="admin-rules-fieldset">
+                    <legend data-i18n="admin.rules.edit.section.lifecycle">Priorit&auml;t &amp; Flags</legend>
+                    <div className="admin-rules-edit-row">
+                      <div className="form-field">
+                        <label htmlFor="f-priority" data-i18n="admin.rules.edit.field.priority">Priorit&auml;t</label>
+                        <select id="f-priority" className="admin-rules-select">
+                          <option value="mandatory">mandatory</option>
+                          <option value="recommended">recommended</option>
+                          <option value="optional">optional</option>
+                          <option value="informational">informational</option>
+                        </select>
+                      </div>
+                      <div className="form-field admin-rules-checkbox-field">
+                        <label>
+                          <input type="checkbox" id="f-is-court-set" />
+                          <span data-i18n="admin.rules.edit.field.is_court_set">Gerichtlich gesetzt</span>
+                        </label>
+                      </div>
+                      <div className="form-field admin-rules-checkbox-field">
+                        <label>
+                          <input type="checkbox" id="f-is-spawn" />
+                          <span data-i18n="admin.rules.edit.field.is_spawn">Spawn</span>
+                        </label>
+                      </div>
+                    </div>
+                    <div className="admin-rules-edit-row" id="f-spawn-row" style="display:none">
+                      <div className="form-field">
+                        <label htmlFor="f-spawn-label" data-i18n="admin.rules.edit.field.spawn_label">Spawn-Label</label>
+                        <input type="text" id="f-spawn-label" className="admin-rules-input" />
+                      </div>
+                      <div className="form-field">
+                        <label htmlFor="f-spawn-proceeding" data-i18n="admin.rules.edit.field.spawn_proceeding">Spawn-Verfahren</label>
+                        <select id="f-spawn-proceeding" className="admin-rules-select">
+                          <option value="" data-i18n="admin.rules.edit.field.spawn_proceeding.none">—</option>
+                        </select>
+                      </div>
+                    </div>
+                  </fieldset>
+
+                  <fieldset className="admin-rules-fieldset">
+                    <legend data-i18n="admin.rules.edit.section.condition">Bedingung (condition_expr)</legend>
+                    <p className="admin-rules-hint" data-i18n="admin.rules.edit.field.condition_hint">
+                      JSON-Grammatik: <code>&#123;"flag":"name"&#125;</code> · <code>&#123;"op":"and|or","args":[...]&#125;</code> · <code>&#123;"op":"not","args":[...]&#125;</code>
+                    </p>
+                    <div className="form-field">
+                      <textarea id="f-condition-expr" className="admin-rules-input admin-rules-code-input" rows={5} placeholder='z. B. {"flag":"with_ccr"}' />
+                      <p className="admin-rules-hint" id="f-condition-msg" />
+                    </div>
+                  </fieldset>
+                </form>
+
+                <aside className="admin-rules-edit-side">
+                  {/* Preview widget */}
+                  <div className="admin-rules-edit-card">
+                    <h3 data-i18n="admin.rules.edit.preview.heading">Preview</h3>
+                    <p className="admin-rules-hint" data-i18n="admin.rules.edit.preview.hint">
+                      Nur f&uuml;r Drafts. Berechnet die Fristenkette mit dieser Draft-Regel anstelle der publizierten Variante.
+                    </p>
+                    <div className="form-field">
+                      <label htmlFor="preview-trigger-date" data-i18n="admin.rules.edit.preview.trigger_date">Trigger-Datum</label>
+                      <input type="date" lang="de" id="preview-trigger-date" className="admin-rules-input" />
+                    </div>
+                    <div className="form-field">
+                      <label htmlFor="preview-flags" data-i18n="admin.rules.edit.preview.flags">Flags (komma-separiert)</label>
+                      <input type="text" id="preview-flags" className="admin-rules-input" placeholder="z. B. with_ccr,is_appeal" />
+                    </div>
+                    <button type="button" id="preview-run" className="btn-secondary" data-i18n="admin.rules.edit.preview.run">
+                      Preview berechnen
+                    </button>
+                    <div id="preview-result" className="admin-rules-preview-result" style="display:none" />
+                  </div>
+
+                  {/* Audit-log timeline */}
+                  <div className="admin-rules-edit-card">
+                    <h3 data-i18n="admin.rules.edit.audit.heading">Audit-Log</h3>
+                    <ol id="rules-edit-audit" className="admin-rules-audit-list">
+                      <li className="admin-rules-loading" data-i18n="admin.rules.edit.audit.loading">Lade...</li>
+                    </ol>
+                    <button type="button" id="audit-loadmore" className="btn-secondary" style="display:none" data-i18n="admin.rules.edit.audit.loadmore">
+                      Weitere laden
+                    </button>
+                  </div>
+                </aside>
+              </div>
+
+              {/* Action bar */}
+              <div className="admin-rules-actionbar">
+                <button type="button" id="action-save-draft" className="btn-primary" style="display:none" data-i18n="admin.rules.edit.action.save_draft">
+                  Draft speichern
+                </button>
+                <button type="button" id="action-publish" className="btn-primary" style="display:none" data-i18n="admin.rules.edit.action.publish">
+                  Publish
+                </button>
+                <button type="button" id="action-clone" className="btn-secondary" style="display:none" data-i18n="admin.rules.edit.action.clone">
+                  Als Draft klonen
+                </button>
+                <button type="button" id="action-archive" className="btn-secondary" style="display:none" data-i18n="admin.rules.edit.action.archive">
+                  Archivieren
+                </button>
+                <button type="button" id="action-restore" className="btn-secondary" style="display:none" data-i18n="admin.rules.edit.action.restore">
+                  Wiederherstellen
+                </button>
+              </div>
+            </div>
+          </section>
+        </main>
+
+        {/* Reason modal — shared for every lifecycle action. Action-specific
+            body text is set by the client at open time. */}
+        <div className="modal-overlay" id="rules-action-modal" style="display:none">
+          <div className="modal-card">
+            <div className="modal-header">
+              <h2 id="rules-action-modal-title">Aktion best&auml;tigen</h2>
+              <button className="modal-close" id="rules-action-modal-close" type="button" aria-label="Close">&times;</button>
+            </div>
+            <p id="rules-action-modal-body" className="invite-modal-body" />
+            <form id="rules-action-modal-form" className="entity-form" autocomplete="off">
+              <div className="form-field">
+                <label htmlFor="rules-action-modal-reason" data-i18n="admin.rules.modal.reason">Grund</label>
+                <textarea
+                  id="rules-action-modal-reason"
+                  className="admin-rules-input"
+                  rows={3}
+                  required
+                  minlength={10}
+                />
+                <p className="admin-rules-hint" data-i18n="admin.rules.modal.reason.hint">
+                  Mindestens 10 Zeichen.
+                </p>
+              </div>
+              <p className="form-msg" id="rules-action-modal-msg" style="display:none" />
+              <div className="form-actions">
+                <button type="button" className="btn-cancel" id="rules-action-modal-cancel" data-i18n="common.cancel">Abbrechen</button>
+                <button type="submit" className="btn-primary" id="rules-action-modal-submit" data-i18n="admin.rules.modal.confirm">
+                  Best&auml;tigen
+                </button>
+              </div>
+            </form>
+          </div>
+        </div>
+
+        <Footer />
+        <PaliadinWidget />
+        <script src="/assets/admin-rules-edit.js"></script>
+      </body>
+    </html>
+  );
+}

frontend/src/admin-rules-export.tsx

@@ -0,0 +1,80 @@
+import { h } from "./jsx";
+import { Sidebar } from "./components/Sidebar";
+import { PaliadinWidget } from "./components/PaliadinWidget";
+import { BottomNav } from "./components/BottomNav";
+import { Footer } from "./components/Footer";
+import { PWAHead } from "./components/PWAHead";
+
+// /admin/rules/export — Slice 11b (t-paliad-192). Surfaces the
+// GET /admin/api/rules/export-migrations endpoint as a SQL preview the
+// editor can copy or download. Optional ?since=<audit-id> query lets
+// the editor scope the export to a particular audit window — empty =
+// every un-exported audit row.
+export function renderAdminRulesExport(): string {
+  return "<!DOCTYPE html>" + (
+    <html lang="de">
+      <head>
+        <meta charset="UTF-8" />
+        <meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover" />
+        <meta name="theme-color" content="#BFF355" />
+        <meta name="apple-mobile-web-app-capable" content="yes" />
+        <meta name="apple-mobile-web-app-status-bar-style" content="default" />
+        <PWAHead />
+        <title data-i18n="admin.rules.export.title">Regel-Migrations exportieren &mdash; Paliad</title>
+        <link rel="stylesheet" href="/assets/global.css" />
+      </head>
+      <body className="has-sidebar">
+        <Sidebar currentPath="/admin/rules" />
+        <BottomNav currentPath="/admin/rules" />
+
+        <main>
+          <section className="tool-page">
+            <div className="container">
+              <div className="tool-header">
+                <div>
+                  <p className="admin-rules-breadcrumb">
+                    <a href="/admin/rules" data-i18n="admin.rules.export.breadcrumb">&larr; Regeln verwalten</a>
+                  </p>
+                  <h1 data-i18n="admin.rules.export.heading">Regel-Migrations exportieren</h1>
+                  <p className="tool-subtitle" data-i18n="admin.rules.export.subtitle">
+                    Generiert ein <code>*.up.sql</code>-Blob mit allen unsynchronisierten Audit-Ver&auml;nderungen.
+                    Manuell in <code>internal/db/migrations/</code> einchecken.
+                  </p>
+                </div>
+              </div>
+
+              <div className="admin-rules-export-controls">
+                <div className="form-field">
+                  <label htmlFor="export-since" data-i18n="admin.rules.export.field.since">Startend ab Audit-ID (optional)</label>
+                  <input type="text" id="export-since" className="admin-rules-input" placeholder="UUID, leer = alle un-exportierten" />
+                </div>
+                <button type="button" id="export-run" className="btn-primary" data-i18n="admin.rules.export.run">
+                  Export generieren
+                </button>
+                <button type="button" id="export-download" className="btn-secondary" style="display:none" data-i18n="admin.rules.export.download">
+                  Als Datei herunterladen
+                </button>
+                <button type="button" id="export-copy" className="btn-secondary" style="display:none" data-i18n="admin.rules.export.copy">
+                  In Zwischenablage kopieren
+                </button>
+              </div>
+
+              <div id="export-feedback" className="form-msg" style="display:none" />
+
+              <div className="admin-rules-export-summary" id="export-summary" style="display:none">
+                <span id="export-summary-count" />
+                <span id="export-summary-latest" />
+              </div>
+
+              <pre id="export-output" className="admin-rules-export-pre" />
+            </div>
+          </section>
+        </main>
+
+        <Footer />
+        <PaliadinWidget />
+        <script src="/assets/admin-rules-export.js"></script>
+      </body>
+    </html>
+  );
+}

frontend/src/admin-rules-list.tsx

@@ -0,0 +1,187 @@
+import { h } from "./jsx";
+import { Sidebar } from "./components/Sidebar";
+import { PaliadinWidget } from "./components/PaliadinWidget";
+import { BottomNav } from "./components/BottomNav";
+import { Footer } from "./components/Footer";
+import { PWAHead } from "./components/PWAHead";
+
+// /admin/rules — Slice 11b (t-paliad-192). Filterable rule table + an
+// Orphans tab that surfaces the Slice 10 fuzzy-match staging rows so an
+// admin can hand-bind each legacy deadline to one of the candidate
+// rule_ids. Both surfaces share the same page shell to keep navigation
+// shallow — the count badge on the Orphans tab is loaded eagerly on
+// first paint so the editor sees the legal-review backlog every visit.
+export function renderAdminRulesList(): string {
+  return "<!DOCTYPE html>" + (
+    <html lang="de">
+      <head>
+        <meta charset="UTF-8" />
+        <meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover" />
+        <meta name="theme-color" content="#BFF355" />
+        <meta name="apple-mobile-web-app-capable" content="yes" />
+        <meta name="apple-mobile-web-app-status-bar-style" content="default" />
+        <PWAHead />
+        <title data-i18n="admin.rules.list.title">Regeln verwalten &mdash; Paliad</title>
+        <link rel="stylesheet" href="/assets/global.css" />
+      </head>
+      <body className="has-sidebar">
+        <Sidebar currentPath="/admin/rules" />
+        <BottomNav currentPath="/admin/rules" />
+
+        <main>
+          <section className="tool-page">
+            <div className="container">
+              <div className="tool-header">
+                <div>
+                  <h1 data-i18n="admin.rules.list.heading">Regeln verwalten</h1>
+                  <p className="tool-subtitle" data-i18n="admin.rules.list.subtitle">
+                    Fristen-Regeln anlegen, bearbeiten und freigeben. Lifecycle: draft &rarr; published &rarr; archived.
+                  </p>
+                </div>
+                <div className="admin-rules-header-actions">
+                  <a href="/admin/rules/export" className="btn-secondary" data-i18n="admin.rules.list.export">
+                    Migrations exportieren
+                  </a>
+                  <button type="button" id="rules-new-btn" className="btn-primary" data-i18n="admin.rules.list.new">
+                    + Neue Regel
+                  </button>
+                </div>
+              </div>
+
+              <div className="admin-rules-tabs">
+                <button type="button" className="admin-rules-tab active" id="rules-tab-rules" data-tab="rules" data-i18n="admin.rules.tab.rules">
+                  Regeln
+                </button>
+                <button type="button" className="admin-rules-tab" id="rules-tab-orphans" data-tab="orphans">
+                  <span data-i18n="admin.rules.tab.orphans">Orphans</span>
+                  <span className="admin-rules-tab-badge" id="rules-orphans-badge" style="display:none">0</span>
+                </button>
+              </div>
+
+              <div id="rules-feedback" className="form-msg" style="display:none" />
+
+              {/* Rules tab */}
+              <div id="rules-pane-rules" className="admin-rules-pane">
+                <div className="admin-rules-filters">
+                  <div className="admin-rules-filter">
+                    <label htmlFor="rules-filter-proceeding" data-i18n="admin.rules.filter.proceeding">Verfahrenstyp</label>
+                    <select id="rules-filter-proceeding" className="admin-rules-select">
+                      <option value="" data-i18n="admin.rules.filter.proceeding.any">Alle</option>
+                    </select>
+                  </div>
+
+                  <div className="admin-rules-filter">
+                    <label htmlFor="rules-filter-trigger" data-i18n="admin.rules.filter.trigger">Trigger-Ereignis</label>
+                    <select id="rules-filter-trigger" className="admin-rules-select">
+                      <option value="" data-i18n="admin.rules.filter.trigger.any">Alle</option>
+                    </select>
+                  </div>
+
+                  <div className="admin-rules-filter admin-rules-filter-chips">
+                    <span className="admin-rules-filter-label" data-i18n="admin.rules.filter.lifecycle">Lifecycle</span>
+                    <div className="admin-rules-chips" id="rules-filter-lifecycle">
+                      <button type="button" className="admin-rules-chip active" data-state="" data-i18n="admin.rules.filter.lifecycle.any">Alle</button>
+                      <button type="button" className="admin-rules-chip" data-state="draft" data-i18n="admin.rules.lifecycle.draft">Draft</button>
+                      <button type="button" className="admin-rules-chip" data-state="published" data-i18n="admin.rules.lifecycle.published">Published</button>
+                      <button type="button" className="admin-rules-chip" data-state="archived" data-i18n="admin.rules.lifecycle.archived">Archived</button>
+                    </div>
+                  </div>
+
+                  <div className="admin-rules-filter admin-rules-filter-search">
+                    <label htmlFor="rules-filter-search" data-i18n="admin.rules.filter.search">Suche</label>
+                    <input
+                      type="text"
+                      id="rules-filter-search"
+                      className="admin-rules-input"
+                      placeholder="Name, Submission Code, Rechtsgrundlage..."
+                      data-i18n-placeholder="admin.rules.filter.search.placeholder"
+                      autocomplete="off"
+                    />
+                  </div>
+                </div>
+
+                <div className="entity-table-wrap admin-rules-table-wrap">
+                  <table className="entity-table admin-rules-table">
+                    <thead>
+                      <tr>
+                        <th data-i18n="admin.rules.col.submission_code">Submission Code</th>
+                        <th data-i18n="admin.rules.col.legal_citation">Rechtsgrundlage</th>
+                        <th data-i18n="admin.rules.col.name">Name</th>
+                        <th data-i18n="admin.rules.col.proceeding">Verfahrenstyp</th>
+                        <th data-i18n="admin.rules.col.priority">Priorit&auml;t</th>
+                        <th data-i18n="admin.rules.col.lifecycle">Lifecycle</th>
+                        <th data-i18n="admin.rules.col.modified">Zuletzt ge&auml;ndert</th>
+                      </tr>
+                    </thead>
+                    <tbody id="rules-tbody">
+                      <tr><td colspan={7} className="admin-rules-loading" data-i18n="admin.rules.loading">Lade...</td></tr>
+                    </tbody>
+                  </table>
+                </div>
+
+                <div className="entity-empty" id="rules-empty" style="display:none">
+                  <p data-i18n="admin.rules.empty">Keine Regeln f&uuml;r die gew&auml;hlten Filter.</p>
+                </div>
+              </div>
+
+              {/* Orphans tab */}
+              <div id="rules-pane-orphans" className="admin-rules-pane" style="display:none">
+                <p className="tool-subtitle" data-i18n="admin.rules.orphans.subtitle">
+                  Legacy-Deadlines aus dem fuzzy-match Backfill (Slice 10), die nicht eindeutig einer Regel zugeordnet werden konnten. Bitte die richtige Kandidaten-Regel ausw&auml;hlen.
+                </p>
+                <div id="rules-orphans-list" className="admin-rules-orphans">
+                  <p className="admin-rules-loading" data-i18n="admin.rules.orphans.loading">Lade...</p>
+                </div>
+              </div>
+            </div>
+          </section>
+        </main>
+
+        {/* Reason modal — reused for "+ Neue Regel" (creates a draft) and for
+            the orphan resolve flow. Both writes go through audit-reason
+            session config server-side, so the modal enforces the 10-char
+            minimum client-side per Slice 11a edge case #4. */}
+        <div className="modal-overlay" id="rules-reason-modal" style="display:none">
+          <div className="modal-card">
+            <div className="modal-header">
+              <h2 id="rules-reason-title" data-i18n="admin.rules.modal.new.title">Neue Regel anlegen</h2>
+              <button className="modal-close" id="rules-reason-close" type="button" aria-label="Close">&times;</button>
+            </div>
+            <p id="rules-reason-body" className="invite-modal-body" data-i18n="admin.rules.modal.new.body">
+              Eine neue Regel wird als Draft angelegt. Bitte einen Grund (mind. 10 Zeichen) angeben &mdash; dieser wandert ins Audit-Log und beim Export in die Migration.
+            </p>
+            <form id="rules-reason-form" className="entity-form" autocomplete="off">
+              <div id="rules-reason-extra" />
+              <div className="form-field">
+                <label htmlFor="rules-reason-text" data-i18n="admin.rules.modal.reason">Grund</label>
+                <textarea
+                  id="rules-reason-text"
+                  className="admin-rules-input"
+                  rows={3}
+                  required
+                  minlength={10}
+                  placeholder="z. B. „Neue Regel f&uuml;r RoP.198 nach UPC-Reform 2026..."
+                  data-i18n-placeholder="admin.rules.modal.reason.placeholder"
+                />
+                <p className="admin-rules-hint" data-i18n="admin.rules.modal.reason.hint">
+                  Mindestens 10 Zeichen.
+                </p>
+              </div>
+              <p className="form-msg" id="rules-reason-msg" style="display:none" />
+              <div className="form-actions">
+                <button type="button" className="btn-cancel" id="rules-reason-cancel" data-i18n="common.cancel">Abbrechen</button>
+                <button type="submit" className="btn-primary" id="rules-reason-submit" data-i18n="admin.rules.modal.confirm">
+                  Best&auml;tigen
+                </button>
+              </div>
+            </form>
+          </div>
+        </div>
+
+        <Footer />
+        <PaliadinWidget />
+        <script src="/assets/admin-rules-list.js"></script>
+      </body>
+    </html>
+  );
+}

frontend/src/admin-team.tsx

@@ -33,6 +33,9 @@ export function renderAdminTeam(): string {
                   </p>
                 </div>
                 <div className="admin-team-actions">
+                  <button className="btn-primary" id="admin-team-add-full" type="button" data-i18n="admin.team.add.full">
+                    Konto direkt anlegen
+                  </button>
                   <button className="btn-primary" id="admin-team-direct-add" type="button" data-i18n="admin.team.add.direct">
                     Bestehendes Konto onboarden
                   </button>
@@ -132,6 +135,67 @@ export function renderAdminTeam(): string {
           </div>
         </div>
 
+        {/* t-paliad-223 Slice B (#49) — "Konto direkt anlegen" modal.
+            Creates BOTH the auth.users row (via Supabase Admin API) and
+            the paliad.users row in one click. New user is visible in
+            dropdowns immediately. */}
+        <div className="modal-overlay" id="admin-add-full-modal" style="display:none">
+          <div className="modal-card">
+            <div className="modal-header">
+              <h2 data-i18n="admin.team.add_full.title">Konto direkt anlegen</h2>
+              <button className="modal-close" id="admin-af-close" type="button" aria-label="Close">&times;</button>
+            </div>
+            <p data-i18n="admin.team.add_full.body" className="invite-modal-body">
+              Legt sowohl das Login-Konto als auch das Paliad-Profil an. Die neue Person erh&auml;lt eine E-Mail mit einem Link, &uuml;ber den sie ein Passwort setzt.
+            </p>
+            <form id="admin-add-full-form" className="entity-form" autocomplete="off">
+              <div className="form-field">
+                <label htmlFor="admin-af-email" data-i18n="admin.team.add_full.email">E-Mail</label>
+                <input type="email" id="admin-af-email" name="email" required autocomplete="off" />
+              </div>
+              <div className="form-field">
+                <label htmlFor="admin-af-name" data-i18n="admin.team.add_full.name">Anzeigename</label>
+                <input type="text" id="admin-af-name" name="display_name" required />
+              </div>
+              <div className="form-field">
+                <label htmlFor="admin-af-office" data-i18n="admin.team.add_full.office">Standort</label>
+                <select id="admin-af-office" name="office" required />
+              </div>
+              <div className="form-field">
+                <label htmlFor="admin-af-profession" data-i18n="admin.team.add_full.profession">Profession</label>
+                <select id="admin-af-profession" name="profession">
+                  <option value="partner" data-i18n="projects.team.profession.partner">Partner</option>
+                  <option value="of_counsel" data-i18n="projects.team.profession.of_counsel">Of Counsel</option>
+                  <option value="associate" selected data-i18n="projects.team.profession.associate">Associate</option>
+                  <option value="senior_pa" data-i18n="projects.team.profession.senior_pa">Senior PA</option>
+                  <option value="pa" data-i18n="projects.team.profession.pa">PA</option>
+                  <option value="paralegal" data-i18n="projects.team.profession.paralegal">Paralegal</option>
+                </select>
+              </div>
+              <div className="form-field">
+                <label htmlFor="admin-af-job-title" data-i18n="admin.team.add_full.job_title">Berufsbezeichnung</label>
+                <input type="text" id="admin-af-job-title" name="job_title" placeholder="Associate" />
+              </div>
+              <div className="form-field">
+                <label htmlFor="admin-af-lang" data-i18n="admin.team.add_full.lang">Sprache</label>
+                <select id="admin-af-lang" name="lang">
+                  <option value="de" selected>Deutsch</option>
+                  <option value="en">English</option>
+                </select>
+              </div>
+              <label className="form-checkbox">
+                <input type="checkbox" id="admin-af-send-welcome" checked />
+                <span data-i18n="admin.team.add_full.send_welcome">Willkommens-E-Mail mit Login-Link senden</span>
+              </label>
+              <div id="admin-af-feedback" className="form-msg" style="display:none" />
+              <div className="form-actions">
+                <button type="button" className="btn-cancel" id="admin-af-cancel" data-i18n="admin.team.add_full.cancel">Abbrechen</button>
+                <button type="submit" className="btn-primary" id="admin-af-submit" data-i18n="admin.team.add_full.submit">Anlegen</button>
+              </div>
+            </form>
+          </div>
+        </div>
+
         <Footer />
         <PaliadinWidget />
         <script src="/assets/admin-team.js"></script>

frontend/src/admin.tsx

@@ -95,6 +95,11 @@ export function renderAdmin(): string {
                   <h2 data-i18n="admin.card.approval_policies.title">Genehmigungspflichten</h2>
                   <p data-i18n="admin.card.approval_policies.desc">4-Augen-Pr&uuml;fung pro Projekt und Partner Unit konfigurieren.</p>
                 </a>
+                <a href="/admin/rules" className="card card-link">
+                  <div className="card-icon" dangerouslySetInnerHTML={{ __html: ICON_TABLE }} />
+                  <h2 data-i18n="admin.card.rules.title">Regeln verwalten</h2>
+                  <p data-i18n="admin.card.rules.desc">Fristen-Regeln anlegen, bearbeiten, publishen. Audit-Log, Preview, Migration-Export.</p>
+                </a>
               </div>
 
               <h3 className="section-heading admin-section-planned" data-i18n="admin.section.planned">Geplant</h3>

frontend/src/appointments-calendar.tsx

@@ -1,103 +0,0 @@
-import { h } from "./jsx";
-import { Sidebar } from "./components/Sidebar";
-import { PaliadinWidget } from "./components/PaliadinWidget";
-import { BottomNav } from "./components/BottomNav";
-import { Footer } from "./components/Footer";
-import { PWAHead } from "./components/PWAHead";
-
-export function renderAppointmentsCalendar(): string {
-  return "<!DOCTYPE html>" + (
-    <html lang="de">
-      <head>
-        <meta charset="UTF-8" />
-        <meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover" />
-        <meta name="theme-color" content="#BFF355" />
-        <meta name="apple-mobile-web-app-capable" content="yes" />
-        <meta name="apple-mobile-web-app-status-bar-style" content="default" />
-        <PWAHead />
-        <title data-i18n="appointments.kalender.title">Terminkalender &mdash; Paliad</title>
-        <link rel="stylesheet" href="/assets/global.css" />
-      </head>
-      <body className="has-sidebar">
-        <Sidebar currentPath="/events?type=appointment" />
-        <BottomNav currentPath="/events?type=appointment" />
-
-        <main>
-          <section className="tool-page">
-            <div className="container">
-              <div className="tool-header">
-                <div className="entity-header-row">
-                  <div>
-                    <h1 data-i18n="appointments.kalender.heading">Terminkalender</h1>
-                    <p className="tool-subtitle" data-i18n="appointments.kalender.subtitle">
-                      Monats&uuml;bersicht aller Termine.
-                    </p>
-                  </div>
-                  <div className="fristen-header-actions">
-                    <a href="/events?type=appointment" className="btn-secondary" data-i18n="appointments.kalender.list">Listenansicht</a>
-                    <a href="/appointments/new" className="btn-primary btn-cta-lime" data-i18n="appointments.list.new">Neuer Termin</a>
-                  </div>
-                </div>
-              </div>
-
-              <div className="frist-calendar-controls">
-                <button type="button" id="cal-prev" className="btn-secondary btn-small" aria-label="Vorheriger Monat">&larr;</button>
-                <h2 id="cal-month-label" className="frist-cal-month-label" />
-                <button type="button" id="cal-next" className="btn-secondary btn-small" aria-label="N&auml;chster Monat">&rarr;</button>
-                <button type="button" id="cal-today" className="btn-secondary btn-small" data-i18n="deadlines.kalender.today">Heute</button>
-              </div>
-
-              <div className="termin-cal-legend">
-                <span className="termin-cal-legend-item">
-                  <span className="termin-dot termin-type-hearing" />
-                  <span data-i18n="appointments.type.hearing">Verhandlung</span>
-                </span>
-                <span className="termin-cal-legend-item">
-                  <span className="termin-dot termin-type-meeting" />
-                  <span data-i18n="appointments.type.meeting">Besprechung</span>
-                </span>
-                <span className="termin-cal-legend-item">
-                  <span className="termin-dot termin-type-consultation" />
-                  <span data-i18n="appointments.type.consultation">Beratung</span>
-                </span>
-                <span className="termin-cal-legend-item">
-                  <span className="termin-dot termin-type-deadline_hearing" />
-                  <span data-i18n="appointments.type.deadline_hearing">Fristverhandlung</span>
-                </span>
-              </div>
-
-              <div className="frist-calendar" id="appointment-calendar">
-                <div className="frist-cal-weekday" data-i18n="cal.day.mon">Mo</div>
-                <div className="frist-cal-weekday" data-i18n="cal.day.tue">Di</div>
-                <div className="frist-cal-weekday" data-i18n="cal.day.wed">Mi</div>
-                <div className="frist-cal-weekday" data-i18n="cal.day.thu">Do</div>
-                <div className="frist-cal-weekday" data-i18n="cal.day.fri">Fr</div>
-                <div className="frist-cal-weekday" data-i18n="cal.day.sat">Sa</div>
-                <div className="frist-cal-weekday" data-i18n="cal.day.sun">So</div>
-                <div id="appointment-cal-grid" className="frist-cal-grid" />
-              </div>
-
-              <p className="entity-events-empty" id="appointment-cal-empty" style="display:none" data-i18n="appointments.kalender.empty">
-                Keine Termine im ausgew&auml;hlten Zeitraum.
-              </p>
-
-              <div className="modal-overlay" id="cal-popup" style="display:none">
-                <div className="modal-card">
-                  <div className="modal-header">
-                    <h2 id="cal-popup-date" />
-                    <button className="modal-close" id="cal-popup-close" type="button">&times;</button>
-                  </div>
-                  <ul className="frist-cal-popup-list" id="cal-popup-list" />
-                </div>
-              </div>
-            </div>
-          </section>
-        </main>
-
-        <Footer />
-        <PaliadinWidget />
-        <script src="/assets/appointments-calendar.js"></script>
-      </body>
-    </html>
-  );
-}

frontend/src/checklists-author.tsx

@@ -0,0 +1,120 @@
+import { h } from "./jsx";
+import { Sidebar } from "./components/Sidebar";
+import { PaliadinWidget } from "./components/PaliadinWidget";
+import { BottomNav } from "./components/BottomNav";
+import { Footer } from "./components/Footer";
+import { PWAHead } from "./components/PWAHead";
+
+// Authoring wizard for paliad.checklists. Both /checklists/new and
+// /checklists/templates/{slug}/edit serve this same bundle; the client reads
+// window.location.pathname to decide create vs edit mode.
+export function renderChecklistsAuthor(): string {
+  return "<!DOCTYPE html>" + (
+    <html lang="de">
+      <head>
+        <meta charset="UTF-8" />
+        <meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover" />
+        <meta name="theme-color" content="#BFF355" />
+        <meta name="apple-mobile-web-app-capable" content="yes" />
+        <meta name="apple-mobile-web-app-status-bar-style" content="default" />
+        <PWAHead />
+        <title data-i18n="checklisten.author.title">Vorlage erstellen &mdash; Paliad</title>
+        <link rel="stylesheet" href="/assets/global.css" />
+      </head>
+      <body className="has-sidebar">
+        <Sidebar currentPath="/checklists" />
+        <BottomNav currentPath="/checklists" />
+
+        <main>
+          <section className="tool-page">
+            <div className="container">
+              <div className="tool-header">
+                <h1 id="author-heading" data-i18n="checklisten.author.heading.new">Neue Checklisten-Vorlage</h1>
+                <p className="tool-subtitle" data-i18n="checklisten.author.subtitle">
+                  Erstellen Sie eine eigene Checkliste mit Sektionen und Punkten.
+                </p>
+              </div>
+
+              <form id="author-form" className="form-stack" autoComplete="off">
+                <div className="form-row">
+                  <label className="form-label" htmlFor="title" data-i18n="checklisten.author.field.title">Titel</label>
+                  <input className="form-input" id="title" name="title" type="text" required maxLength="200" />
+                  <p className="form-hint" data-i18n="checklisten.author.field.title.hint">z.B. &bdquo;UPC SoC &mdash; interne Checkliste&ldquo;.</p>
+                </div>
+
+                <div className="form-row">
+                  <label className="form-label" htmlFor="description" data-i18n="checklisten.author.field.description">Kurzbeschreibung</label>
+                  <textarea className="form-input" id="description" name="description" rows="3" maxLength="2000" />
+                </div>
+
+                <div className="form-grid form-grid-2">
+                  <div className="form-row">
+                    <label className="form-label" htmlFor="regime" data-i18n="checklisten.author.field.regime">Regime</label>
+                    <select className="form-input" id="regime" name="regime">
+                      <option value="UPC">UPC</option>
+                      <option value="DE">DE</option>
+                      <option value="EPA">EPA</option>
+                      <option value="OTHER" selected>OTHER</option>
+                    </select>
+                  </div>
+                  <div className="form-row">
+                    <label className="form-label" htmlFor="lang" data-i18n="checklisten.author.field.lang">Sprache</label>
+                    <select className="form-input" id="lang" name="lang">
+                      <option value="de" selected>Deutsch</option>
+                      <option value="en">English</option>
+                    </select>
+                  </div>
+                </div>
+
+                <div className="form-grid form-grid-2">
+                  <div className="form-row">
+                    <label className="form-label" htmlFor="court" data-i18n="checklisten.author.field.court">Gericht / Beh&ouml;rde</label>
+                    <input className="form-input" id="court" name="court" type="text" maxLength="200" />
+                  </div>
+                  <div className="form-row">
+                    <label className="form-label" htmlFor="reference" data-i18n="checklisten.author.field.reference">Rechtsgrundlage</label>
+                    <input className="form-input" id="reference" name="reference" type="text" maxLength="200" />
+                  </div>
+                </div>
+
+                <div className="form-row">
+                  <label className="form-label" htmlFor="deadline" data-i18n="checklisten.author.field.deadline">Deadline (optional)</label>
+                  <input className="form-input" id="deadline" name="deadline" type="text" maxLength="200" />
+                </div>
+
+                <fieldset className="form-fieldset">
+                  <legend data-i18n="checklisten.author.field.visibility">Sichtbarkeit</legend>
+                  <label className="form-radio">
+                    <input type="radio" name="visibility" value="private" checked />
+                    <span><strong data-i18n="checklisten.mine.visibility.private">Privat</strong> &mdash; <span data-i18n="checklisten.author.visibility.private.hint">Nur f&uuml;r Sie sichtbar.</span></span>
+                  </label>
+                  <label className="form-radio">
+                    <input type="radio" name="visibility" value="firm" />
+                    <span><strong data-i18n="checklisten.mine.visibility.firm">Firmenweit</strong> &mdash; <span data-i18n="checklisten.author.visibility.firm.hint">F&uuml;r alle angemeldeten Kolleginnen und Kollegen sichtbar.</span></span>
+                  </label>
+                </fieldset>
+
+                <fieldset className="form-fieldset">
+                  <legend data-i18n="checklisten.author.groups.heading">Sektionen und Punkte</legend>
+                  <div id="groups-container" />
+                  <button type="button" className="btn btn-secondary" id="add-group" data-i18n="checklisten.author.groups.add">+ Sektion hinzuf&uuml;gen</button>
+                </fieldset>
+
+                <p id="author-error" className="form-error" style="display:none" role="alert" />
+
+                <div className="form-actions">
+                  <button type="submit" className="btn btn-primary" id="author-save" data-i18n="checklisten.author.save">Speichern</button>
+                  <a className="btn btn-secondary" href="/checklists?tab=mine" data-i18n="checklisten.author.cancel">Abbrechen</a>
+                </div>
+              </form>
+            </div>
+          </section>
+        </main>
+
+        <Footer />
+        <PaliadinWidget />
+        <script src="/assets/checklists-author.js"></script>
+      </body>
+    </html>
+  );
+}

frontend/src/checklists-detail.tsx

@@ -39,12 +39,28 @@ export function renderChecklistsDetail(): string {
                   <div>
                     <h1 id="checklist-title">&nbsp;</h1>
                     <p className="tool-subtitle" id="checklist-subtitle">&nbsp;</p>
+                    {/* Provenance line — visible only for authored
+                        templates; populated by the client from the
+                        catalog response's owner_display_name. */}
+                    <p className="checklist-provenance" id="checklist-provenance" style="display:none" />
                     <dl className="checklist-meta" id="checklist-meta" />
                   </div>
                   <div className="checklist-actions">
                     <button type="button" id="btn-new-instance" className="btn-primary btn-cta-lime" data-i18n="checklisten.newInstance">
                       Neue Instanz
                     </button>
+                    {/* Owner controls (Slice B) — toggled on by the
+                        client once /api/checklists/{slug} returns
+                        origin='authored' AND owner_email matches the
+                        logged-in user. Kept hidden by default so
+                        guests / non-owners never see them. */}
+                    <a id="btn-edit-template" className="btn-cta-lime btn-outline" style="display:none" data-i18n="checklisten.detail.edit">Bearbeiten</a>
+                    <button type="button" id="btn-share-template" className="btn-cta-lime btn-outline" style="display:none" data-i18n="checklisten.detail.share">Teilen</button>
+                    <button type="button" id="btn-delete-template" className="btn-cta-lime btn-outline" style="display:none" data-i18n="checklisten.mine.delete">L&ouml;schen</button>
+                    {/* global_admin controls — revealed by the client
+                        when /api/me reports global_role='global_admin'. */}
+                    <button type="button" id="btn-promote-template" className="btn-cta-lime btn-outline" style="display:none" data-i18n="checklisten.detail.promote">Als Firmen-Vorlage hinterlegen</button>
+                    <button type="button" id="btn-demote-template" className="btn-cta-lime btn-outline" style="display:none" data-i18n="checklisten.detail.demote">Aus Katalog entfernen</button>
                     <button type="button" id="btn-feedback" className="btn-cta-lime btn-outline">
                       <span data-i18n="checklisten.feedback.btn">Feedback</span>
                     </button>
@@ -122,6 +138,65 @@ export function renderChecklistsDetail(): string {
           </div>
         </div>
 
+        {/* Share modal (Slice B) — owner-only, hidden until btn-share-template
+            opens it. Four recipient kinds in a single modal: pick the kind,
+            then the matching entity (user / office / partner_unit / project). */}
+        <div className="modal-overlay" id="share-modal" style="display:none">
+          <div className="modal-card modal-card-wide">
+            <div className="modal-header">
+              <h2 data-i18n="checklisten.share.title">Vorlage teilen</h2>
+              <button className="modal-close" id="share-close" type="button">&times;</button>
+            </div>
+            <div className="form-field">
+              <label data-i18n="checklisten.share.kind">Empf&auml;ngertyp</label>
+              <div className="filter-pills" id="share-kind-pills">
+                <button type="button" className="filter-pill active" data-kind="user" data-i18n="checklisten.share.kind.user">Kollege</button>
+                <button type="button" className="filter-pill" data-kind="office" data-i18n="checklisten.share.kind.office">Office</button>
+                <button type="button" className="filter-pill" data-kind="partner_unit" data-i18n="checklisten.share.kind.partner_unit">Dezernat</button>
+                <button type="button" className="filter-pill" data-kind="project" data-i18n="checklisten.share.kind.project">Projekt</button>
+              </div>
+            </div>
+
+            <div className="form-field share-kind-section" data-kind="user">
+              <label htmlFor="share-user" data-i18n="checklisten.share.kind.user">Kollege</label>
+              <select id="share-user">
+                <option value="" data-i18n="checklisten.share.pick">&mdash; ausw&auml;hlen &mdash;</option>
+              </select>
+            </div>
+            <div className="form-field share-kind-section" data-kind="office" style="display:none">
+              <label htmlFor="share-office" data-i18n="checklisten.share.kind.office">Office</label>
+              <select id="share-office">
+                <option value="" data-i18n="checklisten.share.pick">&mdash; ausw&auml;hlen &mdash;</option>
+              </select>
+            </div>
+            <div className="form-field share-kind-section" data-kind="partner_unit" style="display:none">
+              <label htmlFor="share-partner-unit" data-i18n="checklisten.share.kind.partner_unit">Dezernat</label>
+              <select id="share-partner-unit">
+                <option value="" data-i18n="checklisten.share.pick">&mdash; ausw&auml;hlen &mdash;</option>
+              </select>
+            </div>
+            <div className="form-field share-kind-section" data-kind="project" style="display:none">
+              <label htmlFor="share-project" data-i18n="checklisten.share.kind.project">Projekt</label>
+              <select id="share-project">
+                <option value="" data-i18n="checklisten.share.pick">&mdash; ausw&auml;hlen &mdash;</option>
+              </select>
+            </div>
+
+            <div className="form-actions">
+              <button type="button" className="btn-cancel" id="share-cancel" data-i18n="checklisten.share.cancel">Abbrechen</button>
+              <button type="button" className="btn-primary btn-cta-lime" id="share-submit" data-i18n="checklisten.share.submit">Freigeben</button>
+            </div>
+            <p className="form-msg" id="share-msg" />
+
+            {/* Existing grants — populated on open from
+                /api/checklists/templates/{slug}/shares. */}
+            <h3 className="share-grants-heading" data-i18n="checklisten.share.grants.heading">Bestehende Freigaben</h3>
+            <ul className="share-grants-list" id="share-grants-list">
+              <li className="entity-events-empty" id="share-grants-empty" data-i18n="checklisten.share.grants.empty">Keine Freigaben.</li>
+            </ul>
+          </div>
+        </div>
+
         {/* Feedback modal */}
         <div className="modal-overlay" id="feedback-modal" style="display:none">
           <div className="modal-card">

frontend/src/checklists-instance.tsx

@@ -58,6 +58,10 @@ export function renderChecklistsInstance(): string {
                       </div>
                       <p className="tool-subtitle" id="instance-template-title">&nbsp;</p>
                       <dl className="checklist-meta" id="instance-meta" />
+                      {/* Slice C: 'template updated since this instance
+                          was created' banner. Populated by the client
+                          when instance.template_version &lt; template.version. */}
+                      <div id="instance-outdated-slot" />
                     </div>
                     <div className="checklist-actions">
                       <button type="button" id="btn-print" className="btn-ghost" data-i18n="checklisten.print">Drucken</button>
@@ -118,6 +122,21 @@ export function renderChecklistsInstance(): string {
           </div>
         </div>
 
+        {/* Slice C: template-diff modal — opened from the
+            "Änderungen anzeigen" button on the outdated banner. */}
+        <div className="modal-overlay" id="instance-diff-modal" style="display:none">
+          <div className="modal-card modal-card-wide">
+            <div className="modal-header">
+              <h2 data-i18n="checklisten.instance.diff.title">Ge&auml;nderte Punkte</h2>
+              <button className="modal-close" id="instance-diff-close" type="button">&times;</button>
+            </div>
+            <div id="instance-diff-body" />
+            <div className="form-actions">
+              <button type="button" className="btn-cancel" id="instance-diff-close-bottom" data-i18n="checklisten.instance.diff.close">Schlie&szlig;en</button>
+            </div>
+          </div>
+        </div>
+
         <Footer />
         <PaliadinWidget />
         <script src="/assets/checklists-instance.js"></script>

frontend/src/checklists.tsx

@@ -34,6 +34,8 @@ export function renderChecklists(): string {
 
               <nav className="entity-tabs" id="checklists-tabs" aria-label="Checklisten-Ansichten">
                 <a className="entity-tab active" data-tab="templates" href="/checklists" data-i18n="checklisten.tab.templates">Vorlagen</a>
+                <a className="entity-tab" data-tab="mine" href="/checklists?tab=mine" data-i18n="checklisten.tab.mine">Meine Vorlagen</a>
+                <a className="entity-tab" data-tab="gallery" href="/checklists?tab=gallery" data-i18n="checklisten.tab.gallery">Geteilte Vorlagen</a>
                 <a className="entity-tab" data-tab="instances" href="/checklists?tab=instances" data-i18n="checklisten.tab.instances">Vorhandene Instanzen</a>
               </nav>
 
@@ -49,6 +51,36 @@ export function renderChecklists(): string {
                 <div className="checklist-grid" id="checklist-grid" />
               </section>
 
+              {/* Meine Vorlagen tab — caller's own authored templates */}
+              <section className="entity-tab-panel" id="tab-mine" style="display:none">
+                <div className="tool-actions" style="margin-bottom:1rem">
+                  <a href="/checklists/new" className="btn btn-primary" data-i18n="checklisten.mine.new">Neue Vorlage</a>
+                </div>
+                <p className="entity-events-empty" id="checklists-mine-loading" data-i18n="checklisten.mine.loading">L&auml;dt&hellip;</p>
+                <p className="entity-events-empty" id="checklists-mine-empty" style="display:none" data-i18n="checklisten.mine.empty">
+                  Sie haben noch keine eigene Vorlage angelegt.
+                </p>
+                <div className="checklist-grid" id="checklists-mine-grid" style="display:none" />
+              </section>
+
+              {/* Geteilte Vorlagen tab — discovery surface for templates
+                  that aren't owned by the caller (firm-published,
+                  globally-promoted, or explicitly shared). Slice C. */}
+              <section className="entity-tab-panel" id="tab-gallery" style="display:none">
+                <div className="checklist-filters" id="checklist-gallery-filters">
+                  <button className="filter-pill active" data-regime="all" type="button" data-i18n="checklisten.filter.all">Alle</button>
+                  <button className="filter-pill" data-regime="UPC" type="button">UPC</button>
+                  <button className="filter-pill" data-regime="DE" type="button" data-i18n="checklisten.filter.de">DE</button>
+                  <button className="filter-pill" data-regime="EPA" type="button">EPA</button>
+                  <button className="filter-pill" data-regime="OTHER" type="button" data-i18n="checklisten.filter.other">Sonstige</button>
+                </div>
+                <p className="entity-events-empty" id="checklists-gallery-loading" data-i18n="checklisten.mine.loading">L&auml;dt&hellip;</p>
+                <p className="entity-events-empty" id="checklists-gallery-empty" style="display:none" data-i18n="checklisten.gallery.empty">
+                  Noch keine geteilten Vorlagen sichtbar.
+                </p>
+                <div className="checklist-grid" id="checklists-gallery-grid" style="display:none" />
+              </section>
+
               {/* Instances tab — every visible instance across templates */}
               <section className="entity-tab-panel" id="tab-instances" style="display:none">
                 <p className="entity-events-empty" id="checklists-instances-loading" data-i18n="checklisten.instances.all.loading">L&auml;dt&hellip;</p>

frontend/src/client/admin-backups.ts

@@ -0,0 +1,192 @@
+import { initI18n, t } from "./i18n";
+import { initSidebar } from "./sidebar";
+
+// Backup Mode admin client (t-paliad-246 / m/paliad#77 Slice A).
+//
+// Reads /api/admin/backups (chronological list) and wires the
+// "Backup jetzt erstellen" button to POST /api/admin/backups/run.
+// Synchronous: the server holds the connection for the duration of
+// the backup (sub-second at firm-scale today), then returns the new
+// catalog row inline. No polling needed at v1's data shape; if the
+// run takes > 5 minutes the handler returns 500 and the UI surfaces
+// the error.
+
+interface BackupRow {
+  id: string;
+  kind: "scheduled" | "on_demand";
+  status: "running" | "done" | "failed";
+  requested_by?: string;
+  requested_by_email: string;
+  audit_id?: string;
+  storage_uri?: string;
+  size_bytes?: number;
+  row_counts?: unknown; // jsonb passes through as raw bytes; we don't read it
+  sheet_count?: number;
+  warnings?: unknown;
+  error?: string;
+  started_at: string;
+  finished_at?: string;
+  deleted_at?: string;
+}
+
+document.addEventListener("DOMContentLoaded", async () => {
+  initI18n();
+  initSidebar();
+
+  await refreshList();
+  wireRunButton();
+});
+
+function wireRunButton(): void {
+  const btn = document.getElementById("admin-backups-run-btn") as HTMLButtonElement | null;
+  if (!btn) return;
+  btn.addEventListener("click", async () => {
+    btn.disabled = true;
+    const originalText = btn.textContent;
+    btn.textContent = t("admin.backups.running") || "Läuft …";
+    clearFeedback();
+    try {
+      const r = await fetch("/api/admin/backups/run", {
+        method: "POST",
+        credentials: "same-origin",
+      });
+      if (!r.ok) {
+        const body = await r.json().catch(() => ({ error: "request failed" }));
+        showFeedback("error", body.error || `HTTP ${r.status}`);
+        return;
+      }
+      // The created row is in the response; refresh the list to land it.
+      await refreshList();
+      showFeedback("success", t("admin.backups.success") || "Backup erfolgreich erstellt.");
+    } catch (e) {
+      showFeedback("error", (e as Error).message || "network error");
+    } finally {
+      btn.disabled = false;
+      btn.textContent = originalText;
+    }
+  });
+}
+
+async function refreshList(): Promise<void> {
+  const rows = await fetchJSON<BackupRow[]>("/api/admin/backups?limit=200");
+  const tbody = document.getElementById("admin-backups-tbody") as HTMLTableSectionElement | null;
+  const empty = document.getElementById("admin-backups-empty") as HTMLElement | null;
+  if (!tbody) return;
+  if (!rows || rows.length === 0) {
+    tbody.innerHTML = "";
+    if (empty) empty.style.display = "";
+    return;
+  }
+  if (empty) empty.style.display = "none";
+  tbody.innerHTML = rows.map(renderRow).join("");
+}
+
+function renderRow(b: BackupRow): string {
+  const started = formatTimestamp(b.started_at);
+  const kind =
+    b.kind === "scheduled"
+      ? t("admin.backups.kind.scheduled") || "Geplant"
+      : t("admin.backups.kind.on_demand") || "Manuell";
+  const status = renderStatus(b);
+  const requestedBy =
+    b.kind === "scheduled" ? "—" : escapeHTML(b.requested_by_email);
+  const size = b.size_bytes != null ? formatBytes(b.size_bytes) : "—";
+  const rows = b.sheet_count != null ? String(b.sheet_count) : "—";
+  const action = renderAction(b);
+  return `<tr>
+    <td>${started}</td>
+    <td>${kind}</td>
+    <td>${status}</td>
+    <td>${requestedBy}</td>
+    <td>${size}</td>
+    <td>${rows}</td>
+    <td>${action}</td>
+  </tr>`;
+}
+
+function renderStatus(b: BackupRow): string {
+  switch (b.status) {
+    case "done":
+      return `<span class="status-done">${escapeHTML(t("admin.backups.status.done") || "✓ Fertig")}</span>`;
+    case "running":
+      return `<span class="status-running">${escapeHTML(t("admin.backups.status.running") || "Läuft …")}</span>`;
+    case "failed":
+      const label = t("admin.backups.status.failed") || "✗ Fehlgeschlagen";
+      const tip = b.error ? ` title="${escapeAttr(b.error)}"` : "";
+      return `<span class="status-failed"${tip}>${escapeHTML(label)}</span>`;
+    default:
+      return escapeHTML(b.status);
+  }
+}
+
+function renderAction(b: BackupRow): string {
+  if (b.status !== "done" || !b.storage_uri || b.deleted_at) {
+    return "—";
+  }
+  const label = t("admin.backups.download") || "Download";
+  return `<a class="btn-link" href="/api/admin/backups/${encodeURIComponent(b.id)}/file">${escapeHTML(label)}</a>`;
+}
+
+// --- helpers ---
+
+async function fetchJSON<T>(url: string): Promise<T | null> {
+  try {
+    const r = await fetch(url, { credentials: "same-origin" });
+    if (!r.ok) return null;
+    return (await r.json()) as T;
+  } catch {
+    return null;
+  }
+}
+
+function formatTimestamp(iso: string): string {
+  const d = new Date(iso);
+  if (isNaN(d.getTime())) return escapeHTML(iso);
+  const yyyy = d.getUTCFullYear();
+  const mm = String(d.getUTCMonth() + 1).padStart(2, "0");
+  const dd = String(d.getUTCDate()).padStart(2, "0");
+  const hh = String(d.getUTCHours()).padStart(2, "0");
+  const mi = String(d.getUTCMinutes()).padStart(2, "0");
+  return `${yyyy}-${mm}-${dd} ${hh}:${mi} UTC`;
+}
+
+function formatBytes(n: number): string {
+  if (n < 1024) return `${n} B`;
+  if (n < 1024 * 1024) return `${(n / 1024).toFixed(1)} KB`;
+  if (n < 1024 * 1024 * 1024) return `${(n / (1024 * 1024)).toFixed(1)} MB`;
+  return `${(n / (1024 * 1024 * 1024)).toFixed(2)} GB`;
+}
+
+function escapeHTML(s: string): string {
+  return s.replace(/[&<>"']/g, (c) => {
+    switch (c) {
+      case "&": return "&amp;";
+      case "<": return "&lt;";
+      case ">": return "&gt;";
+      case '"': return "&quot;";
+      case "'": return "&#39;";
+      default: return c;
+    }
+  });
+}
+
+function escapeAttr(s: string): string {
+  return escapeHTML(s);
+}
+
+function showFeedback(kind: "success" | "error", text: string): void {
+  const el = document.getElementById("admin-backups-feedback") as HTMLElement | null;
+  if (!el) return;
+  el.textContent = text;
+  el.classList.remove("form-msg-success", "form-msg-error");
+  el.classList.add(kind === "success" ? "form-msg-success" : "form-msg-error");
+  el.style.display = "";
+}
+
+function clearFeedback(): void {
+  const el = document.getElementById("admin-backups-feedback") as HTMLElement | null;
+  if (!el) return;
+  el.style.display = "none";
+  el.textContent = "";
+  el.classList.remove("form-msg-success", "form-msg-error");
+}

frontend/src/client/admin-rules-edit.ts

@@ -0,0 +1,667 @@
+import { initI18n, onLangChange, t, tDyn, getLang } from "./i18n";
+import { initSidebar } from "./sidebar";
+
+// admin-rules-edit.ts — /admin/rules/{id}/edit. Loads a single rule
+// row, drives every form field, the preview widget, the audit-log
+// timeline and the lifecycle action bar. Every write is gated behind
+// a reason modal — the ≥10-char rule is enforced client-side per
+// Slice 11a edge case #4.
+
+interface Rule {
+  id: string;
+  proceeding_type_id?: number | null;
+  parent_id?: string | null;
+  // submission_code is the proceeding-prefixed identifier of this rule
+  // within its proceeding (e.g. `upc.inf.cfi.soc`), distinct from
+  // rule_code (legal citation, e.g. `RoP.013.1`).
+  submission_code?: string | null;
+  rule_code?: string | null;
+  name: string;
+  name_en: string;
+  description?: string | null;
+  primary_party?: string | null;
+  event_type?: string | null;
+  duration_value: number;
+  duration_unit: string;
+  timing?: string | null;
+  alt_duration_value?: number | null;
+  alt_duration_unit?: string | null;
+  alt_rule_code?: string | null;
+  anchor_alt?: string | null;
+  combine_op?: string | null;
+  legal_source?: string | null;
+  deadline_notes?: string | null;
+  deadline_notes_en?: string | null;
+  priority: string;
+  is_court_set: boolean;
+  is_spawn: boolean;
+  spawn_label?: string | null;
+  spawn_proceeding_type_id?: number | null;
+  trigger_event_id?: number | null;
+  condition_expr?: unknown;
+  sequence_order: number;
+  concept_id?: string | null;
+  lifecycle_state: string;
+  draft_of?: string | null;
+  published_at?: string | null;
+  updated_at: string;
+  created_at: string;
+}
+
+interface ProceedingType {
+  id: number;
+  code: string;
+  name_de: string;
+  name_en: string;
+}
+
+interface TriggerEvent {
+  id: number;
+  code: string;
+  name: string;
+  name_de: string;
+}
+
+interface AuditEntry {
+  id: string;
+  rule_id: string;
+  changed_by?: string | null;
+  changed_by_display_name?: string | null;
+  changed_at: string;
+  action: string;
+  before_json?: unknown;
+  after_json?: unknown;
+  reason: string;
+  migration_exported: boolean;
+}
+
+let ruleId = "";
+let rule: Rule | null = null;
+let proceedings: ProceedingType[] = [];
+let triggers: TriggerEvent[] = [];
+let auditEntries: AuditEntry[] = [];
+let auditOffset = 0;
+const AUDIT_PAGE = 20;
+let auditHasMore = false;
+let previewDebounce: number | undefined;
+
+function esc(s: string | null | undefined): string {
+  const d = document.createElement("div");
+  d.textContent = s ?? "";
+  return d.innerHTML;
+}
+
+function fmtDateTime(iso: string): string {
+  if (!iso) return "";
+  const d = new Date(iso);
+  if (Number.isNaN(d.getTime())) return iso;
+  const locale = getLang() === "de" ? "de-DE" : "en-GB";
+  return d.toLocaleString(locale, {
+    year: "numeric", month: "2-digit", day: "2-digit",
+    hour: "2-digit", minute: "2-digit",
+  });
+}
+
+function parseRuleIDFromPath(): string {
+  // /admin/rules/{uuid}/edit
+  const m = /^\/admin\/rules\/([^\/]+)\/edit\/?$/.exec(window.location.pathname);
+  return m ? decodeURIComponent(m[1]) : "";
+}
+
+function showFeedback(msg: string, isError: boolean) {
+  const el = document.getElementById("rules-edit-feedback") as HTMLElement | null;
+  if (!el) return;
+  el.textContent = msg;
+  el.className = "form-msg " + (isError ? "form-msg-error" : "form-msg-success");
+  el.style.display = "block";
+  if (!isError) {
+    setTimeout(() => { el.style.display = "none"; }, 4000);
+  }
+}
+
+function lifecycleLabel(state: string): string {
+  return tDyn(`admin.rules.lifecycle.${state}`) || state;
+}
+
+function lifecycleClass(state: string): string {
+  switch (state) {
+    case "draft": return "admin-rules-pill admin-rules-pill-draft";
+    case "published": return "admin-rules-pill admin-rules-pill-published";
+    case "archived": return "admin-rules-pill admin-rules-pill-archived";
+    default: return "admin-rules-pill";
+  }
+}
+
+// --------------------------------------------------------------------
+// Loaders.
+// --------------------------------------------------------------------
+async function loadProceedings(): Promise<void> {
+  const resp = await fetch("/api/proceeding-types-db?category=fristenrechner");
+  if (!resp.ok) return;
+  proceedings = (await resp.json()) as ProceedingType[];
+  fillProceedingSelect("f-proceeding", proceedings);
+  fillProceedingSelect("f-spawn-proceeding", proceedings);
+}
+
+async function loadTriggers(): Promise<void> {
+  const resp = await fetch("/api/tools/trigger-events");
+  if (!resp.ok) return;
+  triggers = (await resp.json()) as TriggerEvent[];
+  const sel = document.getElementById("f-trigger") as HTMLSelectElement | null;
+  if (!sel) return;
+  const placeholder = sel.querySelector('option[value=""]');
+  sel.innerHTML = "";
+  if (placeholder) sel.appendChild(placeholder);
+  for (const te of triggers) {
+    const opt = document.createElement("option");
+    opt.value = String(te.id);
+    opt.textContent = `${te.code} · ${getLang() === "en" ? te.name : te.name_de}`;
+    sel.appendChild(opt);
+  }
+}
+
+function fillProceedingSelect(selectId: string, list: ProceedingType[]) {
+  const sel = document.getElementById(selectId) as HTMLSelectElement | null;
+  if (!sel) return;
+  const placeholder = sel.querySelector('option[value=""]');
+  sel.innerHTML = "";
+  if (placeholder) sel.appendChild(placeholder);
+  for (const pt of list) {
+    const opt = document.createElement("option");
+    opt.value = String(pt.id);
+    opt.textContent = `${pt.code} · ${getLang() === "en" ? pt.name_en : pt.name_de}`;
+    sel.appendChild(opt);
+  }
+}
+
+async function loadRule(): Promise<void> {
+  const resp = await fetch(`/admin/api/rules/${encodeURIComponent(ruleId)}`);
+  if (!resp.ok) {
+    if (resp.status === 404) {
+      showFeedback(t("admin.rules.edit.error.not_found") || "Regel nicht gefunden.", true);
+    } else {
+      showFeedback(t("admin.rules.edit.error.load") || "Konnte Regel nicht laden.", true);
+    }
+    return;
+  }
+  rule = await resp.json() as Rule;
+  populateForm();
+  updateLifecycleUI();
+}
+
+async function loadAudit(reset: boolean = true): Promise<void> {
+  if (reset) {
+    auditEntries = [];
+    auditOffset = 0;
+  }
+  const resp = await fetch(`/admin/api/rules/${encodeURIComponent(ruleId)}/audit?offset=${auditOffset}&limit=${AUDIT_PAGE}`);
+  if (!resp.ok) return;
+  const body = await resp.json();
+  const rows = Array.isArray(body) ? body as AuditEntry[] : [];
+  auditEntries.push(...rows);
+  auditOffset += rows.length;
+  auditHasMore = rows.length === AUDIT_PAGE;
+  renderAudit();
+}
+
+// --------------------------------------------------------------------
+// Form binding.
+// --------------------------------------------------------------------
+function setInput(id: string, val: unknown) {
+  const el = document.getElementById(id) as HTMLInputElement | HTMLSelectElement | HTMLTextAreaElement | null;
+  if (!el) return;
+  if (val == null) {
+    el.value = "";
+    return;
+  }
+  el.value = String(val);
+}
+
+function setCheckbox(id: string, val: boolean) {
+  const el = document.getElementById(id) as HTMLInputElement | null;
+  if (!el) return;
+  el.checked = !!val;
+}
+
+function getInput(id: string): string {
+  const el = document.getElementById(id) as HTMLInputElement | HTMLSelectElement | HTMLTextAreaElement | null;
+  return el ? el.value.trim() : "";
+}
+
+function getCheckbox(id: string): boolean {
+  const el = document.getElementById(id) as HTMLInputElement | null;
+  return el ? el.checked : false;
+}
+
+function getOptionalInt(id: string): number | null {
+  const v = getInput(id);
+  if (!v) return null;
+  const n = parseInt(v, 10);
+  return Number.isFinite(n) ? n : null;
+}
+
+function getOptionalString(id: string): string | null {
+  const v = getInput(id);
+  return v ? v : null;
+}
+
+function populateForm() {
+  if (!rule) return;
+  const heading = document.getElementById("rules-edit-heading") as HTMLElement;
+  const idEl = document.getElementById("rules-edit-id") as HTMLElement;
+  const lifecycleEl = document.getElementById("rules-edit-lifecycle") as HTMLElement;
+  heading.textContent = (getLang() === "en" ? rule.name_en : rule.name) || rule.name;
+  idEl.textContent = rule.id;
+  lifecycleEl.className = lifecycleClass(rule.lifecycle_state);
+  lifecycleEl.textContent = lifecycleLabel(rule.lifecycle_state);
+
+  setInput("f-name", rule.name);
+  setInput("f-name-en", rule.name_en);
+  setInput("f-description", rule.description ?? "");
+  setInput("f-submission-code", rule.submission_code ?? "");
+  setInput("f-rule-code", rule.rule_code ?? "");
+  setInput("f-legal-source", rule.legal_source ?? "");
+  setInput("f-proceeding", rule.proceeding_type_id ?? "");
+  setInput("f-trigger", rule.trigger_event_id ?? "");
+  setInput("f-parent", rule.parent_id ?? "");
+  setInput("f-concept", rule.concept_id ?? "");
+  setInput("f-sequence", rule.sequence_order);
+  setInput("f-duration", rule.duration_value);
+  setInput("f-duration-unit", rule.duration_unit);
+  setInput("f-timing", rule.timing ?? "");
+  setInput("f-combine-op", rule.combine_op ?? "");
+  setInput("f-alt-duration", rule.alt_duration_value ?? "");
+  setInput("f-alt-duration-unit", rule.alt_duration_unit ?? "");
+  setInput("f-alt-rule-code", rule.alt_rule_code ?? "");
+  setInput("f-anchor-alt", rule.anchor_alt ?? "");
+  setInput("f-primary-party", rule.primary_party ?? "");
+  setInput("f-event-type", rule.event_type ?? "");
+  setInput("f-notes", rule.deadline_notes ?? "");
+  setInput("f-notes-en", rule.deadline_notes_en ?? "");
+  setInput("f-priority", rule.priority);
+  setCheckbox("f-is-court-set", rule.is_court_set);
+  setCheckbox("f-is-spawn", rule.is_spawn);
+  setInput("f-spawn-label", rule.spawn_label ?? "");
+  setInput("f-spawn-proceeding", rule.spawn_proceeding_type_id ?? "");
+  toggleSpawnRow();
+  setInput("f-condition-expr", rule.condition_expr ? JSON.stringify(rule.condition_expr, null, 2) : "");
+}
+
+function toggleSpawnRow() {
+  const row = document.getElementById("f-spawn-row") as HTMLElement | null;
+  if (!row) return;
+  row.style.display = getCheckbox("f-is-spawn") ? "" : "none";
+}
+
+function updateLifecycleUI() {
+  const draftOnly = (id: string, show: boolean) => {
+    const el = document.getElementById(id) as HTMLElement | null;
+    if (el) el.style.display = show ? "" : "none";
+  };
+  if (!rule) return;
+  const isDraft = rule.lifecycle_state === "draft";
+  const isPublished = rule.lifecycle_state === "published";
+  const isArchived = rule.lifecycle_state === "archived";
+
+  draftOnly("action-save-draft", isDraft);
+  draftOnly("action-publish", isDraft);
+  draftOnly("action-clone", isPublished || isArchived);
+  draftOnly("action-archive", isDraft || isPublished);
+  draftOnly("action-restore", isArchived);
+
+  // Lock form fields when not editable (i.e. not draft). Published /
+  // archived rules show the form read-only so editors can confirm
+  // they're about to clone the right row.
+  const readOnly = !isDraft;
+  document.querySelectorAll<HTMLInputElement | HTMLSelectElement | HTMLTextAreaElement>(
+    "#rules-edit-form input, #rules-edit-form select, #rules-edit-form textarea",
+  ).forEach((el) => {
+    el.disabled = readOnly;
+  });
+}
+
+function renderAudit() {
+  const list = document.getElementById("rules-edit-audit") as HTMLElement | null;
+  const more = document.getElementById("audit-loadmore") as HTMLElement | null;
+  if (!list) return;
+  if (auditEntries.length === 0) {
+    list.innerHTML = `<li class="admin-rules-audit-empty">${esc(t("admin.rules.edit.audit.empty") || "Keine Audit-Eintr&auml;ge.")}</li>`;
+  } else {
+    list.innerHTML = auditEntries.map((e) => {
+      const actor = e.changed_by_display_name || (e.changed_by ? e.changed_by.slice(0, 8) : (t("admin.rules.edit.audit.actor.system") || "System"));
+      const actionLabel = tDyn(`admin.rules.edit.audit.action.${e.action}`) || e.action;
+      const exported = e.migration_exported
+        ? `<span class="admin-rules-audit-badge">${esc(t("admin.rules.edit.audit.exported") || "exported")}</span>`
+        : "";
+      return `
+        <li class="admin-rules-audit-entry admin-rules-audit-action-${esc(e.action)}">
+          <div class="admin-rules-audit-head">
+            <span class="admin-rules-audit-action">${esc(actionLabel)}</span>
+            <span class="admin-rules-audit-time">${esc(fmtDateTime(e.changed_at))}</span>
+            ${exported}
+          </div>
+          <div class="admin-rules-audit-actor">${esc(actor)}</div>
+          ${e.reason ? `<div class="admin-rules-audit-reason">${esc(e.reason)}</div>` : ""}
+        </li>
+      `;
+    }).join("");
+  }
+  if (more) more.style.display = auditHasMore ? "" : "none";
+}
+
+// --------------------------------------------------------------------
+// Validation helpers.
+// --------------------------------------------------------------------
+function validateConditionExpr(): { ok: boolean; value: unknown | undefined; msg: string } {
+  const raw = getInput("f-condition-expr");
+  const msgEl = document.getElementById("f-condition-msg") as HTMLElement | null;
+  if (!raw) {
+    if (msgEl) {
+      msgEl.textContent = "";
+      msgEl.className = "admin-rules-hint";
+    }
+    return { ok: true, value: undefined, msg: "" };
+  }
+  try {
+    const parsed = JSON.parse(raw);
+    if (msgEl) {
+      msgEl.textContent = "✓ " + (t("admin.rules.edit.field.condition.valid") || "JSON gültig.");
+      msgEl.className = "admin-rules-hint admin-rules-hint-ok";
+    }
+    return { ok: true, value: parsed, msg: "" };
+  } catch (err) {
+    const m = err instanceof Error ? err.message : String(err);
+    if (msgEl) {
+      msgEl.textContent = "⚠ " + m;
+      msgEl.className = "admin-rules-hint admin-rules-hint-error";
+    }
+    return { ok: false, value: undefined, msg: m };
+  }
+}
+
+// --------------------------------------------------------------------
+// Action modal (reason + lifecycle handler).
+// --------------------------------------------------------------------
+type Action = "save-draft" | "publish" | "clone" | "archive" | "restore";
+
+let pendingAction: Action | null = null;
+
+function openActionModal(action: Action) {
+  pendingAction = action;
+  const modal = document.getElementById("rules-action-modal") as HTMLElement;
+  const title = document.getElementById("rules-action-modal-title") as HTMLElement;
+  const body = document.getElementById("rules-action-modal-body") as HTMLElement;
+  const msg = document.getElementById("rules-action-modal-msg") as HTMLElement;
+  const reasonInput = document.getElementById("rules-action-modal-reason") as HTMLTextAreaElement;
+  msg.style.display = "none";
+  reasonInput.value = "";
+  switch (action) {
+    case "save-draft":
+      title.textContent = t("admin.rules.edit.modal.save_draft.title") || "Draft speichern";
+      body.textContent = t("admin.rules.edit.modal.save_draft.body") || "Bitte einen Grund für die Änderung angeben (mind. 10 Zeichen). Wird ins Audit-Log geschrieben.";
+      break;
+    case "publish":
+      title.textContent = t("admin.rules.edit.modal.publish.title") || "Publish";
+      body.textContent = t("admin.rules.edit.modal.publish.body") || "Diese Draft-Regel wird live geschaltet. Bestehende publizierte Variante wird archiviert.";
+      break;
+    case "clone":
+      title.textContent = t("admin.rules.edit.modal.clone.title") || "Als Draft klonen";
+      body.textContent = t("admin.rules.edit.modal.clone.body") || "Eine neue Draft-Kopie dieser Regel wird angelegt. Sie werden auf die neue Draft-Seite weitergeleitet.";
+      break;
+    case "archive":
+      title.textContent = t("admin.rules.edit.modal.archive.title") || "Archivieren";
+      body.textContent = t("admin.rules.edit.modal.archive.body") || "Regel wird archiviert. Calculator nutzt sie nicht mehr.";
+      break;
+    case "restore":
+      title.textContent = t("admin.rules.edit.modal.restore.title") || "Wiederherstellen";
+      body.textContent = t("admin.rules.edit.modal.restore.body") || "Regel wird wiederhergestellt (archived → published).";
+      break;
+  }
+  modal.style.display = "flex";
+  reasonInput.focus();
+}
+
+function closeActionModal() {
+  (document.getElementById("rules-action-modal") as HTMLElement).style.display = "none";
+  pendingAction = null;
+}
+
+async function submitActionModal(ev: Event) {
+  ev.preventDefault();
+  if (!pendingAction || !rule) return;
+  const reasonInput = document.getElementById("rules-action-modal-reason") as HTMLTextAreaElement;
+  const msg = document.getElementById("rules-action-modal-msg") as HTMLElement;
+  const submit = document.getElementById("rules-action-modal-submit") as HTMLButtonElement;
+  const reason = reasonInput.value.trim();
+  if (reason.length < 10) {
+    msg.textContent = t("admin.rules.modal.reason.too_short") || "Grund muss mindestens 10 Zeichen enthalten.";
+    msg.className = "form-msg form-msg-error";
+    msg.style.display = "block";
+    return;
+  }
+  submit.disabled = true;
+  try {
+    if (pendingAction === "save-draft") {
+      await doSaveDraft(reason);
+    } else if (pendingAction === "publish") {
+      await doLifecycle("publish", reason);
+    } else if (pendingAction === "clone") {
+      await doClone(reason);
+    } else if (pendingAction === "archive") {
+      await doLifecycle("archive", reason);
+    } else if (pendingAction === "restore") {
+      await doLifecycle("restore", reason);
+    }
+  } finally {
+    submit.disabled = false;
+  }
+}
+
+function buildPatchPayload(): Record<string, unknown> {
+  const validation = validateConditionExpr();
+  if (!validation.ok) throw new Error(validation.msg);
+  const payload: Record<string, unknown> = {
+    name: getInput("f-name"),
+    name_en: getInput("f-name-en"),
+    description: getInput("f-description"),
+    primary_party: getInput("f-primary-party"),
+    event_type: getInput("f-event-type"),
+    duration_value: getOptionalInt("f-duration") ?? 0,
+    duration_unit: getInput("f-duration-unit"),
+    timing: getOptionalString("f-timing"),
+    alt_duration_value: getOptionalInt("f-alt-duration"),
+    alt_duration_unit: getOptionalString("f-alt-duration-unit"),
+    alt_rule_code: getOptionalString("f-alt-rule-code"),
+    anchor_alt: getOptionalString("f-anchor-alt"),
+    combine_op: getOptionalString("f-combine-op"),
+    rule_code: getOptionalString("f-rule-code"),
+    legal_source: getOptionalString("f-legal-source"),
+    deadline_notes: getInput("f-notes"),
+    deadline_notes_en: getInput("f-notes-en"),
+    priority: getInput("f-priority"),
+    is_court_set: getCheckbox("f-is-court-set"),
+    is_spawn: getCheckbox("f-is-spawn"),
+    spawn_label: getOptionalString("f-spawn-label"),
+    spawn_proceeding_type_id: getOptionalInt("f-spawn-proceeding"),
+    trigger_event_id: getOptionalInt("f-trigger"),
+    sequence_order: getOptionalInt("f-sequence") ?? 0,
+  };
+  if (validation.value !== undefined) {
+    payload.condition_expr = validation.value;
+  }
+  return payload;
+}
+
+async function doSaveDraft(reason: string) {
+  const msg = document.getElementById("rules-action-modal-msg") as HTMLElement;
+  let payload: Record<string, unknown>;
+  try {
+    payload = buildPatchPayload();
+  } catch (e) {
+    msg.textContent = e instanceof Error ? e.message : String(e);
+    msg.className = "form-msg form-msg-error";
+    msg.style.display = "block";
+    return;
+  }
+  payload.reason = reason;
+  const resp = await fetch(`/admin/api/rules/${encodeURIComponent(ruleId)}`, {
+    method: "PATCH",
+    headers: { "Content-Type": "application/json" },
+    body: JSON.stringify(payload),
+  });
+  if (!resp.ok) {
+    const body = await resp.json().catch(() => ({ error: resp.statusText }));
+    msg.textContent = body.error || (t("admin.rules.edit.action.save_draft.error") || "Speichern fehlgeschlagen.");
+    msg.className = "form-msg form-msg-error";
+    msg.style.display = "block";
+    return;
+  }
+  rule = await resp.json() as Rule;
+  closeActionModal();
+  populateForm();
+  updateLifecycleUI();
+  await loadAudit(true);
+  showFeedback(t("admin.rules.edit.action.save_draft.ok") || "Draft gespeichert.", false);
+}
+
+async function doLifecycle(op: "publish" | "archive" | "restore", reason: string) {
+  const msg = document.getElementById("rules-action-modal-msg") as HTMLElement;
+  const resp = await fetch(`/admin/api/rules/${encodeURIComponent(ruleId)}/${op}`, {
+    method: "POST",
+    headers: { "Content-Type": "application/json" },
+    body: JSON.stringify({ reason }),
+  });
+  if (!resp.ok) {
+    const body = await resp.json().catch(() => ({ error: resp.statusText }));
+    msg.textContent = body.error || (tDyn(`admin.rules.edit.action.${op}.error`) || "Aktion fehlgeschlagen.");
+    msg.className = "form-msg form-msg-error";
+    msg.style.display = "block";
+    return;
+  }
+  rule = await resp.json() as Rule;
+  closeActionModal();
+  populateForm();
+  updateLifecycleUI();
+  await loadAudit(true);
+  showFeedback(tDyn(`admin.rules.edit.action.${op}.ok`) || (t("admin.rules.edit.action.ok") || "Erledigt."), false);
+}
+
+async function doClone(reason: string) {
+  const msg = document.getElementById("rules-action-modal-msg") as HTMLElement;
+  const resp = await fetch(`/admin/api/rules/${encodeURIComponent(ruleId)}/clone-as-draft`, {
+    method: "POST",
+    headers: { "Content-Type": "application/json" },
+    body: JSON.stringify({ reason }),
+  });
+  if (!resp.ok) {
+    const body = await resp.json().catch(() => ({ error: resp.statusText }));
+    msg.textContent = body.error || (t("admin.rules.edit.action.clone.error") || "Klonen fehlgeschlagen.");
+    msg.className = "form-msg form-msg-error";
+    msg.style.display = "block";
+    return;
+  }
+  const newRule = await resp.json() as Rule;
+  window.location.href = `/admin/rules/${encodeURIComponent(newRule.id)}/edit`;
+}
+
+// --------------------------------------------------------------------
+// Preview.
+// --------------------------------------------------------------------
+async function runPreview() {
+  const out = document.getElementById("preview-result") as HTMLElement;
+  if (!rule) return;
+  if (rule.lifecycle_state !== "draft") {
+    out.innerHTML = `<p class="admin-rules-hint admin-rules-hint-error">${esc(t("admin.rules.edit.preview.only_drafts") || "Preview ist nur für Drafts verfügbar.")}</p>`;
+    out.style.display = "";
+    return;
+  }
+  const triggerDate = getInput("preview-trigger-date");
+  if (!triggerDate) {
+    out.innerHTML = `<p class="admin-rules-hint admin-rules-hint-error">${esc(t("admin.rules.edit.preview.trigger_required") || "Bitte Trigger-Datum angeben.")}</p>`;
+    out.style.display = "";
+    return;
+  }
+  const flagsRaw = getInput("preview-flags");
+  const qs = new URLSearchParams();
+  qs.set("trigger_date", triggerDate);
+  if (flagsRaw) qs.set("flags", flagsRaw);
+  out.innerHTML = `<p class="admin-rules-loading">${esc(t("admin.rules.edit.preview.running") || "Berechne...")}</p>`;
+  out.style.display = "";
+  const resp = await fetch(`/admin/api/rules/${encodeURIComponent(ruleId)}/preview?${qs.toString()}`);
+  if (!resp.ok) {
+    const body = await resp.json().catch(() => ({ error: resp.statusText }));
+    out.innerHTML = `<p class="admin-rules-hint admin-rules-hint-error">${esc(body.error || (t("admin.rules.edit.preview.error") || "Preview fehlgeschlagen."))}</p>`;
+    return;
+  }
+  const body = await resp.json();
+  renderPreview(body);
+}
+
+function renderPreview(resp: unknown) {
+  const out = document.getElementById("preview-result") as HTMLElement;
+  type Result = { deadlines?: Array<{ name?: string; titleDE?: string; due_date?: string; dueDate?: string; ruleCode?: string; rule_code?: string }>; deadline?: Array<unknown> };
+  const r = resp as Result;
+  const list = (r && (r.deadlines || r.deadline)) as Array<Record<string, unknown>> | undefined;
+  if (!list || list.length === 0) {
+    out.innerHTML = `<p class="admin-rules-hint">${esc(t("admin.rules.edit.preview.empty") || "Keine Deadlines.")}</p>`;
+    return;
+  }
+  out.innerHTML = `<ul class="admin-rules-preview-list">${list.map((d) => {
+    const name = String(d.name || d.titleDE || d.title || "");
+    const date = String(d.due_date || d.dueDate || "");
+    const code = String(d.rule_code || d.ruleCode || "");
+    return `<li>
+      ${code ? `<code>${esc(code)}</code>` : ""}
+      <span class="admin-rules-preview-name">${esc(name)}</span>
+      <span class="admin-rules-preview-date">${esc(date)}</span>
+    </li>`;
+  }).join("")}</ul>`;
+}
+
+// --------------------------------------------------------------------
+// Init.
+// --------------------------------------------------------------------
+async function init() {
+  initI18n();
+  initSidebar();
+  ruleId = parseRuleIDFromPath();
+  if (!ruleId) {
+    showFeedback(t("admin.rules.edit.error.bad_id") || "Ungültige Regel-ID in der URL.", true);
+    return;
+  }
+
+  (document.getElementById("rules-action-modal-close") as HTMLElement).addEventListener("click", closeActionModal);
+  (document.getElementById("rules-action-modal-cancel") as HTMLElement).addEventListener("click", closeActionModal);
+  (document.getElementById("rules-action-modal-form") as HTMLFormElement).addEventListener("submit", submitActionModal);
+
+  (document.getElementById("action-save-draft") as HTMLElement).addEventListener("click", () => openActionModal("save-draft"));
+  (document.getElementById("action-publish") as HTMLElement).addEventListener("click", () => openActionModal("publish"));
+  (document.getElementById("action-clone") as HTMLElement).addEventListener("click", () => openActionModal("clone"));
+  (document.getElementById("action-archive") as HTMLElement).addEventListener("click", () => openActionModal("archive"));
+  (document.getElementById("action-restore") as HTMLElement).addEventListener("click", () => openActionModal("restore"));
+
+  (document.getElementById("f-is-spawn") as HTMLInputElement).addEventListener("change", toggleSpawnRow);
+  (document.getElementById("f-condition-expr") as HTMLTextAreaElement).addEventListener("input", () => {
+    validateConditionExpr();
+  });
+
+  (document.getElementById("preview-run") as HTMLElement).addEventListener("click", () => {
+    window.clearTimeout(previewDebounce);
+    previewDebounce = window.setTimeout(runPreview, 100);
+  });
+  (document.getElementById("audit-loadmore") as HTMLElement).addEventListener("click", () => loadAudit(false));
+
+  await Promise.all([loadProceedings(), loadTriggers()]);
+  await loadRule();
+  await loadAudit(true);
+
+  onLangChange(() => {
+    if (rule) {
+      populateForm();
+      updateLifecycleUI();
+    }
+    renderAudit();
+  });
+}
+
+document.addEventListener("DOMContentLoaded", init);

frontend/src/client/admin-rules-export.ts

@@ -0,0 +1,100 @@
+import { initI18n, t } from "./i18n";
+import { initSidebar } from "./sidebar";
+
+// admin-rules-export.ts — /admin/rules/export. Calls
+// GET /admin/api/rules/export-migrations[?since=<uuid>] and renders the
+// SQL blob server-side. Download builds a Blob URL and triggers a
+// fake <a> click; copy uses navigator.clipboard.
+
+interface ExportResult {
+  migration_sql: string;
+  count: number;
+  latest_audit_id: string;
+}
+
+let latest: ExportResult | null = null;
+
+function showFeedback(msg: string, isError: boolean) {
+  const el = document.getElementById("export-feedback") as HTMLElement | null;
+  if (!el) return;
+  el.textContent = msg;
+  el.className = "form-msg " + (isError ? "form-msg-error" : "form-msg-success");
+  el.style.display = "block";
+  if (!isError) setTimeout(() => { el.style.display = "none"; }, 4000);
+}
+
+async function runExport() {
+  const since = (document.getElementById("export-since") as HTMLInputElement).value.trim();
+  const qs = new URLSearchParams();
+  if (since) qs.set("since", since);
+  const url = "/admin/api/rules/export-migrations" + (qs.toString() ? "?" + qs.toString() : "");
+  const out = document.getElementById("export-output") as HTMLElement;
+  const summary = document.getElementById("export-summary") as HTMLElement;
+  const dl = document.getElementById("export-download") as HTMLElement;
+  const cp = document.getElementById("export-copy") as HTMLElement;
+  out.textContent = t("admin.rules.export.running") || "Lade...";
+  summary.style.display = "none";
+  dl.style.display = "none";
+  cp.style.display = "none";
+
+  const resp = await fetch(url);
+  if (!resp.ok) {
+    const body = await resp.json().catch(() => ({ error: resp.statusText }));
+    showFeedback(body.error || (t("admin.rules.export.error") || "Export fehlgeschlagen."), true);
+    out.textContent = "";
+    return;
+  }
+  latest = await resp.json() as ExportResult;
+  out.textContent = latest.migration_sql;
+  summary.style.display = "";
+  const countEl = document.getElementById("export-summary-count") as HTMLElement;
+  const latestEl = document.getElementById("export-summary-latest") as HTMLElement;
+  countEl.textContent = (t("admin.rules.export.count") || "Audit-Zeilen: {n}").replace("{n}", String(latest.count));
+  if (latest.latest_audit_id) {
+    latestEl.textContent = (t("admin.rules.export.latest") || "Letzte Audit-ID: {id}").replace("{id}", latest.latest_audit_id);
+  } else {
+    latestEl.textContent = "";
+  }
+  if (latest.count > 0) {
+    dl.style.display = "";
+    cp.style.display = "";
+    showFeedback((t("admin.rules.export.ok") || "{n} Audit-Zeilen exportiert.").replace("{n}", String(latest.count)), false);
+  } else {
+    showFeedback(t("admin.rules.export.no_pending") || "Keine offenen Audit-Zeilen zum Export.", false);
+  }
+}
+
+function downloadFile() {
+  if (!latest) return;
+  const ts = new Date().toISOString().replace(/[:.]/g, "-").slice(0, 19);
+  const name = `rules-export-${ts}.up.sql`;
+  const blob = new Blob([latest.migration_sql], { type: "application/sql" });
+  const url = URL.createObjectURL(blob);
+  const a = document.createElement("a");
+  a.href = url;
+  a.download = name;
+  document.body.appendChild(a);
+  a.click();
+  document.body.removeChild(a);
+  URL.revokeObjectURL(url);
+}
+
+async function copyToClipboard() {
+  if (!latest) return;
+  try {
+    await navigator.clipboard.writeText(latest.migration_sql);
+    showFeedback(t("admin.rules.export.copied") || "In Zwischenablage kopiert.", false);
+  } catch (e) {
+    showFeedback(t("admin.rules.export.copy_failed") || "Kopieren fehlgeschlagen.", true);
+  }
+}
+
+function init() {
+  initI18n();
+  initSidebar();
+  (document.getElementById("export-run") as HTMLElement).addEventListener("click", runExport);
+  (document.getElementById("export-download") as HTMLElement).addEventListener("click", downloadFile);
+  (document.getElementById("export-copy") as HTMLElement).addEventListener("click", copyToClipboard);
+}
+
+document.addEventListener("DOMContentLoaded", init);

frontend/src/client/admin-rules-list.ts

@@ -0,0 +1,524 @@
+import { initI18n, onLangChange, t, tDyn, getLang } from "./i18n";
+import { initSidebar } from "./sidebar";
+
+// admin-rules-list.ts — /admin/rules. Drives the rule table (filterable
+// by proceeding type, trigger event, lifecycle state, free-text query)
+// plus the Orphans tab (Slice 10 backfill staging rows). Row click on
+// a rule routes to /admin/rules/{id}/edit; orphan cards have their own
+// "Pick" affordance with an inline reason prompt that posts to
+// /admin/api/orphans/{id}/resolve.
+
+interface Rule {
+  id: string;
+  proceeding_type_id?: number | null;
+  // submission_code is the proceeding-prefixed identifier of this rule
+  // within its proceeding (e.g. `upc.inf.cfi.soc`), distinct from
+  // rule_code (the legal citation, e.g. `RoP.013.1`).
+  submission_code?: string | null;
+  rule_code?: string | null;
+  name: string;
+  name_en: string;
+  priority: string;
+  lifecycle_state: string;
+  updated_at: string;
+  trigger_event_id?: number | null;
+  duration_value: number;
+  duration_unit: string;
+}
+
+interface ProceedingType {
+  id: number;
+  code: string;
+  name_de: string;
+  name_en: string;
+  category: string;
+}
+
+interface TriggerEvent {
+  id: number;
+  code: string;
+  name: string;
+  name_de: string;
+}
+
+interface OrphanCandidate {
+  id: string;
+  rule_code?: string | null;
+  name: string;
+  name_en: string;
+}
+
+interface Orphan {
+  id: string;
+  deadline_id: string;
+  title: string;
+  project_id?: string | null;
+  project_title?: string | null;
+  proceeding_code?: string | null;
+  reason: string;
+  candidate_count: number;
+  candidate_ids: string[];
+  candidates: OrphanCandidate[];
+  created_at: string;
+}
+
+let rules: Rule[] = [];
+let orphans: Orphan[] = [];
+let proceedings: ProceedingType[] = [];
+let triggerEvents: TriggerEvent[] = [];
+
+let activeProceeding = "";
+let activeTrigger = "";
+let activeLifecycle = "";
+let activeQuery = "";
+let searchDebounce: number | undefined;
+
+function esc(s: string | null | undefined): string {
+  const d = document.createElement("div");
+  d.textContent = s ?? "";
+  return d.innerHTML;
+}
+
+function fmtDateTime(iso: string): string {
+  if (!iso) return "";
+  const d = new Date(iso);
+  if (Number.isNaN(d.getTime())) return iso;
+  const locale = getLang() === "de" ? "de-DE" : "en-GB";
+  return d.toLocaleString(locale, {
+    year: "numeric",
+    month: "2-digit",
+    day: "2-digit",
+    hour: "2-digit",
+    minute: "2-digit",
+  });
+}
+
+function showFeedback(msg: string, isError: boolean) {
+  const el = document.getElementById("rules-feedback") as HTMLElement | null;
+  if (!el) return;
+  el.textContent = msg;
+  el.className = "form-msg " + (isError ? "form-msg-error" : "form-msg-success");
+  el.style.display = "block";
+  if (!isError) {
+    setTimeout(() => { el.style.display = "none"; }, 4000);
+  }
+}
+
+function lifecycleLabel(state: string): string {
+  return tDyn(`admin.rules.lifecycle.${state}`) || state;
+}
+
+function lifecycleClass(state: string): string {
+  switch (state) {
+    case "draft": return "admin-rules-pill admin-rules-pill-draft";
+    case "published": return "admin-rules-pill admin-rules-pill-published";
+    case "archived": return "admin-rules-pill admin-rules-pill-archived";
+    default: return "admin-rules-pill";
+  }
+}
+
+function priorityLabel(p: string): string {
+  return tDyn(`admin.rules.priority.${p}`) || p;
+}
+
+function proceedingLabel(id: number | null | undefined): string {
+  if (id == null) return "—";
+  const pt = proceedings.find((p) => p.id === id);
+  if (!pt) return `#${id}`;
+  const name = getLang() === "en" ? pt.name_en : pt.name_de;
+  return `${pt.code} · ${name}`;
+}
+
+function buildFilterURL(): string {
+  const qs = new URLSearchParams();
+  if (activeProceeding) qs.set("proceeding_type_id", activeProceeding);
+  if (activeTrigger) qs.set("trigger_event_id", activeTrigger);
+  if (activeLifecycle) qs.set("lifecycle_state", activeLifecycle);
+  if (activeQuery) qs.set("q", activeQuery);
+  qs.set("limit", "500");
+  return "/admin/api/rules?" + qs.toString();
+}
+
+async function loadProceedings(): Promise<void> {
+  const resp = await fetch("/api/proceeding-types-db?category=fristenrechner");
+  if (!resp.ok) return;
+  proceedings = (await resp.json()) as ProceedingType[];
+  const sel = document.getElementById("rules-filter-proceeding") as HTMLSelectElement | null;
+  if (!sel) return;
+  // Preserve the "Alle" placeholder option then append every proceeding.
+  // The placeholder is the one with empty value already in the markup.
+  const placeholder = sel.querySelector('option[value=""]');
+  sel.innerHTML = "";
+  if (placeholder) sel.appendChild(placeholder);
+  for (const pt of proceedings) {
+    const opt = document.createElement("option");
+    opt.value = String(pt.id);
+    opt.textContent = `${pt.code} · ${getLang() === "en" ? pt.name_en : pt.name_de}`;
+    sel.appendChild(opt);
+  }
+}
+
+async function loadTriggerEvents(): Promise<void> {
+  const resp = await fetch("/api/tools/trigger-events");
+  if (!resp.ok) return;
+  triggerEvents = (await resp.json()) as TriggerEvent[];
+  const sel = document.getElementById("rules-filter-trigger") as HTMLSelectElement | null;
+  if (!sel) return;
+  const placeholder = sel.querySelector('option[value=""]');
+  sel.innerHTML = "";
+  if (placeholder) sel.appendChild(placeholder);
+  for (const te of triggerEvents) {
+    const opt = document.createElement("option");
+    opt.value = String(te.id);
+    opt.textContent = `${te.code} · ${getLang() === "en" ? te.name : te.name_de}`;
+    sel.appendChild(opt);
+  }
+}
+
+async function loadRules(): Promise<void> {
+  const resp = await fetch(buildFilterURL());
+  if (!resp.ok) {
+    showFeedback(t("admin.rules.error.load") || "Konnte Regeln nicht laden.", true);
+    rules = [];
+    return;
+  }
+  const body = await resp.json();
+  rules = Array.isArray(body) ? body as Rule[] : [];
+}
+
+async function loadOrphans(): Promise<void> {
+  const resp = await fetch("/admin/api/orphans");
+  if (!resp.ok) {
+    orphans = [];
+    return;
+  }
+  const body = await resp.json();
+  orphans = Array.isArray(body) ? body as Orphan[] : [];
+  updateOrphansBadge();
+}
+
+function updateOrphansBadge() {
+  const badge = document.getElementById("rules-orphans-badge") as HTMLElement | null;
+  if (!badge) return;
+  if (orphans.length === 0) {
+    badge.style.display = "none";
+  } else {
+    badge.style.display = "";
+    badge.textContent = String(orphans.length);
+  }
+}
+
+function renderRulesTable() {
+  const tbody = document.getElementById("rules-tbody") as HTMLElement | null;
+  const empty = document.getElementById("rules-empty") as HTMLElement | null;
+  if (!tbody || !empty) return;
+
+  if (rules.length === 0) {
+    tbody.innerHTML = "";
+    empty.style.display = "block";
+    return;
+  }
+  empty.style.display = "none";
+  const name = (r: Rule) => (getLang() === "en" ? r.name_en : r.name) || r.name;
+  tbody.innerHTML = rules.map((r) => `
+    <tr data-row-id="${esc(r.id)}" class="admin-rules-row">
+      <td class="admin-rules-col-code"><code>${esc(r.submission_code || "")}</code></td>
+      <td class="admin-rules-col-legal"><code>${esc(r.rule_code || "")}</code></td>
+      <td>${esc(name(r))}</td>
+      <td>${esc(proceedingLabel(r.proceeding_type_id ?? null))}</td>
+      <td><span class="admin-rules-priority admin-rules-priority-${esc(r.priority)}">${esc(priorityLabel(r.priority))}</span></td>
+      <td><span class="${lifecycleClass(r.lifecycle_state)}">${esc(lifecycleLabel(r.lifecycle_state))}</span></td>
+      <td class="admin-rules-col-modified">${esc(fmtDateTime(r.updated_at))}</td>
+    </tr>
+  `).join("");
+
+  tbody.querySelectorAll<HTMLElement>(".admin-rules-row").forEach((row) => {
+    row.addEventListener("click", (ev) => {
+      const target = ev.target as HTMLElement | null;
+      if (target && (target.closest("a") || target.closest("button"))) return;
+      const id = row.dataset.rowId;
+      if (!id) return;
+      window.location.href = `/admin/rules/${encodeURIComponent(id)}/edit`;
+    });
+  });
+}
+
+function renderOrphans() {
+  const list = document.getElementById("rules-orphans-list") as HTMLElement | null;
+  if (!list) return;
+  if (orphans.length === 0) {
+    list.innerHTML = `<p class="entity-empty" data-i18n="admin.rules.orphans.empty">${esc(t("admin.rules.orphans.empty") || "Keine offenen Orphans. ✔")}</p>`;
+    return;
+  }
+  list.innerHTML = orphans.map((o) => renderOrphanCard(o)).join("");
+  list.querySelectorAll<HTMLButtonElement>(".admin-rules-orphan-pick").forEach((btn) => {
+    btn.addEventListener("click", () => {
+      const orphanId = btn.dataset.orphanId!;
+      const ruleId = btn.dataset.ruleId!;
+      onPickOrphanCandidate(orphanId, ruleId);
+    });
+  });
+}
+
+function renderOrphanCard(o: Orphan): string {
+  const reasonLabel = tDyn(`admin.rules.orphans.reason.${o.reason}`) || o.reason;
+  const meta = [
+    o.project_title ? `<span class="admin-rules-orphan-meta">${esc(t("admin.rules.orphans.field.project") || "Projekt")}: ${esc(o.project_title)}</span>` : "",
+    o.proceeding_code ? `<span class="admin-rules-orphan-meta">${esc(t("admin.rules.orphans.field.proceeding") || "Verfahren")}: <code>${esc(o.proceeding_code)}</code></span>` : "",
+    `<span class="admin-rules-orphan-meta">${esc(t("admin.rules.orphans.field.reason") || "Grund")}: ${esc(reasonLabel)}</span>`,
+  ].filter(Boolean).join(" · ");
+
+  let candidatesHTML = "";
+  if (o.candidates.length === 0) {
+    candidatesHTML = `<p class="admin-rules-orphan-empty">${esc(t("admin.rules.orphans.no_candidates") || "Keine Kandidaten gefunden. Bitte Regel manuell anlegen.")}</p>`;
+  } else {
+    candidatesHTML = `<div class="admin-rules-orphan-candidates">
+      ${o.candidates.map((c) => {
+        const cname = getLang() === "en" ? c.name_en : c.name;
+        return `<button type="button" class="admin-rules-orphan-pick"
+          data-orphan-id="${esc(o.id)}" data-rule-id="${esc(c.id)}">
+          <code>${esc(c.rule_code || "")}</code>
+          <span class="admin-rules-orphan-pick-name">${esc(cname)}</span>
+        </button>`;
+      }).join("")}
+    </div>`;
+  }
+
+  return `
+    <div class="admin-rules-orphan-card" data-orphan-id="${esc(o.id)}">
+      <div class="admin-rules-orphan-header">
+        <div class="admin-rules-orphan-title">${esc(o.title)}</div>
+        <div class="admin-rules-orphan-metas">${meta}</div>
+      </div>
+      ${candidatesHTML}
+    </div>
+  `;
+}
+
+// --------------------------------------------------------------------
+// Reason modal — shared between "+ Neue Regel" and orphan resolve.
+// --------------------------------------------------------------------
+type ModalContext =
+  | { kind: "new-rule" }
+  | { kind: "orphan-resolve"; orphanId: string; ruleId: string };
+
+let modalCtx: ModalContext | null = null;
+
+function openReasonModal(ctx: ModalContext) {
+  modalCtx = ctx;
+  const modal = document.getElementById("rules-reason-modal") as HTMLElement;
+  const title = document.getElementById("rules-reason-title") as HTMLElement;
+  const body = document.getElementById("rules-reason-body") as HTMLElement;
+  const extra = document.getElementById("rules-reason-extra") as HTMLElement;
+  const msg = document.getElementById("rules-reason-msg") as HTMLElement;
+  const reasonInput = document.getElementById("rules-reason-text") as HTMLTextAreaElement;
+  msg.style.display = "none";
+  reasonInput.value = "";
+  extra.innerHTML = "";
+
+  if (ctx.kind === "new-rule") {
+    title.textContent = t("admin.rules.modal.new.title") || "Neue Regel anlegen";
+    body.textContent = t("admin.rules.modal.new.body") || "Eine neue Regel wird als Draft angelegt. Bitte einen Grund angeben.";
+    extra.innerHTML = `
+      <div class="form-field">
+        <label for="rules-new-name" data-i18n="admin.rules.modal.field.name">Name (DE)</label>
+        <input type="text" id="rules-new-name" class="admin-rules-input" required minlength="2" />
+      </div>
+      <div class="form-field">
+        <label for="rules-new-name-en" data-i18n="admin.rules.modal.field.name_en">Name (EN)</label>
+        <input type="text" id="rules-new-name-en" class="admin-rules-input" required minlength="2" />
+      </div>
+      <div class="form-field">
+        <label for="rules-new-duration" data-i18n="admin.rules.modal.field.duration">Dauer</label>
+        <div class="admin-rules-duration-row">
+          <input type="number" id="rules-new-duration" class="admin-rules-input" min="0" value="0" required />
+          <select id="rules-new-unit" class="admin-rules-select">
+            <option value="days">days</option>
+            <option value="weeks">weeks</option>
+            <option value="months">months</option>
+            <option value="working_days">working_days</option>
+          </select>
+        </div>
+      </div>
+    `;
+  } else {
+    title.textContent = t("admin.rules.modal.resolve.title") || "Orphan zuordnen";
+    body.textContent = t("admin.rules.modal.resolve.body") || "Bitte einen Grund (mind. 10 Zeichen) angeben.";
+  }
+  modal.style.display = "flex";
+  reasonInput.focus();
+}
+
+function closeReasonModal() {
+  const modal = document.getElementById("rules-reason-modal") as HTMLElement;
+  modal.style.display = "none";
+  modalCtx = null;
+}
+
+async function submitReasonModal(ev: Event) {
+  ev.preventDefault();
+  if (!modalCtx) return;
+  const reasonInput = document.getElementById("rules-reason-text") as HTMLTextAreaElement;
+  const msg = document.getElementById("rules-reason-msg") as HTMLElement;
+  const submit = document.getElementById("rules-reason-submit") as HTMLButtonElement;
+  const reason = reasonInput.value.trim();
+  if (reason.length < 10) {
+    msg.textContent = t("admin.rules.modal.reason.too_short") || "Grund muss mindestens 10 Zeichen enthalten.";
+    msg.className = "form-msg form-msg-error";
+    msg.style.display = "block";
+    return;
+  }
+  submit.disabled = true;
+  try {
+    if (modalCtx.kind === "new-rule") {
+      const name = (document.getElementById("rules-new-name") as HTMLInputElement).value.trim();
+      const nameEn = (document.getElementById("rules-new-name-en") as HTMLInputElement).value.trim();
+      const duration = parseInt((document.getElementById("rules-new-duration") as HTMLInputElement).value, 10);
+      const unit = (document.getElementById("rules-new-unit") as HTMLSelectElement).value;
+      if (!name || !nameEn) {
+        msg.textContent = t("admin.rules.modal.error.name_required") || "Bitte Name und Name (EN) angeben.";
+        msg.className = "form-msg form-msg-error";
+        msg.style.display = "block";
+        submit.disabled = false;
+        return;
+      }
+      const resp = await fetch("/admin/api/rules", {
+        method: "POST",
+        headers: { "Content-Type": "application/json" },
+        body: JSON.stringify({
+          name,
+          name_en: nameEn,
+          duration_value: Number.isFinite(duration) ? duration : 0,
+          duration_unit: unit,
+          priority: "mandatory",
+          is_court_set: false,
+          is_spawn: false,
+          sequence_order: 0,
+          reason,
+        }),
+      });
+      if (!resp.ok) {
+        const body = await resp.json().catch(() => ({ error: resp.statusText }));
+        msg.textContent = body.error || t("admin.rules.modal.error.create") || "Anlegen fehlgeschlagen.";
+        msg.className = "form-msg form-msg-error";
+        msg.style.display = "block";
+        submit.disabled = false;
+        return;
+      }
+      const created = await resp.json();
+      window.location.href = `/admin/rules/${encodeURIComponent(created.id)}/edit`;
+      return;
+    }
+
+    if (modalCtx.kind === "orphan-resolve") {
+      const resp = await fetch(`/admin/api/orphans/${encodeURIComponent(modalCtx.orphanId)}/resolve`, {
+        method: "POST",
+        headers: { "Content-Type": "application/json" },
+        body: JSON.stringify({ rule_id: modalCtx.ruleId, reason }),
+      });
+      if (!resp.ok) {
+        const body = await resp.json().catch(() => ({ error: resp.statusText }));
+        msg.textContent = body.error || t("admin.rules.modal.error.resolve") || "Zuordnung fehlgeschlagen.";
+        msg.className = "form-msg form-msg-error";
+        msg.style.display = "block";
+        submit.disabled = false;
+        return;
+      }
+      closeReasonModal();
+      showFeedback(t("admin.rules.orphans.resolved") || "Orphan zugeordnet.", false);
+      await loadOrphans();
+      renderOrphans();
+    }
+  } finally {
+    submit.disabled = false;
+  }
+}
+
+function onPickOrphanCandidate(orphanId: string, ruleId: string) {
+  openReasonModal({ kind: "orphan-resolve", orphanId, ruleId });
+}
+
+// --------------------------------------------------------------------
+// Tabs + filter wiring.
+// --------------------------------------------------------------------
+function setActiveTab(name: "rules" | "orphans") {
+  const paneRules = document.getElementById("rules-pane-rules") as HTMLElement;
+  const paneOrphans = document.getElementById("rules-pane-orphans") as HTMLElement;
+  const tabRules = document.getElementById("rules-tab-rules") as HTMLElement;
+  const tabOrphans = document.getElementById("rules-tab-orphans") as HTMLElement;
+  if (name === "rules") {
+    paneRules.style.display = "";
+    paneOrphans.style.display = "none";
+    tabRules.classList.add("active");
+    tabOrphans.classList.remove("active");
+  } else {
+    paneRules.style.display = "none";
+    paneOrphans.style.display = "";
+    tabRules.classList.remove("active");
+    tabOrphans.classList.add("active");
+    renderOrphans();
+  }
+}
+
+function wireFilters() {
+  const proc = document.getElementById("rules-filter-proceeding") as HTMLSelectElement;
+  const trig = document.getElementById("rules-filter-trigger") as HTMLSelectElement;
+  const search = document.getElementById("rules-filter-search") as HTMLInputElement;
+  proc.addEventListener("change", async () => {
+    activeProceeding = proc.value;
+    await loadRules();
+    renderRulesTable();
+  });
+  trig.addEventListener("change", async () => {
+    activeTrigger = trig.value;
+    await loadRules();
+    renderRulesTable();
+  });
+  search.addEventListener("input", () => {
+    window.clearTimeout(searchDebounce);
+    searchDebounce = window.setTimeout(async () => {
+      activeQuery = search.value.trim();
+      await loadRules();
+      renderRulesTable();
+    }, 220);
+  });
+  document.querySelectorAll<HTMLButtonElement>("#rules-filter-lifecycle .admin-rules-chip").forEach((chip) => {
+    chip.addEventListener("click", async () => {
+      document.querySelectorAll(".admin-rules-chip").forEach((c) => c.classList.remove("active"));
+      chip.classList.add("active");
+      activeLifecycle = chip.dataset.state || "";
+      await loadRules();
+      renderRulesTable();
+    });
+  });
+}
+
+function wireTabs() {
+  (document.getElementById("rules-tab-rules") as HTMLElement).addEventListener("click", () => setActiveTab("rules"));
+  (document.getElementById("rules-tab-orphans") as HTMLElement).addEventListener("click", () => setActiveTab("orphans"));
+}
+
+function wireModal() {
+  (document.getElementById("rules-new-btn") as HTMLElement).addEventListener("click", () => openReasonModal({ kind: "new-rule" }));
+  (document.getElementById("rules-reason-cancel") as HTMLElement).addEventListener("click", closeReasonModal);
+  (document.getElementById("rules-reason-close") as HTMLElement).addEventListener("click", closeReasonModal);
+  (document.getElementById("rules-reason-form") as HTMLFormElement).addEventListener("submit", submitReasonModal);
+}
+
+async function init() {
+  initI18n();
+  initSidebar();
+  wireFilters();
+  wireTabs();
+  wireModal();
+  await Promise.all([loadProceedings(), loadTriggerEvents()]);
+  await Promise.all([loadRules(), loadOrphans()]);
+  renderRulesTable();
+  // Re-render proceeding labels when language changes
+  onLangChange(() => {
+    renderRulesTable();
+    renderOrphans();
+  });
+}
+
+document.addEventListener("DOMContentLoaded", init);

frontend/src/client/admin-team.ts

@@ -468,11 +468,125 @@ function initInviteButton() {
   });
 }
 
+// t-paliad-223 Slice B (#49) — "Konto direkt anlegen" modal. Creates both
+// the auth.users row (via Supabase Admin API) and the paliad.users row in
+// one POST. New user appears in dropdowns immediately. Welcome email with
+// magic-link is sent by default; admin can opt out via the checkbox.
+function openAddFullModal() {
+  const modal = document.getElementById("admin-add-full-modal")!;
+  const fb = document.getElementById("admin-af-feedback")!;
+  const officeSel = document.getElementById("admin-af-office") as HTMLSelectElement;
+  const emailField = document.getElementById("admin-af-email") as HTMLInputElement;
+  const nameField = document.getElementById("admin-af-name") as HTMLInputElement;
+  const jobTitleField = document.getElementById("admin-af-job-title") as HTMLInputElement;
+  const profSel = document.getElementById("admin-af-profession") as HTMLSelectElement;
+  const langSel = document.getElementById("admin-af-lang") as HTMLSelectElement;
+  const sendWelcome = document.getElementById("admin-af-send-welcome") as HTMLInputElement;
+
+  fb.style.display = "none";
+  emailField.value = "";
+  nameField.value = "";
+  jobTitleField.value = "";
+  profSel.value = "associate";
+  langSel.value = "de";
+  sendWelcome.checked = true;
+  officeSel.innerHTML = officeOptions("munich");
+
+  modal.style.display = "flex";
+  emailField.focus();
+}
+
+function closeAddFullModal() {
+  document.getElementById("admin-add-full-modal")!.style.display = "none";
+}
+
+function initAddFullModal() {
+  document.getElementById("admin-team-add-full")!.addEventListener("click", openAddFullModal);
+  document.getElementById("admin-af-close")!.addEventListener("click", closeAddFullModal);
+  document.getElementById("admin-af-cancel")!.addEventListener("click", closeAddFullModal);
+  document.getElementById("admin-add-full-modal")!.addEventListener("click", (e) => {
+    if (e.target === e.currentTarget) closeAddFullModal();
+  });
+
+  const emailField = document.getElementById("admin-af-email") as HTMLInputElement;
+  const nameField = document.getElementById("admin-af-name") as HTMLInputElement;
+  // Pre-fill the display name from the email local-part the first time the
+  // admin tabs out of the email field — mirrors the existing onboard flow.
+  emailField.addEventListener("blur", () => {
+    if (nameField.value || !emailField.value) return;
+    const local = emailField.value.split("@")[0] ?? "";
+    nameField.value = local
+      .split(/[._-]/)
+      .map((s) => (s ? s[0].toUpperCase() + s.slice(1) : s))
+      .join(" ")
+      .trim();
+  });
+
+  const form = document.getElementById("admin-add-full-form") as HTMLFormElement;
+  form.addEventListener("submit", async (e) => {
+    e.preventDefault();
+    const fb = document.getElementById("admin-af-feedback")!;
+    fb.style.display = "none";
+
+    const officeSel = document.getElementById("admin-af-office") as HTMLSelectElement;
+    const jobTitleField = document.getElementById("admin-af-job-title") as HTMLInputElement;
+    const profSel = document.getElementById("admin-af-profession") as HTMLSelectElement;
+    const langSel = document.getElementById("admin-af-lang") as HTMLSelectElement;
+    const sendWelcome = document.getElementById("admin-af-send-welcome") as HTMLInputElement;
+    const submitBtn = document.getElementById("admin-af-submit") as HTMLButtonElement;
+
+    const payload: Record<string, unknown> = {
+      email: emailField.value.trim().toLowerCase(),
+      display_name: nameField.value.trim(),
+      office: officeSel.value,
+      job_title: jobTitleField.value.trim() || "Associate",
+      profession: profSel.value,
+      lang: langSel.value,
+      send_welcome_mail: sendWelcome.checked,
+    };
+
+    submitBtn.disabled = true;
+    try {
+      const resp = await fetch("/api/admin/users/full", {
+        method: "POST",
+        headers: { "Content-Type": "application/json" },
+        body: JSON.stringify(payload),
+      });
+      if (!resp.ok) {
+        const body = await resp.json().catch(() => ({ error: resp.statusText }));
+        // Map two friendly cases inline; everything else surfaces the
+        // server message so the admin can act on it.
+        if (resp.status === 503) {
+          fb.textContent = t("admin.team.add_full.error.unavailable")
+            || "Add-User-Pfad ist nicht konfiguriert (SUPABASE_SERVICE_ROLE_KEY fehlt am Server).";
+        } else if (resp.status === 409) {
+          fb.textContent = body.error
+            || (t("admin.team.add_full.error.email_exists")
+              || "Es existiert bereits ein Konto für diese E-Mail — bitte 'Bestehendes Konto onboarden' verwenden.");
+        } else {
+          fb.textContent = body.error || (t("admin.team.add_full.error.generic") || "Fehler.");
+        }
+        fb.className = "form-msg form-msg-error";
+        fb.style.display = "block";
+        return;
+      }
+      const created = (await resp.json()) as User;
+      users = users.concat(created);
+      closeAddFullModal();
+      showFeedback(t("admin.team.add_full.feedback.added") || "Konto angelegt.", false);
+      render();
+    } finally {
+      submitBtn.disabled = false;
+    }
+  });
+}
+
 document.addEventListener("DOMContentLoaded", () => {
   initI18n();
   initSidebar();
   initSearch();
   initDirectAddModal();
+  initAddFullModal();
   initInviteButton();
   onLangChange(() => {
     buildOfficeFilters();

frontend/src/client/appointments-calendar.ts

@@ -1,193 +0,0 @@
-import { initI18n, onLangChange, t, tDyn, getLang } from "./i18n";
-import { initSidebar } from "./sidebar";
-
-interface Appointment {
-  id: string;
-  project_id?: string;
-  title: string;
-  start_at: string;
-  end_at?: string;
-  appointment_type?: string;
-  project_reference?: string;
-  project_title?: string;
-}
-
-let allAppointments: Appointment[] = [];
-let viewYear = 0;
-let viewMonth = 0;
-
-function esc(s: string): string {
-  const d = document.createElement("div");
-  d.textContent = s;
-  return d.innerHTML;
-}
-
-function fmtMonth(year: number, month: number): string {
-  return `${tDyn(`cal.month.${month}`)} ${year}`;
-}
-
-function isoDate(year: number, month: number, day: number): string {
-  const m = String(month + 1).padStart(2, "0");
-  const d = String(day).padStart(2, "0");
-  return `${year}-${m}-${d}`;
-}
-
-async function loadAppointments() {
-  // Pull a wide window (current month plus a little buffer either side).
-  // We could narrow this, but the user typically navigates ±1-2 months
-  // and the dataset is small.
-  try {
-    const resp = await fetch("/api/appointments");
-    if (resp.ok) allAppointments = await resp.json();
-  } catch {
-    /* non-fatal */
-  }
-}
-
-function appointmentsForDate(iso: string): Appointment[] {
-  return allAppointments.filter((t) => t.start_at.slice(0, 10) === iso);
-}
-
-function typeClass(t?: string): string {
-  return t ? `termin-type-${t}` : "termin-type-default";
-}
-
-function fmtTime(iso: string): string {
-  try {
-    const d = new Date(iso);
-    return d.toLocaleTimeString(getLang() === "de" ? "de-DE" : "en-GB", {
-      hour: "2-digit",
-      minute: "2-digit",
-    });
-  } catch {
-    return iso;
-  }
-}
-
-function render() {
-  document.getElementById("cal-month-label")!.textContent = fmtMonth(viewYear, viewMonth);
-
-  const firstDay = new Date(viewYear, viewMonth, 1);
-  const jsWeekday = firstDay.getDay();
-  const offset = (jsWeekday + 6) % 7;
-  const daysInMonth = new Date(viewYear, viewMonth + 1, 0).getDate();
-  const today = new Date();
-  const todayISO = isoDate(today.getFullYear(), today.getMonth(), today.getDate());
-
-  const cells: string[] = [];
-  for (let i = 0; i < offset; i++) {
-    cells.push(`<div class="frist-cal-cell frist-cal-cell-empty"></div>`);
-  }
-  for (let day = 1; day <= daysInMonth; day++) {
-    const iso = isoDate(viewYear, viewMonth, day);
-    const items = appointmentsForDate(iso);
-    const isToday = iso === todayISO;
-
-    const dots = items
-      .slice(0, 4)
-      .map((tt) => `<span class="termin-dot ${typeClass(tt.appointment_type)}" title="${esc(tt.title)}"></span>`)
-      .join("");
-    const more = items.length > 4 ? `<span class="frist-cal-more">+${items.length - 4}</span>` : "";
-
-    cells.push(
-      `<div class="frist-cal-cell${isToday ? " frist-cal-today" : ""}${items.length > 0 ? " frist-cal-cell-has" : ""}" data-iso="${iso}">
-        <span class="frist-cal-day">${day}</span>
-        <div class="frist-cal-dots">${dots}${more}</div>
-      </div>`,
-    );
-  }
-
-  const grid = document.getElementById("appointment-cal-grid")!;
-  grid.innerHTML = cells.join("");
-
-  grid.querySelectorAll<HTMLElement>(".frist-cal-cell-has").forEach((cell) => {
-    cell.addEventListener("click", () => openPopup(cell.dataset.iso!));
-  });
-
-  const monthStart = isoDate(viewYear, viewMonth, 1);
-  const monthEnd = isoDate(viewYear, viewMonth, daysInMonth);
-  const hasInMonth = allAppointments.some((tt) => {
-    const iso = tt.start_at.slice(0, 10);
-    return iso >= monthStart && iso <= monthEnd;
-  });
-  const empty = document.getElementById("appointment-cal-empty")!;
-  empty.style.display = hasInMonth ? "none" : "";
-}
-
-function openPopup(iso: string) {
-  const items = appointmentsForDate(iso);
-  if (items.length === 0) return;
-  const popup = document.getElementById("cal-popup")!;
-  const dateEl = document.getElementById("cal-popup-date")!;
-  const list = document.getElementById("cal-popup-list")!;
-
-  const d = new Date(iso + "T00:00:00");
-  dateEl.textContent = d.toLocaleDateString(getLang() === "de" ? "de-DE" : "en-GB", {
-    weekday: "long",
-    year: "numeric",
-    month: "long",
-    day: "numeric",
-  });
-
-  list.innerHTML = items
-    .map((tt) => {
-      const akteRef = tt.project_id
-        ? `<a href="/projects/${esc(tt.project_id)}" class="frist-cal-popup-project">${esc(tt.project_reference ?? "")}</a>`
-        : `<span class="termin-personal-tag">${esc(t("appointments.personal"))}</span>`;
-      return `<li class="frist-cal-popup-item">
-        <span class="termin-dot ${typeClass(tt.appointment_type)}"></span>
-        <span class="frist-cal-popup-time">${esc(fmtTime(tt.start_at))}</span>
-        <a href="/appointments/${esc(tt.id)}" class="frist-cal-popup-title">${esc(tt.title)}</a>
-        ${akteRef}
-      </li>`;
-    })
-    .join("");
-  popup.style.display = "flex";
-}
-
-function initPopup() {
-  const popup = document.getElementById("cal-popup")!;
-  const close = document.getElementById("cal-popup-close")!;
-  close.addEventListener("click", () => (popup.style.display = "none"));
-  popup.addEventListener("click", (e) => {
-    if (e.target === e.currentTarget) popup.style.display = "none";
-  });
-}
-
-function initNav() {
-  document.getElementById("cal-prev")!.addEventListener("click", () => {
-    viewMonth -= 1;
-    if (viewMonth < 0) {
-      viewMonth = 11;
-      viewYear -= 1;
-    }
-    render();
-  });
-  document.getElementById("cal-next")!.addEventListener("click", () => {
-    viewMonth += 1;
-    if (viewMonth > 11) {
-      viewMonth = 0;
-      viewYear += 1;
-    }
-    render();
-  });
-  document.getElementById("cal-today")!.addEventListener("click", () => {
-    const now = new Date();
-    viewYear = now.getFullYear();
-    viewMonth = now.getMonth();
-    render();
-  });
-}
-
-document.addEventListener("DOMContentLoaded", async () => {
-  initI18n();
-  initSidebar();
-  const now = new Date();
-  viewYear = now.getFullYear();
-  viewMonth = now.getMonth();
-  initNav();
-  initPopup();
-  onLangChange(render);
-  await loadAppointments();
-  render();
-});

frontend/src/client/appointments-detail.ts

@@ -2,6 +2,7 @@ import { initI18n, t, tDyn, getLang } from "./i18n";
 import { initSidebar } from "./sidebar";
 import { initNotes } from "./notes";
 import { projectIndent } from "./project-indent";
+import { openWithdrawWarningModal } from "./components/withdraw-warning-modal";
 
 interface Appointment {
   id: string;
@@ -25,6 +26,9 @@ interface PendingApprovalRequest {
   requested_at: string;
   required_role: string;
   requester_name?: string;
+  // t-paliad-252 — used by the withdraw warning modal to pick the right
+  // copy (CREATE warns about deletion; UPDATE/COMPLETE about revert).
+  lifecycle_event?: string;
 }
 
 interface Me {
@@ -43,6 +47,10 @@ let project: Project | null = null;
 let allProjects: Project[] = [];
 let pendingRequest: PendingApprovalRequest | null = null;
 let me: Me | null = null;
+// t-paliad-252 — see deadlines-detail.ts. Routes Save to the new
+// /api/approval-requests/{id}/edit-entity endpoint when the user picked
+// "Termin bearbeiten" in the withdraw warning modal.
+let pendingEditMode = false;
 
 function parseAppointmentID(): string | null {
   const parts = window.location.pathname.split("/").filter(Boolean);
@@ -207,10 +215,14 @@ function renderHeader() {
   }
 
   // Freeze the edit form + delete button while a request is in flight.
+  // t-paliad-252 — when the user picked "Termin bearbeiten" in the
+  // withdraw modal, pendingEditMode unfreezes the form so Save can route
+  // to /edit-entity (which keeps the request pending + merges payload).
   const form = document.getElementById("appointment-edit-form") as HTMLFormElement | null;
   if (form) {
+    const freeze = isPending && !pendingEditMode;
     form.querySelectorAll<HTMLInputElement | HTMLSelectElement | HTMLTextAreaElement | HTMLButtonElement>("input, select, textarea, button[type=submit]")
-      .forEach((el) => { el.disabled = isPending; });
+      .forEach((el) => { el.disabled = freeze; });
   }
   const deleteBtn = document.getElementById("appointment-delete-btn") as HTMLButtonElement | null;
   if (deleteBtn) deleteBtn.disabled = isPending;
@@ -263,6 +275,39 @@ async function saveEdit(ev: Event) {
 
   submitBtn.disabled = true;
   try {
+    // t-paliad-252 — pending-edit mode routes through /edit-entity which
+    // keeps the request pending + merges fields into payload. clear_project
+    // and project_id are NOT in the counter-allowlist (yet) — the requester
+    // can't move projects on a pending request from this surface.
+    if (pendingEditMode && pendingRequest) {
+      const editFields = { ...payload };
+      delete editFields.clear_project;
+      const resp = await fetch(
+        `/api/approval-requests/${pendingRequest.id}/edit-entity`,
+        {
+          method: "POST",
+          headers: { "Content-Type": "application/json" },
+          body: JSON.stringify({ fields: editFields }),
+        },
+      );
+      if (resp.ok) {
+        const fresh = await fetch(`/api/appointments/${appointment.id}`);
+        if (fresh.ok) appointment = await fresh.json();
+        await loadPendingRequest();
+        // Exit pending-edit mode so the form re-freezes (still pending).
+        pendingEditMode = false;
+        renderHeader();
+        fillEditForm();
+        msg.textContent = t("appointments.detail.saved");
+        msg.className = "form-msg form-msg-ok";
+      } else {
+        const data = await resp.json().catch(() => ({}) as { error?: string; message?: string });
+        msg.textContent = data.message || data.error || t("appointments.error.generic");
+        msg.className = "form-msg form-msg-error";
+      }
+      return;
+    }
+
     const resp = await fetch(`/api/appointments/${appointment.id}`, {
       method: "PATCH",
       headers: { "Content-Type": "application/json" },
@@ -312,12 +357,37 @@ async function deleteAppointment() {
   }
 }
 
+// t-paliad-252 — withdraw warning modal replaces the old confirm().
+// Returns:
+//   "edit"     → unfreeze the edit form (pending-edit mode); Save will
+//                route through /api/approval-requests/{id}/edit-entity
+//   "withdraw" → destructive: the existing /revoke endpoint
+//   null       → user cancelled
 async function withdrawAppointmentRequest() {
   if (!appointment || !pendingRequest) return;
-  if (!confirm(t("approvals.withdraw.confirm") || "Anfrage wirklich zurückziehen?")) return;
   const btn = document.getElementById("appointment-withdraw-btn") as HTMLButtonElement | null;
   if (btn) btn.disabled = true;
   try {
+    const action = await openWithdrawWarningModal({
+      entityType: "appointment",
+      lifecycleEvent: pendingRequest.lifecycle_event ?? "create",
+    });
+    if (action === null) {
+      if (btn) btn.disabled = false;
+      return;
+    }
+    if (action === "edit") {
+      pendingEditMode = true;
+      if (btn) btn.disabled = false;
+      // renderHeader re-evaluates the freeze and unfreezes the form now
+      // that pendingEditMode is set. Focus the first editable field so the
+      // user can type immediately.
+      renderHeader();
+      const titleEl = document.getElementById("appointment-title-edit") as HTMLInputElement | null;
+      titleEl?.focus();
+      return;
+    }
+    // action === "withdraw" → destructive path.
     const resp = await fetch(`/api/approval-requests/${pendingRequest.id}/revoke`, {
       method: "POST",
       headers: { "Content-Type": "application/json" },
@@ -328,9 +398,12 @@ async function withdrawAppointmentRequest() {
       if (fresh.ok) {
         appointment = await fresh.json();
         await loadPendingRequest();
+        renderHeader();
+        fillEditForm();
+      } else {
+        // CREATE lifecycle: entity gone → back to the list.
+        window.location.href = "/events?type=appointment";
       }
-      renderHeader();
-      fillEditForm();
     } else {
       const data = await resp.json().catch(() => ({}) as { message?: string; error?: string });
       const msg = document.getElementById("appointment-edit-msg")!;

frontend/src/client/broadcast.ts

@@ -1,16 +1,23 @@
-// broadcast.ts — bulk team-email compose modal (t-paliad-147 / issue #7).
+// broadcast.ts — bulk team-email compose modal (t-paliad-147 / issue #7,
+// retrofitted onto the unified modal primitive in t-paliad-217 Slice D).
 //
 // Exposes openBroadcastModal({ recipients, projectIDs }) which the /team
 // page calls when the "E-Mail an Auswahl" button is clicked. The modal
 // collects subject + body + (optional) template and posts to
 // /api/team/broadcast. On success it shows a per-recipient send report
-// and closes.
+// and closes after a short delay.
 //
 // Per-recipient privacy: each member receives their own envelope. The
 // modal lists every addressee so the sender knows exactly who will be
 // mailed; there is no surprise to-line.
+//
+// Migration notes (t-paliad-217 Slice D): the shell, ESC, backdrop,
+// close button, and browser back-button are now owned by openModal().
+// The body is built imperatively so the submit handler can read form
+// state from the modal-body element it constructed.
 
 import { t } from "./i18n";
+import { openModal } from "./components/modal";
 
 export interface BroadcastRecipient {
   user_id: string;
@@ -35,6 +42,12 @@ interface EmailTemplateOption {
   is_default: boolean;
 }
 
+interface BroadcastResult {
+  sent: number;
+  failed: number;
+  total: number;
+}
+
 const RECIPIENT_CAP = 100;
 
 function esc(s: string): string {
@@ -78,69 +91,32 @@ export function openBroadcastModal(args: OpenBroadcastModalArgs): void {
     return;
   }
 
-  // Existing modal? Remove. Avoids stacking on rapid double-click.
-  document.getElementById("broadcast-modal")?.remove();
+  const body = renderBody(args);
+  wireBody(body);
 
-  const overlay = document.createElement("div");
-  overlay.id = "broadcast-modal";
-  overlay.className = "modal-overlay";
-  overlay.innerHTML = renderShell(args);
-  document.body.appendChild(overlay);
-
-  // Close handlers
-  overlay.querySelector("[data-broadcast-close]")?.addEventListener("click", () => overlay.remove());
-  overlay.addEventListener("click", (e) => {
-    if (e.target === overlay) overlay.remove();
-  });
-  document.addEventListener("keydown", function escClose(e) {
-    if (e.key === "Escape") {
-      overlay.remove();
-      document.removeEventListener("keydown", escClose);
-    }
-  });
-
-  // Recipient toggle
-  overlay.querySelector("[data-broadcast-toggle-recipients]")?.addEventListener("click", () => {
-    const list = overlay.querySelector<HTMLDivElement>("[data-broadcast-recipient-list]");
-    if (!list) return;
-    list.classList.toggle("hidden");
-  });
-
-  // Template dropdown
-  const templateSelect = overlay.querySelector<HTMLSelectElement>("[data-broadcast-template]");
-  templateSelect?.addEventListener("change", async () => {
-    const key = templateSelect.value;
-    if (!key) return;
-    const lang = (document.documentElement.lang || "de") as "de" | "en";
-    try {
-      const res = await fetch(`/api/admin/email-templates/${encodeURIComponent(key)}/${lang}`);
-      if (!res.ok) return;
-      const tpl = (await res.json()) as EmailTemplateOption;
-      const subjectInput = overlay.querySelector<HTMLInputElement>("[data-broadcast-subject]");
-      const bodyInput = overlay.querySelector<HTMLTextAreaElement>("[data-broadcast-body]");
-      if (subjectInput) subjectInput.value = stripGoTemplate(tpl.subject);
-      if (bodyInput) bodyInput.value = stripGoTemplate(tpl.body);
-    } catch {
-      /* template load failure is non-fatal — sender keeps freeform mode. */
-    }
-  });
-
-  // Submit
-  const form = overlay.querySelector<HTMLFormElement>("[data-broadcast-form]");
-  form?.addEventListener("submit", async (e) => {
-    e.preventDefault();
-    await onSubmit(form, overlay, args);
+  void openModal<BroadcastResult>({
+    title: t("team.broadcast.title") || "E-Mail an Auswahl",
+    body,
+    size: "lg",
+    primary: {
+      label: `${t("team.broadcast.send") || "Senden"} (${args.recipients.length})`,
+      handler: async (close) => {
+        await onSubmit(body, args, close);
+      },
+    },
+    secondary: { label: t("common.cancel") || "Abbrechen" },
   });
 }
 
-function renderShell(args: OpenBroadcastModalArgs): string {
+function renderBody(args: OpenBroadcastModalArgs): HTMLElement {
+  const root = document.createElement("div");
+  root.className = "broadcast-body";
   const count = args.recipients.length;
   const previewItems = args.recipients
     .slice(0, 5)
     .map((r) => esc(r.display_name) + " &lt;" + esc(r.email) + "&gt;")
     .join(", ");
   const more = count > 5 ? ` +${count - 5}` : "";
-
   const fullList = args.recipients
     .map(
       (r) =>
@@ -150,65 +126,89 @@ function renderShell(args: OpenBroadcastModalArgs): string {
     )
     .join("");
 
-  return `
-    <div class="modal modal-broadcast" role="dialog" aria-modal="true" aria-labelledby="broadcast-title">
-      <header class="modal-header">
-        <h2 id="broadcast-title">${esc(t("team.broadcast.title") || "E-Mail an Auswahl")}</h2>
-        <button type="button" class="modal-close" data-broadcast-close aria-label="${esc(t("common.close") || "Schließen")}">&times;</button>
-      </header>
-      <form data-broadcast-form>
-        <div class="modal-body">
-          <div class="broadcast-recipient-summary">
-            <strong>${esc(t("team.broadcast.recipients") || "Empfänger")}: ${count}</strong>
-            <button type="button" class="link-button" data-broadcast-toggle-recipients>${esc(t("team.broadcast.show_all") || "Alle anzeigen")}</button>
-            <a class="link-button broadcast-mailto" href="${buildMailtoHref(args.recipients)}" data-broadcast-mailto title="${esc(t("team.broadcast.mailto.tooltip") || "Im lokalen Mail-Client öffnen")}">
-              ${esc(t("team.broadcast.mailto.label") || "Im Mail-Client öffnen")}
-            </a>
-            <div class="broadcast-recipient-preview">${previewItems}${more}</div>
-            <div class="broadcast-recipient-list hidden" data-broadcast-recipient-list>
-              <ul>${fullList}</ul>
-            </div>
-          </div>
-
-          <label for="broadcast-template-select">${esc(t("team.broadcast.template") || "Vorlage")} <span class="muted">(${esc(t("team.broadcast.template_optional") || "optional")})</span></label>
-          <select id="broadcast-template-select" data-broadcast-template>
-            <option value="">${esc(t("team.broadcast.template_freeform") || "Freitext")}</option>
-            <option value="invitation">${esc(t("team.broadcast.template.invitation") || "Einladung")}</option>
-            <option value="deadline_digest">${esc(t("team.broadcast.template.deadline_digest") || "Frist-Digest")}</option>
-          </select>
-
-          <label for="broadcast-subject">${esc(t("team.broadcast.subject") || "Betreff")}</label>
-          <input type="text" id="broadcast-subject" data-broadcast-subject required maxlength="200" />
-
-          <label for="broadcast-body">${esc(t("team.broadcast.body") || "Nachricht")}</label>
-          <textarea id="broadcast-body" data-broadcast-body required rows="12" placeholder="${esc(t("team.broadcast.body_placeholder") || "Hallo {{first_name}}, …")}"></textarea>
-
-          <p class="broadcast-hint muted">
-            ${esc(t("team.broadcast.placeholders_hint") || "Platzhalter: {{name}}, {{first_name}}, {{role_on_project}}")}
-          </p>
-          <p class="broadcast-hint muted">
-            ${esc(t("team.broadcast.markdown_hint") || "Markdown unterstützt: **fett**, *kursiv*, [Link](https://...), - Aufzählung.")}
-          </p>
-
-          <div class="broadcast-error hidden" data-broadcast-error></div>
-          <div class="broadcast-success hidden" data-broadcast-success></div>
-        </div>
-
-        <footer class="modal-footer">
-          <button type="button" class="btn btn-ghost" data-broadcast-close>${esc(t("common.cancel") || "Abbrechen")}</button>
-          <button type="submit" class="btn btn-primary" data-broadcast-submit>${esc(t("team.broadcast.send") || "Senden")} (${count})</button>
-        </footer>
-      </form>
+  root.innerHTML = `
+    <div class="broadcast-recipient-summary">
+      <strong>${esc(t("team.broadcast.recipients") || "Empfänger")}: ${count}</strong>
+      <button type="button" class="link-button" data-broadcast-toggle-recipients>${esc(t("team.broadcast.show_all") || "Alle anzeigen")}</button>
+      <a class="link-button broadcast-mailto" href="${buildMailtoHref(args.recipients)}" data-broadcast-mailto title="${esc(t("team.broadcast.mailto.tooltip") || "Im lokalen Mail-Client öffnen")}">
+        ${esc(t("team.broadcast.mailto.label") || "Im Mail-Client öffnen")}
+      </a>
+      <div class="broadcast-recipient-preview">${previewItems}${more}</div>
+      <div class="broadcast-recipient-list hidden" data-broadcast-recipient-list>
+        <ul>${fullList}</ul>
+      </div>
     </div>
+
+    <div class="form-field">
+      <label for="broadcast-template-select">${esc(t("team.broadcast.template") || "Vorlage")} <span class="muted">(${esc(t("team.broadcast.template_optional") || "optional")})</span></label>
+      <select id="broadcast-template-select" data-broadcast-template>
+        <option value="">${esc(t("team.broadcast.template_freeform") || "Freitext")}</option>
+        <option value="invitation">${esc(t("team.broadcast.template.invitation") || "Einladung")}</option>
+        <option value="deadline_digest">${esc(t("team.broadcast.template.deadline_digest") || "Frist-Digest")}</option>
+      </select>
+    </div>
+
+    <div class="form-field">
+      <label for="broadcast-subject">${esc(t("team.broadcast.subject") || "Betreff")}</label>
+      <input type="text" id="broadcast-subject" data-broadcast-subject required maxlength="200" />
+    </div>
+
+    <div class="form-field">
+      <label for="broadcast-body">${esc(t("team.broadcast.body") || "Nachricht")}</label>
+      <textarea id="broadcast-body" data-broadcast-body required rows="12" placeholder="${esc(t("team.broadcast.body_placeholder") || "Hallo {{first_name}}, …")}"></textarea>
+    </div>
+
+    <p class="broadcast-hint muted">
+      ${esc(t("team.broadcast.placeholders_hint") || "Platzhalter: {{name}}, {{first_name}}, {{role_on_project}}")}
+    </p>
+    <p class="broadcast-hint muted">
+      ${esc(t("team.broadcast.markdown_hint") || "Markdown unterstützt: **fett**, *kursiv*, [Link](https://...), - Aufzählung.")}
+    </p>
+
+    <div class="broadcast-error hidden" data-broadcast-error></div>
+    <div class="broadcast-success hidden" data-broadcast-success></div>
   `;
+  return root;
 }
 
-async function onSubmit(form: HTMLFormElement, overlay: HTMLElement, args: OpenBroadcastModalArgs): Promise<void> {
-  const subject = (form.querySelector<HTMLInputElement>("[data-broadcast-subject]")?.value ?? "").trim();
-  const body = (form.querySelector<HTMLTextAreaElement>("[data-broadcast-body]")?.value ?? "").trim();
-  const templateKey = form.querySelector<HTMLSelectElement>("[data-broadcast-template]")?.value ?? "";
-  const errEl = overlay.querySelector<HTMLDivElement>("[data-broadcast-error]");
-  const okEl = overlay.querySelector<HTMLDivElement>("[data-broadcast-success]");
+function wireBody(body: HTMLElement): void {
+  // Recipient list toggle.
+  body.querySelector("[data-broadcast-toggle-recipients]")?.addEventListener("click", () => {
+    const list = body.querySelector<HTMLDivElement>("[data-broadcast-recipient-list]");
+    if (!list) return;
+    list.classList.toggle("hidden");
+  });
+
+  // Template dropdown — populates subject/body from the selected template.
+  const templateSelect = body.querySelector<HTMLSelectElement>("[data-broadcast-template]");
+  templateSelect?.addEventListener("change", async () => {
+    const key = templateSelect.value;
+    if (!key) return;
+    const lang = (document.documentElement.lang || "de") as "de" | "en";
+    try {
+      const res = await fetch(`/api/admin/email-templates/${encodeURIComponent(key)}/${lang}`);
+      if (!res.ok) return;
+      const tpl = (await res.json()) as EmailTemplateOption;
+      const subjectInput = body.querySelector<HTMLInputElement>("[data-broadcast-subject]");
+      const bodyInput = body.querySelector<HTMLTextAreaElement>("[data-broadcast-body]");
+      if (subjectInput) subjectInput.value = stripGoTemplate(tpl.subject);
+      if (bodyInput) bodyInput.value = stripGoTemplate(tpl.body);
+    } catch {
+      /* template load failure is non-fatal — sender keeps freeform mode. */
+    }
+  });
+}
+
+async function onSubmit(
+  body: HTMLElement,
+  args: OpenBroadcastModalArgs,
+  close: (result: BroadcastResult) => void,
+): Promise<void> {
+  const subject = (body.querySelector<HTMLInputElement>("[data-broadcast-subject]")?.value ?? "").trim();
+  const bodyText = (body.querySelector<HTMLTextAreaElement>("[data-broadcast-body]")?.value ?? "").trim();
+  const templateKey = body.querySelector<HTMLSelectElement>("[data-broadcast-template]")?.value ?? "";
+  const errEl = body.querySelector<HTMLDivElement>("[data-broadcast-error]");
+  const okEl = body.querySelector<HTMLDivElement>("[data-broadcast-success]");
   errEl?.classList.add("hidden");
   okEl?.classList.add("hidden");
 
@@ -216,17 +216,15 @@ async function onSubmit(form: HTMLFormElement, overlay: HTMLElement, args: OpenB
     showError(errEl, t("team.broadcast.error.subject_required") || "Betreff ist erforderlich.");
     return;
   }
-  if (!body) {
+  if (!bodyText) {
     showError(errEl, t("team.broadcast.error.body_required") || "Nachricht ist erforderlich.");
     return;
   }
 
-  const submitBtn = form.querySelector<HTMLButtonElement>("[data-broadcast-submit]");
-  if (submitBtn) {
-    submitBtn.disabled = true;
-    submitBtn.textContent = t("team.broadcast.sending") || "Sende…";
-  }
-
+  // The modal primary button lives in the footer (owned by openModal),
+  // not in the body. We surface "sending..." feedback via the in-body
+  // success/error areas; the primary button stays clickable but the
+  // server-side idempotency + RECIPIENT_CAP make double-clicks safe.
   const recipientFilter: Record<string, unknown> = {};
   if (args.projectIDs?.length) recipientFilter.project_ids = args.projectIDs;
   if (args.projectID) recipientFilter.project_id = args.projectID;
@@ -242,7 +240,7 @@ async function onSubmit(form: HTMLFormElement, overlay: HTMLElement, args: OpenB
       body: JSON.stringify({
         project_id: args.projectID ?? null,
         subject,
-        body,
+        body: bodyText,
         template_key: templateKey || undefined,
         lang,
         recipient_filter: recipientFilter,
@@ -252,13 +250,9 @@ async function onSubmit(form: HTMLFormElement, overlay: HTMLElement, args: OpenB
     if (!res.ok) {
       const errBody = await res.json().catch(() => ({ error: "Send failed" }));
       showError(errEl, (errBody as { error?: string }).error || "Send failed");
-      if (submitBtn) {
-        submitBtn.disabled = false;
-        submitBtn.textContent = (t("team.broadcast.send") || "Senden") + ` (${args.recipients.length})`;
-      }
       return;
     }
-    const report = (await res.json()) as { sent: number; failed: number; total: number };
+    const report = (await res.json()) as BroadcastResult;
     if (okEl) {
       okEl.classList.remove("hidden");
       const tpl = t("team.broadcast.success") || "{sent} von {total} Mails versandt ({failed} fehlgeschlagen).";
@@ -267,17 +261,10 @@ async function onSubmit(form: HTMLFormElement, overlay: HTMLElement, args: OpenB
         .replace("{total}", String(report.total))
         .replace("{failed}", String(report.failed));
     }
-    if (submitBtn) {
-      submitBtn.disabled = true;
-      submitBtn.textContent = t("team.broadcast.sent") || "Versandt";
-    }
-    setTimeout(() => overlay.remove(), 2500);
+    // Give the sender a moment to see the report, then close.
+    setTimeout(() => close(report), 2500);
   } catch (e) {
     showError(errEl, String(e));
-    if (submitBtn) {
-      submitBtn.disabled = false;
-      submitBtn.textContent = (t("team.broadcast.send") || "Senden") + ` (${args.recipients.length})`;
-    }
   }
 }
 

frontend/src/client/calendar/mount-calendar.test.ts

@@ -0,0 +1,135 @@
+import { describe, expect, test } from "bun:test";
+import {
+  bucketByDate,
+  filterByDay,
+  isToday,
+  isoDate,
+  shift,
+  startOfDay,
+  startOfWeek,
+  type CalendarItem,
+} from "./mount-calendar";
+
+// Regression tests for t-paliad-224: the calendar bucket / week / shift
+// helpers underpin both /events Kalender and the Custom Views shape=
+// calendar. DOM-rendering is covered by manual smoke (frontend tests in
+// this repo run in plain Node, no jsdom — see verfahrensablauf-core.test
+// ts comment), so the pure date-math goes here.
+
+const item = (overrides: Partial<CalendarItem> = {}): CalendarItem => ({
+  kind: "deadline",
+  id: "00000000-0000-0000-0000-000000000000",
+  title: "Klageerwiderung",
+  event_date: "2026-05-08T00:00:00Z",
+  ...overrides,
+});
+
+describe("isoDate / startOfDay / startOfWeek", () => {
+  test("isoDate pads month + day", () => {
+    expect(isoDate(new Date(2026, 0, 3))).toBe("2026-01-03");
+    expect(isoDate(new Date(2026, 11, 31))).toBe("2026-12-31");
+  });
+
+  test("startOfDay strips time", () => {
+    const d = new Date(2026, 4, 8, 13, 47, 22);
+    const out = startOfDay(d);
+    expect(out.getHours()).toBe(0);
+    expect(out.getMinutes()).toBe(0);
+    expect(out.getSeconds()).toBe(0);
+    expect(isoDate(out)).toBe("2026-05-08");
+  });
+
+  test("startOfWeek snaps to Monday (Mon=0)", () => {
+    // 2026-05-08 was a Friday.
+    const fri = new Date(2026, 4, 8);
+    expect(isoDate(startOfWeek(fri))).toBe("2026-05-04");
+    // Sunday wraps backward to the same Monday, not forward to the next.
+    const sun = new Date(2026, 4, 10);
+    expect(isoDate(startOfWeek(sun))).toBe("2026-05-04");
+    // Monday is its own startOfWeek.
+    const mon = new Date(2026, 4, 4);
+    expect(isoDate(startOfWeek(mon))).toBe("2026-05-04");
+  });
+});
+
+describe("shift", () => {
+  test("month shift lands on day=1 of the target month", () => {
+    const out = shift(new Date(2026, 4, 15), "month", 1);
+    expect(out.getFullYear()).toBe(2026);
+    expect(out.getMonth()).toBe(5);
+    expect(out.getDate()).toBe(1);
+  });
+
+  test("month shift wraps year boundary", () => {
+    const out = shift(new Date(2026, 11, 15), "month", 1);
+    expect(out.getFullYear()).toBe(2027);
+    expect(out.getMonth()).toBe(0);
+    expect(out.getDate()).toBe(1);
+  });
+
+  test("week shift moves seven days", () => {
+    const out = shift(new Date(2026, 4, 8), "week", 1);
+    expect(isoDate(out)).toBe("2026-05-15");
+  });
+
+  test("day shift moves one day", () => {
+    const out = shift(new Date(2026, 4, 8), "day", -1);
+    expect(isoDate(out)).toBe("2026-05-07");
+  });
+});
+
+describe("bucketByDate", () => {
+  test("groups items by ISO date and skips items outside the filter", () => {
+    const rows = [
+      item({ id: "a", event_date: "2026-05-08T00:00:00Z" }),
+      item({ id: "b", event_date: "2026-05-08T15:30:00Z" }),
+      item({ id: "c", event_date: "2026-05-09T00:00:00Z" }),
+      // outside the May 2026 filter:
+      item({ id: "x", event_date: "2026-06-01T00:00:00Z" }),
+      // malformed:
+      item({ id: "bad", event_date: "not-a-date" }),
+    ];
+    const out = bucketByDate(rows, (d) => d.getMonth() === 4 && d.getFullYear() === 2026);
+    expect(out.size).toBe(2);
+    expect(out.get("2026-05-08")?.map((r) => r.id)).toEqual(["a", "b"]);
+    expect(out.get("2026-05-09")?.map((r) => r.id)).toEqual(["c"]);
+    expect(out.has("2026-06-01")).toBe(false);
+  });
+});
+
+describe("filterByDay", () => {
+  test("returns only items whose calendar day equals the target", () => {
+    const rows = [
+      item({ id: "a", event_date: "2026-05-08T00:00:00Z" }),
+      item({ id: "b", event_date: "2026-05-08T23:59:00Z" }),
+      item({ id: "c", event_date: "2026-05-09T00:00:00Z" }),
+    ];
+    expect(filterByDay(rows, new Date(2026, 4, 8)).map((r) => r.id)).toEqual(["a", "b"]);
+    expect(filterByDay(rows, new Date(2026, 4, 9)).map((r) => r.id)).toEqual(["c"]);
+    expect(filterByDay(rows, new Date(2026, 4, 10))).toEqual([]);
+  });
+
+  test("ignores malformed dates", () => {
+    const rows = [
+      item({ id: "ok", event_date: "2026-05-08T00:00:00Z" }),
+      item({ id: "bad", event_date: "not-a-date" }),
+    ];
+    expect(filterByDay(rows, new Date(2026, 4, 8)).map((r) => r.id)).toEqual(["ok"]);
+  });
+});
+
+describe("isToday", () => {
+  test("matches today's calendar day", () => {
+    expect(isToday(new Date())).toBe(true);
+  });
+
+  test("rejects yesterday + tomorrow", () => {
+    const now = new Date();
+    const yesterday = new Date(now);
+    yesterday.setDate(now.getDate() - 1);
+    const tomorrow = new Date(now);
+    tomorrow.setDate(now.getDate() + 1);
+    expect(isToday(yesterday)).toBe(false);
+    expect(isToday(tomorrow)).toBe(false);
+  });
+});

frontend/src/client/calendar/mount-calendar.ts

@@ -0,0 +1,579 @@
+import { t, tDyn, getLang, type I18nKey } from "../i18n";
+
+// mount-calendar.ts — the canonical month/week/day calendar (t-paliad-224).
+// Lifted from the original shape-calendar.ts so both Custom Views
+// (shape=calendar) and /events Kalender tab render through the same DOM.
+// See docs/design-calendar-view-align-2026-05-20.md for the audit + plan.
+//
+// Surfaces wire in via mountCalendar(host, items, opts). The returned
+// handle exposes update(items) for re-render after a filter change and
+// destroy() for teardown when the host swaps to a different view.
+
+export type CalendarKind =
+  | "deadline" | "appointment" | "project_event" | "approval_request";
+
+export interface CalendarItem {
+  kind: CalendarKind;
+  id: string;
+  title: string;
+  /** ISO-8601 timestamp or date string. First 10 chars are read as the
+   *  calendar bucket (yyyy-mm-dd). */
+  event_date: string;
+  project_id?: string;
+  project_title?: string;
+  project_reference?: string;
+}
+
+export type CalendarView = "month" | "week" | "day";
+
+export interface CalendarOpts {
+  /** Initial view if URL has no override (or urlState is disabled). */
+  defaultView?: CalendarView;
+  /** Read/write ?cal_view + ?cal_date so a refresh restores the calendar.
+   *  Surfaces that own their own URL contract pass urlState=false. */
+  urlState?: boolean;
+  /** Optional URL param prefix (e.g. "events" → ?eventsCalView=…). Only
+   *  meaningful when urlState=true. Leave empty for the default
+   *  ?cal_view / ?cal_date contract. */
+  urlPrefix?: string;
+  /** Override how a row's href is built. Default routes by kind. */
+  hrefFor?: (item: CalendarItem) => string;
+}
+
+export interface CalendarHandle {
+  /** Replace the item set and re-paint at the current view+anchor. */
+  update(items: CalendarItem[]): void;
+  /** Clear host + drop the keep-alive state. After destroy(), the handle
+   *  is dead; create a fresh one with mountCalendar(). */
+  destroy(): void;
+}
+
+const MAX_PILLS_PER_MONTH_CELL = 3;
+
+export function mountCalendar(
+  host: HTMLElement,
+  initialItems: CalendarItem[],
+  opts: CalendarOpts = {},
+): CalendarHandle {
+  let items = initialItems;
+  let view: CalendarView;
+  let anchor: Date;
+  let destroyed = false;
+
+  const urlEnabled = opts.urlState ?? false;
+  const viewParam = urlEnabled ? paramName(opts.urlPrefix, "cal_view") : "";
+  const dateParam = urlEnabled ? paramName(opts.urlPrefix, "cal_date") : "";
+
+  view = urlEnabled
+    ? readView(viewParam, opts.defaultView ?? "month")
+    : (opts.defaultView ?? "month");
+  anchor = urlEnabled ? readAnchor(dateParam, items) : firstAnchor(items);
+
+  paint();
+
+  return {
+    update(nextItems) {
+      if (destroyed) return;
+      items = nextItems;
+      paint();
+    },
+    destroy() {
+      destroyed = true;
+      host.innerHTML = "";
+    },
+  };
+
+  // --- paint -----------------------------------------------------------
+
+  function paint(): void {
+    if (destroyed) return;
+    host.innerHTML = "";
+
+    // Mobile fallback notice (<600px). Documented in design-calendar-
+    // view-align-2026-05-20.md §6. CSS still lays out the grid; the
+    // notice just nudges users toward a friendlier view.
+    if (typeof window !== "undefined" && window.innerWidth < 600) {
+      const notice = document.createElement("p");
+      notice.className = "views-calendar-mobile-notice";
+      notice.textContent = t("views.calendar.mobile_fallback");
+      host.appendChild(notice);
+    }
+
+    const wrap = document.createElement("div");
+    wrap.className = `views-calendar views-calendar--${view}`;
+    wrap.appendChild(renderToolbar());
+    if (view === "month") {
+      wrap.appendChild(renderMonth());
+    } else if (view === "week") {
+      wrap.appendChild(renderWeek());
+    } else {
+      wrap.appendChild(renderDay());
+    }
+    host.appendChild(wrap);
+  }
+
+  function setView(nextView: CalendarView, nextAnchor: Date): void {
+    view = nextView;
+    anchor = nextAnchor;
+    if (urlEnabled) writeURL(viewParam, dateParam, nextView, nextAnchor);
+    paint();
+  }
+
+  // --- Toolbar ---------------------------------------------------------
+
+  function renderToolbar(): HTMLElement {
+    const bar = document.createElement("div");
+    bar.className = "views-calendar-toolbar";
+
+    const switcher = document.createElement("div");
+    switcher.className = "views-calendar-view-switcher agenda-chip-row";
+    switcher.setAttribute("role", "tablist");
+    for (const v of ["month", "week", "day"] as CalendarView[]) {
+      const chip = document.createElement("button");
+      chip.type = "button";
+      chip.className = "agenda-chip views-calendar-view-chip" + (v === view ? " agenda-chip-active" : "");
+      chip.dataset.calView = v;
+      chip.setAttribute("role", "tab");
+      chip.setAttribute("aria-selected", v === view ? "true" : "false");
+      chip.textContent = t(`cal.view.${v}` as I18nKey);
+      chip.addEventListener("click", () => {
+        if (v === view) return;
+        setView(v, anchor);
+      });
+      switcher.appendChild(chip);
+    }
+    bar.appendChild(switcher);
+
+    const nav = document.createElement("div");
+    nav.className = "views-calendar-nav";
+
+    const prev = document.createElement("button");
+    prev.type = "button";
+    prev.className = "btn-secondary btn-small views-calendar-nav-btn";
+    prev.setAttribute("aria-label", t(navLabelKey(view, "prev")));
+    prev.textContent = "‹";
+    prev.addEventListener("click", () => setView(view, shift(anchor, view, -1)));
+    nav.appendChild(prev);
+
+    const label = document.createElement("span");
+    label.className = "views-calendar-nav-label";
+    label.textContent = formatRangeLabel(view, anchor);
+    nav.appendChild(label);
+
+    const next = document.createElement("button");
+    next.type = "button";
+    next.className = "btn-secondary btn-small views-calendar-nav-btn";
+    next.setAttribute("aria-label", t(navLabelKey(view, "next")));
+    next.textContent = "›";
+    next.addEventListener("click", () => setView(view, shift(anchor, view, 1)));
+    nav.appendChild(next);
+
+    // "Heute" button — jump back to today in the current view. Adds a
+    // recognisable affordance for the /events Kalender users who relied
+    // on the old toolbar's "Heute" button.
+    const today = document.createElement("button");
+    today.type = "button";
+    today.className = "btn-secondary btn-small views-calendar-nav-btn";
+    today.textContent = t("cal.today");
+    today.addEventListener("click", () => setView(view, startOfDay(new Date())));
+    nav.appendChild(today);
+
+    if (view !== "month") {
+      const backToMonth = document.createElement("button");
+      backToMonth.type = "button";
+      backToMonth.className = "btn-link views-calendar-back-to-month";
+      backToMonth.textContent = t("cal.day.back_to_month");
+      backToMonth.addEventListener("click", () => setView("month", anchor));
+      nav.appendChild(backToMonth);
+    }
+
+    bar.appendChild(nav);
+    return bar;
+  }
+
+  // --- Month -----------------------------------------------------------
+
+  function renderMonth(): HTMLElement {
+    const lang = getLang() === "de" ? "de-DE" : "en-GB";
+    const wrap = document.createElement("div");
+    wrap.className = "views-calendar-month";
+
+    const header = document.createElement("h2");
+    header.className = "views-calendar-month-label";
+    header.textContent = anchor.toLocaleDateString(lang, { month: "long", year: "numeric" });
+    wrap.appendChild(header);
+
+    const grid = document.createElement("div");
+    grid.className = "views-calendar-grid";
+
+    const weekdayKeys: I18nKey[] = [
+      "cal.day.mon", "cal.day.tue", "cal.day.wed", "cal.day.thu",
+      "cal.day.fri", "cal.day.sat", "cal.day.sun",
+    ];
+    for (const k of weekdayKeys) {
+      const cell = document.createElement("div");
+      cell.className = "views-calendar-weekday";
+      cell.textContent = t(k);
+      grid.appendChild(cell);
+    }
+
+    const monthStart = new Date(anchor.getFullYear(), anchor.getMonth(), 1);
+    const startWeekday = (monthStart.getDay() + 6) % 7; // Mon=0
+    const daysInMonth = new Date(anchor.getFullYear(), anchor.getMonth() + 1, 0).getDate();
+
+    for (let i = 0; i < startWeekday; i++) {
+      const cell = document.createElement("div");
+      cell.className = "views-calendar-cell views-calendar-cell--out";
+      grid.appendChild(cell);
+    }
+
+    const byDate = bucketByDate(items, (d) =>
+      d.getMonth() === anchor.getMonth() && d.getFullYear() === anchor.getFullYear(),
+    );
+
+    for (let day = 1; day <= daysInMonth; day++) {
+      const dayDate = new Date(anchor.getFullYear(), anchor.getMonth(), day);
+      const dateKey = isoDate(dayDate);
+      const dayRows = byDate.get(dateKey) ?? [];
+      grid.appendChild(renderMonthCell(dayDate, day, dayRows));
+    }
+
+    wrap.appendChild(grid);
+    return wrap;
+  }
+
+  function renderMonthCell(dayDate: Date, dayNum: number, dayRows: CalendarItem[]): HTMLElement {
+    const cell = document.createElement("div");
+    cell.className = "views-calendar-cell";
+    if (isToday(dayDate)) cell.classList.add("views-calendar-cell--today");
+    if (dayRows.length > 0) cell.classList.add("views-calendar-cell--has");
+
+    const dayLabel = document.createElement("button");
+    dayLabel.type = "button";
+    dayLabel.className = "views-calendar-cell-day";
+    dayLabel.textContent = String(dayNum);
+    dayLabel.setAttribute("aria-label", t("cal.day.open_day"));
+    dayLabel.addEventListener("click", (e) => {
+      e.stopPropagation();
+      setView("day", dayDate);
+    });
+    cell.appendChild(dayLabel);
+
+    if (dayRows.length > 0) {
+      const ul = document.createElement("ul");
+      ul.className = "views-calendar-pills";
+      const visible = dayRows.slice(0, MAX_PILLS_PER_MONTH_CELL);
+      for (const row of visible) ul.appendChild(renderPill(row));
+      if (dayRows.length > visible.length) {
+        const more = document.createElement("li");
+        const moreBtn = document.createElement("button");
+        moreBtn.type = "button";
+        moreBtn.className = "views-calendar-pill views-calendar-pill--more";
+        moreBtn.textContent = `+${dayRows.length - visible.length}`;
+        moreBtn.setAttribute("aria-label", t("cal.day.open_day"));
+        moreBtn.addEventListener("click", (e) => {
+          e.stopPropagation();
+          setView("day", dayDate);
+        });
+        more.appendChild(moreBtn);
+        ul.appendChild(more);
+      }
+      cell.appendChild(ul);
+    }
+    return cell;
+  }
+
+  // --- Week ------------------------------------------------------------
+
+  function renderWeek(): HTMLElement {
+    const lang = getLang() === "de" ? "de-DE" : "en-GB";
+    const wrap = document.createElement("div");
+    wrap.className = "views-calendar-week";
+
+    const weekStart = startOfWeek(anchor);
+    const weekEnd = new Date(weekStart);
+    weekEnd.setDate(weekStart.getDate() + 6);
+
+    const header = document.createElement("h2");
+    header.className = "views-calendar-month-label";
+    header.textContent = formatWeekHeader(weekStart, weekEnd, lang);
+    wrap.appendChild(header);
+
+    const grid = document.createElement("div");
+    grid.className = "views-calendar-week-grid";
+    for (let i = 0; i < 7; i++) {
+      const day = new Date(weekStart);
+      day.setDate(weekStart.getDate() + i);
+      grid.appendChild(renderWeekColumn(day));
+    }
+    wrap.appendChild(grid);
+    return wrap;
+  }
+
+  function renderWeekColumn(day: Date): HTMLElement {
+    const lang = getLang() === "de" ? "de-DE" : "en-GB";
+    const col = document.createElement("div");
+    col.className = "views-calendar-week-column";
+    if (isToday(day)) col.classList.add("views-calendar-week-column--today");
+
+    const head = document.createElement("div");
+    head.className = "views-calendar-week-head";
+    const weekdayKey = WEEKDAY_KEYS[(day.getDay() + 6) % 7];
+    const dow = document.createElement("span");
+    dow.className = "views-calendar-week-dow";
+    dow.textContent = t(weekdayKey);
+    const dnum = document.createElement("span");
+    dnum.className = "views-calendar-week-dnum";
+    dnum.textContent = day.toLocaleDateString(lang, { day: "numeric", month: "short" });
+    head.appendChild(dow);
+    head.appendChild(dnum);
+    col.appendChild(head);
+
+    const dayRows = filterByDay(items, day);
+    if (dayRows.length === 0) {
+      const empty = document.createElement("p");
+      empty.className = "views-calendar-week-empty";
+      empty.textContent = t("cal.day.no_entries");
+      col.appendChild(empty);
+      return col;
+    }
+
+    const ul = document.createElement("ul");
+    ul.className = "views-calendar-week-list";
+    for (const row of dayRows) {
+      const li = document.createElement("li");
+      li.appendChild(renderRowAnchor(row, "week"));
+      ul.appendChild(li);
+    }
+    col.appendChild(ul);
+    return col;
+  }
+
+  // --- Day -------------------------------------------------------------
+
+  function renderDay(): HTMLElement {
+    const lang = getLang() === "de" ? "de-DE" : "en-GB";
+    const wrap = document.createElement("div");
+    wrap.className = "views-calendar-day-wrap";
+
+    const header = document.createElement("h2");
+    header.className = "views-calendar-month-label";
+    header.textContent = anchor.toLocaleDateString(lang, {
+      weekday: "long", year: "numeric", month: "long", day: "numeric",
+    });
+    wrap.appendChild(header);
+
+    const dayRows = filterByDay(items, anchor);
+    if (dayRows.length === 0) {
+      const empty = document.createElement("p");
+      empty.className = "views-calendar-day-empty";
+      empty.textContent = t("cal.day.no_entries");
+      wrap.appendChild(empty);
+      return wrap;
+    }
+
+    const ul = document.createElement("ul");
+    ul.className = "views-calendar-day-list";
+    for (const row of dayRows) {
+      const li = document.createElement("li");
+      li.appendChild(renderRowAnchor(row, "day"));
+      ul.appendChild(li);
+    }
+    wrap.appendChild(ul);
+    return wrap;
+  }
+
+  // --- Row rendering ---------------------------------------------------
+
+  function renderPill(row: CalendarItem): HTMLElement {
+    const li = document.createElement("li");
+    const a = document.createElement("a");
+    a.className = `views-calendar-pill views-calendar-pill--${row.kind}`;
+    a.href = hrefFor(row);
+    a.textContent = row.title;
+    a.title = row.title + (row.project_title ? ` — ${row.project_title}` : "");
+    a.addEventListener("click", (e) => e.stopPropagation());
+    li.appendChild(a);
+    return li;
+  }
+
+  function renderRowAnchor(row: CalendarItem, density: "week" | "day"): HTMLElement {
+    const a = document.createElement("a");
+    a.className = `views-calendar-row views-calendar-row--${density} views-calendar-row--${row.kind}`;
+    a.href = hrefFor(row);
+
+    const dot = document.createElement("span");
+    dot.className = `views-calendar-row-dot views-calendar-row-dot--${row.kind}`;
+    a.appendChild(dot);
+
+    const body = document.createElement("span");
+    body.className = "views-calendar-row-body";
+
+    const title = document.createElement("span");
+    title.className = "views-calendar-row-title";
+    title.textContent = row.title;
+    body.appendChild(title);
+
+    const metaParts: string[] = [];
+    metaParts.push(tDyn("views.kind." + row.kind));
+    if (row.project_reference) metaParts.push(row.project_reference);
+    else if (row.project_title) metaParts.push(row.project_title);
+    if (metaParts.length > 0) {
+      const meta = document.createElement("span");
+      meta.className = "views-calendar-row-meta";
+      meta.textContent = metaParts.join(" · ");
+      body.appendChild(meta);
+    }
+
+    a.appendChild(body);
+    return a;
+  }
+
+  function hrefFor(row: CalendarItem): string {
+    if (opts.hrefFor) return opts.hrefFor(row);
+    return defaultHrefFor(row);
+  }
+}
+
+// --- Pure helpers (shared, not closure-bound) ----------------------------
+
+const WEEKDAY_KEYS: I18nKey[] = [
+  "cal.day.mon", "cal.day.tue", "cal.day.wed", "cal.day.thu",
+  "cal.day.fri", "cal.day.sat", "cal.day.sun",
+];
+
+function navLabelKey(view: CalendarView, dir: "prev" | "next"): I18nKey {
+  if (view === "month") return dir === "prev" ? "cal.month.prev" : "cal.month.next";
+  if (view === "week")  return dir === "prev" ? "cal.week.prev"  : "cal.week.next";
+  return dir === "prev" ? "cal.day.prev" : "cal.day.next";
+}
+
+function defaultHrefFor(row: CalendarItem): string {
+  switch (row.kind) {
+    case "deadline":         return `/deadlines/${encodeURIComponent(row.id)}`;
+    case "appointment":      return `/appointments/${encodeURIComponent(row.id)}`;
+    case "approval_request": return `/inbox`;
+    case "project_event":    return row.project_id ? `/projects/${encodeURIComponent(row.project_id)}` : "#";
+  }
+}
+
+export function bucketByDate(
+  rows: CalendarItem[], filter: (d: Date) => boolean,
+): Map<string, CalendarItem[]> {
+  const out = new Map<string, CalendarItem[]>();
+  for (const row of rows) {
+    const d = new Date(row.event_date);
+    if (isNaN(d.getTime())) continue;
+    if (!filter(d)) continue;
+    const key = isoDate(d);
+    const arr = out.get(key);
+    if (arr) arr.push(row);
+    else out.set(key, [row]);
+  }
+  return out;
+}
+
+export function filterByDay(rows: CalendarItem[], day: Date): CalendarItem[] {
+  const key = isoDate(day);
+  return rows.filter((r) => {
+    const d = new Date(r.event_date);
+    if (isNaN(d.getTime())) return false;
+    return isoDate(d) === key;
+  });
+}
+
+export function startOfWeek(d: Date): Date {
+  const out = new Date(d.getFullYear(), d.getMonth(), d.getDate());
+  const offset = (out.getDay() + 6) % 7;
+  out.setDate(out.getDate() - offset);
+  return out;
+}
+
+export function startOfDay(d: Date): Date {
+  return new Date(d.getFullYear(), d.getMonth(), d.getDate());
+}
+
+export function shift(d: Date, view: CalendarView, dir: number): Date {
+  if (view === "month") return new Date(d.getFullYear(), d.getMonth() + dir, 1);
+  if (view === "week")  return new Date(d.getFullYear(), d.getMonth(), d.getDate() + dir * 7);
+  return new Date(d.getFullYear(), d.getMonth(), d.getDate() + dir);
+}
+
+export function isToday(d: Date): boolean {
+  const now = new Date();
+  return d.getFullYear() === now.getFullYear()
+    && d.getMonth() === now.getMonth()
+    && d.getDate() === now.getDate();
+}
+
+export function isoDate(d: Date): string {
+  const y = d.getFullYear();
+  const m = String(d.getMonth() + 1).padStart(2, "0");
+  const day = String(d.getDate()).padStart(2, "0");
+  return `${y}-${m}-${day}`;
+}
+
+function formatRangeLabel(view: CalendarView, anchor: Date): string {
+  const lang = getLang() === "de" ? "de-DE" : "en-GB";
+  if (view === "month") {
+    return anchor.toLocaleDateString(lang, { month: "long", year: "numeric" });
+  }
+  if (view === "week") {
+    const start = startOfWeek(anchor);
+    const end = new Date(start);
+    end.setDate(start.getDate() + 6);
+    return formatWeekHeader(start, end, lang);
+  }
+  return anchor.toLocaleDateString(lang, {
+    weekday: "short", year: "numeric", month: "long", day: "numeric",
+  });
+}
+
+function formatWeekHeader(start: Date, end: Date, lang: string): string {
+  const startStr = start.toLocaleDateString(lang, { day: "numeric", month: "short" });
+  const endStr = end.toLocaleDateString(lang, { day: "numeric", month: "short", year: "numeric" });
+  return `${startStr} – ${endStr}`;
+}
+
+function firstAnchor(rows: CalendarItem[]): Date {
+  for (const row of rows) {
+    const d = new Date(row.event_date);
+    if (!isNaN(d.getTime())) return startOfDay(d);
+  }
+  return startOfDay(new Date());
+}
+
+function paramName(prefix: string | undefined, base: string): string {
+  if (!prefix) return base;
+  return `${prefix}_${base}`;
+}
+
+function readView(viewParam: string, fallback: CalendarView): CalendarView {
+  if (typeof window === "undefined") return fallback;
+  const params = new URLSearchParams(window.location.search);
+  const raw = params.get(viewParam);
+  if (raw === "month" || raw === "week" || raw === "day") return raw;
+  return fallback;
+}
+
+function readAnchor(dateParam: string, rows: CalendarItem[]): Date {
+  if (typeof window === "undefined") return firstAnchor(rows);
+  const params = new URLSearchParams(window.location.search);
+  const raw = params.get(dateParam);
+  if (raw) {
+    const m = /^(\d{4})-(\d{2})-(\d{2})$/.exec(raw);
+    if (m) {
+      const d = new Date(Number(m[1]), Number(m[2]) - 1, Number(m[3]));
+      if (!isNaN(d.getTime())) return d;
+    }
+  }
+  return firstAnchor(rows);
+}
+
+function writeURL(viewParam: string, dateParam: string, view: CalendarView, anchor: Date): void {
+  if (typeof window === "undefined") return;
+  const url = new URL(window.location.href);
+  url.searchParams.set(viewParam, view);
+  url.searchParams.set(dateParam, isoDate(anchor));
+  history.replaceState(null, "", url.toString());
+}

frontend/src/client/checklists-author.ts

@@ -0,0 +1,365 @@
+// Authoring wizard for paliad.checklists. Serves both /checklists/new
+// (create) and /checklists/templates/{slug}/edit (edit). The HTML bundle is the
+// same; this client reads location.pathname to decide which mode to
+// boot into.
+
+import { initI18n, t } from "./i18n";
+import { initSidebar } from "./sidebar";
+
+interface Item {
+  labelDE: string;
+  labelEN: string;
+  noteDE?: string;
+  noteEN?: string;
+  rule?: string;
+}
+
+interface Group {
+  titleDE: string;
+  titleEN: string;
+  items: Item[];
+}
+
+interface Checklist {
+  id: string;
+  slug: string;
+  title: string;
+  description: string;
+  regime: string;
+  court: string;
+  reference: string;
+  deadline: string;
+  lang: string;
+  visibility: string;
+  body: { groups: Group[] };
+}
+
+function esc(s: string): string {
+  const d = document.createElement("div");
+  d.textContent = s;
+  return d.innerHTML;
+}
+
+function escAttr(s: string): string {
+  return s.replace(/&/g, "&").replace(/"/g, """);
+}
+
+function detectMode(): { mode: "create" | "edit"; slug?: string } {
+  const path = window.location.pathname;
+  if (path === "/checklists/new") {
+    return { mode: "create" };
+  }
+  const m = path.match(/^\/checklists\/templates\/([^/]+)\/edit$/);
+  if (m) {
+    return { mode: "edit", slug: m[1] };
+  }
+  return { mode: "create" };
+}
+
+let groups: Group[] = [];
+
+function renderGroups() {
+  const container = document.getElementById("groups-container")!;
+  if (groups.length === 0) {
+    // Seed with a single empty group + item so the user has something
+    // to fill out rather than a blank canvas.
+    groups = [{ titleDE: "", titleEN: "", items: [{ labelDE: "", labelEN: "" }] }];
+  }
+  container.innerHTML = groups.map((g, gi) => {
+    const itemsHTML = g.items.map((it, ii) => {
+      return `<div class="author-item" data-gi="${gi}" data-ii="${ii}">
+        <div class="form-row">
+          <label class="form-label">${esc(t("checklisten.author.item.label"))}</label>
+          <input class="form-input" data-field="label" value="${escAttr(it.labelDE || "")}" />
+        </div>
+        <div class="form-grid form-grid-2">
+          <div class="form-row">
+            <label class="form-label">${esc(t("checklisten.author.item.note"))}</label>
+            <input class="form-input" data-field="note" value="${escAttr(it.noteDE || "")}" />
+          </div>
+          <div class="form-row">
+            <label class="form-label">${esc(t("checklisten.author.item.rule"))}</label>
+            <input class="form-input" data-field="rule" value="${escAttr(it.rule || "")}" />
+          </div>
+        </div>
+        <button type="button" class="btn btn-small btn-danger" data-action="remove-item">${esc(t("checklisten.author.item.remove"))}</button>
+      </div>`;
+    }).join("");
+    return `<div class="author-group" data-gi="${gi}">
+      <div class="form-row">
+        <label class="form-label">${esc(t("checklisten.author.group.title"))}</label>
+        <input class="form-input" data-field="group-title" value="${escAttr(g.titleDE || "")}" />
+      </div>
+      <div class="author-items">${itemsHTML}</div>
+      <div class="author-group-actions">
+        <button type="button" class="btn btn-small" data-action="add-item">${esc(t("checklisten.author.item.add"))}</button>
+        <button type="button" class="btn btn-small btn-danger" data-action="remove-group">${esc(t("checklisten.author.group.remove"))}</button>
+      </div>
+    </div>`;
+  }).join("");
+
+  // Wire input changes back into the data array.
+  container.querySelectorAll<HTMLInputElement>(".author-group > .form-row input[data-field=group-title]").forEach((input) => {
+    const groupDiv = input.closest<HTMLElement>(".author-group")!;
+    const gi = parseInt(groupDiv.dataset.gi!, 10);
+    input.addEventListener("input", () => {
+      groups[gi].titleDE = input.value;
+      groups[gi].titleEN = input.value; // single-language for Slice A
+    });
+  });
+
+  container.querySelectorAll<HTMLDivElement>(".author-item").forEach((itemDiv) => {
+    const gi = parseInt(itemDiv.dataset.gi!, 10);
+    const ii = parseInt(itemDiv.dataset.ii!, 10);
+    itemDiv.querySelectorAll<HTMLInputElement>("input[data-field]").forEach((input) => {
+      input.addEventListener("input", () => {
+        const field = input.dataset.field!;
+        if (field === "label") {
+          groups[gi].items[ii].labelDE = input.value;
+          groups[gi].items[ii].labelEN = input.value;
+        } else if (field === "note") {
+          groups[gi].items[ii].noteDE = input.value || undefined;
+          groups[gi].items[ii].noteEN = input.value || undefined;
+        } else if (field === "rule") {
+          groups[gi].items[ii].rule = input.value || undefined;
+        }
+      });
+    });
+    itemDiv.querySelector<HTMLButtonElement>("button[data-action=remove-item]")!.addEventListener("click", () => {
+      groups[gi].items.splice(ii, 1);
+      if (groups[gi].items.length === 0) {
+        groups[gi].items.push({ labelDE: "", labelEN: "" });
+      }
+      renderGroups();
+    });
+  });
+
+  container.querySelectorAll<HTMLButtonElement>("button[data-action=add-item]").forEach((btn) => {
+    const groupDiv = btn.closest<HTMLElement>(".author-group")!;
+    const gi = parseInt(groupDiv.dataset.gi!, 10);
+    btn.addEventListener("click", () => {
+      groups[gi].items.push({ labelDE: "", labelEN: "" });
+      renderGroups();
+    });
+  });
+
+  container.querySelectorAll<HTMLButtonElement>("button[data-action=remove-group]").forEach((btn) => {
+    const groupDiv = btn.closest<HTMLElement>(".author-group")!;
+    const gi = parseInt(groupDiv.dataset.gi!, 10);
+    btn.addEventListener("click", () => {
+      groups.splice(gi, 1);
+      renderGroups();
+    });
+  });
+}
+
+function showError(msg: string) {
+  const err = document.getElementById("author-error")!;
+  err.textContent = msg;
+  err.style.display = "";
+  err.scrollIntoView({ behavior: "smooth", block: "center" });
+}
+
+function clearError() {
+  const err = document.getElementById("author-error")!;
+  err.textContent = "";
+  err.style.display = "none";
+}
+
+function collectInput() {
+  const title = (document.getElementById("title") as HTMLInputElement).value.trim();
+  const description = (document.getElementById("description") as HTMLTextAreaElement).value.trim();
+  const regime = (document.getElementById("regime") as HTMLSelectElement).value;
+  const court = (document.getElementById("court") as HTMLInputElement).value.trim();
+  const reference = (document.getElementById("reference") as HTMLInputElement).value.trim();
+  const deadline = (document.getElementById("deadline") as HTMLInputElement).value.trim();
+  const lang = (document.getElementById("lang") as HTMLSelectElement).value;
+  const visibilityInput = document.querySelector<HTMLInputElement>("input[name=visibility]:checked");
+  const visibility = visibilityInput?.value || "private";
+  return { title, description, regime, court, reference, deadline, lang, visibility };
+}
+
+function validateGroups(): boolean {
+  if (groups.length === 0) return false;
+  let totalItems = 0;
+  for (const g of groups) {
+    if (!g.titleDE.trim()) return false;
+    for (const it of g.items) {
+      if (it.labelDE.trim()) totalItems += 1;
+    }
+  }
+  return totalItems > 0;
+}
+
+function trimmedGroups(): Group[] {
+  return groups
+    .filter((g) => g.titleDE.trim() && g.items.some((it) => it.labelDE.trim()))
+    .map((g) => ({
+      titleDE: g.titleDE.trim(),
+      titleEN: g.titleEN.trim(),
+      items: g.items
+        .filter((it) => it.labelDE.trim())
+        .map((it) => ({
+          labelDE: it.labelDE.trim(),
+          labelEN: it.labelEN.trim(),
+          noteDE: it.noteDE?.trim() || undefined,
+          noteEN: it.noteEN?.trim() || undefined,
+          rule: it.rule?.trim() || undefined,
+        })),
+    }));
+}
+
+async function loadEditTemplate(slug: string) {
+  // Use /api/checklists/{slug} (catalog Find with visibility check) +
+  // the mine list to ensure we have the editable fields. Templates the
+  // caller doesn't own/admin will trip the PATCH gate later.
+  const resp = await fetch(`/api/checklists/templates/mine`);
+  if (!resp.ok) {
+    showError(t("checklisten.author.error.notfound"));
+    return;
+  }
+  const rows: Checklist[] = (await resp.json()) ?? [];
+  const tpl = rows.find((r) => r.slug === slug);
+  if (!tpl) {
+    showError(t("checklisten.author.error.notfound"));
+    return;
+  }
+  (document.getElementById("author-heading")!).textContent = t("checklisten.author.heading.edit");
+  document.title = t("checklisten.author.title.edit");
+  (document.getElementById("title") as HTMLInputElement).value = tpl.title;
+  (document.getElementById("description") as HTMLTextAreaElement).value = tpl.description;
+  (document.getElementById("regime") as HTMLSelectElement).value = tpl.regime;
+  (document.getElementById("court") as HTMLInputElement).value = tpl.court;
+  (document.getElementById("reference") as HTMLInputElement).value = tpl.reference;
+  (document.getElementById("deadline") as HTMLInputElement).value = tpl.deadline;
+  (document.getElementById("lang") as HTMLSelectElement).value = tpl.lang || "de";
+  const visIn = document.querySelector<HTMLInputElement>(`input[name=visibility][value=${tpl.visibility}]`);
+  if (visIn) visIn.checked = true;
+  groups = (tpl.body?.groups || []).map((g) => ({
+    titleDE: g.titleDE || "",
+    titleEN: g.titleEN || g.titleDE || "",
+    items: g.items.map((it) => ({
+      labelDE: it.labelDE || "",
+      labelEN: it.labelEN || it.labelDE || "",
+      noteDE: it.noteDE,
+      noteEN: it.noteEN,
+      rule: it.rule,
+    })),
+  }));
+  if (groups.length === 0) {
+    groups = [{ titleDE: "", titleEN: "", items: [{ labelDE: "", labelEN: "" }] }];
+  }
+  renderGroups();
+}
+
+async function submitCreate() {
+  clearError();
+  const input = collectInput();
+  if (!input.title) {
+    showError(t("checklisten.author.error.title"));
+    return;
+  }
+  if (!validateGroups()) {
+    showError(t("checklisten.author.error.no_groups"));
+    return;
+  }
+  const saveBtn = document.getElementById("author-save") as HTMLButtonElement;
+  saveBtn.disabled = true;
+  saveBtn.textContent = t("checklisten.author.saving");
+  const body = JSON.stringify({ ...input, body: { groups: trimmedGroups() } });
+  const resp = await fetch("/api/checklists/templates", {
+    method: "POST",
+    headers: { "Content-Type": "application/json" },
+    body,
+  });
+  saveBtn.disabled = false;
+  saveBtn.textContent = t("checklisten.author.save");
+  if (!resp.ok) {
+    let msg = t("checklisten.author.error.generic");
+    try {
+      const j = await resp.json();
+      if (j?.error) msg = j.error;
+    } catch { /* keep generic */ }
+    showError(msg);
+    return;
+  }
+  const created: Checklist = await resp.json();
+  window.location.href = `/checklists/${encodeURIComponent(created.slug)}`;
+}
+
+async function submitEdit(slug: string) {
+  clearError();
+  const input = collectInput();
+  if (!input.title) {
+    showError(t("checklisten.author.error.title"));
+    return;
+  }
+  if (!validateGroups()) {
+    showError(t("checklisten.author.error.no_groups"));
+    return;
+  }
+  const saveBtn = document.getElementById("author-save") as HTMLButtonElement;
+  saveBtn.disabled = true;
+  saveBtn.textContent = t("checklisten.author.saving");
+  const patch = {
+    title: input.title,
+    description: input.description,
+    regime: input.regime,
+    court: input.court,
+    reference: input.reference,
+    deadline: input.deadline,
+    body: { groups: trimmedGroups() },
+  };
+  const resp = await fetch(`/api/checklists/templates/${encodeURIComponent(slug)}`, {
+    method: "PATCH",
+    headers: { "Content-Type": "application/json" },
+    body: JSON.stringify(patch),
+  });
+  // Visibility lives on its own endpoint so the audit row reflects the
+  // distinct transition. Only call if it actually changed.
+  if (resp.ok && input.visibility) {
+    await fetch(`/api/checklists/templates/${encodeURIComponent(slug)}/visibility`, {
+      method: "PATCH",
+      headers: { "Content-Type": "application/json" },
+      body: JSON.stringify({ visibility: input.visibility }),
+    });
+  }
+  saveBtn.disabled = false;
+  saveBtn.textContent = t("checklisten.author.save");
+  if (!resp.ok) {
+    let msg = t("checklisten.author.error.generic");
+    try {
+      const j = await resp.json();
+      if (j?.error) msg = j.error;
+    } catch { /* keep generic */ }
+    showError(msg);
+    return;
+  }
+  window.location.href = `/checklists/${encodeURIComponent(slug)}`;
+}
+
+document.addEventListener("DOMContentLoaded", () => {
+  initI18n();
+  initSidebar();
+  renderGroups();
+
+  document.getElementById("add-group")!.addEventListener("click", () => {
+    groups.push({ titleDE: "", titleEN: "", items: [{ labelDE: "", labelEN: "" }] });
+    renderGroups();
+  });
+
+  const { mode, slug } = detectMode();
+
+  if (mode === "edit" && slug) {
+    void loadEditTemplate(slug);
+  }
+
+  document.getElementById("author-form")!.addEventListener("submit", (e) => {
+    e.preventDefault();
+    if (mode === "edit" && slug) {
+      void submitEdit(slug);
+    } else {
+      void submitCreate();
+    }
+  });
+});

frontend/src/client/checklists-detail.ts

@@ -30,6 +30,37 @@ interface Checklist {
   referenceDE?: string;
   referenceEN?: string;
   groups: ChecklistGroup[];
+  // Slice B fields — present on authored entries via the merged
+  // catalog response. 'static' templates don't carry these.
+  origin?: "static" | "authored";
+  visibility?: string;
+  owner_email?: string;
+  owner_display_name?: string;
+}
+
+interface Me {
+  id: string;
+  email: string;
+  display_name: string;
+  global_role?: string;
+}
+
+interface UserSummary {
+  id: string;
+  email: string;
+  display_name: string;
+}
+
+interface PartnerUnit {
+  id: string;
+  name: string;
+}
+
+interface Share {
+  id: string;
+  checklist_id: string;
+  recipient_kind: "user" | "office" | "partner_unit" | "project";
+  recipient_label: string;
 }
 
 interface ChecklistInstance {
@@ -371,13 +402,320 @@ function rerenderAll() {
   renderInstances();
 }
 
+// --- Slice B: owner actions + admin promote + share modal ----------------
+
+let me: Me | null = null;
+let isOwner = false;
+let isAdmin = false;
+let shareUsers: UserSummary[] = [];
+let sharePartnerUnits: PartnerUnit[] = [];
+let shareProjects: AkteSummary[] = [];
+let activeShareKind: "user" | "office" | "partner_unit" | "project" = "user";
+
+async function loadMe(): Promise<Me | null> {
+  try {
+    const resp = await fetch("/api/me");
+    if (!resp.ok) return null;
+    return await resp.json();
+  } catch {
+    return null;
+  }
+}
+
+function templateOriginInfo() {
+  return template as unknown as {
+    origin?: string;
+    visibility?: string;
+    owner_email?: string;
+    owner_display_name?: string;
+  } | null;
+}
+
+function applyOwnerControls() {
+  const info = templateOriginInfo();
+  const isAuthored = info?.origin === "authored";
+  const provenance = document.getElementById("checklist-provenance")!;
+  if (isAuthored && info?.owner_display_name) {
+    provenance.style.display = "";
+    provenance.textContent = t("checklisten.detail.authored.by").replace("{author}", info.owner_display_name);
+  } else {
+    provenance.style.display = "none";
+  }
+
+  isOwner = !!(isAuthored && me && info?.owner_email && me.email.toLowerCase() === info.owner_email.toLowerCase());
+  isAdmin = !!(me && me.global_role === "global_admin");
+  const ownerOnly = (id: string, show: boolean) => {
+    const el = document.getElementById(id);
+    if (el) (el as HTMLElement).style.display = show ? "" : "none";
+  };
+  if (template) {
+    (document.getElementById("btn-edit-template") as HTMLAnchorElement | null)?.setAttribute(
+      "href",
+      `/checklists/templates/${encodeURIComponent(template.slug)}/edit`,
+    );
+  }
+  ownerOnly("btn-edit-template", isOwner);
+  ownerOnly("btn-share-template", isOwner);
+  ownerOnly("btn-delete-template", isOwner);
+
+  // Admin promote/demote — only when an authored template is visible to
+  // an admin, and only the appropriate one for the current visibility.
+  if (isAuthored && isAdmin) {
+    const isGlobal = info?.visibility === "global";
+    ownerOnly("btn-promote-template", !isGlobal);
+    ownerOnly("btn-demote-template", isGlobal);
+  } else {
+    ownerOnly("btn-promote-template", false);
+    ownerOnly("btn-demote-template", false);
+  }
+}
+
+function initOwnerActions() {
+  document.getElementById("btn-delete-template")?.addEventListener("click", async () => {
+    if (!template) return;
+    const isEN = getLang() === "en";
+    const title = isEN ? template.titleEN : template.titleDE;
+    const msg = t("checklisten.detail.delete.confirm").replace("{title}", title);
+    if (!window.confirm(msg)) return;
+    const resp = await fetch(`/api/checklists/templates/${encodeURIComponent(template.slug)}`, { method: "DELETE" });
+    if (!resp.ok) {
+      window.alert(t("checklisten.detail.delete.error"));
+      return;
+    }
+    window.location.href = "/checklists?tab=mine";
+  });
+
+  document.getElementById("btn-promote-template")?.addEventListener("click", async () => {
+    if (!template) return;
+    if (!window.confirm(t("checklisten.detail.promote.confirm"))) return;
+    const resp = await fetch(`/api/admin/checklists/${encodeURIComponent(template.slug)}/promote`, { method: "POST" });
+    if (!resp.ok) {
+      window.alert(t("checklisten.detail.promote.error"));
+      return;
+    }
+    window.location.reload();
+  });
+
+  document.getElementById("btn-demote-template")?.addEventListener("click", async () => {
+    if (!template) return;
+    if (!window.confirm(t("checklisten.detail.demote.confirm"))) return;
+    const resp = await fetch(`/api/admin/checklists/${encodeURIComponent(template.slug)}/demote`, {
+      method: "POST",
+      headers: { "Content-Type": "application/json" },
+      body: JSON.stringify({ target: "firm" }),
+    });
+    if (!resp.ok) {
+      window.alert(t("checklisten.detail.promote.error"));
+      return;
+    }
+    window.location.reload();
+  });
+}
+
+async function loadSharePickerData() {
+  // Fire all three lookups in parallel — the share modal needs all of
+  // them but doesn't depend on their order.
+  try {
+    const [usersResp, unitsResp, projectsResp] = await Promise.all([
+      fetch("/api/users"),
+      fetch("/api/partner-units"),
+      fetch("/api/projects"),
+    ]);
+    shareUsers = usersResp.ok ? await usersResp.json() : [];
+    sharePartnerUnits = unitsResp.ok ? await unitsResp.json() : [];
+    shareProjects = projectsResp.ok ? await projectsResp.json() : [];
+  } catch {
+    /* leave whatever loaded */
+  }
+  populateSharePickerOptions();
+}
+
+function populateSharePickerOptions() {
+  const userSel = document.getElementById("share-user") as HTMLSelectElement;
+  if (userSel) {
+    userSel.innerHTML = `<option value="">${esc(t("checklisten.share.pick"))}</option>`;
+    shareUsers
+      .slice()
+      .sort((a, b) => a.display_name.localeCompare(b.display_name))
+      .forEach((u) => {
+        if (me && u.id === me.id) return; // can't share with self
+        const opt = document.createElement("option");
+        opt.value = u.id;
+        opt.textContent = `${u.display_name} (${u.email})`;
+        userSel.appendChild(opt);
+      });
+  }
+  const officeSel = document.getElementById("share-office") as HTMLSelectElement;
+  if (officeSel) {
+    const officeKeys = ["munich", "duesseldorf", "hamburg", "amsterdam", "london", "paris", "milan", "madrid"];
+    officeSel.innerHTML = `<option value="">${esc(t("checklisten.share.pick"))}</option>`;
+    officeKeys.forEach((k) => {
+      const opt = document.createElement("option");
+      opt.value = k;
+      opt.textContent = k.charAt(0).toUpperCase() + k.slice(1);
+      officeSel.appendChild(opt);
+    });
+  }
+  const puSel = document.getElementById("share-partner-unit") as HTMLSelectElement;
+  if (puSel) {
+    puSel.innerHTML = `<option value="">${esc(t("checklisten.share.pick"))}</option>`;
+    sharePartnerUnits
+      .slice()
+      .sort((a, b) => a.name.localeCompare(b.name))
+      .forEach((u) => {
+        const opt = document.createElement("option");
+        opt.value = u.id;
+        opt.textContent = u.name;
+        puSel.appendChild(opt);
+      });
+  }
+  const prSel = document.getElementById("share-project") as HTMLSelectElement;
+  if (prSel) {
+    prSel.innerHTML = `<option value="">${esc(t("checklisten.share.pick"))}</option>`;
+    shareProjects
+      .slice()
+      .sort((a, b) => (a.reference || a.title).localeCompare(b.reference || b.title))
+      .forEach((p) => {
+        const opt = document.createElement("option");
+        opt.value = p.id;
+        opt.textContent = `${p.reference || ""} — ${p.title}`;
+        prSel.appendChild(opt);
+      });
+  }
+}
+
+function switchShareKind(kind: "user" | "office" | "partner_unit" | "project") {
+  activeShareKind = kind;
+  document.querySelectorAll<HTMLButtonElement>("#share-kind-pills .filter-pill").forEach((p) => {
+    p.classList.toggle("active", p.dataset.kind === kind);
+  });
+  document.querySelectorAll<HTMLElement>(".share-kind-section").forEach((s) => {
+    s.style.display = s.dataset.kind === kind ? "" : "none";
+  });
+}
+
+function initShareModal() {
+  const modal = document.getElementById("share-modal")!;
+  const msg = document.getElementById("share-msg")!;
+  const close = () => { modal.style.display = "none"; };
+
+  document.getElementById("btn-share-template")?.addEventListener("click", async () => {
+    if (!template) return;
+    msg.textContent = "";
+    msg.className = "form-msg";
+    switchShareKind("user");
+    modal.style.display = "flex";
+    await loadSharePickerData();
+    await renderGrants();
+  });
+
+  document.getElementById("share-close")?.addEventListener("click", close);
+  document.getElementById("share-cancel")?.addEventListener("click", close);
+  modal.addEventListener("click", (e) => { if (e.target === e.currentTarget) close(); });
+
+  document.getElementById("share-kind-pills")?.addEventListener("click", (e) => {
+    const btn = (e.target as HTMLElement).closest<HTMLButtonElement>(".filter-pill[data-kind]");
+    if (!btn) return;
+    switchShareKind(btn.dataset.kind as typeof activeShareKind);
+  });
+
+  document.getElementById("share-submit")?.addEventListener("click", async () => {
+    if (!template) return;
+    const input: Record<string, unknown> = { recipient_kind: activeShareKind };
+    switch (activeShareKind) {
+      case "user": {
+        const v = (document.getElementById("share-user") as HTMLSelectElement).value;
+        if (!v) { msg.textContent = t("checklisten.share.error.pick"); msg.className = "form-msg form-msg-error"; return; }
+        input["recipient_user_id"] = v;
+        break;
+      }
+      case "office": {
+        const v = (document.getElementById("share-office") as HTMLSelectElement).value;
+        if (!v) { msg.textContent = t("checklisten.share.error.pick"); msg.className = "form-msg form-msg-error"; return; }
+        input["recipient_office"] = v;
+        break;
+      }
+      case "partner_unit": {
+        const v = (document.getElementById("share-partner-unit") as HTMLSelectElement).value;
+        if (!v) { msg.textContent = t("checklisten.share.error.pick"); msg.className = "form-msg form-msg-error"; return; }
+        input["recipient_partner_unit_id"] = v;
+        break;
+      }
+      case "project": {
+        const v = (document.getElementById("share-project") as HTMLSelectElement).value;
+        if (!v) { msg.textContent = t("checklisten.share.error.pick"); msg.className = "form-msg form-msg-error"; return; }
+        input["recipient_project_id"] = v;
+        break;
+      }
+    }
+    const resp = await fetch(`/api/checklists/templates/${encodeURIComponent(template.slug)}/shares`, {
+      method: "POST",
+      headers: { "Content-Type": "application/json" },
+      body: JSON.stringify(input),
+    });
+    if (!resp.ok) {
+      let errMsg = t("checklisten.share.error.generic");
+      try {
+        const j = await resp.json();
+        if (j?.error) errMsg = j.error;
+      } catch { /* keep generic */ }
+      msg.textContent = errMsg;
+      msg.className = "form-msg form-msg-error";
+      return;
+    }
+    msg.textContent = t("checklisten.share.success");
+    msg.className = "form-msg form-msg-success";
+    await renderGrants();
+  });
+}
+
+async function renderGrants() {
+  if (!template) return;
+  const list = document.getElementById("share-grants-list")!;
+  const empty = document.getElementById("share-grants-empty")!;
+  const resp = await fetch(`/api/checklists/templates/${encodeURIComponent(template.slug)}/shares`);
+  const rows: Share[] = resp.ok ? await resp.json() : [];
+  if (rows.length === 0) {
+    list.innerHTML = "";
+    list.appendChild(empty);
+    empty.style.display = "";
+    return;
+  }
+  empty.style.display = "none";
+  list.innerHTML = rows.map((s) => {
+    const kindLabel = esc(t(("checklisten.share.grants.recipient." + s.recipient_kind) as never) || s.recipient_kind);
+    return `<li class="share-grant-row" data-id="${esc(s.id)}">
+      <span class="share-grant-kind">${kindLabel}</span>
+      <span class="share-grant-label">${esc(s.recipient_label || "")}</span>
+      <button type="button" class="btn-small btn-ghost" data-action="revoke" data-id="${esc(s.id)}">${esc(t("checklisten.share.grants.revoke"))}</button>
+    </li>`;
+  }).join("");
+  list.querySelectorAll<HTMLButtonElement>("button[data-action=revoke]").forEach((btn) => {
+    btn.addEventListener("click", async () => {
+      if (!window.confirm(t("checklisten.share.grants.revoke.confirm"))) return;
+      const resp = await fetch(`/api/checklists/shares/${encodeURIComponent(btn.dataset.id!)}`, { method: "DELETE" });
+      if (!resp.ok && resp.status !== 204) {
+        window.alert(t("checklisten.share.grants.revoke.error"));
+        return;
+      }
+      await renderGrants();
+    });
+  });
+}
+
 document.addEventListener("DOMContentLoaded", () => {
   initI18n();
   initSidebar();
   initNewInstance();
   initFeedback();
+  initOwnerActions();
+  initShareModal();
   onLangChange(rerenderAll);
-  void loadTemplate();
+  void (async () => {
+    me = await loadMe();
+    await loadTemplate();
+    applyOwnerControls();
+  })();
   void loadInstances();
   void loadAkten();
 });

frontend/src/client/checklists-instance.ts

@@ -40,6 +40,16 @@ interface Instance {
   created_by: string;
   created_at: string;
   updated_at: string;
+  // Slice C — snapshot of the template body + its version at create time.
+  template_snapshot?: { groups: ChecklistGroup[] } | null;
+  template_version?: number | null;
+}
+
+// Slice C — augmented Checklist with origin + version, returned by
+// /api/checklists/{slug}.
+interface ChecklistWithMeta extends Checklist {
+  origin?: "static" | "authored";
+  version?: number;
 }
 
 let template: Checklist | null = null;
@@ -155,6 +165,119 @@ function renderHeader() {
     parts.push(`<div class="checklist-meta-item"><dt>${akteLabel}</dt><dd><a href="/projects/${esc(instance.project_id)}">${t("checklisten.instance.akte.open") || "Öffnen"}</a></dd></div>`);
   }
   document.getElementById("instance-meta")!.innerHTML = parts.join("");
+  renderOutdatedBadge();
+}
+
+// Slice C — show an "outdated" badge when the live template has a
+// version > the instance's snapshot version. Both values must be
+// non-null for the comparison to be meaningful (pre-Slice-C instances
+// have NULL template_version; static templates always have version=1
+// and never bump).
+function renderOutdatedBadge() {
+  const slot = document.getElementById("instance-outdated-slot");
+  if (!slot || !instance || !template) return;
+  const tplMeta = template as ChecklistWithMeta;
+  const instVersion = instance.template_version;
+  const tplVersion = tplMeta.version;
+  if (
+    instVersion == null ||
+    tplVersion == null ||
+    tplMeta.origin !== "authored" ||
+    tplVersion <= instVersion
+  ) {
+    slot.innerHTML = "";
+    return;
+  }
+  const badge = esc(t("checklisten.instance.outdated.badge"));
+  const note = esc(
+    t("checklisten.instance.outdated.note")
+      .replace("{from}", String(instVersion))
+      .replace("{to}", String(tplVersion)),
+  );
+  const action = esc(t("checklisten.instance.outdated.diff"));
+  slot.innerHTML = `<div class="instance-outdated-banner">
+    <span class="instance-outdated-badge">${badge}</span>
+    <span class="instance-outdated-note">${note}</span>
+    <button type="button" class="btn-small" id="btn-show-diff">${action}</button>
+  </div>`;
+  document.getElementById("btn-show-diff")!.addEventListener("click", openDiffModal);
+}
+
+// Shallow diff between two checklist bodies. Compares item label/note/
+// rule pairs grouped by section title. Items with the same group title
+// + same label are matched; differences in note/rule are flagged
+// 'changed'. Items present only in snapshot are 'removed'; items only
+// in current are 'added'.
+function diffBodies(snapshot: { groups: ChecklistGroup[] } | null | undefined, current: ChecklistGroup[]):
+  { added: string[]; removed: string[]; changed: string[] } {
+  const added: string[] = [];
+  const removed: string[] = [];
+  const changed: string[] = [];
+  const oldGroups = snapshot?.groups ?? [];
+  const oldMap: Record<string, ChecklistItem> = {};
+  for (const g of oldGroups) {
+    for (const it of g.items) {
+      const key = `${g.titleDE || g.titleEN}::${it.labelDE || it.labelEN}`;
+      oldMap[key] = it;
+    }
+  }
+  const newMap: Record<string, ChecklistItem> = {};
+  for (const g of current) {
+    for (const it of g.items) {
+      const key = `${g.titleDE || g.titleEN}::${it.labelDE || it.labelEN}`;
+      newMap[key] = it;
+      if (!(key in oldMap)) {
+        added.push(it.labelDE || it.labelEN);
+      } else {
+        const o = oldMap[key];
+        if ((o.noteDE || o.noteEN || "") !== (it.noteDE || it.noteEN || "") ||
+            (o.rule || "") !== (it.rule || "")) {
+          changed.push(it.labelDE || it.labelEN);
+        }
+      }
+    }
+  }
+  for (const key in oldMap) {
+    if (!(key in newMap)) {
+      const labelParts = key.split("::");
+      removed.push(labelParts[1] || key);
+    }
+  }
+  return { added, removed, changed };
+}
+
+function openDiffModal() {
+  if (!template || !instance) return;
+  const modal = document.getElementById("instance-diff-modal")!;
+  const body = document.getElementById("instance-diff-body")!;
+  const diff = diffBodies(instance.template_snapshot, template.groups);
+  const empty = diff.added.length === 0 && diff.removed.length === 0 && diff.changed.length === 0;
+  if (empty) {
+    body.innerHTML = `<p class="entity-events-empty">${esc(t("checklisten.instance.diff.empty"))}</p>`;
+  } else {
+    const section = (label: string, klass: string, items: string[]) => {
+      if (items.length === 0) return "";
+      return `<section class="instance-diff-section ${klass}">
+        <h3>${esc(label)}</h3>
+        <ul>${items.map((s) => `<li>${esc(s)}</li>`).join("")}</ul>
+      </section>`;
+    };
+    body.innerHTML = [
+      section(t("checklisten.instance.diff.added"), "instance-diff-added", diff.added),
+      section(t("checklisten.instance.diff.removed"), "instance-diff-removed", diff.removed),
+      section(t("checklisten.instance.diff.changed"), "instance-diff-changed", diff.changed),
+    ].join("");
+  }
+  modal.style.display = "flex";
+}
+
+function initDiffModal() {
+  const modal = document.getElementById("instance-diff-modal");
+  if (!modal) return;
+  const close = () => { modal.style.display = "none"; };
+  document.getElementById("instance-diff-close")?.addEventListener("click", close);
+  document.getElementById("instance-diff-close-bottom")?.addEventListener("click", close);
+  modal.addEventListener("click", (e) => { if (e.target === e.currentTarget) close(); });
 }
 
 function renderGroups() {
@@ -389,6 +512,7 @@ document.addEventListener("DOMContentLoaded", () => {
   initPrint();
   initRename();
   initFeedback();
+  initDiffModal();
   onLangChange(renderAll);
   void bootstrap();
 });

frontend/src/client/checklists.ts

@@ -11,6 +11,26 @@ interface ChecklistSummary {
   courtDE: string;
   courtEN: string;
   itemCount: number;
+  origin?: "static" | "authored";
+  visibility?: string;
+  owner_email?: string;
+  owner_display_name?: string;
+}
+
+interface MyChecklist {
+  id: string;
+  slug: string;
+  owner_id: string;
+  title: string;
+  description: string;
+  regime: string;
+  court: string;
+  reference: string;
+  deadline: string;
+  lang: string;
+  visibility: string;
+  created_at: string;
+  updated_at: string;
 }
 
 interface ChecklistInstance {
@@ -26,15 +46,20 @@ interface ChecklistInstance {
   project_title?: string | null;
 }
 
-type TabId = "templates" | "instances";
+type TabId = "templates" | "mine" | "gallery" | "instances";
 
-const VALID_TABS: TabId[] = ["templates", "instances"];
+const VALID_TABS: TabId[] = ["templates", "mine", "gallery", "instances"];
 
 let allChecklists: ChecklistSummary[] = [];
 let activeRegime = "all";
+let galleryRegime = "all";
 let allInstances: ChecklistInstance[] = [];
 let templatesBySlug: Record<string, ChecklistSummary> = {};
 let instancesLoaded = false;
+let myTemplates: MyChecklist[] = [];
+let myTemplatesLoaded = false;
+let galleryLoaded = false;
+let me: { id: string; email: string } | null = null;
 let activeTab: TabId = "templates";
 
 function esc(s: string): string {
@@ -208,7 +233,10 @@ function showTab(tab: TabId, opts: { pushHistory?: boolean } = {}) {
     el.style.display = el.id === `tab-${tab}` ? "" : "none";
   });
   if (opts.pushHistory ?? true) {
-    const newURL = tab === "instances" ? "/checklists?tab=instances" : "/checklists";
+    let newURL = "/checklists";
+    if (tab === "instances") newURL = "/checklists?tab=instances";
+    if (tab === "mine") newURL = "/checklists?tab=mine";
+    if (tab === "gallery") newURL = "/checklists?tab=gallery";
     if (window.location.pathname + window.location.search !== newURL) {
       window.history.replaceState({}, "", newURL);
     }
@@ -216,6 +244,155 @@ function showTab(tab: TabId, opts: { pushHistory?: boolean } = {}) {
   if (tab === "instances") {
     void loadInstances();
   }
+  if (tab === "mine") {
+    void loadMyTemplates();
+  }
+  if (tab === "gallery") {
+    void loadGallery();
+  }
+}
+
+async function loadGallery(force = false) {
+  if (galleryLoaded && !force) return;
+  galleryLoaded = true;
+  // /api/checklists already returns the merged catalog; the gallery
+  // filter just narrows to non-static + non-owned + non-private.
+  if (allChecklists.length === 0) {
+    await loadTemplates();
+  }
+  renderGallery();
+}
+
+function renderGallery() {
+  const loading = document.getElementById("checklists-gallery-loading")!;
+  const empty = document.getElementById("checklists-gallery-empty")!;
+  const grid = document.getElementById("checklists-gallery-grid") as HTMLElement;
+
+  loading.style.display = "none";
+
+  const visible = allChecklists.filter((c) => {
+    if (c.origin !== "authored") return false;
+    if (me && c.owner_email && me.email.toLowerCase() === c.owner_email.toLowerCase()) return false;
+    if (galleryRegime !== "all" && c.regime !== galleryRegime) return false;
+    return true;
+  });
+
+  if (visible.length === 0) {
+    empty.style.display = "";
+    grid.style.display = "none";
+    return;
+  }
+  empty.style.display = "none";
+  grid.style.display = "";
+
+  const isEN = getLang() === "en";
+  grid.innerHTML = visible.map((c) => {
+    const title = isEN ? c.titleEN : c.titleDE;
+    const desc = isEN ? c.descriptionEN : c.descriptionDE;
+    const court = isEN ? c.courtEN : c.courtDE;
+    const itemsLabel = isEN ? "items" : "Punkte";
+    const visKey = `checklisten.mine.visibility.${c.visibility || ""}`;
+    const visLabel = c.visibility ? esc(t(visKey as never) || c.visibility) : "";
+    const authorLine = c.owner_display_name
+      ? `<p class="checklist-card-author">${esc(t("checklisten.detail.authored.by").replace("{author}", c.owner_display_name))}</p>`
+      : "";
+    return `<a href="/checklists/${esc(c.slug)}" class="checklist-card">
+      <div class="checklist-card-top">
+        <span class="checklist-regime checklist-regime-${esc(c.regime)}">${esc(c.regime)}</span>
+        <span class="checklist-card-count">${c.itemCount} ${itemsLabel}</span>
+      </div>
+      <h2 class="checklist-card-title">${esc(title)}</h2>
+      <p class="checklist-card-desc">${esc(desc)}</p>
+      <p class="checklist-card-court">${esc(court)}</p>
+      ${authorLine}
+      ${visLabel ? `<span class="visibility-chip visibility-chip-${esc(c.visibility || "")}">${visLabel}</span>` : ""}
+    </a>`;
+  }).join("");
+}
+
+function initGalleryFilters() {
+  const container = document.getElementById("checklist-gallery-filters");
+  if (!container) return;
+  container.addEventListener("click", (e) => {
+    const btn = (e.target as HTMLElement).closest<HTMLButtonElement>(".filter-pill");
+    if (!btn) return;
+    container.querySelectorAll(".filter-pill").forEach((p) => p.classList.remove("active"));
+    btn.classList.add("active");
+    galleryRegime = btn.dataset.regime ?? "all";
+    renderGallery();
+  });
+}
+
+async function loadMe() {
+  try {
+    const resp = await fetch("/api/me");
+    if (resp.ok) me = await resp.json();
+  } catch { /* leave me=null */ }
+}
+
+async function loadMyTemplates(force = false) {
+  if (myTemplatesLoaded && !force) return;
+  myTemplatesLoaded = true;
+  const resp = await fetch("/api/checklists/templates/mine");
+  if (!resp.ok) {
+    myTemplates = [];
+  } else {
+    myTemplates = (await resp.json()) ?? [];
+  }
+  renderMyTemplates();
+}
+
+function renderMyTemplates() {
+  const loading = document.getElementById("checklists-mine-loading")!;
+  const empty = document.getElementById("checklists-mine-empty")!;
+  const grid = document.getElementById("checklists-mine-grid") as HTMLElement;
+
+  loading.style.display = "none";
+
+  if (myTemplates.length === 0) {
+    empty.style.display = "";
+    grid.style.display = "none";
+    return;
+  }
+  empty.style.display = "none";
+  grid.style.display = "";
+
+  grid.innerHTML = myTemplates.map((tpl) => {
+    const visKey = `checklisten.mine.visibility.${tpl.visibility}`;
+    const visLabel = esc(t(visKey as never) || tpl.visibility);
+    const titleSafe = esc(tpl.title);
+    return `<article class="checklist-card checklist-card-mine" data-slug="${esc(tpl.slug)}" data-title="${escAttr(tpl.title)}">
+      <div class="checklist-card-top">
+        <span class="checklist-regime checklist-regime-${esc(tpl.regime)}">${esc(tpl.regime)}</span>
+        <span class="checklist-card-count visibility-chip visibility-chip-${esc(tpl.visibility)}">${visLabel}</span>
+      </div>
+      <h2 class="checklist-card-title">
+        <a href="/checklists/${esc(tpl.slug)}">${titleSafe}</a>
+      </h2>
+      <p class="checklist-card-desc">${esc(tpl.description || "")}</p>
+      <p class="checklist-card-court">${esc(tpl.court || "")}</p>
+      <div class="checklist-card-actions">
+        <a class="btn btn-small" href="/checklists/templates/${esc(tpl.slug)}/edit" data-i18n="checklisten.mine.edit">Bearbeiten</a>
+        <button class="btn btn-small btn-danger" data-action="delete" data-slug="${esc(tpl.slug)}" data-title="${escAttr(tpl.title)}" data-i18n="checklisten.mine.delete">L&ouml;schen</button>
+      </div>
+    </article>`;
+  }).join("");
+
+  grid.querySelectorAll<HTMLButtonElement>("button[data-action=delete]").forEach((btn) => {
+    btn.addEventListener("click", async (e) => {
+      e.preventDefault();
+      const slug = btn.dataset.slug!;
+      const title = btn.dataset.title || slug;
+      const msg = t("checklisten.mine.delete.confirm").replace("{title}", title);
+      if (!window.confirm(msg)) return;
+      const resp = await fetch(`/api/checklists/templates/${encodeURIComponent(slug)}`, { method: "DELETE" });
+      if (!resp.ok) {
+        window.alert(t("checklisten.mine.delete.error"));
+        return;
+      }
+      await loadMyTemplates(true);
+    });
+  });
 }
 
 function initTabs() {
@@ -234,11 +411,15 @@ document.addEventListener("DOMContentLoaded", () => {
   initI18n();
   initSidebar();
   initFilters();
+  initGalleryFilters();
   initTabs();
   onLangChange(() => {
     renderTemplates();
     if (instancesLoaded) renderInstances();
+    if (myTemplatesLoaded) renderMyTemplates();
+    if (galleryLoaded) renderGallery();
   });
+  void loadMe();
   void loadTemplates();
   showTab(parseTab(), { pushHistory: false });
 });

frontend/src/client/components/approval-edit-modal.ts

@@ -0,0 +1,435 @@
+// t-paliad-216 Slice B (initial) + t-paliad-217 Slice C (rewrite) —
+// modal for the "Suggest changes" approval action.
+//
+// The approver authors a counter-proposal: edits any field on the
+// underlying deadline / appointment AND/OR leaves a free-text note. On
+// submit the caller POSTs to /api/approval-requests/{id}/suggest-changes,
+// which closes the OLD row as `changes_requested` and spawns a NEW pending
+// row authored by the approver carrying counter_payload as its payload.
+//
+// Scope (t-paliad-217 m's Q1 Reading A — 2026-05-20):
+//   - Every editable field on the entity is in the form, not just the
+//     date allowlist that triggers approval (t-paliad-138 §Q4). The
+//     backend's counter-allowlist (buildCounterSetClauses in
+//     approval_service.go) accepts the wider set:
+//       deadline:    title, due_date, original_due_date, warning_date,
+//                    description, notes, rule_code, event_type_ids
+//       appointment: title, start_at, end_at, description, location,
+//                    appointment_type
+//   - Lifecycle restriction: update-only. shape-list.ts hides the
+//     suggest_changes button for create / complete / delete; this modal
+//     refuses to open on them as defence-in-depth.
+//
+// Built on the unified openModal() primitive (t-paliad-217 Slice A) —
+// the primitive owns ESC, focus, backdrop, close button, browser
+// back-button, mobile takeover. This module only constructs the body.
+//
+// API:
+//   const result = await openApprovalEditModal({
+//     entityType: "deadline",
+//     lifecycleEvent: "update",
+//     payload: {...},  // requester's proposed values (= current entity row)
+//     preImage: {...}, // pre-mutation values (for "vorher" diff hints)
+//   });
+//   if (result) {
+//     // result.counterPayload + result.note ready to POST
+//   } else {
+//     // user cancelled
+//   }
+
+import { t } from "../i18n";
+import {
+  attachEventTypePicker,
+  fetchEventTypes,
+  type PickerHandle,
+} from "../event-types";
+import { openModal } from "./modal";
+
+export interface ApprovalEditModalArgs {
+  entityType: "deadline" | "appointment";
+  lifecycleEvent: string;
+  payload: Record<string, unknown> | null;
+  preImage: Record<string, unknown> | null;
+  // Optional context for the read-only context section. The caller can
+  // hydrate these from the row's API response (project_title,
+  // requester_name, requested_at) when available; the modal degrades
+  // gracefully when they're missing.
+  projectTitle?: string;
+  requesterName?: string;
+  requestedAt?: string;
+}
+
+export interface ApprovalEditModalResult {
+  counterPayload: Record<string, unknown>;
+  note: string;
+}
+
+// FieldSpec — one editable input row. The type determines the <input>
+// (or <textarea>) shape; getValue / setValue normalise the form-element
+// value to the server-friendly counter_payload shape.
+interface FieldSpec {
+  key: string;
+  labelKey: string;       // i18n key
+  inputType: "text" | "date" | "datetime-local" | "textarea";
+  // Required = title (NOT NULL on the column). Other fields are nullable;
+  // empty string clears (server's addText helper handles this).
+  required?: boolean;
+}
+
+// Deadline-only fields rendered in the editable section. `rule_code` and
+// `event_type_ids` are intentionally NOT here — they're bundled into the
+// dedicated "Verfahrenshandlung" section below the base fields so the
+// event-type (parent concept) reads before the rule (m/paliad#56).
+const DEADLINE_FIELDS: ReadonlyArray<FieldSpec> = [
+  { key: "title",             labelKey: "deadlines.field.title",        inputType: "text",     required: true },
+  { key: "due_date",          labelKey: "deadlines.field.due",          inputType: "date" },
+  { key: "original_due_date", labelKey: "approvals.suggest.field.original_due_date", inputType: "date" },
+  { key: "warning_date",      labelKey: "approvals.suggest.field.warning_date",      inputType: "date" },
+  { key: "description",       labelKey: "approvals.suggest.field.description",       inputType: "textarea" },
+  { key: "notes",             labelKey: "deadlines.field.notes",        inputType: "textarea" },
+];
+
+const APPOINTMENT_FIELDS: ReadonlyArray<FieldSpec> = [
+  { key: "title",            labelKey: "appointments.field.title",       inputType: "text",     required: true },
+  { key: "start_at",         labelKey: "appointments.field.start",       inputType: "datetime-local" },
+  { key: "end_at",           labelKey: "appointments.field.end",         inputType: "datetime-local" },
+  { key: "location",         labelKey: "appointments.field.location",    inputType: "text" },
+  { key: "appointment_type", labelKey: "appointments.field.type",        inputType: "text" },
+  { key: "description",      labelKey: "appointments.field.description", inputType: "textarea" },
+];
+
+export async function openApprovalEditModal(
+  args: ApprovalEditModalArgs,
+): Promise<ApprovalEditModalResult | null> {
+  if (args.lifecycleEvent !== "update") {
+    window.alert(t("approvals.suggest.unsupported_lifecycle"));
+    return null;
+  }
+
+  const fields = args.entityType === "deadline" ? DEADLINE_FIELDS : APPOINTMENT_FIELDS;
+  const original = (args.payload ?? {}) as Record<string, unknown>;
+  const preImage = (args.preImage ?? {}) as Record<string, unknown>;
+
+  // Build the body element imperatively so we can wire input handlers
+  // before openModal mounts the dialog.
+  const body = document.createElement("div");
+  body.className = "approval-suggest-body";
+
+  body.appendChild(renderIntro());
+  body.appendChild(renderFieldsSection(fields, original, preImage));
+
+  // event_type_ids picker (deadline-only) — async because the picker
+  // needs to fetch the firm's event-type catalogue. We attach a host
+  // element synchronously and populate it once the fetch returns.
+  let eventTypePicker: PickerHandle | null = null;
+  let eventTypePickerLoaded = false;
+  if (args.entityType === "deadline") {
+    const pickerSection = renderEventTypePickerSection(original, preImage);
+    body.appendChild(pickerSection.section);
+    void (async () => {
+      try {
+        await fetchEventTypes();
+        eventTypePicker = attachEventTypePicker(pickerSection.host, {
+          initialIDs: (original.event_type_ids as string[] | undefined) ?? [],
+        });
+        eventTypePickerLoaded = true;
+      } catch (_e) {
+        // Fail-soft: leave the section empty; counter still works
+        // without event_type_ids in the payload.
+        pickerSection.host.textContent = t("approvals.suggest.event_type_picker_unavailable");
+      }
+    })();
+  }
+
+  body.appendChild(renderContextSection(args, original));
+  const noteEl = renderNoteSection();
+  body.appendChild(noteEl.section);
+
+  // Read inputs back at submit time. The same list is what we listen to
+  // for the dirty-state gate.
+  const fieldInputs = Array.from(
+    body.querySelectorAll<HTMLInputElement | HTMLTextAreaElement>("[data-suggest-field]"),
+  );
+
+  return openModal<ApprovalEditModalResult>({
+    title: `${t("approvals.suggest.modal_title")} — ${t(("approvals.entity." + args.entityType) as never)}`,
+    body,
+    size: "lg",
+    primary: {
+      label: t("approvals.suggest.submit"),
+      handler: (close) => {
+        const result = buildResult(fieldInputs, noteEl.textarea, original, eventTypePicker, eventTypePickerLoaded);
+        if (!result.dirty && !result.note) {
+          // Server enforces too. Client-side guard avoids the 400 round-trip.
+          window.alert(t("approvals.suggest.submit_disabled_hint"));
+          return;
+        }
+        close({
+          counterPayload: result.counterPayload,
+          note: result.note,
+        });
+      },
+    },
+    secondary: { label: t("approvals.suggest.cancel") },
+  });
+}
+
+function renderIntro(): HTMLElement {
+  const p = document.createElement("p");
+  p.className = "approval-suggest-intro muted";
+  p.textContent = t("approvals.suggest.intro");
+  return p;
+}
+
+function renderFieldsSection(
+  fields: ReadonlyArray<FieldSpec>,
+  original: Record<string, unknown>,
+  preImage: Record<string, unknown>,
+): HTMLElement {
+  const section = document.createElement("section");
+  section.className = "approval-suggest-section approval-suggest-section--editable";
+  const h = document.createElement("h3");
+  h.className = "approval-suggest-section-title";
+  h.textContent = t("approvals.suggest.section.editable");
+  section.appendChild(h);
+
+  for (const f of fields) {
+    section.appendChild(renderSingleField(f, original, preImage));
+  }
+  return section;
+}
+
+// Verfahrenshandlung section — bundles the event-type picker and the
+// rule_code input so the editor reads "what procedural step? which rule
+// cites it?" instead of two disconnected fields with rule above type
+// (m/paliad#56). The hint underneath spells out the parent/child
+// relationship so first-time editors don't read them as peers.
+function renderEventTypePickerSection(
+  original: Record<string, unknown>,
+  preImage: Record<string, unknown>,
+): { section: HTMLElement; host: HTMLElement } {
+  const section = document.createElement("section");
+  section.className = "approval-suggest-section approval-suggest-section--editable";
+
+  const h = document.createElement("h3");
+  h.className = "approval-suggest-section-title";
+  h.textContent = t("approvals.suggest.section.event_type_rule");
+  section.appendChild(h);
+
+  const host = document.createElement("div");
+  host.className = "approval-suggest-event-type-picker";
+  section.appendChild(host);
+
+  // Rule citation — rendered as a sub-field directly beneath the picker so
+  // the visual hierarchy matches the conceptual one (rule is meta on the
+  // event type, not a peer).
+  const ruleField: FieldSpec = {
+    key: "rule_code",
+    labelKey: "approvals.suggest.field.rule_code",
+    inputType: "text",
+  };
+  section.appendChild(renderSingleField(ruleField, original, preImage));
+
+  return { section, host };
+}
+
+// renderSingleField builds one labelled input in the same shape as the
+// fields-section loop. Extracted so the Verfahrenshandlung section can
+// host the rule_code input next to the picker without duplicating the
+// wiring (dirty-tracking, pre_image hint, label/for binding).
+function renderSingleField(
+  f: FieldSpec,
+  original: Record<string, unknown>,
+  preImage: Record<string, unknown>,
+): HTMLElement {
+  const wrap = document.createElement("div");
+  wrap.className = "form-field approval-suggest-field";
+
+  const label = document.createElement("label");
+  label.textContent = t(f.labelKey as never);
+  wrap.appendChild(label);
+
+  const value = formatFieldForInput(original[f.key], f.inputType);
+
+  let input: HTMLInputElement | HTMLTextAreaElement;
+  if (f.inputType === "textarea") {
+    input = document.createElement("textarea");
+    input.rows = 3;
+    (input as HTMLTextAreaElement).value = value;
+  } else {
+    input = document.createElement("input");
+    (input as HTMLInputElement).type = f.inputType;
+    (input as HTMLInputElement).value = value;
+  }
+  input.dataset.suggestField = f.key;
+  input.dataset.suggestOriginal = value;
+  input.dataset.suggestInputType = f.inputType;
+  if (f.required) input.required = true;
+
+  const inputID = `suggest-field-${f.key}`;
+  input.id = inputID;
+  label.setAttribute("for", inputID);
+
+  wrap.appendChild(input);
+
+  const preVal = formatFieldForInput(preImage[f.key], f.inputType);
+  if (preVal && preVal !== value) {
+    const hint = document.createElement("span");
+    hint.className = "approval-suggest-prehint";
+    hint.textContent = `${t("approvals.diff.before")}: ${preVal}`;
+    wrap.appendChild(hint);
+  }
+  return wrap;
+}
+
+function renderContextSection(
+  args: ApprovalEditModalArgs,
+  original: Record<string, unknown>,
+): HTMLElement {
+  const section = document.createElement("section");
+  section.className = "approval-suggest-section approval-suggest-section--context";
+
+  const h = document.createElement("h3");
+  h.className = "approval-suggest-section-title";
+  h.textContent = t("approvals.suggest.section.context");
+  section.appendChild(h);
+
+  const rows: Array<[string, string]> = [];
+  if (args.projectTitle) {
+    rows.push([t("approvals.suggest.context.project"), args.projectTitle]);
+  }
+  if (args.requesterName) {
+    rows.push([t("approvals.suggest.context.requester"), args.requesterName]);
+  }
+  if (args.requestedAt) {
+    rows.push([t("approvals.suggest.context.requested_at"), formatDateForDisplay(args.requestedAt)]);
+  }
+  // Approval status — entity row's current approval_status (typically
+  // "pending" while the modal is open, but display the requester's
+  // perspective for completeness).
+  const approvalStatus = original.approval_status as string | undefined;
+  if (approvalStatus) {
+    rows.push([
+      t("approvals.suggest.context.approval_status"),
+      t(("approvals.status." + approvalStatus) as never) || approvalStatus,
+    ]);
+  }
+
+  if (rows.length === 0) {
+    section.style.display = "none";
+    return section;
+  }
+
+  const dl = document.createElement("dl");
+  dl.className = "approval-suggest-context-grid";
+  for (const [label, value] of rows) {
+    const dt = document.createElement("dt");
+    dt.textContent = label;
+    const dd = document.createElement("dd");
+    dd.textContent = value;
+    dl.appendChild(dt);
+    dl.appendChild(dd);
+  }
+  section.appendChild(dl);
+  return section;
+}
+
+function renderNoteSection(): { section: HTMLElement; textarea: HTMLTextAreaElement } {
+  const section = document.createElement("section");
+  section.className = "approval-suggest-section approval-suggest-section--note";
+  const wrap = document.createElement("div");
+  wrap.className = "form-field approval-suggest-note";
+
+  const label = document.createElement("label");
+  label.textContent = t("approvals.suggest.note_label");
+  label.setAttribute("for", "suggest-note");
+  wrap.appendChild(label);
+
+  const textarea = document.createElement("textarea");
+  textarea.id = "suggest-note";
+  textarea.rows = 3;
+  textarea.placeholder = t("approvals.suggest.note_placeholder");
+  textarea.dataset.suggestNote = "true";
+  wrap.appendChild(textarea);
+
+  section.appendChild(wrap);
+  return { section, textarea };
+}
+
+interface BuildResult {
+  counterPayload: Record<string, unknown>;
+  note: string;
+  dirty: boolean;
+}
+
+function buildResult(
+  fieldInputs: ReadonlyArray<HTMLInputElement | HTMLTextAreaElement>,
+  noteEl: HTMLTextAreaElement,
+  original: Record<string, unknown>,
+  eventTypePicker: PickerHandle | null,
+  eventTypePickerLoaded: boolean,
+): BuildResult {
+  const counterPayload: Record<string, unknown> = {};
+  let dirty = false;
+
+  for (const el of fieldInputs) {
+    const key = el.dataset.suggestField || "";
+    const orig = el.dataset.suggestOriginal || "";
+    const inputType = el.dataset.suggestInputType || "text";
+    if (el.value === orig) continue;
+    counterPayload[key] = formatFieldForServer(el.value, inputType);
+    dirty = true;
+  }
+
+  if (eventTypePicker && eventTypePickerLoaded) {
+    const currentIDs = eventTypePicker.getIDs().slice().sort();
+    const originalIDs = ((original.event_type_ids as string[] | undefined) ?? []).slice().sort();
+    if (currentIDs.length !== originalIDs.length
+        || currentIDs.some((id, i) => id !== originalIDs[i])) {
+      counterPayload.event_type_ids = currentIDs;
+      dirty = true;
+    }
+  }
+
+  return {
+    counterPayload,
+    note: noteEl.value.trim(),
+    dirty,
+  };
+}
+
+// formatFieldForInput — convert a server-side payload value to the format
+// the <input> wants. Dates round-trip as YYYY-MM-DD; datetime-local wants
+// YYYY-MM-DDTHH:MM. Server returns ISO 8601 / RFC 3339 timestamps; we
+// trim to the local-input shape. Text passes through verbatim.
+function formatFieldForInput(v: unknown, inputType: string): string {
+  if (v == null) return "";
+  const s = String(v);
+  if (inputType === "date") {
+    if (/^\d{4}-\d{2}-\d{2}$/.test(s)) return s;
+    const m = s.match(/^(\d{4}-\d{2}-\d{2})/);
+    return m ? m[1] : s;
+  }
+  if (inputType === "datetime-local") {
+    const m = s.match(/^(\d{4}-\d{2}-\d{2})[T\s](\d{2}:\d{2})/);
+    return m ? `${m[1]}T${m[2]}` : s;
+  }
+  return s;
+}
+
+// formatFieldForServer — convert input value back to server-friendly
+// shape. Empty string means "clear this nullable field"; the server's
+// addText helper writes NULL for "". Required fields (title) reach the
+// server's non-empty CHECK on the column, which surfaces as a 400.
+function formatFieldForServer(value: string, inputType: string): unknown {
+  if (inputType === "date" || inputType === "datetime-local") {
+    return value || null;
+  }
+  return value;
+}
+
+function formatDateForDisplay(iso: string): string {
+  const d = Date.parse(iso);
+  if (isNaN(d)) return iso;
+  return new Date(d).toLocaleString();
+}

frontend/src/client/components/modal.ts

@@ -0,0 +1,200 @@
+// Unified modal primitive — t-paliad-217.
+//
+// Native <dialog>-backed. The browser handles top-layer stacking, ESC,
+// ARIA, and focus trap. We layer back-button integration and focus
+// restoration on top so the modal behaves consistently on desktop and on
+// the iPhone PWA (m's checking surface).
+//
+// API:
+//   const result = await openModal<MyResult>({
+//     title: "…",
+//     body: htmlStringOrElement,
+//     primary: { label: "Speichern", handler: (close) => { close(result); } },
+//     secondary: { label: "Abbrechen" },   // optional, defaults to "Abbrechen"
+//     size: "sm" | "md" | "lg" | "full",   // optional, defaults to "md"
+//     onClose: () => { /* … */ },
+//     classNames: "extra css classes on the <dialog>",
+//   });
+//   // result is the value passed to close(), or null if the user
+//   // dismissed via ESC / backdrop / secondary / browser back-button.
+//
+// All dismiss paths are unified: ESC, backdrop click, secondary button,
+// the always-rendered close (×) button, and the browser back-button all
+// resolve the promise with null. Programmatic close from the primary
+// handler resolves with whatever was passed.
+//
+// Migration target: call sites that currently roll their own
+// modal-overlay + ESC handler + focus management replace all of it with
+// one openModal() call. broadcast.ts and approval-edit-modal.ts are the
+// first two call sites (t-paliad-217 Slices C + D); the other ~5 legacy
+// modals migrate in follow-up PRs.
+
+import { t } from "../i18n";
+
+export interface ModalConfig<T> {
+  title: string;
+  // body can be either a pre-built HTMLElement (the caller assembled the
+  // DOM and may have local references for read-back) or an HTML string
+  // (caller is responsible for escaping). Element is preferred when the
+  // caller needs to read form state on submit.
+  body: HTMLElement | string;
+  primary: {
+    label: string;
+    handler: (close: (result: T) => void) => void | Promise<void>;
+  };
+  // secondary defaults to a Cancel button that just dismisses. Pass null
+  // explicitly to suppress (rare — primary-only modals like a confirmation
+  // toast).
+  secondary?: { label: string } | null;
+  size?: "sm" | "md" | "lg" | "full";
+  // onClose fires on EVERY dismiss path (including primary handler
+  // resolution). Use for analytics / dirty-state warnings.
+  onClose?: () => void;
+  classNames?: string;
+}
+
+// openModal returns a promise that resolves with the value passed to
+// close() inside the primary handler, or null if the user dismissed via
+// any other path. Always non-throwing — the primary handler decides
+// whether to surface errors via its own UI (e.g. inline form errors)
+// rather than rejecting the promise.
+export function openModal<T = void>(config: ModalConfig<T>): Promise<T | null> {
+  return new Promise((resolve) => {
+    // Record + restore focus to whatever was focused before the modal
+    // opened. Native <dialog> does NOT do this automatically.
+    const previouslyFocused = document.activeElement as HTMLElement | null;
+
+    const dialog = document.createElement("dialog");
+    dialog.className = ["modal", config.classNames].filter(Boolean).join(" ");
+    dialog.dataset.size = config.size ?? "md";
+
+    const header = document.createElement("header");
+    header.className = "modal__header";
+    const titleEl = document.createElement("h2");
+    titleEl.className = "modal__title";
+    titleEl.textContent = config.title;
+    header.appendChild(titleEl);
+    const closeBtn = document.createElement("button");
+    closeBtn.type = "button";
+    closeBtn.className = "modal__close";
+    closeBtn.setAttribute("aria-label", t("modal.close.label"));
+    closeBtn.textContent = "×"; // ×
+    header.appendChild(closeBtn);
+    dialog.appendChild(header);
+
+    const body = document.createElement("div");
+    body.className = "modal__body";
+    if (typeof config.body === "string") {
+      body.innerHTML = config.body;
+    } else {
+      body.appendChild(config.body);
+    }
+    dialog.appendChild(body);
+
+    const footer = document.createElement("footer");
+    footer.className = "modal__footer";
+    const secondaryCfg = config.secondary === null
+      ? null
+      : config.secondary ?? { label: t("common.cancel") };
+    let secondaryBtn: HTMLButtonElement | null = null;
+    if (secondaryCfg) {
+      secondaryBtn = document.createElement("button");
+      secondaryBtn.type = "button";
+      secondaryBtn.className = "btn btn-ghost modal__secondary";
+      secondaryBtn.textContent = secondaryCfg.label;
+      footer.appendChild(secondaryBtn);
+    }
+    const primaryBtn = document.createElement("button");
+    primaryBtn.type = "button";
+    primaryBtn.className = "btn btn-primary modal__primary";
+    primaryBtn.textContent = config.primary.label;
+    footer.appendChild(primaryBtn);
+    dialog.appendChild(footer);
+
+    document.body.appendChild(dialog);
+
+    // History integration (Q5): push a synthetic history state so the
+    // browser back-button closes the modal instead of leaving the page.
+    // We pop the state in finish() unless popstate already fired it.
+    let historyEntryActive = false;
+    try {
+      history.pushState({ paliadModalOpen: true }, "");
+      historyEntryActive = true;
+    } catch (_e) {
+      // pushState may throw in obscure embedded contexts; degrade gracefully.
+    }
+
+    // resolved guards against double-resolution (e.g. ESC fires + then a
+    // microtask-deferred primary handler also calls close).
+    let resolved = false;
+
+    const finish = (value: T | null) => {
+      if (resolved) return;
+      resolved = true;
+
+      window.removeEventListener("popstate", onPopState);
+
+      // Pop our history entry if it's still on the stack. Skip when the
+      // popstate listener already fired (otherwise we'd go back twice).
+      if (historyEntryActive) {
+        historyEntryActive = false;
+        try { history.back(); } catch (_e) { /* same fallback as pushState */ }
+      }
+
+      // Native dialog close. Use the close event's default rather than
+      // the cancel event so we don't fight the browser's own dismissal.
+      if (dialog.open) dialog.close();
+      dialog.remove();
+
+      // Restore focus to whatever the user was on before. The dialog
+      // teardown happens synchronously so the focus call lands on a
+      // live element.
+      if (previouslyFocused && document.body.contains(previouslyFocused)) {
+        previouslyFocused.focus();
+      }
+
+      config.onClose?.();
+      resolve(value);
+    };
+
+    const close = (result: T) => finish(result);
+
+    // Dismiss paths.
+    closeBtn.addEventListener("click", () => finish(null));
+    secondaryBtn?.addEventListener("click", () => finish(null));
+    dialog.addEventListener("click", (e) => {
+      // Backdrop click — only when the click landed on the dialog element
+      // itself (not on a child). Browsers report dialog.click events
+      // through the backdrop too because the backdrop is conceptually
+      // part of the dialog's box.
+      if (e.target === dialog) finish(null);
+    });
+    // <dialog>'s cancel event fires on ESC. preventDefault stops the
+    // browser's default close so we can run our finish() (history pop,
+    // focus restore, onClose, resolve).
+    dialog.addEventListener("cancel", (e) => {
+      e.preventDefault();
+      finish(null);
+    });
+    const onPopState = () => {
+      // Browser back-button. Our history entry is gone by the time this
+      // fires, so skip the history.back() in finish().
+      historyEntryActive = false;
+      finish(null);
+    };
+    window.addEventListener("popstate", onPopState);
+
+    // Primary action.
+    primaryBtn.addEventListener("click", () => {
+      const result = config.primary.handler(close);
+      // Allow async primary handlers (handler returns a promise) — we
+      // don't wait for it explicitly; the handler is responsible for
+      // calling close() when ready.
+      void result;
+    });
+
+    // Open the dialog in the top layer. showModal activates ARIA
+    // role="dialog" + aria-modal=true + focus trap + backdrop.
+    dialog.showModal();
+  });
+}

frontend/src/client/components/withdraw-warning-modal.ts

@@ -0,0 +1,149 @@
+// t-paliad-252 / m/paliad#83 — withdraw warning modal.
+//
+// Before t-paliad-252 the deadline + appointment detail pages did a
+// confirm() dialog before POSTing to /api/approval-requests/{id}/revoke.
+// For pending CREATE lifecycles that endpoint silently DELETES the
+// underlying entity row — m's "withdrawing the approval deletes the event"
+// surprise.
+//
+// This modal replaces the confirm() with three explicit paths:
+//
+//   1. Cancel                       — does nothing
+//   2. Termin bearbeiten (primary)  — opens the edit form; saving routes
+//                                     through POST /approval-requests/{id}/
+//                                     edit-entity which keeps the request
+//                                     pending and merges the new fields
+//                                     into approval_request.payload
+//   3. Endgültig zurückziehen +     — destructive; current /revoke
+//      löschen                        behaviour (delete for CREATE, revert
+//                                     for UPDATE/COMPLETE, cancel for
+//                                     DELETE-lifecycle requests)
+//
+// Built on the unified openModal() primitive (t-paliad-217 Slice A) so the
+// three-button row sits cleanly inside the body — the primitive only
+// supports one secondary action, but we paint the destructive button as a
+// separate row above the footer.
+
+import { t } from "../i18n";
+import { openModal } from "./modal";
+
+export type WithdrawAction = "edit" | "withdraw";
+
+export interface WithdrawWarningArgs {
+  // entityType drives the copy ("event" vs "appointment" labels).
+  entityType: "deadline" | "appointment";
+  // lifecycleEvent of the pending request; copy adapts (CREATE warns about
+  // deletion; UPDATE/COMPLETE warn about revert; DELETE warns about
+  // cancelling the deletion request).
+  lifecycleEvent: "create" | "update" | "complete" | "delete" | string;
+}
+
+// openWithdrawWarningModal resolves with the chosen action, or null if the
+// user dismissed via Cancel / Esc / backdrop / browser back-button.
+export async function openWithdrawWarningModal(
+  args: WithdrawWarningArgs,
+): Promise<WithdrawAction | null> {
+  const body = document.createElement("div");
+  body.className = "withdraw-warning-body";
+
+  // Lead paragraph + sub-paragraph adapt to lifecycle so the user always
+  // knows what the destructive button will actually do. The /revoke
+  // backend behaviour:
+  //   - create   → DELETE the entity (the "surprise" m flagged)
+  //   - update   → revert to pre_image
+  //   - complete → revert to pre-complete state
+  //   - delete   → cancel the delete request (entity stays alive)
+  const intro = document.createElement("p");
+  intro.className = "withdraw-warning-intro";
+  intro.textContent = leadCopyFor(args);
+  body.appendChild(intro);
+
+  const sub = document.createElement("p");
+  sub.className = "withdraw-warning-sub muted";
+  sub.textContent = subCopyFor(args);
+  body.appendChild(sub);
+
+  // The destructive button lives inside the body — the openModal primitive
+  // only exposes one secondary button slot, and we want the safe "Edit"
+  // path to be the primary CTA. Painting it in red here, separated from
+  // the footer, signals "this is the dangerous option" without competing
+  // visually with the primary CTA.
+  const destructiveRow = document.createElement("div");
+  destructiveRow.className = "withdraw-warning-destructive-row";
+  const destructiveBtn = document.createElement("button");
+  destructiveBtn.type = "button";
+  destructiveBtn.className = "btn btn-danger withdraw-warning-destructive-btn";
+  destructiveBtn.textContent = t("approvals.withdraw.destructive.label");
+  destructiveRow.appendChild(destructiveBtn);
+  body.appendChild(destructiveRow);
+
+  return new Promise<WithdrawAction | null>((resolve) => {
+    let chosen: WithdrawAction | null = null;
+
+    // The destructive button has to close the modal and return "withdraw".
+    // We need access to the modal's internal close() — fortunately openModal
+    // exposes it via the primary handler's first arg. We pass through the
+    // outer resolve and let the primary handler (Edit) own the close-fn
+    // route. For the destructive button we resolve the outer promise
+    // directly and then synthesise an ESC keypress so the modal dismisses
+    // — or, simpler, set chosen and use the secondary "Cancel" path that
+    // the modal already supports. (openModal's onClose fires on every
+    // dismiss path including the primary handler resolution.)
+    destructiveBtn.addEventListener("click", () => {
+      chosen = "withdraw";
+      // The unified openModal primitive (modal.ts) wires its dismiss path
+      // through the native <dialog>'s `cancel` event. Dispatching it on
+      // the parent <dialog> runs the same finish() → onClose → resolve
+      // sequence as ESC / backdrop. We then map the resolved `null` back
+      // to "withdraw" via the captured `chosen` in onClose below.
+      const dialogEl = body.closest("dialog");
+      dialogEl?.dispatchEvent(new Event("cancel"));
+    });
+
+    void openModal<WithdrawAction>({
+      title: t("approvals.withdraw.modal.title"),
+      body,
+      size: "md",
+      classNames: "withdraw-warning-modal",
+      primary: {
+        label: t("approvals.withdraw.primary.label"),
+        handler: (close) => {
+          chosen = "edit";
+          close("edit");
+        },
+      },
+      secondary: { label: t("approvals.withdraw.cancel") },
+      onClose: () => {
+        // Resolves whatever was chosen via the destructive button OR the
+        // primary handler. ESC / backdrop / secondary clear `chosen` to
+        // null which is the right "cancel" semantics.
+        resolve(chosen);
+      },
+    });
+  });
+}
+
+function leadCopyFor(args: WithdrawWarningArgs): string {
+  switch (args.lifecycleEvent) {
+    case "create":
+      return args.entityType === "appointment"
+        ? t("approvals.withdraw.lead.create.appointment")
+        : t("approvals.withdraw.lead.create.deadline");
+    case "delete":
+      return t("approvals.withdraw.lead.delete");
+    default:
+      // update / complete / unknown → revert semantics
+      return t("approvals.withdraw.lead.update");
+  }
+}
+
+function subCopyFor(args: WithdrawWarningArgs): string {
+  switch (args.lifecycleEvent) {
+    case "create":
+      return t("approvals.withdraw.sub.create");
+    case "delete":
+      return t("approvals.withdraw.sub.delete");
+    default:
+      return t("approvals.withdraw.sub.update");
+  }
+}

frontend/src/client/dashboard-grid.test.ts

@@ -0,0 +1,285 @@
+import { describe, expect, test } from "bun:test";
+import {
+  GRID_COLUMNS,
+  clampH,
+  clampW,
+  placeWidgets,
+  type WidgetPlacementInput,
+} from "./dashboard-grid";
+
+// Regression suite for m/paliad#70 (t-paliad-228): the post-#69 edit
+// mode produced overlapping widgets when a 2-col widget sat next to a
+// 1-col widget on the same row, when a drag swapped widgets of
+// different widths, and when a resize grew a widget into a sibling. The
+// fix moved the placement math into ./dashboard-grid + made it
+// collision-aware. These tests pin the no-overlap invariant.
+
+function spec(
+  key: string,
+  x: number | undefined,
+  y: number | undefined,
+  w: number,
+  h = 1,
+  visible = true,
+): WidgetPlacementInput {
+  return { key, visible, x, y, w, h };
+}
+
+// hasOverlap returns true if any placed pair shares a cell. O(n²) is
+// fine — layouts cap at 32 widgets and the tests stay tiny.
+function hasOverlap(rects: Map<string, { x: number; y: number; w: number; h: number }>): string | null {
+  const list = Array.from(rects.entries());
+  for (let i = 0; i < list.length; i++) {
+    const [ka, a] = list[i];
+    for (let j = i + 1; j < list.length; j++) {
+      const [kb, b] = list[j];
+      const xOverlap = a.x < b.x + b.w && b.x < a.x + a.w;
+      const yOverlap = a.y < b.y + b.h && b.y < a.y + a.h;
+      if (xOverlap && yOverlap) return `${ka} ↔ ${kb} at (${a.x},${a.y},${a.w}x${a.h}) vs (${b.x},${b.y},${b.w}x${b.h})`;
+    }
+  }
+  return null;
+}
+
+describe("placeWidgets — basic auto-flow", () => {
+  test("places two 6-wide widgets side by side on row 0", () => {
+    const out = placeWidgets([
+      spec("a", undefined, undefined, 6),
+      spec("b", undefined, undefined, 6),
+    ]);
+    expect(out.get("a")).toEqual({ x: 0, y: 0, w: 6, h: 1 });
+    expect(out.get("b")).toEqual({ x: 6, y: 0, w: 6, h: 1 });
+    expect(hasOverlap(out)).toBeNull();
+  });
+
+  test("wraps when row doesn't fit", () => {
+    const out = placeWidgets([
+      spec("a", undefined, undefined, 8),
+      spec("b", undefined, undefined, 8),
+    ]);
+    expect(out.get("a")!.y).toBe(0);
+    expect(out.get("b")!.y).toBeGreaterThan(0);
+    expect(hasOverlap(out)).toBeNull();
+  });
+
+  test("hidden widgets are skipped and reserve no cells", () => {
+    const out = placeWidgets([
+      spec("hidden", 0, 0, 12, 1, false),
+      spec("visible", undefined, undefined, 6),
+    ]);
+    expect(out.has("hidden")).toBe(false);
+    expect(out.get("visible")).toEqual({ x: 0, y: 0, w: 6, h: 1 });
+  });
+});
+
+describe("placeWidgets — explicit positions, no collision", () => {
+  test("trusts non-colliding explicit positions exactly", () => {
+    const out = placeWidgets([
+      spec("a", 0, 0, 6),
+      spec("b", 6, 0, 6),
+      spec("c", 0, 1, 12),
+    ]);
+    expect(out.get("a")).toEqual({ x: 0, y: 0, w: 6, h: 1 });
+    expect(out.get("b")).toEqual({ x: 6, y: 0, w: 6, h: 1 });
+    expect(out.get("c")).toEqual({ x: 0, y: 1, w: 12, h: 1 });
+    expect(hasOverlap(out)).toBeNull();
+  });
+});
+
+describe("placeWidgets — mixed-width collision (m/paliad#70 regression)", () => {
+  test("1-col + 2-col on same row do not overlap when both explicit", () => {
+    // Half-width left + half-width right is the canonical 'two widgets per
+    // row' layout; pre-fix this was fine but the next regression below
+    // exercises the actual bug.
+    const out = placeWidgets([
+      spec("left", 0, 0, 6),
+      spec("right", 6, 0, 6),
+    ]);
+    expect(hasOverlap(out)).toBeNull();
+  });
+
+  test("4-col + 8-col both claiming (0,0) end up non-overlapping", () => {
+    // Simulates a post-#69 layout where a 4-wide widget sits at (0, 0)
+    // and an 8-wide widget got accidentally placed at (0, 0) too (e.g.
+    // a buggy reset path or a stale spec from before #70). Placer must
+    // honour the first one's position and fit the second somewhere
+    // free — landing it on the same row at x=4 is acceptable (better
+    // density) as long as nothing overlaps.
+    const out = placeWidgets([
+      spec("first", 0, 0, 4),
+      spec("colliding", 0, 0, 8),
+    ]);
+    expect(out.get("first")).toEqual({ x: 0, y: 0, w: 4, h: 1 });
+    expect(out.get("colliding")!.w).toBe(8);
+    expect(hasOverlap(out)).toBeNull();
+  });
+
+  test("drag-drop swap of 12-wide onto 6-wide does not overlap", () => {
+    // Setup before swap:
+    //   A at (0, 0, w=12) — full width row 0
+    //   B at (0, 1, w=6)  — half row 1 left
+    //   C at (6, 1, w=6)  — half row 1 right
+    // User drags A onto B. reorderViaDnd swaps (x, y):
+    //   A.x=0, A.y=1
+    //   B.x=0, B.y=0
+    // Result must not overlap C.
+    const out = placeWidgets([
+      spec("a", 0, 1, 12),
+      spec("b", 0, 0, 6),
+      spec("c", 6, 1, 6),
+    ]);
+    expect(hasOverlap(out)).toBeNull();
+  });
+
+  test("auto-flow widget steps past explicit blocker on same row", () => {
+    // Explicit widget at (6, 0, w=6); auto-flow widget would pack into
+    // (0, 0, w=6) which is fine — but the next auto-flow widget at w=6
+    // would want (6, 0) which is taken. Placer must wrap it.
+    const out = placeWidgets([
+      spec("flow-a", undefined, undefined, 6),
+      spec("anchored", 6, 0, 6),
+      spec("flow-b", undefined, undefined, 6),
+    ]);
+    expect(out.get("flow-a")).toEqual({ x: 0, y: 0, w: 6, h: 1 });
+    expect(out.get("anchored")).toEqual({ x: 6, y: 0, w: 6, h: 1 });
+    expect(out.get("flow-b")!.y).toBeGreaterThan(0);
+    expect(hasOverlap(out)).toBeNull();
+  });
+});
+
+describe("placeWidgets — resize-grow shifts siblings", () => {
+  test("growing a 6-wide to 12-wide bumps the sibling on the same row", () => {
+    // Pre-resize state:
+    //   A at (0, 0, w=6)
+    //   B at (6, 0, w=6)
+    // User resizes A to w=12. resizeWidget() updates A.w but leaves B
+    // at (6, 0). Placer must shift B down.
+    const out = placeWidgets([
+      spec("a", 0, 0, 12),
+      spec("b", 6, 0, 6),
+    ]);
+    expect(out.get("a")).toEqual({ x: 0, y: 0, w: 12, h: 1 });
+    expect(out.get("b")!.y).toBeGreaterThan(0);
+    expect(hasOverlap(out)).toBeNull();
+  });
+
+  test("growing widget pushes only the first colliding sibling", () => {
+    // A grows to 12-wide; B and C on row 0 are both colliding. Both must
+    // move; their relative order on row 0 is preserved (B at x=0, C at
+    // x=6) on row 1.
+    const out = placeWidgets([
+      spec("a", 0, 0, 12),
+      spec("b", 0, 0, 4),
+      spec("c", 4, 0, 4),
+    ]);
+    expect(hasOverlap(out)).toBeNull();
+    expect(out.get("a")!.y).toBe(0);
+    expect(out.get("b")!.y).toBeGreaterThan(0);
+    expect(out.get("c")!.y).toBeGreaterThan(0);
+  });
+});
+
+describe("placeWidgets — explicit position overflow clamp", () => {
+  test("x+w > GRID_COLUMNS is clamped not rejected", () => {
+    // A 12-wide widget with x=6 would extend past col 11. Placer must
+    // clamp x to 0 (or wherever fits) so the widget renders inside the
+    // grid.
+    const out = placeWidgets([
+      spec("wide", 6, 0, 12),
+    ]);
+    const r = out.get("wide")!;
+    expect(r.x + r.w).toBeLessThanOrEqual(GRID_COLUMNS);
+    expect(r.w).toBe(12);
+  });
+});
+
+describe("placeWidgets — vertical (multi-row) widgets", () => {
+  test("a 2-row-tall widget reserves both rows", () => {
+    const out = placeWidgets([
+      spec("tall", 0, 0, 6, 2),
+      spec("collides-on-row-1", 0, 1, 6, 1),
+    ]);
+    expect(out.get("tall")).toEqual({ x: 0, y: 0, w: 6, h: 2 });
+    // The colliding widget must move because tall covers cols 0..5
+    // on both row 0 and row 1. The placer may shift it to the right
+    // half of row 1 (cols 6..11) or to a later row — either is fine
+    // as long as nothing overlaps.
+    const other = out.get("collides-on-row-1")!;
+    expect(other.x >= 6 || other.y >= 2).toBe(true);
+    expect(hasOverlap(out)).toBeNull();
+  });
+});
+
+describe("placeWidgets — includeHidden (edit mode)", () => {
+  test("hidden widgets are skipped by default", () => {
+    const out = placeWidgets([
+      spec("visible", 0, 0, 6),
+      spec("hidden", 0, 0, 6, 1, false),
+    ]);
+    expect(out.has("visible")).toBe(true);
+    expect(out.has("hidden")).toBe(false);
+  });
+
+  test("includeHidden:true places hidden widgets after visible ones", () => {
+    // Regression for m/paliad#73 / t-paliad-238: in edit mode hidden
+    // widgets MUST receive a placement, otherwise applyLayout leaves
+    // their inline grid-column empty and CSS Grid auto-flows them as
+    // 1×1 slivers ("super slim greyed-out column").
+    const out = placeWidgets([
+      spec("active", 0, 0, 12),
+      spec("hidden", 0, 0, 6, 1, false),
+    ], { includeHidden: true });
+    expect(out.has("hidden")).toBe(true);
+    const h = out.get("hidden")!;
+    // Must keep its requested width (6), not collapse to 1.
+    expect(h.w).toBe(6);
+    // Must land below the visible widget — never overlap or steal cells.
+    expect(h.y).toBeGreaterThanOrEqual(1);
+    expect(hasOverlap(out)).toBeNull();
+  });
+
+  test("includeHidden two-pass: visible widgets keep priority over hidden", () => {
+    // Hidden widget stored at (0, 0) shouldn't displace a visible
+    // widget that wants (0, 0). The visible pass runs first, claims
+    // (0, 0); the hidden widget is then placed wherever free — the
+    // placer happily fits it next to the visible widget on the same
+    // row if there's room. The hard invariant is just no-overlap.
+    const out = placeWidgets([
+      spec("active", 0, 0, 6),
+      spec("hidden-at-origin", 0, 0, 6, 1, false),
+    ], { includeHidden: true });
+    expect(out.get("active")).toEqual({ x: 0, y: 0, w: 6, h: 1 });
+    expect(out.has("hidden-at-origin")).toBe(true);
+    expect(hasOverlap(out)).toBeNull();
+  });
+
+  test("multiple hidden widgets all receive valid placements", () => {
+    const out = placeWidgets([
+      spec("a", 0, 0, 12),
+      spec("h1", undefined, undefined, 6, 1, false),
+      spec("h2", undefined, undefined, 6, 1, false),
+      spec("h3", undefined, undefined, 12, 1, false),
+    ], { includeHidden: true });
+    expect(out.size).toBe(4);
+    for (const r of out.values()) {
+      expect(r.w).toBeGreaterThanOrEqual(1);
+      expect(r.x + r.w).toBeLessThanOrEqual(GRID_COLUMNS);
+    }
+    expect(hasOverlap(out)).toBeNull();
+  });
+});
+
+describe("clamp helpers", () => {
+  test("clampW respects min/max bounds", () => {
+    expect(clampW(2, { min_w: 4, max_w: 12 })).toBe(4);
+    expect(clampW(20, { min_w: 4, max_w: 12 })).toBe(12);
+    expect(clampW(0, { default_w: 6 })).toBe(6);
+    expect(clampW(NaN, { default_w: 8 })).toBe(8);
+  });
+
+  test("clampH respects min/max bounds and MAX_ROW_SPAN", () => {
+    expect(clampH(0, { default_h: 2 })).toBe(2);
+    expect(clampH(99, undefined)).toBe(5); // MAX_ROW_SPAN
+    expect(clampH(1, { min_h: 3 })).toBe(3);
+  });
+});

frontend/src/client/dashboard-grid.ts

@@ -0,0 +1,264 @@
+// dashboard-grid — pure layout math for the dashboard widget grid.
+//
+// Lives outside dashboard.ts so the placement logic is importable from
+// tests without dragging in the DOM-side rendering code. The grid is a
+// 12-column CSS Grid matching internal/services/dashboard_layout_spec.go;
+// rows grow vertically as widgets are placed.
+//
+// The core invariant is no-overlap: after placeWidgets() returns, every
+// pair of widgets occupies disjoint cells. Pre-overhaul callers wrote
+// computePlacements() to trust explicit (x, y) without checking — that
+// produced visual overlap whenever a drag or resize landed a widget on
+// cells another widget already covered (m/paliad#70). The collision-
+// aware placer below shifts colliding widgets to the next free row so
+// the rendered grid never overlaps regardless of the input spec.
+
+export const GRID_COLUMNS = 12;
+export const MAX_ROW_SPAN = 5;
+
+// Hard cap on the row-scan depth in findFreeSlot. The widget cap on a
+// single layout is 32 (LayoutWidgetCap on the Go side); each row holds
+// at least one widget, so 256 rows is an order-of-magnitude buffer
+// against runaway loops on pathological inputs.
+const MAX_SCAN_ROWS = 256;
+
+export interface PlacedRect {
+  x: number;
+  y: number;
+  w: number;
+  h: number;
+}
+
+// WidgetSizeBound captures the per-widget min/max/default clamps the
+// catalog publishes. Optional fields keep callers from having to
+// synthesize zeroes when the catalog entry is missing.
+export interface WidgetSizeBound {
+  default_w?: number;
+  default_h?: number;
+  min_w?: number;
+  max_w?: number;
+  min_h?: number;
+  max_h?: number;
+}
+
+// WidgetPlacementInput is the per-widget data the placer consumes. The
+// catalog bound is optional — when missing, defaults fall back to a
+// full-width 1-row widget.
+export interface WidgetPlacementInput {
+  key: string;
+  visible: boolean;
+  x?: number;
+  y?: number;
+  w?: number;
+  h?: number;
+  bound?: WidgetSizeBound;
+}
+
+export function clampW(w: number, bound: WidgetSizeBound | undefined): number {
+  let v = Math.round(w);
+  if (!Number.isFinite(v) || v <= 0) v = bound?.default_w ?? GRID_COLUMNS;
+  v = Math.max(1, Math.min(GRID_COLUMNS, v));
+  if (bound?.min_w && v < bound.min_w) v = bound.min_w;
+  if (bound?.max_w && v > bound.max_w) v = bound.max_w;
+  return v;
+}
+
+export function clampH(h: number, bound: WidgetSizeBound | undefined): number {
+  let v = Math.round(h);
+  if (!Number.isFinite(v) || v <= 0) v = bound?.default_h ?? 1;
+  v = Math.max(1, Math.min(MAX_ROW_SPAN, v));
+  if (bound?.min_h && v < bound.min_h) v = bound.min_h;
+  if (bound?.max_h && v > bound.max_h) v = bound.max_h;
+  return v;
+}
+
+// Occupancy bitmap: one row → Uint8Array of GRID_COLUMNS bits. Rows are
+// created lazily so the map only stores rows the layout actually
+// reaches. Cell value 1 = occupied.
+class Occupancy {
+  private rows = new Map<number, Uint8Array>();
+
+  row(y: number): Uint8Array {
+    let r = this.rows.get(y);
+    if (!r) {
+      r = new Uint8Array(GRID_COLUMNS);
+      this.rows.set(y, r);
+    }
+    return r;
+  }
+
+  free(x: number, y: number, w: number, h: number): boolean {
+    if (x < 0 || y < 0 || x + w > GRID_COLUMNS) return false;
+    for (let yy = y; yy < y + h; yy++) {
+      const row = this.row(yy);
+      for (let xx = x; xx < x + w; xx++) {
+        if (row[xx]) return false;
+      }
+    }
+    return true;
+  }
+
+  mark(x: number, y: number, w: number, h: number): void {
+    for (let yy = y; yy < y + h; yy++) {
+      const row = this.row(yy);
+      for (let xx = x; xx < x + w; xx++) row[xx] = 1;
+    }
+  }
+}
+
+// findFreeSlot scans for the first (x, y) where a w×h block fits without
+// collision, starting at row startY. At each row preferX is tried first
+// — that keeps a widget close to its requested column when only the row
+// is blocked. Falls back to left-to-right scan within the row, then to
+// the next row. Caller guarantees w ≤ GRID_COLUMNS.
+function findFreeSlot(
+  occ: Occupancy,
+  startY: number,
+  w: number,
+  h: number,
+  preferX: number,
+): { x: number; y: number } {
+  for (let y = startY; y < startY + MAX_SCAN_ROWS; y++) {
+    if (preferX >= 0 && preferX + w <= GRID_COLUMNS && occ.free(preferX, y, w, h)) {
+      return { x: preferX, y };
+    }
+    for (let x = 0; x + w <= GRID_COLUMNS; x++) {
+      if (x === preferX) continue;
+      if (occ.free(x, y, w, h)) return { x, y };
+    }
+  }
+  // Pathological fallback — caller's widget cap (32) makes this
+  // unreachable in practice. Snap to the bottom-left so the widget at
+  // least renders somewhere visible instead of vanishing.
+  return { x: 0, y: startY + MAX_SCAN_ROWS };
+}
+
+// PlaceOptions tunes the placer for the caller's render-vs-persist
+// needs.
+export interface PlaceOptions {
+  // When true, hidden widgets are placed too — for edit-mode rendering
+  // where the user can see + un-hide them inline. The two-pass order
+  // (visible first, then hidden) guarantees hidden widgets never
+  // displace visible ones: they get whatever cells are left below the
+  // active layout. Default false matches view-mode behaviour and the
+  // persistence path (materializePositions) where hidden widgets
+  // retain their stored coordinates instead of being repacked.
+  //
+  // Without this option, hidden widgets in edit mode were left without
+  // an explicit grid-column inline style by applyLayout(), so CSS Grid
+  // auto-flowed them into the next free cell at 1×1 — the "super slim
+  // greyed-out column" symptom of m/paliad#73 / t-paliad-238.
+  includeHidden?: boolean;
+}
+
+// placeWidgets assigns no-overlap grid coordinates to widgets. By
+// default only visible widgets receive placements; pass
+// {includeHidden:true} to also place hidden widgets after the visible
+// pass (used by applyLayout in edit mode).
+//
+// Algorithm — per pass:
+//   1. Clamp w/h against catalog bounds.
+//   2. If the spec carries explicit x and y, try that slot. On a
+//      collision, search downward starting at the requested y for the
+//      first free w×h block (preferring the requested x).
+//   3. If only x is explicit, search from y=0 at that x.
+//   4. Otherwise auto-flow: pack left-to-right under a running cursor;
+//      when the row doesn't fit or is blocked by an explicitly-placed
+//      widget, wrap to the next free row.
+//
+// The mixed-spec case (some widgets explicit, others auto-flow) is the
+// real-world layout — placing the explicit widgets first would change
+// the visual order, so we keep input order and let auto-flow widgets
+// step around any explicit blockers via the same collision search.
+//
+// Two-pass behaviour for hidden widgets: the visible pass owns its
+// own auto-flow cursor; the hidden pass continues from where the
+// visible pass left off so the hidden widgets stack right under the
+// active layout. The shared Occupancy bitmap guarantees the second
+// pass can never overlap a placed visible widget.
+export function placeWidgets(
+  widgets: WidgetPlacementInput[],
+  options: PlaceOptions = {},
+): Map<string, PlacedRect> {
+  const out = new Map<string, PlacedRect>();
+  const occ = new Occupancy();
+
+  // Auto-flow cursor — advances as we place flowed widgets. cursorY
+  // tracks the row currently being filled; rowMaxH is the tallest
+  // widget in that row so wrapping advances past it (not just past the
+  // new widget's height — that would let taller previous neighbours
+  // overlap into the wrap row).
+  let cursorX = 0;
+  let cursorY = 0;
+  let rowMaxH = 0;
+
+  const placeOne = (w: WidgetPlacementInput): void => {
+    const dw = clampW(w.w ?? w.bound?.default_w ?? GRID_COLUMNS, w.bound);
+    const dh = clampH(w.h ?? w.bound?.default_h ?? 1, w.bound);
+
+    const hasX = typeof w.x === "number";
+    const hasY = typeof w.y === "number";
+    let placed: { x: number; y: number };
+
+    if (hasX && hasY) {
+      // Clamp x so the widget never overflows the right edge — drag/
+      // resize gestures can produce x+w > GRID_COLUMNS otherwise.
+      const prefX = Math.max(0, Math.min(GRID_COLUMNS - dw, w.x as number));
+      const prefY = Math.max(0, w.y as number);
+      if (occ.free(prefX, prefY, dw, dh)) {
+        placed = { x: prefX, y: prefY };
+      } else {
+        placed = findFreeSlot(occ, prefY, dw, dh, prefX);
+      }
+    } else if (hasX) {
+      const prefX = Math.max(0, Math.min(GRID_COLUMNS - dw, w.x as number));
+      placed = findFreeSlot(occ, 0, dw, dh, prefX);
+    } else {
+      // Auto-flow. Wrap the cursor when the widget wouldn't fit in the
+      // remaining columns of the current row, then ask findFreeSlot to
+      // honour the cursor's preferred (x, y) — that lets it step past
+      // any explicit widget that already claimed cells under the
+      // cursor.
+      if (cursorX + dw > GRID_COLUMNS) {
+        cursorY += rowMaxH || 1;
+        cursorX = 0;
+        rowMaxH = 0;
+      }
+      placed = findFreeSlot(occ, cursorY, dw, dh, cursorX);
+      if (placed.y > cursorY) {
+        // Wrap was forced by a collision deeper than the current row.
+        cursorY = placed.y;
+        rowMaxH = 0;
+      }
+      cursorX = placed.x + dw;
+      if (dh > rowMaxH) rowMaxH = dh;
+    }
+
+    occ.mark(placed.x, placed.y, dw, dh);
+    out.set(w.key, { x: placed.x, y: placed.y, w: dw, h: dh });
+  };
+
+  // Pass 1: visible widgets. They own the active layout.
+  for (const w of widgets) {
+    if (!w.visible) continue;
+    placeOne(w);
+  }
+
+  // Pass 2: hidden widgets (edit-mode only). Wrap the cursor to the
+  // start of the next row before the second pass so the hidden tray
+  // visually separates from the active layout — even if the last
+  // visible widget left half a row open.
+  if (options.includeHidden) {
+    if (cursorX > 0) {
+      cursorY += rowMaxH || 1;
+      cursorX = 0;
+      rowMaxH = 0;
+    }
+    for (const w of widgets) {
+      if (w.visible) continue;
+      placeOne(w);
+    }
+  }
+
+  return out;
+}

frontend/src/client/date-range-picker-pure.test.ts

@@ -0,0 +1,289 @@
+// Unit tests for the date-range picker's pure helpers (t-paliad-248).
+// Run with `bun test`.
+
+import { test, expect, describe } from "bun:test";
+import {
+  horizonBounds,
+  isValidHorizon,
+  isValidISODate,
+  validateCustomRange,
+  parseURL,
+  serializeURL,
+  isDefault,
+  ALL_HORIZONS,
+  PAST_HORIZONS,
+  NEXT_HORIZONS,
+  type TimeHorizon,
+  type TimeSpec,
+} from "./date-range-picker-pure";
+
+// Anchor the clock so day-arithmetic assertions don't drift with the
+// wall clock. 2026-05-25 00:00 UTC matches the Go-side bounds test.
+const NOW = new Date(Date.UTC(2026, 4, 25));
+const DAY = (offsetDays: number): Date =>
+  new Date(NOW.getTime() + offsetDays * 86_400_000);
+
+describe("ALL_HORIZONS / PAST / NEXT registries", () => {
+  test("registries sum to a known total without overlap", () => {
+    // 6 past + 6 next + any + custom = 14 fan chips (custom is the
+    // trailing entry in ALL_HORIZONS; `all` is intentionally absent —
+    // surfaces don't render the legacy bidirectional-unbounded chip).
+    expect(ALL_HORIZONS.length).toBe(14);
+    expect(PAST_HORIZONS.length).toBe(6);
+    expect(NEXT_HORIZONS.length).toBe(6);
+    expect(new Set(ALL_HORIZONS).size).toBe(ALL_HORIZONS.length);
+  });
+
+  test("PAST_HORIZONS are all past_*", () => {
+    for (const h of PAST_HORIZONS) {
+      expect(h.startsWith("past_")).toBe(true);
+    }
+  });
+
+  test("NEXT_HORIZONS are all next_*", () => {
+    for (const h of NEXT_HORIZONS) {
+      expect(h.startsWith("next_")).toBe(true);
+    }
+  });
+
+  test("ALL_HORIZONS ends with custom and contains any in the middle", () => {
+    expect(ALL_HORIZONS.at(-1)).toBe("custom");
+    expect(ALL_HORIZONS).toContain("any");
+  });
+});
+
+describe("horizonBounds", () => {
+  test("future fan: bounds anchor at today, extend forward", () => {
+    expect(horizonBounds("next_1d", NOW)).toEqual({ from: DAY(0),  to: DAY(1) });
+    expect(horizonBounds("next_7d", NOW)).toEqual({ from: DAY(0),  to: DAY(7) });
+    expect(horizonBounds("next_14d", NOW)).toEqual({ from: DAY(0), to: DAY(14) });
+    expect(horizonBounds("next_30d", NOW)).toEqual({ from: DAY(0), to: DAY(30) });
+    expect(horizonBounds("next_90d", NOW)).toEqual({ from: DAY(0), to: DAY(90) });
+  });
+
+  test("past fan: bounds extend back, upper bound is tomorrow (exclusive end-of-today)", () => {
+    expect(horizonBounds("past_1d",  NOW)).toEqual({ from: DAY(-1),  to: DAY(1) });
+    expect(horizonBounds("past_7d",  NOW)).toEqual({ from: DAY(-7),  to: DAY(1) });
+    expect(horizonBounds("past_14d", NOW)).toEqual({ from: DAY(-14), to: DAY(1) });
+    expect(horizonBounds("past_30d", NOW)).toEqual({ from: DAY(-30), to: DAY(1) });
+    expect(horizonBounds("past_90d", NOW)).toEqual({ from: DAY(-90), to: DAY(1) });
+  });
+
+  test("next_all is one-sided: from=today, to undefined", () => {
+    const b = horizonBounds("next_all", NOW);
+    expect(b.from).toEqual(DAY(0));
+    expect(b.to).toBeUndefined();
+  });
+
+  test("past_all is one-sided: from undefined, to=tomorrow", () => {
+    const b = horizonBounds("past_all", NOW);
+    expect(b.from).toBeUndefined();
+    expect(b.to).toEqual(DAY(1));
+  });
+
+  test("any / all / custom: both bounds undefined", () => {
+    expect(horizonBounds("any",    NOW)).toEqual({});
+    expect(horizonBounds("all",    NOW)).toEqual({});
+    expect(horizonBounds("custom", NOW)).toEqual({});
+  });
+
+  test("bounds anchor on UTC start-of-day regardless of input clock time", () => {
+    const nowAfternoon = new Date(Date.UTC(2026, 4, 25, 14, 37, 0));
+    const nowMidnight = new Date(Date.UTC(2026, 4, 25, 0, 0, 0));
+    expect(horizonBounds("past_7d", nowAfternoon)).toEqual(horizonBounds("past_7d", nowMidnight));
+  });
+});
+
+describe("isValidHorizon", () => {
+  test("accepts every entry in ALL_HORIZONS plus 'all' (legacy)", () => {
+    for (const h of ALL_HORIZONS) {
+      expect(isValidHorizon(h)).toBe(true);
+    }
+    expect(isValidHorizon("all")).toBe(true);
+  });
+
+  test("rejects unknown strings, numbers, undefined, null", () => {
+    expect(isValidHorizon("next_5d")).toBe(false);
+    expect(isValidHorizon("past_100d")).toBe(false);
+    expect(isValidHorizon("")).toBe(false);
+    expect(isValidHorizon(7)).toBe(false);
+    expect(isValidHorizon(undefined)).toBe(false);
+    expect(isValidHorizon(null)).toBe(false);
+  });
+});
+
+describe("isValidISODate", () => {
+  test("accepts valid YYYY-MM-DD", () => {
+    expect(isValidISODate("2026-05-25")).toBe(true);
+    expect(isValidISODate("2026-12-31")).toBe(true);
+    expect(isValidISODate("2024-02-29")).toBe(true);
+  });
+
+  test("rejects shape mismatches", () => {
+    expect(isValidISODate("2026/05/25")).toBe(false);
+    expect(isValidISODate("25.05.2026")).toBe(false);
+    expect(isValidISODate("2026-5-25")).toBe(false);
+    expect(isValidISODate("")).toBe(false);
+    expect(isValidISODate(undefined)).toBe(false);
+  });
+
+  test("rejects calendar-impossible dates (Date.parse silently rolls over)", () => {
+    expect(isValidISODate("2026-02-30")).toBe(false);
+    expect(isValidISODate("2026-13-01")).toBe(false);
+    expect(isValidISODate("2026-04-31")).toBe(false);
+  });
+
+  test("rejects 2025-02-29 (non-leap February)", () => {
+    expect(isValidISODate("2025-02-29")).toBe(false);
+  });
+});
+
+describe("validateCustomRange", () => {
+  test("requires both bounds present and valid", () => {
+    expect(validateCustomRange(undefined, undefined)).toBe("date_range.custom.invalid_missing");
+    expect(validateCustomRange("2026-05-25", undefined)).toBe("date_range.custom.invalid_missing");
+    expect(validateCustomRange(undefined, "2026-05-25")).toBe("date_range.custom.invalid_missing");
+  });
+
+  test("rejects malformed dates with format error", () => {
+    expect(validateCustomRange("bogus", "2026-05-25")).toBe("date_range.custom.invalid_format");
+    expect(validateCustomRange("2026-13-01", "2026-12-31")).toBe("date_range.custom.invalid_format");
+  });
+
+  test("rejects to <= from with invalid error", () => {
+    expect(validateCustomRange("2026-05-25", "2026-05-25")).toBe("date_range.custom.invalid");
+    expect(validateCustomRange("2026-05-25", "2026-05-24")).toBe("date_range.custom.invalid");
+  });
+
+  test("accepts strictly-ordered valid pair", () => {
+    expect(validateCustomRange("2026-05-25", "2026-05-26")).toBeNull();
+    expect(validateCustomRange("2026-01-01", "2026-12-31")).toBeNull();
+  });
+});
+
+describe("parseURL", () => {
+  test("missing horizon yields contract default", () => {
+    expect(parseURL(new URLSearchParams(""))).toEqual({ horizon: "any" });
+    expect(parseURL(new URLSearchParams(""), { default: "next_30d" })).toEqual({ horizon: "next_30d" });
+  });
+
+  test("unknown horizon falls back to default, doesn't throw", () => {
+    expect(parseURL(new URLSearchParams("horizon=mystery"), { default: "next_7d" }))
+      .toEqual({ horizon: "next_7d" });
+  });
+
+  test("every fan horizon round-trips on a fresh URLSearchParams", () => {
+    for (const h of ALL_HORIZONS) {
+      if (h === "custom") continue;
+      const params = new URLSearchParams(`horizon=${h}`);
+      expect(parseURL(params)).toEqual({ horizon: h });
+    }
+  });
+
+  test("custom horizon reads from+to", () => {
+    const params = new URLSearchParams("horizon=custom&horizon_from=2026-03-15&horizon_to=2026-04-30");
+    expect(parseURL(params)).toEqual({
+      horizon: "custom",
+      from: "2026-03-15",
+      to: "2026-04-30",
+    });
+  });
+
+  test("custom with malformed dates falls back to default rather than half-state", () => {
+    const params = new URLSearchParams("horizon=custom&horizon_from=2026-99-99&horizon_to=2026-04-30");
+    expect(parseURL(params, { default: "next_30d" })).toEqual({ horizon: "next_30d" });
+  });
+
+  test("custom with from>=to falls back", () => {
+    const params = new URLSearchParams("horizon=custom&horizon_from=2026-05-25&horizon_to=2026-05-25");
+    expect(parseURL(params)).toEqual({ horizon: "any" });
+  });
+
+  test("custom URL key override", () => {
+    const params = new URLSearchParams("range=past_30d");
+    expect(parseURL(params, { key: "range" })).toEqual({ horizon: "past_30d" });
+    expect(parseURL(params)).toEqual({ horizon: "any" }); // default `horizon` key absent
+  });
+});
+
+describe("serializeURL", () => {
+  test("default horizon is omitted (canonical URL stays short)", () => {
+    const params = new URLSearchParams();
+    serializeURL({ horizon: "any" }, params);
+    expect(params.toString()).toBe("");
+  });
+
+  test("explicit default param removed when value matches default", () => {
+    const params = new URLSearchParams("horizon=past_30d&other=keep");
+    serializeURL({ horizon: "past_30d" }, params, { default: "past_30d" });
+    expect(params.toString()).toBe("other=keep");
+  });
+
+  test("non-default horizon is written", () => {
+    const params = new URLSearchParams("other=keep");
+    serializeURL({ horizon: "next_7d" }, params);
+    expect(params.toString()).toBe("other=keep&horizon=next_7d");
+  });
+
+  test("custom writes horizon+from+to", () => {
+    const params = new URLSearchParams();
+    serializeURL({ horizon: "custom", from: "2026-03-15", to: "2026-04-30" }, params);
+    expect(params.toString()).toBe("horizon=custom&horizon_from=2026-03-15&horizon_to=2026-04-30");
+  });
+
+  test("custom partial bounds: from/to are written individually", () => {
+    const params = new URLSearchParams();
+    serializeURL({ horizon: "custom", from: "2026-03-15" }, params);
+    expect(params.toString()).toBe("horizon=custom&horizon_from=2026-03-15");
+  });
+
+  test("stale params cleared on re-serialize", () => {
+    const params = new URLSearchParams("horizon=custom&horizon_from=2026-03-15&horizon_to=2026-04-30&other=keep");
+    serializeURL({ horizon: "past_30d" }, params);
+    expect(params.toString()).toBe("other=keep&horizon=past_30d");
+    // Stale from/to must be gone.
+    expect(params.has("horizon_from")).toBe(false);
+    expect(params.has("horizon_to")).toBe(false);
+  });
+
+  test("key override propagates to from/to", () => {
+    const params = new URLSearchParams();
+    serializeURL({ horizon: "custom", from: "2026-03-15", to: "2026-04-30" }, params, { key: "range" });
+    expect(params.toString()).toBe("range=custom&range_from=2026-03-15&range_to=2026-04-30");
+  });
+
+  test("URL round-trips through parse → serialize → parse", () => {
+    const specs: TimeSpec[] = [
+      { horizon: "any" },
+      { horizon: "next_7d" },
+      { horizon: "past_all" },
+      { horizon: "next_all" },
+      { horizon: "custom", from: "2026-03-15", to: "2026-04-30" },
+    ];
+    for (const spec of specs) {
+      const params = new URLSearchParams();
+      serializeURL(spec, params);
+      expect(parseURL(params)).toEqual(spec);
+    }
+  });
+});
+
+describe("isDefault", () => {
+  test("true when horizon matches default exactly", () => {
+    expect(isDefault({ horizon: "any" }, "any")).toBe(true);
+    expect(isDefault({ horizon: "next_30d" }, "next_30d")).toBe(true);
+  });
+
+  test("false when horizon differs", () => {
+    expect(isDefault({ horizon: "past_7d" }, "any")).toBe(false);
+    expect(isDefault({ horizon: "next_30d" }, "next_7d")).toBe(false);
+  });
+
+  test("custom is never default — even when bounds match", () => {
+    // No surface treats "custom" as the natural default, so any custom
+    // selection IS user-driven and the closed button must surface
+    // the non-default indicator.
+    expect(isDefault({ horizon: "custom", from: "2026-01-01", to: "2026-12-31" }, "custom" as TimeHorizon))
+      .toBe(false);
+  });
+});

frontend/src/client/date-range-picker-pure.ts

@@ -0,0 +1,292 @@
+// date-range-picker-pure.ts — pure helpers for the symmetric date-range
+// picker (t-paliad-248). No DOM access; runnable under `bun test`. The
+// picker's boot client (date-range-picker.ts) drives the popover, but
+// every interesting decision — what does "Letzte 7 Tage" mean today,
+// what URL params should land, when is a custom range valid — lives
+// here so it can be tested without a browser.
+//
+// The Go side (internal/services/view_service.go:computeViewSpecBounds)
+// is the canonical materializer; horizonBounds() below MUST stay in
+// step with it. The bounds test in pure-tests pins the shape so a
+// divergent change to one side breaks the assertions on the other.
+
+import type { I18nKey } from "../i18n-keys";
+
+/**
+ * TimeHorizon — the full 14-value union the symmetric picker can emit.
+ * Mirrors `internal/services/filter_spec.go` TimeHorizon.
+ *
+ * The fan chips: 6 past + 6 next + the ALLES centre (`any`) + custom.
+ * `all` is the legacy bidirectional-unbounded value, gated to
+ * scope=explicit by the validator (Q26); the picker doesn't surface it
+ * but parseURL accepts it for back-compat with saved Custom Views.
+ */
+export type TimeHorizon =
+  | "next_1d" | "next_7d" | "next_14d" | "next_30d" | "next_90d" | "next_all"
+  | "past_1d" | "past_7d" | "past_14d" | "past_30d" | "past_90d" | "past_all"
+  | "any" | "all" | "custom";
+
+/**
+ * TimeSpec — the wire shape mirrored from the Go FilterSpec.TimeSpec.
+ * `from`/`to` are ISO YYYY-MM-DD strings — UTC dates, not timestamps.
+ * Times-of-day intentionally absent from the picker's contract.
+ */
+export interface TimeSpec {
+  horizon: TimeHorizon;
+  from?: string;
+  to?: string;
+}
+
+/**
+ * The full list of horizon values the picker is willing to render
+ * as chips. Order is the picker's reading order — past edge → past
+ * → ALLES → next → next edge, with `custom` last because it lives
+ * below the chip rows in the popover, not in the row itself.
+ */
+export const ALL_HORIZONS: readonly TimeHorizon[] = [
+  "past_all",
+  "past_90d",
+  "past_30d",
+  "past_14d",
+  "past_7d",
+  "past_1d",
+  "any",
+  "next_1d",
+  "next_7d",
+  "next_14d",
+  "next_30d",
+  "next_90d",
+  "next_all",
+  "custom",
+];
+
+// Strict-validity set. Includes the legacy bidirectional-unbounded `all`
+// horizon so a saved Custom View JSON ({"horizon":"all", …}) deserializes
+// without falling back to the surface default. The picker UI itself
+// doesn't surface a chip for `all` — it's read in, kept as state, but
+// the chip the user sees light up is `any` (the centre ALLES button).
+const ALL_HORIZONS_SET: ReadonlySet<string> = new Set([...ALL_HORIZONS, "all"]);
+
+/**
+ * Past chips, in reading order (outermost → innermost). The picker
+ * renders this left-to-right in the popover's past fan.
+ */
+export const PAST_HORIZONS: readonly TimeHorizon[] = [
+  "past_all",
+  "past_90d",
+  "past_30d",
+  "past_14d",
+  "past_7d",
+  "past_1d",
+];
+
+/**
+ * Future chips, in reading order (innermost → outermost). The picker
+ * renders this left-to-right in the popover's future fan.
+ */
+export const NEXT_HORIZONS: readonly TimeHorizon[] = [
+  "next_1d",
+  "next_7d",
+  "next_14d",
+  "next_30d",
+  "next_90d",
+  "next_all",
+];
+
+/**
+ * The i18n key for the closed-button label and chip text of every
+ * horizon. Lives here (not in the TSX) so a single dictionary lookup
+ * sites can hand back a translated string at any point.
+ */
+export const HORIZON_LABEL_KEY: Record<TimeHorizon, I18nKey> = {
+  past_all: "date_range.horizon.past_all",
+  past_90d: "date_range.horizon.past_90d",
+  past_30d: "date_range.horizon.past_30d",
+  past_14d: "date_range.horizon.past_14d",
+  past_7d:  "date_range.horizon.past_7d",
+  past_1d:  "date_range.horizon.past_1d",
+  any:      "date_range.horizon.any",
+  next_1d:  "date_range.horizon.next_1d",
+  next_7d:  "date_range.horizon.next_7d",
+  next_14d: "date_range.horizon.next_14d",
+  next_30d: "date_range.horizon.next_30d",
+  next_90d: "date_range.horizon.next_90d",
+  next_all: "date_range.horizon.next_all",
+  all:      "date_range.horizon.any", // legacy alias — surfaces "Alles" in the closed label
+  custom:   "date_range.horizon.custom",
+};
+
+/**
+ * Bounds for a given horizon, anchored at `now`. Pure function: the
+ * caller passes the clock so tests can pin a specific day without
+ * mocking Date. Bounds are UTC dates; the `to` bound is exclusive
+ * (start-of-day-after) so "past 7d" includes today.
+ *
+ * Returns `{}` for `any` / `all` / `custom` — the picker's surface
+ * lifts the from/to out of TimeSpec directly when horizon === custom,
+ * and treats unbounded values as "no narrowing in that direction".
+ */
+export function horizonBounds(
+  horizon: TimeHorizon,
+  now: Date,
+): { from?: Date; to?: Date } {
+  const day = new Date(Date.UTC(
+    now.getUTCFullYear(),
+    now.getUTCMonth(),
+    now.getUTCDate(),
+  ));
+  const offset = (days: number): Date =>
+    new Date(day.getTime() + days * 86_400_000);
+
+  switch (horizon) {
+    case "past_1d":  return { from: offset(-1),  to: offset(1) };
+    case "past_7d":  return { from: offset(-7),  to: offset(1) };
+    case "past_14d": return { from: offset(-14), to: offset(1) };
+    case "past_30d": return { from: offset(-30), to: offset(1) };
+    case "past_90d": return { from: offset(-90), to: offset(1) };
+    case "past_all": return {                    to: offset(1) };
+    case "next_1d":  return { from: day,         to: offset(1) };
+    case "next_7d":  return { from: day,         to: offset(7) };
+    case "next_14d": return { from: day,         to: offset(14) };
+    case "next_30d": return { from: day,         to: offset(30) };
+    case "next_90d": return { from: day,         to: offset(90) };
+    case "next_all": return { from: day                       };
+    case "any":
+    case "all":
+    case "custom":
+      return {};
+  }
+}
+
+/**
+ * isValidHorizon — narrows an unknown string to a TimeHorizon, used
+ * by parseURL and by surface-side URL alias adapters.
+ */
+export function isValidHorizon(s: unknown): s is TimeHorizon {
+  return typeof s === "string" && ALL_HORIZONS_SET.has(s);
+}
+
+const ISO_DATE_RE = /^\d{4}-\d{2}-\d{2}$/;
+
+/**
+ * isValidISODate — `YYYY-MM-DD` shape check plus a real-date validity
+ * check (rejects 2026-02-30). Doesn't enforce timezone or floor at any
+ * particular date.
+ */
+export function isValidISODate(s: unknown): s is string {
+  if (typeof s !== "string" || !ISO_DATE_RE.test(s)) return false;
+  const ms = Date.parse(`${s}T00:00:00Z`);
+  if (Number.isNaN(ms)) return false;
+  // Reject 2026-02-30 etc. — Date.parse accepts those by rolling over.
+  return new Date(ms).toISOString().slice(0, 10) === s;
+}
+
+/**
+ * Validate a custom range. Returns null on success, an i18n key
+ * pointing at the error message on failure.
+ *
+ * Rules:
+ *   - Both `from` and `to` must be valid ISO YYYY-MM-DD.
+ *   - `to` must be strictly after `from` (single-day ranges use
+ *     `from=2026-05-25&to=2026-05-26`, NOT `from=to=2026-05-25`).
+ */
+export function validateCustomRange(
+  from: string | undefined,
+  to: string | undefined,
+): I18nKey | null {
+  if (!from || !to) return "date_range.custom.invalid_missing";
+  if (!isValidISODate(from) || !isValidISODate(to)) return "date_range.custom.invalid_format";
+  if (Date.parse(`${from}T00:00:00Z`) >= Date.parse(`${to}T00:00:00Z`)) {
+    return "date_range.custom.invalid";
+  }
+  return null;
+}
+
+/**
+ * URLContract — the picker's stable URL serialization. Surfaces can
+ * override the param name via `key` so two pickers on the same page
+ * (rare) don't collide.
+ */
+export interface URLContract {
+  /** Base param name, defaults to "horizon". */
+  key?: string;
+  /** Default value omitted from URL (matches surface's natural default). */
+  default?: TimeHorizon;
+}
+
+/**
+ * parseURL — reads a URL search-params object into a TimeSpec.
+ *
+ *   ?horizon=past_30d                       → {horizon:"past_30d"}
+ *   ?horizon=custom&from=2026-03-15&to=…    → {horizon:"custom",from,to}
+ *   (no params)                             → {horizon: contract.default ?? "any"}
+ *
+ * Unknown / malformed values fall back to the default. Out-of-shape
+ * custom dates clamp to {horizon: default} — the picker never lands
+ * in a half-custom state from a URL.
+ */
+export function parseURL(
+  params: URLSearchParams,
+  contract: URLContract = {},
+): TimeSpec {
+  const key = contract.key ?? "horizon";
+  const fallback: TimeHorizon = contract.default ?? "any";
+
+  const raw = params.get(key);
+  if (raw === null) return { horizon: fallback };
+  if (!isValidHorizon(raw)) return { horizon: fallback };
+  if (raw !== "custom") return { horizon: raw };
+
+  const from = params.get(`${key}_from`) ?? undefined;
+  const to = params.get(`${key}_to`) ?? undefined;
+  if (validateCustomRange(from, to) !== null) {
+    return { horizon: fallback };
+  }
+  return { horizon: "custom", from, to };
+}
+
+/**
+ * serializeURL — writes a TimeSpec into the URL search-params object,
+ * mutating the passed-in instance. Values equal to the surface
+ * default are OMITTED — the canonical URL stays short.
+ *
+ * Always deletes `horizon`, `<key>_from`, `<key>_to` first so a
+ * re-serialise after the picker reverts to default cleans up rather
+ * than accumulating stale entries.
+ */
+export function serializeURL(
+  spec: TimeSpec,
+  params: URLSearchParams,
+  contract: URLContract = {},
+): void {
+  const key = contract.key ?? "horizon";
+  const fromKey = `${key}_from`;
+  const toKey = `${key}_to`;
+
+  params.delete(key);
+  params.delete(fromKey);
+  params.delete(toKey);
+
+  if (spec.horizon === (contract.default ?? "any") && spec.horizon !== "custom") {
+    return;
+  }
+
+  if (spec.horizon === "custom") {
+    params.set(key, "custom");
+    if (spec.from) params.set(fromKey, spec.from);
+    if (spec.to) params.set(toKey, spec.to);
+    return;
+  }
+
+  params.set(key, spec.horizon);
+}
+
+/**
+ * isDefault — used by surfaces to decide whether to render the
+ * "value is non-default" dot on the closed button.
+ */
+export function isDefault(spec: TimeSpec, defaultHorizon: TimeHorizon): boolean {
+  if (spec.horizon !== defaultHorizon) return false;
+  if (spec.horizon === "custom") return false;
+  return true;
+}

frontend/src/client/date-range-picker.ts

@@ -0,0 +1,470 @@
+// date-range-picker.ts — boot client + DOM mount for the symmetric
+// date-range picker (t-paliad-248). The picker is a controlled
+// component: callers pass `value` + `onChange`, the component renders
+// the trigger button + popover scaffold, the popover materialises a
+// chip row and (when "Anpassen" is picked) an inline date-pair editor.
+//
+// The picker reuses the existing `.agenda-chip` styling for chips and
+// the `.multi-panel` popover pattern (auto-positioned under a
+// `.multi-anchor` wrapper). Both patterns are battle-tested by the
+// filter-bar + multi-select widgets — no new design tokens, no new
+// dark-mode contrast risk.
+
+import { t } from "./i18n";
+import {
+  ALL_HORIZONS,
+  HORIZON_LABEL_KEY,
+  NEXT_HORIZONS,
+  PAST_HORIZONS,
+  isDefault,
+  isValidISODate,
+  validateCustomRange,
+  type TimeHorizon,
+  type TimeSpec,
+} from "./date-range-picker-pure";
+
+export interface MountOpts {
+  /** Current value. The picker is fully controlled. */
+  value: TimeSpec;
+  /** Fired on every committed change (chip click or Anwenden). */
+  onChange(next: TimeSpec): void;
+  /**
+   * Which horizon constitutes the "default" for this surface. Used
+   * for the non-default indicator dot. Defaults to `"any"`.
+   */
+  defaultHorizon?: TimeHorizon;
+  /**
+   * Which chips to render. Order is preserved. Defaults to the full
+   * 14-chip fan from ALL_HORIZONS.
+   */
+  presets?: readonly TimeHorizon[];
+  /**
+   * Stable surface tag — feeds into the `data-testid` on every DOM
+   * node the picker creates so tests can scope. Example: "agenda",
+   * "filter-bar.time", "audit-log".
+   */
+  surface: string;
+  /**
+   * Optional prefix for the closed-button label. The label always
+   * starts with the resolved horizon name (e.g. "Letzte 30 Tage").
+   * Surfaces that want a heading prefix ("Zeitraum: Letzte 30 Tage")
+   * pass it here.
+   */
+  labelPrefix?: string;
+}
+
+export interface PickerHandle {
+  /** Root element — append to the host container. */
+  element: HTMLElement;
+  /** Read the current value (may have been edited via Anpassen). */
+  getValue(): TimeSpec;
+  /** Update the value from the host (e.g. after URL change). */
+  setValue(next: TimeSpec): void;
+  /** Force-close the popover. Safe to call when already closed. */
+  close(): void;
+  /** Detach event listeners + remove from DOM. */
+  destroy(): void;
+}
+
+/**
+ * Mount a date-range picker. The returned `element` is a single
+ * inline node containing both the trigger button and the popover
+ * (absolutely positioned via `.multi-anchor` + `.multi-panel`).
+ *
+ * The popover stays in the DOM permanently; opening/closing toggles
+ * the `[hidden]` attribute. This keeps the chip's tab-order stable
+ * and matches the multi-select widget's behaviour.
+ */
+export function mountDateRangePicker(opts: MountOpts): PickerHandle {
+  const presets = opts.presets ?? ALL_HORIZONS;
+  const defaultHorizon = opts.defaultHorizon ?? "any";
+  let value: TimeSpec = normalize(opts.value);
+
+  // Cached drafts for the "Anpassen" editor — preserved across
+  // open/close so the user doesn't lose their typing if they peek
+  // away. Seeded from the live value when the editor opens.
+  let customFromDraft = value.horizon === "custom" ? (value.from ?? "") : "";
+  let customToDraft = value.horizon === "custom" ? (value.to ?? "") : "";
+  let customEditorOpen = value.horizon === "custom";
+
+  const root = document.createElement("div");
+  root.className = "date-range-anchor multi-anchor";
+  root.dataset.testid = `${opts.surface}.date-range-picker`;
+
+  const trigger = document.createElement("button");
+  trigger.type = "button";
+  trigger.className = "date-range-trigger";
+  trigger.setAttribute("aria-haspopup", "dialog");
+  trigger.setAttribute("aria-expanded", "false");
+  trigger.dataset.testid = `${opts.surface}.date-range-trigger`;
+
+  const panel = document.createElement("div");
+  panel.className = "date-range-panel multi-panel";
+  panel.setAttribute("role", "dialog");
+  panel.setAttribute("aria-label", t("date_range.dialog.label"));
+  panel.hidden = true;
+  panel.dataset.testid = `${opts.surface}.date-range-panel`;
+
+  root.appendChild(trigger);
+  root.appendChild(panel);
+
+  renderTrigger();
+  renderPanel();
+
+  // Open/close wiring. Click outside the root collapses the popover;
+  // Esc inside it bubbles up to the same handler via keydown delegate.
+  const onDocClick = (e: MouseEvent) => {
+    if (panel.hidden) return;
+    if (e.target instanceof Node && root.contains(e.target)) return;
+    closePopover();
+  };
+  const onKeydown = (e: KeyboardEvent) => {
+    if (panel.hidden) return;
+    if (e.key === "Escape") {
+      e.stopPropagation();
+      closePopover();
+      trigger.focus();
+    }
+  };
+
+  trigger.addEventListener("click", () => {
+    if (panel.hidden) openPopover();
+    else closePopover();
+  });
+
+  document.addEventListener("mousedown", onDocClick);
+  document.addEventListener("keydown", onKeydown);
+
+  function openPopover(): void {
+    panel.hidden = false;
+    trigger.setAttribute("aria-expanded", "true");
+    // Re-render to reflect the very latest value (host may have
+    // patched via setValue between open/close).
+    renderPanel();
+    // Move keyboard focus into the panel so Esc works without a
+    // prior click. The first chip is the natural landing spot.
+    const firstChip = panel.querySelector<HTMLButtonElement>(".date-range-chip");
+    firstChip?.focus({ preventScroll: true });
+  }
+
+  function closePopover(): void {
+    panel.hidden = true;
+    trigger.setAttribute("aria-expanded", "false");
+  }
+
+  function commit(next: TimeSpec, closeAfter: boolean): void {
+    value = normalize(next);
+    customEditorOpen = value.horizon === "custom";
+    if (value.horizon === "custom") {
+      customFromDraft = value.from ?? "";
+      customToDraft = value.to ?? "";
+    }
+    renderTrigger();
+    renderPanel();
+    opts.onChange(value);
+    if (closeAfter) {
+      closePopover();
+      trigger.focus({ preventScroll: true });
+    }
+  }
+
+  function renderTrigger(): void {
+    trigger.replaceChildren();
+    if (!isDefault(value, defaultHorizon)) {
+      const dot = document.createElement("span");
+      dot.className = "date-range-trigger-dot";
+      dot.setAttribute("aria-hidden", "true");
+      trigger.appendChild(dot);
+    }
+    const labelSpan = document.createElement("span");
+    labelSpan.className = "date-range-trigger-label";
+    labelSpan.textContent = labelFor(value, opts.labelPrefix);
+    trigger.appendChild(labelSpan);
+
+    const chev = document.createElement("span");
+    chev.className = "date-range-trigger-chev";
+    chev.setAttribute("aria-hidden", "true");
+    chev.textContent = "▾";
+    trigger.appendChild(chev);
+  }
+
+  function renderPanel(): void {
+    panel.replaceChildren();
+
+    // Three groups in a single row: past fan / ALLES centre / next fan.
+    const row = document.createElement("div");
+    row.className = "date-range-row";
+
+    const pastGroup = renderFan(
+      PAST_HORIZONS.filter((h) => presets.includes(h)),
+      "past",
+    );
+    const centerGroup = renderCenter();
+    const nextGroup = renderFan(
+      NEXT_HORIZONS.filter((h) => presets.includes(h)),
+      "next",
+    );
+
+    if (pastGroup) row.appendChild(pastGroup);
+    if (centerGroup) row.appendChild(centerGroup);
+    if (nextGroup) row.appendChild(nextGroup);
+
+    panel.appendChild(row);
+
+    // Custom-range section ("Anpassen"). Toggle button + collapsible
+    // date-pair editor below.
+    if (presets.includes("custom")) {
+      panel.appendChild(renderCustomSection());
+    }
+  }
+
+  function renderFan(horizons: readonly TimeHorizon[], side: "past" | "next"): HTMLElement | null {
+    if (horizons.length === 0) return null;
+    const group = document.createElement("div");
+    group.className = `date-range-fan date-range-fan--${side}`;
+    group.setAttribute("role", "group");
+    group.setAttribute("aria-label", side === "past"
+      ? t("date_range.fan.past.label")
+      : t("date_range.fan.future.label"));
+    for (const h of horizons) {
+      group.appendChild(makeChip(h));
+    }
+    return group;
+  }
+
+  function renderCenter(): HTMLElement | null {
+    if (!presets.includes("any")) return null;
+    const wrap = document.createElement("div");
+    wrap.className = "date-range-center";
+    const btn = document.createElement("button");
+    btn.type = "button";
+    btn.className = "date-range-center-btn";
+    if (value.horizon === "any" || value.horizon === "all") {
+      btn.classList.add("date-range-center-btn--active");
+    }
+    btn.setAttribute("aria-pressed", String(value.horizon === "any" || value.horizon === "all"));
+    btn.dataset.testid = `${opts.surface}.date-range-chip.any`;
+
+    const glyph = document.createElement("span");
+    glyph.className = "date-range-center-glyph";
+    glyph.setAttribute("aria-hidden", "true");
+    glyph.textContent = "⌖"; // ⌖ POSITION INDICATOR
+    const label = document.createElement("span");
+    label.className = "date-range-center-label";
+    label.textContent = t("date_range.center.label");
+    btn.appendChild(glyph);
+    btn.appendChild(label);
+
+    btn.addEventListener("click", () => {
+      commit({ horizon: "any" }, /*closeAfter*/ true);
+    });
+
+    wrap.appendChild(btn);
+    return wrap;
+  }
+
+  function makeChip(h: TimeHorizon): HTMLButtonElement {
+    const chip = document.createElement("button");
+    chip.type = "button";
+    chip.className = "agenda-chip date-range-chip";
+    if (value.horizon === h) chip.classList.add("agenda-chip-active");
+    chip.setAttribute("aria-pressed", String(value.horizon === h));
+    chip.textContent = t(HORIZON_LABEL_KEY[h]);
+    chip.dataset.testid = `${opts.surface}.date-range-chip.${h}`;
+    chip.addEventListener("click", () => {
+      commit({ horizon: h }, /*closeAfter*/ true);
+    });
+    return chip;
+  }
+
+  function renderCustomSection(): HTMLElement {
+    const section = document.createElement("div");
+    section.className = "date-range-custom";
+
+    const toggleBtn = document.createElement("button");
+    toggleBtn.type = "button";
+    toggleBtn.className = "agenda-chip date-range-chip date-range-chip--custom";
+    if (value.horizon === "custom") toggleBtn.classList.add("agenda-chip-active");
+    toggleBtn.setAttribute("aria-expanded", String(customEditorOpen));
+    toggleBtn.dataset.testid = `${opts.surface}.date-range-chip.custom`;
+    toggleBtn.textContent = t("date_range.horizon.custom");
+    toggleBtn.addEventListener("click", () => {
+      customEditorOpen = !customEditorOpen;
+      renderPanel();
+      if (customEditorOpen) {
+        // Focus the first input on expand.
+        panel.querySelector<HTMLInputElement>(".date-range-custom-from")?.focus();
+      }
+    });
+    section.appendChild(toggleBtn);
+
+    if (!customEditorOpen) return section;
+
+    const editor = document.createElement("div");
+    editor.className = "date-range-custom-editor";
+
+    const fromWrap = document.createElement("label");
+    fromWrap.className = "date-range-custom-field";
+    const fromLbl = document.createElement("span");
+    fromLbl.className = "date-range-custom-label";
+    fromLbl.textContent = t("date_range.custom.from");
+    const fromInput = document.createElement("input");
+    fromInput.type = "date";
+    fromInput.lang = "de";
+    fromInput.className = "date-range-custom-from";
+    fromInput.value = customFromDraft;
+    fromInput.dataset.testid = `${opts.surface}.date-range-custom-from`;
+    fromInput.addEventListener("input", () => {
+      customFromDraft = fromInput.value;
+      refreshValidity();
+    });
+    fromWrap.appendChild(fromLbl);
+    fromWrap.appendChild(fromInput);
+
+    const toWrap = document.createElement("label");
+    toWrap.className = "date-range-custom-field";
+    const toLbl = document.createElement("span");
+    toLbl.className = "date-range-custom-label";
+    toLbl.textContent = t("date_range.custom.to");
+    const toInput = document.createElement("input");
+    toInput.type = "date";
+    toInput.lang = "de";
+    toInput.className = "date-range-custom-to";
+    toInput.value = customToDraft;
+    toInput.dataset.testid = `${opts.surface}.date-range-custom-to`;
+    toInput.addEventListener("input", () => {
+      customToDraft = toInput.value;
+      refreshValidity();
+    });
+    toWrap.appendChild(toLbl);
+    toWrap.appendChild(toInput);
+
+    const applyBtn = document.createElement("button");
+    applyBtn.type = "button";
+    applyBtn.className = "date-range-custom-apply";
+    applyBtn.textContent = t("date_range.custom.apply");
+    applyBtn.dataset.testid = `${opts.surface}.date-range-custom-apply`;
+    applyBtn.addEventListener("click", () => {
+      const err = validateCustomRange(customFromDraft, customToDraft);
+      if (err !== null) {
+        showError(err);
+        return;
+      }
+      commit(
+        { horizon: "custom", from: customFromDraft, to: customToDraft },
+        /*closeAfter*/ true,
+      );
+    });
+
+    const cancelBtn = document.createElement("button");
+    cancelBtn.type = "button";
+    cancelBtn.className = "date-range-custom-cancel";
+    cancelBtn.textContent = t("date_range.custom.cancel");
+    cancelBtn.addEventListener("click", () => {
+      customEditorOpen = false;
+      // Restore drafts from live value so a re-open shows the
+      // committed state rather than the abandoned typing.
+      customFromDraft = value.horizon === "custom" ? (value.from ?? "") : "";
+      customToDraft = value.horizon === "custom" ? (value.to ?? "") : "";
+      renderPanel();
+    });
+
+    const errEl = document.createElement("div");
+    errEl.className = "date-range-custom-error";
+    errEl.hidden = true;
+    errEl.dataset.testid = `${opts.surface}.date-range-custom-error`;
+
+    editor.appendChild(fromWrap);
+    editor.appendChild(toWrap);
+    editor.appendChild(applyBtn);
+    editor.appendChild(cancelBtn);
+    editor.appendChild(errEl);
+    section.appendChild(editor);
+
+    refreshValidity();
+
+    function refreshValidity(): void {
+      const err = validateCustomRange(customFromDraft, customToDraft);
+      if (err === null) {
+        applyBtn.disabled = false;
+        errEl.hidden = true;
+        errEl.textContent = "";
+        return;
+      }
+      applyBtn.disabled = true;
+      // Only surface the *content* error (`invalid` = inverted range)
+      // while the user is typing. Empty / format errors are visible
+      // through the disabled-Anwenden state alone — surfacing them on
+      // every keystroke would be noisy.
+      if (err === "date_range.custom.invalid") {
+        showError(err);
+      } else {
+        errEl.hidden = true;
+      }
+    }
+
+    function showError(key: Parameters<typeof t>[0]): void {
+      errEl.textContent = t(key);
+      errEl.hidden = false;
+    }
+
+    return section;
+  }
+
+  return {
+    element: root,
+    getValue: () => normalize(value),
+    setValue(next: TimeSpec) {
+      value = normalize(next);
+      customEditorOpen = value.horizon === "custom";
+      if (value.horizon === "custom") {
+        customFromDraft = value.from ?? "";
+        customToDraft = value.to ?? "";
+      }
+      renderTrigger();
+      renderPanel();
+    },
+    close: closePopover,
+    destroy() {
+      document.removeEventListener("mousedown", onDocClick);
+      document.removeEventListener("keydown", onKeydown);
+      root.remove();
+    },
+  };
+}
+
+function normalize(spec: TimeSpec): TimeSpec {
+  if (spec.horizon === "custom") {
+    return {
+      horizon: "custom",
+      from: spec.from && isValidISODate(spec.from) ? spec.from : undefined,
+      to: spec.to && isValidISODate(spec.to) ? spec.to : undefined,
+    };
+  }
+  return { horizon: spec.horizon };
+}
+
+function labelFor(spec: TimeSpec, prefix?: string): string {
+  let body: string;
+  if (spec.horizon === "custom") {
+    if (spec.from && spec.to) {
+      body = t("date_range.button.label.custom_range")
+        .replace("{from}", formatISO(spec.from))
+        .replace("{to}", formatISO(spec.to));
+    } else {
+      body = t("date_range.horizon.custom");
+    }
+  } else {
+    body = t(HORIZON_LABEL_KEY[spec.horizon]);
+  }
+  return prefix ? `${prefix}: ${body}` : body;
+}
+
+function formatISO(iso: string): string {
+  if (!isValidISODate(iso)) return iso;
+  // DE locale: DD.MM.YYYY. The picker is German-first; surfaces in EN
+  // can override via labelPrefix or by formatting before commit if
+  // they want a different shape.
+  const [y, m, d] = iso.split("-");
+  return `${d}.${m}.${y}`;
+}

frontend/src/client/deadlines-calendar.ts

@@ -1,181 +0,0 @@
-import { initI18n, onLangChange, t, tDyn, getLang } from "./i18n";
-import { initSidebar } from "./sidebar";
-
-interface Deadline {
-  id: string;
-  project_id: string;
-  title: string;
-  due_date: string;
-  status: string;
-  project_reference: string;
-  project_title: string;
-}
-
-let allDeadlines: Deadline[] = [];
-let viewYear = 0;
-let viewMonth = 0; // 0-11
-
-function esc(s: string): string {
-  const d = document.createElement("div");
-  d.textContent = s;
-  return d.innerHTML;
-}
-
-function fmtMonth(year: number, month: number): string {
-  return `${tDyn(`cal.month.${month}`)} ${year}`;
-}
-
-function urgencyClass(due: string, status: string): string {
-  if (status === "completed") return "frist-urgency-done";
-  const today = new Date();
-  today.setHours(0, 0, 0, 0);
-  const d = new Date(due.slice(0, 10) + "T00:00:00");
-  const diffDays = Math.floor((d.getTime() - today.getTime()) / 86400000);
-  if (diffDays < 0) return "frist-urgency-overdue";
-  if (diffDays <= 7) return "frist-urgency-soon";
-  return "frist-urgency-later";
-}
-
-async function loadDeadlines() {
-  try {
-    const resp = await fetch("/api/deadlines?status=all");
-    if (resp.ok) allDeadlines = await resp.json();
-  } catch {
-    /* non-fatal */
-  }
-}
-
-function deadlinesForDate(iso: string): Deadline[] {
-  return allDeadlines.filter((f) => f.due_date.slice(0, 10) === iso);
-}
-
-function isoDate(year: number, month: number, day: number): string {
-  const m = String(month + 1).padStart(2, "0");
-  const d = String(day).padStart(2, "0");
-  return `${year}-${m}-${d}`;
-}
-
-function render() {
-  document.getElementById("cal-month-label")!.textContent = fmtMonth(viewYear, viewMonth);
-
-  const firstDay = new Date(viewYear, viewMonth, 1);
-  const jsWeekday = firstDay.getDay();
-  const offset = (jsWeekday + 6) % 7;
-  const daysInMonth = new Date(viewYear, viewMonth + 1, 0).getDate();
-  const today = new Date();
-  const todayISO = isoDate(today.getFullYear(), today.getMonth(), today.getDate());
-
-  const cells: string[] = [];
-  for (let i = 0; i < offset; i++) {
-    cells.push(`<div class="frist-cal-cell frist-cal-cell-empty"></div>`);
-  }
-  for (let day = 1; day <= daysInMonth; day++) {
-    const iso = isoDate(viewYear, viewMonth, day);
-    const items = deadlinesForDate(iso);
-    const isToday = iso === todayISO;
-
-    const dots = items
-      .slice(0, 4)
-      .map((f) => `<span class="frist-cal-dot ${urgencyClass(f.due_date, f.status)}"></span>`)
-      .join("");
-    const more = items.length > 4 ? `<span class="frist-cal-more">+${items.length - 4}</span>` : "";
-
-    cells.push(
-      `<div class="frist-cal-cell${isToday ? " frist-cal-today" : ""}${items.length > 0 ? " frist-cal-cell-has" : ""}" data-iso="${iso}">
-        <span class="frist-cal-day">${day}</span>
-        <div class="frist-cal-dots">${dots}${more}</div>
-      </div>`,
-    );
-  }
-
-  const grid = document.getElementById("deadline-cal-grid")!;
-  grid.innerHTML = cells.join("");
-
-  grid.querySelectorAll<HTMLElement>(".frist-cal-cell-has").forEach((cell) => {
-    cell.addEventListener("click", () => openPopup(cell.dataset.iso!));
-  });
-
-  const monthStart = isoDate(viewYear, viewMonth, 1);
-  const monthEnd = isoDate(viewYear, viewMonth, daysInMonth);
-  const hasInMonth = allDeadlines.some((f) => {
-    const iso = f.due_date.slice(0, 10);
-    return iso >= monthStart && iso <= monthEnd;
-  });
-  const empty = document.getElementById("deadline-cal-empty")!;
-  empty.style.display = hasInMonth ? "none" : "";
-}
-
-function openPopup(iso: string) {
-  const items = deadlinesForDate(iso);
-  if (items.length === 0) return;
-  const popup = document.getElementById("cal-popup")!;
-  const dateEl = document.getElementById("cal-popup-date")!;
-  const list = document.getElementById("cal-popup-list")!;
-
-  const d = new Date(iso + "T00:00:00");
-  dateEl.textContent = d.toLocaleDateString(getLang() === "de" ? "de-DE" : "en-GB", {
-    weekday: "long",
-    year: "numeric",
-    month: "long",
-    day: "numeric",
-  });
-
-  list.innerHTML = items
-    .map((f) => {
-      const cls = urgencyClass(f.due_date, f.status);
-      return `<li class="frist-cal-popup-item">
-        <span class="frist-cal-dot ${cls}"></span>
-        <a href="/deadlines/${esc(f.id)}" class="frist-cal-popup-title">${esc(f.title)}</a>
-        <a href="/projects/${esc(f.project_id)}" class="frist-cal-popup-project">${esc(f.project_reference)}</a>
-      </li>`;
-    })
-    .join("");
-  popup.style.display = "flex";
-}
-
-function initPopup() {
-  const popup = document.getElementById("cal-popup")!;
-  const close = document.getElementById("cal-popup-close")!;
-  close.addEventListener("click", () => (popup.style.display = "none"));
-  popup.addEventListener("click", (e) => {
-    if (e.target === e.currentTarget) popup.style.display = "none";
-  });
-}
-
-function initNav() {
-  document.getElementById("cal-prev")!.addEventListener("click", () => {
-    viewMonth -= 1;
-    if (viewMonth < 0) {
-      viewMonth = 11;
-      viewYear -= 1;
-    }
-    render();
-  });
-  document.getElementById("cal-next")!.addEventListener("click", () => {
-    viewMonth += 1;
-    if (viewMonth > 11) {
-      viewMonth = 0;
-      viewYear += 1;
-    }
-    render();
-  });
-  document.getElementById("cal-today")!.addEventListener("click", () => {
-    const now = new Date();
-    viewYear = now.getFullYear();
-    viewMonth = now.getMonth();
-    render();
-  });
-}
-
-document.addEventListener("DOMContentLoaded", async () => {
-  initI18n();
-  initSidebar();
-  const now = new Date();
-  viewYear = now.getFullYear();
-  viewMonth = now.getMonth();
-  initNav();
-  initPopup();
-  onLangChange(render);
-  await loadDeadlines();
-  render();
-});

frontend/src/client/deadlines-detail.ts

@@ -9,6 +9,8 @@ import {
   type EventType,
   type PickerHandle,
 } from "./event-types";
+import { openWithdrawWarningModal } from "./components/withdraw-warning-modal";
+import { formatRuleLabel, formatRuleLabelHTML, formatCustomRuleLabelHTML } from "./rule-label";
 
 interface Deadline {
   id: string;
@@ -20,6 +22,9 @@ interface Deadline {
   source: string;
   rule_id?: string;
   rule_code?: string;
+  // t-paliad-258 — lawyer's free-text rule label when the deadline was
+  // saved in Custom mode. Mutually exclusive with rule_id.
+  custom_rule_text?: string;
   notes?: string;
   created_at: string;
   completed_at?: string;
@@ -38,6 +43,9 @@ interface PendingApprovalRequest {
   requested_at: string;
   required_role: string;
   requester_name?: string;
+  // t-paliad-252 — used by the withdraw warning modal to pick the right
+  // copy (CREATE warns about deletion; UPDATE/COMPLETE about revert).
+  lifecycle_event?: string;
 }
 
 let eventTypePicker: PickerHandle | null = null;
@@ -54,7 +62,21 @@ interface DeadlineRule {
   id: string;
   code?: string;
   name: string;
+  name_en?: string;
   rule_code?: string;
+  legal_source?: string | null;
+  // t-paliad-258 — canonical event_type for Auto-mode rule resolution
+  // when the user flips to Auto on the edit form.
+  concept_default_event_type_id?: string | null;
+  proceeding_type_id?: number | null;
+}
+
+interface ProceedingType {
+  id: number;
+  jurisdiction: string;
+  name: string;
+  name_en?: string;
+  sort_order?: number;
 }
 
 interface Me {
@@ -70,6 +92,30 @@ let me: Me | null = null;
 let allProjects: Project[] = [];
 let pendingRequest: PendingApprovalRequest | null = null;
 
+// t-paliad-258 — Auto/Custom rule editor state. Mirrors the create form.
+// On enterEdit we initialise the mode from the persisted deadline:
+//   rule_id set                       → "auto"
+//   custom_rule_text set, no rule_id  → "custom"
+//   neither set                       → "auto" (so the Type-driven
+//                                        resolver fills in immediately).
+type RuleMode = "auto" | "custom";
+let ruleMode: RuleMode = "auto";
+let allRules: DeadlineRule[] = [];
+let rulesByID = new Map<string, DeadlineRule>();
+let proceedingTypesByID = new Map<number, ProceedingType>();
+// t-paliad-252 — when the user chose "Edit event" in the withdraw warning
+// modal, the entity is still in approval_status='pending'. Save must POST
+// to /api/approval-requests/{id}/edit-entity (which keeps the request
+// pending + merges the new fields into payload) instead of the regular
+// PATCH /api/deadlines/{id} (which 409s during pending). Cleared on exit
+// from edit mode + after a successful save.
+let pendingEditMode = false;
+
+// pendingEnterEdit — late-bound by initEdit() so the withdraw warning
+// modal handler (initWithdraw) can route into pending-edit mode without
+// duplicating the edit-mode toggle logic.
+let pendingEnterEdit: (() => void) | null = null;
+
 function parseDeadlineID(): string | null {
   const parts = window.location.pathname.split("/").filter(Boolean);
   if (parts[0] !== "deadlines" || !parts[1]) return null;
@@ -165,17 +211,66 @@ function populateProjectPicker() {
   sel.value = deadline.project_id;
 }
 
-async function loadRule(ruleID: string) {
+async function loadAllRules() {
   try {
     const resp = await fetch(`/api/deadline-rules`);
     if (!resp.ok) return;
-    const all: DeadlineRule[] = await resp.json();
-    rule = all.find((r) => r.id === ruleID) || null;
+    allRules = (await resp.json()) as DeadlineRule[];
+    rulesByID = new Map(allRules.map((r) => [r.id, r]));
   } catch {
     /* non-fatal */
   }
 }
 
+async function loadProceedingTypes() {
+  try {
+    const resp = await fetch("/api/proceeding-types-db");
+    if (!resp.ok) return;
+    const types: ProceedingType[] = await resp.json();
+    proceedingTypesByID = new Map(types.map((pt) => [pt.id, pt]));
+  } catch {
+    /* non-fatal */
+  }
+}
+
+function lookupRule(ruleID: string): DeadlineRule | null {
+  return rulesByID.get(ruleID) || null;
+}
+
+// resolveAutoRuleForType mirrors the create-form resolver: pick the
+// canonical rule for the chosen event_type, prioritising the project's
+// proceeding then jurisdiction match.
+function resolveAutoRuleForType(eventTypeID: string): DeadlineRule | null {
+  const candidates = allRules.filter((r) => r.concept_default_event_type_id === eventTypeID);
+  if (candidates.length === 0) return null;
+  if (candidates.length === 1) return candidates[0];
+
+  const projID = deadline?.project_id;
+  const proj = projID ? allProjects.find((p) => p.id === projID) as (Project & { proceeding_type_id?: number | null }) | undefined : undefined;
+  if (proj && proj.proceeding_type_id) {
+    const exact = candidates.find((r) => r.proceeding_type_id === proj.proceeding_type_id);
+    if (exact) return exact;
+  }
+
+  const et = eventTypeByID.get(eventTypeID);
+  if (et?.jurisdiction && et.jurisdiction !== "any") {
+    const want = et.jurisdiction === "EPO" ? "EPA" : et.jurisdiction;
+    const jurMatch = candidates.find((r) => {
+      const pt = r.proceeding_type_id ? proceedingTypesByID.get(r.proceeding_type_id) : undefined;
+      return pt?.jurisdiction === want;
+    });
+    if (jurMatch) return jurMatch;
+  }
+
+  return candidates[0];
+}
+
+function currentAutoRule(): DeadlineRule | null {
+  const picked = eventTypePicker?.getIDs() ?? [];
+  if (picked.length !== 1) return null;
+  return resolveAutoRuleForType(picked[0]);
+}
+
 async function loadMe() {
   try {
     const resp = await fetch("/api/me");
@@ -227,9 +322,15 @@ function render() {
   }
 
   const ruleEl = document.getElementById("deadline-rule-display")!;
+  // t-paliad-258 — display priority:
+  //   1. catalog rule (canonical Name · Citation pattern)
+  //   2. custom_rule_text + Custom badge
+  //   3. legacy rule_code-only (Fristenrechner saves)
+  //   4. "—"
   if (rule) {
-    const code = rule.rule_code || rule.code || "";
-    ruleEl.textContent = code ? `${code} — ${rule.name}` : rule.name;
+    ruleEl.innerHTML = formatRuleLabelHTML(rule, esc);
+  } else if (deadline.custom_rule_text && deadline.custom_rule_text.trim()) {
+    ruleEl.innerHTML = formatCustomRuleLabelHTML(deadline.custom_rule_text, esc);
   } else if (deadline.rule_code) {
     // Fristenrechner-saved deadlines carry rule_code directly without
     // a rule_id (no rule UUID round-trips through the public API).
@@ -353,6 +454,49 @@ function render() {
   }
 }
 
+function refreshRuleAutoDisplay(): void {
+  const panel = document.getElementById("deadline-rule-auto-display");
+  const text = document.getElementById("deadline-rule-auto-text");
+  if (!panel || !text) return;
+  if (ruleMode !== "auto") {
+    panel.style.display = "none";
+    return;
+  }
+  panel.style.display = "";
+  const r = currentAutoRule();
+  if (r) {
+    // Canonical "Name · Citation" with muted citation (t-paliad-258 addendum).
+    text.innerHTML = formatRuleLabelHTML(r, esc);
+    text.classList.remove("rule-auto-text--empty");
+    return;
+  }
+  const picked = eventTypePicker?.getIDs() ?? [];
+  const fallback = picked.length === 1
+    ? (t("deadlines.field.rule.auto_no_match") || "Keine Regel zur gewählten Verfahrenshandlung")
+    : (t("deadlines.field.rule.auto_pick_type") || "Wählen Sie zuerst eine Verfahrenshandlung");
+  text.textContent = fallback;
+  text.classList.add("rule-auto-text--empty");
+}
+
+function applyRuleModeUI(): void {
+  const toggleBtn = document.getElementById("deadline-rule-mode-toggle") as HTMLButtonElement | null;
+  const autoPanel = document.getElementById("deadline-rule-auto-display");
+  const customInput = document.getElementById("deadline-rule-custom-input") as HTMLInputElement | null;
+  if (!toggleBtn || !autoPanel || !customInput) return;
+  if (ruleMode === "auto") {
+    autoPanel.style.display = "";
+    customInput.style.display = "none";
+    toggleBtn.textContent = t("deadlines.field.rule.mode.toggle_to_custom") || "Eigene Regel eingeben";
+    toggleBtn.setAttribute("data-i18n", "deadlines.field.rule.mode.toggle_to_custom");
+  } else {
+    autoPanel.style.display = "none";
+    customInput.style.display = "";
+    toggleBtn.textContent = t("deadlines.field.rule.mode.toggle_to_auto") || "Zurück zu Auto";
+    toggleBtn.setAttribute("data-i18n", "deadlines.field.rule.mode.toggle_to_auto");
+  }
+  refreshRuleAutoDisplay();
+}
+
 function initEdit() {
   const titleDisplay = document.getElementById("deadline-title-display")!;
   const titleEdit = document.getElementById("deadline-title-edit") as HTMLInputElement;
@@ -366,6 +510,11 @@ function initEdit() {
   const etEdit = document.getElementById("deadline-event-types-edit");
   const projectLink = document.getElementById("deadline-project-link") as HTMLAnchorElement;
   const projectEdit = document.getElementById("deadline-project-edit") as HTMLSelectElement | null;
+  const titleDefaultBtn = document.getElementById("deadline-title-default-btn") as HTMLButtonElement | null;
+  const ruleDisplay = document.getElementById("deadline-rule-display");
+  const ruleEdit = document.getElementById("deadline-rule-edit");
+  const ruleCustomInput = document.getElementById("deadline-rule-custom-input") as HTMLInputElement | null;
+  const ruleToggleBtn = document.getElementById("deadline-rule-mode-toggle") as HTMLButtonElement | null;
 
   function enterEdit() {
     titleDisplay.style.display = "none";
@@ -381,6 +530,20 @@ function initEdit() {
       projectEdit.style.display = "";
       projectEdit.value = deadline.project_id;
     }
+    if (titleDefaultBtn) titleDefaultBtn.style.display = "";
+    // t-paliad-258 — show the Auto/Custom rule editor + initialise mode
+    // from the persisted deadline. Display element stays visible so the
+    // user keeps "before / after" context while editing.
+    if (ruleEdit) ruleEdit.style.display = "";
+    if (ruleDisplay) ruleDisplay.style.display = "none";
+    if (deadline?.custom_rule_text && !deadline.rule_id) {
+      ruleMode = "custom";
+      if (ruleCustomInput) ruleCustomInput.value = deadline.custom_rule_text;
+    } else {
+      ruleMode = "auto";
+      if (ruleCustomInput) ruleCustomInput.value = "";
+    }
+    applyRuleModeUI();
     saveBtn.style.display = "";
     editBtn.style.display = "none";
     titleEdit.focus();
@@ -399,12 +562,71 @@ function initEdit() {
       projectEdit.style.display = "none";
       projectLink.style.display = "";
     }
+    if (titleDefaultBtn) titleDefaultBtn.style.display = "none";
+    if (ruleEdit) ruleEdit.style.display = "none";
+    if (ruleDisplay) ruleDisplay.style.display = "";
     saveBtn.style.display = "none";
     editBtn.style.display = "";
+    pendingEditMode = false;
   }
 
+  // Rule mode toggle (Auto ↔ Custom). The Auto resolver re-runs every
+  // time the Type picker changes, so just-toggling-to-Auto immediately
+  // surfaces a fresh resolution.
+  ruleToggleBtn?.addEventListener("click", () => {
+    ruleMode = ruleMode === "auto" ? "custom" : "auto";
+    applyRuleModeUI();
+    if (ruleMode === "custom") ruleCustomInput?.focus();
+  });
+
+  // t-paliad-252 — expose enterEdit so the withdraw warning modal can
+  // route into pending-edit mode without re-running the edit-button
+  // visibility gate (which hides the button during pending).
+  pendingEnterEdit = () => {
+    pendingEditMode = true;
+    enterEdit();
+  };
+
   editBtn.addEventListener("click", enterEdit);
 
+  // t-paliad-251 Part 4 — Standardtitel button.
+  // Recipe (mirror of computeDefaultTitle in deadlines-new.ts):
+  //   head = event_type label (if exactly one Typ chip in edit)
+  //       || Auto-resolved rule's canonical label (Name · Citation)
+  //       || saved rule's canonical label
+  //       || custom_rule_text (when in Custom mode + non-empty)
+  //       || rule_code-only legacy fallback
+  //       || "Neue Frist" fallback
+  //   suffix = " — <project.reference>" when not already in head
+  titleDefaultBtn?.addEventListener("click", () => {
+    if (!deadline) return;
+    let head = "";
+    const ids = eventTypePicker?.getIDs() ?? deadline.event_type_ids ?? [];
+    if (ids.length === 1) {
+      const et = eventTypeByID.get(ids[0]);
+      if (et) head = eventTypeLabel(et);
+    }
+    if (!head) {
+      const r = ruleMode === "auto" ? (currentAutoRule() ?? rule) : null;
+      if (r) head = formatRuleLabel(r);
+    }
+    if (!head && ruleMode === "custom") {
+      const txt = ruleCustomInput?.value.trim() || "";
+      if (txt) head = txt;
+    }
+    if (!head && rule) {
+      head = formatRuleLabel(rule);
+    }
+    if (!head && deadline.rule_code) {
+      head = deadline.rule_code;
+    }
+    if (!head) head = t("deadlines.field.title.default_fallback");
+    const ref = project?.reference?.trim() || "";
+    if (ref && !head.includes(ref)) head = `${head} — ${ref}`;
+    titleEdit.value = head;
+    titleEdit.focus();
+  });
+
   saveBtn.addEventListener("click", async () => {
     if (!deadline) return;
     const newTitle = titleEdit.value.trim();
@@ -424,6 +646,48 @@ function initEdit() {
       if (projectEdit && projectEdit.value && projectEdit.value !== deadline.project_id) {
         payload.project_id = projectEdit.value;
       }
+      // t-paliad-258 — rule_set discriminator tells the service this
+      // PATCH carries an Auto/Custom rule change. Both columns are
+      // mutually exclusive at the persistence boundary.
+      payload.rule_set = true;
+      if (ruleMode === "auto") {
+        const r = currentAutoRule();
+        payload.rule_id = r ? r.id : null;
+        payload.custom_rule_text = null;
+      } else {
+        const txt = ruleCustomInput?.value.trim() || "";
+        payload.rule_id = null;
+        payload.custom_rule_text = txt || null;
+      }
+
+      // t-paliad-252 — pending-edit mode routes through the new endpoint
+      // that updates the entity + merges payload into the still-pending
+      // approval_request. Outside pending-edit mode the regular PATCH
+      // path remains the authoritative one (with its existing 409-on-
+      // pending guard).
+      if (pendingEditMode && pendingRequest) {
+        const resp = await fetch(
+          `/api/approval-requests/${pendingRequest.id}/edit-entity`,
+          {
+            method: "POST",
+            headers: { "Content-Type": "application/json" },
+            body: JSON.stringify({ fields: payload }),
+          },
+        );
+        if (resp.ok) {
+          const fresh = await fetch(`/api/deadlines/${deadline.id}`);
+          if (fresh.ok) deadline = await fresh.json();
+          await loadPendingRequest();
+          render();
+        } else {
+          const body = await resp.json().catch(() => null);
+          const msg = (body && (body.message || body.error))
+            || (t("approvals.withdraw.error") || "Fehler");
+          window.alert(msg);
+        }
+        return;
+      }
+
       const resp = await fetch(`/api/deadlines/${deadline.id}`, {
         method: "PATCH",
         headers: { "Content-Type": "application/json" },
@@ -501,19 +765,39 @@ function initReopen() {
   });
 }
 
-// initWithdraw — t-paliad-160 §C+E. Reuses the existing
-// /api/approval-requests/{id}/revoke endpoint (no new server route
-// needed). After the revoke lands, the entity goes back to
-// approval_status='approved' and the page reloads to refresh the
-// in-memory state cleanly.
+// initWithdraw — t-paliad-160 §C+E + t-paliad-252.
+//
+// Click flow: open the withdraw warning modal (replaces the old
+// confirm()). The modal returns one of:
+//
+//   "edit"     — open the edit form in pending-edit mode; Save calls
+//                /api/approval-requests/{id}/edit-entity which keeps the
+//                request pending + merges the new fields into payload
+//   "withdraw" — destructive: call the existing /revoke endpoint
+//                (DELETE entity for CREATE, revert for UPDATE/COMPLETE,
+//                cancel-delete for DELETE lifecycle)
+//   null       — user cancelled; nothing happens
 function initWithdraw() {
   const btn = document.getElementById("deadline-withdraw-btn") as HTMLButtonElement | null;
   if (!btn) return;
   btn.addEventListener("click", async () => {
     if (!deadline || !pendingRequest) return;
-    if (!window.confirm(t("approvals.withdraw.confirm") || "Anfrage wirklich zurückziehen?")) return;
     btn.disabled = true;
     try {
+      const action = await openWithdrawWarningModal({
+        entityType: "deadline",
+        lifecycleEvent: pendingRequest.lifecycle_event ?? "create",
+      });
+      if (action === null) {
+        btn.disabled = false;
+        return;
+      }
+      if (action === "edit") {
+        btn.disabled = false;
+        pendingEnterEdit?.();
+        return;
+      }
+      // action === "withdraw" → existing destructive path.
       const resp = await fetch(`/api/approval-requests/${pendingRequest.id}/revoke`, {
         method: "POST",
         headers: { "Content-Type": "application/json" },
@@ -521,14 +805,16 @@ function initWithdraw() {
       });
       if (resp.ok) {
         // Re-fetch the entity so approval_status flips back to 'approved'
-        // and the badge / buttons rerender accordingly.
+        // and the badge / buttons rerender accordingly. For CREATE
+        // lifecycle the entity is gone, so the 404 surfaces as a reload.
         const r = await fetch(`/api/deadlines/${deadline.id}`);
         if (r.ok) {
           deadline = await r.json();
           await loadPendingRequest();
           render();
         } else {
-          window.location.reload();
+          // CREATE lifecycle deleted the entity — bounce to the list.
+          window.location.href = "/events?type=deadline";
         }
       } else {
         btn.disabled = false;
@@ -592,8 +878,14 @@ async function main() {
     notfound.style.display = "block";
     return;
   }
-  await Promise.all([loadProject(deadline.project_id), loadAllProjects(), loadPendingRequest()]);
-  if (deadline.rule_id) await loadRule(deadline.rule_id);
+  await Promise.all([
+    loadProject(deadline.project_id),
+    loadAllProjects(),
+    loadPendingRequest(),
+    loadAllRules(),
+    loadProceedingTypes(),
+  ]);
+  if (deadline.rule_id) rule = lookupRule(deadline.rule_id);
 
   // Load event types in parallel; render once ready (the picker re-renders
   // chips off the cached map, and the display element re-renders on the
@@ -614,6 +906,11 @@ async function main() {
     eventTypePicker = attachEventTypePicker(pickerHost, {
       initialIDs: deadline.event_type_ids ?? [],
       currentUserAdmin: me?.global_role === "global_admin",
+      onChange: () => {
+        // Type change shifts the Auto-resolved rule. Refresh the
+        // read-only display panel (no-op outside edit mode / Custom).
+        refreshRuleAutoDisplay();
+      },
     });
   }
 

frontend/src/client/deadlines-new.ts

@@ -1,16 +1,28 @@
-import { initI18n, t, tDyn } from "./i18n";
+import { initI18n, t, tDyn, getLang } from "./i18n";
 import { initSidebar } from "./sidebar";
-import { attachEventTypePicker, type PickerHandle } from "./event-types";
+import {
+  attachEventTypePicker,
+  eventTypeLabel,
+  fetchEventTypes,
+  type EventType,
+  type PickerHandle,
+} from "./event-types";
 import { projectIndent } from "./project-indent";
+import { formatRuleLabel, formatRuleLabelHTML } from "./rule-label";
 
 let eventTypePicker: PickerHandle | null = null;
 let currentUserAdmin = false;
+let eventTypesByID = new Map<string, EventType>();
 
 interface Project {
   id: string;
   reference?: string | null;
   title: string;
   path: string;
+  // Used by the Type→Rule resolver to narrow rule candidates to the
+  // project's own proceeding when one applies. Optional because clients
+  // and matter-level projects don't carry a proceeding type.
+  proceeding_type_id?: number | null;
 }
 
 interface DeadlineRule {
@@ -19,9 +31,37 @@ interface DeadlineRule {
   name: string;
   name_en: string;
   rule_code?: string;
+  legal_source?: string | null;
+  proceeding_type_id?: number | null;
+  sequence_order?: number;
+  // t-paliad-165 — canonical event_type for the rule's concept. The
+  // catalog is indexed by it so we can resolve Type → canonical Rule.
+  concept_default_event_type_id?: string | null;
 }
 
+interface ProceedingType {
+  id: number;
+  code: string;
+  name: string;
+  name_en?: string;
+  jurisdiction: string;
+  sort_order?: number;
+}
+
+// Rule mode (t-paliad-258 / m/paliad#89). The form has two states:
+//   auto   — rule_id resolved from the chosen event_type, rendered
+//            read-only as "Auto: Name · Citation".
+//   custom — free-text input; submits as custom_rule_text on the API.
+type RuleMode = "auto" | "custom";
+let ruleMode: RuleMode = "auto";
+
+let rulesByID = new Map<string, DeadlineRule>();
+let allRules: DeadlineRule[] = [];
+let proceedingTypesByID = new Map<number, ProceedingType>();
+let projectsByID = new Map<string, Project>();
+
 let preselectedProjectID = "";
+let preselectedProjectIDLocal = "";
 
 function esc(s: string): string {
   const d = document.createElement("div");
@@ -35,6 +75,13 @@ function showError(msg: string) {
   el.className = "form-msg form-msg-error";
 }
 
+function proceedingLabel(pt: ProceedingType | undefined): string {
+  if (!pt) return "";
+  const lang = getLang();
+  const name = (lang === "en" && pt.name_en) ? pt.name_en : pt.name;
+  return `${pt.jurisdiction} — ${name}`;
+}
+
 async function loadProjects() {
   const sel = document.getElementById("deadline-project") as HTMLSelectElement;
   const hint = document.getElementById("deadline-project-empty-hint")!;
@@ -42,6 +89,7 @@ async function loadProjects() {
     const resp = await fetch("/api/projects");
     if (!resp.ok) return;
     const projects: Project[] = await resp.json();
+    projectsByID = new Map(projects.map((p) => [p.id, p]));
     if (projects.length === 0) {
       hint.style.display = "";
       hint.innerHTML = `${esc(t("deadlines.field.akte.empty"))} <a href="/projects/new">${esc(t("deadlines.field.akte.empty.link"))}</a>`;
@@ -55,7 +103,7 @@ async function loadProjects() {
       const ref = p.reference || "";
       const indent = projectIndent(p.path);
       options.push(
-        `<option value="${esc(p.id)}"${isSelected}>${indent}${esc(ref)} \u2014 ${esc(p.title)}</option>`,
+        `<option value="${esc(p.id)}"${isSelected}>${indent}${esc(ref)} — ${esc(p.title)}</option>`,
       );
     }
     sel.innerHTML = options.join("");
@@ -64,36 +112,169 @@ async function loadProjects() {
   }
 }
 
-async function loadRules() {
-  // Optional: load rules so user can attach. We pull all rules; small set.
-  const sel = document.getElementById("deadline-rule") as HTMLSelectElement;
+async function loadProceedingTypes() {
   try {
-    const resp = await fetch("/api/deadline-rules");
+    const resp = await fetch("/api/proceeding-types-db");
     if (!resp.ok) return;
-    const rules: DeadlineRule[] = await resp.json();
-    const opts: string[] = [
-      `<option value="" data-i18n="deadlines.field.rule.none">${esc(t("deadlines.field.rule.none"))}</option>`,
-    ];
-    for (const r of rules) {
-      const code = r.rule_code || r.code || "";
-      const label = code ? `${code} \u2014 ${r.name}` : r.name;
-      opts.push(`<option value="${esc(r.id)}">${esc(label)}</option>`);
-    }
-    sel.innerHTML = opts.join("");
+    const types: ProceedingType[] = await resp.json();
+    proceedingTypesByID = new Map(types.map((pt) => [pt.id, pt]));
   } catch {
-    /* non-fatal — rule select stays at "no rule" */
+    /* non-fatal */
   }
 }
 
-function initBackLinks() {
-  if (preselectedProjectID) {
-    const back = document.getElementById("deadline-new-back") as HTMLAnchorElement;
-    const cancel = document.getElementById("deadline-new-cancel") as HTMLAnchorElement;
-    back.href = `/projects/${preselectedProjectID}/deadlines`;
-    cancel.href = `/projects/${preselectedProjectID}/deadlines`;
+async function loadRules() {
+  try {
+    const resp = await fetch("/api/deadline-rules");
+    if (!resp.ok) return;
+    allRules = (await resp.json()) as DeadlineRule[];
+    rulesByID = new Map(allRules.map((r) => [r.id, r]));
+  } catch {
+    /* non-fatal — rule display falls back to "—" */
   }
 }
 
+// resolveAutoRuleForType picks the best-match catalog rule for the
+// chosen event type, scoring by:
+//   1. project's proceeding_type_id (if known) — exact match wins,
+//   2. otherwise event_type.jurisdiction matches the rule's proceeding's
+//      jurisdiction (EPA→EPO canonicalised),
+//   3. otherwise the first candidate in canonical sequence_order.
+//
+// Returns null when no rule maps. Callers render that as "no Auto rule
+// available" so the user can flip to Custom or pick a different Type.
+function resolveAutoRuleForType(eventTypeID: string, projectID: string): DeadlineRule | null {
+  const candidates = allRules.filter((r) => r.concept_default_event_type_id === eventTypeID);
+  if (candidates.length === 0) return null;
+  if (candidates.length === 1) return candidates[0];
+
+  const project = projectID ? projectsByID.get(projectID) : undefined;
+  if (project?.proceeding_type_id) {
+    const exact = candidates.find((r) => r.proceeding_type_id === project.proceeding_type_id);
+    if (exact) return exact;
+  }
+
+  const et = eventTypesByID.get(eventTypeID);
+  if (et?.jurisdiction && et.jurisdiction !== "any") {
+    const want = et.jurisdiction === "EPO" ? "EPA" : et.jurisdiction;
+    const jurMatch = candidates.find((r) => {
+      const pt = r.proceeding_type_id ? proceedingTypesByID.get(r.proceeding_type_id) : undefined;
+      return pt?.jurisdiction === want;
+    });
+    if (jurMatch) return jurMatch;
+  }
+
+  return candidates[0];
+}
+
+// currentAutoRule returns the catalog rule the Auto mode would resolve
+// to for the current form state, or null when no Type is picked or no
+// rule maps. Centralised so the Auto display, submitForm, and the
+// Standardtitel button all agree on the same resolution.
+function currentAutoRule(): DeadlineRule | null {
+  const picked = eventTypePicker?.getIDs() ?? [];
+  if (picked.length !== 1) return null;
+  const projectID = (document.getElementById("deadline-project") as HTMLSelectElement | null)?.value || "";
+  return resolveAutoRuleForType(picked[0], projectID);
+}
+
+// refreshRuleAutoDisplay updates the read-only Auto display panel to
+// reflect the rule that would be saved in Auto mode. Hides itself when
+// the user is in Custom mode (the input takes its place).
+function refreshRuleAutoDisplay(): void {
+  const panel = document.getElementById("deadline-rule-auto-display");
+  const text = document.getElementById("deadline-rule-auto-text");
+  if (!panel || !text) return;
+  if (ruleMode !== "auto") {
+    panel.style.display = "none";
+    return;
+  }
+  panel.style.display = "";
+  const rule = currentAutoRule();
+  if (rule) {
+    // Canonical "Name · Citation" with muted citation (t-paliad-258 addendum).
+    text.innerHTML = formatRuleLabelHTML(rule, esc);
+    text.classList.remove("rule-auto-text--empty");
+    return;
+  }
+  const picked = eventTypePicker?.getIDs() ?? [];
+  const fallback = picked.length === 1
+    ? (t("deadlines.field.rule.auto_no_match") || "Keine Regel zur gewählten Verfahrenshandlung")
+    : (t("deadlines.field.rule.auto_pick_type") || "Wählen Sie zuerst eine Verfahrenshandlung");
+  text.textContent = fallback;
+  text.classList.add("rule-auto-text--empty");
+}
+
+function applyRuleModeUI(): void {
+  const toggleBtn = document.getElementById("deadline-rule-mode-toggle") as HTMLButtonElement | null;
+  const autoPanel = document.getElementById("deadline-rule-auto-display");
+  const customInput = document.getElementById("deadline-rule-custom-input") as HTMLInputElement | null;
+  if (!toggleBtn || !autoPanel || !customInput) return;
+  if (ruleMode === "auto") {
+    autoPanel.style.display = "";
+    customInput.style.display = "none";
+    toggleBtn.textContent = t("deadlines.field.rule.mode.toggle_to_custom") || "Eigene Regel eingeben";
+    toggleBtn.setAttribute("data-i18n", "deadlines.field.rule.mode.toggle_to_custom");
+  } else {
+    autoPanel.style.display = "none";
+    customInput.style.display = "";
+    toggleBtn.textContent = t("deadlines.field.rule.mode.toggle_to_auto") || "Zurück zu Auto";
+    toggleBtn.setAttribute("data-i18n", "deadlines.field.rule.mode.toggle_to_auto");
+  }
+  refreshRuleAutoDisplay();
+}
+
+function setRuleMode(mode: RuleMode): void {
+  ruleMode = mode;
+  applyRuleModeUI();
+  if (mode === "custom") {
+    const input = document.getElementById("deadline-rule-custom-input") as HTMLInputElement | null;
+    input?.focus();
+  }
+}
+
+// computeDefaultTitle — t-paliad-251 Part 4. Priority order picks the head:
+//   1. event_type label (when exactly one Typ chip is set)
+//   2. canonical rule name (when Auto resolves to a rule)
+//   3. custom rule text (when in Custom mode)
+//   4. proceeding type name (when project carries one)
+//   5. fallback i18n key
+// Suffix: " — <project-reference>" when not already in head.
+function computeDefaultTitle(): string {
+  const projectID = (document.getElementById("deadline-project") as HTMLSelectElement | null)?.value || "";
+  const project = projectID ? projectsByID.get(projectID) : undefined;
+  const picked = eventTypePicker?.getIDs() ?? [];
+
+  let head = "";
+  if (picked.length === 1) {
+    const et = eventTypesByID.get(picked[0]);
+    if (et) head = eventTypeLabel(et);
+  }
+  if (!head) {
+    if (ruleMode === "auto") {
+      const rule = currentAutoRule();
+      if (rule) head = formatRuleLabel(rule);
+    } else {
+      const customInput = document.getElementById("deadline-rule-custom-input") as HTMLInputElement | null;
+      const txt = customInput?.value.trim() || "";
+      if (txt) head = txt;
+    }
+  }
+  if (!head && project?.proceeding_type_id) {
+    const pt = proceedingTypesByID.get(project.proceeding_type_id);
+    if (pt) head = proceedingLabel(pt);
+  }
+  if (!head) {
+    head = t("deadlines.field.title.default_fallback");
+  }
+
+  const ref = project?.reference?.trim() || "";
+  if (ref && !head.includes(ref)) {
+    return `${head} — ${ref}`;
+  }
+  return head;
+}
+
 async function submitForm(e: Event) {
   e.preventDefault();
   const submitBtn = document.querySelector<HTMLButtonElement>("#deadline-new-form button[type=submit]")!;
@@ -102,7 +283,6 @@ async function submitForm(e: Event) {
   const projectID = (document.getElementById("deadline-project") as HTMLSelectElement).value;
   const title = (document.getElementById("deadline-title") as HTMLInputElement).value.trim();
   const due = (document.getElementById("deadline-due") as HTMLInputElement).value;
-  const ruleID = (document.getElementById("deadline-rule") as HTMLSelectElement).value;
   const notes = (document.getElementById("deadline-notes") as HTMLTextAreaElement).value.trim();
 
   if (!projectID || !title || !due) {
@@ -119,7 +299,15 @@ async function submitForm(e: Event) {
     due_date: due,
     source: "manual",
   };
-  if (ruleID) payload.rule_id = ruleID;
+  // Rule field: Auto resolves to rule_id, Custom sends the free text.
+  if (ruleMode === "auto") {
+    const rule = currentAutoRule();
+    if (rule) payload.rule_id = rule.id;
+  } else {
+    const customInput = document.getElementById("deadline-rule-custom-input") as HTMLInputElement | null;
+    const txt = customInput?.value.trim() || "";
+    if (txt) payload.custom_rule_text = txt;
+  }
   if (notes) payload.notes = notes;
   const eventTypeIDs = eventTypePicker?.getIDs() ?? [];
   if (eventTypeIDs.length > 0) payload.event_type_ids = eventTypeIDs;
@@ -137,8 +325,8 @@ async function submitForm(e: Event) {
       return;
     }
     const created = await resp.json();
-    if (preselectedProjectID) {
-      window.location.href = `/projects/${preselectedProjectID}/deadlines`;
+    if (preselectedProjectIDLocal) {
+      window.location.href = `/projects/${preselectedProjectIDLocal}/deadlines`;
     } else {
       window.location.href = `/deadlines/${created.id}`;
     }
@@ -160,6 +348,16 @@ function detectPreselect() {
   if (fromQuery) preselectedProjectID = fromQuery;
 }
 
+function initBackLinks() {
+  if (preselectedProjectID) {
+    const back = document.getElementById("deadline-new-back") as HTMLAnchorElement;
+    const cancel = document.getElementById("deadline-new-cancel") as HTMLAnchorElement;
+    back.href = `/projects/${preselectedProjectID}/deadlines`;
+    cancel.href = `/projects/${preselectedProjectID}/deadlines`;
+  }
+  preselectedProjectIDLocal = preselectedProjectID;
+}
+
 async function loadMe() {
   try {
     const resp = await fetch("/api/me");
@@ -173,8 +371,6 @@ async function loadMe() {
 
 // t-paliad-154 — fetch the effective approval policy for (project,
 // deadline, create) and reveal the form-time hint when it applies.
-// Hidden when no policy applies. Re-runs on project change so the hint
-// updates if the user picks a different project mid-form.
 async function refreshApprovalHint(): Promise<void> {
   const hint = document.getElementById("deadline-approval-hint");
   const text = document.getElementById("deadline-approval-hint-text");
@@ -193,7 +389,6 @@ async function refreshApprovalHint(): Promise<void> {
       hint.style.display = "none";
       return;
     }
-    // t-paliad-160 split-grammar (with M1 legacy fallback).
     const eff = await resp.json() as {
       requires_approval?: boolean;
       min_role?: string | null;
@@ -228,16 +423,51 @@ document.addEventListener("DOMContentLoaded", async () => {
   // Default due to today
   const dueInput = document.getElementById("deadline-due") as HTMLInputElement;
   if (!dueInput.value) dueInput.value = new Date().toISOString().split("T")[0];
-  await Promise.all([loadProjects(), loadRules(), loadMe()]);
+
+  await Promise.all([loadProjects(), loadProceedingTypes(), loadRules(), loadMe()]);
+
   const pickerHost = document.getElementById("deadline-event-types");
   if (pickerHost) {
     eventTypePicker = attachEventTypePicker(pickerHost, {
       currentUserAdmin,
+      onChange: () => {
+        // Type change shifts which Auto rule resolves; re-render the
+        // read-only Auto display panel.
+        refreshRuleAutoDisplay();
+      },
     });
   }
-  // Wire approval-hint refresh: on first render + on project change.
+
+  // Preload event_types for the Auto display + Standardtitel resolver.
+  fetchEventTypes()
+    .then((types) => {
+      eventTypesByID = new Map(types.map((et) => [et.id, et]));
+      refreshRuleAutoDisplay();
+    })
+    .catch(() => {/* non-fatal */});
+
+  // Rule mode toggle.
+  document.getElementById("deadline-rule-mode-toggle")?.addEventListener("click", () => {
+    setRuleMode(ruleMode === "auto" ? "custom" : "auto");
+  });
+
+  applyRuleModeUI();
+
+  // Approval-hint refresh: on first render + on project change.
   void refreshApprovalHint();
   document.getElementById("deadline-project")?.addEventListener("change", () => {
     void refreshApprovalHint();
+    // Project change can shift which Auto rule resolves (via the
+    // project's proceeding_type_id).
+    refreshRuleAutoDisplay();
+  });
+
+  // t-paliad-251 Part 4 — Standardtitel button.
+  document.getElementById("deadline-title-default-btn")?.addEventListener("click", () => {
+    const titleInput = document.getElementById("deadline-title") as HTMLInputElement | null;
+    if (!titleInput) return;
+    const derived = computeDefaultTitle();
+    if (derived) titleInput.value = derived;
+    titleInput.focus();
   });
 });

frontend/src/client/event-types.ts

@@ -686,6 +686,33 @@ export function openBrowseEventTypesModal(
   return new Promise<string[] | null>((resolve) => {
     let selected = new Set<string>(opts.initialIDs);
     let searchQuery = "";
+    // t-paliad-251 — court-type filter chips. `null` = "Alle" (any
+    // jurisdiction). Any non-null value matches event_types.jurisdiction;
+    // "any" is mapped to NULL/missing rows via jurisdictionMatches().
+    let activeJurisdiction: string | null = null;
+
+    // Surface every jurisdiction present in the data — "any" stays bucketed
+    // separately so users still have a "show generic-only" chip. EPA is
+    // canonicalised to EPO in event_types (see mig 074); the chip label
+    // shows EPA to match the legal vocabulary the lawyers use.
+    const jurisdictionsPresent = new Set<string>();
+    for (const et of opts.types) {
+      const j = (et.jurisdiction ?? "").trim();
+      if (j) jurisdictionsPresent.add(j);
+    }
+    const JURISDICTION_ORDER = ["UPC", "EPO", "DPMA", "DE", "any"];
+    const chipJurisdictions = JURISDICTION_ORDER.filter((j) => jurisdictionsPresent.has(j));
+    // Any jurisdiction in the data that isn't in our ordered list lands at
+    // the end so the chip row never silently drops a court flavour.
+    for (const j of jurisdictionsPresent) {
+      if (!chipJurisdictions.includes(j)) chipJurisdictions.push(j);
+    }
+
+    function chipLabel(j: string): string {
+      if (j === "EPO") return "EPA";
+      if (j === "any") return t("event_types.browse.jurisdiction.none");
+      return j;
+    }
 
     const overlay = document.createElement("div");
     overlay.className = "modal-overlay event-type-browse-overlay";
@@ -694,6 +721,15 @@ export function openBrowseEventTypesModal(
         <div class="event-type-browse-header">
           <h2 id="event-type-browse-title">${esc(t("event_types.browse.title"))}</h2>
           <input type="text" class="event-type-browse-search" data-role="search" placeholder="${esc(t("event_types.browse.search"))}" autocomplete="off" />
+          <div class="event-type-browse-chips" data-role="chips" role="group" aria-label="${esc(t("event_types.browse.jurisdiction.filter_label"))}">
+            <button type="button" class="event-type-browse-chip event-type-browse-chip--active" data-jurisdiction="" data-role="chip-all">${esc(t("event_types.browse.jurisdiction.all"))}</button>
+            ${chipJurisdictions
+              .map(
+                (j) =>
+                  `<button type="button" class="event-type-browse-chip" data-jurisdiction="${esc(j)}">${esc(chipLabel(j))}</button>`,
+              )
+              .join("")}
+          </div>
         </div>
         <div class="event-type-browse-list" data-role="list" tabindex="-1"></div>
         <div class="event-type-browse-actions">
@@ -711,6 +747,7 @@ export function openBrowseEventTypesModal(
     const countEl = overlay.querySelector<HTMLElement>("[data-role=count]")!;
     const cancelBtn = overlay.querySelector<HTMLButtonElement>("[data-role=cancel]")!;
     const applyBtn = overlay.querySelector<HTMLButtonElement>("[data-role=apply]")!;
+    const chipButtons = overlay.querySelectorAll<HTMLButtonElement>(".event-type-browse-chip");
 
     const groups = groupByCategory(opts.types);
 
@@ -721,6 +758,12 @@ export function openBrowseEventTypesModal(
       return j;
     }
 
+    function jurisdictionMatches(et: EventType): boolean {
+      if (activeJurisdiction === null) return true;
+      const j = (et.jurisdiction ?? "").trim();
+      return j === activeJurisdiction;
+    }
+
     function updateCount() {
       countEl.textContent = t("event_types.browse.selected_count").replace(
         "{n}",
@@ -731,6 +774,7 @@ export function openBrowseEventTypesModal(
     function renderList() {
       const q = searchQuery.trim().toLowerCase();
       const matches = (et: EventType) => {
+        if (!jurisdictionMatches(et)) return false;
         if (!q) return true;
         return (
           et.label_de.toLowerCase().includes(q) ||
@@ -783,6 +827,16 @@ export function openBrowseEventTypesModal(
       renderList();
     });
 
+    chipButtons.forEach((btn) => {
+      btn.addEventListener("click", () => {
+        const raw = btn.dataset.jurisdiction ?? "";
+        activeJurisdiction = raw === "" ? null : raw;
+        chipButtons.forEach((b) => b.classList.remove("event-type-browse-chip--active"));
+        btn.classList.add("event-type-browse-chip--active");
+        renderList();
+      });
+    });
+
     function close(value: string[] | null) {
       document.removeEventListener("keydown", onKey);
       overlay.remove();

frontend/src/client/events.ts

@@ -8,6 +8,8 @@ import {
   type FilterHandle,
 } from "./event-types";
 import { projectIndent } from "./project-indent";
+import { mountCalendar, type CalendarHandle, type CalendarItem } from "./calendar/mount-calendar";
+import { formatRuleLabelHTML, formatCustomRuleLabelHTML } from "./rule-label";
 
 // Two-eyes glyph 👀 inside .approval-pill--icon. m's 2026-05-08 follow-
 // up: "two eyes instead of the one." Emoji rather than SVG keeps the
@@ -65,6 +67,9 @@ interface EventListItem {
   rule_code?: string;
   rule_name?: string;
   rule_name_en?: string;
+  // t-paliad-258 — free-text rule label when the deadline was created
+  // via the Custom rule path. Mutually exclusive with rule_id.
+  custom_rule_text?: string;
   event_type_ids?: string[];
 
   // appointment-only
@@ -125,12 +130,16 @@ const STATUS_OPTIONS_DEADLINE: StatusOption[] = [
   { value: "completed", key: "deadlines.filter.completed" },
 ];
 
+// Appointment status options — m/paliad#54: the legacy 'upcoming' /
+// "Ab heute" option was a UI lie (backend never narrowed past events for
+// appointments) and is removed. 'today' is the sane default — matches the
+// dashboard tile. 'all' stays as the explicit opt-in for past events.
 const STATUS_OPTIONS_APPOINTMENT: StatusOption[] = [
-  { value: "all", key: "events.filter.status.all" },
   { value: "today", key: "deadlines.filter.today" },
   { value: "this_week", key: "deadlines.filter.thisweek" },
   { value: "next_week", key: "deadlines.filter.nextweek" },
   { value: "later", key: "deadlines.filter.later" },
+  { value: "all", key: "events.filter.status.all" },
 ];
 
 function statusOptionsFor(type: EventTypeChoice): StatusOption[] {
@@ -139,7 +148,7 @@ function statusOptionsFor(type: EventTypeChoice): StatusOption[] {
 }
 
 function defaultStatusFor(type: EventTypeChoice): string {
-  return type === "appointment" ? "all" : "pending";
+  return type === "appointment" ? "today" : "pending";
 }
 
 let currentType: EventTypeChoice = "deadline";
@@ -153,8 +162,10 @@ let me: Me | null = null;
 let eventTypeFilter: FilterHandle | null = null;
 let eventTypeByID: Map<string, EventType> = new Map();
 let loadedOK = false;
-let calYear = 0;
-let calMonth = 0;
+// Calendar handle is created lazily when /events first switches into the
+// Kalender view (t-paliad-224). The handle owns its own month/week/day
+// state + ?cal_view / ?cal_date URL contract via mountCalendar.
+let calendar: CalendarHandle | null = null;
 
 function urlParams(): URLSearchParams {
   return new URLSearchParams(window.location.search);
@@ -257,13 +268,26 @@ function urgencyClass(item: EventListItem): string {
 
 function ruleDisplay(item: EventListItem): string {
   if (item.type !== "deadline") return "";
-  // Prefer the saved citation (RoP.023, R.151) over the rule name —
-  // REGEL is meant for the legal reference, not the rule's display
-  // name (which is the title column's job).
-  if (item.rule_code && item.rule_code.trim()) return esc(item.rule_code);
-  const lang = getLang();
-  const localized = lang === "en" ? item.rule_name_en : item.rule_name;
-  if (localized && localized.trim()) return esc(localized);
+  // t-paliad-258 addendum — canonical display contract: Name primary,
+  // Citation muted secondary ("Notice of Appeal · UPC.RoP.220.1").
+  // Custom rules render the lawyer's free text + a "Custom" badge.
+  // Legacy rule-code-only saves (Fristenrechner, no rule_id) still
+  // show the bare citation as last-resort fallback.
+  const hasName = (item.rule_name && item.rule_name.trim()) ||
+    (item.rule_name_en && item.rule_name_en.trim());
+  if (hasName || (item.rule_code && item.rule_code.trim())) {
+    return formatRuleLabelHTML(
+      {
+        name: item.rule_name || "",
+        name_en: item.rule_name_en,
+        rule_code: item.rule_code,
+      },
+      esc,
+    );
+  }
+  if (item.custom_rule_text && item.custom_rule_text.trim()) {
+    return formatCustomRuleLabelHTML(item.custom_rule_text, esc);
+  }
   return "&mdash;";
 }
 
@@ -425,12 +449,13 @@ function hideTableAndCalendar() {
   const calWrap = document.getElementById("events-calendar-wrap");
   if (tableWrap) tableWrap.style.display = "none";
   if (calWrap) calWrap.hidden = true;
+  teardownCalendar();
 }
 
 function render() {
   if (!loadedOK) return;
   if (currentView === "calendar") {
-    renderCalendar();
+    renderCalendarView();
   } else {
     renderTable();
   }
@@ -553,135 +578,57 @@ function renderRow(item: EventListItem, showReopen: boolean): string {
   </tr>`;
 }
 
-// itemDateISO returns the per-item bucketing date (YYYY-MM-DD) used when
-// plotting an event onto the calendar. Deadlines bucket on due_date;
-// appointments on start_at's local-date component.
-function itemDateISO(item: EventListItem): string {
+// toCalendarItem adapts an EventListItem to the canonical CalendarItem
+// shape consumed by mountCalendar (t-paliad-224). Bucketing date matches
+// the pre-refactor behaviour: deadlines bucket on due_date (fallback to
+// event_date); appointments bucket on start_at (fallback to event_date).
+function toCalendarItem(item: EventListItem): CalendarItem {
+  let bucketDate: string;
   if (item.type === "deadline") {
-    const src = item.due_date ?? item.event_date;
-    return src.slice(0, 10);
+    bucketDate = item.due_date ?? item.event_date;
+  } else if (item.start_at) {
+    bucketDate = item.start_at;
+  } else {
+    bucketDate = item.event_date;
   }
-  if (!item.start_at) return item.event_date.slice(0, 10);
-  const d = new Date(item.start_at);
-  return `${d.getFullYear()}-${String(d.getMonth() + 1).padStart(2, "0")}-${String(d.getDate()).padStart(2, "0")}`;
+  return {
+    kind: item.type,
+    id: item.id,
+    title: item.title,
+    event_date: bucketDate,
+    project_id: item.project_id,
+    project_title: item.project_title,
+    project_reference: item.project_reference,
+  };
 }
 
-function isoDate(year: number, month: number, day: number): string {
-  return `${year}-${String(month + 1).padStart(2, "0")}-${String(day).padStart(2, "0")}`;
-}
-
-function fmtMonthYear(year: number, month: number): string {
-  return `${tDyn(`cal.month.${month}`)} ${year}`;
-}
-
-function calDotClass(item: EventListItem): string {
-  // Per-item dot colour. Deadlines reuse the existing urgency palette;
-  // appointments get their own colour so they're visually distinct from
-  // deadlines on a mixed (Beides) calendar.
-  if (item.type === "appointment") return "events-cal-dot-appointment";
-  return urgencyClass(item).replace("frist-urgency-", "frist-urgency-");
-}
-
-function renderCalendar() {
-  const wrap = document.getElementById("events-calendar-wrap")!;
-  const grid = document.getElementById("events-cal-grid")!;
-  const empty = document.getElementById("events-cal-empty") as HTMLElement;
-  const monthLabel = document.getElementById("events-cal-month-label")!;
+function renderCalendarView() {
+  const host = document.getElementById("events-calendar-wrap");
+  if (!host) return;
   const tableEmpty = document.getElementById("events-empty")!;
   const tableEmptyFiltered = document.getElementById("events-empty-filtered")!;
-
-  // Calendar always renders the visible month from allItems, regardless of
-  // pristine vs filtered state — empty calendar is allowed (the per-month
-  // empty hint communicates "no items in this month" without confusing it
-  // with the table-mode "no items at all" empty state).
   tableEmpty.style.display = "none";
   tableEmptyFiltered.style.display = "none";
-  wrap.hidden = false;
+  (host as HTMLElement).hidden = false;
 
-  monthLabel.textContent = fmtMonthYear(calYear, calMonth);
-
-  const firstDay = new Date(calYear, calMonth, 1);
-  const jsWeekday = firstDay.getDay();
-  const offset = (jsWeekday + 6) % 7;
-  const daysInMonth = new Date(calYear, calMonth + 1, 0).getDate();
-  const today = new Date();
-  const todayISO = isoDate(today.getFullYear(), today.getMonth(), today.getDate());
-
-  // Bucket items by ISO date once, so day-cell rendering is O(d) not O(d*n).
-  const byDate = new Map<string, EventListItem[]>();
-  for (const item of allItems) {
-    const iso = itemDateISO(item);
-    const list = byDate.get(iso);
-    if (list) list.push(item);
-    else byDate.set(iso, [item]);
+  const items = allItems.map(toCalendarItem);
+  if (calendar) {
+    calendar.update(items);
+    return;
   }
-
-  const cells: string[] = [];
-  for (let i = 0; i < offset; i++) {
-    cells.push(`<div class="frist-cal-cell frist-cal-cell-empty"></div>`);
-  }
-  for (let day = 1; day <= daysInMonth; day++) {
-    const iso = isoDate(calYear, calMonth, day);
-    const items = byDate.get(iso) ?? [];
-    const isToday = iso === todayISO;
-    const dots = items
-      .slice(0, 4)
-      .map((it) => `<span class="frist-cal-dot ${calDotClass(it)}"></span>`)
-      .join("");
-    const more = items.length > 4 ? `<span class="frist-cal-more">+${items.length - 4}</span>` : "";
-    cells.push(
-      `<div class="frist-cal-cell${isToday ? " frist-cal-today" : ""}${items.length > 0 ? " frist-cal-cell-has" : ""}" data-iso="${iso}">
-        <span class="frist-cal-day">${day}</span>
-        <div class="frist-cal-dots">${dots}${more}</div>
-      </div>`,
-    );
-  }
-  grid.innerHTML = cells.join("");
-
-  grid.querySelectorAll<HTMLElement>(".frist-cal-cell-has").forEach((cell) => {
-    cell.addEventListener("click", () => openCalPopup(cell.dataset.iso!, byDate.get(cell.dataset.iso!) ?? []));
+  // urlState=true: the Kalender tab persists its month/week/day + anchor
+  // in ?cal_view + ?cal_date so a refresh / shared link lands on the same
+  // calendar state (per t-paliad-224 §11 Q3 head decision).
+  calendar = mountCalendar(host as HTMLElement, items, {
+    urlState: true,
+    defaultView: "month",
   });
-
-  const monthStart = isoDate(calYear, calMonth, 1);
-  const monthEnd = isoDate(calYear, calMonth, daysInMonth);
-  const hasInMonth = allItems.some((it) => {
-    const iso = itemDateISO(it);
-    return iso >= monthStart && iso <= monthEnd;
-  });
-  empty.hidden = hasInMonth;
 }
 
-function openCalPopup(iso: string, items: EventListItem[]) {
-  if (items.length === 0) return;
-  const popup = document.getElementById("events-cal-popup") as HTMLElement;
-  const dateEl = document.getElementById("events-cal-popup-date")!;
-  const list = document.getElementById("events-cal-popup-list")!;
-
-  const d = new Date(iso + "T00:00:00");
-  dateEl.textContent = d.toLocaleDateString(getLang() === "de" ? "de-DE" : "en-GB", {
-    weekday: "long",
-    year: "numeric",
-    month: "long",
-    day: "numeric",
-  });
-
-  list.innerHTML = items
-    .map((it) => {
-      const cls = calDotClass(it);
-      const href = it.type === "deadline" ? `/deadlines/${esc(it.id)}` : `/appointments/${esc(it.id)}`;
-      const projectHref = it.project_id ? `/projects/${esc(it.project_id)}` : "";
-      const projectLabel = it.project_reference ?? "";
-      const projectCell = projectHref
-        ? `<a href="${projectHref}" class="frist-cal-popup-akte">${esc(projectLabel)}</a>`
-        : "";
-      return `<li class="frist-cal-popup-item">
-        <span class="frist-cal-dot ${cls}"></span>
-        <a href="${href}" class="frist-cal-popup-title">${rowTypeChip(it)} ${esc(it.title)}</a>
-        ${projectCell}
-      </li>`;
-    })
-    .join("");
-  popup.style.display = "flex";
+function teardownCalendar() {
+  if (!calendar) return;
+  calendar.destroy();
+  calendar = null;
 }
 
 function applyView() {
@@ -702,12 +649,18 @@ function applyView() {
   // Cards view = the original layout (5-card summary + table).
   // List view = no summary cards, table only — gives more vertical space
   //   and matches users' mental model of a flat list.
-  // Calendar view = month grid; cards + table both hidden.
+  // Calendar view = mountCalendar() canon (month/week/day); cards + table
+  //   both hidden. The handle is torn down when the user leaves Kalender
+  //   so its URL state isn't reapplied to other shapes.
   summary.style.display = currentView === "cards" ? "" : "none";
   tableWrap.style.display = currentView === "calendar" ? "none" : "";
   calWrap.hidden = currentView !== "calendar";
 
-  if (currentView === "calendar" && loadedOK) renderCalendar();
+  if (currentView === "calendar") {
+    if (loadedOK) renderCalendarView();
+  } else {
+    teardownCalendar();
+  }
 }
 
 function wireRowHandlers(tbody: HTMLElement) {
@@ -728,6 +681,13 @@ function wireRowHandlers(tbody: HTMLElement) {
     if (cb && !cb.disabled) {
       cb.addEventListener("change", async () => {
         if (!cb.checked) return;
+        const titleCell = row.querySelector<HTMLElement>(".events-title");
+        const title = (titleCell?.textContent || "").trim();
+        const msg = t("deadlines.complete.confirm").replace("{title}", title || "?");
+        if (!window.confirm(msg)) {
+          cb.checked = false;
+          return;
+        }
         cb.disabled = true;
         try {
           const resp = await fetch(`/api/deadlines/${id}/complete`, { method: "PATCH" });
@@ -1002,12 +962,10 @@ function initFilters() {
 }
 
 function initView() {
-  // Calendar always opens on the current month — month navigation is
-  // local to the view (cheap pagination, doesn't refetch).
-  const now = new Date();
-  calYear = now.getFullYear();
-  calMonth = now.getMonth();
-
+  // Kalender state (view + anchor) lives inside mountCalendar; no
+  // events-page-level wiring needed. The view chips below switch
+  // between Karten / Liste / Kalender; applyView() handles the
+  // mount + teardown.
   document.querySelectorAll<HTMLButtonElement>("[data-event-view]").forEach((btn) => {
     btn.addEventListener("click", () => {
       const next = btn.dataset.eventView as EventView;
@@ -1017,31 +975,6 @@ function initView() {
       syncURLParams();
     });
   });
-
-  document.getElementById("events-cal-prev")?.addEventListener("click", () => {
-    calMonth -= 1;
-    if (calMonth < 0) { calMonth = 11; calYear -= 1; }
-    renderCalendar();
-  });
-  document.getElementById("events-cal-next")?.addEventListener("click", () => {
-    calMonth += 1;
-    if (calMonth > 11) { calMonth = 0; calYear += 1; }
-    renderCalendar();
-  });
-  document.getElementById("events-cal-today")?.addEventListener("click", () => {
-    const t = new Date();
-    calYear = t.getFullYear();
-    calMonth = t.getMonth();
-    renderCalendar();
-  });
-
-  const popup = document.getElementById("events-cal-popup") as HTMLElement;
-  document.getElementById("events-cal-popup-close")?.addEventListener("click", () => {
-    popup.style.display = "none";
-  });
-  popup?.addEventListener("click", (e) => {
-    if (e.target === popup) popup.style.display = "none";
-  });
 }
 
 function initSummaryCards() {

frontend/src/client/filter-bar/axes.ts

@@ -0,0 +1,574 @@
+// Per-axis renderers for the FilterBar — t-paliad-163.
+//
+// Each axis is a small, self-contained render function that takes the
+// current BarState slice and a callback. The bar's mountFilterBar
+// composes them in the order declared on the surface.
+//
+// Reuses existing CSS classes wherever possible:
+//   - .agenda-chip / .agenda-chip-active  (chip cluster pattern)
+//   - .filter-group                       (label + control wrapping)
+//   - .akten-multi-trigger / .multi-anchor / .multi-panel
+//
+// New classes are scoped under .filter-bar-* so they don't bleed.
+
+import { t, tDyn, type I18nKey } from "../i18n";
+import { mountDateRangePicker } from "../date-range-picker";
+import {
+  ALL_HORIZONS as DRP_ALL_HORIZONS,
+  type TimeHorizon as DRPTimeHorizon,
+  type TimeSpec as DRPTimeSpec,
+} from "../date-range-picker-pure";
+import type { BarState, AxisKey, InboxFocus } from "./types";
+
+export interface AxisCtx {
+  // Read the current value for this axis.
+  get<K extends keyof BarState>(key: K): BarState[K];
+  // Patch one or more axis values + trigger re-run.
+  patch(delta: Partial<BarState>): void;
+}
+
+// RenderAxisOpts — per-surface tuning the bar threads through to axis
+// renderers. Currently only time-axis chip presets; future axes can grow
+// here without changing every call site.
+export interface RenderAxisOpts {
+  timePresets?: NonNullable<BarState["time"]>["horizon"][];
+}
+
+// renderAxis returns the HTML element for a single axis. The bar's
+// mountFilterBar appends the result to its internal toolbar. Returns
+// null when the axis is ignored (e.g. surface didn't declare it).
+export function renderAxis(axis: AxisKey, ctx: AxisCtx, opts?: RenderAxisOpts): HTMLElement | null {
+  switch (axis) {
+    case "time":                  return renderTimeAxis(ctx, opts?.timePresets);
+    case "project":               return null; // populated lazily — see attachProjectAxis below
+    case "personal_only":         return renderPersonalOnlyAxis(ctx);
+    case "approval_viewer_role":  return renderApprovalRoleAxis(ctx);
+    case "approval_status":       return renderApprovalStatusAxis(ctx);
+    case "approval_entity_type":  return renderApprovalEntityTypeAxis(ctx);
+    case "deadline_status":       return renderDeadlineStatusAxis(ctx);
+    case "appointment_type":      return renderAppointmentTypeAxis(ctx);
+    case "project_event_kind":    return renderProjectEventKindAxis(ctx);
+    case "timeline_status":       return renderTimelineStatusAxis(ctx);
+    case "timeline_track":        return renderTimelineTrackAxis(ctx);
+    case "shape":                 return renderShapeAxis(ctx);
+    case "density":               return renderDensityAxis(ctx);
+    case "sort":                  return renderSortAxis(ctx);
+    case "unread_only":           return renderUnreadOnlyAxis(ctx);
+    case "inbox_focus":           return renderInboxFocusAxis(ctx);
+
+    // Per-source predicates that need their own widgets and a roundtrip
+    // through fetched option lists. Phase 2+ will fill these in by
+    // wiring the existing event-types component.
+    case "deadline_event_type":
+      return null;
+  }
+}
+
+// ----------------------------------------------------------------------
+// time — symmetric date-range picker (t-paliad-248, replaces the t-163
+// chip-cluster + disabled Anpassen stub). The picker emits a TimeSpec
+// (horizon + optional custom from/to); the bar patches that onto
+// BarState.time directly.
+// ----------------------------------------------------------------------
+
+type TimeHorizonValue = NonNullable<BarState["time"]>["horizon"];
+
+// Default chip set when the surface doesn't override. Matches the
+// forward-leaning bias of the legacy filter-bar default (the universal
+// substrate is more often used for "what's coming up" than "what just
+// happened") but now covers the full symmetric fan plus past_30d for
+// quick recent-history lookups.
+const DEFAULT_TIME_PRESETS: TimeHorizonValue[] = [
+  "past_30d", "past_7d", "any", "next_7d", "next_30d", "next_90d", "custom",
+];
+
+function renderTimeAxis(ctx: AxisCtx, presetOverride?: TimeHorizonValue[]): HTMLElement {
+  const wrap = group("views.bar.label.time");
+  const presetSource = presetOverride && presetOverride.length ? presetOverride : DEFAULT_TIME_PRESETS;
+  // The picker's pure module owns the complete chip set; we narrow it
+  // here to whatever this surface declares (preserving the surface's
+  // chip order so timePresets remains the override knob it always was).
+  const presets: DRPTimeHorizon[] = presetSource.flatMap((p) =>
+    DRP_ALL_HORIZONS.includes(p as DRPTimeHorizon) ? [p as DRPTimeHorizon] : [],
+  );
+
+  const current = ctx.get("time");
+  const initialValue: DRPTimeSpec = current
+    ? { horizon: current.horizon as DRPTimeHorizon, from: current.from, to: current.to }
+    : { horizon: "any" };
+
+  const picker = mountDateRangePicker({
+    value: initialValue,
+    onChange(next) {
+      // The bar treats `any` as "no time overlay" (matches the legacy
+      // chip-cluster's behaviour) so the BarState stays minimal when
+      // the user lands on the centre ALLES button.
+      if (next.horizon === "any") {
+        ctx.patch({ time: undefined });
+        return;
+      }
+      ctx.patch({
+        time: {
+          horizon: next.horizon as TimeHorizonValue,
+          from: next.horizon === "custom" ? next.from : undefined,
+          to:   next.horizon === "custom" ? next.to   : undefined,
+        },
+      });
+    },
+    defaultHorizon: "any",
+    presets,
+    surface: "filter-bar.time",
+    labelPrefix: t("views.bar.label.time"),
+  });
+
+  wrap.appendChild(picker.element);
+  return wrap;
+}
+
+// ----------------------------------------------------------------------
+// personal_only — single chip (binary)
+// ----------------------------------------------------------------------
+
+function renderPersonalOnlyAxis(ctx: AxisCtx): HTMLElement {
+  const wrap = group("views.bar.label.personal");
+  const chip = chipBtn(t("views.bar.personal.on"), !!ctx.get("personal_only"));
+  chip.addEventListener("click", () => {
+    ctx.patch({ personal_only: !ctx.get("personal_only") });
+  });
+  wrap.appendChild(chip);
+  return wrap;
+}
+
+// ----------------------------------------------------------------------
+// approval_viewer_role — chip cluster (3 mutually exclusive)
+// ----------------------------------------------------------------------
+
+const APPROVAL_ROLES: Array<{ value: NonNullable<BarState["approval_viewer_role"]>; key: I18nKey }> = [
+  { value: "approver_eligible", key: "views.bar.approval_role.approver_eligible" },
+  { value: "self_requested",    key: "views.bar.approval_role.self_requested" },
+  { value: "any_visible",       key: "views.bar.approval_role.any_visible" },
+];
+
+function renderApprovalRoleAxis(ctx: AxisCtx): HTMLElement {
+  const wrap = group("views.bar.label.approval_role");
+  const row = chipRow();
+  // Default to "any_visible" so the surface lands on a populated view
+  // for every user. The InboxSystemView's base spec also defaults here;
+  // these two defaults must stay in sync — otherwise the chip and the
+  // server narrow disagree on the empty URL.
+  const current = ctx.get("approval_viewer_role") ?? "any_visible";
+  for (const role of APPROVAL_ROLES) {
+    const chip = chipBtn(t(role.key), role.value === current);
+    chip.addEventListener("click", () => {
+      ctx.patch({ approval_viewer_role: role.value });
+    });
+    row.appendChild(chip);
+  }
+  wrap.appendChild(row);
+  return wrap;
+}
+
+// ----------------------------------------------------------------------
+// approval_status — chip cluster (multi-select)
+// ----------------------------------------------------------------------
+
+const APPROVAL_STATUSES: Array<{ value: string; key: I18nKey }> = [
+  { value: "pending",            key: "views.bar.approval_status.pending" },
+  { value: "approved",           key: "views.bar.approval_status.approved" },
+  { value: "rejected",           key: "views.bar.approval_status.rejected" },
+  { value: "revoked",            key: "views.bar.approval_status.revoked" },
+  { value: "changes_requested",  key: "views.bar.approval_status.changes_requested" },
+];
+
+function renderApprovalStatusAxis(ctx: AxisCtx): HTMLElement {
+  const wrap = group("views.bar.label.approval_status");
+  const row = chipRow();
+  const all = chipBtn(t("views.bar.common.all"), !ctx.get("approval_status")?.length);
+  all.addEventListener("click", () => ctx.patch({ approval_status: undefined }));
+  row.appendChild(all);
+  const current = new Set(ctx.get("approval_status") ?? []);
+  for (const status of APPROVAL_STATUSES) {
+    const chip = chipBtn(t(status.key), current.has(status.value));
+    chip.addEventListener("click", () => {
+      if (current.has(status.value)) current.delete(status.value);
+      else current.add(status.value);
+      ctx.patch({ approval_status: current.size ? [...current] : undefined });
+    });
+    row.appendChild(chip);
+  }
+  wrap.appendChild(row);
+  return wrap;
+}
+
+// ----------------------------------------------------------------------
+// approval_entity_type — chip pair (multi-select; deadline / appointment)
+// ----------------------------------------------------------------------
+
+const APPROVAL_ENTITY_TYPES: Array<{ value: string; key: I18nKey }> = [
+  { value: "deadline",    key: "views.bar.approval_entity.deadline" },
+  { value: "appointment", key: "views.bar.approval_entity.appointment" },
+];
+
+function renderApprovalEntityTypeAxis(ctx: AxisCtx): HTMLElement {
+  const wrap = group("views.bar.label.approval_entity");
+  const row = chipRow();
+  const all = chipBtn(t("views.bar.common.all"), !ctx.get("approval_entity_type")?.length);
+  all.addEventListener("click", () => ctx.patch({ approval_entity_type: undefined }));
+  row.appendChild(all);
+  const current = new Set(ctx.get("approval_entity_type") ?? []);
+  for (const ent of APPROVAL_ENTITY_TYPES) {
+    const chip = chipBtn(t(ent.key), current.has(ent.value));
+    chip.addEventListener("click", () => {
+      if (current.has(ent.value)) current.delete(ent.value);
+      else current.add(ent.value);
+      ctx.patch({ approval_entity_type: current.size ? [...current] : undefined });
+    });
+    row.appendChild(chip);
+  }
+  wrap.appendChild(row);
+  return wrap;
+}
+
+// ----------------------------------------------------------------------
+// deadline_status — chip cluster (multi-select)
+// ----------------------------------------------------------------------
+
+const DEADLINE_STATUSES: Array<{ value: string; key: I18nKey }> = [
+  { value: "pending",   key: "views.bar.deadline_status.pending" },
+  { value: "completed", key: "views.bar.deadline_status.completed" },
+];
+
+function renderDeadlineStatusAxis(ctx: AxisCtx): HTMLElement {
+  const wrap = group("views.bar.label.deadline_status");
+  const row = chipRow();
+  const all = chipBtn(t("views.bar.common.all"), !ctx.get("deadline_status")?.length);
+  all.addEventListener("click", () => ctx.patch({ deadline_status: undefined }));
+  row.appendChild(all);
+  const current = new Set(ctx.get("deadline_status") ?? []);
+  for (const s of DEADLINE_STATUSES) {
+    const chip = chipBtn(t(s.key), current.has(s.value));
+    chip.addEventListener("click", () => {
+      if (current.has(s.value)) current.delete(s.value);
+      else current.add(s.value);
+      ctx.patch({ deadline_status: current.size ? [...current] : undefined });
+    });
+    row.appendChild(chip);
+  }
+  wrap.appendChild(row);
+  return wrap;
+}
+
+// ----------------------------------------------------------------------
+// appointment_type — chip cluster (multi-select)
+// ----------------------------------------------------------------------
+
+const APPOINTMENT_TYPES: Array<{ value: string; key: I18nKey }> = [
+  { value: "hearing",          key: "views.bar.appointment_type.hearing" },
+  { value: "meeting",          key: "views.bar.appointment_type.meeting" },
+  { value: "consultation",     key: "views.bar.appointment_type.consultation" },
+  { value: "deadline_hearing", key: "views.bar.appointment_type.deadline_hearing" },
+];
+
+function renderAppointmentTypeAxis(ctx: AxisCtx): HTMLElement {
+  const wrap = group("views.bar.label.appointment_type");
+  const row = chipRow();
+  const all = chipBtn(t("views.bar.common.all"), !ctx.get("appointment_type")?.length);
+  all.addEventListener("click", () => ctx.patch({ appointment_type: undefined }));
+  row.appendChild(all);
+  const current = new Set(ctx.get("appointment_type") ?? []);
+  for (const ty of APPOINTMENT_TYPES) {
+    const chip = chipBtn(t(ty.key), current.has(ty.value));
+    chip.addEventListener("click", () => {
+      if (current.has(ty.value)) current.delete(ty.value);
+      else current.add(ty.value);
+      ctx.patch({ appointment_type: current.size ? [...current] : undefined });
+    });
+    row.appendChild(chip);
+  }
+  wrap.appendChild(row);
+  return wrap;
+}
+
+// ----------------------------------------------------------------------
+// project_event_kind — chip cluster (multi-select)
+//
+// Mirrors KnownProjectEventKinds in internal/services/filter_spec.go.
+// Labels reuse the existing `event.title.<kind>` translation table so
+// the chip text matches the Verlauf row title for the same event type.
+// ----------------------------------------------------------------------
+
+const PROJECT_EVENT_KINDS: string[] = [
+  "project_created",
+  "project_archived",
+  "project_reparented",
+  "project_type_changed",
+  "status_changed",
+  "deadline_created",
+  "deadline_completed",
+  "deadline_reopened",
+  "appointment_created",
+  "appointment_updated",
+  "appointment_deleted",
+  "approval_decided",
+  "member_role_changed",
+];
+
+function renderProjectEventKindAxis(ctx: AxisCtx): HTMLElement {
+  const wrap = group("views.bar.label.project_event_kind");
+  const row = chipRow();
+  const all = chipBtn(t("views.bar.common.all"), !ctx.get("project_event_kind")?.length);
+  all.addEventListener("click", () => ctx.patch({ project_event_kind: undefined }));
+  row.appendChild(all);
+  const current = new Set(ctx.get("project_event_kind") ?? []);
+  for (const kind of PROJECT_EVENT_KINDS) {
+    const label = tDyn(`event.title.${kind}`);
+    const chip = chipBtn(label, current.has(kind));
+    chip.addEventListener("click", () => {
+      if (current.has(kind)) current.delete(kind);
+      else current.add(kind);
+      ctx.patch({ project_event_kind: current.size ? [...current] : undefined });
+    });
+    row.appendChild(chip);
+  }
+  wrap.appendChild(row);
+  return wrap;
+}
+
+// ----------------------------------------------------------------------
+// timeline_status — chip cluster (multi-select)
+//
+// SmartTimeline (t-paliad-173) status vocabulary spans actuals +
+// projections. Default: all. Macro chip pair "Zukunft anzeigen" /
+// "Nur vergangenes" toggles the [predicted, court_set] subset on
+// or off in one click.
+// ----------------------------------------------------------------------
+
+const TIMELINE_STATUSES: Array<{ value: string; key: I18nKey }> = [
+  { value: "done",              key: "views.bar.timeline_status.done" },
+  { value: "open",              key: "views.bar.timeline_status.open" },
+  { value: "overdue",           key: "views.bar.timeline_status.overdue" },
+  { value: "predicted",         key: "views.bar.timeline_status.predicted" },
+  { value: "predicted_overdue", key: "views.bar.timeline_status.predicted_overdue" },
+  { value: "court_set",         key: "views.bar.timeline_status.court_set" },
+  { value: "off_script",        key: "views.bar.timeline_status.off_script" },
+];
+
+function renderTimelineStatusAxis(ctx: AxisCtx): HTMLElement {
+  const wrap = group("views.bar.label.timeline_status");
+  const row = chipRow();
+  const all = chipBtn(t("views.bar.common.all"), !ctx.get("timeline_status")?.length);
+  all.addEventListener("click", () => ctx.patch({ timeline_status: undefined }));
+  row.appendChild(all);
+  const current = new Set(ctx.get("timeline_status") ?? []);
+  for (const s of TIMELINE_STATUSES) {
+    const chip = chipBtn(t(s.key), current.has(s.value));
+    chip.addEventListener("click", () => {
+      if (current.has(s.value)) current.delete(s.value);
+      else current.add(s.value);
+      ctx.patch({ timeline_status: current.size ? [...current] : undefined });
+    });
+    row.appendChild(chip);
+  }
+  // Macro chips. "Zukunft anzeigen" = include predicted+court_set; "Nur
+  // vergangenes" = strip them. Implemented in terms of timeline_status.
+  const future = chipBtn(t("views.bar.timeline_status.macro.future"), false);
+  future.classList.add("filter-bar-chip-macro");
+  future.addEventListener("click", () => {
+    const next = new Set(["done", "open", "overdue", "predicted", "court_set", "predicted_overdue", "off_script"]);
+    ctx.patch({ timeline_status: [...next] });
+  });
+  row.appendChild(future);
+  const past = chipBtn(t("views.bar.timeline_status.macro.past"), false);
+  past.classList.add("filter-bar-chip-macro");
+  past.addEventListener("click", () => {
+    ctx.patch({ timeline_status: ["done", "overdue", "off_script"] });
+  });
+  row.appendChild(past);
+  wrap.appendChild(row);
+  return wrap;
+}
+
+// ----------------------------------------------------------------------
+// timeline_track — chip cluster (multi-select)
+//
+// Slice 2 only renders parent + off_script; counterclaim and child:<id>
+// values land with Slice 3's CCR sub-project FK migration. The renderer
+// stays ready for those values — chip rendering is dynamic on the
+// state set, not hard-coded to the catalogue below.
+// ----------------------------------------------------------------------
+
+const TIMELINE_TRACKS: Array<{ value: string; key: I18nKey }> = [
+  { value: "parent",       key: "views.bar.timeline_track.parent" },
+  { value: "counterclaim", key: "views.bar.timeline_track.counterclaim" },
+  { value: "off_script",   key: "views.bar.timeline_track.off_script" },
+];
+
+function renderTimelineTrackAxis(ctx: AxisCtx): HTMLElement {
+  const wrap = group("views.bar.label.timeline_track");
+  const row = chipRow();
+  const all = chipBtn(t("views.bar.common.all"), !ctx.get("timeline_track")?.length);
+  all.addEventListener("click", () => ctx.patch({ timeline_track: undefined }));
+  row.appendChild(all);
+  const current = new Set(ctx.get("timeline_track") ?? []);
+  for (const tr of TIMELINE_TRACKS) {
+    const chip = chipBtn(t(tr.key), current.has(tr.value));
+    chip.addEventListener("click", () => {
+      if (current.has(tr.value)) current.delete(tr.value);
+      else current.add(tr.value);
+      ctx.patch({ timeline_track: current.size ? [...current] : undefined });
+    });
+    row.appendChild(chip);
+  }
+  wrap.appendChild(row);
+  return wrap;
+}
+
+// ----------------------------------------------------------------------
+// shape — segmented control (list / cards / calendar)
+// ----------------------------------------------------------------------
+
+const SHAPES: Array<{ value: NonNullable<BarState["shape"]>; key: I18nKey }> = [
+  { value: "list",     key: "views.bar.shape.list" },
+  { value: "cards",    key: "views.bar.shape.cards" },
+  { value: "calendar", key: "views.bar.shape.calendar" },
+];
+
+function renderShapeAxis(ctx: AxisCtx): HTMLElement {
+  const wrap = group("views.bar.label.shape");
+  const row = chipRow();
+  row.classList.add("filter-bar-segment");
+  const current = ctx.get("shape");
+  for (const sh of SHAPES) {
+    const chip = chipBtn(t(sh.key), sh.value === current);
+    chip.addEventListener("click", () => ctx.patch({ shape: sh.value }));
+    row.appendChild(chip);
+  }
+  wrap.appendChild(row);
+  return wrap;
+}
+
+// ----------------------------------------------------------------------
+// density — segmented pair (comfortable / compact)
+// ----------------------------------------------------------------------
+
+const DENSITIES: Array<{ value: NonNullable<BarState["density"]>; key: I18nKey }> = [
+  { value: "comfortable", key: "views.bar.density.comfortable" },
+  { value: "compact",     key: "views.bar.density.compact" },
+];
+
+function renderDensityAxis(ctx: AxisCtx): HTMLElement {
+  const wrap = group("views.bar.label.density");
+  const row = chipRow();
+  row.classList.add("filter-bar-segment");
+  const current = ctx.get("density") ?? "comfortable";
+  for (const d of DENSITIES) {
+    const chip = chipBtn(t(d.key), d.value === current);
+    chip.addEventListener("click", () => ctx.patch({ density: d.value }));
+    row.appendChild(chip);
+  }
+  wrap.appendChild(row);
+  return wrap;
+}
+
+// ----------------------------------------------------------------------
+// sort — small <select>
+// ----------------------------------------------------------------------
+
+const SORTS: Array<{ value: NonNullable<BarState["sort"]>; key: I18nKey }> = [
+  { value: "date_asc",  key: "views.bar.sort.date_asc" },
+  { value: "date_desc", key: "views.bar.sort.date_desc" },
+];
+
+function renderSortAxis(ctx: AxisCtx): HTMLElement {
+  const wrap = group("views.bar.label.sort");
+  const sel = document.createElement("select");
+  sel.className = "entity-select filter-bar-select";
+  for (const s of SORTS) {
+    const opt = document.createElement("option");
+    opt.value = s.value;
+    opt.textContent = t(s.key);
+    sel.appendChild(opt);
+  }
+  sel.value = ctx.get("sort") ?? "date_asc";
+  sel.addEventListener("change", () => ctx.patch({ sort: sel.value as NonNullable<BarState["sort"]> }));
+  wrap.appendChild(sel);
+  return wrap;
+}
+
+// ----------------------------------------------------------------------
+// unread_only — single binary chip (t-paliad-249, inbox only)
+// ----------------------------------------------------------------------
+
+function renderUnreadOnlyAxis(ctx: AxisCtx): HTMLElement {
+  const wrap = group("views.bar.label.unread_only");
+  const row = chipRow();
+  const isUnread = ctx.get("unread_only") !== false; // default on
+  const unreadChip = chipBtn(t("views.bar.unread_only.on"), isUnread);
+  unreadChip.addEventListener("click", () => ctx.patch({ unread_only: true }));
+  const allChip = chipBtn(t("views.bar.unread_only.off"), !isUnread);
+  allChip.addEventListener("click", () => ctx.patch({ unread_only: false }));
+  row.appendChild(unreadChip);
+  row.appendChild(allChip);
+  wrap.appendChild(row);
+  return wrap;
+}
+
+// ----------------------------------------------------------------------
+// inbox_focus — coarse 4-chip cluster (t-paliad-249, inbox only)
+//
+// Head's UX refinement #2 (2026-05-25): users pick "what to see" in
+// human terms, not abstract event-kind names. The overlay translates
+// the chip to a (Sources, ProjectEventPredicates.EventTypes,
+// ApprovalRequestPredicates.EntityTypes) triple at spec-resolve time
+// (see applyInboxFocusOverlay in url-codec.ts).
+// ----------------------------------------------------------------------
+
+const INBOX_FOCUS_CHIPS: Array<{ value: InboxFocus; key: I18nKey }> = [
+  { value: "alles",         key: "views.bar.inbox_focus.alles" },
+  { value: "genehmigungen", key: "views.bar.inbox_focus.genehmigungen" },
+  { value: "plus_termine",  key: "views.bar.inbox_focus.plus_termine" },
+  { value: "plus_fristen",  key: "views.bar.inbox_focus.plus_fristen" },
+];
+
+function renderInboxFocusAxis(ctx: AxisCtx): HTMLElement {
+  const wrap = group("views.bar.label.inbox_focus");
+  const row = chipRow();
+  const current: InboxFocus = ctx.get("inbox_focus") ?? "alles";
+  for (const f of INBOX_FOCUS_CHIPS) {
+    const chip = chipBtn(t(f.key), f.value === current);
+    chip.addEventListener("click", () => {
+      ctx.patch({ inbox_focus: f.value === "alles" ? undefined : f.value });
+    });
+    row.appendChild(chip);
+  }
+  wrap.appendChild(row);
+  return wrap;
+}
+
+// ----------------------------------------------------------------------
+// shared helpers — group + chip + row
+// ----------------------------------------------------------------------
+
+function group(labelKey: I18nKey): HTMLElement {
+  const wrap = document.createElement("div");
+  wrap.className = "filter-group filter-bar-group";
+  const label = document.createElement("span");
+  label.className = "filter-bar-label";
+  label.textContent = t(labelKey);
+  wrap.appendChild(label);
+  return wrap;
+}
+
+function chipRow(): HTMLElement {
+  const row = document.createElement("div");
+  row.className = "filter-bar-chip-row";
+  return row;
+}
+
+function chipBtn(text: string, active: boolean): HTMLButtonElement {
+  const btn = document.createElement("button");
+  btn.type = "button";
+  btn.className = "agenda-chip filter-bar-chip" + (active ? " agenda-chip-active" : "");
+  btn.textContent = text;
+  return btn;
+}

frontend/src/client/filter-bar/index.ts

@@ -0,0 +1,405 @@
+// FilterBar — the universal filter + view-mode primitive
+// (t-paliad-163). One client component every list-shaped paliad surface
+// mounts.
+//
+// Lifecycle:
+//   1. Caller hands in baseFilter + baseRender + axes + onResult.
+//   2. We parse URL params (within urlNamespace) and localStorage prefs,
+//      overlay them on the base spec to compute the effective spec.
+//   3. We render the toolbar (one chip cluster / popover / select per
+//      axis, plus trailing actions).
+//   4. We POST /api/views/{slug}/run with the effective spec as override
+//      and hand the result + effective spec to onResult. The surface's
+//      shape host renders.
+//   5. Every axis interaction patches BarState, re-encodes the URL,
+//      re-runs the spec.
+//
+// The bar is a closed loop — surfaces don't see FilterSpec/RenderSpec
+// directly, just BarState diffs and the final ViewRunResult. That keeps
+// the substrate's validation invariants in one place (the bar).
+
+import { onLangChange, t } from "../i18n";
+import type { FilterSpec, RenderSpec, ViewRunResult } from "../views/types";
+import {
+  parseBar,
+  encodeBar,
+} from "./url-codec";
+import { renderAxis, type AxisCtx, type RenderAxisOpts } from "./axes";
+import { openSaveModal } from "./save-modal";
+import type { BarState, MountOpts, BarHandle, EffectiveSpec, AxisKey } from "./types";
+
+export type { MountOpts, BarHandle, AxisKey } from "./types";
+
+const PREFS_PREFIX = "paliad.bar.";
+
+interface PrefsBlob {
+  shape?: string;
+  density?: string;
+  sort?: string;
+}
+
+export function mountFilterBar(host: HTMLElement, opts: MountOpts): BarHandle {
+  if (!!opts.customRunner === !!opts.systemViewSlug) {
+    throw new Error(
+      "mountFilterBar: exactly one of customRunner or systemViewSlug must be provided",
+    );
+  }
+  let state: BarState = {};
+  const ns = opts.urlNamespace;
+
+  // Hydrate state: URL > localStorage prefs > base.
+  const urlParams = new URLSearchParams(window.location.search);
+  state = parseBar(urlParams, ns);
+  hydratePrefs(state, opts.surfaceKey);
+
+  // Toolbar shell.
+  const toolbar = document.createElement("div");
+  toolbar.className = "filter-bar";
+  host.appendChild(toolbar);
+
+  // Trailing actions: Save as view + Reset (when not suppressed).
+  const showSave = opts.showSaveAsView !== false;
+
+  // Run + render orchestration.
+  let runVersion = 0;
+  let lastEffective: EffectiveSpec | null = null;
+
+  const runAndRender = async () => {
+    const effective = computeEffective(opts.baseFilter, opts.baseRender, state);
+    lastEffective = effective;
+    const myVersion = ++runVersion;
+    try {
+      let result: ViewRunResult;
+      if (opts.customRunner) {
+        // Hand the runner a frozen snapshot of the bar state so it can
+        // read axes the EffectiveSpec doesn't round-trip (SmartTimeline
+        // timeline_status / timeline_track on the Verlauf surface).
+        result = await opts.customRunner(effective, Object.freeze({ ...state }));
+      } else {
+        const slug = opts.systemViewSlug as string; // ctor guard guarantees this
+        const r = await fetch(`/api/views/${encodeURIComponent(slug)}/run`, {
+          method: "POST",
+          credentials: "include",
+          headers: { "Content-Type": "application/json" },
+          body: JSON.stringify({ filter: effective.filter }),
+        });
+        if (myVersion !== runVersion) return; // a newer click superseded us
+        if (!r.ok) {
+          opts.onResult({ rows: [], inaccessible_project_ids: [] }, effective);
+          return;
+        }
+        result = (await r.json()) as ViewRunResult;
+      }
+      if (myVersion !== runVersion) return;
+      opts.onResult(result, effective);
+    } catch (_e) {
+      if (myVersion !== runVersion) return;
+      opts.onResult({ rows: [], inaccessible_project_ids: [] }, effective);
+    }
+  };
+
+  // Axis context — all axis renderers patch state through here.
+  const ctx: AxisCtx = {
+    get<K extends keyof BarState>(key: K) { return state[key]; },
+    patch(delta) {
+      state = { ...state, ...delta };
+      // Coerce empties so URL stays clean.
+      for (const k of Object.keys(delta) as (keyof BarState)[]) {
+        const v = state[k];
+        if (Array.isArray(v) && v.length === 0) delete state[k];
+        if (v === undefined || v === null || v === false) delete state[k];
+      }
+      // personal_only false should also be deleted (handled above as
+      // falsy, but explicit for clarity).
+      if (state.personal_only === false) delete state.personal_only;
+      syncURL();
+      syncPrefs();
+      renderToolbar();
+      void runAndRender();
+    },
+  };
+
+  const axisRenderOpts: RenderAxisOpts = {
+    timePresets: opts.timePresets,
+  };
+
+  // First paint.
+  const renderToolbar = () => {
+    toolbar.innerHTML = "";
+    for (const axis of opts.axes) {
+      const el = renderAxis(axis as AxisKey, ctx, axisRenderOpts);
+      if (el) toolbar.appendChild(el);
+    }
+    if (showSave) {
+      const trailing = document.createElement("div");
+      trailing.className = "filter-bar-trailing";
+
+      const resetBtn = document.createElement("button");
+      resetBtn.type = "button";
+      resetBtn.className = "btn-secondary btn-small filter-bar-reset";
+      resetBtn.textContent = t("views.bar.action.reset");
+      resetBtn.disabled = !isDirty(state);
+      resetBtn.addEventListener("click", () => handle.reset());
+      trailing.appendChild(resetBtn);
+
+      const saveBtn = document.createElement("button");
+      saveBtn.type = "button";
+      saveBtn.className = "btn-primary btn-small filter-bar-save";
+      saveBtn.textContent = t("views.bar.action.save_as_view");
+      saveBtn.addEventListener("click", async () => {
+        if (!lastEffective) return;
+        const result = await openSaveModal(lastEffective.filter, lastEffective.render);
+        if (result) {
+          window.location.href = `/views/${encodeURIComponent(result.view.slug)}`;
+        }
+      });
+      trailing.appendChild(saveBtn);
+
+      toolbar.appendChild(trailing);
+    }
+  };
+
+  const syncURL = () => {
+    const params = new URLSearchParams(window.location.search);
+    encodeBar(state, params, ns);
+    const qs = params.toString();
+    const url = qs ? `${window.location.pathname}?${qs}` : window.location.pathname;
+    history.replaceState(null, "", url);
+  };
+
+  const syncPrefs = () => {
+    const blob: PrefsBlob = {};
+    if (state.shape) blob.shape = state.shape;
+    if (state.density) blob.density = state.density;
+    if (state.sort) blob.sort = state.sort;
+    try {
+      if (Object.keys(blob).length === 0) {
+        localStorage.removeItem(PREFS_PREFIX + opts.surfaceKey);
+      } else {
+        localStorage.setItem(PREFS_PREFIX + opts.surfaceKey, JSON.stringify(blob));
+      }
+    } catch { /* private mode / quota — ignore */ }
+  };
+
+  // Re-render labels on language change without losing state. The
+  // existing onLangChange API is register-only (no off-handler). We
+  // gate via a `destroyed` flag so a torn-down bar's callback no-ops.
+  let destroyed = false;
+  onLangChange(() => {
+    if (destroyed) return;
+    renderToolbar();
+  });
+
+  const handle: BarHandle = {
+    reset() {
+      state = {};
+      syncURL();
+      syncPrefs();
+      renderToolbar();
+      void runAndRender();
+    },
+    async refresh() {
+      await runAndRender();
+    },
+    getEffective() {
+      if (lastEffective) return lastEffective;
+      return computeEffective(opts.baseFilter, opts.baseRender, state);
+    },
+    getState() {
+      // Hand back a frozen snapshot so callers can't smuggle mutations
+      // back into the bar's owned state — the bar is the single writer.
+      return Object.freeze({ ...state });
+    },
+    destroy() {
+      destroyed = true;
+      toolbar.remove();
+    },
+  };
+
+  renderToolbar();
+  void runAndRender();
+  return handle;
+}
+
+// hydratePrefs reads the saved `paliad.bar.<surfaceKey>` blob and fills
+// in render axes the URL didn't already pin. URL wins over prefs.
+function hydratePrefs(state: BarState, surfaceKey: string): void {
+  let blob: PrefsBlob;
+  try {
+    const raw = localStorage.getItem(PREFS_PREFIX + surfaceKey);
+    if (!raw) return;
+    blob = JSON.parse(raw) as PrefsBlob;
+  } catch { return; }
+  if (!state.shape && (blob.shape === "list" || blob.shape === "cards" || blob.shape === "calendar")) {
+    state.shape = blob.shape;
+  }
+  if (!state.density && (blob.density === "comfortable" || blob.density === "compact")) {
+    state.density = blob.density;
+  }
+  if (!state.sort && (blob.sort === "date_asc" || blob.sort === "date_desc")) {
+    state.sort = blob.sort;
+  }
+}
+
+// computeEffective overlays the BarState onto the base FilterSpec +
+// RenderSpec to produce the spec that gets POSTed to the substrate.
+//
+// Server-side validator (FilterSpec.Validate) is the final gate; we
+// produce shapes the validator will accept, but defer to it for the
+// hard rejection case (e.g. PersonalOnly + ScopeExplicit).
+export function computeEffective(
+  base: FilterSpec,
+  baseRender: RenderSpec,
+  state: BarState,
+): EffectiveSpec {
+  // Deep-clone to avoid mutating the caller's base. JSON round-trip is
+  // fine here — every field on FilterSpec is a primitive / array /
+  // object literal (no class instances, no Date, no functions).
+  const filter = JSON.parse(JSON.stringify(base)) as FilterSpec;
+  const render = JSON.parse(JSON.stringify(baseRender)) as RenderSpec;
+
+  if (state.time) {
+    filter.time = {
+      ...filter.time,
+      horizon: state.time.horizon,
+      from: state.time.horizon === "custom" ? state.time.from : undefined,
+      to:   state.time.horizon === "custom" ? state.time.to   : undefined,
+    };
+  }
+
+  if (state.project) {
+    if (state.project.mode === "personal") {
+      filter.scope = {
+        ...filter.scope,
+        personal_only: true,
+        // When personal_only takes over, leave projects on the base
+        // mode (typically all_visible). Validator rejects ScopeExplicit
+        // + personal_only so we don't overwrite the mode here.
+      };
+    } else if (state.project.id) {
+      filter.scope = {
+        ...filter.scope,
+        projects: { mode: "explicit", ids: [state.project.id] },
+      };
+    }
+  }
+  if (state.personal_only) {
+    filter.scope = { ...filter.scope, personal_only: true };
+  }
+
+  // Per-source predicates. Build the predicates map idempotently;
+  // never inject a predicate for a source the spec doesn't list.
+  const sources = new Set(filter.sources);
+  filter.predicates = filter.predicates ?? {};
+
+  if (sources.has("deadline") && (state.deadline_status || state.deadline_event_type)) {
+    const cur = filter.predicates.deadline ?? {};
+    const next = { ...cur };
+    if (state.deadline_status) next.status = state.deadline_status;
+    if (state.deadline_event_type) {
+      next.event_types = state.deadline_event_type.ids;
+      next.include_untyped = state.deadline_event_type.include_untyped;
+    }
+    filter.predicates.deadline = next;
+  }
+  if (sources.has("appointment") && state.appointment_type) {
+    const cur = filter.predicates.appointment ?? {};
+    filter.predicates.appointment = { ...cur, appointment_types: state.appointment_type };
+  }
+  if (sources.has("approval_request") && (state.approval_viewer_role || state.approval_status || state.approval_entity_type)) {
+    const cur = filter.predicates.approval_request ?? {};
+    const next = { ...cur };
+    if (state.approval_viewer_role) next.viewer_role = state.approval_viewer_role;
+    if (state.approval_status) next.status = state.approval_status;
+    if (state.approval_entity_type) next.entity_types = state.approval_entity_type;
+    filter.predicates.approval_request = next;
+  }
+  if (sources.has("project_event") && state.project_event_kind) {
+    const cur = filter.predicates.project_event ?? {};
+    filter.predicates.project_event = { ...cur, event_types: state.project_event_kind };
+  }
+
+  // Render overlays.
+  if (state.shape) render.shape = state.shape;
+  if (state.sort) {
+    if (render.shape === "list" || (state.shape === "list" && !render.list)) {
+      render.list = { ...(render.list ?? {}), sort: state.sort };
+    }
+    if (render.shape === "cards" || state.shape === "cards") {
+      render.cards = { ...(render.cards ?? {}), sort: state.sort };
+    }
+  }
+  if (state.density && (render.shape === "list" || state.shape === "list")) {
+    render.list = { ...(render.list ?? {}), density: state.density };
+  }
+
+  // Inbox overlays (t-paliad-249).
+  //
+  // unread_only is a top-level FilterSpec field; the server resolves
+  // the actual cursor at run-time. Default-on for the inbox surface is
+  // baked into the base spec — but we ALSO need to write `true` here
+  // when the user explicitly picks the chip so the server doesn't
+  // confuse "user wants unread" with "user wants no filter".
+  if (state.unread_only !== undefined) {
+    filter.unread_only = state.unread_only;
+  }
+
+  // inbox_focus is a coarse axis that overlays Sources + a few
+  // per-source predicates. Translate here so the server sees a clean
+  // spec; the validator + RunSpec don't need to know about the chip.
+  if (state.inbox_focus && state.inbox_focus !== "alles") {
+    applyInboxFocusOverlay(filter, state.inbox_focus);
+  }
+
+  return { filter, render };
+}
+
+// applyInboxFocusOverlay narrows the spec to the chip's intent.
+// Mutates `filter` in place. Called only when state.inbox_focus is
+// set to a non-default value.
+//
+// Contract:
+//   - "genehmigungen"  → drop project_event from sources entirely.
+//   - "plus_termine"   → keep both sources; narrow project_event to
+//                        appointment_* kinds; narrow approval_request
+//                        entity_types to ["appointment"].
+//   - "plus_fristen"   → keep both sources; narrow project_event to
+//                        deadline_* kinds; narrow approval_request
+//                        entity_types to ["deadline"].
+function applyInboxFocusOverlay(filter: FilterSpec, focus: Exclude<NonNullable<BarState["inbox_focus"]>, "alles">): void {
+  filter.predicates = filter.predicates ?? {};
+  if (focus === "genehmigungen") {
+    filter.sources = filter.sources.filter((s) => s !== "project_event");
+    delete filter.predicates.project_event;
+    return;
+  }
+  const kindPrefix = focus === "plus_fristen" ? "deadline_" : "appointment_";
+  const entity = focus === "plus_fristen" ? "deadline" : "appointment";
+
+  if (filter.sources.includes("project_event")) {
+    const baseKinds = filter.predicates.project_event?.event_types ?? [];
+    const narrowed = baseKinds.filter((k) => k.startsWith(kindPrefix));
+    filter.predicates.project_event = {
+      ...(filter.predicates.project_event ?? {}),
+      event_types: narrowed,
+    };
+  }
+  if (filter.sources.includes("approval_request")) {
+    filter.predicates.approval_request = {
+      ...(filter.predicates.approval_request ?? {}),
+      entity_types: [entity],
+    };
+  }
+}
+
+// isDirty — used to enable the Reset button only when there's something
+// to reset to.
+function isDirty(state: BarState): boolean {
+  for (const k of Object.keys(state) as (keyof BarState)[]) {
+    const v = state[k];
+    if (v === undefined || v === null || v === false) continue;
+    if (Array.isArray(v) && v.length === 0) continue;
+    return true;
+  }
+  return false;
+}

frontend/src/client/filter-bar/save-modal.ts

@@ -0,0 +1,146 @@
+// Save-as-view modal for the FilterBar. Mirrors the create form on
+// /views/new (frontend/src/client/views-editor.ts:168) but as a modal
+// so the user can save the bar's current effective spec without
+// leaving the page they're filtering on.
+//
+// On success, the new view appears in the "Meine Sichten" sidebar
+// group on next render (the sidebar polls /api/user-views on init).
+
+import { t } from "../i18n";
+import type { FilterSpec, RenderSpec, UserView } from "../views/types";
+
+export interface SaveModalResult {
+  view: UserView;
+}
+
+const SLUG_REGEX = /^[a-z0-9][a-z0-9-]{0,62}$/;
+
+export function openSaveModal(filter: FilterSpec, render: RenderSpec): Promise<SaveModalResult | null> {
+  return new Promise((resolve) => {
+    const dialog = document.createElement("dialog");
+    dialog.className = "filter-bar-save-modal";
+
+    dialog.innerHTML = `
+      <form method="dialog" class="filter-bar-save-form">
+        <h2>${t("views.bar.save.heading")}</h2>
+        <label class="filter-bar-save-field">
+          <span>${t("views.bar.save.field.name")}</span>
+          <input type="text" name="name" required maxlength="100" autocomplete="off" />
+        </label>
+        <label class="filter-bar-save-field">
+          <span>${t("views.bar.save.field.slug")}</span>
+          <input type="text" name="slug" required maxlength="63" autocomplete="off" pattern="[a-z0-9][a-z0-9-]*" />
+          <small>${t("views.bar.save.field.slug_hint")}</small>
+        </label>
+        <label class="filter-bar-save-checkbox">
+          <input type="checkbox" name="show_count" />
+          <span>${t("views.bar.save.field.show_count")}</span>
+        </label>
+        <p class="filter-bar-save-error" hidden></p>
+        <div class="filter-bar-save-actions">
+          <button type="button" class="btn-secondary" data-action="cancel">${t("views.bar.save.cancel")}</button>
+          <button type="submit" class="btn-primary">${t("views.bar.save.confirm")}</button>
+        </div>
+      </form>
+    `;
+
+    document.body.appendChild(dialog);
+
+    const form = dialog.querySelector<HTMLFormElement>(".filter-bar-save-form")!;
+    const errorEl = dialog.querySelector<HTMLParagraphElement>(".filter-bar-save-error")!;
+    const nameInput = form.elements.namedItem("name") as HTMLInputElement;
+    const slugInput = form.elements.namedItem("slug") as HTMLInputElement;
+    const showCount = form.elements.namedItem("show_count") as HTMLInputElement;
+    const cancelBtn = dialog.querySelector<HTMLButtonElement>('[data-action="cancel"]')!;
+
+    // Auto-derive slug from name as the user types — but only until
+    // they touch the slug field manually.
+    let slugDirty = false;
+    nameInput.addEventListener("input", () => {
+      if (!slugDirty) slugInput.value = derivedSlug(nameInput.value);
+    });
+    slugInput.addEventListener("input", () => { slugDirty = true; });
+
+    const cleanup = () => {
+      dialog.close();
+      dialog.remove();
+    };
+
+    cancelBtn.addEventListener("click", () => {
+      cleanup();
+      resolve(null);
+    });
+
+    form.addEventListener("submit", async (e) => {
+      e.preventDefault();
+      errorEl.hidden = true;
+      errorEl.textContent = "";
+
+      const name = nameInput.value.trim();
+      const slug = slugInput.value.trim();
+      if (!name) {
+        showError(errorEl, t("views.bar.save.error.name_required"));
+        return;
+      }
+      if (!SLUG_REGEX.test(slug)) {
+        showError(errorEl, t("views.bar.save.error.slug_format"));
+        return;
+      }
+
+      const payload = {
+        name,
+        slug,
+        filter_spec: filter,
+        render_spec: render,
+        show_count: showCount.checked,
+      };
+      try {
+        const r = await fetch("/api/user-views", {
+          method: "POST",
+          credentials: "include",
+          headers: { "Content-Type": "application/json" },
+          body: JSON.stringify(payload),
+        });
+        if (r.status === 409) {
+          showError(errorEl, t("views.bar.save.error.slug_taken"));
+          return;
+        }
+        if (!r.ok) {
+          const body = await r.json().catch(() => ({} as { error?: string }));
+          showError(errorEl, body.error || `${r.status}: ${r.statusText}`);
+          return;
+        }
+        const view = (await r.json()) as UserView;
+        cleanup();
+        resolve({ view });
+      } catch (_e) {
+        showError(errorEl, t("views.bar.save.error.network"));
+      }
+    });
+
+    dialog.addEventListener("cancel", () => {
+      cleanup();
+      resolve(null);
+    });
+
+    dialog.showModal();
+    nameInput.focus();
+  });
+}
+
+function showError(el: HTMLElement, msg: string): void {
+  el.textContent = msg;
+  el.hidden = false;
+}
+
+function derivedSlug(name: string): string {
+  return name
+    .toLowerCase()
+    .replace(/[äÄ]/g, "ae")
+    .replace(/[öÖ]/g, "oe")
+    .replace(/[üÜ]/g, "ue")
+    .replace(/[ß]/g, "ss")
+    .replace(/[^a-z0-9]+/g, "-")
+    .replace(/^-+|-+$/g, "")
+    .slice(0, 63);
+}

frontend/src/client/filter-bar/types.ts

@@ -0,0 +1,181 @@
+// FilterBar types — t-paliad-163. Mirrors the Go FilterSpec/RenderSpec
+// shapes from internal/services/{filter_spec,render_spec}.go via
+// client/views/types.ts. The FilterBar is the universal frontend
+// primitive that consumes a base FilterSpec + RenderSpec, declares
+// which axes the surface supports, and emits diffs back through
+// onResult after running the spec via /api/views/run.
+
+import type { FilterSpec, RenderSpec, RenderShape, ViewRunResult, ListRowAction } from "../views/types";
+
+// AxisKey — every filter dimension the bar can render. Declared per
+// surface in mountFilterBar's `axes` array. See design §3.1 for the
+// universal-vs-per-surface split.
+export type AxisKey =
+  | "time"
+  | "project"
+  | "personal_only"
+  | "deadline_status"
+  | "deadline_event_type"
+  | "appointment_type"
+  | "approval_viewer_role"
+  | "approval_status"
+  | "approval_entity_type"
+  | "project_event_kind"
+  | "timeline_status"
+  | "timeline_track"
+  | "shape"
+  | "sort"
+  | "density"
+  // Inbox-only (t-paliad-249): unread/all toggle + coarse focus chip
+  // (Alles / Genehmigungen / +Termine / +Fristen). The focus chip
+  // overlays Sources + per-source predicates at resolve-time.
+  | "unread_only"
+  | "inbox_focus";
+
+// Inbox focus chip values. "alles" is the default — both sources, full
+// curated kinds. Other values narrow at the bar's resolve step. See
+// applyInboxFocusOverlay() in url-codec.ts for the spec rewrite.
+export type InboxFocus = "alles" | "genehmigungen" | "plus_termine" | "plus_fristen";
+
+// Effective spec — the result of overlaying URL + localStorage prefs
+// on top of the base spec. Handed back to onResult so the surface can
+// dispatch into the matching shape renderer with the right config.
+export interface EffectiveSpec {
+  filter: FilterSpec;
+  render: RenderSpec;
+}
+
+// Per-axis state — what the URL codec round-trips. Each axis's value
+// type is bounded to the FilterSpec/RenderSpec subset it touches.
+export interface BarState {
+  // Universal
+  time?: TimeOverlay;
+  project?: ProjectOverlay;
+  personal_only?: boolean;
+
+  // Per-source
+  deadline_status?: string[];
+  deadline_event_type?: { ids: string[]; include_untyped: boolean };
+  appointment_type?: string[];
+  approval_viewer_role?: "approver_eligible" | "self_requested" | "any_visible";
+  approval_status?: string[];
+  approval_entity_type?: string[];
+  project_event_kind?: string[];
+  // SmartTimeline axes (t-paliad-173). timeline_status spans actuals +
+  // projections; timeline_track is parent / counterclaim / off_script
+  // and grows once Slice 3 lands the CCR sub-project FK (child:<id>
+  // values dynamically populated then).
+  timeline_status?: string[];
+  timeline_track?: string[];
+
+  // Render
+  shape?: RenderShape;
+  sort?: "date_asc" | "date_desc";
+  density?: "comfortable" | "compact";
+
+  // Inbox (t-paliad-249)
+  unread_only?: boolean;
+  inbox_focus?: InboxFocus;
+}
+
+export interface TimeOverlay {
+  // Mirrors internal/services/filter_spec.go TimeHorizon. t-paliad-248
+  // added the symmetric 1d / 14d / all chips on each side; the union
+  // here is the wire-shape the URL codec parses and the picker emits.
+  horizon:
+    | "next_1d" | "next_7d" | "next_14d" | "next_30d" | "next_90d" | "next_all"
+    | "past_1d" | "past_7d" | "past_14d" | "past_30d" | "past_90d" | "past_all"
+    | "any" | "all" | "custom";
+  from?: string; // ISO 8601 — only when horizon === "custom"
+  to?: string;
+}
+
+export interface ProjectOverlay {
+  // The bar's project chip is single-select today; Phase C upgrades
+  // to multi-select. "personal" is a sentinel — the legacy /events
+  // contract reserved this name, we keep it so old bookmarks still
+  // resolve to the right state.
+  mode: "single" | "personal";
+  id?: string;
+}
+
+// MountOpts — the public API.
+export interface MountOpts {
+  // Base spec. Usually a SystemView's FilterSpec+RenderSpec, fetched
+  // from /api/views/system on the surface and passed in here. For
+  // /views/{slug}, the saved user-view's spec.
+  baseFilter: FilterSpec;
+  baseRender: RenderSpec;
+
+  // Which axes the surface exposes. Order is preserved in the rendered
+  // chrome — surfaces use this to control left-to-right grouping.
+  axes: AxisKey[];
+
+  // URL parameter namespace. When set, every URL key is prefixed
+  // (`?<ns>_time=`, `?<ns>_project=`, …). Used when two bars share a
+  // page (dashboard inline lists). Defaults to no prefix.
+  urlNamespace?: string;
+
+  // Surface key for localStorage prefs (density, default shape).
+  // Required so two surfaces don't share preferences.
+  surfaceKey: string;
+
+  // Whether to render "Speichern als Sicht" + "Zur&uuml;cksetzen"
+  // trailing actions. Defaults to true. Set false on the dashboard
+  // inline bars (per design Q6).
+  showSaveAsView?: boolean;
+
+  // Slug of the surface's underlying system view (or saved user view).
+  // POSTed to /api/views/{slug}/run with the override body. Required
+  // unless `customRunner` is supplied — see below. When the bar runs
+  // through this endpoint it is the substrate's canonical entry.
+  systemViewSlug?: string;
+
+  // Custom runner. When set, the bar bypasses the substrate POST and
+  // hands the effective spec + raw BarState to this function instead.
+  // Used by surfaces that need axes the EffectiveSpec doesn't round-trip
+  // (e.g. SmartTimeline's timeline_status / timeline_track, t-paliad-176).
+  // The state argument is a frozen snapshot — same shape getState()
+  // returns on the handle, but available on the very first run before
+  // the handle has been assigned. Must be either this OR systemViewSlug
+  // — the bar throws if both / neither are provided.
+  customRunner?: (effective: EffectiveSpec, state: Readonly<BarState>) => Promise<ViewRunResult>;
+
+  // Per-surface override of the time-axis chip presets. Order is
+  // preserved. Default presets are forward-looking (next_*+past_30d+any)
+  // — backward-looking surfaces (Verlauf, audit) pass past_*+all here.
+  timePresets?: NonNullable<BarState["time"]>["horizon"][];
+
+  // When true, the bar exposes an "Aktualisieren" affordance that
+  // PATCHes /api/user-views/{userViewId} with the effective spec.
+  // Set on /views/{slug} where the user is viewing a saved view.
+  userViewId?: string;
+
+  // Called every time the spec changes (mount, URL change, axis
+  // interaction). The surface dispatches to the matching shape
+  // renderer with the rows from /api/views/{slug}/run.
+  onResult(result: ViewRunResult, effective: EffectiveSpec): void;
+
+  // Optional — surface-specific row-action override. Phase 1: /inbox
+  // pins this to "approve"; /events Phase 3 pins to "complete_toggle".
+  // Future: sourced from the spec's render.list.row_action when set.
+  rowAction?: ListRowAction;
+}
+
+// Bar handle — what mountFilterBar returns. Pages can call .reset()
+// from page-level controls (e.g. an empty-state "Filter zurücksetzen"
+// button), or .destroy() if the page tears down.
+export interface BarHandle {
+  reset(): void;
+  refresh(): Promise<void>;
+  destroy(): void;
+  // Read-only effective spec at this moment (post URL + localStorage
+  // overlay). Pages use this to construct deep-link URLs etc.
+  getEffective(): EffectiveSpec;
+  // Read-only raw BarState. Surfaces with axes the EffectiveSpec doesn't
+  // round-trip (timeline_status / timeline_track on the SmartTimeline
+  // surface — the substrate FilterSpec has no per-source predicate for
+  // those) read state directly to drive client-side filtering. Returns
+  // a frozen snapshot; callers must not mutate.
+  getState(): Readonly<BarState>;
+}

frontend/src/client/filter-bar/url-codec.test.ts

@@ -0,0 +1,131 @@
+// Unit tests for the FilterBar URL codec. Round-trip discipline:
+// every BarState shape parseBar produces must encode back to the same
+// URL params, and vice versa. Run with `bun test`.
+
+import { test, expect, describe } from "bun:test";
+import { parseBar, encodeBar } from "./url-codec";
+import type { BarState } from "./types";
+
+function roundTrip(state: BarState, ns?: string): BarState {
+  const params = new URLSearchParams();
+  encodeBar(state, params, ns);
+  return parseBar(params, ns);
+}
+
+describe("filter-bar/url-codec", () => {
+  test("empty state round-trips to empty", () => {
+    expect(roundTrip({})).toEqual({});
+  });
+
+  test("time horizon round-trips", () => {
+    // Includes the t-paliad-248 symmetric additions (1d / 14d / all on each side).
+    for (const h of [
+      "next_1d", "next_7d", "next_14d", "next_30d", "next_90d", "next_all",
+      "past_1d", "past_7d", "past_14d", "past_30d", "past_90d", "past_all",
+      "any", "all",
+    ] as const) {
+      expect(roundTrip({ time: { horizon: h } })).toEqual({ time: { horizon: h } });
+    }
+  });
+
+  test("custom time horizon round-trips with from + to", () => {
+    const state: BarState = { time: { horizon: "custom", from: "2026-01-01", to: "2026-12-31" } };
+    expect(roundTrip(state)).toEqual(state);
+  });
+
+  test("project sentinel + uuid round-trip", () => {
+    expect(roundTrip({ project: { mode: "personal" } })).toEqual({ project: { mode: "personal" } });
+    expect(roundTrip({ project: { mode: "single", id: "11111111-1111-1111-1111-111111111111" } }))
+      .toEqual({ project: { mode: "single", id: "11111111-1111-1111-1111-111111111111" } });
+  });
+
+  test("personal_only flag round-trips", () => {
+    expect(roundTrip({ personal_only: true })).toEqual({ personal_only: true });
+    expect(roundTrip({})).toEqual({});
+  });
+
+  test("deadline_event_type honours legacy 'none' sentinel", () => {
+    const state: BarState = { deadline_event_type: { ids: ["a", "b"], include_untyped: true } };
+    expect(roundTrip(state)).toEqual(state);
+    const state2: BarState = { deadline_event_type: { ids: [], include_untyped: true } };
+    expect(roundTrip(state2)).toEqual(state2);
+    const state3: BarState = { deadline_event_type: { ids: ["a"], include_untyped: false } };
+    expect(roundTrip(state3)).toEqual(state3);
+  });
+
+  test("approval_request triple round-trips together", () => {
+    const state: BarState = {
+      approval_viewer_role: "approver_eligible",
+      approval_status: ["pending", "approved"],
+      approval_entity_type: ["deadline"],
+    };
+    expect(roundTrip(state)).toEqual(state);
+  });
+
+  test("namespace prefix isolates two bars on the same page", () => {
+    const a: BarState = { time: { horizon: "next_7d" } };
+    const b: BarState = { time: { horizon: "next_30d" } };
+    const params = new URLSearchParams();
+    encodeBar(a, params, "agenda");
+    encodeBar(b, params, "activity");
+    expect(parseBar(params, "agenda")).toEqual(a);
+    expect(parseBar(params, "activity")).toEqual(b);
+    // Without namespace neither bar's keys are visible.
+    expect(parseBar(params)).toEqual({});
+  });
+
+  test("render axes round-trip", () => {
+    const state: BarState = { shape: "cards", sort: "date_desc", density: "compact" };
+    expect(roundTrip(state)).toEqual(state);
+  });
+
+  test("encode is idempotent — re-encoding same state replaces, doesn't accumulate", () => {
+    const state: BarState = { time: { horizon: "next_7d" }, deadline_status: ["pending"] };
+    const params = new URLSearchParams();
+    encodeBar(state, params);
+    encodeBar(state, params);
+    expect(params.get("d_status")).toBe("pending");
+    // Only one entry per key.
+    expect(params.getAll("d_status")).toHaveLength(1);
+  });
+
+  test("encode replaces stale keys when state shrinks", () => {
+    const params = new URLSearchParams();
+    encodeBar({ deadline_status: ["pending"], approval_viewer_role: "self_requested" }, params);
+    encodeBar({ deadline_status: ["completed"] }, params);
+    expect(params.get("d_status")).toBe("completed");
+    expect(params.has("a_role")).toBe(false);
+  });
+
+  test("parse drops unknown enum values silently (forward-compat)", () => {
+    const params = new URLSearchParams();
+    params.set("a_role", "future_role_we_dont_know_yet");
+    params.set("shape", "kanban");
+    params.set("density", "huge");
+    expect(parseBar(params)).toEqual({});
+  });
+
+  // t-paliad-249 — inbox axes
+  test("unread_only round-trips both states", () => {
+    expect(roundTrip({ unread_only: true })).toEqual({ unread_only: true });
+    expect(roundTrip({ unread_only: false })).toEqual({ unread_only: false });
+  });
+
+  test("unread_only undefined stays out of the URL", () => {
+    const params = new URLSearchParams();
+    encodeBar({}, params);
+    expect(params.has("unread")).toBe(false);
+  });
+
+  test("inbox_focus round-trips for non-default values", () => {
+    for (const f of ["genehmigungen", "plus_termine", "plus_fristen"] as const) {
+      expect(roundTrip({ inbox_focus: f })).toEqual({ inbox_focus: f });
+    }
+  });
+
+  test("inbox_focus alles is omitted (it's the default)", () => {
+    const params = new URLSearchParams();
+    encodeBar({ inbox_focus: "alles" }, params);
+    expect(params.has("focus")).toBe(false);
+  });
+});

frontend/src/client/filter-bar/url-codec.ts

@@ -0,0 +1,224 @@
+// FilterBar URL codec — t-paliad-163. Encodes BarState ↔ URL
+// parameters with optional namespace prefix (?<ns>_<key>=).
+//
+// The bar treats the URL as canonical for everything that affects
+// which rows you see. Round-trip discipline: anything written by
+// encodeBar must parse back identically via parseBar so deep-links
+// and refresh both yield the same effective spec.
+//
+// Empty / default values are NOT written — the URL stays clean for
+// users who don't tweak. The page's base spec is the implicit baseline.
+
+import type { BarState, TimeOverlay, ProjectOverlay, InboxFocus } from "./types";
+
+const PERSONAL_PROJECT_SENTINEL = "personal";
+
+// parseBar reads URL params into a BarState. Unknown values are
+// dropped silently (forward-compat with future axes).
+export function parseBar(params: URLSearchParams, ns?: string): BarState {
+  const k = (key: string) => (ns ? `${ns}_${key}` : key);
+  const out: BarState = {};
+
+  // time
+  const time = params.get(k("time"));
+  if (time) {
+    const horizon = parseHorizon(time);
+    if (horizon) {
+      const overlay: TimeOverlay = { horizon };
+      if (horizon === "custom") {
+        const from = params.get(k("from"));
+        const to = params.get(k("to"));
+        if (from) overlay.from = from;
+        if (to) overlay.to = to;
+      }
+      out.time = overlay;
+    }
+  }
+
+  // project
+  const project = params.get(k("project"));
+  if (project) {
+    if (project === PERSONAL_PROJECT_SENTINEL) {
+      out.project = { mode: "personal" };
+    } else {
+      out.project = { mode: "single", id: project };
+    }
+  }
+
+  // personal_only
+  if (params.get(k("personal")) === "1") {
+    out.personal_only = true;
+  }
+
+  // deadline.status
+  const dStatus = params.get(k("d_status"));
+  if (dStatus) out.deadline_status = parseCSV(dStatus);
+
+  // deadline.event_types — preserves the legacy /events contract
+  // where "none" inside the CSV means include_untyped=true.
+  const dEvent = params.get(k("d_event_type"));
+  if (dEvent) {
+    const tokens = parseCSV(dEvent);
+    const ids: string[] = [];
+    let untyped = false;
+    for (const tok of tokens) {
+      if (tok === "none") untyped = true;
+      else ids.push(tok);
+    }
+    out.deadline_event_type = { ids, include_untyped: untyped };
+  }
+
+  // appointment.types
+  const appType = params.get(k("app_type"));
+  if (appType) out.appointment_type = parseCSV(appType);
+
+  // approval_request.viewer_role
+  const aRole = params.get(k("a_role"));
+  if (aRole === "approver_eligible" || aRole === "self_requested" || aRole === "any_visible") {
+    out.approval_viewer_role = aRole;
+  }
+
+  // approval_request.status
+  const aStatus = params.get(k("a_status"));
+  if (aStatus) out.approval_status = parseCSV(aStatus);
+
+  // approval_request.entity_types
+  const aEntity = params.get(k("a_entity_type"));
+  if (aEntity) out.approval_entity_type = parseCSV(aEntity);
+
+  // project_event.event_types
+  const peKind = params.get(k("pe_kind"));
+  if (peKind) out.project_event_kind = parseCSV(peKind);
+
+  // SmartTimeline (t-paliad-173) — status + track axes.
+  const tlStatus = params.get(k("tl_status"));
+  if (tlStatus) out.timeline_status = parseCSV(tlStatus);
+  const tlTrack = params.get(k("tl_track"));
+  if (tlTrack) out.timeline_track = parseCSV(tlTrack);
+
+  // render.shape
+  const shape = params.get(k("shape"));
+  if (shape === "list" || shape === "cards" || shape === "calendar") out.shape = shape;
+
+  // render.list.sort / render.cards.sort — the bar treats sort as one axis
+  const sort = params.get(k("sort"));
+  if (sort === "date_asc" || sort === "date_desc") out.sort = sort;
+
+  // render.list.density
+  const density = params.get(k("density"));
+  if (density === "comfortable" || density === "compact") out.density = density;
+
+  // inbox (t-paliad-249)
+  const unread = params.get(k("unread"));
+  if (unread === "0") out.unread_only = false;
+  else if (unread === "1") out.unread_only = true;
+
+  const focus = params.get(k("focus"));
+  if (focus === "genehmigungen" || focus === "plus_termine" || focus === "plus_fristen" || focus === "alles") {
+    out.inbox_focus = focus as InboxFocus;
+  }
+
+  return out;
+}
+
+// encodeBar writes BarState back into URL params, mutating the
+// passed-in URLSearchParams. Empty / undefined values are omitted.
+// The caller controls how the result is applied (history.replaceState
+// with the page pathname unchanged).
+export function encodeBar(state: BarState, params: URLSearchParams, ns?: string): void {
+  const k = (key: string) => (ns ? `${ns}_${key}` : key);
+
+  // Clear every key the bar owns first, then re-write the non-empty ones.
+  for (const key of [
+    "time", "from", "to", "project", "personal",
+    "d_status", "d_event_type",
+    "app_type",
+    "a_role", "a_status", "a_entity_type",
+    "pe_kind",
+    "tl_status", "tl_track",
+    "shape", "sort", "density",
+    "unread", "focus",
+  ]) {
+    params.delete(k(key));
+  }
+
+  if (state.time) {
+    params.set(k("time"), state.time.horizon);
+    if (state.time.horizon === "custom") {
+      if (state.time.from) params.set(k("from"), state.time.from);
+      if (state.time.to) params.set(k("to"), state.time.to);
+    }
+  }
+
+  if (state.project) {
+    if (state.project.mode === "personal") {
+      params.set(k("project"), PERSONAL_PROJECT_SENTINEL);
+    } else if (state.project.id) {
+      params.set(k("project"), state.project.id);
+    }
+  }
+
+  if (state.personal_only) params.set(k("personal"), "1");
+
+  if (state.deadline_status?.length) params.set(k("d_status"), state.deadline_status.join(","));
+
+  if (state.deadline_event_type) {
+    const parts = [...state.deadline_event_type.ids];
+    if (state.deadline_event_type.include_untyped) parts.push("none");
+    if (parts.length) params.set(k("d_event_type"), parts.join(","));
+  }
+
+  if (state.appointment_type?.length) params.set(k("app_type"), state.appointment_type.join(","));
+  if (state.approval_viewer_role) params.set(k("a_role"), state.approval_viewer_role);
+  if (state.approval_status?.length) params.set(k("a_status"), state.approval_status.join(","));
+  if (state.approval_entity_type?.length) params.set(k("a_entity_type"), state.approval_entity_type.join(","));
+  if (state.project_event_kind?.length) params.set(k("pe_kind"), state.project_event_kind.join(","));
+  if (state.timeline_status?.length) params.set(k("tl_status"), state.timeline_status.join(","));
+  if (state.timeline_track?.length) params.set(k("tl_track"), state.timeline_track.join(","));
+
+  if (state.shape) params.set(k("shape"), state.shape);
+  if (state.sort) params.set(k("sort"), state.sort);
+  if (state.density) params.set(k("density"), state.density);
+
+  // inbox (t-paliad-249). unread_only is tri-state in BarState (undefined
+  // means "page default"); we only write a key when the user has flipped
+  // it explicitly so the URL stays clean for the default landing state.
+  if (state.unread_only === false) params.set(k("unread"), "0");
+  else if (state.unread_only === true) params.set(k("unread"), "1");
+  if (state.inbox_focus && state.inbox_focus !== "alles") {
+    params.set(k("focus"), state.inbox_focus);
+  }
+}
+
+function parseHorizon(s: string): TimeOverlay["horizon"] | null {
+  switch (s) {
+    case "next_1d":
+    case "next_7d":
+    case "next_14d":
+    case "next_30d":
+    case "next_90d":
+    case "next_all":
+    case "past_1d":
+    case "past_7d":
+    case "past_14d":
+    case "past_30d":
+    case "past_90d":
+    case "past_all":
+    case "any":
+    case "all":
+    case "custom":
+      return s;
+    default:
+      return null;
+  }
+}
+
+function parseCSV(s: string): string[] {
+  return s.split(",").map((x) => x.trim()).filter(Boolean);
+}
+
+export { PERSONAL_PROJECT_SENTINEL };
+
+// Re-exported so consumers don't need to import ProjectOverlay just
+// to construct one in tests.
+export type { ProjectOverlay };

frontend/src/client/inbox.ts

@@ -1,122 +1,331 @@
-import { initI18n, t, getLang, type I18nKey } from "./i18n";
+import { initI18n, t } from "./i18n";
 import { initSidebar } from "./sidebar";
+import { mountFilterBar, type BarHandle } from "./filter-bar";
+import type { AxisKey } from "./filter-bar";
+import type { FilterSpec, RenderSpec, SystemView, ViewRunResult } from "./views/types";
+import { renderListShape } from "./views/shape-list";
+import { openApprovalEditModal } from "./components/approval-edit-modal";
 
-// /inbox client. Two tabs (pending-mine / mine), action buttons (approve /
-// reject / revoke), and a small inline diff for update / complete / delete
-// lifecycle events.
+// /inbox client — t-paliad-249 unified inbox feed.
 //
-// State is URL-driven via ?tab= so back/forward buttons work and the bell
-// badge can deep-link to either tab. The badge in the sidebar (id
-// sidebar-inbox-badge) is updated by the shared global polling loop in
-// sidebar.ts; this module just keeps the page content in sync.
+// The bar exposes:
+//   - inbox_focus:        coarse Alles / Genehmigungen / +Termine / +Fristen
+//   - unread_only:        Nur ungelesen / Alle (default: ungelesen)
+//   - time:               last 30 days default; chip cluster + custom range
+//   - project:            single-select autocomplete from visible projects
+//   - approval_viewer_role: Zur Genehmigung / Eigene / Alle sichtbaren
+//   - approval_status / approval_entity_type / project_event_kind: power-user overrides
+//   - sort / density:     newest first default
+//
+// Row rendering: shape-list.ts with row_action="inbox" dispatches per
+// row.kind. Approval rows keep approve/reject/revoke; project_event
+// rows render compact with an Öffnen link.
 
-type Lifecycle = "create" | "update" | "complete" | "delete";
-type RequestStatus = "pending" | "approved" | "rejected" | "revoked" | "superseded";
-type DecisionKind = "peer" | "admin_override";
+const INBOX_AXES: AxisKey[] = [
+  "inbox_focus",
+  "unread_only",
+  "time",
+  "project",
+  "approval_viewer_role",
+  "approval_status",
+  "approval_entity_type",
+  "project_event_kind",
+  "sort",
+  "density",
+];
 
-interface ApprovalRequestView {
-  id: string;
-  project_id: string;
-  project_title: string;
-  entity_type: "deadline" | "appointment";
-  entity_id: string;
-  entity_title?: string;
-  lifecycle_event: Lifecycle;
-  pre_image?: Record<string, unknown> | null;
-  payload?: Record<string, unknown> | null;
-  required_role: string;
-  status: RequestStatus;
-  requested_at: string;
-  requested_by: string;
-  requester_name: string;
-  decided_at?: string;
-  decided_by?: string;
-  decider_name?: string;
-  decision_kind?: DecisionKind;
-  decision_note?: string;
-  // t-paliad-161: 'user' (direct create) or 'agent' (Paliadin-drafted).
-  // 'agent' rows render with a sparkle ✨ next to the requester's name.
-  requester_kind?: "user" | "agent";
-  agent_turn_id?: string;
-}
+// Last paint's newest row timestamp — used to pin mark-all-seen so a
+// second tab can't race the cursor past items the user hasn't seen.
+let newestVisibleAt: string | null = null;
 
-type Tab = "pending-mine" | "mine";
-
-let currentTab: Tab = "pending-mine";
-
-initI18n();
-initSidebar();
+let bar: BarHandle | null = null;
 
 document.addEventListener("DOMContentLoaded", () => {
-  const url = new URL(window.location.href);
-  const t = url.searchParams.get("tab");
-  if (t === "mine") currentTab = "mine";
-  bindTabs();
-  refresh();
+  initI18n();
+  initSidebar();
+  applyLegacyTabRedirect();
+  wireMarkAllSeen();
+  void hydrate();
 });
 
-function bindTabs() {
-  document.querySelectorAll<HTMLButtonElement>("#inbox-tab-row [data-tab]").forEach((btn) => {
-    btn.addEventListener("click", () => {
-      const tab = (btn.dataset.tab as Tab) || "pending-mine";
-      if (tab === currentTab) return;
-      currentTab = tab;
-      const url = new URL(window.location.href);
-      url.searchParams.set("tab", tab);
-      history.replaceState({}, "", url.toString());
-      document.querySelectorAll<HTMLButtonElement>("#inbox-tab-row [data-tab]").forEach((b) => {
-        b.classList.toggle("active", b.dataset.tab === tab);
-      });
-      refresh();
-    });
+// ?tab=pending-mine | mine -> ?a_role=approver_eligible | self_requested.
+// Done client-side because /inbox serves a static dist file (no Go
+// router involvement). Bookmarks from the sidebar bell + outbound
+// emails keep landing on the right sub-view through the bar.
+function applyLegacyTabRedirect(): void {
+  const url = new URL(window.location.href);
+  const tab = url.searchParams.get("tab");
+  if (!tab) return;
+  url.searchParams.delete("tab");
+  if (tab === "mine") {
+    url.searchParams.set("a_role", "self_requested");
+  } else if (tab === "pending-mine") {
+    url.searchParams.set("a_role", "approver_eligible");
+  }
+  history.replaceState(null, "", url.toString());
+}
+
+async function hydrate(): Promise<void> {
+  const host = document.getElementById("inbox-filter-bar");
+  const loading = document.getElementById("inbox-loading");
+  const results = document.getElementById("inbox-results");
+  const empty = document.getElementById("inbox-empty");
+  if (!host || !loading || !results || !empty) return;
+
+  const sys = await fetchInboxSystemView();
+  if (!sys) {
+    loading.style.display = "none";
+    empty.style.display = "";
+    empty.textContent = t("approvals.error.internal");
+    return;
+  }
+
+  bar = mountFilterBar(host, {
+    baseFilter: sys.Filter,
+    baseRender: sys.Render,
+    axes: INBOX_AXES,
+    surfaceKey: "inbox",
+    systemViewSlug: sys.Slug,
+    onResult: (result, effective) => paint(result, effective.render, results, empty, loading),
   });
 }
 
-async function refresh() {
-  const loading = document.getElementById("inbox-loading") as HTMLElement | null;
-  const empty = document.getElementById("inbox-empty") as HTMLElement | null;
-  const list = document.getElementById("inbox-list") as HTMLUListElement | null;
-  if (!loading || !empty || !list) return;
-  loading.style.display = "";
-  empty.style.display = "none";
-  list.innerHTML = "";
-  const path = currentTab === "pending-mine" ? "/api/inbox/pending-mine" : "/api/inbox/mine";
-  let rows: ApprovalRequestView[] = [];
+async function fetchInboxSystemView(): Promise<SystemView | null> {
   try {
-    const r = await fetch(path, { credentials: "include" });
-    if (r.ok) {
-      // Defensive: a Go `nil` slice serialises as JSON `null`, not `[]`.
-      // Coerce so `rows.length` never throws (t-paliad-160 §D regression
-      // hardening). Server-side handler also forces `[]`, but keep the
-      // client guard for older / cached deploys.
-      const body = (await r.json()) as ApprovalRequestView[] | null;
-      rows = body ?? [];
-    }
+    const r = await fetch("/api/views/system", { credentials: "include" });
+    if (!r.ok) return null;
+    const list = (await r.json()) as SystemView[];
+    return list.find((v) => v.Slug === "inbox") ?? null;
   } catch (_e) {
-    // Network errors fall through to empty render.
+    return null;
   }
+}
+
+function paint(
+  result: ViewRunResult,
+  render: RenderSpec,
+  results: HTMLElement,
+  empty: HTMLElement,
+  loading: HTMLElement,
+): void {
   loading.style.display = "none";
-  if (rows.length === 0) {
-    empty.textContent = t(
-      currentTab === "pending-mine"
-        ? "approvals.empty.pending_mine"
-        : "approvals.empty.mine"
-    );
+
+  if (!result.rows || result.rows.length === 0) {
+    results.innerHTML = "";
     empty.style.display = "";
+    empty.textContent = t("inbox.empty.feed");
+    newestVisibleAt = null;
     void maybeShowAdminNudge();
     return;
   }
   hideAdminNudge();
-  for (const row of rows) list.appendChild(renderRow(row));
+  empty.style.display = "none";
+
+  // Remember the newest timestamp so mark-all-seen can pin the cursor
+  // to it (race-safety: a second tab adding a row between this paint
+  // and the click won't get wiped out).
+  newestVisibleAt = result.rows.reduce<string | null>((acc, r) => {
+    if (!acc) return r.event_date;
+    return r.event_date > acc ? r.event_date : acc;
+  }, null);
+
+  // shape-list.ts honours render.list.row_action — InboxSystemView's
+  // RenderSpec sets row_action="inbox" so we get the unified dispatch
+  // (approval rows + project_event rows).
+  renderListShape(results, result.rows, render);
+
+  // Wire action handlers on the freshly stamped DOM. The action
+  // POSTs land on the same endpoints the legacy /inbox used; on
+  // success we trigger a bar refresh so the new state propagates.
+  wireApprovalActions(results);
+}
+
+// wireMarkAllSeen wires the page-header "Alles als gelesen markieren"
+// button. POSTs the newest visible row's timestamp as `up_to` so a
+// stale second tab can't rewind anyone else's cursor; on success the
+// bar refreshes (rows newer than now disappear under unread_only) and
+// the sidebar badge re-counts.
+function wireMarkAllSeen(): void {
+  const btn = document.getElementById("inbox-mark-all-seen") as HTMLButtonElement | null;
+  if (!btn) return;
+  btn.addEventListener("click", async () => {
+    btn.disabled = true;
+    try {
+      const body = newestVisibleAt ? JSON.stringify({ up_to: newestVisibleAt }) : "{}";
+      const r = await fetch("/api/inbox/mark-all-seen", {
+        method: "POST",
+        credentials: "include",
+        headers: { "Content-Type": "application/json" },
+        body,
+      });
+      if (!r.ok) {
+        alert(t("approvals.error.internal"));
+        return;
+      }
+      await bar?.refresh();
+      await refreshInboxBadge();
+    } catch (_e) {
+      alert("Network error");
+    } finally {
+      btn.disabled = false;
+    }
+  });
+}
+
+function wireApprovalActions(host: HTMLElement): void {
+  host.querySelectorAll<HTMLButtonElement>(".views-approval-action").forEach((btn) => {
+    const action = btn.dataset.action as
+      | "approve"
+      | "reject"
+      | "revoke"
+      | "suggest_changes"
+      | undefined;
+    const li = btn.closest<HTMLLIElement>(".views-approval-row");
+    const id = li?.dataset.requestId;
+    if (!action || !id) return;
+    btn.addEventListener("click", async () => {
+      if (action === "suggest_changes") {
+        await handleSuggestChanges(btn, id, li!);
+        return;
+      }
+      let note = "";
+      if (action === "reject") {
+        note = window.prompt(t("approvals.note.placeholder")) || "";
+      }
+      btn.disabled = true;
+      try {
+        const r = await fetch(`/api/approval-requests/${id}/${action}`, {
+          method: "POST",
+          credentials: "include",
+          headers: { "Content-Type": "application/json" },
+          body: JSON.stringify({ note }),
+        });
+        if (!r.ok) {
+          const body = await r.json().catch(() => ({} as { error?: string; code?: string }));
+          alert(mapApprovalError(body.code || body.error || "internal"));
+          btn.disabled = false;
+          return;
+        }
+        await bar?.refresh();
+        await refreshInboxBadge();
+      } catch (_e) {
+        alert("Network error");
+        btn.disabled = false;
+      }
+    });
+  });
+}
+
+// handleSuggestChanges — t-paliad-216. Open the edit modal with the
+// requester's original payload + pre_image pre-populated. If the user
+// submits non-empty changes / note, POST to
+// /api/approval-requests/{id}/suggest-changes; refresh the bar on success
+// so the OLD row flips to changes_requested and the NEW pending row
+// appears.
+async function handleSuggestChanges(
+  btn: HTMLButtonElement,
+  requestID: string,
+  li: HTMLLIElement,
+): Promise<void> {
+  // Read the row's detail blob off the data-attrs the shape-list stamped.
+  // shape-list serialises payload/pre_image inline; we fetch fresh via
+  // the per-row API to avoid relying on stale list data.
+  let payload: Record<string, unknown> | null = null;
+  let preImage: Record<string, unknown> | null = null;
+  let entityType: "deadline" | "appointment" = "deadline";
+  let lifecycleEvent = "update";
+  let projectTitle: string | undefined;
+  let requesterName: string | undefined;
+  let requestedAt: string | undefined;
+  try {
+    const r = await fetch(`/api/approval-requests/${requestID}`, { credentials: "include" });
+    if (r.ok) {
+      const body = (await r.json()) as {
+        entity_type?: "deadline" | "appointment";
+        lifecycle_event?: string;
+        payload?: Record<string, unknown> | null;
+        pre_image?: Record<string, unknown> | null;
+        project_title?: string;
+        requester_name?: string;
+        requested_at?: string;
+      };
+      payload = body.payload ?? null;
+      preImage = body.pre_image ?? null;
+      if (body.entity_type === "appointment") entityType = "appointment";
+      if (body.lifecycle_event) lifecycleEvent = body.lifecycle_event;
+      projectTitle = body.project_title;
+      requesterName = body.requester_name;
+      requestedAt = body.requested_at;
+    }
+  } catch (_e) {
+    // Modal still opens with empty defaults if the fetch fails; the
+    // server-side schema validation catches a misshapen counter.
+  }
+
+  const result = await openApprovalEditModal({
+    entityType,
+    lifecycleEvent,
+    payload,
+    preImage,
+    projectTitle,
+    requesterName,
+    requestedAt,
+  });
+  if (!result) return; // cancel
+
+  btn.disabled = true;
+  try {
+    const r = await fetch(`/api/approval-requests/${requestID}/suggest-changes`, {
+      method: "POST",
+      credentials: "include",
+      headers: { "Content-Type": "application/json" },
+      body: JSON.stringify({
+        counter_payload: result.counterPayload,
+        note: result.note,
+      }),
+    });
+    const body = (await r.json().catch(() => ({}))) as {
+      error?: string;
+      code?: string;
+      new_request_id?: string;
+    };
+    if (!r.ok) {
+      alert(mapApprovalError(body.code || body.error || "internal"));
+      btn.disabled = false;
+      return;
+    }
+    await bar?.refresh();
+    await refreshInboxBadge();
+    btn.disabled = false;
+
+    // Surface the new row's id on the OLD row's <li> so callers (e.g.
+    // tests, future inspection) can find it without re-querying.
+    if (body.new_request_id) {
+      li.dataset.spawnedRequestId = body.new_request_id;
+    }
+  } catch (_e) {
+    alert("Network error");
+    btn.disabled = false;
+  }
+}
+
+function mapApprovalError(key: string): string {
+  switch (key) {
+    case "self_approval_blocked":         return t("approvals.error.self_approval");
+    case "no_qualified_approver":         return t("approvals.error.no_qualified_approver");
+    case "concurrent_pending":            return t("approvals.error.concurrent_pending");
+    case "not_authorized":                return t("approvals.error.not_authorized");
+    case "request_not_pending":           return t("approvals.error.request_not_pending");
+    case "suggestion_requires_change":    return t("approvals.error.suggestion_requires_change");
+    case "suggestion_lifecycle_invalid":  return t("approvals.error.suggestion_lifecycle_invalid");
+    default:                              return key;
+  }
 }
 
 // t-paliad-154 — show the admin-only "configure policies" nudge when:
-//  - the current user is global_admin
-//  - the inbox is empty
-//  - no approval_policies row exists firm-wide (matrix is dormant)
-//
-// All three checks are AND-ed. Anonymous users + non-admins + active-policy
-// admins all skip the nudge.
+//   - current user is global_admin
+//   - inbox empty
+//   - no approval_policies row exists firm-wide
 async function maybeShowAdminNudge(): Promise<void> {
   const nudge = document.getElementById("inbox-admin-nudge");
   if (!nudge) return;
@@ -132,9 +341,7 @@ async function maybeShowAdminNudge(): Promise<void> {
     if (data.any) return;
 
     nudge.style.display = "";
-  } catch (_e) {
-    // Network failure → keep nudge hidden.
-  }
+  } catch (_e) { /* keep hidden */ }
 }
 
 function hideAdminNudge(): void {
@@ -142,175 +349,7 @@ function hideAdminNudge(): void {
   if (nudge) nudge.style.display = "none";
 }
 
-function renderRow(row: ApprovalRequestView): HTMLLIElement {
-  const li = document.createElement("li");
-  li.className = "inbox-row";
-
-  // Header: project / entity / lifecycle / required-role
-  const head = document.createElement("div");
-  head.className = "inbox-row-head";
-  const title = document.createElement("div");
-  title.className = "inbox-row-title";
-  const entityLabel = t(("approvals.entity." + row.entity_type) as I18nKey);
-  const lifecycleLabel = t(("approvals.lifecycle." + row.lifecycle_event) as I18nKey);
-  const entityTitle = row.entity_title || "—";
-  title.textContent = `${entityLabel}: ${entityTitle} — ${lifecycleLabel}`;
-  head.appendChild(title);
-
-  const meta = document.createElement("div");
-  meta.className = "inbox-row-meta";
-  const reqByLabel = t("approvals.requested_by");
-  const roleLabel = t(("approvals.required_role." + row.required_role) as I18nKey);
-  // t-paliad-161 ✨: when the request was drafted by Paliadin, surface
-  // that next to the requester's name. Reads as "von Anna ✨ Paliadin".
-  const requesterTag = row.requester_kind === "agent"
-    ? `${row.requester_name} ✨ ${t("approvals.agent.byline")}`
-    : row.requester_name;
-  meta.textContent = `${row.project_title} · ${reqByLabel} ${requesterTag} · ${roleLabel}+ · ${formatRelativeTime(row.requested_at)}`;
-  head.appendChild(meta);
-  li.appendChild(head);
-
-  // Diff for update / complete (date-bearing fields)
-  const diff = renderDiff(row);
-  if (diff) li.appendChild(diff);
-
-  // Decision note if any
-  if (row.decision_note) {
-    const note = document.createElement("div");
-    note.className = "inbox-row-note";
-    note.textContent = row.decision_note;
-    li.appendChild(note);
-  }
-
-  // Action row
-  const actions = document.createElement("div");
-  actions.className = "inbox-row-actions";
-
-  if (row.status === "pending" && currentTab === "pending-mine") {
-    actions.appendChild(actionButton("approve", row.id, () => doDecision(row.id, "approve")));
-    actions.appendChild(actionButton("reject", row.id, () => doDecision(row.id, "reject")));
-  } else if (row.status === "pending" && currentTab === "mine") {
-    actions.appendChild(actionButton("revoke", row.id, () => doDecision(row.id, "revoke")));
-  } else {
-    // historic — show status pill
-    const pill = document.createElement("span");
-    pill.className = "approval-pill approval-pill--historic";
-    pill.textContent = t(("approvals.status." + row.status) as I18nKey);
-    if (row.decider_name && row.status !== "revoked") {
-      const decided = document.createElement("span");
-      decided.className = "inbox-row-decided";
-      decided.textContent = ` · ${t("approvals.decided_by")} ${row.decider_name}`;
-      pill.appendChild(decided);
-    }
-    actions.appendChild(pill);
-  }
-  li.appendChild(actions);
-
-  return li;
-}
-
-function renderDiff(row: ApprovalRequestView): HTMLElement | null {
-  const before = (row.pre_image || {}) as Record<string, unknown>;
-  const after = (row.payload || {}) as Record<string, unknown>;
-  const keys = Array.from(new Set([...Object.keys(before), ...Object.keys(after)]));
-  if (keys.length === 0) return null;
-  const wrap = document.createElement("div");
-  wrap.className = "inbox-row-diff";
-  for (const k of keys) {
-    const line = document.createElement("div");
-    line.className = "inbox-row-diff-line";
-    const label = document.createElement("span");
-    label.className = "inbox-row-diff-key";
-    label.textContent = k;
-    line.appendChild(label);
-    const span = document.createElement("span");
-    span.className = "inbox-row-diff-values";
-    const fmt = (v: unknown) =>
-      v === null || v === undefined ? "—" : String(v);
-    if (k in before && k in after) {
-      span.textContent = `${fmt(before[k])} → ${fmt(after[k])}`;
-    } else if (k in before) {
-      span.textContent = `${t("approvals.diff.before")}: ${fmt(before[k])}`;
-    } else {
-      span.textContent = `${t("approvals.diff.after")}: ${fmt(after[k])}`;
-    }
-    line.appendChild(span);
-    wrap.appendChild(line);
-  }
-  return wrap;
-}
-
-function actionButton(action: "approve" | "reject" | "revoke", _requestID: string, onClick: () => void): HTMLButtonElement {
-  const btn = document.createElement("button");
-  btn.type = "button";
-  btn.className = `btn btn-${action === "approve" ? "primary" : action === "reject" ? "danger" : "secondary"} inbox-row-action`;
-  btn.textContent = t(("approvals.action." + action) as I18nKey);
-  btn.addEventListener("click", onClick);
-  return btn;
-}
-
-async function doDecision(requestID: string, action: "approve" | "reject" | "revoke") {
-  let note = "";
-  if (action === "reject") {
-    note = window.prompt(t("approvals.note.placeholder")) || "";
-  }
-  let r: Response;
-  try {
-    r = await fetch(`/api/approval-requests/${requestID}/${action}`, {
-      method: "POST",
-      credentials: "include",
-      headers: { "Content-Type": "application/json" },
-      body: JSON.stringify({ note }),
-    });
-  } catch (_e) {
-    alert("Network error");
-    return;
-  }
-  if (!r.ok) {
-    const body = await r.json().catch(() => ({}));
-    const errKey = (body && body.error) || "internal";
-    const msg = mapApprovalError(errKey);
-    alert(msg);
-    return;
-  }
-  refresh();
-  // Update sidebar bell count.
-  refreshInboxBadge();
-}
-
-function mapApprovalError(key: string): string {
-  switch (key) {
-    case "self_approval_blocked":
-      return t("approvals.error.self_approval");
-    case "no_qualified_approver":
-      return t("approvals.error.no_qualified_approver");
-    case "concurrent_pending":
-      return t("approvals.error.concurrent_pending");
-    case "not_authorized":
-      return t("approvals.error.not_authorized");
-    case "request_not_pending":
-      return t("approvals.error.request_not_pending");
-    default:
-      return key;
-  }
-}
-
-function formatRelativeTime(iso: string): string {
-  const t0 = Date.parse(iso);
-  if (isNaN(t0)) return iso;
-  const diffMs = Date.now() - t0;
-  const sec = Math.floor(diffMs / 1000);
-  if (sec < 60) return getLang() === "de" ? `vor ${sec}s` : `${sec}s ago`;
-  const min = Math.floor(sec / 60);
-  if (min < 60) return getLang() === "de" ? `vor ${min}m` : `${min}m ago`;
-  const hr = Math.floor(min / 60);
-  if (hr < 24) return getLang() === "de" ? `vor ${hr}h` : `${hr}h ago`;
-  const day = Math.floor(hr / 24);
-  return getLang() === "de" ? `vor ${day}d` : `${day}d ago`;
-}
-
-// Update the sidebar inbox badge (shared with sidebar.ts polling).
-async function refreshInboxBadge() {
+async function refreshInboxBadge(): Promise<void> {
   const badge = document.getElementById("sidebar-inbox-badge");
   if (!badge) return;
   try {
@@ -323,7 +362,5 @@ async function refreshInboxBadge() {
     } else {
       badge.style.display = "none";
     }
-  } catch (_e) {
-    /* noop */
-  }
+  } catch (_e) { /* noop */ }
 }

frontend/src/client/paliadin-context.ts

@@ -93,12 +93,13 @@ export function routeNameFor(pathname: string): string {
   if (/^\/projects\/[^/]+\/settings/.test(pathname)) return "projects.settings";
   if (/^\/deadlines\/[^/]+$/.test(pathname)) return "deadlines.detail";
   if (pathname === "/deadlines/new") return "deadlines.new";
-  if (pathname === "/deadlines/calendar") return "deadlines.calendar";
   if (pathname === "/deadlines") return "deadlines.list";
   if (/^\/appointments\/[^/]+$/.test(pathname)) return "appointments.detail";
   if (pathname === "/appointments/new") return "appointments.new";
-  if (pathname === "/appointments/calendar") return "appointments.calendar";
   if (pathname === "/appointments") return "appointments.list";
+  // /deadlines/calendar + /appointments/calendar are 301 redirects to
+  // /events?type=…&view=calendar since t-paliad-224 — the client never
+  // sees those pathnames any more.
   if (pathname === "/agenda") return "agenda";
   if (pathname === "/inbox") return "inbox";
   if (pathname === "/dashboard" || pathname === "/") return "dashboard";

frontend/src/client/paliadin-late-poll.ts

@@ -0,0 +1,132 @@
+// Late-response polling (t-paliad-235 rewrite).
+//
+// When the SSE stream closes mid-turn with an error event, the bubble
+// can't tell from the wire whether (a) the upstream is still finishing
+// the turn and we just lost transport, or (b) the upstream is truly
+// dead.
+//
+// This module hits the dispatching recovery endpoint
+// `/api/paliadin/turns/{id}/recover`, which knows the active backend:
+//
+//   - aichat backend  → asks aichat via its conversation API whether
+//                       the turn actually completed upstream
+//   - legacy backend  → reads the local row (paliad's filesystem
+//                       janitor patches it when claude writes the
+//                       response file late)
+//
+// The endpoint returns:
+//
+//   recovery_state="recovered" → response is in the payload, render it
+//   recovery_state="pending"   → keep polling
+//   recovery_state="lost"      → upstream is truly gone, give up
+
+export interface LateTurn {
+  turn_id: string;
+  response: string | null;
+  error_code: string | null;
+  finished_at: string | null;
+  duration_ms: number | null;
+  used_tools: string[];
+  rows_seen: number[];
+  chip_count: number;
+  classifier_tag: string | null;
+}
+
+export interface LatePollOptions {
+  turnId: string;
+  intervalMs?: number;     // default 3000
+  maxDurationMs?: number;  // default 600000 (10 min)
+  onLateResponse: (turn: LateTurn) => void;
+  // onLost — backend confirmed the turn is unrecoverable. Caller should
+  // swap the bubble copy to the "verloren" string. Distinct from
+  // onGiveUp (which fires only on the local timeout).
+  onLost?: () => void;
+  onGiveUp?: () => void;
+}
+
+export interface LatePollHandle {
+  cancel: () => void;
+}
+
+interface RecoverResponse {
+  turn_id: string;
+  started_at: string;
+  response: string | null;
+  error_code: string | null;
+  finished_at: string | null;
+  duration_ms: number | null;
+  used_tools: string[];
+  rows_seen: number[];
+  chip_count: number;
+  classifier_tag: string | null;
+  recovery_state: "recovered" | "pending" | "lost";
+}
+
+export function pollForLateResponse(opts: LatePollOptions): LatePollHandle {
+  const interval = opts.intervalMs ?? 3000;
+  const maxDuration = opts.maxDurationMs ?? 10 * 60 * 1000;
+  const startedAt = Date.now();
+
+  let cancelled = false;
+  let timer: number | undefined;
+
+  const tick = async () => {
+    if (cancelled) return;
+    if (Date.now() - startedAt > maxDuration) {
+      opts.onGiveUp?.();
+      return;
+    }
+    try {
+      const r = await fetch(`/api/paliadin/turns/${opts.turnId}/recover`, {
+        credentials: "same-origin",
+      });
+      if (r.ok) {
+        const body = (await r.json()) as RecoverResponse;
+        if (body.recovery_state === "recovered" && body.response) {
+          opts.onLateResponse(toLateTurn(body));
+          return;
+        }
+        if (body.recovery_state === "lost") {
+          opts.onLost?.();
+          return;
+        }
+        // pending — keep polling
+      } else if (r.status === 404) {
+        // Row gone — give up. Different signal from `lost`: a missing row
+        // is a paliad-side bookkeeping problem; aichat may still have the
+        // answer but we can't surface it without the row.
+        opts.onGiveUp?.();
+        return;
+      }
+    } catch {
+      // Transient network error; retry on next tick.
+    }
+    timer = window.setTimeout(tick, interval);
+  };
+
+  // First poll deliberately runs after one interval so we don't race
+  // the dispatch endpoint on the very first tick (gives the upstream a
+  // moment to actually settle the row after the stream drop).
+  timer = window.setTimeout(tick, interval);
+
+  return {
+    cancel: () => {
+      cancelled = true;
+      if (timer != null) window.clearTimeout(timer);
+    },
+  };
+}
+
+function toLateTurn(body: RecoverResponse): LateTurn {
+  return {
+    turn_id: body.turn_id,
+    response: body.response,
+    error_code: body.error_code,
+    finished_at: body.finished_at,
+    duration_ms: body.duration_ms,
+    used_tools: body.used_tools ?? [],
+    rows_seen: body.rows_seen ?? [],
+    chip_count: body.chip_count ?? 0,
+    classifier_tag: body.classifier_tag,
+  };
+}

frontend/src/client/paliadin-render.ts

@@ -0,0 +1,134 @@
+// Shared Paliadin response renderer — used by both the standalone
+// /paliadin page (client/paliadin.ts) and the inline drawer widget
+// (client/paliadin-widget.ts). Extracted from paliadin.ts so the
+// widget renders the same markdown + chips as the dedicated page
+// without re-implementing the pipeline.
+
+const CHIP_RE = /\[(?:#([a-z]+)-OPEN:([A-Za-z0-9\-_]+)|chip:([a-z]+):([^\]]+))\]/g;
+const MD_LINK_RE = /\[([^\]\n]+)\]\(((?:https?:\/\/|\/)[^\s)]+)\)/g;
+const BARE_URL_RE = /(^|[^"=>])(https?:\/\/[^\s<>"']+)/g;
+
+function chipURL(kind: string, id: string): string {
+  switch (kind) {
+    case "deadline":
+    case "frist":
+      return "/deadlines/" + id;
+    case "projekt":
+    case "project":
+      return "/projects/" + id;
+    case "termin":
+    case "appointment":
+      return "/appointments/" + id;
+    default:
+      return "#";
+  }
+}
+
+function chipLabel(kind: string): string {
+  switch (kind) {
+    case "deadline":
+    case "frist":
+      return "Frist öffnen";
+    case "projekt":
+    case "project":
+      return "Akte ansehen";
+    case "termin":
+    case "appointment":
+      return "Termin öffnen";
+    default:
+      return "öffnen";
+  }
+}
+
+function renderBlocks(escapedHtml: string): string {
+  const out: string[] = [];
+  let listItems: string[] = [];
+  let paraLines: string[] = [];
+
+  const flushList = () => {
+    if (listItems.length === 0) return;
+    out.push(`<ul class="paliadin-list">${listItems.map((li) => `<li>${li}</li>`).join("")}</ul>`);
+    listItems = [];
+  };
+  const flushPara = () => {
+    if (paraLines.length === 0) return;
+    out.push(`<p>${paraLines.join("<br>")}</p>`);
+    paraLines = [];
+  };
+
+  for (const rawLine of escapedHtml.split("\n")) {
+    const line = rawLine.trim();
+    if (line === "") {
+      flushList();
+      flushPara();
+      continue;
+    }
+    let m: RegExpMatchArray | null;
+    if ((m = line.match(/^###\s+(.+)$/))) {
+      flushList();
+      flushPara();
+      out.push(`<h3>${m[1]}</h3>`);
+    } else if ((m = line.match(/^##\s+(.+)$/))) {
+      flushList();
+      flushPara();
+      out.push(`<h2>${m[1]}</h2>`);
+    } else if ((m = line.match(/^[-*]\s+(.+)$/))) {
+      flushPara();
+      listItems.push(m[1]);
+    } else if (line.match(/^---+$/)) {
+      flushList();
+      flushPara();
+      out.push(`<hr>`);
+    } else {
+      flushList();
+      paraLines.push(line);
+    }
+  }
+  flushList();
+  flushPara();
+  return out.join("");
+}
+
+export function renderResponseHTML(raw: string): string {
+  let html = raw
+    .replace(/&/g, "&amp;")
+    .replace(/</g, "&lt;")
+    .replace(/>/g, "&gt;")
+    .replace(/"/g, "&quot;");
+
+  const chipHTML: string[] = [];
+  html = html.replace(CHIP_RE, (_match, kind, id, chipKind, chipArg) => {
+    let rendered = "";
+    if (kind && id) {
+      const url = chipURL(kind, id);
+      const label = chipLabel(kind);
+      rendered = `<a class="paliadin-chip" href="${url}">${label}</a>`;
+    } else if (chipKind === "nav") {
+      rendered = `<a class="paliadin-chip" href="${chipArg}">öffnen</a>`;
+    } else if (chipKind === "filter") {
+      rendered = `<a class="paliadin-chip" href="/inbox?${chipArg}">Filter anwenden</a>`;
+    }
+    if (!rendered) return "";
+    chipHTML.push(rendered);
+    return `CHIP${chipHTML.length - 1}`;
+  });
+
+  html = renderBlocks(html);
+
+  html = html.replace(MD_LINK_RE, (_m, text, url) => {
+    const ext = url.startsWith("http");
+    const attrs = ext ? ` target="_blank" rel="noopener noreferrer"` : "";
+    return `<a href="${url}" class="paliadin-link"${attrs}>${text}</a>`;
+  });
+
+  html = html.replace(BARE_URL_RE, (_m, prefix, url) => {
+    return `${prefix}<a href="${url}" class="paliadin-link" target="_blank" rel="noopener noreferrer">${url}</a>`;
+  });
+
+  html = html.replace(/\*\*([^*\n]+)\*\*/g, "<strong>$1</strong>");
+  html = html.replace(/(^|[^*])\*([^*\n]+)\*(?!\*)/g, "$1<em>$2</em>");
+
+  html = html.replace(/CHIP(\d+)/g, (_m, idx) => chipHTML[Number(idx)] || "");
+
+  return html;
+}

frontend/src/client/paliadin-widget.ts

@@ -26,6 +26,8 @@
 import { initI18n, getLang, t } from "./i18n";
 import { computePaliadinContext, shouldSendContext, routeNameFor } from "./paliadin-context";
 import { startersFor, type Starter } from "./paliadin-starters";
+import { renderResponseHTML } from "./paliadin-render";
+import { pollForLateResponse, type LateTurn, type LatePollHandle } from "./paliadin-late-poll";
 
 interface MeResponse {
   id: string;
@@ -45,14 +47,26 @@ interface TurnResponse {
   sse_url: string;
 }
 
-const SESSION_KEY = "paliadin:widget:session";
-const HISTORY_PREFIX = "paliadin:widget:history:";
+// Shared session key — the inline drawer and the standalone /paliadin
+// page must use the same browser-session id so both surfaces show the
+// same conversation. Migration on first run: if a legacy
+// `paliadin:widget:session` exists but the shared `paliadin:session`
+// does not, copy across so the user doesn't lose drawer state on the
+// rollover.
+const SESSION_KEY = "paliadin:session";
+const LEGACY_WIDGET_SESSION_KEY = "paliadin:widget:session";
+// History bucket — render-cache only; DB is source of truth (server
+// hydrates via /api/paliadin/history on every mount). The cache is keyed
+// by session id so a session reset gives a clean slate.
+const HISTORY_PREFIX = "paliadin:history:";
 
 let sessionId: string;
 let history: HistoryEntry[] = [];
 let drawerOpen = false;
 let activeStream: EventSource | null = null;
 let pending = false;
+// Late-response pollers per turn_id (see paliadin-late-poll.ts).
+const lateWidgetPolls = new Map<string, LatePollHandle>();
 
 document.addEventListener("DOMContentLoaded", () => {
   const trigger = document.getElementById("paliadin-widget-trigger");
@@ -70,9 +84,16 @@ document.addEventListener("DOMContentLoaded", () => {
 function bootSession(): void {
   let s = localStorage.getItem(SESSION_KEY);
   if (!s) {
-    s = crypto.randomUUID();
+    // One-time migration: previous widget builds wrote
+    // `paliadin:widget:session` instead of the shared key. Carry over
+    // the existing id so the user keeps their conversation thread.
+    const legacy = localStorage.getItem(LEGACY_WIDGET_SESSION_KEY);
+    s = legacy || crypto.randomUUID();
     localStorage.setItem(SESSION_KEY, s);
   }
+  // Drop the legacy key now that we've migrated; harmless if it's
+  // already absent.
+  localStorage.removeItem(LEGACY_WIDGET_SESSION_KEY);
   sessionId = s;
   loadHistory();
 }
@@ -119,6 +140,10 @@ async function revealIfOwner(): Promise<void> {
   showTrigger();
   renderStarters();
   rehydrateHistory();
+  // Refresh from DB in the background so cross-surface activity (a
+  // turn typed on the standalone /paliadin page) shows up here without
+  // a manual reload.
+  void hydrateFromServer();
 }
 
 function isPaliadinOwner(me: MeResponse): boolean {
@@ -195,6 +220,10 @@ function openDrawer(): void {
 
   refreshContextChip();
   renderStarters();
+  // Pull the canonical conversation from the DB on every open so a
+  // turn the user typed on /paliadin (or another tab) since the last
+  // open is reflected here.
+  void hydrateFromServer();
   setTimeout(() => {
     document.getElementById("paliadin-widget-input")?.focus();
   }, 60);
@@ -352,11 +381,32 @@ async function sendTurn(): Promise<void> {
   const es = new EventSource(turnRes.sse_url);
   activeStream = es;
 
+  startWidgetThinking(placeholder);
+
   let fullText = "";
+  es.addEventListener("thinking", (ev) => {
+    let elapsed = 0;
+    try {
+      const data = JSON.parse((ev as MessageEvent).data || "{}");
+      if (typeof data.elapsed_seconds === "number") elapsed = data.elapsed_seconds;
+    } catch {
+      /* ignore */
+    }
+    updateWidgetThinking(placeholder, elapsed);
+  });
   es.addEventListener("content", (ev) => {
     try {
       const data = JSON.parse((ev as MessageEvent).data);
+      if (typeof data.delta === "string" && data.delta) {
+        // Streamed delta (aichat backend) — append.
+        stopWidgetThinking(placeholder);
+        fullText += data.delta;
+        setBubbleText(placeholder, fullText);
+        return;
+      }
+      // Legacy one-shot full-text payload.
       fullText = String(data.text || "");
+      stopWidgetThinking(placeholder);
       setBubbleText(placeholder, fullText);
     } catch {
       /* ignore parse error */
@@ -364,14 +414,20 @@ async function sendTurn(): Promise<void> {
   });
   es.addEventListener("end", () => {
     placeholder.dataset.streaming = "false";
+    stopWidgetThinking(placeholder);
     history.push({ role: "assistant", text: fullText || "", ts: new Date().toISOString() });
     saveHistory();
     cleanupStream();
   });
   es.addEventListener("error", () => {
-    setBubbleText(placeholder, t("paliadin.error.connection_lost"));
+    stopWidgetThinking(placeholder);
+    const errText = t("paliadin.error.connection_lost");
+    setBubbleText(placeholder, errText + " " + t("paliadin.late.checking"));
     placeholder.classList.add("paliadin-widget-bubble--error");
+    placeholder.classList.add("paliadin-widget-bubble--late-pending");
     placeholder.dataset.streaming = "false";
+    placeholder.dataset.turnId = turnRes.turn_id;
+    startWidgetLatePoll(turnRes.turn_id, placeholder);
     cleanupStream();
   });
   es.addEventListener("ping", () => {
@@ -379,6 +435,39 @@ async function sendTurn(): Promise<void> {
   });
 }
 
+function startWidgetThinking(bubble: HTMLElement): void {
+  if (bubble.querySelector(".paliadin-widget-thinking")) return;
+  // Clear the static placeholder text — the live pulse + counter is
+  // the canonical "denkt nach" signal.
+  const textNode = bubble.querySelector(".paliadin-widget-bubble-text");
+  if (textNode) textNode.textContent = "";
+  const node = document.createElement("div");
+  node.className = "paliadin-widget-thinking";
+  node.innerHTML = `
+    <span class="paliadin-widget-thinking-dot" aria-hidden="true"></span>
+    <span class="paliadin-widget-thinking-label"></span>
+    <span class="paliadin-widget-thinking-elapsed"></span>
+  `;
+  const label = node.querySelector(".paliadin-widget-thinking-label")!;
+  label.textContent = t("paliadin.thinking");
+  bubble.appendChild(node);
+  updateWidgetThinking(bubble, 0);
+}
+
+function updateWidgetThinking(bubble: HTMLElement, elapsedSeconds: number): void {
+  const node = bubble.querySelector(".paliadin-widget-thinking") as HTMLElement | null;
+  if (!node) return;
+  const elapsed = node.querySelector(".paliadin-widget-thinking-elapsed");
+  if (elapsed) {
+    const s = elapsedSeconds < 0 ? 0 : Math.round(elapsedSeconds);
+    elapsed.textContent = t("paliadin.thinking.seconds").replace("{seconds}", String(s));
+  }
+}
+
+function stopWidgetThinking(bubble: HTMLElement): void {
+  bubble.querySelector(".paliadin-widget-thinking")?.remove();
+}
+
 function cleanupStream(): void {
   activeStream?.close();
   activeStream = null;
@@ -386,6 +475,53 @@ function cleanupStream(): void {
   setSendDisabled(false);
 }
 
+function startWidgetLatePoll(turnId: string, bubble: HTMLElement): void {
+  lateWidgetPolls.get(turnId)?.cancel();
+  const handle = pollForLateResponse({
+    turnId,
+    onLateResponse: (turn) => {
+      lateWidgetPolls.delete(turnId);
+      applyWidgetLateResponse(bubble, turn);
+    },
+    onLost: () => {
+      lateWidgetPolls.delete(turnId);
+      applyWidgetLost(bubble);
+    },
+    onGiveUp: () => {
+      lateWidgetPolls.delete(turnId);
+      applyWidgetLost(bubble);
+    },
+  });
+  lateWidgetPolls.set(turnId, handle);
+}
+
+function applyWidgetLost(bubble: HTMLElement): void {
+  bubble.classList.remove("paliadin-widget-bubble--late-pending");
+  bubble.classList.add("paliadin-widget-bubble--lost");
+  setBubbleText(bubble, t("paliadin.late.lost"));
+}
+
+function applyWidgetLateResponse(bubble: HTMLElement, turn: LateTurn): void {
+  if (!turn.response) return;
+  bubble.classList.remove(
+    "paliadin-widget-bubble--error",
+    "paliadin-widget-bubble--late-pending",
+  );
+  bubble.classList.add("paliadin-widget-bubble--late");
+  setBubbleText(bubble, turn.response);
+  // Append a small "(verspätet)" tag so the late arrival is visible.
+  const tag = document.createElement("span");
+  tag.className = "paliadin-widget-bubble-late-tag";
+  tag.textContent = " · " + t("paliadin.late.marker");
+  bubble.appendChild(tag);
+  history.push({
+    role: "assistant",
+    text: turn.response,
+    ts: new Date().toISOString(),
+  });
+  saveHistory();
+}
+
 function setSendDisabled(disabled: boolean): void {
   const btn = document.getElementById("paliadin-widget-send-btn") as HTMLButtonElement | null;
   if (btn) btn.disabled = disabled;
@@ -404,7 +540,14 @@ function appendBubble(role: "user" | "assistant", text: string): HTMLElement {
   wrap.className = `paliadin-widget-bubble paliadin-widget-bubble--${role}`;
   const body = document.createElement("div");
   body.className = "paliadin-widget-bubble-text";
-  body.textContent = text;
+  // Assistant bubbles get the same markdown + chip pipeline as the
+  // standalone /paliadin page (client/paliadin-render.ts). User bubbles
+  // stay plain text — no need to interpret the user's typed markup.
+  if (role === "assistant") {
+    body.innerHTML = renderResponseHTML(text);
+  } else {
+    body.textContent = text;
+  }
   wrap.appendChild(body);
   messages?.appendChild(wrap);
   if (messages) messages.scrollTop = messages.scrollHeight;
@@ -413,7 +556,14 @@ function appendBubble(role: "user" | "assistant", text: string): HTMLElement {
 
 function setBubbleText(bubble: HTMLElement, text: string): void {
   const body = bubble.querySelector(".paliadin-widget-bubble-text");
-  if (body) body.textContent = text;
+  if (body) {
+    const isAssistant = bubble.classList.contains("paliadin-widget-bubble--assistant");
+    if (isAssistant) {
+      (body as HTMLElement).innerHTML = renderResponseHTML(text);
+    } else {
+      body.textContent = text;
+    }
+  }
   const messages = document.getElementById("paliadin-widget-messages");
   if (messages) messages.scrollTop = messages.scrollHeight;
 }
@@ -424,6 +574,67 @@ function rehydrateHistory(): void {
   history.forEach((h) => appendBubble(h.role, h.text));
 }
 
+// PaliadinTurnRow mirrors the JSON shape /api/paliadin/history returns
+// (services.PaliadinTurn). Fields we don't render yet (used_tools etc.)
+// are typed as unknown to keep the contract loose.
+interface PaliadinTurnRow {
+  turn_id: string;
+  session_id: string;
+  started_at: string;
+  user_message: string;
+  response?: string | null;
+  error_code?: string | null;
+}
+
+// Hydrate from the DB on every mount. Crash-resistant: a typed turn
+// always lands in paliad.paliadin_turns, so even if the user closes
+// the tab mid-flight or the device dies, the next mount picks it up.
+//
+// Reconciliation: DB > localStorage. If the DB returns rows, we trust
+// them entirely and overwrite the cache. If the DB call fails or
+// returns empty, we keep whatever's in localStorage (offline cushion).
+async function hydrateFromServer(): Promise<void> {
+  let rows: PaliadinTurnRow[] = [];
+  try {
+    const r = await fetch(
+      "/api/paliadin/history?session=" + encodeURIComponent(sessionId) + "&limit=50",
+      { credentials: "same-origin" },
+    );
+    if (!r.ok) return;
+    const body = (await r.json()) as PaliadinTurnRow[] | null;
+    rows = Array.isArray(body) ? body : [];
+  } catch {
+    return;
+  }
+  if (!rows.length) return;
+
+  // Project DB rows into the {role, text, ts} shape the cache + render
+  // path expect. Each turn becomes two entries (user prompt then
+  // assistant response). Skip turns with no response (in-flight, or
+  // errored without a recovery) so the bubble doesn't show
+  // half-rendered placeholders on reload.
+  const reconstructed: HistoryEntry[] = [];
+  for (const row of rows) {
+    reconstructed.push({ role: "user", text: row.user_message, ts: row.started_at });
+    if (typeof row.response === "string" && row.response.length > 0) {
+      reconstructed.push({ role: "assistant", text: row.response, ts: row.started_at });
+    }
+  }
+  history = reconstructed;
+  saveHistory();
+
+  // Re-render: clear the message list + replay the canonical history.
+  const messages = document.getElementById("paliadin-widget-messages");
+  const empty = document.getElementById("paliadin-widget-empty");
+  if (messages) {
+    // Strip every prior bubble but keep the empty-state placeholder so
+    // it can be hidden by hideEmpty() if we end up rendering anything.
+    messages.querySelectorAll(".paliadin-widget-bubble").forEach((n) => n.remove());
+    if (empty) empty.style.display = "none";
+    history.forEach((h) => appendBubble(h.role, h.text));
+  }
+}
+
 async function resetSession(): Promise<void> {
   if (!confirm(t("paliadin.widget.reset.confirm"))) return;
   history = [];

frontend/src/client/paliadin.ts

@@ -1,16 +1,27 @@
 import { initI18n, getLang, t } from "./i18n";
 import { initSidebar } from "./sidebar";
+import { renderResponseHTML } from "./paliadin-render";
+import { pollForLateResponse, type LateTurn, type LatePollHandle } from "./paliadin-late-poll";
 
-// Paliadin chat panel client (t-paliad-146 PoC).
+// Paliadin chat panel client (t-paliad-146 PoC, streaming upgrade
+// t-paliad-235).
 //
-// State machine: empty → typing → sending → streaming → done.
+// State machine: empty → typing → sending → thinking → streaming → done.
 // History lives in localStorage under "paliadin:history:<sessionId>"
 // — design §0.5.4 session-only persistence.
 //
 // SSE consumer subscribes to `event: meta`, `event: content`,
-// `event: end`, `event: error`, `event: ping`. Backend currently
-// emits one `content` blob per turn (real chunked streaming is
-// production-v1; PoC simulates with a typewriter effect).
+// `event: thinking`, `event: end`, `event: error`, `event: ping`.
+//
+// `content` events from the aichat backend arrive as incremental
+// `{delta: "..."}` chunks; the bubble accumulates them in real time —
+// no typewriter simulation needed. Legacy backends still emit a single
+// `{text: "..."}` payload and we fall back to the typewriter for that
+// shape.
+//
+// `thinking` events fire while the upstream is alive but hasn't
+// produced content yet (or stalled mid-stream); the bubble renders a
+// pulse + counter so the user can SEE the chat is still working.
 
 interface HistoryEntry {
   role: "user" | "assistant";
@@ -32,6 +43,10 @@ let sessionId: string;
 let history: HistoryEntry[] = [];
 let currentEventSource: EventSource | null = null;
 let currentTurnId: string | null = null;
+// Late-response polls keyed by turn_id. Each entry runs until the
+// response arrives or the 10-min cap expires. Stays alive across
+// turns — m can keep chatting while we wait for the slow one.
+const latePolls = new Map<string, LatePollHandle>();
 
 document.addEventListener("DOMContentLoaded", () => {
   initI18n();
@@ -41,6 +56,10 @@ document.addEventListener("DOMContentLoaded", () => {
   wireStarters();
   wireReset();
   renderHistory();
+  // Pull the canonical conversation from the DB so a turn typed in the
+  // inline drawer (which shares this session id) shows up here on
+  // mount. DB > localStorage when both have data.
+  void hydrateFromServer();
 });
 
 function bootSession(): void {
@@ -157,25 +176,53 @@ async function sendTurn(text: string): Promise<void> {
   const es = new EventSource(turnRes.sse_url);
   currentEventSource = es;
 
+  // Show the thinking pulse immediately — the placeholder text already
+  // says "denkt nach", but the visible pulse + counter is the live
+  // proof-of-life signal m needs to trust that the chat is working.
+  startThinkingIndicator(placeholder);
+  // Reset the streamed accumulator for this turn.
+  placeholder.dataset.fullText = "";
+
   es.addEventListener("meta", () => {
     // Could surface a "thinking" indicator; placeholder text already does.
   });
 
+  es.addEventListener("thinking", (ev) => {
+    let elapsed = 0;
+    try {
+      const data = JSON.parse((ev as MessageEvent).data || "{}");
+      if (typeof data.elapsed_seconds === "number") {
+        elapsed = data.elapsed_seconds;
+      }
+    } catch {
+      /* ignore */
+    }
+    updateThinkingIndicator(placeholder, elapsed);
+  });
+
   es.addEventListener("content", (ev) => {
     const data = JSON.parse((ev as MessageEvent).data);
+    const delta = typeof data.delta === "string" ? data.delta : "";
+    if (delta) {
+      // Aichat streaming path — accumulate the delta into the bubble.
+      stopThinkingIndicator(placeholder);
+      const current = placeholder.dataset.fullText ?? "";
+      const next = current + delta;
+      placeholder.dataset.fullText = next;
+      writeStreamedText(placeholder, next);
+      return;
+    }
+    // Legacy one-shot path — full body in `text`.
     const text = String(data.text || "");
-    // Cache the full text on the bubble so finishBubble can render the
-    // complete response even when the typewriter is mid-flight when end
-    // arrives. textContent reflects only what's been typed so far and
-    // would otherwise truncate the rendered Markdown (m, 2026-05-08 —
-    // saw "## Proje" instead of the full 1408-byte body).
     placeholder.dataset.fullText = text;
+    stopThinkingIndicator(placeholder);
     typewriter(placeholder, text);
   });
 
   es.addEventListener("end", (ev) => {
     const data = JSON.parse((ev as MessageEvent).data);
     placeholder.dataset.streaming = "false";
+    stopThinkingIndicator(placeholder);
     finishBubble(placeholder, data);
     history.push({
       role: "assistant",
@@ -199,10 +246,21 @@ async function sendTurn(text: string): Promise<void> {
   });
 
   es.addEventListener("error", (ev) => {
+    const errText = friendlyErrorMessage((ev as MessageEvent).data);
+    stopThinkingIndicator(placeholder);
+    // Honest copy: we don't claim "nachgereicht" because the recovery
+    // path may report "lost". Frame it as "checking" while we ask the
+    // backend whether the turn actually completed upstream.
     placeholder.querySelector(".paliadin-bubble-text")!.textContent =
-      friendlyErrorMessage((ev as MessageEvent).data);
+      errText + " " + t("paliadin.late.checking");
     placeholder.classList.add("paliadin-bubble--error");
+    placeholder.classList.add("paliadin-bubble--late-pending");
     placeholder.dataset.streaming = "false";
+    placeholder.dataset.errorText = errText;
+    if (currentTurnId) {
+      placeholder.dataset.turnId = currentTurnId;
+      startLatePoll(currentTurnId, placeholder);
+    }
     cleanupTurn();
   });
 
@@ -211,6 +269,65 @@ async function sendTurn(text: string): Promise<void> {
   });
 }
 
+// =============================================================================
+// thinking indicator — proof-of-life pulse + elapsed counter
+// =============================================================================
+
+function startThinkingIndicator(bubble: HTMLElement): void {
+  // Append a thinking node next to the bubble text (sibling, so the
+  // typewriter rewriting text content doesn't clobber it). The node
+  // shows a pulse dot + the elapsed counter.
+  let node = bubble.querySelector(".paliadin-thinking") as HTMLElement | null;
+  if (node) return; // already running
+  // Clear the static placeholder text — the live pulse + counter is
+  // now the canonical "denkt nach" signal. Leaving the text in place
+  // would render the same phrase twice.
+  const textNode = bubble.querySelector(".paliadin-bubble-text");
+  if (textNode) textNode.textContent = "";
+  node = document.createElement("div");
+  node.className = "paliadin-thinking";
+  node.innerHTML = `
+    <span class="paliadin-thinking-dot" aria-hidden="true"></span>
+    <span class="paliadin-thinking-label"></span>
+    <span class="paliadin-thinking-elapsed"></span>
+  `;
+  const label = node.querySelector(".paliadin-thinking-label")!;
+  label.textContent = t("paliadin.thinking");
+  bubble.appendChild(node);
+  // Initial 0s — replaced as soon as a thinking event arrives or our
+  // local ticker fires.
+  updateThinkingIndicator(bubble, 0);
+}
+
+function updateThinkingIndicator(bubble: HTMLElement, elapsedSeconds: number): void {
+  const node = bubble.querySelector(".paliadin-thinking") as HTMLElement | null;
+  if (!node) return;
+  const elapsed = node.querySelector(".paliadin-thinking-elapsed");
+  if (elapsed) {
+    elapsed.textContent = formatThinkingSeconds(elapsedSeconds);
+  }
+}
+
+function stopThinkingIndicator(bubble: HTMLElement): void {
+  bubble.querySelector(".paliadin-thinking")?.remove();
+}
+
+function formatThinkingSeconds(s: number): string {
+  if (s < 0) s = 0;
+  return t("paliadin.thinking.seconds").replace("{seconds}", String(Math.round(s)));
+}
+
+// writeStreamedText fills the bubble with raw text as it accumulates.
+// Cheaper than the typewriter — we already have the real cadence from
+// the wire, no need to simulate it.
+function writeStreamedText(bubble: HTMLElement, text: string): void {
+  const node = bubble.querySelector(".paliadin-bubble-text");
+  if (!node) return;
+  node.textContent = text;
+  const stream = document.getElementById("paliadin-stream");
+  if (stream) stream.scrollTop = stream.scrollHeight;
+}
+
 // Server emits SSE error events as JSON `{code, message}`. Map known
 // codes to localised, user-friendly text; fall through to a generic
 // "connection lost" for anything we don't recognise (including raw
@@ -339,167 +456,140 @@ function finishBubble(bubble: HTMLElement, data: any): void {
   }
 }
 
-// Marker → button render. Mirrors §4.4 of the design.
-const CHIP_RE = /\[(?:#([a-z]+)-OPEN:([A-Za-z0-9\-_]+)|chip:([a-z]+):([^\]]+))\]/g;
-const MD_LINK_RE = /\[([^\]\n]+)\]\(((?:https?:\/\/|\/)[^\s)]+)\)/g;
-const BARE_URL_RE = /(^|[^"=>])(https?:\/\/[^\s<>"']+)/g;
 
-function renderResponseHTML(raw: string): string {
-  // First escape any HTML in the raw text (simple textContent → innerHTML
-  // would have been fine but we then need to inject anchors, so the
-  // manual escape is unavoidable).
-  let html = raw
-    .replace(/&/g, "&amp;")
-    .replace(/</g, "&lt;")
-    .replace(/>/g, "&gt;")
-    .replace(/"/g, "&quot;");
-
-  // Stage 1: extract chip markers as placeholder sentinels so subsequent
-  // link-rendering passes don't try to re-parse the chip URLs as bare
-  // URLs and double-anchor them.
-  const chipHTML: string[] = [];
-  html = html.replace(CHIP_RE, (_match, kind, id, chipKind, chipArg) => {
-    let rendered = "";
-    if (kind && id) {
-      const url = chipURL(kind, id);
-      const label = chipLabel(kind);
-      rendered = `<a class="paliadin-chip" href="${url}">${label}</a>`;
-    } else if (chipKind === "nav") {
-      rendered = `<a class="paliadin-chip" href="${chipArg}">öffnen</a>`;
-    } else if (chipKind === "filter") {
-      rendered = `<a class="paliadin-chip" href="/inbox?${chipArg}">Filter anwenden</a>`;
-    }
-    if (!rendered) return "";
-    chipHTML.push(rendered);
-    return `
CHIP${chipHTML.length - 1}
`;
+// startLatePoll registers the recovery-endpoint poller for one errored
+// turn. When the row gains a response we swap the bubble's content +
+// drop the error class + retroactively replace the history entry
+// (which was never written for the failed turn — append now so reload
+// renders the late reply). When the backend confirms the turn is
+// "lost", we swap the bubble to the honest "verloren" copy.
+function startLatePoll(turnId: string, bubble: HTMLElement): void {
+  // Avoid duplicate pollers for the same turn (e.g. SSE error fires
+  // twice in some browsers when the connection drops).
+  latePolls.get(turnId)?.cancel();
+  const handle = pollForLateResponse({
+    turnId,
+    onLateResponse: (turn) => {
+      latePolls.delete(turnId);
+      applyLateResponse(bubble, turn);
+    },
+    onLost: () => {
+      latePolls.delete(turnId);
+      applyLostResponse(bubble);
+    },
+    onGiveUp: () => {
+      latePolls.delete(turnId);
+      applyLostResponse(bubble);
+    },
   });
-
-  // Stage 2: Block-level Markdown — headings (## / ###), unordered lists
-  // (- item), and paragraphs separated by blank lines. Done before the
-  // inline passes so the inline regexes only ever run inside a block.
-  // Chip SOH placeholders are inert text at this point and pass through
-  // untouched.
-  html = renderBlocks(html);
-
-  // Stage 3: Markdown links [text](url). Internal /paths stay same-tab;
-  // external http(s) URLs open in a new tab.
-  html = html.replace(MD_LINK_RE, (_m, text, url) => {
-    const ext = url.startsWith("http");
-    const attrs = ext ? ` target="_blank" rel="noopener noreferrer"` : "";
-    return `<a href="${url}" class="paliadin-link"${attrs}>${text}</a>`;
-  });
-
-  // Stage 4: auto-link bare URLs. The leading-character class on the
-  // regex avoids matching URLs already inside an href attribute (preceded
-  // by `="`) and the prefix capture is preserved verbatim so we don't
-  // drop punctuation.
-  html = html.replace(BARE_URL_RE, (_m, prefix, url) => {
-    return `${prefix}<a href="${url}" class="paliadin-link" target="_blank" rel="noopener noreferrer">${url}</a>`;
-  });
-
-  // Stage 5: inline emphasis. Bold first so the italic regex doesn't
-  // misparse `**bold**` as nested `*italic*`. Both bounded to single
-  // lines via [^*\n] to avoid runaway matches across paragraphs.
-  html = html.replace(/\*\*([^*\n]+)\*\*/g, "<strong>$1</strong>");
-  html = html.replace(/(^|[^*])\*([^*\n]+)\*(?!\*)/g, "$1<em>$2</em>");
-
-  // Stage 4: substitute chip placeholders back. Done last so chip URLs
-  // never go through the link-rendering passes.
-  html = html.replace(/
CHIP(\d+)
/g, (_m, idx) => chipHTML[Number(idx)] || "");
-
-  return html;
+  latePolls.set(turnId, handle);
 }
 
-// renderBlocks parses the escaped html into block-level Markdown:
-// `## H` → <h2>, `### H` → <h3>, `- item` lines → <ul><li>, blank-line
-// separated runs → <p> with intra-paragraph newlines as <br>. Anything
-// not matched falls through verbatim, so the function is a strict
-// superset of the prior behaviour for plain-text responses.
-function renderBlocks(escapedHtml: string): string {
-  const out: string[] = [];
-  let listItems: string[] = [];
-  let paraLines: string[] = [];
-
-  const flushList = () => {
-    if (listItems.length === 0) return;
-    out.push(`<ul class="paliadin-list">${listItems.map((li) => `<li>${li}</li>`).join("")}</ul>`);
-    listItems = [];
-  };
-  const flushPara = () => {
-    if (paraLines.length === 0) return;
-    out.push(`<p>${paraLines.join("<br>")}</p>`);
-    paraLines = [];
-  };
-
-  for (const rawLine of escapedHtml.split("\n")) {
-    const line = rawLine.trim();
-    if (line === "") {
-      flushList();
-      flushPara();
-      continue;
-    }
-    let m: RegExpMatchArray | null;
-    if ((m = line.match(/^###\s+(.+)$/))) {
-      flushList();
-      flushPara();
-      out.push(`<h3>${m[1]}</h3>`);
-    } else if ((m = line.match(/^##\s+(.+)$/))) {
-      flushList();
-      flushPara();
-      out.push(`<h2>${m[1]}</h2>`);
-    } else if ((m = line.match(/^[-*]\s+(.+)$/))) {
-      flushPara();
-      listItems.push(m[1]);
-    } else if (line.match(/^---+$/)) {
-      flushList();
-      flushPara();
-      out.push(`<hr>`);
-    } else {
-      flushList();
-      paraLines.push(line);
-    }
-  }
-  flushList();
-  flushPara();
-  return out.join("");
+function applyLostResponse(bubble: HTMLElement): void {
+  bubble.classList.remove("paliadin-bubble--late-pending");
+  bubble.classList.add("paliadin-bubble--lost");
+  const node = bubble.querySelector(".paliadin-bubble-text");
+  if (node) node.textContent = t("paliadin.late.lost");
 }
 
-function chipURL(kind: string, id: string): string {
-  switch (kind) {
-    case "deadline":
-    case "frist":
-      return "/deadlines/" + id;
-    case "projekt":
-    case "project":
-      return "/projects/" + id;
-    case "termin":
-    case "appointment":
-      return "/appointments/" + id;
-    default:
-      return "#";
-  }
-}
-
-function chipLabel(kind: string): string {
-  switch (kind) {
-    case "deadline":
-    case "frist":
-      return "Frist öffnen";
-    case "projekt":
-    case "project":
-      return "Akte ansehen";
-    case "termin":
-    case "appointment":
-      return "Termin öffnen";
-    default:
-      return "öffnen";
+function applyLateResponse(bubble: HTMLElement, turn: LateTurn): void {
+  if (!turn.response) return;
+  bubble.classList.remove("paliadin-bubble--error", "paliadin-bubble--late-pending");
+  bubble.classList.add("paliadin-bubble--late");
+  bubble.dataset.fullText = turn.response;
+  bubble.dataset.streaming = "false";
+  finishBubble(bubble, {
+    used_tools: turn.used_tools,
+    rows_seen: turn.rows_seen,
+    classifier_tag: turn.classifier_tag,
+    duration_ms: turn.duration_ms,
+    chip_count: turn.chip_count,
+  });
+  // Inject a small "(verspätet)" marker into the meta row so it's
+  // visible at a glance that this bubble was patched after the fact.
+  const metaEl = bubble.querySelector(".paliadin-bubble-meta") as HTMLElement | null;
+  if (metaEl) {
+    const lateTag = document.createElement("span");
+    lateTag.className = "paliadin-bubble-late-tag";
+    lateTag.textContent = " · " + t("paliadin.late.marker");
+    metaEl.appendChild(lateTag);
+    metaEl.style.display = "";
   }
+  // Persist so a reload shows the late response in place of the error.
+  history.push({
+    role: "assistant",
+    text: turn.response,
+    meta: {
+      used_tools: turn.used_tools,
+      rows_seen: turn.rows_seen,
+      classifier_tag: turn.classifier_tag ?? undefined,
+      duration_ms: turn.duration_ms ?? undefined,
+      chip_count: turn.chip_count,
+    },
+    ts: new Date().toISOString(),
+  });
+  saveHistory();
 }
 
 function saveHistory(): void {
   localStorage.setItem(HISTORY_PREFIX + sessionId, JSON.stringify(history));
 }
 
+// PaliadinTurnRow mirrors the JSON returned by /api/paliadin/history
+// (services.PaliadinTurn). Fields we don't render yet are skipped.
+interface PaliadinTurnRow {
+  turn_id: string;
+  session_id: string;
+  started_at: string;
+  user_message: string;
+  response?: string | null;
+  used_tools?: string[] | null;
+  rows_seen?: number[] | null;
+  classifier_tag?: string | null;
+  duration_ms?: number | null;
+  chip_count?: number | null;
+}
+
+// Hydrate from /api/paliadin/history, replacing the localStorage cache
+// when the DB returns rows. Fail-quiet on network / auth errors —
+// localStorage is a perfectly good offline fallback.
+async function hydrateFromServer(): Promise<void> {
+  let rows: PaliadinTurnRow[] = [];
+  try {
+    const r = await fetch(
+      "/api/paliadin/history?session=" + encodeURIComponent(sessionId) + "&limit=50",
+      { credentials: "same-origin" },
+    );
+    if (!r.ok) return;
+    const body = (await r.json()) as PaliadinTurnRow[] | null;
+    rows = Array.isArray(body) ? body : [];
+  } catch {
+    return;
+  }
+  if (!rows.length) return;
+  const reconstructed: HistoryEntry[] = [];
+  for (const row of rows) {
+    reconstructed.push({ role: "user", text: row.user_message, ts: row.started_at });
+    if (typeof row.response === "string" && row.response.length > 0) {
+      reconstructed.push({
+        role: "assistant",
+        text: row.response,
+        ts: row.started_at,
+        meta: {
+          used_tools: row.used_tools ?? undefined,
+          rows_seen: row.rows_seen ?? undefined,
+          classifier_tag: row.classifier_tag ?? undefined,
+          duration_ms: row.duration_ms ?? undefined,
+          chip_count: row.chip_count ?? undefined,
+        },
+      });
+    }
+  }
+  history = reconstructed;
+  saveHistory();
+  renderHistory();
+}
+
 function renderHistory(): void {
   const stream = document.getElementById("paliadin-stream");
   if (!stream) return;

frontend/src/client/project-form.ts

@@ -1,13 +1,47 @@
-import { t, tDyn } from "./i18n";
+import { t, tDyn, getLang } from "./i18n";
 
 // Shared logic for the Project form rendered by ProjectFormFields.tsx.
 // Used by /projects/new and the edit modal on /projects/{id}.
 
+export interface ProceedingTypeRow {
+  id: number;
+  code: string;
+  name: string;
+  name_en: string;
+  jurisdiction?: string;
+  is_active: boolean;
+}
+
+let proceedingTypesCache: ProceedingTypeRow[] | null = null;
+
+// loadProceedingTypes fetches active fristenrechner-category proceeding
+// types — the only set a project may bind to (mig 087/088 + service
+// validation guard `validateProceedingTypeCategory`). Cached at module
+// level so the page only pays for one fetch even when both the new-
+// project page and the edit modal exercise the picker.
+export async function loadProceedingTypes(): Promise<ProceedingTypeRow[]> {
+  if (proceedingTypesCache) return proceedingTypesCache;
+  try {
+    const resp = await fetch("/api/proceeding-types-db?category=fristenrechner");
+    if (!resp.ok) return [];
+    const rows = ((await resp.json()) ?? []) as ProceedingTypeRow[];
+    proceedingTypesCache = rows.filter((r) => r.is_active);
+    return proceedingTypesCache;
+  } catch {
+    return [];
+  }
+}
+
 export interface ProjectMini {
   id: string;
   title: string;
   type: string;
   reference?: string | null;
+  // t-paliad-222 / m/paliad#50: auto-derived dotted project code from
+  // the ancestor tree. Populated by the service projection on every
+  // /api/projects response, so the picker can show the code without an
+  // extra fetch.
+  code?: string;
 }
 
 export interface ProjectFormState {
@@ -29,6 +63,7 @@ export interface ProjectFormState {
   grantDate: string;
   court: string;
   caseNumber: string;
+  ourSide: string;
 }
 
 let parentCandidates: ProjectMini[] = [];
@@ -47,9 +82,11 @@ function tryGet(id: string): HTMLElement | null {
 export function showFieldsForType(typeSel: string) {
   const parentWrap = tryGet("projekt-parent-wrap") as HTMLDivElement | null;
   const clientFields = tryGet("fields-client") as HTMLDivElement | null;
+  const litigationFields = tryGet("fields-litigation") as HTMLDivElement | null;
   const patentFields = tryGet("fields-patent") as HTMLDivElement | null;
   const caseFields = tryGet("fields-case") as HTMLDivElement | null;
   if (clientFields) clientFields.style.display = typeSel === "client" ? "block" : "none";
+  if (litigationFields) litigationFields.style.display = typeSel === "litigation" ? "block" : "none";
   if (patentFields) patentFields.style.display = typeSel === "patent" ? "block" : "none";
   if (caseFields) caseFields.style.display = typeSel === "case" ? "block" : "none";
   if (parentWrap) parentWrap.style.display = typeSel === "client" ? "none" : "block";
@@ -87,18 +124,28 @@ export function initParentPicker() {
     }
     const matches = parentCandidates
       .filter((p) => {
-        const hay = (p.title + " " + (p.reference || "")).toLowerCase();
+        // Search across title + manual reference + auto-derived code
+        // so the user can type "EXMPL" or "INF.CFI" and find the row.
+        const hay = (p.title + " " + (p.reference || "") + " " + (p.code || "")).toLowerCase();
         return hay.includes(q);
       })
       .slice(0, 8);
     sugs.innerHTML = matches
-      .map(
-        (p) =>
-          `<div class="collab-suggestion" data-id="${esc(p.id)}" data-title="${esc(p.title)}">
+      .map((p) => {
+        // Render the auto-derived code (if any, and distinct from
+        // reference) as a small mono badge on the right so the user
+        // can disambiguate two same-titled projects by their tree
+        // position. Single template literal kept readable inline.
+        const code = p.code && p.code !== (p.reference || "") ? p.code : "";
+        const codeBadge = code
+          ? `<span class="entity-ref entity-ref-code">${esc(code)}</span>`
+          : "";
+        return `<div class="collab-suggestion" data-id="${esc(p.id)}" data-title="${esc(p.title)}">
             <strong>${esc(p.title)}</strong>
             <span class="entity-type-chip entity-type-${esc(p.type)}">${esc(tDyn("projects.type." + p.type) || p.type)}</span>
-          </div>`,
-      )
+            ${codeBadge}
+          </div>`;
+      })
       .join("");
     sugs.querySelectorAll<HTMLDivElement>(".collab-suggestion").forEach((el) => {
       el.addEventListener("click", () => {
@@ -118,6 +165,34 @@ export function wireTypeChange() {
   typeSel.addEventListener("change", () => showFieldsForType(typeSel.value));
 }
 
+// populateProceedingTypeSelect fills #project-proceeding-type-id with one
+// option per fristenrechner-category proceeding type, ordered by `code`
+// (so the user scans `de.*`, `dpma.*`, `epa.*`, `upc.*` in stable
+// jurisdiction-grouped order). The first option is the empty "unset"
+// choice already in the markup; this helper only appends rows below it.
+// Idempotent — clearing rows[1..] on re-call so a re-open of the edit
+// modal doesn't double-render the list.
+export async function populateProceedingTypeSelect(): Promise<void> {
+  const sel = tryGet("project-proceeding-type-id") as HTMLSelectElement | null;
+  if (!sel) return;
+  const rows = await loadProceedingTypes();
+  rows.sort((a, b) => a.code.localeCompare(b.code));
+  while (sel.options.length > 1) sel.remove(1);
+  const isEN = getLang() === "en";
+  for (const row of rows) {
+    const opt = document.createElement("option");
+    opt.value = String(row.id);
+    const label = isEN && row.name_en ? row.name_en : row.name;
+    opt.textContent = `${label} (${row.code})`;
+    sel.appendChild(opt);
+  }
+  // Honour a pre-selection value that prefillForm wrote before the
+  // option set existed. dataset.preselect is set to "" or the saved id;
+  // restoring it here keeps the edit modal's saved value visible.
+  const preselect = sel.dataset.preselect;
+  if (preselect !== undefined) sel.value = preselect;
+}
+
 // readPayload collects the form's current values into a CreateProjectInput /
 // UpdateProjectInput compatible JSON payload. Returns null + sets msg when
 // title is missing.
@@ -173,9 +248,48 @@ export function readPayload(
     const gd = ($("project-grant-date") as HTMLInputElement).value;
     if (gd) payload.grant_date = gd + "T00:00:00Z";
   }
+  if (type === "litigation") {
+    // opponent_code is the litigation-only short slug used as the
+    // middle segment when BuildProjectCode auto-derives a project
+    // code from the ancestor tree (t-paliad-222 / m/paliad#50).
+    // Uppercased on submit so the user can type lowercase comfortably
+    // — the DB CHECK enforces the [A-Z0-9-]{1,16} pattern.
+    const ocEl = tryGet("project-opponent-code") as HTMLInputElement | null;
+    if (ocEl) {
+      const v = ocEl.value.trim().toUpperCase();
+      if (v) payload.opponent_code = v;
+      else if (!opts.omitEmpty) payload.opponent_code = "";
+    }
+  }
   if (type === "case") {
     stringField("project-court", "court");
     stringField("project-case-number", "case_number");
+
+    // Proceeding type — optional picker. Per t-paliad-232, an empty
+    // pick simply omits the key from the payload (create: column stays
+    // NULL; edit: server's `omitempty` skips the SET). Clearing a
+    // previously-set value isn't supported in this slice; once bound,
+    // a project's proceeding type can be swapped but not unset from
+    // the form. The server's validateProceedingTypeCategory backs the
+    // selected id with a category check.
+    const ptSel = tryGet("project-proceeding-type-id") as HTMLSelectElement | null;
+    if (ptSel) {
+      const v = ptSel.value.trim();
+      if (v) {
+        const n = parseInt(v, 10);
+        if (!isNaN(n)) payload.proceeding_type_id = n;
+      }
+    }
+
+    // Client Role (DB column: our_side) — case-only after t-paliad-222.
+    // The select uses "" for the unset option; the service maps empty
+    // string to NULL via nullableOurSide.
+    const osSel = tryGet("project-our-side") as HTMLSelectElement | null;
+    if (osSel) {
+      const v = osSel.value.trim();
+      if (v) payload.our_side = v;
+      else if (!opts.omitEmpty) payload.our_side = "";
+    }
   }
 
   const desc = ($("project-description") as HTMLTextAreaElement).value.trim();
@@ -214,6 +328,20 @@ export function prefillForm(p: Record<string, unknown>) {
   get("project-grant-date").value = isoToDate(p.grant_date as string | null | undefined);
   get("project-court").value = String(p.court ?? "");
   get("project-case-number").value = String(p.case_number ?? "");
+  const osSel = tryGet("project-our-side") as HTMLSelectElement | null;
+  if (osSel) osSel.value = String(p.our_side ?? "");
+  const ocEl = tryGet("project-opponent-code") as HTMLInputElement | null;
+  if (ocEl) ocEl.value = String(p.opponent_code ?? "");
+  // Proceeding-type picker — populated lazily by populateProceedingTypeSelect.
+  // Set the value here even if the options haven't arrived yet; the post-
+  // populate render runs ApplyProceedingTypeValue to re-select the saved id
+  // once the option exists.
+  const ptSel = tryGet("project-proceeding-type-id") as HTMLSelectElement | null;
+  if (ptSel) {
+    const v = p.proceeding_type_id == null ? "" : String(p.proceeding_type_id);
+    ptSel.dataset.preselect = v;
+    ptSel.value = v;
+  }
   getTA("project-description").value = String(p.description ?? "");
   getSel("project-status").value = String(p.status ?? "active");
 }

frontend/src/client/projects-chart.ts

@@ -0,0 +1,489 @@
+import { initI18n, t } from "./i18n";
+import { initSidebar } from "./sidebar";
+import {
+  ALL_DENSITIES,
+  ALL_PALETTES,
+  ALL_RANGE_PRESETS,
+  mount,
+  type ChartHandle,
+  type Density,
+  type Palette,
+  type RangePreset,
+} from "./views/shape-timeline-chart";
+import {
+  exportCSV,
+  exportJSON,
+  exportPNG,
+  exportPrint,
+  exportSVG,
+  type ExportContext,
+} from "./views/chart-export";
+
+// t-paliad-177 Slice 1 — boot client for the standalone Project Timeline
+// / Chart page. Reads the project id from the URL path, loads the
+// project metadata (for title + breadcrumb), mounts the SVG renderer
+// inside #projects-chart-host. Slice 1 keeps the controls inert; Slice 3
+// wires density / palette / zoom against this same surface.
+//
+// Design ref: docs/design-project-chart-2026-05-09.md §8.2 + §12.
+
+interface Project {
+  id: string;
+  title: string;
+  reference?: string;
+  client_matter?: string;
+  type?: string;
+}
+
+const PROJECT_ID_RE = /^\/projects\/([0-9a-fA-F-]{36})\/chart\/?$/;
+
+function projectIdFromPath(): string | null {
+  const match = PROJECT_ID_RE.exec(window.location.pathname);
+  return match ? match[1] : null;
+}
+
+const PALETTE_SET: ReadonlySet<string> = new Set(ALL_PALETTES);
+
+/** Reads ?palette=... from the URL; returns the default when missing /
+ *  unknown so a hostile or stale URL can't break the chart. */
+function paletteFromURL(): Palette {
+  const raw = new URLSearchParams(window.location.search).get("palette");
+  if (raw && PALETTE_SET.has(raw)) return raw as Palette;
+  return "default";
+}
+
+/** Mirrors paletteFromURL but for writing — pushes a new history entry
+ *  so the URL stays bookmarkable / shareable per design §8.2. */
+function writePaletteToURL(palette: Palette): void {
+  writeParamToURL("palette", palette, "default");
+}
+
+const DENSITY_SET: ReadonlySet<string> = new Set(ALL_DENSITIES);
+
+function densityFromURL(): Density {
+  const raw = new URLSearchParams(window.location.search).get("density");
+  if (raw && DENSITY_SET.has(raw)) return raw as Density;
+  return "standard";
+}
+
+function writeDensityToURL(density: Density): void {
+  writeParamToURL("density", density, "standard");
+}
+
+const RANGE_SET: ReadonlySet<string> = new Set(ALL_RANGE_PRESETS);
+
+interface RangeState {
+  preset: RangePreset;
+  from?: string;
+  to?: string;
+}
+
+const ISO_DATE_RE = /^\d{4}-\d{2}-\d{2}$/;
+
+function rangeFromURL(): RangeState {
+  const params = new URLSearchParams(window.location.search);
+  const raw = params.get("range");
+  const preset: RangePreset = raw && RANGE_SET.has(raw) ? (raw as RangePreset) : "1y";
+  if (preset === "custom") {
+    const from = params.get("from") || "";
+    const to = params.get("to") || "";
+    return {
+      preset,
+      from: ISO_DATE_RE.test(from) ? from : undefined,
+      to: ISO_DATE_RE.test(to) ? to : undefined,
+    };
+  }
+  return { preset };
+}
+
+function writeRangeToURL(state: RangeState): void {
+  const params = new URLSearchParams(window.location.search);
+  if (state.preset === "1y") {
+    params.delete("range");
+  } else {
+    params.set("range", state.preset);
+  }
+  if (state.preset === "custom") {
+    if (state.from) params.set("from", state.from);
+    else params.delete("from");
+    if (state.to) params.set("to", state.to);
+    else params.delete("to");
+  } else {
+    params.delete("from");
+    params.delete("to");
+  }
+  const qs = params.toString();
+  const next = window.location.pathname + (qs ? "?" + qs : "");
+  window.history.replaceState(null, "", next);
+}
+
+/** Read ?lanes=id1,id2 from the URL. Empty / missing → null (show all).
+ *  Defence: ids that look hostile (commas embedded, oversized) are dropped
+ *  on render via the renderer's allow-set intersection. */
+function lanesFromURL(): string[] | null {
+  const raw = new URLSearchParams(window.location.search).get("lanes");
+  if (!raw) return null;
+  const ids = raw.split(",").map((s) => s.trim()).filter((s) => s.length > 0 && s.length < 200);
+  return ids.length === 0 ? null : ids;
+}
+
+function writeLanesToURL(lanes: string[] | null): void {
+  const params = new URLSearchParams(window.location.search);
+  if (!lanes || lanes.length === 0) {
+    params.delete("lanes");
+  } else {
+    params.set("lanes", lanes.join(","));
+  }
+  const qs = params.toString();
+  const next = window.location.pathname + (qs ? "?" + qs : "");
+  window.history.replaceState(null, "", next);
+}
+
+/** Shared URL writer — omits the param when it equals its default, so the
+ *  canonical URL stays short and dedupable. */
+function writeParamToURL(name: string, value: string, defaultValue: string): void {
+  const params = new URLSearchParams(window.location.search);
+  if (value === defaultValue) {
+    params.delete(name);
+  } else {
+    params.set(name, value);
+  }
+  const qs = params.toString();
+  const next = window.location.pathname + (qs ? "?" + qs : "");
+  window.history.replaceState(null, "", next);
+}
+
+async function loadProject(id: string): Promise<Project | null> {
+  try {
+    const resp = await fetch(`/api/projects/${encodeURIComponent(id)}`);
+    if (!resp.ok) return null;
+    return (await resp.json()) as Project;
+  } catch {
+    return null;
+  }
+}
+
+function formatMeta(p: Project): string {
+  const parts: string[] = [];
+  if (p.reference) parts.push(p.reference);
+  if (p.client_matter) parts.push(p.client_matter);
+  return parts.join(" • ");
+}
+
+async function boot(): Promise<void> {
+  initI18n();
+  initSidebar();
+
+  const loadingEl = document.getElementById("projects-chart-loading");
+  const notfoundEl = document.getElementById("projects-chart-notfound");
+  const bodyEl = document.getElementById("projects-chart-body");
+  const titleEl = document.getElementById("projects-chart-title");
+  const metaEl = document.getElementById("projects-chart-meta");
+  const backLink = document.getElementById("projects-chart-back-link") as HTMLAnchorElement | null;
+  const host = document.getElementById("projects-chart-host");
+  const undatedHint = document.getElementById("projects-chart-undated");
+
+  const id = projectIdFromPath();
+  if (!id || !host || !bodyEl || !loadingEl || !notfoundEl) {
+    if (loadingEl) loadingEl.style.display = "none";
+    if (notfoundEl) notfoundEl.style.display = "block";
+    return;
+  }
+
+  const project = await loadProject(id);
+  if (!project) {
+    loadingEl.style.display = "none";
+    notfoundEl.style.display = "block";
+    return;
+  }
+
+  // Wire back-link to the Verlauf tab specifically — projects-detail.ts
+  // reads the /history sub-path on init and switches to that tab. Going
+  // back to the bare /projects/{id} also lands on Verlauf today, but the
+  // /history form is explicit + survives a future default-tab change.
+  if (backLink) backLink.href = `/projects/${encodeURIComponent(id)}/history`;
+
+  if (titleEl) titleEl.textContent = project.title || t("projects.chart.title");
+  if (metaEl) metaEl.textContent = formatMeta(project);
+
+  loadingEl.style.display = "none";
+  bodyEl.style.display = "";
+
+  const initialPalette = paletteFromURL();
+  const initialDensity = densityFromURL();
+  const initialRange = rangeFromURL();
+  const initialLanes = lanesFromURL();
+  let handle: ChartHandle | null = null;
+  // Module-scope mirrors so the chip click handlers (rendered later)
+  // can reach the live state without threading it through callbacks.
+  moduleVisibleLanes = initialLanes;
+  try {
+    handle = mount(host, {
+      projectId: id,
+      palette: initialPalette,
+      density: initialDensity,
+      rangePreset: initialRange.preset,
+      rangeFrom: initialRange.from,
+      rangeTo: initialRange.to,
+      visibleLanes: initialLanes,
+      onDataLoaded: ({ lanes }) => {
+        renderLaneFilter(lanes);
+      },
+    });
+  } catch (err) {
+    console.error("chart mount failed", err);
+    host.textContent = t("projects.chart.error.mount");
+    return;
+  }
+  moduleHandleRef = handle;
+
+  // Wire the palette picker. Reflect the URL-decoded initial value, then
+  // re-write the URL + flip the data-palette attribute on every change.
+  const paletteSel = document.getElementById("projects-chart-palette") as HTMLSelectElement | null;
+  if (paletteSel) {
+    paletteSel.value = initialPalette;
+    paletteSel.addEventListener("change", () => {
+      const next = paletteSel.value;
+      if (!PALETTE_SET.has(next)) return;
+      const p = next as Palette;
+      handle!.setPalette(p);
+      writePaletteToURL(p);
+    });
+  }
+
+  // Density picker — same URL-state pattern. Density triggers a repaint
+  // (lane height + mark radius change), palette is a pure CSS swap.
+  const densitySel = document.getElementById("projects-chart-density") as HTMLSelectElement | null;
+  if (densitySel) {
+    densitySel.value = initialDensity;
+    densitySel.addEventListener("change", () => {
+      const next = densitySel.value;
+      if (!DENSITY_SET.has(next)) return;
+      const d = next as Density;
+      handle!.setDensity(d);
+      writeDensityToURL(d);
+    });
+  }
+
+  // Range chips — 4-option select plus a custom date-pair that shows
+  // only when preset === "custom". Per design §8.2 + faraday-Q8 default.
+  const rangeSel = document.getElementById("projects-chart-range") as HTMLSelectElement | null;
+  const rangeCustomWrap = document.getElementById("projects-chart-range-custom");
+  const rangeFromInput = document.getElementById("projects-chart-range-from") as HTMLInputElement | null;
+  const rangeToInput = document.getElementById("projects-chart-range-to") as HTMLInputElement | null;
+  if (rangeSel && rangeCustomWrap && rangeFromInput && rangeToInput) {
+    rangeSel.value = initialRange.preset;
+    if (initialRange.preset === "custom") {
+      rangeCustomWrap.style.display = "";
+      if (initialRange.from) rangeFromInput.value = initialRange.from;
+      if (initialRange.to) rangeToInput.value = initialRange.to;
+    }
+    const applyRange = () => {
+      const preset = rangeSel.value;
+      if (!RANGE_SET.has(preset)) return;
+      const p = preset as RangePreset;
+      rangeCustomWrap.style.display = p === "custom" ? "" : "none";
+      const from = rangeFromInput.value || undefined;
+      const to = rangeToInput.value || undefined;
+      handle!.setRange(p, from, to);
+      writeRangeToURL({ preset: p, from, to });
+    };
+    rangeSel.addEventListener("change", applyRange);
+    rangeFromInput.addEventListener("change", applyRange);
+    rangeToInput.addEventListener("change", applyRange);
+  }
+
+  // Export menu. Each button maps to one chart-export function; the
+  // handle exposes the live SVG + last-fetched data needed to compose
+  // an ExportContext. Errors land in the host's message area so the
+  // user gets feedback instead of a silent failure.
+  function ctxNow(): ExportContext {
+    const data = handle!.getData();
+    return {
+      projectId: id,
+      projectTitle: project.title || t("projects.chart.title"),
+      svgEl: handle!.getSVGElement(),
+      events: data.events,
+      lanes: data.lanes,
+    };
+  }
+  function runExport(fn: (ctx: ExportContext) => void | Promise<void>): void {
+    void Promise.resolve()
+      .then(() => fn(ctxNow()))
+      .catch((err) => {
+        console.error("export failed", err);
+        if (host) {
+          host.setAttribute("data-export-error", "1");
+        }
+      });
+  }
+  wirePermalinkCopy("projects-chart-copylink");
+
+  wireExport("projects-chart-export-svg", () => runExport(exportSVG));
+  wireExport("projects-chart-export-png", () => runExport(exportPNG));
+  wireExport("projects-chart-export-csv", () => runExport(exportCSV));
+  wireExport("projects-chart-export-json", () => runExport(exportJSON));
+  wireExport("projects-chart-export-print", () => exportPrint());
+  // iCal goes server-side so it reuses the existing caldav_ical formatter
+  // (faraday-Q6 / m's pick: deadlines + appointments only — no projected).
+  wireExport("projects-chart-export-ics", () => {
+    window.location.href = `/api/projects/${encodeURIComponent(id)}/timeline.ics`;
+  });
+
+  // After the first paint, surface the undated hint when the renderer
+  // reports clipped/undated rows. Re-checked on resize-debounced repaint.
+  const checkUndated = () => {
+    if (!undatedHint || !handle) return;
+    const layout = handle.getLayout();
+    if (!layout) return;
+    if (layout.undatedCount > 0) {
+      undatedHint.style.display = "";
+      undatedHint.textContent = `${layout.undatedCount} Ereignis(se) ohne Datum (links angeheftet).`;
+    } else {
+      undatedHint.style.display = "none";
+    }
+  };
+  // Poll once after the initial fetch settles. mount() kicks the fetch
+  // synchronously; layout becomes available after the network round-trip.
+  setTimeout(checkUndated, 400);
+  setTimeout(checkUndated, 1500);
+}
+
+/** Render the lane-filter chip group once the renderer has lanes from
+ *  the server. One toggle button per lane; clicking flips inclusion in
+ *  the visible-lane allow-set. Hidden when there's only one lane (or
+ *  none) — the filter is pointless on a single-track render. */
+function renderLaneFilter(lanes: ReadonlyArray<{ id: string; label: string }>): void {
+  const container = document.getElementById("projects-chart-lanes-filter");
+  if (!container) return;
+  // Hide and bail when the filter wouldn't add value.
+  if (lanes.length < 2) {
+    container.innerHTML = "";
+    container.style.display = "none";
+    return;
+  }
+  container.style.display = "";
+  container.innerHTML = "";
+  const titleEl = document.createElement("span");
+  titleEl.className = "smart-timeline-chart-lanes-label";
+  titleEl.textContent = "Spuren:";
+  container.appendChild(titleEl);
+  for (const lane of lanes) {
+    const btn = document.createElement("button");
+    btn.type = "button";
+    btn.className = "smart-timeline-chart-lane-chip";
+    const isVisible = laneIsVisible(lane.id);
+    btn.setAttribute("aria-pressed", isVisible ? "true" : "false");
+    btn.dataset.laneId = lane.id;
+    btn.textContent = lane.label || lane.id;
+    btn.addEventListener("click", () => {
+      toggleLane(lane.id, lanes);
+      // Reflect new state immediately on this button + siblings.
+      for (const sibling of container.querySelectorAll<HTMLButtonElement>("button[data-lane-id]")) {
+        const sid = sibling.dataset.laneId || "";
+        sibling.setAttribute("aria-pressed", laneIsVisible(sid) ? "true" : "false");
+      }
+    });
+    container.appendChild(btn);
+  }
+}
+
+/** Permalink copy. The URL already aggregates every chip's state via the
+ *  individual writeParamToURL writers (palette + density + range + lanes),
+ *  so window.location.href IS the canonical shareable link. We copy it
+ *  to the clipboard and flash a "kopiert" confirmation on the button. */
+function wirePermalinkCopy(buttonId: string): void {
+  const btn = document.getElementById(buttonId) as HTMLButtonElement | null;
+  if (!btn) return;
+  const originalLabel = btn.textContent || "";
+  let resetTimer: ReturnType<typeof setTimeout> | null = null;
+  btn.addEventListener("click", async () => {
+    const url = window.location.href;
+    const ok = await copyToClipboard(url);
+    if (resetTimer) clearTimeout(resetTimer);
+    btn.textContent = ok ? "✓ Kopiert" : "⚠ Konnte nicht kopieren";
+    btn.classList.add(ok ? "is-success" : "is-error");
+    resetTimer = setTimeout(() => {
+      btn.textContent = originalLabel;
+      btn.classList.remove("is-success", "is-error");
+    }, 1800);
+  });
+}
+
+async function copyToClipboard(text: string): Promise<boolean> {
+  // Prefer the async Clipboard API. Falls back to the legacy exec hack
+  // for browsers / contexts where it's unavailable (some iframes, file://).
+  if (navigator.clipboard && window.isSecureContext) {
+    try {
+      await navigator.clipboard.writeText(text);
+      return true;
+    } catch {
+      // fall through
+    }
+  }
+  try {
+    const textarea = document.createElement("textarea");
+    textarea.value = text;
+    textarea.style.position = "fixed";
+    textarea.style.opacity = "0";
+    document.body.appendChild(textarea);
+    textarea.select();
+    const ok = document.execCommand("copy");
+    document.body.removeChild(textarea);
+    return ok;
+  } catch {
+    return false;
+  }
+}
+
+function wireExport(buttonId: string, handler: () => void): void {
+  const btn = document.getElementById(buttonId) as HTMLButtonElement | null;
+  if (!btn) return;
+  btn.addEventListener("click", (e) => {
+    e.preventDefault();
+    handler();
+    // Close the <details> dropdown so the user sees the chart-area
+    // update (download notification, print preview, etc).
+    const details = btn.closest("details");
+    if (details) details.removeAttribute("open");
+  });
+}
+
+// Lane-filter mutable state lives at module scope so renderLaneFilter
+// closures over the same set as toggleLane / laneIsVisible. We can't
+// access boot()'s `visibleLanes` from here cleanly, so we mirror it.
+let moduleVisibleLanes: string[] | null = null;
+let moduleHandleRef: ChartHandle | null = null;
+
+function laneIsVisible(id: string): boolean {
+  if (moduleVisibleLanes === null) return true;
+  return moduleVisibleLanes.includes(id);
+}
+
+function toggleLane(id: string, allLanes: ReadonlyArray<{ id: string }>): void {
+  if (moduleVisibleLanes === null) {
+    // Currently "show all" — turning a chip off means everyone except this one.
+    moduleVisibleLanes = allLanes.map((l) => l.id).filter((l) => l !== id);
+  } else if (moduleVisibleLanes.includes(id)) {
+    moduleVisibleLanes = moduleVisibleLanes.filter((l) => l !== id);
+  } else {
+    moduleVisibleLanes = [...moduleVisibleLanes, id];
+  }
+  // If user toggled every lane back on, collapse to null (show all).
+  if (moduleVisibleLanes.length === allLanes.length) {
+    moduleVisibleLanes = null;
+  }
+  // If user toggled every lane off, snap back to null too — an empty
+  // chart is never useful, treat as "you didn't mean that, show all".
+  if (moduleVisibleLanes !== null && moduleVisibleLanes.length === 0) {
+    moduleVisibleLanes = null;
+  }
+  if (moduleHandleRef) {
+    moduleHandleRef.setVisibleLanes(moduleVisibleLanes);
+  }
+  writeLanesToURL(moduleVisibleLanes);
+}
+
+document.addEventListener("DOMContentLoaded", () => {
+  void boot();
+});

frontend/src/client/projects-new.ts

@@ -6,6 +6,7 @@ import {
   wireTypeChange,
   showFieldsForType,
   readPayload,
+  populateProceedingTypeSelect,
 } from "./project-form";
 
 // /projects/new client. Posts v2 CreateProjectInput shape using the shared
@@ -106,5 +107,8 @@ document.addEventListener("DOMContentLoaded", async () => {
   await loadParentCandidates();
   initParentPicker();
   await applyParentFromQueryString();
+  // Fire-and-forget — the picker is hidden until type=case, so no need
+  // to block initial render on the fetch.
+  void populateProceedingTypeSelect();
   submitForm();
 });

frontend/src/client/rule-label.ts

@@ -0,0 +1,87 @@
+// rule-label — canonical display contract for deadline rules.
+//
+// t-paliad-258 / m/paliad#89 addendum. Previously each surface (deadline
+// form, list rows, detail header, Schriftsätze tab, browse-a-proceeding)
+// invented its own pattern: sometimes citation-only, sometimes name-only,
+// sometimes "code — name". m flagged this on the first submissions in a
+// proceeding sequence where the inconsistency was most visible.
+//
+// Canonical pattern: **Name primary, Citation muted secondary**.
+//   Text: "Notice of Appeal · UPC.RoP.220.1"
+//   HTML: <span class="rule-label-name">Notice of Appeal</span>
+//         <span class="rule-label-sep"> · </span>
+//         <span class="rule-label-cite">UPC.RoP.220.1</span>
+//
+// Custom rules (t-paliad-258 — free-text label entered by the lawyer):
+//   formatCustomRuleLabel produces "<text>" with a "Custom" badge slot
+//   so list/detail surfaces can render both shapes uniformly.
+
+import { getLang, t } from "./i18n";
+
+export interface RuleLike {
+  name: string;
+  name_en?: string | null;
+  // The catalog carries multiple citation fields depending on which
+  // surface populated it. Order of preference: legal_source > rule_code
+  // > code. All three are accepted so callers don't have to normalise.
+  rule_code?: string | null;
+  code?: string | null;
+  legal_source?: string | null;
+}
+
+// formatRuleLabel returns the canonical plain-text label.
+// Falls back gracefully when either side is missing.
+export function formatRuleLabel(r: RuleLike): string {
+  const lang = getLang();
+  const name = (lang === "en" && r.name_en) ? r.name_en : r.name;
+  const cite = ruleCitation(r);
+  if (name && cite) return `${name} · ${cite}`;
+  return name || cite || "";
+}
+
+// formatRuleLabelHTML returns the canonical HTML form with muted-citation
+// styling. The caller passes the HTML-escape helper so we don't pull a
+// dependency on a specific esc() module — every surface already has one.
+export function formatRuleLabelHTML(r: RuleLike, esc: (s: string) => string): string {
+  const lang = getLang();
+  const name = (lang === "en" && r.name_en) ? r.name_en : r.name;
+  const cite = ruleCitation(r);
+  if (name && cite) {
+    return (
+      `<span class="rule-label-name">${esc(name)}</span>` +
+      `<span class="rule-label-sep"> · </span>` +
+      `<span class="rule-label-cite">${esc(cite)}</span>`
+    );
+  }
+  return esc(name || cite || "");
+}
+
+// ruleCitation returns the best-available citation string for a rule.
+// Exported so callers that need the bare code (e.g. CalDAV exports,
+// inline data attributes) can pull it without going through the label
+// formatter.
+export function ruleCitation(r: RuleLike): string {
+  return r.legal_source || r.rule_code || r.code || "";
+}
+
+// formatCustomRuleLabelHTML — render a free-text custom rule label with
+// a "Custom" badge slot. Used by surfaces that may display either a
+// catalog rule (formatRuleLabelHTML) or a custom one. Returns "" when
+// the text is empty so callers can fall through to "—".
+export function formatCustomRuleLabelHTML(text: string | null | undefined, esc: (s: string) => string): string {
+  const trimmed = (text ?? "").trim();
+  if (!trimmed) return "";
+  const badge = t("deadlines.field.rule.custom_badge") || "Custom";
+  return (
+    `<span class="rule-label-name">${esc(trimmed)}</span>` +
+    `<span class="rule-label-badge rule-label-badge--custom">${esc(badge)}</span>`
+  );
+}
+
+// formatCustomRuleLabel — plain-text equivalent of the above.
+export function formatCustomRuleLabel(text: string | null | undefined): string {
+  const trimmed = (text ?? "").trim();
+  if (!trimmed) return "";
+  const badge = t("deadlines.field.rule.custom_badge") || "Custom";
+  return `${trimmed} · ${badge}`;
+}

frontend/src/client/settings.ts

@@ -51,8 +51,8 @@ interface SyncLogEntry {
   duration_ms?: number;
 }
 
-type TabName = "profil" | "benachrichtigungen" | "caldav";
-const TABS: TabName[] = ["profil", "benachrichtigungen", "caldav"];
+type TabName = "profil" | "benachrichtigungen" | "caldav" | "export";
+const TABS: TabName[] = ["profil", "benachrichtigungen", "caldav", "export"];
 const DEFAULT_TAB: TabName = "profil";
 
 let me: Me | null = null;
@@ -115,6 +115,7 @@ function showTab(tab: TabName, pushHistory: boolean) {
     if (tab === "profil") void loadProfilTab();
     else if (tab === "benachrichtigungen") void loadPrefsTab();
     else if (tab === "caldav") void loadCalDAVTab();
+    else if (tab === "export") void loadExportTab();
   }
 }
 
@@ -411,6 +412,11 @@ async function loadCalDAVTab() {
   fillCalDAVForm();
   renderCalDAVStatus();
   await loadCalDAVLog();
+  // Slice 2b — multi-calendar bindings. loadBindingProjects feeds the
+  // project picker for scope=project; runs in parallel with the binding
+  // list fetch.
+  void loadBindingProjects();
+  await loadBindings();
 }
 
 async function loadCalDAVConfig(): Promise<boolean> {
@@ -596,6 +602,415 @@ async function deleteCalDAVConfig() {
   }
 }
 
+// --- CalDAV bindings (Slice 2b multi-calendar picker) ---------------------
+
+interface UserCalendarBinding {
+  id: string;
+  user_id: string;
+  calendar_path: string;
+  display_name: string;
+  scope_kind: "all_visible" | "personal_only" | "project" | "client" | "litigation" | "patent" | "case";
+  scope_id?: string | null;
+  include_personal: boolean;
+  enabled: boolean;
+  last_sync_at?: string | null;
+  last_sync_error?: string | null;
+}
+
+interface DiscoveredCalendar {
+  href: string;
+  display_name: string;
+  supported_components?: string[];
+}
+
+interface ProjectListItem {
+  id: string;
+  reference?: string;
+  title?: string;
+  type?: string;
+}
+
+let bindings: UserCalendarBinding[] = [];
+let discoveredCalendars: DiscoveredCalendar[] = [];
+let bindingProjects: ProjectListItem[] = [];
+let editingBindingID: string | null = null;
+// Slice 2c — capability cached from /api/caldav-discover. null = unprobed,
+// true = MKCALENDAR supported (show "Create new calendar" radio),
+// false = degrade UX (hide radio, surface bilingual notice).
+let supportsMKCalendar: boolean | null = null;
+
+async function loadBindings(): Promise<void> {
+  const section = document.getElementById("caldav-bindings-section");
+  if (!section) return;
+  try {
+    const resp = await fetch("/api/caldav-bindings");
+    if (resp.status === 501) return; // CalDAV unavailable; leave hidden
+    if (!resp.ok) return;
+    bindings = (await resp.json()) as UserCalendarBinding[];
+    section.style.display = "";
+    renderBindingsList();
+  } catch {
+    /* non-fatal */
+  }
+}
+
+function renderBindingsList(): void {
+  const list = document.getElementById("caldav-bindings-list")!;
+  const empty = document.getElementById("caldav-bindings-empty")!;
+  if (!bindings.length) {
+    list.innerHTML = "";
+    empty.style.display = "block";
+    return;
+  }
+  empty.style.display = "none";
+  list.innerHTML = bindings.map(renderBindingCard).join("");
+  // Wire per-card buttons.
+  for (const b of bindings) {
+    const card = document.getElementById(`caldav-binding-card-${b.id}`);
+    if (!card) continue;
+    card.querySelector(".caldav-binding-edit-btn")?.addEventListener("click", () => openBindingModal(b));
+    card.querySelector(".caldav-binding-delete-btn")?.addEventListener("click", () => deleteBinding(b));
+    const toggle = card.querySelector(".caldav-binding-enabled-toggle") as HTMLInputElement | null;
+    toggle?.addEventListener("change", () => toggleBindingEnabled(b, toggle.checked));
+  }
+}
+
+function renderBindingCard(b: UserCalendarBinding): string {
+  const label = b.display_name || b.calendar_path;
+  const scope = scopeLabel(b);
+  const last = b.last_sync_at ? fmtDateTime(b.last_sync_at) : t("caldav.never");
+  const err = b.last_sync_error ? `<span class="caldav-status-error">${esc(b.last_sync_error)}</span>` : "";
+  return `<div class="caldav-binding-card" id="caldav-binding-card-${esc(b.id)}">
+    <div class="caldav-binding-card-row">
+      <div class="caldav-binding-card-title">
+        <strong>${esc(label)}</strong>
+        <span class="caldav-binding-scope-chip">${esc(scope)}</span>
+      </div>
+      <label class="caldav-toggle-label">
+        <input type="checkbox" class="caldav-binding-enabled-toggle" ${b.enabled ? "checked" : ""} />
+        <span data-i18n="caldav.bindings.card.enabled">Aktiv</span>
+      </label>
+    </div>
+    <div class="caldav-binding-card-row caldav-binding-card-meta">
+      <span class="caldav-binding-path">${esc(b.calendar_path)}</span>
+      <span class="caldav-binding-last-sync">${esc(t("caldav.status.last_sync"))} ${esc(last)} ${err}</span>
+    </div>
+    <div class="caldav-binding-card-actions">
+      <button type="button" class="btn-secondary caldav-binding-edit-btn" data-i18n="caldav.bindings.card.edit">Bearbeiten</button>
+      <button type="button" class="btn-danger caldav-binding-delete-btn" data-i18n="caldav.bindings.card.remove">Entfernen</button>
+    </div>
+  </div>`;
+}
+
+function scopeLabel(b: UserCalendarBinding): string {
+  switch (b.scope_kind) {
+    case "all_visible":
+      return t("caldav.bindings.scope.all_visible");
+    case "personal_only":
+      return t("caldav.bindings.scope.personal_only");
+    case "project": {
+      const p = bindingProjects.find((p) => p.id === b.scope_id);
+      const name = p ? p.title || p.reference || p.id.slice(0, 8) : "?";
+      return `${t("caldav.bindings.scope.project")}: ${name}`;
+    }
+    default:
+      return b.scope_kind;
+  }
+}
+
+async function loadBindingProjects(): Promise<void> {
+  if (bindingProjects.length) return;
+  try {
+    const resp = await fetch("/api/projects");
+    if (resp.ok) bindingProjects = (await resp.json()) as ProjectListItem[];
+  } catch {
+    /* ignore */
+  }
+}
+
+async function loadDiscoveredCalendars(): Promise<void> {
+  const sel = document.getElementById("caldav-binding-discover-select") as HTMLSelectElement;
+  sel.innerHTML = `<option value="">${esc(t("caldav.bindings.modal.source.loading"))}</option>`;
+  try {
+    const resp = await fetch("/api/caldav-discover");
+    if (!resp.ok) {
+      sel.innerHTML = `<option value="">${esc(t("caldav.bindings.modal.source.discover_failed"))}</option>`;
+      supportsMKCalendar = null;
+      syncBindingSourceModeUI();
+      return;
+    }
+    const data = (await resp.json()) as {
+      calendars: DiscoveredCalendar[];
+      supports_mkcalendar?: boolean | null;
+    };
+    discoveredCalendars = data.calendars || [];
+    supportsMKCalendar = data.supports_mkcalendar ?? null;
+    if (!discoveredCalendars.length) {
+      sel.innerHTML = `<option value="">${esc(t("caldav.bindings.modal.source.discover_empty"))}</option>`;
+    } else {
+      sel.innerHTML = discoveredCalendars
+        .map((c) => `<option value="${esc(c.href)}">${esc(c.display_name || c.href)}</option>`)
+        .join("");
+    }
+    syncBindingSourceModeUI();
+  } catch {
+    sel.innerHTML = `<option value="">${esc(t("caldav.bindings.modal.source.discover_failed"))}</option>`;
+    supportsMKCalendar = null;
+    syncBindingSourceModeUI();
+  }
+}
+
+// syncBindingSourceModeUI shows / hides the "Neuen Kalender erstellen"
+// radio + the Google-degrade notice based on the cached
+// supports_mkcalendar capability. Also flips the visible input
+// (dropdown vs URL text box) to match the currently selected mode.
+function syncBindingSourceModeUI(): void {
+  const createRow = document.getElementById("caldav-binding-source-mode-create-row");
+  const degrade = document.getElementById("caldav-binding-degrade-notice");
+  if (createRow) createRow.style.display = supportsMKCalendar === true ? "" : "none";
+  if (degrade) degrade.style.display = supportsMKCalendar === false ? "" : "none";
+
+  // If supports_mkcalendar flipped to false while "create" was selected,
+  // fall back to "existing" so the user isn't staring at a hidden radio.
+  if (supportsMKCalendar !== true) {
+    const createRadio = document.querySelector(
+      'input[name="caldav-binding-source-mode"][value="create"]',
+    ) as HTMLInputElement | null;
+    if (createRadio?.checked) {
+      const existing = document.querySelector(
+        'input[name="caldav-binding-source-mode"][value="existing"]',
+      ) as HTMLInputElement | null;
+      if (existing) existing.checked = true;
+    }
+  }
+
+  const mode = currentBindingSourceMode();
+  const sel = document.getElementById("caldav-binding-discover-select") as HTMLSelectElement;
+  const customInput = document.getElementById("caldav-binding-custom-path") as HTMLInputElement;
+  sel.style.display = mode === "existing" ? "" : "none";
+  customInput.style.display = mode === "custom" ? "" : "none";
+}
+
+function currentBindingSourceMode(): "existing" | "create" | "custom" {
+  const checked = document.querySelector(
+    'input[name="caldav-binding-source-mode"]:checked',
+  ) as HTMLInputElement | null;
+  return (checked?.value as "existing" | "create" | "custom") ?? "existing";
+}
+
+function openBindingModal(b: UserCalendarBinding | null) {
+  editingBindingID = b ? b.id : null;
+  const modal = document.getElementById("caldav-binding-modal")!;
+  const title = document.getElementById("caldav-binding-modal-title")!;
+  const submitBtn = document.getElementById("caldav-binding-submit-btn")!;
+  const sourceField = document.getElementById("caldav-binding-source-field")!;
+  const customInput = document.getElementById("caldav-binding-custom-path") as HTMLInputElement;
+  const nameInput = document.getElementById("caldav-binding-display-name") as HTMLInputElement;
+  const projectSel = document.getElementById("caldav-binding-project-select") as HTMLSelectElement;
+  const msg = document.getElementById("caldav-binding-msg")!;
+  msg.textContent = "";
+
+  if (b) {
+    title.textContent = t("caldav.bindings.modal.edit_title");
+    submitBtn.textContent = t("caldav.bindings.modal.submit_edit");
+    sourceField.style.display = "none";
+    nameInput.value = b.display_name;
+    const radio = document.querySelector(`input[name="caldav-binding-scope"][value="${b.scope_kind}"]`) as HTMLInputElement | null;
+    if (radio) radio.checked = true;
+  } else {
+    title.textContent = t("caldav.bindings.modal.add_title");
+    submitBtn.textContent = t("caldav.bindings.modal.submit_add");
+    sourceField.style.display = "";
+    // Reset the 3-way source-mode radio to "existing" (most common path).
+    const existingRadio = document.querySelector(
+      'input[name="caldav-binding-source-mode"][value="existing"]',
+    ) as HTMLInputElement | null;
+    if (existingRadio) existingRadio.checked = true;
+    customInput.value = "";
+    nameInput.value = "";
+    const radio = document.querySelector(`input[name="caldav-binding-scope"][value="all_visible"]`) as HTMLInputElement;
+    radio.checked = true;
+    void loadDiscoveredCalendars();
+  }
+
+  // Project picker — populate options when project scope is picked.
+  projectSel.innerHTML = bindingProjects
+    .map((p) => `<option value="${esc(p.id)}">${esc((p.title || p.reference || p.id.slice(0, 8)))}</option>`)
+    .join("");
+  if (b && b.scope_kind === "project" && b.scope_id) {
+    projectSel.value = b.scope_id;
+    projectSel.disabled = false;
+  }
+  syncBindingScopeUI();
+  syncBindingSourceModeUI();
+
+  modal.style.display = "flex";
+}
+
+function closeBindingModal() {
+  document.getElementById("caldav-binding-modal")!.style.display = "none";
+  editingBindingID = null;
+}
+
+function syncBindingScopeUI(): void {
+  const scope = (document.querySelector('input[name="caldav-binding-scope"]:checked') as HTMLInputElement | null)?.value;
+  const projectSel = document.getElementById("caldav-binding-project-select") as HTMLSelectElement;
+  projectSel.disabled = scope !== "project";
+}
+
+async function submitBindingModal(ev: Event): Promise<void> {
+  ev.preventDefault();
+  const msg = document.getElementById("caldav-binding-msg")!;
+  msg.textContent = "";
+  const customInput = document.getElementById("caldav-binding-custom-path") as HTMLInputElement;
+  const sel = document.getElementById("caldav-binding-discover-select") as HTMLSelectElement;
+  const nameInput = document.getElementById("caldav-binding-display-name") as HTMLInputElement;
+  const projectSel = document.getElementById("caldav-binding-project-select") as HTMLSelectElement;
+  const submitBtn = document.getElementById("caldav-binding-submit-btn") as HTMLButtonElement;
+
+  const scope = (document.querySelector('input[name="caldav-binding-scope"]:checked') as HTMLInputElement | null)?.value;
+  if (!scope) {
+    msg.textContent = t("caldav.bindings.error.scope");
+    msg.className = "form-msg form-msg-error";
+    return;
+  }
+  if (scope === "project" && !projectSel.value) {
+    msg.textContent = t("caldav.bindings.error.scope_project");
+    msg.className = "form-msg form-msg-error";
+    return;
+  }
+
+  submitBtn.disabled = true;
+  try {
+    if (editingBindingID) {
+      const patchPayload: Record<string, unknown> = {
+        display_name: nameInput.value.trim(),
+        scope_kind: scope,
+        enabled: true,
+      };
+      if (scope === "project") patchPayload.scope_id = projectSel.value;
+      const resp = await fetch(`/api/caldav-bindings/${editingBindingID}`, {
+        method: "PATCH",
+        headers: { "Content-Type": "application/json" },
+        body: JSON.stringify(patchPayload),
+      });
+      if (!resp.ok) {
+        const err = await resp.json().catch(() => ({}) as { error?: string });
+        msg.textContent = err.error || t("caldav.error.generic");
+        msg.className = "form-msg form-msg-error";
+        return;
+      }
+    } else {
+      const mode = currentBindingSourceMode();
+      if (mode === "create") {
+        // Slice 2c MKCALENDAR path.
+        const displayName = nameInput.value.trim();
+        if (!displayName) {
+          msg.textContent = t("caldav.bindings.error.create_name_required");
+          msg.className = "form-msg form-msg-error";
+          return;
+        }
+        const createPayload: Record<string, unknown> = {
+          display_name: displayName,
+          scope_kind: scope,
+        };
+        if (scope === "project") createPayload.scope_id = projectSel.value;
+        const resp = await fetch("/api/caldav-mkcalendar", {
+          method: "POST",
+          headers: { "Content-Type": "application/json" },
+          body: JSON.stringify(createPayload),
+        });
+        if (resp.status === 501) {
+          // Race: probe flipped to false between modal-open and submit.
+          // Re-sync the UI and surface a helpful message.
+          supportsMKCalendar = false;
+          syncBindingSourceModeUI();
+          msg.textContent = t("caldav.bindings.error.create_unsupported");
+          msg.className = "form-msg form-msg-error";
+          return;
+        }
+        if (resp.status === 409) {
+          msg.textContent = t("caldav.bindings.error.create_name_taken");
+          msg.className = "form-msg form-msg-error";
+          return;
+        }
+        if (!resp.ok) {
+          const err = await resp.json().catch(() => ({}) as { error?: string });
+          msg.textContent = err.error || t("caldav.error.generic");
+          msg.className = "form-msg form-msg-error";
+          return;
+        }
+      } else {
+        // existing | custom — POST /api/caldav-bindings with the path.
+        const path = mode === "custom" ? customInput.value.trim() : sel.value;
+        if (!path) {
+          msg.textContent = t("caldav.bindings.error.path");
+          msg.className = "form-msg form-msg-error";
+          return;
+        }
+        const postPayload: Record<string, unknown> = {
+          calendar_path: path,
+          display_name: nameInput.value.trim(),
+          scope_kind: scope,
+          enabled: true,
+        };
+        if (scope === "project") postPayload.scope_id = projectSel.value;
+        if (!postPayload.display_name && mode === "existing") {
+          const opt = sel.options[sel.selectedIndex];
+          postPayload.display_name = opt ? opt.text : "";
+        }
+        const resp = await fetch("/api/caldav-bindings", {
+          method: "POST",
+          headers: { "Content-Type": "application/json" },
+          body: JSON.stringify(postPayload),
+        });
+        if (!resp.ok) {
+          const err = await resp.json().catch(() => ({}) as { error?: string });
+          msg.textContent = err.error || t("caldav.error.generic");
+          msg.className = "form-msg form-msg-error";
+          return;
+        }
+      }
+    }
+    closeBindingModal();
+    await loadBindings();
+  } catch {
+    msg.textContent = t("caldav.error.generic");
+    msg.className = "form-msg form-msg-error";
+  } finally {
+    submitBtn.disabled = false;
+  }
+}
+
+async function deleteBinding(b: UserCalendarBinding): Promise<void> {
+  if (!confirm(t("caldav.bindings.delete.confirm"))) return;
+  try {
+    const resp = await fetch(`/api/caldav-bindings/${b.id}`, { method: "DELETE" });
+    if (!resp.ok && resp.status !== 204 && resp.status !== 202) {
+      alert(t("caldav.bindings.delete.failed"));
+      return;
+    }
+    await loadBindings();
+  } catch {
+    alert(t("caldav.bindings.delete.failed"));
+  }
+}
+
+async function toggleBindingEnabled(b: UserCalendarBinding, enabled: boolean): Promise<void> {
+  try {
+    const resp = await fetch(`/api/caldav-bindings/${b.id}`, {
+      method: "PATCH",
+      headers: { "Content-Type": "application/json" },
+      body: JSON.stringify({ enabled }),
+    });
+    if (resp.ok) {
+      b.enabled = enabled;
+    }
+  } catch {
+    /* non-fatal */
+  }
+}
+
 // --- "Meine Partner Units" card on the profile tab -------------------------
 //
 // Read-only summary of the current user's structural memberships. Membership
@@ -662,6 +1077,48 @@ async function renderMyPartnerUnits(): Promise<void> {
   }
 }
 
+// --- Export tab (t-paliad-214 Slice 1) -------------------------------------
+
+// Personal data export. One button; on click hits GET /api/me/export and the
+// browser handles the download via Content-Disposition. We use an anchor +
+// hidden iframe pattern so any non-200 response can surface inline instead
+// of silently triggering a save dialog with an error-html body.
+async function loadExportTab(): Promise<void> {
+  // Nothing to fetch on render; the tab is static text + button. Wired in
+  // the DOMContentLoaded handler.
+}
+
+function runExport(): void {
+  const msg = document.getElementById("export-msg");
+  const btn = document.getElementById("export-btn") as HTMLButtonElement | null;
+  if (msg) msg.textContent = "";
+  if (btn) btn.disabled = true;
+  // Trigger a navigation to the endpoint. The server sets
+  // Content-Disposition: attachment which the browser respects.
+  // We use a transient <a download> so the click goes through the
+  // normal download path even on browsers that try to render text/json.
+  const a = document.createElement("a");
+  a.href = "/api/me/export";
+  // download="" tells the browser to keep the server-provided filename
+  // when one is set via Content-Disposition.
+  a.download = "";
+  document.body.appendChild(a);
+  a.click();
+  document.body.removeChild(a);
+  // Re-enable after a short timeout so users can re-trigger if needed.
+  // We don't try to detect download completion — there's no portable
+  // browser API for it.
+  if (btn) {
+    setTimeout(() => {
+      btn.disabled = false;
+      if (msg)
+        msg.textContent =
+          t("einstellungen.export.started") ||
+          "Download gestartet. Falls nichts passiert, prüfen Sie Ihren Browser-Downloadordner.";
+    }, 500);
+  }
+}
+
 // --- Init -------------------------------------------------------------------
 
 document.addEventListener("DOMContentLoaded", () => {
@@ -675,6 +1132,20 @@ document.addEventListener("DOMContentLoaded", () => {
   document.getElementById("caldav-test-btn")!.addEventListener("click", testCalDAVConnection);
   document.getElementById("caldav-delete-btn")!.addEventListener("click", deleteCalDAVConfig);
 
+  // CalDAV bindings (Slice 2b + 2c) — add/edit modal wiring.
+  document.getElementById("caldav-bindings-add-btn")?.addEventListener("click", () => openBindingModal(null));
+  document.getElementById("caldav-binding-modal-close")?.addEventListener("click", closeBindingModal);
+  document.getElementById("caldav-binding-cancel-btn")?.addEventListener("click", closeBindingModal);
+  document.getElementById("caldav-binding-form")?.addEventListener("submit", submitBindingModal);
+  document.querySelectorAll('input[name="caldav-binding-source-mode"]').forEach((el) => {
+    el.addEventListener("change", syncBindingSourceModeUI);
+  });
+  document.querySelectorAll('input[name="caldav-binding-scope"]').forEach((el) => {
+    el.addEventListener("change", syncBindingScopeUI);
+  });
+  const exportBtn = document.getElementById("export-btn");
+  if (exportBtn) exportBtn.addEventListener("click", runExport);
+
   onLangChange(() => {
     if (loadedTabs.has("profil")) renderOfficeOptions();
     if (loadedTabs.has("caldav")) {

frontend/src/client/sidebar.ts

@@ -11,6 +11,13 @@ const WIDTH_KEY = "paliad-sidebar-width";
 const SIDEBAR_WIDTH_MIN = 180;
 const SIDEBAR_WIDTH_MAX = 480;
 const SIDEBAR_WIDTH_DEFAULT = 240;
+// Per-tab scroll position of the .sidebar-nav scroll container. Persisted
+// on every scroll event, restored on initSidebar() so a full-page nav
+// click doesn't bounce the user back to the top of a long sidebar
+// (Werkzeuge + projects + user views can easily overflow). sessionStorage
+// scopes it to the tab — opening a sidebar link in a new tab (Cmd-click)
+// starts that tab fresh at the top, which matches user expectation.
+const SCROLL_KEY = "paliad.sidebar.scroll";
 
 // toggleMobileSidebar opens or closes the slide-out drawer. Exposed so the
 // BottomNav menu slot can call it without duplicating the open/close
@@ -49,6 +56,23 @@ function applySidebarWidth(px: number): void {
   document.documentElement.style.setProperty("--sidebar-width", `${px}px`);
 }
 
+// readStoredScroll returns the persisted scrollTop or 0 when missing /
+// malformed. Bounds are checked at apply time against the actual
+// scrollHeight, so a stale value pointing past the current scroll range
+// is harmless (the browser clamps assignments to [0, max]).
+function readStoredScroll(): number {
+  const raw = sessionStorage.getItem(SCROLL_KEY);
+  if (raw === null) return 0;
+  const n = parseInt(raw, 10);
+  if (!Number.isFinite(n) || n < 0) return 0;
+  return n;
+}
+
+function applySidebarScroll(nav: HTMLElement, px: number): void {
+  if (px <= 0) return;
+  nav.scrollTop = px;
+}
+
 // migrateLegacyPinKey copies the pre-rebrand pin state into the new key on
 // first load and removes the stale entry. Drop this fallback once the rename
 // grace period is over.
@@ -73,11 +97,13 @@ export function initSidebar() {
   initInboxBadge();
   initAdminGroup();
   initPaliadinLinks();
+  initProjectContextChartLink();
   initUserViewsGroup();
   initThemeToggle();
   const sidebar = document.querySelector<HTMLElement>(".sidebar");
   if (!sidebar) return;
   initSidebarResize(sidebar);
+  initSidebarScrollRestore(sidebar);
 
   const pinBtn = sidebar.querySelector<HTMLButtonElement>(".sidebar-pin");
   const hamburger = document.querySelector<HTMLButtonElement>(".sidebar-hamburger");
@@ -292,6 +318,29 @@ function initSidebarResize(sidebar: HTMLElement): void {
   });
 }
 
+// initSidebarScrollRestore wires the .sidebar-nav scroll container to
+// sessionStorage so the user's scroll position survives a full-page
+// navigation (every sidebar link click is a real reload — see m/paliad#85).
+// Restore is synchronous on init so the first paint is already at the
+// right offset; the passive scroll listener persists subsequent moves.
+// reapplySidebarScroll() exists so callers that mutate sidebar content
+// async (initUserViewsGroup appending /api/user-views into the Ansichten
+// group) can nudge the scroll back to where it was after the layout shift.
+function initSidebarScrollRestore(sidebar: HTMLElement): void {
+  const nav = sidebar.querySelector<HTMLElement>(".sidebar-nav");
+  if (!nav) return;
+  applySidebarScroll(nav, readStoredScroll());
+  nav.addEventListener("scroll", () => {
+    sessionStorage.setItem(SCROLL_KEY, String(nav.scrollTop));
+  }, { passive: true });
+}
+
+function reapplySidebarScroll(): void {
+  const nav = document.querySelector<HTMLElement>(".sidebar .sidebar-nav");
+  if (!nav) return;
+  applySidebarScroll(nav, readStoredScroll());
+}
+
 // Changelog badge — fetches the count of entries newer than the locally
 // stored "last seen" stamp and renders a dot + number on the Neuigkeiten
 // link. Skipped on the changelog page itself because changelog.ts stamps
@@ -431,6 +480,11 @@ function initUserViewsGroup(): void {
       for (const view of views) {
         items.appendChild(renderUserViewItem(view, currentPath));
       }
+      // The synchronous restore in initSidebarScrollRestore() happened
+      // before these views were appended, so a saved scrollTop that
+      // pointed below the Ansichten group would now sit on the wrong
+      // row. Re-apply once the layout has stabilised.
+      reapplySidebarScroll();
       // After rendering, kick off count refresh for views that opted in.
       for (const view of views) {
         if (view.show_count) {
@@ -443,6 +497,11 @@ function initUserViewsGroup(): void {
     });
 }
 
+// fixVerfahrensablaufActive removed (t-paliad-179 Slice 1). The two
+// sidebar entries now map 1:1 to distinct URLs (/tools/fristenrechner
+// vs /tools/verfahrensablauf), so the SSR navItem helper picks the
+// correct active class by pathname alone.
+
 function renderUserViewItem(view: UserViewLite, currentPath: string): HTMLElement {
   const a = document.createElement("a");
   a.href = `/views/${encodeURIComponent(view.slug)}`;
@@ -544,6 +603,31 @@ function initPaliadinLinks(): void {
     });
 }
 
+// initProjectContextChartLink (t-paliad-177 Slice 3) reveals an "Als Chart
+// anzeigen" entry in the sidebar when the user is browsing a project
+// detail page. Hidden everywhere else, hidden on the chart page itself
+// (the chart is the destination, not the source).
+//
+// Self-contained on URL parsing — no per-page handshake needed. Pages
+// don't have to know about the sidebar slot; this function walks the
+// pathname and renders the link if it matches.
+//
+// Layout intent: chip sits directly under the "Übersicht" group so it's
+// visible on every project sub-tab (Verlauf / Team / Parteien / …).
+function initProjectContextChartLink(): void {
+  const link = document.getElementById("sidebar-project-chart-link") as HTMLAnchorElement | null;
+  if (!link) return;
+  const match = /^\/projects\/([0-9a-fA-F-]{36})(\/.*)?$/.exec(window.location.pathname);
+  if (!match) return;
+  const id = match[1];
+  const rest = match[2] || "";
+  // Hide on the chart page itself — a reciprocal "Zurück zum Verlauf"
+  // affordance lives on the chart page header (separate slice).
+  if (rest === "/chart" || rest === "/chart/") return;
+  link.href = `/projects/${encodeURIComponent(id)}/chart`;
+  link.style.display = "";
+}
+
 // initAdminGroup reveals the Admin section in the sidebar when the caller's
 // /api/me lookup confirms global_role='global_admin'. The markup is in the
 // DOM with display:none for everyone — flipping it on after the fetch lands

frontend/src/client/submissions-index.ts

@@ -0,0 +1,130 @@
+import { initI18n, onLangChange, t, getLang } from "./i18n";
+import { initSidebar } from "./sidebar";
+
+// t-paliad-240 — global Schriftsätze drafts index. Loads
+// /api/user/submission-drafts and renders one entity-table row per
+// draft. Row click → editor at /projects/{project_id}/submissions/
+// {submission_code}/draft/{draft_id}. Per project CLAUDE.md row-click
+// contract: a table whose rows look clickable must navigate on click;
+// inner links / buttons keep their own affordance.
+
+interface DraftRow {
+  id: string;
+  project_id: string | null;
+  project_title: string | null;
+  project_reference?: string | null;
+  submission_code: string;
+  name: string;
+  last_exported_at?: string | null;
+  updated_at: string;
+  created_at: string;
+}
+
+let drafts: DraftRow[] = [];
+
+function esc(s: string): string {
+  const d = document.createElement("div");
+  d.textContent = s;
+  return d.innerHTML;
+}
+
+function fmtDate(iso: string): string {
+  const d = new Date(iso);
+  if (isNaN(d.getTime())) return "";
+  const isEN = getLang() === "en";
+  return d.toLocaleDateString(isEN ? "en-GB" : "de-DE", {
+    year: "numeric",
+    month: "2-digit",
+    day: "2-digit",
+    hour: "2-digit",
+    minute: "2-digit",
+  });
+}
+
+async function load(): Promise<void> {
+  const loading = document.getElementById("submissions-index-loading")!;
+  const empty = document.getElementById("submissions-index-empty")!;
+  const error = document.getElementById("submissions-index-error")!;
+  const wrap = document.getElementById("submissions-index-tablewrap")!;
+
+  try {
+    const resp = await fetch("/api/user/submission-drafts");
+    if (!resp.ok) {
+      loading.style.display = "none";
+      error.style.display = "";
+      return;
+    }
+    const data = await resp.json();
+    drafts = (data.drafts ?? []) as DraftRow[];
+  } catch {
+    loading.style.display = "none";
+    error.style.display = "";
+    return;
+  }
+
+  loading.style.display = "none";
+
+  if (drafts.length === 0) {
+    empty.style.display = "";
+    wrap.style.display = "none";
+    return;
+  }
+  empty.style.display = "none";
+  wrap.style.display = "";
+  render();
+}
+
+function render(): void {
+  const body = document.getElementById("submissions-index-body")!;
+
+  const isEN = getLang() === "en";
+  const noProjectLabel = isEN ? "(no project)" : "(kein Projekt)";
+
+  body.innerHTML = drafts.map((d) => {
+    const projectCell = (() => {
+      if (!d.project_id) {
+        return `<span class="submissions-index-no-project">${esc(noProjectLabel)}</span>`;
+      }
+      const title = esc(d.project_title ?? "");
+      if (d.project_reference) {
+        return `<a href="/projects/${esc(d.project_id)}" class="checklist-instance-project"><span class="entity-ref">${esc(d.project_reference)}</span> ${title}</a>`;
+      }
+      return `<a href="/projects/${esc(d.project_id)}" class="checklist-instance-project">${title}</a>`;
+    })();
+
+    const href = d.project_id
+      ? `/projects/${esc(d.project_id)}/submissions/${esc(d.submission_code)}/draft/${esc(d.id)}`
+      : `/submissions/draft/${esc(d.id)}`;
+
+    return `<tr class="submissions-index-row" data-href="${esc(href)}">
+      <td>${projectCell}</td>
+      <td>${esc(d.submission_code)}</td>
+      <td><a href="${esc(href)}" class="submissions-index-draft-name">${esc(d.name)}</a></td>
+      <td>${esc(fmtDate(d.updated_at))}</td>
+    </tr>`;
+  }).join("");
+
+  body.querySelectorAll<HTMLTableRowElement>(".submissions-index-row").forEach((row) => {
+    const href = row.dataset.href!;
+    row.addEventListener("click", (e) => {
+      // Inner <a> elements (project link, draft name) handle their own
+      // navigation — let the browser dispatch them.
+      if ((e.target as HTMLElement).closest("a, button")) return;
+      window.location.href = href;
+    });
+  });
+
+  // Keep tsc happy for the imported `t` (used only via data-i18n on
+  // static markup — keep the import so future dynamic strings can hook
+  // in without re-importing).
+  void t;
+}
+
+document.addEventListener("DOMContentLoaded", () => {
+  initI18n();
+  initSidebar();
+  onLangChange(() => {
+    if (drafts.length > 0) render();
+  });
+  void load();
+});

frontend/src/client/submissions-new.ts

@@ -0,0 +1,368 @@
+import { initI18n, getLang } from "./i18n";
+import { initSidebar } from "./sidebar";
+
+// t-paliad-243 — client for /submissions/new. Fetches the
+// cross-proceeding submission catalog, groups it by proceeding, filters
+// by text + chip, and offers two start paths per row: with project
+// (modal picker) or without (project-less draft → /submissions/draft/{id}).
+
+interface CatalogEntry {
+  submission_code: string;
+  name: string;
+  name_en: string;
+  event_type?: string;
+  primary_party?: string;
+  legal_source?: string;
+  has_template: boolean;
+  proceeding_code: string;
+  proceeding_name: string;
+  proceeding_name_en: string;
+}
+
+interface CatalogResponse {
+  entries: CatalogEntry[];
+}
+
+interface ProjectRow {
+  id: string;
+  title: string;
+  reference?: string | null;
+}
+
+interface State {
+  entries: CatalogEntry[];
+  activeProceeding: string | null; // null = all
+  searchTerm: string;
+  pickerForCode: string | null;
+}
+
+const state: State = {
+  entries: [],
+  activeProceeding: null,
+  searchTerm: "",
+  pickerForCode: null,
+};
+
+function isEN(): boolean {
+  return getLang() === "en";
+}
+
+function esc(s: string): string {
+  const d = document.createElement("div");
+  d.textContent = s;
+  return d.innerHTML;
+}
+
+function partyLabel(role: string | undefined): string {
+  switch ((role ?? "").toLowerCase()) {
+    case "claimant": return isEN() ? "Claimant" : "Klägerin";
+    case "defendant": return isEN() ? "Defendant" : "Beklagte";
+    case "both": return isEN() ? "Both" : "Beide";
+    case "court": return isEN() ? "Court" : "Gericht";
+    default: return "";
+  }
+}
+
+async function loadCatalog(): Promise<void> {
+  const loading = document.getElementById("submissions-new-loading")!;
+  const error = document.getElementById("submissions-new-error")!;
+  const wrap = document.getElementById("submissions-new-tablewrap")!;
+
+  try {
+    const resp = await fetch("/api/submissions/catalog");
+    if (!resp.ok) {
+      loading.style.display = "none";
+      error.style.display = "";
+      return;
+    }
+    const data = (await resp.json()) as CatalogResponse;
+    state.entries = data.entries ?? [];
+  } catch {
+    loading.style.display = "none";
+    error.style.display = "";
+    return;
+  }
+
+  loading.style.display = "none";
+  wrap.style.display = "";
+  renderChips();
+  renderTable();
+}
+
+function renderChips(): void {
+  const host = document.getElementById("submissions-new-proceeding-chips");
+  if (!host) return;
+  const seen = new Map<string, string>();
+  for (const e of state.entries) {
+    if (!seen.has(e.proceeding_code)) {
+      seen.set(e.proceeding_code, isEN() && e.proceeding_name_en ? e.proceeding_name_en : e.proceeding_name);
+    }
+  }
+  const chips: string[] = [];
+  const allLabel = isEN() ? "All" : "Alle";
+  const allActive = state.activeProceeding === null;
+  chips.push(`<button type="button" class="submissions-new-chip${allActive ? " submissions-new-chip--active" : ""}" data-code="">${esc(allLabel)}</button>`);
+  for (const [code, name] of seen) {
+    const active = state.activeProceeding === code;
+    chips.push(`<button type="button" class="submissions-new-chip${active ? " submissions-new-chip--active" : ""}" data-code="${esc(code)}">${esc(name)} <span class="submissions-new-chip-code">${esc(code)}</span></button>`);
+  }
+  host.innerHTML = chips.join("");
+  host.querySelectorAll<HTMLButtonElement>(".submissions-new-chip").forEach((btn) => {
+    btn.addEventListener("click", () => {
+      const code = btn.dataset.code ?? "";
+      state.activeProceeding = code === "" ? null : code;
+      renderChips();
+      renderTable();
+    });
+  });
+}
+
+function filtered(): CatalogEntry[] {
+  const term = state.searchTerm.trim().toLowerCase();
+  return state.entries.filter((e) => {
+    if (state.activeProceeding !== null && e.proceeding_code !== state.activeProceeding) {
+      return false;
+    }
+    if (term === "") return true;
+    const name = isEN() && e.name_en ? e.name_en : e.name;
+    const hay = [
+      name,
+      e.submission_code,
+      e.legal_source ?? "",
+      e.proceeding_code,
+      e.proceeding_name,
+      e.proceeding_name_en,
+    ].join(" ").toLowerCase();
+    return hay.includes(term);
+  });
+}
+
+function renderTable(): void {
+  const body = document.getElementById("submissions-new-body");
+  const empty = document.getElementById("submissions-new-empty");
+  const wrap = document.getElementById("submissions-new-tablewrap");
+  if (!body || !empty || !wrap) return;
+
+  const rows = filtered();
+  if (rows.length === 0) {
+    wrap.style.display = "none";
+    empty.style.display = "";
+    return;
+  }
+  wrap.style.display = "";
+  empty.style.display = "none";
+
+  // Group by proceeding.
+  const groups = new Map<string, { name: string; entries: CatalogEntry[] }>();
+  for (const e of rows) {
+    const gname = isEN() && e.proceeding_name_en ? e.proceeding_name_en : e.proceeding_name;
+    const bucket = groups.get(e.proceeding_code);
+    if (bucket) {
+      bucket.entries.push(e);
+    } else {
+      groups.set(e.proceeding_code, { name: gname, entries: [e] });
+    }
+  }
+
+  const colspan = 4;
+  const html: string[] = [];
+  for (const [code, group] of groups) {
+    html.push(`<tr class="entity-table-group-header"><th colspan="${colspan}" scope="colgroup"><span class="entity-table-group-header__name">${esc(group.name)}</span> <span class="entity-table-group-header__code">${esc(code)}</span></th></tr>`);
+    for (const entry of group.entries) {
+      html.push(renderRow(entry));
+    }
+  }
+  body.innerHTML = html.join("");
+
+  body.querySelectorAll<HTMLButtonElement>(".submissions-new-start-no-project").forEach((btn) => {
+    btn.addEventListener("click", () => {
+      const code = btn.dataset.code;
+      if (code) void startDraft(code, null);
+    });
+  });
+  body.querySelectorAll<HTMLButtonElement>(".submissions-new-start-with-project").forEach((btn) => {
+    btn.addEventListener("click", () => {
+      const code = btn.dataset.code;
+      if (code) openProjectPicker(code);
+    });
+  });
+}
+
+function renderRow(entry: CatalogEntry): string {
+  const name = isEN() && entry.name_en ? entry.name_en : entry.name;
+  const source = entry.legal_source ?? "";
+  const templateBadge = entry.has_template
+    ? ""
+    : ` <span class="submission-template-badge" title="${esc(isEN() ? "Uses the universal style template" : "Verwendet die universelle Stilvorlage")}">${esc(isEN() ? "universal" : "universell")}</span>`;
+  const withProject = isEN() ? "Mit Projekt…" : "Mit Projekt…";
+  const noProject = isEN() ? "Ohne Projekt" : "Ohne Projekt";
+
+  return `<tr class="submission-row">
+    <td>
+      <span class="submission-name">${esc(name)}</span>
+      <span class="submission-code">${esc(entry.submission_code)}</span>${templateBadge}
+    </td>
+    <td>${esc(partyLabel(entry.primary_party))}</td>
+    <td>${esc(source)}</td>
+    <td class="submission-action-cell">
+      <button type="button" class="btn-secondary btn-small submissions-new-start-with-project" data-code="${esc(entry.submission_code)}">${esc(withProject)}</button>
+      <button type="button" class="btn-primary btn-cta-lime btn-small submissions-new-start-no-project" data-code="${esc(entry.submission_code)}">${esc(noProject)}</button>
+    </td>
+  </tr>`;
+}
+
+async function startDraft(submissionCode: string, projectID: string | null): Promise<void> {
+  try {
+    const resp = await fetch("/api/submission-drafts", {
+      method: "POST",
+      headers: { "Content-Type": "application/json" },
+      body: JSON.stringify({ submission_code: submissionCode, project_id: projectID }),
+    });
+    if (!resp.ok) {
+      let detail = "";
+      try {
+        const data = (await resp.json()) as { error?: string };
+        detail = data.error ?? "";
+      } catch { /* ignore */ }
+      alert((isEN() ? "Failed to create draft." : "Entwurf konnte nicht angelegt werden.") + (detail ? `\n\n${detail}` : ""));
+      return;
+    }
+    const view = await resp.json() as { draft: { id: string; project_id: string | null; submission_code: string } };
+    const id = view.draft.id;
+    const pid = view.draft.project_id;
+    const code = view.draft.submission_code;
+    if (pid) {
+      window.location.href = `/projects/${pid}/submissions/${encodeURIComponent(code)}/draft/${id}`;
+    } else {
+      window.location.href = `/submissions/draft/${id}`;
+    }
+  } catch (err) {
+    console.error("submissions-new createDraft:", err);
+    alert(isEN() ? "Failed to create draft." : "Entwurf konnte nicht angelegt werden.");
+  }
+}
+
+// ─────────────────────────────────────────────────────────────────────
+// Project picker modal
+// ─────────────────────────────────────────────────────────────────────
+
+let pickerProjects: ProjectRow[] = [];
+let pickerLoaded = false;
+
+function openProjectPicker(submissionCode: string): void {
+  state.pickerForCode = submissionCode;
+  const modal = document.getElementById("submissions-new-project-modal");
+  if (modal) modal.style.display = "";
+  if (!pickerLoaded) {
+    void loadPickerProjects();
+  } else {
+    renderPickerList();
+  }
+  const searchInput = document.getElementById("submissions-new-project-search") as HTMLInputElement | null;
+  if (searchInput) {
+    searchInput.value = "";
+    setTimeout(() => searchInput.focus(), 50);
+  }
+}
+
+function closeProjectPicker(): void {
+  state.pickerForCode = null;
+  const modal = document.getElementById("submissions-new-project-modal");
+  if (modal) modal.style.display = "none";
+}
+
+async function loadPickerProjects(): Promise<void> {
+  const loadingEl = document.getElementById("submissions-new-project-loading");
+  if (loadingEl) loadingEl.style.display = "";
+  try {
+    const resp = await fetch("/api/projects?status=active");
+    if (!resp.ok) throw new Error(`projects list ${resp.status}`);
+    const rows = (await resp.json()) as ProjectRow[];
+    pickerProjects = rows ?? [];
+    pickerLoaded = true;
+  } catch (err) {
+    console.error("submissions-new loadPickerProjects:", err);
+    pickerProjects = [];
+  } finally {
+    if (loadingEl) loadingEl.style.display = "none";
+  }
+  renderPickerList();
+}
+
+function renderPickerList(): void {
+  const list = document.getElementById("submissions-new-project-list");
+  const empty = document.getElementById("submissions-new-project-empty");
+  if (!list || !empty) return;
+
+  const searchInput = document.getElementById("submissions-new-project-search") as HTMLInputElement | null;
+  const term = (searchInput?.value ?? "").trim().toLowerCase();
+
+  const matches = pickerProjects.filter((p) => {
+    if (term === "") return true;
+    const hay = [p.title, p.reference ?? ""].join(" ").toLowerCase();
+    return hay.includes(term);
+  }).slice(0, 50);
+
+  if (matches.length === 0) {
+    list.innerHTML = "";
+    empty.style.display = "";
+    return;
+  }
+  empty.style.display = "none";
+
+  list.innerHTML = matches.map((p) => {
+    const ref = p.reference ? `<span class="entity-ref">${esc(p.reference)}</span> ` : "";
+    return `<li class="submissions-new-project-item" data-id="${esc(p.id)}">${ref}<span class="submissions-new-project-title">${esc(p.title)}</span></li>`;
+  }).join("");
+
+  list.querySelectorAll<HTMLLIElement>(".submissions-new-project-item").forEach((li) => {
+    li.addEventListener("click", () => {
+      const pid = li.dataset.id;
+      const code = state.pickerForCode;
+      if (pid && code) {
+        closeProjectPicker();
+        void startDraft(code, pid);
+      }
+    });
+  });
+}
+
+// ─────────────────────────────────────────────────────────────────────
+// Boot
+// ─────────────────────────────────────────────────────────────────────
+
+function wireToolbar(): void {
+  const search = document.getElementById("submissions-new-search") as HTMLInputElement | null;
+  if (search) {
+    search.addEventListener("input", () => {
+      state.searchTerm = search.value;
+      renderTable();
+    });
+  }
+
+  const closeBtn = document.getElementById("submissions-new-project-modal-close");
+  if (closeBtn) closeBtn.addEventListener("click", () => closeProjectPicker());
+
+  const modal = document.getElementById("submissions-new-project-modal");
+  if (modal) {
+    modal.addEventListener("click", (e) => {
+      if (e.target === modal) closeProjectPicker();
+    });
+  }
+
+  const pickerSearch = document.getElementById("submissions-new-project-search") as HTMLInputElement | null;
+  if (pickerSearch) {
+    pickerSearch.addEventListener("input", () => renderPickerList());
+  }
+
+  document.addEventListener("keydown", (e) => {
+    if (e.key === "Escape" && state.pickerForCode) closeProjectPicker();
+  });
+}
+
+document.addEventListener("DOMContentLoaded", () => {
+  initI18n();
+  initSidebar();
+  wireToolbar();
+  void loadCatalog();
+});

frontend/src/client/submissions.ts

@@ -0,0 +1,269 @@
+// Submissions panel — fetches the full submission catalog across every
+// proceeding and renders it grouped by proceeding, with the project's
+// own proceeding pinned at the top.
+//
+// t-paliad-215 Slice 1 introduced the per-project list. t-paliad-242
+// broadened it to the catalog: from any project a lawyer can pick a
+// Statement of Defence under UPC.INF.CFI, a Klageerwiderung under
+// DE.INF.LG, an Opposition under EPO, etc. — the editor (t-paliad-238)
+// handles missing variables gracefully via the [KEIN WERT: …] marker,
+// so cross-proceeding picks still render cleanly.
+
+function escapeHtml(s: string): string {
+  return s
+    .replace(/&/g, "&")
+    .replace(/</g, "&lt;")
+    .replace(/>/g, "&gt;")
+    .replace(/"/g, "&quot;")
+    .replace(/'/g, "&#39;");
+}
+
+interface SubmissionEntry {
+  submission_code: string;
+  name: string;
+  name_en: string;
+  event_type?: string;
+  primary_party?: string;
+  legal_source?: string;
+  has_template: boolean;
+  proceeding_code: string;
+  proceeding_name: string;
+  proceeding_name_en: string;
+}
+
+interface SubmissionListResponse {
+  project_id: string;
+  proceeding_type_id?: number;
+  project_proceeding_code?: string;
+  entries: SubmissionEntry[];
+}
+
+// Module state — set once per page load when the user first opens the
+// tab. Subsequent activations re-use the cached result so the lawyer
+// doesn't pay for repeat list calls flipping between tabs.
+let cached: { projectID: string; data: SubmissionListResponse } | null = null;
+let loading = false;
+
+/**
+ * Load + render the submissions panel for the given project.
+ *
+ * Idempotent: safe to call on every tab activation. The second call
+ * paints from cache instantly; the first call shows a loading state
+ * until the list response arrives.
+ */
+export async function loadAndRenderSubmissions(projectID: string): Promise<void> {
+  if (loading) return;
+  if (cached && cached.projectID === projectID) {
+    render(cached.data);
+    return;
+  }
+  loading = true;
+  try {
+    const resp = await fetch(`/api/projects/${projectID}/submissions`);
+    if (!resp.ok) {
+      renderError();
+      return;
+    }
+    const data = (await resp.json()) as SubmissionListResponse;
+    cached = { projectID, data };
+    render(data);
+  } catch {
+    renderError();
+  } finally {
+    loading = false;
+  }
+}
+
+function render(data: SubmissionListResponse): void {
+  const empty = document.getElementById("project-submissions-empty");
+  const noProc = document.getElementById("project-submissions-no-proceeding");
+  const wrap = document.getElementById("project-submissions-tablewrap");
+  const body = document.getElementById("project-submissions-body");
+  if (!empty || !noProc || !wrap || !body) return;
+
+  // t-paliad-242: the catalog is shown to every project regardless of
+  // whether a proceeding is bound — the no-proceeding hint stays as a
+  // soft nudge above the table, but no longer hides the catalog.
+  noProc.style.display = data.proceeding_type_id == null || data.proceeding_type_id === 0
+    ? ""
+    : "none";
+
+  if (data.entries.length === 0) {
+    empty.style.display = "";
+    wrap.style.display = "none";
+    return;
+  }
+  empty.style.display = "none";
+  wrap.style.display = "";
+
+  const isEN = document.documentElement.lang === "en";
+
+  // Group entries by proceeding_code. Build a stable group order:
+  // project's own proceeding first (when present), then alphabetical
+  // by proceeding_code for the rest.
+  const groups = new Map<string, { name: string; entries: SubmissionEntry[] }>();
+  for (const entry of data.entries) {
+    const key = entry.proceeding_code || "";
+    const groupName = isEN && entry.proceeding_name_en
+      ? entry.proceeding_name_en
+      : entry.proceeding_name;
+    const bucket = groups.get(key);
+    if (bucket) {
+      bucket.entries.push(entry);
+    } else {
+      groups.set(key, { name: groupName, entries: [entry] });
+    }
+  }
+
+  const ownCode = data.project_proceeding_code ?? "";
+  const orderedCodes: string[] = [];
+  if (ownCode && groups.has(ownCode)) orderedCodes.push(ownCode);
+  for (const code of Array.from(groups.keys()).sort()) {
+    if (code !== ownCode) orderedCodes.push(code);
+  }
+
+  const ownSuffix = isEN ? " (this project)" : " (dieses Projekt)";
+  const colspan = 4;
+
+  const html: string[] = [];
+  for (const code of orderedCodes) {
+    const group = groups.get(code);
+    if (!group) continue;
+    const isOwn = code === ownCode;
+    const label = group.name + (isOwn ? ownSuffix : "");
+    const headerClass = isOwn
+      ? "entity-table-group-header entity-table-group-header--own"
+      : "entity-table-group-header";
+    html.push(`<tr class="${headerClass}">`
+      + `<th colspan="${colspan}" scope="colgroup">`
+      + `<span class="entity-table-group-header__name">${escapeHtml(label)}</span>`
+      + ` <span class="entity-table-group-header__code">${escapeHtml(code)}</span>`
+      + `</th></tr>`);
+    for (const entry of group.entries) {
+      html.push(renderRow(entry, data.project_id, isEN));
+    }
+  }
+  body.innerHTML = html.join("");
+
+  // Wire button clicks. One handler per render to avoid stale closures
+  // from the previous render's data.
+  body.querySelectorAll<HTMLButtonElement>(".submission-generate-btn").forEach((btn) => {
+    btn.addEventListener("click", (e) => {
+      e.preventDefault();
+      e.stopPropagation();
+      void onGenerateClick(btn);
+    });
+  });
+}
+
+function renderRow(entry: SubmissionEntry, projectID: string, isEN: boolean): string {
+  const name = isEN && entry.name_en ? entry.name_en : entry.name;
+  const party = formatParty(entry.primary_party, isEN);
+  const source = entry.legal_source ?? "";
+  const draftHref = `/projects/${encodeURIComponent(projectID)}/submissions/${encodeURIComponent(entry.submission_code)}/draft`;
+  const templateBadge = entry.has_template
+    ? ""
+    : ` <span class="submission-template-badge" title="${isEN ? "Uses the universal style template" : "Verwendet die universelle Stilvorlage"}">${isEN ? "universal" : "universell"}</span>`;
+  const editBtn = `<a href="${escapeHtml(draftHref)}" class="btn-primary btn-cta-lime btn-small submission-edit-btn"
+            data-code="${escapeHtml(entry.submission_code)}"
+            data-i18n="projects.detail.submissions.action.edit">${isEN ? "Edit" : "Bearbeiten"}</a>`;
+  const generateBtn = `<button type="button" class="btn-secondary btn-small submission-generate-btn"
+                data-code="${escapeHtml(entry.submission_code)}"
+                data-project="${escapeHtml(projectID)}"
+                data-i18n="projects.detail.submissions.action.generate">${isEN ? "Generate" : "Generieren"}</button>`;
+  const action = `${editBtn} ${generateBtn}`;
+  return `<tr class="submission-row">
+    <td>
+      <span class="submission-name">${escapeHtml(name)}</span>
+      <span class="submission-code">${escapeHtml(entry.submission_code)}</span>${templateBadge}
+    </td>
+    <td>${escapeHtml(party)}</td>
+    <td>${escapeHtml(source)}</td>
+    <td class="submission-action-cell">${action}</td>
+  </tr>`;
+}
+
+function renderError(): void {
+  const empty = document.getElementById("project-submissions-empty");
+  const noProc = document.getElementById("project-submissions-no-proceeding");
+  const wrap = document.getElementById("project-submissions-tablewrap");
+  if (!empty || !noProc || !wrap) return;
+  noProc.style.display = "none";
+  wrap.style.display = "none";
+  empty.style.display = "";
+  empty.textContent = document.documentElement.lang === "en"
+    ? "Failed to load submissions list."
+    : "Schriftsatzliste konnte nicht geladen werden.";
+}
+
+function formatParty(role: string | undefined, isEN: boolean): string {
+  switch ((role ?? "").toLowerCase()) {
+    case "claimant": return isEN ? "Claimant" : "Klägerin";
+    case "defendant": return isEN ? "Defendant" : "Beklagte";
+    case "both": return isEN ? "Both" : "Beide";
+    case "court": return isEN ? "Court" : "Gericht";
+    default: return "";
+  }
+}
+
+// onGenerateClick triggers a download. Disables the button while the
+// request is in flight to prevent double-submits and surfaces an
+// inline error on failure.
+async function onGenerateClick(btn: HTMLButtonElement): Promise<void> {
+  const code = btn.dataset.code;
+  const projectID = btn.dataset.project;
+  if (!code || !projectID) return;
+
+  const originalLabel = btn.textContent ?? "";
+  btn.disabled = true;
+  btn.textContent = document.documentElement.lang === "en" ? "Generating…" : "Wird generiert…";
+
+  try {
+    const url = `/api/projects/${projectID}/submissions/${encodeURIComponent(code)}/generate`;
+    const resp = await fetch(url, { method: "POST" });
+    if (!resp.ok) {
+      let detail = "";
+      try {
+        const data = await resp.json() as { error?: string };
+        detail = data.error ?? "";
+      } catch {
+        // fallthrough
+      }
+      alert(
+        (document.documentElement.lang === "en"
+          ? "Generation failed."
+          : "Generieren fehlgeschlagen.") + (detail ? `\n\n${detail}` : ""),
+      );
+      return;
+    }
+    const blob = await resp.blob();
+    const filename = parseFilename(resp.headers.get("Content-Disposition") ?? "")
+      ?? `${code}.docx`;
+    triggerDownload(blob, filename);
+  } finally {
+    btn.disabled = false;
+    btn.textContent = originalLabel;
+  }
+}
+
+// parseFilename pulls the filename out of a Content-Disposition
+// header. Supports both unquoted and quoted forms.
+function parseFilename(header: string): string | null {
+  const m = /filename\s*=\s*"?([^";]+)"?/i.exec(header);
+  return m ? m[1] : null;
+}
+
+// triggerDownload creates an <a> with an object URL, clicks it, and
+// revokes the URL. Standard browser-side download pattern.
+function triggerDownload(blob: Blob, filename: string): void {
+  const url = URL.createObjectURL(blob);
+  const a = document.createElement("a");
+  a.href = url;
+  a.download = filename;
+  document.body.appendChild(a);
+  a.click();
+  document.body.removeChild(a);
+  // Revoke on next tick so the click actually triggers the download
+  // before the URL is gone.
+  setTimeout(() => URL.revokeObjectURL(url), 0);
+}