Files

T

schalli 6e2f6e7c3e docs(03): create phase 3 plans - Module System & Domaincheck

4 plans in 3 waves:
- 03-01: Module SDK + Registry + Activation API
- 03-02: Domaincheck backend + frontend (vertical slice)
- 03-03: Lazy Loading + Category Pages
- 03-04: Visual Verification

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

2026-06-19 12:14:54 +02:00

4.9 KiB

Raw Blame History

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: Module werden in Kategorien gruppiert (z.B. "Domain-Tools"). Eine Kategorie-Seite zeigt alle Module dieser Kategorie im Hauptbereich — nicht ein einzelnes kleines Modul auf der ganzen Seite.
D-05a: Einheitliches Look & Feel: Module sollen als Karten/Panels innerhalb der Kategorie-Seite erscheinen, sodass auch kleine Module nicht verloren wirken.
D-05b: Bei Bedarf kann ein Modul auch eine erweiterte/Vollbild-Ansicht haben (z.B. wenn der Benutzer es oeffnet), aber die Standard-Ansicht ist kompakt in der Kategorie-Uebersicht.

Module SDK

D-06: Modul-Interface als @tessera/sdk Package im Monorepo (packages/sdk oder packages/module-sdk).
D-07: Module werden per Datenbank-Registry verwaltet — kein Filesystem-Scanning.
D-08: Aktivierung/Deaktivierung pro Mandant durch Admin ohne Neustart (Requirement MOD-03, MRKT-02).
D-09: Jedes Modul gehoert zu einer Kategorie (z.B. "Domain-Tools", "Utilities"). Kategorie ist Teil der Modul-Metadaten im SDK.

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

4.9 KiB Raw Blame History