reins — להשאיר רק את הדומיין מ‑Quest CLI, ולהפוך את ה‑ratchet ל‑framework Image: AI generated

how-make-quest היה איך לבנות Quest CLI במו ידיך. מהו ratchet, איך מציבים gate, איך חוסמים cheese. תן מאמר אחד לסוכן ויוצא ממנו Go CLI מבוסס cobra.

אבל מה קורה כשבונים Quest CLI שני. כותבים מחדש את אותה מכונת מצבים חד‑כיוונית. כותבים מחדש את אותם scan/next/submit/status/export. כותבים מחדש את אותה נעילת PASS, אותה ירידה מונוטונית של remaining, אותו export ל‑JSONL. מה שמשתנה הוא רק ה‑gate האחד, אבל בכל פעם כותבים מחדש את כל השאר. זה מס ה‑boilerplate שגובה כל Quest נוסף שבונים.

הדפוס היה ניתן לשימוש חוזר. הקוד לא היה. reins סוגר את הפער הזה.

מה אינווריאנטי ומה דומיין

הניחו שני Quest CLI זה על זה והביטו בהפרש (差分) — הגבול חד.

אינווריאנטי (משותף לכל Quest)        דומיין (שונה בכל Quest)
─────────────────────────       ─────────────────────
ratchet: TODO→PASS בלתי הפיך       מהו Quest אחד
שלד פקודות: scan/next/submit…      מהי "עובדה"
אגרגציה לפי רמה: Fail/Review→verdict   איזה cheese צריך לחסום
התקדמות מתמידה·resumable
export: פליטה חד‑פעמית

הצד השמאלי הוא בדיוק מה ש‑how-make-quest הוכיח — בין אם הדומיין הוא שם חברה, endpoint או פונקציה, שן ה‑ratchet נתפסת באותו אופן. רק את הצד הימני האדם יודע. reins מספק את הצד השמאלי כ‑framework, ומשאיר לך רק את הצד הימני.

זו אינה טענה חדשה אלא עיקרון ותיק ש‑reins אוכף בקוד — הפרדת ההכרעה מהמימוש. ה‑gate הוא ההכרעה (מהו האמת בדומיין הזה), וה‑ratchet, ה‑CLI והאגרגציה הם מימוש. לכתוב מחדש את המימוש בכל פעם הוא כשל של כבילת ההכרעה למימוש.

מממשים רק gate אחד

לבנות Quest עם reins פירושו למלא ארבע מתודות של interface אחד.

type Definition interface {
    Seed(args []string) ([]*quest.Item, error)            // קלט → seed של TODO ראשוני
    Render(it *quest.Item) (string, error)                // prompt הכתיבה + הקשר האימות ש‑next מציג
    Prepare(it *quest.Item, raw []byte) (gate.Context, *quest.Verdict, error) // פענוח ההגשה
    Rules() []gate.Rule                                   // קטלוג חוקי הפרת gate
}

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

שורת main אחת מספקת את ה‑ratchet, שש פקודות, אגרגציה, export ו‑session resumable במלואם. מה שכתבת הוא רק ארבעת חלקי הדומיין. הסוכן עדיין צריך להכיר רק שתי פקודות — מקבל ב‑next, מגיש ב‑submit. את השאר המכונה מכריעה.

ה‑gate הוא קטלוג של חוקי הגנה מפני cheese

לב how-make-quest היה “תכנן gate שלא ניתן ל‑cheese”. reins הופך את אותו תכנון למבנה נתונים — gate = קטלוג חוקים. חוק אחד הוא גלאי cheese אחד. כשהוא מגלה הפרה הוא נדלק (true) וטוען עובדה (Fact).

// חוק הגנה מפני cheese אחד של Quest לחילוץ אירועי חדשות.
// "האם עוגן ה‑who קיים באמת במקור" — אם הסוכן ימציא דמות, הוא ייחשף.
var whoAnchorPresent = gate.Rule{
    Meta: gate.RuleMeta{ID: "who-anchor-present", Level: gate.LevelFail, Desc: "עוגן ה‑who הנדרש קיים במקור"},
    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: "substring של המקור", Actual: miss[0]}
        }
        return false, quest.Fact{}
    },
}

מעלת המבנה הזה היא שהוא גדל. בכל פעם שמגלים cheese חדש מוסיפים חוק אחד וה‑gate מתחזק בהתאם. והקטלוג מתעד את עצמו — כשפקודת rules מדפיסה את רשימת החוקים, זוהי מיד “רשימת ביקורת של ה‑cheese שאני חוסם”. אין gate שלא יודעים מה הוא חוסם.

החומרה אינה משקל אלא רמה. Fail אחד פירושו מיד FAIL. הפרה מכרעת אינה ניתנת למשא ומתן — תשע הפרות בנות 99 נקודות אינן יכולות לכסות Fail אחד. Evaluate מאגרגג את החוקים שנדלקו לפי רמה: אם יש ולו Fail אחד — FAIL, אחרת אם יש Review — REVIEW, אם הכול עבר — PASS.

אוכפים את אסימטריית הסמכות בטיפוס

השורה החשובה ביותר ב‑how-make-quest הייתה “נעילת PASS רק למכונה”. reins מקבע זאת לא כמוסכמה אלא כטיפוס.

L1 מכונה (דטרמיניזם)   הסמכות היחידה לנעול PASS
L2 AI (ספקן)           REVIEW בלבד — מעלה חשד אך אינו מעניק השלמה
L3 אדם                 השארית ששניהם פספסו

gate המכונה מנפיק PASS. גם אם מכניסים verifier של AI ל‑gate, המקסימום שהוא יכול הוא להוציא ל‑REVIEW. הופכים את הדבר השגוי לבלתי אפשרי מלכתחילה — אם ה‑framework אינו מספק ל‑AI API שמעניק סמכות PASS, אי אפשר אפילו בטעות להפקיד את ההכרעה בידי חבר שיכור.

ה‑backend השני — defeat graph

יש הרבה gates שאגרגציה לפי רמה של חוקים בלתי תלויים מספיקה להם. אבל כשהחוקים מתחילים להתחרות זה בזה — “ההפרה הזו משמעותית רק כשקיימת ההפרה ההיא”, “השורש האמיתי של הכשל הזה הוא בעצם ההוא” — שומרי if-else כתובים ביד מכרסמים את ה‑gate. לא במקום שבו gate חלש נשבר, אלא במקום שבו gate מורכב נרקב.

ה‑backend השני של reins מעביר את התחרות הזו לגרף הצהרתי — toulmin h-Categoriser. מודל הטיעון של Toulmin הופך כמות שהוא למבנה נתונים:

  • Warrant — tautology PASS. הנימוק “אם אין הפרכה — עובר”.
  • Counter — הפרה תוקפת warrant.
  • Supersedes — קדימות בין חוקים. איזו הפרכה מנצחת איזו הפרכה.

סעיפי השומרים הכתובים ביד מתאדים לקשתות Attacks·Supersedes. וכאשר מספר הקשתות הוא 0, הגרף הזה שקול בדיוק לאגרגציה לפי רמה — המורכבות היא עלות שנדלקת רק בעת הצורך (opt-in) (היא נדלקת כש‑Definition מממש את gate.Evaluator).

המתנה האמיתית שהגרף נותן אינה ההכרעה אלא המשוב. הערכת הגרף מחזירה לסוכן מדריך פיצוח ישיר — Verdict.Feedback: “למה הפסדת, ומה לשנות כדי לנצח.” לא “FAIL” פשוט, אלא שורש שחושב ממבנה הטיעון.

כאן שוב פועל הפרדוקס של how-make-quest. המודל מחניף — מציית להוראות בצייתנות. בדעות החנופה היא רעל, אבל בעובדות החנופה היא נכס. מדריך הפיצוח אינו דעה (“זה קצת מוזר”) אלא עובדה (“who.anchors אינו קיים במקור, שנה את זה”). ככל שהמודל חנפן יותר, כך הוא מקבל את העובדה בצייתנות ומתכנס. defeat graph דטרמיניסטי + LLM חנפן = לולאה שבה ההתכנסות מובטחת.

מבודדים תופעות לוואי — הערכת ground ו‑staged

כדי שה‑gate יהיה דטרמיניסטי, אסור שהרשת תהיה בתוך ה‑gate. חוק שקורא ישירות ל‑net/http אינו ניתן לבדיקת יחידה, וההכרעה מיטלטלת לפי מצב הקו.

reins דוחף את תופעות הלוואי אל pkg/ground — פעולות פרימיטיביות כמו HTTPBody·MXResolves מחזיקות בשאילתות החיצוניות באמצעות Resolver מוזרק ו‑snapshot לכל בקשה. החוק נשאר טהור, והעולם החיצוני באחריות ground.

ובנוסף הערכת staged: הבדיקות הזולות רצות תחילה, ואם הן נכשלות — fetch הרשת פשוט לא קורה. אין סיבה לשאול DNS על הגשה שצורתה שגויה. מעמידים את היקר והמיטלטל מאחורי הזול והוודאי.

איסור הפשטה ב‑N=1

אחת ממוסכמות reins חושפת את אופי ה‑framework הזה במדויק — אל תחלץ הפשטה מצרכן יחיד. הפשטה חדשה מוקפאת רק לאחר שאומתה בצרכן שני.

זו אינה דקדקנות אלא עיקרון ראשון. הפשטה שחולצה ממקרה אחד טועה לראות את מקריות אותו מקרה כמהות. רק כשהדומיין השני דורש את אותה הפשטה — אז מוכח שהיא אינווריאנטית. ה‑framework מיישם “אימות ולא טענה” אפילו על האבולוציה של עצמו. כשם שה‑gate אינו מאמין לטענת הסוכן, ההפשטה אינה מאמינה לטענת מקרה אחד.

אותו משפט, הופך לספרייה

reins עומד על שבע חבילות ב‑pkg/ — textmatch (פרימיטיב חסימת הזיות), temporal (נרמול זמן), quest (ליבת ה‑ratchet), gate (חוזה ה‑gate), graph (defeat graph), ground (בידוד רשת), cli (scaffold של cobra). עובר go build·go test, מכסה את כל הפונקציות. ו‑toulmin צמוד באופן חד‑כיווני רק ל‑backend הגרף, כך שצרכן שאינו משתמש בגרף אפילו אינו מקשר את toulmin.

קוד: github.com/park-jun-woo/reins

אם how-make-quest היה משפט אחד — הייצור יכול להיות הסתברותי, האימות חייב להיות דטרמיניסטי — reins הקשיח את אותו משפט לצורה ניתנת לקומפילציה. ה‑gate מאמת מחדש את עובדות הדומיין, ה‑ratchet נועל את מה שעבר, הגרף מחזיר את סיבת ההפסד כעובדה, והמודל החנפן מציית לאותה עובדה.

בפעם הבאה שתזדקק ל‑Quest CLI, אל תכתוב מחדש את ה‑ratchet. כתוב רק את ה‑gate של הדומיין, ואת הרסן — שאל.

חומר נוסף לקריאה

העיקרון ש‑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.” אותו עיקרון כמו ה‑gate שמאמת מחדש את העובדה ולא את הטענה של הסוכן.

ושורשי ה‑backend של defeat graph הם בתורת הטיעון — שושלת Toulmin·Dung·Amgoud במקורות שלהלן. ה‑pkg/graph של reins מעביר לוגיקה פורמלית בת יותר מ‑60 שנה למבנה נתונים ב‑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. — המקור של ה‑framework המופשט לטיעון ושל גרף ה‑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. השורש הפורמלי של רמות החוק (Fail/Review) ושל קדימות ה‑Supersedes ב‑reins.
  • Modgil, S. & Prakken, H. (2014). “The ASPIC+ Framework for Structured Argumentation: A Tutorial.” Argument & Computation, 5(1), 31–62. — מערכת טיעון שמבנה את הסיווג של Nute בתוך ה‑framework של 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 מעביר זאת להכרעת gate.
  • 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 — ככל שהיכולת גבוהה יותר, כך נמצאים פרצות ה‑gate טוב יותר → הסיבה ש‑gate=קטלוג חוקים צריך לגדול.
  • Thaman, K. (2026). “Reward Hacking Benchmark: Measuring Exploits in LLM Agents with Tool Use.” arXiv:2605.02964 — הקשחה מכוונת של ה‑gate צמצמה את ה‑exploit ב‑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: מהדורה ראשונה