Understand a verification result

تابع مثال Twitter

يتبع هذا الدليل خطأ حذف المنشور في مثال Twitter الخاص بـ Panolayer. ستقرأ المشكلة، وتتتبع شرحها وصولًا إلى الشيفرة، وتفهم ملخص التحقق قبل أن تقرر الدمج.

للمتابعة، افتح Twitter Clone ضمن جرّب تطبيقًا نموذجيًا. يُفتح باسم twitter-starter. للاطلاع على الإعداد الكامل وشرح خطوات الإصلاح، راجع أصلح أول خطأ برمجي لديك باستخدام Panolayer. تُظهر لقطات الشاشة تشغيلًا واحدًا مسجّلًا؛ قد يختلف ترتيب المشكلات وأعدادها لديك.

ابدأ من المشكلات

عند فتح قاعدة شيفرة، يبدأ Panolayer verification engine بالعمل. يحلّل قاعدة الشيفرة وصولًا إلى دوالها ورموزها واعتمادياتها، ويبني البنية المعمارية المرئية، ويفحص الشيفرة لتحديد الأخطاء.

افتح المشكلات. في هذا المثال، انتهى التشغيل وتظهر الحالة باسم اكتمل التحقق. تظهر المشكلات التي تحتاج إلى تحقيق ضمن تحتاج إلى انتباه.

تصف حالة اكتمل التحقق التشغيل. وهي تعني أن التشغيل قد انتهى؛ اقرأ النتائج لمعرفة ما إذا كان قد وجد إخفاقات.

اقرأ مشكلة الحذف

تُبلغ أول مشكلة في المثال أن شرطًا قد يمنع حذفًا مؤكدًا:

يمكن لحارس canDelete الإضافي منع الحذف رغم تأكيد المستخدم، خلافًا لسلوك حذف المنشور الحالي المعلن.

القاعدة هي توقّع بشأن سلوك دالة: ما الذي ينبغي أن تُرجعه، وما الإجراء الذي ينبغي أن تنفذه، أو ما الذي تتوقعه شيفرة أخرى منها. هنا، يتعلق التوقع بحذف المنشور الحالي بعد تأكيد المستخدم.

اقرأ ملف المشكلة ودالتها وحالتها وشرحها معًا:

افتح التفاصيل. يقول الشرح إن الدالة يمكنها الإرجاع مبكرًا عندما تكون canDelete مساوية لـ false، قبل إكمال الحذف الموصوف في القاعدة. تشير إحالة المصدر إلى الشيفرة ذات الصلة.

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

ماذا تعني الحالات؟

اقرأ الحالة إلى جانب شرحها والشيفرة التي تنطبق عليها.

إذا تعذّر إكمال التحقق، اتبع الخطأ المبلّغ عنه وراجع حل مشكلات الإعداد والوكيل.

أصلح الخطأ ودع التحقق يعمل مرة أخرى

في مشكلة الحذف، انقر على إصلاح، ثم اختر Panolayer Agent. يمرر Panolayer سياق المشكلة إلى الوكيل، لذا لا تحتاج إلى كتابة مطالبة تشرح الخطأ.

Panolayer Agent مدمج. يمكنك أيضًا استخدام وكيل مدعوم آخر بعد تثبيته؛ راجع الوكلاء المدعومون.

يعمل الوكيل في شجرة عمل Git خاصة به، مما يبقي تعديلاته منفصلة عن فرعك. تابع المهمة في وكلائي، أو انقر على فتح في بطاقة التشغيل لفحص نشاطه وتغييراته.

مع تغيّر الشيفرة، يعيد Panolayer فحص الدوال المتأثرة والشيفرة المرتبطة، بما في ذلك المستدعِين في ملفات أخرى. يساعد ذلك في اكتشاف الانحدارات خارج الأسطر التي عدّلها الوكيل.

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

اقرأ ملخص التحقق قبل الدمج

عندما تنتهي عملية التشغيل هذه، يعرض Panolayer Panolayer Agent جاهز للدمج. يلخص مربع الحوار ما فحصه التحقق وأصلحه أثناء المهمة.

تقول رسالة السلامة لا توجد إخفاقات أو تحذيرات أو قواعد غير مفحوصة جديدة. اقرأ تلك الرسالة إلى جانب الأعداد: فهي تصف نتيجة هذا العمل، بينما يشرح السطر التالي الإخفاقات المتبقية من قبل بدئه.

ماذا لو ظهرت «الانحدارات المكتشفة»؟

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

لا يظهر هذا الحقل في لقطة الشاشة هذه. يعرض مثال الحذف إخفاقًا موجودًا مسبقًا تم إصلاحه؛ ولا يوضح انحدارًا تم اكتشافه أثناء الإصلاح.

Why can it be ready to merge when failures remain?

Panolayer compares the result with the baseline: the state of the codebase before the change. This separates problems introduced by the task from problems that were already there.

• A new failure was introduced by the change and needs investigation before you accept the work.
• A pre-existing failure was present before the task started. It can still matter, but this task did not introduce it.
• A repaired failure was present before the task and was fixed during the work.

In the screenshot, the dialog reports 7 pre-existing failures that do not block this merge. The selected deletion issue was repaired, and those other issues remain separate work.

The repository’s issue list and an agent’s verification summary can cover different scopes. The issue list shows what needs attention in the codebase; the merge summary describes the agent’s work against its baseline. An agent’s result can report no new failures while the repository still has pre-existing issues.

You can assign a pre-existing issue as another task using Fix. That gives the agent a specific issue to work on next.

Ready to merge does not mean every issue in the repository is resolved. Read what this task repaired, what it introduced, and what was already there.

Decide what reaches your branch

You control the merge. Before accepting the result:

1. Check that the repaired issue matches the bug you asked the agent to fix.
2. Read the verification summary, including any new failures, warnings, or checks that could not finish.
3. Open Details for more context and inspect the agent’s changed files. Review the relevant tests and run the application when the behavior needs a runtime check.
4. Confirm the target branch. Choose Merge into main when you’re satisfied, or Not now to keep reviewing.

Verification gives you evidence for the decision. Read it alongside the code and relevant tests; it does not cover every possible bug.