mAi b8709b903d feat(docforge): slice 5 — docforge-editor pkg + variable catalogue SSOT (t-paliad-349)
Establish the shared frontend editor package and make the Go resolvers the
single source of truth for variable labels.

Go — catalogue SSOT:
  - VariableResolver gains Keys() []VariableKey; ResolverSet gains
    Catalogue(). The 7 submission resolvers implement Keys() with the
    bilingual labels ported from the TS VARIABLE_LABELS table (incl. the
    legacy rule.* aliases). Keys() is entity-independent, so
    SubmissionVariableCatalogue() builds a metadata-only ResolverSet.
  - GET /api/docforge/variables serves the catalogue (auth-gated, static).
  - Tests: docforge ResolverSet (BuildBag merge + Catalogue order) and the
    submission catalogue integrity (no dupes, labels present, spot-checks).

Frontend — frontend/src/lib/docforge-editor/ (new shared package):
  - dom.ts: escapeHtml + cssEscape (pure), with bun tests. Dedupes the two
    identical escapeHtml/escapeHTML copies + the cssEscape copy that lived
    in the submission editor.
  - catalogue.ts: fetchVariableCatalogue() + labelMap() — the client for
    the Go catalogue.
  - submission-draft.ts now imports escapeHtml/cssEscape from the lib and
    fetches the catalogue on boot into state.varLabels (labelFor reads it,
    falling back to the raw key if the fetch fails — graceful degrade). The
    hardcoded VARIABLE_LABELS table is removed; VARIABLE_GROUPS stays
    (presentation: which keys to show + how to section them, legitimately
    frontend).

Scope note: the DOM-coupled editor plumbing (wireDraftVars/focus
preservation/autosave debounce) is extracted in slice 6 alongside its first
reuse — the authoring page — rather than speculatively now (extract with the
consumer; same principle as slices 2-3). Slice 5 lands the pure utilities +
the catalogue, which the slice-6 authoring palette consumes.

Verification: go build/vet/test green (Go files gofmt-clean; handlers.go
pre-existing drift, added region clean); bun run build.ts clean;
bun test 274/274 (incl. 5 new docforge-editor tests).

m/paliad#157
2026-05-29 15:50:42 +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%