Skip to content

ROO_CODE_TEST_PROMPT.md

Latest commit

 

History

History
101 lines (73 loc) · 9.56 KB

ROO_CODE_TEST_PROMPT.md

File metadata and controls

101 lines (73 loc) · 9.56 KB
Raw

Prompt para Roo Code + DeepSeek — Seguir probando y corrigiendo el Bot Cotizador "Alex"

Copia TODO este bloque en un CHAT NUEVO de Roo Code (modo Code, con DeepSeek) dentro del workspace bot_cotizador, y ejecuta los comandos desde la raíz del proyecto. Este prompt prueba UN SOLO cliente ficticio: primero te preguntará qué tipo de página quieres que ese cliente esté considerando.

Actúa como un señor: consultor senior con años cerrando proyectos de páginas web en México y, a la vez, como QA riguroso del proyecto bot_cotizador (el bot "Alex", que habla como un señor con años de experiencia —sin tecnicismos—, entrevista a clientes y arma propuestas comerciales + PDF).

MÉTODO DE TRABAJO (muy importante):

  1. ANTES de probar nada, pregúntame qué tipo de página quiero que esté considerando el cliente ficticio (elige UNA de las opciones del punto 3). No lo inventes por tu cuenta.
  2. Con mi respuesta defines UN solo cliente ficticio coherente y me lo confirmas.
  3. Pruebas el bot interpretando a ESE único cliente, de forma natural y realista.
  4. Detectas errores de lógica/precios/copy, los corriges en el código y proteges cada fix con un assert de regresión.

No inventes requisitos; respeta la arquitectura existente.

1) Contexto (léelo; NO reinventes la arquitectura)

  • Arquitectura HÍBRIDA (NO romper): DeepSeek redacta el TEXTO de cada turno (lib/chat-llm.ts + app/api/chat/route.ts); el ESTADO lo decide la máquina determinista (lib/conversation-flow.ts + lib/chat-store.ts). El LLM solo pinta el mensaje; si falla o tarda, usa fallbackReply (circuit breaker).
  • Regla de oro del precio (NO romper): UN solo número de punta a punta: precio exacto = quoteTotal (motor calculateQuote); cuota "Desde $X/mes" = total/24; copy "Piensa en esto"/"¿Por qué este precio?" y PDF citan ese MISMO total. NUNCA mezclar precio_min (clamp por giro) con quoteTotal.
  • Mapa de archivos (léelos antes de tocar):
    • lib/conversation-flow.ts → grafo de nodos/saltos · lib/chat-store.ts → motor + persistencia sessionStorage (bot_cotizador:result) · lib/personality.ts → clasificación y señales · lib/pricing-catalog.ts → inferCategory/resolverCategoria/buildFallbackProposal · lib/industry-pricing.ts → giros/ajustarPrecio/adaptarCopyGiro/filtrarPorDeclinados · lib/quote-engine.ts → calculateQuote · lib/openrouter.ts → enrichCommercial · components/results/ProposalView.tsx → precio mostrado · scripts/regression-test.ts → regresión.

2) Cómo correr y validar

  • npm run dev → http://localhost:3000 (/chat, /results).
  • npm run test:regression → DEBE quedar en 0 fallos tras cada cambio.
  • npm run build (valida tipado) + npm run lint. OJO: NO corras npm run build mientras npm run dev esté activo en el mismo workspace (corrompe .next); si pasa, rm -rf .next y reinicia.
  • Sin navegador: simula la conversación con tsx + buildFallbackProposal(...) (ver fase G del test).

3) PRIMERO: pregúntame qué tipo de página considera el cliente ficticio

Antes de abrir el navegador, pregúntame con opciones claras qué tipo de página quieres que esté considerando el cliente ficticio. Elige UNO:

  • Landing / página de presentación (p. ej. tienda de ropa, restaurante, taller, barbería).
  • Tienda online / ecommerce (carrito y pagos en línea).
  • Sistema de citas / reservaciones (clínica, estética, dentista).
  • Plataforma o sistema web a medida (panel, usuarios, base de datos).
  • Blog / sitio de contenido.
  • Portafolio profesional.
  • Cliente que NO sabe nada de tecnología (sin conocimientos técnicos: no entiende de hosting, dominios, SEO, "backend" ni de páginas web en general; hay que explicarle en sencillo).

Cuando me respondas, arma UNA ficha de cliente ficticio coherente con ese tipo y confírmamela antes de probar: giro, ciudad, presupuesto típico, funciones que quiere y cuáles declinará. Si elegiste el cliente "que no sabe nada de tecnología", la ficha debe incluir su nivel técnico (nulo) y el bot debe explicarle sin tecnicismos (qué es dominio, hosting, SEO, etc., si hace falta). Guiones de apertura según el tipo:

  • Landing: "Hola, tengo una tienda de ropa en Guadalajara y quiero una página sencilla para que la gente me encuentre por internet. Algo básico, no muy caro."
  • Ecommerce: "Quiero una tienda online con carrito, pagos con tarjeta y envíos para vender mis productos por internet."
  • Citas: "Tengo una clínica dental y quiero que la gente agende sus citas en línea."
  • Webapp: "Necesito un sistema para administrar clientes, inventario y reportes."
  • No sabe de tecnología: "Mire, la verdad yo de esto de las páginas de internet no sé nada, ni le entiendo a eso de las tecnologías ni del hosting ni nada. Solo quiero que me hagan una página para mi negocio que se vea bien, pero explíqueme en sencillo porque no le entiendo."

3b) Cómo ejecutar la prueba de ESE único cliente

  • Abre /chat → "Nueva conversación" y responde como el cliente ficticio, de forma natural y con muletillas (nada de respuestas de una palabra si el personaje no lo amerita).
  • Recorre hasta la propuesta final y verifica la checklist del punto 4.
  • El foco es UN solo cliente por sesión. Si quieres probar además un caso borde (cliente indeciso o que cambia de opinión a mitad), dímelo y se hace como segunda vuelta después de cerrar la principal.

4) Checklist de invariantes (VERIFICA EN CADA PRUEBA)

  • Categoría correcta y coherente con lo que pidió (landing/citas/ecommerce/webapp/portafolio/blog).
  • Precio único y coherente: el precio mostrado, la cuota ($/24), el copy de valor, "¿Por qué este precio?" y el PDF citan el MISMO total exacto. Sin rangos que contradigan.
  • Nada que el cliente declinó aparece en funcionalidades/entregables/stack (mapa, Supabase, panel, cuentas, pagos, citas, PDFs, PWA). En landings básicas el stack debe ser Next.js + Tailwind + Vercel (sin Supabase).
  • Si el cliente dio presupuesto < total, aparece el mensaje honesto ("dijiste hasta $X y parte de $Y; dime y ajusto alcance").
  • Los datos de contacto se guardan LIMPIOS (nombre real, email válido, teléfono normalizado "+52 ..."); la duda "no sé" NO guarda basura y re-pregunta (máx 2); "no tengo/no doy" avanza sin forzar.
  • El flujo NO hace preguntas redundantes ni ciclos de clarificación; para landing no debe preguntar por pagos/PDFs (se saltan por categoría).
  • Cliente sin conocimientos técnicos: el bot habla en lenguaje sencillo, sin tecnicismos (explica qué es hosting/dominio/SEO si hace falta), NO asume que entiende, y sus dudas ("¿eso qué es?", "no le entiendo") se atienden con empatía sin romper el flujo ni guardar basura.
  • El chat NO promete montos exactos ni confirma que el presupuesto del cliente alcanza (regla del system prompt).
  • Cierre completo: nombre → correo → teléfono → comentarios → propuesta → PDF descargable.

5) Bugs ya corregidos (NO reintroducir — respeta estos comportamientos)

  • inferCategory: "tienda de ropa" + "página sencilla/catálogo/me encuentren" → landing, NO ecommerce. Ecommerce requiere señales de venta en línea real (carrito, checkout, pagar en línea, "vender por internet", "tienda online", envíos).
  • resolverCategoria(ctx): ecommerce→landing si pagos===false; webapp→landing si no hay panel+BD+login.
  • cuota_mensual se deriva SIEMPRE de quoteTotal/24 en ProposalView (nunca del clamp del giro).
  • filtrarPorDeclinados retira ítems que prometen funciones declinadas.
  • budget.nextNode avanza si hay monto aunque la frase tenga "no sé cuánto cobran" (antes se perdía el monto).
  • ProposalView muestra mensaje honesto cuando el presupuesto dicho < total.
  • chat-llm: prohibido prometer/confirmar montos en el turno de presupuesto.
  • No usar new RegExp(re.source, flags) sin flag "g" (loop infinito en exec()).

6) Pendientes conocidos (fuera del alcance del código — NO tocar secretos)

  • Los CTAs de contacto usan PLACEHOLDERS (wa.me/52833, mailto:tu@correo.com, "Tu Nombre") porque las env vars reales las pone el usuario en Vercel (NEXT_PUBLIC_DEVELOPER_WHATSAPP/EMAIL/NAME/AGENCY_NAME). NUNCA pidas ni escribas credenciales/API keys; si algo las requiere, dile al usuario que las agregue él mismo en el dashboard.

7) Reglas de trabajo al corregir

  1. Investiga la causa raíz (lee el archivo y su flujo) antes de editar; no parchees a ciegas.
  2. Corrige en el lugar correcto y de forma idiomática; mantén la voz de "señor" del bot (consultor senior, sin tecnicismos, español de México).
  3. Agrega SIEMPRE un assert a scripts/regression-test.ts que fije el comportamiento corregido (usa fireOnReceive, inferCategory, resolverCategoria, filtrarPorDeclinados, calculateQuote, o una conversación checkLanding completa como las 5 existentes).
  4. Tras cada fix: npm run test:regression (0 fallos) y npm run build (limpio).
  5. Si el fix involucra texto que ve el cliente, valídalo en el navegador con npm run dev (persona de prueba).

8) Formato de entrega

Al terminar la prueba de ESE cliente, entrégame:

  • La ficha del cliente ficticio probado (tipo de página, giro, ciudad, presupuesto, funciones queridas/declinadas).
  • Resultado de la prueba: categoría que detectó el bot, precio exacto, cuota al mes, y si cumplió la checklist del punto 4.
  • Errores encontrados (archivo/función) y el fix aplicado.
  • Asserts de regresión agregados y conteo final (debe ser ≥ 95 y 0 fallos).
  • Cualquier mejora propuesta (no implementada) con prioridad (P0/P1/P2).