/*
 | تنظیمات ظاهری پنل مدیریت (Orchid)
 | این فایل از طریق config/platform.php در بخش resource.stylesheets بارگذاری می‌شود
 | و هیچ فایلِ داخل vendor را تغییر نمی‌دهد.
 |
 | ۱) نوار اکشن بالای صفحه (عنوان + دکمه‌ها) روی دسکتاپ چسبان می‌شود.
 | ۲) سرتیتر و جداکنندهٔ گروه‌های سایدبار واضح‌تر می‌شوند.
 | ۳) ویرایشگر XML، فیلدهای readonly، ویرایشگر سبک و ستونِ «عملیات» مناسبت‌ها.
 */

/* ── ۱) نوار اکشن چسبان ─────────────────────────────────────────── */
@media (min-width: 768px) {
    .command-bar-wrapper {
        position: sticky;
        top: 0;
        bottom: auto;
        /* z-index عوض نمی‌شود؛ مقدار پیش‌فرض خود Orchid (۵) کافی است */
        padding-top: .4rem;
        padding-bottom: .4rem;
        background-color: rgba(var(--bs-body-bg-rgb), .94);
        -webkit-backdrop-filter: blur(8px);
        backdrop-filter: blur(8px);
        border-bottom: 1px solid rgba(21, 20, 26, .06);
    }
}

/*
 | ── ۱/۱) نوار اکشن چندردیفی (وقتی دکمه‌ها زیادند) ────────────────────
 |
 | چرا اینجا لازم شد: Orchid روی خودِ `<ul class="nav command-bar">` هم
 | `width:100%`، `white-space:nowrap` و `overflow-x:auto` می‌گذارد و کلاسِ
 | `flex-sm-nowrap` هم `flex-wrap:nowrap` را با `!important` ثابت می‌کند. نتیجه:
 | در صفحه‌هایی مثل «احادیث بدون پیوند مفهومی» که پنج دکمهٔ عنوان‌بلند دارند،
 | دکمه‌ها نه به ردیفِ بعد می‌رفتند و نه جای کافی داشتند؛ متنشان فشرده می‌شد یا
 | نوارِ افقی می‌ساخت و سرِ صفحه به‌هم می‌ریخت.
 |
 | راه‌حل: همان نوار، به یک ردیفِ flexِ چندخطی تبدیل می‌شود (بدون فشردگی،
 | بدون اسکرولِ افقی) و جای دکمه‌ها در دو ردیف می‌افتد. این تنظیم فقط ظاهری است
 | و منطقِ دکمه‌ها (formaction، confirm و …) دست‌نخورده می‌ماند.
 */
@media (min-width: 576px) {
    /*
     | عنوان و دکمه‌ها نیمی‌نیمیِ عرض را می‌گیرند.
     | پیش از این `col-md-auto`ِ Orchid عرضش را از محتوای دکمه‌ها می‌گرفت و کوچک
     | نمی‌شد؛ یعنی ده‌ها دکمهٔ عنوان‌بلند، عنوان را به یک ستونِ باریک می‌فشردند و
     | خودشان هم از کادر بیرون می‌زدند. با `flex:1 1 0` هر دو طرف کوچک‌شدنی‌اند و
     | دکمه‌ها به‌جای فشرده‌شدن، به ردیفِ بعد می‌روند.
     */
    .command-bar-wrapper .layout > header,
    .command-bar-wrapper .layout > nav {
        flex: 1 1 0;
        min-width: 0;
    }

    .command-bar-wrapper .command-bar {
        display: flex !important;
        /* ⚠️ ابزارکِ `flex-sm-nowrap` خودش `!important` دارد */
        flex-wrap: wrap !important;
        justify-content: flex-end;
        align-items: center;
        width: auto;
        max-width: 100%;
        overflow-x: visible;
        white-space: normal;
    }

    /* دکمه‌ها فشرده نشوند؛ به ردیفِ بعد بروند */
    .command-bar-wrapper .command-bar > li {
        display: block;
        flex: 0 0 auto;
        max-width: 100%;
    }
}

/* ── ۲) گروه‌بندی سایدبار ───────────────────────────────────────── */
/* سرتیتر گروه: کوچک، کم‌رنگ و کمی تودرتو تا با آیتم‌ها اشتباه نشود */
.aside .nav-pills > li.nav-item > small {
    display: inline-block;
    margin-inline-start: .9rem !important;
    font-size: .7rem;
    font-weight: 700;
    line-height: 1.7;
    letter-spacing: .03em;
    color: rgba(255, 255, 255, .48) !important;
}

/* جداکنندهٔ بین گروه‌ها: در سایدبار تیره به‌اندازهٔ کافی دیده نمی‌شد */
.aside .nav-pills > li.divider {
    margin: .5rem .9rem !important;
    border-bottom: 1px solid rgba(255, 255, 255, .13) !important;
    list-style: none;
}

/* ── ۳) ویرایشگر XML (فیلد Code در Orchid = CodeFlask) ──────────── */
/*
 | چرا اینجا نوشته شده: متن رنگ‌آمیزی‌شدهٔ ویرایشگر داخل
 | <pre class="codeflask__flatten"> نوشته می‌شود و Orchid در orchid.rtl.css هم
 | راست‌چینش می‌کند. آن pre عرضش fit-content است، یعنی به اندازهٔ بلندترین خط فایل
 | (در فایل‌های کتابخانه چند هزار پیکسل). در نتیجه متن راست‌چین، چند هزار پیکسل
 | سمت راستِ کادر دید می‌افتد و کادر ویرایشگر خالی دیده می‌شود — متنِ سفیدِ textarea
 | که CodeFlask زیرش می‌گذارد هم روی زمینهٔ سفید دیده نمی‌شود.
 | متن XML کد است و باید چپ‌به‌راست باشد؛ پس اینجا جهت ویرایشگر را ثابت می‌کنیم.
 */
.codeflask .codeflask__pre,
.codeflask .codeflask__flatten,
.codeflask .codeflask__code,
.codeflask .codeflask__textarea {
    direction: ltr;
    text-align: left;
}

/* رنگ‌ها هم صریحاً اینجا آمده‌اند تا ظاهر ویرایشگر به تزریقِ CSS با جاوااسکریپت
   (که CodeFlask در <head> انجام می‌دهد) وابسته نباشد. مقادیر، همان تم پیش‌فرض
   CodeFlask است. */
.codeflask {
    background-color: #fff;
    color: #4f559c;
}

.codeflask .codeflask__pre,
.codeflask .codeflask__code {
    background-color: transparent;
}

/* اگر رنگ‌آمیزی Prism به هر دلیلی انجام نشود، CodeFlask متن textarea را سفید
   می‌گذارد (چون متن اصلی را در pre می‌کشد) و متن روی زمینهٔ سفید ناپدید می‌شود.
   اینجا رنگ متن روشنِ خوانا گرفته است؛ اندازهٔ قلم، line-height، padding و موقعیت
   دقیقاً همان pre است، پس وقتی هر دو روی هم می‌افتند چیزی دوتایی دیده نمی‌شود. */
.codeflask .codeflask__textarea {
    color: #4f559c !important;
    caret-color: #111;
}

.codeflask .codeflask__lines {
    direction: ltr;
}

/* رنگ توکن‌های Prism (همان تم پیش‌فرض CodeFlask) */
.codeflask .token.punctuation { color: #4a4a4a; }
.codeflask .token.keyword { color: #8500ff; }
.codeflask .token.operator { color: #ff5598; }
.codeflask .token.string { color: #41ad8f; }
.codeflask .token.comment { color: #9badb7; }
.codeflask .token.function { color: #8500ff; }
.codeflask .token.boolean { color: #8500ff; }
.codeflask .token.number { color: #8500ff; }
.codeflask .token.selector { color: #8500ff; }
.codeflask .token.property { color: #8500ff; }
.codeflask .token.tag { color: #8500ff; }
.codeflask .token.attr-value { color: #8500ff; }

/* ── ۴) متنِ فیلدهای readonly خوانا باشد ─────────────────────── */
/*
 | چرا اینجا لازم شد: Orchid در orchid.rtl.css روی فیلدهای readonly/disabled
 | این قاعده را دارد:
 |     .form-control[readonly]{background:#f6f6f7;color:rgba(73,80,87,.23)}
 | یعنی متن ۷۷٪ شفاف؛ روی زمینهٔ روشن عملاً ناپیدا.
 |
 | در صفحهٔ «ایمپورت XML» بیشترِ کادرهای مهم readonly هستند (مسیر فایل انتخابی،
 | فایل پیش‌پردازش‌شده و گزارش بازبینی). نتیجه این بود که مدیر بعد از زدنِ
 | «بازبینی» صفحه‌ای می‌دید که همه‌چیزش خالی به نظر می‌رسید و فکر می‌کرد فایل
 | از دست رفته و نمی‌تواند ایمپورت کند — در حالی که مقدارها سر جای خودشان بودند.
 |
 | اینجا همان کادرها خوانا می‌شوند، ولی زمینهٔ متفاوتشان می‌ماند تا هنوز
 | «غیرقابل‌ویرایش» به نظر برسند. (همین فایل بعد از orchid.rtl.css بارگذاری
 | می‌شود، پس با همان ویژگی برنده می‌شود و به !important نیازی نیست.)
 */
.form-control[readonly],
.form-control[disabled],
fieldset[disabled] .form-control,
.bootstrap-tagsinput[readonly],
[readonly].chosen-single,
[readonly].chosen-choices,
.select2-container--bootstrap.select2-container--disabled .select2-selection {
    color: #212529;
    background-color: #f2f3f5;
}

/* کادرِ متنِ لاگ/گزارش در حالت readonly: تمام‌عرض و تک‌عرض خوانا باشد */
textarea.form-control[readonly] {
    max-width: 100%;
    color: #212529;
}

/* ── ۵) ستونِ «عملیات» در فهرست‌های پنل ─────────────────────────── */
/*
 | چرا اینجا لازم شد: Orchid هر اکشن را در یک <div class="form-group"> می‌گذارد و
 | آن div بلاک است، پس دکمه‌های «ویرایش/فعال/حذف» زیرِ هم می‌افتادند و ارتفاعِ هر
 | ردیف به ۱۰۸ پیکسل می‌رسید. با flex، همان دکمه‌ها در یک ردیف می‌نشینند و اگر جا
 | کم بیاید به ردیفِ بعد می‌روند.
 |
 | نکته: ساختارِ HTML عوض نمی‌شود (سلول → div → form-group → دکمه) تا قاعدهٔ
 | اندازهٔ دکمه‌های خودِ Orchid که به همین ساختار وابسته است از کار نیفتد:
 |   .table tbody tr td > div > .form-group > .btn
 |
 | چطور سلولِ عملیات را پیدا می‌کنیم؟ دو راه، هر دو عمدی:
 |   ۱) کلاسِ صریحِ `occasion-actions` که در همان اسکرینِ مناسبت‌ها گذاشته شده.
 |   ۲) `data-column` که خودِ Orchid روی <th> و <td> هر ستون می‌گذارد و مقدارش
 |      (ستونِ «عملیات» در چیدمان‌های آمادهٔ خودِ Orchid کلید فارسیِ ترجمه‌شده را
 |      می‌گیرد، یعنی Str::slug('اقدامات') = "akdamat")
 |      «slug» کلیدِ ستون است (TD::make('actions', …) ⇒ data-column="actions").
 |      این دومی تعمیمِ قاعده به «همهٔ» فهرست‌های پنل است: هر اسکرینی که ستونِ
 |      عملیات داشته باشد و لو در این فایل دست نبریم (پنل‌های تازه هم) خودبه‌خود
 |      یک‌ردیفی می‌شود. علت انتخابِ data-column به‌جای کلاس این است که
 |      `TD::class()` فقط به <td> می‌رسد و سربرگِ <th> بی‌کلاس می‌ماند
 |      (vendor/orchid/platform/resources/views/partials/layouts/th.blade.php)؛
 |      پس هر قاعده‌ای که باید سربرگ و سلول را با هم بگیرد باید روی data-column بنشیند.
 */
.occasion-actions > div,
.table td:is([data-column="actions"], [data-column="action"], [data-column="akdamat"]) > div {
    display: flex;
    flex-wrap: wrap;
    align-items: center;
    justify-content: center;
    gap: .25rem;
}

/*
 | دکمه‌های داخلِ سلولِ عملیات: خودعرض، یک‌خطی و جمع‌وجور.
 | خودِ Orchid روی `.table td .btn` این‌ها را می‌گذارد:
 |     display:block; width:100%; white-space:nowrap;
 | که برای لینکِ داخلِ سلولِ نام خوب است، ولی در ستونِ عملیات باعث می‌شود دکمه‌ها
 | تمام‌عرض و پشته‌ای شوند. اینجا فقط همین سلول به حالتِ inline-flex برمی‌گردد
 | (همان چیزی که خودِ Orchid برای `.table tbody tr td>div>.form-group>.btn` دارد).
 | سلکتور ویژگیِ بالاتری از `.table td .btn` دارد، پس !important لازم نیست.
 |
 | پدینگِ افقی هم کمی جمع می‌شود: در فهرستِ کتاب‌ها ستونِ عملیات ۲۵۰پیکسلی است و
 | سه دکمه با آیکون (مدیریت کامل/ویرایش/حذف) با پدینگِ پیش‌فرضِ Orchid (۰٫۷۵rem
 | هر طرف) به ۲۷۸px می‌رسیدند؛ یعنی به‌جای یک ردیف، دو ردیف می‌شدند و ارتفاعِ
 | ردیف ۹۰px می‌ماند. با ۰٫۵rem، همان سه دکمه در یک ردیف جا می‌شوند.
 */
.table td:is([data-column="actions"], [data-column="action"], [data-column="akdamat"]) .btn {
    display: inline-flex;
    align-items: center;
    width: auto;
    padding: .25rem .5rem;
    white-space: nowrap;
}

/* ── ۵/۱) سلول‌های متنیِ کشسان (نام/عنوان/توضیح) ──────────────────── */
/*
 | مشکل: Orchid روی ستون‌های بی‌عرض `text-truncate` می‌گذارد — یعنی
 | `white-space: nowrap !important` — و لینکِ داخلِ سلول هم از `.table td .btn`
 | همان nowrap را می‌گیرد. نتیجه: بلندترین نام/عنوان/توضیحِ جدول یک کفِ نشکستنی
 | می‌شود و جدول از کارت بیرون می‌زند (دقیقاً همان چیزی که در فهرستِ مناسبت‌ها،
 | گزارش‌های خطا و کتاب‌ها دیده شد).
 |
 | راه‌حل: «هر سلولی می‌تواند بشکند» به‌عنوان پیش‌فرض، با یک فهرستِ کوتاهِ
 | استثنا (شناسه/تاریخ/عدد/بج) که بهتر است یک‌تکه بمانند. این جهتِ پیش‌فرض
 | عمدی است: ستون‌های متنیِ جدید در اسکرین‌های بعدی خودبه‌خود پوشش داده می‌شوند
 | و لازم نیست یادمان بماند اسمشان را به لیستی اضافه کنیم.
 |
 | `!important` لازم است چون باید `white-space:nowrap !important` کلاسِ
 | `text-truncate` خودِ Orchid را خنثی کنیم.
 */
.table td[data-column] {
    white-space: normal !important;
    /* «break-word» نه «anywhere»: کلمهٔ بلندِ بی‌فاصله هم می‌شکند، ولی کلمه‌های
       معمولی وسطِ خودشان تکه‌تکه نمی‌شوند (با anywhere یک عنوانِ بلند در ستونِ
       باریک به ده‌ها خطِ یک‌کلمه‌ای تبدیل می‌شد و ارتفاعِ ردیف به ۵۶۰px می‌رسید). */
    overflow-wrap: break-word;
}

/*
 | ستون‌هایی که باید یک‌تکه بمانند: شناسه، تاریخ/زمان، عدد و بج‌های وضعیت.
 |
 | یک استثنا عمداً بیرون مانده: `date`.
 |   • در فهرستِ مناسبت‌ها، سلولِ `date` فقط یک تاریخ نیست؛ یک خطِ دومِ توضیحی
 |     («پیشرو: شنبه ۲۰ سپتامبر») هم دارد. با nowrap، عرضِ کمینهٔ آن سلول به
 |     ۲۰۰px می‌رفت و روی گوشی جدول را ۱۳۱px از کارت بیرون می‌برد؛ پس همین یک
 |     ستون آزاد می‌شکند و روی گوشی هم با سقفِ دو خط کوتاه می‌شود.
 | محتوای این‌ها کوتاه است، پس nowrap هیچ‌جا جدول را پهن نمی‌کند؛ ولی نمی‌خواهیم
 | وسطِ یک تاریخِ میلادی یا یک شماره هم بشکنند.
 |
 | ⚠️ `!important` اینجا لازم است — و نه برای شکستنِ nowrapِ Orchid (که در بندِ
 | بالا با همان `!important` خنثی شد)، بلکه برای غلبه بر همان قاعدهٔ پیش‌فرضِ خودمان:
 | `.table td[data-column]{white-space:normal !important}`. بدونِ آن، این استثناها
 | می‌بازند و یک تاریخِ میلادی در ستونِ ۶۰پیکسلی سه خط می‌شود و ارتفاعِ ردیف به
 | ۶۰px می‌رسد (اندازه‌گیری‌شده در فهرستِ کتاب‌ها). یعنی «!important» را فقط جایی
 | بگذارید که قاعدهٔ مهمِ دیگری را رد می‌کند، وگرنه همین حالت پیش می‌آید.
 */
.table td[data-column="id"],
.table td[data-column="key"],
.table td[data-column="target-id"],
.table td[data-column="user-id"],
.table td[data-column="book-id"],
.table td[data-column="page-num"],
.table td[data-column="xml-num"],
.table td[data-column="num"],
.table td[data-column="j-year"],
.table td[data-column="slot"],
.table td[data-column="level"],
.table td[data-column="order"],
.table td[data-column="sort-order"],
.table td[data-column="pivot-sort-order"],
.table td[data-column="created-at"],
.table td[data-column="updated-at"],
.table td[data-column="last-used-at"],
.table td[data-column="expires-at"],
.table td[data-column="applies-from"],
.table td[data-column="usage"],
.table td[data-column="usage-pct"],
.table td[data-column="view-count"],
.table td[data-column="replies"],
.table td[data-column="count"],
.table td[data-column="hadiths-count"],
.table td[data-column="aliases-count"],
.table td[data-column="occurrence-count"],
.table td[data-column="size"],
.table td[data-column="price"],
.table td[data-column="confidence"],
.table td[data-column="avg-score"],
.table td[data-column="avg-time"],
.table td[data-column="top-score"],
.table td[data-column="rate-limit-daily"],
.table td[data-column="requests-today"],
.table td[data-column="last-7d-requests"],
.table td[data-column="total-requests"],
.table td[data-column="today-requests"],
.table td[data-column="is-active"],
.table td[data-column="is-approved"],
.table td[data-column="is-general"],
.table td[data-column="is-random-eligible"],
.table td[data-column="is-exact-match"],
.table td[data-column="day-rank"],
.table td[data-column="featured-hadiths-count"],
.table td[data-column="occasions-count"],
.table td[data-column="status"],
.table td[data-column="type"],
.table td[data-column="kind"],
.table td[data-column="state"],
.table td[data-column="language"],
.table td[data-column="image"],  .table td[data-column="target"] {
    white-space: nowrap !important;
  }

/*
 | ستونِ «عنوان» یک کفِ عرضِ کوچک هم روی دسکتاپ دارد.
 | چرا: در چیدمانِ خودکارِ جدول، فضای آزادِ کارت بین ستون‌ها بر اساس «پهن‌ترین
 | محتوا» پخش می‌شود، نه بر اساس اهمیت؛ در فهرستِ کتاب‌ها همین باعث می‌شد ستونِ
 | «نویسنده» ۲۹۵px بگیرد و ستونِ «عنوان» به ۱۱۸px بیفتد و عنوانِ بلند در ده‌ها
 | خط بشکند (ردیفِ ۱۵۳ پیکسلی). با این کف، عنوانِ ردیف خوانا می‌ماند.
 |
 | نکته: همین کف را عمداً روی `name` نمی‌گذاریم. جدولِ «کلیدهای API» دوازده
 | ستون دارد و کارتِ پنل روی پنجرهٔ ۱۳۶۶px فقط ۹۷۸px جا می‌دهد؛ کفِ ۱۶۰پیکسلی
 | روی ستونِ نام، همان جدول را از کادر بیرون می‌برد.
 */
.table td[data-column="title"],
.table td[data-column="booktitle"],
.table td[data-column="book-title"],
.table td[data-column="bab-title"],
.table td[data-column="narrator-text"],
.table td[data-column="display-name"] {
    min-width: 10rem !important;
}

/* لینکِ نام/عنوان هم از قاعدهٔ nowrap خودِ Orchid آزاد شود (سلکتور ویژگی برنده است). */
.table td[data-column="name"] .btn,
.table td[data-column="title"] .btn,
.table td[data-column="name"] a,
.table td[data-column="title"] a,
.table td.occasion-name .btn {
    white-space: normal;
}

/* ── ۵/۱.۲) سقفِ خطِ سلول: ردیفِ جمع‌وجور ───────────────────────── */
/*
 | چرا: «شکستن» (بند ۵/۱) جلوی پهن‌شدنِ جدول را می‌گیرد ولی به‌تنهایی ردیف را
 | کوتاه نمی‌کند؛ یک عنوانِ بلند در ستونِ باریک شش خط می‌شود و ردیف ۱۸۵px ارتفاع
 | می‌گیرد. پس متن‌های بلند سقفِ خط می‌گیرند و اضافهشان با «…» خلاصه می‌شود؛
 | متنِ کامل در صفحهٔ ویرایش همان ردیف هست.
 |
 | دو سطح داریم: ستونِ شناسه (عنوان/نام) سه خط، و ستون‌های فراداده دو خط.
 | روی موبایل هر دو دو خط می‌شوند (بند بعدی). چون آن قاعده بعد از این یکی
 | نوشته شده، همان برنده است.
 */
/*
 | ⚠️ سیاستِ نگهداری: این فهرست باید هر ستونِ متنیِ بلندِ تازه را در بر بگیرد؛
 | اگر ستونی اینجا نباشد و رشته‌اش بلند باشد، در ستونِ باریک چندخطی می‌شود و
 | ردیف را بلند می‌کند. نمونهٔ واقعی: ستونِ `report-type` در فهرستِ گزارش‌های
 | خطا (عرضِ ۶۴px) متنِ «مشکل نمایش یا محتوای تکراری» را در ۶ خط می‌شکست و
 | ارتفاعِ ردیف در پنجرهٔ ۱۲۸۰px به ۱۴۵px می‌رسید؛ با سقفِ دو خط، همان ردیف
 | ۸۵px است.
 */
.table td[data-column="excerpt"] > div,
.table td[data-column="description"] > div,
.table td[data-column="body"] > div,
.table td[data-column="pattern"] > div,
.table td[data-column="report-type"] > div,
.table td[data-column="source-type"] > div,
.table td[data-column="notes"] > div,
.table td[data-column="note"] > div,
.table td[data-column="message"] > div,
.table td[data-column="details"] > div,
.table td[data-column="book"] > div,
.table td[data-column="top-book-title"] > div,
.table td[data-column="occasion"] > div,
.table td[data-column="author"] > div,
.table td[data-column="domain"] > div,
.table td[data-column="origin-domain"] > div,
.table td[data-column="allowed-endpoints"] > div,
.table td[data-column="endpoint"] > div,
.table td[data-column="term"] > div,
.table td[data-column="alias"] > div,
.table td[data-column="label"] > div,
.table td[data-column="reason"] > div,
.table td[data-column="snippet"] > div,
.table td[data-column="source-display"] > div,
.table td[data-column="source-name"] > div,
.table td[data-column="contents-mapped"] > div,
.table td[data-column="parent-path"] > div,
.table td[data-column="candidates"] > div,
.table td[data-column="entity"] > div {
    display: -webkit-box;
    -webkit-line-clamp: 2;
    -webkit-box-orient: vertical;
    overflow: hidden;
}

/*
 | ستون‌های «شناسهٔ فنی» (اسلاگ، کلید): یک خط + «…».
 | این‌ها متنِ کوتاهِ معناداری نیستند (اسلاگِ کتاب تا ۹۰ کاراکتر می‌رسد) و اگر
 | آزاد بشکنند، در ستونِ ۱۲۰پیکسلی شش‌خطی می‌شوند و بلندترین ردیفِ فهرست را
 | می‌سازند: در فهرستِ کتاب‌ها ردیف از ۱۱۶px به ۱۴۵px می‌رفت. با `overflow-wrap:
 | anywhere` هم عرضِ کمینهٔ سلول کوچک می‌ماند (پس جدول پهن نمی‌شود) و هم سقفِ یک
 | خط قابل‌اعمال است.
 */
.table td[data-column="slug"] > div,
.table td[data-column="clean-slug"] > div {
    display: -webkit-box;
    -webkit-line-clamp: 1;
    -webkit-box-orient: vertical;
    overflow: hidden;
    overflow-wrap: anywhere;
}

/* ستونِ شناسه: سه خط (روی گوشی دو خط می‌شود). */
.table td[data-column="title"] > div,
.table td[data-column="name"] > div,
.table td[data-column="narrator-text"] > div,
.table td[data-column="display-name"] > div,
.table td[data-column="booktitle"] > div,
.table td[data-column="book-title"] > div,
.table td[data-column="bab-title"] > div,
.table td[data-column="clean-title"] > div {
    display: -webkit-box;
    -webkit-line-clamp: 3;
    -webkit-box-orient: vertical;
    overflow: hidden;
}

/* ── ۵/۲) موبایل و تبلت: جدول‌های فهرست ──────────────────────────── */
/*
 | مشکل روی موبایل: Orchid روی هر ستونِ دارای `width` یک `min-width` اینلاین
 | می‌گذارد و هر ستونِ بی‌عرض را `text-truncate` می‌کند. روی نمایشگر ۳۹۰px نتیجه
 | این است که جدول چند برابرِ کادر پهن می‌شود و کاربر باید افقی اسکرول کند تا
 | ستونِ «عملیات» (که در RTL آخرین ستون و سمتِ چپ است) را ببیند.
 |
 | راه‌حل چند بخش دارد:
 |   ۱) ستون‌های فراداده در موبایل پنهان می‌شوند (فهرستِ زیر).
 |   ۲) قلم و پدینگِ سلول‌ها کمی جمع می‌شود و متنِ ستون‌های بلند دو خطِ آخر
 |      سه‌نقطه می‌خورد، تا جدول کوتاه و ردیف‌ها جمع‌وجور بمانند.
 |   ۳) ستونِ عملیات به لبهٔ چپ می‌چسبد (sticky) تا در RTL — که آخرین ستون و
 |      سمتِ چپ است — بدونِ اسکرولِ افقی هم دیده و کلیک شود.
 |
 | جدول همچنان داخلِ کارتِ `.table-responsive` افقی اسکرول می‌شود (رفتارِ استانداردِ
 | جدول در موبایل)؛ فقط دیگر «بیرون‌زدگی از کارت» و «ستونِ عملیاتِ ناپیدا» نداریم.
 */

/* ۱) ستون‌های «فراداده»: در موبایل پنهان.
 |    سیاست این است: روی گوشی همان ستون‌هایی بمانند که برای «شناختنِ ردیف و کارِ
 |    اصلی» لازم‌اند (عنوان/نام، وضعیت، عملیات) و ستون‌های شناسه‌ای، فنی و
 |    امتیازی بروند. `slugها همان کلیدِ انگلیسیِ ستون‌هاست؛ چون هم <th> و هم <td>
 |    را می‌گیرد، سربرگ هم با سلول‌ها پنهان می‌شود و سربرگِ یتیم نمی‌ماند. */
@media (max-width: 767.98px) {
    .table [data-column="id"],
    .table [data-column="slug"],
    .table [data-column="image"],
    .table [data-column="key"],
    .table [data-column="domain"],
    .table [data-column="source"],
    .table [data-column="source-type"],
    .table [data-column="target-id"],
    .table [data-column="target-name"],
    .table [data-column="suggested-language"],
    .table [data-column="is-general"],
    .table [data-column="is-random-eligible"],
    .table [data-column="selection-type"],
    .table [data-column="day-rank"],
    .table [data-column="created-at"],
    .table [data-column="rate-limit-daily"],
    .table [data-column="requests-today"],
    .table [data-column="last-used-at"],
    .table [data-column="expires-at"],
    .table [data-column="allowed-endpoints"],
    .table [data-column="category"],
    .table [data-column="usage-pct"],
    .table [data-column="top-score"],
    .table [data-column="total-requests"],
    .table [data-column="today-requests"],
    .table [data-column="level"],
    .table [data-column="order"],
    .table [data-column="sort-order"],
    .table [data-column="pivot-sort-order"],
    .table [data-column="book-id"],
    .table [data-column="user-id"],
    .table [data-column="j-year"],
    /*
     | دستهٔ دومِ پنهان‌سازی: ستون‌هایی که روی گوشی «تکراری یا کم‌ارزش»اند.
     | این‌ها از اندازه‌گیریِ واقعی در عرضِ ۳۹۰px درآمدند: کارت فقط ۴۶۲px جا
     | می‌دهد و ستونِ شناسه (نام/عنوان) و ستونِ عملیات (چسبیده به لبهٔ چپ) هرکدام
     | ~۱۴۰px از آن را می‌خواهند؛ هر ستونِ اضافه یعنی اسکرولِ افقیِ بیشتر داخلِ
     | کارت. مثلاً در فهرستِ مناسبت‌ها «تعداد احادیث منتخب» و در فهرستِ محتوای
     | کتاب «نام کتاب» (که در بالای صفحه نوشته شده) چیزی به دانستنِ ردیف اضافه
     | نمی‌کنند و در عوض ۸۰–۱۶۷px جا می‌گیرند.
     | وضعیت (is-active/is-approved/status/type/state) عمداً می‌ماند؛ چون
     | بدونِ آن، ردیف روی گوشی بی‌معنا است.
     */
    .table [data-column="booktitle"],
    .table [data-column="book-title"],
    .table [data-column="email"],
    .table [data-column="target"],
    .table [data-column="replies"],
    .table [data-column="usage"],
    .table [data-column="occasions-count"],
    .table [data-column="featured-hadiths-count"],
    .table [data-column="occurrence-count"],
    .table [data-column="language"] {
        display: none !important;
    }
}

/*
 | لپ‌تاپ/دسکتاپِ باریک (زیر ۱۴۰۰px): دو ستونِ «آماری» کلیدهای API پنهان می‌شوند.
 |
 | چرا اینجا و نه در بلاکِ موبایل: این جدول ۱۲ ستون دارد و کارتِ پنل روی پنجرهٔ
 | ۱۳۶۶px فقط ۹۷۸px جا می‌دهد. چیدمانِ خودکارِ جدول که جا کم می‌آورد، ستونِ «نام»
 | (تنها ستونِ متنی) را تا ۵۶px له می‌کند و نام کلید در دو خطِ چهارحرفی می‌شکند —
 | همان ظاهرِ خردشده‌ای که در اسکرین‌شات دیده شد.
 |
 | این دو ستون (`rate-limit-daily` و `requests-today`) فقط در همین اسکرین وجود
 | دارند و «آمارِ لحظه‌ای»اند، نه هویتِ ردیف؛ سقفِ روزانه در فرمِ ویرایش همان کلید
 | هم هست. با پنهان‌شدنشان، ۱۱۸px آزاد می‌شود و ستونِ نام جا می‌گیرد.
 | روی نمایش‌گرهای پهن‌تر (۱۴۰۰px به بالا) هیچ چیز پنهان نمی‌شود.
 */
@media (max-width: 1399.98px) {
    .table [data-column="rate-limit-daily"],
    .table [data-column="requests-today"] {
        display: none !important;
    }
}

/* در تبلت (۷۶۸ تا ۹۹۲px) فقط ستون‌های واقعاً حاشیه‌ای حذف می‌شوند. */
@media (max-width: 991.98px) {
    .table [data-column="slug"],
    .table [data-column="updated-at"],
    .table [data-column="expires-at"],
    .table [data-column="last-used-at"] {
        display: none !important;
    }
}

@media (max-width: 767.98px) {
    /* ۲) جدولِ جمع‌وجورتر */
    .table thead th {
        font-size: .78rem;
        padding: .5rem .5rem;
    }

    .table tbody tr td {
        font-size: .8rem;
        padding: .5rem .5rem;
    }

    .table tbody tr td:first-child {
        padding-right: .75rem !important;
    }

    .table tbody tr td:last-child {
        padding-left: .75rem !important;
    }

    /* ۳) نکتهٔ مهم دربارهٔ `min-width`: به‌نظر می‌رسد صفرکردنِ min-widthِ همهٔ
       ستون‌ها روی موبایل خوب باشد، ولی نیست: جدول به عرضِ کارت جمع می‌شود و
       ستون‌های متنی به چند پیکسل له می‌شوند؛ نتیجه ردیف‌هایی چندهصدپیکسلی است.
       پس min-widthها سر جای خودشان می‌مانند، جدول اگر جا کم بیاورد داخلِ همان
       کارتِ `.table-responsive` افقی اسکرول می‌شود، و فقط یک کفِ معقول به
       ستون‌های متنی می‌دهیم تا خوانا بمانند. `!important` لازم است چون Orchid
       عرض را اینلاین (`style="min-width:80px"`) می‌گذارد.

       عددِ کف عمداً ۹rem است و نه ۱۱rem: کارت روی گوشی ۴۶۲px جا می‌دهد و
       ستونِ شناسه و ستونِ عملیات (چسبیده به لبهٔ چپ) هرکدام کفِ خودشان را
       می‌خواهند؛ با ۱۱rem، همان دو ستون ۳۳۴px می‌خوردند و بقیه مجبور بودند
       داخلِ کارت اسکرول شوند. دو خط متن در ۱۳۷px هنوز ردیف را می‌شناساند و
       متنِ کامل در صفحهٔ ویرایش هست. */
    .table tbody tr td[data-column="name"],
    .table tbody tr td[data-column="title"],
    .table tbody tr td[data-column="narrator-text"],
    .table tbody tr td[data-column="display-name"],
    .table tbody tr td[data-column="body"],
    .table tbody tr td[data-column="description"],
    .table tbody tr td[data-column="excerpt"],
    .table tbody tr td[data-column="booktitle"],
    .table tbody tr td[data-column="book-title"],
    .table tbody tr td[data-column="bab-title"] {
        min-width: 9rem !important;
    }

    /* ستونِ تاریخ هم عرضِ ۱۵۰–۲۲۰ پیکسلیِ دسکتاپ را لازم ندارد؛ محتوایش
       («۸ شهریور ۱۴۰۵» و «۱ محرم») با ۶rem هم جا می‌شود. */
    .table tbody tr td[data-column="date"],
    .table tbody tr td[data-column="created-at"] {
        min-width: 6rem !important;
    }

    /* ستونِ `date` سلولِ دوخطی است (تاریخ + خطِ راهنمای «پیشرو»). روی گوشی
       همان دو خط کافی است؛ بدونِ این سقف، متنِ راهنما در ستونِ ۹۰پیکسلی چهار
       خط می‌شد و ارتفاعِ ردیفِ مناسبت‌ها از ۷۴px به ۹۳px می‌رفت. */
    .table td[data-column="date"] > div {
        display: -webkit-box;
        -webkit-line-clamp: 2;
        -webkit-box-orient: vertical;
        overflow: hidden;
    }

    /* ۴) ستون‌های متنی روی گوشی حداکثر دو خط + سه‌نقطه.
       بدونِ این، یک عنوانِ بلند در ستونِ باریک دهها خط می‌شود و ارتفاعِ ردیف به
       چندصد پیکسل می‌رسد (اندازه‌گیری: کتابی با عنوانِ بلند ۵۶۳px). متنِ کامل
       در صفحهٔ ویرایش هست و کاربر با همان دو خط، ردیف را می‌شناسد. */
    .table td[data-column="name"] > div,
    .table td[data-column="title"] > div,
    .table td[data-column="narrator-text"] > div,
    .table td[data-column="display-name"] > div,
    .table td[data-column="booktitle"] > div,
    .table td[data-column="book-title"] > div,
    .table td[data-column="bab-title"] > div,
    .table td[data-column="clean-title"] > div,
    .table td[data-column="description"] > div,
    .table td[data-column="body"] > div,
    .table td[data-column="excerpt"] > div,
    .table td[data-column="snippet"] > div,
    .table td[data-column="pattern"] > div,
    .table td[data-column="book"] > div,
    .table td[data-column="top-book-title"] > div,
    .table td[data-column="occasion"] > div,
    .table td[data-column="author"] > div,
    .table td[data-column="alias"] > div,
    .table td[data-column="label"] > div,
    .table td[data-column="term"] > div,
    .table td.occasion-name > div {
        display: -webkit-box;
        -webkit-line-clamp: 2;
        -webkit-box-orient: vertical;
        overflow: hidden;
    }

    /* ۵) دکمه‌های عملیات روی گوشی فشرده‌تر شوند و ستونشان بتواند به اندازهٔ
       دو دکمه در هر ردیف باریک شود. روی دسکتاپ عرضِ ثابتِ ستون (۲۲۰–۳۳۰px)
       را دست نمی‌زنیم؛ ولی روی گوشی همان عرض، بیشترِ کادرِ ۳۹۰پیکسلیِ چسبیده
       به لبهٔ چپ را می‌خورد و برای متن جا نمی‌گذارد. */
    .table td:is([data-column="actions"], [data-column="action"], [data-column="akdamat"]) .btn,
    .table td.occasion-actions .btn {
        font-size: .75rem;
        padding: .2rem .4rem;
    }

    /* کفِ ستونِ عملیات: ۸٫۷۵rem ≈ ۱۳۳px — جا برای دو دکمهٔ فشرده در یک ردیف
       (بندِ ۵ بالا هم پدینگشان را جمع کرده). روی دسکتاپ عرضِ ثابتِ ۲۲۰–۳۳۰px
       دست‌نخورده می‌ماند و فقط روی گوشی است که این کف اعمال می‌شود. این عدد از
       اندازه‌گیری در عرضِ ۳۹۰px درآمد: با ۱۱rem، ستونِ عملیات و ستونِ شناسه
       تنها نیمی از کارت را می‌خوردند و فهرست نظرات ۲۴px اسکرولِ اضافه داشت. */
    .table td:is([data-column="actions"], [data-column="action"], [data-column="akdamat"]),
    .table td.occasion-actions {
        min-width: 8.75rem !important;
    }

    /* اسکرولِ افقیِ داخلِ کارت به صفحه/تاریخچهٔ مرورگر سرایت نکند. */
    .table-responsive {
        overscroll-behavior-x: contain;
    }
}

/* ── ۵/۳) ستونِ «عملیات» چسبیده به لبهٔ چپ (در RTL آخرین ستون) ──────── */
/*
 | چرا روی همهٔ عرض‌ها و نه فقط موبایل: در RTL ستونِ عملیات آخرین ستون است و سمتِ
 | چپ می‌نشیند؛ هر بار جدول از کارت پهن‌تر شود (موبایل، یا فهرست‌های پرستونی مثل
 | «کلیدهای API» با دوازده ستون که در پنجرهٔ ۱۲۸۰px هم جا نمی‌شوند) همان ستون
 | بیرونِ کادر می‌افتد و دکمه‌های ویرایش/حذف ناپدید می‌شوند. این دقیقاً اشکالی بود
 | که قبلاً در فهرستِ گزارش‌های خطا و مناسبت‌ها دیده شد. چسباندنِ ستون به لبهٔ
 | درونیِ کارت، این کلاسِ اشکال را به یک اسکرولِ ظاهریِ بی‌خطر تبدیل می‌کند.
 |
 | روی جدول‌هایی که جا می‌شوند، sticky هیچ اثری ندارد (چیزی برای اسکرول نیست).
 | زمینهٔ صریح لازم است تا ردیف‌های زیرین از پشتِ سلولِ چسبیده دیده نشوند.
 */
.table td:is([data-column="actions"], [data-column="action"], [data-column="akdamat"]),
.table td.occasion-actions {
    position: sticky;
    left: 0;
    z-index: 2;
    background-color: var(--bs-body-bg, #fff);
    box-shadow: -6px 0 8px -6px rgba(21, 20, 26, .18);
}

.table thead th:is([data-column="actions"], [data-column="action"], [data-column="akdamat"]) {
    position: sticky;
    left: 0;
    z-index: 3;
    background-color: var(--bs-body-bg, #fff);
}

/* روی ردیفِ زیرِ نشانگر، سلولِ چسبیده هم باید رنگِ hover بگیرد، وگرنه
   بریده‌به‌نظر می‌رسد. */
.table tbody tr:hover td:is([data-column="actions"], [data-column="action"], [data-column="akdamat"]),
.table tbody tr:hover td.occasion-actions {
    background-color: var(--bs-tertiary-bg, #f8f9fa);
}

/* ── ۶) ویرایشگر سبک برای فایل‌های چندمگابایتی ─────────────────── */
/*
 | CodeFlask متن را با Prism رنگ‌آمیزی می‌کند و برای فایل‌های چندمگابایتی همین کار
 | مرورگر را قفل می‌کند. در «حالت سبک» به‌جای آن، یک textarea ساده می‌آید: بدون
 | رنگ‌آمیزی، بدون شمارهٔ خط، بدون جاوااسکریپت — فقط یک کادر متنِ سریع.
 */
textarea.xml-editor-light {
    display: block;
    width: 100%;
    /* در CSS خود Orchid قاعدهٔ `.form-control { max-width: 600px }` هست و همین،
       عرض کادر متن را نصفِ کارت می‌کرد؛ اینجا آزادش می‌کنیم. */
    max-width: 100% !important;
    direction: ltr;
    text-align: left;
    font-family: "SFMono-Regular", Consolas, "Liberation Mono", Menlo, Courier, monospace;
    font-size: 13px;
    line-height: 20px;
    height: 70vh;
    padding: 10px;
    background-color: #fff;
    color: #24292f;
    white-space: pre;
    overflow: auto;
    tab-size: 4;
    resize: none;
}