/* 22-responsive.css — lignes 1462-1581 de l'ancien style.css unique, contenu inchangé */

/* ===========================
   RESPONSIVE — MENU MOBILE
=========================== */
.menu-toggle{
    display:none;
    position:fixed;
    top:20px;
    left:20px;
    z-index:1100;
    width:46px;
    height:46px;
    align-items:center;
    justify-content:center;
    border:none;
    border-radius:var(--radius-md);
    background:var(--surface);
    box-shadow:var(--shadow);
    color:var(--text);
    font-size:18px;
    cursor:pointer;
}

.sidebar-overlay{
    display:none;
    position:fixed;
    inset:0;
    background:rgba(15,23,42,.5);
    z-index:900;
}

/* V3, Cycle 140 — « Aller au contenu » pendant que le tiroir est ouvert.

   Le lien vise `#contenuPrincipal`, que `ouvrirMenuMobile` rend `inert` :
   il conduirait vers un endroit où plus rien ne peut recevoir le focus.
   Un geste proposé sans effet est une faute (Cycle 43), et il était le
   PREMIER arrêt de tabulation — le premier geste offert était le seul à
   ne rien faire. */
#app.sidebar-open .lien-evitement{
    display:none;
}

body.dark .menu-toggle{
    background:#1e293b;
    color:white;
}

/* Seuil de basculement de la sidebar fixe vers le mode tiroir.
   Porté de 900px à 1100px au terme de la phase de stabilisation.

   Motif, mesuré : à 900px exactement, la sidebar fixe de 270px s'affichait et
   la largeur utile du contenu chutait de 859px à 560px. Élargir la fenêtre
   rétrécissait donc le contenu, et il fallait atteindre 1199px pour retrouver
   la largeur disponible à 899px. Sur toute la plage 900–1199px (tablettes en
   paysage, petits portables), la sidebar consommait jusqu'à 30 % de la largeur.

   À 1100px, la largeur utile passe de 760px à 1060px sur cette plage.
   Une sidebar compacte (icônes seules) serait probablement préférable à long
   terme, mais c'est une évolution UX à valider avec de vrais usages : on retient
   ici la correction minimale, un seul seuil modifié. */
@media (max-width: 1100px){

    .menu-toggle{
        display:flex;
    }

    /* V3, Cycle 143 — le voile n'existe QU'EN mode tiroir.
    
       Cette règle vivait hors de ce bloc. Le voile s'affichait donc à toute
       largeur dès que `sidebar-open` était posée — et cette classe, elle,
       ne connaît pas les largeurs.
    
       Mesuré : tiroir ouvert à 390 px, fenêtre élargie à 1440 px. Le voile
       couvrait 1440 × 900, le contenu restait `inert`, et `.menu-toggle`
       — le seul bouton qui aurait pu fermer — était masqué par la règle
       ci-dessus. Une application de bureau entièrement grisée, sans rien à
       l'écran pour dire comment en sortir. */
    #app.sidebar-open .sidebar-overlay{
        display:block;
    }

    /* V3, Cycle 137 — `visibility:hidden` autant que le `transform`.
       
       Un `transform` DÉPLACE ; il ne retire rien. Tabulé à 390 px, tiroir
       fermé : six pressions sur Tab de suite tombaient sur des boutons de
       menu situés à x = -238, hors de l'écran. Le focus disparaissait,
       puis « Entrée » changeait de page sans qu'on ait vu ce qu'on
       activait. `visibility:hidden` retire de l'ordre de tabulation tout
       ce que le tiroir contient — et c'est la règle qui l'écarte qui le
       dit, donc un seul endroit décide des deux choses à la fois.
       
       Écarté : poser `inert` en JavaScript. Ce serait un second état à
       tenir à jour à côté de `sidebar-open`, plus une écoute des
       changements de largeur — deux sources pour un seul fait.
       
       Le délai sur `visibility` la laisse tenir le temps de l'animation :
       cette propriété ne s'interpole pas, et sans lui le tiroir
       s'évanouirait au lieu de glisser. */
    .sidebar{
        transform:translateX(-100%);
        visibility:hidden;
        transition:transform .3s ease, visibility 0s linear .3s;
        z-index:1000;
    }

    #app.sidebar-open .sidebar{
        transform:translateX(0);
        visibility:visible;
        transition:transform .3s ease, visibility 0s;
    }

    .content{
        margin-left:0;
        padding:25px 20px;
        padding-top:85px;
    }

    .dashboard-hero{
        flex-direction:column;
        align-items:flex-start;
        gap:var(--space-5);
        padding:28px 24px;
    }

    .hero-kpi{
        align-items:flex-start;
        text-align:left;
        width:100%;
    }

    .hero-kpi-value{
        font-size:40px;
    }

    .topbar{
        flex-wrap:wrap;
        gap:var(--space-4);
    }

}

@media (max-width: 600px){

    .content{
        padding-left:var(--space-4);
        padding-right:var(--space-4);
    }

    .panel, .card, .kpi-mini-card{
        padding:var(--space-5);
    }

    .hero-text h1{
        font-size:22px;
    }

    .hero-kpi-value{
        font-size:34px;
    }

    .cards,
    .kpi-row,
    .quick-actions-row,
    .dashboard-grid,
    .form-grid,
    .stats-grid{
        flex-direction:column;
        align-items:stretch;
    }

    /* `.mission-actions` figurait ici, et son `align-items:stretch` ne
       s'appliquait pas : `23-missions-badges.css` est chargé APRÈS ce
       fichier et y repose `align-items:center` à specificité égale. Une
       règle responsive écrite avant le composant qu'elle vise perd
       toujours. Elle vit désormais dans le fichier du composant. */

}

/* ---------------------------------------------------------------------
   Un tableau qui défile, pas une page — V3, Cycle 25.

   Vu à 390 px : le tableau de l'historique compte quatre colonnes et ne
   tient pas. Sans conteneur, c'est la PAGE entière qui défilait de côté
   — tout le reste de la mise en page partait avec elle.
   --------------------------------------------------------------------- */
.table-defilante{
    width:100%;
    overflow-x:auto;
    -webkit-overflow-scrolling:touch;
}

.table-defilante > table{
    min-width:420px;
}