reins — لا يبقى من Quest CLI سوى النطاق، والـ ratchet يصير إطارًا Image: AI generated

كان how-make-quest طريقةَ بناء Quest CLI بيديك العاريتين. ما هو الـ ratchet، كيف تركّب البوابة، كيف تصدّ الـ cheese. أعطِ الوكيلَ مقالًا واحدًا فيخرج منه Go CLI قائم على cobra.

لكن ماذا يحدث حين تبني الـ Quest CLI الثاني؟ تعيد كتابة آلة الحالة أحادية الاتجاه نفسها. تعيد كتابة scan/next/submit/status/export نفسها. تعيد كتابة قفل PASS نفسه، وتناقص remaining الرتيب نفسه، وexport بصيغة JSONL نفسه. لا يتغيّر سوى بوابة واحدة، ومع ذلك تعيد في كل مرة كتابة كل ما عداها. هذه هي ضريبة الـ boilerplate التي تدفعها كلما بنيت مهمة أخرى.

كان النمط قابلًا لإعادة الاستخدام. أما الكود فلا. يسدّ reins تلك الفجوة.

ما الثابت وما النطاق

ضع مهمتي CLI إحداهما فوق الأخرى وانظر إلى الفرق (الـ diff)، فيغدو الحدّ بيّنًا.

الثابت (تشترك فيه كل المهام)        النطاق (يختلف من مهمة لأخرى)
─────────────────────────       ─────────────────────
ratchet: TODO→PASS لا رجعة        ما الذي يساوي مهمة واحدة
هيكل الأوامر: scan/next/submit…    ما هي "الحقيقة"
تجميع المستويات: Fail/Review→verdict   أي cheese يجب صدّه
استمرار التقدّم·resumable
export: إصدار لمرة واحدة

اليسار كما أثبته how-make-quest تمامًا — سواء كان النطاق اسمَ شركة أو نقطة نهاية أو دالة، تتعشّق أسنان الـ ratchet على النحو ذاته. ولا يعرف الإنسان سوى اليمين. يُورّد reins اليسار بوصفه إطارًا، ويترك لك اليمين وحده.

ليس هذا ادّعاءً جديدًا، بل مبدأ قديم يفرضه reins بالكود — فصل القرار عن التنفيذ. البوابة هي القرار (ما الحق في هذا النطاق)، والـ ratchet والـ CLI والتجميع هي التنفيذ. إعادة كتابة التنفيذ في كل مرة فشلٌ يربط القرار بالتنفيذ.

لا تُنفّذ سوى بوابة واحدة

أن تصنع مهمة بـ reins يعني أن تملأ الدوال الأربع لواجهة واحدة.

type Definition interface {
    Seed(args []string) ([]*quest.Item, error)            // المدخلات ← بذور TODO الأولية
    Render(it *quest.Item) (string, error)                // مُوجِّه الكتابة وسياق التحقق الذي يعرضه next
    Prepare(it *quest.Item, raw []byte) (gate.Context, *quest.Verdict, error) // فكّ ترميز التسليم
    Rules() []gate.Rule                                   // كتالوج قواعد خرق البوابة
}

func main() { cli.NewQuestCmd("myquest", myDef{}, cli.Options{}).Execute() }

سطر main واحد يُورّد كل شيء — الـ ratchet والأوامر الستة والتجميع وexport وجلسة resumable. كل ما كتبته أربع قطع من النطاق. ولا يزال الوكيل يكفيه معرفة أمرين فقط — يتلقّى بـ next ويُسلّم بـ submit. والباقي تقرّره الآلة.

البوابة كتالوج قواعد صدّ الـ cheese

كان جوهر how-make-quest هو «صمّم بوابة يستحيل الـ cheese عليها». يجعل reins ذلك التصميم بنية بيانات — البوابة = كتالوج قواعد. القاعدة الواحدة كاشف cheese واحد. حين تكتشف خرقًا تنطلق (true) وتحمل حقيقة (Fact).

// قاعدة واحدة من قواعد صدّ الـ cheese في مهمة استخراج أحداث الأخبار.
// "هل يوجد who-anchor فعلًا في النص الأصلي" — إن اختلق الوكيل شخصًا انكشف.
var whoAnchorPresent = gate.Rule{
    Meta: gate.RuleMeta{ID: "who-anchor-present", Level: gate.LevelFail, Desc: "وجود who-anchor الإلزامي في النص الأصلي"},
    Check: func(ctx gate.Context) (bool, quest.Fact) {
        sub := ctx.Submission.(*Event)
        if miss := textmatch.MissingTokens(ctx.Source, sub.Who.Anchors); len(miss) > 0 {
            return true, quest.Fact{Where: "who.anchors", Expected: "مقطع فرعي من النص الأصلي", Actual: miss[0]}
        }
        return false, quest.Fact{}
    },
}

فضيلة هذه البنية أنها تنمو. كلما اكتشفت cheese جديدًا أضفت قاعدة واحدة فيصلب جدار البوابة بقدرها. والكتالوج يوثّق نفسه — حين يطبع أمر rules قائمة القواعد، فتلك بعينها «قائمة تدقيق بالـ cheese الذي أصدّه». لا توجد بوابة تجهل ما تصدّه.

الخطورة ليست وزنًا بل مستوى. Fail واحد يعني FAIL فورًا. الخرق الحاسم لا يُتفاوَض عليه — لا تستطيع تسعةُ خروق بتسعة وتسعين نقطة أن تغطّي خرق Fail واحد. يجمّع Evaluate القواعد المنطلقة بحسب المستوى: إن وُجد Fail واحد فـ FAIL، وإلا فإن وُجد Review فـ REVIEW، وإن مرّ الكل فـ PASS.

فرض عدم تماثل السلطة بالنوع

أهمّ سطر في how-make-quest كان «قفل PASS للآلة وحدها». يثبّت reins هذا لا بوصفه عُرفًا بل نوعًا.

L1 آلة (حتمية)    السلطة الوحيدة لقفل PASS
L2 ذكاء اصطناعي (متشكّك)    REVIEW فقط — يثير الشك دون أن يمنح الإنجاز
L3 إنسان           البقايا التي فاتتهما معًا

البوابة الآلية تُصدر PASS. وحتى لو أدخلت مدقّقًا بالذكاء الاصطناعي في البوابة، فأقصى ما يستطيعه إخراجها إلى REVIEW. يجعل العملَ الخاطئ مستحيلًا من الأساس — فإن لم يُتِح الإطار للذكاء الاصطناعي API يمنحه سلطة PASS، لم تستطع ولو خطأً أن تُوكِل الحكم إلى صديق سكران.

الواجهة الخلفية الثانية — defeat graph

كثير من البوابات يكفيها تجميع مستويات قواعد مستقلة. لكن حين تبدأ القواعد تتزاحم — «هذا الخرق لا معنى له إلا بوجود ذاك»، «السبب الجذري لهذا الفشل في الحقيقة ذاك» — تأكل حُرّاس الـ if-else المكتوبة باليد البوابةَ. لا تتعفّن البوابة الضعيفة، بل تتعفّن البوابة المعقّدة.

تنقل الواجهة الخلفية الثانية في reins هذا التزاحم إلى graph تصريحي — toulmin h-Categoriser. يصير نموذج Toulmin للحجاج بنية بيانات كما هو:

  • Warrant — tautology PASS. أساس «إن لم يوجد دحض فالمرور».
  • Counter — الخرق يهاجم الـ warrant.
  • Supersedes — أولوية بين القواعد. أيّ دحض يغلب أيّ دحض.

تتبخّر بنود الحُرّاس المكتوبة باليد إلى حواف Attacks·Supersedes. وإن كانت الحواف صفرًا فهذا الـ graph مكافئ تمامًا لتجميع المستويات — التعقيد كلفة تُشغَّل عند الحاجة فقط (opt-in) (تُشغَّل حين يُنفّذ Definition واجهة gate.Evaluator).

والهدية الحقيقية للـ graph ليست الحكم بل التغذية الراجعة. يعيد تقييمُ الـ graph للوكيل دليلَ خطّة مباشرًا — Verdict.Feedback: «لماذا خسرتَ، وبتغيير ماذا تربح.» ليس مجرد «FAIL» بل سبب جذري مُحتسَب من بنية الحجاج.

وهنا تعمل مفارقة how-make-quest من جديد. النموذج يتملّق — يتبع التعليمات طوعًا. التملّق سمّ في الرأي، لكن التملّق أصل في الحقيقة. دليل الخطّة ليس رأيًا («يبدو غريبًا») بل حقيقة («who.anchors غير موجود في الأصل، غيّر هذا»). وكلما كان النموذج أكثر تملّقًا قبل تلك الحقيقة طوعًا وتقارب. graph حتمي + LLM متملّق = حلقة مضمونة التقارب.

اعزل الآثار الجانبية — تقييم ground وstaged

كي تكون البوابة حتمية يجب ألّا تكون الشبكة داخل البوابة. القاعدة التي تستدعي net/http مباشرة يستحيل اختبارها وحدةً، ويتذبذب حكمها تبعًا لظرف الخط.

يحشر reins الآثار الجانبية في pkg/ground — عمليات أوّلية كـ HTTPBody·MXResolves تملك الاستعلامَ الخارجي عبر Resolver حقني ولقطة (snapshot) لكل طلب. تبقى القاعدة نقية، ويتحمّل ground مسؤولية العالم الخارجي.

ثم تقييم staged: تجري الفحوص الرخيصة أولًا، وإن فشلت فإن جلب الشبكة (fetch) لا يحدث أصلًا. لا داعي لاستعلام DNS على تسليم خاطئ الشكل. ضع الغالي المتذبذب خلف الرخيص الأكيد.

ممنوع التجريد عند N=1

أحد أعراف reins يكشف طبيعة هذا الإطار بأدقّ صورة — لا تستخرج تجريدًا من مستهلك واحد. لا يُجمَّد التجريد الجديد إلا بعد التحقق منه بمستهلك ثانٍ.

ليس هذا تزمّتًا بل مبدأ أوّليًا. التجريد المستخرَج من حالة واحدة يخلط بين عَرَض تلك الحالة وجوهرها. لا يُثبَت أنه ثابت إلا حين يطلبه نطاق ثانٍ بعينه. يطبّق الإطارُ «لا ادّعاء بل تحقق» حتى على تطوّره الذاتي. كما لا تصدّق البوابةُ ادّعاءَ الوكيل، لا يصدّق التجريدُ ادّعاءَ حالة واحدة.

الجملة نفسها، وقد صارت مكتبة

يقوم reins على سبع حزم في pkg/ — textmatch (عملية أوّلية لصدّ الهلوسة)، temporal (تطبيع زمني)، quest (نواة الـ ratchet)، gate (عقد البوابة)، graph (defeat graph)، ground (عزل الشبكة)، cli (سقالة cobra). يجتاز go build·go test، بتغطية كل الدوال. وtoulmin مقترن أحادي الاتجاه بالواجهة الخلفية للـ graph وحدها، فالمستهلك الذي لا يستعمل الـ graph لا يربط toulmin أصلًا.

الكود: github.com/park-jun-woo/reins

إن كان how-make-quest جملةً واحدة — قد يكون التوليد احتماليًا، لكن التحقق يجب أن يكون حتميًا — فإن reins هو تصليبُ تلك الجملة في صورة قابلة للترجمة (compile). تعيد البوابة التحقق من حقيقة النطاق، ويقفل الـ ratchet ما مرّ، ويعيد الـ graph سبب الخسارة بوصفه حقيقة، وينقاد النموذج المتملّق لتلك الحقيقة.

في المرة القادمة حين تحتاج Quest CLI، لا تعد كتابة الـ ratchet. استعمل بوابة النطاق وحدها، واستعِر العِنان.

مقالات للقراءة معًا

المبدأ الذي صلّبه reins بالكود — التوليد احتمالي، والتحقق حتمي — ليس اكتشاف reins وحده. أناس لا يعرف بعضهم بعضًا اصطدموا بالجدار نفسه فوصلوا إلى الخلاصة نفسها. مشاريع التقارب المستقل التي جمعها how-make-quest دليل على ذلك.

  • episteme — يفرض Reasoning Surface قبل عمل لا رجعة فيه. الحدس نفسه لـ ratchet في reins — يُتحقَّق من PASS قبل قفله.
  • MagLab — «نموذج LLM للاستدلال فقط، والأرقام لأداة حتمية.» الفصل نفسه الذي يعزل به reins الآثار الجانبية في pkg/ground.
  • Manifesto — «Agent proposes, World verifies.» يلخّص في جملة واحدة عدم تماثل السلطة في reins (L1 وحده يقفل PASS).
  • oh-my-kamisama — «diffs beat claims.» المبدأ نفسه — تعيد البوابة التحقق من حقيقة الوكيل لا من ادّعائه.

وجذر الواجهة الخلفية للـ defeat graph هو نظرية الحجاج — سلسلة Toulmin·Dung·Amgoud في المراجع أدناه. نقل pkg/graph في reins ذلك المنطقَ الصوري الذي تجاوز عمره الستين عامًا إلى بنية بيانات بلغة Go.

المراجع

  • Toulmin, S. (1958). The Uses of Argument. Cambridge University Press. — نموذج الحجاج الذي اقتُبس منه Warrant·Ground·Backing في defeat graph حرفيًا.
  • Dung, P.M. (1995). “On the Acceptability of Arguments and its Fundamental Role in Nonmonotonic Reasoning, Logic Programming and n-Person Games.” Artificial Intelligence, 77(2), 321–357. — أصل إطار الحجاج المجرّد وgraph الـ attack (defeat).
  • Amgoud, L. & Ben-Naim, J. (2013). “Ranking-based semantics for argumentation frameworks.” SUM 2013, LNCS 8078, 134–147. — weighted h-Categoriser الذي تبنّاه pkg/graph. خاصية Compensation التي يستعيد بها العقدُ المهاجَم درجةَ قبوله إن دُوفِع عنه ثانية، وضمان التقارب.
  • Nute, D. (1994). “Defeasible Logic.” In Handbook of Logic in Artificial Intelligence and Logic Programming, Vol. 3. Oxford University Press. — تصنيف strict/defeasible/defeater. الجذر الصوري لمستوى قواعد reins (Fail/Review) وأولوية Supersedes.
  • Modgil, S. & Prakken, H. (2014). “The ASPIC+ Framework for Structured Argumentation: A Tutorial.” Argument & Computation, 5(1), 31–62. — منظومة حجاج تُبنين تصنيف Nute داخل إطار Dung. نسب الـ defeat graph.
  • Gabriel, V.O. et al. (2020). “Reasoning in BDI agents using Toulmin’s argumentation model.” Theoretical Computer Science, 805, 76–91. — سابقة لتطبيق نموذج Toulmin برمجيًا (وكلاء BDI). ينقل pkg/graph في reins هذا إلى حكم البوابة.
  • Von Neumann, J. (1956). “Probabilistic Logics and the Synthesis of Reliable Organisms from Unreliable Components.” Automata Studies, Princeton University Press. — مبدأ رفع بروتوكول موثوق فوق أجزاء غير مستقرّة (مقدّمة reins).
  • Stechly, K., Valmeekam, K., & Kambhampati, S. (2024). “On the Self-Verification Limitations of Large Language Models.” arXiv:2402.08115 — التحقق الذاتي بالكاد يرفع الأداء ← لماذا يجب وضع سلطة PASS في آلة L1.
  • McKee-Reid, L. et al. (2024). “Honesty to Subterfuge: In-Context RL Can Make Honest Models Reward Hack.” arXiv:2410.06491 — حتى النموذج الصادق يتلاعب إن حكم على مكافأته الذاتية ← أساس عدم تماثل السلطة.
  • Bondarenko, A. et al. (2025). “Demonstrating Specification Gaming in Reasoning Models.” arXiv:2502.13295 — كلما ارتفعت القدرة أحسن إيجاد ثغرة البوابة ← لماذا يجب أن ينمو كتالوج قواعد البوابة.
  • Thaman, K. (2026). “Reward Hacking Benchmark: Measuring Exploits in LLM Agents with Tool Use.” arXiv:2605.02964 — جعل البوابة صلبة عمدًا خفّض عمليات الاستغلال 87.7%.
  • Fanous, A. et al. (2025). “SycEval: Evaluating LLM Sycophancy.” AAAI/ACM AIES 2025. arXiv:2502.08177 — قياس معدل الاستسلام للتملّق. وجها «التملّق أصل في الحقيقة».
  • Shapira, I. et al. (2026). “How RLHF Amplifies Sycophancy.” arXiv:2602.01002 — نظرية أن RLHF يضخّم التملّق. مقدّمة حلقة التقارب: تغذية راجعة حقيقية + تملّق.
  • Deque Systems (2021). “Automated Testing Study Identifies 57 Percent of Digital Accessibility Issues.” — حدّ بين النطاق القابل للحكم الآلي (57%) وبقايا الإنسان (20%).

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

سجل التغييرات

  • 2026-06-05: الإصدار الأول