# الدافع: لماذا "يفوز القرص"؟ ## المشكلة في وضع الهالة الجدة في [Aura Oma Mode](../../../GettingStarted.i18n/GettingStarted-arlang.md) (انظر السطر 67)، تعمل Aura بشكل مستقل إلى حد كبير: يتحدث المستخدم بالأوامر، وتقوم Aura بالكتابة على الملفات من تلقاء نفسها — التكوينات والبرامج النصية وإدخالات السجل والنص الذي تم إنشاؤه. يحدث السيناريو التالي باستمرار: 1. لدى المستخدم ملف مفتوح في المحرر (على سبيل المثال، ملف قاعدة أو برنامج نصي). 2. ينسون أن المحرر لا يزال نشطًا ويتحدثون بأمر Aura. 3. تقوم Aura بتغيير الملف الموجود على القرص. 4. يكتشف المحرر التغيير الخارجي — و**يسأل**. هذه المطالبة هي **Showstopper** في وضع Oma: - قد يكون المستخدم جالسًا على الأريكة، مستخدمًا الإدخال الصوتي، ولا يمكنه رؤية مربع الحوار أو الوصول إليه. - أو أنهم ضغطوا بطريق الخطأ على مفتاح في المحرر، أصبح المخزن المؤقت الآن "معدل"، وكل تغيير خارجي يحجب بـ "إعادة التحميل؟ / الحفاظ على المستوى المحلي؟" الحوار. - النتيجة: تستمر Aura في العمل، ولكن يُظهر المحرر نسخة قديمة. يعتقد المستخدم أنه ينظر إلى الملف الحالي، ولكن يعتمد على التعديلات على الدولة القديمة - الفوضى مضمونة. ## ما نحتاجه سلوك المحرر الذي **يعطي الأولوية للقرص دائمًا**. عندما تقوم Aura (أو أي أداة أخرى) بتغيير الملف، يجب على المحرر القيام بذلك قم فورًا و**دون أي مطالبة** بعرض المحتوى الجديد. قد يتم تجاهل المدخلات غير المحفوظة في المحرر بصمت - لأنه في وضع Oma، Aura هو مصدر الحقيقة، وليس إدخال لوحة المفاتيح البشرية. ## لماذا يفشل المحررون القياسيون جميع برامج التحرير الشائعة تقريبًا (Kate، VS Code، Sublime Text، Notepad++، تتمتع Emacs وVim وCudaText خارج الصندوق) بآلية حماية: بمجرد أن يحتوي المخزن المؤقت على تغييرات غير محفوظة، فإنهم **دائمًا** يسألونك عند حدوث تغيير خارجي. هذه ميزة عادية عمل المطور - ولكن هناك خطأ في وضع Aura Oma. يقوم هذا البرنامج المساعد بإغلاق هذه الفجوة بالضبط بالنسبة لـ CudaText. ## الجمهور المستهدف - مستخدمو وضع Aura Oma الذين يعرضون الملفات في المحرر بالتوازي. - سيناريوهات الأتمتة حيث تقوم العملية بكتابة الملفات والمحرر يخدم فقط كمشاهد مباشر. - أي شخص "القرص يفوز دائمًا" هو السلوك المطلوب.