Crea una herramienta que revisa y corrige código con IA sin perder el código del usuario

## Lee la build y los documentos de responsables antes de cambiar código Lee el punto de entrada del repositorio, el mapa de paquetes, la definición de compilación y los documentos de responsabilidad antes de cambiar el código. Considera las copias generadas y los resúmenes de conveniencia como referencias, no como fuentes de verdad rivales. ### Orientación en el repositorio - Localiza los puntos de entrada ejecutables, los paquetes de implementación, la infraestructura compartida y el sistema de compilación. - Usa la definición de compilación para obtener la lista actual de comandos, en lugar de copiar comandos en guías que pueden quedar obsoletas. - Identifica qué documento o archivo fuente es responsable de cada comportamiento público, clave de configuración, variable de entorno e invariante operativo. - Mantén explícitos los adaptadores específicos del host. Fija las suposiciones sobre las versiones de CLI externas y usa alternativas de API estables cuando el estado del árbol de trabajo vuelva poco fiables los comandos de alto nivel. ### Controles de verificación - Aplica formato y análisis estático antes de la entrega, incluidas las comprobaciones de divergencia en artefactos generados. - Ejecuta pruebas específicas durante la iteración y después las suites autoritativas de pruebas unitarias, de integración, de condiciones de carrera y de extremo a extremo que exija el límite modificado. - Prefiere pruebas de extremo a extremo para procesos, E/S, configuración, Git, demonios y comportamiento de fixtures grabadas; usa pruebas unitarias para funciones auxiliares puras, por velocidad y localización. - Compila el ejecutable real después de cambios no triviales. - Usa desarrollo guiado por pruebas para corregir errores y crear funciones, y deja el trabajo sin resolver en el gestor de incidencias en vez de ocultarlo en cambios no relacionados. ## Detén todos los procesos hijos al cancelar y pasa el directorio de Git de forma explícita La automatización de larga duración debe controlar su cancelación, procesos descendientes, estado compartido y efectos sobre el sistema de archivos en todos los sistemas operativos compatibles. ### Disciplina de procesos - Propaga los contextos de cancelación por las tareas prolongadas, los subprocesos y las operaciones de red. - Deriva tiempos de espera acotados para limpieza, sondeos y llamadas HTTP. - Coloca los subprocesos cancelables dentro de un límite de árbol de procesos para que la cancelación termine los descendientes, no solo el hijo directo. - Recolecta los grupos de procesos tanto al salir correctamente como ante errores o cancelaciones; las tuberías heredadas y los procesos nietos filtrados no deben sobrevivir a una ejecución. - Aplica el endurecimiento de procesos hijo específico de cada plataforma mediante un único contenedor idempotente, para que el trabajo en segundo plano nunca abra consolas no deseadas. - Protege el estado mutable compartido con primitivas estándar de sincronización y haz explícita la responsabilidad sobre goroutines, canales, árboles de trabajo y directorios temporales. ### Disciplina del sistema de archivos y Git - Usa funciones de rutas propias de la plataforma, raíces de estado controladas por la aplicación y modos de archivo documentados. - Resuelve los enlaces simbólicos cuando los alias de la plataforma puedan hacer que rutas equivalentes se comparen como distintas. - Encauza las operaciones Git de repositorios desnudos por una función auxiliar que indique explícitamente el directorio Git; nunca dependas del descubrimiento basado en el directorio actual bajo configuraciones de Git reforzadas. - Elimina o reemplaza estado solo cuando los registros de responsabilidad y ciclo de vida demuestren que es seguro. ## Decide qué comandos se ejecutan solo con la configuración de la rama de confianza La configuración que selecciona comandos o agentes ejecutables es código. Cárgala solo desde una revisión de confianza y trata la configuración y las instrucciones controladas por colaboradores como datos no fiables. ### Entradas de confianza - Resuelve la rama predeterminada de confianza mediante una obtención reciente y fija el commit exacto antes de leer configuraciones que ejecuten código. - Interrumpe el proceso cuando no se puedan obtener, leer o analizar el commit de confianza o su configuración actual. Un árbol de confianza legible sin configuración puede ser válido si el contrato lo permite. - Lee los selectores de comandos y agentes, la política de documentación, las exclusiones voluntarias de instrucciones del proyecto y el permiso para ejecutar comandos del repositorio únicamente desde la copia de confianza. - Mantén deshabilitado de forma predeterminada el permiso para ejecutar comandos del repositorio. Una rama enviada nunca debe poder habilitar sus propios privilegios de ejecución ni debilitar la política de confianza. - Mantén aparte los ajustes de funciones que no ejecutan código, para que el comportamiento específico de una rama no cruce el límite de ejecución. ### Gestión con fallo seguro - Sanea el texto de control adversarial y oculta los secretos antes de incluir contenido del usuario o del repositorio en las instrucciones para agentes. - Verifica que cualquier opción de supresión de instrucciones sea efectiva para el adaptador seleccionado antes de iniciarlo. - Nunca inventes confianza después de un fallo de obtención, análisis o autorización. - Añade pruebas de regresión que demuestren que el contenido enviado no puede autorizarse a sí mismo para ejecutar comandos, reemplazar la política de confianza ni eludir el comportamiento de fallo seguro. ## Ejecuta un solo servicio en segundo plano y rechaza paradas con trabajos activos Los servicios que abarcan toda la máquina necesitan defensas independientes para la responsabilidad de instancia única, la seguridad de sockets, la recuperación y los comandos destructivos del ciclo de vida. ### Instancia única y recuperación - Adquiere un bloqueo exclusivo del sistema operativo antes de la recuperación o la vinculación de sockets y mantenlo durante toda la vida del proceso. - Considera un bloqueo del núcleo retenido como prueba de que existe un responsable activo; no inventes heurísticas para determinar que está obsoleto. - Sondea un socket existente antes de eliminarlo y limita por separado los tiempos de espera de conexión y comprobación de estado. - Inicia la ejecución del servicio solo mediante un modo explícito. Las variables de entorno heredadas no deben reinterpretar sondeos ordinarios como trabajadores. - Haz que la limpieza de inicio tenga en cuenta el estado: nunca elimines un árbol de trabajo ni un recurso cuyo registro de tarea esté pendiente o en ejecución. ### Controles del ciclo de vida - Rechaza detener, reiniciar o actualizar mientras haya tareas activas, salvo que el operador proporcione la anulación destructiva explícita. - No permitas que las opciones de confirmación no interactiva eludan la protección de tareas activas. - Enumera las tareas que bloquean y audita cada invocación del ciclo de vida con la atribución del proceso y su proceso padre. - Trata los límites de supervisión de CI como tiempos de inactividad: reinícialos solo ante progreso ascendente verificado, nunca acortes el plazo existente y falla de forma segura cuando no se pueda comprobar el progreso. - Haz idempotentes las operaciones de cancelación de huérfanos y mantén las marcas temporales de espera del agente como datos observacionales: establécelas solo mientras una compuerta esté realmente detenida y nunca las uses para cambiar la resolución de la compuerta. ## Separa las sesiones de revisión y corrección y compara los cambios con el objetivo La revisión debe comparar el cambio completo con una intención verificable en las fuentes, sin permitir que texto no fiable, el momento de la entrega o la justificación del agente corrector distorsionen la decisión. ### Intención y hallazgos - Conserva la procedencia de la intención. Trata una intención explícita como criterio de aceptación autoritativo y una intención inferida solo como indicio de baja confianza. - Aplica a ambas las mismas medidas de saneamiento, ocultación de secretos y protección contra ejecución. - Convierte cualquier cambio del agente corrector que contradiga criterios explícitos en un hallazgo que requiera consultar al usuario y detenga la ejecución. - Durante la revisión previa a la entrega, excluye solo los resultados que pertenezcan a etapas posteriores del flujo; sigue aplicando los requisitos de ciclo de vida externos o preexistentes. - Falla de forma segura cuando falte una acción para un hallazgo o sea desconocida: clasifícala como consulta al usuario, nunca como corregible automáticamente. ### Disciplina de sesiones y correcciones - Mantén una sesión duradera de revisor por ejecución y otra sesión duradera separada para el agente corrector; los roles nunca deben compartir estado. - Reutiliza las sesiones únicamente para el ciclo de revisión, conserva los metadatos mínimos de identidad y nunca guardes instrucciones ni transcripciones. - Si la reanudación no es compatible o falla, descarta esa identidad y repite desde cero el turno del mismo rol. No vuelvas a intentarlo después de una cancelación. - Cada nueva revisión debe seguir siendo una revisión adversarial completa de toda la diferencia de la rama. - En una ronda de corrección, aplica primero todas las correcciones y ejecuta una única verificación específica limitada al área modificada. Deja las pruebas y los controles de análisis estático autoritativos de toda la suite para sus etapas dedicadas. ## Regenera los documentos desde su fuente y no envíes prompts ni código en las métricas Conserva un único responsable para cada hecho, regenera las guías derivadas desde su fuente y separa las pruebas de diagnóstico locales de los análisis remotos acotados. ### Documentación y contenido generado - Mantén concisos los documentos generales; coloca los datos de referencia detallados en su fuente responsable designada y enlázalos desde las guías. - Actualiza los mapas de responsabilidad cuando esta cambie. - Edita la fuente de las instrucciones generadas para agentes, regenera el artefacto mediante la compilación aprobada y deja que el análisis estático falle si hay divergencias. - Cambia conjuntamente las instrucciones fuente y la salida de comandos en el punto de uso cuando ambas expresen el mismo contrato operativo. - Si una sola ejecución de agente combina tareas de documentación y análisis estático, consume cada resultado exactamente una vez y recurre a una ejecución independiente cuando la salida se omita, no sea válida o no sea fiable. - Limita las modificaciones de documentación al material que el cambio actual haya dejado obsoleto; no vuelvas a introducir revisiones exhaustivas del corpus. ### Observabilidad respetuosa con la privacidad - Las superficies de solo lectura no deben emitir vistas de página; limita su evento remoto de comando a un cambio de estado y un intervalo acotado. - Conserva con fidelidad total los eventos de mutación, pero almacena las pruebas detalladas de rendimiento únicamente en local. - Nunca almacenes instrucciones, salidas, diferencias, secretos ni argumentos de comandos sin procesar en métricas de invocación, y nunca envíes a análisis remotos identificadores de ejecución, rutas, identidades de sesión ni registros por invocación. - Envía únicamente recuentos agregados y acotados en los eventos terminales. - Asigna a las definiciones de métricas y los límites de medición del tiempo una única implementación autoritativa. Representa los valores no disponibles como null, no como ceros inventados, y calcula el uso por ronda a partir de las diferencias entre acumulados de sesión cuando sea necesario. ## Revisa el remoto antes de forzar un push y firma cada build de release El invariante principal es conservar el código del usuario. Rechaza una sincronización o entrega insegura en lugar de intentar una recuperación ingeniosa que pueda sobrescribir trabajo no observado. ### Seguridad del repositorio y las ramas - Mantén separado el enrutamiento de la base de la solicitud de cambios de un destino opcional de envío a una bifurcación. Cuando un host no pueda admitir de extremo a extremo el enrutamiento por bifurcación, omite la creación en vez de abrir una solicitud incorrecta contra el mismo repositorio. - Limita la sincronización ordinaria a un avance rápido estricto y limpio o a un desplazamiento de divergencia equivalente demostrado y anclado al commit exacto del flujo. - El estado pasivo no debe obtener ni modificar nada. Las rutas bloqueadas no deben restablecer, guardar temporalmente, fusionar, reorganizar, forzar, cambiar, eliminar ni actualizar un remoto externo. - Conserva el commit exacto enviado, la identidad del destino sin credenciales y la generación; después, vuelve a comprobar todas las suposiciones mutables inmediatamente antes de aplicar una sincronización. - Conserva el trabajo terminal no publicado bajo una referencia de recuperación. La recuperación solo puede mover un árbol de trabajo limpio mediante avance rápido estricto; para conservar el trabajo local debe actualizarse la compuerta mediante comparación e intercambio sin activar un nuevo flujo. - Deriva las bases de reorganización a partir de referencias remotas autoritativas recién obtenidas. Detén el proceso cuando commits no enviados de la rama predeterminada amplíen silenciosamente un cambio. - Antes de hacer un envío forzado, vuelve a leer la cabecera remota y procede solo ante una rama nueva, una cabecera igual, una cabecera observada anteriormente que no haya cambiado o commits añadidos remotamente cuya equivalencia ya se haya demostrado por la identidad del parche. Cualquier fallo de consulta o demostración debe fallar de forma segura. - Mantén como ancla de arrendamiento la última cabecera realmente observada por la ejecución, nunca una punta obtenida justo antes de forzar el envío. ### Seguridad de versiones y dependencias - En una plataforma con un contrato de firma permanente, firma todos los artefactos oficiales con la identidad fija de la aplicación, el entorno de ejecución reforzado y una marca de tiempo segura antes de archivarlos o calcular sus sumas de comprobación. - Limita las credenciales de firma a la tarea de publicación, impórtalas en almacenamiento efímero y elimínalas tanto si el proceso termina correctamente como si falla. - Haz que la verificación de la versión falle ante una firma ausente o ambigua, una identidad o arquitectura incorrecta, un requisito de identidad mutable, endurecimiento ausente o falta de marca de tiempo. - Trata la notarización, los formatos de empaquetado y los binarios universales como ámbitos separados, salvo que el contrato de publicación los incluya. - Antes de añadir una dependencia, consulta su documentación autoritativa actual y comenta el cambio con el usuario. - No declares que está listo hasta que el formato, el análisis estático, las pruebas específicas, las pruebas de integración, la suite completa, la compilación, las comprobaciones de documentación y la verificación específica de publicación tengan resultados reales.