أساس Founders & PMs: سياق المنتج وقراءة السوق وخريطة codebase التي يرثها كل قرار

لدى فريقك بالفعل الـ playbooks الخاصّة بـ product-context وmarket-landscape وread-the-codebase — الوصفات المُجرَّبة لالتقاط استراتيجيتك، ورسم خريطة الميدان، وقراءة الـ repo الخاص بك بلغة واضحة، خطوة خطوة. هذه الوحدة هي الطبقة فوق الوصفة. هنا تُتقِن الأشياء الثلاثة التي يرثها كل spec وprototype وقرار لاحق — ما الذي تبنيه ولمن، وأين تفوز وتخسر فعلًا، وأين ستعيش feature في كودك فعلًا — تبنيها فعلًا، وتُثبِت — أمام سُلّم تقييم — أنك قادر.

إنها الوحدة الأولى من مسار Founders & PMs المؤهِّل للاعتماد، وهي التي نُبقيها مفتوحة. اقرأها، وأنجِز التكليف، وستعرف تمامًا قيمة هذا العمق قبل أن تُدخِل فريقًا في الباقي.

كل spec تكتبه، وكل prototype تبنيه، وكل مذكّرة قرار وسرد مجلس تنشره هو سحبٌ من ثلاثة حسابات: ما الذي تبنيه فعلًا ولمن، وأين تفوز فعلًا في السوق، وما الذي يفعله كودك فعلًا. ومعظم المؤسِّسين لا يموّلون هذه الحسابات كتابةً قط، فتُعيد كل محادثة مع Claude شرح الشركة من الصفر، وتتجادل كل مكالمة roadmap من ذاكرة مختلفة عن المنافسة، ويتحوّل كل سؤال «كم سيصعب هذا؟» إلى اجتماع. الأساس هو الساعة التي تموّل فيها الثلاثة مرة واحدة، وهو الساعة الأعلى أثرًا في المسار كله.

لماذا الأساس هو الساعة الأعلى أثرًا التي ستقضيها

الشركة الغامضة هي شركة تبدو واثقة. اطلب من Claude أن يزن feature دون وثيقة سياق ولن يرفض — بل سيخمّن مستخدمك وأولوياتك وقيودك، ويجيب بطلاقة انطلاقًا من التخمين. الجواب يُقرأ كنصيحة. وهو في الحقيقة خيال يرتدي صوتًا واثقًا، والإخفاق غير مرئي لأن لا شيء في المُخرَج يبدو غير مؤكَّد.

نمطا فشل يفسّران تقريبًا كل مكالمة roadmap تنحرف عن مسارها. الأول هو الـ spec غير المؤسَّس — تُختبر feature تحت ضغط مقابل مستخدم متخيَّل بدل المستخدم الحقيقي، لأن لا أحد كتب من هو المستخدم الحقيقي. تجتاز كل مراجعة لأن الـ spec متّسق داخليًا؛ لكنه فقط غير متّسق مع استراتيجيتك الفعلية. والثاني هو ادّعاء codebase غير المُتحقَّق منه — يطلب مؤسِّس من Claude تحديد نطاق feature، فيحصل على جواب واثق «هذا يلمس ثلاثة ملفات، جهد صغير»، ويأخذ ذلك الرقم إلى محادثة هندسية، ليكتشف أنه كان تخمينًا معقول المظهر عن كود لم يفتحه Claude فعلًا قط. على نطاق صغير، ذلك تصحيح محرج. وعلى نطاق roadmap ربع سنوي، إنه التزامٌ بُني على خيال.

ثلاثة أشياء تُصلح نمطَي الفشل قبل أن تُكتب أي spec. وثيقة product-context تعني أن «مستخدمنا» و«رهاناتنا» و«ما لا نفعله» تشير إلى شيء ملموس، فتُختبر الـ spec تحت ضغط مقابل استراتيجيتك الحقيقية لا تخمين. وموجز market-landscape يعني أنك تعرف أين تفوز وتخسر فعلًا — بما في ذلك أمام «لا تفعل شيئًا» و«جدول بيانات»، لا فقط أمام المنافسين الذين تقلق منهم بالفعل — فتُجيب مكالمة roadmap عن السوق الموجود فعلًا، لا السوق الذي في رأسك. وخريطة codebase تعني أن سؤال «أين ستعيش هذه؟» يُجاب من الـ repo الحقيقي، مفتوحًا ومقروءًا، لا مُستنتَجًا من اسم feature. ابنِ هذه الثلاثة فترثها كل وحدة لاحقة: تُختبر الـ spec في الوحدة الثانية تحت ضغط مقابل anti-focus الحقيقي لديك لأن الوحدة الأولى سمّته بالفعل؛ وتزن مذكّرة القرار في الوحدة الثالثة الخيارات مقابل أولوياتك الحقيقية لأن الوحدة الأولى كتبتها بالفعل؛ ولا يُعيد سرد المجلس في الوحدة الخامسة اشتقاق موقعك السوقي من الصفر لأن الوحدة الأولى بنته بالفعل.

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

وثيقة product-context — ما الذي يجعلها ركيزة لا ديكورًا

الـ playbook يمنحك الخطوات: أسقِط عرضك التقديمي، استخرِج مسودّة، اشحذ التركيز. الإتقان هو الحُكم داخل تلك الخطوات — القرارات التي تفصل وثيقة سياق يستطيع Claude أن يفكّر منها فعلًا، عن وثيقة تُقرأ جيّدًا ولا تقرّر شيئًا.

• التخمين الواثق أسوأ من فراغ صريح. إن لم يُسمِّ عرضك التقديمي north-star metric قط، فالتصرّف الصحيح وثيقة سياق تقول ذلك بصراحة — لا وثيقة يستنتج فيها Claude مقياسًا معقول المظهر ليملأ الفراغ. الوثيقة التي تحوي استراتيجية مُختلَقة تُؤسِّس كل جواب لاحق على خيال؛ والوثيقة ذات الفراغ الصريح تُخبرك بالضبط بما عليك أن تكتشفه قبل أن تثق بأي شيء يُبنى عليها.
• anti-focus هو الجزء الذي يستحقّ مكانه. معظم وثائق السياق قوية في «ما الذي نبنيه» وضعيفة في «لمن لسنا صراحةً» و«ما الذي نتجنّبه عمدًا». تلك المساحة السلبية هي ما يمنع محادثة «هل نبني X؟» من الانحياز افتراضيًا نحو نعم — إنها الخط الذي تُفحَص الـ spec مقابله، لا الوصف الإيجابي.
• وثيقة واحدة معتمَدة، ومالكٌ واحد مُسمّى. وثيقة سياق تنحرف لأن ثلاثة أشخاص يعدّلونها بصمت في اتجاهات مختلفة أسوأ من غياب الوثيقة — فهي تمنح كل قارئ ثقةً زائفة بأنه يقرأ الاستراتيجية الحالية. سَمِّ مالكًا، ورقّمها بإصدارات، وعامِل أي تغيير كقرار مُراجَع، لا تصحيح خطأ إملائي.

وثيقة سياق تجتاز هذا المعيار تُقرأ كصفحة فرضيات واحدة: ما الذي تبنيه والمشكلة التي يحلّها، والمستخدم الواحد المهم (ومن لسنا له صراحةً بعد)، والـ north-star metric الخاص بك وأين يقف، ورهانات هذه المرحلة وanti-focus، وقيودك الصارمة — قصيرة بما يكفي لتُلصِقها فعلًا أعلى محادثة، لا مقالة استراتيجية لا يفتحها أحد مرّتين.

قراءة market-landscape — الوتد الذي تستطيع الدفاع عنه فعلًا

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

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

القراءة السوقية التي تجتاز هذا المعيار تُسمّي المنافسين الحقيقيين والمجاورين (بما في ذلك اللا-استهلاك)، وقراءة فوز/خسارة صادقة لكل منافس، والتحوّلات السوقية القليلة التي تُحرِّك رهاناتك فعلًا، ووتدك المختار مع تعليله، وقائمة مراقبة قصيرة — مبنية لتُحدَّث في أقل من ساعة كل ربع سنة، لا أن تُشتَقّ من الصفر.

خريطة codebase — مُتحقَّق منها لا مفترَضة

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

• خريطة لا تستطيع الإشارة بها إلى الملفات الفعلية ليست خريطة. «هذا سيلمس قائمة المقالات وطبقة البيانات» مفيد فقط إن سمّى ملفات حقيقية قرأها Claude فعلًا — SignupForm.tsx، db/users.ts — لا تخمينًا معقول المظهر على هيئة جواب. إن لم يفتح Claude المجلد، فهو يطابق الأنماط انطلاقًا من اسم feature، ولا فرق بين ذلك وبين تتبّع حقيقي حتى يأخذه أحد إلى محادثة هندسية ويتبيّن أنه خاطئ.
• النطاق الذي تأخذه إلى الهندسة تقدير بداية، لا رقم تدافع عنه. «يلمس على الأرجح X، ويحتاج غالبًا Y» المؤسَّس هو بالضبط المستوى الصحيح من الثقة الذي تدخل به — إنه سؤال لمهندس، لا حكمًا نهائيًا. عامِله كأي شيء أصلب من ذلك وسيكلّفك أول تصحيح من الهندسة مصداقية لم تكن مضطرًا لإنفاقها.
• السرّية ترافق القراءة. قد يحمل الـ repo الخاص بك أسرارًا أو بيانات عملاء أو منطقًا احتكاريًا — فتحه للفهم مقبول؛ لصق مقتطفات منه في أي مكان عام ليس كذلك. الخريطة تبقى داخل بيئتك المعتمَدة بالطريقة نفسها التي يبقى بها cap table.

خريطة تجتاز هذا المعيار تُسمّي الشكل العام الحقيقي للـ repo، وتتتبّع تدفّق مستخدم حقيقيًا واحدًا تُسمّي فيه الملفات الفعلية بالترتيب، وتُجيب عن سؤالين أو ثلاثة من نوع «سأخجل لو سألت هذا في اجتماع» بأجوبة مؤسَّسة، وتحدّد نطاق feature حقيقية واحدة مقابل ما ستلمسه فعلًا — مُدوَّنة في ملاحظات تأخذها إلى محادثة الهندسة التالية بدل أن تسردها من الذاكرة.

المعيار العربي — ما الذي يتطلّبه السياق ثنائي اللغة فعلًا

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

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

تكليفك

ابنِ وثائق الأساس الثلاث لـ شركتك أنت (المُوصى به: المُخرَج يصير الوثيقة التي تُلصِقها في كل محادثة منتج من الآن فصاعدًا) أو العلامة النموذجية ميزان، أداة مسك دفاتر SaaS لدول الخليج التي تظهر شريكتها المؤسِّسة ورئيسة المنتج فيها، دانا القاسمي، طوال هذا المسار. افتح مجلدًا يضمّ عرضك التقديمي وملاحظاتك والـ repo في Claude Desktop، ووافق على كل قراءة في نافذة Ask permissions، واعمل في المحادثة — دون حاجة إلى terminal.

مُخرَج الوحدة الأولى — أساس المؤسِّس

1. product-context.md  (أقل من 1.5 صفحة)
   - ما الذي تبنيه والمشكلة التي يحلّها
   - المستخدم الواحد المهم، ومن لسنا له صراحةً بعد
   - الـ north-star metric وأين يقف تقريبًا اليوم
   - رهانات هذه المرحلة، وما تتجنّبه صراحةً — مع سبب
     من سطر واحد لكل استبعاد
   - القيود الصارمة: حجم الفريق، والـ runway، والمنصّة، والواقع التنظيمي

2. market-landscape.md  (صفحة واحدة)
   - المنافسون المباشرون والمجاورون، بما في ذلك "لا تفعل شيئًا" و
     "جدول بيانات"
   - قراءة فوز/خسارة صادقة لكل منافس، موثَّقة لا مجامِلة
   - 3-4 تحوّلات سوقية تؤثّر فعلًا في رهاناتك
   - وتدك المختار، مع التعليل وما عليك إثباته
   - قائمة مراقبة قصيرة للإشارات التي قد تُغيّر الصورة

3. codebase-map.md  (صفحة واحدة، لـ repo الخاص بك)
   - الشكل العام: أي المجلدات تفعل ماذا
   - تدفّق مستخدم حقيقي واحد مُتتبَّع من البداية للنهاية، يُسمّي
     الملفات الفعلية بالترتيب
   - 2-3 إجابات لـ"أسئلة أساسية" بسيطة، مؤسَّسة في الكود
   - أين ستعيش feature مرشّحة حقيقية واحدة، والشكل العام للعمل

الفرق ثنائية اللغة: لاحظ أين ستحتاج الـ specs وسرد المجلس المستقبليان
المنبثقان من وثيقة السياق هذه إلى نسخة عربية، مؤلَّفة من موادّ عربية
لا مُترجَمة من هذه المسودّة الإنجليزية.

تمنحك حقيبة أدوات الأساس قالبًا جاهزًا للتعبئة لكلٍّ من هذه، والـ prompts التي تبنيها، فتملأ هيكلًا بدلًا من التحديق في ملف فارغ.

كيف يُقيَّم — سُلّم التقييم

هذا هو الجزء الذي لا تملكه الـ playbooks المجانية، والجزء الذي يجعل للاعتماد معنى. تُقيَّم ملفّاتك الثلاثة مقابل خمسة معايير. كلٌّ منها بدرجة مستوفٍ / قريب / ليس بعد — و«قريب» في أيٍّ منها يعني إعادةً، لا اجتيازًا.

سُلّم تقييم الأساس

1. وثيقة السياق صادقة لا مُختلَقة
   الفراغات في المواد المصدرية مُعلَّمة، لا مملوءة بتخمين معقول
   المظهر. وanti-focus يُسمّي استبعادات حقيقية بأسبابها،
   لا "سنرى" غامضة.

2. القراءة السوقية تضمّ المنافسين المملّين
   "لا تفعل شيئًا" / "جدول بيانات" يظهران حيثما كانا ذَوَي صلة.
   وقراءة الفوز/الخسارة صادقة، لا مجامِلة.

3. الوتد قابل للدفاع عنه
   مرتبط بقوّة حقيقية، مع تسمية "ما علينا إثباته" —
   لا مجرّد اختلاف من أجل الاختلاف.

4. خريطة codebase مُتحقَّق منها
   كل ادّعاء يُسمّي ملفًا حقيقيًا قرأه Claude فعلًا. ونطاق feature
   يُقرأ كتقدير بداية، لا رقمًا يُقدَّم كنهائي.

5. المعيار ثنائي اللغة صحيح (للمؤسِّسين ثنائيي اللغة)
   الموادّ العربية (حيثما وُجدت) تُؤسِّس النسخة العربية مباشرةً —
   فهي ليست ترجمة للمسودّة الإنجليزية.

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

المعيار، مرئيًّا — نموذج إجابة محلول (ميزان)

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

product-context.md — ميزان (مقتطف)

الملخّص: ميزان برنامج مسك دفاتر لشركات الخليج الصغيرة، مبنيّ ليتعامل مع
الـ VAT ووسائل الدفع المحلية من الصندوق مباشرةً، كي لا تحتاج شركة من
5 أشخاص محاسبًا بدوام جزئي لمجرّد البقاء ملتزمة.

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

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

North star: Active Customers. ‏9,460 حتى مايو 2026، في نمو ثابت عبر
الإحالة الشفهية داخل شبكات الشركات الصغيرة الخليجية.

رهانات هذه المرحلة: (1) ثقة الفوترة — كل رسم صحيح، مرّة واحدة، وقابل
للإثبات؛ (2) عمق الامتثال الخليجي — تصدير VAT والصيغ المحلية بشكل
أفضل من أي أحد؛ (3) منتج عربي الأصل، لا منتج إنجليزي مُترجَم.
ما لا نفعله هذه المرحلة: تعدّد العملات بما يتجاوز AED/SAR/QAR (عدد قليل
جدًا من العملاء يطلبه؛ نُعيد النظر عند 50+ طلبًا)، وتطبيق جوّال (الويب
يغطّي المهمّة المطلوب إنجازها)، وSSO للشركات الكبيرة (لا تحرّك نحو
قطاع enterprise بعد).

القيود: فريق من 14 شخصًا، و18 شهرًا من الـ runway عند معدّل الحرق
الحالي، وويب فقط، وPDPL الإماراتي ينطبق على كل بيانات العملاء المالية.

market-landscape.md — ميزان (مقتطف)

المنافسون:
  برنامج مسك دفاتر قديم لسطح المكتب — قوي مع المحاسبين الذين يعرفونه
  فعلًا، صاخب في القناة، وضعيف فعلًا في تفاصيل VAT الخليجية وفي كل ما
  هو cloud-native. نفوز عليه في عمق الامتثال وفي كوننا مبنيين لصاحب
  الشركة، لا للمحاسب.
  منافس إقليمي لمسك الدفاتر السحابي (غير مُسمّى، خليجي فقط) — أقرب
  منافس مباشر؛ قوي في السعر، ضعيف في تجربة المستخدم العربية الأصيلة
  (مبنيّ بالإنجليزية أولًا، والعربية طبقة ترجمة فيه). هنا يعيش وتدنا.
  "جدول بيانات + محاسب خارجي" — المنافس الحقيقي لأصغر شريحة. ليس منتجًا
  على الإطلاق، لكنه من نخسر أمامه حين يبدو الإعداد أصعب من مجرّد
  توظيف ماسك دفاتر ليوم واحد في الشهر.

التحوّلات السوقية المهمّة: تشدّدت متطلّبات تقارير VAT الإماراتية في
2026 (يرفع كلفة مسك الدفاتر "الكافي تقريبًا")؛ ومسرّعات الأعمال
الخليجية تدفع شركات محفظتها نحو أدوات الامتثال الافتراضي.

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

للمراقبة: إن شحن المنافس الإقليمي إعادة بناء عربية أصيلة حقيقية، يضيق
الوتد بسرعة — تلك هي الإشارة الوحيدة التي تستحقّ التتبّع كل ربع سنة.

codebase-map.md — ميزان (مقتطف)

البنية: app/ هو واجهة الويب المواجهة للعميل، وapi/ يتولّى الطلبات
ومنطق الفوترة، وdb/ طبقة البيانات، وbilling/ يضمّ تكامل Stripe ومسار
الفاتورة/التجديد — وهو الـ module الذي أعاد الفريق بناءه هذا الربع.

المسار المتتبَّع — تجديد خطة سنوية: 1. مهمّة مجدولة في
billing/renewals.ts تنطلق لكل اشتراك سنوي في تاريخ تجديده؛ 2. تستدعي
معالج Stripe webhook في billing/webhooks.ts لتحصيل وسيلة الدفع
المحفوظة؛ 3. عند النجاح، يُنشئ invoice.ts سجلّ الفاتورة. إن بدا أن
تجديدًا تكرّر مرّتين، ابدأ من billing/renewals.ts — فهي المهمّة التي
تُطلق التحصيل.

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

feature مرشّحة، محدَّد نطاقها: زرّ "الإبلاغ عن هذه الرسوم" المواجه
للعميل سيلمس مكوّن قائمة الفواتير في app/ ويحتاج جدول flagged_charges
جديدًا في db/، بالإضافة إلى route في api/ — صغير إلى متوسط، ولا يلمس
مهمّة التجديد نفسها. أستخدم هذا لتأطير المحادثة الهندسية، لا لكتابته
بنفسي.

ما الذي أثبتّه — وما التالي

اجتَز سُلّم التقييم وتكون قد أنجزت ما لا يستطيع المسار المجاني اعتماده: بنيت أساسًا حقيقيًّا بمستوى احترافي وأثبتّ الحُكم الكامن خلفه. تلك هي مرحلة الأساس من «Founders & PMs المعتمَدون مع Claude».

من هنا يحوّل المسار الأساس إلى عملية منتج عاملة، وتُقيَّم كل وحدة بالطريقة نفسها:

• الوحدة الثانية — من الفكرة إلى الـ prototype: اختبار طلب غامض تحت ضغط ليصير spec بإصدار أوّل، وبناء prototype قابل للنقر تقرّر به قبل أن يكتب أحد كودًا حقيقيًا.
• الوحدة الثالثة — من الإشارة إلى القرار: تجميع ملاحظات متناثرة في إشارة roadmap قابلة للدفاع عنها، وتحويل الخيارات إلى قرار تستطيع الدفاع عنه.
• الوحدة الرابعة — pipeline الـ roadmap: تشغيل النظام الأسبوعي لأصحاب المصلحة، وربط القوس كاملًا من الطلب إلى الجاهزية لـ roadmap.
• الوحدة الخامسة — التخطيط والمجلس: تشغيل تخطيط ربع سنوي بقائمة استبعاد حقيقية، ثم المشروع الختامي — Roadmap-in-a-Box، منظومة المنتج الكاملة من الأساس إلى الشهادة.

أولًا، اجعل ما بنيته قابلًا لإعادة الاستخدام. خُذ حقيبة أدوات الأساس — ملف CLAUDE.md الخاص بـ Founders & PMs والقوالب الثلاثة التي تحوّل الوثائق التي كتبتها للتوّ إلى ملفات يلصق منها فريقك كله من اليوم الأول. وإن كنت تطرح هذا عبر فريق، فإن دليل التشغيل هو طبقة القرار وأمان البيانات التي تستقرّ تحت كل ذلك.