Hub

electrosystems

projects-hub

paused low work fase: 3-aplicada / 4-y-5-parciales-no-document…
Creado
2026-04-15
Actualizado
2026-05-29
Host
laptop-ia (192.168.3.99)
Directorios
  • /home/sergio/projects-hub
  • /home/sergio/agy/projects/projects-hub

Pendientes abiertos (23)

Ver todos →

🎯 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.

Actividad en bitácora 4 días

jun
jul
ago
sep
oct
nov
dic
ene
feb
mar
abr
may
L
X
V
Menos
Más

Projects Hub

⏸️ Proyecto pausado 2026-05-14 tarde-noche. La laptop laptop-ia se dedicó 100% a electro-ia — sucesor conceptual con alcance más amplio (agente estilo Antigravity CLI corporativo). Este README se conserva intacto como referencia histórica. El estado en disco está preservado: PID matado limpiamente con SIGTERM; repo ~/projects-hub/ y DB projhub siguen en laptop-ia para consulta o reactivación futura.

Contexto

Sistema interno de Electrosystems para tener un único lugar donde quede toda la información de proyectos de la empresa: estado, decisiones, pendientes, contactos, archivos y conversaciones. Consultable y actualizable principalmente por WhatsApp (texto y audio), con dashboard web opcional. Pensado para 15 usuarios y hasta 5 proyectos activos en paralelo. Corre en laptop-ia.

Documento maestro: PLAN.md. Schema: SCHEMA.md. Hoja técnica del stack: STACK.md.

Estado actual (2026-05-14)

  • Fase 0 (diseño): completada salvo aprobación de Meta Cloud API (trámite desde 2026-05-05). El código ya tiene el endpoint /api/meta/webhook listo para handshake de verificación (commit del scheduler audit, observado en logs meta webhook verified × 3).
  • Fase 1 (infra básica en laptop-ia): completada 2026-05-06.
  • Fase 2 (pipeline mínimo end-to-end): completada 2026-05-06.
  • Fase 3 (agente con tools): aplicada en producción 2026-05-14 — los 12 tools, OTP onboarding y RBAC ya estaban. Los cambios de “respuestas más completas” del 2026-05-13 (MAX_REPLY_CHARS 1500→4000, system prompt actualizado, getProject con pending/pending_count estructurado) se commitearon hoy en b155bbc. Falta del pipeline: build_history() (multi-turn), heurística de resolución de contexto, switch a Gemma 4 thinking. Pruebas con 3 usuarios reales sin avance porque el canal está roto (ver más abajo).
  • Fase 4 (dashboard de lectura): parcialmente hecha sin documentar — commit 7a5c4ec (anterior a este README) implementa edit forms en el dashboard SvelteKit para note/status/pending/decision/contact. Vista de lista + búsqueda no auditadas todavía. Pendiente auditar src/dashboard/ con calma.
  • Fase 5 (onboarding/refinamiento): parcialmente hecha — commit 65dd752 agrega scheduler con weekly_reminders (Mon 09:00 TZ Ciudad_Juarez) + activity_report (Mon 09:30). Endpoint admin /api/admin/scheduler-run?job= para forzar manualmente. Tabla scheduler_run para dedup. Confirmado corriendo en logs: scheduler tick installed.
  • Fase 6 (Telegram, NUEVA 2026-05-14): gateway paralelo implementado y committeado en 18e5e40. Falta token de BotFather + bind del primer usuario + reinicio del proceso.

⚠️ Estado operacional del canal WhatsApp (2026-05-14)

Roto desde 2026-05-12 17:06. Diagnóstico en bitácora 2026-05-14 abajo. Resumen:

  • wa_connected:true pero 0 mensajes procesados en las últimas 48 h.
  • Causa raíz: Bad MAC / No matching sessions en la sesión Signal local — se desincronizó. WhatsApp Server cierra el stream cada ~1 h con reason 428/503.
  • 54 ciclos de reconexión + 11 crashes del handler + 7 errores de descifrado.
  • Fix requiere participación del usuario: borrar src/whatsapp/auth/, re-parear con la eSIM vía requestPairingCode, meter el código de 8 caracteres en el teléfono. Después: hardening de la config Baileys (syncFullHistory:false, defaultQueryTimeoutMs, getMessage callback).
  • Telegram se priorizó como canal alternativo estable mientras tanto.

Tareas pendientes

Fase 0 (diseño/trámites)

  • 📅 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.

Fase 3 (agente con tools)

  • (verificado 2026-05-13) Catálogo de tools — excede lo planeado: 12 tools en src/whatsapp/tools.js (los 6 originales create_project, list_projects, get_project, add_note, search, whoami + update_status, add_pending, complete_pending, add_decision, add_contact, register_user).
  • (verificado 2026-05-13) Identidad por OTP en el primer contacto — src/whatsapp/onboarding.js (173 LOC), máquina de estados await_phone → await_otp, hash SHA-256, TTL 5 min, 5 intentos. Tablas en sql/0003_onboarding.sql.
  • (verificado 2026-05-13) RBAC enforcement por tool — canRead/canWrite en projects.js, register_user/add_decision checan rol admin/pm explícitamente. Cada tool decide en su handler; tool_call_log guarda acl_decision.
  • (2026-05-14, committed b155bbc) Respuestas más completas al exponer info de proyectos — MAX_REPLY_CHARS: 1500 → 4000, system prompt actualizado, getProject con pending/pending_count. Smoke test contra beta1 pasó. Falta: reinicio del gateway en producción para que tome los cambios.
  • 📅 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”.

Fase 4 (dashboard)

  • 📅 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.
  • Edit forms note/status/pending/decision/contact (commit 7a5c4ec 2026-05-08).

Fase 5 (onboarding/refinamiento)

  • 📅 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).
  • (commit 7a5c4ec) Edición desde dashboard.
  • (commit 65dd752) Recordatorios automáticos (lunes 09:00 TZ Ciudad_Juarez, scheduler.js runReminders).
  • (commit 65dd752) Reportes semanales generados por el agente (lunes 09:30, runWeeklyReport).
  • 📅 sin-fecha — Auditar el contenido real de los recordatorios y reportes — ¿qué se manda, a quién?

Fase 6 (Telegram — NUEVA 2026-05-14)

  • Migración SQL sql/0006_telegram.sql aplicada en projhub 2026-05-14 — identity.telegram_user_id UNIQUE, message_log.from_telegram_user_id/to_telegram_user_id, channel CHECK ampliado.
  • src/telegram/index.js (314 LOC) — Bot API por fetch nativo, long polling, sendMessage con chunking 4 KB, getFile + descarga de voice/audio, handler idempotente.
  • identity.lookupByTelegramUserId / bindTelegramUserId y db.insertInboundTelegram / insertOutboundTelegram.
  • transcribe.transcribeBuffer — pipeline Whisper agnóstico de canal.
  • Wiring en src/whatsapp/index.js: startTelegram() después de Baileys, /api/health expone bot, nuevo endpoint admin POST /api/admin/telegram-bind?identity_id=&telegram_user_id= (localhost only).
  • .env.example actualizado.
  • 📅 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.

Estabilizar WhatsApp (urgente, requiere participación de Sergio)

  • 📅 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.

En progreso

  • Estabilizar WhatsApp — Bad MAC desde 2026-05-12, requiere re-pareo de la sesión.
  • Fase 6 (Telegram) — código en main (18e5e40), falta token + reinicio + bind.
  • Auditar Fases 4 y 5 — varias cosas ya están en código pero no documentadas.

Notas técnicas

Stack

  • Host único: laptop-ia (Ubuntu 24.04, i9-13900HX, 62 GB RAM, RTX 4060 Mobile, 1.5 TB NVMe).
  • DB: PostgreSQL 16 + pgvector. Schema y tablas en SCHEMA.md §3.
  • Embeddings: bge-m3 (1024 dims) vía Ollama. Decisión cerrada — cambiar implica re-embedding completo.
  • LLM local: Hermes 3 8B / Qwen 2.5 14B Instruct vía Ollama.
  • LLM nube: Antigravity API (Sonnet 4.6) con prompt cache para consultas complejas.
  • Transcripción: faster-whisper large-v3 en CUDA (RTX 4060 Mobile). Latencia ~0.5x del audio.
  • Gateway WhatsApp: Baileys directo en Node.js (src/whatsapp/) — no oficial pero controlado, ~250 LOC. eSIM dedicada (no es la línea personal de nadie). Migración planeada a Meta Cloud API cuando aprueben (~1 día reescribir el adaptador).
  • Dashboard: SvelteKit + Tailwind, login por OTP de WhatsApp.
  • Exposición pública: vía reverse-proxy VM (192.168.20.14, IP pública estática 201.218.172.3) con vhost nginx proyectos.electrosystemsnet.com. DNS estático en Oracle Cloud DNS. Reservación DHCP por MAC mantiene la laptop en 192.168.3.99.

Detalles Mexico-específicos

  • WhatsApp registra móviles MX con prefijo legacy +52 1 .... JID actual: 5215629555094:1@s.whatsapp.net.
  • Variable WHATSAPP_PHONE_NUMBER debe estar en formato 5215... para que requestPairingCode funcione.
  • TZ de la empresa: America/Ciudad_Juarez.

Decisiones cerradas

  • Roles: admin, pm, engineer. Más se pueden agregar sin migración.
  • Visibility: public | internal | restricted. Allow-list explícita en restricted.
  • Embedding model: bge-m3 1024 dims.
  • Audio retention: indefinido, prune al llenarse.
  • TZ: America/Ciudad_Juarez.

Ver también

  • PLAN.md — documento maestro completo (en español).
  • SCHEMA.md — schema técnico completo (campos, roles, tools, tablas Postgres, convenciones — en inglés porque vive en código).

Bitácora

2026-05-14 (tarde — sesión Telegram + diagnóstico WA)

  • Pidió Sergio: avanzar con pendientes; agregar integración Telegram; verificar primero que el servicio esté corriendo bien porque tras pruebas con su jefe sospecha que no funciona como se dejó.
  • Diagnóstico (read-only por SSH a laptop-ia):
    • Gateway WhatsApp :8080 corriendo (PID 216112, setsid nohup), /api/health → {ok:true, wa_connected:true}. Pero el último mensaje procesado en message_log fue el 2026-05-12 17:06 — ~48 h sin un solo in ni out.
    • Log: 247 connection closed vs 54 connection open, reason mayoritario 428 (Connection Terminated) y 503 (stream errored out). 54 init queries timeout en fetchProps. 7 failed to decrypt message (Bad MAC / No matching sessions) desde 2026-05-12 21:47 — la sesión Signal local quedó desincronizada con el server. 11 message handler threw.
    • Conclusión: bot zombie (socket abierto, no procesa). Fix limpio = re-pareo + hardening Baileys; aplazado a próxima sesión porque requiere meter el pairing code en el teléfono.
  • Hice (1) — commit del working tree pendiente del 2026-05-13: b155bbc feat(agent): respuestas detalladas en info de proyecto + pending estructurado en get_project. MAX_REPLY_CHARS 1500→4000, system prompt actualizado, getProject con pending[]/pending_count. Sin reiniciar el servicio aún (decisión de Sergio).
  • Hice (2) — gateway Telegram completo, commit 18e5e40:
    • Migración sql/0006_telegram.sql aplicada en projhub: identity.telegram_user_id UNIQUE, columnas from_telegram_user_id/to_telegram_user_id en message_log, CHECK ampliado con 'telegram'.
    • src/telegram/index.js nuevo (314 LOC) — Bot API por fetch nativo (cero deps externas), long polling con back-off exponencial, sendMessage con chunking 4 KB, descarga de voice/audio vía getFile, handler idempotente con id='tg-<chat>-<msg>'.
    • Helpers nuevos: identity.lookupByTelegramUserId + bindTelegramUserId (detecta colisión con otra identidad), db.insertInboundTelegram + insertOutboundTelegram, transcribe.transcribeBuffer (pipeline agnóstico de canal — processAudio para Baileys queda intacto).
    • Wiring en src/whatsapp/index.js: startTelegram() después de Baileys, /api/health expone telegram_bot, nuevo endpoint admin POST /api/admin/telegram-bind?identity_id=&telegram_user_id= (localhost only) para vincular sin SQL.
    • .env.example: TELEGRAM_BOT_TOKEN=<from-BotFather>. Bot handle elegido: ElectroIA_bot.
  • Onboarding Telegram Fase 1 (decidido en sesión): manual. Usuario nuevo recibe su numeric telegram_user_id; Sergio lo vincula vía curl o SQL. Fase 2 (OTP cross-channel por WhatsApp) queda para cuando WhatsApp esté estable.
  • Hallazgos colaterales (Fases 4–5 ya parcialmente hechas y NO documentadas):
    • Commit 65dd752 agrega scheduler con weekly_reminders (Mon 09:00 TZ Ciudad_Juarez) + activity_report (Mon 09:30); endpoint admin /api/admin/scheduler-run?job= para forzar manualmente; tabla scheduler_run para dedup. Confirmado corriendo (scheduler tick installed en log).
    • Commit 7a5c4ec agrega edit forms para note/status/pending/decision/contact en el dashboard SvelteKit.
    • Endpoint /api/meta/webhook ya hace handshake de verificación de Meta Cloud API (3 verificaciones exitosas en log).
  • Falta del lado de Sergio (orden sugerido para la próxima sesión):
    1. Crear bot en BotFather con handle ElectroIA_bot, copiar el token.
    2. Editar .env en laptop-ia y agregar TELEGRAM_BOT_TOKEN=<token>.
    3. Reiniciar el proceso del gateway (matar PID actual y volver a arrancar con el mismo comando setsid nohup node --env-file=../../.env index.js).
    4. Mandar mensaje al bot desde su Telegram → bot devuelve el telegram_user_id.
    5. Vincular: curl -X POST 'http://127.0.0.1:8080/api/admin/telegram-bind?identity_id=sergio_valencia_mx&telegram_user_id=<id>'.
    6. Smoke test: pedir estatus de beta1 por Telegram (debe llegar lista completa de pendientes, porque la mejora de respuestas detalladas aplica también a Telegram).
    7. Después: atacar el re-pareo de WhatsApp + hardening Baileys + manager de procesos pm2/systemd.

2026-05-14 (mañana — pendientes administrativos previos)

  • Pidió Sergio: avanzar con los pendientes administrativos del hub.
  • Hice: aplicados los 4 pendientes faltantes a ~/projects-hub/projects/beta1/README.md en laptop-ia (emails, llamadas Asterisk, Telegram, ampliar alcance) — el quinto, Excel, ya estaba como pending desde 2026-05-12. Commit quirúrgico 24e4259 (“beta1: 4 pendientes nuevos…”) pusheado a electrosystems-mx/proyectos sin correr 30-git-autopush.sh para no arrastrar los cambios uncommitted en src/whatsapp/agent.js + projects.js (los de “respuestas más completas” del 2026-05-13 que Sergio aún estaba probando — committeados en la sesión tarde como b155bbc).

2026-05-13

  • Pidió Sergio: avanzar en pendientes de pipeline de Fase 3 (en paralelo con otras tareas).
  • Hice (auditoría — agente C): SSH a laptop-ia, leí src/whatsapp/{agent,tools,projects,onboarding,index}.js. Confirmé que el README estaba desactualizado: 12 tools ya implementadas, OTP completo, RBAC completo. Lo único pendiente del pipeline son los tres items de comportamiento (respuestas completas, build_history, heurística de contexto) + switch a Gemma + pruebas con 3 usuarios reales.
  • Hice (implementación — agente Y): apliqué “respuestas más completas” en working tree de laptop-ia (no committeado): MAX_REPLY_CHARS 1500 → 4000, system prompt sin “respuestas breves 1-3 oraciones”, getProject ahora estructura pending/pending_count. Smoke test contra beta1 pasó (pending_count=2, pending[0] bien formado).
  • Falta: Sergio identifica el manager del servicio (pm2/systemd/tmux no aparecieron en sesión SSH del agente) y reinicia. Después: validar en producción que las respuestas detalladas se ven bien en WhatsApp.
  • Siguiente del pipeline: build_history() — diseño cerrado en CONVERSATION-CONTEXT.md, patch redactado por agente C pero no aplicado. Mismo PR debe agregar el bloque “Conversation continuity” al system prompt (resuelve también la heurística de resolución de contexto).

2026-05-12

  • Pidió Sergio (1): una hoja de presentación técnica del stack con flujo end-to-end (mensaje → respuesta), directorios en laptop-ia, herramientas y versiones.
  • Hice (1): redacté STACK.md consolidando lo de PLAN.md, SCHEMA.md y los fixes.md del host. Incluye topología, hardware, tabla de versiones, modelos IA, layout en disco, flujo en 8 pasos con latencias, backups, seguridad y estado por fases. Enlazado desde este README.
  • Pidió Sergio (2): instalar Gemma 4 a petición del jefe (para evaluar capacidades a futuro, más allá del agente de WhatsApp). Sólo local, nada cloud. Elegimos la variante MoE.
  • Hice (2): ollama pull gemma4:26b en laptop-ia vía tmux. Modelo de 25.8B params (A4B MoE), Q4_K_M, contexto 256K, capabilities completion+vision+tools+thinking, Apache 2.0. Smoke test en español: 13.67 tok/s de generación con thinking activo → ~65 s para una respuesta de 4 oraciones (gasta ~840 tokens internos en razonar). Calidad de respuesta correcta. Detalle técnico completo en ~/agy/electrosystems/servers/laptop-ia/fixes.md entrada 2026-05-12.
  • Lectura: no reemplaza a qwen2.5:14b-instruct para el agente de WhatsApp (latencia muy alta por el thinking). Sí es candidato sólido para cargas async/batch donde la calidad importa más que el tiempo. Falta evaluar visión (es multimodal) y modo sin thinking si se puede desactivar.
  • Pidió Sergio (3): abrir proyecto separado para futuras pruebas de modelos + agregar como tarea concreta de Fase 3 el switch Qwen↔Gemma por prefix en el router del agente.
  • Hice (3): creado ia-evaluacion con frontmatter, tareas, tabla de modelos evaluados y techo de hardware. _INDEX actualizado. Agregada tarea de switch de modelo en Fase 3 de este README con sus tres pre-requisitos (apagar thinking, validar tools, política de KEEP_ALIVE).
  • Pidió Sergio (4) — post-junta con jefe (PM): que el agente de WhatsApp use gemma4:26b con thinking activo como modelo default, aceptando explícitamente la latencia (~1 min por respuesta).
  • Hice (4): revertí la tarea anterior de “switch por prefix” — ahora Gemma 4 thinking es el default. Qwen 2.5 14B queda como posible fallback vía prefix /fast (a decidir).
  • Pidió Sergio (5) — observaciones de pruebas en la junta: dos defectos concretos:
    • Pérdida de contexto entre turnos. Ejemplos reproducidos:
      • “Crea un usuario con nombre Gustavo Chavira…” → IA pide id → Sergio: gustavo_chavira_mx → IA: “¿qué quieres hacer con gustavo_chavira_mx?” (perdió el turno previo).
      • “Pendientes de Beta 1” → IA pide slug → Sergio: beta1 → IA confirma → Sergio: “dame toda la info” → IA: “¿de cuál de estos cuatro proyectos?” (volvió a pedir slug).
    • Respuestas demasiado breves al mostrar info de proyectos. Pediste estatus de beta1 y la IA contestó tres oraciones, sin lista de pendientes, sin cuentas, sin detalle.
  • Lectura técnica (5): ninguno de estos dos problemas se arregla cambiando el modelo a Gemma. Son problemas del pipeline: no se le pasa historial de la conversación al LLM, y el tool get_project no devuelve la info completa. Lo apunté como tres tareas separadas en Fase 3 (memoria multi-turn, respuestas más completas, heurística de resolución de contexto).
  • Pidió Sergio (6) — pendientes nuevos para el proyecto beta1 (vive en el hub remoto, ~/projects-hub/projects/beta1/ en laptop-ia, no aquí):
    • Enviar y recibir emails.
    • Recibir llamadas telefónicas y contestar contra un servidor Asterisk.
    • Conectar con Telegram.
    • Analizar archivos tipo Excel.
    • Ampliar alcance a más que solo manejo de proyectos.
  • Hice (6): registré los 5 items aquí — no los agregué al projects/beta1/README.md remoto porque (a) los tools del agente no existen aún en Fase 3 y (b) el flujo correcto del hub es vía add_pending. Pendiente de aplicar manualmente vía SSH o esperar a que esté el agente. Ver tarea administrativa abajo.
  • Pidió Sergio (7): diseñar el formato exacto del historial conversacional que se pasa al prompt — cuántos turnos, cómo se serializan, qué hacer con audios.
  • Hice (7): creado CONVERSATION-CONTEXT.md. Cubre: ventana inicial 20 mensajes / 45 min (ampliada desde 10/20 a petición de Sergio para tener más margen las primeras semanas) con excepción para conservar el último turno, query SQL, serialización por role, 4 escenarios para audios (con/sin/fallida transcripción), agrupación de mensajes consecutivos del mismo lado, presupuesto de 6 K tokens, reglas de continuidad para el system prompt (en inglés), tratamiento de tool calls previas (no se inyectan, salvo si fallaron), pseudocódigo de build_history(), persistencia para debug en tool_call_log.input.history, batería de 7 casos de prueba que deben pasar, y 3 abiertos.

2026-05-08

  • Pidió Sergio: centralizar pendientes en ~/agy/ y dejar ~/agy/electrosystems/ solo para docs de servidores.
  • Hice: migré ~/agy/electrosystems/projects-hub/PLAN.md y SCHEMA.md a ~/agy/projects/projects-hub/. Creé este README.md como entry-point con frontmatter, status, tareas y bitácora.
  • Falta: borrar ~/agy/electrosystems/projects-hub/ original.

Histórico (compactado de PLAN.md)

  • 2026-04-15 — Inicio del proyecto.
  • 2026-05-05 — Decisiones cerradas (roles, TZ, embedding model, retención de audio). Inicio del trámite Meta Cloud API. Provisión de eSIM en curso.
  • 2026-05-06 — Fase 1 + Fase 2 completadas en laptop-ia. Postgres+pgvector, Ollama, faster-whisper, gateway Baileys pareado, transcripción local funcionando, vhost proyectos.electrosystemsnet.com con TLS válido. (Evolution API se intentó primero pero no pareó en el setup; ver electrosystems/servers/laptop-ia/fixes.md 2026-05-06.)