Idioma / Language

Jaiva v1: qué está listo y qué falta

Revisado el 2026-10-11 contra main en 731603e0 y la evidencia actual de los issues. Esta es la base de la revisión, no la revisión desplegada. Fuentes: el mapa del sistema y el #994 seguimiento del release v1. La etapa E se basa en el #1168 mapa del Delegado del cliente y el documento aceptado ADR-0030 Delegado del cliente.

21 de 27 partes del release funcionan o tienen prueba etapas A a D
  • 21 funcionan o tienen prueba
  • 4 construidas, apagadas
  • 2 planificadas

Etapas del release

La prueba del release: La Santa Picá recibe diez publicaciones programadas seguidas mediante este circuito y luego un segundo cliente recibe cinco. La etapa E pertenece a v1, pero no condiciona el release y queda fuera de la barra principal. Los estados «funciona» indican evidencia observada en staging o producción; no significan que todos los clientes estén operando. Los componentes apagados conservan su prueba, pero no pueden ejecutar nuevos efectos. B2 cerró con excepciones aceptadas y el esfuerzo humano aún no se midió. Abre una etapa para ver sus partes y una parte para ver su evidencia.

A Generar una publicación y aprobarla en Studio Listo. El 2026-09-27 ejecutaste una publicación real en staging: generación, un cambio de dirección, admisión y aprobación; aceptaste la prueba #979. Studio abrió en producción para ambos fundadores con acceso de Google el 2026-09-27 (#1263) y responde en studio.jaiva.cl desde esa noche (#1294). Estas pruebas en staging no acreditan el primer circuito de un cliente real en la plataforma. La generación está habilitada en producción desde el despliegue del 2026-09-28. Ambas claves de proveedores están configuradas (#1268). Están activos el horario cada dos minutos, la facturación verificada de textos y el alcance a todos los clientes (#1269). El formulario #1266 para registrar clientes también está activo: cualquier cliente que autorices puede generar sin otro despliegue. Falta ese primer cliente: La Santa Picá. Desde el 2026-10-02, «Preparar propuesta» (#1369) está en producción; permite agregar el plato y escribir la propuesta cuando el kit esté activo. 12 de 13 funcionando
  • Decisiones en Studio: aprobar, corregir o rechazar la versión exactafunciona
    Qué hace
    El fundador ve una publicación, edita el texto si hace falta y aprueba, corrige o rechaza esa versión exacta. La aprobación registra una intención de envío y un evento en el registro de efectos en la misma transacción.
    Evidencia
    platform/src/lib/studio/studioPacket*.ts, de las PR #897 y #929 de publicaciones en Studio.
    Documento responsable
    Spec 893: contrato de publicaciones en Studio
  • Kits de marca con versiones y fotos de referencia fijadasfunciona
    Qué hace
    Cada cliente tiene un kit de marca. Cada cambio crea una versión. Un fundador activa una versión exacta que puede fijar fotos aprobadas del cliente.
    Evidencia
    studioBrandKit.ts, tabla client_brand_kit_revisions.
  • Carga de fotos por el fundador y decisión de usofunciona
    Qué hace
    Un fundador carga fotos del cliente e indica cuáles se pueden usar. Hoy solo se pueden habilitar fotos que pertenecen al cliente.
    Evidencia
    registerFounderSourceAsset.ts, tabla studio_source_eligibility_decisions.
  • Acceso a Studio mediante Cloudflare Accessfunciona
    Estado
    Funciona en staging y producción. Studio abrió en producción (#1263) el 2026-09-27 con acceso de Google Workspace exclusivo para ambos fundadores. Ambos ingresaron; otras cuentas son rechazadas. Desde esa noche Studio en producción también responde en studio.jaiva.cl, con el mismo acceso exclusivo (#1294). Ambos fundadores lo usan y un tercero es rechazado. Los comandos de publicaciones y la preparación de marcas están habilitados en producción desde el 2026-09-27 (#1267). El formulario de clientes (#1266) y la generación (#1269) están activos desde el 2026-09-28. Al abrir, Studio estaba vacío; registrar al primer cliente corresponde a #1265.
    Evidencia
    #933 acceso a Studio, studio-auth.ts.
    Documento responsable
    Spec 933: acceso a Studio con Cloudflare
  • Registros de generaciónfunciona
    Qué hace
    Guarda cada generación e intento de imagen contra la versión exacta de la propuesta.
    Evidencia
    Tablas studio_generation_runs y studio_generation_attempts.
  • Adaptador del proveedor de imágenesfunciona
    Estado
    Integrado en la PR #1000 (#257). La prueba #979 hizo llamadas reales de imágenes en staging, a USD 0,19 por imagen. Consulta la evidencia #979.
    Evidencia
    platform/src/lib/imagegen/openAIImageProvider.ts
  • Generación duradera de imágenes en la nubefunciona
    Qué hace
    Ejecuta la generación como un trabajo que sobrevive a interrupciones: reservas con hora de la base de datos, permisos de un solo uso, recuperación acotada del almacenamiento y aislamiento entre clientes.
    Estado
    Integrado en la PR #1049 (#258). Se ejecutó en staging durante la prueba #979. Un corte de base de datos después de la llamada de imagen dejó el intento «incierto»; el siguiente tuvo éxito. La configuración de staging se conserva en el repositorio (#1269), por lo que un despliegue ya no la borra. La generación en producción está habilitada desde el 2026-09-28 (#1269), a la espera del primer cliente. El traspaso mediante Queue (#1378) está implementado y activado en staging bajo #1489; producción conserva su ruta anterior. Avanza un trabajo exacto de imagen o texto por entrega y conserva la recuperación en la base. El 2026-10-01, una prueba de staging procesó tres publicaciones por Queue y cada una recibió imagen y texto (evidencia del traspaso Queue #1378). Los mensajes repetidos e inválidos no iniciaron llamadas pagadas. Al arrancar en frío, Queue procesa primero una imagen a la vez; una publicación esperó unos dos minutos a otra. La reparación automática (#1379) está integrada y superó una prueba de dos publicaciones en staging el 2026-10-02 (evidencia de reparación #1379). Una perdió su mensaje inicial y otra su etapa de texto. La siguiente revisión cada dos minutos terminó ambas sin pagar otra imagen. Desde el 2026-10-02, la habilitación de Queue en staging se conserva entre despliegues (#1489). La meta de 100 publicaciones (#1380) no está probada. Consulta la evidencia #979.
    Evidencia
    studioGeneration.ts, worker.ts, migración 0036.
    Documento responsable
    Spec 258: generación duradera
  • Texto escrito desde la imagen terminada, con pausa por conflictofunciona
    Qué hace
    Gemini escribe el texto cuando la imagen ya existe. Si contradice los datos del menú, la publicación se pausa. Un fallo técnico reinicia solo el texto y conserva la imagen y su costo.
    Estado
    Integrado con #258. La prueba #979 generó textos pagados de Gemini en staging. Un texto vencido se reinició desde Studio conservando la imagen. La pausa por conflicto no se probó en staging. La ruta de textos administrada por Cloudflare (#1378) está habilitada en staging bajo #1489; producción mantiene la ruta directa. Conserva el modelo y los límites de solicitud y reintento, y rechaza trabajos de la ruta anterior antes de gastar nuevamente. El 2026-10-01 escribió tres textos mediante Cloudflare, cada uno en unos 15 segundos. Esa prueba autorizada de tres publicaciones ya se usó; el juicio de calidad del fundador es independiente.
    Evidencia
    geminiCaptionProvider.ts, tabla studio_caption_cycles.
  • Generar en Studio y aceptar o descartar la imagen y el textofunciona
    Qué hace
    Un fundador inicia la generación desde Studio. Imagen y texto entran como un par exacto. Puede descartar una propuesta y pedir otra dirección creativa para la misma entrega.
    Estado
    Integrado en la PR #1148 (#978). En la prueba #979 generaste, cambiaste una vez de dirección, admitiste y aprobaste en staging. No se envió ni publicó nada. Antes, Studio en producción no tenía una pantalla para agregar platos o escribir propuestas y «Nuevo paquete» estaba vacío. «Preparar propuesta» (#1369) agrega ambas: escribes el nombre y precio del plato y eliges el plato, la entrega programada y una foto del kit. El servidor resuelve el resto. Está en producción desde el 2026-10-02.
    Evidencia
    StudioDecisionWorkspace.tsx, studioPacketAdmission.ts, migración 0038.
  • Datos del menú con vigencia y controles de aprobaciónfunciona
    Qué hace
    Los datos del menú tienen fecha de vigencia. Un cambio invalida las aprobaciones de publicaciones aún no publicadas. Generación, admisión y aprobación comprueban esos datos.
    Estado
    Integrado en la PR #1039 (#977). Generación, admisión y aprobación comprobaron los datos en la prueba #979. La invalidación de una aprobación por cambio de datos no se probó en staging.
    Evidencia
    studioMenuFact.ts, tablas client_menu_fact_revisions y studio_packet_fact_invalidations.
  • Foto de prueba en staging y reparación de interrupcionesapagado
    Estado
    Integrado en la PR #1001 (#976). Validado con fallos simulados. La prueba #979 usó tu propia foto, por lo que esta ruta de fixture no se ejecutó.
    Evidencia
    studioStagingGenerationFixture.ts
  • Informe de solo lectura para cada publicación de una pruebafunciona
    Qué hace
    Entrega al fundador un informe por publicación desde registros guardados: qué se ejecutó, cuánto costó, qué falló y qué sigue. No llama a proveedores ni cambia datos. La evidencia ausente se conserva como «desconocida».
    Estado
    Integrado en la PR #1162 (#1160). La prueba #979 dejó un informe completo y uno interrumpido. Las pruebas #985 de aprobación y #993 de publicación agregan su evidencia.
    Evidencia
    GET /api/internal/studio/packet-report
  • Prueba de staging de toda la etapafunciona
    Qué demuestra
    Una generación real en staging, completa e interrumpida, cada una con su informe.
    Estado
    Completada el 2026-09-27 y aceptada por ti. Tu tiempo activo fue de unos 10 minutos y cada imagen costó USD 0,19. Consulta la evidencia #979.
    Enlaces
    #979 prueba de generación en staging · Spec 974: publicación generada en la nube
B El cliente aprueba la publicación exacta por WhatsApp Prueba de staging completada el 2026-10-11: propuesta real, entrega, aprobación, solicitud de cambios y nueva versión del texto. El transporte de publicaciones sigue apagado en producción. La línea de pruebas volvió al fixture A para #309; la prueba usó Mimbre. 6 de 6 funcionando
  • Router de WhatsApp: aprobaciones antiguas y respuestas supervisadasfunciona
    Qué hace
    Encamina los mensajes del número compartido y permite que un fundador supervise las respuestas. Registra aprobaciones antiguas mediante botones. Esa ruta heredada no vincula la versión exacta de un paquete; la ruta separada #984 ahora sí.
    Cambio de seguridad
    Activo desde el despliegue a producción del 2026-09-25 (#1195). Todo borrador de IA espera a León o Juanro; el router ya no envía automáticamente. No existe código de acceso por OTP, aunque el mapa lo mencionaba.
    Línea de staging
    Desde el 2026-10-04, un número de prueba de Meta llega al Worker de staging y un texto de fundador recibe un borrador Gemini que espera aprobación (#1539 línea WhatsApp de staging). En staging, los borradores llaman a Gemini mediante Cloudflare AI Gateway; producción mantiene la ruta directa (#1531 borradores mediante AI Gateway). El código integrado registra el resultado de la respuesta supervisada después del envío (#1441, 2026-10-04) y elimina la antigua ruta de respuestas /inbox (#1442, 2026-10-02).
    Evidencia
    platform/src/lib/whatsapp/router.ts, ADR-0006.
  • Recepción duradera y recuperación de interrupcionesprobado en staging
    Qué hace
    Guarda cada respuesta firmada antes de devolver un 200 a Meta. Un trabajo cada dos minutos usa una marca reciente de actividad para terminar trabajo interrumpido, con reintentos acotados; el mantenimiento horario también busca trabajo. Respuestas firmadas, comandos de generación, aprobaciones de envío, resoluciones de reintento con evidencia y cargas de fuentes establecen esa marca antes de crear trabajo. Las ráfagas la reutilizan hasta 30 minutos; una activación no verificada rechaza trabajo nuevo (#1371). Esta conexión no habilita por sí sola el transporte ni la recuperación de cargas. Un comprobante guardado nunca equivale por sí solo a una aprobación.
    Estado
    #981 está en main y se ejercitó en la ida y vuelta real de #985, incluida la recuperación de recepción antes del procesamiento. La configuración confiable del destino selecciona el cliente. La línea de staging ahora usa fixture A (PR #1901); producción no tiene un destino de paquetes vinculado.
    Enlaces
    Spec 980: recuperación de mensajes entrantes · pendiente de tipos de pruebas #1182 corrección de tipos de mocks
  • Template de propuesta y adaptador de mediosprobado en staging
    Qué hace
    Construye la solicitud exacta de imagen, texto completo, hora y botones para Meta, con evidencia tipada y acotada.
    Estado
    Meta aprobó packet_proposal el 2026-10-04. #985 envió propuestas reales con imagen y texto por el adaptador; la versión sucesora recibió mensaje y aprobación nuevos. #1883 / PR #1894 muestra la hora local de Chile continental, incluido el horario de verano.
    Evidencia
    packetProposalProvider.ts, metaPacketProposalProvider.ts y packetProposalProvider.contract.md.
    Enlaces
    #982 template y medios de Meta
  • Envío, recuperación y control del teléfono de pruebaprobado en staging
    Qué hace
    Envía cada publicación aprobada una vez. Un resultado perdido queda «incierto» hasta resolverlo con evidencia. En staging solo envía a un teléfono de prueba autorizado.
    Estado
    #983 está en main. #985 observó cinco envíos de template para cinco intenciones distintas, un destino no autorizado rechazado sin llamar al proveedor y una recuperación anterior al envío sin duplicación. Un resultado perdido sigue sin resolverse; #1885 confirmación de envío perdido es responsable de la brecha de evidencia. El transporte en producción sigue apagado.
    Enlaces
    #983 envío de propuestas
  • Respuesta del cliente: aprobar, pedir cambios y corregir lo enviadoprobado en staging
    Qué hace
    Solo puede aprobar la persona designada y solo la versión actual. Pedir cambios pausa la publicación. El texto libre y el silencio nunca aprueban. Tras siete días sin aprobación, la propuesta cierra sin publicarse.
    Estado
    #984 se integró en la PR #1872. #985 ejercitó aprobación real, pausa por cambios, una versión sucesora enviada y aprobación nueva del cliente, conservando el plazo original de siete días. La aprobación antigua no autorizó la sucesora. La asociación de texto libre sigue en #1887. #991 y #992 aportan la admisión de publicación y el permiso final de efectos.
    Enlaces
    #984 respuesta del cliente y pausa por cambios
  • Prueba de staging de toda la etapacerrado con brechas
    Qué demuestra
    La misma publicación de la prueba de generación #979 llega a un teléfono real y vuelve una respuesta de botón real; el informe se amplía con esa evidencia.
    Falta
    #985 cerró el 2026-10-11 bajo la autorización del fundador. Se omitió la prueba con otra persona no autorizada porque no había un segundo teléfono; el texto ambiguo tomó la derivación heredada. Pendientes: #1885 evidencia del envío perdido y #1887 asociación de texto libre. La hora #1883 está corregida. Evidencia: decisiones de ejecución y capturas.
    Enlaces
    #985 prueba de aprobación del cliente en staging
B2 Publicar una vez, a la hora acordada La prueba de staging cerró el 2026-10-11 con excepciones aceptadas por el fundador: una publicación real en Instagram, texto exacto y copia pública verificada por hash. Workflow y bucket están conectados en staging, pero la publicación se apagó de nuevo tras la prueba. Producción no tiene esa conexión ni las tablas de publicación. 2 de 5 funcionando
  • Cliente Zernio, publicación y conciliación de efectosfunciona
    Qué hace
    Publica y concilia mediante el proveedor configurado. Producción conserva Zernio; desde #1431, staging dirige el cliente Zernio de la plataforma a Jaiva social-api. La prueba Workflow #993 usó social-api de staging.
    Evidencia
    platform/src/lib/zernio/, platform/src/lib/effects/. El servicio propio de Jaiva, descrito en el mapa de reemplazo #1320 , ya tiene conexión, custodia cifrada del token, publicación en cola y métricas diarias de cuenta en main (#1384 conexión segura, #1385 publicación duradera, #1386 métricas de cuenta), con 343 pruebas controladas y PostgreSQL real aprobados en la revisión del adaptador OAuth. La repetición devuelve la misma publicación guardada; un resultado incierto se pausa para conciliación. Las métricas conservan ceros reales y dejan ausentes los valores no disponibles; el total de la cuenta no acredita el rendimiento de una publicación. El servicio está desplegado en staging, con base y cola provisionadas, secretos instalados y reversión ejercitada. OAuth propio funciona con identificadores de aplicación y profesionales verificados por separado. El listado acredita que el fixture está activo; se verificaron los tres permisos reales y la custodia cifrada del token con vencimiento futuro. La imagen neutra aprobada por el fundador está visible en el fixture de staging con el texto exacto. Repetir devuelve la misma publicación y medio; cambiar el contenido o usar encabezados contradictorios se rechaza. Se guardó una observación real del 30 de septiembre con cuatro ceros entregados por el proveedor y sin métricas no disponibles. Es una observación de cuenta del día anterior, no evidencia de rendimiento de la nueva publicación. El borrador de construcción sin conexión registra su alcance; el borrador de ejecución en staging planifica una publicación y una observación en @jaiva_staging_fixture. B2 y el recolector en producción conservan Zernio; staging dirige el cliente Zernio a social-api bajo #1431. El servicio de producción responde en https://social.jaiva.cl con su propia base, cola y secretos (#1430 puesta en marcha en producción). La puesta en marcha inicial quedó sin cuentas conectadas. La aplicación separada de Meta, Jaiva Social, todavía necesita App Review antes de conectar clientes.
  • Copia pública de medios con comprobación de hashprobado, apagado
    Qué hace
    Copia la imagen aprobada a una dirección pública y la comprueba byte por byte. El comprobante acredita la copia, no la publicación.
    Estado
    #990 está integrado en #992. #993 leyó la copia R2 pública real con HTTP 200 y comprobó su hash contra la imagen privada del paquete. La conexión de staging existe. La publicación volvió a apagarse, así que las ventanas nuevas no ejecutan efectos.
    Evidencia
    publicPacketMediaCopy.ts, tabla studio_public_media_copy_receipts.
  • Intención de publicación y control de horarioprobado, apagado
    Qué hace
    La aprobación del cliente registra una intención y una ventana en la hora original. Si se procesa tarde, se pausa para revisión del fundador; tocar otra vez no cambia nada. El control de la entrega conserva evidencia de publicación posible o confirmada entre versiones sucesoras.
    Estado
    #991 se integró en la PR #1879; #992 aporta el participante real y el adaptador de programación. #993 admitió y programó la publicación real, conservando el control de la entrega durante el reinicio y la pérdida del resultado. Ahora está apagado: una admisión con la habilitación apagada queda deshabilitada (#1893). La liberación nueva del fundador y las ventanas 2 en adelante siguen en #1861.
    Enlaces
    #991 intención de publicación · Spec 989: publicación
  • Workflow de publicación y recuperaciónprobado, apagado
    Qué hace
    Publica a la hora debida, revalida al final la pausa por cambios y nunca repite una creación que podría haberse ejecutado. Los resultados inciertos llegan al fundador en Studio.
    Estado
    #992 se integró en las PR #1877 y #1888. #993 registró Workflow y bucket públicos en staging (PR #1892) y probó una publicación tras reinicio, pérdida inyectada del resultado de creación y callback firmado que la confirmó. No hubo otra creación. Se retiró la habilitación y se limpiaron los triggers de prueba. Activar producción tiene su propia autorización humana.
    Enlaces
    #992 ejecución de publicación
  • Prueba de staging: una publicación real e interrupcionescerrado con excepciones
    Qué demuestra
    Una publicación real en Instagram a las 13:21:46 UTC del 2026-10-11, con el texto exacto del paquete y el hash coincidente de la copia pública. Se observó recuperación tras reinicio y callback; la pérdida de resultado se inyectó mediante un trigger de base de datos, no matando el proceso.
    Falta
    #993 y #989 cerraron con excepciones aceptadas por el fundador. #1896 conserva la comprobación de pausa en el Worker desplegado, la retención ante incidentes posteriores, los campos engañosos del informe y la medición pendiente de tiempo humano activo. El éxito sincrónico y la liberación del fundador siguen sin prueba; #1861 y #1893 siguen abiertos. Evidencia: registro de ejecución.
    Enlaces
    #993 prueba de publicación en staging
C El cliente acepta el plan y paga Sin iniciar. Los términos de Plan Base y las excepciones de precio están registrados; la aceptación, el próximo período y las respuestas de Mercado Pago aún condicionan la especificación. 0 de 1 funcionando
  • Enlace de aceptación y pago, cobro y conciliacióndepende de ti
    Qué hace
    Un enlace donde el cliente acepta Plan Base e inicia una suscripción de Mercado Pago. Mercado Pago cobra cada mes y Jaiva concilia cada cobro.
    Falta
    La etapa C aún no tiene especificación. La Santa Picá debe aceptar Plan Base estándar con su addendum de CLP 25.000 mensuales; siguen pendientes la fecha del próximo período y la conciliación. Que Panzza tiene una oferta de CLP 50.000 sin reels, pendiente de aceptación. K-Burgas puede participar en la prueba del release con excepción de CLP 1.000; falta verificar el mínimo de pago específico de la cuenta.
    Enlaces
    #881 aceptación y cobro · Spec 836: producto v1
D Informes de mitad y cierre del período Las métricas funcionan. #993 está cerrado, así que la especificación de informes ya no espera esa prueba; los dos informes de período para el cliente aún no están construidos. 1 de 2 funcionando
  • Métricas capturadas desde Zerniofunciona
    Evidencia
    Tabla metric_snapshots, efecto captureMetricsSnapshots.
  • Informes de mitad y cierre del período de servicioplanificadas
    Qué hace
    Dos informes por período de servicio para el cliente. Cada uno se escribe después de cerrar su ventana y un fundador lo aprueba antes de enviarlo.
    Falta
    Todavía no hay especificación ni implementación de informes. #993, que antes era requisito, cerró con excepciones aceptadas; informes y prueba completa del release siguen pendientes.
E Delegado del cliente: un agente conversa por nosotros No condiciona el release. La especificación de fase 1 está en main; atribución y bandeja de conversaciones se integraron, con la bandeja probada en staging. Memoria, contexto de turno y controles de envío apagados por defecto están parcialmente construidos. MCP, OAuth, aprobación de envío y progresión siguen esperando decisiones en #1214. 1 de 6 funcionando
  • ADR: patrón del Delegado del cliente y matriz de autoridaddecidido
    Qué hace
    Registra lo que el Delegado puede hacer por el cliente, lo que solo puede hacer el cliente (aprobar, aceptar, pagar, cancelar) y lo reservado a los fundadores. Retira el nombre «Orchestrator».
    Estado
    Redactado como ADR-0030, ratificado el 2026-09-24. Registra tus decisiones de #1169 matriz de autoridad y control de envío : cada envío espera como intención pendiente hasta que cualquiera de los fundadores lo apruebe en una página de Access.
    Falta
    Nada. La especificación de fase 1 se apoya en este documento.
  • Superficie de capacidades del cliente: servidor MCP por cliente en stagingplanificadas
    Qué hace
    La puerta única del Delegado para actuar por un cliente. Obtiene el cliente del token de quien llama, nunca de un argumento de herramienta, para que un mensaje no alcance los datos de otro cliente. Studio mantiene sus rutas: tu decisión del 2026-10-02 limita la Superficie al Delegado; aprobar paquetes y generar, reservados al fundador, nunca son herramientas del Delegado.
    Estado
    ADR-0030 y la especificación #1238 están en main. #1340 probó las lecturas del registro por cliente; #1591 cerró con atribución de aprobador y Delegado; #1592 cerró con la bandeja probada en staging. Memoria #1593, habilitación/control de envío #1594 y contexto #1595 tienen código integrado y criterios de staging pendientes. Todavía no existen servidor MCP, OAuth/permisos ni una ruta completa de envío exitoso del Delegado.
    Falta
    Las decisiones de arquitectura siguen en #1214. #1444 sigue a cargo de comprobar el rol de ejecución en producción. Cada ticket conserva su prueba de staging pendiente; los componentes integrados no prueban la Superficie completa.
  • Fase 1: los fundadores ejecutan el Delegado en sus computadoresplanificadas
    Qué hace
    Una sesión de Claude Code o Codex guiada por un fundador responde y hace seguimiento a un cliente. Un fundador aprueba cada envío. Cada envío se registra y se autoriza en el servidor.
    Estado
    Investigación terminada: #1175 operación desde el computador y #1176 contexto, memoria y defensa ante inyección.
    Falta
    El contrato de fase 1 está integrado (PR #1243), ya no es un borrador pendiente. El texto no solicitado tiene la bandeja por cliente de #1592, probada en staging. #985 está cerrado. La primera sesión de Delegado sigue esperando las decisiones de capacidades, aprobación y envío de #1214.
  • Mensajes proactivos: catálogo de disparadores y templates Metaplanificadas
    Qué hace
    Avisos, seguimientos y sugerencias, cada uno asociado a un template aprobado, con límite de frecuencia y presupuesto por cliente.
    Estado
    La #1170 investigación de templates Meta y ventanas en Chile está terminada. Las sugerencias solo van dentro de una ventana abierta de 24 horas; v1 no tiene template de marketing y los templates fuera de la ventana conservan contenido factual. Regla: registrar el consentimiento del cliente antes del primer mensaje proactivo.
    Falta
    Una decisión sobre la modificación de ADR-0030 en #1242 recomendaciones proactivas y seguimientos (PR #1245 en borrador) y sobre #1254 contabilidad compartida de proactividad. Luego, el control de #1255 consentimiento, frecuencia y presupuesto y #1288 captura de consentimiento al incorporar al cliente. Hoy no se registra ese consentimiento. El precio de mensajes libres después del 2026-10-01 sigue abierto en #592 precios de WhatsApp.
  • Detener las respuestas automáticas del router antiguofunciona
    Qué cambia
    #1195 eliminó el envío automático del modelo y deja cada borrador pendiente de aprobación del fundador. Está activo en producción desde el despliegue del 2026-09-25.
    Evidencia
    #1195 aprobación de cada borrador por el fundador, platform/src/lib/whatsapp/router.ts.
  • Fase 2: Delegado alojado, siempre supervisadomás adelante
    Qué hace
    El Delegado alojado prepara borradores; un fundador aprueba cada envío. Cada clase de mensaje pasa a envío automático solo mediante su propia decisión escrita.
    Falta
    La investigación empieza después de operar fase 1. Los fundadores decidieron una excepción acotada de clave API solo para este agente.
    Enlaces
    #1168 mapa del Delegado del cliente
4Depende de ti
  • Aceptación de La Santa Picá, próximo período y conciliaciónEl precio de CLP 25.000 está decidido; la aceptación aún condiciona la etapa C
  • Decidir las modificaciones de mensajes proactivos #1242 y #1254La ruta proactiva del Delegado es independiente y sigue sin construir
  • Resolver las decisiones de arquitectura y herramientas de #1214Desbloquea MCP, OAuth, aprobación y progresión de envíos exitosos
  • Que Panzza acepta o rechaza la oferta de octubreCLP 50.000 sin reels está decidido; no se cobra ni cuenta para la prueba antes de aceptar

Alrededor del circuito

Estas partes alimentan o sostienen el circuito. No cuentan en la barra del release.

WhatsApp de ventas con aprobación del fundador El circuito completo de respuesta supervisada de Ventas está planificado. #528 construyó ingreso aislado por fuente, custodia por rol, lecturas de salud y conciliación de conexiones; sigue apagado. Faltan activación y consumidores posteriores. 0 de 1 funcionando
  • Recordar conversaciones de ventas, proponer respuestas y pedir aprobaciónplanificadas
    Qué hará
    Mantiene una conversación de Ventas vinculada a evidencia, prepara una respuesta y una acción opcional y muestra la propuesta exacta a León y Juanro en un número de Control separado. La respuesta del agente llega al prospecto solo tras una decisión estructurada vigente del fundador y la última comprobación de vigencia de conversación y ventana Meta de 24 horas.
    Elección del número
    Preferir el número de Ventas existente solo si se prueba la coexistencia oficial de Business App y Cloud API. Si falla, el número sigue manual mientras se evalúa otro exclusivo para API.
    Estado
    La arquitectura y el flujo supervisado están definidos en #782 y ADR-0029. El transporte entrante separado de Ventas y Control se construye apagado bajo #528 transporte aislado por fuente. Están integrados los comprobantes, la recuperación, la ruta habilitable, la conciliación de versiones y la lectura de salud exclusiva del fundador. La habilitación está ausente en todas las configuraciones, por lo que la ruta sigue apagada. La configuración de Ventas y Control, sus consumidores, la activación y la prueba de staging siguen pendientes. La línea de aprobación de clientes pertenece a otro dominio.
Fotos, referencias y prospectos Registro de fuentes, curaduría y resumen determinista de referencias están probados en staging. Una ejecución real de Apify continuó sin pagar dos veces; se detuvo la recolección y la evidencia quedó legible. La recolección en producción y el alcance más amplio de prospectos y cola siguen condicionados. 2 de 4 funcionando
  • Página de propuesta comercialfunciona
    Evidencia
    platform/src/pages/p/[token].astro, ADR-0023. La preparación inicial de prospectos nunca se conectó y #1208 la eliminó.
  • Resumen de referenciasprobado en staging
    Evidencia
    #1109 / PR #1612 y la conexión de lectura PR #1713 construyen dossiers versionados y resúmenes basados solo en taxonomía. #1110 materializó dossier v1 y un resumen limitado con 12 citas; repetir devolvió no_change. Aún no alcanza las cinco referencias positivas exigidas. Reemplaza la antigua ruta de primera etapa eliminada.
  • Registro de cuentas, recolector Apify y cola de referencias en Studioparcial; recolección apagada
    Qué hace
    Recolecta publicaciones públicas de Instagram de referencias y prospectos mediante Apify, sin acceso Meta. Los fundadores aprueban o rechazan elementos en Studio. Fotos autorizadas, reels reales y textos pueden entrar al análisis de Brand Kit con custodia aislada por cliente y acceso temporal por ejecución, snapshot e intento. Generar imágenes de marketing conserva su autorización separada de source_assets.
    Estado
    La custodia #1106 cerró tras la prueba sintética de aislamiento en staging. #1107, #1108, #1109 y las rutas #1110 están en main. El #1110 trazador real de staging recolectó 11 publicaciones y 59 archivos en cuarentena de una sola ejecución Apify de USD 1,62; Neon, registro y R2 conciliaron 59/59. La cobertura es parcial con cursor reanudable, no una ejecución de 600 elementos terminada. Se apagó el control duradero; las lecturas siguieron disponibles. El código de producción #1858 está integrado, pero bucket, provisión, despliegue, secretos, control y prueba siguen bajo autorización del fundador en #1859. Recolección de prospectos y cola completa aún están incompletas.
    Enlaces
    #1004 registro de cuentas fuente · ADR-0028
  • Pedir permiso al fotógrafoplanificadas
    Qué hace
    Pedir permiso al autor de una foto de terceros. Sí: usarla y etiquetarlo. Sin respuesta: solo una imagen semejante, sin usar sus píxeles. No: nunca usarla.
    Enlaces
    ADR-0021
Constructor de Brand Kit La etapa de Brand Kit para una marca existente cerró tras pruebas reales en staging: borrador, edición, activación, actualización, exportación de DESIGN.md y uso de voz en el texto. #1866 habilita la edición manual en producción; la preparación con IA sigue apagada allí. Video y conversión de prospectos siguen pendientes. 3 de 3 funcionando
  • Borrador de Brand Kit desde evidencia autorizadaprobado en staging
    Qué hace
    El constructor lee fotos, video, PDF y texto autorizados mediante un acceso privado y acotado. Las fuentes ausentes quedan como brechas. Studio muestra el borrador, evidencia e historial. Cada edición del fundador crea una versión y protege ese campo; activa una versión exacta. La PR #1328 del registro (#1106), integrada el 2026-10-02, agrega referencias fijadas a fotos, reels, PDF y textos por cliente, con lecturas temporales ligadas a ejecución, snapshot, intento y permiso exactos. El constructor todavía no lee del registro.
    Estado
    La generación pasa por Worker AI, una llamada por intento. El 2026-10-02, una ejecución controlada en un cliente de prueba produjo un borrador con citas a fotos, PDF de menú y texto. Siguieron edición, activación explícita y actualización. La actualización conservó la voz editada por el fundador y ofreció su propio texto como sugerencia. El modelo no citó el video de prueba; ese análisis no está probado. La ejecución está habilitada en staging y el despliegue la conserva (#1489). Consulta la prueba de staging del 2026-10-02.
    Enlaces
    #323 constructor de Brand Kit · Contrato de Studio · Evidencia HTTP 403 y límites
  • DESIGN.md generado desde cada versión del kitprobado en staging
    Estado
    En staging, el archivo DESIGN.md guardado para la versión activa coincidió byte por byte con dos versiones generadas localmente. Se guarda en la carpeta propia del cliente.
    Enlaces
    #264 DESIGN.md ligado a la revisión. Neon sigue siendo la fuente de verdad.
  • Identidad verbal: reglas de voz para publicaciones y mensajesprobado en staging
    Estado
    Voz, audiencia y dirección de Schema2 están implementadas. El 2026-10-02, una publicación de staging generó imagen y texto. El texto usó la versión activa, su hash y la voz editada por el fundador. Consulta la prueba del texto.
Bases de la plataforma Funcionan el registro de efectos, la detención de publicaciones, las lecturas de Stand-up y el flujo de cambios de Studio. Los controles de envío del Delegado están integrados pero apagados por defecto; el envío completo y la cobertura total del registro siguen pendientes. 4 de 4 funcionando
  • Punto único de efectos tipados que escribe el registrofunciona
    Qué hace
    Las funciones de efectos tipados escriben el registro domain_event en la misma transacción que el cambio. Los comandos de publicaciones en Studio también registran sus propias transacciones.
    Brecha
    La cobertura es parcial. #1441 registra respuestas supervisadas después del envío; #1591 agrega el aprobador original y la atribución del Delegado; #1594 registra cambios de habilitación y rechazos. Aprobación y progresión completas del Delegado siguen sin construir, y no todos los envíos heredados del router pasan por el punto único de efectos.
    Evidencia
    platform/src/lib/effects/, ADR-0012.
  • Control de detenciónfunciona
    Evidencia
    Efecto killSwitch. Probado en staging el 2026-07-04.
    Brecha
    La publicación lo comprueba. #1594 agrega un control compartido usado por #983 y la futura ruta del Delegado, con rechazo por detención. La habilitación del Delegado permanece apagada; la ruta de envío exitoso no está construida.
  • Resumen Stand-up y lecturas de salud de fuentesfunciona
    Evidencia
    platform/src/lib/standup/, solo lectura. #1429 cuenta publicaciones listas y planificadas desde el calendario de Jaiva. #992 agrega ventanas atrasadas, incidentes de duplicación y pausas del control de entrega. La migración 0058 se aplicó en producción; eso es independiente de habilitar las tablas B2 o publicar.
  • Flujo de cambios de Studio para actualización en vivofunciona
    Qué hace
    Conserva un contador de cambios por cliente. Studio abierto lo consulta cada 5 segundos y vuelve a cargar solo lo cambiado. Tras 5 minutos sin interacción se pausa detrás de «Pausado · Actualizar» y se pone al día con la siguiente acción.
    Estado
    Probado en staging desde el 2026-09-28: un cambio remoto apareció en otra pestaña en 2,6 segundos. Producción tiene las tablas de contadores. #1364 entrega miniaturas WebP de 192 px, con respaldo seguro de la imagen completa; revisión y precarga acotada mantienen la URL original. Revalidar responde 304 si la imagen no cambió.
    Evidencia
    GET /api/internal/studio/changes, tablas studio_change_log y studio_change_cursors.
Infraestructura Neon protegida — proyecto creado, ejecución deshabilitada

#1387 / PR #1393 estado protegido de Neon integró un almacén privado separado para el estado de infraestructura de base de datos y un control de planificación autorizado por el fundador. Pasaron revisión independiente, 5.424 pruebas locales, compilación y comprobaciones GitHub. Los comprobantes del coordinador 5913317628 y 5913684193 registran el backend GCP privado, versionado y de acceso uniforme, con prevención obligatoria de acceso público en SOUTHAMERICA-WEST1. El propietario Google verificado tiene permisos de metadatos, sin lectura, listado, creación ni borrado de objetos. La identidad CI aislada está ACTIVE con confianza exacta de repositorio 1233171759/main/manual/workflow/environment, desplegada desde la revisión 5e46d162 con el mapa explícito de workflows Neon; el valor predeterminado del repositorio queda vacío y bloquea la ejecución. Las variables públicas WIF y región (aws-sa-east-1) están configuradas. Observación del 2026-09-30: acceso de propietario/administrador Neon y clave protegida verificados; la facturación de la organización Jaiva muestra Free Plan / Current plan (plan gratuito actual). La PR #1402 agregó aplicación privada de planes guardados. La ejecución anterior plan CI 36756445312 aprobadoacredita autenticación CI permitida, inicialización del backend y planificación con bloqueo. La ejecución anterior apply CI 36756649030 fallido falló en la aplicación con HTTP 400; no se identificó el campo responsable. El proveedor fijado usa por defecto una ventana de restauración de 24 horas, superior al máximo de seis horas del SDK para Free. La corrección pide seis horas explícitamente para este proyecto. La diferencia de configuración está confirmada; atribuirle el HTTP 400 histórico sigue siendo una inferencia. Las ejecuciones protegidas posteriores plan 36767609149 y apply 36767795075 en main 66f3eab4 verificaron el proyecto summer-paper-60597222, rama principal br-shy-scene-b6bh45hj, Free / São Paulo / seis horas. Los proyectos existentes no cambiaron y no hubo migración. La admisión está deshabilitada (NEON_PRODUCTION_ENABLED=false); cada intento real requiere sus controles para la revisión exacta. No incluye cambio de proveedor ni plan pagado. Contención de bloqueo, recuperación y casos de identidad negativa siguen sin prueba.

#1388 preparación de staging declara un proyecto social-api y una cola, configuración de staging, un perfil inicial y un procedimiento atendido. La decisión de hostname del fundador selecciona https://social-api-staging.jaiva-staging.workers.dev para el trazador y callback; social-stg.jaiva.cl se posterga porque la cuenta dedicada de staging no tiene zonas. No se planifica mover DNS ni pagar configuración. El callback exacto de Meta está guardado y verificado, conservando la redirección original; no equivale a un permiso OAuth. Al 2026-09-30 está aceptado el acceso profesional/de prueba. La ausencia anterior en el inventario observado de Neon no fue una auditoría de estado privado o recursos huérfanos; la creación posterior se verificó arriba. Un workflow manual prepara creación o no-op privado con bloqueo, usando el bucket R2 de estado existente y una clave separada. El permiso acotado Queues Write y la creación de la cola se ejecutaron por CI revisado; apply de cola 36784922158 creó social-api-publication-staging. Productor y consumidor se conectan al Worker dedicado de staging. La base separada tiene tres migraciones, nueve tablas, un perfil inicial y un usuario de ejecución con privilegios mínimos. Cuatro secretos se instalaron de forma atómica y se guardaron en el gestor de contraseñas existente mediante rbwj. El hostname workers.dev entrega health 200 con previews deshabilitadas; se ejercitaron la reversión a la base cerrada y su restauración. La revisión 2b824a9a sirve la versión 9a619add-234f-4753-888b-675ee00e1ec7. OAuth propio y custodia del token probados: el fixture está activo, los tres permisos reales están otorgados y el token está cifrado con clave v1 y vencimiento futuro. La publicación aprobada por separado y la observación de cuenta real guardada se acreditan en el comprobante de publicación y métricas 5928736643. En esa prueba existe una publicación del servicio; repetir conserva su identidad. Los totales del 30 de septiembre son ceros reales de Meta; ningún dato ausente se convirtió en cero. Pueden llegar con 48 horas de retraso. La inspección del agente confirma imagen neutra y texto exacto; la evaluación del fundador es aparte. El propietario elimina la publicación manualmente; retención y desconexión del token siguen siendo decisiones separadas. La autorización existente del fundador cubre provisión, despliegue, OAuth y prueba real en staging. Antes de una ejecución se mantienen requisitos de identidad, secretos, revisión y configuración revisadas, base del Worker y reversión, más controles protegidos aplicables. La configuración no otorga autoridad; no hace falta nueva autorización general para staging. Aprobar la publicación exacta es independiente. Quedan excluidos cambios del servicio en producción, migración de proyectos existentes, contacto con clientes y DNS pagado. B2 en producción conserva Zernio; #993 usó social-api en staging mediante #1431. Esta prueba inicial del servicio no acredita una etapa del release, por lo que no altera sus barras ni conteos. Procedimiento de Neon protegido.

Cómo entregan código los agentes Los niveles por rutas y la integración por runner están activos. Se requieren gates y e2e del commit actual; typecheck controla regresiones cuando corresponde. La prueba de staging puede revertir un despliegue fallido. La suite completa corre periódicamente en main, no en cada PR. 2 de 2 funcionando
  • Nivel de revisión de PR según las rutas cambiadasfunciona
    Qué hace
    Las rutas eligen T0 (solo documentos, sin revisor), T1 (un revisor independiente) o T2. KITCHEN_T2_AS_T1 permite la ruta T1 habitual del runner para T2 confirmado. Un nivel no confirmado sigue siendo T2. Todos conservan autorizaciones de producción, clientes y gasto. Gates/e2e del commit actual y typecheck cuando corresponde determinan la admisión. El runner integra el trabajo apto; los autores no lo omiten.
    Evidencia
    Reglas por rutas en platform/scripts/ci/ceremony-tier.ts. El bloqueo de verificador, los journeys T2 con verificador previo y la aprobación humana de cambios de pruebas se eliminaron el 2026-10-09 (#1840, #1841), bajo las eliminaciones 1–4 de #1836. Política del repositorio
  • Prueba tras cada despliegue de staging, con reversión automáticafunciona
    Qué hace
    Tras cada despliegue, una cuenta de prueba ingresa a Studio, genera una publicación desde una foto fija y la aprueba. Si un paso falla, se revierte el despliegue y vuelve la versión anterior. Usa un cliente de staging sin conexión Instagram; no envía ni publica nada. No toca producción.
    Evidencia
    El 2026-10-03 se detectó un despliegue roto a propósito (PR #1532) 1,7 segundos después y se restauró el anterior 3,4 segundos después. El despliegue siguiente (PR #1537) superó los tres pasos. La prueba de publicación se incorpora por separado; no se envía al cliente ni a Instagram durante esta prueba de Studio. #1459 prueba de staging · procedimiento
Después del release Panel del cliente, acceso al portal y cancelación autónoma. 0 de 1 funcionando
  • Después del release: panel, portal y cancelación autónomaplanificadas

La mapa del sistema es la fuente de verdad, con diagramas y evidencia exacta. Esta página resume en lenguaje simple su registro de estados, el tracker #994 y, para E, el mapa del Delegado #1168. Si difieren, prevalece el mapa.

«Apagado» significa que el código está en main pero no tiene conexión, está deshabilitado o nunca se ejecutó. «Funciona o tiene prueba» indica evidencia observada de staging o producción para esa capacidad o prueba; no es un porcentaje de avance del release. Al lado se indica la activación actual y los criterios exceptuados o sin probar. Gris significa código congelado en main que se está retirando.

Jaiva v1: what is done, what is left

Audited 2026-10-11 against main at 731603e0 and live issue evidence. This is the audit baseline, not the deployment revision. From the system map and the #994 v1 release tracker. Slice E from the #1168 Client Delegate map and the accepted ADR-0030 Client Delegate.

21 of 27 release parts working or proven slices A to D
  • 21 working or proven
  • 4 built, switched off
  • 2 planned

Release slices

The release proof: La Santa Picá gets ten scheduled posts in a row through this loop, and then a second client gets five. Slice E is in v1 but does not gate the release, so it stays out of the top bar. Working badges name observed staging or production evidence; they do not mean all clients are live. Switched-off components retain their proof but cannot execute new effects. B2 closed with waivers, and the human-effort gate is unmeasured. Open a slice to see its parts. Open a part to see its evidence.

A Generate a post, founder approves in Studio Done. You ran one real post on staging through generate, one pivot, admission and approval on 2026-09-27, and accepted the #979 generation proof. In production, Studio opened for both founders behind Google sign-in on 2026-09-27 (#1263), and it answers at studio.jaiva.cl since the same night (#1294). Its first real-client platform loop is not established by these staging proofs. Since the 2026-09-28 production deploy, generation is enabled in production. Both provider keys are set (#1268 production provider keys). The two-minute schedule, the verified caption billing and the all-clients scope are live (#1269 production generation). The #1266 production client records form is live too, so any client you authorize there can generate, with no deploy per client. It still needs that first client: La Santa Picá. Since 2026-10-02 the «Preparar propuesta» panel (#1369 dish and proposal screens) is in production too, so you can add the dish and write the proposal in Studio once the kit is active. 12 of 13 working
  • Studio decision workspace: approve, correct or reject the exact versionworks
    What it does
    The founder sees one post, edits the caption if needed, and approves, corrects or rejects that exact version. Approval records a send intent and a ledger event in one transaction.
    Evidence
    platform/src/lib/studio/studioPacket*.ts, from the Studio packet PRs #897 and #929.
    Owner doc
    Spec 893 Studio packet contract
  • Brand kits with versions and pinned reference photosworks
    What it does
    Each client has a brand kit. Each change makes a new version. A founder activates one exact version, and it can pin approved client photos.
    Evidence
    studioBrandKit.ts, table client_brand_kit_revisions.
  • Founder photo upload and "can we use it" decisionworks
    What it does
    A founder uploads client photos and marks each one usable or not. Only client-owned photos can be marked usable today.
    Evidence
    registerFounderSourceAsset.ts, table studio_source_eligibility_decisions.
  • Studio login behind Cloudflare Accessworks
    State
    Works on staging and in production. Production (#1263 Studio in production) opened on 2026-09-27 with Google Workspace sign-in for the two founders only. Both founders signed in; other accounts are refused. Since the night of 2026-09-27 production Studio also answers at studio.jaiva.cl, behind the same founder-only sign-in (#1294 Studio hostname). Both founders work there and a non-founder is refused. Packet commands and brand bootstrap are on in production since 2026-09-27 (#1267). Since 2026-09-28 the client records form (#1266) and generation (#1269) are live in production too. Studio was empty at initial opening; #1265 owns registering the first client.
    Evidence
    #933 Studio login, studio-auth.ts.
    Owner doc
    Spec 933 Studio Cloudflare login
  • Generation run recordsworks
    What it does
    Stores every generation run and image attempt against the exact proposal version.
    Evidence
    Tables studio_generation_runs and studio_generation_attempts.
  • Image provider adapterworks
    State
    Merged in PR #1000 (#257 provider adapter). Real image calls ran on staging in the #979 generation proof, at $0.19 per image. See the #979 evidence.
    Evidence
    platform/src/lib/imagegen/openAIImageProvider.ts
  • Durable image generation run in the cloudworks
    What it does
    Runs generation as a job that survives crashes: database-time claims, one-shot permissions, bounded storage recovery, tenant isolation.
    State
    Merged in PR #1049 (#258 durable generation). It ran on staging in the #979 generation proof. A database cut after the image call left that attempt marked "uncertain", and the next attempt succeeded. Staging generation is now on through settings kept in the repository (#1269 committed generation flags), so a deploy no longer clears it. Production generation is live since the 2026-09-28 deploy (#1269) and waits for its first client. The new Queue handoff (#1378) is implemented and enabled on staging under #1489; production retains its prior route. It can advance one exact image or caption job per delivery while retaining database recovery state. On 2026-10-01 a staging test ran three packets through the Queue, and each got its image and its caption (Queue handoff #1378 evidence). Repeated and invalid messages started no paid call. When the Queue starts cold, it works on one image at a time first, so one packet waited about two minutes for another. Automatic repair (#1379 stranded-run repair) is merged and passed a two-packet staging test on 2026-10-02 (repair #1379 evidence). One packet lost its Queue message at the start, and the other lost its caption step. The next two-minute check finished both, and neither paid for a second image. Since 2026-10-02 the staging Queue flag stays on across deploys (#1489 staging flag durability). The 100-packet target (#1380 generation capacity) is unproven. See the #979 evidence.
    Evidence
    studioGeneration.ts, worker.ts, migration 0036.
    Owner doc
    Spec 258 durable generation
  • Caption written from the finished image, with a conflict holdworks
    What it does
    Gemini writes the caption after the image exists. If the caption conflicts with the menu facts, the post is held. A technical failure restarts only the caption and keeps the image and its cost.
    State
    Merged with #258 durable generation. Paid Gemini captions ran on staging in the #979 generation proof. A caption that passed its deadline was restarted from Studio, and the image was kept. The conflict hold has not been tested on staging. A separate staging-only Cloudflare managed caption route (#1378) is enabled on staging under #1489; production remains direct. It retains the same model, request and retry limits and refuses old-route jobs before any new provider spending. On 2026-10-01 it wrote three captions on staging through Cloudflare, each in about 15 seconds. The approved three-packet test is used up; founder quality judgment remains separate.
    Evidence
    geminiCaptionProvider.ts, table studio_caption_cycles.
  • Generate from Studio, then keep or decline the image and captionworks
    What it does
    A founder starts generation from Studio. The image and caption enter as one exact pair. A founder can decline a candidate and ask for a new creative direction for the same slot.
    State
    Merged in PR #1148 (#978 pair admission). You generated, pivoted once, admitted and approved on staging in the #979 generation proof. Nothing was sent or published. Production Studio had no screen to add a dish or write a proposal, so Nuevo paquete stayed empty. The «Preparar propuesta» panel (#1369 dish and proposal screens) adds both: you type the dish name and price, then pick the dish, the scheduled delivery and a kit photo. The server works out the rest. It is in production since 2026-10-02.
    Evidence
    StudioDecisionWorkspace.tsx, studioPacketAdmission.ts, migration 0038.
  • Dated menu facts and approval guardsworks
    What it does
    Menu facts carry the date they take effect. A fact change cancels approvals for posts that are not yet published. Generation, admission and approval all check the facts.
    State
    Merged in PR #1039 (#977 menu facts). Generation, admission and approval checked the facts in the #979 generation proof. A fact change that cancels an approval has not been tested on staging.
    Evidence
    studioMenuFact.ts, tables client_menu_fact_revisions and studio_packet_fact_invalidations.
  • Staging test-photo fixture and crash repairswitched off
    State
    Merged in PR #1001 (#976 fixture repair). Verified with simulated faults. The #979 generation proof used your own photo, so this fixture path did not run.
    Evidence
    studioStagingGenerationFixture.ts
  • Read-only report for each post in a proofworks
    What it does
    Gives a founder one report per post, read from stored records: what ran, what it cost, what failed, what comes next. It never calls a provider or changes data. Missing evidence stays "unknown".
    State
    Merged in PR #1162 (#1160 packet report). The #979 generation proof posted a completed report and an interrupted report. The #985 client approval and #993 publication proofs add their own evidence.
    Evidence
    GET /api/internal/studio/packet-report
  • Staging proof of the whole sliceworks
    What it proves
    A real generation run on staging, one complete and one interrupted, each with its report.
    State
    Done 2026-09-27. You accepted it. Your active time was about 10 minutes, and each image cost $0.19. See the #979 evidence.
    Links
    #979 generation staging proof · Spec 974 cloud packet
B Client approves the exact post on WhatsApp Staging proof complete on 2026-10-11: a real proposal, delivery, approval, change request and fresh caption successor. Production packet transport is still off. The staging test line has returned to fixture A for #309; the proof used Mimbre. 6 of 6 working
  • WhatsApp router: old-style post approvals and supervised repliesworks
    What it does
    Routes each incoming WhatsApp message on the shared number and lets a founder supervise replies. It records old-style post approvals from a button reply. Its legacy reply path does not bind an exact packet version; the separate #984 path now does.
    Safety change
    Live since the 2026-09-25 production deploy (#1195). Every AI draft now waits for León or Juanro; the router no longer auto-sends. No login-code (OTP) code exists, although the map once listed it.
    Staging line
    Since 2026-10-04 a Meta test number delivers to the staging Worker, and a founder text there gets a Gemini draft that waits for a founder (#1539 staging WhatsApp line). On staging the drafts call Gemini through the Cloudflare AI Gateway; production keeps the direct route (#1531 drafts through the AI Gateway). Merged code now records a supervised reply's outcome after the send (#1441, 2026-10-04) and removes the old /inbox reply route (#1442, 2026-10-02).
    Evidence
    platform/src/lib/whatsapp/router.ts, ADR-0006.
  • Durable inbound receipts and crash recoverystaging proven
    What it does
    Stores every signed reply before Meta gets its 200. A recovery job every two minutes uses a recent wake marker to finish work a crash left behind, with bounded retries; hourly maintenance also checks for work. Signed replies, generation commands, send approvals, evidenced retry resolutions and source uploads establish that marker before creating work. Bursts reuse it for up to 30 minutes; an unverified wake refuses new work (#1371). This wiring does not turn on transport or upload recovery. A stored receipt never counts as an approval on its own.
    State
    #981 is on main and was exercised through the real #985 round trip, including receipt-before-processing recovery. Trusted destination binding selects the tenant. The staging line is now fixture A (PR #1901); production has no packet destination binding.
    Links
    Spec 980 inbound recovery · test-typing follow-up #1182 mock type fix
  • Proposal template and media adapterstaging proven
    What it does
    Builds the exact image, full-caption, time and button request for Meta, with bounded typed evidence.
    State
    Meta approved packet_proposal on 2026-10-04. #985 sent real image-and-caption proposals through the adapter; the successor got a fresh message and approval. #1883 / PR #1894 now renders proposal time in continental Chile local time, including daylight saving.
    Evidence
    packetProposalProvider.ts, metaPacketProposalProvider.ts and packetProposalProvider.contract.md.
    Links
    #982 Meta template and media
  • Send sweep, send recovery and test-phone gatestaging proven
    What it does
    Sends each approved post once. A lost send result stays "uncertain" until evidence resolves it. On staging it sends only to an authorized test phone.
    State
    #983 is on main. #985 observed five template sends for five distinct intents, an unauthorized destination refused with zero provider calls, and recovery before submission without a duplicate. One lost result remains unresolved; #1885 lost-send confirmation owns the evidence gap. Production transport stays off.
    Links
    #983 send sweep
  • Client reply: approve, ask for changes, sent correctionstaging proven
    What it does
    Only the designated approver can approve, and only the current version. A change request pauses publication. Free text or silence never approves. After seven days without approval the post closes unpublished.
    State
    #984 merged in PR #1872. #985 exercised real approval, a change pause, a sent caption successor and fresh client approval, preserving the original seven-day deadline. Old approval did not authorize a successor. Plain-text association remains #1887. #991 and #992 supply publication admission and final effect permission.
    Links
    #984 client reply and change pause
  • Staging proof of the whole sliceclosed with gaps
    What it proves
    The same post from the #979 generation proof reaches a real test phone and a real button reply comes back, with the report extended.
    Left
    #985 closed on 2026-10-11 under the founder grant. The non-approver test was skipped (no second phone), and ambiguous text took legacy handoff. Follow-ups: #1885 lost-send evidence and #1887 text association. Time rendering #1883 is fixed. Evidence: run decisions and screenshots.
    Links
    #985 client approval staging proof
B2 Publish once, at the agreed time Staging proof closed with founder waivers on 2026-10-11: one real Instagram post, exact caption and hash-verified public copy. The Workflow and public bucket are bound on staging, but publication was switched off again after the proof. Production has no binding or publication tables. 2 of 5 working
  • Zernio client, publish and reconcile effectsworks
    What it does
    Publishes and reconciles through the configured provider. Production keeps Zernio; since #1431 staging routes the platform Zernio client to Jaiva social-api. The #993 Workflow proof used social-api staging.
    Evidence
    platform/src/lib/zernio/, platform/src/lib/effects/. The separate Jaiva-owned service under Replacement map #1320 now has connection, encrypted token custody, queued publication and dated account snapshots on main (Secure connection #1384, Durable publication #1385, Account snapshots #1386), with 343 controlled tests and real PostgreSQL passing at the reviewed OAuth adapter revision. Replays return the same stored post; an uncertain publish result pauses for reconciliation. Snapshots keep real zeros and leave missing values absent; account totals do not prove one post's performance. The staging service is deployed. Its database and queue are provisioned, secrets installed and rollback exercised. Service-owned OAuth now succeeds with separately verified app-scoped and professional IDs. Account listing proves the selected fixture is active; all three actual permissions and encrypted token custody with future expiry are verified. The founder-approved neutral image is now visible on the staging fixture with the exact caption. Replay returns the same post and media; changed content and conflicting request headers are rejected. One genuine account snapshot for September 30 is stored with four provider-supplied zeros and no unavailable metrics. It is an account observation for the previous day, not performance evidence for the new post. The offline build draft records its scope; the staging run draft plans one post and a snapshot on @jaiva_staging_fixture. Production B2 and the collector keep Zernio; staging routes the Zernio client to social-api under #1431. The production service now runs on https://social.jaiva.cl with its own database, queue and secrets (Production bring-up #1430). The initial production bring-up had no connected accounts. Its separate Meta app, Jaiva Social, still needs App Review before any client connects.
  • Public media copy with a hash checkproven, switched off
    What it does
    Copies the approved image to a public address and checks it byte for byte. The receipt proves the copy, never the post.
    State
    #990 is integrated into #992. #993 read the real public R2 copy with HTTP 200 and verified its hash against the private packet image. The staging binding exists. The publication flag is off again, so new window effects do not run.
    Evidence
    publicPacketMediaCopy.ts, table studio_public_media_copy_receipts.
  • Publication intent and timing guardproven, switched off
    What it does
    Client approval records one intent and window at the original time. Late processing pauses for founder review; a second tap changes nothing. The occurrence guard preserves possible or confirmed publication across successors.
    State
    #991 merged in PR #1879; #992 supplies the real participant and scheduling adapter. #993 admitted and scheduled the real post, preserving the occurrence guard through restart and a lost result. The flag is now off: a flag-off admission stays disabled (#1893). Fresh founder release and windows 2 and later remain #1861.
    Links
    #991 publication intent · Spec 989 publication
  • Publication workflow and recoveryproven, switched off
    What it does
    Publishes at the due time, rechecks the change pause last, and never repeats a create call that may have gone through. Unclear results go to a founder in Studio.
    State
    #992 merged in PRs #1877 and #1888. #993 registered the staging Workflow and public bucket (PR #1892), then proved one post through a restart, an injected lost-create-result and a signed callback that settled publication. No second create occurred. The flag was removed and fault triggers cleaned up. Production activation has its own human gate.
    Links
    #992 publish sweep
  • Staging proof: one real post, and crash testsclosed with waivers
    What it proves
    One real Instagram post at 13:21:46 UTC on 2026-10-11, with the exact packet caption and matching public-copy hash. Restart and callback recovery were observed; the lost result was injected by a database trigger, not a process kill.
    Left
    #993 and #989 closed with founder waivers. #1896 retains the deployed pause-wins check, later-incident retention, misleading report fields and unmeasured human active-time gate. Synchronous success and founder release remain unproven; #1861 and #1893 stay open. Evidence: run record.
    Links
    #993 publication staging proof
C Client accepts the plan and pays Not started. Plan Base terms and price exceptions are recorded; client acceptance, the next paid period and Mercado Pago answers still gate the spec. 0 of 1 working
  • Accept-and-pay link, charge and reconciliationwaits on you
    What it does
    One link where the client accepts Plan Base and starts a Mercado Pago subscription. Mercado Pago charges once a month, and Jaiva reconciles each charge.
    Left
    No slice-C spec yet. La Santa Picá must accept standard Plan Base with its CLP 25,000 monthly addendum; its next paid-period date and payment reconciliation remain open. Que Panzza has a CLP 50,000 Plan Base offer without reels, pending acceptance. K-Burgas is eligible for release proof with a CLP 1,000 price exception; the account-specific payment minimum is still to verify.
    Links
    #881 acceptance and charge · Spec 836 v1 product
D Midpoint and closing reports Metric snapshots work. #993 is closed, so the report spec no longer waits for that proof; the two client period reports are still unbuilt. 1 of 2 working
  • Metric snapshots from Zernioworks
    Evidence
    Table metric_snapshots, effect captureMetricsSnapshots.
  • Midpoint and closing period reportsplanned
    What it does
    Two reports per service period for the client. Each is written after its window closes, and a founder approves it before it goes out.
    Left
    No report spec or implementation yet. The former #993 prerequisite is closed with waivers; reporting and the broader release proof remain open.
E Client Delegate: an agent talks to each client for us Not a release gate. The phase-1 spec is on main; attribution and the conversation inbox landed, with the inbox proven on staging. Memory, turn context and default-off send guards are partially built. MCP, OAuth, send approval and progression still wait on #1214 decisions. 1 of 6 working
  • ADR: the Client Delegate pattern and its authority matrixdecided
    What it does
    Records what the Delegate may do for a client, what only the client may do (approve, accept, pay, cancel), and what only founders may do. It retires the "Orchestrator" name.
    State
    Drafted as ADR-0030, ratified 2026-09-24. It records your #1169 authority matrix and send gate decisions: each send waits as a pending intent that either founder approves on an Access page.
    Left
    Nothing. The phase-1 spec builds on it.
  • Client Capability Surface: an MCP server scoped to each client, on stagingplanned
    What it does
    The one door the Delegate uses to act for a client. It takes the client from the caller's token, never from a tool argument, so one client's message can never reach another client's data. Studio keeps its own routes: your 2026-10-02 decision scopes the Surface to the Delegate only, so founder-only actions such as packet approval and generation are never Delegate tools.
    State
    ADR-0030 and spec #1238 are on main. #1340 proved tenant ledger reads; #1591 closed with approver/Delegate attribution; #1592 closed with the staging inbox proof. #1593 memory, #1594 send flag/guard and #1595 turn context have merged code but remaining staging criteria. No MCP server, OAuth/grants or full successful Delegate-send path exists yet.
    Left
    Architecture choices remain in #1214. #1444 still owns the production runtime-role check. Preserve each ticket’s remaining staging proof; merged components do not prove the whole Capability Surface.
  • Phase 1: founders run the Delegate from their own computersplanned
    What it does
    A founder-guided Claude Code or Codex session answers and follows up with one client. A founder approves every send. Every send is ledgered and gated on the server.
    State
    Research done: #1175 workstation operation and #1176 context, memory and injection defense.
    Left
    The phase-1 contract is merged (PR #1243), rather than a pending draft. Unsolicited client text now has the #1592 tenant inbox, proven on staging. #985 is closed. The first workstation Delegate session still waits on the unresolved capability, approval and send decisions in #1214.
  • Proactive messages: trigger catalog and Meta templatesplanned
    What it does
    Heads-ups, follow-ups and suggestions, each tied to an approved template, with a frequency cap and a budget per client.
    State
    The #1170 Meta template and window rules in Chile research is done. Suggestions go only inside an open 24-hour window, v1 has no marketing template, and templates outside the window stay factual. The rule: the client's opt-in must be recorded before the first proactive message.
    Left
    A decision on the ADR-0030 amendment in #1242 proactive recommendations and check-ins (draft PR #1245) and on #1254 shared proactivity accounting. Then the gate in #1255 consent, cadence and budget and #1288 consent capture in onboarding. Nothing records client opt-in today. The price of free-form messages after 2026-10-01 is open in #592 WhatsApp pricing.
  • Stop the old router auto-replying on the client lineworks
    What changes
    #1195 removed model auto-send from the router and queues every draft for founder approval. It is live in production since the 2026-09-25 deploy.
    Evidence
    #1195 founder approval for every draft, platform/src/lib/whatsapp/router.ts.
  • Phase 2: hosted Delegate, still supervisedlater
    What it does
    The Delegate runs hosted and drafts; a founder approves each send. Each message type moves to auto-send only on its own written record.
    Left
    Research opens after phase 1 has run. The founders decided a scoped API-key exception for this agent only.
    Links
    #1168 Client Delegate map
4Waiting on you
  • La Santa Picá acceptance, next paid-period date and payment reconciliationCLP 25,000 price addendum is decided; acceptance still gates slice C
  • Decide the proactive-message amendments in #1242 and #1254The proactive Delegate path remains separate and unbuilt
  • Resolve the remaining architecture and tool-shape decisions on #1214Unblocks MCP, OAuth, approval and successful Delegate-send progression
  • Que Panzza accepts or declines the October Plan Base offerCLP 50,000 without reels is decided; no charge or release-proof place before acceptance

Around the loop

These parts feed or support the loop. They do not count toward the release bar.

Sales WhatsApp with founder approval The full supervised Sales reply loop is planned. #528 source-isolated ingress, role custody, health reads and binding reconciliation are built but dark; activation and downstream consumers remain missing. 0 of 1 working
  • Remember Sales conversations, propose replies and ask a founder before sendingplanned
    What it will do
    Keep an evidence-linked Sales conversation, draft one reply and an optional action, then show the exact proposal to León and Juanro on a separate Control number. An agent reply reaches a prospect only after a current structured founder decision and a final check of conversation freshness and Meta's 24-hour window.
    Number choice
    Prefer the existing Sales number only if official Business App and Cloud API coexistence is proven. If that fails, the existing number stays manual while a separate API-only Sales number is evaluated.
    State
    The architecture and supervised flow are defined in #782 and ADR-0029. The separate inbound transport for Sales and Control is being built switched off under #528 source-isolated transport. Receipts, recovery, the enabled route, binding-version reconciliation and founder-only health reads are merged. The enable flag is absent everywhere, so the route stays dark. Production is at migration 0080 since your production dispatches of 2026-10-06 and 2026-10-08. Sales/Control configuration, downstream consumers, activation and staging proof remain pending. The client approval line is a separate domain.
Photos, references and prospects The source registry, curation and a thin deterministic reference brief are proven on staging. One real Apify run resumed without paying twice; collection was stopped with evidence readable. Production collection and broader prospect/queue work remain gated. 2 of 4 working
  • Pitch pageworks
    Evidence
    platform/src/pages/p/[token].astro, ADR-0023. The prospect bootstrap code was never wired in, and #1208 deleted it.
  • Reference briefstaging proven
    Evidence
    #1109 / PR #1612 and reader wiring PR #1713 build versioned dossiers and taxonomy-only briefs. #1110 materialized dossier v1 and a thin brief with 12 citations; replay returned no_change. It remains below the five-positive-reference requirement. This replaces the deleted legacy first-stage path.
  • Account registry, Apify collector and Studio reference queuepartial; collection off
    What it does
    Collects public Instagram posts from reference and prospect accounts through Apify, with no Meta login. Founders approve or reject each one in Studio. Authorized photos, actual Reels and captions can enter Brand Kit analysis through customer-isolated custody and temporary run/snapshot/attempt access. Marketing-image generation retains its separate source_assets authorization gate.
    State
    #1106 custody closed after synthetic staging isolation proof. #1107, #1108 and #1109 code and #1110 routes are on main. The #1110 real staging tracer collected 11 publications and 59 quarantined assets from one USD 1.62 Apify run; Neon, ledger and R2 reconciled 59/59. Coverage is partial with a resumable cursor, not a fully drained 600-item run. The durable control was turned off; reads remained available. Production code #1858 is merged, but bucket/provision/deploy/secrets/control and smoke remain founder-gated under #1859. Broader prospect collection and the full curation queue remain incomplete.
    Links
    #1004 source-account registry · ADR-0028
  • Ask a photographer for permissionplanned
    What it does
    Ask the author of a third-party photo. Yes: use it and tag them. No answer: look-alike only, no pixels. No: never use it.
    Links
    ADR-0021
Brand Kit builder candidate The existing-Brand Kit slice closed after real staging draft, edit, activation, refresh, DESIGN.md export and caption-consumer proof. Manual production kit editing is enabled by #1866; AI preparation remains off in production. Video analysis and prospect conversion remain open. 3 of 3 working
  • Draft Brand Kit from scoped evidencestaging proven
    What it does
    The candidate reads authorized photos, video, PDF and text through a private scoped bridge. Missing sources stay as gaps. Studio shows the draft, its evidence and its history. A founder edits fields, and each edit makes a new version that protects the edited field. A founder activates one exact version. Registry PR #1328 (#1106), merged on 2026-10-02, adds producer pins for per-client photos, Reels, PDFs and captions, with temporary reads bound to the exact run, snapshot, attempt and grant. The builder does not read from the registry yet.
    State
    Generation runs through the Worker AI binding, one call per try. On 2026-10-02 one controlled run on a test client made a draft that cites photos, the menu PDF and text. A founder edit, an explicit activation and a refresh followed. The refresh kept the founder's voice text and offered its own text only as a suggestion. The model did not cite the test video, so video analysis is not proven. Execution is on in staging, and the staging deploy keeps it on (#1489). See the staging proof 2026-10-02.
    Links
    #323 Brand Kit builder · Studio contract · HTTP 403 evidence and limits
  • DESIGN.md rendered from each kit versionstaging proven
    State
    In staging, the DESIGN.md file saved for the active version matched two local renders byte for byte. It is stored under the client's own folder.
    Links
    #264 revision-bound DESIGN.md. Neon stays the source of truth.
  • Verbal identity: voice rules for posts and messagesstaging proven
    State
    Schema2 voice, audience and direction are implemented. On 2026-10-02 one staging post ran image and caption. Its caption used the active version, its hash and the founder-edited voice. See the caption proof.
Platform foundations The ledger, publishing kill-switch, stand-up reads and Studio change feed work. Delegate send guards are merged but default-off; full Delegate sending and complete ledger coverage remain open. 4 of 4 working
  • Typed effect chokepoint that writes the ledgerworks
    What it does
    Typed effect functions write the domain_event ledger in the same transaction as the change. Studio packet commands also ledger in their own transaction.
    Gap
    Coverage remains partial. #1441 records supervised replies after send; #1591 adds original approver and Delegate attribution; #1594 adds ledgered send-flag changes and refusal evidence. Full Delegate approval/progression is unbuilt, and legacy router sends are not all effect-chokepoint calls.
    Evidence
    platform/src/lib/effects/, ADR-0012.
  • Kill-switchworks
    Evidence
    Effect killSwitch. Proven on staging on 2026-07-04.
    Gap
    Publishing checks it. #1594 adds a shared send guard used by #983 and the future Delegate path, including kill-switch refusal. The Delegate flag stays off; its successful send path is not built.
  • Stand-up snapshot and source health readsworks
    Evidence
    platform/src/lib/standup/, read only. #1429 counts ready/planned posts from Jaiva’s schedule. #992 adds overdue windows, duplicate incidents and occurrence-guard holds. Migration 0058 was applied in production; that is separate from enabling the new B2 tables or publishing.
  • Studio change feed for live updatesworks
    What it does
    Keeps one change counter per client. An open Studio checks it every 5 seconds and reloads only what changed. It pauses after 5 minutes without input behind «Pausado · Actualizar» and catches up on the next input.
    State
    Proven on staging since 2026-09-28; a remote change reached another tab in 2.6 seconds. Production has the cursor tables. #1364 gives rail thumbnails a 192 px WebP variant with safe full-image fallback; the review image and bounded preload keep the original URL. Image revalidation returns 304 when the asset is unchanged.
    Evidence
    GET /api/internal/studio/changes, tables studio_change_log and studio_change_cursors.
Protected Neon infrastructure — project created, execution disabled

Protected Neon state #1387 / PR #1393 merged a separate private store for database infrastructure state and a founder-authorized plan gate. Independent review, 5,424 local tests, build and GitHub checks passed. Coordinator receipts 5913317628 and 5913684193 record the private, versioned, uniform-access GCP backend with enforced public access prevention in SOUTHAMERICA-WEST1. The verified Google owner has metadata permissions, with no object get/list/create/delete permissions. The isolated CI identity is ACTIVE under exact repository 1233171759/main/manual/workflow/environment trust, deployed from reviewed 5e46d162 with the explicit Neon workflow map; the repository default remains empty and fail-closed. Public WIF and region (aws-sa-east-1) variables are set. Observed 2026-09-30: Neon owner/administrator access and the protected key are verified; the Jaiva organization billing UI shows Free Plan / Current plan. Merged PR #1402 added private saved-plan apply. Earlier CI plan 36756445312 passed, proving permitted CI authentication, backend initialization and locked planning. Earlier CI apply 36756649030 failed in phase apply with HTTP 400; the offending field was not identified. The pinned provider defaults to a 24-hour restore window, exceeding its SDK’s six-hour Free-plan maximum. The source correction explicitly requests six hours for this project. That configuration mismatch is confirmed; its responsibility for the historical HTTP 400 remains an inference. Subsequent protected plan 36767609149 and apply 36767795075 at main 66f3eab4 verified project summer-paper-60597222, main branch br-shy-scene-b6bh45hj, Free / São Paulo / six hours. Existing projects remain unchanged; no migration occurred. Admission is disabled (NEON_PRODUCTION_ENABLED=false); applicable exact-revision gates precede any further live attempt. No provider or paid-plan upgrade is included. Lock contention, recovery and negative identity cases remain unproven.

Staging preparation #1388 declares one social-api project and one queue, with staging configuration, a one-profile seed and an attended procedure. The founder’s hostname decision selects https://social-api-staging.jaiva-staging.workers.dev for the tracer and callback; social-stg.jaiva.cl is deferred because the dedicated staging account has zero zones. No DNS move or paid setup is planned. The exact Meta staging callback is persisted and verified, with the original redirect preserved; this is not an OAuth grant. As of 2026-09-30, professional/tester access is accepted. The earlier absence from the observed Neon inventory was not a private-state/orphan audit; subsequent creation is verified above. A manual queue workflow now prepares private locked creation/no-op using the existing R2 state bucket and a separate key. The scoped Queues Write grant and queue creation succeeded through reviewed CI; queue apply 36784922158 created social-api-publication-staging. The queue producer and consumer attach to the dedicated staging Worker. The separate database has three migrations, nine tables, one seeded profile and a least-privilege runtime login. Four runtime secrets are installed atomically and retained in the existing password manager through rbwj. The selected workers.dev hostname serves health 200 with previews disabled; rollback to the closed baseline and restoration were exercised. Reviewed 2b824a9a serves version 9a619add-234f-4753-888b-675ee00e1ec7. Service-owned OAuth and token custody are proven: the fixture is active, all three actual business permissions are granted, and its token is encrypted under key version v1 with a future expiry. The separately approved post and genuine stored account snapshot are now proven in publication and snapshot receipt 5928736643. In that proof exactly one service post exists; replay keeps its identity. The stored September 30 account totals are real zeros supplied by Meta, with no missing metric converted to zero; data may lag 48 hours. Agent inspection confirms the neutral image and exact caption; founder product judgment is separate. The account owner removes the test post manually; token/connection retention and disconnect remain separate dispositions. The existing founder authority covers staging provisioning, deployment, OAuth and live proof. Identity, secret, reviewed revision/configuration and first Worker baseline/rollback readiness remain required, together with applicable protected execution gates. Configuration itself grants no authority; no new blanket staging approval is needed. Exact publication approval remains separate. Production service changes, existing-project migration, client contact and paid DNS setup remain excluded. Production B2 keeps Zernio; #993 used social-api staging through the #1431 override. This initial standalone service proof proves no release slice, so it does not change the counts or bars. Protected Neon runbook.

How agents ship code Path-based ceremony tiers and runner merge are live. Current-head gates and e2e are required; typecheck ratchets when applicable. Staging smoke can restore a failed deploy. Full tests run periodically on main, not on every PR. 2 of 2 working
  • Pull request ceremony tier from changed pathsworks
    What it does
    Changed paths select T0 (docs-only, no reviewer), T1 (one independent reviewer) or T2. The live KITCHEN_T2_AS_T1 switch permits the normal T1 runner route for confirmed T2 work. Unconfirmed tiers remain T2. Every tier retains production, customer and spending gates. Required current-head gates/e2e and applicable typecheck decide readiness. The runner merges green eligible work; authors do not bypass it.
    Evidence
    Changed-path rules in platform/scripts/ci/ceremony-tier.ts. The verifier lock, verifier-first T2 journeys and founder test approval were deleted on 2026-10-09 (#1840, #1841), under #1836 deletions 1–4. Repository policy
  • Staging check after every deploy, with automatic put-backworks
    What it does
    After each staging deploy, a test account signs in to Studio, makes a post from a fixed test photo and approves it. If any step fails, the deploy is undone and the version from before comes back. It uses one staging test client with no Instagram connection, so nothing is sent or published. Production is never touched.
    Evidence
    On 2026-10-03 a release broken on purpose (PR #1532 restore drill) was caught 1.7 seconds after the deploy and put back 3.4 seconds after it. The next deploy (PR #1537 drill revert) passed all three steps. Publishing checks join separately; this Studio smoke sends no client message or Instagram post. #1459 staging smoke · runbook
After the release Client dashboard, portal login and self-serve cancellation. 0 of 1 working
  • After release: client dashboard, portal login, self-serve cancelplanned