Fall 5 von 6 · eigenes Produkt, öffentlich Stand 02.09.2026

Der Kurator

Eine App, mit der Wanderer ihr Packgewicht planen. Der Katalog kennt ein paar hundert Ausrüstungsteile. Nutzer tragen ständig Dinge ein, die er nicht kennt, im Freitext: „Jetboil Flash“, „der grüne Kocher von Aldi“. Ein Bot recherchiert diese Kandidaten mit Websuche und legt Vorschläge in einen Posteingang. Der Kurator, das bin ich, nimmt an oder lehnt ab.

Befund

Kleiner Agent  Innerhalb eines Aufrufs entscheidet das Modell selbst, ob und wie oft es sucht. Deckel: drei Suchen je Kandidat. Drumherum ein fester Stapel: fünf Kandidaten je Lauf, zwei Läufe am Tag.

Bauform 01 aus Abschnitt 06, gar keine Oberfläche: Auslöser ist die Uhrzeit, das Ergebnis erscheint dort, wo ich ohnehin hinsehe.

01

Aufgabe

Aus einem Freitextnamen einen Katalogeintrag machen: Hersteller, Modell, Gewicht in Gramm, ein bis drei Belegadressen, und ein Satz dazu, wie sicher das ist. Das Gewicht ist der Kern, denn die App rechnet damit. Ein falsches Gewicht ist schlimmer als ein fehlendes.

Der Bot läuft auf dem eigenen Server, zweimal am Tag per Zeitplan, und ruft die Verwaltungsschnittstelle der App auf. Die App selbst liegt bei einem Hoster, dessen Kommandozeile eine alte PHP-Version hat, deshalb der Umweg über HTTP. Je Lauf fünf Kandidaten, sortiert danach, wie klar der Name ein Produkt bezeichnet. Je Kandidat ein Modellaufruf mit Websuche, höchstens drei Suchen, festes Ausgabeschema, neunzig Sekunden Zeitlimit.

02

Vorfrage

  • JAWeg unbekannt? Innerhalb eines Kandidaten ja. Ob „Jetboil Flash“ mit einer Suche erledigt ist und „der grüne Kocher von Aldi“ mit drei nicht, weiß vorher niemand. Deshalb darf das Modell hier entscheiden, wie oft es sucht. Der Stapel drumherum ist ein Workflow.
  • JAErgebnis prüfbar? Ja. Ein Gewicht gegen die Herstellerseite zu prüfen dauert Sekunden, und die Belegadressen stehen am Vorschlag.
  • JAFehler umkehrbar? Ja, solange der Vorschlag im Posteingang bleibt. Unten steht, wo das zweimal nicht galt.
  • JANutzen trägt? Ja. Zehn Kandidaten am Tag, jeder eine Minute Handarbeit gespart, für Bruchteile eines Cents je Suche.
03

Bauform

AuslöserDie Uhrzeit. Ein Zeitplan auf dem eigenen Server, zweimal täglich. Kein Mensch startet etwas.
LaufFünf Kandidaten, je einer ein Aufruf: das Modell sucht, liest, entscheidet, ob es noch einmal sucht, und füllt das Schema. Nach drei Suchen ist Schluss, ob es fertig ist oder nicht. Das Ergebnis bekommt den Status „recherchiert“.
RückgabeDer Posteingang des Kurators: Vorschlagsliste mit Gewicht, Belegen und dem Sicherheitssatz. Annehmen öffnet den Eintrag zur Bearbeitung, Ablehnen schließt ihn. Ein angenommener Eintrag geht erst mit dem nächsten bewussten Veröffentlichen in die App.
04

Wo die Umkehrbarkeit gerissen war

Bedingung 3 aus der Vorfrage, zweimal an einem Tag.

19.08.2026 · ein Text am Backend vorbei

Ein Ratgebertext wurde als Datei direkt ins Webverzeichnis gelegt, statt als Seite in die Redaktion. Dort war er im Backend unsichtbar, und beim nächsten Druck auf den Veröffentlichen-Knopf ging er mit, unredigiert. Zurückgenommen am selben Tag. Regel seitdem: Texte leben in der Redaktion, nie als Datei daneben. Ein Freigabeschritt schützt nur, was durch ihn hindurch muss.

19.08.2026 · „Annehmen“ ohne Speichern

Annehmen setzte den Status sofort auf „angenommen“ und öffnete den Editor. Wer dort abbrach, hatte trotzdem einen angenommenen Eintrag. Die Rücknahme gab es nicht. Der Knopf hieß Annehmen und meinte Übernehmen. Das ist die Vorauswahl aus Station 06 des Durchstichs in anderer Gestalt: ein Schritt, der aussieht wie prüfen und wirkt wie durchwinken.

August 2026 · ein Wächter, der ins Leere lief

Der Dienst, der Änderungen auf den Server bringt, lief seit jeher ohne Wirkung: ein Rechte-Eintrag auf Nutzerebene stach die allgemeinen Rechte aus, und die üblichen Rechtebefehle heilten ihn nicht. Keine Fehlermeldung. Kein Modell beteiligt, aber dasselbe Muster wie überall auf dieser Seite: das stille Versagen ist das teure.

05

Messlatte

Für den Bot: keineDie App hat Ende-zu-Ende-Tests, der Bot hat keine. Zwanzig Kandidaten mit bekanntem Gewicht wären der Testsatz, und sie stünden in einer Stunde. Bis dahin ist jeder angenommene Vorschlag die Messung, und die Zahl, wie oft ich ablehne, wird nicht festgehalten. Das ist der Fehler aus Abschnitt 03, und ich mache ihn hier selbst.
06

Grenzen

Freigabe

Ja, doppelt: Annehmen im Posteingang, dann Veröffentlichen. Zwischen beiden liegt die Bearbeitung.

Kostendeckel

Teilweise. Drei Suchen je Kandidat, fünf Kandidaten je Lauf, zwei Läufe je Tag. Das begrenzt die Schritte, nicht die Token und nicht das Geld. Der Bot läuft nicht über die Schleuse, also ohne Tagesbudget. Bei zehn Aufrufen am Tag ist das eine Lücke, kein Risiko.

Spur

Dünn. Ein Protokoll je Lauf, das der nächste Lauf leert. Am Vorschlag selbst bleiben Belege und Sicherheitssatz. Wer wissen will, warum der Bot letzte Woche ein Gewicht vorgeschlagen hat, das ich abgelehnt habe, findet nichts mehr.

Personendaten

Keine im Modellaufruf. Der Bot sieht Produktnamen, keine Nutzer. Die App selbst kommt ohne Konto, ohne Tracking und ohne Cookies aus.

 

Quellen

Modellaufruf mit Suchdeckel und Schema: outdoorkitchen/admin/lib.php, Zeilen 1303 bis 1411. Zeitplan: build/outdoorkitchen-gear-research-cron.sh. Vorfälle vom 19.08.2026: 05_Projects/outdoorkitchen.md.