2026-09-06 · nodo.ws = garden público · second-brain = capa de trabajo privada

Contexto: tras unificar el repo (Quartz como garden en ~/nef/quartz, rama v1 congelada, build verde), se decide la separación de responsabilidades.

Decisión

Dos capas, un solo repo ([usuario]/second-brain, git PRIVATE):

1. nodo.ws (público / garden) — front + data salen SOLO de:

   • content/nodes/ → grafo derivado (backlinks, nivel efectivo, rutas, debt)
   • content/projects/ → implementaciones que otorgan niveles
   • study/ → compendio/rutas Pipeline: npm run build deriva dist/graph.json + curriculum.json, garden.mjs LIMPIA y regenera el vault de Quartz, npx quartz build emite HTML, y dist/ (lo que sirve wrangler) es solo eso. Nada del journal entra.

2. content/journal/ (privado / capa de trabajo) — journaling, idea-dev, experimentos, implementaciones en bruto:

   • npm run journal -- <texto> [--idea] [--img ruta] → content/journal/AAAA-MM-DD.md
   • nunca se deriva, nunca se sincroniza al vault, nunca se publica
   • garden.mjs borra el vault de Quartz (QUARTZ_DIR/content), NO el journal del repo

Ciclo de maduración

idea (journal [idea]) → nodo (new-node, entra al garden) → experimento (kind: experiment) → implementación (content/projects/). Promover es un paso manual deliberado; el journal es el suelo fértil, el garden es lo que otros ven.

Por qué privado y no gitignore

El journal ES el valor del second-brain; vive en git local+remoto privado. No se publica porque no viaja a dist/, no porque se oculte.

Pendiente natural (no hecho hoy)

• script promote journal→node (hoy se hace a mano con new-node).
• ¿separar content/experiments/ como sección propia, o basta kind: experiment en nodes?