מועדון 2030

הי חברים יקרים 😍 כמו כל שבוע, הטיפים פה הם מהניסיון שלי ורק מהניסיון שלי. יש ברשת אלפי "תעשה ככה וככה", אבל אני כותב אחרי קרוב לשנה של עבודה עם קלוד קוד ולא מעט פרויקטים מעניינים איתו. אז בטור שעבר דיברנו על VPS, המחשב שגר בענן ולא הולך לישון....חח...  ראינו איך הוא הפך אצלי לבית של הדאטהבייס של פרויקט הווצאפ, איך מריצים עליו ג'ובים ארוכים בלילה בלי שהמחשב האישי בכלל יהיה קשור אליו...  ואיך Cron יחד עם Resend או Green API מעדכנים אותנו כשמשהו נכשל. וגם סגרתי את הטור בהבטחה שלא שכחתי שאני חייב לכם טור על GuardRails (הבטחה שגררתי עוד מטורים קודמים).

אז היום משלמים חובות! הפעם מדברים על... (טם-טם-טם 🔔) GuardRails!

מה זה GuardRails?

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

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

קלוד הוא חברנו היקר ואני סומך עליו (אתם כבר יודעים שאני חסיד שלו..). אבל חשוב לזכור דבר אחד: כמו שדיברתי בטור #8 על ה-CLI, קלוד קוד לא רק "מדבר". הוא קורא קבצים, עורך אותם ומריץ פקודות אמיתיות על המחשב שלכם ועל ה-Repo שלכם. וזה בדיוק מה שהופך אותו לכל כך חזק.

אבל יש פקודות שאין מהן דרך חזרה.

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

רגע, למה לא פשוט לכתוב את זה ב-CLAUDE.md?

שאלה מצוינת, ואני מודה שזה הדבר הראשון שהייתי חושב עליו.

בטור #9 הסברתי ש-CLAUDE.md הוא דף ההוראות של הפרויקט. אפשר בהחלט לכתוב שם "אל תריץ אף פעם rm -rf", וברוב המקרים קלוד גם יקשיב.

אבל ההבדל חשוב:

CLAUDE.md הוא הנחיה. קלוד קורא אותה ומשתדל לפעול לפיה.

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

במילים אחרות: CLAUDE.md זה לבקש יפה. GuardRails זה לנעול את הדלת.

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

שכבה ראשונה: רשימת "אסור" (deny)

=======================================

לקלוד קוד יש קובץ הגדרות לפרויקט בשם settings.json, והוא יושב בתיקייה .claude בתוך הפרויקט. בתוך הקובץ הזה אפשר לכתוב רשימה של פקודות שקלוד פשוט לא מורשה להריץ. קוראים לה רשימת deny.

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

שתי הדוגמאות שהכי חשובות לי:

• rm -rf מוחקת תיקייה עם כל מה שבתוכה. ה-r אומר "תמחק גם את כל מה שבפנים", וה-f אומר "בלי לשאול שאלות". אין סל מחזור ואין "בטל".

• git push --force דורסת את מה שיש ב-Repo בגיטאהב בגרסה שיש לכם במחשב. אם בטור #11 למדנו ש-Push שולח, אז Push עם force שולח ו"מנצח" בכוח, גם אם זה אומר להעיף Commits שכבר היו שם. כולל Commits של אנשים אחרים בצוות.

ואם אתם זוכרים מטור #3 כמה אני מתעקש לשמור על הענף הראשי Main, אז תבינו למה git push --force נמצא אצלי ראשון ברשימה כן הפחד למחוק את הכל....

ואיך מוסיפים אותן? לא צריך לפתוח את הקובץ וגם לא צריך לדעת JSON (אל תתרגשו...גם לא מכיר טוב ה JSON). פשוט מבקשים מקלוד:

pls add to the project settings.json a deny rule for rm -rf and git push --force

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

ודיסקליימר קטן: הרשימה הזאת בודקת את הפקודה לפי איך שהיא כתובה. אם אותה פקודה כתובה קצת אחרת (למשל rm -r -f במקום rm -rf), היא עלולה לעבור. אז זה מעקה טוב, אבל לא מבצר... וזה מביא אותנו לשכבה השנייה.

שכבה שנייה: Hook מסוג PreToolUse

======================================

בטור #10 הסברתי ש-Hook זה בגדול "כשקורה X, תעשה Y". אז PreToolUse הוא Hook שרץ לפני שקלוד מפעיל כלי. במקרה שלנו הכלי הוא Bash  כלומר הרצת פקודה בטרמינל.

איך זה עובד:

• קלוד רוצה להריץ פקודה.

• לפני שהיא רצה, ה-Hook מקבל אותה ומעביר אותה לסקריפט קטן שלכם.

• הסקריפט בודק את הפקודה. אם הכל בסדר, היא ממשיכה לרוץ כרגיל.

• אם הסקריפט מזהה משהו מסוכן, הוא חוסם את הפקודה (מחזיר exit code 2), והסיבה לחסימה חוזרת לקלוד כדי שיבין למה לא ויחפש דרך אחרת.

תחשבו על זה כמו סלקטור בכניסה למועדון: כל פקודה עוברת אצלו לפני שהיא נכנסת  למועדון 😄 ומה שיפה זה שהסלקטור גם אומר לקלוד למה לא נתן לו להיכנס, אז קלוד לא סתם נתקע אלא מבין ומתקן כיוון. ההבדל מרשימת ה-deny הוא שפה יש לכם קוד שבודק, ולא רק תבנית טקסט. אז אפשר לתפוס גם וריאציות של אותה פקודה מסוכנת. למשל rm -rf, rm -r -f ו-rm -fr, או git push --force לצד הקיצור שלו git push -f.

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

pls create a PreToolUse hook for Bash in the project settings that blocks rm -rf and git push --force, including variations like rm -r -f and git push -f, and explain to me how it works

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

אז איך שתי השכבות עובדות ביחד?

רשימת deny היא הקו הראשון. פשוטה, ברורה, ותופסת את המקרים הצפויים.

ה-Hook הוא הקו השני. חכם יותר, ותופס את מה שחמק מהקו הראשון.

deny = רשימה.
Hook = שומר עם לוגיקה .

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

ורגע משהו חשוב..  GuardRails הם לא תחליף לגיבוי

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

GuardRails מקטינים מאוד את הסיכוי לטעות הרסנית, אבל הם לא מבטלים אותו. ולכן הבסיס נשאר הבסיס: הפרויקט צריך לשבת ב-GitHub (טור #3), ולעשות Commit ו-Push באופן קבוע (טור #11). ככה גם אם משהו כבר כן השתבש, יש לאן לחזור.

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

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

תתחילו עם deny קטן וברור: שתיים או שלוש פקודות שאתם יודעים בוודאות שאתם לא רוצים שירוצו אף פעם.

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

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

. אז בשבילי GuardRails זה לא "עוד הגדרה טכנית". זה בדיוק המעקה שחוסך טעויות קשות... 

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

באהבה, אלכס! 🥰

=================================================

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

https://8bitretro.tech/