/*
 * Buffalo147 AI — the shell, and only the shell.
 *
 * WHY THIS FILE EXISTS.
 *
 * The owner photographed /image with the sidebar stretched across the whole
 * window above the content, every panel unstyled, and said it settles after
 * a moment. The cause was one attribute in the emitted head: chat.css — 130
 * KB, and the file that holds `.bf-app { display: grid }` — was sent as
 * `media='print'` with an onload that flips it back to `all`, which keeps it
 * out of the render path entirely. So the browser drew the page with the
 * shell rule absent, `.bf-app` was an ordinary block, every child stacked,
 * and only afterwards did the sheet switch on and everything jump into
 * place.
 *
 * That was done for speed and bought none: the paint on that route already
 * waits for 284 KB of other stylesheets, so holding back the shell made the
 * first frame no earlier — only wrong.
 *
 * WHAT IS IN HERE, AND WHAT IS NOT.
 *
 * The rules that decide the GEOMETRY of the first frame, and nothing else:
 * the grid, its two tracks, the rail in the first track, the work area in
 * the second, and the WordPress toolbar's height, which moves everything
 * down for a logged-in administrator. About 2 KB. Everything else — every
 * colour, every message bubble, every menu — stays in chat.css and stays
 * out of the render path, where it costs nothing to wait for.
 *
 * These rules were MOVED here, not copied. Two files carrying the same
 * declarations would drift the first time one of them was edited, and the
 * drift would show up as exactly the bug this closes.
 *
 * Enqueued wherever chat.css is, always render-blocking, always before it.
 * The handle is `bf-shell-layout` and not `bf-shell`: that one is already a
 * SCRIPT (`assets/js/shell.js`). WordPress keeps the two registries apart,
 * so nothing would have broken — but two different things under one name is
 * how the next person makes the mistake.
 */

.bf-chat-page {
  overflow: hidden;
  /* A translated panel must never widen the document. */
  overflow-x: hidden;
}

.bf-app {
  display: grid;
  /*
   * In a right-to-left document the first track is the rightmost one, so the
   * rail is declared first to put it on the right where it belongs.
   *
   * Both children also pin themselves to row 1. Without that, grid's default
   * sparse auto-placement refuses to move its cursor backwards: the rail took
   * column 2, the main area asked for column 1, and since the cursor had
   * already passed it the browser dropped the whole workspace onto a second
   * row. The result was a page stacked vertically with the composer far below
   * the fold — which is exactly what the screenshot showed.
   */
  grid-template-columns: var(--bf-sidebar-w) 1fr;
  height: calc(100vh - var(--bf-admin-bar, 0px));
  height: calc(100dvh - var(--bf-admin-bar, 0px));
  position: relative;
  overflow: hidden;
}

/*
 * An administrator sees the WordPress toolbar, which is fixed at the top and
 * pushes everything down. Without accounting for it the composer sits below
 * the fold — visible to the owner, invisible to everyone else, which is the
 * worst kind of layout bug because it only appears to the person testing.
 */
.admin-bar { --bf-admin-bar: 32px; }

@media screen and (max-width: 782px) {
  .admin-bar { --bf-admin-bar: 46px; }
}

.admin-bar .bf-rail { inset-block-start: var(--bf-admin-bar); }
.admin-bar .bf-toasts { inset-block-start: calc(var(--bf-space-5) + var(--bf-admin-bar)); }

.bf-rail {
  grid-column: 1;
  grid-row: 1;
  display: flex;
  flex-direction: column;
  min-height: 0;

  /*
   * A panel that floats, not a column welded to the edge.
   *
   * The reference leaves 5px above and 15px to the side, and rounds the
   * corners — so the black page shows all the way round it and the
   * sidebar reads as a card rather than a wall.
   */
  margin: 5px 15px 5px 0;
  padding: 14px;
  gap: 12px;
  border: 1px solid rgba(255,255,255,.05);
  border-radius: 18px;
  /*
   * The rail sits a step above the page, and a row sinks under the pointer.
   *
   * It was darker than the page behind it, so the list read as a hole
   * rather than a panel. Now it is the lighter surface and a hovered row
   * drops to the page's own colour — the row moves toward you by moving
   * away from the rail, which is the opposite of what it did before.
   */
  background: #20201F;
  position: relative;

  /*
   * Above the page, below anything that opens over it.
   *
   * On a phone the rail slides across the content and must cover it; on
   * a desktop it sits alongside and the number does not matter. What
   * matters is that a menu at --bf-z-menu is higher, so opening one does
   * not put it behind the sidebar.
   */
  z-index: var(--bf-z-sticky);
  transition: transform var(--bf-normal) var(--bf-ease);
}

.bf-main {
  grid-column: 2;
  grid-row: 1;
  display: flex;
  flex-direction: column;
  min-height: 0;

  /*
   * Positioned, but with no z-index of its own.
   *
   * `z-index: 1` here made this column a stacking context, and everything
   * inside it was then trapped below the rail at 2 — including menus that
   * ask for 100. A menu opening behind the sidebar was the symptom.
   *
   * `position: relative` stays: descendants are positioned against it.
   * Only the layer number goes, and nothing needed it — this column and
   * the rail are side by side in a grid, not stacked.
   */
  position: relative;
}


/* ---------------------------------------------------------------------
 * The second half, added after measuring rather than after reasoning.
 *
 * With the grid above in place the page was laid out correctly at first
 * paint — and still shifted by 0.46, which is «poor» by any measure. The
 * tool was made to name what moved instead of leaving it to guesswork,
 * and it named the top bar: `.bf-crumb` slid 116px and the credit chip
 * jumped 967px across the window, because both are styled by image.css —
 * which blocks — while the FLEX ROW THAT ARRANGES THEM was in chat.css,
 * which does not. The children were dressed and the shelf they stand on
 * was missing.
 *
 * The rail's footer moved for the same reason, 27px.
 *
 * The lesson is the one this project keeps relearning: the sentinel said
 * `display: grid` and the page was still wrong. One assertion is one
 * assertion.
 * ------------------------------------------------------------------ */

/*
 * The account card sits above the rail's own edge.
 *
 * Pinned to the bottom it read as a footer — the last thing on the
 * page rather than a thing to use. Lifted a little, with the
 * conversation list taking the space the upgrade card used to hold, it
 * is where the eye lands when it reaches the end of the list.
 */
.bf-rail__foot {
  flex: none;
  margin-bottom: 12px;
  padding-top: 12px;
  border-top: 1px solid var(--border-default);
}

/* ---------------------------------------------------------------------
 * Rail footer
 * ------------------------------------------------------------------ */

.bf-rail__foot {
  display: grid;
  gap: var(--bf-space-2);
  padding-bottom: 2px;
}

.bf-topbar {
  display: flex;
  align-items: center;
  gap: var(--bf-space-3);
  padding: var(--bf-space-3) var(--bf-space-5);
  flex: none;
}

/*
 * Credit sits at the far end, as it does on every other page.
 *
 * Nothing here pushed it there, so it landed wherever the model picker
 * left off — halfway across the bar, in the middle of nothing. The
 * picker takes the slack instead.
 */
.bf-topbar .bf-picker { margin-inline-end: auto; }

.bf-topbar__rail { display: none; }