Replaces the misleading Proaktiv/Reaktiv column pair with a static
"Unsere Seite" / "Gericht" / "Gegnerseite" axis ("WE always on the
left", per m's t-paliad-257 ask). The side toggle now drives row
PLACEMENT into the ours/opponent buckets — the column labels stay
truthful regardless of which physical party occupies them.
Old framing lied half the time: Klägerseite is sometimes proactive
(filing the claim) and sometimes reactive (responding to a CCR),
so "Proaktiv (Klägerseite)" was wrong whenever the user's perspective
flipped. New axis is purely positional with semantic labels.
Changes:
- frontend/src/client/views/verfahrensablauf-core.ts:
• ColumnsRow fields proactive/reactive → ours/opponent.
• renderColumnsBody picks static "Unsere Seite" / "Gegnerseite"
labels — no more variant-by-side label keys.
• bucketDeadlinesIntoColumns routes the user's party into `ours`
when opts.side ∈ {"defendant"}; default (null) keeps the legacy
"we are claimant" fallback so claimant-on-left layout survives.
- verfahrensablauf-core.test.ts: rewritten expectations on the new
ours/opponent fields. Added two new tests pinning the WE-on-left
semantics and the side+appellant interaction (side=defendant +
appellant=claimant → "both" collapses into opponent).
- fristenrechner.ts: wires currentPerspective into renderColumnsBody
as `side` so the columns honour the chip-strip perspective.
Without this, a defendant-perspective user would see claimant
filings under the "Unsere Seite" header — the old code didn't
need the wire-up because the labels weren't perspective-aware.
- i18n.ts: replaces deadlines.col.proactive(.defendant) +
deadlines.col.reactive(.claimant) with deadlines.col.ours +
deadlines.col.opponent ("Unsere Seite"/"Client Side",
"Gegnerseite"/"Opponent Side"). Court key unchanged.
- i18n-keys.ts: regenerated key union.
- global.css: .fr-col-proactive/.fr-col-reactive renamed to
.fr-col-ours/.fr-col-opponent.
Out of scope (kept intact):
- Side and appellant URL-state plumbing.
- Appellant selector for Appeal-type proceedings (separate axis).
- Project-default side-from-our_side wiring — /tools/verfahrensablauf
has no project context, and /tools/fristenrechner already does this
via applyOurSidePredefine().
Build: bun run build clean (2794 keys), go build ./... clean.
Tests: 112 frontend tests pass (was 110, +2 new); all Go tests
cached green.
paliad
Paliad — all-in-one patent practice platform for HLC (formerly Hogan Lovells). Knowledge tools and Aktenverwaltung behind one sidebar.
- Aktenverwaltung: Akten (matters), Fristen (deadlines), Termine (appointments) with CalDAV sync, Parteien, Dashboard. Office-scoped visibility with explicit collaborators.
- Knowledge tools: Prozesskostenrechner (DE / UPC / EPA), Fristenrechner, Gebührentabellen, Patentglossar, Gerichtsverzeichnis, Checklisten, Link Hub, Downloads.
Domain: paliad.de (legacy: patholo.de, patholo.msbls.de).
Repo: m/paliad on mgit.msbls.de.
Stack
- Frontend: Bun + custom JSX/TSX renderer (no React), per-page client TS bundles, HTML-first forms
- Backend: Go (
net/http),sqlxfor DB access - Migrations:
golang-migrate/migrate/v4with SQL files embedded viaembed.FS; applied at server startup before the HTTP listener binds - Database: youpc Supabase Postgres,
paliadschema. Office-scoped RLS (paliad.can_see_akte(akte_id)) — seedocs/design-kanzlai-integration.md§2 - Auth: Supabase password (cookie session,
@hoganlovells.com/@hlc.*email gate) - CalDAV: hand-rolled iCal + minimal WebDAV client in
internal/services/caldav_*.go; AES-GCM at rest for stored passwords - Hosting: Dokploy compose
Zx147ycurfYagKRl_Zzyoon mlake
Database migrations
Migrations live in internal/db/migrations/ as NNN_description.up.sql + .down.sql pairs. They are embedded into the Go binary via embed.FS and applied automatically at server startup (before the HTTP listener binds) when DATABASE_URL is set.
The migration tracker is paliad.paliad_schema_migrations (not the default public.schema_migrations). This avoids a collision with other apps on the shared youpc Supabase instance — see the memory episode "paliad migration bootstrap collision with shared Postgres" for the incident that drove the change.
Current migrations (as of April 2026):
001_paliad_schema schema + extensions
002_users paliad.users (office, role, practice_group)
003_reference_tables proceeding_types, deadline_rules, holidays
004_akten paliad.akten with visibility columns
005_akten_children parteien, fristen, termine, dokumente, akten_events, notizen
006_visibility paliad.can_see_akte() function
007_rls_policies RLS on every paliad table
008_seed_proceeding_types
009_seed_deadline_rules 32 UPC + 4 ZPO rules
010_seed_holidays DE federal + UPC judicial vacations
011_feedback_tables link_suggestions, checklisten_feedback, gerichte_feedback
012_fristenrechner_rules DB-backed rule set for /tools/fristenrechner
013_user_caldav_config per-user CalDAV (encrypted) + sync log
014_checklist_instances persisted checklist instances linkable to Akten
Add a new migration:
internal/db/migrations/015_<description>.up.sql
internal/db/migrations/015_<description>.down.sql
The down file is required and must reverse the up cleanly (verified by adding a one-off down test before merge).
To run migrations against a local Postgres:
docker run -d --name paliad-pg -e POSTGRES_PASSWORD=test -p 5432:5432 postgres:16-alpine
# bootstrap a mock auth schema (auth.users + auth.uid()) — required because
# the migrations reference Supabase-provided objects:
psql postgres://postgres:test@localhost:5432/postgres -f internal/db/devtools/mock_supabase_auth.sql
DATABASE_URL='postgres://postgres:test@localhost:5432/postgres?sslmode=disable' \
SUPABASE_URL=stub SUPABASE_ANON_KEY=stub \
go run ./cmd/server
Environment
| Variable | Required | Purpose |
|---|---|---|
PORT |
no (default 8080) | HTTP listen port |
SUPABASE_URL |
yes | Supabase project URL (auth) |
SUPABASE_ANON_KEY |
yes | Supabase anon key (auth) |
DATABASE_URL |
for Aktenverwaltung | Direct Postgres conn for migrations + Akten/Fristen/Termine services. Knowledge-platform endpoints (Kostenrechner, Glossar, Links, Gebührentabellen, Checklisten, Gerichte, Downloads) don't use the pool and work without it. Aktenverwaltung endpoints return 503 if unset. |
CALDAV_ENCRYPTION_KEY |
for CalDAV sync | 32-byte AES-256 key, base64-encoded. Encrypts CalDAV passwords at rest (AES-GCM). Server fails fast on malformed key; if unset, CalDAV is silently disabled (/api/caldav-config returns 501). Generate with openssl rand -base64 32. |
GITEA_TOKEN |
optional | Gitea API token for the private file proxy (Downloads) |
ANTHROPIC_API_KEY |
not used today | Reserved for Phase H (AI Frist-Extraktion). Currently deferred — do not set. |
Development
make build # compile backend + frontend
make test # run Go tests + frontend tests
go build ./... # backend only
go vet ./... # static checks
go test ./... # Go tests
bun run build # frontend only (produces frontend/dist/)
Project layout:
cmd/server/ # main entry point
internal/db/ # sqlx pool + embedded migrations
internal/services/ # AkteService, FristService, TerminService, CalDAV, ...
internal/handlers/ # HTTP handlers (pages + API)
internal/calc/ # Kostenrechner / Fristenrechner logic
frontend/ # Bun + TSX source; static HTML output to frontend/dist/
docs/ # design docs + this roadmap
Deploy
Push to main → Gitea webhook → Dokploy auto-deploy on mlake.
Project status (April 2026)
Phases A–G, I and J of the KanzlAI integration are shipped: schema, services, Akten, Fristen, Termine + CalDAV, Dashboard, Notizen service + UI (commit 5a9f8e5, 2026-04-17), and instanceable Checklisten (migration 014). Phase H (AI Frist extraction) is deferred pending a reversal of the "no Anthropic API" decision; the Dokumente tab on Akten detail is hidden until that lands. KanzlAI infra retirement (Dokploy shutdown, kanzlai schema drop, Gitea archive) is still pending.
See docs/feature-roadmap.md for the full backlog and docs/design-kanzlai-integration.md for the integration design.