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 | orch 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 | orch, al cerrar |
.orch/MEMORY_BRIEF.md |
Brief durable y corto, cuando la memoria está activa | orch |
.orch/ORCH_RUNTIME.md |
La identidad de este asiento: sesión, agente, rol, pista de MCP | orch, 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_reportde un worker y el veredicto de guardrails que orch 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-recallexiste para que un asiento nuevo lea.orch/LAST_SESSION.mden lugar de pedirte que vuelvas a explicar el proyecto.
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.
Aquí no hay nada que ejecutar#
Leer estos archivos es el punto; escribirlos es edición común. El único comando de esta página es orch memory condense, y lo corres cuando un archivo quedó demasiado grande, no por calendario.