Supervisor/AGENTS.md

Repository Guidelines

Project Structure & Module Organization

This repository is a Nuxt 4 application.

• pages/: route pages (for example pages/index.vue).
• components/: reusable Vue components (for example DiskSidebarWidget.vue, ApiStatusBubble.vue).
• layouts/: shared page shells (layouts/default.vue).
• server/api/: Nitro server endpoints (for example disk.get.ts, version-status.get.ts).
• assets/css/: global styles and theme tokens (main.css, malio.css).
• public/: static files served as-is.

Keep feature logic close to usage: UI in components/, page composition in pages/, backend checks in server/api/.

Build, Test, and Development Commands

Use npm scripts from package.json:

• npm run dev: start local dev server with hot reload.
• npm run build: production build (client + server).
• npm run preview: run the built app locally.
• npm run generate: static generation when needed.

There is no dedicated test script currently. At minimum, run npm run build before opening a PR.

Coding Style & Naming Conventions

• Language: TypeScript + Vue SFCs (<script setup lang="ts">).
• Indentation: 2 spaces.
• Prefer double quotes in TS files to match current codebase.
• Components: PascalCase file names (ApiStatusBubble.vue).
• API handlers: kebab-case + HTTP suffix (version-status.get.ts).
• Use Tailwind utility classes and project color tokens (text-m-error, bg-m-success, text-m-primary).

Testing Guidelines

No automated framework is configured yet. Use these checks:

• Build validation: npm run build.
• Manual smoke test: open /, verify API status cards refresh and disk sidebar renders.
• For new endpoints, validate response shape in browser/network tab or curl.

Commit & Pull Request Guidelines

Git history is not available in this workspace snapshot, so use this convention:

• Commit format: type(scope): short summary.
• Example: feat(api): add labeled multi-endpoint status check.
• Types: feat, fix, refactor, style, docs, chore.

PRs should include:

• What changed and why.
• Affected paths (e.g. server/api/version-status.get.ts).
• UI screenshots for visual changes.
• Verification steps (commands run, expected result).

Security & Configuration Notes

• Do not hardcode secrets in source.
• Prefer environment variables for private endpoints/tokens.
• Keep external API checks server-side (server/api/*) to avoid exposing sensitive details in the client.

Ne lance pas de build si je le dit pas