مولَّد من إصدار Techstack v0.32.8 (المصدر
4c7d219a5d56). بالنسبة إلى إصدار مثبَّت، فإن techstack api <command> --help هو المرجع.techstack api stacks create
إنشاء نشر StackKit في Homelab المالك. ينشئ نشر StackKit داخلياً تحت Homelab الوحيد لمالك B2C المصادَق عليه، من حمولة stack-spec القياسية لـ StackKits المقدَّمة بوصفهاstack_spec. يحدد المسار القديم /stacks وحقل الاستجابة stack_id هذا النشر؛ ولا ينشئان منتج Homelab ثانياً ولا يختارانه. يمكن لمثيل TechStack واحد أن يخدم مالكين كثيرين، لكل منهم Homelab خاص به. تظل حمولات user_config/kombination القديمة مقبولة عند حد التوافق هذا. ينبغي لعملاء المعالج إرسال X-Idempotency-Key ثابت؛ وتُرجع إعادات المحاولة بالمفتاح والحمولة نفسيهما النشر الأصلي والخادم المخطط ومهمة التجهيز.
techstack api stacks deploy
طرح نشر StackKit واحد (unify + IaC + tofu apply).techstack api stacks destroy
إخراج نشر StackKit واحد وبنيته التحتية من الخدمة.techstack api stacks drift check
تشغيل فحص الانحراف. محدود بمرة واحدة كل 5 دقائق (ما لم يكن force=true)techstack api stacks drift details
جلب معلومات مفصلة عن الانحراف مع الموارد المتأثرة.techstack api stacks drift resolve
تشغيل معالجة الانحراف (re-apply). شرط مسبق — يجب أن تكون حالة الـ stack هي “drifted”techstack api stacks drift status
جلب حالة الانحراف الحالية.techstack api stacks export
تصدير الـ stack بصيغة stack-spec.yaml. يُرجع stack-spec الخاصة بـ StackKits بصيغة YAML أو JSON حسب ترويسة Accepttechstack api stacks import
استيراد stack-spec.yaml كنشر StackKit. يستورد YAML أو JSON كنشر تحت Homelab المالك المصادَق عليه.techstack api stacks intent
جلب kombination.yaml المحفوظ (مطابق بايتاً ببايت، base64).techstack api stacks list
عرض عمليات نشر StackKit التابعة للمالك. يُرجع كل عمليات نشر StackKit تحت Homelab الوحيد لمالك B2C المصادَق عليه.kit_deployment_id وhomelab_id وstackkit_id هي هويات المنتج؛ وتبقى المعرّفات القديمة أسماء بديلة للتوافق على هذا المسار ريثما ينتقل المستهلكون.
techstack api stacks managed-runtimes add
إضافة عقدة مُدارة واحدة عبر التحكم الأصلي لدى المزوّد. ينشئ أو يستأنف مهمة Add-Server حتمية واحدة لنشر StackKit المملوك المحدد. مفتاحIdempotency-Key القياسي إلزامي. تُرجع إعادة إرسال المفتاح نفسه مع الطلب القياسي نفسه ارتباطات المهمة وعقد الإيجار وخادم وقت التشغيل وجيل الموارد وعملية المزوّد الأصلية؛ وتفشل إعادة استخدامه بنية مختلفة بالرمز 409.
لا يُحفظ المفتاح الخام ولا يُرجَع أبداً. لا يمكن استئناف استجابة مفقودة أو نتيجة قبول أصلي غير مؤكدة إلا بالمفتاح نفسه. يعني قبول HTTP أن القبول الأصلي دائم وأن المطابقة لدى المزوّد معلّقة؛ ولا يدّعي أبداً أن الـ VM قد جُهّزت بالفعل أو أنها سليمة. يحجز القبول الجديد بشكل ذرّي خانة سعة المستأجر/المالك المصادَق عليه مع جيل عقد الإيجار وعملية المزوّد. وعندما يجد القبول الأصلي المرجعي أن تلك السعة المحدودة ممتلئة، يحفظ نتيجة 403 غير قابلة لإعادة المحاولة، وتُرجع إعادة تشغيل تلك المهمة المرفوضة النتيجة نفسها. تعيد عمليات الإعادة الدقيقة لقبول مُلتزَم به مسبقاً استخدام حجزه القائم. لا يوجد في هذا الإصدار تحرير تلقائي للحجز: فحالة الإخراج من الخدمة النهائية أو المحلية وحدها لا تحرر خانة. لا يفوّض جرد عقود الإيجار وأعلام feature-delivery السعة ولا يرفضانها أبداً. يتطلب القبول الجديد المستضاف أيضاً استحقاقات وقت التشغيل التجاري والمزوّد الموقَّعة بإصدار v2، إضافة إلى قرار الوضع/الحد الموقَّع cloud.runtime.credits managed_servers؛ ولا تمنح أعلام الميزات وحدها سعة لدى المزوّد أبداً. يستخدم Self-host OSS سياسة بيان الإصدار الثابتة المحددة عند البناء بدلاً من الاعتماد على استحقاق SaaS.
techstack api stacks operations
جلب نموذج قراءة العمليات بعد التهيئة لنشر StackKit مملوك واحد. يُرجع نموذج القراءة الدقيق المحصور بالمالك والمستأجر الذي تستخدمه لوحة عمليات TechStack. يسجّلapproved_servers موافقة المشغّل؛ أما connected_servers فأكثر صرامة ولا يحتسب إلا العقد المعيَّنة الموافق عليها التي لديها أدلة قياسية موسومة بحداثتها على نبض Guard واتصاله وحالته الصحية. العملية للقراءة فقط ولا تبدأ أبداً طرحاً أو تجهيزاً أو عملاً لدى المزوّد.
techstack api stacks owner-spec
جلب مواصفة تمهيد المالك لنشر StackKit. نقطة نهاية admin-bootstrap في StackKit لجلب حقول المالك المحلي وتجزئة عبارة مرور الاسترداد. لا يقبل هذا المسار إلا رمز bearer للتمهيد قصير العمر الذي يُرجعهcreateStack؛ ولا يستخدم رمز bearer العادي للمتصفح/الجلسة.
techstack api stacks pipeline-status
جلب حالة خط المعالجة الكاملة لكل مراحل المواصفة.techstack api stacks provision
بدء تجهيز نشر StackKit قائم.techstack api stacks prune-orphans
مراجعة تنظيف بقايا الاختبار المحصور بالمالك أو تطبيقه. تنظيف على مرحلتين لإسقاطات مستوى التحكم فقط. يُرجعdry_run المرشحين الدقيقين من E2E/runtime-cloud للمالك المصادَق عليه وملخصاً ثابتاً مرتبطاً بالمراجعة. يعيد apply حساب الخطة ولا يقبل إلا ذلك الملخص بعينه. لا يُخرج هذا المسار أبداً عقد إيجار من الخدمة ولا يستدعي مزوّداً ولا يهدم بنية تحتية ولا يضع أعمال دورة حياة في الطابور.
techstack api stacks requirements
جلب مواصفة المتطلبات (مُخرج المرحلة 1).techstack api stacks resume-enrollment
استئناف انتظار متأخر لعقدة مُدارة على الـ VM القائمة المحددة الخاصة بها. استرداد مصادَق عليه وغير متغير النتيجة (idempotent) لمهمة محفوظة في الحالةwaiting_enrollment أو waiting_provider_provision أو waiting_canonical_guard تجاوز موعد next_resume_at الخاص بها فترة السماح المحدودة. يتحقق الخادم من نشر StackKit المملوك والمهمة المصدر وسبب الانتظار وعقد الإيجار الدقيق ودور الأساس النشط والعقدة القياسية كعملية واحدة. وهو ينهي بشكل ذرّي الانتظار المصدر المحدد، وينشئ أو يعيد بناء عملية نشر بديلة حتمية واحدة مرتبطة بعقد الإيجار والعقدة نفسيهما، ويعيد تشغيل تلك المهمة في الاستدعاءات اللاحقة. قبل الدخول إلى المعالج، يحصل عمّال الطابور بشكل ذرّي على مطالبة التنفيذ التوافقية الدائمة tenant/stack؛ وهذا يسلسل المهام المختلفة لنشر StackKit نفسه عبر نسخ Techstack المتماثلة. تبقى المطالبة دائمة في الحالة running حتى يخرج المعالج، بما في ذلك أثناء الإلغاء. لا تستدعي نقطة النهاية هذه أبداً إنشاء VM لدى المزوّد ولا تختار VM أحدث. البديل الذي يُعثر عليه دائماً في الحالة running بعد انهيار يبقى مغلقاً عند الفشل، ويُبلَّغ عنه بوصفه المهمة نفسها، ولا يُكرَّر تلقائياً أبداً؛ وتبقى مطابقة إجراءات وقت التشغيل شأناً منفصلاً للمشغّل.
techstack api stacks retry-rollout
إعادة محاولة طرح فاشل لنشر StackKit واحد على الـ VM المُدارة القائمة المحددة الخاصة به. يتحقق من عملية النشر الفاشلة المملوكة وعقد إيجار الأساس النشط الدقيق الخاص بها والعقدة القياسية في عملية واحدة على جانب الخادم. يتجاوز البديل الدائم الحتمي إنشاء VM لدى المزوّد، ويفوز بمطالبة التنفيذ التوافقية الدائمةtenant/stack قبل الدخول إلى المعالج، ويُعاد تشغيله عند تكرار استدعاء هذه العملية. تسلسل المطالبة المهام المختلفة لنشر StackKit نفسه عبر النسخ المتماثلة، وتبقى مغلقة عند الفشل بالحالة running بعد انهيار العملية حتى يطابقها المشغّل.
techstack api stacks routing ensure
ضمان طبقة التوجيه المرغوبة لنشر StackKit وعقدة محددين. يحفظ بشكل ذرّي طبقة توجيه ذات مراجعات وغير متغيرة النتيجة (idempotent) دون تعديل نية المستخدم غير القابلة للتغيير. server_id دقيق وإلزامي دائماً. lease_id إلزامي لأوقات التشغيل المُدارة ويُحذف لوقت تشغيل محلي/Basement ليس له عقد إيجار. بالنسبة إلى هدف مُدار، لا يُطلق طلب ensure_rollout بقيمة true خط النشر القائم إلا بعد إثبات أن عقد إيجار الأساس النشط المختار والعقدة القياسية يساويان هذا الهدف بعينه. لا تُبلغ API أبداً عن المهمة الناتجة بوصفها مطبَّقة بالفعل. لا تُستهلك الطبقة إلا أثناء اشتقاق مخرجات StackKits، ولا ينشئ هذا المسار أبداً VM بديلة ولا يختارها.techstack api stacks routing get
قراءة حالة التوجيه المرغوبة والمرصودة لنشر StackKit واحد. يُرجع طبقة التوجيه المرتبطة بالمستأجر والمالك لنشر StackKit المحدد. يُبلَّغ عن الحالة المرغوبة والحالة المرصودة/المطبَّقة بشكل منفصل، كي لا يستنتج العملاء أبداً نجاح DNS أو TLS أو طرح StackKit من مجرد الحفظ.techstack api stacks routing targets
عرض أهداف التوجيه الأساسية الصريحة لنشر StackKit واحد. اكتشاف للقراءة فقط مدعوم بسلطة RuntimeLease النشطة. يُرجع كل هدف أساس/مستوى تحكم مرئي للمالك، ولا يختار أبداً أحدها أو ينشئ إسقاط عقدة قياسية (ServerRuntime) أو يعدّل نشر StackKit. يجب على المستدعين إرسال الزوج الكامل server_id وlease_id إلى أي تعديل للتوجيه.