**Full Development Prompt for Nature in Pots**

**Context:**
You are ChatGPT, assisting with the continued development of the "Nature in Pots" Flask web application. The app uses MySQL, Neo4j, SQLAlchemy, Flask-Migrate, and a plugin structure. You will be provided a ZIP file containing the entire codebase. Your task is to:

1. **Review Every File in the ZIP**

   * **Scan every single line and file** without exceptions or omissions.
   * Only use code present in the ZIP as source of truth. Do **not** assume or generate context beyond what the files contain.
   * Persistently store the reviewed code in memory for reference in all subsequent responses.

2. **Incorporate All Historical Changes & Conversations**

   * The code you see may already include modifications from earlier prompts (media plugin, submissions plugin, vendor affiliation, image voting, vendor claims, etc.). When generating any new code, **explicitly reference existing code** structures, naming conventions, imports, and file placements from the ZIP.
   * Integrate **all features and rules** we have specified so far, including but not limited to:

     * **Authentication & Core Models**: `User`, `Role`, `user_roles` many-to-many, `has_role()`, hashed passwords, Flask-Login user\_loader, CSRF on auth forms.
     * **Media Plugin**: `Media`, `ImageHeart` model (likes/dislikes), `FeaturedImage`, image filename randomization, EXIF stripping, storage under `/static/uploads`, AJAX endpoints for voting, batch job every 12 hours to select top-voted image per species, exclude logos/avatars from voting, `net_votes` column on `Media`.
     * **Submissions Plugin**: Submission types (`market_price`, `name_correction`, `new_plant`, `mutation`, `vendor_rating`, `vendor_alias`), `Submission.plant_id`, vendor fields (`vendor_id`, `old_vendor_id`, `new_vendor_id`), form logic for conditional fields, CSRF, redirect `/submission/` to `/submission/new`, list and view routes filtered by user role, image uploads, preventing self-ratings, ex-affiliate flags, vendor alias community voting with `VendorAliasVote` model, thresholds, vendor appeals via `VendorAliasAppeal`, admin override, redirect behaviors.
     * **Vendor Profiles & Affiliations**: `VendorProfile` (`owner_id`, `business_name`, `description`, `logo_url`, `is_active`, `unclaimed` logic), `VendorMember` (`joined_at`, `left_at`, `left_reason`), `VendorAffiliationRequest` (user-initiated or owner-initiated), owner or admin can approve/reject, owner can forcibly remove members, store affiliation history, prevent self-voting by active members, allow ex-affiliate rating flagged, claims: `VendorClaimRequest` to claim unclaimed vendors, admin review, set `is_active=True`, assign `owner_id`.
     * **Grow-Log Plugin**: `PlantUpdate` and `UpdateImage` models, BigInteger IDs, `is_public` flag, share-by-key mechanism, personal vs. vendor context (`vendor_id` on `PlantUpdate`), image uploads use shared `Media` table, only public images eligible for voting, owners choose a personal featured image per plant instance.
     * **Ownership & Transfers Plugin**: `TransferRequest`, `PlantOwnershipLog` extended with `date_released` and `transfer_note`, `Plant` has `owner_id` (user or vendor) and `vendor_id` (nullable), standard transfer flows (owner-to-owner), purchase-proof transfers (invoice upload, admin/moderator approval), migrations, CSRF, role checks.
     * **Search Plugin**: AJAX autocomplete on common/scientific names, search results page, navbar integration with JS snippet, templates.
     * **Trait & Health Events Plugin**: `Trait` and `HealthEvent` models, image attachments, admin approval queue, display under "Health & Traits" tab, optional standardized `PestType` and `CareType` lookup tables.
     * **Vendor Dashboard & Inventory**: `VendorProfile` and `VendorMember`, unclaimed vs. active vendors, claim workflow, owner and member management, plant inventory management (assign `plant.vendor_id` or personal), multiple vendor profiles per user, pending transfer requests within vendor context.
     * **Admin Dashboard**: Queues for all pending items (Submissions, Traits, HealthEvents, TransferRequests, VendorClaimRequests, VendorAffiliationRequests, VendorAliasAppeals), user management (role assignment, cannot demote super admin), ability to override community featured images (`Plant.override_featured_media_id`), CSV exports, ERD viewer.
     * **Marketplace & Analytics**: `Listing` and `PriceHistory` models, listing CRUD, price-trend charts (Recharts), analytics metrics (top-selling plants, vendor performance, marketplace price distributions).
     * **PWA & Offline Support**: `manifest.json`, `service-worker.js`, caching strategies, responsive design, offline GrowLog drafts.

3. **Include All Recent Changes & Rules**

   * Vendors cannot vote on images "as a vendor"; votes are always tied to the user account.
   * Community may add unclaimed vendors when adding a plant or purchase-based submission; vendors later claim their profile via `VendorClaimRequest`.
   * Prevent a user from rating a vendor they currently own or belong to (active `VendorMember`). Ex-affiliate ratings are allowed but flagged.
   * Vendor alias submissions: approval paths are vendor self (if active member of both), admin, or community voting (threshold); vendors can appeal alias, admin or community may reject based on votes.
   * Image voting logic: likes/dislikes stored in `ImageHeart`; toggling vote nullifies prior vote; update `Media.net_votes`; exclude logos and avatars.
   * Batch job every 12 hrs updates `Plant.featured_media_id` based on highest `net_votes` among `media.is_public=True`.
   * Vendor affiliations: multiple users per vendor; track `joined_at`, `left_at`, `left_reason`; affiliation requests and approvals; owner can remove members unilaterally.
   * Plant-addition form: prepopulate vendors dropdown; if user chooses "Add New Vendor", show inline minimal vendor fields (name, URL); create unclaimed vendor in background.
   * Purchase-proof transfers: user requests a transfer by submitting invoice; vendor or moderator/admin approves; then proceed with standard transfer logs.

4. **When Generating New Code or Modifications**

   * Always reference existing file paths, blueprints, model names, import statements, migrations, templates, and static assets from the ZIP. E.g., if adding a new model, follow the existing pattern in `plugins/<plugin>/models.py`.
   * For every new or updated file, provide the full file contents including imports, class definitions, blueprint registration, and template code as necessary—**never partial snippets**.
   * If migrations are needed, supply a complete Alembic revision file with `upgrade()`/`downgrade()` including all column/table changes; name the revision descriptively (e.g., `phase3_growlog_models_added`).
   * When modifying templates, show the full Jinja2 file, include `{% csrf_token() %}` in forms, ensure blocks match `base.html` inheritance.
   * For static content (CSS/JS), reference existing asset locations; if adding new JS for AJAX voting or dynamic form field toggling, place it under the same `static/js/` directory and update `base.html` or relevant templates to include the script.

5. **Testing & Verification**

   * After each phase’s changes, describe how to manually test: e.g., "Log in as a user with Vendor role, navigate to /vendor/dashboard, click 'Add Plant', verify vendor dropdown and inline vendor creation, submit Plant, check DB record, attempt image vote, etc.".
   * Provide instructions for verifying image storage: ensure uploaded files appear under `static/uploads/<YYYY>/<MM>/<DD>/`, are persisted by Docker volume, and accessible via `/media/files/<path>`.
   * Show how to test purchase-proof transfer: as a member, buy from an existing vendor, upload invoice, check that a `TransferRequest` is created; log in as vendor owner, approve, confirm `Plant.owner_id` changes.
   * Demonstrate vendor-affiliation flows: a normal user requests to join vendor, vendor owner approves, record `VendorMember` created; if removed, `left_at` set and voting blocked.

6. **Final Instructions**

   * **Only modify code under** `app/` and `plugins/` directories—do not create files elsewhere.
   * Keep plugin discovery and blueprint registration intact (e.g., ensure each plugin has `plugin.json` with correct metadata). Do not remove any existing plugin scaffolding files.
   * Include any adjustments necessary to `app/__init__.py` (e.g., blueprint imports, CLI registration) if new plugins or routes are added.
   * For Docker setup: ensure `docker-compose.yml` still maps `./static/uploads` as a volume so that image files persist outside the container.
   * When providing a response, indicate which files were added or changed by listing their relative paths and giving full contents.
   * Always include a brief summary of that phase’s changes and a manual testing plan.
   * **Wait for a new ZIP upload** before implementing changes. After reviewing the ZIP, return a short acknowledgement: "Got it, ready to review." then proceed phase by phase.

**End of Prompt**