Reglas vigentes​

Un ruling es la polaridad positiva del ledger de refutaciones. Una refutación registra lo que se descartó; un ruling registra lo que rige. Mismo ledger, misma maquinaria de ciclo de vida, afirmación opuesta, y la polaridad se deriva del evento fundacional, nunca de un campo que un escritor pueda fijar.

daimon ruling propose registra un candidato. Un agente puede proponer con --by agent, y un candidato es todo lo que un agente puede producir: la activación exige daimon ruling ratify de una persona en una terminal interactiva. Es la misma regla de autoridad que sostiene el resto de daimon. La identidad y la autoridad se derivan, nunca se autoafirman.

Una vez activo, un ruling se renderiza al tope de cada briefing, en cada superficie, como una sección compacta:

Standing rulings (human-ratified — honor these):
§ never deploy the payments service on a friday

Esa sección es parte del esqueleto. Sobrevive la presión de presupuesto que recorta todas las demás secciones, se renderiza antes de que exista el primer checkpoint de un proyecto nuevo, y cuando el briefing por LLM (opt-in) está activo la sección se antepone literal, nunca re-narrada por un paso generativo.

Las decisiones de diseño que conviene decir sin rodeos​

La ratificación está ligada al contenido. ruling ratify registra un hash del texto exacto que te mostró, y la activación se rehúsa si el texto almacenado cambió entre el prompt y tu confirmación. Lo que aprobás es lo que se activa, byte por byte.

Una propuesta de agente no puede cambiar lo que se renderiza. Los agentes pueden proponer una revisión o el retiro de un ruling activo, pero el texto activo queda intacto hasta que una persona resuelva la propuesta, y el fold lo garantiza por debajo del CLI: ni siquiera un ledger editado a mano puede promover las palabras de un agente a tu briefing.

El bucle de eco se cierra en la frontera de escritura. Una sección que se renderiza en cada sesión sería, si no, una fotocopiadora: la próxima captura re-extrae el texto del ruling como una creencia nueva, que decae, deriva y se renderiza dos veces. 0.31.0 filtra los ecos exactos en la admisión del checkpoint. El descarte se cuenta bajo su propio código de razón y se ve en daimon status, nunca en silencio, y el filtro falla abierto: un ledger ilegible jamás puede costarte una captura.

La sección está acotada y nunca se trunca en silencio. Los rulings tienen tope (siete por defecto, DAIMON_RULING_CAP para cambiarlo) y el texto de cada uno está acotado al momento de escribir. Si un ledger llega a tener más rulings activos que el tope, el briefing dice cuántos quedaron afuera y dónde verlos.

Los rulings no decaen. El retiro es una ceremonia humana, y daimon forget alcanza el texto de un ruling por valor como todo lo demás en el ledger.

También desde 0.29​

El visor local llegó en 0.30.0. daimon serve abre un visor de solo lectura en localhost: briefing, ledger, páginas por sesión, búsqueda como recall, una tira de verificación y una vista de impresión. 0.31.0 agrega el carril de rulings junto al de refutaciones, cada polaridad con su propio vocabulario.

Un ledger tipado de relaciones llegó en modo sombra, con verbos de adjudicación e historial renderizado en el visor.

0.30.2 corrigió un defecto real de forget: forget por valor solo comparaba contra el campo subject de una refutación, dejando cuatro de sus cinco campos de texto plano inalcanzables por valor. Se encontró durante la revisión de diseño de este release, y se corrigió y publicó antes que la feature que lo hacía importar.

Cómo obtenerlo​

uv tool install 'daimon-briefing[pretty]'

Para actualizar:

uv tool upgrade daimon-briefing

Usuarios del plugin: /plugin, actualizar daimon y recargar.

El ledger de refutaciones​

daimon refute add registra un veredicto acotado sobre un sujeto, con la evidencia citada en el momento de afirmarlo. La afirmación de un agente queda como candidata hasta que una persona ejecuta daimon refute ratify. daimon refute guard contrasta una acción propuesta contra el ledger activo antes de que repitas algo ya resuelto, y daimon refute overturn es la forma de dar de baja un veredicto cuando la evidencia cambia.

Hay dos decisiones de diseño que conviene decir sin rodeos.

Nada en el ledger se purga por antigüedad. Una refutación vale más con el tiempo, no menos: que un enfoque haya fallado hace ocho meses es justamente lo que querés ver cuando alguien lo propone de nuevo. Por eso daimon refute search lee el ledger completo sin decaimiento por edad, a diferencia del recall de checkpoints.

Y el guard es consultivo. Muestra el veredicto previo; no bloquea la acción. Un agente puede seguir adelante igual. Lo que cambia es que queda registro de lo que se le advirtió, así que un error repetido ahora se puede rastrear hasta una decisión y no hasta el desconocimiento.

Las skills que el host no podía ver​

El plugin publica dos skills, daimon-briefing y daimon-end. Estaban un directorio por debajo de donde el loader busca, así que nada falló y nada avisó. Simplemente no aparecían en la lista de skills de la sesión.

0.29.0 las ubica donde los hosts buscan, confirmado sobre una instalación real y no inferido. La misma versión suma daimon why, el lado de lectura de la evidencia de un ítem, a la skill que un agente efectivamente lee. Estaba documentado para personas e invisible para agentes.

También en esta versión​

Los rollout stems de Codex ahora resuelven al id de sesión generado.

La referencia de CLI está reagrupada por lo que querés hacer y no por subsistema.

Una nueva página de claims lista cada número que publicamos sobre daimon, cada uno con el comando que mide lo mismo en tu propia instalación. Esos comandos corren de forma local y no envían nada. Tus números se quedan en tu máquina.

Cómo obtenerlo​

uv tool install daimon-briefing

Para actualizar:

uv tool upgrade daimon-briefing

Quienes usan el plugin necesitan /plugin y recargar. La caché del plugin está fijada por versión, así que el arreglo de las skills llega con el commit de release y no con la publicación en PyPI.

Un agente que olvida un éxito lo vuelve a derivar en unos cientos de tokens. Un agente que olvida un fracaso lo vuelve a intentar: el refactor que rompió prod, la "limpieza obvia" que sostenía todo, el upgrade de dependencia que se abandonó dos veces por la misma razón. Pagás el mismo callejón sin salida cada vez que una sesión nueva entra caminando con toda confianza.

El campo recién se dio cuenta​

Tres papers aterrizaron sobre esto en los últimos dos meses.

Un paper del workshop AI4Research de ICML 2026 (arXiv:2606.21024) le pone nombre al objeto: conocimiento negativo. Su diagnóstico de los sistemas de investigación automatizada aplica palabra por palabra a los agentes de código: los fracasos "aparecen como señales locales de debugging pero rara vez se convierten en objetos de investigación durables". Su propuesta es una capa de memoria "diseñada explícitamente para el fracaso", con registros tipados y un curador separado del agente que falló, "para reducir el sesgo de autoevaluación". El paper conceptual que el espacio necesitaba. También, siendo honestos, deja abiertas las preguntas operativas: sin política de obsolescencia, sin modelo de expiración, y sus propias tablas muestran un registro de fracaso de un sistema confundiendo a otro (transferencia negativa). El concepto quedó establecido. El ciclo de vida, no.

Un reporte de campo de un equipo en producción (arXiv:2607.13091) convirtió comentarios de review aceptados en reglas de comportamiento persistentes, con una heurística de calificación que vale la pena robar textual: "¿Este error podría plausiblemente repetirse en otro contexto? Si sí, se convierte en regla." Su franqueza también vale la pena robarla: sin grupo de control, muestra chica, y esta advertencia que todo sistema de memoria debería enmarcar y colgar en la pared: "una cultura de review ruidosa puede envenenar el conjunto de reglas más rápido de lo que el paso de validación puede atrapar".

Y PROJECTMEM publicó lo más parecido a nuestro diseño: un log de eventos append-only, git-nativo, en texto plano, con una compuerta determinística pre-acción, "memoria que no se limita a responderle al agente sino que actúa sobre su próxima acción". A la categoría la llaman Memory-as-Governance. Es el nombre correcto. (Relacionado, del lado de la escritura: GovMem gobierna la promoción de memorias con una decisión promote / reject / needs-review, que es estructuralmente la misma compuerta que describimos más abajo del lado humano.)

Así que el terreno no está vacío, y no estamos reclamando un "primero". Lo que podemos ofrecer es un diseño que lleva un mes corriendo en un repo real, con las cicatrices para demostrarlo.

Cómo lo hacemos: autoría, promoción, disparo​

Nuestra versión son dos herramientas con un humano en el medio.

Los agentes escriben durante el trabajo. Cuando una sesión abandona un enfoque, conserva una rareza a propósito, o pisa un acople no obvio, el agente lo registra como scar candidato ahí mismo, bajo un contrato de autoría: un callejón sin salida necesita evidencia del intento y del abandono, una mina necesita los dos sitios acoplados nombrados, y la prosa de transcript en primera persona se descarta porque un sentimiento no es una afirmación sobre código. Cada scar activo en el repo de daimon se escribió así, durante la sesión que se lo ganó.

Sobre la cosecha automática, con honestidad. También construimos un cosechador sin LLM que mina los checkpoints de sesión buscando candidatos, porque un repo recién arrancado no tiene sesiones desde las cuales escribir. Su historial de campo hasta ahora es mayormente ruido: el primer conteo fue 4 candidatos, 0 promovibles, y el log de falsos disparos es más largo que la lista de aceptados. En respuesta se agregó un filtro de calificación que exige las mismas obligaciones estructurales al momento de escritura automática, y sus resultados todavía se están acumulando. Te lo contamos porque los recibos son el punto: medimos nuestra propia herramienta, no llegó a la vara, la enrejamos, y ahora también medimos la reja. Un sistema de memoria que no puede rechazar sus propias escrituras es el vector de envenenamiento del que advierte el paper de reglas de comportamiento.

Un humano promueve. Los candidatos caen en .scars/candidates/, nunca en el conjunto activo. La promoción es un acto humano deliberado. Es la misma conclusión a la que llegó el paper de reglas de comportamiento desde la otra dirección: la calidad de sus reglas "depende de la calidad del review humano", y las reglas malas amplifican errores. Una memoria de fracasos auto-promovida es un vector de envenenamiento con diagrama de flujo.

Scar dispara. Scar es la mitad de enforcement: los scars promovidos llevan anclas, y cuando un agente está por editar código anclado, el scar se inyecta antes de que corra la herramienta de edición. No en el commit, cuando el error ya está hecho y stageado. Antes de la edición.

Esa última distinción no es solo nuestra; es el propio roadmap de PROJECTMEM. Su sección de trabajo futuro describe "moverla a la frontera de tool-call del agente (un hook pre-acción)" para que la compuerta avise "en el instante en que un cambio empieza a parecerse a uno que ya falló—interviniendo antes de la edición, no en el commit". Esa es la compuerta que Scar entrega hoy. Y para ser igual de claros con la otra columna: PROJECTMEM tiene un paper publicado y unos doscientos stars; Scar tiene tres. Esto es una nota de diseño, no un reclamo de madurez.

Las dos piezas que no vimos en ningún otro lado​

Una condición de falsación en cada scar. Cada scar registra expires.condition: el cambio específico que lo volvería obsoleto, más una fecha de revisión que el linter hace cumplir. La condición en sí hoy es disciplina de autoría, todavía no verificada por máquina; el punto es que existe al momento de escribir. El conocimiento negativo se pudre distinto que el positivo; un hecho que queda viejo está mal, pero una advertencia que queda vieja es fricción que entrena a todos a ignorar advertencias. Ninguno de los papers de arriba tiene modelo de expiración. Uno hace crecer su conjunto de reglas monotónicamente y nunca borra nada. El paper del workshop ni trata la obsolescencia. Dejar escrita la condición bajo la cual una advertencia debe morir es, hasta donde sabemos, terreno todavía sin reclamar.

El fence. Los callejones sin salida y las minas son memoria de fracasos. El tercer tipo de scar no lo es: un fence protege código que se ve mal a propósito. El timeout de menos de un segundo que parece demasiado apretado pero acota un presupuesto real. El bloque duplicado que dos sistemas no deben compartir. La memoria de fracasos le dice al agente "no repitas este intento". Un fence le dice "no limpies esto". Ningún esquema de registro de fracasos que hayamos encontrado representa eso, y en la práctica dispara todo el tiempo, porque limpiar rarezas intencionales es exactamente lo que un agente capaz quiere hacer.

Lo que no estamos reclamando​

No hay tasa de prevención medida. Ni nuestra ni de nadie: PROJECTMEM nombra "fracasos-prevenidos-por-commits" como el benchmark faltante de toda la categoría, y el paper de reglas de comportamiento titula una sección "The Missing Benchmark". Estamos de acuerdo, y no vamos a llenar ese hueco con una sensación. Lo que tenemos son recibos de capturas individuales: un scar que marcó un riesgo de denegación de servicio por regex que había pasado tests unitarios y review, y un fence que disparó en medio de un build y cambió el piso de timeout de un wizard esa misma tarde. Anécdotas, etiquetadas como anécdotas.

Si querés que la mitad de fracasos de la memoria de tu agente exista: Scar entrega el contrato de autoría como skill cargable y dispara los scars promovidos, daimon borradorea candidatos de arranque en frío desde los checkpoints de sesión, y el formato es una página de YAML y prosa que podrías implementar vos mismo en una tarde. Los callejones sin salida que ya pagaste son el conocimiento más barato que vas a entregar jamás.

Queríamos esa funcionalidad. La re-observación independiente debería fortalecer una memoria — así funciona la evidencia en todos lados. Pero antes de construirla salimos a buscar las formas en que se rompe, y lo que encontramos cambió el diseño, el release y una suposición de seguridad con la que veníamos conviviendo. Todo eso salió hoy en v0.22.0.

El eco en nuestra propia casa​

Daimon inyecta memoria previa en las sesiones nuevas: un briefing al inicio y una línea daimon recall: cuando un prompt coincide con trabajo pasado. Ese texto inyectado pasa a formar parte de la transcripción de la sesión nueva. El serializador después lee esa transcripción para extraer lo que la sesión aprendió.

¿Ves el bucle? Un ítem de la sesión A se inyecta en la transcripción de la sesión B, y la extracción de B puede "observarlo" ahí — no porque el hecho se haya re-derivado de trabajo real, sino porque daimon se citó a sí mismo. En nuestro propio corpus, trece transcripciones cargan ítems previos inyectados. Un contador ingenuo de corroboración ("otra sesión lo vio de nuevo") contaría los ecos de daimon como testigos independientes, y los ítems más recordados acumularían la mayor confianza. La frecuencia de recall se volvería verdad.

Se puso peor antes de mejorar. Mapeando las superficies de inyección encontramos que nuestro verificador de citas comparaba las citas verbatim contra la transcripción sin filtrar. Una cita copiada de una línea inyectada por el propio daimon pasaba la verificación y se guardaba como verbatim, quote_verified: true — un ítem de una sesión anterior lavado como si fuera recién atestiguado. Ese agujero no esperó a la funcionalidad de corroboración: salió como fix de seguridad independiente el mismo día en que se encontró, y la verificación ahora rechaza cualquier cita cuyo único soporte esté dentro de la salida del propio daimon. Los ecos rechazados tienen su propia razón en el ledger (echo-only), así que la tasa de eco ahora se puede medir en vez de ser invisible.

La prueba de que la versión ingenua no se puede parchar​

Esto no es solo un bug nuestro. Un paper reciente — Securing LLM-Agent Long-Term Memory Against Poisoning: Non-Malleable, Origin-Bound Authority with Machine-Checked Guarantees — demuestra, con teoremas TLA+ verificados por máquina, que las defensas basadas en el contenido de un ítem o en su historial de derivación no son sólidas. Los atacantes lavan orígenes no confiables por tres canales: el propio resumen del agente, los ecos de herramientas confiables y la corroboración fabricada — plantar fuentes que coinciden para que la coincidencia se lea como verificación.

Ese tercer canal es exactamente el bucle de auto-referencia de arriba, con nombre de primitiva de ataque y un resultado de imposibilidad detrás. La reparación que prescribe el paper: ligar el origen al momento de escritura es necesario, y la autoridad ligada al origen con elevación por corroboración resistente a Sybil es suficiente. En corto: fija de dónde vino una afirmación en el momento en que se escribe, y cuenta la coincidencia solo cuando la independencia se pueda probar desde esos orígenes — nunca asumirla desde la coincidencia misma.

Qué trae v0.22.0​

Nuestra implementación de esa prescripción, en una CLI local-first:

• Origen ligado al escribir. Cada ítem queda estampado con la sesión y el autor que lo escribió por primera vez, en la frontera de admisión, sobre el mismo riel que nunca se reescribe donde vive su identidad. Si un modelo emite sus propios campos de origen, se le quitan — una memoria no puede emitirse un testigo a sí misma.
• Independencia probada desde los orígenes. Una re-observación cuenta solo cuando el escritor original es una sesión distinta, la observación nueva es verbatim local con cita verificada (lo que, después del fix del eco, excluye estructuralmente la salida del propio daimon), la coincidencia es lo bastante fuerte para certificar y no solo deduplicar, y las dos observaciones no comparten anclajes de mensajes de transcripción.
• Un conteo auditable, nunca un puntaje guardado. Las corroboraciones son eventos en el log append-only, uno por testigo independiente. El conteo se deriva al leer. La contradicción manda: un ítem superseded o contradicho por el world-check pierde su insignia, y reabrirlo no restaura conteos ganados antes de la contradicción.
• Un eje aparte, no una promoción de confianza. Los ítems vistos independientemente dos veces se muestran como [≈ corroborated ×2] al lado de su clase de confianza. La clase en sí nunca sube por recurrencia — eso sigue exigiendo evidencia de re-verificación o una decisión humana explícita.
• Conectado a nada, a propósito. La insignia no afecta ningún ranking ni el scoring de recall, y un test impone que el código de scoring ni siquiera pueda importar el lector de corroboraciones. El bucle auto-reforzante — la promoción sube la saliencia, la saliencia sube la inyección, la inyección fabrica la próxima corroboración — se cierra exactamente donde un contador alimenta el ranking, así que ese cable queda cortado hasta que los datos de campo digan otra cosa. Publicamos la medición antes de que nada actúe sobre la medición.

Qué no hace​

Sección de honestidad, como siempre. La corroboración solo se acumula sobre ítems escritos desde v0.22.0 en adelante — los orígenes nunca se adivinan retroactivamente, porque una adivinanza errada haría parecer independientes a observaciones dependientes. Una sesión reanudada que repite la misma conversación bajo otro id se rechaza donde el host preserva los ids de mensaje, pero un host que emite ids frescos puede hacer que una conversación parezca dos. Un atacante que controla el contenido de dos sesiones separadas todavía puede fabricar dos orígenes — el diseño sube el costo del acuerdo falso de una línea de recall a dos sesiones comprometidas; no lo vuelve imposible. Y los checkpoints de compañeros de equipo no corroboran en esta versión: una copia sincronizada de una afirmación sigue siendo un solo testigo, y las compuertas que harían el conteo entre autores resistente a Sybil están diseñadas pero deliberadamente apagadas por ahora.

El release completo también trae el endurecimiento del gateway de escritura sobre el que se apoyó este trabajo: borrado por valor de punta a punta, un guard de auditoría de escritura sobre cada comando, y contenido entrante de equipo pasando por las mismas compuertas de scope, redacción, forget y confianza que las escrituras locales.

Si la memoria de tu agente te dice algo dos veces, pregúntale quién se lo dijo primero. daimon ahora puede responder.

Las tres llegan con la misma tipografía, el mismo tono seguro y ninguna forma de distinguirlas. Ese es el problema real de la memoria de agentes, y no se arregla recordando más cosas.

Dos poblaciones, dos formas de fallar​

Daimon etiqueta cada ítem que arrastra con una clase de confianza, visible en la línea misma:

- [✓ verbatim] PR #60 esperando review  — "review requested 2026-07-01"
- [~ inferred] La tormenta de reintentos vino de un deadline compartido entre tres llamadas

La etiqueta no es decoración. Las dos clases fallan de maneras distintas:

• Un ítem verbatim puede quedar viejo (el mundo siguió andando después de la cita) pero no puede estar mal recordado. La cita es lo que se dijo.
• Un ítem inferido puede estar viejo y además equivocado. El modelo pudo haber leído mal la sesión en el momento exacto en que escribió el resumen.

Esa diferencia debería cambiar qué hacés con la línea. Una cita vieja pide verificar contra el mundo. Una inferencia equivocada va a la basura. Meter las dos en la misma bolsa de "la memoria dice" destruye la distinción justo cuando más la necesitás.

El verificador tiene que ser más tonto que lo que verifica​

Una clase de confianza no vale nada si el modelo se la asigna a sí mismo. Un modelo que alucina una cita también va a etiquetar felizmente esa alucinación como verbatim.

Así que el modelo no vota. Al momento de serializar, cada cita candidata se compara contra el transcript renderizado con un verificador determinista: operaciones de string puras, sin LLM, sin criterio. La cita que coincide recibe el sello. La cita que no coincide baja a ~ inferred en el acto, y se conserva, no se borra. Sobrevive la afirmación; lo que no sobrevive es la certificación.

Sobre este principio se apoya todo el diseño. El verificador tiene que ser más tonto que lo que verifica, porque cualquier cosa lo bastante inteligente como para que el extractor la engañe no es una verificación.

El problema difícil: una cita perfecta puede ser perfectamente falsa​

Acá está la parte que tuvimos mal durante meses, y la razón de este post.

La coincidencia verbatim certifica transcripción, no verdad.

El fallo que nos lo enseñó: un agente terminó una sesión larga y escribió "serialización exitosa" en su propia memoria. No había sido exitosa. La sesión siguiente leyó esa línea, creyó que la capa de memoria estaba sana y construyó sobre unos cimientos que no existían.

Cada paso es fiel. El modelo lo dijo. El transcript lo registra exacto. El verificador de citas lo encontró en el transcript y lo selló como ✓ verbatim, correctamente. La clase de confianza hizo su trabajo y la memoria igual era falsa, porque lo que se estaba certificando era que la frase se dijo, no que el evento pasó.

Los resultados necesitan un testigo, no una cita​

Desde la 0.20, las afirmaciones que declaran un resultado terminado tienen que pasar por una segunda vara.

Si el texto de un ítem afirma que algo terminó (funcionó, se mergeó, se deployó, los tests pasan, salió) tiene que citar una señal concreta de esa misma sesión: un resultado de herramienta, un exit status. Algo que la sesión haya producido de verdad, no algo que el modelo concluyó.

Una afirmación de resultado que cita una señal real sigue siendo verbatim. Una afirmación de resultado sin cita, en una sesión que sí produjo señales, baja a ~ inferred. La cita y su sello de verificación quedan, porque la transcripción sigue estando honestamente atestiguada. Lo que queda sin testigo es el resultado.

Un resultado sin testigo es un reporte, no un hecho.

Dos límites deliberados en esa regla, los dos en la dirección de no hacer nada antes que adivinar:

• Los condicionales no son afirmaciones. "se va a mergear" es un plan. "si el deploy funcionó" es una pregunta. No se tocan.
• Las sesiones sin señales nunca bajan de clase. Hay hosts que no exponen ningún resultado de herramienta parseable. Ahí verificar es imposible, y la ausencia de evidencia sobre el host no es evidencia contra la afirmación.

Lo que nada de esto arregla​

Las clases de confianza te dicen de dónde salió una afirmación. No te dicen nada sobre si sigue siendo cierta.

Una cita ✓ verbatim con un resultado de herramienta real detrás está completamente atestiguada y queda vieja en el instante en que alguien mergea el PR que describe. La procedencia no es actualidad, y fingir lo contrario sería el mismo error una capa más arriba.

Por eso cada briefing abre con un bloque VERIFY BEFORE TRUSTING en lugar de un resumen, y por eso la 0.20 suma un chequeo opcional que vuelve a leer el estado externo al momento de armar el briefing y marca de forma visible las afirmaciones que el mundo ya contradijo. Estamos midiendo cada cuánto salta eso antes de decir nada sobre el tamaño del problema.

Probalo​

uv tool install 'daimon-briefing[pretty]'

La mecánica completa está en la página de clases de confianza, con carry y obsolescencia para la mitad de actualidad y receipts para qué pasa si alguien edita un checkpoint después de escrito. Código e issue tracker: Daily-Nerd/daimon.

El servidor MCP: memoria para hosts que no podemos hookear​

El loop de captura de daimon se conecta a los hosts mediante hooks. Muchas herramientas compatibles con MCP no tienen superficie de hooks — hasta ahora, simplemente no podían ver la memoria de daimon. daimon mcp serve resuelve la mitad de lectura:

daimon mcp serve   # JSON-RPC sobre stdio, bloquea hasta EOF

Cuatro herramientas, todas de solo lectura: daimon_recall (búsqueda con procedencia completa — clase de confianza, autor, estado de supersesión, proyecto de origen), daimon_brief (el último briefing, etiquetado por confianza), daimon_projects (todo lo que daimon recuerda) y daimon_status (salud de la captura). Biblioteca estándar pura, cero dependencias nuevas — el mismo trato que el resto de daimon.

Solo lectura es una posición de diseño, no una limitación. Las escrituras quedan en el pipeline de captura, donde cada afirmación verbatim se verifica mecánicamente contra una transcripción real. Un agente puede leer la memoria por MCP; no puede insertar recuerdos nuevos. Y el servidor hereda la disciplina entre proyectos de daimon: las lecturas están acotadas al proyecto, y un proyecto sin checkpoint recibe exactamente ese mensaje — nunca el contenido de otro proyecto.

La referencia de MCP tiene los snippets de registro para Claude Code, Windsurf, Cursor y cualquier config stdio genérica.

Sale daimon forget: borrado con tombstone​

En el post anterior lo anunciamos mergeado — ahora está publicado. daimon forget elimina un ítem del checkpoint vivo, del índice de recall y del contenido del rastro de auditoría, mientras el flujo de eventos conserva un tombstone con el hash del contenido. Con receipts activos, el checkpoint posterior a la eliminación se re-firma. Podés demostrar que el borrado ocurrió sin conservar lo borrado. La mecánica está en la página de ciclo de vida de los ítems.

La caché de fragmentos: los reintentos dejan de re-pagar trabajo terminado​

La serialización extrae memoria de las transcripciones por fragmentos, y hasta ahora una corrida fallida tiraba a la basura cada fragmento que sí había salido bien — el reintento volvía a pagar todo, en tiempo y en tokens. La 0.19 agrega una caché direccionada por contenido para las extracciones: un heal o un reintento reutiliza cada fragmento cuyo contenido no cambió y solo paga lo que falta de verdad. Primera rebanada de un arco más largo de serialización incremental.

Y el sitio de docs en sí​

Inicio rápido (de la instalación al primer briefing en una página), páginas de conceptos para las ideas que hacen distinto a daimon — clases de confianza, arrastre y obsolescencia, receipts, ciclo de vida — guías de hosts, configuración, memoria de equipo. Cada página en español además de inglés, escrita para quienes desarrollan en español, no volcada por máquina. Este blog (con RSS) es el hogar canónico de los anuncios; el README ahora simplemente apunta aquí.

Actualizar​

uv tool install --force 'daimon-briefing[pretty]'

Todos los detalles en el changelog. Si algo se rompe, el issue tracker lee todos los reportes.

Qué salió esta semana​

daimon 0.18.0 está en PyPI (uv tool install 'daimon-briefing[pretty]'). El experimento principal: scene traces por ítem, opt-in, indexadas para recall. Sale detrás de un flag mientras la sometemos a un A/B contra nuestro propio benchmark — si los números no la justifican, no se activa por defecto. Ese es el trato que hacemos con cada feature.

daimon forget está mergeado y sale en el próximo release: eliminación de ítems con un evento tombstone. El ítem sale del checkpoint vivo, del índice de recall y del contenido del rastro de auditoría — pero el flujo de eventos conserva un tombstone con el hash del contenido, y con receipts activos el checkpoint posterior a la eliminación se re-firma. Borrado que puedes demostrar que ocurrió, sin conservar lo borrado. La página del ciclo de vida de los ítems cubre la mecánica.

La documentación se volvió bilingüe. Cada página — inicio rápido, conceptos, hosts, configuración, memoria de equipo — está disponible en español. No es un volcado de máquina: está escrita para desarrolladores que leen en español, porque la comunidad hispanohablante de agentes merece documentación de primera, no una ocurrencia tardía.

Windsurf está validado en uso real. El ciclo de captura (serialización desde transcript nativo) ya fue probado de punta a punta en uso real de Windsurf, sumándose a Claude Code. Codex sigue; Gemini espera un arreglo upstream.

Por qué existe este proyecto, en un párrafo​

Tu agente olvida todo entre sesiones, y la mayoría de los sistemas de memoria lo "arreglan" almacenando texto que un modelo escribió sobre lo que pasó — sin manera de saber qué partes son citas y qué partes son conjeturas. daimon marca cada ítem recordado como verbatim (una cita exacta, verificada mecánicamente contra el transcript por un verificador determinista — ningún LLM calificando su propia tarea) o inferido (puede evolucionar, se señala para verificación). Una encuesta reciente de la investigación en memoria de agentes llama a la procedencia a nivel de afirmación un problema abierto; nosotros creemos que la respuesta es hacer la memoria demostrable, y ese es el eje sobre el que está construido todo esto.

Pronto más — releases, historias de guerra del campo, y análisis a fondo de cómo funciona la maquinaria de verificación. Suscríbete por RSS o sigue el repo en GitHub.