Buscar/Corregir documentación técnica según las reglas del proyecto sin romper enlaces

Corregir documentación técnica según las reglas del proyecto sin romper enlaces

Úsalo cuando una IA edite la documentación técnica de un proyecto. Distingue qué archivos se pueden editar, sigue las reglas de redacción y de cada página, comprueba los enlaces, ejecuta solo las pruebas necesarias y hace cambios pequeños y fáciles de revisar.

Para usar estas reglas de IA
## Distinguir los archivos editables de los generados antes de editar - Identifica dónde se encuentran el contenido redactado, los fragmentos reutilizables, las plantillas, los datos estructurados, los recursos estáticos y las referencias generadas. - Considera como fuentes autorizadas la guía de contribución, la guía de estilo, la referencia de componentes y las reglas de metadatos iniciales del repositorio. - Distingue las fuentes editables del contenido incorporado desde fuentes externas o generado antes de realizar un cambio. - No edites directamente archivos incorporados desde fuentes externas ni páginas de referencia generadas. Localiza su fuente original y corrige allí el problema. - Cuando un fallo de validación local se origine en contenido protegido, informa de la fuente original responsable en lugar de aplicar una solución provisional local. ## Usar rutas de archivo reales en los enlaces y comprobar cada destino - Determina si el sistema de publicación reescribe las rutas de origen, elimina partes de ellas o les asigna alias. - Usa la ruta de origen completa en las referencias internas cuando el sistema de compilación resuelva los enlaces con respecto al árbol de fuentes, aunque la URL pública sea más corta. - Comprueba los anclajes con los identificadores de encabezado que genera el procesador real, incluidas las reglas de conversión a minúsculas y de creación de slugs. - Verifica los enlaces de sustitución en vez de adivinarlos. Si no puedes confirmar el destino, considera bloqueado el cambio, salvo que una migración consolidada permita usar con seguridad una URL sin anclaje. - Antes de cambiar la referencia a un recurso ausente, inspecciona el sistema de archivos virtual del framework y los recursos que proporcionan las dependencias, además de la carpeta de fuentes visible. ## Escribir frases cortas y directas con los términos aprobados del proyecto - Escribe de forma directa, concisa y con voz activa. - Elimina expresiones evasivas, relleno promocional, comentarios sobre el propio texto y formulaciones que presenten una tarea como carente de esfuerzo. - Da prioridad a las instrucciones centradas en el lector y nombra el producto o sistema cuando sea necesario dejar clara la propiedad. - Utiliza la terminología, el uso de mayúsculas y minúsculas, los verbos de la interfaz y las reglas de énfasis aprobados por el repositorio. - Conserva las notas permanentes de introducción de versiones cuando expliquen cuándo comenzó un comportamiento; evita expresiones relativas cuyo significado caduque con el tiempo. - Añade los términos técnicos legítimos a la lista de vocabulario permitido más específica. Usa las mayúsculas y minúsculas canónicas y evita patrones amplios que desactiven comprobaciones no relacionadas. ## Completar el título y la descripción de cada página y escribir bien los componentes - Incluye todos los campos de metadatos obligatorios, como el título de la página, la descripción para vistas previas y las palabras clave de búsqueda. - Mantén las etiquetas de navegación dentro de los límites documentados y usa campos de ordenación solo cuando la sección los requiera. - Consulta la referencia de componentes antes de escribir shortcodes del framework o componentes incrustados; una sintaxis no válida puede fallar sin avisar y producir contenido defectuoso. - Sigue el comportamiento documentado de las directivas de interfaz del lado del cliente. No combines dos mecanismos de ocultación si uno puede anular al otro de forma permanente; usa el patrón de ocultación previo a la inicialización del framework. - No cambies la configuración global únicamente para eludir una limitación de la compilación local o del árbol de trabajo. ## Formatear y revisar primero los archivos cambiados y luego todo el sitio si hace falta - Después de editar, ejecuta el formateador proporcionado por el repositorio sobre los archivos modificados. - Antes de una validación más amplia, ejecuta el analizador limitado a archivos que combina comprobaciones del marcado y del texto. - Durante el trabajo incremental, da prioridad a las comprobaciones específicas para que los fallos no relacionados no oculten el resultado. - Ejecuta compilaciones completas del sitio y comprobaciones de enlaces cuando el cambio afecte al enrutamiento, los componentes compartidos, la navegación, las referencias generadas u otros comportamientos entre páginas. - En entornos donde un objetivo de validación integral sea incompatible, ejecuta por separado las comprobaciones compatibles y deja la configuración sin cambios. - Completa la verificación aplicable sin esperar otro recordatorio e informa de cualquier comprobación que no se haya podido ejecutar. ## Hacer un cambio pequeño por problema y responder a cada comentario de revisión - Crea un único conjunto de cambios enfocado para cada incidencia. No mezcles tareas de limpieza cercanas ni refactorizaciones no relacionadas con las correcciones de documentación. - Prepara los archivos de forma explícita. No uses nunca comandos de preparación amplios que puedan incluir archivos de bloqueo o cambios generados. - Antes de confirmar los cambios, inspecciona la lista de archivos preparados y excluye todo lo que quede fuera del ámbito de documentación previsto. - Confirma que el destino de cualquier envío sea la bifurcación del colaborador u otro repositorio remoto aprobado, no el repositorio original protegido. - Trata los informes de incidencias y las sugerencias de revisión como afirmaciones que deben verificarse. Confirma el comportamiento observado antes de modificar la documentación. - Responde a cada hilo de revisión después de atenderlo, incluidos los comentarios en líneas concretas que puedan requerir una llamada independiente a la API de revisión. - Usa el endpoint del servicio que haya demostrado conservar las etiquetas y los metadatos cuando un comando abreviado no sea fiable. ## Eliminar páginas o añadir una versión nueva sin dejar enlaces rotos - Antes de eliminar una página, busca su slug, título, alias y referencias entrantes en el contenido redactado y en la configuración de navegación. - Al avanzar una referencia versionada, actualiza la configuración central de versiones, crea la página de la nueva versión y traslada a ella los alias de la versión más reciente desde la página anterior, todo en un único cambio. - No permitas nunca que dos páginas de versión reclamen el mismo alias de la versión más reciente. - Para las referencias generadas, modifica la especificación o el generador original y vuelve a generar el contenido; no edites manualmente la página generada. - Mantén las correcciones al mínimo, verifica el fallo real y conserva una vía de escalado clara cuando la propiedad o las pruebas externas sigan sin resolverse.