docs(03): capture phase 3 context - Module System & Domaincheck
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,103 @@
|
|||||||
|
# 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:** 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
|
||||||
|
|
||||||
|
</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*
|
||||||
Reference in New Issue
Block a user