mAi 07acf7b4a2
Some checks failed
Paliad CI gate / build (push) Has been cancelled
Paliad CI gate / test-go (push) Has been cancelled
Paliad CI gate / deploy (push) Has been cancelled
feat(litigationplanner): Berufung unification — one upc.apl + 5 appeal_target chips (Slice B1, m/paliad#124 §18.1)
Collapses the 3 UPC appeal proceeding_types (upc.apl.merits 7 rules,
upc.apl.cost 2, upc.apl.order 7 = 16 total across 3 codes) into ONE
unified upc.apl proceeding type + a per-rule applies_to_target[]
discriminator. The verfahrensablauf picker now shows one "Berufung"
tile; after picking it, the user selects which decision the appeal is
directed AT via a 5-chip group (Endentscheidung / Kostenentscheidung /
Anordnung / Schadensbemessung / Bucheinsicht) and the engine filters
rules whose applies_to_target contains the picked slug.

m's 2026-05-26 decision: Schadensbemessung-as-appeal is a NEW first-
class target with its OWN rule set (no shared inheritance from
merits). The 5 enum values are all defined + addressable; for now
schadensbemessung and bucheinsicht return empty timelines until rules
are seeded in a follow-up slice (likely via /admin/rules or pairing
with t-paliad-193 orphan-concept-seed).

Migration 134 (additive only):
  - ADD proceeding_types.appeal_target text (CHECK on 5 slugs OR NULL)
  - ADD deadline_rules.applies_to_target text[] (CHECK each element
    in the 5 slugs)
  - INSERT the unified upc.apl row (inherits sort/color from
    upc.apl.merits)
  - Audit-first RAISE NOTICE pass listing every row about to be
    touched + a post-migration sanity check
  - Reassign rule rows: merits → applies_to_target={endentscheidung},
    cost → {kostenentscheidung}, order → {anordnung}
  - Archive (is_active=false, NOT DELETE) the 3 old proceeding_types
    so historical FKs stay intact
  - Down migration restores is_active=true on the 3 old types, points
    rules back by their applies_to_target stamp, drops the unified
    row, drops both columns. Safe.

Package additions (pkg/litigationplanner):
  - AppealTarget* constants + AppealTargets[] ordered list +
    IsValidAppealTarget(s) predicate (silent no-op on unknown slugs
    so a stale frontend chip doesn't break the render)
  - ProceedingType.AppealTarget *string field (top-level marker;
    NULL on non-appeal proceedings)
  - Rule.AppliesToTarget pq.StringArray field (per-row applies-to set)
  - CalcOptions.AppealTarget string (engine filter — when set,
    keeps only rules whose AppliesToTarget contains the slug)

Engine filter runs after ApplyRuleOverrides but before the rule walk
so the existing condition_expr / spawn / appellant-context machinery
operates on the filtered subset transparently.

paliad-side wiring:
  - deadline_rule_service.go: ruleColumns + proceedingTypeColumns
    extended to scan the new columns
  - handlers/fristenrechner.go: AppealTarget JSON field on the
    request payload, threaded into CalcOptions

Frontend (verfahrensablauf surface only):
  - Single "Berufung" tile replaces the 3 separate Berufung tiles
  - New 5-chip appeal-target row, shown only when upc.apl is picked
  - URL state ?target=<slug>; default endentscheidung when none set
  - APPELLANT_AXIS_PROCEEDINGS updated: upc.apl.* (3 entries) →
    upc.apl (1 entry)
  - i18n keys (DE + EN) for the new tile + the 5 chip labels +
    the "Worauf richtet sich die Berufung?" / "Appeal against:" prompt
  - calculateDeadlines threads appealTarget through to the API

Acceptance:
  - go build clean, go test all green (existing test suite — no new
    tests on the engine filter as a follow-up; the migration's
    sanity-check DO block guards the rule-reassignment count)
  - Live audit before drafting confirmed: 3 active UPC appeal
    proceeding_types, 16 rules total, primary_party already conforms
    to 4-value vocab on all proceeding-bound rules
2026-05-26 13:49:03 +02:00

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%