tessera-ctl/.planning/phases/03-module-system-domaincheck/03-CONTEXT.md

Phase 3: Module System & Domaincheck - Context

Gathered: 2026-06-19 Status: Ready for planning

## Phase Boundary

Modulares Plugin-System mit versioniertem SDK (@tessera/sdk), datenbankgestuetzter Registry, Aktivierung/Deaktivierung ohne Neustart, und Lazy Loading der Modul-UIs. Validiert durch ein funktionierendes Domaincheck-Modul (Domain eingeben, TLD-Varianten pruefen, frei/registriert anzeigen). Kein Marketplace-UI, keine Sidebar-Integration — das kommt in Phase 4.

## Implementation Decisions

Domaincheck-Modul

• D-01: Ergebnis-Anzeige: Nur Status — Domain frei (gruen) oder registriert (rot). Keine WHOIS-Details.
• D-02: Eingabe: Benutzer gibt einen Domain-Namen ein (z.B. "beispiel"), System prueft automatisch TLD-Varianten (.de, .com, .net, .org) und zeigt alle Ergebnisse.
• D-03: TLD-Liste soll konfigurierbar sein (Standard-TLDs vorausgewaehlt, erweiterbar).

Modul-Darstellung

• D-04: Claude entscheidet das UI-Pattern fuer die Modul-Darstellung basierend auf der bestehenden Architektur (Next.js App Router, Route Groups, Lazy Loading).

Module SDK

• D-05: Modul-Interface als @tessera/sdk Package im Monorepo (packages/sdk oder packages/module-sdk).
• D-06: Module werden per Datenbank-Registry verwaltet — kein Filesystem-Scanning.
• D-07: Aktivierung/Deaktivierung pro Mandant durch Admin ohne Neustart (Requirement MOD-03, MRKT-02).

Claude's Discretion

• Modul-UI-Pattern: eigene Seite vs. Panel vs. anderes — basierend auf bestehender App Router Architektur
• SDK Interface Design: Lifecycle Hooks, Export-Konventionen, Settings-Schema
• Domain-Pruefung Technik: RDAP, DNS, WHOIS-Library — soll zuverlaessig und schnell sein
• Backend-Integration: Wie Module eigene API-Endpoints registrieren (NestJS Dynamic Modules)
• Lazy Loading Strategie: Next.js dynamic imports, Code Splitting Pattern

<canonical_refs>

Canonical References

Downstream agents MUST read these before planning or implementing.

Projekt-Kontext

• .planning/PROJECT.md — Gesamtprojekt, Core Value, Constraints
• .planning/REQUIREMENTS.md — Phase-3-Requirements: MOD-01..04, DCHK-01..03
• .planning/ROADMAP.md — Phase-Ziel und Success Criteria

Vorherige Phasen

• .planning/phases/01-foundation-portal-shell/01-CONTEXT.md — Design-Entscheidungen, OKLCH Tokens, Layout-Pattern
• .planning/phases/02-authentication-multi-tenancy/02-CONTEXT.md — Auth, Rollen, Mandanten-Modell, RLS

Research

• .planning/research/STACK.md — Technologie-Stack (NestJS 11, Prisma 7, Next.js)
• .planning/research/ARCHITECTURE.md — Architektur-Patterns

</canonical_refs>

<code_context>

Existing Code Insights

Reusable Assets

• apps/api/prisma/schema.prisma — Tenant/User/Role-Schema, erweiterbar fuer Module-Registry
• apps/api/src/prisma/prisma.service.ts — Prisma-Client Service als DB-Zugang
• apps/api/src/prisma/prisma-tenant.extension.ts — RLS-Extension fuer Tenant-Isolation (Module muessen tenant-aware sein)
• apps/web/src/app/(portal)/page.tsx — Dashboard-Seite als Vorlage fuer Modul-Seiten
• packages/shared/src/index.ts — Shared Package existiert, SDK kann parallel angelegt werden

Established Patterns

• NestJS Module mit Controller + Service + DTOs (auth, tenant, user, ldap, mail)
• Prisma-Schema-Erweiterung via Migration
• Next.js App Router Route Groups: (auth) fuer Login, (portal) fuer authentifizierte Seiten
• Zustand Stores fuer Client-State
• next-intl fuer alle UI-Strings
• Docker-Build mit Multi-Stage (apps/api/Dockerfile, apps/web/Dockerfile)

Integration Points

• Module brauchen Tenant-Kontext (tenantId aus JWT/Session)
• Module-UI muss im (portal) Route Group leben (AppShell mit Header + Sidebar)
• API-Endpoints fuer Module muessen durch Auth-Guard geschuetzt sein
• Prisma-Schema muss um Module-Registry erweitert werden

</code_context>

## Specific Ideas

• Domaincheck: Eingabefeld oben, darunter Tabelle/Liste mit TLD-Varianten und farbigem Status-Badge (gruen=frei, rot=registriert)
• Module-Registry: Prisma-Model mit name, version, description, isActive, tenantId-Relation
• SDK: TypeScript Interface das Frontend-Component-Path, Backend-Routes, und Metadata definiert

## Deferred Ideas

None — discussion stayed within phase scope

---

Phase: 3-Module System & Domaincheck Context gathered: 2026-06-19