BuyingAgent/.specs/buying-agent-frontend-mvp-spec-v0.2.md

Buying Agent – Frontend MVP Specification v0.2

Status: Review Candidate – vor Implementierung erneut durch den Coding-Agenten zu prüfen
Spezifikationsversion: 0.2
Stand: 2026-10-04
Ersetzt vollständig: buying-agent-frontend-mvp-spec-v0.1.md

Gilt zusammen mit:

1. buying-agent-v0.1-spec-v1.1.md
2. buying-agent-architecture-addendum-v1.md
3. buying-agent-source-discovery-spec-v0.1.md

Bei Widersprüchen innerhalb des Frontend-/MVP-Bereichs hat diese v0.2 Vorrang.
Sie präzisiert außerdem die für das Frontend notwendigen Backend-Verträge.

---

1. Zielbild

Der Buying Agent soll nicht nur ein Backend-Skeleton sein, sondern als nutzbare PWA einen vollständigen vertikalen Nutzerfluss abbilden.

Der Nutzer soll ohne technische Kenntnisse:

BuyingProject anlegen
    ↓
Produktkategorie auswählen
    ↓
verfügbare Kriterien aus der Source-Taxonomie laden
    ↓
gewünschte Suchparameter auswählen und Werte setzen
    ↓
externe Suche generieren
    ↓
SearchRun starten / Status verfolgen
    ↓
Kandidaten sehen
    ↓
Shortlist / Ranking sehen, soweit konfiguriert
    ↓
Kandidat öffnen
    ↓
Attribute, Preise, Historie und bisherigen Status sehen
    ↓
Kriterien anpassen
    ↓
neue Suche ausführen

Die Oberfläche soll einfach bleiben. Die technische Komplexität verbleibt im Backend.

---

2. Grundsätzliche Architektur

2.1 Backend bleibt System of Record

Das Frontend enthält keine fachliche Kernlogik.

Es konsumiert ausschließlich die versionierte /api/v1-API.

Fachliche Entscheidungen über:

• Taxonomie
• Mapping
• Query-Generierung
• Produktidentität
• Diffing
• Ranking
• Historisierung
• Lifecycle

liegen im Backend.

2.2 Keine Canonical-Criteria-Schicht

Es wird keine separate globale Canonical-Criteria-Ontologie eingeführt.

Für eine unterstützte Source/Kategorie bildet deren gelernte Taxonomie zunächst den primären Kriterienkatalog.

Jedes Source-Kriterium erhält lediglich eine stabile interne ID:

CriterionDefinition.id = interne UUID

Diese ID dient als Persistenz- und Referenzidentität.

Sie ist keine Behauptung, dass das Kriterium global quellenunabhängig kanonisch sei.

2.3 Source-Kriterien und Ergebnisattribute werden verbunden

Ein Kriterium muss sowohl mit dem Suchfilter als auch mit den aus Suchergebnissen bzw. Produktdetailseiten extrahierten Attributen verbunden werden können.

Beispiel:

CriterionDefinition
id = <uuid>
origin = SOURCE
source = geizhals
category = notebook
label = "Arbeitsspeicher"

SourceFilterMapping:
Geizhals Filter 17023 -> CriterionDefinition.id

SourceAttributeMapping:
"RAM" -> CriterionDefinition.id
"Arbeitsspeicher" -> CriterionDefinition.id
ggf. source_attribute_id -> CriterionDefinition.id

Eine Produktbeobachtung soll dann auf dieselbe interne CriterionDefinition referenzieren:

ProductAttributeObservation
- source_product_reference_id
- criterion_definition_id
- raw_name
- raw_value
- normalized_value
- unit
- observed_at

2.4 INTERNAL-Kriterien

Zusätzliche interne Kriterien werden nur angelegt, wenn für die Kaufentscheidung relevante Eigenschaften von der Source-Taxonomie nicht angeboten werden.

Beispiele:

• externer Akku-Benchmark
• Reparierbarkeit
• Testscore
• Lautstärke unter Last

CriterionDefinition.origin = INTERNAL

Diese besitzen naturgemäß keinen Source-Filter, können aber später von anderen Datenquellen befüllt werden.

---

3. Produktkategorien

Das BuyingProject referenziert eine interne ProductCategory.

Beispiel:

ProductCategory
id = notebook
name = Notebooks

Die Source-spezifische Kategorie wird separat gemappt:

SourceCategory
source = geizhals
external_category_key = nb
product_category_id = notebook

Damit ist das BuyingProject nicht direkt an geizhals/nb gekoppelt.

---

4. BuyingProject

Ein BuyingProject ist die konkrete Instanz eines Kaufvorhabens.

Es kann ohne ProductProfile angelegt werden.

Mindestens:

id
workspace_id nullable
name
product_category_id
market
currency
budget_target nullable
budget_maximum nullable
shortlist_size
schedule_interval_minutes
status
created_at
updated_at
archived_at nullable

Status:

ACTIVE
PURCHASED
ARCHIVED

Default:

shortlist_size = 5
schedule_interval_minutes = 180

---

5. Rolle von ProductProfile / BuyingTemplate

Das bisherige ProductProfile ist für neue BuyingProjects nicht verpflichtend.

Fachlich wird es künftig als optionale Vorlage verstanden.

Zielbild:

BuyingTemplate
"Mobiler Entwicklungsrechner"
    ↓ optional beim Projektstart
BuyingProject

Eine Vorlage kann z. B. liefern:

• vorgeschlagene Suchkriterien
• Ranking-Konfiguration
• Default-Budget
• Kategorie
• Markt / Währung

Beim Erstellen eines Projekts werden relevante Werte in die Projektkonfiguration übernommen.

Spätere Änderungen an der Vorlage verändern bestehende Projekte nicht rückwirkend.

Zur Nachvollziehbarkeit darf gespeichert werden:

template_id
template_version

Die bestehende ProductProfile-Implementierung darf technisch weiterverwendet werden, solange sie nicht mehr als zwingende Voraussetzung für ein BuyingProject fungiert.

---

6. ProjectCriteria

6.1 Zweck

ProjectCriteria beschreiben die vom Nutzer gewählten Suchparameter eines BuyingProjects.

Sie referenzieren die dynamisch geladenen CriterionDefinitions.

Beispiel:

ProjectCriterion
- id
- project_id
- criterion_definition_id
- operator
- value
- enabled_for_discovery
- created_at
- updated_at

6.2 Standard-UI

Die Standardoberfläche zeigt keine technischen Ranking-Parameter wie:

• weight
• acceptable
• ideal
• strategy
• scoring_version

Der Nutzer wählt lediglich:

Kriterium
Operator
Wert / Wertebereich
für externe Suche aktiv ja/nein

Optional kann später eine einfache Kennzeichnung wie „Muss“ / „Wunsch“ ergänzt werden, sie ist für v0.2 nicht Voraussetzung.

6.3 Beispiel

Arbeitsspeicher  >=  24 GB
Preis            <=  1700 EUR
Gewicht          <=  1.5 kg

Die verfügbaren Operatoren und UI-Controls werden aus der SourceFilterDefinition bzw. CriterionDefinition abgeleitet.

---

7. Ranking-Konfiguration

Discovery und Ranking bleiben getrennte fachliche Bereiche.

ProjectCriteria dürfen keine versteckten Scoring-Regeln erzwingen.

Ein Projekt kann optional eine Ranking-Konfiguration besitzen.

Mögliche Herkunft:

1. aus einem BuyingTemplate/ProductProfile übernommen
2. später explizit durch Advanced UI
3. später von KI vorgeschlagen
4. später durch eine Default-Strategie erzeugt

Für den MVP gilt:

• Ein Projekt ohne Ranking-Konfiguration darf trotzdem Discovery ausführen.
• In diesem Zustand zeigt das Frontend Kandidaten, aber kennzeichnet Ranking als NOT_CONFIGURED.
• Für den Notebook-Pilot kann das vorhandene Profil mobile-development-notebook als optionale Vorlage genutzt werden, damit ProductScore/Shortlist end-to-end getestet werden können.
• Es dürfen keine stillen, nicht dokumentierten Scoring-Regeln erfunden werden.

---

8. Criterion-Katalog vor Projektanlage

Der Projekt-Wizard muss Kriterien laden können, bevor eine Project-ID existiert.

Erforderliche Endpunkte:

GET /api/v1/sources
GET /api/v1/sources/{source}/categories
GET /api/v1/sources/{source}/categories/{category}/available-criteria

available-criteria liefert mindestens:

criterion_definition_id
label
description nullable
origin
source
category
filter_type
unit nullable
operators
options / range metadata
mapping_status
supports_discovery

Nur Source-Kriterien mit nutzbarer Filterdefinition werden als externe Suchparameter angeboten.

INTERNAL-Kriterien dürfen separat sichtbar sein, wenn sie für die Kategorie bekannt sind.

---

9. Taxonomie-Lernen

Taxonomie wird on demand pro Kategorie gelernt.

Initial:

Geizhals -> Notebooks

Die gelernte Taxonomie soll später im Admin-Bereich bearbeitbar sein.

Mapping-Status:

DISCOVERED
LEARNED_UNVERIFIED
VERIFIED
BROKEN
DISABLED

Nur VERIFIED darf automatisch für produktive Source-Query-Generierung verwendet werden.

Technisch eindeutige automatische Verifikation ist zulässig, wenn der Backend-Service einen reproduzierbaren Roundtrip sicher nachweisen kann.

---

10. DiscoverySearch

Persistenz bleibt 1:n:

BuyingProject
    └── DiscoverySearch[]

Für den ersten MVP gilt als fachliche Einschränkung:

maximal eine aktive DiscoverySearch
pro BuyingProject + Source + SourceCategory

Diese Einschränkung darf nicht als dauerhafte 1:1-Beziehung in das Datenmodell eingebaut werden.

Mindestens:

id
buying_project_id
source_id
source_category_id
criteria_version
mapping_version
generated_url
status
schedule_interval_minutes
next_run_at nullable
last_successful_run_at nullable
created_at
updated_at

---

11. Statuswelten strikt trennen

11.1 Project Lifecycle

ACTIVE
PURCHASED
ARCHIVED

11.2 DiscoverySearch / SearchRun Status

Je nach fachlicher Ebene:

RUNNING
SUCCESS
PARTIAL
FAILED
BLOCKED
TOO_BROAD
OUT_OF_SYNC

OUT_OF_SYNC gehört fachlich zur Search-Konfiguration.

TOO_BROAD beschreibt den Zustand bzw. das Ergebnis einer DiscoverySearch/SearchRun-Ausführung.

11.3 Run Diff

NEW
CHANGED
UNCHANGED
MISSING

11.4 Product Lifecycle

ACTIVE
DISAPPEARED
ARCHIVED

11.5 Identity / Matching

MATCHED
MATCH_UNCERTAIN

Diese Status dürfen in DB, API und UI nicht zu einem gemeinsamen Statusfeld vermischt werden.

---

12. Diff- und Lifecycle-Regeln

Nur vollständige erfolgreiche Full Runs dürfen fehlende Produkte ableiten.

SUCCESS Full Run:
- NEW
- CHANGED
- UNCHANGED
- MISSING

PARTIAL darf keine MISSING-/DISAPPEARED-Transition auslösen.

Lifecycle:

1 vollständiger Run fehlend -> MISSING im Run-Diff
3 aufeinanderfolgende vollständige Runs fehlend -> Product Lifecycle DISAPPEARED

Wiederauftauchen reaktiviert bestehende SourceProductReference, sofern Identity ausreichend sicher ist.

---

13. Candidate Summary DTO

Listen und Shortlist müssen genügend Daten liefern, damit das Frontend nicht für jede Zeile Einzelrequests benötigt.

Mindestens:

candidate_id
source_product_reference_id
title
manufacturer nullable
model nullable
source_url
current_best_price nullable
currency nullable
current_dynamic_attributes
product_score nullable
product_eligibility nullable
ranking_status
shortlist_status
current_diff_status
product_lifecycle_status
match_status
first_seen_at
last_seen_at

current_dynamic_attributes ist metadata-driven und keine feste Notebook-Struktur.

---

14. Candidate Detail DTO

Erforderlicher Endpunkt:

GET /api/v1/buying-projects/{project_id}/candidates/{candidate_id}

Mindestens:

Candidate Summary
+
alle aktuellen normalisierten Attribute
+
Source-Metadaten
+
aktuelle Observation
+
Ranking-/Eligibility-Daten, soweit vorhanden

Das Frontend darf keine Gründe/Empfehlungen behaupten, die nicht tatsächlich persistiert sind.

---

15. Observation History

Erforderlicher Endpunkt:

GET /api/v1/buying-projects/{project_id}/candidates/{candidate_id}/observations

Mindestens:

observed_at
best_price
currency
availability nullable
seller_count nullable
dynamic_attributes
search_run_id

Diese Historie ermöglicht:

• Preisentwicklung
• Attributänderungen
• Last Seen
• Verlauf über SearchRuns

Kein HTML-Archiv.

---

16. Project Summary DTO

Die Projektliste soll nicht N+1-Requests erzeugen.

Erforderlich:

GET /api/v1/buying-projects

Pro Projekt mindestens:

id
name
product_category
status
last_successful_run_at nullable
next_run_at nullable
discovery_status nullable
candidate_count
shortlist_count
new_count
changed_count
missing_count
current_search_result_count nullable

---

17. Projekt-Wizard

Route:

/projects/new

Schritt 1 – Basis

Projektname
Produktkategorie
Markt
Währung
Budget Ziel optional
Budget Maximum optional
Shortlist-Größe
Suchintervall
optional BuyingTemplate

Schritt 2 – Kriterien laden

Nach Kategorieauswahl:

GET available-criteria

Die UI zeigt die Source-Kriterien als verständliche Liste.

Beispiel Notebooks:

[ ] Hersteller
[ ] Arbeitsspeicher
[ ] SSD
[ ] Gewicht
[ ] Displaygröße
[ ] CPU
[ ] Grafikkarte
...

Schritt 3 – Parameter setzen

Nach Aktivierung eines Kriteriums:

Arbeitsspeicher
Operator: mindestens
Wert: 24 GB

Control-Typen:

BOOLEAN
ENUM
MULTI_ENUM
NUMERIC_RANGE
NUMERIC_THRESHOLD
TEXT

Das UI rendert dynamisch.

Keine hartcodierten Notebook-Felder.

Schritt 4 – Projekt speichern

Erst jetzt wird das BuyingProject angelegt und die ProjectCriteria werden gespeichert.

---

18. Kriterienänderung im bestehenden Projekt

Route:

/projects/:projectId/criteria

Ändert der Nutzer relevante ProjectCriteria:

criteria_version++
DiscoverySearch.status = OUT_OF_SYNC

Das Frontend zeigt:

Suchparameter wurden geändert. Die externe Suche muss aktualisiert werden.

Aktion:

Suche aktualisieren

Backend:

generate-query
→ VERIFIED Mappings verwenden
→ neue URL speichern
→ optional SearchRun starten

---

19. Hauptscreens

19.1 Projektliste

/projects

Anzeige:

• Name
• Kategorie
• Project Lifecycle
• letzter erfolgreicher Run
• Discovery-Status
• Kandidatenzahl
• Shortlistzahl
• NEW / CHANGED Counts
• nächste Suche

19.2 Projektdetail

/projects/:projectId

Bereiche:

Übersicht
Kandidaten
Shortlist
Kriterien
Historie

19.3 Kandidaten

/projects/:projectId/candidates

Desktop:

• Tabelle / kompakte Liste

Mobile:

• Cards / List Items

19.4 Kandidatendetail

/projects/:projectId/candidates/:candidateId

Zeigt nur tatsächlich vorhandene Daten:

• Titel / Hersteller / Modell
• aktueller Preis
• dynamische Attribute
• Eligibility / ProductScore, soweit vorhanden
• Ranking Status
• Diff Status
• Product Lifecycle
• Match Status
• First Seen / Last Seen
• Observation History

Nicht anzeigen, solange Backend es nicht erzeugt:

• Deep-Enrichment-Ergebnisse
• Review-Zusammenfassungen
• finale Kaufentscheidung
• nicht persistierte Begründungen

19.5 Shortlist

/projects/:projectId/shortlist

Zeigt Top-N, falls Ranking konfiguriert.

Ohne Ranking-Konfiguration:

Ranking ist noch nicht konfiguriert.

19.6 Historie

/projects/:projectId/history

SearchRuns mit:

Zeitpunkt
Run Status
Trefferzahl
Page Count
NEW
CHANGED
MISSING
Fehler / BLOCKED / TOO_BROAD

---

20. Admin-Bereich

Routen:

/admin/sources
/admin/sources/:source/categories
/admin/sources/:source/categories/:category

Funktionen:

• Kategorien sehen
• Taxonomie laden/neu laden
• SourceFilterDefinitions sehen
• Optionen / Ranges sehen
• CriterionDefinitions sehen
• SearchFilter-Mapping sehen
• SourceAttributeMappings sehen
• Mapping-Status ändern
• kleine Mapping-Korrekturen durchführen
• BROKEN / DISABLED erkennen

Technische IDs sind nur hier sichtbar.

Das Frontend generiert keine Source-URL-Encodings selbst.

---

21. Frontend-Technologie

Verbindlich:

• React
• TypeScript
• Vite
• PWA
• TanStack Query
• React Router oder vergleichbare schlanke Lösung

Nicht erforderlich:

• Next.js
• SSR
• SEO

Begründung:

Die Anwendung ist eine private/interne App und benötigt keine suchmaschinenoptimierte öffentliche Seitenauslieferung.

---

22. Responsive Architektur

Von Anfang an zwei bewusste Hauptlayouts.

Desktop

Sidebar + Hauptinhalt + optional Detailbereich

Mobile

Bottom Navigation / kompakte Navigation
+ Vollbild-Detailseiten
+ projektinterne Tabs

Keine bloße Verkleinerung des Desktop-Layouts.

---

23. Mitai-Bezug

Wenn der Mitai-Quellcode dem Coding-Agenten im Repository oder über einen konkret angegebenen Pfad zugänglich ist, sollen passende Muster wiederverwendet werden:

• PWA-Shell
• Responsive Breakpoints
• Navigation
• Layout
• ggf. Basiskomponenten

Ohne zugänglichen Pfad darf der Agent keine Annahmen über konkrete Mitai-Komponenten treffen.

Dann nur dieselben Architekturprinzipien umsetzen.

---

24. CORS

Backend muss den Frontend-Origin konfigurierbar zulassen.

Keine harte Produktions-URL im Code.

Beispiel:

CORS_ALLOWED_ORIGINS

Lokale Entwicklung:

http://localhost:<frontend-port>

Produktive Origins über Environment.

---

25. Docker Compose

Der nutzbare MVP enthält mindestens:

api
postgres
frontend

Das Frontend muss über Compose startbar sein.

Development und Production Build dürfen unterschiedliche Docker Targets verwenden.

Root-Compose bleibt zentrale Startstelle.

---

26. CI

CI muss mindestens enthalten:

Backend:

• Unit Tests
• Integration Tests
• API E2E

Frontend:

• TypeScript typecheck
• lint
• unit/component tests
• production build

E2E:

• vollständiger Notebook-Pilot mit Fixture/Mock-Source
• Desktop viewport
• Mobile viewport

Live-Geizhals-Abfragen gehören nicht in CI.

---

27. PWA

Mindestens:

• Manifest
• installierbare App
• App Icons
• Responsive App Shell
• Offline-Fallback

Keine komplexe Offline-Synchronisation im MVP.

---

28. Loading / Empty / Error States

Jeder wesentliche Screen braucht:

Loading
Empty
Error
Retry

Beispiele:

• Noch keine Projekte vorhanden.
• Noch keine Kandidaten gefunden.
• Noch kein SearchRun ausgeführt.
• Taxonomie wurde noch nicht geladen.
• Suche ist OUT_OF_SYNC.
• Suche wurde BLOCKED.
• Ranking ist nicht konfiguriert.

---

29. API-Verträge – Mindestumfang

Projekte

GET   /api/v1/buying-projects
POST  /api/v1/buying-projects
GET   /api/v1/buying-projects/{id}
PATCH /api/v1/buying-projects/{id}

Kriterien

GET /api/v1/buying-projects/{id}/criteria
PUT /api/v1/buying-projects/{id}/criteria

Source / Kategorien

GET  /api/v1/sources
GET  /api/v1/sources/{source}/categories
POST /api/v1/sources/{source}/categories/{category}/discover-taxonomy
GET  /api/v1/sources/{source}/categories/{category}/available-criteria

Admin Mapping

GET   /api/v1/sources/{source}/categories/{category}/filters
GET   /api/v1/criterion-mappings
POST  /api/v1/criterion-mappings
PATCH /api/v1/criterion-mappings/{id}
GET   /api/v1/source-attribute-mappings
POST  /api/v1/source-attribute-mappings
PATCH /api/v1/source-attribute-mappings/{id}

Discovery Search

GET  /api/v1/buying-projects/{id}/discovery-searches
POST /api/v1/buying-projects/{id}/discovery-searches
POST /api/v1/discovery-searches/{id}/generate-query
POST /api/v1/discovery-searches/{id}/run

SearchRuns

GET /api/v1/discovery-searches/{id}/runs
GET /api/v1/search-runs/{id}

Candidates

GET /api/v1/buying-projects/{id}/candidates
GET /api/v1/buying-projects/{id}/candidates/{candidateId}
GET /api/v1/buying-projects/{id}/candidates/{candidateId}/observations
GET /api/v1/buying-projects/{id}/shortlist

---

30. Nutzerfreundlichkeit

Die Standardoberfläche zeigt keine Begriffe wie:

CriterionDefinition
SourceFilterDefinition
mapping_version
source_filter_id
normalized_spec_fingerprint

Stattdessen:

Arbeitsspeicher
mindestens
24 GB

Technische Details gehören in den Admin-Bereich.

---

31. KI-Erweiterung – bewusst vorbereitet, nicht implementiert

Später soll KI den heute manuellen Kriterien-Auswahlschritt übernehmen können.

Ziel:

Nutzer beschreibt Wunsch in natürlicher Sprache
    ↓
KI erhält verfügbare Source-Kriterien
    ↓
KI schlägt konkrete Filterparameter vor
    ↓
Nutzer bestätigt / korrigiert
    ↓
ProjectCriteria werden gespeichert

Wichtig:

Die KI soll Source-Kriterien möglichst aus dem tatsächlich verfügbaren Katalog auswählen.

INTERNAL-Kriterien dürfen nur vorgeschlagen werden, wenn sie im System bekannt sind und eine Datenquelle bzw. Bewertungsstrategie existiert.

Keine KI-Implementierung in v0.2.

---

32. Tests

Frontend Unit / Component

• dynamischer Criteria Renderer pro Filtertyp
• Projekt-Wizard
• Mapping-/Statusdarstellung
• Candidate List
• Candidate Detail
• Mobile Navigation
• Desktop Navigation
• Loading / Empty / Error States

API Integration

• Kategorie-Katalog laden
• available-criteria vor Projektanlage laden
• Projekt ohne Profil anlegen
• Projekt optional aus Template anlegen
• Criteria speichern
• Search generieren
• SearchRun starten
• Candidate Summary laden
• Candidate Detail laden
• Observation History laden
• Shortlist laden

E2E Notebook-Pilot

App öffnen
→ neues Projekt
→ Notebooks wählen
→ Geizhals-Kriterien laden
→ RAM >= 24 GB auswählen
→ Preismaximum setzen
→ Projekt speichern
→ Query generieren
→ SearchRun ausführen
→ Kandidaten anzeigen
→ Kandidat öffnen
→ dynamische Attribute sehen
→ Preis / Observation History sehen
→ Kriterien ändern
→ OUT_OF_SYNC sehen
→ Query neu generieren

Wenn optional ein Ranking-Template verwendet wird:

→ ProductScore sichtbar
→ Shortlist sichtbar

Responsive E2E

Mindestens:

• Desktop Viewport
• Mobile Viewport

---

33. Nicht Bestandteil dieses Slices

• Auth / Login
• RBAC
• Einladungen
• Multi-User UI
• Keepa
• Idealo
• LLM-Automation
• Deep Enrichment
• finale Decision Engine
• Kaufautomatisierung
• Warenkorb
• komplexe Benachrichtigungen

Die Architektur darf diese Erweiterungen nicht verbauen.

---

34. Definition of Done

Architektur

• Keine separate Canonical-Criteria-Schicht.
• Source-Kriterien besitzen stabile interne CriterionDefinition-IDs.
• SearchFilter und Ergebnisattribute können auf dieselbe CriterionDefinition-ID gemappt werden.
• INTERNAL-Kriterien sind möglich.
• BuyingProject ist ohne ProductProfile anlegbar.
• ProductProfile kann optional als Vorlage dienen.
• DiscoverySearch-Persistenz bleibt 1:n-fähig.
• Statuswelten sind getrennt.

API

• Source-Kategorie-Katalog existiert.
• available-criteria funktioniert vor Projektanlage.
• Candidate Summary DTO enthält Preis, Attribute, Diff, Lifecycle, last_seen und Ranking-Felder.
• Candidate Detail existiert.
• Observation History existiert.
• Project Summary DTO enthält Aggregate.
• CORS ist konfigurierbar.

Frontend

• React + TypeScript + Vite.
• PWA installierbar.
• Desktop-Layout.
• Mobile-Layout.
• Projektliste.
• Projekt-Wizard.
• Kriterien dynamisch aus Source-Taxonomie.
• Keine notebook-spezifisch hartcodierten Criteria Controls.
• Projekt-Detail.
• Kandidatenliste.
• Kandidatendetail.
• Observation History.
• Shortlist, wenn Ranking verfügbar.
• Admin-Bereich für Taxonomie/Mappings.
• OUT_OF_SYNC sichtbar und korrigierbar.
• Loading / Empty / Error States.

Integration

• Frontend in Docker Compose.
• Frontend Build/Tests in CI.
• Backend Tests grün.
• Frontend Tests grün.
• Desktop E2E grün.
• Mobile E2E grün.
• Notebook-Pilot über die UI erfolgreich.

---

35. Arbeitsauftrag an den Coding-Agenten

Diese Datei ersetzt buying-agent-frontend-mvp-spec-v0.1.md vollständig.

Bitte noch nicht implementieren.

Führe zunächst denselben Review-Prozess durch wie bei der v0.1:

1. Prüfe die aktuelle Repository-Implementierung gegen:

   • buying-agent-v0.1-spec-v1.1.md
   • buying-agent-architecture-addendum-v1.md
   • buying-agent-source-discovery-spec-v0.1.md
   • buying-agent-frontend-mvp-spec-v0.2.md

2. Prüfe insbesondere, ob die in deinem vorherigen Frontend-MVP-Review identifizierten Blocker F1–F6 und die weiteren Lücken mit v0.2 vollständig geschlossen sind.

3. Berichte ausschließlich:

   • verbleibende echte fachliche Widersprüche,
   • noch fehlende Verträge,
   • technisch riskante Annahmen,
   • notwendige Backend-Änderungen,
   • notwendige Frontend-Änderungen.

4. Keine neue Fachlogik erfinden, um Lücken still zu schließen.

5. Wenn keine blockierenden Punkte mehr bestehen, erstelle einen aktualisierten Implementierungsplan für einen vertikalen End-to-End-MVP, sodass jeder Schritt über das Frontend prüfbar wird.

6. Implementierung erst nach ausdrücklicher Freigabe dieses Reviews.