docs(01): create phase plan

.planning/ROADMAP.md

@@ -7,6 +7,7 @@ Tessera delivers a modular portal platform where tenants activate workflow modul
 ## Phases
 
 **Phase Numbering:**
+
 - Integer phases (1, 2, 3): Planned milestone work
 - Decimal phases (2.1, 2.2): Urgent insertions (marked with INSERTED)
 
@@ -22,86 +23,112 @@ Decimal phases appear between their surrounding integers in numeric order.
 ## Phase Details
 
 ### Phase 1: Foundation & Portal Shell
+
 **Goal:** Users can access a running portal application with responsive layout, theme switching, and bilingual interface -- the structural frame into which all features will be placed.
 **Mode:** mvp
 **Depends on**: Nothing (first phase)
 **Requirements**: INFRA-01, INFRA-02, INFRA-03, PRTAL-01, PRTAL-04, UI-01, UI-02, UI-03
 **Success Criteria** (what must be TRUE):
+
   1. User can access the portal in a browser served from a Docker Compose stack with PostgreSQL
   2. User sees a responsive layout with header (branding area) and sidebar frame that adapts to screen size
   3. User can toggle between light and dark theme and the preference persists
   4. User can switch between German and English interface language
   5. All UI strings are rendered through the i18n framework (no hardcoded text)
-**Plans**: 3 plans
-Plans:
+
+**Plans**: 3 plansPlans:
+**Wave 1**
+
 - [ ] 01-01-PLAN.md -- Walking Skeleton: Monorepo + Docker Compose stack with NestJS, Next.js, PostgreSQL, Traefik
+
+**Wave 2** *(blocked on Wave 1 completion)*
+
 - [ ] 01-02-PLAN.md -- Portal Shell: Design tokens, i18n (DE/EN), theme switching, responsive layout with header + sidebar
+
+**Wave 3** *(blocked on Wave 2 completion)*
+
 - [ ] 01-03-PLAN.md -- Visual Verification: Human confirms portal appearance and interactions
+
 **UI hint**: yes
 
 ### Phase 2: Authentication & Multi-Tenancy
+
 **Goal:** Users can securely log in, manage accounts, and operate within isolated tenant boundaries -- every request is scoped to the correct tenant with data fully separated at the database level.
 **Mode:** mvp
 **Depends on**: Phase 1
 **Requirements**: AUTH-01, AUTH-02, AUTH-03, AUTH-04, AUTH-05, AUTH-06, TNNT-01, TNNT-02, TNNT-03
 **Success Criteria** (what must be TRUE):
+
   1. Initial admin account is created automatically from Docker environment variables on first startup
   2. Admin can create, edit, and delete user accounts with role assignment (Admin/User)
   3. User can log in and log out, with session surviving browser refresh
   4. Admin can create and manage tenants, and each user's data is isolated per tenant via RLS
   5. Users can be imported from an LDAP/AD directory
+
 **Plans**: TBD
 
 ### Phase 3: Module System & Domaincheck
+
 **Goal:** The platform can discover, register, and load modules dynamically -- validated end-to-end by a working Domaincheck module that users can interact with.
 **Mode:** mvp
 **Depends on**: Phase 2
 **Requirements**: MOD-01, MOD-02, MOD-03, MOD-04, DCHK-01, DCHK-02, DCHK-03
 **Success Criteria** (what must be TRUE):
+
   1. Modules are registered in a database-driven registry with a versioned SDK interface
   2. An admin can activate and deactivate a module without restarting the application
   3. Module UIs load on demand (lazy loading) -- no bundle bloat from inactive modules
   4. User can open the Domaincheck module, enter a domain, and see whether it is registered or available
+
 **Plans**: TBD
 **UI hint**: yes
 
 ### Phase 4: Marketplace & Portal Navigation
+
 **Goal:** Users can browse available modules in a categorized marketplace, admins can activate modules per tenant, and activated modules appear in the sidebar for navigation.
 **Mode:** mvp
 **Depends on**: Phase 3
 **Requirements**: MRKT-01, MRKT-02, MRKT-03, MRKT-04, PRTAL-02, PRTAL-03, PRTAL-05
 **Success Criteria** (what must be TRUE):
+
   1. User can browse a marketplace view showing all available modules with descriptions and categories
   2. Admin can activate or deactivate modules for their tenant from the marketplace
   3. Only activated modules appear in the left sidebar, grouped by category
   4. User can select a module from the sidebar and it opens in the main content area
   5. User can search and filter modules in the sidebar
+
 **Plans**: TBD
 **UI hint**: yes
 
 ### Phase 5: Dashboard & Calendar
+
 **Goal:** Users have a personal, configurable start page with freely arrangeable widgets -- including clock, search, notes, and calendar with external calendar source integration.
 **Mode:** mvp
 **Depends on**: Phase 4
 **Requirements**: DASH-01, DASH-02, DASH-03, DASH-04, DASH-05, DASH-06, DASH-07, CAL-01, CAL-02, CAL-03
 **Success Criteria** (what must be TRUE):
+
   1. User sees a configurable dashboard as their start page with a drag-and-drop grid
   2. User can add, reposition, and resize widgets (clock, search bar, calendar, notes)
   3. Dashboard layout is saved per user and restored on next login
   4. User can configure external calendar sources (WebDAV, Exchange, ICS) in settings
   5. Calendar widget shows upcoming events from selected calendar sources
+
 **Plans**: TBD
 **UI hint**: yes
 
 ### Phase 6: Desktop Client & CI/CD
+
 **Goal:** Users can install and run Tessera as a native desktop application, and the development workflow includes automated version control via Gitea.
 **Mode:** mvp
 **Depends on**: Phase 5
 **Requirements**: DESK-01, DESK-02, INFRA-04
 **Success Criteria** (what must be TRUE):
+
   1. User can install a Tauri-based desktop app on Windows or Linux
   2. Desktop app connects to the existing web backend (no standalone server)
   3. Code changes are automatically committed and pushed to Gitea with minimal manual intervention
+
 **Plans**: TBD
 
 ## Progress