chore: bootstrap MNQ Astro site

2026-05-07 18:23:50 +02:00
commit 51b0d1fb67
28 changed files with 7543 additions and 0 deletions
@@ -0,0 +1,108 @@
+# MNQ Critical Fixes Design
+
+## Goal
+Corregir los problemas críticos visibles del sitio actual de MNQ Catering y Evento sin introducir todavía CMS, base de datos, chatbot ni backend temporal innecesario.
+
+## Context
+El proyecto ya cuenta con Astro 5 SSR, layout compartido, páginas aprobadas y sistema CSS base. Sin embargo, hoy está en fase skeleton: el número de WhatsApp está hardcodeado con un placeholder, el formulario de contacto no es funcional y la Home/Contacto todavía no sostienen una narrativa comercial premium completa.
+
+## Scope for This Phase
+
+### Included
+- Centralizar el número de WhatsApp y los mensajes base en una sola fuente de configuración.
+- Reemplazar el placeholder actual en header/footer/botón flotante/CTAs.
+- Mantener el formulario de contacto visible.
+- Hacer que el submit del formulario muestre feedback elegante de “próximamente disponible” y redireccione la intención al CTA principal de WhatsApp.
+- Reforzar la Home con secciones editoriales mínimas pero reales.
+- Reforzar Contacto para que WhatsApp sea la acción primaria y el formulario la secundaria.
+- Agregar mejoras base de accesibilidad y metadata mínima de layout.
+
+### Explicitly Excluded
+- Strapi 5.44.
+- PostgreSQL 17, pgvector o RAG.
+- Chatbot.
+- Integración con Groq, Ollama o embeddings.
+- Endpoint temporal para formulario.
+- Modelado de contenido dinámico.
+
+## Approach Options Considered
+
+### Option A — Minimal Smart Fixes (chosen)
+Resolver solo lo crítico visible, dejando el sitio comercialmente más creíble y técnicamente preparado para una fase 2 más seria.
+
+### Option B — Broader Commercial Expansion
+Además de lo crítico, expandir ya las páginas de servicio con más contenido editorial y bloques de valor.
+
+### Option C — Early Future Architecture
+Introducir desde ahora contratos y preparación para CMS/chatbot, aun sin backend real.
+
+## Why Option A
+Es la mejor relación impacto/costo. El problema actual no es sofisticación arquitectónica sino credibilidad comercial y coherencia UX. Meter estructura futura ahora sería sobreingeniería prematura.
+
+## Functional Design
+
+### WhatsApp Configuration
+Se definirá una única fuente compartida para:
+- número de WhatsApp
+- URL base `wa.me`
+- mensajes por contexto si hace falta
+
+Esto evita repetir strings en páginas y componentes, y deja el sitio listo para conectar luego con CMS o variables de entorno.
+
+### Contact Form Behavior
+El formulario seguirá visible como señal de producto serio, pero no prometerá una integración inexistente.
+
+Comportamiento:
+- validación básica de campos requeridos en frontend
+- al enviar, no habrá request real
+- se mostrará mensaje claro y elegante del tipo: “Próximamente disponible. Mientras tanto, escribinos por WhatsApp para una respuesta más rápida.”
+- se conservará CTA inmediato a WhatsApp en la misma página
+
+Esto protege la confianza del usuario: la interfaz no miente y tampoco se rompe.
+
+### Home Content Expansion
+La Home dejará de ser solo un hero. Debe sumar 2 o 3 bloques concretos:
+- servicios destacados
+- propuesta de valor / por qué elegir MNQ
+- cierre comercial con CTA principal
+
+No hace falta construir una mega landing todavía. Hace falta que la Home parezca un negocio real, no una maqueta.
+
+### Contact Page Structure
+La página de contacto debe mostrar una jerarquía clara:
+1. WhatsApp como acción principal
+2. datos/contexto de respuesta
+3. formulario secundario visible
+4. feedback elegante de “próximamente” al enviar
+
+## UX and Accessibility Design
+Se incorporarán mejoras base, sin entrar en una auditoría exhaustiva:
+- skip link hacia contenido principal
+- estados visibles de `:focus-visible`
+- revisión de jerarquía de headings en Home y Contacto
+- copy de CTA más específico cuando corresponda
+
+## Metadata / SEO
+Se añadirá metadata mínima útil en el layout:
+- descripción
+- canonical básica si aplica
+- Open Graph esencial
+- `theme-color`
+
+## Future Compatibility
+Esta fase no implementa CMS ni chatbot, pero deja una dirección correcta para fase 2:
+- configuración centralizable
+- componentes menos acoplados a strings hardcodeados
+- formulario visible, listo para luego conectarse a Strapi o a otro flujo
+
+## Risks
+- Si el número real de WhatsApp todavía no está definido, habrá que esperar ese dato antes de ejecutar el reemplazo final.
+- El formulario visible pero no conectado exige un mensaje muy bien escrito para no generar frustración.
+- Si la Home crece demasiado ahora, se puede perder foco y abrir trabajo de copy innecesario antes del CMS.
+
+## Success Criteria
+- No queda ningún placeholder de WhatsApp en producción.
+- El formulario visible no rompe ni promete envío real.
+- Home y Contacto transmiten más confianza comercial.
+- Mejoran accesibilidad base y metadata del layout.
+- El alcance queda contenido y no invade la fase 2.