ifnex/CLIENT_DELIVERY.md

IFNEX — چک‌لیست تحویل به مشتری

وضعیت: آماده برای UAT نهایی کارفرما (فاز ۳.۱۱) فاز جاری: فاز ۳.۱۱ — UAT → قدم بعدی: تأیید کارفرما و انتشار رسمی تاریخ آخرین به‌روزرسانی: ۲۰۲۶-۱۱-۰۱ مخزن: git.vernahost.ir/gitmodir110/ifnex

⚠️ این فایل فقط برای مدیریت تعهدات، تست و تحویل نسخهٔ فعلی مشتری است و جایگزین AGENT.md یا IFNEX_Roadmap.md نیست.

---

راهنمای وضعیت‌ها

نشان	معنی
✅	تکمیل‌شده
🟡	پیاده‌سازی‌شده — نیازمند تأیید نهایی
⏳	در انتظار
🔴	مسدود
❌	پیاده‌سازی‌نشده

---

۱. فرانت‌اند و صفحهٔ اصلی

۱.۱ هدایت دکمهٔ ردیابی مرسوله

الزام مشتری: در بخش Hero صفحهٔ اصلی وردپرس، دکمهٔ «ردیابی مرسوله» کاربر را به صفحهٔ اختصاصی Tracking هدایت کند.

مورد	مقدار
وضعیت	🟡 پیاده‌سازی‌شده — نیازمند تأیید نهایی
فایل‌ها	03_WordPress/wp-content/themes/ifnex/ 03_WordPress/wp-content/plugins/ifnex-bridge/

تست پذیرش:

• کلیک روی دکمهٔ CTA
• ریدایرکت صحیح انجام می‌شود
• URL مقصد صحیح است
• صفحهٔ Tracking درست نمایش داده می‌شود
• رفتار در حالت Login و Guest بررسی شد

---

۱.۲ فرم ثبت سفارش چندمرحله‌ای

الزام مشتری: پس از تکمیل مرحلهٔ اول، مرحلهٔ دوم بدون خطا Load شود.

مورد	مقدار
وضعیت	🟡 پیاده‌سازی‌شده — نیازمند تأیید نهایی
باگ تاریخی	بسته‌نبودن یک div در فایل shortcodes.php
فایل‌ها	includes/shortcodes.php assets/js/ifnex-order-form.js

تست پذیرش:

• حرکت رو به جلو بین مراحل
• حرکت رو به عقب بین مراحل
• اعتبارسنجی فرم در هر مرحله
• حفظ اطلاعات مراحل قبلی
• Console مرورگر بدون Error
• رفتار Export و Import بررسی شد

---

۲. داشبورد مشتری و وضعیت مالی

۲.۱ مانده حساب مشتری

الزام مشتری: در داشبورد مشتری، علاوه بر موجودی کیف پول و سفارش‌ها، مانده حساب نیز نمایش داده شود.

فرمول مورد انتظار:

Account Balance = Wallet Balance − Outstanding Approved Obligations

مورد	مقدار
وضعیت	🟡 پیاده‌سازی‌شده — نیازمند تأیید نهایی

تست پذیرش:

• کیف پول مثبت
• مشتری بدون بدهی
• مشتری دارای بدهی
• مشتری با چند سفارش تأییدشده ولی پرداخت‌نشده
• نمایش صحیح ارز
• بدهی چندارزی به مبلغ ریالی اشتباه تبدیل نمی‌شود

---

۳. تأیید سفارش پیش از پرداخت

الزام اصلی: مشتری بلافاصله پس از ثبت سفارش نباید وارد درگاه پرداخت شود.

۳.۱ فلوی عمومی

Create Order
  → Pending Approval
  → Staff Review
  → Approved
  → Documents / Commitment Verification
  → Payment Enabled
  → Wallet OR Online Payment
  → Paid
  → Processed

مورد	مقدار
وضعیت	🟡 پیاده‌سازی‌شده — نیازمند تأیید End-to-End

۳.۲ سفارش Export

Create Export Order
  → Pending Approval
  → Staff Approval
  → Documents Available
  → Customer Downloads Documents
  → Customer Signs / Fingerprints
  → Customer Uploads Signed Documents
  → Staff Verification
  → Payment Enabled
  → Wallet / Online Payment
  → Paid
  → Shipment Processing

اسناد مرتبط: AWB، Invoice، Label، فرم‌های تعهدنامه و سایر اسناد الزامی.

مورد	مقدار
وضعیت	✅ تکمیل — تست End-to-End تأیید شد

نکات پیاده‌سازی (۲۰۲۶-۱۰-۰۳):

• چرخهٔ تعهدنامه به‌صورت کامل تست شد: دانلود قالب توسط مشتری (از طریق پروکسی وردپرس با توکن)، آپلود فایل امضاشده، تأیید یا رد توسط ادمین در Filament به‌همراه اعلان دیتابیسی، و نمایش وضعیت (تأییدشده / ردشده + دلیل رد) در پورتال مشتری.
• دانلود امن فایل‌ها در پنل ادمین از طریق روت‌های admin.commitment-forms.* و از دیسک secure انجام می‌شود.

نکات پیاده‌سازی (۲۰۲۶-۱۰-۰۴):

• فلوی کامل سفارش (ثبت ← تأیید ← آپلود تعهدنامه ← تأیید تعهدنامه ← پرداخت کیف پول یا درگاه) به‌صورت End-to-End تست و تأیید شد.

۳.۳ سفارش Import

Create Import Order
  → Pending Approval
  → Staff Review
  → Required Documents
  → Customer Verification / Upload
  → Staff Verification
  → Payment Enabled
  → Wallet / Online Payment
  → Paid
  → Shipment Processing

مورد	مقدار
وضعیت	🟡 پیاده‌سازی‌شده — نیازمند تأیید نهایی

---

۴. چک‌لیست کارمند

الزام مشتری: برای هر سفارش یک چک‌لیست عملیاتی وجود داشته باشد.

فیلدهای اجباری هر آیتم:

فیلد
عنوان آیتم
وضعیت
Required / Optional
کارمند تکمیل‌کننده
تاریخ و ساعت تکمیل
یادداشت
پیوست (در صورت نیاز)

الزامات مدیر:

• مشاهدهٔ تمام مراحل
• مشاهدهٔ کارمند انجام‌دهنده
• مشاهدهٔ تاریخ و ساعت
• مشاهدهٔ موارد ناقص
• امکان گزارش‌گیری

مورد	مقدار
وضعیت	✅ تکمیل — نمونه‌سازی خودکار پس از تأیید

نکات پیاده‌سازی (۲۰۲۶-۱۰-۰۴):

• چک‌لیست پس از تأیید سفارش (در ShipmentReviewService::approve) از قالب‌های فعال (ShipmentChecklistTemplate) نمونه‌سازی می‌شود.
• مدیریت کامل در ChecklistsRelationManager روی ShipmentResource و ShipmentChecklistResource انجام می‌شود.
• اکشن‌های تکمیل تکی و گروهی به‌همراه فیلدهای completed_by و completed_at پیاده‌سازی شدند.

---

۵. تاریخچه و تایم‌لاین مرسوله

الزام مشتری: مدیر بتواند تاریخچهٔ کامل هر مرسوله را از ابتدا تا انتها مشاهده کند.

هر تغییر وضعیت باید شامل موارد زیر باشد:

• وضعیت قبلی
• وضعیت جدید
• کاربر / کارمند
• تاریخ
• ساعت
• یادداشت

مورد	مقدار
وضعیت	🟡 پیاده‌سازی‌شده — نیازمند تأیید نهایی

---

۶. اسناد PDF

الزام مشتری: اسناد AWB، Invoice، Label، فاکتور واردات و تعهدنامه‌ها تولید شوند و طراحی آن‌ها تا حد امکان مطابق نمونه‌های اکسل و اسناد کارفرما باشد.

توجه: تطبیق ۱۰۰٪ پیکسلی به دلیل تفاوت موتور PDF با اکسل ممکن نیست. هدف، نزدیک‌ترین تطبیق عملی و قابل چاپ است.

۶.۱ بازطراحی انجام‌شده (۲۰۲۶-۱۰-۰۴)

سند	طراحی
AWB	A4 افقی، پالت navy + amber، چیدمان جدولی، بارکد در هدر، لوگوی IFNEX، گرید ۴×۱
Invoice	A4 عمودی، طراحی هم‌سبک AWB، فیلدهای خالی با @if مخفی، جدول با راه‌راه Zebra
Import Invoice	A4 عمودی، بر اساس شیت ENG Invoice
Label	A5 افقی، بدون برند (white-label)، تک‌رنگ، بارکد بزرگ، جدول وزن و ابعاد

همهٔ اسناد با dompdf و چیدمان جدولی (نه flexbox) تولید می‌شوند تا سازگاری کامل و بدون overflow تضمین شود.

۶.۲ وضعیت تأیید PDF

مورد	وضعیت
AWB	✅ بازطراحی شد
Export Invoice	✅ بازطراحی شد
Import Invoice	✅ بازطراحی شد — نیازمند تأیید نهایی مشتری
Label	✅ بازطراحی شد
بارکد	✅ Code-128 قابل اسکن
چیدمان	✅ جدولی، بدون overflow
تایپوگرافی	✅ DejaVu Sans / Vazirmatn
اندازهٔ صفحه	✅ A4 افقی (AWB) / A4 عمودی (Invoice) / A5 افقی (Label)
خروجی چاپ	⏳ نیازمند تست چاپ فیزیکی

وضعیت کلی بخش	مقدار
نتیجه	🟡 پیاده‌سازی‌شده — در انتظار تأیید نهایی مشتری

---

۷. اطلاعات مالی مشتری (کارمند / مدیر)

الزام مشتری: کارمند یا مدیر بتواند با انتخاب یا جستجوی مشتری، اطلاعات مالی کامل او را مشاهده کند.

اطلاعات مورد نیاز:

• موجودی فعلی
• مطالبات / بدهی‌ها
• ارز
• تراکنش‌های اخیر
• سفارش‌های اخیر
• شمارهٔ مرجع سفارش
• مبلغ
• وضعیت پرداخت
• تاریخ‌ها
• یادداشت‌ها

مورد	مقدار
وضعیت	✅ تکمیل — صفحهٔ نمای کلی مالی مشتری ساخته شد

نکات پیاده‌سازی (۲۰۲۶-۱۰-۰۴):

• صفحهٔ «وضعیت مالی مشتری» در App\Filament\Pages\CustomerFinancialOverview ساخته شد.
• مدیر یا کارمند با جستجوی مشتری موارد زیر را می‌بیند:
  • ۴ کارت KPI: موجودی کیف پول، بدهی فعلی، کل پرداختی، مانده حساب
  • جدول بدهی‌های چندارزی به تفکیک ارز (EUR / USD / AED / CNY)
  • ۵ سفارش اخیر و ۵ تراکنش اخیر
  • دکمه‌های اقدام: اعتبار جدید، سفارش‌ها، وضعیت مالی
• طراحی با گرید ۱۲ ستونی و CSS اختصاصی IFNEX انجام شده است.

---

۸. اعتبار مشتری (چندارزی)

الزام مشتری: فقط مدیر کل بتواند برای مشتریِ شناخته‌شده اعتبار ایجاد یا افزایش دهد.

۸.۱ قاعدهٔ اصلی

اگر مشتری مثلاً ۵۰ EUR بدهکار باشد، بدهی باید به همان ارز ثبت شود و نباید به مبلغ ریالی روز تبدیل و جایگزین شود.

۸.۲ اطلاعات لازم هنگام تسویهٔ ریالی

فیلد
مبلغ اصلی
ارز اصلی
ارز تسویه
نرخ تبدیل
تاریخ نرخ
مبلغ تسویه
دلیل / مرجع

مورد	مقدار
وضعیت	✅ تکمیل — سیستم اعتبار چندارزی کامل شد

نکات پیاده‌سازی (۲۰۲۶-۱۰-۰۴):

• CustomerCreditService با متدهای grantCredit()، settle() و getCustomerDebtsByCurrency()
• جدول‌های customer_credits و credit_settlements — بدهی به همان ارز ثبت و تسویه با نرخ روز
• CustomerCreditResource با فرم ایجاد و اکشن تسویه (exchange_rate، rate_date، from_wallet)
• CreditsRelationManager روی UserResource برای مشاهدهٔ درجا
• نمایش بدهی‌های ارزی در پورتال مشتری (تب کیف پول و پروفایل در وردپرس)
• ویجت داشبورد «بدهی‌های ارزی تسویه‌نشده» به‌همراه badge روی منو
• اصلاح race condition در settle() با بررسی مجدد مانده پس از lockForUpdate()
• Policy: فقط super_admin مجاز به اعطای اعتبار است

---

۹. ایمپورت گروهی وضعیت ترکینگ

الزام مشتری: امکان Import گروهی آخرین وضعیت Trackingها در پنل مدیریت.

مورد	مقدار
ورودی	فایل CSV یا فرمت Import تأییدشده
وضعیت	🟡 پیاده‌سازی‌شده — نیازمند تأیید نهایی

خروجی مورد انتظار:

• یافتن مرسوله
• اعتبارسنجی شمارهٔ ترکینگ
• به‌روزرسانی وضعیت
• ثبت تاریخچه
• ثبت نتیجهٔ Import
• گزارش ردیف‌های ناموفق

---

۱۰. ویرایش مدیریتی و Audit Log

الزام مشتری: مدیر بتواند تقریباً همهٔ اطلاعات عملیاتی لازم را ویرایش کند.

قاعدهٔ مهم: تغییرات مدیریتی باید قابل Audit باشند.

اطلاعات Audit:

• کاربر
• نوع عملیات
• مدل
• رکورد
• مقدار قبلی
• مقدار جدید
• تاریخ
• ساعت
• IP (در صورت کاربرد)

مورد	مقدار
وضعیت	🟡 پیاده‌سازی‌شده — نیازمند بررسی امنیت و مجوز دسترسی

---

۱۱. یکپارچه‌سازی پیامک

مورد	مقدار
سرویس‌دهنده	Kavenegar
وضعیت	🟡 پیاده‌سازی‌شده — نیازمند پیکربندی Production و تأیید End-to-End

موارد استفاده:

• تأیید موبایل
• تأیید ثبت‌نام
• ثبت سفارش
• تأیید سفارش
• رد سفارش
• پرداخت موفق
• تغییر وضعیت ترکینگ
• اعلان‌های مهم سیستم

---

۱۲. سخت‌سازی Production

۱۲.۱ امنیت

مورد	وضعیت
حذف اسکریپت‌های دیباگ (opcache_reset / header / cache-buster)	✅ ۲۰۲۶-۱۰-۳۱ — از ۵ فایل پلاگین حذف شد؛ cache-buster با filemtime جایگزین شد
چرخش کلیدهای افشاشده	🔑 در چک‌لیست استقرار (بخش ۴.۴ DEPLOYMENT_HANDOFF.md) — قبل از دیپلوی چرخش شود
بررسی نحوهٔ نگهداری Bridge API Key	✅ ۲۰۲۶-۱۰-۳۱ — wp-config.php از گیت حذف شد (فقط sample در مخزن)؛ راهنمای چرخش در .env.example
بررسی مجوز روت‌های Staff	✅ StaffApiMiddleware روی همهٔ /staff/*
بررسی عملیات مختص مدیر	✅ Policy روی CustomerCredit و Shipment
اعتبارسنجی آپلود فایل	✅ ۲۰۲۶-۱۰-۳۱ — mimetypes (بررسی محتوا) + mimes + max:5120 + دیسک secure + چک مالکیت
بررسی مالکیت و مجوز اسناد	✅ ShipmentPolicy و CustomerCreditPolicy
امنیت Callback پرداخت	✅ OrderPaymentService با محافظ Mock در Production
غیرفعال‌سازی Mock Gateway در Production	✅ ۲۰۲۶-۱۰-۳۱ — گارد سخت: در APP_ENV=production درگاه تستی با RuntimeException مسدود می‌شود
Rate Limiting	✅ ۲۰۲۶-۱۰-۰۴ — ۶ لایه throttle: auth / sms / public / customer / wallet / staff

۱۲.۲ یکپارچگی مالی

مورد	وضعیت
حفاظت از همزمانی کیف پول	✅ lockForUpdate() در CustomerCreditService::settle()
یکتایی پرداخت (Idempotency)	✅ race condition اصلاح شد
منطق مصرف کد تخفیف	✅ ۲۰۲۶-۱۰-۳۱ — DiscountCodeService + جدول discount_code_usages: قفل رقابتی، مصرف یک‌بار، رکورد Audit، گارد ظرفیت در قیمت‌گذاری، ۴۲۲ در شکست مصرف. باگ P0 تاریخی: متد consumeDiscountCode() وجود نداشت و ثبت سفارش را می‌شکست — برطرف شد
دقت مبلغ و ارز	✅ cast با decimal:2
یکپارچگی بدهی چندارزی	✅ بدهی به همان ارز ثبت می‌شود، نه معادل ریالی

✅ انجام شد (۲۰۲۶-۱۰-۰۳): تغییر نرخ ارز فقط از منوی «نرخ ارز» (تاریخچه + گردش تأیید + به‌روزرسانی از API) انجام می‌شود. فیلدهای مستقیم نرخ در «تنظیمات سیستم» حذف و به نمایش فقط‌خواندنی تبدیل شدند.

۱۲.۳ اپلیکیشن

مورد	وضعیت
بازبینی فلوی قدیمی سفارش	✅ ۲۰۲۶-۱۰-۳۱ — باگ P0 کد تخفیف کشف و برطرف شد؛ ۳۳ تست پاس (۱۰۱ assertion) شامل ثبت سفارش با تخفیف
مدیریت خطاها	✅ ۲۰۲۶-۱۰-۳۱ — شکست مصرف کد تخفیف → ۴۲۲ با پیام واضح؛ Mock در Production → خطای صریح؛ مسیرهای حساس Log::error/critical
لاگ Production	✅ ۲۰۲۶-۱۰-۳۱ — راهنمای LOG_STACK=daily + LOG_LEVEL=warning در .env.example و بخش ۴.۴ سند استقرار
پیکربندی Cache / OPcache	✅ ۲۰۲۶-۱۰-۳۱ — راهنمای config:cache / route:cache / view:cache در سند استقرار؛ هک OPcache حذف شد
نسخه‌بندی Assetها	✅ ۲۰۲۶-۱۰-۳۱ — ifnex_asset_version() مبتنی بر filemtime + ثابت IFNEX_BRIDGE_VERSION (۲.۱.۰)

---

۱۳. تست پذیرش End-to-End

۱۳.۱ مشتری

• ثبت‌نام
• تأیید موبایل
• ورود
• ثبت سفارش Export
• ثبت سفارش Import
• مشاهدهٔ سفارش
• انتظار برای تأیید
• دریافت اسناد
• دانلود اسناد
• آپلود اسناد امضاشده
• دریافت تأیید
• پرداخت با کیف پول
• پرداخت آنلاین
• مشاهدهٔ موجودی
• مشاهدهٔ تراکنش‌ها
• مشاهدهٔ ترکینگ
• دریافت اعلان‌ها

۱۳.۲ کارمند

• مشاهدهٔ سفارش‌ها
• تأیید سفارش
• رد سفارش
• آپلود تعهدنامه
• بررسی اسناد مشتری
• تکمیل چک‌لیست
• به‌روزرسانی مرسوله
• ایمپورت ترکینگ
• مشاهدهٔ وضعیت مالی مشتری
• مشاهدهٔ سفارش‌های مشتری
• بازبینی Audit Log

۱۳.۳ مدیر / مدیر کل

• بازبینی مالی مشتری
• اعطای اعتبار
• ویرایش اعتبار
• بازبینی Audit
• مشاهدهٔ تایم‌لاین مرسوله
• ویرایش داده‌های عملیاتی
• بازبینی فعالیت کارمندان

---

۱۴. دروازهٔ نهایی تحویل

پیش از انتشار در Production:

• همهٔ قابلیت‌های الزامی پیاده‌سازی شده‌اند
• باگ‌های بحرانی برطرف شده‌اند
• بازبینی امنیتی انجام شده
• فلوی پرداخت تست شده
• فلوی کیف پول تست شده
• فلوی Export تست شده
• فلوی Import تست شده
• PDFها تأیید شده‌اند
• پیامک تست شده
• ایمپورت ترکینگ تست شده
• بکاپ بررسی شده
• محیط Production بررسی شده
• تست پذیرش کارفرما (UAT) انجام شده

---

۱۵. خلاصهٔ وضعیت تحویل

وضعیت فعلی: آماده برای دیپلوی (فاز ۳.۸، ۳.۸.۱ و ۳.۹ تکمیل شد)

آخرین کامیت بازبینی‌شده: ۲۰۲۶-۱۱-۰۱ — فاز ۳.۹ (دفترچه آدرس: مدل + مایگریشن، CRUD API با Sanctum، اتصال به ثبت سفارش، dropdown آدرس ذخیره‌شده + چک‌باکس ذخیره در فرم سفارش، تب دفترچه آدرس در پنل کاربری، ۴ پروکسی AJAX، ۱۸ تست جدید).

۱۵.۱ تکمیل‌شده در فاز ۳.۶ (۲۰۲۶-۱۰-۰۴)

• فلوی پذیرش End-to-End (کیف پول + درگاه پس از تأیید تعهدنامه)
• بازطراحی داشبورد و صفحهٔ Login (پنل Filament)
• بازطراحی PDFهای AWB، Invoice و Label (dompdf، چیدمان جدولی، navy + amber)
• صفحهٔ وضعیت مالی مشتری در پنل ادمین
• سیستم اعتبار چندارزی (درخواست ۹) — تکمیل End-to-End
• ویجت بدهی‌های ارزی تسویه‌نشده + badge ناوبری
• اصلاح race condition در تسویهٔ اعتبار
• CreditsRelationManager روی UserResource
• Rate Limiting روی همهٔ endpointهای API (۶ لایه)
• چک‌لیست خودکار کارمند پس از تأیید سفارش (درخواست ۵)
• نمایش بدهی ارزی در پورتال مشتری وردپرس
• استایل‌دهی صفحهٔ پروفایل مشتری در وردپرس
• پاک‌سازی کد (حذف فایل‌های تستی، تأیید تمیزی کد)

۱۵.۲ تکمیل‌شده در فاز ۳.۷ (۲۰۲۶-۱۰-۳۰)

• سیستم ۴-رُبعی نرخ‌ها (Export/Import × Doc/Parcel) با ایمپورت از اکسل
• معماری IRR-only — ارز مبنا = ریال ایران، حذف جفت‌ارز و تبدیل در زمان ایمپورت
• ایمپورت فایل اصلی مشتری + قالب جدید IFNEX_Rate_Template.xlsx
• حذف تمام «تومان» و «درهم» از نمایش قیمت‌های داخلی در همه UIها
• فاکتورهای دستی مدیر — صدور، پرداخت از کیف پول، اعلان خودکار
• تب «فاکتورهای دستی» در پورتال وردپرس (لیست + جزئیات + پرداخت)
• اضافه شدن فاکتورها به وضعیت مالی و داشبورد مشتری
• فرمت هزارگان در فیلدهای عددی فرم فاکتور ادمین
• آپدیت خط قرمزها برای معماری ارزی

۱۵.۳ تکمیل‌شده در فاز ۳.۸ (۲۰۲۶-۱۰-۳۱)

• Favicon حرفه‌ای IFNEX — طراحی هواپیمای کاغذی کهربایی روی پس‌زمینهٔ سرمه‌ای (favicon.ico چندسایزی + favicon.svg وکتور + apple-touch-icon + icon-192/512 + site.webmanifest) + لینک‌ها در head پنل فیلمنت
• صفحهٔ / برندشده — جایگزین welcome پیش‌فرض لاراول (RTL، وزیرمتن، کارت‌های پنل مدیریت / استعلام نرخ / ثبت سفارش)
• جمع‌شدن کارت لاگین فیلمنت — عرض ۴۴۰←۳۸۰px، padding و فاصله‌های فشرده‌تر، موبایل-فرندلی
• SweetAlert2 برای خطاهای فرم سفارش وردپرس — باندل محلی (بدون CDN)، پاپ‌آپ مرکزی برای خطاهای اعتبارسنجی/ثبت/ارتباط با fallback به alert

۱۵.۴ تکمیل‌شده در فاز ۳.۸.۱ — سخت‌سازی Production (۲۰۲۶-۱۰-۳۱)

• باگ P0 کد تخفیف — متد consumeDiscountCode() صدا زده می‌شد ولی وجود نداشت (ثبت سفارش شکسته بود)؛ سرویس DiscountCodeService + جدول discount_code_usages (Audit + Idempotency + قفل رقابتی) پیاده‌سازی شد
• گارد Mock Gateway در Production — پردازش با درگاه تستی در Production مسدود می‌شود
• حذف هک‌های دیباگ از ۵ فایل پلاگین وردپرس (opcache_reset / header / cache-buster)
• نسخه‌بندی سالم assetها — filemtime + ثابت نسخه به‌جای time()
• سخت‌سازی آپلود — بررسی mimetype واقعی فایل
• خروج wp-config.php از گیت (saltها لو‌رفته فرض می‌شوند — چرخش در چک‌لیست استقرار)
• تعمیر ۷ تست شکسته + ۹ تست جدید — ۳۳ تست پاس، ۱۰۱ assertion
• چک‌لیست امنیتی استقرار در DEPLOYMENT_HANDOFF.md (بخش ۴.۴)

۱۵.۵ تکمیل‌شده در فاز ۳.۹ — دفترچه آدرس (۲۰۲۶-۱۱-۰۱)

• مدل + جدول address_book_entries — نقش sender/receiver، فیلدهای عیناً مطابق ستون‌های sender_/receiver_ در shipments، آدرس پیش‌فرض، شمارندهٔ استفاده + آخرین استفاده، سقف ۵۰ رکورد برای هر کاربر
• CRUD API محافظت‌شده با Sanctum — GET/POST/PUT/DELETE /api/v1/addresses + POST /addresses/{id}/default؛ بررسی مالکیت در همهٔ اکشن‌ها؛ فیلتر بر اساس نقش و جستجو؛ جلوگیری از رکورد تکراری (نقش + تلفن + آدرس → بروزرسانی)
• اتصال به ثبت سفارش — چک‌باکس «ذخیره این آدرس» برای هر دو نقش (upsert بدون رکورد تکراری) + ثبت استفاده از آدرس انتخاب‌شده؛ عملیات دفترچه هرگز ثبت سفارش را ناموفق نمی‌کند
• فرم سفارش وردپرس — dropdown «آدرس‌های ذخیره‌شده» بالای هر دو بخش فرستنده/گیرنده (پر شدن یک‌کلیکی تمام فیلدها) + چک‌باکس ذخیره؛ در نبود آدرس ذخیره‌شده کاملاً مخفی است
• تب «دفترچه آدرس» در پنل کاربری — کارت‌های آدرس با فیلتر (همه/فرستنده/گیرنده)، فرم افزودن/ویرایش، حذف با تأیید SweetAlert، تنظیم پیش‌فرض، حالت خالی راهنما، موبایل-فرندلی
• ۴ پروکسی AJAX امن (get/save/delete/set-default) — nonce + sanitize + توکن Sanctum کاربر در سمت لاراول
• ۱۸ تست Feature جدید — مالکیت، سقف، تکراری، پیش‌فرض، فیلترها و رفتار مدل

۱۵.۶ تکمیل‌شده در فاز ۳.۱۰ — استقرار Production (۲۰۲۶-۱۱-۰۱)

• ifnex:preflight — دستور fail-fast برای ممیزی محیط Production پیش از migrate (APP_ENV, APP_DEBUG, APP_KEY, IFNEX_API_KEY, IFNEX_BRIDGE_API_KEY, ZARINPAL_SANDBOX, DB_CONNECTION, CORS, currencies, اکستنشن‌های PHP, دسترسی storage)
• ifnex:import-fx-rates — جایگزین ifnex:update-rates با پشتیبانی از EUR/CNY از FreeCurrencyAPI (به‌علاوه USD/AED از Exir.io)، پرچم --auto-approve برای کرون، Log::critical در شکست HTTP، URL اکسیر از env
• CurrencySeeder — پنج ارز پایه (USD/AED/EUR/CNY/IRR) با نرخ صفر (IRR=1)؛ idempotent — نرخ‌های واقعی را overwrite نمی‌کند
• scripts/deploy.sh — اسکریپت خودکار ۱۳ مرحله‌ای استقرار (composer install → key:generate → preflight → migrate → seed → FX import → cache → chown)؛ fail-fast با set -e
• scripts/cron-exir-rates.sh — wrapper کرون روزانه برای ifnex:import-fx-rates --source=all --auto-approve
• سخت‌سازی .env.example — MySQL پیش‌فرض، EXIR_API_URL/EXIR_API_TIMEOUT، SANCTUM_STATEFUL_DOMAINS، APP_TIMEZONE، LOG_DAILY_DAYS، رفع تکرار CURRENCY_API_KEY
• رفع باگ latent در bootstrap/app.php — حذف use ApiKeyAuth که کلاس وجود نداشت (کی向着 fatal)
• بهبود DatabaseSeeder — حساب super_admin با رمز password در Production ساخته نمی‌شود
• ۲۲ تست Feature جدید (IfnexPreflightTest ۹، IfnexImportFxRatesTest ۹، CurrencySeederTest ۴) — مجموعاً ۷۳ تست / ۱۹۸ assertion

۱۵.۷ تکمیل‌شده در فاز ۳.۱۱ — UAT نهایی (۲۰۲۶-۱۱-۰۱)

• ifnex:smoke-test — دستور E2E خودکار Post-Deploy (اتصال DB، وجود جدول‌ها، ارزها با نرخ غیر صفر، کشورها، نقش‌ها، ادمین، تنظیمات سیستم، دسترسی storage، config/route cache، ۴ endpoint API: /up، /countries، /track/{invalid}، /customer/profile)
• ۹ تست Feature جدید (IfnexSmokeTestTest) — حالت‌های PASS/FAIL با Http::fake شامل تست باگ امنیتی endpoint محافظت‌شده
• سند UAT-3.11.md — چک‌لیست ۴۳ موردی فارسی برای کارفرما، سازمان‌دهی‌شده در ۱۵ بخش، با فرم امضای تحویل
• به‌روزرسانی CLIENT_DELIVERY.md — ثبت فاز ۳.۱۰ و ۳.۱۱

۱۵.۸ باقی‌مانده

• i18n (موکول به زمان دیپلوی)
• تست نهایی UAT کارفرما — سند UAT-3.11.md آماده شد؛ منتظر اجرا توسط کارفرما
• دیپلوی روی سرور Production — فاز ۳.۱۰ با اسکریپت deploy.sh خودکار شد
• سند پیشنهادی سیستم مالی (درخواست ۱۳ کارفرما — موکول به آینده)
• پلاگین SMS (منتظر تحویل پنل SMS مشتری)

باقی‌مانده برای نسخه Pro (آینده)

• ارز مرجع قابل تنظیم (IRR/EUR/USD/AED) — 01_Documents/IFNEX_Pro_Backlog.md
• سیستم لایسنس با Domain Lock + Feature Flags
• بروزرسانی خودکار از گیت

---

نکتهٔ نگهداری: این فایل باید در طول تحویل پروژه به‌روزرسانی شود. این فایل فقط برای وضعیت تحویل مشتری است و نباید به مستندات معماری یا Roadmap محصول تبدیل شود.