Un agente no puede entregar trabajo a la siguiente persona o proceso confiando solo en una transcripción de chat. La decisión pertinente puede estar enterrada entre muchos turnos, y el estado del repositorio puede haber cambiado después de que se tomó la decisión. El trabajo de VALESKA del 9 de junio añade dos ayudas deliberadamente distintas: un comando compartido para una captura de memoria significativa y un hook de Stop que registra una pequeña instantánea mecánica cuando un agente devuelve el control. Un lanzador separado hace que el servicio de memoria pueda iniciarse desde cualquier repositorio. Juntos abordan la repetibilidad en el punto de relevo, mientras dejan el juicio sobre lo que importa en manos del agente o del operador.
La captura es deliberada; el registro del turno es mecánico
El nuevo ayudante de captura publica un pensamiento en el endpoint de memoria de VALESKA. Acepta un tipo de pensamiento, proyecto, identificador de agente, etiquetas, alcance de visibilidad y contenido. Cuando no se proporciona ningún proyecto, detecta el repositorio y aplica un mapa limitado de sustituciones de slug. Su contenido puede llegar por entrada estándar, lo que evita problemas de comillas de shell cuando el relevo contiene rutas, salida de comandos o razonamiento de varias líneas. Una solicitud correcta devuelve el identificador del pensamiento; una solicitud fallida sale con un error. Esta es una ruta común implementada para que un agente registre una decisión, acción, insight o resumen de sesión sintetizado.
El hook de Stop tiene una tarea distinta. Lee la entrada del hook, le pide a Git la rama y el estado del árbol de trabajo, y luego agrega una línea de JavaScript Object Notation (JSON) con una marca temporal, identificador de sesión, directorio actual, rama y hasta cincuenta archivos modificados. Deliberadamente no publica un elemento de memoria para cada turno. Un evento de fin de turno tiene poca señal por sí solo, y la prosa automática con esa frecuencia empeoraría la recuperación posterior. El registro es evidencia para una síntesis posterior, no un sustituto de ella. Su comportamiento ante fallos también es intencionalmente tolerante: un problema de registro no debe impedir que el agente devuelva el control.
Un punto de entrada estable
El lanzador del Model Context Protocol (MCP) aborda una fuente más silenciosa de fallos de relevo. Un cliente de standard input/output (stdio) inicia un servidor en el directorio actual del cliente, que puede ser cualquier proyecto en lugar del repositorio de VALESKA. El lanzador cambia a la raíz de VALESKA, coloca esa raíz en la ruta de importación de Python y ejecuta el servidor en el mismo proceso. Eso hace que la configuración relativa y las importaciones de paquetes se resuelvan desde la ubicación esperada sin dejar atrás un proceso envoltorio. Es una corrección de lanzamiento, no una afirmación de que el servicio esté disponible, autorizado o sano en todos los entornos.
Lo que establece esta evidencia
Los commits de origen establecen que estos scripts existen con el comportamiento indicado. No establecen que todos los agentes adopten el ayudante de captura, que cada sesión produzca un buen resumen o que la memoria resultante sea útil al recuperarla. Esas son preguntas de práctica observada. La pregunta de trabajo es si un registro mecánico corto más una captura escrita conscientemente permite que un nuevo agente reconstruya una tarea con suficiente precisión para continuar sin reabrir toda la transcripción. La siguiente prueba es usar este camino en varios relevos reales, comparar el estado reconstruido con el repositorio e inspeccionar si los registros capturados son lo bastante específicos para recuperarse y actuar sobre ellos.
Base histórica: hitos de repositorio del 2026-06-09, commits 94ec996 y 88bb67a.