update

plan.md

@@ -0,0 +1,41 @@
+## Plan: Thrift Resale Dashboard
+
+Build a greenfield internal dashboard for a 3-person reselling workflow, optimized for fast item intake, flexible templates, searchable inventory, and profit visibility. Recommended default stack for implementation is a Python-first web app, ideally Django + PostgreSQL + server-rendered forms with a small amount of HTMX for fast interactions. That fits the user's readability preference, keeps auth/data modeling simple, and reduces complexity for an internal tool.
+
+**Steps**
+1. Define the domain model and workflow boundaries first: items, templates, users, status history, sold listings, pricing estimates, and profit calculation rules. Capture the minimum viable lifecycle from acquisition to sale so implementation does not drift into marketplace-management scope.
+2. Scaffold the app foundation: authentication, database, local dev setup, environment config, and a simple layout shell for the dashboard. Use built-in auth patterns where possible so user attribution is straightforward from the start.
+3. Build item intake and templates: create editable item templates for common thrifting categories, allow one-click creation from templates, and make properties customizable per template so the team can adapt as buying patterns change.
+4. Build inventory views and filters: implement item search across multiple fields and filters such as category, status, owner, acquisition date, price range, estimated value, and sale channel. Prioritize fast filtering and low-friction navigation over complex reporting.
+5. Build pricing and profit estimation: support manual resale price suggestions at first, then integrate an external sold-comps source as a pluggable service. Cache retrieved comps, show the source and date, and always allow manual override when the estimate is wrong or unavailable.
+6. Add sales tracking and profitability: track sold price, fees, shipping, net profit, time-to-sell, and item-level margin. Make it easy to mark items as sold and associate them with the person who added them.
+7. Add operational quality-of-life features that fit the internal scope: photo uploads, quick notes, condition grading, bulk status updates, and a simple dashboard summary for inventory value, sales velocity, and profit by user/category.
+8. Write the supporting markdown docs for future code agents and maintainers: architecture overview, data model, workflow notes, pricing integration notes, and an implementation checklist so later agents can work without re-discovering decisions.
+9. Verify each slice with focused tests and a small end-to-end pass: auth, item/template CRUD, filtering, profit math, and pricing suggestion fallback behavior. Keep manual review focused on usability from intake to sale.
+
+**Relevant files**
+- `docs/architecture.md` - stack choice, system boundaries, and major components.
+- `docs/domain-model.md` - entities, relationships, and lifecycle states.
+- `docs/workflows.md` - intake, templating, selling, and edit flows.
+- `docs/pricing.md` - comp sourcing, caching, overrides, and fallback rules.
+- `docs/agent-guide.md` - conventions and instructions for future code agents.
+- `app/` or equivalent project root - implementation of auth, inventory, search, and reporting once the repo is scaffolded.
+
+**Verification**
+1. Confirm the initial schema supports the full item lifecycle without migrations that force redesign.
+2. Validate that a new item can be created from a template in a small number of steps.
+3. Validate multi-filter search returns expected results and stays responsive on realistic inventory sizes.
+4. Validate pricing suggestions fall back cleanly when external comps are unavailable and never block item entry.
+5. Validate profit calculations against known sample sales and ensure item attribution always shows the creator.
+
+**Decisions**
+- Scope is internal-only for a 3-person company; prioritize usability and speed of entry over permissions complexity.
+- Use simple email/password auth for the first release; no role-based permission system unless a later need appears.
+- Marketplace pricing should be advisory, not blocking, with manual overrides always available.
+- Start with a Python/Django-style implementation unless you decide to force a different stack later.
+- Keep public marketplace posting automation out of the first phase; the first version is about inventory, pricing, and profitability tracking.
+
+**Further Considerations**
+1. If you want the plan to assume a different stack than Django/PostgreSQL, tell me before implementation and I will revise the architecture section.
+2. If you want eBay sold-comps integration to be authoritative rather than advisory, the plan should add API credential, caching, and failure-handling requirements up front.
+3. If you expect to manage many item photos or barcode scans, the plan should add storage and capture workflow details now rather than later.