הגדר תצורה עם עוזר ה־AI שלך

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

מסרו את המדריך לעוזר שלכם#

פתחו את העוזר במאגר שבו אתם רוצים ש־Coroid יעבוד, ותנו לו את ההנחיה הבאה:

Set up Coroid for this repository. Follow the runbook at
https://coroid.ai/docs/export/en-US/getting-started/assistant-setup.md
step by step. Ask me before you change anything, and never ask me to paste a
password or token into this chat.

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

כללי יסוד לעוזר#

אתם מגדירים את Coroid, מפעל תוכנה מבוסס ענן מסוג AI שממיר תיאור משימה לקובץ pull request שעבר בדיקות וסקירה במאגר של המשתמש. עקבו אחר הכללים הבאים לאורך כל התהליך:

1. המשתמש פועל; אתם מכינים. אינכם יכולים להירשם, להתחבר, לקבל תנאים, להתקין אפליקציות או למתוח רשויות עבור המשתמש. ציינו בדיוק מה לעשות ואיפה, וחכו עד שהמשתמש יאשר שזה בוצע.
2. הימנעו מלהזין סיסמאות סודיות לשיחה. לעולם לא בקשו סיסמה, אסימון גישה אישי, מפתח ספק או אסימון MCP. המשתמש מקליד פרטי גישה סודיים בפורטל של Coroid או בקונסולה שלו. אם פרט כזה נדבק בכל זאת לצ׳אט, הודיעו למשתמש לבטל אותו וליצור חדש.
3. שאלו לפני כל שינוי: קבצים, ענפים ובקשות משיכה במאגר של המשתמש, פרויקטים של Coroid, והזמנות.
4. בדקו כל שלב לפני המעבר לשלב הבא. אם הבדיקה נכשלת, השתמשו בהערות שבאותו שלב, והמשיכו רק לאחר שהיא תצליח או שהמשתמש יחליט לדלג עליה.
5. עקבו אחר המוצר, לא אחר ההנחות שלכם. אם הפורטל מציג משהו שהמדריך הזה אינו מתאר, הודיעו למשתמש מה אתם רואים ופעלו לפי ההנחיות שבפורטל. אל תמציאו הגדרות חדשות.
6. שמרו תיעוד של תהליך ההגדרה של כל שלב ותוצאתו, לקראת הסיום.

כל שלב מקשר בין הדפים לפרטים הרלוונטיים.״ https://coroid.ai/llms.txt המערכת מבצעת אינדקס של כל המסמכים.״

שלב 1: הסכימו על התוכנית#

שאלו את המשתמש את השאלות הבאות יחד, ולא אחת אחרי השנייה:

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

ראו תוכניות ומחירים, מגבלות ומכסות ו מסונכרן או מקומי בלבד.

שלב 2: בדוק שכל מאגר קוד נבנה ונבדק מתוך עותק נקי#

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

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

1. זהוו את שפות התכנות, מנהל החבילות ואם מדובר במונורפו.
2. מצאו את פקודות ההתקנה, הבנייה והבדיקה ב-README, בהגדרות ה-CI ובקבצי ההגדרה.
3. בקשו אישור לפני שתריצו דברים. לאחר מכן העתיקו את הפרויקט לתוך תיקייה זמנית ריקה והריצו שם את פקודות ההתקנה, הבנייה והבדיקה ללא כל הגדרות נוספות. העתק העבודה של המשתמש מכיל זיכרונות ו .env קבצים שמסתירים בעיות.
4. רשמו את כל מה שהריצה דרשה ושאינו קיים בהעתק החדש:
   • שירותים שהבדיקות מצפות להם, כגון מסד נתונים, מטמון או תור הודעות.
   • שלבים לפני הבדיקות, כגון יצירת קוד, הגירות או קבצי יסוד.
   • משתנים סביבתיים או .env קובץ שאינו מבוצע קומיט.
   • מאגרי חבילות פרטיים.
   • סביבת ריצה שאינה נמצאת ב- סביבת הסוכן.

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

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

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

ראו הגדרות בנייה ובדיקה ו- תמיכה בשפות וסביבת הסוכן.

שלב 3: כתבו את ההוראות שסוכני Coroid קוראים.#

לפני כל משימה, סוכני Coroid קוראים את קבצי הזיכרון בפרויקט: AGENTS.md, CLAUDE.md או GEMINI.md בשורש, ו- .cursor/rules. הפקודות שאישרתם בשלב 2 צריכות להופיע שם.

הציעו AGENTS.md, או תוספת לקיים, שיכילו את הדברים הבאים:

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

השמיטו את מה שהקוד כבר מציג, והשאירו את הקובץ קצר. אם CLAUDE.md או .cursor/rules מכילים את אותן הוראות, שמרו אותן פעם אחת ב- AGENTS.md ואז ייבאו אותן מהקובץ האחר באמצעות שורת @AGENTS.md .

הצג את ה־diff למשתמש. עם אישורו, בצע גריט על ענף חדש ופתח pull request, או השאר זאת לו כדי שיבצע את הגריט בעצמו. יש להעביר את השינויים לענף הבסיס לפני תחילת משימה ראשונה, מכיוון שכל משימה קוראת את קבצי הזיכרון מהעותק שלה מאותו ענף. טפל בתיקונים משלב 2 שאושרו על ידי המשתמש באותו אופן.

ראה הגדרות הקשר פרויקט ו הקשר פרויקט.

שלב 4: חשבון וארגון (המשתמש)#

דלג על שלב זה אם המשתמש כבר שייך לארגון Coroid כבעלים או מנהל.

בקש מהמשתמש ל:

1. להירשם ב- https://client.coroid.ai/auth/signup באמצעות כתובת האימייל העבודתית שלו, ו לאמת את הכתובת
2. לקבל את תנאי השימוש
3. ליצור את הארגון

בדוק: שהמשתמש יכול לפתוח https://client.coroid.ai/projects. האדם שמשלים את ההגדרה הזו נדרש לתפקיד בעלים או מנהל, מכיוון שרק תפקידים אלו יכולים לחבר בקרת קוד מקור ולהוסיף מפתחות ספק.

ראה צור את החשבון והארגון שלך.

שלב 5: חיבור בקרת קוד מקור (המשתמש)#

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

GitHub#

המשתמש פותח הגדרות → חיבורים → בקרת קוד מקור (https://client.coroid.ai/settings/connections/source-control).

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

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

GitLab#

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

הגנת ענף#

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

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

ראו חבר את הקוד שלך, GitHub, GitLab ו־ הגדרות מאגר וענף.

שלב 6: יצירת הפרויקטים (המשתמש)#

יש ליצור פרויקט אחד לכל מאגר, לעולם לא שני פרויקטים לאותו מאגר. המשתמש פותח פרויקטים → חדש (https://client.coroid.ai/projects/new) ולגבי כל מאגר:

1. בוחר אותו מהספק המחובר, או משתמש ב־ חיבור באמצעות כתובת URL עבור מאגר ציבורי
2. בוחר את מצב מאגר: מסונכרן, כאשר Coroid דוחף ענפים ופותח בקשות משיכה, או רק מקומי, כאשר Coroid לעולם אינו כותב למאגר עד שמישהו בוחר ב־ התחל סינכרון
3. בודק את הענף המוגדר כברירת מחדל
4. יוצר את הפרויקט

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

אם מאגר חסר ברשימה, הסיבה כמעט תמיד היא אחת מהבאות:

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

ראו צור את הפרויקט הראשון שלך ו־ הגדרות מאגר וענף.

שלב 7: בדוק מה מצא Coroid#

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

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

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

ראו הגדרות הקשר של פרויקט ו־ תצורת בנייה ובדיקה.

שלב 8: הגדרות ארגון (אופציונלי)#

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

• חברים, תחת הגדרות → חברים: האנשים שיבצעו סקירה של בקשות משיכה כבעלים, מנהל, חבר או מבקר. מומלץ למנות רק מנהלים לאנשים שצריכים לשנות מדיניות ומפתחות ספק. נדרשת רמת Professional.
• מפתחות ספק, תחת הגדרות → מפתחות ספק: רק לשימוש בחשבונות ספקי מודלים של הארגון עצמו. המשתמש מזין את המפתח בפורטל. מומלץ להשתמש במפתח מוגבל עם מגבלת הוצאות אצל הספק.
• הגדרות מארגון אחר: יש לייצא חבילת הגדרות לשם ולייבא אותה תחת הגדרות → נתונים → ייצוא הגדרות. הסודות נשלחים כתוויות מתאר, ולכן כל needsRebind פריט בתצוגה מקדימה דורש תשומת לב.

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

שלב 9: התחברות אישית ל־Coroid (אופציונלי)#

אם הלקוח שלך תומך בשרתי MCP מרוחקים, תוכל לגשת ל־Coroid דרך שרת ה־MCP שלו ב־ https://api.coroid.ai/mcp. ההגדרה אינה תלויה בכך, אך זה מאפשר לך לבדוק את הפרויקטים בעצמך ולסייע למשתמש להפעיל משימות מאוחר יותר.

1. המשתמש פותח הגדרות → אוטומציה → Coroid MCP server (https://client.coroid.ai/settings/automation/coroid-mcp). אם השירות אינו זמין לארגונו, דלג על שלב זה.
2. הגדרת לקוח מציג את הפקודות לפי לקוח. באמצעות OAuth, המשתמש מאשר את הגישה שלך בדפדפן שלו. באמצעות אסימון גישה אישי, המשתמש יוצר אותו תחת אסימוני גישה ושומר אותו במשתנה סביבה בקליפ שלו. אינך צריך לראות את הערך לעולם.
3. מומלץ להעניק את רמת הגישה המינימלית הדרושה: mcp.read כדי לבדוק את ההגדרה, בתוספת mcp.work.write רק אם אתה אמור ליצור משימות. הגבל את האסימון לפרויקטים אלו, קבע לו תאריך תפוגה, והגדר מדיניות אוטומציה לפני שכל לקוח יפעיל פעולות ללא השגחה.

בדיקה: קרא ל־ list_projects, ולאחר מכן get_project עבור כל פרויקט משלב 6, ואשר שהמאגר והענף תקינים.

השתמש רק ב־ api.coroid.ai עבור MCP. שם המארח של פורטל הלקוח אינו מספק שירות זה.

ראו Coroid כשרת MCP.

שלב 10: טיוטה של משימה ראשונה#

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

תאר את התוצאה, לא את היישום: מה צריך להיות נכון כשהעבודה תסתיים, אילו קבצים רלוונטיים, ומה לא לגעת בו. המשתמש שולח אותה מ־ עבודה חדשה (https://client.coroid.ai/work/new), קורא את המפרט, ומאשר את התוכנית. ביצוע משימות צורך שעות סוכן, ותוכנית Free כוללת 2 שעות ליום UTC, לכן תן למשתמש להחליט מתי היא תתבצע.

ראו הפעל את המשימה הראשונה שלך ו מפרטים.

שלב 11: מסירה לידיים#

מסור למשתמש את רשימת ההגדרות:

• כל מאגר נתונים, הפרויקט שלו, מצב המאגר וענף הבסיס
• אופן חיבור בקרת הקוד מקור, ומי הוא בעל החיבור: מתקין האפליקציה, או בעל אסימוני הגישה ותאריך התפוגה שלו
• לכל מאגר נתונים – התיקונים שבוצעו, אלו שעדיין תלויים (כגון בקשת משיכה פתוחה עם AGENTS.md), ואלו שהמשתמש בחר להשאיר כך
• ההגדרות האופציונליות שבוצעו ודולגו עליהן, והמשימה הראשונה שנוסחה

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

הבא#

צור את החשבון והארגון שלך – אותה הגדרה, אך באופן ידני.