# Instrucciones para continuar mitienda

## Antes de trabajar

1. Leer `CONTEXTO-DESARROLLO.md`: objetivo, decisiones, estado, pendientes y punto de continuación.
2. Leer `README.md`: operación, configuración e integración de pagos.
3. Si cambió la computadora, leer `CONTINUAR-EN-OTRA-PC.md`.
4. Inspeccionar el código y los cambios existentes antes de editar. La documentación es una instantánea, no prueba de que el entorno actual esté configurado o de que las pruebas sigan pasando.

## Forma de trabajar

- Responder en español claro. El usuario no tiene por qué conocer programación: explicar qué cambia y para qué sirve.
- Continuar la aplicación existente. No reemplazarla por una maqueta, otro framework ni un proyecto nuevo sin una petición que lo justifique.
- La petición actual del usuario dirige el trabajo; el listado de pendientes aporta contexto, no autoriza por sí solo todas las integraciones ni un despliegue.
- No asumir que Mercado Pago, SMTP, dominio o hosting están conectados. Diferenciar código implementado, pruebas simuladas y verificación con servicios reales.
- Mantener modo local demo para desarrollo. Los datos de ejemplo no son productos ni cobros reales.
- No sobrescribir `.env`, regenerar `APP_KEY` de una instalación trasladada, recrear la base ni eliminar datos para resolver problemas de configuración. Inspeccionar y conservar primero.
- No incluir contraseñas, tokens, `.env`, datos de clientes o volcados SQL en documentación, respuestas o control de versiones. Referenciar el archivo privado cuando sea necesario.
- Instalar desde `composer.lock` y `pnpm-lock.yaml`. No actualizar masivamente dependencias como parte de un traslado.

## Reglas del negocio que se deben conservar

- Importes en centavos; precios, descuentos y envío se calculan en servidor.
- Stock por variante: unidades físicas y reservadas separadas; usar los servicios y transacciones existentes para no permitir sobreventa.
- Crear un pedido reserva; confirmar pago vende; cancelar/vencer libera una sola vez. Una notificación repetida no puede vender dos veces.
- La página de retorno del pago nunca acredita una venta. Verificar firma del webhook y consultar el pago al proveedor; validar vendedor, ambiente, referencia, moneda y monto.
- Un pago tardío sin stock requiere revisión. Un reembolso no repone automáticamente mercadería que todavía no volvió físicamente.
- Respetar roles y usuario activo, CSRF, límites de solicitudes y acceso privado al pedido. No quitar estos controles para lograr que una prueba pase.
- Los ingresos de reportes excluyen pagos demo.

## Verificar y entregar

- Para cambios de negocio/servidor: ejecutar pruebas relevantes; la suite completa es `php artisan test --no-ansi`. Verificar previamente que la configuración de pruebas usa SQLite `:memory:` y no la base del negocio.
- Para cambios visuales: `node node_modules/vite/bin/vite.js build` y revisar las pantallas afectadas en navegador, incluyendo móvil cuando corresponda.
- Documentación solamente: revisar coherencia, rutas y contenido; no requiere volver a ejecutar toda la suite.
- No confundir pruebas HTTP simuladas con pagos sandbox reales. Explicar los límites de la verificación.
- Al terminar una funcionalidad o cambiar una decisión, actualizar `CONTEXTO-DESARROLLO.md` con qué se hizo, cómo se verificó, qué queda y el próximo paso. No marcar como completado algo que solo está propuesto.
- Actualizar `README.md` cuando cambien instalación u operación. Mantener este archivo breve y estable; los detalles y el registro van en el contexto de desarrollo.