CapaKraken/docs/api-router-procedure-support-pattern.md

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