[Rafa-Innerchispa]

Problema real

El 22-oct-2026 Intel y AMD perdieron simultáneamente sus sesiones Evolution/WhatsApp (408). El aviso de autorización no alcanzó al dueño porque notify_ops_owner_authorization_request retornaba antes del fallback SMTP; ese fix pertenece al PR #210, que debe integrarse por separado. El owner requiere aprobación rápida y autenticada desde Android, sin depender de WhatsApp.

Qué implementa este PR (fase 1)

• owner_multichannel.py: tipos validados de solicitud, enlaces de visualización HTTPS por ops_task exacta, notificaciones accionables ntfy autohospedado (view, sin llamadas HTTP mutantes), aviso de bot Telegram con botones que abren página HTTPS, y senders transport-only con timeout y estado provider_accepted.
• Fail-closed: rechaza origen no HTTPS, IDs incorrectos o vencidos, topics mal formados; sin credenciales no realiza envío; errores no vuelcan secrets; no ejecuta ni autoriza tareas desde botones, token de proveedor o URLs.
• docs/OWNER_APPROVAL_CHANNELS.md: arquitectura del inbox/autorización única, ntfy/F-Droid directo sin FCM, Telegram secundario, SMTP paralelo/fallback, WebAuthn/passkeys y auditoría/CAS; requisitos de pruebas móviles y seguridad.
• test_owner_multichannel.py: 17 passed en AMD con HTTP simulado. No se enviaron push ni Telegram reales.

Dependencias para la fase 2 y aceptación real

1. Crear API/página HTTPS de aprobación con owner login y passkeys/WebAuthn + user verification, challenge antireplay y registro de decisiones en único flujo Temporal/Mongo (issue canónica Owner approval UX: implement reusable scoped grants instead of per-task reapproval #180). Las URLs del PR aún no apuntan a un endpoint desplegado; jamás aceptarlas como concesión.
2. Aprovisionar ntfy en host con capacidad (AMD al 94% disco, no añadir carga sin resolver), TLS/ACL deny-all y credenciales privadas; vincular Android F-Droid y prueba real con Wi-Fi desconectada/bloqueo de pantalla. Registrar device_id sin exponer secretos.
3. Crear bot con BotFather y vincular por chat ID autorizado; recepción de callbacks nunca puede aprobar tareas físicas/financieras/de pago sin confirmación de passkey.
4. Outbox durable multicanal con dedupe por request_id/channel, recibos separados de entrega/lectura/decisión, escalado push→Telegram+SMTP, y canary E2E con 2 solicitudes ficticias. No reemplazar scheduler existente.
5. Integrar PR fix(P0): proteger autorizaciones WhatsApp y aislamiento Mongo de Temporal #210 de correo seguro, revisión independiente y reactivar ruleset main (issue [P0] Reactivar protección de main para integrar AG-60 (PR #197) #204), después despliegue gobernado.

Estado exacto: código del transporte aprobado en 17 tests locales, no servicio instalado, no bot provisionado, no teléfono emparejado, no envío real ni autorización productiva. Sin gasto de Cursor/Codex, reinicios o cambios de red.

[Rafa-Innerchispa]

22-oct-2026 | Router adicional publicado, HEAD 7adf07dda51d8a566a5068ffa8f87289b9bbe89d

Segundo módulo sobre PR #212, platform/inneros_core_runtime/notifications/owner_notification_router.py, con prioridad EXACTA solicitada por propietario push → WhatsApp → Telegram → correo, control de tipo de evento (approval, incident, report, task_status, test_result, service_health, opportunity, digest, other), preferencias de canal/categoría habilitadas por defecto, conservación de alertas críticas/aprobaciones y distinción tajante entre silenciar aviso y pausar tarea. Si el envío falla, prueba canal siguiente. Si evento high/critical/approval tiene aceptación de proveedor pero no confirmación del dueño, escalamiento al siguiente canal tras 120s. No identifica provider_accepted como entregado, leído ni aprobado. Evidencia: tests locales 32 passed sobre transports + router; CI GitHub del HEAD nueva ejecución en curso al registrar. El router es puro/injectable; NO hay worker outbox ni entrega automática productiva. Si todos los canales fallan preserva estado exhausted que debe conservarse y reintentarse desde almacenamiento duradero.

Integración FASE 2 imprescindible: conectarlo a fuentes ya existentes (checkpoint OPS, coordination_alerts, reports AG-60, test_results, incidentes, email_ops, OpportunityOps) mediante un solo outbox persistente y worker del sistema, idempotencia event_id/channel, reintentos y persistencia CAS; backend seguro WebAuthn/passkeys y botones de pausa/reanudación/confirmación sobre tarea canónica con Temporal, sin comandos operativos directos desde push/Telegram/email. No generar un segundo scheduler; controlar volumen con preferencia categoría, digests/batching sin perder eventos. No desplegar hasta probar con móvil y SMTP fallback. Issue #180 centraliza UX/grants; issue #204 main protection; PR #210 email fallback necesita fusión. AG-60 #197 independiente, su task ops_0784065f1fb1 aún awaiting_antigravity_claim por binding inconsistente.