docs: update vue-modular-architecture.md to integrate ESLint plugin rules for modular architecture

Author: andrewmolyuk

docs/vue-modular-architecture.md

@@ -211,150 +211,9 @@ src/
         └── utilities.css         # Utility classes
 ```
 
-## Rules
+## ESLint Plugin Integration
 
-### File Organization Rules
-
-- All Vue components must use PascalCase naming (e.g., `UserForm.vue`, `ProductList.vue`)
-- All TypeScript files must use camelCase naming (e.g., `useAuth.ts`, `userApi.ts`)
-- All folders must use kebab-case naming (e.g., `user-management/`, `auth/`)
-- Each feature folder must contain an `index.ts` file as its public API
-- All `components/` folders must contain an `index.ts` file for component exports
-- The `shared/ui/` folder must contain an `index.ts` file for UI component exports
-
-### Dependency Rules
-
-- Features cannot import from other features directly
-- Features can only import from `shared/` folder
-- `shared/` folder cannot import from `features/` or `views/`
-- `app/` folder can import from `shared/` and `features/` (exception: `app/router.ts` may import feature route files to compose the global router)
-- All cross-feature communication must go through the `shared/` layer
-
-### Component Rules
-
-- All Vue components should be written as Single File Components (SFC) with `.vue` extension
-- SFC blocks must be ordered: `<script>`, `<template>`, `<style>` (at least one of script or template must exist)
-- Layout-specific components must be in `app/components/`
-- Reusable UI components (design system) must be in `shared/ui/`
-- Business components used across features must be in `shared/components/`
-- Feature-specific components must be in `features/{feature}/components/`
-- Component props must be typed with TypeScript interfaces
-
-### Service Rules
-
-- Cross-cutting services must be in `shared/services/`
-- Feature-specific services must be in `features/{feature}/services/`
-- Service files must not have "Service" suffix (e.g., `auth.ts`, not `authService.ts`)
-- Services must export named classes or named functions (avoid default exports)
-- API services must use the shared `apiClient.ts`
-
-### Store Rules
-
-- Global state must be in `shared/stores/`
-- Feature-specific state must be in `features/{feature}/stores/`
-- Store files must use Pinia composition API syntax
-- Store files must not have "Store" suffix (e.g., `auth.ts`, not `authStore.ts`)
-- Cross-cutting concerns (auth, notifications) must be in `shared/stores/`
-- Feature stores cannot import other feature stores directly
-
-### Type Rules
-
-- Global types must be in `shared/types/`
-- Feature-specific types must be in `features/{feature}/types/`
-- Type files must export interfaces and types, not classes
-- Common utility types must be in `shared/types/common.ts`
-- API response types must be in `shared/types/api.ts`
-
-### Routing Rules
-
-- Global routes must be in `app/router.ts`
-- Feature routes must be in `features/{feature}/routes.ts`
-- Feature routes must be imported and merged in `app/router.ts`
-- Route components must be lazy-loaded using dynamic imports
-- Layout selection must be defined in route `meta.layout` property
-
-### View Rules
-
-- Feature views must be in `features/{feature}/views/`
-- Global views (not feature-specific) must be in `views/` folder
-- View files must end with `View.vue` suffix
-- Views cannot contain business logic (delegate to composables/services)
-- Layout selection must be defined in route metadata, not imported directly in views
-
-### Composable Rules
-
-- Global composables must be in `shared/composables/`
-- Feature composables must be in `features/{feature}/composables/`
-- Composable files must start with `use` prefix
-- Composables must return reactive refs and computed properties
-- Composables cannot directly manipulate DOM elements
-
-### Asset Rules
-
-- Global styles must be in `assets/styles/`
-- Images must be in `assets/images/`
-- Icons must be in `assets/icons/`
-- Fonts must be in `assets/fonts/`
-- Component-specific styles must be scoped within component files
-
-### Utility Rules
-
-- Global utilities must be in `shared/utils/`
-- Feature-specific utilities must be in `features/{feature}/utils/`
-- Utility files must export pure functions without side effects
-- Utility functions must be stateless and deterministic
-
-### Middleware Rules
-
-- Global route middleware must be in `app/middleware/`
-- Feature-specific middleware must be in `features/{feature}/middleware/`
-- Middleware files must use descriptive names (e.g., `authGuard.ts`, not `guard.ts`)
-- Route guards must be registered in feature route configurations
-- Middleware must be composable and chainable
-
-### Plugin Rules
-
-- Global plugin registration must be in `app/plugins.ts`
-- Plugin configurations must be environment-aware
-- Third-party plugins must be initialized before app mounting
-- Custom plugins must follow Vue.js plugin API conventions
-- Plugin dependencies must be clearly documented
-
-### Environment/Config Rules
-
-- Environment configurations must be type-safe
-- Configuration files must use `.env` files for environment variables
-- Sensitive data must not be committed to version control
-- Different environments (dev/staging/prod) must have separate config handling
-- Runtime configuration must be validated at application startup
-- App configurations must be in `app/config/` folder
-- Config files must export typed configuration objects
-
-### Import Rules
-
-- Use absolute imports with `@/` alias for cross-layer imports and shared resources
-- Use relative imports for same-feature or nearby file imports (within 2 levels)
-- Avoid relative imports with more than 2 levels (`../../../`) - use absolute instead
-- Import from `index.ts` files when available
-- Group imports: Vue imports, third-party imports, internal imports
-- Type imports must use `import type` syntax
-- Avoid deep imports into feature internals
-
-### Export Rules
-
-- Use named exports instead of default exports for better tree-shaking
-- Internal feature helpers should not be exported from their modules
-- Types must be exported with `export type` syntax
-- Components must use default exports and be re-exported as named exports in `index.ts`
-
-### Naming Conventions
-
-- Use camelCase for variables, function names, and named exports (e.g., `fetchUsers`, `getUserById`).
-- Use PascalCase for exported types, interfaces, classes, and component identifiers (e.g., `User`, `AuthState`, `UserCard`). Avoid `I` prefixes on interfaces
-- Prefix composable functions with `use` and keep them camelCase (e.g., `useAuth`, `useProductForm`).
-- Pinia store factory exports should follow Pinia's recommendation: start with `use` and include the `Store` suffix (e.g., `useAuthStore`, `useNotificationsStore`)
-- Use UPPER_SNAKE_CASE for compile-time constants and environment keys (e.g., `API_TIMEOUT_MS`) and camelCase for runtime constants.
-- Component-emitted custom event names should use kebab-case (e.g., `item-selected`, `save:success`).
+To enforce modular architecture patterns, use the `eslint-plugin-vue-modular` plugin. This plugin provides rules to ensure that your Vue.js project adheres to the modular architecture principles outlined above.
 
 ## Conclusion