Automatischer Eingang
Telegram‑Nachricht → validierter Ingress → kanonische Kleinanzeigen‑Anzeige → SQLite‑Inbox.
Dokumentation des tatsächlich umgesetzten Fahrrad‑Schnäppchen‑Scouts: sichere Telegram‑Aufnahme, zweistufige Analyse, bildgestützte Modellidentifikation, forensische Prüfung hochpreisiger Kandidaten, persistente Verarbeitung, nachverfolgte Zustellung und Statistik. Stand: 14. September 2026.
Der Scout verarbeitet neue, vom fest konfigurierten Kleinanzeigen‑Monitorbot gelieferte Anzeigen automatisch. Er filtert erst günstig über Text, untersucht nur Verdachtsfälle mit Bildern vertieft und meldet ausschließlich policy‑konforme Deals – oder konservative Fälle zur manuellen Prüfung – in diesen Telegram‑Chat.
Telegram‑Nachricht → validierter Ingress → kanonische Kleinanzeigen‑Anzeige → SQLite‑Inbox.
Textfilter hält Kosten gering; Bild-/Tiefenanalyse wird nur bei promote ausgelöst.
Unklare, ungültige oder technisch unvollständige Daten führen nicht zu einem Schnäppchen‑Alert.
scout bewertet den vollständigen Anzeigentext. Er lässt nur MTB, Rennrad und Gravel zu; Teile, Gesuche, falsche Kategorien und E‑Bikes werden verworfen. Generischer Titel, knapper Text oder VB können einen Verdacht (promote) auslösen.promote ruft die Seite und maximal begrenzte First‑Party‑Bildkandidaten ab. Der scout-deep-Runner bewertet Text plus flüchtige Bilddateien nach dem Fachskill.alert_dedupe genau einmal den Schlüssel.alert wird als potenzielles Schnäppchen ausgeliefert. Ein abgeschlossener manual_review ohne rotes Risiko wird als klar gekennzeichnete Prüfmeldung ausgeliefert. Alle anderen Zustände lösen keine Nachricht aus.Die produktive Inbox ist SQLite mit aktivierten Foreign Keys und vorwärtsgerichteten Migrationen. Roh‑Telegram‑Text ist nicht Teil des Ingress‑Events. Anzeigentext wird nur dort gespeichert, wo er für die ausdrücklich gewünschte Textanalyse erforderlich ist.
| Migration | Tabellen | Zweck |
|---|---|---|
0001 | ingress_events, source_items | Idempotenter, textfreier Nachrichteneingang und kanonische Quellen. |
0002 | workflow_revisions, workflow_queue, workflow_runs, budget_ledger, alert_dedupe | Workflow‑Grundlage: atomare Claims, Leases, Recovery/Reconcile, Ledger und einmalige Alert‑Reservierung. |
0003 | listing_text | Vollständiger Listing‑Text für die Stufe‑1‑Fachprüfung; Preis und Ort für die Analyse bzw. Darstellung. |
0004 | screen_results | Textfilter‑Entscheidung, Kategorie/Zustandsband und begrenzte Reason‑Codes. |
0005 | deep_results | Tiefenanalyse, Evidenzqualität, konservative Marge, Risiken und Reason‑Codes. |
Agent: scout. Primärmodell: OpenAI GPT‑5.6 Luna über vorhandenes OAuth. Fallback: DeepSeek V4 Flash.
Input: vollständiger Anzeigentext mit Titel, Beschreibung, Preis und Ort, als explizit untrusted markierter Block. Generische Beschreibungen dürfen bei Schnäppchensignalen zur Bildanalyse weitergehen; harmlose überlange Reason-Listen werden normalisiert.
Agent: scout-deep. Primär: Gemini 2.5 Flash. Backup: DeepSeek Vision nur bei einem technischen Gemini-Bildfehler.
Es werden nur Bilder der geöffneten Anzeige akzeptiert, nie Vorschauen ähnlicher Anzeigen. Ein fachlicher reject für MTB, Rennrad oder Gravel braucht Marktwert und konservative Marge; sichtbare strukturelle Schäden bleiben die Ausnahme. Abholung, Rechnung oder OVP-/Katalogbilder sind keine Betrugsindikatoren.
marie_fit = confirmed. E-MTB sowie City-/Trekking-Pedelecs bleiben ausgeschlossen.incomplete / images_missing – wird nicht als fachliches manual_review kaschiert. Gemini wird nach DeepSeek-Backup genau einmal mit frischem Seiten-, Bild- und Modellabruf wiederholt; danach wird ein sichtbarer terminaler Fehlerstatus gespeichert.alert durch eine harte Regel blockiert – etwa weil sichtbare Scheibenbremsen nicht bestätigt sind – steht dort klar „Alert blockiert“ samt Grund. Solche Fälle werden weder versendet noch als Alert gezählt.Erfordert alert, abgeschlossene Analyse, positive konservative Netto‑Marge, Evidenz medium oder high und kein rotes Risiko.
Erfordert manual_review, mindestens mittlere Evidenz, kein rotes Risiko und eine konkrete, vor dem Kauf klärbare Frage. Low‑Evidence- und rein technische Fälle werden nicht zugestellt.
Jede Reservierung wird nach dem Versand als sent, failed oder bei Timeout als ambiguous gespeichert. Nur bestätigte Fehler sind bei späterer Neubewertung erneut zustellbar; ein Timeout wird nicht blind doppelt versendet.
Die Meldung enthält Titel, Preis-/Ortseinordnung soweit validiert, Evidenz, Risiken/offene Punkte, Verkäuferfragen und den kanonischen Kleinanzeigen‑Link. Sie ist eine Kaufprüfung, keine Kauf- oder Kontaktaktion.
| Bereich | Umsetzung |
|---|---|
| Telegram‑Session | Private Config und Umgebung außerhalb des Repositories; restriktive Rechte. Der Dauerlistener benutzt eine temporäre Kopie der Originalsession. |
| Quelle | Nur kanonische Kleinanzeigen‑Einzelanzeigen; HTTPS, Host-/Redirect‑Allowlist, harte Zeit‑ und Größenlimits; kein Login, CAPTCHA‑Bypass, Proxy oder Ersatzkandidat. |
| Untrusted Input | Beschreibung, Titel, Bilder und Links steuern niemals Skill, Tool, Empfänger, Pfad oder Modell. Schema‑Validatoren weisen Zusatzfelder und ungültige Enums ab. |
| Modelle | Dedizierte Agenten mit minimalem Toolprofil; keine Modelltools für Shell, Web, Datei oder Messaging. |
| Versand | Deterministische Policy plus Dedupe vor dem Senden. Keine automatische Kontaktaufnahme mit Verkäufern. |
| Not-Aus | systemctl --user stop deal-scout-listener stoppt die Aufnahme; Inbox und autorisierte Session bleiben erhalten. |
| Arbeitspaket | Ergebnis | Wichtige Erkenntnis / Abweichung |
|---|---|---|
| AP1–AP3 | Ingress, Adapter, SQLite‑Inbox | Textfreier Erstkontakt, idempotente Speicherung und strikte Kleinanzeigen‑Normalisierung. |
| AP4 | Telethon‑Owner‑Handoff, Session‑Sicherheit, begrenzter Empfang | Autorisierung, temporäre Sessionkopien und Monitorbot‑Bindung wurden vor Dauerbetrieb verifiziert. |
| AP5 | Isolierter OpenClaw‑ACK‑Nachweis | Zeigte die sichere Modell‑Einbettung mit deny‑all Tooloberfläche; kein Fachlauf. |
| AP6 | Workflow‑/Queue‑Fundament | Atomare Claims, Lease‑Recovery, Reconcile, Ledger und Alert‑Dedupe offline getestet. |
| AP7 | Quellen-/Strukturspikes | Enge HTML-/JSON‑LD‑Extraktoren waren für reale Seiten zu fragil. Daraus entstand bewusst der pragmatische Pfad: begrenzter Abruf → vollständiger Text → Modellanalyse, statt breites Scraping. |
| AP8 | Statisches Routing | Nur bike → bike-deals-v1; keine dynamisch durch Daten gesetzten Workflows. |
| AP9 | Zweistufige Fahrradlogik | Vom ursprünglichen Terra‑Vorschlag zu Luna/OAuth als Textstandard; neuer allgemeiner Agent scout statt bikespezifischem Agentennamen. |
| Live‑Integration | Daemon, scout-deep, Gemini‑Vision und Versand | Gemini ist Bildprimärmodell; DeepSeek dient als technisches Backup. manual_review wird nur bei fachlich auflösbarem Potenzial ausgeliefert. |
| Statistik | Öffentliche, responsive Übersichtsseite | 15‑Minuten‑Refresh, Zeitraumfilter, Timeline mit Titel, Link, Preis und vom Owner freigegebenem PLZ/Ort. Keine Rohtexte oder Verkäuferdaten in der Statistik. |
Der User‑Service deal-scout-listener startet den Listener mit UMask=0077 und Restart=on-failure. Aktueller Status: active/running · 0 Restarts.
Service-Status: systemctl --user status deal-scout-listener
Live-Logs: journalctl --user -u deal-scout-listener -f
Generiert im 15‑Minuten‑Takt aus der Inbox, mit Filtern für Alle, Heute, Woche, Monat und Jahr. Die Timeline verlinkt bewusst auf die Anzeige und zeigt ihren gespeicherten Preis; andere Statistikbereiche bleiben aggregiert.
256 Unit-/Integrations-/Contract‑Tests bestehen. Der systemd‑Dienst läuft aktiv ohne Neustarts.
Telegram‑Eingang, Textanalyse, Bildpfad, Fallback, Persistenz und Dedupe wurden live mit begrenzten Kandidaten ausgeführt.
Der Versandpfad ist aktiv und policy-konforme reale Alerts werden einmalig zugestellt.
manual_review erhältst du eine konservative Prüfmeldung nur bei fachlich klärbarem Potenzial und mindestens mittlerer Evidenz; bei alert einen potenziellen Schnäppchentreffer. Bei reject, uncertain oder technischen Fehlern wird nicht gestört.Gemini analysiert Bilder primär, DeepSeek dient nur als technisches Backup. Bei Timeout, Bild-/Transport- oder Modellprozessfehler folgt genau ein frischer Retry mit neuem Seitenabruf, Bilddownload und Modellprozess. Nach zwei technischen Fehlschlägen wird ein sichtbarer terminaler Fehlerstatus gespeichert; fachliche Entscheidungen und ungültige Modellinhalte werden nicht wiederholt.
manual_review wird nur bei mindestens mittlerer Evidenz, ohne rotes Risiko und mit einer konkreten, vor der Abholung klärbaren Frage gesendet. Low‑Evidence- und rein technische Fälle bleiben intern. Telegram-Nachrichten erklären Modell, Preisvorteil, Marktwert, Spielraum und konkrete Prüfschritte in Klartext; technische Codes stehen nur auf der Statusseite.
Die Statusseite wurde am 07.09.2026, 19:42 UTC soft zurückgesetzt. Anzeigenliste, Kennzahlen und Alerts zeigen nur neue Daten seit diesem Zeitpunkt; Datenbank, Dedupe, Fehlerhistorie und Listener bleiben unverändert. Stufe‑1- und Stufe‑2‑Verteilungen sind standardmäßig eingeklappt. Teststand dieser Änderung: 236/236 grün.