Toornaa
/
New_Micro_Learning
1
0
انشعاب 0
کد مسائل درخواست‌های ادغام بسته‌ها عنوان پروژه‌ها انتشارها ویکی فعالیت
New_Micro_Learning/Prompt/Manager.md

46 KiB
خام سرزنش تاریخچه

Master Prompt — MicroLearning Manager Experience Redesign

می‌خواهم بخش Manager / مدیران در پروژه MicroLearning را به‌صورت کامل بازطراحی و اصلاح کنی.

این کار فقط یک تغییر ظاهری نیست.

هدف این است که Manager Experience از حالت «نسخه محدودشده Admin Panel» خارج شود و به یک فضای مستقل، ساده، actionable و مخصوص مدیریت یادگیری تیم تبدیل شود.

هدف اصلی Manager Experience

پنل مدیر باید حول این سؤال طراحی شود:

وضعیت یادگیری تیم من چگونه است و الان باید چه اقدامی انجام دهم؟

Manager نباید برای انجام کارهای روزمره مجبور باشد با ساختار Course Designer، Admin یا Super Admin کار کند.

اصول اصلی

Manager Experience باید:

  • Team-centric باشد.
  • Action-oriented باشد.
  • Data driven باشد.
  • ساده‌تر از Admin Panel باشد.
  • Role-aware باشد.
  • Permission-aware باشد.
  • فقط اطلاعات مجاز تیم را نمایش دهد.
  • برای Desktop، Tablet و Mobile مناسب باشد.
  • RTL و LTR را پشتیبانی کند.
  • Dark Mode را خراب نکند.
  • از Design System موجود استفاده کند.

قانون Safety

Working Code Is Sacred

اگر بخشی:

  • درست کار می‌کند،
  • تست دارد،
  • Security Issue ندارد،
  • و مانع Manager Experience نیست،

فقط برای زیبایی Architecture آن را تغییر نده.

Minimum Necessary Change

فقط تغییراتی را انجام بده که مستقیماً برای Manager Experience ضروری هستند.

از Refactorهای unrelated خودداری کن.

Scope Lock

در ابتدای هر Phase اعلام کن:

Files expected to change
Modules affected
API endpoints affected
Permissions affected
Expected behavior changes
Behavior that must remain unchanged

اگر Issue جدیدی پیدا کردی که مربوط به فاز جاری نیست، در:

Deferred Technical Debt

ثبت کن.

Backend Safety

هیچ Permission یا Data Scope را فقط در Frontend پیاده‌سازی نکن.

اگر Manager نباید داده‌ای را ببیند:

Backend نیز باید آن را محدود کند.

Hide کردن Menu امنیت محسوب نمی‌شود.

Manager Data Scope

قاعده پیش‌فرض:

Manager
    ↓
Own permitted team
    ↓
Direct / authorized reports

نه:

Manager
    ↓
Entire Organization

مگر اینکه Permission صریح وجود داشته باشد.

PHASE 0 — Manager Role Audit & Permission Scope

هدف

قبل از تغییر UI، نقش Manager را در کل پروژه بررسی کن.

در این Phase redesign انجام نده.

1. Manager Role Audit

تمام موارد مربوط به Manager را پیدا کن:

roles
permissions
policies
middleware
API authorization
organization scope
team membership
reporting hierarchy
frontend route guards
navigation permissions

مشخص کن Manager در وضعیت فعلی چه چیزهایی می‌تواند:

View
Create
Update
Delete
Assign
Approve
Export

کند.

2. Data Visibility Audit

بررسی کن Manager اکنون به چه اطلاعاتی دسترسی دارد.

به‌خصوص:

Users
Teams
Courses
Assignments
Assessments
Progress
Skills
Reports
Certificates
Monitoring

هر endpoint را بررسی کن.

Manager نباید بتواند با تغییر دستی URL یا API parameter داده خارج از Scope خود را ببیند.

IDOR را بررسی کن.

3. Define Manager Permission Matrix

یک Matrix ایجاد کن.

مثال:

Capability Manager
View own team Yes
View organization users No
View team learning progress Yes
Assign approved course Yes
Create course No by default
Edit course No
Use Builder No
Use AI Studio No
View team skills Yes
Export team report Permission based
Extend assignment deadline Permission based
Approve learning request Permission based

Matrix نهایی را براساس قابلیت‌های واقعی پروژه تنظیم کن.

4. Role Separation

این چهار Experience را از هم تفکیک کن:

Super Admin
Course Designer
Manager
Learner

Manager نباید Sidebar مربوط به Course Designer را با چند گزینه hidden دریافت کند.

Manager Experience باید Navigation خودش را داشته باشد.

5. Backend Authorization Tests

Test بنویس برای اینکه Manager:

بتواند:

Own team data
Own team assignments
Own team progress
Authorized reports

نتواند:

Other team's private data
Organization-wide user data
Unauthorized course editing
Unauthorized Builder access
Unauthorized admin settings

Acceptance Criteria Phase 0

  • Manager role دقیقاً تعریف شده.
  • Permission Matrix وجود دارد.
  • Team Scope مشخص است.
  • Data Leakage بررسی شده.
  • Backend authorization تست دارد.
  • Feature unrelated تغییر نکرده.
  • UI redesign هنوز شروع نشده.

بعد متوقف شو.

PHASE 1 — Manager Shell, Navigation & Dashboard

هدف

Manager یک Experience مستقل و ساده داشته باشد.

Manager Navigation

Navigation پیشنهادی:

داشبورد

تیم من

یادگیری تیم

تخصیص آموزش

مهارت‌ها

گزارش‌ها

تأییدها

پایین Navigation:

اعلان‌ها
تنظیمات شخصی

فقط آیتم‌هایی را نمایش بده که Manager واقعاً Permission آن‌ها را دارد.

Remove Manager Irrelevant Navigation

موارد زیر به‌صورت پیش‌فرض نباید در پنل Manager نمایش داده شوند:

Course Builder
AI Studio
Question Bank
Template Management
Library Administration
Subscription
Organization Settings
System Settings

مگر Manager Permission صریح دیگری داشته باشد.

Manager App Shell

Shell مدیر شامل:

Sidebar
Top Header
Context
Main Content

باشد.

در Header:

Search if useful
Notifications
User menu
Team context if applicable

وجود داشته باشد.

Manager Dashboard

Dashboard مدیر را از Dashboard عمومی جدا کن.

Layout پیشنهادی:

Greeting
↓
Team Health
↓
Needs Attention
↓
Team Learning Progress
↓
Upcoming Deadlines
↓
Skills Snapshot
↓
Recent Activity

KPI Cards

KPIها compact باشند.

پیشنهاد:

Team members

Active learners

Completion rate

Behind schedule

Due soon

اعداد باید از داده واقعی backend بیایند.

Metric جعلی یا static ایجاد نکن.

Needs Attention

مهم‌ترین بخش Dashboard باشد.

نمونه:

4 learners are behind schedule

3 mandatory courses have not been started

2 assignments are due this week

3 employees haven't been active for 7 days

هر Item باید مستقیم Action داشته باشد.

مثلاً:

View learners

Send reminder

Extend deadline

View course

Continue Management Tasks

وظایف نیمه‌تمام Manager را نمایش بده:

Pending approvals

Recently assigned learning

Saved reports

Pending team actions

در صورت وجود داده واقعی.

Recent Activity

Activity Feed ساده باشد:

Ali completed Leadership Basics

Sara started Workplace Safety

5 users were assigned Communication Skills

Certificate issued to Reza

Dashboard Empty State

اگر Manager تیم ندارد یا داده‌ای موجود نیست، Dashboard نباید شکسته یا خالی باشد.

State مناسب طراحی کن.

Acceptance Criteria Phase 1

  • Manager Navigation مستقل است.
  • Admin navigation reuse کورکورانه نشده.
  • Dashboard کاملاً team-centric است.
  • Needs Attention وجود دارد.
  • KPIها compact و واقعی‌اند.
  • Actions مستقیم‌اند.
  • Permission-aware UI وجود دارد.
  • responsive صحیح است.

بعد متوقف شو.

PHASE 2 — My Team & Employee Learning Profiles

هدف

Manager بتواند وضعیت اعضای تیم را سریع بفهمد.

My Team Page

صفحه:

تیم من

ایجاد یا بازطراحی کن.

Toolbar:

Search
Status Filter
Team/Subteam Filter if permitted
Learning Status
Skills Filter if applicable

Team Table

اطلاعات پیشنهادی:

Employee

Role / Position

Active courses

Completion %

Due soon

Overdue

Last activity

Status

مثلاً:

Ali Rezaei
3 active
82%
0 overdue
Active today
Good

Team Status

از semantic state استفاده کن:

On Track

Needs Attention

Behind

Inactive

رنگ تنها indicator نباشد.

Text یا icon هم وجود داشته باشد.

Employee Learning Profile

روی Employee کلیک شود و پروفایل یادگیری باز شود.

حداقل:

Overview

Active Learning

Completed Learning

Assessments

Skills

Learning Paths

Certificates

Recent Activity

اما فقط اطلاعاتی که Manager اجازه دیدن آن را دارد.

Employee Overview

پیشنهاد:

Name
Position
Team

Current progress
Active courses
Completed courses
Due assignments
Skill development

Learning Timeline

در صورت وجود داده:

Assigned
Started
Progressed
Completed
Assessment
Certificate

Timeline ساده ایجاد کن.

Manager Quick Actions

از Employee Profile:

Assign Learning

Send Reminder

View Progress

View Skills

و در صورت Permission:

Extend Deadline

Privacy

اطلاعات unrelated منابع انسانی را نمایش نده.

Manager Learning Profile نباید به HR Master Profile تبدیل شود.

Acceptance Criteria Phase 2

  • My Team قابل استفاده است.
  • Search و Filter مناسب دارد.
  • Employee Learning Profile ایجاد شده.
  • مدیر فقط Scope خودش را می‌بیند.
  • Quick Actions وجود دارد.
  • mobile table مناسب است.
  • N+1 query یا request explosion ایجاد نشده.

بعد متوقف شو.

PHASE 3 — Learning Assignment, Deadlines & Notifications

هدف

تخصیص آموزش برای Manager بسیار ساده شود.

Assignment Flow

Manager نباید وارد workflow پیچیده Admin شود.

Flow پیشنهادی:

Who?
↓
What learning?
↓
Deadline
↓
Notification
↓
Review
↓
Assign

STEP 1 — Audience

Manager بتواند انتخاب کند:

Whole Team

Specific employees

Sub-team

فقط در Scope مجاز.

STEP 2 — Learning

Manager فقط محتوایی را ببیند که برای assignment مجاز است.

مثلاً:

Published Courses

Learning Paths

Mandatory Learning

Draft یا private course در صورت عدم Permission نمایش داده نشود.

STEP 3 — Deadline

انتخاب:

No deadline

Specific date

Relative deadline

مثلاً:

Complete within 14 days

اگر backend support می‌کند.

STEP 4 — Notification

گزینه‌های مناسب:

Notify learner now

Reminder before deadline

Reminder on deadline

Reminder if not started

Push Notification Readiness

Architecture را طوری طراحی کن که Notification Service بعداً بتواند به:

Web
PWA
Android APK
FCM

وصل شود.

ولی اگر FCM هنوز پیاده‌سازی نشده، mock یا fake production integration ایجاد نکن.

Integration point تمیز ایجاد کن.

Notification Preferences

به تنظیمات notification کاربر احترام بگذار.

Notificationهای mandatory و optional را تفکیک کن.

Assignment Confirmation

قبل از Assign خلاصه واضح بده:

Course:
Workplace Safety

Audience:
12 employees

Deadline:
September 10

Notifications:
Immediate + 3 days before deadline

Success State

بعد از Assignment:

Learning assigned successfully

12 learners assigned
12 notifications scheduled

اگر بخشی fail شده، partial failure را واضح گزارش کن.

Deadline Management

Manager در صورت Permission بتواند:

Extend deadline

Remove deadline

کند.

Bulk extension نیز در صورت نیاز واقعی.

Reminder Action

در Team / Assignment view:

Send reminder

وجود داشته باشد.

از duplicate notification جلوگیری کن.

Acceptance Criteria Phase 3

  • Assignment workflow ساده است.
  • Scope رعایت می‌شود.
  • Deadline management صحیح است.
  • Notification architecture آماده است.
  • Error و partial failure مدیریت می‌شود.
  • duplicate assignments کنترل شده.
  • tests وجود دارند.

بعد متوقف شو.

PHASE 4 — Skills, Insights, Reports & Approvals

هدف

Manager فقط Progress نبیند؛ بتواند تصمیم مدیریتی بگیرد.

Skills Dashboard

صفحه Skills برای Manager team-specific باشد.

نمایش:

Team skill level

Skill gaps

Improving skills

Critical gaps

Skill Visualization

مثلاً:

Communication     82%

Leadership        68%

Excel             54%

Safety            91%

عددها فقط اگر مدل داده واقعاً آنها را پشتیبانی می‌کند.

Skill Gap

Manager بتواند ببیند:

Skill

Required level

Current level

Gap

Affected employees

Learning Recommendation

اگر سیستم recommendation واقعی دارد:

Suggested learning

نمایش بده.

اگر ندارد، recommendation جعلی نساز.

در صورت امکان rule-based recommendation را جداگانه پیاده‌سازی کن.

Manager Insights

یک بخش:

بینش‌های این هفته

ایجاد کن.

Insights باید از داده واقعی derive شوند.

مثال:

Completion rate increased 8%

3 learners inactive for more than 7 days

Workplace Safety has the lowest completion rate

Communication is the largest team skill gap

No Fake AI

Insightهای ساده را به اسم AI نمایش نده.

اگر AI واقعاً تحلیل می‌کند، مشخص باشد.

اگر rule-based است، به‌عنوان Insight نمایش داده شود.

Reports

Manager Reportها باید team-scoped باشند.

پیشنهاد:

Team Learning Overview

Course Completion

Assignment Status

Assessment Performance

Skills Gap

Engagement

Filters

گزارش‌ها حداقل:

Date

Course

Learning Path

Employee

Team/Subteam

Status

در حد Permission مدیر.

Export

اگر سیستم export دارد:

Excel
CSV
PDF

Manager فقط داده Scope خودش را export کند.

Approvals

اگر Approval Workflow وجود دارد، صفحه:

تأییدها

فقط کارهای مربوط به Manager را نشان دهد.

مثلاً:

Learning request

Deadline extension

Course enrollment

Certificate approval

بسته به قابلیت واقعی محصول.

Approval UX

هر Approval:

Requester

Request

Reason

Date

Relevant context

Approve

Reject

Reject باید در صورت نیاز Reason داشته باشد.

Acceptance Criteria Phase 4

  • Skills team-scoped هستند.
  • Skill gaps واضح‌اند.
  • Insights actionable هستند.
  • Reportها team-scoped هستند.
  • Export امن است.
  • Approvals واضح و permission-aware هستند.
  • fake metric یا fake AI وجود ندارد.

بعد متوقف شو.

PHASE 5 — Responsive, Security, QA & Final Manager Polish

هدف

Manager Experience را برای Release آماده کن.

Responsive QA

حداقل viewportهای زیر:

375

430

768

1024

1280

1440

را بررسی کن.

Mobile Manager Experience

Mobile نباید نسخه shrink شده Desktop باشد.

Navigation:

Drawer

یا navigation مناسب role.

Dashboard روی موبایل:

Needs Attention
↓
Quick Actions
↓
KPIs
↓
Team
↓
Deadlines

اولویت اطلاعات را تغییر بده.

Tables

در Mobile صرفاً horizontal scroll ایجاد نکن.

از:

Column priority

Card representation

Expandable row

استفاده کن.

Quick Actions on Mobile

Manager باید بتواند از گوشی:

View team

Send reminder

Assign course

Review approval

Check progress

را انجام دهد.

Accessibility

بررسی کن:

Keyboard

Focus

ARIA

Labels

Dialogs

Drawers

Tables

Forms

Color contrast

RTL

Screen reader semantics

Security Recheck

دوباره بررسی کن:

IDOR

Role escalation

Team scope bypass

URL manipulation

API parameter manipulation

Export leakage

Frontend hiding را Security Control محسوب نکن.

Performance

Manager Dashboard ممکن است چند Widget داشته باشد.

بررسی کن:

duplicate API requests

N+1 backend queries

large payloads

unnecessary polling

over-fetching

unnecessary renders

برای Dashboard در صورت نیاز endpoint تجمیعی بهینه طراحی کن، اما فقط اگر bottleneck واقعی وجود دارد.

Loading States

از Skeleton استفاده کن.

هر Widget باید:

Loading

Empty

Error

Success

داشته باشد.

خرابی یک Widget نباید کل Dashboard را از کار بیندازد مگر dependency واقعی وجود داشته باشد.

RTL / LTR

فارسی:

RTL

انگلیسی:

LTR

Table alignment، icons، arrows و breadcrumbs را بررسی کن.

Dark Mode

تمام Manager pages را بررسی کن.

به‌خصوص:

Charts

Tables

Status badges

Empty states

Filters

Dialogs

Final Test Flow

حداقل این Scenarioها را اجرا کن.

Scenario 1

Manager Login
→
Dashboard
→
View Needs Attention
→
Employee
→
Send Reminder

Scenario 2

Manager
→
My Team
→
Employee
→
Learning Profile

Scenario 3

Manager
→
Assign Learning
→
Whole Team
→
Set Deadline
→
Notify
→
Confirm

Scenario 4

Manager
→
Skills
→
Skill Gap
→
Affected Employees

Scenario 5

Manager
→
Reports
→
Filter
→
Export

Scenario 6

Manager
→
Approvals
→
Review
→
Approve / Reject

Unauthorized Tests

تست کن Manager نتواند:

open other team's employee

read other team's progress

assign learning to unauthorized user

access admin settings

access Builder

access AI Studio unless explicitly permitted

export organization-wide data

Final Quality Gate

Frontend:

npm run lint
npm run typecheck
npm test
npm run build

Backend:

php artisan test

و تست‌های authorization مربوط به Manager را حتماً اجرا کن.

Final Report

در انتهای Phase 5 گزارش بده.

Manager Architecture

چه چیزهایی تغییر کرده؟

Permissions

چه محدودیت‌هایی اضافه یا اصلاح شده؟

Dashboard

چه تغییراتی انجام شده؟

My Team

چه تغییراتی انجام شده؟

Assignments

چه تغییراتی انجام شده؟

Notifications

چه چیزی آماده یا پیاده‌سازی شده؟

Skills

چه تغییراتی انجام شده؟

Reports

چه تغییراتی انجام شده؟

Approvals

چه تغییراتی انجام شده؟

Responsive

چه تغییراتی انجام شده؟

Security

چه مواردی بررسی یا اصلاح شده؟

Test Results

Backend:

Tests:
Assertions:
Failures:

Frontend:

Test Files:
Tests:
Lint:
Typecheck:
Build:

Remaining Manager Technical Debt

فقط مشکلات واقعی باقی‌مانده را ثبت کن.

Severity:

High

Medium

Low

Manager Experience Score

به موارد زیر از 10 امتیاز بده:

Navigation

Dashboard

Team Management

Learning Assignment

Notifications

Skills

Reports

Approvals

Mobile UX

Accessibility

Security

Performance

و در نهایت:

Manager Experience Score: XX/100

اجرای دقیق فازها

PHASE 0
Role & Permission Audit
        ↓
PHASE 1
Manager Shell & Dashboard
        ↓
PHASE 2
My Team & Learning Profiles
        ↓
PHASE 3
Assignments, Deadlines & Notifications
        ↓
PHASE 4
Skills, Insights, Reports & Approvals
        ↓
PHASE 5
Responsive, Security & Final QA

قانون آخر

هر Phase را کامل کن.

Test کن.

git diff را بررسی کن.

فایل‌های تغییرکرده را گزارش بده.

Regressionها را رفع کن.

سپس متوقف شو.

بدون دستور صریح من وارد Phase بعد نشو.

SUPPLEMENTARY PROMPT

MicroLearning — Learner Android APK + Native Push Notifications + Manager PWA Notifications

این Prompt مکمل Promptهای قبلی Learner و Manager است.

قوانین Safety، Scope Lock، Minimum Necessary Change، Regression Testing و Working Code Is Sacred که در Promptهای اصلی تعریف شده‌اند، همچنان لازم‌الاجرا هستند.

هیچ بخش سالمی صرفاً برای اجرای این قابلیت‌ها بازنویسی نشود.

PART A — LEARNER PROMPT EXTENSION

Prompt فعلی Learner دارای Phase 0 تا Phase 5 است.

دو Phase جدید زیر را بعد از Phase 5 اضافه کن:

PHASE 6
Android APK with Capacitor

PHASE 7
Native Push Notifications with Firebase Cloud Messaging

ترتیب نهایی Learner:

PHASE 0
Critical Stabilization
        ↓
PHASE 1
Learning Paths + Resume
        ↓
PHASE 2
Course Player + Assessments
        ↓
PHASE 3
Offline + PWA
        ↓
PHASE 4
Progress + Certificates + Notifications
        ↓
PHASE 5
APK Readiness + QA
        ↓
PHASE 6
Android APK with Capacitor
        ↓
PHASE 7
FCM Native Push Notifications

PHASE 6 — Android Learner APK with Capacitor

هدف

Learner PWA فعلی را بدون ایجاد Frontend جدید به Android Application واقعی تبدیل کن.

قانون معماری:

ONE LEARNER SOURCE CODE

React Learner
      │
      ├── Web
      ├── PWA
      └── Capacitor Android

به هیچ عنوان یک React App، Flutter App یا Android UI مستقل برای Learner نساز.

1. Capacitor Integration

نسخه‌های dependencyهای فعلی را بررسی کن و نسخه سازگار Capacitor را انتخاب کن.

Dependency upgrade unrelated انجام نده.

Android Platform را به پروژه اضافه کن.

ساختار باید به‌صورت استاندارد باشد:

frontend/
  src/
  dist/
  capacitor.config.*
  android/

از build output فعلی Vite استفاده کن.

2. Learner-Only Android Experience

APK باید تجربه Learner را ارائه کند.

نباید به‌صورت پیش‌فرض navigation مربوط به:

Super Admin
Course Designer
Course Builder
AI Studio
Platform Administration

نمایش دهد.

اگر همان User چند Role دارد، رفتار را از architecture واقعی Role Switching پروژه استخراج کن.

امنیت را فقط با مخفی کردن menu پیاده‌سازی نکن.

Backend authorization همچنان Source of Truth است.

3. API Configuration

هیچ URL مانند:

localhost
127.0.0.1

در Production APK hard-code نشود.

Environmentهای واقعی را پشتیبانی کن:

Development
Staging
Production
On-Premise

Configuration باید از روش استاندارد پروژه گرفته شود.

4. On-Premise Support

MicroLearning ممکن است روی Server داخلی سازمان نصب شود.

Android App باید بتواند به Endpoint سازمان متصل شود.

Architecture را طوری طراحی کن که Server/Base URL قابل configuration امن باشد اگر Business Model پروژه نیاز دارد.

Validation انجام بده:

HTTPS preferred
Valid hostname
No malformed URL
Connection test

در Production اتصال insecure را بدون تصمیم صریح Business/Security مجاز نکن.

5. Authentication

Authentication فعلی را برای Capacitor بررسی کن.

Token/Session نباید در storage ناامن نگهداری شود.

بررسی کن:

Login
Logout
Session expiry
Token refresh if applicable
401 handling
Multiple accounts
Organization context

بعد از Logout داده Authentication و داده خصوصی local پاک یا isolate شود.

6. Native Back Button

Android Back Button باید رفتار طبیعی داشته باشد.

مثلاً:

Course Player
→ Previous App Screen

Drawer Open
→ Close Drawer

Modal Open
→ Close Modal

نباید با اولین Back کل App بسته شود.

در Root Screen در صورت لزوم رفتار native مناسب داشته باش.

7. Deep Linking Foundation

زیرساخت Deep Link ایجاد کن.

هدف:

microlearning://learning/{assignmentId}

و ترجیحاً:

microlearning://learning/{assignmentId}/lesson/{lessonId}

در صورت استفاده از App Links:

https://learn.example.com/app/...

نیز architecture آماده باشد.

Deep Link باید بعد از Authentication به destination صحیح منتقل شود.

8. Native Safe Areas

بررسی کن:

Status Bar
Navigation Bar
Display Cutout
Notch
Gesture Area
Keyboard

UI نباید زیر عناصر system قرار بگیرد.

CSS safe-area را برای:

env(safe-area-inset-top)
env(safe-area-inset-bottom)

در صورت نیاز صحیح استفاده کن.

9. Android Keyboard

روی:

Login
Notes
Discussion
Assessment
Search
Forms

بررسی کن Keyboard باعث مخفی شدن input یا CTA نشود.

10. External Links

External URLها را audit کن.

تصمیم واضح داشته باش:

Internal route
→ App

External trusted URL
→ System browser

رفتار ناخواسته WebView ایجاد نکن.

11. Downloads

این موارد را بررسی کن:

Certificates
Documents
Course resources

اگر download در Web کار می‌کند، رفتار Android را نیز تست کن.

برای Certificate باید حداقل امکان:

Open
Download
Share

در صورت پشتیبانی platform وجود داشته باشد.

12. Sharing

برای موارد مناسب abstraction ایجاد کن:

Certificate
Course link
Achievement

در Android از Native Share در صورت نیاز استفاده کن و Web fallback حفظ شود.

13. Network Awareness

App باید وضعیت شبکه را تشخیص دهد.

Stateهای حداقل:

Online
Offline
Reconnecting

Offline Learning Phase 3 باید همچنان کار کند.

Capacitor integration نباید Offline/PWA architecture را خراب کند.

14. Splash Screen

Splash Screen حرفه‌ای ولی کوتاه باشد.

از نمایش Splash طولانی و مصنوعی جلوگیری کن.

Branding موجود پروژه را reuse کن.

15. App Icon

Android launcher icon و adaptive icon استاندارد ایجاد کن.

از asset برند فعلی MicroLearning استفاده کن.

Icon جدید unrelated طراحی نکن مگر asset مناسب موجود نباشد.

16. Status Bar

Status Bar با:

Light Theme
Dark Theme

هماهنگ شود.

17. PWA Must Continue Working

بعد از اضافه شدن Capacitor این موارد نباید خراب شوند:

Web
PWA Install
Service Worker
Offline Downloads
Responsive UI
Desktop Learner

APK نباید باعث fork شدن codebase شود.

18. Android Build

Debug APK بساز.

در صورت آماده بودن signing configuration، release build architecture را نیز آماده کن.

Secret signing key را commit نکن.

19. GitHub Actions Readiness

در صورت وجود GitHub Actions، pipeline جدا برای Android ایجاد کن یا readiness آن را اضافه کن.

هدف آینده:

Frontend Test
↓
Frontend Build
↓
Capacitor Sync
↓
Android Build
↓
APK Artifact

اما CI موجود را بدون ضرورت بازنویسی نکن.

PHASE 6 ACCEPTANCE CRITERIA

Phase 6 فقط وقتی Complete است که:

React Web works
PWA works
Android project builds
APK installs
Login works
Learner Home works
Course Player works
Assessments work
Resume works
Offline works
Certificates work
Android Back works
Dark Mode works
RTL works
LTR works

و هیچ Frontend دوم ایجاد نشده باشد.

PHASE 7 — Native Push Notifications with FCM

هدف

Learner Android App باید Notification واقعی Android دریافت کند.

حتی وقتی App در foreground نیست.

Architecture مقصد:

MicroLearning Backend
        ↓
Notification Domain Event
        ↓
Notification Service
        ↓
Laravel Queue
        ↓
Firebase Cloud Messaging
        ↓
Android App
        ↓
Native Android Notification

1. Notification Architecture

Notification logic را داخل Controllerها پراکنده نکن.

Architecture ترجیحی:

Domain Event
↓
Notification Orchestrator
↓
Channel

Channelها:

InAppChannel
PushChannel
EmailChannel

Web Push در آینده قابل اضافه شدن باشد.

2. Device Registration

Backend باید Deviceهای User را مدیریت کند.

مدل مناسب طراحی کن.

مثلاً:

user_devices

فیلدهای منطقی:

id
user_id
organization_id
platform
device_identifier
push_token
enabled
last_seen_at
created_at
updated_at

نام نهایی را با conventions پروژه هماهنگ کن.

3. Multiple Devices

یک User ممکن است:

Phone
Tablet
Second Phone

داشته باشد.

Notification architecture باید Multiple Device را پشتیبانی کند.

4. Token Registration

بعد از دریافت FCM Token:

Android App
↓
Authenticated API
↓
Register Device Token

Backend ownership را verify کند.

5. Token Refresh

FCM Token ممکن است تغییر کند.

Token refresh باید به Backend sync شود.

Duplicate token ایجاد نکن.

6. Logout

هنگام Logout:

Device registration مربوطه disable یا unregister شود.

User قبلی نباید Notification User جدید را دریافت کند.

7. Android 13+ Permission

برای Androidهایی که Permission لازم دارند:

POST_NOTIFICATIONS

را صحیح مدیریت کن.

Permission را بلافاصله و بدون context درخواست نکن.

UX پیشنهادی:

اعلان‌های یادگیری را فعال کنید

مهلت دوره‌ها، آموزش‌های جدید و
گواهی‌های صادرشده را از دست ندهید.

[فعال کردن اعلان‌ها]
[بعداً]

از Dialog/Component استاندارد پروژه استفاده کن.

8. Notification Channels

Android Notification Channels ایجاد کن.

حداقل:

Learning
Deadlines
Certificates
System

در صورت نیاز:

Assignments
Reminders

اما Channelهای بسیار زیاد نساز.

9. Learner Notification Types

حداقل Eventهای زیر را بررسی و در صورت support Backend پیاده‌سازی کن:

Course Assigned
Learning Path Assigned
Mandatory Learning Assigned

Deadline Approaching
Due Today
Overdue

Continue Learning Reminder

Assessment Available

Course Completed

Certificate Issued

Important Organization Announcement

10. Notification Preferences

به Preference واقعی User احترام بگذار.

مثلاً:

New assignments
Deadline reminders
Daily reminders
Certificates
Organization announcements

Notificationهای security/critical system در صورت Business Rule می‌توانند سیاست متفاوت داشته باشند.

11. Scheduled Reminders

Reminderها از queue/scheduler ارسال شوند.

برای مثال:

3 days before deadline
1 day before deadline
Due today
Overdue

از Request synchronous برای ارسال bulk notification استفاده نکن.

12. Duplicate Protection

یک Notification نباید به دلیل Retry Queue چندبار برای یک Event ارسال شود.

Idempotency مناسب ایجاد کن.

مثلاً بر اساس:

user
event
assignment
notification type
scheduled window

13. Deep Link on Notification Tap

هر Push باید در صورت نیاز مقصد داشته باشد.

مثلاً:

Course Assigned

Notification
↓
My Learning
↓
Course

Deadline

Notification
↓
Assignment
↓
Resume Lesson

Certificate

Notification
↓
My Certificates
↓
Certificate

14. Foreground Behavior

اگر App باز است، Notification نباید UX آزاردهنده ایجاد کند.

در صورت مناسب بودن:

In-app banner / toast

و در background:

Native notification

15. Notification History

Push Notification باید در صورت منطقی بودن با Notification Center داخل App هماهنگ باشد.

یعنی Notification دریافت‌شده فقط ephemeral نباشد.

User بتواند بعداً در:

Notifications

آن را مشاهده کند.

16. Read / Unread

Notification Center:

Unread
Read
Mark as read
Mark all as read

داشته باشد در صورت support فعلی.

17. Security

هر Notification Payload را حداقل‌گرا نگه دار.

Sensitive data را مستقیماً داخل Push Payload قرار نده.

مثلاً اطلاعات خصوصی ارزیابی یا اطلاعات حساس Employee ارسال نشود.

Push فقط context identifier امن ارسال کند و App داده اصلی را از API مجاز دریافت کند.

18. FCM Credentials

Firebase credential:

.env
Secret Manager
Server Configuration

باشد.

هیچ:

Private Key
Server Key
Service Account Secret

در repository commit نشود.

19. Failure Handling

FCM responseها را مدیریت کن.

برای Tokenهای:

Invalid
Expired
Unregistered

Device token را disable/remove کن.

20. Observability

حداقل بتوانیم بفهمیم:

Queued
Sent to FCM
Failed
Invalid token

ولی Delivery قطعی را اگر FCM چنین اطلاعاتی نداده، جعلی نمایش نده.

21. Push Tests

حداقل تست:

User A notification
→ User A devices only

User B
→ Must not receive User A notification

Disabled preference
→ Optional notification not sent

Invalid token
→ Safely disabled

Logout
→ Device no longer receives private push

Notification tap
→ Correct deep link

PHASE 7 ACCEPTANCE CRITERIA

Phase 7 زمانی Complete است که:

FCM connected
Device registration works
Token refresh works
Logout cleanup works
Android permission works
Native notification works
Background notification works
Notification channels work
Preferences work
Deep linking works
Duplicate push protection works
Notification center stays consistent
Security tests pass

LEARNER FINAL QUALITY GATE — UPDATED

پس از Phase 7 حتماً این Flow را تست کن:

Learner Login
↓
Device Registered
↓
Course Assigned
↓
App Closed
↓
Native Notification Received
↓
Tap Notification
↓
App Opens
↓
Correct Course
↓
Correct Resume Location

و:

Deadline Reminder
↓
Native Notification
↓
Tap
↓
Assignment
↓
Continue Learning

و:

Course Complete
↓
Certificate Issued
↓
Native Notification
↓
My Certificates

UPDATED LEARNER RELEASE STATUS

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

NOT READY

PWA PRODUCTION READY

ANDROID DEBUG READY

ANDROID RELEASE READY WITH CONDITIONS

ANDROID PRODUCTION READY

PART B — MANAGER PROMPT EXTENSION

Prompt Manager فعلی Phase 0 تا Phase 5 دارد.

یک Phase جدید اضافه کن:

PHASE 6
Manager PWA & Push/Web Notification Experience

ترتیب نهایی:

PHASE 0
Role & Permission Audit
        ↓
PHASE 1
Manager Shell & Dashboard
        ↓
PHASE 2
My Team & Learning Profiles
        ↓
PHASE 3
Assignments, Deadlines & Notifications
        ↓
PHASE 4
Skills, Insights, Reports & Approvals
        ↓
PHASE 5
Responsive, Security & Final QA
        ↓
PHASE 6
Manager PWA & Notifications

PHASE 6 — Manager PWA & Notification Experience

هدف

Manager Panel علاوه بر Desktop/Web، روی موبایل نیز به‌صورت PWA قابل استفاده باشد.

برای Manager فعلاً Android APK مستقل نساز.

Architecture:

Manager React Experience
        ↓
Web
+
Installable PWA

1. PWA Availability

Manager بتواند در browserهای پشتیبانی‌شده PWA را Install کند.

PWA Shell باید Role-aware باشد.

وقتی Manager وارد می‌شود:

Manager Dashboard

نمایش داده شود، نه Learner Home.

2. Role Combination

اگر Manager خودش Learner هم هست، Role Switching یا Experience Switching فعلی پروژه را بررسی کن.

راه‌حل جدید duplicate نساز.

در صورت وجود switching استاندارد:

Manager Mode
Learner Mode

را حفظ کن.

3. Manager Mobile Priorities

PWA Manager روی موبایل باید حداقل این Actions را عالی پشتیبانی کند:

View Needs Attention
View My Team
View Employee Learning
Send Reminder
Assign Learning
Review Deadline
Approve Request
View Team Progress

Course Builder و Admin Toolهای unrelated را وارد PWA Manager نکن.

4. Manager In-App Notifications

Notification Center برای Manager category-aware باشد.

نمونه:

Team Learning
Deadlines
Approvals
Skill Alerts
Reports
System

5. Manager Notification Events

در صورت وجود داده واقعی، Manager بتواند Notification دریافت کند برای:

Team member overdue

Mandatory course not started

Team deadline approaching

Approval requested

Learning request received

Assignment completed

Critical skill gap alert

Weekly learning summary ready

Insight ساده را بی‌دلیل Push نکن.

Notification fatigue ایجاد نکن.

6. Immediate vs Digest

همه Eventها Push فوری نباشند.

تقسیم‌بندی منطقی:

Immediate:
Critical overdue
Approval needing action
Important assignment issue

Digest:
Team learning summary
Weekly progress
General insights

7. Manager Notification Preferences

Manager بتواند تنظیم کند:

Team deadline alerts
Overdue alerts
Approval requests
Learning activity
Weekly summary

8. Web Push

اگر infrastructure Web Push پروژه آماده و قابل اتکا است، Manager PWA بتواند Web Push واقعی دریافت کند.

اگر هنوز زیرساخت Web Push وجود ندارد:

Fake implementation ایجاد نکن.

Architecture Notification Channel را طوری نگه دار که Web Push بعداً اضافه شود.

9. Shared Notification Backend

Notification Business Rules را بین:

Learner APK
Manager PWA
In-App Notification Center

duplicate نکن.

Architecture:

Domain Event
        ↓
Notification Service
        ↓
Recipient Resolution
        ↓
Preferences
        ↓
Channels

Channels:

In-App
FCM
Web Push
Email

باید قابل توسعه باشند.

10. Manager Assignment Notification Integration

وقتی Manager در Phase 3 دوره‌ای تخصیص می‌دهد:

Manager
↓
Assign Course
↓
Learners
↓
Notification Event
↓
In-App + FCM according to preference

در صورت APK Learner.

Manager نباید خودش مستقیم FCM API را فراخوانی کند.

11. Manager Reminder Action

Action:

Send Reminder

باید از همان Notification Service استفاده کند.

نه implementation جداگانه.

قبل از ارسال bulk reminder خلاصه نشان بده:

12 learners
Course: Workplace Safety
Channel:
In-App + Push

[Send Reminder]

12. Rate / Spam Protection

Manager نباید بتواند ناخواسته پشت سر هم Pushهای مشابه برای یک Team ارسال کند.

برای Reminder:

cooldown
duplicate detection
authorization

در نظر بگیر.

13. Team Scope

Notification recipientها حتماً Backend-scoped باشند.

Manager با دستکاری Request نباید بتواند برای افراد خارج از Team مجاز خودش Push ارسال کند.

14. Notification Audit

عملیات مهم Manager مثل:

Bulk reminder sent
Assignment notification triggered
Deadline changed

در صورت وجود Audit architecture ثبت شود.

15. PWA Responsive QA

بررسی:

360
375
390
430
768

Manager PWA روی mobile نباید desktop table shrink شده باشد.

MANAGER PHASE 6 ACCEPTANCE CRITERIA

Manager PWA installable
Manager route correct
Mobile dashboard works
Team actions work
Notifications permission-aware
Reminder action uses shared service
Team scope enforced
Duplicate reminder protection works
Learner FCM integration compatible
No separate Manager APK created

PART C — SHARED NOTIFICATION ARCHITECTURE

این بخش برای هر دو Prompt الزامی است.

نباید برای Manager و Learner دو سیستم Notification جدا ساخته شود.

Architecture مقصد:

                 MicroLearning
                      │
              Domain/Application Events
                      │
              Notification Service
                      │
          ┌───────────┼───────────┐
          │           │           │
       In-App        Push        Email
                      │
             ┌────────┴────────┐
             │                 │
            FCM             Web Push
             │                 │
       Learner APK        Manager PWA

Recipient Resolution

Notification Service باید خودش مشخص کند Recipient چه کسی است.

مثلاً:

Course Assigned
→ Learner

Deadline approaching
→ Learner

Employee overdue
→ Authorized Manager

Approval requested
→ Manager

Preferences

Flow:

Event
↓
Recipient
↓
Permission / Scope
↓
Notification Preference
↓
Channel
↓
Queue
↓
Delivery

Queue First

ارسال Notificationهای خارجی را synchronous داخل user request انجام نده.

از Queue استفاده کن.

Failure FCM/Web Push نباید عملیات اصلی مثل:

Assign Course
Complete Course
Issue Certificate

را rollback کند مگر business rule صریحی وجود داشته باشد.

Notification Taxonomy

یک taxonomy استاندارد داشته باش.

مثلاً:

learning.assigned
learning.reminder
learning.deadline_soon
learning.overdue
learning.completed

assessment.available

certificate.issued

manager.approval_requested
manager.team_overdue
manager.weekly_summary

system.announcement

Naming را با conventions فعلی پروژه تطبیق بده.

Notification Payload

Payload استاندارد داشته باش:

type
title
body
recipient
entityType
entityId
deepLink
createdAt

Sensitive information اضافه نکن.

Shared Deep Links

Learner:

/course
/lesson
/certificate
/notification

Manager:

/team/member
/assignment
/approval
/report

هم Web و هم Native باید از destination منطقی مشترک استفاده کنند.

FINAL SAFETY RULE

برای اضافه کردن Capacitor، FCM یا PWA Notification:

هیچ‌یک از فازهای قبلی را دوباره Refactor نکن مگر integration واقعاً به تغییر آن نیاز داشته باشد.

اگر integration نیازمند تغییر گسترده شد:

STOP

و قبل از ادامه گزارش بده:

Integration blocker:
Why:
Affected modules:
Risk:
Minimum viable fix:
Alternative:

UPDATED EXECUTION ORDER

ترتیب پیشنهادی نهایی برای این دو بخش:

LEARNER PHASE 0–5
        ↓
LEARNER PHASE 6
Android APK
        ↓
LEARNER PHASE 7
FCM Push
        ↓
MANAGER PHASE 0–5
        ↓
MANAGER PHASE 6
PWA + Manager Notifications

اگر Manager Phaseهای 0–5 قبلاً انجام شده‌اند، مستقیماً Phase 6 را اجرا کن.

هیچ Phase را بدون دستور صریح من شروع نکن. پس از هر Phase تست کن، گزارش بده و متوقف شو.