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

بين يدي فريقك الآن playbooks الـ query-and-learn والـ clean-and-join — وصفتان مفصّلتان: الأولى تشرح لك query بندًا بندًا حتى تستطيع الدفاع عنه، والثانية تجمع ملفّين فوضويين في مجموعة بيانات واحدة دون أن يختفي صف. كلٌّ منهما حركة جيدة، تُؤدَّى مرة واحدة، على ملف واحد. هذه الوحدة هي الطبقة التي تحوّل الحركتين المنفصلتين إلى محرّك تشغيلي: ‏queries تُردّ إلى رقم يثق به فريقك أصلًا، وعمليات دمج تثبت — حتى آخر صفٍّ وآخر درهم — أن شيئًا لم يضِع بين الملفات الخام والتقرير.

هذه هي الوحدة الثانية من مسار البيانات والمحلّلين المعتمَد، وهي ترث كل ما بنيته في الوحدة الأولى. ملفّاك dataset-profile.md وmetrics.md ليسا قراءة خلفية هنا — إنهما العقد الذي تُحاسَب عليه queries هذه الوحدة: كل شرط WHERE ينبغي أن يطابق تعريفًا دوّنته من قبل، لا تعريفًا أُعيد اختراعه في منتصف الكتابة. الوحدة الأولى أتقنت ماذا تحتوي بياناتك وماذا تعني أرقامك؛ والثانية تبني فوق ذلك الأساس المحرّكَ الذي يجيب عن طلبات حقيقية — وتقيّم المحرّك، لا إجابة واحدة أصابت بالحظ.

الـ query ليس مجرد جواب — إنه ادّعاء. «العملاء النشطون حسب فئة الخطة: 9,240» جملةٌ يردّدها أحدهم في اجتماع قيادة دون أن يعيد قراءة الـ SQL الذي وراءها. الـ playbooks المجانية تعلّمك أن تكتب query تشرحه وjoin تثق به مرة واحدة. هذه الوحدة هي حيث يصير ذلك المعيارَ الذي يبلغه كل query، في كل مرة — لأن صاحب الطلب لا يميّز الرقم المتين من الرقم المحظوظ، وليس ذلك من شغله أصلًا.

المحرّك، لا الـ query اليتيم

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

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

• الاستعلام — ثبّت السؤال الفضفاض، واكتب الـ SQL، وامشِ على كل بند بلغة واضحة، وطابِق النتيجة مع رقم يثق به metrics.md (أو مصدر ثانٍ) أصلًا.
• الدمج — حين يحتاج الجواب إلى ملفّين، وحّد المفاتيح، وادمج على المعرّف الصحيح، وأظهر كل صف لم يجد نظيره، وطابِق الإجمالي المدموج رجوعًا مع المدخلَين كليهما قبل أن يبني أحد تقريرًا عليه.

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

الحركتان كلتاهما تجريان في المحادثة. افتح مجلد بياناتك في Claude Desktop، ووافق على كل قراءة من نافذة Ask permissions، واعمل حركةً حركة — لا حاجة إلى terminal على المسار الرئيسي.

الاستعلام — رقم يستطيع غريبٌ تدقيقه

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

• التعريف يأتي من metrics.md، لا من الذاكرة. إن كان للمؤشر تعريف قائم، فشرط WHERE في الـ query ينبغي أن يكون ذلك التعريف بنصّه، لا تخمينًا جديدًا لمعنى ‘active’ هذه المرة. الـ query الذي يعيد اختراع تعريف حسمه metrics.md أصلًا هو بالضبط كيف يخرج محلّلان برقمين للمؤشر الواحد — عين الانزلاق الذي وُجدت الوحدة الأولى لمنعه.
• امشِ على البند، لا تلصقه فحسب. إن عجز مراجعٌ عن إعادة إنتاج ما يفعله مرشِّح WHERE أو GROUP BY من شرحك وحده، فالـ query لم يُشرح بعد — إنما كُتب. لغة واضحة، سطر لكل بند، على افتراض أن القارئ ليس خبير SQL.
• طابِق مع رقم يثق به الناس أصلًا — لا مع الـ query نفسه. الـ query الذي لا يفحص إلا مجموعه الفرعي لم يثبت شيئًا. اربط النتيجة برقم metrics.md، أو بتقرير سابق، أو بإجمالي حُسب استقلالًا، وقل صراحةً بمَ قارنت وهل تطابقا. هذه هي بوابة RECONCILE، وليست قابلة للتفاوض قبل أن تغادر نتيجةٌ المحادثةَ.
• وصّف العمود الجديد قبل أن تأتمنه في شرط WHERE. حتى داخل ملف وصّفته الوحدة الأولى، قد يجرّ طلبٌ جديد عمودًا لم ينظر فيه أحد بعد — جدول مختلف، أو بُعد جديد. اقرأ قيمًا فعلية قبل أن ترشّح عليه. قاعدة PROFILE FIRST تسري في كل مرة يلمس فيها query شيئًا غير موصوف، لا في اليوم الأول فقط.

الدمج — إثبات أنه ما أضاع صفًّا ولا درهمًا

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

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

ملاحظة على البيانات العربية

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

تكليفك

ابنِ محرّك الاستعلام والدمج لـطلب حقيقي واحد — على بياناتك أنت (وهذا ما ننصح به: الناتج query ومجموعة بيانات يعيد فريقك استخدامهما فعلًا)، أو على العلامة النموذجية «ميزان»، أداة مسك الدفاتر SaaS الخليجية التي ترافقك محلّلة أعمالها مايا حدّاد في المسار كله. كل شيء هنا يرث ملفات أساس الوحدة الأولى؛ إن لم يكن عندك dataset-profile.md وmetrics.md بعد، فأنجِز الوحدة الأولى أولًا. افتح مجلد بياناتك في Claude Desktop، ووافق على كل قراءة من نافذة Ask permissions، واعمل داخل المحادثة — لا حاجة إلى terminal.

ناتج الوحدة الثانية — محرّك الاستعلام والدمج

يرث من الوحدة الأولى: dataset-profile.md + metrics.md

1. query.sql + walkthrough.md   (ناتج حركة الاستعلام)
   - السؤال الدقيق، وكل مصطلح فضفاض مثبَّت قبل أي SQL — مع
     الاستشهاد بمنطق metrics.md الحرفي لأي مؤشر معرَّف أصلًا
   - الـ query، وفوق كل بند تعليق من سطر واحد
   - شرح بلغة واضحة يستطيع قارئ لا يعرف SQL أن يتبعه ويتحقق به
   - المطابقة: النتيجة تُردّ إلى رقم من metrics.md أو من مصدر
     ثانٍ — سمِّ المصدر وصرّح بالتطابق (أو بالفجوة، محقَّقة
     ومفسَّرة، لا مُلوَّحًا بها بعيدًا)

2. joined-dataset.csv + join-notes.md   (ناتج حركة الدمج)
   - توحيد المفاتيح معروضًا: 5 أمثلة قبل/بعد، مع تعليم كل قيمة
     تصير فارغة أو تتصادم بعد التنظيف
   - عمود match_status على كل صف (matched / orphan / no_match)
   - المطابقة: المتطابق + اليتيم يساوي عدد صفوف الملف الذي دمجت
     عليه؛ وإجمالي مالي أو عددي يتساوى بين المدخل الخام والناتج
     المدموج
   - كل تطابق ملتبس (الكيان نفسه بمعرّفين؛ تكرار مرجّح) معلَّم
     «يحتاج مراجعة» — لا مدموج بصمت أبدًا

البيانات الشخصية: الأعمدة الحاملة للهوية — أسماء الأفراد والبريد
والبيانات المرتبطة بشخص واحد — تبقى في مساحة العمل. ما تسلّمه هو
الـ SQL والشرح والملف المدموج والأعداد المطابَقة — لا تصديرًا خامًا.

وحقيبة أدوات الأساس تضم قالبَي metrics.md وdataset-profile.md اللذين تُبنى queries هذه الوحدة وعمليات دمجها فوقهما مباشرة.

كيف يجري التقييم — المعايير

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

معايير تقييم محرّك الاستعلام والدمج

1. الـ query يُطابَق مع رقم قائم أصلًا
   النتيجة تُردّ إلى رقم metrics.md أو إلى مصدر ثانٍ مسمّى — لا إلى
   مجموعها الفرعي فحسب. الفجوة تُحقَّق وتُفسَّر، ولا تُقبل بصمت
   ولا تُقرَّب حتى تختفي.
2. الشرح حقيقي، لا إعادة صياغة
   قارئ لا يعرف SQL يستطيع إعادة إنتاج ما يفعله كل بند من الشرح
   وحده — مرشِّح WHERE، وGROUP BY، وأي منطق تواريخ، لكلٍّ سطر
   واضح، لا لمحة من كلمة واحدة.
3. كل مفتاح دمج وُحّد وعُرض، لا افتُرض
   أمثلة قبل/بعد تثبت أن التحويل لم يشوّه قيمة حقيقية. وكل مفتاح
   يصير فارغًا أو يتصادم بعد التنظيف مسمًّى، لا مُسقطًا بصمت.
4. الصفوف التي بلا نظير مكشوفة، لا مخفية
   الصفوف اليتيمة وصفوف اللاتطابق مسرودتان بأعداد متحقَّق منها.
   المتطابق + اليتيم يساوي عدد صفوف الملف حامل عمود match_status —
   بالضبط، لا تقريبًا.
5. الإجماليان يتطابقان، والملتبس معلَّم
   عدد الصفوف وإجمالي مالي أو كمّي كلاهما يتساوى بين المدخل
   والناتج المدموج. وكل حالة ملتبسة (معرّفان، تكرار مرجّح) سطرُ
   «يحتاج مراجعة» — لا خيارًا افتراضيًا اختاره Claude، ولا خيارًا
   اتخذه المحلّل وحده دون تسميته.

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

المستوى المطلوب، معروضًا — نموذج إجابة (ميزان)

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

active-customers-by-plan.sql + walkthrough.md
(مايا حدّاد، للوحة متابعة الـ churn التي طلبتها نادية السيّد — جانب
المقام «العملاء النشطون» من brief الوحدة الأولى؛ أما تفصيلة الدول
للّوحة نفسها فتدمج هذا مع جدول العملاء — النصف الآخر من هذه الوحدة.)

السؤال، مثبَّتًا قبل أي SQL: «العملاء النشطون حسب الخطة، عن آخر 6
أشهر.» النشط يعني منطق metrics.md الحرفي (status = 'active' AND
plan != 'trial'). وآخر 6 أشهر تعني أكتوبر 2025 حتى مارس 2026،
لقطةً في آخر يوم من كل شهر — على الطريقة التي يُقاس بها MRR أصلًا،
كي يبقى المؤشران قابلَين للمقارنة شهرًا بشهر.

SELECT
  DATE_TRUNC('month', snapshot_date)::date AS month,  -- one row per month
  plan,                                                -- one row per plan
  COUNT(DISTINCT account_id) AS active_customers       -- accounts, not rows
FROM subscription_monthly_snapshots                    -- the history table;
                                                         -- see note below
WHERE status = 'active'                                -- metrics.md's exact
  AND plan <> 'trial'                                  -- Active Customers logic
  AND snapshot_date IN ('2025-10-31','2025-11-30','2025-12-31',
                         '2026-01-31','2026-02-28','2026-03-31')
GROUP BY 1, 2
ORDER BY 1, 2;

الشرح:
  WHERE status = 'active' AND plan <> 'trial' — منطق «العملاء
    النشطين» في metrics.md بنصّه، لا مرشِّح معاد اختراعه. التجربة
    النشيطة الاستخدام ليست عميلًا بعد، مهما بدا نشاطها.
  subscription_monthly_snapshots لا subscriptions — التقاطة
    PROFILE FIRST: جدول subscriptions الحيّ الذي يستعلم منه منطق
    metrics.md اللحظي يحمل حالة اليوم فقط، بلا تاريخ. هذا جدول
    منفصل يملؤه المستودع في آخر كل شهر خصيصًا لاستعلامات الاتجاه
    مثل هذا — المنطق التجاري نفسه، بجدول مختلف، لأن الاتجاه يحتاج
    تاريخًا لا يحفظه الجدول الحيّ. وُصّف قبل ائتمانه: الأعمدة نفسها،
    والتعريفات نفسها، وصف لقطة واحد لكل حساب في آخر كل شهر.
  snapshot_date IN (ستة تواريخ صريحة) — لا نطاق BETWEEN، لأن هذا
    الجدول يحمل صفًّا لكل حساب في كل يوم؛ والنطاق كان سيعدّ كل يوم
    في النافذة، لا لقطات آخر الشهر الست التي يعتمدها metrics.md
    لـ«نشط كما في».
  GROUP BY month, plan — صف لكل خطة في كل شهر، فالحساب الذي رقّى
    خطته في منتصف الفترة يظهر مرة في كل شهر، تحت الخطة السارية في
    تاريخ لقطة ذلك الشهر — ولا يُعدّ تحت الخطتين أبدًا.
  COUNT(DISTINCT account_id) — يعدّ كل حساب مرة واحدة ولو حمل أكثر
    من سطر اشتراك (إضافة مقعد مثلًا)، مطابقًا تعريف العملاء النشطين
    كحسابات، لا كسطور بنود.

النتيجة (آخر 6 أشهر):
  month        starter   pro    business   total
  2025-10-31     5,580   2,520      610     8,710
  2025-11-30     5,650   2,560      620     8,830
  2025-12-31     5,730   2,600      630     8,960
  2026-01-31     5,790   2,620      640     9,050
  2026-02-28     5,850   2,640      660     9,150
  2026-03-31     5,920   2,650      670     9,240

المطابقة: إجمالي مارس 9,240 يطابق رقم العملاء النشطين الذي يبلّغه
metrics.md للشهر نفسه — المنطق ذاته، معاد حسابه استقلالًا من جدول
اللقطات التاريخي بدل الجدول الحيّ الذي يقرأ منه الملخص عادة.
اتفاق المصدرين هو نفسه فحص.

اختبار الضغط: حساب رقّى من Starter إلى Pro في منتصف مارس يظهر مرة
واحدة، تحت Pro، في لقطة 3/31 — لا معدودًا مرتين على الخطتين،
مطابقًا الحالة الحدّية المنصوصة في metrics.md لتغييرات الخطة في
منتصف الفترة («يُحسب مرة واحدة، على الخطة الجديدة»).

join-notes.md — customers.csv + orders.csv
(مايا حدّاد، لفحص يوسف حمدان التقاطعي بين الذمم المدينة والإيراد،
الربع الأول 2026)

الملفات، خامًا:
  customers.csv   9,640 صفًّا، 9,640 قيمة مميزة لـ customer_id
                  (الصيغة: "MZ-00482" — ببادئة وأصفار حشو)
  orders.csv      28,460 صفًّا (سطور فواتير الذمم، يناير-مارس 2026)،
                  9,510 قيمة مميزة لـ account_id
                  (الصيغة: "482" — أرقام مجردة، بلا بادئة ولا حشو)
تقدير التقاطع قبل التنظيف: نحو 9,400 من حسابات جانب الطلبات
الـ 9,510 تبدو مرشحة لمطابقة صف عميل متى اتّحدت الصيغتان.

توحيد المفاتيح (5 من التحويلات، قبل/بعد):
  MZ-00482  -> 482     حذف بادئة "MZ-" والأصفار البادئة
  MZ-00071  -> 71      القاعدة نفسها
  MZ-09003  -> 9003    القاعدة نفسها
  mz-00482  -> 482     صفّان يستخدمان "mz-" الصغيرة — طُبّعا
                        بالطريقة نفسها؛ عُلّما ليوسف بوصفهما أثر
                        مسارَي إدخال في الـ CRM على الأرجح، ولم
                        يُمَسّا هنا بأكثر من ذلك
  MZ-00000  -> فارغ    4 صفوف؛ حسابات اختبار متروكة من ترحيل
                        الفوترة في 2025 — استُبعدت من الدمج، ولم
                        تُبقَ بصمت كعميل حقيقي

التقاطع الفعلي بعد التوحيد: 9,450 حسابًا مميزًا يتطابق (بزيادة 60
على تقدير ما قبل التنظيف — كانت مخفيّة خلف حالة الأحرف والحشو).

الدمج: LEFT JOIN للطلبات على العملاء بالمفتاح الموحَّد، صف لكل
طلب، وmatch_status على كل صف.
  صفوف الطلبات المتطابقة:            28,210
  صفوف الطلبات اليتيمة (بلا نظير):      250  -> تعود إلى 60 قيمة
                                              مميزة لـ account_id؛
                                              انظر العلامة 1 أدناه
  عملاء بلا طلبات هذا الربع:            190  (حسابات موقوفة أو
                                            محوَّلة من تجربة لم
                                            تُفوتَر بعد — متوقَّع،
                                            لا عيب)

المطابقة:
  الصفوف:   28,210 متطابقًا + 250 يتيمًا = 28,460 — يساوي orders.csv
            بالضبط.
  الحسابات: 9,450 متطابقًا + 60 يتيمًا = 9,510 — يساوي عدد
            account_id المميز في orders.csv بالضبط.
  المبالغ:  sum(order_amount) في orders.csv         = AED 1,498,650.00
            sum(order_amount) في joined-dataset.csv = AED 1,498,650.00
            متساويان حتى الفلس. لا مبلغ طلب أُسقط أو تكرر.

العلامات — تحتاج مراجعة، ولا تُدمج آليًا أبدًا:
  1. نجد للخدمات اللوجستية (customer_id MZ-00482) — ‏64 من الصفوف
     اليتيمة الـ 250 تجلس تحت account_id 1188، معرّف فوترة قديم
     من قبل ترحيل الـ CRM في 2025 لم يُعَد ربطه قط. لولا هذه
     العلامة لقُرئ 64 طلبًا لعميل حقيقي قائم على أنها «يتيمة».
     أُحيلت إلى يوسف للتأكيد قبل إعادة الربط — فالدمج يغيّر أي
     فئة تقادم ذمم تُحسب عليها تلك الفواتير الـ 64.
  2. الحصن للتجارة — صفّان في customers.csv: ‏MZ-03114
     ‏("ops@alhosntrading.ae") وMZ-03212 ("Ops@AlHosnTrading.ae") —
     الشركة نفسها، والنطاق نفسه، بحالة أحرف مختلفة، أدخلهما مندوبا
     مبيعات بفارق ثمانية أشهر. كلاهما طابق طلباته صحيحًا، فالدمج
     غير معطوب — لكنهما أُبقيا صفّين منفصلين وعُلّما بدل أن يُدمجا.
     دمج شبه التكرار آليًا على تطابق اسم هو بالضبط القرار الذي
     تحجزه الوحدة الأولى لإنسان؛ والدمج في الاتجاه الخطأ كان
     سيُنقص رصيد ذمم أحد المعرّفين في الفحص التقاطعي.

joined-dataset.csv — مقتطف (5 من 28,650 صفًّا: 28,460 صف طلب
[متطابق + يتيم] زائد 190 صف عميل بلا طلبات؛ الترويسة + البيانات)
  customer_id,company,order_id,order_amount,order_date,match_status
  482,Najd Logistics,ORD-55012,4250.00,2026-01-14,matched
  ,UNMATCHED-1188,ORD-44210,3100.00,2025-09-02,orphan [see flag 1]
  3114,Al Hosn Trading,ORD-56210,9800.00,2026-03-02,matched [see flag 2]
  3212,Al Hosn Trading,ORD-56344,2100.00,2026-03-09,matched [see flag 2]
  7780,,,,,no_orders

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

باجتيازك هذه المعايير تكون قد أثبتّ ما لا تستطيع الـ playbooks المجانية وحدها أن تشهد لك به: أنك تحوّل طلب الإدارة الفضفاض إلى query يستطيع غريب تدقيقه، وملفّين فوضويين إلى مجموعة بيانات مطابَقة حتى آخر صفٍّ وآخر درهم. هذه هي مرحلة محرّك الاستعلام والدمج من اعتماد «البيانات والتحليل مع Claude».

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

• الوحدة 3 — الجودة والسبب الجذري: تدقيق مجموعة بيانات قبل أن تُغذّي ما له وزن، ومعرفة سبب تحرّك رقم دون تخمين.
• الوحدة 4 — التجارب والرسوم البيانية: قراءة اختبار A/B بصدق تحت ضغط الإطلاق، وتحويل ملف CSV إلى رسم يصمد أمام نظرة ثانية.
• الوحدة 5 — منظومة التقارير: بناء التقرير الدوري الذي يخرج بالطريقة نفسها كل شهر، ثم المشروع الختامي — «الرؤية الجاهزة» (Insight-in-a-Box)، التحقيق الكامل من ملف التصدير الخام إلى الشهادة.

لكن أولًا، اجعل هذا قابلًا لإعادة الاستخدام: ملف الـ .sql المعلَّق وقواعد التوحيد التي وراء الدمج هما الأثران الدائمان. احفظ الـ query بوصفه prompt محفوظًا أو أمرًا مخصصًا على شاكلة /mau، وقواعد التنظيف بوصفها skill باسم /merge (انظر تنويعة مسار الـ Power Track في الـ playbooks)، فتجري نسخةُ الشهر القادم بالطريقة نفسها دون إعادة اشتقاقها. وإن كنت تنشر هذا على مستوى فريق، فـدليل التشغيل هو طبقة أمان البيانات والتحقق التي تقوم المنظومة كلها عليها.