🏷️ Dueños de la información
Hecho, preferencia, hipótesis, decisión. Cuando tienes tres versiones de la misma información repartidas entre la memoria, CLAUDE.md y sesiones antiguas, ¿cuál vale? Este módulo da la respuesta: cada tipo de información tiene un dueño, un origen, una fecha y una regla de actualización. Eso es lo que hace que el "cerebro" sobreviva al cambio de modelo sin convertirse en un desorden.
🧩 Los cuatro tipos y por qué mezclarlos rompe todo
Toda información que vive en tu workspace es de uno de cuatro tipos: un hecho (algo verificado, con fuente), una preferencia (cómo te gusta que se hagan las cosas), una hipótesis (algo que parece verdad, pero nadie confirmó) o una decisión (una elección aceptada, con contexto y consecuencias). El error más común de quien usa agentes es meter todo en la misma bolsa: la memoria automática de Claude guarda "el usuario prefiere X" junto a "el puerto del servidor es 8000" junto a "creo que el build se rompió por culpa del caché". Tres tipos distintos, tratados como iguales.
Lee cada caja de arriba hacia abajo: el tipo, un ejemplo real de este curso, quién es el dueño, la regla que cambia la información y dónde vive. Solo el hecho tiene brillo porque es el único que exige fuente; la hipótesis tiene borde punteado porque es provisional por definición.
¿Nuevo aquí? "Fuente" es de dónde vino la información: un archivo, un comando que ejecutaste, una página. Un hecho sin fuente es solo una frase que alguien escribió algún día. "Provenance" (procedencia) es la palabra técnica para eso: el rastro de origen de un dato. Lo vamos a usar bastante en este módulo.
✓ Separado por tipo
- ✓Un agente nuevo sabe en qué puede confiar y qué necesita verificar.
- ✓Una preferencia no se convierte en "verdad sobre el mundo".
- ✓La hipótesis envejece y se descarta sin piedad.
- ✓La decisión tiene contexto: se puede revocar sabiendo el porqué.
✗ Todo en la misma bolsa
- ✗Un "creo que" de hace tres meses se convierte en instrucción obligatoria.
- ✗El agente cita una suposición como si fuera un hecho verificado.
- ✗Nadie sabe quién puede cambiar qué.
- ✗Al cambiar de modelo, el ruido migra junto con la señal.
Conceptos clave
Verificado, con fuente y fecha. Cambia solo con una nueva fuente.
Cómo lo quiere el dueño. Solo el dueño la modifica.
Provisional. O se convierte en hecho o se descarta.
Elección aceptada con contexto y consecuencias.
📇 Origen, alcance, fecha, estado, regla de actualización
El Prompt B (el megaprompt de workspace portátil) pide que toda nota durable registre cinco cosas: un ID, el alcance (¿vale para este proyecto? ¿para este cliente? ¿para todo?), la fuente, la fecha de observación y el estado (borrador, aceptado, revocado), más una regla de cuándo revisar o expirar. Parece burocracia. No lo es: es lo mínimo para que un agente que nunca vio el proyecto pueda responder "¿de dónde salió esto y todavía vale?".
Nota durable de ejemplo — el encabezado que el template context/overview.md del kit ya trae
# Overview — agente-claude-codex
- ID: overview | Alcance: este repo | Fuente: docs/ (3 textos + PDF) y auditoría local
- Fecha de observación: 2026-09-13 | Status: aceptado | Revisar en: al cambiar la versión de Codex o de Claude Code
## Hechos verificados (2026-09-13)
- Codex CLI 0.154.0 no tiene comando `import`; el import "un clic" es de la app de escritorio.
- polyskill 0.1.0 instalado globalmente.
## Preferencias del dueño
- Auditoría primero, sin copia masiva, secretos afuera.
## Hipótesis (no verificadas)
- La clasificación heurística de 71 skills como "reutilizable" es correcta en la mayoría; necesita muestreo.Fíjate que el mismo archivo tiene tres secciones separadas: hechos (con fecha), preferencias e hipótesis. Un agente que lee esto sabe exactamente con qué peso tratar cada línea. Y el campo "Revisar en" dice cuándo el hecho puede haber envejecido: cuando Codex cambie de versión, la línea sobre el import necesita verificarse de nuevo.
ID y alcance
Un nombre estable para que otros archivos lo citen, y la respuesta a "¿vale dónde?". Un hecho de cliente nunca tiene alcance global.
Fuente y fecha de observación
De dónde vino y cuándo se vio. "Fecha de observación" no es "fecha de escritura": es cuándo se comprobó la realidad.
Estado y regla de revisión
Borrador, aceptado o revocado. Y el disparador de revisión: una fecha, o un evento ("cuando Codex se actualice").
¿Nuevo aquí? "Alcance" es hasta dónde llega una información: global (vale para ti en cualquier proyecto), de proyecto (vale solo aquí) o de cliente (vale solo para ese cliente). Confundir el alcance es como poner la contraseña de un cliente en el archivo de reglas generales: la información correcta, en el lugar equivocado, se convierte en problema.
Conceptos clave
Información que sobrevive a la sesión y necesita metadatos.
Cuándo se comprobó la realidad, no cuándo se escribió el texto.
Borrador, aceptado, revocado. Dice si se puede confiar.
El disparador que obliga a volver a comprobar el hecho.
⚖️ Provenance vence al timestamp
Cuando dos versiones de una información se contradicen, el instinto es quedarse con la más reciente. El Prompt B prohíbe exactamente eso: resuelve conflictos por procedencia y decisión aceptada, no por "cuál timestamp es más nuevo". ¿Por qué? Porque la versión más nueva puede ser una suposición de una sesión apurada, y la antigua puede ser un hecho verificado con fuente. La fecha de escritura no mide confiabilidad.
La versión de la izquierda es más antigua y gana porque tiene fuente y status aceptado. La de la derecha es más nueva y pierde: sin fuente, es hipótesis. Recibe superseded_by (sustituida por) y queda punteada, pero no se borra.
🔬 Cómo lo hace el openpcbotv3 de verdad
El bot v3 de esta máquina tiene una consolidación nocturna de memoria. Fusiona duplicados y, cuando detecta una contradicción entre dos memorias, la antigua recibe superseded_by apuntando a la nueva, y nunca se borra. El mismo mecanismo sirve para el camino inverso: si la "nueva" es la que pierde, es ella la que recibe la marca. El punto es que nada desaparece; solo cambia lo que está vigente.
- •Borrar destruye el rastro. Pierdes el "por qué creíamos eso".
- •Ocultar preserva el rastro y mantiene una sola versión activa.
- •Backup antes de cada ronda de consolidación, porque equivocarse aquí borra contexto.
¿Nuevo aquí? "Timestamp" es el sello de fecha y hora de cuando algo fue guardado. "Superseded" (sustituido) es el estado de una información que fue reemplazada por otra más confiable. Guardar la sustituida con un puntero a la ganadora es lo que permite reconstruir la historia después.
Conceptos clave
El rastro de origen. Decide quién gana un conflicto.
Gana a cualquier versión sin aceptación, nueva o vieja.
Marca la versión que perdió, sin borrar.
Reciente no significa correcto.
⬆️ Promover un hecho: de memoria bruta a overview aprobado
Claude Code guarda memoria por su cuenta: en esta máquina son 869 archivos en 227 carpetas. Ninguno pasó por aprobación. Eso no es fuente de verdad; es materia prima. El Prompt B dice "promueve hechos verificados deliberadamente desde la memoria nativa o desde las conversaciones". Promover es el acto consciente de tomar una línea de la memoria bruta, verificarla, darle fuente y fecha, y solo entonces guardarla en context/overview.md como hecho aceptado.
Memoria bruta guardada
El agente escribió "el usuario usa flux2-klein por defecto" en una sesión cualquiera. Sin fuente, sin fecha.
Propuesta
Al tocar el proyecto, el agente propone: "esto parece una preferencia estable; ¿promover al overview?"
Verificación y aprobación humana
Tú confirmas (o corriges: "es preferencia, no hecho"). Gana fuente ("regla global del CLAUDE.md"), fecha y status aceptado.
Guardado en el lugar correcto
Va a la sección correcta del overview. La memoria bruta sigue existiendo como evidencia, por separado.
🗃️ El vault del openpcbotv3: "el bot propone, tú apruebas"
El bot v3 mantiene dos archivos curados, ~/vault/MEMORY.md y USER.md. El bot propone entradas; nada se escribe sin que tú apruebes. El USER.md entra en todo prompt. Es la misma idea de promoción, ya funcionando: la memoria automática de la base de datos es materia prima; el vault es el overview aprobado. El plan de migración de esta máquina usa ese vault como overview global de hechos personales.
En la Ruta 3, Proyecto 3, conectas Claude, Codex y el dsh para que lean el mismo USER.md.
✓ Promover
- ✓Un hecho a la vez, al tocar el proyecto.
- ✓Con verificación y aprobación humana.
- ✓Gana ID, alcance, fuente, fecha, status.
- ✓Evidencia bruta preservada aparte.
✗ Copiar en masa
- ✗Volcar los 869 archivos de memoria en
context/. - ✗Arrastrar suposiciones, duplicados y hechos muertos junto con todo.
- ✗Sin fuente: el agente nuevo no sabe en qué confiar.
- ✗El ruido de Claude se convierte en ruido de Codex.
Conceptos clave
Memoria nativa y sesiones: evidencia, no fuente.
Acto deliberado de verificar y registrar con metadatos.
El agente sugiere, el humano decide. Nada automático.
MEMORY.md y USER.md: el resumen aprobado de openpcbotv3.
🔁 Índices reconstruibles a partir de las fuentes
Búsqueda semántica, embeddings, base de datos de vectores, caché de resúmenes: todo eso es índice, y un índice es derivado. El Prompt B cierra la sección de propiedad con una regla simple: "haga que los índices de búsqueda sean reconstruibles a partir de los registros fuente que usted posee". Si el índice se corrompe, si cambia de herramienta o de modelo de embedding, usted ejecuta el build de nuevo y vuelve. Si la única copia de la información está dentro del índice, la perdió.
📊 Ejemplos reales de esta máquina
- •openpcbotv3: los vectores
bge-m3se reindexan por cron cada 15 min a partir de la tabla de memorias. Borrar el índice no pierde nada. - •Catálogo INEMA:
courses.data.json,cursos.json,base.jsonson todos generados. La fuente escourses.tsyPortal.tsx. Editar el generado a mano es el error que la skill del portal prohíbe. - •Kit de migración:
relatorios/auditoria-*.mdlo generaaudit.sh. Lo ejecutó de nuevo, lo rehízo.
¿Nuevo aquí? "Embedding" es una forma de transformar texto en números para que un programa encuentre textos parecidos. "Índice" es cualquier estructura armada para encontrar cosas más rápido. Ambos son copias transformadas del original. Regla práctica: si no puede borrarlo y regenerarlo, no es índice, es fuente disfrazada.
⚠️ El error a evitar
Dejar que la memoria del agente viva solo en una base de datos vectorial propietaria. Cambió de modelo, el embedding antiguo ya no sirve. Cambió de herramienta, la base no abre. Sin la fuente en Markdown, el "cerebro" desaparece junto con el modelo. Es lo opuesto de lo que este curso enseña.
Conceptos clave
Fuente es lo que usted edita; derivado es lo que el build genera.
Borrar y regenerar sin pérdida. La prueba definitiva.
Búsqueda, vectores, caché. Siempre derivado.
Se abre en cualquier lugar, con cualquier modelo.
🔐 Secretos y material en bruto quedan fuera
Dos tipos de contenido nunca entran al núcleo portátil: secretos (claves de API, tokens, contraseñas) y estado nativo en bruto (sesiones JSONL, base de memoria de Claude, exports de chat completos). Los mega-prompts repiten esto en casi todas las secciones: "mantenga secretos y memoria privada en bruto fuera de reportes y repositorios", "preserve la evidencia en bruto por separado". El núcleo portátil es lo que usted publicaría; el resto se queda en su lugar, referenciado, nunca copiado.
✓ Entra al núcleo
- ✓La regla "las keys están en
~/projetos/openpcbotv2/.env" (la referencia). - ✓Hechos promovidos, decisiones, tareas, handoffs.
- ✓El nombre del MCP registrado (magnific, metricool).
- ✓Un snapshot curado y fechado de contexto.
✗ Queda fuera
- ✗El valor de la clave (nunca impreso, nunca copiado).
- ✗Los 2,3 GB de sesiones JSONL de Claude.
- ✗La carpeta
~/.claudeo~/.codexcopiada entera. - ✗Material de terceros sin licencia (el
docs/del kit quedó fuera del git por eso).
🧭 El caso del dsh-sandbox
La carpeta ~/projetos de esta máquina tiene 269 archivos de secretos. Por eso el dsh-sandbox amarra montaje y proveedor: el modo local monta los proyectos pero solo habla con Ollama; el modo remoto habla con OpenRouter pero no ve los proyectos. Juntar los dos exige escribir "CONFIRMO". Es la regla de este tema convirtiéndose en mecanismo: el secreto puede existir en la máquina, pero el ejecutor que habla con afuera no puede verlo.
¿Nuevo aquí? "Evidencia en bruto" es el material original sin tratamiento: la transcripción entera, el log completo, el export del chat. Es valiosa para auditar después, pero no es para leerse en cada sesión. Queda archivada, con un puntero en context/sources.md que dice dónde está y de cuándo es.
Conceptos clave
El núcleo dice dónde está la clave, nunca cuál es.
Sesiones y memoria automática se quedan donde nacieron.
Recorte aprobado, con fuente y fecha, en vez del bruto.
Si no puede ir a un repo, no está en el núcleo.
Autoverificación (opcional): dos anotaciones se contradicen. La de agosto dice "puerto 8000" con fuente; la de septiembre dice "creo que es 8080" sin fuente. ¿Cuál vale?
🎯 Resumen del módulo
Próximo módulo:
1.6 — Audit antes de implement: analizar → planificar → simular