/* ==========================================================================
   account-workspace-tokens.css — Mercher partner cabinet redesign (Task 1)
   Spec: docs/superpowers/specs/2026-09-19-partner-workspace-design.md §5
   Reference values: git show a26c6adf:app/static/admin.css

   Scope: everything lives under `.account-workspace` (put on <body> of the
   ordinary shell and three of the four standalone editors — design.html,
   page_edit.html, product_details.html) or under `.dz-theme` (designer.html
   only, see below). This file ONLY defines custom properties + one tiny
   layout utility; every visual rule stays in account.css, restyled through
   the cascade below.

   How the retheme works without touching fw-tokens.css or rewriting every
   selector in account.css: account.css already reads color/radius through
   two layers of CSS variables — `--fw-*` (fw-tokens.css) and semantic
   aliases (`--ink`, `--surface`, `--brand`, `--r-*`, defined once in
   account.css's own `:root`). A custom property set directly on an element
   always wins over one only inherited from an ancestor, regardless of
   selector specificity — so redeclaring both layers here, scoped to
   `.account-workspace` (the <body> class), reshades the whole existing
   stylesheet without duplicating its rules. fw-tokens.css itself is never
   edited (shared file, other consumers) — this only shadows its values
   inside the cabinet's own subtree.

   `.dz-theme` (designer.html, Task 3, owner decision 2026-09-20 — conservative
   restyle only): same variable block, SEPARATE class name on <body> instead of
   `.account-workspace`. Custom properties inherit to every descendant
   regardless of which selector declared them, so `.dz-topbar`/`.dz-upload-thumb`/
   etc. (plain, unscoped `.dz-*` rules in account.css, all already reading
   `var(--line)`/`var(--surface)`/`var(--r-sm)`/…) retint exactly the same way.
   What does NOT apply this way: the `.account-workspace <component>` rules
   further down account.css (e.g. `.account-workspace .btn{min-height:40px;
   padding:0 14px}`, `.account-workspace .btn--sm{min-height:38px}`) — those
   are keyed to the literal `.account-workspace` class name, not to a variable,
   so they simply don't match a `.dz-theme` body. That is deliberate: those
   rules change CONTROL SIZE (padding/min-height/gap), which the owner's
   conservative-designer directive explicitly forbids ("не менять размеры…
   контролов, отступы"), and they measurably do — verified empirically
   (`.btn--sm` height 32.08px → 38px under `.account-workspace`, which alone
   grew `.dz-topbar` by 4px; see docs/workstreams/reports/
   partner-workspace-implementation.md, Task 3 "Дизайнер"). `.dz-theme` gets
   every color/radius/focus token the same as `.account-workspace`, none of
   its size-changing component rules.
   ========================================================================== */

.account-workspace, .dz-theme {
  /* -------- raw admin-parity tokens (spec §5) -------- */
  --pw-bg: #161712;
  --pw-sidebar: #1c1d19;
  --pw-surface: #242521;
  --pw-surface-2: #292b23;
  --pw-border: #343531;
  --pw-text: #fdfcfb;
  --pw-muted: #b5b3b0;
  --pw-faint: #9a9b95;
  --pw-primary: #4557ff;
  --pw-primary-hover: #3444dc;
  --pw-link: #929dff;
  --pw-success: #69d2ae;
  --pw-warning: #efc370;
  --pw-danger: #f18e87;
  --pw-focus: #a5afff;
  --pw-input: #25281f;
  --pw-input-border: #454a3c;
  --pw-section-gap: 20px;

  /* -------- shadow fw-tokens.css consumers used across account.css --------
     Scoped override only: fw-tokens.css itself is untouched. */
  --fw-bg: var(--pw-bg);
  --fw-surface: var(--pw-surface);
  --fw-surface-2: var(--pw-surface-2);
  --fw-line: var(--pw-border);
  --fw-line-2: var(--pw-border);
  --fw-text: var(--pw-text);
  --fw-text-2: var(--pw-muted);
  --fw-muted: var(--pw-muted);
  --fw-faint: var(--pw-faint);
  --fw-blue: var(--pw-primary);
  --fw-blue-hover: var(--pw-primary-hover);
  --fw-blue-soft: var(--pw-link);
  --fw-blue-12: color-mix(in srgb, var(--pw-primary) 14%, transparent);
  --fw-blue-24: color-mix(in srgb, var(--pw-primary) 30%, transparent);
  --fw-green: var(--pw-success);
  --fw-yellow: var(--pw-warning);
  --fw-red: var(--pw-danger);

  /* -------- account.css semantic aliases (same names as its :root) -------- */
  --ink: var(--pw-text);
  --ink-2: var(--pw-muted);
  --muted: var(--pw-muted);
  --faint: var(--pw-faint);
  --line: var(--pw-border);
  --line-2: var(--pw-border);
  --bg: var(--pw-bg);
  --surface: var(--pw-surface);
  --surface-2: var(--pw-surface-2);
  --brand: var(--pw-primary);
  --brand-press: var(--pw-primary-hover);
  --brand-12: color-mix(in srgb, var(--pw-primary) 14%, transparent);
  --brand-24: color-mix(in srgb, var(--pw-primary) 30%, transparent);
  --ok: var(--pw-success);
  --warn: var(--pw-warning);
  --danger: var(--pw-danger);

  /* -------- radii: card 8 / button 6 / field-ish 5 / badge 4 (spec §5) -------- */
  --r-lg: 8px;
  --r-xl: 8px;
  --r: 6px;
  --r-sm: 5px;
  --r-xs: 4px;
}

/* Generic vertical stack, gap = section rhythm (spec §6 "Stack"). */
.account-workspace .pw-stack {
  display: flex;
  flex-direction: column;
  gap: var(--pw-section-gap);
  min-width: 0;
}

/* Visible keyboard focus matching admin-visual exactly: a plain outline
   never gets clipped by an ancestor's `overflow:hidden` (unlike the
   box-shadow ring account.css uses elsewhere, e.g. inside .table-wrap).
   Applies to the designer too (`.dz-theme`) — focus-visible is explicitly
   allowed for the conservative designer restyle. */
.account-workspace :focus-visible, .dz-theme :focus-visible {
  outline: 2px solid var(--pw-focus);
  outline-offset: 3px;
  box-shadow: none;
  border-radius: 0;
}