cookbook-brain

Dale a tus agentes una memoria que te pertenece.

cookbook-brain almacena lo que tus agentes de IA aprenden como archivos markdown simples en un repositorio git en tu disco. Claude Code, Codex o cualquier cliente MCP puede recordar, recuperar y construir sobre ello: un cerebro, todos tus agentes. Tu Claude y tu Codex finalmente saben las mismas cosas, e incluso pueden pasarse trabajo entre sí. Cada nota indica quién la escribió, humano o qué agente. Nada se sobrescribe nunca. Y las notas ganan confianza de la única manera que significa algo: siendo correctas cuando un trabajo real dependía de ellas.

Abre la carpeta en Obsidian y verás notas simples, porque eso es todo lo que es.

Quickstart

npx cookbook-brain init             # creates ./brain with a schema note
npx cookbook-brain harvest          # propose notes distilled from your recent Claude Code sessions
npx cookbook-brain harvest --apply  # write the proposals the refuter kept
claude mcp add brain -- npx cookbook-brain serve

Tu cerebro comienza lleno: antes de que tu primera sesión de agente se conecte, harvest lee tus transcripciones locales recientes de Claude Code y destila las decisiones, problemas y convenciones que ya están en ellas en notas atribuidas (ver "Harvest" más abajo; solo propone, hasta que digas --apply).

Luego dile a tu agente: "recuerda que la base de datos de staging se reinicia cada noche" y se guarda, se atribuye y se recuerda en cada sesión futura. Ese es el ciclo completo.

Otros comandos:

npx cookbook-brain log           # recent notes, newest first
npx cookbook-brain credit <id>   # credit notes whose facts held up in real work
npx cookbook-brain tasks         # open and claimed tasks, with age
npx cookbook-brain doctor        # validate every note, link, chain, and task
npx cookbook-brain index         # generate INDEX.md, a wikilinked view of the brain
npx cookbook-brain web           # read-only local viewer at http://127.0.0.1:4321
npx cookbook-brain install-hook  # every session harvests itself when it closes (report-only)

El directorio del cerebro se resuelve como la bandera --dir, luego la variable de entorno BRAIN_DIR, luego ./brain. La atribución humana proviene de BRAIN_HUMAN, con respaldo a tu nombre de usuario del sistema operativo. Requiere Node 20 o superior.

Related MCP server: clawmem-mcp-server

Why files

La memoria de tus agentes no debería vivir en la base de datos vectorial de otro. Los archivos significan que puedes leer cada memoria, ver las diferencias de cada cambio, hacer grep a las 2 a.m., hacer copias de seguridad con git, e irte en cualquier momento conservando tu carpeta. Los proveedores cambian políticas; markdown no.

Y no, no hay una base de datos vectorial subyacente, por tres razones concretas. Los embeddings necesitan una clave API y llamadas de red, y esta herramienta no hace ninguna: nada sale de tu disco. Un índice vectorial es opaco: no puedes hacerle grep, ver diferencias, ni ver por qué devolvió lo que devolvió. Y a la escala de un cerebro personal (cientos de notas, no millones de documentos), la búsqueda de texto plano más el grafo de enlaces recupera igual de bien. Los vectores ganan su complejidad a escala de corpus. Esto no es un corpus; es un cerebro.

The format

Una nota por archivo. El frontmatter contiene los datos sobre el hecho:

---
id: 01J8ZQ4X2E5N9GVHBK3W7T1MCD
type: decision
title: Poll interval is 30s, not 10
aliases: ["Poll interval is 30s, not 10"]
author:
  human: diego
  agent: claude-code
created: 2026-08-18T17:20:00.000Z
supersedes: null
source: "https://status.example.com/limits"
credits: 3
last_credited: 2026-08-20T09:30:00.000Z
---
Free-tier endpoints rate-limit hard. At 10s we tripped limits on 3 of 8
targets. 30s stays under every limit tested. Related:
[[Unknown check state renders as degraded]]

Las notas están tipadas (decision, gotcha, convention, note, open_thread, task) y atribuidas a un humano más, cuando un agente la escribió, la etiqueta del agente. El campo opcional source cita de dónde proviene un hecho (una URL, una ruta de archivo, un id de ticket); la memoria citada es memoria auditable, y obtiene un límite de confianza más alto. Cada nota también lleva una lista aliases que contiene su propio título; los nombres de archivo tienen fecha y slug, y ese alias es lo que permite a Obsidian resolver los wikilinks [[Title]] al archivo correcto (ver "Usarlo con Obsidian" más abajo). Los wikilinks son el grafo. La recuperación devuelve una nota CON sus enlaces inversos y las líneas alrededor de cada mención, para que los agentes obtengan contexto conectado, no hechos aislados. La recuperación también lleva cada nota convention activa textualmente, independientemente de la consulta: las reglas permanentes viajan para que los agentes las apliquen a todo el trabajo, no solo al trabajo que las buscó. Los nombres de archivo son <date>--<slug-of-title>.md, por lo que el directorio se lee como un diario.

Never overwrite

Actualizar una nota crea una nueva nota que reemplaza a la anterior. El archivo antiguo permanece, marcado como reemplazado. Dos razones, ambas aprendidas por las malas: cada reescritura de IA pierde silenciosamente un poco de significado, y no puedes depurar una memoria sin su historial. El registro git de tu cerebro es su pista de auditoría.

Los cuerpos de las notas son de solo añadidura para siempre; exactamente dos contadores pueden ser estampados en un archivo existente: credits y last_credited, escritos cuando un trabajo que dependía de una nota se completa verificablemente. Ese par de créditos es la segunda mutación sancionada, junto con el sello superseded_by. Las notas de tarea llevan un tercer conjunto de sellos, solo en notas de tipo tarea: status, claimed_by, result y abandon_reason. Nada más de un archivo existente se toca nunca.

Confidence: trust is earned, not asserted

Cada recuperación lleva una puntuación de confianza y un nivel (proven / standing / verify). La fórmula es pública y aburrida a propósito:

score = clamp(cap - 0.10 + 0.05 * min(credits, 3) - staleness, 0.20, cap)

• La procedencia limita el techo. Una nota escrita por humano tiene un límite de 0.95. Una nota de agente que cita una fuente (el campo source del frontmatter, una línea source: o una URL en el cuerpo): 0.85. Una afirmación de agente sin cita: 0.60. Ninguna cantidad de repetición eleva una nota por encima de su límite.

• Los créditos la elevan. Una nota nueva sin crédito se sitúa 0.10 por debajo de su límite. Cuando un trabajo que recuperó una nota tiene éxito verificable, credit la nota (una llamada CLI, o deja que tu agente lo haga al completar); cada crédito añade 0.05, y tres recuperan el límite.

• El silencio la baja. La obsolescencia resta 0.05 por cada 90 días completos desde last_credited (o desde created, si nunca se acreditó), hasta 0.15. Una nota que nadie ha acreditado en meses decae hacia "verificar antes de confiar".

Las puntuaciones se redondean a dos decimales. Niveles: proven significa acreditado al menos una vez Y con puntuación 0.80 o superior, por lo que solo las notas en las que se basó un trabajo real completado pueden ser probadas. standing (0.60 o superior) se puede usar con confianza. Todo lo demás es verify: verifícalo antes de construir sobre ello.

Esta es la parte que ningún otro sistema de memoria incluye: memoria que responde no solo "¿qué dijimos?" sino "¿esto ha sido realmente correcto cuando importaba?"

Tasks: your agents can hand each other work

Una tarea es solo otra nota (tipo: task) con un estado y un asignado:

"assign my codex a task: read docs/brief.md and draft the FAQ"

Tu Claude escribe la nota de tarea. La próxima vez que tu sesión de Codex se inicie y recupere el cerebro, la tarea abierta dirigida a él estará allí en la sección open_tasks de la respuesta. La reclama, hace el trabajo y la completa, y la finalización es donde se cierra el ciclo: el agente que completa registra en qué notas se basó (helped_note_ids), y esas notas reciben crédito. Así es como la memoria gana su confianza sin que tú ejecutes nunca un comando de contabilidad.

Y cuando una tarea reclamada resulta estar más allá de las capacidades de un agente (falta de acceso, fallos repetidos), abandona la tarea en lugar de quedarse con ella: la tarea vuelve a abierta con la razón registrada en abandon_reason, visible para el asignador y el siguiente reclamante. La visibilidad del fracaso es una característica; una tarea que se pudre en silencio es peor que una tarea devuelta en voz alta. La razón se borra cuando alguien reclama la tarea a continuación.

Mecánica honesta: no hay un proceso en segundo plano. La asignación significa que la nota espera en la carpeta hasta que la próxima sesión de ese agente la recoja. Tus agentes se coordinan a través del cerebro como un equipo se coordina a través de una pizarra: nada se mueve hasta que alguien pasa y lo lee. Para el reclamo siempre activo, las transferencias en vivo entre personas y los recibos con atribución de costos reales, ese es el trabajo del producto alojado.

Dreaming

Los cerebros que solo acumulan eventualmente se sedimentan. npx cookbook-brain dream es el pase de consolidación nocturna: fusiona duplicados, promueve gotchas acreditados dos veces hacia convenciones, marca contradicciones como hilos abiertos y renombra notas que chocan, con cada propuesta revisada por un refutador adversarial antes de aplicar nada. Se ejecuta en tu propio Claude CLI bajo tu propio inicio de sesión: cookbook-brain nunca tiene una clave API y no realiza llamadas de red propias.

npx cookbook-brain dream               # report-only: propose and review, apply nothing
npx cookbook-brain dream --apply       # execute the proposals the refuter kept
npx cookbook-brain dream --apply --commit  # then git commit the brain directory (only paths under it)
npx cookbook-brain dream --json        # machine-readable report on stdout (report file still written)
npx cookbook-brain dream --dry-digest  # print exactly what would be sent to the model, then exit
npx cookbook-brain dream --model <id>  # pick the model; default is your claude setting

Cómo funciona un sueño, en orden:

1. Escaneo de higiene, sin modelo. Un pase determinista recopila títulos activos duplicados, notas reemplazadas aún referenciadas por wikilinks activos, y notas no probadas obsoletas (nivel verify, mayores de 90 días). Estos hallazgos alimentan el siguiente paso.

2. Proponente. Una llamada claude -p ve un resumen compacto de tus notas activas (id, tipo, título, créditos, antigüedad, primeros 280 caracteres de cada cuerpo) y puede proponer operaciones de un conjunto cerrado solamente: merge, promote, flag_contradiction, retitle_for_collision. Ejecuta --dry-digest primero si quieres leer exactamente lo que sale para el modelo; la llamada del refutador además envía el texto completo de cualquier nota que toque una propuesta.

3. Refutador. Una segunda llamada claude -p con contexto nuevo y sin memoria de haber propuesto revisa cada propuesta contra el texto completo de sus notas fuente, y debe responder keep o reject con una razón. Una propuesta cuyo veredicto no se puede analizar se rechaza por defecto, nunca se mantiene en silencio. Si la llamada del refutador falla o devuelve basura, todo el sueño se marca como refuter: absent y no se aplica nada, incluso con --apply. El informe siempre distingue "sin objeciones" de "el revisor nunca apareció". El prompt del refutador tiene un límite de 24,000 caracteres: cuando las propuestas más sus notas fuente lo desbordarían, las propuestas más grandes se eliminan de la revisión, se registran como "no revisadas: demasiado grandes", y nunca se aplican, porque las propuestas no revisadas nunca se aplican.

4. Aplicar, solo si lo pediste. El valor predeterminado es solo informe. Con --apply, las propuestas aceptadas se ejecutan de forma reversible: una fusión escribe una nueva nota cuyo campo consolidates enumera los ids fuente y sella cada fuente como superseded_by; una promoción hace lo mismo en una convención; una contradicción archiva una nota open_thread ordinaria (se omite cuando un open_thread activo ya referencia ambas notas, por lo que el mismo conflicto nunca se marca dos veces); un renombramiento es un reemplazo simple. Mientras escribe, la aplicación mantiene un archivo brain/.lock: las herramientas de escritura MCP esperan, las lecturas nunca bloquean, y un bloqueo de más de diez minutos está obsoleto (una aplicación fallida) y se anula con una advertencia. Deshacer un sueño es git revert en su commit, porque un sueño solo añade archivos y sella superseded_by. Añade --commit y una aplicación exitosa hace commit del directorio del cerebro por ti, tocando solo las rutas dentro de él.

Cada sueño escribe un informe en brain/dreams/DREAM_<date>.md (un subdirectorio que el escáner de notas nunca lee): las estadísticas del resumen, los hallazgos de higiene, cada propuesta con su fundamento, cada veredicto del refutador con su razón, la línea obligatoria refuter: ran o refuter: absent, lo que se aplicó y cómo deshacerlo.

Una propiedad que vale la pena notar: las notas que escribe un sueño son autoría { human: you, agent: "dream" }, y se aplica el límite de procedencia de agente sin cita. El cerebro desconfía de sus propios sueños hasta que el trabajo los prueba. Una nota fusionada por un sueño comienza con baja confianza como cualquier otra afirmación de agente sin cita, y solo gana su camino hacia arriba siendo correcta cuando un trabajo real depende de ella.

Nightly, if you want it

Los sueños están diseñados para ejecutarse mientras duermes. Una línea simple de crontab lo hace:

15 3 * * * cd /path/to/your/project && npx cookbook-brain dream >> brain/dreams/cron.log 2>&1

Omite --apply y lee los informes mientras tomas café, o añádelo una vez que confíes en el gusto de tu refutador. De cualquier manera, haz commit del cerebro después para que cada sueño sea un commit reversible; --apply --commit hace ese commit por ti.

Harvest: your brain starts full

Un cerebro nuevo no debería comenzar vacío mientras semanas de tus decisiones reales están en transcripciones de sesiones locales. npx cookbook-brain harvest lee tus sesiones recientes de Claude Code, las destila en notas atómicas, y pasa cada propuesta por el mismo refutador adversarial que revisa los sueños. Así es como un cerebro se inicia el primer día y cómo se repone después de una semana intensa.

npx cookbook-brain harvest                  # report-only: propose notes from the last 7 days
npx cookbook-brain harvest --days 30        # scan further back
npx cookbook-brain harvest --project myapp  # only sessions whose working directory basename matches
npx cookbook-brain harvest --apply          # write the notes the refuter kept
npx cookbook-brain harvest --session <id> --since-last  # one session, only messages newer than its watermark
npx cookbook-brain harvest --dry-digest     # print exactly what would be sent to the model, then exit
npx cookbook-brain harvest --json           # machine-readable report on stdout (report file still written)
npx cookbook-brain harvest --sessions <path> --model <id>   # override the transcripts root and the model

Respuestas directas a las preguntas que deberías estar haciendo:

• Lo que lee. Transcripciones locales de Claude Code en ~/.claude/projects (se puede sobrescribir con --sessions), de los últimos N días, y sí: lee el CONTENIDO de los mensajes, los mensajes del humano y las conclusiones principales del asistente, porque destilar contenido es todo el trabajo. La ventana se aplica por MARCA DE TIEMPO del mensaje, por lo que un archivo de sesión que hayas mantenido activo durante meses solo contribuye con sus mensajes dentro de la ventana, nunca con todo su historial. El tráfico de herramientas, las transcripciones de subagentes y las ejecuciones propias de claude -p de la herramienta (llamadas de harvest y dream, detectadas por su marcador de prompt) se omiten. Esto es lo opuesto deliberado a las herramientas solo de metadatos; se indica aquí para que nunca lo descubras por sorpresa.

• Dónde lo envía. Los resúmenes compactos por sesión van a tu propio claude CLI con sesión iniciada, la misma herramienta que produjo las sesiones en primer lugar. Sin claves API, sin otras llamadas de red, nada sale de tu máquina por ninguna ruta que tu inicio de sesión de claude no utilice ya. --dry-digest imprime el prompt de salida exacto.

• Qué escribe. Nada, por defecto. Un informe en brain/dreams/HARVEST_<date>.md enumera cada propuesta, cada omisión por deduplicación (hechos que el cerebro ya posee) y cada veredicto del refutador, incluyendo la línea obligatoria refuter: ran o refuter: absent; una cosecha no revisada no aplica nada, incluso con --apply. Solo --apply escribe notas, y una cosecha aplicada solo añade archivos nuevos, por lo que deshacerlo es git revert o eliminar los archivos listados.

• La propiedad de desconfianza. Las notas cosechadas tienen como autor { human: you, agent: "harvest" }, y cada cuerpo termina con una línea source: que cita su sesión con el rango real de fechas de mensajes del fragmento digerido (por ejemplo source: session 2026-08-15, project cookbook-app, o source: session 2026-08-12 to 2026-08-18, project phonestack para una sesión de larga duración). Esa cita otorga el límite de confianza del agente con fuente (0.85) a través de la detección de fuente ordinaria, sin casos especiales: el cerebro confía más en su propio arranque que en una afirmación sin respaldo, pero menos que en ti, hasta que el trabajo real acredite las notas al alza.

Dos banderas hacen que la cosecha sea quirúrgica en lugar de masiva. --session <id> cosecha exactamente una transcripción (la ventana de días aún se aplica, por defecto a 2 días generosos en este modo). --since-last hace que la cosecha sea incremental: lee marcas de agua por sesión de brain/dreams/harvested.json (un mapa de id de sesión a la marca de tiempo del último mensaje que una cosecha digirió) y solo digiere mensajes más nuevos que cada marca de agua, por lo que un archivo de sesión que mantengas activo durante meses nunca redigiere contenido antiguo. Cada cosecha exitosa, incluso solo de informe, avanza las marcas de agua; una llamada de modelo fallida o no analizable no avanza nada, por lo que el contenido nunca se pierde en silencio. El archivo reside en dreams/, el escáner de notas nunca lo lee, y eliminarlo solo significa que la próxima cosecha comienza desde la ventana de días simple.

Autocosecha: sesiones que se destilan a sí mismas

Un comando hace que cada sesión de Claude Code se coseche a sí misma al cerrarse:

npx cookbook-brain install-hook

Eso registra un hook de SessionEnd en ~/.claude/settings.json, de forma quirúrgica: el archivo se analiza, exactamente una entrada se fusiona, cada otra clave y hook se conserva, y el comando se niega a escribir si el archivo no se analiza. A partir de entonces, cada vez que una sesión termina, el hook lee la carga útil de SessionEnd, genera una ejecución en segundo plano DETACHED de

cookbook-brain harvest --session <that session> --since-last --json

contra el directorio de trabajo de la sesión, y sale inmediatamente, por lo que cerrar una sesión nunca se retrasa. La marca de agua --since-last significa que una sesión de larga duración solo se digiere de forma incremental: cada cierre destila solo lo que sucedió desde la última cosecha.

Las respuestas directas, de nuevo:

• Siempre solo informe. El hook no puede aplicar, por diseño y codificado: las escrituras no supervisadas en tu memoria necesitan tus ojos primero. Las propuestas mantenidas se acumulan en los informes, y cookbook-brain log termina con una línea como 2 harvest report(s) with unapplied keeps: review with cookbook-brain harvest --apply cada vez que los informes recientes contienen notas mantenidas pero no aplicadas. Revísalas con un café y aplica cuando estés de acuerdo; la deduplicación evita que los hechos ya conocidos lleguen dos veces.

• Dónde vive la salida. Cada ejecución añade su informe JSON a ~/.cookbook-brain-autoharvest.log, y el informe markdown aterriza en brain/dreams/HARVEST_<date>.md como cualquier cosecha (el visor web también los muestra). El directorio del cerebro se resuelve desde el propio directorio de trabajo de la sesión (./brain, o BRAIN_DIR), por lo que una sesión en un proyecto sin cerebro solo registra un fallo educado y no cambia nada.

• La nota honesta sobre el costo. Un cierre de sesión desencadena hasta dos llamadas de modelo (proponente y refutador) en tu propio inicio de sesión de claude CLI. Se ejecutan en segundo plano, por lo que cerrar es instantáneo, pero son llamadas reales en tu cuenta. Las mitigaciones son estructurales: una sesión sin nada nuevo más allá de su marca de agua sale antes de cualquier llamada de modelo, y las ejecuciones propias de claude -p de la herramienta (llamadas de harvest y dream) se detectan por su marcador de prompt y se omiten directamente, por lo que la autocosecha nunca se recursiona sobre sí misma.

• Deshacer es un comando. npx cookbook-brain uninstall-hook elimina solo la entrada de cookbook-brain y deja todas las demás configuraciones y hooks intactos. Las sesiones ya en ejecución lo notan en su próximo reinicio, en ambas direcciones.

Lo que no es

• No es una base de datos vectorial (ver "Por qué archivos" arriba; las incrustaciones opcionales pueden llegar más tarde, y nunca serán obligatorias).

• No está alojado. Un cerebro, un propietario, cualquier número de TUS agentes.

• No es un registro de chat. Almacena notas atómicas y deliberadas, no transcripciones; incluso harvest, que lee tus sesiones, las destila en notas de un solo hecho y nunca almacena una transcripción.

¿Puede mi equipo compartir un cerebro?

Puedes compartir el repositorio como compartes cualquier repositorio, y para dos personas cuidadosas eso funciona a medias. Lo que se rompe es lo que hace que la memoria compartida sea confiable: no hay sincronización en vivo (recuerdas notas obsoletas hasta que alguien hace pull), las escrituras concurrentes significan conflictos de fusión, y nada impone la atribución: cualquiera puede editar cualquier archivo, incluidos sus créditos. Un registro que cualquiera puede reescribir silenciosamente no es un registro.

La atribución forzada, la sincronización en vivo, las reclamaciones de tareas atómicas y los recibos que acreditan la memoria en todo un equipo necesitan un servidor al que las personas no puedan eludir. Ese es el producto que vendemos: cookbook.team es el cerebro multijugador. Este repositorio es el de un solo jugador, y es honestamente excelente en ese trabajo.

cookbook-brain y Obsidian

Tu carpeta de cerebro se abre en Obsidian como una bóveda normal: los wikilinks se iluminan, la vista de gráfico dibuja el conocimiento de tus agentes, los backlinks funcionan. Obsidian es el mejor lector jamás construido para este formato, y definitivamente deberías apuntarlo a tu cerebro.

Entonces, ¿qué añade esto que una bóveda de Obsidian más uno de los servidores MCP de bóveda existentes no haga? Esos servidores abren una puerta: el agente puede leer, editar y eliminar tus notas. Esta herramienta añade la disciplina para lo que camina a través de ella. Los servidores de bóveda permiten que un agente sobrescriba tu nota; aquí, cada cambio es una nueva nota atribuida que reemplaza a la anterior. Las notas de la bóveda son todas igualmente confiables para siempre; aquí, las notas llevan procedencia y ganan confianza a partir de los resultados. Y una bóveda no tiene idea de qué agente tuyo escribió qué o cómo se transfieren el trabajo; aquí, ese es el punto central.

Obsidian es donde lees tu cerebro. cookbook-brain es lo que evita que tus agentes lo estropeen.

Usarlo con Obsidian

Ábrelo como una bóveda

Abre el directorio del cerebro (o cualquier carpeta que lo contenga) con "Abrir carpeta como bóveda" de Obsidian. No se necesitan plugins para lo básico: los wikilinks se resuelven, la vista de gráfico dibuja lo que tus agentes saben, y los backlinks funcionan.

Por qué los enlaces se resuelven: alias

Los nombres de archivo tienen fecha y slug (2026-08-18--poll-interval-is-30s.md) pero los cuerpos de las notas enlazan por título ([[Poll interval is 30s]]). El puente es el campo aliases del frontmatter: cada nota lleva su propio título como alias, y Obsidian resuelve los wikilinks a través de los alias. Las notas escritas por cookbook-brain 0.5 y anteriores carecen del campo; cookbook-brain doctor advierte sobre ellas, y

npx cookbook-brain doctor --fix-aliases

estampa aliases: [<title>] en cada nota activa que le falte. Esa estampa es una adición sancionada al frontmatter, documentada en SCHEMA.md junto con las estampas de supersede y crédito, y nunca toca un cuerpo.

Vista de propiedades

Obsidian lee el frontmatter como propiedades: abre cualquier nota y ves type, author, created, credits, last_credited, y en las tareas status, assigned_to, claimed_by, result. Eso convierte la búsqueda de Obsidian y el panel de propiedades en una superficie de consulta gratuita sobre los metadatos del cerebro.

El cerebro dentro de tu bóveda

¿Ya tienes una bóveda? Pon el cerebro en una subcarpeta de ella y apunta las herramientas allí:

npx cookbook-brain init --dir ~/Vault/brain
claude mcp add brain -- npx cookbook-brain serve --dir ~/Vault/brain

La memoria de tus agentes vive entonces junto a tus propias notas, tus notas de la bóveda pueden enlazar a las notas del cerebro como cualquier otra, y BRAIN_DIR funciona de la misma manera si prefieres una variable de entorno. El escáner solo lee archivos .md de nivel superior en esa carpeta, por lo que el resto de tu bóveda nunca se toca.

Edición manual

Tus archivos, edita libremente; la disciplina de solo añadir vincula las herramientas de los agentes, no tus manos. Corrige un error tipográfico, reformula un cuerpo, elimina una nota que nunca quisiste: es tu cerebro. La regla de nunca sobrescribir existe para que ninguna IA reescriba silenciosamente la historia, no para mantenerte fuera. Después de una edición manual masiva, cookbook-brain doctor te dirá si algo rompió un enlace, una cadena de supersede o una tarea.

Fragmentos de Dataview

Estos requieren el plugin comunitario Dataview. Ajusta FROM "brain" si tu carpeta de cerebro tiene otro nombre.

Todas las decisiones acreditadas (el proxy más cercano solo de frontmatter para el nivel probado; el cálculo exacto del nivel necesita la fórmula de confianza, que web muestra):

```dataview
TABLE credits, last_credited, author.agent AS agent
FROM "brain"
WHERE type = "decision" AND credits >= 1 AND !superseded_by
SORT credits DESC
```

Errores nunca acreditados (trampas registradas pero nunca confirmadas por trabajo real):

```dataview
TABLE created, author.agent AS agent
FROM "brain"
WHERE type = "gotcha" AND credits = 0 AND !superseded_by
SORT created ASC
```

Tareas abiertas por asignado:

```dataview
TABLE assigned_to, abandon_reason, created
FROM "brain"
WHERE type = "task" AND status = "open" AND !superseded_by
SORT assigned_to ASC
```

La página de inicio y la vista de niveles

npx cookbook-brain index genera INDEX.md en la raíz del cerebro: cada nota activa como un wikilink, agrupada por tipo con las convenciones primero, cada una con su nivel y créditos. Hace una buena página de inicio de bóveda; es una vista, no una nota, por lo que regenerarla la sobrescribe y el escáner la ignora. Y para lo único que Obsidian no muestra, el cálculo de confianza y nivel en vivo, ejecuta npx cookbook-brain web: un visor de solo lectura en http://127.0.0.1:4321 con barras de confianza, insignias de nivel, el tablero de tareas y los informes de dream y harvest.

Cuando tu equipo esté listo

Tu cerebro y cookbook.team hablan el mismo idioma: los mismos tipos de nota, los mismos niveles, la misma disciplina de fuente, los mismos verbos de tarea. Por lo tanto, la migración es una instrucción a un agente conectado a ambos: lee cada nota activa en mi cerebro y recuérdala en mi espacio de trabajo de equipo, mismo tipo, título, cuerpo y fuente. La atribución se transfiere. Tus convenciones comienzan a viajar en la memoria de cada compañero de equipo en el momento en que aterrizan.

Los créditos no migran, deliberadamente: la confianza del equipo se gana a partir de los resultados del equipo, y las afirmaciones importadas comienzan con la confianza del agente citado hasta que el trabajo del equipo las demuestre. El principio de desconfianza hasta que se demuestre se aplica a la migración misma.

Conserva el cerebro después de actualizar. Muchas personas querrán ambos: el cerebro para el contexto personal, el espacio de trabajo para el contexto del equipo. Son altitudes, no rivales.

Agradecimientos y el mapa honesto

Mem0, Zep y Letta son excelentes capas de memoria alojadas/infraestructura con capacidades que esta herramienta no tiene (escala gestionada, gráficos temporales, funciones empresariales). QM envía memoria por persona con alcance para equipos. cookbook-brain difiere en tres ejes: tu memoria son archivos que posees en lugar de filas en un servicio, cada nota está atribuida y es de solo añadidura, y la confianza se gana a partir de los resultados en lugar de afirmarse en el momento de la escritura. Si quieres una API de memoria gestionada, úsalos. Si quieres un cerebro que puedas leer, usa esto.

Por qué construimos esto

En cookbook.team construimos la versión multijugador: un espacio de trabajo compartido donde los humanos y agentes de un equipo trabajan en un mismo tablero, comparten un mismo cerebro, y cada tarea archiva un recibo que acredita la memoria que usó. cookbook-brain es esa capa de memoria, para un solo usuario, gratuita, tuya. Si tu equipo alguna vez quiere la versión compartida, sabes dónde está la cocina.

MIT, derechos de autor Diego Prozzi.