


Crea un servicio de agentes de programación que recibe peticiones del chat y del gestor de incidencias
Para un servicio cuyos agentes de programación reciben trabajo del alojamiento de código, el gestor de incidencias y el chat. Separa los roles principal, revisor y analizador, usa un entorno aislado por hilo, fija el orden del middleware y deja activar la reparación automática de CI.
Para usar estas reglas de IA
## Da una sola tarea a cada rol de ejecución y deja al revisor en solo lectura
Asigna una responsabilidad clara a cada función de ejecución:
- un grafo del agente principal de programación crea un agente nuevo para cada hilo, mientras que el estado duradero permanece en el entorno aislado y los metadatos del hilo;
- un grafo de revisión realiza revisiones de código de solo lectura mediante un modelo de hallazgos y una acción específica de publicación, sin herramientas para modificar, confirmar, enviar o abrir revisiones;
- un grafo de análisis crea directrices de revisión específicas para cada repositorio en los modos de arranque y aprendizaje continuo, y las guarda mediante una sola herramienta específica;
- una aplicación web recibe webhooks del alojamiento de código, del gestor de incidencias y del chat, determina un hilo estable e inicia o transmite la ejecución del grafo correspondiente;
- un panel controla el inicio de sesión, los perfiles de usuario, los valores predeterminados del equipo, los repositorios habilitados, la administración del estilo de revisión y la API de hilos que usa la interfaz.
Proporciona los procedimientos de análisis como competencias virtuales, versionadas y de solo lectura, en lugar de copiarlos en cada entorno aislado. Registra el perfeccionamiento continuo programado solo después de que termine el arranque. Mantén todos los puntos de entrada de los grafos y las rutas de la aplicación en un único manifiesto de ejecución, permitiendo a la vez un entorno de desarrollo completo y un proceso más limitado exclusivo para la web.
## Elige un único juego de herramientas y ejecuta primero la prueba más pequeña
Declara un gestor de dependencias, un ejecutor de pruebas, un analizador estático, un formateador, un comprobador de tipos, una versión mínima del lenguaje y una versión del entorno de ejecución desplegado. El repositorio debe seguir siendo válido tanto para el mínimo admitido como para cualquier versión más reciente fijada por los metadatos de despliegue.
Proporciona comandos documentados para:
1. instalar las dependencias de desarrollo;
2. iniciar el entorno de ejecución completo de los grafos y la web;
3. iniciar solo la aplicación web;
4. ejecutar todo el directorio de pruebas unitarias;
5. ejecutar un archivo o caso de prueba;
6. comprobar el análisis y el formato sin modificar archivos;
7. aplicar el formateador y las correcciones automáticas seguras;
8. comprobar los tipos del código de producción y de pruebas.
Usa pruebas unitarias de forma predeterminada. Reserva un directorio específico para las pruebas de integración y trata la ausencia de una suite de integración como una operación nula explícita, no como un fallo ambiguo. Durante el desarrollo, ejecuta una sola prueba o la suite pertinente más pequeña antes de las comprobaciones amplias del repositorio.
## Mantén un entorno aislado por hilo y vuelve a crearlo cuando falle
Mantén una caché de entornos aislados dentro del proceso, indexada por el identificador del hilo, y conserva el identificador del entorno aislado en los metadatos del hilo. Gestiona explícitamente los estados del ciclo de vida:
1. Si un entorno aislado está en la caché, comprueba su estado; vuelve a crearlo si la comprobación falla y actualiza su proxy de red autenticado si está sano.
2. Si los metadatos contienen un valor centinela de creación, pero no hay un entorno aislado en la caché, retira el centinela obsoleto antes de crear uno de reemplazo.
3. Si no existe ningún entorno aislado, escribe el centinela de creación, crea el entorno aislado y sustituye el centinela por el identificador real.
4. Si los metadatos tienen un identificador, pero la caché del proceso está vacía, vuelve a conectarte y, si la reconexión falla, recurre a la recreación.
Para los proveedores que admitan un proxy autenticado, obtén una credencial de instalación nueva y de corta duración cada vez que se cree o actualice el entorno. Permite que el proxy inyecte la autenticación del alojamiento de código y de la API para que los comandos del entorno aislado puedan usar un valor provisional inocuo en lugar de almacenar la credencial real. Los proveedores que no tengan esta función deben omitir explícitamente la ruta del proxy.
Vuelve a aplicar la configuración de identidad de la automatización en cada ejecución. Los entornos reutilizados o reconectados pueden perder la configuración global, y las comprobaciones posteriores de despliegue pueden rechazar las confirmaciones cuya identidad de autor no sea reconocida.
## Ejecuta el middleware que rodea las llamadas al modelo en un orden fijo
Ejecuta el middleware que rodea las llamadas al modelo en una secuencia deliberada:
1. limpia y normaliza las entradas de las herramientas;
2. limita las llamadas al modelo y termina correctamente al alcanzar el límite;
3. convierte las excepciones de las herramientas en mensajes de herramienta;
4. añade las instrucciones superiores aplicables a las lecturas de archivos una sola vez por ejecución;
5. inserta los mensajes de incidencias o chat que lleguen durante la ejecución antes de la siguiente llamada al modelo;
6. actualiza los indicadores externos del estado del asistente;
7. sustituye una respuesta vacía del modelo por una llamada sintética a una herramienta de continuación o confirmación de finalización;
8. notifica al canal de origen cuando se alcance el límite general de pasos;
9. activa un disyuntor tras fallos repetidos del entorno aislado;
10. añade un modelo alternativo solo cuando se haya configurado uno distinto;
11. retira los bloques de razonamiento específicos del proveedor que estén mal formados inmediatamente antes de llamar al proveedor.
Combina la instrucción del sistema de continuar actuando con la protección ante respuestas vacías para que el trabajo no termine en silencio. Mantén más reducido el middleware de revisión cuando no necesite instrucciones de archivo delimitadas, inserción de la cola de mensajes, un modelo alternativo o recuperación del entorno aislado. La mera existencia de un componente de middleware sin usar no lo activa; registra expresamente el middleware nuevo en la posición correcta.
## Da a cada rol solo las herramientas que necesita
Mantén un registro pequeño y plano de herramientas personalizadas. El agente principal puede recibir solicitudes de red aprobadas, búsquedas, acciones del gestor de incidencias, solicitudes de revisión, reactivaciones programadas y respuestas de chat. El revisor debe recibir solo herramientas de red orientadas a la lectura, además de las acciones para crear, actualizar y enumerar hallazgos y publicar revisiones. El analizador debe recibir únicamente la acción necesaria para guardar las directrices de revisión.
Deja que el marco de agentes proporcione las funciones genéricas de archivos, shell, búsqueda, tareas y planificación. No dupliques esas herramientas en el registro personalizado.
No dependas de una protección posterior al agente para publicar el trabajo. El flujo de trabajo del agente debe realizar explícitamente cada confirmación, envío, apertura o actualización de revisión y respuesta al canal de origen que haya sido autorizada. Un revisor de solo lectura nunca debe heredar estas capacidades de modificación.
## Elige el modelo en un orden fijo y cifra las credenciales
Resuelve el modelo y la intensidad de razonamiento de cada ejecución en este orden:
1. la configuración por hilo proporcionada por el evento activador o la interfaz;
2. la anulación del perfil del usuario identificado;
3. el valor predeterminado del equipo.
Centraliza los identificadores de modelos admitidos, las reglas de intensidad, los argumentos del proveedor, la construcción y la selección de alternativas. Conserva en el perfil de usuario los indicadores de comportamiento, como el permiso para crear revisiones automáticamente, en lugar de dispersarlos por el código de los webhooks.
Cifra las credenciales de autorización de los usuarios cuando estén almacenadas y mantenlas en la caché del proceso solo durante una ejecución. Cuando no haya una credencial de usuario disponible, recurre a una credencial de instalación de la aplicación de corta duración. Usa la misma credencial de la aplicación para configurar un proxy autenticado del entorno aislado, pero nunca conserves la credencial sin procesar dentro de este.
Verifica la autenticidad de los webhooks antes de dirigir un evento. Mantén las comprobaciones de firma del alojamiento de código, la verificación del chat, la verificación del gestor de incidencias y el tratamiento del inicio de sesión del panel en los módulos que correspondan.
## Devuelve los mensajes de seguimiento al mismo hilo y entorno aislado
Deriva identificadores de hilo estables a partir de la identidad de la conversación externa para que todos los mensajes posteriores de la misma incidencia, hilo de chat, rama o revisión regresen al mismo estado del agente y al mismo entorno aislado. Asigna a las ejecuciones de revisión un espacio de nombres determinista independiente y marca el tipo de hilo en los metadatos.
Cuando lleguen mensajes durante una ejecución, colócalos en la cola del hilo e insértalos antes de la siguiente llamada al modelo. Esto conserva la continuidad sin abandonar la ejecución actual ni crear un agente competidor. Alinea las actualizaciones de estado con los límites de las llamadas al modelo para que los usuarios externos puedan distinguir el trabajo activo, la finalización y la terminación por alcanzar el límite de pasos.
## Ejecuta la reparación automática de CI solo cuando esté activada
Un flujo de reparación automática puede reaccionar a comprobaciones fallidas, conflictos de fusión o comentarios que requieran una acción en una revisión creada por el agente. Localiza el hilo de origen mediante metadatos duraderos de la revisión y, a continuación, envía al grafo del agente principal una ejecución de reparación sujeta a un umbral de confianza.
Exige una activación por capas:
- un indicador de automatización por usuario;
- la adhesión voluntaria del repositorio;
- una anulación de activación o desactivación por revisión.
Centraliza las reglas para omitir los fallos que ya estén presentes en la rama base, las confirmaciones hechas por personas, el procesamiento repetido de la misma revisión de cabecera, la agrupación mientras esté activa otra ejecución de reparación y un límite estricto de bucles. Usa un monitor periódico solo como alternativa que examine las revisiones abiertas creadas por el agente en busca de eventos omitidos.
## Añade proveedores y herramientas en sus registros y mantén el código asíncrono
Añade un proveedor de entornos aislados a su módulo de integración y regístralo en el mapa de fábricas de proveedores. Añade una herramienta personalizada al paquete de herramientas, expórtala una sola vez e inclúyela únicamente en la lista de herramientas de la función que la necesite. Añade el middleware a su propio módulo, expórtalo y colócalo deliberadamente en la pila ordenada. Añade los puntos finales del panel al enrutador montado y los grafos nuevos al manifiesto de ejecución.
Mantén asíncrona una aplicación exclusivamente asíncrona. No crees implementaciones síncronas paralelas. Omite el método síncrono cuando la interfaz lo permita; cuando un contrato abstracto exija que exista, proporciona solo un método mínimo que genere un error de operación no admitida.
Usa pruebas unitarias de forma predeterminada, emplea el área específica de pruebas de integración para las integraciones reales y limita los comentarios. Los comentarios deben explicar un motivo no evidente o una restricción de orden, no repetir la implementación.
