ה-Loop שעובד בזמן שאתה ישן: Cron + Eval + Reflexion

מנטליותמודל מנטלי למה "סוכן שמחכה לך" הוא עדיין צוואר בקבוק

בוא נחזור רגע לבעיה שפתחנו בה את הקורס. בפרק 1 אמרנו: אם אתה פותח ChatGPT, מבקש משימה, מקבל תשובה, וחוזר חלילה — אתה לא operator, אתה עדיין צוואר הבקבוק היחיד. בפרק 2 נתת לסוכן תפקיד. בפרק 3 נתת לו נוהל. אבל יש משהו ששני הפרקים האלה לא פתרו: מי לוחץ על "הפעל"?

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

ה-loop הוא שלושה רכיבים שמחוברים למעגל אחד:

• Cron — השעון. הוא מפעיל את הסוכן בתזמון קבוע, בלי שאף אחד יבקש. זה מה שהופך "מחכה לך" ל"רץ לבד".
• Eval — המבחן. לפני שהפלט יוצא החוצה (ללקוח, אליך, לדף), scorer אוטומטי מנקד אותו מול דוגמאות-זהב. זה מה ששומר על איכות בלי שתקרא כל פלט.
• Reflexion — הזיכרון. אחרי כל ריצה הסוכן כותב לעצמו "מה הייתי צריך לעשות אחרת", ושומר את זה. זה מה שהופך "רץ לבד" ל"משתפר לבד".

שים לב לסדר ההגיוני: cron בלי eval = סוכן שרץ לבד אבל אף אחד לא בודק אותו (מתכון לאסון). cron + eval בלי reflexion = סוכן שלא שובר את אותו ראש פעמיים אבל גם לא לומד — הוא נופל באותה מהמורה כל בוקר. שלושתם ביחד הם מנוע שיפור עצמי: רץ, נבדק, לומד, חוזר. זה ה-loop ש"עובד בזמן שאתה ישן" — וגם משתפר בזמן שאתה ישן.

Cronתזמוןטכני רכיב 1 — Cron: חמשת דפוסי התזמון של 2026

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

לרוב המקרים של operator סולו, cron הוא ברירת המחדל הנכונה. הוא הכי פשוט, הכי צפוי, והכי קל לנפות. נתחיל ממנו, ונשאיר event-driven ו-adaptive לתפקידים שבאמת צריכים אותם (פרק 7 חוזר לזה כשנרכיב את הצי המלא).

קריאת crontab — התחביר ב-5 שדות

cron הוא תוכנת תזמון ותיקה שקיימת בכל מערכת לינוקס/Mac. אתה כותב שורה אחת בקובץ שנקרא crontab, והמערכת מריצה את הפקודה שלך בזמן שביקשת. התחביר הוא חמישה שדות + הפקודה:

# ┌───────── דקה (0-59)
# │ ┌─────── שעה (0-23)
# │ │ ┌───── יום בחודש (1-31)
# │ │ │ ┌─── חודש (1-12)
# │ │ │ │ ┌─ יום בשבוע (0-6, 0=ראשון)
# │ │ │ │ │
# * * * * *  command-to-run

# כל יום ב-06:00 בבוקר — זה ה-morning brief שלנו:
0 6 * * *  cd /home/you/fleet && /usr/bin/python3 morning_brief.py >> logs/brief.log 2>&1

שלוש מילים על השורה האחרונה, כי בה מסתתרות שתי טעויות-זהב:

• cd /home/you/fleet && — cron לא רץ מהתיקייה שלך. אם לא תיכנס לתיקייה הנכונה, הסקריפט לא ימצא את .context/ ואת קובצי הסביבה. זו הטעות מספר 1 של מתחילים ב-cron.
• נתיב מלא ל-Python (/usr/bin/python3) — ל-cron אין את ה-PATH שיש לך ב-Terminal. תן נתיב מלא. (בדוק עם which python3.)
• >> logs/brief.log 2>&1 — הפנה הכל ללוג. בלי זה, אם הסוכן נכשל ב-2 בלילה, אין שום עקבה. זה הגרעין של ה-dead-agent alerting שנבנה בהמשך.

0 6 * * *      → כל יום ב-06:00
*/15 * * * *   → כל 15 דקות (heartbeat)
0 9 * * 1      → כל יום שני ב-09:00 (דוח שבועי)
0 */2 * * *    → כל שעתיים
30 8 1 * *     → ה-1 בכל חודש ב-08:30 (P&L חודשי)

Self-host מול Managed: איפה רץ השעון

יש לך שתי דרכים להריץ סוכן מתוזמן, ולכל אחת trade-off ברור:

Hermes Agent (של Nous Research, שוחרר ב-25 בפברואר 2026) הוא daemon פתוח (open-source) שרץ באופן רציף, מתזמן משימות cron, ושומר זיכרון בין סשנים. "daemon" הוא תהליך-רקע שרץ כל הזמן בלי חלון — כמו עובד שיושב בשרת ולא הולך הביתה. היתרון: $0 על infra, אתה משלם רק את הטוקנים של ה-LLM מתחת. החיסרון, וזה קריטי: daemon ש"רץ בזמן שאתה ישן" גם נכשל בזמן שאתה ישן — נחזור לזה בחלק ה-gotchas.

Claude Code Routines הוא הצד השני: תזמון מרחוק על תשתית Anthropic, בלי שתשאיר מחשב דלוק. זה מוריד את הרף ל-operator שלא רוצה לתחזק שרת. ה-trade-off הוא פחות שליטה ותלות בספק.

*/5 * * * * cd /YOUR/PATH/fleet && echo "alive: $(date)" >> heartbeat.log

EvalאיכותGolden Set רכיב 2 — Eval Gate: לשמור איכות בלי לקרוא כל פלט

עכשיו הסוכן רץ לבד. אבל אם הוא רץ לבד — מי בודק שהפלט שלו טוב? אתה לא יכול לקרוא כל מייל שה-SDR שולח וכל סיכום שה-research agent מייצר. אם תקרא הכל, חזרת להיות צוואר הבקבוק. אם לא תקרא כלום, אתה משגר פלט בינוני (או שגוי) ללקוחות, אוטומטית, בקנה מידה.

הפתרון הוא eval gate: scorer אוטומטי שמנקד את הפלט מול golden dataset — אוסף של דוגמאות-ייחוס שאתה כבר יודע שהן טובות — לפני שהפלט מגיע ללקוח. הוא יושב כמו שער בין "הסוכן ייצר" ל"הפלט יוצא". פלט שעובר את הסף — ממשיך. פלט שנכשל — נחסם, מסומן, או מנותב אליך.

בלי golden set, ה-eval שלך הוא סתם LLM שמנחש

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

eval אמיתי מנקד מול דוגמאות-זהב. וכאן מתחבר פרק 3: תוצרי ה-dry-run שעשית — 3–5 מקרים אמיתיים מהחודש שעבר שעליהם הרצת את ה-SOP וחידדת אותו — הם הזרע של ה-golden set שלך. הרחב אותם ל-10+ מקרים, ויש לך נקודת ייחוס אמיתית. בלי golden set, כמו שאומר המחקר במפורש: ה-"eval" הוא רק עוד LLM שמנחש, והוא לא יתפוס regression אמיתי.

איך נראה golden case

כל פריט ב-golden dataset הוא קלט + מה אתה מצפה לראות בפלט. דוגמה ל-morning brief:

// golden/brief_cases.json — golden dataset ל-morning brief
[
  {
    "id": "case_01_normal_day",
    "input": {
      "revenue_today_ils": 1240,
      "support_open": 3,
      "competitor_signals": ["מתחרה X הוריד מחיר ל-99₪"],
      "inbox_highlights": ["לקוח Y שואל על חידוש"]
    },
    "must_contain": ["1240", "3 פניות", "חידוש"],
    "must_not_contain": ["undefined", "null", "[object Object]"],
    "max_words": 180
  },
  {
    "id": "case_02_empty_day",
    "input": { "revenue_today_ils": 0, "support_open": 0,
               "competitor_signals": [], "inbox_highlights": [] },
    "must_contain": ["אין", "שקט"],
    "must_not_contain": ["שגיאה"],
    "max_words": 80
  }
]

שים לב לרכיבים: must_contain (מה חייב להופיע — מספרים אמיתיים, לא placeholder), must_not_contain (סימני באג — undefined, null, מחרוזות ריקות), ו-max_words (brief שעובר 180 מילים הוא לא brief — הוא דוח). זה ה-rubric. הוא לא צריך להיות מתוחכם בהתחלה; הוא צריך לתפוס את הכשלים שכבר ראית ב-dry-run.

ה-scorer — 40 שורות Python שעובדות

עכשיו ה-scorer עצמו. הוא קורא את ה-golden cases, מריץ את הסוכן על כל input, ובודק את הפלט מול הכללים. זה קוד עובד — העתק, שנה נתיבים:

# eval_gate.py — scorer אוטומטי מול golden dataset
import json, re

def score_output(output: str, case: dict) -> dict:
    """מנקד פלט בודד מול golden case. מחזיר pass/fail + סיבות."""
    fails = []

    # 1. חייב להכיל את כל ה-must_contain
    for needle in case.get("must_contain", []):
        if needle not in output:
            fails.append(f"חסר: '{needle}'")

    # 2. אסור שיכיל אף must_not_contain (סימני באג)
    for bad in case.get("must_not_contain", []):
        if bad in output:
            fails.append(f"מופיע באג: '{bad}'")

    # 3. אורך — brief ארוך מדי נכשל
    words = len(re.findall(r"\S+", output))
    if words > case.get("max_words", 9999):
        fails.append(f"ארוך מדי: {words} מילים")

    return {"id": case["id"], "passed": len(fails) == 0, "fails": fails}

def run_gate(cases_path: str, agent_fn) -> dict:
    """מריץ את הסוכן על כל golden case ומחזיר pass-rate כולל."""
    cases = json.load(open(cases_path, encoding="utf-8"))
    results = [score_output(agent_fn(c["input"]), c) for c in cases]
    passed = sum(r["passed"] for r in results)
    rate = passed / len(results)
    return {"pass_rate": rate, "passed": passed,
            "total": len(results), "results": results}

if __name__ == "__main__":
    # agent_fn = הפונקציה שמייצרת את ה-brief (ב-morning_brief.py)
    from morning_brief import generate_brief
    report = run_gate("golden/brief_cases.json", generate_brief)
    print(f"pass-rate: {report['pass_rate']:.0%} "
          f"({report['passed']}/{report['total']})")
    for r in report["results"]:
        if not r["passed"]:
            print(f"  ✗ {r['id']}: {', '.join(r['fails'])}")

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

# פלט אמיתי לדוגמה מ-eval_gate.py:

pass-rate: 80% (8/10)
  ✗ case_03_missing_data: חסר: '847', ארוך מדי: 213 מילים
  ✗ case_07_competitor_alert: מופיע באג: 'undefined'

# מה לקרוא מהפלט הזה:
# 1. 80% — case 01, 02, 04, 05, 06, 08, 09, 10 עברו בסדר.
# 2. case_03 — הסוכן לא הזכיר את סכום ה-847₪ (השמיט נתון!) ו-brief ארוך מ-180 מילה.
# 3. case_07 — באג: יש "undefined" בפלט, כנראה שדה שלא מולא בנתונים.

• pass-rate מספרי — "8 מתוך 10 עברו = 80%". המספר הזה הוא לא רק לפה; בפרק 5 הוא הופך לסף שמטפסים בו בסולם האוטונומיה. אם ה-pass-rate מתחת ל-X, הסוכן לא מקבל אישור לפעול לבד.
• חוסם regression — אם ערכת את ה-SOP והפלט הידרדר, ה-gate יראה את ה-pass-rate צונח. זה בדיוק כמו CI/CD בקוד: שינוי ששובר את המבחנים לא עובר.
• זה rubric דטרמיניסטי — ה-scorer למעלה בודק מילים ואורך, בלי LLM נוסף, בלי טוקנים. לקריטריונים שדורשים שיפוט ("האם הטון מקצועי?") אפשר להוסיף LLM-as-judge — אבל גם הוא חייב golden references, אחרת חזרת לניחוש.

Reflexionזיכרוןשיפור-עצמי רכיב 3 — Reflexion: איך הסוכן לומד מטעויות בלי אימון מחדש

יש לנו סוכן שרץ לבד (cron) ונבדק לבד (eval). אבל מה קורה כשהוא נכשל? בלי הרכיב השלישי, התשובה היא: כלום. הוא ייכשל באותו אופן שוב מחר. Reflexion הוא הרכיב שהופך כישלון ללקח, ולקח לשיפור.

Reflexion היא טכניקה מתועדת ממאמר אקדמי (Shinn et al., 2023, arXiv 2303.11366) שבו סוכן מנסח במילים מה הוא למד מכישלון, ושומר את הניסוח הזה בזיכרון אפיזודי (episodic memory — זיכרון של "מה קרה בריצות קודמות"), כדי לעשות טוב יותר בניסיון הבא. הקסם: השיפור קורה בלי לעדכן את משקלי המודל — אין אימון, אין fine-tuning. הסוכן פשוט קורא את הלקחים שלו לפני שהוא פועל בפעם הבאה.

שלושת המודולים: Actor → Evaluator → Self-Reflection

המאמר מגדיר את ה-loop בשלושה מודולים, ושים לב כמה זה מתאים בדיוק למה שכבר בנינו:

ה-loop הוא: ה-Actor מייצר → ה-Evaluator מנקד → אם נכשל, ה-Self-Reflection כותב "מה הייתי צריך לעשות אחרת" → הלקח נשמר → בריצה הבאה ה-Actor קורא את הלקחים לפני שהוא פועל. ככה, כפי שמנסח template ה-OSS gru-ai, "ההנחיה ה-10 רצה טוב יותר מהראשונה" — כי היא נכתבת על גבי 9 לקחים.

הקוד: צעד ה-reflexion

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

# reflexion.py — צעד ה-Self-Reflection
import datetime
from anthropic import Anthropic   # ה-SDK של Claude

client = Anthropic()  # קורא ANTHROPIC_API_KEY מהסביבה

REFLECT_PROMPT = """אתה מנתח כישלון של סוכן כדי לכתוב לקח לעתיד.

הקלט שהסוכן קיבל:
{input}

הפלט שייצר (שנכשל ב-eval):
{output}

סיבת הכישלון:
{fails}

כתוב לקח אחד, קצר (משפט-שניים), פעולתי, בגוף ציווי
("בעתיד, כש... — עשה/אל תעשה..."). אל תתנצל, אל תסביר.
רק הלקח."""

def reflect(input_data, output, fails) -> str:
    msg = client.messages.create(
        model="claude-haiku-4-5",   # מודל זול — reflexion הוא משימה קלה
        max_tokens=120,
        messages=[{"role": "user", "content": REFLECT_PROMPT.format(
            input=input_data, output=output, fails="; ".join(fails))}],
    )
    return msg.content[0].text.strip()

def save_lesson(lesson: str, case_id: str, path=".context/lessons.md"):
    stamp = datetime.date.today().isoformat()
    line = f"- [{stamp}] (מתוך {case_id}, **לבדיקה**) {lesson}\n"
    with open(path, "a", encoding="utf-8") as f:
        f.write(line)
    return line

איך הלקחים מוזרקים חזרה

לקח שנשמר ולא נקרא הוא חסר ערך. הקטע האחרון: בתחילת כל ריצה, הסוכן טוען את .context/lessons.md ומדביק אותו ל-prompt שלו, אחרי ה-SOP. ככה:

# בתוך morning_brief.py, לפני שהסוכן פועל:
def load_lessons(path=".context/lessons.md") -> str:
    try:
        lessons = open(path, encoding="utf-8").read()
    except FileNotFoundError:
        return ""
    # רק לקחים שאושרו (לא מסומנים **לבדיקה**) נכנסים ל-prompt:
    approved = [l for l in lessons.splitlines()
                if l.strip() and "**לבדיקה**" not in l]
    if not approved:
        return ""
    return "לקחים מריצות קודמות (קח בחשבון):\n" + "\n".join(approved)

# ואז ה-prompt נבנה כך:
prompt = f"{SOP_TEXT}\n\n{load_lessons()}\n\nהקלט להיום:\n{todays_data}"

שים לב לשורה הקריטית: רק לקחים שלא מסומנים **לבדיקה** נכנסים ל-prompt. כל לקח חדש נכתב עם תג "לבדיקה" (ראית את זה ב-save_lesson), והוא לא משפיע על הסוכן עד שאתה מאשר אותו ידנית (מוחק את התג). זה לא קישוט — זה ההגנה מפני "לקח מורעל", והנושא של ה-gotcha הכי חשוב בפרק.

MAR — הרחבת 2026 (לידיעה)

אם תרצה להעמיק: הרחבה מ-2026 בשם MAR (Multi-Agent Reflexion, arXiv 2512.20845) מפרידה את ה-act / evaluate / critique לפרסונות שונות — סוכן שפועל, סוכן שמנקד, וסוכן שמבקר. זה רלוונטי לציים גדולים; ל-operator סולו שמתחיל, ה-loop של שלושה מודולים בקובץ אחד מספיק לחלוטין. אל תסבך לפני שיש לך loop בסיסי שעובד.

כשליםהגנותproduction שלושת כשלי-הליבה (ואיך מונעים כל אחד)

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

כשל 1 — Idempotency: עבודה כפולה ושליחה כפולה ללקוח

idempotency (אִי-דֶמְפּוֹטֶנְטִיוּת) פירושה: להריץ את אותה פעולה פעמיים נותן את אותה תוצאה כמו להריץ אותה פעם אחת. cron בלי idempotency הוא אסון: סוכן SDR שרץ כל שעה ו"מעבד את ה-inbox" יעבד שוב את אותם לידים בכל ריצה — ישלח לאותו לקוח את אותו מייל 24 פעם ביום. זה לא רק בזבוז טוקנים; זה נזק למוניטין מול לקוח אמיתי.

הפתרון: already-done marker — סימון שאומר "כבר טיפלתי בזה". לפני שהסוכן מטפל בפריט, הוא בודק אם הוא כבר עיבד אותו:

# idempotency.py — מונע עיבוד כפול
import json, os

DONE_FILE = ".context/processed.json"

def already_done(item_id: str) -> bool:
    if not os.path.exists(DONE_FILE):
        return False
    return item_id in json.load(open(DONE_FILE))

def mark_done(item_id: str):
    done = json.load(open(DONE_FILE)) if os.path.exists(DONE_FILE) else []
    done.append(item_id)
    json.dump(done, open(DONE_FILE, "w"))

# בשימוש:
for lead in incoming_leads:
    if already_done(lead["id"]):
        continue          # דלג — כבר טיפלנו
    process(lead)
    mark_done(lead["id"]) # סמן רק אחרי הצלחה

# lead_id: "roi-cohen-2026-06-15" הוכנס ל-CRM ב-09:00
# ריצה 09:00 → עיבד → שלח מייל היכרות → ✓
# ריצה 10:00 → "lead חדש!" → שלח מייל היכרות שני → ✗
# ריצה 11:00 → "lead חדש!" → שלח מייל היכרות שלישי → ✗
# ...
# ריצה 17:00 → "lead חדש!" → שלח מייל היכרות תשיעי → ✗

# רועי כהן קיבל 9 מיילים זהים ביום אחד.
# עלות טוקנים: 8 הרצות מיותרות × 2,000 טוקן = ~16,000 טוקן = ~₪3.20
# עלות מוניטין: רועי סימן את הדומיין כ-spam.

כשל 2 — Dead-agent alerting: ה-daemon שמת בשקט

זה הכשל הכי ערמומי, כי הוא בלתי-נראה. סוכן ש"רץ בזמן שאתה ישן" גם נכשל בזמן שאתה ישן. אם השרת קרס, ה-API key פג, או הסקריפט זרק חריגה ב-3 בלילה — הסוכן פשוט מפסיק. אין הודעת שגיאה שתראה, כי אתה ישן. אתה תגלה את זה רק כשלקוח יתלונן ש"לא קיבלתי תשובה" — וזה כבר מאוחר.

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

# watchdog.py — רץ ב-cron נפרד, מתריע אם הסוכן מת
import time, os, requests

HEARTBEAT = ".context/last_run.txt"
MAX_AGE_SECONDS = 26 * 3600   # brief יומי — מותר עד 26 שעות שקט

def alert(msg: str):
    # שלח ל-Telegram (או email/SMS) — זה ה-tripwire שלך
    requests.post(
        f"https://api.telegram.org/bot{os.environ['TG_TOKEN']}/sendMessage",
        json={"chat_id": os.environ["TG_CHAT"], "text": f"🚨 {msg}"})

if not os.path.exists(HEARTBEAT):
    alert("הסוכן morning_brief מעולם לא דיווח שהוא חי!")
else:
    age = time.time() - os.path.getmtime(HEARTBEAT)
    if age > MAX_AGE_SECONDS:
        alert(f"morning_brief שותק {age/3600:.0f} שעות — כנראה מת.")

# והסוכן עצמו, בסוף ריצה מוצלחת, כותב:
#   open(".context/last_run.txt", "w").write(str(time.time()))

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

# ה-watchdog רץ פעם בשעה, בדקה ה-30 — לא באותה דקה כמו הסוכן
30 * * * * cd /YOUR/PATH && /usr/bin/python3 watchdog.py >> logs/watchdog.log 2>&1

כשל 3 — Poisoned lesson: ה-reflexion שמרעיל את הצי

זה הכשל שהכי קל לפספס כי הוא נראה כמו תכונה. reflexion אמור לשפר את הסוכן — אבל מה אם הוא כותב לקח שגוי? נניח שביום אחד היו נתונים חריגים, והסוכן "למד" לקח שגוי: "כשהכנסות גבוהות מ-10,000₪ — כנראה טעות, התעלם". הלקח הזה נשמר בזיכרון האפיזודי, ומעכשיו כל ריצה עתידית קוראת אותו ומתעלמת מימים טובים. לקח אחד שגוי מרעיל את כל הצי, בשקט, לנצח.

הפתרון כבר בנוי בקוד שלנו, וזו הסיבה שבנינו אותו ככה: reflections דורשים review, לא אמון עיוור. כל לקח חדש נכתב עם תג **לבדיקה**, ו-load_lessons לא מזריק לקחים מסומנים ל-prompt. הלקח משפיע רק אחרי שאתה קראת אותו ומחקת את התג ידנית. זה צעד שלוקח 10 שניות בשבוע, והוא ההבדל בין "הסוכן לומד" ל"הסוכן צובר אמונות שגויות".

הרכבההפרויקטEnd-to-End הרכבה: ה-loop השלם של ה-morning brief

עכשיו מחברים הכל לקובץ אחד שרץ מ-cron. זה השלד של morning_brief.py שמחבר את ארבעת החלקים — load → act → evaluate → reflect — עם כל ההגנות:

# morning_brief.py — ה-loop השלם, רץ מ-cron ב-06:00
import time, os
from anthropic import Anthropic
from eval_gate import score_output
from reflexion import reflect, save_lesson

client = Anthropic()
SOP_TEXT = open(".context/sops/morning_brief.md", encoding="utf-8").read()

def load_lessons(path=".context/lessons.md") -> str:
    try: lines = open(path, encoding="utf-8").read().splitlines()
    except FileNotFoundError: return ""
    ok = [l for l in lines if l.strip() and "**לבדיקה**" not in l]
    return ("לקחים מאושרים:\n" + "\n".join(ok)) if ok else ""

def generate_brief(data: dict) -> str:
    prompt = (f"{SOP_TEXT}\n\n{load_lessons()}\n\n"
              f"נתוני היום (₪):\n{data}\n\nכתוב brief בעברית, עד 180 מילים.")
    msg = client.messages.create(model="claude-sonnet-4-5",
        max_tokens=600, messages=[{"role":"user","content":prompt}])
    return msg.content[0].text

def run():
    data = collect_metrics()                 # הכנסות/תמיכה/מתחרים/inbox
    output = generate_brief(data)            # 1. Actor
    golden_case = {"must_contain": [str(data["revenue_today_ils"])],
                   "must_not_contain": ["undefined","null"], "max_words": 180}
    verdict = score_output(output, {**golden_case, "id":"live_run"})  # 2. Evaluator

    if verdict["passed"]:
        send_to_telegram(output)             # רק פלט שעבר יוצא
    else:                                    # 3. Self-Reflection
        lesson = reflect(data, output, verdict["fails"])
        save_lesson(lesson, "live_run")      # נשמר עם **לבדיקה**
        send_to_telegram(f"⚠️ ה-brief נכשל ב-eval ({verdict['fails']}). "
                         f"נכתב לקח לבדיקה. לא נשלח digest היום.")

    open(".context/last_run.txt","w").write(str(time.time()))  # heartbeat

if __name__ == "__main__":
    run()

קרא את ה-run() שורה-שורה ותראה את כל הפרק: Actor מייצר, Evaluator מנקד, ורק אם עבר — הפלט יוצא. אם נכשל — reflexion כותב לקח (עם תג לבדיקה), ואתה מקבל התרעה במקום digest שגוי. ובסוף, תמיד, חותמת ה-heartbeat. זה ה-loop. שמור הכל ב-git, ויש לך חברה שמתחילה לזכור.

תרגולפרויקט תרגילים — בנה את ה-loop שלך

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