FightThis

الملخص

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

المشكلة والمستفيدون

يصعب فهم الفواتير الطبية وقرارات رفض التأمين، فيدفع كثيرون أو يستسلمون دون تدقيق. يشرح FightThis الفاتورة أو قرار الرفض بلغة بسيطة، ويقدّر قوة الاعتراض، ويصوغ الرسائل، دون أن يتصرف كمحامٍ أو يعد بنتيجة.

الأشخاص الذين يواجهون فاتورة طبية أو رفضًا من التأمين الصحي لا يفهمونه. نطاق المنتج ضيق عن قصد (الفواتير الطبية وقرارات رفض التأمين) رغم أن نموذج البيانات يسمح بأنواع أخرى من النزاعات. لا نسخة مستضافة له ولا مستخدمين.

دوري

عمل فردي. حدّدت نطاق المنتج، وقواعد السلامة (لا استشارة قانونية أو طبية، ولا نتائج موعودة، ولا قوانين أو مواعيد نهائية مختلَقة، ومسار للمراجعة البشرية)، والبنية، وخطة المراحل. كان التنفيذ بمساعدة الذكاء الاصطناعي تحت توجيهي خلال الفترة من 2026-06-11 إلى 2026-06-13 وأُودع إيداعًا أوليًا واحدًا، لذا لا يُظهر git الخطوات المنفردة. وفي سبتمبر 2026 أضفت التكامل المستمر بعد أن وجدت أن النسخة النظيفة لم تعد تُثبَّت.

البنية

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

القرارات والمفاضلات

• فحص المعنى، لا الشكل فقط. يضمن التحقق من المخطط أن النموذج أعاد الحقول الصحيحة. ويفحص مرور ثانٍ ما تقوله تلك الحقول: يرفض الوعود بالنتائج ولغة المحامين، ويشترط تصريحًا حقيقيًا بعدم اليقين، ويرفض تقييمًا عاليًا لقوة الاعتراض لا يستشهد بأي مصدر. وكل ما يفشل يذهب إلى المراجعة البشرية بدل المستخدم. قوائم العبارات فجّة وستفوتها إعادة الصياغة، لذا فهي حد أدنى خلفه مسار مراجعة، لا ضمان.
• الفشل إلى حالة محفوظة، لا إلى إجابة جزئية أبدًا. يعلّم انتهاء المهلة أو المخرجات غير الصالحة أو خطأ المزوّد التحليل بأنه فاشل، ويحتفظ بالحالة ومستنداتها، ويضعها في وضع «يلزم إجراء»، ويكتب مدخلًا في الخط الزمني. وتفرض خمسة اختبارات تكامل مع قاعدة البيانات كل وضع فشل وتفحص الحالة المخزّنة.
• الويب هوك وحده يمنح الشراء. لا يُوثَق أبدًا بعودة المتصفح من صفحة الدفع. تُنشأ الاستحقاقات عبر ويب هوك Stripe وحده، ويُتجاوز معرّف الحدث المكرّر، وتُلغي المبالغ المستردة الوصول. والتكلفة تأخير قصير بين الدفع وفتح المحتوى. تغطي اختبارات قاعدة البيانات ذلك بعميل Stripe مُحاكى (stub)؛ ولم يُشغَّل على Stripe نفسه.
• جعل كل اعتمادية اختيارية في التطوير وإلزامية في الإنتاج. دون مفاتيح يستخدم التطبيق محاكاة حتمية للذكاء الاصطناعي، واستخراجًا محليًا للنص، ومهامَّ مضمّنة، وتخزينًا على القرص، وصندوق صادر في ملف، فيمكن بناؤه واختباره دون اتصال. ويرفض إعداد الإنتاج الإقلاع في أي من تلك الأوضاع. والمفاضلة مساران في الشيفرة لكل نظام فرعي، والمسارات الحقيقية هي الأقل ممارسة.

نتائج مُتحقَّق منها

القيود والعمل المتبقي

• لم يُطلق ولم يُنشر؛ لا مستخدمين. حزمة لبيئة ما قبل الإنتاج (حاوية، وإعداد Railway، ودليل تشغيل) مُعدّة لكنها لم تُشغَّل قط.
• لم يحلّل أي نموذج ذكاء اصطناعي حقيقي أي مستند. والتحليل في هذه الصفحة وفي الاختبارات من المزوّد المُحاكى الحتمي.
• لم تُمارَس المدفوعات وتسليم البريد وتخزين S3 وطابور Redis والتعرّف الضوئي على الصور إلا عبر المحاكاة أو الأوضاع المحلية. ومراقبة الأخطاء من جهة العميل غير موصولة.
• الضوابط قائمة على القواعد والعبارات. تقلّل المخاطر؛ لكنها لا تجعل المخرجات صحيحة، والمنتج ليس استشارة قانونية أو طبية. يراعي الخصوصية لكنه غير متوافق مع HIPAA.
• فقدان مفتاح تشفير البيانات يجعل نص المستندات المخزّن غير قابل للاستعادة؛ ويحتاج تدوير المفاتيح إلى خطة إعادة تشفير غير موجودة بعد.
• تاريخ التطوير إيداع أولي واحد، لذا فالعمل مرحلةً بمرحلة مسجّل في ملاحظات المشروع ووثائقه، لا في git.