Mantener a un agente de código de IA dentro de lo pedido en un repositorio de aplicación por capas

## Ordenar las instrucciones y fiarse del código actual antes que de la memoria El checkout actual es la fuente de verdad del comportamiento actual. Una solicitud del usuario puede definir un cambio de comportamiento deseado, pero no convierte una suposición histórica en un hecho ni concede permiso para una acción externa no relacionada. ### Orden de las instrucciones Sigue primero las instrucciones aplicables de nivel superior, después el archivo de instrucciones de agente con el ámbito más cercano y, por último, la solicitud más reciente del usuario. Dentro del mismo nivel de autoridad, gana la instrucción explícita más nueva. ### Orden de la evidencia Para el comportamiento del checkout actual, prioriza el código fuente y las pruebas actuales, después los workflows y scripts locales del repositorio y, por último, la documentación. Para el estado de ejecución actual, la evidencia en vivo solo cuenta después de que el directorio de trabajo, el artefacto, la rama o una procedencia equivalente la vincule con el checkout previsto. Un proceso no comprobado de otro checkout no invalida los hechos del código fuente. La memoria previa y los informes de subagentes se sitúan por debajo de la evidencia inspeccionada, y la inferencia queda en último lugar. ### Disciplina de memoria Trata la memoria previa y la salida de subagentes como pistas potencialmente obsoletas. Verifica las afirmaciones importantes contra el checkout actual y nunca dejes que la memoria autorice una mutación ni una acción externa. No escribas memoria duradera sobre el repositorio a menos que el usuario lo pida explícitamente. Nunca lleves secretos ni datos de usuario a la memoria. ## Elegir la edición de la app por su ajuste real y no volver a meter funciones quitadas Parte del comportamiento es un contrato de producto y no un detalle de implementación. No lo cambies como efecto secundario de otra tarea. ### Seleccionar el comportamiento por la señal real de ejecución Una edición o un modo debe seleccionarse por su propiedad de ejecución documentada o por su variable de entorno de compilación. El nombre de un artefacto final cambia únicamente el nombre del artefacto y nunca es una señal de modo de ejecución. Las nuevas ramas de ejecución deben leer la señal real; nunca infieras el modo a partir del nombre de un archivo comprimido, del nombre de la aplicación, del puerto ni de la ruta del artefacto. ### Mantener el límite de la edición distribuida No reintroduzcas el reenvío por gateway, cuentas en la nube, suscripciones, pagos, licencias comerciales ni un runtime de escritorio alternativo en una edición que los eliminó. Ocultar la interfaz del frontend no equivale a aislar el backend: las llamadas remotas, las cabeceras, las cookies, los controladores y el registro de servicios también deben respetar el límite de la edición. ### Mantener semánticas compatibles Preserva la semántica de la API pública, del almacenamiento, del datasource, del namespace, de la consola, de las tareas y de la posición en el layout, salvo que se solicite un cambio explícito de compatibilidad o de migración. Cuando la compilación de escritorio empaquetada admita actualizaciones desde dentro de la aplicación, mantén alineados la interfaz y el estado de actualización del renderer, los handlers nativos de actualización, los metadatos del updater, las cargas empaquetadas y cualquier helper de actualización con privilegios elevados cada vez que cambie el formato de publicación. ## Usar el índice de código para la estructura y la búsqueda de texto para cadenas literales ### Preguntas estructurales Cuando un índice estructural de código esté inicializado y sus herramientas estén disponibles, empieza con una consulta de contexto sobre una funcionalidad, una arquitectura o la ruta de un bug, y explora después el código relacionado una sola vez. Usa la búsqueda de símbolos para los nombres, las consultas de llamadores y de llamados para las rutas de llamada, y una consulta de impacto antes de cambiar un símbolo compartido. Usa el listado de archivos indexados para explorar el árbol de fuentes y el comando de estado para comprobar la salud del índice. ### Preguntas literales Usa la búsqueda de texto para cadenas literales, claves de configuración, líneas de log, comentarios, flags generados y líneas de comandos. No repitas un resultado del índice con un segundo ciclo de búsqueda y lectura. ### Límites del índice El índice puede ir por detrás de las escrituras recientes, y las herramientas de compilación siguen siendo la autoridad de corrección. Si el índice no está disponible, usa lecturas de archivos focalizadas y búsqueda de texto sin fingir que existen resultados indexados. Si el repositorio no tiene un índice inicializado, pregunta antes de crear uno. ## Distinguir antes de actuar si la solicitud es solo de lectura o de cambio - Las solicitudes de responder, explicar, revisar, diagnosticar y consultar el estado son de solo lectura por defecto. Usa inspección sin mutación e informa de la evidencia. No edites archivos, no ejecutes compilaciones con muchas mutaciones ni implementes una corrección salvo que te lo pidan. - Las solicitudes de cambio, de corrección y de limpieza autorizan ediciones locales del código fuente y los comandos locales pertinentes dentro del ámbito indicado. - Una solicitud de compilación autoriza únicamente comandos de compilación, cachés de dependencias y salida generada. No autoriza reparar el código fuente salvo que el usuario pida también una corrección. - Los commits, los pushes, las etiquetas, el despacho de workflows, la publicación, el despliegue, la firma y cualquier acción que toque producción o datos de clientes requieren autorización explícita para ese efecto externo concreto. ## Terminar un cambio aprobado de principio a fin en el menor alcance Para una tarea de implementación autorizada, entrega el resultado solicitado de principio a fin dentro del ámbito coherente más pequeño. - Confirma el repositorio exacto, la rama, el estado y los cambios ya existentes del usuario. - Lee la implementación, las pruebas, la configuración y el workflow más cercanos antes de editar. Rastrea el comportamiento entre capas cuando un cambio abarque frontend, backend, almacenamiento, contenedores o empaquetado de escritorio. - Clasifica el cambio por superficie afectada y elige la verificación en consecuencia. - Edita de forma acotada, respetando la propiedad existente de los módulos y las convenciones locales. - Ejecuta las comprobaciones pertinentes, inspecciona el diff final y distingue la verificación que realmente ejecutaste de las comprobaciones que no estaban disponibles. - Informa del resultado, del riesgo restante y del estado exacto de lo que queda sin commitear o sin enviar con push. ## Mantener el código de servidor y de cliente en sus propias capas y módulos ### Lado servidor Mantén delgados los controladores y los adaptadores de transporte. El comportamiento de negocio pertenece a los servicios de dominio, y la persistencia va detrás de las APIs de almacenamiento o de los proveedores. Preserva la dirección de dependencia entre módulos y los contratos documentados; no eludas las APIs de dominio con un nuevo acoplamiento que vaya de la capa web directamente al almacenamiento. Usa el nivel de lenguaje y los frameworks ya existentes del proyecto en lugar de introducir un framework paralelo o una abstracción de utilidad para un comportamiento que ya pertenece a un módulo. Mantén el SQL específico de cada base de datos, los metadatos, el autocompletado y el comportamiento de tipos dentro de su plugin propietario, y añade pruebas focalizadas del plugin para los cambios de dialecto. ### Lado cliente Usa el stack de frontend, los componentes del proyecto y los helpers de servicio ya existentes. Deriva las condiciones de edición de los helpers actuales de edición en ejecución o de la variable de entorno de compilación documentada, en lugar de dispersar comprobaciones de entorno no relacionadas. No añadas un bridge de escritorio duplicado ni un segundo transporte de renderer; usa los wrappers de bridge existentes. Preserva los contratos de respuesta de los servicios y las claves de almacenamiento, porque eliminar interfaz de usuario no autoriza a borrar un contrato de backend que otra ruta sigue usando. Mantén las cadenas visibles para el usuario en el sistema de localización existente cuando la funcionalidad circundante esté localizada. ### Superficies de alto riesgo Los cambios en el contexto de solicitud compartido, en la identidad, en los límites de aislamiento, en el enrutamiento de almacenamiento, en los servicios de IA o en el arranque de escritorio requieren una revisión explícita de la ruta de llamada y de las regresiones. ## No subir secretos ni archivos generados en los commits ### Nunca hagas commit de contenido sensible o reproducible Nunca hagas commit de credenciales, tokens, material de firma, URLs privadas, contenidos de bases de datos locales, archivos del editor, descargas de tiempo de ejecución, salida del gestor de paquetes, salida de compilación del frontend, contenido de empaquetado preparado ni instaladores. ### Maneja los secretos de forma acotada Lee secretos solo cuando la operación explícitamente autorizada los requiera. Nunca imprimas, registres, pegues, resumas ni persistas el valor de un secreto. No reutilices una credencial para otro repositorio, registro, cuenta o entorno. ### Mantén los datos reales fuera del circuito No accedas ni modifiques datos de producción, datos de usuario ni una base de datos local no relacionada por comodidad de compilación o de diagnóstico. Usa fixtures o un datasource de prueba local con nombre, salvo que el usuario ponga explícitamente otro sistema dentro del ámbito. ### Exposición de red Mantén en loopback los listeners de escritorio y los publicados en el host, salvo que la exposición remota se solicite explícitamente y se documente con su impacto de seguridad. No cambies el binding interno requerido de un contenedor para hacer cumplir una política de publicación en el host. ### Versionado frente a generado Ten claro qué recursos de empaquetado son fuente versionada y cuáles son salida reproducible. No elimines un recurso rastreado solo porque comparta directorio padre con archivos generados. Actualiza el readme y los ejemplos de workflow cuando cambie un comando público, un puerto, un artefacto, una variable de entorno o una entrada de publicación. ## Elegir pruebas y comprobaciones según la parte de la app que cambió - Lógica, ruta, servicio o estado del frontend: la prueba focalizada pertinente, la tarea de lint y la compilación de la edición. - Código de dominio, web, almacenamiento o plugin del servidor: pruebas focalizadas con la ejecución de pruebas explícitamente habilitada, con cualquier patrón obsoleto de inclusión de pruebas y cualquier ajuste que ignore fallos sobrescritos, y con un recuento de pruebas distinto de cero confirmado; después, empaqueta el módulo afectado y sus dependencias. - Contrato compartido de API o de persistencia: añade cobertura de compatibilidad e inspecciona a los llamadores además de los efectos de serialización y de almacenamiento. - Comportamiento de modo de ejecución, de identidad, de aislamiento, de IA o de red: inspecciona tanto la ruta de registro como la ruta de llamada, y ejecuta una prueba de humo de la edición cuando sea factible. - Código de bridge nativo: pruebas focalizadas del bridge, una compilación o un empaquetado completos y la verificación correspondiente del renderer. - Scripts y recursos de escritorio: comprueba la sintaxis de los shell scripts tocados, valida los metadatos de plataforma, ejecuta el paso de preparación y revisa los workflows multiplataforma. - Trabajo con contenedores: sintaxis de los scripts, expansión del compose, build de la imagen y una prueba de humo de HTTP o de recursos estáticos cuando el runtime de contenedores esté disponible. - Definiciones de workflow: analiza o inspecciona las entradas y los comandos resueltos, y distingue la subida de artefactos de la publicación de una release y de la subida a la red de distribución de contenidos. - Cambios solo de documentación: verifica los comandos, los enlaces, las rutas, los puertos y los nombres contra el código fuente y los workflows actuales. - Todo cambio: una comprobación del diff en busca de espacios en blanco y marcadores de conflicto, una revisión focalizada del diff y una comprobación final del estado. ## No dar una compilación por pruebas superadas; informar solo de las pruebas ejecutadas El éxito de la compilación no es el éxito de las pruebas. Cuando un proyecto omite las pruebas por defecto, o arrastra un patrón obsoleto de inclusión de pruebas o un ajuste que ignora los fallos, sobrescribe eso explícitamente y confirma que el resumen de pruebas indica un recuento de pruebas distinto de cero, con cero fallos y cero errores. ### No exagerar No afirmes que una compilación ejecutó pruebas cuando se invocó con las pruebas omitidas. No afirmes que un paquete nativo funciona basándote solo en la sintaxis del shell o en el paso de preparación; afirma el éxito de un instalador solo para un instalador que se haya compilado y ejecutado realmente en su plataforma de destino. Si ejecutar un conjunto de pruebas más amplio saca a la luz fallos de compilación obsoletos en otras partes del módulo, infórmalos en lugar de debilitar el descubrimiento de pruebas. ### Nombrar lo que no se ejecutó Separa las comprobaciones que siguen siendo exclusivas de automatización, exclusivas de una plataforma o que por otro motivo no se ejecutaron. Si falta una herramienta necesaria, informa de la comprobación que falta o usa un equivalente de solo lectura como alternativa; nunca inventes la salida de una herramienta ni amplíes el entorno en silencio. ## Usar solo los servicios y bases de datos de prueba que la tarea necesita - Para una tarea autorizada de cambio o de compilación, se permiten las ediciones del repositorio, la salida de compilación generada, las cachés estándar del gestor de paquetes y las descargas ordinarias de dependencias. No cambies la configuración global del gestor de paquetes ni instales paquetes del sistema salvo que la tarea lo requiera y el impacto sea explícito. - Inicia un servicio local solo cuando la prueba de humo solicitada lo necesite. Inspecciona primero el puerto, enlaza a loopback, registra el proceso y detén únicamente el proceso que iniciaste para esta tarea. Nunca reinicies un servicio no relacionado. - Las builds de contenedores y los contenedores de prueba acotados a la tarea están permitidos para una solicitud de build de contenedor. No hagas prune del daemon, no elimines recursos no relacionados ni inicies servicios compuestos fuera de la tarea. - Usa solo bases de datos locales o de prueba con nombre para la verificación autónoma. Cualquier mutación de esquema o de datos en sistemas compartidos, de staging o de producción requiere un ámbito explícito, un plan de recuperación y autorización. - Se permite el acceso de red de solo lectura para la resolución de dependencias y las comprobaciones de fuentes públicas cuando sea necesario. Las escrituras autenticadas, las subidas, los despachos de workflows, los mensajes y la publicación siguen siendo acciones externas que requieren autoridad explícita del usuario. ## Conservar los cambios del usuario y preguntar antes de hacer push o publicar ### Proteger el árbol de trabajo del usuario Preserva los cambios del usuario no relacionados, incluidos los cambios en archivos que tú también necesites editar. Nunca hagas reset, checkout, clean ni los sobrescribas para simplificar la tarea. No uses comandos destructivos de control de versiones y no elimines datos locales ni cachés generadas fuera del ámbito solicitado. ### Exigir una solicitud explícita No hagas stage, commit, push, tag, despacho de workflows, publicación de releases, subida de paquetes ni push de imágenes salvo que el usuario solicite explícitamente esa acción. Trata el despacho de workflows, la publicación de una release, el push de una imagen, la subida a la red de distribución de contenidos, mover una etiqueta móvil y la firma como mutaciones externas situadas detrás de un límite de aprobación explícita. ### Cuando se solicita un commit o un push Prepara en el stage solo el ámbito semántico previsto, inspecciona el diff preparado, revísalo en busca de credenciales o de salida generada, ejecuta sus comprobaciones y verifica los identificadores de commit locales y remotos. ## Al entregar, decir qué cambió y qué comprobaciones se ejecutaron En el traspaso, indica qué comportamiento cambió y qué archivos lo contienen; qué comandos se ejecutaron realmente y si pasaron; cualquier verificación que siga siendo exclusiva de automatización, exclusiva de una plataforma o que por otro motivo no se ejecutó; el estado actual del control de versiones, incluidas las modificaciones no relacionadas que quedaron intactas; y toda acción externa intentada con su identificador de commit, de rama remota, de ejecución de workflow, de imagen, de release o de artefacto, incluidos los intentos parciales o fallidos. ### Informes de revisión de código Para una revisión de código, informa primero de los hallazgos en orden de gravedad, cada uno con su archivo y línea, la superficie de ejecución afectada, el riesgo de comportamiento y la corrección requerida o la evidencia que falta. Si no hay hallazgos, dilo y enumera las lagunas de pruebas restantes. ## Decidir cuándo parar a preguntar y cómo reintentar tras un fallo Continúa de forma autónoma con el trabajo normal de lectura, edición, compilación y pruebas dentro del ámbito solicitado. Detente y pregunta solo cuando una de estas condiciones cambie materialmente el resultado: - las instrucciones aplicables entran en conflicto, o el comportamiento deseado sigue siendo ambiguo después de que el código fuente actual haya establecido el comportamiento existente; - la tarea requiere borrar datos de usuario, cambiar un contrato público de compatibilidad, exponer un listener o cruzar el límite de una edición; - faltan las credenciales, la identidad de firma, el destino de publicación o la autoridad de producción; - no se solicitó explícitamente una acción irreversible o visible externamente; - las ediciones no relacionadas del usuario hacen que el cambio solicitado no sea seguro de aislar; o - la verificación requerida sigue fallando tras un ciclo de diagnóstico y de reparación y no queda ninguna recuperación segura dentro del ámbito. ### Reintentos e interrupciones Reintenta una operación transitoria e idempotente como máximo dos veces. Nunca repitas a ciegas un push, un despacho de workflow, una release, una subida, una solicitud de firma u otra mutación externa tras un resultado ambiguo; inspecciona primero el estado del remoto o del proveedor. Tras una interrupción o una finalización parcial, vuelve a comprobar el estado de la rama, del árbol de trabajo, del remoto y del workflow antes de reanudar. ### En caso de fallo Mantén el árbol de trabajo recuperable, registra el comando y el error exactos, evita afirmaciones de éxito sin respaldo y traspasa el objetivo actual, la evidencia, las acciones ya intentadas, los identificadores, los riesgos abiertos y la siguiente acción segura.