MyClub — وصف المشروع وعقد التطوير

0. هذا المستند: لماذا، ولمن، وما الذي يفعله

0.1 المشروع انطلق قبل عامين، والآن يُستأنف

بدأ العمل على MyClub قبل نحو عامين، ثم توقف. والآن نلتزم باستئنافه.

الاستئناف ليس مجرد إعادة تشغيل. فحالة المشروع القائمة عند الاستئناف فرضت إعادة كتابة عقد التطوير صراحةً: أي ما لم يكن مكتوبًا ومتفقًا عليه لم يكن عقدًا، وإن وُجد في الذاكرة أو كنية ضمنية.

هذا المستند هو هذا العقد. والغرض منه أربعة:

1. أن نثبت فهمًا مشتركًا للفكرة التجارية — ما هذا المنتج، ولماذا يوجد.
2. أن نثبت فهمًا مشتركًا لرحلات المستخدم — من يفعل ماذا، ومتى، وبأي صلاحيات.
3. أن نُظهر بصراحة مواضع الاختلاف بين النية والسلوك القائم، بدل إخفائها.
4. أن نطلب قرارًا صريحًا في كل موضع لا يمكن حسمه إلا بقرار تجاري.

0.2 ما يفعله هذا المستند وما لا يفعله

0.3 علامات التمييز المستخدمة في المستند

1. ما هذا المنتج

MyClub هو منصة متعددة المستأجرين لإدارة اتحادات الرياضة والأندية التابعة لها — على الأرجح رياضات الدفاع عن النفس، لاستخدام المفردات الدالة على ذلك: الفئات مقسمة بالعمر والجنس، وفئات الوزن، والدرجات (الأحزمة والرتب)، وإصدار رخصة لكل موسم، وقول «مجلس» في هذا السياق يعني مجلس إدارة لا لوح تزلج.

MyClub يحلّ مشكلة تجارية محددة وغير براقة: الاتحاد يبيع رخصًا موسمية للرياضيين. ولا يجوز لأي رياضي أن يتنافس دون رخصة. ويحتاج الاتحاد إلى معرفة من هو مرخَّص، وإلى القدرة على تحصيل المقابل عن ذلك، وأن يتمكّن عدّة مستويات من المديرين — من مدرب نادٍ حتى رئيس الاتحاد — من إنجاز كل جزء من مسؤولياتهم دون أن يتجاوز أحدهم حدودهم.

تدفّق المال يتّجه صعودًا (الأندية تدفع للمنظمة)، وتدفّق الرخص يتّجه هبوطًا (المنظمة تُصدرها للرياضيين عبر الأندية). كل قرار تصميمي في هذا المنتج يتبع من هذا.

1.1 من يستخدم المنصة

1.2 نموذج المستأجر — الفكرة الأهم في النظام

المنظمة هي مستأجر. وهي ليست مجرد سجل في جدول: إنشاء منظمة يُنشئ قاعدة بيانات منفصلة لها، تُسمّى بمُعرِّف المنظمة، تُنشأ من قالب وتُملأ بالبيانات المرجعية. وكل بيانات الأندية والرياضيين والمواسم والرخص والإيصالات والصلاحيات توجد داخل تلك القاعدة.

هذا عزل حقيقي، لا مجرد عمود تمييز مستأجر. ونتائجه ظاهرة في كل مكان:

• تبديل المنظمة يغيّر أي قاعدة بيانات تُستعلم، لا مجرد مُرشِّح.
• مجموعة الصلاحيات لكل منظمة على حدة. الشخص نفسه قد يكون مديرًا كاملًا في مستأجر وعضوًا عاديًا في مستأجر آخر.
• لكل شخص سجلّا هوية: حساب واحد على مستوى المنصة، وملف تعريف داخل كل منظمة. الحساب يقول من هو، والملف يقول ما هو هنا.
• ولأن السجلّين منفصلان، يمكن تعليق شخص داخل نادٍ أو منظمة مع بقائه نشطًا في كل مكان آخر. التعليق قرار عضوية، وليس قرارًا على مستوى المنصة.

هناك أربعة أنواع من المنظمات — Club، وOrganization، وContinental، وFederation — ويحدد النوع موضع تلك المنظمة في التسلسل الهرمي، وأي مستويات صلاحيات يمكن أن تصل إليها. والتسلسل هو: نادٍ ← منطقة ← منظمة ← قارية ← اتحاد. ومنظمة من نوع «نادٍ» هي نادٍ مستقل لم ينضم بعد إلى جسم أكبر، و«اتحاد» هو جهاز وطني في القمة.

2. المجال، بترتيب استخدامه في الأعمال

2.1 المواسم — العمود الفقري للعمل

الموسم (مثل 2026-2027) هو فترة الفوترة والترخيص. وهو أهم عنصر في المنتج المنفرد، للأسباب التالية:

• الرخص تنتمي إلى موسم. فالرياضي يُرخَّص لموسم.
• الرسوم تُعرَّف لكل موسم (رسوم رياضي ورسوم نادٍ)، فتتغيّر الأسعار عامًا بعد عام.
• الموسم قد يكون مفتوحًا أو مغلقًا. والموسم المغلق لا يقبل أي طلب ترخيص إطلاقًا — وهذا توقف قاطع، يُفحص قبل أي شيء آخر.
• يوجد موسم واحد افتراضي — هو الموسم الذي تُصدر إليه الرخص. كل منطق «طلب رخصة» يُحلّ بالنسبة له، ويتيح الشريط علوي للمستخدم تبديل الموسم الذي ينظر إليه.

المواسم هي سبب وجود مفهوم «الموسم الحالي» أصلًا، ولماذا تفحص عدة بوّابات حالة الموسم بدل أي حالة حساب أو نادٍ.

2.2 الرسوم ووضع الدفع

يحدّد كل موسم رسمين:

• رسوم الرياضي — ما يدفعه النادي للمنظمة لترخيص رياضي واحد.
• رسوم النادي — ما يدفعه النادي للمنظمة لعضوية الموسم.

ووضع دفع واحد، وهو الفرع الجوهري في محرّك الترخيص كله:

• مدفوع مسبقًا — النادي يحتفظ برصيد مدفوع مسبقًا. رفع طلب الترخيص يخصم رسوم الرياضي فورًا من رصيد النادي. المال يتحرك لحظة الطلب. وإذا لم يكفِ الرصيد، يُرفض الطلب.
• عند الطلب — لا يُخصم شيء لحظة الطلب. يُرفع الطلب فقط، وينتظر مراجعة من مدير في المنظمة.

هذا الإعداد الواحد يحدد ما إذا كان طلب الترخيص معاملة مالية أم بند في طابور عمل. وهو يُحدَّد لكل موسم، فبإمكان المنظمة أن تعمل بنظام الدفع المسبق هذا العام وبنظام عند الطلب في العام التالي.

2.3 ترقيم الرخص — كيف يحصل الترخيص على رقمه

بشكل مستقل عن وضع الدفع، يختار كل موسم طريقة إسناد أرقام الرخص:

• تلقائي — المنصة تُصدر الرقم التالي من عدّاد.
• الإبقاء على السابق — الرياضي العائد يحتفظ برقمه السابق، فيُصان ترابط رقم الرخصة عبر المواسم.
• يدوي — مدير يكتب الرقم.

هذا أهم مما يبدو. رقم الرخصة وثيقة هوية قانونية للمنافس. وخيار «الإبقاء على السابق» موجود تحديدًا ليبقى رقم رخصة المنافس ثابتًا مدى الحياة — وهو نوع الشيء الذي تعتمد عليه مطالبة تأمين أو سجل في الاتحاد. وعدّاد الأرقام التلقائي جدول مخصص وظيفته الوحيدة تسليم الرقم التالي بأمان.

2.4 الرخص

تربط الرخصة رياضيًا واحدًا بموسم واحد، وتحمل رقمًا وتاريخ انتهاء صلاحية، ويُشترط أن تكون مسنودة بإيصال — فحقل معرّف الإيصال في الرخصة إجباري وفريد. لا يمكن أن توجد رخصة دون سجل الدفع الذي سدّد ثمنها. هذا هو سجل التدقيق، مفروضًا بالمخطط لا بالعرف.

تتتبّع الرخصة كذلك هل طُبعت. بطاقات الرخص المطبوعة شيء حقيقي في هذا النشاط، والرخصة المطبوعة نوع مختلف من الوثيقة عن المُصدَرة.

2.5 طلبات الترخيص ومراجعتها

دورة الطلب والمراجعة هي جوهر الحوكمة. يحمل طلب الترخيص نوعًا — إنشاء (أول رخصة) أو تجديد — وحالة تتحرك ضمن:

• PENDING — مرفوع، ولم ينظر فيه أحد.
• VALIDATE — وافق عليه مدير. وفي نظام «عند الطلب» مع الترقيم اليدوي أو التلقائي، هذه هي لحظة إصدار الرخصة فعليًا، داخل معاملة واحدة تُنشئ الإيصال وتربطه.
• REJECT وREFUSE — مرفوض، مع ملاحظات.

كل قرار يُسجَّل في سجل مراجعة منفصل بدلًا من تعديل الطلب الأصلي: من قرّر، ومتى، ولماذا. والسجل محفوظ. والموافقة مشروطة بصلاحية محددة، والرفض مشروط بصلاحية مختلفة — تستطيع أن تسمح لشخص بالاعتماد وآخر بالرفض.

وقبل أي من ذلك، يجب أن تتحقق ثلاثة شروط: نادي الرياضي ACTIVE، والرياضي ACTIVE، والموسم غير مغلق. والشرطان الثلاثة مُفصَّل صراحةً، لكلٍّ منها سبب تجاري حقيقي في الرفض.

2.6 الإيصالات ومحطات الدفع

المال يُسجَّل في إيصالات لا فواتير — مخطط البيانات يصرّح بذلك. وللإيصال رقم نسبي للمنظمة أو النادي لا تسلسل عام، ومبلغ، وبنود، ونوع:

• ORG_CLUB_MEMBERSHIP — النادي يسدد رسوم عضوية الموسم.
• ORG_CLUB_PREPAID — تعبئة رصيد مدفوع مسبقًا.
• ORG_CLUB_LICENSES — رسوم التراخيص.
• CLUB_ATH_LICENSE وCLUB_ATH_SERVICE — مال يتحرك داخل النادي.
• OTHER.

ويمكن تقسيم الإيصال إلى محطات دفع (أقساط). أي يدفع النادي رسم موسم كبيرًا على دفعات، والإيصال يتابع الأجزاء. ويحمل الإيصال أيضًا حالة دفع (مدفوع، أو غير مدفوع، أو جزئي) تُحتسب ولا تُخزَّن، وتاريخ استحقاق منفصل عن تاريخ الإصدار.

ويحمل النادي رصيدًا هو المحفظة المدفوعة مسبقًا، يُخصم ذرّيًا داخل المعاملة نفسها التي تُصدر الرخصة، فلا يمكن أن يصبح سالبًا عبر سباق بين طلبات.

2.7 الرياضيون

الرياضي شخص، لكن الأهم: الرياضي ليس مستخدمًا. قد يكون له حساب — وليّ أمر يتابع طفلًا، أو منافس يتابع نفسه — وقد لا يكون له: منافس طفل سجلٌّ رياضي حقيقي بلا حساب إطلاقًا. ويمكن ربط الرياضي بحساب مستخدم، بواحد لواحد.

يحمل الرياضي بيانات هوية (اسم، وتاريخ ميلاد، ونوع ورقم بطاقة التعريف، والجنس)، وناديًا، وفئة، ووظيفة (دوره، مثل رئيس أو سكرتير أو أمين مال أو نائب رئيس)، وحالة من PENDING وACTIVE وSUSPENDED وARCHIVED.

الفئات هي الأقسام التنافسية: اسم، وجنس، وعمر، ومجموعة أوزان مسموحة. وتسلسل الفئة إلى فئة سابقة، فينتقل «بنات مبتدئ» إلى قسم أعلى. ويمكن أن تنتمي الفئة إلى نادٍ بعينه، وهكذا يعرّف النادي أقسامه الداخلية.

الدرجات هي ما يقابل الأحزمة والرتب، وهي أيضًا تتسلسل إلى درجة سابقة.

2.8 السيرة الرياضية — سجل التدقيق

كل ما يحدث للرياضي مهم يُسجَّل كـحدث سيرة يُضاف فقط، ولا يُكتب فوقه أبدًا. والمفردات واسعة وهي تحكي ما تعتبره الأعمال جديراً بالتسجيل: انضمام إلى نادٍ، وانضمام إلى منظمة، وبدء وظيفة، وانتهاء وظيفة، وانتقال إلى فئة جديدة، وترقي درجة، واشتراك في تدريب، وفوز، وخسارة.

يسجّل كل حدث من راجعه وحالة مراجعته — فحدث السيرة ليس صحيحًا تلقائيًا، بل مُقدَّم ثم مُراجَع. فمن له الصلاحية يعتمد تاريخ رياضي. وهناك أيضًا حقل يفرّق بين «من سجّل هذا» و«من نقل الرياضي بين الأندية».

هذه هي الميزة التي تجعل المنصة أغلى من جدول بيانات: التاريخ الكامل القابل للمراجعة لكل منافس.

2.9 مجالس الإدارة — لجان لا أثاث

للمنظمة ولكل نادٍ مجلس إدارة: مجموعة من المناصب، لكل منها عدد مقاعد. قد يكون مجلس النادي «رئيس بواحد، وسكرتير بواحد، وأمين مال بواحد»، وتطلب المنظمة أربعة على الأقل منها أثناء الإعداد.

شغل المقعد طلب، لا تعيين. فلمقعد المجلس حالة تمثّل اتفاقًا بين طرفين:

• PENDING_ADD — رُشّح أحدهم، ولم يقبل بعد.
• ACTIVE — قبل.
• REVOKED وTERMINATE — انتهى.
• PENDING_REVOKE وPENDING_TERMINATE وPENDING_ACCEPT وPENDING_ACTIVE — الحالات الانتقالية أثناء الاتفاق على التغيير.

ويمكن شغل مقاعد مجلس النادي ب دعوة عبر البريد برمز وانتهاء صلاحية. ويمكن للمدعوّ القبول أو الرفض. ولكل دعوة حالتها: CREATED وPENDING وACCEPTED و REFUSED وEXPIRED وCANCELLED وUNDELIVERED. وتعذّر التسليم حالة صريحة — فالارتدادات متوقعة ومُتتبَّعة لا معاملة كإخفاق.

لاحظ أن مقاعد مجلس المنظمة لا يوجد لها تدفق دعوة — الدعوة لمقاعد النادي فقط. وهذا التنافر قائم ويستحق التأكيد.

2.10 الصلاحيات — قلب نموذج التفويض

هنا تقيم معظم تعقيد المنتج، وهو نموذج من أربع طبقات بالفعل:

• الصلاحية — إجراء واحد، مثل «إضافة نادٍ» أو «اعتماد طلبات انضمام» أو «مراجعة طلبات رخصة جديدة». منها 43.
• الوحدة — صلاحيات مجمّعة في مجالات عمل: إدارة المستخدمين، وإدارة الوظائف، وإدارة الدرجات، وإدارة المواسم، وإدارة الأندية، وإدارة الرياضيين، وإدارة المسابقات، وإدارة مجلس المنظمة، وإعدادات المنظمة، وإدارة مالية المنظمة، وإدارة تراخيص المنظمة.
• مستوى الصلاحية — لمن عُدّت الصلاحية: USER وCLUB وZONE وORG وCONT وFED. وكل صلاحية يحمل المستويات التي تنطبق عندها.
• مجموعة الصلاحيات — حزمة صلاحيات، تُسنَد لشخص داخل منظمة واحدة.

إذن الصلاحية ليست «هل تستطيع أن تفعل X» فحسب، بل «هل تستطيع أن تفعل X عند هذه الدرجة من التسلسل». وهكذا يستطيع رئيس الاتحاد ومدرب النادي حمل نفس مفتاح الصلاحية مع بقاء تمييزهما صحيحًا بحسب السياق.

مجموعات صلاحيات النظام تُسنَد تلقائيًا عند الإنشاء بحسب الدور:

• ORG_CREATOR — من أنشأ المنظمة يصبح مُنشئها ويحصل على مجموعة إدارةها الكاملة.
• CLUB_CREATOR — من أنشأ نادٍ.
• ATHLETE_CREATOR — من سجّل نفسه رياضيًا.
• USER_CREATOR — مذكور في المخزون مرجعًا لإنشاء النادي، دون مجموعة مُهيّأة.

كل ما في الشريط الجانبي قائم على الصلاحيات. القائمة ليست ثابتة؛ فكل عنصر يعلن الصلاحية التي يحتاجها، ويرى المستخدم بالضبط ما تستحقه صلاحياته. لهذا يرى شخصان في المنظمة نفسها تطبيقين مختلفين.

[تعارض النية والتنفيذ] بعض الصلاحيات موجودة في المخزون لكنها غير مُسندة إلى أي مجموعة: CONFIRM_GRADE_CHANGE، وVALIDATE_CLUB_TEAM، وORG_FIN_MANAGEMENT، و ORG_FIN_PAY_STATS، وORG_FIN_REQUEST_MEMBERSHIP، وORG_LIC_MANAGEMENT، وثلاثية مراجعة الترخيص، وMANAGE_COMPETITIONS، وثلاثية الترخيص على مستوى النادي. فهي معرَّفة وواصلة في المخزون لكنها غير مُسندة افتراضيًا، وهو ما يُقرأ كأنها محجوزة لمشغّل المنصة ليجوزها لكل منظمة على حدة — أو كخطوة لم تكتمل في بناء وحدتي التمويل والترخيص. هذا أوضح سؤال مفتوح في المنتج.

2.11 دورة حياة المنظمة — الإنشاء والمراجعة والاعتماد

المنظمة لا توجد لمجرد ملء استمارة.

الإنشاء يتطلب: اسمًا، ونوعًا (أي درجة في التسلسل)، وقالبًا (فئة منظمة)، ومنطقة خدمة (في أي منطقة بيانات تُستضاف)، وبيانات اتصال، ودولة، وقبولًا صريحًا للشروط. ثم يُنشئ قاعدة بيانات مخصصة، ويدفع المخطط، ويزرع البيانات المرجعية، وينشئ ملف المُنشئ داخلها، ويُسنِد له مجموعة ORG_CREATOR.

تُنشأ المنظمة بحالة PENDING.

الإعداد — يجب أن تبلغ منظمة في حالة PENDING حدًّا أدنى قبل مراجعتها. أربعة أمور، وهي نفس الأربعة التي تعرضها الواجهة كقائمة تحقق:

• موسم واحد على الأقل
• أربع وظائف للمنظمة وأربعة مقاعد في المجلس على الأقل
• أربع فئات على الأقل

حتى ذلك الحين يُحتجَز المُنشئ على شاشة الإعداد.

طلب المراجعة ينقل الحالة من PENDING إلى REVIEW_REQUESTED. والمُنشئ وحده هو من يطلب. والطلب لا يعتمد شيئًا تلقائيًا.

بوّابة المراجعة إعداد على مستوى المنصة، ومقصود أن يكون قابلًا للضبط، لأن الجواب الصحيح قرار تجاري لا قرار برمجي:

• لوحة التحكم مفتوحة (الافتراضي) — المنظمة قيد المراجعة تحصل على التطبيق كاملًا ريثما تكون المراجعة مفتوحة. مناسب حين تكون المراجعة إجراء شكلي. ل.لوحة التحكم مفتوحة (الافتراضي) — المنطقة قيد المراجعة تحصل على التطبيق كاملًا ريثما تكون المراجعة مفتوحة. مناسب حين تكون المراجعة إجراء شكلي.
• الاحتجاز على شاشة الإعداد — تُحتجَز حتى الاعتماد. مناسب حين لم تتحقق المنصة من المنشأة ولا تريده يعمل.

حالة PENDING مقيَّدة في الوضعين معًا: فالمنظمة لم تطلب بعد، فالإعداد ما زال مستحقًا. وسبب اعتماد الوضع المفتوح افتراضيًا هو أن الوضع التقييدي الافتراضي بلا مسار اعتماد مدمج يحبس كل منظمة إلى الأبد — فاختير الوضع الذي له مخرج.

الاعتماد على مستوى المنصة إجراء صريح ومميّز: مشغّل المنصة يراجع المنظمات المنتظرة ويحرّكها من REVIEW_REQUESTED إلى ACTIVE. وهذا ليس نفس شيء مراجعة طلب الانضمام (طلب شخص في الانضمام إلى منظمة). فالخلط بينهما كان خطأ مبكرًا يستحق التسجيل: أحدهما يعمل على حالة المنظمة، والآخر على طلب شخص للانضمام.

حالات المنطقة: PENDING وREVIEW_REQUESTED وACTIVE وSUSPENDED. والمنظمة المعلّقة تبقى مخفية — على عكس منظمة قيد المراجعة، والتي يُسمح لها بالعمل ريثما تكون قيد المراجعة.

2.12 الانضمام إلى منظمة — أربعة مسارات مختلفة

العضوية ليست مسارًا واحدًا، بل أربعة، وهي أشياء مختلفة حقًا:

1. المنظمة تدعو شخصًا. (INVIT_USER)
2. شخص يطلب الانضمام. (USER_REQUEST)
3. المنظمة تدعو نادٍ كاملًا. (INVIT_CLUB)
4. نادٍ يطلب الانضمام إلى المنطقة. (CLUB_REQUEST)

ويمكن أن يتحرك طلب الانضمام عبر PENDING ثم VALIDATE أو REJECT أو ACCEPT أو REFUSE أو FORWARD. وFORWARD هو المهم — إذ تستطيع المنظمة تصعيد طلب نادٍ إلى مستوى أعلى، وهكذا تمرر هيئة إقليمية حالة إلى هيئة وطنية. إنها ميزة حوكمة متعددة المستويات حقيقية، ولهذا تحمل طلبات الانضمام رابطًا عائدًا إلى المراجعة التي قامت بالإحالة.

ولشخص ينضم إلى نادٍ: نفس الشكل (دعوة أو طلب)، ويمكن قبوله مستخدمًا أو رياضيًا — وهكذا يُدعى وليّ أمر لإدارة طفل، ويُدعى مدرب لإدارة فريق، من مسار واحد.

2.13 شروط الاستخدام والقبول القانوني

الشروط مُصدَّرة بإصدارات. فهناك قائمة بإصدارات الشروط، أحدها مُعلَّم بأنه الحالي، ولكل إصدار تاريخ بدء. والقبول يُسجَّل كسجل لكل مستخدم ولكل إصدار بتاريخ.

[فجوة امتثال] لا يوجد أي مسار في النظام يكتب سجل قبول. فالنموذج والاستعلام وعلامة «قبل الشروط» في إنشاء المنطقة كلها موجودة، لكن الكتابة لا تحدث أبدًا — فالقبول المسجَّل عند التسجيل مُلفَّق لا مقيس من حدث حقيقي. ولمنتج يعمل تحت قانون حماية البيانات هذه فجوة امتثال حقيقية، وليست تجميلية.

2.14 المسابقات والإداريون والدوريات

المسابقات والدوريات تظهر في مخزون الصلاحيات وفي الشريط الجانبي، وللدوريات شاشة، لكن المسابقات عنصر فارغ — الوحدة مذكورة ومرخّصة وغير مبنية. أما الإداريون فهو مجلس المنطقة من زاوية تنظيمية. وكلاهما منطقه عمل لاحق؛ والمهم أن وجودهما في القائمة لا يعني أنهما مكتملان.

3. رحلات المستخدم من البداية إلى النهاية

الرحلة A — شخص يسجّل ويؤسّس منظمة

1. التسجيل بالبريد وكلمة السر والاسم الأول والاسم الأخير. يُنشأ حساب على مستوى المنصة بحالة NEW (انظر الرحلة F — هذا مهم).
2. تسجيل الدخول. يقرّر الخادم الوجهة بناءً على عدد المنظمات التي يمكن للمستخدم الانتماء إليها. فالشخص الجديد تمامًا يجد نفسه في إنشاء منظمة.
3. إنشاء المنظمة — اسم، ونوع، وقالب، ومنطقة خدمة، واتصال، ودولة، وقبول الشروط. هذا أثقل إجراء في المنتج: ينشئ المستأجر، ويهيّئ قاعدة بياناته، ويزرعها، ويجعل صاحبه مُنشئها.
4. الإعداد — يجب على المُنشئ تقديم الحد الأدنى الذي يتطلبه الأعمال قبل أن تستحق المنطقة المراجعة: موسم، وأربع وظائف، وأربعة مقاعد في المجلس، وأربع فئات. وتعرض قائمة تحقّق نسبة الإنجاز.
5. طلب المراجعة — يطلب المُنشئ من فريق المنصة النظر في الأمر. تصبح المنطقة REVIEW_REQUESTED. وبحسب إعداد بوّابة المنصة، إما أكمل العمل في التطبيق كاملًا أو انتظر عند شاشة الإعداد.
6. اعتماد المنصة — يشغّل المنصة يراجع ويعتمد. تصبح المنطقة ACTIVE، وعندها تملك التطبيق كاملًا.

الرحلة B — مشغّل المنصة يدير المنصة

يسجّل الدخول فيصل إلى بوابة، لا إلى لوحة التحكم — فمشغّل المنصة لا يكون داخل مستأجر أبدًا. ومنها يستطيع مراجعة المنظمات المنتظرة للاعتماد، وقراءة إعدادات المنصة، ورؤية أعداد المنظمات بحسب الحالة. ولا يمكن أن تُعطى له بيانات منظمة بالخطأ، لأن البوابة سطح منفصل عن تطبيق المستأجر.

الرحلة C — منطقة تدير موسمها

العمل اليومي للمنظمة حلقة، لا قائمة مهام:

1. تجهيز الموسم — التواريخ، ورسوم الرياضي، ورسوم النادي، ووضع الدفع (مسبق أو عند الطلب)، وسياسة ترقيم الرخص، ونافذة فتح وإغلاق السداد.
2. تعريف الرياضة — فئات بأوزانها، ودرجات، ووظائف، ومقاعد مجلس. والفئات والدرجات تتسلسل، فيُعرَّف التقدّم مرة واحدة.
3. تنظيم المجلس — ترشيح أشخاص للمناصب، وهم يقبلون.
4. تسجيل الأندية — يُنشأ نادٍ تحت المنطقة، ويوضع في منطقة، ويصبح مُنشئه مديره.
5. رسوم عضوية الأندية — تطلب الأندية سداد رسوم العضوية للموسم، وتصدر المنطقة إيصالًا، ويمكن سداده على أقساط.
6. مراجعة طلبات الترخيص — طابور «عند الطلب». يعتمد أو يرفض، ويُسجَّل كل قرار مع المراجع والملاحظات. والاعتماد يُصدر الرخصة ويُتمّ الإيصال في معاملة واحدة.
7. إغلاق الموسم عند الانتهاء، ما يوقف كل نشاط ترخيص لاحق.

الرحلة D — نادٍ يدير رياضييه

1. يضيف مدير النادي رياضيين — مُنشئًا سجل الرياضي، ومن شاء يُنشئ له حسابًا لوليّ الأمر أو للرياضي.
2. لكل رياضي فئة (قسم) ووظيفة (دور).
3. يرفع النادي طلبات ترخيص لرياضييه. في نظام الدفع المسبق تُخصم الرسوم من رصيد النادي فورًا. وفي نظام عند الطلب يصبح الطلب بانتظار مراجعة المنطقة.
4. يتقدّم الرياضيون: فئة جديدة، درجة جديدة، نتيجة مسابقة. كل منها حدث سيرة يحتاج مراجعة، فيبقى التاريخ موثوقًا.
5. يمكن تعليق الرياضيين أو أرشفتهم، فيتوقف الترخيص عنهم دون المساس بحسابهم على مستوى المنصة.

الرحلة E — وصول الدعاوات والطلبات

• دعوة مجلس نادي — يدعو نادٍ شخصًا لمقعد في المجلس عبر البريد. يحمل الرابط رمزًا وانتهاء صلاحية. يقبل المدعوّ أو يرفض. وتُتتبَّع الارتدادات كـUNDELIVERED لا تُفقد بصمت.
• طلب انضمام إلى نادٍ — يطلب شخص الانضمام إلى نادٍ، أو يدعوه النادي. ويُقبل مستخدمًا أو رياضيًا.
• طلب انضمام إلى منظمة — أحد المسارات الأربعة أعلاه، مع خيار الإحالة صعودًا.

الرحلة F — مشكلة الهويتين

في النظام حالة الحساب على مستوى المنصة (NEW وPENDING وACTIVE و SUSPENDED)، معناها «هل أتمّ هذا الشخص الخطوات التي تجعله قادرًا على استخدام المنصة؟».

وتطبّق بوّابة على لوحة التحكم ذلك حرفيًا: ما دام الحساب ليس ACTIVE، يبقى المستخدم محبوسًا في صفحة هبوط واحدة.

النتيجة ملموسة: يُنشأ حساب مُنشئ المنطقة بحالة NEW عند التسجيل، ولا شيء يرفعه أبدًا. وفي المقابل، مسارات إنشاء الرياضي والنادي والمستخدم الأخرى ترفع الحساب إلى ACTIVE. أي أن شخصًا يستطيع أن يؤسّس منظمة، ويحصل على اعتمادها الكامل، ومع ذلك يبقى عاجزًا عن التنقّل.

لم أغيّر هذا. وفيه ثلاثة مخرجات، وهي قرار منتج:

A هي قراءتي للنية، لأن عدم اتساقها مع مسارات الإنشاء الأخرى يبدو إغفالًا لا سياسة.

ونقطة مهمة: حالة المنطقة (نشطة، أو قيد المراجعة، أو معلّقة) مفهوم مختلف تمامًا عن حالة الحساب على مستوى المنصة، وعن حالة العضوية داخل المنطقة (وهي تُخزَّن داخل قاعدة بيانات كل منظمة). خلط هذه الثلاثة هو مصدر أغلب الالتباس في هذا النظام. الثلاثة مستقلة، ولكل منها قرار منفصل.

4. قواعد عامة تحكم كل شيء

هويتان، دائمًا. حساب على مستوى المنصة + ملف داخل كل منظمة. ويمكن أن يحمل الشخص سلطة مختلفة تمامًا في منظمتين. وكل «مستخدم» داخل مستأجر هو في الحقيقة «حساب على مستوى المنصة، يُنظر إليه من داخل هذه المنطقة».

سياق المنطقة يُحدَّد عند تسجيل الدخول، لا بالبحث عنه. عند تسجيل الدخول يحدّد النظام منظمتك فقط إذا كان المرشّح الوحيد غير ملتبس — بعدّ العضويات وطلبات الانضمام المفتوحة معًا، ومعاملة سجلّين يشيران إلى المنطقة نفسها كخيار واحد. فإن وُجد أي التباس، لا يُحدَّد سياق وتُحوَّل لاختياره. وإن كان واحدًا فقط، يُثبَّت هذا السياق في جلستك. ولهذا فإن تبديل المنطقة في الشريط علوي إعادة مصادقة كاملة، لا تغيير تفضيل: يعيد اشتقاق سياق بياناتك بالكامل ويُصدر جلسة جديدة.

لا شيء يُكتب فوقه؛ التاريخ محفوظ. أحداث السيرة، ومراجعات التراخيص، ومراجعات طلبات الانضمام — كلها تُضاف ولا تُستبدل. والقيمة الحالية استمرار للتاريخ، لا التاريخ نفسه.

كل طلب يحرّك مالًا أو حالة هو سجل قابل للمراجعة. طلبات الترخيص، ومدفوعات العضوية، وتغييرات الدرجات، والتحقق من فرق النادي. هذه هي القيمة الفعلية للمنتج: سلسلة تدقيق من مَن طلب، ومَن اعتمد، ومتى.

الصلاحيات لكل منظمة وهرمية. فالصلاحية صالحة عند درجات معيّنة من تدرّج نادٍ ← منطقة ← منظمة ← قارية ← اتحاد، والشريط الجانبي يعرض ما تستحقه صلاحياتك فقط. شكل التطبيق دالة على دورك.

المنصة تحرس الحدود، والمنطقة تحرس الداخل. فمشغّل المنصة يقرّر أي المنظمات توجد، وهل المراجعة تحجب العمل أم لا. وداخل المنطقة المعتمدة، قرارات كل شيء آخر لمديري تلك المنطقة.

5. مواضع يختلف فيها التنفيذ عن النية

هذه هي المواضع التي أودّ أن أعرضها على العميل، لأنها المواضع التي قد يُخالف فيها أي تغيير ظاهرَ النيةَ المقصودة.

5.1 مشكلة الهويتين: حسابات NEW محبوسة [مطلوب قرار]

موصوفة بالكامل في الرحلة F. والخلاصة: مُنشئ المنطقة لا يستطيع التنقّل في التطبيق حتى لو اعتُمدت منظمته بالكامل.

لم أغيّر شيئًا. والمقترحات الثلاثة في الرحلة F أعلاه، وأوصي بـA.

5.2 بوّابة هيكل لوحة التحكم

كانت هناك بوّابة تقرّر أي المنظمات ترى الشريط الجانبي والشريط العلوي. وكانت تعرض التطبيق الكامل فقط لمنظمات ACTIVE، ما جعل منظمة قيد المراجعة ترى صفحة تعمل بلا تنقّل إطلاقًا — وهو ما يُقرأ «التخطيط مفقود» ويدعو إلى إعادة بناء مكونات موجودة أصلًا.

القاعدة القائمة الآن: ACTIVE وREVIEW_REQUESTED يحصلان على التطبيق الكامل؛ PENDING وSUSPENDED لا يحصلان عليه. والتعليل الجدير بالتسجيل: منظمة قيد المراجعة منظمة مشروعة تعمل عملًا مشروعًا، وإخفاء تنقّلها يعاقبها على تأخير ليس بذنبها. أما المنظمة المعلّقة فمحتجَزة لسبب حقيقي، فتبقى معتمة.

5.3 تسع صفحات تحوّل تحمل جميعها عيبًا واحدًا [مُصلح جزئيًا]

الوجهات المجرّدة في الشريط الجانبي (/clubs و/settings و/staff و/athletes …) هي صفحات راحة تحوّل إلى تبويبها الحقيقي. وكل واحدة منها تبني وجهة التحويل بإلحاق الجزء الناقص على العنوان الكامل للطلب الوارد، فتُثبَّت الوجهة على أي مضيف جاء منه الطلب.

في حاوية يكون ذلك المضيف هو المنفذ الداخلي، بينما استخدم المتصفح المنفذ المنشور — فتقفز القفزة بصمت إلى تطبيق آخر على المضيف نفسه، فيرى المستخدم صفحة 404 لتطبيق آخر لصفحة موجودة. وتسع صفحات بهذا الشكل؛ أُصلحت واحدة وتحقّقت، والثماني الباقية العيب نفسه.

المؤكد أن مسار التحويل نفسه صحيح التصميم، والعيب محصور في المضيف الذي تسمّيه القفزة.

5.4 صلاحيات غير مُسندة [مطلوب قرار]

تسع صلاحيات فأكثر — معظمها واجهة التمويل ومراجعة الترخيص — لا تنتمي إلى أي مجموعة صلاحيات. إما أن مشغّل المنصة يسنّدها لكل منظمة يدويًا (وهو معقول: هذه بالضبط السلطات التي لا يُمنح لها تلقائيًا)، أو أن خطوة الإسناد لم تكتمل. يستحق التأكيد، لأنه يحدد هل وحدتا التمويل والترخيص «مقيّدتان بالتصميم» أم «غير قابلتين للوصول أصلًا».

وتفصيل ذو صلة: الشريط الجانبي يُظهر عنصرًا للتمويل، مقيّدًا بصلاحية إدارة التمويل — لكن تلك الصلاحية في المجموعة غير المُسندة، والشاشة المقصودة غير موجودة. فالعنصر اليوم رابط ميت لا ميزة مقيّدة. وهو متسق مع «التمويل مخطط له وقيد البناء»، فيستحق التأكيد بدل الافتراض، إذ إن مخزون الصلاحيات يصف بالفعل واجهة تمويل ومراجعة ترخيص كاملة بالتفصيل.

5.5 قبول الشروط لا يُسجَّل أبدًا [فجوة امتثال]

الإصدارات والسجلات وعلامة «قبل الشروط» كلها موجودة. ولا يكتب أي مسار في النظام سجل قبول. فالقبول المرتبط بالحسابات مُلفَّق لا مقيس. ولمنتج يعالج بيانات شخصية هذه فجوة حقيقية، والإصلاح كتابةٌ عند لحظة القبول لا تغيير في الواجهة.

5.6 ملاحظة على ترقيم الفصول

الأرقام في هذا القسم (5.1 — 5.5) تشير إلى مواضع الاختلاف بين النية والتنفيذ فقط، ولا تشمل كل ما في المستند. أما ما عدا ذلك من الملاحظات والقواعد فيُقرأ كوصف لحالة المشروع القائمة، لا كقائمة مطالب.

6. ملاحظة عن المنهج

استُنتج هذا الوصف من قراءة نموذج المجال، ومخزون الصلاحيات، وعقد الواجهات، وقواعد دورة الحياة في منطق الأعمال، والشاشات الموجّهة للمستخدم — لا من بنية الشيفرة. وحيث استنتجتُ نية — خاصةً قواعد ترقيم الرخص، ومبدأ «التاريخ على القيمة الحالية» — فالأمر مذكور صراحةً بدل الجزم. وحيث كان شيء غير مبني وصفته غير مبني بدل وصف ما قد يفعله.

وعند الاختلاف بين هذا المستند والسلوك القائم: السلوك القائم هو الواقع، وهذا المستند قراءتي له. فنرجو تصحيح القراءة، لا اعتبار الشيفرة خطأ. وعدة مواضع أعلاه صيغت عمدًا أسئلة إليكم، لأننا نفضّل السؤال على التخمين في أمور أعمالكم.

ما أحتاجه منكم للخطوة التالية:

1. تأكيد الفكرة التجارية في القسم 1، ولا سيما نموذج المستأجر.
2. حسم [مطلوب قرار] في 5.1 (اختيار A أو B أو C).
3. حسم [مطلوب قرار] في 5.4 (هل منح الصلاحيات يدويًا قرار مقصود؟).
4. مراجعة القسم 2، وبخاصة وضع الدفع وترقيم الرخص.
5. إبلاغنا بأي نقطة لم تُذكر هنا وتعتقدون أنها جزء من العقد.