yongol — عارضة السفينة للبرمجيات السحابية المبنية بالذكاء الاصطناعي

نقطة النهاية رقم 200

تبني منصة SaaS بالبرمجة الحدسية. في البداية يكون الأمر سريعًا. 5 جداول، 12 نقطة نهاية — عشرون دقيقة ويعمل.

لكن بعد 50 نقطة نهاية، يبدأ شيء غريب بالحدوث. الذكاء الاصطناعي ينتج اليوم نمطًا يناقض نمط الأمس. بعد 100، تتعطل الميزات الموجودة بصمت. بعد 200، إضافة ميزة واحدة تكلف 10 أضعاف ما كلفته أول عشر ميزات.

ليس لأن النموذج غبي.

القرارات والتنفيذ

ثلاثة أشياء متشابكة في الشفرة المصدرية:

• قرارات المستخدم — هذا العمود هو BIGINT، نقطة النهاية هذه للمالك فقط، التصفح بالمؤشر.
• منطق الأعمال — التسعير، سير العمل، قواعد دورة الحياة.
• تفاصيل التنفيذ — أسماء المتغيرات، ترتيب استدعاءات المكتبات، تغليف الأخطاء.

عندما يقرأ الذكاء الاصطناعي هذه الشفرة، لا يستطيع تمييز أي سطر هو قرار وأيها تفصيل. لذا عندما “يعيد الهيكلة” أو “ينظف”، يكتب فوق القرارات التي ظنها تفاصيل — بصمت. لا يلاحظ المستخدم حتى يكون السلوك قد انحرف بالفعل.

هذا هو سبب انهيار البرمجة الحدسية عند 200 نقطة نهاية. نموذج أكبر لا يحل المشكلة. الوسيط — الشفرة الخام — ببساطة لا يحفظ القرارات. كل نموذج يصطدم بنفس الجدار في النهاية.

العارضة

العارضة هي أول عظم يُوضع عند بناء السفينة. تحمل وزن الهيكل، وتمنع التمايل الجانبي، وكل هيكل آخر يُبنى فوقها. سفينة بُنيت بدون عارضة تطفو في المياه الهادئة لكنها تتشوه عندما تأتي الأمواج.

منصة SaaS المبنية بالبرمجة الحدسية كذلك. تطفو عندما تكون صغيرة. تتشوه عندما تكبر.

yongol هو عارضة البرمجيات السحابية المبنية بالذكاء الاصطناعي.

نقل القرارات خارج الشفرة

جوهر yongol بسيط. فصل القرارات عن الشفرة.

عشرة مواصفات تصريحية (SSOTs) يتعامل كل منها مع اهتمام واحد:

ثمانية من العشرة هي معايير صناعية (OpenAPI، SQL، sqlc، Rego، Mermaid، Hurl، YAML). فقط SSaC وSTML هما DSL أنشأهما yongol. ما يجب على الذكاء الاصطناعي تعلمه من الصفر يُقلَّل إلى الحد الأدنى.

كل SSOT يحتوي على قرارات فقط. لا تفاصيل تنفيذ. الذكاء الاصطناعي يحرر الـ SSOTs؛ yongol generate يولد الشفرة منها. القرارات تعيش بشكل دائم في الـ SSOTs؛ الشفرة هي إسقاط قابل للتخلص منه.

فرض التناسق

القرارات موزعة الآن على عشرة ملفات، لذا يمكن أن تظهر تناقضات. DDL يقول BIGINT لكن OpenAPI يقول string؟ SSaC يُصرِّح @auth لكن Rego ليس لديه قاعدة مطابقة؟ مخطط الحالة فيه انتقال لكن SSaC ليس لديه دالة مقابلة؟

SSOT متناقض هو قرار فاسد. مهما كانت الشفرة نظيفة، إذا تعارضت القرارات، يكون السلوك خاطئًا.

yongol validate يلتقط هذا.

✓ manifest        ✓ openapi_ddl       ✓ ssac_rego
✓ openapi         ✓ openapi_ssac      ✓ ssac_authz
✓ ddl             ✓ hurl_openapi      ✓ ssac_sqlc
✓ query           ✓ hurl_statemachine ✓ ddl_statemachine
✓ ssac            ✓ hurl_manifest     ✓ ddl_rego
✓ statemachine    ✓ openapi_manifest  ✓ rego_manifest
✓ rego            ✓ ssac_ddl          ✓ stml_openapi
✓ hurl            ✓ ssac_statemachine
✓ funcspec        ✓ ssac_func

0 errors, 0 warnings

يتحقق من كل SSOT على حدة أولاً، ثم يُجري فحوصات تبادلية بين الطبقات. ~287 قاعدة تفحص كل مرجع رمزي عبر جميع الـ SSOTs العشرة. إذا وُجد تناقض واحد، يُرفض التجميع.

الذكاء الاصطناعي يكتب بحرية. إذا خرج عن السكة، validate يلتقطه فورًا. حرية على السكة.

operationId هو حجر الأساس

كيف تربط عشر طبقات معًا؟ بمُعرِّف PascalCase واحد.

أدخل operationId التالي ExecuteWorkflow:

── Feature Chain: ExecuteWorkflow ──

  OpenAPI    api/openapi.yaml                POST /workflows/{id}/execute
  SSaC       service/workflow/execute_workflow.ssac   @get @empty @auth @state @call @publish @response
  DDL        db/workflows.sql                CREATE TABLE workflows
  DDL        db/execution_logs.sql           CREATE TABLE execution_logs
  Rego       policy/authz.rego               resource: workflow
  StateDiag  states/workflow.md              diagram: workflow → ExecuteWorkflow
  FuncSpec   func/billing/check_credits.go   @func billing.CheckCredits
  FuncSpec   func/billing/deduct_credit.go   @func billing.DeductCredit
  FuncSpec   func/worker/process_actions.go  @func worker.ProcessActions
  FuncSpec   func/webhook/deliver.go         @func webhook.Deliver
  Hurl       tests/scenario-happy-path.hurl  scenario: scenario-happy-path.hurl

من مواصفات API إلى مخطط قاعدة البيانات، من سياسات التفويض إلى انتقالات الحالة، من تنفيذات الدوال إلى سيناريوهات الاختبار — الطوبولوجيا الكاملة لميزة واحدة في شاشة واحدة. عشرات عمليات grep يستبدلها أمر واحد.

operationId هو حجر الأساس لأن وحدة الميزة في تطبيق full-stack هي نقطة نهاية API. المستخدم يضغط زرًا، يُستدعى API، وذلك الـ API يخترق كل طبقة أخرى. اسم واحد يربط عشر طبقات فيزيائيًا.

اختبار الأداء: ZenFlow

ZenFlow — منصة SaaS لأتمتة سير العمل متعددة المستأجرين. Claude Sonnet 4.6 كتب الـ SSOTs؛ yongol تحقق منها.

النتيجة النهائية: 30 نقطة نهاية، 12 جدولاً، 64 طلب اختبار. كلها ناجحة.

أُضيفت 10 ميزات بالتتابع. إضافة الميزات لم تبطئ أبدًا. الاختبارات الموجودة لم تنكسر أبدًا. جدار الـ 200 نقطة نهاية لم يكن موجودًا.

تشغيل نفس المواصفات مع Opus: 30 نقطة نهاية، 73 طلب اختبار، ~76 دقيقة. النموذج يتغير، السكة تبقى كما هي.

لماذا النموذج الأكبر ليس الجواب

“GPT-6 سيحل هذا.”

لن يحل. المشكلة ليست ذكاء النموذج — إنها الوسيط.

الشفرة كوسيط لا تميز القرارات عن التنفيذ. أي نموذج يقرأ الشفرة يرى نصًا حيث القرارات والتفاصيل متشابكة. مهما كان النموذج ذكيًا، إذا لم يوفر الوسيط التمييز، لا يستطيع النموذج التمييز.

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

نموذج لغوي صغير يحرر SSOTs فقط، مع validate يقدم ملاحظات دقيقة عند كل خطأ، يمكنه الحفاظ على نفس سلامة القرارات التي يحققها نموذج أكبر بكثير يحرر شفرة خام. yongol يسد هذه الفجوة.

ابدأ

npx skills add park-jun-woo/yongol

ثبِّت skill yongol في وكيل الذكاء الاصطناعي الخاص بك (Claude Code، Cursor، Copilot وغيرها). يتعلم الوكيل سير العمل تلقائيًا عند التثبيت.

لاستخدام CLI مباشرة:

go install github.com/park-jun-woo/yongol/cmd/yongol@latest

git clone https://github.com/park-jun-woo/yongol && cd yongol
yongol validate examples/zenflow

0 errors, 0 warnings.

وجِّه ذكاءً اصطناعيًا إلى هذه المواصفات واطلب منه إضافة ميزة. validate يضع السكة؛ والذكاء الاصطناعي يجري عليها. لا يوجد جدار.

مقالات ذات صلة

• SSaC — Service Sequences as Code — DSL حجر الأساس في yongol. يُصرِّح القرارات داخل نقاط النهاية.
• Feature Chain — تتبع Full Stack بـ operationId واحد — تتبع جميع الطبقات الثمانية من خلال operationId واحد.
• Ratchet Pattern — كيف تجعل الوكيل يُنهي المهمة — الأساس النظري لكيفية تغذية validate الراجعة للوكلاء.

الشفرة: github.com/park-jun-woo/yongol