/* =============================================================================
   MAIN.CSS — Shawn's Hub, site-wide overrides
   -----------------------------------------------------------------------------
   NOTHING ON THIS SITE HOVERS BLUE. That is a standing rule, not a preference,
   so it is enforced here once for the whole hub rather than patched per screen.

   Astra ships these blues and they leak through anywhere we have not spoken:
     a:hover / a:focus              #191970  (midnight blue)
     link + accent default          #046bd2 / #0170B9
     social element hover           #0274be

   Two layers of defence:
     1. Repoint Astra's own colour variables at our palette, so anything of
        Astra's that we never anticipated still comes out on-brand.
     2. Explicitly override the hover and focus rules above.

   !important is used deliberately and only here. We are overriding a third
   party theme's defaults on a rule that has no exceptions, and losing that
   fight silently is exactly what the rule exists to prevent.
   ============================================================================= */

/* --- 1. Repoint Astra's palette at ours ---------------------------------- */

:root {
	--ast-global-color-0: var(--violet);
	--ast-global-color-1: var(--violet-dk);
	--ast-global-color-2: var(--ink);
	--ast-global-color-3: var(--ink-soft);
	--ast-global-color-4: var(--bg);
	--ast-global-color-5: var(--card);
	--ast-global-color-6: var(--line);
	--ast-global-color-7: var(--ink);
	--ast-global-color-8: var(--violet);

	/* Astra's link variables, used by its dynamic CSS. */
	--ast-link-color: var(--violet);
	--ast-link-hover-color: var(--violet-dk);
}

/* --- 2. Links ------------------------------------------------------------ */

a {
	color: var(--violet);
}

/* The link sweep deliberately skips anything shaped like a button. A button is
   a filled surface, so recolouring its TEXT to the fill colour hides the label
   completely. That is what happened to the directory's Enter buttons: they are
   anchors, this rule caught them, and violet text landed on a violet fill.

   The standing rule is wider than "never blue". It is: text must never end up
   the same colour as what it sits on. Same failure as the chips and the card
   header, third costume. */
/* ONE :not() holding a list, not four chained ones.
   Each :not() contributes its own specificity, so the chained version weighed
   (0,5,1) — heavier than every header rule — and quietly repainted the site
   title violet on the deep-plum header. My own button fix caused that.
   A single :not() takes the weight of its most specific argument, so this is
   (0,2,1): still ahead of Astra's defaults, no longer ahead of our own
   component and chrome rules. */
/* SIXTH costume: .hub-who — a person's NAME, wherever it appears.
   Same mechanism as the nav: the component sets its own hover in profile.css
   and lost to this !important, so hovering a name went violet on the thread
   band, on every comment row and on the crew screen. Shawn: "it should just
   still be the text color rather than this purple. The purple looks funny."
   ⚠️ Excluded here rather than fixed in three places, because .hub-who IS the
   one component all three use. One exclusion, one treatment. */

/* FIFTH costume: .hub-nav-link. The menu sits on the deep-plum masthead, so
   this rule was painting Teams / Lounge / Account violet-dk — a dark colour on
   a dark ground. Shawn: "the links also turn violet, which almost disappears in
   the plum background."
   ⚠️ Same shape as .site-title-link two names along, and for the same reason:
   CHROME ON A DARK GROUND CANNOT TAKE THE LINK COLOUR. nav.css already said
   `.hub-nav-link:hover { color: #fff }` and lost, because (0,2,0) without
   !important cannot beat (0,2,1) with it. The rule looked correct in its own
   file and never painted.
   ⚠️ If a sixth costume turns up, the answer is probably to stop excluding
   components one at a time and scope this rule to content instead.

/* FOURTH costume, and the one that took four attempts: .hub-inbox-filter. An
   active filter pill is a filled violet control with white text, so this rule
   repainted its label violet-dk ON violet and the label vanished.
   Why it survived three fixes: there are TWO link-colour rules in this file,
   this one and the .hub-review a:not(...) block further down. I kept excluding
   the pill from that one, which is not the rule that wins. Both now exclude it.
   ⚠️ A filled control belongs in THIS list, beside .hub-btn and .hub-chip, and
   :focus matters as much as :hover — a tap on a phone leaves focus behind, so a
   hover-only fix cannot touch what he was seeing. */
a:not(.hub-btn, .hub-chip, .hub-door, .hub-back, .hub-inbox-filter, .site-title-link, .hub-nav-link, .hub-who, .lounge-room, .lounge-thread, .lounge-up, .lounge-side-link, .lounge-pager-step, .hub-fp-link, .hub-fp-go):hover,
a:not(.hub-btn, .hub-chip, .hub-door, .hub-back, .hub-inbox-filter, .site-title-link, .hub-nav-link, .hub-who, .lounge-room, .lounge-thread, .lounge-up, .lounge-side-link, .lounge-pager-step, .hub-fp-link, .hub-fp-go):focus,
a:not(.hub-btn, .hub-chip, .hub-door, .hub-back, .hub-inbox-filter, .site-title-link, .hub-nav-link, .hub-who, .lounge-room, .lounge-thread, .lounge-up, .lounge-side-link, .lounge-pager-step, .hub-fp-link, .hub-fp-go):active,
a:not(.hub-btn, .hub-chip, .hub-door, .hub-back, .hub-inbox-filter, .site-title-link, .hub-nav-link, .hub-who, .lounge-room, .lounge-thread, .lounge-up, .lounge-side-link, .lounge-pager-step, .hub-fp-link, .hub-fp-go):focus-visible {
	color: var(--violet-dk) !important;
}

/* Filled controls: darken the FILL on hover, never the text. Stated for both
   anchors and buttons so it holds whichever element a control is built from. */
/* ⚠️ `:not(.hub-btn--ghost)` on every one of these.
   Without it this rule claimed EVERY anchor carrying .hub-btn, ghosts
   included, and forced them white. A ghost button is transparent, so a ghost
   built from an anchor rendered as white text on nothing — an outlined box
   with no words in it. The ghost rules below only ever reclaimed the colour
   on :hover and :focus, neither of which exists at rest or on a touch screen,
   so the button was invisible until somebody happened to hover it.
   Found on the account screen's Sign out link. Every other ghost in the theme
   is a <button> or a <span>, which is why nothing had shown it before — this
   was the first ghost anchor. Narrowing the rule fixes that one and stops the
   next one inheriting the same trap. */
/* ⚠️ The gold variant is excluded for the same reason as the ghost, and it was
   missed the first time: gold is a LIGHT fill, so white text on it is barely
   readable. directory.css already says `.hub-lounge .hub-btn--gold { color:
   #241d33 }`, but that is (0,2,0) against this rule's (0,3,1) and both carry
   !important, so this one won and painted the lounge's Enter button white on
   pale gold. Anything filled and light has to be listed here. */
a.hub-btn:not(.hub-btn--ghost, .hub-btn--gold),
a.hub-btn:not(.hub-btn--ghost, .hub-btn--gold):hover,
a.hub-btn:not(.hub-btn--ghost, .hub-btn--gold):focus,
a.hub-btn:not(.hub-btn--ghost, .hub-btn--gold):visited,
button.hub-btn:not(.hub-btn--ghost, .hub-btn--gold):hover,
button.hub-btn:not(.hub-btn--ghost, .hub-btn--gold):focus {
	color: #fff !important;
}

/* Dark ink on the gold fill, wherever it is used. */
a.hub-btn--gold,
a.hub-btn--gold:visited,
button.hub-btn--gold,
span.hub-btn--gold {
	color: #241d33 !important;
}

/* And the ghost's resting state, stated rather than assumed. */
a.hub-btn--ghost,
a.hub-btn--ghost:visited,
button.hub-btn--ghost,
span.hub-btn--ghost {
	color: var(--violet) !important;
	background: transparent !important;
}

a.hub-btn:hover,
a.hub-btn:focus,
button.hub-btn:hover,
button.hub-btn:focus {
	/* ⚠️ ONE CHANGE PER INTERACTION: the ground darkens, the ink never moves.
	   It swapped to violet-with-white, which reads as the button becoming a
	   different button rather than as the same button responding. */
	background: var(--gold-dk) !important;
}

/* Ghost buttons are outlined, not filled, so they keep violet text on a tinted
   background. Their text and background stay far apart either way. */
a.hub-btn--ghost:hover,
a.hub-btn--ghost:focus,
button.hub-btn--ghost:hover,
button.hub-btn--ghost:focus {
	background: rgba(106, 74, 156, .07) !important;
	color: var(--violet-dk) !important;
}

/* --- 3. Buttons, in every form Astra and WordPress produce ---------------- */

/* This rule is for buttons WordPress and Astra produce — comment forms, block
   buttons, Astra's own chrome — so they hover on-palette instead of blue.
   ⚠️ It must not reach OUR components. It used to, and because it carries
   !important it beat every plain rule in review.css, which is why that file
   accumulated 93 !important declarations of its own: each one was fighting this
   one. Excluding our namespace here removes the conflict at its source rather
   than out-ranking it 93 times.
   [class*="hub-"] keeps the weight identical to the old selector — (0,1,1) —
   so nothing else in the cascade shifts underneath it. */
button:not([class*="hub-"]):hover,
button:not([class*="hub-"]):focus,
.button:hover,
.button:focus,
.ast-button:hover,
.ast-button:focus,
.wp-block-button__link:hover,
.wp-block-button__link:focus,
input[type="button"]:hover,
input[type="button"]:focus,
input[type="reset"]:hover,
input[type="reset"]:focus,
input[type="submit"]:hover,
input[type="submit"]:focus {
	border-color: var(--violet-dk) !important;
}

/* Astra's own accent bits. */
.ast-builder-social-element:hover,
.ast-builder-social-element:focus {
	color: var(--violet-dk) !important;
}

/* --- 4. Focus rings ------------------------------------------------------ */

/* Browsers default the focus ring to blue. Keyboard focus must stay clearly
   visible, so this recolours it rather than removing it. */
:focus-visible {
	outline-color: var(--violet);
}

::selection {
	background: rgba(106, 74, 156, .18);
}

/* --- 5. Forms ------------------------------------------------------------ */

/* ⚠️ A TEXT FIELD INDICATES ITS OWN FOCUS. The caret is the indicator, and it is
   a better one than anything we can draw — it says where you are as well as that
   you are there. Shawn: "we don't need anything to happen. Just have the little
   cursor blinking in there when somebody taps in. That's perfect."

   What was here drew TWO purple lines at once: an outline AND a recoloured
   border. The same pair was written out in five places across four stylesheets,
   so it is removed at each source rather than overridden here — an override would
   have left five rules that look live and paint nothing.

   ⚠️ SELECT IS NOT A TEXT FIELD and keeps its focus ring. It has no caret, so
   taking the indicator away would leave a keyboard with no way to see where it
   is. Same reason buttons, chips and links keep theirs. */
select:focus-visible {
	outline: 2px solid var(--violet);
	outline-offset: 1px;
}

/* ⚠️ `outline: none`, STATED — not simply left unsaid. Removing our own outline
   rule does not remove a ring, it hands the job back to the BROWSER, which draws
   `outline-style: auto`. Shawn saw the result immediately: "it gave a blue edge,
   which is a little awkward."
   ⚠️ AND `:focus-visible { outline-color: var(--violet) }` CANNOT FIX IT. Chrome
   paints an `auto` outline in its own accent colour and ignores outline-color
   altogether — so the computed value reads as our violet while the pixels are
   blue. That is why my check passed on something wrong in front of him: I read
   the colour and never read the STYLE.
   The caret is the indicator for anything you type into. This says so in a way
   the browser cannot override. */
input:focus,
input:focus-visible,
textarea:focus,
textarea:focus-visible,
[contenteditable]:focus,
[contenteditable]:focus-visible {
	outline: none;
}

/* Except the ones that are controls wearing an input's clothes — they have no
   caret, so they keep a ring. */
input[type="checkbox"]:focus-visible,
input[type="radio"]:focus-visible,
input[type="submit"]:focus-visible,
input[type="button"]:focus-visible,
input[type="file"]:focus-visible {
	outline: 2px solid var(--violet);
	outline-offset: 1px;
}

/* --- 6. The hub's own components ---------------------------------------- */

/* Stated again at higher specificity so no Astra rule can reach past the
   component stylesheets and repaint a hover. */
/* These container sweeps must skip button-shaped anchors. `.hub-dir a:hover`
   and `a.hub-btn:hover` have IDENTICAL specificity (0,2,1), so the winner was
   decided purely by which appeared later in the file — and this block does.
   That is why the Enter button kept reading correct in isolation and kept
   losing on the page. Excluding buttons here removes the conflict rather than
   trying to out-rank it. */
/* .hub-inbox-filter joins the exclusions for exactly the reason above. A filter
   pill that is ON is solid violet with white text; this rule was repainting its
   label violet-dk on hover, so the label disappeared into the pill and it read
   as a blank purple lozenge. Excluding it removes the conflict rather than
   fighting an !important with another one. */
/* ⚠️ .hub-fp-go is the THIRD control this rule has repainted, and the pattern
   is now plain enough to state as a rule rather than discovering a fourth time:
   ANY ANCHOR THAT IS A CONTROL BELONGS IN THESE EXCLUSION LISTS. This one was
   turning the gold Enter button's plum ink violet on hover — found by measuring
   it rather than reading, because the component's own rules all said #241d33
   and looked correct in isolation. Shawn: "when you hover, it turns to violet,
   which is kinda awkward looking." */
/* ⚠️ `.hub-fp-link` is the FIFTH name on this list, and I tried to avoid adding
   it. The attempt — a rule stating the plum panel's own link colour after this
   one — could not win: this selector carries four `:not()` arguments, which
   COUNT, making it (0,6,1) with !important. Nothing sane outranks that.
   Measuring the computed colour is what showed the override was dead weight
   pretending to work; it looked correct in the file.

   ⭐ So the exclusion stands for now, and the real answer is the one you
   suggested: INVERT THIS RULE. It should scope to prose — the places that
   contain sentences with links in them — instead of trying to name every
   control that will ever exist. Four controls have been repainted by it so far
   and the list can only grow.
   That is a change across eight screens and it is not a thing to do in the same
   pass as a live bug, so it is written down here rather than half-done. */
.hub-review a:not(.hub-btn):not(.hub-chip):not(.hub-back):not(.hub-inbox-filter):not(.hub-fp-go):not(.hub-fp-link):hover,
.hub-review a:not(.hub-btn):not(.hub-chip):not(.hub-back):not(.hub-inbox-filter):not(.hub-fp-go):not(.hub-fp-link):focus,
.hub-dir a:not(.hub-btn):not(.hub-chip):not(.hub-door):not(.hub-fp-go):not(.hub-fp-link):hover,
.hub-dir a:not(.hub-btn):not(.hub-chip):not(.hub-door):not(.hub-fp-go):not(.hub-fp-link):focus {
	color: var(--violet-dk) !important;
}


.hub-tab:hover,
.hub-tab:focus,
.hub-tab:focus-visible {
	color: var(--violet) !important;
	border-bottom-color: var(--violet) !important;
	background: none !important;
}

/* Chip hover and selected states are defined in review.css, which fills the
   chip with its accent and puts white text on it. They are not repeated here:
   two !important rules for the same thing is how a colour ends up depending on
   file load order. This block only guarantees no chip ever hovers blue. */
.hub-chip:hover,
.hub-chip:focus {
	color: #fff;
}

.hub-btn:hover,
.hub-btn:focus {
	background: var(--gold-dk) !important;
	color: var(--deep, #241d33) !important;
}

.hub-btn--ghost:hover,
.hub-btn--ghost:focus {
	background: rgba(106, 74, 156, .07) !important;
	color: var(--violet-dk) !important;
}





.hub-lounge a:not(.hub-btn):hover,
.hub-lounge a:not(.hub-btn):focus {
	color: var(--gold) !important;
}

/* Inert chips must not react at all. */
.is-soon:hover,
.is-soon:focus {
	background: transparent !important;
	border-color: var(--line) !important;
	color: var(--lash) !important;
}



.hub-source:hover,
.hub-source:focus {
	color: var(--violet-dk) !important;
	border-bottom-color: var(--violet-dk) !important;
}

/* =============================================================================
   HEADER AND FOOTER — the two dark bookends
   -----------------------------------------------------------------------------
   Deep plum, light text, and a 2px gold rule on the inner edge of each: along
   the header's bottom and the footer's top. Astra colours these elements
   directly, so they are stated here explicitly rather than left to inherit.
   ============================================================================= */

/* Backgrounds on every header wrapper, but the gold rule on ONE element only.
   The previous version put the border on both <header class="site-header"> and
   the inner .ast-primary-header-bar, which are adjacent, so the header drew the
   line TWICE and rendered about 4px. The footer drew it once. That, not a faded
   footer, was the mismatch: I had trimmed the wrong side. */
.site-header,
.ast-primary-header-bar,
.ast-main-header-bar,
.main-header-bar,
.ast-header-break-point .main-header-bar {
	background: var(--deep, #241d33) !important;
}

.ast-primary-header-bar,
.ast-main-header-bar,
.main-header-bar,
.ast-main-header-wrap,
.ast-header-break-point .main-header-bar {
	border-bottom: 0 !important;
	box-shadow: none !important;
}

.site-header {
	border-bottom: 2px solid var(--gold) !important;
}

.site-header .site-title,
.site-header .site-title a,
.site-header .site-title a:hover,
.site-header .site-title a:focus,
.site-header .site-description,
.ast-primary-header-bar .site-title a,
.main-header-bar .site-title a {
	color: #fff !important;
}

.site-header .site-description,
.ast-site-identity .site-description {
	color: #cfc6dd !important;
}

/* ⚠️ THIS BLANKET NOW KNOWS WHERE TO STOP, and finding that out cost an hour.
   It exists to keep ASTRA's own header links light on the plum band, and it
   carries !important — so it silently beat every colour the hub's own nav set
   for itself. I rewrote the menu to be quiet chrome, measured it, and the items
   were still #efeaf5 with a gold hover: this rule, not mine, was painting them.

   ⚠️ Same fault as the `.hub-fp span` blanket that kept repainting a button's
   arrow — and the same fix rather than a fourth override on top: the blanket
   excludes the components that state their own colours.

   The exclusions are the hub's own nav and masthead. Everything Astra renders
   into the header is still covered. */
.site-header a:not(.hub-nav-link):not(.hub-mast-link),
.ast-primary-header-bar a:not(.hub-nav-link):not(.hub-mast-link),
.main-header-bar a:not(.hub-nav-link):not(.hub-mast-link),
.main-header-bar .main-header-menu a {
	color: #efeaf5 !important;
}

.site-header a:not(.hub-nav-link):not(.hub-mast-link):hover,
.site-header a:not(.hub-nav-link):not(.hub-mast-link):focus,
.ast-primary-header-bar a:not(.hub-nav-link):not(.hub-mast-link):hover,
.main-header-bar a:not(.hub-nav-link):not(.hub-mast-link):hover,
.main-header-bar .main-header-menu a:hover {
	color: var(--gold) !important;
}

/* The mobile menu toggle sits on the dark band too. */
.ast-mobile-menu-trigger-minimal,
.ast-mobile-menu-buttons-minimal.menu-toggle {
	color: #fff !important;
	background: transparent !important;
}

/* --- footer, mirroring the header ---------------------------------------- */

.site-footer,
.ast-small-footer,
.site-primary-footer-wrap,
.site-below-footer-wrap,
.ast-footer-copyright {
	background: var(--deep, #241d33) !important;
	color: #cfc6dd !important;
}

/* The gold rule runs along the TOP of the footer, mirroring the header's bottom
   edge. Astra's footer is several stacked wrappers, each able to carry its own
   border, so the line looked thicker than the header's: it was being drawn more
   than once. Every inner border is cleared and exactly one 2px line is drawn on
   the outer element. */
.site-footer,
.ast-small-footer,
.site-primary-footer-wrap,
.site-below-footer-wrap,
.ast-footer-copyright {
	border-top: 0 !important;
	box-shadow: none !important;
}

.site-footer {
	border-top: 2px solid var(--gold) !important;
}

.site-footer a,
.ast-small-footer a,
.ast-footer-copyright a {
	color: #efeaf5 !important;
}

.site-footer a:hover,
.site-footer a:focus,
.ast-footer-copyright a:hover {
	color: var(--gold) !important;
}

.hub-credit {
	font-family: 'IBM Plex Mono', ui-monospace, monospace;
	font-size: 12.5px;
	letter-spacing: .06em;
	color: #cfc6dd;
}

/* =============================================================================
   #25 HEADER AND FOOTER ALIGNMENT
   -----------------------------------------------------------------------------
   Astra's header and footer use their own container width, which did not match
   the page body's, so the site title sat further left than the content and the
   nav hung further right. Both are pinned to the same width and padding the
   hub's own screens use, so the three line up on one edge.
   ============================================================================= */

.site-header .ast-container,
.site-header .site-primary-header-wrap > .ast-builder-grid-row-container-inner,
.ast-primary-header-bar .ast-container,
.main-header-bar .ast-container,
.site-footer .ast-container,
.site-primary-footer-wrap .ast-builder-grid-row-container-inner,
.site-below-footer-wrap .ast-container {
	max-width: 1240px !important;
	margin-left: auto !important;
	margin-right: auto !important;
	padding-left: 32px !important;
	padding-right: 32px !important;
}

@media (max-width: 700px) {
	.site-header .ast-container,
	.ast-primary-header-bar .ast-container,
	.main-header-bar .ast-container,
	.site-footer .ast-container,
	.site-below-footer-wrap .ast-container {
		padding-left: 20px !important;
		padding-right: 20px !important;
	}
}

/* =============================================================================
   #29 — SITE TITLE, FORCED VISIBLE
   -----------------------------------------------------------------------------
   The title element and its text ARE in the rendered markup (verified: two
   .site-title elements, both containing the name, one for the desktop bar and
   one for the mobile bar), and no rule in Astra's stylesheet, its inline CSS, or
   ours hides them. Static inspection could not explain why it did not appear.

   So rather than guess again at a cause I cannot see, this states every property
   that could suppress it. If something outside what I can inspect is hiding it,
   this overrides that; if the real cause was elsewhere, this changes nothing and
   costs nothing.
   ============================================================================= */

.site-header .site-branding,
.site-header .ast-site-identity,
.site-header .ast-site-title-wrap,
.site-header .site-title,
.site-header .site-title a,
.site-header .site-title-link {
	display: block !important;
	visibility: visible !important;
	opacity: 1 !important;
	overflow: visible !important;
	clip: auto !important;
	clip-path: none !important;
	text-indent: 0 !important;
	width: auto !important;
	height: auto !important;
	max-height: none !important;
	position: static !important;
	transform: none !important;
}

.site-header .site-title,
.site-header .site-title a,
.site-header .site-title-link {
	font-size: 22px !important;
	line-height: 1.25 !important;
	font-family: 'Merriweather', Georgia, serif !important;
	font-weight: 900 !important;
	color: #fff !important;
	text-decoration: none !important;
	white-space: normal !important;
}

.site-header .site-title a:hover,
.site-header .site-title-link:hover {
	color: var(--gold) !important;
}

/* The bar must have room to show it. */
.site-header,
.ast-primary-header-bar {
	min-height: 64px !important;
}

/* =============================================================================
   #20 — BOTH gold lines doubled, and equal
   -----------------------------------------------------------------------------
   Correcting my own fix. The header originally drew the line twice (two nested
   elements each with a border) and the footer once, so they differed. I
   equalised them by removing the duplicate, which made BOTH thin. What was
   wanted was both THICK. So: one line per side, 4px each.
   ============================================================================= */

.site-header {
	border-bottom: var(--gold-rail) solid var(--gold) !important;
}

.site-footer {
	border-top: var(--gold-rail) solid var(--gold) !important;
}


/* =============================================================================
   #21 — BUTTON LABELS ALWAYS WIN
   -----------------------------------------------------------------------------
   Last block in the file and deliberately specific, so no container rule can
   repaint a button's label. Two defences on purpose: the sweeps above now skip
   buttons, and these out-rank them anyway if a new container rule appears later.

   The general lesson, which is what actually cost the time here: a rule like
   `.container a:hover` and a rule like `a.button:hover` weigh the SAME. Reading
   either one alone tells you nothing about which paints the pixel. That is why
   three "correct" fixes kept failing on screen.
   ============================================================================= */

.hub-dir a.hub-btn:hover,
.hub-dir a.hub-btn:focus,
.hub-review a.hub-btn:hover,
.hub-review a.hub-btn:focus,
.hub-lounge a.hub-btn:hover,
.hub-lounge a.hub-btn:focus,
a.hub-btn:hover,
a.hub-btn:focus,
button.hub-btn:hover,
button.hub-btn:focus {
	color: var(--deep, #241d33) !important;
	background: var(--gold-dk) !important;
}

/* Ghost buttons are outlined, so violet text on a pale tint is the readable
   pairing. Stated at the same weight so it is not caught by the rule above. */
.hub-dir a.hub-btn--ghost:hover,
.hub-dir a.hub-btn--ghost:focus,
.hub-dir button.hub-btn--ghost:hover,
.hub-dir button.hub-btn--ghost:focus,
.hub-review a.hub-btn--ghost:hover,
.hub-review button.hub-btn--ghost:hover,
a.hub-btn--ghost:hover,
button.hub-btn--ghost:hover {
	background: rgba(106, 74, 156, .07) !important;
	color: var(--violet-dk) !important;
}




/* =============================================================================
   #48 — ONE CONTENT WIDTH
   -----------------------------------------------------------------------------
   The site title is the reference. The header container is 1240px with 32px of
   side padding, so every screen uses exactly that and their edges line up with
   the title above them. The review tool had drifted to 1100px/24px, which is
   what made it read narrower than everything else.
   ============================================================================= */

/* The content box is stated ONCE, on Astra's own content container, exactly as
   it is on the header's. Our screens then fill it.

   The previous version set the box on our screens instead, which left them
   nested inside Astra's container and paying BOTH paddings:

     header   1240 - 32 - 32                  = 1176px
     content  (1240 - 20 - 20) - 32 - 32      = 1136px

   40px narrower, and no amount of trimming our own padding would have fixed it
   while both boxes were applying. */
.site-content > .ast-container {
	max-width: 1240px !important;
	margin-left: auto !important;
	margin-right: auto !important;
	padding-left: 32px !important;
	padding-right: 32px !important;
}

/* Astra sets `.site-content .ast-container { display: flex }`, so our screens
   are FLEX ITEMS. A flex item with no grow shrinks to fit its content, which is
   why the landing sat about two thirds wide and left-aligned with empty space
   beside it, while the section pages looked fine purely because their card grid
   happened to be wide enough to fill the row.

   max-width alone could never fix that: it caps a width, it does not claim one.
   flex-grow is what makes the block take the row. */
/* ⚠️ .hub-lounge-wrap was missing from this list and that is exactly what the
   comment above predicts. The lounge screens used to carry .hub-review on their
   outer div, so they were covered by accident; the redesign made
   .hub-lounge-wrap the top-level element and it inherited no correction. Astra
   shrank it to its content, so a forum view — whose content is narrower than
   the front page's — rendered in about a third of the column with the rest
   empty beside it.
   Fixed here rather than with a width on the lounge, which would have looked
   right on that one screen and broken on the next. */
.hub-review,
.hub-dir,
.hub-submit,
.hub-lounge-wrap {
	flex: 1 1 100% !important;
	width: 100% !important;
	min-width: 0 !important;
	max-width: 100% !important;
	margin-left: 0 !important;
	margin-right: 0 !important;
	padding-left: 0 !important;
	padding-right: 0 !important;
}

/* Mobile keeps its breathing room; the fix above is a desktop alignment issue. */
@media (max-width: 700px) {
	.site-content > .ast-container {
		padding-left: 20px !important;
		padding-right: 20px !important;
	}

	.site-header .ast-container,
	.site-footer .ast-container {
		padding-left: 20px !important;
		padding-right: 20px !important;
	}
}

/* =============================================================================
   THE BUTTON STANDARD — one description, every button on the hub
   -----------------------------------------------------------------------------
   ⚠️ Shawn: "the post reply button is much more rounded than the other buttons
   we've been using on the site... let's try to equalize that throughout."

   He was right, and the cause was NOT bbPress. Its stylesheet is dequeued in
   hub-lounge.php and nothing of its own reaches the page — the forum screens
   are hand-built markup. The odd one out was mine: .lounge-btn was invented for
   the lounge with a 999px pill radius, a 15px serif face and its own padding,
   while every other button on the site is 8px / IBM Plex Mono / 12.5px.

   So geometry and type are stated ONCE, here, for all three button classes, and
   the variants only change colour. A button that wants a different shape is a
   signal that the standard is wrong, not a reason to add a fourth class.
   ============================================================================= */

.hub-btn,
.hub-fp-go,
.lounge-btn {
	font-family: 'IBM Plex Mono', ui-monospace, monospace;
	font-size: 12.5px;
	font-weight: 600;
	letter-spacing: .04em;
	line-height: 1;

	display: inline-flex;
	align-items: center;
	justify-content: center;
	gap: 6px;

	/* 44px of tappable height. This crew works on phones. */
	min-height: 44px;
	padding: 0 22px;

	border-radius: 8px;
	border: 0;
	text-decoration: none;
	white-space: nowrap;
	cursor: pointer;
}

/* ⚠️ THE GOLD VARIANT. PLUM INK IN EVERY STATE — REST, HOVER, FOCUS, ACTIVE.
   Never white: gold is a light fill and white on it is barely readable.

   ⭐ AND NEVER ANY OTHER COLOUR EITHER. Shawn talked himself through this and
   landed on the simplest answer: "we don't need to change the colour at all.
   Keep it plum, because the colour of the button itself fades a little when
   it's touched or hovered. That's an indicator enough."

   ONE CHANGE PER INTERACTION. The ground moves and nothing else does. Two
   things changing at once is noise rather than clarity — the same principle
   that took the recolour off the thread cards, which lift instead.

   Stated here for every state so there is one place to look, and nothing
   downstream needs to restate it. */
.hub-fp-go,
.hub-fp-go:link,
.hub-fp-go:visited,
.hub-fp-go:hover,
.hub-fp-go:focus,
.hub-fp-go:focus-visible,
.hub-fp-go:active,
.lounge-btn,
.lounge-btn:hover,
.lounge-btn:focus,
.lounge-btn:focus-visible,
.lounge-btn:active {
	color: #241d33;
}

.hub-fp-go,
.lounge-btn {
	background: var(--gold);
}

/* ⚠️ A STICKY HOVER ON TOUCH MUST STILL BE GOLD, and leaving this out was a
   real regression I introduced and then measured.
   Astra styles `button:hover` with its own accent, which is violet. My gold
   hover used to hold that back everywhere; the moment I scoped it to
   hover-capable devices, a phone had nothing opposing Astra and a stuck :hover
   after a tap painted the gold button VIOLET. Worse than the sticky state it
   was meant to prevent.
   So hover is stated twice on purpose: gold unconditionally, then the darker
   ground only where hovering is a real thing somebody does. */
@media (hover: hover) {
	.lounge-btn:hover {
		background: var(--gold);
	}
}

.lounge-btn:active {
	background: var(--gold);
}

/* ⚠️ THE GROUND MOVES ONLY WHERE HOVER IS REAL. A phone has no hover, and a
   :hover state left unscoped sticks after a tap — the button stays looking
   pressed until something else is touched. Same trap the card hover had. */
@media (hover: hover) {
	.hub-fp-go:hover,
	.lounge-btn:hover {
		background: var(--gold-dk);
	}
}

/* Keyboard focus and touch both get the darker ground, which is the whole of
   the feedback on a device that cannot hover. */
.hub-fp-go:focus-visible,
.lounge-btn:focus-visible,
.hub-fp-go:active,
.lounge-btn:active {
	background: var(--gold-dk);
}

.hub-fp-go:active,
.lounge-btn:active {
	transform: translateY(1px);
}


/* The smaller button, for a secondary control that should not command a corner.
   ⚠️ Its metrics are the CHIP's, not a third size invented for one button —
   .hub-chip is 11.5px type in 8px/14px padding, and the hub already reads that
   as "a control, quietly". */
.hub-btn--sm {
	min-height: 34px;
	padding: 0 16px;
	font-size: 11.5px;
}

/* --- one reset for every button the hub draws ----------------------------- */

/* ⚠️ THE GHOSTED BOX, FIXED ONCE INSTEAD OF SIX TIMES.
   Astra gives every <button> a native appearance, a 4px radius and
   `box-shadow: 0 1px 2px rgba(0,0,0,.05)`. On a control meant to read as a
   WORD — Remove, Edit, Delete — that shadow draws a faint edge hugging the text
   with no padding, which Shawn described three rounds running as "that strange,
   slightly ghosted button" and "a little hard to see button effect".

   ⚠️ It survives `appearance: none`, `border: 0`, `background: none` AND
   `border-radius: 0` — all four were already on .lounge-post-act and none of
   them touches a shadow. Only measuring the Reply LINK beside it, which
   reported `box-shadow: none`, showed what the difference actually was.

   The sweep found the same gap in five more stylesheets: inbox, nav, directory,
   profile and forum-panel declare no appearance reset at all. This is one rule
   so the sixth screen cannot inherit it again.

   ⚠️ Scoped to the hub's own wrappers ON PURPOSE. A blanket `button {}` would
   also strip the WordPress admin bar, which is not ours to restyle.
   ⚠️ And it resets CHROME ONLY. Every component that wants a fill, a border or
   a radius sets its own afterwards and is unaffected — .hub-btn and .hub-chip
   both still paint normally. */
.hub-review button,
.hub-dir button,
.hub-submit button,
.hub-transcribe button,
.hub-inbox button,
.hub-crew button,
.hub-profile button,
.hub-fp button,
.hub-nav button,
.hub-say-bubble button,
.lounge-say button,
.lounge-post button,
.lounge-started button,
.hub-rt button {
	-webkit-appearance: none;
	appearance: none;
	box-shadow: none;
}

/* ⚠️ AND ASTRA'S VIOLET FILL, KILLED FOR EVERY HUB BUTTON IN EVERY STATE. This
   is the purple Shawn hit five times on one inbox card: press and hold, and the
   whole area behind the title and blurb fills solid violet with the text lost
   inside it.

   Astra's injected customizer CSS says
       button:focus, button:hover, … { background-color: var(--ast-global-color-1) }
   and that colour is #56397F — our own violet-dk, which is why it never looked
   like a foreign style. It applies to any bare <button>, and the inbox card IS
   a bare button wrapping a title and a blurb.

   ⚠️ WHY FOUR EARLIER FIXES MISSED IT. The override existed. It was written as
       @media (hover: hover) { .hub-inbox-open:hover { background: none } }
   and a phone has no hover media, so on his screen the override was not there
   at all while Astra's unconditioned rule was. It measured perfectly on a
   desktop every time. A held finger IS a hover — that is the third bug from
   this exact assumption, so the reset is unconditional here and belongs to no
   media query, ever.

   ⚠️ `:where()` so this contributes NOTHING to specificity. It lands at (0,1,1)
   — level with Astra's own rule, winning on source order — which leaves every
   component free to paint its own hover with a plain class at (0,2,0). .hub-btn
   and .hub-chip still fill exactly as they did; this only takes back the states
   nobody asked Astra to paint. */
:where(.hub-review, .hub-dir, .hub-submit, .hub-transcribe, .hub-inbox, .hub-crew,
	.hub-profile, .hub-fp, .hub-nav, .hub-say-bubble, .lounge-say, .lounge-post,
	.lounge-started, .hub-rt) button:hover,
:where(.hub-review, .hub-dir, .hub-submit, .hub-transcribe, .hub-inbox, .hub-crew,
	.hub-profile, .hub-fp, .hub-nav, .hub-say-bubble, .lounge-say, .lounge-post,
	.lounge-started, .hub-rt) button:focus,
:where(.hub-review, .hub-dir, .hub-submit, .hub-transcribe, .hub-inbox, .hub-crew,
	.hub-profile, .hub-fp, .hub-nav, .hub-say-bubble, .lounge-say, .lounge-post,
	.lounge-started, .hub-rt) button:active {
	background-color: transparent;
}


/* =============================================================================
   #22 — THE REPLY CHIP ON THE SEAM
   -----------------------------------------------------------------------------
   ⚠️ AT THE END OF THE FILE, AND THAT POSITION IS THE POINT. Block #21 above is
   `button.hub-btn:focus { background: var(--gold-dk) !important }` — the same
   weight as anything written for this chip, so whichever comes LAST paints the
   pixel. Stated earlier in the file, every one of these rules measured correct
   and lost on screen, which is the lesson #21 already records in its own words:
   "Reading either one alone tells you nothing about which paints the pixel."

   Shawn saw the result of that: a chip that turned gold with black text and
   picked up a purple ring on tap, three changes at once, in a shape that matched
   nothing else on the page. "Awkward" was the right word.

   The chip is a member of the button family — `.hub-btn .hub-btn--ghost
   .hub-btn--sm` gives it the shape, the type and the height every other control
   here uses. What follows is only what is different about this one.
   ============================================================================= */

/* ⚠️ A SMALL GOLD BAR, AND NOTHING ELSE. Shawn's design, specified in his own
   words after three rounds of mine: "no outlines, no popping out, no nothing."

   ⚠️ AND IT DOES NOT CHANGE WHEN IT OPENS. Not on hover, not on focus, not on
   tap — the arrow turns and that is the entire feedback. Every state is stated
   here so nothing is left to a default: the previous version kept `:focus` after
   a tap and painted a 7% violet wash, which let the gold bar show straight
   through the button and through the word on it. That translucency was the
   fault, not the colour.

   Dark ink, taken from this file's own gold rule rather than chosen: gold is a
   light FILL in this palette and white on it is barely readable. */
button.lounge-here-chip,
button.lounge-here-chip:hover,
button.lounge-here-chip:focus,
button.lounge-here-chip:focus-visible,
button.lounge-here-chip:active {
	min-height: 26px;
	padding: 0 12px;
	font-size: 11px;
	gap: 5px;

	background: var(--gold) !important;

	/* ⚠️ CREAM, NOT THE DARK INK — and this deliberately reverses the rule a few
	   blocks up that says a gold fill takes plum. Shawn overrode it for this one
	   control, with a reason: "let's change it to be cream, like the background of
	   the card above it. That'll kind of help it flow more nicely." The chip rides
	   the seam of that cream card, and wearing the card's own colour ties it to
	   what it belongs to instead of reading as a separate object sitting on a bar.

	   ⚠️ THE CARD'S TOKEN, BY NAME. Sampling its hex would give two colours that
	   match today; naming --l-warm is what makes them the same colour. It inherits
	   down from .hub-lounge-wrap, which this chip is always inside. */
	color: var(--l-warm, #FBF7F0) !important;
	border: 0 !important;
	box-shadow: none !important;
	transform: none;
}

/* ⚠️ THE ONE EXCEPTION, AND IT IS KEYBOARD-ONLY. `:focus-visible` never fires on
   a tap, so this is invisible to him and to anyone using a finger — it exists so
   somebody tabbing through the thread can see where they are. Removing it would
   be the only way to make a control on this site unreachable by keyboard.
   Reported rather than assumed. */
button.lounge-here-chip:focus-visible {
	outline: 2px solid var(--deep, #241d33);
	outline-offset: 2px;
}

button.lounge-here-chip:focus:not(:focus-visible) {
	outline: none;
}

/* The arrow says what will happen; turning it says it has. */
.lounge-here-arrow {
	display: block;
	transition: transform .32s cubic-bezier(.4, 0, .2, 1);
}

.lounge-here.is-open .lounge-here-arrow {
	transform: rotate(180deg);
}

@media (prefers-reduced-motion: reduce) {
	.lounge-here-arrow {
		transition: none;
	}
}


/* =========================================================================
   AN EMPTY FLEX CHILD STILL CLAIMS THE GAP
   ====================================================================== */

/* ⚠️ TWICE IN ONE HOUR, SO IT IS A RULE RATHER THAN TWO PATCHES.
   The review tool's "sent to layout" stamp renders empty until a section has
   been sent, and the search box's status line renders empty until there is
   something to say. Both are flex children, and an EMPTY child is still a
   child — so the container's gap sat between the visible thing and whatever
   came next, and nobody could see what was holding the space.

   It cost 10px of a button's right alignment and 12px under the search field,
   and in both cases the space appeared to belong to a neighbour that was not
   producing it. That is the hardest kind of spacing fault to find, because the
   element responsible has no ink.

   ⚠️ These are elements that are EMPTY BY DESIGN and fill in later — not a
   blanket :empty rule, which would catch things that are legitimately blank
   boxes. Add to this list; do not generalise it to every element. */
.hub-commit-stamp:empty,
.hub-search-status:empty,
.hub-inbox-elsewhere-count:empty {
	display: none;
}