Contenido detallado
🔒 Modelos locales para datos sensibles
El Freedom OS se encarga del pasaporte, las residencias, el certificado de nacimiento: cosas que tú no quieres poner en el contexto de un modelo en la nube. La respuesta del autor es ejecutar modelos locales para los dominios más sensibles. Por eso invirtió mucho en hardware antes del alza de los precios de la memoria: análisis de datos privados que nunca salen de tu máquina.
🌱 ¿Nuevo aquí?
Un modelo local se ejecuta en tu propia computadora; los datos no se envían a un servidor de terceros. PII (información personal identificable) es cualquier dato que te identifica: CPF, pasaporte, dirección. Hardware aquí es una máquina con suficiente GPU/memoria para ejecutar el modelo localmente.
✓ Lo local tiene sentido cuando…
- ✓El dato contiene muchos datos personales identificables (documentos, salud, finanzas personales).
- ✓La filtración sería irreversible.
- ✓Aceptas invertir en hardware a cambio de privacidad.
✗ No lo pongas en la nube
- ✗Certificado de nacimiento en el contexto de un chat en la nube.
- ✗El pasaporte en un prompt que se sube a un servidor.
- ✗Confiar en que «no se filtrará» en un escenario de filtraciones constantes.
Por qué aprender
Porque la sensibilidad del dominio determina la arquitectura. Para la mayoría de los OS, la nube es excelente; para el Freedom OS, no. Saber elegir un modelo local cuando el dato es irrecuperable es lo que separa la conveniencia de la imprudencia y protege lo que no puedes volver a emitir.
Conceptos clave
⚖️ Cerrado vs. abierto vs. híbrido
La elección del modelo no es igual para todos los OS. Algunos OS usan principalmente modelos código cerrado (cerrados, en la nube); otros, local/código abierto; y algunos son híbridos — lo local se ocupa de lo sensible; el entorno cerrado hace el trabajo pesado no sensible. La regla que guía: el dominio determina la combinación.
🌱 ¿Nuevo aquí?
Closed source = modelo propietario al que accedes mediante una API en la nube (más potente, pero los datos salen de tu máquina). Open source = modelo abierto que puedes descargar y ejecutar localmente. Híbrido = usar ambos según la tarea, dirigiendo lo sensible al entorno local.
Nube, potente. Para lo que no es sensible.
Se ejecuta en tu máquina. Para PII y secretos.
Enruta: local para lo sensible, nube para el resto.
💡 La regla práctica
No preguntes "¿cuál es el mejor modelo?"; pregunta "¿cuál es la sensibilidad de este dominio?". Tax OS y Freedom OS se inclinan por lo local/híbrido; Content OS y Sales OS funcionan bien en la nube. La arquitectura sigue los datos, no la moda del modelo de la semana.
Por qué aprender
Porque te libera de la idea de "un modelo para todo". Cada OS puede tener una postura diferente, y el híbrido suele ser el punto óptimo: no renuncias a la potencia donde puedes usar la nube ni a la privacidad donde los datos son sagrados. Es una decisión de arquitectura, no de marca.
Conceptos clave
💾 Copia de seguridad en 3 frentes
Todo OS importante tiene una copia en tres frentes: un repositorio privado en GitHub, un SSD local e a nube. El detalle que te protege: un .gitignore que mantiene lo sensible fuera de GitHub — no subes tu pasaporte a un repositorio, por más privado que sea, especialmente con las filtraciones que ocurren todo el tiempo.
🌱 ¿Nuevo aquí?
Un repositorio (repo) es la carpeta versionada en Git/GitHub. Privado = solo tú accedes. SSD es un disco físico local. El .gitignore es un archivo que indica qué debe ignorar Git; lo que incluyes en él nunca sube a GitHub. Es tu barrera de seguridad para evitar subir información confidencial.
Cómo leer: tres copias = ningún fallo único te derriba. El .gitignore es la compuerta: el material confidencial (en rojo) se sube al SSD/nube privada, pero nunca entra en GitHub.
Por qué aprender
Porque tu OS se convierte en un activo crítico: perder las carpetas significa perder meses de trabajo. Tres frentes garantizan que ningún fallo aislado (un disco duro que se avería, una cuenta suspendida) lo borre todo, y el .gitignore garantiza que la redundancia no se convierta en una puerta de filtración de información confidencial.
Conceptos clave
🍂 Context rot: el punto de corte por dominio
Todo contexto se deteriora, pero a ritmos distintos. La pregunta de producción es: ¿qué se deteriora más rápido en este dominio?. La ley tributaria cambia en meses, no de la noche a la mañana; la identidad tiende a ser estática; las tendencias de contenido cambian en días. Para cada dominio defines un punto de corte: cada cuánto tiempo hay que actualizar ese contexto.
🌱 ¿Nuevo aquí?
Context rot (deterioro del contexto) es el sustrato que envejece: lo que era verdad queda desactualizado. El punto de corte es la cadencia de actualización que defines por dominio, como una fecha de vencimiento. Sin ella, el OS responde con confianza usando datos antiguos.
Cómo leer: la clave es la «validez» de cada contexto. La identidad casi no se deteriora; la tendencia se deteriora rápido. El punto de corte es cuándo programas el ↻: actualizar demasiado pronto es un desperdicio; demasiado tarde, un error cometido con confianza.
Por qué aprender
Porque es lo que mantiene el OS confiable con el paso del tiempo. Un OS que parece inteligente, pero funciona con un contexto podrido, es peligroso: se equivoca con la misma seguridad con la que acierta. Definir el punto de corte por dominio es asumir el mantenimiento como parte del diseño, no como un detalle posterior al lanzamiento.
Conceptos clave
📝 /tldr — resumen después de la sesión
El hábito que hace que el OS se mejore a sí mismo: un slash command de resumen posterior a la sesión. El /tldr guarda el resumen de lo que pasó e propone actualizaciones a CLAUDE.md y a las reglas con el tiempo. Es automejora con una persona en el circuito: la IA sugiere el diff, pero solo tú lo aplicas.
🌱 ¿Nuevo aquí?
Un slash command es un atajo que activas escribiendo /nombre en Claude Code — existe como un archivo en .claude/commands/. O frontmatter es el encabezado entre --- con metadatos. Humano en el bucle significa que la máquina propone, pero la decisión final es tuya.
🎯 Objetivo de la copy-run
Crear el slash command /tldr que, al final de una sesión, genera el resumen, destila nuggets y propone (como diff, para que lo apruebes) actualizaciones a CLAUDE.md y a las reglas.
--- description: Resume a sessão e propõe updates ao CLAUDE.md e às regras --- Você é o arquivista deste OS. A sessão acabou. Faça, nesta ordem: 1. RESUMO: escreva até 8 bullets do que decidimos / fizemos hoje, sem floreio. Salve em substrate/sessions/<AAAA-MM-DD>.md (o raw da sessão). 2. NUGGETS: extraia só o que tem valor durável (uma preferência minha, um fato do domínio, um atalho que funcionou) e acrescente ao substrate/compendium.md. 3. PROPOSTAS DE REGRA: se algo deu errado hoje, proponha 1 never-rule para rules/never.md e, se for inegociável, 1 reflexo (hook). NÃO edite rules/ sozinho — liste as mudanças como diff e PERGUNTE antes de aplicar. 4. CLAUDE.md: se surgiu um fato estável sobre mim ou o negócio, proponha a linha exata a adicionar / trocar — de novo, como diff para eu aprovar. 5. Nunca grave dado marcado como sensível: use um identificador, não o valor real. Termine com "onde paramos" + o próximo passo para a próxima sessão.
Las partes en <...> se completan en el momento (la fecha). Después de crear el archivo, ejecuta /tldr al cerrar cualquier sesión.
✅ Cómo verificar
- ✓Apareció el archivo substrate/sessions/<data>.md con el resumen en viñetas.
- ✓Los nuevos nuggets entraron en el compendium.md (y solo lo que es duradero).
- ✓Los cambios en rules/ e CLAUDE.md llegaron como diff propuesto, a la espera de tu aprobación — no se aplican por sí solas.
- ✓Ningún valor sensible aparece en texto sin formato (solo identificadores).
Por qué aprender
Porque es el motor de la filosofía "cultiva, no instales". Sin el /tldr, el aprendizaje de cada sesión se evapora. Con él, el OS mejora con cada uso —captura preferencias y corrige reglas—, pero nunca se edita a ciegas: sigues al mando de lo que entra en el archivo-alma.
Conceptos clave
⏰ Crons semanales de síntesis
El /tldr se encarga de cada sesión; el cron semanal se encarga de todo. Es una tarea programada que, cada semana, destila todas las conversaciones en hallazgos sintetizados — el mismo patrón raw → destilado que se repite en todo dominio, ahora automático. Si una tarea se ejecuta el 100% de las veces sin que tú tengas que decidir, merece convertirse en cron, no en skill.
🌱 ¿Nuevo aquí?
Un cron es una tarea que se ejecuta sola según un horario programado (ej.: todos los domingos a las 3h). Sintetizar es resumir el material bruto en unos pocos nuggets útiles. La diferencia con una skill: tú llamas a la skill cuando quieres; el cron se activa solo, sin que se lo pidas.
El ciclo de síntesis: lo raw se convierte en destilado, por sí solo
cron semanal (domingo, sem você pedir) │ ├── varre substrate/sessions/*.md # o raw da semana ├── destila com um modelo workhorse # barato + esperto └── grava substrate/compendium.md # só os nuggets
🔎 ¿Skill o cron?
La prueba es sencilla: si tú siempre ejecuta la tarea siempre de la misma manera, sin criterio, es candidata a cron (o script determinista). Si todavía depende de una decisión tuya cada vez, se queda como skill. La síntesis semanal es el caso clásico de cron: repetitiva y sin opciones.
Por qué aprender
Porque es lo que mantiene fresco el sustrato sin que tengas que hacer ningún esfuerzo. Las conversaciones se acumulan; sin síntesis, se convierten en un archivo muerto que nadie lee. El cron transforma el historial en bruto en conocimiento destilado cada semana: el OS aprende de su propio uso mientras duermes.
Conceptos clave
🌱 Cultivar en producción
Cerramos donde empezó el curso: cultiva, no instales. Un OS de producción se mantiene activo con el uso diario: observas dónde se atasca y encuentras los "muletillas" (los puntos donde la conversación se traba) y ajusta. El backup, el context rot, el /tldr y los crons no son tareas aisladas: son los hábitos que mantienen vivo el jardín después de que ya creció.
El ciclo de mantenimiento de producción
Úsala a diario
El uso real es la «prueba de fuego». Solo al usarlo aparecen las fallas; ninguna auditoría de escritorio las detecta.
Encuentra las disfluencias
¿Dónde tuviste que volver a explicar algo? ¿Dónde dudó el OS? Cada tropiezo es una pista de lo que falta en alguna capa.
Ajusta y audita
Corrige la capa adecuada (el /tldr ayuda) y ejecuta /os-coach audit para volver a puntuar el OS frente al objetivo.
✓ Quién cultiva
- ✓Vuelve, úsala y ajusta la capa adecuada.
- ✓Ejecuta /tldr y audita el OS según el objetivo.
- ✓Cultiva un OS que mejora cada mes.
✗ Quién instala y desaparece
- ✗Lo arma todo en un fin de semana y nunca vuelve.
- ✗Deja que el contexto se deteriore sin un punto de corte.
- ✗Confía en un OS que envejeció silenciosamente.
💡 El cierre del curso
Ya tienes todo: las 6 capas, el paso a paso con el /os-coach, los 6 dominios y ahora los patrones de producción. Lo que falta ya no es más teoría —es cultivo. Elige un dominio, construye, úsalo y vuelve para auditar.
Por qué aprender
Porque es lo que separa un experimento de fin de semana de un sistema en el que confías durante años. La producción no es un estado que alcanzas y olvidas: es un ciclo de uso, detección de la disfluencia, ajuste y auditoría. Quien cultiva cosecha un OS que mejora; quien instala y abandona cosecha uno que se pudre.
Conceptos clave
🎉 Llegaste al final
Fin de la Ruta 5 — y del curso:
Completaste las 5 rutas. Ahora elige un dominio, construye tu OS y ejecuta /os-coach audit para puntuarlo frente a tu objetivo.