/*
 * OSTADEEZ — scheme-driven surfaces.
 *
 * THE STANDARD: a surface belongs here when it is drawn by a PLUGIN that ships its own literal
 * colours and therefore cannot follow the token swap on its own. Everything in this file does one
 * thing — hand that surface a `--ostz-*` token instead of the colour it shipped with.
 *
 * Nothing here invents a colour. If a rule below contains a hex value, it is wrong.
 */

/*
 * ⚠ THE TOGGLE'S RULES WERE DELETED 2026-09-22. The control itself went with the light-only
 * decision of 2026-09-20; its markup is printed by nothing, and its script was registered and
 * never enqueued. Four classes styling an element that cannot exist. Do not put them back
 * without the button.
 */

/* ---------------------------------------------------------------- category chips
 * ⚠ THE CHIP'S COLOUR IS NOT HERE ANY MORE, and the reason it ever was is worth keeping.
 *
 * `.ostz a { color: inherit }` in the main sheet scored 0-1-1 and therefore BEAT `.ostz-chip` at
 * 0-1-0, so the chips never used their own colour token — they inherited, and in light mode read
 * as near-white text on a near-white surface. The workaround was to re-declare the colour HERE at
 * 0-2-0, which fixed the symptom and split one component across two files.
 *
 * The main sheet's anchor rule is `:where(.ostz) a` now — zero specificity — so the component
 * simply wins, and modules/ostadeez-m-chip.css carries every chip declaration including the
 * `text-DIM, not text-faint` decision the count needed (measured 4.16:1 on its own lifted pill,
 * where the faint token passes on the page but not on the chip).
 */

/* ⚠ THE FILTER RAIL'S 145 LINES LEFT THIS FILE on 2026-09-22 → `modules/ostadeez-b-filters.css`,
   which loads only where the rail is actually printed. This sheet is enqueued on every page, so
   anything here that belongs to ONE surface is paid for by every other surface. Measured before
   the move: `.ostz-filters` is present on the shop archive and nowhere else of the four pages
   checked. Nothing about the rail may be declared here again. */

/* ---------------------------------------------------------------- the search modal
   Renders into every page's footer, so it is a sitewide surface, not a shop one. Measured on the
   rendered page: a white submit face, a #888 close control and a #3e68ff «show all results»
   button — three of the plugin's own defaults, none of them in this palette. */

/*
 * ⚠ `__panel` AND `__box` ARE CLASSES THE PLUGIN NEVER EMITS. The block below was written against
 * guessed names, matched nothing, and the modal has been a WHITE panel on the dark scheme ever
 * since — invisible to every sweep because the modal was never opened. MEASURED 2026-09-05, opened
 * by a real click: `.dm-search-modal__content` had `background: rgb(255,255,255)` with
 * `data-theme="dark"`, and the close control our own rule had just re-inked measured **1.1:1**.
 *
 * The names are kept for one release in case a plugin update introduces them, but the real element
 * is `__content`, and the plugin builds it from its OWN variables — so the variables are what get
 * pointed at the tokens, the same mechanism the cart drawer already uses. That is more durable
 * than a rule per element: it survives the plugin adding markup we have not seen.
 */
/* ⚠ `.dms-widget` was a fourth entry here and is gone: it is one of the three names the block
   at the top of the rail section records as never emitted, and it survived that clean-up inside a
   selector LIST, where a dead alternative changes nothing visible because its siblings still
   match. A list is exactly where this kind of leftover hides. */
.ostz .dm-search-modal,
.ostz .dm-search-modal__content,
.ostz .dms-sidebar {
	--dms-surface: var(--ostz-bg-raised);
	--dms-surface-alt: var(--ostz-bg-raised-2);
	--dms-surface-muted: var(--ostz-bg-sunken);
	--dms-border: var(--ostz-line);
	--dms-border-light: var(--ostz-line);
	--dms-border-soft: var(--ostz-line);
	--dms-text: var(--ostz-text);
	--dms-text-strong: var(--ostz-text);
	--dms-text-muted: var(--ostz-text-dim);
	--dms-text-soft: var(--ostz-text-dim);
	--dms-primary: var(--ostz-accent);
	--dms-primary-dark: var(--ostz-accent);
	--dms-primary-contrast: var(--ostz-accent-ink);
}

.ostz .dm-search-modal__content,
.ostz .dm-search-modal__panel,
.ostz .dm-search-modal__box {
	background: var(--ostz-bg-raised);
	border-color: var(--ostz-line);
	color: var(--ostz-text);
}

.ostz .dm-search-modal__close {
	color: var(--ostz-text-dim);
	background: transparent;
}

.ostz .dm-search-form__input {
	background: var(--ostz-bg-sunken);
	border-color: var(--ostz-line-strong);
	color: var(--ostz-text);
}

.ostz .dm-search-form__submit {
	background: var(--ostz-accent);
	color: var(--ostz-accent-ink);
	border-color: var(--ostz-accent);
}

.ostz .dm-search-more-btn {
	background: var(--ostz-accent);
	color: var(--ostz-accent-ink);
}

/* ---------------------------------------------------------------- the cart drawer
   The cart-modal plugin is fully settings-driven and emits `--dm-scm-*` custom properties from
   values saved in the database. Saved values are static, so the drawer could not follow the
   scheme — these point the same variables at the tokens instead.

   ⚠ ONLY FOUR NAMES BELONG HERE, and knowing which four is not a matter of taste. This block
   used to declare twelve; the other eight (`panel`, `surface`, `box`, `bg-alt`, `muted`,
   `text-light`, `primary-text`, `danger`) are a generic vocabulary the plugin has never used —
   absent from the fork and from the market copy alike, so those eight lines resolved to nothing.
   The plugin's real vocabulary is PER-CONTROL (`--dm-scm-checkout-bg`, `--dm-scm-pay-btn-bg`,
   `--dm-scm-upsell-bg`, …), it has ~40 of them, and they are owned by its own settings — written
   from this same palette by seeds/seed-cart-modal.php, which is where they must stay so the
   operator keeps control. Adding a name here that the plugin does not read is not harmless: it
   reads as skinning that is already handled and stops anyone looking for the real reason a
   surface is the wrong colour. check-plugin-contract.php now fails on it. */

.dm-scm-drawer,
.dm-scm-drawer-content,
.dm-scm-modal,
.dm-scm-overlay,
body {
	--dm-scm-bg: var(--ostz-bg-raised);
	--dm-scm-text: var(--ostz-text);
	--dm-scm-border: var(--ostz-line);
	--dm-scm-primary: var(--ostz-accent);
	/* the modal's line price read 2.06:1 in the light scheme off the plugin's settings colour. */
	--dm-scm-price-reg: var(--ostz-text-dim);
}

/*
 * ⚠ 0-2-0 on purpose. The shared `.dm-scm-close` rule further down is 0-1-0, the plugin's own is
 * 0-1-0 with `color:#999` and loads after ours, so load order decided it and the × measured
 * 2.85:1 on the light modal (پویش ظاهر 2026-09-19) — the count-badge trap again.
 */
.dm-scm-modal .dm-scm-close {
	color: var(--ostz-text-dim);
}

/* On a phone the two footer buttons share one row and «مشاهده سبد و تسویه» wrapped to two lines,
   80px beside a 55px sibling. Stack them full-width instead. */
@media (max-width: 480px) {
	.dm-scm-modal .dm-scm-btn-wrapper {
		flex-direction: column;
		align-items: stretch;
	}
}

.dm-scm-drawer-content,
.dm-scm-drawer-header,
.dm-scm-drawer-body,
.dm-scm-drawer-footer,
.dm-scm-modal {
	background: var(--ostz-bg-raised);
	color: var(--ostz-text);
	border-color: var(--ostz-line);
}

.dm-scm-drawer-header,
.dm-scm-drawer-footer {
	border-color: var(--ostz-line);
}

.dm-scm-drawer-content a,
.dm-scm-modal a {
	color: var(--ostz-accent);
}

/*
 * ⚠ THE PANEL WAS THEMED AND ITS CONTENTS WERE NOT, and the difference is the whole finding.
 *
 * MEASURED 2026-09-05, with the drawer OPENED BY A REAL CLICK — the first time it has ever been
 * measured open, because off-canvas the backdrop reading is meaningless and every earlier sweep
 * therefore recorded it as «not re-measured». The panel above correctly takes `bg-raised` and
 * `text`. But the plugin paints its heading, its item titles and its subtotal with a hardcoded
 * `#333`, and its checkout button with hardcoded white ink — literals no variable can reach.
 *
 * On the light scheme that pairing accidentally works, which is why nothing ever looked wrong.
 * On DARK it measured **1.42:1** for «سبد خرید», the item title, «جمع جزء» and the total, and
 * **1.66:1** for «تسویه حساب» — white on our cyan, whose correct ink is near-black. The customer's
 * running total and the button they press to pay were both effectively invisible in the site's
 * own default scheme.
 *
 * ⚠ The lesson for the next plugin: variables reach a plugin only where the plugin USES variables.
 * Where it writes a literal, only a rule on the element itself reaches it — and the only way to
 * find out which is which is to open the thing and measure it.
 */
.dm-scm-drawer-content h3,
.dm-scm-drawer-header h3,
.dm-scm-modal h3,
.dm-scm-modal h4,
.dm-scm-item-title,
.dm-scm-drawer-body .dm-scm-item-title,
/* ⚠ `dm-scm-total-label` / `dm-scm-total-value` were here and neither copy of the plugin has
   ever emitted them; the footer's real names are below. The `strong`/`span` fallbacks at the end
   of this list are what has actually been painting the total all along. */
.dm-scm-drawer-footer .dm-scm-total,
.dm-scm-drawer-footer .dm-scm-total-price,
.dm-scm-cp-totals-row,
.dm-scm-drawer-footer strong,
.dm-scm-drawer-footer span {
	color: var(--ostz-text);
}

.dm-scm-drawer-content .woocommerce-Price-amount,
.dm-scm-modal .woocommerce-Price-amount {
	color: var(--ostz-text);
}

/*
 * The pay button: our accent needs OUR ink on it, not the plugin's white.
 *
 * ⚠ `!important` HERE IS DELIBERATE AND IT IS THE THIRD SANCTIONED USE IN THIS PROJECT (the other
 * two are the nested-table bleed and the `[hidden]` normalize). The plugin writes
 * `.dm-scm-btn-primary { color: #fff !important }`, and an important declaration is beatable only
 * by another one — no amount of specificity reaches it. MEASURED: white on our cyan is **1.66:1**,
 * on the button a customer presses to pay, in the site's own default scheme.
 * ⚠ Do not «tidy» this into a plain declaration; it will silently stop applying.
 */
.dm-scm-drawer-footer .checkout,
.dm-scm-drawer-footer .dm-scm-btn-primary,
.dm-scm-btn-primary,
.dm-scm-modal .dm-scm-btn-primary {
	background: var(--ostz-accent) !important;
	border-color: transparent;
	color: var(--ostz-accent-ink) !important;
}

/* Measured 19×18 — the control that removes a line from the cart, under the 24px tap floor. */
.dm-scm-remove-item,
.dm-scm-drawer-body .dm-scm-remove-item {
	display: inline-flex;
	align-items: center;
	justify-content: center;
	inline-size: 26px;
	block-size: 26px;
}

/* The search modal's close control measured 2.17:1 against 3 — an icon-only escape route. */
.dm-search-modal__close,
.dm-search-modal .dm-search-modal__close {
	color: var(--ostz-text);
}

/* ---------------------------------------------------------------- the login controls
   ⚠ The OTP button is the single most important control in the purchase path, and it was wearing
   the plugin's own colour rather than the site's. Both entry points get the same treatment: the
   modal that opens anywhere on the site, and the standalone forced-login page, which never loads
   the theme stylesheet and so is handed the same variables through the plugin's own hook. */

.dml-btn-primary,
.dml-btn.dml-btn-primary,
button.dml-btn-primary {
	background: var(--ostz-accent);
	border-color: transparent;
	color: var(--ostz-accent-ink);
	font-family: inherit;
	font-weight: var(--ostz-weight-bold);
}

.dml-btn-primary:hover {
	filter: brightness(1.08);
	color: var(--ostz-accent-ink);
}

.dml-btn:not(.dml-btn-primary) {
	background: var(--ostz-bg-raised-2);
	border-color: var(--ostz-line-strong);
	color: var(--ostz-text);
	font-family: inherit;
}

.dml-btn:not(.dml-btn-primary):hover {
	border-color: var(--ostz-accent);
	color: var(--ostz-accent);
}

/* ⚠ THE ENGAGEMENT PLUGIN'S CONTROLS LEFT THIS FILE on 2026-09-22 →
   `modules/ostadeez-b-engagement.css`, which rides the shop skin. Same reason as the rail: a
   blog post was carrying the paint for a waitlist button it can never render. */

/* ---------------------------------------------------------------- plugin tap targets
 *
 * Three controls from the forked plugins measured under the 24x24 floor: the search modal's close
 * (14x24), the cart drawer's close (12x24) and the filter rail's stock switch (36x20). Each is the
 * only way out of, or into, the surface it belongs to. Sized here rather than in the forks because
 * it is a house rule about our UI, not a defect in their logic — and a rule stated once in the skin
 * cannot drift out of step with the plugin's own updates.
 */

.dm-search-modal__close,
.dm-scm-drawer-close,
.dm-scm-close {
	display: inline-flex;
	align-items: center;
	justify-content: center;
	min-width: 32px;
	min-height: 32px;
	border-radius: 8px;
	/* The plugins ship a mid-grey close glyph that measures under the floor on both of these dark
	   panels. Same token as every other secondary control on the site. */
	color: var(--ostz-text-dim);
}

/* The drawer's empty state and its badge, both plugin defaults chosen for a light theme. */
.dm-scm-empty-cart {
	color: var(--ostz-text-dim);
}

/*
 * ⚠ This used to declare `background`/`color` directly and it NEVER APPLIED. The plugin declares
 * the same bare `.dm-scm-count-badge` selector — 0-1-0 against our 0-1-0 — and its stylesheet is
 * enqueued after ours, so load order decided it and the plugin won on every page of the site.
 * MEASURED before the fix: white on #EF3E63 at 3.79:1, not our accent, on all 44 surfaces.
 *
 * The plugin now exposes the badge as custom properties (dm-smart-cart-modal 2.30.6), so we SET
 * THE PROPERTIES rather than re-declaring the paint. A custom property is inherited, not matched,
 * so specificity and load order stop deciding anything.
 */
.dm-scm-count-badge {
	--dm-scm-count-bg: var(--ostz-accent);
	--dm-scm-count-ink: var(--ostz-accent-ink);
	font-weight: var(--ostz-weight-bold);
}

.dm-search-modal__close:hover,
.dm-scm-drawer-close:hover,
.dm-scm-close:hover {
	background: var(--ostz-bg-raised-2);
	color: var(--ostz-text);
}

/* (the rail's two tap-target rules moved with it — see `modules/ostadeez-b-filters.css`) */

/*
 * dm-advanced-reviews' mobile «جزئیات دیدگاه» sheet. Since the plugin's 3.28.5 its layout lives in
 * the plugin's always-loaded core sheet and reads these three role tokens (RULES-DELTA §5); the
 * theme only paints it. The 0.26.5 stop-gap that copied the whole layout here is gone.
 */
#dm-single-review-modal {
	--dm-card-bg: var(--ostz-bg-raised);
	--dm-text: var(--ostz-text);
	--dm-border: var(--ostz-line);
}

/*
 * The question-and-answer block of the same plugin, painted the same way and for the same reason:
 * we set ITS tokens, we never re-declare paint on its classes.
 *
 * ⚠ MEASURED 2026-09-22: its empty state («هنوز پرسشی ثبت نشده») computed **4.33:1** against a 4.5
 * requirement at 13px, on EVERY product page in both schemes. The plugin's own default for
 * `--dmqa-muted` is `#6c757d` on a `#f4f6f8` ground — a pairing that fails by construction. Nothing
 * in the plugin needed changing: the value was already a token, so this is the whole fix, and it
 * reaches every element of that block rather than the one the probe happened to name.
 *
 * `--ostz-text-dim` is the theme's own dimmed-text role and is contrast-checked against both
 * schemes, so the pair stays correct when the scheme flips.
 */
.dmqa-wrap,
.dmqa-root,
[class^='dmqa-'],
[class*=' dmqa-'] {
	--dmqa-text: var(--ostz-text);
	--dmqa-muted: var(--ostz-text-dim);
	--dmqa-surface-soft: var(--ostz-bg-raised);
	--dmqa-border: var(--ostz-line);
}