Arrastre y desactualización

Un checkpoint captura una sesión. El arrastre (carry) es lo que hace que la memoria abarque muchas: los ítems que siguen abiertos — preguntas sin resolver, decisiones vigentes, trabajo sin terminar — se arrastran desde checkpoints anteriores al siguiente briefing, y siguen apareciendo hasta que algo los cierra.

El sufijo [carried]

Un ítem escrito por la sesión más reciente aparece sin marca. Un ítem que viene de un checkpoint anterior lleva un sufijo visible:

- [~ inferred] The staging config drift needs an owner [carried]

[carried] significa: ninguna sesión reciente re-confirmó esto — puede estar desactualizado. Cuanto más viejo es un ítem arrastrado, con más escepticismo hay que leerlo. El arrastre deliberadamente nunca reformula ítems — una cita verbatim arrastrada tiene los mismos bytes que el primer día (mira clases de confianza).

El arrastre es acotado, no infinito

Los ítems sin cerrar no se acumulan para siempre:

• El peso de arrastre de cada ítem decae con el tiempo, graduado por importancia. Con el piso por defecto (DAIMON_CARRY_FLOOR), las decisiones expiran del arrastre en unas 5–6 semanas; las preguntas abiertas escaladas viven alrededor de 3–4 meses.
• Se arrastran como máximo DAIMON_CARRY_MAX ítems por tipo (por defecto: 24). El corte ocurre al escribir el checkpoint, no al renderizar el briefing, así que es el presupuesto de render el que mantiene legible el briefing sin importar cuánto dure un proyecto.
• Resolver un ítem termina su arrastre de inmediato — esa es la vía prevista de salida; el decaimiento es la red de seguridad.

Todas las perillas están en la referencia de configuración, incluido DAIMON_CARRY (interruptor maestro, encendido por defecto).

Qué significa salir del arrastre

La memoria viva es un checkpoint por proyecto, y un briefing muestra solo lo que el arrastre conserva. Cuando un ítem decae — o el tope por tipo lo recorta — no se borra: sobrevive en los archivos históricos de sesión y en el índice de recall, y daimon recall <términos> lo alcanza para siempre. Pero nunca volverá a entrar a un briefing por sí solo. Ese es el trade deliberado de un producto de briefing: el conjunto de trabajo se mantiene legible precisamente porque todo lo que queda afuera solo se alcanza cuando se pide. Si el silencio de un briefing te sorprende, la respuesta es recall, no una memoria perdida.

La advertencia de desactualización

El arrastre tiene un modo de falla del que daimon advierte explícitamente: un ítem puede viajar, repetido briefing tras briefing, sin que nadie lo re-verifique contra el mundo. Que dos artefactos del propio daimon coincidan — el briefing y un checkpoint viejo — no es corroboración; son la misma fuente repetida.

Por eso, cuando el sello de última verificación de un ítem arrastrado envejece más allá de DAIMON_STALE_DAYS (por defecto: 7 días), el briefing marca el ítem mismo. Se muestra como [? unverified] en lugar de su etiqueta de confianza guardada, con la etiqueta original y la edad en un sufijo:

- [? unverified] The staging config drift needs an owner [carried] (was inferred, carried 12d)

No hay un pie de página aparte. Un ítem arrastrado y vencido es además lo primero que el briefing suelta cuando se queda sin espacio: todas las secciones comparten un único presupuesto de bytes (DAIMON_BRIEF_MAX_BYTES), y los ítems arrastrados vencidos salen antes que cualquier otro, las secciones de fondo antes que las accionables. Una sección que ocultó alguno lo dice en su propia nota:

(4 of 13 shown; 9 carried checks unverified over 7d hidden. See: daimon loops --stale)

Los ítems ocultos siguen en el checkpoint. daimon loops --stale lista con sus ids los ítems arrastrados que pasaron el presupuesto de vencimiento, y daimon loops a secas muestra cada loop abierto con su edad y una marca stale. Cuando una sección también recortó ítems solo por presupuesto, la nota apunta a daimon loops a secas, y un briefing del checkpoint de otro proyecto (un fallback o --slug) no lleva puntero. Los ítems sobre los que se espera que actúes (una supersesión marcada, una afirmación de un agente, una enmienda) salen al final, y una nota avisa cuando se ocultó alguno.

La respuesta prevista es verificar el mundo — código, git, el issue tracker — y luego o resolver el ítem (ya está hecho o está mal) o ejecutar daimon reverify con evidencia (sigue siendo cierto), lo cual reinicia el reloj.

Supersesión: arrastre que discute consigo mismo

Cuando una sesión nueva contradice un ítem arrastrado — el proyecto se comprometió con X, y después con Y — el arrastre no descarta el ítem viejo en silencio ni lo sigue inyectando como hecho. El briefing lo marca como candidato a supersesión, presentando ambos lados con los comandos de confirmar/rechazar en línea. Confirmar (daimon resolve <id>) oculta el lado obsoleto de todos los briefings futuros; rechazar (daimon reverify <id>) conserva el ítem y registra por qué. Nada se decide por ti — mira el ciclo de vida de los ítems para la mecánica completa.