قرارات الاستجابة للتدخل والمستويات

محرك RTI هو طبقة القرار المركزية. المسارات منشورة تحت وسم rti في مرجع واجهة برمجة التطبيقات، ومتتبّع الإخلاص وغرفة البيانات اللذان يعتمد عليهما مشحونان وموصولان الآن. يعمل بخطين مستقلين:

• خط أنابيب A (التنبيهات) يُقيّم صورة الأدلة الكاملة لكل طالب ويرفع إشارة مرئية للمعلم عند وجود ما يستوجب الانتباه.
• خط أنابيب B (حركة المستوى) يدير العملية الرسمية لتغيير مستوى دعم الطالب عبر تسلسل مراجعة-توصية-قرار.

المعلم، وللدعم عالي الكثافة متخصص، يوافق على كل تغيير جوهري. المحرك يقترح؛ البشر يقررون.

المُوقِف: do_not_decide_yet

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

• أعاد محرك حالة المهارة do_not_decide_yet لأدلة الطالب
• يُظهر نطاق partial_domain للحالة
• ملف الطالب الشخصي هو PR2-00 DATA_INCOMPLETE
• لدى محرك المراقبة حكم إيقاف
• لدى CBM insufficient_points

لا يمكن تجاوز المُوقِف بأي دور أو رمز تجاوز (403 إذا جُرِّب).

تسليم طلاقة CBM

تُصدر وحدة CBM إشارة CbmTrendSignal خام؛ يقرأ قارئ مدخلات RTI أحدثها لكل طالب (prismaCbmTrendReader، مُحدَّد بالمؤسسة) ويُحوّلها إلى خط أنابيب التنبيهات. هذا هو التوصيل الحي بين مراقبة الطلاقة وطبقة قرار RTI:

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

خط أنابيب A: تنبيهات الطبقة A والطبقة B

الطبقة A تُقيّم حالة كل مهارة مقابل 3 حالات وتُنتج إشارة وسيطة.

الطبقة B تُجمّع عبر المهارات وتُصدر إحدى ثلاثة أنواع تنبيه:

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

مستوى RTI

لكل طالب student_tier_status يحمل currentRtiTier. القيم الثلاث داخلية ولا تُعرض للطلاب أو أولياء الأمور قط:

خط أنابيب B: تدفق حركة المستوى

تتبع تغييرات المستوى بروتوكولاً من ثلاث خطوات:

1. الفتح POST /api/tier-review-requests: يفتح TierReviewRequest رسمياً ويربط decision_packet (حزمة الأدلة المستخدمة لدعم القضية).
2. التوصية POST /api/tier-review-requests/:id/recommendation: يحسب المحرك حكم TM_* الحتمي (قراءة فحسب، بدون كتابة). هذا هو اقتراح المحرك.
3. القرار POST /api/tier-review-requests/:id/decision: المعلم (أو المتخصص لـ TIER_3) يوافق أو يرفض. الموافقة تُشغّل applyDecision().

قواعد حركة TM_ الأربع

تُختبر كل حركة مقترحة مقابل القواعد الأربع:

تعمل TM_BLOCK_01 (الإخلاص) قبل TM_ESC_01. خطة لا تعمل مختلفة عن خطة لم تُنجَز؛ تضمن بوابة الإخلاص أن التصعيد لا يُشغَّل إلا عندما تُقدَّم الخطة فعلاً.

بوابة الإخلاص

متتبّع الإخلاص (WP-FID-BE، 35-fidelity-tracker) مشحون. يقرأ RTI حكمه عبر prismaFidelityReader، الذي يُفوّض إلى readLatestProjection الخاص بالمتتبّع: تُنتج أحدث لقطة intervention_fidelity حكماً محسوباً (high / adequate / partial / low / unknown) إضافةً إلى قيمة escalationBlocked التي يُثبّتها المتتبّع. تقرأ TM_BLOCK_01 قيمة escalationBlocked تلك بدل إعادة اشتقاقها من المعدّل الخام.

يبقى الافتراض المغلق على الفشل سارياً، لكن للبيانات المفقودة فعلاً فحسب. صفّ إخلاص مفقود، أو صفّ عابر للمؤسسة، أو bundleAssignmentId فارغ (لا خطة فعّالة) يُعيد fidelityRating = 'unknown'، escalationBlocked = true. هذا حارس B.21: غياب بيانات الإخلاص يجب أن يحجب التصعيد لا أن يسمح به. لم يعد حجباً شاملاً ينوب عن وحدة غير مبنية؛ تعكس البوابة الآن حكم التقديم الحقيقي لأي طالب لديه واحد.

بوابة موافقة TIER_3

يستلزم تصعيد TIER_3 إذن REQUEST_TIER_REVIEW (يملكه المعلمون) على المسار، و بوابة المتخصص APP_HIGH_INTENSITY داخل المعالج (APPROVE_TIER_3_ACTIVATION). يرتكز ذلك الإذن على AdminProfile.specialistRole. الموافِق المسموح له على TIER_3 في المرحلة الأولى هو إذن معلم مُجلَس كمسؤول بصفة المتخصص (B.20)، لا مسؤول عادي. المسؤول العادي بدون specialistRole يُرفض (403).

applyDecision(): مسار الكتابة الفردي

جميع تحولات المستوى تمر عبر apply-decision.ts. إنه المكان الوحيد الذي يُحدَّث فيه student_tier_status.currentRtiTier (مُطبَّق بـ lint:tier-status-single-write-path).

الكتابة ذرّية: في معاملة واحدة تقوم بـ:

1. إدراج tier_decision_record إلحاقي فحسب
2. تحديث student_tier_status.currentRtiTier (فقط عندما يُحرّك القرار المستوى)
3. إغلاق rti_alert المرتبط (فقط عند تغيير المستوى)
4. انتقال حالة tier_review_request إلى closed

تغيير المستوى بدون tier_decision_record مقابل مستحيل هيكلياً.

تكتب إجراءات الإقرار والرفض للتنبيه صفاً في teacher_action_log عبر معالجاتها الخاصة، غير أن مسار قرار المستوى (applyDecision) لا يفعل ذلك.

الحتمية (V-6)

ملفات المحرك النقية الأربعة (layer-a.ts, layer-b.ts, rti-status.ts, tm-rules.ts) تأخذ فقط المدخلات المُخزَّنة وإصدار tier_movement_rule المُثبَّت. بنفس المدخلات وإصدار القاعدة ذاته، تُنتج دائماً نفس نوع التنبيه وحكم الحركة، مضموناً بالتصميم ومُتحقَّق منه بمجموعة الاختبارات.

الوصلات العليا (موصولة الآن)

كلا المُنتِجَين اللذين يقرأ منهما RTI مشحونان، فيرتبط القارئان بأحكام حقيقية. تبقى الواجهات القابلة للحقن كي تظل البوابة قابلة للاختبار بمحاكاة، ويبقى كل منها مغلقاً على الفشل عند فقدان البيانات فعلاً:

بقية واحدة مؤجَّلة فعلاً: documentedException (فرع الاستثناء الموثّق لـ APP_HIGH_INTENSITY ضمن بند adequate_or_documented في TM_ESC_01) ليس بعد حقلاً على intervention_fidelity؛ يبقى false، وتُلبّي أحكام adequate / high البند في المرحلة الانتقالية. يصل مع عمل حزمة القرار.

أدلة ذات صلة

• القياس المنهجي وطلاقة القراءة: CBM يُصدر إشارة الاتجاه الخام التي يستهلكها محرك RTI
• مراقبة التقدم: أحكام المراقبة تُغذّي الطبقة B
• سير عمل تفعيل المعلم: السطح الخاص بالمعلم لترشيح مراجعات المستوى
• الملفات الشخصية للطلاب: الملف الشخصي الذي يُغذّي فحص مُوقِف RTI
• قواعد السلامة: بوابة الإخلاص وقواعد GSR في السياق الكامل