Memory and Persistence — זיכרון והמשכיות

בעיית הזיכרון — למה שיחות שוכחות

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

"Claude, תמשיך מאיפה שעצרנו אתמול."
"I don't have any context from previous sessions. Could you provide more details about what you'd like to continue working on?"

זו בעיית הזיכרון (The Memory Problem). כל שיחת Claude Code מתחילה מלוח חלק — בלי זיכרון של שיחות קודמות, בלי ידיעה מה דיברתם אתמול, בלי הכרת הסטנדרטים שהגדרתם בשבוע שעבר. זה לא באג — זה הארכיטקטורה הבסיסית של מודלי שפה. כל שיחה היא אינטראקציה חדשה ומנותקת.

בתוך שיחה אחת, Claude זוכר הכל. Context Window של 200K טוקנים (או עד 1M עם Opus 4.6 ב-Max/Team/Enterprise — כלומר כ-750,000 מילים, או ספר של 2,500 עמודים) מחזיק עשרות אלפי שורות קוד, מאות הודעות, והיסטוריה מלאה של מה שעשיתם יחד. זה כמו זיכרון לטווח קצר מצוין — כל עוד השיחה פתוחה, Claude יודע הכל.

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

מה זה אומר בפועל? שאתה חוזר ומסביר שוב ושוב:

• "הפרויקט שלנו משתמש ב-TypeScript עם Next.js ו-Prisma"
• "תמיד תכתוב טסטים עם Vitest, לא Jest — כבר עברנו ל-Vitest לפני חצי שנה"
• "ה-API נמצא ב-src/api/ ומשתמש בפורמט REST, לא GraphQL"
• "ההחלטה מלפני חודש — עברנו מ-MongoDB ל-PostgreSQL בגלל מודל נתונים רלציוני"
• "Imports צריכים להיות ממוינים: external, internal, relative"
• "הסיסמאות ב-.env — לעולם אל תגע בקובץ הזה"

כל הסבר חוזר = טוקנים מבוזבזים, זמן מבוזבז, ולפעמים גם אי-דיוקים כי שכחת פרט חשוב. והנה החישוב: אם כל שיחה מתחילה עם 5 דקות של "תדרוך", ואתה פותח 6 שיחות ביום — זה חצי שעה יומית רק על הסברים חוזרים. 2.5 שעות בשבוע. יותר מ-100 שעות בשנה.

הפתרון של Claude Code: מערכת זיכרון בשכבות (Layered Memory System). לא מנגנון אחד, אלא ארבע שכבות שכל אחת פותרת חלק אחר מבעיית הזיכרון. הרעיון דומה לאיך שזיכרון במחשב עובד — Cache מהיר לדברים תכופים, RAM לעבודה נוכחית, דיסק לאחסון ארוך טווח:

בפרק הזה נבנה כל שכבה צעד אחרי צעד, נבין מתי להשתמש באיזה מנגנון, ונרכיב מערכת זיכרון מלאה שגורמת ל-Claude "לזכור" כל מה שחשוב. בסוף הפרק, תפתח שיחה חדשה ותראה שClaude כבר יודע את הכל — בלי שתסביר מילה אחת.

Auto-Memory — הזיכרון האוטומטי

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

איך זה עובד בפועל? בזמן שאתה עובד עם Claude, הוא מזהה דפוסים ותובנות שכדאי לזכור לשיחות הבאות:

• החלטות ארכיטקטוניות: "הפרויקט משתמש ב-Prisma ORM, לא ב-TypeORM — כדאי לזכור לפעם הבאה"
• העדפות סגנון: "המשתמש תמיד מבקש הערות בעברית בקוד — זו העדפה קבועה"
• בעיות שנפתרו: "הבעיה עם ה-CORS headers נפתרה על ידי הוספת stripe.com ל-allowed origins — אם נתקלים בזה שוב, זה הפתרון"
• נתיבי קבצים חשובים: "הקונפיגורציה הראשית נמצאת ב-config/production.ts, לא ב-root"
• מוסכמות צוות: "בפרויקט הזה משתמשים ב-pnpm, לא npm. אסור להריץ npm install"

המידע נשמר בתיקייה ~/.claude/memory/ כברירת מחדל, כקבצי טקסט שClaude קורא בתחילת כל שיחה חדשה. זה כמו פתקיות Post-It שClaude מדביק על המסך שלו לפני שהוא מתחיל לעבוד — תזכורות לעצמו ממה שלמד בשיחות קודמות.

מבנה קובצי הזיכרון — MEMORY.md וקבצי נושא

הקובץ הראשי נקרא MEMORY.md — זהו אינדקס תמציתי שClaude שומר מתחת ל-200 שורות. זה הסף שנטען אוטומטית בתחילת כל שיחה. כש-MEMORY.md מתחיל להתמלא, Claude מפצל אוטומטית נושאים לקבצים נפרדים — debugging.md, patterns.md, architecture.md — ושומר ב-MEMORY.md רק קישורים והפניות. הקבצים המפורטים נטענים לפי הצורך, לא בכל שיחה.

~/.claude/projects/myproject/memory/
  MEMORY.md              # אינדקס ראשי (~200 שורות מקס) — נטען תמיד
  debugging.md           # טיפים ופתרונות לבעיות חוזרות
  patterns.md            # דפוסי קוד ומוסכמות שClaude גילה
  architecture.md        # תובנות ארכיטקטוניות
  preferences.md         # העדפות המשתמש (סגנון, שפה, כלים)

נקודה חשובה: לכל פרויקט יש תיקיית Auto-Memory נפרדת, שנגזרת מנתיב ה-Git Repository. כל ה-Worktrees של אותו Repo חולקים את אותו Auto-Memory — שינוי בשיחה אחת זמין מיד בשיחה אחרת על אותו פרויקט. זה מנגנון שלמדנו עליו בפרק 6 (Worktrees) — עכשיו אתה מבין איך הוא עובד מאחורי הקלעים.

ניהול Auto-Memory עם /memory

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

מה נשמר אוטומטית ומה לא

Claude לא שומר הכל — יש לו שיקול דעת לגבי מה חשוב מספיק להישמר. הנה ההבחנה:

נקודה חשובה שכדאי לזכור: Auto-Memory מנוטרל לחלוטין במצב --bare (שנוסף במרץ 2026 למצב -p, ומיועד ל-CI/CD ואוטומציה). זה הגיוני — Pipeline אוטומטי צריך לרוץ בצורה דטרמיניסטית (זהה בכל פעם), ו-Auto-Memory שמשתנה בין ריצות יפגע בדטרמיניזם הזה. ב---bare גם Hooks, LSP, סריקת Plugins, ו-Skills לא פעילים — הכל מופשט למינימום.

Custom Memory Directories — תיקיות זיכרון מותאמות

ברירת המחדל של Auto-Memory היא שמירה ב-~/.claude/memory/ — תיקייה גלובלית במחשב שלך שמכילה זיכרונות מכל הפרויקטים. זה עובד, אבל יש כמה מגבלות: הזיכרון לא חלק מה-Git של הפרויקט (אי אפשר לעקוב אחרי שינויים), הוא ספציפי למחשב שלך (לא עובר בין מכונות), וזיכרונות מפרויקט אחד עלולים "לזהם" פרויקט אחר.

ההגדרה autoMemoryDirectory (נוספה במרץ 2026) פותרת את כל הבעיות האלה. היא מאפשרת לך להגדיר תיקייה מותאמת לכל פרויקט:

{
  "autoMemoryDirectory": ".claude/memory/"
}

למה זה משנה? שלושה יתרונות מיידיים:

1. Version Control: הוסיפו את .claude/memory/ ל-Git. עכשיו אתם יכולים לעקוב אחרי מה Claude למד לאורך זמן — מתי הוא גילה שהפרויקט עבר מ-MongoDB ל-Postgres, מתי הוא שמר את ההעדפה שלכם ל-pnpm. זה גם מאפשר git blame על שינויי זיכרון, ו-git revert אם Claude שמר משהו שגוי.

2. הפרדה בין פרויקטים: כל פרויקט עם זיכרון עצמאי. פרויקט React לא "מזהם" פרויקט Python. פרויקט ישן לא זולג לפרויקט חדש.

3. שיתוף צוותי: כשה-Memory Directory הוא חלק מה-Git, כל חבר צוות שעושה git pull מקבל את הזיכרון המשותף. Claude לומד מכולם.

זיכרון משותף לצוות — תרחיש מתקדם

תרחיש מעניין במיוחד: כל חברי הצוות מכוונים את autoMemoryDirectory לאותה תיקייה (דרך Git). כשClaude לומד משהו חדש בשיחה של מפתח אחד — כל הצוות נהנה אחרי ה-Pull הבא. לדוגמה:

• מפתח א' מגלה ש-API מסוים דורש Header מיוחד — Claude שומר ל-Memory
• מפתח ב' עושה git pull — הזיכרון מתעדכן
• בשיחה הבאה של מפתח ב', Claude כבר יודע על ה-Header

נקודה חשובה: Claude קורא גם את תיקיית ברירת המחדל (~/.claude/memory/) וגם את התיקייה המותאמת. הוא משלב ידע משני המקורות. זה אומר שהעדפות אישיות גלובליות (שפה, סגנון) ממשיכות לפעול גם בפרויקט עם זיכרון מותאם — הן לא נמחקות, הן מצטרפות.

CLAUDE.md — הקשר שנשאר לנצח

אם Auto-Memory הוא הזיכרון ש-Claude מנהל (כמו פתקיות שהוא כותב לעצמו), אז CLAUDE.md הוא הזיכרון שאתה מנהל. זהו הכלי הכי חשוב וחזק בכל מערכת הזיכרון של Claude Code — כי הוא נטען אוטומטית בתחילת כל שיחה, בלי שום פעולה מצידך, בלי שום פקודה, בלי שום הגדרה.

חשוב על CLAUDE.md כמו מסמך Onboarding (חפיפה) — אותו מסמך שאתה נותן לעובד חדש ביום הראשון: "הנה מה שאתה צריך לדעת כדי לעבוד בפרויקט הזה." כל מה שעובד חדש צריך: איזה Tech Stack אנחנו משתמשים, מה הפקודות החשובות, מה הסטנדרטים, מה המלכודות שצריך להיזהר מהן. זה בדיוק מה שClaude קורא ברגע שהוא מתחיל שיחה.

ההיררכיה — שלוש שכבות של CLAUDE.md

יש שלושה מיקומים אפשריים לקובצי CLAUDE.md, וClaude קורא את כולם ומשלב ביניהם. זה עובד כמו מערכת שכבות — הכללי פועל תמיד, והספציפי מוסיף או דורס:

ההיררכיה עובדת כמו CSS: הספציפי דורס את הכללי. אם CLAUDE.md הגלובלי אומר "כתוב באנגלית" וCLAUDE.md של הפרויקט אומר "כתוב בעברית", Claude יכתוב בעברית בפרויקט הזה. אבל בפרויקט אחר בלי CLAUDE.md פרויקטי — הוא יחזור לאנגלית.

CLAUDE.md גלובלי — העדפות אישיות שפועלות בכל מקום

הקובץ ~/.claude/CLAUDE.md מכיל את ברירות המחדל שלך שמתאימות לכל פרויקט. כותבים אותו פעם אחת ומעדכנים לעיתים רחוקות:

## Communication
- Always respond in Hebrew, keep technical terms in English
- Be concise — short paragraphs, bullet points preferred
- When suggesting changes, explain WHY before HOW
- Don't apologize for mistakes — just fix them

## Safety Rules
- NEVER commit .env files or any file containing secrets
- NEVER amend existing git commits unless I explicitly ask
- Before any destructive operation (rm -rf, DROP TABLE), ask for confirmation
- NEVER force-push to main/master branch

## Coding Preferences
- Use pnpm over npm in all projects
- Prefer TypeScript over JavaScript
- Testing framework: Vitest (not Jest)
- Always use const over let, never use var
- Imports sorted: external > internal > relative

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

CLAUDE.md פרויקטי — הכוכב של מערכת הזיכרון

הקובץ ./CLAUDE.md בשורש הפרויקט הוא החלק הכי חשוב. הנה מבנה מומלץ שכולל את כל מה שClaude צריך כדי לעבוד ביעילות:

# Project: PayFlow — מערכת תשלומים לעסקים קטנים

## Architecture
- Next.js 14 (App Router) + TypeScript
- Database: PostgreSQL via Prisma ORM
- Auth: NextAuth.js with Google + Email providers
- Payments: Stripe Israel integration (ILS currency)
- Hosting: Vercel (production), local Docker (development)

## Key Commands
- `pnpm dev` — start dev server (port 3000)
- `pnpm test` — run Vitest tests
- `pnpm db:push` — push Prisma schema to database
- `pnpm db:seed` — seed database with test data
- `pnpm lint` — ESLint + Prettier check
- `pnpm build` — production build (run before deploying)

## Directory Structure
- src/app/ — Next.js pages and API routes
- src/lib/ — shared utilities and helpers
- src/components/ — React components (use shadcn/ui)
- src/types/ — TypeScript type definitions
- prisma/ — database schema and migrations
- tests/ — integration and e2e tests

## Important Decisions
- [2026-01] Chose Prisma over TypeORM for better DX and native Next.js support
- [2026-02] Moved from MongoDB to PostgreSQL — relational data model fits better
- [2026-03] Using Server Components by default, Client Components only when needed
- [2026-03] Chose shadcn/ui over MUI — lighter, more customizable

## Coding Standards
- All functions must have JSDoc comments
- API routes return { success: boolean, data?: T, error?: string }
- Use Zod for input validation on all API routes
- Imports sorted: external > internal > relative
- Error messages in Hebrew for user-facing, English for logs

## Known Gotchas
- Stripe webhooks need `export const config = { api: { bodyParser: false } }`
- Prisma Client must be instantiated as singleton in development (see src/lib/prisma.ts)
- Hebrew text in emails requires explicit dir="rtl" attribute
- Vercel has 10-second timeout on free plan — use background jobs for long operations

שים לב למבנה: ארכיטקטורה, פקודות, מבנה תיקיות, החלטות חשובות (עם תאריכים!), סטנדרטים, ומלכודות ידועות. זה כל מה שעובד חדש צריך לדעת ביום הראשון — וזה בדיוק מה שClaude צריך כדי לעבוד נכון מהשיחה הראשונה.

גודל CLAUDE.md — הכלל הכי חשוב

הנה משהו שחשוב להבין: כל טוקן ב-CLAUDE.md צורך מקום ב-Context Window. קובץ CLAUDE.md של 1,000 שורות (כ-10K טוקנים) אוכל 5% מ-Context Window סטנדרטי של 200K. זה אולי נשמע מעט, אבל מצטבר: Auto-Memory צורך עוד 2-3%, Rules עוד 1-2%, כל קובץ שClaude קורא עוד 1-5%. פתאום 10-15% מה-Context נלקח עוד לפני שהתחלת לעבוד.

Timestamps — טריות המידע

מגרסה 2.1.0 (ינואר 2026), קבצי CLAUDE.md כוללים חותמות זמן (Timestamps) של עדכון אחרון (Last Modified). Claude משתמש בזה כדי להעריך טריות (Freshness): הוא רואה שההוראה הזו עודכנה לפני 3 חודשים ומקבל אינדיקציה שאולי היא כבר לא רלוונטית. בגרסאות מרץ 2026 המנגנון הזה משופר עוד יותר — Claude משקלל את הטריות כשהוא מחליט כמה "לסמוך" על הוראה מסוימת. זה אומר שחשוב לעדכן את CLAUDE.md באופן שוטף כשהפרויקט משתנה — לא רק כדי שהמידע יהיה נכון, אלא גם כדי שClaude יידע שהמידע טרי ואמין.

/init — התחלה מהירה כשאתה לא יודע מאיפה להתחיל

הפקודה /init מנתחת את מבנה הפרויקט שלך — קוראת package.json, requirements.txt, Dockerfile, מבנה תיקיות, וקבצי קונפיגורציה — ויוצרת CLAUDE.md ראשוני שכולל את מה שהיא גילתה. זו נקודת פתיחה מצוינת, אבל תמיד תערוך ותשפר ידנית אחרי שClaude יוצר את הטיוטה. Claude לא יודע על ההחלטות שלך, המוסכמות הבלתי-כתובות, והמלכודות הספציפיות — את כל אלה רק אתה יכול להוסיף.

.claude/rules/ — הוראות מותנות וממוקדות

CLAUDE.md הוא כללי — כל מה שבתוכו נטען תמיד, בכל שיחה, לא משנה על מה עובדים. אבל מה אם יש לך כללים שרלוונטיים רק לחלק מהפרויקט? כללי סגנון TypeScript שלא רלוונטיים כשעובדים על Python Scripts. כללי API שלא רלוונטיים כשעובדים על ה-Frontend. הוראות Testing שלא נחוצות כשכותבים תיעוד. הוראות Docker שלא צריך כשעורכים CSS.

לשים את הכל ב-CLAUDE.md = בזבוז. כל הכללים נטענים תמיד, גם כשהם לא רלוונטיים, וכל אחד צורך טוקנים מה-Context Window. עם 50 כללים ב-CLAUDE.md, אתה מבזבז מאות טוקנים בכל שיחה על הוראות שClaude לא צריך באותו רגע.

כאן נכנסת תיקיית .claude/rules/ — מערכת כללים מודולרית עם הפעלה מותנית (Conditional Activation).

איך זה עובד

כל קובץ .md בתיקייה .claude/rules/ נטען אוטומטית, בדיוק כמו CLAUDE.md. אבל הקסם האמיתי הוא ב-YAML Frontmatter שמגדיר מתי הכלל נטען — רק כש-Claude עובד עם קבצים שמתאימים ל-Glob Pattern:

---
globs: ["*.ts", "*.tsx"]
---

# TypeScript Coding Standards

- Always use `interface` over `type` for object shapes
- Prefer `const` over `let` — never use `var`
- All exported functions must have explicit return types
- Use `unknown` instead of `any` — `any` is banned in our project
- Enums: use `const enum` for performance when possible
- Null handling: use `??` (nullish coalescing), not `||`
- Array iteration: prefer `.map()`, `.filter()`, `.reduce()` over `for` loops
- String templates: always use template literals, not concatenation

הכלל הזה נטען רק כש-Claude עורך קבצי TypeScript (*.ts או *.tsx). כשהוא עובד על Dockerfile או README.md — הכלל לא נטען ולא צורך טוקן אחד מה-Context Window.

---
globs: ["src/api/**", "src/app/api/**"]
---

# API Development Guidelines

- Every route must validate input with Zod schema before processing
- Standard response: { success: boolean, data?: T, error?: string }
- Error codes: 400 (validation), 401 (auth), 403 (forbidden), 404 (not found), 500 (internal)
- Rate limiting: 100 requests/minute per authenticated user
- Always log: method, path, status code, response time
- Hebrew error messages for user-facing errors, English for internal logs
- Pagination: cursor-based, not offset-based (better performance)
- Always use try/catch with specific error types

כלל זה פעיל רק כשClaude עובד בתיקיות API. עוד דוגמה שימושית במיוחד:

---
globs: ["**/*.test.ts", "**/*.spec.ts", "tests/**"]
---

# Testing Standards

- Framework: Vitest (NOT Jest — we migrated in Jan 2026)
- Every test file: describe() wrapping, clear test names in Hebrew
- Use `it.each()` for parameterized tests
- Mock external services — never make real HTTP calls in tests
- Minimum coverage: 80% for business logic, 60% for utilities
- Test file location: same directory as source, with .test.ts suffix
- Use `vi.fn()` for mocks, `vi.spyOn()` for spies
- Cleanup: always call `vi.clearAllMocks()` in afterEach()

---
globs: ["prisma/**", "src/lib/db/**", "**/repository.*"]
---

# Database Guidelines

- ORM: Prisma (schema in prisma/schema.prisma)
- Always use transactions for multi-step operations
- Use `findUniqueOrThrow` over `findUnique` when record must exist
- Soft delete: use deletedAt column, never hard delete user data
- Indexes: every foreign key must have an index
- Naming: tables in PascalCase, columns in camelCase
- Migrations: always test with `pnpm db:push` before creating migration

Rules בלי Globs — כללים שנטענים תמיד

לא כל Rule צריך Conditional Activation. קובץ .md בתוך .claude/rules/ בלי frontmatter נטען תמיד, בדיוק כמו CLAUDE.md. זה שימושי לכללים שרלוונטיים תמיד אבל רוצים לשמור אותם בקובץ נפרד — למשל, כללי בטיחות, מוסכמות Git, או הוראות Code Review. היתרון: מודולריות ותחזוקה קלה, בלי לנפח את CLAUDE.md הראשי.

# Git Conventions

- Commit messages: conventional commits format (feat:, fix:, refactor:, docs:, test:)
- Branch naming: feature/ticket-number-description, bugfix/ticket-number-description
- Never force-push to main or develop branches
- Always rebase feature branches on develop before PR
- PR description must include: what, why, how to test

תת-תיקיות לארגון

בפרויקטים גדולים, אפשר לארגן Rules בתת-תיקיות לפי דומיין:

• .claude/rules/frontend/ — כללי React, CSS, Accessibility, Components
• .claude/rules/backend/ — כללי API, Database, Auth, Background Jobs
• .claude/rules/devops/ — כללי Docker, CI/CD, Deployment, Monitoring
• .claude/rules/security/ — כללי Input Validation, CORS, CSP Headers

למה Rules עדיפים על CLAUDE.md ענק?

מה שמים איפה — מטריצת הזיכרון

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

כלל אצבע: אם תשאל את אותה שאלה שוב מחר — זה שייך ל-CLAUDE.md או Auto-Memory. אם זה רלוונטי רק לסוג קבצים מסוים — זה שייך ל-Rules. אם זה חד-פעמי ולא ישפיע על שום דבר אחר — השאר אותו בשיחה ואל תשמור.

המשכיות שיחה — /resume ו-/fork

מערכת הזיכרון שבנינו (CLAUDE.md, Rules, Auto-Memory) פותרת את בעיית ה"מי אני ומה הפרויקט." Claude מתחיל כל שיחה עם הקשר בסיסי. אבל מה קורה כשאתה רוצה להמשיך שיחה ספציפית? כשעצרת באמצע Refactoring מורכב ורוצה לחזור בדיוק לנקודה ההיא, עם כל ההקשר שנצבר?

/resume — המשך מאיפה שעצרת

הפקודה /resume (או הפעלה עם claude --resume) טוענת מחדש את השיחה האחרונה — כולל היסטוריית הודעות, הקשר שנצבר, פלטי כלים, וכל מה שנעשה. אפשר גם claude --continue או claude -c כקיצור נוח. לחידוש שיחה ספציפית לפי ID: claude -r "session-id". זה כמו לפתוח את הלפטופ אחרי הפסקה ולראות את כל החלונות פתוחים מאיפה שעצרת — שום דבר לא אבד.

פרט טכני חשוב: גרסה 2.1.80 תיקנה בעיה משמעותית בשחזור זוגות tool_use/tool_result. בגרסאות ישנות יותר, Resume של שיחה עם קריאות כלים מרובות לפעמים "שבר" את ההקשר. מגרסה 2.1.80 ומעלה — Resume עובד בצורה חלקה לחלוטין, גם בשיחות מורכבות.

/fork — הסתעפות לניסוי בטוח

/fork יוצר עותק (Clone) של השיחה הנוכחית. השיחה המקורית נשארת כמו שהיא — ללא שינוי — וההסתעפות ממשיכה באופן עצמאי. מה-CLI אפשר גם claude --fork-session "session-id" כדי ליצור Fork של שיחה קיימת ישירות מהטרמינל. זה בדיוק כמו git branch אבל לשיחות: שני כיוונים שונים מאותה נקודת פיצול.

למה זה שימושי? כי לפעמים אתה רוצה לנסות כיוון אחר בלי לסכן את מה שכבר בנית:

Resume לעומת שיחה חדשה — מתי מה?

דפוס "רענון ההקשר" (Context Refresh Pattern)

גישה חכמה לחידוש עבודה כשה-Resume לא מתאים: פתח שיחה חדשה וספק הקשר ידנית בהודעה הראשונה. זה נקי יותר מ-Resume על שיחה ישנה כי: (1) אין הקשר ישן שמזהם, (2) אתה שולט בדיוק מה Claude יודע, (3) פחות טוקנים מבוזבזים:

"אתמול עבדתי על אינטגרציית Stripe בפרויקט PayFlow.
השינויים ב-branch feature/stripe-checkout.
מה שעשינו:
- Checkout session creation — עובד ונבדק
- Success/cancel pages — עובדות
מה שנשאר:
- Webhook handler ל-payment_intent.succeeded
- עדכון status ב-DB אחרי תשלום מוצלח
- טסטים ל-webhook handler"

3 שורות של הקשר = Claude יודע בדיוק מאיפה להמשיך, בלי לטעון 200 הודעות מהשיחה הקודמת.

אופטימיזציית Context Window — חיסכון של 25-45%

ה-Context Window הוא המשאב היקר ביותר בשיחת Claude Code. כל דבר שClaude "רואה" — כל קובץ שנקרא, כל פלט של כלי, כל הודעה בשיחה — צורך טוקנים מהחלון הזה. כשנגמר המקום (כ-95% קיבולת), מופעלת Auto-Compaction — דחיסה אוטומטית שמסכמת את השיחה ומאבדת חלק מההקשר הישן. הסף המדויק משתנה לפי מודל — Opus מפעיל דחיסה מוקדם יותר מ-Sonnet — אבל בפועל, ברוב המקרים Auto-Compaction מתחילה כשנותרו 5-25% מהחלון. ניהול חכם של Context = שיחות ארוכות יותר, עקביות טובה יותר, ופחות עלות כספית.

מפת צריכת הטוקנים — לאן הם הולכים?

כדי לנהל Context בצורה חכמה, צריך להבין מה צורך כמה. הנה התפלגות טיפוסית בשיחה של 200K:

עם 1M Context (Opus 4.6, Max/Team/Enterprise) — המספרים האלה הופכים לשוליים. CLAUDE.md של 8K טוקנים צורך פחות מ-1% מ-1M. אבל גם עם 1M, כל טוקן עולה כסף — Opus 4.6 מתומחר ב-$5/$25 לכל מיליון טוקנים (input/output), ללא מכפיל לחלון גדול. שיחה שצורכת 800K טוקנים עולה יותר משיחה שצורכת 200K, גם אם שתיהן מצליחות. ניהול חכם = לא רק שיחות ארוכות יותר, אלא גם חשבון חודשי נמוך יותר.

Plan Mode — חיסכון של 25-45% מהטוקנים

הפעלת Plan Mode (Shift+Tab פעמיים, או הפקודה /plan) משנה את אופן העבודה של Claude: במקום לנתח ולבצע בו-זמנית, הוא קודם מנתח את המשימה ומציע תוכנית מפורטת. רק אחרי שמאשרים — הוא מבצע. הקסם: כשמאשרים תוכנית, ה-Context מתנקה אוטומטית. כל הניתוח הארוך שClaude עשה לא נשאר בזיכרון — רק התוכנית עצמה. זה חוסך 25-45% מצריכת הטוקנים.

/compact — דחיסה חכמה לפי דרישה

הפקודה /compact דוחסת את השיחה — Claude מסכם את מה שקרה עד עכשיו, שומר מידע מפתח, ומשחרר את כל השאר. הכוח האמיתי הוא בהוראות מותאמות שאומרות ל-Claude מה לשמור:

compactInstructions — הוראות דחיסה קבועות שעובדות תמיד

במקום לציין הוראות Compact בכל פעם מחדש, הגדר compactInstructions פעם אחת — ב-CLAUDE.md או ב-settings.json. ההוראות האלה יחולו על כל Compact, גם ידני וגם אוטומטי:

## Compact Instructions

When compacting context, ALWAYS preserve:
- Current task state and pending items
- File paths being actively worked on
- API endpoint URLs and response formats
- Error messages and their root causes (if debugging)
- Database schema changes in progress
- Test results (pass/fail) from the current session

Always DROP:
- Tool call details and intermediate search results
- Verbose log output and stack traces (keep only the error message)
- Full file contents that were already read (keep only the relevant sections)
- Exploration paths that didn't lead anywhere

כל פעם שClaude עושה Compact — ידני (אתה מקליד /compact) או אוטומטי (הגיע ל-80% קיבולת) — הוא עוקב אחרי ההוראות האלה. זה מבטיח שמידע קריטי לא נעלם בדחיסה, ומידע לא חשוב משתחרר.

טכניקות חיסכון נוספות שעובדות מיד

/context — ניטור צריכה בזמן אמת

הפקודה /context מציגה את מצב ה-Context Window הנוכחי: כמה טוקנים נצרכו, כמה נותרו, מה האחוז עד Auto-Compaction, והצעות לאופטימיזציה. השתמש ב-/context כמו "מד דלק" — תבדוק מדי פעם כדי לדעת כמה מקום נשאר לפני שתצטרך לדחוס.

דפוס "תקציב Context" (Context Budget): התייחס ל-Context כמו לתקציב כספי. כל קובץ שנקרא, כל פלט כלי, כל שורה בשיחה — עולה טוקנים. כמו שלא קונים 10 מוצרים כשצריכים אחד, ככה לא קוראים 10 קבצים כשצריכים לראות פונקציה אחת. תקרא רק מה שצריך, תדחוס באופן קבוע, ותשתמש ב-Fork לחקירות צדדיות.

מתן שם ואירגון שיחות

כשיש לך 20 שיחות Claude Code מהשבוע האחרון, איך מוצאים את השיחה הנכונה לעשות עליה Resume? Session Naming (מתן שם לשיחות) הופך את "Session #47" ל-"payments-integration-0323" — ומיד ברור מה עשית שם ומתי.

שלוש דרכים לתת שם לשיחה

מוסכמת שמות מומלצת

פורמט: [project]-[task]-[date]

• payflow-stripe-0323 — אינטגרציית Stripe, 23 במרץ
• payflow-auth-fix-0324 — תיקון Authentication, 24 במרץ
• payflow-db-migration-0325 — מיגרציית Database, 25 במרץ
• payflow-perf-0326 — אופטימיזציית ביצועים, 26 במרץ

לצוותים: הוסיפו את שם המפתח: payflow-nadav-stripe-0323. ככה אפשר לחפש בהיסטוריה את כל השיחות של מפתח מסוים על נושא מסוים.

בשילוב עם Auto-Memory, מתן שם עקבי לשיחות יוצר היסטוריה ניתנת לחיפוש. כשאתה פותח שיחה חדשה ואומר "מה עבדנו עליו בנושא Stripe?", Claude יכול להסתמך על שמות השיחות ב-Auto-Memory כדי לתת תשובה מדויקת.

אסטרטגיות התמדה מתקדמות

CLAUDE.md, Rules, ו-Auto-Memory הם הבסיס — הם פותרים 80% מבעיית הזיכרון. אבל Power Users צריכים עוד שיטות שמכסות את ה-20% הנותרים: זיכרון של "למה" (לא רק "מה"), מעקב בין שיחות על משימות ארוכות, וזיכרון מהיסטוריית ה-Git.

Architecture Decision Records (ADRs) — הזיכרון של "למה"

ADR (Architecture Decision Record) הוא מסמך קצר שמתעד החלטה ארכיטקטונית ואת הסיבה מאחוריה. CLAUDE.md אומר "אנחנו משתמשים ב-PostgreSQL." ADR אומר "למה עברנו ל-PostgreSQL, מה שקלנו, ומה ההשלכות." זה ה"זיכרון של למה."

בלי ADRs, Claude עלול להציע לחזור ל-MongoDB — כי הוא לא יודע שכבר ניסיתם ועברתם ממנו בגלל סיבות ספציפיות. עם ADR, Claude קורא את הנימוק ומבין שלא כדאי לחזור.

# ADR-003: Move from MongoDB to PostgreSQL

## Status: Accepted (January 2026)

## Context
Our data model became increasingly relational — users have orders,
orders have items, items reference products. MongoDB required
data duplication and couldn't enforce referential integrity.
We had 3 bugs in Q4 2025 caused by orphaned references.

## Decision
Migrate to PostgreSQL with Prisma ORM.

## Alternatives Considered
- TypeORM: more mature but worse DX, heavy decorators
- Drizzle: too new, less community support at the time
- Keep MongoDB + Mongoose: doesn't solve the relational problem

## Consequences
- Better data integrity (foreign keys, unique constraints, check constraints)
- Prisma migration system for safe schema evolution
- Need to rewrite all database queries (estimated 2 weeks)
- Team needs to learn SQL basics (most were NoSQL-only)

שמרו ADRs בתיקיית decisions/ בשורש הפרויקט. הוסיפו את התיקייה ל-Git. Claude יכול לקרוא אותם כשצריך להבין למה משהו מסוים נבחר.

סיכומי שיחה (Session Summaries) — זיכרון מובנה

בסוף כל שיחה משמעותית, בקש מ-Claude סיכום מובנה:

"Summarize what we accomplished today in a structured format:
1. What was completed
2. What's still in progress
3. What's blocked and why
4. Important decisions made
5. Files that were modified"

שמור את הסיכום בקובץ (למשל sessions/2026-03-23-stripe.md). בשיחה הבאה, ספק את הסיכום כהקשר ראשוני — ו-Claude ימשיך בדיוק מאיפה שעצרת. Auto-Memory תופס חלק מזה אוטומטית, אבל סיכום מפורש שאתה כותב הוא מקיף ומדויק יותר.

קובץ CURRENT-TASK.md — מעקב בין שיחות למשימות ארוכות

למשימות שנמשכות כמה ימים (Sprint של שבוע, אינטגרציה מורכבת, מיגרציה), נהל קובץ CURRENT-TASK.md בשורש הפרויקט:

# Current Task: Stripe Payment Integration

## Status: In Progress (Day 3 of estimated 5)

## Completed
- [x] Stripe SDK setup and configuration
- [x] Checkout session creation endpoint
- [x] Success/cancel redirect pages
- [x] Price calculation with ILS currency support

## In Progress
- [ ] Webhook handler for payment events
  - payment_intent.succeeded — started, needs testing
  - payment_intent.payment_failed — not started
  - charge.refunded — not started

## Blocked
- Need Stripe webhook secret for production (waiting on DevOps — asked March 22)

## Notes for Next Session
- Use idempotency keys on all Stripe API calls
- Test with Stripe CLI: `stripe listen --forward-to localhost:3000/api/webhooks`
- Remember: bodyParser must be disabled for webhook endpoint

עדכנו את הקובץ בסוף כל שיחה. Claude קורא אותו בתחילת השיחה הבאה ומיד יודע: מה עשינו, מה נשאר, מה חוסם.

Git כזיכרון — הודעות Commit שClaude יכול לקרוא

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

שילוב זיכרון עם Hooks ו-Worktrees — הסינרגיה המלאה

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

סיכום שבועי של CLAUDE.md — 10 דקות שחוסכות שעות

כל שבוע, הקדישו 10 דקות לסקירת מערכת הזיכרון. זו ההשקעה עם ה-ROI הכי גבוה בכל מה שלמדנו:

• הסירו הוראות מ-CLAUDE.md שכבר לא רלוונטיות
• הוסיפו מוסכמות חדשות שנקבעו השבוע
• עדכנו תיאור ארכיטקטורה אחרי שינויים גדולים
• בדקו ש-Auto-Memory לא מכיל מידע שגוי (/memory)
• עדכנו Rules אם הסטנדרטים השתנו

Frameworks להחלטות

Framework 1: "היררכיית הזיכרון" — מה שמים איפה

כשיש לך מידע חדש שClaude צריך לדעת, עבור על עץ ההחלטות הזה:

Framework 2: "Resume לעומת Fresh Start" — מתי לחדש ומתי להתחיל מחדש

Framework 3: "גודל הזיכרון" — כמה מידע לשים ב-CLAUDE.md

טעויות נפוצות — מה לא לעשות עם מערכת הזיכרון

שגרת עבודה — תחזוקת זיכרון שוטפת

מערכת זיכרון היא לא "הגדר ושכח" — היא דורשת תחזוקה שוטפת כדי להישאר מדויקת ויעילה. בנוסף לשגרת ה-Hooks מפרק 1 ושגרת ה-Worktrees מפרק 6 — הנה שגרת הזיכרון:

תרגילים מעשיים

תרגיל 1: בניית מערכת זיכרון מלאה מאפס

תרגיל 2: מיגרציה מ-CLAUDE.md מונוליטי ל-Rules

תרגיל 3: Resume, Fork, וניהול שיחות

תרגיל 4: Context Budget Challenge

אם אתה עושה רק דבר אחד

בדוק את עצמך

סיכום הפרק

צ'קליסט — זיכרון והמשכיות