Motoshub · Delivery Plan · Backend

تسک‌های تیم Backend — با جزئیات پیاده‌سازی

همه‌ی تسک‌های بک‌اند با subtask، تخمین، User Story و معیار پذیرش. مرجع رفتار: demo.shub.ir · خط لوله‌ی الزامی تحویل: فرآیند تحویل و کیفیت · تسک‌های Front

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

راهنمای پیاده‌سازی تیم Backend

استک و قراردادها. Django 5 + DRF + SimpleJWT روی MariaDB (دیتابیس مشترک Oxwall به‌صورت خواندنی از طریق مدل‌های unmanaged در legacy/). قرارداد پاسخ ثابت: پاکت {data, links, meta}، خطاهای ۴۰۱/۴۰۳/۴۰۴/۴۲۲ با بدنه‌ی یکسان — مرجع: Swagger زنده‌ی PHP در motonext.shub.ir/api/v1/docs.

auth مشترک. JWT HS256 با راز OW_PASSWORD_PEPPER و claims {iat, exp, sub} — توکن صادرشده توسط PHP باید در Django معتبر باشد و برعکس (تست سازگاری متقابل در B2.4 اجباری است).

الگوی هر ماژول. Model (یا legacy-map) ← Serializer ← ViewSet + Permission ← urls ← تست pytest (سناریوی موفق + ۴۰۱/۴۰۳/۴۲۲ + یک edge + تست IDOR برای منابع مالک‌دار). هیچ endpoint بدون تست merge نمی‌شود.

سوییچ تدریجی. هر ماژول که برابری قراردادش با PHP تایید شد، مسیرش در Gateway به Django سوییچ می‌شود (B19.3)؛ تا آن روز PHP پاسخ‌گوی production است — مهاجرت strangler-fig، بدون big-bang.

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

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

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

اصلاحِ جمع‌بندی (۱۴۰۵/۰۵/۱۱). جمعِ ستون‌های این جدول با مجموعِ تخمینِ تک‌تکِ تسک‌ها هم‌خوان نبود (Front ~۹۶ در برابر ۹۰ واقعی، Backend ~۹۲ در برابر ۸۶). اعدادِ جدول با مجموعِ واقعی هم‌خوان شد. هیچ تخمینی در هیچ تسکی تغییر نکرده است — فقط خطای جمع رفع شد. برآوردهای هفتگی و سناریوهای اندازه‌ی تیم نیز دست‌نخورده مانده‌اند، چون آن‌ها بر پایه‌ی مسیر بحرانی محاسبه شده‌اند نه جمعِ ساده.

تفسیرِ زمان. با ۲ توسعه‌دهنده‌ی 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 و بدنه‌ی یکسان. مرجعِ فیلدها: Swagger روی motonext.shub.ir/api/v1/docs/index — که در راستی‌آزماییِ ۱۴۰۵/۰۵/۱۱ پاسخِ ۴۰۴ داد و باید بازگردانده شود (جزئیات). تا آن زمان مرجعِ فیلدها = کنترلرها و Resourceهای ow_plugins/*/src/Http در برنچ API..

۴) دامنه‌بندی الزام‌آور است (الحاقیه ۱۴۰۵/۰۵/۱۴). هر موجودیت محتوایی سه فیلد scope/holdingId/companyId دارد؛ دامنه‌ی دید از عضویتِ کاربر محاسبه می‌شود نه از انتخاب او؛ و فیلتر/اعتبارسنجی باید سمت سرور باشد. مشخصات کامل و سناریوهای پذیرش: قرارداد دامنه‌بندی و دسترسی.

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

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

◆ تیم 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 مبنا	۵ ساعت

تعریف انجام (DoD)

پاکت پاسخ {data,links,meta}، صفحه‌بندی، بدنهٔ خطای یکسان (۴۰۱/۴۰۳/۴۰۴/۴۲۲)، CORS و آپلود مشترک — همگی با تست.
عبور از خط لولهٔ تحویل: تست واحد + تست قرارداد علیه OpenAPI + CI سبز + پذیرش PO روی staging (کالکشن Postman) — فرآیند.

وابستگی: ندارد (نقطه‌ی شروعِ 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 ۴۰۱ برگردد.

تعریف انجام (DoD)

JWT HS256 با راز مشترک OW_PASSWORD_PEPPER؛ توکن PHP در Django معتبر و برعکس، با تست سازگاری متقابل.
عبور از خط لولهٔ تحویل: تست واحد + تست قرارداد علیه OpenAPI + CI سبز + پذیرش PO روی staging (کالکشن Postman) — فرآیند.

وابستگی: 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	۵ ساعت

تعریف انجام (DoD)

production.py کامل، Dockerfile سالم و بیلد‌پذیر، CI هر دو ریپو سبز، محیط staging بالا.
عبور از خط لولهٔ تحویل: تست واحد + تست قرارداد علیه OpenAPI + CI سبز + پذیرش PO روی staging (کالکشن Postman) — فرآیند.

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

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

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

◆ تیم 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	۳ ساعت

تعریف انجام (DoD)

endpointهای auth/login·me·refresh·logout·change-password با تست موفق + خطاها.
عبور از خط لولهٔ تحویل: تست واحد + تست قرارداد علیه OpenAPI + CI سبز + پذیرش PO روی staging (کالکشن Postman) — فرآیند.

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

الحاقیه‌ی ۱۴۰۵/۰۵/۱۴ (این تسک را تغییر نمی‌دهد): در نسخه‌ی نهایی، auth/me باید عضویت‌ها، تخصیص نقش و مجوزهای مؤثر را هم برگرداند ← B21.3.

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، تستِ اتصال	۴ ساعت

تعریف انجام (DoD)

تصمیم داده نهایی؛ مدل‌های legacy پایه (unmanaged، بدون ستون‌های حساس) با DB router.
عبور از خط لولهٔ تحویل: تست واحد + تست قرارداد علیه OpenAPI + CI سبز + پذیرش PO روی staging (کالکشن Postman) — فرآیند.

وابستگی: B1. پیش‌نیازِ همه‌ی منابعِ 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	۴ ساعت

تعریف انجام (DoD)

منبع کاربران/پروفایل: /users با جستجو/صفحه‌بندی، ویرایش خود، آواتار — با تست.
عبور از خط لولهٔ تحویل: تست واحد + تست قرارداد علیه OpenAPI + CI سبز + پذیرش PO روی staging (کالکشن Postman) — فرآیند.

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

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

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

Subtaskها

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

تعریف انجام (DoD)

منبع فید: /feed با scope و پیوست؛ لایک/نظر/فوروارد — با تست.
عبور از خط لولهٔ تحویل: تست واحد + تست قرارداد علیه OpenAPI + CI سبز + پذیرش PO روی staging (کالکشن Postman) — فرآیند.

وابستگی: 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 + دسترسی	۴ ساعت

تعریف انجام (DoD)

منبع بلاگ: CRUD /blogs با مجوز — با تست.
عبور از خط لولهٔ تحویل: تست واحد + تست قرارداد علیه OpenAPI + CI سبز + پذیرش PO روی staging (کالکشن Postman) — فرآیند.

وابستگی: B5.

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

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

◆ تیم Backend

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

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

تعریف انجام (DoD)

منبع اخبار: CRUD /news + دسته‌بندی/scope انتشار — با تست lifecycle و دسترسی.
عبور از خط لولهٔ تحویل: تست واحد + تست قرارداد علیه OpenAPI + CI سبز + پذیرش PO روی staging (کالکشن Postman) — فرآیند.

وابستگی: B5.

الحاقیه‌ی ۱۴۰۵/۰۵/۱۴ (این تسک را تغییر نمی‌دهد): فیلد topic خبر (۵ مقدار) + فیلتر ?topic= ← B24.

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

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

تعریف انجام (DoD)

منبع گروه‌ها: CRUD + عضویت + نقش ناظم — با تست IDOR.
عبور از خط لولهٔ تحویل: تست واحد + تست قرارداد علیه OpenAPI + CI سبز + پذیرش PO روی staging (کالکشن Postman) — فرآیند.

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

الحاقیه‌ی ۱۴۰۵/۰۵/۱۴ (این تسک را تغییر نمی‌دهد): قواعد «ناظم گروه» سمت سرور (فقط گروه خودش) ← B22.4.

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	۴ ساعت

تعریف انجام (DoD)

منبع رویدادها با دعوت/حضور — با تست.
عبور از خط لولهٔ تحویل: تست واحد + تست قرارداد علیه OpenAPI + CI سبز + پذیرش PO روی staging (کالکشن Postman) — فرآیند.

وابستگی: B5.

الحاقیه‌ی ۱۴۰۵/۰۵/۱۴ (این تسک را تغییر نمی‌دهد): فیلدهای category و capacity رویداد ← B24.

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	عدمِ دسترسیِ غیرمالک به ویرایش/حذف	۴ ساعت

تعریف انجام (DoD)

منبع رسانه (عکس/آلبوم/ویدیو) با حریم خصوصی — با تست.
عبور از خط لولهٔ تحویل: تست واحد + تست قرارداد علیه OpenAPI + CI سبز + پذیرش PO روی staging (کالکشن Postman) — فرآیند.

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

الحاقیه‌ی ۱۴۰۵/۰۵/۱۴ (این تسک را تغییر نمی‌دهد): فیلد duration ویدیو ← B24.

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

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

تعریف انجام (DoD)

منبع فروم: بخش/موضوع/پست، قفل/پین/انتقال با مجوز — با تست.
عبور از خط لولهٔ تحویل: تست واحد + تست قرارداد علیه OpenAPI + CI سبز + پذیرش PO روی staging (کالکشن Postman) — فرآیند.

وابستگی: B5.

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

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

◆ تیم Backend

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

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

تعریف انجام (DoD)

منبع پیام‌رسان در سطح فعلی: کانال/پیام/رشته/reaction روی WebSocket — با تست.
عبور از خط لولهٔ تحویل: تست واحد + تست قرارداد علیه OpenAPI + CI سبز + پذیرش PO روی staging (کالکشن Postman) — فرآیند.

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

الحاقیه‌ی ۱۴۰۵/۰۵/۱۴ (این تسک را تغییر نمی‌دهد): کانال‌ها دامنه‌دارند — فیلتر فهرست کانال بر اساس نشست ← B21.2 و B22.1.

الحاقیه‌ی ۱۴۰۵/۰۵/۱۴ (این تسک را تغییر نمی‌دهد): ادامه‌ی این تسک برای هم‌ترازی کامل با تلگرام: B25–B28 — مرجع: مشخصات پیام‌رسان.

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

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

تعریف انجام (DoD)

منبع دوستان و اعلان: درخواست/تأیید، تولید اعلان از رویدادها، شمارش خوانده‌نشده — با تست.
عبور از خط لولهٔ تحویل: تست واحد + تست قرارداد علیه OpenAPI + CI سبز + پذیرش PO روی staging (کالکشن Postman) — فرآیند.

وابستگی: B5.

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

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

تعریف انجام (DoD)

منبع دانش و پروژه: آپلود/نسخه سند، بورد/تسک/گانت — با تست.
عبور از خط لولهٔ تحویل: تست واحد + تست قرارداد علیه OpenAPI + CI سبز + پذیرش PO روی staging (کالکشن Postman) — فرآیند.

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

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

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

◆ تیم Backend

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

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

تعریف انجام (DoD)

منبع ماژول‌های سازمانی: قرارداد/تیکت/صندوق/پژوهش/آموزش با گردش‌کار وضعیت — با تست.
عبور از خط لولهٔ تحویل: تست واحد + تست قرارداد علیه OpenAPI + CI سبز + پذیرش PO روی staging (کالکشن Postman) — فرآیند.

وابستگی: B5.

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

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

تعریف انجام (DoD)

منبع نظرسنجی/مسابقه/ارزیابی با رأی و امتیازدهی — با تست.
عبور از خط لولهٔ تحویل: تست واحد + تست قرارداد علیه OpenAPI + CI سبز + پذیرش PO روی staging (کالکشن Postman) — فرآیند.

وابستگی: B5.

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

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

◆ تیم 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، انتشارِ داکِ نهایی	۶ ساعت

تعریف انجام (DoD)

منبع جستجو (/search)، برابری قرارداد Django↔PHP، سوییچ Gateway مستند و OpenAPI هم‌تراز.
عبور از خط لولهٔ تحویل: تست واحد + تست قرارداد علیه OpenAPI + CI سبز + پذیرش PO روی staging (کالکشن Postman) — فرآیند.

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

دامنه‌ی کشف‌شده — افزوده‌ی ۱۴۰۵/۰۵/۱۱

تطبیقِ صفحه‌های demo.shub.ir با فهرستِ B1–B19 نشان داد ماژولِ تیکت در هیچ‌کدام از دو تیم تسک نداشت، با این‌که در PHP آماده است. مانندِ سمتِ Front، این تسک با شماره‌ی تازه آمده و در جمعِ فازهای ۰ تا ۶ حساب نشده است.

◆ تیم Backend

B20منبعِ تیکت پشتیبانیP3آماده در PHP۲ روز

۱۲ عملیاتِ آماده در برنچ API (/tickets، /tickets/{id}، /ticket-categories، /ticket-orders) که هنوز روی production مستقر نشده‌اند. کارِ Backend اینجا = استقرارِ همان‌ها و سپس بازسازی در Django طبقِ همان قرارداد.

Subtaskها

#	کار	جزئیات فنی	تخمین
B20.1	استقرارِ مسیرهای PHP	فعال‌سازیِ `iisticketing` در استقرارِ production و تاییدِ پاسخ‌ها	۴ ساعت
B20.2	مدل و فهرست	تیکت/دسته/پاسخ، `GET /tickets` با فیلترِ وضعیت و صفحه‌بندی	۵ ساعت
B20.3	ایجاد و گردشِ وضعیت	`POST /tickets`، تغییرِ وضعیت، مجوزِ مالک/پشتیبان (IDOR)	۵ ساعت
B20.4	تست	سناریوی موفق + ۴۰۱/۴۰۳/۴۲۲ + دسترسیِ کاربرِ دیگر	۲ ساعت

تعریف انجام (DoD)

منبع تیکت (/tickets، دسته، سفارش) مستقر و بازسازی‌شده در Django با مجوز مالک/پشتیبان (IDOR) — با تست.
عبور از خط لولهٔ تحویل: تست واحد + تست قرارداد علیه OpenAPI + CI سبز + پذیرش PO روی staging (کالکشن Postman) — فرآیند.

وابستگی: B1، B4. مصرف‌کننده: F24.

نکته‌ی مکمل برای B4. در راستی‌آزماییِ ۱۴۰۵/۰۵/۱۱ مشخص شد api/v1 فقط auth/login، auth/me و auth/permissions دارد — refresh، logout، register و change-password در PHP وجود ندارند. چون F3 (فاز ۱، P1) به هر چهارِ این‌ها وابسته است، B4 عملاً روی مسیرِ بحرانیِ کلِ برنامه قرار می‌گیرد. جزئیات: وضعیت زنده.

≡

هم‌ترازی با نسخه‌ی نهایی demo.shub.ir — الحاقیه ۱۴۰۵/۰۵/۱۴

نسخه‌ی نهایی دمو، دامنه‌بندی «سیستم ← هلدینگ ← شرکت»، دسترسی نقش‌محور و چند فیلد محتوایی تازه دارد که در هیچ‌کدام از دو بک‌اند وجود ندارد (راستی‌آزمایی: جستجوی holding/company/scope در هر دو Swagger صفر نتیجه). این‌ها تسک‌های تازه‌اند؛ B1–B20 دست‌نخورده‌اند. مرجع فنی کامل و معیارهای پذیرش: قرارداد الزام‌آور دامنه‌بندی.

◆ تیم Backend

B21مدل داده‌ی دامنه‌بندی و عضویتP1نساخته۶ روز

موجودیت‌های Holding، Company، عضویت کاربر (companyIds)، تخصیص نقش {roleId, level, holdingId?, companyId?, groupId?} و افزودن سه فیلد scope/holdingId/companyId به همه‌ی موجودیت‌های محتوایی (فهرست کامل در قرارداد، بخش ۱). مهاجرت: رکوردهای موجود = «سراسری».

Subtaskها

#	کار	جزئیات فنی	تخمین
B21.1	جدول‌های ساختار	holdings، companies، user_company_memberships، role_grants + ایندکس‌ها	۸ ساعت
B21.2	فیلدهای scope روی محتوا	مهاجرتِ افزودن سه ستون به همه‌ی جدول‌های محتوایی + پیش‌فرض سراسری	۱۰ ساعت
B21.3	`auth/me` توسعه‌یافته	برگرداندن عضویت‌ها، تخصیص نقش و مجوزهای مؤثر (قرارداد، بخش ۴٫۱)	۶ ساعت
B21.4	seed پذیرش	بازتولید پنج سناریوی مرجع (u1/u3/u4/u7/u12) در داده‌ی تست	۴ ساعت
B21.5	تست	pytest/Pest برای مدل و `auth/me`	۸ ساعت

تعریف انجام (DoD)

جدول‌های holding/company/عضویت/تخصیص + سه ستون scope روی همهٔ محتواها (مهاجرت = سراسری)؛ auth/me عضویت+نقش+مجوز مؤثر برمی‌گرداند؛ پنج سناریوی پذیرش seed — با تست.
عبور از خط لولهٔ تحویل: تست واحد + تست قرارداد علیه OpenAPI + CI سبز + پذیرش PO روی staging (کالکشن Postman) — فرآیند.

وابستگی: B2، B5. مصرف‌کننده: F25.

B22اجرای دامنه سمت سرور (خواندن + نوشتن)P1نساخته۵ روز

حیاتی‌ترین تسک امنیتی الحاقیه. فیلتر فرانت کافی نیست — داده‌ای که به مرورگر برسد نشت کرده است. یک لایه/میدل‌ور مشترک، قانون دیده‌شدن را روی همه‌ی خواندن‌ها و «دامنه‌های مجاز انتشار» را روی همه‌ی نوشتن‌ها اعمال می‌کند.

Subtaskها

#	کار	جزئیات فنی	تخمین
B22.1	میدل‌ور/کوئری‌ست دامنه	اعمال خودکار قانون بخش ۲ قرارداد بر اساس نشستِ توکن — یک‌بار، برای همه‌ی ماژول‌ها	۱۰ ساعت
B22.2	خارج از دامنه = ۴۰۴	جزئیاتِ آیتم غیرمجاز ۴۰۴ برمی‌گرداند نه ۴۰۳ (عدم افشای وجود)	۴ ساعت
B22.3	اعتبارسنجی نوشتن	scope ارسالی ⊆ دامنه‌های مجاز نشست؛ تخلف = ۴۲۲؛ پیش‌فرض = دامنه‌ی نشست	۸ ساعت
B22.4	گارد admin و ناظم گروه	مسیرهای مدیریتی: مجوز مؤثر؛ اکشن‌های گروه: `canModerateGroup` سمت سرور	۶ ساعت
B22.5	تست نفوذ دامنه	برای هر ماژول: کاربر شرکت A نتواند آیتم شرکت B را بخواند/بسازد/ویرایش کند (IDOR بین‌دامنه‌ای)	۱۲ ساعت

تعریف انجام (DoD)

یک لایه/میدل‌ور دامنه روی همهٔ خواندن‌ها؛ آیتم خارج از دامنه = ۴۰۴؛ انتشار نامجاز = ۴۲۲؛ گارد admin و ناظم گروه؛ تست نفوذ بین‌دامنه‌ای (IDOR) برای هر ماژول سبز.
عبور از خط لولهٔ تحویل: تست واحد + تست قرارداد علیه OpenAPI + CI سبز + پذیرش PO روی staging (کالکشن Postman) — فرآیند.

وابستگی: B21. مصرف‌کننده: F25، F26.

B23هویت نصب، SSO و APIهای زنجیره‌ی واگذاریP2نساخته۴ روز

پشتیبان بخش «سیستم و ورود یکپارچه» و «هلدینگ‌ها و شرکت‌ها» در پنل راهبری دمو (F28).

Subtaskها

#	کار	جزئیات فنی	تخمین
B23.1	هویت سیستم	`GET/PATCH /system/identity` — نام/دامنه/برند + پیکربندی SSO (بدون افشای secret در GET)	۶ ساعت
B23.2	CRUD ساختار	هلدینگ/شرکت + فعال/غیرفعال — با قواعد واگذاری (مدیر هلدینگ فقط زیرمجموعه‌ی خودش)	۸ ساعت
B23.3	عضویت و تخصیص	افزودن/حذف عضویت شرکت؛ ثبت/تغییر `RoleGrant` — هر دو محدود به دامنه‌ی مدیر	۸ ساعت
B23.4	تست اتصال SSO	`POST /system/sso/test` — اعتبارسنجی endpoint بدون ذخیره	۴ ساعت

تعریف انجام (DoD)

/system/identity (بدون افشای secret در GET)؛ CRUD هلدینگ/شرکت با قواعد واگذاری؛ عضویت و RoleGrant؛ /system/sso/test — با تست.
عبور از خط لولهٔ تحویل: تست واحد + تست قرارداد علیه OpenAPI + CI سبز + پذیرش PO روی staging (کالکشن Postman) — فرآیند.

وابستگی: B21، B22. مصرف‌کننده: F28.

B24فیلدهای محتوایی جدید در مدل و قراردادP2نساخته۲ روز

مطابق قرارداد، بخش ۵: event.category (۵ مقدار) + event.capacity، news.topic (۵ مقدار)، media.duration. مهاجرت nullable + افزودن به Serializer/Resource و Swagger + پارامتر فیلترِ فهرست (?category=، ?topic=).

تعریف انجام (DoD)

فیلدهای event.category+capacity، news.topic، media.duration در مدل/Serializer/Swagger + پارامتر فیلتر (?category=،?topic=) — با تست.
عبور از خط لولهٔ تحویل: تست واحد + تست قرارداد علیه OpenAPI + CI سبز + پذیرش PO روی staging (کالکشن Postman) — فرآیند.

وابستگی: B9، B11، B12 (گسترش تحویل‌شده‌ی همان‌ها — بازکاری نیست). مصرف‌کننده: F27.

جمعِ الحاقیه‌ی Backend: ~۱۷ روز (B21–B24) — جدا از جمع فازهای ۰ تا ۶. ترتیب پیشنهادی: B21 ← B22 (مسیر بحرانی الحاقیه) ← B23/B24 موازی.

✆

پیام‌رسان کامل — هم‌ترازی با تلگرام (الحاقیه ۱۴۰۵/۰۵/۱۴)

پشتوانه‌ی سرویسِ چهار تسک Front (F29–F32). فهرست الزام‌آور قابلیت‌ها: مشخصات کامل پیام‌رسان. B14 دست‌نخورده است — این تسک‌ها روی خروجی آن سوارند. یادآوری معماری: real-time روی WebSocket (تصمیم B14.4) و کانال‌ها دامنه‌دار (B21/B22).

◆ تیم Backend

B25مدل کامل پیام (چرخه‌ی حیات تلگرامی)P1نساخته۶ روز

Subtaskها (مرجع: مشخصات، بخش ۱ و ۲)

#	کار	جزئیات فنی	تخمین
B25.1	چرخه‌ی پیام	ویرایش با پنجره + تاریخچه‌ی نسخه‌ها؛ حذف برای من/همه (tombstone برای انطباق)؛ پنجره‌ها از تنظیمات راهبر	۱۰ ساعت
B25.2	پاسخ/نقل‌قول/فوروارد	reply با quote جزئی (offsetهای متن)؛ فورواردِ چندمقصدی با ثبت مبدأ؛ گاردِ مرز دامنه	۸ ساعت
B25.3	زمان‌بندی و پیش‌نویس	صف پیام‌های زمان‌بندی‌شده (Celery/صف موجود) + CRUD؛ draft per-چت per-کاربر	۸ ساعت
B25.4	واکنش و پین	واکنش‌های چندگانه با فهرست کاربران؛ پین چندتایی مرتب؛ مجموعه‌ی واکنش مجاز از راهبری	۶ ساعت
B25.5	موجودیت‌های متن	ذخیره‌ی entities قالب‌بندی (نه HTML خام)؛ اعتبارسنجی؛ رندر امن	۶ ساعت
B25.6	تست	پنجره‌ها، حذف دوطرفه، فوروارد بین‌دامنه‌ای (باید ۴۲۲ شود)	۱۰ ساعت

تعریف انجام (DoD)

ویرایش با پنجره و تاریخچهٔ نسخه؛ حذف دوطرفه با tombstone؛ فورواردِ چندمقصدی با گارد دامنه؛ زمان‌بندی؛ ذخیرهٔ entities قالب‌بندی (نه HTML خام) — با تست.
عبور از خط لولهٔ تحویل: تست واحد + تست قرارداد علیه OpenAPI + CI سبز + پذیرش PO روی staging (کالکشن Postman) — فرآیند.

وابستگی: B14، B21. مصرف‌کننده: F29.

B26بلادرنگ، رسیدها، جستجو و syncP1نساخته۶ روز

Subtaskها (مرجع: مشخصات، بخش ۵ و ۶)

#	کار	جزئیات فنی	تخمین
B26.1	پروتکل WS	رویدادهای typed: پیام/ویرایش/حذف/واکنش/تایپ/حضور/رسید — نسخه‌دار و مستند	۸ ساعت
B26.2	رسید تحویل/خواندن	cursor خواندن per-عضو per-چت؛ seen-by گروه کوچک؛ به‌روزرسانی جمعی بهینه	۸ ساعت
B26.3	sync چنددستگاهی	وضعیت خوانده/پیش‌نویس بین نشست‌ها؛ بازیابی event از offset پس از قطعی (آفلاین)	۱۰ ساعت
B26.4	جستجوی پیام	ایندکس Elasticsearch موجود: سراسری + درون‌چت + فیلتر نوع/فرستنده/تاریخ — با احترام به دامنه	۱۰ ساعت
B26.5	اعلان per-چت	ترجیحات بی‌صدا/مدت/فقط‌منشن per-کاربر per-چت + شمارنده‌های تفکیکی	۶ ساعت

تعریف انجام (DoD)

پروتکل WS نسخه‌دار و مستند؛ رسید تحویل/خواندن + seen-by؛ sync چنددستگاهی و بازیابی offset پس از قطعی؛ جستجوی Elasticsearch دامنه‌محور — با تست.
عبور از خط لولهٔ تحویل: تست واحد + تست قرارداد علیه OpenAPI + CI سبز + پذیرش PO روی staging (کالکشن Postman) — فرآیند.

وابستگی: B14، B25. مصرف‌کننده: F29، F32.

B27رسانه، فایل و صوتP2نساخته۵ روز

Subtaskها (مرجع: مشخصات، بخش ۳)

#	کار	جزئیات فنی	تخمین
B27.1	آپلود مقاوم	آپلود قطعه‌قطعه با ازسرگیری؛ سقف حجم/نوع از تنظیمات؛ اسکن ضدویروس موجود	۱۰ ساعت
B27.2	پردازش رسانه	بندانگشتی، ابعاد، مدت و شکل موج صوت (استخراج سمت سرور)؛ آلبوم گروه‌شده	۸ ساعت
B27.3	گالری چت	endpointهای رسانه/فایل/لینک/صوت per-چت با صفحه‌بندی	۶ ساعت
B27.4	پیش‌نمایش لینک	unfurl سمت سرور با کش و allowlist؛ کارت اختصاصی لینک‌های داخلی	۶ ساعت
B27.5	دسترسی فایل	URLهای امضاشده با انقضا — دانلود فقط برای اعضای همان چت/دامنه	۶ ساعت

تعریف انجام (DoD)

آپلود قطعه‌قطعه با ازسرگیری و اسکن ضدویروس؛ استخراج بندانگشتی/مدت/شکل‌موج؛ گالری چت؛ unfurl امن؛ URL امضاشدهٔ دانلود per-دامنه — با تست.
عبور از خط لولهٔ تحویل: تست واحد + تست قرارداد علیه OpenAPI + CI سبز + پذیرش PO روی staging (کالکشن Postman) — فرآیند.

وابستگی: B25. مصرف‌کننده: F30.

B28گروه/کانال پیشرفته، مدیریت و انطباقP2نساخته۶ روز

Subtaskها (مرجع: مشخصات، بخش ۴ و ۶)

#	کار	جزئیات فنی	تخمین
B28.1	تاپیک‌ها	موجودیت topic ذیل گروه؛ شمارنده/اعلان per-تاپیک	۸ ساعت
B28.2	ناظمان ریزدانه	ماتریس مجوز per-ناظم؛ محدودسازی/بن با مدت؛ Slow Mode؛ اجرای سمت سرور	۱۰ ساعت
B28.3	دعوت و عضویت	لینک با انقضا/سقف/QR؛ صف Join Request با تایید؛ حساب مهمان با انقضا	۸ ساعت
B28.4	کانال کامل	امضا، شمارش بازدید، اتصال گروه بحث برای نظرات پست	۶ ساعت
B28.5	Poll، auto-delete، بلاک/گزارش	نظرسنجی/آزمون درون‌چت؛ زمان‌بند حذف خودکار؛ بلاک DM و صف گزارش تخلف برای راهبر	۸ ساعت
B28.6	انطباق	Admin Log دائمی متصل به Audit؛ Compliance Export با تاریخچه‌ی ویرایش/حذف — فقط نقش انطباق	۸ ساعت

تعریف انجام (DoD)

تاپیک؛ مجوز ریزدانهٔ ناظم و Slow Mode؛ لینک دعوت/Join Request/مهمان؛ کانال با امضا/بازدید/نظر؛ Poll/auto-delete/بلاک-گزارش؛ Admin Log دائمی + Compliance Export — با تست.
عبور از خط لولهٔ تحویل: تست واحد + تست قرارداد علیه OpenAPI + CI سبز + پذیرش PO روی staging (کالکشن Postman) — فرآیند.

وابستگی: B25، B22 (گارد دامنه). مصرف‌کننده: F31.

B29زیرساخت تماس/جلسه‌ی زندهP3اختیاری — منتظر تصمیم PO≈۷ روز*

استقرار و ادغام SDK انتخابی (Jitsi/LiveKit) پشت SSO و دامنه‌بندی؛ توکن اتاق، ضبط، سیاست نگه‌داری.

تخمین مشروط (*به‌فرض SDK آماده)

#	کار	تخمین
B29.1	استقرار self-host + TLS + TURN/STUN پشت شبکه‌ی سازمان	۱۲ ساعت
B29.2	اتصال هویت: توکن اتاق امضاشده از نشست ما (JWT) — بدون لاگین دوم	۱۰ ساعت
B29.3	گارد دامنه: اتاقِ کانال فقط برای اعضای همان کانال/دامنه	۶ ساعت
B29.4	ضبط جلسه + ذخیره در استوریج + سیاست نگه‌داری/دسترسی	۱۲ ساعت
B29.5	رویدادهای چت (شروع/پایان/مدت) + تست بار ۲۰ شرکت‌کننده	۱۰ ساعت

تعریف انجام (DoD)

استقرار self-host SDK پشت SSO و دامنه؛ توکن اتاق از JWT ما؛ گارد دامنهٔ اتاق کانال؛ ضبط با سیاست نگه‌داری؛ تست بار ۲۰ شرکت‌کننده.
عبور از خط لولهٔ تحویل: تست واحد + تست قرارداد علیه OpenAPI + CI سبز + پذیرش PO روی staging (کالکشن Postman) — فرآیند.

وابستگی: تصمیم PO. مصرف‌کننده: F33. خارج از جمع الحاقیه.

جمعِ الحاقیه‌ی پیام‌رسان (Backend): ~۲۳ روز (B25–B28) — جدا از همه‌ی جمع‌های قبلی. مسیر بحرانی: B25 ← B26؛ B27/B28 موازی پس از B25.

Σ+

جمع‌بندی تخمین‌ها — همه‌ی بلوک‌ها (الحاقیه ۱۴۰۵/۰۵/۱۴)

جمعِ روزنفرِ تک‌تک تسک‌ها، به تفکیک بلوک. اعداد روز-نفر (person-day) اند و مستقل از تعداد تیم؛ تبدیل به تقویم در انتهای جدول.

بلوک	تسک‌ها	Front (روزنفر)	Backend (روزنفر)	وضعیت
هسته‌ی قرارداد (فاز ۰–۶)	F1–F20 · B1–B19	۹۰	۸۶	در حال اجرا
دامنه‌ی کشف‌شده	F21–F24 · B20	۱۳	۲	منتظر تصمیم PO
هم‌ترازی دامنه‌بندی	F25–F28 · B21–B24	۱۲	۱۷	الحاقیه — الزام‌آور
پیام‌رسان کامل (تلگرام)	F29–F32 · B25–B28	۲۸	۲۳	الحاقیه — خواسته‌ی محصول
مجموع الزامی (بدون تماس)		۱۴۳	۱۲۸	۲۷۱ روزنفر
تماس صوتی/تصویری (اختیاری — F33/B29)		+۶	+۷	پس از تصمیم PO
مجموع با تماس		۱۴۹	۱۳۵	۲۸۴ روزنفر

تبدیل به تقویم (ترکیب فعلی: ۴F + ۳B + QA + DevOps، اجرای موازی دو رشته). با بهره‌وریِ واقع‌بینانه‌ی ~۸۰٪ (جلسه/ریویو/رگرسیون):

سناریو	Front	Backend	پروژه (موازی)
فقط هسته (فاز ۰–۶) — خط پایه‌ی قبلی	~۹ هفته	~۹ هفته	~۹–۱۱ هفته
الزامی کامل (هسته + دامنه‌بندی + پیام‌رسان)	~۹ هفته	~۱۱ هفته	~۱۱–۱۳ هفته
+ دامنه‌ی کشف‌شده (F21–F24/B20)	+~۱ هفته	—	~۱۲–۱۴ هفته
+ تماس (F33/B29)	+~۰.۵ هفته	+~۰.۵ هفته	~۱۳–۱۵ هفته

گلوگاه = Backend (۱۲۸ روزنفر ÷ ۳ نفر). تسک‌های الزام‌آورِ مسیر بحرانی: B21→B22 (دامنه) و B25→B26 (بلادرنگ چت). اعداد تخمینی‌اند و در Planning هر Sprint دوباره کالیبره می‌شوند.

مرجع الزام‌آور — قرارداد دامنه‌بندی و دسترسی (سیستم ← هلدینگ ← شرکت)

مشخصات دقیقِ مدل چندسطحی، همان‌طور که در نسخه‌ی نهایی demo.shub.ir پیاده و راستی‌آزمایی شده. مبنای الزام‌آورِ تسک‌های F25–F28 / B21–B24. مرجع کد: src/data/tenancy.ts و src/context/TenancyContext.tsx در مخزن پروتوتایپ.

مهم‌ترین قاعده: فیلتر باید سمت سرور باشد. در پروتوتایپ فیلتر در فرانت انجام می‌شود چون داده mock است؛ در محصول واقعی اگر فیلتر فقط در فرانت باشد یعنی داده‌ی شرکت‌های دیگر واقعاً به مرورگر کاربر رسیده و فقط نمایش داده نشده — این نشتی داده است. سرور موظف است بر اساس نشستِ برآمده از توکن، هم «خواندن» را فیلتر و هم «نوشتن» را اعتبارسنجی کند.

موجودیت‌ها

موجودیت	فیلدها	توضیح
`SystemIdentity`	`name, shortName, domain, color, ssoProvider, ssoEndpoint, ssoDomainHint, autoProvision, allowLocalLogin`	هر نصب = یک مشتری. `ssoProvider ∈ {بدون SSO, LDAP/AD, SAML 2.0, OIDC, OTP موبایل}`
`Holding`	`id, name, color, lead?, active`	n هلدینگ زیر هر نصب
`Company`	`id, name, holdingId, field?, users, active`	n شرکت زیر هر هلدینگ
`UserProfile` (افزوده)	`companyIds?: string[]`	عضویت — کاربر خودش انتخاب نمی‌کند؛ مدیر شرکت او را اضافه می‌کند
`RoleGrant`	`roleId, level ∈ {سیستم, هلدینگ, شرکت, گروه}, holdingId?, companyId?, groupId?`	تخصیص نقش = (کاربر، نقش، دامنه). `groupId` فقط برای سطح «گروه» (ناظم گروه)
`Scoped` (میکس‌این همه‌ی محتواها)	`scope? ∈ {سراسری, هلدینگ, شرکت}, holdingId?, companyId?`	روی همه‌ی موجودیت‌های محتوایی/کاری. نبودِ `scope` = «سراسری» (سازگاری با داده‌ی قدیمی)

پوشش Scoped — الزامی روی این موجودیت‌ها: خبر، بلاگ، رویداد، رسانه، انجمن (موضوع)، گروه، سند دانش، کانال گفتگو، پروژه، قالب فرآیند*، قرارداد، پروپوزال/طرح صندوق (هر دو نوع)، فراخوان پژوهشی، دوره‌ی آموزشی، تیکت، نظرسنجی، آزمون، مسابقه، چالش. (* قالب فرآیند و «جایزه نوآوری» سراسری‌اند — جایزه ذاتاً رویداد سطح بنیاد است.) پیام مستقیم (DM) دامنه‌بندی نمی‌شود — عضویت‌محور است.

نشست (Session) — دامنه از «کاربر» محاسبه می‌شود، نه از انتخاب او

در لحظه‌ی ورود، سرور از روی عضویت‌ها و تخصیصِ نقش، نشست را می‌سازد. کاربر هیچ سوالی درباره‌ی هلدینگ/شرکتش نمی‌بیند.

سطح نشست	چه می‌بیند	سوییچر هدر	دامنه‌های مجاز انتشار
سیستم (بدون عضویت + نقش سیستمی)	همه‌چیز	«مشاهده به‌عنوان» — همه‌ی دامنه‌ها	سراسری، هلدینگ، شرکت
هلدینگ (نقش سطح هلدینگ)	سراسری + کل هلدینگ خودش	کل هلدینگ + شرکت‌های همان هلدینگ	هلدینگ، شرکت
شرکت — عضو ۱ شرکت	سراسری + همان شرکت	ندارد — فقط برچسب خواندنی	فقط شرکت (بدون گزینه: «منتشر می‌شود برای: X»)
شرکت — عضو چند شرکت	سراسری + شرکت‌های عضو	فقط همان شرکت‌های عضو	فقط شرکت (بین عضویت‌ها)

قانون دیده‌شدن (مرجع: isVisibleForSession) — آیتم دیده می‌شود اگر: scope=سراسری (همیشه) · scope=هلدینگ و هلدینگ آیتم ∈ هلدینگ‌های کاربر · scope=شرکت و شرکت آیتم ∈ شرکت‌های عضو. وقتی کاربر روی یک دامنه‌ی مشخص ایستاده (سوییچر)، همان تنگ‌تر اعمال می‌شود. نشستِ سطح سیستم بدون دامنه‌ی فعال، همه‌چیز را می‌بیند.

زنجیره‌ی واگذاری اختیار

نقش	می‌تواند	نمی‌تواند
مدیر سیستم	ساخت/حذف هلدینگ؛ انتصاب مدیر هلدینگ؛ همه‌چیز	—
مدیر هلدینگ	ساخت/مدیریت شرکت‌های هلدینگ خودش؛ انتصاب مدیر شرکت	حذف هلدینگ؛ هر کاری بیرون از هلدینگ خودش
مدیر شرکت	افزودن/حذف کاربرانِ شرکت خودش؛ تخصیص نقش در دامنه‌ی خودش	هر کاری بیرون از شرکت خودش
ناظم گروه (`level=گروه` + `groupId`)	ویرایش/حذف گروهِ خودش؛ اخراج عضو همان گروه	مدیریت هر گروه دیگر؛ پنل راهبری
عضو عادی	مصرف و تولید محتوا در دامنه‌ی عضویتش	پنل راهبری (منو پنهان و مسیر گارد‌شده)؛ انتشار خارج از شرکتش

دسترسی مؤثر از نقشِ تخصیص‌یافته محاسبه می‌شود (کاربر بدون تخصیص = «عضو عادی» r4). دسترسی راهبری = سطح سیستم/هلدینگ، یا نقشی که یکی از مجوزهای users.create / users.edit / roles.edit / settings.system را دارد. گاردِ سمت سرور برای مسیرهای admin الزامی است — پنهان‌کردن منو کافی نیست.

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

#	الزام	جزئیات
۱	نشست در توکن/پاسخ `auth/me`	`memberCompanyIds[]`، `grant {roleId, level, holdingId?, companyId?, groupId?}` و مجوزهای مؤثر باید از `auth/me` برگردد؛ فرانت هیچ‌چیز را خودش استنتاج نمی‌کند.
۲	فیلتر خواندن	همه‌ی endpointهای فهرست/جزئیات، قانون دیده‌شدن بخش ۲ را روی داده اعمال می‌کنند. آیتم خارج از دامنه = `404` (نه `403`، تا وجودش لو نرود).
۳	اعتبارسنجی نوشتن	`scope/holdingId/companyId`ی ارسالی باید داخل «دامنه‌های مجاز انتشار» نشست باشد؛ در غیر این صورت `422`. مقدار پیش‌فرض = دامنه‌ی فعال نشست.
۴	زنجیره‌ی واگذاری	APIهای مدیریت هلدینگ/شرکت/عضویت/تخصیص نقش، قواعد بخش ۳ را سمت سرور اجرا می‌کنند.
۵	سازگاری داده‌ی قدیمی	رکوردهای بدون `scope` = «سراسری». مهاجرت اولیه می‌تواند همه را سراسری بگذارد و به‌تدریج دامنه‌دار شود.

فیلدهای محتوایی جدید (قرارداد داده)

این فیلدها در نسخه‌ی نهایی دمو وجود دارند و باید در مدل و قرارداد هر دو بک‌اند بیایند (تسک B24).

موجودیت	فیلد	نوع/مقادیر	مصرف در UI
رویداد	`category`	`جلسه \| کارگاه \| وبینار \| همایش \| آموزش`	چیپ فیلتر + نشان روی ردیف (عمومی و داشبورد)
رویداد	`capacity`	`number`	«X از Y ظرفیت» + وضعیت «در حال ثبت‌نام»
خبر	`topic`	`اقتصادی \| اجتماعی \| فرهنگی \| عمرانی \| سازمانی`	چیپ فیلتر + تگ روی هیرو/کارت/ردیف
رسانه	`duration`	`"mm:ss"` — فقط ویدیو	نشان روی بندانگشتی
کاربر	`companyIds`	`string[]`	مبنای کل نشست — بخش ۲

سناریوهای مرجع پذیرش (داده‌ی seed دمو)

این پنج سناریو معیار پذیرش پیاده‌سازی بک‌اند است — با «ورود به‌عنوان» در demo.shub.ir قابل مشاهده‌اند.

کاربر	عضویت / نقش	رفتار مورد انتظار
u1 — پایگاه اطلاع‌رسانی	بدون عضویت + r1 (سیستم)	همه‌چیز؛ سوییچر ۱۷ گزینه؛ هر سه دامنه‌ی انتشار؛ پنل راهبری کامل
u3 — عضو ۱ شرکت (بهنوش)	`[c-behnoush]`	سوییچر ندارد؛ فقط سراسری+بهنوش؛ فرم انتشار بدون گزینه («منتشر می‌شود برای: بهنوش»)؛ بدون پنل راهبری
u4 — عضو ۲ شرکت + r2 هلدینگ فردوس	`[c-dashtnaz, c-ferdows-agri]`	سوییچر: کل هلدینگ + ۲ شرکت؛ انتشار هلدینگ/شرکت؛ راهبریِ محدود به هلدینگ خودش
u7 — ناظم گروه g1	`[c-ferdows-agri]` + r3/گروه/g1	دکمه‌های مدیریتی فقط در گروه g1؛ در g2 هیچ اکشن مدیریتی ندارد
u12 — عضو ۳ شرکت	`[c-pak, c-behnoush, c-zamzam]`	سوییچر دقیقاً همین ۳ شرکت؛ محتوای فهرست‌ها با سوییچ واقعاً عوض می‌شود

✆

مرجع الزام‌آور — مشخصات کامل پیام‌رسان (هم‌ترازی با تلگرام)

پیام‌رسانِ موتوشاب باید تمام قابلیت‌های تلگرام (به‌جز موارد حذف عمدی) به‌علاوه‌ی قابلیت‌های سازمانی را داشته باشد. مبنای الزام‌آورِ تسک‌های F29–F33 / B25–B29. برای هر قابلیت: جزئیات، وضعیت فعلی در دمو، و تسک متناظر.

سه قاعده‌ی برش (Scope Cut): (۱) هر قابلیت تلگرام که به «هویت شخصی/شبکه‌ی عمومی» گره خورده (شماره‌تلفن عمومی، People Nearby، استوری، Premium) در بستر سازمانی حذف عمدی است و در جدول با «—حذف» مشخص شده. (۲) استیکر/GIF به‌صورت «مجموعه‌ی سازمانیِ مدیریت‌شده» می‌آید نه فروشگاه باز. (۳) تماس صوتی/تصویری طبق تصمیم معماری موجود (برون‌سپاری/ادغام، نه ساخت از صفر) تسک اختیاریِ جداست (F33/B29).

پیام‌رسانی پایه

قابلیت	جزئیات الزام‌آور	در دمو	تسک
ارسال متن	ارسال با Enter، خط جدید با Shift+Enter، پیش‌نویس هر گفتگو جدا ذخیره و بین دستگاه‌ها sync شود	✅ (بدون draft-sync)	F29 · B25
ویرایش پیام	پنجره‌ی ویرایش قابل‌تنظیم (پیش‌فرض ۴۸ ساعت)، برچسب «ویرایش‌شده»، تاریخچه‌ی ویرایش برای انطباق	✅ (بدون پنجره/تاریخچه)	F29 · B25
حذف پیام	«حذف برای من» / «حذف برای همه» (پنجره‌ی قابل‌تنظیم)؛ در کانال: فقط ناظم	نیمه (حذف ساده)	F29 · B25
پاسخ (Reply)	نقل‌قول پیام با پرش به اصل؛ نقل‌قول بخشی از متن (Quote انتخابی — تلگرام ۲۰۲۳)	✅ reply · ❌ quote انتخابی	F29
رشته‌ی پاسخ (Thread)	پنل رشته کنار گفتگو، شمارنده‌ی «N پاسخ در رشته»، دنبال‌کردن رشته	✅	—
فوروارد	تکی و چندتایی، با/بدون نامِ فرستنده، به چند مقصد هم‌زمان؛ احترام به مرز دامنه (فوروارد به کانالِ خارج از دامنه ممنوع)	✅ تکی	F29 · B25
انتخاب چندتایی	انتخاب چند پیام → فوروارد/حذف/کپی گروهی	❌	F29
پیام زمان‌بندی‌شده	ارسال در زمان معین + «ارسال بی‌صدا» (بدون نوتیف گیرنده)	❌	F29 · B25
واکنش (Reaction)	چند واکنش روی هر پیام، شمارنده + فهرست واکنش‌دهنده‌ها؛ مجموعه‌ی مجاز توسط راهبر	✅ پایه	F29 · B25
پین پیام	چند پین هم‌زمان با نوار پیمایش بین پین‌ها (مثل تلگرام)، پین با/بدون اعلان	✅ تک‌پین	F29
ذخیره‌شده‌ها	Saved Messages شخصی + ذخیره از هر گفتگو	✅	—
رسید خواندن	تیک ✓ (رسیده) / ✓✓ (خوانده)؛ در گروه‌های کوچک «چه کسانی خواندند»	✅ تیک‌ها · ❌ seen-by	F32 · B26
در حال تایپ…	نشانگر تایپ per-چت؛ در گروه با نام افراد	✅ در DM	B26
جداکننده‌ی خوانده‌نشده	خط «پیام‌های خوانده‌نشده» هنگام بازکردن چت + اسکرول به همان‌جا	❌	F32
تایمر حذف خودکار	Auto-delete per-چت (۱ روز/۱ هفته/۱ ماه/سفارشی) — برای گفتگوهای حساس سازمانی	❌	F31 · B28

قالب‌بندی و محتوای غنی

قابلیت	جزئیات الزام‌آور	در دمو	تسک
قالب‌بندی متن	پررنگ، مورب، زیرخط، خط‌خورده، `مونو/کد`، بلوک کد، نقل‌قول، اسپویلر (متن پنهان تا لمس)، لینک با متن دلخواه — با میانبر کیبورد و منوی انتخاب متن	❌	F29
پیش‌نمایش لینک	کارت پیش‌نمایش (عنوان/تصویر/توضیح) + امکان حذف پیش‌نمایش قبل از ارسال؛ لینک‌های داخلی سامانه کارت اختصاصی (خبر/سند/رویداد)	❌	F29 · B27
منشن	`@نام` با پیشنهاد خودکار، هایلایت و شمارنده‌ی منشن روی چت؛ `@all/@here` فقط ناظم	✅ پایه	F29
هشتگ	کلیک‌پذیر → جستجوی همان برچسب در گفتگو	❌	F32
ایموجی	پیکر ایموجی با جستجو و پرکاربردها؛ ایموجی تکی بزرگ‌نمایی شود	✅ پایه	F29
استیکر سازمانی	مجموعه‌های استیکرِ تأییدشده توسط راهبر (برند سازمان)؛ بدون فروشگاه باز	❌ (اختیاری)	F30 · B27
نظرسنجی درون‌چت	Poll تلگرامی: چندگزینه‌ای، ناشناس/آشکار، چندانتخابی، حالت آزمون (Quiz) — جدا از ماژول نظرسنجی سازمانی	❌	F31 · B28

رسانه، فایل و صوت

قابلیت	جزئیات الزام‌آور	در دمو	تسک
عکس و ویدیو	ارسال با کپشن، چندتایی به‌صورت آلبوم گروه‌شده، فشرده/اصل، ویرایشگر ساده (برش/چرخش/قلم)	نیمه (تک‌عکس)	F30 · B27
نمایشگر رسانه	تمام‌صفحه با ورق‌زدن بین رسانه‌های همان چت، زوم، ذخیره، نمایش فرستنده/زمان	❌	F30
پیام صوتی	ضبط با نگه‌داشتن + قفل ضبط، شکل موج، پخش با سرعت ۱×/۱.۵×/۲×، ادامه‌ی پخش هنگام جابه‌جایی بین چت‌ها	✅ ضبط پایه	F30 · B27
پیام ویدیویی (دایره‌ای)	ضبط ویدیوی کوتاه دایره‌ای (video message تلگرام)	❌ (اختیاری)	F30
فایل/سند	هر نوع فایل تا سقف تنظیم‌شده‌ی راهبر، نوار پیشرفت آپلود/دانلود قابل‌لغو، ازسرگیری آپلود قطع‌شده	نیمه (UI پیوست)	F30 · B27
گالری اشتراکی چت	تب‌های «رسانه / فایل / لینک / صوت» در پروفایل هر چت — مثل Shared Media تلگرام	✅ رسانه (پایه)	F30 · B27
تنظیم دانلود خودکار	per-نوع و per-شبکه (داده/وای‌فای) — برای کاربر موبایل	❌	F32
اشتراک مخاطب/موقعیت	اشتراک کارت کاربر سازمانی؛ موقعیت زنده «—حذف» (کاربرد سازمانی ندارد، ریسک حریم خصوصی)	❌ / —حذف	F30

گروه‌ها، کانال‌ها و تاپیک‌ها

قابلیت	جزئیات الزام‌آور	در دمو	تسک
کانال (Broadcast)	فقط ناظم‌ها می‌نویسند؛ امضای نویسنده، شمارنده‌ی بازدید هر پست، نظرات ذیل پست از طریق گروه بحث متصل	نیمه (کانال ساده)	F31 · B28
گروه	اعضا، توضیحات، قوانین پین‌شده؛ ظرفیت بالا	✅ پایه	B28
تاپیک‌ها (Forum Groups)	گروه‌های تاپیک‌دار تلگرام: هر گروه چند تاپیک مجزا با فهرست، آیکن و اعلان جدا — برای گروه‌های بزرگ سازمانی حیاتی	❌	F31 · B28
مجوزهای ریزدانه‌ی ناظم	مثل تلگرام: تفکیک حق حذف پیام / بن / دعوت / پین / تغییر اطلاعات / افزودن ناظم — per-ناظم	❌ (ناظم واحد)	F31 · B28
محدودیت اعضا	محدودکردن عضو خاص (فقط‌خواندن، بدون رسانه) با مدت؛ بن با پاک‌سازی پیام‌ها	❌	F31 · B28
لینک دعوت	لینک + QR، با انقضا/سقف استفاده، درخواست عضویت با تایید ناظم (Join Request)	❌	F31 · B28
حالت آهسته (Slow Mode)	فاصله‌ی اجباری بین پیام‌های هر عضو (۱۰ث تا ۱س)	❌	F31 · B28
گزارش اقدامات ناظمان	Admin Log ۴۸ساعته‌ی تلگرام → در نسخه‌ی سازمانی: دائمی و متصل به Audit Log انطباق	❌	B28
دامنه‌بندی کانال	کانال‌ها `Scoped`‌اند (سراسری/هلدینگ/شرکت) — قرارداد دامنه‌بندی	✅	B21

سازماندهی، جستجو و اعلان

قابلیت	جزئیات الزام‌آور	در دمو	تسک
پوشه‌های چت	Chat Folders تلگرام: پوشه‌های سفارشی با قواعد شمول/استثنا + شمارنده‌ی خوانده‌نشده per-پوشه؛ پوشه‌های پیش‌ساخته‌ی سازمانی (هلدینگ من/شرکت من)	نیمه (۳ دسته‌ی ثابت)	F31
آرشیو	آرشیو چت با سوایپ، خروج خودکار از آرشیو با پیام جدید (قابل‌تنظیم)	✅ پایه	F31
پین چت / علامت خوانده‌نشده	سنجاق گفتگو بالای فهرست؛ mark-as-unread دستی	✅ علاقه‌مندی · ❌ unread دستی	F31
جستجوی سراسری چت	روی همه‌ی گفتگوها + پرش به پیام در بستر خودش؛ فیلتر بر اساس نوع (رسانه/فایل/لینک/صوت) و فرستنده	✅ فیلتر نام چت	F32 · B26
جستجوی درون‌چت + پرش به تاریخ	جستجو داخل یک گفتگو، پیمایش بین نتایج، Jump to Date با تقویم شمسی	❌	F32 · B26
اعلان per-چت	بی‌صدا با مدت (۱س/۸س/۲روز/همیشه)، استثناها، پیش‌نمایش روشن/خاموش، «فقط منشن‌ها» برای کانال شلوغ	✅ بی‌صدا ساده	F32 · B26
شمارنده‌ها	Badge خوانده‌نشده per-چت/پوشه/کل؛ تفکیک منشن (@) از پیام عادی	✅ پایه	F32

همگام‌سازی، حریم خصوصی و سازمانی

قابلیت	جزئیات الزام‌آور	در دمو	تسک
چنددستگاهی	وضعیت خوانده/پیش‌نویس/ارسال بین تب‌ها و دستگاه‌ها sync؛ فهرست نشست‌ها و خروج از راه دور (به «امنیت و نشست‌ها»ی موجود وصل می‌شود)	❌ sync	B26
آفلاین	صف ارسال آفلاین با retry، کش تاریخچه، حالت optimistic با برگشت در خطا	نیمه (optimistic)	F32 · B26
حضور (Presence)	چهار وضعیت (آنلاین/غایب/مزاحم نشوید/نامرئی) + «آخرین بازدید» با سطوح حریم خصوصی تلگرامی (همه/اعضای سازمان/هیچ‌کس)	✅ چهار وضعیت	B26
مسدودسازی/گزارش	بلاک کاربر در DM؛ گزارش پیام/کاربر به راهبر با دسته‌ی تخلف	❌	F31 · B28
بات و وب‌هوک	حساب بات با ارسال از API، وب‌هوک ورودی/خروجی، دکمه‌های اینلاین زیر پیامِ بات (inline keyboard)	✅ تعریف در راهبری	B28
دستور اسلش	`/command` با منوی پیشنهاد و پارامتر — اجرا از طریق همان بات‌ها	✅	—
حساب مهمان	دسترسی محدود به کانال‌های مشخص با انقضا (پیمانکاران)	✅ تعریف در راهبری	B28
خروجی انطباق	Compliance Export گفتگوها با فیلتر بازه/کاربر/کانال + تاریخچه‌ی ویرایش/حذف — فقط نقش انطباق	✅ UI در راهبری	B28
—حذف عمدی	استوری، People Nearby، شماره‌تلفن عمومی، Premium/هدیه، کیف پول — در بستر سازمانی بی‌معنا	—	—

تماس صوتی/تصویری و جلسات زنده (اختیاری — تصمیم PO)

طبق تصمیم معماری موجود، ساخت موتور تماس از صفر ممنوع است؛ گزینه‌ها: ادغام SDK آماده (Jitsi/LiveKit self-host) پشت همان هویت. دامنه‌ی هدف: تماس ۱:۱ صوتی/تصویری، گفتگوی صوتی گروهی (Voice Chat تلگرام) روی کانال/گروه با دست‌بلندکردن و ضبط جلسه، اشتراک صفحه. تسک‌های F33/B29 فقط پس از تایید PO فعال می‌شوند و در جمع الحاقیه حساب نشده‌اند.