schalli
6e2f6e7c3e
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>
107 lines
4.9 KiB
Markdown
107 lines
4.9 KiB
Markdown
# Phase 3: Module System & Domaincheck - Context
|
|
|
|
**Gathered:** 2026-06-19
|
|
**Status:** Ready for planning
|
|
|
|
<domain>
|
|
## 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.
|
|
|
|
</domain>
|
|
|
|
<decisions>
|
|
## 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
|
|
|
|
</decisions>
|
|
|
|
<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>
|
|
|
|
<specifics>
|
|
## 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
|
|
|
|
</specifics>
|
|
|
|
<deferred>
|
|
## Deferred Ideas
|
|
|
|
None — discussion stayed within phase scope
|
|
|
|
</deferred>
|
|
|
|
---
|
|
|
|
*Phase: 3-Module System & Domaincheck*
|
|
*Context gathered: 2026-06-19*
|