Adrian RomoAdrian Romo
Aktiv

Einkaufswagen-Bridge

Wandelt eine Einkaufs­liste aus dem Mahlzeiten­planer 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.

PythonModel Context Protocolpytest

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.