Editar el Content Center a nivel XML

Hay una categoría de trabajo que casi nunca sale en LinkedIn: la aburrida. Nadie publica capturas de un log de cambios ni celebra un backup que se restauró bien. Y sin embargo, cuando repaso los proyectos que he visto salvarse en el último tramo, casi siempre los salvó algo aburrido: una copia de seguridad, un reporte previo, un registro de qué cambió y cuándo.

Esta es la historia de una de esas herramientas: el Content Center Smart Editor, un tooling en Python para editar familias del Content Center de Inventor a nivel XML. Cero IA, y con razón.

El problema: días de clics

El Content Center es la librería de la que dependen los diseños de toda una empresa: tornillos, perfiles, tubería, componentes estándar. Hay ajustes que en la interfaz significan abrir familia por familia, campo por campo, durante días. Cambiar una propiedad en decenas de familias, corregir una nomenclatura, ajustar valores que quedaron mal desde una migración. Nadie quiere hacer ese trabajo a mano, así que se aplaza. Y se aplaza. Hasta que un proyecto lo necesita con urgencia y ya no hay días disponibles.

Debajo de esa interfaz hay una estructura XML perfectamente editable. Las familias del Content Center se pueden leer, modificar y escribir con código, en lote, en minutos. La pregunta no es si se puede: es cómo hacerlo sin romper la librería de la que depende todo el mundo.

Tres reglas no negociables

Backup automático antes de tocar cualquier familia. No es opcional y no depende de que alguien se acuerde: el tooling lo hace solo, siempre. Si un cambio sale mal, el estado anterior existe y se restaura. La diferencia entre un susto y una catástrofe es exactamente esa copia.

Revisión previa en lote. Antes de ejecutar, el reporte: qué familias se van a tocar, qué campos, qué valores hay y cuáles van a quedar. La ejecución viene después de leer ese reporte, no antes. Si el patrón de cambio está mal diseñado, se descubre en el papel, no en la librería.

Log de cada cambio. Qué familia, qué campo, qué valor había y cuál quedó. La trazabilidad no es burocracia: es lo que permite responder, seis meses después, la pregunta de por qué un componente se comporta distinto. Sin log, esa pregunta se responde con arqueología y suposiciones.

Por qué cero IA

Si me sigues, sabes que construyo agentes de IA para estos mismos productos. Aquí no la usé, y la razón es la misma que repito cuando me preguntan si la IA sirve para todo: este era un problema de regla clara. Los cambios se describían con exactitud, no había excepciones que negociar ni criterio que aplicar en medio de la ejecución. Y las reglas claras se automatizan con código determinista, que es más barato, más auditable y no alucina.

Sospecho que por eso funcionó tan bien. La herramienta correcta para ese problema no era la más moderna: era la más trazable. Backup, preview, log. Lo aburrido que salva proyectos.