Ai/API_RELIABILITY_AUDIT_FA.md

ممیزی ضعف‌ها و میزان اعتماد APIها

این سند بر اساس بررسی کد فعلی پروژه نوشته شده است و هدفش این است که برای هر API مشخص کند:

• خروجی روی چه داده یا فرمولی تکیه دارد
• کجاها خروجی صرفا تقریبی، heuristic، mock یا وابسته به LLM است
• برای چه نوع استفاده‌ای قابل اتکا هست و برای چه نوع تصمیمی نیست
• سطح اعتماد عملی به پاسخ خروجی چقدر است

توجه:

• این سند درباره قابلیت اتکای عملیاتی است، نه فقط درست بودن ساختار JSON.
• ممکن است یک API از نظر فنی همیشه JSON درست برگرداند، اما از نظر agronomy یا تصمیم‌سازی هنوز کم‌اعتماد باشد.
• سطح اعتماد به معنی اعتماد به محتوای پاسخ است، نه availability سرویس.

معیار سطح اعتماد

• زیاد: عمدتا داده واقعی یا ذخیره شده برمی‌گرداند؛ فرمول یا منطق ساده ولی قابل توضیح است؛ برای نمایش و گزارش مناسب است.
• متوسط: داده واقعی دارد اما بخش مهمی از نتیجه وابسته به تقریب، پیش‌فرض، شبیه‌سازی، یا LLM است.
• کم: نتیجه بیشتر heuristic، fallback، برآورد تقریبی، یا تلفیق داده ناقص است.
• خیلی کم: داده mock، stub، یا خروجی عمدتا غیرقابل اتکا برای تصمیم واقعی.

خلاصه سریع APIهای پرریسک

• POST /api/economy/overview/: داده کاملا mock است؛ برای تصمیم واقعی نباید استفاده شود.
• POST /api/plants/fetch-info/: عملا پیاده‌سازی نشده و 503 برمی‌گرداند.
• POST /api/irrigation/water-stress/: اگر engine شبیه‌سازی خطا بدهد هنوز به فرمول ساده سنسور fallback می‌کند.
• POST /api/pest-disease/detect/ و POST /api/pest-disease/risk/: وابستگی مستقیم به RAG/LLM دارند؛ برای KPI قطعی یا تصمیم سم‌پاشی خودکار مناسب نیستند.
• POST /api/farm-alerts/tracker/ و POST /api/farm-alerts/timeline/: ترکیب rule-based + LLM هستند؛ برای آگاهی خوب‌اند ولی برای اتوماسیون بحرانی نه.
• POST /api/soile/moisture-heatmap/: visualization خوبی می‌دهد اما هنوز geostatistics دقیق یا history واقعی سنسورها را مدل نمی‌کند.

---

1) Soil Data API

GET|POST /api/soil-data/

• منبع داده:
  • اگر رکورد کامل موجود باشد از DB برمی‌گردد.
  • اگر موجود نباشد فقط task صف می‌شود و 202 می‌دهد.
• ضعف‌ها:
  • در حالت 202 هنوز خود داده خاک برنگشته، فقط شروع فرآیند واکشی اعلام می‌شود.
  • تطابق location بر اساس lat/lon گرد شده تا 6 رقم است؛ برای نقاط خیلی نزدیک ممکن است حساسیت مکانی محدود شود.
  • کیفیت نهایی کاملا وابسته به سرویس بیرونی خاک و کامل شدن depthهاست.
• اگر فرمول/اطلاعات قابل اتکا نباشد:
  • این API خودش مدل پیش‌بینی ندارد؛ ریسک اصلی از ناقص بودن داده منبع یا incomplete بودن رکورد است.
• مناسب برای:
  • واکشی داده خام خاک و persistence.
• نامناسب برای:
  • استنتاج agronomy بدون بررسی منبع و completeness.
• سطح اعتماد:
  • زیاد وقتی source=database و location کامل است.
  • کم وقتی فقط task_id گرفته‌اید و هنوز داده واقعی ندارید.

GET /api/soil-data/tasks/{task_id}/status/

• منبع داده: وضعیت Celery + نتیجه ذخیره شده در DB.
• ضعف‌ها:
  • ممکن است task موفق شده باشد ولی رکورد location هنوز کامل نباشد.
  • خروجی SUCCESS لزوما به معنی کیفیت agronomic داده نیست؛ فقط completion فنی را نشان می‌دهد.
• سطح اعتماد:
  • متوسط برای وضعیت فنی task.
  • کم تا متوسط برای اعتماد به خود محتوای خاک، بسته به کامل بودن رکورد.

POST /api/soil-data/ndvi-health/

• منبع داده: observation ماهواره‌ای NDVI در location_data.ndvi.
• ضعف‌ها:
  • اگر observation موجود نباشد، کارت عملا به وضعیت Unavailable می‌رسد.
  • تفسیر NDVI ساده است و به تنهایی برای تشخیص علت تنش کافی نیست.
  • NDVI میانگین مزرعه است؛ heterogeneity داخل مزرعه را کامل نشان نمی‌دهد.
• اگر فرمول/اطلاعات قابل اتکا نباشد:
  • NDVI فقط شاخص پوشش گیاهی است، نه تشخیص علت؛ کمبود آب، بیماری، تغذیه یا خطای سنجش ممکن است با هم اشتباه شوند.
• سطح اعتماد:
  • متوسط برای پایش کلی وضعیت پوشش گیاهی.
  • کم برای تصمیم‌گیری علّی یا درمانی.

---

2) Soile API

POST /api/soile/moisture-heatmap/

• منبع داده:
  • latest measurement هر سنسور
  • وزن‌دهی تازگی داده
  • جریمه outlier
  • interpolation از نوع weighted IDW
  • mask مرز مزرعه
• ضعف‌ها:
  • history واقعی سنسورها هنوز مدل نمی‌شود.
  • drift سنسور، calibration uncertainty و quality assurance واقعی لحاظ نشده‌اند.
  • depth-specific map به صورت measured واقعی نیست و بخشی از لایه‌ها از soil profile مشتق می‌شوند.
  • uncertainty به صورت heuristic برآورد می‌شود.
  • با تراکم سنسور پایین یا farm نامتقارن، heatmap بیشتر visualization است تا اندازه‌گیری دقیق.
• اگر فرمول/اطلاعات قابل اتکا نباشد:
  • مدل interpolation علمی پیشرفته مثل kriging یا مدل uncertainty مکانی ندارد.
  • خروجی برای zoning دقیق agronomy کافی نیست.
• سطح اعتماد:
  • متوسط برای visualization و درک trend کلی.
  • کم برای تصمیم آبیاری دقیق نقطه‌ای یا نسخه agronomy.

POST /api/soile/health-summary/

• منبع داده: داده سنسور + خلاصه‌ساز سلامت خاک.
• ضعف‌ها:
  • خلاصه سلامت ذاتا compression از چند متریک است و همه context مزرعه را در بر نمی‌گیرد.
  • اگر سنسورهای مزرعه کم‌تعداد یا داده‌هایشان قدیمی باشد، summary گمراه‌کننده می‌شود.
• سطح اعتماد:
  • متوسط برای dashboard summary.
  • کم تا متوسط برای تصمیم اصلاح خاک بدون نمونه‌برداری میدانی.

POST /api/soile/anomaly-detection/

• منبع داده: anomaly آماری + تفسیر RAG.
• ضعف‌ها:
  • anomaly detection بر اساس context موجود است و به history و baseline کامل چندفصلی متکی نیست.
  • تفسیر نهایی توسط RAG تولید می‌شود و deterministic نیست.
  • اگر anomaly آماری واقعی نباشد، LLM ممکن است فقط آن را با متن تخصصی بسط دهد.
• سطح اعتماد:
  • متوسط برای پیدا کردن موارد مشکوک.
  • کم برای diagnosis نهایی بدون تایید کارشناس.

---

3) Weather API

POST /api/weather/farm-card/

• منبع داده: forecastهای ذخیره‌شده در DB از سرویس هواشناسی خارجی.
• ضعف‌ها:
  • docstring سرویس هنوز misleading است، ولی کد واقعا requests.get می‌زند.
  • اگر forecast تازه نباشد، کارت weather کهنه می‌شود.
  • کارت فقط summary ساده از forecast است و uncertainty پیش‌بینی هوا را منتقل نمی‌کند.
  • اگر forecast موجود نباشد، خروجی عملا صفر/نامشخص می‌شود.
• اگر فرمول/اطلاعات قابل اتکا نباشد:
  • مشکل اصلی فرمول نیست؛ dependency به forecast خارجی و freshness داده است.
• سطح اعتماد:
  • متوسط تا زیاد وقتی forecast تازه و کامل موجود باشد.
  • کم وقتی داده weather ناقص یا قدیمی باشد.

POST /api/weather/water-need-prediction/

• منبع داده:
  • محاسبات ET/crop profile از irrigation.evapotranspiration
  • forecast هفت‌روزه
  • تفسیر تکمیلی از RAG
• ضعف‌ها:
  • دقت خروجی به کیفیت crop profile، growth stage و راندمان روش آبیاری وابسته است.
  • horizon فقط کوتاه‌مدت است.
  • insight متنی توسط LLM تولید می‌شود و fallback هم دارد.
  • اگر forecast ضعیف باشد، کل محاسبه نیاز آبی ضعیف می‌شود.
• اگر فرمول/اطلاعات قابل اتکا نباشد:
  • برای برنامه‌ریزی کوتاه‌مدت خوب است، اما irrigation scheduling دقیق در مزرعه واقعی هنوز به سنسور و بازخورد عملی نیاز دارد.
• سطح اعتماد:
  • متوسط برای برنامه‌ریزی 3 تا 7 روزه.
  • کم تا متوسط برای تصمیم اجرایی بدون کنترل میدانی.

---

4) Economy API

POST /api/economy/overview/

• منبع داده: mock صریح در سرویس.
• ضعف‌ها:
  • کل خروجی ساختگی است.
  • اعداد هزینه آب، صرفه‌جویی، درآمد و هزینه کود از مزرعه واقعی استخراج نمی‌شوند.
  • trend chart نیز mock است.
• اگر فرمول/اطلاعات قابل اتکا نباشد:
  • این API فعلا برای عملیات واقعی قابل اتکا نیست.
• سطح اعتماد:
  • خیلی کم

---

5) Plant API

GET|POST /api/plants/ و GET|PUT|PATCH|DELETE /api/plants/{id}/

• منبع داده: رکوردهای DB.
• ضعف‌ها:
  • اعتماد به محتوای agronomic رکوردها بستگی به کسی دارد که داده را وارد کرده است.
  • validation دامنه‌ای یا علمی عمیق روی محتوا دیده نمی‌شود.
• اگر فرمول/اطلاعات قابل اتکا نباشد:
  • مشکل اصلی از جنس data governance است، نه الگوریتم.
• سطح اعتماد:
  • زیاد برای این‌که رکوردی که ذخیره شده همان برگردد.
  • متوسط برای اعتماد علمی به محتوای متنی رکوردها.

POST /api/plants/fetch-info/

• منبع داده: قرار بوده API خارجی باشد، ولی فعلا None برمی‌گرداند.
• ضعف‌ها:
  • عملا پیاده‌سازی نشده است.
  • در حالت فعلی 503 می‌دهد.
• سطح اعتماد:
  • خیلی کم

---

6) Farm Data API

POST /api/farm-data/

• منبع داده:
  • boundary مزرعه
  • sensor payload
  • واکشی خودکار location و weather
• نقاط قوت فعلی:
  • مرکز مزرعه با centroid هندسی polygon محاسبه می‌شود، نه average ساده.
  • merge سنسورها flat و overwrite خاموش ندارد؛ payload هر sensor جدا می‌ماند.
• ضعف‌ها:
  • centroid هندسی هنوز برای همه use-caseها بهترین نقطه نمونه‌برداری نیست؛ مخصوصا در مزرعه‌های خیلی کشیده یا چندبخشی.
  • health داده به شدت به درست بودن boundary ورودی وابسته است.
  • location و weather فقط برای یک نقطه مرکزی resolve می‌شوند؛ variability در سطح مزرعه از بین می‌رود.
• اگر فرمول/اطلاعات قابل اتکا نباشد:
  • این API بیشتر data-ingestion است؛ ضعف اصلی spatial representativeness است.
• سطح اعتماد:
  • زیاد برای ذخیره‌سازی و linkage داده.
  • متوسط برای این فرض که یک center point نماینده کل مزرعه است.

GET /api/farm-data/{farm_uuid}/detail/

• منبع داده:
  • sensor payload
  • soil depth data
  • weather
  • plants و irrigation method
  • resolved_metrics با aggregation deterministic
• نقاط قوت فعلی:
  • conflict چند سنسور silent overwrite نمی‌شود.
  • source هر metric در metric_sources مشخص می‌شود.
• ضعف‌ها:
  • aggregation متریک‌های عددی در تعارض، به average ختم می‌شود؛ این روش همیشه از نظر agronomy بهترین strategy نیست.
  • sensor locality و timestamp تفکیک‌شده در resolved_metrics نهایی از بین می‌رود.
  • برای farm چندناحیه‌ای، یک resolved metric ممکن است variance مهم را پنهان کند.
• سطح اعتماد:
  • متوسط تا زیاد برای unified context.
  • متوسط برای تصمیم نقطه‌ای داخل مزرعه.

POST /api/farm-data/parameters/

• منبع داده: DB و log تغییرات.
• ضعف‌ها:
  • افزودن پارامتر جدید به معنی معتبر بودن agronomic آن نیست.
  • کیفیت metadata وابسته به داده ورودی کاربر است.
• سطح اعتماد:
  • زیاد برای ثبت و نگهداری metadata.
  • متوسط برای معنی علمی metadata.

---

7) Irrigation API

GET|POST /api/irrigation/ و GET /api/irrigation/{id}/

• منبع داده: رکوردهای روش آبیاری در DB.
• ضعف‌ها:
  • درصد راندمان و توضیحات روش آبیاری اگر دستی وارد شده باشند، لزوما calibrated برای مزرعه خاص نیستند.
• سطح اعتماد:
  • زیاد برای بازگرداندن داده ذخیره‌شده.
  • متوسط برای کاربرد agronomic عمومی.

POST /api/irrigation/recommend/

• منبع داده:
  • sensor/farm context
  • plant data
  • irrigation method
  • محاسبات FAO-56 و optimizer
  • متن نهایی از RAG
• نقاط قوت فعلی:
  • پاسخ نهایی provenance دارد و مشخص می‌کند کدام فیلد از LLM و کدام از fallback آمده است.
• ضعف‌ها:
  • merge نهایی هنوز deterministic است و برای پایداری UI fallback را نگه می‌دارد.
  • اگر crop profile، weather یا irrigation method درست نباشد، recommendation قابل اتکا نیست.
  • optimizer و LLM هر دو وابسته به کیفیت ورودی هستند.
  • خروجی ممکن است از نظر ظاهر کامل باشد، حتی وقتی بخشی از آن fallback است.
• اگر فرمول/اطلاعات قابل اتکا نباشد:
  • برای تصمیم نهایی آبیاری در مزرعه، باید provenance و fallback بودن بخش‌ها دیده شود.
• سطح اعتماد:
  • متوسط وقتی داده مزرعه کامل باشد و fallback محدود باشد.
  • کم تا متوسط وقتی بخش‌های زیادی fallback شده باشند.

POST /api/irrigation/water-stress/

• منبع داده:
  • ابتدا سرویس crop simulation
  • در صورت خطا fallback به فرمول ساده clamp(round(35 - (soil_moisture / 2)), 0, 100)
• ضعف‌ها:
  • اگر engine اصلی خطا بدهد هنوز به فرمول ساده سنسوری fallback می‌شود.
  • fallback فقط از soil_moisture استفاده می‌کند و ET0، بارش، root depth، نوع گیاه، مرحله رشد و روند زمانی را نادیده می‌گیرد.
  • بنابراین ظاهر endpoint ممکن است simulation-based باشد اما در failure عملا heuristic برگرداند.
• اگر فرمول/اطلاعات قابل اتکا نباشد:
  • هر خروجی‌ای که sourceMetric.engine = sensor_fallback داشته باشد برای KPI دقیق تنش آبی قابل اتکا نیست.
• سطح اعتماد:
  • متوسط اگر واقعا از simulation engine آمده باشد.
  • کم اگر fallback سنسوری فعال شده باشد.

---

8) Fertilization API

POST /api/fertilization/recommend/

• منبع داده:
  • sensor/farm context
  • plant data
  • optimizer
  • RAG
• نقاط قوت فعلی:
  • مانند irrigation، provenance بخش‌ها اضافه شده و تشخیص fallback بهتر شده است.
• ضعف‌ها:
  • merge نهایی هنوز deterministic است و ساختار UI را حتی در خروجی ضعیف حفظ می‌کند.
  • وضعیت واقعی عناصر غذایی مزرعه به sample quality و coverage محدود است.
  • مدل crop-specific کامل و region-specific صریح دیده نمی‌شود.
  • پاسخ متنی نهایی LLM-based است.
• اگر فرمول/اطلاعات قابل اتکا نباشد:
  • برای نسخه کود نهایی بدون آزمون خاک و تایید agronomist کافی نیست.
• سطح اعتماد:
  • متوسط برای پیشنهاد اولیه.
  • کم تا متوسط برای prescription نهایی.

---

9) Pest & Disease API

POST /api/pest-disease/detect/

• منبع داده:
  • تصویر ارسالی
  • context مزرعه
  • knowledge base
  • LLM vision / RAG
• ضعف‌ها:
  • دقت شدیدا به کیفیت، زاویه، نور و فاصله تصویر وابسته است.
  • خروجی deterministic نیست.
  • confidence هم از خود مدل می‌آید و لزوما calibrated نیست.
  • ممکن است علائم تغذیه‌ای، abiotic stress و بیماری با هم اشتباه شوند.
• سطح اعتماد:
  • کم تا متوسط برای triage اولیه.
  • کم برای تصمیم سم‌پاشی یا تشخیص قطعی.

POST /api/pest-disease/risk/

• منبع داده:
  • context مزرعه
  • weather
  • knowledge base
  • RAG
• ضعف‌ها:
  • هرچند intent آن RAG-based است، در لایه سرویس هنوز fallback heuristic نیز وجود دارد.
  • risk forecast region-specific و crop-specific calibrated model ندارد.
  • خروجی نهایی به retrieval quality و model behavior وابسته است.
• اگر فرمول/اطلاعات قابل اتکا نباشد:
  • این endpoint باید فعلا به عنوان expert-assist دیده شود، نه predictive model قطعی.
• سطح اعتماد:
  • متوسط برای آگاهی از ریسک کلی.
  • کم برای عملیات خودکار یا قطعی.

10) Crop Simulation API

POST /api/crop-simulation/growth/

• منبع داده:
  • weather
  • soil
  • crop parameters
  • agromanagement
  • PCSE engine
• ضعف‌ها:
  • اگر پارامترهای واقعی مزرعه ناقص باشند، سیستم از defaultهای زیادی استفاده می‌کند.
  • بخشی از پارامترها مثل ELEV, IRRAD, RDMSOL, WAV, NAVAILI پیش‌فرض‌محور هستند.
  • کیفیت شبیه‌سازی به کیفیت profile گیاه و agromanagement وابسته است.
• نکته مهم:
  • در failure فعلی، خطا propagate می‌شود و دیگر fallback projection در مسیر اصلی برگردانده نمی‌شود؛ این از نظر شفافیت خوب است.
• سطح اعتماد:
  • متوسط وقتی ورودی‌ها خوب باشند و PCSE درست اجرا شود.
  • کم تا متوسط وقتی بخش زیادی از ورودی‌ها default باشند.

GET /api/crop-simulation/growth/{task_id}/status/

• منبع داده: status تسک + نتیجه شبیه‌سازی.
• ضعف‌ها:
  • وضعیت SUCCESS به معنی خوب بودن ورودی‌های مدل نیست.
  • page‌بندی timeline فقط presentation است و تضمین کیفیت علمی مدل نمی‌دهد.
• سطح اعتماد:
  • زیاد برای وضعیت فنی task.
  • متوسط برای محتوای simulation output.

POST /api/crop-simulation/current-farm-chart/

• منبع داده: simulation engine + context فعلی مزرعه.
• ضعف‌ها:
  • chart از شبیه‌سازی می‌آید، نه مشاهده واقعی برگ/بیوماس/weight.
  • leaf_count_estimate و برخی شاخص‌ها derived هستند، نه measured.
  • اگر weather forecast یا plant profile ضعیف باشد، chart گمراه‌کننده می‌شود.
• سطح اعتماد:
  • متوسط برای KPI بصری و trend.
  • کم تا متوسط برای تصمیم agronomy دقیق.

POST /api/crop-simulation/harvest-prediction/

• منبع داده:
  • growth simulation
  • GDD profile
  • extrapolation تا رسیدگی
• ضعف‌ها:
  • اگر maturity داخل بازه forecast رخ ندهد، تاریخ برداشت با extrapolation از میانگین رشد برآورد می‌شود.
  • بنابراین بخش‌هایی از تاریخ برداشت پیش‌بینی‌شده ممکن است فراتر از خروجی واقعی engine باشند.
  • وابستگی زیاد به required_gdd_for_maturity و current profile گیاه دارد.
• اگر فرمول/اطلاعات قابل اتکا نباشد:
  • برای برنامه‌ریزی برداشت به عنوان estimate مناسب است، نه تعهد تقویمی قطعی.
• سطح اعتماد:
  • متوسط

POST /api/crop-simulation/yield-prediction/

• منبع داده: خروجی شبیه‌سازی رشد و تبدیل آن به yield KPI.
• ضعف‌ها:
  • عملکرد نهایی به کیفیت شبیه‌سازی upstream وابسته است.
  • اگر داده soil fertility، weather یا management واقعی نباشند، yield estimate فقط تقریبی است.
  • حمایت از uncertainty interval یا confidence band دیده نمی‌شود.
• سطح اعتماد:
  • متوسط رو به کم

---

11) Farm Alerts API

POST /api/farm-alerts/tracker/

• منبع داده:
  • rule-based tracker
  • thresholdهای hard-coded
  • خلاصه و notification با RAG/LLM
• ضعف‌ها:
  • alert tracker پایه، heuristic و threshold-driven است.
  • آستانه‌های moisture، pH، EC، fungal risk و ... hard-coded هستند.
  • region-specific و crop-specific calibration محدود است.
  • اگر LLM JSON بد برگرداند، fallback rule-based جای آن را می‌گیرد.
• اگر فرمول/اطلاعات قابل اتکا نباشد:
  • برای هشدارآگاهی مناسب است، نه برای auto-actuation.
• سطح اعتماد:
  • متوسط برای شناسایی موارد مشکوک.
  • کم تا متوسط برای اقدام خودکار.

POST /api/farm-alerts/timeline/

• منبع داده: همان tracker + LLM timeline.
• ضعف‌ها:
  • timeline بیشتر narration است تا سنجش مستقل.
  • اگر مبنای alertها heuristic باشد، timeline فقط همان heuristic را بازبسته‌بندی می‌کند.
• سطح اعتماد:
  • کم تا متوسط

---

12) RAG API

POST /api/rag/chat/

• منبع داده:
  • farm context
  • history
  • images احتمالی
  • retrieval از knowledge base
  • LLM
• ضعف‌ها:
  • پاسخ stream می‌شود و structure قراردادی سختی ندارد.
  • hallucination، retrieval miss، و dependence به prompt/tone وجود دارد.
  • برای سوال‌های policy/diagnosis/operation ممکن است confident but wrong باشد.
• اگر فرمول/اطلاعات قابل اتکا نباشد:
  • این endpoint باید دستیار تحلیلی در نظر گرفته شود، نه source of truth.
• سطح اعتماد:
  • کم تا متوسط

---

13) جمع‌بندی نهایی بر اساس کاربرد

APIهای مناسب برای استفاده عملی‌تر

• POST /api/farm-data/
• GET /api/farm-data/{farm_uuid}/detail/
• GET|POST /api/soil-data/
• POST /api/weather/farm-card/

این‌ها بیشتر data-centric هستند و اگر داده منبع خوب باشد، قابل اتکاترند.

APIهای مناسب برای dashboard و insight، نه تصمیم قطعی

• POST /api/soile/moisture-heatmap/
• POST /api/soile/health-summary/
• POST /api/weather/water-need-prediction/
• POST /api/crop-simulation/current-farm-chart/
• POST /api/crop-simulation/harvest-prediction/
• POST /api/crop-simulation/yield-prediction/
• POST /api/farm-alerts/tracker/
• POST /api/farm-alerts/timeline/

APIهای کم‌اعتماد یا نیازمند بازطراحی

• POST /api/economy/overview/
• POST /api/plants/fetch-info/
• POST /api/irrigation/water-stress/ در حالت fallback
• POST /api/pest-disease/detect/ برای diagnosis قطعی
• POST /api/pest-disease/risk/
• POST /api/rag/chat/ برای پاسخ‌های حساس و اجرایی

---

14) پیشنهاد اولویت اصلاح

1. حذف fallback ساده از water-stress یا حداقل expose کردن صریح نوع engine در top-level response
2. جایگزینی mock در economy با data pipeline واقعی
3. پیاده‌سازی واقعی plants/fetch-info
4. افزودن uncertainty و freshness صریح به heatmap و water-need outputs
5. crop-specific و region-specific کردن alert/risk thresholds
6. اضافه کردن confidence واقعی و source provenance استاندارد به تمام endpointهای RAG-based