Hedy conduce la release semanal: fechas límite de merge reclamadas, checklists confirmadas, avisos redactados — con cada paso hacia el exterior a la espera de una aprobación humana. Los trabajos programados deben nombrar su destino de entrega de forma explícita.
Hedy ejecuta la gestión de releases como un único empleado de IA privado, no otro puesto en Slack. Rastrea las fechas límite de cierre y los elementos de la checklist, mantiene todas las notas de versión salientes y los avisos a clientes detrás de la aprobación L0/L1/L2, y escribe cada resultado entregado en un libro. Los recordatorios cron declaran un canal de destino explícito—nunca el «último canal usado». Self-hosted en su propia infraestructura Docker/K8s o air-gapped (aislado de red), con auditoría append-only y escrituras que deniegan por defecto.
Última actualización: 20 de julio de 2026
Conoce el calendario del tren y los cierres de merge; recuerda a los responsables antes de la fecha límite, no después.
Recorre la checklist de release e informa de los huecos al responsable de la release.
Los avisos de release a canales públicos se encolan como tarjetas de aprobación. Apruebe o deniegue con un toque.
Se entregue o se retrase, el resultado queda registrado con sus razones en el libro de actividad.
La gestión de releases es un trabajo de coordinación que abarca fechas límite, checklists, aprobaciones y llevar el registro. Un asistente de IA en la nube que vive en Slack puede recordarle que un cierre se acerca, pero no es dueño de la release. Hedy sí. Es un empleado de IA que se ejecuta en su propia infraestructura, que vigila la ventana de congelación, recorre la checklist de release y sabe qué pasos siguen abiertos antes de que salga una build. El sentido de hedy.one es que una sola Hedy lleva todo el ciclo de release en lugar de añadir otro puesto a un canal.
La comunicación saliente es donde las releases se tuercen, así que Hedy la trata como una escritura gobernada. Redactar una nota de versión externa, una actualización de la página de estado o un aviso a clientes es una acción de escritura, y las escrituras se deniegan por defecto en una lista de permitidos. Cualquier cosa de cara al cliente se enruta por aprobación por niveles—L0 automático, L1 un solo revisor, L2 doble firma—antes de salir. Hedy puede preparar el aviso y dejarlo listo, pero un humano abre la puerta. El límite vive en la configuración y el código, no en un prompt, así que aguanta incluso cuando el modelo está seguro.
Cada release entregada va a parar a un libro. La versión, el estado de la checklist, quién aprobó el aviso, cuándo salió y la evidencia enlazada se escriben en un registro de auditoría append-only sin ruta de actualización ni de borrado. Cuando Hedy responde una pregunta sobre una release pasada, la puerta de evidencia le exige citar la fuente de forma literal en lugar de parafrasear de memoria, y la recuperación se acota por la ACL de quien pregunta—de modo que un informe refleja lo que esa persona está autorizada a ver.
Cron es donde la automatización falla en silencio, así que Hedy hace el destino explícito. Un recordatorio de cierre programado o un aviso de checklist debe nombrar su canal de destino en la definición del trabajo; no hay un recurso implícito al «último canal» que pueda filtrar un recordatorio a la audiencia equivocada. Hedy habla Feishu/Lark como canal de primera clase junto a Slack, usa sus propias claves de modelo (incluidos vLLM u Ollama locales), se despliega en unos 30 minutos mediante compose y no incluye subencargados (sub-processors)—el historial de releases permanece en su infraestructura.