Happy Thoughts

Happy Thoughts ist ein Antwort-Produkt, das auf einer einfachen Aufteilung basiert:

• Konsens hilft Nutzern beim Denken

• Faktencheck hilft Nutzern beim Vertrauen

Die öffentlich kommunizierte Idee ist nicht „wähle das richtige Modell“. Sie lautet: Erhalte zuerst eine nützliche Antwort und zahle dann für eine stärkere Verifizierung, wenn es um mehr geht.

Hier starten

Wenn Sie gerade erst im Repo gelandet sind, nutzen Sie diesen Pfad:

1. Das Produkt verstehen → diese README

2. Die öffentliche API-Oberfläche sehen → public/llm.txt oder public/openapi.json

3. Als Anbieter integrieren → docs/PROVIDER_QUICKSTART.md

4. Ein praktisches Muster stehlen → docs/PROVIDER_EXAMPLES.md

5. Den Anbietervertrag in der Praxis erkunden → docs/HOSTED_PROVIDER_DELIVERY.md

Related MCP server: hyperd-mcp

Für wen dieses Repo gedacht ist

• Entwickler, die Käufer-Flows integrieren

• Gehostete Anbieter, die die Angebotsseite integrieren

• Betreiber, die Pläne, Berechtigungen und das öffentliche Produktverhalten überprüfen

• Mitarbeiter, die den Vertrag benötigen, nicht die geheimen Interna

Architektur auf einen Blick

Betrachten Sie Happy Thoughts als einen einfachen 3-Schichten-Stack:

1. Käuferschicht

   • Menschen oder Agenten bitten um eine Antwort

   • kostenlos beginnt bei Konsens

   • bezahlt schaltet Faktencheck frei

2. Produktschicht

   • erzwingt Pläne, Quoten und Gating

   • routet Anfragen durch den öffentlichen Vertrag

   • gibt eine saubere Antwortform mit Konfidenz + Vorbehalten zurück

3. Anbieterschicht

   • gehostete Anbieter und Webhook-Anbieter liefern Antworten im Hintergrund

   • Anbieter bleiben wichtig, aber Nutzer müssen die Backend-Mechanik nicht zuerst verstehen

Diese Trennung ist der ganze Punkt: Das Produkt fühlt sich oben einfach an, während die Angebotsseite unten flexibel bleibt.

Produkt-Framing

Konsens

Kostenloser oder begrenzter Einstiegspfad.

Konsens vergleicht mehrere Modellantworten, synthetisiert sie zu einer einzigen Antwort und gibt Konfidenz sowie Vorbehalte zurück. Es ist konzipiert für:

• alltägliche Fragen

• exploratives Denken

• Entscheidungsunterstützung bei geringem Risiko

• breite Zugänglichkeit

Faktencheck

Bezahlte Vertrauensschicht.

Faktencheck ist der Zweig mit höherer Sicherheit für Prompts, bei denen faktische Konfidenz wichtiger ist als Geschwindigkeit oder Kosten. Intern ist der Anfragemodus für die Kompatibilität immer noch verified, aber die öffentliche Produktsprache ist Faktencheck. Es ist darauf ausgelegt, eine prägnante endgültige Antwort zurückzugeben, während eine tiefere Verifizierungsstruktur im Hintergrund verfügbar bleibt. Es ist konzipiert für:

• Überprüfungen im Stil eines Faktenchecks

• Prompts mit höherem Risiko

• stärkere Vertrauenssignale

• Premium-UX und Abrechnungspfade

Was dieses Repo enthält

• Cloudflare Worker-Anwendungscode

• Antwort-Routing- und Synthese-Logik

• Plan- / Berechtigungs-Gerüst

• Anbieterregistrierung + Plumbing für gehostete Anbieter

• Abrechnungs- und Aktivierungs-Flows

• rechtliche/öffentliche Produktdokumente

• ein kuratiertes öffentliches Codebeispiel der Worker-Oberfläche

Öffentliche Repo-Grenzen

Dieses Repo soll die Produktoberfläche und den Integrationsvertrag zeigen, nicht jede interne Ranking- oder Orchestrierungsentscheidung.

Öffentliche Dokumente sollten erklären:

• was Käufer aufrufen können

• womit Anbieter sich integrieren können

• welche Pläne/Gates existieren

• welche Antwortformen und Kontrollen stabil sind

Öffentliche Dokumente sollten nicht herausgeben:

• interne Gewichtungslogik

• private Routing-Heuristiken

• versteckte Ranking-Regler

• geheime Bewertungs-Soße

Was das Projekt interessant macht

• produktisierte Multi-Modell-Orchestrierung

• Antwort-Leiter von kostenlos zu bezahlt

• Marktplatz-Ausrichtung für gehostete Anbieter

• Durchsetzung von Quoten und Berechtigungen

• anmutige Degradierung bei Anbieterausfällen

• Worker-natives Deployment-Modell

Aktuelle implementierte Richtung

• öffentliche Anfragen standardisieren auf Konsens

• kostenlose Konsens-Quote wird durchgesetzt

• Faktencheck existiert als gegateter bezahlter Pfad

• Anbieterangebot existiert weiterhin unter der Produktoberfläche

• PayPal-Erfassungs-Flow ist gehärtet, um erst nach abgeschlossener Erfassung zu aktivieren

Zuverlässigkeitsmodell

Konsens ist darauf ausgelegt, anmutig zu degradieren.

Wenn ein Anbieter ausfällt, sollte die Anfrage nach Möglichkeit dennoch abgeschlossen werden. Fehlermetadaten werden angezeigt, anstatt stillschweigend so zu tun, als wäre alles perfekt.

Wichtige Konzepte auf Antwortebene umfassen:

• confidence

• confidence_reason

• models_used

• models_failed

• meta.degraded

• meta.failure_count

Abrechnungspfade

Happy Thoughts unterstützt derzeit zwei Aktivierungsstile:

• x402 / Agent-native Flows

• PayPal für konventionellen Checkout

Die PayPal-Aktivierung basiert auf Erfassung, nicht nur auf Genehmigung. Das hält die Berechtigungsaktivierung an die tatsächlich abgeschlossene Zahlung gebunden.

Beispiel-API-Aufrufe

Diese Beispiele sind absichtlich auf Produktebene gehalten und bereinigt. Sie zeigen, wie man Happy Thoughts verwendet, ohne interne Scoring- oder Orchestrierungslogik offenzulegen.

Um eine Konsens-Antwort bitten

curl -X POST https://happythoughts.proteeninjector.workers.dev/think \
  -H "Content-Type: application/json" \
  -d '{
    "prompt": "Give me the strongest argument against this idea.",
    "buyer_wallet": "0xabc123...",
    "mode": "consensus"
  }'

Wünschen Sie vertikale Beispiele statt generischer? Siehe docs/PROVIDER_EXAMPLES.md.

Faktencheck anfordern

curl -X POST https://happythoughts.proteeninjector.workers.dev/think \
  -H "Content-Type: application/json" \
  -d '{
    "prompt": "Fact-check this product claim and call out weak evidence.",
    "buyer_wallet": "0xabc123...",
    "mode": "verified"
  }'

Polling-Schleife für gehostete Anbieter

curl https://happythoughts.proteeninjector.workers.dev/provider/jobs/next \
  -H "Authorization: Bearer htp_your_provider_token"

curl -X POST https://happythoughts.proteeninjector.workers.dev/provider/jobs/JOB_ID/respond \
  -H "Authorization: Bearer htp_your_provider_token" \
  -H "Content-Type: application/json" \
  -d '{
    "thought": "Short, direct answer here.",
    "confidence": 0.91,
    "meta": {"style": "direct"}
  }'

Repo-Struktur

• src/ — Worker-Logik

• public/ — öffentliche Website-Assets

• docs/ — öffentliche Integrations- und Anbieterdokumente

• legal/ — Bedingungen, Datenschutz, Anbietervereinbarung, AUP

Nützliche Einstiegspunkte

• Öffentliche API-Zusammenfassung: public/llm.txt

• Maschinenlesbare Spezifikation: public/llms-full.txt

• OpenAPI: public/openapi.json

• Anbieter-Schnellstart: docs/PROVIDER_QUICKSTART.md

• Anbieter-Beispielpaket: docs/PROVIDER_EXAMPLES.md

• Spezialitätenliste: docs/SPECIALTIES.md

• Registrierungs-Schnellstart: docs/REGISTRATION_QUICKSTART.md

Hinweise zur öffentlichen Sauberkeit

Dieses Repository ist am stärksten, wenn es präsentiert wird als:

• ein Produkt-Engineering-Repo

• ein Abrechnungs- + Berechtigungs-Repo

• ein Multi-Modell-Antwortsystem

• ein Worker-natives API/App-Deployment

Nicht als „nur ein weiterer Wrapper um LLMs“.

Empfohlene Startdokumente

• docs/PROVIDER_QUICKSTART.md

• docs/PROVIDER_EXAMPLES.md

• docs/REGISTRATION_QUICKSTART.md

• docs/HOSTED_PROVIDER_DELIVERY.md

Status

Aktives Produkt-Repo mit einer klaren Richtung: kostenloser Konsens, bezahlter Faktencheck, Anbieterinfrastruktur im Hintergrund.