/* Shared page/list primitives — the ONE set of classes for page chrome every module content view
   uses (page header/title/subtitle, empty state, muted meta text, plain links, bordered list rows).
   Mirrors the forms.css thesis: no module re-declares these (coding-standards §3/§4). Flex-wrap
   layout, no media queries. Token-driven (§12). */

.platform-page__header {
    display: flex;
    flex-wrap: wrap;
    align-items: center;
    justify-content: space-between;
    gap: var(--platform-space-sm, 0.5rem);
    margin: 0 0 var(--platform-space-lg, 1.5rem);
}

.platform-page__title {
    margin: 0;
    font-size: var(--platform-font-size-lg, 1.5rem);
}

.platform-page__subtitle {
    margin: var(--platform-space-lg, 1.5rem) 0 var(--platform-space-sm, 0.5rem);
    font-size: var(--platform-font-size-md, 1rem);
    font-weight: 600;
}

/* The page's EXPLAINER — the one line under the title saying what the page is for, rendered by
   <x-platform::page-header> from its default slot. Lives here, with the other page primitives, rather than in
   admin.css where it started life as `.platform-admin__explainer`: it was always a page-header part, not an
   admin one, and the header component now emits it on ordinary module pages too, where an "admin" class name
   would simply have been false.

   This is the ONLY under-the-title prose primitive. There was briefly a second — a "lead": a multi-sentence
   passage in its own card. It was removed (with its component) because in practice a lead is the worst of both
   shapes: too long to skim as a caption, too short to be documentation, and a permanent box of prose above
   content the user came to read. A page that needs more than one line to explain itself needs help that is
   asked for, not help that is always on screen. Distinct from `.platform-page__subtitle`, which is a section
   HEADING, not prose. */
.platform-page__explainer {
    margin: 0 0 var(--platform-space-lg, 1.5rem);
    color: var(--platform-color-text-muted, #57606a);
    font-size: var(--platform-font-size-sm, 0.875rem);
    line-height: 1.5;
}

/* The header's trailing action cluster (the `actions` slot): buttons sit in a row opposite the title and stay
   together when the header wraps on a narrow viewport.

   A page header renders straight on the page background — since M-197/M-203 a photo — so the cluster opts its
   buttons onto an opaque token surface by setting the inherited `--platform-btn-surface`. The mechanism, and why
   it is an inherited variable rather than a descendant rule, is stated once in coding-standards §12 (M-246) and
   at the point of temptation in buttons.css. */
.platform-page__actions {
    --platform-btn-surface: var(--platform-color-surface, #fff);

    display: flex;
    flex-wrap: wrap;
    align-items: center;
    gap: var(--platform-space-sm, 0.5rem);
}

/* An explainer belongs to the title above it, so the header's own bottom gap collapses when one follows. */
.platform-page__header:has(+ .platform-page__explainer) {
    margin-bottom: var(--platform-space-sm, 0.5rem);
}

.platform-empty {
    color: var(--platform-color-text-muted, #57606a);
}

.platform-meta {
    font-size: var(--platform-font-size-sm, 0.875rem);
    color: var(--platform-color-text-muted, #57606a);
}

.platform-link {
    color: var(--platform-color-accent, #0969da);
    text-decoration: none;
}

.platform-link:hover {
    text-decoration: underline;
}

.platform-link--strong {
    font-weight: 600;
}

.platform-list {
    margin: 0;
    padding: 0;
    list-style: none;
}

.platform-list__row {
    display: flex;
    flex-wrap: wrap;
    align-items: baseline;
    justify-content: space-between;
    gap: var(--platform-space-xs, 0.25rem);
    padding: var(--platform-space-sm, 0.5rem) 0;
    border-bottom: 1px solid var(--platform-color-border, #d0d7de);
}

.platform-inline-form {
    display: inline;
    margin: 0;
}

/* Two-column layout (M-074) — the LEFT column of `<x-platform::two-column>`. It carries the page's
   primary content: the form inputs on an editor, or the details/files/comments/access/history stack on a
   detail page. On a wide `col-lg-6` that content would read poorly stretched edge-to-edge.

   Instead of narrowing the BOXES (which would leave the column background showing at their sides), the
   cards span the FULL column width and we constrain their CONTENT to a comfortable ~42rem by GROWING the
   card's horizontal padding: `max(base, (100% - 42rem) / 2)`. On a wide column the calc wins, so the
   padding expands to keep content centered at exactly 42rem; on a narrow/mobile column the calc goes
   small (or negative) and `max()` falls back to the card's base inline padding, so content simply fills
   the box. Header + body share the value so a card title stays aligned with its content. Only the content
   BLOCK is centered — labels/text keep their own alignment. `100%` here is the card width (now the full
   column), and `--platform-space-lg` is the card's base inline padding (card.css). */
.platform-col-left .platform-card__header,
.platform-col-left .platform-card__body {
    padding-inline: max(var(--platform-space-lg), calc((100% - 42rem) / 2));
}