Generar esquemas de comandos para agentes de IA a partir de los comandos y flags reales

## Cambia el registro y los generadores, no los archivos generados Trata las directrices del repositorio como un contrato para los archivos de su ámbito. Conserva el trabajo no relacionado, aplica el formateador del lenguaje a cada archivo fuente modificado y cambia únicamente la entrada propietaria mínima necesaria para obtener el comportamiento solicitado. Identifica las entradas autorizadas antes de editar. Un registro de comandos revisado debe controlar la identidad estable de los comandos, las rutas principales, los alias y la navegación. El árbol de comandos ejecutable debe determinar si una ruta existe, si se puede ejecutar y qué indicadores acepta. Los catálogos generados y los metadatos de agentes son salidas, no superficies de edición; modifica sus entradas de origen y sus generadores y, después, vuelve a generarlos. Ejecuta la compilación, las pruebas completas, la generación, las comprobaciones de desviaciones, las comprobaciones de políticas y las pruebas de comandos específicas que el repositorio establezca para el cambio. Revisa las diferencias generadas y rechaza las reescrituras no relacionadas. ## Crea los esquemas en un solo sentido y vincula cada comando una vez Mantén unidireccional la resolución del esquema: 1. Construye el árbol de comandos y los indicadores realmente ejecutables. 2. Combina el registro de identidad revisado con las superposiciones de metadatos revisadas antes del enlace. 3. Resuelve los tipos y las asignaciones de parámetros, los estados obligatorios, los valores predeterminados y las restricciones entre parámetros. 4. Resuelve la selección del agente y la semántica de seguridad, interfaz y puertas de ejecución según la precedencia de fuentes declarada. 5. Enlaza cada comando exactamente una vez en una única especificación tipada de herramienta y su índice. 6. Publica catálogos, exportaciones completas, resúmenes y metadatos generados únicamente desde esa fuente tipada. Después del enlace, no vuelvas a abrir anotaciones, registros fuente, catálogos anteriores ni JSON generado para reparar o volver a resolver la identidad. Un cargador de producción que descodifica una instantánea incrustada es un límite de entrega, no una segunda fase de resolución de fuentes. Nunca debe crear ni reparar comandos, indicadores, entradas de registro o entradas de generación posteriores. Conserva el contrato de formato serializado publicado salvo que se autorice expresamente un cambio versionado. La alineación arquitectónica con otro sistema no justifica un cambio de formato sin versión. ## Comprueba en ambos sentidos que cada comando y cada esquema coincidan El enlazador debe rechazar las rutas de comandos ausentes o no ejecutables, las colisiones de alias y las declaraciones de identidad nativas que no coincidan con el registro efectivo. Puede permitirse una declaración de identidad nativa ausente cuando las anotaciones sean comprobaciones de coherencia y no fuentes de identidad alternativas. Impón la cobertura en ambas direcciones: 1. Toda herramienta de esquema entregada, incluida su proyección en el catálogo, debe resolverse hacia un comando ejecutable. 2. Toda hoja de comando pública y ejecutable debe resolverse hacia el esquema o figurar en una exclusión exacta, revisada y con un motivo no vacío. Nunca uses exclusiones por prefijo o comodín, ya que pueden ocultar comandos futuros. Las exclusiones obsoletas, no válidas o duplicadas deben hacer que la generación falle, y una exclusión debe retirarse cuando su comando entre en el esquema. Trata el registro revisado como la única fuente de identidad estable y navegación, y el árbol ejecutable como la fuente de verdad sobre rutas, capacidad de ejecución e indicadores. Ejecuta pruebas de completitud inversa siempre que cambie el árbol de comandos. ## Separa los metadatos de seguridad de los textos de selección del agente Divide las entradas redactadas por personas según su propiedad. Los metadatos controlan los efectos, el riesgo, la confirmación, la idempotencia, las interfaces, las puertas de ejecución y las superposiciones opcionales de parámetros. La selección controla los resúmenes para agentes, las directrices de enrutamiento positivas y negativas, los ejemplos y el enrutamiento de productos. Un índice solo debe asignar identificadores de productos a esos archivos. No mezcles campos entre estos bloques. Cada entrada redactada debe revisarse expresamente, incluir un motivo concreto de revisión y referencias de evidencias, y ser la entrada mínima que exprese el comportamiento visible para el usuario. El texto de selección debe explicar la intención de activación, el enrutamiento entre comandos relacionados y los resultados esperados, en lugar de repetir el resumen de un comando. Resuelve las evidencias según la precedencia declarada: primero los hechos del entorno de ejecución, después el esquema de interfaz activo, los metadatos de interfaz fijados y, por último, la documentación de habilidades solo como evidencia. Cuando la consulta activa use credenciales personales, nunca muestres ni incorpores credenciales de acceso a un commit. Si la consulta activa falla, registra el fallo, utiliza las evidencias alternativas aprobadas y no inventes una interfaz ni un procedimiento remoto. Las superposiciones de parámetros deben apuntar a una hoja pública y ejecutable exacta y a indicadores reales. Pueden precisar descripciones, asignaciones de interfaz, estados obligatorios y requisitos condicionales, pero no deben crear comandos o indicadores, definir una interfaz ni anunciar un procedimiento remoto desconocido. ## Reconstruye todas las salidas desde cero y comprueba que coincidan Trata la generación como una reconstrucción completa y determinista de la instantánea, no como un parche incremental sobre un catálogo anterior. Vuelve a leer todas las entradas revisadas, retira los metadatos de productos generados que hayan quedado obsoletos y reescribe las proyecciones de salida exactas. Los archivos generados nunca deben convertirse en entradas de combinación, y las protecciones por bytes deben fallar si la generación cambia entradas redactadas o el registro revisado. Usa la misma especificación tipada de herramienta ya resuelta para todas las proyecciones. La carga de una hoja debe ser igual a su entrada correspondiente en la exportación completa y el catálogo, mientras que los resúmenes generales y de grupo deben ser iguales a la proyección resumida de esa misma herramienta. Una consulta mediante alias solo puede cambiar los campos de vista propios del alias; no debe volver a resolver ni modificar el contrato del comando. Para cada herramienta y campo de parámetro entregados, el valor de procedencia seleccionado debe ser exactamente igual al valor entregado. No basta con comprobar el nombre de la fuente, el número de candidatos, la presencia del campo o el hash. Ejecuta la generación, las comprobaciones de veracidad de la confirmación en ejecución, las pruebas de completitud inversa, las pruebas de comandos específicas y las comprobaciones finales del cargador incrustado. Revisa todas las diferencias resultantes antes de aceptar la instantánea. ## Valida ejemplos y ejecuciones de prueba sin saltos ni --yes Guarda como máximo dos ejemplos revisados por herramienta. Los ejemplos deben usar una ruta principal o un alias reales, indicadores aceptados, argumentos posicionales obligatorios y todas las restricciones efectivas `require-one-of`, `require-together` y `mutual-exclusion`. No incluyas comentarios de shell ni indicadores que omitan la confirmación, como `--yes`. Cada ejemplo debe superar la validación del contrato con respecto a su comando enlazado. La ausencia de un valor obligatorio, el incumplimiento de una restricción, un error de ejecución o un error de resolución de interfaz son defectos del contrato, no motivos para omitir el ejemplo. La ejecución de ejemplos en tiempo de ejecución es voluntaria y solo se permite cuando la herramienta tipada final publica una capacidad explícita y revisada de ejecución de prueba. Los metadatos de riesgo y confirmación no deben fabricar compatibilidad con vistas previas. Una disposición manual revisada puede limitar una capacidad de ejecución de prueba existente a un índice de ejemplo exacto que empiece en cero, pero debe usar un código de motivo aprobado, aportar un motivo concreto y nunca convertir la validación ordinaria del contrato en una omisión. Nunca captures un fallo de ejecución de prueba para degradarlo dinámicamente a una validación solo del contrato. Ejecuta de forma predeterminada puertas exhaustivas del contrato; con el comando real, ejecuta únicamente el subconjunto apto para pruebas, con el estado del usuario aislado y los proxys bloqueados. Trata los cambios en los recuentos estables de ejecución como cambios de contrato sujetos a revisión. ## Prueba qué comando elige la IA sin enviarle las respuestas esperadas Trata cada escenario de selección positivo como una afirmación de que debe elegirse su comando revisado, y cada escenario negativo como una afirmación de que ese comando no debe elegirse. Deriva casos de prueba tipados y deterministas de los campos de selección redactados, exige una cobertura exacta de herramientas y comandos principales ejecutables y rechaza expectativas ausentes, duplicadas o contradictorias. La coincidencia de cadenas por sí sola no demuestra comprensión semántica. Mantén expresamente voluntarias las comprobaciones de selección con un modelo activo. Admite un pequeño conjunto básico, un conjunto revisado completo y una lista exacta de casos. Envía al evaluador únicamente los identificadores de caso, el texto del escenario y una tabla de candidatos del mismo producto; conserva en local las afirmaciones esperadas y prohibidas. Incluye en la lista de permitidos los puntos finales HTTPS integrados del evaluador. Cualquier otro proveedor HTTPS requiere que su URL base exacta figure en la lista aprobada, y el HTTP sin cifrar solo es aceptable para un servidor de prueba de bucle local. Nunca envíes credenciales de API a un punto final arbitrario sin cifrar. La integración continua normal debe seguir siendo determinista y no debe llamar a ningún modelo. Sus puertas bloqueantes son los casos de prueba reproducibles, el enlace de comandos, la validez de los ejemplos, la procedencia y la igualdad de la entrega final. ## Decide la seguridad y la confirmación según la prioridad de las fuentes Resuelve los metadatos de seguridad y parámetros según la precedencia de fuentes, no eligiendo el valor que parezca más estricto. Una fuente revisada de mayor prioridad puede aumentar o reducir intencionadamente el efecto, el riesgo, la confirmación, la idempotencia, las descripciones o las asignaciones. Conserva todos los candidatos y la fuente seleccionada, y haz que los conflictos del mismo nivel de precedencia fallen en lugar de combinarlos silenciosamente. Los indicadores obligatorios de un comando son un límite inferior inalterable: una superposición puede convertir un indicador opcional en obligatorio, pero nunca debe debilitar un requisito declarado por el comando ejecutable. Para el texto de los comandos, prioriza las indicaciones específicas y revisadas del comando, después la ayuda del comando y, por último, los metadatos de interfaz; el texto genérico de procedimientos remotos no debe sustituir una descripción especializada del comando. No deduzcas un campo de seguridad a partir de otro. Un efecto destructivo o un riesgo alto no reescriben mecánicamente la confirmación. La confirmación debe coincidir con la puerta de ejecución explícita y, cuando se requiera confirmación del usuario, debe obtenerse antes de añadir un indicador de omisión como `--yes`. Si la ayuda distribuida del comando y el esquema de hoja no coinciden, pasa únicamente indicadores aceptados por el comando ejecutable. Si las fuentes de seguridad entran en conflicto, usa la interpretación más segura o detente e informa de la desviación del contrato. Verifica la semántica de confirmación a través del cargador incrustado final y la ruta de consulta, no solo mediante una prueba unitaria del generador. ## Descubre los comandos por pasos y obtén los datos con comandos reales Mantén progresivo el descubrimiento ordinario: primero la vista general, después el producto o grupo y, por último, la hoja. Reserva la exportación completa como contrato de compatibilidad estable e incluye los parámetros, las restricciones y la semántica de seguridad completos para cada herramienta final, incluido un objeto de parámetros vacío para comandos sin indicadores. Una exportación completa compacta no constituye una referencia de compatibilidad completa. La ayuda del comando determina si existe una ruta y qué indicadores acepta el ejecutable. El esquema de hoja determina la selección del agente, la asignación y las restricciones de parámetros, y la semántica de seguridad y confirmación. Cualquier discrepancia es una desviación del contrato, no un permiso para adivinar. Los esquemas y la ayuda describen comandos; no devuelven datos empresariales. Después del descubrimiento, ejecuta el comando real de lectura, búsqueda o listado que corresponda, dentro de sus permisos confirmados, para obtener los datos. Antes de la entrega, confirma que la identidad de comandos esté revisada, la cobertura ejecutable sea bidireccional, las exclusiones sean exactas, los bloques redactados mantengan propiedades separadas, se preserve la precedencia de fuentes, las salidas generadas sigan siendo solo salidas, los ejemplos superen sus contratos reales, la confirmación coincida con las puertas de ejecución y todas las proyecciones sean iguales a la misma fuente tipada.