תיעוד

הקשר הפרויקט

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

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

הקשר של הפרויקט משלב בין הוראות המאגר לבין ההנחיות שאתם שומרים ב־Coroid.

גם הוראות המאגר נחשבות כהקשר

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

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

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

מה ש־Coroid מסוגל לקבוע בעצמו

רק מהמאגר, הסוכנים יכולים לראות:

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

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

מה שהם אינם יכולים להסיק

הקוד מראה מה עשיתם, אך מעולם לא למה:

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

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

המאגר מציג מה

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

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

אתה מוסיף מדוע

הקשר הפרויקטי כולל את מה שנמצא בראשם של אנשים.

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

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

השאירו בחוץ את מה שהמאגר כבר מציג. רשמו את מה שמי שקורא רק את המאגר לא יוכל להבין.

הוספת הקשר

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

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

הקשר לפי משימה

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

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

שמירה על דיוק המידע

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

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