Desktop con daemon

Cuando usar este modo

Es el modo correcto para:

• cajas o escritorios que deben seguir operando aunque la interfaz principal se cierre
• integraciones con ERP o POS que requieren bandeja local por REST o por archivos
• despliegues donde se necesita autoarranque del servicio en el equipo

Responsabilidades recomendadas

Aplicacion de escritorio

La aplicacion visible al usuario deberia encargarse de:

• configuracion del punto de emision
• alta y validacion de certificados
• diagnostico y soporte
• visualizacion de pendientes, errores y logs
• acciones manuales como sincronizar, reintentar o reimprimir

Daemon local

El daemon deberia encargarse de:

• sincronizacion periodica
• reserva de rangos segun objetivos configurados
• procesamiento de bandeja de archivos
• exposicion REST local cuando aplique
• flush de outbox y reintentos
• impresion automatica cuando el flujo lo requiera

Topologia recomendada

1. La interfaz escribe settings.json y .env.local.
2. El daemon arranca con el base_dir de la instalacion.
3. El daemon carga el perfil activo y resuelve el runtime local.
4. El daemon mantiene state.json, pid y logs operativos.
5. El host consulta GET /state o lee estado via comando Tauri para la UI.

Canales de entrada

REST local

Recomendado cuando el sistema emisor y el daemon corren en el mismo equipo o en la misma red local y se necesita respuesta inmediata.

Usos tipicos:

• POST /sign-cfe
• POST /enqueue
• GET /health
• GET /state

Bandeja de archivos

Recomendada cuando el sistema tercero solo puede escribir archivos o necesita desacople fuerte.

Usos tipicos:

• ingreso por JSON
• ingreso por texto plano estilo cola legacy
• procesamiento asincrono con carpetas entrada, temporal, salida y error

Recomendaciones de operacion

• activar solo los canales realmente usados por el perfil
• dejar REST y archivos configurables por punto de emision
• registrar el daemon como servicio del sistema o autoarranque del usuario
• separar claramente la carpeta de runtime de la carpeta de datos
• monitorear state.json para detectar caidas y latidos vencidos

Estado minimo que la UI deberia mostrar

• daemon activo o detenido
• ultimo heartbeat
• ultimo sync
• ultimo flush
• pendientes en outbox
• archivos procesados y con error
• ultimo error tecnico
• vigencia de certificado

Riesgos frecuentes

• tener multiples instancias del daemon sobre la misma base SQLite
• dejar activo REST si no existe control sobre quien puede consumir loopback o red local
• usar impresoras compartidas sin validar disponibilidad real del spooler
• reconstruir o actualizar el daemon sin reiniciarlo luego

Criterio de cierre

Un despliegue desktop con daemon esta bien cerrado cuando:

• el servicio arranca solo
• puede sincronizar y reservar sin UI abierta
• procesa pendientes si el sistema central estuvo caido
• expone solo los canales habilitados
• la UI solo consulta y administra, no depende del proceso interactivo para operar