Perfila los VALORES del modelo abierto y devuelve lo que no cuadra.

Complementa a pbi_audit_model, que revisa la estructura: un porcentaje que vale -800 no es un defecto del modelo sino de los datos, y solo se ve consultandolos.

Detecta porcentajes fuera de 0-100, columnas vacias, columnas de un solo valor y columnas mayormente vacias. Cada hallazgo trae la consulta que lo demuestra y la consecuencia concreta sobre el tablero.

Solo lectura. tables acota el trabajo; max_columns evita que un modelo grande agote el timeout y devuelva un perfil a medias.

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.

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.

Planifica correcciones para reglas CONCRETAS. No escribe nada.

No existe "arreglar todo": hay que indicar rules explicitamente. objects acota mas todavia (ids de visual o de pagina). Devuelve las acciones exactas que se aplicarian, con su motivo.

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.

Reglas que tienen correccion automatica, y en que consiste cada una.

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.

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.

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.

Radiografia de un .pbix SIN convertirlo ni abrir Power BI Desktop.

Dice en que formato esta el informe ('pbir' si ya trae el formato mejorado y solo hay que copiarlo, 'layout' si es el heredado y hay que traducirlo), si lleva modelo de datos propio o es un informe con conexion en vivo, y cuantas paginas, recursos y visuales personalizados tiene. Sirve para saber que esperar antes de lanzar la conversion.

path: ruta al archivo .pbix.

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. 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.

Lista los .pbix de una carpeta y como se convertiria cada uno.

Recorre los archivos sin abrirlos en Desktop y dice, por cada uno, si el informe se copiaria (ya esta en PBIR) o habria que traducirlo, y si hace falta Desktop para sacar el modelo. Es la vista previa del lote.

path: carpeta (o un .pbix suelto). recursive: incluir subcarpetas.

Lista los modelos de Power BI Desktop abiertos localmente.

Detecta el motor de Analysis Services (localhost:) de cada informe abierto y devuelve puerto, connection string, catalogo y nº de tablas.

Selecciona el modelo local activo para futuras operaciones.

Si hay un solo modelo abierto no hace falta indicar nada. Si hay varios, pasa port o connection_string TAL CUAL lo devuelve pbi_list_desktop_models ("Data Source=localhost:56057"): lo que sale de esa tool entra en esta sin tener que extraer el puerto a mano.

Abre un .pbip o .pbix en Power BI Desktop y espera a que sirva el modelo.

Cierra el ciclo de trabajo: despues de editar un proyecto, esto permite comprobar que ABRE de verdad y consultar sus medidas, sin pedirle al usuario que lo haga a mano. Un TMDL que no carga se manifiesta aqui.

Espera a que el motor local aparezca y deje de crecer, identifica cual de las instancias corresponde a este archivo (el puerto es dinamico) y, con select=true, lo deja como modelo activo.

Si el archivo ya estaba abierto se reutiliza esa sesion y no se toca nada (reuse_open). Nunca cierra una ventana del usuario.

path (o pbip_path, como lo llama pbi_session_info) se puede omitir: entonces se abre el proyecto .pbip activo.

Ojo: un .pbip recien abierto trae el modelo SIN DATOS. Refresca despues con pbi_refresh_model si vas a comprobar valores.

Abre un .pbip/.pbix y captura su ventana real sin depender del foco.

Es la comprobacion visual automatizable que complementa al validador PBIR: espera el modelo, identifica la ventana por PID y hora de inicio, y la renderiza con PrintWindow directamente a outputs/desktop_captures. La captura no activa ni trae Desktop al frente, por lo que no puede fotografiar por accidente otra ventana que tape el informe.

path (o pbip_path, el mismo nombre que devuelve pbi_session_info) se puede omitir: entonces se usa el proyecto .pbip activo.

refresh=true es lo que hace que la captura signifique algo en un .pbip: ese formato guarda la definicion, no los datos, asi que recien abierto el modelo viene VACIO y las tablas y matrices salen en blanco aunque el informe este perfecto. Con refresh se abre, se refresca, se espera a que la ventana deje de repintar y se captura. Ese es tambien el camino para fotografiar OTRA pagina con datos: page exige abrir el proyecto, y al abrirlo hay que volver a refrescar.

Pase lo que pase, la respuesta lleva data_loaded: si es false, la captura no es representativa del informe, es la foto de un modelo sin datos. Si no se pudo comprobar, se dice; no se afirma ninguna de las dos.

page (solo .pbip): captura ESA pagina (id o nombre visible), no la que quedo activa. fit_to_page (solo .pbip, activado por defecto): fuerza la vista "Ajustar a la pagina" para que salga el lienzo COMPLETO y no el tercio superior al zoom guardado. Ambos ajustan la vista antes de abrir y la restauran byte a byte al terminar; exigen que el proyecto no este ya abierto (con sesion reutilizada no se pueden aplicar: page falla y fit_to_page degrada a un aviso).

Si la tool tuvo que abrir Desktop, lo cierra al terminar (tambien si la captura falla) y devuelve la seleccion de modelo a como estaba. Si el informe ya estaba abierto, reutiliza esa sesion y nunca cierra la ventana del usuario.

Ejecuta una consulta DAX de SOLO LECTURA contra el modelo activo.

Solo se admiten formas reconocidas: EVALUATE, DEFINE...EVALUATE y DMVs de $SYSTEM. Cualquier otra cosa se rechaza (politica fail-closed).

max_rows: limite de filas. max_bytes: tope de tamano del resultado, para no devolver megas al cliente. timeout_seconds: timeout del comando. export=true vuelca el resultado completo a outputs/ y devuelve la ruta.

Devuelve columnas, tipos observados, filas, estadisticas de ejecucion y si se trunco (y por que: filas o tamano). Los errores DAX del motor se devuelven tal cual.

Valida la conexion al modelo activo con una consulta trivial.

Valida DAX de medidas SIN modificar el modelo (dry-run con DEFINE MEASURE).

Ideal para probar medidas ANTES de crearlas con pbi_create_measure. measures: lista de {"name","dax","table"(opcional)}. Las medidas pueden referenciarse entre si. Devuelve por cada una: valid, value (muestra) y error.

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) se puede omitir: se cierra el proyecto activo, que es el que el servidor ya conoce.

Por donde empezar. Mira el estado real y dice los siguientes pasos.

Ciento treinta y dos tools con buen nombre siguen siendo ciento treinta y dos tools. Esta responde «¿y ahora que?» con tres o cuatro pasos concretos, cada uno con el nombre exacto de la tool y por que toca ahora: si hay proyecto activo, si tiene modelo o solo informe, si esta vacio, y si Power BI Desktop lo tiene abierto —que impide escribir el TMDL—.

Devuelve tambien common_tasks: tareas frecuentes y la secuencia de tools que las resuelve.

No escribe nada. Empieza por aqui cuando no sepas que sigue.

Sistemas de diseno disponibles: para que sirve cada uno y que trae.

Un sistema decide a la vez el tema (color y tipografia, con paletas ya verificadas contra daltonismo), el tamano del lienzo, la rejilla sobre la que se coloca todo y la escala de texto. Son la misma decision: un tablero de sala se lee a cuatro metros y uno en PDF a cuarenta centimetros, y eso no es el mismo diseno con otro color.

Eligelo ANTES de la primera pagina; cambiarlo despues obliga a recolocarlo todo.

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.

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.

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.

Lee el brief de intencion del proyecto activo.

Devuelve defined: false si no existe —con las preguntas que hay que hacerle al usuario para definirlo—, o el brief completo y el sistema de diseño que recomienda. Consultalo ANTES de proponer paginas o elegir sistema: es la diferencia entre servir al proposito del tablero y deducirlo todo del modelo.

Reescala las paginas ya escritas al lienzo de otro sistema.

El camino de vuelta que faltaba. Aplicar un sistema cambia el tema del informe, pero NO reescribe lo ya compuesto: las paginas se quedan con el lienzo anterior —visuales fuera de limites, basura invisible que si viaja al render— y con los colores que se cocieron al componerlas: un titulo compuesto en tema oscuro queda BLANCO SOBRE BLANCO al pasar a claro, sin que falle nada.

Esto hace las dos cosas: reescala cada visual proporcionalmente al lienzo nuevo (acotandolo si no cabe) y recalcula el color de texto de los elementos decorativos con el tema del sistema destino.

No recompone: no se puede saber que intencion tenia cada visual, y adivinarla seria peor. Si una pagina necesita otra estructura, recomponla con pbi_compose_page. Esto la deja utilizable, no optima.

pages: subconjunto opcional (id o nombre visible); por defecto todas. dry_run=true (por defecto) devuelve el plan visual por visual, con cuales estaban ya fuera de limites, sin escribir nada.

Escribe en el informe (PBIR): requiere el proyecto CERRADO en Desktop.

Lista tablas con columnas, tipos, visibilidad y conteos.

source: 'live' (modelo abierto, por defecto) o 'pbip' (archivos TMDL).

Empieza por detail='summary'. Devuelve nombre, visibilidad y recuentos, sin la lista de columnas. Con detail='full' (por defecto, por compatibilidad) un modelo de siete tablas ocupa ~28.000 caracteres y uno corporativo puede llenar buena parte de la ventana de contexto en una sola llamada.

tables: acota a esas tablas por nombre. Es lo que se usa despues del resumen para pedir el detalle solo de las que interesan. Un nombre que no existe falla y devuelve los disponibles, en vez de una lista vacia.

Lista medidas con tabla, expresion DAX, formato, descripcion y carpeta.

Empieza por detail='summary'. Omite la expresion DAX, que es el grueso del peso y rara vez hace falta para orientarse; para leer el DAX de una medida concreta usa pbi_get_object, y para buscar dentro del DAX, pbi_search_model. detail='full' sigue siendo el valor por defecto por compatibilidad.

tables: acota a las medidas de esas tablas.

Lista relaciones: tablas/columnas, cardinalidad, filtro cruzado y estado.

Detecta problemas tipicos del modelo (calidad).

Revisa medidas sin carpeta, DAX muy largo, relaciones bidireccionales/ inactivas, columnas calculadas, IDs visibles, ausencia de calendario, etc.

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/.

Exporta el CONTENIDO del informe: los datos que muestra el tablero.

A diferencia de pbi_export_excel y pbi_generate_pdf_report, que documentan el proyecto, esto exporta lo que el cliente ve. select admite tres formas, combinables:

• pages: ["Matriz de Riesgos"] -> la tabla que hay detras de CADA visual de esas paginas (por nombre visible o id interno).

• visuals: ["15b0fc11e628..."] -> solo esos visuales.

• queries: [{name, rows:["Tabla[Columna]"], values:["Medida"], filters:[{field, values, exclude?}], top_n?}] -> lo que el cliente declare, sin referirse a ningun visual.

Cada consulta se reconstruye a partir de los campos del visual, se ejecuta en SOLO LECTURA contra el modelo en vivo y sale como una hoja de Excel (format: xlsx|pdf|both).

Necesita el modelo en vivo: los datos solo existen en el motor, no en el .pbip. Con auto_open abre el informe en Desktop si hace falta, y se NIEGA a exportar si el modelo esta abierto pero sin procesar, en vez de publicar un archivo en blanco. Con dry_run devuelve el DAX que ejecutaria sin tocar el motor ni escribir nada.

Cada hoja declara con que filtros se saco y, sobre todo, cuales no se pudieron aplicar. Los visuales sin consulta tabular -textos, imagenes, formas- se listan aparte con el motivo.

Exporta la informacion disponible a un libro Excel verificado.

Crea hojas para resumen, tablas, columnas, medidas, relaciones y, si hay PBIP activo, paginas, visuales y auditoria. source admite auto|live|pbip. Si se proporciona query, ejecuta DAX de solo lectura contra Desktop y agrega Datos_DAX, declarando cualquier truncamiento.

El archivo se escribe en outputs/excel/, nunca dentro del PBIP. No sobrescribe nombres existentes, neutraliza formulas inyectadas y vuelve a abrir el XLSX antes de informar exito.

Genera un PDF ejecutivo, tecnico o de auditoria con capturas.

Compone informacion existente del modelo, paginas, visuales y auditoria. capture_paths acepta hasta 20 PNG/JPEG, por ejemplo las rutas devueltas por pbi_validate_desktop_render. No inventa graficas si no hay captura.

El PDF se reabre con pypdf y, cuando Poppler esta disponible, su primera pagina se renderiza a PNG como prueba visual. Se guarda en outputs/pdf/.

Conecta con SharePoint Online y lista una carpeta mediante Graph.

site_url es la URL HTTPS del sitio; library es el nombre o id de la biblioteca documental; folder_path usa /. Sigue la paginacion de Graph y puede recorrer subcarpetas con un limite total explicito.

Autenticacion app-only: las credenciales SOLO se leen de las variables HORIZUN_PBI_MCP_SHAREPOINT_TENANT_ID, _CLIENT_ID y _CLIENT_SECRET. Nunca se aceptan secretos como parametros ni se devuelven tokens.

Descarga una carpeta de SharePoint a outputs/ de forma todo-o-nada.

Primero inventaria el lote y valida max_files, max_total_mb y el filtro opcional extensions (por ejemplo ['xlsx','csv']). Luego usa URLs temporales emitidas por Graph, verifica tamano y SHA-256 y publica el directorio completo bajo outputs/sharepoint/. Un fallo elimina el staging y no deja una carpeta final parcial.

Es una descarga de solo lectura remota: no sube, mueve ni elimina nada en SharePoint.

Resumen compacto del modelo, pensado para leerlo de un vistazo.

Conteos, tablas con su tamano, medidas por tabla, columnas calculadas, tablas desconectadas, relaciones bidireccionales y referencias rotas. Es la primera tool que conviene llamar para orientarse en un modelo. source: 'live' (Desktop abierto) o 'pbip' (archivos TMDL).

Busca objetos del modelo por nombre (y en el DAX de las medidas).

term: texto a buscar, sin distinguir mayusculas. kinds: filtra por tipo — table, column, measure, hierarchy, role. Para las medidas indica si coincidio el nombre o la expresion.

Devuelve un objeto del modelo con todo su detalle.

kind: table | column | measure. Para una columna usa 'Tabla[Columna]'. En una medida incluye ademas las referencias que aparecen en su DAX.

De que depende una medida y quien depende de ella.

Devuelve dependencias directas (medidas, columnas y referencias ROTAS), el cierre transitivo sobre medidas hasta depth, y la lista de medidas que la usan. Analisis lexico: detecta referencias escritas, no las construidas dinamicamente.

Que usa una columna: medidas, columnas calculadas, relaciones y jerarquias.

Util antes de ocultar o eliminar una columna: dice si algo se rompe.

Lista las jerarquias del modelo con sus niveles y columnas.

Lista los roles de seguridad (RLS) y sus filtros por tabla.

Lista las perspectivas del modelo.

Requiere la capa EN VIVO: el lector TMDL de este proyecto no las extrae. Si no hay ninguna, devuelve una lista vacia con la explicacion.

Lista las particiones por tabla (modo de almacenamiento y origen).

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.

Catalogo de reglas de auditoria disponibles, con su dominio y severidad.

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.

Actualiza una medida existente. Lo no especificado se conserva.

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 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.

Renombra una medida actualizando TODO lo que la referencia.

Renombrar a mano rompe el informe en silencio: cualquier visual o medida que apuntara al nombre viejo abre y sale VACIO, sin error. Esta tool compila primero y escribe en UNA transaccion: la cabecera TMDL, las expresiones DAX de otras medidas que usan [old_name], y los visual.json del informe. Devuelve la lista de lo tocado.

Limite honesto: las referencias DAX CALIFICADAS (Tabla[old]) no se reescriben —pueden ser una columna homonima de otra tabla, y adivinar seria corromper—; si quedan, salen en warnings con su ubicacion, igual que las de bookmarks y filtros.

Solo pbip (escribe modelo E informe a la vez: exige Desktop CERRADO). dry_run=true (defecto) devuelve el plan sin escribir.

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.

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 pueda ser encabezado (sin huecos y sin nombres repetidos) y se dice cual se eligio en warnings. skip_rows fuerza cuantas saltar cuando la deteccion no acierta; skip_rows=0 obliga a usar la fila 1 tal cual. Aplica a csv y xlsx.

dry_run=true devuelve el TMDL y la M sin escribir nada. sheet: hoja del libro; si se omite, la primera. Solo aplica a xlsx.

Escribe en TMDL: requiere el proyecto CERRADO en Power BI Desktop.

Cambia el modo de almacenamiento de una tabla: import | directQuery | dual.

Con directQuery el dato se consulta al origen en cada interaccion y desaparece el refresco, pero NO es un interruptor inocuo: la consulta M tiene que ser plegable al origen, las columnas y tablas calculadas dejan de estar disponibles, y cada visual pasa a ser una consulta al servidor.

Devuelve el modo anterior y cuantas particiones cambiaron, para poder deshacerlo sabiendo exactamente que se toco.

Escribe en TMDL: requiere el proyecto CERRADO en Power BI Desktop.

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 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.

Oculta o muestra una columna del modelo (p.ej. ocultar columnas de ID).

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.

Oculta/muestra VARIAS columnas como un solo lote.

columns: lista de {"table": ..., "column": ...}.

Valida todas las entradas antes de escribir: si alguna tabla o columna no existe, no se modifica nada y el error indica el indice. Los archivos TMDL se escriben en una sola transaccion y el modelo en vivo con un solo SaveChanges. count es el numero de entradas SOLICITADAS (incluidos duplicados); results trae una entrada por cada una, en el mismo orden.

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.

Cambia el filtro cruzado de una relacion.

direction: 'single' (una direccion, recomendado) o 'both' (bidireccional). OJO: cambiar a 'single' puede alterar totales que dependian de la bidireccional; verifica el informe despues.

No confundir direction='both' (bidireccional, valido) con mode='both', que 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.

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.

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.

Estado general del servidor: dependencias, DLLs, sesion y proyecto.

Solo lectura. Es lo primero que conviene llamar: dice si la capa EN VIVO esta disponible, si hay un proyecto .pbip abierto y si algo requiere atencion (sesion obsoleta, journals pendientes).

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.

Detalle de la sesion: modelo activo, proyecto activo y su frescura.

Distingue una sesion valida de una obsoleta (stale) o de otra que ocupo el mismo puerto (mismatch).

Lista los journals del proyecto activo.

Un journal pending es el de una operacion que ni se confirmo ni se revirtio (el proceso murio en medio). Contiene los originales. only_pending=false lista tambien los ya cerrados.

Inspecciona un journal y lo compara con el estado ACTUAL del proyecto.

Solo lectura: no restaura nada. Por cada archivo dice si sigue como el original, si hay respaldo disponible y cual fue su desenlace. journal: ruta devuelta por pbi_list_pending_journals.

Restaura los originales guardados en un journal. DESTRUCTIVA.

Sin confirm devuelve la VISTA PREVIA: que archivos se restaurarian, cual es su estado actual y si alguien los cambio despues.

Estados: recoverable, recovered, conflict, incomplete, corrupted. Si un archivo cambio despues de la transaccion, se rechaza con recovery_conflict en vez de pisar ese trabajo; force_conflict lo aplica de todas formas.

Cada archivo se verifica byte a byte tras restaurarlo, y se recrean los directorios padre que hubieran desaparecido.

Aplica la politica de retencion a los backups. DESTRUCTIVA.

Sin confirm devuelve el MANIFIESTO de lo que se eliminaria, sin tocar nada. Solo se borran directorios de journal reconocibles (con su manifest.json) dentro de la carpeta de backups del proyecto activo: nunca un archivo suelto, ni un enlace simbolico, ni una raiz amplia.

Se conserva siempre el journal mas reciente y TODOS los pendientes: un journal pendiente guarda los unicos originales de una transaccion que no llego a cerrarse.

Calcula un PLAN sin aplicar nada, y devuelve un plan_token.

operation: una de las que lista pbi_capabilities en planned_operations. arguments: los mismos que aceptaria la tool.

El plan incluye el diff por archivo y una huella del estado sobre el que se calculo. Si el proyecto cambia despues, pbi_apply_plan lo rechaza.

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.

Mira el modelo y PROPONE varios diseños distintos, con su porque.

A diferencia de pbi_page_building_blocks, que entrega el inventario y deja el diseño en manos de quien pregunta, esto clasifica lo que hay —que columna es un estado, cual una fecha, cuales forman una familia de metricas comparables— y devuelve paginas completas con un spec listo para aplicar.

Devuelve tambien blockers: lo que hay que resolver ANTES de construir (p.ej. un modelo sin medidas, donde todo visual caeria en sumas implicitas), y themes con las paletas disponibles.

Usalo para ofrecer opciones al usuario en vez de decidir por el.

Entrega el material para diseniar una hoja: modelo (tablas/medidas/columnas), catalogo de visuales existentes (reutilizables como plantilla), canvas y paginas.

Usa esto ANTES de proponer una hoja: te dice que campos y tipos de visual hay.

Genera una MAQUETA HTML de una hoja propuesta (sin escribir nada al .pbip).

spec: {page_name, canvas?, layout?, visuals:[{type,title,fields,position?}]}. Devuelve la ruta del HTML (abrelo en el navegador para revisar el diseno).

Exporta una MAQUETA HTML de una pagina EXISTENTE (layout + campos de cada visual).

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'.

Abre un proyecto .pbip y lo marca como proyecto activo.

Detecta carpetas .SemanticModel (TMDL) y .Report (PBIR) y devuelve un resumen con advertencias (p.ej. si el informe no usa PBIR). path: ruta al archivo .pbip o a su carpeta.

Valida a fondo el proyecto .pbip activo (estructura, PBIR, TMDL).

Incluye references: cada Measure/Column que un visual.json o su filterConfig citan, cruzada contra el TMDL real. El esquema PBIR y la sintaxis TMDL pueden pasar limpios por separado con un visual que apunta a una medida borrada -- Desktop lo resuelve en silencio a nada, sin marca visible. Solo corre si el TMDL es valido (comparar contra un modelo que no abre es ruido, no una comprobacion).

Crea un proyecto .pbip vacio pero valido, y lo deja activo.

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.

Comprueba si un modelo TMDL abrira, sin abrir Power BI Desktop.

Dos capas. Un lint estatico que caza las trampas que solo se veian al abrir (una propiedad de tabla colocada despues de sus hijos, un comentario '///' sobre una relacion, una medida que se llama como una columna de su tabla, medidas duplicadas, referencias rotas) y, si estan las DLL, un parseo con el MISMO serializador que usa Power BI.

Cada hallazgo trae rule, severity, el archivo y la linea. Si el parseo no se pudo ejecutar se dice (parse_checked: false) en vez de darlo por bueno.

Hay fallos que NINGUN analisis estatico ve porque dependen de los datos —un blanco en el lado 'uno' de una relacion, un separador decimal mal interpretado—. Salen en limitations: para esos hay que refrescar.

path: carpeta definition del modelo, la carpeta .SemanticModel o el .pbip. Si se omite, el proyecto activo. use_tom=False: solo el lint estatico, sin tocar las DLL.

Crea un backup con timestamp del proyecto .pbip activo.

mode: folder | zip. scope: report | model | both. Devuelve la ruta.

Refresca el modelo LOCAL abierto en Power BI Desktop (no el Service).

type: full | calculate | clear_values (tambien automatic | data_only). tables: lista opcional de tablas a refrescar; si se omite, todo el modelo. Los errores de credenciales/origen se reportan.

timeout_seconds (600 por defecto, 0 lo desactiva): un refresh lanzado por XMLA no puede mostrar el dialogo de credenciales de Desktop, asi que un origen sin credenciales guardadas deja al motor esperando para siempre y no hay ninguna ventana que cerrar. Al agotarse el plazo se pide la cancelacion al motor y se devuelve refresh_timeout enumerando los origenes que REQUIEREN credenciales -no si las tienen: eso Desktop no lo expone- y si la cancelacion se confirmo o el comando pudo quedar corriendo.

Devuelve estado, duracion y rows_by_table: cuantas filas quedaron en cada tabla refrescada. Un refresh puede terminar en 'ok' y haber cargado CERO filas -credenciales que devuelven vacio, un filtro de fecha que no alcanza nada, un origen que cambio de esquema-, asi que las tablas vacias salen ademas en warnings. Si no se pudo contar, se dice; no se inventa el numero.

En un proyecto .pbip los datos NO se guardan: viven en la sesion de Desktop y al reabrir hay que refrescar otra vez. Lo que persiste al guardar es la definicion (TMDL + PBIR).

Exige confirm=true desde 2.0.0. Hasta entonces era la unica tool destructiveHint sin confirmacion junto con pbi_open_and_refresh: un agente que decide por «¿tiene confirm?» no veia nada que preguntar.

Abre el proyecto en Power BI Desktop y lo refresca, en una llamada.

Es la secuencia real de trabajo y siempre eran dos llamadas de unos catorce segundos cada una, porque un .pbip recien abierto trae el modelo SIN DATOS: abrirlo sin refrescar no sirve para comprobar nada.

path y pbip_path son el mismo parametro -el segundo es como lo llama pbi_session_info-, y se pueden omitir los dos: entonces se usa el proyecto .pbip activo.

Devuelve lo mismo que las dos por separado, incluido rows_by_table. Si el archivo ya estaba abierto se reutiliza esa sesion (reuse_open).

Si el refresh falla, la ventana se DEJA ABIERTA: ya cargo bien, y cerrarla borraria justo el contexto que hace falta para ver por que fallo. Sale en desktop_left_open.

Exige confirm=true desde 2.0.0. Abre una aplicacion y refresca: los dos efectos son visibles y el segundo descarta lo que hubiera en memoria sin guardar.

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).

Recursos del informe: declarados, en disco y los que no cuadran.

Un archivo sin declarar no lo encuentra Power BI; una declaracion sin archivo deja el visual vacio. Los dos casos son invisibles al abrir el informe, asi que se listan aparte.

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'.

Marcadores del informe, y los que no cuadran entre indice y disco.

Un marcador que no esta en el indice no se muestra; una entrada del indice sin archivo rompe el panel. Los dos casos son mudos al abrir.

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

Temas de informe disponibles, con su paleta y para que sirve cada uno.

Devuelve, por tema: el escenario de uso, el color de fondo, los colores de serie EN SU ORDEN (el orden es lo que garantiza que dos series contiguas se distingan tambien con daltonismo) y los colores de estado.

Usalo para PROPONER un esquema antes de construir, en vez de decidirlo por el usuario.

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.

Definicion completa y normalizada de un visual.

Devuelve tipo, posicion, orden Z, titulo, campos por rol, medidas y columnas referenciadas, si tiene formato propio, sus filtros, y la definicion cruda por si hace falta inspeccionarla.

Version PBIR observada, tema, custom visuals y tipos clonables.

Solo se pueden crear visuales de tipos ya presentes en el informe: se clona una estructura real en vez de inventarla. Esta tool dice cuales hay disponibles antes de intentarlo.

Duplica un visual conservando campos, formato y filtros.

Solo se regenera el identificador, que debe ser unico. La copia se desplaza offset_x/offset_y para que no quede tapando al original. target_page permite copiarlo a otra pagina.

Elimina un visual. Operacion destructiva: requiere confirm=true.

Devuelve la definicion previa, y el journal permite restaurarla.

Cambia u oculta el titulo de un visual PRESERVANDO su formato.

title: el texto nuevo. show=false: oculta el titulo SIN borrar su texto ni formato (el rodeo de poner texto vacio dejaba la banda del titulo ocupando altura); show=true lo vuelve a mostrar. Se puede pasar solo uno de los dos, o ambos.

Colorea un visual segun el valor de un campo (degradado).

Es lo que convierte una matriz de numeros en un mapa de calor, o unas barras planas en una escala de semaforo.

field: 'Tabla[Campo]' o '[Medida]' de donde sale el VALOR. target_column: que columna del visual se pinta con ese valor; sin ella se pinta la columna del propio field. Debe estar proyectada en el visual (p.ej. pintar 'Resumen[semaforo]' con '[Puntaje promedio]'). target: 'background' o 'font' para tablas y matrices; 'bars' para barras, columnas y puntos. mid_color: si lo indicas, el degradado tiene tres paradas en vez de dos, util cuando hay un punto neutro. min_value/mid_value/max_value: anclas numericas de las paradas (sin ellas, Power BI usa el minimo y maximo observados). null_strategy: asZero | none | specificColor.

Si el visual ya tenia una regla en ese mismo destino, se sustituye: dos degradados sobre la misma propiedad no se suman, se pisan.

Colorea un visual con el color que DEVUELVE una medida.

Es el modo "valor de campo" de Power BI: la medida entrega '#D03B3B' o un nombre de color, y el visual lo aplica tal cual. Es el patron tipico de un semaforo calculado en DAX.

field: '[Medida]' o 'Tabla[Medida]' que devuelve el color. target: 'background' o 'font' (tablas y matrices), 'bars' (barras, columnas y puntos). La matriz de que combinacion funciona en que tipo de visual vive en el servidor y se valida antes de escribir. target_column: columna proyectada a pintar; sin ella se pinta la columna del propio campo.

Fija el orden Z de los visuales de una pagina.

order: ids de MENOR a MAYOR z; el ultimo queda encima. Los visuales que no menciones se colocan por encima, conservando su orden relativo.

Sustituye una referencia de campo dentro de un visual.

old_ref/new_ref: 'Tabla[Campo]' o '[Medida]'. Trabaja sobre las proyecciones existentes; no crea roles nuevos. Falla si el visual no referencia old_ref, en vez de no hacer nada en silencio.

El destino se valida contra el modelo antes de escribir: si no existe, es ambiguo o es de otro tipo (medida donde va una columna), se rechaza con field_not_found en lugar de inventarlo.

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.

Duplica una pagina con todos sus visuales, en una sola transaccion.

Se regeneran los identificadores que deben ser unicos (el de la pagina y el de cada visual) y se conserva todo lo demas.

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.

Cambia el nombre visible de una pagina. El id interno no cambia.

Fija el orden de las paginas del informe.

Acepta ids o nombres visibles. Las paginas que no menciones quedan al final, conservando su orden relativo.

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.

Alinea varios visuales por un borde.

edge: left | right | top | bottom | center_h | center_v. Determinista: la misma entrada produce siempre la misma salida.

Reparte visuales con separacion uniforme. axis: horizontal|vertical.

Necesita al menos tres visuales: con dos, la separacion ya es la que hay.

Corrige lo corregible de una pagina sin reacomodarla entera.

Mete dentro del lienzo lo que se sale, sube al minimo lo demasiado pequeno y respeta los margenes. NO mueve lo que ya esta bien: es una correccion conservadora. dry_run=true devuelve el plan sin escribir.

Presets de pagina disponibles, con los bloques que compone cada uno.

Un preset describe la INTENCION de la pagina (KPIs arriba, grafico protagonista, detalle abajo). Los campos concretos los eliges tu.

Genera un borrador de spec a partir de un preset y unos campos.

preset: executive | financial | sales | operations | evm | detail. measures: medidas para los KPIs y los graficos. category: columna para el eje de los graficos. El resultado es un spec editable: revisalo y pasalo por pbi_validate_page_spec.

Valida un spec: esquema, referencias contra el modelo y geometria.

Los errores traen su JSON path ($.visuals[2].fields.values[0]) para que se puedan corregir sin adivinar. No escribe nada.

Maqueta HTML del spec con las posiciones FINALES. No escribe al .pbip.

Lo que muestra el preview es exactamente lo que se escribiria: tipos, titulos, campos, tamanos y posiciones salen del mismo compilado que usa la aplicacion.

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.

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.

Verifica una pagina YA escrita: referencias rotas y geometria.

Se usa despues de aplicar un spec para comprobar que el resultado es valido de verdad, no solo que la escritura no fallo.

Lista las paginas del informe PBIR activo (id, nombre, tamano, nº visuales).

Lista los visuales de una pagina: id, tipo, posicion, campos, titulo.

page: id interno o nombre visible de la pagina.

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

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, color, bold, font, align. El texto va en options.text, NO en fields ni en la raiz: {"type": "textbox", "options": {"text": "Resumen", "font_size": 20}}.

• image: resource (ItemName ya registrado con pbi_add_image_resource), name, scaling.

• pageNavigator: show_hidden, show_current.

• actionButton: action, icon, target_page, text.

• format: formato del VISUAL, no del contenedor. mode (segmentador: Dropdown, List, Between...), header (bool: el encabezado del campo del segmentador; false lo oculta), dataLabels (bool), legend (bool), legendPosition (Top, Bottom, Left, Right...). Una clave desconocida aqui SE RECHAZA con la lista de las validas: un formato que se pide y no se aplica deja el informe distinto de lo que se penso sin decir por que.

position: {x, y, width, height} (z opcional). Clona un visual del mismo tipo como plantilla si existe. Hace backup.

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.

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).

Mueve/redimensiona un visual existente.

Filtra un visual EXISTENTE sin escribir filterConfig a mano.

filters: lista de specs. Por COLUMNA, {field: 'Tabla[Columna]', values?: [...], type?: 'Categorical' | 'Advanced' | 'TopN' | 'Range' | 'RelativeDate' | 'Passthrough', exclude?: bool, raw?: {...}, hidden?: bool, locked?: bool, display_name?: str}. Con values se arma un filtro de lista (Categorical); sin values ni raw el campo queda declarado pero SIN acotar, como el panel de filtros vacio. raw pasa una consulta semantica ya construida, para lo que este constructor no cubre.

Por MEDIDA, {measure: 'Tabla[Medida]', condition: 'GreaterThan', value: 0} (condition: Equal | NotEqual | GreaterThan | GreaterThanOrEqual | LessThan | LessThanOrEqual, o los simbolos > >= < <= = !=). Es la forma de ENCADENAR slicers de dimension cuando varias tablas de hechos cuelgan de las mismas dimensiones y una relacion bidireccional crearia ambiguedad.

field/measure van con el NOMBRE real de la tabla. La mitad interna de la consulta usa un ALIAS (SourceRef.Source) que esta tool resuelve sola: escribirlo a mano ahi es el error mas comun al construir un filtro de visual, y Power BI lo ignora sin decir por que.

Por defecto REEMPLAZA los filtros del visual, y una lista vacia los quita todos. Cuidado con los slicers: suelen traer un filtro Categorical donde vive la seleccion del usuario, y reemplazarlo la borra. Para anadir sin pisar, merge=true (ahi una lista vacia no quita nada). No comprueba el campo contra el modelo: uno que no existe se escribe igual y Power BI lo resuelve en silencio a nada.

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'.

Genera una pagina con visuales propuestos a partir del modelo.

Revisa el modelo, valida los campos sugeridos (no inventa campos), crea la pagina, agrega tarjetas para medidas y un grafico por categoria, y acomoda todo con el layout indicado. Devuelve un resumen de lo creado.

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 de resumen ejecutivo: fila de KPIs y grafico protagonista.

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.

Detecta referencias rotas en los visuales y las repara.

Sin mapping solo diagnostica: adivinar a que campo queria apuntar un visual roto no es una decision que deba tomarse sola. Pasa {"Tabla[Viejo]": "Tabla[Nuevo]"} para repararlas, y el destino se valida contra el modelo antes de escribir.

Normaliza la geometria de TODAS las paginas del informe.

Mete dentro del lienzo lo que se sale, sube al minimo lo demasiado pequeno y respeta margenes. No reacomoda lo que ya cumple. Compara el puntaje de auditoria antes y despues.

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.

Checklist de pre-entrega con plan de correccion.

Audita el proyecto, produce un checklist de bloqueantes y propone las correcciones automaticas disponibles. Con dry_run=false las aplica y compara el puntaje antes y despues.

Documentacion tecnica completa en Markdown, guardada en outputs/.

Incluye el modelo (tablas, medidas con su DAX y dependencias), el informe pagina a pagina con los campos de cada visual, y la auditoria con puntaje por dominio.