Fix: Contract Vol. y Forecast en Summary y Package Detail. Contract Vol. sumaba Saves (siempre negativo), por lo que lo restaba del volumen contratado. Ahora Contract Vol. = Main Contract + CO + Order, y Forecast = Contract Vol. + ACP + Saves. En el desglose de Package Detail, la línea Saves pasa a ir entre ACP y Forecast. Petición explícita de Antonio (ejemplo: 08 OBRA CIVIL, Contract Vol. debía ser 3.788.562,99 € y mostraba 3.740.562,99 €).

Summary: salto de línea explícito en las cabeceras de Variance. El ajuste de v1.04 (white-space:normal) no garantizaba que el título pasara a dos líneas: con table-layout:auto, el navegador puede seguir dando hueco suficiente para mostrarlo en una sola línea si hay espacio disponible en la tabla — dependía de cuánto se hubiera encogido el resto de columnas, no de una regla fija. Ahora el salto es explícito (<br> en el propio texto de la cabecera): "Variance vs
Budget" y "Variance vs
Actual Budget", siempre en el mismo punto, con independencia del ancho disponible. Petición explícita de Antonio ("no me gusta como queda").

Summary: cabeceras de Variance en dos líneas. Las dos columnas nuevas de v1.03 ("Variance vs Budget"/"Variance vs Actual Budget") ensanchaban mucho su columna al llevar el título en una sola línea (comportamiento por defecto de las cabeceras de tabla en toda la app). Nueva clase .wrapHead: el título de ambas cabeceras pasa a dos líneas (texto centrado, tamaño de letra algo menor), con lo que la columna vuelve a ocupar un ancho similar al resto — la fila de cabecera crece de alto automáticamente para acomodar las dos líneas, sin afectar al resto de cabeceras de esa fila. Petición explícita de Antonio.

Lists: nueva columna Description. Summary: desviación desglosada en dos columnas. (1) La pantalla Lists no mostraba ningún campo de texto libre — el usuario tenía que abrir Package/Contract Detail para saber de qué trataba un registro. Nueva columna "Description" (entre Type y Amount) que unifica, para cualquier tipo de registro, el campo de texto correspondiente: descripcion en BUDGET/TRASPASO BUDGET/ACP/SAVE, contrato en CONTRATO/OS y conceptoFactura en FACTURA — mismo orden de precedencia ya usado en el buscador (Search) y en Package Detail. Export CSV de Lists actualizado con la misma columna. (2) La pantalla Summary tenía una única columna "Variance" (Forecast − Actual Budget, ya con ajustes ACP y traspasos incluidos). Ahora hay dos: "Variance vs Budget" (Forecast − Budget Inicial, sin ajustes) y "Variance vs Actual Budget" (la desviación que ya existía, solo renombrada para distinguirla de la nueva). Mismo criterio de color aplicado a ambas. KPI superior y exportaciones (Excel del workbook completo, CSV de Summary) actualizados con el mismo cambio. Petición explícita de Antonio.

Fixes tras siete auditorías externas de seguridad (verificadas contra el código): corregidas dos regresiones funcionales reales de la migración de v1.01 — (1) crear/borrar un "lote global" (Packages), editar los usuarios de un proyecto desde Admin → Projects y crear un proyecto nuevo ya no pueden sobrescribir en silencio cambios de otro usuario ni colisionar con un identificador existente: las tres operaciones comparten el mismo criterio "fallar cerrado" que ya usa el botón Push normal; (2) Contratistas y su catálogo (compartido por todos los proyectos) queda restringido de verdad al superadmin en las tres capas. Además, cerrar sesión ya borra la copia local de los datos del navegador, y se retiró el código heredado que consultaba de forma anónima, antes de iniciar sesión, la tabla de la arquitectura anterior a la migración de seguridad. (3) SEC-08 (XSS almacenado) cerrado en toda la aplicación, incluyendo una familia de casos más sutil detectada en la séptima revisión: escapar con escHtml() el contenido de un atributo onclick="alguna_funcion('...')" NO es una defensa real — es un escape para contexto HTML, no para el JavaScript embebido dentro de ese atributo, y el navegador decodifica las entidades HTML antes de ejecutar ese JavaScript. Cerrados los 2 sitios reales con este patrón (el buscador de nº de contrato y el de nombre de lote, que ahora generan sus opciones con textContent/addEventListener en vez de HTML interpolado) y los 3 enlaces clicables de las fichas de detalle (ahora abren el link vía un atributo data-link ya validado, con un único onclick fijo sin datos interpolados) — más, de paso, SEC-09: linkBtn() y esos mismos enlaces ya no aceptan ningún link que no sea https: real (antes solo se escapaba el HTML del link, sin comprobar su protocolo). Ver PLAN_MIGRACION_SEGURIDAD_2026-09.md.

Migración de seguridad — separación real de datos por proyecto: hasta v1.00, todos los proyectos vivían en una única fila de la base de datos, descargada entera por cualquier usuario autenticado — la separación de "qué proyecto ves" era solo de interfaz, no de acceso real. Esta versión reparte los datos en tablas propias por proyecto (cost_control_projects) y una tabla de permisos (project_permissions) que Supabase usa para filtrar de verdad qué puede leer o escribir cada usuario, sin depender del navegador. También deja de guardarse la contraseña del superadmin en este navegador (antes se guardaba en texto plano para comodidad; ahora hay que reintroducirla cada vez que se usa "Guardar y conectar"). Crear/editar proyectos y gestionar sus usuarios sigue haciéndose exactamente igual desde la pantalla de Ajustes — sin cambios de uso para el superadmin ni para el resto del equipo. Ver PLAN_MIGRACION_SEGURIDAD_2026-09.md.

Versión oficial 1.00 — Control de Costes pasa a producción: Antonio declara esta app como su primera versión oficial, operativa y funcional, alcanzando el hito reservado en la convención de versionado desde la Rev. 99 (2026-08-20). A partir de esta versión, los textos de versión (título, login, cabecera) dejan de mostrar el contador de Rev. junto al número de versión — mostrar "v0.112 · Rev. 112" duplicaba la misma información dos veces; a partir de ahora se muestra solo el número de versión (vX.XX), que pasa a ser también el único indicador visible de revisión. El Version Log sigue registrando cada entrega, ahora con el número de versión como etiqueta en vez de "Rev. XX". Petición explícita de Antonio.

Fix: el superadmin no podía borrar lotes recién creados (ni ningún lote "numerado" por encima de 59): reportado por Antonio al probar la Rev. 109 — los lotes obligatorios de siempre (60 CONTINGENCIES...99 PRORATE) deben seguir bloqueados tal cual, pero un lote nuevo creado libremente también aparecía con el botón "×" deshabilitado. Causa: la comprobación de "lote obligatorio, no se puede borrar" (deletePackage() y el render de la fila en renderSettings()) usaba packNum(p)>=60 — cualquier lote cuyo número (real, o el valor por defecto 999 que packNum() asigna cuando el prefijo no es numérico, como el placeholder recién añadido "XX NEW") fuera 60 o más se trataba como obligatorio, en vez de comprobar si es realmente uno de los 11 lotes fijos de DEFAULT_PACKAGES (60/70/80/81/82/83/84/90/97/98/99). Corregido con MANDATORY_PACK_NUMS (conjunto de esos 11 números concretos, calculado una vez a partir de DEFAULT_PACKAGES) e isMandatoryPackage(p), que sustituye a packNum(p)>=60 en ambos puntos. Los 11 lotes obligatorios siguen exactamente igual de bloqueados que antes; cualquier otro lote (nuevo o ya existente, tenga el número que tenga) pasa a ser borrable por el superadmin. Petición explícita de Antonio.

Sidebar: columna izquierda más ancha, tooltip con el nombre completo del proyecto al pasar el cursor, y Version Log movido a Admin: (1) .sidebar pasa de 200px a 230px, para que los nombres de proyecto largos en el grupo "Projects" se corten menos. (2) Nuevo tooltip propio (#sideProjectTip, sideProjectTipShow()/sideProjectTipHide()/sideProjectTipEl(), mismo patrón position:fixed ya usado por #cfPctFloat) que aparece junto a la fila al pasar el cursor sobre un proyecto del sidebar (sin clicar), mostrando el nombre completo — sustituye al atributo title nativo (tooltip del navegador, lento y con estilo genérico) por uno con la misma estética oscura del sidebar y aparición inmediata. (3) La sección "Version Log" (antes en el tab "Project", visible a cualquier admin de proyecto) pasa al tab "Admin", justo debajo de "Database Backups & Version History" — coherente con que el resto del historial técnico de la app ya vive ahí, y con que el tab "Project" quede centrado en el uso diario. Petición explícita de Antonio.

Settings dividido en dos pantallas — "Project" (cualquier admin) y "Admin" (solo superadmin): hasta ahora, una única pantalla Settings mezclaba gestión de proyectos (crear/borrar/usuarios), Cloud Settings, Cloud Admin Account y Backups/Version History (en la práctica ya solo operativos para superadmin) con configuración de uso diario del proyecto (selector, Packages, Warranty/Prorate, Cashflow Settings), visible a cualquier admin de proyecto. Ahora: "Project" (antes "Settings", visible a cualquier isSettingsAdmin()) — selector de proyecto limitado a los proyectos donde ese admin está autorizado (myProjectsList(), mismo criterio que el selector del sidebar; el superadmin los ve todos), Packages (añadir siempre permitido; borrar solo visible para el superadmin, admin@admin.es), Project Settings, Cashflow Settings y Version Log. "Admin" (pestaña nueva, solo superadmin) — CRUD completo de Projects (crear, activar/desactivar, borrar, gestión de Allowed/Read-only/Settings Admins), Cloud Settings, Cloud Admin Account y Database Backups & Version History; opera siempre sobre el proyecto seleccionado en la pestaña "Project". Nuevas renderProjectPicker() (selector ligero del tab Project) y renderAdminSettings() (agrupa lo anterior); changeSettingsProject() pasa de isSuperAdmin() a isSettingsAdmin() con verificación explícita de projectUserAllowed() para no-superadmin (evita que un admin de un proyecto pueda activarse dentro de otro ajeno). Petición explícita de Antonio.

Fix: al cambiar de proyecto en Settings, el título/código del proyecto y los campos de Users no se actualizaban: regresión introducida por la Rev. 102. changeSettingsProject() pasa por setActiveProject(), que ya actualiza SETTINGS_PROJECT_ID y dispara renderCurrentPanel() → renderSettings() — pero renderSettings() vuelve a llamar a syncSelectedProjectEditorToStore() como primera línea, y esa función leía getSettingsProjectId() "en caliente": en ese segundo llamado ya devolvía el proyecto **nuevo**, mientras el formulario en pantalla (Center/Project/Active/Users) todavía mostraba los valores del proyecto **anterior** (el nuevo renderProjectEditor() aún no se había ejecutado) — el resultado era que los datos antiguos se volcaban sobre el proyecto nuevo, sobrescribiéndolo con sus propios valores stale en el mismo instante en que se cargaba. Corregido con un id explícito (PROJECT_CARD_RENDERED_ID, nueva variable) que registra a qué proyecto pertenecen realmente los campos visibles en el DOM en cada momento — se fija al final de renderProjectEditor() y es el que usa syncSelectedProjectEditorToStore() para decidir dónde volcar, en vez de volver a preguntar el proyecto "actual" cada vez. Detectado por Antonio.

Settings → Projects: seleccionar un proyecto lo activa directamente, sin botón "Use": hasta ahora, elegir un proyecto en el selector o en la lista de accesos rápidos de Settings (superadmin) solo cambiaba qué proyecto se estaba editando en el panel (changeSettingsProject()) — para que pasara a ser el proyecto realmente en uso en el resto de la app había que pulsar además un botón "Use" aparte (useSettingsProject()). changeSettingsProject() pasa a llamar directamente a setActiveProject() (misma función que ya usa el selector de "Projects" del sidebar, Rev. 76, y que ya cambia de proyecto sin botón adicional): la selección y la activación quedan unificadas en una sola acción. Retirados el botón "Use" y el indicador "Current App Project" (quedaba siempre igual al proyecto seleccionado, sin poder divergir). Petición explícita de Antonio.

Ventana flotante de % acumulado (Cashflow, casillas Budget %/Ajuste %): añadidos los importes en € junto a cada porcentaje: además de "Acumulado" y "Resta" en %, la ventana muestra ahora el importe correspondiente entre paréntesis (Acumulado/Resta × Budget Actual del lote ÷ 100, la misma base que ya usa la tabla para calcular Budget €/Ajuste € por mes), y una tercera línea "Este mes" con el % que se está escribiendo y su importe, actualizada tecla a tecla igual que el resto del panel. Los inputs cf-budget/cf-adjust pasan a llevar data-base (Budget Actual del lote, calculado una vez por fila en renderEditableRow()) para que cfPctShow() no tenga que recalcularlo. Panel ensanchado de 170px a 230px (fijo por CSS, sin medir offsetWidth, mismo criterio de rendimiento que la Rev. 90) para que quepan los importes sin partir línea. Petición explícita de Antonio.

Invoice Summary: lote clicable y botón de link uniformado en toda la app: la fila "TOTAL [Package]" de cada lote abre ahora la misma ventana emergente de detalle de lote (showPackDetail()) ya usada en Summary, en vez de ser texto plano — mismo componente .packLink; las filas individuales de contrato no son clicables, solo el subtotal del lote. Nuevo botón circular de enlace (icono SVG "enlace externo", nueva clase CSS .linkBtn + helper JS linkBtn(url)) que sustituye, en toda la app, al símbolo de texto "↗" usado hasta ahora: Invoice Summary (nueva columna, primer link no vacío entre las facturas del contrato de esa fila), historial de facturas de Invoice Entry, Package Detail (Contracts & Orders + Invoices), Contract Detail (Contract Lines + Invoices) y Lists (columna Link, que además deja de depender de openLink() — retirada por quedar sin uso — y pasa a un <a href> real con la URL escapada). Petición explícita de Antonio, que pidió expresamente extender el nuevo icono (ya aprobado en Invoice Summary) al resto de sitios con contratos, facturas o pedidos con link.

Fix: las ventanas emergentes de detalle (Package Detail, Contract Detail) necesitaban scroll horizontal: .pdBody (cuadrícula Cost Breakdown + Contracts & Orders de Package Detail) usaba grid-template-columns:220px 1fr — el pitfall clásico de CSS Grid en el que una pista 1fr sin minmax(0,...) crece para ajustarse al contenido (la tabla de contratos) en vez de respetar el espacio disponible, forzando scroll horizontal en todo el modal. Corregido a minmax(160px,220px) minmax(0,1fr). Además, las celdas de tabla dentro de cualquier ventana emergente (.modal-body table) ahora permiten partir texto largo sin espacios (overflow-wrap:anywhere) en vez de forzar anchura — nombres de contratista largos ya no empujan la tabla más allá del modal. El scroll vertical sigue disponible donde ya lo había (listados de contratos/facturas con max-height). Petición explícita de Antonio.

Excel del Informe de Cashflow: en las filas de lote, el % pasa a ser el dato guardado y el importe el que se calcula (antes al revés): en la hoja "DETALLE COMPLETO" (Rev. 97), las filas de lote tenían el importe (€) como número pegado y el % como fórmula dividiendo €/base — invertido respecto a cómo funciona realmente el dato: Budget % y Ajuste % (en meses abiertos) son el valor que se guarda y edita en la app, y el importe se calcula multiplicando ese % por el Budget Actual del lote, igual que hace buildCashflowProjection(). Ahora la celda de % lleva el número guardado y la de € la fórmula =Budget×%/100. Sin cambios en Coste Real (siempre un hecho medido, nunca un % de entrada) ni en Ajuste de meses cerrados (el importe sigue siendo el Coste Real real, con el % derivado de él) ni en las filas de categoría/totales (siguen siendo sumas, sin % guardado en ningún sitio al que referenciar). Petición explícita de Antonio.

Excel del Informe de Cashflow reescrito para llevar fórmulas reales, no solo valores pegados: la hoja "DETALLE COMPLETO" deja de leerse del texto ya formateado en pantalla (Rev. 95) y pasa a construirse con números reales y fórmulas de Excel — SUMA() en las filas de categoría/totales sobre el rango de sus lotes, sumas por referencia entre subtotales para HARD COSTS/SOFT COSTS/TOTAL (que no vuelven a sumar cada lote, referencian directamente sus dos subtotales), y los tres % (Budget %, Coste Real %, Ajuste %) como fórmulas que dividen la celda € entre la celda Budget/Contratado de la misma fila, con protección `IF(...=0,0,...)` para evitar errores de división por cero. La hoja resumen ("CASHFLOW REPORT") pasa a su vez a referenciar la fila TOTAL de "DETALLE COMPLETO" para los 4 KPIs y la tabla mensual, en vez de llevar los mismos números pegados por duplicado. Nuevo `window.buildFullDetailFormulaMatrix()` (dentro del cierre de `renderCashflow()`, mismo patrón que `exportCashflowExcel`) y `excelColLetter()`. El PDF no cambia — sigue usando `cfReadFullDetailTable()` (lectura de texto ya formateado), porque un PDF no admite fórmulas vivas. Petición explícita de Antonio.

Fix: los totales de categoría (CONSTRUCTION COSTS, HARD COSTS...) sumaban de más la columna "Budget" cuando algún lote tenía Budget Actual exactamente 0€: las filas individuales calculan ese caso con r.actualBudget??r.budget (operador de coalescencia nula: solo cae al Budget Inicial si `actualBudget` es `null`/`undefined`, nunca si es `0`), pero la suma de categoría (sumRows()) usaba data.summary.actualBudget||data.summary.budget (operador OR: trata `0` como "vacío" y cae igualmente al Budget Inicial) — por eso un lote mostraba correctamente 0k€ en su fila pero sumaba su Budget Inicial (no 0) al total de categoría. Mismo fix aplicado a la base del reparto mensual (`buildCashflowProjection`, llamada tanto desde `renderCashflow()` como desde el Informe de Cashflow, Rev. 94/95) por el mismo motivo. Ejemplo: CONSTRUCTION COSTS mostraba 15,11M€ en vez de 12,15M€ (coincidente con "suma budget ajustado", que sí sumaba bien por usar otra ruta de cálculo). Detectado por Antonio.

Informe de Cashflow: anexo/hoja con el Detalle completo cashflow tal cual está: el PDF añade una página apaisada (A4 landscape, con salto de página horizontal automático si no cabe en una) con la tabla completa por lote y mes (Budget €/%, Coste Real €/%, Ajuste €/%, incluidas las filas de totales por categoría). El Excel añade una segunda hoja "DETALLE COMPLETO" con la misma tabla, cabeceras combinadas y primera columna/dos filas de cabecera congeladas para facilitar la navegación. En ambos casos, el contenido se lee directamente del DOM de la tabla ya renderizada en pantalla (nuevo cfReadFullDetailTable()) en vez de recalcular las fórmulas por separado — garantiza que el anexo coincide exactamente con lo que se ve en la app, sin riesgo de que ambos cálculos diverjan con el tiempo. Petición explícita de Antonio.

Nuevo: Informe de Cashflow para remitir a la propiedad, en PDF y Excel: dos botones "📄 Generar PDF"/"📊 Generar Excel" en Detalle completo cashflow, en una barra separada de las herramientas internas ("Informe para propiedad"). Ambos incluyen cabecera de proyecto, 4 KPIs (Budget, Contratado, Facturado, Ajustado), un gráfico de evolución mensual (Budget/Real facturado/Ajustado) y la tabla mensual de esas tres series — nivel de resumen de proyecto, sin desglose por lote. El PDF usa jsPDF + jspdf-autotable (nuevas dependencias CDN). El Excel usa ExcelJS (nueva dependencia CDN) en vez de SheetJS específicamente para este informe, porque SheetJS gratuito no soporta escribir imágenes en el archivo — el gráfico de evolución se incrusta como imagen fija (no editable como gráfico nativo de Excel); el resto de exportaciones Excel de la app siguen en SheetJS. Petición explícita de Antonio, confirmado el alcance (resumen de proyecto, gráfico como imagen) con AskUserQuestion.

Excel export/import (Rev. 91): meses cerrados exportan el Ajuste % efectivo, no el valor guardado: para un mes cerrado, `adjustArr[i]` (el % planificado) ya no se usa en la app — el Ajuste % real que se aplica es Coste Real ÷ Budget Actual (mismo cálculo de la Rev. 92). El Excel exportado volcaba el valor guardado (a menudo 0 o desactualizado) en vez de ese % efectivo. Nuevo closedAdjustPct(pack,i)/cfExportAdjustArr(pack): los meses cerrados se rellenan con el % efectivo (de solo lectura en la práctica, ya que tampoco son editables desde la tabla) y los abiertos siguen mostrando el % planificado editable. El import compara también contra ese % efectivo en meses cerrados, para no marcar como "distinto" un valor que en realidad coincide con lo exportado. Petición explícita de Antonio.

Fix: Ajuste % dividía por "suma budget ajustado" (la suma de los propios ajustes del lote) en vez de por Budget Actual: mismo tipo de error que el de Budget % (Rev. 90) pero en la columna de Ajuste. Corregido en renderRow()/renderEditableRow(): `baseAdj` pasa de `tAdj` (suma de projection.adjusted) a `tBudget` (Budget Actual, la misma cifra ya usada como base de Budget %). La columna "suma budget ajustado" del resumen no cambia (sigue mostrando esa suma como referencia informativa, solo deja de usarse como denominador del %). Ejemplo: lote 01 EXCAVACION Y MOV. TIERRAS, mes cerrado con 108k€ de ajuste sobre 1,25M€ de Budget Actual = 8,64% (antes 12%, dividiendo por 872k€ de suma ajustado). Detectado por Antonio.

"Detalle completo cashflow": exportar/importar Budget % y Ajuste % en Excel: nuevos botones "↓ Exportar % a Excel" y "↑ Importar % desde Excel" (solo admin), visibles junto a Export CSV/Refresh. La exportación (exportCashflowExcel()) genera un `.xlsx` con un lote por fila y dos bloques de columnas (Budget %, Ajuste %) por mes, cada bloque con una columna "Total" con fórmula =SUMA() para ver de un vistazo si el reparto cuadra al 100% mientras se rellena en Excel — igual que la ventana flotante ya hace en la app (Rev. 89/90). La importación (cfImportFile()) no aplica los cambios directamente: primero muestra un resumen con cada celda que cambiaría (lote, serie, mes, valor actual → nuevo), lotes no reconocidos y celdas de Ajuste % en meses cerrados ignoradas (no editables desde la tabla tampoco), y solo escribe en el proyecto tras pulsar "Confirmar import" (cfApplyImport()). Pensado como alternativa más ágil a rellenar celda a celda en la propia tabla. Petición explícita de Antonio.

Fix: Budget €/mes se calculaba sobre Budget Inicial, no sobre Budget Actual/Ajustado (el mismo número de la columna "Budget"): `buildCashflowProjection()` vuelve a usar un único `totalBudget` (= Budget Actual) para Budget € y Ajuste €/mes — antes de la Rev. 85 ya era así; la separación introducida en esa revisión resultaba en que la columna "Budget" (Rev. 86, Budget Actual) y el reparto mensual de Budget % (Budget Inicial) usaran referencias distintas sin que se viera reflejado en la interfaz, dando resultados que no cuadraban al calcular a mano. Coste Real % sigue sobre Contratado, sin cambios. Ejemplo corregido: lote 04 ESTRUCTURA PREFABRICADA, 15% de 1,82M€ (Budget Actual) = 273k€, antes 204k€ (15% de 1,36M€ Budget Inicial). Además, fix de fluidez: la ventana flotante de % acumulado (Rev. 89) recalculaba su posición en pantalla (`getBoundingClientRect`/medida de ancho) en cada pulsación de tecla, forzando un recálculo de layout del navegador en una tabla grande — sensación de "trompicones" al escribir. Ahora la posición solo se calcula una vez, al entrar en la casilla; el contenido se sigue actualizando en cada tecla sin volver a medir nada. Detectado por Antonio.

Sustituido el desplegable de % acumulado (Rev. 87/88) por una ventana flotante que aparece al editar: Antonio pidió un patrón distinto — no un icono que hay que pulsar, sino una ventana que aparece sola al seleccionar la casilla de % y se actualiza en vivo mientras se escribe. Los inputs de Budget %/Ajuste % ya no llevan el icono "Σ%"; al hacer foco (o escribir) en cualquiera, aparece junto a la casilla una ventana con el % acumulado del lote/serie y lo que resta hasta 100% (en rojo si se supera), calculado con el valor todavía no guardado que se está tecleando. Desaparece al salir de la casilla. Un único elemento flotante (`#cfPctFloat`, fuera de la tabla, anexado a `document.body`) evita el problema de recorte por `overflow:auto` que tenía el desplegable anterior.

Fix: el desplegable de % acumulado (Rev. 87) no aparecía al pulsar el icono "Σ%": el panel usaba position:absolute, recortado por el overflow:auto de .cashflowFullWrap — mismo problema ya conocido y resuelto en esta app para los desplegables de autocomplete (contratistas, nº de contrato). Corregido con el mismo patrón: position:fixed + getBoundingClientRect(), calculado en el nuevo cfPctToggle() (disparado por el evento toggle del <details>), con ajuste para no salirse del viewport por la derecha. Detectado por Antonio.

Detalle completo cashflow: quitadas las flechas de los inputs de % mensual y añadido desplegable de % acumulado/restante por lote: los campos numéricos de Budget % (cf-budget) y Ajuste % (cf-adjust) dejan de mostrar las flechas de subida/bajada del navegador (edición solo por teclado). Junto al nombre de cada lote aparece un icono "Σ%" que, al pulsarlo, despliega un panel con el % acumulado de Budget y de Ajuste a lo largo de todos los meses y lo que resta hasta el 100% (en rojo si el acumulado supera el 100%); se cierra solo al clicar fuera. Petición explícita de Antonio, que edita los porcentajes directamente con el teclado y quería esta información como consulta puntual, no fija en la fila.

Fix: columna "Budget" de "Detalle completo cashflow" mostraba Budget Inicial en vez de Budget Actual: la columna de totales "Budget" (primera de las cuatro, junto a Contratado/suma budget ajustado/Facturado) usaba meta.budget/r.budget (Budget Inicial, sin ajustes) tanto en las filas de categoría (renderRow()) como en las de lote (renderEditableRow()). Pasa a usar actualBudget (Budget Inicial + ajustes ACP + traspasos) cuando existe, con Budget Inicial como fallback. La base del Budget %/mes (Rev. 85) no cambia — sigue dividiendo por Budget Inicial, ahora en una variable separada (tBudgetInicial) para no arrastrar el mismo cambio. Detectado por Antonio: 01 EXCAVACION Y MOV. TIERRAS mostraba 1,26M€ en vez de 1,248M€.

Fix: fórmulas de % erróneas en "Detalle completo cashflow" (Budget %, Coste Real %, Ajuste %): los tres porcentajes de cada mes se calculaban contra la misma base ("suma budget ajustado"), en vez de cada uno contra su referencia propia. Corregido en buildCashflowProjection() (Budget €/mes ahora se calcula sobre el Budget Inicial del lote, no sobre el Budget Ajustado) y en renderRow()/renderEditableRow() (Budget % = Budget €/mes ÷ Budget Inicial; Coste Real % = Coste Real €/mes ÷ Contratado; Ajuste % = Ajuste €/mes ÷ suma Budget Ajustado — cada uno con su propio denominador). No afecta a las columnas de totales del resumen (Budget/Contratado/suma budget ajustado/Facturado) ni a las filas CONTROL BUDGET INITIAL TOTAL/CONTROL ADJUSTED TOTAL, que ya usaban la base correcta. Detectado por Antonio con ejemplos concretos (Construction Costs 62k€ sobre 11,98M€ mostraba 4% en vez de 0,53%; 80 HON 20% de 503k€ mostraba 97k€ en vez de 100k€).

Cashflow: editar el Budget % por package/mes deja de exigir la cuenta admin@admin.es: la columna Budget % de "Detalle completo cashflow" solo era editable si isSuperAdmin() (comparaba el usuario conectado contra la cuenta literal admin@admin.es), un nivel más estricto que el resto de acciones de administrador de la app. Ahora usa isSettingsAdmin() (superadmin o cualquier usuario de la lista settingsAdmins del proyecto), mismo criterio que "Apply Gauss Distribution" y "Apply Plan to All Packages". Petición explícita de Antonio, que no podía editar la columna con su cuenta habitual de administrador del proyecto.

Fix: los porcentajes de Budget mensual editados en Settings → Cashflow Settings no se guardaban ni se usaban: el botón "Save Settings" nunca leía los campos de % editables del plan inicial (función readCashflowPlanFromUI(), ya existente pero huérfana), así que cualquier cambio se perdía al guardar; y aunque se hubiera guardado, los paquetes nuevos tomaban siempre la curva de Gauss fija en vez del plan editado. Corregido: "Save Settings" y "Normalise Budget %" ahora sí leen y persisten los % introducidos; cualquier package sin distribución propia hereda el plan inicial editado (antes: siempre Gauss); nuevo botón "Apply Plan to All Packages" para aplicar el plan editado también a packages que ya tienen distribución propia (mismo criterio que "Apply Gauss Distribution", pero con el plan del usuario en vez de recalcular Gauss). Las cifras de Budget € mensuales por package ya se recalculaban automáticamente a partir del %, sin cambios ahí. Petición explícita de Antonio.

Invoice Entry: listado de facturas del contrato junto al formulario: al seleccionar o buscar un número de contrato en Invoice Entry, aparece a la derecha del formulario un panel con todas las facturas ya registradas de ese contrato/OS/pedido (nº factura, fecha, importe certificado, concepto, enlace y total), para verlas de un vistazo mientras se introduce la nueva sin tener que navegar a otra pantalla. La factura que se está editando queda resaltada en el listado; clicar cualquier fila la carga en el formulario (mismo comportamiento que Search). Nueva función invRenderHistory(), invocada desde invFillFromContract() y invNew(). Petición explícita de Antonio.

Fix: Invoice Entry perdía Link y mostraba Warranty/Prorate Ret. en blanco al editar una factura existente: invLoad() nunca asignaba inv-link (el campo quedaba vacío al reabrir la factura, y al guardar se sobreescribía el link real con cadena vacía). Además calculaba Warranty Ret./Prorate Ret. antes de rellenar el importe certificado (inv-cert) — ncAcSelect('inv-ncontrato',...) dispara invFillFromContract()→invUpdateRetentions(), que lee inv-cert en ese momento, así que las retenciones se calculaban con el valor todavía vacío (o el de la factura anterior) en vez del certificado real de la factura cargada. Corregido reordenando invLoad(): ahora inv-cert e inv-link se rellenan antes de llamar a ncAcSelect. Detectado por Antonio.

Parent Contract (Contract Entry) con búsqueda por contrato, empresa y lote: el campo Parent Contract de las Órdenes de Servicio (OS) pasaba a solo filtrar por número de contrato al escribir, sin mostrar contratista ni lote — a diferencia de Contract Number en Invoice Entry, que ya buscaba por las tres columnas. Ahora usa exactamente el mismo desplegable de búsqueda (número, empresa o lote, con las tres columnas visibles en cada resultado), restringido a contratos de tipo CONTRATO (los únicos que pueden ser padre de una OS). Además, baja de varias ACP al crear una OS: tras guardar una nueva Orden de Servicio, antes solo se podía dar de baja una ACP del lote; ahora, tras cada baja, se pregunta si se quiere dar de baja otra, repitiendo hasta que no queden ACP abiertas en ese lote o el usuario decida parar. Protegido además contra seleccionar dos veces la misma ACP ya cerrada. También corregido: Package (Contract Entry) quedaba colgado al cambiar de pantalla: `icNew()` reseteaba Contract Number, Description, Amount, Contractor, Link y Parent Contract al entrar en Contracts, pero no Package — quedaba visible el último valor tecleado de una entrada anterior aunque el formulario estuviera "en blanco". Ahora Package también se limpia.

Fix: Grand Total incorrecto en Invoice Summary: el Grand Total (Contracted, Invoiced, Pending) se calculaba con una acumulación que podía duplicar importes si `DB.packages` contenía algún package repetido. Corregido: ahora el Grand Total se calcula explícitamente como la suma de los subtotales "TOTAL [Package]" ya mostrados en pantalla (nunca una pasada independiente sobre las filas), y la lista de packages se deduplica antes de recorrerla. De paso, Warranty Ret. y Prorate Ret. — hasta ahora en blanco tanto en los subtotales como en el Grand Total — pasan a sumarse igual que el resto de columnas.

Desplegables de Inputs con búsqueda dinámica: los campos Package (Budget, Budget Transfer, ACP, Contracts) y Parent Contract (Contracts) pasan de <select> plano a campo de búsqueda con autocomplete (mismo patrón ya usado en el buscador de contratistas y en Contract Number de Invoice) — al escribir, filtran dinámicamente por coincidencia. Además, Contract Number en Saves pasa a tener exactamente el mismo comportamiento y opciones que Contract Number en Invoice Entry: búsqueda por número de contrato, empresa y lote.

Tipografía cambiada a Arial: sustituidas Barlow Condensed y Roboto (Google Fonts) por Arial en toda la app — variables CSS --font-title/--font-body, etiquetas de los gráficos Chart.js y estilos de la exportación a Excel. Eliminado el enlace a Google Fonts (ya no se carga ninguna fuente externa). De paso, corregido el texto de versión de login/cabecera, que seguía mostrando v0.75 · Rev. 75 pese a ser ya la Rev. 76.

Projects pasa al lateral como sección propia: la sección "Projects" (Rev. 75) deja de ser un panel independiente al que hay que navegar — ahora es un grupo más del menú lateral (resaltado en verde, igual que Outputs/Inputs/System), colocado justo debajo de Inputs, con el listado de proyectos autorizados directamente como filas clicables dentro del propio lateral. Cambiar de proyecto ya no navega a ningún panel: se queda en la pantalla donde estabas, solo cambian los datos. El proyecto activo se resalta con un borde de acento en su fila.