/* ============================================================
   HUF — Shell del AdminPortal (.hd-shell) + composición canónica
   de pantalla (.hd-page) — HVL §8.1
   ------------------------------------------------------------
   Dos responsabilidades separadas a propósito:

   .hd-shell  → mecánica de layout de la SUPERFICIE: sidebar + columna
                principal, colapso a 72px, drawer off-canvas en móvil.
   .hd-page   → composición canónica de la PANTALLA: las cinco regiones
                de HVL §8.1 (header · línea de estado · toolbar ·
                contenido · footer contextual). Toda pantalla del
                producto usa esta estructura, sin excepción.

   Se separan porque otra superficie (POS, kiosco) podría montar un
   shell distinto y seguir usando las mismas cinco regiones.

   Reglas duras que este archivo implementa:
   - HVL §8.4: contenido A SANGRE, anclado a la izquierda. Prohibida la
     columna centrada con max-width — era una violación real que traía
     este archivo (`max-width:1400px; margin-inline:auto`), corregida en
     la revisión 2.
   - HVL §8.2: el footer de acciones NO es chrome permanente. Existe en
     el DOM pero no ocupa altura hasta que algo lo activa.
   - HVL §7.2/§8.1: la ventana no scrollea; scrollea la región de
     contenido. Se relaja bajo 992px.
   - HVL §8.3: cuando falta espacio cede el chrome, nunca las filas.

   Consumo: <hd-shell> y <hd-page> (una vista nunca escribe estas
   clases a mano — HVL §6, "Interfaz pública oficial").
   Ejemplos → docs/hednora-ui-framework-guide.md §Shell.
   ============================================================ */

/* `height`, no `min-height`: la cáscara tiene que ser una caja de alto DEFINIDO
   o nada de lo que hay dentro puede scrollear por su cuenta.

   Con `min-height: 100vh` la rejilla crecía con su contenido (1040px medidos en
   una ventana de 620), y ese alto se propagaba hacia abajo: `.hd-page` resolvía
   su `height: 100%` contra los 1040 en vez de contra la ventana, con lo que
   `.hd-page__content` nunca desbordaba y su `overflow-y: auto` quedaba INERTE.
   Resultado: la ventana scrolleaba y se llevaba cabecera, total y footer de
   acciones fuera de la pantalla — lo contrario de HVL §8.1. No era un defecto de
   una pantalla: ninguna de las 82 scrolleaba por dentro. Se reportó desde Caja,
   donde más duele porque es la única con footer de acciones.

   `dvh` y no `vh`: en móvil la barra de direcciones entra y sale, y `vh` deja
   una franja bajo el pliegue. Bajo 992px esto se revierte a `auto` — ahí la
   ventana SÍ scrollea, por diseño (HVL §7.2). */
.hd-shell {
    display: grid;
    grid-template-columns: var(--hd-size-sidebar) 1fr;
    height: 100dvh;
    background: var(--hd-theme-bg);
    color: var(--hd-theme-text);
}

/* La transición solo se activa tras el primer paint (clase agregada por JS
   en window.load) — así cada recarga pinta el sidebar ya colapsado/expandido
   sin animación, y el usuario solo ve la transición al hacer clic en el
   toggle. */
.hd-shell--anim-ready {
    transition: grid-template-columns var(--hd-motion-standard) var(--hd-ease);
}

.hd-shell--collapsed {
    grid-template-columns: var(--hd-size-sidebar-collapsed) 1fr;
}

/* Columna principal. `min-width: 0` evita que una tabla ancha reviente la
   rejilla; `min-height: 0` permite que .hd-page__content scrollee en vez de
   empujar la página (sin él, un hijo de grid nunca encoge por debajo de su
   contenido). */
.hd-shell__main {
    display: flex;
    flex-direction: column;
    min-width: 0;
    min-height: 0;
    /* Sin `height` propio: la fija `.hd-shell` (`100dvh`) y el ítem de grid la
       hereda por el `stretch` de la rejilla. Tenerla dos veces era duplicar la
       fuente de verdad, y la copia decía `100vh` — la variante que en móvil deja
       una franja bajo la barra de direcciones. */
    /* `auto` y no `hidden`: red de seguridad. Hoy **toda** pantalla que se
       renderiza acá dentro usa `<hd-page>` y trae su propio scroll interno, así
       que `auto` no se activa nunca — comprobado en las 58 del barrido. Pero una
       pantalla nueva escrita sin `<hd-page>` quedaría recortada con `hidden`, y
       ese fallo es mudo: no hay error, solo contenido inalcanzable. Con `auto`
       degrada a scrollear acá dentro, que es feo pero usable. */
    overflow-y: auto;
    overflow-x: hidden;
}

/* El padding de página (24px, HVL §8.4) lo pone cada REGIÓN, no la columna.
   Ponerlo acá arriba obligaba a la línea de estado —que la ley manda **a
   sangre**— a arrancar 24px adentro: medido a 1366px con el sidebar terminando
   en 280, iba de 304 a 1342 en vez de 280 a 1366. Y como las regiones también
   traen el suyo, el contenido acumulaba 48px. Ver ADR-039.

   Esta regla es la pareja de la red de seguridad de arriba, y hoy no aplica a
   nadie: las pantallas del repositorio sin `<hd-page>` —`Login`,
   `Consentimiento`, `Acceso/Index`, `Public/Cuenta/RecuperarPassword`,
   `Public/Suscripcion/Vencida`— declaran `Layout = null` y traen su propio
   `<body>`, así que **no pasan por acá**; `Index` solo redirige y no llega a
   renderizar. Existe para que una pantalla nueva escrita sin `<hd-page>` no nazca
   pegada a los bordes mientras se la migra. */
.hd-shell__main > :not(.hd-page) {
    padding: var(--hd-space-5);
}

.hd-shell__backdrop {
    display: none;
}

/* ELIMINADA `.hd-shell__content` (ADR-039).

   Era la región de contenido "plana", anterior a la composición canónica de
   HVL §8.1, y su propio comentario decía que debía desaparecer al adoptar
   `<hd-page>`. Nunca desapareció: `_Layout.cshtml` la emitía y las 82
   pantallas pasaban por ella, incluidas las 64 que sí adoptaron `<hd-page>`.
   Convivían dos columnas principales —esta y `.hd-shell__main`, la canónica,
   que no usaba nadie— y la que corría era la legada. Leer este archivo daba a
   entender lo contrario, que es como ADR-038 se llevó tres horas de
   diagnóstico. Ahora el layout emite `<hd-shell-main>` y queda una sola. */

/* ============================================================
   .hd-page — las cinco regiones de HVL §8.1
   ============================================================ */

/* Flex en columna, NO grid con filas fijas.
   La primera versión usaba `grid-template-rows: auto auto auto minmax(0,1fr)
   auto`, que asigna la fila elástica POR POSICIÓN. Basta que una pantalla
   incluya un elemento más —p. ej. <hd-context-path> como hijo directo, que es
   justo lo que hace el patrón de listado— para que todo se corra y la fila
   elástica se la quede la toolbar: el resultado eran dos franjas muertas de
   ~180px entre regiones. Detectado en la verificación de Empresas.
   Con flex, la región de contenido crece porque lo pide ella (`flex: 1`), no
   porque le toque el cuarto lugar. */
.hd-page {
    display: flex;
    flex-direction: column;
    height: 100%;
    min-height: 0;
}

/* Las regiones de chrome no crecen ni encogen: su alto es el que fija la ley.
   `min-width: 0` evita el desborde clásico —un hijo flex tampoco encoge por
   debajo del ancho mínimo de su contenido, así que una tabla ancha estiraría
   su región y con ella la ventana (HVL §8.1, "la ventana no scrollea"). */
.hd-page > * {
    flex-shrink: 0;
    min-width: 0;
}

/* ── Región A · Header ─────────────────────────────────────────
   Título + ruta de contexto + UNA acción primaria (HVL §8.4). No
   scrollea: es chrome.

   Se apunta al COMPONENTE (`.hd-page-header`, que es lo que emite
   `<hd-page-header>`) y no a un `.hd-page__header` que nadie escribe: esa
   clase de región existía acá con estos mismos valores y **no la producía
   ningún TagHelper**, así que la regla nunca corrió. El aire del encabezado se
   lo daba el padding de la columna, y al quitarlo el título quedaba contra el
   techo y la acción primaria pegada al borde derecho (visto en navegador).
   El `>` importa: un toolbar o un encabezado anidado dentro del contenido no
   es la región y no debe recibir padding de página. */
.hd-page > .hd-page-header {
    padding: var(--hd-space-5) var(--hd-space-5) var(--hd-space-4);
    flex-shrink: 0;
}

/* La ruta de contexto es el tercer hijo directo que puede abrir la pantalla, y
   tampoco traía padding propio: se lo daba la columna, y al quitarlo quedaba
   pegada al techo (medida: 7px del borde superior). Sin cierre inferior — lo
   pone el header que viene debajo. */
.hd-page > .hd-context-path {
    padding: var(--hd-space-5) var(--hd-space-5) 0;
    flex-shrink: 0;
}

/* Cuando la ruta abre la pantalla, el aire superior ya lo puso ella: si el
   header repitiera el suyo se acumularían 48px y el título se hundiría. */
.hd-page > .hd-context-path + .hd-page-header {
    padding-top: var(--hd-space-2);
}

/* ── Región B · Línea de estado ────────────────────────────────
   48px, una sola fila, A SANGRE, sin tarjetas (HVL §7.2 zona A).
   Es la misma línea de estado que la zona A del Workspace: se declara
   una sola vez, nunca dos (HVL §8.1, nota de anidamiento). */
.hd-page__status {
    display: flex;
    align-items: center;
    gap: var(--hd-space-5);
    height: var(--hd-size-topbar);
    padding: 0 var(--hd-space-5);
    background: var(--hd-color-bg-secondary);
    border-block: 1px solid var(--hd-color-border);
    font-size: var(--hd-text-meta);
    color: var(--hd-theme-text-muted);
    flex-shrink: 0;
}

/* ── Región C · Toolbar ────────────────────────────────────────
   El componente vive en toolbar.css; aquí solo su lugar en la rejilla.
   Sin borde propio: la línea de estado (arriba) o el encabezado de la
   tabla (abajo) ya separan — ley de bordes anidados, HVL §5.2. */
.hd-page > .hd-toolbar {
    padding: var(--hd-space-4) var(--hd-space-5) var(--hd-space-3);
    flex-shrink: 0;
}

/* ── Región D · Contenido ──────────────────────────────────────
   El objeto dominante. Scroll INTERNO, no de ventana (HVL §8.1).
   A sangre y anclado a la izquierda: sin max-width, sin auto-margin. */
.hd-page__content {
    /* La única región que crece: ocupa todo el alto disponible, y por eso
       la pantalla no termina donde termina su último elemento sino donde
       termina la ventana (HVL §8.5 regla 1). */
    flex: 1 1 auto;
    display: flex;
    flex-direction: column;
    padding: 0 var(--hd-space-5) var(--hd-space-5);
    overflow-y: auto;
    /* Red de seguridad: si un hijo no puede encoger más (una tabla ancha),
       el scroll horizontal queda contenido AQUÍ y no llega a la ventana.
       No es la solución prevista para tablas en móvil —HVL §6.7 manda
       convertirlas en lista de fichas, y eso se resuelve por pantalla según
       su contenido— pero garantiza que ninguna pantalla pueda romper la
       regla de "la ventana no scrollea". */
    overflow-x: auto;
    min-height: 0;
}

/* La región no lleva padding superior (lo pone el chrome de arriba), así
   que el primer bloque de contenido necesita su propio aire. Vive aquí y
   no en la pantalla: una alerta de resultado aparece en casi todas, y
   dejarlo a la vista significaba un style="margin:…" repetido por
   archivo, con valores que ya divergían entre ellos. */
.hd-page__content > .hd-alert {
    margin: var(--hd-space-1) 0 var(--hd-space-4);
}

/* Un <form> que envuelve toda la región de contenido —necesario cuando la
   pantalla se apoya en el footer contextual, que se activa con
   `data-hd-dirty-track` sobre un formulario (§8.2)— es un contenedor
   TÉCNICO: no debe aparecer en el reparto vertical. Sin esto, el form se
   queda con la altura de su contenido y la región deja de llegar al fondo
   de la ventana, que es exactamente lo que prohíbe §8.5 regla 1. */
.hd-page__content > form {
    flex: 1 1 auto;
    display: flex;
    flex-direction: column;
    min-height: 0;
}

/* Cuando el contenido es una tabla que gestiona su propio scroll, la
   región cede el suyo para no anidar dos scrolls. */
/* "Flush" es sin padding INTERNO: el panel de la tabla llega a los bordes de
   la región para que la tabla vaya a sangre dentro de él (HVL §8.1 región D).
   Nunca quiso decir que el panel tocara la ventana — el margen de página se lo
   daba la columna, y al quitarlo el panel quedaba pegado al borde. Conserva el
   padding de página y sigue sin poner nada entre región y panel. */
.hd-page__content--flush {
    padding: 0 var(--hd-space-5) var(--hd-space-5);
    overflow: hidden;
}

/* ── Región E · Footer de acciones ─────────────────────────────
   HVL §8.2: CONTEXTUAL, NUNCA PERMANENTE. Aparece solo cuando hay
   selección múltiple activa o un formulario con cambios sin guardar.
   Por defecto no existe visualmente NI ocupa altura de rejilla — de
   otro modo se comería los 56px que HVL §8.3 reserva a las filas. */
.hd-page__footer {
    display: none;
}

.hd-page__footer.is-active {
    display: flex;
    align-items: center;
    justify-content: space-between;
    gap: var(--hd-space-4);
    height: var(--hd-size-footer);
    padding: 0 var(--hd-space-5);
    background: var(--hd-color-bg-secondary);
    border-top: 1px solid var(--hd-color-border);
    animation: hd-footer-in var(--hd-motion-standard) var(--hd-ease);
}

.hd-page__footer-summary {
    font-size: var(--hd-text-meta);
    color: var(--hd-theme-text-muted);
    font-variant-numeric: tabular-nums;
}

.hd-page__footer-actions {
    display: flex;
    align-items: center;
    gap: var(--hd-space-2);
}

@keyframes hd-footer-in {
    from { transform: translateY(100%); }
    to   { transform: translateY(0); }
}

@media (prefers-reduced-motion: reduce) {
    .hd-page__footer.is-active { animation: none; }
}

/* ============================================================
   Móvil — bajo 992px la ventana vuelve a scrollear normalmente
   (HVL §7.2: "en < 992px esta regla se relaja")
   ============================================================ */

@media (max-width: 991.98px) {
    .hd-shell {
        grid-template-columns: 1fr;
        /* La topbar solo existe aquí, y al aparecer se convierte en una
           SEGUNDA fila del grid. Con `align-content` en su valor inicial
           (equivalente a stretch) el sobrante entre el alto del contenido y
           el `min-height: 100vh` se reparte entre las dos filas auto: la
           topbar conserva sus 48px y el resto de su fila queda en blanco.
           Eso abría una franja muerta bajo la topbar en toda pantalla más
           corta que la ventana —113px medidos en Comprobantes a 390×844—.
           Anclando las filas al inicio, el sobrante se lo queda la última
           fila, que es la de contenido. */
        align-content: start;
    }

    /* El colapso de escritorio no aplica en móvil — el drawer off-canvas
       (topbar + botón hamburguesa) ya resuelve mostrar/ocultar. */
    .hd-shell--collapsed {
        grid-template-columns: 1fr;
    }

    /* La cáscara suelta su alto definido junto con el resto: acá la ventana
       vuelve a ser el scroller, así que ni la rejilla ni la región de contenido
       deben acotar nada. `min-height` y no `height` para que una pantalla corta
       siga pintando el fondo hasta abajo. */
    .hd-shell {
        height: auto;
        min-height: 100vh;
    }

    .hd-shell__main {
        height: auto;
        overflow: visible;
    }

    .hd-page {
        height: auto;
    }

    .hd-page__content {
        overflow-y: visible;
    }

    .hd-shell__main {
        min-height: auto;
        overflow-y: visible;
        overflow-x: visible;
    }

    .hd-shell__main > :not(.hd-page) {
        padding: var(--hd-space-4);
    }

    .hd-page > .hd-page-header,
    .hd-page > .hd-context-path,
    .hd-page > .hd-toolbar {
        padding-inline: var(--hd-space-4);
    }

    .hd-page__content,
    .hd-page__content--flush {
        padding-inline: var(--hd-space-4);
    }

    /* La línea de estado deja de ser una fila rígida de 48px: a 390px sus
       cifras no caben en una sola línea y quedaban cortadas por abajo
       (contenido de 51px dentro de una caja de 48). Envuelve y crece lo que
       necesite — sigue siendo chrome de una sola pieza, no contenido. */
    .hd-page__status {
        padding-inline: var(--hd-space-4);
        padding-block: var(--hd-space-2);
        height: auto;
        min-height: var(--hd-size-topbar);
        flex-wrap: wrap;
        gap: var(--hd-space-2) var(--hd-space-4);
    }

    /* En móvil el footer contextual se ancla al viewport: la página
       scrollea, así que un footer en flujo quedaría fuera de vista. */
    .hd-page__footer.is-active {
        position: sticky;
        bottom: 0;
        z-index: var(--hd-z-dropdown);
    }

    .hd-topbar {
        position: sticky;
        top: 0;
        z-index: var(--hd-z-dropdown);
    }

    .hd-sidebar {
        position: fixed;
        top: 0;
        left: 0;
        width: min(85vw, 20rem);
        /* Mismo bug que .hd-modal (ver modals.css): drawer fijo con altura
           resuelta contra el viewport grande, tapado por la barra de
           direcciones en Android/iOS reales. `100svh` lo corrige. */
        height: 100vh;
        height: 100svh;
        max-height: none;
        overflow-y: auto;
        transform: translateX(-100%);
        transition: transform var(--hd-motion-standard) var(--hd-ease);
        /* Por ENCIMA de su velo. Ver --hd-z-drawer en tokens.css: mientras
           el drawer usó --hd-z-modal-backdrop y el velo --hd-z-modal, el
           velo lo tapaba y el menú era inoperable bajo 992px. */
        z-index: var(--hd-z-drawer);
    }

    .hd-sidebar.is-open {
        transform: translateX(0);
    }

    /* En móvil, el sidebar es un drawer completo (280px, se abre/cierra) —
       el colapso a 72px es una función exclusiva de escritorio. */
    .hd-sidebar__close {
        display: inline-flex;
    }

    .hd-sidebar__collapse-toggle {
        display: none;
    }

    .hd-shell__backdrop {
        display: block;
        position: fixed;
        inset: 0;
        /* Por DEBAJO del drawer: su trabajo es oscurecer la pantalla y
           capturar el toque FUERA del menú, no encima de él. */
        z-index: var(--hd-z-drawer-backdrop);
        background: rgba(8, 15, 26, 0.72);
        opacity: 0;
        pointer-events: none;
        transition: opacity var(--hd-motion-standard) var(--hd-ease);
    }

    .hd-shell__backdrop.is-open {
        opacity: 1;
        pointer-events: auto;
    }
}

/* En escritorio el shell del AdminPortal no necesita topbar: la navegación
   vive en el sidebar y la línea de estado la pone cada pantalla (región B).
   ACOTADO al shell a propósito: la regla iba suelta sobre `.hd-topbar` y el
   portal del cliente (_ClienteLayout) y el menú QR (_MenuLayout) usan ese
   mismo componente como su ÚNICA cabecera, sin shell ni sidebar debajo. Se
   quedaban sin marca, sin acciones y sin cerrar sesión en cuanto la ventana
   pasaba de 992px. */
@media (min-width: 992px) {
    .hd-shell > .hd-topbar {
        display: none;
    }
}

/* ============================================================
   Alturas cortas — cede el CROMO, nunca las filas (HVL §8.3)
   ------------------------------------------------------------
   Esta hoja declaraba esa ley en su cabecera desde el principio y solo la
   implementaba para el ANCHO. Faltaba el otro eje, y es el que escasea en los
   equipos donde de verdad se opera: un POS, un portátil de 768, una ventana a
   media pantalla.

   MEDIDO el 2026-09-20 (Playwright, 5 pantallas × 7 alturas, tenant laparrilla):
   el cromo era **exactamente el mismo número en las siete alturas** — Menú 285px
   lo mismo a 1040 que a 560, Inventario 277, Comprobantes y Mesas 229, Caja 142.
   A 560 de alto eso es el 51 % de la ventana gastado antes de la primera fila:
   3 filas visibles de 22. Se reportó desde un POS de cliente, donde el operador
   lo estaba tapando a mano poniendo el navegador al 80 %, a costa de dejar todo
   el texto diminuto en una pantalla táctil.

   POR QUÉ `max-height` Y NO DETECTAR EL DISPOSITIVO. La media query se evalúa en
   píxeles CSS, que es justo la unidad que decide cuánto contenido cabe. El zoom
   del navegador cambia esos píxeles, así que el escalón se adapta solo: al 80 %
   el POS tiene 960px CSS y no se activa —porque a ese zoom ya le caben las
   filas—, y al 100 % tiene 768 y sí. No hay que conocer el equipo, y el objetivo
   real se cumple: que el operador pueda volver al 100 % y seguir viendo sus datos.

   ACOTADO A `min-width: 992px` A PROPÓSITO. Bajo 992 la ventana vuelve a
   scrollear (HVL §7.2) y el alto deja de ser un recurso escaso: comprimir ahí no
   gana nada y metería estas reglas en el barrido de 390×844, que tiene su propio
   contrato. Un teléfono en horizontal cae por el ancho, no por el alto.

   LO QUE NO SE TOCA: `--hd-size-row`. Ceder filas es exactamente lo que §8.3
   prohíbe — el cromo se aprieta para que quepan MÁS filas, no filas más flacas.

   OJO CON `--hd-size-topbar`: NO se redefine acá aunque sea el token del alto de
   la línea de estado. Lo comparte `.hd-topbar` (topbar.css), que en el portal del
   cliente y en el menú QR es su ÚNICA cabecera a cualquier ancho — tocarlo por
   token les encogería la barra de marca sin que nadie lo pidiera. El alto va
   directo sobre `.hd-page__status`, que es la región que se quiere apretar.

   Longhand (`padding-top`/`padding-bottom`) y NUNCA el shorthand `padding`: el
   bloque de móvil fija `padding-inline` aparte, y un shorthand acá lo borraría.

   La mitad tipográfica (título y subtítulo) vive en page-header.css, con el resto
   del componente.
   ============================================================ */

@media (min-width: 992px) and (max-height: 850px) {
    .hd-page > .hd-context-path {
        padding-top: var(--hd-space-3);
    }

    .hd-page > .hd-context-path + .hd-page-header {
        padding-top: var(--hd-space-1);
    }

    .hd-page > .hd-page-header {
        padding-bottom: var(--hd-space-3);
    }

    .hd-page__status {
        height: 40px;
    }

    .hd-page > .hd-toolbar {
        padding-top: var(--hd-space-3);
        padding-bottom: var(--hd-space-2);
    }

    .hd-page__content,
    .hd-page__content--flush {
        padding-bottom: var(--hd-space-4);
    }
}

/* Segundo escalón: POS y ventanas de verdad cortas. Sigue sin tocar las filas. */
@media (min-width: 992px) and (max-height: 650px) {
    .hd-page > .hd-context-path {
        padding-top: var(--hd-space-2);
    }

    .hd-page > .hd-page-header {
        padding-bottom: var(--hd-space-2);
    }

    .hd-page__status {
        height: 36px;
    }

    .hd-page > .hd-toolbar {
        padding-top: var(--hd-space-2);
    }

    .hd-page__content,
    .hd-page__content--flush {
        padding-bottom: var(--hd-space-3);
    }
}

/* ── Impresión ────────────────────────────────────────────────
   Lo que se imprime de una pantalla de Hednora es su CONTENIDO, nunca su
   chrome: un cuadre de caja en papel no lleva barra lateral, ni filtros,
   ni botones que en papel no se pueden pulsar.

   Vive aquí y no en un <style> de cada pantalla porque la decisión es de
   la composición canónica, no de la vista (HVL §6): toda pantalla tiene
   las mismas cinco regiones, así que todas se imprimen igual. Una vista
   que necesite además ocultar o revelar algo suyo usa las utilidades
   `d-print-*`, no un bloque de estilos propio. */
@media print {
    .hd-sidebar, .hd-topbar, .hd-shell__backdrop, .hd-page__footer { display: none; }
    .hd-shell { grid-template-columns: 1fr; }
    .hd-shell__main { height: auto; overflow: visible; }
    .hd-page { height: auto; }
    .hd-page__content { overflow: visible; padding: 0; }
    .hd-btn, form { display: none; }

    /* Regiones de chrome: la ruta de contexto y la toolbar solo sirven
       para navegar y filtrar; en papel no hacen ninguna de las dos. La
       línea de estado SÍ se imprime — son las cifras del documento. */
    .hd-context-path, .hd-toolbar, .hd-tabs__list { display: none; }

    /* El rail es la cola de trabajo de la pantalla, no parte del
       documento; y sin él la tabla recupera el ancho completo. */
    .hd-listing__rail { display: none; }
    .hd-listing, .hd-listing--with-rail { display: block; height: auto; }
    .hd-listing__main { overflow: visible; border: none; }

    /* Un panel en papel se delimita con línea, no con superficie: los
       fondos oscuros del tema gastan tinta y no se leen. */
    .hd-panel-card, .hd-listing__main {
        box-shadow: none;
        background: transparent;
    }

    /* Los paneles de pestaña ocultos siguen ocultos; el visible se
       imprime. hd-tabs.js alterna con `hidden`, que el navegador ya
       respeta al imprimir. */
    .hd-table { break-inside: auto; }
    .hd-table tbody tr { break-inside: avoid; }
}

/* ── Región E en el teléfono ───────────────────────────────────
   El footer de acciones no cabe en una fila: los tres botones del composer
   ("Cancelar" · "Crear y cobrar" · "Confirmar orden") suman **477px dentro de
   390**. Y el daño no es que se corte el último: al desbordar, el navegador
   hace **zoom out de toda la página** para que quepa —medido `innerWidth` 517
   en un viewport de 390— así que el catálogo entero se ve más chico y el
   problema parece de otra cosa. Es el mismo defecto que ya se corrigió en el
   carrito del menú público apilando los botones.

   Se reparte en dos filas: el primario a ancho completo arriba, en la zona del
   pulgar, y los secundarios debajo repartidos. El alto deja de ser los 56px
   fijos de escritorio.

   El corte va en 768 y no en 992 porque a 768 medido no hay desborde: la
   tablet sí los acomoda en una fila. */
@media (max-width: 767.98px) {
    .hd-page__footer.is-active {
        height: auto;
        flex-wrap: wrap;
        gap: var(--hd-space-2);
        padding: var(--hd-space-3) var(--hd-space-4);
    }

    /* Vacío en el composer; cuando la pantalla lo usa, va en su propia fila. */
    .hd-page__footer-summary:not(:empty) {
        width: 100%;
    }

    .hd-page__footer-actions {
        display: grid;
        grid-template-columns: 1fr 1fr;
        gap: var(--hd-space-2);
        width: 100%;
    }

    /* El primario se lleva su propia fila arriba: en una rejilla de dos
       columnas quedaría del mismo tamaño que un secundario, y es la acción que
       el pulgar busca sin mirar. `order` y no reordenar el markup, que en el
       DOM la acción primaria va última por foco y lectura. */
    .hd-page__footer-actions > .hd-btn--primary {
        grid-column: 1 / -1;
        order: -1;
    }

    /* 48px es el mayor de los dos mínimos táctiles (Android 48 / iOS 44). */
    .hd-page__footer-actions .hd-btn {
        min-height: 48px;
    }
}