You are auditing the Angular frontend repository of the “Rasme Bandegi” project.

IMPORTANT RESPONSE LANGUAGE:
- Perform the audit in the repository.
- Write all generated reports and your final response entirely in Persian.
- Do not modify application source code.
- Do not implement guards, roles, permissions, services, routes, UI changes, or backend code.
- Do not rename endpoints or components.
- Do not invent permissions, roles, APIs, or backend behavior.
- Your task is discovery, classification, and reporting only.

==================================================
هدف اصلی
==================================================

تمام بخش‌ها، صفحات، عملیات، دکمه‌ها، منوها، مسیرها و APIهایی را که باید براساس نقش یا Permission محدود شوند شناسایی کن.

گزارش باید به ما کمک کند که بعداً:

1. تمام Permissionهای واقعی موردنیاز بک‌اند را تعریف کنیم.
2. Permissionهای هر نقش را مشخص کنیم.
3. کنترل دسترسی فرانت و بک‌اند را هماهنگ کنیم.
4. نقاطی را که اکنون فقط با مخفی‌کردن دکمه محافظت شده‌اند پیدا کنیم.
5. مسیرها یا APIهایی را که احتمال دورزدن دسترسی دارند شناسایی کنیم.

منظور از «آیتم قابل دسترسی» هر قابلیتی است که یکی از این کارها را انجام می‌دهد:

- مشاهده اطلاعات غیرعمومی
- ایجاد
- ویرایش
- حذف
- انتشار
- تغییر وضعیت
- تأیید یا رد
- آپلود
- دانلود
- مدیریت ارتباط‌ها
- مدیریت کاربران و نقش‌ها
- مشاهده گزارش‌ها
- مشاهده آمار مدیریتی
- اجرای عملیات دسته‌جمعی
- ورود به یک Route مدیریتی
- مشاهده یا کلیک روی یک دکمه حساس
- فراخوانی API حساس

==================================================
قواعد قطعی
==================================================

- هیچ فایل سورس برنامه را تغییر نده.
- فقط فایل‌های گزارش را در پوشه `docs` ایجاد کن.
- براساس نام صفحه یا دکمه، رفتار بک‌اند را حدس نزن.
- هر ادعا باید به فایل، Component، Route، Service یا Endpoint واقعی ارجاع داشته باشد.
- اگر کنترل بک‌اند قابل تشخیص نیست، بنویس:
  «کنترل بک‌اند از مخزن فرانت قابل تأیید نیست.»
- اگر نقش یا شرطی در کد وجود دارد، متن دقیق شرط را ثبت کن.
- اگر فقط دکمه مخفی شده ولی API همچنان قابل فراخوانی است، آن را ریسک امنیتی ثبت کن.
- اگر یک عملیات در چند صفحه تکرار شده، همه محل‌ها را ثبت کن ولی Permission پیشنهادی را تکراری نساز.
- میان Role، Permission و وضعیت تأییدشدگی کاربر تفاوت قائل شو.
- `IsVerified` یا وضعیت مشابه را Role فرض نکن.
- مهمان، عضو واردشده و عضو تأییدشده را جدا بررسی کن.
- از تغییر معماری، Refactor یا ارائه کد اجرایی خودداری کن.

==================================================
مرحله اول — شناخت معماری دسترسی فعلی
==================================================

ابتدا این موارد را پیدا و گزارش کن:

1. محل ذخیره Token
2. HTTP Interceptor
3. Auth Service
4. Login و Logout
5. بازیابی اطلاعات کاربر
6. مدل User
7. مدل Role
8. مدل Permission، اگر وجود دارد
9. Claims یا اطلاعات داخل JWT
10. Route Guardها
11. شرط‌های نمایش منوها
12. شرط‌های نمایش دکمه‌ها
13. شرط‌های داخل Componentها
14. توابعی مانند:
   - isAdmin
   - isSuperAdmin
   - hasRole
   - hasPermission
   - isAuthenticated
   - isVerified
15. Routeهای مدیریتی بدون Guard
16. APIهای حساس که بدون بررسی نقش از فرانت فراخوانی می‌شوند
17. هر نوع Role ID یا Role Name هاردکدشده
18. هر نوع Permission ID هاردکدشده
19. هر استفاده از localStorage/sessionStorage برای تشخیص نقش
20. تفاوت میان کنترل Route و کنترل UI

نقش‌ها یا نام‌هایی که واقعاً در کد مشاهده می‌شوند را عیناً ثبت کن؛ از جمله موارد احتمالی مانند:

- Super Admin
- Admin
- Indexing
- Relations
- Writer
- Editor
- Public User

اما فقط موارد واقعاً موجود را به‌عنوان وضعیت فعلی اعلام کن.

==================================================
مرحله دوم — ممیزی تمام Routeها
==================================================

تمام Routeهای پروژه را بررسی کن.

برای هر Route ثبت کن:

- مسیر
- عنوان یا کاربرد
- Component
- عمومی یا مدیریتی
- نیاز به Login
- Guard فعلی
- Role یا شرط فعلی
- عملیات قابل انجام در صفحه
- APIهای اصلی صفحه
- حساسیت صفحه
- Permission پیشنهادی
- وضعیت محافظت:
  - مناسب
  - ناقص
  - فقط UI
  - بدون کنترل قابل مشاهده
  - نامشخص

Routeهای Lazy Loaded، Child Routeها و Dialogهایی را که از Routeها باز می‌شوند نیز بررسی کن.

==================================================
مرحله سوم — ممیزی منو، هدر و داشبورد
==================================================

تمام آیتم‌های زیر را پیدا کن:

- منوی اصلی مدیریت
- Sidebar
- منوی موبایل
- هدر
- دکمه ورود به پنل
- میانبرهای داشبورد
- کارت‌های آماری
- منوهای سه‌نقطه
- دکمه‌های داخل جدول
- دکمه‌های شناور
- دکمه‌های داخل Dialog
- Action Bar فرم‌ها

برای هر مورد مشخص کن:

- در کدام فایل قرار دارد
- به کدام Route یا عملیات متصل است
- شرط نمایش فعلی چیست
- آیا فقط پنهان می‌شود یا Route نیز محافظت شده است
- Permission پیشنهادی چیست

==================================================
مرحله چهارم — ممیزی ماژول محتوا
==================================================

تمام قابلیت‌های مرتبط با پست و محتوا را بررسی کن، از جمله:

- مشاهده فهرست پست‌های مدیریت
- مشاهده پیش‌نویس‌ها
- مشاهده پست‌های منتشرنشده
- مشاهده پست‌های حذف‌شده، اگر وجود دارد
- ایجاد پست
- ویرایش پست
- ویرایش پست دیگران
- حذف پست
- حذف دائمی، اگر وجود دارد
- فعال یا غیرفعال‌کردن
- انتشار
- لغو انتشار
- Pin یا Unpin
- تغییر ترتیب
- کپی پست
- مشاهده Preview
- افزودن و ویرایش متن
- خلاصه
- گزیده
- فهرست
- پرسش‌وپاسخ
- اطلاعات جلسه
- موضوع
- دسته‌بندی
- محل برگزاری
- تاریخ
- SEO
- Canonical
- تصویر شاخص
- رسانه
- فایل صوتی
- ویدئو
- آپارات
- عملیات گروهی
- جستجوی مدیریتی
- فیلتر منتشرشده/نشده

برای هر عملیات مشخص کن:

- محل UI
- Component
- متد اجرا
- Service
- Endpoint
- HTTP Method
- شرط دسترسی فعلی
- Permission پیشنهادی
- سطح حساسیت

Permissionها را بیش از حد کلی نکن.

نمونه سطح تفکیک قابل بررسی:

- Content.ViewAdminList
- Content.ViewUnpublished
- Content.Create
- Content.Edit
- Content.EditAny
- Content.Delete
- Content.Publish
- Content.Unpublish
- Content.Pin
- Content.ManageMedia

این‌ها فقط مثال هستند. ابتدا وضعیت واقعی پروژه را استخراج کن و سپس Permission پیشنهادی بده.

==================================================
مرحله پنجم — ممیزی ارتباط‌دهی
==================================================

تمام قابلیت‌های Relation را بررسی کن:

- آیات مرتبط
- روایات مرتبط
- کلیدواژه‌ها
- پست‌های مرتبط
- دعاهای مرتبط
- افزودن Relation
- حذف Relation
- تغییر Level
- مشاهده Relationها
- جستجوی مرجع
- افزودن کلیدواژه داخل Dialog
- افزودن آیه
- افزودن روایت
- افزودن دعا
- ویرایش اطلاعات مرجع
- حذف اطلاعات مرجع
- صفحه مدیریت دعا
- صفحه مدیریت آیات
- صفحه مدیریت روایات
- صفحه مدیریت کلیدواژه‌ها

برای هر نوع Relation تفکیک کن:

- مشاهده
- افزودن
- تغییر سطح
- حذف
- ایجاد داده مرجع
- ویرایش داده مرجع
- حذف داده مرجع

بررسی کن که آیا نقش ارتباط‌ده می‌تواند ناخواسته بخش دیگری از پست را تغییر دهد.

تمام عملیات Auto Save را نیز ثبت کن.

Permissionهای پیشنهادی باید امکان این مدل را بدهند:

- مدیریت Relation بدون ویرایش متن پست
- مدیریت داده مرجع مستقل از مدیریت Relation
- مدیریت دعا مستقل از حدیث
- تغییر سطح بدون حذف و ایجاد مجدد Relation

==================================================
مرحله ششم — ممیزی کاربران، نقش‌ها و عضویت
==================================================

تمام قابلیت‌های مربوط به کاربران را پیدا کن:

- مشاهده لیست کاربران
- مشاهده جزئیات کاربر
- جستجوی کاربران
- تأیید عضویت
- لغو تأیید
- فعال یا غیرفعال‌کردن
- حذف کاربر
- ویرایش مشخصات
- تخصیص نقش
- حذف نقش
- مشاهده نقش‌ها
- ایجاد نقش
- ویرایش نقش
- حذف نقش
- مدیریت Permissionها
- مشاهده Loginها یا Sessionها، اگر وجود دارد
- باطل‌کردن Token، اگر وجود دارد
- مشاهده اطلاعات خصوصی کاربر

وضعیت تأییدشدگی را از Role جدا گزارش کن.

==================================================
مرحله هفتم — ممیزی رسانه و فایل
==================================================

تمام عملیات فایل و رسانه را شناسایی کن:

- آپلود تصویر
- آپلود صوت
- آپلود ویدئو
- آپلود فایل ضمیمه
- مشاهده فایل
- دانلود فایل
- حذف فایل
- تغییر وضعیت فایل
- انتخاب تصویر شاخص
- فایل‌های گزارش کاربران
- فایل‌های گزارش اقدام
- دانلود صوت محافظت‌شده
- لینک مستقیم CDN
- Media Manager
- Gallery
- مدیریت فایل‌های بدون استفاده، اگر وجود دارد

برای هرکدام مشخص کن:

- عمومی یا خصوصی
- نیازمند Login
- نیازمند تأییدشدگی
- نیازمند نقش مدیریتی
- Endpoint
- آیا URL مستقیم قابل دسترس است
- Permission پیشنهادی

==================================================
مرحله هشتم — ممیزی جستجو و داده‌های عمومی
==================================================

بررسی کن:

- جستجوی عمومی
- جستجوی مدیریت
- جستجوی پست‌های منتشرنشده
- جستجوی کاربران
- جستجوی داده‌های مرجع
- جستجوی Relation
- جستجوی ID
- SearchAdvanced
- فیلتر تاریخ
- مشاهده اطلاعاتی که نباید عمومی باشند

اگر یک Search API اطلاعات پیش‌نویس یا فیلدهای مدیریتی برمی‌گرداند، آن را گزارش کن.

==================================================
مرحله نهم — قابلیت‌های برنامه‌ریزی‌شده اما هنوز پیاده‌نشده
==================================================

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

- گزارش اشکال
- نظر خصوصی
- گزارش اقدام
- پیوست فایل تا مجموع ۶۰ مگابایت
- نسخه پیشنهادی اصلاح محتوا
- ذخیره خودکار نسخه پیشنهادی
- مقایسه نسخه اصلی و پیشنهادی
- تأیید و جایگزینی نسخه
- صف مشترک سردبیران
- تحویل به سردبیر
- انتشار نهایی سردبیر
- نیازمند بررسی
- رد همراه با توضیح
- بازگرداندن پست منتشرشده به صف
- داشبورد سردبیری
- شمارنده پست‌های منتظر
- مرکز بازخورد و بازبینی
- تاریخچه اقدامات
- دانلود امن صوت برای کاربر تأییدشده

این موارد را با وضعیت زیر گزارش کن:

- موجود و کامل
- موجود ولی ناقص
- فقط UI
- فقط مدل یا Service
- هنوز وجود ندارد
- قابل تشخیص نیست

برای مواردی که هنوز وجود ندارند، Permission پیشنهادی را در بخش جداگانه «Permissionهای آینده» قرار بده تا با وضعیت فعلی مخلوط نشوند.

==================================================
مرحله دهم — شناسایی تمام Actionها
==================================================

تمام Actionهای حساس را از HTML و TypeScript استخراج کن، از جمله:

- click handlerها
- submit handlerها
- context menuها
- Dialog actionها
- تغییر وضعیت Dropdownها
- Toggleها
- Deleteها
- Saveها
- Publishها
- Downloadها
- Uploadها
- Approve/Rejectها
- Bulk actionها

برای هر Action بنویس:

- متن دکمه
- فایل HTML
- فایل TypeScript
- نام متد
- Service method
- Endpoint
- شرط نمایش
- شرط اجرای داخل TypeScript
- Permission پیشنهادی

==================================================
مرحله یازدهم — بررسی Endpointها
==================================================

یک فهرست یکتا از تمام Endpointهای استفاده‌شده در فرانت تهیه کن.

برای هر Endpoint:

- Module
- URL
- Method
- عملیات
- صفحه یا Component مصرف‌کننده
- عمومی یا حساس
- Login موردنیاز
- Role/Permission فعلی قابل مشاهده
- Permission پیشنهادی
- آیا چند عملیات متفاوت از یک Endpoint استفاده می‌کنند
- آیا نام Endpoint با عملیات آن ناسازگار یا مبهم است
- آیا احتمال IDOR وجود دارد
- آیا ContentID/UserID از سمت کاربر ارسال می‌شود
- آیا API باید مالکیت رکورد را بررسی کند
- آیا کنترل بک‌اند قابل تأیید است

Endpointهای تکراری را یکی کن ولی تمام مصرف‌کنندگان را ذکر کن.

==================================================
مرحله دوازدهم — شناسایی ریسک‌های امنیتی
==================================================

این موارد را جداگانه گزارش کن:

- Route مدیریتی بدون Guard
- Guard فقط براساس Login
- کنترل فقط براساس نام Role در Angular
- دکمه مخفی بدون کنترل Route
- دکمه مخفی بدون کنترل API قابل تأیید
- Role ID هاردکدشده
- SuperAdmin check پراکنده
- اطلاعات نقش قابل‌تغییر در localStorage
- امکان فراخوانی مستقیم API
- امکان تغییر ID رکورد در Request
- امکان ویرایش یا حذف رکورد دیگران
- دانلود فایل با URL عمومی
- Endpoint حساس GET
- عملیات حذف بدون Confirmation
- عملیات Publish بدون Permission مشخص
- خطاهایی که اطلاعات حساس نمایش می‌دهند
- نمایش اطلاعات پیش‌نویس در صفحات عمومی
- کنترل دسترسی متفاوت میان موبایل و دسکتاپ
- منوی مخفی ولی Route قابل ورود مستقیم
- استفاده از `isAdmin` برای چند سطح دسترسی متفاوت

ریسک‌ها را با این اولویت مشخص کن:

- بحرانی
- زیاد
- متوسط
- کم

==================================================
خروجی اول — گزارش جامع Markdown
==================================================

فایل زیر را ایجاد کن:

`docs/access-control-audit-fa.md`

ساختار گزارش:

# ممیزی جامع دسترسی‌ها

## ۱. خلاصه مدیریتی

## ۲. معماری فعلی احراز هویت و مجوزها

## ۳. نقش‌های فعلی مشاهده‌شده در کد

## ۴. وضعیت‌های کاربری مشاهده‌شده

## ۵. Routeهای قابل‌کنترل

## ۶. منوها و دکمه‌های حساس

## ۷. دسترسی‌های مدیریت محتوا

## ۸. دسترسی‌های رسانه

## ۹. دسترسی‌های ارتباط‌دهی

## ۱۰. دسترسی‌های کاربران و نقش‌ها

## ۱۱. دسترسی‌های جستجو

## ۱۲. قابلیت‌های آینده و Permissionهای موردنیاز

## ۱۳. فهرست Endpointهای حساس

## ۱۴. نقاط کنترل فقط در UI

## ۱۵. ریسک‌ها و شکاف‌های امنیتی

## ۱۶. Permissionهای پیشنهادی یکتا

## ۱۷. موارد نامشخص برای پاسخ بک‌اند

## ۱۸. جمع‌بندی

برای هر مورد، حتماً مسیر فایل و نام Component یا Service را ذکر کن.

==================================================
خروجی دوم — ماتریس CSV
==================================================

فایل زیر را ایجاد کن:

`docs/access-control-inventory.csv`

ستون‌ها دقیقاً:

- Module
- Feature
- Action
- UI_Label
- Route
- Component
- Template_File
- TypeScript_File
- Service
- Service_Method
- Endpoint
- HTTP_Method
- Current_UI_Condition
- Current_Guard
- Current_Role_Check
- Authentication_Required
- Verification_Required
- Suggested_Permission
- Sensitivity
- Backend_Enforcement_Known
- Risk
- Notes

هر Action باید یک سطر جداگانه داشته باشد.

==================================================
خروجی سوم — فهرست Permissionهای پیشنهادی
==================================================

فایل زیر را ایجاد کن:

`docs/suggested-permissions-fa.md`

Permissionها را براساس Domain گروه‌بندی کن:

- Auth
- Users
- Roles
- Content
- Editorial
- Relations
- ReferenceData
- Media
- Feedback
- ActionReports
- CorrectionProposals
- Search
- Reports
- Settings
- SecureDownloads

برای هر Permission بنویس:

- نام فنی پیشنهادی
- عنوان فارسی
- شرح دقیق
- عملیات تحت پوشش
- فایل‌ها یا Endpointهای مرتبط
- فعلی یا آینده
- آیا قابل ترکیب با Permission دیگر است یا باید مستقل بماند

از ساخت Permissionهای بیش از حد ریز یا بیش از حد کلی خودداری کن.

==================================================
خروجی چهارم — ماتریس اولیه نقش‌ها
==================================================

فایل زیر را ایجاد کن:

`docs/proposed-role-permission-matrix-fa.md`

ردیف‌ها Permissionها و ستون‌ها این نقش‌ها باشند:

- مهمان
- عضو واردشده ولی تأییدنشده
- عضو تأییدشده
- نویسنده/تدوین‌گر
- ادمین محتوا
- ارتباط‌ده
- سردبیر
- سوپر ادمین

برای هر خانه یکی از این وضعیت‌ها را بگذار:

- مجاز
- غیرمجاز
- فقط رکورد خود
- فقط خواندن
- نیازمند تصمیم
- آینده

مهم:

این ماتریس صرفاً پیشنهاد اولیه Codex است و تصمیم نهایی را اعلام نکن.

==================================================
خروجی پنجم — پرسش‌های لازم از بک‌اند
==================================================

فایل زیر را ایجاد کن:

`docs/backend-access-questions-fa.md`

فقط سؤال‌هایی را ثبت کن که از روی فرانت قابل پاسخ نیستند؛ مانند:

- آیا Endpoint مجوز را در بک‌اند بررسی می‌کند؟
- Claimهای فعلی JWT چیست؟
- آیا User می‌تواند چند Role داشته باشد؟
- آیا Permission در دیتابیس وجود دارد؟
- مالکیت رکورد چگونه بررسی می‌شود؟
- آیا Download URL عمومی است؟
- آیا Edit/Delete فقط با ID کنترل می‌شود؟
- آیا انتشار داخل SP کنترل می‌شود؟
- آیا Role IDهای فعلی ثابت هستند؟

سؤال‌ها را براساس اولویت مرتب کن:

- حیاتی پیش از طراحی Permission
- لازم پیش از پیاده‌سازی
- قابل تصمیم در مرحله بعد

==================================================
کنترل کیفیت گزارش
==================================================

پیش از پایان بررسی کن:

- تمام Routeها پوشش داده شده باشند.
- تمام Serviceها و Endpointها بررسی شده باشند.
- تمام دکمه‌های CRUD پوشش داده شده باشند.
- تمام Dialogها بررسی شده باشند.
- نسخه موبایل یا منوی موبایل فراموش نشده باشد.
- Role checkهای تکراری گزارش شده باشند.
- Permissionهای پیشنهادی یکتا باشند.
- وضعیت فعلی و نیاز آینده با هم مخلوط نشده باشند.
- هیچ قابلیت فرضی به‌عنوان قابلیت موجود معرفی نشده باشد.
- هیچ فایل سورس برنامه تغییر نکرده باشد.

==================================================
گزارش نهایی Codex
==================================================

در پایان فقط یک گزارش کوتاه فارسی بده و شامل این موارد باشد:

1. تعداد Routeهای بررسی‌شده
2. تعداد Componentهای بررسی‌شده
3. تعداد Serviceهای بررسی‌شده
4. تعداد Endpointهای یکتا
5. تعداد Actionهای حساس
6. تعداد Permissionهای پیشنهادی
7. تعداد ریسک‌های بحرانی، زیاد، متوسط و کم
8. نقش‌های فعلی مشاهده‌شده
9. فایل‌های گزارش ایجادشده
10. مهم‌ترین ابهام‌هایی که باید از بک‌اند پرسیده شوند
11. تأیید اینکه هیچ فایل سورس برنامه تغییر نکرده است

هیچ اصلاحی در کد انجام نده.