MD به‌عنوان حافظه و رابط

در فصل ۱.۴.۱ گفتیم پیش‌فرض این است که هیچ حافظه‌ای وجود ندارد — هر session از صفر شروع می‌شود. فایل حافظه جوابِ همان مسئله است، و حالا می‌خواهیم درست بنویسیمش.

سؤال درست این نیست «چه چیزی را نگه دارم؟» — که جوابش «همه‌چیز» می‌شود و به فایلی می‌رسی که کسی نمی‌خواندش. سؤال درست این است:

به‌خاطر بسپار «چه چیزی را اگر ننویسم، دفعه‌ی بعد باید دوباره توضیح بدهم؟» هر چیزی که جوابش بله است، حافظه است. بقیه‌اش یادداشت است و جای دیگری دارد.

پس چه چیزهایی می‌مانند:

• تصمیم‌ها و دلیلشان. مهم‌ترین بخش. «چرا این‌طور» ارزشش از «این‌طور است» بیشتر است، چون بدون دلیل، شش ماه بعد تصمیم را عوض می‌کنی و همان اشتباه قبلی را دوباره می‌کنی.
• چیزهایی که امتحان شدند و جواب ندادند. این را تقریباً همه فراموش می‌کنند، و بی‌ارزش‌ترین وقتِ ازدست‌رفته همان دوباره‌آزمودنِ راهِ بسته است.
• ترجیح‌های ثابت. «خروجی همیشه فارسی»، «تاریخ‌ها شمسی».
• و آدرس‌ها. فایل‌ها کجا هستند، منبع اصلی داده کدام است.

و چه چیزی نباید داخلش باشد: هر چیزی که از خودِ سیستم قابل دیدن است. فهرست فایل‌ها، محتوای پوشه‌ها، چیزهایی که با یک نگاه معلوم‌اند — نوشتنشان یعنی دو نسخه‌ی حقیقت داری که از هم جدا می‌افتند. و البته هیچ رمز و کلیدی (فصل ۵.۳.۵).

یک فایل حافظه‌ی بزرگ، خیلی زود به فایلی تبدیل می‌شود که خودت هم نمی‌خوانی‌اش. راه‌حل، شکستن است — ولی شکستنی که تکه‌ها را گم نکند. یعنی لینک.

در Markdown دو شکل رایج دارد:

• [نامِ نمایشی](مسیر/فایل.md) — شکل استاندارد که همه‌جا کار می‌کند.
• [[نام-فایل]] — شکل کوتاه‌تر که در برنامه‌های یادداشت‌برداری رایج است.

ولی نکته‌ی مهم‌تر از شکلِ لینک این است: لینک، ساختار را از پوشه‌ها مستقل می‌کند. پوشه فقط یک سلسله‌مراتب می‌دهد — هر فایل یک‌جا. لینک اجازه می‌دهد یک چیز از چند جا قابل رسیدن باشد، بدون کپی‌کردنش.

و یک قاعده که فایل حافظه را زنده نگه می‌دارد: یک فایل فهرست داشته باش که به بقیه لینک می‌دهد. آن یکی را همیشه می‌خوانی؛ بقیه را وقتی لازم شد. این همان کاری است که context engineering توصیه می‌کند — کوچک‌ترین مجموعه‌ی پرسیگنال، نه همه‌چیز یک‌جا (فصل ۲.۷.۲).

حالا مهم‌ترین تفکیک این فصل. حافظه و وضعیت دو چیز جدا هستند، و اگر یکی‌شان کنی، هر دو را از دست می‌دهی:

• حافظه پایدار است. «این سیستم چطور کار می‌کند»، «چرا این‌طور تصمیم گرفتیم». ماه‌ها معتبر می‌ماند.
• وضعیت فرّار است. «الان کجای کار هستیم»، «قدم بعدی چیست»، «چه چیزی نیمه‌کاره ماند». فردا عوض می‌شود.

چرا جداکردنشان مهم است؟ چون عمرشان فرق دارد. اگر وضعیتِ امروز را وسط حافظه‌ی پایدار بنویسی، دو هفته بعد فایل حافظه‌ات پر از جمله‌های منقضی است — و آن‌وقت به هیچ‌کدامش اعتماد نمی‌کنی. یک فایل حافظه‌ای که به آن اعتماد نداری، بدتر از نداشتنش است، چون هم وقت می‌گیرد و هم گمراه می‌کند.

یک فایل وضعیت خوب چهار چیز دارد و کوتاه است:

1. کجا هستیم — یک جمله.
2. چه چیزی تمام شد — از آخرین دفعه.
3. قدم بعدی چیست — مشخص و قابل‌شروع، نه «ادامه‌ی کار».
4. چه چیزی گیر است — و منتظر چه کسی.

و در نقطه‌های میانی به‌روزش کن، نه فقط آخر کار. دلیلش ساده است: کاری که نصفه رها می‌شود، معمولاً ناگهانی رها می‌شود — و آن‌وقت فایل وضعیتی که فقط قرار بود آخرِ کار نوشته شود، هیچ‌وقت نوشته نمی‌شود.

این قاعده‌ی جمع‌بندیِ فصل است، و آزمونش یک سؤال است: «این فایل کِی عوض می‌شود؟» اگر دو جواب داشت، باید دو فایل باشد.

مثال روشن:

• _قانون.md — وقتی قاعده‌ای عوض شود. شاید ماهی یک بار.
• _حافظه.md — وقتی تصمیمی گرفته شود. هفته‌ای یک بار.
• _وضعیت.md — هر بار که کار می‌کنی.

سه ریتم متفاوت، سه فایل. اگر این سه در یک فایل بودند، هر بار که وضعیت را به‌روز می‌کردی، کلِ قوانین را هم دست می‌زدی — و احتمال خرابکاری در چیزی که نباید عوض شود بالا می‌رفت.

یک فایده‌ی جانبی هم دارد که به M1 برمی‌گردد: می‌توانی فقط همان فایلی را به ایجنت بدهی که به کار این کار می‌آید. سه فایل کوچک، سه انتخاب؛ یک فایل بزرگ، فقط یک انتخابِ گران (فصل ۱.۳.۴).