Horizun PBI MCP

Registra un custom visual de AppSource en el informe (publicCustomVisuals). Sin argumentos registra "HTML Content" (renderiza HTML/SVG desde una medida DAX). Power BI Desktop lo descarga de AppSource al abrir el informe.

Incrusta una imagen en el informe y la deja lista para usar. La copia a StaticResources y la declara en report.json: sin las dos cosas Power BI no la encuentra y el visual sale vacio sin dar ningun error. Devuelve `item_name`, que es lo que se le pasa al visual de tipo 'image' en options.resource. `path`: archivo local (.png .jpg .gif .bmp .svg).

Carga un archivo al modelo como lo haria una persona: abrir, transformar, cargar. El mismo recorrido de Power Query —Obtener datos, promover encabezados, cambiar tipos, Cargar— pero escrito directo en el proyecto. Los pasos de la consulta se llaman como los pone Power BI ('Origen', 'Encabezados promovidos', 'Tipo cambiado'), asi que se puede abrir y editar en el editor sin que desentone. Admite .csv, .txt, .tsv, .xlsx, .xlsm, .json, .html/.htm y '.xls'. Sin dependencias nuevas: el .xlsx se lee como lo que es, un zip con XML, y el HTML con `html.parser` de la biblioteca estandar. Un '.xls' NO se toma por la extension: se mira la firma real del archivo. En la practica, casi ningun '.xls' que exportan los ERPs es el binario OLE2 que la extension promete -- es una tabla HTML con esa extension porque Excel la abre igual. Si de verdad es OLE2 (Excel 97-2003), se rechaza con un mensaje claro en vez de leerlo mal; si es un .xlsx renombrado, se lee como .xlsx. Para HTML: si el archivo trae varias `<table>`, se elige la mas grande y se avisa (usa `table_id` para elegir una en concreto, el `id` HTML de la tabla). Los encabezados solo se promueven si la tabla usa `<th>`; un reporte sin esa marca (el caso normal en un reporte de ERP, donde la fila 1 es el titulo del reporte, no un encabezado) carga con columnas 'Column1', 'Column2'... **La cultura se deduce del archivo**, mirando como escribe los decimales, y se emite SIEMPRE explicita en la consulta. Asumir la del modelo es lo que convierte 10527.52 en diez millones sin que nada falle: un informe que abre, pinta y miente. `culture` permite forzarla. Lo escrito se valida antes de darlo por bueno: si el TMDL generado no pasara `pbi_validate_tmdl`, se aborta en vez de dejar un proyecto que no abre. **Filas de basura antes del encabezado**: es el patron de export mas comun de un ERP -fila 1 con el titulo del reporte y el resto de la fila vacia, encabezado real en la fila 2-. Por defecto se AUTODETECTA la primera fila que pu…

Crea una tabla apuntando a una BASE DE DATOS o API externa. `source`: sqlserver | postgresql | odata | web_json. - sqlserver/postgresql: `server` + `database` + (`schema`/`source_table` o, solo en sqlserver, `native_query` con plegado activado). - odata: `url` del ENTITY SET (…/odata/Presupuestos), no la raiz. - web_json: `url` que devuelve un array de objetos; `json_path` desciende hasta el (["data","rows"]). Tipado con cultura en-US fija: JSON escribe numeros sin cultura, y la del sistema es el bug del 10527.52 que se vuelve diez millones. `columns` ([{name, type}]) es OBLIGATORIO: sin credenciales no se puede leer el esquema de la fuente, y las columnas no se inventan. **La verdad de las credenciales, por delante**: la consulta queda escrita y validada, pero el PRIMER refresh lo completa una persona en Desktop —pedira credenciales y nivel de privacidad, que viven en Desktop, no en el .pbip—. Hasta entonces la tabla existe sin datos y este servidor no puede verificar la conexion. Prometer otra cosa seria mentir. Escribe TMDL: requiere el proyecto CERRADO en Desktop.

Alinea varios visuales por un borde. `edge`: left | right | top | bottom | center_h | center_v. Determinista: la misma entrada produce siempre la misma salida.

Detecta problemas tipicos del modelo (calidad). Revisa medidas sin carpeta, DAX muy largo, relaciones bidireccionales/ inactivas, columnas calculadas, IDs visibles, ausencia de calendario, etc.

Aplica las acciones devueltas por pbi_plan_audit_fixes. Requiere confirm=true. Cada accion se aplica por su propia via segura (transaccion, verificacion y rollback); si una falla, se reporta sin detener las demas y sin ocultarlo.

Aplica el sistema al informe y devuelve su rejilla. Escribe el tema y lo declara en `report.json`. Devuelve el lienzo, la rejilla (columnas, margen y medianil) y la escala tipografica, para que lo que se coloque a mano despues use las mismas guias que `pbi_compose_page`. Escribe en el informe (PBIR): conviene tener el proyecto CERRADO en Power BI Desktop.

Materializa el spec como una pagina PBIR, en UNA transaccion. Cuatro desenlaces explicitos: `create` (no existe), `update` (existe y el spec cambia algo), `no_change` (ya coincide) y `conflict` (el nombre no identifica una sola pagina). `page`: id o nombre visible de la pagina a actualizar. Si se omite, se usa el nombre del spec. Al actualizar se CONSERVAN el id de la pagina y el de cada visual que siga representando lo mismo. `sync_mode`: `merge` (por defecto) anade y actualiza pero no borra lo que el spec no menciona; `replace` ademas elimina los visuales ausentes. El defecto es conservador para que un spec parcial no pueda vaciar una pagina por omision. `interactions`: que le hace un visual a otro al seleccionar en el. Cada visual del spec se puede senalar por su POSICION en `visuals` (0, 1, 2...), por el `id` que se le ponga en el spec, o por su titulo; no hace falta conocer los ids finales, que se generan aqui. Tipos: `Default`, `DataFilter`, `HighlightFilter`, `NoFilter` (tambien valen `filter`, `highlight` y `none`). `dry_run=true` devuelve un plan con `plan_token` y no escribe nada; aplicalo despues con pbi_apply_plan.

Aplica un plan calculado con pbi_plan_change o con un dry_run. Verifica que el proyecto siga en el estado sobre el que se planifico; si cambio, rechaza el plan en vez de aplicar algo distinto de lo aprobado. `expected_operation` es opcional: si lo indicas, el plan solo se aplica si fue generado para esa operacion (`plan_operation_mismatch` si no). **Exige `confirm=true`.** Hasta 2.0.0 el default era `True`, o sea que omitir el parametro APLICABA: un gate que viene abierto no es un gate, y ademas rompia la simetria con las otras ocho tools con `confirm`, que es justo la inconsistencia que hace que un agente generalice mal.

Aplica un tema de colores al informe .pbip activo. Escribe el JSON del tema en StaticResources/RegisteredResources y lo declara en report.json (themeCollection + resourcePackages). Sin las tres cosas Power BI Desktop lo ignora en silencio. `preset`: ver pbi_list_themes. `data_colors`: sustituye la paleta de series por la tuya (#RRGGBB); ojo, entonces el orden deja de estar verificado contra daltonismo. `name`: nombre visible del tema. `theme_json`: un tema COMPLETO tuyo (el objeto JSON), que se escribe tal cual — para tipografia corporativa o formatos que los presets no cubren, sin tener que sobrescribir el archivo a mano despues. Cuando lo pasas, `preset` no se usa; `data_colors` y `fonts` se aplican encima. `fonts`: {'title'|'body'|'callout': 'Familia'} fija las fuentes via textClasses, sobre el preset o sobre tu theme_json. `patch`: cambios PARCIALES sobre el tema que el informe YA tiene, sin reenviar el tema completo (p.ej. {"visualStyles": {...}} para retocar un estilo). Los dicts se fusionan en profundidad; las listas se reemplazan enteras. Con `patch`, el resto de parametros no se usa y hace falta que el informe ya tenga un tema propio. Si el informe ya tenia un tema con contenido DISTINTO (p.ej. editado a mano), se reemplaza avisandolo en `warnings`; la version anterior queda recuperable en el backup de la transaccion. Requiere el proyecto CERRADO en Power BI Desktop.

Reorganiza los visuales de una pagina. `layout`: grid | dashboard | executive_summary | custom. `visual_ids`: subconjunto opcional (por defecto todos). `custom`: mapa visual_id -> {x,y,width,height} para layout 'custom'.

Audita el modelo semantico con reglas de identificador estable. Cada hallazgo trae `rule`, `severity`, `object`, `evidence`, `recommendation` y `auto_fix_available`. Ninguna heuristica se presenta como certeza: la evidencia acompana siempre al hallazgo. `rules`: subconjunto de reglas (ver pbi_list_audit_rules). `min_severity`: info | warning | error.

Auditoria integral: modelo semantico + informe + layout. Devuelve puntaje global y por dominio, resumen ejecutivo, hallazgos priorizados con evidencia y recomendacion, y que reglas tienen correccion automatica. `formats`: ['markdown','html'] escribe tambien esos informes en outputs/ y devuelve sus rutas. `rules` y `min_severity` acotan. `compact=true` devuelve la MISMA auditoria sin repetir texto: cada hallazgo lleva un `finding_id`, `priority` pasa a ser la lista de esos identificadores en orden en vez de copias completas, y `groups` agrupa las repeticiones por regla con su recuento y una muestra. Los puntajes y recuentos por dominio no cambian. Los informes de `formats` se escriben siempre completos.

Audita solo el informe PBIR (sin las reglas del modelo semantico). Cubre paginas vacias, visuales sin titulo, campos rotos, duplicados, tamanos de lienzo inconsistentes y la geometria de cada pagina.

Crea un backup con timestamp del proyecto .pbip activo. `mode`: folder | zip. `scope`: report | model | both. Devuelve la ruta.

Construye un dashboard completo desde un objetivo, no desde primitivas. Analiza el modelo, compone el spec segun el preset, calcula el layout, genera preview, aplica en una transaccion y verifica el resultado. `dry_run=true` (por defecto) se detiene tras el preview.

Pagina EVM (Earned Value Management). Espera medidas del tipo PV, EV, AC, CPI y SPI; si no las reconoce, lo avisa en vez de generar una pagina que no significa nada.

Pagina de resumen ejecutivo: fila de KPIs y grafico protagonista.

Que puede hacerse AHORA MISMO, y que no, con el motivo. Un agente deberia consultarla antes de planificar: dice si la capa en vivo esta disponible, si se puede escribir en el .pbip, y que capacidades dependen de la version del motor.

Valida contra el contrato del puerto: un archivo entrante o el modelo. Con `source_path` (+ `dataset`): el export de Revit/Navisworks/Project ANTES de cargarlo — columnas que faltan, tipos incompatibles, llave ausente. Chequeo ESTRUCTURAL y honesto: unicidad y huerfanas de la llave exigen los datos completos, y eso es pbi_diagnose_data con la tabla ya cargada; la respuesta lo dice en `not_checked`. Sin `source_path`: el MODELO activo contra el contrato entero, y el circulo que cierra todo: `suggested_critical_fields` — las llaves del puerto listas para pbi_define_brief, de modo que el diagnostico las trate como criticas del dueño sin teclearlas dos veces.

Cierra la instancia de Power BI Desktop que sirve ESE proyecto. Es la salida que faltaba del ciclo editar-abrir-mirar-editar: escribir el TMDL exige Desktop cerrado, y no habia forma de cerrarlo desde aqui -tocaba matar el proceso a mano en PowerShell-. Cierra SOLO la instancia con ese archivo abierto, verificando la identidad del proceso (nombre + hora de arranque, nunca el PID a secas). Al final re-comprueba que el archivo ya no este abierto y lo dice en `verified_closed`. DESTRUCTIVA: los cambios SIN GUARDAR de esa ventana se pierden -y en un .pbip eso incluye los datos refrescados de la sesion-. Por eso exige `confirm=true`. Si el archivo no estaba abierto, no hace nada y lo dice (`was_open: false`). `path` (o `pbip_path` / `project_path`) se puede omitir: se cierra el proyecto activo, que es el que el servidor ya conoce. **Tras `pbi_export_pbix(leave_open=true)`** la ventana queda sobre el archivo exportado y ya no responde a la ruta del .pbip original. Pasa `desktop_pid` y `desktop_started` tal cual los devuelve `desktop_session` de la exportacion: se cierra exactamente esa instancia, verificando nombre del proceso y hora de arranque (nunca el PID a secas, que Windows recicla). Con `path` ademas se exige que la ventana no este sirviendo demostrablemente otro documento.

Que usa una columna: medidas, columnas calculadas, relaciones y jerarquias. Util antes de ocultar o eliminar una columna: dice si algo se rompe.

Compara el modelo EN VIVO con el TMDL del disco. Util para saber si hay cambios en memoria sin guardar: lista tablas y medidas que solo estan en un lado, y medidas cuyo DAX difiere.

Compone una pagina entera sobre la rejilla del sistema de diseno. Se describe la INTENCION y el servidor decide la geometria: - `title` / `subtitle`: banda de cabecera, con el tamano y el color del sistema y la altura minima que el texto necesita para no cortarse. - `kpis`: lista de campos (`"[Medida]"` o `{"field":..., "title":...}`). Se reparten la fila entera sin dejar huecos. - `hero`: el grafico protagonista. `{"type":"lineChart", "category":"T[C]", "values":["[M]"], "title":...}`. - `supports`: los que van apilados a su derecha, mismo formato. - `detail`: tabla al pie. `{"values": [...], "title": ...}`. La composicion es siempre la misma de arriba abajo, a proposito: la coherencia entre paginas sale de que ninguna pueda inventarse su propio orden. Si algo no cabe se dice con la cuenta hecha, en vez de encogerlo hasta que no se lea. El COLOR del texto sale del tema que el informe tiene puesto, no del sistema: un informe solo admite un tema, y escribir el color del sistema pintaba el titulo casi invisible en cuanto los dos no coincidian. La geometria si es de la pagina. Si no cuadran se avisa. `dry_run=true` devuelve el spec con todas las posiciones y no escribe. Aplica el mismo camino que `pbi_apply_page_spec`, asi que pasa por la misma validacion y la misma transaccion.

Convierte uno o varios .pbix en proyectos .pbip (PBIR + TMDL). El informe sale del propio archivo: si el .pbix ya guarda PBIR se copia tal cual, y si trae el formato heredado se traduce pagina a pagina. El modelo NO se puede leer del archivo (es un backup comprimido del motor), asi que se ABRE EL .pbix EN POWER BI DESKTOP y se serializa a TMDL desde ahi. Cuenta con eso: cada archivo tarda lo que tarde Desktop en cargarlo. Si el informe ya esta abierto se reutiliza esa sesion; si lo abre esta tool, lo cierra al terminar (`close_desktop`). El .pbix original nunca se modifica. `path`: un .pbix o una CARPETA (`recursive` incluye subcarpetas). `out_dir`: carpeta donde crear el proyecto; se crea una subcarpeta por informe. Los dos son obligatorios y esos son sus nombres: `pbix_path` y `output_dir` NO existen como alias, porque un parametro obligatorio del contrato congelado no se puede sustituir por otro nombre. `include_model=false` genera solo la mitad del informe, sin tocar Desktop. `dataset_connection_string` es obligatorio para informes con conexion en vivo (los que no llevan modelo propio). Devuelve, por archivo, que se escribio y —lo importante— los avisos y lo que se quedo por el camino (`dropped`), como los marcadores.

Copia el formato de un visual a otros DEL MISMO TIPO. Se copia el formato pero no el texto del titulo, que es contenido. Copiar entre tipos distintos se rechaza: la estructura de formato no es intercambiable y Power BI podria rechazar el informe.

Crea un marcador: un estado del informe al que volver con un boton. Escribe el archivo del marcador Y lo mete en el indice: sin el indice Power BI no lo muestra aunque el archivo exista. `page`: id o titulo de la pagina que activara. `filters`: filtros a guardar, con la misma forma que en un page spec. `target_visuals` limita a que visuales afecta. Devuelve `usage`, listo para pasarselo a un boton con action='bookmark'.

Crea una columna calculada (DAX) en una tabla del modelo .pbip. `data_type`: string | int64 | double | decimal | boolean | dateTime. `summarize_by`: como se agrega por defecto; 'none' para clasificaciones y textos, que es lo que casi siempre se quiere. Escribe en TMDL: requiere el proyecto CERRADO en Power BI Desktop.

Crea una tabla calculada (DAX) en el modelo .pbip. Resuelve el caso tipico de tener diez metricas guardadas en diez COLUMNAS en vez de en filas: con una tabla calculada que las dinamice se obtiene una matriz de verdad, en lugar de escribir una medida por columna. TMDL exige declarar las columnas y no se pueden adivinar leyendo el DAX: si no pasas `columns`, se deducen EJECUTANDO la expresion contra el modelo abierto en Power BI Desktop y leyendo el esquema que devuelve el motor. Para eso hace falta el modelo abierto Y seleccionado. Escribe en TMDL: requiere el proyecto CERRADO en Power BI Desktop.

Crea una jerarquia sobre columnas de la misma tabla. `levels`: nombres de columna de MAYOR a MENOR granularidad (p.ej. ['Anio','Mes','Dia']). El orden es el de profundizacion y se respeta tal cual: no se ordena ni se deduplica porque es informacion. Escribe en TMDL: requiere el proyecto CERRADO en Power BI Desktop.

Crea un visual "HTML Content" que renderiza el HTML/SVG devuelto por una medida. `html_measure`: medida cuyo resultado es HTML (p.ej. "[HTML Panel EVM]"). Registra el custom visual en el informe si aun no esta. La medida se crea aparte con pbi_create_measure (el HTML se arma en DAX, tipicamente con VARs y CONCATENATEX sobre los datos del modelo).

Crea (o reemplaza con overwrite=true) una medida DAX. Valida que la tabla exista y que la medida no exista salvo overwrite. `data_category`: opcional, p.ej. "ImageUrl" para medidas que devuelven un data-URI SVG (Power BI las renderiza como imagen en tablas/matrices). Devuelve el diff antes/despues. mode='both' esta temporalmente deshabilitado bajo la politica estricta: 'live' necesita Power BI Desktop abierto y 'pbip' lo necesita cerrado, asi que una sola llamada aplicaria solo uno de los dos destinos. Elige 'live' o 'pbip', o usa 'auto' y se mira el estado para elegir. Si estas construyendo desde cero, 'auto' o 'pbip': el defecto es 'live' y exige Desktop abierto.

Crea una hoja (pagina) PBIR completa a partir de un spec. `spec`: {page_name, canvas?, layout?(grid|dashboard|executive_summary), visuals:[{type,title,fields:{rol:refs},position?}]}. Clona visuales existentes del mismo tipo como plantilla. Hace backup. Omite 'position' en un visual para que se auto-acomode con 'layout'.

Crea un proyecto .pbip vacio pero valido, y lo deja activo. Por defecto escribe out_dir/name/name.pbip. Con subfolder=false (o si out_dir ya termina en .pbip) escribe out_dir/name.pbip con sus carpetas al lado, como Desktop, sin reemplazar nada que ya exista. Es el punto de partida para armar un tablero solo con rutas de archivos: crear el proyecto, cargarle los datos con pbi_add_table_from_file y componer las paginas, sin abrir Power BI Desktop hasta el final. Escribe el minimo que Power BI acepta —informe y modelo semantico apuntandose entre si— con la referencia en ruta RELATIVA: una absoluta ataria el proyecto a esta maquina. Incluye una pagina, porque un informe sin ninguna no abre. No declara `sourceQueryCulture` a proposito: la cultura se fija en cada consulta, que es lo unico que no obliga a suponer como escribe los decimales cada origen.

Crea una relacion entre dos columnas del modelo .pbip. Por defecto muchos-a-uno con filtro en un sentido: es lo que crea Power BI y lo unico que no introduce ambiguedad. `cross_filtering` 'bothDirections' resuelve casos concretos y complica el modelo entero, asi que conviene justificarlo. Escribe en TMDL: requiere el proyecto CERRADO en Power BI Desktop.

Crea un visual PBIR en una pagina. `visual_type` acepta: actionButton, areaChart, barChart, button, card, cardVisual, clusteredBarChart, clusteredColumnChart, columnChart, donut, donutChart, funnel, gauge, htmlContent, htmlContent443BE3AD55E043BF878BED274D3A6855, image, kpi, lineChart, matrix, multiRowCard, navigation, pageNavigator, pieChart, pivotTable, rectangle, ribbonChart, scatterChart, shape, slicer, table, tableEx, text, textbox, treemap, waterfall y waterfallChart. Para visuales con datos, valida antes de escribir los roles obligatorios, la cardinalidad maxima de cada rol y el tipo de campo admitido: dimension (`Grouping`), medida (`Measure`) o cualquiera de ambos (`GroupingOrMeasure`). Los elementos decorativos (texto, forma, imagen, navegador y boton) rechazan `fields` porque no llevan consulta. `fields`: rol -> campos, p.ej. {"category":"Tabla[Col]", "values":["[Medida]"], "legend":"Tabla[Col]"}. El rol se reconoce escrito como sea: el logico (`values`), el nombre que usa PBIR y que devuelve `pbi_list_visuals` (`Values`, `Y`, `Category`, `Data`) o un sinonimo (`measure`, `axis`). Cada campo puede ser `"Tabla[Campo]"` o el objeto que devuelve `pbi_list_visuals`, para poder leer una pagina y rehacerla sin traducir nada. Un rol que ese tipo de visual no tiene se RECHAZA con la lista de los validos. Antes se descartaba en silencio y el visual salia sin datos. `options`: formato adicional. Llaves reconocidas (una clave no reconocida se ignora, no se rechaza; ver `pbi_get_visual` para comprobar que quedo escrito): - `background_color`, `border_color` ('#RRGGBB'), `background_transparency` (0-100), `border_radius` (px): el marco de CUALQUIER visual (panel General > Efectos de Desktop). Sin `background_color`/`border_color` no se toca el marco. - `card`/`cardVisual`: `show_category_label`, `value_font_size`, `bold_value`, `value_color`. - `shape`: `fill`, `transparency`, `text`, `font_size`, `text_color`. - `textbox`: `text`, `font_size`…

Escribe el BRIEF DE INTENCION del tablero: para que existe. Es la pieza que gobierna a las demas: la propuesta de paginas, el sistema de diseño y las auditorias leen este artefacto para servir a un proposito en vez de deducirlo todo del modelo. **Las respuestas son del HUMANO, no tuyas.** Antes de llamar, pregunta en conversacion: ¿para que quieres este tablero? ¿quien lo va a mirar? ¿que decisiones debe sostener? ¿como se va a ver (sala, escritorio, PDF, movil)? Un brief inventado por el agente es peor que ninguno: fija en un archivo con autoridad lo que nadie dijo. `delivery`: pantalla_sala | escritorio | lectura_pdf | movil — decide el sistema de diseño recomendado (legibilidad fisica, no estetica). `critical_fields`: [{field, why, min?, max?}] — que campos son criticos y sus umbrales; los usara el diagnostico de datos. Se guarda como `pbi-brief.json` JUNTO al .pbip (fuera de .Report/ .SemanticModel, que Desktop reescribe al guardar): versionado con el proyecto y editable en cualquier momento. Reescribirlo es normal: los tableros cambian de proposito.

Escribe el CONTRATO del puerto del ecosistema (pbi-port-contract.json). El puerto NO es un bus de APIs entre Revit/Navisworks/Project —eso es fragil sin arreglo—: es un contrato de datos. Cada herramienta EMITE un dataset normalizado con una llave compartida, y este MCP lo valida y lo consume. `datasets`: [{name, key, columns: [{name, type, required?}], emitted_by?, description?}]. La llave es obligatoria: es lo que permite cruzar los datasets entre si (p.ej. HRZ_COD_PRES entre el modelo BIM, el presupuesto y el cronograma). Vive versionado junto al .pbip, como el brief. Se valida con pbi_check_contract: archivos entrantes antes de cargar, y el modelo activo despues.

Borra un marcador y lo quita del indice. Destructiva: confirm=true.

Elimina una medida. Operacion destructiva: requiere confirm=true. mode='both' esta temporalmente deshabilitado bajo la politica estricta: 'live' necesita Power BI Desktop abierto y 'pbip' lo necesita cerrado, asi que una sola llamada aplicaria solo uno de los dos destinos. Elige 'live' o 'pbip', o usa 'auto' y se mira el estado para elegir. Si estas construyendo desde cero, 'auto' o 'pbip': el defecto es 'live' y exige Desktop abierto.

Elimina una pagina y actualiza el orden y la pagina activa. Destructiva: requiere confirm=true. Se niega a borrar la ultima pagina del informe, porque un informe sin paginas no abre.

Elimina un visual. Operacion destructiva: requiere confirm=true. Devuelve la definicion previa, y el journal permite restaurarla.

Diagnostica la geometria de una pagina (o de todas). Solo lectura. Detecta solapamientos, visuales fuera del lienzo, tamanos demasiado pequenos, margenes, separaciones inconsistentes, orden Z duplicado o ausente, paginas vacias y paginas saturadas. Cada hallazgo trae su evidencia geometrica.

Diagnostico de CONTENIDO contra el modelo VIVO: lo que rompe tableros y ningun metadato ve. Cuatro chequeos deterministas, cada uno con la consulta DAX que lo demuestra y muestras de los valores culpables: - **claves_huerfanas**: filas del lado muchos cuya clave no existe en el lado uno (caen al Blank de la relacion; los totales cuadran de menos sin error). Incluye claves EN BLANCO. - **grano_duplicado**: el lado uno con claves repetidas (todo se multiplica al cruzar). - **calendario_con_huecos**: dias faltantes en la tabla de fechas. - **umbral_del_brief_violado** y **campo_critico_inexistente**: los `critical_fields` del brief contra los datos reales. La severidad la decide el dueño: lo que declaro critico sale como `error`. No hay heuristicas "inteligentes" de outliers ni escalas: lo generico es determinista y lo subjetivo viene del brief. Un chequeo que no se pudo correr sale en `skipped` con su motivo — "no se comprobo" y "esta bien" no son lo mismo. Requiere el modelo ABIERTO en Desktop (consulta datos, no archivos). `tables` acota a las relaciones que tocan esas tablas.

Compara el spec con una pagina existente antes de aplicarlo. Dice que visuales se anadirian, cuales sobrarian y cuantos quedan igual. Si la pagina no existe, informa que se creara.

Activa/desactiva 'Auto fecha y hora' (solo modo pbip). Desactivarlo aligera el modelo: al reabrir el .pbip, Power BI elimina las tablas de fecha automaticas (LocalDateTable_*). Requiere proyecto .pbip activo.

Reparte visuales con separacion uniforme. `axis`: horizontal|vertical. Necesita al menos tres visuales: con dos, la separacion ya es la que hay.

Genera documentacion completa del modelo en Markdown. Incluye resumen, tablas, columnas, medidas, relaciones, jerarquias, roles (RLS) y advertencias de calidad. Guarda el archivo en outputs/.

Genera documentacion Markdown del layout del informe (paginas y visuales).