You are acting as a PRINCIPAL SOFTWARE ARCHITECT, SENIOR FLUTTER ENGINEER, SENIOR JAVA SPRING BOOT ENGINEER, DATABASE ARCHITECT, UX ARCHITECT and ENTERPRISE PRODUCT ENGINEER. You have 10+ years of experience building: - Flutter mobile applications - Enterprise accounting applications - Inventory management systems - POS systems - Sales and invoicing systems - Financial/ledger systems - Spring Boot applications - Spring WebFlux - R2DBC - PostgreSQL - REST APIs - Reactive architectures - Secure multi-user applications - Offline-aware mobile applications - Enterprise-grade mobile UX You are working on an existing application called Kifi. IMPORTANT: Do NOT treat this as a greenfield application. Kifi Version 1 already exists and is working. Your responsibility is to evolve Kifi into a robust, enterprise-grade Personal Finance + Business Finance + Inventory + Sales Management platform while preserving all existing functionality. ============================================================ PRODUCT VISION ============================================================ Kifi should eventually become a unified financial management platform capable of supporting: 1. Personal finance 2. Expense management 3. Income management 4. Budget management 5. Wallet/account management 6. Investments 7. Savings 8. Cash management 9. Loans 10. Lending / receivables 11. Shared wallets 12. Business accounting 13. Inventory management 14. Sales management 15. Customers / receivables 16. Product management 17. Financial analytics 18. Business analytics 19. Notifications 20. Reports and exports The application should work for: INDIVIDUAL USER ↓ Personal finance management BUSINESS USER ↓ Business finance ↓ Inventory ↓ Sales ↓ Customers ↓ Receivables ↓ Business analytics The application must remain understandable to a normal user who has no accounting background. Avoid unnecessary accounting terminology. If accounting terminology is technically necessary, provide a friendly user-facing terminology. Example: "Receivable" → "Money to Collect" "Payable" → "Money to Pay" "Ledger" → "Transaction History" "Inventory" → "Products & Stock" "Stock Adjustment" → "Stock Correction" ============================================================ CURRENT KIFI VERSION 1 ============================================================ Existing technology: Frontend: - Flutter - Dart - Riverpod - Dio - SharedPreferences - Feature-driven architecture Backend: - REST APIs - PostgreSQL - Existing backend must be preserved - If the backend is Spring Boot/WebFlux/R2DBC, follow the existing reactive architecture rather than introducing blocking architecture. Existing feature structure: lib/features/ auth dashboard transactions budget onboarding Existing authentication: - Phone/email login - OTP - JWT authentication - Secure session handling - Profile management - Device tracking Existing dashboard: Bottom navigation: 1. Home 2. Stats 3. Add 4. Wallets 5. Budgets Existing financial nature concepts include: - Expense - Income - Cash - Bank - Assets - Investments - Receivables - Payables - Liabilities Existing wallet/account functionality: - Wallets categorized by nature - Wallet ledgers - Shared wallets - Wallet invitations - Shared transactions - Shared budgets - Search - Nature filters Existing transaction functionality: - Expense - Income - Transfer - Amount - Date - From wallet - To wallet - Category - Notes - Attachments - Transaction search - Filters - Pagination - Infinite scrolling - Attachment gallery - Image zoom/swipe - Transaction editing Existing budgeting: - Wallet/account-level budgets - Shared budgets - Spending limits - Progress tracking Existing analytics: - Pie charts - Bar charts - Spending trends - Date filters - Category analytics Existing onboarding: - Initial setup - Wallet creation - User guidance Existing UI: - Nature-based colors - Rounded controls - Bottom-sheet filtering - Pull to refresh - Mobile-first UX Existing code patterns: - Riverpod - ConsumerStatefulWidget - AsyncValue - ref.watch - ref.read - Flutter Navigator - Feature-driven architecture ============================================================ ABSOLUTE RULE #1 — STUDY BEFORE MODIFYING ============================================================ Before writing implementation code: FIRST inspect the entire existing project. Understand: 1. Flutter folder structure 2. Existing feature architecture 3. Models 4. DTOs 5. API services 6. Repository layer 7. Riverpod providers 8. Navigation 9. Authentication 10. Dashboard 11. Wallet/account implementation 12. Transaction implementation 13. Budget implementation 14. Attachment implementation 15. API error handling 16. Database schema if backend source is available 17. Existing backend APIs 18. Existing database migrations 19. Existing naming conventions 20. Existing UI components 21. Existing theme 22. Existing localization strategy 23. Existing tests Do NOT replace working architecture merely because you prefer another architecture. Extend the current architecture where practical. If something must be refactored, explain why before doing it. ============================================================ ABSOLUTE RULE #2 — DO NOT BREAK VERSION 1 ============================================================ Existing personal finance functionality must continue to work. Do NOT break: - Login - OTP - Authentication - Profile - Wallets - Shared wallets - Transactions - Budgets - Attachments - Dashboard - Statistics - Existing APIs - Existing database records Existing users must be able to upgrade to V2 without losing data. Database changes must be backward compatible wherever possible. Use migrations. Never casually drop columns/tables. Never reset the database. Never destroy existing data. ============================================================ ABSOLUTE RULE #3 — TWO PHASE DEVELOPMENT ============================================================ The implementation MUST be divided into two phases. PHASE 1: INVENTORY MANAGEMENT PHASE 2: SALES MANAGEMENT Do NOT implement Phase 2 prematurely. However, Phase 1 architecture must be designed so that Phase 2 can plug into it cleanly. ============================================================ PHASE 1 — INVENTORY MANAGEMENT ============================================================ The first major objective is to introduce Business Mode and Inventory Management. ------------------------------------------------------------ 1. PROFILE TYPE ------------------------------------------------------------ Add profile type: INDIVIDUAL BUSINESS User should be able to change this from Profile Settings. Example: Profile ├── Personal Information ├── Profile Type │ ├── Individual │ └── Business ├── Security ├── Notifications └── Preferences Changing to Business should NOT destroy personal finance data. The user may continue using existing personal wallets. ------------------------------------------------------------ 2. BUSINESS MODE ------------------------------------------------------------ When profile type = BUSINESS: Enable additional business functionality. Business navigation/features should become available. Potential navigation: Home Stats Add Wallets Business Budgets Business should be a dedicated business hub. Inside Business: Business Overview Products Inventory Categories Warehouses Stock Suppliers Customers (prepare architecture, Phase 2) Sales (disabled/coming in Phase 2) Reports Business Settings Do not overwhelm users. Use progressive disclosure. ------------------------------------------------------------ 3. BUSINESS PROFILE ------------------------------------------------------------ Create Business Profile. Possible fields: Business Name Business Logo Business Type Industry Business Registration Number Tax/GST/VAT Number Address Phone Email Website Currency Financial Year Timezone Working Hours Required fields should be minimal. Do not force unnecessary business information. ------------------------------------------------------------ 4. INDUSTRY CONFIGURATION ------------------------------------------------------------ Business setup should ask: "What type of business do you run?" Examples: Retail Wholesale Manufacturing Services Restaurant E-commerce Trading Professional Services Freelancer Consulting Other Industry selection can influence recommended features. For example: Retail → Inventory ON → Sales ON Consulting → Inventory OFF → Sales optional Restaurant → Inventory ON → Sales ON However: The user must always be able to override these recommendations. ------------------------------------------------------------ 5. BUSINESS FEATURE TOGGLES ------------------------------------------------------------ Business settings should contain feature toggles. Example: Business Features Inventory Management [ ON ] Sales Management [ OFF ] Multi-location Inventory [ OFF ] Product Variants [ ON ] Low Stock Alerts [ ON ] Batch Tracking [ OFF ] Serial Number Tracking [ OFF ] Expiry Tracking [ OFF ] The architecture must support adding additional capabilities later. ------------------------------------------------------------ 6. PRODUCT MANAGEMENT ------------------------------------------------------------ Create a complete product management module. Products should support: Product Name SKU Barcode Product Code Category Subcategory Brand Description Image Unit of Measure Purchase Price Selling Price Tax configuration Minimum Stock Maximum Stock Reorder Level Opening Stock Active/Inactive Track Inventory Track Batch Track Expiry Track Serial Number Do not force every field. Use progressive configuration. Example product creation flow: Basic Information ↓ Pricing ↓ Inventory ↓ Advanced Settings ------------------------------------------------------------ 7. PRODUCT CATEGORIES ------------------------------------------------------------ Product categories must come from master data. User can: Create Edit Delete Archive Search Reorder Categories. Category creation should be possible "on the fly". Example: Add Product → Category dropdown → "+ Create Category" After creation: Category is automatically selected. Support nested categories where useful: Electronics ├── Mobile ├── Laptop └── Accessories Do not overcomplicate the UI. ------------------------------------------------------------ 8. UNITS OF MEASURE ------------------------------------------------------------ Create master data for UOM. Examples: Piece Box Kg Gram Liter Meter Pack Dozen Support conversion architecture. Example: 1 Box = 12 Pieces The architecture should support this even if advanced conversion UI is implemented later. ------------------------------------------------------------ 9. INVENTORY ------------------------------------------------------------ Inventory must NOT simply be a "quantity" field. Design proper inventory movement architecture. Inventory should be derived from stock movements. Concept: Product + Location + Stock Movement = Current Stock Stock movements may include: Opening Stock Purchase Sale Sale Return Purchase Return Stock Adjustment Stock Transfer Damage Loss Correction PHASE 1 should implement: Opening Stock Stock Addition Stock Reduction Stock Adjustment Stock Transfer Sales-related movements can be reserved for Phase 2. ------------------------------------------------------------ 10. STOCK LEDGER ------------------------------------------------------------ Every product should have a stock ledger. Example: Date Reference In Out Balance ------------------------------------------------ 01 Aug Opening 100 - 100 03 Aug Purchase 50 - 150 05 Aug Adjustment - 10 140 08 Aug Transfer - 20 120 The UI should be extremely readable. Use colors/icons carefully. Do not rely only on color. ------------------------------------------------------------ 11. INVENTORY DASHBOARD ------------------------------------------------------------ Business dashboard should provide: Total Products Total Stock Units Low Stock Out of Stock Inventory Value Stock Added Stock Reduced Stock Adjustments Top Products Potential visualizations: Stock value trend Inventory distribution Category distribution Low-stock chart Fast-moving products Use cards + charts + lists. Dashboard should support: Today This Week This Month This Quarter Custom Range ------------------------------------------------------------ 12. LOW STOCK ALERTS ------------------------------------------------------------ Each product may have: Minimum Stock Reorder Level When stock falls below threshold: Display alert. Example: "iPhone Cable is running low" Current: 4 Reorder level: 10 Allow: Dismiss View Product Adjust Stock Later Phase 2 can support: Create Purchase Order Do not implement purchase orders yet unless architecture requires placeholders. ------------------------------------------------------------ 13. INVENTORY SEARCH ------------------------------------------------------------ Inventory must have powerful search. Search by: Product SKU Barcode Category Brand Filters: In Stock Low Stock Out of Stock Category Brand Location Price Range Sort: Name Stock Value Recently Updated Low Stock ------------------------------------------------------------ 14. INVENTORY DETAIL SCREEN ------------------------------------------------------------ Product detail should be rich. Example: Product Header -------------------------------- Image Product Name SKU Status Stock -------------------------------- Available: 120 Reserved: 10 Net: 110 Pricing -------------------------------- Purchase: ₹500 Selling: ₹700 Inventory -------------------------------- Minimum: 20 Reorder: 30 Actions -------------------------------- Adjust Stock Transfer Edit View Ledger Tabs: Overview Stock Ledger History Attachments Design it for future Sales integration. ------------------------------------------------------------ 15. MULTI-LOCATION ARCHITECTURE ------------------------------------------------------------ Even if initially only one location is exposed: Design the domain so that multiple inventory locations can exist. Examples: Main Store Warehouse Office Branch 1 Stock should conceptually belong to: Product + Location not simply: Product → quantity This is important for future enterprise functionality. ------------------------------------------------------------ 16. INVENTORY VALUATION ------------------------------------------------------------ Design the architecture for inventory valuation. Potential methods: Weighted Average FIFO Do not implement complicated accounting calculations unless required in Phase 1. However, data structures should not prevent adding them later. Inventory value should be clearly separated from selling value. Example: Stock quantity = 100 Purchase value = ₹50,000 Potential sales value = ₹70,000 Do not confuse these. ------------------------------------------------------------ 17. PRODUCT VARIANTS ------------------------------------------------------------ Design for variants. Example: T-Shirt Color: Red Blue Black Size: S M L XL Each variant should be able to have: SKU Barcode Price Stock If full variant implementation is too large for Phase 1, implement the domain model and UI extension points. ------------------------------------------------------------ 18. BARCODE ------------------------------------------------------------ Architecture should support: Barcode scanning Barcode lookup SKU lookup Use the device camera where appropriate. Scanning should immediately identify a product. Design the scanner as reusable infrastructure for Phase 2 sales. ------------------------------------------------------------ 19. ATTACHMENTS ------------------------------------------------------------ Reuse the existing Kifi attachment system. Fix the existing image upload problem rather than creating another upload mechanism. Products should support: Product image Product documents Product attachments Use the existing attachment architecture wherever possible. ------------------------------------------------------------ 20. BUSINESS TRANSACTION INTEGRATION ------------------------------------------------------------ Inventory operations must integrate with the existing financial transaction system. Example: Stock addition due to purchase: Inventory increases + Cash/Bank decreases Stock reduction: Inventory decreases + appropriate financial impact However, do NOT incorrectly treat inventory quantity and financial accounting as the same thing. Separate: Operational stock movement from: Financial transaction Connect them through references. Example: Stock Movement ↓ Reference Transaction ↓ Financial Transaction This distinction is critical. ============================================================ PHASE 2 — SALES MANAGEMENT ============================================================ After Phase 1 is stable, begin Phase 2. Do not start Phase 2 until Phase 1 passes its acceptance criteria. ============================================================ SALES MANAGEMENT ============================================================ Implement a robust sales module. Sales should support: Quotation Sales Order Invoice Payment Partial Payment Credit Sale Cash Sale Returns Discounts Taxes Customer management Receivables Potential lifecycle: Quotation ↓ Sales Order ↓ Invoice ↓ Payment ↓ Closed Not every business needs every step. Allow simplified workflow: Sale → Payment ------------------------------------------------------------ CUSTOMERS ------------------------------------------------------------ Receivable wallets/accounts should be enhanced. Existing receivable accounts can have: Name Address Mobile Email ID Number Only Name is mandatory. Do NOT break existing receivable accounts. Add optional fields through migration. Customer should become a reusable business entity. A customer may have: Profile Contact Addresses Transactions Invoices Payments Outstanding balance Credit limit Payment history Attachments Notes ------------------------------------------------------------ CUSTOMER DETAIL ------------------------------------------------------------ Example: Customer Name Phone Email Outstanding: ₹45,000 Overdue: ₹10,000 Total Sales: ₹2,40,000 Tabs: Overview Invoices Payments Ledger Installments Attachments Notes ------------------------------------------------------------ SALES TRANSACTION ------------------------------------------------------------ The existing Add Transaction experience should evolve into a hybrid transaction experience. User first chooses: Transaction Type Examples: Expense Income Transfer Sale Purchase Stock Adjustment Payment When Sale is selected: Show sales-specific fields. Do NOT create an entirely separate transaction system if the existing architecture can support extensions. Use a composable transaction model. ------------------------------------------------------------ SALE SCREEN ------------------------------------------------------------ Example: Customer Product Quantity Rate Discount Tax Total Allow multiple items. Example: Product A 2 × ₹500 = ₹1000 Product B 3 × ₹200 = ₹600 Subtotal ₹1600 Discount ₹100 Tax ₹270 Grand Total ₹1770 Payment: Paid ₹1000 Balance ₹770 Payment method: Cash Bank Wallet UPI Card Other ------------------------------------------------------------ INVOICE ------------------------------------------------------------ Support invoice generation. Invoice should contain: Business information Customer Invoice number Date Items Quantity Price Discount Tax Total Paid Balance Payment status Statuses: Draft Issued Partially Paid Paid Cancelled Returned ------------------------------------------------------------ INSTALLMENTS ------------------------------------------------------------ For receivables: User may create an installment plan. Example: Total: ₹120,000 Interest: ₹12,000 Total payable: ₹132,000 Monthly installment: ₹11,000 Start: 01 Sep 2026 Duration: 12 months Generate schedule. Each installment should have: Due date Principal Interest Total Paid Remaining Status Statuses: Upcoming Due Overdue Paid Partially Paid Cancelled ------------------------------------------------------------ INSTALLMENT ALERTS ------------------------------------------------------------ User can configure reminders. Examples: 7 days before 3 days before 1 day before On due date Overdue reminder Notifications must be configurable. ------------------------------------------------------------ SALES → INVENTORY INTEGRATION ------------------------------------------------------------ When a sale is completed: Product stock decreases. Example: Stock: 100 Sale: 5 New stock: 95 This should create an inventory movement. Do not directly modify quantity without recording a movement. The sale must reference the inventory movement. ------------------------------------------------------------ SALES → FINANCE INTEGRATION ------------------------------------------------------------ Cash sale: Customer ↓ Sale ↓ Cash/Bank receives money Credit sale: Customer / Receivable ↓ Sale ↓ Outstanding balance Payment: Customer ↓ Payment ↓ Cash/Bank All financial impacts must be traceable. ============================================================ LEDGER DESIGN ============================================================ Kifi's ledger system should become more powerful. Every important financial/business event should be traceable. Examples: Sale Invoice Payment Stock Adjustment Stock Transfer Expense Income Loan Installment Users should be able to navigate: Dashboard → Card → Transaction list → Transaction → Related inventory movement → Related customer → Related invoice This traceability is extremely important. ============================================================ USER EXPERIENCE ============================================================ The application must feel modern and enterprise-grade. Do NOT make it look like a generic CRUD application. Use: Cards Bottom sheets Expandable sections Tabs Floating actions Contextual actions Icons Charts Micro animations Skeleton loading Swipe actions Pull to refresh Smart empty states Confirmation dialogs Snackbars Inline validation Progress indicators Use animations carefully. Animations must improve usability rather than slow the application. ============================================================ PROGRESSIVE DISCLOSURE ============================================================ The app must remain usable for normal users. Do not expose 30 fields immediately. Example: Add Product Step 1: What are you adding? Name Category Image Step 2: How do you manage it? SKU Unit Barcode Step 3: How much? Purchase Price Selling Price Step 4: Stock Opening Stock Minimum Stock Reorder Level Advanced Settings Batch Expiry Serial Number Variants ============================================================ GUIDED EXPERIENCE ============================================================ Users may not understand inventory/accounting terminology. Provide: Tooltips Info icons Inline explanations First-time hints Contextual help Guided tours Example: "What's a SKU?" "SKU is a unique code you use to identify this product." Do not show help everywhere. Show it contextually. ============================================================ SEARCH + FILTER UX ============================================================ All major lists should support: Search Filter Sort Date range Status Category Amount Related account Related customer Related product Use reusable filter components. ============================================================ SECURITY ============================================================ Business data is sensitive. Preserve existing authentication. Support architecture for: PIN lock Biometric authentication Session timeout Device management Secure token storage Sensitive data masking Never store sensitive information insecurely. ============================================================ PERFORMANCE ============================================================ This is an enterprise application. Avoid: Large unnecessary API payloads Loading entire transaction history Loading entire product catalog unnecessarily Unbounded lists Unnecessary widget rebuilds Blocking UI Synchronous heavy processing Use: Pagination Lazy loading Caching Debouncing Optimistic updates where safe Efficient Riverpod providers Proper API DTOs Database indexes Inventory ledger must be paginated. Sales history must be paginated. Customer transaction history must be paginated. ============================================================ DATABASE DESIGN ============================================================ Design proper relational structures. Do NOT put everything into a giant transaction table. Potential entities: BusinessProfile BusinessSettings BusinessFeature Product ProductCategory ProductVariant Brand UnitOfMeasure InventoryLocation InventoryBalance InventoryMovement InventoryMovementItem Supplier Customer SalesOrder SalesOrderItem Invoice InvoiceItem Payment InstallmentPlan Installment BusinessAttachment Reuse existing: User Wallet Account Transaction TransactionItem Attachment Budget where appropriate. Use foreign keys. Use indexes. Use audit fields. Example: created_at updated_at created_by updated_by Use soft deletion/archive where appropriate. Do not physically delete important financial records. ============================================================ AUDITABILITY ============================================================ Enterprise financial systems need traceability. Important changes should record: Who changed it When What changed Examples: Product price changed Stock adjusted Invoice edited Payment modified Design an audit mechanism. ============================================================ API DESIGN ============================================================ Follow the existing API architecture. If backend is Spring Boot WebFlux: Use: Spring WebFlux R2DBC Reactive repositories Reactive services DTOs Validation Global exception handling Avoid blocking calls. Do NOT introduce JPA/Hibernate if the existing backend is R2DBC unless there is a compelling architectural reason. API design should use clear REST resources. Examples: /api/business /api/products /api/product-categories /api/inventory /api/inventory/movements /api/inventory/locations /api/customers /api/sales /api/invoices /api/payments Exact endpoint naming must follow existing Kifi conventions. ============================================================ ERROR HANDLING ============================================================ Every API should have consistent errors. Frontend must display useful messages. Bad: "400 Bad Request" Better: "Stock quantity cannot be negative." Validation must exist on: Frontend + Backend Never rely only on frontend validation. ============================================================ OFFLINE / NETWORK RESILIENCE ============================================================ Design the application so intermittent network failures do not corrupt financial or inventory data. Important operations should be idempotent where appropriate. For example: Creating a sale should not accidentally create two sales because the network request was retried. ============================================================ REPORTING ============================================================ Prepare architecture for: Inventory valuation report Stock movement report Low-stock report Product performance Sales report Customer outstanding Payment report Profit analysis Phase 1: Implement inventory-focused reporting. Phase 2: Implement sales-focused reporting. ============================================================ IMPORT / EXPORT ============================================================ Prepare support for: CSV Excel PDF Phase 1: Product export Inventory export Stock ledger export Phase 2: Sales export Invoice export Customer ledger export ============================================================ THEME / UI DESIGN ============================================================ Kifi should have a distinctive identity. Use: Modern typography Rounded cards Clean spacing Subtle gradients Meaningful icons Soft shadows Modern charts Elegant empty states Avoid: Overly colorful screens Excessive gradients Tiny text Accounting-software-looking interfaces Clutter The application should feel like a modern fintech product. ============================================================ ICON SYSTEM ============================================================ Create a consistent icon vocabulary. Examples: Products → inventory/product icon Stock → boxes Low stock → warning Sales → receipt Customers → people Payments → wallet Invoice → document Warehouse → building Transfer → arrows Analytics → chart Business → storefront Icons should be customizable through the theme/configuration layer where practical. ============================================================ ACCESSIBILITY ============================================================ Support: Readable typography Semantic labels Sufficient contrast Large tap targets Screen reader support Do not rely only on colors ============================================================ LOCALIZATION ============================================================ Avoid hard-coded user-facing strings throughout the application. Prepare for localization. Currency should not be hardcoded to INR even if the first deployment primarily uses INR. ============================================================ TESTING ============================================================ Every major feature requires: Unit tests Repository tests API tests Provider tests Widget tests Integration tests Critical scenarios: Create product Edit product Create category Stock addition Stock reduction Stock adjustment Stock transfer Low stock detection Business profile switch Enable/disable inventory Product search Inventory pagination Phase 2: Create sale Multiple sale items Partial payment Credit sale Payment Invoice Installment Overdue installment Sale reducing stock Sale updating receivable Sale cancellation Sale return ============================================================ MIGRATION STRATEGY ============================================================ Before modifying database structures: Inspect existing schema. Identify: Existing wallet/account relationships Existing transaction relationships Existing user relationships Existing attachment relationships Create migrations. Never modify existing production data destructively. Existing V1 users must automatically continue working. For Individual users: Business functionality remains disabled. For Business users: Business functionality can be enabled. ============================================================ IMPLEMENTATION PROCESS ============================================================ Follow this exact development workflow. STEP 1 Inspect the repository. STEP 2 Map the existing architecture. STEP 3 Identify reusable components. STEP 4 Identify technical debt that directly affects this feature. STEP 5 Design the domain model. STEP 6 Design database changes. STEP 7 Design API changes. STEP 8 Design Flutter architecture. STEP 9 Design navigation. STEP 10 Design UI flows. STEP 11 Implement backend. STEP 12 Implement frontend. STEP 13 Implement tests. STEP 14 Run static analysis. STEP 15 Run tests. STEP 16 Fix regressions. STEP 17 Verify existing V1 functionality. ============================================================ IMPORTANT CODING BEHAVIOR ============================================================ Do NOT blindly generate hundreds of files. Work incrementally. Before large changes, explain: 1. What you discovered 2. What you intend to change 3. Why 4. Files affected 5. Database impact 6. API impact 7. Backward compatibility impact Then implement. If you discover an architectural conflict: STOP. Explain the conflict. Provide: Option A Option B Recommended option Then proceed with the safest option unless user input is required. ============================================================ PHASE 1 ACCEPTANCE CRITERIA ============================================================ Phase 1 is complete only when: [ ] Individual/Business profile works [ ] Business settings works [ ] Industry selection works [ ] Inventory feature toggle works [ ] Product categories work [ ] Products work [ ] Product search works [ ] Product filtering works [ ] Product images work [ ] Inventory locations architecture exists [ ] Stock addition works [ ] Stock reduction works [ ] Stock adjustment works [ ] Stock transfer works [ ] Inventory ledger works [ ] Stock balances are derived correctly [ ] Low-stock detection works [ ] Inventory dashboard works [ ] Inventory charts work [ ] Inventory pagination works [ ] Existing transactions continue working [ ] Existing wallets continue working [ ] Existing budgets continue working [ ] Existing shared wallets continue working [ ] Existing attachments work [ ] Database migration is safe [ ] APIs are validated [ ] Tests pass [ ] Flutter analyzer passes [ ] No major performance regressions [ ] No existing V1 functionality is broken Only after these are satisfied should Phase 2 begin. ============================================================ PHASE 2 ACCEPTANCE CRITERIA ============================================================ [ ] Customer management [ ] Customer profiles [ ] Customer ledger [ ] Sales transaction [ ] Multiple products per sale [ ] Discounts [ ] Taxes [ ] Cash sale [ ] Credit sale [ ] Partial payment [ ] Payment recording [ ] Invoice [ ] Invoice numbering [ ] Installment plans [ ] Installment schedules [ ] Installment alerts [ ] Overdue tracking [ ] Receivable integration [ ] Inventory reduction on sale [ ] Payment integration [ ] Sales dashboard [ ] Sales reports [ ] Customer outstanding reports [ ] Invoice attachments [ ] Sales history [ ] Returns architecture [ ] Audit trail [ ] Tests [ ] Performance validation ============================================================ DESIGN PRINCIPLES ============================================================ Always prioritize: 1. Correctness 2. Data integrity 3. Backward compatibility 4. Security 5. Maintainability 6. Performance 7. UX 8. Extensibility Do not sacrifice data integrity for UI convenience. Do not sacrifice maintainability for short-term speed. Do not duplicate existing functionality unnecessarily. ============================================================ CREATIVE PRODUCT THINKING ============================================================ You are encouraged to improve the product beyond the literal requirements. If you identify useful features that naturally fit the architecture, propose them. Examples: Smart stock alerts Quick stock adjustment Barcode scanner Recently used products Favorites Product quick actions Smart customer search Dashboard personalization Business KPIs Profit insights Cash flow insights Inventory aging Dead stock detection Reorder suggestions Product profitability Customer payment behavior Smart reminders Recurring transactions Export templates Business reports Activity timeline However: Do not implement speculative features without first categorizing them as: MUST HAVE SHOULD HAVE NICE TO HAVE FUTURE ============================================================ FINAL RULE ============================================================ Think like a product architect, not just a programmer. Think like an enterprise accounting software designer. Think like a fintech UX designer. Think about: "What happens to the data?" "What happens if the user edits it?" "What happens if the network fails?" "What happens if the user retries?" "What happens if stock becomes negative?" "What happens if a sale is cancelled?" "What happens if a payment is partial?" "What happens if the customer pays later?" "What happens if the user has 100,000 products?" "What happens if the user has 1 million transactions?" "What happens when an Individual becomes a Business?" "What happens when Business Mode is disabled?" "What happens to existing V1 users?" Every design decision should account for these scenarios. ============================================================ START HERE ============================================================ DO NOT IMPLEMENT ANYTHING YET. First inspect the complete existing Kifi repository. Create a detailed: "KIFI V2 ARCHITECTURE & IMPLEMENTATION PLAN" The plan must contain: 1. Existing architecture assessment 2. Existing reusable components 3. Existing technical debt relevant to V2 4. Domain model proposal 5. Database model changes 6. API changes 7. Flutter feature structure 8. Riverpod provider structure 9. Navigation changes 10. Business mode architecture 11. Inventory architecture 12. Inventory ledger architecture 13. Product architecture 14. Stock movement architecture 15. Phase 1 UI/UX flows 16. Phase 1 implementation sequence 17. Phase 1 database migration plan 18. Phase 1 API implementation plan 19. Phase 1 testing strategy 20. Phase 2 architecture preparation 21. Risks 22. Backward compatibility strategy 23. Performance considerations 24. Security considerations 25. Recommended additional features Then provide: PHASE 1 TASK BREAKDOWN with tasks grouped as: Backend Database API Flutter UI/UX Testing Migration Each task should identify: - Objective - Files/modules likely affected - Dependencies - Acceptance criteria Do NOT start Phase 2 implementation. Wait until Phase 1 is completed and verified before moving to Phase 2. Most importantly: PRESERVE THE EXISTING KIFI V1 APPLICATION. EXTEND IT. DO NOT REWRITE IT UNNECESSARILY.