Motoshub · Delivery Plan · Front + Backend

برنامه‌ی تحویل: تسک‌های تیم Front و Backend

نقشه‌ی اجراییِ ساختِ محصولِ واقعی تا رسیدن به همین پروتوتایپ (demo.shub.ir). هر تسک شکسته‌شده به subtask، هر تسک و subtask دارای تخمینِ زمانی، مرتب‌شده بر اساس فاز و اولویت، با شرحِ فنیِ دقیق، User Story و معیارهای پذیرش.

مبنا: خواندنِ کاملِ سه ریپو — motoshub-prototype (هدف)، motoshub-web-client (Front/Next.js)، motoshub-new-api (Backend/Django). واحد تخمین: روزِ‌نفر (۱ روز = ۸ ساعت مفید).

راهنمای خواندن

وضعیت: انجام‌شدهکار می‌کند ناقصUI هست، داده mock نساختهاصلاً وجود ندارد

اولویت: P1پایه/بحرانی P2مهم P3تکمیلی تخمین:۳ روزمجموعِ subtaskها

شناسه‌گذاری ساختار را رمزگذاری می‌کند: F=Front، B=Backend، عدد اول = ترتیب اجرا. subtaskها با .1 .2 .3. تخمین‌ها برای یک توسعه‌دهنده‌ی میان‌ردهٔ آشنا با استک.

به‌روزرسانی ۱۴۰۵/۰۴/۳۱: (۱) بخش جدید «پایپ‌لاین تحویل و کیفیت» اضافه شد — عبور از آن برای هر تسکِ هر دو تیم الزامی است. (۲) جدول «سناریوهای اندازه‌ی تیم» به خلاصه اضافه شد. (۳) پروتوتایپِ هدف (demo.shub.ir) برای پوششِ کاملِ ماژول‌های motoshub-web گسترش یافت: صفحات جدید دوستان و دنبال‌کردن (friends/follow)، نظرسنجی و آزمون (iisquestions/iispors)، مسابقات و چالش‌ها (iiscompetition/iischallenge) و تیکت پشتیبانی (iisticketing) — این‌ها UIِ مرجعِ تسک‌های F18/B15/B17/B18 هستند؛ تخمین‌ها همان‌اند.

خلاصه‌ی زمان‌بندی و فازها تصمیم‌های معماریِ الزام‌آور فاز ۰ — پایه و زیرساخت فاز ۱ — احراز هویت، پوسته، لایه‌ی داده فاز ۲ — هسته‌ی محتوا فاز ۳ — فضاهای اجتماعی فاز ۴ — ارتباط و همکاری فاز ۵ — ماژول‌های سازمانی فاز ۶ — راهبری، جستجو، پولیش و تحویل پایپ‌لاین تحویل و کیفیت منابع فنی

خلاصه‌ی زمان‌بندی و فازها

دو مسیرِ موازی. چون PHP api/v1 همین حالا هر ۲۹۳ عملیات را پاسخ می‌دهد، تیم Front از فاز ۱ به‌بعد به آن وصل می‌شود و منتظرِ Django نمی‌ماند؛ Backend به‌موازات همان قرارداد را در Django بازمی‌سازد و Gateway هر مسیرِ آماده را سوییچ می‌کند.

فاز	محتوا	Front	Backend	موازی
۰	پایه: axios/design-system · REST-infra/auth-JWT/deploy/data-model	۵.۵ روز	۱۲ روز	~۱۲ روز
۱	احراز هویت، پوسته و ناوبری، لایه‌ی داده · endpointهای auth + مدل‌ها	۹.۵ روز	۶ روز	~۱۰ روز
۲	هسته: داشبورد، تازه‌ها، بلاگ، کاربران/پروفایل	۱۷ روز	۱۶ روز	~۱۷ روز
۳	اجتماعی: گروه‌ها، اخبار، رویدادها، رسانه، فروم	۲۴ روز	۲۵ روز	~۲۵ روز
۴	ارتباط: چت، دانش، پروژه · پیام‌رسان، دوستان/اعلان، دانش/پروژه	۱۶ روز	۱۶ روز	~۱۶ روز
۵	سازمانی: قرارداد/صندوق/پژوهش/آموزش · نظرسنجی/مسابقات	۸ روز	۱۳ روز	~۱۳ روز
۶	راهبری، ظاهر، گزارش، اعلان، جستجو، راهنما، دستیار، پولیش، تست	۱۶ روز	۴ روز	~۱۶ روز
مجموع (تک‌نفره، بدون همپوشانی)		~۹۶ روز	~۹۲ روز	~۱۰۹ روز

تفسیرِ زمان. با ۲ توسعه‌دهنده‌ی Front + ۲ Backend و اجرای موازیِ فازها، بازه‌ی واقع‌بینانه‌ی رسیدن به پروتوتایپِ کامل حدود ۱۳ تا ۱۶ هفته‌ی کاری است. «حداقلِ محصولِ قابل‌نمایش» (فاز ۰ تا ۲) در حدود ۵ تا ۶ هفته به‌دست می‌آید. این اعداد تخمینی‌اند و باید در Planningِ هر Sprint دوباره کالیبره شوند.

سناریوهای اندازه‌ی تیم

ترکیب تیم	MVP (فاز ۰-۲)	پروتوتایپ کامل	ملاحظات
۱ Front + ۱ Backend	~۹-۱۰ هفته	~۲۲-۲۶ هفته	ارزان‌ترین؛ ریسک گلوگاه تک‌نفره و ریزش. توصیه نمی‌شود.
۲ Front + ۲ Backend (خط پایه)	۵-۶ هفته	۱۳-۱۶ هفته	ترکیب فعلی. هر فاز دو workstream موازی؛ review متقابل ممکن است.
۲F + ۲B + ۱ نفر QA/تست‌خودکار	۵-۶ هفته	۱۲-۱۴ هفته	زمان زیاد کم نمی‌شود اما دوباره‌کاری و باگِ برگشتی به‌شدت کم می‌شود؛ پیشنهاد PO.
۳ Front + ۳ Backend + QA	۴-۵ هفته	۹-۱۱ هفته	بازده نزولی: مسیر بحرانی (auth→چت realtime→گزارش) کوتاه‌تر از این نمی‌شود.
تیم واقعی: ۴F + ۳B + ۱QA + ۱DevOps	~۴ هفته	~۹-۱۱ هفته	ترکیب فعلی ما. DevOps تسک‌های B3/استقرار/CI را برمی‌دارد و Backend خالص فیچر می‌زند؛ QA از هفته‌ی ۱ گیت‌های ۸ و ۹ پایپ‌لاین را مالک است.

مسیر بحرانی مستقل از تعداد نفرات: فاز ۰ (زیرساخت) ← auth ← لایه‌ی داده ← ماژول‌های وابسته به فایل/اعلان ← چتِ بی‌درنگ ← پولیش. حداقل تقویمیِ عبوری از این زنجیره ~۹ هفته است؛ نفرِ اضافه فقط پهنای موازی را زیاد می‌کند، نه عمق زنجیره را. با تیم ۹ نفره، گلوگاه = Backend (۳ نفر / ~۸۰ روزنفرِ باقی‌مانده پس از واگذاری استقرار به DevOps).

تقسیم کار پیشنهادی تیم واقعی (workstreamهای پایدار — هر نفر مالک یک رشته)

نقش	مالکیت (رشته‌ی کاری ثابت)	تسک‌ها به ترتیب
Front ۱ (لید)	زیرساخت فرانت، auth، لایه‌ی داده، سپس چت	F1 → F3 → F5 → F15 → F20.5
Front ۲	پوسته/ناوبری + هسته‌ی محتوا	F2 → F4 → F6 → F7 → F8
Front ۳	فضاهای اجتماعی	F9 → F10 → F11 → F12 → F13 → F14
Front ۴	دانش/پروژه + ماژول‌های سازمانی + راهبری	F16 → F17 → F18 → F19 → F20.1-3
Backend ۱ (لید)	زیرساخت REST + auth مشترک + پیام‌رسان	B1 → B2 → B4 → B5 → B14
Backend ۲	هسته‌ی محتوا: کاربران/فید/بلاگ/اخبار	B6 → B7 → B8 → B9 → B15
Backend ۳	اجتماعی + سازمانی: گروه/رویداد/رسانه/فروم → دانش/پروژه → سازمانی	B10 → B11 → B12 → B13 → B16 → B17 → B18
QA	مالک گیت‌های ۸-۹ پایپ‌لاین: کالکشن Postman هر ماژول، تست قرارداد، E2E (Playwright) مسیرهای حیاتی، رگرسیون هفتگی	از هفته ۱ موازی با همه؛ B19.2 و F20.6 با اوست
DevOps	B3 کامل + CI enforcement + staging دو سرویس + مانیتورینگ/لاگ + بکاپ + سوییچ Gateway	B3 → CI هر دو ریپو → B19.3 → پایداری production

ریسک برنامه و پادزهر: (۱) Front چهارنفره زودتر از Backend تمام می‌کند (~هفته ۷) — از آن نقطه Front ۳ و ۴ به E2E/پولیش/دواپسِ فرانت شیفت می‌شوند، نه فیچرِ جدید. (۲) وابستگی همه به فاز ۰: هفته‌ی اول همه‌ی تمرکز دو لید + DevOps روی B1/B2/B3/F1/F2 است؛ بقیه در همان هفته کالکشن تست و شناخت قرارداد API را آماده می‌کنند. (۳) هر workstream مالک ثابت دارد تا context-switching حذف شود؛ جابه‌جایی فقط با تصمیم PO.

تصمیم‌های معماریِ الزام‌آور

پیش‌فرض‌هایی که هر دو تیم باید رعایت کنند تا کارها به هم برسند.

۱) مبدأ داده‌ی Front مستقل از پیاده‌ساز است. Front فقط با قراردادِ api/v1 کار می‌کند؛ نباید بداند پاسخ از PHP می‌آید یا Django. همه‌ی مسیرها از libs/axios.ts با baseURL=/api/v1 و rewrite در next.config.ts.

۲) auth واحد. استانداردِ توکن = JWT HS256 با رازِ مشترک OW_PASSWORD_PEPPER و claims {iat, exp, sub:userId}. Django باید همین را verify (و در فاز بعد صادر) کند، نه صرفاً خواندنِ ow_base_user_auth_token.

۳) قراردادِ پاسخ ثابت است. فهرست‌ها همیشه پاکتِ {data, links, meta} با meta.current_page/per_page/total؛ خطاها با کدهای 401/403/404/422 و بدنه‌ی یکسان. مرجعِ فیلدها: مرجع API و Swagger.

پایه و زیرساخت

پیش‌نیازِ هر چیزِ دیگر. بدون این‌ها هر تسکِ بعدی روی شن ساخته می‌شود. دو تیم موازی کار می‌کنند.

◆ تیم Front

F1یکپارچه‌سازی HTTP client و پاک‌سازی بدهیِ فنیP1ناقص۱.۵ روز

دو client موازی هست: libs/axios.ts (زنده) و services/apiClient.ts (مرده). باید یکی بماند، منبعِ همه‌ی درخواست‌ها شود و کدهای بلااستفاده حذف شوند.

Subtaskها

#	کار	جزئیات فنی	تخمین
F1.1	حذف client مرده	حذف `services/apiClient.ts`؛ انتقالِ ارجاع‌ها به `libs/axios.ts`	۲ ساعت
F1.2	حذف کد/وابستگیِ بلااستفاده	حذف `jsonwebtoken`، `social/homepage/`، `social/menu/`، `libs/routes.ts` کهنه	۳ ساعت
F1.3	پیکربندی پایه‌ی axios	تثبیت `baseURL/timeout`، هدرهای پیش‌فرض، اتصالِ توکن از store در request interceptor	۳ ساعت
F1.4	ESLint/type-check سبز	رفعِ importهای شکسته، اجرای `tsc --noEmit` و `lint`	۴ ساعت

وابستگی: ندارد (نقطه‌ی شروعِ Front).

F2سیستم طراحی، توکن‌های ظاهری و تمِ روشن/تیرهP1نساخته۴ روز

User Storyبه‌عنوان کاربر، می‌خواهم رابط با ظاهرِ یکدست، فارسی/RTL و قابلِ‌تعویض بین روشن/تیره ببینم، تا تجربه‌ی حرفه‌ای و خوانا داشته باشم.

themeی Tailwind خالی است. توکن‌های طراحیِ برگرفته از پروتوتایپ (رنگ/فاصله/شعاع/سایه/تایپ) و کامپوننت‌های پایه ساخته شوند. طبقِ اصولِ طراحی: مقیاسِ تایپِ مشخص و هویتِ منطبق بر دامنه‌ی سازمانی، نه پیش‌فرضِ جنریک.

EARS: هرگاه کاربر تمِ نمایش را تغییر دهد، سامانه باید کلِ رابط را بدون بارگذاری مجدد به تمِ انتخابی درآورد و انتخاب را ماندگار کند.

Subtaskها

#	کار	جزئیات فنی	تخمین
F2.1	استخراج توکن‌ها	استخراج پالت رنگ/فاصله/تایپ از پروتوتایپ → CSS variables + `tailwind.config`	۶ ساعت
F2.2	تایپوگرافی و فونت	مقیاس تایپ (وزن/عرض/فاصله)، فونت IRANYekan، RTL سراسری	۴ ساعت
F2.3	کامپوننت‌های پایه	Button/Input/Select/Modal/Card/Badge/Toast/Skeleton/Table با variantها	۱۲ ساعت
F2.4	تمِ روشن/تیره	mountِ `next-themes`، دو تم، سوییچرِ ماندگار، اجتناب از flash	۶ ساعت
F2.5	حالت‌های وضعیت	الگوهای loading/empty/error استاندارد	۴ ساعت

معیار پذیرش

Given تمِ تیره فعال، When صفحه رندر شود، Then همه‌ی کامپوننت‌ها رنگِ درست و کنتراستِ AA دارند.
Given تعویضِ تم، When رفرش شود، Then تمِ قبلی بدون پرشِ رنگ بازیابی شود.

وابستگی: F1.

◆ تیم Backend

B1زیرساختِ REST مشترک (پاکت، صفحه‌بندی، خطا، CORS، آپلود)P1نساخته۴ روز

قبل از هر منبع، لایه‌های عرضیِ DRF باید ساخته شوند تا همه‌ی endpointها دقیقاً قراردادِ PHP را بدهند. الان هیچ‌کدام وجود ندارد.

EARS: هرگاه یک درخواستِ فهرست پردازش شود، سامانه باید پاسخ را در پاکتِ {data, links, meta} با meta.current_page/per_page/total بازگرداند.

Subtaskها

#	کار	جزئیات فنی	تخمین
B1.1	Pagination class	`PageNumberPagination` سفارشی با خروجیِ دقیقِ `data/links/meta`	۵ ساعت
B1.2	Exception handler	هندلرِ سراسری برای فرمتِ یکسانِ خطا در ۴۰۱/۴۰۳/۴۰۴/۴۲۲	۵ ساعت
B1.3	فیلتر/جستجو/مرتب‌سازی	backendهای مشترک با نام‌پارامترهای یکسان با PHP	۶ ساعت
B1.4	CORS و هدرها	نصب/پیکربندی `django-cors-headers` (نصب نیست)، هدرهای امنیتی	۳ ساعت
B1.5	آپلود فایل/رسانه	`MultiPartParser`، اعتبارسنجی نوع/اندازه، مسیرِ سازگار با اکسوال	۶ ساعت
B1.6	پایه‌ی تست	راه‌اندازی `pytest-django` + factory + APIClient مبنا	۵ ساعت

وابستگی: ندارد (نقطه‌ی شروعِ Backend).

B2استراتژیِ auth واحد PHP↔Django (JWT مشترک)P1نساخته۳ روز

بلوکِ SIMPLE_JWT در config/settings/base.py نیست. Django باید همان JWT HS256 با رازِ مشترک و claimهای اکسوال را verify کند تا توکنِ PHP در Django معتبر باشد و بالعکس.

Subtaskها

#	کار	جزئیات فنی	تخمین
B2.1	پیکربندی SimpleJWT	HS256، `SIGNING_KEY = sha256(OW_PASSWORD_PEPPER)`، claim `sub`→userId، طولِ عمرِ منطبق	۶ ساعت
B2.2	Authentication class	کلاسِ سفارشیِ DRF: verify JWTِ PHP و resolve کاربرِ legacy	۶ ساعت
B2.3	Permission mapping	ترجمه‌ی مجوزِ پلاگینیِ اکسوال (`isAuthorized`) به permissionهای DRF	۶ ساعت
B2.4	تستِ سازگاری متقابل	توکنِ رازِ PHP در Django بپذیرد؛ بدون‌امضا/منقضی رد شود	۶ ساعت

معیار پذیرش

Given یک JWTِ معتبرِ PHP، When به endpointِ محافظت‌شده‌ی Django فرستاده شود، Then ۲۰۰ و همان کاربر resolve شود.
Given توکنِ منقضی/دست‌کاری‌شده، When فرستاده شود، Then ۴۰۱ برگردد.

وابستگی: B1. مرجع: معماری — بخش auth.

B3رفعِ خطاهای استقرار و پیکربندیِ productionP1نساخته۲ روز

production.py خالی است؛ docker/Dockerfile ENTRYPOINT اشتباه دارد (shub.asgi، Celery SharifAutoEDA — کپی از پروژه‌ی دیگر)؛ requirements فاقد gunicorn/uvicorn/pytest است.

Subtaskها

#	کار	جزئیات فنی	تخمین
B3.1	production.py	DEBUG=False، ALLOWED_HOSTS، DB از env، static/media، logging	۴ ساعت
B3.2	Dockerfile	اصلاحِ ENTRYPOINT، حذف ارجاعِ Celery غلط، multi-stage تمیز	۴ ساعت
B3.3	requirements و env	افزودن gunicorn/uvicorn/pytest؛ اصلاحِ `.env.example` برای دو DB	۳ ساعت
B3.4	healthcheck و اجرای محلی	تأیید بالاآمدنِ کانتینر، `/api/v1/health`، اتصالِ دو DB	۵ ساعت

وابستگی: مستقل؛ موازیِ B1/B2.

احراز هویت، پوسته و لایه‌ی داده

دروازه‌ی ورود و اسکلتِ همه‌ی صفحه‌های بعدی. تا اینجا تمام نشود، هیچ صفحه‌ی محتوایی قابلِ‌اتکا نیست.

◆ تیم Front

F3جریان کاملِ احراز هویت: refresh، محافظتِ مسیر، logoutP1ناقص۳.۵ روز

User Storyبه‌عنوان عضو سازمان، می‌خواهم یک‌بار وارد شوم و نشستم بی‌آنکه مدام بیرون بیفتم حفظ شود، و مسیرهای خصوصی بدونِ ورود در دسترس نباشند، تا کارم امن و بی‌وقفه باشد.

login/register هست ولی response interceptor در libs/axios.ts no-op است، logout در useAuth.ts صرفاً stub است و هیچ middleware.tsای مسیرها را محافظت نمی‌کند.

EARS: هرگاه یک درخواستِ API با ۴۰۱ برگردد و refresh معتبر باشد، سامانه باید توکن را نو و همان درخواست را یک‌بار تکرار کند؛ در غیر این‌صورت کاربر را به ورود هدایت کند.

Subtaskها

#	کار	جزئیات فنی	تخمین
F3.1	منطق refresh	interceptor: بر ۴۰۱ فراخوانیِ `POST /auth/refresh`، صف‌بندیِ همزمان، retry یک‌باره، خروج بر شکست	۸ ساعت
F3.2	middleware مسیر	`middleware.ts` گاردِ `/workspace/` و `/social/`؛ ریدایرکتِ مهمان به `/login?next=`	۵ ساعت
F3.3	logout واقعی	ابطالِ سمتِ سرور، پاک‌سازیِ store و توکن‌ها، ریدایرکت	۳ ساعت
F3.4	هیدریشنِ نشست	بازخوانیِ کاربر از `GET /auth/me` در بوت، همگام‌سازی با store پایدار	۴ ساعت
F3.5	ثبت‌نام و خطاها	اتصالِ فرمِ register، نمایشِ خطاهای ۴۲۲ فیلدی، loading	۴ ساعت
F3.6	تغییر رمز	UIِ `PATCH /auth/change-password` (endpoint هست)	۴ ساعت

معیار پذیرش

Given نشستِ منقضی، When کاربر عملی انجام دهد، Then توکن بی‌صدا نو و عمل بدونِ خروج ادامه یابد.
Given مهمان، When /workspace باز شود، Then به /login با پارامترِ بازگشت هدایت شود.

وابستگی: F1؛ داده: B4 (تا آماده‌شدن به PHP /auth/* وصل شود).

F4پوسته‌ی برنامه: چیدمان، سایدبار، هدر و ناوبریP1ناقص۳ روز

User Storyبه‌عنوان کاربر، می‌خواهم منوی کناریِ همه‌ی بخش‌ها، نوارِ بالا با پروفایل/اعلان/جستجو و مسیرِ فعال را ببینم، تا در ~۲۰ بخشِ محصول به‌راحتی جابه‌جا شوم.

پروتوتایپ سایدباری با ~۲۰ برچسب دارد (components/Sidebar.tsx). پوسته‌ی واکنش‌گرا با active-state، حالتِ موبایل و اسلاتِ محتوا ساخته شود تا صفحه‌های بعدی داخلش بنشینند.

Subtaskها

#	کار	جزئیات فنی	تخمین
F4.1	Layout و گرید	layoutِ سه‌بخشی (سایدبار/هدر/محتوا)، اسکرول مستقل، RTL	۴ ساعت
F4.2	سایدبار	~۲۰ آیتم منطبق بر پروتوتایپ، گروه‌بندی، آیکن، active-state از مسیر	۶ ساعت
F4.3	هدر	منوی پروفایل، زنگِ اعلان (badge)، جستجوی سراسری، سوییچرِ تم	۵ ساعت
F4.4	ناوبریِ موبایل	drawer/بستنِ خودکار، breakpointها، focus trap	۴ ساعت
F4.5	Breadcrumb و عنوان	عنوانِ صفحه‌ی پویا و مسیر بر اساس روت	۳ ساعت

وابستگی: F2، F3.

F5لایه‌ی داده‌ی استاندارد (سرویس + hookهای Query/Mutation)P1ناقص۳ روز

الان فقط useAuth و useBlogs واقعی‌اند؛ بقیه روی آرایه‌ی mock با useState کار می‌کنند و حتی mock را mutate می‌کنند. یک الگوی تکرارپذیر (سرویس + hook) و ابزارهای مشترکِ TanStack Query ساخته شود تا هر بخشِ بعدی سریع و یکدست وصل شود.

Subtaskها

#	کار	جزئیات فنی	تخمین
F5.1	پیکربندی QueryClient	defaultها (staleTime/retry)، devtools، مرزهای خطا	۳ ساعت
F5.2	الگوی سرویس	قالبِ `services/api/<resource>.ts` بر پایه‌ی `blogs.ts`؛ typeها از قرارداد	۴ ساعت
F5.3	hookهای عمومی	`useList/useDetail/useCreate/useUpdate/useDelete` با کلیدِ کش و invalidation	۶ ساعت
F5.4	ابزارِ صفحه‌بندی/فیلتر	هوکِ مشترکِ pagination/filter منطبق بر `meta`؛ infinite/صفحه‌ای	۵ ساعت
F5.5	مدیریت خطا و توست	نگاشتِ ۴۲۲ به خطای فیلدی، توستِ سراسری، optimistic اختیاری	۴ ساعت

وابستگی: F1. پیش‌نیازِ همه‌ی تسک‌های محتوایی (F6 به بعد).

◆ تیم Backend

B4endpointهای احراز هویتP1ناقص۳ روز

فقط /me و /health هست. مجموعه‌ی کاملِ auth منطبق بر قراردادِ PHP، روی مدلِ کاربرِ legacy.

Subtaskها

#	کار	جزئیات فنی	تخمین
B4.1	login	`POST /auth/login`: راستیِ رمز به‌شیوه‌ی اکسوال (pepper+hash)، صدور JWT	۶ ساعت
B4.2	refresh + logout	`POST /auth/refresh`، ابطال، چرخشِ refresh	۵ ساعت
B4.3	register	`POST /auth/register`: اعتبارسنجی، ایجادِ کاربر در جداولِ اکسوال	۶ ساعت
B4.4	change-password + permissions	`PATCH /auth/change-password`، `GET /auth/permissions`	۴ ساعت
B4.5	تست	login/refresh/register/۴۲۲؛ برابری با پاسخِ PHP	۳ ساعت

وابستگی: B1، B2.

B5تصمیمِ داده + مدل‌های پایه‌ی legacyP1ناقص۳ روز

الان فقط ۲ جدول (ow_base_user, ow_base_user_auth_token) با managed=False نگاشت شده. سیاستِ داده تثبیت شود: خواندنِ مستقیم از ow_ در برابر مهاجرت به motoshub_new؛ و مدل‌های پایه ساخته شوند.

Subtaskها

#	کار	جزئیات فنی	تخمین
B5.1	سندِ تصمیمِ داده (ADR)	کدام منابع مستقیم از `ow_`، کدام مهاجرت؛ روترِ DB	۴ ساعت
B5.2	introspect جداول	`inspectdb` روی جداولِ کلیدی، پاک‌سازیِ مدل‌ها، `managed=False`	۶ ساعت
B5.3	مدلِ کاربر و پروفایل	تکمیلِ `LegacyUser`، پروفایل/آواتار، رابطه‌ها	۶ ساعت
B5.4	سرویس‌های مشترک	لایه‌ی سرویسِ پایه، تراکنش روی دو DB، تستِ اتصال	۴ ساعت

وابستگی: B1. پیش‌نیازِ همه‌ی منابعِ B6 به بعد.

هسته‌ی محتوا

پرتکرارترین بخش‌هایی که کاربر روزانه می‌بیند: داشبورد، تازه‌ها، بلاگ، کاربران/پروفایل. رسیدن تا اینجا = «محصولِ قابلِ‌نمایش».

◆ تیم Front

F6داشبورد فعالیت‌هاP1ناقص۴ روز

User Storyبه‌عنوان عضو، می‌خواهم در ورود، فیدِ فعالیت، رویدادهای پیشِ‌رو، اعلان‌ها و میان‌برهای کاری‌ام را یک‌جا ببینم، تا وضعیت روزم را سریع بفهمم.

/workspace و /social الان literalِ ثابت‌اند. ویجت‌های واقعی از چند endpoint ساخته شوند. مرجع: pages/Dashboard.tsx.

Subtaskها

#	کار	جزئیات فنی	تخمین
F6.1	ویجت فید	خلاصه از `GET /newsfeed?scope=feed`، خالی/loading	۶ ساعت
F6.2	ویجت رویداد/اعلان	`GET /events`، `GET /notifications`	۶ ساعت
F6.3	ویجت آمار/میان‌بر	کارت‌های آمار و میان‌برهای سریع منطبق بر پروتوتایپ	۵ ساعت
F6.4	چیدمان واکنش‌گرا	گریدِ ویجت‌ها، ترتیب موبایل، اسکلتون	۴ ساعت

وابستگی: F4، F5. داده: B7/B11/B15.

F7تازه‌ها / فید سازمانی (Channels)P1ناقص۶ روز

User Storyبه‌عنوان عضو، می‌خواهم مطلب (متن/عکس/فایل PDF/Word) منتشر کنم، آن را «انتشار عمومی» با یک «دسته‌بندی» بزنم و مطالبِ دیگران را لایک/نظر بدهم، تا جریانِ اطلاعاتِ سازمان زنده بماند.

/social/channels mock است. پیچیده‌ترین بخشِ فاز: کامپوزرِ انتشار با پیوست، دسته‌بندیِ انتشارِ عمومی (همان فیچرِ افزوده‌شده به پلاگین iisnewsfeedpin)، لایک/نظر/فوروارد و اسکرولِ بی‌نهایت.

EARS: هرگاه کاربر مطلبی را «انتشار عمومی» کند، سامانه باید امکانِ انتخابِ دسته‌بندیِ درختی را بدهد و مطلب را با آن دسته در فیدِ عمومی نمایش دهد.

Subtaskها

#	کار	جزئیات فنی	تخمین
F7.1	فهرست فید	اسکرول بی‌نهایت از `GET /newsfeed`، رندرِ انواع آیتم، اسکلتون	۸ ساعت
F7.2	کامپوزر انتشار	`POST /newsfeed`: متن، منشن، پیش‌نمایشِ لینک	۶ ساعت
F7.3	پیوست فایل	آپلودِ PDF/Word/عکس، نوار پیشرفت، اعتبارسنجیِ نوع/اندازه	۶ ساعت
F7.4	انتشار عمومی + دسته‌بندی	floatboxِ انتخابِ دسته‌ی درختی، اتصال به endpointِ دسته‌بندیِ انتشار	۸ ساعت
F7.5	تعامل‌ها	لایک/نظر/فوروارد با optimistic و invalidation	۸ ساعت
F7.6	فیلترِ دسته	فیلترِ فیدِ عمومی بر اساس دسته‌بندی	۴ ساعت

معیار پذیرش

Given فایلِ PDF پیوست، When مطلب منتشر شود، Then در فید با لینکِ دانلود نمایش داده شود.
Given انتشارِ عمومیِ دسته‌دار، When فیدِ عمومی با آن دسته فیلتر شود، Then فقط مطالبِ همان دسته دیده شوند.

وابستگی: F5. داده: B7.

F8بلاگ (تکمیل: جزئیات و ساخت)P2ناقص۳ روز

User Storyبه‌عنوان نویسنده، می‌خواهم پستِ بلاگ بنویسم، ویرایش/حذف کنم و پست‌ها را کامل بخوانم، تا محتوای بلندِ سازمانی تولید و مصرف شود.

فهرست به /blogs وصل است. باقی‌مانده: صفحه‌ی جزئیات، ساخت/ویرایش با ادیتور، و رفعِ تگِ ساختگیِ blogsList.tsx:30.

Subtaskها

#	کار	جزئیات فنی	تخمین
F8.1	صفحه‌ی جزئیات	`/social/blogs/[id]` از `GET /blogs/:id`، نظرات، متادیتا	۶ ساعت
F8.2	ساخت/ویرایش	`POST/PATCH /blogs` با ادیتورِ غنی، پیش‌نمایش، کاور	۸ ساعت
F8.3	حذف و رفعِ mock	`DELETE /blogs/:id` با تأیید؛ حذفِ تگِ ساختگیِ `blogsList.tsx:30`	۴ ساعت
F8.4	فهرست و فیلتر	صفحه‌بندی، جستجو، فیلترِ نویسنده/تاریخ	۴ ساعت

وابستگی: F5. داده: B8 (قرارداد PHP آماده است).

F9کاربران، پروفایل و تنظیماتِ حسابP2ناقص۴ روز

User Storyبه‌عنوان کاربر، می‌خواهم پروفایلم را ببینم و ویرایش کنم، آواتار بگذارم و کاربرانِ دیگر را بیابم؛ و به‌عنوان مدیر، فهرستِ کاربران را مدیریت کنم.

جدولِ کاربران mock است و دکمه‌های Add/Edit مرده‌اند. فهرست، پروفایلِ عمومی، ویرایشِ پروفایلِ خود و آواتار ساخته شود.

Subtaskها

#	کار	جزئیات فنی	تخمین
F9.1	فهرست کاربران	`GET /users` با جستجو/صفحه‌بندی/فیلتر	۵ ساعت
F9.2	پروفایلِ عمومی	صفحه‌ی پروفایل، تب‌های فعالیت/دوستان/رسانه	۶ ساعت
F9.3	ویرایش پروفایل	`PATCH /users/me`، فیلدهای پویا، اعتبارسنجی	۶ ساعت
F9.4	آواتار	آپلود/برش آواتار `/users/me/avatar`	۵ ساعت
F9.5	تنظیمات حساب	یکپارچه‌سازی با تغییرِ رمز (F3.6)، حریمِ خصوصی، مسدودها	۴ ساعت

وابستگی: F5. داده: B6.

◆ تیم Backend

B6منبعِ کاربران و پروفایلP1نساخته۴ روز

منبعِ پرکاربردِ همه‌ی بخش‌ها. مطابقِ endpointهای PHP: فهرست، پروفایل، ویرایش، آواتار، مسدودها و نشست‌ها.

Subtaskها

#	کار	جزئیات فنی	تخمین
B6.1	Model + Serializer	نگاشتِ کاربر/پروفایل/فیلدهای پویا (`ow_base_question*`)	۶ ساعت
B6.2	list + detail	`GET /users`، `GET /users/:id` با فیلتر/جستجو/صفحه‌بندی	۶ ساعت
B6.3	update + avatar	`PATCH /users/me`، `POST /users/me/avatar`	۶ ساعت
B6.4	blocked + sessions	`/users/blocked`، `/sessions`	۴ ساعت
B6.5	تست + مجوز	تست‌های دسترسی/مالکیت، برابری با PHP	۴ ساعت

وابستگی: B4، B5.

B7منبعِ تازه‌ها (فید) + دسته‌بندیِ انتشارP1نساخته۶ روز

پیچیده‌ترین منبعِ فاز: فید، انتشار با پیوست، لایک/نظر/فوروارد و دسته‌بندیِ انتشارِ عمومی (منطبق با فیچرِ iisnewsfeedpin).

Subtaskها

#	کار	جزئیات فنی	تخمین
B7.1	مدل‌های فید	نگاشتِ `ow_newsfeed_*`، اکشن/آیتم/محتوا	۶ ساعت
B7.2	list فید	`GET /newsfeed` با scope (feed/site/user)، صفحه‌بندی	۶ ساعت
B7.3	create + attachment	`POST /newsfeed`، پیوستِ PDF/Word/عکس	۸ ساعت
B7.4	لایک/نظر/فوروارد	endpointهای تعامل منطبق بر PHP	۸ ساعت
B7.5	دسته‌بندیِ انتشار	منبعِ دسته‌ی درختی + فیلترِ فیدِ عمومی بر اساس دسته	۸ ساعت
B7.6	تست	انتشار/تعامل/فیلترِ دسته	۴ ساعت

وابستگی: B5، B6.

B8منبعِ بلاگP2نساخته۳ روز

Subtaskها

#	کار	جزئیات فنی	تخمین
B8.1	Model + Serializer	نگاشتِ `ow_blogs_post` و نظرات/برچسب	۴ ساعت
B8.2	CRUD	`GET/POST/PATCH/DELETE /blogs`، `GET /blogs/:id`	۸ ساعت
B8.3	مالکیت/مجوز	چکِ مالکیت در ویرایش/حذف، منطبق بر منطقِ PHP	۴ ساعت
B8.4	تست	lifecycle + دسترسی	۴ ساعت

وابستگی: B5.

فضاهای اجتماعی

بخش‌های تعاملیِ سازمان: گروه‌ها، اخبار، رویدادها، رسانه، فروم. الگوهای فاز ۲ اینجا تکرار و مقیاس‌پذیر می‌شوند.

◆ تیم Front

F10گروه‌های تعاملیP2ناقص۶ روز

User Storyبه‌عنوان عضو، می‌خواهم گروه بسازم/عضو شوم، در دیوارِ گروه مطلب بگذارم، فایل به اشتراک بگذارم و اعضا را ببینم، تا کارِ تیمی حولِ موضوع شکل بگیرد.

/social/groups mock با handlerهای خالی است. نیازمندِ فهرست، جزئیاتِ گروه (دیوار/اعضا/فایل)، عضویت و ساخت.

Subtaskها

#	کار	جزئیات فنی	تخمین
F10.1	فهرست + ساخت	`GET /groups`، `POST /groups`، فیلتر/جستجو	۶ ساعت
F10.2	جزئیات + دیوار	`/groups/:id`، فیدِ اختصاصیِ گروه	۸ ساعت
F10.3	اعضا و عضویت	`/members`، `/join`، `/invites`، نقش‌ها	۸ ساعت
F10.4	فایل‌های گروه	`/files` با آپلود/دانلود	۶ ساعت
F10.5	تنظیمات گروه	ویرایش/حریمِ خصوصی/حذف با مجوز	۴ ساعت

وابستگی: F5، F7 (الگوی دیوار). داده: B10.

F11اخبار سازمانP2نساخته۲.۵ روز

User Storyبه‌عنوان عضو، می‌خواهم اخبارِ رسمیِ سازمان را با جزئیات بخوانم؛ و به‌عنوان مدیرِ محتوا خبر منتشر کنم، تا اطلاع‌رسانیِ رسمی متمرکز باشد.

روتِ /social/news اصلاً وجود ندارد (۴۰۴). مرجع: News.tsx, NewsItemDetail.tsx.

Subtaskها

#	کار	جزئیات فنی	تخمین
F11.1	فهرست اخبار	روتِ جدید، `GET /news`، دسته‌بندی/صفحه‌بندی	۶ ساعت
F11.2	جزئیات خبر	`/news/[id]` از `GET /news/:id`، رسانه/گالری	۵ ساعت
F11.3	انتشار/ویرایش	`POST/PATCH /news` با مجوزِ مدیر	۶ ساعت
F11.4	ویجت داشبورد	اتصالِ آخرین اخبار به داشبورد	۳ ساعت

وابستگی: F5. داده: B9.

F12رویدادها و جلساتP2نساخته۳.۵ روز

User Storyبه‌عنوان عضو، می‌خواهم رویداد بسازم، دیگران را دعوت کنم و حضورم را اعلام کنم و تقویمِ رویدادها را ببینم، تا جلساتِ سازمان هماهنگ شوند.

روتِ /social/events وجود ندارد. مرجع: Events.tsx, EventItemDetail.tsx. قراردادِ Backend از قبل تست‌شده است (Pest).

Subtaskها

#	کار	جزئیات فنی	تخمین
F12.1	فهرست/تقویم	`GET /events`، لیست + تقویم، فیلترِ زمان	۸ ساعت
F12.2	ساخت/ویرایش	`POST/PATCH /events` با زمان/مکان/سطحِ دید	۶ ساعت
F12.3	دعوت و RSVP	`/invites`، اعلامِ حضور، فهرستِ شرکت‌کنندگان	۶ ساعت
F12.4	جزئیات + پیوست	جزئیات، فایل‌ها، حذف با مجوز	۵ ساعت

وابستگی: F5. داده: B11 (آماده).

F13تصاویر و ویدیو (رسانه)P2نساخته۳.۵ روز

User Storyبه‌عنوان عضو، می‌خواهم آلبومِ عکس و ویدیو بسازم، رسانه آپلود کنم و گالریِ سازمان را مرور کنم، تا محتوای بصری به اشتراک گذاشته شود.

روتِ /social/media وجود ندارد. مرجع: Media.tsx, MediaItemDetail.tsx.

Subtaskها

#	کار	جزئیات فنی	تخمین
F13.1	گالری عکس/آلبوم	`/photos`، `/albums`، لایت‌باکس، صفحه‌بندی	۸ ساعت
F13.2	آپلود عکس	آپلودِ چندتایی، پیش‌نمایش، انتخابِ آلبوم	۶ ساعت
F13.3	ویدیو	`/videos`، پخش، آپلود/embed	۶ ساعت
F13.4	مدیریت آلبوم	ساخت/ویرایش/حذف، کاور، مجوزِ مالکیت	۵ ساعت

وابستگی: F5. داده: B12 (آماده، با اصلاحاتِ IDOR).

F14انجمن (فروم)P2نساخته۳ روز

User Storyبه‌عنوان عضو، می‌خواهم موضوع بسازم، پاسخ بدهم و بحث‌های دسته‌بندی‌شده را دنبال کنم، تا گفتگوهای ماندگارِ سازمان شکل بگیرد.

روتِ /social/forums وجود ندارد. مرجع: Forum.tsx و نوعِ ForumTopic.

Subtaskها

#	کار	جزئیات فنی	تخمین
F14.1	دسته‌ها/بخش‌ها	فهرستِ بخش‌ها و موضوع‌ها `GET /forum/topics`	۶ ساعت
F14.2	موضوع + پست‌ها	`/topics/:id/posts`، صفحه‌بندیِ پاسخ‌ها، نقل‌قول	۸ ساعت
F14.3	ساخت موضوع/پاسخ	ادیتور، پیوست، اعلانِ اشتراک	۶ ساعت
F14.4	مدیریت	قفل/پین/انتقال با مجوزِ ناظر	۴ ساعت

وابستگی: F5. داده: B13.

◆ تیم Backend

B9منبعِ اخبارP2نساخته۳ روز

#	کار	جزئیات فنی	تخمین
B9.1	Model + Serializer	نگاشتِ منبعِ خبر و دسته/رسانه	۴ ساعت
B9.2	CRUD + list	`GET/POST/PATCH /news`، `/news/:id`	۸ ساعت
B9.3	مجوزِ انتشار	محدودسازیِ انتشار به نقشِ مدیرِ محتوا	۴ ساعت
B9.4	تست	lifecycle + دسترسی	۴ ساعت

وابستگی: B5.

B10منبعِ گروه‌هاP2نساخته۶ روز

#	کار	جزئیات فنی	تخمین
B10.1	مدل‌ها	گروه/عضویت/نقش/دعوت، نگاشتِ جداولِ اکسوال	۶ ساعت
B10.2	CRUD گروه	`GET/POST/PATCH/DELETE /groups`، `/groups/:id`	۸ ساعت
B10.3	اعضا/عضویت	`/members`، `/join`، `/invites`، نقش/مجوز	۸ ساعت
B10.4	دیوار/فایل	فیدِ گروه، `/files` آپلود/دانلود	۸ ساعت
B10.5	تست	عضویت/مجوز/فایل	۴ ساعت

وابستگی: B5، B7 (الگوی فید).

B11منبعِ رویدادهاP2آماده در PHP۵ روز

قراردادِ PHP و تست‌های Pest موجودند (نمونه: EventControllerTest). این تسک بازسازیِ همان در Django است.

#	کار	جزئیات فنی	تخمین
B11.1	مدل‌ها	رویداد/دعوت/شرکت‌کننده/فایل	۶ ساعت
B11.2	CRUD	`GET/POST/PATCH/DELETE /events`، اعتبارسنجیِ زمان	۸ ساعت
B11.3	دعوت/RSVP	`/invites`، حضور، سطحِ دید/دعوت	۸ ساعت
B11.4	تست معادلِ Pest	پورتِ سناریوهای `EventControllerTest` به pytest	۴ ساعت

وابستگی: B5.

B12منبعِ رسانه (عکس/آلبوم/ویدیو)P2آماده در PHP۶ روز

در PHP کامل و امن‌شده است (اصلاحاتِ IDOR و چکِ مالکیت در PhotoService/AlbumService). Django باید همان قرارداد و چک‌های مالکیت را بدهد.

#	کار	جزئیات فنی	تخمین
B12.1	مدل‌ها	عکس/آلبوم/کاور/ویدیو، نگاشتِ `ow_photo_*`	۶ ساعت
B12.2	آلبوم CRUD	`/albums` با چکِ مالکیت (مثلِ PHP: مالک یا ناظر)	۸ ساعت
B12.3	عکس CRUD + آپلود	`/photos`، آپلود، به‌روزرسانیِ کاور، PATCH جزئی (بدون null‌کردن)	۸ ساعت
B12.4	ویدیو	`/videos` CRUD + پردازش/embed	۶ ساعت
B12.5	تست IDOR	عدمِ دسترسیِ غیرمالک به ویرایش/حذف	۴ ساعت

وابستگی: B5، B1.5 (آپلود).

B13منبعِ فرومP2نساخته۵ روز

#	کار	جزئیات فنی	تخمین
B13.1	مدل‌ها	بخش/موضوع/پست، نگاشتِ `ow_forum_*`	۶ ساعت
B13.2	موضوع‌ها	`GET/POST /forum/topics`، دسته‌بندی	۸ ساعت
B13.3	پست‌ها	`/topics/:id/posts`، پاسخ/نقل‌قول	۸ ساعت
B13.4	مدیریت + تست	قفل/پین/انتقال با مجوز؛ تست	۴ ساعت

وابستگی: B5.

ارتباط و همکاری

ابزارهای کارِ روزمره: پیام‌رسان، مدیریت دانش، مدیریت پروژه (کانبان).

◆ تیم Front

F15گفتگو (پیام‌رسان)P3ناقص۶ روز

User Storyبه‌عنوان عضو، می‌خواهم گفتگوی خصوصی/گروهی داشته باشم، پیام و فایل بفرستم و پیامِ جدید را بی‌درنگ ببینم، تا هماهنگیِ سریع ممکن شود.

در پروتوتایپ و تبِ چتِ پروژه UIِ کاملِ mock هست. اتصال به پیام‌رسانِ واقعی؛ به‌روزرسانیِ بی‌درنگ (polling یا WebSocket).

#	کار	جزئیات فنی	تخمین
F15.1	فهرست گفتگوها	`GET /conversations`، شمارشِ نخوانده، جستجو	۶ ساعت
F15.2	پنجره‌ی پیام	`/messages`، ارسال، بارگذاریِ تاریخچه (اسکرول معکوس)	۸ ساعت
F15.3	بی‌درنگ	polling/WebSocket، وضعیتِ خوانده، تایپینگ	۸ ساعت
F15.4	پیوست	ارسالِ فایل/عکس، پیش‌نمایش	۶ ساعت

وابستگی: F5. داده: B14.

F16مدیریت دانشP3نساخته۲.۵ روز

User Storyبه‌عنوان عضو، می‌خواهم اسناد و راهنماهای سازمانی را در یک کتابخانه‌ی دسته‌بندی‌شده بیابم و بخوانم، تا دانشِ سازمان حفظ و بازیابی شود.

#	کار	جزئیات فنی	تخمین
F16.1	کتابخانه	`GET /knowledge/documents`، درختِ دسته، جستجو	۶ ساعت
F16.2	نمای سند	نمایشگر/دانلود، متادیتا، نسخه	۶ ساعت
F16.3	افزودن سند	آپلود/دسته‌بندی با مجوز	۵ ساعت

وابستگی: F5. داده: B16.

F17مدیریت پروژه (کانبان + چت پروژه)P3ناقص۷ روز

User Storyبه‌عنوان عضوِ تیم، می‌خواهم پروژه بسازم، وظایف را روی بردِ کانبان بکشم‌و‌رها کنم، اعضا را تخصیص دهم و در چتِ پروژه گفتگو کنم، تا کارِ تیمی مدیریت شود.

/workspace/projects (فهرست/جزئیات/کانبان/چت) کامل ولی mock است. اتصالِ همه به API واقعی، از جمله drag-and-drop با persist.

#	کار	جزئیات فنی	تخمین
F17.1	فهرست/ساخت پروژه	`GET/POST /projects`، اعضا، وضعیت	۶ ساعت
F17.2	بردِ کانبان	ستون‌ها/کارت‌ها، drag-and-drop، persistِ ترتیب/وضعیت	۱۲ ساعت
F17.3	وظیفه	جزئیاتِ وظیفه، تخصیص، سررسید، چک‌لیست، پیوست	۸ ساعت
F17.4	چتِ پروژه	استفاده‌ی مجددِ کامپوننتِ چت (F15) در بستر پروژه	۶ ساعت
F17.5	نماها	لیست/کانبان/تقویم، فیلترِ عضو/وضعیت	۴ ساعت

وابستگی: F5، F15. داده: B16.

◆ تیم Backend

B14منبعِ پیام‌رسانP3نساخته۶ روز

#	کار	جزئیات فنی	تخمین
B14.1	مدل‌ها	گفتگو/پیام/عضو/وضعیتِ خوانده، نگاشتِ `ow_mailbox_*`	۶ ساعت
B14.2	گفتگوها	`GET /conversations`، ساخت، شمارشِ نخوانده	۶ ساعت
B14.3	پیام‌ها	`/messages` ارسال/فهرست، صفحه‌بندیِ تاریخچه	۸ ساعت
B14.4	بی‌درنگ	Channels/WebSocket یا long-poll؛ پیوست	۱۰ ساعت
B14.5	تست	ارسال/خواندن/دسترسیِ عضو	۴ ساعت

وابستگی: B5. (WebSocket نیازمندِ ASGI؛ مرتبط با B3.)

B15منبعِ دوستان و اعلان‌هاP2نساخته۴ روز

#	کار	جزئیات فنی	تخمین
B15.1	دوستان	`/friends`: درخواست/تأیید/حذف، نگاشتِ `ow_friends_*`	۸ ساعت
B15.2	اعلان‌ها	`GET /notifications`، علامتِ خوانده، شمارش	۸ ساعت
B15.3	تولیدِ اعلان	hookهای رویداد (لایک/نظر/دعوت) → اعلان	۶ ساعت
B15.4	تست	چرخه‌ی دوستی/اعلان	۴ ساعت

وابستگی: B5.

B16منبعِ دانش و پروژهP3نساخته۶ روز

#	کار	جزئیات فنی	تخمین
B16.1	دانش	`/knowledge/documents` CRUD + دسته + آپلود	۸ ساعت
B16.2	پروژه	`/projects` CRUD + اعضا + وضعیت	۸ ساعت
B16.3	وظیفه/کانبان	ستون/کارت/ترتیب، endpointِ جابه‌جایی و تخصیص	۸ ساعت
B16.4	تست	CRUD + persistِ ترتیب	۴ ساعت

وابستگی: B5. (اگر پروژه در اکسوال منبع ندارد، مدلِ جدید در motoshub_new.)

ماژول‌های سازمانی

بخش‌های تخصصیِ سازمان: قراردادها، صندوقِ نوآوری، پژوهش، آموزش، نظرسنجی/مسابقات/ارزیابی.

◆ تیم Front

F18ماژول‌های سازمانی (قرارداد/صندوق/پژوهش/آموزش)P3نساخته۸ روز

User Storyبه‌عنوان کاربرِ سازمانی، می‌خواهم قراردادها، فراخوان‌های صندوقِ نوآوری، پروژه‌های پژوهشی و دوره‌های آموزشی را ببینم و در آن‌ها اقدام کنم، تا فرایندهای سازمانی دیجیتال شوند.

چهار بخشِ مجزا با روت‌های موجودنبوده. مرجع: Contracts/Funds/Research/Training. هر بخش الگوی فهرست/جزئیات/فرم دارد.

#	کار	جزئیات فنی	تخمین
F18.1	قراردادها	روت، فهرست/جزئیات، وضعیت/گردش‌کار	۱۰ ساعت
F18.2	صندوقِ نوآوری	فراخوان‌ها `/cfps`، ثبتِ درخواست `/grants`	۱۲ ساعت
F18.3	پژوهش	فهرست/جزئیاتِ پروژه‌های پژوهشی، فناوری‌ها	۱۰ ساعت
F18.4	آموزش	دوره‌ها، ثبت‌نام، پیشرفت	۱۰ ساعت
F18.5	یکپارچه‌سازی منو	افزودن به سایدبار/داشبورد، مجوزها	۴ ساعت

وابستگی: F5. داده: B17.

◆ تیم Backend

B17منبعِ ماژول‌های سازمانیP3نساخته۸ روز

#	کار	جزئیات فنی	تخمین
B17.1	قراردادها/تیکت	`/tickets` و منبعِ قرارداد، گردش‌کارِ وضعیت	۱۲ ساعت
B17.2	صندوق	`/cfps`، `/grants`: فراخوان/درخواست/داوری	۱۲ ساعت
B17.3	پژوهش/فناوری	`/technologies`، `/journal-*`	۱۲ ساعت
B17.4	آموزش	دوره/ثبت‌نام/پیشرفت	۱۲ ساعت
B17.5	تست	CRUD + گردش‌کار	۴ ساعت

وابستگی: B5.

B18منبعِ نظرسنجی، مسابقات و ارزیابیP3نساخته۵ روز

#	کار	جزئیات فنی	تخمین
B18.1	نظرسنجی	`/polls`: ساخت/رأی/نتیجه	۸ ساعت
B18.2	مسابقات	`/competitions`: ثبت/داوری	۸ ساعت
B18.3	ارزیابی	`/evaluations`	۶ ساعت
B18.4	تست	رأی/نتیجه/دسترسی	۴ ساعت

وابستگی: B5.

راهبری، جستجو، پولیش و تحویل

بخش‌های مدیریتی و پایانی که محصول را «کامل» و آماده‌ی تحویل می‌کنند.

◆ تیم Front

F19پنل راهبری، ظاهر/برندسازی و گزارش‌گیریP3نساخته۸ روز

User Storyبه‌عنوان مدیرِ سامانه، می‌خواهم کاربران/محتوا/تنظیمات را مدیریت کنم، ظاهر و برندِ سازمان را تغییر دهم و گزارش‌های کاربری بگیرم، تا سامانه را اداره کنم.

#	کار	جزئیات فنی	تخمین
F19.1	داشبوردِ راهبری	آمار کلی، مدیریتِ کاربران/نقش‌ها `/admin/*`	۱۰ ساعت
F19.2	ظاهر/برند	لوگو/رنگ/نامِ سازمان (per-tenant)، پیش‌نمایشِ زنده	۱۰ ساعت
F19.3	گزارش‌گیری	گزارش‌های کاربری/محتوایی، نمودار، خروجی	۱۰ ساعت
F19.4	مدیریتِ محتوا/مجوز	ابزارهای مدیریتِ محتوا و نقش/دسترسی	۶ ساعت

وابستگی: F5، F9. داده: endpointهای admin.

F20اعلان، جستجوی سراسری، راهنما، دستیار و پولیشِ نهاییP3ناقص۸ روز

User Storyبه‌عنوان کاربر، می‌خواهم اعلان‌هایم را ببینم، در کلِ سامانه جستجو کنم، راهنما بگیرم و از دستیارِ هوشمند کمک بخواهم، و رابطی روان و بی‌نقص داشته باشم.

#	کار	جزئیات فنی	تخمین
F20.1	مرکز اعلان	`GET /notifications`، خواندن/تنظیمات، هدرِ زنگ	۶ ساعت
F20.2	جستجوی سراسری	`GET /search`، نتایجِ چنددسته، صفحه‌ی نتایج	۸ ساعت
F20.3	راهنما و دستیار	صفحه‌ی راهنما، دستیارِ هوشمند (طبقِ پروتوتایپ)	۶ ساعت
F20.4	پولیشِ a11y/RTL	پیمایشِ کیبورد، aria، کنتراست، بازبینیِ RTL همه‌ی صفحه‌ها	۶ ساعت
F20.5	عملکرد	code-splitting، بهینه‌ی تصویر، بازبینیِ کش، Lighthouse	۶ ساعت
F20.6	تستِ E2E	سناریوهای کلیدی با Playwright	۶ ساعت

وابستگی: همه‌ی تسک‌های Front.

◆ تیم Backend

B19منبعِ جستجو + یکپارچه‌سازی و تحویلP3نساخته۴ روز

#	کار	جزئیات فنی	تخمین
B19.1	جستجوی سراسری	`GET /search` چنددسته (کاربر/بلاگ/فروم/...)، صفحه‌بندی	۸ ساعت
B19.2	برابریِ قرارداد	تستِ diffِ پاسخِ Django با PHP روی endpointهای کلیدی	۶ ساعت
B19.3	سوییچِ Gateway	مستندِ گذارِ مسیر‌به‌مسیر از PHP به Django بدونِ downtime	۶ ساعت
B19.4	OpenAPI + تحویل	هم‌ترازیِ `drf-spectacular` با قراردادِ v1، انتشارِ داکِ نهایی	۶ ساعت

وابستگی: همه‌ی منابعِ Backend.

یادداشتِ برنامه‌ریزی. ترتیبِ فازها ترتیبِ اجراست، اما درونِ هر فاز تسک‌های Front و Backend موازی‌اند. توصیه: در آغازِ هر فاز یک جلسه‌ی Planning و کالیبراسیونِ تخمین، و در پایانِ هر فاز یک Demo روی همان صفحه‌ی پروتوتایپ برای سنجشِ «چقدر به هدف رسیدیم». تخمین‌ها بدونِ زمانِ بازکاریِ ناشی از تغییرِ نیازمندی و بدونِ زمانِ استقرار محاسبه شده‌اند؛ یک بافرِ ۱۵–۲۰٪ در برنامه لحاظ شود.

✓

پایپ‌لاین تحویل و کیفیت (الزامی برای هر دو تیم)

هیچ تسکی «انجام‌شده» نیست مگر از همه‌ی این گیت‌ها عبور کند. هدف: کارِ اضافه نه، اما هر کاری که انجام می‌شود چندبار و در چند لایه تست شده باشد. هر گیت مسئول مشخص دارد و هیچ مرحله‌ای «به عهده‌ی بعداً» نیست.

◆ مسیر عبور هر تسک (Front و Backend یکسان)

#	گیت	مسئول	معیار عبور (بدون ابهام)
۱	آماده‌ی شروع (DoR)	PO	تسک شماره‌ی issue دارد؛ User Story + معیارهای پذیرش در همین صفحه/ایشو مشخص است؛ وابستگی‌هایش باز نیست. تسکِ بدون معیار پذیرش شروع نمی‌شود.
۲	توسعه روی برنچ ایشو	Dev	برنچ `issue-N` از `main`؛ کامیت‌ها با پیشوند `#N`. مستقیم روی main کامیت ممنوع (CI هم بلاک می‌کند).
۳	تستِ لایه‌ی ۱ — واحد	Dev	Backend: تست pytest/Pest برای هر endpoint جدید (سناریو موفق + ۴۰۱/۴۰۳/۴۲۲ + یک edge). Front: تست کامپوننت برای منطق غیربدیهی + `tsc` و ESLint سبز. کدِ بدون تستِ همراه، merge نمی‌شود.
۴	Self-review + چک‌لیست MR	Dev	قالب MR پر شده: «چه چیزی، چرا، چطور تست شد» + برای Front اسکرین‌شات/فیلم قبل‌وبعد (لایت و دارک، دسکتاپ و ۳۷۵px) + برای Backend نمونه‌ی curl درخواست/پاسخ.
۵	CI سبز — لایه‌ی ۲	خودکار	lint + type-check + کل تست‌ها + build + (Backend: تستِ قرارداد علیه OpenAPI؛ Front: build بدون warning جدید). قرمز = merge غیرممکن.
۶	Code review همتا	Dev دوم	حداقل ۱ تایید از غیرنویسنده؛ SLA بررسی ۲۴ ساعت کاری. تمرکز review: درستی، امنیت (IDOR/مجوز)، سازگاری با قراردادِ پاکت پاسخ.
۷	Merge به main → دیپلوی staging خودکار	خودکار	Front: motonextfront.shub.ir · Backend: motonext staging. دیپلوی شکسته = بازگردانی فوری (revert اول، دیباگ بعد).
۸	تستِ لایه‌ی ۳ — پذیرش روی staging	PO / QA	اجرای معیارهای پذیرش روی staging: Front در دو مرورگر + موبایل واقعی؛ Backend با کالکشن Postman ماژول (همه‌ی حالت‌ها). فقط بعد از این تیک، وضعیت تسک «انجام‌شده» می‌شود.
۹	رگرسیون هفتگی	تیم (چرخشی)	پایان هر هفته: چک‌لیست ۳۰ دقیقه‌ای مسیرهای حیاتی (ورود، فید، ایجاد محتوا، چت، آپلود، اعلان) روی staging. شکستِ رگرسیون = اولویت P1 هفته‌ی بعد.

◆ قواعد مکمل کیفیت

قانون باگ. هر باگی که پیدا شد، اول یک تستِ بازتولیدکننده نوشته می‌شود که قرمز شود، بعد فیکس — تا همان باگ هیچ‌وقت برنگردد.

تعریفِ «انجام‌شده» (DoD). کد merge شده + تست‌های هر سه لایه پاس + روی staging توسط PO پذیرفته + بدون TODO/console.log باقی‌مانده + مستند (endpoint جدید در Swagger / کامپوننت جدید با props مستند).

بدون کار اضافه. هر چیزی خارج از معیارهای پذیرشِ تسک = تسک جدید برای PO؛ داخل همان MR نمی‌آید. MRهای بزرگ‌تر از ~۴۰۰ خط تغییر باید شکسته شوند.

ادغام مکرر. برنچ ایشو بیش از ۳ روز کاری زنده نمی‌ماند؛ کار بزرگ‌تر از آن یعنی تسک درست شکسته نشده (برگشت به گیت ۱).

منابع فنی

سند	کاربرد
راهنمای فرانت‌اند	قرارداد، احراز هویت، صفحه‌بندی، خطاها، همه‌ی endpointها
مرجع کامل API · Swagger	امضای دقیقِ هر endpoint برای Backend (بازسازی) و Front (اتصال)
معماری سیستم	Gateway/دو ORM/اسکیمای ۴۰۷ جدول، استراتژیِ auth
راهنمای Ops	نیازمندیِ سرور، استقرار، پایشِ منابع
Postman · openapi.json	تستِ قرارداد و مبنای برابریِ Django با PHP

Motoshub · برنامه‌ی تحویلِ تیم Front و Backend
۳۹ تسک · ~۱۷۰ subtask · تخمینِ کلِ تک‌نفره ~۱۸۸ روزِ‌نفر · مسیرِ موازیِ ۴‌نفره ~۱۳ تا ۱۶ هفته
روش‌شناسی: Feature-Forge (User Story + EARS + Given/When/Then) و اصولِ Frontend-Design · تهیه‌شده پس از خواندنِ کاملِ سه ریپو