mAi a6d0acbcb4 mAi: #111 - t-paliad-279 — Verfahrensablauf form reorder + project auto-fill chip
Reorder Verfahrensablauf 'Browse a proceeding' so the user-input flow
matches the importance hierarchy: proceeding-type → side → appellant →
date / court / flags. Side was previously below the date input; it is
the most-defining input after proceeding-type, so it belongs above.

- frontend/src/verfahrensablauf.tsx: move .verfahrensablauf-perspective
  block above .date-input-group inside step-2. Wrap the side radio
  cluster in #side-radio-cluster and add a sibling #side-chip (hidden by
  default) that the client swaps in when a project pre-fills the side.
  Add a 1px divider between perspective and date-input groups. Update
  step-2 heading from "Ausgangsdatum eingeben" → "Perspektive und Datum"
  to honestly describe both controls now under the heading.

- frontend/src/client/verfahrensablauf.ts: read ?project=<id> on init,
  fetch /api/projects/<id>, map our_side onto the side axis (mirrors
  fristenrechner.ts ourSideToPerspective: claimant/applicant/appellant
  → claimant, defendant/respondent → defendant, else null) and render
  the side row as a read-only chip + "Andere Seite wählen" override
  link. The chip respects ?side= as an explicit user pick — URL wins
  over project auto-fill, same precedence as fristenrechner. Override
  swaps back to the radio cluster and drops ?project= from the URL.
  Side-chip label is language-aware via onLangChange.

- frontend/src/styles/global.css: .verfahrensablauf-step2-divider
  (1px hr between perspective and date blocks); .side-chip / -tag /
  -value / -override styles mirror .proceeding-summary's chip look so
  the two read as the same visual family.

- frontend/src/client/i18n.ts + i18n-keys.ts: 3 new keys
  (deadlines.step2.perspective, deadlines.side.from_project,
  deadlines.side.override) in DE + EN.

URL state stays backward-compatible: ?side= and ?appellant= survive
the reorder unchanged. Adding ?project= opts in to auto-fill; without
it the page behaves identically to before.

No backend / projection logic change.
2026-05-25 16:51:27 +02:00

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), sqlx for DB access
  • Migrations: golang-migrate/migrate/v4 with SQL files embedded via embed.FS; applied at server startup before the HTTP listener binds
  • Database: youpc Supabase Postgres, paliad schema. Office-scoped RLS (paliad.can_see_akte(akte_id)) — see docs/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_Zzyo on 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 AG, 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.

Description
patholo.de — Patent knowledge sharing platform for HL colleagues
Readme 14 MiB
Languages
Go 49.9%
TypeScript 38%
CSS 6.7%
PLpgSQL 4.7%
HTML 0.3%
Other 0.4%