النافذة المنزلقة (Sliding Window) والموجة الباردة: عندما يتضخم سياق العميل (Agent Context) وتصبح الأرشفة ضرورية دون فقدان البيانات

wc -l .agents/INDEX.adoc .agents/SESSIONS_HISTORY.adoc \
  .agents/archives/COMPLETED_TASKS_ARCHIVE_2026-04.adoc

@startuml
skinparam backgroundColor #FEFEFE
skinparam handwritten false

title نمو سياق الوكيل — الجلسات من 1 إلى 48
rectangle "الجلسة 1-10" as S10 #E8F5E9
rectangle "الجلسة 11-20" as S20 #C8E6C9
rectangle "الجلسة 21-30" as S30 #A5D6A7
rectangle "الجلسة 31-40" as S40 #81C784
rectangle "الجلسة 41-48" as S48 #66BB6A

note right of S10
الفهرس : ~50 سطرًا
الجلسات : ~10 أسطر
الأرشيف : ~100 سطر
**الإجمالي : ~300 سطر**
end note

note right of S20
الفهرس : ~100 سطر
الجلسات : ~20 سطر
الأرشيف : ~400 سطر
**الإجمالي : ~800 سطر**
end note

note right of S30
الفهرس : ~160 سطرًا
الجلسات : ~30 سطرًا
الأرشيف : ~900 سطرًا
**المجموع : ~1800 سطرًا**
end note

note right of S40
الفهرس : ~220 سطرًا
الجلسات : ~45 سطرًا
الأرشيف : ~1400 سطرًا
**الإجمالي : ~3200 سطرًا**
end note

note right of S48
الفهرس : **260 سطرًا**
الجلسات : **55 سطرًا**
الأرشيف : **1756 سطرًا**
**المجموع : 5200 سطرًا** ⚠️
end note

S10 -[#green]-> S20
S20 -[#green]-> S30
S30 -[#FF9800]-> S40
S40 -[#red]-> S48

@enduml

----
----
----
----
----
.agents/
├── INDEX.adoc                         → Sessions N-9 à N (10 dernières)
├── SESSIONS_HISTORY.adoc              → Sessions N-9 à N
├── SCRIPT_VERIFICATION.adoc           → Dernière vérif (pas d'historique)
├── PROMPT_REPRISE.adoc                → Session N+1 uniquement
├── sessions/                          → Sessions N-1 à N uniquement
└── backup/
    └── Y2026-sessions-001-039/          ← Vague froide, COPIE INTÉGRALE
        ├── INDEX.adoc                  → Sessions 001 à 039 (complet)
        ├── SESSIONS_HISTORY.adoc       → Sessions 001 à 039 (complet)
        ├── COMPLETED_TASKS_ARCHIVE.adoc → Sessions 001 à 039 (complet)
        └── sessions/                   → 001.adoc, 002.adoc...
----

مفتاح الآلية :**النسخ الاحتياطي ليس فهرسًا مركزيًا، هو نسخة متطابقة من الموجة الماضية**. عندما يتجاوزنا الأفق لـ 10 جلسات نشطة، لا نحذف شيئًا. لا نقوم بإعادة فهرسة أي شيء. لا ندمج شيئًا. نأخذ حزمة ملفات الوكلاء كما كانت في الجلسة N-10، وننقلها إلى`backup/`.

الملفات النشطة، من ناحيتها، مقطوعة :

* المؤشر: فقط آخر 10 أسطر (نافذة منزلقة)
* SESSIONS_HISTORY : نفسه
* COMPLETED_TASKS_ARCHIVE : ملف جديد للفترة الحالية
* الجلسات/ : فقط آخر جلستين

[plantuml, format=svg, id=diag-hot-warm-cold, alt="Architecture Hot/Warm/Cold du contexte agent — EAGER/LAZY/backup"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 200

title هندسة ساخن / دافئ / بارد وكيل السياق
package "HOT (EAGER)\nتم الشحن تلقائيًا\n~300 سطر" as HOT #FFCDD2 {
  file "INDEX.adoc\n(10 جلسات)" as IDX_HOT
  file "PROMPT_REPRISE\n(جلسة N+1)" as PRO_HOT
  file "AGENT.adoc\n(قواعد مطلقة)" as AG_HOT
}

package "WARM (LAZY)\nتم التحميل عند الطلب\n~500 سطر" as WARM #FFF9C4 {
  file "SESSIONS_HISTORY\n(الأخيرة 10)" as HIS_WARM
  file "SCRIPT_VERIFICATION\n(الأخيرة)" as VER_WARM
  file "PROCEDURES.adoc\n(قوالب)" as PRO_WARM
  file "*_مرجع.adoc\n(وثيقة فنية)" as REF_WARM
}

package "COLD (backup/)\nلم يُشحّن أبدًا\nالقراءة البشرية فقط" as COLD #BBDEFB {
  folder "Y2026-001-039/" as WAVE {
    file "الفهرس (مكتمل)" as IDX_COLD
    file "SESSIONS_HISTORY\n(مكتمل)" as HIS_COLD
    file "COMPLETED_TASKS\n(مكتمل)" as ARCH_COLD
    folder "جلسات/ (001-039)" as SESS_COLD
  }
  folder "Y2026-040-???\n(المستقبل)" as FUTURE
}

HOT --> WARM : "الوكيل يرتفع\nإذا لزم الأمر"
WARM --> COLD : "أبدًا تلقائيًا\nالإنسان يذهب هناك بمفرده"

note bottom of COLD
  Règle : COPIE INTÉGRALE
  Pas de transformation
  Pas de réindexation
  Read-only après archivage
end note

@enduml
----

المكسب الفوري هائل: سياق EAGER يمر من**~5200 سطر إلى ~300 سطر**. قسمة على 17. دون فقدان أي سطر من البيانات التاريخية.

== لماذا هذا ليس حاوية شاملة

الوكيل، في تكراره الأول، كان يخشى أن`backup/`مجلد يُلقى فيه ملفات لن تُعاد قراءتها أبدًا. هذا خوفٌ مشروع. لكنها تقوم على لبس.

المجموعة المتنوعة هي عندما نرمي الملفات**بدون بنية، بدون اتفاقية، بدون منطق للتجميع**. هنا، يتم تنظيم النسخ الاحتياطي حسب الفترة (Y2026-001-039)، وكل مجلد نسخ احتياطي يحتوي**نفس الهيكل**أن الملف`.agents/`نشط : INDEX, SESSIONS_HISTORY, COMPLETED_TASKS_ARCHIVE, sessions/.

ليس حاوية شاملة. إنه**لقطة ذات طابع زمني**.يمكن حتى القول إن هذا آلية إصدار مبسطة — باستثناء أنه لا يُصدر الملفات بشكل فردي، بل الحزمة الكاملة للحكم في لحظة T.

عندما تريد استرداد معلومات قديمة، لا تحتاج إلى فهرس مركزي. لديك خياران :

1. **grep` المستهدف** : `grep -r "zsh" backup/Y2026-001-039/`— وأنت تجد كل ما يذكر zsh خلال الفترة، بغض النظر عن الزاوية (INDEX, SESSIONS_HISTORY, أرشيف الجلسة).
2. **إعادة دمج يدويّة**تقوم بنسخ مجلد الاحتياطي مؤقتًا إلى السياق النشط، ثم تطلب من الوكيل تحليل هذه الفترة المحددة.

المؤشر مفهوماً ضمنيًا. إنه موجود في بنية الملفات نفسها — كل ملف هو بالفعل فهرس من زاويته الخاصة.

== ميتافور الأرفف

لجعل الآلية بديهية، تصوّرتها على أنها ثلاث طبقات :

* **رف 1 (EAGER)**— خطة العمل. ما أحتاجه *الآن*. الفهرس الحديث، PROMPT_REPRISE، القواعد المطلقة. خفيف، فوري، حاسم.
* **رف 2 (LAZY)**— مكتبة الاستشارة. ما يمكنني استرجاعه عند الطلب. مراجع تقنية، تاريخ حديث، إجراءات. أضخم، لكنه غير محمل في الذاكرة.
* **القبو (backup/)**— الأرشيفات الباردة. كل ما هو ماضٍ لكنني لا أريد التخلص منه. الوكيل لا يدخلها أبدًا. الإنسان ينزل إليه عندما يرغب في التقطير.

الوكيل اقترح في البداية الرف الرابع — واحد`index-backup.adoc`الذي سيكون LAZY ويتضمن جدول محتويات للنسخة الاحتياطية بأكملها. رفضت. سيكون ذلك تكرارًا إضافيًا في نظام يعاني بالفعل من نمو خطي. بنية الملفات المؤرشفة هي بالفعل فهرس.

== المستشعر ذو الزنادين

كان المفهوم صلبًا، لكن بقيت نقطة عمياء :**متى بالضبط يجب تشغيل الدوران؟**المقالة الأولية حددته كسؤال مفتوح. بعد يومين، تم ترميز الإجابة في ملفات حوكمة ستة مشاريع: مستشعر ذو محفّزين.

=== المُشغل التلقائي — `N % 10 == 0

المُحفّز الأول رياضي. عندما يكون رقم الجلسة مضاعفًا لـ 10 — الجلسة 10، 20، 30، 40 — يتم تنفيذ تدوير النسخ الاحتياطي تلقائيًا داخل إجراء انتهاء الجلسة، مباشرةً بعد الخطوة 6.

لماذا 10؟ إنه توازن بين قوتين متعارضتين: نافذة قصيرة جدًا (5 جلسات) تفقد السياق الضروري للاستمرارية؛ نافذة طويلة جدًا (20 جلسة) لا تحل مشكلة تضخم السياق. عشر جلسات، بوتيرة جلسة إلى جلستين يوميًا، تغطي تقريبًا أسبوع عمل — كافٍ لكي يتذكر الوكيل القرارات الأخيرة، وغير كافٍ ليؤدي إلى انفجار السياق.

=== المُحفّز بالحد — 500 سطرًا EAGER

المشغل الثاني ديناميكي. بغض النظر عن رقم الجلسة، إذا تجاوزت الملفات EAGER المتراكمة**500 سطر**, يبدأ الدوران.

هذا الحد يقي من السيناريو حيث تكون الجلسات استثنائية الإنتاجية — يتم كتابة الكثير من المحتوى في عدد قليل من الجلسات. جلسة تنتج 120 سطرًا من المحتوى التحريري تجعل COMPLETED_TASKS_ARCHIVE يزداد أسرع بكثير من جلسة تصحيح تصلح سطرين. حدّ 500 سطرًا، المقاس عبر`wc -l .agents/INDEX.adoc .agents/archives/COMPLETED_TASKS_ARCHIVE_*.adoc PROMPT_REPRISE.adoc`, يلتقط هذا الاختلال

=== المنبه اليدوي — "rotation backup

أخيرًا، يبقى الإنسان هو المتحكم. الكلمات المفتاحية`rotation backup`, `backup rotation` ou `lance la rotation backup`يطلِقون الإجراء عند الطلب، بشكل مستقل عن انتهاء الجلسة. مفيد عندما تشعر أن السياق يصبح ثقيلًا ولكنك لم تصل بعد إلى مضاعف 10، أو عندما تريد أرشفة مرحلة عمل قبل بدء مرحلة جديدة.

[plantuml, format=svg, id=diag-capteur-trigger, alt="Les trois déclencheurs du capteur de rotation backup — automatique, seuil, manuel"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 200

title مستشعر دوران احتياطي — المحفزات الثلاثة
start

:Procédure de fin de session;
note right: Mots-clés "نهاية الجلسة"\nou "نتوقف هنا"

:Étapes 1 à 6\n(archivage standard);
note right
  1. Archive sessions/N.adoc
  2. MAJ PROMPT_REPRISE
  3. MAJ SESSIONS_HISTORY
  4. MAJ INDEX.adoc
  5. MAJ TEST_COVERAGE
  6. MAJ COMPLETED_TASKS
end note

if (N % 10 == 0\nOU\nEAGER cumulé > 500 lignes ?) then (oui)
  :⚙️ Rotation Backup\n(étape 7);
  note right
    1. Créer backup/Y20XX-sessions-X-Y/
    2. Copier intégrale INDEX + HISTORY
       + COMPLETED_TASKS + sessions/
    3. Tronquer actifs à 10 sessions
    4. Ajouter _Localisation active_
  end note
else (non)
  :Pas de rotation;
endif

:Checklist [✅] x 7\n(si applicable);

stop

@enduml
----

يوضح هذا الرسم البياني الإدخال الدقيق للمستشعر في إجراء نهاية الجلسة. الخطوة 7 اختيارية — يتم تنفيذها فقط إذا كانت إحدى الحالتين صحيحتين — لكنها تتم بشكل منهجي *مُتحقَّق*. قائمة التحقق النهائية تشمل`[✅] 7. Backup roté (si applicable)`.

=== الحلقة المغلقة

هذا المستشعر يغلق الحلقة التي فتحها المقال السابق. الإدارة Eager/Lazy قد حلت مشكلة ذاكرة الوكيل بين جلستين. الآلية Hot/Warm/Cold حلت مشكلة الذاكرة التي تزداد. المستشعر ذو المحرّكين يحل مشكلة *الوقت* — يزيح عن الإنسان العبء الذهني لمراقبة حجم السياق.

[plantuml, format=svg, id=diag-boucle-fermee, alt="Les trois couches de la gouvernance agent — Eager/Lazy, Hot/Warm/Cold, Capteur"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center

title الطبقات الثلاث لحوكمة الوكيل
left to right direction

package "الطبقة 1 — ذاكرة\n(المادة 0108)" as C1 #E8F5E9 {
  rectangle "**مستعد**\nلوحة التحكم\nمحمل تلقائيًا" as EAG
  rectangle "**LAZY**\nدليل المالك\nيتم الشحن عند الطلب" as LAZ
  EAG -[hidden]right-> LAZ
}

package "طبقة 2 — الشيخوخة\n(المادة 0110)" as C2 #FFF9C4 {
  rectangle "**HOT**\n10 جلسات نشطة\nحوالي 300 سطر" as HOT
  rectangle "**WARM**\nالمراجع\nالإجراءات" as WRM
  rectangle "**COLD**\nbackup/\nموجة باردة" as CLD
  HOT -[hidden]right-> WRM
  WRM -[hidden]right-> CLD
}

package "الطبقة 3 — المشغّل\n(اليوم)" as C3 #BBDEFB {
  rectangle "**تلقائي**\nN % 10 == 0" as AUTO
  rectangle "حد\n> 500 أسطر" as SEUIL
  rectangle "**Manuel**\nالنسخ الاحتياطي بالدوران" as MAN
  AUTO -[hidden]right-> SEUIL
  SEUIL -[hidden]right-> MAN
}

C1 --> C2 : "الذاكرة تنمو\n→ يلزم وجود آلية للشيخوخة"
C2 --> C3 : "الشيخوخة\n→ يجب أن يكون هناك مشغل\nلتنفيذه"

note bottom of C3
  ✅ Déployé sur 6 projets
  magic-stick · bakery-gradle
  plantuml-gradle · cheroliv.com
  jhipster-gradle-plugins
  quizz-benchmark-gradle
end note

@enduml
----

الطبقات الثلاث تُرتبّ منطقيًا. الطبقة الأولى تمنح الذاكرة للوكيل. الطبقة الثانية تمنع هذه الذاكرة من إخنق الوكيل. الطبقة الثالثة تقوم بأتمتة صيانة هذه الذاكرة بحيث لا يحتاج الإنسان إلى التفكير فيها.

=== الهجرة الفعالة على cheroliv.com

لم يظل الميكانيزم نظريًا. على`cheroliv.com`, تم تنفيذ أول دوران للنسخ الاحتياطي في 29 أبريل 2026 — تم نقل الجلسات من -6 إلى 2 إلى`.agents/backup/Y2026-sessions-neg6-a-002/`:

|===
|ملف |قبل الدوران |بعد الدوران |كسب |`.agents/INDEX.adoc` |19 جلسة مدرجة |10 جلسات (3-12) |-9 مدخلات |`.agents/SESSIONS_HISTORY.adoc` |18 جلسة |10 جلسات |-8 مدخلات |`COMPLETED_TASKS_ARCHIVE` |161 سطرًا (الجلسات 1-12) |135 أسطر (الجلسات 3-12) |-26 أسطر |`sessions/` |20 ملفات |10 ملفات |-10 ملفات |**نسخة احتياطية/** |غير موجود |موجة باردة (10 جلسات أرشيفية) |+1 حزمة باردة
|===

الزيادة في عدد الأسطر كانت متواضعة — المشروع شاب، 12 جلسات — لكن المهم هو أن الـ**الالية موجودة**. سيتم تشغيل الدوران التلقائي التالي في الجلسة 20، أو في وقت سابق إذا تم الوصول إلى 500 سطر EAGER.

== الدرس الوكيل البشري

هذه الجلسة 048 علمتني شيئًا جوهريًا حول التعاون مع وكيل ذكاء اصطناعي.

الوكيل لديه تحيز طبيعي: يسعى إلى**تحسين**, à **تبسيط**, à **إزالة التكرارات**. هذا هو التحيز لنظام تم تدريبه لإنتاج إجابات نظيفة وموجزة. عند مواجهة مجموعة بيانات غنية ومتعددة الأبعاد، يكون أول رد فعل له هو تقليلها إلى أبسط تعبير.

الإنسان، من جهته، لديه حدس مختلف: إنه يشعر أن التكرار المنظم هو**ميزة**، ليس عيبًا. إن تنوع الزوايا حول نفس الواقع هو بالضبط ما سيسمح لاحقًا بتقطير عالي الجودة.

ليس الأمر أن الوكيل مخطئ. بل إن "الأمثل" الخاص به ليس هو "الأمثل" الخاص بي. الوكيل يحسّن لـ**الحاضر**— السياق الفوري، الجواب السريع على السؤال المطروح. الإنسان يحسّن لل**المستقبل**— القدرة على البحث، والتمازج، والتقطير خلال ثلاثة أشهر أو ثلاث سنوات.

____ ما أريده هو المواد الخام. أفكارك، ترددك، إجاباتك على أسئلتي. ليس تركيبك. التركيب، أنا أعرف كيف أقوم به أفضل منك. أريد المادة الخام. ____

هذه الجملة التي قلتها له في نهاية الجلسة تلخص كل شيء. الوكيل هو أداة الإنتاج. الإنسان هو أداة التقطير. الحوكمة ليست مُصمَّـة بحيث يفهم الوكيل كل شيء بمفرده — بل هي مُصمَّـة ليتمكّن الإنسان لاحقًا من العمل على المادة المنتجة.

الموجة الباردة المتطابقة هي الترجمة المعمارية لهذه الفلسفة: لا نلقي بشيء، لا ندمج شيئًا، لا نعيد فهرسة أي شيء. نحن ننقل الحزمة سليمة. سيأتي التقطير لاحقًا، يدويًا، بواسطة الإنسان.

== التتابع المنطقي للمقالة السابقة

إذا قرأتlink:/blog/2026/0108_gouvernance_agent_opencode_eager_lazy_post.html[المقالة حول استراتيجية Eager/Lazy], ستدرك التقدم الطبيعي :

1. **المادة 0108**حوكمة Eager/Lazy : *comment* تنظيم سياق الوكيل على مستويين من التوفر
2. **هذا المقال 0110**— آلية النسخ الاحتياطي : *comment* جعل هذا السياق يشيخ دون فقده عندما يصبح كبيرًا جدًا

أجاب المقال الأول على السؤال: « لا يتذكر الوكيل شيئًا بين جلستين، كيف نعطيه ذاكرة؟

هذا يجيب عن السؤال الذي ينشأ حتمًا من الأول : «الذاكرة تزداد في كل جلسة، كيف نمنعها من اختناق الوكيل دون مسحها؟

الجواب يقتصر على نمط:**حار/دافئ/بارد**, تم تطبيقه على ملفات الحوكمة. ومبدأ واحد :**لا تفقد شيئًا أبدًا، أعد توطين كل شيء دائمًا**.

== روابط

* المقال السابق :link:/blog/2026/0108_gouvernance_agent_opencode_eager_lazy_post.html[حكم وكيل ذكاء اصطناعي باستخدام AsciiDoc]
* موقعي : https://cheroliv.com
* المشروع`magic-stick`: https://github.com/cheroliv/magic-stick

---

نظام حوكمة جيد لا يحذف البيانات أبداً. إنه يخزنها.
----
----

مفتاح الآلية :**النسخ الاحتياطي ليس فهرسًا مركزيًا، بل هو نسخة طبق الأصل من الموجة الماضية**. عندما يتجاوز المرء الأفق الخاص بـ 10 جلسات نشطة، لا نحذف شيئًا. لا نعيد فهرسة شيئًا. لا ندمج شيئًا. نأخذ حزمة ملفات الوكلاء كما كانت في الجلسة N-10، ثم ننقلها إلى`backup/`.

الملفات النشطة، هي، مقتطعة :

* INDEX : فقط آخر 10 أسطر (نافذة منزلقة)
* SESSIONS_HISTORY : نفس
* COMPLETED_TASKS_ARCHIVE : nouveau fichier pour la période en cours
* الجلسات/: فقط الجلستين الأخيرتين

[plantuml, format=svg, id=diag-hot-warm-cold, alt="Architecture Hot/Warm/Cold du contexte agent — EAGER/LAZY/backup"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 200

title المعمارية الساخنة / الدافئة / الباردة لسياق الوكيل
package "HOT (EAGER)\nمحمّل تلقائيًا\n~300 سطر" as HOT #FFCDD2 {
  file "INDEX.adoc\n(10 جلسات)" as IDX_HOT
  file "موجّه الاستئناف\n(الجلسة N+1)" as PRO_HOT
  file "AGENT.adoc\n(قواعد مطلقة)" as AG_HOT
}

package "WARM (LAZY)\nمحمّل عند الطلب\n~500 سطر" as WARM #FFF9C4 {
  file "سجل الجلسات\n(آخر 10)" as HIS_WARM
  file "SCRIPT_VERIFICATION\n(الأخيرة)" as VER_WARM
  file "PROCEDURES.adoc\n(قوالب)" as PRO_WARM
  file "*_REFERENCE.adoc\n(مستند تقني)" as REF_WARM
}

package "COLD (backup/)\nلم يتم تحميله قط\nقراءة بشرية فقط" as COLD #BBDEFB {
  folder "Y2026-001-039/" as WAVE {
    file "الفهرس (كامل)" as IDX_COLD
    file "SESSIONS_HISTORY\n(كامل)" as HIS_COLD
    file "المهام المكتملة\n(مكتمل)" as ARCH_COLD
    folder "الجلسات/ (001-039)" as SESS_COLD
  }
  folder "Y2026-040-???\n(المستقبل)" as FUTURE
}

HOT --> WARM : "يعود الوكيل إلى الأعلى\nعند الحاجة"
WARM --> COLD : "ليس تلقائيًا أبدًا\nالإنسان يذهب إلى هناك وحده"

note bottom of COLD
  Règle : COPIE INTÉGRALE
  Pas de transformation
  Pas de réindexation
  Read-only après archivage
end note

@enduml
----

المكسب الفوري هائل: سياق EAGER ينتقل من**~5200 أسطر إلى ~300 أسطر**. قسم على 17. بدون فقدان أي سطر واحد من البيانات التاريخية.

== لماذا هذا ليس حاوية شاملة

الوكيل، في أول تكرار له، كان يخشى أن`backup/`تصبح صندوقًا أسود — مجلدًا يلقى فيه ملفات لن يُعاد قراءتها أبدًا. هذا خوفٌ مشروع. لكنه مبني على لبس.

المُجمّع هو عندما نرمي الملفات**بدون هيكل، بدون اتفاقية، بدون منطق تجميع**. هنا، يتم تنظيم النسخ الاحتياطي حسب الفترة (Y2026-001-039)، وكل مجلد نسخ احتياطي يحتوي**نفس الهيكل**الملف`.agents/`نشط : INDEX, SESSIONS_HISTORY, COMPLETED_TASKS_ARCHIVE, sessions/.

ليس هذا مكانًا لتجميعEverything. إنه**لقطة ذات طابع زمني**. يمكن حتى القول إنه آلية تبسيط للإصدار — مع استثناء أنه لا يصدر إصدارات للملفات بشكل فردي، بل للحزمة الكاملة للإدارة في لحظة زمنية معينة.

عندما تريد استرجاع معلومات قديمة، لا تحتاج إلى فهرس مركزي. لديك خياران:

1. **grep` مستهدف**:`grep -r "zsh" backup/Y2026-001-039/`— وتجد كل ما يذكر zsh خلال الفترة، مهما كان الزاوية (INDEX, SESSIONS_HISTORY, أرشيف الجلسة).
2. **إعادة الدمج اليدوي**: بعد ذلك، تقوم بنسخ مجلد النسخ الاحتياطي مؤقتًا إلى السياق النشط، وتطلب من الوكيل تحليل هذه الفترة المحددة.

الفهارس ضمنية. إنها موجودة في بنية الملفات نفسها — كل ملف هو بالفعل فهرس من زاوية خاصة به.

== استعارة الرفوف

لجعل الآلية بديهية، قمت بتصورها على ثلاث رفوف :

* **الرف 1 (EAGER)**— خطة العمل. ما أحتاجه *الآن*. INDEX حديث, PROMPT_REPRISE, قواعد مطلقة. خفيف, فوري, حاسم.
* **رف 2 (LAZY)**— مكتبة الاستشارة. ما يمكنني استرجاعه عند الطلب. المراجع التقنية، التاريخ الحديث، الإجراءات. أكبر حجماً، لكنه غير محمل في الذاكرة.
* **قبو (backup/)**— الأرشيفات الباردة. كل ما مرّ لكنني لا أريد أن ألقى به. الوكيل لا يدخله أبداً. الإنسان ينزل إليه عندما يريد التقطير.

اقترح الوكيل في البداية رفًا رابعًا — واحد`index-backup.adoc`سيكون LAZY ويحتوي على جدول محتويات لكل النسخة الاحتياطية. رفضت ذلك. سيكون ذلك تكرارًا إضافيًا في نظام يعاني بالفعل من نمو خطي. هيكل الملفات المؤرشفة هو بالفعل فهرس.

== المستشعر ذو المحفزين

كان المفهوم صلبًا، لكنه كان لا يزال هناك نقطة عمياء :**متى بالضبط تشغيل الدوران؟**المقال الأول حددها كسؤال مفتوح. بعد يومين، تم ترميز الإجابة في ملفات الحوكمة لستة مشاريع: مستشعر باثنين من المشغلات.

=== المُشغِّل التلقائي — `N % 10 == 0

المُشغِّل الأول هو رياضي. عندما يكون رقم الجلسة مضاعفًا لـ 10 — الجلسة 10، 20، 30، 40 — فإن عملية rotation backup تُنفَّذ تلقائيًا داخل إجراء انتهاء الجلسة، مباشرةً بعد الخطوة 6.

لماذا 10؟ إنها تسوية بين قوتين متضادتين: نافذة قصيرة جدًا (5 جلسات) تفقد السياق الضروري للاستمرارية؛ ونافذة طويلة جدًا (20 جلسة) لا تحل مشكلة تراكم السياق. عشر جلسات، بمعدل جلسة إلى جلستين يوميًا، تغطي تقريبًا أسبوعًا من العمل — كافية لتذكر الوكيل للقرارات الحديثة، غير كافية لتسبب انفجار السياق.

=== المُحفّز بالحدّ — 500 أسطر EAGER

المُحفّز الثاني ديناميكي. بغض النظر عن رقم الجلسة، إذا تجاوزت ملفات EAGER المتراكمة**500 سطر**, تبدأ الدوران

هذا العتبة تحمي من السيناريو حيث تكون الجلسات استثنائيًا منتجة — الكثير من المحتوى مكتوب في عدد قليل من الجلسات. جلسة تنتج 120 سطرًا من المحتوى التحريري تجعل COMPLETED_TASKS_ARCHIVE يزداد بشكل أسرع بكثير من جلسة تصحيح أخطاء تصحّح سطرين. العتبة التي تبلغ 500 سطرًا، التي تُقاس عبر`wc -l .agents/INDEX.adoc .agents/archives/COMPLETED_TASKS_ARCHIVE_*.adoc PROMPT_REPRISE.adoc`, يلتقط هذا عدم التماثل.

=== المُشغّل اليدوي — "نسخة احتياطية دورية

أخيرًا، الإنسان هو من يسيطر. الكلمات المفتاحية`rotation backup`, `backup rotation` ou `lance la rotation backup`يطلُقون الإجراء عند الطلب، بغضّ النظر عن انتهاء الجلسة. يكون ذلك مفيدًا عندما يشعر المرء بأن السياق يصبح ثقيلًا لكنه لم يصل بعد إلى مضاعف 10، أو عندما يرغب في أرشفة مرحلة عمل قبل بدء مرحلة جديدة.

[plantuml, format=svg, id=diag-capteur-trigger, alt="Les trois déclencheurs du capteur de rotation backup — automatique, seuil, manuel"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 200

title مستشعر الدوران الاحتياطي — المحفزات الثلاثة
start

:Procédure de fin de session;
note right: Mots-clés "نهاية الجلسة"\nou "نتوقف هنا"

:Étapes 1 à 6\n(archivage standard);
note right
  1. Archive sessions/N.adoc
  2. MAJ PROMPT_REPRISE
  3. MAJ SESSIONS_HISTORY
  4. MAJ INDEX.adoc
  5. MAJ TEST_COVERAGE
  6. MAJ COMPLETED_TASKS
end note

if (N % 10 == 0\nOU\nEAGER cumulé > 500 lignes ?) then (oui)
  :⚙️ Rotation Backup\n(étape 7);
  note right
    1. Créer backup/Y20XX-sessions-X-Y/
    2. Copier intégrale INDEX + HISTORY
       + COMPLETED_TASKS + sessions/
    3. Tronquer actifs à 10 sessions
    4. Ajouter _Localisation active_
  end note
else (non)
  :Pas de rotation;
endif

:Checklist [✅] x 7\n(si applicable);

stop

@enduml
----

يوضح هذا الرسم البياني الإدراج الدقيق للمستشعر في إجراء نهاية الجلسة. الخطوة 7 اختيارية — لا تُنفذ إلا إذا كان أحد الشرطين صحيحًا — لكنها تتحقق *بشكل منهجي*. قائمة المراجعة النهائية تشمل`[✅] 7. Backup roté (si applicable)`.

=== الحلقة المغلقة

هذا المستشعر يغلق الحلقة التي فتحتها المقالة السابقة. كانت إدارة Eager/Lazy قد حلّت مشكلة الذاكرة الوكيلة بين الجلستين. آلية Hot/Warm/Cold حلّت مشكلة الذاكرة التي تزداد. المستشعر ذو مفعّلين يحلّ مشكلة الـ `*quand*` — مُزيلًا عن الإنسان العبء العقلي لمراقبة حجم السياق.

[plantuml, format=svg, id=diag-boucle-fermee, alt="Les trois couches de la gouvernance agent — Eager/Lazy, Hot/Warm/Cold, Capteur"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center

title الطبقات الثلاث لحوكمة الوكيل
left to right direction

package "الطبقة 1 — الذاكرة\n(المادة 0108)" as C1 #E8F5E9 {
  rectangle "**EAGER**\nلوحة المعلومات\nتحميل تلقائي" as EAG
  rectangle "**LAZY**\nدليل المالك\nمحمّل عند الطلب" as LAZ
  EAG -[hidden]right-> LAZ
}

package "الطبقة 2 — التقادم\n(المادة 0110)" as C2 #FFF9C4 {
  rectangle "**رائج**\n10 جلسات نشطة\n~300 سطر" as HOT
  rectangle "**WARM**\nالمراجع\nالإجراءات" as WRM
  rectangle "**COLD**\nbackup/\nموجة باردة" as CLD
  HOT -[hidden]right-> WRM
  WRM -[hidden]right-> CLD
}

package "الطبقة 3 — مُشغِّل\n(اليوم)" as C3 #BBDEFB {
  rectangle "**تلقائي**\nN % 10 == 0" as AUTO
  rectangle "**العتبة**\n> 500 سطر" as SEUIL
  rectangle "**دليل**\nتدوير النسخ الاحتياطي" as MAN
  AUTO -[hidden]right-> SEUIL
  SEUIL -[hidden]right-> MAN
}

C1 --> C2 : "الذاكرة تنمو\n→ يلزم وجود آلية\nللشيخوخة"
C2 --> C3 : "التقادم\n→ يلزم مُشغِّل\nلتنفيذه"

note bottom of C3
  ✅ Déployé sur 6 projets
  magic-stick · bakery-gradle
  plantuml-gradle · cheroliv.com
  jhipster-gradle-plugins
  quizz-benchmark-gradle
end note

@enduml
----

الطبقات الثلاث تتكدس منطقيًا. الطبقة الأولى تمنح الوكيل ذاكرة. الطبقة الثانية تمنع هذه الذاكرة من إرهاق الوكيل. الطبقة الثالثة تقوم بأتمتة صيانة هذه الذاكرة حتى لا يضطر الإنسان إلى التفكير فيها.

=== الهجرة الفعالة على cheroliv.com

لم يظل الآلية نظرية. على`cheroliv.com`, تم تنفيذ أول دوران للنسخ الاحتياطي في 29 أبريل 2026 — تم نقل الجلسات من -6 إلى 2 إلى`.agents/backup/Y2026-sessions-neg6-a-002/`:

|===
|ملف |قبل الدوران |بعد الدوران |ربح |`.agents/INDEX.adoc` |19 جلسات مدرجة |10 جلسات (3-12) |-9 المدخلات |`.agents/SESSIONS_HISTORY.adoc` |18 جلسات |10 جلسات |-8 مداخلات |`COMPLETED_TASKS_ARCHIVE` |161 خطوط (جلسات 1-12) |135 أسطر (الجلسات 3-12) |-26 سطر |`sessions/` |20 ملفًا |10 ملفات |-10 ملفات |**نسخة احتياطية/** |غير موجود |موجة باردة (10 جلسات مؤرشفة) |+1 حزمة باردة
|===

الزيادة في عدد الأسطر كانت متواضعة — المشروع صغير، 12 جلسة — لكن الأهم هو أن**الآلية موجودة**. الدوران التالي التلقائي سيُفعَّل في الجلسة 20، أو قبل ذلك إذا تم الوصول إلى 500 سطر EAGER.

== الدرس الوكيل-البشري

هذه الجلسة 048 علمتني شيئًا أساسيًا حول التعاون مع وكيل ذكاء اصطناعي.

الوكيل لديه انحياز طبيعي: هو يسعى إلى**يُحسّن**, à **تبسيط**, à **إزالة التكرارات**. هذا هو تحيّز نظام تم تدريبه لإنتاج إجابات نظيفة ومختصرة. عندما يواجه مجموعة بيانات غنية ومتعددة الأبعاد، فإن أول انعكاس له هو تقليلها إلى أبسط تعبير.

الإنسان، من جهته، لديه بديهية مختلفة: إنه يشعر أن التكرار المنظم هو واحد**ميزة**, ليس عيبًا. إن تعدد الزوايا على نفس الواقع هو بالضبط ما سيسمح لاحقًا بعملية تقطير ذات جودة.

ليس أن الوكيل مخطئ؛ بل إن `optimum` الخاص به ليس لي. الوكل يحسّن لـ**حاضر**— السياق الفوري، الرد السريع على السؤال المطروح. الإنسان يحسّن من أجل**المستقبل**— القدرة على استرجاع، تقاطع، تقطير خلال ثلاثة أشهر أو ثلاث سنوات.

(Empty) ما أريده هو المادة الخام. تفكيرك، ترددك، إجاباتك على أسئلتي. ليس تجميعك. التجميع، أعرف أنني أستطيع أن أفعله أفضل منك. أريد المادة الأولية. ____

هذه الجملة التي قلتها له في نهاية الجلسة تلخص كل شيء. الوكيل هو أداة إنتاج. الإنسان هو أداة تقطير. الحوكمة ليست مصمّمة لكي يفهم الوكيل كل شيء بمفرده — إنها مصمّمة لتمكين الإنسان من العمل لاحقًا على المادة المنتجة.

الموجة الباردة المتطابقة هي الترجمة المعمارية لهذه الفلسفة: لا نرمي شيئًا، ولا ندمج شيئًا، ولا نعيد فهرسة شيئًا. نحن ننقل الحزمة سليمة. سيأتي التقطير لاحقًا، يدويًا، بواسطة الإنسان.

== التتابُع المنطقي للمقال السابق

إذا قرأتَlink:/blog/2026/0108_gouvernance_agent_opencode_eager_lazy_post.html[المقالة حول الاستراتيجية الجشعة/الكسل]، ستعرفون التقدم الطبيعي:

1. **المادة 0108**— حوكمة Eager/Lazy : *كيف* تنظيم سياق الوكيل في مستويين من التوفر
2. **هذه المقالة 0110**— آلية النسخ الاحتياطي: *comment* جعل هذا السياق يشيخ دون فقده عندما يصبح كبيرًا جدًا

المقالة الأولى أجابت على السؤال: « لا يتذكر الوكيل أي شيء بين جلستين، كيف نعطيه ذاكرة؟

هذا يجيب على السؤال الذي ينشأ حتمًا من الأول: «الذاكرة تتضخم في كل جلسة، كيف نمنعها من اختناق الوكيل دون مسحه؟

الإجابة تكمن في نمط :**ساخن/دافئ/بارد**, مطبق على ملفات الحوكمة. ومبدأ واحد :**لا تفقد شيئًا أبدًا، دائمًا أعد توطين كل شيء**.

== روابط

* المقال السابق :link:/blog/2026/0108_gouvernance_agent_opencode_eager_lazy_post.html[إدارة وكيل ذكاء اصطناعي باستخدام AsciiDoc]
* موقعي: https://cheroliv.com
* المشروع`magic-stick`: https://github.com/cheroliv/magic-stick

---

*نظام الحوكمة الجيد لا يحذف البيانات أبدًا. إنه يخزنها.*
----

مفتاح الآلية:**النسخة الاحتياطية ليست فهرساً مركزياً، بل هي نسخة مطابقة للموجة الماضية**عندما نتجاوز أفق الـ 10 جلسات النشطة، لا نقوم بحذف أي شيء. ولا نعيد فهرسة أي شيء. ولا ندمج أي شيء. نأخذ حزمة ملفات الوكلاء كما كانت في الجلسة N-10، وننقلها إلى`backup/`يرجى تقديم النص الذي ترغب في ترجمته.

أما الملفات النشطة، فهي مقتطعة:

* الفهرس: فقط الـ 10 أسطر الأخيرة (sliding window)
* SESSIONS_HISTORY : نفس الشيء
* COMPLETED_TASKS_ARCHIVE : ملف جديد للفترة الحالية
* sessions/ : آخر جلستين فقط

[plantuml, format=svg, id=diag-hot-warm-cold, alt="Architecture Hot/Warm/Cold du contexte agent — EAGER/LAZY/backup"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 200

title بنية Hot / Warm / Cold لسياق العميل
package "HOT (EAGER)\nيتم تحميله تلقائياً\n~300 سطر" as HOT #FFCDD2 {
  file "INDEX.adoc\n(10 جلسات)" as IDX_HOT
  file "PROMPT_REPRISE\n(الجلسة N+1)" as PRO_HOT
  file "AGENT.adoc\n(قواعد مطلقة)" as AG_HOT
}

package "WARM (LAZY)\nيتم تحميله عند الطلب\n~500 سطر" as WARM #FFF9C4 {
  file "SESSIONS_HISTORY\n(آخر 10)" as HIS_WARM
  file "SCRIPT_VERIFICATION\n(الأخير)" as VER_WARM
  file "PROCEDURES.adoc\n(نماذج)" as PRO_WARM
  file "*_REFERENCE.adoc\n(وثيقة تقنية)" as REF_WARM
}

package "COLD (backup/)\nلا يتم تحميله أبداً\nللقراءة البشرية فقط" as COLD #BBDEFB {
  folder "Y2026-001-039/" as WAVE {
    file "INDEX (كامل)" as IDX_COLD
    file "SESSIONS_HISTORY\n(كامل)" as HIS_COLD
    file "COMPLETED_TASKS\n(كامل)" as ARCH_COLD
    folder "sessions/ (001-039)" as SESS_COLD
  }
  folder "Y2026-040-???\n(مستقبلي)" as FUTURE
}

HOT --> WARM : "يقوم العميل بالرجوع إليها\nعند الحاجة"
WARM --> COLD : "ليس تلقائياً أبداً\nالبشر يدخلون إليها بأنفسهم"

note bottom of COLD
القاعدة: نسخة مطابقة
لا تحويل
لا إعادة فهرسة
للقراءة فقط بعد الأرشفة
end note

@enduml
----

المكسب الفوري هائل: يتغير السياق `EAGER` من**حوالي 5200 سطر إلى حوالي 300 سطر**قسمة على 17. دون فقدان سطر واحد من البيانات التاريخية.

== لماذا لا يُعد هذا مجرد وعاء لكل شيء

كان العميل، في تكراره الأول، يخشى أن`backup/`تتحول إلى صندوق أسود — مجلد نلقي فيه ملفات لن نعيد قراءتها أبداً. إنه خوف مشروع، لكنه يقوم على خلط في المفاهيم.

الحقيبة الشاملة (fourre-tout) هي عندما نقوم برمي ملفات**بدون بنية، بدون اتفاقية، بدون منطق تجميع**. هنا، يتم تنظيم النسخة الاحتياطية حسب الفترة (`Y2026-001-039`)، ويحتوي كل مجلد نسخ احتياطي على**نفس البنية**أن الملف`.agents/`نشط: `INDEX` و `SESSIONS_HISTORY` و `COMPLETED_TASKS_ARCHIVE` و `sessions/`.

هذا ليس وعاءً لكل شيء. إنه**لقطة فورية مختومة زمنياً**يمكننا القول حتى أنها آلية إصدارات (versioning) مبسطة — مع فارق أنها لا تقوم بإصدار الملفات بشكل فردي، بل حزمة الحوكمة الكاملة في لحظة زمنية معينة.

عندما تريد استعادة معلومة قديمة، لست بحاجة إلى فهرس مركزي. لديك خياران:

1. **grep` مستهدف**يرجى إدخال `apiKey` الخاص بك.`grep -r "zsh" backup/Y2026-001-039/`— وستجد كل ما يشير إلى `zsh` في تلك الفترة، بغض النظر عن الزاوية (`INDEX` أو `SESSIONS_HISTORY` أو أرشيف الجلسة).
2. **إعادة دمج يدوية**: تقوم بنسخ مجلد النسخ الاحتياطي مؤقتاً إلى السياق النشط، وتطلب من الوكيل تحليل هذه الفترة المحددة.

الفهرس ضمني. إنه موجود في بنية الملفات ذاتها — حيث يمثل كل منها فهرساً من منظوره الخاص.

== استعارة الرفوف

لجعل الآلية بديهية، قمت بتصورها على شكل ثلاثة رفوف:

* **الرف 1 (EAGER)**— خطة العمل. ما أحتاجه *الآن*. `INDEX` حديث، `PROMPT_REPRISE`، قواعد مطلقة. خفيف، فوري، حاسم.
* **الرف 2 (LAZY)**— مكتبة المراجعة. ما يمكنني البحث عنه عند الطلب. مراجع تقنية، تاريخ حديث، إجراءات. أكبر حجماً، ولكنها غير محملة في الذاكرة.
* **Cave (backup/)**— الأرشيفات الباردة. كل ما مضى ولكنني لا أريد التخلص منه. العميل لا يدخل إلى هناك أبداً. أما الإنسان فينزل إليها عندما يريد التقطير.

اقترح الوكيل في البداية رفاً رابعاً — وهو`index-backup.adoc`الذي سيكون `LAZY` ويحتوي على جدول محتويات لكل النسخة الاحتياطية. لقد رفضت ذلك. سيكون هذا تكراراً إضافياً في نظام يعاني بالفعل من نمو خطي. فبنية الملفات المؤرشفة هي بالفعل بمثابة فهرس.

== المستشعر ذو المشغلين

كان التصور متيناً، ولكن ظلت هناك نقطة عمياء:**متى يجب تفعيل التدوير بالضبط؟**حدد المقال الأصلي ذلك على أنه سؤال مفتوح. بعد يومين، تم تدوين الإجابة في ملفات الحوكمة لستة مشاريع: مستشعر بمشغّلين.

=== المُشغِّل التلقائي — `N % 10 == 0

المحفز الأول رياضي. عندما يكون رقم الجلسة مضاعفاً للعدد 10 — الجلسة 10، 20، 30، 40 — يتم تنفيذ تدوير النسخ الاحتياطي (rotation backup) تلقائياً ضمن إجراء نهاية الجلسة، مباشرة بعد الخطوة 6.

لماذا 10؟ إنه الحل الوسط بين قوتين متضادتين: نافذة قصيرة جداً (5 جلسات) تفقد السياق اللازم للاستمرارية؛ ونافذة طويلة جداً (20 جلسة) لا تحل مشكلة تضخم السياق. عشر جلسات، بمعدل جلسة إلى جلستين يومياً، تغطي حوالي أسبوع من العمل — وهو ما يكفي ليتذكر العميل القرارات الأخيرة، وليس كافياً ليتسبب في انفجار السياق.

=== المُشغل حسب العتبة — 500 سطر `EAGER

المشغل الثاني ديناميكي. وبغض النظر عن رقم الجلسة، إذا تجاوزت ملفات `EAGER` المتراكمة**500 سطر**، يبدأ الدوران.

تحمي هذه العتبة من السيناريو الذي تكون فيه الجلسات منتجة بشكل استثنائي — أي كتابة الكثير من المحتوى في جلسات قليلة. فالجلسة التي تنتج 120 سطراً من المحتوى التحريري تؤدي إلى تضخم `COMPLETED_TASKS_ARCHIVE` بشكل أسرع بكثير من جلسة تصحيح أخطاء (debug) تقوم بتصحيح سطرين. يتم قياس عتبة الـ 500 سطر عبر`wc -l .agents/INDEX.adoc .agents/archives/COMPLETED_TASKS_ARCHIVE_*.adoc PROMPT_REPRISE.adoc`، يلتقط هذا التباين.

=== المشغل اليدوي — "rotation backup

أخيراً، يبقى التحكم بيد الإنسان. الكلمات المفتاحية`rotation backup`, `backup rotation` ou `lance la rotation backup`تُطلق الإجراء عند الطلب، وبغض النظر عن نهاية الجلسة. مفيد عندما يشعر المرء أن السياق أصبح ثقيلاً ولكننا لم نصل بعد إلى مضاعفات الرقم 10، أو عندما نريد أرشفة مرحلة عمل قبل البدء في مرحلة جديدة.

[plantuml, format=svg, id=diag-capteur-trigger, alt="Les trois déclencheurs du capteur de rotation backup — automatique, seuil, manuel"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 200

title مستشعر الدوران الاحتياطي — المشغلات الثلاثة
start

:Procédure de fin de session;
note right: Mots-clés "نهاية الجلسة"\nou "سنتوقف هنا"

:Étapes 1 à 6\n(archivage standard);
note right
1. أرشيف الجلسات/N.adoc
2. تحديث `PROMPT_REPRISE`
3. تحديث `SESSIONS_HISTORY`
4. تحديث `INDEX.adoc`
5. تحديث `TEST_COVERAGE`
6. تحديث `COMPLETED_TASKS
end note

if (N % 10 == 0\nOU\nEAGER cumulé > 500 lignes ?) then (oui)
  :⚙️ Rotation Backup\n(étape 7);
  note right
1. إنشاء `backup/Y20XX-sessions-X-Y/`
2. نسخ كامل `INDEX` + `HISTORY`
+ `COMPLETED_TASKS` + `sessions/`
3. اقتطاع النشطين إلى 10 جلسات
4. إضافة _الموقع النشط_
  end note
else (non)
  :Pas de rotation;
endif

:Checklist [✅] x 7\n(si applicable);

stop

@enduml
----

يوضح هذا المخطط الإدراج الدقيق للمستشعر في إجراء نهاية الجلسة. الخطوة 7 اختيارية — حيث لا يتم تنفيذها إلا إذا كان أحد الشرطين صحيحاً — ولكن يتم *التحقق* منها بشكل منهجي. تتضمن القائمة النهائية لتدقيق المراجعة`[✅] 7. Backup roté (si applicable)`يرجى تقديم النص المراد ترجمته.

=== الحلقة المغلقة

يغلق هذا المستشعر الحلقة المفتوحة التي تركها المقال السابق. لقد حلت حوكمة Eager/Lazy مشكلة ذاكرة الوكيل بين جلستين، بينما حلت آلية Hot/Warm/Cold مشكلة تضخم الذاكرة. أما المستشعر ذو المشغلين فيحل مشكلة "متى" — مما يرفع عن كاهل الإنسان العبء الذهني المتمثل في مراقبة حجم السياق.

[plantuml, format=svg, id=diag-boucle-fermee, alt="Les trois couches de la gouvernance agent — Eager/Lazy, Hot/Warm/Cold, Capteur"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center

title الطبقات الثلاث لحوكمة الوكيل
left to right direction

package "الطبقة 1 — الذاكرة\n(المادة 0108)" as C1 #E8F5E9 {
  rectangle "**EAGER**\nلوحة القيادة\nتحميل تلقائي" as EAG
  rectangle "**LAZY**\nدليل المالك\nتحميل عند الطلب" as LAZ
  EAG -[hidden]right-> LAZ
}

package "الطبقة 2 — التقادم\n(المادة 0110)" as C2 #FFF9C4 {
  rectangle "**HOT**\n10 جلسات نشطة\n~300 سطر" as HOT
  rectangle "**WARM**\nالمراجع\nالإجراءات" as WRM
  rectangle "**COLD**\nbackup/\nموجة باردة" as CLD
  HOT -[hidden]right-> WRM
  WRM -[hidden]right-> CLD
}

package "الطبقة 3 — المُشغل\n(اليوم)" as C3 #BBDEFB {
  rectangle "**Auto**\nN % 10 == 0" as AUTO
  rectangle "**Seuil**\n> 500 سطر" as SEUIL
  rectangle "**Manuel**\nتدوير النسخ الاحتياطي" as MAN
  AUTO -[hidden]right-> SEUIL
  SEUIL -[hidden]right-> MAN
}

C1 --> C2 : "الذاكرة تتوسع\n→ هناك حاجة لآلية\nتقادم"
C2 --> C3 : "التقادم\n→ هناك حاجة لمُشغل\nلتنفيذه"

note bottom of C3
✅ تم نشره في 6 مشاريع
`magic-stick` · `bakery-gradle`
`plantuml-gradle` · `cheroliv.com`
`jhipster-gradle-plugins`
`quizz-benchmark-gradle
end note

@enduml
----

تتراكم الطبقات الثلاث بشكل منطقي. تمنح الطبقة الأولى ذاكرة للوكيل. وتمنع الطبقة الثانية هذه الذاكرة من إغراق الوكيل. أما الطبقة الثالثة فتقوم بأتمتة صيانة هذه الذاكرة حتى لا يضطر الإنسان للتفكير فيها.

=== الهجرة الفعلية على cheroliv.com

لم يظل هذا الميكانيزم نظرياً. على`cheroliv.com`، تم تنفيذ أول تدوير للنسخ الاحتياطي في 29 أبريل 2026 — وقد انتقلت الجلسات من -6 إلى 2 نحو`.agents/backup/Y2026-sessions-neg6-a-002/`يرجى تقديم النص الذي ترغب في ترجمته.

|===
|ملف |قبل التدوير |بعد التدوير |كسب |`.agents/INDEX.adoc` |19 جلسات مدرجة |١٠ جلسات (٣-١٢) |-9 مدخلات |`.agents/SESSIONS_HISTORY.adoc` |١٨ جلسة |10 جلسات |-8 مداخل |`COMPLETED_TASKS_ARCHIVE` |161 سطراً (الجلسات 1-12) |135 سطرًا (الجلسات 3-12) |-26 أسطر |`sessions/` |20 ملفاً |١٠ ملفات |-10 ملفات |**نسخة احتياطية/** |غير موجود |موجة باردة واحدة (10 جلسات مؤرشفة) |+1 عبوة تبريد
|===

كانت الزيادة في عدد الأسطر متواضعة — فالمشروع لا يزال في بدايته، 12 جلسة — ولكن المهم هو أن الـ**الآلية مفعلة**ستبدأ عملية التدوير التلقائي التالية عند الجلسة 20، أو في وقت أقرب إذا تم الوصول إلى 500 سطر `EAGER`.

== درس الإنسان-الوكيل

لقد علمتني هذه الجلسة `048` شيئاً أساسياً حول التعاون مع وكيل ذكاء اصطناعي.

لدى الوكيل انحياز طبيعي: فهو يسعى إلى**تحسين**, à **تبسيط**, à **إزالة التكرارات**. هذا هو انحياز نظام تم تدريبه على تقديم إجابات نظيفة وموجزة. فبمجرد مواجهته لمجموعة بيانات غنية ومتعددة الأبعاد، يكون رد فعله الأول هو اختزالها إلى أبسط تعبير ممكن.

أما الإنسان، فلديه حدس مختلف: فهو يشعر بأن التكرار المهيكل هو**ميزة**، وليس عيباً. بل إن تنوع الزوايا حول الواقع نفسه هو بالضبط ما سيسمح، لاحقاً، بعملية تقطير نوعية.

ليس الأمر أن الوكيل على خطأ، بل أن "optimum" الخاص به ليس هو الخاص بي. الوكيل يقوم بالتحسين من أجل الـ**حاضر**— السياق المباشر، والرد السريع على السؤال المطروح. الإنسان يحسّن من أجل الـ**مستقبل**— القدرة على الاسترجاع، والمقارنة، والتلخيص بعد ثلاثة أشهر أو ثلاث سنوات.

يرجى تزويدي بالنص الذي ترغب في ترجمته. ما أريده هو المادة الخام. تأملاتك، تردداتك، وإجاباتك على أسئلتي. لا أريد ملخصك. فالتلخيص أجيده أكثر منك. أريد المادة الأولية. يرجى تزويدي بالنص المراد ترجمته.

هذه الجملة التي قلتها له في نهاية الجلسة تلخص كل شيء. العميل هو أداة إنتاج. والإنسان هو أداة التقطير. الحوكمة ليست مصممة لكي يفهم العميل كل شيء بمفرده — بل هي مصممة لكي يتمكن الإنسان، لاحقاً، من صقل المادة المنتجة.

الموجة الباردة المتطابقة هي الترجمة المعمارية لهذه الفلسفة: لا يتم رمي أي شيء، ولا دمج أي شيء، ولا إعادة فهرسة أي شيء. يتم نقل الحزمة كما هي دون مساس. أما التقطير فسيأتي لاحقاً، يدوياً، بواسطة الإنسان.

== التتمة المنطقية للمقال السابق

إذا كنت قد قرأتlink:/blog/2026/0108_gouvernance_agent_opencode_eager_lazy_post.html[المقال حول استراتيجية `Eager/Lazy]، ستلاحظ التطور الطبيعي:

1. **المادة 0108**— حوكمة Eager/Lazy: *كيفية* هيكلة سياق العميل في مستويين من التوفر
2. **هذا المقال 0110**— آلية النسخ الاحتياطي (backup): *كيفية* جعل هذا السياق يتقادم دون فقدانه عندما يصبح حجمه كبيراً جداً

أجاب المقال الأول على السؤال: «الوكيل لا يتذكر شيئاً بين جلستين، كيف يمكن منحه ذاكرة؟

يجيب هذا على السؤال الذي ينجم حتماً عن السؤال الأول: «الذاكرة تتضخم في كل جلسة، كيف نمنعها من خنق العميل دون مسحها؟

تكمن الإجابة في نمط:**ساخن/دافئ/بارد**، المطبق على ملفات الحوكمة. وبمبدأ:**عدم فقدان أي شيء أبدًا، وإعادة تحديد موقع كل شيء دائمًا**يرجى تقديم النص الذي ترغب في ترجمته.

== روابط

* المقال السابق:link:/blog/2026/0108_gouvernance_agent_opencode_eager_lazy_post.html[إدارة وكيل ذكاء اصطناعي باستخدام `AsciiDoc]
* موقعي: https://cheroliv.com
* المشروع`magic-stick`: https://github.com/cheroliv/magic-stick

---

إن نظام الحوكمة الجيد لا يقوم أبداً بحذف البيانات، بل يقوم بأرشفتها.
----