karyamanswasta/karyaman-project
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: initial commit for camping rental webapp

Browse Source 
This commit establishes the foundational structure for the Karyaman project, focusing on the camping equipment rental web application.

Key additions include:
- Scaffolding for three React applications: `adventure-rental-app`, `motel-app`, and `pakrete-app` using Create React App.
- Initial implementation of `HomePage` and `CategoriesPage` components for the `adventure-rental-app`, based on provided design mockups.
- Project documentation including PRDs and design files for the applications.
- Configuration of the Kilo Code memory bank with core project details such as architecture, product vision, and tech stack.
This commit is contained in:
karyamanswasta
2025-07-31 00:07:28 +07:00
commit 12c65e4f9f
68 changed files with 55300 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

167
.kilocode/rules/memory-bank-instructions.md Normal file
View File

@@ -0,0 +1,167 @@
# Memory Bank
I am an expert software engineer with a unique characteristic: my memory resets completely between sessions. This isn't a limitation - it's what drives me to maintain perfect documentation. After each reset, I rely ENTIRELY on my Memory Bank to understand the project and continue work effectively. I MUST read ALL memory bank files at the start of EVERY task - this is not optional. The memory bank files are located in `.kilocode/rules/memory-bank` folder.
When I start a task, I will include `[Memory Bank: Active]` at the beginning of my response if I successfully read the memory bank files, or `[Memory Bank: Missing]` if the folder doesn't exist or is empty. If memory bank is missing, I will warn the user about potential issues and suggest initialization.
## Memory Bank Structure
The Memory Bank consists of core files and optional context files, all in Markdown format.
### Core Files (Required)
1. `brief.md`
This file is created and maintained manually by the developer. Don't edit this file directly but suggest to user to update it if it can be improved.
- Foundation document that shapes all other files
- Created at project start if it doesn't exist
- Defines core requirements and goals
- Source of truth for project scope
2. `product.md`
- Why this project exists
- Problems it solves
- How it should work
- User experience goals
3. `context.md`
This file should be short and factual, not creative or speculative.
- Current work focus
- Recent changes
- Next steps
4. `architecture.md`
- System architecture
- Source Code paths
- Key technical decisions
- Design patterns in use
- Component relationships
- Critical implementation paths
5. `tech.md`
- Technologies used
- Development setup
- Technical constraints
- Dependencies
- Tool usage patterns
### Additional Files
Create additional files/folders within memory-bank/ when they help organize:
- `tasks.md` - Documentation of repetitive tasks and their workflows
- Complex feature documentation
- Integration specifications
- API documentation
- Testing strategies
- Deployment procedures
## Core workflows
### Memory Bank Initialization
The initialization step is CRITICALLY IMPORTANT and must be done with extreme thoroughness as it defines all future effectiveness of the Memory Bank. This is the foundation upon which all future interactions will be built.
When user requests initialization of the memory bank (command `initialize memory bank`), I'll perform an exhaustive analysis of the project, including:
- All source code files and their relationships
- Configuration files and build system setup
- Project structure and organization patterns
- Documentation and comments
- Dependencies and external integrations
- Testing frameworks and patterns
I must be extremely thorough during initialization, spending extra time and effort to build a comprehensive understanding of the project. A high-quality initialization will dramatically improve all future interactions, while a rushed or incomplete initialization will permanently limit my effectiveness.
After initialization, I will ask the user to read through the memory bank files and verify product description, used technologies and other information. I should provide a summary of what I've understood about the project to help the user verify the accuracy of the memory bank files. I should encourage the user to correct any misunderstandings or add missing information, as this will significantly improve future interactions.
### Memory Bank Update
Memory Bank updates occur when:
1. Discovering new project patterns
2. After implementing significant changes
3. When user explicitly requests with the phrase **update memory bank** (MUST review ALL files)
4. When context needs clarification
If I notice significant changes that should be preserved but the user hasn't explicitly requested an update, I should suggest: "Would you like me to update the memory bank to reflect these changes?"
To execute Memory Bank update, I will:
1. Review ALL project files
2. Document current state
3. Document Insights & Patterns
4. If requested with additional context (e.g., "update memory bank using information from @/Makefile"), focus special attention on that source
Note: When triggered by **update memory bank**, I MUST review every memory bank file, even if some don't require updates. Focus particularly on context.md as it tracks current state.
### Add Task
When user completes a repetitive task (like adding support for a new model version) and wants to document it for future reference, they can request: **add task** or **store this as a task**.
This workflow is designed for repetitive tasks that follow similar patterns and require editing the same files. Examples include:
- Adding support for new AI model versions
- Implementing new API endpoints following established patterns
- Adding new features that follow existing architecture
Tasks are stored in the file `tasks.md` in the memory bank folder. The file is optional an can be empty. The file can store many tasks.
To execute Add Task workflow:
1. Create or update `tasks.md` in the memory bank folder
2. Document the task with:
- Task name and description
- Files that need to be modified
- Step-by-step workflow followed
- Important considerations or gotchas
- Example of the completed implementation
3. Include any context that was discovered during task execution but wasn't previously documented
Example task entry:
```markdown
## Add New Model Support
**Last performed:** [date]
**Files to modify:**
- `/providers/gemini.md` - Add model to documentation
- `/src/providers/gemini-config.ts` - Add model configuration
- `/src/constants/models.ts` - Add to model list
- `/tests/providers/gemini.test.ts` - Add test cases
**Steps:**
1. Add model configuration with proper token limits
2. Update documentation with model capabilities
3. Add to constants file for UI display
4. Write tests for new model configuration
**Important notes:**
- Check Google's documentation for exact token limits
- Ensure backward compatibility with existing configurations
- Test with actual API calls before committing
```
### Regular Task Execution
In the beginning of EVERY task I MUST read ALL memory bank files - this is not optional.
The memory bank files are located in `.kilocode/rules/memory-bank` folder. If the folder doesn't exist or is empty, I will warn user about potential issues with the memory bank. I will include `[Memory Bank: Active]` at the beginning of my response if I successfully read the memory bank files, or `[Memory Bank: Missing]` if the folder doesn't exist or is empty. If memory bank is missing, I will warn the user about potential issues and suggest initialization. I should briefly summarize my understanding of the project to confirm alignment with the user's expectations, like:
"[Memory Bank: Active] I understand we're building a React inventory system with barcode scanning. Currently implementing the scanner component that needs to work with the backend API."
When starting a task that matches a documented task in `tasks.md`, I should mention this and follow the documented workflow to ensure no steps are missed.
If the task was repetitive and might be needed again, I should suggest: "Would you like me to add this task to the memory bank for future reference?"
In the end of the task, when it seems to be completed, I will update `context.md` accordingly. If the change seems significant, I will suggest to the user: "Would you like me to update memory bank to reflect these changes?" I will not suggest updates for minor changes.
## Context Window Management
When the context window fills up during an extended session:
1. I should suggest updating the memory bank to preserve the current state
2. Recommend starting a fresh conversation/task
3. In the new conversation, I will automatically load the memory bank files to maintain continuity
## Technical Implementation
Memory Bank is built on Kilo Code's Custom Rules feature, with files stored as standard markdown documents that both the user and I can access.
## Important Notes
REMEMBER: After every memory reset, I begin completely fresh. The Memory Bank is my only link to previous work. It must be maintained with precision and clarity, as my effectiveness depends entirely on its accuracy.
If I detect inconsistencies between memory bank files, I should prioritize brief.md and note any discrepancies to the user.
IMPORTANT: I MUST read ALL memory bank files at the start of EVERY task - this is not optional. The memory bank files are located in `.kilocode/rules/memory-bank` folder.

42
.kilocode/rules/memory-bank/architecture.md Normal file
View File

@@ -0,0 +1,42 @@
# Architecture: Webapp Rental Peralatan Camping
## System Architecture
The system will follow a client-server architecture with a clear separation between the frontend and backend.
```mermaid
graph TD
A[User/Renter] -->|Accesses| B(Frontend React.js)
B -->|API Calls| C(Backend n8n)
C -->|Database Queries| D[PostgreSQL Database]
E[Admin/Business Owner] -->|Manages| F(Admin Dashboard React.js)
F -->|API Calls| C
C -->|Webhooks/Triggers| G[Payment Gateway]
C -->|Triggers| H[Email Service Provider]
```
## Source Code Paths
- Frontend (React.js): `src/frontend/` (to be created)
- Backend (n8n workflows): `src/backend/n8n/` (to be created)
- Database (PostgreSQL schema/migrations): `src/backend/database/` (to be created)
## Key Technical Decisions
- **Frontend Framework:** React.js for a dynamic and interactive user interface.
- **Backend Orchestration:** n8n for workflow automation, API endpoint creation, and integration with external services (payment gateways, email). This allows for rapid development and flexible workflow management.
- **Database:** PostgreSQL for robust and scalable data storage, supporting complex queries and relationships.
- **Real-time Availability:** Calendar integration on the frontend will pull real-time availability data from PostgreSQL via n8n APIs.
- **Payment Processing:** Integration with local payment gateways via n8n webhooks for secure transactions.
## Design Patterns in Use
- **MVC/MVVM (Conceptual):** While n8n handles much of the backend logic, the React frontend will conceptually follow an MVVM pattern for UI separation.
- **API-driven Development:** Frontend and backend communicate exclusively via RESTful APIs exposed by n8n.
- **Event-driven Architecture (for integrations):** n8n's workflow capabilities enable event-driven interactions with payment gateways and email services.
## Component Relationships
- **Frontend & Backend:** The React.js frontend consumes APIs provided by the n8n backend.
- **Backend & Database:** n8n interacts directly with the PostgreSQL database for all data persistence.
- **Backend & External Services:** n8n acts as an intermediary for payment gateways and email services.
## Critical Implementation Paths
- **Booking Process:** Ensuring seamless date selection, cart management, and secure payment integration.
- **Inventory Management:** Real-time stock updates and calendar synchronization are crucial.
- **Order Status Updates:** Manual status changes by admins must correctly trigger availability updates.

3
.kilocode/rules/memory-bank/brief.md Normal file
View File

@@ -0,0 +1,3 @@
# Project Brief: Webapp Rental Peralatan Camping
This project aims to develop a web application for renting camping equipment. The primary goal is to provide an intuitive platform for customers to browse, rent, and return equipment, while enabling business owners to efficiently manage inventory, orders, and customer interactions.

10
.kilocode/rules/memory-bank/context.md Normal file
View File

@@ -0,0 +1,10 @@
# Context
## Current work focus
Initializing the memory bank for the Webapp Rental Peralatan Camping project.
## Recent changes
- Created `architecture.md` and `tech.md` based on `adventure-rental-app/prd.md`.
## Next steps
- Summarize project understanding and ask for user verification.

32
.kilocode/rules/memory-bank/product.md Normal file
View File

@@ -0,0 +1,32 @@
# Product: Webapp Rental Peralatan Camping
## Why this project exists
This project exists to provide a modern, efficient, and user-friendly solution for renting camping equipment. Many existing rental processes are manual, inefficient, and lack real-time inventory visibility. This web application aims to streamline operations for business owners and simplify the rental experience for customers.
## Problems it solves
- Inefficient manual inventory tracking
- Difficulties for customers to check equipment availability
- Lack of a centralized platform for managing orders and customer data
- Limited reach for rental businesses beyond physical locations
## How it should work
The web application will consist of two main modules:
1. **User Module (Renter):**
- **Search & Discovery:** Users can search by category, keyword, and apply filters/sorts (price, availability, capacity, brand, reviews).
- **Product Details:** Comprehensive information including name, description, price, images, availability calendar, specifications, and customer reviews.
- **Booking Process:** Users select rental dates via an interactive calendar, add items to a shopping cart, review order summary, fill in personal details, and choose a payment method. Order confirmation is sent via email/notification.
- **User Account Management:** Registration/login, profile management, order history, and notifications.
2. **Admin/Business Owner Module:**
- **Inventory Management:** Add, edit, delete equipment with full details (name, description, price, stock, images, category, specifications). Manage categories. Real-time stock tracking integrated with the calendar, allowing admins to block dates for maintenance.
- **Order Management:** View all orders with statuses, detailed order information, and manual status changes (which update calendar availability). Search and filter orders.
- **Customer Management:** View customer list and order history.
- **Return Management:** Record returned equipment, note condition, and calculate penalties for damage/late returns.
- **Reports & Analytics:** Revenue reports, inventory reports (popular, rarely rented, frequently damaged items), and availability forecasts.
## User experience goals
- **Intuitive Interface:** Easy to navigate for both renters and admins.
- **Seamless Booking:** A straightforward and clear booking process, especially with calendar interactions.
- **Real-time Information:** Instant updates on equipment availability and order statuses.
- **Responsive Design:** Accessible and functional on both desktop and mobile devices.
- **Secure Transactions:** Ensuring safe and reliable payment processing and data handling.

29
.kilocode/rules/memory-bank/tech.md Normal file
View File

@@ -0,0 +1,29 @@
# Tech: Webapp Rental Peralatan Camping
## Technologies Used
- **Frontend:** React.js (with Create React App)
- **Backend Orchestration:** n8n
- **Database:** PostgreSQL
- **Payment Gateway Integration:** Local payment providers (e.g., Midtrans, Xendit, Duitku)
- **Email Service Provider:** (To be determined, integrated via n8n)
## Development Setup
- **Frontend:** Node.js, npm/yarn, React development server (from CRA).
- **Backend:** Docker for n8n, PostgreSQL database instance.
- **Version Control:** Git.
## Technical Constraints
- **n8n Limitations:** Understanding and working within n8n's capabilities for complex logic and custom integrations.
- **Scalability:** Initial setup might focus on a single server, with future considerations for horizontal scaling.
- **Security:** Adherence to best practices for data security and user authentication.
## Dependencies
- React libraries (e.g., React Router, state management library like Redux/Context API).
- PostgreSQL client library for n8n.
- Payment gateway SDKs/APIs.
- Email service provider APIs.
## Tool Usage Patterns
- **Frontend Development:** Standard React development workflow (component-based, JSX, state management).
- **Backend Development:** n8n workflow creation (nodes, expressions, webhooks).
- **Database Management:** SQL for schema definition, migrations, and direct queries if needed.