# API Router Procedure-Support Pattern

Ziel: Top-Level-Router bleiben dünne tRPC-Kompositionsschichten. Orchestrierung, Audit-Logik und
zusammengehörige Input-Schemas wandern in ein benachbartes `*-procedure-support.ts` Modul.

## Struktur

- `router/<domain>.ts`
  Enthält nur Procedure-Wiring, Rollen-Gates und die Delegation an benannte Support-Funktionen.
- `router/<domain>-procedure-support.ts`
  Enthält:
  - zusammengehörige `zod`-Input-Schemas für Router-Procedures
  - DB-Orchestrierung und Guard-Checks
  - Audit-Aufrufe
  - kleine private Hilfsfunktionen wie `withAuditUser(...)`
- `router/<domain>-support.ts`
  Bleibt für pure Builder-, Resolver- und Transform-Helfer reserviert.

## Teststrategie

- `__tests__/<domain>-support.test.ts`
  Deckt reine Helper-Funktionen ab.
- `__tests__/<domain>-procedure-support.test.ts`
  Deckt Orchestrierung, Audit-Snapshots und Guard-Verhalten ab.
- `__tests__/<domain>-router.test.ts`
  Deckt echte `createCaller`-Pfade ab und hält den Router als dünne Integrationsschicht ehrlich.

## Guardrails

- Öffentliche Router-Contracts bleiben stabil.
- Keine Logik zurück in den Top-Level-Router ziehen.
- Vorhandene pure Support-Module weiterverwenden statt duplizieren.
- Slice-Tests gezielt fahren; globales `tsc --noEmit` nur dort nutzen, wo kein fremder Blocker aktiv ist.

## Referenz-Slices

- `rate-card`
- `effort-rule`
- `experience-multiplier`
- `management-level`
- `blueprint`
- `client`