Auto-Reparación (Motor de Reglas Auto-Corregible)
Un motor de memoria y aprendizaje auto-corregible que registra correcciones, convenciones del proyecto y correcciones de errores en un archivo de reglas persistente (autofix.json). Asegura que el agente se adapte continuamente, elimine errores repetidos entre sesiones y se adhiera estrictamente a las preferencias del usuario.
Por qué funciona: Los agentes de IA tienden a repetir las mismas suposiciones o errores de estilo en sesiones nuevas. Al externalizar el conocimiento aprendido en un conjunto de reglas JSON imperativo y versionado con precedencia estricta (las reglas más nuevas ganan), el agente mantiene límites duros adaptados al usuario y repositorio específicos.
Almacenamiento y Configuración
La habilidad busca el archivo de reglas en una de las siguientes ubicaciones (en orden de prioridad):
.agents/autofix.jsonautofix.json(en la raíz del espacio de trabajo).rules/autofix.json
Si ninguno existe cuando se necesita agregar una nueva regla, crea .agents/autofix.json (o autofix.json en la raíz, dependiendo de la convención del proyecto).
Esquema de Regla
Cada regla se almacena dentro de un arreglo JSON con el siguiente esquema:
[
{
"Rule_number": 1,
"Category": "CODE",
"Instruction": "No usar nunca exportaciones por defecto para componentes React - usar siempre exportaciones con nombre.",
"Why": "Asegura consistencia con la base de código y simplifica la refactorización."
}
]
Categorías Permitidas
| Categoría | Descripción | Ejemplos |
|---|---|---|
[STYLE] | Formateo de código, convenciones de nomenclatura, orden de importaciones, comentarios | "Usar siempre camelCase para funciones auxiliares" |
[CODE] | Patrones de lenguaje, elecciones de librerías, definiciones de tipo, manejo de errores | "No usar nunca any en TypeScript; usar unknown con guards de tipo" |
[ARCH] | Estructura de directorios, límites de módulos, capas arquitectónicas | "Las rutas de API viven en src/server/routes/, no en src/api/" |
[TOOL] | Comandos CLI, herramientas de construcción, gestores de paquetes, frameworks de pruebas | "Usar siempre pnpm en lugar de npm o yarn" |
[PROCESS] | Flujo de trabajo Git, mensajes de commit, requisitos de PR, compuertas de pruebas | "No agregar nunca emojis a los mensajes de commit" |
[DATA] | Esquemas de base de datos, migraciones, estrategias de caché, formas de estado | "Incluir siempre marcas de tiempo created_at y updated_at en las tablas" |
[UX] | Comportamientos de UI, convenciones de copia, estándares de accesibilidad | "Proporcionar siempre un aria-label explícito para botones solo con icono" |
[OTHER] | Preferencias generales del proyecto o dominio específico | "Documentar siempre los endpoints de API pública en formato de tabla markdown" |
Flujo de Trabajo Operativo
[Inicio de Sesión / Tarea Recibida]
│
▼
┌───────────────────────────────┐
│ 1. Escaneo Pre-Tarea │ ◄── Leer autofix.json
│ - Cargar todas las reglas │
│ - Resolver conflictos (nueva>antigua)
│ - Construir restricciones activas │
└───────────┬───────────────────┘
│
▼
┌───────────────────────────────┐
│ 2. Ejecución de Tarea │
│ - Aplicar restricciones │
│ - Ejecutar código/ediciones│
└───────────┬───────────────────┘
│
├─────────────────────────────────────────┐
│ │
[Sin Correcciones] [Disparador Detectado]
│ │
▼ ▼
┌───────────────────────────────┐ ┌───────────────────────────────┐
│ Tarea Completa │ │ 3. Auto-Reparación y Captura │
│ Entregar resultado al usuario │ │ - Formular regla imperativa│
└───────────────────────────────┘ │ - Anexar a autofix.json │
│ - Confirmar aprendizaje │
└─────────────┬─────────────────┘
│
▼
┌───────────────────────────────┐
│ 4. Re-ejecutar y Corregir │
│ Corregir la salida actual │
└───────────────────────────────┘
Ejecución Detallada Paso a Paso
1. Escaneo Pre-Tarea (Antes de Hacer Cualquier Cosa)
Antes de planificar o modificar archivos en cualquier tarea:
- Localizar y cargar
autofix.json. - Escaneo de las reglas:
- Verificar si alguna regla aplica directamente a los archivos, herramientas o patrones involucrados en el prompt actual.
- Resolver conflictos:
- Si dos reglas dan instrucciones contradictorias, la regla con el número más alto (más nueva) gana.
- Mantener restricciones activas:
- Tratar todas las reglas activas como restricciones estrictas (equivalente a
CONSTRAINTSdel contrato de prompt).
- Tratar todas las reglas activas como restricciones estrictas (equivalente a
2. Cuándo Agregar una Regla (Condiciones de Disparo)
Activar inmediatamente la captura de reglas cuando ocurra cualquiera de los siguientes casos:
- El usuario corrige explícitamente la salida: p. ej., "No, no uses X, hazlo con Y", "Aquí no usamos componentes de clase".
- El usuario rechaza un archivo, enfoque o patrón: p. ej., "No pongas archivos de prueba junto al código fuente".
- El usuario establece una preferencia personal/de equipo: p. ej., "Formatea siempre los mensajes de commit como Conventional Commits", "No uses nunca emojis en las docs".
- Un error fue causado por suposiciones incorrectas: El agente asumió una librería o ubicación de archivo que provocó un fallo.
- El usuario ejecuta
/learno pide recordar una regla.
3. Anexar una Nueva Regla
Cuando ocurre un disparador, realizar la siguiente actualización atómica:
- Leer el arreglo existente de
autofix.json. - Determinar el siguiente
Rule_numbersecuencial:- Si el número de regla más alto existente es $N$, la nueva regla es $N + 1$.
- Si el archivo está vacío o es nuevo, comenzar en
1.
- Dar formato al nuevo objeto de regla:
- Rule_number: Entero secuencial.
- Category: Una de las categorías estándar (
STYLE,CODE,ARCH,TOOL,PROCESS,DATA,UX,OTHER). - Instruction: Escrita en formato imperativo estricto:
"Nunca/Siempre haz X - porque Y." - Why: Razón breve (p. ej. "preferencia del usuario", "patrón de la base de código", "limitación del framework").
- Anexar la regla al arreglo JSON y guardar el archivo con sangría de 2 espacios.
- Nunca eliminar reglas existentes. Si una regla antigua es reemplazada, escribir la nueva regla para que su número más alto tenga prioridad.
- Notificar brevemente al usuario:
"Regla aprendida #
<N>([CATEGORÍA]):<Instrucción>— registrada enautofix.json."
4. Archivo de Reglas de Ejemplo (autofix.json)
[
{
"Rule_number": 1,
"Category": "PROCESS",
"Instruction": "No agregar nunca emojis a los mensajes de commit - mantener títulos de commit como Conventional Commits simples.",
"Why": "preferencia del usuario"
},
{
"Rule_number": 2,
"Category": "ARCH",
"Instruction": "Colocar siempre los manejadores de rutas de API en 'src/server/routes/', nunca en 'src/api/' - mantener una arquitectura de backend consistente.",
"Why": "patrón de la base de código existente"
},
{
"Rule_number": 3,
"Category": "CODE",
"Instruction": "Usar siempre esquemas Zod para validación de entrada en todos los puntos de entrada externos - prevenir entradas de ejecución sin tipo.",
"Why": "previene errores de ejecución y aplica tipos"
}
]
Mejores Prácticas y Casos Especiales
- Escritura JSON Atómica: Analizar siempre el arreglo JSON existente, anexar el nuevo objeto y escribir de vuelta un JSON válido. Nunca corromper el archivo con texto sin escapar.
- Concreto e Imperativo: Escribir reglas que otra IA pueda seguir sin ambigüedad. Evitar consejos vagos como "Escribir código limpio"; preferir "Exportar siempre los tipos junto con las implementaciones de componentes en archivos
.types.ts". - Sin Bucles Infinitos: Al registrar una regla, no disparar un bucle de auto-reparación separado para el archivo de reglas en sí.
- Reglas que Reemplazan: Si la Regla 1 dice "Usar Axios" y el usuario luego indica "Migrar todo a Fetch", agregar la Regla 4 "Usar siempre Fetch nativo en lugar de Axios" con
Why: "usuario solicitó migración a fetch nativo (reemplaza la Regla 1)".