ChefManager - Hardening de producción
======================================

Cambios aplicados:
- app.env=production
- app.demo_mode=false
- app.force_https=true
- La carga sqlite-demo.sql queda bloqueada cuando app.env=production.
- Cuentas demo heredadas se desactivan automáticamente en producción y se revocan sus sesiones.
- Se eliminaron contraseñas y tarjetas demo de public/assets/app.js.
- Se eliminó del seed la creación/restauración del Super Admin con contraseña pública conocida.
- El Super Admin inicial/comprometido usa storage/admin-reset-once.json de un solo uso; el ZIP no lo trae pre-generado. Créalo por CLI con cli/create-admin-recovery.php.
  El archivo contiene solo un hash de la contraseña temporal (nunca la contraseña en texto plano),
  está protegido por .htaccess y se elimina automáticamente tras aplicarse.
- El reinicio solo pisa la contraseña si la cuenta no existe o conserva uno de los hashes inseguros publicados.
- El primer ingreso con contraseña temporal obliga a crear una contraseña privada.
- Se reforzaron las sesiones con session.use_strict_mode, cookies-only y HttpOnly.
- Se mantienen CSRF, password_hash/password_verify, tokens de recuperación,
  separación plataforma/tenant y permisos por rol.

IMPORTANTE:
- Esta compilación está preparada para un servidor con HTTPS válido.
- En XAMPP/localhost sin HTTPS, force_https=true redirigirá a HTTPS.


ChefManager 3.3.3 · DEMO COMERCIAL SEGURO
- app.demo_mode continúa false en producción.
- app.public_demo_access=true habilita únicamente el tenant comercial aislado.
- El login normal rechaza las cuentas demo y no existe contraseña pública distribuida.
- auth/demo-login acepta solamente owner/cashier/waiter/kitchen de una lista cerrada.
- Las sesiones demo duran como máximo 30 minutos.
- Cambios sensibles de usuarios, roles, uploads, integraciones, webhooks y backups están bloqueados para el demo.
- Los datos demo se restauran automáticamente cuando vence el intervalo configurado y no hay sesiones demo activas.

ChefManager 3.5.0 · Private AI
- El LLM no recibe credenciales SQLite/PostgreSQL del ERP ni SQL libre.
- La capa PHP ejecuta únicamente herramientas allow-list con restaurant_id/branch_id del usuario autenticado.
- Las acciones de escritura generadas por IA se guardan como propuestas y requieren permiso + confirmación humana antes de ejecutarse.
- AI Gateway usa secreto compartido X-ChefManager-AI-Key y por defecto solo permite gateway localhost desde PHP.
- docker-compose.ai.yml publica el Gateway únicamente en 127.0.0.1:8090; Ollama y PostgreSQL/pgvector no publican puertos al host.
- La tabla vectorial aplica Row Level Security + FORCE RLS por app.restaurant_id.
- RAG se usa para conocimiento documental; ventas, stock, costos, RRHH y operación se consultan mediante SQL controlado.
- ChefManager Vision solo extrae/previsualiza: no modifica Compras, Inventario ni Cuentas por pagar sin revisión humana.
- Si AI Gateway/modelos no están disponibles, el ERP sigue funcionando y Private AI degrada al motor analítico interno.
- No se incluyen pesos de modelos ni secretos en el ZIP. ai-gateway/.env se genera localmente y debe conservarse con permisos restringidos.

- ai-gateway/ y cli/ se bloquean desde .htaccess; Ollama/PostgreSQL no deben exponerse a Internet.
- PostgreSQL/PGVector separa superusuario de inicialización y rol de aplicación chefmanager_ai_app (NOSUPERUSER/NOBYPASSRLS); AI Gateway usa únicamente el rol restringido.
