مخطط الاختبار وجدول المواصفات: من المجال إلى صورة قابلة للدفاع

مخطط الاختبار Test Blueprint أو جدول المواصفات هو الجسر بين ما ندعي أن الاختبار يقيسه وبين البنود التي تظهر فعلًا في كل صورة. يحدد الغرض والسكان والمجال والمحتوى والمهارات والأوزان وأنواع المهام والطول والزمن والتسجيل والقيود وخصائص البناء، بحيث لا يصبح اختيار البنود تجميعًا عشوائيًا من بنك كبير. تعريف NCME لمواصفات الاختبار يشمل الغرض والاستخدام والمحتوى والشكل والطول والخصائص السيكومترية وطريقة التقديم والإدارة والتسجيل والتقرير. هذه الصفحة تقدم دورة بناء كاملة وقالبًا أصليًا للتوثيق، وتربط الـblueprint بصدق المحتوى والإنصاف والـstandard setting والـequating، من دون نشر مواصفات تشغيلية سرية أو مواد بنك اختبارات محمي.

الفرق بين Test Blueprint وTest Specifications

يستخدم المجال المصطلحين أحيانًا بالتبادل، لكن من المفيد عمليًا التمييز بينهما. Blueprint يمكن أن يشير إلى مصفوفة توزيع المحتوى والمهارات والأوزان وعدد البنود، بينما Test Specifications وثيقة أوسع تشمل الغرض والسكان والوقت وأنواع البنود وخصائصها وقواعد الشكل والتسجيل والإدارة والتقرير. في البرامج الصغيرة قد تجتمع كلها في ملف واحد، أما البرامج الكبيرة فهناك مواصفات مستوى الاختبار ومواصفات مستوى المهمة أو البند. الأهم هو ألا تتحول المصفوفة إلى جدول أرقام منفصل عن منطق البناء؛ كل خلية يجب أن ترتبط بادعاء أو مكون مجال ودليل مطلوب.

الـBlueprint ليس جدول حصص فقط

في الاختبارات الصفية قد يبدأ جدول المواصفات بتوزيع عدد البنود حسب وحدات المنهج ومستويات التفكير، وهذا مفيد، لكنه غير كافٍ في تقييمات عالية المخاطر أو معقدة. نحتاج تعريف task features، القيود، صيغ الاستجابة، زمن الأداء، متطلبات اللغة، القواعد الحسابية، ومتطلبات الإتاحة. الفصل السابع من Educational Measurement 2026 يعرض Principled Assessment Design بوصفه طريقة لدمج تعريف المجال وPerformance Level Descriptors وتصميم المهام وخصائص المقياس بدل إبقاء هذه المراحل منفصلة.

ابدأ ببيان الغرض والاستخدام

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

عرّف البناء والمجال قبل توزيع البنود

Domain Definition يحدد المعرفة والمهارات والعمليات التي تمثل البناء، وكذلك ما لا يدخل فيه. في اختبار قراءة مثلًا قد تكون سرعة فك الرموز جزءًا من البناء في عمر معين وغير مقصودة في اختبار فهم عال المستوى. في مقياس نفسي، اللغة المعقدة قد تصبح construct-irrelevant إذا كان البناء هو سمة انفعالية لا قدرة لغوية. يجب الاعتماد على نظرية ومعايير منهجية أو تحليل وظيفة وأدلة خبراء بحسب المجال. كلما كان المجال غامضًا، أصبح جدول الأوزان دقيقًا شكليًا لكنه غير صالح مفاهيميًا.

من Domain Analysis إلى Claims

يمكن تحويل المجال إلى Claims واضحة حول ما نستطيع استنتاجه من الأداء، ثم تحديد Evidence اللازم لإسناد كل claim، ثم أنواع Tasks القادرة على إظهار ذلك evidence. هذه الفكرة قريبة من evidence-centered أو principled design. فائدتها أنها تمنع كتابة بنود لمجرد سهولتها. إذا كان الادعاء يتطلب دمج معلومات متعددة، فإن مهمة تعرف بسيط قد لا توفر الدليل المطلوب حتى لو كان محتواها في الوحدة الصحيحة. يجب أن تعكس خلايا الـblueprint العلاقة بين المحتوى والعملية لا عنوان الدرس فقط.

الأوزان: كيف نقرر نسبة كل مجال؟

الوزن ليس بالضرورة نسبة ساعات التدريس. في اختبار تحصيل صفّي يمكن أن تكون ساعات التعليم أحد الأدلة، لكن أهمية الهدف وعمقه وتكراره ومتطلبات المنهج تدخل أيضًا. في اختبار مهني قد تأتي الأوزان من job analysis يطلب من ممارسين تقدير أهمية وتكرار المعرفة والمهارة. ETS يوثق استخدام لجان وخبراء ومسوح عمل لتأكيد المجالات قبل تطوير test specifications في بعض برامج الترخيص. يجب توثيق مصدر كل وزن، وعدم تعديل النسب بعد رؤية أداء البنود فقط لموازنة صعوبة الاختبار.

عدد البنود مقابل اتساع المجال

كل اختبار عينة محدودة من مجال أوسع. زيادة التغطية قد تقلل عدد البنود لكل مكون فتضعف دقة subscore، بينما زيادة البنود في مكون واحد قد تضيق تمثيل المجال. الـBlueprint هو مكان إدارة هذا التوتر. يجب تحديد الحد الأدنى من البنود اللازمة لكل claim ودقة القرار، ثم فحص زمن الاختبار والموارد. في الاختبارات القصيرة قد يكون من الأفضل عدم الإبلاغ عن subscore مستقل لمجال لا يملك عددًا كافيًا من البنود، حتى لو كان المجال ممثلًا بما يكفي لدعم الدرجة الكلية.

مستويات المعرفة والعمليات المعرفية

يمكن للـblueprint أن يوزع المهام على مستويات معرفة أو عمليات مثل تذكر وتطبيق وتحليل أو إطار Depth of Knowledge، لكن التصنيف يجب أن يعكس المتطلبات الفعلية للمهمة لا كلمات في stem. استخدام فعل «حلل» لا يجعل السؤال تحليليًا إذا كان الجواب يستدعي حقيقة محفوظة. الأفضل تعريف مؤشرات أداء لكل مستوى مع أمثلة أصلية داخل فريق التطوير وتدريب الكتاب على استخدامها. كما يجب تجنب فرض توزيع موحد على كل مجال إذا كانت طبيعة البناء تتطلب عمليات مختلفة.

صعوبة البند ليست هي العمق المعرفي

Item difficulty خاصية تجريبية أو متوقعة تتعلق بنسبة النجاح أو موقع البند على مقياس، بينما cognitive complexity تصف نوع المعالجة المطلوبة. بند تذكر في موضوع نادر قد يكون صعبًا، ومهمة تحليلية مألوفة قد تكون سهلة نسبيًا. الـBlueprint المتقدم يفصل بين البعدين ويحدد أهدافًا لكليهما عند الحاجة. هذا الفصل يمنع تصميم اختبار يبدو موزعًا معرفيًا لكنه ينتهي بدرجة صعوبة غير مناسبة أو العكس.

أنواع البنود والمهام

Selected response مناسب لبعض الأدلة، constructed response أو performance task مناسب لأدلة أخرى. اختيار النوع يتبع claim والعمليات المطلوبة وقيود الزمن والتسجيل والوصول، لا تفضيل تقني. يمكن للـblueprint تحديد نسبة أو عدد كل format وقواعد استخدامه. إذا كان item type يضيف عبئًا لغويًا أو حركيًا غير مقصود، يجب مراجعة construct representation. وفي الاختبارات الرقمية، التفاعل المعقد قد يقيس مهارة تقنية إلى جانب البناء. لذلك تُسجل خصائص الواجهة والأجهزة ضمن المواصفات عندما تؤثر في الاستجابة.

Task Features وDifficulty Drivers

Principled Assessment Design يشجع على تحديد خصائص المهمة التي نتوقع أن تغير الصعوبة أو نوع الدليل: عدد مصادر المعلومات، تجريد السياق، طول النص، تعدد الخطوات، وجود تمثيلات، أو درجة scaffolding. تسجيل هذه الخصائص يساعد item writers على إنتاج تنوع مقصود ويسمح بعد التجريب بفحص هل drivers تعمل كما توقع الفريق. إذا كانت خاصية لا علاقة لها بالبناء ترفع الصعوبة باستمرار، فقد تكون مصدر construct-irrelevant variance ينبغي تقليلها.

الزمن والسرعة في الـBlueprint

إذا كان الاختبار غير مقصود لقياس السرعة، يجب أن يوفر زمنًا يسمح لمعظم المفحوصين بإظهار البناء دون ضغط غير ضروري. المواصفات تسجل الوقت الكلي والوقت المتوقع حسب task type وسياسة الاستراحات. بعد field test يمكن فحص completion rates وrapid guessing والموقع التسلسلي للبنود. إذا ظهرت speededness في نهاية النموذج، لا يكفي حذف بضعة بنود عشوائيًا؛ قد نحتاج إعادة توزيع الأحمال أو تقليل زمن المهام الطويلة أو تعديل الطول.

التسجيل والـRubrics جزء من المواصفات

في المهام المفتوحة، لا يكتمل blueprint من دون scoring specification. يجب تحديد evidence الذي يبرر كل مستوى في rubric، عدد المصححين عند الحاجة، قواعد الحالات الحدية، التدريب، adjudication، وسياسة missing أو nonresponse. إذا كانت النقاط الجزئية تُجمع في scale score، يجب أن يكون وزنها متوافقًا مع البناء لا نتيجة اعتباطية لعدد خانات rubric. كما يجب تحليل inter-rater reliability وrater drift في الدراسة التجريبية.

لا تجعل الـRubric يوسع البناء دون قصد

قد تضيف rubric معايير أسلوب أو إملاء في مهمة يفترض أنها تقيس فهم العلوم، فتتحول الدرجة إلى خليط بناءات. كل criterion في rubric يجب أن يرتبط بالclaim المطلوب. إذا كانت جودة اللغة جزءًا مقصودًا، يذكر ذلك؛ وإذا لم تكن، فيجب منعها من التأثير غير المقصود. هذا مثال على كيف يحمي blueprint الصدق قبل أن يبدأ التحليل الإحصائي.

الإتاحة والإنصاف منذ التصميم

لا ينبغي انتظار مراجعة accessibility بعد بناء البنود. المواصفات تحدد مبكرًا متطلبات النص البديل والوسائط والتباين ودعم قارئ الشاشة واللغة والإرشادات والتسهيلات. الفصل الرابع عشر من Educational Measurement 2026 يضع الإتاحة ضمن الإنصاف وصلاحية تفسير الدرجات. إذا كان الاختبار سيستخدم مع متعلمي لغة أو أشخاص ذوي إعاقات، يجب فحص task features التي قد تضيف حواجز غير مرتبطة بالبناء، وتحديد أي accommodations تحفظ البناء وأي modifications تغيره.

اللغة والثقافة في المواصفات

في اختبار متعدد اللغات، يجب أن يحدد blueprint هل الصور تشترك في المحتوى والأوزان وأنواع المهام، وما متطلبات translation/adaptation. قد تحتاج الأمثلة والسياقات إلى cultural review، لكن التغيير يجب أن يحافظ على claim والصعوبة المستهدفة قدر الإمكان. لا يكفي ترجمة جدول المواصفات؛ يجب فحص equivalence في المهام والـrubrics والتعليمات. كما يمكن إضافة قواعد تمنع الاعتماد على معرفة ثقافية جانبية غير ضرورية للبناء.

تجميع صورة الاختبار من البنك

عندما يحتوي البنك على مئات البنود، يستخدم blueprint كقيود Assembly: عدد البنود بكل مجال ومستوى، targets للصعوبة أو information، توازن formats، منع تكرار موضوعات أو عائلات items، وقيود أمنية. يمكن للتجميع أن يكون يدويًا بمراجعة خبراء أو آليًا باستخدام optimization. أي طريقة تحتاج فحصًا نهائيًا لأن تحقيق القيود العددية لا يضمن coherence أو fairness. يجب أيضًا مراقبة exposure للبنود في الاختبارات المتكررة.

Alternate Forms تحتاج مواصفات مشتركة

لكي تكون الصور قابلة للمقارنة، يجب أن تحقق نفس construct representation بدرجة كافية. قد تختلف البنود لكن تغطية المحتوى والعمليات والـformats والدقة المستهدفة يجب أن تبقى ضمن tolerances واضحة. إذا تجاوزت صورة التوزيع المتفق عليه، قد يصعب تفسير فرق الأداء أو يتعقد equating. لذلك يحفظ النظام نسخة blueprint التي بنيت عليها كل form، لا ملفًا واحدًا متغيرًا بلا تاريخ.

Field Testing: اختبر الفرضيات لا البنود فقط

الدراسة التجريبية لا تهدف فقط إلى حساب صعوبة وتمييز. يجب فحص تمثيل المجال، completion، عمل task features، DIF، factor structure، scoring، rater effects، والوقت. يمكن أن تكشف البيانات أن خلية في blueprint تنتج بنودًا أسهل بكثير أو أن format معين يخلق construct-irrelevant variance. عندها نراجع المواصفات أو كتابة البنود وفق حجة، لا نطارد خصائص إحصائية مستقلة عن المحتوى.

مراجعة Content Validity

خبراء المحتوى يمكنهم تقييم relevance وrepresentativeness وalignment بين البنود والمجال. قد تستخدم مؤشرات كمية مثل CVI أو قواعد panel rating كأدلة مساعدة، لكنها لا تحل محل جودة تعريف المجال وتنوع الخبراء. يجب تسجيل تضارب المصالح، الخبرة، التدريب، وقاعدة اتخاذ القرار. وعندما تكون الأداة مهنية، يمكن job analysis أو survey واسع دعم الأوزان وتأكيد أن المعرفة والمهارات مهمة للممارسة المستهدفة.

الـBlueprint وStandard Setting

Performance Level Descriptors ينبغي أن ترتبط بالمحتوى والمهارات التي يختبرها النموذج، لأن standard-setting panel سيحكم على أداء حول الحدود بناءً على هذه المواصفات. إذا كان blueprint لا يمثل المجال أو مستويات التعقيد، فإن cut score الجيد إجرائيًا لن يصلح مشكلة content underrepresentation. لذلك من المنطقي أن يراجع خبراء standard setting مواصفات الاختبار وPLDs ويؤكدوا صلتها بالقرار قبل الحكم على البنود.

الـBlueprint وScaling وEquating

ثبات التغطية عبر الصور يساعد في إنشاء درجات قابلة للتفسير والحفاظ عليها. Equating لا يجعل صورتين مختلفتين جذريًا في البناء متكافئتين؛ يفترض قدرًا من interchangeability. إذا تغير blueprint بسبب منهج جديد أو job analysis جديد، قد يكون التغيير أكبر من تحديث form عادي ويحتاج transition study أو linking لا equating بسيط. يجب أن توثق governance متى يعد التغيير minor ومتى ينشئ إصدارًا جديدًا للاختبار.

مراجعة الـBlueprint دوريًا

المجالات تتغير. منهج دراسي يتحدث، مهنة تدخل تقنية جديدة، أو أدلة علمية تغير تعريف البناء. ETS يصف في بعض برامج Praxis مراجعة المواصفات عبر خبراء ومسوح عندما تصبح المعايير المهنية غير متطابقة مع الاختبار. لذلك يجب أن يكون للـblueprint owner وتاريخ إصدار ومؤشرات trigger للمراجعة. تحديث البنود وحدها لا يكفي إذا كان الإطار نفسه قديمًا.

Version Control ليس تفصيلًا إداريًا

كل form يجب أن يرتبط بإصدار blueprint، item specifications، scoring rules، وPLDs. إذا تغير وزن مجال من 20% إلى 30%، يجب أن يعرف المحلل أي forms قبل وبعد التغيير. يساعد ذلك في تفسير drift وفي قرارات equating وتحديث التقارير. نظام الملفات الذي يسمي كل نسخة «final_v3_new» غير كافٍ؛ نحتاج معرف إصدار وتاريخ وسبب تغيير وموافقات.

قالب أصلي لمخطط اختبار قابل للطباعة

يمكن إنشاء ورقة عمل أصلية بهذه الحقول: اسم الاختبار وإصداره؛ الغرض؛ السكان؛ القرارات؛ البناء والمجالات؛ claims؛ evidence المطلوب؛ عدد البنود أو النقاط لكل مجال؛ مستوى العملية المعرفية؛ item type؛ الزمن المستهدف؛ الصعوبة أو information target؛ scoring rule؛ accessibility constraints؛ اللغة/الثقافة؛ security/exposure constraints؛ subscore intent؛ مصدر الوزن؛ reviewer؛ تاريخ آخر مراجعة. لكل صف خانة «مبرر» وخانة «دليل بعد field test». هذا القالب لا يحتوي أي مادة اختبار ولا يحل محل مواصفات ناشر.

مصفوفة التغطية الأصلية

للمورد العملي يمكن بناء مصفوفة صفوفها المجالات وأعمدتها العمليات أو claims. داخل كل خلية نسجل target number of items، min/max tolerance، format، وأولوية. أسفل الجدول تُحسب المجاميع وتفحص أنها تساوي طول النموذج. يمكن إضافة عمود actual بعد assembly لمقارنة المخطط بالتنفيذ. إذا كانت الخلية صفرًا عمدًا، يسجل السبب حتى لا يتحول النقص إلى سهو. هذه المصفوفة مفيدة للمراجعة والطباعة ولا تتضمن بنودًا أو إجابات.

اختبار جودة الـBlueprint

قبل الاعتماد، اطلب من فريق مستقل نسبيًا الإجابة: هل يمكنهم معرفة ما يقيسه الاختبار وما لا يقيسه؟ هل الأوزان مبررة؟ هل كل claim لديه evidence task؟ هل يوجد مجال بلا تغطية أو format يهيمن لأنه أسهل في الإنتاج؟ هل الوقت والإتاحة معقولان؟ هل reporting intent متوافق مع عدد البنود؟ هل alternate forms يمكن بناؤها من البنك؟ هل توجد خصائص قد تسبب DIF؟ ثم جرّب بناء form تجريبي؛ إذا فشل assembly باستمرار فالمواصفات ربما غير قابلة للتنفيذ.

أخطاء شائعة

من الأخطاء: نسخ أوزان اختبار قديم من دون مراجعة المجال، مساواة زمن التدريس بأهمية الهدف آليًا، وصف cognitive level بالكلمات فقط، ترك accessibility للنهاية، الإبلاغ عن subscores لمجالات قليلة البنود، بناء forms تتجاوز tolerances، تعديل الأوزان لتناسب البنود المتاحة، وعدم حفظ الإصدارات. خطأ آخر هو نشر blueprint تشغيلي شديد التفصيل إذا كان يكشف أمن الاختبار؛ يمكن نشر إطار عام للمحتوى مع حفظ constraints الأمنية داخليًا.

حقوق الاختبار وأمن المواصفات

مفاهيم blueprint عامة، لكن مواصفات بنك اختبارات تجاري قد تكون محمية أو حساسة أمنيًا. لا تعيد روافد نشر عدد البنود السري في مجالات دقيقة أو قواعد assembly تكشف bank structure إذا لم تكن معلنة. يمكن شرح المنهج بقالب أصلي ومثال اصطناعي. الحقوق والأمن يجب أن يراجعا قبل نشر أي test specifications من ناشر خارجي، تمامًا كما تراجع حقوق البنود والمفاتيح.

مثال اصطناعي

لنفترض اختبار علوم أصليًا من 40 بندًا يقيس أربعة مجالات وعمليتين معرفيتين. يقرر الفريق 10 بنود لكل مجال، لكن التحليل النظري يظهر أن مجال الاستقصاء يحتاج مهام تطبيق أكثر، فتعدل المصفوفة إلى توزيع غير متساوٍ عبر العمليات مع بقاء مجموع المجال ثابتًا. بعد field test يتبين أن format تفاعلي واحد يسبب وقتًا زائدًا ودلالة DIF لدى مستخدمي تقنية مساعدة. لا يحذف المجال؛ يعاد تصميم task feature وإتاحة format ثم يعاد التجريب. المثال يوضح أن blueprint وثيقة حية مرتبطة بالبيانات لا جدولًا ثابتًا.

العلاقة مع صفحات القياس الأخرى

Validity تضع الحجة الكبرى، blueprint يترجم البناء إلى عينة مهام، item analysis يفحص أداء البنود، factor analysis وIRT يختبران بنية وأداء القياس، DIF وinvariance يفحصان المقارنة والإنصاف، standard setting يربط الأداء بمستويات، وscore reporting ينقل النتائج. إذا غاب blueprint تصبح هذه التحليلات لاحقة لمحاولة إصلاح اختبار لم يُعرف منذ البداية ما الذي يفترض أن يغطيه. لذلك هو وثيقة مركزية تربط المحتوى بالسيكومتريا.

الخلاصة

Test Blueprint الجيد يحدد الغرض والبناء والسكان والclaims والأدلة، ثم يوزع المحتوى والعمليات والمهام والزمن والتسجيل والدقة والإتاحة ضمن قيود قابلة للبناء والمراجعة. بعد field test يعود الفريق إلى الفرضيات ويعدل المواصفات بالإدلة، ويحفظ كل إصدار. بهذه الدورة يصبح جدول المواصفات جزءًا من validity argument ومراقبة الجودة، لا جدول أرقام يملأ بعد كتابة الأسئلة.

أسئلة شائعة

الخصائص السيكومترية المستهدفة في المواصفات

المواصفات المتقدمة لا تحدد المحتوى فقط، بل تسجل أهدافًا سيكومترية يمكن التحقق منها بعد التجريب، مثل نطاق صعوبة معقول، مقدار information قرب نقاط القرار، حدود speededness، متطلبات reliability للدرجة الكلية، وأي هدف للتصنيف. هذه الأهداف ليست وعودًا قبل وجود بيانات؛ هي فرضيات تصميم تقود بناء البنك وتساعد في تفسير نتائج field testing. إذا كان الاختبار سيستخدم عند cut score محدد، قد يحتاج البنك كثافة من البنود ذات معلومات جيدة حول ذلك المستوى بدل توزيع الصعوبة بالتساوي على المقياس. وإذا كان الهدف قياس النمو عبر مدى واسع، قد نحتاج تغطية أوسع. يجب ألا يُحسن الفريق مؤشرًا واحدًا على حساب construct representation؛ test information ممتازة في مجال ضيق لا تعوض غياب جزء مهم من المحتوى.

مراجعة قابلية إعادة بناء الصورة

اختبار عملي قوي للـblueprint هو محاولة فريق آخر بناء form منه من دون الاعتماد على معرفة شفوية غير مكتوبة. يجب أن يستطيع تحديد عدد البنود، tolerances، قواعد اختيار المحتوى والعمليات، أنواع المهام، قيود العائلات، خصائص scoring، ومتطلبات الوصول. بعد assembly تقارن الصورة الفعلية بالمخطط في تقرير deviation: أي خلية خرجت عن target؟ هل كان السبب نقص بنك أم تعارض قيود أم قرار خبراء؟ هل يؤثر الانحراف في validity أو equating؟ إذا احتاج الفريق إلى تجاوز متكرر، فالخلل قد يكون في حجم البنك أو في المواصفات نفسها. هذا النوع من audit يجعل الوثيقة قابلة للتشغيل لا وصفًا نظريًا.

حوكمة التغييرات والموافقات

كل تغيير جوهري في blueprint يجب أن يحمل owner وسببًا ودليلًا وتاريخ سريان. يمكن تصنيف التغييرات إلى تحريرية لا تغير البناء، تشغيلية مثل tolerance صغير، وتغييرات construct أو weights قد تنشئ إصدارًا جديدًا. قبل الاعتماد يراجع المحتوى والسيكومتريا والإتاحة والتسجيل والأمن أثر التغيير. إذا كانت النتائج السابقة ستظل تقارن بالجديدة، يجب إشراك فريق scaling/equating مبكرًا. كما يحتاج score reporting إلى معرفة أي labels أو مستويات تغيرت. هذه الحوكمة تمنع أن يتطور الاختبار تدريجيًا بعيدًا عن الحجة الأصلية من خلال تعديلات صغيرة لا يراها أحد مجتمعة.