add activity diagrams for system workflows

Added user stories for the university maintenance reporting system, detailing requirements for students, faculty, maintenance staff, and technicians.

.github/CODEOWNERS

@@ -0,0 +1,2 @@
+# All files require review from AmirAref
+* @AmirAref

CONTRIBUTING.md

@@ -72,6 +72,29 @@ git push -u origin aref-tasks
 
 ---
 
+## ۶. رسم نمودار با Mermaid
+
+برای رسم نمودارها (مثل Class Diagram) از ابزار [Mermaid](https://mermaid.js.org/) استفاده کنید.  
+نمودار به‌صورت متن نوشته می‌شود، بنابراین تغییرات آن در Git قابل مشاهده و بازبینی است. گیت‌هاب این نمودارها را مستقیم در فایل‌های `.md` نمایش می‌دهد.
+
+مثال یک Class Diagram:
+
+```mermaid
+classDiagram
+    class Report {
+        +id: int
+        +status: string
+        +submit()
+    }
+    class Technician {
+        +name: string
+        +assign(report)
+    }
+    Technician "1" --> "*" Report : repairs
+```
+
+---
+
 ## نکات مهم
 
 - همیشه قبل از شروع کار جدید، آخرین تغییرات `CONTRIBUTINGmain` را بگیر:

README.md

@@ -41,3 +41,5 @@
 ## نحوه همکاری
 
 هر عضو تیم با اکانت شخصی خود محتوا را اضافه یا اصلاح می‌کند تا تاریخچه Commitها نشان‌دهندهٔ سهم هر نفر باشد.
+
+برای جزئیات بیشتر درباره نحوهٔ کار با برنچ‌ها و Pull Request، [راهنمای همکاری (CONTRIBUTING.md)](CONTRIBUTING.md) را ببینید.

docs/analysis/activity.md

@@ -0,0 +1,265 @@
+# نمودارهای فعالیت
+
+این سند جریان‌های کاری اصلی سامانه گزارش و مدیریت خرابی‌های دانشگاه را با استفاده از Mermaid نمایش می‌دهد.
+
+> **نکته:** نمودارها بر اساس بازیگران و ۱۷ داستان کاربری شناسایی‌شده در مستندات تحلیل تهیه شده‌اند. جزئیاتی که در نیازمندی‌ها صریحاً مشخص نشده‌اند، به‌عنوان فرض یا پرسش باز علامت‌گذاری شده‌اند و نباید قانون قطعی سیستم تلقی شوند.
+
+## ۱. بازیگران و مسئولیت‌ها
+
+| بازیگر | مسئولیت‌ها |
+|---|---|
+| دانشجو (Student) | ثبت و پیگیری گزارش خرابی، ارائه اطلاعات تکمیلی و تأیید یا رد نتیجه تعمیر |
+| استاد (Professor) | ثبت و پیگیری گزارش خرابی، ارائه اطلاعات تکمیلی و تأیید یا رد نتیجه تعمیر |
+| کارمند تأسیسات (Facilities Staff) | بررسی و فیلتر گزارش‌ها، تعیین اولویت، تخصیص تعمیرکار، به‌روزرسانی وضعیت و مشاهده تاریخچه |
+| تعمیرکار (Technician) | مشاهده مأموریت‌های تخصیص‌یافته، شروع تعمیر، ثبت نتیجه و درخواست اطلاعات تکمیلی |
+| مدیر (Manager) | مشاهده داشبورد مدیریتی؛ سطح دسترسی دقیق این نقش باید در نیازمندی‌ها مشخص شود |
+| کاربر سیستم (System User) | عنوان عمومی کاربر احراز هویت‌شده در داستان‌های ورود و اعلان؛ لزوماً یک نقش انسانی مستقل نیست |
+
+## ۲. نمودار فعالیت احراز هویت (Authentication Activity)
+
+**داستان کاربری مرتبط:** US-15 — ورود به سیستم (Log in).
+
+این نمودار فرایند عمومی ورود کاربر را نشان می‌دهد. روش دقیق احراز هویت، بازیابی رمز عبور و سیاست قفل حساب در این بخش مشخص نشده‌اند.
+
+```mermaid
+flowchart TD
+    A([شروع]) --> B[باز کردن صفحه ورود]
+    B --> C[وارد کردن نام کاربری و رمز عبور]
+    C --> D[ارسال فرم ورود]
+    D --> E{آیا اطلاعات ورود معتبر هستند؟}
+    E -->|خیر| F[نمایش خطای ورود]
+    F --> C
+    E -->|بله| G[احراز هویت کاربر]
+    G --> H[تشخیص نقش کاربر]
+    H --> I[نمایش داشبورد متناسب با نقش کاربر]
+    I --> J([پایان])
+```
+
+## ۳. نمودار فعالیت ثبت گزارش خرابی (Fault Reporting Activity)
+
+**داستان‌های کاربری مرتبط:**
+- US-01 — دانشجو گزارش خرابی ثبت می‌کند.
+- US-02 — استاد گزارش خرابی ثبت می‌کند.
+- US-03 — دانشجو یا استاد وضعیت گزارش را پیگیری می‌کند.
+- US-04 — دانشجو یا استاد اطلاعات تکمیلی ارائه می‌دهد.
+
+دانشجو و استاد از جریان کاری کلی یکسانی برای گزارش خرابی استفاده می‌کنند؛ بنابراین در یک گروه مسئولیت نمایش داده شده‌اند.
+
+```mermaid
+flowchart TD
+    subgraph Reporter["دانشجو / استاد"]
+        A([شروع]) --> B[باز کردن صفحه ثبت گزارش خرابی]
+        B --> C[وارد کردن جزئیات خرابی]
+        C --> D[ثبت و ارسال گزارش خرابی]
+        H[اصلاح اطلاعات گزارش]
+        I[مشاهده وضعیت گزارش]
+        J[ارائه اطلاعات تکمیلی]
+    end
+
+    subgraph System["سیستم"]
+        E{آیا اطلاعات واردشده معتبر هستند؟}
+        F[نمایش خطاهای اعتبارسنجی]
+        G[ذخیره گزارش خرابی]
+        K[قرار دادن گزارش در فهرست گزارش‌های قابل بررسی]
+        L[نمایش وضعیت فعلی گزارش]
+    end
+
+    D --> E
+    E -->|خیر| F
+    F --> H
+    H --> D
+    E -->|بله| G
+    G --> K
+    K --> I
+    I --> L
+    L --> M{آیا اطلاعات تکمیلی درخواست شده است؟}
+    M -->|بله| J
+    J --> K
+    M -->|خیر| N([پایان])
+```
+
+**نکته مدل‌سازی:** حلقه اصلاح اطلاعات، اعتبارسنجی فرم را نمایش می‌دهد. باید مشخص شود آیا کاربر می‌تواند در هر زمان اطلاعات تکمیلی ارسال کند یا فقط پس از درخواست کارمند تأسیسات یا تعمیرکار مجاز به این کار است.
+
+## ۴. نمودار فعالیت مدیریت گزارش‌ها (Report Management Activity)
+
+**داستان‌های کاربری مرتبط:**
+- US-06 — مشاهده و فیلتر گزارش‌های باز.
+- US-07 — تعیین اولویت گزارش.
+- US-08 — تخصیص تعمیرکار.
+- US-09 — به‌روزرسانی وضعیت گزارش.
+- US-10 — مشاهده تاریخچه گزارش.
+- US-17 — مشاهده داشبورد توسط کارمند تأسیسات یا مدیر.
+
+```mermaid
+flowchart TD
+    subgraph Staff["کارمند تأسیسات"]
+        A([شروع]) --> B[باز کردن داشبورد مدیریت گزارش‌ها]
+        B --> C[مشاهده و فیلتر گزارش‌های باز]
+        C --> D[انتخاب یک گزارش]
+        E[بررسی جزئیات گزارش]
+        F[تعیین اولویت گزارش]
+        G[انتخاب تعمیرکار مناسب]
+        H[به‌روزرسانی وضعیت گزارش]
+        I[مشاهده تاریخچه گزارش]
+    end
+
+    subgraph System["سیستم"]
+        J[نمایش گزارش انتخاب‌شده]
+        K{آیا گزارش آماده تخصیص است؟}
+        L[درخواست یا ثبت اطلاعات ناقص]
+        M[ذخیره اولویت]
+        N[ذخیره تخصیص تعمیرکار]
+        O[ذخیره تغییر وضعیت]
+        P[در دسترس قرار دادن مأموریت برای تعمیرکار]
+    end
+
+    D --> J
+    J --> E
+    E --> K
+    K -->|خیر| L
+    L --> I
+    I --> Q([پایان])
+    K -->|بله| F
+    F --> M
+    M --> G
+    G --> N
+    N --> P
+    P --> H
+    H --> O
+    O --> I
+```
+
+**نکته مدل‌سازی:** تصمیم «آیا گزارش آماده تخصیص است؟» یک مرحله پیشنهادی است. شرایط دقیق تخصیص تعمیرکار و نحوه بازگرداندن گزارش‌های ناقص به گزارش‌دهنده باید در نیازمندی‌ها مشخص شوند.
+
+## ۵. نمودار فعالیت تعمیر خرابی (Repair Activity)
+
+**داستان‌های کاربری مرتبط:**
+- US-11 — تعمیرکار کارهای تخصیص‌یافته را مشاهده می‌کند.
+- US-12 — تعمیرکار تعمیر را آغاز می‌کند.
+- US-13 — تعمیرکار نتیجه تعمیر را ثبت می‌کند.
+- US-14 — تعمیرکار درخواست اطلاعات تکمیلی می‌دهد.
+
+```mermaid
+flowchart TD
+    subgraph Technician["تعمیرکار"]
+        A([شروع]) --> B[باز کردن فهرست کارهای تخصیص‌یافته]
+        B --> C[انتخاب یک مأموریت]
+        C --> D[بررسی جزئیات خرابی]
+        E[شروع فرایند تعمیر]
+        F[انجام عملیات تعمیر]
+        G[ثبت نتیجه تعمیر]
+        H[درخواست اطلاعات تکمیلی]
+    end
+
+    subgraph System["سیستم"]
+        I[نمایش مأموریت تخصیص‌یافته]
+        J[به‌روزرسانی وضعیت گزارش]
+        K{آیا اطلاعات تکمیلی مورد نیاز است؟}
+        L[ارسال درخواست اطلاعات]
+        M[ذخیره نتیجه تعمیر]
+        N[اعلان ثبت نتیجه تعمیر به کاربر مربوطه]
+    end
+
+    C --> I
+    I --> D
+    D --> E
+    E --> J
+    J --> F
+    F --> K
+    K -->|بله| H
+    H --> L
+    L --> O[انتظار برای دریافت اطلاعات درخواستی]
+    O --> F
+    K -->|خیر| G
+    G --> M
+    M --> N
+    N --> P([پایان])
+```
+
+**نکته مدل‌سازی:** در این نمودار، درخواست اطلاعات تکمیلی باعث توقف موقت تعمیر می‌شود. باید مشخص شود چه کسی اطلاعات را ارائه می‌کند، پس از دریافت اطلاعات چگونه به تعمیرکار اطلاع داده می‌شود و آیا هنگام انتظار وضعیت گزارش تغییر می‌کند یا خیر.
+
+## ۶. نمودار فعالیت تأیید تعمیر (Repair Verification Activity)
+
+**داستان کاربری مرتبط:** US-05 — دانشجو یا استاد تکمیل تعمیر را تأیید یا رد می‌کند.
+
+گزارش‌دهنده نتیجه ثبت‌شده تعمیر را بررسی می‌کند و مشخص می‌کند که آیا خرابی برطرف شده است یا خیر.
+
+```mermaid
+flowchart TD
+    subgraph Reporter["دانشجو / استاد"]
+        A([شروع]) --> B[مشاهده اطلاعات تکمیل تعمیر]
+        B --> C[بررسی نتیجه تعمیر]
+        C --> D{آیا خرابی برطرف شده است؟}
+        E[تأیید تکمیل تعمیر]
+        F[رد تکمیل تعمیر]
+    end
+
+    subgraph System["سیستم"]
+        G[ثبت تأیید گزارش‌دهنده]
+        H[بستن گزارش]
+        I[ثبت رد نتیجه تعمیر]
+        J[بازگرداندن گزارش برای پیگیری بیشتر]
+    end
+
+    D -->|بله| E
+    E --> G
+    G --> H
+    H --> K([پایان])
+    D -->|خیر| F
+    F --> I
+    I --> J
+    J --> L([پایان - نیازمند پیگیری بیشتر])
+```
+
+**پرسش باز:** نیازمندی‌ها باید مشخص کنند پس از رد نتیجه تعمیر چه اتفاقی می‌افتد: آیا گزارش به کارمند تأسیسات بازمی‌گردد، دوباره به همان تعمیرکار تخصیص داده می‌شود یا فرایند دیگری اجرا می‌شود؟ این نمودار هیچ‌یک از این سیاست‌ها را به‌عنوان تصمیم قطعی انتخاب نمی‌کند.
+
+## ۷. نمودار کلی چرخه عمر گزارش خرابی (Overall Fault Lifecycle)
+
+این نمودار نمایی کلی از فرایند اصلی سیستم ارائه می‌دهد و مراحل ثبت گزارش، مدیریت، تعمیر و تأیید را به یکدیگر متصل می‌کند.
+
+```mermaid
+flowchart TD
+    A([شروع]) --> B[ثبت گزارش خرابی توسط دانشجو یا استاد]
+    B --> C{آیا گزارش معتبر است؟}
+    C -->|خیر| D[اصلاح اطلاعات گزارش توسط گزارش‌دهنده]
+    D --> B
+    C -->|بله| E[ذخیره گزارش توسط سیستم]
+    E --> F[بررسی گزارش توسط کارمند تأسیسات]
+    F --> G{آیا اطلاعات بیشتری مورد نیاز است؟}
+    G -->|بله| H[درخواست اطلاعات تکمیلی]
+    H --> I[ارائه اطلاعات توسط گزارش‌دهنده]
+    I --> F
+    G -->|خیر| J[تعیین اولویت توسط کارمند تأسیسات]
+    J --> K[تخصیص تعمیرکار توسط کارمند تأسیسات]
+    K --> L[مشاهده مأموریت توسط تعمیرکار]
+    L --> M[شروع فرایند تعمیر توسط تعمیرکار]
+    M --> N{آیا تعمیرکار به اطلاعات بیشتری نیاز دارد؟}
+    N -->|بله| O[درخواست اطلاعات توسط تعمیرکار]
+    O --> P[ارائه اطلاعات درخواستی]
+    P --> M
+    N -->|خیر| Q[ثبت نتیجه تعمیر توسط تعمیرکار]
+    Q --> R[بررسی نتیجه تعمیر توسط گزارش‌دهنده]
+    R --> S{آیا گزارش‌دهنده تعمیر را تأیید می‌کند؟}
+    S -->|بله| T[بستن گزارش توسط سیستم]
+    T --> U([پایان])
+    S -->|خیر| V[ثبت عدم تأیید]
+    V --> W[بازگرداندن گزارش برای پیگیری بیشتر]
+    W --> F
+```
+
+**نکته مدل‌سازی:** بازگشت گزارش ردشده به مرحله بررسی کارمند تأسیسات، یک مسیر پیشنهادی برای پیگیری مجدد است و هنوز سیاست قطعی تخصیص مجدد محسوب نمی‌شود. این مسیر باید با اعضای تیم پروژه بررسی و تأیید شود.
+
+## ۸. پرسش‌ها و ابهام‌های نیازمندی‌ها
+
+موارد زیر باید پیش از نهایی‌شدن نمودارها با اعضای تیم پروژه مشخص شوند:
+
+1. **اعتبارسنجی گزارش:** کدام فیلدها اجباری هستند و چه شرایطی باعث نامعتبر شدن گزارش می‌شود؟
+2. **رد گزارش:** آیا کارمند تأسیسات می‌تواند گزارش ثبت‌شده را رد کند؟ در صورت امکان، دلایل و وضعیت‌های مربوط به آن چیست؟
+3. **اولویت‌ها:** چه سطوحی برای اولویت وجود دارد و معیار تعیین هر سطح چیست؟
+4. **وضعیت‌های گزارش:** فهرست رسمی وضعیت‌ها و انتقال‌های مجاز بین آن‌ها چیست؟
+5. **تخصیص تعمیرکار:** آیا یک گزارش می‌تواند به چند تعمیرکار تخصیص داده شود یا در هر لحظه فقط یک تعمیرکار مسئول آن است؟
+6. **اطلاعات تکمیلی:** چه افرادی می‌توانند درخواست اطلاعات دریافت کنند و هنگام انتظار برای پاسخ چه اتفاقی می‌افتد؟
+7. **تأیید تعمیر:** پس از رد نتیجه تعمیر توسط گزارش‌دهنده، جریان کاری دقیق چیست؟
+8. **اعلان‌ها:** کدام رویدادها باعث ارسال اعلان می‌شوند، دریافت‌کنندگان چه کسانی هستند و اعلان‌ها از چه کانالی ارسال می‌شوند؟
+9. **دسترسی مدیر:** آیا دسترسی مدیر فقط به مشاهده داشبورد محدود است یا این نقش امکان مدیریت گزارش‌ها را نیز دارد؟
+10. **احراز هویت:** آیا قوانین ورود یا کنترل دسترسی برای نقش‌های مختلف متفاوت است؟

docs/analysis/requirements-specification.md

@@ -0,0 +1,43 @@
+# سند نیازمندی‌های سامانهٔ مدیریت و گزارش خرابی دانشگاهی
+
+## ۱. هدف و محدودهٔ سامانه
+
+هدف این سامانه، فراهم کردن بستری متمرکز برای ثبت خرابی تجهیزات و فضاهای دانشگاه، پیگیری درخواست‌ها و مدیریت فرایند تعمیر است. سامانه به گزارش‌دهندگان امکان می‌دهد خرابی را ثبت و وضعیت آن را پیگیری کنند و به مسئولان تأسیسات کمک می‌کند درخواست‌ها را بررسی و به تعمیرکاران ارجاع دهند.
+
+در این مرحله، محدودهٔ دقیق سامانه و امکانات نهایی آن هنوز نیازمند بررسی بیشتر است.
+
+## ۲. کاربران سامانه
+
+- **دانشجو و استاد:** ثبت گزارش خرابی و مشاهدهٔ وضعیت درخواست.
+- **مسئول تأسیسات:** بررسی گزارش‌ها، تعیین اولویت و ارجاع درخواست‌ها.
+- **تعمیرکار:** مشاهدهٔ درخواست‌های ارجاع‌شده و ثبت نتیجهٔ تعمیر.
+
+## ۳. نیازمندی‌های کارکردی (Functional Requirements)
+
+- **FR-01 — ثبت گزارش خرابی:** سامانه باید امکان ثبت گزارش شامل عنوان، توضیحات، محل خرابی و نوع تجهیز را فراهم کند.
+- **FR-02 — مشاهدهٔ گزارش:** کاربر باید بتواند اطلاعات گزارش ثبت‌شده و وضعیت فعلی آن را مشاهده کند.
+- **FR-03 — بررسی درخواست:** مسئول تأسیسات باید بتواند گزارش‌های ثبت‌شده را بررسی کند.
+- **FR-04 — تعیین اولویت:** مسئول تأسیسات باید بتواند اولویت رسیدگی به هر گزارش را مشخص کند.
+- **FR-05 — ارجاع به تعمیرکار:** مسئول تأسیسات باید بتواند درخواست را به تعمیرکار مربوطه ارجاع دهد.
+- **FR-06 — به‌روزرسانی وضعیت:** وضعیت درخواست باید در مراحل مختلف رسیدگی قابل به‌روزرسانی باشد.
+- **FR-07 — ثبت نتیجهٔ تعمیر:** تعمیرکار باید بتواند نتیجهٔ بررسی و اقدامات انجام‌شده را ثبت کند.
+- **FR-08 — مشاهدهٔ سوابق:** کاربران مجاز باید بتوانند سوابق درخواست‌ها و تعمیرات را متناسب با سطح دسترسی خود مشاهده کنند.
+
+## ۴. نیازمندی‌های غیرکارکردی (Non-functional Requirements)
+
+- **NFR-01 — امنیت:** سامانه باید از دسترسی غیرمجاز به اطلاعات و امکانات مدیریتی جلوگیری کند.
+- **NFR-02 — کنترل دسترسی:** هر کاربر باید فقط به امکانات متناسب با نقش خود دسترسی داشته باشد.
+- **NFR-03 — سهولت استفاده:** فرم‌های ثبت و پیگیری گزارش باید ساده و قابل فهم باشند.
+- **NFR-04 — کارایی:** عملیات معمول مانند ثبت گزارش و مشاهدهٔ وضعیت باید در زمان قابل قبول انجام شوند.
+- **NFR-05 — قابلیت اطمینان:** سامانه باید اطلاعات ثبت‌شده را به‌درستی نگهداری کند و از حذف یا تغییر ناخواستهٔ آن‌ها جلوگیری کند.
+- **NFR-06 — قابلیت نگهداری:** ساختار سامانه باید امکان اصلاح و افزودن قابلیت‌های جدید را در آینده فراهم کند.
+
+## ۵. فرضیات و ابهامات
+
+- هنوز مشخص نشده است که سامانه فقط فضاهای آموزشی و عمومی را پوشش می‌دهد یا خوابگاه‌ها و فضاهای اداری را نیز شامل می‌شود.
+- نحوهٔ اطلاع‌رسانی دربارهٔ تغییر وضعیت درخواست‌ها هنوز تعیین نشده است.
+- معیارهای دقیق اولویت‌بندی خرابی‌ها و سطح دسترسی هر نقش باید در مراحل بعدی مشخص شوند.
+
+## ۶. وضعیت سند
+
+این سند نسخهٔ اولیهٔ نیازمندی‌هاست و با تکمیل تحلیل پروژه و دریافت بازخورد اعضای گروه اصلاح خواهد شد.

docs/analysis/use-case.md

@@ -0,0 +1,131 @@
+# داستان‌های کاربر (User Stories) – سامانه مدیریت و گزارش خرابی دانشگاهی
+
+**تهیه‌کننده:** امیرحسن عارف اصل  
+**بازبین:** ارشیا همتی‌زاده  
+**آخرین به‌روزرسانی:** ۱۴۰۴/۰۸/۰۴
+
+---
+
+## مقدمه
+
+در این سند، نیازمندی‌های اصلی سامانه به صورت **داستان کاربر (User Story)** نوشته شده‌اند.  
+هر داستان کاربر از دیدگاه یک نقش مشخص بیان می‌شود و هدف آن را نیز مشخص می‌کند.
+
+قالب استاندارد:
+
+> به عنوان یک **<نقش>**  
+> می‌خواهم **<هدف>**  
+> تا بتوانم **<مزیت / نتیجه>**
+
+---
+
+## داستان‌های کاربر مرتبط با گزارش‌دهنده (دانشجو / استاد)
+
+### US-01
+به عنوان یک **دانشجو**  
+می‌خواهم **خرابی مشاهده‌شده را به همراه مکان و توضیحات ثبت کنم**  
+تا بتوانم **مشکل را سریع به بخش تأسیسات اطلاع دهم و پیگیری کنم**.
+
+### US-02
+به عنوان یک **استاد**  
+می‌خواهم **خرابی کلاس یا آزمایشگاه را ثبت کنم**  
+تا بتوانم **بدون اتلاف وقت، مشکل را به مسئولان مربوطه اعلام کنم**.
+
+### US-03
+به عنوان یک **دانشجو یا استاد**  
+می‌خواهم **وضعیت گزارش‌هایی که خودم ثبت کرده‌ام را مشاهده کنم**  
+تا بتوانم **از پیشرفت رسیدگی به گزارشم مطلع شوم**.
+
+### US-04
+به عنوان یک **دانشجو یا استاد**  
+می‌خواهم **تصویر یا توضیح بیشتری به گزارش قبلی اضافه کنم**  
+تا بتوانم **اطلاعات کامل‌تری در اختیار تعمیرکار قرار دهم**.
+
+### US-05
+به عنوان یک **دانشجو یا استاد**  
+می‌خواهم **پس از اعلام رفع خرابی، آن را تأیید یا رد کنم**  
+تا بتوانم **از بسته شدن صحیح گزارش مطمئن شوم**.
+
+---
+
+## داستان‌های کاربر مرتبط با کارمند تأسیسات
+
+### US-06
+به عنوان یک **کارمند تأسیسات**  
+می‌خواهم **لیست تمام گزارش‌های باز را مشاهده و فیلتر کنم**  
+تا بتوانم **گزارش‌های مهم و فوری را سریع‌تر پیدا کنم**.
+
+### US-07
+به عنوان یک **کارمند تأسیسات**  
+می‌خواهم **اولویت هر گزارش را تعیین کنم**  
+تا بتوانم **تعمیرات را بر اساس اهمیت و فوریت مدیریت کنم**.
+
+### US-08
+به عنوان یک **کارمند تأسیسات**  
+می‌خواهم **یک گزارش را به تعمیرکار مناسب تخصیص دهم**  
+تا بتوانم **کار را به فرد درست ارجاع دهم و پیگیری کنم**.
+
+### US-09
+به عنوان یک **کارمند تأسیسات**  
+می‌خواهم **وضعیت گزارش را تغییر دهم**  
+تا بتوانم **وضعیت واقعی رسیدگی به هر گزارش را در سیستم منعکس کنم**.
+
+### US-10
+به عنوان یک **کارمند تأسیسات**  
+می‌خواهم **تاریخچه کامل اقدامات انجام‌شده روی یک گزارش را ببینم**  
+تا بتوانم **روند رسیدگی را بررسی و در صورت نیاز پیگیری کنم**.
+
+---
+
+## داستان‌های کاربر مرتبط با تعمیرکار
+
+### US-11
+به عنوان یک **تعمیرکار**  
+می‌خواهم **لیست کارهای تخصیص‌یافته به خودم را ببینم**  
+تا بتوانم **بدانم چه کارهایی در انتظار انجام است**.
+
+### US-12
+به عنوان یک **تعمیرکار**  
+می‌خواهم **شروع کار روی یک گزارش را اعلام کنم**  
+تا بتوانم **وضعیت گزارش را به «در حال تعمیر» تغییر دهم**.
+
+### US-13
+به عنوان یک **تعمیرکار**  
+می‌خواهم **نتیجه تعمیر را همراه با توضیحات ثبت کنم**  
+تا بتوانم **گزارش را به مرحله بعدی (تأیید یا پیگیری) برسانم**.
+
+### US-14
+به عنوان یک **تعمیرکار**  
+می‌خواهم **در صورت نیاز، اطلاعات بیشتری از گزارش‌دهنده درخواست کنم**  
+تا بتوانم **تعمیر را با اطلاعات کامل‌تری انجام دهم**.
+
+---
+
+## داستان‌های کاربر مشترک / سیستمی
+
+### US-15
+به عنوان یک **کاربر سیستم**  
+می‌خواهم **با نام کاربری و رمز عبور وارد سامانه شوم**  
+تا بتوانم **به امکانات مربوط به نقش خودم دسترسی داشته باشم**.
+
+### US-16
+به عنوان یک **کاربر سیستم**  
+می‌خواهم **هنگام تغییر وضعیت گزارش مرتبط با خودم، اعلان دریافت کنم**  
+تا بتوانم **از آخرین وضعیت مطلع شوم**.
+
+### US-17
+به عنوان یک **کارمند تأسیسات یا مدیر**  
+می‌خواهم **داشبورد خلاصه‌ای از تعداد گزارش‌های باز و فوری ببینم**  
+تا بتوانم **وضعیت کلی خرابی‌ها را سریع ارزیابی کنم**.
+
+---
+
+## نکات و کارهای باقی‌مانده
+
+- این داستان‌ها نسخه اولیه هستند و ممکن است در بازبینی تغییر کنند یا داستان‌های جدید اضافه شود.
+- جزئیات پذیرش (Acceptance Criteria) برای داستان‌های مهم‌تر در مراحل بعدی نوشته خواهد شد.
+- ابهام دامنه (آیا خوابگاه‌ها و فضاهای اداری هم شامل می‌شوند؟) هنوز وجود دارد و روی برخی داستان‌ها تأثیر می‌گذارد.
+
+---
+
+**وضعیت سند:** نسخه اولیه (Draft) – آماده بازبینی