/* spec-20260908-001-lucayuvdev (AC1) — EL TAMAÑO DE FUENTE DE UN CONTROL Y EL DE SU ETIQUETA,
   CON UN SOLO ORIGEN.

   Antes eran dos valores sin ninguna relación declarada: `.lb-sm` con un `12px` literal más abajo en
   esta misma hoja, y `.form-control` sin declarar nada, heredando el `1rem` de `bootstrap.min.css`.
   Cambiar uno sin acordarse del otro los desalineaba y ningún chequeo lo notaba — que es exactamente
   lo que AC1 vino a cerrar (Q2: la misma decisión no se escribe dos veces).

   ACÁ VIVEN LOS DOS CONSUMIDORES; LA DECLARACIÓN DEL TOKEN VIVE EN `public/css/bootstrapTokenizado.css`.
   El reparto no es capricho: cada una de las tres hojas candidatas rechaza una de las dos mitades, y
   las tres exclusiones están MEDIDAS corriendo la suite, no leídas:
     - El `font-size` de `.form-control` NO puede ir en `bootstrapTokenizado.css`:
       `tests/Support/TokensDelCanvas.php` cuenta `font-size` entre las familias de geometría, y
       ponerlo ahí pone en rojo un caso hoy verde de
       `BootstrapTokenizadoInputsTablasPortalesServidoTest`.
     - El `:root` del token NO puede ir en ESTA hoja: `PantallaTiendaReact.jsx:3` la importa desde JS,
       así que `style-loader` la inyecta en runtime y cae bajo el AC10 de
       `spec-20260901-001-lucayuvdev`, que prohíbe `:root`/`html`/`body`/`*` en alcance global en toda
       hoja importada desde JS (`resources/js/__tests__/hojasImportadasDesdeJsScopeadas.test.js`).
       Medido: con el `:root` acá, esa suite se pone roja.
     - Ninguna de las dos mitades puede ir en `public/css/tokensDeDiseno.css`: su cabecera (:19-21)
       declara que no contiene ni una regla de geometría, `font-size` nombrado con todas las letras.
   Queda entonces el único reparto que no rompe nada: la DECLARACIÓN en `bootstrapTokenizado.css`
   (que no la importa ningún JS) y los dos CONSUMIDORES acá. AC1 pide un solo ORIGEN del valor, y
   sigue habiendo uno solo.

   EL TOKEN SE DECLARA EN `:root` Y NO EN `body`: las custom properties heredan desde la raíz, así que
   también alcanza a una etiqueta dentro de un modal portado a `document.body` (el motivo por el que
   `spec-20260904-005-lucayuvdev` mudó la clase del tema al `<body>`).

   Y NO NECESITA `!important`: `React/main.blade.php` enlaza esta hoja DESPUÉS de `bootstrap.min.css`
   con la misma especificidad de selector, así que gana por orden. */
/* spec-20260909-003-lucayuvdev (AC8a) — LA ALTURA DEL CONTROL DEJA DE SALIR DEL TAMAÑO DE LETRA.
   El usuario reportó: "Todos los inputs deben medir 31px de alto. Cuando cambio el tamaño de la
   letra se achicaron de alto". Era literal: `bootstrap.min.css` (4.0.0, la hoja que los documentos
   REALMENTE sirven) no le declara a `.form-control` ni `height` ni `min-height`, así que su alto
   salía entero del box model —`padding` + `line-height` × `font-size`—, y el `font-size` es el
   `--fuente-de-control` de la regla de acá abajo. Bajar el token achicaba los inputs.

   `min-height` Y NO `height` FIJO: clavar la altura corta el texto el día que alguien suba
   `--fuente-de-control`; el mínimo da los 31px pedidos y deja que el control crezca si el contenido
   lo necesita. En `px` y no en `em`: el `em` es relativo al font-size del PROPIO control, que es la
   dependencia que este AC viene a cortar (`rem` también serviría, pero el pedido es un alto
   concreto en píxeles, no una proporción de la raíz).

   VA EN ESTA HOJA Y NO EN `bootstrapTokenizado.css`, aunque la spec la nombrara: aquella hoja
   declara en su cabecera que contiene SÓLO propiedades de color y ninguna regla de geometría, y
   esto es geometría. Acá ya vive el otro extremo de la misma decisión —el `font-size` del control—,
   así que las dos mitades de "cómo se dimensiona un control" quedan a la vista una al lado de la
   otra en vez de repartidas en dos hojas. Esta hoja la sirve un `<link>` en los dos documentos que
   hospedan la app, así que la regla llega igual. */
.form-control {
  font-size: var(--fuente-de-control);
  min-height: 31px;
}

/* spec-20260915-002-lucayuvdev (AC7) — EL TAMAÑO DE FUENTE DE LAS OPCIONES DEL DROPDOWN.
   Bootstrap 5.3.2 le clava `--bs-dropdown-font-size: 1rem` a `.dropdown-menu`, o sea el tamaño de
   cuerpo de fábrica: las opciones se veían notoriamente más grandes que el resto de los controles
   de la misma pantalla. `--fuente-de-control` es el origen único de ese número desde
   `spec-20260908-001` (AC1), y acá arriba ya lo consume `.form-control`.

   VA EN ESTA HOJA Y NO EN `bootstrapTokenizado.css`, AUNQUE LA SPEC LA HUBIERA PUESTO AHÍ. Aquella
   hoja declara color y nada más, y esto es tipografía. No es interpretación: `TokensDelCanvas.php`
   cuenta `font-size` entre las familias de geometría, y el recorrido de
   `BootstrapTokenizadoInputsTablasPortalesServidoTest` pregunta además por el NOMBRE de cada
   `--bs-*` de esa hoja (`-size` matchea), así que declararla ahí pone en rojo un caso hoy verde.
   Es el mismo reparto que ya obligó a que el `font-size` de `.form-control` viva acá y su token
   allá — el § de arriba lo explica con las tres exclusiones medidas.

   UNA SOLA REGLA ALCANZA A LOS DOS NODOS que el AC nombra: `.dropdown-item` no declara `font-size`
   propio en la 5.3.2, lo hereda del menú. Y gana por orden de enlace, igual que todo lo de esta
   capa: los dos documentos enlazan esta hoja después de `bootstrap.min.css` y las dos declaran
   sobre `.dropdown-menu`, que empatan en 0-1-0. */
.dropdown-menu {
  --bs-dropdown-font-size: var(--fuente-de-control);
}

/* spec-20260915-002-lucayuvdev (AC10/AC11) — EL BOTÓN QUE SE ANEXA A UN CONTROL, CON UN SOLO
   SISTEMA DE TAMAÑO.

   Los tres botones de la fila de Producto medían distinto porque cada uno tomaba su tamaño por un
   mecanismo distinto, y ninguno de los tres por el mismo eje: la lupa (`Producto.jsx`) por una
   clase de `<select>` (`form-select-sm`), el de ampliar (`CampoExpandible.jsx`) por `btn-sm`, y el
   `?` (`DescuentoAnidado.jsx`) por un `style` inline de 30x30. MEDIDO: 26x14, 18x10 y 30x30.
   Y `btn-sm` en los tres NO los iguala —también está medido—: `form-select-sm` le cambia el
   `font-size` a la lupa y con él el padding, así que la lupa seguía en 26x14 mientras los otros
   dos daban 10x18. Mientras el tamaño salga del contenido, tres contenidos distintos dan tres
   tamaños distintos.

   POR ESO ACÁ EL TAMAÑO ES EXPLÍCITO Y EL CONTENIDO NO PARTICIPA: `width`/`height` del token y
   `padding: 0`. El `--bs-btn-font-size` se ata a `--fuente-de-control` para que el glifo siga la
   tipografía de los controles, pero ya no decide el tamaño de la caja — que es justo la
   dependencia que AC10 viene a cortar.

   EL NÚMERO NO ESTÁ ACÁ: sale de `--ancho-del-boton-anexo` (`bootstrapTokenizado.css`, § 1), que
   es el mismo que lee la reserva de espacio del § de abajo. El porqué del reparto está escrito
   allá. */
/* EL ALTO SE SEPARÓ DEL ANCHO — reportado por el usuario mirando Nuevo Pedido después de que esta
   spec cerrara: "el botón de + está más grande que el input de alto".

   MEDIDO sobre el DOM real de esa pantalla: el `+` de agregar daba `38` de alto contra `31` del
   input y `31` de la lupa. Y no era sólo feo: ERA ÉL EL QUE ESTIRABA LA FILA. Con el `+` en 38 la
   fila externa medía 64, siete más que su contenido, y ese sobrante es el que dejaba al bloque de
   valores fuera de eje. Bajándolo a 31 la fila queda en 57 y los bordes coinciden solos.

   POR QUÉ NO ALCANZABA CON DARLE `.btn-anexo-de-control`: ese botón lleva `w-100` (ocupa el ancho de
   su columna), y aquella clase fija ALTO Y ANCHO al mismo token. Serviría de casualidad —la utilidad
   `.w-100` de Bootstrap trae `!important` y le ganaría al `width` de acá—, pero apoyarse en esa
   colisión es frágil y no queda declarado en ningún lado.

   Por eso la mitad que dice "este botón mide lo mismo de alto que un control" vive ahora en su
   propio selector, y `.btn-anexo-de-control` le suma la mitad cuadrada. El alto sigue teniendo UN
   SOLO origen —`--ancho-del-boton-anexo`— y no dos reglas que se desincronicen (Q2). */
.btn-anexo-de-control,
.btn-alto-de-control {
  height: var(--ancho-del-boton-anexo);
  padding: 0;
  display: inline-flex;
  align-items: center;
  justify-content: center;
  line-height: 1;
  --bs-btn-font-size: var(--fuente-de-control);
}

.btn-anexo-de-control {
  flex: 0 0 auto;
  width: var(--ancho-del-boton-anexo);
}

/* EL RECUADRO QUE ALOJA UN CHECK O UN RADIO, A LA ALTURA DE UN CONTROL.

   Reportado por el usuario en Cuenta Corriente: "el input de checkbox tiene un alto mayor al
   correspondiente a los demás inputs". Medido sobre el marcado real: 40px contra los 32 de un
   `.form-control`.

   Eran DOS excesos sumados, y por eso sacar uno solo no alcanzaba (medido: quedaba en 36):
     1. El recuadro llevaba `input-group-text` Y `form-control` a la vez — dos clases que declaran su
        propio padding, su propio borde y su propio fondo. Una sola alcanza, y la que corresponde es
        `.form-control`, que es la que le da a todo el resto de los controles su altura y su fondo.
     2. El `.form-check` de adentro trae `min-height: 1.5rem` de Bootstrap, pensado para cuando el
        check vive suelto en un formulario. Adentro de un recuadro que ya tiene su propia altura, ese
        mínimo sólo empuja.

   Medido con las dos cosas: 31px, contra los 32 de un `.form-control`. La diferencia de 1px es la
   caja de línea de un checkbox contra la de un `<input type=text>`, y no se fuerza con un valor
   propio: hacerlo sería clavar un número que se desincroniza el día que cambie `--fuente-de-control`.

   El `margin-bottom` también se neutraliza: Bootstrap le da `.125rem` al `.form-check` para separarlo
   del siguiente en una lista, y acá no hay siguiente. */
.control-con-check .form-check {
  min-height: 0;
  margin-bottom: 0;
}

/* spec-20260915-002-lucayuvdev (AC12b, "forma D") — EL CAMPO QUE ALOJA A SU BOTÓN ANEXO ENCIMA, Y
   LA DEPENDENCIA QUE NO SE PUEDE ESCRIBIR EN UN SOLO LUGAR.

   El campo de % Dto. medía 34px menos que sus tres hermanos de la fila (108.7 contra 142.7,
   sangría derecha 38 contra 4, reproducido en cinco anchos de viewport y en los dos temas) porque
   `DescuentoAnidado` le reservaba el espacio del botón `?` con un `paddingRight: 34` en el
   WRAPPER: esos 34px se los descontaba al input. Como Cantidad, % Dto. y Total llevan `text-end`,
   las tres cifras se alineaban al borde derecho de cajas de anchos distintos, que es el síntoma
   que el usuario reportó.

   LA FORMA D —elegida en el segundo gate, tras medir seis— devuelve el ancho completo al campo y
   le pasa la reserva a ÉL, como padding interno: el botón sigue absoluto sobre el borde derecho,
   se superpone a la CAJA del input pero no a la cifra. Las cinco formas descartadas y sus números
   están en el recuadro de AC12 de la spec; la que parecía obvia (un botón estático al lado, como
   la lupa) NO cumple: dentro de una columna de ancho fijo le descuenta el ancho al campo igual que
   el padding (113.5 contra 142.7).

   LOS `+5px` SON LA HOLGURA, MEDIDA Y NO ELEGIDA A OJO: con `99.99` cargado —el valor más ancho
   que el campo admite, `maxVal={100}`— la caja de contenido del input termina 5px antes de donde
   arranca el botón.

   ESTA ES LA MITAD QUE NO SE PUEDE UNIFICAR: el ancho del botón y esta reserva son UNA SOLA
   decisión repartida en dos reglas, y por eso las dos leen `--ancho-del-boton-anexo` en vez de un
   número propio. Si alguien agranda el botón, la reserva crece con él; si en cambio le escribiera
   un `width` propio al botón, la cifra vuelve a quedar tapada y nada lo avisa salvo el caso de
   AC12b. Queda dicho acá, que es donde se ve. */
.campo-con-boton-anexo {
  position: relative;
}

.campo-con-boton-anexo > .btn-anexo-de-control {
  position: absolute;
  right: 0;
  bottom: 0;
}

.campo-con-boton-anexo .form-control {
  padding-right: calc(var(--ancho-del-boton-anexo) + 5px);
}

/* spec-20260915-002-lucayuvdev (AC16) — ACÁ ESTABA `background: var(--surface)`, Y ERA LA MISMA
   DECISIÓN ESCRITA DOS VECES (Q2).

   `public/css/bootstrapTokenizado.css` (§ 1) ya tokeniza `--bs-body-bg: var(--surface)` en los dos
   alcances de tema, y de esa variable Bootstrap 5.3 cuelga `--bs-card-bg` —su propio comentario lo
   dice con todas las letras: "de `--bs-body-bg` cuelgan `--bs-card-bg`, `--bs-modal-bg`, …"—. O sea
   que la capa de tokens ya pintaba `.card` con `--surface`, y esta línea volvía a decidirlo desde
   otra hoja. El valor computado es el MISMO con y sin ella: medido `oklch(0.995 0.002 260)` en tema
   claro y `oklch(0.25 0.018 240)` en oscuro, en el documento de las cinco hojas.

   POR QUÉ IGUAL HUBO QUE SACARLA, y no es cosmética: mientras estuvo, el fondo de la tarjeta NO
   colgaba de la capa `--bs-*`, así que mutilar esa capa dejaba de cambiar el color de la tarjeta y
   el contra-control de `laCapaDeBootstrapAlcanzaElTemaOscuro.test.js` —el caso que prueba que su
   caso positivo no es vacuo— no podía distinguir nada. Medido: con esta línea puesta, el `.card`
   del documento ROTO (capa sólo en `:root`) computaba igual el `--surface` OSCURO, o sea que el par
   positivo/contra-control quedaba midiendo otra hoja. Sin ella, el documento roto congela la
   tarjeta en el tema claro, que es el defecto que aquel archivo vigila.

   LO QUE ESTA REGLA SIGUE DECIDIENDO —radio, sombra, transición y cursor— no lo toca ninguna capa
   de tokens y se queda tal cual. */
.card {
  border-radius: 4px;
  box-shadow: 0 6px 10px rgba(0, 0, 0, .08), 0 0 6px rgba(0, 0, 0, .05);
  transition: .3s transform cubic-bezier(.155, 1.105, .295, 1.12), .3s box-shadow, .3s -webkit-transform cubic-bezier(.155, 1.105, .295, 1.12);
  cursor: pointer;
}

.card:hover {
  box-shadow: 0 10px 20px rgba(0, 0, 0, 0.329), 0 4px 8px rgba(0, 0, 0, 0.247);
}

.cardCli {
  background-color: var(--bg);
  border: 1px solid var(--border);
  border-radius: 4px;
}

.cardCli:hover {
  box-shadow: 0 !important;
}

#toggle {
  transition: 0.3s ease-out;
}

.ancla{
  color: var(--text-muted);
  text-decoration: none;
  background-color: transparent;
  -webkit-text-decoration-skip: objects;
  transition: 0.5s all;
}

.ancla:hover {
  color: var(--text-faint);
  transition: 0.5s all;
}

.fontCliPoten {
  font-size: 90%;
}

.tarjeta-img-selected {
  border: 1px solid var(--text);
  border-radius: 10px;
}

.tarjeta-info-class div {
  width: 100%;
  text-align: center;
}

.tarjeta-info-class {
  border: 1px solid var(--border);
  border-radius: 0.25rem;
  padding: 0.75rem;
  margin-bottom: 0.5rem;
}

.selectPrecio {
  color: var(--text);
  background-color: var(--bg);
  border-color: var(--bg);
  display: inline-block;
  font-weight: 400;
  text-align: center;
  -webkit-user-select: none;
  -moz-user-select: none;
  -ms-user-select: none;
  user-select: none;
  border: 1px solid transparent;
  padding: 0.375rem 0.75rem;
  font-size: 1rem;
  line-height: 1.5;
  border-radius: 0.25rem;
  transition: color .15s ease-in-out, background-color .15s ease-in-out, border-color .15s ease-in-out, box-shadow .15s ease-in-out;
  height: 80%;
}

.fila {
  display: flex;
  align-items: center;
  justify-content: space-between;
  margin-bottom: 0.5rem;
}

.noView {
  display: none;
}

.titulo {
  font-weight: bold;
  margin-bottom: 0.25rem;
}

.descripcion {
  flex-basis: 35%;
}

.cuotas,
.monto {
  flex-basis: 15%;
  text-align: center;
}

@media (max-width: 1500px) {
  .fontCliPoten {
    font-size: 75%;
  }

}

@media (max-width: 890px) {
  .descarto {
    display: none;
  }

  .soloMobile {
    display: initial;
  }
}

@media (min-width: 798px) {
  .soloMobile {
    display: none;
  }
}

.listado td,
th {
  vertical-align: middle !important;
  padding: 2px !important;
}

.listado thead>tr {
  background-image: linear-gradient(to right, var(--surface), var(--border), var(--surface));
  border-bottom: 0px !important;
  color: var(--text-muted)
}


.fc-slats>table tbody tr:hover {
  background: var(--accent-tint);
  cursor: pointer;
}

.dropdown-submenu {
  position: relative;
}

.dropdown-submenu>.dropdown-menu {
  top: 0;
  left: 100%;
  margin-top: -6px;
  margin-left: -1px;
  -webkit-border-radius: 0 6px 6px 6px;
  -moz-border-radius: 0 6px 6px;
  border-radius: 0 6px 6px 6px;
}

.dropdown-submenu:hover>.dropdown-menu {
  display: block;
}

.dropdown-submenu>a:after {
  display: block;
  content: " ";
  float: right;
  width: 0;
  height: 0;
  border-color: transparent;
  border-style: solid;
  border-width: 5px 0 5px 5px;
  border-left-color: var(--border);
  margin-top: 5px;
  margin-right: -10px;
}

.dropdown-submenu:hover>a:after {
  border-left-color: var(--surface);
}

.dropdown-submenu.pull-left {
  float: none;
}

.dropdown-submenu.pull-left>.dropdown-menu {
  left: -100%;
  margin-left: 10px;
  -webkit-border-radius: 6px 0 6px 6px;
  -moz-border-radius: 6px 0 6px 6px;
  border-radius: 6px 0 6px 6px;
}

.tableFixHead {
  overflow-y: auto;
  height: 100px;
}

.tableFixHead thead th {
  position: sticky;
  top: 0;
  background-color: var(--surface) !important
}

/* Just common table stuff. Really. */
.fc-slats>table {
  border-collapse: collapse;
  width: 100%;
}

.fc-slats>th,
td {
  padding: 8px 16px;
}

.fc-slats>th {
  background: var(--border-soft);
}

input[type="date"]::-webkit-inner-spin-button {
  display: none;
  -webkit-appearance: none;
}

input::-webkit-outer-spin-button,
input::-webkit-inner-spin-button {
  -webkit-appearance: none;
  margin: 0;
}

.highlight {
  background-color: var(--accent-tint);
}


.hoverable:hover {
  background-color: var(--accent) !important;
  color: white !important;
}

.sorting:before,
.sorting_asc:before,
.sorting_desc:before,
.sorting:after,
.sorting_asc:after,
.sorting_desc:after {
  /* esconder las flechas de orden de las datatables pero seguir ordenando al hacerle clic a la columna */
  color: transparent;
}

.strong {
  font-weight: 700;
}

/* clases para "labels" en los filtros */

/* El `12px` que esta clase tenía literal es el valor que ahora vive en `--fuente-de-control` (AC1,
   ver la cabecera de esta hoja). `.lb-md`/`.lb-lg` se quedan con su literal a propósito: no son el
   tamaño de un control, son dos escalones más grandes que ningún AC ata a nada. */
.lb-sm {
  font-size: var(--fuente-de-control);
  margin-bottom: 4px;
  font-weight: bold;
  color: var(--text-muted);
}

/* Un campo de formulario con `showLabel: false` (checkbox, selector). Las filas de un formulario no
   tienen `row-gap` (`--separacion-de-filas-de-formulario` es 0): a los demás campos los separa su
   label. Sin él, el recuadro quedaba pegado al de arriba. 8px a ojo, pedido del usuario: los 4px
   del `margin-bottom` del label quedaban cortos. */
.campo-sin-label {
  padding-top: 8px;
}

.lb-md {
    font-size: 16px;
    margin-bottom: 4px;
    font-weight: bold;
    color: var(--text-muted);
}

.lb-lg {
    font-size: 20px;
    margin-bottom: 4px;
    font-weight: bold;
    color: var(--text-muted);
}

.user-name:hover {
  color: var(--accent-tint);
}

.user-name:hover {
  color: var(--accent-tint);
}

.dropdown:hover .dropdown-menu {
  display: block;
  margin-top: 0;
  /* remove the gap so it doesn't close */
}

.panel-title {
  position: relative;
}

.panel-title::after {
  content: "\f107";
  color: var(--text);
  right: 10px;
  position: absolute;
  font-family: "Font Awesome 5 Free";
  font-weight: 900;
  font-size: 1.0em;
}

.panel-title[aria-expanded="true"]::after {
  content: "\f106";
  font-weight: 900;
}

.panel-heading-full.panel-heading {
  padding: 0;
}

.panel-heading-full .panel-title {
  padding: 10px 15px;
}

.panel-heading-full .panel-title::after {
  top: 10px;
  right: 15px;
}

/* spec-20260904-005-lucayuvdev (AC6) — el botón flotante de WhatsApp del layout autenticado. El
 * verde es MARCA DE TERCEROS y el blanco del ícono es texto claro sobre esa marca: los dos quedan
 * como literal a propósito (excepciones con motivo del AC), porque un `--success` del tema dejaría
 * de leerse como WhatsApp. */
.float {
  position: fixed;
  width: 60px;
  height: 60px;
  background-color: #25d366;
  color: #FFF;
  border-radius: 50px;
  text-align: center;
  font-size: 30px;
  box-shadow: 2px 2px 3px #999;
  z-index: 100;
}

.my-float {
  margin-top: 16px;
}

/* spec-20260904-005-lucayuvdev (AC6) — el hover no tiene un token de "tinte fuerte" en la capa de
 * color (research § 6): el fondo del hover queda en el mismo `--accent-tint` que el estado base y la
 * diferencia la marca el borde, que pasa de `--border` a `--accent`. Es una decisión de diseño menor
 * y declarada, no un mapeo del inventario. */
.btn-primary-custom-awa {
  background-color: var(--accent-tint);
  border-color: var(--border);
  color: var(--accent-tint-text)
}

.btn-primary-custom-awa:hover {
  background-color: var(--accent-tint);
  border-color: var(--accent);
  color: var(--accent-tint-text)
}


/* spec-20260904-005-lucayuvdev (AC6, D8) — `.btn-success-custom-awa` NO TIENE CONSUMIDORES.
 *
 * Los dos verdes con alfa son el verde de WhatsApp (`#25d366`, el mismo de `.float`), así que se
 * exceptúan como MARCA DE TERCEROS en vez de mandarse a `--success`, y el blanco del texto queda
 * como "texto claro sobre color de marca". La clase no se borra: ningún test la ejecuta, y borrar
 * código sin red de test no es de esta spec (queda registrada en `memory/tech-debt.md`). Sólo el
 * borde —que sí es neutro— pasa a token. */
.btn-success-custom-awa {
  background-color: #25d366a8;
  border-color: var(--border);
  color: #ffffff;
}

.btn-success-custom-awa:hover {
  background-color: #07a741cb;
  border-color: var(--border);
  color: #ffffff;
}


div.pac-container {
  z-index: 1050 !important;
}

.est-alerta {
  border-style: solid;
  border-color: var(--warning);
  border-radius: 5px;
}

input.error {
  color: var(--danger-text);
  background-color: var(--danger-tint);
  border-color: var(--danger);
}

/* spec-20260904-005-lucayuvdev (AC6) — `.popover` tiene TRES escritores fuera de Bootstrap: esta
 * regla (el rosa de error), `resources/css/Producto.css:1` (`white !important`, que gana desde que
 * `NuevoComprobante` cargó su hoja) y el gemelo tokenizado de `public/css/bootstrapTokenizado.css`.
 * Los tres se tokenizan in place: sin cobertura ejecutable de cuál gana en cada pantalla, unificar
 * el hogar sería refactor sin red (queda en `memory/tech-debt.md`). */
.popover {
  background: var(--danger-tint);
}

.popover.bottom .arrow:after {
  border-bottom-color: var(--danger-tint);
}

/* spec-20260831-004-lucayuvdev (AC1b) — EL CONTENIDO DEL ACCESO ENTRA CON UN FUNDIDO, NO DE GOLPE.
 *
 * `Screens/PantallaLogin.jsx` reemplaza el indicador de carga por el formulario en cuanto los
 * catálogos del tenant resuelven, y ese reemplazo era un intercambio instantáneo: dos nodos
 * distintos, uno que desaparece y otro que aparece en el mismo tick.
 *
 * Es una ANIMACIÓN y no una transición a propósito: una transición necesita un valor de partida
 * sobre un nodo que ya existía, y acá el nodo que entra se acaba de crear. Sin `fill-mode`, si el
 * motor de animación no corriera el elemento queda en su opacidad normal en vez de invisible.
 *
 * Vive en esta hoja —y no en el bloque `<style>` de las vistas de acceso— porque las tres
 * plantillas que pueden hospedar el formulario la enlazan: login, cambio de clave y el layout
 * autenticado, donde `Shell/ReLoginEnElLugar.jsx` monta la misma pantalla sobre la sesión vencida. */
@keyframes aparicion-de-acceso {
  from {
    opacity: 0;
  }

  to {
    opacity: 1;
  }
}

.aparicion-de-acceso {
  animation: aparicion-de-acceso 0.28s ease-out;
}

/* spec-20260831-004-lucayuvdev (AC10) — ANCHO DE LAS MODALES `size="xl"`, QUE BOOTSTRAP 4.0.0 NO TRAE.
 *
 * El Bootstrap que sirven las cuatro plantillas es `public/bootstrap/css/bootstrap.min.css`, v4.0.0,
 * y `.modal-xl` llegó recién en 4.2 (el `bootstrap.css` v4.4.1 que también está en el repo NO lo
 * enlaza ninguna vista). O sea que ninguna hoja servida lo declaraba… salvo
 * `resources/js/components/Tienda/styles.css`, que se inyectaba en TODOS los documentos vía
 * `style-loader`. Las ~10 modales `size="xl"` del resto de la aplicación (Buscadores, Fondos,
 * Informes de Pago, Órdenes de Producción) sacaban su ancho de ahí sin que nadie lo supiera.
 *
 * Al aislar la hoja de la tienda, esta regla se mudó acá TAL CUAL —mismo breakpoint, mismo ancho—
 * para que ninguna de esas modales cambie de tamaño. No es una regla del módulo Tienda: es un
 * parche de la aplicación a una versión de Bootstrap que se quedó corta. */
@media (min-width: 1100px) {
  .modal-xl {
    max-width: 1200px;
  }
}

/* spec-20260914-001-lucayuvdev (AC10/AC13) — ACÁ ESTABA LA COPIA A MANO DEL SPINNER, Y SE FUE.
 *
 * QUÉ HABÍA: `@keyframes spinner-border` (con su gemelo `-webkit-`), `.spinner-border` y
 * `.spinner-border-sm`, copiados TAL CUAL de Bootstrap 4.6 por `spec-20260901-001` (AC2/AC3). El
 * motivo era que el Bootstrap servido era la **4.0.0** y esa clase llegó recién en la 4.2, así que
 * el `<span class="spinner-border spinner-border-sm">` que `Common/BotonConCarga.jsx:44` y
 * `Shell/Sidebar.jsx` emiten desde `spec-20260827-003` no lo dibujaba NADIE.
 *
 * POR QUÉ SE FUE, Y POR QUÉ AHORA: aquel bloque dejaba escrita su propia condición de salida —"SI
 * ALGÚN DÍA SE ACTUALIZA EL VENDORED A 4.2+, ESTO SE QUITA en vez de mantenerse: serían dos lugares
 * donde se cambia la misma decisión (`Q2`)"— y nombraba el caso que iba a avisar el día que pasara.
 * Pasó: AC10 de esta spec reemplazó el servido por la **5.3.2**, que declara las tres piezas, y
 * `SpinnerDibujableEnHojaServidaTest::test_ac2_la_clase_no_existe_como_regla_en_el_bootstrap_vendored_que_las_plantillas_sirven`
 * se puso rojo diciendo exactamente esto. El borrado no es una limpieza oportunista: es la condición
 * de salida que la propia spec anterior escribió, ejecutada.
 *
 * QUIÉN LO CUSTODIA AHORA: el mismo archivo de test, que sigue midiendo sobre las REGLAS SERVIDAS
 * que el spinner se dibuje —ahora desde `bootstrap/css/bootstrap.min.css`— y no desde dos lugares. */

/* spec-20260903-003-lucayuvdev (AC11) — el menú de acciones de `TablaGenerica`, que Bootstrap 4
 * pintaría blanco/negro fijo con su `.dropdown-menu` de fábrica.
 *
 * POR QUÉ EL SELECTOR ES DE UN SOLO NIVEL Y NO DE DESCENDENCIA. `TablaGenerica` porta ese menú a
 * `document.body` (`DropdownMenuPortal`) para escapar del stacking context de la celda sticky, así
 * que el nodo no cuelga del `.page-wrapper`. Una `.tema-oscuro .dropdown-acciones` habría dependido
 * de dónde vive la clase del tema; ésta no depende de nada.
 *
 * ACTUALIZADO POR spec-20260904-005-lucayuvdev (AC1/AC6): el portador de `tema-oscuro` pasó a ser el
 * `<body>` en los dos documentos, así que el portal SÍ hereda los custom properties por ancestría y
 * el parche que hacía viajar la clase hasta este nodo (`TablaGenerica.jsx` →
 * `clasesDelMenuDeAcciones`) se retiró. Esta regla se conserva igual: lo que resuelve no es la
 * herencia del token sino el color de fábrica de `.dropdown-menu`, que sigue siendo blanco fijo.
 *
 * Le gana al `.dropdown-menu` de fábrica por orden de enlace: `estilosAWA.css` se enlaza después de
 * `bootstrap.min.css` (`resources/views/React/main.blade.php:157` contra `:132`) con la misma
 * especificidad, así que no hace falta `!important` ni subir el selector. */
.dropdown-acciones {
  background-color: var(--surface);
  color: var(--text);
  border: 1px solid var(--border);
}

/* spec-20260921-001-estefano99 (CORRECCIÓN F, F.2) — la animación de shimmer del primitivo
 * `Common/Skeleton.jsx` se QUEDA en esta hoja general (no se muda a `public/css/dashboard.css` con
 * `.tarjeta-acceso-rapido`, ver ese archivo). Criterio explícito de F.2: una regla exclusiva de una
 * pantalla va a la hoja de esa pantalla; una regla de un componente COMPARTIDO, pensado para reusarse
 * fuera del dashboard (`Skeleton.jsx` ya lo declara así, AC26 — "no sabe qué es una tarjeta ni conoce
 * ninguna sección"), se queda en la hoja general. Alterna opacidad sobre el fondo `var(--border-soft)`
 * que el propio componente ya declara inline — la animación sólo anima la opacidad, nunca el color,
 * así que no hay ningún literal acá tampoco. */
@keyframes shimmer {
  0% {
    opacity: 1;
  }

  50% {
    opacity: 0.5;
  }

  100% {
    opacity: 1;
  }
}

.awa-skeleton-shimmer {
  animation: shimmer 1.4s ease-in-out infinite;
}