העברת פרויקט מ-Codex ל-Hermes בשרת

לעזרה בשימוש בשירות, עיינו בתיעוד של Ailoot.

מה להכין לפני ההעברה#

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

אם הסוכן עדיין לא מותקן בשרת, התחילו בהתקנת Hermes Agent ב-VPS. כאן תזדקקו להתקנת Hermes פעילה, למסוף השרת ול-Git. דרוש לכם מאגר מרוחק שנגיש מהשרת; אם עדיין אין לכם כזה, צרו אותו תחילה ושמרו בו את הפרויקט ללא סודות. אם מדובר במאגר פרטי, הגדירו מראש גישת קריאה מהחשבון שלכם; אל תכניסו אסימון לכתובת המאגר או להודעה לסוכן.

השהו עריכות מקבילות בפרויקט במהלך ההעברה. במחשב המקור, פתחו מסוף בתיקיית הפרויקט עצמה והריצו:

git status --short --branch
git status --short --ignored

הפקודה הראשונה מציגה את הענף ואת מצב הקבצים. M מציין שינוי, ו-?? מציין קובץ ש-Git עדיין לא עוקב אחריו. בפקודה השנייה, קבצים שהתעלמו מהם מסומנים ב-!!. מצב נקי רגיל לא מוכיח שאין לכם קבצים נחוצים מחוץ ל-Git.

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

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

העתקת הענף הנכון לשרת#

תחילה שמרו את הפלט של הפקודה הזאת במחשב המקור:

git status --porcelain=v2 --branch

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

בשרת, עברו לתיקייה שבה תשמרו את הפרויקטים. שכפלו את המאגר לתיקייה חדשה. בתבנית שלהלן, החליפו את REPOSITORY_URL בכתובת המאגר שלכם, את BRANCH_NAME בשם הענף ששמרתם ודחפתם, ואת my-project בשם הרצוי לתיקייה החדשה:

git clone --branch BRANCH_NAME REPOSITORY_URL my-project
cd my-project
git status --porcelain=v2 --branch

זאת תבנית, לא כתובת מוכנה להעתקה. git clone יוצר תיקייה ועותק עבודה של הענף שנבחר. אם תיקיית היעד כבר קיימת, היא חייבת להיות ריקה: אל תמחקו את התוכן שלה כדי להריץ שוב את הפקודה; בחרו שם חדש.

השוו את # branch.oid בשני העותקים. אם הערכים שונים, אל תתחילו לתקן קוד בשרת: בדקו את הענף שנבחר, את הקומיטים שדחפתם והאם נעשו שינויים מקבילים. אם פלט המצב מציג קבצים ששונו, בדקו אותם בנפרד. אל תשתמשו בניקוי או באיפוס כפוי כדי "לגרום להם להיות זהים".

מאגרי Git עם תת-מודולים—מאגרי Git מקוננים—מחייבים גם להביא את התוכן שלהם. ל-git clone יש אפשרות --recurse-submodules לשם כך; השתמשו בה אם הפרויקט אכן מכיל תת-מודולים וכתובותיהם נבדקו. פרויקטים עם משאבים חיצוניים אחרים עשויים לדרוש הליך נוסף שמתואר ב-README.

שחזור התלויות לפי כללי הפרויקט#

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

דוגמה היפותטית עבור Node.js ו-npm: במאגר יש קובצי package.json ו-package-lock.json עקביים, ובשרת מותקנת גרסת Node.js שמתאימה לפרויקט. במקרה כזה, הריצו את הפקודה הזאת בתיקיית הפרויקט:

npm ci

לפי תיעוד npm ci, הפקודה מתקינה תלויות עבור הפרויקט כולו מתוך קובץ הנעילה, בלי לשכתב את package.json או את package-lock.json. אם התוכן שלהם אינו עקבי, ההתקנה נכשלת. כל תיקיית node_modules קיימת נמחקת לפני ההתקנה.

אם קובץ הנעילה נוצר עם אפשרויות שמשפיעות על עץ התלויות, כגון --legacy-peer-deps, גם npm ci זקוקה לאותן אפשרויות. בדקו את הוראות הפרויקט המקורי ואת ההגדרות שלו. אל תמחקו את קובץ הנעילה ואל תעדכנו את כל התלויות כדי להסתיר את שגיאת ההעברה הראשונה.

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

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

פתיחת עותק העבודה ב-Hermes#

במסוף השרת, עברו לשורש העותק החדש והפעילו את הסוכן שכבר מותקן:

cd /absolute/path/to/my-project
hermes

כאן, /absolute/path/to/my-project הוא מציין מקום לנתיב המלא של הפרויקט. במסך ההפעלה של Hermes, בדקו את תיקיית העבודה ואת הסביבה שבה פועלות פקודות המסוף. שיטת הפעלה זו מיועדת לסביבת המסוף המקומית של Hermes בשרת. אם SSH או Docker מוגדרים, ייתכן שהסוכן יפעיל פקודות בסביבה אחרת; תחילה ודאו שנתיב הפרויקט זמין שם.

בקשו מהסוכן לאשר את תיקיית העבודה בפועל באמצעות כלי המסוף שלו, ואז לקרוא את README ואת הוראות הפרויקט. אל תסתפקו בשם תיקייה שמופיע בהודעה כאימות.

סדר העדיפויות שלהלן מצוין בגרסה מוצמדת של התיעוד, וייתכן שהוא שונה בגרסה של Hermes שמותקנת אצלכם. בדקו את ההוראות העדכניות בהפעלה שלכם. Hermes תומך ב-AGENTS.md, אבל קריאת הקובץ תלויה בסדרי העדיפויות של קובצי ההקשר. לפי התיעוד הרשמי של Hermes, נבחר סוג אחד של קובץ הוראות: .hermes.md, אחריו AGENTS.override.md, אחריו AGENTS.md, אחריו CLAUDE.md ולבסוף .cursorrules. לפני תחילת העבודה, בדקו אם קיים קובץ .hermes.md ישן או AGENTS.override.md אישי: אל תניחו שהסוכן בהכרח יחיל את AGENTS.md לצד הקובץ הזה.

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

תנו לסוכן משימה אחת ובדקו את התוצאה#

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

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

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

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

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

הכירו את Ailoot.