Einkaufswagen-Bridge
Wandelt eine Einkaufsliste aus dem Mahlzeitenplaner in einen überprüfbaren Warenkorb-Vorschlag um – und bleibt dann bewusst stehen
Überblick
Kontext, Ansatz und Ergebnis.
Problem
Mein selbst gehosteter Essensplaner weiß, was ich einkaufen muss. Die Website meines Supermarkts kennt die Preise, weiß, welche Aktionen gelten, und was im Abverkauf ist. Das jede Woche von Hand abzugleichen, ist genau die Art von wiederkehrender Kleinaufgabe, die Automatisierung übernehmen sollte.
Meine Rolle
Ich habe alles entworfen und gebaut, inklusive der Abgrenzungen – die machen den Großteil des Designs aus.
Rahmenbedingungen
- Spanischsprachige Lebensmitteldaten, bei denen dasselbe Produkt mehrere Namen hat und das Matching deterministisch genug sein muss, um es zu überprüfen.
- Die Aktionslogik ist wirklich komplex: Multi-Buy-Angebote, prozentuale und feste Rabatte, Abverkaufspreise, Treueprämien.
- Es geht um Geld. Diese Einschränkung hat alles andere bestimmt.
Architektur
Bedarfe aus der Einkaufsliste werden normalisiert, deterministisch mit dem Katalog abgeglichen und gegen aktive Aktionen ausgewertet, um einen Warenkorb-Vorschlag zur menschlichen Überprüfung zu erzeugen. Lokale Präferenzspeicherung sorgt dafür, dass eine einmalige Korrektur dauerhaft gemerkt wird. Die Funktionen werden über Model Context Protocol bereitgestellt, sodass ein Assistant sie aufrufen kann.
Dry-Run ist der Standard. Warenkorb-Änderungen sind möglich, aber hinter einem expliziten Apply-Flag deaktiviert. Die Out-of-Scope-Liste ist fest im Projekt verankert und kein TODO: kein Checkout, keine Bezahlung, keine Lieferterminplanung, keine Bestellübermittlung, kein Einlösen von Treuepunkten, kein autonomer Einkauf und kein Versuch, Bot-Schutz zu umgehen.
Ergebnis
Läuft end-to-end ab v0.1.0, wird wöchentlich genutzt, mit einer Fixtures-First-Test-Suite, sodass die Aktionslogik geprüft werden kann, ohne eine Live-Seite zu belasten.
Was ich anders machen würde
Nichts Strukturelles – das ist das Projekt, bei dem ich die Abgrenzung beim ersten Versuch richtig gesetzt habe, und der Grund dafür ist, dass ich die Out-of-Scope-Liste vor der Feature-Liste geschrieben habe. Automatisierung, die mit Geld zu tun hat, sollte vorschlagen, nicht handeln. Der Review-Schritt kostet mich dreißig Sekunden pro Woche und eliminiert eine ganze Fehlerkategorie, gegen die ich sonst hätte anentwickeln müssen.
Erkenntnisse
Was ich mitnehme.
Das Erstellen der Out-of-Scope-Liste vor der Feature-Liste hat zu einem besseren Design geführt, als es jede spätere Refaktorisierung je könnte. Wenn Automatisierung mit Geld zu tun hat, ist der Review-Schritt das eigentliche Produkt.
Stack
Tools und Plattformen.
Reden wir
Möchtest du über solche Arbeit sprechen?
Wenn du für ähnliche Backend-, AWS-, Voice- oder Integrations-Arbeit einstellst — oder einfach Architektur-Notizen vergleichen willst — melde dich direkt.