Análisis de Configuración Actual de Hermes (Stefy)

Fecha: 2 de octubre de 2026 Propósito: Identificar las causas de raíz por las que Stefy mezcla proyectos y sesiones al trabajar con Jorge.

1. Diagnóstico de la Configuración Actual

1.1 Perfil único (`default`)

Solo existe un perfil Hermes — el perfil default. Esto significa que cada sesión carga:

Todos los skills (126 habilitados, 60 locales)
Toda la memoria (1.346/1.375 caracteres — al 98% de capacidad)
La misma configuración de modelo, terminal, herramientas
El mismo directorio de trabajo (cwd: .)

Consecuencia: no hay separación entre proyectos. En una misma sesión Stefy tiene acceso a las memorias, skills y convenciones de Terry, Machotes, DTF Impulsora, InnovaQR, Gastos Diarios y más. Al no saber a qué proyecto pertenece la conversación, mezcla datos, prioridades y flujos de trabajo.

1.2 Memoria al límite

La memoria de perfil (user) está al 98% de capacidad (1.346/1.375 caracteres). Contiene:

Preferencias de Jorge (nombre, email, forma de trabajo)
Notas técnicas (SQL Server, pymssql)
Prioridades cruzadas (DTF + WhatsApp + Terry + Machotes)
Información de proyecto DTF Impulsora (precios, ubicación, alcance)
Estilo de trabajo

Problema: al estar cerca del límite, cualquier añadido nuevo requiere borrar/reemplazar entradas existentes. Además, al mezclar proyectos en el mismo espacio, Stefy prioriza según lo que quepa, no según el proyecto activo.

1.3 Skills genéricos sin contexto de proyecto

Los skills (especialmente los locales) cubren tecnologías y tareas (dotnet-web-api, blazor-server-development, cloudflare-deploy, dokploy-deploy, database-connections, workspace-conventions, etc.) pero ninguno está anclado a un proyecto concreto.

Cuando Stefy carga un skill como dotnet-web-api, no sabe si es para Terry (RDS + Vanilla/JS), Machotes (Blazor Server), InnovaQR (FastAPI) o una API nueva. Lo mismo ocurre con cloudflare-deploy y dokploy-deploy.

1.4 Cron sin contexto de proyecto

El único cron job activo es un resumen semanal general (Resumen semanal general). No hay separación por proyecto, por lo que en un mismo resumen se mezclan actualizaciones de todos los frentes.

1.5 Sin plan de skills por proyecto

Hay skills redundantes o solapados:

project-context-management y project-context-organi y project-context-organiz → 3 skills con enfoque similar
blazor-email-templates y dotnet-email-templates → solapamiento
cloudflare + cloudflare-deploy + cloudflare-pages-deploy + cloudflare-deployment → 4 skills de Cloudflare
fastapi-dokploy-deploy + dokploy-deploy → 2 skills de deploy

1.6 Sin convención de sesiones

No hay forma de etiquetar una sesión con el proyecto al que pertenece. Hermes soporta nombrar sesiones con /title [name], pero no hay un standard que Stefy use para recordar el proyecto activo en cada sesión.

2. Capacidades de Hermes Relevantes (Documentación)

La documentación de Hermes Agent ofrece varias herramientas diseñadas para resolver estos problemas:

2.1 Perfiles (`hermes profile`)

Un perfil es un entorno completamente aislado: skills, config, sesiones, memoria, cron.
hermes profile create NAME crea un perfil nuevo. Se puede clonar del perfil default con --clone o --clone-all.
hermes profile use NAME establece el perfil sticky.
También se puede invocar con hermes --profile NAME para sesiones puntuales.

2.2 Skills (`hermes skills`)

Los skills pueden instalarse por perfil (cada perfil tiene su propia carpeta skills/).
Se pueden pre-cargar con --skills SKILL1,SKILL2 en la línea de comandos.
Los external_dirs permiten compartir skills entre perfiles.

2.3 Memoria por perfil

Cada perfil tiene su propio almacén de memoria (~/.hermes/profiles/<name>/memories/).
La memoria del perfil default se inyecta en cada sesión de ese perfil.
Al cambiar de perfil, la memoria del perfil default NO se inyecta.

2.4 Sesiones aisladas

Cada perfil tiene su propia base de sesiones (state.db). Las sesiones de Terry no se mezclan con las de Machotes.
session_search busca solo dentro del perfil activo.

2.5 Cron por perfil

Los cron jobs se ejecutan en su perfil correspondiente, por lo que el resumen semanal de Terry lleva skills y memoria de Terry.

2.6 Kanban (work queues)

El sistema Kanban de Hermes permite crear tableros de tareas multi-perfil, con workers que se ejecutan en su perfil asignado y reportan resultados al tablero central.

2.7 Worktree mode (`-w`)

El flag --worktree o -w permite usar git worktrees aislados para sesiones paralelas, evitando conflictos de merge.

3. Patrones de Trabajo Observados (Sesiones Recientes)

Basado en el resumen semanal y las skills locales:

Proyecto	Stack	Despliegue	Prioridad
Terry	Blazor .NET + RDS	Railway / VPS	En pausa (no genera dinero)
Machotes	Blazor .NET	Cloudflare Pages	En pausa (no genera dinero)
DTF Impulsora	Landing estática	Cloudflare Pages	Prioridad (genera dinero)
InnovaQR	FastAPI + Python	Dokploy (planeado)	Activo
Asistente WhatsApp	Node.js / Chatwoot	VPS	Alta prioridad (autónomo)
Gastos Diarios	Node.js	Local	Activo

Jorge tiene un estilo de trabajo: - Prefiere C#/Blazor/ASP.NET Core para proyectos web - API-first sin DB en fase inicial (Terry usa RDS, pero la API arranca sin DB) - Planificación spec-first (documentar antes de codificar) - Despliegues en Cloudflare Pages + Dokploy - Sin credenciales en el repo (seguridad estricta) - Comunicación informal pero espera foco estricto

4. Causas Raíz Identificadas

Causa	Efecto
1 perfil único	Skills, memoria, sesiones y cron de todos los proyectos se inyectan en cada sesión
Memoria al límite	Al no caber más, Stefy reemplaza información crucial de un proyecto con otro
Skills sin contexto	Stefy carga un skill de "API REST" y no sabe si es para Terry, Machotes o InnovaQR
Sin proyecto declarado	Al no haber un ritual de entrada (cargar proyecto → cargar contexto), Stefy trabaja en el último proyecto que recuerda
Sin plan de skills	Skills redundantes y desactualizados añaden ruido a la sesión

Siguiente paso: proposal.md — propuesta detallada de configuración y organización.