Instruction file imported from Wipse/salve-onboarding (.cursor/rules/global.mdc). Copyright stays with the author.

SALVE

A modern and fast (rolldown + oxc based) Nuxt 4 onboarding platform with TypeScript, file-based routing, state management. An employee onboarding platform using the 6C methodology.

Standards

• Use the Context7 MCP when the user requests code examples, setup or configuration steps, or library/API documentation
• Stack: Nuxt 4, Vue.js, TypeScript, TailwindCSS v4, Vue Router, Pinia, Pinia Colada
• Patterns: ALWAYS use Composition API + <script setup>, NEVER use Options API
• ALWAYS Keep types alongside your code, use TypeScript for type safety, prefer interface over type for defining types
• Keep unit and integration tests alongside the file they test: src/ui/Button.vue + src/ui/Button.spec.ts
• ALWAYS use TailwindCSS classes rather than manual CSS
• DO NOT hard code colors, use Tailwind's color system
• ONLY add meaningful comments that explain why something is done, not what it does
• Dev server is already running on http://localhost:3000 with HMR enabled. NEVER launch it yourself
• ALWAYS use named functions when declaring methods, use arrow functions only for callbacks
• ALWAYS prefer named exports over default exports
• ALWAYS add a JSDOC comment to a function

Project Structure

Keep this section up to date with the project structure. Use it as a reference to find files and directories.

EXAMPLES are there to illustrate the structure, not to be implemented as-is.

public/ # Public static files (favicon, robots.txt, static images, etc.)
├── data/ # JSON data files for front-end only mode
│   ├── organization.json # Organization configuration
│   ├── modules.json # Onboarding modules
│   ├── journeys.json # Journey definitions
│   └── checkins.json # Check-in templates
src/
├── components/ # Reusable Vue components
│   ├── ui/ # Base UI components (SalveCard, SalveButton, SalveBadge)
│   └── features/ # Feature-specific components
│       ├── modules/ # Module-related components (ModuleTile)
│       ├── journeys/ # Journey-related components (JourneyCard, JourneyProgress)
│       └── checkins/ # Check-in components (CheckinList)
├── composables/ # Composition functions (if needed in future)
├── stores/ # Pinia stores for global state
│   ├── modules.ts # Module state management
│   ├── journeys.ts # Journey state management
│   ├── checkins.ts # Check-in state management
│   ├── progress.ts # User progress tracking
│   └── org.ts # Organization configuration
├── pages/ # Page components (file-based routing)
│   ├── (home).vue # Homepage at /
│   ├── modules.(module-library).vue # Module library at /modules
│   ├── journeys.(journey-list).vue # Journey list at /journeys
│   ├── journeys.[journeyId].vue # Journey detail at /journeys/:journeyId
│   ├── checkins.(checkin-list).vue # Check-ins at /checkins
│   └── admin.(admin-panel).vue # Admin panel at /admin
├── types/ # TypeScript type definitions
│   └── index.ts # Core types (Module, Journey, Checkin, etc.)
├── utils/ # Global utility pure functions
│   ├── storage.ts # IndexedDB utilities
│   ├── ical.ts # Calendar export utilities
│   └── validate.ts # Data validation utilities
├── assets/ # Static assets processed by Vite
│   └── css/ # Global CSS
│       └── base.css # Base styles with Tailwind
└── app.vue # Root Vue component with navigation

Project Commands

Frequently used commands for this project

• pnpm run build: bundles the project for production
• pnpm run test: runs all tests
• pnpm exec vitest run <test-files>: runs one or multiple specific test files
  • add --coverage to check missing test coverage

Development Workflow

ALWAYS follow the workflow when implementing a new feature or fixing a bug in this project. This ensures consistency, quality, and maintainability of the codebase.

1. Plan your tasks, review them with user. Include tests when possible
2. Write code, following the project structure and conventions
3. ALWAYS test implementations work:
   • Write tests for logic and components
   • Use the Playwright MCP server to test like a real user
4. Stage your changes with git add once a feature works
5. Review changes and analyze the need of refactoring

Research & Documentation

• NEVER hallucinate or guess URLs
• ALWAYS try accessing the llms.txt file first to find relevant documentation. EXAMPLE: https://pinia-colada.esm.dev/llms.txt
  • If it exists, it will contain other links to the documentation for the LLMs used in this project
• ALWAYS follow existing links in table of contents or documentation indices
• Verify examples and patterns from documentation before using

MCP Servers

You have these MCP servers configured globally:

• Context7: For fetching up-to-date code examples and documentation

Note: These are user-level servers available in all your projects.