Codex SPU es un sistema operativo de pensamiento local-first para investigar, capturar, sintetizar y publicar conocimiento. No es solo un vault de notas ni solo un CMS de contenido: es un sistema compuesto donde el Zettelkasten envuelve un pipeline editorial ya automatizado.
La idea central es simple:
- el conocimiento vive en archivos Markdown locales
- las notas se transforman por etapas
- el output editorial nace de una base de pensamiento conectada
- el pipeline de publicacion es un subsistema, no el sistema entero
El sistema se apoya en cuatro principios:
-
Soberania de datos
La verdad vive en el archivo local. Obsidian, VS Code, GitHub y los scripts son perifericos. -
Separacion de funciones
Capturar, destilar, pensar, sintetizar y publicar son trabajos distintos. Cada tipo de nota debe hacer bien una sola cosa. -
Recursividad
Nada nace de la nada. Toda pieza de output deberia poder rastrearse hacia notas, fuentes, maps o clusters de pensamiento previos. -
Friccion selectiva
El sistema permite capturar rapido, pero exige mas estructura a medida que una idea se acerca a convertirse en obra.
La estructura actual del vault expresa un flujo funcional:
-
00-inbox
Captura rapida. Fleeting notes, preguntas, intuiciones, bullets e ideas en bruto. -
01-sources
Notas de fuente y destilacion de conocimiento externo. Libros, articulos, papers, podcasts, clases, glosarios. -
02-maps
Notas de orientacion. MOCs, mapas tematicos y mapas de proyecto. -
03-output
Incubacion creativa. Aqui viven las output notes y la sintesis previa al draft. -
04-pipeline
Subsistema editorial automatizado. Backlog, drafts, in progress, refined, ready, published y feedback. -
reference_docs
Capa transversal de referencia. Aqui viven thought corpus, research refs, working references, estrategia y documentos largos de apoyo que alimentan el resto del sistema sin entrar necesariamente en el flujo diario. -
08-calendar
Planificacion editorial y correspondencias temporales del sistema. -
zettelkasten
Capa permanente del sistema. Base viva de notas atomicas y pensamiento reusable. Esta carpeta vive fuera de la numeracion principal por una razon deliberada: no representa una fase temporal del workflow, sino la memoria permanente que alimenta todo el sistema. -
99-archive
Cierre, historico y material ya resuelto.
En otras palabras:
00-03 transforman conocimiento
reference_docs sostiene contexto y criterio
04-pipeline produce contenido
08-calendar orquesta ritmo y correspondencias
zettelkasten conserva pensamiento permanente
99-archive guarda lo cerrado
El flujo recomendado del sistema es:
inbox -> sources -> zettelkasten -> maps -> output -> pipeline -> published -> aprendizaje -> vuelta al sistema
reference_docs y 08-calendar atraviesan el flujo como capas de apoyo, no como pasos obligatorios.
Ese loop puede leerse asi:
-
Captura
Una idea entra sin friccion por00-inbox. -
Destilacion
Si viene de una fuente, pasa por01-sources. -
Pensamiento permanente
Si ya es una idea reusable y formulada en tus palabras, entra enzettelkasten. -
Orientacion
Si necesitas organizar un territorio o un proyecto, construyes un map en02-maps. -
Sintesis creativa
Si un cluster de ideas ya pide forma, nace una output note en03-output. -
Produccion editorial
Cuando ya existe tesis, estructura y direccion, la pieza entra en04-pipeline. -
Retroalimentacion
Al publicar, el aprendizaje vuelve al sistema como nuevas notas, conexiones o refinamientos.
El sistema usa una familia de notas con funciones distintas:
-
Fleeting note
Captura provisional. No esta hecha para durar. -
Literature note
Destilacion de una fuente externa. -
Zettel
Idea permanente, atomica, conectable y reusable. -
Map
Nota de estructura para orientar territorios de investigacion o proyectos. -
Output note
Nota de destilacion creativa. Convierte una red de notas en direccion de obra. -
Draft
Pieza ya orientada a una audiencia, con intencion editorial. -
Reference doc
Documento largo de apoyo, consulta o trabajo. Puede contener corpus, doctrina, listas, estrategia o contexto compuesto del que luego salen notas, maps u output notes.
La documentacion de snippets vive en:
En este sistema, el Zettelkasten no sustituye al pipeline. Tampoco es una carpeta de apoyo secundaria.
Es la capa permanente del sistema:
- guarda ideas procesadas
- conserva conexiones reutilizables
- acumula pensamiento a largo plazo
- alimenta maps, output notes, articulos, libros, cursos y cualquier obra futura
Por eso esta carpeta puede crecer mucho y vivir visualmente separada del flujo numerado. No es una excepcion. Es una decision de diseno.
reference_docs no forma parte del flujo diario de notas. Funciona como infraestructura intelectual de apoyo.
Aqui viven documentos como:
- thought corpus
- manifiestos
- whitepapers
- research refs
- working references
- content strategy
Estos archivos no intentan ser atomicos como una Zettel. Su funcion es concentrar contexto, criterio y materiales extensos para consulta y futura destilacion.
La regla practica es esta:
- si una nota quiere decir una sola cosa bien, probablemente pertenece al Zettelkasten
- si una nota quiere reunir muchas cosas utiles para volver a pensar desde ahi, probablemente pertenece a
reference_docs
03-output no es todavia el pipeline. Es el espacio donde el conocimiento comienza a convertirse en obra.
Aqui vive la transicion entre:
- investigar
- detectar patrones
- sintetizar
- encontrar insight
- imaginar una pieza posible
En este proyecto, esa transicion se trabaja con output notes basadas en el metodo PPT123.
04-pipeline sigue siendo el motor editorial del sistema. Es el lugar donde un artefacto ya entra en produccion con automatizacion.
Aqui es donde:
- el watcher detecta movimientos
- se actualizan
pathystatus - se crean o sincronizan issues en GitHub
- el contenido se mueve por el tablero editorial
El pipeline no desaparece. Se vuelve mas fuerte al estar alimentado por una base de conocimiento mejor estructurada.
08-calendar no produce conocimiento nuevo, pero coordina cadencia, identidad y distribucion.
Es la capa que ayuda a traducir output en ritmo editorial:
- calendario de publicacion
- plantillas semanales
- correspondencias de tono, energia y voz
- planificacion tactica
El sistema utiliza scripts en Node.js para mantener integridad operativa:
-
npm run watch
Iniciawatcher.js. Sincronizastatus,pathy GitHub Projects en tiempo real. -
npm run audit
Detecta desincronizaciones entre la ruta real del archivo y sus metadatos. -
npm run audit:fix
Corrige automaticamente lospathdel sistema. -
npm run audit:full
Corrige rutas y detecta notas sin campopath.
Para mantener la trazabilidad del pensamiento, LocalCodex recomienda una adaptación de Conventional Commits:
- feat:: Nueva pieza de conocimiento o contenido.
- refactor:: Evolución de una idea o síntesis de múltiples notas.
- fix:: Corrección de metadatos, rutas o enlaces de navegación.
- brain:: Volcado de pensamientos crudos o ráfagas de ideas (Brain dump).
- chore:: Mantenimiento técnico de los scripts o configuración.
Este repositorio esta evolucionando desde un sistema editorial personal hacia una version mas general y open source llamada LocalCodex. La estructura actual ya refleja esa evolucion: un wrapper de investigacion y Zettelkasten alrededor de un pipeline CMS que ya existia.
- Para mantener
Ctrl + Clicksin romper el YAML, el sistema usa comentarios de navegacion dentro de las notas. - Si una IA opera sobre este repo, deberia respetar la separacion funcional entre captura, fuentes, Zettelkasten, maps, output, pipeline y reference docs.
- Toda pieza que entra en pipeline deberia mantener trazabilidad hacia notas anteriores del sistema.
MIT (c) Simon Hernández Leal (https://simonhl.com), ver el archivo de LICENSE.