Motoshub · Delivery Plan · Front

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

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

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

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

استک و قراردادها. Next.js App Router + TypeScript strict + TanStack Query (server-state) + Zustand (client-state) + RHF+Zod (فرم). همه‌ی درخواست‌ها فقط از libs/axios.ts با baseURL=/api/v1؛ فرانت نباید بداند پاسخ از PHP است یا Django.

الگوی هر ماژول. service (توابع خالص axios) ← hookهای query/mutation (کلیدهای cache استاندارد: [module, list, params] / [module, id]) ← کامپوننت. invalidation بعد از هر mutation. حالت‌های loading=اسکلتون، empty=EmptyState، error=پیام+retry برای هر فهرست الزامی است.

ظاهر. توکن‌های طراحی پروتوتایپ (ink/brand/navy + دارک‌مود توکنی + Vazirmatn) مبنای F2 است — از demo.shub.ir به‌عنوان مرجع پیکسلی استفاده کنید؛ RTL و aria و فوکوس کیبورد در DoD است.

مرجع پذیرش. رفتار هر صفحه = همان صفحه در demo.shub.ir؛ معیارهای پذیرش هر تسک در همین سند، و عبور از خط لوله‌ی تحویل و کیفیت الزامی است.

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

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

تصحیحِ ۱۴۰۵/۰۵/۱۱ — چه چیزی امروز واقعاً پاسخ می‌دهد. پیش‌تر اینجا نوشته شده بود «PHP همین حالا هر ۲۹۳ عملیات را پاسخ می‌دهد». اندازه‌گیریِ زنده نشان می‌دهد آن ۲۹۳ عملیات در برنچِ API مخزن هست ولی روی production مستقر نیست؛ امروز ۱۱ منبع از ۵۵ پاسخ می‌دهند: auth · users · blogs · news · groups · events · photos · albums · videos · forum · files.

یعنی F8، F9، F10، F11، F12، F13، F14 همین امروز دادهٔ واقعی دارند؛ اما F7 (فید)، F15 (چت)، F20.1 (اعلان)، F20.2 (جستجو) فعلاً داده ندارند و باید با لایه‌ی mockِ قابل‌تعویض ساخته شوند. فهرستِ کامل و روشِ اندازه‌گیری: وضعیت زنده.

فاز	محتوا	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 دارد؛ دامنه‌ی دید از عضویتِ کاربر محاسبه می‌شود نه از انتخاب او؛ و فیلتر/اعتبارسنجی باید سمت سرور باشد. مشخصات کامل و سناریوهای پذیرش: قرارداد دامنه‌بندی و دسترسی.

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

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

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

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

یک HTTP client فعال به‌عنوان تنها منبع درخواست‌ها؛ کد/وابستگی مرده حذف؛ tsc --noEmit و ESLint سبز.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

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

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

توکن‌های طراحی و کامپوننت‌های پایه ساخته و مستند؛ سوییچ تم روشن/تیره ماندگار و بدون flash؛ کنتراست AA در هر دو تم.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

وابستگی: F1.

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

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

◆ تیم 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 در `api/v1` وجود ندارد (فقط `auth/login`، `auth/me`، `auth/permissions` موجود است)؛ پیش‌نیازش B4 است	۴ ساعت

معیار پذیرش

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

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

ورود/خروج واقعی؛ refresh خودکار روی ۴۰۱ با صف و retry یک‌باره؛ middleware مسیرهای خصوصی؛ هیدریشن نشست از auth/me؛ خطای ۴۲۲ فیلدی.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

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

الحاقیه‌ی ۱۴۰۵/۰۵/۱۴ (این تسک را تغییر نمی‌دهد): در نسخه‌ی نهایی، پاسخ auth/me عضویت و تخصیص نقش را هم می‌آورد و نشستِ دامنه از همان ساخته می‌شود ← F25 و قرارداد دامنه‌بندی.

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 و عنوان	عنوانِ صفحه‌ی پویا و مسیر بر اساس روت	۳ ساعت

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

پوسته/سایدبار/هدر ریسپانسیو تا ۳۷۵px بدون سرریز افقی؛ آیتم فعالِ مسیر هایلایت؛ ناوبری موبایل کامل.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

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

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

الگوی service+hook با کلید کش استاندارد؛ حالت loading=اسکلتون / empty=EmptyState / error=retry برای هر فهرست؛ invalidation پس از هر mutation.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

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

هسته‌ی محتوا

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

◆ تیم Front

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

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

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

Subtaskها

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

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

داشبورد با دادهٔ واقعی API (بدون mock)؛ حالت خالی/loading؛ ویجت‌ها deep-link‌پذیر.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

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

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

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

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

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

Subtaskها

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

معیار پذیرش

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

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

اسکرول بی‌نهایت فید؛ کامپوزر با پیوست PDF/Word/عکس و نوار پیشرفت؛ دسته‌بندی انتشار عمومی؛ لایک/نظر/فوروارد optimistic با invalidation.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

وابستگی: 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	فهرست و فیلتر	صفحه‌بندی، جستجو، فیلترِ نویسنده/تاریخ	۴ ساعت

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

بلاگ کامل: فهرست/جزئیات/ساخت/ویرایش/حذف متصل به API؛ حالت‌های خالی/خطا.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

وابستگی: 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)، حریمِ خصوصی، مسدودها	۴ ساعت

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

فهرست کاربران با جستجو/صفحه‌بندی؛ پروفایل عمومی؛ ویرایش پروفایل + آپلود/برش آواتار؛ تنظیمات حساب (رمز/حریم/مسدودها).
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

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

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

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

◆ تیم 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	تنظیمات گروه	ویرایش/حریمِ خصوصی/حذف با مجوز	۴ ساعت

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

CRUD گروه؛ عضویت/خروج؛ تب‌های پست/انجمن/اعضا/اسناد؛ تغییر حریم خصوصی.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

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

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

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	ویجت داشبورد	اتصالِ آخرین اخبار به داشبورد	۳ ساعت

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

CRUD خبر با دامنهٔ انتشار (سراسری/هلدینگ/شرکت)؛ فقط نقش مدیر محتوا منتشر می‌کند.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

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

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

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	جزئیات + پیوست	جزئیات، فایل‌ها، حذف با مجوز	۵ ساعت

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

CRUD رویداد؛ تقویم شمسی/میلادی؛ دعوت اعضا.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

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

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

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

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

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

Subtaskها

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

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

آپلود/ویرایش/حذف رسانه؛ آلبوم؛ حریم خصوصی per-آیتم.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

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

الحاقیه‌ی ۱۴۰۵/۰۵/۱۴ (این تسک را تغییر نمی‌دهد): ویدیو در نسخه‌ی نهایی نشانِ duration روی بندانگشتی دارد ← F27.3.

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

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

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

Subtaskها

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

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

CRUD موضوع و پاسخ؛ علامت «حل‌شده»؛ پذیرش پاسخ.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

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

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

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

◆ تیم Front

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

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

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

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

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

کانال/DM/رشتهٔ پاسخ/reaction/پین/ذخیره/دستور اسلش در سطح فعلی دمو، همگی کارکردی.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

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

الحاقیه‌ی ۱۴۰۵/۰۵/۱۴ (این تسک را تغییر نمی‌دهد): کانال‌ها در نسخه‌ی نهایی موجودیتِ دامنه‌دارند و فهرست با نشست فیلتر می‌شود (DM بدون تغییر) ← F25.3.

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

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

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

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

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

آپلود/دسته‌بندی/جستجو/نسخه‌گذاری سند؛ سطل بازیافت ۳۰ روزه.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

وابستگی: 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	نماها	لیست/کانبان/تقویم، فیلترِ عضو/وضعیت	۴ ساعت

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

بورد کانبان با CRUD تسک؛ گانت؛ چت پروژه؛ بودجه.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

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

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

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

◆ تیم Front

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

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

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

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

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

چهار بخش قرارداد/صندوق/پژوهش/آموزش با فهرست/جزئیات/فرم و گردش‌کار وضعیت.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

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

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

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

◆ تیم Front

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

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

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

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

پنل راهبری: مدیریت کاربر/نقش، ظاهر/برند per-tenant با پیش‌نمایش زنده، گزارش‌گیری.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

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

الحاقیه‌ی ۱۴۰۵/۰۵/۱۴ (این تسک را تغییر نمی‌دهد): پنل راهبری در نسخه‌ی نهایی «سیستم و ورود یکپارچه»، CRUD هلدینگ/شرکت و تخصیص (کاربر، نقش، دامنه) دارد ← F28.

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

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

مرکز اعلان؛ جستجوی سراسری؛ راهنما/دستیار؛ پولیش a11y/RTL؛ Lighthouse سبز؛ E2E مسیرهای حیاتی.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

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

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

تطبیقِ کاملِ صفحه‌های demo.shub.ir با فهرستِ F1–F20 نشان داد چند بخشِ ساخته‌شده‌ی پروتوتایپ هیچ تسکی ندارند. برای این‌که برنامه‌ی در حالِ اجرا به‌هم نخورد، این‌ها با شماره‌های تازه آمده‌اند و در جمعِ فازهای ۰ تا ۶ حساب نشده‌اند. زمان‌بندی‌شان تصمیمِ PO است.

◆ تیم Front

F21نمای عمومی: لندینگ، ویترینِ محتوای عمومی و صفحه‌ی جزئیاتP2نساخته۵ روز

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

تنها سطحِ بدونِ ورودِ محصول. در پروتوتایپ ~۱۴۷۰ خط است (Landing، PublicShowcase، PublicItemDetail) و در «سناریوی دموی فروش» ایستگاهِ پایانی است، ولی در F1–F20 نیامده. داده‌اش همان محتوایی است که visibility=عمومی دارد.

EARS: هرگاه محتوایی «عمومی» علامت بخورد، سامانه باید آن را بدونِ نیاز به ورود در ویترینِ عمومی نمایش دهد و بقیه را پنهان نگه دارد.

Subtaskها

#	کار	جزئیات فنی	تخمین
F21.1	لندینگ	صفحه‌ی معرفی، SSR برای SEO، CTAِ ورود/ثبت‌نام	۸ ساعت
F21.2	ویترینِ عمومی	تب‌های اخبار/رویداد/بلاگ/رسانه/انجمن با فیلترِ عمومی، بدونِ توکن	۱۲ ساعت
F21.3	جزئیاتِ آیتمِ عمومی	صفحه‌ی deep-link‌پذیر هر آیتم + متادیتای اشتراک‌گذاری	۱۰ ساعت
F21.4	گاردِ مهمان	هدایتِ اقدام‌های نیازمندِ ورود به `/login?next=`	۴ ساعت
F21.5	SEO و کارایی	عنوان/توضیح هر صفحه، sitemap، Lighthouse سبز	۶ ساعت

معیار پذیرش

Given کاربرِ بدونِ حساب، When آدرسِ آیتمِ عمومی را باز کند، Then محتوا بدونِ ورود دیده شود.
Given محتوای غیرِعمومی، When مهمان تلاش به دیدنش کند، Then به ورود هدایت شود و محتوا لو نرود.

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

لندینگ + ویترین عمومی + جزئیات آیتم، همگی بدون ورود؛ گاردِ اقدامِ نیازمند ورود؛ SEO و sitemap.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

وابستگی: F5. داده: endpointهای عمومیِ محتوا (نیازمندِ حالتِ بدونِ توکن — امروز همه‌ی مسیرها ۴۰۱ می‌دهند؛ تسکِ Backend متناظر باید تعریف شود).

F22دوستان و دنبال‌کردن (صفحه‌ی مستقل)P3نساخته۲ روز

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

Backend این ماژول را دارد (B15)، اما در برنامه‌ی Front فقط به‌صورت «تبِ دوستان» داخلِ F9.2 آمده؛ پروتوتایپ یک صفحه‌ی مستقل با درخواست‌ها/پیشنهادها دارد. قرارداد: GET /friends، GET /friends/requests، POST /friends/{id}/accept، POST|DELETE /users/{id}/follow.

Subtaskها

#	کار	جزئیات فنی	تخمین
F22.1	فهرست دوستان	`GET /friends` با جستجو/صفحه‌بندی	۴ ساعت
F22.2	درخواست‌ها	پذیرش/رد با optimistic و invalidation	۵ ساعت
F22.3	دنبال‌کردن	دکمه‌ی follow/unfollow در پروفایل و فهرستِ کاربران	۴ ساعت
F22.4	اتصال به F9	هم‌راستایی با تبِ دوستانِ پروفایل، حذفِ دوباره‌کاری	۳ ساعت

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

صفحهٔ مستقل دوستان: فهرست/درخواست/دنبال‌کردن؛ هم‌راستا با تب پروفایل (F9) بدون دوباره‌کاری.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

وابستگی: F5، F9. داده: B15. وضعیتِ امروز: /friends روی production مستقر نیست.

F23نظرسنجی و آزمون · مسابقات و چالش‌هاP3نساخته۴ روز

User Storyبه‌عنوان عضو، می‌خواهم در نظرسنجی‌ها و آزمون‌های سازمان شرکت کنم و مسابقات و چالش‌ها را ببینم و ثبت‌نام کنم، تا در برنامه‌های سازمان مشارکت داشته باشم.

در سرفصلِ فاز ۵ نام برده شده‌اند («نظرسنجی/مسابقات») و Backend تسکِ B18 را دارد، اما هیچ subtaskِ Frontی برایشان تعریف نشده بود. مرجع: Polls و Competitions در پروتوتایپ. قرارداد: /polls (+{id}/vote)، /quizzes، /competitions، /challenges.

Subtaskها

#	کار	جزئیات فنی	تخمین
F23.1	نظرسنجی	فهرست/جزئیات، رأی‌دهی، نمایشِ نتیجه پس از رأی	۸ ساعت
F23.2	آزمون	نمایشِ سوال‌ها، ثبتِ پاسخ، نتیجه	۸ ساعت
F23.3	مسابقات و چالش‌ها	فهرست/جزئیات، ثبت‌نام، ارسالِ اثر، جدولِ امتیاز	۱۰ ساعت
F23.4	یکپارچه‌سازی منو و مجوز	سایدبار، دسترسیِ نقش‌محور	۴ ساعت

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

نظرسنجی (رأی+نتیجه)، آزمون، مسابقه/چالش با ثبت‌نام و جدول امتیاز.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

وابستگی: F5. داده: B18. وضعیتِ امروز: هیچ‌کدام از این مسیرها روی production مستقر نیستند.

F24تیکت پشتیبانیP3نساخته۲ روز

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

صفحه‌ی Tickets در پروتوتایپ وجود دارد و PHP هم ۱۲ عملیاتِ آماده دارد (/tickets، /ticket-categories، /ticket-orders)، ولی در برنامه‌ی هیچ‌کدام از دو تیم نیامده بود.

Subtaskها

#	کار	جزئیات فنی	تخمین
F24.1	فهرست و فیلتر	`GET /tickets` با وضعیت/دسته/صفحه‌بندی	۵ ساعت
F24.2	ثبت تیکت	`POST /tickets`، انتخابِ دسته، پیوست	۵ ساعت
F24.3	گفتگوی تیکت	جزئیات، پاسخ‌ها، تغییرِ وضعیت	۶ ساعت

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

تیکت: فهرست/ثبت با پیوست/گفتگو/تغییر وضعیت.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

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

جمعِ دامنه‌ی افزوده: ~۱۳ روزِ Front (F21–F24) + ~۲ روزِ Backend (B20). این عدد عمداً در جدولِ «خلاصه‌ی زمان‌بندی» بالا وارد نشده تا تخمین‌های در حالِ اجرا دست‌نخورده بمانند. جایزه‌ی نوآوری (/dashboard/award) نیز پس از نگارشِ تسک‌ها صفحه‌ی مستقل شد و به‌عنوان زیرکارِ F18.5 پوشش داده می‌شود.

≡

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

از نگارش قبلی این سند، مرجعِ پذیرش (demo.shub.ir) جلو رفته است: دامنه‌بندی «سیستم ← هلدینگ ← شرکت»، ناوبری نقش‌محور، ناظم گروه، فیلدهای محتوایی جدید و پایه‌ی دسترس‌پذیری WCAG. هیچ تسک قبلی تغییر نکرده — همه‌ی این دلتاها تسک‌های تازه‌اند تا کارهای در جریان مختل نشود؛ مرجع فنی کامل: قرارداد الزام‌آور دامنه‌بندی.

◆ تیم Front

F25نشست و دامنه‌بندی سمت کاربرP1نساخته۴ روز

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

دامنه از auth/me می‌آید (عضویت + تخصیص نقش) و کاربر آن را انتخاب نمی‌کند. مرجع رفتار: سوییچر هدر، نشان دامنه روی ردیف‌ها، و انتخاب‌گر دامنه‌ی انتشارِ مجوزمحور در دمو.

Subtaskها

#	کار	جزئیات فنی	تخمین
F25.1	مدل نشست	خواندن `memberCompanyIds` و `grant` از `auth/me`؛ context مشترک (معادل `TenancyContext` دمو)	۶ ساعت
F25.2	سوییچر هدر	تک‌عضویتی: برچسب خواندنی؛ چندعضویتی: فقط شرکت‌های عضو؛ راهبر: «مشاهده به‌عنوان»؛ در موبایل آیکنی	۶ ساعت
F25.3	نشان و فیلتر فهرست‌ها	`ScopeBadge` روی ردیف/کارت همه‌ی ماژول‌ها + پارامتر دامنه در queryها	۸ ساعت
F25.4	انتشار مجوزمحور	`ScopePicker` فقط دامنه‌های مجاز نشست؛ عضو عادی: بدون گزینه («منتشر می‌شود برای: X»)	۶ ساعت
F25.5	مدیریت خطای دامنه	۴۰۴ آیتم خارج از دامنه، ۴۲۲ انتشار نامجاز — پیام روشن + بازگشت	۴ ساعت

معیار پذیرش (سناریوهای مرجع در قرارداد، بخش ۶)

Given کاربر عضو یک شرکت، When وارد شود، Then سوییچر نبیند و فهرست‌ها فقط سراسری+شرکتش باشند.
Given عضو ۳ شرکت، When سوییچر را باز کند، Then دقیقاً همان ۳ شرکت را ببیند و محتوای فهرست با سوییچ عوض شود.

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

نشست از auth/me ساخته می‌شود؛ سوییچر فقط برای چندعضویتی/راهبر؛ نشان دامنه روی همهٔ ردیف‌ها؛ انتشار مجوزمحور؛ پنج سناریوی پذیرشِ قرارداد (u1/u3/u4/u7/u12) عبور می‌کنند.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

وابستگی: F3، F5. داده: B21، B22.

F26ناوبری و اکشن‌های نقش‌محور + ناظم گروهP1نساخته۲ روز

User Storyبه‌عنوان عضو عادی، «پنل راهبری» را نه در منو ببینم و نه با آدرس مستقیم باز کنم؛ و به‌عنوان ناظم گروه فقط در گروه خودم اکشن مدیریتی داشته باشم.

Subtaskها

#	کار	جزئیات فنی	تخمین
F26.1	فیلتر ناوبری	آیتم‌های `adminOnly` در سایدبار/منوی پروفایل/منوی موبایل بر اساس مجوز مؤثر	۴ ساعت
F26.2	گارد مسیر	مسیر admin برای نقش بدون اختیار: صفحه‌ی «دسترسی ندارید» (نه ریدایرکت خاموش)	۳ ساعت
F26.3	ناظم گروه	ویرایش/حذف گروه، اخراج عضو و تغییر حریم فقط برای `canModerateGroup` — مثبت و منفی (g1/g2) تست شود	۵ ساعت

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

آیتم‌های adminOnly بر اساس مجوز مؤثر پنهان؛ مسیر admin برای نقش بدون اختیار «دسترسی ندارید»؛ ناظم گروه فقط در گروه خودش (مثبت g1 / منفی g2).
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

وابستگی: F25. داده: B21.

F27فیلدهای محتوایی جدید در فرم‌ها، فهرست‌ها و فیلترهاP2نساخته۲ روز

مطابق «قرارداد دامنه‌بندی، بخش ۵»: دسته‌ی رویداد (۵ مقدار) + ظرفیت، موضوع خبر (۵ مقدار)، مدت ویدیو. در نمای عمومی چیپ فیلتر، در داشبورد فیلد فرم + ستون/نشان.

Subtaskها

#	کار	جزئیات فنی	تخمین
F27.1	رویداد	select دسته + ورودی ظرفیت در فرم؛ «X از Y ظرفیت»؛ چیپ «دسته:» در نمای عمومی	۶ ساعت
F27.2	خبر	select موضوع در فرم؛ تگ موضوع روی هیرو/کارت/ردیف؛ چیپ «موضوع:» در نمای عمومی	۵ ساعت
F27.3	رسانه	نشان مدت (mm:ss) روی بندانگشتی ویدیوها در هر دو نما	۳ ساعت

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

select دسته+ظرفیت رویداد، select موضوع خبر، نشان مدت ویدیو در فرم و فهرست؛ چیپ فیلتر «دسته/موضوع» در نمای عمومی.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

وابستگی: F11، F12، F13 (تحویل‌شده‌ی همان‌ها را گسترش می‌دهد — بازکاری نیست). داده: B24.

F28پنل راهبری نسخه‌ی نهایی: هویت سیستم، SSO و ساختار سازمانیP2نساخته۴ روز

User Storyبه‌عنوان مدیر، هویت و روش ورود این نصب را تنظیم کنم؛ هلدینگ/شرکت بسازم و نقش را با دامنه به کاربر بدهم — هر کدام فقط در حد اختیار خودم.

دلتای F19 نسبت به دموی نهایی — F19 دست‌نخورده می‌ماند. بخش «سازمان‌های مشتری» در دمو حذف و جایگزین شده است.

Subtaskها

#	کار	جزئیات فنی	تخمین
F28.1	سیستم و ورود یکپارچه	فرم هویت (نام/دامنه/برند) + پیکربندی SSO (LDAP/SAML/OIDC/OTP) + تست اتصال + سوییچ‌های provisioning	۸ ساعت
F28.2	هلدینگ‌ها و شرکت‌ها	CRUD دو سطح + فعال/غیرفعال — محدود به زیرمجموعه‌ی مدیرِ واردشده (زنجیره‌ی واگذاری)	۱۰ ساعت
F28.3	تخصیص (کاربر، نقش، دامنه)	دو انتخاب‌گر کنار هم: نقش + دامنه (سیستم/هلدینگ/شرکت/گروه)؛ فهرست کاربران محدود به دامنه‌ی مدیر	۸ ساعت
F28.4	عضویت کاربران	افزودن/حذف کاربر به شرکت توسط مدیر شرکت؛ نمایش عضویت‌ها در فهرست	۶ ساعت

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

فرم هویت+SSO با تست اتصال؛ CRUD هلدینگ/شرکت محدود به زیرمجموعهٔ مدیر؛ تخصیص (کاربر،نقش،دامنه) و عضویت — زنجیرهٔ واگذاری رعایت شود.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

وابستگی: F19، F25، F26. داده: B21، B23.

جمعِ الحاقیه‌ی Front: ~۱۲ روز (F25–F28) — جدا از جمع فازهای ۰ تا ۶ و جدا از F21–F24، تا تخمین‌های در حال اجرا دست‌نخورده بمانند. یادآوری کیفیت: خطِ پایه‌ی دسترس‌پذیریِ دمو «صفر نقض WCAG A/AA در axe» است — توکن‌های رنگ اصلاح‌شده (ink-400 #5d6b81، ink-500 #5b6678، navy-950 #0b1220) مبنای F2 هستند و نباید به مقادیر کم‌کنتراست قبلی برگردند.

✆

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

خواسته‌ی نهایی محصول: پیام‌رسان باید تمام قابلیت‌های تلگرام را (به‌جز موارد حذف عمدی) به‌علاوه‌ی قابلیت‌های سازمانی داشته باشد. فهرست کامل قابلیت‌ها، جزئیات هر کدام و وضعیتشان در دمو: مشخصات کامل پیام‌رسان. F15 دست‌نخورده است — این چهار تسک ادامه‌ی آن‌اند و پس از تحویل F15 شروع می‌شوند.

◆ تیم Front

F29هسته‌ی پیام‌رسانی در سطح تلگرامP1نساخته۸ روز

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

Subtaskها (مرجع جزئیات: مشخصات پیام‌رسان، بخش ۱ و ۲)

#	کار	جزئیات فنی	تخمین
F29.1	چرخه‌ی پیام	حذف برای من/همه با پنجره؛ ویرایش با پنجره و برچسب؛ انتخاب چندتایی → فوروارد/حذف/کپی گروهی	۱۰ ساعت
F29.2	پاسخ و نقل‌قول	Quote بخشی از متن (انتخاب متن → نقل‌قول)، پرش به پیام اصل با هایلایت	۶ ساعت
F29.3	فوروارد پیشرفته	چند مقصد، با/بدون نام فرستنده؛ مقصدها محدود به دامنه‌ی مجاز	۶ ساعت
F29.4	زمان‌بندی و بی‌صدا	Schedule picker شمسی + صف پیام‌های زمان‌بندی‌شده‌ی قابل‌ویرایش؛ ارسال بی‌صدا	۶ ساعت
F29.5	قالب‌بندی کامل	bold/italic/underline/strike/mono/code-block/quote/spoiler/لینک با متن — منوی انتخاب متن + میانبرها	۱۰ ساعت
F29.6	پیش‌نمایش لینک + منشن/ایموجی	کارت پیش‌نمایش با حذف قبل از ارسال؛ کارت اختصاصی لینک‌های داخلی؛ @all/@here ناظم؛ پیکر ایموجی با جستجو	۸ ساعت
F29.7	پین چندتایی + واکنش کامل	نوار پیمایش بین پین‌ها؛ فهرست واکنش‌دهنده‌ها؛ مجموعه‌ی واکنش راهبری	۶ ساعت

معیار پذیرش

Given پیام ارسال‌شده، When پنجره‌ی ویرایش بگذرد، Then گزینه‌ی ویرایش غیرفعال شود و «حذف برای همه» طبق قاعده رفتار کند.
Given انتخاب سه پیام، When فوروارد به دو مقصد شود، Then هر شش رونوشت با ترتیب درست و برچسب فرستنده ثبت شود.

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

ویرایش/حذف با پنجرهٔ زمانی؛ نقل‌قول جزئی؛ فوروارد چندتایی/چندمقصدی؛ پیام زمان‌بندی‌شده و بی‌صدا؛ قالب‌بندی کامل (تا اسپویلر)؛ پین چندتایی؛ واکنش با فهرست کاربران.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

وابستگی: F15. داده: B25، B26.

F30رسانه، فایل و صوت در سطح تلگرامP1نساخته۷ روز

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

#	کار	جزئیات فنی	تخمین
F30.1	آلبوم و کپشن	چند عکس/ویدیو = یک آلبوم گروه‌شده؛ کپشن؛ انتخاب فشرده/اصل	۸ ساعت
F30.2	نمایشگر تمام‌صفحه	ورق‌زدن بین رسانه‌های چت، زوم، ذخیره، اطلاعات فرستنده	۸ ساعت
F30.3	پیام صوتی کامل	قفل ضبط، شکل موج، سرعت ۱×/۱.۵×/۲×، پخش پیوسته بین چت‌ها	۱۰ ساعت
F30.4	فایل با آپلود مقاوم	پیشرفت قابل‌لغو، ازسرگیری، سقف حجم از تنظیمات راهبر، خطای روشن	۶ ساعت
F30.5	گالری اشتراکی	تب‌های رسانه/فایل/لینک/صوت در پروفایل چت	۶ ساعت
F30.6	اختیاری‌ها	پیام ویدیویی دایره‌ای، استیکر سازمانی، اشتراک کارت کاربر — پشت پرچم قابلیت	۸ ساعت

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

آلبوم گروه‌شده با کپشن؛ نمایشگر تمام‌صفحه؛ ویس با شکل موج و سرعت ۲×؛ آپلود قابل‌ازسرگیری؛ گالری اشتراکی چهار-تبی.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

وابستگی: F29. داده: B27.

F31گروه‌ها، کانال‌ها، تاپیک‌ها و سازماندهیP2نساخته۸ روز

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

#	کار	جزئیات فنی	تخمین
F31.1	تاپیک‌ها (Forum Groups)	فهرست تاپیک‌های گروه، ساخت/بستن تاپیک، اعلان per-تاپیک	۱۲ ساعت
F31.2	کانال کامل	امضای نویسنده، بازدید پست، نظرات ذیل پست (گروه بحث متصل)	۸ ساعت
F31.3	مدیریت ناظمان	مجوزهای ریزدانه per-ناظم؛ محدودسازی/بن عضو با مدت؛ UI گزارش اقدامات	۱۰ ساعت
F31.4	دعوت و عضویت	لینک+QR با انقضا/سقف، درخواست عضویت با صف تایید ناظم، Slow Mode	۸ ساعت
F31.5	پوشه‌های چت	پوشه‌ی سفارشی با قواعد + پیش‌ساخته‌های سازمانی؛ آرشیو/سنجاق/خوانده‌نشده‌ی دستی	۱۰ ساعت
F31.6	Poll درون‌چت + auto-delete + بلاک/گزارش	نظرسنجی/آزمون تلگرامی؛ تایمر حذف خودکار per-چت؛ بلاک در DM و گزارش تخلف	۱۰ ساعت

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

تاپیک‌های گروه؛ کانال با امضا/بازدید/نظرات؛ مجوز ریزدانهٔ ناظم؛ لینک دعوت+Join Request+Slow Mode؛ پوشهٔ چت؛ Poll و auto-delete.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

وابستگی: F29. داده: B28.

F32جستجو، اعلان و همگام‌سازیP2نساخته۵ روز

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

#	کار	جزئیات فنی	تخمین
F32.1	جستجوی کامل	سراسری + درون‌چت با پیمایش نتایج، فیلتر نوع/فرستنده، پرش به تاریخ شمسی، هشتگ کلیک‌پذیر	۱۰ ساعت
F32.2	اعلان پیشرفته	بی‌صدا با مدت، «فقط منشن»، پیش‌نمایش، Badge تفکیکی @ در چت/پوشه/کل	۸ ساعت
F32.3	خوانده‌نشده و رسیدها	جداکننده‌ی خوانده‌نشده + اسکرول به آن؛ seen-by گروه‌های کوچک	۶ ساعت
F32.4	آفلاین و sync	صف ارسال آفلاین با retry، بازگردانی خطای optimistic، sync وضعیت بین تب‌ها	۸ ساعت

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

جستجوی سراسری و درون‌چت با پرش به تاریخ شمسی؛ اعلان پیشرفته (بی‌صدا/فقط‌منشن)؛ جداکنندهٔ خوانده‌نشده و seen-by؛ صف آفلاین و sync بین تب‌ها.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

وابستگی: F29. داده: B26.

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

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

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

#	کار	تخمین
F33.1	صفحه‌ی تماس ۱:۱ (صوتی/تصویری): زنگ‌خوردن، پاسخ/رد، کنترل‌ها (میوت/دوربین/بلندگو)	۱۲ ساعت
F33.2	گفتگوی صوتی گروهی روی کانال: فهرست حاضران، دست‌بلندکردن، دعوت، نشانگر ضبط	۱۴ ساعت
F33.3	اشتراک صفحه + چیدمان بینندگان	۸ ساعت
F33.4	ادغام با چت: دکمه‌ی شروع از هدر چت، پیام سیستمی «تماس شروع/پایان یافت»، تاریخچه‌ی تماس‌ها	۸ ساعت
F33.5	تست دو-مرورگر + کیفیت اتصال ضعیف	۶ ساعت

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

تماس ۱:۱ صوتی/تصویری، گفتگوی صوتی گروهی با دست‌بلندکردن و ضبط، اشتراک صفحه؛ ادغام با هدر چت و تاریخچهٔ تماس؛ تست دو-مرورگر.
عبور از خط لولهٔ تحویل: تست سه‌لایه + CI سبز + پذیرش PO روی staging (لایت/دارک، دسکتاپ و ۳۷۵px) — فرآیند؛ بدون TODO/console.log و مستندسازی به‌روز.

وابستگی: تصمیم PO + B29. خارج از جمع الحاقیه.

جمعِ الحاقیه‌ی پیام‌رسان (Front): ~۲۸ روز (F29–F32) — جدا از همه‌ی جمع‌های قبلی. ترتیب: F29 ← F30/F32 موازی ← F31. F33 فقط با تایید PO.

Σ+

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

جمعِ روزنفرِ تک‌تک تسک‌ها، به تفکیک بلوک. اعداد روز-نفر (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 فعال می‌شوند و در جمع الحاقیه حساب نشده‌اند.