[Rafa-Innerchispa]

Objetivo

Reparación de producción para el mismo frente InnerOS/AG-60, coordinado con ops_0784065f1fb1, PR #197 e issues #193/#204. Reproduje las fallas en rama limpia del main actual antes de modificar código. Sin agentes externos de pago.

Bugs reales corregidos

1. ops_whatsapp_owner: si varias autorizaciones están pendientes, una respuesta 1/2 no puede aprobar por error la última tarea. Requiere un único pendiente válido o un botón/ID exacto.
2. Cancelar mediante WhatsApp solicita cancelación en Temporal y guarda metadata de solicitud, pero no comunica 'Acción cancelada' antes de confirmación en la proyección. Conserva pendiente y marca cancel_requested hasta que existe estado terminal. Una solicitud de cancelación bloquea posteriores intentos de autorizar la misma tarea.
3. notifications/ops_task_alerts: no duplica una notificación si la tarea ya tiene un desafío de aprobación pendiente en Mongo. Añade resend_ops_owner_authorization(task_id) para reenviar solo una tarea existente y no terminal, sin crear tareas ni eludir identificación exacta.
4. temporal_activities._mongo_projection_client: respeta la base INNEROS_MONGO_DB para canaries aislados y preserva el nombre productivo habitual si no existe override, evitando escribir evidencias de prueba en la base productiva.
5. Agrego platform/tests/probe_owner_whatsapp_readonly.py, probe explícito que solo consulta estado de Evolution API y no envía WhatsApps ni muestra números/secretos.

Evidencia ejecutada localmente en AMD, 21 oct 2026

• Baseline pre-fix sobre main: 5 fallos WhatsApp en test_ops_whatsapp_authorization_flow.py; un test adicional de aislamiento Temporal falló por no incluir INNEROS_MONGO_DB en temporal_activities.py.
• 66 passed en 12 archivos de autorización, Temporal, coordinación y ciclo OPS.
• 56 passed en pruebas adicionales AG-60, autorización de acciones en host, gobernanza, deployment y servicios.
• Read-only WhatsApp preflight: 1 passed. Evolution Intel principal: API up, conectado; AMD secundario: API up, sesión desconectada; destinatario de alertas configurado. No se envió mensaje.
• Un test heredado test_temporal_ops_engine.py sigue sin recolectar por importar AgentState/_build_langgraph_agent de un módulo que ya no los exporta. Requiere migrar esa prueba al contrato actual, sin afirmar que el runtime productivo está roto por ello.

Release gate

NO auto-merge: main sigue protected=false, ruleset #24944199 disabled (#204). Exigir revisión humana y checks reales. Antes del deployment, validar hash activo de MCP/Temporal, timer AG-60, ruta de confirmación WhatsApp extremo a extremo mediante tarea inocua con propietario autenticado, rollback y canary orden→ejecución→evidencia→cierre. Cualquier cambio productivo de red/equipos/servicios necesita autorización concreta del propietario por la ruta gobernada.

Código construido en worktree aislado desde main SHA d9eee4cfcc6ca680e4ca093c8b9ff9d567178c26, commit 00fe937c. Este PR no despliega ni envía mensajes WhatsApp.

[Rafa-Innerchispa]

P0 real detectado el 22-oct-2026: ambos WhatsApp desconectados y sin email de autorización

Evidencia de proveedor (lectura Evolution real desde AMD, 22-oct 20:52 Ecuador): Intel/RalphiIA-pcdoctor api_up=true, connected=false; AMD/Innerchispa api_up=true, connected=false. Evolución reportó cierres code 408 de ambos a 2026-10-22T23:24:08Z y una alerta adicional Intel 2026-10-23T00:56:50Z. Ya existen correos QR enviados con SMTP aceptado hacia el Gmail del owner, pero ninguno para autorizar la reparación del disco.

Causa raíz de ausencia de fallback: notify_ops_owner_authorization_request hacía return skipped=evolution_whatsapp_down ANTES de _notify_ops_auth_email_fallback. Y notify_cursor_awaiting_claim no tenía fallback SMTP. El mensaje interno a RalfIA msg_d486c9b11dc713ce quedó OPEN, NO se procesó como envío WhatsApp/email. La tarea de disco existente ops_f9983b081feb está BLOCKED; no hubo generación de solicitud automática de aprobación.

Parche commit 77887ba8d01181654c0b912390d9da6f3825b8f2 en esta misma rama: conserva controles anti-spam y síntesis de tarea, verifica conectividad WA sin retorno prematuro, falla hacia correo cuando ambas sesiones están caídas o el envío WA falla, también en awaiting_claim y alertas internas urgentes; no presenta replies de email como aprobaciones automáticas; no autoriza gastos externos, no reinicia Evolution, no borra datos. 83 pruebas locales focalizadas de autorización/Temporal/AG-60 PASS, incluyendo 3 nuevas para email y la ruta awaiting_claim; probe de configuración real informa email fallback habilitado y destinatario existente sin revelar dirección/secretos. Se corrigieron tests que asumían WA conectado en el mundo real.

Mitigación operativa ya REALIZADA: se envió correo informativo único desde rlopez@pcdoctor.com.ec a la bandeja verificada de Gmail del owner, subject [P0 InnerOS] WhatsApp desconectado en Intel y AMD | Disco AMD 94% | Acción pendiente. SMTP ACCEPTED, message_id=<179272040085.817961.5432804754480737384@pcdoctor.com.ec>, IMAP append appended y Gmail confirmó INBOX / UNREAD. No equivalió a autorización de limpieza ni ejecución de Cursor.

Faltan para PROD: checks CI del HEAD, revisión independiente y fusión protegida (main protected=false, ruleset #24944199 disabled, issue #204), despliegue SHA-pinned, prueba real de pipeline automático task→WA o email y ticket dedup. WhatsApp requiere reemparejamiento por QR desde el móvil. NO reportar reparación desplegada por hecho de este PR.