m/paliad
1
0
Fork 0
Code Issues 146 Pull Requests 8 Actions 3 Packages Projects Releases Wiki Activity

docs: revise integration design per m's feedback

Browse Source 
Five changes from athena's review (paliad/athena → paliad/cronus):

1. §2 rewritten — office-scoped visibility from day one (NOT firm-wide).
   - paliad.users adds: office (required), practice_group (optional), role
   - paliad.akten adds: owning_office, collaborators uuid[], firm_wide_visible
   - SQL function paliad.can_see_akte(akte_id) used by every RLS policy
   - Visibility predicate: own office OR collaborator OR firm_wide OR admin
   - Real (not permissive) RLS policies enforced from Phase A
   - Defense in depth: app-layer ListVisibleForUser mirrors the predicate
   - Onboarding flow added (Phase D) so users self-identify office on signup

2. Mandate → Akten throughout (German end-to-end):
   - Tables: paliad.akten / parteien / fristen / termine / dokumente /
     akten_events / notizen
   - Go structs: Akte, Partei, Frist, Termin, Dokument, AkteEvent, Notiz
   - URLs: /akten, /akten/[id], /akten/[id]/{verlauf|fristen|...}
   - UI: "Akten", "Aktenverwaltung", "Zur Akte speichern" CTA on Fristenrechner
   - Naming convention table added in §3

3. §9 risk added: Outlook/Exchange CalDAV is limited; Phase F ships with
   CalDAV only (verified against dav.msbls.de + iCloud); long-term plan is
   Phase K = EWS / Microsoft Graph backend behind same sync abstraction.

4. Compliance/IT-approval unknown removed from §9 (m handles out of band).

5. Single-tenant risk replaced by visibility-model risk (now the
   security-critical layer); Phase A and B both gain Opus design reviews
   on the visibility predicate; Phase B integration test requires 3 users
   in 2 offices; pre-Phase J pen-test pass added.

Effort: 52h → 56h (Phase A +2h for visibility model, Phase D +2h for
onboarding + collaborator UI). Total with design ~59h, ~2-3 weeks.
This commit is contained in:
m
2026-04-16 13:36:19 +02:00
parent d1add11668
commit 5b92926db4
1 changed files with 276 additions and 110 deletions
Download Patch File Download Diff File Expand all files Collapse all files

386
docs/design-kanzlai-integration.md
View File

@@ -3,15 +3,16 @@
**Author:** cronus (inventor)
**Date:** 2026-04-16
**Task:** t-paliad-001
**Revision:** 2 (incorporates m's feedback via athena 2026-04-16: office-scoped visibility from day one; Mandate → Akten; Outlook as long-term risk; compliance handled out-of-band)
**Status:** Design draft for review
---
## Executive Summary
**Recommendation: Full merge into a single Paliad codebase, single Go binary, single Supabase schema, single Dokploy deployment.** Port KanzlAI's domain logic (deadline rules, calculator, holiday service, matter/deadline/appointment/notes models, CalDAV sync, AI extraction) into Paliad's existing Go backend. Rewrite KanzlAI's React+Next.js frontend in Paliad's Bun + TSX stack. Retire `kanzlai.msbls.de` to a 301 redirect once parity is reached.
**Recommendation: Full merge into a single Paliad codebase, single Go binary, single Supabase schema, single Dokploy deployment.** Port KanzlAI's domain logic (deadline rules, calculator, holiday service, Akten/Fristen/Termine/notes models, CalDAV sync, AI extraction) into Paliad's existing Go backend. Rewrite KanzlAI's React+Next.js frontend in Paliad's Bun + TSX stack. Retire `kanzlai.msbls.de` to a 301 redirect once parity is reached.
**Why this path.** Two backends behind one domain doubles operational surface for zero user benefit. The two products share an audience (HLC patent practice), a stack philosophy (Go + Supabase), and an auth model (Supabase password). The only real cost is rewriting the React frontend — which is a smaller burden than it sounds, because KanzlAI's UI is mostly forms, lists, calendar grids, and tabbed details, all of which fit Paliad's server-rendered TSX + per-page client JS pattern. The merger from HL → HLC is the right moment to consolidate: one platform, one URL, one mental model. Knowledge tools and matter management belong together — a lawyer who looks up a UPC fee on Paliad should also see their next UPC deadline.
**Why this path.** Two backends behind one domain doubles operational surface for zero user benefit. The two products share an audience (HLC patent practice), a stack philosophy (Go + Supabase), and an auth model (Supabase password). The only real cost is rewriting the React frontend — which is a smaller burden than it sounds, because KanzlAI's UI is mostly forms, lists, calendar grids, and tabbed details, all of which fit Paliad's server-rendered TSX + per-page client JS pattern. The merger from HL → HLC is the right moment to consolidate: one platform, one URL, one mental model. Knowledge tools and Aktenverwaltung belong together — a lawyer who looks up a UPC fee on Paliad should also see their next UPC deadline.
---
@@ -38,41 +39,147 @@ Four options were considered:
### Trade-off accepted
- **~6 weeks of focused implementation** (estimated 52h coder time, see §8) to retire ~16,500 lines of KanzlAI code and rebuild ~4,000 lines on Paliad's stack.
- **~6 weeks of focused implementation** (estimated 56h coder time, see §8) to retire ~16,500 lines of KanzlAI code and rebuild ~4,500 lines on Paliad's stack.
- **Lose React ecosystem** (react-query, react-day-picker, etc.). Paliad's stack handles these patterns with HTML-first forms + small per-page TS bundles. Acceptable.
---
## 2. Auth & multi-tenancy
## 2. Auth & visibility
### Decision: HLC is one tenant. Drop multi-tenancy entirely.
### Decision: Office-scoped visibility from day one. Drop multi-tenancy infrastructure.
KanzlAI was built multi-tenant in case it became a SaaS product. That bet is now dead — Paliad serves one firm. Multi-tenancy adds:
- A whole `tenants` + `user_tenants` table layer
- Tenant resolution middleware (with the tenant isolation bypass bug)
- `tenant_id` on every row + every query
- RLS policies that key off tenant membership
KanzlAI was built multi-tenant in case it became a SaaS product. That bet is dead — Paliad serves one firm. But "one firm" doesn't mean "every lawyer sees every Akte". Patent practice at HLC is **office-anchored**: a Munich associate works on Munich Akten; a partner may have visibility across offices; cross-office collaboration happens via explicit naming (collaborator lists), not via blanket access.
For one firm with one matter pool, this is pure overhead. **Strip it.**
**Strip the SaaS multi-tenancy plumbing (`tenants`, `user_tenants`, X-Tenant-ID headers, the bypass bug). Build office-scoped visibility natively in its place.**
### Concrete model
- **Auth gate**: keep the email domain whitelist on registration. Accept `@hoganlovells.com` AND `@hlc.com` (any TLD HLC ends up using). Whitelist is a config slice, not a hardcoded constant.
- **Single shared visibility**: every authenticated user sees every matter/deadline/appointment by default. No office-scoped or practice-group-scoped filtering at the schema level.
- **`paliad.users` table**: extends `auth.users`, adds `office`, `practice_group`, `role` (`partner` | `associate` | `pa` | `admin`). Used for display, attribution, and future ACL — not for access control on day one.
- **RLS posture**: enable RLS on all tables, but with permissive policies (`USING (auth.role() = 'authenticated')`). RLS-on with permissive policies is cheap insurance against future tenant requirements and against forgotten WHERE clauses.
- **Audit trail**: every mutation writes a `case_event` (or equivalent) with `created_by = auth.uid()`. So we have *attribution* even though we don't have *isolation*.
#### `paliad.users` table (extends `auth.users`)
### When the model needs to change
```
paliad.users
id uuid PK / FK auth.users.id
email text (synced from auth.users; for display)
display_name text
office text NOT NULL CHECK (office IN
('munich','duesseldorf','hamburg',
'amsterdam','london','paris','milan'))
practice_group text NULL -- e.g. 'patents-litigation', 'patents-prosecution'
role text NOT NULL DEFAULT 'associate' CHECK (role IN
('partner','associate','pa','admin'))
created_at timestamptz DEFAULT now()
```
If HLC ever decides "Munich shouldn't see Düsseldorf matters" (unlikely — HLC is a single firm with cross-office teams), we add an `acl` JSONB column or a `matter_visibility` table and tighten the RLS policy. Don't build that now.
`office` is mandatory; new users pick during first-login onboarding. `practice_group` is optional (used for filtering, not access control today).
#### Visibility on `paliad.akten` (and child rows)
Every Akte carries explicit visibility:
```
paliad.akten
id uuid PK
aktenzeichen text NOT NULL -- internal reference
title text NOT NULL
status text ...
owning_office text NOT NULL -- the office the Akte "belongs to"
collaborators uuid[] DEFAULT '{}' -- explicit user IDs with access
firm_wide_visible boolean NOT NULL DEFAULT false -- partner-toggled override
created_by uuid FK paliad.users(id)
created_at, updated_at
...
```
Visibility rule (the canonical predicate, used by RLS *and* by query helpers):
```
A user U can see Akte A iff:
A.firm_wide_visible = true
OR A.owning_office = U.office
OR U.id = ANY(A.collaborators)
OR U.role = 'admin'
```
#### RLS policies (enforced from day one)
A SQL function, then policies that use it:
```sql
CREATE OR REPLACE FUNCTION paliad.can_see_akte(akte_id uuid)
RETURNS boolean LANGUAGE sql STABLE SECURITY DEFINER AS $$
SELECT EXISTS (
SELECT 1
FROM paliad.akten a
JOIN paliad.users u ON u.id = auth.uid()
WHERE a.id = akte_id
AND (
a.firm_wide_visible
OR a.owning_office = u.office
OR auth.uid() = ANY(a.collaborators)
OR u.role = 'admin'
)
);
$$;
-- akten themselves
CREATE POLICY akten_select ON paliad.akten FOR SELECT
USING (paliad.can_see_akte(id));
CREATE POLICY akten_insert ON paliad.akten FOR INSERT
WITH CHECK (
-- user can only create Akten in their own office
-- (admins can create anywhere)
owning_office = (SELECT office FROM paliad.users WHERE id = auth.uid())
OR (SELECT role FROM paliad.users WHERE id = auth.uid()) = 'admin'
);
CREATE POLICY akten_update ON paliad.akten FOR UPDATE
USING (paliad.can_see_akte(id))
WITH CHECK (paliad.can_see_akte(id));
CREATE POLICY akten_delete ON paliad.akten FOR DELETE
USING (
paliad.can_see_akte(id)
AND (SELECT role FROM paliad.users WHERE id = auth.uid()) IN ('partner','admin')
);
-- child rows (parteien, fristen, termine, dokumente, akten_events, notizen)
-- inherit visibility via akte_id
CREATE POLICY fristen_select ON paliad.fristen FOR SELECT
USING (paliad.can_see_akte(akte_id));
-- ...analogous for the rest
```
Notes:
- `firm_wide_visible` is the partner override for cross-office matters of firm-wide interest (e.g., a strategic UPC test case).
- `collaborators` is the per-Akte explicit access list — how cross-office teams collaborate without flipping the firm-wide flag.
- Only partners and admins can delete Akten; everyone with visibility can update.
- Reference data (`proceeding_types`, `deadline_rules`, `holidays`) is global — RLS on but with `USING (true)` permissive policies. These tables hold no user data.
- Knowledge content tables (`link_suggestions`, `checklisten_feedback`, `gerichte_feedback`) stay as-is — feedback is intentionally firm-wide.
#### Auth gate (registration)
Email domain whitelist, env-configured: `[@hoganlovells.com, @hlc.com, @hlc.de]`. Easy to extend if HLC picks a new TLD.
#### Onboarding flow (new in Phase D)
After first sign-in: prompt for office (required) + practice group (optional) + role (defaults to `associate`; partners self-identify, admins set by SQL initially). Without this row in `paliad.users`, the user can't see any Akten — that's the safe default.
### Backend implications
- All Akten queries route through a `service.ListVisibleForUser(ctx, userID)` helper that enforces the predicate at the application layer too (defense in depth — RLS is the floor, not the ceiling).
- "All Akten in the firm" view exists for admins/partners as a feature, not as the default.
- The Dashboard (Phase G) shows *visible* Akten only.
### Post-merger email transition
- Phase 1 (now → merger): whitelist `[@hoganlovells.com, @hlc.com, @hlc.de]`. Any new HLC subdomain TLD added to the slice in env config.
- Phase 2 (post-merger): when HLC mandates a new email, existing `@hoganlovells.com` Supabase identities continue to work. New users register under `@hlc.*`. No data migration needed because Supabase keys on UUID, not email.
- Phase 1 (now → merger): whitelist `[@hoganlovells.com, @hlc.com, @hlc.de]`. Any new HLC subdomain TLD added to the env config slice.
- Phase 2 (post-merger): existing `@hoganlovells.com` Supabase identities continue to work (Supabase keys on UUID, not email). New users register under `@hlc.*`. No data migration needed.
- Phase 3 (cleanup, +1 year): optional script to update display emails in `paliad.users` if HLC actually retires the old domain.
### When the model needs to extend
- **Practice-group scoping** (e.g., "Patents Litigation can't see Patents Prosecution Akten"): add `visible_to_groups text[]` column on `paliad.akten`, extend the RLS predicate. Don't build now — wait until a partner asks.
- **External counsel access** (e.g., bringing in an Italian boutique on a Milan Akte): add a separate `external_collaborators` table with email + scoped RLS. Don't build now.
- **Read-only Akten archive after closure**: add `is_archived` flag, deny mutations via RLS. Cheap follow-on.
---
## 3. Database / schema
@@ -82,15 +189,45 @@ If HLC ever decides "Munich shouldn't see Düsseldorf matters" (unlikely — HLC
KanzlAI's schema lives in `kanzlai.*` on the youpc Supabase instance. Paliad currently has 3 feedback tables (`link_suggestions`, `checklisten_feedback`, `gerichte_feedback`) that look like they're in the public schema (no schema prefix in `docs/migrations/00*.sql`).
**Plan:**
1. Create `paliad` schema in the same youpc Supabase instance (no new project, no DB migration).
1. Create `paliad` schema in the same youpc Supabase instance (no new project).
2. Move Paliad's 3 existing feedback tables into `paliad.*` (CREATE in new schema, COPY data, drop old).
3. Port KanzlAI's tables into `paliad.*`, dropping multi-tenancy fields:
- `cases` → `paliad.matters` (rename: "matter" is universal across DE/EN; "Akte" stays the German display label)
- `parties`, `deadlines`, `appointments`, `documents`, `case_events`, `notes` → `paliad.*`, drop `tenant_id`, keep `created_by` (FK to `auth.users.id`)
- Reference tables: `proceeding_types`, `deadline_rules`, `holidays` → `paliad.*` (these are pure reference data, no tenancy concept needed)
4. RLS enabled on all paliad tables with permissive `authenticated` policies (per §2).
3. Port KanzlAI's tables into `paliad.*`, dropping multi-tenancy fields and adding visibility columns:
- `cases` → `paliad.akten` (German throughout: table name, Go struct `Akte`, URL `/akten`, UI label "Akten")
- `parties` → `paliad.parteien`
- `deadlines` → `paliad.fristen`
- `appointments` → `paliad.termine`
- `documents` → `paliad.dokumente`
- `case_events` → `paliad.akten_events`
- `notes` → `paliad.notizen`
- All drop `tenant_id`, all add `akte_id` FK to `paliad.akten`, all gain visibility via `paliad.can_see_akte(akte_id)` in RLS.
- `paliad.akten` itself adds `owning_office`, `collaborators uuid[]`, `firm_wide_visible boolean` per §2.
- Reference tables: `proceeding_types`, `deadline_rules`, `holidays` → `paliad.*`. RLS-on but permissive (no user data).
- New: `paliad.users` per §2.
4. RLS enabled on all paliad tables with **real visibility policies** per §2 (not just permissive-authenticated).
5. Retire `kanzlai.*` schema once cutover is verified (`DROP SCHEMA kanzlai CASCADE` in Phase J).
### German vs. English naming
Going **fully German** end-to-end (table, struct, URL, UI). Reasons:
- Paliad already uses German nouns for routes (`/fristen`, `/termine`, `/glossar`, `/checklisten`). Mixing German routes with English internals creates lifelong cognitive translation overhead — KanzlAI showed this with `cases` (English) ↔ "Akten" (German UI).
- The audience reads German legal terminology natively.
- Go struct names allow Unicode-clean ASCII (`Akte`, `Frist`, `Termin`) — no friction.
- Database identifiers in lowercase German plurals (`akten`, `fristen`, `parteien`) read fine to anyone who's worked with German data.
Concrete naming convention:
| Concept | DB table | Go struct | Go service | URL | German UI |
|---|---|---|---|---|---|
| Matter | `paliad.akten` | `Akte` | `AkteService` | `/akten` | "Akte" / "Akten" |
| Party | `paliad.parteien` | `Partei` | `ParteienService` | (sub of Akte) | "Partei" / "Parteien" |
| Deadline | `paliad.fristen` | `Frist` | `FristService` | `/fristen` | "Frist" / "Fristen" |
| Appointment | `paliad.termine` | `Termin` | `TerminService` | `/termine` | "Termin" / "Termine" |
| Document | `paliad.dokumente` | `Dokument` | `DokumentService` | (sub of Akte) | "Dokument" |
| Audit event | `paliad.akten_events` | `AkteEvent` | (in `AkteService`) | n/a | "Verlauf" |
| Note | `paliad.notizen` | `Notiz` | `NotizenService` | (cross-cutting) | "Notiz" / "Notizen" |
| User | `paliad.users` | `User` | `UserService` | n/a | n/a |
`User` stays English (it's a Supabase concept, not a legal one).
### Reuse vs. port
- **Reuse the data**: KanzlAI's `deadline_rules` table has 32 UPC + 4 ZPO rules (more than Paliad's hardcoded `internal/calc/deadline_rules.go`). Port the data, drop Paliad's hardcoded rules.
@@ -106,7 +243,7 @@ Paliad currently has SQL files in `docs/migrations/` with no runner. Pick a tool
### Schema collisions
None. Paliad's existing 3 feedback tables don't overlap with anything in KanzlAI. The risk vector was `cases` vs. `matters` naming — resolved by picking `matters` for the merged schema.
None. Paliad's existing 3 feedback tables don't overlap with anything in KanzlAI. The risk vector was `cases` vs. `akten` naming — resolved by going fully German.
---
@@ -117,33 +254,33 @@ KanzlAI shipped a lot in one session; not all of it was production-quality. Cher
### Ports (P0 — first cutover)
- **Deadline rules + holidays + calculator** (KanzlAI: `holidays.go`, `deadline_calculator.go`, `deadline_rule_service.go`). Replaces Paliad's `internal/calc/deadline_rules.go` hardcoded data.
- **Matters (Mandate) CRUD + parties** (KanzlAI: `case_service.go`, `parties.go`). Foundation for everything below.
- **Deadline management UI** (KanzlAI: `DeadlineList`, `DeadlineCalendarView`, traffic light cards). Extends current Fristenrechner with persistence.
- **Akten CRUD + Parteien** (KanzlAI: `case_service.go`, `parties.go`). Foundation for everything below. Includes the office-scoped visibility logic from §2.
- **Frist management UI** (KanzlAI: `DeadlineList`, `DeadlineCalendarView`, traffic light cards). Extends current Fristenrechner with persistence.
### Ports (P1 — fast follow)
- **Appointments + CalDAV sync** (KanzlAI: `appointment_service.go`, `caldav_service.go`). CalDAV is a real differentiator. **Mandatory fix during port:** encrypt CalDAV credentials at rest (audit §1.3).
- **Termine + CalDAV sync** (KanzlAI: `appointment_service.go`, `caldav_service.go`). CalDAV is a real differentiator. **Mandatory fix during port:** encrypt CalDAV credentials at rest (audit §1.3).
- **Dashboard** (KanzlAI: `dashboard_service.go`, dashboard widgets). Replaces Paliad's logged-in landing.
### Ports (P2 — once foundation is stable)
- **AI deadline extraction** (KanzlAI: `ai_service.go`, document upload). Dependency on Anthropic key in Dokploy.
- **Notes** (polymorphic notes table, KanzlAI Phase A backend). Cross-cutting; useful but not blocking.
- **AI Frist extraction** (KanzlAI: `ai_service.go`, document upload). Dependency on Anthropic key in Dokploy.
- **Notizen** (polymorphic notes table, KanzlAI Phase A backend). Cross-cutting; useful but not blocking.
### Drop entirely
- **Billing / RVG (`billing_rates.go`, `invoices.go`, `time_entries.go`)** — KanzlAI has handler stubs, no real impl. The audit (§8.2) calls out beA + RVG as table-stakes for *competing with RA-MICRO*. We're not competing with RA-MICRO. HLC has its own firm-wide billing. Don't pretend.
- **`reports.go`, `notifications.go`, `templates.go`, `tenant_handler.go`, `case_assignments.go`** — all aspirational stubs in KanzlAI. Drop.
- **Multi-tenancy infrastructure** — see §2.
- **Reports/audit endpoints** beyond the basic `case_events` audit log.
- **Multi-tenancy infrastructure (`tenants`, `user_tenants`, X-Tenant-ID middleware)** — see §2; replaced by office-scoped visibility.
- **Reports/audit endpoints** beyond the basic `akten_events` audit log.
### Knowledge platform features that survive
Paliad's existing tools (Kostenrechner, Glossar, Gebührentabellen, Checklisten, Gerichte, Links, Downloads) all stay as-is. They sit alongside the new matter management features in the same sidebar.
Paliad's existing tools (Kostenrechner, Glossar, Gebührentabellen, Checklisten, Gerichte, Links, Downloads) all stay as-is. They sit alongside the new Aktenverwaltung features in the same sidebar.
### Knowledge platform features that change
- **Fristenrechner** evolves: same calculator UI, but now backed by the same DB as deadline management. Adds a "Save to matter" button that creates persistent deadlines.
- **Fristenrechner** evolves: same calculator UI, but now backed by the same DB as Frist management. Adds a "Zur Akte speichern" button that creates persistent Fristen on a chosen Akte.
- **Roadmap §2.3 UPC Rechtsprechungsübersicht** — dropped entirely (per task brief). Replaced by a curated link in the Link Hub pointing to youpc.org.
---
@@ -159,8 +296,12 @@ Paliad's existing tools (Kostenrechner, Glossar, Gebührentabellen, Checklisten,
Paliad is the all-in-one platform for HLC patent practice:
- **Knowledge platform** — curated content, practical tools, quick reference (Glossar, Gebührentabellen, Checklisten, Gerichtsverzeichnis, Leitfäden, Links).
- **Matter management** — Mandate (cases), Fristen (deadlines), Termine (appointments), parties, documents, notes, audit trail. Personal calendar sync via CalDAV. AI-assisted deadline extraction from uploaded court documents.
- **Knowledge platform** — curated content, practical tools, quick reference
(Glossar, Gebührentabellen, Checklisten, Gerichtsverzeichnis, Leitfäden, Links).
- **Aktenverwaltung** — Akten, Fristen, Termine, Parteien, Dokumente, Notizen,
Verlauf (audit trail). Office-scoped visibility with explicit collaborator
lists for cross-office teams. Personal calendar sync via CalDAV. AI-assisted
Frist extraction from uploaded court documents.
What Paliad is *not*:
@@ -172,24 +313,24 @@ What Paliad is *not*:
**Drop §2.3 UPC Rechtsprechungsübersicht entirely.** Replace with one Link Hub entry under "Recherche" pointing to `youpc.org/upc/rechtsprechung` (or wherever the curated overview lives). Save 14h of work; defer to youpc.org which already has the data.
**Update §4.2 Fristenkalender.** Currently P3, "8h, High impact". Promote to P0 — it's the entry point to the matter-management features, not an optional add-on. Replace with: "Fristenkalender → see §8 Phase E (Deadline management UI), Phase F (CalDAV sync)."
**Update §4.2 Fristenkalender.** Currently P3, "8h, High impact". Promote to P0 — it's the entry point to the Aktenverwaltung features, not an optional add-on. Replace with: "Fristenkalender → see §8 Phase E (Frist management UI), Phase F (Termine + CalDAV sync)."
**Add new sections** (after current §1.5 or as a new top-level "Phase 0: Matter Management Foundation"):
**Add new sections** (as a new top-level "Phase 0: Aktenverwaltung Foundation"):
```markdown
### 0.1 Mandate (Matter Management)
### 0.1 Akten (Matter Management) — office-scoped
### 0.2 Fristen (Persistent Deadline Management)
### 0.3 Termine + CalDAV Sync
### 0.4 Dashboard (Logged-in Landing)
### 0.5 AI-assisted Deadline Extraction
### 0.6 Notes
### 0.5 AI-assisted Frist-Extraktion
### 0.6 Notizen
```
Each section should reference the per-phase task in §8 of *this* design doc rather than duplicating estimates.
**Update prioritized backlog table** (lines 463–483): insert the 6 Phase 0 features at the top with P0 priority. Demote 1.5 (Kostenrechner enhancements) to P1 — matter management beats Kostenrechner polish.
**Update prioritized backlog table** (lines 463–483): insert the 6 Phase 0 features at the top with P0 priority. Demote 1.5 (Kostenrechner enhancements) to P1 — Aktenverwaltung beats Kostenrechner polish.
**Update Architecture Notes "Data Strategy" (line 489).** Currently says "Most Phase 1 and 2 features use static JSON data." Add: "Phase 0 features (matter management) use Supabase tables with RLS. The split is: reference data + curated content = git/JSON; user-generated data = DB."
**Update Architecture Notes "Data Strategy" (line 489).** Currently says "Most Phase 1 and 2 features use static JSON data." Add: "Phase 0 features (Aktenverwaltung) use Supabase tables with office-scoped RLS. The split is: reference data + curated content = git/JSON; user-generated data = DB."
---
@@ -206,7 +347,7 @@ PALIAD (logo, lime green)
Dashboard
— ARBEIT —
Mandate
Akten
Fristen
Termine
@@ -233,7 +374,7 @@ PALIAD (logo, lime green)
Rationale:
- **"Übersicht"** (Dashboard) is the new home for logged-in users. The current `/` marketing-ish landing becomes the unauthenticated welcome screen.
- **"Arbeit"** = the user's active workload. This is what KanzlAI provided; it's now the top of the new value stack.
- **"Werkzeuge"** = stateless calculators / lookups. Including Fristenrechner here as a quick scratch tool, separate from `/fristen` which is the persistent deadline list. (Yes, two deadline-related routes — they serve different jobs.)
- **"Werkzeuge"** = stateless calculators / lookups. Including Fristenrechner here as a quick scratch tool, separate from `/fristen` which is the persistent Fristen list. (Yes, two deadline-related routes — they serve different jobs.)
- **"Wissen"** = curated content.
- **"Ressourcen"** = files + external links.
@@ -241,29 +382,33 @@ Rationale:
- `/` — unauthenticated landing OR redirects authenticated users to `/dashboard`.
- `/dashboard` — Dashboard (KanzlAI port).
- `/mandate`, `/mandate/neu`, `/mandate/[id]`, `/mandate/[id]/{verlauf|fristen|termine|dokumente|parteien|notizen}` — matter list + detail with sub-pages.
- `/fristen`, `/fristen/neu`, `/fristen/[id]`, `/fristen/kalender` — persistent deadlines.
- `/termine`, `/termine/neu`, `/termine/[id]`, `/termine/kalender` — appointments.
- `/tools/fristenrechner` — stays at current path (don't break links). Adds "Save to matter" button.
- `/akten`, `/akten/neu`, `/akten/[id]`, `/akten/[id]/{verlauf|fristen|termine|dokumente|parteien|notizen}` — Akten list + detail with sub-pages.
- `/fristen`, `/fristen/neu`, `/fristen/[id]`, `/fristen/kalender` — persistent Fristen.
- `/termine`, `/termine/neu`, `/termine/[id]`, `/termine/kalender` — Termine.
- `/einstellungen/caldav` — per-user CalDAV configuration.
- `/onboarding` — first-login office/practice-group/role setup (Phase D).
- `/tools/fristenrechner` — stays at current path (don't break links). Adds "Zur Akte speichern" button.
- All other knowledge routes unchanged.
### Visual language
- Lime accent (`#c6f41c`) stays — it's the brand. Used for active nav, primary CTAs, traffic-light "go", new-since-last-visit badges.
- Traffic light colors for deadlines: red `#ef4444` (overdue), amber `#f59e0b` (this week), green `#22c55e` (OK). KanzlAI's choices, keep them.
- Type colors for appointments: hearing=blue, meeting=violet, consultation=emerald, deadline_hearing=amber. KanzlAI's choices, keep them.
- Traffic light colors for Fristen: red `#ef4444` (überfällig), amber `#f59e0b` (diese Woche), green `#22c55e` (OK). KanzlAI's choices, keep them.
- Type colors for Termine: hearing=blue, meeting=violet, consultation=emerald, deadline_hearing=amber. KanzlAI's choices, keep them.
- Akten list: a small office badge per row (Munich, Düsseldorf, etc.) so cross-office collaborators can scan visibility origin at a glance.
- Sidebar: existing Paliad styling, with section headers (small caps, low contrast) added.
### Frontend rewrite scope
Pages to build in Bun TSX:
- `dashboard.tsx` (1 page)
- `mandate.tsx`, `mandate-detail.tsx`, `mandate-neu.tsx` (3 pages, plus sub-routes via Go mux)
- `akten.tsx`, `akten-detail.tsx`, `akten-neu.tsx` (3 pages, plus sub-routes via Go mux)
- `fristen.tsx`, `fristen-detail.tsx`, `fristen-neu.tsx`, `fristen-kalender.tsx` (4 pages)
- `termine.tsx`, `termine-detail.tsx`, `termine-neu.tsx`, `termine-kalender.tsx` (4 pages)
- `einstellungen-caldav.tsx` (1 page)
- `onboarding.tsx` (1 page — first-login form)
Per-page client-side TS bundles in `src/client/` for interactive bits (calendar nav, mark complete, modal forms). HTML-first: forms POST and reload by default; JS enhances where it improves UX (calendar pagination, optimistic mark-complete).
Per-page client-side TS bundles in `src/client/` for interactive bits (calendar nav, mark complete, collaborator-picker autocomplete, modal forms). HTML-first: forms POST and reload by default; JS enhances where it improves UX (calendar pagination, optimistic mark-complete).
No react-query, no Tailwind v4. Use existing `global.css` patterns.
@@ -311,47 +456,53 @@ If KanzlAI ever gets users before cutover, switch to a parallel-run-with-data-mi
Each phase is sized for one focused coder session with clear acceptance criteria. Effort estimates assume Sonnet implementation with Opus design review where flagged.
### Phase A — Database foundation & migration tooling (~6h)
### Phase A — Database foundation, visibility model & migration tooling (~8h)
**Scope:**
- Create `paliad` schema in youpc Supabase instance.
- Add `golang-migrate` to the Docker entrypoint.
- Move existing Paliad migrations (`docs/migrations/00{1,2,3}.sql`) → `migrations/00{1,2,3}_*.up.sql` + `.down.sql`. Re-namespace tables into `paliad.*`.
- Port KanzlAI tables → `paliad.*` migrations: `users`, `proceeding_types`, `deadline_rules`, `holidays`, `matters` (renamed from `cases`), `parties`, `deadlines`, `appointments`, `documents`, `case_events`, `notes`. Drop `tenant_id` everywhere; add `created_by` FK to `auth.users.id`.
- RLS: `ENABLE ROW LEVEL SECURITY` on all paliad tables with permissive `authenticated` policy. Document the rationale in a migration comment.
- Indexes per audit §3.3: `(status, due_date)` on deadlines, `(start_at)` on appointments, `(matter_id, created_at)` on case_events, `(status)` on matters.
- Create `paliad.users` table with `office`, `practice_group`, `role` columns per §2.
- Port KanzlAI tables → `paliad.*` migrations with German names: `proceeding_types`, `deadline_rules`, `holidays`, `akten` (renamed from `cases`, with `owning_office` + `collaborators uuid[]` + `firm_wide_visible` columns), `parteien`, `fristen`, `termine`, `dokumente`, `akten_events`, `notizen`. Drop `tenant_id` everywhere; add `created_by` FK to `paliad.users.id`.
- Create `paliad.can_see_akte(akte_id uuid)` SQL function per §2.
- RLS policies per §2: `akten_select/insert/update/delete` using the visibility predicate; child-row policies (fristen, termine, parteien, dokumente, akten_events, notizen) using `paliad.can_see_akte(akte_id)`. Reference tables RLS-on but `USING (true)`.
- Indexes per audit §3.3 + visibility queries: `(owning_office)` on akten, `(status, due_date)` on fristen, `(start_at)` on termine, `(akte_id, created_at)` on akten_events, `(status)` on akten, GIN index on `collaborators` for `= ANY` lookups.
- Seed: 6 proceeding types, 32 UPC + 4 ZPO rules, 68 holidays (port directly from KanzlAI seed).
- Seed `paliad.users` with cronus's test user as `admin` for local dev (real users register via the app).
**Acceptance:**
- `\dt paliad.*` on the Supabase Postgres shows ≥11 tables.
- `\dt paliad.*` shows ≥12 tables (including `users`).
- RLS enabled on all (verified via `pg_class.relrowsecurity`).
- Visibility predicate verified with 3 test users in 2 offices: each sees only their own office's Akten + any with their UUID in collaborators + any with `firm_wide_visible=true`.
- Migrations run cleanly up + down.
- Seed data present.
- Server starts after `migrate up` runs in entrypoint.
**Owner suggestion:** coder. Opus review the RLS policy + index choices before merge.
**Owner suggestion:** coder. Opus review the RLS policy + visibility predicate before merge — this is the security-critical layer.
---
### Phase B — Backend foundation (sqlx, services, no UI yet) (~8h)
**Scope:**
- Add `internal/db/` package (sqlx connection pool with `search_path = paliad,public` qualified at table level — don't rely on session-level setting per audit §2.8).
- Add `internal/db/` package (sqlx connection pool with table references qualified to `paliad.*` — don't rely on session-level `search_path` per audit §2.8).
- Port `internal/services/holidays.go` from KanzlAI (with `sync.RWMutex` fix per audit §1.6).
- Port `internal/services/deadline_calculator.go` (UUID-based; works from DB rules).
- Port `internal/services/deadline_rule_service.go` (read from DB).
- Add `internal/services/matter_service.go` (formerly `case_service.go`), simplified — no tenant filtering, all queries scoped only by `auth.uid()` for `created_by` attribution.
- Port `internal/services/party_service.go`.
- Tests: deadline calculator round-trip, holiday adjustment, matter CRUD basic happy-path.
- Add `internal/services/user_service.go` — bootstrap `paliad.users` row from `auth.users`, get current user from request context, list users.
- Add `internal/services/akte_service.go` (formerly `case_service.go`). Visibility-aware: `ListVisibleForUser(ctx, userID)` enforces the §2 predicate at app layer (defense in depth alongside RLS). Create/Update/Delete enforce role + office checks.
- Port `internal/services/parteien_service.go`.
- Tests: deadline calculator round-trip, holiday adjustment, Akte visibility (3-user 2-office scenario), Akte CRUD happy-path with role enforcement.
**Acceptance:**
- `GET /api/deadline-rules` returns rules from DB.
- `POST /api/deadlines/calculate` works with DB rules (proves Phase A schema ↔ Phase B services wiring).
- `GET/POST /api/matters` works (no UI yet — verified via curl).
- `POST /api/fristen/calculate` works with DB rules (proves Phase A schema ↔ Phase B services wiring).
- `GET/POST /api/akten` works (no UI yet — verified via curl with 3 test users).
- Visibility verified end-to-end: User A (Munich associate) cannot see User B (Düsseldorf associate)'s Akte unless added as collaborator or `firm_wide_visible=true`.
- All ported tests pass.
- No regressions in existing Paliad endpoints.
**Owner suggestion:** coder.
**Owner suggestion:** coder. Opus review the visibility enforcement code paths.
---
@@ -372,64 +523,75 @@ Each phase is sized for one focused coder session with clear acceptance criteria
---
### Phase D — Matters (Mandate) CRUD UI (~6h)
### Phase D — Akten CRUD + onboarding + collaborator UI (~8h)
**Scope:**
- Backend: handlers for `GET/POST/PATCH/DELETE /api/matters`, `GET/POST /api/matters/{id}/parties`.
- New TSX pages: `mandate.tsx` (list with filters), `mandate-neu.tsx` (form), `mandate-detail.tsx` (header + tabs).
- Sub-routes via Go mux: `/mandate/{id}/verlauf`, `/mandate/{id}/parteien`, etc. (other tabs come in later phases — show "Coming soon" placeholder).
- Sidebar: add "Arbeit" group with Mandate as the only entry initially.
- Per-page client TS for inline edit, delete confirm.
- Backend: handlers for `GET/POST/PATCH/DELETE /api/akten`, `GET/POST /api/akten/{id}/parteien`, `GET /api/users` (for collaborator-picker autocomplete, returns minimal user list).
- Backend: `POST /api/onboarding` — accepts office/practice_group/role for the current `auth.uid()`, creates the `paliad.users` row.
- Backend: `PATCH /api/akten/{id}/collaborators` (add/remove), `PATCH /api/akten/{id}/firm-wide-visible` (partner-only — checked via role).
- Frontend (TSX):
- `onboarding.tsx` — first-login form. Middleware-detected: if `paliad.users` row missing, redirect here on any protected route.
- `akten.tsx` — list scoped to visible Akten. Office badge per row. Filter by office (own / firm-wide / all-visible).
- `akten-neu.tsx` — form. `owning_office` defaults to user's own office; admin can pick any.
- `akten-detail.tsx` — header + tabs. Header shows office badge + collaborator avatars + firm-wide-visible flag. Collaborator-picker modal for adding/removing. Partner-only "Firm-wide visible" toggle.
- Sidebar: add "Arbeit" group with Akten as the only entry initially.
- Per-page client TS for inline edit, delete confirm, collaborator autocomplete.
**Acceptance:**
- Lawyer logs in, clicks "Mandate", creates a new matter, adds parties, sees it in the list, opens detail page.
- Audit trail: each mutation creates a `case_event` row.
- New user signs up → redirected to `/onboarding` → completes form → redirected to `/dashboard`.
- Lawyer creates Akte → automatically owns it under their office.
- Lawyer in another office cannot see the Akte unless added as collaborator.
- Partner toggles `firm_wide_visible` → all users now see it.
- Audit trail: each mutation creates an `akten_events` row.
- Empty states are friendly (German Umlaute correct per audit §2.10).
**Owner suggestion:** coder.
**Owner suggestion:** coder. Opus review the visibility-related UI flows (collaborator picker, firm-wide toggle).
---
### Phase E — Persistent deadline management UI (~6h)
### Phase E — Persistent Frist management UI (~6h)
**Scope:**
- Backend: handlers for `GET /api/deadlines` (all), `GET/POST /api/matters/{id}/deadlines`, `PATCH /api/deadlines/{id}`, `PATCH /api/deadlines/{id}/complete`, `DELETE /api/deadlines/{id}`.
- New TSX pages: `fristen.tsx` (list with status filter — overdue/this_week/all), `fristen-neu.tsx`, `fristen-detail.tsx`, `fristen-kalender.tsx` (month grid).
- Traffic light cards on `fristen.tsx` + on `mandate-detail.tsx` (deadlines tab — replace placeholder from Phase D).
- "Save to matter" button on existing Fristenrechner: select target matter from dropdown, persists calculated deadlines as draft.
- Backend: handlers for `GET /api/fristen` (all visible), `GET/POST /api/akten/{id}/fristen`, `PATCH /api/fristen/{id}`, `PATCH /api/fristen/{id}/complete`, `DELETE /api/fristen/{id}`. All visibility-enforced via the parent Akte.
- New TSX pages: `fristen.tsx` (list with status filter — überfällig/diese_woche/alle), `fristen-neu.tsx`, `fristen-detail.tsx`, `fristen-kalender.tsx` (month grid).
- Traffic light cards on `fristen.tsx` + on `akten-detail.tsx` (Fristen tab).
- "Zur Akte speichern" button on existing Fristenrechner: select target Akte from dropdown of visible Akten, persists calculated Fristen as draft.
**Acceptance:**
- Lawyer creates matter, adds deadlines manually OR via Fristenrechner "Save to matter".
- Lawyer creates Akte, adds Fristen manually OR via Fristenrechner "Zur Akte speichern".
- List filterable by status. Calendar view navigable by month.
- Mark-complete works, persists, updates traffic light counts.
- Lawyer cannot see Fristen on Akten they don't have visibility to.
**Owner suggestion:** coder.
---
### Phase F — Appointments + CalDAV sync (~8h)
### Phase F — Termine + CalDAV sync (~8h)
**Scope:**
- Backend: `appointment_service.go`, handlers for CRUD.
- Backend: `termin_service.go`, handlers for CRUD. Visibility via parent Akte.
- Backend: `caldav_service.go` ported from KanzlAI **with credential encryption fix** (audit §1.3): use `CALDAV_ENCRYPTION_KEY` env var with AES-GCM at rest. Never return password in API responses.
- New TSX pages: `termine.tsx`, `termine-neu.tsx`, `termine-detail.tsx`, `termine-kalender.tsx`, `einstellungen-caldav.tsx`.
- Per-user CalDAV config (one entry per `auth.uid()`, stored in new `paliad.user_caldav_config` table).
- Background sync goroutine per user with active config (pulled at server startup, refreshed when config changes).
- Sync scope: only sync Termine on Akten the user can see (visibility predicate applies to outbound sync too).
**Acceptance:**
- User configures CalDAV in settings, password is encrypted in DB.
- User creates an appointment, it appears in their external calendar within 60s.
- User creates a Termin, it appears in their external calendar within 60s.
- External calendar event edited → reflected in Paliad on next sync cycle.
- Deleting CalDAV config purges credentials.
- User cannot leak Termine to their personal calendar from Akten they don't have visibility to.
**Owner suggestion:** coder, Opus design review of the encryption scheme + sync conflict resolution.
**Owner suggestion:** coder, Opus design review of the encryption scheme + sync conflict resolution + visibility-aware sync scope.
---
### Phase G — Dashboard (~4h)
**Scope:**
- Backend: `dashboard_service.go` ported and simplified (no tenant). Returns `deadline_summary`, `matter_summary`, `upcoming_deadlines` (7d), `upcoming_appointments` (7d), `recent_activity`.
- Backend: `dashboard_service.go` ported and simplified (no tenant; uses visibility predicate). Returns `frist_summary`, `akten_summary`, `upcoming_fristen` (7d), `upcoming_termine` (7d), `recent_activity` — all scoped to what the user can see.
- New TSX page: `dashboard.tsx` — server-rendered initial paint (no client-side fetch + skeleton, per audit §2.3 critique).
- Update `/` route: redirect authenticated users to `/dashboard`; serve current marketing-ish landing only for unauthenticated visitors (or remove entirely if HLC sees no value in the unauthenticated landing).
- Update sidebar "Übersicht → Dashboard" entry.
@@ -438,39 +600,42 @@ Each phase is sized for one focused coder session with clear acceptance criteria
- Authenticated user lands on `/dashboard` with zero client-side waterfall.
- Traffic lights link to `/fristen?status=...`.
- Upcoming items link to detail pages.
- Recent activity shows last 10 case events with author + timestamp.
- Recent activity shows last 10 akten_events with author + timestamp, scoped to visible Akten.
**Owner suggestion:** coder.
---
### Phase H — AI deadline extraction (~4h)
### Phase H — AI Frist-Extraktion (~4h)
**Scope:**
- Backend: `ai_service.go` ported from KanzlAI. Anthropic SDK call with PDF document blocks + tool-forced structured output.
- Backend: document upload → Supabase Storage, then AI extraction triggered.
- Frontend: document upload component on `mandate-detail.tsx` "Dokumente" tab.
- Extraction result: review screen with confidence scores + source quotes; user confirms which deadlines to persist.
- Backend: document upload → Supabase Storage, then AI extraction triggered. Visibility check on parent Akte before processing.
- Frontend: document upload component on `akten-detail.tsx` "Dokumente" tab.
- Extraction result: review screen with confidence scores + source quotes; user confirms which Fristen to persist.
- Feature flag: AI tab/buttons hidden if `ANTHROPIC_API_KEY` is unset.
- Per-user rate limit on AI endpoint (fixes audit §1.7 by keying off `auth.uid()`, not spoofable headers).
**Acceptance:**
- Upload a UPC Statement of Defence PDF → AI extracts deadlines with rule references → user confirms → persisted as draft deadlines on the matter.
- No AI calls on uploads to other matters' documents (stays user-triggered).
- Upload a UPC Statement of Defence PDF → AI extracts Fristen with rule references → user confirms → persisted as draft Fristen on the Akte.
- No AI calls on uploads to other Akten (visibility-checked).
- Rate limit caps abuse.
**Owner suggestion:** coder.
---
### Phase I — Notes (polymorphic) (~4h)
### Phase I — Notizen (polymorphic) (~4h)
**Scope:**
- Backend: `notes.go` table migration (polymorphic FK with CHECK constraint per KanzlAI Phase A pattern), `note_service.go`, handlers.
- Frontend: shared `NotesList` TSX component, embedded on matter / deadline / appointment / case-event detail pages.
- Backend: `notizen` table migration (polymorphic FK with CHECK constraint per KanzlAI Phase A pattern), `notiz_service.go`, handlers. Visibility inherited from parent Akte (when notiz attaches to Akte/Frist/Termin/AkteEvent).
- Frontend: shared `NotizenList` TSX component, embedded on Akte / Frist / Termin / AkteEvent detail pages.
**Acceptance:**
- User adds note to a matter → visible on matter detail.
- User adds note to a deadline → visible on deadline detail.
- User adds Notiz to an Akte → visible on Akte detail.
- User adds Notiz to a Frist → visible on Frist detail.
- Edit/delete works.
- Visibility inherited correctly.
**Owner suggestion:** coder.
@@ -500,7 +665,7 @@ Each phase is sized for one focused coder session with clear acceptance criteria
### Total effort
**~52 hours of focused implementation across 10 phases**, plus this design review (~3h) = **~55h total**. At 1–2 phases per day with one coder, this completes in **2–3 working weeks**.
**~56 hours of focused implementation across 10 phases** (revised up from 52h: Phase A +2h for visibility model, Phase D +2h for onboarding + collaborator UI), plus this design review (~3h) = **~59h total**. At 1–2 phases per day with one coder, this completes in **2–3 working weeks**.
---
@@ -508,11 +673,11 @@ Each phase is sized for one focused coder session with clear acceptance criteria
### Risks
1. **KanzlAI's audit issues must not be ported as-is.** The audit identified 7 critical and 13 important issues. Each port phase is responsible for fixing the issues relevant to its code: Phase A fixes RLS policies (audit §2.13), Phase B fixes HolidayService race + search_path (§1.6, §2.8), Phase F fixes CalDAV plaintext (§1.3), every backend phase implements proper error handling (§1.5) + length limits + pagination (§2.1, §2.2). Track these in a checklist per phase.
1. **KanzlAI's audit issues must not be ported as-is.** The audit identified 7 critical and 13 important issues. Each port phase is responsible for fixing the issues relevant to its code: Phase A enforces real (not permissive) RLS policies (audit §2.13), Phase B fixes HolidayService race + search_path (§1.6, §2.8) and the tenant-isolation pattern (§1.1, replaced by visibility predicate), Phase F fixes CalDAV plaintext (§1.3), Phase H fixes the rate-limiter spoofability (§1.7). Every backend phase implements proper error handling (§1.5) + length limits + pagination (§2.1, §2.2). Track these in a checklist per phase.
2. **React → Bun TSX rewrite friction.** KanzlAI's frontend uses react-query, react-day-picker, modal libs, complex client state. Paliad's stack uses server-rendered TSX + small per-page client TS. Some patterns translate awkwardly. Mitigation: HTML-first design, JS only where it materially improves UX. If a feature *requires* a heavy interactive component (e.g., date picker), prefer native `<input type="date">` over importing a library.
3. **Single-tenant assumption locks us in.** If HLC ever wants per-office or per-practice-group matter visibility, schema needs ACL columns or a separate visibility table. Mitigation: every table has `created_by`; can add `visible_to JSONB` later without breaking changes. Don't build it now.
3. **Visibility model is the security-critical layer.** Office-scoped RLS with collaborator override is more complex than either "everyone sees everything" or pure tenant-id. Bugs here leak Akten across offices. Mitigation: Phase A and Phase B both have Opus design reviews on the visibility predicate; Phase B includes a 3-user 2-office integration test as an acceptance gate; the predicate lives in a single SQL function (`paliad.can_see_akte`) reused by every RLS policy and mirrored at the app layer for defense in depth. Add a pen-test pass (or at minimum a security-review skill run) before Phase J.
4. **Email domain transition risk.** Whitelist `[@hoganlovells.com, @hlc.com, @hlc.de]`. Risk: HLC picks a TLD we didn't anticipate (`@hlc.law`?). Mitigation: keep the whitelist in env config, not hardcoded. Trivial to update.
@@ -520,15 +685,16 @@ Each phase is sized for one focused coder session with clear acceptance criteria
6. **KanzlAI-derived German Umlaut typos** in audit §2.10. Don't carry them forward. Style check during each frontend port phase.
7. **No load testing on KanzlAI's calc-heavy paths.** AI extraction in particular can be slow + expensive. Phase H should add per-user rate limits before going live.
7. **Outlook / Exchange CalDAV is not where HLC lawyers live.** HLC primarily uses Outlook + Exchange; Exchange's CalDAV support is limited or off by default. Phase F ships with CalDAV only (verified against `dav.msbls.de` and Apple iCloud as KanzlAI did). **Long-term plan: add an EWS / Microsoft Graph API backend behind the same sync abstraction.** That's a follow-on phase (call it Phase K), not blocking the v1 cutover. For HLC users on Outlook, Phase F will work for *manual* iCal export; full bidirectional sync waits for Phase K.
8. **No load testing on KanzlAI's calc-heavy paths.** AI extraction in particular can be slow + expensive. Phase H adds per-user rate limits before going live (per-user via `auth.uid()`, not header).
### Unknowns
- **Does HLC actually want firm-wide matter visibility, or office-scoped?** Need product input from m. The §2 decision (firm-wide) is the simplest assumption; if wrong, Phase D needs an ACL design before shipping.
- **Practice-group scoping intent.** §2 makes office the access boundary and treats `practice_group` as filter-only metadata. Confirm with a HLC partner: are there matters where Patents Litigation must be walled off from Patents Prosecution? If yes, schema is ready (extend the predicate); if no, status quo.
- **AI extraction quality on real HLC documents.** KanzlAI's test fixtures were synthetic. Real UPC Statements of Defence are messier. Phase H should include a manual test pass on 3–5 real (anonymized) HLC documents before declaring done.
- **CalDAV server compatibility.** KanzlAI tested against `dav.msbls.de` and Apple iCloud. HLC lawyers may use Outlook + Exchange, where CalDAV support is limited or off by default. Phase F should verify against the actual calendar systems HLC lawyers use.
- **HLC IT approval for storing matter data on a Supabase instance hosted in Germany.** Out of scope for this design but blocking for going live with real client data. Flag to m.
- **Naming: "Mandate" vs "Akten" vs "Matters"** in the German UI. Currently picking "Mandate" — confirm with a HLC partner before frontend strings are baked in.
- **Outlook integration urgency.** Phase K (EWS / Graph) could be ahead of Phase J if a partner says CalDAV-only is a non-starter at HLC. Decide at end of Phase F based on internal feedback.
- **Naming check with a HLC partner.** "Akten" / "Aktenverwaltung" is the German legal-practice norm — confirm one final time before the strings are baked in across the UI.
---
@@ -538,9 +704,9 @@ Once this design is approved, who implements?
- **Option 1: I (cronus) implement Phases A–J as coder.** I have the deepest context from this design work and the source repos. Single context, no handoff loss. Likely faster overall.
- **Option 2: Hand off to a separate coder worker (e.g., pike, knuth, ritchie) per phase.** Better parallelism if multiple phases can run in parallel. But Phases A → B → C → D have hard dependencies; only F, G, H, I can run in any order after E.
- **Option 3: Hybrid — I implement Phases A–C (foundation), hand off D–I to coder workers in parallel where possible, take J myself for the wrap-up.**
- **Option 3: Hybrid — I implement Phases A–C (foundation, including the security-critical visibility model), hand off D–I to coder workers in parallel where possible, take J myself for the wrap-up.**
**My recommendation: Option 3.** Foundation needs design context (cronus is the carrier). Phases D–I are mechanical ports of well-defined services; coder workers can run them with the design doc + KanzlAI source as the brief. Phase J is the easy victory lap.
**My recommendation: Option 3.** Foundation needs design context (cronus is the carrier), and the visibility model in §2 is too security-critical to hand off cold. Phases D–I are mechanical ports of well-defined services; coder workers can run them with the design doc + KanzlAI source as the brief. Phase J is the easy victory lap.
---