My claude file

claude.md

Claude Code – Project Guidelines (David’s Style)

This file defines mandatory rules for all code generation and modifications. If any rule would be violated, stop and fix the solution to fully comply with these guidelines.

---

0) Global Principles (always)

• TypeScript everywhere (backend + frontend).
• Prefer many small, short functions over a few large ones.
• NO automated tests:
  • Do NOT generate unit / integration / e2e tests.
  • Do NOT keep any test-related scaffolding, configs, or dependencies.
  • If a template generates them (e.g. __tests__, *.spec.ts, Vitest/Jest configs, Playwright, Cypress), delete them.
• Use .env files for all environment variables (API URL, UI URL, PORT, etc.).
  • Always provide .env.example (no secrets, only placeholders).
  • Never commit secrets.
• If any implementation decision or uncertainty arises, ASK BEFORE coding.
  • Examples: auth strategy, endpoint contracts, data models, permissions, UI flows, error handling, pagination, realtime needs.

---

1) Backend Rules (NestJS + MongoDB)

Required stack:

• NestJS framework
• MongoDB with Mongoose
• DTOs for all operations (create, update, queries, filters, etc.)
• Zod validation wherever it makes sense (request bodies, query params, config/env)

Project structure:

• Always split code into controller / service / utils layers.
• Controllers:
  • routing
  • DTO usage
  • validation
  • minimal orchestration only
• Business logic belongs in services.
• Shared helpers go into utils.

Validation:

• Use Zod schemas alongside DTOs.
• Provide clear, developer-friendly error messages.

Swagger (OpenAPI):

• Generate Swagger documentation.
• Keep it up to date whenever endpoints or DTOs change.
• Ensure consistency between DTOs and Swagger definitions.

README (mandatory):

• Include a README.md that lists features only, in short bullet points.
• Always keep it updated when features or endpoints change.

Testing is forbidden:

• Do not create test folders or files.
• Remove any test files generated by NestJS templates (*.spec.ts, etc.).
• No CI test steps.

---

2) Frontend Rules (Vue + Vite + Tailwind)

Required stack:

• Vue.js with Vite
• Tailwind CSS v3 (always use v3-compatible configuration)
• Pinia store
• Persistence: localStorage only

Folder structure (mandatory):

• All Vue components go into src/components
• Page-level components: src/components/pages
• Feature / UI components:
  • src/components/<feature-name>/...
  • Example:
    • src/components/auth/LoginForm.vue
    • src/components/profile/ProfileCard.vue

Styling:

• Write as little custom CSS as possible.
• Prefer Tailwind utilities everywhere.
• Apply a global Tailwind theme for the entire project.
  • Customize the theme if needed (colors, spacing, fonts), instead of scattered CSS.

Testing is forbidden:

• Do not generate Vitest/Jest/Cypress/Playwright configs or files.
• Remove any testing setup coming from starter templates.

---

3) .env Conventions (all projects)

• Always use .env and .env.example.
• Typical backend variables:
  • PORT
  • MONGODB_URI
  • UI_URL (for CORS if needed)
• Typical frontend variables:
  • VITE_API_URL
• Keep naming consistent and document required variables briefly in the README.

---

4) Workflow Rules (mandatory before coding)

For every task:

1. Describe in 3–7 bullet points what will be created or changed (files, modules, endpoints).
2. If any decision point exists, stop and ask for clarification before implementation.
3. After implementation:
   • Remove all test-related artifacts.
   • Update Swagger (backend).
   • Update the README feature list.
   • Verify folder structure (especially frontend components).

---