# SPEC

## Objetivo del producto

RingoChecker ayuda a una persona a revisar una web pública desde un único punto y a detectar señales básicas de:

- transparencia
- seguridad visible
- fiabilidad operativa básica
- claridad de contacto
- calidad mínima de presentación

El producto no pretende sustituir una investigación humana, una auditoría legal o un análisis forense.

## Tipos de sitio cubiertos

- tiendas online
- SaaS
- landings
- blogs
- webs corporativas
- webs sospechosas o poco transparentes

## Prioridad técnica

Orden no negociable:

1. seguridad
2. privacidad
3. robustez
4. eficiencia
5. funcionalidad y claridad

## Filosofía del scoring

- Base neutral en lugar de asumir confianza alta por defecto.
- Reglas con pesos firmes pero conservadores.
- Cada contribución se puede rastrear en código.
- Sin lenguaje de "IA opaca".
- Sin simular fuentes de terceros.
- Las comprobaciones no disponibles se muestran como límites del modo estático, no como evidencia falsa.

## Estados de salida

El informe usa tres estados obligatorios:

- `Good signs`
- `Caution`
- `High risk`

Cada uno se acompaña de:

- resumen humano corto
- descargo de responsabilidad
- listado de positivos
- listado de banderas rojas
- recomendación práctica final

## Señales del MVP

### Transparencia y confianza

- aviso legal
- política de privacidad
- términos y condiciones
- política de envío
- política de devolución o reembolso
- página de contacto
- página sobre la empresa
- email
- teléfono
- dirección física probable
- razón social o nombre mercantil probable
- identificadores tipo VAT/CIF/NIF cuando aparezcan claramente

### Técnicas

- HTTPS
- URL normalizada
- respuesta HTTP si el navegador puede leerla
- redirecciones observables
- separación clara entre checks estáticos y checks futuros server-side

### Calidad visible

- navegación clara
- rutas de soporte/contacto
- políticas visibles
- señales básicas de tienda si aplica
- patrones rotos o de baja confianza solo cuando sean explicables

## Principios UX

- móvil primero
- diseño sobrio y profesional
- jerarquía visual fuerte
- tema claro y oscuro
- español por defecto
- preparado para i18n futura
- mensajes honestos sobre límites, sin alarmismo gratuito
- explicación del porqué de la puntuación

## Arquitectura

Separación requerida:

- UI en `src/js/ui.js`
- orquestación en `src/js/app.js`
- análisis en `src/js/analysis/`
- reglas en `src/js/rules/`
- utilidades en `src/js/utils/`
- configuración en `src/js/config.js`
- adaptador server-side en `_worker.js`
- PWA en raíz

## Limitaciones conocidas del modo estático

- El navegador no puede leer muchas webs por CORS.
- Un sitio con anti-bot o políticas restrictivas puede bloquear la lectura aunque el sitio sea legítimo.
- Una web HTTP no puede ser inspeccionada plenamente desde una app servida por HTTPS.
- No hay comprobación de WHOIS, DNS, listas negras, certificados detallados ni malware feeds.
- No se ejecuta JavaScript remoto de la web analizada.
- El análisis visible se basa en el HTML accesible de la URL solicitada o de la landing final observable.

## Adaptador server-side opcional

- Cuando existe `_worker.js` con la ruta `/api/analyze`, el frontend intenta primero el análisis desde servidor.
- Ese adaptador evita el bloqueo CORS típico del navegador para webs de terceros.
- El adaptador debe bloquear hosts locales, privados o reservados.
- Las respuestas del adaptador no deben persistirse ni cachearse.
- Si el adaptador no existe o falla, la app debe degradar con limpieza al modo cliente.

## Decisiones PWA

- Cachear solo shell y recursos propios.
- Actualización segura basada en Service Worker con activación rápida.
- El contenido remoto analizado no se cachea.
- Si no hay conexión, la app sigue cargando pero deja claro que el análisis en vivo no está disponible.