urieljarethandClaude Opus 5 74c0374a2a Propuesta IA: correcciones encontradas probando contra la API real de MiniMax
Tres defectos que solo se veian llamando al modelo de verdad.

1. min(2) en los factores obligaba a inventar relleno. Con una dimension sin
   cifras, MiniMax produjo "herramienta_de_seguimiento_actual=0 x canal=1" solo
   para satisfacer la restriccion. Ahora los dos factores se exigen unicamente
   cuando hay montoAnualMXN.

2. El modelo OMITE montoAnualMXN en vez de mandar null explicito, que es lo
   natural para un LLM. Exigirlo presente quemaba los tres intentos del paso.
   Ahora es .default(null) y la omision se tolera.

3. Sin confianza por factor, el modelo la metia dentro del nombre
   ("tasa_conversion (por_validar)=0.1"). Ahora es un campo.

Y el hallazgo que mas importa, porque es comercial y no de formato: el modelo
puede OMITIR un factor y aun asi cuadrar la aritmetica. En una corrida calculo
40 mensajes x 0.5 sin contestar x 52 semanas x 3,000 de utilidad POR CLIENTE =
3,120,000, asumiendo que cada mensaje sin responder es un cliente perdido. R5 lo
acepto porque los factores si multiplican al monto: R5 no puede ver lo que falta.

El ratio habria dicho "subcotizado" con el denominador inflado diez veces. Como
no se puede impedir que el modelo produzca estimaciones plausibles y erroneas, lo
que se hace es que el asesor las cache de un vistazo:
- R5b avisa cuando una cifra no tiene ni un factor confirmado.
- El anexo interno desglosa cada factor con su confianza, y alerta en rojo si el
  valor descansa entero en estimaciones.

Ademas, el presupuesto de reintentos sube (5 en extraccion, 4 en los otros dos):
MiniMax se equivoca de array de vez en cuando con schemas anidados, y la
extraccion es el paso fundacional. Una corrida real necesito los 5.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-28 18:59:42 -06:00
1
2026-06-10 02:15:05 -06:00
1
2026-06-10 02:16:08 -06:00
1
2026-06-10 02:15:05 -06:00
1
2026-06-10 02:15:05 -06:00
2026-04-27 02:36:51 -06:00
1
2026-06-10 02:16:08 -06:00
1
2026-06-10 02:04:37 -06:00
1
2026-06-10 02:04:37 -06:00
1
2026-06-10 02:04:37 -06:00

Cotizador E3

Sistema de generación de cotizaciones para Consultoría E3 (marketing digital, Querétaro MX). Servicios organizados en 4 fases, dos tipos de pago (único / mensual), planes CRM Bucéfalo y financiamiento opcional. Exporta a PDF y Excel.

Stack

  • Frontend / app web: Next.js 16 (App Router) + React 19 + Tailwind CSS v4 + Zustand
  • ORM: Prisma 7 (cliente generado en src/generated/prisma, driver adapter PrismaPg)
  • Base de datos: PostgreSQL 16 (vía Docker)
  • Auth: JWT (jose) en cookie httpOnly, contraseñas con bcryptjs
  • API alterna: servicio Python FastAPI en api/ (para n8n / integraciones)

Requisitos

  • Node.js 20+
  • Docker (para PostgreSQL)
  • Un archivo .env en la raíz — copia .env.example y define al menos JWT_SECRET

Arranque rápido (Windows)

start.bat   :: levanta PostgreSQL en Docker, aplica migraciones y arranca Next.js
stop.bat    :: detiene todo

Arranque manual

docker compose up -d postgres   # base de datos
npx prisma migrate deploy        # aplica migraciones
npx tsx prisma/seed.ts           # carga catálogo (idempotente)
npm run dev                      # http://localhost:3000

Comandos

Comando Propósito
npm run dev Servidor de desarrollo (puerto 3000)
npm run build Build de producción (incluye chequeo de tipos)
npm run lint ESLint
npm run db:migrate prisma migrate dev
npm run db:seed Carga de datos semilla
npm run db:studio Prisma Studio
npm run db:generate Regenera el cliente Prisma

API Python (opcional)

cd api
pip install -r requirements.txt
uvicorn main:app --reload --port 8000   # Swagger en /docs

Referencia completa de endpoints en api/COTIZADOR_API_SKILL.md.

Despliegue en Coolify

El stack de producción está en docker-compose.coolify.yml: postgres + web (Next.js) + api (FastAPI). El contenedor web aplica las migraciones de Prisma automáticamente en cada arranque.

Pasos

  1. Sube el repo a GitHub (privado recomendado).
  2. En Coolify: + New Resource → Docker Compose, conecta el repo y la rama.
  3. En la configuración del recurso, define Docker Compose Location = /docker-compose.coolify.yml.
  4. Coolify detecta los servicios y asigna dominio a web (puerto 3000) y api (puerto 8000) vía las variables SERVICE_FQDN_* — configura los dominios deseados en la UI.
  5. Define las variables de entorno en Coolify:
Variable Obligatoria Notas
JWT_SECRET openssl rand -base64 32
API_KEY Sí (para el API) Clave para agentes/n8n
DB_PASSWORD Recomendada Password de PostgreSQL (default postgres)
RUN_SEED Primer deploy true solo la primera vez; luego false
SEED_ADMIN_EMAIL / SEED_ADMIN_PASSWORD / SEED_ADMIN_NAME Primer deploy Usuario admin inicial
SEED_ASESOR_EMAIL / SEED_ASESOR_PASSWORD / SEED_ASESOR_NAME No Asesor opcional
  1. Deploy. Orden de arranque: postgres (healthy) → web (migra + seed + sirve) → api.
  2. Después del primer despliegue exitoso, cambia RUN_SEED a false y redeploya (el seed es idempotente, pero no hace falta correrlo cada vez).

Healthchecks

  • Web: GET /api/health (verifica también la conexión a la BD)
  • API: GET /health

Notas

  • No expongas el puerto 5432: los servicios se comunican por la red interna del compose.
  • El volumen postgres_data persiste la base de datos entre deploys. No lo borres.
  • El API expone REST en https://<dominio-api> con auth por X-API-Key o JWT. El servidor MCP se retiro el 2026-07-28 (ver AGENTS.md).
  • Las versiones de api/requirements.txt estan fijas a proposito: un rango abierto dejo entrar mcp 2.0.0 y tumbo el API en produccion. Sube dependencias a proposito, no al redesplegar.
  • La fórmula de financiamiento y los cálculos viven duplicados en src/lib/calculators.ts y api/app/services/calculators.py — mantenlos en paridad.

Documentación para agentes

Las convenciones del proyecto, gotchas de Prisma 7 / PDFKit / Next.js 16 y el modelo de datos están en AGENTS.md (importado por CLAUDE.md).

S
Description
Cotizador E3
Readme
5.6 MiB
Languages
TypeScript 78%
Python 21.2%
Dockerfile 0.3%
Batchfile 0.2%
CSS 0.2%