קראתי את הקוד לפני שהרצתי: ניסוי בכלי…

לפני שמתקינים כלי orchestration agents כדאי לדעת מה הוא כותב מחוץ לתיקייה שלו ומה נשאר רץ אחרי שסיימת. קראתי את הקוד לפני שהרצתי משהו, והפוסט מראה מה שאלתי, מה מצאתי ומה לקחתי.

בקטלוג כלי הבינה המלאכותית שלי היו 64 כלים, 14 מהם רלוונטיים ל-orchestration של agents, ואף אחד לא נבדק אף פעם. הרישום שלי עצמו קובע (VER-05) שהטענות של כלי שכתב אדם אחד הן לא מאומתות עד שמישהו מנסה אותו. phalanx היה הראשון שניסיתי, ופסק הדין שלי הוא פיילוט: לא לאמץ, לא לדחות, ולקחת ממנו את התכנון ולא את הספרייה.

השאלה

האם כלי orchestration שמתואר בקטלוג כמנהל צוות agents עם ניטור קריסות ותקיעות באמת עושה את זה, והאם הוא בטוח להריץ אצלי? חסר לי דבר אחד בעיקר: היום, אם agent מפוקח בחלון טרמינל מת באמצע משימה, שום דבר לא שם לב עד שאני מסתכל בעצמי.

ההגדרה

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

קריאה: שכפלתי את ה-repo לתיקייה זמנית וקראתי אותו לפני שהרצתי משהו. ב-repo 126 קבצים במעקב, רישיון MIT ומחבר יחיד.
שלב 1: התקנה ו-unit tests, בלי עלות חיצונית.
שלב 2: live test של המנגנון, גם היא בלי עלות. חבילת ה-tests של הכלי כוללת backend מזויף שמריץ סקריפט בשורת הפקודה במקום model, עם התנהגויות בשם (complete, crash, stall, block, escalate), ולכן מפעיל את ה-pipeline האמיתי בלי קריאות ל-model.

את הטענות מהקטלוג רשמתי לפני שנגעתי בקוד, כדי שהקריאה תוכל לסתור אותן: orchestrator שאינו תלוי בספק, ראש צוות עם בריכת עובדים מתחלפת, תפקידים שמוגדרים ב"נשמה", חלון tmux מבודד לכל agent, ניתוב לפי אירועים, ותהליך רקע שמנטר תקיעות וקריסות.

הזרימה

היסטוריה של ה-repo. לפי gh api, ה-repo נוצר ב-2026-03-13, נדחף לאחרונה ב-2026-03-18, ויש בו 3 כוכבים, פיצול אחד ואפס בעיות פתוחות. חמישה ימים של פעילות, חמישה חודשים לפני הניסוי, ואז שקט.
ארבע שאלות בטיחות, מהקוד, לפני כל הרצה. האם הוא צריך מפתח API משלו? לא: חיפוש של שמות מפתחות בקוד לא החזיר כלום, והוא מפעיל כלי שורת פקודה שכבר מחוברים דרך send-keys של tmux. האם הוא משאיר תהליכים אחרי הניסוי? כן: הוא פותח סשן tmux מנותק לכל agent, ועוד סשן מנותק לכל צוות בשביל תהליך הניטור, ושניהם חיים עד שהורגים אותם במפורש. האם הוא כותב מחוץ לתיקייה שלו? כן, בשני מסלולים: תיקיית worktrees תחת ~/.phalanx (רק אם הגדרת הצוות מבקשת), וקובץ הפקודות הגלובלי ~/.claude/commands/phalanx.md. האם הוא מתקין משהו גלובלית? רק דרך המסלול השני.
המסלול שלא הרצתי. הקובץ הגלובלי נכתב רק מהפעלה חשופה של phalanx בלי תת-פקודה, ואם הקובץ כבר קיים העדכון דורס אותו בלי שאלת [Y/n]. זו אותה תיקייה שבה אני שומר את פקודות הלוכסן שלי. לכן קבעתי כלל לכל הניסוי: רק init, team ו-agent, אף פעם לא phalanx חשוף, ובלי הגדרת worktree.
baseline לפני ההרצה. רשמתי את המצב: אין phalanx.md בתיקיית הפקודות, אין ~/.phalanx, אין שרת tmux ואין תהליך phalanx.
שכבה 1. uv sync התקין 18 חבילות, ו-uv run pytest עבר: 615 unit tests ירוקים ב-146.97 שניות. uv run pytest הוריד גם CPython מנוהל, גרסה 3.13.5, ל-cache של uv. זו ההתנהגות הרגילה של uv ולא משהו ש-phalanx עשה.
מה נשבר. ה-e2e tests לא נאספים מהקופסה: tests/e2e/conftest.py מייבא helpers ביבוא חשוף, אבל tests/e2e/__init__.py הופך את התיקייה לחבילה, וזה משנה את הנתיב ש-pytest מוסיף, והתוצאה ModuleNotFoundError: No module named 'helpers'. תיקנתי עם PYTHONPATH=. והרצה מתוך התיקייה, ואימתתי שזה עובד. זה באג אריזה ב-repo עצמו ולא טעות בהגדרה אצלי.
שכבה 2. הרצתי את ה-tests שמעידים ישירות על טענת הקריסה והתקיעה, ועוד מחזור חיים מלא של צוות: 9 עברו ב-0.20 שניות. ביניהן זיהוי רוח רפאים אחרי קריסה והפעלה מחדש אוטומטית, יציאה שקטה לשורת פקודה ריקה, זיהוי הגבלת קצב, ויצירה ועצירה של צוות. אלה נתיבי הקוד האמיתיים, עם חלונות tmux אמיתיים שנפתחו ונסגרו, ורק ה-model הוחלף בסקריפט.
ניקוי ובדיקה. בסוף אין שרת tmux, אין תהליך phalanx, אין ~/.phalanx, ותיקיית הפקודות כמו ב-baseline.
מה לא הרצתי, ולמה. צוות חי עם claude, codex או gemini שעושה עבודה אמיתית. על המחשב מותקן רק claude, כך שהרצה כזאת לא הייתה בודקת את טענת ריבוי הספקים בכל מקרה, והיא הייתה שורפת שימוש אמיתי במנוי בשביל מעט ראיה נוספת על הדבר שהכי עניין אותי, תהליך הניטור, שחבילת ה-tests כבר הפעילה בחינם. זו החלטת תחום ולא חסם, ובגללה פסק הדין הוא פיילוט ולא אימוץ.

המספרים

מדד	ערך
כלים בקטלוג / רלוונטיים ל-orchestration / נבדקו	64 / 14 / 0
קבצים במעקב ב-repo	126
כוכבים / פיצולים / בעיות פתוחות	3 / 1 / 0
ימי פעילות, חמישה חודשים לפני הניסוי	5
unit tests (שכבה 1)	615 עברו, 146.97 שניות
live tests של המנגנון (שכבה 2)	9 עברו, 0.20 שניות
שאלות בטיחות שנענו מהקוד	4
מסלולי כתיבה מחוץ לתיקייה	2

מה הכלי עושה טוב ממה שיש לי

ניטור אמיתי של קריסה ותקיעה. הדבר הקרוב היחיד שמצאתי אצלי הוא agent_prompt_stalled של מנהל החלונות שלי, אבל זה timeout של 5 שניות על מסירה של prompt אחד, לא פיקוח מתמשך. ב-phalanx monitor/stall.py הוא מכונת מצבים עם חמישה מצבים (RUNNING, BLOCKED_ON_PROMPT, IDLE_TIMEOUT, STALLED, DEAD), סורק מסך עם דפוסים רשומים, זיהוי מוות בהשהיה והשתקה לפי תוצרים, וכל זה אומת בהרצה חיה ולא רק נקרא.
חלון נראה וניתן לחידוש לכל agent. לכל עובד סשן tmux בשם משלו עם לוג זורם, ואפשר לצפות בו ולחדש אותו ישירות. ל-sub-agents של ה-plugin שלי אין סשן נפרד להתחבר אליו.
שכבת הפשטה לספקים. ארבעה backends מאחורי ממשק אחד, גם אם לא יכולתי לבדוק יותר מספק אחד.
התמדה בין סשנים. המצב נשמר ב-SQLite, ו-team resume שורד קריסה או טרמינל שנסגר.

איפה הוא לא מספיק

ריבוי ספקים לא אומת. הטענה נשענת על קריאת backends/registry.py ועל דוגמת ההגדרה ב-README, לא על צפייה ב-codex וב-claude עובדים יחד.
אין פירוק משימות מובנה. זו תשתית: להקים, לפקח, לשלוח הודעות ולאחד. אין בה מקבילה ל-pipeline של ה-plugin שלי עם השערים שזורקים לפני שליחה ותקרת הסיבובים של תיקון ואימות. לאמץ אותו משמעו לבנות את המשמעת הזאת מעליו.
מלכודת בנתיב שנמנעתי ממנו. ה-Quick Start המתועד, phalanx --auto-approve --backend claude ..., נוגע בתיקיית הפקודות הגלובלית בלי אזהרה כפולה.
שטח תפעולי גדול מהבידוד שהוא נותן. צריך tmux, uv, Python מגרסה 3.11 ומעלה, והתחברות נפרדת לכל כלי. עובדים בלי השגחה צריכים --auto-approve, שמאשר אוטומטית prompts של "bypass permissions", ו-agent מקונן כזה יכול להריץ bash בכל מקום בתיקיית העבודה שלו.

המסקנה ומה השתנה אצלי

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

מה שהשתנה בדרך העבודה שלי:

לוקחים את התכנון, לא את הספרייה. חוזה חיות: הסשן קיים, והפקודה שרצה בו היא לא מעטפת ריקה, בתוספת סריקה של שורות המסך האחרונות. מוות בהשהיה: STARTUP_GRACE_SECONDS = 120 ו-STARTUP_DEAD_THRESHOLD = 3 בדיקות כושלות ברצף. השתקה אחרי תוצר: agent שכתב את התוצאה שלו לא מפעיל התראת תקיעה בזמן שהוא ממתין. קירור של 60 שניות בין תזכורות, וניסיון חוזר עם השהיה שגדלה (2**n * 5) עד 300 שניות.
לא לוקחים את הדפוסים עצמם. ביטויי הסריקה (אמון בסביבת עבודה, הגבלת קצב, סימני סרק של Claude Code) קשורים לפני השטח של הטרמינל, ויתיישנו בפעם הבאה שהוא ישתנה. החלק ששווה העתקה הוא הארכיטקטורה סביבם: כל גלאי נרשם בנפרד וניתן לבדיקה בנפרד.
הצעד הבא הוא צופה קטן משלי. צופה קטן, מקומי וללא תלות חיצונית על חלונות הטרמינל שלי, בצורה של חוזה חיות, השהיה ושתיקה אחרי תוצר. לא תלות ב-phalanx.
ואם ארצה בכל זאת לנסות אותו: משימה אחת קטנה והפיכה דרך phalanx team create עם עובד claude חי אחד, max_runtime מוגבל, ב-repo זמני, ובדיקת tmux ls ו-pgrep אחרי.

מה המספרים לא יודעים להגיד

הם לא מודדים התנהגות מול model חי: בשכבה 2 ה-model הוחלף בסקריפט, ולכן הניטור הוכח מול התנהגויות מוגדרות מראש ולא מול התקיעות הבלתי צפויות של סשן אמיתי.
615 tests ירוקים מעידים על קוד נבדק היטב, לא על מחבר שיתחזק אותו. חמישה ימים של פעילות וחמישה חודשים של שקט הם בדיוק המקרה ש-VER-05 מדבר עליו.
ריבוי הספקים נשאר לא מאומת, כי רק claude מותקן אצלי.
זו בדיקה אחת של כלי אחד מתוך 14, בהרצה אחת. היא לא אומרת כלום על שאר הקטלוג.

מה אפשר לקחת מזה

עונים על ארבע שאלות בטיחות מהקוד לפני כל הרצה. האם הכלי צריך מפתח משלו, האם הוא משאיר תהליכים, האם הוא כותב מחוץ לתיקייה שלו והאם הוא מתקין משהו גלובלית. כאן התשובה הייתה כן בשניים מהם, ושניהם נמצאו בקריאה ולא בהרצה.
רושמים את הטענות של הכלי לפני שקוראים אותו. כך הקריאה יכולה לסתור אותן, ולא רק לאשר אותן בדיעבד.
מוצאים את הנתיב היחיד שנוגע בהגדרות הגלובליות ואוסרים אותו לכל הניסוי. כאן זו הפעלה חשופה בלי תת-פקודה. לפני ההרצה רושמים baseline (תיקיית הפקודות, תהליכים, שרת tmux), ואחריה בודקים שהוא חזר זהה.
בודקים אם חבילת ה-tests של הכלי מביאה תחליף ל-model. ה-backend המזויף של phalanx הריץ את pipeline הניטור האמיתי, 9 tests ב-0.20 שניות, בלי קריאות ל-model ובלי עלות.
כשהמחבר יחיד וה-repo ישן, לוקחים את העיצוב ולא את הספרייה. מה שנשאר מהניסוי הוא חוזה חיות, מוות בהשהיה והשתקה אחרי תוצר, וכל אחד מהם אפשר לכתוב לבד בלי לתלות את העבודה במחבר אחד.