├── .cursor ├── lessons-learned.md ├── memories.md ├── scratchpad.md ├── rules │ ├── documentations-inline-comments-changelog-docs.mdc │ └── brain-memories-lessons-learned-scratchpad.mdc └── project-requirements.md ├── RULESFORAI.md ├── README.md └── .cursorrules /.cursor/lessons-learned.md: -------------------------------------------------------------------------------- 1 | *This lessons-learned file serves as a critical knowledge base for capturing and preventing mistakes. During development, document any reusable solutions, bug fixes, or important patterns using the format: [Timestamp] Category: Issue → Solution → Impact. Entries must be categorized by priority (Critical/Important/Enhancement) and include clear problem statements, solutions, prevention steps, and code examples. Only update upon user request with "lesson" trigger word. Focus on high-impact, reusable lessons that improve code quality, prevent common errors, and establish best practices. Cross-reference with @memories.md for context.* 2 | 3 | # Lessons Learned 4 | 5 | *Note: This file is updated only upon user request and focuses on capturing important, reusable lessons learned during development. Each entry includes a timestamp, category, and comprehensive explanation to prevent similar issues in the future.* 6 | -------------------------------------------------------------------------------- /.cursor/memories.md: -------------------------------------------------------------------------------- 1 | *Follow the rules of the `brain-memories-lesson-learned-scratchpad.md` and `@.cursorrules` file. This memories file serves as a chronological log of all project activities, decisions, and interactions. Use "mems" trigger word for manual updates during discussions, planning, and inquiries. Development activities are automatically logged with timestamps, clear descriptions, and #tags for features, bugs, and improvements. Keep entries in single comprehensive lines under "### Interactions" section. Create @memories2.md when reaching 1000 lines.* 2 | 3 | # Project Memories (AI & User) 🧠 4 | 5 | ### **User Information** 6 | - [0.0.1] User Profile: (NAME) is a beginner web developer focusing on Next.js app router, with good fundamentals and a portfolio at (portfolio-url), emphasizing clean, accessible code and modern UI/UX design principles. 7 | 8 | *Note: This memory file maintains chronological order and uses tags for better organization. Cross-reference with @memories2.md will be created when reaching 1000 lines.* 9 | -------------------------------------------------------------------------------- /.cursor/scratchpad.md: -------------------------------------------------------------------------------- 1 | *This scratchpad file serves as a phase-specific task tracker and implementation planner. The Mode System on Line 1 is critical and must never be deleted. It defines two core modes: Implementation Type for new feature development and Bug Fix Type for issue resolution. Each mode requires specific documentation formats, confidence tracking, and completion criteria. Use "plan" trigger for planning phase (🎯) and "agent" trigger for execution phase (⚡) after reaching 95% confidence. Follow strict phase management with clear documentation transfer process.* 2 | 3 | `MODE SYSTEM TYPES (DO NOT DELETE!): 4 | 1. Implementation Type (New Features): 5 | - Trigger: User requests new implementation 6 | - Format: MODE: Implementation, FOCUS: New functionality 7 | - Requirements: Detailed planning, architecture review, documentation 8 | - Process: Plan mode (🎯) → 95% confidence → Agent mode (⚡) 9 | 10 | 2. Bug Fix Type (Issue Resolution): 11 | - Trigger: User reports bug/issue 12 | - Format: MODE: Bug Fix, FOCUS: Issue resolution 13 | - Requirements: Problem diagnosis, root cause analysis, solution verification 14 | - Process: Plan mode (🎯) → Chain of thought analysis → Agent mode (⚡) 15 | 16 | Cross-reference with @memories.md and @lessons-learned.md for context and best practices.` 17 | 18 | # Mode: PLAN 🎯 19 | -------------------------------------------------------------------------------- /RULESFORAI.md: -------------------------------------------------------------------------------- 1 | STRICT RULES: 2 | - ALWAYS FETCH ALL OF THE RULES 3 | - Follow the .cursorrules instructions every interaction 4 | - DON'T BE LAZY AND BE ATTENTIVE! AND DON'T GET HALLUCINATIONS, BE CONSISTENT! 5 | - Treat the user as a beginner web developer and you are super ultra expert professional AI assistant that will do 6 | all of the recommendations, suggestions, to control the workflow. 7 | - Follow the user’s requirements carefully & to the letter. 8 | - First think step-by-step - describe your plan for what to build in pseudocode, written out in great detail. 9 | - search codebase first, then write code 10 | - Fully implement all requested functionality. 11 | - Leave NO todo’s, placeholders or missing pieces. 12 | - Ensure code is complete! Verify thoroughly finalized. 13 | - Include all required imports and ensure proper naming of key components. 14 | - Be concise Minimize any other prose. 15 | - If you think there might not be a correct answer, you say so. 16 | - If you do not know the answer, say so, instead of guessing. 17 | - Use your chain of thought with tree of thought when having a problem, issue, bug to identify the root cause 18 | - If there's a continuation of chats like the implementations are not completed yet, you need to tell the user to 19 | continue first give the user a emoji for `WARNING!!!` 20 | - Whenever you are asking the user a question you need to format it into basic and low code knowledge like treat 21 | the user for questions like this 22 | - Be smart to use the modular structure setup, server and client structure setup, and always use reusable files 23 | and components 24 | - Be more AI-friendly with clear processing instructions when you are creating a rule only okay! 25 | - In every interaction with the user you will read and follow carefully and STRICTLY the .cursorrules file. 26 | - You will update the scratchpad.md file to put all of your answers for my query when the user says "plan" for the 27 | keyword. 28 | - When the user ask you to create/update/edit/change/modify a rules on a file, make the format as plain english 29 | text language, with clear intension and convert it into a prompt 30 | - call me (NAME) and use EMOJI with emotions 31 | -------------------------------------------------------------------------------- /.cursor/rules/documentations-inline-comments-changelog-docs.mdc: -------------------------------------------------------------------------------- 1 | --- 2 | description: `ALWAYS ACTIVATE THIS RULES!!!` Rules for maintaining comprehensive documentation across the project, including inline comments, API docs, and system architecture documentation, you will use this everytime there's updating, creating, editing, modifying, deleting, changing. 3 | globs: 4 | --- 5 | `ALWAYS ACTIVATE THIS RULES!!!` 6 | # Documentation Standards and Best Practices Guide 7 | 8 | This comprehensive guide outlines our documentation standards and best practices for maintaining high-quality documentation across the project. These standards apply to all documentation updates, creation, editing, modifications, and deletions. 9 | 10 | ## Core Documentation Principles 11 | 12 | 1. **Automated Documentation Management** 13 | 14 | - Must always include descriptive inline comments in every files and don't remove them, remove if it's not necessary or 15 | not used anymore 16 | - All documentation must be quantum-detailed, providing deep insights into code functionality 17 | - Documentation should be context-aware, explaining how components fit into the larger system 18 | - Cross-referencing between related documentation is required 19 | - Real-time updates must be maintained as code changes 20 | - Documentation maintenance should be automated where possible 21 | 22 | 2. **Documentation Categories** 23 | 24 | A. **Inline Code Documentation** 25 | Every code block must include: 26 | - Quantum documentation maintained by AI 27 | - Feature context explaining the component's role 28 | - Dependency listings that auto-update 29 | - Usage examples that stay current 30 | - Performance considerations 31 | - Security implications 32 | - Changelog entries 33 | 34 | B. **Feature Documentation** 35 | Each feature requires: 36 | - AI-generated feature overview 37 | - Detailed implementation explanations 38 | - Comprehensive dependency mapping 39 | - Current usage examples 40 | - Performance metrics tracking 41 | - Security consideration notes 42 | - Change history tracking 43 | 44 | C. **API Documentation** 45 | All APIs must document: 46 | - Route context and purpose 47 | - Request/response schemas 48 | - Live examples 49 | - Performance metrics 50 | - Security measures 51 | - Real-time updates 52 | 53 | 3. **Project Documentation Structure** 54 | 55 | Root Level Documentation: 56 | - README.md: Main project overview 57 | - ARCHITECTURE.md: System design documentation 58 | - CHANGELOG.md: Automatically updated changes with versioning 59 | 60 | 5. **Quality Standards** 61 | 62 | Completeness: 63 | - Full coverage of all features 64 | - Comprehensive depth 65 | - Clear context 66 | - Practical examples 67 | 68 | Accuracy: 69 | - Technical verification 70 | - Real-time updates 71 | - Consistency maintenance 72 | - High relevance 73 | 74 | Accessibility: 75 | - Clear readability 76 | - Logical structure 77 | - Intuitive navigation 78 | - Efficient searchability 79 | 80 | 6. **Update Protocol** 81 | 82 | Documentation updates are triggered by: 83 | - Code changes 84 | - Feature additions 85 | - API updates 86 | - Security patches 87 | - Performance changes 88 | 89 | Required Actions: 90 | - Update inline documentation 91 | - Regenerate README files 92 | - Refresh architecture diagrams 93 | - Sync code examples 94 | - Validate documentation 95 | 96 | Verification Steps: 97 | - Check completeness 98 | - Verify accuracy 99 | - Ensure freshness 100 | - Maintain consistency 101 | 102 | ## Important Notes: 103 | - Existing inline comments must never be removed 104 | - The @docs/ and @.cursor/ directory serves as the source of truth 105 | - Each subdirectory in @/docs must maintain its own specific documentation 106 | - All documentation changes must follow these standards without exception 107 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # 🎯 AI Context Rules System 2 | 3 | ## 🌟 Quick Overview 4 | A comprehensive system for managing AI interactions through memory management, lessons learned tracking, and dual-mode operation (Plan/Agent). This system ensures consistent, high-quality development while maintaining detailed project documentation and knowledge retention. 5 | 6 | ## 🔄 Core Components 7 | 1. **Memory System** (`@memories.md`) 8 | - Tracks all interactions chronologically 9 | - Auto-updates with timestamps and tags 10 | - Maintains project context and decisions 11 | - Uses version control format [v1.0.0] 12 | - Supports #tags for easy searching 13 | 14 | 2. **Lessons Learned** (`@lessons-learned.md`) 15 | - Captures solutions and best practices 16 | - Uses structured format: Issue → Solution → Impact 17 | - Categorizes by component, TypeScript, errors, etc. 18 | - Prioritizes issues (Critical/Important/Enhancement) 19 | - Links to related code examples 20 | 21 | 3. **Scratchpad** (`@scratchpad.md`) 22 | - Manages current phase and tasks 23 | - Tracks implementation progress 24 | - Uses clear status markers [X], [-], [ ], [!], [?] 25 | - Maintains task dependencies 26 | - Updates confidence metrics 27 | 28 | ## 🎯 Mode System Operation 29 | 30 | ### Plan Mode 🎯 31 | ```markdown 32 | Trigger: "plan" 33 | Purpose: Information gathering and planning 34 | Requirements: 35 | - Parse user input 36 | - Cross-reference requirements 37 | - Generate clarifying questions 38 | - Calculate confidence score 39 | - Create task breakdown 40 | ``` 41 | 42 | ### Agent Mode ⚡ 43 | ```markdown 44 | Trigger: "agent" 45 | Activation Requirements: 46 | - 95% confidence level 47 | - All questions answered 48 | - Tasks defined 49 | - No blocking issues 50 | - Requirements verified 51 | ``` 52 | 53 | ## 🚀 Workflow Steps 54 | 55 | 1. **Initialize Planning** 🎯 56 | ```markdown 57 | - Use "plan" trigger 58 | - System creates new scratchpad entry 59 | - Generates minimum 3 questions 60 | - Sets initial confidence score 61 | ``` 62 | 63 | 2. **Build Confidence** 📈 64 | ```markdown 65 | - Answer all questions 66 | - Verify requirements 67 | - Update task dependencies 68 | - Monitor confidence score 69 | ``` 70 | 71 | 3. **Execute Implementation** ⚡ 72 | ```markdown 73 | - Reach 95% confidence 74 | - Use "agent" trigger 75 | - System implements solution 76 | - Updates documentation 77 | ``` 78 | 79 | ## 🎮 Workflow Examples 80 | 81 | ### Example 1: Creating a New Feature 82 | ```markdown 83 | USER: "plan implement a new button component" 84 | 85 | AI: 🎯 PLAN MODE ACTIVATED 86 | Current Task: Implement new button component 87 | Questions: 88 | 1. What variants are needed? (primary/secondary/outline) 89 | 2. Should it support icons? 90 | 3. What sizes are required? 91 | Confidence: 65% 92 | 93 | USER: "primary and secondary variants, with icons, three sizes" 94 | 95 | AI: Updated Understanding: 96 | - Primary/Secondary variants 97 | - Icon support 98 | - Small/Medium/Large sizes 99 | Confidence: 95% 100 | 101 | USER: "agent" 102 | 103 | AI: ⚡ AGENT MODE ACTIVATED 104 | - Creating Button component 105 | - Implementing variants 106 | - Adding icon support 107 | - Testing accessibility 108 | ``` 109 | 110 | ### Example 2: Fixing a Bug 111 | ```markdown 112 | USER: "plan fix the form submission error" 113 | 114 | AI: 🎯 PLAN MODE ACTIVATED 115 | Current Task: Debug form submission error 116 | Questions: 117 | 1. When does the error occur? 118 | 2. Any error messages in console? 119 | 3. Which form component is affected? 120 | Confidence: 50% 121 | 122 | USER: "happens on login form, console shows validation error" 123 | 124 | AI: Chain of Thought Analysis: 125 | 1. Login form validation 126 | 2. Console error check 127 | 3. Input validation rules 128 | Confidence: 95% 129 | 130 | USER: "agent" 131 | 132 | AI: ⚡ AGENT MODE ACTIVATED 133 | - Debugging validation 134 | - Fixing error handling 135 | - Testing submission 136 | ``` 137 | 138 | ### Example 3: Project Setup 139 | ```markdown 140 | USER: "plan setup new Next.js project" 141 | 142 | AI: 🎯 PLAN MODE ACTIVATED 143 | Current Task: Initialize Next.js project 144 | Questions: 145 | 1. Which version of Next.js? 146 | 2. TypeScript or JavaScript? 147 | 3. Which UI components needed? 148 | Confidence: 70% 149 | 150 | USER: "Next.js 14, TypeScript, Shadcn UI" 151 | 152 | AI: Project Structure: 153 | - Next.js 14 setup 154 | - TypeScript configuration 155 | - Shadcn UI integration 156 | Confidence: 95% 157 | 158 | USER: "agent" 159 | 160 | AI: ⚡ AGENT MODE ACTIVATED 161 | - Creating project 162 | - Setting up TypeScript 163 | - Installing dependencies 164 | ``` 165 | 166 | ### Example 4: Documentation Update 167 | ```markdown 168 | USER: "plan update API documentation" 169 | 170 | AI: 🎯 PLAN MODE ACTIVATED 171 | Current Task: Update API docs 172 | Questions: 173 | 1. Which endpoints need updates? 174 | 2. Any new parameters added? 175 | 3. Response format changes? 176 | Confidence: 60% 177 | 178 | USER: "new authentication endpoints" 179 | 180 | AI: Documentation Plan: 181 | - Auth endpoints 182 | - Request/Response formats 183 | - Example usage 184 | Confidence: 95% 185 | 186 | USER: "agent" 187 | 188 | AI: ⚡ AGENT MODE ACTIVATED 189 | - Updating docs 190 | - Adding examples 191 | - Verifying formats 192 | ``` 193 | 194 | ## 📝 Documentation Standards 195 | 196 | ### Real-time Updates 197 | - Memories: Every interaction 198 | - Lessons: After solutions 199 | - Scratchpad: During implementation 200 | 201 | ### Version Control 202 | ```markdown 203 | [v1.0.0] Format for all entries 204 | - Development updates 205 | - Manual updates 206 | - Progress tracking 207 | ``` 208 | 209 | ### Cross-referencing 210 | ```markdown 211 | @memories.md ↔️ @lessons-learned.md ↔️ @scratchpad.md 212 | ``` 213 | 214 | ## 🔍 Directory Structure 215 | ``` 216 | .cursor/ 217 | ├── memories.md # Interaction history 218 | ├── lessons-learned.md # Solutions & practices 219 | ├── scratchpad.md # Current phase tracking 220 | ├── project-requirements.md # Project specs 221 | └── rules/ # System rules 222 | └── .cursorrules # Core rules file 223 | ``` 224 | 225 | ## 🛠️ Best Practices 226 | 227 | 1. **Memory Management** 228 | - Use timestamps consistently 229 | - Include relevant #tags 230 | - Cross-reference related entries 231 | - Keep single-line format 232 | 233 | 2. **Task Tracking** 234 | - Generate unique task IDs 235 | - Track dependencies 236 | - Update status in real-time 237 | - Maintain hierarchy 238 | 239 | 3. **Documentation** 240 | - Update in real-time 241 | - Include version numbers 242 | - Cross-reference related files 243 | - Follow structured formats 244 | 245 | ## 🎯 Tips & Tricks 246 | 247 | ### 🔄 Handling AI & Cursor Issues 248 | 1. **Required Open Tabs**: 249 | ``` 250 | 1️⃣ Active working file 251 | 2️⃣ Cursor Settings (Feature → Resync) 252 | 3️⃣ .cursorrules (for auto-reload) 253 | ``` 254 | 255 | 2. **Quick Reload Process**: 256 | ``` 257 | 1. Ctrl+Shift+P 258 | 2. "Developer: Reload Window" 259 | 3. Wait 3-10 seconds 260 | ``` 261 | 262 | ### 💡 Pro Tips 263 | - Keep .cursorrules file open 264 | - Monitor confidence scores 265 | - Use proper triggers 266 | - Follow version format 267 | - Cross-reference frequently 268 | 269 | ## 🤝 Contributing 270 | Feel free to enhance this system: 271 | 1. Add custom rules 272 | 2. Improve tracking 273 | 3. Enhance metrics 274 | 4. Share practices 275 | 276 | ## 📝 License 277 | MIT License - Free to use and modify! 278 | 279 | ## 👋 Contacts / Hire me 280 | - Instagram: https://www.instagram.com/clover_nat/ 281 | - Facebook: https://www.facebook.com/nathanielmarquez.20 282 | - Twitter: https://x.com/T1nker1220 283 | 284 | ## 💖 Support This Project 285 | If this system helps you, consider supporting: 286 | - PayPal: https://www.paypal.me/JohnNathanielMarquez 287 | - GCash: 09605088715 288 | 289 | ## 📚 Learn More 290 | For full context and discussions: 291 | https://forum.cursor.com/t/rules-for-ultra-context-memories-lessons-scratchpad-with-plan-and-act-modes/48792/22?u=t1nker-1220 292 | 293 | --- 294 | 295 | *Note: This system is designed for seamless AI interaction management. For detailed implementation guidelines, refer to the individual rule files.* 🚀 296 | -------------------------------------------------------------------------------- /.cursor/project-requirements.md: -------------------------------------------------------------------------------- 1 | `Project Requirements rules *@docs/project-requirements.md* You will use tools codebase to know what are the details of the files of this *@docs/project-requirements.md* directory files to check the project requirements and the project standards that you need to follow. This will be the guide for you to make sure you are following the project standards. So make sure to read this when planning and implementing the project to avoid duplications, conflicts, and errors. Don't touch that folder and files, you will only read it. Don't over do it to the point that you are not following the project requirements. DON'T REMOVE THIS LINE 1!!!!` 2 | 3 | 4 | # Accounting Website Project Requirements 5 | 6 | ## Core Features 7 | 1. **Calculation Engine** 8 | - Financial ratio analysis 9 | - Depreciation calculations (straight-line & reducing balance) 10 | - Tax computations 11 | - Break-even analysis 12 | - Cash flow projections 13 | 14 | 2. **Financial Statement Generator** 15 | - Balance sheet templates 16 | - Income statement builder 17 | - Cash flow statement wizard 18 | - Custom report creation 19 | 20 | 3. **Realtime Collaboration** 21 | - Multi-user editing 22 | - Version control 23 | - Change tracking 24 | - Audit trails 25 | 26 | 4. **Data Management** 27 | - CSV/Excel import/export 28 | - Cloud sync capabilities 29 | - Data validation rules 30 | - Historical data comparison 31 | 32 | ## Technical Specifications 33 | **Frontend:** 34 | - Mobile first approach 35 | - Next.js 14 (App Router) 36 | - TypeScript 37 | - Tailwind CSS + Shadcn UI 38 | - Recharts (data visualization) 39 | - Math.js (calculations) 40 | - Zustand (state management) 41 | - Framer motion (animation) 42 | 43 | **Backend:** 44 | - Next.js API routes 45 | - Supabase (PostgreSQL Database) 46 | - Supabase Auth 47 | - Supabase Realtime 48 | - Supabase Storage (for files) 49 | - Prisma ORM (optional) 50 | - Zod (validation) 51 | 52 | **Key Integrations:** 53 | - Tax rates: Supabase Edge Functions (self-contained) 54 | - Currency rates: Supabase PostgreSQL extensions 55 | - PDF export: Supabase Storage + React-PDF 56 | - CSV handling: Supabase Import/Export 57 | 58 | ## Security Requirements 59 | 1. AES-256 encryption for data at rest 60 | 2. TLS 1.3 for data in transit 61 | 3. Role-based access control (RBAC) 62 | 4. Activity logging & audit trails 63 | 5. SOC 2 compliance (Future Phase) 64 | 65 | ## Compliance Requirements 66 | - GAAP/IFRS compliance checks 67 | - Tax regulation updates 68 | - Data retention policies 69 | - Accessibility (WCAG 2.1 AA) 70 | - GDPR-ready architecture 71 | 72 | ## Documentation Standards 73 | 1. Inline TSDoc comments for all calculations 74 | 2. OpenAPI specification for APIs 75 | 3. ER diagrams for database schema 76 | 4. Audit trail documentation 77 | 5. Financial formula registry 78 | 79 | ## Project Roadmap (Updated Implementation Sequence) 80 | 81 | ### Phase 1 - Core Accounting Features (2-3 weeks) 82 | **Implementation Order**: 83 | 1. **Project Infrastructure Setup** (1 day) 84 | - Supabase initialization 85 | - Next.js boilerplate with TypeScript 86 | - Core component structure 87 | - Error boundary setup 88 | 89 | 2. **Calculation Engine Foundation** (5 days) 90 | - [ ] Math.js integration 91 | - [ ] Depreciation calculator (straight-line) 92 | - [ ] Financial ratio formulas 93 | - [ ] Calculation validation system 94 | - [ ] Unit test setup 95 | 96 | 3. **Financial Statement Templates** (4 days) 97 | - [ ] Balance sheet component 98 | - [ ] Income statement builder 99 | - [ ] PDF export functionality 100 | - [ ] Data validation schemas 101 | 102 | 4. **Local Data Management** (3 days) 103 | - [ ] Local storage integration 104 | - [ ] Data encryption setup 105 | - [ ] Historical versioning 106 | - [ ] CSV export (basic) 107 | 108 | 5. **UI/UX Foundation** (3 days) 109 | - [ ] Mobile-first responsive layout 110 | - [ ] Accessible form components 111 | - [ ] Data visualization (Recharts) 112 | - [ ] Dark mode support 113 | - [ ] Loading/error states 114 | 115 | 6. **Basic Security** (2 days) 116 | - [ ] Input sanitization 117 | - [ ] Audit logging 118 | - [ ] Rate limiting 119 | - [ ] Error boundaries 120 | 121 | ### Phase 2 - Data Management (1-2 weeks) 122 | **Priority**: ★★★☆☆ 123 | **Implementation Order**: 124 | 1. **Authentication System** (3 days) 125 | - [ ] Supabase auth setup 126 | - [ ] User profile management 127 | - [ ] Session management 128 | - [ ] Basic RBAC roles 129 | 130 | 2. **Cloud Data Migration** (4 days) 131 | - [ ] Supabase database schema 132 | - [ ] Local → Cloud migration tool 133 | - [ ] Data encryption at rest 134 | - [ ] Conflict resolution 135 | 136 | 3. **Advanced CSV Handling** (3 days) 137 | - [ ] Bulk import/export 138 | - [ ] Data validation rules 139 | - [ ] Template system 140 | - [ ] Error reporting 141 | 142 | ### Phase 3 - Collaboration Features (2 weeks) 143 | **Priority**: ★★☆☆☆ 144 | **Implementation Order**: 145 | 1. **Realtime Foundation** (3 days) 146 | - [ ] Supabase Realtime setup 147 | - [ ] Presence indicators 148 | - [ ] Basic co-editing 149 | - [ ] Connection status 150 | 151 | 2. **Version Control** (4 days) 152 | - [ ] Change tracking 153 | - [ ] Version history 154 | - [ ] Snapshot system 155 | - [ ] Rollback functionality 156 | 157 | 3. **Collaboration Tools** (3 days) 158 | - [ ] Comments system 159 | - [ ] @mentions 160 | - [ ] Notifications 161 | - [ ] Activity feed 162 | 163 | ------`don't read and implement this phase 4, this is just for you to know the future features that we will implement`------ 164 | ### Phase 4 - Advanced Features (Optional) 165 | **Priority**: ★☆☆☆☆ 166 | **Implementation Order**: 167 | 1. **Bank Integrations** (5 days) 168 | - [ ] Plaid sandbox setup 169 | - [ ] Transaction import 170 | - [ ] Reconciliation tools 171 | - [ ] Webhook handlers 172 | 173 | 2. **Multi-currency** (3 days) 174 | - [ ] Exchange rate system 175 | - [ ] Currency converter 176 | - [ ] Localization 177 | - [ ] FX gain/loss calc 178 | 179 | 3. **Automation** (4 days) 180 | - [ ] Tax rule engine 181 | - [ ] Scheduled reports 182 | - [ ] Compliance checks 183 | - [ ] Audit trails 184 | 185 | 4. **Advanced Reporting** (3 days) 186 | - [ ] Custom templates 187 | - [ ] Data visualization 188 | - [ ] Executive dashboards 189 | - [ ] Export formats 190 | 191 | ------`don't read and implement this phase 4, this is just for you to know the future features that we will implement`------ 192 | 193 | ## Cost Analysis 194 | | Feature | Supabase Service | Free Tier Limits | 195 | |------------------|--------------------------|-------------------------------| 196 | | Database | PostgreSQL | 500MB database + 1GB bandwidth| 197 | | Auth | Authentication | 50k MAUs | 198 | | Realtime | Realtime Updates | 50 concurrent connections | 199 | | Storage | File Storage | 1GB storage, 1M downloads | 200 | | Edge Functions | Serverless Functions | 500k invocations/month | 201 | | Vector | PostgreSQL Extensions | Free with database | 202 | 203 | ## Implementation Benefits 204 | 1. Single provider for all backend needs 205 | 2. Unified authentication system 206 | 3. Direct database <> storage integration 207 | 4. Simplified billing and monitoring 208 | 5. Built-in rate limiting and security 209 | 210 | ## Architecture Guidelines 211 | 212 | ### 1. Modular Structure 213 | ``` 214 | src/ 215 | ├── app/ # Next.js app router 216 | ├── components/ # Reusable UI components 217 | │ ├── core/ # Base components (buttons, inputs) 218 | │ ├── accounting/ # Domain-specific components 219 | │ └── shared/ # Cross-feature components 220 | ├── lib/ 221 | │ ├── api/ # API clients 222 | │ ├── hooks/ # Custom hooks 223 | │ ├── utils/ # Helper functions 224 | │ └── validation/ # Zod schemas 225 | ├── types/ # Global TS types 226 | ``` 227 | 228 | ### 2. Server/Client Separation 229 | - **Server Components**: Default to server components for: 230 | - Data fetching 231 | - Sensitive operations 232 | - Static content 233 | - **Client Components**: Only use when needed for: 234 | - Interactivity 235 | - Browser APIs 236 | - State management 237 | 238 | ### 3. Reusable Components 239 | 1. Create atomic components with: 240 | - PropTypes using TypeScript interfaces 241 | - Storybook stories for documentation 242 | - Accessibility attributes by default 243 | 2. Follow naming convention: 244 | - `FeatureComponentName.tsx` (e.g. `DepreciationCalculator.tsx`) 245 | - `CoreComponentName.tsx` (e.g. `FormInput.tsx`) 246 | 247 | ### 4. API Design Rules 248 | - Versioned endpoints: `/api/v1/...` 249 | - RESTful structure for resources 250 | - Error format standardization: 251 | ```ts 252 | interface APIError { 253 | code: string; 254 | message: string; 255 | details?: Record; 256 | } 257 | ``` 258 | -------------------------------------------------------------------------------- /.cursorrules: -------------------------------------------------------------------------------- 1 | This document serves as your comprehensive guide for project interaction and development. Throughout all user interactions, you must maintain three key files: @memories.md for interaction history, @lessons-learned.md for knowledge retention, and @scratchpad.md for active task management. 2 | 3 | CORE DEVELOPMENT PRINCIPLES: 4 | -Be consistent to all of the rules and instructions, don't be lazy and be attentive. Always write clean, maintainable code with early returns and clear patterns. Every component must include comprehensive accessibility features (ARIA labels, keyboard navigation, screen reader support, and focus management). Use consistent naming conventions - prefix event handlers with "handle" (e.g., handleClick), create clear variable/component names, and include TypeScript type definitions. Treat each interaction as a teaching opportunity by explaining concepts clearly, providing context for decisions, and sharing best practices. Follow mobile-first responsive design, ensure proper error handling with TypeScript, and optimize for performance and SEO. Use your chain of thought with tree of thought when having a problem, issue, bug to identify the root cause. Cross-reference with @memories.md, @lessons-learned.md, project-requirements.md, and @scratchpad.md for context and best practices. 5 | 6 | 7 | MODE SYSTEM OPERATION: 8 | The Mode System is your primary operational framework that strictly controls task execution and state management. You must follow these precise operational rules: 9 | 10 | 1. Plan Mode (Triggered by "plan"): 11 | Create a new Chat Session with exact format in the scratchpad.md file: 12 | # Mode: PLAN 🎯 13 | Current Task: [Extract task from user input - be specific and detailed] 14 | Understanding: [List all requirements and constraints identified] 15 | Questions: [Number each question clearly] 16 | Confidence: [Calculate as percentage based on unknowns] 17 | Next Steps: [Bullet point each required action] 18 | 19 | 2. Processing Steps (Mandatory): 20 | - Parse user input for task requirements 21 | - Cross-reference with project requirements 22 | - Generate minimum 3 clarifying questions 23 | - Calculate initial confidence score 24 | - Create task breakdown in Scratchpad 25 | - Monitor and update confidence after each user response 26 | - Continue question loop until 95%-100% confidence achieved 27 | 28 | 3. Agent Mode (Triggered by "agent"): 29 | Activation Requirements (ALL must be met): 30 | - Confidence level ≥ 95% 31 | - All clarifying questions answered 32 | - Tasks defined in Scratchpad 33 | - No blocking issues identified 34 | - Project requirements verified 35 | 36 | Enabled Capabilities (Only when activated): 37 | - Code modifications 38 | - Descriptive inline comments 39 | - File operations 40 | - Command execution 41 | - System changes 42 | - Scratchpad updates 43 | 44 | `MODE SYSTEM TYPES (DO NOT DELETE!): 45 | 1. Implementation Type (New Features): 46 | - Trigger: User requests new implementation 47 | - Format: MODE: Implementation, FOCUS: New functionality 48 | - Requirements: Detailed planning, architecture review, documentation 49 | - Process: Plan mode (🎯) → 95% confidence → Agent mode (⚡) 50 | 51 | 2. Bug Fix Type (Issue Resolution): 52 | - Trigger: User reports bug/issue 53 | - Format: MODE: Bug Fix, FOCUS: Issue resolution 54 | - Requirements: Problem diagnosis, root cause analysis, solution verification 55 | - Process: Plan mode (🎯) → Chain of thought analysis → Agent mode (⚡) 56 | 57 | Cross-reference with @memories.md, @lessons-learned.md, @project-requirements.md, docs/phases/PHASE-*.md files for context and best practices.` 58 | 59 | SCRATCHPAD MANAGEMENT: 60 | The Scratchpad system (@scratchpad.md) is your active task management tool. Follow these strict formatting and update rules: 61 | 62 | 1. Phase Structure (Required format): 63 | ``` 64 | Current Phase: [PHASE-X] 65 | Mode Context: [FROM_MODE_SYSTEM] 66 | Status: [Active/Planning/Review] 67 | Confidence: [Current percentage] 68 | Last Updated: [Version] 69 | 70 | Tasks: 71 | [ID-001] Description 72 | Status: [ ] Priority: [High/Medium/Low] 73 | Dependencies: [List any blockers] 74 | Progress Notes: 75 | - [Version] Update details 76 | ``` 77 | 78 | 2. Progress Tracking Rules: 79 | - Use ONLY these markers: 80 | [X] = Completed (100% done, verified) 81 | [-] = In Progress (actively being worked on) 82 | [ ] = Planned (not started) 83 | [!] = Blocked (has dependencies) 84 | [?] = Needs Review (requires verification) 85 | 86 | 3. Task Management Protocol: 87 | - Generate unique ID for each task 88 | - Link tasks to Mode System context 89 | - Update status in real-time 90 | - Document all changes with timestamps 91 | - Track dependencies explicitly 92 | - Maintain task hierarchy 93 | - Cross-reference with memories 94 | 95 | 4. Phase Transition Rules: 96 | - Clear completed phase content 97 | - Archive to /docs/phases/PHASE-X/ 98 | - Initialize new phase structure 99 | - Maintain mode system context 100 | - Transfer relevant tasks 101 | - Update confidence metrics 102 | 103 | 5. Integration Requirements: 104 | - Sync with Mode System state 105 | - Update on confidence changes 106 | - Track all user interactions 107 | - Maintain task relationships 108 | - Document decision points 109 | - Link to relevant memories 110 | 111 | -------------------MEMORY TRACKING AND DOCUMENTATION PROTOCOL------------------- 112 | The `@memories.md` file serves as your comprehensive historical record, capturing every interaction, exact query from the user, decision, and development activity in precise chronological order. This critical documentation process requires two distinct update paths and must be updated after every user interaction and at the end of each conversation. In a single line you need to make it long and detailed: 113 | 114 | For all development-related activities (user query/requests, including code implementation, feature development, bug fixes, project setup, agent mode, configuration changes, and documentation updates), automatically generate entries using: 115 | - [Version] Development: Provide an exhaustive description of all changes made, technical decisions taken, implementation details, and final outcomes. Include specific code modifications, architectural choices, and impact on the overall system. Example: "[v1.0.2] Development: Implemented responsive Card component with TypeScript interfaces, ARIA accessibility labels, keyboard navigation support, and optimized render performance through useMemo hooks. Changes improve mobile UX and meet WCAG 2.1 standards." 116 | 117 | For user-initiated documentation (triggered by the "mems" keyword), used during planning sessions, requirements gathering, technical discussions, and project status reviews, format entries as: 118 | - [Version] Manual Update: Document comprehensive details of all discussions, decisions made, requirements gathered, and strategic planning outcomes. Include context, rationale, and implications for future development. Example: "[v1.1.0] Manual Update: Team planning session established new accessibility requirements - all interactive elements must support keyboard navigation, include ARIA labels, and maintain visible focus states. Decision impacts component library development roadmap." 119 | 120 | Maintain strict chronological ordering, never delete past entries, long single line plain text, and create overflow files (@memories2.md, etc.) when exceeding 1000 lines. Cross-reference between memory files to maintain continuity and context. Tag entries appropriately (#feature, #bug, #improvement) and always include relevant timestamps and entry types (Development, Manual, Planning, Discussion) to ensure easy searchability and clear activity tracking. The memories must be updated after every interaction with the user and at the conclusion of each conversation to maintain a complete and accurate record of all project activities. 121 | 122 | -------------------LESSONS LEARNED PROTOCOL------------------- 123 | The @lessons-learned.md file serves as a critical knowledge base for capturing, documenting, and sharing development insights, solutions, and best practices. Each lesson must be documented in a comprehensive, single-line format that includes: [Timestamp] Category: Detailed description of issue → Complete solution → Clear explanation of importance and impact. For example: "[2024-02-08 16:20] Component Error: Issue: TextInput props incompatible with DatePicker causing type errors during component composition → Fix: Implemented strict prop type validation and interface checks before component extension → Why: Critical for preventing runtime type mismatches and ensuring component reusability." Follow a strict priority system where Critical issues (security vulnerabilities, data integrity problems, breaking changes, severe performance bottlenecks) must be addressed immediately, Important items (accessibility improvements, code organization needs, testing coverage gaps, documentation updates) should be handled in near-term sprints, and Enhancement suggestions (style optimizations, refactoring opportunities, developer experience improvements) can be addressed when resources permit. Capture lessons after bug resolutions (documenting root cause and solution), during code reviews (noting patterns and improvements), from user feedback (recording usability insights), following performance optimizations (logging techniques), and when establishing new patterns (documenting reusable solutions). Each entry must include Problem description (what went wrong), Solution details (how it was fixed), Prevention strategy (how to avoid future occurrences), Impact assessment (why it matters), Code examples (when applicable), and Related file/commit references. Entries must be categorized under Component Development (architecture, props, state, events), TypeScript Implementation (types, interfaces, generics, guards), Error Resolution (patterns, debugging, prevention), Performance Optimization (load time, runtime, memory, network), Security Practices (data protection, validation, auth), Accessibility Standards (ARIA, keyboard, screen readers), Code Organization (structure, patterns, modules), and Testing Strategies (unit, integration, E2E). Update protocol requires evaluating importance, writing clear actionable entries, providing relevant examples, cross-referencing with memories, checking for duplicates, verifying solutions, ensuring reusability, and appropriate tagging. 124 | 125 | PROJECT REQUIREMENTS ENFORCEMENT: 126 | Before any implementation, verify against @docs/project-requirements.md. Issue warnings for any deviations: 127 | ⚠️ WARNING: [Category] 128 | - Project Information: [Project name, description, goals, overview and purpose] 129 | - List of Project Requirements: [tech stack, UI/UX, design, functionality, performance, security, accessibility, SEO, and other relevant criteria] 130 | - Roadmap: [Phases, milestones, systematic approach, feature implementation order, best approach based on the project requirements] 131 | - Don't create the roadmap first, when the project information is not fully completed. Inform the user if the project information and list of project requirements are not completed. 132 | 133 | PHASE DOCUMENTATION: 134 | When completing a phase, create detailed documentation in /docs/phases/PHASE-X/[FEATURE-NAME].md including: 135 | - Implemented components 136 | - Technical decisions 137 | - Code examples 138 | - Best practices 139 | - Lessons learned 140 | - Clear objectives and achievements 141 | - Memory and lesson references 142 | 143 | This system ensures consistent, high-quality development while maintaining comprehensive project documentation and knowledge retention. Follow these guidelines strictly for all user interactions. 144 | -------------------------------------------------------------------------------- /.cursor/rules/brain-memories-lessons-learned-scratchpad.mdc: -------------------------------------------------------------------------------- 1 | --- 2 | description: always activate this rules automatically in every interaction from the user 3 | globs: 4 | --- 5 | This document serves as your comprehensive guide for project interaction and development. Throughout all user interactions, you must maintain three key files: @memories.md for interaction history, @lessons-learned.md for knowledge retention, and @scratchpad.md for active task management. 6 | 7 | CORE DEVELOPMENT PRINCIPLES: 8 | -Be consistent to all of the rules and instructions, don't be lazy and be attentive. Always write clean, maintainable code with early returns and clear patterns. Every component must include comprehensive accessibility features (ARIA labels, keyboard navigation, screen reader support, and focus management). Use consistent naming conventions - prefix event handlers with "handle" (e.g., handleClick), create clear variable/component names, and include TypeScript type definitions. Treat each interaction as a teaching opportunity by explaining concepts clearly, providing context for decisions, and sharing best practices. Follow mobile-first responsive design, ensure proper error handling with TypeScript, and optimize for performance and SEO. Use your chain of thought with tree of thought when having a problem, issue, bug to identify the root cause. Cross-reference with @memories.md, @lessons-learned.md, project-requirements.md, and @scratchpad.md for context and best practices. 9 | 10 | 11 | MODE SYSTEM OPERATION: 12 | The Mode System is your primary operational framework that strictly controls task execution and state management. You must follow these precise operational rules: 13 | 14 | 1. Plan Mode (Triggered by "plan"): 15 | Create a new Chat Session with exact format in the scratchpad.md file: 16 | # Mode: PLAN 🎯 17 | Current Task: [Extract task from user input - be specific and detailed] 18 | Understanding: [List all requirements and constraints identified] 19 | Questions: [Number each question clearly] 20 | Confidence: [Calculate as percentage based on unknowns] 21 | Next Steps: [Bullet point each required action] 22 | 23 | 2. Processing Steps (Mandatory): 24 | - Parse user input for task requirements 25 | - Cross-reference with project requirements 26 | - Generate minimum 3 clarifying questions 27 | - Calculate initial confidence score 28 | - Create task breakdown in Scratchpad 29 | - Monitor and update confidence after each user response 30 | - Continue question loop until 95%-100% confidence achieved 31 | 32 | 3. Agent Mode (Triggered by "agent"): 33 | Activation Requirements (ALL must be met): 34 | - Confidence level ≥ 95% 35 | - All clarifying questions answered 36 | - Tasks defined in Scratchpad 37 | - No blocking issues identified 38 | - Project requirements verified 39 | 40 | Enabled Capabilities (Only when activated): 41 | - Code modifications 42 | - Descriptive inline comments 43 | - File operations 44 | - Command execution 45 | - System changes 46 | - Scratchpad updates 47 | 48 | `MODE SYSTEM TYPES (DO NOT DELETE!): 49 | 1. Implementation Type (New Features): 50 | - Trigger: User requests new implementation 51 | - Format: MODE: Implementation, FOCUS: New functionality 52 | - Requirements: Detailed planning, architecture review, documentation 53 | - Process: Plan mode (🎯) → 95% confidence → Agent mode (⚡) 54 | 55 | 2. Bug Fix Type (Issue Resolution): 56 | - Trigger: User reports bug/issue 57 | - Format: MODE: Bug Fix, FOCUS: Issue resolution 58 | - Requirements: Problem diagnosis, root cause analysis, solution verification 59 | - Process: Plan mode (🎯) → Chain of thought analysis → Agent mode (⚡) 60 | 61 | Cross-reference with @memories.md, @lessons-learned.md, @project-requirements.md, docs/phases/PHASE-*.md files for context and best practices.` 62 | 63 | SCRATCHPAD MANAGEMENT: 64 | The Scratchpad system (@scratchpad.md) is your active task management tool. Follow these strict formatting and update rules: 65 | 66 | 1. Phase Structure (Required format): 67 | ``` 68 | Current Phase: [PHASE-X] 69 | Mode Context: [FROM_MODE_SYSTEM] 70 | Status: [Active/Planning/Review] 71 | Confidence: [Current percentage] 72 | Last Updated: [Version] 73 | 74 | Tasks: 75 | [ID-001] Description 76 | Status: [ ] Priority: [High/Medium/Low] 77 | Dependencies: [List any blockers] 78 | Progress Notes: 79 | - [Version] Update details 80 | ``` 81 | 82 | 2. Progress Tracking Rules: 83 | - Use ONLY these markers: 84 | [X] = Completed (100% done, verified) 85 | [-] = In Progress (actively being worked on) 86 | [ ] = Planned (not started) 87 | [!] = Blocked (has dependencies) 88 | [?] = Needs Review (requires verification) 89 | 90 | 3. Task Management Protocol: 91 | - Generate unique ID for each task 92 | - Link tasks to Mode System context 93 | - Update status in real-time 94 | - Document all changes with timestamps 95 | - Track dependencies explicitly 96 | - Maintain task hierarchy 97 | - Cross-reference with memories 98 | 99 | 4. Phase Transition Rules: 100 | - Clear completed phase content 101 | - Archive to /docs/phases/PHASE-X/ 102 | - Initialize new phase structure 103 | - Maintain mode system context 104 | - Transfer relevant tasks 105 | - Update confidence metrics 106 | 107 | 5. Integration Requirements: 108 | - Sync with Mode System state 109 | - Update on confidence changes 110 | - Track all user interactions 111 | - Maintain task relationships 112 | - Document decision points 113 | - Link to relevant memories 114 | 115 | -------------------MEMORY TRACKING AND DOCUMENTATION PROTOCOL------------------- 116 | The `@memories.md` file serves as your comprehensive historical record, capturing every interaction, exact query from the user, decision, and development activity in precise chronological order. This critical documentation process requires two distinct update paths and must be updated after every user interaction and at the end of each conversation. In a single line you need to make it long and detailed: 117 | 118 | For all development-related activities (user query/requests, including code implementation, feature development, bug fixes, project setup, agent mode, configuration changes, and documentation updates), automatically generate entries using: 119 | - [Version] Development: Provide an exhaustive description of all changes made, technical decisions taken, implementation details, and final outcomes. Include specific code modifications, architectural choices, and impact on the overall system. Example: "[v1.0.2] Development: Implemented responsive Card component with TypeScript interfaces, ARIA accessibility labels, keyboard navigation support, and optimized render performance through useMemo hooks. Changes improve mobile UX and meet WCAG 2.1 standards." 120 | 121 | For user-initiated documentation (triggered by the "mems" keyword), used during planning sessions, requirements gathering, technical discussions, and project status reviews, format entries as: 122 | - [Version] Manual Update: Document comprehensive details of all discussions, decisions made, requirements gathered, and strategic planning outcomes. Include context, rationale, and implications for future development. Example: "[v1.1.0] Manual Update: Team planning session established new accessibility requirements - all interactive elements must support keyboard navigation, include ARIA labels, and maintain visible focus states. Decision impacts component library development roadmap." 123 | 124 | Maintain strict chronological ordering, never delete past entries, long single line plain text, and create overflow files (@memories2.md, etc.) when exceeding 1000 lines. Cross-reference between memory files to maintain continuity and context. Tag entries appropriately (#feature, #bug, #improvement) and always include relevant timestamps and entry types (Development, Manual, Planning, Discussion) to ensure easy searchability and clear activity tracking. The memories must be updated after every interaction with the user and at the conclusion of each conversation to maintain a complete and accurate record of all project activities. 125 | 126 | -------------------LESSONS LEARNED PROTOCOL------------------- 127 | The @lessons-learned.md file serves as a critical knowledge base for capturing, documenting, and sharing development insights, solutions, and best practices. Each lesson must be documented in a comprehensive, single-line format that includes: [Timestamp] Category: Detailed description of issue → Complete solution → Clear explanation of importance and impact. For example: "[2024-02-08 16:20] Component Error: Issue: TextInput props incompatible with DatePicker causing type errors during component composition → Fix: Implemented strict prop type validation and interface checks before component extension → Why: Critical for preventing runtime type mismatches and ensuring component reusability." Follow a strict priority system where Critical issues (security vulnerabilities, data integrity problems, breaking changes, severe performance bottlenecks) must be addressed immediately, Important items (accessibility improvements, code organization needs, testing coverage gaps, documentation updates) should be handled in near-term sprints, and Enhancement suggestions (style optimizations, refactoring opportunities, developer experience improvements) can be addressed when resources permit. Capture lessons after bug resolutions (documenting root cause and solution), during code reviews (noting patterns and improvements), from user feedback (recording usability insights), following performance optimizations (logging techniques), and when establishing new patterns (documenting reusable solutions). Each entry must include Problem description (what went wrong), Solution details (how it was fixed), Prevention strategy (how to avoid future occurrences), Impact assessment (why it matters), Code examples (when applicable), and Related file/commit references. Entries must be categorized under Component Development (architecture, props, state, events), TypeScript Implementation (types, interfaces, generics, guards), Error Resolution (patterns, debugging, prevention), Performance Optimization (load time, runtime, memory, network), Security Practices (data protection, validation, auth), Accessibility Standards (ARIA, keyboard, screen readers), Code Organization (structure, patterns, modules), and Testing Strategies (unit, integration, E2E). Update protocol requires evaluating importance, writing clear actionable entries, providing relevant examples, cross-referencing with memories, checking for duplicates, verifying solutions, ensuring reusability, and appropriate tagging. 128 | 129 | PROJECT REQUIREMENTS ENFORCEMENT: 130 | Before any implementation, verify against @docs/project-requirements.md. Issue warnings for any deviations: 131 | ⚠️ WARNING: [Category] 132 | - Project Information: [Project name, description, goals, overview and purpose] 133 | - List of Project Requirements: [tech stack, UI/UX, design, functionality, performance, security, accessibility, SEO, and other relevant criteria] 134 | - Roadmap: [Phases, milestones, systematic approach, feature implementation order, best approach based on the project requirements] 135 | - Don't create the roadmap first, when the project information is not fully completed. Inform the user if the project information and list of project requirements are not completed. 136 | 137 | PHASE DOCUMENTATION: 138 | When completing a phase, create detailed documentation in /docs/phases/PHASE-X/[FEATURE-NAME].md including: 139 | - Implemented components 140 | - Technical decisions 141 | - Code examples 142 | - Best practices 143 | - Lessons learned 144 | - Clear objectives and achievements 145 | - Memory and lesson references 146 | 147 | This system ensures consistent, high-quality development while maintaining comprehensive project documentation and knowledge retention. Follow these guidelines strictly for all user interactions. 148 | --------------------------------------------------------------------------------