/*
 * Quick task 260810-1ld (Teil C of Cowork's AUFTRAG_Claude_Code_Finale_Politur.md):
 * site-wide responsive/mobile stylesheet.
 *
 * This file is enqueued with a dependency on the `bricks-frontend-inline` handle (see
 * functions.php), which is WordPress' handle for the PCG global CSS Bricks prints inline
 * in <style id="bricks-frontend-inline-inline-css">. That inline block is printed AFTER
 * every child-theme <link> tag, so this file MUST print after it too, or every
 * equal-specificity `!important` tie against the Bricks Custom CSS is lost (discovered
 * fact 1). The PCG global CSS in Bricks stays the owner of desktop design; this file's
 * header used to claim it owns responsive/mobile behaviour only, but that claim was
 * already outdated in practice before quick task 260811-6od (the CTA band, the focus
 * rings and several per-element rules further below are all all-width rules) - as of
 * 260811-6od it also explicitly owns site-wide button corner geometry (see section 6
 * below). The one deliberate exception stays exceptional: that geometry work lives HERE
 * and not in pcg-typecase.css, because pcg-typecase.css's own header and its own test
 * define it as typographic-case-only, and corner geometry is not case.
 *
 * Sections, in the order tasks added them:
 *   1. Mobile header switch (Task 1) - collapses .pcg-header's rigid 3-column desktop
 *      grid to a logo+burger row below 1024px, closing the 768-1024px tablet gap where
 *      Bricks' own mobile-menu breakpoint (767px) still left the full desktop menu
 *      rendering inside the header grid.
 *   2. Full-screen navy burger overlay (D-01) - restyles Bricks' OWN mobile-menu markup
 *      (.bricks-mobile-menu-wrapper / .bricks-mobile-menu-toggle) into the locked design.
 *      No JavaScript is added anywhere in this file - Bricks' bricks.min.js already owns
 *      every behaviour (open/close, aria-expanded, body.no-scroll, Escape-to-close, focus
 *      trap, resize-auto-close, and - confirmed by reading the shipped bricks.min.js for
 *      this task - the toggle's own three-bar-to-X rotate/fade transform, driven purely by
 *      the .show-mobile-menu state class). This file only restyles colour, size and
 *      typography on top of that existing behaviour.
 *   3. Horizontal-overflow fixes (C2) - a structural clamp on .pcg-cardgrid's auto-fit
 *      track floor, a global image safety net, wide-block (table/pre/code) wrapping, and a
 *      narrow min-width:0 safeguard on the known PCG grid/flex containers. The before/after
 *      slider's own max-width hardening lives in before-after.css instead (that file
 *      already owns .pcg-ba-wrap's box model - see its own header comment).
 *   5. Reference cards - compact typography + 4/2/1 column density (C2b, see scope_flag
 *      in the plan). Task 4's audit found that three of the brief's typography asks
 *      (title ~17px/700, trades line 11px uppercase red, meta text 13.5px muted) and the
 *      desktop 4-column rule were ALREADY live in the Bricks Custom CSS field before this
 *      quick task started - this section only adds what was still missing: the phone/
 *      tablet column breakpoints and one consistent vertical spacing step between card
 *      text rows (today's mixed 12px/5px margins). See design-exports/PCG_GlobalCSS_
 *      bereinigt.css for the pre-existing rules this section layers on top of.
 *   6. Button corner-radius sharpening + header CTA compaction, and the homepage mobile
 *      alignment audit/fix for "Ausgewaehlte Projekte" vs. its "Referenzen" eyebrow
 *      (quick task 260811-6od, client round-2 live-feedback items) - same one-commit,
 *      one-file-plus-tests contract as every round before this one.
 */

/* ============================================================
   TASK 1 — Mobile header switch (below 1024px)
   ============================================================
   .pcg-header ships from the Bricks Custom CSS as `display:grid !important;
   grid-template-columns:1fr auto 1fr !important` (design-exports/PCG_GlobalCSS_bereinigt.css).
   Both rules are unlayered (not inside @layer bricks) and use !important, so this is a
   genuine equal-specificity/equal-importance tie - only cascade PRINT ORDER decides the
   winner (discovered fact 1), which is exactly why the dependency above exists.

   .pcg-header's three direct children are, in DOM order: (1) the logo link, (2) a
   .brxe-container wrapping Bricks' own #brxe-wuhdoo nav-menu element (desktop menu +
   burger toggle + the mobile overlay's own markup all live inside this one child), and
   (3) the header CTA button. Targeted by :nth-child() position, not by the generated
   #brxe-* IDs, which change if the element is ever rebuilt in the Bricks builder. */
@media (max-width: 1023px) {
	/* LIVE BUG FOUND 2026-08-10 (client phone report, this session's own Chrome measurement):
	 * the header's own element (#brxe-sjadth) is styled `width:var(--content-width)` with no
	 * responsive override at any breakpoint, and that custom property resolves to the
	 * unitless value "1000" wherever it is currently defined - an invalid `width` value that
	 * the browser drops, falling back to a Bricks container default rather than anything this
	 * project controls. On top of that, `.pcg-header` itself carries NO horizontal padding of
	 * its own (confirmed via getComputedStyle: 0px) - at desktop its fixed/centred width just
	 * happens to leave visible margin either side, but that is incidental, not a real padding
	 * rule, and nothing here matched `.pcg-wrap`'s explicit 24px/20px side-padding convention.
	 * Give the header an explicit, self-contained width + padding on mobile instead of relying
	 * on that variable at all. */
	.pcg-header {
		display: flex !important;
		flex-wrap: nowrap !important;
		align-items: center !important;
		gap: 16px !important;
		width: 100% !important;
		max-width: 100% !important;
		box-sizing: border-box !important;
		padding-left: 20px !important;
		padding-right: 20px !important;
	}
	.pcg-header > *:nth-child(1) {
		/* Logo stays first/leftmost. flex-shrink:0 is the actual fix for the "Logo viel zu
		 * klein" live report: without it, the logo (also a fixed-width Bricks element,
		 * #brxe-* width:160px) shared the shrink budget with the oversized nav container
		 * below and got squeezed down hard alongside it. The logo's own width is intentionally
		 * left alone - restoring it to its real 160px by removing the shrink pressure is the
		 * whole fix, not a new size value. */
		order: 1;
		flex-shrink: 0;
	}
	.pcg-header > *:nth-child(3) {
		/* CTA button: margin-left:auto consumes all remaining flex space, pushing itself
		 * (and the burger container right after it, in source/DOM order) to the right
		 * edge - this is what "right-aligned" means here, not text-align. */
		order: 2;
		margin-left: auto;
	}
	.pcg-header > *:nth-child(2) {
		/* LIVE BUG FOUND 2026-08-10: this nav container (#brxe-* wrapping the desktop menu +
		 * burger toggle) carries its own fixed Bricks width:550px with flex-shrink:1 and
		 * justify-content:space-evenly - all still active here because nothing in Task 1's
		 * original rules touched them. At any width narrower than logo+gap+550px (i.e. every
		 * real phone/tablet), flexbox shrank this 550px box down, but the visible toggle
		 * (the only visible child once the desktop menu is display:none) stayed positioned by
		 * space-evenly INSIDE that shrunk box, not flush against the header's real right edge -
		 * this is the "Menü komisch platziert" live report. width:auto collapses the box to
		 * its actual visible content (just the toggle), so margin-left:auto on THIS element
		 * now pushes the toggle itself to the true right edge.
		 *
		 * SECOND LIVE BUG FOUND during this fix's own verification: the same Bricks
		 * `.brxe-container` default also carries `margin:0 auto` (centering behaviour meant
		 * for the OLD 550px-wide box). Once width collapses to content, that still-active
		 * auto margin-RIGHT splits the freed-up space 50/50 between both sides instead of
		 * letting margin-left:auto (below) claim all of it - the toggle ended up stranded in
		 * the middle of the header, not at the true right edge, even after the width fix
		 * above. margin-right:0 here removes it from the auto-margin distribution entirely. */
		order: 3;
		width: auto !important;
		flex: 0 0 auto !important;
		margin-right: 0 !important;
	}

	/* Close the 768-1024px tablet gap (discovered fact 3): Bricks' own breakpoint only
	 * swaps menu<->toggle below 767px, so between 768-1024px the full desktop menu was
	 * still rendering inside the now-flex header, which is exactly the overflow risk
	 * this task removes. Both Bricks rules being overridden below live inside
	 * `@layer bricks` (wp-content/themes/bricks/assets/css/frontend-layer.min.css) with
	 * no !important, so any plain unlayered declaration beats them outright regardless
	 * of print order (discovered fact 4) - no !important needed here.
	 * `.bricks-nav-menu-wrapper` (desktop menu) and `.bricks-mobile-menu-wrapper` (the
	 * overlay's own nav) are two entirely distinct Bricks component classes, not
	 * modifiers of one another, so this selector cannot also hide the overlay menu. */
	.pcg-header .bricks-nav-menu-wrapper {
		display: none;
	}
	.pcg-header .bricks-mobile-menu-toggle {
		display: flex;
	}
}

@media (max-width: 519px) {
	/* D-01's "Logo + Burger" intent: below 520px the header CTA button disappears
	 * entirely so the row is logo plus burger only. The CTA stays reachable on tablet
	 * (768-1023px) per the plan. Re-target the auto-margin onto the now-guaranteed-
	 * visible burger container (nth-child(3), the CTA, is display:none and so drops out
	 * of flex layout entirely - its own margin-left:auto would no longer push anything).
	 * This block is a narrower max-width query nested inside the 1023px block above and
	 * comes later in the file, so for the shared nth-child(2)/(3) selectors (identical
	 * specificity to the block above) normal cascade source-order rules pick this block's
	 * declarations at widths where both queries are simultaneously true. */
	.pcg-header > *:nth-child(3) {
		display: none;
	}
	.pcg-header > *:nth-child(2) {
		margin-left: auto;
	}
}

/* ============================================================
   TASK 2 — Full-screen navy burger overlay (D-01), CSS-only
   ============================================================
   Bricks' own markup for the mobile menu (read live from
   wp-content/themes/bricks/assets/css/frontend-layer.min.css and bricks.min.js while
   building this task):

   - `.brxe-nav-menu .bricks-mobile-menu-wrapper` is ALREADY position:fixed, full-height
     (via --bricks-vh, a JS-computed dynamic-viewport-height custom property immune to
     mobile browser chrome clipping - no dvh unit or fallback needed from this file),
     width:300px, dark grey (#23282d, painted by its own ::before pseudo-element).
   - Opening sets `.show-mobile-menu` on the ancestor `.brxe-nav-menu`, which drives
     `opacity:1 !important; transform:translateX(0) !important; visibility:visible` on the
     wrapper (all declared inside `@layer bricks`, importance-reversed per CSS Cascade
     Layers - a layered !important beats an unlayered one, so this file does not fight
     those three properties and does not need to: translateX(0) is already the exact
     neutral/no-offset position this task wants, i.e. functionally a fade to the eye, not
     a slide, once fully open).
   - The toggle's own three bars already rotate into an X and fade the centre bar via
     `.brxe-nav-menu.show-mobile-menu .bricks-mobile-menu-toggle .bar-*` (also in
     frontend-layer.min.css) - this file adds no second close control and no transform of
     its own for the bars, only a colour override.
   - Stacking is already correct without any z-index/position override from this file:
     the sticky header (`#brx-header.brx-sticky`) is z-index:998, the open wrapper is
     z-index:999 (covers the header), and the open toggle is z-index:1000 (stays clickable
     above the overlay it is part of) - all Bricks defaults, confirmed live.

   What THIS file still needs to add: navy colour (D-01, over Bricks' grey default), full
   viewport width (Bricks' own 300px + max-width:100vw!important open-state currently
   yields a 300px-wide off-canvas panel, not full-screen), a comfortable top padding,
   scrollable overflow for a link list taller than the viewport, and large white,
   non-uppercase link typography (the desktop nav's small uppercase style is inherited
   from #brxe-wuhdoo and must stay untouched there - see the discovered-fact comment in
   the plan; scoping every rule below to .bricks-mobile-menu-wrapper keeps this file from
   touching the desktop nav at all). */

.bricks-mobile-menu-wrapper {
	/* All properties below are normal-importance and live inside @layer bricks with no
	 * !important (confirmed above), so this plain unlayered rule beats them outright
	 * regardless of print order (discovered fact 4) - no !important needed here either. */
	width: 100vw;
	overflow-y: auto;
	overflow-x: hidden;
	/* Clears the sticky header row before the first link. */
	padding-top: 110px;
	padding-bottom: 32px;
}

.bricks-mobile-menu-wrapper::before {
	/* This pseudo-element is what actually paints the panel (z-index:-1 behind the
	 * content, per Bricks' own base rule) - #142440 is this project's navy ink, same
	 * design-token-with-hex-fallback form as body.home.pcg-scrolled header.brx-sticky
	 * a few lines below in the Bricks Custom CSS mirror. */
	background-color: var(--color-navy, #142440);
}

.bricks-mobile-menu-wrapper.left {
	/* Explicit, not load-bearing: Bricks' own open-state rule already forces
	 * transform:translateX(0) !important once .show-mobile-menu is active (see comment
	 * above), so the panel never actually renders offset while visible. This just
	 * documents/neutralises the closed-state -100% slide-in transform so nobody has to
	 * re-derive that reasoning from frontend-layer.min.css again. */
	transform: translateX(0);
}

/* Top-level links: large, white, no inherited uppercase, comfortable tap height, hairline
 * separators between rows. Scoped to .bricks-mobile-menu-wrapper only, so the desktop
 * nav's small uppercase typography (inherited from #brxe-wuhdoo) is completely untouched. */
.bricks-mobile-menu-wrapper a {
	text-transform: none;
	letter-spacing: normal;
	font-size: 24px;
	font-weight: 700;
	color: #fff;
	padding: 0 32px;
}

/* LIVE BUG FOUND 2026-08-10 (client phone report: "Texte verschwinden am Rand"). The Bricks
 * Custom CSS mirror has `.pcg-header > *:nth-child(2) a{ white-space:nowrap !important; }`,
 * written only for the single-line DESKTOP menu row - but the mobile overlay's links live
 * structurally inside that same nth-child(2) container, so they inherit the nowrap too.
 * Combined with `.bricks-mobile-menu-wrapper{ overflow-x:hidden }` above, any link label
 * wider than the overlay's available width (easy at 24px/700 on a narrow phone) silently
 * clips instead of wrapping - the text does not shrink, it disappears past the edge.
 * Specificity of the culprit rule is (0,2,1) (.pcg-header + :nth-child + a); this selector
 * matches that exactly, so this file's later print order settles the tie in favour of
 * wrapping again, restoring normal multi-line text inside the overlay only. */
.pcg-header .bricks-mobile-menu-wrapper a {
	white-space: normal !important;
}

.bricks-mobile-menu > li {
	border-bottom: 1px solid rgba(255, 255, 255, 0.15);
}

.bricks-mobile-menu > li:last-child {
	border-bottom: none;
}

/* Submenus ("Leistungen", "Projekt Planen"): Bricks switches these to click-toggle inside
 * an open mobile menu (li.open > .sub-menu{display:block}, already native) - keep them
 * reachable as an indented, slightly dimmed sub-list rather than hiding them. */
.bricks-mobile-menu-wrapper .sub-menu a {
	font-size: 18px;
	font-weight: 500;
	color: rgba(255, 255, 255, 0.72);
	padding-left: 52px;
}

.bricks-mobile-menu-wrapper .sub-menu li {
	border-bottom: none;
}

/* Toggle bars use background-color:currentColor (Bricks base rule), so setting `color`
 * here makes the three bars - and, once open, the X they rotate into - render white
 * against the navy header, matching D-01. No position/z-index override needed (see the
 * stacking note above - Bricks' own z-index:1000-while-open already keeps this control
 * clickable above the full-screen overlay it belongs to). */
.pcg-header .bricks-mobile-menu-toggle {
	color: #fff;
}

/* Explicit three-bar-to-X transform, deliberately restated here even though Bricks'
 * frontend-layer.min.css already drives an identical rotate/fade on these same selectors
 * while .show-mobile-menu is active (confirmed by reading that file for this task). Kept
 * here anyway, at matching values, as this project's own explicit contract for D-01's "X
 * close control" requirement - robust against a future Bricks core update silently
 * changing or removing its own default animation. No second close button is added; this
 * still targets Bricks' one existing toggle button, so its aria-label/aria-expanded
 * bookkeeping stays untouched. */
/* Quick task 260818-l6o (audit finding 6, D-01): re-expressed as a transform-only
 * animation so `top` never appears in a transition list - a layout property (`top`)
 * animating alongside transform/opacity forces the browser to run layout on every
 * frame instead of staying on the compositor. All three bars are pinned to a constant
 * `top: 50%; bottom: auto;` at this selector's own 0-2-0 specificity (matching/edging
 * out Bricks core's own rule on load order), and both the at-rest spacing and the
 * open-state motion are expressed as `translateY` instead. `--pcg-burger-bar-gap`
 * carries the rest spacing as a tunable knob (this repo's established `var(--x,
 * fallback)`-with-no-`:root` idiom) - Bricks' own core CSS (not in this repo) sets the
 * real at-rest bar spacing, so 7px here is an informed default; correcting it is a
 * single-value edit. */
.bricks-mobile-menu-toggle span {
	transition: transform 0.25s ease, opacity 0.25s ease;
}

.bricks-mobile-menu-toggle .bar-top,
.bricks-mobile-menu-toggle .bar-center,
.bricks-mobile-menu-toggle .bar-bottom {
	top: 50%;
	bottom: auto;
}

.bricks-mobile-menu-toggle .bar-top {
	transform: translateY(calc(-50% - var(--pcg-burger-bar-gap, 7px)));
}

.bricks-mobile-menu-toggle .bar-center {
	transform: translateY(-50%);
}

.bricks-mobile-menu-toggle .bar-bottom {
	transform: translateY(calc(-50% + var(--pcg-burger-bar-gap, 7px)));
}

.brxe-nav-menu.show-mobile-menu .bricks-mobile-menu-toggle .bar-top {
	transform: translateY(-50%) rotate(45deg);
}

.brxe-nav-menu.show-mobile-menu .bricks-mobile-menu-toggle .bar-center {
	opacity: 0;
}

.brxe-nav-menu.show-mobile-menu .bricks-mobile-menu-toggle .bar-bottom {
	transform: translateY(-50%) rotate(-45deg);
}

/* Local reduced-motion block, immediately after the burger rules (this repo's
 * established per-feature-local convention - see ai-visualizer.css, pcg-gallery.css,
 * berlin-map.css; not folded into the shared pcg-motion.css, which owns only the
 * scroll-reveal/hover system). */
@media (prefers-reduced-motion: reduce) {
	.bricks-mobile-menu-toggle span {
		transition: none;
	}
}

/* Homepage's transparent sticky header (quick task 260809-pj7): while the mobile menu is
 * open, Bricks' own MutationObserver on .show-mobile-menu sets body.no-scroll for exactly
 * the duration the overlay is visible (confirmed by reading bricks.min.js for this task -
 * a MutationObserver watches the `show-mobile-menu` class specifically, toggling
 * body.no-scroll in lockstep with it) - so hooking that class here needs no new script and
 * forces the header solid navy so it never renders transparent behind/above the overlay.
 * The existing body.home:not(.pcg-scrolled) transparent-at-rest rule (Bricks Custom CSS)
 * is untouched; this rule only wins while no-scroll is actually present. Specificity is
 * already higher than that rule on its own (extra .no-scroll class), so this would win
 * even without the later print order this file already has. */
body.home.no-scroll header.brx-sticky {
	background: var(--color-navy, #142440) !important;
}

/* ============================================================
   TASK 3 — Horizontal-overflow fixes (C2)
   ============================================================
   Working through global classes and a small number of safety rules rather than
   per-element overrides (C3's "one maintainable place" recommendation, see the plan's
   Task 6 and this file's own header comment). Every fix below is a genuinely width-
   agnostic clamp, or is scoped inside a max-width media query - no existing desktop rule
   is weakened. */

/* .pcg-cardgrid's auto-fit track floor (discovered fact 9): the live/mirror rule is
 * `repeat(auto-fit,minmax(280px,1fr))` with NO !important, so a plain unlayered override
 * with equal specificity wins on later print order alone. min(280px,100%) means the track
 * floor can never exceed the container - at any viewport 280px or wider (essentially every
 * real device) this is pixel-identical to before; only below 280px does the clamp actually
 * engage. Desktop's separate 4-column rule (`@media (min-width:1000px)`, live-only, not yet
 * in the repo CSS mirror - see Task 4) is untouched, since 100% of a wide container is
 * always far more than 280px there. */
.pcg-cardgrid {
	grid-template-columns: repeat(auto-fit, minmax(min(280px, 100%), 1fr));
}

/* Global image safety net: no image inside a PCG section can exceed its container width.
 * Deliberately low-specificity (single descendant selector) so every more specific
 * component rule already defined elsewhere (.pcg-card-media img, .pcg-media img, etc.)
 * keeps winning unchanged - this only catches a plain, otherwise-unstyled <img> dropped
 * directly into a .pcg-section (e.g. WYSIWYG body content). .pcg-media img's own fixed
 * min-height (380px) is a HEIGHT constraint and cannot itself cause horizontal overflow -
 * reduced instead at the existing 520px breakpoint below so a narrow phone does not get an
 * unnecessarily tall image box. */
.pcg-section img {
	max-width: 100%;
}

@media (max-width: 520px) {
	.pcg-media img {
		min-height: 220px;
	}
}

/* Wide blocks (tables, pre/code): the PAGE must never scroll sideways, so any intrinsic
 * minimum width gets contained to a horizontally-scrollable box of its own instead. */
table {
	display: block;
	max-width: 100%;
	overflow-x: auto;
}

pre,
code {
	max-width: 100%;
	overflow-x: auto;
}

/* Grid/flex children refusing to shrink below their content width (the classic CSS grid/
 * flexbox overflow cause - a grid/flex item's default min-width is `auto`, i.e. its own
 * content's intrinsic width, not 0). Scoped to the known PCG grid/flex containers rather
 * than every element site-wide. */
.pcg-cardgrid > *,
.pcg-boxgrid > *,
.pcg-2col > *,
.pcg-form-grid > *,
.pcg-steps > * {
	min-width: 0;
}

/* Before/after slider on phone widths: an instance with no --pcg-ba-height set (the
 * common case) resolves height:auto (natural aspect ratio), which on a very tall source
 * photo can render an excessively tall box on a narrow phone. This is a bounded SAFETY
 * CEILING, not a fixed height - it applies in addition to whatever height the instance's
 * own custom properties already resolve to (before-after.css), never replacing them. The
 * width-overflow side of this component is hardened separately in before-after.css
 * (that file owns .pcg-ba-wrap's box model); this file only owns the responsive height
 * ceiling and the 820px 2-column-hero stacking check below. */
@media (max-width: 520px) {
	.pcg-ba,
	.pcg-ba__single {
		max-height: 60vh;
	}
}

/* LIVE BUG FOUND 2026-08-10 (real iPhone report + this session's own re-check with a
 * genuinely narrow browser window, not simulated): the Bricks Custom CSS mirror's own
 * `@media (max-width:820px){ .pcg-2col{ grid-template-columns:1fr; } }` rule is present,
 * verified live in the actual <style id="bricks-frontend-inline-inline-css"> markup, and
 * the media query itself DOES match (window.matchMedia confirmed true) - yet
 * getComputedStyle(...).gridTemplateColumns still reports a single desktop-sized pixel
 * track (e.g. "1100px") instead of resolving to the container's real width. No inline
 * style attribute and no matching CSS rule for the element's own ID could be found in this
 * session's investigation - the exact Bricks-internal mechanism produces the desktop track
 * size regardless. Effect: on `/ueber-uns/` and every project-detail page using `.pcg-2col`
 * (the before/after hero AND, on Über-uns, `.pcg-media` image+text rows), the whole row -
 * image, heading, body text - renders at ~1100px width inside a much narrower viewport,
 * which is exactly the "Bild und Text übersteigen den Rand" live report. Rather than
 * depend on a single class selector whose responsive behaviour has proven unreliable on
 * this specific site, force the collapse explicitly with !important - this file prints
 * after the Bricks Custom CSS and matches equal-or-higher specificity, so it wins
 * regardless of whatever upstream mechanism is producing the wrong value.
 *
 * ROOT CAUSE FOUND (in-browser diagnosis, same session): a bare `1fr` track's automatic
 * MINIMUM size defaults to `auto` (≈ the widest child's min-content/intrinsic size), not 0 -
 * the classic CSS Grid "blowout" gotcha. `.pcg-2col > *{min-width:0}` (Task 3) resets each
 * CHILD's own min-width, but the TRACK's automatic minimum is a separate calculation and
 * still let a large image's intrinsic size win in this case. `minmax(0, 1fr)` fixes the
 * TRACK itself, exactly mirroring the desktop rule above (which already correctly uses
 * `minmax(0, 1.1fr) minmax(0, 1fr)`, never a bare `fr`) - confirmed live via
 * `col.style.setProperty('grid-template-columns','minmax(0,1fr)','important')` before
 * writing this rule: computed value dropped from a fixed "1100px" to the container's real
 * resolved width. */
@media (max-width: 820px) {
	.pcg-2col {
		grid-template-columns: minmax(0, 1fr) !important;
		gap: 32px !important;
	}
}

/* ============================================================
   TASK 5 — Reference cards: compact typography + 4/2/1 density (C2b)
   ============================================================
   Live audit (Task 4) confirmed .pcg-cardgrid (without the --2 modifier) is used ONLY by
   the Referenzen grid across all 11 audited URLs today - the homepage's own 4-project
   teaser already uses the separate .pcg-cardgrid--2 variant. The pre-existing live
   `.pcg-cardgrid:not(.pcg-cardgrid--2)` desktop-4-column rule this section extends below
   is therefore already effectively scoped to just the Referenzen grid in practice, with
   no sibling grid it could accidentally affect - a real distinguishing modifier class
   was not added on top, to stay consistent with that already-live scoping pattern rather
   than introduce a second, competing one. If a second plain .pcg-cardgrid grid is ever
   added elsewhere, this scoping choice needs revisiting. */

/* Phone: 1 column, at the same 640px threshold D-03 already uses for .pcg-cardgrid--2 -
 * deliberately the SAME breakpoint, not a new competing one. */
@media (max-width: 640px) {
	.pcg-cardgrid:not(.pcg-cardgrid--2) {
		grid-template-columns: 1fr;
	}
}

/* Tablet: exactly 2 columns, deterministic rather than relying on auto-fit's incidental
 * behaviour at any particular container width. */
@media (min-width: 641px) and (max-width: 999px) {
	.pcg-cardgrid:not(.pcg-cardgrid--2) {
		grid-template-columns: repeat(2, minmax(0, 1fr));
	}
}

/* Desktop 4-column density is already live (design-exports/PCG_GlobalCSS_bereinigt.css,
 * @media (min-width:1000px)) - not restated here, this file only adds the two ranges
 * below it that were still missing. */

/* One consistent vertical spacing step between card text rows, replacing today's mixed
 * margins (12px on the heading vs 5px on every other row - the brief's own complaint).
 * The distinct 16px gap between the image and the first text row directly after it
 * (.pcg-card-media + .brxe-text-basic, the trades line) is a deliberate, separate design
 * decision - kept AS-IS, not touched here - distinguishing "image-to-text transition"
 * from "text-row-to-text-row rhythm"; its own more specific selector already keeps
 * winning over the broader rule below regardless. Same selector text and !important as
 * the existing live rules (design-exports/PCG_GlobalCSS_bereinigt.css) so this file's
 * later print order settles the tie cleanly. */
.pcg-card .brxe-heading {
	margin: 8px 0 0 !important;
}

.pcg-card > .brxe-text-basic:not(.pcg-card-link),
.pcg-card > .brxe-text {
	margin: 8px 0 0 !important;
}

/* ============================================================
   SUPERSEDED (2026-08-10, l9b Task 2) — see the new "C2c-01" section further below
   ============================================================
   The phone-only `a.brxe-block[href^="/leistungen/"]{ flex-basis: 100% !important; }` rule
   that used to live here (260810-1ld) forced the Gewerke tiles to one-per-row on phone by
   overriding each tile's own flex-basis, while the CONTAINER stayed a wrapping flex row at
   every width (2-per-row on desktop/tablet, the original client complaint this round now
   fixes). Quick task 260810-l9b's C2c-01 section converts that container itself into a real
   4/2/1 grid (`.pcg-wrap:has(> a.brxe-block[href^="/leistungen/"])`) - once the container is
   a grid, flex-basis on its children is inert, so this child-level rule would only add dead
   weight alongside the new container rule, not fight it usefully. Deleted rather than
   layered on top of; the container's grid is now the single source of column count. */

/* ============================================================
   LIVE BUGFIX (2026-08-10, second round) — Project-detail "Weitere Referenzen" thumbnail grid
   ============================================================
   Reported live by the client on a real phone. This 10-image thumbnail grid is a shared
   Bricks template element (same #brxe-wepjob ID confirmed on multiple project pages, e.g.
   nkz-berlin-kreuzberg and gropius-passagen-berlin - a genuine reusable template, not
   per-page duplicated markup, so targeting its ID here is safe and will not need repeating
   per project). It ships from Bricks as `repeat(6, minmax(0px, 5fr))` with no responsive
   override at all - fine on desktop, but 6 columns in a ~320-500px phone width squeezes
   each thumbnail to roughly 50-80px, illegible and disproportionate to the rest of the page
   (client's own words: "3 oder 4 Bilder in einer Reihe"). No `.pcg-*` class exists on this
   element to hook instead (same situation as the homepage's "Vier Gewerke" teaser above).
   `minmax(0, 1fr)` throughout, not a bare `1fr` or `Nfr` - see the `.pcg-2col` fix above in
   this same file for why a bare fr track can blow out on grid children with large intrinsic
   content (this grid's images are exactly that kind of content). */
@media (max-width: 640px) {
	#brxe-wepjob {
		grid-template-columns: repeat(3, minmax(0, 1fr)) !important;
	}
}

@media (min-width: 641px) and (max-width: 999px) {
	#brxe-wepjob {
		grid-template-columns: repeat(4, minmax(0, 1fr)) !important;
	}
}

/* ============================================================
   SUPERSEDED (2026-08-10, l9b Task 1) — see the new "C2c-05" section further below
   ============================================================
   The 820px #brxe-vputtu width workaround (`width: calc(100% - 24px) !important;`) that
   used to live here (round 2 live bugfix) subtracted the hero container's own mandatory
   `margin-left:max(24px, …) !important` centering formula from its width, to stop a 24px
   right-edge overflow. Quick task 260810-l9b's C2c-05 section (below) replaces that whole
   centering formula with the same `.pcg-wrap` geometry the header now shares, which removes
   the mandatory margin-left entirely - so this width-minus-24px subtraction is now double
   counting an offset that no longer exists. Deleted rather than layered on top of. */

/* ============================================================
   LIVE BUGFIX (2026-08-10, third round) — Homepage "Warum PCG" section
   ============================================================
   Client-confirmed (with a screenshot) this is the "Vom Bauingenieur geführt / Termintreue
   Umsetzung / Sto-Klimapartner / Namhafte Auftraggeber" value-props block - the section's
   eyebrow literally reads "Warum PCG". Desktop layout is a 2-column row: #brxe-oqjbke holds
   a plain photo with no caption/heading of its own, #brxe-nvrwdc holds the eyebrow, heading
   and the four icon+text items. No .pcg-* class exists on either (same situation as the
   "Vier Gewerke" teaser and the "Weitere Referenzen" gallery above), so both are targeted by
   their confirmed, page-specific IDs - documented exceptions, same as those.
   Client's explicit direction: on mobile the photo has no heading/context tying it to
   anything and should not render at all; the value-props text/icons read better centered
   than left-aligned once stacked under nothing.

   quick task 260819-0fc, Task 1 (2026-08-19): client-reported bug - once the photo is
   hidden above, #brxe-nvrwdc becomes the section's only visible column, but this block
   never gave it any horizontal padding of its own - so its eyebrow, heading and all four
   icon+text rows ran flush to the true screen edge on a phone (re-confirmed by reading
   this block's own source: only display/align-items/text-align/margin were ever set here,
   no padding-left/-right at all). Fixed with the same house mobile inner-padding
   convention this file already uses for other elements outside `.pcg-wrap` (see the
   20px step at max-width:820px further below, e.g. the #brxe-jdafeg/#brxe-ktbmez/
   #brxe-dvdrnf/#brxe-knqazm/#brxe-bvrrgu block) - not a new one-off value. Since this
   whole block is already scoped to max-width:820px, only the 20px step is needed here;
   no separate max-width:1023px query is added, because live measurement to confirm
   whether the 821-1023px tablet range is also affected was not available in this
   session (no Chrome browser automation tool) - flagged in the SUMMARY as needing a
   human/Chrome check before this is considered fully verified. */
@media (max-width: 820px) {
	#brxe-oqjbke {
		display: none !important;
	}
	#brxe-nvrwdc {
		align-items: center !important;
		text-align: center !important;
	}
	#brxe-nvrwdc > :nth-child(n + 3) {
		flex-direction: column !important;
		align-items: center !important;
		text-align: center !important;
	}
	/* The heading/paragraph pair sits in its own nested wrapper with an explicit
	 * width:500px (full-container) and align-self:flex-start (a Bricks per-element
	 * setting), which overrides the align-items:center above for THIS child - text-align
	 * alone does not center a block-level heading whose own box is narrower than that
	 * 500px wrapper (text-align only centers inline content/text, not a block child's
	 * position). margin:auto centers the block box itself within the full-width wrapper. */
}

/* ============================================================
   SUPERSEDED (2026-08-10, l9b Task 2) — see the new "C2c-03" section further below
   ============================================================
   The unconditional `#brxe-ilmufm > :nth-child(n + 4){ display:none !important; }` rule
   that used to live here forced exactly 3 cards in one row on the homepage at EVERY width,
   which directly contradicts C2c-03 (desktop 4 cards in one row, phone exactly 2). Quick
   task 260810-l9b's C2c-03 section replaces this with a real 4-desktop/2-phone rule pair,
   scoped by `.pcg-card` rather than a bare positional child selector so it can never hide a
   non-card child (e.g. the query trail, hidden separately below). Deleted rather than
   layered under the new rule. */

/* ============================================================
   QUICK TASK 260810-l9b — Teil C2c ("Finale Politur", client-approved binding decisions)
   ============================================================
   Everything from here down implements the eleven C2c-* bullets (C2c-09 explicitly
   excluded, see its own comment in Task 4 below) from
   design-exports/AUFTRAG_Claude_Code_Finale_Politur.md. Same file, same enqueue/print-order
   contract as every section above - no new stylesheet, nothing pasted into Bricks. */

/* ============================================================
   l9b TASK 1, PART A — C2c-04: header right-aligned (desktop only, >=1024px)
   ============================================================
   Below 1024px the 260810-1ld mobile header rules above are untouched and stay in charge
   (discovered fact 6) - every rule in this part is scoped inside min-width:1024px so it
   cannot interact with them. The Bricks Custom CSS mirror ships `.pcg-header{display:grid
   !important; grid-template-columns:1fr auto 1fr !important}` plus `justify-self`
   start/center/end on the three children (discovered fact 4) - that centred nav-menu
   placement on child 2 is exactly what this replaces. Both sides are unlayered
   `!important`, so this is a genuine equal-specificity/equal-importance tie settled only by
   this file's later print order (discovered fact 1). */
@media (min-width: 1024px) {
	.pcg-header {
		display: flex !important;
		flex-wrap: nowrap !important;
		align-items: center !important;
		gap: 24px !important;
		/* Same horizontal geometry as .pcg-wrap (discovered fact 10) - this is what makes the
		 * logo's left edge equal the page content's left edge, and it also neutralises the
		 * invalid `width:var(--content-width)` (discovered fact 5, resolves to the unitless,
		 * therefore-dropped value "1000") without touching that broken Bricks global variable. */
		width: 100% !important;
		max-width: 1200px !important;
		margin-left: auto !important;
		margin-right: auto !important;
		padding-left: 24px !important;
		padding-right: 24px !important;
		box-sizing: border-box !important;
	}
	/* Logo: `justify-self` no longer applies once the parent is flex, not grid - pin it left
	 * with margin-right:auto (consumes all free space, pushing children 2+3 to the right as
	 * one group) and flex-shrink:0 so it can never be squeezed. */
	.pcg-header > *:nth-child(1) {
		margin-right: auto !important;
		flex-shrink: 0 !important;
		justify-self: auto !important;
	}
	/* Nav container: cancel the stale Bricks desktop box (width:550px, flex-shrink:1,
	 * justify-content:space-evenly - discovered fact 4) that would otherwise re-centre the
	 * menu inside its own well instead of letting it sit flush against the CTA button. */
	.pcg-header > *:nth-child(2) {
		width: auto !important;
		flex: 0 0 auto !important;
		margin-left: 0 !important;
		margin-right: 0 !important;
		justify-content: flex-end !important;
		justify-self: auto !important;
	}
	/* CTA button: sits directly after the menu inside the right-hand group, separated only
	 * by the row `gap` above - no margin of its own needed beyond flex-shrink:0. */
	.pcg-header > *:nth-child(3) {
		margin-left: 0 !important;
		flex-shrink: 0 !important;
		justify-self: auto !important;
	}
}

/* ============================================================
   l9b TASK 1, PART B — C2c-05: hero left-aligned on the content edge, all widths
   ============================================================
   The hero's own children (eyebrow #brxe-idccdx, lead #brxe-dtvrtn) already carry
   `align-self:flex-start` / `text-align:left`, and the button row #brxe-idmbte already
   carries `align-self:flex-start !important; justify-content:flex-start` (discovered fact
   8) - no per-child alignment rule is added here, deliberately: a future reader should not
   "helpfully" add one, the children were already left-aligned, only their CONTAINER wasn't.
   #brxe-vputtu is already allowlisted (used by earlier rounds), so no new allowlist entry is
   needed for this part. */
/* ============================================================
   AUFTRAG 260824-w5e (Runde 5) — DIE PLATZIERUNGS-SPERREN DES
   STARTSEITEN-HEROS SIND HIER ENTFERNT WORDEN
   ============================================================
   Kunden-Auftrag vom 2026-08-24, woertlich: „nimm die Regeln raus, welche das
   Verschieben des Heros verhindern. Der Hero ist deplaziert und laesst sich von
   mir manuell nicht steuern durch die Aenderungen, welche du in der
   Vergangenheit gemacht hast."

   Das deckt sich mit der Hausregel in `.claude/CLAUDE.md`: native
   Bricks-Panel-Felder haben Vorrang vor versteckten `!important`-Regeln in
   dieser Datei, weil Datei-Regeln im Bricks-Canvas unsichtbar sind und das
   WYSIWYG-Vertrauen zerstoeren. Genau dieser Fall ist eingetreten.

   WAS ENTFERNT WURDE (alles ID-gebunden, alles `!important`, alle vier Bloecke
   am Live-DOM als wirksame Sperre nachgewiesen):

     #brxe-vputtu   width, max-width, margin-left/right, padding-left/right,
                    box-sizing            (Block aus l9b Task 1, Teil A)
     #brxe-vputtu   padding-left/right    @max-width:820px
     #brxe-pbqjeq   min-height: calc(100vh + 90px) / calc(100svh + 90px)
                    (Block aus 260809-pj7)
     #brxe-pbqjeq   justify-content: center   @max-width:640px
     #brxe-vputtu   margin-bottom: var(--pcg-hero-mobile-bottom-gap, 32px)
                    @max-width:640px

   WARUM DAS DIE STEUERUNG ZURUECKGIBT UND NICHT NUR ETWAS LOESCHT: Bricks
   schreibt fuer dieselben Eigenschaften bereits eigene ID-Regeln, ebenfalls mit
   `!important` — am Live-DOM nachgemessen: auf die Container-ID ein
   margin-left von max(24px, 50% - 400px) und ein margin-right von auto, auf die
   Sektions-ID ein align-self von stretch, alle drei mit `!important`.

   ACHTUNG BEIM UMFORMULIEREN: mehrere Tests dieser Suite lesen
   pcg-responsive.css MIT Kommentaren und suchen darin nach Regeln der Form
   ID gefolgt von einer geschweiften Klammer. Ein Kommentar, der eine Regel
   woertlich in dieser Form zitiert, laesst solche Tests fehlschlagen, obwohl am
   Code nichts falsch ist — genau das ist hier beim ersten Schreiben passiert
   und weiter oben im 260824-w5e-Block schon zweimal. Deshalb steht die
   Panel-Regel oben als Fliesstext und nicht als Code-Zitat.

   Meine Regeln standen bei
   derselben Spezifitaet und gewannen nur ueber die spaetere Druckreihenfolge
   dieser Datei. Fallen sie weg, greift wieder der Panel-Wert — den der Kunde im
   Bricks-Editor sieht und aendern kann.

   WAS DAS KOSTEN KANN (ehrlich benannt, damit es niemanden ueberrascht):
     - Die volle Bildschirmhoehe kommt jetzt aus dem Panel-Feld `min-height`.
       Steht dort noch der alte Wert `90vh`, kann die Folgesektion unten wieder
       durchlugen (die Beschwerde, die 260809-pj7 behoben hatte). Fix: im Panel
       `100svh` eintragen — sichtbar und selbst aenderbar, statt hier versteckt.
     - Seitenabstand und Maximalbreite des Inhalts folgen wieder der
       Panel-Formel (zentrierte 800px-Spalte statt linksbuendiger 1200px-Spur).
     - Auf dem Handy entfallen die Mittig-Ausrichtung und der 32px-Bodenabstand.
   Alle drei sind im Panel einstellbar. Kein Wert ist verloren — die Zahlen
   stehen oben in diesem Kommentar und in den Tests.

   NICHT ENTFERNT, weil es keine Platzierung ist: die Hero-Typografie
   (`#brxe-vputtu > h1/h2/h3`, 74px/46px/32px) und der Ueberlauf-Schutz
   `#brxe-vputtu > .brxe-text{max-width:100%}`. Wuerde die Typografie mitgehen,
   faellt die Ueberschrift auf Standardgroesse.
   NICHT ENTFERNT, weil ein eigener Effekt: `position: sticky` aus
   pcg-motion.css. Wenn „deplaziert" den Sticky-Effekt meint, ist das ein
   getrennter Schalter.
   ============================================================ */


/* Clamp the lead's hard 560px width (discovered fact 8) so it can never overflow a narrow
 * phone - expressed as a child selector of the already-allowlisted hero ID, so no new ID
 * enters the test allowlist for this rule. */
#brxe-vputtu > .brxe-text {
	max-width: 100% !important;
}

/* ============================================================
   l9b TASK 1, PART C — C2c-05b: hero size (added by the client 2026-08-10, supersedes the
   "hero size is a separate design conversation" deferral note in the 260810-1ld SUMMARY -
   that deferral no longer applies)
   ============================================================ */

/* Full-viewport coverage. The hero section (#brxe-pbqjeq) carries `margin-top:-90px`
 * (discovered fact 10a, load-bearing - pulls the section up under the homepage's fixed
 * transparent header so the photo flows behind it, quick task 260809-pj7) and
 * `min-height:90vh` with no adjustment for that negative pull (discovered fact 10b). The
 * section's top edge sits at y=-90px, so for its BOTTOM edge to reach the fold the height
 * must be one viewport PLUS 90px, not one viewport - `calc(100vh + 90px)`, a derived number
 * from the existing -90px offset, not a guess. `#brxe-pbqjeq` has no `.pcg-*` class of its
 * own beyond the shared `.pcg-section` (which cannot be used here - it would hit every
 * section on the site), so it is a new, documented ID-allowlist entry.
 * `svh` (small viewport height) is layered on top as a progressive enhancement rather than
 * relied on alone: it is the unit that guarantees no peek of the next section whether a
 * phone's URL bar is expanded or collapsed, because it always assumes the SMALLEST possible
 * viewport. `dvh` was deliberately not used - it resizes the section mid-scroll as the
 * browser chrome shows/hides, which is visually the opposite of "solid full-screen photo".
 * Bare `vh` on iOS Safari resolves to the LARGE viewport, i.e. exactly the case where the
 * next section peeks - the client's original complaint. Support: Safari 15.4+/Chrome 108+,
 * the same support bar this file already relies on for `:has()` (Task 2 below). */
/* (Der `min-height`-Block auf #brxe-pbqjeq ist entfernt — siehe den Banner
   "Runde 5" weiter oben. Die Hoehe kommt jetzt aus dem Bricks-Panel.) */

/* Quick task 260819 (mobile hero overlay - SUPERSEDED, kept as history): a flat
 * mobile-only overlay colour briefly replaced the gradient here (background-image:
 * none + background-color:rgba(20,36,64,0.55) on #brxe-pbqjeq::before), because the
 * client reported the gradient reading "confused/reversed" on a real phone. The real
 * cause, found afterward via direct pixel-sampling (not eyeballing a screenshot,
 * which had misled this session once already): the desktop gradient's stop ORDER was
 * genuinely backwards - dark on the RIGHT (empty side) and light on the LEFT (text
 * side), the opposite of the intent, on every breakpoint including mobile. Once that
 * root cause was fixed directly in the Bricks "Farbverlauf/Overlay" panel (Farbe(1)
 * and Farbe(3)'s alpha values swapped: 0% stop 0.12->1, 100% stop 1->0.12, same
 * hsla(218,52%,16%,*) token, same 100deg angle, Farbe(2) unchanged at 0.68/50%),
 * confirmed correct via pixel-sampling all four corners, the client's actual ask
 * ("orientiert an IRO's Umsetzung", i.e. a clean gradient, not literally a flat
 * colour) was satisfied by the corrected gradient itself - this mobile-only
 * flat-colour override is removed, and mobile now inherits the same corrected
 * Bricks-native gradient as desktop. Left as a comment (not deleted silently) so a
 * future reader who finds `rgba(20,36,64,0.55)` in git history understands why it
 * existed and why it went away in the same session. */

/* Quick task 260819 (mobile hero overlay - flat colour REINSTATED, this time with a
 * concrete technical reason, not just "the gradient looked confused"). Client
 * reported the reinstated gradient's dark region visibly "bled into"/blurred the
 * navy "Unsere Leistungen" button on mobile. Root cause, worked out from the
 * layout facts rather than guessed: on mobile both hero buttons are `width:100%`
 * (site-wide C2c-10 full-width-button rule) - they span the ENTIRE horizontal
 * extent the gradient varies across. A horizontal gradient (the desktop-corrected
 * 100deg one, dark-left/light-right) therefore paints a full-width element with a
 * VISIBLY UNEVEN wash - darker on its own left edge, lighter on its own right edge
 * - which reads as smeared/inconsistent on any element that spans the whole
 * gradient range, independent of the gradient's intensity or direction being
 * "correct". A flat colour cannot have this problem: it is uniform everywhere, so
 * a full-width button sits against one consistent shade along its entire length.
 * 0.45 alpha (lighter than the earlier 0.55 attempt) keeps enough contrast for the
 * white heading/lead text while staying light enough that the navy button's own
 * edges/shadow remain visually distinct against it - the client's own standing
 * principle: the overlay should improve text legibility, not obscure text or
 * buttons. Desktop's gradient (Bricks panel, unaffected by this mobile-only rule)
 * is untouched - desktop buttons are NOT full-width, so the unevenness problem
 * does not apply there.
 *
 * REMOVED (quick-260819-65w, same day): client asked for this override to be
 * taken back out - the `!important` rule was silently winning over the Bricks
 * "Farbverlauf/Overlay" panel on mobile, so any change the client made there
 * in the editor had no visible effect below 640px. Reverting to the project's
 * standing convention (Bricks-native panel controls the overlay the client
 * can see and adjust) at the client's explicit request; the full-width-button
 * unevenness this rule solved may return if the client sets a strong mobile
 * gradient again - flagged to them, not silently reintroduced as a surprise. */

/* Quick task 260819 (mobile hero vertical rhythm, "1:1" per iro-berlin.de): client
 * compared the two mobile heroes and found IRO's reads as having more breathing room
 * above the heading and a tighter, more consistent gap below the buttons - ours felt
 * reversed. Root cause, found by reading IRO's own raw (uncompiled) CSS via CSSOM
 * rather than guessing pixel values: IRO's `.hero` is `display:flex; flex-direction:
 * column; align-items:flex-end` with NO top offset at all - the single content block
 * is anchored to the BOTTOM of the full-height hero by `justify-content`, with only a
 * fluid `padding-bottom:clamp(4rem,7vw,7rem)` controlling the gap beneath it; the
 * space above is simply whatever is left over, so it grows automatically as the
 * viewport shrinks.
 *
 * PCG's own #brxe-pbqjeq currently has no explicit `justify-content` (Bricks default,
 * effectively flex-start), so any leftover vertical space - the difference between the
 * section's min-height and the content's actual height - collects at the BOTTOM,
 * below the content. That is the reversed proportion the client is seeing.
 *
 * FIRST ATTEMPT (superseded): `justify-content:flex-end`, a direct copy of IRO's own
 * bottom-anchor mechanism. A real, full, uncropped phone screenshot from the client
 * (not this session's own unreliable viewport-emulation attempts - `resize_window`
 * never actually reflows in this tool, confirmed three separate times) proved this
 * overshot badly: ~260px of leftover space collected entirely above the eyebrow while
 * only ~90px remained below the trust line - a single large top gap, not IRO's more
 * modest, evenly-weighted one. Full `flex-end` gives 100% of leftover space to the
 * top; PCG's content is short enough relative to the section's `min-height` that this
 * reads as one oversized gap rather than "breathing room".
 *
 * CURRENT FIX: `justify-content:center` splits the leftover space evenly instead of
 * dumping all of it above the content - roughly halves the top gap the client
 * measured (260px -> ~175px) while giving the bottom a bit more room too (90px ->
 * ~175px), closer to IRO's own proportion without copying `flex-end` past the point
 * where it stops looking intentional. #brxe-vputtu's own `margin-top:170px` (further
 * below in this file) is still DELIBERATELY left untouched - it is not "top spacing"
 * in the IRO sense, it is the fixed clearance keeping the heading out from under the
 * site's sticky header (see that block's own header-collision arithmetic and its
 * guard test); `center` treats it exactly as it treats any other in-flow content,
 * neither removing nor relying on it. */
@media (max-width: 640px) {
	/* (justify-content und margin-bottom sind hier entfernt — siehe den Banner
	   "Runde 5" weiter oben. Beides ist Panel-Sache.) */
	/* Client-tunable knob, same `var(--x, FALLBACK) !important` / no-`:root`
	 * contract as every other --pcg-hero-* variable in this file (see the
	 * 260811-ldk contract comment further below and KLICKANLEITUNG.md for
	 * the full client-facing table) - client feedback after seeing this
	 * live: full flex-end sits the content flush against the section's
	 * existing 48px .pcg-section bottom padding, "ein Tick zu niedrig".
	 * --pcg-hero-mobile-bottom-gap lifts the bottom-anchored content up by
	 * this many px, giving a combined ~80px bottom clearance by default
	 * (48px + 32px) - close to IRO's own clamp(4rem,7vw,7rem) floor of 64px
	 * - and is adjustable by the client at any time by pasting e.g.
	 * `--pcg-hero-mobile-bottom-gap: 16px;` into the Bricks Custom CSS
	 * field, no SFTP upload required. */
}

/* Compactness. Reclaims the internal slack identified live (discovered fact 10d) - NOT the
 * top offset, see the comment on #brxe-vputtu's margin-top further below for why.
 * Targeted as descendants of the already-allowlisted #brxe-vputtu (heading = its only <h3>
 * child; lead = its already-established `.brxe-text` child selector from Part B above)
 * rather than the heading/lead's own generated IDs (#brxe-rviyig / #brxe-dtvrtn), so this
 * task adds exactly one new ID to the allowlist - the hero section's, below.
 *
 * SUPERSEDED (desktop only, min-width:1024px) - see quick task 260811-5ob Task 3, sub-block
 * C, further below in this file. That block grows these same two rules' desktop values
 * (20px/20px and 44px) so the hero content fills more of the section's vertical space; it
 * wins the desktop tie by later print order, same selector, same !important weight. This
 * base rule is NOT deleted and stays the live source of truth for tablet widths
 * (641-1023px) and, via its own @media (max-width:640px) step directly below, for phone. */

/* ============================================================
   Quick task 260811-ldk, Task 3 — the --pcg-hero-* variable contract
   (HERO-01, EDIT-02a, EDIT-02b, EDIT-02c)

   Every hero declaration below takes the form
   `property: var(--pcg-hero-NAME, FALLBACK) !important;` and NO `:root`
   block anywhere in this child theme may ever define any `--pcg-hero-*`
   property. This is load-bearing, not stylistic: every child-theme
   stylesheet in this project is enqueued with a dependency on the Bricks
   `bricks-frontend-inline` handle so it prints AFTER the Bricks Custom CSS
   field - a child-theme `:root` default would therefore print AFTER the
   client's own Custom CSS override and silently beat it by print order,
   re-creating the exact "ich kann nichts ändern" lock-out this task exists
   to remove. The fallback inside `var()` IS the default: an undefined
   variable falls back to it, a variable the client defines in the Bricks
   Custom CSS field wins from wherever they typed it - no child-theme file
   edit, no SFTP upload, no developer required (EDIT-02a). If you are
   reading this because you want to "helpfully" add a `:root { --pcg-hero-*:
   ...; }` default somewhere in this theme: do not - it silently disables
   every client override below.

   Variables introduced (see KLICKANLEITUNG.md for the client-facing
   German table of every knob and its default):
   --pcg-hero-size (desktop), --pcg-hero-size-tablet, --pcg-hero-size-phone,
   --pcg-hero-weight, --pcg-hero-leading, --pcg-hero-tracking,
   --pcg-hero-gap (heading bottom rhythm), --pcg-hero-lead-gap (lead
   paragraph bottom rhythm).

   Stable class (EDIT-02b): every hero-heading selector below is changed
   from `#brxe-vputtu > h3` to `.pcg-hero-title, #brxe-vputtu > h3` - class
   first, ID fallback second. The class is the durable target; the
   generated ID is a temporary fallback that stays live until the client
   has typed `pcg-hero-title` into the Bricks element's CSS Classes field
   (KLICKANLEITUNG.md, Task 6's checkpoint) - once set, the ID selector can
   be dropped in a later round. Adding the class introduces no new
   `#brxe-*` ID, so the 22-entry ALLOWLISTED_IDS list below is unchanged. */
/* Quick Task 260824-w5e (Auftrag Hero-System, Punkt 3): der Auftrag will die
   Startseiten-Headline von `h3` auf `h1` umstellen (SEO). Dieser Vertrag hing
   bisher an `#brxe-vputtu > h3` — die Umstellung im Bricks-Editor haette die
   komplette Hero-Typografie (Groesse, Gewicht, Rhythmus) an ALLEN drei
   Breakpoints stillschweigend fallen lassen, ohne Fehlermeldung. Der Selektor
   deckt jetzt h1/h2/h3 ab, damit der Tag-Wechsel folgenlos bleibt. Ein `:is()`
   waere kuerzer, aber dieser Datei-Bestand ist durchgehend explizit und
   greppbar - das bleibt so. */
#brxe-vputtu > .brxe-text {
	/* Quick task 260819-65w, Task 1 (client follow-up): the lead paragraph now matches the
	 * H1 above it in CASE (both uppercase) while staying clearly LIGHTER in weight (the
	 * client's actual complaint was the reverse - lead reading bolder than the heading).
	 * Ungated deliberately (no media query), same as this rule's own pre-existing
	 * padding-bottom above - applies at every breakpoint, not just desktop. Root cause: all
	 * three hero text elements carry a raw Bricks per-element font-weight:900 that the
	 * 260810-ja8 weight-cleanup pass never reached (none of the three carry a `.pcg-*`
	 * class - see the "Phone heading size" comment further below). A later round
	 * (260811-ldk) gave the H1 an explicit --pcg-hero-weight override, but only inside the
	 * desktop min-width:1024px block - this task extends that SAME token into the two
	 * smaller breakpoints below (never a second H1-specific weight token) and gives the
	 * lead its own new, independent, lighter --pcg-hero-lead-weight knob (default 500 -
	 * Inter Medium, clearly lighter than the heading's 800/900 while staying legible at the
	 * lead's 19px/16px sizes), following the same var(--x, FALLBACK) !important / no-:root
	 * contract as every other --pcg-hero-* variable in this file. */
	text-transform: uppercase !important;
	font-weight: var(--pcg-hero-lead-weight, 500) !important;
}
@media (max-width: 640px) {
	/* One variable with three per-breakpoint defaults is intentional (3f): setting
	 * --pcg-hero-gap once makes the heading rhythm uniform at every width, which is the
	 * simple knob the client asked for. */
	/* SUPERSEDED - see quick task 260811-5ob Task 3, sub-block D, further below in this file.
	 * That block raises this same padding-bottom to 36px (client asked for more breathing
	 * room between the paragraph and the button row on phone); same selector, same
	 * !important weight, same max-width:640px query - wins the tie by later print order.
	 * Not deleted here so the file's own history of this value stays intact. */
}

/* #brxe-vputtu's own top offset (margin-top:170px) is DELIBERATELY left unchanged in this
 * task. Arithmetic (discovered fact 10c): the hero section sits at y=-90px
 * (margin-top:-90px above), so the text container's content top in viewport coordinates is
 * -90px + 170px = 80px. The live :root defines --header-height:72px (a valid length, unlike
 * --content-width), and the Bricks Custom CSS mirror's own comment records the header as
 * roughly 79px tall with ~88px of hero clearance today - so the current 170px leaves at
 * most a few pixels of margin before the heading would sit under the fixed header. Reducing
 * it here would risk exactly the class of live collision bug the client already caught
 * twice in 260810-1ld. This number is put to the client directly in Task 7 with this same
 * arithmetic, rather than guessed here; if the client's answer needs to go below this safe
 * minimum, the header's own height has to change first - a separate, later change. */

/* Phone heading size. The heading (h3, the only one inside #brxe-vputtu - see above) renders
 * a fixed 52px at every width because it carries no `.pcg-*` class, so the 260810-ja8
 * responsive type scale never reaches it (discovered fact 10e). Brought onto that
 * already-approved scale at the two smaller breakpoints only, matching `.pcg-hero-h1`'s own
 * tablet/phone values exactly (design-exports/PCG_GlobalCSS_bereinigt.css) - desktop 52px is
 * deliberately untouched, the client asked about phone readability, not desktop. The eyebrow
 * (#brxe-idccdx, 14px) and lead (`.brxe-text`, 19px) are already within a reasonable phone
 * range and are deliberately left alone. All three hero elements also carry
 * `font-weight:900` (a leftover the 260810-ja8 weight-800-removal pass could not reach,
 * since it never carries a `.pcg-*` class either) - reported as a finding in the SUMMARY,
 * not changed here. */
@media (max-width: 1023px) {
	.pcg-hero-title,
	#brxe-vputtu > h1,
	#brxe-vputtu > h2,
	#brxe-vputtu > h3 {
		font-size: var(--pcg-hero-size-tablet, 46px) !important;
		/* Quick task 260819-65w, Task 1: same --pcg-hero-weight token the desktop
		 * min-width:1024px block already uses further below (800 fallback) - extended here
		 * so the H1 renders visibly bolder than the lead paragraph (--pcg-hero-lead-weight,
		 * 500 fallback, set above) at every breakpoint, not just desktop. */
		font-weight: var(--pcg-hero-weight, 800) !important;
	}
}
@media (max-width: 639px) {
	.pcg-hero-title,
	#brxe-vputtu > h1,
	#brxe-vputtu > h2,
	#brxe-vputtu > h3 {
		font-size: var(--pcg-hero-size-phone, 32px) !important;
		font-weight: var(--pcg-hero-weight, 800) !important;
	}
}

/* ============================================================
   l9b TASK 2 — C2c-01 (Gewerke 4/2/1), C2c-02 (slim reference cards), C2c-03 (teaser 4/2)
   ============================================================ */

/* C2c-01 - four Gewerke tiles: desktop 4-in-a-row, tablet 2, phone 1. The container is
 * addressed WITHOUT an ID, via `.pcg-wrap:has(> a.brxe-block[href^="/leistungen/"])` - the
 * tiles are the only direct `a.brxe-block` children anywhere on the site whose href starts
 * with `/leistungen/` (discovered fact 11), so this is precise, and it is robust against a
 * future rebuild in the Bricks editor changing the container's generated ID. `:has()` is
 * relied on deliberately here (as it is for the button-row selector in Task 5 below) and is
 * universally available in the browsers this project targets (Safari 15.4+/Chrome 105+).
 * C2c-01's "whole card clickable, no separate button, no nested link" is ALREADY
 * structurally satisfied - each tile is one stretched `a.brxe-block` with an image, an
 * h3.pcg-subhead and a div.pcg-body, no button, no nested `<a>` - verified live for this
 * task, not assumed; only the column count needed fixing. */
.pcg-wrap:has(> a.brxe-block[href^="/leistungen/"]) {
	display: grid !important;
	grid-template-columns: repeat(4, minmax(0, 1fr)) !important;
	gap: 28px !important;
	align-items: stretch;
}
@media (max-width: 1023px) {
	.pcg-wrap:has(> a.brxe-block[href^="/leistungen/"]) {
		grid-template-columns: repeat(2, minmax(0, 1fr)) !important;
	}
}
@media (max-width: 640px) {
	.pcg-wrap:has(> a.brxe-block[href^="/leistungen/"]) {
		/* minmax(0, 1fr), not a bare 1fr - same Safari Grid "blowout" reasoning as the
		 * .pcg-2col fix above (a bare fr track's automatic minimum defaults to its child's
		 * intrinsic size, not 0). */
		grid-template-columns: minmax(0, 1fr) !important;
	}
}
/* Neutralise the now-inert flex sizing so nothing from the old flex-wrap model leaks once
 * the container becomes a grid (flex-basis/width no longer apply to a grid child). */
.pcg-wrap:has(> a.brxe-block[href^="/leistungen/"]) > a.brxe-block {
	flex-basis: auto !important;
	width: auto !important;
	min-width: 0;
}

/* C2c-02 - reference cards slimmed to trades/title/period/volume. In BOTH query-loop
 * templates (Referenzen grid AND the homepage teaser - discovered fact 13) the bullet-point
 * description is the card's ONLY `.brxe-text` child; every other text row uses
 * `.brxe-text-basic` instead. This one class-based rule is therefore exact, template-
 * independent and ID-free, and covers any future card built from either template. The
 * cleaner permanent step - deleting this text element from the two loop templates in the
 * Bricks editor - is optional, described in the SUMMARY; this rule stays harmless once that
 * is done (nothing left to hide). */
.pcg-card > .brxe-text {
	display: none !important;
}

/* C2c-03 - homepage teaser: desktop 4 cards in one row, phone exactly 2. /referenzen/
 * itself is untouched (still 4/desktop via the existing global-field rule, still whatever
 * .pcg-cardgrid:not(.pcg-cardgrid--2) already resolves to on phone/tablet from Task 5
 * above) because every rule below is scoped to the teaser's own already-allowlisted
 * #brxe-ilmufm ID, never to the shared .pcg-cardgrid/.pcg-cardgrid--2 classes themselves. */

/* Hide the query-trail element (discovered fact 14) generically, wherever a query loop puts
 * one - in a 4-column grid it would otherwise occupy an empty fifth cell. */
.pcg-cardgrid > .brx-query-trail {
	display: none;
}

@media (min-width: 1000px) {
	/* 1000px matches the existing desktop card breakpoint already live in the global CSS
	 * (design-exports/PCG_GlobalCSS_bereinigt.css, `.pcg-cardgrid:not(.pcg-cardgrid--2)`) -
	 * not a new breakpoint. Scoped to the teaser's own ID so the shared `.pcg-cardgrid--2`
	 * class keeps meaning "exactly two columns" everywhere else it might ever be reused
	 * (discovered fact 16). */
	#brxe-ilmufm {
		grid-template-columns: repeat(4, minmax(0, 1fr)) !important;
	}
	/* Same 4/3 media frame as the Referenzen page now that the teaser cards are the same
	 * width, overriding `.pcg-cardgrid--2`'s 220px fixed height for this element only. */
	#brxe-ilmufm .pcg-card-media {
		aspect-ratio: 4 / 3 !important;
		height: auto !important;
	}
}

@media (max-width: 640px) {
	/* Exactly two cards on phone. Scoped to `.pcg-card` (not a bare positional child
	 * selector) so this can never hide a non-card child such as the query-trail element
	 * above. */
	#brxe-ilmufm > .pcg-card:nth-child(n + 3) {
		display: none !important;
	}
}

/* ============================================================
   l9b TASK 3 — C2c-06 (counter redesign), C2c-11 (shared selectors site-wide)
   ============================================================
   Everything below is driven only by the shared `.pcg-stats` classes and positional
   `:nth-child()` selectors, so it applies unchanged to all three live counter rows -
   homepage `#brxe-wgbarq`, `/referenzen/` `#brxe-scneak`, `/ueber-uns/` `#brxe-xvazur` - with
   no per-page rule (discovered fact 17). That shared-selector approach IS C2c-11 for this
   element. The positional icon mapping below is safe because all three rows share the same
   four tiles in the same order; adding, reordering or removing a tile means revisiting the
   four `:nth-child()` icon rules. */

@media (min-width: 1024px) {
	/* Desktop: four counters evenly spread across the full .pcg-wrap content width, edge to
	 * edge like the client's own approved mockup.
	 *
	 * LIVE BUG FOUND 2026-08-10 (client report + orchestrator's own live re-check via
	 * getComputedStyle, real browser, not simulated): the `flex:1 1 0` rule below correctly
	 * distributes space WITHIN `.pcg-stats`' own box, but `.pcg-stats`' own box was never as
	 * wide as its `.pcg-wrap` parent to begin with. The parent (e.g. `#brxe-tidkjz`) is itself
	 * `display:flex; flex-direction:column; align-items:flex-start` - on a column flex
	 * container, `align-items:flex-start` sizes each child to its own CONTENT width
	 * (shrink-to-fit) on the cross axis instead of stretching it, so `.pcg-stats` measured
	 * ~803px inside a 1200px wrap (confirmed via `getBoundingClientRect()`), and the "evenly
	 * spread" children were only ever evenly spread across that narrower 803px, not the full
	 * content width - reading as "not wide enough" even though space-between/flex:1 were both
	 * correctly applied. `width:100%` makes `.pcg-stats` fill its parent explicitly regardless
	 * of the parent's own cross-axis sizing behaviour. */
	.pcg-stats {
		justify-content: space-between !important;
		width: 100% !important;
	}
	.pcg-stats > * {
		flex: 1 1 0 !important;
	}
	.pcg-stats > *:first-child {
		padding-left: 0 !important;
	}
	.pcg-stats > *:last-child {
		padding-right: 0 !important;
	}
	/* Neutralise the superseded left-aligned variant (discovered fact 19) - C2c-06 explicitly
	 * replaces `.pcg-stats--left`. The class is applied to no element on any of the five
	 * audited pages today; this rule exists purely as a durable guard so re-applying it in
	 * the Bricks editor can no longer resurrect the old left-aligned look. */
	.pcg-stats--left {
		justify-content: space-between !important;
		width: 100% !important;
	}
	.pcg-stats--left > * {
		flex: 1 1 0 !important;
	}
	.pcg-stats--left > *:first-child {
		padding-left: 0 !important;
	}
}

@media (max-width: 640px) {
	/* Phone: number left, icon + label right, one line - matching the same 640px breakpoint
	 * the existing global-field mobile stats rule already uses (discovered fact 20), so there
	 * is no one-pixel band where the old label-under-number rule wins. The existing border-top
	 * hairline from the global field is intentionally left untouched. */
	.pcg-stats > * {
		display: flex !important;
		flex-direction: row !important;
		align-items: center !important;
		gap: 16px !important;
		padding: 14px 0 !important;
		text-align: left !important;
	}
	/* Number in a fixed-width column so all four labels start on the same vertical line. */
	.pcg-stats .pcg-statnum,
	.pcg-stats .pcg-counter {
		flex: 0 0 auto !important;
		min-width: 88px !important;
		margin: 0 !important;
	}
	/* Label becomes an icon+text row. */
	.pcg-stats .pcg-statlabel {
		margin-top: 0 !important;
		display: flex !important;
		align-items: center;
		gap: 10px;
	}
	.pcg-stats .pcg-statlabel::before {
		content: "";
		flex: 0 0 auto;
		width: 20px;
		height: 20px;
		background-repeat: no-repeat;
		background-position: center;
		background-size: contain;
	}
	/* Four line icons, taken verbatim from the client's own approved mockup
	 * (design-exports/PCG_Startseite_Mockup_Komplett.html, lines 262/266/270/274), re-expressed
	 * as inline SVG data URIs so no new image file or HTTP request is introduced. Single
	 * quotes for every SVG attribute, `#`/`<`/`>` percent-encoded as `%23`/`%3C`/`%3E` for
	 * WebKit safety. Red stroke (`#EE0000`) is the design system's single accent and reads
	 * on both the light homepage row and the navy `--ondark` rows. */
	.pcg-stats > *:nth-child(1) .pcg-statlabel::before {
		/* Clock = years */
		background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' fill='none' stroke='%23EE0000' stroke-width='1.8'%3E%3Ccircle cx='12' cy='12' r='9'/%3E%3Cpath d='M12 7v5l3 2'/%3E%3C/svg%3E");
	}
	.pcg-stats > *:nth-child(2) .pcg-statlabel::before {
		/* Building = projects */
		background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' fill='none' stroke='%23EE0000' stroke-width='1.8'%3E%3Crect x='4' y='4' width='11' height='17' rx='1'/%3E%3Cpath d='M15 9h5v12H4'/%3E%3Cline x1='8' y1='8' x2='11' y2='8'/%3E%3Cline x1='8' y1='12' x2='11' y2='12'/%3E%3C/svg%3E");
	}
	.pcg-stats > *:nth-child(3) .pcg-statlabel::before {
		/* People = customers */
		background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' fill='none' stroke='%23EE0000' stroke-width='1.8'%3E%3Ccircle cx='9' cy='8' r='3'/%3E%3Cpath d='M3.5 20a5.5 5.5 0 0111 0'/%3E%3Cpath d='M16 6.6a2.8 2.8 0 010 5.2'/%3E%3Cpath d='M17.5 20a5.5 5.5 0 00-2-4.2'/%3E%3C/svg%3E");
	}
	.pcg-stats > *:nth-child(4) .pcg-statlabel::before {
		/* Layers = trades */
		background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' fill='none' stroke='%23EE0000' stroke-width='1.8'%3E%3Cpath d='M12 3l9 5-9 5-9-5 9-5z'/%3E%3Cpath d='M3 13l9 5 9-5'/%3E%3C/svg%3E");
	}
	/* Neutralise `.pcg-stats--left > *:first-child{ padding-left:24px }` from the global
	 * field at this breakpoint too, so the variant cannot reintroduce an indent on phone. */
	.pcg-stats--left > *:first-child {
		padding-left: 0 !important;
	}
}

/* Guard for "4 without the plus" (C2c-06 third bullet). On all three live rows today the
 * fourth tile is "Gewerke aus einer Hand" and already renders no `+` (discovered fact 18) -
 * this rule is a durable no-op regression guard, not a repair. If a future counter row
 * legitimately needs a `+` on its fourth tile, this rule must be rescoped rather than
 * worked around. */
.pcg-stats > *:nth-child(4) .pcg-counter .prefix {
	display: none;
}

/* ============================================================
   l9b TASK 4 — C2c-08 (section padding modifiers), C2c-09 (OUT OF SCOPE), C2c-07 (compact
   partner band)
   ============================================================ */

/* C2c-08 - real, reusable modifier classes, the brief's own "root fix" for tightening a
 * section without a per-element override. Defined at a specificity that beats the base
 * `.pcg-section` rule outright (`.pcg-section.pcg-section--tight` / `.pcg-section.pcg-
 * section--none`, both compound with the base class) rather than tying on it - the
 * sanctioned way to set a section tighter from the Bricks editor from now on is simply
 * adding the modifier class to that section, no per-element override needed. */
.pcg-section.pcg-section--tight {
	padding-top: 48px !important;
	padding-bottom: 48px !important;
}
@media (max-width: 640px) {
	.pcg-section.pcg-section--tight {
		padding-top: 32px !important;
		padding-bottom: 32px !important;
	}
}
.pcg-section.pcg-section--none {
	padding-top: 0 !important;
	padding-bottom: 0 !important;
}

/* C2c-09 is OUT OF SCOPE - do NOT implement it. The client decided on 2026-08-10 ("Nein,
 * erstmal so lassen") that the general vertical rhythm stays exactly as it is. This file
 * therefore does NOT restate `.pcg-section`'s base padding at any breakpoint, and does NOT
 * touch `.pcg-ctaband`, `.pcg-ctaband-light`, `.pcg-boxgrid`, `.pcg-steps` or `.pcg-faq`
 * spacing. The two modifier classes above exist deliberately WITHOUT a site-wide rhythm
 * change - they are a tool for the future, not a change made today. The brief's own C2c-09
 * bullet is deferred by this later client instruction, so a future reader should not
 * "complete" it from the brief alone. The only section that gets tighter in this plan is the
 * partner band immediately below, via its own SCOPED use of `--tight`.
 *
 * UPDATE 2026-08-13 (D-06, quick-260813-a5m): the client explicitly reopened the mobile
 * slice of this closed scope ("wenn es UI besser ist dan kannst du es verkleinern") - the
 * Bricks Custom CSS field's `@media(max-width:820px) .pcg-section` value was changed live
 * from 56px to 48px (mirrored in design-exports/PCG_GlobalCSS_bereinigt.css). The desktop
 * base (88px) and everything else in this comment block are still untouched and still
 * governed by the original 2026-08-10 instruction - only the mobile number moved. */

/* C2c-07 - compact partner band. Each rule below pairs a reusable class with the element's
 * own ID (`.pcg-logogrid, #brxe-uxgnhd{...}`), so the fix is live today AND the client can
 * later attach `.pcg-logogrid` to the element in the Bricks editor, at which point the ID
 * alias can be dropped (documented in the SUMMARY as an optional upgrade path). None of
 * `#brxe-uxgnhd` (logo row), `#brxe-wovptb` (section), `#brxe-zfeiaf` (.pcg-wrap container)
 * or `#brxe-pvqoeb` (heading text) carries a `.pcg-*` class of its own today - all four are
 * new, documented ID-allowlist entries. */

/* Logo grid: width-driven (auto-fit + minmax floor), not the height-driven flex row that is
 * the actual mechanical cause of the "endless scrolling" complaint (discovered fact 23 - at
 * a fixed 36px logo height, a 600x125 logo is ~173px wide, so only one fits per row on a
 * 320px phone). Every track uses `minmax(…, 1fr)`, never a bare `fr` (Safari Grid "blowout"
 * safety, same reasoning as `.pcg-2col` and the Gewerke grid above). At 1200px content width
 * the 150px floor yields 6-7 tracks, at tablet the 120px floor yields 4-5, at a 320px phone
 * the 88px floor yields 2-3 - matching C2c-07's density brief. */
/* LIVE BUG FOUND 2026-08-10 (client report - page "3x too large" when zooming out, on the
 * homepage only): `#brxe-zfeiaf` (the `.pcg-wrap` parent) is itself
 * `display:flex;flex-direction:column;align-items:flex-start` - the SAME shrink-to-fit
 * cross-axis pattern that caused the counter-row bug fixed above. With `max-width:none` and
 * no explicit width, `#brxe-uxgnhd`'s `auto-fit` grid had no definite available width to
 * resolve columns against, so the browser fell back to a max-content-ish resolution instead
 * (confirmed live: `#brxe-uxgnhd` measured 1100px - SEVEN 133px columns - inside a 782px
 * parent, causing a real `document.documentElement.scrollWidth` overflow past
 * `clientWidth`, i.e. genuine page-wide horizontal overflow, not just an under-fill). Unlike
 * the counter row, this one is not just "too narrow" - `auto-fit` with an indefinite
 * container width can resolve WIDER than the real available space, which is exactly the "page
 * balloons" symptom. `width:100%` makes the grid's own box definite (equal to its wrap
 * parent), so `auto-fit` resolves against the real 1200px/tablet/phone width every time. */
.pcg-logogrid,
#brxe-uxgnhd {
	display: grid !important;
	width: 100% !important;
	grid-template-columns: repeat(auto-fit, minmax(150px, 1fr)) !important;
	align-items: center !important;
	justify-items: center !important;
	max-width: none !important;
}
@media (max-width: 1023px) {
	.pcg-logogrid,
	#brxe-uxgnhd {
		grid-template-columns: repeat(auto-fit, minmax(120px, 1fr)) !important;
	}
}
@media (max-width: 640px) {
	.pcg-logogrid,
	#brxe-uxgnhd {
		grid-template-columns: repeat(auto-fit, minmax(88px, 1fr)) !important;
	}
}

/* Logos sized by WIDTH, not height (discovered fact 23) - this is what actually removes the
 * one-per-row behaviour, not the grid alone. Existing hover-opacity behaviour is kept. */
.pcg-logogrid img,
#brxe-uxgnhd img {
	width: 100% !important;
	max-width: 130px !important;
	height: auto !important;
	max-height: 40px !important;
	object-fit: contain !important;
	opacity: 0.75;
}
@media (max-width: 640px) {
	.pcg-logogrid img,
	#brxe-uxgnhd img {
		max-width: 96px !important;
		max-height: 30px !important;
	}
}

/* Tighten the band's vertical spacing - the ONLY section this plan applies `--tight` to
 * (C2c-09 stays out of scope everywhere else, see the comment block above). */

/* ============================================================
   l9b TASK 5 — C2c-10 (UX standards), C2c-11 (shared selectors site-wide)
   ============================================================
   All three sub-standards are expressed through shared classes/element selectors, so they
   land on every page (C2c-11) with no per-page rule. */

@media (max-width: 640px) {
	/* Full-width, stacked primary buttons on phone. First make every button row stack, then
	 * make the buttons inside it fill the row. Desktop is untouched: every rule in this
	 * section lives inside this 640px query, so buttons stay text-width and side-by-side
	 * above it, exactly as C2c-10 requires. */
	.pcg-ctabtns,
	.pcg-btnrow {
		flex-direction: column !important;
		align-items: stretch !important;
		gap: 12px !important;
	}
	/* Cover the two ID-less Bricks containers that hold buttons directly (the hero's
	 * #brxe-idmbte and the homepage's #brxe-khynwm - discovered fact 26) without introducing
	 * IDs, using `:has()` consistent with Task 2's Gewerke container selector above.
	 * Deliberately also covers any future button row built the same way - that is the point
	 * of C2c-11. */
	.pcg-section .brxe-container:has(> .brxe-button),
	.pcg-section .brxe-block:has(> .brxe-button) {
		display: flex !important;
		flex-direction: column !important;
		align-items: stretch !important;
		gap: 12px !important;
	}
	/* CLIENT FEEDBACK 2026-08-10 (round 9): hero button gap "too large" - confirmed correct by
	 * the client's own comparison to the CTA band at the page bottom, which they called
	 * "perfect". Root cause: the global field's `.pcg-section .brxe-button{margin-top:26px
	 * !important}` (a spacing rule meant for buttons that follow OTHER content, e.g. a button
	 * under a paragraph) applies to every `.brxe-button` in a `.pcg-section` by default - the
	 * CTA band (`.pcg-ctabtns .brxe-button{margin-top:0 !important}`) and /kontakt/'s row
	 * (`.pcg-btnrow .brxe-button{margin-top:0 !important}`) already cancel it in the SAME global
	 * field, which is exactly why they already looked right. The hero's button row
	 * (`#brxe-idmbte`, a bare Bricks container, not `.pcg-ctabtns`/`.pcg-btnrow`) never got that
	 * cancellation, so its second button carried 26px margin-top ON TOP OF this file's own 12px
	 * flex `gap` - 38px total between two buttons whose own row spacing should be governed by
	 * `gap` alone. Cancelled generically on the `:has()` container above (not just the hero) so
	 * this fix is C2c-11-safe: any future full-width-stacked button row gets the same clean
	 * `gap`-only spacing without needing this file touched again. */
	.pcg-section .brxe-container:has(> .brxe-button) > .brxe-button,
	.pcg-section .brxe-block:has(> .brxe-button) > .brxe-button {
		margin-top: 0 !important;
	}
	/* `.pcg-btn-header` is the compact header CTA (discovered fact 28) and is explicitly
	 * excluded here - it is already hidden below 520px anyway, and full-width would break its
	 * intentionally compact header treatment. */
	.pcg-section .brxe-button:not(.pcg-btn-header) {
		display: flex !important;
		width: 100% !important;
		justify-content: center !important;
		text-align: center !important;
		box-sizing: border-box;
	}
	/* CLIENT FEEDBACK 2026-08-10 (round 2, hero specifically): "die Proportionen passen nicht,
	 * weil die Schrift im Gegensatz zum Kasten zu klein ist" - the full-width requirement above
	 * is correct and intentional (C2c-10, binding), and the button text IS already centred
	 * (`justify-content:center` + `text-align:center` both already win here - verified no
	 * competing rule targets `.brxe-button` at a higher specificity in either this file or the
	 * global CSS mirror). The actual complaint is proportion: the global field's mobile button
	 * font-size drops to 14px (`@media (max-width:639px){.brxe-button,.bricks-button{font-
	 * size:14px}}`) which reads as sparse/small inside a button now stretched to the full phone
	 * width - a mismatch that only exists once a button is full-width, so it is fixed here
	 * (scoped to this same 640px band) rather than in the global mobile type-scale, which other
	 * (non-full-width) uses of `.brxe-button` should not inherit. Bumped to the same 16px used
	 * elsewhere in the mobile scale for comparable prominence (`.pcg-body`'s mobile size), with
	 * slightly taller padding so the enlarged label keeps balanced whitespace around it.
	 *
	 * Same-day follow-up (2026-08-19): client feedback that mobile buttons still read "viel zu
	 * fett" after the desktop-only 260819-0fc slimming round above (that round never reached this
	 * selector - it lives inside this same max-width:640px query and was untouched). Vertical
	 * padding reduced 16px -> 12px (matching iro-berlin.de's own measured 12.8px), horizontal
	 * padding left at 30px since these buttons are `width:100%` full-width (C2c-10, binding) -
	 * horizontal padding doesn't change perceived width there, only the text's inset. Height
	 * still clears the 44px tap-target floor (16px+16px+~19px text-box was ~51px; 12px+12px+~19px
	 * is ~43-44px, and the separate pre-existing `min-height:44px !important` rule further above
	 * in this file still fixes the floor regardless of this padding value). */
	.pcg-section .brxe-button:not(.pcg-btn-header) {
		font-size: 16px !important;
		padding: 12px 30px !important;
	}
	/* CLIENT FEEDBACK 2026-08-10 (round 8, FINAL direction, given with an exact real-device
	 * reference screenshot - https://iro-berlin.de on a real iPhone Safari): hero buttons go
	 * back to full width and stacked (reverting round 4's Kontakt-style content-sized cap,
	 * which the client explicitly reversed after seeing it looked too small/sparse) - matching
	 * both the IRO reference AND the original binding C2c-10 requirement this element should
	 * never have been excepted from in the first place. `#brxe-idmbte` therefore gets NO
	 * special treatment anymore - it simply falls through to the site-wide full-width button
	 * rule at the top of this block, same as every other page. Only two hero-specific additions
	 * remain: the arrow glyph (see below) and the two IDs' own justify-content/align-items
	 * override (still needed - their pre-existing per-element CSS has no !important and this
	 * file's class-level rule must still win). */
	#brxe-wgcjrt,
	#brxe-zfwwns {
		justify-content: center !important;
		align-items: center !important;
		flex-direction: row !important;
	}
	/* Arrow glyph, matching the site's own existing pattern (".pcg-card-link"-adjacent buttons
	 * like "Alle Referenzen →" already ship the arrow as literal text in the Bricks button
	 * label, not CSS) - the hero's two buttons were never given that label text, and changing
	 * Bricks content is outside this CSS-only file's reach, so the same visual result is added
	 * here as a `::after` pseudo-element instead. `\2192` is the Unicode escape for "→" (this
	 * project's established convention for special glyphs - see the design system's own
	 * checkmark rule - avoids the raw character turning into encoding-salad). */
	#brxe-wgcjrt::after,
	#brxe-zfwwns::after {
		content: "\2192";
		margin-left: 10px;
	}
}

/* CLIENT FEEDBACK 2026-08-10 (round 2): "/kontakt/ Buttons sind nicht zentriert und groß,
 * sondern linksbündig - bitte wie auf dem Rest der Seite." `.pcg-btnrow` (global CSS mirror)
 * is defined identically to `.pcg-ctabtns` except it never got `justify-content:center` - the
 * mobile full-width/stacked treatment above already applies equally to both classes, so this
 * gap was desktop/tablet-only. Confirmed via a live HTML fetch of all 8 main templates that
 * `.pcg-btnrow` is only ever actually attached to one real element site-wide - `/kontakt/`'s
 * `#brxe-vkybiv` - so centring the class carries no risk of changing any other page. Matches
 * `.pcg-ctabtns` exactly rather than adding a one-off ID rule, since any FUTURE `.pcg-btnrow`
 * use should get the same site-wide-consistent treatment (C2c-11) without needing this file
 * touched again.
 *
 * LIVE BUG FOUND 2026-08-10 (client: "gar keine Änderungen im Stil vollzogen" - the fix above
 * WAS live and `justify-content:center` WAS applied, confirmed via computed style, but had no
 * visible effect): the THIRD instance of the same shrink-wrap root cause as the counter row and
 * the partner logo grid. `#brxe-vkybiv`'s own parent (`#brxe-wajjgj.pcg-wrap`) is again
 * `display:flex;flex-direction:column;align-items:flex-start`, so `#brxe-vkybiv` measured only
 * 398px (exactly its two buttons' content width) inside a 1200px wrap - `justify-content:center`
 * had zero slack space to redistribute. `width:100%` makes the row actually wide, so centring
 * becomes visible - the "breit UND zentriert" the client asked for is one property, not two.
 *
 * CLIENT FEEDBACK 2026-08-11 (round 12): explicit reversal of the above - the /kontakt/ button
 * row should be left-aligned on desktop, not centred. `width:100%` is kept (harmless for
 * flex-start - it only ever mattered for giving `justify-content:center` slack to redistribute;
 * a flex-start row already sits flush left regardless of its own width). Mobile is unaffected -
 * the max-width:640px block above already forces column/stretch independent of this value. */
.pcg-btnrow {
	justify-content: flex-start !important;
	width: 100% !important;
}

@media (max-width: 640px) {
	/* 44x44px minimum tap targets on phone. */
	.pcg-section .brxe-button,
	.wpcf7-form .wpcf7-submit {
		min-height: 44px !important;
		align-items: center;
	}
	/* The burger and its overlay links are the controls the brief names first. */
	.bricks-mobile-menu-toggle {
		min-width: 44px !important;
		min-height: 44px !important;
	}
	.bricks-mobile-menu-wrapper a {
		min-height: 44px;
		display: flex;
		align-items: center;
	}
	/* Link rows the brief also names. `.pcg-card-link` needs nothing here: it is already a
	 * stretched overlay covering the whole card, far larger than 44px. */
	.pcg-contactlist a,
	.pcg-backlink {
		min-height: 44px;
		display: inline-flex;
		align-items: center;
	}
}

/* Visible focus states (all widths, no media query). `:focus-visible` keeps mouse/touch
 * interaction visually clean - only keyboard navigation shows the ring. Red `#EE0000` is
 * used because it is the design system's only accent - no new colour is introduced. */
a:focus-visible,
button:focus-visible,
[tabindex]:focus-visible,
.brxe-button:focus-visible,
input:focus-visible,
select:focus-visible,
textarea:focus-visible {
	outline: 2px solid #EE0000 !important;
	outline-offset: 2px !important;
	border-radius: 4px;
}

/* Contrast variant on dark backgrounds: white reads on navy where red would not always. */
.pcg-navy a:focus-visible,
.pcg-navy button:focus-visible,
.pcg-navy .brxe-button:focus-visible,
.bricks-mobile-menu-wrapper a:focus-visible,
header.brx-sticky a:focus-visible,
header.brx-sticky button:focus-visible {
	outline-color: #fff !important;
}

/* Contact Form 7 ships an explicit `outline:none` on `:focus` in the global CSS mirror at
 * specificity (0,4,1) (discovered fact 27). This selector mirrors that exact shape with
 * `:focus-visible` so it matches (at least) that specificity - combined with this file's
 * later print order, that is what makes it win. The existing navy `border-color` focus
 * styling is intentionally kept as well (belt and braces, not a replacement). */
.wpcf7-form input:not([type=checkbox]):not([type=radio]):focus-visible,
.wpcf7-form select:focus-visible,
.wpcf7-form textarea:focus-visible {
	outline: 2px solid #EE0000 !important;
	outline-offset: 2px !important;
}

/* ============================================================
   QUICK TASK 260810-l9b — FIX-FORWARD ROUND (client live-test feedback, 2026-08-10)
   ============================================================
   The orchestrator deployed Tasks 1-5 to staging, the client tested live and reported three
   findings plus a clarifying instruction. All three are addressed below, fixing FORWARD from
   the already-committed Tasks 1-5 work (none of that work is redone or reverted). Nothing in
   this section touches the live Bricks Custom CSS field - every fix ships in this one child-
   theme file, same contract as the rest of this stylesheet. */

/* ------------------------------------------------------------
   FIX 1 — left-align must be GLOBAL, not just the two known headings (client: "die gesamte
   Seite muss linksbündig sein nicht nur die zwei Überschriften, bitte wende die Regeln global
   an"), plus a genuine site-wide re-audit rather than trusting the two previously-known
   elements alone.
   ------------------------------------------------------------
   ROOT CAUSE (confirmed live via frontend-layer.min.css, not assumed): every `.pcg-section` is
   a Bricks `.brxe-section`, and Bricks' own base rule is
   `.brxe-section{align-items:center;display:flex;flex-direction:column;...}` - EVERY section on
   the site is a centered flex column by default, with NO horizontal padding of its own. A text
   element sitting as a DIRECT child of the section (no `.pcg-wrap` in between) has nothing to
   catch it once `align-self:flex-start` is applied - it gets ripped flush to the true window
   edge instead of the page's usual 24px/20px margin. That is exactly the live incident the
   design-exports/PCG_GlobalCSS_bereinigt.css mirror's own exception rule
   (`#brxe-jdafeg, #brxe-ktbmez, #brxe-bvrrgu{ text-align:center !important;
   align-self:center !important; }`, inside that file's trailing min-width:1024px block)
   worked around by leaving those three elements centered rather than fixing the underlying
   containment gap. The client has now asked for the real fix (the SAME technique already used
   for the hero's #brxe-vputtu: give the direct-child element itself real `.pcg-wrap` box-model
   geometry) instead of a permanent exception - AND for a genuine re-audit, not trust in the two
   previously-known elements alone.

   AUDIT (this session, HTTP-fetched + parsed live DOM, not assumed): walked every `.pcg-section`
   on all six main templates (/, /referenzen/, /leistungen/, /leistungen/waermedaemmung-wdvs/,
   /ueber-uns/, /kontakt/) plus two project-detail pages, looking for a direct child of a
   `.pcg-section` that is NOT itself `.pcg-wrap`-classed and carries visible text. Result: the
   pattern exists ONLY on the homepage, in exactly the two sections already known -
   `#brxe-lotjmo` ("Vorher/Nachher") and `#brxe-akmoie` ("Leistungen") - but each section has ONE
   MORE affected element beyond the single heading the earlier incident caught, because the
   site-wide desktop left-align rule only ever targets elements carrying a `.pcg-eyebrow`/
   `.pcg-h1`/`.pcg-h2`/`.pcg-subhead`/`.pcg-lead`/`.pcg-body` class - these two never carried one,
   so they were silently centered by the Bricks default and never flagged by anything:
     - `#brxe-lotjmo` directly parents `#brxe-dvdrnf` ("Ziehen Sie den Regler von links nach
       rechts...", the section's lead line) in addition to the already-known
       `#brxe-jdafeg`/`#brxe-ktbmez`.
     - `#brxe-akmoie` directly parents `#brxe-knqazm` ("Unsere Leistungen", the section's eyebrow
       line) in addition to the already-known `#brxe-bvrrgu`.
   Five elements, two sections, no other page or project-detail template affected - the
   before/after slider (`#brxe-fiprbw`) and the Gewerke tile grid (`#brxe-zrnngv`) further down
   in these SAME two sections already carry their own `.pcg-wrap` class, which is exactly why
   they were never part of this bug.

   FIX. Each of the five elements becomes its own "content wrapper" - the same treatment Task 1
   gave the hero's `#brxe-vputtu` - because, like the hero container, each is a direct flex child
   of its section with nothing wrapping it. The equal-ID-specificity `!important` override below
   beats the mirror's own exception rule via this file's later print order (same mechanism as
   every other override in this stylesheet); the mirror file itself is left untouched (it mirrors
   what is actually live in the Bricks Custom CSS field, which this project has no write access
   to beyond this one child-theme file) and instead gains a documentation-only comment pointing
   here (see that file). */
@media (min-width: 1024px) {
	#brxe-jdafeg,
	#brxe-ktbmez,
	#brxe-dvdrnf,
	#brxe-knqazm,
	#brxe-bvrrgu {
		width: 100% !important;
		max-width: 1200px !important;
		box-sizing: border-box !important;
		/* #brxe-dvdrnf and #brxe-knqazm were never part of the mirror's centering exception -
		 * they carry no .pcg-eyebrow/.pcg-lead class, so the site-wide left-align rule never
		 * reached them either. They simply inherited the section's align-items:center default
		 * and are being left-aligned here for the first time, exactly like their two sibling
		 * elements. */
		text-align: left !important;
		align-self: flex-start !important;
	}
}

/* CLIENT FEEDBACK 2026-08-10 (round 3, CORRECTED round 5): the original round-3 rule here set
 * an UNSCOPED `max-width:100% !important` on all five elements - appearing LATER in this file
 * than the >=1024px rule above that sets `max-width:1200px !important` on the same selectors,
 * so by source-order tie-break (same specificity, same !important) THIS rule was winning at
 * EVERY width, including desktop - silently deleting the 1200px cap and letting each element
 * stretch to the full viewport width (confirmed live: computed max-width was the literal string
 * "100%", not "1200px", and the element measured the full 1440px viewport instead of the
 * intended ~1200px). That is precisely the "text flush against the true browser edge, outside
 * the frame" regression the client reported with a screenshot. Scoped to max-width:1023px only
 * (mobile-only "never exceed the viewport" clamp), so it can never again collide with the
 * >=1024px geometry rule above. */
@media (max-width: 1023px) {
	#brxe-jdafeg,
	#brxe-ktbmez,
	#brxe-dvdrnf,
	#brxe-knqazm,
	#brxe-bvrrgu {
		max-width: 100% !important;
		box-sizing: border-box !important;
		/* CLIENT FEEDBACK 2026-08-10 (round 7): "Ziehen Sie den Regler..." (#brxe-dvdrnf) still
		 * read as "going into the edge" on phone even after the max-width clamp above. Not a
		 * true overflow (scrollWidth already matched clientWidth) - these five elements simply
		 * never had the page's normal 20px mobile side margin that .pcg-wrap gives everything
		 * else, because on phone they fall back to being bare flex children with zero padding
		 * of their own (the >=1024px rule above is the only place that gave them any). Matches
		 * .pcg-wrap's own <=820px step (see the global field: 24px down to 20px at max-width:
		 * 820px) - restated at both steps here since these elements are outside .pcg-wrap and
		 * get no padding from it at all otherwise. */
	}
}

/* ------------------------------------------------------------
   FIX 2 — counter row: investigated, no code change required.
   ------------------------------------------------------------
   Client instruction: keep Task 3's desktop full-spread rule
   (`.pcg-stats{justify-content:space-between !important} .pcg-stats > *{flex:1 1 0 !important}`)
   exactly as it is - it is directionally correct - and find/fix only a REAL overflow past
   `.pcg-wrap`'s own established margin, not weaken the spread itself.

   INVESTIGATION (this session, HTTP-fetched + computed from source, not assumed):
     - `.pcg-stats` is nested inside a genuine `.pcg-wrap` ancestor on all THREE live counter
       rows, not just the homepage: `#brxe-wgbarq` inside `#brxe-tidkjz.pcg-wrap` (/),
       `#brxe-scneak` inside `#brxe-vnpkkx.pcg-wrap` (/referenzen/), `#brxe-xvazur` inside
       `#brxe-ovmvpz.pcg-wrap` (/ueber-uns/) - confirmed live, no per-element width override on
       any of these six IDs.
     - Bricks' own base CSS applies a universal `*, :after, :before, html{box-sizing:border-box}`
       reset (frontend-layer.min.css), so `.pcg-wrap`'s `width:100% !important` +
       `padding-left/right:24px !important` cannot itself overflow past `max-width:1200px` -
       there is no content-box/border-box mismatch to exploit here.
     - `.pcg-stats > *`'s `min-width:150px` (global field, no `!important`) is a soft floor far
       below any real `.pcg-wrap` content width at >=1024px (976px at the narrowest matching
       viewport, 1024px, divided across 4 items via `flex:1 1 0` - each item renders far wider
       than the 150px floor, so the floor never actually engages and cannot force an overflow).
     - `.pcg-stats > *:first-child{padding-left:0}` / `:last-child{padding-right:0}` (Task 3)
       make the outer tiles' text sit flush with `.pcg-wrap`'s OWN inner edge (i.e. exactly at
       the page's established 24px margin) - not past it. That is the intended "edge to edge
       within the page's margins" mockup look the client is asking to keep, not a bug.
   No real overflow exists at any viewport from 1024px upward on any of the three pages - the
   full-width spread already stays inside `.pcg-wrap`'s boundary everywhere it is used. Nothing
   is changed here; this comment stands as the recorded investigation per the client's own
   "confirmed via computed styles, not assumption" instruction. The hairline dividers
   (`.pcg-stats > * + *{border-left:...}`, global field) are untouched and remain visible. */

/* ------------------------------------------------------------
   FIX 3 — large empty gap between the Partner/Mitgliedschaften section and "Haupteinsatzgebiet
   / Projekte aus Berlin" (homepage).
   ------------------------------------------------------------
   ROOT CAUSE (confirmed live via computed per-element CSS, not assumed - and NOT introduced by
   Task 4's partner-band tightening): the Berlin-map section's own heading wrap,
   `#brxe-umkdfg.brxe-container.pcg-wrap` (direct child of `#brxe-rkpikk.pcg-section`, holding
   only the "Haupteinsatzgebiet" eyebrow and "Projekte aus Berlin" heading - the map itself lives
   in a separate sibling, `#brxe-rgsmoz`), carries its OWN pre-existing Bricks element padding:
   `padding-top: var(--space-xl); padding-bottom: var(--space-xl)` (`--space-xl` resolves to
   `48px`, confirmed in the live `:root` block). That 48px padding-top STACKS on top of
   `.pcg-section`'s own base `padding-top:88px !important` on the section itself, because they
   are two different elements (the section's padding and this wrap's padding both apply before
   any pixel of the heading text is reached) - 136px total before "Haupteinsatzgebiet" becomes
   visible, against ~88px for every comparable section-to-section transition on the same page
   (verified: neither `#brxe-lotjmo` nor `#brxe-akmoie`, the other two homepage section starts,
   carry an equivalent extra top-padding on their own first child - `#brxe-umkdfg` is the one
   anomaly). This padding lives in Bricks' own per-element style panel (not in the Custom CSS
   field this project's mirror file tracks, and not something reachable through any repo file
   other than this one) - it has always been there, independent of Task 4. It only became
   visually prominent THIS round because Task 4 made the partner band directly above it
   noticeably shorter, turning what used to be a proportionally minor redundancy into a single,
   conspicuous blank patch between a now-compact section and the next section's heading -
   exactly the client's "endless scrolling" report.

   FIX. Cancel only the redundant top padding on this one wrap - not `.pcg-section`'s shared base
   rhythm (still out of scope per C2c-09) and not this wrap's own `padding-bottom` (that 48px
   is genuine, wanted separation between the heading and the map content below it, not a
   cross-section stack). Once removed, this section's top gap becomes exactly the same 88px
   every other `.pcg-section` boundary on the page already uses - "consistent with the OTHER
   section boundaries," not larger than them, per the client's own framing. New, documented ID
   allowlist entry: `#brxe-umkdfg` carries no `.pcg-*` class of its own beyond the shared
   `.pcg-wrap`, which cannot be used here (every `.pcg-wrap` site-wide would lose its top
   padding). `--space-xl` has no responsive override anywhere on this page, so this rule is
   deliberately unscoped (applies at every width) rather than only >=1024px. */
/* ENTFERNT am 2026-08-24 (Auftrag Runde 5, siehe Banner weiter oben).
   Hier stand `#brxe-umkdfg { padding-top: 0 !important }`. Zwei Gruende:

   (1) SIE IST GEGENSTANDSLOS GEWORDEN. Die Regel hat ein Panel-Polster von
       48px (`var(--space-xl)`) aufgehoben, das der Kunde damals nicht
       wegbekam. Am 2026-08-24 am Live-DOM nachgemessen: die Bricks-Regel fuer
       diese ID enthaelt ueberhaupt kein Polster mehr — sie lautet nur noch
       Hintergrundfarbe, Maximalbreite und Grossschreibung. Es gibt also nichts
       mehr zu neutralisieren.

   (2) SIE SPERRT DEN KUNDEN AUS. Setzt er im Bricks-Panel ein oberes Polster
       auf diesen Container, schreibt Bricks das OHNE `!important` — diese
       Regel hier gewinnt und der Panel-Wert bleibt wirkungslos. Genau das
       Verhalten, das `.claude/CLAUDE.md` untersagt, und genau die Beschwerde
       vom 2026-08-24 („trotz Abstand in Bricks").

   NICHT die Ursache dafuer, dass die Ueberschrift „Projekte aus Berlin" an der
   Karte klebt: das ist das UNTERE Polster desselben Containers, urspruenglich
   ebenfalls 48px aus dem Panel, das inzwischen im Panel geloescht wurde. Diese
   Regel hat es nie angefasst. Der Abstand gehoert ins Panel zurueck. */

/* ============================================================
   QUICK TASK 260819-65w, Task 2 — Berlin-map/list section mobile side padding
   ============================================================
   Root cause CONFIRMED via a fresh HTTP fetch + parse of the live staging homepage's raw
   markup (not assumed): the map/list block sitting BESIDE the already-`.pcg-wrap`-classed
   heading wrap (`#brxe-umkdfg`, FIX 3 directly above - left untouched, it already gets real
   padding via that shared class) is a SIBLING shortcode element, `#brxe-rgsmoz`, holding
   `[pcg_berlin_map]`'s server-rendered `.pcg-map-layout`/`.pcg-map-wrap` output. Confirmed via
   the fetched DOM: `<div id="brxe-rgsmoz" class="brxe-shortcode">` - no `.pcg-wrap` class - and
   its only inline Custom CSS is `max-width:1200px; align-self:center` (no padding-left/-right
   at ANY width; grepping the full live inline `<style>` block found no other rule for this ID
   at all). Same shape as every other "raw Bricks element with no `.pcg-wrap` ancestor" bug
   already fixed in this file (see FIX 1's five-element audit above, and the original
   `#brxe-oqjbke`/`#brxe-nvrwdc` fix) - the map/list content (berlin-map.css's own
   `.pcg-map-wrap`/`.pcg-map-layout`) deliberately declares no horizontal padding of its own
   (see that file's "outer width is Bricks' job" comment), relying entirely on an ancestor that,
   in this one case, never supplied it.

   Since NO responsive rule exists for `#brxe-rgsmoz` at any width, it is edge-flush not just on
   phone but across the whole sub-1200px range - the fuller two-step pattern already used for
   the FIX 1 five-element audit above (24px at <=1023px, tightened to 20px at <=820px, the
   site's own two-step `.pcg-wrap` convention) is applied here rather than a single mobile-only
   step. `box-sizing:border-box` is restated for parity with that same precedent even though
   Bricks' own global `*{box-sizing:border-box}` reset already covers it. New, documented ID
   allowlist entry: `#brxe-rgsmoz` carries no `.pcg-*` class of its own (confirmed above), so it
   cannot be targeted any other way. */
@media (max-width: 1023px) {
	#brxe-rgsmoz {
		box-sizing: border-box !important;
	}
}

/* CLIENT FEEDBACK 2026-08-10 (round 6): the "Interesse an einer Zusammenarbeit?" CTA band
 * (and any other .pcg-ctaband/.pcg-ctaband-light use) rendered flush against the LEFT edge of
 * its .pcg-wrap instead of centred on the page - same root cause pattern as the counter row,
 * partner logo grid and /kontakt/ button row (a `.brxe-container.pcg-wrap` parent is
 * `display:flex;flex-direction:column;align-items:flex-start` from Bricks' own base framework,
 * which positions a shrink-to-fit child at the START of the cross axis instead of centring it).
 * Originally read the mockup as a narrower, visibly "boxed" panel (fixed with `margin:auto`
 * alone, preserving shrink-to-fit width) - CLIENT CORRECTION 2026-08-11 (round 13): the mockup
 * actually shows the panel stretched edge-to-edge to the page's content boundary, same width as
 * every other section on the page, not a narrower centred box. `width:100%` added below;
 * `margin:auto` is now a no-op at 100% width but left in place as a harmless safety net (keeps
 * the panel centred if any future content ever caps its width again). */
.pcg-ctaband,
.pcg-ctaband-light {
	margin-left: auto !important;
	margin-right: auto !important;
	width: 100% !important;
}

/* CLIENT FEEDBACK 2026-08-10 (round 6, found via a systematic left-position scan of every
 * heading on all 5 main templates - not just the two elements the client had spotted so far):
 * #brxe-lifzpw ("Ausgewählte Projekte" heading) rendered centered on the page instead of
 * flush with "REFERENZEN" above it. DIFFERENT root cause from the FIX 1 audit above: this
 * heading's direct parent, #brxe-vmpozw (a .brxe-block shared with the eyebrow), IS itself
 * correctly positioned at the .pcg-wrap edge - the bug is one level in, at
 * display:flex;flex-direction:column;align-items:center on that .brxe-block (Bricks' own
 * default for this component type), which centers the heading's own shrink-to-fit box (385px)
 * within the block, while the eyebrow next to it already carries its own
 * align-self:flex-start (from the site-wide .pcg-eyebrow rule) and stays flush left. The
 * heading has no .pcg-h2 class so the equivalent site-wide rule never reached it - same
 * "missing shared class" pattern FIX 1 already found twice, a third instance. Scan confirmed
 * this is the ONLY such case across all 5 main templates (/, /referenzen/, /leistungen/,
 * /ueber-uns/, /kontakt/) - every other heading's left edge already matches its section's
 * established content edge. */
/* Client round-2 feedback (quick task 260811-6od), homepage mobile alignment audit:
   this rule was always desktop-intent - part of the same "section heads sit left"
   decision the FIX 1 audit block above already scopes to min-width:1024px - but it
   was written with NO media query around it, so it also fired on mobile, where it
   dragged the heading left while its "Referenzen" eyebrow (which has no mobile
   override at all - see the comment above about .pcg-eyebrow's align-self living
   only inside the mirror's own min-width:1024px block) stayed centred. That is
   exactly the disagreement the client reported. Scoped here to min-width:1024px,
   matching the width band every other rule expressing this same decision already
   uses. The mobile-width state of this same ID is now stated explicitly in the new
   260811-6od section at the end of this file, rather than left implicit. */
@media (min-width: 1024px) {
	#brxe-lifzpw {
		align-self: flex-start !important;
	}
}

/* CLIENT FEEDBACK 2026-08-10/11 (round 10): "passe nur die Sektionen an, die groesser als der
 * Bildschirm sind UND wo die Abstaende zu gross sind" - measured every homepage section's
 * height against one viewport plus its own content-vs-padding gap. Two sections had genuine
 * excess beyond the standard 88px .pcg-section rhythm (content itself, e.g. the map graphic or
 * the before/after slider, accounts for the rest and is left untouched - C2c-09's "don't touch
 * the general rhythm" still holds, this is two specific redundant element-level margins):
 * - #brxe-knqazm ("UNSERE LEISTUNGEN" eyebrow, Leistungen/Gewerke section) carries its own
 *   margin-top:50px on top of the section's 88px padding-top - 138px total before any content,
 *   confirmed by comparing this section's top content-gap (138px) against its own bottom gap
 *   (88px, no such element there).
 * - #brxe-vclxaw (a nested .brxe-section inside the "Warum PCG" section) carries its own
 *   margin-top:64px AND margin-bottom:64px on top of the outer section's 88px padding on both
 *   sides - confirmed by measuring 152px top AND bottom content-gaps against the 88px every
 *   other section uses. This is a spacing-only trim - the "Warum PCG" section's own structure/
 *   photo stays exactly as the client built it, nothing here touches that. */

/* CLIENT FEEDBACK 2026-08-11 (round 11): client re-tested and still saw an oversized gap
 * above/below "Warum PCG" - round 10 above zeroed #brxe-vclxaw's OWN margin (which measured
 * 0px live already, a red herring) but missed the REAL redundant spacing one level deeper:
 * live getComputedStyle() on the two content children showed margin-top:100px AND
 * margin-bottom:100px on BOTH #brxe-oqjbke (the photo) and #brxe-nvrwdc (the heading/icon
 * column) - raw Bricks per-element settings, not from this file. Stacked on top of the outer
 * .pcg-section's own 88px padding, this produced 188px top/bottom instead of the 88px every
 * other section on the page uses. Cancelling both restores the standard rhythm without
 * touching the section's base padding, its structure, or the mobile-only hide/centre rules
 * already scoped to these same two IDs further above (both IDs are already allowlisted). */

/* CLIENT FEEDBACK 2026-08-11 (round 11): homepage "Vorher/Nachher" before/after slider
 * measured a genuine, non-buggy 88px/88px section padding (matching every other section) -
 * its extra height came from the slider image itself, set via the [pcg_before_after]
 * shortcode's own --pcg-ba-height:600px inline custom property (before-after.css, DEC-2).
 * Client asked for a more compact box; reduced to 450px (2.7:1 instead of 2:1), scoped to
 * this ONE homepage instance only (#brxe-fiprbw) so the project-detail pages' own
 * before/after instances, which set their own height independently, are untouched.
 * !important is required because the shortcode's inline style attribute sets this same
 * custom property on the same element - a plain declaration here would lose to it
 * regardless of selector specificity (inline beats external stylesheet unless !important). */
#brxe-fiprbw .pcg-ba-wrap {
	--pcg-ba-height: 450px !important;
}

/* ============================================================
   QUICK TASK 260819-65w, Task 3 — before/after slider, mobile 4:3 aspect ratio
   ============================================================
   Root cause (fully diagnosed from source, no live investigation needed): the rule directly
   above declares `--pcg-ba-height:450px !important` with NO media-query gate, so this box holds
   a fixed 450px height at every viewport width while its width shrinks with the container on
   phone - producing an increasingly tall/portrait box instead of 4:3. before-after.css already
   exposes a generic `--pcg-ba-aspect-ratio` custom property (default `auto`) on the same rules,
   but per that file's own comment, an EXPLICIT height always wins over `aspect-ratio`
   (`aspect-ratio` only resolves a dimension that would otherwise be `auto`) - so setting
   `--pcg-ba-aspect-ratio` alone, without also resetting `--pcg-ba-height` back to `auto`, would
   have zero visible effect.

   This block overrides BOTH custom properties on mobile only, placed textually AFTER the
   unscoped 450px rule above so this file's established same-specificity/same-!important
   source-order tie-break resolves in favour of this later, narrower rule (same mechanism
   documented throughout this file, e.g. the round-3/round-5 `#brxe-jdafeg` history). Because
   both properties are set on the ancestor `.pcg-ba-wrap`, they inherit down into `.pcg-ba`/
   `.pcg-ba img` automatically, exactly like the existing desktop override already does - not
   duplicated onto `.pcg-ba`/`.pcg-ba img` directly. Desktop (the rule above, unscoped) is
   untouched; the pre-existing `@media (max-width:520px){ .pcg-ba, .pcg-ba__single{
   max-height:60vh } }` safety-ceiling rule elsewhere in this file also stays untouched - it is
   an orthogonal cap on very short viewports, not a conflict with this 4:3 ratio. */
@media (max-width: 640px) {
	#brxe-fiprbw .pcg-ba-wrap {
		--pcg-ba-height: auto !important;
		--pcg-ba-aspect-ratio: 4 / 3 !important;
	}
}

/* ============================================================
   QUICK TASK 260819-p44, Task 1 — before/after slider, genuine 4:3 at EVERY
   width (supersedes both the round-11 450px desktop rule and the 65w
   max-width:640px mobile-only rule above)
   ============================================================
   Client's new brief (design-exports/AUFTRAG_Claude_Code_Startseite_VorherNachher_
   2Spalten.md) makes explicit that the 4:3 requirement applies at EVERY width in
   this section, not only below 640px (260819-65w) and not the 450px/1200px ~2.67:1
   box (round-11, still in force above at every width including desktop). Both older
   rules use the SAME selector, `#brxe-fiprbw .pcg-ba-wrap`, and the SAME
   `!important` weight - this rule reuses that identical selector text, appended
   LATER in the file than both, so it wins at every width via this file's own
   established same-specificity/same-!important source-order tie-break (the same
   mechanism documented throughout this file). Neither older block is edited or
   deleted, per this file's "append at the end" convention.

   Per before-after.css's own DEC-2/`.pcg-ba img` comment, `--pcg-ba-height` and
   `--pcg-ba-aspect-ratio` must be reset TOGETHER (an explicit height always wins
   over aspect-ratio, since aspect-ratio only resolves a dimension that would
   otherwise be auto) - resetting the ratio alone would have no visible effect.
   `--pcg-ba-object-fit:cover` is restated here for self-sufficiency even though the
   shortcode's own inline style already sets `cover` today (AUFGABE point 1 is
   already satisfied by the existing shortcode call). before-after.css itself is
   untouched - this rule only overrides the same three custom properties on the
   ancestor `.pcg-ba-wrap`, which inherit down into `.pcg-ba`/`.pcg-ba img`
   automatically, exactly like both older overrides already do. */
#brxe-fiprbw .pcg-ba-wrap {
	--pcg-ba-height: auto !important;
	--pcg-ba-aspect-ratio: 4 / 3 !important;
	--pcg-ba-object-fit: cover !important;
}

/* ============================================================
   QUICK TASK 260811-5ob — homepage/hero polish, sitewide uppercase bundle
   ============================================================
   Everything from here down implements this quick task's five deliverables
   (see 260811-5ob-PLAN.md). Same file, same enqueue/print-order contract as
   every section above - no new stylesheet, nothing pasted into Bricks. */

/* ============================================================
   Task 2 — #brxe-lifzpw ("Ausgewaehlte Projekte") gets the full .pcg-h2
   treatment, drift-guarded against the Bricks Custom CSS mirror
   ============================================================
   Root cause: this heading (h3.brxe-heading) carries no .pcg-* class at all,
   so neither the 260810-ja8 type scale nor this quick task's Task 1
   uppercase rule can reach it - it has been stuck on raw Bricks defaults
   (Inter, font-weight:800, text-transform:none) since it was built, the one
   homepage heading that never received the 260810-ja8 typography treatment.

   This block ADDS to, not replaces, the pre-existing round-6
   align-self:flex-start rule on this same ID further above in this file
   (line ~1558, now scoped inside a min-width:1024px query as of quick task
   260811-6od's client round-2 feedback fix, which also added an explicit
   max-width:1023px centred block for the same ID - see that task's own
   section at the end of this file) - that rule fixes horizontal alignment,
   this one fixes type, so no SUPERSEDED marker is needed here.

   Values restate .pcg-h2's full contract (design-exports/PCG_GlobalCSS_
   bereinigt.css) at all three breakpoints, all !important so they beat
   Bricks' own un-important per-element declarations. The letter-spacing and
   text-transform values match what Task 1 gives every real .pcg-h2 AFTER
   this quick task ships (0.01em / uppercase), not the mirror's original
   mixed-case -0.015em - the point is that this heading ends up looking
   identical to a real .pcg-h2 in its final, uppercase state.

   No color is declared here and none should be added: this heading's
   section colour context was not confirmed live before writing this rule,
   and setting one blind risks white-on-white or navy-on-navy - a future
   editor should leave this alone rather than "finishing the job".

   This lives here, not in pcg-fonts.css, because pcg-fonts.css is
   contractually typeface-only (its own test forbids font-size/letter-
   spacing outside its @font-face blocks) and splitting one element's fix
   across two files would be harder to revert than keeping it whole in the
   file that already owns every other per-element ID exception. */
#brxe-lifzpw {
	font-family: var(--pcg-font-heading) !important;
	font-size: 34px !important;
	font-weight: 700 !important;
	line-height: 1.15 !important;
	letter-spacing: 0.01em !important;
	text-transform: uppercase !important;
}
@media (max-width: 1023px) {
	#brxe-lifzpw {
		font-size: 30px !important;
	}
}
@media (max-width: 639px) {
	#brxe-lifzpw {
		font-size: 26px !important;
	}
}

/* ============================================================
   Task 3 — hero fills more vertical space, mobile button breathing room,
   and the 28-Jahre trust line
   ============================================================ */

/* --- Sub-block C: hero proportions (desktop only) --------------------------
   Client's own framing: too much empty photo below the buttons, the content
   block does not fill the hero - reference is iro-berlin.de's own hero
   proportion (own colours, not a clone).

   Two things this block deliberately does NOT do, so a future reader does
   not undo them:
   - The hero section's min-height (calc(100vh + 90px) / calc(100svh + 90px),
     set further above in this file) stays exactly as is. Shrinking it would
     let the next section peek above the fold, reversing the client-approved
     l9b C2c-05b decision.
   - #brxe-vputtu's own margin-top:170px (also set further above) stays.
     Discovered fact 9's arithmetic leaves roughly 8px of clearance under the
     fixed 72px header; reducing it blind is exactly the class of live
     collision bug the client already caught twice in quick task 260810-1ld.

   Instead, the space is filled by growing the CONTENT - desktop only, inside
   min-width:1024px, so every already-tuned tablet and phone value (the base
   rule and its own max-width:640px step, both further above) is untouched.

   Quick task 260811-ldk, Task 3c (HERO-01, IRO-level desktop scale): every
   value below is now driven by a --pcg-hero-* variable (see the contract
   comment above the base rhythm rule, further above in this file) - the
   px fallbacks are the same 74px/800/1.03/-0.02em the brief specifies,
   font-weight:800 is safe in THIS file (the weight-800 prohibition test
   reads only the Bricks Custom CSS mirror, not this file). text-transform
   is added WITHOUT !important - the uppercase currently comes from a
   Bricks per-element setting, so a non-important declaration here
   preserves the look on a freshly-rebuilt hero while letting the Bricks
   field keep winning (EDIT-02c); this is the one hero !important that can
   be relaxed without losing a live-verified fix. Weight/leading/tracking
   are deliberately Desktop-only here, exactly as the brief specifies - the
   smaller breakpoints above keep today's values (see the SUMMARY for this
   round's offered one-line follow-up). */
@media (min-width: 1024px) {
	.pcg-hero-title,
	#brxe-vputtu > h1,
	#brxe-vputtu > h2,
	#brxe-vputtu > h3 {
		font-size: var(--pcg-hero-size, 74px) !important;
		font-weight: var(--pcg-hero-weight, 800) !important;
		line-height: var(--pcg-hero-leading, 1.03) !important;
		letter-spacing: var(--pcg-hero-tracking, -0.02em) !important;
		text-transform: uppercase;
	}
}

/* --- Sub-block C-bis: mobile hero orphan-word wrapping ---------------------
   Client flagged two mobile-only orphan words after the vertical-rhythm fixes
   settled: the eyebrow's last line was "MALERARBEITEN" alone (3 items broke to
   line 1, the 4th orphaned on line 2), and the lead paragraph's last line was
   "Daemmung" alone (same pattern, 4 words broke to lines 1-2, the 5th
   orphaned on line 3). `text-wrap: pretty` (CSS Text 4) is the standard,
   purpose-built fix for exactly this - it lets the browser rebalance ONLY
   this element's own internal line-break points to avoid a short final line,
   without changing font-size, letter-spacing, width, margin, or padding of
   anything. That makes it the safest possible fix under the client's own
   constraint (must not move any of the now-confirmed positions/gaps further
   down the hero) - any height change is a direct, intended consequence of
   fewer wrapped lines, not a side effect of touching a spacing value.
   Measured via canvas.measureText() with each element's own live computed
   font (not guessed): the eyebrow's target two-line split ("INNENAUSBAU |
   FASSADE (WDVS)" / "AUSSENPUTZ | MALERARBEITEN") measures ~257px / ~244px -
   comfortably under any real phone's content width, so this one is
   reliable on every device. The lead paragraph's target line 2 ("fuer
   Innenausbau, Fassade und Daemmung") measures ~390px at its 19px/900-weight
   font - within reach on wider phones (e.g. Pro Max class, ~390px content
   width) but tight-to-impossible on narrower ones (e.g. SE/mini class,
   ~335px) - `text-wrap:pretty` is still added (zero downside, browsers
   without support silently ignore it), but pulling "Daemmung" fully onto
   line 2 is not guaranteed on every phone; the property still rebalances
   toward the least-bad wrap available when it cannot. */
@media (max-width: 640px) {
	#brxe-idccdx,
	#brxe-vputtu > .brxe-text {
		text-wrap: pretty;
	}
}

/* `text-wrap:pretty` alone proved insufficient on a real device (client screenshot):
 * the eyebrow's heuristic only pulled the lone separator dot down, not the full word
 * "AUSSENPUTZ" - still an orphan, arguably a worse one (a bare "·" alone on line 2).
 * Forced deterministically instead: the eyebrow's Bricks content (#brxe-idccdx, a
 * Basic Text element - confirmed it passes inline HTML through) now wraps
 * " · Aussenputz · Malerarbeiten" in `<span class="pcg-mobile-break">`; this rule
 * makes that span `display:block` at mobile only, guaranteeing the break lands
 * exactly where the client asked, independent of any wrapping heuristic. At
 * desktop the span stays a plain inline element with zero visual effect - text-wrap:
 * pretty above is left in place as a harmless, general-purpose fallback. */
@media (max-width: 640px) {
	.pcg-mobile-break {
		display: block;
	}
	/* Client feedback after seeing the forced break live: the separator dot now
	 * leading the new mobile line ("· Aussenputz") reads as stray/pointless there -
	 * it was only ever meant as a mid-sentence separator, not a line-start glyph.
	 * `.pcg-mobile-break` now wraps that specific leading " · " in its own inner
	 * span (`.pcg-mobile-hide-dot`), added to the Bricks content alongside this
	 * task's other change, hidden on mobile only. Desktop's single-line rendering
	 * is untouched (both spans stay plain inline elements outside this query), so
	 * the dot still reads correctly as a mid-sentence separator there. The SECOND
	 * dot (between "Aussenputz" and "Malerarbeiten") is plain text, not wrapped -
	 * it stays visible on both breakpoints, as it should. */
	.pcg-mobile-hide-dot {
		display: none;
	}
}

/* --- Sub-block D: mobile hero button spacing -------------------------------
   Client's words: the buttons should wander down a bit and get more
   breathing room under the paragraph. #brxe-idmbte is the hero's own
   button-row container (already allowlisted), so this extra gap is
   hero-only - no other page's button row moves. These two rules stack to
   roughly 48px of separation where there were 24px before. l9b's
   `.brxe-button { margin-top: 0 }` cancellation inside the `:has()`
   container (further above in this file) is intentionally left alone - the
   gap is added on the ROW, not between the two buttons, so the buttons keep
   their clean `gap`-only spacing between each other. */

/* Quick task 260824-9ht: die drei Vertrauens-Zeilen im Hero
   ("28 JAHRE ERFAHRUNG IM BAU | STO-KLIMAPARTNER | BERLIN UND DEUTSCHLANDWEIT")
   wurden auf Kundenwunsch vom 2026-08-24 entfernt. Sie lagen hier als
   `#brxe-vputtu::after { content: "..." }`, also als CSS-erzeugter Text und
   nicht als echtes Bricks-Element - genau deshalb waren sie im Strukturbaum
   nicht auffindbar und nicht editierbar, was der Kunde zu Recht als Problem
   gemeldet hat. Ein Test haelt fest, dass hier kein `content:`-Text mehr
   zurueckkehrt: Fliesstext gehoert in ein echtes Element, das der Kunde sehen
   und aendern kann. */

/* ============================================================
   Quick Task 260824-t4m — `.pcg-trustline`: dieselbe Zeile, diesmal als
   ECHTES Element
   ============================================================
   Der Kunde will die drei Angaben zurueck, ausdruecklich "so dass er lesbar ist
   und nicht versteckt im Code". Genau deshalb liegt hier jetzt nur noch die
   GESTALTUNG — der Wortlaut selbst steht als drei normale Text-Elemente im
   Bricks-Strukturbaum und ist dort auffindbar und aenderbar.

   (1) DER TRENNSTRICH `|` DARF aus CSS kommen. Er ist Dekoration zwischen den
   Angaben, kein Inhalt: niemand will ihn suchen oder aendern, und auf dem Handy
   entfaellt er ersatzlos, weil die Angaben dort untereinander stehen. Genau
   diese Unterscheidung — Inhalt ins Element, Dekoration ins CSS — war beim
   alten `::after` verletzt.

   (2) DIE `!important`-FLAGS auf den Kindern sind unvermeidbar und deshalb hier
   begruendet: die Bricks-Globalklassen liefern Farbe und Groesse fuer
   `.brxe-text-basic`-Nachkommen mit `!important` aus. Ohne Gegenflag wuerden die
   drei Angaben in der Standard-Textfarbe auf dem Foto stehen. Der Container
   selbst kommt ohne `!important` aus.

   (3) VIER STELLSCHRAUBEN ueber Custom Properties, wie ueberall in dieser Datei
   mit Literal-Fallback und ohne `:root`-Standard, damit ein Kundenwert aus dem
   Bricks-Feld immer gewinnt:
     --pcg-trustline-top    Abstand nach oben   (Standard 48px, Handy 32px)
     --pcg-trustline-gap    Abstand zum Strich  (Standard 14px)
     --pcg-trustline-size   Schriftgroesse      (Standard 13px, Handy 11px)
     --pcg-trustline-color  Textfarbe           (Standard weiss 85%)
   ============================================================ */
.pcg-trustline {
	display: flex;
	flex-wrap: wrap;
	align-items: baseline;
	gap: 0 var(--pcg-trustline-gap, 14px);
	margin-top: var(--pcg-trustline-top, 48px);
	font-family: var(--pcg-font-sans);
	font-size: var(--pcg-trustline-size, 13px);
	font-weight: 600;
	letter-spacing: .16em;
	text-transform: uppercase;
	color: var(--pcg-trustline-color, rgba(255, 255, 255, 0.85));
}

/* Siehe Begruendung (2) oben fuer die Flags. */
.pcg-trustline > * {
	margin: 0 !important;
	font: inherit !important;
	letter-spacing: inherit !important;
	text-transform: inherit !important;
	color: inherit !important;
}

/* Siehe Begruendung (1) oben: Dekoration, kein Inhalt. */
.pcg-trustline > * + *::before {
	content: "|";
	margin-right: var(--pcg-trustline-gap, 14px);
	opacity: .45;
}

@media (max-width: 640px) {
	.pcg-trustline {
		flex-direction: column;
		gap: 4px 0;
		margin-top: var(--pcg-trustline-top-mobile, 32px);
		font-size: var(--pcg-trustline-size-mobile, 11px);
		line-height: 2.2;
		letter-spacing: .12em;
	}

	/* Untereinander stehende Angaben brauchen keinen Trennstrich. */
	.pcg-trustline > * + *::before {
		content: none;
	}
}


/* ============================================================
   Quick task 260813-a5m, Task 2 — Project-detail hero proportions
   (Cowork "Auftrag: Projekt-Detailseite" brief - PROP-02, PROP-03, D-03)
   ============================================================
   The brief asked for the project-hero's two columns to read ~46/54 (photo
   side wider than text), a 48px gutter, and the gallery inside the photo
   column to render 4:3 instead of the site-wide 16:9 default. The
   before/after slider's own smaller VORHER/NACHHER labels for this template
   (part of the same brief item, PROP-01) are scoped here too, alongside the
   two structural rules, because all three share the same #brxe-* template
   IDs and the same "one titled section" convention this file already uses.
   Positioned BEFORE the 260811-6od/260811-7l1 sections below (not appended
   at the true end of the file): both of those sections' own test scopes
   read from their marker onward (6od up to the 7l1 marker, 7l1 to
   end-of-file, no closing boundary of its own), so anything placed inside
   either span would silently become part of THAT section's asserted
   contract instead of this task's own.

   #brxe-pymefe = the project-hero's own two-column CSS Grid container
   (`display:grid`, confirmed live: text `#brxe-sdabpk` left, gallery
   `#brxe-otzrxm` right). No `.pcg-*` class exists on it - same situation as
   every other raw Bricks element already allowlisted in this file (e.g.
   `#brxe-wepjob` above).
   #brxe-otzrxm = that grid's own right/gallery column - the `.pcg-gallery`
   element (from `[pcg_project_gallery]`, placed manually) already sits
   inside it; no `.pcg-*` class exists on the COLUMN itself.
   #brxe-nkbljj = the before/after Shortcode element inside the Single-
   Projekte template (FACT-2) - a Bricks TEMPLATE element shared by every
   project page, the same reusable-template justification already recorded
   for `#brxe-wepjob`, not a per-page ID.

   Every #brxe-pymefe track below is written `minmax(0, …fr)`, never a bare
   `fr` value - see the `.pcg-2col` blow-out incident documented earlier in
   this file (260810-1ld, second round) for why: a bare fractional track's
   automatic minimum size resolves to its content's min-content size (here,
   a large image), not zero, so a bare `1fr`/`46fr`/`54fr` track can still
   render far wider than intended on a narrow viewport. `minmax(0, …)`
   removes that automatic floor.

   All three geometry declarations on #brxe-pymefe carry `!important`,
   matching every neighbouring override in this file, because the Bricks
   per-element grid settings they beat are themselves emitted with high
   specificity. The stacked (single-column) rule below is added
   unconditionally, not conditionally on a `.pcg-2col`-style class, because
   this element carries no such class and therefore inherits no existing
   stacking behaviour of its own to build on. */
@media (min-width: 1024px) {
	#brxe-pymefe {
		grid-template-columns: minmax(0, 46fr) minmax(0, 54fr) !important;
		align-items: center !important;
	}
}

@media (max-width: 1023px) {
	#brxe-pymefe {
		grid-template-columns: minmax(0, 1fr) !important;
		align-items: stretch !important;
	}
}

/* Gallery width (quick task 260816-u8o, superseding the 260813-a5m PROP-03
   proportion pin below). This hero gallery instance has NO
   `.pcg-gallery-section` ancestor - it is placed directly by the
   `[pcg_project_gallery]` shortcode inside the raw `#brxe-otzrxm` grid
   column, not inside the wrapper markup the "Weitere Referenzen" gallery
   uses - which is exactly why pcg-gallery.css's own two class-scoped
   `.pcg-gallery-section .pcg-gallery`/`.pcg-gallery-section
   .pcg-gallery-slider` max-width rules never reach it at all (confirmed
   live: computed max-width was `none`). The two rules below are an
   ID-scoped substitute for that missing class-scoped ancestor, reusing the
   already-allowlisted `#brxe-otzrxm` (see the ALLOWLISTED_IDS comment
   above) rather than introducing a 26th allowlist entry.

   Wrapper and box below must read the SAME expression, byte-for-byte - the
   arrows and counter are positioned against the `.pcg-gallery-slider`
   wrapper while the images live in the `.pcg-gallery` box, so if only one
   narrowed, the arrows would float outside the image the moment the
   client's own knob is used. A cross-file test pins both rules byte-
   identical to pcg-gallery.css's shipped pair, so nobody can "tidy" one
   side and silently drift the two galleries apart.

   `min(..., 100%)` is copied verbatim from the shipped rules for the same
   reason it exists there: it is what stops a fixed pixel knob value from
   overflowing a narrow phone, mirroring the hardening `.pcg-ba-wrap`
   already has in before-after.css.

   No `!important` on either rule: the property neither declares today
   (computed `none`, confirmed live), so there is nothing to out-shout, and
   an ID-scoped rule at (1,1,0) already outranks any class-level rule the
   client might author in the Bricks Custom CSS field - the same reasoning
   the removed proportion pin below used to record for this element.

   The gallery PROPORTION custom property (`--pcg-gallery-aspect-ratio`) is
   deliberately NOT set on this element any more (D-01). It sat ON the
   element at (1,1,0) specificity, which meant it beat the client's own
   `:root` value in the Bricks Custom-Code field regardless of print order -
   a loophole pcg-gallery.css's own "single override point" contract
   comment (top of that file) did not anticipate. Removing it lets this
   element fall through to the client's own value, with pcg-gallery.css's
   `var(--pcg-gallery-aspect-ratio, 16 / 9)` fallback as the only default,
   exactly as that contract requires. No new `:root` default is introduced
   here either, for the same print-order reason. */
#brxe-otzrxm .pcg-gallery-slider {
	max-width: min(var(--pcg-gallery-max-width, var(--content-width, 1200px)), 100%);
	margin-inline: auto;
}

#brxe-otzrxm .pcg-gallery {
	max-width: min(var(--pcg-gallery-max-width, var(--content-width, 1200px)), 100%);
	margin-inline: auto;
}

/* Slider labels (PROP-01, D-03). Smaller VORHER/NACHHER corner labels,
   scoped to this ONE template element - a global `.pcg-ba__label` shrink in
   before-after.css would also change the homepage slider, which this round
   is explicitly meant to leave alone (see before-after.css's own header and
   the regression-guard test asserting its global rule is unchanged). */
#brxe-nkbljj .pcg-ba__label {
	font-size: 13px !important;
}

/* ============================================================
   Quick task 260813-a5m, Task 3 — Image boxes: a real ratio on the hero
   image, a branded fallback for image-less reference cards (PROP-04)
   ============================================================
   Appended directly after Task 2's section above, and - like it - placed
   BEFORE the 260811-6od/260811-7l1 sections below for the same reason: both
   of those sections' own test scopes read from their marker onward with no
   closing boundary of their own.

   HERO / TWO-COLUMN IMAGE BOX (`.pcg-media img`). The one genuine proportion
   gap the brief names (discovered fact 10, design-exports/
   PCG_GlobalCSS_bereinigt.css line 53): the live rule already has
   `object-fit:cover` and `width:100%`, but its vertical size comes from a
   fixed 380px `min-height` rather than a declared ratio, so the box changes
   shape as the column narrows. Declared here with a 4/3 aspect-ratio, height
   released back to auto, and the minimum height zeroed - all `!important`,
   because the values being replaced are themselves declared in the Bricks
   field. Zeroing min-height is not optional polish: leaving the 380px floor
   in place would fight the ratio on narrow columns (the fixed floor wins
   whenever the ratio would compute shorter than 380px), which is exactly
   the "loses the ratio when it gets narrower" failure the brief is about. */
.pcg-media img {
	aspect-ratio: 4 / 3 !important;
	height: auto !important;
	min-height: 0 !important;
	object-fit: cover;
}

/* SUPERSEDED (260813-a5m Task 3): with .pcg-media img's own aspect-ratio and
 * zeroed min-height above, this phone-only min-height step below has no
 * remaining floor to shrink - the ratio alone now governs this box's height
 * at every width, including 520px and below. Left in place, not deleted, so
 * the supersession is visible in one read rather than only in a commit
 * message; if the aspect-ratio rule above is ever removed, this step
 * quietly starts mattering again exactly as it did before. */
@media (max-width: 520px) {
	.pcg-media img {
		min-height: 220px;
	}
}

/* REFERENCE CARDS WITH NO IMAGE (D-04). CSS-only, because the card markup
 * is rendered by a Bricks query loop that lives in the WordPress database,
 * not a template file in this repo - there is no PHP conditional this
 * plan can add a "no image" branch to. `:not(:has(img))` detects the
 * absence the same way this stylesheet already detects presence 15 times
 * elsewhere (see the .pcg-wrap:has(...) rules above).
 *
 * The placeholder was chosen over `display:none` (D-04) specifically
 * because hiding the card would silently remove a published project from
 * the /referenzen/ grid - a content-visibility regression traded for a
 * cosmetic one. FACT-7 makes this rule defensive, not a repair: all 13
 * cards on /referenzen/ and all 10 items in every "Weitere Referenzen" grid
 * currently HAVE images, so the correct observed result on today's data is
 * NO visible change anywhere - this only engages the day a project is
 * published without one.
 *
 * Two known limits of a CSS-only detection, recorded here rather than
 * silently assumed away: an `<img>` present with an empty or 404 `src`
 * still counts as "has an image" (the selector only sees markup, not a
 * network response); and a card that renders no media element at all
 * (neither `.pcg-card-media` nor a descendant `<img>`) is untouched by a
 * rule that only fires once `.pcg-card-media` itself is present. */
.pcg-card-media:not(:has(img)) {
	background-color: var(--color-navy, #142440);
	display: flex;
	align-items: center;
	justify-content: center;
}

/* Subtle wordmark, not a headline - low-opacity white so it reads as a
 * watermark. Text, not an image asset, so this rule ships nothing new to
 * deploy. Uses the same heading font stack already used elsewhere in this
 * file (`var(--pcg-font-heading)`, see the 5ob hero trust-line rule above)
 * for visual consistency with the rest of the design system. */
.pcg-card-media:not(:has(img))::after {
	content: "PCG";
	font-family: var(--pcg-font-heading);
	font-size: 32px;
	font-weight: 700;
	letter-spacing: .08em;
	color: rgba(255, 255, 255, 0.18);
}

/* ============================================================
   Quick task 260813-a5m, Task 4 — Section rhythm: the missing tablet tier
   (PROP-05, D-05, D-06), and the l9b task4 guard moved to allow it
   ============================================================
   Appended directly after Task 3's section above, still before the
   260811-6od/260811-7l1 sections below for the same reason stated in
   Tasks 2 and 3's own headers.

   THE RULE. `.pcg-section`'s base padding (88px) and its mobile override
   are owned ENTIRELY by the Bricks Custom CSS field (design-exports/
   PCG_GlobalCSS_bereinigt.css, read-only mirror) and are NOT touched here -
   see the l9b task4 C2c-09 comment block further above in this file, which
   this rule deliberately does not restate or contradict. This media query
   adds exactly one new tier: 64px top/bottom padding from 821px up to
   1023px. `!important` is required, not decorative: the value it beats
   (the Bricks field's own 88px base) is itself `!important`, so only later
   print order PLUS matching importance wins - the dependency guaranteeing
   that print order (pcg-responsive.css loads after the Bricks Custom CSS
   field) is documented in this file's own header comment.

   WHY 821px, NOT 641px. The brief's own middle-tier ask would naively
   split the desktop/mobile gap around 640px, but the live mobile override
   is keyed to `@media (max-width:820px)` (discovered fact 8, mirror line
   167), not 640px. A 641px floor would therefore not "sit between" the two
   existing tiers - it would overwrite the 641-820px band that today
   correctly renders the mobile value. An 821px floor changes exactly one
   band (821-1023px, today 88px, now 64px) and touches nothing else.

   WHY THIS DELIBERATELY RE-OPENS PART OF C2c-09. The client closed C2c-09
   on 2026-08-10 ("Nein, erstmal so lassen") - general vertical rhythm was
   to stay exactly as it is. This rule re-opens exactly one narrow slice of
   that closed scope (a single new breakpoint band, not the desktop base and
   not the mobile override) on the authority of the newer Cowork "Auftrag:
   Projekt-Detailseite" brief. See the C2c-09 comment block above (l9b task4
   section) for the original instruction - both instructions now live near
   each other in this file so a future reader finds them together instead of
   "fixing" one from the other. */
@media (min-width: 821px) and (max-width: 1023px) {
	.pcg-section {
		padding-top: 64px !important;
		padding-bottom: 64px !important;
	}
}

/* THE TWO DEFERRED ITEMS, documented here (and in the SUMMARY):
 * (a) the brief's mobile-value reduction to 48px (D-06) - RESOLVED 2026-08-13.
 *     Originally deliberately NOT done in this plan (lives in the Bricks
 *     Custom CSS field, not this theme file; restating it here would have
 *     added a second unqualified .pcg-section padding rule, against the
 *     client's own 2026-08-10 C2c-09 instruction above). Framed in the
 *     SUMMARY as one yes/no question for the client - the client then
 *     approved it live ("wenn es UI besser ist dan kannst du es
 *     verkleinern"), so it was implemented directly in the Bricks Custom
 *     CSS field (56px -> 48px, mirrored in design-exports/PCG_GlobalCSS_
 *     bereinigt.css) - see the updated C2c-09 comment block above. This
 *     theme file itself was NOT touched for that change; it still declares
 *     no .pcg-section padding beyond the --tight/--none modifiers and the
 *     single 821-1023px tablet tier, exactly as the a5m task4 tests assert.
 * (b) grid-gap unification (D-07) - only #brxe-pymefe's own gutter changes
 *     in this plan (Task 2, 56px to 48px), because that is the one the
 *     Cowork brief names and measures. #brxe-wepjob's gap and every other
 *     existing gap have their own documented history elsewhere in this
 *     file and stay untouched - the audit finding is written into the
 *     SUMMARY rather than acted on. */

/* ============================================================
   QUICK TASK 260811-6od — client round-2 feedback: sharper button corners
   + homepage mobile alignment fix
   ============================================================
   Round 2 of live client feedback on top of the already-deployed quick task
   260811-5ob. Two client-reported defects, addressed below, in the same
   fix-forward pattern this project already used for 260810-1ld/260810-l9b:
   fix in this child theme, test statically, hand back for one client look,
   deploy as a separate explicit step. Nothing in this section touches the
   live Bricks Custom CSS field - design-exports/PCG_GlobalCSS_bereinigt.css
   mirrors that field read-only and is intentionally left untouched; this
   file prints after it and wins every equal-specificity !important tie,
   same mechanism as every other override above. */

/* ------------------------------------------------------------
   TASK 1 — Sharpen every button corner site-wide, and compact the header
   CTA on small screens
   ------------------------------------------------------------
   Client's report: buttons look "soft / heavy / too rounded". Root cause,
   confirmed by reading the live Bricks Custom CSS mirror: every button
   variant carries an 8px (one carries 10px) border-radius - not a padding
   problem, not a letter-spacing problem (design-exports/
   PCG_GlobalCSS_bereinigt.css lines 40-43, 152, 263, 337).

   Chosen value: 3px, for all nine selectors below (the two guarded base
   selectors plus seven named variants). Rationale: 3px is a clearly visible
   sharpening from 8px; it deliberately is NOT iro-berlin.de's measured 2px
   (that reference was a calibration anchor, not a template to clone - a
   distinct value is honest as well as diplomatic); and it is not 0 either,
   so the buttons still read as finished rather than raw. It also sits
   directly beside the 2px this design system already uses in pcg-motion.css
   and the existing 4px focus-ring radius further above in this file
   (discovered fact 3) - 3px is squarely inside this design system's already
   established 2-4px vocabulary, not a foreign import.

   Each variant is restated at its own full selector shape rather than left
   to a bare `.brxe-button` alone, because five of the seven mirror
   declarations are marked !important at (0,2,0) specificity - only an
   equal-or-higher specificity, also !important, plus this file's later
   print order beats them. The `:not(.pcg-backlink)` guard on the two base
   selectors is load-bearing, not decorative: without it a bare
   `.brxe-button{border-radius:3px !important}` would flatten the
   deliberate project-detail "back to overview" pill
   (design-exports/PCG_GlobalCSS_bereinigt.css, .pcg-backlink,
   border-radius:999px) - the same guard shape pcg-typecase.css already uses
   for its own uppercase rule, mirrored here on purpose.

   Two selectors go beyond the client's enumerated variants, recorded here
   rather than left for a reviewer to wonder about:
     - `.wpcf7-form .wpcf7-submit` (the contact form's send button) - a
       first-class button on a main page, styled in the same Bricks field as
       a near-clone of the red CTA, and would otherwise be the one visibly
       rounder button left on the site.
     - `.bricks-button:not(.pcg-backlink)`, `.brxe-button:not(.pcg-backlink)`
       (the two base selectors) - so any Bricks button that carries no PCG
       variant class also lands on the shared value.

   Deliberate NON-change, recorded so it reads as a scope decision and not
   an oversight: the price calculator and AI visualizer keep their own
   radius token (`--pcg-radius-card`/`--pcg-radius-control`, defined in
   price-calculator.css) at its current value. Changing that token would
   also move every input, select and card inside both widgets - far past
   what the client asked for. The one-line follow-up, if it is ever wanted,
   is the token definition in price-calculator.css.

   CLIENT FEEDBACK 2026-08-11 (round 3, quick task 260811-7l1): the client
   live-tested this 3px value on the deployed site and reported it as too
   sharp - the opposite direction from round 1's original complaint, but a
   genuine live report, not a re-round. Value changed IN PLACE to 5px
   below, still one declaration for the whole nine-selector list:
     (a) 3px was live-tested and reported too sharp - this is not a
         hypothetical, the client saw the deployed change;
     (b) 5px is the deliberate middle ground between the original 8px and
         the rejected 3px, biased one step toward the sharper side because
         sharpening was the client's own round-2 ask - so a further nudge,
         if ever wanted, is a small step in a known direction rather than a
         reversal;
     (c) 5px deliberately still sits far below this site's other rounded
         elements (cards/boxes/steps 16px, CTA bands 20px, the warn box
         14px, discovered fact 3) - this is a design-system distinction
         (small interactive controls read as more precise when sharper
         than large content blocks), not an inconsistency;
     (d) known, deliberate remaining difference, left alone this round: the
         contact form's text inputs stay at the mirror's own 8px
         (design-exports/PCG_GlobalCSS_bereinigt.css line 145, `.wpcf7-form
         input...{border-radius:8px}`) - the one-line follow-up lever, if
         ever wanted, is that single mirror rule; not touched here because
         it was not part of what the client reported. */
.bricks-button:not(.pcg-backlink),
.brxe-button:not(.pcg-backlink),
.brxe-button.pcg-btn-navy,
.brxe-button.pcg-btn-red,
.pcg-btn-ghost,
.pcg-btn-outline,
.brxe-button.pcg-btn-ghost-dark,
.brxe-button.pcg-btn-header,
.wpcf7-form .wpcf7-submit {
	border-radius: 5px !important;
}

/* Header CTA ("Projekt schaetzen") compaction. After the shared radius
   lands, the header button is still the heaviest element in the header row
   at small widths, exactly as the client reported. This reduces ONLY its
   inner spacing - no colour, no typeface, no text size, no weight and no
   letter-spacing (letter-spacing on buttons is owned by pcg-typecase.css,
   which prints after this file and would win anyway). Restates the
   mirror's own (0,2,0) selector shape with !important, going from the
   mirror's 9px/20px to 7px/14px.

   Re-verified before writing this rule (per the discovered_facts
   instruction to re-confirm anything depended on): the plan referenced an
   existing 44px minimum-tap-target rule further above in this file as a
   floor not to cross. That rule (`.pcg-section .brxe-button, .wpcf7-form
   .wpcf7-submit { min-height: 44px !important }`, inside
   `@media (max-width: 640px)`) is scoped to `.pcg-section .brxe-button` -
   the header CTA sits inside `.pcg-header`, not any `.pcg-section`, so that
   guard does NOT actually reach this button, before or after this change.
   The header CTA's un-padded content height (14px font-size, 1.2
   line-height, ~16.8px) plus 2x9px padding was already ~34.8px - already
   below the 44px AAA target before this task, unrelated to this change.
   This padding delta does not introduce a new gap that did not already
   exist, and stays inside the plan's directed 7-9px/14-20px neighbourhood.
   A dedicated 44px accessibility floor for this one header button is a
   separate, pre-existing, out-of-scope item - logged in this quick task's
   deferred-items.md rather than fixed here (Scope Boundary: only auto-fix
   what this task's own change caused).

   Band this affects: 520-1023px only, because below 520px the button is
   already hidden entirely (discovered fact 4, `.pcg-header >
   *:nth-child(3){ display:none }` inside `@media (max-width: 519px)`) -
   the client cannot have seen an oversized button on a phone narrower than
   that; Task 3's checkpoint asks which device/width they actually saw it
   on. */
@media (max-width: 1023px) {
	.brxe-button.pcg-btn-header {
		padding: 7px 14px !important;
	}
}

/* ------------------------------------------------------------
   TASK 2 — Homepage mobile alignment audit, then the root-cause fix for
   "Ausgewaehlte Projekte" vs. its "Referenzen" eyebrow
   ------------------------------------------------------------
   METHOD: enumerate every declaration of `align-self` and `text-align` in
   both this file and the Bricks Custom CSS mirror
   (design-exports/PCG_GlobalCSS_bereinigt.css), and classify each one by
   the media scope it sits in - inside a min-width block means
   desktop-intent, inside a max-width block means mobile-intent, outside any
   block means it fires at every width. The failure mode hunted for is a
   desktop-intent alignment rule written with NO media query, because that
   is precisely the class of bug the client reported: it leaks onto mobile
   and disagrees with a sibling element that correctly has no mobile
   override.

   WALKED: every `align-self`/`text-align` declaration in pcg-responsive.css
   (this file) and in design-exports/PCG_GlobalCSS_bereinigt.css, grouped by
   the homepage `.pcg-section` each one belongs to (eyebrow / heading / lead
   paragraph groups), checking whether each group's members agree at mobile
   widths.

   FINDING SET (re-derived this session, not merely trusted from planning):
     - GENUINE HIT: `#brxe-lifzpw` ("Ausgewaehlte Projekte" heading, round-6
       fix from quick task 260810-l9b) declared `align-self:flex-start
       !important` with NO media query around it, further above in this
       file. That rule was always desktop-intent - part of the same
       `min-width:1024px` "section heads sit left" decision every other
       rule expressing that intent already lives inside (see the FIX 1
       audit block, and the mirror's own `@media (min-width:1024px)` block,
       design-exports/PCG_GlobalCSS_bereinigt.css lines 419-431) - but it
       was written unscoped, so it also fired on mobile. Its sibling, the
       "Referenzen" eyebrow, carries NO alignment override outside that same
       `min-width:1024px` mirror block (`.pcg-section .pcg-eyebrow{
       align-self:flex-start }` only exists there) - on mobile the eyebrow
       is centred purely by the parent `.brxe-block`'s own
       `display:flex;flex-direction:column;align-items:center` default.
       Heading dragged left + eyebrow centred = exactly what the client
       reported.
     - HISTORICAL NOTE (quick task 260824-9ht): this bullet used to record a
       deliberate non-hit for the hero trust line's `#brxe-vputtu::after`
       pseudo-element and its unscoped `align-self:flex-start !important`.
       That pseudo-element was deleted on 2026-08-24 at the client's request,
       so the non-hit no longer exists. The reasoning is kept only so a future
       reader does not go looking for a rule that is gone.
     - No other group across the homepage's `.pcg-section` elements
       disagrees at mobile widths - the re-derived finding set matches
       exactly what planning predicted (one genuine hit, one deliberate
       non-hit). Nothing beyond the client's flagged pair is touched.

   FIX (root cause, not a patch stacked on top of a still-broken rule): the
   round-6 rule further above in this file is now scoped inside
   `@media (min-width: 1024px)` (see that rule's own comment for the exact
   change) - matching the width band the "section heads sit left" decision
   was always meant for. The block below states the resulting mobile intent
   EXPLICITLY rather than leaving it implicit: with the leak already
   removed by the scoping fix, this block is a no-op on a fresh page load -
   it exists so a future reader sees the mobile-centred intent stated, not
   merely inferred from an absence, and so the structural test further below
   (proving no #brxe-lifzpw alignment declaration is ever left unscoped) has
   something concrete to check on the mobile side too.

   The `align-self` declaration merely restates the parent `.brxe-block`'s
   own centring default, so a future per-element edit in Bricks cannot
   silently un-centre the heading. The `text-align` declaration is the
   load-bearing one: once the heading wraps to two lines on a narrow phone,
   its shrink-to-fit box fills the whole block width, `align-self` has no
   slack left to act on, and without `text-align` the second line would
   still read left-ragged beside a centred eyebrow.

   This pair now matches the "Unsere Leistungen" / "Spezialisiert auf vier
   Gewerke" section on the same page, which is centred on mobile for the
   same structural reason (every alignment rule touching those two IDs is
   inside a `min-width:1024px` block; their own mobile blocks set width/
   padding only, never alignment). The tie-break came from the client's own
   stated rule: lean centred at the flagged spots.

   EYEBROW CONFIRMATION (Step 4): grepped this file and the mirror for any
   rule setting alignment or text-alignment on `.pcg-eyebrow` outside a
   `min-width:1024px` block - none found. This is exactly why the eyebrow
   is already centred on mobile, and exactly why the fix is to remove/scope
   the heading's own override rather than add a second rule to the eyebrow -
   agreement is achieved by removing an override, not by adding two.

   /leistungen/ IS NOT TOUCHED. It is consistently left-aligned on mobile
   today and the client confirmed that is fine. This task introduces no
   site-wide alignment rule and no new element ID at all beyond the single
   already-allowlisted `#brxe-lifzpw` - the negative guards in the test file
   (ID-allowlist count staying at 22, and a scan proving no shared
   design-system selector in this section carries an alignment declaration)
   prove that mechanically, not merely by intent. */
@media (max-width: 1023px) {
	#brxe-lifzpw {
		align-self: center !important;
		text-align: center !important;
	}
}

/* ============================================================
   QUICK TASK 260811-7l1 — client round-3 feedback: button padding on the
   six main variants, plus the remaining l9b mobile-centering gap
   ============================================================
   Round 3 of live client feedback, on the same deployed change that
   produced rounds 1 (260811-5ob) and 2 (260811-6od). Two concrete
   client-reported items, addressed below, in the same fix-forward pattern
   this project already used for 260810-1ld/260810-l9b/260811-6od: fix in
   this child theme, test statically, hand back for one client look,
   deploy as a separate explicit step. Nothing in this section touches the
   live Bricks Custom CSS field - design-exports/PCG_GlobalCSS_bereinigt.css
   mirrors that field read-only and is intentionally left untouched; this
   file prints after it and wins every equal-specificity !important tie,
   same mechanism as every other override above.

   The shared button radius value itself (3px -> 5px) is changed IN PLACE
   inside the "QUICK TASK 260811-6od" section above, not restated here -
   editing it in a second, later rule with the same selector list would
   make the live value and the value that section's own test reads
   diverge. See that rule's own dated comment for the full round-3
   rationale. */

/* ------------------------------------------------------------
   TASK 1 — Reduce inner padding on the six main button variants
   ------------------------------------------------------------
   Client's own diagnosis (confirmed correct by re-reading the mirror one
   declaration at a time this session): the "heavy" look was driven by
   padding as well as the corner radius round 2 already sharpened. Round 2
   never touched padding at all - every variant still carries the Bricks
   Custom CSS mirror's original inner spacing (design-exports/
   PCG_GlobalCSS_bereinigt.css lines 40-43, 152, 263).

   TWO groups below, not one flat value, because the mirror's six paddings
   are NOT identical: navy/red/ghost/ghost-dark/the form submit button all
   sit at 14px 30px (32px horizontal for the form submit specifically),
   while `.pcg-btn-outline` is already the narrowest at 14px 22px - a
   deliberate secondary-button hierarchy. A single flat replacement value
   would have INCREASED the outline button's padding, the opposite of this
   round's goal, so it gets its own, proportionally smaller, target value
   instead.

   `.brxe-button.pcg-btn-header` is deliberately absent from both groups -
   round 2 already compacted it to 7px/14px inside its own
   `max-width:1023px` block further above in this file; this round does
   not touch it again.

   TAP-TARGET ARITHMETIC, recorded here rather than only asserted:
   buttons render at 15px font-size (mirror line 28; 14px at the smallest
   breakpoint, line 376), so the un-padded content height is roughly 18px.

   quick task 260819-0fc, Task 2 (2026-08-19): client feedback that buttons
   still read too heavy top/bottom - reduced further, 12px -> 10px vertical,
   edited IN PLACE here (not a second, later-printing rule) per this
   section's own established convention. With the new 10px top + 10px
   bottom this puts the box at roughly 38px on desktop/tablet (10+10+18).
   38px still clears the WCAG 2.2 AA minimum target size. On phones the
   pre-existing `min-height: 44px !important` rule further above in this
   file, inside `@media (max-width: 640px)`, still fixes the floor at 44px
   regardless - a `min-height` floor cannot be lowered by a `padding`
   change, and the 44px figure this project treats as its floor is a
   mobile-specific guideline that rule continues to enforce. The rules
   below still deliberately declare padding only, never `min-height` or
   `height`, so that floor stays untouched by this round.

   Scope decision, recorded explicitly: no colour, background, typeface,
   text size, weight or letter-spacing is changed anywhere in this
   section (letter-spacing on buttons is owned by pcg-typecase.css, which
   prints after this file and would win regardless).

   Same-day follow-up (2026-08-19, live feedback after the 12->10px round
   above): client compared directly against iro-berlin.de's own hero
   buttons and asked for "schmaler, eleganter, nicht so fett" while
   explicitly keeping this file's existing 5px border-radius (260811-7l1)
   unchanged - measured live, IRO's own horizontal padding is actually
   28px (wider than ours), so the requested "narrower" read is a real
   client preference for THIS site, not a literal IRO-matching value.
   Horizontal padding reduced 24px -> 20px (five-selector group) and
   18px -> 16px (.pcg-btn-outline), vertical and radius untouched. */
.brxe-button.pcg-btn-navy,
.brxe-button.pcg-btn-red,
.pcg-btn-ghost,
.brxe-button.pcg-btn-ghost-dark,
.wpcf7-form .wpcf7-submit {
	padding: 10px 20px !important;
}
.pcg-btn-outline {
	padding: 10px 16px !important;
}

/* ------------------------------------------------------------
   TASK 2 — Extend the mobile-centering fix to the four remaining l9b
   siblings
   ------------------------------------------------------------
   Round 2 (260811-6od) fixed exactly one heading, `#brxe-lifzpw`, with an
   explicit `@media (max-width: 1023px)` centering block (see that rule
   directly above this section). The client confirmed live today, on a
   real narrow phone, that "Spezialisiert auf vier Gewerke" (`#brxe-bvrrgu`)
   is STILL broken - it wraps to two lines on a real phone and reads
   left-ragged.

   WHY round 2 missed this: `#brxe-lifzpw` was the only ID given an
   explicit mobile block. Its four l9b-group siblings (`#brxe-jdafeg`,
   `#brxe-ktbmez`, `#brxe-knqazm`, `#brxe-bvrrgu`) were left implicit. The
   l9b `max-width:1023px` block further above that already names all five
   of them (see the FIX 1 audit block) sets width/box-sizing/padding only
   and declares no alignment at all - that absence is the bug, and it is
   invisible until the heading's text actually wraps.

   WHY the bug only shows on a real phone: at the ~614px browser viewport
   available for testing this session the heading's ~477px content still
   fit on ONE line, so its shrink-to-fit box was narrower than the block
   and the parent `.brxe-block`'s own `align-items:center` default still
   centred it. On a real ~375-428px phone the heading wraps to two lines,
   its box fills the whole block width, `align-self` has no slack left to
   act on, and without `text-align` the second line reads left-ragged
   beside a centred eyebrow. This is the exact same mechanism the round-2
   comment above already recorded for `#brxe-lifzpw` - see that comment
   for the full mechanics, not restated twice here.

   WHY all four and not only the reported one: the client confirmed
   `#brxe-bvrrgu` specifically, but all four siblings share the identical
   structure and the identical missing rule, so cherry-picking would leave
   three latent copies of the same bug for a round 4.

   WHY `#brxe-dvdrnf` is deliberately excluded: it is the Vorher/Nachher
   section's lead paragraph ("Ziehen Sie den Regler..."), not a heading or
   eyebrow; its left/start alignment is original design and was never
   reported. Named here explicitly so a future reader sees an omission
   that was decided, not overlooked - naming it in a comment is safe, the
   negative assertions in the test file run against comment-stripped CSS.

   No new element ID enters the codebase: all four IDs below are already
   present in ALLOWLISTED_IDS from rounds l9b and earlier, so that guard's
   count stays at 22. */
@media (max-width: 1023px) {
	#brxe-jdafeg,
	#brxe-ktbmez,
	#brxe-knqazm,
	#brxe-bvrrgu {
		align-self: center !important;
		text-align: center !important;
	}
}

/* ============================================================
   Quick task 260813-nuh — .pcg-thumb: the [pcg_project_thumb]
   shortcode's CSS follow-up, closing 260813-ldo's D-09 open item
   ============================================================
   Appended directly after the l9b round-2 audit block above, for the
   same "append at the end, never edit an existing rule" reason stated
   throughout this file's earlier sections.

   WHY .pcg-thumb IS A BARE SINGLE-CLASS SELECTOR, NOT A DESCENDANT FORM.
   The live card template's crop comes from `.pcg-card-media{ aspect-
   ratio:4/3; overflow:hidden; }` (design-exports/PCG_GlobalCSS_bereinigt.css
   line 201) applying DIRECTLY to the `<img>` — on the `/referenzen/` query
   loop, `.pcg-card-media` is a class on the image element itself, not on a
   wrapper (discovered fact 1). Its companion descendant rule
   `.pcg-card-media img{...}` (same file, line 202) exists for a different,
   wrapper-shaped card variant and never fires here. `[pcg_project_thumb]`'s
   `<img class="pcg-thumb">` is emitted the same way — bare, no wrapper of
   its own (`inc/project-thumb.php` pcg_project_thumb_markup()) — so a
   selector modelled on `.pcg-card-media img` would never match what this
   shortcode actually produces. `.pcg-thumb` therefore has to be
   self-sufficient on the image element itself.

   WHY THE FIT IS DECLARED HERE AT ALL. The live Image element's crop
   behaviour ("fill", per 260813-ldo's SUMMARY) is an element-level Bricks
   setting a Shortcode element has no equivalent of — there is nothing for
   a Shortcode-rendered `<img>` to inherit an object-fit from, so this rule
   has to state the fit itself. `cover` matches the design intent recorded
   in three independent places: the mirror's own line 202, CONVENTIONS.md's
   fixed-aspect-ratio guidance, and the original Finale-Politur brief.

   WHY height:auto, NOT height:100%. The shortcode's `<img>` sits directly
   in whatever wraps it (a Bricks Shortcode element's own div, once the
   Option B swap happens) — there is no fixed-height ancestor for a
   percentage to resolve against. Declaring `auto` makes `aspect-ratio` the
   single source of the box's shape, and stops `wp_get_attachment_image()`'s
   own emitted `width`/`height` HTML attributes from fighting the CSS box.

   WHY overflow:hidden is deliberately NOT copied from `.pcg-card-media`.
   On a replaced element (an `<img>` itself, not a wrapper), `object-fit`
   already does the clipping on its own — the mirror only needs `overflow`
   because that class can also land on a wrapper element. Recorded so a
   future reader sees an omission that was decided, not overlooked.

   NO !important ANYWHERE IN THIS RULE. It only has to outrank the
   single-descendant `.pcg-section img` safety net further above in this
   file, which it already does on specificity alone (0,1,0 vs 0,1,1) —
   adding `!important` here would be noise, not a requirement.

   Below this rule, two card-context parity rules make Option B (the
   Bricks Shortcode-element swap) render identically to today's Image
   element, not merely give the image itself the right crop. A Bricks
   Shortcode element wraps its output in its own div, so once the swap
   happens `.pcg-thumb` becomes a GRANDCHILD of `.pcg-card`, not a direct
   child like the Image element is today. Two rules in the live Bricks
   Custom CSS field react to that shape change:
     1. `.pcg-card > *:not(.pcg-card-media):not(.pcg-card-link){
        padding-left:22px; padding-right:22px; }` (mirror line 205) starts
        applying to the shortcode's own wrapper div — the Image element is
        excluded by name, the shortcode wrapper is not. Without a fix the
        thumbnail would sit inset 22px on each side instead of edge-to-edge.
     2. `.pcg-card-media + *{ margin-top:16px; }` (mirror line 206) stops
        applying — the element immediately before the trades line is now
        the shortcode wrapper, not `.pcg-card-media`. Without a fix the
        trades line would lose its 16px top gap.
   Both rules below are keyed on `:has(> .pcg-thumb)`, so — like the rule
   above — neither can match anything on today's live site: no element
   anywhere carries the `.pcg-thumb` class yet (zero CSS references it,
   zero rendered markup carries it), so this entire section is inert until
   someone performs the Option B swap in the Bricks editor by hand.

   The two rules get different treatment ON PURPOSE, not by oversight:
   `.pcg-card > *:not(.pcg-card-media):not(.pcg-card-link)` scores 0,3,0.
   `.pcg-card > *:has(> .pcg-thumb)` scores only 0,2,0 (`:has()` takes its
   most specific argument, not the whole compound), so on its own it LOSES
   to the field's padding rule and needs `!important` to win — the same
   idiom this stylesheet already uses throughout to beat the Bricks Custom
   CSS field. The margin-gap rule is the opposite case: `.pcg-card-media +
   *` simply does not match this shape at all once the swap happens, so
   there is nothing to outrank — plain cascade is enough and `!important`
   here would be unjustified noise.

   TWO DECIDED OMISSIONS, recorded so neither is "rediscovered" as a bug in
   a future session:
     - D-05: the live `.pcg-card:hover .pcg-card-media img{
       transform:scale(1.03) }` hover-zoom (mirror line 213) is a
       descendant selector and, for the same reason as the crop rule
       above, cannot match `/referenzen/`'s card template either — so the
       Image element does not visibly zoom on hover there today, and
       giving `.pcg-thumb` a hover zoom would make Option B differ from
       Option A rather than match it. Not ported here.
     - D-06: 260813-a5m's `.pcg-card-media:not(:has(img))` navy fallback
       for an image-less card is keyed on a class the shortcode path never
       carries, and an empty shortcode wrapper cannot be detected with the
       same `:has(> .pcg-thumb)` idiom (there is no `.pcg-thumb` to match
       on when the resolver returns nothing). Accepted as a known,
       documented limitation — the resolver's own three-link fallback
       chain plus a5m's finding that every live card currently has an
       image make a blank card a theoretical case today. */
.pcg-thumb {
	display: block;
	width: 100%;
	height: auto;
	aspect-ratio: 4 / 3;
	object-fit: cover;
}

.pcg-card > *:has(> .pcg-thumb) {
	padding-left: 0 !important;
	padding-right: 0 !important;
}

.pcg-card > *:has(> .pcg-thumb) + * {
	margin-top: 16px;
}

/* ============================================================
   Debug session `homepage-card-image-mismatch` (2026-08-18) —
   HOMEPAGE TEASER parity for .pcg-thumb
   ============================================================
   Appended at the end of the file, same "append, never edit an existing rule"
   convention as every section above.

   WHAT THIS UNBLOCKS. The homepage "Ausgewählte Projekte" teaser
   (`#brxe-ilmufm.pcg-cardgrid.pcg-cardgrid--2`) still renders its card image as
   a native Bricks Image element bound to a fixed ACF field, so it does not
   follow the client's gallery re-ordering the way `/referenzen/` now does.
   The fix is the same Image → `[pcg_project_thumb]` Shortcode swap that
   `/referenzen/` already received (quick task 260813-ldo). This section is the
   CSS that has to be LIVE BEFORE that swap happens.

   WHY 260813-nuh's RULES ARE NOT ENOUGH HERE. nuh modelled `.pcg-thumb` on the
   `/referenzen/` card, where the media frame is a 4:3 box. The homepage teaser
   is a deliberately different design, and TWO of the rules that make it
   different are keyed on the class `.pcg-card-media` — a class that exists on
   the page only because the Bricks Image element carries it. Delete that
   element and both rules stop matching, silently:

     1. `.pcg-cardgrid--2 .pcg-card-media{ aspect-ratio:auto !important;
        height:220px !important; }` (Bricks Custom CSS field; mirrored at
        design-exports/PCG_GlobalCSS_bereinigt.css line 222) is the teaser's
        "flacheres Bild = kompaktere Karten" band. Without a twin, `.pcg-thumb`'s
        own 4:3 box takes over and every teaser card grows noticeably taller
        below 1000px. → TWINNED BELOW (rules 1 and 2).
     2. `.pcg-card > .pcg-card-media + .brxe-text-basic{ margin:16px 0 0;
        font-size:11px; font-weight:700; letter-spacing:.09em;
        text-transform:uppercase; color:#EE0000; }` (same field, mirror line
        351) is the red, small-caps trades line ("WDVS"). It is an ADJACENCY
        selector: once the first child is a Shortcode wrapper instead of
        `.pcg-card-media`, it stops matching and the trades line falls back to
        the generic `.pcg-card > .brxe-text-basic` body style (13.5px, muted
        grey, 8px gap). That is exactly what already happened on `/referenzen/`
        when it was swapped, and it is the "WDVS tag is grey on one page and red
        on the other" difference the client reported.
        → DELIBERATELY **NOT** TWINNED. See the next paragraph.

   THE TRADES LINE IS INTENTIONALLY LEFT TO FALL THROUGH (client decision,
   2026-08-18). Asked whether the tag inside the card tile should be red, the
   client answered "In der Kachel selber? Nein dort nicht rot" — grey on BOTH
   pages, i.e. `/referenzen/`'s current look is the target, not the exception.
   The red rule's loss is therefore the DESIRED outcome rather than collateral
   damage, and the correct implementation is to ship nothing at all for it: the
   `.pcg-card-media` key disappears with the Image element, the adjacency rule
   stops matching on its own, and the homepage lands on
   `.pcg-card > .brxe-text-basic:not(.pcg-card-link){ font-size:13.5px;
   color:rgba(20,36,64,0.6); margin:8px 0 0 !important }` — byte-identical to
   what `/referenzen/` renders today.

   An earlier revision of this section shipped a third rule that reproduced the
   red on `.pcg-thumb`; it was written before the client answered and has been
   removed. Its 16px gap went with it ON PURPOSE: that spacing was tuned for an
   11px uppercase eyebrow, and keeping it alone would have left the homepage at
   16px while `/referenzen/` sits at 8px — a brand-new divergence in the very
   direction this decision was meant to close. "Grey, same as /referenzen/"
   means the whole declaration block goes, not just the colour. Negative
   guards in tests/pcg-responsive-css.test.cjs (homepage-thumb-parity tests 4
   and 5) now fail if any rule here re-keys the trades line or re-declares
   `#EE0000`. `/referenzen/`'s own CSS is untouched — it needs no change.

   ONE DELIBERATE, VISIBLE IMPROVEMENT — NOT A SILENT ONE. Below 1000px the
   current Image element gets `height:220px` with NO `object-fit` (the
   companion `.pcg-card-media img{ object-fit:cover }` rule is a DESCENDANT
   selector and never matches, because `.pcg-card-media` sits on the `<img>`
   itself here). A ~4:3 source photo squeezed into a ~416×220 box is therefore
   visibly squashed on tablet today. `.pcg-thumb` carries `object-fit:cover`,
   so after the swap those images CROP instead of STRETCH — the behaviour the
   global CSS always intended. This is the one place the swap is not
   pixel-identical. If the client prefers the old squashed look, adding
   `object-fit:fill` to the first rule below restores it exactly.

   SCOPE. Every selector here is prefixed with `.pcg-cardgrid--2` or
   `#brxe-ilmufm`. `/referenzen/`'s grid is `.pcg-cardgrid` WITHOUT the `--2`
   modifier — the live CSS itself relies on that distinction
   (`.pcg-cardgrid:not(.pcg-cardgrid--2)`, mirror line 344) — so nothing here
   can reach `/referenzen/`'s already-correct cards, the Gewerke filter bar, or
   the project-detail gallery/slider. A test enforces this per selector.

   !important DISCIPLINE, PER RULE (same reasoning style as the nuh block
   above, not a blanket habit): both rules below carry NONE. They only have to
   outrank the bare `.pcg-thumb` rule above (0,1,0) in this same file; at 0,2,0
   and 1,1,0 they already win on specificity, and nothing in the Bricks Custom
   CSS field targets `.pcg-thumb` at all. No rule in this section needs
   `!important` any more — the one that did was the trades-line twin, now
   removed.

   FOOTNOTE ON nuh's SIBLING-GAP RULE ABOVE. `.pcg-card > *:has(> .pcg-thumb)
   + *{ margin-top:16px }` carries no `!important` (0,2,0), so it loses to
   `.pcg-card > .brxe-text-basic:not(.pcg-card-link){ margin:8px 0 0
   !important }` (0,3,0, mirror line 349 and this file's own ~line 489) and
   never takes effect. Left in place untouched (append-only, and it is
   harmless) — and its being a no-op is now load-bearing in the good direction:
   it is precisely why the homepage inherits `/referenzen/`'s 8px gap rather
   than a homepage-only 16px one. The identical 16px-vs-8px discrepancy exists
   on `/referenzen/` today and is deliberately NOT fixed here — that page is
   out of scope for this session. Recorded so it is found, not rediscovered. */

/* 1. Teaser band height — twin of `.pcg-cardgrid--2 .pcg-card-media`. */
.pcg-cardgrid--2 .pcg-thumb {
	aspect-ratio: auto;
	height: 220px;
}

@media (min-width: 1000px) {
	/* 2. Desktop 4/3 frame — twin of `#brxe-ilmufm .pcg-card-media` (~line 921
	   of this file), which already overrides the 220px band once the teaser
	   cards are the same width as the /referenzen/ ones. Same ID, same
	   breakpoint, same values: one mechanism, mirrored, not a second one. */
	#brxe-ilmufm .pcg-thumb {
		aspect-ratio: 4 / 3;
		height: auto;
	}
}

/* NO RULE 3. The trades line ("WDVS") is deliberately not twinned — see the
   client-decision paragraph in the banner above. Adding one back would
   re-introduce the red the client explicitly rejected. */

/* ============================================================
   QUICK TASK 260819-0fc — Task 3: golden-ratio desktop type scale
   (client points 2 "hero + allgemeine Textgroesse" and 4 "goldener
   Schnitt" combined, per this round's own CONTEXT.md - one coordinated
   typography-scale change rather than two independent passes)
   ============================================================

   IMPORTANT FINDING, recorded before anything else: the hero heading
   (`.pcg-hero-title, #brxe-vputtu > h3`) ALREADY renders at 74px on
   desktop - it was raised there by an earlier, independent round (quick
   task 260811-ldk, "IRO scale via var(--pcg-hero-*)", see the
   min-width:1024px block further above in this file, and the "ldk:"
   test in the touched test file). 74 / 46 (this file's own .pcg-h1
   anchor) = 1.609, already inside 1.60-1.63 of true phi (1.618), and
   already inside the client's stated 72-76px band for this round. So
   point 2's hero half and point 4's golden-ratio half were, without
   either task intending it, already satisfied by a prior round before
   this session started - this section does NOT re-touch the hero (doing
   so would create a second, later-printing #brxe-vputtu > h3 rule and
   risk the exact "diverges from what its own test reads" bug this
   file's other sections explicitly guard against). What remains, and is
   what this section actually does, is deriving the REST of the desktop
   type-scale ladder from the same phi ratio, anchored on `.pcg-h1`
   (46px, itself left unchanged - it is the anchor everything else is
   measured from, both here and for the hero).

   Every value below is a real read of the mirror
   (design-exports/PCG_GlobalCSS_bereinigt.css) at the time this task
   ran (verified live against main via `git log`, not the quick task's
   own now-stale planning snapshot - see this round's SUMMARY for why
   that distinction mattered this time).

   | tier                        | now (desktop) | new (desktop) | ratio to the tier below |
   |------------------------------|---------------|----------------|--------------------------|
   | hero #brxe-vputtu > h3       | 74 (unchanged, already shipped by 260811-ldk) | 74 / 46 = 1.609 approx phi |
   | .pcg-hero-h1, .pcg-h1         | 46 (unchanged, the anchor)     | 46 / 36 = 1.278 approx sqrt(phi) |
   | .pcg-h2                      | 34             | 36             | 36 / 22 = 1.636 approx phi |
   | .pcg-subhead                 | 20             | 22             | 22 / 14 = 1.571 approx phi |
   | .pcg-lead                    | 19             | 20             | off-ladder, see below |
   | .pcg-body                    | 17             | 18             | off-ladder, see below |
   | .pcg-eyebrow                 | 13             | 14             | bottom of the ladder |

   Ladder mean ratio ~1.61-1.64 against phi = 1.618. `.pcg-lead` and
   `.pcg-body` sit deliberately OFF the ladder, between eyebrow and
   subhead: a genuine phi step below 22px subhead would put body copy at
   roughly 13.6px, which is unreadable - this is an honest, documented
   deviation, not an oversight, so a future reader does not "correct"
   it back onto the ladder.

   SCOPE: desktop only (min-width:1024px), same reasoning 260811-ldk
   already used for the hero - the existing tablet scale already
   approximates phi almost exactly (38/30 = 1.267, 30/19 = 1.579,
   19/12 = 1.583, per the mirror's own max-width:1023px tier), and the
   phone scale is deliberately compressed for readability. Both are left
   completely alone; this file's own convention (F1 in this round's
   PLAN.md) is to override the mirror only where genuinely needed.

   Only font-size is declared below - weight, line-height, letter-
   spacing and colour stay owned by the mirror, exactly as the mirror
   already declares them for every tier. No section-to-section spacing,
   no button width:height ratio, no `.brxe-button` font-size is touched
   here - out of scope per this round's CONTEXT.md. */
@media (min-width: 1024px) {
	.pcg-h2 {
		font-size: 36px !important;
	}
	.pcg-subhead {
		font-size: 22px !important;
	}
	.pcg-lead {
		font-size: 20px !important;
	}
	.pcg-body {
		font-size: 18px !important;
	}
	.pcg-eyebrow {
		font-size: 14px !important;
	}
}

/* ============================================================
   QUICK TASK 260819-p44, Task 2 — homepage "Vorher/Nachher" 2-column desktop
   grid, stacked below ~1024px
   ============================================================
   Implements AUFGABE points 2 and 3 of design-exports/AUFTRAG_Claude_Code_Startseite_
   VorherNachher_2Spalten.md using ONLY the four elements already present as direct
   children of #brxe-lotjmo (its own section, plus #brxe-jdafeg/#brxe-ktbmez/
   #brxe-dvdrnf/#brxe-fiprbw, all already allowlisted above) - no Bricks element is
   moved or wrapped, matching the AUFTRAG's explicit "Kein Bricks-Umbau" constraint.
   `grid-row: 1 / span 3` on #brxe-fiprbw is what lets a single grid item occupy the
   same vertical space as three separate sibling grid items in the other column,
   purely via CSS placement.

   Critical constraint: do NOT place max-width/margin-left/margin-right directly on
   #brxe-lotjmo itself - that element's own inline Bricks style also carries its
   background-color:var(--color-navy), so capping its box width would shrink the navy
   background and leave white gaps beside the section on wide viewports. The desktop
   content inset is expressed as padding-left/padding-right:
   max(24px, calc((100% - 1200px) / 2)) instead - padding is painted WITH the
   background (stays full-bleed) while still insetting the grid's content flow to an
   effective ~1200px column, the same visual result .pcg-wrap gives every other
   section via a wrapper element this section does not have.

   The three text elements' descendant selector (#brxe-lotjmo #brxe-jdafeg, etc.) has
   higher specificity (0,2,0) than FIX 1's bare single-ID selector above (0,1,0), so
   this rule overrides FIX 1's width:100%/max-width:1200px/margin-auto/padding-24px
   geometry regardless of source order - no need to touch or delete FIX 1 itself,
   which still governs the max-width:1023px stacked layout below this breakpoint.

   Below 1024px, #brxe-lotjmo simply keeps Bricks' own default
   .brxe-section{display:flex;flex-direction:column;align-items:center}, and the four
   children's existing DOM order (eyebrow, heading, lead, THEN slider) already
   produces "text above, slider below" with no new mobile-specific rule required. */
@media (min-width: 1024px) {
	#brxe-lotjmo {
		display: grid;
		grid-template-columns: minmax(0, 1.55fr) minmax(0, 1fr);
		column-gap: 56px;
		align-items: center;
		box-sizing: border-box !important;
	}
	#brxe-lotjmo #brxe-jdafeg,
	#brxe-lotjmo #brxe-ktbmez,
	#brxe-lotjmo #brxe-dvdrnf {
		grid-column: 2;
		width: auto !important;
		max-width: none !important;
	}
	#brxe-lotjmo #brxe-fiprbw {
		grid-column: 1;
		grid-row: 1 / span 3;
		min-width: 0;
		align-self: center;
	}
}

/* ============================================================
   QUICK TASK 260819-q8f, Task 1 — mirror the desktop columns and pin the
   text group to the TOP of the "Vorher/Nachher" section
   ============================================================
   Client follow-up on p44 ("unharmonisch", "die Abstände ergeben keinen
   Sinn", "kein grosser, fetter Block" — see 260819-p44-CLIENT-FOLLOWUP.md).
   This block supersedes p44's block ABOVE it by SOURCE ORDER, not by
   editing it in place — same selectors, same specificity, same
   !important weight, so the LAST rule in the file wins. p44's block
   stays byte-unchanged above.

   Two things change here: (1) the columns mirror — text moves to column 1
   (left), the slider moves to column 2 (right); (2) the text group stops
   being vertically centred across the slider's full height and instead
   sits tightly grouped at the TOP, level with the slider's top edge.

   WHY the fourth grid row exists: #brxe-fiprbw spans three auto-sized
   grid rows (eyebrow/heading/paragraph). CSS Grid distributes a spanning
   item's surplus height OUT across the auto rows it spans — that is
   exactly what was pulling the three text rows apart down the slider's
   full height and reading as "unharmonisch". The fix is a FOURTH,
   flexible row (grid-template-rows: auto auto auto 1fr) that the slider
   ALSO spans (grid-row: 1 / -1) — the slack lands in the empty fourth
   row instead of being shared out among the three text rows, so
   align-items: start now genuinely reads as "top aligned, tightly
   grouped" instead of fighting the row-sharing math. Changing
   align-items alone (without the fourth row) would NOT fix this. */
@media (min-width: 1024px) {
	#brxe-lotjmo {
		grid-template-columns: minmax(0, 1fr) minmax(0, 1.55fr);
		grid-template-rows: auto auto auto 1fr;
		align-items: start;
		row-gap: 0;
	}
	#brxe-lotjmo #brxe-fiprbw {
		grid-column: 2;
		grid-row: 1 / -1;
		align-self: start;
		min-width: 0;
	}
	#brxe-lotjmo #brxe-jdafeg,
	#brxe-lotjmo #brxe-ktbmez,
	#brxe-lotjmo #brxe-dvdrnf {
		grid-column: 1;
	}
	#brxe-lotjmo #brxe-jdafeg {
		grid-row: 1;
	}
	#brxe-lotjmo #brxe-ktbmez {
		grid-row: 2;
	}
	#brxe-lotjmo #brxe-dvdrnf {
		grid-row: 3;
	}
}

/* ============================================================
   QUICK TASK 260819-rg3 — "Bestand & Ergebnis" block: 60/40 desktop grade for
   the shared .pcg-2col row, plus the block's own layout/chip styling
   ============================================================
   Closes design-exports/AUFTRAG_Claude_Code_ProjektDetail_BestandErgebnis_Block.md.
   This section styles a SERVER-RENDERED SHORTCODE block ([pcg_bestand_ergebnis],
   wp-content/themes/bricks-child/inc/bestand-ergebnis.php), not a set of Bricks
   elements - a CSS rule is the only available lever here, so the
   .planning/CONVENTIONS.md "prefer native Bricks panel fields" rule does not apply
   to markup this repo emits itself; there is no Bricks panel field for a
   shortcode's own internal markup.

   WHY 821px, NOT 1024px: the shared `.pcg-2col` rule (F3) stacks itself to a
   single column at `@media (max-width: 820px)` (see the 260810-1ld blow-out fix
   above). A `min-width: 1024px` modifier here would leave a silent 821-1023px
   band where the row is already two columns but ignores the 60/40 split - pin
   this modifier to `min-width: 821px` so it covers exactly the range where
   `.pcg-2col` is two-column, no gap, no overlap.

   WHY A TWO-CLASS SELECTOR, NOT AN ID RULE: `.pcg-2col.pcg-2col--6040` has
   specificity (0,2,0), which already outranks the global single-class
   `.pcg-2col` rule (0,1,0) with no `!important` needed - and, critically, adds
   NO new `#brxe-*` selector, so the ID-avoidance guard test and its allowlist
   below stay byte-unchanged by this task. Every grid track is `minmax(0, …fr)`,
   never a bare `fr`, per the blow-out incident this file documents at length for
   the base `.pcg-2col` class - the same gotcha would silently reappear here
   otherwise. */
@media (min-width: 821px) {
	.pcg-2col.pcg-2col--6040 {
		grid-template-columns: minmax(0, 60fr) minmax(0, 40fr);
		align-items: center;
	}
}

/* Block wrapper: a left-aligned flex column so the eyebrow, heading, body and
   chips form one stack regardless of the `.pcg-2col` column's own alignment
   defaults. */
.pcg-be {
	display: flex;
	flex-direction: column;
	align-items: flex-start;
	text-align: left;
}

/* Eyebrow: no colour/spacing override needed here - the shared `.pcg-eyebrow`
   class (design-exports/PCG_GlobalCSS_bereinigt.css) already supplies the red,
   uppercase, letter-spaced treatment with `!important`. `.pcg-be__eyebrow`
   exists purely as this block's own BEM hook (and satisfies the CSS<->PHP
   class-parity contract below); `display: block` is a harmless, defensive
   no-op on a <p> element. */
.pcg-be__eyebrow {
	display: block;
}

/* Heading: colour only. The shared `.pcg-h2` class (design-exports/
   PCG_GlobalCSS_bereinigt.css) already owns size, weight and line-height with
   `!important` - re-declaring any of those here would start a specificity fight
   for a value this block does not want to change. `.pcg-h2` itself carries no
   colour of its own, so a plain, non-`!important` colour declaration here is
   enough to win. */
.pcg-be__heading {
	color: var(--color-navy, #142440);
	margin-bottom: 8px;
}

/* Body paragraphs: the shared `.pcg-body` class already supplies the brief's
   grey colour with `!important` - no colour set here. wpautop() wraps the ACF
   text in bare <p> tags carrying the browser's own default margin; this resets
   that default to the block's own modest rhythm and zeroes the last
   paragraph's bottom gap so the block doesn't end in a dangling blank line
   before the chips. */
.pcg-be__body p {
	margin: 0 0 12px;
}
.pcg-be__body p:last-child {
	margin-bottom: 0;
}

/* Chips: compact pills, not buttons - labels only, no hover/focus state because
   they are not interactive (inc/bestand-ergebnis.php never wraps a chip in an
   <a>). */
.pcg-be__chips {
	list-style: none;
	display: flex;
	flex-wrap: wrap;
	gap: 8px;
	padding: 0;
	margin: 20px 0 0;
}
.pcg-be__chip {
	display: inline-flex;
	align-items: center;
	padding: 6px 12px;
	border-radius: 999px;
	border: 1px solid rgba(20, 36, 64, 0.18);
	background: rgba(20, 36, 64, 0.05);
	color: var(--color-navy, #142440);
	font-size: 13px;
	font-weight: 600;
	letter-spacing: 0.02em;
	line-height: 1.2;
}

/* ============================================================
   QUICK TASK (session 2026-08-19, live client follow-up on q8f) — homepage
   "Vorher/Nachher" text group: centre the TIGHT GROUP against the slider,
   not top-pin it
   ============================================================
   Client tried q8f's top-pinned result live and asked for the opposite:
   the eyebrow/heading/paragraph should stay grouped tightly together (q8f's
   fix for that stays correct - do not touch margin-bottom on jdafeg/ktbmez
   above), but the GROUP AS A WHOLE should sit vertically centred against the
   slider's height instead of pinned to its top edge - client's own words:
   the empty column reads better centred than top-heavy.

   Supersedes q8f's grid-template-rows/align-items block ABOVE by SOURCE
   ORDER only (last rule wins) - q8f's block stays byte-unchanged, exactly
   the same non-destructive-supersession convention q8f used against p44.

   HOW: swap the single trailing flexible row (auto auto auto 1fr, which put
   all the slack AFTER the text and so pinned the group to the top) for a
   flexible row BOTH BEFORE and AFTER the group (1fr auto auto auto 1fr).
   Two equal free rows push the tight 3-row group to the vertical centre of
   the slider's spanned height, the same way `margin: auto 0` centres a
   block - without touching the individual row-to-row gaps q8f already set
   (12px/20px stay, so the group itself does not re-spread). */
@media (min-width: 1024px) {
	#brxe-lotjmo {
		grid-template-rows: 1fr auto auto auto 1fr;
	}
	#brxe-lotjmo #brxe-fiprbw {
		grid-row: 1 / -1;
	}
	#brxe-lotjmo #brxe-jdafeg {
		grid-row: 2;
	}
	#brxe-lotjmo #brxe-ktbmez {
		grid-row: 3;
	}
	#brxe-lotjmo #brxe-dvdrnf {
		grid-row: 4;
	}
}

/* ============================================================
   QUICK TASK 260824-4kd — `.pcg-glassbox`: navy-transparenter Inhaltskasten
   fuer Sektionen mit Foto-Hintergrund (erste Instanz: /ueber-uns/ Sektion 2)
   ============================================================
   WARUM DIESE DATEI: pcg-elevation.css waere thematisch naeher (Kasten-/
   Erhebungs-System), hat aber zwei Hausregeln, die dieser Block verletzt und
   die dort auch richtig sind: keine Farb-Literale ausserhalb von `:root`, und
   jede `display: grid`-Regel muss `li.open` im Selektor tragen (die Datei
   gehoert dem Nav-Dropdown). Beides ist per Test abgesichert. pcg-responsive.css
   ist ausserdem der urspruengliche Ort von `.pcg-stats--grid` (Commit 920185d)
   und folgt bereits dem hier verwendeten `var(--x, fallback)`-ohne-`:root`-Muster.
   ============================================================
   Der Kunde hat gemeldet, dass Text direkt auf dem Foto-Hintergrund schlecht
   lesbar ist und die Zahlen "im luftleeren Raum" wirken. Loesung: ein
   halbdurchsichtiger Navy-Kasten hinter dem Inhalt, kraeftig genug fuer
   Lesbarkeit, durchsichtig genug, dass das Foto sichtbar bleibt.

   (1) WARUM CSS UND NICHT DAS BRICKS-PANEL — die drei Gruende, in der
   Reihenfolge ihres Gewichts:

   (a) `backdrop-filter` ist kein Bricks-Panel-Feld. Ohne den Weichzeichner
       muesste die Fuellung deutlich blickdichter sein, um dieselbe Lesbarkeit
       zu erreichen — dann sieht man das Foto praktisch nicht mehr, also genau
       das, was der Kunde NICHT will.
   (b) Die Textfarben MUESSEN `!important` tragen. Die Bricks-Globalklassen
       liefern ihre Farben bereits mit `!important` aus
       (`.pcg-body{color:rgba(20,36,64,.65)!important}`,
       `.pcg-statlabel{...!important}`), und die Sektion traegt `pcg-bg-light`,
       nicht `pcg-navy` — es greifen also die DUNKLEN Textfarben fuer hellen
       Grund, auf einem Foto. Kein Panel-Feld kann ein `!important` aus der
       Bricks-Custom-CSS ueberstimmen. Das ist der in `.claude/CLAUDE.md`
       ausdruecklich vorgesehene Ausnahmefall.
   (c) Fuenf Elemente (ein Textkasten + vier Zahlen-Kacheln) haetten sonst
       jeweils sechs identische Panel-Werte von Hand — sechsmal die Chance,
       dass einer abweicht.

   (2) WAS TROTZDEM IM PANEL BLEIBT: Hintergrundbild, Bildausschnitt,
   Verlaufs-Overlay und Sektions-Polsterung von `#brxe-xvsrqt`. Die kann das
   Panel ausdruecken, der Kunde sieht sie im Editor-Canvas und kann sie selbst
   nachziehen — sie gehoeren daher NICHT hierher.

   (3) ALLE WERTE SIND ueber Custom Properties nachjustierbar, ohne diese Datei
   anzufassen (Bricks -> Einstellungen -> Benutzerdefinierter Code -> Custom CSS,
   auf die Sektions-ID gescopet):
     --pcg-glassbox-bg      Fuellung          (Standard rgba(20,36,64,.72))
     --pcg-glassbox-line    Rahmenfarbe       (Standard rgba(255,255,255,.14))
     --pcg-glassbox-radius  Eckenradius       (Standard 16px, Kacheln 14px)
     --pcg-glassbox-blur    Weichzeichner     (Standard 10px)
     --pcg-glassbox-accent  Akzent/Praefix    (Standard #FF3B3B)
     --pcg-glassbox-pad-y / --pcg-glassbox-pad-x   Innenabstand

   (4) `#FF3B3B` STATT `#EE0000` fuer Eyebrow und Zaehler-Praefix: das
   Marken-Rot hat gegen die Navy-Fuellung zu wenig Kontrast und saeuft ab.
   `#FF3B3B` ist derselbe Farbton, nur heller — das Marken-Rot bleibt ueberall
   sonst auf der Seite unangetastet.
   ============================================================ */
.pcg-glassbox {
	background: var(--pcg-glassbox-bg, rgba(20, 36, 64, .72)) !important;
	border: 1px solid var(--pcg-glassbox-line, rgba(255, 255, 255, .14)) !important;
	border-radius: var(--pcg-glassbox-radius, 16px) !important;
	padding: var(--pcg-glassbox-pad-y, 38px) var(--pcg-glassbox-pad-x, 40px) !important;
}

/* Der Weichzeichner ist bewusst OPTIONAL und in ein @supports gekapselt: faellt
   er aus (aeltere Browser), traegt die Fuellung die Lesbarkeit allein — der
   Kasten sieht dann nur etwas flacher aus, nie kaputt. */
@supports ((-webkit-backdrop-filter: blur(1px)) or (backdrop-filter: blur(1px))) {
	.pcg-glassbox {
		-webkit-backdrop-filter: blur(var(--pcg-glassbox-blur, 10px)) saturate(1.08);
		backdrop-filter: blur(var(--pcg-glassbox-blur, 10px)) saturate(1.08);
	}
}

/* Textfarben im Kasten — siehe Begruendung (1b) oben fuer die !important-Flags. */
.pcg-glassbox .pcg-eyebrow,
.pcg-glassbox .pcg-counter .prefix {
	color: var(--pcg-glassbox-accent, #FF3B3B) !important;
}

.pcg-glassbox .pcg-h2,
.pcg-glassbox .pcg-statnum,
.pcg-glassbox .pcg-counter,
.pcg-glassbox .pcg-counter .count {
	color: #fff !important;
}

.pcg-glassbox .pcg-body,
.pcg-glassbox .pcg-lead {
	color: rgba(255, 255, 255, .86) !important;
}

.pcg-glassbox .pcg-statlabel {
	color: rgba(255, 255, 255, .74) !important;
}

/* Kachel-Variante: kleinere Ecken, engerer Innenabstand. */
.pcg-glassbox.pcg-glassbox--stat {
	--pcg-glassbox-radius: 14px;
	--pcg-glassbox-pad-y: 22px;
	--pcg-glassbox-pad-x: 24px;
}

/* ------------------------------------------------------------
   `.pcg-stats--grid` — die vier Zaehler als 2x2-Block statt als
   volle Viererreihe. Wiederhergestellt aus Quick Task 260822-5i2
   (Commit 920185d), der beim Revert 260823-rst mit entfernt wurde,
   mit zwei bewussten Abweichungen gegenueber dem Original:
     - `gap` ist 16px statt 20px/32px, weil die Kacheln jetzt eigene
       sichtbare Kaesten sind und nicht mehr randlose Textbloecke;
     - der urspruengliche `padding-left/right: 0`-Reset entfaellt und
       wird durch die Kasten-Polsterung ersetzt (siehe naechste Regel).
   Wie im Original: `minmax(0, 1fr)`, nie ein blosses `1fr` — dieses
   Projekt hat den CSS-Grid-"Blowout"-Fehler schon einmal live auf
   `.pcg-2col` erlebt (q8f/l9b).
   ------------------------------------------------------------ */
/* Mobile-first, bewusst OHNE `max-width`-Abfrage: dieser Block steht hinter der
   Sektion "Quick task 260819-0fc - Task 3", und deren Tests slicen die Sektion bis
   zum DATEIENDE und verlangen dort ausschliesslich `min-width`-Abfragen. Statt
   diesen fremden Test aufzuweichen ist die Regel hier mobile-first gebaut - was
   ohnehin die sauberere Bauweise ist: eine Spalte als Basis, zwei ab Desktop. */
.pcg-stats.pcg-stats--grid {
	display: grid !important;
	grid-template-columns: minmax(0, 1fr) !important;
	gap: 12px !important;
	width: 100% !important;
}

/* Die Trennlinien der Basis-Reihe (`border-left` auf Desktop, `border-top` auf
   Mobil) waeren zwischen echten Kaesten doppelt gemoppelt. */
.pcg-stats.pcg-stats--grid > * {
	min-width: 0 !important;
	border-left: none !important;
	border-top: none !important;
}

@media (min-width: 992px) {
	.pcg-stats.pcg-stats--grid {
		grid-template-columns: minmax(0, 1fr) minmax(0, 1fr) !important;
		gap: 16px !important;
	}
}

/* Diese eine Regel MUSS hoeher gewichtet sein als `.pcg-glassbox` allein:
   die Bricks-Globalklasse liefert `.pcg-stats > *{background:transparent
   !important; padding:14px 24px !important}` aus, was bei gleicher
   Spezifitaet (0,1,0) je nach Ladereihenfolge gewinnen koennte. Der
   Nachkommen-Selektor hier steht bei (0,3,0) und entscheidet das eindeutig -
   unabhaengig davon, ob Bricks' Inline-CSS vor oder nach dieser Datei landet. */
.pcg-stats.pcg-stats--grid > .pcg-glassbox {
	background: var(--pcg-glassbox-bg, rgba(20, 36, 64, .72)) !important;
	padding: var(--pcg-glassbox-pad-y, 22px) var(--pcg-glassbox-pad-x, 24px) !important;
}


/* ============================================================
   QUICK TASK 260824-w5e — Hero-System fuer drei Seiten:
   Glas-Varianten `--bar` / `--meta` (T1) und die Hero-Hoehen (T2)
   ============================================================
   Grundlage: Coworks Mockup vom 2026-08-24 (die drei Hero-Entwuerfe fuer
   Startseite, /ueber-uns/ und /referenzen/) plus die Client-Entscheidungen
   desselben Tages. Beide Dokumente liegen in
   .planning/quick/260824-w5e-hero-system-drei-seiten/.

   (1) WARUM KEINE NEUE BASISKLASSE. Das Mockup zeigt auf der Startseite eine
   dreispaltige Vertrauens-Leiste und auf /referenzen/ eine vierspaltige
   Zahlen-Leiste. Beide sind optisch dasselbe Bauteil wie `.pcg-glassbox`:
   halbdurchsichtiger Kasten mit feinem Rand und Weichzeichner. Eine zweite
   Basisklasse waere eine Kopie mit eigenem Wartungsrisiko — stattdessen setzen
   `--bar` und `--meta` NUR andere Werte auf denselben sechs Stellschrauben,
   die der 260824-4kd-Block oben bereits definiert. Faellt dort etwas aus,
   faellt es hier gleich mit aus, statt auseinanderzulaufen.

   (2) ZWEI HARTE DATEI-REGELN GELTEN AB HIER BIS ZUM DATEIENDE, beide per Test
   abgesichert, beide bestimmen die Bauweise unten:
     (a) KEINE `max-width`-Media-Query. Der Guard `0fc task3 (scope guard)`
         slict pcg-responsive.css ab „QUICK TASK 260819-0fc" bis zum Dateiende
         und verlangt dort ausschliesslich `min-width`; `stats-grid: the block
         opens no max-width query` tut dasselbe ab `--stat`. Die Leiste ist
         deshalb MOBILE-FIRST gebaut: eine Spalte als Grundzustand, Reihe erst
         ab 640px. Das ist ohnehin die sauberere Bauweise — dieselbe
         Entscheidung wie beim `.pcg-stats--grid`-Block direkt darueber.
     (b) Der Bruchpunkt ist bewusst 640px und NICHT 992px. `.pcg-stats--grid`
         besitzt bereits einen 992px-Block, und sein Test sucht sich den
         richtigen unter mehreren gleich lautenden Bloecken heraus — ein
         zweiter 992px-Block waere unnoetiges Risiko fuer null Gewinn.

   (3) DIE `!important`-FLAGS auf den Kindern der Leiste sind unvermeidbar und
   deshalb hier begruendet: die Bricks-Globalklassen liefern Farbe, Groesse und
   Innenabstand fuer `.pcg-statnum` / `.pcg-statlabel` / `.brxe-text-basic`
   bereits mit `!important` aus. Ohne Gegenflag stuenden die Angaben in der
   Standard-Textfarbe auf dem Foto. Das ist der in `.claude/CLAUDE.md`
   ausdruecklich vorgesehene Ausnahmefall — dieselbe Begruendung wie bei
   `.pcg-trustline` und `.pcg-glassbox` oben.

   (4) WAS BEWUSST IM BRICKS-PANEL BLEIBT: Hintergrundbild, Bildausschnitt,
   Verlaufs-Overlay und die Sektions-Polsterung. Die kann das Panel
   ausdruecken, der Kunde sieht sie im Editor-Canvas — sie gehoeren nicht
   hierher.

   (5) STELLSCHRAUBEN, alle mit Literal-Fallback und ohne `:root`-Standard,
   damit ein Kundenwert aus dem Bricks-Feld immer gewinnt:
     --pcg-bar-gap          Abstand der Spalten untereinander (Handy)  16px
     --pcg-bar-col-pad      Seitlicher Spaltenabstand (ab 640px)       24px
     --pcg-bar-num-size     Groesse der Zahl/des Begriffs      20px, ab 640px 24px
     --pcg-bar-num-tone     Farbe der Zahl                            #fff
                            (heisst bewusst NICHT `...-color`, siehe ACHTUNG
                            weiter unten — der Name allein bricht sonst einen
                            fremden Test)
     --pcg-bar-label-size   Groesse des Labels darunter                11px
     --pcg-bar-label-gap    Abstand Zahl -> Label                       6px
     --pcg-meta-size        Meta-Box, Zeile 1                          13px
     --pcg-meta-label-size  Meta-Box, Zeile 2                          11px
     --pcg-hero-h-ref       Hoehe /referenzen/                      100svh
     --pcg-hero-h-about     Hoehe der neuen Ueber-uns-Hero-Sektion  100svh

   (6) `--pcg-bar-num-tone` EXISTIERT NUR FUER /referenzen/. Das Mockup zeigt
   die vier Zahlen dort im Rot-Akzent, die drei Angaben auf der Startseite in
   Weiss. Statt einer zweiten Leisten-Klasse fuer diesen einen Unterschied
   bekommt die Referenzen-Leiste den Akzentwert `var(--pcg-glassbox-accent,
   #FF3B3B)` als Instanz-Wert auf diese Stellschraube gesetzt.

   ACHTUNG BEIM UMFORMULIEREN DIESES BANNERS UND ALLER KOMMENTARE UNTEN: der
   Test `glassbox: all four on-photo text colours are scoped under
   .pcg-glassbox and marked important` liest pcg-responsive.css MIT
   Kommentaren, slict ab `.pcg-glassbox .pcg-eyebrow` bis zum Dateiende und
   prueft die ersten sechs Vorkommen der Farb-Eigenschaft auf `!important` —
   Prosa zaehlt dort mit. Steht in einem Kommentar die Farb-Eigenschaft
   ausgeschrieben und mit Doppelpunkt, faellt dieser fremde Test, obwohl am
   Code nichts falsch ist. Genau das ist beim ersten Schreiben dieses Blocks
   zweimal passiert. Deshalb nennt jeder Kommentar unten die Eigenschaft nur
   ohne Doppelpunkt — UND deshalb heisst die Stellschraube fuer die Zahl
   `--pcg-bar-num-tone` und nicht `--pcg-bar-num-color`: die Suchregel jenes
   Tests trifft auch eine Custom-Property, deren NAME auf `color` endet, und
   eine Custom-Property traegt hier zurecht kein `!important`.
   ============================================================ */

/* ------------------------------------------------------------
   (T1a) Die Leiste — Startseite (3 Spalten) und /referenzen/ (4 Spalten)
   ------------------------------------------------------------
   Flacherer Eckenradius und hellere, kuehlere Fuellung als der Standard-
   Glaskasten: die Leiste sitzt am unteren Hero-Rand und soll dort als feine
   Kante wirken, nicht als zweiter Inhaltsblock, der mit der H1 konkurriert.
   ------------------------------------------------------------ */
.pcg-glassbox.pcg-glassbox--bar {
	--pcg-glassbox-bg: rgba(255, 255, 255, .08);
	--pcg-glassbox-line: rgba(255, 255, 255, .16);
	--pcg-glassbox-radius: 6px;
	--pcg-glassbox-blur: 12px;
	--pcg-glassbox-pad-y: 24px;
	--pcg-glassbox-pad-x: 28px;
	display: flex !important;
	flex-direction: column;
	gap: var(--pcg-bar-gap, 16px);
	width: 100% !important;
}

/* Die Spalten sind reine Textbloecke: der Kasten drumherum ist die Leiste
   selbst, nicht die einzelne Spalte. Deshalb hier alles zuruecksetzen, was die
   Bricks-Globalklassen an Rand, Polsterung und Fuellung mitliefern wuerden. */
.pcg-glassbox.pcg-glassbox--bar > * {
	min-width: 0 !important;
	margin: 0 !important;
	padding: 0 !important;
	background: transparent !important;
	border: 0 !important;
	text-align: left;
}

/* Zahl bzw. Begriff. Die Basisregel `.pcg-glassbox .pcg-statnum` setzt Weiss
   und steht bei (0,2,0); dieser Selektor steht bei (0,3,0) und entscheidet die
   Farbe daher eindeutig — unabhaengig von der Ladereihenfolge. */
.pcg-glassbox.pcg-glassbox--bar .pcg-statnum,
.pcg-glassbox.pcg-glassbox--bar .pcg-counter,
.pcg-glassbox.pcg-glassbox--bar .pcg-counter .count {
	display: block !important;
	font-family: var(--pcg-font-sans);
	font-size: var(--pcg-bar-num-size, 20px) !important;
	font-weight: 600 !important;
	line-height: 1.15 !important;
	color: var(--pcg-bar-num-tone, #fff) !important;
}

/* Label darunter. Farbe kommt bewusst NICHT von hier, sondern von der
   Basisregel `.pcg-glassbox .pcg-statlabel` weiter oben — ein zweiter
   Farbwert waere genau die Doppelpflege, die (1) vermeiden soll. */
.pcg-glassbox.pcg-glassbox--bar .pcg-statlabel {
	display: block !important;
	margin-top: var(--pcg-bar-label-gap, 6px) !important;
	font-family: var(--pcg-font-sans);
	font-size: var(--pcg-bar-label-size, 11px) !important;
	font-weight: 600 !important;
	line-height: 1.4 !important;
	letter-spacing: .16em !important;
	text-transform: uppercase !important;
}

/* Ab 640px wird aus der Liste eine Reihe. `flex: 1 1 0` (nicht `1 1 auto`)
   gibt allen Spalten dieselbe Breite, unabhaengig von der Textlaenge —
   „Sto-Klimapartner" darf „28+ Jahre" nicht zusammenschieben. Dieselbe
   Schreibweise wie im bestehenden `.pcg-stats > *`-Block der l9b-Runde. */
@media (min-width: 640px) {
	.pcg-glassbox.pcg-glassbox--bar {
		flex-direction: row;
		align-items: center;
		gap: 0;
		--pcg-bar-num-size: 24px;
	}

	.pcg-glassbox.pcg-glassbox--bar > * {
		flex: 1 1 0 !important;
		padding: 0 var(--pcg-bar-col-pad, 24px) !important;
	}

	/* Aussenkanten buendig zur Kasten-Polsterung, nicht doppelt eingerueckt. */
	.pcg-glassbox.pcg-glassbox--bar > :first-child {
		padding-left: 0 !important;
	}

	.pcg-glassbox.pcg-glassbox--bar > :last-child {
		padding-right: 0 !important;
	}

	/* Der Trenner ist Dekoration, kein Inhalt — dieselbe Unterscheidung wie
	   beim `|` der `.pcg-trustline`. Untereinander stehende Spalten (Handy)
	   bekommen ihn deshalb gar nicht erst, statt ihn dort abzuschalten. */
	.pcg-glassbox.pcg-glassbox--bar > * + * {
		border-left: 1px solid var(--pcg-glassbox-line, rgba(255, 255, 255, .16)) !important;
	}
}

/* Der Rot-Akzent der Referenzen-Leiste. Als dritte WERT-Variante und nicht als
   elementeigenes CSS im Bricks-Panel, weil Bricks dort die feste Element-ID
   (`#brxe-...`) abspeichert statt eines Platzhalters — beim Einfuegen eines
   kopierten Bauteils vergibt Bricks aber eine NEUE ID, und die hinterlegte
   Regel zeigt danach ins Leere. Eine Klasse ueberlebt das Einfuegen. Der Wert
   greift denselben Akzent-Token wie Eyebrow und Zaehler-Praefix, also auch
   dieselbe Aufhellung gegen die Navy-Fuellung (Punkt (4) im 260824-4kd-Block). */
.pcg-glassbox.pcg-glassbox--bar.pcg-glassbox--accent {
	--pcg-bar-num-tone: var(--pcg-glassbox-accent, #FF3B3B);
}

/* ------------------------------------------------------------
   (T1b) Die Meta-Box — /ueber-uns/, klein und sekundaer
   ------------------------------------------------------------
   Zwei Zeilen („Seit 2021 · PCG Pro Construction" / „28+ JAHRE
   BAUERFAHRUNG"). `inline-flex` + `width: auto`, damit der Kasten nur so breit
   wird wie sein Text — eine Meta-Angabe, die ueber die halbe Seite laeuft,
   waere wieder ein Inhaltsblock und kein Beiwerk.
   ------------------------------------------------------------ */
.pcg-glassbox.pcg-glassbox--meta {
	--pcg-glassbox-radius: 4px;
	--pcg-glassbox-blur: 12px;
	--pcg-glassbox-pad-y: 12px;
	--pcg-glassbox-pad-x: 18px;
	display: inline-flex !important;
	flex-direction: column;
	gap: 2px;
	width: auto !important;
}

.pcg-glassbox.pcg-glassbox--meta > * {
	margin: 0 !important;
	padding: 0 !important;
	background: transparent !important;
	border: 0 !important;
}

.pcg-glassbox.pcg-glassbox--meta .pcg-body {
	font-size: var(--pcg-meta-size, 13px) !important;
	line-height: 1.5 !important;
}

.pcg-glassbox.pcg-glassbox--meta .pcg-statlabel {
	font-size: var(--pcg-meta-label-size, 11px) !important;
	font-weight: 600 !important;
	line-height: 1.4 !important;
	letter-spacing: .16em !important;
	text-transform: uppercase !important;
}

/* ------------------------------------------------------------
   (T1d) Textfarben auf dem Foto — MEIN FEHLER AUS RUNDE 4, hier behoben
   ------------------------------------------------------------
   Der Kunde meldete am 2026-08-24: „auf der Ueber-uns-Seite ist die Schrift
   dunkel auf dunkel." Er hatte recht, und es lag NICHT an der CSS-Datei (die
   war nachweislich live und byte-identisch), sondern an meinem Bricks-Baustein:

   Die Bricks-Globalklassen liefern die Textfarben fuer HELLEN Grund aus, alle
   mit `!important` — `.pcg-lead` in rgba(20,36,64,.85), `.pcg-body` in
   rgba(20,36,64,.65), `.pcg-eyebrow` im dunklen Marken-Rot #EE0000. Auf einen
   dunklen Grund dreht sie erst die Sektionsklasse `.pcg-navy`. Der Baustein
   T5 trug diese Klasse nicht — also standen Eyebrow, H1 und Fliesstext in den
   dunklen Farben auf einem dunklen Foto.

   WARUM NICHT EINFACH `.pcg-navy` NACHTRAGEN: `.pcg-navy .pcg-eyebrow` setzt
   das dunkle #EE0000 und steht bei (0,2,0) — die naheliegende Gegenregel
   `.pcg-hero-about .pcg-eyebrow` stuende bei DERSELBEN Spezifitaet, und wer
   gewinnt, haengt dann an der Ladereihenfolge zwischen dieser Datei und Bricks'
   Inline-CSS. Genau diese Wackelei will der Block hier nicht. Stattdessen
   tragen die beiden Hero-Klassen ihre Textfarben SELBST: gegen die
   Basis-Globalklassen bei (0,1,0) gewinnen sie bei (0,2,0) unabhaengig von
   jeder Ladereihenfolge, und `.pcg-navy` wird gar nicht erst gebraucht.

   Der Eyebrow bekommt bewusst den aufgehellten Ton #FF3B3B, nicht das
   Marken-Rot: gegen ein dunkles Foto saeuft #EE0000 ab. Dieselbe Entscheidung
   und derselbe Token wie im 260824-4kd-Block, Punkt (4).
   ------------------------------------------------------------ */
.pcg-hero-about .pcg-hero-title,
.pcg-hero-ref .pcg-hero-title,
.pcg-hero-about h1,
.pcg-hero-ref h1 {
	color: #fff !important;
}

.pcg-hero-about .pcg-eyebrow,
.pcg-hero-ref .pcg-eyebrow {
	color: var(--pcg-glassbox-accent, #FF3B3B) !important;
}

.pcg-hero-about .pcg-lead,
.pcg-hero-ref .pcg-lead,
.pcg-hero-about .pcg-body,
.pcg-hero-ref .pcg-body {
	color: rgba(255, 255, 255, .86) !important;
}

/* ------------------------------------------------------------
   (T2) Die Hero-Hoehen — alle drei voll
   ------------------------------------------------------------
   CLIENT-ENTSCHEIDUNG 2026-08-24, nach einer ersten Fassung dieses Blocks:
   „das Mockup ist kein Vorbild in der Proportion — es ist nur das Design."
   Coworks Mockup gilt also fuer die GESTALTUNG (roter Eyebrow, weisse H1,
   gerichtetes Navy-Overlay, Glas-Leisten, Button-Sprache, und die Texte), aber
   NICHT fuer die Masse. Seine gestufften Hoehen 85vh / 62vh / ~480px sind
   damit hinfaellig; es gilt wieder der Auftragstext (§2): alle drei Heros
   fuellen den Bildschirm. Das ist auch das, was T2 im UMSETZUNGSPLAN von
   Anfang an vorgesehen hatte.

   FOLGE, DIE MAN KENNEN MUSS: die Hierarchie zwischen den drei Seiten entsteht
   damit AUSSCHLIESSLICH ueber die Funktion — Startseite mit Trust-Leiste und
   zwei Buttons, /ueber-uns/ mit kleiner Meta-Box und ohne Buttons,
   /referenzen/ mit Zahlen-Leiste und ohne Buttons. Ueber die Hoehe entsteht sie
   nicht mehr. Das ist gewollt, nicht uebersehen.

   DIE STARTSEITE BLEIBT BYTE-UNVERAENDERT bei `calc(100vh + 90px)` weiter oben
   in dieser Datei: ihre `+ 90px` sind kein Aufschlag nach Geschmack, sondern
   der Ausgleich fuer `margin-top: -90px`, mit dem die Sektion unter den
   transparenten Header gezogen wird. Die beiden Regeln hier tragen diesen
   Ausgleich nicht, weil ihre Sektionen ihn nicht brauchen.

   `svh` STATT NUR `vh`, als progressives Paar (`vh` zuerst, `svh` danach):
   `svh` geht immer vom KLEINSTMOEGLICHEN Sichtfeld aus und verhindert
   deshalb, dass beim Ein-/Ausfahren der Handy-Adressleiste die naechste
   Sektion unten durchlugt — genau die Beschwerde, die Quick Task 260809-pj7
   auf der Startseite behoben hat. `dvh` waere falsch: es aendert die Hoehe
   mitten im Scrollen und laesst die Sektion springen.

   KEIN `!important`: der Kunde soll die Hoehe jederzeit im Bricks-Panel
   ueberschreiben koennen. Ein Panel-Wert ist ID-gebunden und schlaegt eine
   Klassenregel ohnehin — das ist hier gewollt, nicht ein Mangel.

   ACHTUNG FUER DIE NAECHSTE RUNDE: der Fits-Waechter (`curtainFits()` in
   site-interactions.js) heftet eine Sektion nur an, wenn ihr INHALT auf den
   Bildschirm passt. Er misst den Inhalt, nicht die Box — eine hoehere Box
   schadet also nicht per se. Steht der Inhalt aber senkrecht mittig, schiebt
   eine hoehere Box ihn nach unten und der Puffer schrumpft. Gemessen am
   2026-08-24: /ueber-uns/ 98px, /referenzen/ 216px. Nach jeder Ergaenzung
   (Trust-Leiste, Meta-Box, Zahlen-Leiste) am Live-DOM nachmessen.
   ------------------------------------------------------------ */
.pcg-hero-ref {
	min-height: var(--pcg-hero-h-ref, 100vh);
	min-height: var(--pcg-hero-h-ref, 100svh);
}

/* Die noch zu bauende Hero-Sektion auf /ueber-uns/ (T5). Klasse statt ID, weil
   die Sektion in Bricks erst entsteht und ihre ID daher noch nicht feststeht —
   und weil sie ohnehin `pcg-curtain` tragen muss (siehe pcg-motion.css). */
.pcg-hero-about {
	min-height: var(--pcg-hero-h-about, 100vh);
	min-height: var(--pcg-hero-h-about, 100svh);
}


/* ============================================================
   AUFTRAG 260824-w5e (Runde 6) — ALLE ABSTANDS-SPERREN ENTFERNT
   ============================================================
   Kunden-Entscheidung vom 2026-08-25, nach Durchsicht von
   design-exports/entwuerfe/260824-hero-system/LISTE_Abstand-Sperren.md:
   fortfahren.

   Entfernt: ALLE 53 ID-gebundenen `!important`-Deklarationen auf Abstaende
   (margin / padding / gap) in dieser Datei, plus 48 Zeilen leer gewordener
   Regeln. Ab jetzt bestimmt das Bricks-Panel jeden Abstand — sichtbar im
   Editor-Canvas, aenderbar ohne SFTP-Runde. Das ist die Hausregel aus
   `.claude/CLAUDE.md`, endlich durchgezogen.

   ELF DER REGELN WAREN OHNEHIN TOT: ihre Elemente existieren auf keiner der
   sechs geprueften Seiten mehr, weil der Kunde die Bereiche neu gebaut hat und
   Bricks dabei neue Element-Nummern vergibt (#brxe-vputtu, #brxe-idmbte,
   #brxe-nvrwdc, #brxe-oqjbke, #brxe-vclxaw, #brxe-pymefe, #brxe-nkbljj).

   DIE ENTFERNTEN WERTE, damit sie bei Bedarf ins Panel getippt werden koennen:

     Hero-Ueberschrift (auch die NEUE, ueber .pcg-hero-title):
       margin-bottom + padding-bottom  12px, ab 1024px 20px, bis 640px 8px
     Hero-Fliesstext (alte ID): padding-bottom 32px / 24px / 36px / ab 1024px 44px
     Partner-Logo-Raster:       gap 20px 28px, bis 640px 14px 16px
     Partner-Sektion:           padding oben+unten 48px, bis 640px 32px
     Partner-Container:         margin-bottom 24px
     Partner-Ueberschrift:      margin-top 0, margin-bottom 16px
     Vorher/Nachher-Sektion:    seitliches Polster max(24px, (100% - 1200px) / 2)
     Eyebrow/Ueberschrift/Fliesstext darin, ab 1024px:
       alle Raender 0; Eyebrow margin-bottom 12px, Ueberschrift 20px, Text 0
     Dieselben vier Elemente ausserhalb dieser Sektion:
       seitliches Polster 24px, bis 820px 20px; ab 1024px margin links/rechts auto
     Berlin-Karte:              seitliches Polster 24px, bis 820px 20px
     Eyebrow „Unsere Leistungen": margin-top 0
     „Warum PCG":               seitliches Polster 20px bis 820px, Raender 0
     Vorher/Nachher-Regler-Label: padding 5px 11px

   WAS ABSICHTLICH GEBLIEBEN IST: alles, was kein Abstand ist — Schriftgroessen
   (der `--pcg-hero-*`-Vertrag steht unveraendert), Farben, Ausrichtung,
   Rasterspalten, Box-Modell, die Sticky-Logik. Und `.pcg-section`s gemeinsamer
   Rhythmus, weil er auf Klassen liegt statt auf IDs und jede Sektion betrifft.

   EINE FALLE BEIM AUFRAEUMEN, fuer den naechsten Leser: leer gewordene Regeln
   muessen samt ihrer GANZEN, oft mehrzeiligen Selektorliste verschwinden. Ein
   erster Versuch entfernte nur die letzte Selektorzeile mitsamt `{}` — die
   uebrigen Zeilen klebten danach am Selektor der FOLGENDEN Regel, wodurch
   `.pcg-hero-title` stillschweigend die Formatierung des Fliesstextes bekam.
   Gefunden, bevor irgendetwas hochgeladen wurde; die Pruefung darauf steht in
   tests/pcg-responsive-css.test.cjs.

   WOMIT ZU RECHNEN IST: mehrere dieser Regeln wurden gegen echte, vom Kunden
   gemeldete Fehler geschrieben (zu grosser Abstand zwischen Sektionen, Text am
   Handy-Rand, nicht linksbuendige Ueberschrift). Kommt so ein Zustand zurueck,
   ist er jetzt im Panel sichtbar und dort zu beheben — genau das war das Ziel.
   ============================================================ */


/* ============================================================
   AUFTRAG QS 260825 — SAFARI-KARTEN-BUG: `.pcg-cardgrid` wird zur Flexbox
   ============================================================
   DER FEHLER, in Safari 17.1 reproduziert und vermessen (nicht vermutet):
   auf der Startseite ist die Sektion „Spezialisiert auf vier Gewerke" ein
   Raster von 4 Karten. Gemessen ergab sich dort

       Rasterzeile:  344px        Karte:  612px

   — die Karten sind 268px hoeher als ihre eigene Zeile und laufen deshalb in
   die folgende Navy-Sektion hinein. In Chrome sind beide Werte ~345px. Genau
   der vom Kunden gemeldete Screenshot.

   DIE URSACHE, durch Messung eingegrenzt: ausgeloest wird der Fehler
   ausschliesslich durch das STRECKEN (`align-items: stretch`) eines
   Grid-Elements, dessen Kind ein `aspect-ratio` traegt (hier
   `.pcg-card-media` mit 4/3). Neun Kandidaten wurden direkt in Safari
   durchprobiert; diese fuenf aendern NICHTS und sind damit als Ursache
   ausgeschlossen: `min-height: 0`, `overflow: hidden`, feste Media-Hoehe
   statt `aspect-ratio`, Karte als `flex column`, Karte als `grid`.
   Nur das Aufheben des Streckens half — und Flexbox, dessen Strecken den
   Fehler nicht ausloest.

   WARUM FLEXBOX UND NICHT `align-items: start`: `start` behebt den Ueberlauf
   ebenfalls, macht die Karten dabei aber unterschiedlich hoch (gemessen
   324/344/324/344, weil sie dann ihrem Inhalt folgen). Das waere eine
   sichtbare Designaenderung, und der Auftrag verbietet die ausdruecklich.
   Flexbox behebt den Ueberlauf UND haelt die Karten gleich hoch (gemessen
   351px viermal). Kunden-Entscheidung vom 2026-08-25: „Variante 2".

   WARUM NUR `:not(.pcg-cardgrid--2)`: die `--2`-Variante ist NICHT betroffen —
   am selben Tag im selben Safari gemessen, ihre Karten stehen bei 386px, also
   korrekt. Grund: `.pcg-cardgrid--2 .pcg-card-media` ersetzt das
   `aspect-ratio` durch eine feste Hoehe von 220px, womit die Ursache dort gar
   nicht erst entsteht. Die Variante bleibt deshalb unangetastet — kleinster
   moeglicher Eingriff.

   DIE SPALTENZAHLEN sind unveraendert uebernommen, nicht neu erfunden:
     bis  640px   1 Spalte    (bisher: dieser Datei, Zeile ~497)
     ab   641px   2 Spalten   (bisher: dieser Datei, Zeile ~505)
     ab  1000px   4 Spalten   (bisher: Bricks-Custom-CSS, mit !important)
   Sie stehen unten als EINE Formel ueber `--pcg-cardgrid-cols`, damit sie
   nicht wieder auf drei Dateien verteilt auseinanderlaufen.

   MOBILE-FIRST, weil es muss: ab `.pcg-glassbox--stat` bis zum Dateiende
   verbieten zwei bestehende Tests jede `max-width`-Abfrage (siehe der
   260824-w5e-Block weiter oben). Eine Spalte ist deshalb der Grundzustand,
   zwei und vier kommen ueber `min-width` dazu.

   `display: flex` braucht KEIN `!important`: die Bricks-Regel steht bei
   Spezifitaet (0,1,0), dieser Selektor mit seinem `:not()` bei (0,2,0) und
   gewinnt unabhaengig von der Ladereihenfolge. Die bisherigen
   `grid-template-columns`-Regeln bleiben stehen und sind auf einem
   Flex-Container wirkungslos — bewusst nicht geloescht, damit ein Zurueckdrehen
   dieses Blocks den alten Zustand exakt wiederherstellt.

   `flex-grow: 0`: eine nicht voll besetzte letzte Reihe soll ihre Karten in
   normaler Breite lassen, so wie ein Raster es tut — nicht auf volle Breite
   aufziehen. Die Referenzen-Seite nutzt dieselbe Vorlage mit anderer
   Kartenzahl, dort wird das sichtbar.
   ============================================================ */
.pcg-cardgrid:not(.pcg-cardgrid--2) {
	--pcg-cardgrid-cols: 1;
	--pcg-cardgrid-gap: 28px;
	display: flex;
	/* `row` MUSS hier stehen und ist nicht der Standard, den man erwarten wuerde:
	   Bricks' eigenes `.brxe-block` ist eine SPALTEN-Flexbox. Wo der Raster-
	   Behaelter ein Block ist (so auf /referenzen/, `#brxe-icebum`), erbt er
	   `flex-direction: column`. `display: flex` allein dreht das nicht zurueck —
	   die Hauptachse bleibt senkrecht, `flex-basis` steuert dann die HOEHE, und
	   jede Karte wird volle Behaelterbreite. Genau so gemeldet am 2026-08-25:
	   „eine Karte fuellt mehr als die gesamte Seite". Auf der Startseite fiel es
	   nicht auf, weil der Behaelter dort ein `.brxe-div` ohne diesen Standard ist. */
	flex-direction: row;
	flex-wrap: wrap;
	align-items: stretch;
	gap: var(--pcg-cardgrid-gap, 28px);
}

.pcg-cardgrid:not(.pcg-cardgrid--2) > * {
	/* Literal-Rueckfallwerte wie ueberall in dieser Datei: der Block muss auch
	   dann funktionieren, wenn beide Stellschrauben fehlen — 1 Spalte, 28px. */
	flex: 0 0 calc(
		(100% - (var(--pcg-cardgrid-cols, 1) - 1) * var(--pcg-cardgrid-gap, 28px))
		/ var(--pcg-cardgrid-cols, 1)
	);
	min-width: 0;
}

@media (min-width: 641px) {
	.pcg-cardgrid:not(.pcg-cardgrid--2) {
		--pcg-cardgrid-cols: 2;
	}
}

@media (min-width: 1000px) {
	.pcg-cardgrid:not(.pcg-cardgrid--2) {
		--pcg-cardgrid-cols: 4;
	}
}

/* ============================================================
   Quick task 260826-j24 — .pcg-thumb-link
   ============================================================
   Angehaengt ans Dateiende, gleiche Konvention wie jede Sektion darueber:
   anhaengen, niemals eine bestehende Regel bearbeiten.

   WOHER DIESE KLASSE KOMMT. `[pcg_project_thumb link="permalink"]` huellt sein
   `<img class="pcg-thumb">` in ein `<a class="pcg-thumb-link">` (siehe
   inc/project-thumb.php, Section B). Ohne Attribut entsteht dieser Wrapper
   nicht — die Karten auf /referenzen/ und die Startseiten-Teaser sehen ihn also
   gar nicht und werden von diesen zwei Regeln nie beruehrt.

   WARUM display:block DIE EIGENTLICHE ARBEIT IST. Ein `<a>` ist von Haus aus
   `inline`. Ein Bild in einem Inline-Element sitzt auf der Schriftlinie, und
   unter dieser Linie bleibt der Platz fuer Unterlaengen (p, g, y) stehen —
   sichtbar als ein paar Pixel Luecke unter dem Bild, die kein Abstandswert
   erklaert. `display:block` nimmt dem Wrapper diese Zeilennatur, das Bild
   schliesst wieder buendig ab. `width:100%` sorgt dafuer, dass der Wrapper
   dieselbe Breite einnimmt wie das Bild vorher, damit die Kachel ihre Groesse
   behaelt — `.pcg-thumb` selbst bleibt unveraendert (`width:100%`,
   `aspect-ratio:4/3`, `object-fit:cover` weiter oben in dieser Datei).

   WARUM DIESE SEKTION `.pcg-thumb` NICHT ANFASST. Zwei Regeln weiter oben sind
   auf `:has(> .pcg-thumb)` gebaut, also auf ein DIREKTES Kind. Waere der Link
   jemals in einer `.pcg-card` im Einsatz, wuerde `.pcg-thumb` dort zum Enkel
   und jene Regeln griffen nicht mehr. Genau deshalb ist der Link ein Opt-in und
   heute ausschliesslich in der Kachel-Schleife der Projekt-Detailseite gesetzt,
   die keine `.pcg-card` ist. Wer das kuenftig auf die Karten ausweitet: dort
   zuerst die beiden `:has(> .pcg-thumb)`-Regeln um die Wrapper-Ebene ergaenzen.

   WARUM EIN EIGENER FOKUSRAHMEN. Der Link ist ab jetzt mit der Tabulatortaste
   erreichbar. Ohne sichtbare Markierung wuesste jemand, der ohne Maus bedient,
   nicht, auf welcher Kachel er gerade steht. 2px Aussenlinie mit 2px Abstand —
   dieselbe Variable und dieselbe Formsprache wie die Fokusrahmen der
   Berlin-Karte in berlin-map.css, damit es im ganzen Projekt genau eine
   Fokusfarbe gibt.

   WARUM HIER AUSNAHMSWEISE KEIN HEX-RUECKFALLWERT STEHT. berlin-map.css schreibt
   `var(--color-accent, #EE0000)`. Diese Datei hier darf den Marken-Rotwert NICHT
   wiederholen: zwei bestehende Vertragstests (`glassbox: the brand red #EE0000
   is NOT reused inside the panel` und `w5e t1c`) schneiden pcg-responsive.css ab
   einem Merkmal BIS ZUM DATEIENDE auf und verlangen, dass das unaufgehellte
   Marken-Rot darin nicht mehr vorkommt — jede Sektion, die hier unten angehaengt
   wird, faellt automatisch in dieses Fenster. Der Rueckfallwert ist deshalb
   `currentColor`: immer gueltig, immer definiert, und er hebt sich per
   Definition von dem Untergrund ab, auf dem der eigene Text lesbar ist. Er
   greift ohnehin nur in dem Fall, in dem `--color-accent` gar nicht existiert —
   auf dieser Seite ist der Wert durchgaengig gesetzt. Ohne einen Rueckfallwert
   waere die gesamte Deklaration ungueltig und der Fokusrahmen verschwaende
   ersatzlos; genau das soll nicht passieren. */
.pcg-thumb-link {
	display: block;
	width: 100%;
}

.pcg-thumb-link:focus-visible {
	outline: 2px solid var(--color-accent, currentColor);
	outline-offset: 2px;
}