Spec Kit في Full-Stack الحقيقي: كيف أدت 17 Sprints إلى نشر متتبِّع العادات للإنتاج

تمكّن تطوير مدفوع بالمواصفات من الوصول ليس فقط إلى عرض توضيحي لليلة واحدة، بل إلى إطلاقة كاملة full-stack حقيقية. تصف حالة LifeSync 17 دورة تطوير لمتتبع العادات والأهداف وتطبيقًا منفصلين ومئات الاختبارات وإطلاقة إلى الإنتاج — وتقود إلى الاستنتاج الرئيسي: في الحجم الكبير، SDD قيّم ليس من أجل سرعة توليد الكود، بل لمنع فقدان السيطرة عندما يبدأ backend و frontend والبنية الأساسية بسحب المشروع في اتجاهات مختلفة. تستخدم دراسة الحالة خدمة B2C للعادات والأهداف كمثال.

يتم بناء backend على Spring Boot 3.5 و Java 21، منظمة باستخدام العمارة السادسة عشرة عبر ستة وحدات 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 ترحيل Liquibase وتم إطلاقه إلى الإنتاج: backend مُنشر على Railway و frontend على Vercel.

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

يتم استكمال ذلك بملفي دستور مختلفين. بالنسبة للـ backend، نما المستند بمرور الوقت من قالب إلى 437 سطرًا وشمل قواعد الترحيلات والالتزامات والأسلوب و OpenAPI. بالنسبة للـ frontend، كان الدستور أكثر إحكاما — 137 سطرًا، لأن المجموعة والأنماط تم تعريفها بشكل أكثر صرامة من البداية.

يتم التركيز بشكل خاص على أمر speckit.analyze الذي يستخدمه المؤلف كحلقة تغذية راجعة إلزامية بعد كل دورة. لا يحل محل الاختبارات ولا يتظاهر بأنه linter، بل يوفق بين spec.

md و plan.md و tasks.md والتطبيق الفعلي.

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

عنصر مهم آخر هو نهج API-first كعقد بين المستودعين. في المشروع، يتم تخصيص وحدة منفصلة لهذا مع مواصفات OpenAPI بحوالي 2669 سطر و 32 endpoint. يولد backend واجهات تحكم Java منها، و frontend يستخدم نفس YAML كمصدر حقيقة واحد ويحافظ يدويًا على أنواع TypeScript لسيناريوهات واجهة المستخدم الحقيقية.

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

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