/*
 * Bloque `ipropanel/project-info` — cuerpo del detalle de proyecto (S8.3).
 *
 * Nodos: `325:2440` (desktop, 1280) y `325:4275` (mobile, 414). Los dos se
 * leyeron completos con `get_design_context`; no hay ni un valor medido
 * sobre el PNG (regla de S8.2, `DESIGN-INVENTORY.md` §2.4).
 *
 * TIPOGRAFÍA: la sección va entera en **Inter**, incluidos H2 y H3. Es lo
 * que dice el nodo y lo confirma el vecino `325:2567`; las únicas partes en
 * Montserrat son las instancias de componente de librería, de ahí que el CTA
 * —que sí es el Button `393:489`— sea la excepción dentro de este archivo.
 * Rompe V8 y queda como pregunta #53 de `INTERACTIONS.md`.
 *
 * DESGLOSE VERTICAL DESKTOP (el metadata da la sección en 928,3 de alto):
 *   64      padding-block-start (sin padding-block-end: los 80 de aire hasta
 *           el footer los pone la sección siguiente, `325:2567`)
 *   ├─ columna izquierda (610,125 de ancho, 864,3 de alto)
 *   │  36   H2  +  16 pt  +  381  descripción
 *   │  32 pt + 32 H3 + 16 pt + 163,2 grilla de materiales
 *   │  32 pt + 32 H3 + 16 pt + 108,1 card de impacto
 *   └─ ficha (329 de ancho, x = 711 → gap de 100,875)
 *
 * TRES ARTEFACTOS DEL IMPORT que NO se reproducen literalmente (el frame
 * viene de un prototipo HTML: bordes de 0,8, paddings de 16,8/24,8 y tipos
 * de 15,142/17,306 = escala 0,8653). Quedan como preguntas #54-#56:
 *   a) Mobile apila las 3 cards de material con ancho FIJO de 297,0625 —el
 *      ancho de la columna desktop— dentro de un contenedor de 350, y con
 *      gap 0: se tocan borde con borde. Acá van a ancho completo con el
 *      mismo `gap: 16px` que el propio diseño usa en desktop.
 *   b) La ficha se declara `h: 571` pero su contenido suma 581,6 — se
 *      desborda sola. La altura la da el contenido.
 *   c) El botón se declara en 279 fijos. En desktop eso ES el interior de la
 *      ficha (329 − 24,8·2 = 279,4); en mobile se queda corto dentro de
 *      300,4. Va al 100 % en los dos.
 *
 * COLOR: el nodo alterna sin criterio el color de los dos H3 —"Materiales"
 * es #d1d5dc en desktop y blanco en mobile, "Impacto" al revés—, así que los
 * dos y el nombre del material se unifican en `gray-0`. El H2 sí coincide en
 * los dos frames (blanco). Pregunta #56.
 *
 * LOS PADDINGS LLEVAN EL BORDE DESCONTADO. Las cuatro cajas con borde de
 * esta sección declaran en el nodo 16,8 / 24,8 / 18,171 de padding, pero
 * Figma dibuja el borde **por dentro** de la caja: su alto de 73,6 para la
 * card de material es 40 + 16,8·2, sin sumar los 0,8 del trazo. En CSS el
 * borde sí suma (`border-box` incluye padding y borde), así que reproducir
 * el literal daba 75,2 — 1,6 de más, el ancho de los dos bordes. Se
 * descuenta el borde del padding (16, 24 y 17,306) y las cajas miden lo que
 * mide el nodo. NO es una excepción al invariante de `box-sizing`: es
 * justamente lo que dice —"si una caja no mide lo que dice el diseño, el
 * problema está en su width/padding"—. Medido a 1280: 73,6 / 108,1 / 279,4
 * de interior en la ficha, todos exactos.
 */

.ipropanel-project-info {
	background-color: var( --wp--custom--color--detalle-bg );
	padding-block: 64px 0;
}

/* El aire hasta el footer lo pone `related-projects` con su
   `padding-block-end: 80px` — pero ese bloque hace `return` sin emitir markup
   cuando el proyecto no tiene relacionados, y entonces la página cerraba con la
   ficha «Datos del Proyecto» y su sombra a ras del footer: 0px de separación
   (hallazgo `D-63` de S8.5, reproducible con un sitio de un solo proyecto).

   `:last-child` y no un `padding-block-end` incondicional: con relacionados los
   dos aires se sumarían y darían 144. Los tres bloques del detalle son hijos
   directos del `<main>` de `single-proyecto.html`, así que cuando el último no
   se pinta esta sección queda última de verdad — y si alguien inserta otro
   bloque después desde el Editor de sitio, la regla deja de aplicar sola.

   Mobile no lo necesita: ya declara su propio `padding-block: 48px 80px`. */
.ipropanel-project-info:last-child {
	padding-block-end: 80px;
}

.ipropanel-project-info__inner {
	display: grid;

	/*
	 * La ficha es la única columna de ancho fijo del nodo (329). La de texto
	 * es lo que sobre: a 1280 da 610,125, exactamente lo que mide el frame.
	 * Por eso `1fr` y no el literal — a anchos mayores la descripción crece
	 * en vez de dejar un hueco (regla R1 / V17).
	 */
	grid-template-columns: 1fr 329px;
	column-gap: 100.875px;
	align-items: start;
	max-width: var( --wp--style--global--wide-size );
	margin-inline: auto;
	padding-inline: var( --wp--preset--spacing--section-padding-inline );
}

/* Sin descripción, materiales ni impacto la columna izquierda no tiene qué
   contener, y a 1280 dejaba 610,125px de aire a la izquierda de la ficha —
   770,125 a 1440, o sea que el hueco CRECE con el ancho porque es la columna
   `1fr` la que se lo lleva. Medido en las 37 fichas publicadas del portafolio
   real: las 37 emiten el modificador.

   La salida no es apagar la caja —eso es lo que hace mobile y en desktop
   estiraría la ficha, ver el comentario del media query— sino quitar la
   COLUMNA: con una sola pista de 329px la ficha conserva su ancho y la de
   texto deja de existir. `align-items: start` no se toca: el hueco es
   horizontal.

   La ficha queda a la izquierda, alineada con el breadcrumb y el `<h1>` del
   hero. No es un valor tomado del archivo —el archivo NO dibuja este estado,
   misma laguna que la pregunta #78 de `INTERACTIONS.md`, registrada como #79—
   sino la extensión de lo que el sitio YA sirve en mobile, donde la ficha
   ocupa la columna única desde el borde del contenido. */
.ipropanel-project-info__inner--sin-contenido {
	grid-template-columns: 329px;
}

/* ---------------------------------------------------------------- Columna
   izquierda: descripción, materiales, impacto. ------------------------- */

.ipropanel-project-info__titulo {
	margin: 0;
	font-family: var( --wp--preset--font-family--inter );
	font-size: var( --wp--preset--font-size--heading-2-interna );
	line-height: 1.125; /* 36 / 32 */
	font-weight: 700;
	color: var( --wp--preset--color--neutral-white );
}

.ipropanel-project-info__descripcion {
	padding-top: 16px;
	font-family: var( --wp--preset--font-family--inter );
	font-size: var( --wp--preset--font-size--parrafo-detalle );
	line-height: 1.625; /* 29,25 / 18 */
	color: var( --wp--preset--color--neutral-white );
}

.ipropanel-project-info__descripcion p {
	margin: 0;
}

/* En la maqueta los párrafos se separan con un salto de línea vacío, o sea
   exactamente un interlineado. El campo es un WYSIWYG y trae `<p>` reales,
   así que el aire va como margen y no como `<br>` de más. */
.ipropanel-project-info__descripcion p + p {
	margin-top: 29.25px;
}

.ipropanel-project-info__bloque {
	padding-top: 32px;
}

.ipropanel-project-info__subtitulo {
	margin: 0;
	font-family: var( --wp--preset--font-family--inter );
	font-size: var( --wp--preset--font-size--heading-3-interna );
	line-height: 1.3333; /* 32 / 24 */
	font-weight: 700;
	color: var( --wp--preset--color--gray-0 );
}

.ipropanel-project-info__materiales {
	display: grid;
	grid-template-columns: repeat( 2, 1fr );
	gap: 16px;
	margin: 0;
	padding: 16px 0 0;
	list-style: none;
}

.ipropanel-project-info__material {
	display: flex;
	align-items: flex-start;
	gap: 12px;
	padding: 16px; /* 16,8 del nodo − 0,8 de borde */

	/* 14 no está en la escala del tema (8/10/16/24/full) y solo lo usan las
	   dos cards de esta sección; queda literal, citado del nodo `325:2454`. */
	border: 0.8px solid var( --wp--custom--color--badge-teal-bg );
	border-radius: 14px;
}

.ipropanel-project-info__material-badge {
	display: flex;
	flex-shrink: 0;
	align-items: center;
	justify-content: center;
	width: 40px;
	height: 40px;
	border-radius: var( --wp--custom--border-radius--md );
	background-color: var( --wp--preset--color--primary-yellow );
}

.ipropanel-project-info__material-icono {
	display: block;
	width: 20px;
	height: 20px;
	background-color: var( --wp--preset--color--dark-blue-gradient );
	mask: var( --ipropanel-icono ) no-repeat center / 100% 100%;
	-webkit-mask: var( --ipropanel-icono ) no-repeat center / 100% 100%;
}

.ipropanel-project-info__material-nombre {
	font-family: var( --wp--preset--font-family--inter );
	font-size: var( --wp--preset--font-size--boton );
	line-height: 1.5; /* 24 / 16 */
	font-weight: 600;
	color: var( --wp--preset--color--gray-0 );
}

.ipropanel-project-info__impacto {
	display: flex;
	align-items: flex-start;
	gap: 12px;
	margin-top: 16px;
	padding: 24px; /* 24,8 del nodo − 0,8 de borde */
	border: 0.8px solid var( --wp--custom--color--impacto-card-border );
	border-radius: 14px;
	background-color: var( --wp--custom--color--impacto-card-bg );
}

/* El nodo pinta este badge en `primary-light-blue`, en los DOS breakpoints.
   `DESIGN-INVENTORY.md` lo daba por confirmado en `secondary-extralight-blue`
   desde S1.2; manda el nodo (V13). Pregunta #53. */
.ipropanel-project-info__impacto-badge {
	display: flex;
	flex-shrink: 0;
	align-items: center;
	justify-content: center;
	width: 48px;
	height: 48px;
	border-radius: var( --wp--custom--border-radius--md );
	background-color: var( --wp--preset--color--primary-light-blue );
}

.ipropanel-project-info__impacto-icono {
	display: block;
	width: 24px;
	height: 24px;
	background-color: var( --wp--preset--color--neutral-white );
	mask: var( --ipropanel-icono ) no-repeat center / 100% 100%;
	-webkit-mask: var( --ipropanel-icono ) no-repeat center / 100% 100%;
}

.ipropanel-project-info__impacto-texto {
	margin: 0;
	font-family: var( --wp--preset--font-family--inter );
	font-size: var( --wp--preset--font-size--parrafo-detalle );
	line-height: 1.625;
	color: var( --wp--preset--color--near-black );
}

/* ------------------------------------------- Ficha "Datos del Proyecto".
   Los 15,142 / 17,306 / 21,632 / 0,865 / 12,979 / 18,171 / 17,306 son la
   escala 0,8653 del import: no hay preset equivalente, van literales. --- */

.ipropanel-project-info__ficha {
	padding: 24px; /* 24,8 del nodo − 0,8 de borde */
	border: 0.8px solid var( --wp--preset--color--neutral-white );
	border-radius: var( --wp--custom--border-radius--lg );
	background-color: var( --wp--custom--color--ficha-card-bg );
	box-shadow: var( --wp--preset--shadow--shadow-md );
}

.ipropanel-project-info__ficha-titulo {
	margin: 0;
	font-family: var( --wp--preset--font-family--inter );

	/* 1.25rem = 20 px, el valor del nodo. El slug es de otro contexto pero
	   el criterio de S2.7 es coincidencia de valor, no de nombre. */
	font-size: var( --wp--preset--font-size--heading-2-parrafo );
	line-height: 1.4; /* 28 / 20 */
	font-weight: 700;
	color: var( --wp--preset--color--neutral-white );
}

.ipropanel-project-info__ficha-lista {
	margin: 24px 0 0;
}

/* `grid` y no `flex` desde S11.3: al quitar el `<div>` intermedio que hacía
   inválida la lista de definición, `dt` y `dd` pasaron a ser hermanos del
   icono. Con `flex` quedarían los tres en fila; con dos columnas y el icono
   ocupando ambas filas, el resultado es exactamente el mismo que antes
   —verificado midiendo las cajas de las 5 filas a 1280 y 414. */
.ipropanel-project-info__ficha-fila {
	display: grid;
	grid-template-columns: auto 1fr;
	align-items: start;
	column-gap: 12.979px;
	padding-bottom: 17.306px; /* 18,171 del nodo − 0,865 de borde */
	border-bottom: 0.865px solid var( --wp--preset--color--neutral-white );
}

.ipropanel-project-info__ficha-fila + .ipropanel-project-info__ficha-fila {
	margin-top: 17.306px;
}

.ipropanel-project-info__ficha-fila--ultima {
	padding-bottom: 0;
	border-bottom: 0;
}

/* Los tres primeros íconos son los archivos que S2.4 exportó para
   `project-card`, con el trazo teal quemado; acá van en amarillo. Por eso
   `mask` y no `<img>`: el color sale del token, no del archivo. */
.ipropanel-project-info__ficha-icono {
	display: block;
	grid-row: span 2;
	width: 21.632px;
	height: 21.632px;
	margin-top: 4.326px;
	background-color: var( --wp--preset--color--primary-yellow );
	mask: var( --ipropanel-icono ) no-repeat center / 100% 100%;
	-webkit-mask: var( --ipropanel-icono ) no-repeat center / 100% 100%;
}

.ipropanel-project-info__ficha-label {
	font-family: var( --wp--preset--font-family--inter );
	font-size: 15.142px;
	line-height: 21.632px;
	font-weight: 400;
	color: var( --wp--preset--color--neutral-white );
}

.ipropanel-project-info__ficha-valor {
	margin: 0;
	font-family: var( --wp--preset--font-family--inter );
	font-size: 17.306px;
	line-height: 25.958px;
	font-weight: 600;
	color: var( --wp--preset--color--neutral-white );
}

/* --------------------------------------------------------------- CTA. --
   Único elemento en Montserrat de la sección, porque es la instancia del
   componente Button (`393:489`) y no texto propio del frame.

   ES LA DEFINICIÓN CANÓNICA DEL BOTÓN PRIMARIO; los otros siete consumidores
   del par apuntan acá.

   ── S16.3 (`RD-04`, 2026-08-19): el texto vuelve a BLANCO ──────────────

   El nodo pinta el texto en blanco sobre `primary-light-blue` (#00A5AE) y ese
   par da **3,00 : 1 medido**. A 16px / 600 no califica como «texto grande»
   —WCAG 2.2 AA 1.4.3 pide ≥ 18,66px bold o ≥ 24px para bajar el umbral a
   3 : 1—, así que el mínimo aplicable es 4,5 y **no se cumple**.

   S8.6 había resuelto ese incumplimiento poniendo `neutral-black`, que sobre
   el mismo fondo da 6,99 : 1, y lo registró como decisión provisional `D-62`
   con la consulta `CD-F1` abierta. **`RD-04` la revierte**: el diseñador pidió
   por escrito, el 2026-08-18 y sobre el ambiente de test, «botones llevan
   texto en blanco» — la misma instrucción que ya traía la respuesta `A5`. Por
   **V22** una instrucción escrita y posterior prevalece sobre el archivo, sobre
   el QA y sobre una decisión provisional nuestra.

   V22 exige a cambio dos cosas, y las dos están hechas: el cambio queda
   registrado en `DECISIONES-PROVISIONALES.md`, y **prevalecer no es dejar de
   medir** — el 3,00 : 1 está escrito y vuelve al diseñador en la segunda ronda
   de consultas. `CD-F1` sigue abierta y ahora con el número de las dos
   direcciones.

   **Alcance: sólo botones.** `D-62` había tocado siete sitios, y uno de ellos
   —el chip del pin del mapa, 8 px, el peor caso del tema— NO es un botón:
   conserva `neutral-black` y `D-62` sigue vivo para él. El par tampoco cambia
   donde es objeto gráfico y no texto (1.4.11 pide 3 : 1 y da exactamente
   3,00): flechas de la galería, dot del hero, badges y pines. El zoom del mapa
   ya era blanco y cumple por ser 20px/700, o sea texto grande.

   Se revierte si `CD-F1` contesta otra cosa. */

.ipropanel-project-info__cta {
	display: flex;
	align-items: center;
	justify-content: center;
	gap: 8px;
	width: 100%;

	/* `min-height` y no `height`, desde S11.5d (`D-79`). El nodo `325:2988`
	   declara 48 y con la etiqueta española eso es exacto: una línea de 24 más
	   los 12+12 del padding. En inglés «Request a consultation» necesita dos
	   líneas dentro de los 279 px del botón a 1280, y con el alto fijo el
	   texto **se salía de la píldora** — la segunda línea quedaba montada en
	   el borde inferior. Es un caso que el archivo no dibuja porque el archivo
	   está en español, y la etiqueta es contenido administrable: puede
	   alargarse en cualquier idioma. Con `min-height` el botón sigue midiendo
	   48 exactos cuando cabe en una línea —o sea que la reconciliación contra
	   el nodo no se mueve— y crece solo cuando el texto lo obliga. */
	min-height: 48px;
	margin-top: 23.8px;
	padding: 12px 32px;
	border: 0;
	border-radius: var( --wp--custom--border-radius--full );
	background-color: var( --wp--preset--color--primary-light-blue );
	box-shadow: var( --wp--preset--shadow--shadow-lg );
	cursor: pointer;
	font-family: var( --wp--preset--font-family--montserrat );
	font-size: var( --wp--preset--font-size--boton );
	line-height: 24px;
	font-weight: 600;
	/* Blanco, que es lo que pinta el nodo: `RD-04` bajo V22. Ver arriba. */
	color: var( --wp--preset--color--neutral-white );
	transition: background-color var( --wp--custom--motion--duration-estado ) var( --wp--custom--motion--easing-estado ), color var( --wp--custom--motion--duration-estado ) var( --wp--custom--motion--easing-estado );
}

/* `currentColor` y no un token: así la flecha sigue al texto en el hover
   sin una segunda regla. Es también la razón de que sea `mask` y no `<img>`
   —el SVG trae el trazo blanco quemado y no heredaría nada—, mismo motivo
   que el toggle de `projects-browser` (S6.3). */
.ipropanel-project-info__cta-flecha {
	display: block;
	flex-shrink: 0;
	width: 20px;
	height: 20px;
	background-color: currentColor;
	mask: var( --ipropanel-icono ) no-repeat center / 100% 100%;
	-webkit-mask: var( --ipropanel-icono ) no-repeat center / 100% 100%;
}

/* Verificado vía MCP contra el component set "Button" (variant
   Primary/Hover `393:493`): fondo a amarillo y texto —e ícono— a negro.
   `:active` cubre táctil (INTERACTIONS.md §4).

   FORMA CANÓNICA DEL PAR HOVER/ACTIVE — todos los demás consumidores del par
   apuntan acá en vez de repetir el fundamento (S11.1, 2026-08-11). Eran 7 de
   los 8 botones del sitio los que lo tenían mal, más la píldora del FAQ y la
   card de Ventajas.

   La guarda `@media ( hover: hover )` NO es cosmética y no es opcional: en
   táctil el navegador deja el `:hover` PEGADO al último elemento tocado, así
   que sin ella el botón se queda amarillo indefinidamente después del tap y
   deja de ser distinguible de un estado. Es el mismo modo de fallo que V20.c
   corrigió para los pines del mapa; S11.1 lo generalizó al resto del tema,
   donde 7 de los 8 botones agrupaban `:hover, :active` sin guarda.

   Por eso las dos reglas van SEPARADAS y no agrupadas: agruparlas mete el
   `:hover` dentro de la media query y el `:active` se perdería en escritorio,
   o lo deja fuera y vuelve el hover pegado. No hay forma agrupada correcta.

   Consecuencia asumida (misma que V20.a): en un portátil táctil con mouse el
   puntero primario es fino, así que ahí el hover se conserva. */
@media ( hover: hover ) {
	.ipropanel-project-info__cta:hover {
		background-color: var( --wp--preset--color--primary-yellow );
		color: var( --wp--preset--color--neutral-black );
	}
}

.ipropanel-project-info__cta:active {
	background-color: var( --wp--preset--color--primary-yellow );
	color: var( --wp--preset--color--neutral-black );
}

/* El `:focus-visible` propio de este botón se retiró en S11.3 y pasó a
   `src/scss/base/_focus.scss`. No era solo duplicación: medido contra la
   ficha sobre la que se pinta —`rgba(255,255,255,0.2)` sobre `detalle-bg`—
   daba **1,92 : 1**, por debajo del 3 : 1 de WCAG 1.4.11. El indicador
   global le añade el contorno oscuro que lo resuelve. */

/* ------------------------------------------------------------- Mobile. */

@media ( max-width: 767px ) {
	.ipropanel-project-info {
		padding-block: 48px 80px;
	}

	.ipropanel-project-info__inner {
		grid-template-columns: 1fr;
		row-gap: 48px;
	}

	/* Un ítem de grid con `height: 0` sigue ocupando su fila y cobrando el
	   `row-gap`, así que con los tres campos vacíos sobre la ficha quedaban
	   96px de aire en vez de 48 (hallazgo `A-41` de S8.5). `display: none` lo
	   saca del grid y del árbol de accesibilidad.

	   Solo en mobile: en desktop este `<div>` es el que ocupa la columna `1fr`
	   y apagarlo movería la ficha a esa columna, estirándola de 329 a 610. Ahí
	   el aire no se cobra porque las dos cajas son hermanas de la misma fila y
	   el `column-gap` no depende de la altura.

	   Eso sigue siendo cierto, y la tercera salida que faltaba es la que
	   `__inner--sin-contenido` aplica arriba: en desktop no se apaga el
	   ocupante, se quita la COLUMNA. Las dos reglas conviven porque atacan
	   defectos distintos —acá el `row-gap` cobrado de más, allá el hueco
	   horizontal— y ninguna de las dos sirve en el breakpoint de la otra. */
	.ipropanel-project-info__contenido--vacio {
		display: none;
	}

	.ipropanel-project-info__titulo {
		line-height: normal;
	}

	/* El bloque de materiales cierra con 32 abajo, y el de impacto ya no
	   abre con padding: su aire hasta el H3 lo pone ese cierre. */
	.ipropanel-project-info__bloque {
		padding-block: 32px;
	}

	.ipropanel-project-info__bloque--impacto {
		padding-block: 0;
	}

	.ipropanel-project-info__materiales {
		grid-template-columns: 1fr;
	}

	.ipropanel-project-info__impacto {
		margin-top: 24px;
	}
}