38 KiB
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:
- Personal finance
- Expense management
- Income management
- Budget management
- Wallet/account management
- Investments
- Savings
- Cash management
- Loans
- Lending / receivables
- Shared wallets
- Business accounting
- Inventory management
- Sales management
- Customers / receivables
- Product management
- Financial analytics
- Business analytics
- Notifications
- 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:
- Home
- Stats
- Add
- Wallets
- 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:
- Flutter folder structure
- Existing feature architecture
- Models
- DTOs
- API services
- Repository layer
- Riverpod providers
- Navigation
- Authentication
- Dashboard
- Wallet/account implementation
- Transaction implementation
- Budget implementation
- Attachment implementation
- API error handling
- Database schema if backend source is available
- Existing backend APIs
- Existing database migrations
- Existing naming conventions
- Existing UI components
- Existing theme
- Existing localization strategy
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
- 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.
- 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.
- 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.
- 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.
- 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
- 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.
- 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
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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:
- What you discovered
- What you intend to change
- Why
- Files affected
- Database impact
- API impact
- 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:
- Correctness
- Data integrity
- Backward compatibility
- Security
- Maintainability
- Performance
- UX
- 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:
- Existing architecture assessment
- Existing reusable components
- Existing technical debt relevant to V2
- Domain model proposal
- Database model changes
- API changes
- Flutter feature structure
- Riverpod provider structure
- Navigation changes
- Business mode architecture
- Inventory architecture
- Inventory ledger architecture
- Product architecture
- Stock movement architecture
- Phase 1 UI/UX flows
- Phase 1 implementation sequence
- Phase 1 database migration plan
- Phase 1 API implementation plan
- Phase 1 testing strategy
- Phase 2 architecture preparation
- Risks
- Backward compatibility strategy
- Performance considerations
- Security considerations
- 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.