Actualizar y ampliar instrucciones de IA hechas desde un solo original para varias herramientas de IA

## Encontrar qué parte se encarga de algo antes de cambiarlo Trate el repositorio como un conjunto de capas con responsables definidos, no como una colección dispersa de archivos. Antes de editar, identifique qué capa es responsable del comportamiento solicitado: - las instrucciones fuente definen operaciones reutilizables para los usuarios; - las referencias compartidas definen contratos y esquemas transversales; - los scripts auxiliares implementan procesos repetibles; - los adaptadores convierten las instrucciones canónicas en paquetes específicos para cada plataforma; - las distribuciones generadas contienen resultados que pueden volver a compilarse; - los hooks hacen cumplir las reglas del repositorio y de los resultados; - la arquitectura y los manuales de operación explican cómo interactúan las capas; - los archivos de dependencias e instalación definen el entorno de ejecución compatible. Use la capa de fuentes canónicas como autoridad. Las distribuciones generadas demuestran que la compilación funciona, pero no son fuentes de verdad independientes. Vuelva a generarlas mediante el flujo de compilación documentado en lugar de editarlas directamente. Localice el archivo autoritativo más pequeño que controle el comportamiento solicitado y, a continuación, identifique todos los documentos, esquemas, pruebas y artefactos generados que dependan de él y deban mantenerse sincronizados. ## Tener un solo original y crear la versión de cada herramienta con un convertidor Mantenga las instrucciones reutilizables en un único formato fuente independiente de la plataforma. Deje que los adaptadores realicen el empaquetado y la conversión de sintaxis que requiera cada entorno compatible. Un adaptador puede: - copiar una fuente compatible sin cambios semánticos; - emitir un paquete de habilidad nativo por cada operación; - ensamblar un motor compartido con varios puntos de entrada; - crear un paquete de plataforma con prompts y habilidades auxiliares; - generar un despachador y una tabla de enrutamiento a partir de los metadatos de la fuente. Los adaptadores deben conservar el comportamiento y las restricciones originales. Cuando el entorno de destino use herramientas distintas, traduzca los nombres específicos de la plataforma en acciones neutrales. Genere los metadatos de enrutamiento a partir de la descripción canónica en vez de mantener un segundo catálogo escrito a mano. Al añadir una operación, edite una sola vez su fuente canónica. Use una exclusión explícita de plataforma únicamente cuando la operación no pueda funcionar en ella. Vuelva a compilar todos los adaptadores afectados y revise sus resultados para detectar desviaciones semánticas. ## Marcar cada nota guardada con sus fuentes y su nivel de certeza Toda operación que escriba artefactos de conocimiento debe seguir el contrato de escritura canónico del repositorio. Diseñe los artefactos para que permitan una recuperación y un razonamiento futuros fiables, no solo para que resulten legibles de inmediato para una persona. Exija que cada artefacto incluya: - un breve preámbulo que explique su propósito a un futuro lector de IA; - metadatos estructurados, como el tipo de artefacto, la fecha, las etiquetas y una marca `AI-first` explícita; - enlaces internos estables para las personas, los proyectos, las ideas y las decisiones mencionados; - indicadores de vigencia para las afirmaciones que puedan quedar desactualizadas; - las URL de las fuentes conservadas literalmente junto a las afirmaciones externas; - etiquetas de confianza que distingan hechos declarados, evidencia sólida, evidencia moderada y especulación. No elimine metadatos, enlaces, procedencia ni señales de confianza para que un artefacto parezca más limpio. Si una operación introduce un nuevo tipo de artefacto, amplíe el esquema compartido antes de producirlo. ## Usar reglas de escritura que las comprobaciones automáticas puedan confirmar Use convenciones que los formateadores y los hooks puedan verificar de manera uniforme: - escriba los encabezados Markdown con mayúsculas de tipo oración; - no incluya emojis decorativos en las fuentes de instrucciones; - use puntuación ASCII en lugar de sustituciones tipográficas, salvo cuando un símbolo no ASCII tenga un significado propio; - use valores de etiqueta en minúsculas y ponga entre comillas las cadenas de metadatos ambiguas; - respete la versión del lenguaje, el formateador, el límite de longitud de línea y el gestor de dependencias configurados; - use asuntos de commit en modo imperativo y aplique la política de atribución del repositorio. Trate el formateador canónico y los hooks de validación como la autoridad final para el estilo mecánico. No los eluda ni conserve manualmente formatos que rechacen. Mantenga las convenciones lo bastante acotadas como para poder aplicarlas automáticamente. Cuando una regla no pueda comprobarse de forma mecánica, documente la evidencia de revisión necesaria para confirmarla. ## Al añadir una tarea nueva, actualizar a la vez los manuales y las listas Use esta secuencia al añadir una operación nueva: 1. Cree la fuente de instrucciones canónica con metadatos de enrutamiento y una guía operativa completa. 2. Añada un auxiliar en el área de scripts designada solo cuando sea necesaria lógica ejecutable. 3. Haga referencia al contrato de escritura compartido desde todas las rutas que puedan crear o modificar un artefacto. 4. Amplíe el esquema de metadatos compartido antes de introducir un nuevo tipo de artefacto. 5. Actualice el manual de operación, el inventario de capacidades, las notas de arquitectura y el catálogo público de comandos. 6. Registre el cambio en la sección de cambios aún no publicados. 7. Ejecute la compilación de los adaptadores e inspeccione los resultados de todas las plataformas afectadas. No duplique una operación en árboles de plataforma generados. Un cambio sincronizado actualiza conjuntamente la fuente, las referencias rectoras, las pruebas y la documentación, para que las compilaciones posteriores no puedan borrarlo ni contradecirlo. ## Probar por separado las instrucciones y el proceso que crea las versiones Pruebe por separado el comportamiento de la fuente y el proceso de generación. Use un espacio de trabajo de prueba aislado o una copia de trabajo local enlazada en lugar de un almacén de conocimiento activo. Para validar el comportamiento: - invoque la operación modificada con datos de prueba representativos; - inspeccione los artefactos resultantes; - verifique los metadatos, enlaces, procedencia, etiquetas de confianza y demás campos obligatorios del contrato de escritura; - confirme que los hechos desconocidos sigan marcados explícitamente como tales. Para validar el proceso: - ejecute la suite de pruebas de humo del repositorio mediante el ejecutor de paquetes configurado; - verifique las ubicaciones de los resultados de los adaptadores y el enrutamiento generado; - pruebe las interfaces de los scripts auxiliares y los resultados legibles por máquinas; - actualice la aserción correspondiente en el mismo cambio cuando se modifique intencionadamente la disposición de los resultados. Ejecute primero la prueba pertinente más acotada y después la suite de pruebas de humo afectada. Las comprobaciones manuales de comportamiento complementan las pruebas automatizadas; no las sustituyen. ## Publicar una versión nueva solo tras pasar las comprobaciones y con permiso Publique únicamente cuando la integración continua esté en verde y se siga cumpliendo el contrato de escritura orientado a máquinas. Use una secuencia de publicación controlada: 1. Mueva las entradas de cambios aún no publicados bajo un encabezado de versión con fecha. 2. Actualice la versión en el archivo principal del paquete y en todos los archivos de manifiesto o cita replicados. 3. Ejecute comprobaciones de divergencia que comparen todas las declaraciones de versión. 4. Vuelva a compilar las distribuciones generadas y ejecute las pruebas afectadas. 5. Confirme el rol de publicación y la política de ramas antes de etiquetar o hacer push. 6. Publique las notas de la versión a partir de la entrada aprobada del registro de cambios. Proteja las ramas predeterminadas compartidas. Los colaboradores deben usar la vía de revisión requerida. Un responsable de mantenimiento puede publicar directamente solo cuando la política del repositorio le conceda explícitamente esa autoridad y se hayan superado las mismas puertas de verificación. ## No inventar datos que faltan ni editar a mano los archivos generados Nunca debilite el contrato de recuperación del sistema por motivos estéticos. No quite los preámbulos ni los metadatos obligatorios, no reescriba artefactos orientados a máquinas solo para que suenen más humanos ni añada elementos decorativos prohibidos por las convenciones de las fuentes. No invente tasas, fechas, propiedad, relaciones ni otros hechos ausentes. Marque los valores desconocidos con `TBD` o con el indicador explícito equivalente que use el repositorio. Nunca edite un resultado generado cuando pertenezca a un generador. No eluda los hooks, no publique mediante una rama no autorizada ni afirme que algo funciona basándose únicamente en la inspección de la fuente. Antes de informar de la finalización: - revise la diferencia prevista completa para detectar cambios no relacionados; - confirme que las fuentes canónicas y los resultados generados coincidan; - ejecute el formateador, los hooks, las pruebas y la compilación de adaptadores pertinentes; - verifique los esquemas, manuales, catálogos y entradas del registro de cambios que deban sincronizarse; - registre toda validación manual y cualquier comprobación que no haya podido ejecutarse; - confirme que la acción final de publicación correspondió al rol autorizado. Informe del comportamiento modificado, la evidencia de verificación, las limitaciones restantes y cualquier decisión que siga pendiente.