NavisCoord

Matriz de coordinación: decisiones abiertas por cruce de disciplinas. Responde una pregunta distinta a la lista priorizada. La lista dice qué abrir primero; la matriz dice **qué dos equipos tienen que sentarse**, que es lo que decide a quién se convoca a la reunión.

Qué instancia y qué documento están seleccionados ahora mismo.

Los problemas a atacar, ya sin los que otra decisión cierra. Filtra opcionalmente por prioridad: critical, high, medium, low.

Lee cómo está estructurado ESTE modelo, sin asumir nada. Muestrea el modelo y reporta cada propiedad que existe con su cobertura real, detecta sistemas de clasificación por la FORMA de los valores (OmniClass, Uniclass, MasterFormat, UniFormat, IFC, códigos corporativos) —no por el nombre del parámetro, que cambia según quién armó el modelo— y evalúa qué propiedad separa de verdad las especialidades. La prueba clave: una llave de disciplina agrupa por QUÉ SON las cosas; una de nivel agrupa por DÓNDE ESTÁN. Se mide con información mutua contra la categoría, así que funciona en cualquier idioma…

Cierra el documento y sale de Navisworks de forma verificable. Usa las mismas disposiciones explícitas de `navis_close_document`. El puente responde antes de solicitar WM_CLOSE y este servidor comprueba que el PID terminó. Si Navisworks sigue abierto —por ejemplo, por un diálogo de otro complemento— devuelve `partial`, nunca un falso `completed`. Con `dry_run=true` no cierra nada. Espera hasta `verify_timeout` segundos (45 por defecto, máximo 50; en la prueba en vivo del comité Navisworks tardó 36 s en terminar el proceso): descargar un federado tarda, y con 15 s un cierre en curso se report…

Paso 3 — agrupa los resultados de cada test por nivel. Es la organización con la que se preparan las incidencias en ACC. Solo toca resultados sueltos: lo ya agrupado, por una corrida anterior o a mano, se respeta, así el paso es re-ejecutable tras cada Update All. Además renombra los choques con nombre por defecto (Clash 1, Conflicto 2) a «NNN · elemento vs elemento» y detecta interferencias-tipo repetidas en tres o más niveles, para abrir UNA incidencia por serie en vez de una por piso. Recuerda guardar: nada de esto queda en disco hasta hacerlo.

Genera los artefactos que consumen las herramientas que consumen la coordinación. Escribe: · coordination_handoff.json — el contrato compartido, con los problemas resueltos hasta ElementId de Revit y código de presupuesto · revit_worklist.json — el trabajo agrupado por modelo de autoría, listo para que el MCP de Revit lo ejecute modelo por modelo · fct_issues.csv + brg_issue_elements.csv + dimensiones — esquema estrella para Power BI, unido por el mismo código de presupuesto que ya usa el tablero Reporta cuántos problemas son rastreables hasta Revit; los que no lo son s…

Estado del puente y del documento abierto en Navisworks. Llama esto PRIMERO. Reporta la versión de Navisworks, qué documento está activo, cuántos modelos tiene la federación y cuántos tests y resultados de clash existen. Todo lo demás actúa sobre ese documento. Si hay varias instancias de Navisworks abiertas, responde la seleccionada con navis_target o, si no elegiste ninguna, la más reciente — y lo dice.

Zonas del modelo con más severidad acumulada, para recorrerlas en orden. `cell_size_m` discretiza el modelo en una rejilla, así que es un divisor: con cero, el motor falla varias llamadas más adentro y el error no señala al argumento que lo causó.

Por qué NavisCoord no pudo arrancar y cómo arreglarlo.

Detalle completo de un problema: elementos, propiedades, por qué puntúa así.

Estado, fase y avance de un trabajo en curso. Se responde sin tocar el documento, así que sigue contestando mientras Navisworks está ocupado con el trabajo. El avance es honesto: cuando el paso recorre unidades reporta unidades y porcentaje; cuando es una sola llamada atómica del API dice «indeterminate» y la fase, en vez de inventar una barra.

Los trabajos de esta sesión del puente, con el que esté activo.

Lista los conjuntos de selección del documento. No modifica nada. Es la lectura con la que se comprueba lo que `navis_build_search_sets` dejó escrito, y la única de este grupo que no exige huella ni destino para mutar: sin escritura no hay nada que proteger. `item_count` solo es real para conjuntos explícitos. Un search set guarda la regla, no la lista, así que Navisworks no reporta un tamaño hasta reevaluarla — se devuelve `null` en vez de un cero que se leería como «vacío».

Lista los tests de clash del documento con su estado y conteo.

Carga un perfil de proyecto (pesos, tolerancias, reglas de disciplina). Sin argumento recarga el perfil por defecto. El perfil es la única fuente de criterio: cambiarlo cambia qué se considera grave, sin tocar código. El perfil se instala en LOS DOS lados: aquí y en el complemento, que lo recibe por el puerto autenticado y lo usa para `workflow/rules`, Configurar, los search sets y la matriz. Antes solo se cargaba aquí y el complemento seguía leyendo su propio archivo del disco, así que cargar un perfil y correr las reglas aplicaba criterios distintos sin decirlo. La respuesta trae `checksu…

Inventario de la federación: archivos, tamaños e histograma de categorías. Úsalo antes de armar la matriz de tests. El histograma de categorías por archivo es lo que permite decidir la disciplina de cada modelo con evidencia en lugar de adivinar por el nombre del archivo.

El informe redactado: qué le pasa a este modelo, en prosa. Separa lo que es problema de DISEÑO (decisiones que no se tomaron), de MODELADO (el modelo no representa el alcance real) y de COORDINACIÓN (dos especialidades que no han hablado) — que es la distinción que una lista de cruces nunca hace y de la que depende a quién se le pide qué. Emite además un veredicto de si el modelo está en condiciones de coordinarse punto por punto.

Dónde puede escribir este servidor, y cómo autorizar otra carpeta. Toda salida —PDF, handoff, CSV, export, save_as— se resuelve contra esta política. Una ruta fuera de las raíces permitidas se rechaza con el motivo, en vez de escribirse en cualquier sitio que pida quien llama.

Genera el informe PDF de coordinación. Portada con el resumen y las causas raíz, la matriz de coordinación con la agenda sugerida, y **una página por interferencia** con su imagen 3D renderizada por Navisworks, la ubicación, quién mueve, por qué importa y qué hacer. **Las imágenes se verifican, no se asumen.** De cada una se comprueba que los dos elementos en conflicto están dentro del encuadre (proyectando sus cajas por la cámara que se aplicó de verdad) y que ambos aparecen en los píxeles, que es lo único que detecta que un muro tapaba el cruce. La que no pasa se vuelve a tomar más abierta…

Qué perfil usará de verdad el complemento en el próximo paso. Reporta esquema, checksum, nombre, cuándo se cargó, la sesión a la que pertenece y de dónde salió: `explicit_mcp` si lo enviaste con `navis_load_profile`, `plugin_default` o `packaged_default` si el complemento lo encontró en disco. Trae también el perfil del servidor, para que la pregunta «¿los dos lados están usando el mismo?» se responda con dos checksums en la misma respuesta en vez de con dos llamadas y una suposición.

Propone el mapeo archivo → disciplina, para revisión humana. No aplica nada. Un mapeo equivocado envenena en silencio toda la priorización posterior y termina culpando al equipo incorrecto, así que la propuesta se confirma antes de usarse.

Quita todos los colores aplicados sobre el modelo. Sin argumentos borra TODO override de apariencia del documento, incluidos los que puso una persona a mano. Es la mutación más fácil de disparar por error y la única sin dry_run, así que la huella se comprueba igual.

Devuelve el complemento a su perfil por defecto (el del disco). Deshace lo que hizo `navis_load_profile` en el complemento: a partir de aquí los pasos que corren dentro de Navisworks vuelven a usar el archivo que encuentre en disco, reportado como `plugin_default`. Útil para volver al perfil corporativo de la máquina tras probar uno alternativo. El servidor sigue con el perfil que tenga cargado; `navis_profile_info` muestra los dos lados.

Patrones sistémicos detectados: cota errada, pasos faltantes, detalle repetido, zonas saturadas. Esto es lo que comprime un ciclo de coordinación. Una causa raíz con cuarenta problemas debajo se cierra con una decisión, no con cuarenta. Devuelve las `limit` más grandes más un conteo por tipo. Un modelo real genera decenas de causas del mismo tipo —48 sistemas mal trazados, 19 zonas saturadas— y volcarlas todas son 61 KB de texto casi repetido.

Paso 2 — corre todos los clash tests (equivale a Run All). Por defecto asíncrono: en un federado real esto retiene el hilo de UI de Navisworks durante minutos, y esperar en la conexión HTTP solo consigue que expire. Consulta el avance con navis_job_status. El progreso se reporta por FASE, no por porcentaje: TestsRunAllTests es una sola llamada atómica del API y cualquier barra sería inventada.

Paso 4 — aplica las reglas residuales que declara el PERFIL. Compone dos cosas y nada más: corre todos los tests **solo si** el bloque de reglas del perfil lo pide con `run_tests`, y luego aplica esos pares con `clash/apply_rules`. No agrupa, no colorea y no vuelve a construir sets; si ya corriste los tests, deja `run_tests` en falso en el perfil para no repetirlos. La diferencia con `navis_apply_clash_rules` es de dónde salen los pares: aquí del perfil, allí del llamador. Con un perfil sin bloque de reglas el paso no es un error — devuelve «nada que aprobar», que con el estándar actual es e…

Corre los tests indicados, o todos si no se especifica ninguno. Reporta el conteo de resultados antes y después de cada test, para que un test que no encontró nada se distinga de uno que no llegó a correr. Correr un test escribe sus resultados dentro del documento, así que pasa por el mismo guardia que el resto de las mutaciones aunque no tenga dry_run: no hay ensayo posible de una corrida de clash.

Guarda el documento abierto en su propia ruta. Todo lo que produce el flujo —sets, matriz, resultados, grupos, nombres— vive solo en memoria hasta que alguien guarda: cerrar Navisworks sin hacerlo descarta una corrida entera. Exige `expected_document_fingerprint` (léelo de navis_health): guardar es irreversible y no voy a escribir sobre un documento distinto del que creías. Si el archivo viene de ACC (.nwfacc) esto se rechaza con la razón — guardar encima NO publica nada en la nube y el siguiente sync de Desktop Connector puede reemplazarlo: usa navis_save_as a un .nwf local.

Guarda una copia del documento en otra ruta (.nwf o .nwd). Es la salida correcta para un archivo de ACC: un .nwfacc es la cara local de un documento cuyo maestro vive en la nube, no un .nwf con otro nombre. Guardar como .nwfacc se rechaza; guarda a un .nwf local y publica desde Desktop Connector. La ruta pasa por la política de salida del complemento (raíces autorizadas, sin UNC ni rutas de dispositivo) y `overwrite` es false por defecto. Después de escribir se verifica releyendo: que el archivo exista, que tenga bytes, que la marca de tiempo se haya movido, que el documento apunte al destin…

Guarda el export crudo en disco, para reanalizar sin abrir Navisworks. Útil para afinar el perfil: cambias un peso, corres `python -m naviscoord analyze` sobre el archivo y ves moverse el ranking. La ruta se resuelve contra la política de salida: solo se escribe bajo las raíces autorizadas (`navis_output_policy` las lista) y nunca se reemplaza un archivo existente sin overwrite=true.

Guarda un viewpoint por problema, para recorrerlos dentro de Navisworks.

Selecciona en Navisworks los elementos de un problema. Cambiar la selección es una mutación del documento, aunque no se guarde: se exige la huella y se valida el target, como cualquier otra. Antes no lo hacía, así que después de cerrar Torre A y abrir Torre B esta herramienta mandaba los path id del análisis anterior y el complemento seleccionaba lo que esos identificadores nombraran en el modelo nuevo.

Instancias de Navisworks activas, con su documento y su target_id. Un coordinador tiene a menudo dos abiertas —2024 con el modelo archivado y 2026 con el vivo, o dos proyectos a la vez—. Cada una publica su propia sesión: aquí se ven todas, con cuál está seleccionada.

Fija el mapeo archivo → disciplina, sobrescribiendo la heurística. mapping: {"PROY-HVAC-T1.rvt": "HVAC", ...}

Marca los cruces de esos problemas con un estado (New/Active/Reviewed/Approved/Resolved).

Guarda todas las incidencias con IDs persistentes, perfil y revisión del modelo.

Fija a qué instancia de Navisworks van las llamadas siguientes. Obligatorio para mutar cuando hay más de una abierta: elegir en silencio la última es cómo un plan calculado sobre Torre A termina escrito en Torre B. Los ids salen de navis_sessions.

El plan de trabajo: las decisiones agrupadas en paquetes ejecutables. Mil decisiones ordenadas no son un plan. Nadie trabaja una lista de 1.375 ítems, y entregarla es como termina un informe de coordinación sin leer: correcto, completo e inútil. Esto devuelve paquetes. Primero los SISTÉMICOS —una decisión que cierra cientos, como aprobar el listado de pasos— porque al aterrizar encogen todo lo demás. Después SESIONES: una pareja de especialidades, una zona, dimensionada para que quepa en una reunión, con un responsable. El resto queda contado como cola, no listado, porque fingir que es accio…