راهنمای خواندن مستندات Agent

مرور کامل فایل‌های Markdown

این صفحه فقط فهرست فایل‌ها نیست؛ توضیح می‌دهد هر فایل چه مسئله‌ای را حل می‌کند، چرا در پروژهٔ شما قرار گرفته و نبودنش چه چیزی را کم می‌کند.

ترتیب خواندن فایل‌ها

Agent ابتدا قوانین عمومی ریشهٔ پروژه را می‌خواند. اگر کار به یک حوزهٔ تخصصی مربوط باشد، فایل مهارت مسیر را مشخص می‌کند و بعد فقط مرجع مرتبط باز می‌شود.

AGENTS.md←SKILL.md←references/*.md←اجرا و بررسی
قانون عمومی پروژه

AGENTS.md

./AGENTS.md

چه چیزی نوشته‌اید؟

قواعد سطح بالای پروژه را نوشته‌اید: هدف repository، استفاده از .NET 8، حفظ Clean Architecture و MediatR، ممنوعیت اضافه‌کردن الگوهای دیتابیس یا HTTP بدون درخواست، محدودیت پکیج‌ها و الزام build قبل از پایان کار.

چرا نوشته‌اید؟

تا هر Agent یا توسعه‌دهنده‌ای قبل از دست‌زدن به کد، مرزهای پروژه را بداند و تصمیم‌های ناسازگار مثل تغییر معماری، افزودن پکیج یا ساختن persistence را خودسرانه انجام ندهد.

اگر نباشد چه؟ قوانین عمومی منبع واحدی برای فهم محدودیت‌های کل پروژه ندارند. در این پروژه جای درست این اطلاعات همین فایل ریشه است؛ اطلاعات مربوط به یک توانایی خاص باید در SKILL.md یا references باشد.
نقطهٔ ورود توانایی تخصصی

SKILL.md

./.agents/bmsd-clean-connector/SKILL.md

چه چیزی نوشته‌اید؟

توضیح داده‌اید این skill برای ساخت یا تغییر connectorهای Clean Architecture است، چه محدوده‌ای دارد و Agent باید با چه ترتیبی کار کند: بررسی پروژه، خواندن rules و سپس انتخاب کوچک‌ترین reference لازم.

چرا نوشته‌اید؟

SKILL.md نقشهٔ راه است. به‌جای اینکه همهٔ جزئیات هر بار از ابتدا خوانده شود، مشخص می‌کند کدام دستورالعمل تخصصی برای درخواست فعلی لازم است.

اگر نباشد چه؟ پوشهٔ skill قابل کشف و استفادهٔ قابل‌اعتماد نیست. قوانین عمومی به AGENTS.md و جزئیات موضوعی به references تعلق دارند.
قواعد اجرا و کنترل کیفیت

rules.md

./.agents/bmsd-clean-connector/references/rules.md

چه چیزی نوشته‌اید؟

قواعد اجرایی connector را مشخص کرده‌اید: جهت وابستگی لایه‌ها، استفاده از MediatR، نازک‌بودن handler، قرارگیری منطق در service، ثبت dependencyها، استفاده از CancellationToken، لاگ‌نکردن اطلاعات حساس و quality gate.

چرا نوشته‌اید؟

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

اگر نباشد چه؟ جزئیات اجرای connector پراکنده یا سلیقه‌ای می‌شود. این موارد باید در همین references/rules.md بمانند؛ قوانین عمومی‌تر به AGENTS.md برمی‌گردند.
معماری و مسئولیت لایه‌ها

architecture.md

./.agents/bmsd-clean-connector/references/architecture.md

چه چیزی نوشته‌اید؟

مسئولیت Domain، Application، Infrastructure و Presentation را توضیح داده‌اید و برای MediatR، registration، handler، service، logging و exception middleware مرز مشخص کرده‌اید.

چرا نوشته‌اید؟

تا فایل‌ها و منطق در لایهٔ درست قرار بگیرند؛ مثلاً controller تصمیم کسب‌وکار نگیرد، handler orchestration-only بماند و Program.cs محل wiring ویژگی‌ها نشود.

اگر نباشد چه؟ ساختار لایه‌ها قابل تفسیرهای مختلف می‌شود. توضیح مسئولیت هر لایه باید اینجا باشد؛ نام‌گذاری و قراردادها جای convention.md هستند.
قراردادهای نام‌گذاری و شکل کد

convention.md

./.agents/bmsd-clean-connector/references/convention.md

چه چیزی نوشته‌اید؟

قواعد دقیق namespace، نام controller، command/query، request/response، route، validator، ساخت model و نحوهٔ درج مقدار در FetchXML را نوشته‌اید.

چرا نوشته‌اید؟

برای جلوگیری از نام‌های مبهم و اختلاف‌های کوچک اما اثرگذار؛ Agent باید بتواند از روی use case نام درست نوع‌ها، مسیر endpoint و شکل مدل را یکسان تولید کند.

اگر نباشد چه؟ قوانین معماری باقی می‌مانند، اما نام‌ها و قراردادها هر بار دوباره حدس زده می‌شوند. این جزئیات باید اینجا باشند، نه در rules.md.
مرجع فنی CRM و پکیج‌ها

reference.md

./.agents/bmsd-clean-connector/references/reference.md

چه چیزی نوشته‌اید؟

شکل ثابت CrmSettings، تنظیمات Dataverse، مدل‌ها و resourceها، قرارداد repository، الگوی create و update، نسخه‌های مجاز NuGet و feed خصوصی Systan را ثبت کرده‌اید.

چرا نوشته‌اید؟

این‌ها اطلاعات مرجع و سازگاری هستند؛ تغییر اشتباه در property، logical name، نسخهٔ پکیج یا feed می‌تواند connector را از نمونه‌ها و محیط واقعی جدا کند.

اگر نباشد چه؟ Agent ممکن است مقدار یا نسخه‌ای را اختراع کند. اطلاعات فنی ثابت CRM و dependencyها باید اینجا باشد؛ موضوعات رمزنگاری به security.md تعلق دارند.
امنیت و زیرساخت مشترک

security.md

./.agents/bmsd-clean-connector/references/security.md

چه چیزی نوشته‌اید؟

محل و نقش CryptographyHelper، CryptographyService و ICryptographyService، ثابت‌های رمزنگاری، سازگاری با ciphertext قبلی، نحوهٔ نگهداری credential و ممنوعیت logکردن secretها را مشخص کرده‌اید.

چرا نوشته‌اید؟

چون امنیت و compatibility جای حدس‌زدن نیست. این فایل مانع چرخش ناخواستهٔ key یا تغییر mode و padding می‌شود و جلوی افشای credential در log و response را می‌گیرد.

اگر نباشد چه؟ ممکن است رمزنگاری موجود ناسازگار شود یا اطلاعات حساس وارد log شود. invariants رمزنگاری باید همین‌جا بمانند.
راهنمای خواندن مستندات Agent

مرور سادهٔ فایل‌های Markdown

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

ترتیب خواندن فایل‌ها

اول قوانین کلی پروژه، بعد راهنمای مهارت و در پایان فقط مرجع لازم خوانده می‌شود؛ سپس تغییر build و بررسی می‌شود.

AGENTS.md→SKILL.md→references/*.md→اجرا و بررسی
قانون عمومی پروژه

AGENTS.md

./AGENTS.md

چه نوشته‌اید؟

قواعد اصلی پروژه را نوشته‌اید: .NET 8، Clean Architecture، MediatR، نساختن چیزهای خارج از درخواست و build قبل از پایان کار.

چرا نوشته‌اید؟

تا همه قبل از تغییر کد، مرزهای پروژه را بدانند؛ مثل تابلوی قوانین ورودی است.

نمونه از محتوا

- Target .NET 8 only | - Preserve Clean Architecture | - Build the affected project
اگر نباشد چه؟ قوانین پراکنده می‌شوند و تصمیم‌ها یکسان نخواهند بود.
راهنمای توانایی تخصصی

SKILL.md

./.agents/bmsd-clean-connector/SKILL.md

چه نوشته‌اید؟

مسیر کار connectorهای .NET را نوشته‌اید: پروژه را بررسی کن، rules را بخوان و کوچک‌ترین reference لازم را انتخاب کن.

چرا نوشته‌اید؟

تا Agent بداند از کجا شروع کند و همهٔ جزئیات را بی‌دلیل نخواند.

نمونه از محتوا

1. Inspect project | 2. Read rules.md | 3. Select relevant reference | 4. Build and verify
قواعد اجرا و کیفیت

rules.md

./.agents/bmsd-clean-connector/references/rules.md

چه نوشته‌اید و چرا؟

گفته‌اید handler باریک باشد، منطق در service بماند، CancellationToken استفاده شود و اطلاعات حساس log نشود؛ تا کد فقط compile نشود و کیفیت و امنیت هم رعایت شوند.

نمونه از محتوا

- Put business logic in an Application service | - Do not log passwords or tokens
معماری لایه‌ها

architecture.md

./.agents/bmsd-clean-connector/references/architecture.md

چه نوشته‌اید و چرا؟

مسئولیت Domain، Application، Infrastructure و Presentation را جدا کرده‌اید تا هر بخش در جای درست بماند؛ مثل نقشهٔ یک ساختمان.

نمونه از ساختار

Domain ← models | Application ← use cases | Infrastructure ← implementations | Presentation ← API
نام‌گذاری و مرجع فنی

convention.md + reference.md

./.agents/bmsd-clean-connector/references/

چه نوشته‌اید و چرا؟

convention نام controller و command را یکدست می‌کند؛ reference تنظیمات CRM و نسخهٔ پکیج‌ها را ثابت نگه می‌دارد تا Agent چیزی را حدس نزند.

نمونه

ContactController | UpdateContactStatusReasonByMobilePhoneCommand | Version: 9.1 | Authentication: Windows
امنیت و رمزنگاری

security.md

./.agents/bmsd-clean-connector/references/security.md

چه نوشته‌اید و چرا؟

قواعد رمزنگاری، سازگاری با داده‌های قدیمی و ممنوعیت log کردن secretها را نوشته‌اید؛ چون امنیت جای حدس‌زدن نیست.

نمونه از محتوا

- Do not change existing encryption without a plan | - Do not log passwords, tokens, or keys
اگر نباشد چه؟ داده‌های قدیمی ممکن است خوانده نشوند یا اطلاعات محرمانه افشا شود.