Memoria en disco

El taller recuerda en disco — ledger, resume, board, ficha de la última sesión. La ventana de chat no es memoria.

Qué es#

Un conjunto pequeño de archivos Markdown planos que sobreviven al final de una ventana de chat.

Archivo Qué contiene Quién lo escribe
.workflow/RESUME.md Dónde está parado el taller; lo primero que lee un asiento nuevo Tú y el Chair
.workflow/LEDGER.md La lista numerada de requisitos, una línea - [ ] N. por ítem Tú y el Chair
.workflow/BOARD.md El board vivo: sesiones abiertas, claims, veredictos Orchemax y el Chair
<proyecto>/docs/TRACKER.md Tabla de estado por proyecto: status, SPEC, evidencia Los agentes del proyecto
.orch/LAST_SESSION.md Ficha telegráfica del asiento que acaba de cerrar Orchemax, al cerrar
.orch/MEMORY_BRIEF.md Brief durable y corto, cuando la memoria está activa Orchemax
.orch/ORCH_RUNTIME.md La identidad de este asiento: sesión, agente, rol, pista de MCP Orchemax, al abrir

orch init siembra los tres primeros; el resto aparece a medida que trabajas.

Por qué existe#

Porque el chat es efímero y todo el mundo sigue fingiendo que no. La ventana de contexto de un modelo termina, se compacta o mañana la reemplaza otro modelo. Todo lo que tenga que sobrevivir a la ventana tiene que ser un archivo — y un archivo que el siguiente agente pueda encontrar sin que se lo expliquen, que es la razón de que las rutas sean fijas y no configurables por proyecto.

La segunda razón es el arbitraje. Cuando dos sesiones discrepan sobre qué se decidió, un bloque ## Clarified en el ledger lo zanja y una transcripción de chat no.

Cómo se relaciona con el resto#

  • El verify_report de un worker y el veredicto de guardrails que Orchemax observa al cerrar la sesión caen ambos en el board, así que el board es el único lugar donde la mitad reportada y la observada quedan lado a lado.
  • task_claim / orch task claim <ledger-file> <item> pone exactamente un dueño sobre una línea - [ ] N., visible en el board y liberado cuando la tarea termina o la sesión se recoge. Dos agentes no pueden tomar el ítem 12 en silencio a la vez.
  • El skill sellado orch-recall existe para que un asiento nuevo lea .orch/LAST_SESSION.md en lugar de pedirte que vuelvas a explicar el proyecto.

Horizonte medio (no claude-mem)#

Orchemax no copia herramientas que observan cada tool call hacia un almacén vectorial de meses. La memoria es:

  1. Verdad en disco — LEDGER / RESUME / BOARD / LAST_SESSION (decisiones durables).
  2. Inject mínimo — LAST_SESSION ≤ 2400 bytes y MEMORY_BRIEF ≤ 1200 bytes en la orientación del asiento; el brief por defecto son como máximo 8 entradas de los últimos memory.horizon_days (default 14).
  3. Recall bajo demanda — memory_recall con limit + max_bytes (~2 KB).
  4. TTL tipado en SQLite — memory.retention_days caduca el ruido en días (context 3, observation 7, event/error 14, decision/goal/learning 30, instruction/preference/fact 45).

La doctrina (GATES.md, principles, skills) es permanente en disco — no es memoria SQLite. Ajusta inject/horizonte en Ajustes → Memoria. Nunca vuelques transcripciones de chat (estilo agent-recall) a un asiento nuevo.

Buscar en ella: memory_recall#

La herramienta MCP memory_recall (y orch memory recall en la CLI) no se queda en las entradas durables de memory_remember. También busca en los fragmentos de contexto indexados por ctxstore y grepea .orch/LAST_SESSION.md y .orch/MEMORY_BRIEF.md con la misma consulta, así que "¿esto ya se decidió?" tiene una sola respuesta en vez de tres lugares para revisar a mano. La búsqueda en sí es de texto completo (SQLite FTS5 donde el driver embebido lo tiene, un escaneo de subcadenas donde no), no solo de coincidencia exacta, así que una consulta por "budget" también encuentra una entrada que dice "budgets". limit acota los hits por fuente; max_bytes (2 KB por defecto) acota la respuesta total para que un recall nunca se convierta en una segunda transcripción.

Encoger un archivo es decisión humana#

.workflow/BOARD.md y .orch/LAST_SESSION.md crecen. Cuando uno se vuelve inmanejable:

orch memory condense

Corre a través del gateway del workspace y nunca es automático: ningún umbral de tamaño lo dispara. Preserva ## Clarified y ## Ownership byte por byte, conserva cada casilla abierta y deja el original al lado del archivo. A propósito no hay herramienta MCP para esto: un agente no puede decidir olvidar por ti.

El hook opcional context.hooks.pre_compact corre el mismo condensador justo antes de que un harness compacte su propio contexto. Como todo hook, está apagado hasta que tú lo enciendas — ver Hooks y guards.

Huella y recorte (0.5.0)#

Orchemax libera lo que ocupa. Mide su propia huella (caché de compilación, worktrees, scratch y logs) en orch stats, recorta la caché de compilación de Go cuando está inactivo y supera su límite, elimina binarios orch sueltos al arrancar y libera los worktrees de workers muertos sin perder sus ramas ni su trabajo sin confirmar. Ver Versión 0.5.0.

Aquí no hay nada que ejecutar#

Leer estos archivos es el punto; escribirlos es edición común. memory_recall los lee por ti bajo demanda; el único comando que corres tú es orch memory condense, y solo cuando un archivo quedó demasiado grande, no por calendario.