📋 Pre-flight Checks
🔍 Problem Description
Actualmente, engram gestiona el contexto basándose en scopes como el usuario y el proyecto. Sin embargo, en el flujo de trabajo diario de desarrollo, cambiamos constantemente de ramas (branches) para implementar diferentes funcionalidades, refactorizaciones o correcciones.
Al no tener en cuenta la rama actual, el contexto generado en una funcionalidad en desarrollo puede terminar "contaminando" o mezclándose con el contexto de la rama principal (main/master) o de otras tareas concurrentes. Esto reduce la precisión del contexto cuando saltamos de una tarea a otra.
💡 Proposed Solution
Proponemos que engram sea consciente del estado de Git del repositorio para aislar y fusionar contextos bajo la siguiente lógica:
Detección y aislamiento por rama: El sistema debe detectar automáticamente en qué rama de Git se encuentra el usuario. El contexto generado se guardará e indexará asociado de forma única a esa rama (ej. feature/auth-system).
Estrategia de Fusión (Context Merge): Cuando una rama secundaria se fusiona con la rama principal, el usuario debería tener la opción de integrar ese contexto acumulado.
Comportamiento esperado: Al hacer el merge en Git, se debería poder ejecutar un comando o habilitar un flujo para elegir si fusionar el contexto de la rama origen en la rama destino (ej. main), o si simplemente descartarlo para mantener limpio el historial.
📦 Affected Area
CLI (commands, flags)
🔄 Alternatives Considered
Gestión manual por proyectos: Crear un "proyecto" diferente en engram para cada rama de Git de forma manual. Desventaja: Es un proceso tedioso, propenso a errores y rompe la fricción cero que busca la herramienta.
Uso de tags/etiquetas manuales: Etiquetar cada interacción con el nombre de la rama. Desventaja: Requiere que el usuario se acuerde de añadir el tag en cada comando, en lugar de automatizarlo mediante la lectura del .git local.
📎 Additional Context
Un flujo de trabajo de ejemplo ideal sería:
El desarrollador pasa a la rama feature/api-refactor.
engram detecta el cambio y empieza a almacenar el nuevo contexto de forma aislada en esa rama.
Tras hacer git merge feature/api-refactor hacia main, el desarrollador ejecuta un comando de consolidación (por ejemplo, engram context merge feature/api-refactor main) para que la rama principal herede los aprendizajes y el contexto de esa funcionalidad de forma definitiva.
📋 Pre-flight Checks
status:approvedbefore a PR can be opened🔍 Problem Description
Actualmente, engram gestiona el contexto basándose en scopes como el usuario y el proyecto. Sin embargo, en el flujo de trabajo diario de desarrollo, cambiamos constantemente de ramas (branches) para implementar diferentes funcionalidades, refactorizaciones o correcciones.
Al no tener en cuenta la rama actual, el contexto generado en una funcionalidad en desarrollo puede terminar "contaminando" o mezclándose con el contexto de la rama principal (main/master) o de otras tareas concurrentes. Esto reduce la precisión del contexto cuando saltamos de una tarea a otra.
💡 Proposed Solution
Proponemos que engram sea consciente del estado de Git del repositorio para aislar y fusionar contextos bajo la siguiente lógica:
Detección y aislamiento por rama: El sistema debe detectar automáticamente en qué rama de Git se encuentra el usuario. El contexto generado se guardará e indexará asociado de forma única a esa rama (ej. feature/auth-system).
Estrategia de Fusión (Context Merge): Cuando una rama secundaria se fusiona con la rama principal, el usuario debería tener la opción de integrar ese contexto acumulado.
Comportamiento esperado: Al hacer el merge en Git, se debería poder ejecutar un comando o habilitar un flujo para elegir si fusionar el contexto de la rama origen en la rama destino (ej. main), o si simplemente descartarlo para mantener limpio el historial.
📦 Affected Area
CLI (commands, flags)
🔄 Alternatives Considered
Gestión manual por proyectos: Crear un "proyecto" diferente en engram para cada rama de Git de forma manual. Desventaja: Es un proceso tedioso, propenso a errores y rompe la fricción cero que busca la herramienta.
Uso de tags/etiquetas manuales: Etiquetar cada interacción con el nombre de la rama. Desventaja: Requiere que el usuario se acuerde de añadir el tag en cada comando, en lugar de automatizarlo mediante la lectura del .git local.
📎 Additional Context
Un flujo de trabajo de ejemplo ideal sería:
El desarrollador pasa a la rama feature/api-refactor.
engram detecta el cambio y empieza a almacenar el nuevo contexto de forma aislada en esa rama.
Tras hacer git merge feature/api-refactor hacia main, el desarrollador ejecuta un comando de consolidación (por ejemplo, engram context merge feature/api-refactor main) para que la rama principal herede los aprendizajes y el contexto de esa funcionalidad de forma definitiva.