Motoshub · Verified Status

وضعیت زنده — راستی‌آزماییِ محیط‌ها و قرارداد API

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

راستی‌آزمایی: ۱۴۰۵/۰۵/۱۱ — بازبینی دوم همان روز (۲۰۲۶-۰۸-۰۲) · روش: HTTP probe + شمارش Route* attributeها · مرجع تسک‌ها: Front · Backend

این صفحه هیچ تسکی را تغییر نمی‌دهد. شماره‌ی تسک‌ها، تخمین‌ها و وضعیت‌های اعلام‌شده در صفحه‌های Front و Backend دست‌نخورده باقی مانده‌اند. این صفحه فقط «واقعیتِ محیط» را کنار آن‌ها می‌گذارد تا ترتیبِ شروعِ کارها درست انتخاب شود.
۱

محیط‌ها — چه چیزی واقعاً بالاست

همه‌ی آدرس‌ها مستقیماً تست شدند. از بازبینی اول تا دوم، سه محیطِ تازه بالا آمد: Gateway، Swaggerِ PHP و Swaggerِ Django.

آدرسنقشنتیجهتوضیح
motonext.shub.irسایت فعلی (برنچ motonext)۲۰۰بالا — رابط Oxwall.
api.shub.irGateway (Kong) — موبایل و آینده‌ی کلِ اپفعال، ناقصKong وارد مدار شد (هدرهای x-kong-*). فقط ۴ مسیر: auth، blogs، news → PHP و projects → Django. مسیر catch-all ندارد؛ هر مسیرِ دیگر ۴۰۴ می‌گیرد.
api1.shub.irSwagger و APIِ فعلیِ PHP۲۰۰/api/v1/docs/index و /api/v1/docs/json هر دو زنده. ۱۲۹ عملیات / ۱۷ منبع.
api2.shub.irSwagger و APIِ Django۲۰۰/api/schema/ زنده. ۳۴۱ عملیات / ۱۷۳ مسیر — بسیار جلوتر از آنچه اسناد قبلی می‌گفتند.
demo.shub.irمرجع تجربه و پذیرش۲۰۰بالا — GitHub Pages.
docs.shub.irاسناد تحویل۲۰۰بالا — همین سایت.
motonextfront.shub.irStaging فرانت جدیدDNS نداردتنها محیطِ همچنان غایب. گیتِ ۷ و ۸ پایپ‌لاین (دیپلوی staging و پذیرش PO) هنوز مقصدی برای تیم Front ندارد.
۲

دو بک‌اند، دو نیمه‌ی مکمل — نه دو نسخه از یک چیز

هر دو Swagger خوانده و مقایسه شد. نتیجه با فرضِ اسنادِ قبلی («Django همان قرارداد را از نو می‌سازد») نمی‌خواند.

یافته‌ی اصلی. PHP و Django عملاً هم‌پوشانی ندارند: PHP هسته‌ی اجتماعی را می‌دهد و Django ماژول‌های سازمانی را. تنها منبعِ مشترک conversations است. یعنی این دو رقیب هم نیستند — دو نیمه‌ی یک محصول‌اند و Gateway باید هر کدام را سرِ جای خودش بنشاند.
بک‌اندعملیاتمنابعپوشش
api1.shub.ir — PHP/Oxwall۱۲۹۱۷ auth · users · blogs · news · groups · events · forum · feed · photos · albums · videos · conversations · messages · files · tags · flags · contact
api2.shub.ir — Django/DRF۳۴۱۱۳ contracts (۷۵) · funds (۱۰۲) · research (۶۳) · knowledge (۵۰) · projects (۳۴) · conversations · login/logout/register · legacy-users · public · health
مجموعِ سطحِ زنده۴۷۰۲۹هم‌پوشانی: فقط conversations

PHP: ساخته‌شده در برنچ API ولی مستقرنشده

برنچ API شاملِ ۲۹۳ عملیات روی ۵۵ منبع است؛ api1 فقط ۱۲۹ عملیات از ۱۷ منبع را سرو می‌کند. ۳۹ منبعِ زیر کد دارند ولی روی هیچ محیطی بالا نیستند:

tickets · ticket-categories · ticket-orders · polls · quizzes · quiz-questions · competitions · competition-submissions · challenges · challenge-* · friends · notifications · search · comments · mentions · privacy · cfps · grants · evaluations · technologies · tech-units · companies · employees · journal-* · landing-*
استقرارِ همین برنچ، ارزان‌ترین راه برای پرکردنِ نیمی از شکاف‌های بخش ۵ است.

وضعیت Gateway

مسیر روی api.shub.irپاسخیعنی
/api/v1/auth/me۴۰۱روت شده → PHP
/api/v1/blogs۴۰۱روت شده → PHP
/api/v1/news۴۰۱روت شده → PHP
/api/v1/projects۳۰۱روت شده → Django
هر مسیر دیگر (/groups، /feed، /funds، …)۴۰۴روت ندارد — بدون catch-all
کوچک‌ترین تغییر با بیشترین اثر: افزودنِ دو روتِ catch-all به Kong — /api/v1/* → PHP به‌عنوان پیش‌فرض، و مسیرهای contracts|funds|research|knowledge|projects → Django. با همین یک تغییر، هر ۴۷۰ عملیات از یک دامنه‌ی واحد در دسترس می‌آید و فرانت دیگر لازم نیست بداند کدام سرویس پاسخ می‌دهد.
۳

مخزن در برابر production — ۲۹۳ عملیات کجاست

شمارشِ مستقیمِ RouteGet/RoutePost/RoutePatch/RouteDelete روی کنترلرهای Http/Controllers/API/V1 در هر برنچ.

برنچ در motoshub-webکنترلرعملیاتمنبعوضعیت
API (کارِ مهاجرتِ کامل)۶۲۲۹۳۵۵ادغام‌نشده و مستقرنشده. منبعِ عددِ ۲۹۳ در اسناد همین برنچ است.
moto-next۵۲۴۵مبنای استقرارِ production.
main۰۰۰بدون لایه‌ی api/v1.
سرویسِ زنده api1.shub.ir۱۲۹۱۷استقرارِ فعلی — جلوتر از moto-next و عقب‌تر از برنچ API.
تصمیمی که PO باید بگیرد. ۲۹۳ عملیاتِ برنچ API کارِ انجام‌شده‌ای است که پشتِ یک MR مانده. تا وقتی ادغام و مستقر نشود، تیم Backend همان قابلیت‌ها را در Django از صفر می‌سازد و تیم Front منتظرِ هر دو می‌ماند. ادغامِ این برنچ کوتاه‌ترین مسیر به «فرانت روی دادهٔ واقعی» است.
ارقامِ برنچ‌ها از آخرین کپیِ محلیِ مخزن (۱۴۰۵/۰۴/۳۰) است؛ اتصالِ git به gl.iiscenter.ir از سرورِ تحلیل برقرار نشد، بنابراین ممکن است برنچ‌ها جلوتر رفته باشند. ارقامِ بخش‌های ۱ و ۲ همگی امروز و زنده اندازه‌گیری شده‌اند.
۴

انحراف از «قراردادهای الزام‌آور»

سه قراردادِ الزام‌آورِ اسناد با پاسخِ واقعیِ سرویس مقایسه شد.

قراردادآنچه سند می‌گویدآنچه سرویس برمی‌گردانداثر
بدنه‌ی یکسانِ خطا خطاها با 401/403/404/422 و بدنه‌ی یکسان ۴۰۱ → {"error":"Authorization header token is missing."}
۴۰۴ → {"message":"no Route matched…","request_id":"…"}
دو شکلِ متفاوت. هیچ‌کدام هم شکلِ استانداردِ اعلام‌شده نیست. تا یکسان‌سازی، هندلرِ خطای Front باید هر دو را بپذیرد. → B1، و یک نکته در F5.
مرجعِ فیلدها = Swagger لینکِ Swagger در راهنمای هر دو تیم حل شدapi1.shub.ir/api/v1/docs/index و api2.shub.ir/api/schema/ هر دو ۲۰۰ هر دو تیم حالا مرجعِ رسمیِ فیلد دارند. نکته: دو Swagger مجزا است، نه یک سند واحد؛ تا ادغام‌نشدنشان، «قرارداد واحد» روی کاغذ است نه در عمل.
auth واحد و کاملِ نشست F3: POST /auth/refresh، logout با ابطالِ سمتِ سرور، F3.6 «endpointِ تغییر رمز هست» در کلِ api/v1 فقط auth/login، auth/me، auth/permissions وجود دارد refresh، logout، register و change-password در PHP وجود ندارند. F3 (فاز ۱، P1، پیش‌نیازِ همه) به B4 گره خورده است و بدونِ آن قابلِ اتمام نیست.
نامِ مسیرِ فید F7/B7: GET /newsfeed مسیرِ واقعی در قرارداد: GET/POST /api/v1/feed (+ /feed/{id}/like، /feed/{id}/forward، /feed/{id}/privacy) در صفحه‌های تسک اصلاح شد؛ /newsfeed فقط نامِ پلاگینِ PHP است، نه مسیرِ API.
ریسکِ امنیتیِ قبلی — بسته شد. توکن‌های oauth2 که در URLِ ریموتِ چند مخزن ذخیره شده بودند دیگر معتبر نیستند (چرخانده شده‌اند). نکته‌ی باقی‌مانده: ریموتِ محلیِ توسعه‌دهنده‌ها هنوز همان توکنِ مرده را دارد و git fetch با آن شکست می‌خورد — هر کس یک‌بار باید git remote set-url بزند.
۵

دامنه‌ی پوشش‌داده‌نشده — صفحه‌هایی از پروتوتایپ که هیچ تسکی ندارند

مرجعِ پذیرش، demo.shub.ir است. همه‌ی صفحه‌های پروتوتایپ با فهرستِ F1–F20 و B1–B19 تطبیق داده شد؛ موارد زیر در هیچ تسکی نیامده‌اند.

صفحه در پروتوتایپمسیرحجموضعیت در برنامهتخمینِ افزوده
نمای عمومی (لندینگ + ویترینِ عمومی + جزئیاتِ آیتمِ عمومی)/، /public/*~۱۴۷۰ خطهیچ تسکی ندارد. تنها سطحِ بدونِ ورودِ محصول و ایستگاهِ پایانیِ سناریوی فروش.F21 — ۵ روز
دوستان و دنبال‌کردن/dashboard/friends۱۸۷ خطBackend دارد (B15) — Front فقط یک «تبِ دوستان» داخلِ F9.2 دارد، نه صفحه‌ی مستقل.F22 — ۲ روز
نظرسنجی و آزمون · مسابقات و چالش‌ها/dashboard/polls، /dashboard/competitions۴۲۲ خطBackend دارد (B18) — در سرفصلِ فاز ۵ نام برده شده ولی هیچ subtaskِ Frontی ندارد.F23 — ۴ روز
تیکت پشتیبانی/dashboard/tickets۲۳۴ خطدر هیچ‌کدام از دو تیم تسک ندارد، با این‌که ۱۲ عملیاتِ آماده در PHP دارد.F24 + B20 — ۲ + ۲ روز
جایزه نوآوری و فناوری/dashboard/award۹۳ خطپس از نگارشِ تسک‌ها به صفحه‌ی مستقل تبدیل شد؛ در برنامه نیامده.داخل F18.5
جمعِ دامنه‌ی کشف‌شده — خارج از تخمین‌های فعلی~۱۵ روز

شکافِ بک‌اند برای ماژول‌های پروتوتایپ (بر پایه‌ی هر دو Swagger)

ماژول پروتوتایپبک‌اندوضعیت
فید، اخبار، بلاگ، گروه، انجمن، رویداد، رسانه، گفتگو، کاربرانPHPزنده روی api1
دانش، پروژه، قرارداد، صندوق، پژوهشDjangoزنده روی api2
تیکت، نظرسنجی/آزمون، مسابقات/چالش، دوستان، اعلان، جستجوی سراسریPHPکد دارد، مستقر نیست — در برنچ API
آموزش، جایزه نوآوری، گزارش‌گیری عمومی، مدیریت نقش‌ها، برندسازیدر هیچ بک‌اندی نیست
هلدینگ / شرکت و دامنه‌بندی محتوادر هیچ بک‌اندی نیست — نه مدل، نه فیلد، نه فیلتر
مهم‌ترین شکافِ معماری. در هیچ‌کدام از دو Swagger هیچ نشانی از holding، company، tenant یا scope نیست. یعنی سلسله‌مراتبِ سیستم ← هلدینگ ← شرکت و «دامنه‌ی انتشار» فقط در پروتوتایپ وجود دارد. چون این لایه روی هر موجودیتِ محتوایی اثر می‌گذارد (فیلدِ مالک + فیلترِ خواندن + مجوزِ نوشتن)، هرچه دیرتر اضافه شود گران‌تر است: افزودنش الان یعنی سه فیلد و یک فیلترِ مشترک؛ افزودنش بعد از پرشدنِ دیتابیس یعنی مهاجرتِ داده روی همه‌ی جدول‌ها.
چرا این‌ها به تسک‌های موجود اضافه نشدند. تیم روی F1–F20 و B1–B19 در حالِ اجراست و تخمین‌ها مبنای اسپرینت‌اند. این دامنه به‌صورت شماره‌های تازه (F21–F24، B20) و با جمعِ جدا آورده شده تا هیچ تخمینی جابه‌جا نشود؛ تصمیم درباره‌ی زمان‌بندی‌شان با PO است — یا فاز ۶، یا پس از تحویلِ پروتوتایپِ کامل.
۶

کوتاه‌ترین مسیرِ رفعِ انسداد — بازبینی‌شده

به ترتیبِ اثر بر جریانِ کار. سه موردِ بازبینی اول («بازگرداندن Swagger»، «DNSِ Django») دیگر لازم نیست.

#اقداممالکباز می‌کند
۱catch-all در Kong: /api/v1/* → PHP به‌عنوان پیش‌فرض + مسیرهای contracts|funds|research|knowledge|projects → DjangoDevOpsهر ۴۷۰ عملیات از یک دامنه؛ فرانت از api.shub.ir تغذیه می‌شود نه مستقیم از دو سرویس
۲تصمیم درباره‌ی مدل هلدینگ/شرکت و افزودن scope/holdingId/companyId به موجودیت‌های هر دو بک‌اندPO + هر دو لیدتنها لایه‌ای که در پروتوتایپ هست و در بک‌اند نیست؛ هرچه دیرتر، گران‌تر
۳استقرارِ برنچ API (۲۹۳ عملیات) روی api1Backend لید + DevOpsتیکت، نظرسنجی، مسابقات، دوستان، اعلان، جستجو — بدون یک خط کدِ تازه
۴افزودنِ auth/refresh، auth/logout، auth/change-passwordBackend ۱F3 — پیش‌نیازِ همه‌ی صفحه‌های محافظت‌شده
۵یکسان‌سازی پاکت پاسخ و بدنه‌ی خطای دو بک‌اند + انتشارِ یک Swaggerِ واحد پشت Gatewayهر دو لید«قرارداد واحد» را از کاغذ به عمل می‌آورد؛ تستِ قرارداد در CI
۶ساختِ رکورد DNS برای motonextfront.shub.irDevOpsگیتِ ۷ و ۸ پایپ‌لاین (staging و پذیرشِ PO)
۷تصمیمِ PO درباره‌ی ماژول‌های بی‌بک‌اند: آموزش، جایزه، گزارش‌گیری، مدیریت نقش، برندسازیPOتعریفِ روشنِ «پروتوتایپِ کامل»
docs.shub.ir · راستی‌آزمایی ۱۴۰۵/۰۵/۱۱ · بازگشت به فهرست اسناد