Spec Kit في مشروع full-stack حقيقي: كيف أوصلت 17 سبرنت متتبّع العادات إلى الإنتاج

لم يقتصر نجاح Spec-Driven Development على عرض تجريبي يُنجز في أمسية واحدة، بل بلغ إطلاق full-stack متكاملًا. تصف حالة LifeSync تطوير متتبّع للعادات والأهداف عبر 17 سبرنت ومستودعين منفصلين ومئات الاختبارات، وصولًا إلى الإنتاج، وتخلص إلى استنتاج رئيسي: في المشاريع الكبيرة لا تكمن فائدة SDD في سرعة توليد الكود، بل في أنه يحافظ على قابلية التحكم حين تبدأ backend وfrontend والبنية التحتية بجذب المشروع في اتجاهات مختلفة.

اختير مثالًا خدمة B2C للعادات والأهداف. بُني backend على Spring Boot 3.5 وJava 21، ووُزّع وفق العمارة السداسية (hexagonal architecture) على ستة وحدات Maven، ويستخدم jOOQ بدلًا من JPA، وKafka للمنطق القائم على الأحداث، وJWT RS256، وOpenAPI 3.1 بوصفه العقد الأساسي للـ API. أما frontend فقد بُني على React 19 وTypeScript 5.9 وVite 8 وTanStack React Query وZustand وshadcn/ui مع Tailwind CSS. وخلال 17 سبرنت وصل المشروع إلى 251 اختبارًا في الجزء الخادمي و77 اختبارًا في جانب العميل، وضمّ 19 ترحيلًا (migration) عبر Liquibase، ثم أُطلق في الإنتاج: نُشر backend على Railway وfrontend على Vercel.

الفكرة المحورية في الحالة أن الحجم الكبير تطلّب انضباطًا مختلفًا في العمل مع الذكاء الاصطناعي. ففي المشروع الصغير كانت محادثة تفكير واحدة وبيئة تنفيذ واحدة كافيتين، أما في مشروع full-stack فقد انتهى المؤلف إلى نظام من ثلاث محادثات. فهناك سياق مستقل لـ backend وآخر لـ frontend وثالث لتنسيق القرارات المشتركة التي تمسّ المستودعين معًا: النشر والميزات العابرة للطبقات وتغييرات API والمراجعات الاسترجاعية.

ويُستكمل ذلك بملفَّي constitution مختلفين. فوثيقة backend نمت مع الوقت من قالب أولي إلى 437 سطرًا، وضمّت قواعد الترحيلات وعمليات الـ commit والأسلوب وOpenAPI. أما دستور frontend فجاء أكثر إيجازًا بوضوح، 137 سطرًا، لأن التقنيات والأنماط كانت محددة بصرامة أكبر منذ البداية.

ويُسلَّط الضوء بوجه خاص على الأمر speckit.analyze، الذي يستخدمه المؤلف حلقة تغذية راجعة إلزامية بعد كل سبرنت. فهو لا يحلّ محل الاختبارات ولا يدّعي أنه أداة linter، بل يطابق بين spec.md وplan.md وtasks.md والتنفيذ الفعلي. ووفق المؤلف، ساعد هذا التحليل تحديدًا على اكتشاف مشكلة حرجة في سبرنت backend الخاص بـ Kafka: كان نشر الأحداث في عدة use case يجري داخل معاملة (transaction) دون try-catch واقٍ. ولم يظهر الخطأ في بيئة الاختبار لأن Kafka في الحاويات كان متاحًا دائمًا، لكنه كان قد يؤدي عند عطل حقيقي إلى التراجع عن بيانات حُفظت بالفعل وترك النظام في حالة غير متسقة. وبعد التحليل أُضيفت الحماية إلى الكود، وحُسّن منطق retry، وتوسّعت فحوص التكامل.

وثمة ركيزة مهمة أخرى هي نهج API-first بوصفه اتفاقًا بين المستودعين. فقد خُصصت لذلك في المشروع وحدة مستقلة تضم مواصفة OpenAPI بنحو 2669 سطرًا و32 endpoint. يولّد backend منها واجهات Java للـ controllers، بينما يعتمد frontend على ملف YAML نفسه مصدرًا وحيدًا للحقيقة، ويحافظ يدويًا على أنواع TypeScript بما يلائم سيناريوهات الواجهة الفعلية. ويؤكد المؤلف على نحو خاص أن speckit.analyze لا يستطيع التحقق تلقائيًا من الاتساق بين المستودعين معًا، ولذلك لا تزال الفحوص العابرة للمستودعات تُجرى يدويًا عبر سياق التنسيق. غير أن النظام يقلّل حتى بهذا الشكل خطر الانفصال الصامت بين الخادم والواجهة: فإذا تغيّر الـ API سُجّل ذلك أولًا في المواصفة، ثم يظهر في مرحلة توليد الواجهات أو عند تجميع (compile) الـ frontend.

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

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