Mi vault de Obsidian en tres capas: cerebro, proyectos y guías

Tengo un vault de Obsidian con 164 ficheros markdown, de los que 114 son notas del cerebro (el resto son plantillas, archivo, índices y ficheros de configuración). Este post explica cómo lo organizo y por qué. Es un sistema que diseño y curo yo: cada nota lleva su fuente y la fecha en que la revisé, y cada dominio tiene un mapa de contenido que lleva a una guía de decisión con trade-offs.

PARA numerado y tres capas

La base es PARA (Projects, Areas, Resources, Archive) con carpetas numeradas para que el orden en el explorador sea siempre el mismo, de 00-INBOX a 08-GUIAS:

00-INBOX/          captura rápida sin procesar
01-PROYECTOS/      proyectos activos
02-AREAS/          responsabilidades continuas
03-RECURSOS/       EL CEREBRO
04-ARCHIVO/        completados / obsoletos
05-TEMPLATES/      plantillas (no editar)
06-DAILY/          notas diarias YYYY-MM-DD.md
07-META/           MOCs, índices, roadmap
08-GUIAS/          manuales de herramientas

Encima de PARA puse un modelo de tres capas, que es lo que de verdad me importa:

La regla de consulta

El fichero CLAUDE.md de la raíz fija la "Regla del Cerebro" para que los asistentes la sigan solos. Este es el núcleo, resumido (el original lleva emojis, negritas y backticks):

- CEREBRO → 03-RECURSOS/ (10 dominios conceptuales reutilizables) → DEFAULT
- PROYECTOS → 01-PROYECTOS/ → solo si el usuario nombra un proyecto
- GUÍAS → 08-GUIAS/ → solo si el usuario nombra una herramienta

La idea es separar preguntas de naturaleza distinta. "¿Cómo diseño autenticación?" es conocimiento y va al cerebro. "¿Cómo va mi multi-agente?" nombra un proyecto. "¿Qué hace Ctrl+J en Claude Code?" nombra una herramienta. Sin esa separación, una respuesta sobre un patrón general se contamina con detalles de un proyecto concreto. El coste es que dependo de que yo nombre las cosas: si la pregunta mezcla capas, tengo que decirlo explícitamente.

Otra regla del mismo fichero: cuando tomo una decisión de arquitectura, el asistente debe preguntarme si quiero registrarla como ADR.

El cerebro: 10 dominios, 102 notas

03-RECURSOS nació con diez dominios y 102 notas:

Cada dominio tiene su MOC (Map of Content) en 07-META. En total hay 13 MOCs: los de dominio, más Decisiones, Guías y el de la Fábrica de Agentes. Esta última es un undécimo dominio que añadí el 2026-08-30, al unificar otro vault en este. Tiene 12 notas más y no entra en el 102.

Sobre los enlaces: el roadmap registra 0 wikilinks rotos. Lo he vuelto a comprobar con un script de lectura: unos 1800 enlaces internos y solo 4 destinos sin resolver, que no son notas. Uno es un ejemplo de sintaxis en OBSIDIAN-CONFIG.md y tres son marcadores de la plantilla del daily. El criterio es ignorar los ejemplos dentro de bloques de código y de código en línea; según qué excluya, la cuenta baila unos pocos enlaces arriba o abajo, así que no le doy más precisión que "unos 1800". Por eso digo "0 rotos reales".

El estándar de nota

La plantilla template-guia-decision.md es el estándar al que apunta el cerebro. Estas son sus secciones:

## Cuándo tirar de esto
## Decisión en 30 segundos
## Opciones y trade-offs
## Cómo decidir
## Errores comunes
## Checklist
## En tu stack
## Fuentes (con fecha)
## Relacionado

La sección que más me importa es "Cuándo tirar de esto". Una nota que solo define un concepto se olvida; una que dice en qué situación la necesito, se usa. "En tu stack" fuerza a aterrizar el concepto en Python o en TypeScript con Next. Y la idea de las fuentes con fecha es que una cifra sin fecha envejece sin avisar.

Las 102 notas del cerebro tienen "Cuándo tirar de esto", "En tu stack", "Errores comunes" y "Fuentes", y 101 tienen "Checklist". El campo fuentes-revisadas: 2026-05-28 está en el frontmatter de las 102.

---
tags: [dominio, subtema]
created: 2026-05-28
updated: 2026-05-28
status: draft | in-progress | completed
type: concepto | proyecto | recurso | nota | moc
---

Los desvíos que he visto: una nota del cerebro tiene status: stable (que no está en la lista) y las notas de la Fábrica de Agentes usan type: convenciones, tampoco permitido.

Entrada por situación

MOC-Decisiones no es un índice de temas, es una tabla de "necesito decidir…". Cada fila lleva a una guía: arquitectura y BD, serverless frente a contenedores, REST frente a GraphQL o gRPC, estrategia de testing, autenticación, respuesta a incidentes, selección de modelo LLM, y más. Son 11 filas con enlace.

Estado de proyectos con Bases

Para el estado de los agentes que construyo uso Obsidian Bases. El fichero Proyectos.base es una tabla viva:

filters:
  and:
    - tipo == "proyecto-agente"
views:
  - type: table
    name: Proyectos
    order:
      - file.name
      - status
      - mode
      - features_done
      - features_total
      - last_sync

No escribo esos datos a mano. Las notas de 01-PROYECTOS/_estado-agentes/ las genera sync_vault.py como proyección del feature_list.json de cada proyecto, al cerrar sesión. Por eso en CLAUDE.md hay una advertencia explícita de no editarlas: se sobrescriben. Hoy hay una única nota real, aegisgraph, con 3 de 3 features completadas. No detallo aquí el script de sincronización; me limito a cómo consume el vault su resultado.

Git y lo que decide el .gitignore

El vault está versionado con Git y tiene solo 2 commits: el que unifica los 164 ficheros y uno que deja de versionar graph.json. Las líneas con más historia del .gitignore son estas (el fichero real también lleva boilerplate como .DS_Store, Thumbs.db y desktop.ini):

.obsidian/workspace.json
.obsidian/workspace-mobile.json
.obsidian/graph.json
.obsidian/cache
.trash/
 
.opencode/
 
.claude/settings.local.json
 

• El estado de interfaz (workspace.json) cambia cada vez que muevo un panel; versionarlo solo genera conflictos entre máquinas.
• graph.json guarda preferencias visuales por máquina, y Obsidian reescribe el zoom al abrir. Lo saqué del repo en el segundo commit.
• .opencode/ fuera por decisión mía del 2026-08-30: OpenCode lo uso solo en un equipo y su configuración lleva rutas absolutas.
• .claude/settings.local.json lleva rutas y permisos de cada máquina.

Mi script de búsqueda

Tengo obsidian_helper.py, unas 220 líneas de Python para que Claude Code pueda buscar en el vault. Depende de PyYAML para leer el frontmatter y busca por tag, por contenido y por backlinks, además de listar carpetas y sacar estadísticas.

Lo que me aporta

Tener las decisiones y sus trade-offs por escrito, con fuente y fecha, me ahorra empezar de cero cada vez que un proyecto me pide elegir algo. Y la separación en tres capas (cerebro, proyectos y guías) hace que una pregunta general no se contamine con los detalles de un proyecto concreto.