🗃️ Proyecto 3: memoria curada
El agente propone, tú apruebas. En este proyecto dejas de tratar la memoria bruta de Claude como fuente de verdad y armas una capa de hechos aprobados que Claude, Codex y cualquier otro ejecutor leen desde el mismo lugar — reutilizando el vault que openpcbotv3 ya opera en esta máquina.
🎯 El proyecto en una pantalla
Tener UN lugar de hechos verificados sobre ti y tus proyectos, aprobado por ti y leído por todos los ejecutores.
3 hechos promovidos de la memoria de Claude al context/overview.md de un proyecto, con fuente y fecha; AGENTS.md y CLAUDE.md indicando leer el USER.md del vault.
Una sesión nueva en Claude Y en Codex cita un hecho personal señalando el USER.md como fuente. No se copió nada de la memoria bruta en masa.
🧱 La memoria de Claude es materia prima, no fuente
El diagnóstico de esta máquina encontró 227 carpetas de memoria y 869 archivos en ~/.claude/projects/*/memory. Cada archivo es una observación que Claude consideró útil guardar: una preferencia, una ruta, un hecho de proyecto. Nada de eso pasó por tu aprobación. Buena parte está desactualizada, duplicada o contradice otro archivo escrito semanas después. Y solo Claude lee esa carpeta.
Por eso el plan trata esa memoria como materia prima: una mina de hechos candidatos, no la verdad. La verdad es lo que tú aprobaste, con fuente y fecha, en un archivo que cualquier runtime puede abrir.
✗ Copiar la memoria en masa
- ✗869 archivos se convierten en 869 archivos en otro lugar, con las mismas contradicciones.
- ✗Codex empieza a creer en hechos que Claude guardó mal en mayo.
- ✗Ninguna fuente, ninguna fecha: imposible saber qué versión es la válida.
- ✗Secretos y rutas privadas pueden irse junto con todo lo demás.
✓ Promover hecho por hecho
- ✓Lees la memoria del proyecto en el que estás trabajando y eliges lo que todavía es verdad.
- ✓Cada hecho promovido recibe fuente, fecha y alcance.
- ✓El resto se queda donde está, como historial.
- ✓El resultado cabe en una pantalla y cualquier modelo lo lee.
¿Eres nuevo aquí? La "memoria" de Claude Code es una carpeta de archivos Markdown que el propio agente escribe entre sesiones para acordarse de cosas. "Promover" un hecho es copiarlo, ya revisado, a un archivo que tú controlas. La diferencia entre ambos es una sola: la aprobación humana.
Conceptos clave
Observaciones no aprobadas, candidatas a hecho.
Lo que aprobaste, con origen y fecha.
Llevar un hecho de la memoria bruta al overview, ya revisado.
El error que hay que evitar: arrastra ruido y contradicciones.
🗄️ El vault de openpcbotv3 como overview global
No necesitas inventar la capa de hechos aprobados: ya existe en esta máquina. El bot openpcbotv3 mantiene un vault curado en ~/vault/MEMORY.md y ~/vault/USER.md. El bot propone entradas; nada se escribe sin que lo apruebes con /memoria aprovar <id>. Y el USER.md entra en el prompt de cada conversación del bot. Es exactamente el "overview global" que pide el plan.
Léelo de abajo hacia arriba: cada peldaño filtra el anterior. Solo el último peldaño, aprobado por ti, lo leen los ejecutores. La memoria bruta nunca sube directo.
📊 Lo que v3 ya hace (del README, sección Cérebro)
- •Cada mensaje tuyo se convierte en memoria clasificada como semantic (duradera: "prefiero", "siempre", "vivo en") o episodic. Una pregunta nunca se convierte en hecho.
- •Búsqueda por palabra clave (FTS5) más vector
bge-m3; contexto en el prompt limitado a 600 tokens. - •Vault curado: el bot propone, tú apruebas.
USER.mdentra en cada prompt. - •Consolidación nocturna a las 4 h, en Ollama, costo cero: fusiona duplicados y marca contradicciones.
💡 Por qué reutilizar en lugar de crear
El plan de migración dice: no reinventar. El vault ya tiene el mecanismo de aprobación, ya corre como servicio y ya lo lee un ejecutor (el bot). Solo falta apuntar Claude, Codex y dsh al mismo archivo. Crear un segundo "overview global" sería crear la segunda fuente de verdad que todo el curso intenta evitar.
Conceptos clave
MEMORY.md + USER.md, solo entra lo que fue aprobado.
Hechos sobre ti; entra en cada prompt del bot.
Duradero vs "pasó una vez".
El archivo de hechos personales que todo ejecutor lee.
✅ Flujo propone → aprueba, aplicado a un proyecto
Ahora, manos a la obra. Elige un proyecto que ya hayas migrado (Proyecto 1) y promueve 3 hechos de la memoria bruta de Claude a su context/overview.md. Tres, no treinta: el objetivo es entrenar el gesto, no vaciar la carpeta.
Listar la memoria bruta del proyecto
Objetivo: ver qué guardó Claude sobre este proyecto, con fecha. Cambia la ruta por la tuya.
MEM=~/.claude/projects/-home-nmaldaner-projetos-<meu-projeto>/memory
ls -lt "$MEM" | head -20
# leer solo el índice, que resume cada archivo en una línea
cat "$MEM/MEMORY.md"Cómo verificar: el índice lista los archivos con un gancho por línea. Si está vacío, este proyecto no tiene memoria y pasas al paso 3 con hechos del propio CLAUDE.md.
Pedirle al agente que PROPONGA, sin escribir
Objetivo: el agente lee la memoria y devuelve candidatos clasificados. Pégalo en Claude Code o en Codex, dentro del proyecto.
Lee los archivos en <ruta del memory/ de arriba>. No edites nada.
Devuelve una tabla con como máximo 8 candidatos a hecho duradero sobre este proyecto.
Columnas: hecho (una frase), tipo (hecho | preferencia | hipótesis | decisión),
archivo de origen, fecha del archivo y "¿todavía parece válido?" (sí / no / no sé).
Descarta preguntas, tareas pasadas y cualquier secreto o clave.Cómo verificar: la tabla cita el archivo de origen en cada línea. Sin origen, la línea no vale.
Aprobar 3 y guardarlos en el overview con fuente y fecha
Objetivo: tú eliges; el agente escribe solo lo que aprobaste, en el formato de la plantilla.
Apruebo los candidatos 2, 5 y 7. Agrégalos en context/overview.md,
en la sección "Hechos verificados", uno por línea, con el formato:
- <hecho> (fuente: memory/<archivo>, observado el <AAAA-MM-DD>, promovido el 2026-09-14)
Los demás candidatos NO entran. No cambies nada más en el archivo.Cómo verificar: git diff context/overview.md muestra exactamente 3 líneas nuevas, todas con fuente y dos fechas.
💡 Lo mismo en el bot
En openpcbotv3 el gesto es idéntico, solo que por Telegram: el bot envía una propuesta con id, respondes /memoria aprovar <id>, y solo entonces la línea entra en ~/vault/MEMORY.md o USER.md. Lo que acabas de hacer a mano en el proyecto es la versión manual del mismo protocolo.
Conceptos clave
Candidato con origen, tipo y fecha; todavía no vale.
Tú nombras cuáles entran; el resto no entra.
Cuándo se observó y cuándo se promovió.
Tres líneas. Si el diff es grande, algo se salió del protocolo.
🕰️ Consolidación con superseded_by: nunca borra, oculta
¿Qué pasa cuando un hecho aprobado deja de ser verdad? La v3 responde con la consolidación nocturna: cuando detecta dos memorias que se contradicen, la más antigua recibe el campo superseded_by apuntando a la nueva. No se borra, solo deja de entrar en el prompt. Puedes volver y ver lo que se creía antes.
El hecho antiguo sigue existiendo, pero punteado y fuera del prompt. El ejecutor solo ve el hecho actual. Si la nueva decisión estaba equivocada, la deshaces sin perder nada.
✓ Cómo resolver un conflicto
- ✓El origen y la decisión aceptada ganan. El timestamp solo desempata entre iguales.
- ✓La versión vencida recibe
superseded_byy sale del prompt. - ✓Backup antes de cada ronda de consolidación.
✗ Lo que rompe la memoria
- ✗"Lo más nuevo siempre gana": un archivo escrito por error borra una decisión tuya.
- ✗Borrar la versión antigua: se pierde el rastro de por qué cambiaste.
- ✗Mantener ambas activas: el ejecutor elige una al azar.
En el overview en Markdown, sin base de datos: aplica la misma idea a mano. En lugar de borrar la línea antigua, muévela a una sección "Superado" al final del archivo con la nota superado por: <línea nueva>, el <fecha>. El agente lee solo "Hechos verificados"; el historial queda para ti.
Conceptos clave
Puntero del hecho vencido al hecho que lo reemplazó.
Sale del prompt, queda en el historial.
De dónde vino y quién decidió; pesa más que la fecha.
Ronda periódica que fusiona y marca; siempre con respaldo.
🔗 Claude, Codex y dsh leyendo el mismo USER.md
El bot ya inyecta el USER.md en cada prompt porque su código lo hace. Claude Code y Codex no tienen ese código, y ningún archivo se carga solo aparte del CLAUDE.md y del AGENTS.md. La solución es la misma de todo el curso: una instrucción explícita de lectura en esos dos archivos.
Agregar la instrucción en el AGENTS.md global y del proyecto
Objetivo: todo ejecutor que lee AGENTS.md aprende dónde están los hechos personales aprobados. El CLAUDE.md lo hereda vía @AGENTS.md.
cat >> ~/.codex/AGENTS.md <<'EOF'
## Hechos personales aprobados
- Antes de asumir cualquier preferencia mía (voz, modelo de imagen, cuenta git, rutas),
lee `~/vault/USER.md`. Es la única fuente aprobada. Cita el archivo cuando uses un hecho de él.
- No propongas guardar nada ahí por tu cuenta: propónlo en texto y yo lo apruebo.
EOF
# ¿el CLAUDE.md global empieza con "@AGENTS.md"? Si no, agrega esa línea al inicio.
head -1 ~/.claude/CLAUDE.mdCómo verificar: grep -n USER.md ~/.codex/AGENTS.md devuelve la línea; head -1 ~/.claude/CLAUDE.md devuelve @AGENTS.md.
Probar en los dos runtimes
Objetivo: una sesión nueva cita el USER.md como fuente de un hecho personal. Si no cita la fuente, no pasó.
P='¿Cuál es la voz de narración predeterminada que uso? Responde en una frase y di en qué archivo lo leíste. No edites nada.'
claude -p "$P"
codex exec --skip-git-repo-check "$P"Cómo verificar: las dos respuestas nombran ~/vault/USER.md. Si una cita la memoria de Claude o "no sé", la instrucción no llegó; revisa si se está leyendo el AGENTS.md correcto.
🐳 ¿Y el dsh?
El dsh-sandbox no lee ~/vault porque el contenedor solo ve lo que se montó. En el modo local, ~/projetos está montado; el vault no. Dos salidas: montar ~/vault como solo lectura en el docker-compose.projetos.yml, o copiar el USER.md aprobado al proyecto como context/user.md con la fecha del snapshot. El Proyecto 4 trata el dsh en detalle.
Conceptos clave
La forma de "inyectar" sin código: pedir que lea.
Bot, Claude, Codex y dsh apuntan al mismo archivo.
El criterio de aceptación: una respuesta correcta sin fuente no vale.
Cuando no se puede leer en vivo, se copia con fecha y regla de actualización.
📦 Archivar sesiones antiguas, solo después de que el ciclo funcione
En esta máquina hay 6.859 sesiones JSONL de Claude (2,3 GB) y 209 de Codex. Son el historial en bruto de cada conversación. Mientras tu contexto vivía solo ahí, borrar era perder memoria. Una vez que handoff y prime (módulo 2.6) están funcionando, lo que importa de cada sesión ya pasó a handoffs/latest.md y al overview. Entonces, y solo entonces, archivar se vuelve una limpieza segura.
Semana 1: ciclo funcionando
Toda sesión termina con handoff. Cada sesión nueva empieza por el prime. Todavía no se borra ninguna sesión.
Semana 2: promoción de hechos
En los proyectos trabajados, de 3 a 5 hechos promovidos al overview (tópico 3). Lo que era memoria en bruto relevante ya está aprobado.
Semana 3: archivar, no borrar
Las sesiones con más de 90 días van a un archivo comprimido fuera de ~/.claude. Si algo falta, está ahí.
Después: rutina mensual
Un comando al mes. El disco (88% lleno hoy) lo agradece.
Paso 6: archivar sesiones con más de 90 días (reversible)
Objetivo: quitarlas del camino sin perderlas. Primero cuenta y lista; solo el segundo bloque mueve.
# 1) solo mirar: cuántas son y cuánto pesan
find ~/.claude/projects -name '*.jsonl' -mtime +90 | wc -l
find ~/.claude/projects -name '*.jsonl' -mtime +90 -print0 | du -ch --files0-from=- | tail -1
# 2) archivar (mueve a un tar.gz fechado fuera de ~/.claude; no se borra nada)
ARQ=~/projetos/output/arquivo-sessoes-claude-$(date +%Y-%m-%d).tar.gz
find ~/.claude/projects -name '*.jsonl' -mtime +90 -print0 \
| tar --null -T - -czf "$ARQ" --remove-files
ls -lh "$ARQ"Cómo verificar: el primer find ejecutado de nuevo devuelve 0; el tar.gz existe y se abre con tar -tzf "$ARQ" | head. Rollback: tar -xzf "$ARQ" -C /.
⚠️ Riesgos y rollback del proyecto
- •Promover un hecho equivocado: el diff es de 3 líneas;
git checkout context/overview.mdlo deshace. - •Archivar demasiado pronto: no archives antes de tener al menos dos semanas de handoffs. El tar.gz es reversible, pero el hábito de ir a buscar ahí no.
- •Dos fuentes de hechos personales: si creas un
context/user.mdglobal además del vault, elige uno y haz que el otro apunte a él. - •Secreto en el overview: las claves quedan en
.env; el overview cita la ruta, nunca el valor.
Conceptos clave
Comprime y quita del camino; vuelve con un comando.
Handoff/prime funcionando antes de cualquier limpieza.
En bruto, útil para auditoría; no es fuente de contexto.
Una vez al mes, el mismo comando.
Autoevaluación (opcional): Claude guardó en mayo que "el modelo de imagen predeterminado es flux2-dev" y en agosto que "es flux2-klein". ¿Qué hacer en el overview?
🎯 Resumen del proyecto
Próximo proyecto:
3.4 — Proyecto 4: tercer ejecutor (dsh-sandbox y modelo local)