# Plan — Study Companion MVP

## Ziel

Ein minimaler Study Companion soll Studierenden helfen, ihren Lernstoff strukturiert zu organisieren, konkrete Lernsessions durchzufuehren und den eigenen Fortschritt sichtbar zu machen.

Der MVP soll frueh nutzbar sein und in zwei kleinen Iterationen einen durchgaengigen Kernablauf liefern:

1. Fach oder Thema anlegen
2. Lernaufgaben erfassen und priorisieren
3. Eine Lerneinheit starten und abschliessen
4. Fortschritt im Dashboard sehen

## Produktannahmen

- Zielgruppe sind einzelne Studierende, nicht Lerngruppen.
- Der MVP startet als Webanwendung fuer Desktop und mobile Browser.
- Es wird zunaechst nur ein einzelner Benutzer unterstuetzt.
- Benutzerauthentifizierung ist fuer die ersten zwei Iterationen nicht notwendig.
- KI-Funktionen, Datei-Upload und Kalender-Integrationen sind explizit spaetere Ausbaustufen.

## Scope

### In Scope

- Themen oder Kurse anlegen und auflisten
- Lernaufgaben mit Titel, Fach, Prioritaet und Status verwalten
- Eine gefuehrte Lernsitzung mit Start, Ende und kurzer Reflexion
- Einfaches Fortschritts-Dashboard mit offenen und erledigten Aufgaben
- Solide Grundstruktur fuer Frontend, Backend und Datenhaltung

### Out of Scope

- Mehrbenutzerbetrieb und Kollaboration
- Login, Rollen und Cloud-Synchronisation
- Automatische Lernplan-Generierung durch KI
- Upload und Analyse von PDFs oder Vorlesungsfolien
- Push-Benachrichtigungen, Gamification und komplexe Analytics

## Vorgeschlagene Projektstruktur

Die Struktur ist bewusst klein gehalten, damit der MVP schnell implementierbar bleibt und spaeter erweitert werden kann.

```text
study-companion/
  README.md
  docs/
	 architecture.md
	 backlog.md
  frontend/
	 src/
		app/
		components/
		features/
		  dashboard/
		  study-sessions/
		  subjects/
		  tasks/
		services/
		styles/
		tests/
  backend/
	 src/
		api/
		domain/
		services/
		repositories/
		tests/
  shared/
	 types/
	 validation/
  data/
	 seed/
  scripts/
```

### Strukturprinzipien

- Fachliche Features werden getrennt von generischen UI-Komponenten organisiert.
- Gemeinsame Typen und Validierungsregeln liegen zentral in `shared/`.
- Tests liegen nah an den jeweiligen Schichten, damit Aenderungen lokal nachvollziehbar bleiben.
- Dokumentation fuer Architektur und Produktentscheidungen bleibt in `docs/`, waehrend die Projektsteuerung weiter in `agent-workbench/` gepflegt wird.

## Erste User Stories

### Prioritaet P0

1. Als Studierende moechte ich ein Fach oder Thema anlegen, damit ich meinen Lernstoff strukturieren kann.
	Akzeptanzkriterien: Name ist Pflicht; Themen werden in einer Liste angezeigt; doppelte leere Eintraege sind nicht moeglich.
2. Als Studierende moechte ich Lernaufgaben erfassen, damit ich weiss, was ich als Naechstes bearbeiten muss.
	Akzeptanzkriterien: Aufgabe hat Titel, Fach, Prioritaet und Status; offene Aufgaben sind sichtbar filterbar.
3. Als Studierende moechte ich den Status einer Aufgabe aendern, damit ich erledigte Arbeit nachvollziehen kann.
	Akzeptanzkriterien: Statuswechsel ist direkt aus der Aufgabenliste moeglich; Dashboard aktualisiert sich korrekt.

### Prioritaet P1

4. Als Studierende moechte ich eine Lernsitzung starten und beenden, damit ich fokussiert an einer Aufgabe arbeiten kann.
	Akzeptanzkriterien: Startzeit und Endzeit werden gespeichert; eine Aufgabe kann optional mit einer Session verknuepft werden.
5. Als Studierende moechte ich nach einer Lernsitzung eine kurze Reflexion erfassen, damit ich spaeter sehe, was gut funktioniert hat.
	Akzeptanzkriterien: Notizfeld nach Session-Ende; Reflexion ist spaeter im Verlauf sichtbar.
6. Als Studierende moechte ich auf einem Dashboard sehen, wie viele Aufgaben offen, in Arbeit und erledigt sind, damit ich meinen Fortschritt einschätzen kann.
	Akzeptanzkriterien: Kennzahlen werden aus den gespeicherten Daten berechnet; Ansicht bleibt auch bei wenig Daten sinnvoll.

## Milestones

### M0 — Projektbasis steht

- Repository-Struktur angelegt
- Grundlegende Entwicklungsumgebung laeuft lokal
- Erste Datenmodelle und API-Schnittstellen sind definiert

### M1 — Aufgabenverwaltung nutzbar

- Themen koennen angelegt werden
- Aufgaben koennen angelegt, angezeigt und aktualisiert werden
- Einfaches Dashboard fuer Aufgabenstatus ist vorhanden

### M2 — Erste komplette Lernsession moeglich

- Lernsession kann gestartet und beendet werden
- Reflexion wird gespeichert
- Durchgaengiger MVP-Flow ist manuell testbar

## Risiken

1. Der Scope waechst zu schnell durch Zusatzwuensche wie KI, Kalender oder Kollaboration.
	Gegenmassnahme: Nur Stories mit direktem Beitrag zum Kernablauf in die ersten zwei Iterationen aufnehmen.
2. Zu fruehe technische Komplexitaet bremst die Umsetzung.
	Gegenmassnahme: Einfache Architektur und wenige Abhaengigkeiten bevorzugen; keine Optimierung ohne akuten Bedarf.
3. Unklare Produktabgrenzung fuehrt zu einem unscharfen MVP.
	Gegenmassnahme: Jede Story gegen den Kernablauf Fach -> Aufgabe -> Session -> Fortschritt pruefen.
4. Datenmodell wird spaeter durch Session- oder Fortschrittslogik unnoetig kompliziert.
	Gegenmassnahme: Zuerst wenige zentrale Entitaeten definieren: Subject, Task, StudySession.
5. Zu spaete Verifikation fuehrt zu Integrationsproblemen.
	Gegenmassnahme: Ab Iteration 1 jeden Slice mit kurzem manuellen Test und einfachen Checks abschliessen.

## Offene Fragen

- Soll der MVP rein lokal laufen oder frueh eine persistente Backend-Speicherung enthalten?
- Ist Mobile-First oder Desktop-First fuer die erste Benutzungsoberflaeche wichtiger?
- Soll eine Lernsession zwingend an eine Aufgabe gebunden sein oder auch frei startbar sein?
- Welche minimalen Kennzahlen sind fuer das erste Dashboard wirklich nuetzlich?
- Reicht ein einzelner Demo-Benutzer oder wird frueh ein Login benoetigt?

## Iteration 1 — Aufgabenbasis schaffen

### Ziel

Die erste Iteration liefert einen nutzbaren Kern fuer Themen- und Aufgabenverwaltung inklusive einfacher Fortschrittsanzeige.

### Geplante Slices

1. Produkt- und Datenbasis festlegen
	Ergebnis: Entitaeten, Statuswerte und einfache UI-Flows sind definiert.
2. Themenverwaltung umsetzen
	Ergebnis: Themen koennen erstellt und angezeigt werden.
3. Aufgabenverwaltung umsetzen
	Ergebnis: Aufgaben koennen angelegt, gelistet und im Status geaendert werden.
4. Einfaches Dashboard bauen
	Ergebnis: Offene, laufende und erledigte Aufgaben werden aggregiert angezeigt.
5. Grundlegende Verifikation und Doku ergaenzen
	Ergebnis: Kernfluss ist manuell nachvollziehbar und dokumentiert.

### Schritt-fuer-Schritt-Plan

1. Domänenobjekte und Statuswerte fuer Subject und Task definieren.
2. Minimale Navigations- und Seitenstruktur fuer Dashboard, Themen und Aufgaben festlegen.
3. Eingabemasken fuer Themen und Aufgaben implementierungsbereit spezifizieren.
4. Datenhaltung fuer den MVP festlegen, zum Beispiel lokale Persistenz oder einfache API mit Speicherlogik.
5. Aufgabenliste mit Filtern fuer Status und Fach planen.
6. Dashboard-Kennzahlen definieren und Ableitungslogik beschreiben.
7. Manuelle Testfaelle fuer Anlegen, Bearbeiten und Statuswechsel festhalten.
8. Review-Notizen und Wiki nach Abschluss aktualisieren.

### Done-Kriterien

- Ein Benutzer kann mindestens ein Fach anlegen.
- Ein Benutzer kann Aufgaben einem Fach zuordnen.
- Aufgabenstatus laesst sich sichtbar aendern.
- Dashboard zeigt konsistente Kennzahlen auf Basis der Aufgaben.
- Der Ablauf ist in Doku und Review-Notizen nachvollziehbar.

## Iteration 2 — Lernsessions ergaenzen

### Ziel

Die zweite Iteration erweitert den MVP um fokussierte Lernsitzungen und schliesst damit den ersten echten End-to-End-Lernablauf.

### Geplante Slices

1. Session-Datenmodell definieren
	Ergebnis: Start, Ende, Dauer, Notiz und optionale Task-Verknuepfung sind spezifiziert.
2. Session-Start und Session-Ende umsetzen
	Ergebnis: Benutzer koennen eine Session beginnen und abschliessen.
3. Reflexion nach Session-Ende ergaenzen
	Ergebnis: Kurze Lernnotizen koennen gespeichert werden.
4. Dashboard und Aufgabenkontext erweitern
	Ergebnis: Letzte Session oder Session-Anzahl wird sichtbar.
5. End-to-End-Verifikation fuer den MVP durchfuehren
	Ergebnis: Der komplette Kernablauf ist demonstrierbar.

### Schritt-fuer-Schritt-Plan

1. Datenmodell und Statusregeln fuer StudySession definieren.
2. UX fuer Start, laufende Session und Abschlussbildschirm skizzieren.
3. Verknuepfung zwischen Aufgabe und Session sauber festlegen.
4. Speicherung von Startzeit, Endzeit und Dauer beschreiben.
5. Reflexionsfeld und Verlaufsansicht spezifizieren.
6. Dashboard um Session-bezogene Kennzahlen oder letzte Aktivitaet erweitern.
7. Einen End-to-End-Testfall definieren: Fach anlegen -> Aufgabe anlegen -> Session starten -> Session abschliessen -> Fortschritt sehen.
8. Offene Fragen und Risiken nach Iterationsende neu priorisieren.

### Done-Kriterien

- Eine Session kann gestartet und sauber beendet werden.
- Eine Session kann optional mit einer Aufgabe verknuepft werden.
- Eine kurze Reflexion kann gespeichert und wieder angezeigt werden.
- Dashboard oder Verlauf zeigt Session-bezogene Informationen.
- Der MVP ist als klickbarer Kernablauf demonstrierbar.

## Nächste Slices nach Iteration 2

1. Persistenz haerten und erste automatisierte Tests ergaenzen
2. Such- und Filterfunktionen verbessern
3. Usability-Verbesserungen fuer mobile Nutzung
4. Optional: Login oder Cloud-Synchronisation evaluieren
5. Optional: spaetere KI-Unterstuetzung fuer Zusammenfassungen oder Lernempfehlungen pruefen