/* FILE: site/css/chat-widget.css

   BLUE AND GOLD, NOT PURPLE — 2026-08-16, owner-directed.

   The header note here used to say this file "uses --gradient-brand
   (pink→purple) as the closest on-brand match for the original purple accent."
   Read that sentence again: it treats the ORIGINAL PURPLE as the thing to match.
   The site's brand is Amber/Sapphire. The chat widget is the persona's face on
   every single page, and it was wearing Swag Studio's feature colour because a
   migration off a hardcoded hex asked "what is closest to what was here?"
   instead of "what should be here?". --gradient-brand is now built from
   --color-primary-amber and --color-accent-sapphire; see theme.css.

   The four `color: #fff` in this file went with it, and that was not cosmetic.
   White was hardcoded rather than using --color-on-fill, so it did not flip
   with the theme. Measured on the DEFAULT dark theme, on the purple it sat on:

     chat header, send button, user's own message bubbles
       #a78bfa on #ffffff  2.72:1     FAIL
       #7c5cff on #ffffff  4.35:1     FAIL   (AA needs 4.5)

   Now var(--color-on-fill), which is #ffffff in light and #0b0e1a in dark, so
   both ends of the new gradient clear AA in both themes: 5.07 / 6.70 light,
   8.92 / 8.91 dark. This is the exact bug --color-on-fill was created for on
   2026-07-31; the chat widget simply never adopted it.

   The FAB itself is an emoji (💬) so its own contrast is decorative, but it
   shares the rule and there is no reason to leave one hardcoded white behind. */

#aime-chat-fab {
  position: fixed;
  bottom: 24px;
  right: 24px;
  width: 56px;
  height: 56px;
  border: none;
  border-radius: 50%;
  background: var(--gradient-brand);
  color: var(--color-on-fill);
  font-size: 24px;
  cursor: pointer;
  box-shadow: 0 4px 16px rgba(0, 0, 0, 0.3);
  z-index: 9999;
}

#aime-chat-panel {
  position: fixed;
  bottom: 92px;
  right: 24px;
  width: 320px;
  max-height: 70vh;
  display: flex;
  flex-direction: column;
  background: var(--color-bg-surface);
  border: 1px solid var(--color-border);
  border-radius: var(--radius-md, 12px);
  box-shadow: 0 8px 32px rgba(0, 0, 0, 0.25);
  overflow: hidden;
  z-index: 9999;
}
/* FIX 2026-07-26: chat-widget.js sets `panel.hidden = true` on creation and
   toggles it from the FAB -- but the `display: flex` above beats the
   browser's built-in `[hidden] { display: none }` rule (a plain element
   selector with a property outranks the UA stylesheet's default). So the
   panel rendered OPEN on every page load regardless of the hidden
   attribute, and the FAB's toggle did nothing visible. Confirmed live in a
   real browser 2026-07-26: on index.html the panel covered the hero
   headline and the secondary CTA -- the first thing any visitor saw.
   Explicitly re-asserting display:none for [hidden] is the standard fix
   whenever a `display` is set on an element that also uses the hidden
   attribute. */
#aime-chat-panel[hidden] {
  display: none;
}

#aime-chat-header {
  padding: 12px 16px;
  background: var(--gradient-brand);
  color: var(--color-on-fill);
  font-weight: 600;
}

#aime-chat-personas {
  display: flex;
  flex-direction: column;
  gap: 6px;
  padding: 8px;
  border-bottom: 1px solid var(--color-border);
  max-height: 260px;
  overflow-y: auto;
}

/* UPDATED 2026-07-25 (site-experience pass): was a compact same-row pill;
   now a full-width row per persona so the pickerLine (the "default move"
   one-liner, see chat-widget.js) has room to actually show -- personality
   needs to be visible before the first reply, not just inside the button
   title attribute. */
.aime-persona-btn {
  display: flex;
  align-items: center;
  flex-wrap: wrap;
  gap: 4px 8px;
  width: 100%;
  text-align: left;
  font-size: 12px;
  padding: 6px 10px;
  border: 1px solid var(--color-border);
  border-radius: 10px;
  background: var(--color-bg-primary);
  color: var(--color-text-primary);
  cursor: pointer;
}

.aime-persona-btn.is-active {
  border-color: var(--color-primary-amber);
  color: var(--color-primary-amber);
}

.aime-persona-picker-line {
  flex-basis: 100%;
  font-size: 11px;
  font-style: italic;
  font-weight: 400;
  color: var(--color-text-secondary);
  line-height: 1.3;
}

.aime-persona-btn.is-active .aime-persona-picker-line {
  color: var(--color-primary-amber);
  opacity: 0.85;
}

.aime-persona-avatar {
  width: 22px;
  height: 22px;
  border-radius: 50%;
  object-fit: cover;
  object-position: top center;
  flex-shrink: 0;
}

#aime-chat-log {
  flex: 1;
  overflow-y: auto;
  padding: 12px;
  display: flex;
  flex-direction: column;
  gap: 8px;
}

/* ── WHY THE BOT LOOKED LIKE ONE WALL OF TEXT ──────────────────────────────
   Owner, 2026-08-17: "I want the syntax of the bot to be better and double
   spaced."

   chat-widget.js:212 renders every reply with `line.textContent = text`.
   That is CORRECT and must not change -- innerHTML on model output is an XSS
   vector, and this project has no sanitiser and no build step to add one.

   But CSS `white-space` defaults to `normal`, which COLLAPSES every newline
   into a single space. So a reply the model wrote as three tidy paragraphs
   arrived in the DOM with its \n\n intact and then rendered as one unbroken
   blob. The model was formatting correctly the whole time; the stylesheet was
   throwing it away.

   `pre-wrap` keeps newlines AND still wraps long lines at the bubble edge.
   `pre` would not wrap and would force horizontal scrolling on a phone, which
   is the wrong trade for a mobile-first creator audience.

   TWO THINGS WERE BROKEN AND ONE FIX WAS NOT ENOUGH. No persona prompt told
   the model to use paragraphs either, so even with this rule the replies would
   have stayed dense. See the formatting block in functions/bot.js. Fixing only
   the CSS would have looked like a fix and changed almost nothing. */
.aime-msg {
  white-space: pre-wrap;
  padding: 10px 12px;
  border-radius: 8px;
  font-size: 14px;
  /* 1.4 -> 1.65. This is the "double spaced" half of the request and it does
     more work than it looks: `pre-wrap` alone restores the paragraph BREAKS,
     but at 1.4 the lines inside a paragraph still sit tight enough that a
     blank line reads as a small gap rather than a real separation.

     1.65 on 14px is ~23px of line box — comfortable for a phone held at arm's
     length, which is the audience: a working creator, on mobile, between
     shifts. Above ~1.8 the lines start to feel disconnected from each other
     and a short reply looks like a list of unrelated sentences. */
  line-height: 1.65;
}

.aime-msg-user {
  align-self: flex-end;
  background: var(--gradient-brand);
  color: var(--color-on-fill);
}

.aime-msg-bot {
  align-self: flex-start;
  background: var(--color-bg-primary);
  color: var(--color-text-primary);
  border: 1px solid var(--color-border);
}

.aime-msg-system {
  align-self: center;
  font-size: 12px;
  color: var(--color-text-secondary);
}

#aime-chat-form {
  display: flex;
  border-top: 1px solid var(--color-border);
}

#aime-chat-input {
  flex: 1;
  border: none;
  padding: 12px;
  font-size: 14px;
  background: var(--color-bg-surface);
  color: var(--color-text-primary);
}

#aime-chat-form button {
  border: none;
  background: var(--gradient-brand);
  color: var(--color-on-fill);
  padding: 0 16px;
  cursor: pointer;
}