# 🌊 Code Generation Instructions  
**(For AI-Assisted Code Suggestions)**

These are **project-specific** and **AI-optimized** instructions for **Mboss**, our internal code assistant. They define how code should be structured, styled, and validated for projects like the Billing & OSS system.

---

## 📆 Project Overview

Mboss is used across full-stack projects built with:

- **Backend**: Node.js, Express.js, MySQL, Sequelize
- **Frontend**: React (functional components), Tailwind CSS
- **Infrastructure**: Docker Compose
- **Database**: MySQL (with Sequelize or native queries), InfluxDB for monitoring
- **Architecture**: MVC + Service Layer, Modular + REST APIs

---

## 🛠️ Architecture Standards

### ✅ Backend (`/api`)
- **MVC + Service Layer**:  
  `controllers/`, `services/`, `models/`, `routes/`, `validators/`, `middleware/`
- Use **Joi** for input validation
- Logic must go in `/services`, not controllers
- Routes -> Controllers -> Services -> Models

### ✅ Frontend (`/admin`, `/client`, etc.)
- Functional components with React Hooks
- Tailwind CSS for all styling
- Axios for HTTP requests
- Folders:  
  `/components/`, `/pages/`, `/hooks/`, `/services/`, `/utils/`, `/layout/`

---

## 📂 Directory-Aware Folder Expectations

```plaintext
/api/
  ├── controllers/
  ├── models/
  ├── services/
  ├── routes/
  ├── validators/
  ├── middleware/
  ├── utils/
  ├── config/
  └── tests/

/admin/src/
  ├── components/
  ├── pages/
  ├── hooks/
  ├── services/
  ├── layout/
  └── utils/
```

---

## 📝 Database Schema

db_structure.dbml is the database schema file that defines the structure of the database.

---

## ✅ Code Generation Conventions (Mboss Rules)

| Rule | Description |
|------|-------------|
| `camelCase` | Functions, variables |
| `PascalCase` | Components, models |
| `async/await` only | No `.then()` chains |
| No logic in controllers | Use `/services/` instead |
| Validation required | Always add Joi schema for APIs |
| `.env` usage | For secrets, base URLs, etc. |
| Docker-ready | No hardcoded config in source |

---

## 💪 Testing Expectations

- Backend: Use **Jest**
  - Generate `*.test.js` in `/tests/` when creating new services
- Frontend: Use **React Testing Library** (optional)
  - Prefer E2E or integration-style tests for key flows

---

<!-- ## 🧠 Mboss Code Output Must Include:

| Context | Minimum Expected Output |
|--------|--------------------------|
| New Model (e.g., `Account`) | Model, Validator, Controller, Service, Route, Test |
| New API | Joi validation, Controller, Service logic |
| New React Page | Page file, API calls via Axios, Tailwind layout |
| New Shared UI | Component in `/components/` or shared folder | -->

---

<!-- ## 💡 Cross-App Component Reuse Strategy

Yes — you **can and should reuse components** (especially UI and utilities) across `admin`, `client`, and `wifi` apps.

### ✅ Recommended Approach:

1. **Create a shared package**
   ```bash
   /shared/
     /components/
     /hooks/
     /utils/
     /constants/
   ```

2. **Turn it into a local npm package**  
   Add `package.json` to `/shared` and symlink or alias it in `admin`, `client`, etc.

   In each app’s `package.json`:
   ```json
   "dependencies": {
     "mboss-shared": "file:../shared"
   }
   ```

3. **Import across apps like so:**
   ```jsx
   import { LoadingIndicator, Select } from 'mboss-shared/components';
   import useFetch from 'mboss-shared/hooks/useFetch';
   ```

4. **Use Webpack/TurboRepo/Lerna** for advanced setups (optional)

--- -->

## 🔒 Security Checklist

- Always validate API inputs using Joi
- Sanitize inputs before DB insert
- Use HTTPS and secure cookies
- Use env vars for:
  - API keys
  - Base URLs
  - Domain locks (React apps)

---

## 👨‍💻 Example: When Mboss Generates `ticketService.js`

It should also create:
- `ticketController.js` (thin, just call service)
- `ticketValidator.js` (Joi schema)
- `routes/tickets.js` (with validator middleware)
- `tests/ticketService.test.js`

---