Thank you for taking the time to contribute to Maleku System! Every contribution — whether it is a bug fix, a new feature, improved documentation, or a failing test — makes the project better for everyone. Maleku System is released under the MIT License, which means your contributions will always remain open and freely available to the community.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/IvanchoDev89/maleku-system/llms.txt
Use this file to discover all available pages before exploring further.
Branching Strategy
Maleku System follows Git Flow. Thedevelop branch is the integration target for all in-progress work; main always reflects production-ready code. Use the branch naming patterns below so that CI, reviewers, and release tooling can identify the intent of a branch at a glance:
| Branch / Prefix | Purpose | Based on | Merges into |
|---|---|---|---|
main | Production code | — | — |
develop | Development integration | — | main |
feature/* | New functionality | develop | develop |
bugfix/* | Bug corrections | develop | develop |
hotfix/* | Urgent production fixes | main | main + develop |
release/* | Release preparation | develop | main |
Keep branches short-lived and focused on a single concern. Long-running branches diverge quickly from
develop and create difficult merge conflicts. Open a draft PR early if you want feedback before the work is complete.Commit Conventions
Maleku System follows the Conventional Commits specification. Every commit message must start with a type, an optional scope in parentheses, and a concise imperative description.Commit Types
| Type | When to use |
|---|---|
feat | Introduces a new feature |
fix | Corrects a bug |
docs | Documentation-only changes |
chore | Maintenance tasks (deps, tooling, CI config) |
refactor | Code restructuring with no functional change |
test | Adding or updating tests |
perf | Performance improvements |
style | Formatting changes with no logic change |
ci | CI/CD pipeline changes |
security | Security-related fixes |
Examples from the Project’s Own History
Code Style
Backend (Python)
The backend enforces style automatically through ruff (linting + formatting) configured in.pre-commit-config.yaml. Black is effectively replaced by ruff-format, which uses the same 88-character line length as Black.
Frontend (TypeScript / Vue)
The frontend uses ESLint with the Vue 3 + TypeScript rule set. TypeScript strict mode is enabled intsconfig.json.
Pre-commit hooks enforce both
Never push code that fails the pre-commit checks. The hooks run automatically on everygit commit once installed (see Dev Setup → Pre-commit Hooks):
The CI pipeline runs the same checks — ruff, Vitest, and the deploy step — on every pushed branch. Pre-commit hooks let you catch failures locally before they block your PR. This pipeline was introduced in the v1.0.0 release alongside integration tests, monitoring, feature flags, and rate limiting.
Pull Request Process
Fork the repository
Create a personal fork on GitHub and add the upstream remote so you can keep your fork in sync with
main.Create a feature branch
Branch from the latest
develop using one of the naming conventions described in Branching Strategy.Make changes and write tests
Implement your change, then add or update tests to cover the new behaviour. Backend tests go in
backend/tests/; frontend tests live alongside source files or in a __tests__/ subdirectory. All tests must pass before opening a PR.Commit with a conventional message
Stage your changes and commit using the Conventional Commits format. The pre-commit hooks will run automatically and block the commit if any check fails.
Push and open a Pull Request
Push your branch to your fork and open a PR against
develop on the upstream repository. Fill in the PR template: describe the change, its type, how it was tested, and link any related issues.PR Checklist
Before marking your PR as ready for review, confirm the following:- Code follows style guidelines (
pre-commit run --all-filespasses) - All existing tests pass
- New tests cover the new or changed behaviour
- No
console.logor debug code left in - Commit messages follow the Conventional Commits convention
- Documentation updated if the change affects public APIs or developer workflows
Backend Standards
Async All the Way
Every route handler, service method, and database call must beasync. Maleku System uses SQLAlchemy 2.x with asyncpg as the async PostgreSQL driver — never use the synchronous session in application code.
Pydantic v2 Schemas
All request bodies and response models must use Pydantic v2 (pydantic>=2.10.0). Define separate Create, Update, and Response schemas — never expose ORM models directly.
Structured Logging
Useget_logger(__name__) for all logging throughout the application. Never use print() in application code.
Swagger Documentation
Every route decorator must include asummary and description. As of v1.0.0, Swagger summaries, descriptions, and tags are present on all 52 endpoints — new endpoints must maintain this standard.
Frontend Standards
Composition API with <script setup>
Every component must use the Composition API with the <script setup lang="ts"> single-file component syntax. Options API and defineComponent wrappers are not accepted in new code.
Pinia for State Management
Global and cross-component state must live in Pinia stores. The@pinia/nuxt module is already registered — define stores using the Composition API syntax (defineStore with a setup function).
Composables for Reusable Logic
Extract reusable reactive logic into composables undercomposables/. Name them with the use prefix (e.g., useAuth.ts, useSearch.ts).
TypeScript Strict Mode
TypeScript strict mode is enabled. All new files must be.ts or use lang="ts" in <script setup>. Avoid any — use explicit types or unknown with type guards.
i18n Keys for All User-Visible Strings
The project supports English (en), Spanish (es), and French (fr) via @nuxtjs/i18n. Every string rendered to the user must reference an i18n key — never hard-code display text in templates or composables.
Security Reporting
Maleku System takes security seriously. Please review the full SECURITY.md before disclosing any vulnerability. Instead, report vulnerabilities privately by emailing security@costaricatravel.dev. You should receive a response within 48 hours. If you do not, follow up to confirm receipt of your original message. Include the following in your report:- A clear description of the vulnerability
- Step-by-step instructions to reproduce it
- The affected endpoints or components
- Any proof-of-concept code or screenshots (if available)
- The potential impact
What to Expect
| Step | Timeline |
|---|---|
| Acknowledgement | Within 48 hours |
| Estimated fix timeline | Provided in first response |
| Fix deployed notification | Sent when patch is live |
| Coordinated public disclosure | Within 90-day disclosure window |
1.x is the only currently supported release. Vulnerabilities reported against versions below 1.0 will not receive patches.
Maleku System uses bcrypt (11 rounds) for password hashing, SLOWAPI rate limiting (60 req/min per IP, 5 login attempts per 15 min), JWT with token blacklisting, and parameterized SQLAlchemy queries throughout. Consult
SECURITY.md for the full list of security measures in place.