# 🤝 Contributing to Plexus

We maintain high standards for code quality and documentation. Please follow this workflow for all contributions.

## 🔄 Development Workflow

### 1. Pick a Task
Before coding, ensure you are working on an assigned task.
- List tasks: `make task-list`
- Add a task: `make task-add title="Your Task"`
- Mark as in-progress: (Update manually in `tasks/tasks.duckdb` or via CLI if implemented).

### 2. Implementation
- Write clean, modular code.
- Follow the existing design patterns (Vue 3 Composition API, Pinia, Socket.io).
- Ensure UI changes are mobile-friendly and follow the Discord-inspired aesthetic.

### 3. Verification
Before committing, you **must** verify your changes:
- Run linting: `make lint`
- Run tests: `make test`
- Manual check: Verify the feature in the browser.

### 4. Commit
We use **Husky** and **lint-staged** to enforce quality.
- Your commit will fail if linting or tests do not pass.
- Use descriptive commit messages (e.g., `feat: add user profiles`, `fix: message alignment`).

### 5. Documentation
If your change affects the architecture, data model, or API:
- Update the relevant file in `docs/`.
- Ensure the root `README.md` is still accurate.

### 6. Finalize Task
Mark the task as done:
- `make task-done id=X`

## 🛠 Tooling
- **Linting**: ESLint for JS/Vue, Ruff for Python.
- **Testing**: Mocha for backend integration tests.
- **Automation**: Use the `Makefile` for all common operations.

---
Thank you for helping make Plexus better!