דרכים להתחיל עבודה

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

נבדק, ואז מנותב#

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

גם בקשות מקליטת העבודה ב־API עוברות דרכו, וכך גם אירועים שאוטומציית אירועים שולחת לתהליך הסיווג.

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

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

הפונקציונליות של Ask Coroid שונה. במצב Assistant, העוזר בצ'אט יוצר משימות ותוכניות ישירות, ללא Qualification. צ'אט Prepare Work, שהוא תהליך SDLC מונחה, שולח את המפרט שאושר ל-Qualification לפני תחילת התכנון. ראו עוזר צ'אט.

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

כשהעבודה מתחילה#

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

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

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

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

משימה או תוכנית?#

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

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

עבודה מיובאת#

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

ממערכותיכם שלכם#

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

API זקוק לחשבון שירות, שכלול בתוכניות Professional וארגונית. ניתן ליצור אותו תחת הגדרות → חשבונות שירות. מפתח ה־API שלו זקוק לטווח הרשאות זה: intake:write. המפתח מוצג פעם אחת בלבד בעת יצירתו, וניתוק חשבון השירות גורם לדחייה של כל המפתחות שלו.

שלחו כל בקשה לצומת ה־API, עם המפתח כטוקן bearer:

curl -X POST https://api.coroid.ai/api/v1/organizations/work/intake \
  -H "Authorization: Bearer ak_…" \
  -H "Content-Type: application/json" \
  -d '{"title": "Export invoices as CSV", "content": "Customers want to download their invoices as CSV from the billing page."}'

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

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

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

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

אירועים ב־GitHub, Slack, Telegram ו־Jira יכולים להפוך גם לבקשות, מבלי שאף אחד יצטרך להקליד אותן מחדש. אוטומציית אירועים שולחת אותן לתהליך האישור. ראו מפעילים ויעדים.

מהעוזרים שלכם#

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

כניסה אוטומטית#

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

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

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

בפרק זה#

• תיאור הצרכים שלכם
• משימות
• ייבוא עבודה
• תוכניות
• ספרינטים
• גרסאות