Hub

Pendientes abiertos

289 pendientes en 33 proyectos · agrupados por proyecto, dentro de cada uno en el orden recomendado del propio projects/<slug>.md.

🤖 Complejidad: Todos (289) Alto (3) Medio (1) Ligero (0)
electro-ia
electrosystems · active · high 15 pendientes

🎯 Top de ataque (15)

  • #018 📅 2026-06-05 Smoke test extendido 1 semana con Sergio en uso real (en curso).
  • #019 📅 2026-06-05 Documentar costos reales vs estimación (cuando se use el API).
  • #018 📅 2026-06-02 Sergio + jefe: smoke test E2E real — mandar audio (validado por Sergio), mandar PDF, hacer preguntas sobre su contenido. En curso.
  • #017 📅 2026-06-08 Agregar 2-3 usuarios más: Gustavo Chavira (gustavo_chavira_mx, admin) ya vinculado 2026-05-15 tarde. Faltan ingenieros (sin nombres decididos).
  • #013 📅 2026-06-22 (causa secundaria del incidente jefe, no urgente con Antigravity API ya online) Empujar al modelo local a usar APIs JSON para datos estructurados (clima, finance). Antigravity lo hace bien solo. Para el local: (a) tool dedicada web_search(query) con Brave Search API (2k búsquedas/mes gratis, key registrable en brave.com/search/api/), (b) hint en system prompt, (c) dejar al modelo iterar (ya tiene la regla nueva).
  • #335 📅 2026-06-10 (en pausa — Fase 2.10) Bug de resolución anafórica ("este archivo" → file_id más reciente) + tool send_email. Archivos deployados en disco; pendiente restart + credenciales SMTP + smoke + commit. Detalle en sección 🔄 RETOMAR arriba y bitácora 2026-05-19 (noche — Fase 2.10).
  • #336 📅 2026-06-15 Streaming en WhatsApp (chunking).
  • #337 📅 2026-06-03 Validación E2E vía Telegram — Sergio puede preguntarle al bot "cuántas llamadas hubo hoy en oasa-plutarco", "última llamada", "top extensiones por duración", etc.
  • #338 📅 2026-06-12 (opcional, no urgente) Replicar el patrón a los 5 Sangoma 7 restantes en lote: minadolores2, miscelec-chih/queretaro/leon/jrz, novamex-jrz. ~5 min por host con el flujo ya probado (ssh validation → alias → extract creds → yaml block → restart).
  • #339 📅 2026-06-03 Validación E2E vía Telegram — Sergio puede preguntarle al bot "qué hosts corren CentOS 6 EOL", "cuáles tienen llave rotada", "qué hay en 192.168.20.x", "dame detalle de oasa-plutarco". Pendiente cuando Sergio quiera probarlo.
  • #135 📅 2026-06-25 Sumar más DBs al allowlist. Cerrado parcialmente 2026-05-22 (Fases 2.14 + 2.15): cluster FreePBX Sangoma 7 completo (7 PBXs / 15 DB endpoints). Scope aclarado por Sergio: solo infra Electrosystems — clientes freelance (holbox/deportescampeon/grecocell/jmeza) y proyectos personales NO entran al bot. Quedan en scope ES: (a) Postgres lado ES (electroia local + netbox + uisp en datacenter, requiere portar db_runner a Postgres ~1-2 h), (b) 18 PBX no-Sangoma en sitios cliente ES (extraer creds en backups-infra primero), (c) otrs y clientes.electrosystemsnet.com (ambos CentOS 6 EOL con MySQL).
  • #020 📅 2026-06-28 Resto del equipo (15 usuarios).
  • #020 📅 2026-06-30 Allowlist de SSH a hosts de clientes (uno por uno, decisión por decisión).
  • #020 📅 2026-06-30 Editor de prompts desde dashboard (admin).
  • #020 📅 2026-06-30 Reportes de uso comparativo (Claude vs local) para el jefe.
es-antenas-new
electrosystems · active · high 10 pendientes

🎯 Top de ataque (10)

  • #262 📅 2026-06-02 (sigue 2026-05-11) Confirmar con Sergio el resultado de su validación manual de correos. Sergio revisa el comportamiento en su Gmail durante el fin de semana 2026-05-09/10 y comparte si requiere ajuste.
  • #011 📅 2026-06-25 (opcional, follow-up) Considerar el mismo filtro "excluir notificados muy recientemente" en procesarFlapping's expansión de RECORDATORIOS: hoy la query solo filtra whereNotNull('flapping_notificado_at'), así que en un tick donde simultáneamente cae un nuevo flapping (block "detectado") y otro vencía su recordatorio en el mismo sitio, podría salirse el correo "detectado" + "recordatorio" mencionando al recién detectado. Riesgo bajo (requiere 24h-vencido + nuevo en mismo tick). NOTA: con el debounce de detectados (commit 017e1b9) la probabilidad bajó aún más porque el detectado ahora se retrasa 5 min.
  • #012 📅 2026-06-10 Observar próximos eventos de flapping + recordatorios en vivo para confirmar consolidación en ambos caminos tras debounce + arrastre por sitio.
  • #007 📅 2026-06-05 (Fase 3a) Scaffold de tests para monitoreo-collector. El repo Go NO tiene tests hoy — antes de meter el resolver, montar harness: testify + mock de gosnmp (sea gosnmp/gosnmp.MockSNMP o servidor SNMP en docker para integración) + 4-5 tests del resolver de {IF} (cache hit/miss, fallback ifDescr→ifName, interfaz no encontrada, invalidación on noSuchInstance). ~1-2 hrs sesión propia. Sin tocar lógica de producción todavía. Salida: harness pasando + tests muriendo de manera predecible que validen futuras decisiones del resolver.
  • #008 📅 2026-06-12 (Fase 3b) Implementación SNMP placeholder end-to-end. Sub-tareas:
  • #009 📅 2026-06-22 (Fase 4) Migración de datos por lotes. Crear monitoreos nuevos genéricos (ifInOctets {IF}, ifOutOctets {IF}, ifHCInOctets {IF}, ifHCOutOctets {IF}, ifHighSpeed {IF}, ifSpeed {IF}). Empezar piloto con MikroTik (mayor fragilidad — VLANs idx 2001/2005 cambian al menor reboot/restore). Por dispositivo: setear interfaz en cada asignación nueva, validar lecturas correctas durante 1-2 ciclos, soft-deletear las asignaciones viejas hardcodeadas. Auditoría completa: 15 monitoreos ifTable + 62 ifXTable.
  • #010 📅 2026-06-03 Packet loss al AP Rumurachi-Urique (192.168.37.61). Ping desde monitoreo mostró 50% pérdida intermitente durante el diagnóstico. Probable causa de que el monitoreo 166 (ifSpeed.1 LAN1) caiga en falla esporádicamente y se persista como 0. Investigar enlace/RF a Rumurachi (no es es-antenas-new — es operación de red, capturar también en projects/electrosystems-network.md si aplica).
  • #172 📅 2026-06-18 (Fase 6 del flujo "Agregar candidato UISP") Wizard 1-page de Agregar. Unificar todo el flujo en UNA sola vista en lugar del redirect actual Agregar → /dispositivos/{id}/edit. Pantalla nueva (ruta dedicada /uisp-candidatos/{id}/wizard o modal grande en /uisp-candidatos) con: bloque plantilla (con preview de monitoreos que se van a prepoblar), bloque SNMP (community, versión), bloque variables de monitoreo (con botón "Copiar del contraparte" ya implementado en Fase 3), bloque enlace (Fase 5 reutilizable). Submit único: crea dispositivo + prepuebla monitoreos + sobreescribe los límites editados + asigna al enlace, todo en una transacción. Reemplaza el combo "click Agregar → redirect a edit → llenar SNMP → guardar → editar más → enlaces". Depende de Fase 5 ya implementada para el bloque de enlaces. Trade-off: vista más densa, pero el operador no pierde estado entre saltos y todo el contexto del candidato UISP (IP, nombre, plantilla sugerida) queda visible mientras llena.
  • #190 📅 2026-06-20 Retomar /metrics para Prometheus. Hoy quedó desactivado (commit 2efa022) porque el endpoint disparaba una query agregada sobre lecturas_historicas_detalles (49.6M filas) y colgaba PHP-FPM cuando un scraper lo pegaba. Cuando se vuelva a necesitar: (a) reescribir MetricsController::index evitando el eager-load with('ultima_lectura_historica.detalles'); opciones probadas en diagnóstico: loop con DB::table('lecturas_historicas')->where('dispositivo_id', $id)->orderByDesc('fecha')->first() (N=317 queries triviales con lecturas_historicas_dispositivo_id_fecha_index, backward scan, lee 1 fila por query) + 1 query bulk whereIn('lectura_historica_id', $ids) para los detalles, o LATERAL JOIN equivalente en SQL crudo. (b) Restaurar la ruta Route::get('/metrics', [MetricsController::class, 'index']) y el use App\Http\Controllers\MetricsController; en routes/web.php. (c) Considerar autenticarla (hoy era pública). El archivo MetricsController.php quedó intacto en el repo como referencia.
  • #196 📅 2026-06-02 Tepehuanes collector remoto caído. sitios.fecha_ultima_conexion para Tepehuanes a las 13:00 estaba a 487 minutos (~8 horas sin reportarse). Sigue caído. Es problema del HOST físico en sitio (collector Go corriendo en un equipo en Tepehuanes) — no del server. Pendiente operacional: investigar conectividad/equipo en Tepehuanes. Capturar en electrosystems-network-map cuando esté listo.
machine-parity
personal · active · high 4 pendientes

🎯 Top de ataque (4)

  • #155 📅 2026-06-03 Triage de repos atrasados / con changes locales: deportescampeon (5 changes, 1.5y), joyeriameza (1 change, 2y), greco-cell (limpio pero 1.2y), sis_platform (3y — confirmar si vivo). Decidir cada uno: pull, descartar changes, commitear, o archivar.
  • #408 📅 2026-06-02 ⏱ 30m Configurar WireGuard en el celular de Sergio con las mismas redes que el PC personal. App WireGuard (Android/iOS) → "Add tunnel" genera par de llaves → agregar peer 10.255.255.15 en la VM wireguard (wg set + append a wg0.conf, nunca wg-quick save) → config cliente split-tunnel reusando el mismo bloque AllowedIPs del túnel es-wg (sitios + 10.11.0.0/16 + 172.16.0.0/16 + 192.168.20/3.0/24 + 10.255.255.0/24) + Endpoint 201.174.219.154:51820. Peer name #celular-sergio. Runbook en electrosystems/servers/wireguard/README.md.
  • #409 📅 2026-06-03 ⏱ 1h Definir el proceso repetible para agregar más clientes WG road-warrior con acceso a las mismas redes. Base ya escrita (runbook en electrosystems/servers/wireguard/README.md + memoria reference_es_wireguard_roadwarrior). Pendiente: decidir si conviene un script/plantilla (genera llaves + arma el .conf cliente con el AllowedIPs canónico + comando server listo), convención de IPs .16+, y dejar el bloque AllowedIPs canónico en un solo lugar reutilizable. Toca infra ES (VM wireguard).
  • #410 📅 2026-06-04 ⏱ 2h ⚠️ Control de acceso más fino: que el router de oficina (y otros equipos) permitan solo clientes WG elegidos, no a todos los que salen NAT'eados como .20.5. Enfoque: que la VM wireguard NO enmascare el tráfico al destino sensible (regla iptables -t nat -I POSTROUTING -d <dst> -j ACCEPT antes del MASQUERADE general, o SNAT selectivo) para que el equipo vea el 10.255.255.x real del peer → ruta de regreso a 10.255.255.0/24 en el MikroTik vía gw → ACL del router que permita solo las IPs WG elegidas (ej. .14 PC, .15 celular). Implica tocar la VM wireguard (prod) + el router. Hoy (2026-05-29) se hizo el fix simple: .20.5 en el allow del MikroTik (da acceso a todos los clientes WG).
orion-decommission
electrosystems · active · high 10 pendientes

🎯 Top de ataque (10)

  • #139 📅 2026-06-05 Decidir destino de dokuwiki — coordinar con docs-platform. Opción A: migrar VM tal cual a poseidon. Opción B (ya pre-elegida en docs-platform): importar contenido a Wiki.js y decommissionar el VM sin migrar. RSS real 704 MB / qcow2 20 GB. Decidir antes de iniciar migración.
  • #140 📅 2026-06-10 Migrar otrs a poseidon (primero del lote, la más liviana confirmada en uso). RSS real 1.7 GB / allocated 2 GB / qcow2 20 GB. Observar swap/load 24-48 h antes de pasar a la siguiente. Bloqueado por: triage de / en poseidon (poseidon-root-triage).
  • #141 📅 2026-06-08 Migrar BORRAR traccar2025. ✅ Resuelto el "a dónde": #396 confirmó que el Traccar real vive en el host ares (192.168.3.2, vivo con ~20.5M check-ins). El traccar2025 de orion es un leftover de migración muerto (-incoming, NIC nunca cableado) — no hay servicio que preservar ni migrar. Acción: borrar la VM de orion (confirmar con Sergio antes del virsh undefine/borrado del qcow2). No bloqueante para el decommission.
  • #142 📅 2026-06-20 Considerar +RAM en poseidon como upgrade preventivo (oversubscribed con swap 100%). No bloquea la migración — los 2.5 GB RSS reales de las 3 VMs caben en los 9.6 GB available de poseidon — pero quita el miedo de raíz y compra runway para el refresh del hypervisor (poseidon también es CentOS 7 EOL).
  • #021 📅 2026-06-15 Decommissionar FreePBX/Asterisk local de orion. Descubierto el 2026-05-11. Sergio confirmó (2026-05-11): no está en uso actualmente, se usaba hace mucho tiempo. Se puede prescindir sin problema → simplificar el end-game: solo apagar el servicio + limpiar configuración antes de apagar el host, sin migración a otro PBX.
  • #023 cond:migracion-completa Decidir destino de la VM paused bookstack (parte de docs-platform).
  • #024 cond:migracion-completa Inventariar VMs archivadas en orion y decidir borrado o snapshot off-host antes de apagar.
  • #400 cond:migracion-completa Confirmar nada vivo apunta a orion (DNS, monitoring, scripts en otros hosts).
  • #401 cond:migracion-completa Documentar en INVENTORY.md el cambio de status a "decommissioned" cuando ocurra.
  • #402 cond:migracion-completa Apagar físicamente.
poseidon-root-triage
electrosystems · active · high 1 pendientes

🎯 Top de ataque (1)

  • #144 📅 2026-06-15 Limpieza low-risk (opcional, baja ganancia). El diagnóstico de #143 mostró que /var/log (1.2G) + /var/tmp (1.2G) + /root (53M) es el único terreno disponible para limpieza in-place — máximo ~2 GB recuperables, insuficiente para sacar / del rango crítico. Saltar este paso y ejecutar #145 directo. Mantener este pendiente como segunda barrida de mantenimiento DESPUÉS de #145.
telcel-capellina-lajunta
telcel · active · high 3 pendientes

🎯 Top de ataque (1)

  • #384 cond:respuesta-telcel ⚠️ Seguimiento con Telcel: su CPE en La Junta inyecta ~0 kbps pese a enlace 1G activo. Pedir que revisen puerto lado-servicio / mapeo de VLAN/EVC en su equipo de La Junta. Lado ES ya agotado y probado sano (ver bitácora 2026-05-28).

📦 Backlog (2)

  • #386 sin fecha Reactivar el pipeline de monitoreo de estos equipos en es-monitoreo (lecturas muertas desde ~2026-04-17 → no hubo timeline disponible durante este incidente).
  • #397 cond:activar-puertos-T2 Provisionar la llave de oxidized en los 4 radios de redundancia T2 (27.81/27.80/37.126/37.125) para que entren al backup automático. Hoy inalcanzables (puertos apagados en Gasachi); ya están listados en router.db, solo falta la llave cuando se activen.
monitoring-homologation
electrosystems · paused · high 12 pendientes

🎯 Top de ataque (12)

  • #344 sin fecha Investigar API de UISP: endpoints para listar devices (/nms/api/v2.1/devices), atributos relevantes (id, name, model, ip, site, role), webhook/event stream para alta/baja en tiempo real.
  • #345 sin fecha Diseñar mapping UISP → dispositivos:
  • #346 sin fecha Elegir modo de sync:
  • #347 sin fecha Flow de "claim" (edge case): cuando Sergio agrega a UISP un device por fuera de la herramienta (no via Fase 1A) y ya existía como origen=manual en es-antenas-new:
  • sin fecha Posible Modo A' (NO emprender sin discusión): capturar el endpoint interno que la UI usa al "Add Device" (browser DevTools al agregar manual una vez) y replicarlo con session cookie auth desde es-antenas-new. Técnicamente posible, operacionalmente frágil (Ubiquiti puede romperlo sin aviso en cualquier release). Solo considerar si Modo B resulta inviable por algún campo que el CSV no acepte.
  • #031 sin fecha Reporte de huérfanos en UI ("Devices pendientes de migrar a UISP"):
  • #349 sin fecha Flow de migración por device:
  • #350 sin fecha Métrica de cierre de proyecto: count(origen=manual AND administrado=true) = 0. Cuando se cumple, Fase 1A queda terminada y Fase 3 (doc) puede arrancar con un estado limpio.
  • #351 sin fecha Que los devices no-UISP (servers de telefonía, switches no-Ubiquiti, etc.) que Sergio quiere backupear estén entrando a NetBox con el tag backup-enabled.
  • #352 sin fecha Que el flow de NetBox a Oxidized esté funcionando (ya documentado en backup-system).
  • #353 sin fecha Documentar el flujo final en ~/agy/electrosystems/backup-system/README.md y/o en el wiki (docs.electrosystemsnet.com) para que la operación quede asentada.
  • #354 sin fecha Considerar un dashboard/vista de "salud del inventario" — cuántos devices en cada plataforma, cuántos sincronizados, cuántos huérfanos.
horizon-casas-internet-lento
electrosystems · done · high 5 pendientes

🎯 Top de ataque (5)

  • sin fecha Confirmar con Sergio: ¿cuál es la velocidad contratada por las 3 casas en agregado? Para decidir si el shaper de 70 Mbps en eth4 (CASAS) está bien o hay que subirlo.
  • sin fecha Decidir cambio countrycode 511 → 484 en los 4 equipos airOS para destrabar TX power.
  • sin fecha (Opcional) Evaluar pasar chanbw 40 → 80 MHz si hay espectro libre (correr AirView).
  • sin fecha iperf3 gateway↔ERX y ERX↔cada estación para medir antes/después del cambio.
  • sin fecha Documentar resultado final + verificar quejas resueltas con clientes.
hub-web-viewer
personal · active · medium 1 pendientes

🎯 Top de ataque (1)

  • #302 📅 2026-06-05 ⏱ 1-2h RSS / Atom feed de log diario (solo Sergio).
tareas-hijo
personal · active · medium 3 pendientes

🎯 Top de ataque (3)

  • #HIJ-003 📅 2026-06-22 🤖 alto (Fase 4, economía de puntos + premios) Schemas puntos_transacciones/premios/canjes, balance de puntos prominente en home hijo, catálogo + canjear, CRUD de premios en admin, cola de aprobación de canjes, ajuste manual de puntos. Deliverable: hijo acumula, canjea "30 min Switch", Sergio aprueba/marca cumplido. Estimación 1 sem. (antes #187) Gancho ya puesto: Tareas.aprobar/1 es el punto donde crear la transacción de puntos al aprobar.
  • #HIJ-004 📅 2026-06-30 🔥 🤖 medio (Fase 5, streaks + push) Query de streaks + badge en home hijo, VAPID + service worker, push diario al hijo si quedan pendientes (Oban cron), push a papá en eventos clave, settings de notifs en admin. Deliverable: hijo ve "🔥 7 días seguidos", recibe recordatorio si olvida tarea. Estimación 0.5 sem. (antes #188)
  • #HIJ-005 sin fecha 🤖 alto (Fase 6, evolución continua) Lo que el uso real revele — dashboard semanal para papá, mejor offline, posibles segundos hijos, etc. Sin alcance fijo todavía. (antes #189)
adfsa-migration
electrosystems · active · medium 7 pendientes

🎯 Top de ataque (7)

  • #360 📅 2026-06-05 Migrar la tarjeta E1 (TE210P dual-span) a Nortel del servidor viejo al nuevo. Implica:
  • #361 📅 2026-06-10 Desmantelar el servidor viejo (asterisk-adfsa-old). Pre-condición: migración de tarjeta E1 completa y validada + ruta IAX2 retirada del NEW. Pasos:
  • #041 📅 2026-06-15 Agregar IP pública en el NEW para troncal SIP de Transtelco (líneas americanas). ADFSA va a tener un segundo trunk SIP con Transtelco para sus DIDs US (en paralelo al de Telmex que ya está en cutover). Requiere:
  • #042 📅 2026-06-15 Validar estatus end-to-end de la migración SIP Telmex — confirmar que llamadas in/out funcionan después del swap, que los teléfonos están registrando contra el nuevo server, y que el trunk Telmex sigue activo.
  • #043 📅 2026-06-12 Verificar soporte MFC-R2 (openr2) en el chan_dahdi de FreePBX 17 / Debian 13 antes de insertar la tarjeta E1. Comando útil cuando DAHDI esté cargado: asterisk -rx "dahdi show mfcr2 variants" y revisar si la librería libopenr2 está en el sistema. Sin esto, la migración del E1 falla en signalling MX.
  • #044 📅 2026-06-17 Limpiar inconsistencia de apt sources en Debian 12/13. El host tiene mezcla: líneas bookworm + una línea stable (resuelve a trixie) + repo Sangoma bookworm. Runtime es trixie pero Sangoma no soporta oficialmente trixie. Decidir: bajar a bookworm (alineado con Sangoma) o quedarse en trixie (no soportado, riesgo de roto en el siguiente major upgrade de FreePBX). Revisar packages held antes de tocar nada.
  • #366 📅 2026-06-20 Inbound desde Telmex. Outbound validado en producción 2026-05-07; inbound deferido al provider. Confirmar con Telmex cuando restauren el servicio. Probable: parte del rollout de PSTN-E1 → SIP-trunk de los próximos días.
amadeus
electrosystems · active · medium 38 pendientes

🎯 Top de ataque (37)

  • sin fecha B.1 Migración auditorias_viaje + modelo + relaciones.
  • #392 ⏱ 2h 🔥 Quick-win nativo (ya viable). El Traccar de ares es 6.6 con emailEnabled:true → se puede definir el geofence "Cd. Juárez" + una notificación por email a la contadora directo en la UI de Traccar, sin tocar Amadeus. Requiere login admin de Traccar (lo tiene Sergio) — yo lo guío o lo hace él. Limitación conocida: dispara con cualquier entrada a Juárez (ruido) y sin contexto de viaje; cobertura provisional hasta el bridge.
  • #249 📅 2026-06-01 🔥 Prender ANALISIS_HOOK_CONSUMOS_ENABLED=true (validación automática al subir). Desbloqueado — workers ya listos (#371 cerrado). (Bloque 0)
  • sin fecha B.2 AuditorViajeService con flags determinísticos.
  • #393 cond:post-milestone ⏱ 1d ⚠️ Cimientos del bridge. Columna traccar_device_id en vehiculos + mapeo unidad↔device (consultando GET http://201.218.172.10:8082/api/devices); permiso nuevo notificar_retorno en permisos (Nova + modelo); crear token/usuario read-only en Traccar 6.6 (login admin de Sergio); montar scheduler (cron de php artisan schedule:run, hoy inexistente).
  • #369 📅 2026-06-04 ⏱ 1d 🔥 PR 1-4 de políticas/lineamientos editables (amadeus-politicas-viaticos.md). D1-D5 cerradas. ✅ PR 1, PR 2, PR 3 y PR 4 COMPLETADOS (commits 7e53af6/449a2cb/2506bb2/c60fc91 + PR 4 listo en local). Pendiente: (1) validación en staging/prod (correr analisis:auditar-viaje <viaje-cerrado> y comparar violaciones_politica vs juicio humano), (2) deploy de PR 4 a producción. (Bloque 0b)
  • sin fecha B.3 Llamada extra a Antigravity para resumen ejecutivo (helper en mismo service o ResumidorAuditoriaService).
  • #394 cond:post-milestone ⏱ 2d ⚠️ Bridge Amadeus↔Traccar. Comando programado que consulta la posición (GET http://201.218.172.10:8082/api/positions?deviceId= en Traccar 6.6) de los vehículos en viaje activo (fecha_cierre IS NULL y destino fuera de Juárez); detecta transición fuera→dentro del bbox de Juárez; dispara evento RetornoDetectadoEvent → listener push+email a quienes tengan notificar_retorno. Mensaje con contexto: "Vehículo U09 (viaje folio X, técnico Y) regresó a Cd. Juárez a las HH:MM." Idempotente (no re-avisar). Alternativa más limpia: notificación web (webhook) de Traccar 6.6 al geofence → endpoint en Amadeus (evita scheduler).
  • #380 📅 2026-06-06 ⏱ 1d ⚠️ Pantalla mapa Leaflet+OSM de consumos con popup/hover de detalle. (Bloque C — victoria visual)
  • sin fecha B.4 AuditoriaViajeController + ruta + policy.
  • #378 📅 2026-06-09 ⏱ 0.5d ⚠️ Coords oficina/matriz (config) + medir cobertura GPS de sitios. (Hospedaje omitido.) (Bloque B)
  • sin fecha B.5 Page Vue Admin/AuditoriaViaje.vue con secciones del diseño.
  • #379 📅 2026-06-10 ⏱ 1d ⚠️ Validación de ubicación por corredor (sitio/oficina/segmento), solo bandera; pasar anclas a la IA. (Bloque B)
  • sin fecha B.6 Botón "Auditar" en /viajes/{id} show (visible si admin).
  • #382 📅 2026-06-16 ⏱ 2d ⚠️ Subida offline = borrador local (IndexedDB + sync al reabrir con señal, preservar ubicación, notificar si queda observado). (Bloque D — el más caro)
  • sin fecha B.7 Comando artisan analisis:auditar-viaje.
  • #387 cond:post-milestone ⏱ 3-4d ⚠️ Reloj checador en sitio (geolocalizado) para técnicos de viaje. Checada con captura de coordenada + cotejo contra el GPS del sitio asignado (geofence por radio) para validar que estén físicamente en el lugar de trabajo. Validación suave (bandera, no bloqueo), coherente con la filosofía del milestone. Diseño/ideas en Notas técnicas → Checador geolocalizado (#387). Depende de coords de sitios pobladas (#378).
  • sin fecha B.8 Tests Pest end-to-end.
  • #388 cond:post-milestone ⏱ 4-6d ⚠️ Ingesta de facturas desde la bandeja de contabilidad + ligado automático a consumos. Leer los correos donde llegan las facturas (CFDI) de los viáticos, parsear el XML, y ligarlas automáticamente al consumo del técnico que corresponde (por monto + fecha + RFC/comercio) para que la contadora ya no cotije a mano al validar/imprimir. Diseño/ideas en Notas técnicas → Ingesta de facturas CFDI (#388).
  • sin fecha B.9 Smoke test contra viaje 191 / Manuel para validar que la IA captura los patrones que ya vemos en metadatos.
  • #392 ⏱ 2h 🔥 Quick-win nativo (ya viable): geofence Juárez + email a contadora directo en la UI de Traccar 6.6. Requiere login admin de Sergio.
  • #393 cond:post-milestone ⏱ 1d ⚠️ Cimientos del bridge: traccar_device_id en vehículos + permiso notificar_retorno + scheduler.
  • #394 cond:post-milestone ⏱ 2d ⚠️ Bridge Amadeus↔Traccar: re-entrada a Juárez de vehículos en viaje activo → push+email con contexto.
  • #395 cond:fase-2-lista ⏱ 2-3d Futuro: detección por celular del técnico (PWA) para viajes en avión.
  • #048 📅 2026-06-02 #048 Asignar permisos inventarios_preparar/_entregar/_revisar al resto (18 usuarios en 0) cuando Selene valide el piloto. Capa 1 ON parcial para Selene Ortega (user_id=14, los 3 permisos en 1). Capa 2 (INVENTARIO_VIAJE_LINK) sigue OFF — solo Sergio la activa editando .env.
  • #047 📅 2026-06-01 #047 Smoke piloto Selene — flujo manual end-to-end de inventarios desde /movimientos-inventario (preparar → entregar → revisar). Probar también MisEntregas y ViajeCompras. Crear OT, asociar inventario, verificar descuento.
  • #050 📅 2026-06-03 #050 Smoke N vehículos fase 1 — crear viaje con 2+ vehículos, verificar guardado, edit (vuelve a marcar los 2), listado pluralizado, reporte.
  • #211 📅 2026-06-04 #211a Smoke notificaciones in-app — crear notif en Nova con permisos_requeridos={"inventarios":true} y validar filtrado por superadmin + usuario con permiso + usuario sin permiso. Badge y campana móvil deben encenderse.
  • #175 📅 2026-06-05 #175 Smoke E2E bot electro-ia ↔ amadeus — desde Telegram (documentado en electro-ia con plan completo).
  • 📅 2026-06-05 Decidir branch a desplegar (recomendado: merge a main primero por trazabilidad).
  • 📅 2026-06-06 Backup de la BD de producción antes de migrar.
  • 📅 2026-06-06 Revisar las 22 migraciones por orden (especialmente modify_* y remove_* — son destructivas si fallan a mitad).
  • 📅 2026-06-07 Plan de rollback: snapshot de la VM en Poseidon + dump de BD. Reversión de migraciones no es trivial con tantos cambios encadenados.
  • 📅 2026-06-07 Ventana de despliegue acordada (¿fuera de horario operativo?).
  • 📅 2026-06-08 Composer install + npm build + php artisan migrate --force + php artisan optimize.
  • 📅 2026-06-08 Verificar permisos nuevos en add_inventario_granular_permisos (puede que necesite seed/sync de roles).
  • 📅 2026-06-08 Smoke test: crear OT, crear movimiento de inventario (rápido y normal), revisión de traslado, viaje_compras.

📦 Backlog (1)

  • #395 cond:fase-2-lista ⏱ 2-3d Fase futura: detección por celular del técnico. Para las contadas ocasiones en que el técnico viaja en avión (el vehículo no se mueve, así que Traccar no lo detecta). Geofence ligero vía la PWA de Amadeus (navigator.geolocation), reusando el patrón de captura GPS de #381 (consumos) y del checador #387. Más invasivo (requiere permiso de ubicación / app abierta) — por eso es fase 2, solo el caso avión.
amadeus-sprints
electrosystems · active · medium 30 pendientes

📦 Backlog (6)

  • #233 sin fecha (AM-49, L) Traducciones a español end-to-end. Sprint dedicado cuando Sergio decida alcance: end-to-end o página por página.
  • #234 sin fecha (AM-57, L) BD de equipos en sitios con identificadores. Tabla inventarios ya tiene equipo_id+numero_serie+sitio_id; falta aclarar "hacia dónde están apuntados" (topología de red / enlace lógico entre equipos). Pide aclaración antes de tasar.
  • #235 sin fecha (AM-139, L) Múltiples destinos + cuadrillas + vehículos por viaje (Fase 2 de N vehículos). Después de validar Fase 1 en prod (smoke #050).
  • #236 sin fecha (AM-140) Editar productos de viaje recién creado. Editor en FormaViaje.vue:214-245 bajo viaje_link_enabled. Solo accionable al activar capa 2 (INVENTARIO_VIAJE_LINK=true en .env).
  • #237 sin fecha (AM-144, M) Visualizar existencia de productos al hacer viaje/traslado. Display de stock en SelectorProductosMovimiento.vue. Caso del traslado puede hacerse antes; caso del viaje depende de capa 2.
  • #238 sin fecha (AM-143, S-M) Checklist entrega: "presione OK" sin botón + mensaje falso. En pausa hasta que Sergio reproduzca el caso real con screenshot (botón SÍ existe en Checklist.vue:104-120; mensaje aparece cuando anyBad=true con default ok=false). Necesita screenshot para distinguir fix A/B/C.

📝 Otras (24)

  • #209 sin fecha (AM-52, S) Indicador "cargando" al subir consumo — loading state en Pages/Consumos/Create.vue durante el submit.
  • #218 sin fecha (AM-69, M) Correo diario de saldos con viáticos — job + Mailable + schedule en Kernel.php (SMTP ya configurado desde 2026-05-19).
  • #222 sin fecha (AM-55, L) Layer de roles persistidos (Opción A aprobada 2026-05-20) — schema nuevo (roles, rol_permiso, FK opcional usuarios.rol_id), refactor de policies para resolver vía rol con override per-usuario, Nova UI para gestionar roles. Tests.
  • #224 sin fecha (consolida AM-65/AM-73/AM-90/AM-99/AM-136) Modelo Nota polimórfico + foto opcional + listener al crear viaje. 5 tickets del backlog colapsados a un solo epic.
  • #225 sin fecha (AM-129, M) Paginación estandarizada — componente Paginador.vue reusable + audit de páginas que hoy paginan distinto.
  • #228 sin fecha (AM-119, M) Inventarios pertenezcan a sitio O usuario — inventarios.usuario_id nullable + check constraint OR (uno de los dos, no ambos null ni ambos non-null). Originalmente en Sprint 11 de Jira.
  • #231 sin fecha (AM-135, M) Viajar sin unidad (avión/camión) con detalles de vuelo/camión — tipo de transporte alternativo + campos.
  • #210 sin fecha (AM-53, S) Mensaje flash móvil tapado — z-index del toast en Layout.vue:14-21 lo deja atrás de elementos del topbar; subir el z-index.
  • #219 sin fecha (AM-93, M) Consumos por usuario/fecha/categoría sumarizados — reporte agregado con filtros.
  • #223 sin fecha (AM-72, S+) Push + email scheduled job a las 16:00 (Opción C aprobada 2026-05-20, NO SMS pagado) — scheduled job que dispara push a técnicos pidiendo captura de viáticos; fallback a email si no marcan leído en X horas. Reusa VAPID + Gmail Workspace. Costo recurrente $0.
  • #226 sin fecha (AM-137, M) Form de creación de viajes en móvil — mobile UX de FormaViaje.vue. Reusar patrones del rediseño móvil de /notificaciones (2026-05-20).
  • #229 sin fecha (AM-120, S) Verificar cobertura de cambio de estatus → inventario. InventarioService::aplicarEntrada ya cubre entregado. Al inicio del sprint verificar que también cubra rechazado y cancelado — si ya están cubiertos, cerrar sin trabajo.
  • #232 sin fecha (AM-145, M) Actualizar órdenes y notificar cambios — extender listener actual (dispara en created) a updated con diff. Reusar NotificarViajeCreadoService.
  • #211 sin fecha (AM-66, S) Nota por consumo para justificación de compras — campo nota text en consumos + form field + display en detalle.
  • #220 sin fecha (AM-131, M) Vista detalle de producto (Pages/Productos/Show.vue) con dos tablas: inventarios por sitio + historial de movimientos.
  • #227 sin fecha ⚠️ (AM-142, S-M) Mejorar estilo de info de materiales/productos ⚠️ aclarar al inicio del sprint qué pantalla específicamente; sin contexto no se puede tasar bien.
  • #230 sin fecha (AM-59, M) Fotos de estado de unidad en salida y llegada — tabla viaje_fotos + storage + UI camera. Originalmente en Sprint 11 de Jira.
  • #212 sin fecha (AM-89, S) Fecha manual en depósitos — campo fecha en form (hoy es auto al server time).
  • #221 sin fecha (AM-100, M) Múltiples fotos en consumos — storage multi-file + UI gallery.
  • #213 sin fecha (AM-94, S) Subtotal e IVA en consumos — agregar subtotal + iva calculados/capturados; mostrar desglose.
  • #214 sin fecha (AM-95, S) Entrada/salida siempre con servicio o lugar — validar al inicio que sitio_id requerido en MovimientoInventario (probablemente ya está, verificar).
  • #215 sin fecha (AM-130, S) Select buscable en filtro de productos — usar SearchableSelectInput.vue (ya existe) en la lista de movimientos de inventario.
  • #216 sin fecha (AM-133, S) Buscar movimientos por número de serie — filtro en MovimientosInventarioController::index usando numero_serie en inventarios (disponible desde 2025-11-19).
  • #217 sin fecha (AM-138, S) Cancelar órdenes sin viáticos ni depósitos — botón condicional en detalle de orden; endpoint POST /ordenes/{id}/cancelar con validación.
backup-system
electrosystems · active · medium 19 pendientes

🎯 Top de ataque (19)

  • #314 📅 2026-06-03 Planet — vendor faltante. Pendiente: identificar cuántos devices Planet hay en la red (probablemente switches L2/L3 de la línea Planet). Existe ya un alias planet-parral en ~/.ssh/config (192.168.44.2, user admin). Investigar firmware/CLI y elegir/escribir modelo Oxidized.
  • #315 📅 2026-06-05 Siklu — vendor faltante. Sergio nota: "no está documentado por nombre, es parte de los dispositivos faltantes". Probable: equipos mmWave/E-band que están entre los blackBox UNKNOWN de UISP. Identificar por OUI (Siklu OUI: 00-22-91) y agregar a BLACKBOX_OUI_MAP similar al patrón Mimosa. Verificar si tienen SSH y cómo se exporta su config.
  • 📅 2026-06-08 Decidir credenciales por vendor (password fijo del fabricante? key auth? RBAC en NetBox?).
  • 📅 2026-06-10 Para cada vendor: confirmar si necesita un provision_<vendor>.sh (instalación de SSH keys) o si se backup con password en sops.
  • 📅 2026-06-12 Tag backup-enabled en NetBox para devices ya inventariados de cada vendor (ver flujo en electrosystems/backup-system/README.md).
  • #316 📅 2026-06-15 Aclarar caso de uso real con Sergio: si la pendiente "ver manera de descargar" sigue viva, ¿qué le falta a la UI actual? Casos posibles:
  • #061 📅 2026-06-17 #061a A — IP en el header del archivo de config. Auto-inyectada por Oxidized vía model hook. Primera línea del archivo como comentario con la IP del device en el momento del backup. git grep <ip> instantáneo.
  • #061 📅 2026-06-19 #061b C — Manifest inventory.yaml versionado. Generado por inventory_merger.py en cada run, commiteado al repo configs.git. Mapea device-slug → IP, modelo, sitio, region por snapshot. Snapshot histórico de "qué IP tenía X el día tal" queda en git log inventory.yaml.
  • #319 📅 2026-06-22 155 devices recién agregados de regiones nuevas (Chihuahua, Parral, Caborca, Namiquipa, Nogales, Villa Ahumada, Colonia del Valle): pendientes de correr fleet_provision_airos.sh / fleet_provision_edgeos.sh antes de que los backups con key-auth funcionen. Lista de runs candidata en el README de electrosystems/backup-system/ § "Onboarding the new regions".
  • #320 📅 2026-06-24 45 Netonix WS-x: correr fleet_provision_netonix.sh con la firmware-split logic. Old firmware (kernel 2.6.x) acepta keys, new firmware (kernel 5.x) requiere password en sops creds.
  • #321 📅 2026-06-25 6 devices airFiber AF60-LR tienen prompt diferente al airfiber.rb stock (AP/ST-Castillo-Market, AP/ST-El-Paso-Matriz, AP/ST-Matriz-Gus). Workaround actual: device_overrides.yaml los fuerza a model airos. Mejora futura: tunear el modelo airFiber upstream o escribir uno custom AF60-LR.
  • #322 📅 2026-06-26 AP-MEDICOS2, SECTORIALELPASO (airOS) y ST-Castillo-Jichasa (airFiber) — rechazan los 5 candidate passwords. Probable creds device-specific. Discovery manual o reset físico.
  • #323 📅 2026-06-27 Cambium ePMP requiere KEX curve25519 — gem Ruby x25519 instalado en VM oxidized 2026-05-05 (fixed). Pendiente: agregarlo al provisioning-baseline doc (parte del README) para que cualquier reprovisión futura del VM lo incluya por default.
  • #324 📅 2026-06-28 Subir RAM de netbox VM a ≥ 4 GiB (actualmente ~414 MiB swap en uso). Próxima ventana de mantenimiento.
  • #325 📅 2026-06-29 Identificar hipervisor de netbox — SMBIOS solo reporta "Red Hat / KVM" genérico. Necesario para provisionar un VM hermano del oxidized si se quiere distribuir carga.
  • #326 📅 2026-06-30 Configurar Snapshot Replication policy sobre el share NetworkBackups en es-nas. Recomendación del README: hourly×24h, daily×30d, weekly forever.
  • #244 📅 2026-06-30 Endurecer shell del user oxidized en es-nas de /bin/sh a /usr/bin/git-shell una vez que el pipeline esté estable. Constrain a operaciones git solamente.
  • #328 📅 2026-06-30 Agregar QEMU guest-agent channel al VM oxidized (no se hizo en el virt-install). Cosmético; arreglable editando domain XML y agregando <channel type='unix'>...</channel>.
  • #329 📅 2026-06-30 Verificar salud del cron cgit-mirror en reverse-proxy (sync hourly de nas:configs.git a /var/lib/cgit/configs.git). No hay alarma; verificar pasivamente en el siguiente touch del host.
cpe-benito-juarez
benito-juarez · active · medium 5 pendientes

🎯 Top de ataque (5)

  • #092 📅 2026-06-04 Limitar el servicio a 200 Mbps cuando se haga la entrega formal del cliente.
  • #088 📅 2026-06-06 Subir llave SSH al Netonix sw-villa-ahumada (mismo flujo que el MK; aún sin key auth).
  • #089 📅 2026-06-08 Confirmar con el cliente la metodología del speedtest del 2026-05-08 (dispositivo, cableado, WiFi, server).
  • #090 📅 2026-06-10 Probar speedtest desde detrás del MK directamente (ether3/7/8 libres, cable, target conocido — Cloudflare/speedtest.net/etc.).
  • #091 📅 2026-06-20 Re-checar SFP rx-power en 2-4 semanas (hoy −26.38 dBm, dentro de spec pero en zona baja).
deportescampeon
deportes-campeon · active · medium 2 pendientes

🎯 Top de ataque (2)

  • #093 📅 2026-06-08 Recopilar / revisar la lista de requerimientos pendientes del cliente (no documentados aquí todavía — Sergio los irá dictando o pegará referencias).
  • #094 📅 2026-06-12 Reanudar trabajo activo en el proyecto.
electrosystems-network-map
electrosystems · active · medium 4 pendientes

🎯 Top de ataque (4)

  • 📅 2026-06-05 Fase 1 — resto:
  • 📅 2026-06-12 Fase 2 — llenado guiado por Sergio:
  • 📅 2026-06-20 Fase 3 — pulir PLAYBOOKS.md tras primer triage en vivo: refinar caso A (qué OID específico mirar en cada Telcel L2L), caso B (procedimiento para enlace de 1 solo AP como Mina Dolores), caso C (queries específicas a monitoreo.alertas/monitoreo.lecturas_historicas para extraer grupos).
  • sin fecha Fase 4 — stale-check: definir cadencia (¿semanal? ¿con cada incidente?) y qué comparar (monitoreo dispositivos actuales vs KB).
gi-siptrunks-replacement
electrosystems · active · medium 6 pendientes

🎯 Top de ataque (6)

  • #034 📅 2026-06-03 Recopilar datos del VM nuevo: hostname, IP/LAN, distro + versión, FreePBX/Asterisk version, vCPU/RAM/disco, ruta de acceso SSH (¿mismo alias gi-siptrunks?, ¿mismo bastion gi-corp?).
  • #035 📅 2026-06-05 Validar registración de trunks SIPSTATION (trunk1.freepbx.com, trunk2.freepbx.com, user d4ca438c) — asterisk -rx 'pjsip show registrations' o equivalente.
  • #036 📅 2026-06-05 Validar admin UI carga con TLS moderno (el bloqueador del 2026-04-29 debería estar resuelto al subir OpenSSL).
  • #037 📅 2026-06-08 Confirmar dialplan + extensiones migrados; comparar contra el viejo si hay backup.
  • #038 📅 2026-06-10 Status del VM viejo (172.16.1.34): ¿apagado?, ¿decommission completo?, ¿queda como backup encendido por N días?
  • #039 📅 2026-06-12 Actualizar docs internas de electrosystems con nuevo stack.
greco-cell
greco-cell · active · medium 3 pendientes

🎯 Top de ataque (3)

  • #097 📅 2026-06-04 Recopilar / revisar la lista de requerimientos pendientes del cliente.
  • #098 📅 2026-06-06 Reanudar trabajo activo.
  • #095 📅 2026-06-10 Diagnosticar la razón por la que a veces hay que reiniciar mysql y/o php-fpm.
holbox
holbox · active · medium 12 pendientes

🎯 Top de ataque (12)

  • #383 📅 2026-06-01 ⏱ 3-4h ⚠️ 💰 FACTURABLE — Reducir fallos de WhatsApp (33% actual) con fix de calidad de dato en 2 capas: (1) upstream validar teléfono al capturar en POS/alta de cliente (10 dígitos + LADA mexicana válida, se apoya en PhoneNumber/libphonenumber del #197/#368) para atrapar typos antes de gastar envíos; (2) downstream en el webhook marcar números que rebotan con 131026 (flag suave whatsapp_no_disponible, NO opt-out duro porque 131026 a veces es transitorio) + aviso en banda del POS "este número no recibe WhatsApp, verifícalo". Diagnóstico completo en bitácora 2026-05-28. Esperando que Aarón apruebe (Sergio le mostrará el reporte con la columna de causa de falla primero).
  • 📅 2026-05-30 (Fase 2 futura) Imagen/PDF en lugar de link, vía plantilla Meta con header media. Generar PNG/PDF del ticket server-side (Browsershot/snappy), subir a /{phone_id}/media, usar media_id en send. La arquitectura ya tolera este cambio sin refactor: el contract WhatsAppSender gana un parámetro o un segundo método.
  • 📅 2026-06-01 (mejora futura, no urgente) Cuando el error en quick-add sea email duplicado, sugerir "Ya existe un cliente con ese email, ¿lo seleccionas?" con shortcut para asignarlo a la venta en curso sin abandonar el form.
  • 📅 2026-06-02 (opcional pulir) Autocomplete de productos en el form — hoy el select de productos lista todos (26 en dev, presumiblemente más en prod). Si se vuelve incómodo, cambiar a autocomplete por SKU/nombre. Por ahora la lista es manejable.
  • 📅 2026-06-03 Versión anterior del pendiente (preservada como historia): Diseño tentativo:
  • #148 📅 2026-06-04 #148 (NUEVO 2026-05-21, bloqueado por Aarón) Registrar Holbox Óptica en Google Business Profile. Sin el local registrado en Google Maps, cuando el cliente da clic en el pin del template WhatsApp (optica_ubicacion_v1), Maps no encuentra "Holbox Óptica" y resuelve a otro lugar. Mitigación corta aplicada 2026-05-21: address en .env extendido a "Avenida de la Raza 7030, 32500 Cd. Juárez, Chih." para que Maps geocodifique la calle correcta. Solución de fondo: Aarón crea el perfil del local en Google Business Profile (gratis); cuando Google lo apruebe, el pin abrirá la ficha real del local.
  • #160 📅 2026-06-05 #160 (NUEVO 2026-05-22, PAUSADO 2026-05-24) Revisar habilitar recepción de llamadas al número de WhatsApp Business. Análisis cerrado: la solución técnica ideal es WhatsApp Business Coexistence (Meta mayo 2025) — mismo número en app móvil + Cloud API simultáneo vía Messaging Echoes, llamadas en celular, sin costo extra, sin tocar nuestro código. Pausado porque (a) Sergio no ve la opción "Coexistence" en Meta Business Manager del WABA de Holbox (rollout regional incompleto a 2026-05) y (b) Aarón prefiere no hacer setup elaborado. Despausa condicional a decisión sobre #165 (cotización CRM) — si va por CRM SaaS, el CRM probablemente cubre llamadas y #160 queda N/A. Detalle completo bitácora 2026-05-24 (noche).
  • #256 📅 2026-06-07 ⏱ 28h (cotizado) 🔥 💰 FACTURABLE (DESBLOQUEADO 2026-05-28 — Aarón aprobó) — Fase 1: Bandeja básica + atención manual. Webhook inbound extendiendo el del #149 para procesar messages, tablas conversaciones + mensajes_wa + identificación cliente/prospecto, UI /admin/conversaciones con bandeja + chat view + asignación humana + estado activa/archivada + pipeline de prospectos. Entregable independiente y útil aunque no se haga Fase 2 — el equipo puede ver y contestar todos los mensajes en un solo lugar. 28h × $350 = $9,800 MXN cotizado a Aarón (facturación = horas reales × tarifa con flujo asistido, ver regla del hub). EN PROGRESO — plan técnico cerrado en plan-crm-fase1.md (preguntas P1/P2/P3/P5 resueltas por Sergio, ver bitácora). 3 entregas deployables: ✅ E1 captura inbound ~11h DEPLOYADA A PROD (commit a8ad89e, GHA 26605651268 verde — migraciones + backfill telefono_e164 corridos en prod); ✅ E2 bandeja read-only ~10h DEPLOYADA A PROD OCULTA (commits 30632da + bdcf05e, GHA 26659946880 verde; sin link en menú a propósito para testing previo a entrega — acceso solo por URL /admin/conversaciones, role:admin; revertir bdcf05e al entregar); ✅ E3 atención+envío+conversión ~9h DEPLOYADA A PROD (commit 9769533, push 2026-05-29 16:18 local; menú sigue oculto — revertir bdcf05e al entregar). tenant_id nullable desde día 1 (decisión #258). Prospecto = tabla nueva (no flag en clientes). Decisiones: telefono_e164 materializado (P1), solo admin atiende (P2), hilo global (P3), imágenes desde día 1 (P5).
  • #257 📅 2026-06-08 #257 💰 FACTURABLE (condicional a #256 entregada) — Fase 2: Asistente automático + integración holbox.store + escalado. Servicio IAResponder con Antigravity Haiku 4.5 (interno, no se menciona al cliente) + guion configurable desde /admin/asistente (textarea editable, versionado, variables {nombre_negocio}/{catalogo}/{promociones}), conexión con catálogo de holbox.store (sync periódico configurable, productos/precios/stock/links directos), lógica de escalado (intent "humano" / queja / fuera de guion / N mensajes sin resolver), notificaciones push+email al equipo, modo sombra inicial (asistente propone, humano aprueba y envía) configurable. 26h × $350 = $9,100 MXN, 1.5 semanas calendario (con leve traslape sobre el final de Fase 1). Costo recurrente Anthropic estimado $3-15 USD/mes para Holbox (a cargo del cliente, no del desarrollo). Los datos para reportería quedan registrados desde día 1 — pantallas en #260.
  • #258 📅 2026-06-10 #258 — Fase 3 multi-tenant opcional (interno, NO en propuesta cliente-facing). Abstracciones tenant_id en conversaciones/mensajes_wa/asistente_config, panel super-admin, docs de adopción para portar a Joyerías Meza / Greco Cell / Deportes Campeón. ~30-40h × $350 = $10,500-14,000 MXN, cobrable a cada cliente que adopte después. Decisión técnica: dejar tenant_id como columna nullable desde Fase 1 para no migrar después si Sergio decide adoptar el módulo en otro cliente sin tocar a Holbox. No mencionar a Aarón salvo que pregunte.
  • #260 📅 2026-06-11 #260 💰 FACTURABLE (extensión opcional posterior a #257) — Reportería del módulo Conversaciones. Pantallas: conversaciones por día/semana/mes, % resueltas por asistente vs humano, tiempo de respuesta promedio, preguntas más frecuentes (útil para mejorar el guion), prospectos → clientes con tasa de conversión. Los datos ya están registrados desde el día 1 (Fase 1+2 los persisten), solo se construyen las vistas. ~5-8h × $350 = $1,750-2,800 MXN. Cotizar y arrancar cuando Aarón la pida (típicamente mes 2-3 tras arranque del módulo).
  • 📅 2026-06-12 Atender el flujo continuo de cambios pedidos por el cliente post-rollout.
hub-portability
personal · active · medium 1 pendientes

🎯 Top de ataque (1)

  • sin fecha (Más adelante) Migrar el remote de GitHub privado a Gitea/Forgejo self-hosted en poseidon cuando docs-platform lo lleve a cabo.
ia-evaluacion
electrosystems · active · medium 5 pendientes

🎯 Top de ataque (5)

  • #103 📅 2026-06-09 Probar gemma4:26b en tareas multimodales (mandarle una imagen — foto de un equipo de red, screenshot, diagrama — y medir calidad).
  • #102 📅 2026-06-11 Comparativa de latencia y calidad: qwen2.5:14b-instruct vs gemma4:26b con el mismo prompt en español, con num_ctx=8192 en ambos.
  • #105 📅 2026-06-13 Decidir si vale la pena instalar también gemma4:31b dense para tener referencia de techo de calidad (a costa de latencia muy alta).
  • #101 📅 2026-06-15 Aplicar Tier 3 en Ollama (OLLAMA_FLASH_ATTENTION=1 + OLLAMA_KV_CACHE_TYPE=q8_0) — necesita sudo, no aplicado. Esperar ventana con Sergio en sesión local.
  • #104 📅 2026-06-18 Caracterizar gemma4:latest (4B edge) como fallback rápido para chat conversacional cuando no se necesite razonamiento multimodal.
jm-checador
joyerias-meza · active · medium 2 pendientes

🎯 Top de ataque (2)

  • #111 📅 2026-08-14 (cierre condicional) Sacar los campos descanso, dia_extra, tipo_extra (y opcionalmente los horarios semanales) del bloque if($usuario->admin) en src/Template/Element/forma_empleados.ctp:15 para que admins de sucursal también puedan editarlos. Alternativa: agregarlo al form de jm-contabilidad (empleados/forma.blade.php), que hoy no lo expone.
  • #286 sin fecha (Si aplica) Validar si otras empleadas de cualquier sucursal tienen empleados.descanso != 0 como rezago del modelo viejo: SELECT id, nombres, apellidos, sucursal_id, descanso FROM empleados WHERE descanso != 0 AND deleted_at IS NULL. Si son pocas, limpiar igual que Lidia; si son muchas, justifica el fix permanente.
joyeriameza
joyerias-meza · active · medium 7 pendientes

🎯 Top de ataque (7)

  • #178 📅 2026-06-02 Redactar y enviar correo 1 al cliente (tarifa nueva + disponibilidad para trabajo grande + handoff profesional como opción abierta). Tarifa propuesta: $300 MXN/h desarrollo + $3,500 MXN/mes soporte, aplicación 1 de agosto de 2026. Draft listo en bitácora 2026-05-22; ajustar [Nombre] del contacto antes de enviar. Acción al confirmar recibo del cliente: actualizar clients/joyerias-meza.md con la nueva tarifa vigente y marcar rate_locked_since: 2026-08.
  • #179 📅 2026-06-04 Construir inventario actual de PCs + cuentas Office del cliente. Tabla en este mismo archivo o en joyeriameza/inventario-pcs.md. Columnas: sucursal · etiqueta/nombre de la PC · usuario humano que la opera · cuenta Office instalada (una de las 3 familiares) · fecha de setup · estado (activa / fuera de uso / desconocida). Fuente principal: portal de admin de cada cuenta Office para ver dispositivos asociados. Pre-requisito del #181.
  • #180 📅 2026-06-06 Documentar manual de setup de PC nueva (Office, bookmarks, startup apps, etc.) en formato paso a paso con screenshots, pensado para que cualquier persona de Joyerías Meza pueda seguirlo sin background técnico. Guardar en joyeriameza/setup-pc-nueva.md o equivalente. Pre-requisito del #181.
  • #181 📅 2026-06-08 (bloqueado por #178 + #179 + #180) Redactar y enviar correo 2 al cliente: aclarar scope del soporte mensual (cubre software/fallas/ajustes; NO cubre hardware, configuración de PCs nuevas ni soporte de Office) + propuesta de handoff del proceso de setup de PCs y administración de las cuentas Office. Adjuntar inventario (#179) + link al manual (#180). Mandar 4-6 semanas después del correo 1, una vez digerida la tarifa. Draft listo en bitácora 2026-05-22.
  • #373 📅 2026-06-10 #373 (NUEVO 2026-05-27) Follow-up del bug compuesto: cuando se cancela una transacción que afectó al limite_credito, el sistema no lo restaura (el método de cancelación no re-procesa el cálculo del límite). En el caso de Veneza, la transacción #1935290 fue cancelada 4 minutos después pero el límite ya estaba en 0 y se quedó así. Investigar el método de cancelación y agregar restauración del límite cuando se cancele una transacción de consignación que dejó saldo=0. Sin urgencia — el fix del #189 evita que el bug se repita; este follow-up es robustez adicional.
  • 📅 2026-06-15 Plan de modernización (futuro, no calendarizado): definir alcance, costo, ventana, qué se migra y qué se reescribe. Nota: el correo 1 abre la puerta a este trabajo; si el cliente pica, abrir pendientes específicos aquí.
  • 📅 2026-06-30 Atender los pedidos de cambios conforme lleguen (irlos documentando aquí). Recordatorio: a partir del 1-ago-2026 cualquier desarrollo nuevo se cotiza a $300 MXN/h.
telcel-jacala
telcel · active · medium 2 pendientes

🎯 Top de ataque (2)

  • #032 📅 2026-06-08 Pendiente investigar (no toqué): identificar MAC origen del broadcast con tcpdump -i switch0 -nne 'ether broadcast and src host 206.135.14.86' (NO ejecutado — solo investigación read-only en esta sesión).
  • #033 📅 2026-06-08 erx-jacala NO está en /var/lib/oxidized/router.db — si queremos backups automáticos de config, hay que darlo de alta.
vpn-clientes
electrosystems · active · medium 23 pendientes

📝 Otras (23)

  • sin fecha Definir host: VM nueva en poseidon, o servicio en reverse-proxy, o un VPS dedicado fuera de Electrosystems (mejor disponibilidad si el datacenter cae).
  • #073 📅 2026-06-02 🤖 alto Fase 0 — diseño + scaffolding del concentrador WG nuevo. No toca producción. ✅ Diseño APROBADO 2026-05-29 (las 5 decisiones cerradas) → vpn-clientes/PLAN.md. Instancia wg-cli separada en la VM wireguard; solo /32 de cada servidor, NO se rutean LANs (LAN de cliente = SSH tunnel, por LANs solapadas); subredes por función + bloque ADFSA /22; source of truth en la VM; segmentación rol-based. Todas las decisiones cerradas. Siguiente: materializar scaffolding (/etc/wireguard/wg-cli/ + 4 scripts) y lab en poseidon.
  • sin fecha Definir si es un solo concentrador o múltiples por región (mejor latencia por geografía).
  • #414 📅 2026-06-05 ⏱ 0.5d Fase 0b — lab de validación en poseidon. VM(s)/netns: 1 hub + servidores + 2 operadores; correr los tests de segmentación rol-based (operador→pool PASA, no-permitido DROP, servidor↔servidor DROP, revoke en vivo). Verde = se desbloquea #077.
  • sin fecha Definir el patrón: hub-and-spoke (operadores y servers se conectan al hub; el hub rutea), mesh (cada operador con cada cliente), o per-client subnet (un túnel por cliente, segmentación dura).
  • #077 cond:fase-0b-verde Fase 1 — piloto ARIAS (confirmado 2026-05-29). Levantar wg-cli en su server en paralelo a apolo, dar acceso a operadores (default amplio), validar conectividad + SSH tunnel a su LAN + monitoreo, soak, retirar ruta apolo.
  • sin fecha Política: un operador no debería ver hosts de un cliente con el que no trabaja. Hoy con la VPN plana de apolo cualquier operador con acceso ve toda la 10.11.0.0/16.
  • #077 sin fecha #077b Fase 2 — clientes restantes en orden de menor a mayor criticidad. ADFSA y Grupo Imperial al final (telefonía en producción).
  • sin fecha Diseño: asignar /24 (o más fino) por cliente. Routing y firewall del concentrador permiten solo a operadores autorizados llegar a la subred del cliente que les corresponde.
  • #077 sin fecha #077c Fase 3 — migración de operadores. Una vez todos los clientes están en el WG nuevo, los operadores cambian su ~/.ssh/config o equivalente para usar el nuevo VPN.
  • sin fecha Mapping de operadores a clientes: tabla de quién accede a qué. Necesita ser actualizable cuando rote personal.
  • #077 sin fecha #077d Fase 4 — apagar apolo. Solo cuando ningún operador ni ningún flujo automatizado lo necesite.
  • sin fecha Qué muestra: lista de clientes y sus hosts (con IPs en la nueva segmentación), estado de conectividad (last handshake), peers activos.
  • sin fecha Quién lo ve: Sergio + admins de Electrosystems. ¿Operadores también? Probable que sí (con vista filtrada a sus clientes asignados).
  • sin fecha Stack sugerido: SvelteKit + algo simple para la API (Laravel o Node), datos desde wg show parseado y/o desde una DB con la asignación de peers. Auth via Google Workspace OAuth (alineado con docs.* y backups.*).
  • sin fecha Hosting: detrás de reverse-proxy con TLS y allow-list LAN/VPN, igual que los demás portales.
  • sin fecha wg-create-key.sh — script para crear par de llaves nuevas + entrada en el concentrador + plantilla de config para el peer (operador o server).
  • sin fecha wg-install-key-server.sh — script para instalar la llave en un server existente del cliente (SSHea al server, instala wireguard si no está, configura el túnel, hace systemctl enable wg-quick@wg0).
  • sin fecha wg-revoke-peer.sh — script para revocar (rotación de personal, fuga de llave). Quita la llave del concentrador + opcionalmente del peer (si se puede SSHear).
  • sin fecha wg-list-peers.sh — listado plano del estado de peers para troubleshooting rápido (probablemente lo que el portal expone, en CLI).
  • sin fecha Manual del operador: cómo levantar el túnel en su máquina (Linux/Mac/Windows), cómo verificar conectividad, qué hacer si el handshake no pasa.
  • sin fecha Manual del admin: cómo agregar un cliente nuevo (subnet, peer del concentrador, server peers, mapping a operadores), cómo rotar llaves, cómo decommissionar un peer.
  • sin fecha Runbook de migración desde apolo: orden de cutover, validación por cliente, plan de rollback si algo no llega.
wireguard-jrz-elp
electrosystems · active · medium 13 pendientes

🎯 Top de ataque (13)

  • #078 📅 2026-06-05 Documentar el estado actual del enlace Juárez ↔ El Paso. ¿Qué tecnología usa hoy? ¿Cuál es el endpoint en cada lado? ¿Qué subnets enruta?
  • #078 📅 2026-06-05 Documentar el WireGuard ya existente (192.168.20.5). ¿Para qué se usa hoy? ¿Es servidor de "road warrior" (clientes remotos) o site-to-site? ¿Qué peers tiene configurados?
  • #079 📅 2026-06-08 Identificar si hay perfiles de host en ~/agy/electrosystems/servers/ para los dos endpoints del túnel actual; si no, crearlos.
  • 📅 2026-06-10 Decidir topología WireGuard:
  • 📅 2026-06-12 Plan de IPs: ¿qué subnet /24 usar para los túneles WireGuard? Mantener disjunto del rango interno actual.
  • 📅 2026-06-15 Plan de routing: ¿quién enruta qué? Si hay redes que ya están "anunciadas" por el túnel actual, mapear cada una a su AllowedIPs correspondiente del lado WireGuard.
  • 📅 2026-06-18 Plan de cutover: cómo hacer la transición sin tirar el enlace (probable: levantar WireGuard en paralelo, validar, mover rutas, retirar el viejo).
  • 📅 2026-06-20 Generar pares de llaves en cada extremo.
  • 📅 2026-06-22 Configurar wg0 en cada extremo + persistencia (systemd-networkd, wg-quick, NetworkManager — depende de la distro).
  • 📅 2026-06-24 Abrir UDP en firewalls (puerto típico 51820, o dedicado).
  • 📅 2026-06-26 Validar con ping cross-site usando rutas WireGuard.
  • 📅 2026-06-28 Cambiar las rutas internas para que prefieran WireGuard.
  • 📅 2026-06-30 Decommissionar el túnel viejo.
cobros-recurrentes
personal · active · medium 1 pendientes

🎯 Top de ataque (1)

  • #177 📅 2027-03-01 (recordatorio) Cobrar a Aarón la anualidad de hosting holbox.val-soft.com para el ciclo mayo 2027 → abril 2028 ($3,600 MXN). Antes de cobrar: validar que el costo en DigitalOcean siga en $14 USD/mes y que el TC USD/MXN no haya erosionado el margen; ajustar tarifa con aviso previo a Aarón si hace falta.
infra-updates
electrosystems · backlog · medium 10 pendientes

🎯 Top de ataque (10)

  • #113 📅 2026-06-02 Para equipos Ubiquiti blackBox (mayoría de los 354 en 10.11.30-37): qué tipo de equipo, qué firmware corre. Probable que esto requiera coordinarse con backup-system (oxidized ya tiene info de modelo en algunos).
  • #113 📅 2026-06-03 Para apps Laravel: tabla con PHP version, Laravel version, dependencias outdated (composer outdated --direct), node version, paquetes npm outdated (npm outdated).
  • #113 📅 2026-06-04 Para hipervisor (poseidon): CentOS 7 → considerar plan de migración (EOL 2024-06, ya pasado). Cross con poseidon-storage.
  • #115 📅 2026-06-05 CentOS 6 EOL → migración: orion (192.168.20.2), otrs (192.168.20.21), clientes (192.168.20.60). El "update" aquí es decom + migración a OS soportado. Coordinar con orion-decommission (que ya está activo para orion). Crear plan equivalente para otrs y clientes.
  • #115 📅 2026-06-06 CentOS 7 EOL (2024-06) → migración: poseidon (hipervisor) + jmeza (shared hosting cliente, fuera de scope). Para poseidon: cross con poseidon-storage.
  • #115 📅 2026-06-07 Sangoma 7 en PBXs cliente: auditar versiones de FreePBX y Asterisk. Capturar matriz cuando se haga el inventario A.
  • 📅 2026-06-08 MariaDB 5.5 EOL en jmeza: fuera de scope (cliente externo, shared hosting), pero documentado.
  • #420 sin fecha Página cliente-facing del estado de infra (para el jefe de Sergio): dashboard/reporte donde el jefe pueda ver el inventario de versiones + EOL + deuda técnica de este proyecto y tomar decisiones de migración. Pensado por Sergio 2026-05-29. Decisión de vehículo pendiente: (a) entregable HTML/PDF estático en deliverables/electrosystems/infra-updates/ regenerable desde estas tablas; (b) vista dedicada en el hub-web-viewer (ojo: es hub personal, requeriría auth/sección pública); (c) página propia. Recomendación inicial: empezar por (a) — un HTML con las tablas #113/#113b/#113c + semáforo EOL + "recomendación de migración", que no expone el resto del hub.
  • 📅 2026-06-08 backup-system: cuando se inventaríe firmware de Ubiquiti, alimentar pendientes ahí (oxidized + UISP).
  • 📅 2026-06-08 Cada proyecto de app Laravel (amadeus, es-antenas-new, holbox, jm-*, etc.): captura de cadencia propia de composer/npm outdated cuando se decida.
aprende-ingles
personal · active · low 5 pendientes

🎯 Top de ataque (5)

  • #405 📅 2026-06-02 ⏱ 4-6h Fase 3 del AUDIT (#205): streak con holgura + dashboard /progreso del papá. Streak freeze (1-2 congeladores/semana) + celebración fuerte de los primeros 7 días + récord personal (NO liga/leaderboard). Pantalla /progreso: palabras dominadas vs en repaso, racha, minutos esta semana vs meta, nivel CEFR estimado (Pre-A1/A1, usando datasets CEFR/NGSL locales). Los datos ya están en BD; falta la pantalla que los agregue. Resuelve eje f (métricas). Detalle en AUDIT.md §8.
  • #406 📅 2026-06-03 ⏱ 3-4h Fase 4 del AUDIT (#205): repaso priorizado por error real + anclaje de vocabulario. Pasar al LessonPlannerService "qué domina / qué falló" estructurado y repasar prerrequisitos antes de subir dificultad (mastery learning estilo Khan: +2.7% corrección del siguiente ítem). Anclar el vocab nuevo a NGSL/NDL + filtro CEFR A1/A2 (datasets locales). Mejora el motor IA existente sin rehacerlo. Detalle en AUDIT.md §8.
  • #407 📅 2026-06-04 ⏱ 1-2d Fase 5 del AUDIT (#205, stretch): producción/conversación libre. Micro-historias i+1 (la IA genera párrafos de 3-5 frases, 95-98% vocab conocido + 1-2 nuevas, con imagen) → comprensión lectora real. Mini-roleplay con IA sobre lo recién estudiado (empezar por texto, luego voz con la eval de pronunciación ya existente) + tutor socrático en errores (pista que lleva a la respuesta, no la da). El gap diferenciador que casi ninguna app casera tiene; ya hay ladrillos (IA + voz). Detalle en AUDIT.md §8.
  • #206 📅 2026-05-31 Integración aprende-ingles ↔ tareas-hijo — marcar lección diaria automáticamente. Cuando el hijo complete una LessonCompletion en aprende-ingles (Postgres en val-soft), una tarea correspondiente en tareas-hijo (Postgres en Fly.io) debería marcarse hecha automáticamente. Mecanismo posible: webhook desde aprende-ingles → endpoint Phoenix en tareas-hijo. Requiere: (a) tareas-hijo tener un endpoint público autenticado para "marcar tarea hecha por slug" (NO existe hoy — Fase 1 #184 está en bloque 1/4); (b) aprende-ingles tener un job/queue que dispatch al completar lección; (c) modelo de mapeo: en tareas-hijo, una tareas_definicion con slug='leccion-ingles-diaria' se vincula. Bloqueado por #184 Fase 1 completa de tareas-hijo (que tenga su esquema LiveView + auth). Cuando se desbloquee, decidir si la integración es push (webhook) o pull (cron en tareas-hijo consulta aprende-ingles). Estimación: chica una vez desbloqueado (1 endpoint + 1 job).
  • 📅 2026-06-01 Después (no bloqueante): rate limit del lado app en generatePlan (padre puede tirar N llamadas a OpenAI con clicks repetidos) + retry/backoff en LessonPlannerService.
docs-platform
electrosystems · active · low 5 pendientes

🎯 Top de ataque (5)

  • #106 📅 2026-06-10 Mitigar leak de procesos git zombies en Wiki.js v2. Confirmado: el módulo de git-storage acumula procesos zombie en periodos largos. Fix manual aplicado 2026-05-04 (restart). Recurre en escala de varias semanas. Opciones de mitigación:
  • #107 📅 2026-06-15 Migrar contenido activo de DokuWiki (en orion) a Wiki.js. Diferido el 2026-04-25. Importarlo como folder en Wiki.js. Bloqueador parcial: orion corre CentOS 6 EOL con root partition al 100% — coordinar con orion-decommission.
  • #108 📅 2026-06-20 Decidir destino del VM bookstack (paused, en orion). Contenido mínimo, set aside por reportes de lentitud. Confirmar salvageabilidad y borrar si no aporta. Parte del esfuerzo de orion-decommission.
  • #109 📅 2026-06-25 ACL groups + restricciones por folder en Wiki.js. Diferido el 2026-04-25 — actualmente todos los del Workspace ven y editan todo. Revisitar si surge necesidad real (ej. notas con info sensible que no deba ver todo el equipo).
  • #110 📅 2026-06-30 Migrar el remote git de Wiki.js de GitHub a Gitea/Forgejo self-hosted. Goal: docs/code en red interna con backups internos. Sin fecha. Tarea grande — requiere standup de un Gitea/Forgejo, migración de repos, ajuste de Wiki.js storage config y de los workflows de los developers.
projects-hub
electrosystems · paused · low 23 pendientes

🎯 Top de ataque (23)

  • sin fecha (sigue 2026-05-12) Seguimiento Meta Cloud API — confirmar con el trámite si hay avance / requiere acción.
  • sin fecha Visibility: ¿hace falta cuarto nivel "client-visible" para sharing externo? (probablemente no por ahora)
  • sin fecha Default OTP TTL (sugerido 5 min) y max attempts (sugerido 5).
  • sin fecha Storage watermark para prune de audio: warn al 80%, prune al 90%.
  • sin fecha Política de datos pre-Fase 2: visibilidad de PII en notas, derecho al olvido, exportación.
  • sin fecha Pruebas con 3 usuarios reales.
  • sin fecha Cambiar default del router a gemma4:26b con thinking activo (decisión de junta con jefe 2026-05-12) — aunque las respuestas tarden ~1 min por el razonamiento interno. Persistir el modelo elegido en tool_call_log.model. Mandar al usuario un ack inmediato (pensando…) para que no parezca colgado. Pre-requisitos a resolver en ia-evaluacion antes del switch: (a) validar fidelidad de function-calling de Gemma 4 contra el schema de tools, (b) política de OLLAMA_KEEP_ALIVE (la VRAM 8 GB no aguanta dos modelos a la vez), (c) decidir si se conserva Qwen 2.5 14B como fallback opcional vía prefix /fast para queries triviales.
  • sin fecha Memoria de conversación multi-turn — hoy cada mensaje se trata como aislado, el agente pierde el contexto del turno anterior. Diseño cerrado en CONVERSATION-CONTEXT.md: ventana inicial de 20 mensajes / 45 min, serialización por roles, manejo de audios pendientes, presupuesto de 6 K tokens, reglas de continuidad en el system prompt. Falta implementar build_history() en src/whatsapp/. Patch propuesto listo (agente C, sesión 2026-05-13) — archivo nuevo src/whatsapp/history.js (~80 LOC) + 4 ediciones en agent.js. No se resuelve cambiando de modelo.
  • sin fecha Heurística de resolución de contexto sin pregunta extra — cuando el último mensaje del usuario menciona algo identificable como id/slug (gustavo_chavira_mx, beta1), el agente debe vincularlo al hilo abierto en lugar de preguntar "¿qué quieres hacer con eso?". Se logra con: (a) historial conversacional (ver arriba), (b) regla en el system prompt: "si tu turno anterior fue una pregunta y el usuario responde con un valor, asume que ese valor responde a tu pregunta".
  • sin fecha SvelteKit con login OTP — auditar src/dashboard/auth/, el commit 7a5c4ec agregó edit forms pero no se documentó el login.
  • sin fecha Vista de lista de proyectos + detalle — auditar si ya está.
  • sin fecha Búsqueda — auditar.
  • sin fecha Migración Baileys → Cloud API (cuando se apruebe). Endpoint /api/meta/webhook ya tiene handshake de verificación funcionando (logs muestran 3 verificaciones exitosas).
  • sin fecha Auditar el contenido real de los recordatorios y reportes — ¿qué se manda, a quién?
  • sin fecha Sergio crea el bot en BotFather — handle elegido: ElectroIA_bot. Token va a .env como TELEGRAM_BOT_TOKEN=....
  • sin fecha Sergio reinicia el proceso del gateway en laptop-ia (kill $(pgrep -f "node.*index.js" | head -1) y volver a arrancar con el comando setsid nohup actual, o de paso meter a pm2/systemd — ver pendiente abajo).
  • sin fecha Sergio se manda un mensaje al bot desde su Telegram → el bot le devuelve su telegram_user_id → Sergio hace curl -X POST 'http://127.0.0.1:8080/api/admin/telegram-bind?identity_id=<su-slug>&telegram_user_id=<id>'.
  • sin fecha Smoke test: pedir estatus de beta1 por Telegram, verificar que llega lista completa de pendientes (la mejora de respuestas detalladas también aplica por Telegram porque reusa agent.respondTo).
  • sin fecha Fase 2 de Telegram (después de que WhatsApp esté estable): OTP cross-channel — un usuario nuevo manda /start, el bot busca identity.phone, manda OTP por WhatsApp, usuario lo confirma en Telegram. Quita el step manual de bind.
  • sin fecha Indicador "typing…" mientras el bot genera la respuesta (pedido Sergio 2026-05-14, especialmente útil con gemma4:26b thinking que puede tardar ~1 min). En Telegram: sendChatAction(chat_id, 'typing') cada ~4 s mientras respondTo corre (dura 5 s en cliente). En WhatsApp/Baileys: sock.sendPresenceUpdate('composing', remoteJid) al inicio + 'paused' al terminar — verificar primero que la sesión Baileys (cuando esté re-pareada) emita presence updates a chats 1:1. Implementación sugerida: wrapper withTyping(channel, target, fn) que arranca un setInterval antes de respondTo y lo limpia en finally. Sin tocar el agente.
  • sin fecha Re-pareo de la sesión Baileys — borrar src/whatsapp/auth/, levantar el proceso, sacar el pairing code de 8 caracteres del log, meterlo en el teléfono (Configuración → Dispositivos vinculados → Vincular con número). Esto resuelve el Bad MAC. El JID actual 5215629555094:1@s.whatsapp.net se renueva pero el historial en DB se conserva.
  • sin fecha Hardening de la config Baileys en baileys.js: syncFullHistory: false, defaultQueryTimeoutMs: 90_000, shouldIgnoreJid para LIDs no-bound, getMessage callback que consulte message_log. Reduce probabilidad de que la sesión se vuelva a corromper.
  • sin fecha Manager de procesos — pasar de setsid nohup a pm2 o systemd. Sin esto, el proceso no se recupera de crashes duros, y reiniciar manualmente requiere SSH cada vez.
poseidon-storage
electrosystems · backlog · low 2 pendientes

🎯 Top de ataque (2)

  • #122 📅 2026-06-10 Auditar qcow2 en pool default y decidir cuáles mover a home para liberar espacio. Criterio: VMs activas que pueden moverse en una ventana corta de mantenimiento. Para cada candidato:
  • #123 📅 2026-06-15 Confirmar que el pool default queda con margen razonable (≥ 30% libre) tras la limpieza.