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 -pen el PC del miembro, tareaCreaRack-Correo-Pass8/13/18) publica actúa/entérate/ruido acorreo_digestsvíaPOST /api/correo/digest(Bearer personal + service token CF Access — credenciales que ya tenían los 3 PCs). La página/correoy 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 encorreo_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.
Referenciado desde
- Componente CorreoPage — página /correo completa
- Decisión: Correo — no guardar cuerpos de mensajes
- Endpoint /api/correo/digest — GET/POST informe de correo
- Estación compartida de Dani y Txell · decisiones y plan de onboarding
- Página y widget /correo (UI)
- Setup de equipo nuevo desde cero
- Tabla D1 correo_digests
- Widget CorreoWidget — resumen compacto en dashboard