Skip to content

Latest commit

 

History

2 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 

Repository files navigation

PROJECT: AI-Powered Crop & Plant Health Assistant (Production-Grade, Full Build)

CONTEXT Build a complete, production-quality, end-to-end web application in one pass — both frontend and backend fully implemented and working together — for farmers, agriculturists, and plant hobbyists to diagnose plant/crop health from a photo. Primary users are in India with mixed digital literacy, so the UI must be simple, visual, and mobile-first. Support Hindi and English at launch, but design the localization layer so additional languages can be added later without re-architecting anything.

SCOPE FOR THIS BUILD This is not a prototype or a wireframe — build the real thing: working frontend, working backend, database schema applied, API integration wired up end-to-end, so I can run it locally and actually use it today. Plan the architecture first (briefly), then build everything in one continuous pass — don't stop after the plan and wait for approval unless something is genuinely blocking.

CORE USER FLOW

  1. User opens the app (mobile web, works on low-end Android phones / weak internet).
  2. User selects language — Hindi or English — this persists across the session (store as a language code so more languages can be added later as a config change, not a code change).
  3. User uploads or captures a photo of a plant/crop/tree (leaf, stem, fruit, or whole plant).
  4. System analyzes the image and returns, in the user's chosen language: a. Crop/plant identification (name, and common regional name if known) b. Health status (healthy / diseased / pest-infested / nutrient deficiency) c. If unhealthy: disease/pest name, confidence level, visual symptoms matched d. Actionable treatment steps (organic + chemical options, dosage, timing) e. Preventive care tips going forward f. Sowing season guidance for that crop (best months, soil/climate notes) g. Expected harvest window from sowing, and how to tell it's ready
  5. User can save results to a history log (per plant/crop) to track over time.
  6. Optional: text-to-speech playback of results for low-literacy users.

FUNCTIONAL REQUIREMENTS

  • Image upload via camera or gallery, with client-side compression before upload.
  • Use the Claude API's vision capability (multimodal message: image + text) as the core analysis engine.
  • Force Claude to return strict JSON: crop_name, health_status, disease_name, confidence, symptoms_observed, treatment_organic, treatment_chemical, prevention_tips, sowing_window, harvest_window, harvest_readiness_signs. Generate this base analysis in English internally for consistency.
  • Localization layer: a separate step/prompt that takes the structured English result and produces natural, farmer-appropriate Hindi (correct agricultural terminology, not stiff machine translation) when Hindi is selected. Structure this as a pluggable function keyed by language code, so adding a third language later means adding one more localization prompt, not touching the pipeline.
  • Handle ambiguous/blurry images gracefully — ask the user to retake the photo with a clear, translated reason (poor lighting, too far, out of focus, etc.). Never hallucinate a diagnosis on unclear input.
  • History/dashboard: past scans per user, viewable and searchable by crop or date.
  • Auth: phone number + OTP flow (mock/stub the OTP provider for local dev, but structure it so swapping in a real provider like MSG91/Twilio is a config change).
  • Basic offline tolerance: if upload fails due to network drop, queue and retry automatically with a visible status indicator.

NON-FUNCTIONAL REQUIREMENTS

  • Mobile-first, responsive, performs acceptably on 3G/patchy connections (compressed assets, lazy loading, skeleton loaders).
  • Accessibility: large tap targets, high-contrast option, icons paired with text (not text-only) for low-literacy users, voice narration option.
  • Loading state during analysis (5-15 sec) with reassuring, localized micro-copy.
  • Encrypt stored images/health data at rest; don't retain data longer than needed unless the user opts into keeping history.
  • Backend should handle traffic bursts gracefully (e.g., basic rate limiting, queuing for the vision API calls).

TECH STACK

  • Frontend: React (PWA-installable, so it behaves like an app on rural Android phones without needing an app store)
  • Backend: Node.js/Express or Python/FastAPI — pick one and justify briefly
  • Database: PostgreSQL for structured data, S3-compatible storage for images
  • AI: Anthropic Claude API (vision + text) for diagnosis and localization
  • Auth: Phone OTP, stubbed provider for local dev
  • Deployment: Dockerized, so it can run locally with docker-compose and deploy to any standard cloud later

DELIVERABLES

  1. A short architecture overview (how the vision pipeline and localization layer work, why this stack).
  2. Database schema (users, scans, crops reference table, history) with migrations.
  3. The actual Claude API prompt templates: one for structured diagnosis (English), one for localization (Hindi), including the exact JSON schema enforced.
  4. Full working frontend: language selector, image capture/upload screen, results screen (with icons, not just text blocks), history screen, TTS playback control. Should feel like a real consumer product.
  5. Full working backend: image upload endpoint, Claude API integration (diagnosis
    • localization), auth endpoints (OTP request/verify), history CRUD endpoints.
  6. docker-compose setup so I can run frontend + backend + database locally with one command.
  7. README covering setup, required environment variables (including where my Anthropic API key goes), and how to run and test it locally.
  8. Explicitly call out anything that's stubbed/mocked for local dev vs. what needs a real credential/service before going to production (OTP provider, cloud storage bucket, etc.).

QUALITY BAR Build this as if real users will use it tomorrow: proper error handling, empty states, loading states, and warm, clear copy — not robotic placeholder text. The Hindi experience should read naturally to a native speaker with correct farming vocabulary, not translated UI labels bolted onto an English app.

Do the planning yourself and proceed straight to building. Only ask me a clarifying question if something is truly blocking (e.g., you need a real external credential you don't have) — otherwise make sensible production-grade decisions, note them, and keep going.

About

No description, website, or topics provided.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors