schalli
6e99ccc2a1
- Remove frontend artifacts from 05-03 must_haves (belong to 05-04) - Remove trailing XML generation artifacts from 05-04 and 05-05 - Update ROADMAP Phase 5: 5 plans across 4 waves Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
230 lines
10 KiB
Markdown
230 lines
10 KiB
Markdown
# Roadmap: Tessera
|
|
|
|
## Overview
|
|
|
|
Tessera delivers a modular portal platform where tenants activate workflow modules from a marketplace, interact through a configurable dashboard, and optionally use a desktop wrapper. The roadmap builds foundation-first (Docker + DB + shell), layers in authentication and multi-tenancy, establishes the module system with a proof-of-concept module, adds marketplace and portal navigation, delivers the dashboard experience, and wraps up with desktop client and CI/CD integration.
|
|
|
|
## Phases
|
|
|
|
**Phase Numbering:**
|
|
|
|
- Integer phases (1, 2, 3): Planned milestone work
|
|
- Decimal phases (2.1, 2.2): Urgent insertions (marked with INSERTED)
|
|
|
|
Decimal phases appear between their surrounding integers in numeric order.
|
|
|
|
- [ ] **Phase 1: Foundation & Portal Shell** - Docker infrastructure, database with RLS, frontend shell with i18n and theming
|
|
- [ ] **Phase 2: Authentication & Multi-Tenancy** - User accounts, sessions, RBAC, tenant isolation per request
|
|
- [ ] **Phase 3: Module System & Domaincheck** - Module SDK, registry, lazy loading, and first proof-of-concept module
|
|
- [ ] **Phase 4: Marketplace & Portal Navigation** - Module catalog, licensing, activation, and sidebar integration
|
|
- [ ] **Phase 5: Dashboard & Calendar** - Configurable widget grid with drag-and-drop, core widgets, and calendar integration
|
|
- [ ] **Phase 6: Desktop Client & CI/CD** - Tauri wrapper for Windows/Linux and automated Gitea integration
|
|
|
|
## 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
|
|
**Wave 1**
|
|
|
|
- [x] 01-01-PLAN.md -- Walking Skeleton: Monorepo + Docker Compose stack with NestJS, Next.js, PostgreSQL, Traefik
|
|
|
|
**Wave 2** *(blocked on Wave 1 completion)*
|
|
|
|
- [x] 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**: 5 plans
|
|
|
|
**Wave 1**
|
|
|
|
- [x] 02-01-PLAN.md -- Backend Auth Foundation: Prisma schema, RLS migration, JWT Passport auth, admin seed, tenant middleware
|
|
|
|
**Wave 2** *(blocked on Wave 1 completion)*
|
|
|
|
- [x] 02-02-PLAN.md -- Frontend Auth & CRUD: Login page, Next.js middleware, user/tenant management UI, auth-wired portal
|
|
- [ ] 02-03-PLAN.md -- Password Reset & Mail: SUS package verification, MailModule, password reset flow, force-change interceptor
|
|
|
|
**Wave 3** *(blocked on Wave 2 completion)*
|
|
|
|
- [ ] 02-04-PLAN.md -- LDAP Integration: LDAP sync service, per-tenant config, field mapping, admin UI
|
|
|
|
**Wave 4** *(blocked on Wave 3 completion)*
|
|
|
|
- [ ] 02-05-PLAN.md -- Visual Verification: Human confirms complete auth and multi-tenancy flow
|
|
|
|
**UI hint**: yes
|
|
|
|
### 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**: 4 plans
|
|
|
|
**Wave 1**
|
|
|
|
- [x] 03-01-PLAN.md -- Module SDK, Prisma Registry, Activation API
|
|
|
|
**Wave 2** *(blocked on Wave 1 completion)*
|
|
|
|
- [x] 03-02-PLAN.md -- Domaincheck Module: Backend DNS + Frontend UI
|
|
- [x] 03-03-PLAN.md -- Lazy Loading, Category Pages, Expanded Module View
|
|
|
|
**Wave 3** *(blocked on Wave 2 completion)*
|
|
|
|
- [ ] 03-04-PLAN.md -- Visual Verification: Human confirms module system
|
|
|
|
**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**: 4 plans
|
|
|
|
**Wave 1**
|
|
|
|
- [ ] 04-01-PLAN.md -- Test infra (Vitest) + marketplace i18n + Marketplace page slice: card grid browse + activate (MRKT-01/02/04)
|
|
|
|
**Wave 2** *(blocked on Wave 1 completion)*
|
|
|
|
- [ ] 04-02-PLAN.md -- Marketplace refinements: search/category/status filters, deactivation dialog, toast, Super-Admin tenant context, module detail page
|
|
- [ ] 04-03-PLAN.md -- Sidebar enhancement: Next.js Link + usePathname active state, per-module links, sidebar search, live refresh (PRTAL-02/03/05, MRKT-03)
|
|
|
|
**Wave 3** *(blocked on Wave 2 completion)*
|
|
|
|
- [ ] 04-04-PLAN.md -- Visual Verification: Human confirms marketplace, activation, tenant context, and sidebar navigation
|
|
|
|
**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**: 4 plans
|
|
|
|
**Wave 1**
|
|
|
|
- [ ] 05-01-PLAN.md -- Dashboard slice: Prisma models + Dashboard CRUD API + grid with edit-mode + clock widget + settings shell + header link + i18n (DASH-01/02/03/07)
|
|
|
|
**Wave 2** *(blocked on Wave 1 completion)*
|
|
|
|
- [ ] 05-02-PLAN.md -- Search + Notes widgets + widget settings panel + SearchProvider backend (DASH-04/06)
|
|
|
|
**Wave 3** *(blocked on Wave 2 completion)*
|
|
|
|
- [ ] 05-03-PLAN.md -- Calendar slice: CalendarSource model + AES-256-GCM crypto + CalDAV/ICS/Exchange providers + event aggregation + calendar widget + calendar settings (CAL-01/02/03, DASH-05)
|
|
|
|
**Wave 4** *(blocked on Wave 3 completion)*
|
|
|
|
- [ ] 05-04-PLAN.md -- Visual Verification: Human confirms dashboard grid, all four widgets, settings, and calendar integration
|
|
|
|
**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**: 5 plans
|
|
|
|
**Wave 1**
|
|
|
|
- [ ] 05-01-PLAN.md -- Dashboard foundation: Prisma models, CRUD API, grid, edit-mode, clock widget, settings shell, header link, i18n
|
|
|
|
**Wave 2** *(blocked on Wave 1 completion)*
|
|
|
|
- [ ] 05-02-PLAN.md -- Search + Notes widgets, widget settings panel, SearchProvider backend
|
|
|
|
**Wave 3** *(blocked on Wave 2 completion)*
|
|
|
|
- [ ] 05-03-PLAN.md -- Calendar backend: Prisma model, AES-256-GCM crypto, source CRUD, CalDAV/ICS/Exchange providers, event aggregation
|
|
- [ ] 05-04-PLAN.md -- Calendar frontend: calendar widget, calendar settings page, API client (depends on 05-03)
|
|
|
|
**Wave 4** *(blocked on Wave 3 completion)*
|
|
|
|
- [ ] 05-05-PLAN.md -- Visual Verification: Human confirms dashboard, widgets, calendar, settings
|
|
|
|
**UI hint**: yes
|
|
|
|
## Progress
|
|
|
|
**Execution Order:**
|
|
Phases execute in numeric order: 1 -> 2 -> 3 -> 4 -> 5 -> 6
|
|
|
|
| Phase | Plans Complete | Status | Completed |
|
|
|-------|----------------|--------|-----------|
|
|
| 1. Foundation & Portal Shell | 2/3 | In Progress | - |
|
|
| 2. Authentication & Multi-Tenancy | 2/5 | In Progress| |
|
|
| 3. Module System & Domaincheck | 3/4 | In Progress| |
|
|
| 4. Marketplace & Portal Navigation | 0/4 | Not started | - |
|
|
| 5. Dashboard & Calendar | 0/4 | Not started | - |
|
|
| 6. Desktop Client & CI/CD | 0/TBD | Not started | - |
|