.cart-summary table.table tbody tr,
.cart-summary table.table tbody td
{
  white-space: normal;
}

.hpk-table tbody>tr>td.price-col {
  vertical-align: bottom;
  text-align: right;
}

.totals-box {
  margin-top: 20px;
}

.totals-box table {
  margin-bottom: 20px;
  text-align: right;
  border: none;
}

.totals-box table>tbody>tr>td {
  border: none;
}

/* HosterPK 13.3 (2026-07-28) — the five stock `.whois` rules are RETIRED with the
 * wrapper. lookup.pdt no longer emits `col-md-12 whois`; the surface is one card. Each
 * rule is disposed of explicitly rather than left dangling:
 *
 *   .whois                    DELETED. Its rgba(0,0,0,.05) tint was the invisible middle
 *                             surface of the three-deep nest (finding 14), and its
 *                             background-image: url(../images/globe.svg) 110% -70px
 *                             painted ~545px of un-themed white artwork over the label,
 *                             input and chips below md — a rendering error in dark
 *                             (finding 1). images/globe.svg STAYS ON DISK: it is a
 *                             stock-fork sibling and order-pack-upgrade-check.sh counts
 *                             213 files. Retire the rule, not the asset.
 *   .whois div.checkbox label DELETED. The 12.6 chip rewrite replaced div.checkbox with
 *                             .hpk-tld-chip-wrap; the pack emits no div.checkbox inside
 *                             this surface at all (checkout/signup keep their own, and
 *                             they were never in .whois scope).
 *   .whois div.tlds,          DELETED, BOTH HALVES. The first is superseded by
 *   div.search                fieldset.tlds (12.6). The second was UNSCOPED and still
 *                             matched lookup.pdt's <div class="search hpk-search-actions">
 *                             — the no-JS transfer row — centring it. The card is
 *                             left-aligned now, so a centred lone button read as a stray;
 *                             the row keeps normal block flow. It is the pack's only
 *                             div.search, so nothing else changes.
 *   .whois div.tlds           DELETED with the above.
 *   .whois .show_more         DELETED. .hpk-tld-chip carries margin: 0 space-1 space-1 0,
 *                             so the preceding chip already supplies the gap the 5px
 *                             margin-left was providing.
 *
 * The .well rule that painted the third surface is retired in the same pass — see the
 * 13.3 section at the foot of this file. */

/* HosterPK 12.4 AC3 TLD atomicity (nowrap) is superseded by Story 12.6 — the chip
 * classes .spotlight_tld/.normal_tld now sit on the .hpk-tld-chip-wrap, which owns the
 * nowrap atomicity rule in the 12.6 block at the foot of this file. */

/* Begin for order pages */

/* HosterPK 13.7 (Trap 10): the FOUR `.card-steps` rules that stood here — the 10px
 * padding + g100 card fill, the `i { opacity: .3 }` chevron dimmer, the 13.5 note about
 * the deleted `p { opacity: .7 }`, and `a.active:before` (the stock check glyph on the
 * current step) — are DELETED, not merely left unmatched.
 *
 * They are dead: the marker rail retires the entire `.card.card-blesta.card-steps`
 * structure and `grep -r card-steps` over the pack's views now returns nothing, so every
 * one of these selects on markup no lane emits. A retired hook with a live rule is the
 * defect signal 13.4 paid for and reach.py exists to catch; deleting is the fix, and
 * leaving them "in case" would mean the next reader cannot tell shipped CSS from residue.
 *
 * Nothing is lost. The g100 fill is superseded by the rail sitting bare on the hero-wash
 * (the mock's composition); the chevrons no longer exist to dim; and the check glyph is
 * re-provided, correctly, as the COMPLETE state's marker — the stock rule put it on the
 * CURRENT step, which is the one place a check is wrong. The same certified
 * --hpk-success-text token carries over verbatim (D8). */

.table>tbody>tr.sub-item>td {
  border-top: none;
}

#login_box #login_message .alert {
	margin-top: 10px;
}
.pass-reset {
    padding-top: 5px;
    font-size: 12px;
    font-style: italic;
}

/* End for order pages */

/* ==========================================================================
 * HosterPK 11.3 — chrome + design-token port for the order surface.
 *
 * WHY. The modern HosterPK shell (Story 2.2/FR7) DROPPED stock application.min.css,
 * so the Bootstrap grid + .btn/.card base the order pack's stock .pdt depend on have
 * NO stylesheet (ORDER-PAGES §4: sidebar drops below content, the Step 1-4 rail
 * stacks, Add-to-Cart renders unstyled). vendor-compat.css is the CLOSED 33-class
 * shim and provides ONLY .col-xs-*, .float-*, .btn-block/-xs/-default, .form-group,
 * .table-curved — NOT .col-md-* or .row, the .btn base, or .card. We re-provide exactly
 *
 * 13.2 FIX: the phrase above used to join those two class names with a bare slash,
 * which put a comment-terminator sequence (star-slash) in the middle of this block.
 * It closed the comment 25 lines early; everything down to the next opening brace was
 * then parsed as one garbage selector, and the rule that garbage selector swallowed
 * was the .hpk-main / .row float containment immediately below — silently dead since
 * Story 11.3, and invisible to every gate. NEVER put that two-character sequence
 * inside a CSS comment, not even when quoting it.
 * the missing order vocabulary HERE (this file is injected by the controller's
 * $custom_head ONLY on order pages and loads AFTER the bundle -> wins the cascade
 * with no override flag). Do NOT move any of this into vendor-compat.css (D1: never an
 * unbounded second framework).
 *
 * SCOPING. Every structure-assuming rule is gated behind the live order body marker
 * `.hpk-client[class*="plugin-order"]` (verified emitted at structure.pdt:164 ->
 * "plugin-orderclient-main-packages" etc). That marker (0,2,0) also lets these rules
 * out-rank base.css frame-tier element rules (e.g. .hpk-client a = (0,1,1)) WITHOUT a
 * flag — required so <a class="btn"> buttons aren't repainted blue-on-blue by the
 * link rule (the frame-tier specificity trap).
 *
 * GRID MODEL = FLOATS. Stock bootstrap/structure.pdt wrapped $content in
 * `col-md-9 > div.row` (a flex parent). The modern shell echoes $content bare into
 * <main>, so the pack's top-level col-md-9 (content) + col-md-3 (#summary_section)
 * lost their flex parent. Re-providing cols as BS3-style FLOATS (the SAME model
 * vendor-compat already uses for .col-xs-4) works WITHOUT a .row flex parent; a
 * display:flow-root on <main> and on .row contains the floats. Mobile-first: cols are
 * full-width blocks by default, floated only at the md breakpoint.
 *
 * AA. Every colour reuses a token whose light+dark pair is pre-certified by the
 * check.sh 24-cell matrix (surface/ink, g100/g200/neutral-text, success/danger
 * tint+text, primary+#fff) -> AA holds in both themes for free. No net-new pair.
 * ========================================================================== */

/* --- Float containment: give <main> (order pages only) + every .row a block
 * formatting context so the floated columns below don't escape. flow-root is
 * layout-neutral otherwise. --- */
.hpk-client[class*="plugin-order"] .hpk-main,
.hpk-client[class*="plugin-order"] .row:not(#payment_details *) {
  display: flow-root;
}

/* HosterPK 13.7 (Trap 10): 12.3's float-containment pair on `.card-steps` + its `.row`
 * is DELETED. It existed to stop the rail's floated .col-md-3 cells and float-right
 * chevron <i>'s leaking onto the next card — and the marker rail has neither. A flex row
 * of four <li> establishes its own formatting context and floats nothing, so the whole
 * class of defect it guarded against no longer has a mechanism. The generic
 * `.row:not(#payment_details *)` BFC above is untouched and still serves every other
 * order lane. */

/* --- The dropped md grid (mobile-first: full-width blocks; float at >=768px). --- */
.hpk-client[class*="plugin-order"] [class*="col-md-"]:not(#payment_details *),
.hpk-client[class*="plugin-order"] .col-xs-5:not(#payment_details *),
.hpk-client[class*="plugin-order"] .col-sm-5:not(#payment_details *) {
  box-sizing: border-box;
}
/* summary.pdt uses col-md-5 col-sm-5 col-xs-5 for the cart-summary label/value row;
 * provide the xs/sm widths the dropped grid removed. */
.hpk-client[class*="plugin-order"] .col-xs-5:not(#payment_details *) { float: left; width: 41.6667%; }
@media (min-width: 768px) {
  .hpk-client[class*="plugin-order"] .col-sm-5:not(#payment_details *) { float: left; width: 41.6667%; }
}
@media (min-width: 768px) {
  .hpk-client[class*="plugin-order"] .col-md-12:not(#payment_details *) { width: 100%; }
  .hpk-client[class*="plugin-order"] .col-md-9:not(#payment_details *)  { float: left; width: 75%; padding-inline-end: var(--hpk-space-4); }
  .hpk-client[class*="plugin-order"] .col-md-8:not(#payment_details *)  { float: left; width: 66.6667%; }
  .hpk-client[class*="plugin-order"] .col-md-7:not(#payment_details *)  { float: left; width: 58.3333%; }
  .hpk-client[class*="plugin-order"] .col-md-6:not(#payment_details *)  { float: left; width: 50%; }
  .hpk-client[class*="plugin-order"] .col-md-5:not(#payment_details *)  { float: left; width: 41.6667%; }
  .hpk-client[class*="plugin-order"] .col-md-4:not(#payment_details *)  { float: left; width: 33.3333%; }
  .hpk-client[class*="plugin-order"] .col-md-3:not(#payment_details *)  { float: left; width: 25%; }
  /* offsets (cart totals box right-aligns via offset-md-8; col-md-offset-2 is a
   * stock BS3 spelling used by config). margin-inline keeps them logical. */
  .hpk-client[class*="plugin-order"] .offset-md-8:not(#payment_details *)     { margin-inline-start: 66.6667%; }
  .hpk-client[class*="plugin-order"] .col-md-offset-2:not(#payment_details *) { margin-inline-start: 16.6667%; }
}
/* col-border: the checkout multi-column divider (config_packageoptions / checkout
 * when >2 columns). A subtle inline rule between columns; logical for RTL hygiene. */
.hpk-client[class*="plugin-order"] .col-border { border-inline-start: 1px solid var(--hpk-border); }
/* clearfix (used after the float-right package action row; not in the shim). */
.hpk-client[class*="plugin-order"] .clearfix::after { content: ""; display: block; clear: both; }

/* --- Visibility utilities the pack emits (absent from vendor-compat).
 *
 * HosterPK 13.5 (AC5, D9): the `.hidden-xs` / `.hidden-sm` re-provisions that used to
 * live here are DELETED, together with the classes themselves on all 7 stepper views.
 * They were BS3-faithful and that was the problem: .hidden-xs hides below 768px and
 * .hidden-sm hides 768–991px, so the pair blanked the step rail across the WHOLE band
 * below 992px. The review measured the rail at 0×0 at 764px as well as at 386px — the
 * tablet band has never shown a stepper at all. The rail is now REPLACED below 760px by
 * {components.order-stepper}.compact rather than removed, so there is always wayfinding,
 * and it is visible from 761px up for the first time.
 *
 * Deleted only after a fresh repo-wide grep proved zero remaining emitters: no file
 * under plugins/order/views/templates/hosterpk_standard/ or app/views/client/hosterpk/
 * carries either class, and the pack ships a counterpart for every one of stock's 21
 * views (the 7 stock files that still emit them can never render while this stylesheet
 * is loaded, because this stylesheet only loads when this pack is the active template).
 * --- */
/* HosterPK 13.7 (Trap 10): `.d-none` is DELETED. Its ONLY emitter in the pack was the
 * stepper's `d-none d-sm-block` chevron, which the marker rail retires — measured, not
 * assumed: a class-token diff of every `class="..."` attribute in the pack between
 * baseline_commit and this change lists exactly five tokens 13.7 stopped emitting
 * (card-steps, d-none, d-sm-block, d-sm-none, fa-chevron-right), of which these three
 * were the only ones with a live rule left behind. `.hidden` — the class the lookup JS
 * actually toggles — is a DIFFERENT class and is untouched, as the note below says. */
/* HosterPK 11.4: the domain-lookup JS toggles the class `.hidden` (NOT `.d-none`) on
 * the spotlight/normal TLD labels and the AJAX-loaded TLD-pricing rows — and lookup.pdt
 * replaces a conditional inline display:none on .normal_tld with this class toggle to
 * clear the RULE 1 inline-style trap (tld_pricing_rows.pdt:9 reuses it; 11.3 review
 * defer). Scoped exactly like .d-none above; at (0,3,0) it out-ranks the kit
 * .hpk-client .hpk-table tr (0,2,1) so a hidden TLD-pricing row stays hidden inside the
 * <=760px card reflow until the toggle reveals it (jQuery .toggle() sets inline display
 * to override). No override flag. */
.hpk-client[class*="plugin-order"] .hidden { display: none; }
/* HosterPK 13.4: the 11.4 `.tld_pricing.hidden.tld-pricing-open` reveal pair is RETIRED.
 * The pricing table is now an aria-expanded disclosure whose collapse unit is
 * #hpk-pricing-body, so toggleTldPricingTable(), the per-row `.hidden` and the
 * `.tld-pricing-open` reveal are all deleted together in lookup.pdt. Nothing emits either
 * class any more (13.4 also drops `hidden` from tld_pricing_rows.pdt's appended rows, and
 * the append path strips it defensively in case a pre-13.4 cache entry is replayed), so
 * keeping these rules would be dead CSS that muddies 13.6's fidelity attribution. */
/* HosterPK 12.3: stale results dimmed + inert while a NEW domain search is in flight
 * (10-18s live). JS-toggled marker class (RULE-1-safe, no inline style). opacity is not
 * a colour so no 6/CONTRAST cell; the JS also sets aria-hidden + a tabindex sweep, and
 * pointer-events:none blocks pointer interaction, so the dimmed region is neither
 * interactive nor announced. Removed on full-page reload. */
.hpk-client[class*="plugin-order"] .hpk-inflight-dim {
  opacity: .5;
  pointer-events: none;
}
/* HosterPK 12.4 AC4: loading-skeleton shimmer for the getAllTlds pricing expansion.
 * loadAllTlds() injects <tr class="hpk-skeleton-row"> placeholder rows while the AJAX
 * request is in flight, so the expander never shows a bare hung "Loading…". Marker-
 * scoped (RULE 1: no inline style=); the neutral gray/white gradient reuses no brand
 * token, so it adds no new 6/CONTRAST colour pair. No override flag (RULE 2). */
.hpk-client[class*="plugin-order"] .hpk-skeleton-row td { color: transparent; }
.hpk-client[class*="plugin-order"] .hpk-skeleton {
  display: inline-block;
  height: .8em;
  width: 60%;
  border-radius: 4px;
  background: linear-gradient(90deg, rgba(0,0,0,.06), rgba(0,0,0,.12), rgba(0,0,0,.06));
  background-size: 200% 100%;
  animation: hpk-skeleton-shimmer 1.2s ease-in-out infinite;
}
@keyframes hpk-skeleton-shimmer {
  0%   { background-position: 200% 0; }
  100% { background-position: -200% 0; }
}
/* Dark theme is selected by [data-theme], not OS preference. */
[data-theme="dark"] .hpk-client[class*="plugin-order"] .hpk-skeleton {
  background: linear-gradient(90deg, rgba(255,255,255,.08), rgba(255,255,255,.16), rgba(255,255,255,.08));
  background-size: 200% 100%;
}
/* Respect reduced-motion preferences (WCAG 2.2): drop the animation, keep a flat tint. */
@media (prefers-reduced-motion: reduce) {
  .hpk-client[class*="plugin-order"] .hpk-skeleton {
    animation: none;
    background: rgba(128,128,128,.2);
  }
}
.hpk-client[class*="plugin-order"] .hpk-pricing-error td {
  background: var(--hpk-danger-tint);
  border-color: var(--hpk-danger);
  color: var(--hpk-danger-text);
  font-weight: 600;
}
@media (min-width: 576px) {
  /* HosterPK 13.7 (Trap 10): `.d-sm-block` and `.d-sm-none` are DELETED with `.d-none`
   * above — the stepper's two chevrons were their only emitters in the pack and the
   * marker rail retires both. `.mb-sm-0` is NOT deleted: 13.7 did not change its emitter
   * status, and deleting a rule this story did not orphan would be churn dressed as
   * cleanup. */
  .hpk-client[class*="plugin-order"] .mb-sm-0 { margin-bottom: 0; }
}

/* --- Cards: the step rail, the package widget, and the cart summary all use
 * .card/.card-blesta/.card-header/.card-body/.card-footer, none styled by the bundle
 * on this surface. Blesta's generated theme.css paints .card-header dark (the navy
 * bars in the §4 break) and loads BEFORE us; the scoped marker (0,3,0) out-ranks its
 * (0,1,0) with no flag. --- */
.hpk-client[class*="plugin-order"] .card,
.hpk-client[class*="plugin-order"] .card-blesta {
  background: var(--hpk-surface);
  border: 1px solid var(--hpk-border);
  border-radius: var(--hpk-r-lg);
  margin-bottom: var(--hpk-space-4);
}
.hpk-client[class*="plugin-order"] .card-header {
  padding: var(--hpk-space-3) var(--hpk-space-card-padding);
  background: var(--hpk-g100);
  color: var(--hpk-ink);
  font-weight: 600;
  border-bottom: 1px solid var(--hpk-border);
  border-start-start-radius: var(--hpk-r-lg);
  border-start-end-radius: var(--hpk-r-lg);
}
.hpk-client[class*="plugin-order"] .card-body,
.hpk-client[class*="plugin-order"] .card-content {
  padding: var(--hpk-space-card-padding);
}
.hpk-client[class*="plugin-order"] .card-footer {
  padding: var(--hpk-space-card-padding);
  background: var(--hpk-g100);
  border-top: 1px solid var(--hpk-border);
  border-end-start-radius: var(--hpk-r-lg);
  border-end-end-radius: var(--hpk-r-lg);
}
/* HosterPK 13.7 (Trap 10): the `.card-steps` de-carding rule (g100 tint, no border, no
 * shadow) is DELETED with the card it de-carded. 13.7 reaches the same end by not
 * rendering a card at all — the rail is a bare <ol> on the hero-wash, which is the v2
 * mock's composition and one fewer surface between the customer and the funnel. */

/* --- Spacing utilities (BS4 idioms -> design-system space tokens). Placed AFTER the
 * .card block so .mb-* utilities win when a card also carries a margin utility. --- */
.hpk-client[class*="plugin-order"] .m-0   { margin: 0; }
.hpk-client[class*="plugin-order"] .mb-0  { margin-bottom: 0; }
.hpk-client[class*="plugin-order"] .mb-2  { margin-bottom: var(--hpk-space-2); }
.hpk-client[class*="plugin-order"] .mb-3  { margin-bottom: var(--hpk-space-3); }
.hpk-client[class*="plugin-order"] .mt-2  { margin-top: var(--hpk-space-2); }
.hpk-client[class*="plugin-order"] .mx-1  { margin-inline: var(--hpk-space-1); }
.hpk-client[class*="plugin-order"] .p-3   { padding: var(--hpk-space-3); }

/* --- Buttons. The §4(c) break is the MISSING BS .btn BASE: vendor-compat (:89) and
 * Blesta's generated theme.css both omit the base, so Add-to-Cart / checkout / coupon
 * / login render as unstyled boxes (no padding/shape). We re-provide the base here
 * (mirrors .hpk-btn, components.css:103). .btn-block/.btn-xs are already shimmed.
 *
 * The semantic COLOURS are NOT ours to set: Blesta's generated /client/theme/theme.css
 * (retained globally by structure.pdt, BEFORE our bundle) declares .btn-{light,success,
 * danger,secondary,primary,...} background+color+border with the override flag — the
 * SAME theme-wide flag condition the vendor-compat badge allowlist documents. A
 * non-flagged order.css rule cannot beat it, and RULE 2 forbids the flag outside the audited
 * vendor-compat badge set. So order.css supplies only the base SHAPE; the variant
 * colour is theme.css's (a clean light button in light mode). KNOWN RESIDUAL: theme.css
 * is light-only, so in dark mode the flagged .btn-* keep their light colours (e.g.
 * .btn-light = white = a dark-mode searchlight; .btn-success = #fff-on-#28a746 ~2.7:1).
 * Both remain legible, and this is a pre-existing CLIENT-AREA-WIDE theme.css condition
 * (every fallback .btn-* page, not order-specific) — neutralising the flagged btn/alert
 * family in dark is a theme-wide vendor-compat/dark-mode story, NOT 11.3's pack scope. --- */
.hpk-client[class*="plugin-order"] .btn:not(#payment_details *) {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  gap: var(--hpk-space-2);
  font-family: var(--hpk-font-body);
  font-size: var(--hpk-button-font-size);
  font-weight: var(--hpk-button-font-weight);
  padding: var(--hpk-space-button-padding);
  border: 1px solid transparent;
  border-radius: var(--hpk-r-md);
  line-height: 1.2;
  text-decoration: none;
  cursor: pointer;
  min-height: 44px;
}
/* sm/xs sizing + button group (the package term <select> sits beside its submit) — NOT
 * flagged by theme.css, so these apply. Preserve .btn-block layout and .btn-xs sizing
 * so the more-specific base .btn rule above doesn't wipe them out. */
.hpk-client[class*="plugin-order"] .btn-sm:not(#payment_details *),
.hpk-client[class*="plugin-order"] .btn-xs:not(#payment_details *) {
  padding: .35rem .75rem;
  font-size: .8rem;
  min-height: 44px;
}
.hpk-client[class*="plugin-order"] .btn-block:not(#payment_details *) {
  display: block;
  width: 100%;
  min-height: 44px;
}
.hpk-client[class*="plugin-order"] .btn-group:not(#payment_details *) {
  display: inline-flex;
  flex-wrap: wrap;
  gap: var(--hpk-space-1);
  max-width: 100%;
}
.hpk-client[class*="plugin-order"] .btn[disabled]:not(#payment_details *),
.hpk-client[class*="plugin-order"] .btn.disabled:not(#payment_details *),
.hpk-client[class*="plugin-order"] .btn[aria-disabled="true"]:not(#payment_details *) {
  cursor: not-allowed;
  opacity: .65;
}

/* --- Checkbox / radio containers (BS3 .checkbox/.radio) used in checkout, signup,
 * config, and domain lookup. Provide minimal block layout so labels/input groups do
 * not collapse; native controls keep their UA paint. Deeper custom-control styling is
 * 11.4/11.5/11.6 per-view scope. --- */
.hpk-client[class*="plugin-order"] .checkbox:not(#payment_details *),
.hpk-client[class*="plugin-order"] .radio:not(#payment_details *) {
  position: relative;
  display: block;
  margin-bottom: var(--hpk-space-2);
}
.hpk-client[class*="plugin-order"] .checkbox:not(#payment_details *) label,
.hpk-client[class*="plugin-order"] .radio:not(#payment_details *) label {
  display: inline-block;
  margin-bottom: 0;
  cursor: pointer;
}

/* --- Alerts (the empty-cart warning in the summary surface + any order alert).
 * theme.css declares .alert-* WITHOUT a flag, so a scoped (0,3,0) rule wins and brings
 * the design-system state tint/text (AA-certified, dark-aware) — fixing the dark-mode
 * yellow/red searchlight theme.css's light-only alert would otherwise leave. Mirrors
 * the components.css plugin-route alert mapping. --- */
.hpk-client[class*="plugin-order"] .alert:not(#payment_details *) {
  padding: var(--hpk-space-3);
  border: 1px solid transparent;
  border-radius: var(--hpk-r-md);
  margin-bottom: var(--hpk-space-3);
}
.hpk-client[class*="plugin-order"] .alert-success:not(#payment_details *) {
  background: var(--hpk-success-tint);
  border-color: var(--hpk-success);
  color: var(--hpk-success-text);
}
.hpk-client[class*="plugin-order"] .alert-warning:not(#payment_details *) {
  background: var(--hpk-warning-tint);
  border-color: var(--hpk-warning);
  color: var(--hpk-warning-text);
}
.hpk-client[class*="plugin-order"] .alert-danger:not(#payment_details *) {
  background: var(--hpk-danger-tint);
  border-color: var(--hpk-danger);
  color: var(--hpk-danger-text);
}
.hpk-client[class*="plugin-order"] .alert-info:not(#payment_details *) {
  background: var(--hpk-info-tint);
  border-color: var(--hpk-info);
  color: var(--hpk-info-text);
}

/* --- Story 14.4 / D8 / OQ-14.4-B1: the handoff-deflected LANDING on the cart lane.
 * Both checkout deflections are server-side redirects to order/cart/index, so the
 * designed state renders on cart.pdt around the flash the platform already composed.
 * GEOMETRY ONLY, AND THAT IS A MEASUREMENT NOT A PREFERENCE: the alert's own colours
 * already come from the certified, dark-aware state tints declared immediately above,
 * and the flash's recovery BUTTON cannot be re-voiced from here at all because
 * theme.css declares the .btn-* colour variants with the flag that RULE 2 forbids
 * outside the audited vendor-compat badge set. So this rule introduces NO colour and
 * therefore NO net-new certified pair - gen-contrast.sh stays out of this story's
 * surface, which is the 14.2 round-2 ruling. scroll-margin-top keeps the reason the
 * buyer was sent back clear of any sticky chrome when the landing is anchored.
 * ⚠ EVERY TOKEN HERE IS ONE THAT EXISTS. --hpk-space-6 does NOT (tokens.css stops at
 * -5), and an undefined var() does not fall back to nothing - it INHERITS, so the
 * rule would have silently taken the parent's value and looked deliberate. Verified
 * against tokens.css:135-146 rather than assumed. --- */
.hpk-cart-flash {
  margin-bottom: var(--hpk-space-4);
  scroll-margin-top: var(--hpk-space-5);
}

/* --- Form-control small sizing + responsive tables + legacy boxes the pack emits. --- */
.hpk-client[class*="plugin-order"] .input-sm:not(#payment_details *),
.hpk-client[class*="plugin-order"] .form-control-sm:not(#payment_details *) {
  padding: .25rem .5rem;
  font-size: var(--hpk-small-font-size);
}
.hpk-client[class*="plugin-order"] .table-responsive { overflow-x: auto; }
/* HosterPK 13.3: the `.well` rule is RETIRED. lookup.pdt:80 carried the pack's ONLY
 * `.well` (grep it), and that rule — g100 fill + 1px border + radius — was what made the
 * inner panel VISIBLE, so it was surface #3 of the three-deep nest. 13.3 drops the class
 * from .hpk-search-card, which would have left this rule matching nothing. A dead rule is
 * churn that muddies 13.6's fidelity attribution (13.2's standard), so it goes with the
 * class rather than surviving as an un-exercised shim. .hpk-search-card keeps its own
 * text-align:left in the 12.5 block below. */
.hpk-client[class*="plugin-order"] .top-focus-box:not(#payment_details *) {
  padding: var(--hpk-space-3);
  background: var(--hpk-g100);
  border-radius: var(--hpk-r-md);
}
/* panel-fix wraps a row that must not inherit float artefacts; flow-root contains it. */
.hpk-client[class*="plugin-order"] .panel-fix:not(#payment_details *) { display: flow-root; }

/* ==========================================================================
 * HosterPK 12.5 — hero search card + intent segment (Wave-2 recomposition).
 *
 * Recomposes the Step-1 search region (lookup.pdt #domain-lookup-form) into a
 * labelled search card: a visible label, one large input with the primary CTA
 * attached as an .hpk-input-group (Enter submits), a REAL-radio intent segment
 * (Register / Transfer), and a subordinate "continue without a domain" text link.
 * Flag-free, scoped to the order body marker, reusing --hpk-* tokens whose
 * light+dark pairs are pre-certified by the check.sh CONTRAST matrix (the intent
 * active-dark #A9C5FF cell + idle-item cells were added there for this story).
 * Dark via [data-theme="dark"]. All new show/hide is class-driven (RULE 1-safe).
 * ========================================================================== */

/* Card content is left-aligned. (13.3: it used to be a correction for the .whois
 * container's centring; that container is retired, so this is now simply the search
 * region's own alignment contract and the rule stays exercised.) */
.hpk-client[class*="plugin-order"] .hpk-search-card { text-align: left; }

/* Visible search label above the input. */
.hpk-client[class*="plugin-order"] .hpk-search-label {
  display: block;
  margin-bottom: var(--hpk-space-2);
  font-weight: 600;
  color: var(--hpk-ink);
}

/* Hero input-group. The bundle's .hpk-input-group__suffix carries password-toggle
 * chrome (g200 fill + border + inline padding). Here the suffix holds the primary CTA
 * button, which owns its own fill/border/radius — strip the suffix chrome so the button
 * sits flush against the input, and square the button's left edge to marry the input.
 * Order-scoped, so the password-toggle input-group primitive is untouched elsewhere. */
.hpk-client[class*="plugin-order"] .hpk-search-group { width: 100%; }
.hpk-client[class*="plugin-order"] .hpk-search-group input { min-height: 48px; }
.hpk-client[class*="plugin-order"] .hpk-search-group .form-control { padding-inline-end: .75rem; }
.hpk-client[class*="plugin-order"] .hpk-search-group .hpk-input-group__suffix {
  padding: 0;
  border: 0;
  background: transparent;
}
.hpk-client[class*="plugin-order"] .hpk-search-group .hpk-input-group__suffix .hpk-btn {
  border-start-start-radius: 0;
  border-end-start-radius: 0;
  min-height: 48px;
  white-space: nowrap;
}

/* Intent segment: a pill track holding two real radios rendered as segment labels.
 * The native radios are .sr-only (focusable + in the a11y tree) so arrow keys roam the
 * group and Space selects; the visible, styled control is the adjacent <label>. */
.hpk-client[class*="plugin-order"] .intent-segment {
  display: inline-flex;
  gap: 4px;
  margin: 0 0 var(--hpk-space-3);
  padding: 4px;
  border: 0;
  border-radius: 9999px;
  background: var(--hpk-g200);
}
.hpk-client[class*="plugin-order"] .intent-segment__item {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  min-height: 44px;
  min-width: 44px;
  margin: 0;
  padding: 0 var(--hpk-space-4);
  border-radius: 9999px;
  color: var(--hpk-ink);
  font-weight: 500;
  cursor: pointer;
}
/* Active (checked) item — light: --hpk-primary text on --hpk-surface, the inverse of
 * .hpk-btn-primary and the same certified pair as link|light; weight + shadow lift it. */
.hpk-client[class*="plugin-order"] .intent-segment__control:checked + .intent-segment__item {
  background: var(--hpk-surface);
  color: var(--hpk-primary);
  font-weight: 600;
  box-shadow: var(--hpk-shadow);
}
/* Active item — dark: #A9C5FF on surface-dark, gen-contrast-verified 7.52:1 (>=4.5). */
[data-theme="dark"] .hpk-client[class*="plugin-order"] .intent-segment__control:checked + .intent-segment__item {
  color: #A9C5FF;
}
/* Visible keyboard focus on the segment (the native radio is .sr-only). Placed last so
 * the focus ring wins over the active-item elevation shadow when an item is both. */
.hpk-client[class*="plugin-order"] .intent-segment__control:focus-visible + .intent-segment__item {
  box-shadow: var(--hpk-focus);
}

/* No-JS Transfer submit: default-visible so the no-JS transfer lane works; hidden only
 * once JS marks the form ready (the input-group CTA + enabled bridge take over). */
.hpk-client[class*="plugin-order"] .hpk-js-ready .hpk-no-js-transfer-submit { display: none; }

/* The escape hatch. 12.5 made it a subordinate text link; 13.5 AC3 makes it an OUTLINE
 * button (the treatment continues in the 13.5 section at the foot of this file).
 *
 * HosterPK 13.5: the three link declarations that used to sit here — small font,
 * --hpk-link, underline — are DELETED, not merely overridden. Scoped at (0,3,0) they
 * out-ranked the bundle's own `.hpk-client a.hpk-btn-outline` (0,2,1) and order.css
 * loads after the bundle, so leaving them would have painted the new button as an
 * underlined blue link wearing button chrome. */
.hpk-client[class*="plugin-order"] .hpk-continue-wrap {
  margin-top: var(--hpk-space-3);
  text-align: center;
}

/* ==========================================================================
 * HosterPK 12.6 — TLD chips, grouped picker & compact pricing card (Wave-2).
 *
 * Recomposes the Step-1 TLD selector (lookup.pdt .tlds fieldset) into
 * {components.tld-chip} pills and demotes the pre-search pricing table to a
 * compact, visually-quiet popular-prices card with the currency select in its
 * header. Flag-free, scoped to the order body marker, reusing --hpk-* tokens
 * whose light+dark pairs are certified by the check.sh CONTRAST matrix (the
 * tld-chip-selected light + dark cells were added there for this story). Dark
 * via [data-theme="dark"]. Supersedes the 12.4 .whois .spotlight_tld/.normal_tld
 * nowrap rule — atomicity now rides the chip wrapper.
 * ========================================================================== */

/* fieldset reset: the live CSS targeted div.tlds; the block is now a <fieldset>
 * with an sr-only <legend>, so reset the UA fieldset chrome and left-align the
 * chips under the hero (the .hpk-search-card text-align:left already flips it).
 *
 * 13.3: display:block added. The fieldset also carries .hpk-form-group, which the
 * bundle defines as `display: flex; flex-direction: COLUMN` (components.css:2863) —
 * so every chip was stretched to one full-width bar per row, defeating 12.6's pill
 * design and DESIGN.md's "each chip is an atomic nowrap unit". MEASURED: at the
 * baseline 95740fa8 the chips were already one-per-row at 523px each, so this is
 * inherited, not introduced — but 13.3 removes the col-md-8 col-md-offset-2
 * narrowing, which widened each bar to 940px and made it the loudest thing on the
 * surface. It is amplified by this story, belongs to no other Epic-13 story, and is
 * one declaration inside the rule that already owns this fieldset, so it is fixed
 * here rather than routed. Restoring block flow lets the inline-flex chips wrap
 * naturally on their own margins, exactly as 12.6 intended. */
.hpk-client[class*="plugin-order"] fieldset.tlds {
  display: block;
  border: 0;
  padding: 0;
  margin: 0 0 var(--hpk-space-3);
  min-width: 0;
  text-align: left;
}
/* 13.3 review: the two fixes above and AC4's transfer-mode hide COLLIDE, and the
 * layout rule silently won. hpkSyncIntent() hides the picker with .hidden, but
 * `.hpk-client[class*="plugin-order"] .hidden` is (0,3,0) while the rule directly
 * above is (0,3,1) — element-qualified — so `display:block` outranked it at every
 * source order and the chips, .show_more and #hpk-tld-groups (all children of this
 * fieldset) stayed on screen in Transfer mode. That is finding 8's exact
 * contradiction: transfer copy beside a live extension picker. MEASURED before the
 * fix: class list `form-group hpk-form-group tlds hidden`, computed `display: block`.
 * Restated at (0,4,1) so the hidden STATE outranks the layout rule on specificity
 * alone — no override flag (RULE 2), and no change to either rule's intent. */
.hpk-client[class*="plugin-order"] fieldset.tlds.hidden {
  display: none;
}

/* Chip wrapper: the atomic unit — a control never wraps apart from its label
 * (the 12.4 nowrap moves here from .whois .spotlight_tld/.normal_tld). */
.hpk-client[class*="plugin-order"] .hpk-tld-chip-wrap {
  display: inline-flex;
  white-space: nowrap;
}

/* Idle chip: pill (rounded.pill, 1px border, surface bg, ink text), >=44px hit
 * target; the whole label is clickable (the native input is .sr-only). */
.hpk-client[class*="plugin-order"] .hpk-tld-chip {
  display: inline-flex;
  align-items: center;
  min-height: 44px;
  padding: 0 var(--hpk-space-3);
  border: 1px solid var(--hpk-border);
  border-radius: 9999px;
  background: var(--hpk-surface);
  color: var(--hpk-ink);
  cursor: pointer;
  margin: 0 var(--hpk-space-1) var(--hpk-space-1) 0;
  font-weight: 500;
}

/* Selected (light): primary border + primary-tint bg + primary text + a leading
 * check. Certified by the tld-chip-selected|light CONTRAST cell (1457E6/EAF0FD).
 * The check uses the already-loaded Font Awesome 5 Free family (no new asset). */
.hpk-client[class*="plugin-order"] .hpk-tld-chip__control:checked + .hpk-tld-chip {
  border-color: var(--hpk-primary);
  background: var(--hpk-primary-tint);
  color: var(--hpk-primary);
  font-weight: 600;
}
.hpk-client[class*="plugin-order"] .hpk-tld-chip__control:checked + .hpk-tld-chip::before {
  content: "\f00c";
  font-family: "Font Awesome 5 Free";
  font-weight: 900;
  font-size: .8em;
  margin-inline-end: var(--hpk-space-1);
}

/* Selected (dark): primary-on-primary-tint is illegible (~1.9:1), so use the
 * stronger .28 wash + light-blue #A9C5FF — the same rule as active nav / the
 * intent segment. Certified by the tld-chip-selected|dark CONTRAST cell. */
[data-theme="dark"] .hpk-client[class*="plugin-order"] .hpk-tld-chip__control:checked + .hpk-tld-chip {
  background: rgba(20, 87, 230, .28);
  color: #A9C5FF;
}

/* Visible keyboard focus on the label (the native input is .sr-only). */
.hpk-client[class*="plugin-order"] .hpk-tld-chip__control:focus-visible + .hpk-tld-chip {
  box-shadow: var(--hpk-focus);
}

/* Grouped "+ More extensions" reveal: the note + sub-headings. .hidden owns the
 * collapsed state (RULE 1 class toggle); .hidden already declared above. */
.hpk-client[class*="plugin-order"] .hpk-tld-note {
  margin: var(--hpk-space-1) 0 var(--hpk-space-2);
}
.hpk-client[class*="plugin-order"] .hpk-tld-group {
  margin-top: var(--hpk-space-2);
}
.hpk-client[class*="plugin-order"] .hpk-tld-group__heading {
  margin: 0 0 var(--hpk-space-1);
  font-size: var(--hpk-small-font-size);
  font-weight: 600;
  color: var(--hpk-text);
  text-transform: uppercase;
  letter-spacing: .04em;
}

/* Compact popular-prices card (AC3): reads quieter than the hero — subtle border,
 * smaller heading, tighter header padding. The <=760px .hpk-table reflow ships in
 * the bundle already, so this adds no reflow CSS. */
.hpk-client[class*="plugin-order"] .hpk-price-card {
  margin-top: var(--hpk-space-4);
  border: 1px solid var(--hpk-border);
  border-radius: var(--hpk-r-md);
  background: var(--hpk-surface);
}
.hpk-client[class*="plugin-order"] .hpk-price-card__header {
  display: flex;
  flex-wrap: wrap;
  align-items: center;
  justify-content: space-between;
  gap: var(--hpk-space-2);
  padding: var(--hpk-space-2) var(--hpk-space-3);
  background: var(--hpk-g100);
  border-bottom: 1px solid var(--hpk-border);
  border-start-start-radius: var(--hpk-r-md);
  border-start-end-radius: var(--hpk-r-md);
}
.hpk-client[class*="plugin-order"] .hpk-price-card__heading {
  margin: 0;
  font-size: 1rem;
  font-weight: 600;
  color: var(--hpk-ink);
}
/* HosterPK 13.4: three rules, three different dispositions — do not sweep them together.
 *   .hpk-currency-form        RETIRED: its only user was the Form->create(... 'class' =>
 *                             'form-inline hpk-currency-form') 13.4 deletes.
 *   .hpk-currency-form__label RETIRED: its only user was the <label for="change_currency">
 *                             13.4 deletes.
 *   .hpk-price-card__currency KEPT, BODY REDEFINED. It is still live — it is the static
 *                             currency marker's hook in the 13.4 target DOM. What changed
 *                             is its JOB: it used to be the flex row laying out label +
 *                             select; it now holds a single run of text, and the flex-row
 *                             role moved to the new .hpk-price-card__meta that carries the
 *                             marker AND the disclosure toggle. Deleting it would strip
 *                             the marker of styling; leaving it a flex container would be
 *                             a rule that no longer describes its content. */
.hpk-client[class*="plugin-order"] .hpk-price-card__meta {
  display: flex;
  flex-wrap: wrap;
  align-items: center;
  gap: var(--hpk-space-2);
}
.hpk-client[class*="plugin-order"] .hpk-price-card__currency {
  font-size: var(--hpk-small-font-size);
  color: var(--hpk-muted);
  white-space: nowrap;
}
.hpk-client[class*="plugin-order"] .hpk-price-card__body {
  padding: var(--hpk-space-2) var(--hpk-space-3);
}

/* ==========================================================================
 * HosterPK 12.7 — results recomposition: per-row [Add] toggle, verdict banner
 * & honest tally bar (Wave-2, third/last authoring recomposition).
 *
 * Recomposes the Step-1 RESULTS region inside #configure_domain: each available
 * row's domains[] checkbox becomes an [Add]/Remove toggle (presentation sugar
 * over the SAME submitted checkbox — POST byte-identical), the verdict alert
 * ladder gains a .hpk-verdict-banner layout carrying the subject's honest price
 * + a verdict CTA, and the "Order Selected" button becomes a single-primary
 * .hpk-tally bar with an honest count + running total. Flag-free, scoped to the
 * order body marker, reusing --hpk-* tokens whose light+dark pairs are certified
 * by the check.sh CONTRAST matrix. The Add-toggle added state + verdict/tally
 * CTAs reuse the tld-chip-selected + hpk-btn-primary/outline certified pairs, so
 * NO net-new CONTRAST pair. Dark via [data-theme="dark"]. All promotion/state is
 * marker-class toggling (RULE 1-safe: no inline style, no .show()/.hide()).
 * ========================================================================== */

/* --- Per-row [Add] toggle. The native checkbox is .sr-only (focusable + in the
 * a11y tree); the visible styled control is the adjacent <label>, an outline
 * button. CSS flips the Add/Remove spans by :checked (RULE-7-safe: both strings
 * render server-side from the copy table — no JS text injection). The added look
 * reuses the certified tld-chip-selected pair, so no new CONTRAST cell. --- */
.hpk-client[class*="plugin-order"] .hpk-add-toggle {
  min-height: 44px;
  white-space: nowrap;
}
.hpk-client[class*="plugin-order"] .hpk-add-toggle__remove { display: none; }
.hpk-client[class*="plugin-order"] .hpk-add-toggle__control:checked + .hpk-add-toggle .hpk-add-toggle__add { display: none; }
.hpk-client[class*="plugin-order"] .hpk-add-toggle__control:checked + .hpk-add-toggle .hpk-add-toggle__remove { display: inline; }
/* Added (light): primary border + primary-tint bg + primary text — the same
 * certified pair as tld-chip-selected|light (1457E6/EAF0FD). */
.hpk-client[class*="plugin-order"] .hpk-add-toggle__control:checked + .hpk-add-toggle {
  border-color: var(--hpk-primary);
  background: var(--hpk-primary-tint);
  color: var(--hpk-primary);
  font-weight: 600;
}
/* Added (dark): primary-on-primary-tint is illegible (~1.9:1), so use the .28
 * wash + #A9C5FF — the same rule as the intent segment / tld-chip. Certified by
 * the tld-chip-selected|dark CONTRAST cell. */
[data-theme="dark"] .hpk-client[class*="plugin-order"] .hpk-add-toggle__control:checked + .hpk-add-toggle {
  background: rgba(20, 87, 230, .28);
  color: #A9C5FF;
}
/* Visible keyboard focus on the label (the native input is .sr-only). */
.hpk-client[class*="plugin-order"] .hpk-add-toggle__control:focus-visible + .hpk-add-toggle {
  box-shadow: var(--hpk-focus);
}

/* --- Verdict banner. The certified hpk-alert-* alert (semantic colour + tint +
 * 1px border + radius + padding, all AA in the CONTRAST matrix) gains a flex
 * layout (subject/price on the leading edge, the verdict CTA on the trailing
 * edge) + a 3px semantic LEFT border. The 3px width rides the .alert +
 * .hpk-verdict-banner double-class + :not() selector so it out-ranks the alert
 * base's (1,3,0) border-inline-start-width:1px; the border COLOUR is left to the
 * certified .alert-* border-color (no restated colour → no new CONTRAST pair).
 * Subject/price stay in the certified alert TEXT colour (bold for prominence) —
 * deliberately NOT --hpk-ink, which would be an uncertified ink-on-tint pair and
 * break AC4's 29-cell mandate; the 3px border + weight + price sub-line already
 * distinguish the banner from a plain alert. --- */
.hpk-client[class*="plugin-order"] .alert.hpk-verdict-banner:not(#payment_details *) {
  display: flex;
  flex-wrap: wrap;
  align-items: center;
  justify-content: space-between;
  gap: var(--hpk-space-3);
  border-inline-start-width: 3px;
}
.hpk-client[class*="plugin-order"] .hpk-verdict-banner__body {
  flex: 1 1 auto;
  min-width: min(100%, 220px);
  margin: 0;
}
.hpk-client[class*="plugin-order"] .hpk-verdict-banner__subject {
  margin: 0;
  font-weight: 600;
}
.hpk-client[class*="plugin-order"] .hpk-verdict-banner__price {
  margin: var(--hpk-space-1) 0 0;
  font-size: .9rem;
  font-weight: 600;
}

/* --- Tally bar: the foot-of-results single-primary action bar. Honest count +
 * running total on the leading edge (aria-live), the sole primary CTA on the
 * trailing edge; the CTA itself reuses the certified hpk-btn-primary/outline. The
 * bar surface reuses the g100 action-surface + --hpk-ink text — the same pairing
 * the card header/footer already ship (no new CONTRAST pair). Wraps on narrow
 * screens. --- */
.hpk-client[class*="plugin-order"] .hpk-tally {
  display: flex;
  flex-wrap: wrap;
  align-items: center;
  justify-content: space-between;
  gap: var(--hpk-space-3);
  margin-top: var(--hpk-space-3);
  padding: var(--hpk-space-3);
  border: 1px solid var(--hpk-border);
  border-radius: var(--hpk-r-md);
  background: var(--hpk-g100);
}
.hpk-client[class*="plugin-order"] .hpk-tally__sum {
  font-weight: 600;
  color: var(--hpk-ink);
}
.hpk-client[class*="plugin-order"] .hpk-tally__cta {
  min-height: 44px;
  max-width: 100%;
  white-space: normal;
  overflow-wrap: anywhere;
  text-align: center;
}
.hpk-client[class*="plugin-order"] .hpk-verdict-cta {
  max-width: 100%;
  white-space: normal;
  overflow-wrap: anywhere;
  text-align: center;
}

/* ==========================================================================
 * HosterPK 13.2 (2026-07-28) - the focused order shell.
 *
 * WHAT THIS SECTION IS. The pack now owns its own chrome via
 * templates/hosterpk_standard/structure.pdt (order_form_controller::getViewDir
 * ($structure=true)). These rules dress that shell: a 60px brand bar over a centred
 * 1320px container with a 980px card column and 70px section rhythm, and NO
 * dashboard sidebar. Applies to Steps 1-4, because the structure is chosen in the
 * shared preAction and the chrome must not change under the customer mid-purchase.
 *
 * WHY THE VALUES ARE PACK-LOCAL CUSTOM PROPERTIES AND NOT BRAND TOKENS. DESIGN.md
 * lists spacing.section-rhythm (70px) in the shared spacing scale, but Epic 13's
 * sealed guardrail scopes the client theme's token source to Story 13.1 only.
 * Promoting these to brand/tokens/tokens.css would mean a 0.6.0 -> 0.7.0 bump, a dual
 * re-pin, a rebuilt client bundle and a new hash on EVERY client-area surface -
 * cross-epic blast radius for values only the order funnel consumes. The divergence
 * is recorded in deferred-work.md for a future token-owning story. The 1320px
 * container is NOT duplicated: --hpk-space-container-xxl already exists in brand.
 *
 * SCOPING. Same doctrine as the rest of this file: every structure-assuming rule is
 * gated behind the live order body marker .hpk-client[class*="plugin-order"]. That
 * (0,2,0) marker is both the Reach-Rule component-tier gate and the specificity that
 * lets these rules out-rank base.css frame-tier element rules and chrome.css's
 * .hpk-client .hpk-main / .hpk-footer (0,2,0) without an override flag. Zero flagged
 * declarations, as everywhere else in this file.
 *
 * BOTH THEMES. The bar inherits .hpk-client .hpk-topbar's --hpk-primary background
 * in BOTH light and dark - cross-app continuity (UJ-7) depends on it, so there is
 * deliberately nothing to author here for dark mode.
 *
 * NOT THIS STORY: the hero-wash page gradient, the 3px card-accent-top and the
 * two-tone title (13.3), and the sticky selection tally (13.4). An unused rule is
 * churn and it muddies 13.6's fidelity attribution.
 * ========================================================================== */
.hpk-client[class*="plugin-order"] {
  --hpk-order-rhythm: 70px;      /* DESIGN.md spacing.section-rhythm - the public site's measured section padding */
  --hpk-order-bar-height: 60px;  /* components.order-shell delta from the client bar's 64px */
  --hpk-order-card-max: 980px;   /* components.order-shell.column - the card column inside the 1320px container */
}

/* --- Icon sprite host. Finding 22b: the sprite root is width=0 height=0, but an
 * INLINE <svg> still generates a line box and pushed the entire page down by a 24px
 * dead strip above the bar. Taking the host out of flow removes the line box while
 * every same-document <use href="#hpk-icon-*"> still resolves. Authored here rather
 * than as an inline attribute because RULE 1 forbids one in an authored .pdt. --- */
.hpk-client[class*="plugin-order"] .hpk-order-spritehost {
  position: absolute;
  width: 0;
  height: 0;
  overflow: hidden;
}

/* --- The 60px brand bar. Height is the only visual delta from the client bar; the
 * colour, shadow, stickiness and white foreground are all inherited so the customer
 * sees one HosterPK across the marketing -> ordering seam. The padding expression
 * aligns the bar's content with the 1320px container on wide viewports and collapses
 * to the plain gutter below it, so the logo is never hard against the screen edge
 * while the card sits 250px inboard. --- */
.hpk-client[class*="plugin-order"] .hpk-order-bar {
  height: auto;
  min-height: var(--hpk-order-bar-height);
  flex-wrap: wrap;
  padding-inline: max(var(--hpk-space-3), calc((100% - var(--hpk-space-container-xxl)) / 2));
}
.hpk-client[class*="plugin-order"] .hpk-order-bar .hpk-topbar-actions {
  flex-wrap: wrap;
  justify-content: flex-end;
}

/* --- The page area. Overrides chrome.css's dashboard density (24px padding) with
 * the funnel's 70px section rhythm. scroll-margin-top follows the shorter bar so an
 * in-page anchor is not hidden behind it. --- */
.hpk-client[class*="plugin-order"] .hpk-order-main {
  /* Float containment restated locally. The .hpk-main contract 700 lines above is
   * the canonical one and it works again now that the comment trap on line 109 is
   * fixed, but the shell's own block formatting context should not depend on a rule
   * that far away in a file three later stories will keep editing. Belt and braces,
   * one declaration. */
  display: flow-root;
  padding-block: var(--hpk-order-rhythm);
  padding-inline: var(--hpk-space-3);
  scroll-margin-top: var(--hpk-order-bar-height);
}

/* --- The two nested widths the spine specifies: a centred 1320px container (the
 * live public-site .container width, so nothing narrows at the seam) with the card
 * column at 980px inside it. flow-root on BOTH: the pack renders floated col-md-*
 * columns and the containment contract keyed on .hpk-main is now two levels up, so
 * each wrapper needs its own block formatting context or the floats leak. --- */
.hpk-client[class*="plugin-order"] .hpk-order-shell {
  display: flow-root;
  max-width: var(--hpk-space-container-xxl);
  margin-inline: auto;
}
.hpk-client[class*="plugin-order"] .hpk-order-column {
  display: flow-root;
  max-width: var(--hpk-order-card-max);
  margin-inline: auto;
}

/* --- Slim footer: one centred copyright line. chrome.css pushes .hpk-footer-copyright
 * to the trailing edge with margin-inline-start:auto, which reads as a stray when it
 * is the only child; centre it instead. --- */
.hpk-client[class*="plugin-order"] .hpk-order-footer {
  justify-content: center;
}
.hpk-client[class*="plugin-order"] .hpk-order-footer .hpk-footer-copyright {
  margin-inline-start: 0;
}

/* ==========================================================================
 * HosterPK 13.3 (2026-07-28) - one card, a usable hero, and the answer in place.
 *
 * WHAT THIS SECTION IS. lookup.pdt no longer nests WidgetClient's .card inside stock
 * .whois inside a .well: it hand-authors ONE #hpk-order-card holding the two-tone
 * section title, the hero search, the extension picker and - new - #hpk-domain-results,
 * so the answer renders where the question was asked. These rules dress that card, give
 * the page its brand texture back as a gradient, stack the hero below 760px, and carry
 * the field-level error the story moved beside the input.
 *
 * WHY THE VALUES ARE PACK-LOCAL CUSTOM PROPERTIES. Same reason 13.2 gave for
 * --hpk-order-rhythm: DESIGN.md:358 specifies hero-wash in the shared palette, but
 * Epic 13's sealed guardrail scopes the client theme's token source to Story 13.1 only.
 * Promoting it to brand/tokens/tokens.css would force a 0.6.0 -> 0.7.0 bump, a dual
 * re-pin, a rebuilt client bundle and a new hash on EVERY client-area surface -
 * cross-epic blast radius for a value only the order funnel consumes. Recorded in
 * deferred-work.md beside 13.2's spacing.section-rhythm entry.
 * --hpk-section-title-font-size / -font-weight are the OPPOSITE case: Story 13.1
 * already shipped them in brand, inert, for exactly this story. They are CONSUMED here.
 * No brand file is opened by 13.3.
 *
 * SCOPING. Same doctrine as the rest of this file: every rule is gated behind the live
 * order body marker .hpk-client[class*="plugin-order"]. That (0,2,0) marker is both the
 * Reach-Rule component-tier gate and the specificity that lets these rules out-rank
 * base.css frame-tier element rules - which is what makes the section title 700 where
 * the frame-tier .hpk-client h2 (0,1,1) says 600. Zero flagged declarations.
 *
 * BOTH THEMES. Three dark deltas, all reusing already-certified pairs: the wash goes
 * .07 -> .16 (DESIGN.md:358), the title accent goes --hpk-primary -> #A9C5FF (the SAME
 * pair as .intent-segment__control:checked, measured 7.52:1 in 12.5), and the field
 * error rides --hpk-danger-text, which the token file already flips. No net-new
 * gen-contrast cell: the matrix stays at 29/29.
 *
 * THE CARD IS A NAMED EXCEPTION, NOT A NEW RULE. DESIGN.md's card law is borderless +
 * shadow-only; the 3px primary top accent is the ONE sanctioned amendment
 * (DESIGN.md:418, {components.card-accent-top}), scoped here to #hpk-order-card and to
 * nothing else. It is never attached to .card or .hpk-card.
 *
 * NOT THIS STORY: the results TABLE internals and the sticky tally (13.4); the trust
 * band, example prompts, the escape-hatch button promotion and the compact mobile
 * stepper (13.5). An unused rule is churn and it muddies 13.6's fidelity attribution.
 * ========================================================================== */
.hpk-client[class*="plugin-order"] {
  --hpk-order-hero-wash: rgba(20, 87, 230, .07);   /* DESIGN.md:358 hero-wash, light */
  --hpk-order-hero-wash-end: rgba(20, 87, 230, 0); /* explicit same-hue zero-alpha stop: fading to `transparent` greys the ramp in some engines */
  --hpk-order-hero-depth: 420px;                   /* {components.hero-wash} - "the top ~420px of the page" */
}
[data-theme="dark"] .hpk-client[class*="plugin-order"] {
  --hpk-order-hero-wash: rgba(20, 87, 230, .16);   /* DESIGN.md:358 hero-wash, dark */
}

/* --- Hero wash. ON THE PAGE, NEVER ON A CARD (DESIGN.md:446, EXPERIENCE.md:223) -
 * putting it on the card would re-break the borderless-shadow-only rule that
 * card-accent-top was granted a narrow, named exception to. One exception, not two.
 * .hpk-order-main already owns this surface's padding and background box (13.2), so the
 * gradient layers over the inherited page fill and needs no extra element. It replaces
 * the retired .whois globe watermark. --- */
.hpk-client[class*="plugin-order"] .hpk-order-main {
  background-image: linear-gradient(180deg, var(--hpk-order-hero-wash) 0, var(--hpk-order-hero-wash-end) var(--hpk-order-hero-depth));
  background-repeat: no-repeat;
}

/* --- THE ONE CARD. Hand-authored in lookup.pdt because WidgetClient cannot coexist
 * with AC6: create() ALWAYS emits a visible .card-header (widget_client.php:113-121)
 * which order.css:291-299 paints g100 with a border-bottom, so keeping it would mean a
 * second title and an extra surface in the story whose whole purpose is removing
 * surfaces. Dropping .card/.card-blesta with it also detaches this surface from
 * order.css:284-289 - which is what makes the composition below authorable cleanly,
 * because that rule gives .card a 1px border on ALL FOUR sides and NO shadow, the exact
 * inverse of the brand rule. Clear the box first, then add the one sanctioned edge. --- */
.hpk-client[class*="plugin-order"] .hpk-order-card {
  border: 0;
  border-top: 3px solid var(--hpk-primary);
  border-radius: var(--hpk-r-lg);
  padding: var(--hpk-space-card-padding);
  margin-bottom: var(--hpk-space-4);
  background: var(--hpk-surface);
  box-shadow: var(--hpk-shadow);
}

/* --- Two-tone section title ({components.two-tone-title}): 32px Urbanist 700, plain
 * half in ink, emphasis half in primary. The size/weight tokens are 13.1's, shipped
 * inert for this story; line-height restates the shared heading ramp so the composed
 * 38.4px is explicit rather than inherited-by-luck. The frame-tier .hpk-client h2 rule
 * supplies 600, so the scoped marker's specificity is what makes 700 land. --- */
/* The three fallbacks are LOAD-BEARING, and this is the one place in this file that
 * needs them. --hpk-section-title-font-size / -font-weight were added by Story 13.1;
 * every other token this file consumes predates it. If order.css is ever served next to
 * a pre-13.1 client bundle (a stale deploy, a half-synced local stack - MEASURED on
 * exactly that pairing while closing 13.3's Steps 2-4 lane), those two var() lookups
 * resolve to nothing, the declarations become invalid at computed-value time, and the
 * property INHERITS - it does NOT fall back to the frame-tier h2 rule. The headline then
 * renders at 16px/400 body text, which is WORSE than the 32px/600 a plain <h2> would
 * have given. Measured on the skewed pairing: 16px/400 vs the plain h2's 32px/600.
 * The fallback values are DESIGN.md's pinned 32px/700 + the 1.2 heading ramp, so this
 * degrades to the correct design rather than to an accident. */
.hpk-client[class*="plugin-order"] .hpk-order-section-title {
  margin-bottom: var(--hpk-space-2);
  font-size: var(--hpk-section-title-font-size, 2rem);
  font-weight: var(--hpk-section-title-font-weight, 700);
  line-height: var(--hpk-heading-line-height, 1.2);
  color: var(--hpk-ink);
}
.hpk-client[class*="plugin-order"] .hpk-order-section-title .hpk-title-accent {
  color: var(--hpk-primary);
}
/* Dark: primary on surface-dark is illegible; #A9C5FF is the SAME certified pair the
 * intent segment and the selected TLD chip already use (measured 7.52:1 in 12.5), so
 * this adds no gen-contrast cell. */
[data-theme="dark"] .hpk-client[class*="plugin-order"] .hpk-order-section-title .hpk-title-accent {
  color: #A9C5FF;
}
/* The lede deliberately sets no colour: it inherits the certified body text pair. */
.hpk-client[class*="plugin-order"] .hpk-order-lede {
  margin-bottom: var(--hpk-space-4);
}

/* --- Hero search, 56px input ({components.hero-search}). 12.5 shipped 48px before the
 * component was specified; the sealed spine now names 56px, and this is the story that
 * owns hero-search CSS, so the delta is taken here rather than left for nobody. --- */
.hpk-client[class*="plugin-order"] .hpk-search-group input,
.hpk-client[class*="plugin-order"] .hpk-search-group .hpk-input-group__suffix .hpk-btn {
  min-height: 56px;
}

/* --- THE PHONE STACK - the highest-value fix on the surface. #domain measured
 * 34 x 48px at a 386px viewport while the CTA held its intrinsic 159px: the input
 * carries min-width:0 (components.css:2876) so it absorbs ALL of the flex shrink, while
 * the CTA's nowrap label sets a min-content floor it never goes below. Below the 760px
 * phone band - the same band as {components.table-card-reflow} and EXPERIENCE.md:300,
 * NOT a looser ~640px - both go full-width with the input above the button, and the
 * corners each side squared for the joined desktop layout are given back. --- */
@media (max-width: 760px) {
  .hpk-client[class*="plugin-order"] .hpk-search-group {
    flex-wrap: wrap;
    row-gap: var(--hpk-space-2);
  }
  .hpk-client[class*="plugin-order"] .hpk-search-group input {
    flex: 1 1 100%;
    border-start-end-radius: var(--hpk-r-sm);
    border-end-end-radius: var(--hpk-r-sm);
  }
  .hpk-client[class*="plugin-order"] .hpk-search-group .hpk-input-group__suffix {
    flex: 1 1 100%;
  }
  .hpk-client[class*="plugin-order"] .hpk-search-group .hpk-input-group__suffix .hpk-btn {
    width: 100%;
    border-start-start-radius: var(--hpk-r-md);
    border-end-start-radius: var(--hpk-r-md);
  }
}

/* --- AC2, second half: no horizontal PAGE overflow at any band. MEASURED, not
 * assumed. At a true 390px viewport the document scrolled 446px wide (the baseline at
 * 95740fa8 scrolled 467px, so this is inherited and 13.3 already narrowed it) — and
 * hiding every .sr-only element brought it to exactly 390px in both.
 *
 * The mechanism: .sr-only is `position: absolute` with no offsets, so it stays at its
 * static position — and several of them sit inside the results table, which is 572px
 * wide inside a 318px .hpk-table-wrap. The wrapper scrolls correctly (overflow-x: auto,
 * scrollWidth 572 vs clientWidth 318), but an absolutely-positioned descendant resolves
 * against the nearest POSITIONED ancestor, and there was none — so those 1px spans
 * escaped the scroll container and extended the DOCUMENT's scrollable area instead.
 *
 * Making the wrapper a containing block is the whole fix: the spans now contribute to
 * the scroll container that was already scrolling. Zero visual change (no offsets are
 * introduced), the table still scrolls, and the client theme's .sr-only definition —
 * which is out of bounds for this story — is untouched. --- */
.hpk-client[class*="plugin-order"] .hpk-table-wrap {
  position: relative;
}

/* --- The field-level error (AC5): ONE message, in one voice, beside the field. The
 * carrier ALWAYS renders - hx-select-oob needs a target in every response and
 * config_preconfig.pdt reads data-hpk-invalid out of $content - so the visual treatment
 * hangs off the attribute, never off emptiness.
 *
 * COLOUR AND THE 29-CELL MATRIX. --hpk-danger-text is certified as text-on-tint
 * (#B5303A on #FDECEC light, #F58A90 on the .18 danger wash dark). Here it sits on
 * --hpk-surface, which is LIGHTER than the light tint and DARKER than the dark wash - so
 * the composited ratio is strictly greater than the certified cell in BOTH themes. No
 * net-new pair, matrix stays 29/29. --- */
.hpk-client[class*="plugin-order"] .hpk-field-error {
  margin: var(--hpk-space-1) 0 0;
  font-size: var(--hpk-small-font-size);
}
.hpk-client[class*="plugin-order"] .hpk-field-error[data-hpk-invalid="1"] {
  color: var(--hpk-danger-text);
  font-weight: 600;
}
/* DESIGN.md {components.input}: "Error: border -> danger". Supplementary only - the
 * message and aria-invalid carry the meaning for anyone who cannot see the border. */
.hpk-client[class*="plugin-order"] #domain[aria-invalid="true"] {
  border-color: var(--hpk-danger);
}

/* --- The results region: the answer, inside the card, directly under the question.
 * It is the hx-select swap target, so it must be a plain, stable box - no padding or
 * border that a swapped-in copy could disagree about. The heading is the focus landing
 * site after a swap (tabindex="-1" in the markup, so it never appears in the tab order).
 * Results TABLE internals are 13.4's. --- */
.hpk-client[class*="plugin-order"] .hpk-domain-results[data-hpk-empty="0"] {
  margin-top: var(--hpk-space-4);
}
.hpk-client[class*="plugin-order"] .hpk-results-heading {
  margin-bottom: var(--hpk-space-3);
}
/* Skeleton rows while a search is in flight ({components.loading-skeleton}). The
 * .hpk-skeleton primitive ships in the bundle and its shimmer + dark variant are already
 * provided at the head of this file for loadAllTlds; this only shapes the rows so they
 * mask the eventual 4-column result shape instead of collapsing the card. */
.hpk-client[class*="plugin-order"] .hpk-results-skeleton .hpk-skeleton {
  display: block;
  min-height: 1rem;
}

/* ==========================================================================
 * HosterPK 13.4 (2026-07-29) - the results table, the sticky tally and the
 * honest-data surfaces.
 *
 * WHAT THIS SECTION IS. 13.3 collapsed the surface to one card but deliberately did
 * not touch the thing inside it the customer actually reads. This section dresses
 * that: the results table's new Price column and fixed action cell, the muted taken
 * row, the tally's promotion from a static bar to a sticky/fixed one, and the
 * pricing card's disclosure + empty/error state.
 *
 * WHY THESE VALUES ARE PACK-LOCAL. Every one of them describes the ORDER STEP-1
 * composition specifically - a results table that is only rendered here, a tally
 * that only exists on results lanes, and a disclosure over a pricing table this pack
 * owns. None of it generalises to the client theme, and the client bundle is out of
 * bounds for this story. The one thing that WOULD have generalised - the phone card
 * reflow - is NOT authored here at all: {components.table-card-reflow} already ships
 * in the bundle at components.css:507-571, and 13.4's entire mobile fix is opting the
 * markup in with one class and four data-label attributes.
 *
 * SCOPING DOCTRINE. Every rule is gated on .hpk-client[class*="plugin-order"], and
 * every results rule additionally rides a RESULTS-SPECIFIC hook
 * (.hpk-results-price, .hpk-results-actions, .hpk-results-row--taken, .hpk-tally).
 * That second gate is load-bearing now that TWO tables on this page carry
 * `hpk-table`: a rule keyed on .hpk-table alone would silently restyle the pricing
 * table as well.
 *
 * BOTH THEMES. Colour comes only from tokens that ship a dark value
 * (--hpk-ink / --hpk-muted / --hpk-surface / --hpk-border), so every rule here
 * follows the theme without a single [data-theme] override. Two measurements worth
 * recording: --hpk-muted on --hpk-g100 (the price-card header the currency marker
 * sits on) is 5.14:1 light and 4.73:1 dark, and --hpk-muted on --hpk-surface (the
 * taken row, the tally reassurance line) is the pairing the bundle's .hpk-empty__body
 * already ships. No token is touched, so gen-contrast stays 29/29 with no net-new
 * cell.
 *
 * NOT THIS STORY. The chip framing copy, the trust band, the escape hatch's
 * promotion to a secondary button, the heading-outline repair, the compact mobile
 * stepper and the Steps 2-4 rail treatment are all 13.5's. The both-themes x
 * all-lanes fidelity, axe and responsive gate is 13.6's. Nothing here reaches
 * outside Step 1: the only selectors that can match on another order step are
 * .hpk-js-only (which no other step's markup emits), .hpk-no-js-price-hint (same),
 * and the retired currency rules above. The one rule that now matches the BODY -
 * the phone clearance at the foot of this section - is gated on :has(.hpk-tally),
 * and .hpk-tally is emitted by lookup.pdt alone.
 * ========================================================================== */

/* --- Price as its own column (finding 10). The amount is the row's primary number,
 * so it takes --hpk-ink and 600; the term drops to small/muted underneath it. Both
 * are display:block so the two stack in the desktop cell AND inside the phone
 * mini-card without a second rule. nowrap on the amount stops a formatted total
 * breaking across "Rs." and its digits.
 *
 * The review patch's two wrappers (.hpk-results-price__known / __unknown) are styled
 * NOWHERE ON PURPOSE. They exist so the cell can switch between a formatted price and
 * the honest em-dash in either direction, and they are switched with `.hidden` - which
 * is (0,3,0) at the head of this file. Give either wrapper a `display` here and it
 * would out-rank that (same specificity, later in the file) and a "hidden" branch
 * would render anyway. Style their CHILDREN, never them. --- */
.hpk-client[class*="plugin-order"] .hpk-results-price__amount {
  display: block;
  color: var(--hpk-ink);
  font-weight: 600;
  white-space: nowrap;
}
.hpk-client[class*="plugin-order"] .hpk-results-price__term {
  display: block;
  font-size: var(--hpk-small-font-size);
  color: var(--hpk-muted);
}

/* --- The no-JS price-truth line. The price cell tracks a term change only while this
 * page's script is running; without it the cell keeps the server-rendered term's price
 * while the select already carries another pricing_id. One quiet line says so, and the
 * 12.5 hpk-js-ready idiom removes it the moment hpkInitResults() marks the results form
 * ready - so the enhanced lane never shows it. The (0,4,0) hide out-ranks the (0,3,0)
 * base rule. --- */
.hpk-client[class*="plugin-order"] .hpk-no-js-price-hint {
  margin: 0 0 var(--hpk-space-2);
  font-size: var(--hpk-small-font-size);
  color: var(--hpk-muted);
}
.hpk-client[class*="plugin-order"] .hpk-js-ready .hpk-no-js-price-hint {
  display: none;
}

/* --- The action cell holds still (finding 11). "+ Add" and "Remove" are different
 * widths, so a shrink-to-fit column re-measured on every toggle and shunted Domain /
 * Status / Price / Term sideways. Fixing the COLUMN width on the th/td pair and
 * giving the toggle a min-width wider than its longer label makes the delta 0px. At
 * <=760px the reflow turns these cells into blocks, so the width is inert there and
 * the mini-card is unaffected. --- */
.hpk-client[class*="plugin-order"] .hpk-results-actions {
  width: 9.5rem;
  text-align: end;
}
.hpk-client[class*="plugin-order"] .hpk-results-actions .hpk-add-toggle {
  min-width: 8.5rem;
}

/* --- The muted taken row. 12.2 specified "muted taken rows" but no tr class and no
 * rule ever landed, so this authors both halves. The DOMAIN NAME keeps --hpk-ink -
 * muting the name would make the one piece of information the customer is scanning
 * for the hardest thing to read. The (0,3,1) scoped selector out-ranks the bundle's
 * .hpk-client .hpk-table td (0,2,1). --- */
.hpk-client[class*="plugin-order"] .hpk-results-row--taken td {
  color: var(--hpk-muted);
}
.hpk-client[class*="plugin-order"] .hpk-results-row--taken td:first-child {
  color: var(--hpk-ink);
}

/* --- The sticky tally ({components.selection-tally}, finding 16: "check all 15
 * extensions and the running total plus the Continue button scroll out of view").
 * Sticky to the CARD on desktop; the media query below makes it fixed to the
 * VIEWPORT on phone.
 *
 * TWO DELIBERATE DELTAS FROM THE v2 MOCK, both recorded:
 *  1. No negative BOTTOM margin and no bottom radius. In the mock the tally is the
 *     card's last child; in our composition the escape hatch follows it, so bleeding
 *     to the card's bottom edge would pull the escape hatch up underneath. We take
 *     the horizontal full-bleed only, expressed against the card-padding TOKEN
 *     rather than the mock's hardcoded 34px, so the two can never drift apart.
 *  2. The bar moves off --hpk-g100 onto --hpk-surface. A g100 bar is translucent
 *     enough in dark mode to let rows show through as they scroll under it; surface
 *     is opaque. Both pairings are already certified against --hpk-ink, so this adds
 *     no contrast cell either way.
 *
 * STICKY IS FRAGILE BY DESIGN: it dies inside any ancestor with overflow other than
 * visible, and is re-anchored by any ancestor with transform/filter/perspective.
 * The chain here is .hpk-tally -> #configure_domain -> #hpk-domain-results ->
 * #hpk-order-card -> .hpk-order-column -> .hpk-order-shell -> .hpk-order-main and
 * none of them sets any of those. Do NOT reach for overflow:hidden on the card to
 * tidy the full-bleed - it would silently kill this rule AND re-anchor the phone
 * lane's position:fixed. --- */
.hpk-client[class*="plugin-order"] .hpk-tally {
  position: sticky;
  bottom: 0;
  z-index: 5;
  margin-inline: calc(-1 * var(--hpk-space-card-padding, 1.25rem));
  padding-inline: var(--hpk-space-card-padding, 1.25rem);
  border: 0;
  border-top: 1px solid var(--hpk-border);
  border-radius: 0;
  background: var(--hpk-surface);
  box-shadow: 0 -4px 14px rgba(0, 0, 0, .05);
}
/* The summary block: count + total on top (aria-live lives on the sum span itself,
 * never on this wrapper - the reassurance line must not re-announce on every
 * selection), the quiet "Secure checkout" line beneath. min-width:0 lets the block
 * shrink instead of forcing the flex row to overflow. */
.hpk-client[class*="plugin-order"] .hpk-tally__summary {
  display: flex;
  flex-direction: column;
  gap: var(--hpk-space-1);
  min-width: 0;
}
.hpk-client[class*="plugin-order"] .hpk-tally__reassurance {
  font-size: var(--hpk-small-font-size);
  font-weight: 400;
  color: var(--hpk-muted);
}

/* --- The pricing disclosure. The trigger is JS-ONLY: with no JS the body stays
 * server-rendered expanded and a button that could never collapse it must not be
 * visible at all (that is finding 9 - a control that cannot act - in a new place).
 * This is the exact inversion of the 12.5 hpk-js-ready idiom above: hidden by
 * default, revealed once JS marks the card ready. Both this trigger and the retry
 * control clear the 44px touch-target floor .hpk-add-toggle and .hpk-tld-chip
 * already carry. --- */
.hpk-client[class*="plugin-order"] .hpk-js-only {
  display: none;
}
.hpk-client[class*="plugin-order"] .hpk-price-card.hpk-js-ready .hpk-js-only {
  display: inline-flex;
}
.hpk-client[class*="plugin-order"] #hpk-pricing-toggle,
.hpk-client[class*="plugin-order"] #hpk-pricing-retry {
  min-height: 44px;
}
/* The empty/error block. Always in the DOM (JS only flips .hidden on it), so the
 * no-JS lane keeps it; the retry form is a real POST and must not inherit a form
 * margin that pushes it away from its own block. */
.hpk-client[class*="plugin-order"] .hpk-pricing-state {
  padding-block: var(--hpk-space-4);
}
.hpk-client[class*="plugin-order"] .hpk-pricing-state form {
  margin: 0;
}

/* --- Phone: the tally leaves the flow, so whatever ends the page would sit underneath
 * it. The mock compensates with page-level bottom padding, and after the 13.4 review
 * so do we - on the BODY, not on the card.
 *
 * THREE REVIEW PATCHES ARE ENCODED HERE, and each one replaces something that looked
 * fine at 390px and was wrong in general:
 *
 *  1. THE CLEARANCE BELONGS TO THE DOCUMENT, NOT THE CARD. The bar is fixed to the
 *     VIEWPORT, so it hangs over everything at every scroll position - including the
 *     pricing card that FOLLOWS #hpk-order-card and the theme footer below that. Card
 *     padding cleared the escape hatch and nothing else, so the last pricing row, the
 *     retry control or a footer link could still sit under the checkout bar at the end
 *     of the scroll. .hpk-client IS the body element (structure.pdt:164), so gating the
 *     padding on `:has(.hpk-tally)` puts the clearance at the END OF THE DOCUMENT and
 *     still only on lanes that actually render a tally.
 *
 *  2. THE CLEARANCE FOLLOWS THE BAR'S REAL HEIGHT. 9rem was a measurement of one lane
 *     at one width: a long subject-domain CTA, a narrower viewport or text zoom all
 *     make the bar taller, and the compensation silently stopped compensating. JS
 *     publishes the measured height as --hpk-tally-clearance (hpkSyncTallyClearance,
 *     re-run per swap, per tally recompute and on resize), and this adds the gap and
 *     the inset on top. The fallback keeps the NO-JS lane safe and is in `em` so it
 *     tracks text zoom by itself: 8.5em is ~2.4x the two-line bar measured at 390px.
 *
 *  3. THE HOME INDICATOR IS NOT A PLACE TO PUT A BUTTON. env(safe-area-inset-bottom)
 *     is added to BOTH the bar's own bottom padding and the document clearance, so on
 *     an inset device the CTA sits above the indicator rather than under it. On every
 *     other device the function resolves to 0px and nothing changes.
 *
 * :has() is the right tool for exactly one reason that matters: it works on the NO-JS
 * lane, which a JS class-toggle would not, and it re-evaluates by itself after an HTMX
 * swap. An engine without :has() ignores the rule and degrades to "the bar overlaps the
 * last element" rather than breaking the page, which is why it sits in its own rule and
 * cannot invalidate its neighbours. --- */
@media (max-width: 760px) {
  .hpk-client[class*="plugin-order"] .hpk-tally {
    position: fixed;
    inset: auto 0 0 0;
    margin: 0;
    padding: var(--hpk-space-2) var(--hpk-space-3);
    padding-bottom: calc(var(--hpk-space-2) + env(safe-area-inset-bottom, 0px));
    border-radius: 0;
    z-index: 20;
  }
  .hpk-client[class*="plugin-order"]:has(.hpk-tally) {
    padding-bottom: calc(
      var(--hpk-tally-clearance, 8.5em) + var(--hpk-space-3) + env(safe-area-inset-bottom, 0px)
    );
  }
}

/* ==========================================================================
 * HosterPK 13.5 (2026-07-29) - the conversion layer, the semantics repair and
 * the shared order-flow stepper.
 *
 * WHAT THIS SECTION IS. 13.1 corrected the ramp, 13.2 gave the funnel a shell, 13.3
 * collapsed three surfaces to one card and 13.4 made the answer inside it legible.
 * Every one of those treated the page as a surface with defects. This section is the
 * first that dresses it as a STOREFRONT - the chip framing line, the trust band, the
 * example prompts and a real escape-hatch affordance - and at the same time repairs
 * the semantics a screen-reader user actually experiences: the heading the search
 * region never had, and a stepper that told every lane but one that no step was
 * current.
 *
 * REACH. This is the one 13.5 block that deliberately reaches OUTSIDE Step 1.
 * order.css is a single stylesheet for the whole pack, so every .hpk-order-steps*
 * rule below lands on main, main/packages, config, cart, checkout and signup as well.
 * That is the point - the stepper defect is per-lane and six of the seven lanes had
 * it - but it is also why AC9 renders and asserts all seven rather than trusting the
 * Step-1 harness. Every OTHER rule in this section rides a Step-1-only hook.
 *
 * BOTH THEMES / TRAP 8. This story writes more secondary text than any other in the
 * epic, and --hpk-muted is a DOCUMENTED dark-mode trap (tokens.css:166-170: dark muted
 * is 55% white and fails 4.5:1 on the dark neutral surface; dark neutral text MUST be
 * --hpk-text at 70% white). So NO new secondary-text rule in this section uses
 * --hpk-muted. Every one uses --hpk-text, whose light #6B6B7E on --hpk-g100 #F9FAFB
 * measures 4.99:1 and whose dark 70%-white on the composited g100 measures ~7.5:1.
 * gen-contrast.sh stays at 29/29 with NO net-new cell: its matrix is state colours,
 * links, the intent segment and the chip, and adding cells for these is exactly the
 * churn 13.4 refused. A green matrix is not evidence about text you did not put in it,
 * which is why these pairs are measured in the browser and recorded in the story.
 *
 * RULE 1 / RULE 2. No inline style= is introduced anywhere (the compact progress bar
 * is driven by a data-hpk-step attribute and the four width rules below, never by a
 * style attribute), and this file stays at ZERO flagged declarations.
 * ========================================================================== */

/* --- A. The shared order-flow stepper. All 7 pack views, one block, D4.
 *
 * The wrapper is a <nav aria-label> now instead of a bare <div class="col-md-12">.
 * MEASURED before promoting it: the client bundle carries no bare `nav` element
 * selector at all, so the element change inherits nothing and computes identically -
 * every layout rule that reaches it (.col-md-12, the float grid, flow-root) is
 * class-keyed. --- */

/* A1. Unreachable steps (D3, D5). Reachability is POSITIONAL, because a cart-state read
 * is a controller read this epic may not make - and the position that matters is
 * current + 2, not current + 1.
 *
 * REVISED after code review (2026-07-29). The first cut marked every step after the
 * current one inert, and that contradicted the page itself: cart.pdt's rail announced
 * Checkout unavailable while cart.pdt's own primary CTA was "Checkout" to the SAME URL.
 * Every step page's primary action goes exactly one step forward, so current + 1 is
 * genuinely reachable. Prior steps stay live too, because going back is legitimate.
 *
 * This rule is only ONE of four parts, and on its own it is not enough. The bundle's
 * disabled-control contract (components.css:189-197) says it outright: pointer-events
 * "blocks the mouse only, never keyboard activation". So the markup carries
 * aria-disabled="true" for the state and tabindex="-1" to leave the tab order, and a
 * delegated click handler calls preventDefault() for the activation neither of those
 * stops. The other branch the contract sanctions - dropping href - is unavailable:
 * three of the four Html->safe( calls in this block ARE step hrefs and six of the
 * seven files sit at exactly their RULE 8 floor (Trap 1).
 *
 * HosterPK 13.7: the `color` and `text-decoration` declarations that stood here are
 * DELETED and the rule keeps only its load-bearing half. Both were written for the stock
 * markup, where the <a> held its own text; in the marker rail the colour lives on the
 * .hpk-order-step__marker / __label spans, which are descendants and therefore win over
 * anything inherited from the anchor no matter what it says. Keeping them would have
 * been worse than redundant: it would have implied a colour delta between the inert
 * steps and the live current+1 step, and D3 is explicit that `future` looks IDENTICAL
 * whether or not it is reachable — the difference is behaviour, never appearance. */
.hpk-client[class*="plugin-order"] .hpk-order-steps a[aria-disabled="true"] {
  pointer-events: none;
  cursor: default;
}

/* HosterPK 13.7 (Trap 10): `.card-steps p { color }` — 13.5's AA fix for the italic step
 * descriptions — is DELETED. The descriptions are retired with the chevrons: the mock's
 * rail is label-only, and the marker rail renders Main.steps.step_N_description AS the
 * label (which is what DESIGN.md's compact spec already calls "{step label}"). No lane
 * emits a <p> inside a stepper any more. The keys are NOT retired — the compact variant
 * still renders one, and a 23-locale key removal is churn the upgrade check notices. */

/* A3. The compact variant ({components.order-stepper}.compact, D9).
 *
 * Below 760px the rail is REPLACED, not hidden. 760 is not a new breakpoint: it is the
 * one the bundle's .hpk-table card reflow and 13.4's fixed tally already use. */
.hpk-client[class*="plugin-order"] .hpk-order-steps-compact {
  display: none;
  margin-bottom: var(--hpk-space-3);
}
.hpk-client[class*="plugin-order"] .hpk-order-steps-compact__label {
  display: flex;
  align-items: baseline;
  justify-content: space-between;
  gap: var(--hpk-space-2);
  margin: 0 0 var(--hpk-space-2);
}
.hpk-client[class*="plugin-order"] .hpk-order-steps-compact__label b {
  font-weight: 600;
  color: var(--hpk-ink);
}
.hpk-client[class*="plugin-order"] .hpk-order-steps-compact__label span {
  flex: none;
  font-size: var(--hpk-small-font-size);
  color: var(--hpk-text);
}
/* The bar is aria-hidden and carries no information the label does not already state
 * in words ("Choose a domain - Step 1 of 4"), so it is decorative: no 1.4.11 contrast
 * obligation and no gen-contrast cell. */
.hpk-client[class*="plugin-order"] .hpk-order-steps-compact__bar {
  height: 5px;
  border-radius: var(--hpk-r-pill);
  background: var(--hpk-g300);
  overflow: hidden;
}
.hpk-client[class*="plugin-order"] .hpk-order-steps-compact__bar span {
  display: block;
  height: 100%;
  border-radius: inherit;
  background: var(--hpk-primary);
  /* 13.5 review round 2: an EXPLICIT default. Every width below is keyed on
   * data-hpk-step, so a typo'd or absent attribute would leave the fill with no width
   * rule at all. Zero is the honest default — it under-claims progress rather than
   * inventing it, and the label directly above still reads "Step N of 4" from a copy
   * key, so a broken attribute stays visible rather than silently drawing a plausible
   * bar. The emitted values are separately asserted on all 7 views by
   * render_stepper.php and browser_steps.js, which is what stops it happening. */
  width: 0;
}
/* RULE 1: the fill width is driven by the server-rendered data-hpk-step attribute, so
 * no view needs an inline style= to say how far along it is. */
.hpk-client[class*="plugin-order"] .hpk-order-steps-wrap[data-hpk-step="1"] .hpk-order-steps-compact__bar span { width: 25%; }
.hpk-client[class*="plugin-order"] .hpk-order-steps-wrap[data-hpk-step="2"] .hpk-order-steps-compact__bar span { width: 50%; }
.hpk-client[class*="plugin-order"] .hpk-order-steps-wrap[data-hpk-step="3"] .hpk-order-steps-compact__bar span { width: 75%; }
.hpk-client[class*="plugin-order"] .hpk-order-steps-wrap[data-hpk-step="4"] .hpk-order-steps-compact__bar span { width: 100%; }

@media (max-width: 760px) {
  .hpk-client[class*="plugin-order"] .hpk-order-steps { display: none; }
  .hpk-client[class*="plugin-order"] .hpk-order-steps-compact { display: block; }
  /* TRAP 3. Both rules above are (0,3,0) and sit LATER in the file than the scoped
   * `.hidden` rule, which is also (0,3,0) - so a .hidden applied to either element
   * would lose and the element would stay visible with the class measurably on it.
   * Restate .hidden here at (0,4,0) so it can still win. Nothing toggles .hidden on
   * the stepper today; this exists so that the first thing that does cannot fail
   * silently, which is the exact shape of the defect 13.3 was written to remove. */
  .hpk-client[class*="plugin-order"] .hpk-order-steps.hidden,
  .hpk-client[class*="plugin-order"] .hpk-order-steps-compact.hidden { display: none; }
}

/* --- B. The chip framing line (AC1, D7b) and the reversible disclosure.
 *
 * The line answers the question the pre-checked chips otherwise provoke — "…is .com
 * not available here?" — and it sits inside fieldset.tlds so Transfer's wholesale
 * picker hide takes it along with the chips it frames.
 *
 * Two elements, not one string with a span around a substring: the lead and the
 * qualifier are separate copy keys so a translator can reorder them, and so the
 * colour split needs no markup authored around part of a sentence. The qualifier is
 * --hpk-text and NOT --hpk-muted (Trap 8). --- */
.hpk-client[class*="plugin-order"] .hpk-tld-frame {
  margin: 0 0 var(--hpk-space-2);
  font-size: var(--hpk-small-font-size);
}
.hpk-client[class*="plugin-order"] .hpk-tld-frame__lead {
  font-weight: 600;
  color: var(--hpk-ink);
}
.hpk-client[class*="plugin-order"] .hpk-tld-frame__qualifier {
  color: var(--hpk-text);
}

/* FR43: the disclosure trigger is a real touch target in BOTH its states. It measured
 * 175x30 at baseline, and the label length changes when it flips to "Fewer extensions"
 * while the height must not. Same floor #hpk-pricing-toggle, #hpk-pricing-retry,
 * .hpk-add-toggle and .hpk-tld-chip already carry. */
.hpk-client[class*="plugin-order"] .show_more {
  min-height: 44px;
}

/* --- C. Example prompts and the escape hatch (AC3, D8).
 *
 * The prompts are the cheapest thing on this page: three words that turn "what do I
 * type?" into "oh, like that". They are also the easiest thing to get wrong, in two
 * ways this block is built to prevent.
 *
 * ONE: they must not exist without JS. A button that fills a field is inert with
 * scripting off, and 13.4 established that nothing focusable may exist that cannot
 * act. .hpk-js-only (declared in the 13.4 section) hides them by default; the reveal
 * below is gated on the form's own hpk-js-ready marker.
 *
 * TWO — TRAP 3, and this is the one that would have shipped silently. The reveal
 * carries an id, so it is (1,3,0), while the scoped `.hidden` rule is (0,3,0). Without
 * the restatement, hpkSyncIntent()'s Transfer hide would add .hidden to the prompts and
 * they would STAY VISIBLE with the class measurably on the element — finding 8's exact
 * contradiction (transfer copy beside register affordances), invisible to every static
 * gate and to any test that asserts on classList instead of geometry. That is why the
 * story asserts hides with getClientRects().length === 0. --- */
.hpk-client[class*="plugin-order"] #domain-lookup-form.hpk-js-ready .hpk-example-prompts {
  display: block;
  margin: var(--hpk-space-2) 0 0;
}
.hpk-client[class*="plugin-order"] #domain-lookup-form.hpk-js-ready .hpk-example-prompts.hidden {
  display: none;
}

/* The grouped-extension disclosure trigger is JS-ONLY for the same reason (13.5 review,
 * HIGH). Without JS it could not open anything, and the container it controls is
 * server-rendered `.hidden` — so a no-JS customer saw 5 chips out of a 65-extension
 * catalogue with no way to reach the other 60. The trigger now never renders on that
 * lane, and a <noscript> rule in lookup.pdt opens the container instead. Same
 * `.hidden` restatement for the same Trap-3 reason as the prompts above. */
.hpk-client[class*="plugin-order"] #domain-lookup-form.hpk-js-ready .show_more.hpk-js-only {
  display: inline-flex;
}
.hpk-client[class*="plugin-order"] #domain-lookup-form.hpk-js-ready .show_more.hpk-js-only.hidden {
  display: none;
}
.hpk-client[class*="plugin-order"] .hpk-example-prompts__lead {
  margin-inline-end: var(--hpk-space-1);
  font-size: var(--hpk-small-font-size);
  color: var(--hpk-text);
}
/* FR43: a real touch target. The prompt reads as a quiet suggestion, not a button —
 * hence the ghost-ish treatment — but it is 44px tall like every other control on this
 * surface, because "looks quiet" and "is hard to tap" are different decisions. */
.hpk-client[class*="plugin-order"] .hpk-example-prompt {
  min-height: 44px;
  padding: 0 var(--hpk-space-2);
  margin: 0 var(--hpk-space-1) var(--hpk-space-1) 0;
  border: 0;
  background: transparent;
  color: var(--hpk-link);
  font-size: var(--hpk-small-font-size);
  text-decoration: underline;
  cursor: pointer;
}
.hpk-client[class*="plugin-order"] .hpk-example-prompt:hover {
  color: var(--hpk-link-hover);
}
.hpk-client[class*="plugin-order"] .hpk-example-prompt:focus-visible {
  box-shadow: var(--hpk-focus);
  border-radius: var(--hpk-r-sm);
}

/* The escape hatch's lead-in. It asks the question the button answers, so the control
 * can be named after its CONSEQUENCE ("I'll use my own domain") instead of after the
 * click ("Continue without a domain"). --hpk-text, not --hpk-muted (Trap 8). */
.hpk-client[class*="plugin-order"] .hpk-continue-lead {
  margin: 0 0 var(--hpk-space-2);
  font-size: var(--hpk-small-font-size);
  color: var(--hpk-text);
}
/* FR43 again: 150x22px at baseline. The button chrome itself is the bundle's
 * {components.button-outline}; only the floor is pack-local. */
.hpk-client[class*="plugin-order"] .hpk-continue-without-domain {
  min-height: 44px;
}

/* --- D. The search region's heading (AC4, D7).
 *
 * The <h3> exists for the OUTLINE, not for the look: it closes the h2 -> h4 skip and
 * stops the picker's group headings being orphans. So it must be typographically
 * transparent, or the frame-tier heading rule (.hpk-client h3 = 28px in the display
 * family, plus a bottom margin) would repaint the label it wraps.
 *
 * Everything is `inherit` rather than a restated value on purpose: the label's parent
 * used to be .form-group and is now this element, so inheriting reproduces the previous
 * computed values EXACTLY, and it cannot drift if the ramp moves again the way 13.1
 * moved it. The label keeps its own display/margin/weight/colour rule untouched, and
 * its bottom margin collapses through this zero-margin wrapper, so the spacing below
 * the label is unchanged too. --- */
.hpk-client[class*="plugin-order"] .hpk-search-heading {
  margin: 0;
  font-family: inherit;
  font-size: inherit;
  font-weight: inherit;
  line-height: inherit;
  color: inherit;
}

/* --- E. The trust band (AC2, D1).
 *
 * A row of plain statements between the card and the pricing disclosure — never inside
 * a card, which is DESIGN.md:324's rule and EXPERIENCE.md:236's placement. It stacks
 * 1-up at <=760px alongside everything else on this surface.
 *
 * It ships with TWO items rather than {components.trust-band}'s three. That is a
 * recorded deviation, not an oversight: the third slot needed a DNS-or-support fact
 * nobody could ratify, and an unverifiable trust claim is worse than none. The rule
 * below is written for N items so a third needs no CSS change if one is ever named.
 *
 * COLOUR. The icon is --hpk-primary in light; in dark, raw brand blue on the dark
 * surface is ~2.2:1, so it takes #A9C5FF — the SAME certified pair the intent segment,
 * the selected chip and the two-tone accent already use, which is why this adds no
 * gen-contrast cell. The text is --hpk-text (Trap 8: never --hpk-muted). --- */
.hpk-client[class*="plugin-order"] .hpk-trust-band {
  display: flex;
  flex-wrap: wrap;
  gap: var(--hpk-space-3);
  margin-bottom: var(--hpk-space-4);
}
.hpk-client[class*="plugin-order"] .hpk-trust-band__item {
  flex: 1 1 200px;
  display: flex;
  align-items: baseline;
  gap: var(--hpk-space-2);
  font-size: var(--hpk-small-font-size);
  color: var(--hpk-text);
}
/* TRAP 3, again. `.hpk-trust-band__item` sets display:flex at (0,3,0) and the scoped
 * `.hidden` rule is also (0,3,0) but EARLIER in the file — so hiding the speed claim in
 * Transfer mode would set the class and leave the claim on screen. Restate at (0,4,0). */
.hpk-client[class*="plugin-order"] .hpk-trust-band__item.hidden {
  display: none;
}
.hpk-client[class*="plugin-order"] .hpk-trust-band__item i {
  flex: none;
  color: var(--hpk-primary);
}
[data-theme="dark"] .hpk-client[class*="plugin-order"] .hpk-trust-band__item i {
  color: #A9C5FF;
}
@media (max-width: 760px) {
  .hpk-client[class*="plugin-order"] .hpk-trust-band {
    display: block;
  }
  .hpk-client[class*="plugin-order"] .hpk-trust-band__item {
    margin-bottom: var(--hpk-space-2);
  }
}

/* --- F. Two layout defects the 13.5 code review found. ---------------------------
 *
 * F1 — the 761-767px gap — is DELETED by 13.7 (Trap 10), not merely superseded.
 *
 * The defect was real: D9 pins the rail/compact swap at 760px, but the pack's grid only
 * floats `.col-md-3` from 768px up, so between 761 and 767 the rail's four cells stacked
 * vertically. 13.5 fixed it by floating the STEPPER's own .col-md-3 cells from 761.
 *
 * The marker rail has no .col-md-3 cells and does not float: `.hpk-order-steps` is
 * `display: flex` at EVERY width above the 760px swap, so the 761-767 band is served by
 * the same rule as 1280 and there is no breakpoint gap left to patch. Keeping the rule
 * would have left a live selector for a hook the rail no longer emits — exactly the dead
 * reference reach.py exists to find. The band is still ASSERTED (AC2/AC6 measure the rail
 * visible and unwrapped at 761, 768, 860 and 945), so deleting the fix does not delete
 * the coverage that would notice if it were ever needed again. */

/* F2 — the packages page overflowed the viewport by 4px at exactly 768px. INHERITED,
 * not introduced: the overflowing element is the stock coupon input, it sits outside the
 * stepper, the overflow survives removing the stepper from the DOM entirely, and the
 * same 772-vs-768 was measured on the pre-13.5 pack where the rail was not rendered at
 * that width at all.
 *
 * Fixed here rather than routed, on Israr's ruling, because AC9 requires zero page-body
 * overflow at 768px and describing a defect is not meeting a floor. The cause is an
 * `.input-group` child with a UA-default intrinsic min-width: a flex/table cell will not
 * shrink below its content's min-content size unless told it may. Scoped to #coupon_box
 * so no other input-group on any order lane is touched. */
.hpk-client[class*="plugin-order"] #coupon_box .input-group,
.hpk-client[class*="plugin-order"] #coupon_box .form-control {
  min-width: 0;
  max-width: 100%;
}

/* ==========================================================================
 * HosterPK 13.7 (2026-07-30) — Step-1 mock parity completion: the DESKTOP MARKER
 * RAIL, and the intent segment at its sealed position.
 *
 * WHAT THIS SECTION IS. Two fidelity deltas against the sealed v2 mock survived Epic
 * 13's terminal gate. Delta A is this block: DESIGN.md {components.order-stepper}
 * (:284-291) has specified a marker rail since 2026-07-09 and NO story in Epic 12 or 13
 * ever owned that desktop visual — 13.5's stepper scope was the `unreachable` semantics
 * plus the compact phone variant, and the desktop rail it shipped was restyled STOCK
 * chevron markup (a .card.card-steps holding four floated .col-md-3 cells, each a
 * chevron pair + a "Step N" link + an italic description). It fell between two epic
 * decompositions. Delta B is the intent segment, which the sealed composition order
 * (EXPERIENCE.md:225-234) puts ABOVE the search field and which shipped below it; that
 * one is a markup move in lookup.pdt, not CSS (D6 — DOM order is tab order is
 * screen-reader order, and that is the whole point of the mock's placement), so this
 * section adds nothing for it beyond the note in §C.
 *
 * MEASURED, NOT TRANSCRIBED. Every layout number below was read off the rendered v2
 * mock by tooling/evidence/13-7/mock_targets.js, not copied out of its stylesheet:
 * 28x28 marker with a 2px ring, 9px step gap, first step flex 0 0 auto and the rest
 * 1 1 auto, connector flex 1 1 auto with min-width 16px / height 2px / margin 0 12px,
 * label 600 .84rem display-family nowrap, rail max-width = the card column, 26px below.
 * The mock's own tokens resolve to ours exactly — border rgb(233,233,233) = --hpk-border
 * #E9E9E9, muted rgb(95,107,130) = --hpk-muted #5F6B82, ink rgb(3,18,62) = --hpk-ink,
 * primary rgb(20,87,230) = --hpk-primary — so this is token reuse, not re-specification.
 *
 * TWO DELIBERATE DEVIATIONS FROM THE MOCK, both recorded rather than silent:
 *
 *   1. COMPLETE uses --hpk-success-text, not the raw spec hex (D8). DESIGN.md:288 says
 *      `complete: check glyph · border {colors.success} · text {colors.success}`, and raw
 *      {colors.success} #17CA68 on white measures ~2.17:1 — below even the 3:1 UI floor,
 *      far below 4.5:1 for the label text beside it. The replacement is the pack's
 *      ALREADY-CERTIFIED success token (tokens.css:51 #0A6E37 light / :171 #3CE08A dark)
 *      written in the fallback shape this file already uses for a step-card success cell
 *      at :89-91. The v2 mock cannot arbitrate: it is a Step-1 page and renders NO
 *      complete state at all. DESIGN.md:32's a11y-darkened `muted` is the precedent.
 *
 *   2. The live step anchor is >=44px tall (FR43, prd.md:232), where the mock's step box
 *      is 28px. The 28px circle is the VISUAL, never the target. The mock says of itself
 *      that it is "an illustrative composition reference ONLY ... NOT an a11y reference
 *      implementation", so the floor wins and the rail is 16px taller than the mock.
 *
 * DARK. Trap 8 again: bare --hpk-muted in dark is 55% white and is the documented
 * dark-mode AA trap (tokens.css:166-170) — dark neutral text MUST be --hpk-text. The
 * future step is therefore the ONE cell that needs an explicit [data-theme="dark"]
 * override; current and complete already ride tokens that define both themes. The
 * override is scoped to --future so it cannot reach the other two states, which sit at
 * the same (0,4,0) specificity and would otherwise lose to it on source order.
 *
 * REACH. Like 13.5's stepper block this deliberately reaches all seven stepper lanes —
 * that IS the deliverable (the rail is duplicated per D4, never extracted as a partial,
 * because View->fetch partials have no fallback and a missing one silently blanks the
 * lane). Every rule is gated behind the live order body marker and an .hpk- component
 * hook; reach.py measures it rather than asserting it.
 *
 * RULE 1 / RULE 2. No inline style= anywhere; this file stays at ZERO flagged
 * declarations.
 * ========================================================================== */

/* --- A. The rail container. The <ol> now carries `hpk-order-steps`, which stays the
 * desktop container's hook because three shipped rules select on it: the 760px swap
 * (:1574), the `.hidden` restatement (:1582) and the a[aria-disabled] pointer-events
 * contract (:1504). Moving the class rather than renaming it is what keeps all three
 * working untouched.
 *
 * max-width is stated even though .hpk-order-column (13.2) already constrains this
 * subtree to the same 980px: AC1's fidelity row is "rail max-width = the card width",
 * and a rail that is only accidentally the right width because of an ancestor is not
 * that. margin-inline auto keeps it centred if either constraint ever changes. --- */
.hpk-client[class*="plugin-order"] .hpk-order-steps {
  display: flex;
  align-items: center;
  /* 13.7 review round 2: the overflow guard, chosen by MEASUREMENT rather than by the
   * first fix that comes to mind. The review proposed `overflow: hidden` +
   * `text-overflow: ellipsis` on the label; that would truncate wayfinding text to
   * "Choose your p…", contradicting AC1's fidelity target, and — worse — it would HIDE
   * an overflow instead of surfacing it.
   *
   * What was actually measured: the rail's min-content width is 608px and constant (the
   * labels are nowrap), against a 729px container at 761px, the NARROWEST band the rail
   * is visible at. That is 121px of headroom, plus ~123px more of connector shrink before
   * min-content even binds — so the overflow the finding predicts cannot occur at the
   * shipped copy. A stress probe confirmed where the real cliff is: at 2x label length the
   * page body DOES overflow (800 vs 761).
   *
   * `flex-wrap: wrap` is the guard that costs nothing and truncates nothing. Verified a
   * BYTE-IDENTICAL no-op at 761/768/860/945/1280/1456 (every step box identical to the
   * pixel), and under the same 2x/3x stress it holds the page at 761/761 by letting the
   * rail take a second row instead of pushing the document. Graceful degradation, no text
   * loss, zero effect on what ships today. The latent risk is separately GATED:
   * browser_steps.js now asserts min-content <= container at every band, so a future
   * re-voicing that eats the slack fails the gate before it can reach a customer. */
  flex-wrap: wrap;
  max-width: var(--hpk-order-card-max, 980px);
  margin: 0 auto 26px;
  padding: 0;
  list-style: none;
}

/* Each step is its own flex line: [connector] [link]. The connector is the ::before of
 * every step BUT the first, which is why the first step is the only one that does not
 * grow — it has no rule to its left to absorb the slack. */
.hpk-client[class*="plugin-order"] .hpk-order-step {
  display: flex;
  align-items: center;
  gap: 9px;
  flex: 1 1 auto;
  min-width: 0;
}
.hpk-client[class*="plugin-order"] .hpk-order-step:first-child {
  flex: 0 0 auto;
}
/* The 2px connector. Decorative: it repeats, in a rule, the sequence the numbers and
 * the ordered list already state, so it carries no information of its own and takes no
 * contrast cell (the same reading 13.5 recorded for the compact progress bar). It is
 * the growing element, so the rail distributes its slack between the steps rather than
 * after them. */
.hpk-client[class*="plugin-order"] .hpk-order-step + .hpk-order-step::before {
  content: "";
  flex: 1 1 auto;
  min-width: 16px;
  height: 2px;
  margin: 0 12px;
  background: var(--hpk-border, #E9E9E9);
}

/* The link. `color: inherit` deliberately drops the frame-tier --hpk-link on this one
 * component: a rail of four blue links reads as navigation-in-progress, and the state
 * colours below ARE the affordance. text-decoration is dropped for the same reason and
 * restored on hover — on the LABEL only, so the numeral inside the circle never gets an
 * underline through it.
 *
 * min-height is FR43 (>=44px touch target), and it is the reason this rail is taller
 * than the mock's. Inert steps are pointer-events:none (:1504) and are exempt from the
 * target-size floor as non-actionable; the live ones are asserted in browser_steps.js at
 * every band including the 761-945px tablet touch range. */
.hpk-client[class*="plugin-order"] .hpk-order-step a {
  display: flex;
  align-items: center;
  gap: 9px;
  /* FR43 is an AREA, not a height. 13.7 review (MEDIUM): only min-height was stated, so a
   * short or missing label could have left a live anchor narrower than 44px while the
   * "≥44px hit box" claim stayed green — the assertion measured only one dimension too.
   * In practice the marker (28) + gap (9) + the shortest shipped label already clears it,
   * which is exactly why the gap would have gone unnoticed; stating both makes the contract
   * true by construction rather than true by luck. Costs nothing: it is a floor, not a size. */
  min-height: 44px;
  min-width: 44px;
  color: inherit;
  text-decoration: none;
}
.hpk-client[class*="plugin-order"] .hpk-order-step a:hover .hpk-order-step__label {
  text-decoration: underline;
}

/* B. The marker and the label — the FUTURE state is the base, because it is the only
 * one of the three that needs no override on any lane. box-sizing is restated locally:
 * the 2px ring must sit INSIDE the 28px the spec gives, and this file's border-box
 * contract is set on [class*="col-md-"], which this element is not. */
.hpk-client[class*="plugin-order"] .hpk-order-step__marker {
  flex: none;
  box-sizing: border-box;
  display: grid;
  place-items: center;
  width: 28px;
  height: 28px;
  border: 2px solid var(--hpk-border, #E9E9E9);
  border-radius: 50%;
  background: transparent;
  color: var(--hpk-muted, #5F6B82);
  font-family: var(--hpk-font-display, "Urbanist", system-ui, sans-serif);
  font-size: .8rem;
  font-weight: 700;
  line-height: 1;
}
/* nowrap is the atomicity rule the chip family already uses: a step label that wraps
 * mid-phrase turns a 4-across rail into a ragged block, and the connector's flex-basis
 * would absorb the reflow silently. Asserted by measuring label height at every band. */
.hpk-client[class*="plugin-order"] .hpk-order-step__label {
  color: var(--hpk-muted, #5F6B82);
  font-family: var(--hpk-font-display, "Urbanist", system-ui, sans-serif);
  font-size: .84rem;
  font-weight: 600;
  white-space: nowrap;
}

/* C. CURRENT — filled brand disc, white numeral, ink label at 600 (DESIGN.md:286).
 * Theme-complete without an override: --hpk-primary is brand-constant and --hpk-ink
 * flips to #FFFFFF in dark on its own. */
.hpk-client[class*="plugin-order"] .hpk-order-step--current .hpk-order-step__marker {
  background: var(--hpk-primary, #1457E6);
  border-color: var(--hpk-primary, #1457E6);
  color: #fff;
}
.hpk-client[class*="plugin-order"] .hpk-order-step--current .hpk-order-step__label {
  color: var(--hpk-ink, #03123E);
}

/* D. COMPLETE — check glyph in place of the numeral, ring and label on the certified
 * success token (D8, and the exact var() shape this file already uses at :89-91).
 * Both themes ride the token; no [data-theme] rule is needed or wanted. */
.hpk-client[class*="plugin-order"] .hpk-order-step--complete .hpk-order-step__marker {
  border-color: var(--hpk-success-text, var(--success, #28a745));
  color: var(--hpk-success-text, var(--success, #28a745));
}
.hpk-client[class*="plugin-order"] .hpk-order-step--complete .hpk-order-step__label {
  color: var(--hpk-success-text, var(--success, #28a745));
}

/* E. The two dark-theme overrides. Both are the "explicit [data-theme=dark] override
 * where a cell fails AA on its own tint" that the forward rules require, not restyling.
 *
 * E1 — FUTURE neutral text. --hpk-muted resolves to 55% white in dark and fails 4.5:1 on
 * the dark neutral surface BY DESIGN (tokens.css:166-170), so dark neutral text takes
 * --hpk-text. Scoped to --future so it cannot out-rank the current/complete rules above,
 * which sit at the same specificity and come earlier in the file.
 *
 * E2 — the CURRENT marker's RING. MEASURED, not assumed — and 13.7 code review (LOW)
 * required each figure to NAME the background it is against, because the first cut quoted
 * the disc from one composite and the ring from another and the story body then mixed the
 * two. The hero-wash is a gradient (:1026), so "the page" is not one colour: alpha runs
 * from its peak at the wash origin to 0 at --hpk-order-hero-depth (420px), and the rail's
 * own top sits 70px in (.hpk-order-main's padding-block, :937). All four values below are
 * reproducible from those two numbers alone:
 *
 *   brand disc #1457E6, light, wash at the rail's y (alpha .0583)  ->  5.05:1  (floor 3, ok)
 *   brand disc #1457E6, dark,  wash at the rail's y (alpha .1333)  ->  2.32:1  ** FAILS **
 *   brand disc #1457E6, dark,  wash at full strength (alpha .16)   ->  2.27:1  ** FAILS **
 *   ring #8AB4F8,       dark,  wash at full strength (gated)       ->  6.40:1  (ok)
 *
 * The filled disc IS the "you are here" signal, so 1.4.11's 3:1 floor for state
 * information binds and the dark disc fails it at every point on the ramp. The fix is the
 * design system's OWN idiom for this exact problem rather than a new colour: --hpk-primary
 * is a deliberately theme-AGNOSTIC brand hue with no dark override (components.css:129-136
 * says so, and .hpk-btn-primary keeps brand fill + literal #fff in both themes), and where
 * a brand-blue shape must stay visible on navy the theme draws its BOUNDARY from
 * --hpk-link instead — that is precisely how the dark --hpk-focus ring is built
 * (tokens.css: "the brightened content link --hpk-link (#8AB4F8), which clears AA on the
 * dark surface"). So the fill and the numeral stay exactly as DESIGN.md:286 specifies and
 * only the 2px ring brightens, to the 6.40:1 gated above — the value gen-contrast reports,
 * not a second measurement taken against a different slice of the ramp.
 *
 * The FUTURE ring and the connector are deliberately NOT given the same treatment. They
 * measure 1.35:1 dark / 1.05:1 light and that is correct: {colors.border} is a hairline
 * token and a hairline is what the sealed spec asks for. They carry no information — a
 * future step is identified by its numeral and its label, both real text gated at 4.5:1,
 * and the current step additionally by aria-current="step". Brightening them would
 * contradict DESIGN.md:287/289 to satisfy a criterion that does not apply to decoration. */
[data-theme="dark"] .hpk-client[class*="plugin-order"] .hpk-order-step--future .hpk-order-step__marker,
[data-theme="dark"] .hpk-client[class*="plugin-order"] .hpk-order-step--future .hpk-order-step__label {
  color: var(--hpk-text, rgba(255, 255, 255, .70));
}
[data-theme="dark"] .hpk-client[class*="plugin-order"] .hpk-order-step--current .hpk-order-step__marker {
  border-color: var(--hpk-link, #8AB4F8);
}

/* F. The 760px swap, RESTATED. 13.5's swap block sits at :1573-1584, EARLIER in this
 * file than the `display: flex` above and at the same (0,3,0) specificity — so without
 * this the later rule would win below 760px and the desktop rail would render on a
 * phone alongside the compact variant. This is the same restatement idiom 13.5 used for
 * `.hidden` at :1582 and for the same class of failure: a cascade that depends on source
 * order across 200 lines is a defect waiting for the next edit. The compact half of the
 * swap is untouched (D5) and still lives at :1573-1584. */
@media (max-width: 760px) {
  .hpk-client[class*="plugin-order"] .hpk-order-steps {
    display: none;
  }
}

/* G. `.hidden`, RESTATED FOR THE DESKTOP BAND — 13.7 code review (MEDIUM).
 *
 * Section F restated the 760px swap because the `display: flex` above it wins on source
 * order. The same reasoning has a second half that the first cut missed, and missing it
 * QUIETLY DISARMED A GUARD 13.5 INSTALLED ON PURPOSE.
 *
 * The scoped hide is `.hpk-client[class*="plugin-order"] .hidden { display: none }` at
 * :217 — (0,3,0), and roughly 1600 lines EARLIER than this block. So:
 *
 *   .hpk-order-steps   display: flex   (0,3,0) later  -> beats `.hidden` above 760px
 *   .hpk-order-step    display: flex   (0,3,0) later  -> beats `.hidden` at EVERY width
 *   .hpk-order-step a  display: flex   (0,3,1)        -> outranks `.hidden` outright
 *
 * At baseline_commit the ONLY `display` declaration on any of these hooks lived inside
 * the `max-width: 760px` block, which is exactly why 13.5 restated `.hidden` there and
 * nowhere else — above 760px there was nothing to beat. 13.7 introduced the first
 * unconditional `display` on all three hooks and did not carry the restatement across,
 * so `.hidden` worked on a phone and was inert on a desktop. Nothing toggles it on the
 * rail today; that is precisely the condition under which this would have gone unnoticed,
 * and 13.5's own comment states the intent it is protecting: "this exists so that the
 * first thing that does cannot fail silently."
 *
 * Restated for all three hooks at a rank that wins in both bands. No rendered pixel
 * changes today — no element carries `.hidden` on any stepper lane — so this is a guard,
 * not a restyle. */
.hpk-client[class*="plugin-order"] .hpk-order-steps.hidden,
.hpk-client[class*="plugin-order"] .hpk-order-step.hidden,
.hpk-client[class*="plugin-order"] .hpk-order-step a.hidden {
  display: none;
}

/* ==========================================================================
 * STORY 14.1 — ORDER STEP 2: THE CONSOLIDATED-CHECKOUT LEFT COLUMN
 *
 * Scope: config.pdt and its async config_packageoptions.pdt partial ONLY. The
 * summary rail, the term-radio cards and the commitment bar are 14.2's; the
 * account and billing sections are 14.3's. Nothing below pre-builds them.
 *
 * REUSE, NOT REINVENTION (D11). {components.numbered-section-card} IS
 * {components.card} + {components.card-accent-top}, and .hpk-order-card (:1038)
 * already ships exactly that box. Everything here is a MODIFIER on it or a new
 * component the sealed spine names; there is no second card in this file.
 *
 * TOKENS (Trap 12 — an undefined var() INHERITS, it does not fall back). Every
 * custom property consumed below is declared in brand/tokens/tokens.css:
 * --hpk-primary, --hpk-primary-tint, --hpk-success-text, --hpk-border,
 * --hpk-ink, --hpk-text, --hpk-muted, --hpk-surface, --hpk-g100, --hpk-focus,
 * --hpk-r-sm, --hpk-r-pill, --hpk-small-font-size, --hpk-font-display and the
 * --hpk-space-* ramp. Verified by grep before authoring, not assumed.
 *
 * BOTH THEMES. Secondary text uses --hpk-text, never --hpk-muted: dark --hpk-muted
 * is 55% white and fails 4.5:1 on the dark neutral surface (tokens.css:166-170) —
 * the same trap 13.5's block records.
 * ========================================================================== */

/* --- A. The 3-step compact bar (D4). A NEW HOOK, deliberately.
 *
 * :1556-1559 map data-hpk-step 1|2|3|4 to 25|50|75|100% and those four rules serve
 * ALL SEVEN pack views. A three-step page at step 2 must read ~66%, not 50%.
 * Rewriting the shared [data-hpk-step="2"] rule would silently move the bar on the
 * other six views, which still run the four-step funnel until 14.4 consolidates.
 * So the wrapper carries an ADDITIONAL data-hpk-steps="3" and these rules
 * out-qualify the shared four by one attribute selector — (0,4,0) vs (0,3,0) — and
 * sit later in the file. The 1 and 3 rules are emitted by no view today; they exist
 * so that the first 3-step view that IS added cannot silently inherit a four-step
 * width, which is the same reasoning as the explicit `width: 0` default at :1552. */
.hpk-client[class*="plugin-order"] .hpk-order-steps-wrap[data-hpk-steps="3"][data-hpk-step="1"] .hpk-order-steps-compact__bar span { width: 33.3333%; }
.hpk-client[class*="plugin-order"] .hpk-order-steps-wrap[data-hpk-steps="3"][data-hpk-step="2"] .hpk-order-steps-compact__bar span { width: 66.6667%; }
.hpk-client[class*="plugin-order"] .hpk-order-steps-wrap[data-hpk-steps="3"][data-hpk-step="3"] .hpk-order-steps-compact__bar span { width: 100%; }

/* --- B. Card titles and the numbered disc ({components.numbered-section-card}).
 *
 * The heading is an <h3>: the shell owns the page's only <h1> and D2's ruling puts
 * the two-tone page title at <h2>, so the card headlines sit one level below it and
 * the outline stays contiguous (h1 - h2 - h3xN).
 *
 * The disc is 28px, --hpk-primary fill, #fff numeral at 700/.85rem, and the sub-text
 * indents 39px to clear it (28px disc + the 11px gap). DESIGN.md:336 is explicit
 * that the number is SEQUENCE, not progress: it never changes state, so there is no
 * active/complete variant here and none should be added. */
.hpk-client[class*="plugin-order"] .hpk-order-card__title {
  display: flex;
  align-items: center;
  gap: var(--hpk-space-2);
  margin: 0 0 var(--hpk-space-2);
  font-family: var(--hpk-font-display, "Urbanist", system-ui, sans-serif);
  font-size: 1.25rem;
  font-weight: 600;
  line-height: var(--hpk-heading-line-height, 1.2);
  color: var(--hpk-ink);
}
.hpk-client[class*="plugin-order"] .hpk-order-card__num {
  flex: none;
  display: inline-flex;
  align-items: center;
  justify-content: center;
  inline-size: 28px;
  block-size: 28px;
  border-radius: var(--hpk-r-pill);
  background: var(--hpk-primary);
  color: #fff;
  font-size: .85rem;
  font-weight: 700;
  line-height: 1;
}
.hpk-client[class*="plugin-order"] .hpk-order-card__sub {
  margin: 0 0 var(--hpk-space-3);
  font-size: .9rem;
  color: var(--hpk-text);
}
/* The 39px indent aligns the sub-text with the title TEXT rather than the disc, and
 * it only applies where a disc actually exists. */
.hpk-client[class*="plugin-order"] .hpk-order-card--section > .hpk-order-card__sub {
  padding-inline-start: 39px;
}
/* Below the phone band the indent is a liability: it eats a fifth of a 390px line
 * for alignment nobody can see once the text wraps three times. */
@media (max-width: 760px) {
  .hpk-client[class*="plugin-order"] .hpk-order-card--section > .hpk-order-card__sub {
    padding-inline-start: 0;
  }
}

/* --- C. The submit row. The CTA used to carry `float-right` inside a card-body;
 * with the sections now being real boxes a float would escape the flow. --- */
.hpk-client[class*="plugin-order"] .hpk-order-actions {
  display: flex;
  justify-content: flex-end;
  margin-block-start: var(--hpk-space-4);
}

/* --- D. {components.addon-card}.
 *
 * THE FLEX LIVES ON THE <label>, NEVER ON .form-group (D15 consequence 2). The
 * generated option-logic JS reveals conditional options with
 * $(target).parents("div.form-group").show(), and jQuery .show() writes
 * `display: block` INLINE. An inline declaration beats any authored rule without
 * the flag RULE 2 forbids, so a card laid out on .form-group would collapse the
 * first time a conditional option appeared — on a package with option conditions
 * only, i.e. a green build and a broken page. The <label> is a descendant jQuery
 * never touches.
 *
 * The whole card is the hit target (FR43 >=44px via the padding + min-block-size),
 * and the real checkbox stays a real checkbox — it is never replaced, so the
 * option-logic handlers and any checked state survive composition. */
.hpk-client[class*="plugin-order"] .hpk-addon-card-host {
  margin-block-end: var(--hpk-space-2);
}
/* SPECIFICITY, MEASURED — this pair is not decoration.
 *
 * :398 already declares `display: inline-block` for the SAME element:
 *   .hpk-client[class*="plugin-order"] .checkbox:not(#payment_details *) label
 * `:not()` takes the specificity of its most specific argument, and that argument is
 * `#payment_details *` — an ID. So that rule ranks (1,3,1), and a plain
 * `.hpk-client[class*="plugin-order"] .hpk-addon-card` at (0,3,0) LOSES to it no
 * matter how late it sits in the file. MEASURED before this pair existed: the card
 * computed `display: inline-block`, so the price block sat under the text instead of
 * on the trailing edge and the whole flex layout was silently inert.
 *
 * The fix carries the FR22 FENCE FORWARD rather than escaping it: same
 * `:not(#payment_details *)`, one more class. That keeps the guarantee the fence
 * exists for — this rule still cannot reach INTO gateway/payment DOM — while ranking
 * (1,4,1). Only the two CONTESTED properties are restated here; everything the fence
 * rule does not set stays in the (0,3,0) block below, where nothing competes.
 * `cursor: pointer` needs no restatement: the fence rule already sets it to the value
 * this component wants. */
.hpk-client[class*="plugin-order"] .checkbox:not(#payment_details *) label.hpk-addon-card,
.hpk-client[class*="plugin-order"] .radio:not(#payment_details *) label.hpk-addon-card {
  display: flex;
  margin: 0;
}
.hpk-client[class*="plugin-order"] .hpk-addon-card {
  display: flex;
  align-items: flex-start;
  gap: var(--hpk-space-2);
  min-block-size: 44px;
  margin: 0;
  padding: var(--hpk-space-3);
  border: 1px solid var(--hpk-border);
  border-radius: var(--hpk-r-sm);
  background: var(--hpk-surface);
  cursor: pointer;
}
/* A DISABLED option must not LOOK actionable.
 *
 * The generated option-logic JS has two ways to suppress a conditional option, and
 * which one it uses is the admin's choice, not ours: Logic.php:92 sets
 * `hide_on_disable` from `package_option_groups.hide_options`. With hide_options = 0
 * the option is DISABLED IN PLACE and stays visible — a card that still had the hover
 * border and the pointer cursor would be claiming an affordance it does not have.
 * The disabled input is correctly out of the tab order, so this is a visual honesty
 * fix, not a focus fix. The fixture exercises the hide_options = 1 branch (see D15);
 * this branch is unexercised locally — close recipe: set hide_options = 0 on the
 * fixture option group, re-run options.js, and assert this state renders. */
.hpk-client[class*="plugin-order"] .hpk-addon-card:has(input:disabled) {
  border-style: dashed;
  cursor: default;
  opacity: .6;
}
.hpk-client[class*="plugin-order"] .hpk-addon-card.is-disabled {
  border-style: dashed;
  cursor: default;
  opacity: .6;
}
.hpk-client[class*="plugin-order"] .hpk-addon-card:has(input:disabled):hover {
  border-color: var(--hpk-border);
}
.hpk-client[class*="plugin-order"] .hpk-addon-card.is-disabled:hover {
  border-color: var(--hpk-border);
}
.hpk-client[class*="plugin-order"] .hpk-addon-card:hover {
  border-color: var(--hpk-primary);
}
.hpk-client[class*="plugin-order"] .hpk-addon-card input[type="checkbox"] {
  flex: none;
  inline-size: 18px;
  block-size: 18px;
  margin: 2px 0 0;
}
.hpk-client[class*="plugin-order"] .hpk-addon-card__body {
  flex: 1 1 auto;
  display: flex;
  flex-direction: column;
  gap: 2px;
  min-inline-size: 0;
}
.hpk-client[class*="plugin-order"] .hpk-addon-card__name {
  font-weight: 600;
  color: var(--hpk-ink);
}
.hpk-client[class*="plugin-order"] .hpk-addon-card__desc {
  font-size: var(--hpk-small-font-size);
  color: var(--hpk-text);
}
.hpk-client[class*="plugin-order"] .hpk-addon-card__price {
  flex: none;
  display: flex;
  flex-direction: column;
  align-items: flex-end;
  gap: 2px;
  text-align: end;
}
.hpk-client[class*="plugin-order"] .hpk-addon-card__amount {
  font-family: var(--hpk-font-display, "Urbanist", system-ui, sans-serif);
  font-weight: 600;
  color: var(--hpk-ink);
}
.hpk-client[class*="plugin-order"] .hpk-addon-card__unit {
  font-size: var(--hpk-small-font-size);
  color: var(--hpk-text);
}
/* A genuinely free upgrade is a STATEMENT, so it is not styled as a price. */
.hpk-client[class*="plugin-order"] .hpk-addon-card__price--free .hpk-addon-card__amount {
  color: var(--hpk-success-text);
}
/* Checked / disabled / focus states.
 *
 * EVERY :has() RULE IS MIRRORED BY AN EXPLICIT CLASS, IN A SEPARATE RULE BLOCK.
 * `:has()` is unsupported in Firefox < 121 and older mobile WebKit; without a mirror a
 * buyer there saw a checked add-on render IDENTICALLY to an unchecked one — a selection
 * with no visible confirmation, on a page whose whole job is making a purchase decision
 * legible. The in-view script stamps `is-checked` / `is-disabled` / `is-focus` and
 * keeps them in sync.
 *
 * ROUND 3 REVIEW FIX — THE MIRROR MUST NOT SHARE A SELECTOR LIST WITH `:has()`.
 * Round 2 wrote each pair as ONE grouped selector. A CSS selector list is UNFORGIVING:
 * if any compound in it fails to parse, the ENTIRE list is discarded along with its
 * declaration block. So on precisely the browsers the fallback exists for, the
 * `:has()` half killed the `.is-*` half too and NONE of the state styling applied —
 * the fallback was not merely useless, it was self-defeating. (`:is()`/`:where()` are
 * forgiving; a bare selector list is not.) Each half is now its own rule block, parsed
 * independently: a browser that cannot read the `:has()` rule drops only that rule. */
.hpk-client[class*="plugin-order"] .hpk-addon-card:has(input:checked) {
  border-color: var(--hpk-primary);
  background: var(--hpk-primary-tint);
}
.hpk-client[class*="plugin-order"] .hpk-addon-card.is-checked {
  border-color: var(--hpk-primary);
  background: var(--hpk-primary-tint);
}
[data-theme="dark"] .hpk-client[class*="plugin-order"] .hpk-addon-card:has(input:checked) {
  background: rgba(20, 87, 230, .14);
}
[data-theme="dark"] .hpk-client[class*="plugin-order"] .hpk-addon-card.is-checked {
  background: rgba(20, 87, 230, .14);
}
/* Visible keyboard focus. The native checkbox keeps its own focus ring; this puts
 * the ring on the card so the hit target and the focus indicator agree. */
.hpk-client[class*="plugin-order"] .hpk-addon-card:has(input:focus-visible) {
  box-shadow: var(--hpk-focus);
}
.hpk-client[class*="plugin-order"] .hpk-addon-card.is-focus {
  box-shadow: var(--hpk-focus);
}
/* Sub-760px the price block drops under the text rather than squeezing the name to
 * a two-character column. */
@media (max-width: 760px) {
  .hpk-client[class*="plugin-order"] .hpk-addon-card {
    flex-wrap: wrap;
  }
  .hpk-client[class*="plugin-order"] .hpk-addon-card__price {
    inline-size: 100%;
    flex-direction: row;
    align-items: baseline;
    justify-content: flex-start;
    gap: var(--hpk-space-1);
    padding-inline-start: calc(18px + var(--hpk-space-2));
    text-align: start;
  }
}

/* --- E. {components.included-strip}. A STATEMENT, NOT A CONTROL.
 *
 * It replaces the zero-priced single-value groups the buyer could never decline, so
 * it contains no input, no tabindex and nothing focusable (AC2). The check glyph is
 * --hpk-success-text (#0A6E37 light / #3CE08A dark), NOT raw --hpk-success #17CA68,
 * which measures ~2.17:1 on white — the delta recorded at deferred-work.md:861. Both
 * values are already gen-contrast cells, so this adds none. --- */
.hpk-client[class*="plugin-order"] .hpk-included-strip {
  display: flex;
  align-items: baseline;
  flex-wrap: wrap;
  gap: var(--hpk-space-1);
  margin: var(--hpk-space-2) 0 0;
  padding: var(--hpk-space-2) var(--hpk-space-3);
  border-radius: var(--hpk-r-sm);
  background: var(--hpk-g100);
  font-size: var(--hpk-small-font-size);
  color: var(--hpk-text);
}
.hpk-client[class*="plugin-order"] .hpk-included-strip__glyph {
  color: var(--hpk-success-text);
}
/* The label is now a <p> wrapping the glyph + a bold <b>, and the items are a real
 * <ul>/<li> the label programmatically names (round 2 review). The visual result is
 * IDENTICAL to the previous flat markup — that is the point: the structure changed for
 * assistive technology, not for sighted layout. The list is stripped of its marker and
 * laid out inline; `margin: 0` on both children keeps the single-line baseline the
 * flex container above already establishes. */
.hpk-client[class*="plugin-order"] .hpk-included-strip__label {
  display: inline-flex;
  align-items: baseline;
  gap: var(--hpk-space-1);
  margin: 0;
  font-weight: 700;
  color: var(--hpk-ink);
}
.hpk-client[class*="plugin-order"] .hpk-included-strip__items {
  display: inline-flex;
  flex-wrap: wrap;
  gap: var(--hpk-space-1);
  margin: 0;
  padding: 0;
  list-style: none;
}
/* Comma separators are DECORATIVE and generated, so they never reach the a11y tree —
 * which is exactly why the items are <li> rather than one comma-joined string: the
 * separator is for the eye, the list structure is for the screen reader. */
.hpk-client[class*="plugin-order"] .hpk-included-strip__item + .hpk-included-strip__item::before {
  content: ", ";
}

/* --- F. The collapsed group.
 *
 * D16 collapses single-value select/radio groups into the strip, but their submitted
 * name/value MUST survive as a hidden field (AC5) — so the div.form-group stays where
 * it is, inside .generated_fields_div, carrying only that hidden input. It is emptied
 * of every visible child as well as hidden, so that if the option-logic JS ever calls
 * .show() on it (inline display:block, which no non-flagged rule can beat) the result
 * is an inert zero-height box rather than a stray control. Belt and braces without
 * reaching for the flag RULE 2 forbids. --- */
.hpk-client[class*="plugin-order"] .hpk-option-collapsed {
  display: none;
  margin: 0;
  padding: 0;
}

/* --- G. The async option region.
 *
 * `hpk-card` was dropped from config_packageoptions.pdt's wrapper: inside a
 * .hpk-order-card section it was a card in a card. This replaces it with spacing
 * only — no surface, no border, no shadow. --- */
.hpk-client[class*="plugin-order"] .hpk-option-region {
  padding: 0;
}
.hpk-client[class*="plugin-order"] .hpk-option-desc {
  display: block;
  font-size: var(--hpk-small-font-size);
  color: var(--hpk-text);
}
/* Loading / error. Stock had neither, because the response WAS the content; once an
 * amount and a unit are applied client-side from the selected term, a silent failure
 * would leave a stale price on screen under a new unit (D6b). */
.hpk-client[class*="plugin-order"] .hpk-option-message {
  margin: 0;
  padding: var(--hpk-space-2) 0;
  font-size: var(--hpk-small-font-size);
  color: var(--hpk-text);
}
.hpk-client[class*="plugin-order"] .hpk-option-message--error {
  color: var(--hpk-danger-text, var(--hpk-ink));
}

/* ==========================================================================
 * HosterPK 14.2 (2026-08-02) - the order summary rail and the commitment bar.
 *
 * WHAT THIS SECTION IS. 14.1 recomposed Step 2's LEFT column and deliberately left
 * the col-md-9 / col-md-3 float pair alone, deferring the grid here by name. This
 * section is that edit plus the sealed {components.order-summary-rail},
 * {components.term-radio-card} and {components.checkout-bottom-bar}.
 *
 * THE FR22 FENCE IS CARRIED FORWARD, NOT ESCAPED. The shared float grid at :167-173
 * is written `.col-md-9:not(#payment_details *)`, and :not() takes the specificity of
 * its MOST SPECIFIC argument - an ID - so those rules rank (1,3,0), not (0,3,0). A
 * rule here that merely added a class would LOSE and be inert while every gate stayed
 * green, which is exactly what happened to 14.1's addon-card flex. Every rule below
 * that has to out-rank a fenced rule carries the same fence and is one class deeper.
 * ========================================================================== */

/* --- D2. THE 980px COLUMN CAP IS IN structure.pdt, WHICH IS OUT OF SURFACE, SO THE
 * WIDENING IS DONE FROM HERE AND ONLY ON THE CONFIG LANE.
 *
 * The sealed grid is minmax(0,1fr) + a 400px rail with a 26px gap, which does not fit
 * inside 980px. It fits the 1320px shell, and the mock's own form column is therefore
 * 1320 - 400 - 26 = 894px, NOT 980px.
 *
 * The scope hook is the per-route body marker. MEASURED on this stack, not assumed:
 * /order/config/index/{label} renders
 *   <body class="hpk-client plugin-orderclient-config-index order">
 * so `plugin-orderclient-config-index` is a real, per-lane class. The other six pack
 * views keep 980px, and 13.6's chrome gate still measures 1320 / 980 on Step 1. --- */
.hpk-client.plugin-orderclient-config-index .hpk-order-column {
  max-width: var(--hpk-space-container-xxl);
}
/* The fallback lives in its OWN RULE and is never grouped with the rule above.
 * 14.1's round-3 review caught exactly this mistake: a :has() selector sharing a
 * comma list with its fallback invalidates THE WHOLE LIST in an engine that cannot
 * parse :has(), so the fallback does nothing - the one thing it exists not to do. */
.hpk-client[class*="plugin-order"] .hpk-order-column:has(.hpk-order-layout) {
  max-width: var(--hpk-space-container-xxl);
}

/* --- The two-column grid. The shared float rules (:167-173) serve six other lanes
 * and are out of surface, so the floats are NEUTRALISED INSIDE the layout rather than
 * edited: grid items ignore `float` by spec, but `width: 75%` would still resolve
 * against the track, so the widths are reset explicitly. flow-root containment stays
 * wherever a float can still occur. --- */
.hpk-client[class*="plugin-order"] .hpk-order-layout {
  display: grid;
  grid-template-columns: minmax(0, 1fr) 400px;
  gap: 26px;
  align-items: start;
}
.hpk-client[class*="plugin-order"] .hpk-order-layout > .col-md-9:not(#payment_details *),
.hpk-client[class*="plugin-order"] .hpk-order-layout > .col-md-3:not(#payment_details *) {
  float: none;
  width: auto;
  min-width: 0;
  padding-inline-end: 0;
  display: flow-root;
}

/* --- The rail itself. {components.order-summary-rail} = {components.card} +
 * {components.card-accent-top}, which this pack ALREADY ships as .hpk-order-card
 * (:1038-1046). The rail is a MODIFIER of that box, not a second card (D11). --- */
.hpk-client[class*="plugin-order"] .hpk-order-rail {
  position: sticky;
  top: 22px;
}
.hpk-client[class*="plugin-order"] .hpk-rail {
  margin-bottom: 0;
}
.hpk-client[class*="plugin-order"] .hpk-rail__title {
  margin: 0 0 var(--hpk-space-3);
  font-size: 1.1rem;
  font-weight: 700;
  color: var(--hpk-ink);
}
.hpk-client[class*="plugin-order"] .hpk-rail__section-title {
  margin: 0 0 var(--hpk-space-2);
  font-size: var(--hpk-small-font-size);
  font-weight: 600;
  color: var(--hpk-muted);
}

/* --- {components.term-radio-card}: 2-up radio cards. The WHOLE CARD is the hit
 * target and it is a <label>, so the >=44px minimum is met by the box rather than by
 * the input. They stay 2-up at 390px - that is an explicit AC6 band. --- */
.hpk-client[class*="plugin-order"] .hpk-term-cards {
  display: grid;
  grid-template-columns: repeat(2, minmax(0, 1fr));
  gap: var(--hpk-space-2);
  margin-bottom: var(--hpk-space-3);
}
.hpk-client[class*="plugin-order"] .hpk-term-card {
  position: relative;
  display: flex;
  flex-direction: column;
  gap: 2px;
  min-height: 44px;
  margin: 0;
  padding: var(--hpk-space-2);
  border: 1px solid var(--hpk-border);
  border-radius: var(--hpk-r-md);
  background: var(--hpk-surface);
  cursor: pointer;
}
/* The radio is present, focusable and operable - it is moved out of sight, NEVER
 * display:none, which would remove it from the tab order and from the accessibility
 * tree and leave a radiogroup nothing can operate. */
.hpk-client[class*="plugin-order"] .hpk-term-card__input {
  position: absolute;
  width: 1px;
  height: 1px;
  margin: -1px;
  padding: 0;
  overflow: hidden;
  clip: rect(0 0 0 0);
  white-space: nowrap;
  border: 0;
}
.hpk-client[class*="plugin-order"] .hpk-term-card__name {
  font-weight: 600;
  font-size: .86rem;
  color: var(--hpk-ink);
}
.hpk-client[class*="plugin-order"] .hpk-term-card__price {
  font-size: var(--hpk-small-font-size);
  color: var(--hpk-muted);
}
.hpk-client[class*="plugin-order"] .hpk-term-card__permonth,
.hpk-client[class*="plugin-order"] .hpk-term-card__renews {
  font-size: var(--hpk-small-font-size);
  color: var(--hpk-muted);
}
/* Selected state, written TWICE on purpose - once with :has() and once with an
 * explicit class - so an engine without :has() still shows which term is selected.
 * Two separate rules, never one comma list. */
.hpk-client[class*="plugin-order"] .hpk-term-card:has(.hpk-term-card__input:checked) {
  border-color: var(--hpk-primary);
  background: var(--hpk-primary-tint);
  box-shadow: inset 0 0 0 1px var(--hpk-primary);
}
.hpk-client[class*="plugin-order"] .hpk-term-card.is-checked {
  border-color: var(--hpk-primary);
  background: var(--hpk-primary-tint);
  box-shadow: inset 0 0 0 1px var(--hpk-primary);
}
.hpk-client[class*="plugin-order"] .hpk-term-card:has(.hpk-term-card__input:focus-visible) {
  box-shadow: var(--hpk-focus);
}
.hpk-client[class*="plugin-order"] .hpk-term-card.is-focus {
  box-shadow: var(--hpk-focus);
}

/* --- The "Popular" pill. RECORDED DEVIATION FROM DESIGN.md:352, which specifies
 * {colors.secondary} background with #fff text: white on #F78326 measures 2.57:1 and
 * the pill is 700 / .6rem uppercase (~9.6px), i.e. NORMAL text, so the floor is
 * 4.5:1. It fails by a wide margin, in both themes.
 *
 * The certified pair is a LITERAL dark ink, and this codebase already reached the
 * same conclusion for the same hue: components.css:129-141 ships .hpk-btn-secondary
 * as #03123E on --hpk-secondary = 7.09:1, and documents why var(--hpk-ink) is wrong
 * here (it FLIPS to #FFFFFF in dark, which would re-fail at 2.57:1). --hpk-secondary
 * has no dark override, so a theme-agnostic literal holds in both themes.
 *
 * Added to the gen-contrast matrix as the term-popular cells rather than shipped on
 * trust. The DESIGN.md deviation is routed to the PO, never re-baselined. --- */
.hpk-client[class*="plugin-order"] .hpk-term-card__badge {
  position: absolute;
  top: -8px;
  inset-inline-end: var(--hpk-space-2);
  padding: 1px 6px;
  border-radius: 999px;
  background: var(--hpk-secondary);
  color: #03123E;
  font-size: .6rem;
  font-weight: 700;
  text-transform: uppercase;
  letter-spacing: .04em;
}

/* --- The rail body: order lines, totals, footnote, currency marker. --- */
.hpk-client[class*="plugin-order"] .hpk-rail-lines {
  margin: 0 0 var(--hpk-space-2);
  padding: 0;
  list-style: none;
  border-top: 1px solid var(--hpk-border);
}
.hpk-client[class*="plugin-order"] .hpk-rail-line {
  display: flex;
  align-items: baseline;
  gap: var(--hpk-space-2);
  padding: var(--hpk-space-2) 0;
  border-bottom: 1px solid var(--hpk-border);
}
.hpk-client[class*="plugin-order"] .hpk-rail-line__name {
  flex: 1 1 auto;
  min-width: 0;
  color: var(--hpk-ink);
  font-weight: 600;
  /* REVIEW FIX - A LONG UNBREAKABLE NAME MUST WRAP, NOT OVERFLOW.
   * `min-width: 0` lets the flex item SHRINK, but it does nothing about a single
   * unbreakable token: a 63-character domain label is one word, and in a 400px rail
   * (or 390px phone) it pushes the row wider than the page. AC6 requires ZERO
   * horizontal overflow at 390px, and the fixture's short names were simply never
   * going to catch it. `anywhere` is the modern property; `break-word` is the legacy
   * spelling older engines still honour, so both ship. */
  overflow-wrap: anywhere;
  word-break: break-word;
}
.hpk-client[class*="plugin-order"] .hpk-rail-line__price {
  flex: 0 0 auto;
  color: var(--hpk-ink);
}
/* The secondary line ({components.order-summary-rail}'s .line.addline): add-on and
 * per-option fee rows read as subordinate to the service they belong to. */
.hpk-client[class*="plugin-order"] .hpk-rail-line--addon .hpk-rail-line__name,
.hpk-client[class*="plugin-order"] .hpk-rail-line--addon .hpk-rail-line__price {
  font-weight: 400;
  font-size: var(--hpk-small-font-size);
  color: var(--hpk-muted);
}
/* The Remove control is a real <form> with a real submit, so it is an icon BUTTON
 * with an accessible name that NAMES THE DOMAIN. The form must not introduce a line
 * box of its own inside the flex row. */
.hpk-client[class*="plugin-order"] .hpk-rail-remove {
  flex: 0 0 auto;
  margin: 0;
  display: flex;
}
.hpk-client[class*="plugin-order"] .hpk-rail-remove__btn {
  min-width: 44px;
  min-height: 44px;
  padding: 0;
  border: 0;
  border-radius: var(--hpk-r-sm);
  background: transparent;
  color: var(--hpk-muted);
  cursor: pointer;
}
.hpk-client[class*="plugin-order"] .hpk-rail-remove__btn:hover {
  color: var(--hpk-danger-text);
}
.hpk-client[class*="plugin-order"] .hpk-rail-remove__btn:focus-visible {
  box-shadow: var(--hpk-focus);
}
.hpk-client[class*="plugin-order"] .hpk-rail-choose-domain {
  margin: 0 0 var(--hpk-space-2);
  font-size: var(--hpk-small-font-size);
}

.hpk-client[class*="plugin-order"] .hpk-rail-totals {
  margin: 0 0 var(--hpk-space-2);
}
.hpk-client[class*="plugin-order"] .hpk-rail-total-row {
  display: flex;
  justify-content: space-between;
  gap: var(--hpk-space-2);
  padding: 2px 0;
}
.hpk-client[class*="plugin-order"] .hpk-rail-total-row dt,
.hpk-client[class*="plugin-order"] .hpk-rail-total-row dd {
  margin: 0;
  font-size: var(--hpk-small-font-size);
  color: var(--hpk-muted);
  font-weight: 400;
}
/* "Due today" is the LARGEST NUMBER ON THE RAIL - the sealed hierarchy, and the one
 * figure the commitment bar repeats from the same server-rendered variable. */
.hpk-client[class*="plugin-order"] .hpk-rail-total-row--due {
  align-items: baseline;
  padding-top: var(--hpk-space-2);
  border-top: 1px solid var(--hpk-border);
}
.hpk-client[class*="plugin-order"] .hpk-rail-total-row--due dt {
  font-size: .95rem;
  font-weight: 600;
  color: var(--hpk-ink);
}
.hpk-client[class*="plugin-order"] .hpk-rail-total-row--due dd {
  /* §K (14.5, round-7 M3): the sealed fidelity row 24 reads "Due today (Urbanist 700 /
     1.35rem)" and this rule set the weight and the size but NOT the family, so the most
     prominent amount in the rail inherited the body face (measured: "Hind Siliguri").
     Nothing caught it because fidelity.js captured `dueFamily` and never asserted it.
     The pack already uses the display face for a sibling monetary amount —
     `.hpk-addon-card__amount` above — so this was an isolated omission, not a design
     choice, and the same idiom is used here verbatim. */
  font-family: var(--hpk-font-display, "Urbanist", system-ui, sans-serif);
  font-size: 1.35rem;
  font-weight: 700;
  color: var(--hpk-ink);
}
.hpk-client[class*="plugin-order"] .hpk-rail-renewal,
.hpk-client[class*="plugin-order"] .hpk-rail-currency {
  margin: 0 0 var(--hpk-space-1, 4px);
  font-size: var(--hpk-small-font-size);
  color: var(--hpk-muted);
}

/* Loading / error / exhausted / cleared. The rail states what it knows and never
 * leaves a number the server did not send (D18). `cleared` is 14.3's terminal
 * state: the server destroyed the cart, so the rail carries no lines, no totals
 * and no commitment bar at all - only this sentence. It reuses the certified
 * --hpk-danger-text on-surface pair the error state already uses, so it is not a
 * net-new coloured cell. */
.hpk-client[class*="plugin-order"] .hpk-rail-message {
  margin: 0;
  padding: var(--hpk-space-2) 0;
  font-size: var(--hpk-small-font-size);
  color: var(--hpk-text);
}
.hpk-client[class*="plugin-order"] .hpk-rail-message--error,
.hpk-client[class*="plugin-order"] .hpk-rail-message--exhausted,
.hpk-client[class*="plugin-order"] .hpk-rail-message--cleared {
  color: var(--hpk-danger-text);
}

/* --- The single rail CTA. --- */
.hpk-client[class*="plugin-order"] .hpk-rail__cta {
  margin-top: var(--hpk-space-3);
}
/* --- HosterPK 14.5 (2026-08-03) - §K SCOPED CONFORMANCE FIX: THE 44px TOUCH FLOOR
 * REACHES THE PACK'S OWN CTAs.
 *
 * MEASURED by 14.5's bands.js, and it is the first time anyone measured touch targets on
 * the RAIL: #hpk-rail-submit rendered at 32px, #hpk-bar-submit at 32px and the rail's
 * coupon Redeem submit at 34px, against AC3's explicit ">=44px in both states". They were
 * missed because 14.3's floor is scoped to the ACCOUNT REGION alone
 * (`#hpk-account-region .hpk-btn` et al), so #hpk-signup-submit got 44px and the page's
 * PRIMARY ACTION did not. .hpk-btn itself declares no min-height - it sizes from padding.
 *
 * `display` moves block -> flex, and that is part of the fix rather than churn: .hpk-btn
 * centres its label with inline-flex + align-items/justify-content, and the `block`
 * override discarded that. Growing a block button to 44px would top-align its text.
 * `width: 100%` is what makes it full-bleed, not the display value, so nothing else moves.
 *
 * The clearance the fixed bar reserves is `5.5em` (:2879) = 88px at the 16px root, and the
 * bar grows by 12px to roughly 69px, so the reservation still covers it - asserted by
 * fidelity row 20 and bands.js rather than argued here. --- */
.hpk-client[class*="plugin-order"] .hpk-rail__cta-btn {
  display: flex;
  width: 100%;
  min-height: 44px;
}
/* The rail's OTHER submits - the coupon Redeem control (summary.pdt:706) and the
 * commitment bar's CTA (summary.pdt:807, which renders INSIDE the repainted
 * #summary_section) - carried no floor at all.
 *
 * SCOPED TO THOSE TWO CONTROLS, AND THE REASON IS MEASURED (round-4 finding).
 * The first cut was `#summary_section .hpk-btn`, on the reasoning that "both are .hpk-btn
 * descendants of the rail host". True - and #summary_section is ALSO the injection host on
 * main.pdt:50 and main_packages.pdt:139, where summary.pdt renders its NON-RAIL shape. So
 * the rule additionally hit two controls it never named:
 *   · summary.pdt:748  <a class="hpk-btn hpk-btn-primary hpk-btn-sm float-right">
 *   · summary.pdt:883  the guest login submit
 * .hpk-btn-sm is the DESIGN.md-sanctioned small variant (components.css:184-187,
 * padding .35rem .75rem / font-size .8rem => about 27px) at specificity (0,1,0); the rule
 * was (1,3,0) and won outright, silently defeating the variant on two pack views whose
 * heights nothing in this story measures (fidelity.js:110 visits order/main/index only for
 * row 2's width counterfactual). A floor that reaches past its own comment is the D10 /
 * Trap 2 shape this epic keeps burning on.
 * Both targets are addressed by a hook they already carry, so no markup changes (D1):
 * the bar CTA by its id, the Redeem control by its input-group ancestor. */
.hpk-client[class*="plugin-order"] #hpk-bar-submit,
.hpk-client[class*="plugin-order"] #summary_section .input-group-append .hpk-btn {
  min-height: 44px;
}
.hpk-client[class*="plugin-order"] .hpk-rail__no-charge {
  margin: var(--hpk-space-2) 0 0;
  text-align: center;
  font-size: var(--hpk-small-font-size);
  color: var(--hpk-muted);
}

/* ==========================================================================
 * {components.checkout-bottom-bar} - the commitment bar.
 *
 * The bar is SERVER-RENDERED inside the summary fragment (D8), so its total is the
 * same PHP variable that rendered "Due today" - not a JS-synced copy, because a
 * second copy of a number is a defect waiting for a race.
 *
 * CONTAINING-BLOCK TRAP: a `fixed` descendant is captured by ANY ancestor carrying
 * transform, filter, perspective, backdrop-filter, will-change on those, or
 * contain: paint|layout|strict. `position: sticky` does NOT create one, which is why
 * .hpk-order-rail above is safe - but the bar sits inside .hpk-order-main /
 * .hpk-order-shell / .hpk-order-column, and a future transform anywhere up that chain
 * would silently re-anchor it to the card. Nothing here can prevent that, so it is
 * asserted BY OUTCOME instead: bar.js scrolls the page and requires the bar's
 * getBoundingClientRect().bottom to stay at the viewport bottom.
 *
 * CLEARANCE follows 13.4's PROVEN mechanism (:1376-1424), not a guessed value: the
 * measured height is published into a custom property, env(safe-area-inset-bottom) is
 * added to BOTH the bar's own bottom padding and the document clearance, an `em`
 * fallback keeps the no-JS lane safe, and the body padding is gated on :has() IN ITS
 * OWN RULE so an engine without :has() degrades to overlap rather than to a broken
 * page.
 *
 * IT DOES NOT REUSE .hpk-tally. DESIGN.md:365 says the bar is the same component
 * FAMILY as the selection tally - reuse the mechanics, not the hook. 13.4's rules are
 * keyed on .hpk-tally, which lookup.pdt alone emits, and sharing the class would make
 * Step 1's clearance respond to Step 2's bar.
 * ========================================================================== */
.hpk-client[class*="plugin-order"] .hpk-checkout-bar {
  display: none;
}
@media (max-width: 1020px) {
  .hpk-client[class*="plugin-order"] .hpk-checkout-bar {
    display: block;
    position: fixed;
    inset: auto 0 0 0;
    z-index: 20;
    padding: var(--hpk-space-2) var(--hpk-space-3);
    padding-bottom: calc(var(--hpk-space-2) + env(safe-area-inset-bottom, 0px));
    background: var(--hpk-surface);
    border-top: 1px solid var(--hpk-border);
    /* REVIEW FIX - use the SAME upward shadow the pack's other fixed bottom bar
     * already uses (the 13.4 selection tally, :1328), instead of an invented
     * brand-ink literal that no other rule in this file uses.
     *
     * The review asked for "a design token". There ISN'T one that fits, and saying so
     * is more useful than pretending: --hpk-shadow is `0 3px 10px` - a DOWNWARD
     * shadow - and a bar fixed to the bottom of the viewport casts upward. Every
     * upward shadow in this bundle is a literal for that reason. Matching the sibling
     * component is the real remedy; minting an --hpk-shadow-up token would need a
     * brand re-pin, which is out of this story's surface. Recorded in the ledger. */
    box-shadow: 0 -4px 14px rgba(0, 0, 0, .05);
  }
  .hpk-client[class*="plugin-order"] .hpk-checkout-bar__inner {
    display: flex;
    align-items: center;
    gap: var(--hpk-space-2);
    max-width: var(--hpk-space-container-xxl);
    margin-inline: auto;
  }
  .hpk-client[class*="plugin-order"] .hpk-checkout-bar__label {
    font-size: var(--hpk-small-font-size);
    color: var(--hpk-muted);
  }
  .hpk-client[class*="plugin-order"] .hpk-checkout-bar__total {
    font-size: 1.05rem;
    font-weight: 700;
    color: var(--hpk-ink);
  }
  .hpk-client[class*="plugin-order"] .hpk-checkout-bar__cta {
    margin-inline-start: auto;
  }
  /* The document clearance, in its OWN rule. .hpk-client IS the body element
   * (structure.pdt:321), so this reserves the bar's height at the END OF THE
   * DOCUMENT rather than inside a card that the fixed bar hangs over anyway. */
  .hpk-client[class*="plugin-order"]:has(.hpk-checkout-bar) {
    padding-bottom: calc(
      var(--hpk-checkout-bar-clearance, 5.5em) + var(--hpk-space-3) + env(safe-area-inset-bottom, 0px)
    );
  }
}

/* --- AC4 / gate finding 3: ONE PRIMARY PER ACTION ON SCREEN.
 *
 * THE SUPPRESSION IS GATED ON THE BAR'S PRESENCE, NOT ON THE VIEWPORT WIDTH, and the
 * distinction is load-bearing here in a way it was not in the mock: THE BAR LIVES IN
 * A JS-INJECTED FRAGMENT. A width-only rule would hide the rail CTA at <=1020px on a
 * NO-JS PHONE, where the bar never renders - leaving the buyer with NO SUBMIT CONTROL
 * AT ALL and no way to order. That is a worse failure than the duplicate CTA this
 * rule exists to prevent.
 *
 * So it FAILS OPEN: the un-suppressed rail CTA is the DEFAULT state, and only the
 * presence of a rendered bar removes it. An engine that cannot evaluate :has() keeps
 * the rail CTA, which is the safe direction - an extra CTA is a rubric finding, no CTA
 * is a broken funnel. Its own rule, never grouped. --- */
@media (max-width: 1020px) {
  .hpk-client[class*="plugin-order"] .hpk-order-rail:has(.hpk-checkout-bar) .hpk-rail__cta {
    display: none;
  }
}

/* --- <=1020px the grid collapses to one column with the RAIL AFTER THE FORM STACK.
 * Source order already puts it there, so this is a track change only - no `order`
 * property, and therefore no DOM-order/focus-order divergence to reconcile. --- */
@media (max-width: 1020px) {
  .hpk-client[class*="plugin-order"] .hpk-order-layout {
    grid-template-columns: minmax(0, 1fr);
    gap: var(--hpk-space-3);
  }
  .hpk-client[class*="plugin-order"] .hpk-order-rail {
    position: static;
    top: auto;
  }
}

/* ═══════════════════════════════════════════════════════════════════════════════
 * HosterPK 14.3 — the account region (sealed section 1) and the billing region
 * (sealed section 3), plus the affordances they need.
 *
 * SCOPE. Every rule is prefixed .hpk-client[class*="plugin-order"] so it
 * out-qualifies the frame tier. A bare .hpk-* class loses to any element-
 * qualified frame rule and does so SILENTLY, which is how a component ends up
 * looking almost right.
 *
 * TOKENS ONLY, AND ONLY TOKENS THAT EXIST. An undefined var() does not fall
 * back — it INHERITS (13.3), so a typo renders something plausible instead of
 * something obviously broken. Every custom property below appears in the token
 * list this bundle already defines.
 *
 * VISIBILITY IS display, NEVER a class or an attribute alone. `.hidden` in this
 * bundle ranks (0,3,0) and the [hidden] attribute is a UA rule, so both lose to
 * any element-qualified or display-declaring scoped rule. The regions are hidden
 * by the [hidden] attribute AND asserted with getClientRects(), never by class
 * presence.
 * ═══════════════════════════════════════════════════════════════════════════ */

/* ── The two host regions on the config page ──────────────────────────────── */
.hpk-client[class*="plugin-order"] .hpk-host-region[hidden],
.hpk-client[class*="plugin-order"] .hpk-host-region__body[hidden] {
  display: none;
}
.hpk-client[class*="plugin-order"] .hpk-host-region__body {
  margin-top: var(--hpk-space-3);
}
/* The loading and failure states of a region that has not received its fragment.
 * A failed fetch leaves the section hidden and says so; it never shows an empty
 * numbered card, which is D12's whole point. */
.hpk-client[class*="plugin-order"] .hpk-host-region__status {
  margin: 0;
  padding: var(--hpk-space-3);
  border: 1px solid var(--hpk-border);
  border-radius: var(--hpk-r-md);
  color: var(--hpk-muted);
  font-size: var(--hpk-small-font-size);
}
.hpk-client[class*="plugin-order"] .hpk-host-region__status--error {
  border-color: var(--hpk-danger);
  background: var(--hpk-danger-tint);
  color: var(--hpk-danger-text);
}

/* ── The signed-in identity card (AC2) ────────────────────────────────────── */
.hpk-client[class*="plugin-order"] .hpk-account-identity {
  display: flex;
  flex-wrap: wrap;
  align-items: baseline;
  gap: var(--hpk-space-2) var(--hpk-space-3);
  padding: var(--hpk-space-3);
  border: 1px solid var(--hpk-border);
  border-radius: var(--hpk-r-md);
  background: var(--hpk-g100);
}
.hpk-client[class*="plugin-order"] .hpk-account-identity__name {
  margin: 0;
  font-family: var(--hpk-font-display);
  font-weight: 600;
  color: var(--hpk-ink);
}
.hpk-client[class*="plugin-order"] .hpk-account-identity__email {
  margin: 0;
  /* A flex item's default min-width:auto refuses to shrink below its content,
   * so one long unbroken address pushes the card past the viewport. */
  min-width: 0;
  overflow-wrap: break-word;
  color: var(--hpk-muted);
  font-size: var(--hpk-small-font-size);
}
.hpk-client[class*="plugin-order"] .hpk-account-identity__signout {
  /* RTL-safe: `margin-inline-start: auto` pushes to the END of the line in both
   * directions; `margin: 0 0 0 auto` pins it to the physical left in RTL. */
  margin: 0;
  margin-inline-start: auto;
}
.hpk-client[class*="plugin-order"] .hpk-account-identity__note {
  flex-basis: 100%;
  margin: 0;
  color: var(--hpk-muted);
  font-size: var(--hpk-small-font-size);
}

/* ── Lanes, messages, actions ─────────────────────────────────────────────── */
.hpk-client[class*="plugin-order"] .hpk-account-lane[hidden] {
  display: none;
}
.hpk-client[class*="plugin-order"] .hpk-account-message:empty {
  display: none;
}
.hpk-client[class*="plugin-order"] .hpk-account-actions {
  display: flex;
  flex-wrap: wrap;
  align-items: center;
  gap: var(--hpk-space-3);
  margin-top: var(--hpk-space-3);
}
.hpk-client[class*="plugin-order"] .hpk-account-actions__link {
  color: var(--hpk-link);
  font-size: var(--hpk-small-font-size);
}
.hpk-client[class*="plugin-order"] .hpk-account-actions__link:hover {
  color: var(--hpk-link-hover);
}

/* ── Field layout ─────────────────────────────────────────────────────────── */
.hpk-client[class*="plugin-order"] .hpk-field-grid {
  display: grid;
  grid-template-columns: repeat(2, minmax(0, 1fr));
  gap: 0 var(--hpk-space-3);
}
/* Phone: one column. The seal's rule, and the reason the grid is declared with
 * minmax(0, 1fr) rather than 1fr — a bare 1fr lets a long <select> option force
 * the track wider than the container and overflow the page body. */
@media (max-width: 760px) {
  .hpk-client[class*="plugin-order"] .hpk-field-grid {
    grid-template-columns: minmax(0, 1fr);
  }
}
.hpk-client[class*="plugin-order"] .hpk-field-hint {
  margin: var(--hpk-space-1) 0 0;
  color: var(--hpk-muted);
  font-size: var(--hpk-small-font-size);
}
/* A single field is a single field, not a grid with one cell and a hole beside
 * it. The email input used .hpk-field-grid and left a blank column at >=760px
 * while the password pair below filled both (round 5). */
.hpk-client[class*="plugin-order"] .hpk-field-single {
  max-width: 100%;
}

/* ── VALIDATION ERRORS HAVE A VISUAL TREATMENT (AC5, round-5 HIGH) ──────────
 * `.hpk-field-hint--error` was declared in NO rule at all: an invalid field's
 * message rendered in exactly the muted grey, size and position of the password
 * constraint hint two fields above it, and the field itself was visually
 * identical to a valid one. The subtask claiming "colour never the only
 * indicator (icon + text always)" had neither an icon nor a colour behind it.
 *
 * COLOUR IS NEVER THE ONLY INDICATOR: the message carries an icon (markFieldError
 * builds it aria-hidden - it is duplicate information for AT, which already has
 * aria-invalid and aria-describedby), error-voiced text, and a weight change.
 *
 * NO NET-NEW COLOURED CELL: --hpk-danger-text on the card surface is the pair
 * `.hpk-field-error[data-hpk-invalid="1"]` already ships in this same sheet, and
 * the border reuses the --hpk-danger treatment `#domain[aria-invalid="true"]`
 * already uses. Both are existing certified pairs on this page. */
.hpk-client[class*="plugin-order"] .hpk-field-hint--error {
  display: flex;
  gap: var(--hpk-space-1);
  align-items: baseline;
  color: var(--hpk-danger-text);
  font-weight: 600;
}
/* DESIGN.md {components.input}: "Error: border -> danger". Supplementary only -
 * the message and aria-invalid carry the meaning for anyone who cannot see it. */
.hpk-client[class*="plugin-order"] #hpk-account-region [aria-invalid="true"],
.hpk-client[class*="plugin-order"] #hpk-billing-region [aria-invalid="true"],
.hpk-client[class*="plugin-order"] #hpk-account-fields [aria-invalid="true"],
.hpk-client[class*="plugin-order"] #hpk-billing-fields [aria-invalid="true"] {
  border-color: var(--hpk-danger);
}
.hpk-client[class*="plugin-order"] .hpk-field-legend {
  padding: 0;
  color: var(--hpk-ink);
  font-size: var(--hpk-small-font-size);
  font-weight: 600;
}

/* ── Password show/hide ───────────────────────────────────────────────────── */
.hpk-client[class*="plugin-order"] .hpk-password-wrap {
  position: relative;
  display: block;
}
.hpk-client[class*="plugin-order"] .hpk-password-toggle {
  position: absolute;
  top: 0;
  /* RTL: `right` does not flip for ar_xa / he_il. `inset-inline-end` is the
   * logical equivalent and is what the pack ships 23 locales for. The physical
   * property is kept FIRST as the fallback for engines without logical-property
   * support, then overridden. */
  right: 0;
  inset-inline-end: 0;
  /* FR43 / the Step-1 chip precedent: every interactive control clears 44px in
   * BOTH dimensions at 390px. A 44px-tall control that is 30px wide fails the
   * same criterion. */
  min-height: 44px;
  min-width: 44px;
  padding: 0 var(--hpk-space-3);
  border: 0;
  background: transparent;
  color: var(--hpk-link);
  font-size: var(--hpk-small-font-size);
  cursor: pointer;
}
.hpk-client[class*="plugin-order"] .hpk-password-toggle:hover {
  color: var(--hpk-link-hover);
}
.hpk-client[class*="plugin-order"] .hpk-password-toggle:focus-visible {
  /* Windows High Contrast / forced-colors DISCARDS box-shadow, so a
   * shadow-only ring leaves the control with no visible focus at all. A
   * transparent outline is invisible normally and is forced to the system
   * highlight colour in forced-colors mode. */
  outline: 2px solid transparent;
  outline-offset: 2px;
  box-shadow: var(--hpk-focus);
}
/* The label pair is swapped by STATE, not by script writing copy: both strings
 * are server-rendered from the locale file, and aria-pressed decides which is
 * shown. A toggle whose text is built in JS cannot be translated. */
.hpk-client[class*="plugin-order"] .hpk-password-toggle .hpk-password-toggle__hide,
.hpk-client[class*="plugin-order"] .hpk-password-toggle[aria-pressed="true"] .hpk-password-toggle__show {
  display: none;
}
.hpk-client[class*="plugin-order"] .hpk-password-toggle[aria-pressed="true"] .hpk-password-toggle__hide {
  display: inline;
}
.hpk-client[class*="plugin-order"] .hpk-password-wrap .form-control {
  /* Room for the toggle. Logical so it flips with the toggle itself. */
  padding-inline-end: 4.5rem;
}

/* ── The details disclosure (sealed component) ────────────────────────────── */
.hpk-client[class*="plugin-order"] .hpk-disclosure {
  margin-top: var(--hpk-space-3);
}
.hpk-client[class*="plugin-order"] .hpk-disclosure__trigger {
  min-height: 44px;
  padding: 0 var(--hpk-space-3);
  border: 1px dashed var(--hpk-border);
  border-radius: var(--hpk-r-sm);
  background: transparent;
  color: var(--hpk-ink);
  font-size: var(--hpk-small-font-size);
  cursor: pointer;
}
.hpk-client[class*="plugin-order"] .hpk-disclosure__trigger:hover {
  color: var(--hpk-primary);
  border-color: var(--hpk-primary);
}
.hpk-client[class*="plugin-order"] .hpk-disclosure__trigger:focus-visible {
  outline: 2px solid transparent;
  outline-offset: 2px;
  box-shadow: var(--hpk-focus);
}
/* CLOSED means display:none, not merely invisible: the panel's controls must be
 * out of the tab order AND out of the accessible tree. A visually-hidden
 * fallback achieves neither. */
.hpk-client[class*="plugin-order"] .hpk-disclosure__panel[hidden] {
  display: none;
}
.hpk-client[class*="plugin-order"] .hpk-disclosure__panel {
  margin-top: var(--hpk-space-3);
}

/* ── Billing tiers and captcha ────────────────────────────────────────────── */
.hpk-client[class*="plugin-order"] .hpk-billing-tier--primary {
  display: grid;
  grid-template-columns: repeat(2, minmax(0, 1fr));
  gap: 0 var(--hpk-space-3);
}
@media (max-width: 760px) {
  .hpk-client[class*="plugin-order"] .hpk-billing-tier--primary {
    grid-template-columns: minmax(0, 1fr);
  }
}
.hpk-client[class*="plugin-order"] .hpk-captcha {
  margin: var(--hpk-space-3) 0;
}

/* ── A quiet, link-shaped button (the sign-out control) ───────────────────── */
.hpk-client[class*="plugin-order"] .hpk-btn-link {
  min-height: 44px;
  padding: 0 var(--hpk-space-2);
  border: 0;
  background: transparent;
  color: var(--hpk-link);
  font-size: var(--hpk-small-font-size);
  cursor: pointer;
}
.hpk-client[class*="plugin-order"] .hpk-btn-link:hover {
  color: var(--hpk-link-hover);
  text-decoration: underline;
}

/* FR43 — THE 44px FLOOR APPLIES TO TEXT INPUTS AND SELECTS TOO, not only to
 * buttons and chips. MEASURED at 390px on the account and billing regions: the
 * bundle's .form-control renders 41px tall, so every field in both regions was
 * three pixels under the touch-target floor the Step-1 chip precedent set. The
 * rule is scoped to these two regions rather than to .form-control globally,
 * because widening every input in the client area is a different decision with
 * a different blast radius — and this story's surface does not include it. */
.hpk-client[class*="plugin-order"] #hpk-account-region .form-control,
.hpk-client[class*="plugin-order"] #hpk-billing-region .form-control,
.hpk-client[class*="plugin-order"] #hpk-account-fields .form-control,
.hpk-client[class*="plugin-order"] #hpk-billing-fields .form-control {
  min-height: 44px;
}

/* FR43, continued — THE TWO CONTROLS THE FIRST PASS MISSED, both MEASURED at
 * 390px rather than reasoned about:
 *   · the username-type radios rendered 13x13 (the UA default). Unlike the
 *     intent segment's, these are REAL visible radios, so the target is the
 *     radio itself and the row it sits in — the label is made a 44px-tall flex
 *     row and the control is given a 24px box inside it, so the whole row is
 *     hittable and the dot is still recognisably a radio.
 *   · the primary submit rendered 143x32. Height, not width, was the failure. */
.hpk-client[class*="plugin-order"] #hpk-account-region .radio > label,
.hpk-client[class*="plugin-order"] #hpk-account-fields .radio > label {
  display: flex;
  align-items: center;
  gap: var(--hpk-space-2);
  min-height: 44px;
  margin: 0;
  cursor: pointer;
}
.hpk-client[class*="plugin-order"] #hpk-account-region .radio > label input[type="radio"],
.hpk-client[class*="plugin-order"] #hpk-account-fields .radio > label input[type="radio"] {
  /* WITHOUT appearance:none, iOS Safari and some Android engines ignore the
   * width/height and paint the UA control at its default ~13px — the exact
   * touch-target failure this block exists to fix, invisible on desktop
   * Chromium where it was measured. The custom dot below replaces the native
   * paint; :checked keeps a real, visible selected state. */
  -webkit-appearance: none;
  appearance: none;
  border: 2px solid var(--hpk-border);
  border-radius: 50%;
  background: var(--hpk-surface);
  width: 24px;
  height: 24px;
  margin: 0;
  flex: 0 0 auto;
}
.hpk-client[class*="plugin-order"] #hpk-account-region .radio > label input[type="radio"]:checked,
.hpk-client[class*="plugin-order"] #hpk-account-fields .radio > label input[type="radio"]:checked {
  border-color: var(--hpk-primary);
  box-shadow: inset 0 0 0 4px var(--hpk-surface), inset 0 0 0 10px var(--hpk-primary);
}
/* ROUND-3 [LOW] — THE FOCUS RING MUST NOT ERASE THE SELECTED STATE.
 * The :checked dot is painted entirely with box-shadow, and this rule replaced
 * that property wholesale — so a checked radio lost its dot the moment it took
 * keyboard focus, which is precisely when the buyer most needs to see it. The
 * focused-AND-checked case composes both shadows; focused-and-unchecked keeps
 * the ring alone. */
.hpk-client[class*="plugin-order"] #hpk-account-region .radio > label input[type="radio"]:focus-visible,
.hpk-client[class*="plugin-order"] #hpk-account-fields .radio > label input[type="radio"]:focus-visible {
  outline: 2px solid transparent;
  outline-offset: 2px;
  box-shadow: var(--hpk-focus);
}
.hpk-client[class*="plugin-order"] #hpk-account-region .radio > label input[type="radio"]:checked:focus-visible,
.hpk-client[class*="plugin-order"] #hpk-account-fields .radio > label input[type="radio"]:checked:focus-visible {
  box-shadow: inset 0 0 0 4px var(--hpk-surface), inset 0 0 0 10px var(--hpk-primary), var(--hpk-focus);
}
.hpk-client[class*="plugin-order"] #hpk-account-region .hpk-btn,
.hpk-client[class*="plugin-order"] #hpk-billing-region .hpk-btn,
.hpk-client[class*="plugin-order"] #hpk-account-fields .hpk-btn {
  min-height: 44px;
}

/* REVIEW ROUND 2 [LOW] — the dead `.continue_form` lane relies on the bare
 * [hidden] attribute, which is only a UA rule and loses to ANY `display`
 * declaration on `.option_section` or `.hpk-card` from the frame tier (Trap 13).
 * The lane is measured unreachable and must never become visible, so the scoped
 * rule makes that explicit rather than inherited. */
.hpk-client[class*="plugin-order"] .continue_form[hidden],
.hpk-client[class*="plugin-order"] .option_section[hidden],
.hpk-client[class*="plugin-order"] .hpk-account-lane[hidden] {
  display: none;
}

/* ── ROUND 5: the elements whose visibility became load-bearing ─────────────
 * Every one of these is hidden by the `hidden` ATTRIBUTE and asserted with
 * getClientRects(), never by class presence (Trap 13) - and every one needs its
 * own scoped display:none, because the UA `[hidden]` rule loses to ANY
 * display-declaring rule from the frame tier (.form-group, .card, and the grid
 * on the billing tier all declare one). */
.hpk-client[class*="plugin-order"] .hpk-username-type .username[hidden],
.hpk-client[class*="plugin-order"] .hpk-billing-standalone-title[hidden],
.hpk-client[class*="plugin-order"] #hpk-billing-fields[hidden] {
  display: none;
}
/* Section 3's heading on the STANDALONE signup page only. The config page gets
 * its heading from the numbered card shell and never extracts this node, so the
 * two surfaces cannot end up with two headings over one card. It is the page's
 * first h2 (the only h1 is structure.pdt's page title). */
.hpk-client[class*="plugin-order"] .hpk-billing-standalone-title {
  margin: var(--hpk-space-5) 0 var(--hpk-space-3);
  color: var(--hpk-ink);
  font-size: var(--hpk-h3-font-size);
  font-weight: 700;
}
/* The wipe-recovery link sits on --hpk-danger-tint, where `.hpk-client a` would
 * otherwise repaint it --hpk-link - a link-on-danger-tint pair in NEITHER
 * theme's certified matrix. This puts it back on the certified
 * --hpk-danger-text/--hpk-danger-tint pair and underlines it, so it stays
 * identifiable as a link without relying on an unaudited hue. */
.hpk-client[class*="plugin-order"] .hpk-host-region__status-link {
  color: var(--hpk-danger-text);
  text-decoration: underline;
}

/* ============================================================================
 * Billing-details disclosure (checkout_contact_info.pdt). The prefilled
 * billing contact renders as text inside <summary> with an Edit affordance;
 * the form fields stay in the DOM (collapsed inputs still POST). Native
 * <details> - no JS needed to open. Token-driven, both themes.
 * ========================================================================== */
.hpk-billing {
  margin: 0 0 var(--hpk-space-3);
  border: 1px solid var(--hpk-border);
  border-radius: var(--hpk-r-md);
  background: var(--hpk-surface);
}
.hpk-billing__summary {
  display: flex;
  align-items: center;
  justify-content: space-between;
  gap: var(--hpk-space-2);
  padding: var(--hpk-space-3);
  cursor: pointer;
  list-style: none;
}
.hpk-billing__summary::-webkit-details-marker {
  display: none;
}
.hpk-billing__info {
  display: flex;
  flex-direction: column;
  gap: 2px;
  min-width: 0;
}
.hpk-billing__title {
  font-weight: 600;
  color: var(--hpk-ink);
}
.hpk-billing__text {
  color: var(--hpk-muted);
  font-size: var(--hpk-small-font-size);
  overflow-wrap: anywhere;
}
/* When the form is open the live fields are the source of truth - hide the
 * summary line rather than risk showing stale details next to fresh edits. */
.hpk-billing[open] .hpk-billing__text {
  display: none;
}
.hpk-billing__toggle {
  flex-shrink: 0;
  font-weight: 600;
  font-size: var(--hpk-small-font-size);
  color: var(--hpk-primary);
}
.hpk-billing__toggle-done {
  display: none;
}
.hpk-billing[open] .hpk-billing__toggle-edit {
  display: none;
}
.hpk-billing[open] .hpk-billing__toggle-done {
  display: inline;
}
.hpk-billing > h4 {
  margin: 0;
  padding: var(--hpk-space-2) var(--hpk-space-3);
}
.hpk-billing > .row {
  margin-left: 0;
  margin-right: 0;
  padding: 0 var(--hpk-space-3) var(--hpk-space-2);
}