Menú Correo del workspace · plan F0

Menú Correo del workspace · F0 + F1 + F2

Nacido del grill del 12-08-2026 (Edu + Claude). Estado: F0, F1 y F2 EN PROD desde el 12-08-2026 (PRs #154 y #155 del workspace + claude-method c88e605→4c00940). Apuesta #9 en WAGERS.md gobierna si se sigue invirtiendo (evalúa el 31-08).

Qué es

El menú “Correo” del workspace: la secretaria del buzón Zoho de cada miembro (skill /correo) publica su informe periódico, conversa sobre él y atiende encargos. No sustituye al cliente de Zoho: es la capa de criterio encima del buzón.

Las tres capas

• F0 · el informe: la pasada desatendida (claude -p en el PC del miembro, tarea CreaRack-Correo-Pass 8/13/18) publica actúa/entérate/ruido a correo_digests vía POST /api/correo/digest (Bearer personal + service token CF Access — credenciales que ya tenían los 3 PCs). La página /correo y el pill de cabecera (junto al de servicios; el bento del dashboard no cabía y se reubicó el mismo día) lo pintan. Urgencias → alerta general del WS.
• F1 · el chat (POST /api/correo/ask + panel “Pregúntale” en /correo): Gemma 4 con decodificación restringida (responder/buscar/leer, máx 3 rondas — sin function-calling nativo en AI Studio) sobre el último informe + el buzón en vivo con el OAuth per-user de Zoho (s68). Cuerpos al navegador, jamás a D1. Conversación efímera; telemetría en correo_chat_queries (rate-limit + dato de la apuesta #9). Solo navegador (identidad CF Access).
• F2 · las peticiones (/api/correo/peticiones + panel “Peticiones”): el miembro encola encargos; la siguiente pasada los atiende (≤5/pasada) — borradores con deep-link a Zoho compose, movimientos (la petición es la autorización), análisis. El envío es SIEMPRE manual (grill Q8); el envío directo con toggle per-member quedó diseñado pero NO construido — activarlo será re-auth de Zoho con scope de envío + endpoint + toggle, sin rediseño.

Privacidad (decisiones del grill)

En D1 nunca hay cuerpos de mensajes: el informe guarda remitente + asunto + “por qué importa” + enlace; el chat trae cuerpos en vivo solo al navegador; las conversaciones no se persisten. Cada miembro ve exclusivamente lo suyo (scoping por identidad en todos los endpoints; los tokens de servicio no pueden publicar ni leer informes).

Verificación (12-08-2026)

• F0: pasada real (3 correos → informe publicado → GET ok) + camino de alarma con informe sintético (alerta creada, limpiada, estado repuesto).
• F2: petición real #1 (“¿cuántos correos hoy en Infra?”) atendida por una pasada real con respuesta correcta contra el buzón real.
• F1: mecanismo desplegado y verificado en build/CI; estreno en navegador pendiente del primer uso de Edu (es solo-navegador por diseño).

Pendiente

• Activación en Dani y Txell (task #220 del Gestor, sept, enganchada al plan de onboarding nuevo de Edu).
• Envío directo (toggle) — solo si el uso lo pide y con decisión explícita.
• Apuesta #9: ≥3 días de uso del chat + ≥2 peticiones atendidas para el 31-08, o F3+ se congela.