1070 lines
20 KiB
Markdown
1070 lines
20 KiB
Markdown
You are a senior software architect, Flutter/mobile engineer, and Spring Boot/Java backend engineer with 10+ years of production experience.
|
|
|
|
You are working on an EXISTING application repository.
|
|
|
|
Your job is to transform the existing application into a modern, platform-independent PERSONAL FINANCE MANAGEMENT application while preserving and reusing as much existing functionality as possible.
|
|
|
|
IMPORTANT:
|
|
Do NOT rebuild the application from scratch.
|
|
Do NOT replace working functionality simply because you prefer another architecture.
|
|
Do NOT introduce a new framework/state-management/library without first checking what the project already uses.
|
|
Do NOT make destructive database changes.
|
|
Do NOT remove existing features unless explicitly required.
|
|
|
|
============================================================
|
|
PRIMARY PRODUCT GOAL
|
|
============================================================
|
|
|
|
Transform the existing application into a personal finance/accounting management app for ordinary users.
|
|
|
|
The user should be able to:
|
|
|
|
- track income
|
|
- track expenses
|
|
- manage cash
|
|
- manage bank accounts
|
|
- manage savings
|
|
- manage investments
|
|
- track loans
|
|
- track money lent to others
|
|
- transfer money between wallets
|
|
- create budgets
|
|
- analyze spending
|
|
- view financial history
|
|
- attach receipts/documents/images
|
|
- share wallets with other users
|
|
|
|
The application must be understandable to users who know nothing about accounting.
|
|
|
|
Avoid accounting terminology in the UI where possible.
|
|
|
|
Use friendly terminology such as:
|
|
|
|
"Wallet"
|
|
"Money In"
|
|
"Money Out"
|
|
"Transfer"
|
|
"Savings"
|
|
"Investment"
|
|
"Money Lent"
|
|
"Loan"
|
|
"Balance"
|
|
|
|
Internal technical/accounting terminology may remain different if necessary.
|
|
|
|
============================================================
|
|
PHASE 0 — INSPECT BEFORE CODING
|
|
============================================================
|
|
|
|
FIRST inspect the entire repository.
|
|
|
|
Do NOT start making large changes immediately.
|
|
|
|
Understand:
|
|
|
|
1. Flutter architecture
|
|
2. Flutter state management
|
|
3. Flutter navigation
|
|
4. Existing screens
|
|
5. Existing widgets/components
|
|
6. Existing models
|
|
7. Existing API layer
|
|
8. Existing authentication
|
|
9. Existing transaction workflow
|
|
10. Existing account/wallet implementation
|
|
11. Existing category implementation
|
|
12. Existing items implementation
|
|
13. Existing attachment/image upload implementation
|
|
14. Existing wallet-sharing implementation
|
|
15. Spring Boot architecture
|
|
16. Controllers
|
|
17. Services
|
|
18. Repositories
|
|
19. DTOs
|
|
20. Entities
|
|
21. Database schema
|
|
22. Database migrations
|
|
23. Configuration
|
|
24. Security/authorization
|
|
25. Existing tests
|
|
|
|
Search the repository instead of guessing.
|
|
|
|
Identify what can be reused.
|
|
|
|
Identify broken functionality.
|
|
|
|
Identify technical debt that directly affects this transformation.
|
|
|
|
Then produce a concise report:
|
|
|
|
- Current architecture
|
|
- Current application workflow
|
|
- Current data model
|
|
- Current transaction model
|
|
- Existing reusable functionality
|
|
- Existing broken functionality
|
|
- Attachment implementation
|
|
- Wallet sharing implementation
|
|
- Risks
|
|
- Recommended implementation order
|
|
|
|
Only after this analysis begin implementation.
|
|
|
|
============================================================
|
|
PRODUCT REQUIREMENT
|
|
============================================================
|
|
|
|
The client wants to change the nature of the application.
|
|
|
|
Current application workflow is too limited.
|
|
|
|
New application:
|
|
|
|
PERSONAL FINANCE MANAGEMENT
|
|
|
|
============================================================
|
|
1. WALLETS
|
|
============================================================
|
|
|
|
Use "Wallet" as the primary user-facing concept instead of "Account" if this fits the existing architecture.
|
|
|
|
A wallet represents a place/type where money is tracked.
|
|
|
|
Examples:
|
|
|
|
Cash
|
|
Bank Account
|
|
Credit Card
|
|
Savings
|
|
Investment
|
|
Loan
|
|
Money Lent
|
|
Salary
|
|
Other
|
|
|
|
Users can create custom wallets.
|
|
|
|
However, the system must control the underlying financial nature/type.
|
|
|
|
Separate:
|
|
|
|
USER-FACING WALLET
|
|
from
|
|
SYSTEM FINANCIAL NATURE
|
|
|
|
Suggested internal nature values:
|
|
|
|
EXPENSE
|
|
INCOME
|
|
CASH
|
|
DEPOSIT
|
|
SAVINGS
|
|
INVESTMENT
|
|
LOAN
|
|
LEND
|
|
TRANSFER
|
|
|
|
You may improve this model if repository analysis indicates a better normalized design.
|
|
|
|
The user should not be able to create arbitrary financial natures.
|
|
|
|
Each wallet should support where applicable:
|
|
|
|
- id
|
|
- name
|
|
- icon
|
|
- customizable icon
|
|
- color/theme
|
|
- nature/type
|
|
- opening balance
|
|
- current balance
|
|
- currency
|
|
- description
|
|
- active/archived
|
|
- createdAt
|
|
- updatedAt
|
|
|
|
Prefer ARCHIVE over DELETE when transactions already reference a wallet.
|
|
|
|
Do not destroy historical financial data.
|
|
|
|
============================================================
|
|
2. TRANSACTIONS
|
|
============================================================
|
|
|
|
The primary "+" action should be extremely simple.
|
|
|
|
When the user taps "+":
|
|
|
|
Step 1:
|
|
Amount
|
|
|
|
Step 2:
|
|
From Wallet
|
|
|
|
Step 3:
|
|
To Wallet
|
|
|
|
Then:
|
|
|
|
- Category
|
|
- Description
|
|
- Items
|
|
- Attachments
|
|
- Date/time
|
|
- Notes
|
|
|
|
Negative transaction amounts must be supported.
|
|
|
|
Examples:
|
|
|
|
Expense:
|
|
Bank → Food/Expense
|
|
|
|
Income:
|
|
Income → Bank
|
|
|
|
Transfer:
|
|
Bank → Cash
|
|
|
|
Savings:
|
|
Bank → Savings
|
|
|
|
Investment:
|
|
Bank → Investment
|
|
|
|
Money lent:
|
|
Bank → Money Lent
|
|
|
|
Loan received:
|
|
Loan → Bank
|
|
|
|
The UI should explain From/To in simple language.
|
|
|
|
Example:
|
|
|
|
"From Wallet"
|
|
Where the money comes from.
|
|
|
|
"To Wallet"
|
|
Where the money goes.
|
|
|
|
Do not force users to understand debit/credit terminology.
|
|
|
|
============================================================
|
|
3. TRANSACTION EDITING
|
|
============================================================
|
|
|
|
Users must be able to edit:
|
|
|
|
- amount
|
|
- from wallet
|
|
- to wallet
|
|
- category
|
|
- description
|
|
- items
|
|
- attachments
|
|
- date/time
|
|
- notes
|
|
|
|
After editing:
|
|
|
|
- balances must be recalculated correctly
|
|
- reports must remain correct
|
|
- dashboard totals must remain correct
|
|
- ledger must remain correct
|
|
|
|
Support:
|
|
|
|
- edit
|
|
- delete/cancel
|
|
- attachment add/remove/replace
|
|
- item add/edit/remove
|
|
|
|
Use confirmation for destructive operations.
|
|
|
|
============================================================
|
|
4. ATTACHMENTS
|
|
============================================================
|
|
|
|
The existing image upload is currently not working.
|
|
|
|
FIX THE ROOT CAUSE.
|
|
|
|
Inspect the entire pipeline:
|
|
|
|
Flutter
|
|
→ request/multipart
|
|
→ Spring Boot
|
|
→ storage
|
|
→ database/reference
|
|
→ retrieval
|
|
→ Flutter display
|
|
|
|
Do not hide the error.
|
|
|
|
Support where practical:
|
|
|
|
- camera
|
|
- gallery
|
|
- file picker
|
|
- image preview
|
|
- multiple attachments
|
|
- upload progress
|
|
- retry
|
|
- delete
|
|
- replace
|
|
- error state
|
|
|
|
Preserve existing attachment data.
|
|
|
|
============================================================
|
|
5. WALLET SHARING
|
|
============================================================
|
|
|
|
Existing wallet-sharing functionality MUST remain.
|
|
|
|
Do not remove it.
|
|
|
|
Inspect the existing implementation first.
|
|
|
|
Preserve existing behavior.
|
|
|
|
Improve UX if useful.
|
|
|
|
Potential permissions:
|
|
|
|
OWNER
|
|
VIEW
|
|
EDIT
|
|
|
|
Authorization must be enforced on the backend.
|
|
|
|
Never rely only on Flutter UI restrictions.
|
|
|
|
============================================================
|
|
6. DASHBOARD
|
|
============================================================
|
|
|
|
Build a rich financial dashboard.
|
|
|
|
Include:
|
|
|
|
- total balance / net position
|
|
- income
|
|
- expenses
|
|
- savings
|
|
- investments
|
|
- loans
|
|
- money lent
|
|
- cash
|
|
- recent transactions
|
|
- budget status
|
|
- spending trends
|
|
- wallet summaries
|
|
|
|
Provide nature-based tabs/cards such as:
|
|
|
|
All
|
|
Cash
|
|
Spending
|
|
Savings
|
|
Investments
|
|
Loans
|
|
Money Lent
|
|
|
|
Each card should show:
|
|
|
|
- current balance
|
|
- trend
|
|
- relevant summary
|
|
- icon
|
|
- visual indicator
|
|
|
|
Cards must be tappable.
|
|
|
|
Tap a card → detailed ledger.
|
|
|
|
============================================================
|
|
7. LEDGER
|
|
============================================================
|
|
|
|
Dashboard cards and wallets should open a ledger-style transaction view.
|
|
|
|
Conceptually show:
|
|
|
|
Date | Amount | From | To | Balance
|
|
|
|
On mobile use responsive cards/list rows rather than literal desktop tables.
|
|
|
|
Each transaction should show:
|
|
|
|
- date/time
|
|
- amount
|
|
- from wallet
|
|
- to wallet
|
|
- category
|
|
- description
|
|
- attachment indicator
|
|
- item count
|
|
- running balance
|
|
|
|
Support:
|
|
|
|
- search
|
|
- date range
|
|
- wallet filter
|
|
- nature filter
|
|
- category filter
|
|
- amount range
|
|
- income/expense filter
|
|
- attachment filter
|
|
- sorting
|
|
- ascending/descending
|
|
- pagination/infinite scrolling
|
|
|
|
============================================================
|
|
8. CATEGORIES
|
|
============================================================
|
|
|
|
Preserve existing categories.
|
|
|
|
Improve where appropriate.
|
|
|
|
Examples:
|
|
|
|
Food
|
|
Transport
|
|
Shopping
|
|
Bills
|
|
Health
|
|
Education
|
|
Entertainment
|
|
Salary
|
|
Freelance
|
|
Investment
|
|
Loan
|
|
Other
|
|
|
|
Allow user management where safe:
|
|
|
|
- create
|
|
- rename
|
|
- archive
|
|
- icon
|
|
- color
|
|
|
|
Do not break existing category records.
|
|
|
|
============================================================
|
|
9. ITEMS
|
|
============================================================
|
|
|
|
Preserve existing transaction item functionality.
|
|
|
|
Example:
|
|
|
|
Grocery ₹1,250
|
|
|
|
Rice ₹500
|
|
Vegetables ₹300
|
|
Snacks ₹250
|
|
Other ₹200
|
|
|
|
Display:
|
|
|
|
- item name
|
|
- quantity if supported
|
|
- price
|
|
- total
|
|
|
|
Transaction total should be validated against item totals where appropriate.
|
|
|
|
============================================================
|
|
10. BUDGETING
|
|
============================================================
|
|
|
|
Add budgeting functionality.
|
|
|
|
Support:
|
|
|
|
- monthly budgets
|
|
- category budgets
|
|
- wallet-specific budgets
|
|
|
|
Show:
|
|
|
|
Allocated
|
|
Spent
|
|
Remaining
|
|
Percentage used
|
|
|
|
Provide warning levels.
|
|
|
|
Examples:
|
|
|
|
70% → informational
|
|
90% → warning
|
|
100%+ → exceeded
|
|
|
|
Make thresholds configurable if appropriate.
|
|
|
|
============================================================
|
|
11. REPORTS / ANALYTICS
|
|
============================================================
|
|
|
|
Provide understandable financial analytics.
|
|
|
|
Charts:
|
|
|
|
- income vs expenses
|
|
- spending by category
|
|
- cash flow
|
|
- savings trend
|
|
- investment trend
|
|
- wallet distribution
|
|
- top spending categories
|
|
- monthly comparison
|
|
- recurring expenses
|
|
|
|
Charts must be mobile friendly.
|
|
|
|
Avoid excessive complexity.
|
|
|
|
============================================================
|
|
12. SEARCH / FILTER
|
|
============================================================
|
|
|
|
Provide powerful transaction filtering.
|
|
|
|
Filters:
|
|
|
|
- date
|
|
- wallet
|
|
- category
|
|
- nature
|
|
- amount
|
|
- income/expense
|
|
- attachment
|
|
- item
|
|
- text search
|
|
|
|
Make filtering easy for non-technical users.
|
|
|
|
============================================================
|
|
13. RECURRING TRANSACTIONS
|
|
============================================================
|
|
|
|
If compatible with the existing architecture, support:
|
|
|
|
- salary
|
|
- rent
|
|
- EMI
|
|
- subscriptions
|
|
- insurance
|
|
- SIP
|
|
- recurring bills
|
|
|
|
Fields:
|
|
|
|
- frequency
|
|
- start date
|
|
- end date
|
|
- next occurrence
|
|
- active/inactive
|
|
|
|
Do not over-engineer this if it conflicts heavily with the current architecture.
|
|
|
|
============================================================
|
|
14. ALERTS / NOTIFICATIONS
|
|
============================================================
|
|
|
|
Useful alerts:
|
|
|
|
- budget nearing limit
|
|
- budget exceeded
|
|
- upcoming recurring payment
|
|
- loan due
|
|
- lending due
|
|
- unusual spending
|
|
- failed upload
|
|
- wallet activity
|
|
|
|
Allow notification preferences.
|
|
|
|
============================================================
|
|
15. USER EDUCATION
|
|
============================================================
|
|
|
|
The application must teach users how to use it.
|
|
|
|
Provide:
|
|
|
|
- onboarding
|
|
- contextual hints
|
|
- tooltips
|
|
- "What is this?" explanations
|
|
- guided tours
|
|
- contextual help
|
|
- examples
|
|
|
|
Example:
|
|
|
|
"From Wallet"
|
|
Where the money comes from.
|
|
|
|
"To Wallet"
|
|
Where the money goes.
|
|
|
|
"Nature"
|
|
How the app categorizes this money movement.
|
|
|
|
Users should be able to:
|
|
|
|
- skip
|
|
- replay
|
|
- disable hints
|
|
|
|
Do not make onboarding annoying.
|
|
|
|
============================================================
|
|
16. UI / UX
|
|
============================================================
|
|
|
|
Create a polished modern financial application.
|
|
|
|
Requirements:
|
|
|
|
- modern Flutter UI
|
|
- responsive design
|
|
- light theme
|
|
- dark theme
|
|
- customizable icons
|
|
- meaningful icons
|
|
- smooth animations
|
|
- animated dashboard cards
|
|
- page transitions
|
|
- bottom sheets
|
|
- dialogs
|
|
- snackbars
|
|
- loading states
|
|
- skeleton loaders
|
|
- empty states
|
|
- error states
|
|
- confirmation dialogs
|
|
- pull-to-refresh
|
|
- swipe actions where appropriate
|
|
- floating Add button
|
|
|
|
Suggested navigation:
|
|
|
|
Dashboard
|
|
Wallets
|
|
Transactions
|
|
Budgets
|
|
Reports
|
|
Profile
|
|
|
|
BUT:
|
|
|
|
Do not force this navigation if the existing application's navigation architecture is better.
|
|
|
|
Reuse existing navigation where practical.
|
|
|
|
============================================================
|
|
17. PROFILE / SECURITY
|
|
============================================================
|
|
|
|
Preserve existing authentication.
|
|
|
|
Improve where appropriate.
|
|
|
|
Possible features:
|
|
|
|
- profile
|
|
- password/security
|
|
- PIN
|
|
- biometric lock
|
|
- logout
|
|
- notification settings
|
|
- currency
|
|
- theme
|
|
- privacy
|
|
- data export
|
|
- account deletion
|
|
|
|
Never expose another user's financial information.
|
|
|
|
============================================================
|
|
18. FINANCIAL DATA MODEL
|
|
============================================================
|
|
|
|
This is CRITICAL.
|
|
|
|
Design a consistent transaction model.
|
|
|
|
Every transaction should have:
|
|
|
|
- id
|
|
- user/owner context
|
|
- amount
|
|
- fromWallet
|
|
- toWallet
|
|
- timestamp
|
|
- category
|
|
- description
|
|
- items
|
|
- attachments
|
|
- metadata
|
|
|
|
Wallet balance must be deterministic.
|
|
|
|
Avoid duplicated balance calculations.
|
|
|
|
Do not use floating point for money.
|
|
|
|
Backend:
|
|
Use Java BigDecimal.
|
|
|
|
Flutter:
|
|
Use a safe monetary representation appropriate for the existing architecture.
|
|
|
|
Use database transactions for financial operations.
|
|
|
|
Ensure edits/deletes correctly update financial calculations.
|
|
|
|
============================================================
|
|
19. NEGATIVE AMOUNTS
|
|
============================================================
|
|
|
|
Negative values are explicitly allowed.
|
|
|
|
Define and document exactly how negative transactions affect:
|
|
|
|
- from wallet
|
|
- to wallet
|
|
- wallet balance
|
|
- income
|
|
- expense
|
|
- reports
|
|
- budgets
|
|
|
|
Do not let different parts of the application interpret negative amounts differently.
|
|
|
|
The backend is the source of truth.
|
|
|
|
============================================================
|
|
20. BACKEND
|
|
============================================================
|
|
|
|
Inspect the existing Spring Boot architecture first.
|
|
|
|
Reuse:
|
|
|
|
- controllers
|
|
- services
|
|
- repositories
|
|
- DTOs
|
|
- entities
|
|
- authentication
|
|
- exception handling
|
|
- migrations
|
|
|
|
Extend existing APIs rather than creating duplicates.
|
|
|
|
Use:
|
|
|
|
- DTO validation
|
|
- service-layer business logic
|
|
- transaction boundaries
|
|
- authorization
|
|
- consistent API errors
|
|
|
|
Financial business rules belong on the backend.
|
|
|
|
Never rely exclusively on Flutter validation.
|
|
|
|
============================================================
|
|
21. DATABASE
|
|
============================================================
|
|
|
|
Before modifying entities:
|
|
|
|
1. Understand existing schema.
|
|
2. Understand existing data.
|
|
3. Preserve existing records.
|
|
4. Create migrations.
|
|
5. Avoid destructive migrations.
|
|
6. Provide defaults for old records.
|
|
7. Maintain backward compatibility where practical.
|
|
|
|
Never silently delete user financial data.
|
|
|
|
============================================================
|
|
22. FLUTTER ARCHITECTURE
|
|
============================================================
|
|
|
|
Inspect the current Flutter architecture first.
|
|
|
|
Preserve existing:
|
|
|
|
- state management
|
|
- routing
|
|
- API client
|
|
- repository pattern
|
|
- dependency injection
|
|
- theme
|
|
- widgets
|
|
|
|
Do NOT replace state management just because another solution is preferred.
|
|
|
|
Create reusable:
|
|
|
|
- wallet widgets
|
|
- transaction widgets
|
|
- dashboard cards
|
|
- ledger rows
|
|
- filters
|
|
- forms
|
|
- dialogs
|
|
- charts
|
|
- attachment components
|
|
|
|
Maintain iOS/Android parity.
|
|
|
|
============================================================
|
|
23. TESTING
|
|
============================================================
|
|
|
|
Backend tests:
|
|
|
|
- unit tests
|
|
- service tests
|
|
- controller tests
|
|
- authorization tests
|
|
- transaction tests
|
|
- balance tests
|
|
|
|
Flutter tests:
|
|
|
|
- widget tests
|
|
- transaction form tests
|
|
- wallet tests
|
|
- balance tests
|
|
- dashboard tests
|
|
- attachment tests
|
|
|
|
Critical scenarios:
|
|
|
|
1. Create wallet
|
|
2. Create income
|
|
3. Create expense
|
|
4. Transfer money
|
|
5. Negative transaction
|
|
6. Edit transaction
|
|
7. Delete transaction
|
|
8. Upload attachment
|
|
9. Replace attachment
|
|
10. Shared wallet
|
|
11. Budget calculation
|
|
12. Dashboard totals
|
|
13. Ledger running balance
|
|
14. Unauthorized wallet access
|
|
|
|
============================================================
|
|
24. PERFORMANCE
|
|
============================================================
|
|
|
|
The application should remain responsive with large transaction histories.
|
|
|
|
Consider:
|
|
|
|
- pagination
|
|
- lazy loading
|
|
- database indexes
|
|
- optimized queries
|
|
- cached dashboard summaries
|
|
- debounced search
|
|
- image compression
|
|
- thumbnail generation
|
|
- background upload
|
|
- efficient chart data
|
|
|
|
Do not optimize prematurely.
|
|
|
|
Measure first where possible.
|
|
|
|
============================================================
|
|
25. ACCESSIBILITY
|
|
============================================================
|
|
|
|
Support:
|
|
|
|
- readable typography
|
|
- sufficient contrast
|
|
- semantic labels
|
|
- screen-reader friendly controls
|
|
- touch-friendly controls
|
|
- scalable text where practical
|
|
|
|
Do not rely only on color to communicate financial status.
|
|
|
|
============================================================
|
|
26. IMPLEMENTATION PHASES
|
|
============================================================
|
|
|
|
Do NOT implement everything in one giant change.
|
|
|
|
PHASE 1:
|
|
Repository analysis
|
|
Architecture understanding
|
|
Data model analysis
|
|
Existing functionality inventory
|
|
Implementation plan
|
|
|
|
PHASE 2:
|
|
Wallet/account model
|
|
Transaction model
|
|
Balance calculation
|
|
Create/edit transaction
|
|
|
|
PHASE 3:
|
|
Dashboard
|
|
Ledger
|
|
Search
|
|
Filters
|
|
|
|
PHASE 4:
|
|
Attachments
|
|
Items
|
|
Categories
|
|
Wallet sharing
|
|
|
|
PHASE 5:
|
|
Budgets
|
|
Reports
|
|
Analytics
|
|
Recurring transactions
|
|
|
|
PHASE 6:
|
|
Notifications
|
|
Onboarding
|
|
Guided tours
|
|
Profile/security
|
|
|
|
PHASE 7:
|
|
UI polish
|
|
Animations
|
|
Accessibility
|
|
Performance
|
|
Testing
|
|
iOS/Android validation
|
|
|
|
After every phase:
|
|
|
|
- build backend
|
|
- run backend tests
|
|
- run Flutter analyzer
|
|
- run Flutter tests
|
|
- fix compilation errors
|
|
- fix test failures
|
|
- verify affected functionality
|
|
|
|
============================================================
|
|
27. CODE QUALITY RULES
|
|
============================================================
|
|
|
|
Follow existing project conventions.
|
|
|
|
Prefer small, maintainable changes.
|
|
|
|
Avoid unnecessary abstractions.
|
|
|
|
Avoid duplicate models/services.
|
|
|
|
Avoid dead code.
|
|
|
|
Avoid magic constants.
|
|
|
|
Use meaningful names.
|
|
|
|
Document complicated financial business rules.
|
|
|
|
Do not hide errors.
|
|
|
|
Do not suppress compiler warnings simply to make builds pass.
|
|
|
|
Do not disable tests.
|
|
|
|
Do not remove tests to make the implementation pass.
|
|
|
|
============================================================
|
|
28. GIT / CHANGE SAFETY
|
|
============================================================
|
|
|
|
Before major modifications:
|
|
|
|
Inspect git status.
|
|
|
|
Do not overwrite unrelated user changes.
|
|
|
|
Do not reset/revert user work.
|
|
|
|
Do not delete files unless you have established they are obsolete.
|
|
|
|
Keep changes logically grouped.
|
|
|
|
============================================================
|
|
29. IMPORTANT AGENT BEHAVIOR
|
|
============================================================
|
|
|
|
When uncertain:
|
|
|
|
1. Inspect the code.
|
|
2. Search for existing implementation.
|
|
3. Follow existing conventions.
|
|
4. Make the smallest safe change.
|
|
|
|
Do not guess the architecture.
|
|
|
|
Do not assume an API exists.
|
|
|
|
Do not create duplicate functionality.
|
|
|
|
Do not rewrite working modules unnecessarily.
|
|
|
|
If a requirement conflicts with existing behavior, explain the conflict before making a destructive architectural change.
|
|
|
|
============================================================
|
|
30. FIRST RESPONSE / FIRST ACTION
|
|
============================================================
|
|
|
|
DO NOT IMPLEMENT FEATURES YET.
|
|
|
|
First inspect the repository.
|
|
|
|
Then report:
|
|
|
|
A. Current architecture
|
|
B. Flutter architecture
|
|
C. Spring Boot architecture
|
|
D. Current database model
|
|
E. Current account/wallet model
|
|
F. Current transaction workflow
|
|
G. Current dashboard
|
|
H. Current attachment implementation
|
|
I. Current wallet sharing implementation
|
|
J. Existing reusable functionality
|
|
K. Existing bugs/problems
|
|
L. Proposed target architecture
|
|
M. Database migration strategy
|
|
N. API changes required
|
|
O. Flutter screens/components required
|
|
P. Implementation phases
|
|
|
|
Then begin PHASE 1.
|
|
|
|
Do not proceed with a massive rewrite.
|
|
|
|
Implement incrementally and verify every phase. |