/*
 * My Account shell (Task 3, task-3-brief.md) — the two-column grid, the
 * sidebar card, the welcome block and the nav list. Nothing past the shell:
 * `.st-account__content` is a bare grid-item safety net, and every endpoint
 * (orders, addresses, account details, …) rendered inside it belongs to a
 * later task.
 *
 * Measurements below are the "05 MINHA CONTA" artboard's own, copied
 * verbatim from task-3-brief.md's own "Resolved values" section rather than
 * re-measured here. Where a value matches an existing token exactly it uses
 * that token (268px does not — no token is 268px, so the grid track stays a
 * literal, same precedent checkout.css's own 380px/1160px measures set); where
 * it does not (14.5px font-size, 0.1em letter-spacing, 13.5px, 20px — none of
 * tokens.css's own type scale lands on these) it stays a literal too, per the
 * same "layout numbers are literals, colour/type/rhythm are tokens where one
 * exists" split checkout.css documents.
 */

.st-account {
  display: grid;
  grid-template-columns: 268px 1fr;
  gap: 32px;

  /* --st-container is 1360px, --st-gutter is 24px — both are exact matches
     for this screen's own container/padding numbers, so both are tokens
     rather than the literals they would otherwise have to be. */
  max-width: var(--st-container);
  margin-inline: auto;
  padding: 32px var(--st-gutter) var(--st-section-y);

  /* Not "stretch" (grid's own default): the content column will carry a
     tall orders table or address cards in later tasks while the sidebar
     stays a short, fixed-content card, and stretch would pull the sidebar's
     border down to match the taller column — same reasoning cart.css and
     checkout.css already give their own two-column shells for the same
     property. */
  align-items: start;
}

/*
 * Task 10 (task-10-brief.md): the shell's own responsive collapse — deferred
 * by every task from 3 through 9 (each one's own report/test names this same
 * gap; see e.g. this file's own "Payment methods and Downloads" section,
 * below, and account.spec.js's own Task 3/7/8 tests, each scoped around it
 * rather than fixing it). 899px matches the two other "N columns -> 1 column"
 * collapses already shipped in this file — `.st-account__addresses` (Task 6)
 * and `.st-account__auth--split` (Task 9) — both independently landing on
 * 899px for the same "bordered-card/panel pairing" shape this shell's own
 * sidebar-beside-content pairing shares, and checkout.css's own comment
 * records 767px already tried once in this codebase for a structurally
 * similar collapse and rejected. `.st-account__sidebar` is first in DOM
 * order (my-account.php's own docblock), so a single `1fr` track stacks it
 * above `.st-account__content` with no `order` property needed — the sidebar
 * was never the narrow column even before this fix (its own track is a fixed
 * 268px), it is the flexible `1fr` CONTENT column that squeezed toward zero
 * and is what actually needed this collapse.
 */
@media (max-width: 899px) {
  .st-account {
    grid-template-columns: 1fr;
  }
}

.st-account__sidebar {
  border: var(--st-rule);
  background: var(--st-surface);
}

/* A bare grid-item safety net — see this file's own header comment. Every
   endpoint template renders its own content here untouched; this class adds
   no visual treatment of its own. */
.st-account__content {
  min-width: 0;
}

/* --- Welcome block ------------------------------------------------------ */

.st-account__welcome {
  padding: 20px;
  border-block-end: var(--st-rule);
}

.st-account__welcome-label {
  margin: 0;
  color: var(--st-muted-2);
  font-size: var(--st-size-eyebrow);
  font-weight: var(--st-weight-extrabold);

  /* 0.1em is the artboard's own value for this one label — not
     --st-track-eyebrow (0.09em) or --st-track-eyebrow-wide (0.14em), which
     are close but not it. Kept as the literal task-3-brief.md gives rather
     than rounded onto a token that would quietly redraw the artboard. */
  letter-spacing: 0.1em;
  text-transform: uppercase;
}

.st-account__welcome-name {
  margin: 6px 0 0;

  /* Coincides with --st-size-price-row (20px), but that token names a cart
     line-item price — reusing it here for a person's name would read as a
     borrowed meaning the next reader has to untangle, so this stays its own
     literal instead, same call checkout.css already makes for its own
     14.5px/15px row sizes. */
  font-size: 20px;
  font-weight: var(--st-weight-extrabold);
}

.st-account__welcome-email {
  margin: 4px 0 0;
  color: var(--st-muted);
  font-size: 13.5px;
}

/* --- Nav ------------------------------------------------------------------ */

.st-account__nav ul {
  margin: 0;
  padding: 0;
  list-style: none;
}

.st-account__nav-item {
  display: block;
  padding: 14px 20px;
  border-block-start: 1px solid var(--st-hairline);
  color: var(--st-ink);
  font-size: 14.5px;
  font-weight: var(--st-weight-regular);
  text-decoration: none;
  transition: background-color var(--st-transition), color var(--st-transition);
}

/*
 * Background only — deliberately no `color` override here. base.css's own
 * sitewide `a:hover, a:active { color: var(--st-accent-deep); }` already
 * applies underneath this (a nav item is a plain list link, the exact case
 * that sitewide rule exists for), so an inactive item's text goes
 * accent-deep on hover on top of this tint. task-3-brief.md's own resolved
 * values name the background only for this state, and the sitewide link
 * rule is the design system's own answer for the text colour — restating it
 * here would just be a second copy of a value this file does not own.
 */
.st-account__nav-item:hover,
.st-account__nav-item:active {
  background: var(--st-accent-tint);
}

/* The first item sits directly under the welcome block's own 2px rule
   (--st-rule, above); giving it a second, 1px rule one pixel below that
   reads as a stray double edge rather than a separator, so it is the one
   item that does not carry the hairline every other inactive item gets.
   Placed after the :hover/:active rule above to satisfy stylelint's
   no-descending-specificity (this selector's specificity is higher) —
   purely a source-order convention, the same one nav.css's own header
   comment documents; the two never contend on the same declaration. */
.st-account__nav li:first-child > .st-account__nav-item {
  border-block-start: none;
}

/*
 * The current endpoint. wc_is_current_account_menu_item() (navigation.php)
 * is what decides which item gets this class AND aria-current="page" — both
 * come from the one PHP variable, so they cannot disagree with each other.
 * Restated ahead of :hover/:active above only where it needs to win against
 * them (the tint hover would otherwise wash out the solid ink the moment a
 * pointer rests on the active item — the same override
 * .st-payment__radio:not(:checked):hover already needs in checkout.css, run
 * in reverse: here the STATE, not the hover, is what must win).
 */
.st-account__nav-item--active,
.st-account__nav-item--active:hover,
.st-account__nav-item--active:active {
  border-block-start-color: var(--st-ink);
  background: var(--st-ink);
  color: var(--st-surface);
  font-weight: var(--st-weight-bold);
}

/*
 * Focus rings: no rule here on purpose. base.css's own
 * `:focus-visible { outline: var(--st-focus-width) solid var(--st-accent);
 * outline-offset: var(--st-focus-offset); }` is unscoped — it already
 * applies to every nav link on this page — and --st-focus-width/
 * --st-focus-offset are both 2px, exactly task-3-brief.md's own "outline:
 * 2px solid var(--st-accent); outline-offset: 2px". A second copy here would
 * be a value this screen would then have to keep in step with the site-wide
 * one for no reason.
 */

/* --- Orders (Task 4, task-4-brief.md) ------------------------------------
 *
 * `.st-account__title`, the delivery tracker card (`.st-order-progress*`)
 * and the history table (`.st-orders-table*`) — all built against
 * woocommerce/myaccount/orders.php. Measurements are task-4-brief.md's own
 * "Resolved values", used verbatim; a value gets a token only where one is
 * an EXACT match (--st-size-h1 is 34px, --st-track-h1 is -0.03em, etc.) —
 * the same "layout numbers are literals, colour/type/rhythm are tokens
 * where one exists" split account.css's own header comment and
 * checkout.css already document. Where the brief names a size or
 * letter-spacing tokens.css has nothing exact for (13px chip text lands on
 * --st-size-label exactly, but 15.5px item names and 0.08em/0.1em
 * letter-spacings do not), it stays a literal.
 */

.st-account__title {
  margin: 0 0 20px;
  padding-bottom: 16px;
  border-block-end: var(--st-rule);
  font-size: var(--st-size-h1);
  font-weight: var(--st-weight-black);
  letter-spacing: var(--st-track-h1);
}

/* --- Delivery tracker card ------------------------------------------------ */

.st-order-progress {
  margin-bottom: 32px;
  border: 2px solid var(--st-accent);
  background: var(--st-surface);
}

.st-order-progress__head {
  display: flex;
  align-items: center;
  justify-content: space-between;
  gap: 16px;
  padding: 14px 20px;
  border-block-end: 2px solid var(--st-accent);
  background: var(--st-accent-tint);
}

.st-order-progress__id {
  color: var(--st-accent-ink);
  font-size: var(--st-size-label); /* 13px — an exact match for tokens.css. */
  font-weight: var(--st-weight-extrabold);

  /* 0.08em is task-4-brief.md's own value for this label — close to but not
     --st-track-eyebrow (0.09em), so it stays the literal the brief gives
     rather than a token that would quietly redraw the artboard, the same
     call navigation.php's own 0.1em welcome-label makes. */
  letter-spacing: 0.08em;
  text-transform: uppercase;
}

/* The delivery-window string — a full sentence ("Aguardando confirmação de
   pagamento"), not a label, so no uppercase/tracking here even though it
   shares the head's accent-ink colour. Renders nothing at all for
   `processing` (AccountScreen::delivery_progress()'s own `message => null`
   — see orders.php's own comment on why no ETA is invented in its place). */
.st-order-progress__window {
  color: var(--st-accent-ink);
  font-size: var(--st-size-label);
  font-weight: var(--st-weight-bold);
}

.st-order-progress__body {
  display: grid;
  grid-template-columns: 1fr 260px;
  gap: 32px;
  padding: 20px;
}

/*
 * Task 10 (task-10-brief.md): stacks to one column — the summary sits BELOW
 * the item details rather than being squeezed beside them (the brief's own
 * "reachable below the item details rather than clipped").
 *
 * 599px, not the shell's own 899px: this split is NOT the "N independently
 * bordered cards side by side" shape `.st-account__addresses` (Task 6) and
 * `.st-account__auth--split` (Task 9) both collapse at 899px — it is two
 * BARE regions (an item list, a summary) inside ONE already-bordered card,
 * the same shape `.st-account-form__row`'s own bare paired `<p>` fields
 * (Task 7) and `.st-address-form__fields`'s own bare paired cells (Task 6)
 * already collapse at 599px, not 899px. Confirmed against real content
 * widths rather than picked blind: once the shell itself has stacked (below
 * 899px), the content column's own width tracks the viewport directly
 * (`viewport - 2*24px gutter`), reaching only ~342px at the 360px width
 * task-10-brief.md's own Step 1 names — nowhere near enough for a 260px
 * fixed summary column plus a legible item column alongside it. At 599px
 * (unstacked, non-collapsed shell case near the shell's own 899px edge) the
 * content column is still >=550px, comfortably enough for both columns
 * side by side; below 599px it is not.
 */
@media (max-width: 599px) {
  .st-order-progress__body {
    grid-template-columns: 1fr;
  }

  .st-order-progress__summary {
    padding-left: 0;
    border-inline-start: 0;
    border-block-start: 2px solid var(--st-rule-soft);
    padding-top: 20px;
    margin-top: 20px;
  }
}

.st-order-progress__items {
  min-width: 0;
}

.st-order-progress__item {
  display: flex;
  align-items: center;
  gap: 14px;
  margin-bottom: 20px;
}

.st-order-progress__image {
  width: 78px;
  height: 66px;
  flex-shrink: 0;
  border: var(--st-rule);
  object-fit: cover;
}

.st-order-progress__item-name {
  margin: 0;
  font-size: 15.5px; /* No token lands on 15.5px — see header comment. */
  font-weight: var(--st-weight-bold);
}

.st-order-progress__item-meta {
  margin: 4px 0 0;
  color: var(--st-muted);
  font-size: var(--st-size-label);
}

.st-order-progress__bar {
  display: flex;
  gap: 4px;
}

.st-order-progress__segment {
  height: 6px;
  flex: 1;
  background: var(--st-hairline);
}

.st-order-progress__segment--done {
  background: var(--st-accent);
}

.st-order-progress__labels {
  display: flex;
  justify-content: space-between;
  margin-top: 8px;
  color: var(--st-muted);
  font-size: var(--st-size-caption);
}

.st-order-progress__summary {
  padding-left: 24px;

  /* rgb(32 30 29 / 40%) — "40% ink opacity" — is exactly --st-rule-soft's
     own value. */
  border-inline-start: 2px solid var(--st-rule-soft);
}

.st-order-progress__summary-label {
  margin: 0;
  color: var(--st-muted);
  font-size: var(--st-size-label);
}

.st-order-progress__summary-total {
  margin: 6px 0 20px;
  font-size: var(--st-size-price-card); /* 24px — an exact match. */
  font-weight: var(--st-weight-black);
  letter-spacing: var(--st-track-h2); /* -0.02em — an exact match. */
}

.st-order-progress__cta {
  display: inline-flex;
  align-items: center;
  justify-content: center;

  /* task-4-brief.md's own artboard value is 42px, but that falls short of
     the plan's global "touch targets >= 44px on both axes" constraint —
     --st-h-touch (44px) is used instead, the same deviation
     CheckoutScreen.php already documents for select2's native ~28px
     control (dequeued rather than shipped at its native, sub-44px size). */
  height: var(--st-h-touch);
  padding: 0 16px;
  background: var(--st-ink);
  color: var(--st-surface);
  font-size: var(--st-size-caption); /* 12.5px — an exact match. */
  font-weight: var(--st-weight-extrabold);
  letter-spacing: var(--st-track-button); /* 0.05em — an exact match. */
  text-decoration: none;
  text-transform: uppercase;
  transition: background-color var(--st-transition);
}

/*
 * `color` is restated here even though it never changes: base.css's own
 * unscoped `a:hover, a:active { color: var(--st-accent-deep); }` (0,1,1)
 * outranks this class's own base `color: var(--st-surface)` (0,1,0) the
 * moment :hover/:active applies, which would otherwise swap this button's
 * white label for dark-red text on top of the --st-accent background below
 * — the same specificity fight .st-account__nav-item--active's own
 * :hover/:active override (account.css, above) already documents, run
 * against a solid button instead of a list link.
 */
.st-order-progress__cta:hover,
.st-order-progress__cta:active {
  background: var(--st-accent);
  color: var(--st-surface);
}

/* --- Order history table --------------------------------------------------- */

/*
 * Task 10 (task-10-brief.md): "account tables scroll horizontally inside
 * their own `overflow-x: auto` container rather than the page itself
 * overflowing" — `.st-account__table-scroll`, a bare wrapper `<div>` around
 * each table, the exact same "a bare wrapper added purely so the real table
 * can be targeted/contained by a scoped selector" pattern
 * `.st-account__downloads` (Task 8, below) and `.st-order-detail` (Task 5,
 * below) already establish in this same file, reused rather than reinvented.
 *
 * `display: block; overflow-x: auto;` applied DIRECTLY to the `<table>`
 * element itself (no wrapper) was tried first and reverted: Chromium still
 * lays the table out correctly (children keep real table-row/-cell layout
 * via an anonymous table box), but that ANONYMOUS inner box does not inherit
 * the outer `<table>` element's own `width: 100%` — only the outer
 * (now-block) box does — so at a width wider than the table's own natural
 * content needs (confirmed live: the orders history table at 1440px), the
 * bordered box stayed full-width but the thead's ink band and row dividers
 * stopped short of its own right edge, leaving a dead grey gap INSIDE the
 * border that was never there before this task. A real wrapper `<div>` does
 * not have that failure mode: the `<table>` keeps its native `display: table`
 * and its own `width: 100%` still resolves against (and fills) the wrapper,
 * exactly as it did before this task at every width the shell was already
 * wide enough not to need scrolling at all.
 */
.st-account__table-scroll {
  overflow-x: auto;
}

.st-orders-table {
  width: 100%;
  border: var(--st-rule);
  border-collapse: collapse;
}

.st-orders-table th,
.st-orders-table td {
  padding: 14px 18px;
  text-align: left;
}

.st-orders-table thead {
  background: var(--st-ink);
  color: var(--st-surface);
}

.st-orders-table tbody tr {
  border-block-start: 2px solid var(--st-rule-soft);
}

/*
 * Task 11 (task-11-brief.md): the whole-screen sweep measured this at
 * 40x17px live — a real, previously-uncaught 44px-floor violation (no
 * earlier task's own test ever measured this selector; `.st-orders-table`
 * itself has existed since Task 4). Same fix, same reasoning
 * `.st-address-card__edit` (Task 6) and `.st-auth-card__lost-password a`
 * (Task 9) already apply to an identical shape of control — a bare text
 * link with no button chrome: `inline-flex` + `align-items: center` +
 * `min-height: var(--st-h-touch)`. `min-width` is also needed here and was
 * not on either precedent, because a short order number ("#118") is
 * narrower than 44px even once the height clears the floor — the
 * precedents' own link text ("Editar"/"Esqueceu a senha?") never has that
 * problem.
 */
.st-orders-table__number {
  display: inline-flex;
  align-items: center;
  min-height: var(--st-h-touch);
  min-width: var(--st-h-touch);
  color: var(--st-ink);
  font-weight: var(--st-weight-bold);
}

.st-orders-table__status {
  display: inline-block;
  padding: 4px 9px;
  border: 1px solid var(--st-line);
  background: var(--st-skeleton);
  font-size: var(--st-size-caption); /* 12.5px — an exact match. */
  font-weight: var(--st-weight-bold);
}

/*
 * Colour is deliberately absent here: base.css's own sitewide
 * `a:hover, a:active { color: var(--st-accent-deep); }` already applies —
 * an action link is a plain text link, the same case
 * .st-account__nav-item's own hover comment (above) already documents for
 * this exact rule, restated here for the same reason.
 *
 * Task 11: measured at 82x14px live — width already clears 44px (the
 * uppercase caption text is long enough on its own), but height did not.
 * Same `inline-flex`/`align-items: center`/`min-height: var(--st-h-touch)`
 * fix as `.st-orders-table__number` above, no `min-width` needed here.
 */
.st-orders-table__action {
  display: inline-flex;
  align-items: center;
  min-height: var(--st-h-touch);
  margin-inline-end: 12px;
  color: var(--st-ink);
  font-size: var(--st-size-caption); /* 12.5px — an exact match. */
  font-weight: var(--st-weight-bold);
  letter-spacing: var(--st-track-button); /* 0.05em — an exact match. */
  text-decoration: none;
  text-transform: uppercase;
}

/*
 * Task 8 (task-8-brief.md): payment-methods.php's own table, rendered only
 * when `$has_methods` is true. That template adds `.st-orders-table`
 * ALONGSIDE core's own `woocommerce-MyAccount-paymentMethods`/`shop_table`/
 * `account-payment-methods-table` classes directly on the `<table>` — the
 * same dual-class reuse this file's own orders table (above) already
 * establishes for the identical selector — so every declaration in THIS
 * section already applies to it verbatim; nothing new to declare for the
 * table itself. `.st-account__payment-table` adds only the one thing this
 * section's own table does not need — bottom margin, because payment-
 * methods.php's table is followed directly by the "Adicionar forma de
 * pagamento" CTA rather than pagination. Styled but unexercised on this
 * fixture — `conta.teste` has no saved payment method to render a real row
 * for (task-8-report.md's own "what was found live").
 */
.st-account__payment-table {
  margin-bottom: 20px;
}

/*
 * downloads.php's own table — the REAL one core's own
 * `woocommerce_order_downloads_table()` renders (order/order-downloads.php's
 * own `.woocommerce-table--order-downloads`, confirmed live reading that
 * chain) into downloads.php's own `.st-account__downloads` wrapper, when
 * `$has_downloads` is true. Scoped under that wrapper the same way
 * `.st-order-detail .woocommerce-table--order-details` (this file's own
 * "Single order view" section, below) already scopes a different real
 * core-rendered class under a wrapper that task's own template adds. Every
 * declaration below restates this section's own `.st-orders-table`
 * treatment verbatim against that different real selector, rather than
 * inventing a third table style, per task-8-brief.md's own instruction.
 * Styled but unexercised on this fixture — `conta.teste` has no
 * downloadable product to render a real row for.
 */

/*
 * Task 10 (task-10-brief.md): `.st-account__downloads` is ALREADY a real
 * wrapper `<div>` immediately around this table (downloads.php's own
 * docblock) — the exact shape `.st-account__table-scroll` (above) adds on
 * purpose elsewhere, already present here, so `overflow-x: auto` is added
 * directly to it rather than introducing a second, redundant wrapper.
 */
.st-account__downloads {
  overflow-x: auto;
}

.st-account__downloads .woocommerce-table--order-downloads {
  width: 100%;
  margin: 0;
  border: var(--st-rule);
  border-collapse: collapse;
}

.st-account__downloads .woocommerce-table--order-downloads th,
.st-account__downloads .woocommerce-table--order-downloads td {
  padding: 14px 18px;
  text-align: left;
}

.st-account__downloads .woocommerce-table--order-downloads thead {
  background: var(--st-ink);
  color: var(--st-surface);
}

.st-account__downloads .woocommerce-table--order-downloads tbody tr {
  border-block-start: 2px solid var(--st-rule-soft);
}

/* --- Single order view (Task 5, task-5-brief.md) ---------------------------
 *
 * `.st-order-detail` wraps woocommerce/myaccount/view-order.php's whole
 * output (that file's own docblock). No mockup exists for this endpoint —
 * task-5-brief.md is explicit that it "extends the same table/typography
 * system Task 4 establishes" rather than drawing anything new, so nothing
 * below invents a value Task 4 did not already set: the line-items table
 * reuses `.st-orders-table`'s own border/thead/padding/divider rules
 * verbatim (just re-declared against `.woocommerce-table--order-details` —
 * the real class WooCommerce's own `order/order-details.php` renders via
 * `woocommerce_view_order`, confirmed live rather than assumed; see
 * task-5-report.md's "what WooCommerce actually renders" section for the
 * full markup this was checked against), and the intro sentence reuses
 * checkout's own `.st-thankyou__lede` treatment (thankyou.css) — the one
 * existing "page-intro sentence" this design system already has, and an
 * exact precedent for task-5-brief.md's own instruction to "check
 * tokens.css for a body-text size that's already used for similar intro
 * sentences elsewhere".
 */

.st-order-detail__intro {
  margin: 0 0 24px;
  font-size: var(--st-size-body); /* 16.5px — matches .st-thankyou__lede. */
  line-height: var(--st-lh-body);
}

/*
 * Core wraps the order number/date/status in bare `<mark>` elements
 * (view-order.php's own docblock — copied verbatim from WooCommerce's own
 * template). Left unstyled, the browser's UA stylesheet paints those a
 * flat yellow highlight — confirmed live, a colour this palette does not
 * have anywhere else (tokens.css is ink, greys and one red; components/
 * notice.css's own header comment already documents this theme deliberately
 * not inventing a colour outside that set). Emphasis is kept, the clashing
 * highlight is not: bold ink text, no background, matching how every other
 * inline emphasis in this design system (e.g. `.st-orders-table__number`,
 * above) carries weight through font-weight rather than a highlight colour.
 */
.st-order-detail__intro mark {
  background: none;
  color: inherit;
  font-weight: var(--st-weight-bold);
}

/* --- Order notes -----------------------------------------------------------
 *
 * task-5-brief.md's own resolved value asks for "a bordered card treatment
 * consistent with this theme's other card elements", naming --st-rule's 2px
 * ink border as the theme's standard weight but explicitly leaving room to
 * judge it too heavy for a small note. It is: every other 2px-ink-bordered
 * "card" in this theme (.st-order-progress above, .st-store in lojas.css)
 * carries a heading band, a multi-line body and/or a price — enough visual
 * weight that a heavy frame reads as a container. A note here is one
 * timestamp line plus one short sentence; framing that in the same 2px used
 * for a delivery-tracker card reads as over-built for the content, the same
 * "does this content carry that much weight" judgment call
 * .st-account__welcome-name (account.css, above) already documents for
 * picking a literal over a coincidentally-matching token. --st-rule-thin
 * (1px solid var(--st-hairline)) is used instead — still a real, visible
 * border (not a borderless list item), just the lighter of this theme's two
 * named rule weights.
 */
.st-order-detail__notes {
  display: grid;
  gap: 12px;
  margin: 0 0 32px;
  padding: 0;
  list-style: none;
}

.st-order-detail__note {
  padding: 14px 18px; /* Matches .st-orders-table's own cell padding. */
  border: var(--st-rule-thin);
  background: var(--st-surface);
}

/*
 * `woocommerce-OrderUpdate-meta`/`-description` carry capitals
 * .stylelintrc's frozen selector-class-pattern does not admit — the same
 * `[class~="…"]` attribute-selector escape components/notice.css's own
 * header comment already documents for `woocommerce-NoticeGroup`, reused
 * here rather than inventing a second convention for the same problem.
 */
.st-order-detail__note [class~="woocommerce-OrderUpdate-meta"] {
  margin: 0 0 6px;
  color: var(--st-muted);
  font-size: var(--st-size-caption); /* 12.5px — an exact match. */
  font-weight: var(--st-weight-bold);
}

.st-order-detail__note [class~="woocommerce-OrderUpdate-description"] p {
  margin: 0;
  font-size: var(--st-size-body-sm); /* 14px — an exact match. */
  line-height: var(--st-lh-body);
}

/* --- Line-items table -------------------------------------------------------
 *
 * `.woocommerce-table--order-details` is the real class
 * order/order-details.php renders (not overridden by this task — see
 * view-order.php's own docblock) — styled here by that name, scoped under
 * `.st-order-detail` so it never leaks onto the SAME class thankyou.css
 * already styles differently (its own `.st-thankyou` scope, a deliberately
 * separate, lighter treatment for that screen).
 *
 * This table renders WITH a `<thead>` on this install (confirmed live:
 * "Product"/"Total" column headers) — unlike the brief's own caveat that
 * some WooCommerce order-details tables render without one, this one does,
 * so `.st-orders-table`'s exact thead treatment applies unmodified. No
 * product thumbnails are rendered by core's own order-details-item.php on
 * this install either (confirmed live) — task-5-brief.md is explicit that
 * this is not scope to add.
 */

/*
 * Task 10 (task-10-brief.md): `.st-order-detail` (above) wraps the intro
 * sentence and the notes list too, not just the table — scoping
 * `overflow-x: auto` there directly would be correct in practice (neither
 * of those two ever overflows) but broader than what it is actually for, so
 * `.st-order-detail__scroll` is a new, narrowly-scoped wrapper `<div>`
 * view-order.php (below) adds around ONLY `do_action( 'woocommerce_view_order',
 * $order_id )` — the same real hook that renders this table (this file's own
 * "Single order view" section header comment) — matching
 * `.st-account__table-scroll`'s own shape (above) exactly.
 */
.st-order-detail__scroll {
  overflow-x: auto;
}

.st-order-detail .woocommerce-table--order-details {
  width: 100%;
  margin: 0 0 32px;
  border: var(--st-rule);
  border-collapse: collapse;
}

.st-order-detail .woocommerce-table--order-details th,
.st-order-detail .woocommerce-table--order-details td {
  padding: 14px 18px;
  text-align: left;
}

.st-order-detail .woocommerce-table--order-details thead {
  background: var(--st-ink);
  color: var(--st-surface);
}

.st-order-detail .woocommerce-table--order-details tbody tr,
.st-order-detail .woocommerce-table--order-details tfoot tr {
  border-block-start: 2px solid var(--st-rule-soft);
}

/*
 * The final total row — the one figure on this table a shopper actually
 * checks against what they paid. `.st-orders-table` has no tfoot of its own
 * to match (it is a list of orders, not one order's totals), so this is a
 * sensible extension rather than a reused value: the same
 * heavier-weight-for-the-one-number-that-matters call
 * `.st-order-progress__summary-total` (above) already makes for this
 * table's own equivalent row. WooCommerce's own `get_order_item_totals()`
 * gives the final row no distinguishing class of its own (confirmed live —
 * no `.order-total` or similar; task-5-report.md notes this), so it is
 * targeted structurally instead.
 */
.st-order-detail .woocommerce-table--order-details tfoot tr:last-child th,
.st-order-detail .woocommerce-table--order-details tfoot tr:last-child td {
  font-weight: var(--st-weight-black);
}

/* --- Addresses (Task 6, task-6-brief.md) -----------------------------------
 *
 * woocommerce/myaccount/my-address.php (`.st-account__addresses`,
 * `.st-address-card`) and form-edit-address.php (`.st-address-form__fields`
 * and its cell spans, the submit button).
 *
 * The address-form grid reuses the APPROACH
 * woocommerce/checkout/form-billing.php already established for its own
 * six-column grid — a field-key => column-span map, `.st-field`/
 * `.st-field__label` on each rendered field — but not its literal CSS
 * classes. `Assets::screen()` loads exactly one screen stylesheet per
 * request (checkout.css on checkout, this file on /minha-conta/), so a class
 * that exists only in checkout.css (`.st-checkout__cell--N`) would render
 * completely unstyled here. `.st-address-form__fields`/
 * `.st-address-form__cell--N` are this file's own copies of the same
 * six-column/14px-gap/span-N structure, matching checkout's own spans for
 * the equivalent fields (CEP 2, Endereço 4, Número 2, Complemento 2, Bairro
 * 2, Cidade/Estado/País 2 apiece) so a field looks the same whether it is
 * filled in at checkout or from this screen.
 *
 * `.st-address-card`'s border is `--st-rule` (2px solid var(--st-ink)) — this
 * theme's own standard card weight, and an exact match for task-6-brief.md's
 * own "2px solid var(--st-ink) border (this theme's standard card border
 * weight)", so it is the token here rather than the literal, the same
 * `.st-account__sidebar` (account.css, above) already uses it.
 */

.st-account__addresses {
  display: grid;
  grid-template-columns: repeat(2, minmax(0, 1fr));
  gap: 24px;
}

@media (max-width: 899px) {
  .st-account__addresses {
    grid-template-columns: 1fr;
  }
}

.st-address-card {
  border: var(--st-rule);
  background: var(--st-surface);
}

.st-address-card__head {
  display: flex;
  align-items: center;
  justify-content: space-between;
  gap: 16px;
  padding: 14px 20px;
  border-block-end: var(--st-rule);
}

.st-address-card__title {
  margin: 0;
  font-size: var(--st-size-label);
  font-weight: var(--st-weight-extrabold);
  letter-spacing: var(--st-track-eyebrow);
  text-transform: uppercase;
}

/*
 * Colour is deliberately absent: base.css's own sitewide
 * `a:hover, a:active { color: var(--st-accent-deep); }` already applies —
 * a plain text link, the same case .st-account__nav-item's own hover
 * comment (above) already documents for this exact rule.
 *
 * Fix round 1 (code review): with no padding/min-height/line-height of its
 * own, this link's rendered box was just its inline text at 12.5px — roughly
 * 17-19px tall at EVERY viewport width, not only narrow ones (so this is not
 * an instance of `.st-account`'s own deferred mobile-collapse gap, which is
 * about the outer shell squeezing at narrow widths — this box was under the
 * 44px floor even at full desktop width). `display: inline-flex` +
 * `align-items: center` + `min-height: var(--st-h-touch)` is the same
 * technique `.st-checkout__help` (checkout.css) already uses for its own
 * plain-text link: it grows the tap target without adding a background or
 * padding that would make this read as a button, which the review
 * explicitly asked to avoid — this stays a text link, just a taller one.
 */
.st-address-card__edit {
  display: inline-flex;
  align-items: center;
  min-height: var(--st-h-touch);
  color: var(--st-ink);
  font-size: var(--st-size-caption); /* 12.5px — an exact match. */
  font-weight: var(--st-weight-bold);
  letter-spacing: var(--st-track-button); /* 0.05em — an exact match. */
  text-decoration: none;
  text-transform: uppercase;
}

.st-address-card__body {
  padding: 20px;
  font-style: normal;
  line-height: var(--st-lh-body);
}

.st-address-card__empty {
  margin: 0;
  color: var(--st-muted);
}

/* --- Edit-address form ------------------------------------------------- */

.st-address-form__title {
  margin: 0 0 20px;
  font-size: var(--st-size-h2);
  letter-spacing: var(--st-track-h2);
}

.st-address-form__fields {
  display: grid;
  grid-template-columns: repeat(6, minmax(0, 1fr));
  gap: 14px;
  margin-block: 0;
}

.st-address-form__cell {
  min-width: 0;
  margin-block: 0;
}

.st-address-form__cell--2 {
  grid-column: span 2;
}

.st-address-form__cell--3 {
  grid-column: span 3;
}

.st-address-form__cell--4 {
  grid-column: span 4;
}

/*
 * Same reasoning as checkout.css's own identical rule: a `<select>` carrying
 * .st-field needs the same box as an input but not the same fixed `height`,
 * which clips its own native option list on some platforms.
 */
.st-address-form__fields select.st-field {
  height: auto;
  min-height: var(--st-h-field);
  padding-block: 10px;
}

/*
 * No button rule of this file's own: `.st-btn`/`.st-btn--primary`/
 * `.st-btn--block` (button.css, always loaded) are this theme's established
 * primary-submit treatment (56px --st-h-button, accent fill, full width via
 * `.st-btn--block` itself) — the same classes checkout's own #place_order
 * and the cart's "Finalizar compra" link already use (review-order.php,
 * cart-totals.php) and form-edit-address.php's own submit button carries
 * unchanged, rather than a new button style — or a redundant override — for
 * this one form.
 */
.st-address-form__submit {
  margin-block-start: 20px;
}

/*
 * Every span collapses to the full two-column row rather than pairing up —
 * the same collapse checkout.css's own address grid uses at the same
 * breakpoint, and for the same reason: the field order alternates narrow
 * and wide cells (CEP 2, Endereço 4, Número 2, …), and a `span 1` beside a
 * cell that still needs `span 2` would leave a hole grid auto-placement
 * cannot fill. One field per row has no holes.
 */
@media (max-width: 599px) {
  .st-address-form__fields {
    grid-template-columns: repeat(2, minmax(0, 1fr));
  }

  .st-address-form__cell--2,
  .st-address-form__cell--3,
  .st-address-form__cell--4 {
    grid-column: span 2;
  }
}

/* --- Edit account form (Task 7, task-7-brief.md) ---------------------------
 *
 * woocommerce/myaccount/form-edit-account.php ("Dados pessoais"). No mockup
 * exists for this endpoint either (same as Task 5's view-order.php and Task
 * 6's edit-address form above) — task-7-brief.md is explicit that it
 * "extends the same `.st-field` input treatment and `--st-h-button` 56px
 * submit button used everywhere else", so nothing below invents a new
 * field/button style: `.st-field`/`.st-field__label` (field.css, always
 * loaded) are reused directly on every input with no redefinition here, and
 * the submit button carries `.st-btn`/`.st-btn--primary`/`.st-btn--block`
 * (button.css, also always loaded) unchanged — the exact same classes
 * `.st-address-form__submit`'s own button (above) already uses — so its
 * 56px height and its `:hover`/`:active` rules come from button.css with
 * nothing duplicated here.
 *
 * Layout judgment call (form-edit-account.php's own docblock, restated
 * here for anyone reading the CSS first): first/last name are paired
 * side by side in a two-column row — core's own template already marks
 * them `form-row-first`/`form-row-last`, the exact semantic split a
 * two-column pairing restates visually rather than invents. Every OTHER
 * field (display name, e-mail, all three password fields) stays
 * single-column/full-width: none of them has a natural pairing partner
 * core's own markup groups them with, and task-7-brief.md's own resolved
 * values leave this choice explicitly open.
 */

.st-account-form__row {
  display: grid;
  grid-template-columns: repeat(2, minmax(0, 1fr));
  gap: 14px;
  margin: 0 0 20px;
}

.st-account-form__field {
  margin: 0 0 20px;
}

/* Zeroes the field's own bottom margin where two sit inside one row
   together — the row itself carries the 20px gap to the next field below
   it instead (above), so the two are not stacked twice. */
.st-account-form__row > .st-account-form__field {
  margin: 0;
}

.st-account-form__description {
  display: block;
  margin-top: 6px;
  color: var(--st-muted);
  font-size: var(--st-size-caption); /* 12.5px — an exact match. */
  font-style: normal;
}

/*
 * The password-change `<fieldset>` (form-edit-account.php's own docblock):
 * core's own element, kept for its native semantics, but with the
 * browser's default border/padding replaced entirely by a single
 * `--st-hairline` top rule plus top padding/margin — a divider beneath the
 * name/e-mail fields above, not a boxed sub-form.
 */
.st-account-form__password {
  margin: 12px 0 24px;
  padding: 24px 0 0;
  border: 0;
  border-top: 1px solid var(--st-hairline);
}

/*
 * The `<legend>` restyled as a small section heading — the same small-caps/
 * eyebrow treatment `.st-checkout__section-title` (checkout.css) already
 * establishes as this theme's own "looks like a heading" pattern, copied
 * here rather than reused by class: checkout.css is never loaded on
 * `/minha-conta/` (Assets::screen() loads exactly one screen stylesheet per
 * request — see this file's own "Addresses" section, above, for the same
 * constraint documented against form-edit-address.php's own grid).
 */
.st-account-form__password-legend {
  padding: 0;
  margin: 0 0 20px;
  font-size: var(--st-size-label); /* 13px — an exact match. */
  font-weight: var(--st-weight-extrabold);
  letter-spacing: var(--st-track-eyebrow);
  text-transform: uppercase;
}

.st-account-form__submit {
  margin: 0;
}

@media (max-width: 599px) {
  .st-account-form__row {
    grid-template-columns: 1fr;
  }
}

/* --- Payment methods and Downloads (Task 8, task-8-brief.md) --------------
 *
 * woocommerce/myaccount/payment-methods.php and
 * woocommerce/myaccount/downloads.php. Ground truth confirmed live
 * (task-8-report.md): the seeded `conta.teste` customer has zero saved
 * payment methods (no tokenizing gateway is configured — only `cod`/`bacs`)
 * and zero downloadable products, so both pages render ONLY their empty
 * state on this fixture. `.st-account__title` needs no rule of its own
 * here — both templates reuse the exact same class orders.php/form-edit-
 * account.php already style, above. The two tables' own CSS lives up in
 * this file's "Order history table" section instead (rather than here, at
 * the end of the file) purely to satisfy stylelint's no-descending-
 * specificity — the same source-order-only constraint this file's own
 * `.st-account__nav li:first-child > .st-account__nav-item` comment already
 * documents — since those two tables' `th`/`td` selectors are lower-
 * specificity than the "Single order view" section's own `tfoot
 * tr:last-child th`/`td` rule and must sort ahead of it; the two rule sets
 * never contend on the same declaration.
 *
 * The empty-state message itself needs no new CSS either:
 * `wc_print_notice( …, 'notice' )` renders a bare `.woocommerce-info` div,
 * which components/notice.css already styles sitewide (padding, ink border,
 * `--st-surface-2` background) — restating any of that here would just be a
 * second copy of a value this file does not own, the same call this file's
 * own "Nav" section (above) already makes for focus rings. That box also
 * already clears the 44px touch-target floor on both axes purely from
 * notice.css's own 14px/16px padding plus real sentence-length pt-BR copy,
 * confirmed live rather than assumed — at every width the HEIGHT half
 * genuinely holds; the WIDTH half does too everywhere except the shell's
 * own pre-existing gap at the 390px mobile project (`.st-account` is still
 * a fixed `268px 1fr` grid with no responsive collapse of its own,
 * task-3-brief.md's own grid test — the exact same gap Task 7's own
 * submit-button test already scopes its own width assertion around, not
 * something this task's markup introduces).
 *
 * The CTA itself needs no new CSS either: `.st-btn`/`.st-btn--primary`
 * (button.css, always loaded) already give it `min-height: var(--st-h-
 * button)` (56px, comfortably above the 44px floor) and real horizontal
 * padding — the same reuse form-edit-account.php's own submit button and
 * cart-totals.php's own checkout link already make of these two classes.
 * Same desktop-vs-390px-mobile width caveat as the notice above.
 */

/* The two tables' own selectors are declared up in this file's own "Order
   history table" section instead of here — see this section's own header
   comment for why. */

/* --- Auth forms (Task 9, task-9-brief.md) ----------------------------------
 *
 * woocommerce/myaccount/form-login.php, form-lost-password.php,
 * form-reset-password.php and lost-password-confirmation.php — the four
 * templates that render OUTSIDE a logged-in session
 * (`WC_Shortcode_My_Account::output()`/`::lost_password()` call
 * `wc_get_template()` on them directly, never through my-account.php's own
 * shell, confirmed live reading that class). No `.st-account__sidebar` makes
 * sense pre-login, so these get their own single centred column,
 * `.st-account__auth`, rather than reusing `.st-account` itself — every
 * field inside still reuses `.st-field`/`.st-field__label`/
 * `.st-account-form__row`/`.st-account-form__field`/
 * `.st-account-form__submit`/`.st-account-form__description` (Task 7,
 * above) and `.st-btn`/`.st-btn--primary`/`.st-btn--block` (button.css)
 * verbatim — no new field/button styling anywhere in this section, per
 * task-9-brief.md's own resolved values.
 *
 * No mockup exists for any of these four pages (task-9-brief.md, same as
 * Tasks 5-7's own endpoints) — every measurement below is this task's own
 * judgment call, justified against real precedent found live in this
 * codebase rather than invented from nothing.
 *
 * WIDTH — 520px. No exact existing precedent for "a narrow centred single-
 * column form" exists anywhere in this theme (checked: checkout.css's own
 * 380px is a SIDEBAR track beside a wide content column, not a standalone
 * measure; thankyou.css's own 1160px `.woocommerce-form-login` box is the
 * FUNNEL's own wide container, holding a gated login form inside an
 * already-full-width order-received page, not a narrow one). 520px is
 * therefore a literal, chosen within task-9-brief.md's own suggested
 * ~480-560px range — and it is not an arbitrary pick inside that range: it
 * lands almost exactly on the width `.st-address-card` (Task 6, above)
 * already resolves to when TWO of them sit side by side in
 * `.st-account__addresses`'s own real two-column grid (that grid's own
 * content column is ~1060px at desktop, minus its 24px gap, /2 = ~518px per
 * card) — the closest real "two cards side by side" precedent this theme
 * has, and the exact shape `.st-auth-card` (below) reuses for the
 * login/register split. Keeping this page's own single-card width in step
 * with what a two-card grid elsewhere already renders at means a shopper
 * who has seen the address cards is not shown a differently-proportioned
 * card here for no reason.
 *
 * SPLIT WIDTH / BREAKPOINT — task-9-brief.md's own text names "767px" for
 * the login/register two-column collapse, but flags it explicitly as "your
 * judgment call... match whichever is the established convention". Checked
 * live against every "N columns -> 1 column" collapse already shipped in
 * this codebase: `.st-account-form__row` (Task 7, above — two bare, borderless
 * `<p>` fields paired side by side) collapses at 599px, while
 * `.st-account__addresses` (Task 6, above — two independently-BORDERED CARDS
 * side by side, `.st-address-card`) collapses at 899px. `.st-auth-card` is
 * explicitly a CARD (task-9-brief.md's own name for it, and this section's
 * own bordered-box treatment below) holding a whole form, not a bare paired
 * field — the same shape `.st-address-card` is, not the shape
 * `.st-account-form__row` is. 899px is used here for that reason, not 767px
 * or 599px: checkout.css's own comment (that file, "the address grid's own
 * collapse, moved... from 767px to [899px]") independently confirms 767px was
 * already tried in this codebase once, for a structurally similar
 * side-by-side collapse, and found NOT to match real content behaviour at
 * the viewports that matter — a second reason not to default back to it here
 * without evidence. `woocommerce_enable_myaccount_registration` is `no` on
 * this install (confirmed live, `lando wp option get`), so this split is
 * implemented and styled but not exercised end-to-end by a real page render
 * here — task-9-report.md has the full account of that gap.
 */

.st-account__auth {
  max-width: 520px;
  margin-inline: auto;
  padding: 32px var(--st-gutter) var(--st-section-y);
}

/*
 * Only present when `woocommerce_enable_myaccount_registration` is `yes`
 * (form-login.php's own `$st_registration_enabled` — the same flag core's
 * own template branches on, read once rather than twice). Widened to hold
 * two `.st-auth-card` panels — each kept at THIS section's own 520px measure
 * (above) — side by side with the same 24px gap `.st-account__addresses`
 * (Task 6) already uses for its own two-card grid: 520 + 520 + 24 = 1064px.
 */
.st-account__auth--split {
  max-width: 1064px;
}

/*
 * `u-columns`/`col2-set` are core's own classes (form-login.php's own
 * template, kept alongside this theme's own `st-account__auth--split` for
 * the same "core's own class stays reachable by name" reason every other
 * override in this theme keeps core's classes — my-account.php's own
 * docblock). `.stylelintrc`'s frozen selector-class-pattern does not admit
 * an unprefixed `u-*` class, so it is reached through an attribute selector
 * instead — the same escape components/notice.css's own header comment
 * already documents for `woocommerce-NoticeGroup`.
 */
.st-account__auth--split [class~="u-columns"] {
  display: grid;
  grid-template-columns: repeat(2, minmax(0, 1fr));
  gap: 24px;
}

@media (max-width: 899px) {
  .st-account__auth--split [class~="u-columns"] {
    grid-template-columns: 1fr;
  }
}

/*
 * The card itself — a bordered box holding one whole form, the same real
 * shape `.st-address-card` (Task 6) already establishes for "a bordered box
 * with a heading holding one self-contained thing", reused as a PATTERN
 * (not by class — this card has no edit-link header row to match).
 * 28px/20px padding matches thankyou.css's own `.woocommerce-form-login`
 * box exactly (that file's own "gated states" section) — the identical kind
 * of content (a login form in a bordered box), already given this exact
 * measure once in this theme; Assets::screen() loads exactly one screen
 * stylesheet per request (this file's own "Addresses" section, above,
 * documents the same constraint), so that value is copied here as a literal
 * rather than shared by class across two stylesheets that are never loaded
 * together.
 */
.st-auth-card {
  padding: 28px 20px;
  border: var(--st-rule);
  background: var(--st-surface);
}

.st-auth-card__title {
  margin: 0 0 20px;
  font-size: var(--st-size-h2);
  letter-spacing: var(--st-track-h2);
}

.st-auth-card__remember-label {
  display: flex;
  align-items: center;
  gap: 8px;
  margin: 0 0 20px;
  color: var(--st-ink);
  font-size: var(--st-size-body-sm);
  font-weight: var(--st-weight-regular);

  /* The native checkbox itself is tiny; its own <label> is what a user
   * actually taps, so the label needs the 44px minimum tap-target height
   * instead. Same technique as `.st-auth-card__lost-password a` below. */
  min-height: var(--st-h-touch);
}

/*
 * Fix pre-empted rather than found: `.st-address-card__edit` (Task 6, above)
 * shipped with no padding/min-height of its own and needed a "fix round 1"
 * afterward once it was measured at ~17-19px tall on a real page. This is
 * the identical shape of control — a bare text link, no button chrome — so
 * the same `display: inline-flex` + `align-items: center` +
 * `min-height: var(--st-h-touch)` technique is applied here from the start.
 */
.st-auth-card__lost-password a {
  display: inline-flex;
  align-items: center;
  min-height: var(--st-h-touch);
  color: var(--st-ink);
  font-size: var(--st-size-label);
  text-decoration: none;
}

.st-auth-card__lost-password a:hover,
.st-auth-card__lost-password a:active {
  color: var(--st-accent-deep);
}

/*
 * Task 11 (task-11-brief.md): the whole-screen sweep measured the product-
 * name link WooCommerce's own `order/order-details.php` renders inside
 * `td.product-name` at 240x17px (1440) / 143x42.5px (360) — under the 44px
 * floor on the height axis at every width, real content this fixture always
 * renders (the seeded on-hold order has one real line item), not a
 * hypothetical. The cell's own 14px top/bottom padding is not enough on its
 * own once added to one line of body text. Same
 * `inline-flex`/`align-items: center`/`min-height: var(--st-h-touch)` fix as
 * `.st-orders-table__number` and `.st-auth-card__lost-password a` above — a
 * bare text link with no button chrome, extending the cell padding's own
 * click area rather than growing the font. Placed here, after every other
 * selector this rule shares a property with, to satisfy stylelint's
 * no-descending-specificity (this selector's own specificity is higher than
 * `.st-auth-card__lost-password a`'s). `[class~="product-name"]` is the same
 * attribute-selector escape this file's own `.st-order-detail__note
 * [class~="woocommerce-OrderUpdate-meta"]` rule (above) already uses for a
 * WooCommerce-core class .stylelintrc's selector-class-pattern does not
 * admit literally.
 */
.st-order-detail .woocommerce-table--order-details [class~="product-name"] a {
  display: inline-flex;
  align-items: center;
  min-height: var(--st-h-touch);
}