// tier: vasic-util-secondary · order 24
DocProcessor activelicense: Apache-2.0
Source
المحتوى حول الوثائق إلى خريطة ميزات قابلة للتحقق لأتمتة ضمان الجودة
DocProcessor هو وحدة Go مستقلة تمامًا ومفككة تمامًا، تقوم بتحميل وثائق المشروع، وبناء خرائط ميزات منظمة، وتتبع تغطية التحقق. تم تصميمها للعمل مع وكلاء LLM لاستخراج الميزات الذكي، ولكنها تتضمن أيضًا استخراجًا قائمًا على الاستدلال للاستخدام دون اتصال.
وحدة Go مستقلة عن المشروع لمعالجة الوثائق واستخراج خرائط الميزات. تحلل الوثائق إلى خرائط ميزات منظمة وتتبع الميزات التي تم التحقق منها — باستخدام وكلاء LLM للاستخراج الذكي أو الاستدلال دون اتصال — لتزويد أتمتة ضمان الجودة بضمان عدم التلاعب ومطابقة الواقع دائمًا.
تعيش كل فرق البرمجيات مع الكذبة البطيئة ذاتها: الوثائق تعد بميزات، والاختبارات تغطي شيئًا قريبًا منها، ولا أحد يستطيع الجزم ما إذا كان الاثنان يصفان المنتج ذاته. وُجد DocProcessor لجعل هذه الفجوة مرئية وقابلة للقياس. عند تزويده بوثائق المشروع، يبني خريطة ميزات منظمة — نموذج معدود وقابل للقراءة آليًا لكل ما يدعي المنتج القيام به — ويتتبع تغطية التحقق مقابلها، بحيث يتحول سؤال "هل هذه الميزة الموثقة مثبتة بالفعل؟" من جدال في الممرات إلى استعلام له إجابة. تم تصميمه للعمل بوضع مزدوج: يستخدم وكلاء LLM للاستخراج الدلالي الذكي عند توفره، ويعتمد على محلل استدلالي للاستخدام دون اتصال، فلا يعتمد بشكل صارم على وجود نموذج ويعمل بنفس الكفاءة سواء في مهمة CI معزولة أو على حاسوب مطور في وضع الطيران.
من الناحية المعمارية، هو وحدة Go مستقلة تمامًا وغير مدركة للمشروع ومفككة بالكامل (CONST-051(B)): لا يشحن أي قيم خاصة بالمشروع ويتم دمجه من قبل المستهلكين كوحدة فرعية متساوية في قاعدة الشفرة، بحيث يمكن لأي مشروع تبنيه دون وراثة افتراضات الآخرين. كما يلتزم بنفس المعايير التي يفرضها على الآخرين — إذ ترتبط مزاعمه بميثاق عدم التلاعب (CONST-035) وقواعد التغطية التامة للأتمتة (CONST-048)، مما يعني أن كل قدرة يعلن عنها ملف README يتم اختبارها عبر اختبار آلي أو نص تحدي يؤكد سلوكًا حقيقيًا وقابلًا للاستخدام من قبل المستخدم النهائي، وليس مجرد خروج خالٍ من الأخطاء؛ وتنتقل السلاسل المعروضة للمستخدم عبر طبقة مترجم التدويل CONST-046. الهدف من كل هذا هو حلقة مغلقة: DocProcessor هو الجانب المدخلي لدورة ضمان الجودة التي يغلقها HelixQA — فهو يستخرج خريطة الميزات من الوثائق، ويثبت HelixQA كل ميزة مُدرجة بأدلة تشغيلية مسجلة، مما يجبر الوثائق والاختبارات والسلوك النهائي على التقارب بدلاً من الانجراف بصمت إصدارًا بعد إصدار.
تنفصل الوثائق والاختبارات عن بعضها: الوثائق تعد بميزات لا يثبتها أي اختبار، ولا تستطيع ضمان الجودة بسهولة تحديد ما يعنيه "الاكتمال". يحول DocProcessor الوثائق إلى خريطة ميزات قابلة للقراءة آليًا بحيث يمكن قياس تغطية التحقق مقابل ما تم وعد به بالفعل.
المحتوى
يحوّل هذا الحلّ أكثر الأسئلة ضبابيّةً في تسليم البرمجيّات — "هل ما سلّمنا يتطابق مع ما زعمنا أننا سلّمنا؟" — إلى أمر قابل للأتمتة والمراقبة المستمرّة، وذلك دون الاعتماد الصارم على AI: استخراج LLM عند توفّر النموذج، أو الاعتماد على الاستدلالات عند عدم توفّره، بحيث يظلّ الضمان سارياً في كلّ بيئة، من المُشغّل غير المتّصل بالشبكة إلى خطّ الإنتاج التامّ التلقائيّة.
- استخراج خريطة المزايا من الوثائق مع تتبّع تغطية التحقّق.
- الاستخراج المزدوج: مدفوع بواسطة وكيل LLM أو الاستدلال/العمل دون اتّصال.
- الفصل التامّ عن المشروع دون الحاجة إلى ضبط مسبق (CONST-051(B)).
- التحقّق الذاتي من عدم التضليل: ادّعاءات ملفّ README مدعومة باختبارات/تحدّيات (CONST-035/048).
- العمل دون الحاجة إلى نموذج: تمّ حلّها باستخدام مُستخرج استدلالي احتياطي لضمان عمل الوحدة دون اتّصال.
- مواءمة الوثائق مع الواقع: تمّ حلّها عبر خرائط المزايا المنظّمة وتتبّع تغطية التحقّق، مُدمجة في حلقة ضمان الجودة.
- إمكانيّة إعادة الاستخدام: تمّ حلّها عبر الفصل الصارم واستهلاك الوحدات الفرعيّة من قاعدة الشفرة ذاتها.
- مصداقيّة الادّعاءات: تمّ حلّها باختبارات/تحدّيات مضادّة للتضليل لكلّ قدرة معلن عنها.
- Go (الإصدار 1.25 فما فوق) — نواة الوحدة؛ مرخّصة بموجب رخصة Apache-2.0.
- وكلاء LLM — استخراج المزايا الدلاليّة الذكيّة (اختياري).
- المُحلّل الاستدلالي — احتياطي لاستخراج المزايا دون اتّصال.
- مترجم التدويل (
pkg/i18n) — سلاسل نصيّة محلّية وفقاً لـ CONST-046. - إطار التحدّيات — التحقّق المضادّ للتضليل من ادّعاءات الوحدة ذاتها.