Happy Thoughts

Happy Thoughts es un producto de respuestas construido en torno a una división sencilla:

• El Consenso ayuda a los usuarios a pensar

• La Verificación de hechos ayuda a los usuarios a confiar

La idea orientada al público no es "elegir el modelo correcto". Es: obtener primero una respuesta útil y, después, pagar por una verificación más sólida cuando hay mucho en juego.

Empieza aquí

Si acabas de llegar al repositorio, utiliza esta ruta:

1. Entender el producto → este README

2. Ver la superficie de la API pública → public/llm.txt o public/openapi.json

3. Integrarse como proveedor → docs/PROVIDER_QUICKSTART.md

4. Copiar un patrón práctico → docs/PROVIDER_EXAMPLES.md

5. Explorar el contrato de proveedor en la práctica → docs/HOSTED_PROVIDER_DELIVERY.md

Related MCP server: hyperd-mcp

Para quién es este repositorio

• desarrolladores que integran flujos de compradores

• proveedores alojados que integran el lado de la oferta

• operadores que revisan planes, derechos y comportamiento del producto público

• colaboradores que necesitan el contrato, no los detalles internos secretos

Arquitectura de un vistazo

Piensa en Happy Thoughts como una pila sencilla de 3 capas:

1. Capa de comprador

   • humanos o agentes piden una respuesta

   • el acceso gratuito comienza en Consenso

   • el pago desbloquea la Verificación de hechos

2. Capa de producto

   • aplica planes, cuotas y restricciones

   • enruta las solicitudes a través del contrato público

   • devuelve una forma de respuesta limpia con confianza + advertencias

3. Capa de proveedor

   • los proveedores alojados y los proveedores de webhook suministran respuestas por debajo

   • los proveedores siguen siendo importantes, pero los usuarios no necesitan entender primero la mecánica del backend

Esa separación es el objetivo principal: el producto parece sencillo por fuera mientras que el lado de la oferta sigue siendo flexible por debajo.

Encuadre del producto

Consenso

Ruta de entrada gratuita o limitada.

El Consenso compara múltiples respuestas de modelos, las sintetiza en una única respuesta y devuelve la confianza junto con advertencias. Está diseñado para:

• preguntas cotidianas

• pensamiento exploratorio

• apoyo a la toma de decisiones de bajo riesgo

• amplia accesibilidad

Verificación de hechos

Capa de confianza de pago.

La Verificación de hechos es la rama de mayor garantía para las consultas donde la confianza factual importa más que la velocidad o el coste. Internamente, el modo de solicitud sigue siendo verified por compatibilidad, pero el lenguaje del producto público es verificación de hechos. Está diseñado para devolver una respuesta final concisa manteniendo una estructura de verificación más profunda disponible por debajo. Está diseñado para:

• revisiones al estilo de verificación de hechos

• consultas de mayor riesgo

• señales de confianza más fuertes

• rutas de UX y facturación premium

Qué contiene este repositorio

• código de aplicación de Cloudflare Worker

• lógica de enrutamiento y síntesis de respuestas

• andamiaje de planes / derechos

• registro de proveedores + infraestructura de proveedores alojados

• flujos de facturación y activación

• documentos legales/de producto público

• una muestra de código público curada de la superficie del Worker

Límites del repositorio público

Este repositorio pretende mostrar la superficie del producto y el contrato de integración, no cada decisión interna de clasificación u orquestación.

Los documentos públicos deben explicar:

• qué pueden llamar los compradores

• con qué pueden integrarse los proveedores

• qué planes/puertas existen

• qué formas de respuesta y controles son estables

Los documentos públicos no deben entregar:

• lógica de ponderación interna

• heurísticas de enrutamiento privadas

• controles de clasificación ocultos

• salsa secreta de evaluación

Qué hace interesante al proyecto

• orquestación multimodelo productivizada

• escalera de respuestas de gratuito a pago

• dirección de mercado de proveedores alojados

• aplicación de cuotas y derechos

• degradación elegante cuando los proveedores fallan

• modelo de despliegue nativo de worker

Dirección implementada actualmente

• las solicitudes públicas tienen como valor predeterminado el Consenso

• se aplica la cuota de consenso gratuita

• la Verificación de hechos existe como una ruta de pago restringida

• la oferta de proveedores sigue existiendo bajo la superficie del producto

• el flujo de captura de PayPal está reforzado para activarse solo después de una captura completada

Modelo de fiabilidad

El Consenso está diseñado para degradarse elegantemente.

Si un proveedor falla, la solicitud debería completarse siempre que sea posible. Los metadatos de fallo se muestran en lugar de fingir silenciosamente que todo es perfecto.

Los conceptos importantes a nivel de respuesta incluyen:

• confidence

• confidence_reason

• models_used

• models_failed

• meta.degraded

• meta.failure_count

Rutas de facturación

Happy Thoughts admite actualmente dos estilos de activación:

• flujos x402 / nativos de agente

• PayPal para pagos convencionales

La activación de PayPal se basa en la captura, no solo en la aprobación. Eso mantiene la activación de derechos vinculada al pago completado real.

Ejemplos de llamadas a la API

Estos ejemplos son intencionadamente a nivel de producto y están saneados. Muestran cómo usar Happy Thoughts sin exponer la lógica interna de puntuación u orquestación.

Pedir una respuesta de Consenso

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"
  }'

¿Quieres ejemplos verticales en lugar de genéricos? Consulta docs/PROVIDER_EXAMPLES.md.

Solicitar Verificación de hechos

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"
  }'

Bucle de sondeo de proveedor alojado

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"}
  }'

Estructura del repositorio

• src/ — Lógica del Worker

• public/ — activos del sitio público

• docs/ — documentos públicos de integración y proveedores

• legal/ — términos, privacidad, acuerdo de proveedor, AUP

Puntos de entrada útiles

• Resumen de la API pública: public/llm.txt

• Especificación legible por máquina: public/llms-full.txt

• OpenAPI: public/openapi.json

• Inicio rápido para proveedores: docs/PROVIDER_QUICKSTART.md

• Paquete de ejemplos para proveedores: docs/PROVIDER_EXAMPLES.md

• Lista de especialidades: docs/SPECIALTIES.md

• Inicio rápido de registro: docs/REGISTRATION_QUICKSTART.md

Notas sobre la limpieza pública

Este repositorio es más fuerte cuando se presenta como:

• un repositorio de ingeniería de producto

• un repositorio de facturación + derechos

• un sistema de respuesta multimodelo

• un despliegue de API/aplicación nativo de worker

No como "solo otro envoltorio alrededor de LLMs".

Documentos de inicio sugeridos

• docs/PROVIDER_QUICKSTART.md

• docs/PROVIDER_EXAMPLES.md

• docs/REGISTRATION_QUICKSTART.md

• docs/HOSTED_PROVIDER_DELIVERY.md

Estado

Repositorio de producto activo con una dirección clara: Consenso gratuito, Verificación de hechos de pago, infraestructura de proveedores por debajo.