# دلتای گفت‌وگوی دوم نسبت به گفت‌وگوی اول و ماکاپ فعلی

این سند از خواندن کامل، پیام‌به‌پیام، [رونوشت گفت‌وگوی دوم](capacity-engine-chat-2.fa.md) (۶۰ پیام، Prompt 1 تا Prompt 30) به دست آمده و هر مورد را با [رونوشت گفت‌وگوی اول](capacity-engine-chat.fa.md) و کد فعلی ماکاپ (`../capacity-engine-mockup/js/engine/model.js`، `network.js`، `README.md`) مقایسه کرده است. هدف: فقط مفاهیم/فرمول‌ها/قواعد/صفحات *تازه یا اصلاح‌شده* را فهرست کند؛ هر بازنویسی صرف محتوای قبلی حذف شده است. برای هر مورد، تصمیم اجرا («برای پیاده‌سازی در این وظیفه» یا «موکول‌شده» + دلیل) ثبت شده است.

## خلاصهٔ ساختار گفت‌وگو

- **Prompt 1:** کاربر لینک گفت‌وگوی اول را می‌فرستد؛ دستیار صراحتاً می‌گوید نمی‌تواند محتوای آن را از طریق لینک بخواند.
- **Prompt 2:** کاربر عیناً نمونهٔ عددی سنگان–فولاد مبارکه (همان اعداد §14–16 مدل فعلی) را دوباره پیست می‌کند تا زمینه بازسازی شود؛ چیزی عددی جدید ندارد.
- **Prompt 3–4:** مشخصات کامل UX/UI — بخش اصلی و مستقیماً قابل‌استفادهٔ این گفت‌وگو.
- **Prompt 5–21:** بازنویسی/رسمی‌سازی مدل مفهومی، ریاضی و معماری نرم‌افزار (۶ سند مدیریتی/مفهومی/معماری/ریاضی/SOW/قابلیت‌ها). عمدتاً فرمول‌بندی دقیق‌تر همان مفاهیم سند اول با نام‌گذاری رسمی‌تر؛ تعداد کمی مفهوم واقعاً تازه دارد (فهرست زیر).
- **Prompt 22–27:** اصلاح بنیادین مدل دامنه: تشکیل قطار در ایران **مبدا‑مقصدی** است (نه تشکیل مجدد در میانهٔ راه مثل شبکه‌های متراکم بین‌المللی)؛ معرفی یک منبع دادهٔ سوم واقعی (برنامهٔ حرکت Excel + پایگاه Access) که **در مخزن ما موجود نیست**؛ نگاشت کامل فیلدهای آن به یک مدل کاننیکال.
- **Prompt 28–29:** کاربر لینک زندهٔ همین ماکاپ (`https://motortolid.psrai.ir/#/network`) را می‌فرستد؛ دستیار آن را صفحه‌به‌صفحه نقد می‌کند — **مستقیم‌ترین و عملی‌ترین بخش کل گفت‌وگو**.
- **Prompt 30 (پایانی، بی‌پاسخ):** «از جهت UI, UX نکاتت رو برای ارتقاء ش بگو یا خودت یه موکاپ آماده کن» — همان پرسشی که این وظیفه پاسخ عملی آن است.

---

## ۱. مفاهیم/فرمول‌های ریاضی و مدل — تازه یا اصلاح‌شده

| # | مفهوم | منبع | نوع | تصمیم |
|---|---|---|---|---|
| M1 | تفکیک رسمی **Generation / Estimation / Optimization** به‌عنوان سه عملیات جدا که نباید در یک تابع ادغام شوند | Prompt 6، پاسخ دستیار | اصلاح مفهومی (تأکید صریح‌تر از سند اول) | برای پیاده‌سازی — به‌صورت برچسب‌گذاری در نمای کلی موتور (نمای ۱) که این سه گام را از هم متمایز نشان دهد؛ کد موجود در `engine/model.js`/`network.js` از قبل این جداسازی را رعایت می‌کند |
| M2 | ۱۲ **Test Case** رسمی (CASE‑001 تا CASE‑012: Mixed Track، Batch Optimization، Loaded/Empty، Buffer، Station‑Length، Fleet، Shared Resource، Policy، Demand، Investment، Bottleneck Migration، Network Re‑optimization) | Prompt 6، پاسخ دستیار | تازه (برچسب‌گذاری صریح) | برای پیاده‌سازی جزئی — نمای «اعتبارسنجی» فعلی قبلاً بیشتر این قواعد را per-value بررسی می‌کند؛ برچسب CASE-00x به هر قاعدهٔ موجود اضافه می‌شود تا ردیابی با سند صریح شود |
| M3 | **Explainability با تفکیک Primary/Secondary Binding Constraint** (نه یک فهرست تخت) | Prompt 7 و 9 و 10، پاسخ‌های دستیار | اصلاح | برای پیاده‌سازی — درخت «خروجی توضیح‌پذیر» در نمای ظرفیت مسیر (C_r) به دو ردهٔ Primary/Secondary بازآرایی می‌شود؛ داده از همان `limitingFactor` و گیت‌های `bufferOk/fleetOk/stationOk` موجود در `model.js` قابل استخراج است |
| M4 | **Hidden Capacity** = C_optimized‑operation − C_current‑operation (ظرفیت قابل‌آزادسازی صرفاً با اصلاح عملیات، بدون سرمایه‌گذاری) | Prompt 10، §۳۱ و Prompt 11، §۳۱ | تازه | برای پیاده‌سازی — در نمای سناریو/حساسیت به‌عنوان یک ردیف مشتق (تفاوت ظرفیت بهترین N فعلی با بهترین N در صورت اصلاح Batch/رژیم جهت‌دهی، بدون تغییر Buffer/Fleet/Station) اضافه می‌شود |
| M5 | **Capacity Transfer** بین Routeهای رقیب = C_available − C_reserved | Prompt 10، §۵۴ | تازه | موکول‌شده — نیازمند سیاست تخصیص چندمسیره‌ای که در LP دو‑مسیرهٔ فعلی فرض ساده‌تری (حل مشترک هم‌زمان) دارد؛ افزودن یک لایهٔ سیاست انتقال ظرفیت پس از حل، فراتر از دامنهٔ این وظیفه است |
| M6 | **سه‌گانهٔ تقاضا** با تعریف رسمی: D_Market ≥ D_Transportable ≥ D_Allocated (بازار / قابل‌حمل با واگن‌وناوگان‌وترمینال‌وزمان / تخصیص‌یافته پس از حل شبکه) | Prompt 3، §۴ و Prompt 23، §پایانی | اصلاح/تدقیق (در Prompt 3 به‌عنوان ایدهٔ UI مطرح شد؛ در Prompt 23 تعریف ریاضی رسمی گرفت) | برای پیاده‌سازی — در نمای ظرفیت مسیر/شبکه، کنار D (تقاضا) و C (ظرفیت) موجود، این سه‌گانه به‌صراحت با همین سه برچسب نمایش داده می‌شود؛ از داده‌های موجود (D_r، C_r) قابل مشتق است، چیز جدیدی محاسبه نمی‌شود |
| M7 | **Capacity Profile**: C = f(Route, OD, TrainType, Commodity, LoadState, Time, Direction, Station, Wagon, Locomotive) — ظرفیت یک عدد تخت نیست، به OD/کالا/زمان بستگی دارد | Prompt 23، §پایانی و Prompt 27، §۵۶ | تازه | موکول‌شده — نیازمند چند کالا/چند OD هم‌زمان با داده‌های واقعی تناژ به تفکیک کالا که در SRC-02/SRC-03 وجود ندارد (این دو فایل فقط تناژ/بارنامه به تفکیک مبدأ یا مبدأ‑مقصد دارند، نه کالا)؛ ساختن این پروفایل با داده‌های نمایشی، خودِ داده را گمراه‌کننده می‌کند |
| M8 | **الگوی عملیاتی بومی ایران: تشکیل قطار مبدا‑مقصدی**، در تقابل صریح با مدل بین‌المللی تشکیل/تفکیک مجدد در میانهٔ مسیر؛ `Train=(O,D,Type,Load,Formation,Route)` با تشکیل در مبدأ | Prompt 22، پاسخ دستیار | **اصلاح بنیادین دامنه** (تازه در این گفت‌وگو، در سند اول نبود) | برای پیاده‌سازی — این یک اصلاح مفهومی مهم است که باید در متن/برچسب‌های ماکاپ صریح شود: هرجا از Batch یا تشکیل قطار صحبت می‌شود باید روشن باشد قطار در مبدأ تشکیل و در مقصد تخلیه می‌شود، نه در میانهٔ راه |
| M9 | تفکیک صریح **Train Formation** (تشکیل قطار در مبدأ برای یک سرویس مشخص) از **Operational Batch** (گروه‌بندی قطارهای ازپیش‌تشکیل‌شده برای بهره‌برداری تک‌خطه) — این دو باید هرگز یکی گرفته نشوند | Prompt 22 و 23 و 29 (§۸) | **اصلاح بنیادین** | برای پیاده‌سازی — نمای «بچ‌سازی جهت‌دار» فعلی مفهوم Batch را دقیقاً به‌معنای Operational Batch پیاده کرده (گروه‌بندی قطارهای هم‌جهت)، که درست است؛ فقط باید یک جملهٔ توضیحی اضافه شود که این Batch با «تشکیل قطار» یکی نیست تا کاربر دچار برداشت اشتباه نشود |
| M10 | ورودی «مسئله» باید قبل از ورود به لایه‌های ظرفیت مشخص شود: Scenario/Origin/Destination/Commodity/Demand/Time Horizon/Train Type/Existing Schedule — به‌جای ورود مستقیم به C_b→C_s→C_r→C_n | Prompt 29، §۲ | **اصلاح جریان کاربری** | برای پیاده‌سازی — نمای اول («نمای کلی موتور») یک گام «تعریف مسئله» را قبل از چهار سؤال موجود اضافه می‌کند (بدون حذف چهار سؤال، که خودِ گفت‌وگو تأیید می‌کند باید حفظ شوند) |
| M11 | **برنامهٔ حرکت موجود / Baseline Schedule** باید قبل از تولید ظرفیت جدید روی شبکه اعمال شود: `Existing Schedule → Mandatory Capacity Consumption → Remaining Network Capacity → New Capacity Generation` | Prompt 26–27 و 29، §۳ | تازه | **موکول‌شده — کمبود دادهٔ واقعی**: منبع این مفهوم دو فایل واقعی جدید است (`REPORTKholase_31-06-1405_02-19-35.xlsx` برنامهٔ حرکت و `aaa.accdb` با فیلدهای TrainNo/StationName/Sequence/time_in/time_take/time_out/RequiredWait/Kilometerage/MaxSpeed) که **هیچ‌کدام در مخزن ما وجود ندارد** (فقط SRC-02/SRC-03 تناژ موجودند؛ بررسی شد با `find` روی `new-idea-content/source/data/`). ساختن Baseline Schedule با داده‌ی جعلی، ادعای «دادهٔ واقعی» را که در بقیهٔ ماکاپ به‌دقت رعایت شده نقض می‌کند |
| M12 | مدل **Train / TrainRun / TrainStationCall** با فیلدهای واقعی (Sequence، time_in، time_take، time_out، RequiredWait، Kilometerage، Distance، MaxSpeed) و وضعیت «نیازمند تأیید معنایی» برای فیلدهای مبهم (time_take، RequiredWait، seir، faultV، sumDistancezz) | Prompt 26–27 | تازه (نگاشت داده، نه فرمول) | موکول‌شده — همان دلیل M11؛ بدون فایل منبع واقعی، فقط می‌توان اسکیمای مفهومی را در سند نگه داشت، نه در UI پیاده‌سازی کرد |
| M13 | **EffectiveSpeed = min(InfrastructureLimit, TrainLimit, OrganizationLimit, TemporaryRestriction)** — تدقیق فرمول سرعت مؤثر موجود در سند اول (که فقط `V_effective = L_total / T_run` داشت) | Prompt 2، پاسخ دستیار (بخش ۱) و Prompt 26، §۸ | اصلاح/تدقیق جزئی | موکول‌شده — ماکاپ فعلی سرعت را به‌صورت ورودی مستقیم پارامتر رژیم می‌گیرد، نه از چند منبع محدودکننده؛ افزودن «محدودیت سازمانی/موقت» بدون دادهٔ واقعی این محدودیت‌ها صرفاً یک ورودی نمایشی دیگر اضافه می‌کند که ارزش تبیینی کمی دارد |
| M14 | **No Verified Mapping ⇒ No Production Use** (اصل حاکم جدید، موازی با «No Feasible Schedule ⇒ No Operational Capacity» موجود) | Prompt 27، §۱۳۰ | تازه (اصل حاکم) | برای پیاده‌سازی — این اصل همان چیزی است که ماکاپ فعلی برای SRC-02/SRC-03 از قبل رعایت می‌کند (برچسب «داده واقعی» فقط روی ردیف‌های تأییدشده)؛ در سند/UI به‌صراحت به‌عنوان یک اصل نام‌گذاری‌شده تکرار می‌شود، نه منطق تازه |

## ۲. اصلاحات نسبت به مدل/ماکاپ فعلی (نه فقط افزودنی)

| # | اصلاح | منبع | وضعیت در ماکاپ فعلی | تصمیم |
|---|---|---|---|---|
| C1 | نمونهٔ عددی سنگان–فولاد مبارکه باید **Validation/Test Case باشد، نه مبنای معماری**؛ اعداد آن (۴۲ واگن، ۶۷ تن، Buffer=۶/۱۰/۱۵) نباید Default عمومی موتور تلقی شوند | Prompt 5، 6 (§۳۳)، 27 (§۱۰۶–۱۰۷) | **بدون تناقض** — README فعلی از قبل می‌گوید «مسیر اول یکی از مسیرهای نمونه است، نه مبنای الزام‌آور» و SRC-03 مسیرهای دیگر را هم به‌عنوان انتخاب واقعی OD ارائه می‌دهد | نیازی به تغییر کد نیست؛ فقط عبارت‌بندی در README/متن نمای پارامترها می‌تواند صراحتاً بگوید «این پارامترها Validation Case سند مرجع‌اند، نه پیش‌فرض موتور» |
| C2 | ظرفیت شبکه هرگز نباید حاصل جمع سادهٔ ظرفیت مسیرها باشد؛ این تأکید در گفت‌وگوی دوم به‌کرات (بیش از ۶ بار) تکرار شده | Prompt 6، 9، 10، 27 | **از قبل پیاده‌سازی‌شده** — README می‌گوید نمای اعتبارسنجی همین قاعده را با مقادیر واقعاً محاسبه‌شده بررسی می‌کند | بدون تغییر |
| C3 | صفحهٔ اول ماکاپ نباید از «ظرفیت» شروع شود؛ باید از «تعریف مسئله» شروع شود (نگاه کنید M10) | Prompt 29، §۲ | نمای ۱ فعلی مستقیماً چهار سؤال ظرفیت را معرفی می‌کند | برای پیاده‌سازی — بازطراحی نمای اول |
| C4 | Navigation باید حول جریان کسب‌وکار (داده/شبکه → برنامه قطار → تقاضا و بازارگاه → تشکیل قطار → تحلیل ظرفیت → زمان‌بندی → ظرفیت مسیر/شبکه → سناریو → گلوگاه → نقشه → گزارش) سازمان یابد، نه صرفاً حول توالی نمادهای ریاضی C_b→C_s→C_r→C_n | Prompt 29، §۱۳ | ناوبری فعلی خطی و بر اساس توالی فرمول‌هاست (۱۳ نما، فهرست تخت) | برای پیاده‌سازی — بازطراحی IA به گروه‌های موضوعی با همان صفحات فعلی به‌عنوان زیرمجموعهٔ «تحلیل ظرفیت» |
| C5 | Batch باید به‌وضوح «گروه‌بندی عملیاتی قطارهای ازپیش‌تشکیل‌شده» معرفی شود، نه «تشکیل قطار» (نگاه کنید M9) | Prompt 29، §۸ | نمای «بچ‌سازی جهت‌دار» عملاً همین را پیاده‌سازی کرده اما این تمایز را صراحتاً بیان نمی‌کند | برای پیاده‌سازی — افزودن یک جملهٔ توضیحی/برچسب |
| C6 | Bottleneck باید Utilization را از Binding/Effective Bottleneck تفکیک کند (منبعی با ۱۰۰٪ استفاده لزوماً مؤثرترین محل سرمایه‌گذاری نیست) | Prompt 9 (§۴۶)، 11 (§۳۰)، 29 (§۱۰) | نمای سناریو/حساسیت فعلی این تفکیک را دارد (best feasible N + limitingFactor) اما در یک نمای «گلوگاه» مستقل و رتبه‌بندی‌شده نمایش داده نشده | برای پیاده‌سازی — یک بلوک «تحلیل گلوگاه» با ستون‌های Utilization/Binding/Marginal Impact از داده‌های موجود سناریو ساخته می‌شود |

## ۳. مفاهیم/صفحات UI و UX تازه (Prompt 3–4 و تکمیل‌های ۲۸–۳۰)

این بخش هستهٔ اصلی کاری است که این وظیفه باید پیاده کند.

| # | مفهوم UI | منبع | تصمیم |
|---|---|---|---|
| U1 | سه سؤال دائمی محصول: **Where؟ (نقشه) → Why؟ (Explainability) → What if؟ (Scenario)** به‌عنوان فلسفهٔ راهنمای کل تجربهٔ کاربری | Prompt 3، §۲۰ | برای پیاده‌سازی — به‌عنوان یک نخ راهنما (breadcrumb مفهومی) در هر نمای تحلیلی تکرار می‌شود |
| U2 | «تعریف مسئله» قبل از محاسبه (نگاه کنید M10) | Prompt 29 | برای پیاده‌سازی |
| U3 | KPI چهارگانهٔ ظرفیت (Physical/Operational/Route/Network) + سه‌گانهٔ تقاضا (Market/Transportable/Allocated) در یک نمای کلی/داشبورد | Prompt 3، §۴ | برای پیاده‌سازی — نمای کلی موتور بازطراحی می‌شود تا این هفت عدد را هم‌زمان و با برچسب فارسی ساده نشان دهد |
| U4 | **پنل Explainability ثابت**: «چرا ظرفیت این مسیر X است؟» با فهرست محدودیت‌های مؤثر و اثر عددی هرکدام (رتبه‌بندی‌شده، نه تخت) | Prompt 3، §۶ و Prompt 7، §۲۴ | برای پیاده‌سازی — درخت توضیح‌پذیر موجود در نمای ظرفیت مسیر بازآرایی می‌شود؛ ر.ک. M3 |
| U5 | **Capacity Waterfall**: نمودار پلکانی Physical → −Rules → −Constraints → −Fleet → −Demand → −Conflicts → Available | Prompt 3، §۱۳ | برای پیاده‌سازی — یک نمودار جدید در نمای ظرفیت مسیر/شبکه، با مقادیر واقعاً محاسبه‌شده (نه اعداد نمونهٔ متن) |
| U6 | **Time-Space Diagram** تعاملی: محور افقی = مسیر/ایستگاه، محور عمودی = زمان؛ خطوط مورب = مسیر هر قطار؛ نشانگر تعارض و انتظار | Prompt 3، §۷ و Prompt 29، §۴ (تکرار شده، بارها تأکید شده) | **برای پیاده‌سازی — بالاترین اولویت افزودنی**؛ از داده‌های همین ماکاپ (batch timeline، headway، switch time، conflict intervals که در نمای «بچ‌سازی» و «تشخیص تعارض» از قبل محاسبه می‌شوند) قابل ساخت است بدون نیاز به دادهٔ جدید |
| U7 | **Capacity Inspector**: کلیک روی هر عدد ظرفیت → درخت اشتقاق + Binding Constraint + Confidence + Run ID | Prompt 3، §۲۱ | برای پیاده‌سازی جزئی — نسخهٔ ساده‌شده (بدون Run ID/نسخهٔ داده که نیازمند بک‌اند واقعی است) به‌صورت یک تولتیپ/پنل روی هر عدد کلیدی |
| U8 | سیستم رنگ معنایی: سبز=Feasible، زرد=Warning/نزدیک ظرفیت، قرمز=Conflict/Binding، آبی=Information؛ همراه با آیکون/برچسب متنی برای دسترس‌پذیری (نه فقط رنگ) | Prompt 3، §۲۳ | برای پیاده‌سازی |
| U9 | استراتژی واکنش‌گرا: **دسکتاپ اولویت اصلی** (نقشه/Time-Space/جداول به فضای زیاد نیاز دارند)؛ موبایل فقط برای پایش/KPI/تأیید، نه ویرایشگر کامل | Prompt 3، §۲۴ | برای پیاده‌سازی — طراحی ریسپانسیو با این محدودیت آگاهانه (نه «موبایل‌فرست») |
| U10 | وضعیت‌های خالی/خطا با پیام عملی (نه پیام فنی خام) + دکمهٔ اقدام | Prompt 3، §۱۹–۲۰ | برای پیاده‌سازی — نمای نقشه از قبل خطای اتصال دارد؛ الگو به بقیهٔ نماها (مثلاً حالت «هنوز پارامتری وارد نشده») تعمیم می‌یابد |
| U11 | Scenario Builder به‌شکل «آزمایشگاه»: سه ستون Baseline / تغییرات / نتیجه، با جدول مقایسهٔ چندسناریویی | Prompt 3، §۱۲ و ۱۷؛ Prompt 29، §۱۱ | برای پیاده‌سازی — نمای سناریو/حساسیت فعلی (جاروب تک‌پارامتری) به سه‌ستونی + جدول مقایسه گسترش می‌یابد |
| U12 | «قبول/رد تقاضا» با شکست دلیل کسری (نه فقط بله/خیر) | Prompt 3، §۱۱ | برای پیاده‌سازی جزئی — در نمای ظرفیت مسیر، مقایسهٔ تقاضا/ظرفیت موجود با شکست علت کسری (از محدودیت‌های موجود buffer/station/fleet) نمایش داده می‌شود |
| U13 | Run History / نسخهٔ داده و مدل در سربرگ هر نتیجه، برای ردیابی | Prompt 3، §۱۷؛ Prompt 7، §۲۵ | موکول‌شده — نیازمند بک‌اند با ذخیرهٔ Runهای واقعی؛ در یک ماکاپ استاتیک بدون سرور معنا ندارد. به‌جای آن فقط برچسب «نسخهٔ سند مرجع v1.0» که از قبل در نوار منبع هر صفحه هست حفظ می‌شود |
| U14 | Data Quality indicator (٪ صحت، هشدار، خطا) | Prompt 3، §۱۶ | موکول‌شده — این ماکاپ یک بار پوشش دادهٔ SRC-02/SRC-03 را در سند source/coverage.fa.md مستند کرده؛ ساختن یک شمارندهٔ «کیفیت داده» پویا بدون قوانین اعتبارسنجی واقعی صرفاً یک عدد جعلی تولید می‌کند |
| U15 | ناوبری گروه‌بندی‌شده به‌جای فهرست تخت ۱۳موردی (نگاه کنید C4) | Prompt 29، §۱۳ | برای پیاده‌سازی |
| U16 | ترمینولوژی فارسیِ ساده در سطح اصلی UI؛ نماد ریاضی (C_b، C_s، …) فقط در پنل «جزئیات فنی/روش‌شناسی» | Prompt 3، §۱۹ | برای پیاده‌سازی — این دقیقاً همان هدف «راهنمای گذار بین لایه‌های ظرفیت با زبان ساده» است که در Firstmate spec خواسته شده |
| U17 | دو محصول/دو نمای مجزا برای «کاربر عملیاتی» (شبکه/قطار/زمان‌بندی) و «کاربر تصمیم‌گیر» (ظرفیت/سناریو/گلوگاه/سرمایه‌گذاری) | Prompt 29، §۱۴ | موکول‌شده — دوشقه‌کردن کل ماکاپ به دو حالت مجزا در این مرحله بیش از حد گستاخانه است و مزیت زیادی برای یک ماکاپ نمایشی ندارد؛ همان تفکیک با گروه‌بندی ناوبری (U15) تا حد زیادی پوشش داده می‌شود |
| U18 | نمای «برنامهٔ پایهٔ شبکه» (Baseline Timetable) با ردیف‌های Train/TrainRun واقعی | Prompt 29، §۳ | موکول‌شده — همان دلیل M11 (بدون دادهٔ واقعی) |
| U19 | صفحهٔ «تشکیل قطار» تعاملی (Train Formation wizard) با انتخاب واگن/لکوموتیو | Prompt 3، §۹–۱۰ | موکول‌شده — نیازمند دادهٔ ناوگان/واگن واقعی که در SRC-02/SRC-03 وجود ندارد؛ ساختن آن با اعداد صرفاً نمایشی چیزی به مدل محاسباتی موجود اضافه نمی‌کند و ریسک بزرگ‌شدن بی‌مورد دامنهٔ کار را دارد |

## ۴. خارج از دامنهٔ این ماکاپ (نیازمند بک‌اند/داده واقعی/Solver)

این‌ها به‌صراحت در گفت‌وگو مطرح شده‌اند اما ساختن‌شان در HTML/CSS/JS خام و بدون سرور، بدون دادهٔ واقعی پشتیبان، یا خلاف اصل «داده نمایشی را داده واقعی جا نزنیم» است:

- کل سند معماری نرم‌افزار (Prompt 11): میکروسرویس‌ها، صف کار، Solver Worker، پایگاه‌دادهٔ مکانی/رابطه‌ای جدا، RBAC، Deployment/Kubernetes.
- مدل کامل MILP/CP-SAT با متغیرهای دودویی ترتیب‌دهی (Prompt 2 و 6) — خودِ سند مرجع هم این را «گام فنی بعدی» می‌داند؛ ماکاپ فعلی عمداً شبه‌کد سند (جاروب N، LP دو‑متغیره) را پیاده می‌کند، نه یک Solver عمومی.
- Baseline Schedule واقعی، Train/TrainRun/StationCall با فیلدهای Access (M11، M12، U18) — فایل منبع در مخزن ما موجود نیست.
- Capacity Profile چندکالایی/چندزمانی (M7) — دادهٔ کالا در SRC-02/SRC-03 وجود ندارد.
- Data Quality score پویا (U14) و Run History با Run ID واقعی (U13) — نیازمند بک‌اند با اجراهای واقعی.
- Train Formation wizard با انتخاب واگن/لکوموتیو واقعی (U19) — دادهٔ ناوگان واقعی نداریم.
- Capacity Transfer بین Routeهای رقیب با سیاست تخصیص (M5) — فراتر از LP دو‑مسیرهٔ فعلی.
- دو محصول/نمای کاملاً مجزا برای دو پرسونای کاربر (U17).

## ۵. جمع‌بندی برای فاز اجرا

اولویت اجرا (به ترتیب ارزش/امکان‌پذیری):
1. بازطراحی IA/ناوبری به گروه‌های موضوعی + گام «تعریف مسئله» قبل از لایه‌های ظرفیت (M10، C3، C4، U2، U15).
2. افزودن Time-Space Diagram تعاملی (U6) — از داده‌های batch/conflict موجود.
3. پنل Explainability با تفکیک Primary/Secondary + Capacity Waterfall (M3، U4، U5).
4. سه‌گانهٔ تقاضا (Market/Transportable/Allocated) و ترمینولوژی ساده در سطح اصلی UI با نماد ریاضی در پنل فنی (M6، U16).
5. تفکیک زبانی Train Formation در برابر Operational Batch (M8، M9، C5).
6. نمای «تحلیل گلوگاه» رتبه‌بندی‌شده (C6) و Capacity Inspector ساده (U7).
7. سیستم رنگ معنایی + وضعیت‌های خالی/خطای عملی + استراتژی ریسپانسیو دسکتاپ‌محور (U8، U9، U10).
8. Scenario Builder سه‌ستونی + جدول مقایسه (U11) و شکست علت کسری تقاضا (U12).

هیچ‌کدام از این موارد نیازمند دادهٔ جدید یا تغییر منابع SRC-02/SRC-03/OpenRailwayMap نیست؛ همگی از خروجی‌های موجود `engine/model.js` و `engine/network.js` (یا بسط جزئی همان توابع) قابل استخراج‌اند.

## ۶. وضعیت واقعی پس از اجرا (این وظیفه)

بندهای ۱ تا ۷ اولویت بالا **پیاده‌سازی شدند** در ماکاپ (`capacity-engine-mockup/`):

- **پیاده‌سازی‌شده:** M3، M4، M6، M8، M9، M10، C1 (فقط عبارت‌بندی)، C3، C4، C5، C6، U1، U2، U3، U4، U5، U6، U7 (نسخهٔ ساده‌شده، بدون Run ID)، U8 و U10 (سیستم رنگ/وضعیت خالی از قبل موجود بود؛ به صفحات جدید تعمیم داده شد)، U9 (رویکرد دسکتاپ‌محور از قبل موجود بود؛ یک باگ مسدودکنندهٔ منوی موبایل در RTL که حین بازبینی مرورگر کشف شد اصلاح شد — نگاه کنید به یادداشت زیر)، U15، U16.
- **پیاده‌سازی جزئی:** U12 — سه‌گانهٔ تقاضا (D_market/D_transportable/D_allocated) با شکاف/مازاد نمایش داده می‌شود، اما شکست علت کسری به‌ازای هر قید (مثل «−۲۰۰ تن به‌دلیل ایستگاه») اضافه نشد.
- **موکول‌شده (این نوبت):** M1 (برچسب‌گذاری صریح Generation/Estimation/Optimization در نمای کلی)، M2 (کدهای CASE-001..012 روی قواعد اعتبارسنجی موجود)، M14 (نام‌گذاری صریح اصل «No Verified Mapping» — رفتار از قبل رعایت می‌شود، فقط برچسب صریح اضافه نشد)، U11 (بازطراحی کامل Scenario Builder به سه‌ستونی Baseline/تغییرات/نتیجه — نمای فعلی سوئیپ تک‌پارامتری + پنل مداخله را حفظ کرد). دلیل مشترک: محدودیت زمانی این نوبت کاری؛ هیچ‌کدام نیازمند داده یا تصمیم جدید نیستند و می‌توانند در نوبت بعد بدون تغییر معماری اضافه شوند.
- **یافتهٔ جانبی حین بازبینی مرورگر:** `css/base.css` (کد از قبل موجود، نه افزودهٔ این نوبت) یک باگ specificity داشت که باعث می‌شد کشوی ناوبری موبایل هرگز روی این صفحهٔ همیشه-RTL باز نشود (قاعدهٔ `html[dir="rtl"] .app-nav` به‌دلیل specificity بالاتر بر `.app-nav.open` غالب می‌شد). در این نوبت اصلاح شد؛ همان الگوی باگ در پنل جدید Capacity Inspector (که خودِ این نوبت اضافه کرد) نیز پیش از انتشار پیدا و اصلاح شد.

تأیید در مرورگر واقعی: هر ۱۵ نما (۱۳ نمای قبلی + دو نمای تازه: نمودار زمان-مکان، تحلیل گلوگاه) بدون خطای Console، در دسکتاپ (1440px) و موبایل (390px) بازبینی شدند؛ منوی موبایل، پنل Capacity Inspector، نمودار زمان-مکان (شامل تعویض حالت برنامهٔ نادرست) و نقشهٔ زندهٔ OpenRailwayMap به‌صورت مستقیم تعامل و تأیید شدند.