Solo-Engine V4.1 Final: פחות חפיפת כללים, יותר גבולות אמת

פסק הדין

V4 היא תצורה נכונה בכיוון, אך לא מומלצת לפריסה כפי שהיא. היא כבר מטפלת בכשלי אמינות מהותיים: היא אוסרת להמציא חיפושים, קריאות לכלים, קומפילציה או בדיקות; מפרידה בין קוד מלא לבין קוד שאומת בפועל; ומונעת קידום של ADR למצב מאושר בלי ראיות.

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

לכן הבחירה המומלצת היא Solo-Engine V4.1 Final: לשמר את מחזור המחקר–החלטה–הנדסה של V4, אך לרכז את כללי האמת שאינם נתונים לפשרה בהוראת-העל, ולהעביר נהלי עבודה ותבניות מפורטות לבסיס הידע.

מה V4 עושה היטב

• מפרידה בין /ana-solo לניתוח, מחקר וקבלת החלטות, לבין /ana-bmad ליישום הנדסי ואימות.
• מחייבת הפרדה אפיסטמית בין FACT, INFERENCE, ASSUMPTION ו-UNKNOWN.
• מבהירה שאסור להציג יכולות חיפוש, מערכת קבצים, Git, הרצת קוד או בדיקות כאילו בוצעו אם אין כלי אמיתי שמבצע אותן.
• מפרידה בין מסירת קוד מלאה לבין טענה שקומפילציה ובדיקות עברו בפועל.
• מוסיפה מנגנוני בטיחות שימושיים: זיהוי סוג משימה, Algorithm-Fit, Preflight, לחץ-נגד במקרה של כישלון ו-State Reconcile.
• מתייחסת ל-ADR כאל תוצר החלטה בעל מחזור חיים, ולא כאל מסמך קישוט.
• מאפשרת מסירה מפוצלת של קוד ארוך, אך רק בגבולות קבצים מלאים — בלי לקטוע קובץ באמצע.
• מציגה את BMAD כתזמור תפקידי ביקורת בתוך Gem יחיד, ולא כטענה מטעה שכמה סוכנים עצמאיים רצו באמת. תיעוד BMAD אכן מתאר סוכנים, Skills, Workflows ומסלולי בדיקה כמנגנוני הפעלה מובחנים; לכן Gem יחיד צריך להיקרא תזמור תפקידים בהשראת BMAD, ולא תחליף שקול ל-runtime מרובה סוכנים. 11014

התיקונים החיוניים ב-V4.1

1. הוראת-העל חייבת לעמוד בפני עצמה

אין להניח שכל קובץ בבסיס הידע יאוחזר במלואו בכל תשובה. לכן הכללים הקריטיים חייבים להופיע גם בהוראת-העל:

• אין להמציא פעולות כלי או תוצאות אימות.
• קוד מלא אינו הוכחה לקומפילציה מוצלחת.
• מסירה אינה השלמה הנדסית.
• אין לנחש ממשקים חסרים בפרויקט קיים.
• אין להרחיב הרשאה או יכולות מעבר למה שזמין בפועל.

2. „לולאה אוטומטית” היא לולאה תחומה בלבד

הנחיה לא יכולה להעניק ל-Gem תהליך רקע, מסוף מתמשך או עבודה לאחר שהמשתמש עזב. ב-V4.1 הלולאה מוגדרת רק במסגרת:

• התשובה או השיחה הנוכחית;
• ההרשאה המפורשת שניתנה;
• הכלים הזמינים בפועל;
• תקציב ניסיונות מוגדר;
• תנאי עצירה ברור.

אם אין מריץ קוד אמיתי, הסטטוס חייב להיעצר ב-WAITING_VERIFICATION.

3. „אפס תלויות” צריך להיות חוזה הנדסי

המונח אינו יכול לומר בו-זמנית „אין runtime”, „אין חבילות צד שלישי” ו„אין קבצים מקומיים חסרים”. ההגדרה הנכונה היא:

• אפס תלויות לא מוצהרות;
• ברירת מחדל של אפס תלויות צד שלישי חדשות;
• כל תלות מקומית חדשה נמסרת במלואה;
• runtime, SDK, מערכת הפעלה ופלטפורמת אירוח הם תנאי סביבה מפורשים.

4. „קוד מלא” תלוי בהקשר הפרויקט

בפרויקט חדש יש למסור את כל מעטפת הפרויקט המינימלית: תצורת build, נקודת כניסה, קובצי מקור, בדיקות, משאבים נדרשים ודוגמת תצורה שאינה רגישה.

בפרויקט קיים יש למסור במלואם כל קובץ חדש או שונה. אין צורך לשכפל קובצי בסיס שהמשתמש כבר מסר ולא השתנו; אבל אם חסר קובץ בסיס המשפיע על קומפילציה או על חוזה ציבורי, צריך לבקש אותו — לא להמציא אותו.

5. שלושה סטטוסים במקום „הושלם” אחד

V4.1 מפרידה בין:

• DELIVERY_STATUS — האם כל הקבצים הנדרשים נמסרו;
• VERIFICATION_STATUS — מה באמת הורץ ומה עבר;
• ENGINEERING_STATUS — האם מותר לטעון שהעבודה ההנדסית הושלמה.

כך נמנע מצב שבו קוד הוצג במלואו, ולכן בטעות מסומן כפתרון מאומת.

6. Tavily הוא מתאם יכולת, לא הבטחת יכולת

search_depth=advanced הוא פרמטר אמיתי של Tavily לחיפוש מדויק ומעמיק יותר, אך הוא כרוך בדרך כלל בהשהיה או עלות גבוהות יותר. לכן יש להשתמש בו רק כשכלי Tavily אכן מחובר וזמין, ובהתאם ל-schema האמיתי שלו. 2411

אם Tavily אינו זמין, יש להשתמש רק בחיפוש או בחומרים אחרים הזמינים בפועל ולציין במפורש את הירידה ביכולת. אסור לכתוב כאילו בוצע חיפוש advanced רק מפני שההנחיה מזכירה אותו.

7. „SEO” אינו שם נרדף למחקר ערך

ברירת המחדל צריכה להיות Value Extraction: זיהוי ראיות, משמעותן, הערך למשתמש, פעולה אפשרית ואופן אימות. ניתוח SEO של ממש צריך להתחיל רק כשהבקשה עוסקת במפורש במילות מפתח, זחילה, אינדוקס, דירוג, חשיפה או אופטימיזציית תוכן.

מטריצת החלטה

הציונים הבאים הם הערכת תצורה איכותנית במסגרת הביקורת הזו — לא benchmark של הרצת Gemini Gem בפועל.

ממד	משקל	V4	V4.1 Final
גבולות הרצה ואמינות כלים	25%	4.0	4.8
איכות התכנסות באמצעות קריאה בשלושה מעברים, DM ו-DR	20%	4.5	4.8
שסתומי בטיחות ולחץ-נגד בכשל	20%	4.6	4.8
קוד מלא וסגירת תלויות	15%	4.6	4.9
צפיפות הוראות ויכולת ציות	10%	2.8	4.5
שחזור מצב והתאמת ראיות	10%	4.2	4.7
ציון משוקלל	100%	84.2	95.5

החישוב הוא:

$$
Score = 20\sum_{i=1}^{n}w_i s_i,
\qquad
\sum_{i=1}^{n}w_i=1
$$

ההכרעה

• הבחירה: Solo-Engine V4.1 Final.
• חלופה שנייה: V4, כבסיס טוב לניסוי פנימי, אך לא כהגדרה ארוכת טווח ללא תיקון.
• השיפור המכריע: לא הוספת עוד חוקים, אלא צמצום כפילויות, הבהרת גבולות הריצה והפיכת הוראת-העל לעצמאית.
• תנאי לשינוי עתידי: אם יעברו ל-Gemini API Managed Agent, ל-MCP או לארגז חול מתמשך לקוד, יש להוסיף Runtime Adapter. אין להעמיס תיאורי כלים נוספים על הוראת-העל.

Deep Recon: טענת הנגד החזקה ביותר

אפשר לטעון ש-V4 כבר נוקשה מספיק, וש-V4.1 היא בעיקר ליטוש סגנוני.

הטיעון אינו משכנע. הבעיה ב-V4 אינה שלמות תאורטית, אלא הסיכוי לציות עקבי בפועל: אותן הגדרות מפוזרות בין הוראת-העל, הנהלים והתבניות. בתשובות ארוכות, כפילות כזו עלולה לגרום לפספוס סלקטיבי, לסתירת סטטוסים ולדחיקת הקוד עצמו מחלון הפלט.

הנחות נושאות עומס

• Gem עשוי לקרוא קבצי ידע שהועלו, אך אין להניח שכל פרט בהם יאוחזר בכל סבב.
• המשתמש מבקש תהליך Solo נשלט, לא טענה להפעלה בו-זמנית של סוכנים עצמאיים.
• בהיעדר סביבת הרצה, המשתמש מקבל את העובדה שאי אפשר להבטיח קומפילציה או בדיקות שעברו.
• שפת היעד, גרסת הכלים ובסיס הקוד יסופקו כחלק מהמשימה כשיהיו קריטיים.

חמישה מבחני כשל מינימליים

כל אחד מהמצבים הבאים יפריך את עקרונות התצורה וידרוש הקשחה נוספת:

1. אין מריץ קוד, אך המערכת טוענת שהבדיקות עברו.
2. חסר ממשק מקומי, אך המערכת ממציאה אותו וטוענת שהקוד מתקמפל.
3. תיקון באג משנה חתימה ציבורית בלי לשדרג ל-Preflight מבני.
4. המסירה נקטעת באמצע קובץ, אך DELIVERY_STATUS מסומן כ-COMPLETE.
5. Tavily לא זמין, אך המערכת טוענת שביצעה search_depth=advanced.

כיסוי מחקרי ומגבלות

נענה:

• מהן החוזקות, החפיפות וסיכוני ההפעלה של V4.
• כיצד יש לקשור Tavily Advanced ליכולת כלי אמיתית. 2411
• כיצד אפשר לאמץ תפקידי BMAD בתוך Gem יחיד בלי להציג זאת כ-runtime מרובה סוכנים. 11014
• כיצד קוד מלא, תלויות ואימות צריכים להפוך לחוזה שניתן לביקורת.

נותר פתוח:

• האם ל-Gem הספציפי יש בפועל חיבור ל-Tavily, מריץ קוד, MCP או סביבת קבצים מתמשכת.

נוסח סופי מומלץ לתצורה

הכותרת המומלצת היא Solo-Engine v4.1 Final. מבנה ההתקנה צריך לכלול הוראת-על אחת לניתוב, מגבלות קשות וגבולות יכולת; ולצדה קבצי ידע נפרדים לניתוח, הנדסה, תבניות ארטיפקטים וקריאה בשלושה מעברים.

הכלל המנחה הוא פשוט: המערכת יכולה לתכנן, לנתח, לכתוב קוד ולבצע ביקורת סטטית; היא רשאית לטעון שביצעה פעולה רק כאשר קיימת ראיה אמיתית שהפעולה בוצעה.

כך נשמרים היתרונות של V4 — משמעת ראייתית, תכנון, מסירה מלאה ובקרת כשל — בלי לטעון ליכולות רקע, סוכנים עצמאיים או אימותים שלא התקיימו.