Documentación
y versiones.

# Arquitectura y requisitos

Fecha: 4 de octubre de 2026.
Estado: arquitectura inicial. El propietario ha elegido Next.js con TypeScript y PostgreSQL, alojamiento gestionado y venta inicial en España. Este documento describe el diseño previsto; no acredita funcionalidades implementadas ni un despliegue realizado.

## 1. Objetivo y alcance inicial

Construir una tienda de jamones y paletas con catálogo, carrito, compra, cobro mediante TPV virtual de Banco Sabadell y gestión privada. Mantener documentación accesible al propietario e historial de cambios visuales y operativos por versión.

Catálogo inicial solicitado:

| Referencia provisional | Producto solicitado | Datos por concretar |
| --- | --- | --- |
| JAM-50 | Jamón de cebo ibérico 50 % | Denominación, precio, peso, existencias y lote |
| JAM-100 | Jamón de cebo ibérico 100 % | Denominación, precio, peso, existencias y lote |
| PAL-100 | Paleta de cebo ibérico 100 % | Denominación, precio, peso, existencias y lote |

No se fijan precios, impuestos, certificaciones ni características comerciales sin información del propietario. El propietario define «fuera de norma» como productos que no reúnen los requisitos para llevar un precinto identificativo de la norma del ibérico. Falta identificar el incumplimiento concreto y la documentación de cada referencia antes de decidir su denominación pública.

Se ha identificado como fuente a consultar el [Real Decreto 4/2014 en el BOE](https://www.boe.es/buscar/act.php?id=BOE-A-2014-318). La consulta desde este entorno ha sido bloqueada por el proxy; se ha guardado un cambio de red para permitir `www.boe.es`, pendiente de activación. No se ha revisado todavía el texto oficial vigente ni se ha redactado contenido comercial definitivo sobre la norma.

## 2. Elección de tecnología

La elección confirmada es una aplicación Next.js con TypeScript y PostgreSQL. Para un catálogo pequeño permite reunir tienda y gestión en un mismo proyecto, con páginas preparadas para buscadores y una base de datos transaccional. Las alternativas consideradas quedan registradas a continuación.

| Alternativa | Qué aporta | Implicación de mantenimiento |
| --- | --- | --- |
| Next.js + TypeScript + PostgreSQL | React para la interfaz, servidor para catálogo y pagos, tipos para detectar errores antes de publicar | Una aplicación y una base de datos; recomendación inicial |
| Nuxt + TypeScript + PostgreSQL | Vue para la interfaz, renderizado y servidor integrado | Una aplicación y una base de datos; equivalente si se prefiere Vue |
| Next.js + Django + PostgreSQL | Tienda React y servidor Python separado, con administración de Django | Dos aplicaciones, dos toolchains y coordinación adicional entre ambas |

En la arquitectura Next.js:

- Tailwind CSS establece estilos y diseño responsive mediante un sistema compartido.
- shadcn/ui aporta componentes React accesibles y personalizables; la accesibilidad se comprobará en la web final.
- Prisma gestiona el acceso tipado a PostgreSQL y las migraciones; no sustituye las validaciones ni las transacciones del negocio.
- Las validaciones de entrada se ejecutan en el servidor, aunque también existan ayudas en los formularios.

Las versiones exactas se fijarán al preparar el entorno: versiones estables compatibles, runtime con soporte y archivo de bloqueo de dependencias. Esta propuesta todavía no elige versiones ni instala paquetes.

## 3. Componentes y límites

```mermaid
flowchart LR
    Cliente[Comprador] --> Tienda[Tienda pública]
    Tienda --> Servidor[Servidor: catálogo, pedidos y pagos]
    Gestor[Propietario o gestor] --> Panel[Panel privado]
    Panel --> Servidor
    Servidor --> BD[(PostgreSQL)]
    Servidor --> Archivos[Imágenes y documentos]
    Servidor --> Correo[Servicio de correo transaccional]
    Tienda --> TPV[TPV virtual Sabadell]
    TPV -->|Notificación autenticada| Servidor
    Git[Repositorio y versiones] --> Documentacion[Documentación de cada publicación]
    Documentacion --> Panel
```

La tienda pública contendrá catálogo, fichas, carrito, compra, información de envío y páginas comerciales. Se propone permitir compra sin cuenta para reducir pasos; queda pendiente de elección.

El panel privado permitirá gestionar productos, precios, existencias, pedidos, envíos y documentación. El servidor comprobará permisos en cada operación y cada documento privado. Los papeles internos no se publicarán como archivos estáticos accesibles por URL.

Roles propuestos:

- Propietario: administración, usuarios y configuración.
- Gestor: operaciones comerciales que se acuerden, sin acceso a claves del TPV.
- Consulta: documentación o pedidos que se autoricen.

El acceso al código en GitHub y el acceso al panel de la tienda son permisos independientes. Sergio usa la cuenta GitHub `sh3rencr`. Se ha intentado enviar una invitación de escritura; GitHub la ha rechazado con `Resource not accessible by integration` (403). Sigue pendiente de una conexión con permiso de administración de colaboradores. La invitación al repositorio no crea por sí sola una cuenta en la web.

## 4. Productos, existencias y pedidos

Entidades previstas: producto, variante comercial, lote, movimiento de existencias, reserva, pedido, línea de pedido, intento de pago, evento bancario, envío, usuario, evento de auditoría y versión publicada.

- Confirmar si se vende por pieza con precio fijo, por intervalo de peso o por peso exacto. Esta decisión afecta catálogo, inventario e importe del cobro.
- Guardar en el pedido una copia de descripción, cantidad, precio, impuestos y envío. Un cambio posterior del catálogo no alterará lo comprado.
- Calcular importes en el servidor usando céntimos enteros o decimales de precisión fija.
- Reservar existencias de forma transaccional durante el pago para evitar vender la misma última unidad a dos compradores.
- Expirar reservas pendientes según una política acordada. Un pago confirmado después de expirar su reserva requiere conciliación; no debe sobrescribir un pedido cancelado ni generar existencias negativas.
- Separar el estado del pago del estado de preparación y envío. Un pedido cobrado puede estar todavía pendiente de preparar; una devolución debe registrarse por separado.
- Registrar lote en las unidades vendidas cuando corresponda al proceso comercial acordado.

## 5. Integración con Banco Sabadell

Confirmar con el contrato del TPV el proveedor técnico, la modalidad habilitada y la documentación de integración. Redsys es una posibilidad que debe verificarse; todavía no se ha validado un terminal, una clave ni un endpoint.

Se propone el pago alojado en la pasarela del banco: el comprador introduce los datos de tarjeta allí y la tienda conserva referencias del pago, sin almacenar números de tarjeta ni códigos de seguridad.

Flujo previsto:

1. El servidor valida carrito, productos, disponibilidad, dirección, impuestos y envío.
2. Crea el pedido pendiente y un intento de pago con importe y moneda inmutables.
3. Genera los parámetros y la firma conforme al protocolo oficial contratado y redirige al comprador a la pasarela.
4. El banco notifica el resultado a una URL HTTPS del servidor. Se verifican firma, identificador de pedido, comercio, terminal, importe, moneda y resultado.
5. Una notificación válida confirma el pago dentro de una transacción y consolida la reserva una sola vez. Las notificaciones repetidas no duplican cobros registrados, existencias ni correos.
6. El regreso del navegador muestra el estado registrado por el servidor. Llegar a una página de éxito no confirma por sí mismo el cobro.
7. Un proceso de conciliación detecta pagos sin resultado final y discrepancias; las devoluciones mantienen su propia referencia y registro.

El protocolo exacto determinará firma, identificadores, respuesta a la notificación y estrategia de reintentos. No se deben inventar estos detalles antes de consultar la documentación del terminal.

La vista previa ya muestra la interfaz de este flujo en `/pedido/` (envío, revisión y pago) con pedidos de prueba guardados solo en el navegador (`lib/pedidos.ts`). Ese guardado no sustituye al servidor: cuando exista, el paso de pago redirigirá a la pasarela y el pedido se creará y validará en el servidor como se describe arriba.

Datos necesarios: TPV contratado, entorno de pruebas, comercio y terminal, modalidades de pago habilitadas, contrato de devoluciones y URLs públicas de notificación y retorno. Las claves se configurarán mediante el gestor seguro del alojamiento y no se introducirán en chat, documentación o repositorio.

Las pruebas y la producción tendrán claves y configuraciones separadas. Se probarán pago aprobado, denegado, cancelado, retorno sin notificación, notificación manipulada o duplicada e importe incorrecto.

## 6. Infraestructura propuesta

| Recurso | Propuesta inicial | Decisión pendiente |
| --- | --- | --- |
| Aplicación | Alojamiento gestionado compatible con el framework | Proveedor, plan y presupuesto |
| Datos | PostgreSQL gestionado en una región de la UE | Región, capacidad y recuperación |
| Archivos | Almacenamiento de objetos, con acceso privado para documentos internos | Proveedor y política de conservación |
| Correo | Servicio transaccional para pedidos y avisos | Proveedor y dominio remitente |
| Dominio y HTTPS | Dominio propio y certificados renovados automáticamente | Dominio y acceso a DNS |
| Observación | Errores, alertas y registros con identificadores de pedido | Proveedor y destinatarios de avisos |
| Entregas | Desarrollo, pruebas y producción con datos y claves separados | Proveedor y flujo de despliegue |

Un VPS es una alternativa si se desea controlar el servidor. En ese caso habrá que gestionar actualizaciones, proxy HTTPS, procesos, base de datos, copias, monitorización y recuperación. Se compararán costes totales cuando exista presupuesto; todavía no se contrata ningún servicio.

La copia de seguridad debe incluir base de datos y archivos, con una restauración ensayada. Falta acordar cuánto tiempo de caída y cuántos datos se pueden tolerar perder. Las publicaciones deberán permitir volver a la versión anterior sin aplicar migraciones destructivas a ciegas.

La región de la aplicación y la base de datos se elegirán juntas. Los servicios externos se documentarán con sus destinos de red, variables y requisitos de autenticación cuando se elijan.

## 7. Comprobaciones antes de vender

- Aplicación construida y ejecutable con las versiones de herramientas fijadas.
- Catálogo y compra comprobados en móvil, teclado y escritorio.
- Pedidos calculados en servidor con precio, impuestos y envío correctos.
- Dos compras simultáneas de la última unidad no producen sobreventa.
- TPV de pruebas validado con los casos indicados y trazabilidad del resultado.
- Panel y documentos privados protegidos incluso al acceder directamente a sus URLs.
- Confirmación de pedido, preparación y aviso de envío comprobados.
- Copia restaurada y recuperación de una publicación comprobada.
- Contenido comercial, denominaciones, condiciones y política de envíos completados para los territorios elegidos.

Estas comprobaciones son objetivos de la futura implementación. Ninguna se presenta como realizada en esta fase documental.

## 8. Requisitos que hay que recoger

Decisiones recibidas en la primera ronda:

1. Framework: Next.js con TypeScript; base de datos PostgreSQL.
2. Alojamiento: servicios gestionados. Proveedor y presupuesto mensual pendientes.
3. Mercado: España. Falta concretar Península, Baleares, Canarias, Ceuta y Melilla para tarifas y condiciones.
4. «Fuera de norma»: ausencia de los requisitos para precinto identificativo. Falta documentación y motivo concreto por producto.
5. El estado del contrato del TPV Sabadell no se ha confirmado.

Siguiente ronda:

| Área | Información requerida | Para qué sirve |
| --- | --- | --- |
| Marca | Nombre, logotipo, dominio y ejemplos visuales | Diseño e identidad de la tienda |
| Catálogo | Denominación documentada, fotografías, precios, pesos, unidades y lotes | Fichas, variantes y existencias |
| Venta | Moneda, impuestos aplicables, venta por pieza o peso, descuentos | Cálculo del pedido |
| Logística | Transportista, destinos, tarifas, plazos y devoluciones | Compra y preparación de pedidos |
| Legal | Titular, NIF, domicilio, correo, teléfono, datos registrales y registro sanitario (`lib/empresa.ts`); revisión profesional de los textos | Aviso legal, privacidad, cookies y condiciones de compra |
| Gestión | Quién gestiona, quién consulta y si Sergio también usará el panel | Roles y autenticación |
| Documentación | Audiencia, documentos internos y contenido del historial visible | Permisos y registro de versiones |
| Operación | Volumen esperado, facturación e integración con software existente | Capacidad y automatizaciones |
| Continuidad | Tiempo de recuperación y pérdida de datos tolerables | Copias y alertas |

## 9. Secuencia de implementación

1. Concretar el proveedor, presupuesto, catálogo y estado del TPV sobre la tecnología y modalidad de alojamiento elegidas.
2. Fijar herramientas, instalar dependencias y guardar instrucciones reutilizables de instalación, arranque y validación para el entorno cloud.
3. Crear catálogo, interfaz inicial y modelo de pedidos con datos de prueba identificados.
4. Implementar administración, documentación privada y auditoría.
5. Integrar TPV de pruebas, reservas, conciliación, envíos y correo.
6. Validar el flujo completo en el entorno de pruebas.
7. Configurar producción y realizar la puesta en marcha acordada con el propietario.

No se crean servidores, cuentas de pago, recursos de pago ni publicaciones en esta fase. El paso actual produce un diseño revisable y recoge los requisitos para implementar.

# Requisitos y decisiones pendientes

## Confirmados por el propietario

- Tienda online para vender jamones descritos como «fuera de norma».
- Tres familias inicialmente indicadas:
  - Jamones Cebo Ibérico 50 %.
  - Jamones Cebo Ibérico 100 %.
  - Paleta Cebo Ibérico 100 %.
- Cobro mediante TPV virtual de Banco Sabadell.
- Acceso a documentación e historial por versiones, diferenciando cambios visuales y operativos.
- Uso de frameworks; selección explicada y consultada con el propietario.
- Base aprobada: Next.js + TypeScript + PostgreSQL.
- Venta inicial solo en España; destinos insulares, Ceuta y Melilla pendientes de concretar.
- TPV virtual de Sabadell aún no contratado.
- El propietario describe como fuera de norma piezas que incumplen requisitos como el peso. Motivo concreto y documentación por familia pendientes.
- Repositorio solicitado: `Web_Jamones_Innure`, en la cuenta de GitHub del propietario.
- Colaborador solicitado: `sergio@innure.es`.

Las denominaciones anteriores son las facilitadas por el propietario, pendientes de verificar con el etiquetado y la situación real de los productos. «Fuera de norma» no permite deducir por sí solo qué menciones comerciales pueden utilizarse.

## Primera ronda de preguntas

### Respuestas recibidas

- Rangos indicados: 7–8 kg y 8–9 kg. Aplicados inicialmente a jamones; falta confirmar pesos de las paletas y aclarar el motivo concreto de descalificación, que no se deduce de estos rangos por sí solos.
- Venta por piezas.
- «Ambos» para destinos: se interpreta como Península y otros destinos españoles, pendientes de concretar tarifas y cobertura.
- El propietario quiere ver la web antes de decidir servidor y dominio.
- Usuario de Sergio: sh3rencr, identidad de GitHub verificada.
- Repositorio privado madh2210/Web_Jamones_Innure ya disponible. Invitación intentada mediante API: GitHub devuelve 403 por permisos insuficientes de la integración.

1. Para cada familia, ¿qué requisito incumple: peso de la canal, peso de la pieza elaborada, curación, certificación o trazabilidad? ¿Qué peso tiene y qué denominación legal aparece en la etiqueta y ficha del proveedor?
2. Resuelto: Next.js + TypeScript + PostgreSQL.
3. España confirmado. ¿Solo Península o también Baleares, Canarias, Ceuta y Melilla?
4. ¿Precio fijo por pieza, por rango de peso o por peso real? ¿Qué variantes y existencias hay?
5. El TPV no está contratado. Al contratarlo, solicitar documentación técnica, modalidad de integración y acceso a pruebas antes de incorporar credenciales reales.
6. ¿Cuál es el usuario de GitHub de Sergio? El correo no produjo resultados en la búsqueda pública de usuarios.

## Siguiente ronda, después de aclarar lo anterior

- Nombre comercial, dominio, identidad visual y fotografías disponibles.
- Datos de la empresa vendedora y fichas técnicas del proveedor, lotes y certificaciones cuando correspondan.
- Tarifas, impuestos, transportista, destinos excluidos y política de devoluciones.
- Quién modifica precios, gestiona pedidos y consulta documentación; acceso que necesita Sergio.
- Compra como invitado y necesidad de cuentas de cliente.
- Facturación e integración con software de gestión, si existe.
- Presupuesto mensual de infraestructura, volumen esperado y fecha objetivo.
- Necesidad de cupones, Bizum u otros medios que admita el contrato del TPV.

Las claves del TPV se incorporarán mediante el mecanismo de secretos del alojamiento, nunca en la documentación, el código o una conversación.

## Estado de GitHub

- Cuenta conectada verificada: `madh2210`.
- Repositorio privado verificado: madh2210/Web_Jamones_Innure.
- Usuario de Sergio verificado: sh3rencr.
- La invitación mediante API devuelve HTTP 403: `Resource not accessible by integration`. No se ha enviado.
- Para invitar se necesita una credencial con permisos suficientes de administración de colaboradores, o realizar la invitación desde la configuración del repositorio.

# Productos fuera de norma: investigación inicial

Fuente primaria consultada: [Real Decreto 4/2014, texto consolidado en el BOE](https://www.boe.es/buscar/act.php?id=BOE-A-2014-318). Esta nota identifica requisitos para el catálogo; no certifica la situación de los productos del proveedor.

## El color del precinto no depende solo de la raza

El artículo 9.3 establece:

| Precinto | Denominación |
| --- | --- |
| Negro | De bellota 100 % ibérico |
| Rojo | De bellota ibérico |
| Verde | De cebo de campo ibérico |
| Blanco | De cebo ibérico |

Un producto de cebo 100 % ibérico no corresponde al precinto negro por tener un 100 % de raza ibérica. El régimen de alimentación y manejo también determina la denominación. «Pata negra» queda reservado a de bellota 100 % ibérico conforme al artículo 4.5.

## Peso de la pieza elaborada

El artículo 12 exige los siguientes mínimos de la pieza elaborada, una vez etiquetada, a la salida de la instalación de la industria final:

| Tipo | Peso mínimo |
| --- | --- |
| Jamón 100 % ibérico | 5,75 kg |
| Jamón ibérico | 7 kg |
| Paleta 100 % ibérica | 3,7 kg |
| Paleta ibérica | 4 kg |

La norma también regula pesos de canal y tiempos de elaboración. No deben confundirse el peso de la canal en el matadero y el de la pieza curada a la salida de la industria final, ni deducirse un incumplimiento únicamente del peso que tenga posteriormente en la tienda.

## Denominaciones y publicidad

El artículo 1 vincula las denominaciones reguladas al cumplimiento de las características de calidad. El artículo 4.2 prohíbe el uso incompleto o aislado de los términos de la denominación, salvo el tipo de producto, también para productos fuera de la norma. El artículo 9.7 contempla pérdida del derecho a las denominaciones en supuestos de descalificación de canal o fallos de identificación y trazabilidad.

Por ello no se aprueban automáticamente los nombres «Jamón de cebo ibérico 50 %», «Jamón de cebo 100 % ibérico» o «Paleta de cebo 100 % ibérica» para piezas descalificadas. Añadir «fuera de norma» no acredita por sí mismo que sean denominaciones admisibles. La situación y la denominación comercial deben revisarse con el proveedor y su responsable de cumplimiento alimentario antes de publicarlas.

## Pregunta corregida al proveedor

Para cada una de las tres familias, indicar:

1. Motivo concreto por el que queda fuera de norma: peso de canal, peso de pieza final, curación, certificación, trazabilidad u otro requisito.
2. Rango de peso y momento de medición.
3. Denominación legal exacta de venta que figura en la etiqueta y ficha técnica.
4. Información y documentos de lote, origen, composición y certificación que correspondan.

Estas respuestas permitirán diseñar las fichas comerciales y el inventario sin presentar una certificación que el producto no tiene.

# Historial de cambios

## Sin publicar

### Herramienta interna de gestión de pedidos (rama `preproduccion`)

- Panel para el equipo en una ruta interna sin enlace desde la tienda (la ruta y la puesta en marcha están en `docs/DESPLIEGUE.md`, que no se publica): bandejas por preparar, preparando, enviados, entregados, incidencias y sin pagar; búsqueda por número, nombre, correo, teléfono o seguimiento; ficha con dirección, piezas, pagos, estado de envío, transportista, número de seguimiento, nota interna, incidencias e historial de cambios con autor; hoja de envío imprimible.
- Acceso con usuario y contraseña propios del equipo, guardados en **otra base de datos** (`GESTION_DATABASE_URL`), separada de las cuentas de clientes. Sesión revocable en cookie httpOnly, bloqueo tras intentos fallidos, contraseñas temporales con cambio obligatorio y roles operador/responsable.
- Migraciones: `0002` en la base de datos de la tienda (seguimiento e historial de pedidos) y `migraciones-gestion/0000` en la del equipo. Scripts nuevos: `db:local:gestion`, `db:gestion:generar`, `db:gestion:migrar` y `gestion:operador`.
- Comprobación: `typecheck` y `build` sin errores; prueba manual en local (PGlite) de entrada, contraseña temporal, roles, pedidos, incidencias, equipo, freno de intentos y móvil a 375 px. Sin desplegar ni migrar en Supabase.

### Cuentas reales, pedidos de cliente y administración (rama `preproduccion`)

- Login real con Auth.js (credenciales + JWT en cookie httpOnly). Usuarios en PostgreSQL (`usuarios`), contraseñas con scrypt, nunca en claro. Migración `0001` aplicada en Supabase.
- Registro, entrada, cierre de sesión y recuperación de contraseña por correo (`/olvido/`, `/restablecer/`; enlace de un solo uso, caduca en 1 h). Correo con Resend (`RESEND_API_KEY`); sin clave, solo en local se escribe en la consola.
- «Mi cuenta» lee y guarda la dirección y los pedidos reales en la base de datos (sustituye a `localStorage`). Los pedidos hechos con sesión quedan ligados al usuario.
- Panel `/admin/` (rol admin, dado por `ADMIN_EMAILS`): pedidos y estado de envío, precios y existencias, portes por zona.
- Variables nuevas: `AUTH_SECRET`, `ADMIN_EMAILS`, `RESEND_API_KEY`, `CORREO_REMITENTE` (ver `.env.example`).

### Continuidad entre agentes

- Memoria común de Codex y Claude, entrada `CLAUDE.md` y protocolo de relevo con puntos de guardado, commit y push.
- Registrados Supabase y Vercel como proveedores elegidos y verificados. Diferenciados la v0.1.0 desplegada (`main`) y las versiones v0.2.0 y v0.3.0 de `claude/rediseno-web`, ya subidas.
- Comprobación: coherencia y enlaces locales de documentación; sin cambios en la aplicación.
- Comprobaciones de navegador en `pruebas/` (`npm run comprobar`), sin rutas de un entorno concreto, para que cualquier agente pueda repetirlas.

### v0.3.0: servidor, base de datos y pago de pruebas (rama `claude/v0.3.0-servidor-pedidos`, sin desplegar)

- La web deja de exportarse como estática (`output: 'export'` eliminado): necesita Node para la API de pedidos y el webhook. Alojamiento previsto: Vercel.
- Base de datos PostgreSQL con Drizzle ORM (`lib/servidor/esquema.ts`, migración `migraciones/0000_late_maelstrom.sql`): productos, variantes con precio y existencias, tarifas de envío, pedidos, líneas, pagos y eventos de Stripe. Supabase se usa solo como PostgreSQL.
- `/pedido/` crea el pedido en el servidor (`/api/pedidos/`): valida cesta y dirección, recalcula precios y portes desde la base de datos, aparta las existencias 31 minutos y abre Stripe Checkout de pruebas. `/pedido/resultado/` muestra el estado real y `/api/pedidos/cancelar/` devuelve las piezas si el cliente cancela.
- Webhook de Stripe `/api/stripe/webhook/`: firma verificada, idempotente por evento, con conciliación de reservas vencidas. Solo se vende a la Península; otros destinos se rechazan hasta fijar portes.
- Scripts: `db:local` (PGlite), `db:generar`, `db:migrar`, `db:sembrar` y `prueba:pagos`. Variables en `.env.example`; guía en `docs/DESPLIEGUE.md`.
- Dependencias nuevas: `drizzle-orm`, `pg`, `stripe`, `server-only`; de desarrollo, `drizzle-kit`, `tsx` y PGlite.
- Sin cambiar: sesión, cuenta, dirección y «pedidos de prueba» de `/cuenta` siguen en `localStorage`. Acceso real, panel y TPV de Sabadell pendientes.
- Comprobación: `npm run typecheck` y `npm run build` sin errores. No se han repetido las pruebas de navegador, ni se ha aplicado la migración en Supabase, ni configurado Vercel o el webhook real.

### Cambios visuales

### v0.3.0 · Plato con mano, pedido de prueba y páginas legales

Código en `claude/rediseno-web`: `89e84ba` (plato) y `4e0b828` (pedido, cuenta, ayuda y legales).

- «El plato», en la historia «Del jamón al plato», con imágenes realistas generadas con IA (rotuladas como tales): una mano coloca las lonchas una a una en un plato que gira y, al cerrar la corona, se abren en el centro las iniciales JB hechas con lonchas y su grasa. Sustituye al plato dibujado de la v0.2.0.
- Compra de demostración completa: en la cesta, «Tramitar pedido» abre `/pedido/` con tres pasos (envío, revisión y pago). Valida los datos, deduce la provincia por el código postal, avisa de los destinos por concretar y explica el pago en la pasarela del banco sin pedir la tarjeta. Termina en un pedido de prueba numerado que no se cobra ni se envía.
- «Mi cuenta» funcional: lista los pedidos de prueba y permite guardar, cambiar y borrar la dirección de envío, que después rellena el pedido. Si se entra desde el pedido, se vuelve a él.
- Páginas de ayuda y legales: envíos y devoluciones, contacto (el formulario valida y confirma, pero todavía no envía), aviso legal, privacidad, cookies y condiciones de compra. Enlazadas desde el pie (columna «Ayuda» y fila legal) y la de privacidad, también desde el alta y el pedido.
- Los pedidos de prueba y la dirección se guardan solo en el navegador (`jb-demo-pedidos` y `jb-demo-direcciones`). La política de cookies enumera todo lo que guarda la web; no hay cookies ni servicios de terceros.
- Datos del titular en `lib/empresa.ts`, todos pendientes: las páginas legales los muestran como «pendiente» hasta que el propietario los aporte. Los textos legales son borradores pendientes de revisión profesional.
- Imágenes de «El plato» en `public/images/historia/` (WebP, 0,4 MB en total con las versiones de 720 px para móvil): plato final, plato vacío alineado con él y la misma mano con y sin loncha. Se cargan al acercarse a la sección.
- Comprobado: `npm run typecheck` y `npm run build` sin errores (16 páginas). Prueba en Chromium (88 comprobaciones, escritorio, 360 px y 390 px, sin errores de consola): cesta, validación, registro, entrada, persistencia, cierre de sesión, redirección, menú móvil, sin desbordes horizontales, anclas con scroll suave, indicador de peso, acordeón, bloqueo del scroll con ventana abierta, movimiento reducido, página sin JavaScript, enlace para saltar al contenido, fichas de producto, cesta compartida entre páginas, barra de compra, comparador, 404, vídeo de portada (con un clip de prueba que no se ha subido) e historia «Del jamón al plato» (la mano aparece, el plato termina completo con las iniciales, las siete capas cargan, imagen de 720 px en móvil, sin scroll lateral, movimiento reducido sin mano y sin JavaScript), rastreo de todos los enlaces y anclas sin 404, compra completa como invitado y con sesión, «Mi cuenta» (pedidos y dirección, sin perder el foco), vuelta al pedido tras entrar, contacto, páginas legales con los datos pendientes marcados, tabla de cookies frente a lo que guarda la web, cada enlace del pie pulsable (el nombre gigante ya no tapa los legales), móvil a 360 px y legales sin JavaScript.

### v0.2.0 · Cambios visuales

- Rediseño completo de la vista previa (v0.2.0): estilo moderno, cabecera fija, botones en píldora, adaptable desde 360 px y con foco visible en teclado.
- Banner provisional «Próximamente en jamonesbaratos.es». El nombre de marca vive en `lib/brand.ts` y es provisional hasta tener el briefing.
- Secciones nuevas: «Cómo comprar» (3 pasos) y preguntas frecuentes.
- Pantallas nuevas: `/acceso` (entrar y crear cuenta) y `/cuenta`.
- Diseño futurista tomando como referencia el movimiento y la composición de `franpradas.com` (detalle en `docs/DISENO.md`): portada a pantalla completa con degradado vino, menú en píldora de cristal flotante, banner provisional en marquesina, rejilla de tarjetas con indicador de peso interactivo, marquesina de texto, burbujas flotantes en «Fuera de norma» con los cuatro precintos del RD 4/2014, tarjeta de envíos, preguntas en acordeón y pie con el nombre gigante.
- Movimiento: scroll suave, títulos palabra a palabra, apariciones al hacer scroll, contadores, parallax en la portada y foco de luz que sigue al ratón. Desactivado con «reducir movimiento»; sin JavaScript todo el contenido se ve.
- Imagen en WebP: de 2,3 MB a 153 KB (y 39 KB la versión pequeña).
- Fichas de producto al estilo de apple.com: `/producto/jam-50/`, `/producto/jam-100/` y `/producto/pal-100/`, con datos clave, indicador de peso, comparador de las tres piezas y barra fija de compra. En el catálogo, cada tarjeta tiene «Elegir pieza» y «Ver detalles».
- Texto hueco que se rellena con el scroll y franja final de llamada a la acción, tomando como referencia forjagym.com.
- Portada con movimiento: deriva lenta y reflejo de luz sobre la foto, y preparada para un vídeo en bucle (por ejemplo, un cuchillo cortando el jamón) cuando haya clip.
- Página 404 propia en español.
- «Del jamón al plato»: sección fija tras la portada que recorre la pieza, el corte, la loncha y el plato al hacer scroll; las lonchas llegaban a un plato dibujado con rosa de tocino (sustituido en la v0.3.0).

### v0.2.0 · Cambios operativos

- Añadido `AGENTS.md` con las instrucciones de trabajo del proyecto y `docs/MEMORIA.md` como resumen de partida.
- Borrado el borrador antiguo `docs/arquitectura.md`; el documento vigente es `docs/ARQUITECTURA.md`. El README y la página `/documentacion` apuntan ahora a él.
- Dominio elegido para la tienda: `jamonesbaratos.es`. Todavía no configurado.
- El acceso de usuarios es de demostración (`lib/auth.tsx`): la sesión vive solo en el navegador y no se guarda ni comprueba ninguna contraseña. Se sustituirá por Auth.js + PostgreSQL cuando haya servidor.
- La cesta de prueba es la misma en todas las páginas y se guarda en este navegador, para que no se pierda al cambiar de página o recargar.
- Dependencias nuevas: `lenis` (scroll suave) y las tipografías de Fontsource `@fontsource-variable/inter`, `@fontsource/instrument-serif` y `@fontsource-variable/jetbrains-mono`, alojadas en la propia web.

## 0.1.0 — 4 de octubre de 2026

Primera vista privada de revisión. La publicación se confirma en el resultado de Sites, no por esta entrada.

### Cambios visuales

- Identidad inicial Innure, catálogo de tres referencias y diseño responsive.
- Ambientación fotográfica generada, marcada como ilustrativa; faltan fotos reales.
- Selectores y diálogos accesibles para peso, cantidad y cesta.
- Página de documentación y versiones.

### Cambios operativos

- Demostración de selección por pieza para jamones de 7–8 kg y 8–9 kg.
- Cesta en memoria con cantidades, eliminación de líneas y estado vacío.
- Paleta pendiente de pesos; precios y portes sin confirmar.
- Sin pagos, pedidos, datos de clientes, reservas ni PostgreSQL conectado.
- Sitio de revisión privado; autenticación propia del panel de producción pendiente.

## Borrador de arquitectura — sin publicar

### Documentación

- Requisitos iniciales del catálogo y del TPV de Sabadell.
- Propuesta de tecnologías, infraestructura y control de versiones.
- Preguntas pendientes de validación con el propietario.
- Base aprobada: Next.js + TypeScript + PostgreSQL; mercado inicial España y TPV pendiente de contratación.
- Consulta del RD 4/2014 en el BOE sobre precintos, pesos mínimos y denominaciones de venta.

### Cambios visuales

- Sin cambios: la tienda todavía no está implementada.

### Cambios operativos

- Sin cambios: no hay pedidos, cobros ni servicios desplegados.

# Operación de la vista previa v0.1.0

Fecha: 4 de octubre de 2026.

## Implementado

Aplicación Next.js, React y TypeScript con Tailwind CSS y primitivas accesibles Radix. Catálogo, selector de pesos, cesta de demostración y consulta de documentos.

Esta versión genera una exportación estática para revisar el diseño en un sitio privado sin contratar un servidor ni dominio. No representa todavía el servidor de comercio electrónico de producción.

La cesta vive en memoria durante la visita: al recargar se vacía. No hay llamadas a una base de datos, captura de datos personales, pedidos, reservas de stock ni cobros. Los precios y portes aparecen pendientes de confirmar. La paleta no admite selección hasta definir sus pesos.

La imagen de jamón es generada y se identifica como ilustrativa. No representa una fotografía verificada del producto. Debe sustituirse por fotografías del proveedor, incluida una imagen específica de paleta.

Los documentos se incorporan en el momento de construir la vista previa. Cualquier cambio exige reconstruir y publicar. El sitio completo se publica privado: no equivale a implementar autenticación del futuro panel interno.

## Instalación y comprobaciones

Requisito: Node.js 20.9 o superior compatible con la versión fijada en package-lock.json.

- Instalar: npm ci.
- Desarrollo: npm run dev.
- Comprobar tipos: npm run typecheck.
- Construir: npm run build.
- Resultado: out/ con HTML, JavaScript, CSS e imágenes.

No guardar claves en el repositorio. La configuración de Sites está en .openai/hosting.json. El resultado de compilación no se versiona.

## Próxima fase de servidor

Al habilitar pedidos, retirar output: export de Next.js y configurar un servidor compatible, PostgreSQL gestionado, validación de precios e inventario en el servidor, autenticación y permisos del panel y un endpoint verificado de notificaciones del TPV.

No simular pagos aprobados con el retorno del navegador. Probar la integración con credenciales de pruebas facilitadas por Sabadell antes de pasar a producción. Los secretos del banco permanecerán exclusivamente en el servidor.

## Versiones y recuperación

Cada publicación conserva el código y documentación en Git y en una versión de Sites. Para recuperar esta vista estática puede reconstruirse su commit o volver a desplegar una versión guardada. La futura base de datos necesita un procedimiento de recuperación separado.