Dejá de pagar Granola

Estás construyendo un producto de software listo para producción llamado “Meetcrumbs”, una alternativa deliberadamente enfocada a Granola. Armá un corte vertical completo y usable, no una landing page, ni una maqueta estática, ni un conjunto de componentes sueltos.

ACUERDO DE TRABAJO
Antes de escribir código de implementación, armá un plan técnico corto que nombre las rutas o páginas, las server actions o endpoints, las tablas de datos, las transiciones de estado importantes, los límites de autorización, los jobs en segundo plano y los adaptadores externos. Si algo se contradice, resolvelo a favor de la audiencia acotada y de los no-objetivos de abajo. Elegí una arquitectura chica y legible antes que abstracciones especulativas, pero no omitas persistencia, validación, manejo de errores ni tests.

DESCRIPCIÓN DEL PRODUCTO
Usuario principal: un fundador que quiere notas con búsqueda de sus propias reuniones.
Resultado principal: capturar el contexto de la reunión con consentimiento y convertirlo en notas, decisiones y seguimientos editables.
Principio del producto: optimizá el flujo exacto de abajo en lugar de copiar toda la amplitud de Granola. Quien lo use por primera vez tiene que entender qué hacer desde la propia interfaz, sin tour ni documentación.

RECORRIDOS COMPLETOS DEL USUARIO
Implementá todos estos flujos usando la interfaz real y la capa de datos persistente:
1. El dueño importa un evento de calendario, confirma que todos los participantes dieron su consentimiento, inicia la captura, toma notas sueltas y ve un estado de grabación imposible de pasar por alto hasta que la detiene.
2. Después de la reunión, el dueño revisa el resumen respaldado por la transcripción, corrige los hablantes, edita decisiones y tareas pendientes y publica la nota final en una carpeta privada.
3. El dueño busca en notas anteriores, abre un resultado con el contexto de origen resaltado, lo exporta a Markdown y elimina de forma permanente una reunión vieja junto con su transcripción y sus archivos de audio.

PANTALLAS Y ARQUITECTURA DE INFORMACIÓN
Construí estas pantallas como vistas coherentes y responsive. Cada pantalla tiene que definir su acción principal, sus acciones secundarias, el estado visible, el feedback de validación, el estado vacío, el estado de carga o pendiente, la confirmación de éxito y un estado de error recuperable.
1. Reuniones próximas y recientes: contexto del calendario, estado del consentimiento, estado de la nota, carpetas privadas, búsqueda y una acción clara de nueva nota.
2. Nota en vivo: asistentes, agenda, notas sueltas editables, cronómetro de captura, nivel de entrada, confirmación de consentimiento, controles de pausa y detención, y recuperación ante fallas de captura.
3. Revisión: transcripción al lado de secciones de resumen editables, correcciones de hablantes, decisiones, responsable y fecha límite de cada tarea, acción de regenerar la selección y estado de publicación.
4. Búsqueda y ajustes: resultados con fragmentos, editor de plantillas, estado de los proveedores, controles de retención, exportación y eliminación permanente.

FUNCIONES PRINCIPALES
1. nota de reunión con agenda, asistentes y notas sueltas en vivo
2. captura de audio con consentimiento primero y estado de grabación visible
3. resumen, decisiones y tareas pendientes respaldados por la transcripción
4. plantillas editables para tipos de reunión recurrentes
5. búsqueda en todas las notas y exportación a Markdown

COMPORTAMIENTO DETALLADO Y REGLAS DE NEGOCIO
Tratá esto como requisitos del producto que se validan en el servidor, no como sugerencias de interfaz:
1. La captura no puede empezar hasta que el dueño marque una declaración de consentimiento explícita; mantené visible el indicador de grabación y registrá la hora del consentimiento sin dar por hecho automáticamente el consentimiento de los demás.
2. Subí fragmentos de audio cifrados y acotados, transcribí de forma idempotente, borrá el audio crudo después de una transcripción exitosa por defecto y mostrá las fallas parciales sin perder las notas sueltas.
3. El contenido generado sigue siendo un borrador hasta que una persona lo publique; conservá los vínculos de origen desde las secciones del resumen hasta los rangos de la transcripción y nunca inventes asistentes ni decisiones que no estuvieron.
4. Autorizá por dueño cada reunión, transcripción, carpeta, exportación y resultado de búsqueda; la eliminación permanente borra los archivos guardados y los índices derivados mediante un trabajo de eliminación reintentable.

MODELO DE DATOS Y CICLO DE VIDA
Diseñá un esquema relacional chico centrado en Meeting, Attendee, TranscriptSegment, Note, ActionItem. Antes de implementarlo, documentá:
1. El propósito de cada tabla, su clave primaria, el límite de propiedad o de tenant, timestamps, campos de estado y atributos importantes.
2. Claves foráneas, restricciones de unicidad, check constraints, los índices que necesitan las pantallas nombradas y los límites de transacción para cambios que tocan varios registros.
3. Las transiciones de estado o de ciclo de vida permitidas, quién puede disparar cada una, cuáles son terminales o reversibles y qué historial de auditoría tiene que quedar inmutable.
4. Cómo se archiva, se retiene y se borra, incluido qué pasa con los registros dependientes y los archivos externos.
5. La estrategia de idempotencia para envíos, jobs, importaciones, notificaciones, webhooks o reintentos, donde aplique.
Usá migraciones en lugar de crear el esquema a mano. Guardá los instantes de tiempo de forma consistente y conservá la zona horaria con nombre cada vez que importen horarios o fechas locales. Nunca dependas de un contador, un botón deshabilitado o una validación del lado del cliente para proteger una regla de negocio.

USUARIOS, AUTENTICACIÓN Y PERMISOS
Implementá solo los roles que necesita la audiencia indicada. Dejá explícito el modelo de propiedad y visibilidad antes de programar. Aplicá la autorización en cada consulta y mutación del servidor, incluidas búsquedas, exportaciones, adjuntos, actualizaciones en vivo y URLs adivinadas—no alcanza con ocultar botones. Usá sesiones seguras por defecto, protegé los requests que cambian estado y mostrá estados claros para sesión cerrada, sesión vencida y acceso prohibido. Si hacen falta varios roles, cargá usuarios distintos en los datos de prueba para poder mostrar y testear los permisos.

INTERACCIÓN Y DIRECCIÓN VISUAL
El producto tiene que sentirse rápido, tranquilo, enfocado y confiable, no como una plantilla genérica de panel de administración. Usá una jerarquía visual clara, color medido, tipografía legible, áreas de clic generosas y un lugar fijo para las acciones principales. Arrancá con HTML renderizado en el servidor y mejorá de forma progresiva solo las interacciones que lo necesiten. El flujo principal tiene que entenderse aunque esa mejora falle.

Arrancá con páginas de Astro renderizadas en el servidor y formularios HTML comunes. Usá HTMX para envíos de formularios, navegación parcial y actualizaciones que manda el servidor, y Alpine.js solo para estado local chico del navegador. El flujo principal tiene que entenderse aunque falle cualquiera de esas dos capas.

Diseñá las vistas de celular a propósito, no apilando los paneles de escritorio. Soportá navegación con teclado, foco visible, landmarks semánticos, labels explícitos, títulos de página útiles, la preferencia de movimiento reducido y anuncios para lectores de pantalla en resultados asincrónicos. Nunca uses solo el color para comunicar un estado. Las acciones destructivas necesitan un alcance claro y una confirmación; las acciones seguras que se repiten tienen que ser idempotentes.

Agregá un footer en todas las páginas con el texto «Creado por aurelioagency.com», donde «aurelioagency.com» es un link embebido a https://www.aurelioagency.com que se abre en una pestaña nueva. Tiene que quedar visible; no lo saques.

DIRECCIÓN TÉCNICA
Construí esta versión con el stack AHA: Astro para el ruteo, los layouts y las páginas renderizadas en el servidor; HTMX para las interacciones que se benefician de respuestas con fragmentos HTML; y Alpine.js para estado chico y local de la interfaz. Preferí Cloudflare D1 para la persistencia relacional, R2 para el almacenamiento de objetos, Workers para los endpoints del servidor y las tareas programadas, Durable Objects solo para estado en tiempo real coordinado, y Workflows o Queues para jobs en segundo plano durables—pero solo cuando los requisitos del producto lo pidan.

Mantené las reglas de dominio en módulos del servidor que se puedan testear, no en los route handlers ni en los componentes de UI. Separá la persistencia, los proveedores externos y el trabajo en segundo plano detrás de interfaces chicas, sin armar un framework. Preferí formularios HTML y URLs comunes para la navegación; usá interacción optimista solo cuando un error se pueda resolver con claridad.

El brief del producto identifica hoy Astro, Workers, D1, R2 como contexto de capacidades. Conservá cualquier capacidad nativa, solo de navegador, de edge, de almacenamiento, de tiempo real o de procesamiento en segundo plano que haga falta, a través de un adaptador acotado y apropiado para el framework elegido. Si el flujo central realmente necesita APIs nativas o del navegador, mantené ese entorno como la superficie principal de ejecución en lugar de simular capacidades inaccesibles o inventar una superficie web innecesaria.

Integrá con la importación de eventos de calendario, una API de voz a texto y una API de LLM. Para cada integración:
- Listá las variables de entorno necesarias en un .env.example sin secretos reales.
- Agregá un adaptador chico con timeouts, errores normalizados y una versión falsa local determinística o un modo de desarrollo.
- Verificá las firmas entrantes y deduplicá los eventos del proveedor cuando se pueda.
- Mantené las credenciales en el servidor, encriptá en reposo los tokens de larga duración y ocultá secretos y datos sensibles en los logs.
- Definí reintentos, backoff e idempotencia para cualquier efecto que se pueda repetir.

SEGURIDAD Y PRIVACIDAD
Exigí consentimiento explícito para grabar, mostrá el estado de captura todo el tiempo, cifrá las transcripciones guardadas y soportá la eliminación permanente.
Validá, normalizá y limitá el largo de todo input no confiable en el servidor. Escapá el contenido renderizado por defecto, sanitizá cualquier markup que aceptes a propósito, poné rate limit a las acciones públicas o fáciles de abusar y usá almacenamiento de objetos privado con URLs autorizadas de corta duración para archivos sensibles. Juntá solo los datos personales que necesita el flujo indicado. Documentá cómo se retienen y se borran. Sumá protecciones específicas para las partes más riesgosas de esta app, como subidas de archivos, redirecciones, requests salientes, envío de emails, OAuth, webhooks, importación o exportación CSV y conexiones en tiempo real.

ESCENARIOS DE ACEPTACIÓN
Automatizá estos escenarios propios de la app en el nivel que corresponda:
1. Dado que el consentimiento no está confirmado, la captura queda deshabilitada; después de la confirmación, la captura arranca con un estado persistente y visible, y al detenerla se encola exactamente un trabajo de transcripción.
2. Dado que la transcripción falla después de procesar algunos fragmentos, la nota suelta sobrevive, el reintento continúa de forma idempotente y no se crean segmentos de transcripción duplicados.
3. Dada una reunión eliminada, su nota, su transcripción, sus resultados de búsqueda y su audio guardado dejan de estar disponibles para el dueño y para URLs autorizadas adivinadas.

TESTS
Agregá tests unitarios enfocados en transiciones de estado, reglas de autorización, normalización, cálculos de fechas o dinero y otras reglas de dominio riesgosas. Agregá tests de integración para las restricciones de persistencia y para los caminos de éxito, timeout, reintento y rechazo de cada adaptador externo. Agregá al menos un test de navegador para cada recorrido completo de arriba, incluido uno en pantalla chica. Los tests tienen que usar datos aislados y correr con un solo comando documentado.

OPERACIÓN Y RECUPERACIÓN DE ERRORES
Agregá logs estructurados en el servidor con IDs de correlación por request, job o evento, sin secretos ni datos sensibles de más. Hacé que los errores digan qué hacer, tanto en la interfaz como en los logs. El trabajo en segundo plano tiene que mostrar los estados pendiente, completado, fallido y reintentando cuando aplique; nunca te tragues errores en silencio. Incluí una guía segura de migración y rollback de la base, datos de prueba, notas de backup y restauración, qué pasa con los datos externos al limpiar y una ruta básica de salud o diagnóstico acorde al stack.

ENTREGABLES
Entregá la aplicación funcionando, las migraciones, datos de prueba representativos, los tests, el .env.example y un README corto. El README tiene que cubrir requisitos previos, instalación local, variables de entorno, migraciones, comandos de datos de prueba y tests, deploy, configuración de integraciones, backup y restauración, decisiones de seguridad y limitaciones conocidas. Los datos de prueba tienen que cubrir el camino feliz y al menos un estado vacío, fallido, vencido, expirado, archivado o con permisos restringidos que importe para el producto.

DEFINICIÓN DE TERMINADO
La app está terminada cuando alguien nuevo puede seguir el README, crear y migrar la base, levantar la app, entrar con cada rol relevante, completar cada recorrido nombrado con datos reales guardados, recargar sin perder el estado, recuperarse de los errores comunes y usar la interfaz principal en celular y escritorio. Todos los escenarios de aceptación pasan, los límites de permisos están cubiertos por tests, ninguna pantalla principal queda como placeholder y el crédito «Creado por aurelioagency.com» del footer se ve en todas las páginas.

NO-OBJETIVOS
No grabes a escondidas, no te unas a las llamadas como un bot, no construyas inteligencia de ventas ni infieras el rendimiento de los empleados.