/* ==========================================================================
   Reports status bar (#20) — a CSS-only, purpose-built visualisation for
   exactly the 4 known RequestStatus values, not a general charting
   primitive. Segment colours reuse the same custom properties every
   status-pill elsewhere in the app already uses (Status pills section,
   below), so this reads as the same colour language, not a second one.
   ========================================================================== */

.status-bar {
  display: flex;
  height: 1.5rem;
  border-radius: var(--md-sys-shape-corner-full);
  overflow: hidden;
  gap: 2px;
  background: var(--md-sys-color-surface-container-high);
}

.status-bar-segment {
  min-width: 2px;
}

.status-bar-open {
  background: var(--md-extended-color-success);
}

.status-bar-enough {
  background: var(--md-sys-color-on-surface-variant);
}

.status-bar-cancelled {
  background: var(--md-sys-color-error);
}

.status-bar-legend {
  display: flex;
  flex-wrap: wrap;
  gap: 0.25rem 1rem;
  margin: 0.5rem 0 0;
}

.status-bar-legend div {
  display: flex;
  gap: 0.35rem;
  align-items: baseline;
}

/* Sparse top-N data (#20, folds in Horizon 2's 2.6) — a bordered table
   for 1-2 rows looks like an accident, not content; render as a plain
   list instead once row count drops below the threshold each Reports
   section checks in its template. */
.compact-stat-list {
  margin: 0;
  padding: 0;
  list-style: none;
  display: grid;
  gap: 0.4rem;
}

.withdraw-form {
  margin-top: 1rem;
}

.withdrawn-profiles {
  margin-top: 1.5rem;
}

.withdrawn-profiles summary {
  cursor: pointer;
  font-weight: var(--meta-strong-weight);
  color: var(--md-sys-color-on-surface-variant);
}

/* Fill-in request lifecycle states are deliberately separate from the
   shared .status-pill family above: its colour classes are reused by
   unrelated enabled/import/knowledge-base statuses. */
.state-pill {
  display: inline-block;
  border: 1px solid var(--state-pill-border);
  border-radius: var(--md-sys-shape-corner-full);
  padding: 9px 16px;
  color: var(--state-pill-text);
  background: var(--state-pill-bg);
  font-size: var(--meta-size);
  font-weight: var(--meta-strong-weight);
  letter-spacing: var(--meta-tracking);
}

.state-needs-reply {
  --state-pill-text: var(--state-needs-reply-text);
  --state-pill-border: var(--state-needs-reply-border);
  --state-pill-bg: var(--state-needs-reply-bg);
}

.state-open {
  --state-pill-text: var(--state-open-text);
  --state-pill-border: var(--state-open-border);
  --state-pill-bg: var(--state-open-bg);
}

.state-sorted {
  --state-pill-text: var(--state-sorted-text);
  --state-pill-border: var(--state-sorted-border);
  --state-pill-bg: var(--state-sorted-bg);
}

.state-cancelled {
  --state-pill-text: var(--state-cancelled-text);
  --state-pill-border: var(--state-cancelled-border);
  --state-pill-bg: var(--state-cancelled-bg);
}

/* ==========================================================================
   Conversation thread (match/request messages — #16 2.5). Own messages
   right-aligned, other party left, grouped by consecutive sender with one
   name/timestamp per group rather than repeated on every message. The
   thread scrolls within its own fixed height so the composer form directly
   below it (in matches/conversation.html) stays in view without needing to
   scroll the whole page — "pinned at the bottom of the panel."
   ========================================================================== */

.message-thread {
  display: flex;
  flex-direction: column;
  gap: 0.75rem;
  max-height: 24rem;
  margin-bottom: 1rem;
  padding-right: 0.25rem;
  overflow-y: auto;
}

.message-group {
  display: flex;
  flex-direction: column;
  gap: 0.15rem;
  max-width: 80%;
}

.message-group-own {
  align-self: flex-end;
  align-items: flex-end;
}

.message-group-other {
  align-self: flex-start;
  align-items: flex-start;
}

.message-group-sender {
  color: var(--md-sys-color-on-surface-variant);
  font-size: var(--meta-size);
  font-weight: var(--meta-strong-weight);
}

.message-bubble {
  margin: 0;
  padding: 0.5rem 0.75rem;
  border-radius: var(--md-sys-shape-corner-medium);
  overflow-wrap: break-word;
}

.message-group-own .message-bubble {
  background: var(--md-sys-color-primary-container);
  color: var(--md-sys-color-on-primary-container);
}

.message-group-other .message-bubble {
  background: var(--md-sys-color-surface-container-high);
  color: var(--md-sys-color-on-surface);
}

.message-group-meta {
  color: var(--md-sys-color-on-surface-variant);
  font-size: var(--meta-size);
}

/* ==========================================================================
   Two-column detail layout (#18, review 3.3) — substance (.detail-main)
   left, a compact status/actions rail (.detail-rail) right, at ≥1024px
   only. Below that, both sections render in source order (.detail-rail
   first) with no grid at all — same as before this change. .detail-rail
   stays first in the DOM regardless of viewport so phone width and
   screen readers see the key figure and actions before the match table,
   only the *visual* desktop position moves via grid-column.
   ========================================================================== */

@media (min-width: 1024px) {
  .detail-layout {
    display: grid;
    grid-template-columns: 1fr 20rem;
    align-items: start;
    gap: 1.5rem;
  }

  .detail-rail {
    grid-column: 2;
    grid-row: 1;
  }

  .detail-main {
    grid-column: 1;
    grid-row: 1;
  }
}