is not rendered at all. Pinned both ways by PortalViewRenderTests.ACleanPageRendersNoEmptyErrorBox and .ModelLevelErrorsAreActuallyRenderedOnThePage. */ .pf-alert--error ul { margin: 0; padding-left: var(--sp-5); } /* ── The one-time key panel ── */ .pf-newkey { margin-top: var(--sp-5); padding: var(--sp-5); border: 2px solid var(--c-accent); border-radius: var(--r-lg); background: var(--c-accent-wash); } .pf-newkey__title { display: flex; align-items: center; gap: var(--sp-2); margin: 0; font-size: var(--fs-xl); } .pf-newkey__title i { color: var(--c-accent); } .pf-newkey__lead { margin: var(--sp-3) 0 0; max-width: 70ch; } .pf-newkey__value { margin: var(--sp-4) 0 0; padding: var(--sp-4); border: 1px solid var(--c-line-strong); border-radius: var(--r-sm); background: var(--c-surface); overflow-x: auto; font-size: var(--fs-sm); } /* THE WRAP RULE WAS INERT. .pf-newkey__value is a
, so the UA gives it
   white-space: pre - there are no soft-wrap opportunities at all, which makes
   word-break on the  inside do nothing. A ~70-character credential
   therefore scrolled sideways inside a ~290px panel on a phone, on the one
   page that states plainly the value will never be shown again. Scoped to the
   key panel so /reference's curl blocks keep scrolling, which is right for a
   command line. */
.pf-newkey .pf-newkey__value { white-space: pre-wrap; overflow-x: visible; }
.pf-newkey__value code { word-break: break-all; user-select: all; }
.pf-newkey__hint { margin: var(--sp-3) 0 0; color: var(--c-text-muted); font-size: var(--fs-sm); }

/* A worked EXAMPLE payload on /reference (the usage-limit problem body). Scrolls
   sideways rather than wrapping, deliberately and unlike .pf-newkey__value above: JSON
   re-flowed at an arbitrary column stops being copy-pasteable and stops looking like
   JSON, whereas a credential must never scroll out of sight. Different content, opposite
   rule — see the wrap-rule note above for why that one went the other way. */
.pf-code {
    margin: var(--sp-4) 0 0;
    padding: var(--sp-4);
    border: 1px solid var(--c-line-strong);
    border-radius: var(--r-sm);
    background: var(--c-surface);
    overflow-x: auto;
    font-size: var(--fs-sm);
    line-height: 1.5;
}

/* ── Cards / the create form ── */
/* --c-surface-2, not --c-surface: a card painted the same colour as the page
   it sits on is a card only by its 1px border, in both ramps. */
.pf-card {
    margin-top: var(--sp-5);
    padding: var(--sp-5);
    border: 1px solid var(--c-line);
    border-radius: var(--r-lg);
    background: var(--c-surface-2);
    box-shadow: var(--shadow-1);
}
.pf-card__title { margin: 0 0 var(--sp-4); font-size: var(--fs-xl); }
/* A fieldset legend and a single field's label were both .pf-label, so a group
   of four checkboxes announced itself exactly like one more text input. */
.pf-legend {
    display: block;
    margin-bottom: var(--sp-1);
    padding: 0;
    font-size: var(--fs-lg);
    font-weight: var(--fw-semibold);
}
.pf-card__actions { margin-top: var(--sp-5); }

.pf-field { margin-top: var(--sp-5); }
/* ⚠ NOT :first-of-type — .pf-field is on a  AND on the scopes , so
   :first-of-type matches the first of EACH, silently zeroing the fieldset's top margin
   too and leaving the form's gaps asymmetric. Anchor on the heading instead: exactly one
   element can follow it. */
.pf-card__title + .pf-field { margin-top: 0; }
.pf-field--narrow { max-width: 22rem; }
.pf-fieldset { border: 0; padding: 0; margin-inline: 0; }
.pf-label { display: block; font-weight: var(--fw-semibold); padding: 0; }
.pf-help { margin: var(--sp-1) 0 var(--sp-3); color: var(--c-text-muted); font-size: var(--fs-sm); max-width: 70ch; }
.pf-input {
    width: 100%;
    margin-top: var(--sp-2);
    padding: 10px var(--sp-3);
    font: inherit;
    color: var(--c-text);
    background: var(--c-surface);
    border: 1px solid var(--c-line-strong);
    border-radius: var(--r-sm);
}
.pf-input--tiny { width: auto; margin-top: 0; padding: 6px var(--sp-3); font-size: var(--fs-sm); min-height: 40px; }
/* ⚠ NO .pf-field__error. The portal renders MODEL-level errors only (the note twenty
   lines up explains why the empty-box guard is unnecessary); there is no per-field
   validation span anywhere on this host, so the rule had nothing to style. */

/* Separator on the ADJACENT SIBLING, not a first-of-type override. This is
   exactly the fragility the comment twelve lines above warns about: .pf-check
   would need :first-of-type to reset a border it should never have had, and
   :first-of-type matches per element TYPE, so one  among s
   silently resets a second time. */
.pf-check { display: flex; gap: var(--sp-3); padding: var(--sp-3) 0; }
.pf-check + .pf-check { border-top: 1px solid var(--c-line); }
.pf-check input { margin-top: 4px; flex: 0 0 auto; width: 20px; height: 20px; accent-color: var(--c-accent); }
.pf-check label { display: grid; gap: 2px; cursor: pointer; }
.pf-check__title { font-weight: var(--fw-semibold); }
.pf-check__desc { color: var(--c-text-muted); font-size: var(--fs-sm); }
.pf-check__token { color: var(--c-text-faint); font-size: var(--fs-xs); }

/* ── The key table ── */
.pf-tablewrap { overflow-x: auto; }
.pf-table { width: 100%; border-collapse: collapse; font-size: var(--fs-sm); }
/* display:block, not the UA default table-caption: at the 860px breakpoint
   below, .pf-table itself switches to display:block, and a table-caption
   box whose parent is no longer display:table/inline-table gets wrapped in
   its own anonymous single-child table by the CSS box-fixup algorithm —
   which sizes to shrink-to-fit content instead of the .pf-table width,
   rendering the caption text in an extremely narrow, heavily word-wrapped
   column beside empty space. Forcing block here keeps it an ordinary
   full-width block box at every viewport, table-shaped parent or not. */
.pf-table__caption { display: block; width: 100%; text-align: left; color: var(--c-text-muted); padding-bottom: var(--sp-3); }
.pf-table th, .pf-table td { text-align: left; padding: var(--sp-3); border-bottom: 1px solid var(--c-line); vertical-align: top; }
.pf-table thead th { color: var(--c-text-muted); font-weight: var(--fw-semibold); white-space: nowrap; }
.pf-keyid { word-break: break-all; }
.pf-scopelist { margin: 0; padding: 0; list-style: none; display: grid; gap: 2px; }
.pf-scopelist code { font-size: var(--fs-xs); }

.pf-badge {
    display: inline-block; padding: 2px var(--sp-2);
    border-radius: var(--r-pill); font-size: var(--fs-xs); font-weight: var(--fw-semibold);
    white-space: nowrap;
}
.pf-badge--ok { background: var(--c-success-wash); color: var(--c-success); }
.pf-badge--warn { background: var(--c-warn-wash); color: var(--c-warn); }
.pf-badge--off { background: var(--c-surface-2); color: var(--c-text-muted); }
.pf-badge__note { display: block; margin-top: 2px; font-size: var(--fs-xs); }

.pf-actions { white-space: nowrap; }
.pf-inline-form { display: inline-flex; align-items: center; gap: var(--sp-2); margin-right: var(--sp-2); }
.pf-btn--sm { padding: 6px var(--sp-3); font-size: var(--fs-sm); min-height: 40px; }
.pf-btn--danger { color: var(--c-danger); border-color: var(--c-danger); }
.pf-btn--danger:hover { background: var(--c-danger-wash); border-color: var(--c-danger-hover); }

/* ── Refusal page ── */
.pf-denied { max-width: 60ch; }
.pf-denied__actions { display: flex; flex-wrap: wrap; gap: var(--sp-3); margin-top: var(--sp-6); }
.pf-denied__signout { margin-top: var(--sp-5); }

/* 860, not 720. The host had four unaligned numbers doing one job (980 post
   reflow, 860 listing reflow, 720 portal table, 700 panel/chrome), so between
   721 and 860 a forum listing was stacked while a portal table beside it was
   still a table. Two forum numbers now: 860 = the major reflow, 700 = the phone
   floor. 980 stays, because the post's author column runs out of room before a
   table does. */
@media (max-width: 860px) {
    .pf-table, .pf-table thead, .pf-table tbody, .pf-table th, .pf-table td, .pf-table tr { display: block; }
    .pf-table thead { display: none; }
    .pf-table tr { border-bottom: 1px solid var(--c-line-strong); padding: var(--sp-3) 0; }
    .pf-table td { border-bottom: 0; padding: 2px 0; }
    /* The column header moves into the cell, so a stacked row still says what it is. */
    .pf-table td::before {
        content: attr(data-label) ": ";
        color: var(--c-text-muted);
        font-weight: var(--fw-semibold);
    }
    /* attr() on a MISSING attribute resolves to the empty string, so a 
       with no data-label rendered a bare ": value" once the header was hidden.
       /reference's scopes table was exactly that - eight bare cells - and it is
       the table three RFC 7807 refusal middlewares deep-link a developer to.
       The attributes are added now, but the rule degrades to nothing anyway, so
       the next table to forget them is merely unlabelled rather than wrong. */
    .pf-table td::before { content: ""; }
    .pf-table td[data-label]::before { content: attr(data-label) ": "; }

    /* AFTER the generic rule, not before it. Both selectors carry identical
       specificity, so source order is the only thing that decides — and with the
       suppressor first the generic rule won and put "Actions: " back above the
       Rotate/Revoke buttons on every stacked key row. */
    .pf-table td[data-label="Actions"]::before { content: ""; }
    .pf-actions { white-space: normal; padding-top: var(--sp-3); }
    .pf-inline-form { margin-top: var(--sp-2); }
}

/* AI assistant access — the MCP lane's connection panel. */
.pf-assistant p { margin: 0 0 var(--sp-3); max-width: 70ch; }
.pf-assistant p:last-of-type { margin-bottom: var(--sp-4); }
.pf-assistant__state { display: flex; align-items: center; gap: var(--sp-2); flex-wrap: wrap; }

/* ==========================================================================
   Shared-kit completions
   ==========================================================================
   Every rule below names a class that was ALREADY in the markup and had no
   declaration anywhere — the views were rendering with browser defaults and
   nobody noticed, because a missing CSS class fails silently. The audit that
   produced this list cross-referenced every `class="…"` token under Views/
   against every selector in this file; 100+ forum classes came back unmatched,
   which is the whole of the "the forum looks plain" complaint.

   🔴 THE FOUR THAT WERE NOT MERELY PLAIN BUT WRONG:
     .msec__title / .msec__lede — every forum  and lede used these; the kit
       only ever defined .msec__heading / .msec__lead. So every forum page title
       rendered at the UA default and no forum page had a lede style at all.
     .fm-sr-only — used on s in Drafts, Member and Moderate that are
       meant to be screen-reader-only. With no rule they were VISIBLE, so the
       moderation console printed stray "Name"/"Reason"/"Warning" labels.
     .mk-container--narrow — the FAQ, Compose and Denied pages asked for a
       narrow measure and got the full 1200px column.
     .pf-input--sm / .mk-btn--sm — every "compact" control in the moderation
       console and on the topic page rendered full size, which is why those
       pages read as a wall of full-width inputs.
   ========================================================================== */

/* Section heading pair used by the FORUM views (left-aligned page titles), as
   distinct from .msec__heading/.msec__lead which centre inside .msec__head for
   the marketing bands. */
.msec__title {
    margin: 0 0 var(--sp-2);
    font-size: clamp(1.5rem, 3vw, 2rem);
    font-weight: var(--fw-bold);
    letter-spacing: -0.01em;
}
.msec__lede {
    margin: 0 0 var(--sp-5);
    max-width: 70ch;
    color: var(--c-text-muted);
    font-size: var(--fs-lg);
}

/* A reading measure for prose pages (FAQ entries, compose forms, refusals). */
.mk-container--narrow { max-width: 860px; }

/* Compact control sizes. .mk-btn keeps its pill shape and its font stack; only
   the box shrinks, so a row of small buttons still reads as the same family as
   the page's primary action. */
/* .mk-btn is already inline-flex, so a min-height here is a floor rather than
   a layout change. 7px on a --fs-sm line computes to ~34px, which is under
   every touch guideline - and these are the forum's action rows. */
.mk-btn--sm { padding: 7px 14px; font-size: var(--fs-sm); min-height: 40px; }

/* Screen-reader-only. Same technique as .pf-visually-hidden — kept as a second
   name rather than renamed in eight views, because the two namespaces are
   deliberately independent and a forum view should not have to know the portal
   kit exists to hide a label. */
.fm-sr-only {
    position: absolute;
    width: 1px;
    height: 1px;
    overflow: hidden;
    clip: rect(0 0 0 0);
    clip-path: inset(50%);
    white-space: nowrap;
    border: 0;
    padding: 0;
    margin: -1px;
}

/* Portal-kit completions. */
.pf-input--sm {
    width: auto;
    max-width: 100%;
    margin-top: 0;
    padding: 6px var(--sp-3);
    font-size: var(--fs-sm);
    min-height: 40px;
}
.pf-field--check { display: flex; align-items: flex-start; gap: var(--sp-3); }
.pf-field--check input[type="checkbox"] {
    margin-top: 3px;
    flex: 0 0 auto;
    width: 18px;
    height: 18px;
    accent-color: var(--c-accent);
}
.pf-subsection-title {
    margin: var(--sp-5) 0 var(--sp-3);
    font-size: var(--fs-lg);
    font-weight: var(--fw-semibold);
}
.pf-create { max-width: 46rem; }
/* NO .pf-alert--warning ALIAS. Two views spelled the modifier that way and it had no
   rule at all, so the moderator-warning banner and the "your forum account is still
   being set up" notice both rendered as neutral grey boxes. The fix is the two markup
   sites, not a second selector: an alias leaves both spellings alive in one file and the
   next view picks whichever it happens to read first. ForumStyleCoverageTests now fails
   on the misspelling instead of silently accepting it. */

.mk-footer__brand { min-width: 0; }

/* ==========================================================================
   The application surface — 
   ==========================================================================
   The forum, the FAQ, the developer portal and the API reference are
   APPLICATIONS sitting on the marketing host, and they were rendering on the
   same edge-to-edge white page the landing pages use. phpBB's whole sense of
   structure comes from the opposite arrangement: a light ground with the board
   sitting on it as a distinct panel (prosilver's `body` #f5f5f5 vs `.wrap`
   #ffffff). Reproduced here with tokens, so it inverts correctly in dark.

   The attribute is set in _Layout from the request path, so no view has to
   remember it and a new /forum/** page gets it for free.
   ========================================================================== */
body[data-surface='app'] { background: var(--c-bg); }

body[data-surface='app'] > main > .msec { padding-block: clamp(16px, 3vw, 28px); }

body[data-surface='app'] > main > .msec > .mk-container {
    padding-block: clamp(20px, 3vw, 32px);
    background: var(--c-surface);
    border: 1px solid var(--c-line);
    border-radius: var(--r-lg);
    box-shadow: var(--shadow-1);
}

/* On a phone the panel goes edge to edge and drops its corners — exactly what
   prosilver's responsive.css does to .wrap/.forabg/.forumbg below 750px. The
   gutter is worth more to the content than the frame is to the composition. */
@media (max-width: 700px) {
    body[data-surface='app'] > main > .msec { padding-block: 0; }
    body[data-surface='app'] > main > .msec > .mk-container {
        border-radius: 0;
        border-inline: 0;
        border-top: 0;
        box-shadow: none;
    }
}

/* ==========================================================================
   fm-*  —  the community forum (/forum) and the FAQ (/faq)
   ==========================================================================
   A THIRD namespace in this file, deliberately, beside mk-* (marketing) and
   pf-* (portal).

   🔴 EVERY RULE BELOW CONSUMES var(--…) ONLY AND HARD-CODES NO BRAND HEX. That
   is what makes dark theme work: the tokens flip under 
   and nothing here needs a second definition.

   🔴 NEVER hand-edit wwwroot/css/tokens.css: an MSBuild target overwrites it
   from PTM.UX/src/styles/tokens.css on every build, with an  guard.

   ⚠ THE PREVIOUS VERSION OF THIS BLOCK REFERENCED FIVE CUSTOM PROPERTIES THAT
     TOKENS.CSS HAS NEVER DEFINED — --c-border, --radius-sm, --radius-md,
     --lh-relaxed and --ff-mono. Four carried a fallback and were merely
     hand-copied values pretending to be tokens; --c-border carried NONE, so
     "border-bottom: 1px solid var(--c-border)" on .fm-member__post was invalid
     at computed-value time and the profile page's post separators simply did
     not exist. All five are gone: colours and radii come from the real ramp,
     and the two non-colour locals are declared once, below, as fm-scoped
     properties so they cannot be mistaken for cross-repo tokens.

   The visual language is phpBB prosilver's, expressed in PTM's palette: a
   light ground with the board as a white panel, accent-filled category bars
   with light-on-dark titles, zebra-striped rows with a hover wash, a folder
   glyph in front of every forum, and posts split into an author column and a
   body panel. Nothing here needs JavaScript — this host renders no