# 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.