diff --git a/.planning/phases/03-module-system-domaincheck/03-CONTEXT.md b/.planning/phases/03-module-system-domaincheck/03-CONTEXT.md
new file mode 100644
index 0000000..0963063
--- /dev/null
+++ b/.planning/phases/03-module-system-domaincheck/03-CONTEXT.md
@@ -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*