Archivos como base de datos
Acá está la movida que separa un sistema de un chat piola: todo vive como archivos. No en una ventana de conversación, no en tu cabeza — como JSON y markdown en tu disco que Claude lee al inicio de cada sesión.
El chat que se olvida
Cuando usás IA en un chat, el conocimiento muere con la ventana. Detectás un gran hook el martes, cerrás la pestaña, y para el viernes ya no está. La semana que viene arrancás de cero — mismas preguntas, mismo contexto, misma hoja en blanco. La herramienta nunca se vuelve más inteligente porque nunca se acuerda.
Un archivo no se olvida. Cuando tu competitor tracker escribe cada post en data/refs/<creator>/<shortcode>.json, esa inteligencia sigue ahí el mes que viene. Cuando tu dashboard escribe cada uno de tus reels en data/mine/<id>.json, tu historia se acumula. Cada sesión, Claude lee lo que ya está en disco — así el sistema sabe más cada semana en vez de resetearse a la nada.
Esa es toda la razón por la que esto compone. No porque la IA sea inteligente. Porque la data se queda.
Dos carpetas, un schema
El setup es simple a propósito:
data/mine/— tus propios reels, las analíticas reales traídas vía la API de Meta (reach, saves, shares, watch time — owner-only).data/refs/— posts de competencia y referencia, organizados por creador.
La parte que importa: ambas comparten un schema. Mismos campos, misma forma — vistas, saves, shares, watch time, outlier_multiplier. Tu data y la de ellos hablan el mismo idioma.
¿Por qué importa tanto? Porque le permite al vault rankear hooks cruzando ambos a la vez. Podés hacer una sola pregunta — "¿qué hooks son outliers en mi nicho, y cuáles de esos ya logré en mi propio contenido?" — y el sistema la responde de una pasada, porque todo es comparable. Dos schemas distintos significarían reconciliarlos a mano cada semana. Un schema significa que el sistema hace el cross-reference por vos.
Este es el modelo atoms / refs de mi content-OS real: cada pieza de contenido — mía o de otro — se guarda como un registro chico y uniforme. Los registros uniformes son lo que hace triviales el query, el ranking y la comparación.
Pensá data/mine y data/refs como dos tablas de la misma base de datos, con columnas idénticas. El vault es una query que corre cruzando ambas. Eso solo es posible porque el schema es compartido — diseñalo así desde el arranque.
Por qué los archivos le ganan a una base de datos "de verdad"
Te podés preguntar por qué no usar Postgres desde el día uno. Para el content OS de un solo creador, los archivos ganan: son diffeables, versionables con git, legibles a ojo, y Claude los puede grepear directo sin ningún setup. Sacás el 90% del valor de una base de datos sin nada de ceremonia. (Cuando escalás el scraping a miles de posts, agregás una cola y un store de verdad — lo vemos en la lección de automatización — pero el modelo archivos-primero es por donde arrancás y donde está el apalancamiento.)
¿Por qué data/mine y data/refs comparten un solo schema?
Lo que te llevás
Guardá todo como archivos, no en un chat. Un chat se olvida; los archivos persisten y componen — el sistema sabe más cada semana. Mantené data/mine (tus analíticas) y data/refs (competencia) en un mismo schema compartido para que el vault pueda rankear hooks cruzando ambos a la vez. Los registros uniformes son lo que hace todo consultable.