Files
tessera-ctl/.planning/PROJECT.md
T
schalli 862988966f
Tessera CI/CD / Lint & Type Check (push) Successful in 44s
Tessera CI/CD / Tests (push) Successful in 52s
Tessera CI/CD / Build & Publish Images (push) Successful in 7s
docs: Meilenstein-Buchhaltung auf den tatsaechlichen Stand gebracht
Die Unterlagen fuehrten weiterhin v1.1 als laufenden Meilenstein, obwohl alle 17
Phasen und 83 Plaene ausgefuehrt sind und die Phasen 15 bis 17 zu v1.2 gehoeren. Wer
neu draufschaute, sah einen falschen Projektstand.

Korrigiert in ROADMAP.md, STATE.md und PROJECT.md:

v1.0 bleibt ausgeliefert. v1.1 traegt jetzt den ehrlichen Zwischenstand — alle Plaene
fertig, alle Phasen ausser 14 verifiziert, offen allein der Live-Test von Phase 14
gegen ein echtes Exchange-Postfach; inhaltlich abgeschlossen, formal nicht. v1.2 ist
abgeschlossen, alle drei Phasen verifiziert. Ergaenzt um den Hinweis, dass kein neuer
Meilenstein begonnen wurde und die drei verbleibenden Pruefpunkte Fremdsysteme
brauchen.

Ausserdem die Zeile zu Phase 2 praezisiert. Sie stand auf "Incomplete", was nach
liegengebliebener Arbeit klang und im Widerspruch zu v1.0 als ausgeliefertem
Meilenstein stand. Tatsaechlich sind alle vier Baupläne fertig und seit v1.0 in
Betrieb; offen ist allein die nie ausgefuehrte Browser-Abnahme, die der User am
2026-09-07 bewusst zurueckgestellt hat, weil Tessera zunaechst nur intern laeuft.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5jtbGzC5Sf9npJ3JCjKhq
2026-09-07 14:11:05 +02:00

5.3 KiB
Raw Blame History

Tessera

What This Is

Tessera ist eine modulare, Docker-basierte Webplattform fuer interne Workflow-Automatisierung und Tool-Integration. Sie bietet ein Portal mit Seitenleiste, konfigurierbarem Dashboard und einem Marketplace fuer lizenzierbare Module. Perspektivisch soll Tessera auch an externe Kunden verkauft werden — Mandantenfaehigkeit ist von Anfang an eingeplant.

Core Value

Eine zentrale Plattform, in der beliebige Workflow-Tools als Module lizenziert, aktiviert und genutzt werden koennen — ohne zwischen verschiedenen Anwendungen wechseln zu muessen.

Current Milestone: v1.2 Plattform-Berechtigungen (abgeschlossen 2026-09-07)

Goal: Tessera-Modul, das Vergabeportale nach Ausschreibungen durchsucht, nach Kriterien filtert, Treffer im Portal anzeigt und optional per E-Mail versendet.

Target features:

  • Zentrale Datenquelle: DÖE OpenData-API (oeffentlichevergabe.de, eForms/OCDS, auth-frei)
  • Portal-Adapter: 1× AI-AG NetServer (lhs-vpbw, tender24, vergabe.landbw), 1× cosinex (DTVP)
  • E-Mail-Alert-Ingestion für Unterschwellen-Portale (nutzt bestehende DKV-Inbox-Infrastruktur)
  • RSS-Quellen: subreport-elvis, service.bund.de
  • Normalisiertes Ausschreibungs-Schema (OCDS-orientiert) + Dedup über Quellen
  • Filter-Engine: Stichwörter, Region/PLZ/Bundesland, CPV/Branche, Frist & Auftragswert
  • Durchsuchbare UI-Trefferliste mit Detailansicht
  • Optionaler E-Mail-Versand (periodischer Digest + Sofort-Alert), im Webinterface konfigurierbar
  • Meiden (AGB-Verbot automatisierter Zugriffe): vergabe24, aumass

Key context: Neues Modul im bestehenden Monorepo, multi-tenant, analog DKV-Fleet- und Cert-Manager-Modul. Feasibility-Research in .planning/research/ausschreibungs-portale-feasibility.md. Phasen setzen die v1.0-Nummerierung fort (ab Phase 10).

Requirements

Validated

(None yet — ship to validate)

Active

  • Modulares Portal mit Kopfzeile und Seitenleiste (Kategorien + Module)
  • Benutzerauthentifizierung (initialer Admin, manuelle Benutzerverwaltung, LDAP-Anbindung)
  • Mandantenfaehigkeit (Multi-Tenancy)
  • Marketplace fuer Module (Lizenzierung, Aktivierung, Kategorisierung)
  • Konfigurierbares Dashboard (Drag & Drop, Groessenaenderung, Widgets: Uhr, Suchleiste, Kalender, Notizen)
  • Domaincheck-Modul (erstes Beispielmodul: Domain-Verfuegbarkeitspruefung)
  • Light/Dark Theme Toggle
  • Mehrsprachigkeit (Deutsch + Englisch, i18n)
  • Desktop-Client (Electron/Tauri Wrapper fuer Windows/Linux)
  • Automatisierte Gitea-Integration (Commits, Pushes, Merges — so wenig manuell wie moeglich)

Out of Scope

  • Externe Drittanbieter-Module — erst spaeter, aktuell nur eigene Module (mit Claude)
  • Bezahlsystem/Payment — Lizenzierung erstmal per Admin-Freischaltung, Bezahlung kommt spaeter
  • Mobile App — Web-first, Desktop-Wrapper reicht fuer v1

Context

  • Entwicklung erfolgt ausschliesslich mit Claude (Nutzer ist kein Programmierer)
  • Interne Nutzung als Testphase, spaeterer Verkauf an externe Kunden geplant
  • Module sind breit gefaechert: E-Mail-Tools, Datenbank-Tools, LDAP-Tools, Konvertierungen etc.
  • Dashboard ist unabhaengig von Modulen — persoenlicher Startbereich mit frei platzierbaren Widgets
  • Bestehendes Gitea-Setup vorhanden, soll als Versionskontrolle genutzt werden
  • Bereits teilweise umgesetztes Dashboard-Konzept vorhanden

Constraints

  • Infrastruktur: Docker-basiert — alle Komponenten als Container
  • Datenbank: PostgreSQL oder MariaDB (Entscheidung durch Claude)
  • Authentifizierung: Initialer Admin-Account + manuelle Benutzerverwaltung + LDAP
  • Versionierung: Automatisierte Gitea-Integration (minimaler manueller Aufwand)
  • Entwicklung: Alles wird von Claude gebaut — Architektur muss wartbar und verstaendlich sein
  • Mandantenfaehigkeit: Von Anfang an in der Architektur verankert

Key Decisions

Decision Rationale Outcome
Docker als Deployment-Basis Portabilitaet, einfache Installation, Isolation — Pending
PostgreSQL als Datenbank Robust, mandantenfaehig, hervorragender Docker-Support, JSON-Spalten fuer flexible Modul-Daten — Pending
Modularer Marketplace mit Lizenzierung Kernkonzept: Module erst nach Freischaltung sichtbar und nutzbar — Pending
Light/Dark Theme von Anfang an Benutzerfreundlichkeit, professioneller Eindruck — Pending
i18n (DE+EN) von Anfang an Spaeteres Nachrüsten ist aufwaendiger als fruehe Integration — Pending
Desktop-Wrapper (Electron/Tauri) Installierbarkeit auf Windows/Linux neben Browser-Zugriff — Pending

Evolution

This document evolves at phase transitions and milestone boundaries.

After each phase transition (via /gsd-transition):

  1. Requirements invalidated? → Move to Out of Scope with reason
  2. Requirements validated? → Move to Validated with phase reference
  3. New requirements emerged? → Add to Active
  4. Decisions to log? → Add to Key Decisions
  5. "What This Is" still accurate? → Update if drifted

After each milestone (via /gsd-complete-milestone):

  1. Full review of all sections
  2. Core Value check — still the right priority?
  3. Audit Out of Scope — reasons still valid?
  4. Update Context with current state

Last updated: 2026-09-07 — v1.2 Plattform-Berechtigungen abgeschlossen; kein neuer Meilenstein begonnen