# SKILL: Architecture Rules (.agent/skills/architecture-rules)

## 📌 Objetivo
Garantir que a evolução do `PlatformSistemas` mantenha o isolamento total entre os módulos e siga o padrão "Zero-Boilerplate" para conexões com o backend.

## 🏗️ Regras de Escopo de Componentes

### 1. Libs/Shared (`src/components/shared`)
*   **Definição:** Apenas componentes **Puros** e **Burros** (Stateless ou State-local).
*   **Proibido:** Lógica de negócio, chamadas ao `api.js` ou dependência de contextos específicos de feature (ex: `useVehicles`).
*   **Exemplos:** `Button.jsx`, `ModalBase.jsx`, `Input.jsx`, `LoadingOverlay.jsx`.

### 2. Feature-Specific (`src/features/[feature]/components`)
*   **Definição:** Componentes que possuem lógica de negócio ou dependem de hooks da própria feature.
*   **Obrigatório:** Devem viver dentro da pasta da feature correspondente.
*   **Exemplos:** `VehicleCard.jsx` (Prafrot), `AttendanceFormModal.jsx` (Prafrot), `TripDetailsModal.jsx` (Prafrot).

## 🔌 Regra "Zero-Boilerplate" (API Contract)

*   **JAMAIS** crie arquivos `*Service.js` para novas funcionalidades.
*   **Sempre Use** o hook `useApiContract.js` em conjunto com o arquivo de configuração JSON correspondente (ex: `prafrotRoutes.json`).
*   **TanStack Query:** Use os poderes de cache e invalidação automática providos pelo re-query através do hook central.

## 🛡️ Muralha de Isolamento

1.  **Tokens Modulares:** Sempre injete o token correspondente ao módulo via `getTokenForModule(environment)`.
2.  **Anti-Colisão:** Antes de alterar um componente em `shared`, verifique se a mudança afeta o layout de outros módulos (RH, GR, Financeiro). Use variantes em vez de condicionais de negócio.
3.  **Tailwind v4:** Siga o padrão de camadas (`@layer components`) no `index.css` para evitar conflitos de utilitários customizados.

## ⚠️ Enforcement (Falha Crítica se Violado)
Qualquer tentativa de injetar lógica de "Prafrot" em um componente usado pelo "RH" sem o uso de variantes isoladas será considerada regressão técnica.