# Data Model v2 — Clients, nestable Projects, Teams

**Author:** cronus (inventor)
**Date:** 2026-04-20
**Task:** t-paliad-023
**Status:** Design draft for review. Supersedes the flat `paliad.akten` model in `design-kanzlai-integration.md` §2–§3.
**Scope:** Schema + migration plan. No implementation in this change.

---

## Executive summary

**Recommendation.** Replace the flat `paliad.akten` table with a two-table core:

1. `paliad.mandanten` — clients (companies or people who instruct HLC).
2. `paliad.projekte` — a **single, self-referential, typed tree** of all work. Every row has a `project_type` (`mandat`, `litigation`, `patent`, `verfahren`, `projekt`), an optional `parent_project_id`, and a required `client_id` that points to the Mandant at the root of the tree. Fristen, Termine, Notizen, Dokumente and Parteien all hang off a **single polymorphic `project_id`** — "polymorphic" only in the sense that any node in the tree can own them, not in the sense of multi-table FKs.

**Teams** become explicit rows. `paliad.teams` holds both Dezernate (structural, one partner-led unit per row) and — as a separate concept — Project Teams (ad-hoc, per-project roster). The `paliad.users.dezernat` free-text field is superseded by `paliad.team_mitglieder`. The `paliad.akten.collaborators uuid[]` array on every Akte is replaced by `paliad.projekt_mitglieder`, giving us per-user roles inside a project and a sane target for audit + invitations.

**Visibility** stays office-scoped, but the predicate now walks the tree: seeing *any* node in a project grants the viewer access to the whole connected tree (root, siblings, descendants). This matches how lawyers actually use the data — a Munich associate put on one UPC Case of a Siemens litigation must see the parent litigation and the sibling Cases to do their job, and a lead partner put on the litigation root must see everything below.

**Naming.** Stay German, matching everything shipped so far — `mandanten`, `projekte`, `teams`, `team_mitglieder`, `projekt_mitglieder`. German plural for table names, singular for Go structs (`Mandant`, `Projekt`, `Team`). `User` stays English (Supabase concept).

**Migration** is phased and non-destructive. Existing `paliad.akten` rows survive as `projekte` rows with `project_type='verfahren'` (best match for the flat-Akte pattern), the same primary key UUIDs, and `client_id` nullable during a cleanup window (the partner UI collects real Mandant assignment). Every child table (`fristen`, `termine`, `notizen`, `dokumente`, `parteien`, `akten_events`, `checklist_instances`) gets its FK column renamed from `akte_id` to `project_id` in a follow-on migration — no data move, just a DDL rename. The existing `/akten` URLs stay live as aliases of `/projekte`.

**This is the foundation for Paliad v2.** It is opinionated. The trade-offs are called out inline.

---

## 1. Entity-Relationship

### 1.1 Mermaid

```mermaid
erDiagram
    USERS ||--o{ TEAM_MITGLIEDER          : "belongs to"
    USERS ||--o{ PROJEKT_MITGLIEDER       : "staffed on"
    TEAMS ||--o{ TEAM_MITGLIEDER          : "has members"

    MANDANTEN ||--o{ PROJEKTE             : "owns"
    PROJEKTE  ||--o{ PROJEKTE             : "parent of"
    PROJEKTE  ||--o{ PROJEKT_MITGLIEDER   : "has team"

    PROJEKTE  ||--o{ FRISTEN              : "1:N"
    PROJEKTE  ||--o{ TERMINE              : "1:N (nullable)"
    PROJEKTE  ||--o{ NOTIZEN              : "1:N (polymorphic parent)"
    PROJEKTE  ||--o{ DOKUMENTE            : "1:N"
    PROJEKTE  ||--o{ PARTEIEN             : "1:N"
    PROJEKTE  ||--o{ AKTEN_EVENTS         : "1:N (audit)"
    PROJEKTE  ||--o{ CHECKLIST_INSTANCES  : "1:N (nullable)"

    FRISTEN   ||--o{ NOTIZEN              : "parent (optional)"
    TERMINE   ||--o{ NOTIZEN              : "parent (optional)"
    AKTEN_EVENTS ||--o{ NOTIZEN           : "parent (optional)"

    TEAMS {
        uuid   id PK
        text   type "dezernat | project_team"
        text   name
        uuid   partner_id FK "for dezernat; NULL for project team"
        uuid   projekt_id FK "for project team; NULL for dezernat"
        text   office "seat of the dezernat; NULL for project team"
        bool   is_active
    }

    MANDANTEN {
        uuid   id PK
        text   name
        text   legal_form "e.g., AG, GmbH, Einzelerfinder"
        text   industry
        text   country
        text   billing_reference
        jsonb  key_contacts
        text   owning_office "Default office for new Projekte"
        uuid[] collaborators "Firm-wide people with explicit Mandant access"
        bool   firm_wide_visible
        text   status "active | archived"
    }

    PROJEKTE {
        uuid   id PK
        uuid   client_id FK "nullable during migration"
        uuid   parent_project_id FK "self"
        text   project_type "mandat|litigation|patent|verfahren|projekt"
        text   title
        text   reference "human-readable ref (Aktenzeichen)"
        text   external_ref "EP no., UPC docket, etc."
        text   court
        text   court_ref
        text   status "active | pending | closed | archived"
        text   owning_office
        bool   firm_wide_visible
        uuid   created_by FK
        jsonb  metadata
        ltree  path "materialised ancestor path"
        int    depth "0 = root"
    }

    PROJEKT_MITGLIEDER {
        uuid   projekt_id PK FK
        uuid   user_id    PK FK
        text   role "lead|associate|pa|of_counsel|local_counsel|expert|observer"
        timestamptz added_at
        uuid   added_by FK
    }

    TEAM_MITGLIEDER {
        uuid   team_id PK FK
        uuid   user_id PK FK
        text   role "partner|associate|pa|trainee|of_counsel|secretariat"
        timestamptz added_at
    }
```

### 1.2 ASCII worked example

Showing the Siemens portfolio from the brief. `[P]` = partner, `[A]` = associate, `[LC]` = local counsel. Node IDs are illustrative.

```
MANDANTEN: M1 "Siemens AG" (industry=industrial, owning_office=munich)
│
└── PROJEKTE (client_id=M1)
    │
    └── P0  project_type=mandat         "Siemens — Overall relationship"       (path=P0,            depth=0)
        │   owning_office=munich
        │   Team: [P Lead=partner_a@munich] [A associate_b@munich]
        │
        └── P1  project_type=litigation   "Siemens v. Huawei — SEP Portfolio"    (path=P0.P1,         depth=1)
            │   owning_office=munich, firm_wide_visible=false
            │   Team: [P Lead=partner_a@munich] [A associate_c@duesseldorf] [LC local_uk@london]
            │
            ├── P2 project_type=patent    "EP 1 234 567"                         (path=P0.P1.P2,      depth=2)
            │   │  external_ref=EP1234567
            │   │
            │   ├── P3 project_type=verfahren "UPC Infringement UPC_CFI_123/2026"(path=P0.P1.P2.P3,  depth=3)
            │   │     court=UPC_CFI_Munich, court_ref=UPC_CFI_123/2026
            │   │     └─ Fristen, Termine, Notizen, Dokumente all project_id=P3
            │   │
            │   ├── P4 project_type=verfahren "EPO Opposition W 0001/26"
            │   └── P5 project_type=verfahren "BPatG Nullity 3 Ni 45/26"
            │
            ├── P6 project_type=patent    "EP 2 345 678"
            │   └── P7 project_type=verfahren "UPC Infringement UPC_CFI_456/2026"
            │
            └── P8 project_type=patent    "EP 3 456 789"
                └── P9 project_type=verfahren "LG München I 21 O 12345/26"
```

The key insight: **every box is a row in `paliad.projekte`**. Fristen/Termine/Notizen live at whichever node is the right home. Dashboard aggregates across all nodes the user can see by walking the visibility predicate.

---

## 2. Table schemas

### 2.1 `paliad.mandanten`

```sql
CREATE TABLE paliad.mandanten (
    id                   uuid PRIMARY KEY DEFAULT gen_random_uuid(),
    name                 text NOT NULL,
    legal_form           text,                      -- 'AG', 'GmbH', 'Inc.', 'Einzelerfinder', …
    industry             text,                      -- free text, not an enum
    country              text,                      -- ISO 3166-1 alpha-2 ('DE','US',…)
    billing_reference    text,                      -- matches the firm-wide billing system
    key_contacts         jsonb NOT NULL DEFAULT '[]'::jsonb,
                                                    -- [{"name":"…","role":"…","email":"…","phone":"…"}]
    owning_office        text NOT NULL CHECK (owning_office IN (
                             'munich','duesseldorf','hamburg',
                             'amsterdam','london','paris','milan')),
    -- Visibility knobs, analogous to paliad.akten today:
    collaborators        uuid[] NOT NULL DEFAULT '{}',
    firm_wide_visible    boolean NOT NULL DEFAULT false,
    status               text NOT NULL DEFAULT 'active'
                         CHECK (status IN ('active','archived')),
    metadata             jsonb NOT NULL DEFAULT '{}',
    created_by           uuid REFERENCES auth.users(id) ON DELETE SET NULL,
    created_at           timestamptz NOT NULL DEFAULT now(),
    updated_at           timestamptz NOT NULL DEFAULT now()
);

CREATE INDEX mandanten_owning_office_idx  ON paliad.mandanten (owning_office);
CREATE INDEX mandanten_firm_wide_idx      ON paliad.mandanten (firm_wide_visible) WHERE firm_wide_visible = true;
CREATE INDEX mandanten_collaborators_gin  ON paliad.mandanten USING GIN (collaborators);
CREATE INDEX mandanten_name_trgm          ON paliad.mandanten USING GIN (name gin_trgm_ops);
```

Notes:
- `key_contacts` is JSONB not a child table. Contacts don't have their own identity (they're denormalised name/email/phone); pulling them into `paliad.contacts` would be overkill and block nothing. If HLC later wants CRM-style contact records, promote to a table in a follow-on.
- `owning_office` on `mandanten` is the **default** for new Projekte; individual Projekte can override.
- Duplicated visibility knobs (`collaborators`, `firm_wide_visible`) are intentional: a user can have Mandant-level visibility without being on any particular Projekt (e.g., the relationship partner who hasn't been staffed on a specific case yet). The predicate OR-fans these in.

### 2.2 `paliad.projekte`

```sql
-- Enable the ltree extension in Supabase (first migration to use it).
CREATE EXTENSION IF NOT EXISTS ltree;

-- project_type is a text + CHECK, not an enum type. Enums are painful to extend
-- in Postgres migrations; text + CHECK gives us the same validation with room
-- to add a new type by replacing the constraint.
CREATE TABLE paliad.projekte (
    id                   uuid PRIMARY KEY DEFAULT gen_random_uuid(),
    client_id            uuid REFERENCES paliad.mandanten(id) ON DELETE RESTRICT,
                                                    -- NULLABLE during migration;
                                                    -- enforced NOT NULL in a later phase.
    parent_project_id    uuid REFERENCES paliad.projekte(id) ON DELETE CASCADE,

    project_type         text NOT NULL CHECK (project_type IN
                             ('mandat','litigation','patent','verfahren','projekt')),
    title                text NOT NULL,
    reference            text,                      -- firm-internal human ref (Aktenzeichen)
    external_ref         text,                      -- EP no., UPC docket, BPatG ref, …
    court                text,
    court_ref            text,

    status               text NOT NULL DEFAULT 'active'
                         CHECK (status IN ('active','pending','closed','archived')),

    owning_office        text NOT NULL CHECK (owning_office IN (
                             'munich','duesseldorf','hamburg',
                             'amsterdam','london','paris','milan')),
    firm_wide_visible    boolean NOT NULL DEFAULT false,

    -- Materialised tree state. Maintained by a BEFORE INSERT/UPDATE trigger.
    -- `path` is the ltree of ancestor ids ending with this row's id.
    path                 ltree NOT NULL,
    depth                int   NOT NULL CHECK (depth >= 0),

    created_by           uuid REFERENCES auth.users(id) ON DELETE SET NULL,
    metadata             jsonb NOT NULL DEFAULT '{}',
    ai_summary           text,                      -- unused today; kept from akten
    created_at           timestamptz NOT NULL DEFAULT now(),
    updated_at           timestamptz NOT NULL DEFAULT now(),

    -- Sanity: a project's client must match its parent's client (and root of
    -- tree carries the single source of truth).
    CONSTRAINT projekte_parent_self_differs CHECK (parent_project_id IS NULL OR parent_project_id <> id)
);

-- Trees are navigated by path. GiST over ltree makes ancestor / descendant
-- lookups <@ / @> work in O(log n) — critical for the visibility predicate.
CREATE INDEX projekte_path_gist          ON paliad.projekte USING GIST (path);
CREATE INDEX projekte_parent_idx         ON paliad.projekte (parent_project_id);
CREATE INDEX projekte_client_idx         ON paliad.projekte (client_id);
CREATE INDEX projekte_client_type_idx    ON paliad.projekte (client_id, project_type)
                                         WHERE status <> 'archived';
CREATE INDEX projekte_owning_office_idx  ON paliad.projekte (owning_office);
CREATE INDEX projekte_firm_wide_idx      ON paliad.projekte (firm_wide_visible) WHERE firm_wide_visible = true;
CREATE INDEX projekte_status_idx         ON paliad.projekte (status);
CREATE INDEX projekte_reference_trgm     ON paliad.projekte USING GIN (reference gin_trgm_ops);
CREATE INDEX projekte_title_trgm         ON paliad.projekte USING GIN (title     gin_trgm_ops);
```

**Why ltree and not a recursive CTE?** RLS is called once per candidate row on every SELECT. A recursive CTE per row is O(depth) repeated per predicate call. `path @> ancestor_path` uses the GiST index and collapses to one index scan. This is the biggest performance decision in the doc; ltree is the right tool.

**Why a materialised path *and* `parent_project_id`?** The parent FK is the source of truth for the tree (used by `ON DELETE CASCADE`). The `path` + `depth` columns are derived state maintained by a trigger. Keeping both is redundant on purpose — the FK guarantees referential integrity; the path gives us fast traversal. Updates to `parent_project_id` re-compute path for the subtree in the trigger.

**Tree trigger sketch:**

```sql
CREATE FUNCTION paliad.projekte_sync_path() RETURNS trigger LANGUAGE plpgsql AS $$
DECLARE
    parent_path ltree;
BEGIN
    IF NEW.parent_project_id IS NULL THEN
        NEW.path  := text2ltree(replace(NEW.id::text, '-', '_'));
        NEW.depth := 0;
    ELSE
        SELECT path, depth + 1 INTO parent_path, NEW.depth
        FROM paliad.projekte
        WHERE id = NEW.parent_project_id;
        IF parent_path IS NULL THEN
            RAISE EXCEPTION 'parent project % not found', NEW.parent_project_id;
        END IF;
        NEW.path := parent_path || text2ltree(replace(NEW.id::text, '-', '_'));
    END IF;
    RETURN NEW;
END;
$$;

CREATE TRIGGER projekte_sync_path_ins
    BEFORE INSERT ON paliad.projekte
    FOR EACH ROW EXECUTE FUNCTION paliad.projekte_sync_path();

-- On parent change, re-path both this row and every descendant.
CREATE FUNCTION paliad.projekte_rewrite_subtree() RETURNS trigger LANGUAGE plpgsql AS $$
BEGIN
    IF NEW.parent_project_id IS DISTINCT FROM OLD.parent_project_id THEN
        PERFORM paliad.projekte_sync_path() FROM paliad.projekte WHERE id = NEW.id;
        UPDATE paliad.projekte
           SET path  = NEW.path || subpath(path, nlevel(OLD.path) - 1),
               depth = NEW.depth + (nlevel(path) - nlevel(OLD.path))
         WHERE path <@ OLD.path
           AND id <> NEW.id;
    END IF;
    RETURN NEW;
END;
$$;
```

(Sketch — implementer will refine. The constraint that uuid-hyphens aren't valid in ltree labels means we encode UUIDs with `-`→`_`. Alternative: use `hashtext(id::text)::text` to keep labels short — discuss with implementer.)

### 2.3 `paliad.teams`

**Two kinds, one table.** The shape is similar enough that splitting into `dezernate` + `project_teams` would mostly duplicate columns. A `type` column + partial CHECK constraints is cheaper.

```sql
CREATE TABLE paliad.teams (
    id           uuid PRIMARY KEY DEFAULT gen_random_uuid(),
    type         text NOT NULL CHECK (type IN ('dezernat','project_team')),
    name         text NOT NULL,

    -- For type = 'dezernat':
    partner_id   uuid REFERENCES auth.users(id) ON DELETE SET NULL,
    office       text CHECK (office IS NULL OR office IN (
                     'munich','duesseldorf','hamburg',
                     'amsterdam','london','paris','milan')),

    -- For type = 'project_team':
    projekt_id   uuid REFERENCES paliad.projekte(id) ON DELETE CASCADE,

    is_active    boolean NOT NULL DEFAULT true,
    metadata     jsonb NOT NULL DEFAULT '{}',
    created_at   timestamptz NOT NULL DEFAULT now(),
    updated_at   timestamptz NOT NULL DEFAULT now(),

    -- Shape invariants per type.
    CONSTRAINT teams_dezernat_shape CHECK (
        type <> 'dezernat'
        OR (partner_id IS NOT NULL AND office IS NOT NULL AND projekt_id IS NULL)
    ),
    CONSTRAINT teams_project_team_shape CHECK (
        type <> 'project_team'
        OR (projekt_id IS NOT NULL AND partner_id IS NULL AND office IS NULL)
    )
);

-- One project_team per Projekt (if any).
CREATE UNIQUE INDEX teams_one_team_per_projekt
    ON paliad.teams (projekt_id) WHERE type = 'project_team';

CREATE INDEX teams_partner_idx ON paliad.teams (partner_id) WHERE type = 'dezernat';
CREATE INDEX teams_office_idx  ON paliad.teams (office)     WHERE type = 'dezernat';
CREATE INDEX teams_projekt_idx ON paliad.teams (projekt_id) WHERE type = 'project_team';
```

**Critique already anticipated.** Mixing two entities in one table is a smell. I accept the smell because: (a) the queries we actually run split cleanly by `type`; (b) the join from a user to "every team I'm on" wants a single table; (c) project teams and dezernate both feed the same `team_mitglieder` roster table and the same per-team role enum overlap is ~80%. If we discover real divergence (project teams grow a `stage` field, dezernate grow a `parent_dezernat_id`), split then.

### 2.4 `paliad.team_mitglieder`

Roster for **both** kinds of team. Dezernat and project-team memberships coexist — a user is typically in exactly one Dezernat *and* on multiple project teams.

```sql
CREATE TABLE paliad.team_mitglieder (
    team_id     uuid NOT NULL REFERENCES paliad.teams(id)   ON DELETE CASCADE,
    user_id     uuid NOT NULL REFERENCES auth.users(id)     ON DELETE CASCADE,
    role        text NOT NULL CHECK (role IN (
                    'partner','associate','pa','trainee','of_counsel',
                    'secretariat','lead','local_counsel','expert','observer'
                )),
    added_at    timestamptz NOT NULL DEFAULT now(),
    added_by    uuid REFERENCES auth.users(id) ON DELETE SET NULL,
    PRIMARY KEY (team_id, user_id)
);

CREATE INDEX team_mitglieder_user_idx ON paliad.team_mitglieder (user_id);
```

Role values overlap intentionally: `partner`, `associate`, `pa`, `trainee`, `of_counsel`, `secretariat` are the typical Dezernat roles; `lead`, `associate`, `pa`, `of_counsel`, `local_counsel`, `expert`, `observer` are the typical project-team roles. The union is finite and small — don't over-engineer with separate role enums per team type.

### 2.5 `paliad.projekt_mitglieder` (replaces `collaborators uuid[]`)

I recommend **flattening project-team rosters into a dedicated junction table** instead of going through `teams` + `team_mitglieder` for the project-team case. Reason: project-team membership is the hot path for RLS. A dedicated two-column junction with a covering index beats any indirection through `teams`.

```sql
CREATE TABLE paliad.projekt_mitglieder (
    projekt_id   uuid NOT NULL REFERENCES paliad.projekte(id) ON DELETE CASCADE,
    user_id      uuid NOT NULL REFERENCES auth.users(id)      ON DELETE CASCADE,
    role         text NOT NULL CHECK (role IN (
                     'lead','associate','pa','of_counsel','local_counsel','expert','observer'
                 )),
    added_at     timestamptz NOT NULL DEFAULT now(),
    added_by     uuid REFERENCES auth.users(id) ON DELETE SET NULL,
    PRIMARY KEY (projekt_id, user_id)
);

CREATE INDEX projekt_mitglieder_user_idx ON paliad.projekt_mitglieder (user_id);
```

**So what's `paliad.teams` type='project_team' for?** Two things the junction can't express alone: (a) the *identity* of the team as a first-class object (naming, status, metadata, invitations); (b) a place to attach team-level settings (e.g., a project-team Slack channel URL, a CalDAV group calendar id). If we decide we don't need either, `teams` shrinks to dezernate only and `project_team` rows go away. That's fine too — implementation can start with junction-only and add `teams` rows on demand.

**Opinion:** start with `projekt_mitglieder` only. Add `teams` rows for project teams if/when we ship team-scoped features (project Slack channel, group calendar). For the purposes of visibility and role, the junction table is sufficient.

### 2.6 Child tables — single `project_id` polymorphic FK

No polymorphic magic. Every node in the tree is a `projekte` row. A Frist attached to "the Siemens SEP litigation" just FKs to the litigation-level projekt. A Frist on the root Mandat-level projekt is rare but expressible. Polymorphic multi-FK tables (with multiple nullable parent columns + a CHECK) are a pattern we have today on `notizen`, and they create RLS pain — we avoid extending it.

Revised child tables (columns that change only):

| Table | Today | v2 |
|---|---|---|
| `paliad.parteien`            | `akte_id NOT NULL`  | `project_id NOT NULL` |
| `paliad.fristen`             | `akte_id NOT NULL`  | `project_id NOT NULL` |
| `paliad.termine`             | `akte_id NULL`      | `project_id NULL` (personal stays NULL) |
| `paliad.dokumente`           | `akte_id NOT NULL`  | `project_id NOT NULL` |
| `paliad.akten_events`        | `akte_id NOT NULL`  | `project_id NOT NULL` (table stays `akten_events` for history; see §10) |
| `paliad.checklist_instances` | `akte_id NULL`      | `project_id NULL` (personal stays NULL) |
| `paliad.notizen`             | 4 nullable FKs (akte/frist/termin/event), 1-of CHECK | **Keep as-is** — still polymorphic across frist/termin/event/*project*; `akte_id`→`project_id`. |

`notizen` stays polymorphic because notes attach to three different kinds of entity (Projekt, Frist, Termin, AktenEvent) — a note on a Frist is *not* the same thing as a note on the owning Projekt. The alternative (always attach at Projekt and store `frist_id` / `termin_id` in metadata) loses referential integrity; reject it.

### 2.7 `paliad.users` changes

- **Drop:** `dezernat text` (free-text, only introduced in migration 015).
- **Keep:** `office`, `role`, `practice_group`, `lang`, `email_preferences`.
- **New:** nothing — Dezernat membership moves to `team_mitglieder` with `team_id` pointing at a `teams` row of type `dezernat`.

Migration 015 left `dezernat` as free text precisely because the partner might not have registered yet. v2 keeps the freedom differently: during onboarding, the user either (a) picks an existing Dezernat from a dropdown (fed from `paliad.teams WHERE type='dezernat'`) or (b) types a new one, and the onboarding service auto-creates a `teams` row with `partner_id = NULL` and a note "claim this partnership by signing up with role=partner". The partner claims on their own first-login.

---

## 3. Polymorphic FK strategy (the explicit recommendation)

> **Single `project_id` on all child tables (except `notizen`).**

Rationale:
- Everything a Frist/Termin/Dokument/Partei could "attach to" is now a row in `paliad.projekte`. A Mandant-level Frist FKs to the `project_type='mandat'` root. A verfahren-level Frist FKs to the `project_type='verfahren'` leaf. No discriminator column, no CHECK constraint juggling.
- RLS becomes one predicate: `paliad.can_see_project(project_id)`. Today's `can_see_akte()` + `notiz_is_visible()` split goes away for 6 of 7 child tables.
- Client visibility (a Mandant-level Frist like "send yearly renewal reminder") is uniform: it just lives on the Mandant-level projekt — no `client_id` FK on child tables, no third polymorphic branch.
- Query aggregation across a client's work ("show me all deadlines in the next 30 days for Siemens") is a single JOIN: `fristen JOIN projekte ON fristen.project_id = projekte.id WHERE projekte.path <@ (SELECT path FROM projekte WHERE id = <mandat-projekt-id>)`.

Alternatives I considered and rejected:
- **Multiple nullable FKs (`client_id`, `litigation_id`, `patent_id`, `verfahren_id`) with a 1-of CHECK.** Reproduces the notizen pain for every child table. Harder to index, harder for RLS. Rejected.
- **`parent_type text` + `parent_id uuid` (classic polymorphic)**. Kills foreign-key integrity. Rejected.
- **Separate child tables per level (`mandat_fristen`, `litigation_fristen`, …)**. Absurd proliferation. Rejected on sight.

`notizen` is the one exception because a note genuinely attaches to one of four *kinds of entity*, not to four different positions in the same tree. Keep the 4-FK-one-nullable shape (akte_id → **project_id**, frist_id, termin_id, akten_event_id; CHECK = 1-of-4).

---

## 4. Visibility model

### 4.1 Design principles

1. Visibility is **tree-connected**: if you can see one node, you can see the whole tree (root → all descendants). Mimics how litigation teams actually work.
2. Office-scoping stays **at the project level**, not the Mandant level, because different Projekte under one client may legitimately belong to different offices (e.g., the client's Munich patent prosecution vs. their Düsseldorf enforcement).
3. Project-team membership **grants visibility**, including for users outside `owning_office`.
4. Mandant-level visibility (`mandanten.collaborators`, `mandanten.firm_wide_visible`) grants visibility to the **Mandant** and its **entire project tree**. This is the firm-wide or relationship-partner override.
5. `admin` role sees everything.

### 4.2 The predicate, in English

A user U can see a Projekt P iff **any** of the following:

- `P.firm_wide_visible = true`, **or**
- `P.owning_office = U.office`, **or**
- U is in `projekt_mitglieder` for P, **or**
- U is in `projekt_mitglieder` for **any ancestor or descendant of P** (tree-connected visibility), **or**
- `P.client_id` points to a Mandant M where:
  - `M.firm_wide_visible = true`, **or**
  - U's uuid ∈ `M.collaborators`, **or**
- `U.role = 'admin'`.

A user U can see a Mandant M iff **any** of:
- `M.firm_wide_visible = true`, **or**
- `M.owning_office = U.office`, **or**
- U's uuid ∈ `M.collaborators`, **or**
- U can see **any** Projekt under M (inductive), **or**
- `U.role = 'admin'`.

### 4.3 SQL predicate

```sql
-- Canonical visibility predicate for projects. Used in RLS and mirrored at
-- the service layer (AkteService.ListVisibleForUser equivalent).
CREATE OR REPLACE FUNCTION paliad.can_see_project(_project_id uuid)
RETURNS boolean
LANGUAGE sql
STABLE
SECURITY DEFINER
SET search_path = paliad, public
AS $$
    WITH me AS (
        SELECT id, office, role FROM paliad.users WHERE id = auth.uid()
    ),
    tgt AS (
        SELECT id, client_id, owning_office, firm_wide_visible, path
          FROM paliad.projekte
         WHERE id = _project_id
    )
    SELECT EXISTS (SELECT 1 FROM tgt WHERE tgt.firm_wide_visible)
        OR EXISTS (SELECT 1 FROM tgt, me WHERE tgt.owning_office = me.office)
        OR EXISTS (SELECT 1 FROM me WHERE me.role = 'admin')
        OR EXISTS (
            -- membership at target, or at any ancestor/descendant
            SELECT 1 FROM paliad.projekt_mitglieder pm, tgt
             WHERE pm.user_id = auth.uid()
               AND pm.projekt_id IN (
                   SELECT id FROM paliad.projekte
                    WHERE path @> tgt.path OR path <@ tgt.path
               )
        )
        OR EXISTS (
            SELECT 1 FROM paliad.mandanten m, tgt
             WHERE m.id = tgt.client_id
               AND (m.firm_wide_visible
                 OR auth.uid() = ANY (m.collaborators))
        );
$$;
```

The `path @> tgt.path OR path <@ tgt.path` clause is the tree-connected check: any project whose path is an ancestor or descendant of the target's path. Uses the GiST index on `projekte.path`.

**Performance note.** For a litigation tree of ~20 nodes with ~100 members, the predicate runs a handful of index probes per row. Measurably worse than today's flat `can_see_akte()` (one EXISTS), but still sub-millisecond in Postgres. If we ever see RLS cost dominate a listing page, the follow-on is to cache "visible project ids for user X" in a session-scoped CTE at the application layer (same trick we use in `ListVisibleForUser`).

### 4.4 Cross-office teams — concretely

Example: Munich partner (Dezernat A) leads; Düsseldorf associate and London local counsel are staffed in.

- The Litigation-level Projekt is created with `owning_office = 'munich'`.
- The Munich partner, the Düsseldorf associate, and the London local counsel all get rows in `projekt_mitglieder` (roles `lead`, `associate`, `local_counsel`).
- Result: the Düsseldorf associate can see the whole litigation tree even though `owning_office <> 'duesseldorf'`. Munich-office colleagues not on the team can still see it (office-scope). London colleagues not on the team cannot see it.

**Edge case: "Chinese-walled" cases.** If a single Akte needs to be hidden from the rest of `owning_office` (conflict of interest), `owning_office` can't carry the day. Add a boolean `restricted` column in a later iteration that flips the predicate to team-only. Don't build now — wait for the first real conflict.

---

## 5. Migration plan

Non-destructive, phased. Data survives at every step.

### Phase 1 — Add new tables (no FK rewrites)

Migration `018_v2_core_tables`:
- `CREATE EXTENSION IF NOT EXISTS ltree;`
- Create `paliad.mandanten`, `paliad.projekte`, `paliad.teams`, `paliad.team_mitglieder`, `paliad.projekt_mitglieder`.
- Create the path trigger.
- No change to `paliad.akten` or its children yet. Old code keeps running.

Acceptance: `\dt paliad.*` shows the new tables. Smoke test: insert a Mandant + one Projekt tree, query via `path @>`.

### Phase 2 — Backfill `paliad.projekte` from `paliad.akten` (synthetic Mandanten)

Migration `019_v2_backfill_projects_from_akten`:
- For each distinct `owning_office` with any Akte, create one synthetic Mandant: `name = 'Unbekannter Mandant (<office>)'`, `status = 'active'`, `owning_office = <office>`, `metadata = {"synthetic": true}`.
- Insert a `paliad.projekte` row for every `paliad.akten` row. **Same UUID** (`projekte.id = akten.id`), `client_id = synthetic mandant of matching office`, `parent_project_id = NULL`, `project_type = 'verfahren'` (best-match to current flat Akte semantics — most are single proceedings), `title`, `reference = aktenzeichen`, `owning_office`, `firm_wide_visible`, `created_by` copied 1:1. The path trigger populates `path` and `depth`.
- Also backfill `projekt_mitglieder` from `paliad.akten.collaborators` (array → rows with `role='associate'`).

Acceptance: `(SELECT COUNT(*) FROM paliad.projekte) = (SELECT COUNT(*) FROM paliad.akten)`; every akten id survives as a projekte id. Visibility-predicate returns the same answers as `can_see_akte` for every (user, akte) pair (spot-check).

### Phase 3 — Rename FK columns on child tables to `project_id`

Migration `020_v2_rename_akte_id_to_project_id`:
- For `parteien`, `fristen`, `termine`, `dokumente`, `akten_events`, `checklist_instances`: `ALTER TABLE … RENAME COLUMN akte_id TO project_id;` and `ALTER TABLE … RENAME CONSTRAINT <akte_fk> TO <project_fk>;` plus rewrite the REFERENCES target from `paliad.akten` to `paliad.projekte`.
- For `notizen`: `RENAME COLUMN akte_id TO project_id;` similarly; keep `frist_id/termin_id/akten_event_id` intact.
- Because of the shared UUID trick in Phase 2, no data moves. Indexes are renamed in the same migration.

Acceptance: `\d paliad.fristen` shows `project_id uuid NOT NULL REFERENCES paliad.projekte(id)`. Existing SELECTs joining to `paliad.akten` now break — that's the signal to cut the application code over in Phase 4.

### Phase 4 — Cut application code over to `paliad.projekte`

- Rename Go types: `models.Akte` → `models.Projekt`. Keep `models.Akte` as a deprecated type alias for one release for external API compatibility if needed.
- `services.AkteService` → `services.ProjektService`. Preserve method signatures; internals switch to `paliad.projekte`.
- Update handlers. `/api/akten` becomes an alias to `/api/projekte` (same handler, same JSON shape during transition — `projekte` additionally exposes `client_id`, `parent_project_id`, `project_type`, `path` fields).
- Update the dashboard query to aggregate by `projekte` (tree-walk already shown in §4.3).

Acceptance: the app runs end-to-end on the new schema; old routes still resolve; old JSON shapes still accepted (new fields additive).

### Phase 5 — New Mandant UI + partner cleanup

- `/mandanten` list + detail pages. Partners assign every synthetic-Mandant project to a real Mandant row (bulk "Change Mandant" on the project-detail page, or a dedicated migration UI at `/einstellungen/migration`).
- After every `projekte.client_id` in `metadata->>'synthetic'=true` has been reassigned, drop the synthetic Mandanten and enforce `paliad.projekte.client_id SET NOT NULL` (migration 021).

Acceptance: no synthetic Mandanten remain. `client_id` is NOT NULL.

### Phase 6 — Decommission `paliad.akten`

- `DROP TABLE paliad.akten` (migration 022). Everything that referenced it has been rewritten.
- Drop the legacy `paliad.can_see_akte()` function; the one-to-one function becomes `can_see_project()`.

Acceptance: `\dt paliad.akten` → not found. All FK constraints still satisfy.

### Rollback

Every migration has a `down`:
- Phases 3 and 6 are destructive DDL (drop column rename → rename back; drop table → re-create). Data preservation in those down-migrations is **not guaranteed** after the migration completes; the safe rollback window is "before Phase 3 runs in production". Document loudly.
- Phases 1, 2, 4, 5 are additive or app-level, rollback by reverting code or running `DELETE FROM paliad.projekte WHERE …`.

---

## 6. RLS policy updates

### 6.1 New policies

`paliad.projekte` — enable RLS. Policies:

```sql
CREATE POLICY projekte_select ON paliad.projekte
    FOR SELECT TO authenticated
    USING (paliad.can_see_project(id));

-- Non-admins can only create Projekte rooted in an office they belong to
-- (or a tree whose existing parent they can already see).
CREATE POLICY projekte_insert ON paliad.projekte
    FOR INSERT TO authenticated
    WITH CHECK (
        -- Creating under an existing parent? — must already see it.
        (parent_project_id IS NOT NULL AND paliad.can_see_project(parent_project_id))
        OR
        -- Root project: own office, or admin.
        (parent_project_id IS NULL
         AND (owning_office = (SELECT office FROM paliad.users WHERE id = auth.uid())
              OR (SELECT role FROM paliad.users WHERE id = auth.uid()) = 'admin'))
    );

CREATE POLICY projekte_update ON paliad.projekte
    FOR UPDATE TO authenticated
    USING      (paliad.can_see_project(id))
    WITH CHECK (paliad.can_see_project(id));

-- Delete: partner/admin only. Cascades down the tree.
CREATE POLICY projekte_delete ON paliad.projekte
    FOR DELETE TO authenticated
    USING (
        paliad.can_see_project(id)
        AND (SELECT role FROM paliad.users WHERE id = auth.uid()) IN ('partner','admin')
    );
```

`paliad.mandanten` — enable RLS. Visibility: any user who can see at least one of the Mandant's Projekte, or who is in `collaborators`, or `firm_wide_visible`, or admin.

```sql
CREATE OR REPLACE FUNCTION paliad.can_see_mandant(_mandant_id uuid)
RETURNS boolean LANGUAGE sql STABLE SECURITY DEFINER
SET search_path = paliad, public AS $$
    SELECT EXISTS (
        SELECT 1 FROM paliad.mandanten m, paliad.users u
         WHERE m.id = _mandant_id
           AND u.id = auth.uid()
           AND (
                m.firm_wide_visible
             OR m.owning_office = u.office
             OR auth.uid() = ANY (m.collaborators)
             OR u.role = 'admin'
             OR EXISTS (
                 SELECT 1 FROM paliad.projekte p
                  WHERE p.client_id = _mandant_id
                    AND paliad.can_see_project(p.id)
             )
           )
    );
$$;

CREATE POLICY mandanten_select ON paliad.mandanten
    FOR SELECT TO authenticated
    USING (paliad.can_see_mandant(id));

CREATE POLICY mandanten_insert ON paliad.mandanten
    FOR INSERT TO authenticated
    WITH CHECK (
        owning_office = (SELECT office FROM paliad.users WHERE id = auth.uid())
        OR (SELECT role FROM paliad.users WHERE id = auth.uid()) = 'admin'
    );

-- Update/Delete policies analogous; delete is partner/admin-gated.
```

### 6.2 Child-table policies — converge on `can_see_project`

Every child table's policy changes from `paliad.can_see_akte(akte_id)` to `paliad.can_see_project(project_id)`. `notizen` loses its dedicated `notiz_is_visible()` helper in favour of an inline check that dispatches by which FK is set:

```sql
CREATE POLICY notizen_all ON paliad.notizen
    FOR ALL TO authenticated
    USING (
        CASE
            WHEN project_id    IS NOT NULL THEN paliad.can_see_project(project_id)
            WHEN frist_id      IS NOT NULL THEN paliad.can_see_project(
                                                    (SELECT project_id FROM paliad.fristen WHERE id = frist_id))
            WHEN termin_id     IS NOT NULL THEN
                CASE
                    WHEN (SELECT project_id FROM paliad.termine WHERE id = termin_id) IS NULL
                        THEN (SELECT created_by FROM paliad.termine WHERE id = termin_id) = auth.uid()
                    ELSE paliad.can_see_project(
                            (SELECT project_id FROM paliad.termine WHERE id = termin_id))
                END
            WHEN akten_event_id IS NOT NULL THEN paliad.can_see_project(
                                                    (SELECT project_id FROM paliad.akten_events WHERE id = akten_event_id))
            ELSE false
        END
    )
    WITH CHECK (...same...);
```

(We may extract a helper `notiz_is_visible(project_id, frist_id, termin_id, akten_event_id)` again — symmetric to today's.)

### 6.3 Admin bootstrap

Unchanged. The `pg_advisory_xact_lock(7346298141)` onboarding gate that lets the first user self-assign `role='admin'` still works. Nothing to do.

### 6.4 Defense-in-depth at the service layer

Same pattern as today: every service mirrors the predicate in `ListVisibleForUser` for indexed performance. The SQL is wordier for the tree variant — we do it once in `ProjektService.listVisibleIDsForUser` (returns a `map[uuid.UUID]struct{}`) and re-use across list endpoints.

---

## 7. API surface changes

### 7.1 New endpoints

| Method + path | Purpose |
|---|---|
| `GET /api/mandanten`                            | List Mandanten the user can see. |
| `POST /api/mandanten`                           | Create Mandant. |
| `GET /api/mandanten/{id}`                       | Detail. |
| `PATCH /api/mandanten/{id}`                     | Update. |
| `DELETE /api/mandanten/{id}`                    | Delete (partner/admin only). |
| `GET /api/mandanten/{id}/projekte`              | List root-level Projekte under this Mandant. |
| `GET /api/projekte`                             | List top-level visible Projekte (flat root list). |
| `POST /api/projekte`                            | Create a Projekt (optionally nested via `parent_project_id`). |
| `GET /api/projekte/{id}`                        | Detail + immediate children. |
| `GET /api/projekte/{id}/tree`                   | Full subtree (depth-first). |
| `PATCH /api/projekte/{id}`                      | Update. |
| `DELETE /api/projekte/{id}`                     | Cascade delete subtree (partner/admin). |
| `GET /api/projekte/{id}/kinder`                 | Direct children (for lazy-loaded UI). |
| `POST /api/projekte/{id}/team`                  | Add project team member. |
| `DELETE /api/projekte/{id}/team/{user_id}`     | Remove member. |
| `GET /api/teams`                                | List Dezernate (+ optionally project teams). |
| `POST /api/teams`                               | Create Dezernat (admin-gated). |
| `GET /api/teams/{id}/mitglieder`                | List members. |

### 7.2 Aliased endpoints

During transition:
- `GET /api/akten` → alias of `GET /api/projekte?project_type=verfahren` (or all, with `akte_type`/`court` fields surfaced) for clients still using the old shape.
- `POST /api/akten` → alias of `POST /api/projekte` with `project_type='verfahren'` default.
- `/api/akten/{id}/fristen` → alias of `/api/projekte/{id}/fristen`.

Remove aliases after 60 days + 1 green deployment.

### 7.3 Retired endpoints

None immediately. Keeping aliases means no 404s for the UI during the Phase 4 cutover.

### 7.4 New query parameters

- `?client_id=<uuid>` on `GET /api/projekte` — scope to one Mandant's tree.
- `?project_type=<type>` — filter by type.
- `?ancestor=<uuid>` — subtree of a given root (uses `path <@`).
- `?include_children=true` on `GET /api/projekte/{id}` — one-shot detail + subtree (cheap because of the path index).

---

## 8. UI implications

### 8.1 Sidebar

Insert "Mandanten" above "Akten" in the "ARBEIT" group. Rename "Akten" → "Projekte" in a second phase once partners get used to the concept — initially, keep "Akten" as the label and add the Mandanten entry only.

```
— ARBEIT —
  Dashboard
  Mandanten          ← NEW
  Projekte           ← renamed from "Akten" (phase 2)
  Fristen
  Termine
```

### 8.2 New pages

- `/mandanten` — list. Columns: Name, Büro, #Projekte, #aktive Fristen, letzte Aktivität.
- `/mandanten/neu` — create form.
- `/mandanten/{id}` — detail with tabs: Übersicht, Projekte (the tree at this root), Fristen (aggregated), Termine (aggregated), Notizen (aggregated), Team (aggregated from all child projekt_mitglieder).
- `/projekte` — flat list of root projects + filter by Mandant, type, office.
- `/projekte/{id}` — detail. Tabs today (`verlauf`, `parteien`, `fristen`, `termine`, `dokumente`, `notizen`, `checklisten`) stay. **New first tab: "Untergeordnet"** — renders the subtree of child projekte as a collapsible list. A "Neues Untervorhaben" button under each node creates a child.
- `/projekte/neu` — create. Form adapts to `project_type`: `mandat`/`litigation`/`patent` surface no `court` / `court_ref`; `verfahren` does.

### 8.3 Detail-page tree rendering

On `/projekte/{id}` the sidebar (left sub-nav) renders the ancestor path (breadcrumbs: Mandant → Litigation → Patent → Verfahren). Children render in the Untergeordnet tab as a collapsible tree. Keep click-depth low: clicking a child navigates to that child's detail page; siblings render as flat siblings on the current page.

### 8.4 Team editor

On `/projekte/{id}` under the Team tab: list of team members with role, "Mitglied hinzufügen" modal with autocomplete fed by `GET /api/users`. Removing the `collaborators uuid[]` array means the multi-pick UI gets a proper role column and an "added_by/at" audit line, which today's model can't show.

### 8.5 Dashboard impact

Dashboard queries aggregate across **every** Projekt the user can see (all tree levels). Fristen summary widget: `SELECT * FROM paliad.fristen f JOIN paliad.projekte p ON f.project_id = p.id WHERE can_see_project(p.id) AND f.status='pending' AND f.due_date <= now() + interval '30 days'`. Same tree-agnostic pattern for Termine.

"Neu auf ..." — add a Mandanten-level aggregate: "Siemens AG: 3 neue Fristen diese Woche, 1 Verhandlung am Donnerstag". Requires a `client_id` join via `projekte` — same index pattern.

### 8.6 Fristenrechner "Save to Akte"

Rename button to "Zur Verfahren-Akte speichern" (or simpler: "Zur Akte speichern" still works because Verfahren are the most common target). The target picker is now a two-step autocomplete: Mandant → Projekt (scoped to that Mandant's tree). Or skip Mandant picker entirely and autocomplete across all visible projekte — simpler, lets the user jump straight to the right leaf by typing the court-ref.

### 8.7 Checklisten Akten-link

Minimal change: `akte_id` → `project_id` on the service layer and UI picker. Picker is the same cross-tree autocomplete.

### 8.8 CalDAV sync

No material change. Today each Termin's iCal includes the Akte's `aktenzeichen` in the DESCRIPTION. v2 includes the full path: `Siemens AG · Siemens v. Huawei · EP 1 234 567 · UPC_CFI_123/2026`. Lawyers will find events in their calendar far more easily.

---

## 9. Impact on existing features

| Feature | Change |
|---|---|
| Dashboard | Queries shift from `akten` to `projekte`; widgets aggregate tree-wide. Mandanten-level "Neu auf ..." widget added. |
| Fristenrechner | Save-to-Projekt instead of save-to-Akte. Autocomplete is cross-tree (all visible projekte). |
| Fristen list | Columns show `Mandant · Projekt` chain instead of flat Aktenzeichen. Filter by Mandant. |
| Termine list | Same. |
| Notizen | FK rename only (akte_id → project_id). Polymorphic shape preserved. |
| Checklisten | FK rename only. Picker widened to cross-tree autocomplete. |
| CalDAV | Richer DESCRIPTION (full path). Termin ↔ calendar event mapping unchanged. |
| Akten detail page | Gains Untergeordnet tab + tree sub-nav. Existing tabs keep working. |
| Audit trail (Verlauf) | `akten_events` stays as a table name (history); `akte_id` → `project_id`. New event types: `projekt_nested`, `projekt_reparented`, `mandant_assigned`, `team_member_added`, `team_member_removed`. |
| Dokumente (placeholder) | No change today (still placeholder). Future implementation attaches to the right level of the tree. |

---

## 10. Naming conventions — German, with one English holdover

**Decision: German throughout. Match everything shipped so far.**

| Concept | DB table | Go struct | Go service | URL | German UI |
|---|---|---|---|---|---|
| Client | `paliad.mandanten` | `Mandant` | `MandantService` | `/mandanten` | "Mandant" / "Mandanten" |
| Project (generic) | `paliad.projekte` | `Projekt` | `ProjektService` | `/projekte` | "Projekt" / "Projekte" |
| Project sub-type "Mandat" | (row in projekte) | — | — | (row variant) | "Mandat" (Gesamtbeziehung) |
| Project sub-type "Litigation" | (row in projekte) | — | — | (row variant) | "Streitsache" |
| Project sub-type "Patent" | (row in projekte) | — | — | (row variant) | "Patent" |
| Project sub-type "Verfahren" | (row in projekte) | — | — | (row variant) | "Verfahren" |
| Project sub-type "Projekt" | (row in projekte) | — | — | (row variant) | "Projekt" (generisch) |
| Team (structural / project) | `paliad.teams` | `Team` | `TeamService` | `/teams` (admin) | "Team" / "Teams" |
| Team member | `paliad.team_mitglieder` | `TeamMitglied` | — | (sub) | "Teammitglied" |
| Project roster | `paliad.projekt_mitglieder` | `ProjektMitglied` | — | (sub of Projekt) | "Projektmitglied" |
| Party | `paliad.parteien` | `Partei` | `ParteienService` | (sub of Projekt) | "Partei" / "Parteien" |
| Deadline | `paliad.fristen` | `Frist` | `FristService` | `/fristen` | "Frist" / "Fristen" |
| Appointment | `paliad.termine` | `Termin` | `TerminService` | `/termine` | "Termin" / "Termine" |
| Document | `paliad.dokumente` | `Dokument` | `DokumentService` | (sub) | "Dokument" |
| Audit event | `paliad.akten_events` | `AkteEvent` | (in `ProjektService`) | n/a | "Verlauf" |
| Note | `paliad.notizen` | `Notiz` | `NotizService` | cross-cutting | "Notiz" / "Notizen" |
| User | `paliad.users` | `User` | `UserService` | n/a | n/a |

**The one English holdover:** `paliad.akten_events` table name. Rationale:
- It's the audit-trail table name already shipped.
- "Verlauf" is the UI label; the table name is invisible to users.
- Migrating to `projekt_events` would churn migration history for no gain, and any historical tools (Grafana, ad-hoc SQL) keep working. Preserve the name; update the comment and the Go struct semantics.

**Why not `projekt_*` everywhere?**
- `projekt_mitglieder` reads cleanly; kept.
- `projekt_events` would be clean too but see above — churn:benefit ratio unfavourable.

**URL aliases.** `/akten` and `/akten/{id}` keep redirecting to `/projekte` and `/projekte/{id}` indefinitely (bookmark preservation). No hard break. 301 from `/akten/neu` → `/projekte/neu`.

---

## 11. Open questions & deferrable decisions

1. **Patent registry.** Should `external_ref` on a `patent`-type projekt be a FK to a firm-wide `paliad.patente` table (EP number + metadata, shared across Mandanten)? Not today — a single litigation's view of a patent is legitimately separate from the firm-wide "patents we've ever seen" list. Revisit when HLC asks for firm-wide IP inventory. If/when built, add `patent_registry_id uuid` on `projekte` where `project_type='patent'`.

2. **Conflict of interest / Chinese walls.** Partner-level override to restrict a single project to its team roster only (strip office-scope). Not built now; add `restricted boolean` in a follow-on migration, and extend the predicate to skip the office-scope branch when `restricted = true`.

3. **Practice-group scoping.** `paliad.users.practice_group` is already free-text. If HLC splits Patents Litigation vs. Patents Prosecution and wants wall-like isolation, add `visible_to_groups text[]` on `projekte` + predicate extension. Not now.

4. **Matrix management.** A user belongs to one Dezernat (structural) today. If partners share associates (e.g., a "tax-patent" associate is on both the Patents and the Tax Dezernate), relax `team_mitglieder` — it already allows multiple memberships. The onboarding UI currently picks one Dezernat; relax when needed.

5. **Billing hooks.** `mandanten.billing_reference` is provisioned but not wired. Deliberate: HLC has firm-wide billing; Paliad does not compete. Field exists so the UI can show it and the future Outlook/Exchange integration can look it up.

6. **External collaborators.** A Milan boutique working on a case today would go into `projekt_mitglieder` only if they have Supabase accounts. Building external-party access (email-only, scoped, audit-logged) is a post-foundation feature; deferred.

7. **Hard delete vs. archive.** `status='archived'` on Mandanten and Projekte exists; hard-delete is cascade via FK. Consider a `archived_at` + soft-delete semantics once we have retention-policy rules. Not now.

8. **ltree label encoding.** UUIDs with hyphens aren't valid ltree labels. Replace `-` with `_`, or hash. Implementer's call; both work, hash is shorter but loses traceability.

---

## 12. Trade-off summary (for the head)

| Choice | Alternative | Why I picked this | Cost |
|---|---|---|---|
| Single `projekte` tree with type enum | Separate tables per type (mandate/litigation/patent/case) | Polymorphic FK pain, cross-tree queries, UI shared components | `project_type` CHECK has to grow carefully |
| ltree materialised path | Recursive CTE | RLS is the hottest call site; O(log n) tree queries matter | Extension dependency; label encoding quirk |
| Single `project_id` on child tables | Multi-level polymorphic FKs | RLS simplicity, uniform service code | Discipline: every Fristen/Termin has a Projekt, even "client-level" rare cases |
| `mandanten` as a separate table | Project with `type='mandat'` as the conceptual client | Clients have no deadlines/termine/parteien; they're a different shape. Also: Mandant outlives any specific matter. | One extra table |
| `teams` shared between Dezernat + project_team | Two separate tables | Single roster table (`team_mitglieder`), UI/service reuse | Partial CHECK constraints are a minor smell |
| `projekt_mitglieder` junction in addition to `teams` | Route project-team membership through `teams` | Hot path for RLS wants a dedicated two-column junction | Small duplication of concept |
| German naming | Mixed EN/DE | Continuity with everything shipped; audience speaks German | German plural forms (`mandanten`, `projekte`) in URLs |
| Tree-connected visibility | Downward-only (seeing ancestor grants ancestor+descendants only) | Matches how associate-on-one-case actually needs parent context | Slightly bigger RLS query |
| Phased non-destructive migration with preserved UUIDs | Dump-transform-reload | Zero downtime; every child-table row survives untouched | Requires discipline: match UUIDs in the backfill exactly |

---

## 13. Who implements?

Recommendation: **I (cronus) can implement the foundation** — migrations 018–022, the predicate function, the new `ProjektService`, and the API alias shim. Reasons:
- I wrote the design; I know the edge cases.
- The schema work is security-critical (RLS policy + path trigger); having design-context on the implementer cuts review cycles.
- The pragmatic split: cronus does schema + services + aliases + RLS (Phase 1–4). A parallel coder worker does the Mandanten UI (`/mandanten` list + detail + create + partner cleanup wizard) in Phase 5. Cronus does Phase 6 decommission.

If the head prefers to keep cronus on design duty and hand implementation to a coder, the design is detailed enough to hand off — every schema has columns, constraints, triggers, RLS snippets, and migration acceptance criteria. I'd still want to review the RLS + path trigger PR before merge.

---

## 14. Acceptance criteria for the design itself

A "yes" on this design means head agrees to:

- [ ] Mandanten as a first-class table (not just a Projekt type).
- [ ] Single `projekte` tree with 5-value type enum.
- [ ] ltree materialised path + GiST index.
- [ ] Single `project_id` FK on fristen/termine/dokumente/parteien/akten_events/checklist_instances; `notizen` keeps its polymorphic shape with `akte_id` renamed to `project_id`.
- [ ] Tree-connected visibility predicate (ancestors + descendants both reachable from any team node).
- [ ] `paliad.teams` as a single table for Dezernat + project-team, with the two-kind shape CHECK.
- [ ] `projekt_mitglieder` as a hot-path junction, *and* optional `teams` rows of type `project_team` for team-level features.
- [ ] Phased migration with preserved UUIDs between `akten` and `projekte` rows.
- [ ] German naming throughout; `akten_events` table name preserved for continuity.
- [ ] `/akten` URLs alias to `/projekte` indefinitely.