2207 lines
38 KiB
Markdown
2207 lines
38 KiB
Markdown
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. |