fix(styles): include feature modules in Tailwind content scan

2026-09-30 12:02:08 +03:30
parent 92a3f014a6
commit fb2c394433
3 changed files with 1037 additions and 636 deletions
@@ -4,9 +4,8 @@
    <option name="autoReloadType" value="SELECTIVE" />
  </component>
  <component name="ChangeListManager">
-    <list default="true" id="bb7b50a5-be9c-4cd7-a05b-979f0e91b173" name="Changes" comment="refactor(products): organize product showcase into feature module">
+    <list default="true" id="bb7b50a5-be9c-4cd7-a05b-979f0e91b173" name="Changes" comment="fix(styles): include feature modules in Tailwind content scan">
      <change beforePath="$PROJECT_DIR$/.idea/workspace.xml" beforeDir="false" afterPath="$PROJECT_DIR$/.idea/workspace.xml" afterDir="false" />
      <change beforePath="$PROJECT_DIR$/tailwind.config.ts" beforeDir="false" afterPath="$PROJECT_DIR$/tailwind.config.ts" afterDir="false" />
    </list>
    <option name="SHOW_DIALOG" value="false" />
    <option name="HIGHLIGHT_CONFLICTS" value="true" />
@@ -97,39 +96,39 @@
    <option name="hideEmptyMiddlePackages" value="true" />
    <option name="showLibraryContents" value="true" />
  </component>
-  <component name="PropertiesComponent"><![CDATA[{
+  <component name="PropertiesComponent">{
-  "keyToString": {
+  &quot;keyToString&quot;: {
-    "ASKED_MARK_IGNORED_FILES_AS_EXCLUDED": "true",
+    &quot;ASKED_MARK_IGNORED_FILES_AS_EXCLUDED&quot;: &quot;true&quot;,
-    "ModuleVcsDetector.initialDetectionPerformed": "true",
+    &quot;ModuleVcsDetector.initialDetectionPerformed&quot;: &quot;true&quot;,
-    "RunOnceActivity.ShowReadmeOnStart": "true",
+    &quot;RunOnceActivity.ShowReadmeOnStart&quot;: &quot;true&quot;,
-    "RunOnceActivity.TerminalTabsStorage.copyFrom.TerminalArrangementManager.252": "true",
+    &quot;RunOnceActivity.TerminalTabsStorage.copyFrom.TerminalArrangementManager.252&quot;: &quot;true&quot;,
-    "RunOnceActivity.git.unshallow": "true",
+    &quot;RunOnceActivity.git.unshallow&quot;: &quot;true&quot;,
-    "RunOnceActivity.typescript.service.memoryLimit.init": "true",
+    &quot;RunOnceActivity.typescript.service.memoryLimit.init&quot;: &quot;true&quot;,
-    "codeWithMe.voiceChat.enabledByDefault": "false",
+    &quot;codeWithMe.voiceChat.enabledByDefault&quot;: &quot;false&quot;,
-    "com.intellij.ml.llm.matterhorn.ej.ui.settings.DefaultModelSelectionForGA.v1": "true",
+    &quot;com.intellij.ml.llm.matterhorn.ej.ui.settings.DefaultModelSelectionForGA.v1&quot;: &quot;true&quot;,
-    "git-widget-placeholder": "develop",
+    &quot;git-widget-placeholder&quot;: &quot;develop&quot;,
-    "javascript.nodejs.core.library.configured.version": "24.20.0",
+    &quot;javascript.nodejs.core.library.configured.version&quot;: &quot;24.20.0&quot;,
-    "javascript.nodejs.core.library.typings.version": "24.13.3",
+    &quot;javascript.nodejs.core.library.typings.version&quot;: &quot;24.13.3&quot;,
-    "javascript.preferred.runtime.type.id": "node",
+    &quot;javascript.preferred.runtime.type.id&quot;: &quot;node&quot;,
-    "js.debugger.nextJs.config.created.client": "true",
+    &quot;js.debugger.nextJs.config.created.client&quot;: &quot;true&quot;,
-    "js.debugger.nextJs.config.created.server": "true",
+    &quot;js.debugger.nextJs.config.created.server&quot;: &quot;true&quot;,
-    "junie.onboarding.icon.badge.shown": "true",
+    &quot;junie.onboarding.icon.badge.shown&quot;: &quot;true&quot;,
-    "kronk.content.tree.expanded.paths": "",
+    &quot;kronk.content.tree.expanded.paths&quot;: &quot;&quot;,
-    "last_opened_file_path": "/home/hamed/Documents/Projects/GItLabRepo/device_web",
+    &quot;last_opened_file_path&quot;: &quot;/home/hamed/Documents/Projects/GItLabRepo/device_web&quot;,
-    "node.js.detected.package.eslint": "true",
+    &quot;node.js.detected.package.eslint&quot;: &quot;true&quot;,
-    "node.js.detected.package.jshint": "true",
+    &quot;node.js.detected.package.jshint&quot;: &quot;true&quot;,
-    "node.js.detected.package.tslint": "true",
+    &quot;node.js.detected.package.tslint&quot;: &quot;true&quot;,
-    "node.js.selected.package.eslint": "(autodetect)",
+    &quot;node.js.selected.package.eslint&quot;: &quot;(autodetect)&quot;,
-    "node.js.selected.package.jshint": "",
+    &quot;node.js.selected.package.jshint&quot;: &quot;&quot;,
-    "node.js.selected.package.tslint": "(autodetect)",
+    &quot;node.js.selected.package.tslint&quot;: &quot;(autodetect)&quot;,
-    "nodejs_package_manager_path": "npm",
+    &quot;nodejs_package_manager_path&quot;: &quot;npm&quot;,
-    "prettierjs.PrettierConfiguration.Package": "/home/hamed/Documents/Projects/GIthubRepo/robot-market-landing/node_modules/prettier",
+    &quot;prettierjs.PrettierConfiguration.Package&quot;: &quot;/home/hamed/Documents/Projects/GIthubRepo/robot-market-landing/node_modules/prettier&quot;,
-    "settings.editor.selected.configurable": "settings.javascript.prettier",
+    &quot;settings.editor.selected.configurable&quot;: &quot;preferences.lookFeel&quot;,
-    "to.speed.mode.migration.done": "true",
+    &quot;to.speed.mode.migration.done&quot;: &quot;true&quot;,
-    "ts.external.directory.path": "/home/hamed/Documents/Projects/GIthubRepo/robot-market-landing/node_modules/typescript/lib",
+    &quot;ts.external.directory.path&quot;: &quot;/home/hamed/Documents/Projects/GIthubRepo/robot-market-landing/node_modules/typescript/lib&quot;,
-    "vue.rearranger.settings.migration": "true"
+    &quot;vue.rearranger.settings.migration&quot;: &quot;true&quot;
  }
-}]]></component>
+}</component>
  <component name="RecentsManager">
    <key name="MoveFile.RECENT_KEYS">
      <recent name="$PROJECT_DIR$" />
@@ -225,7 +224,7 @@
      <workItem from="1790568898974" duration="91000" />
      <workItem from="1790569032481" duration="788000" />
      <workItem from="1790573950198" duration="16000" />
-      <workItem from="1790660862579" duration="2098000" />
+      <workItem from="1790660862579" duration="6418000" />
    </task>
    <task id="LOCAL-00001" summary="update">
      <option name="closed" value="true" />
@@ -595,7 +594,15 @@
      <option name="project" value="LOCAL" />
      <updated>1790662596270</updated>
    </task>
-    <option name="localTasksCounter" value="47" />
+    <task id="LOCAL-00047" summary="fix(styles): include feature modules in Tailwind content scan">
      <option name="closed" value="true" />
      <created>1790663421347</created>
      <option name="number" value="00047" />
      <option name="presentableId" value="LOCAL-00047" />
      <option name="project" value="LOCAL" />
      <updated>1790663421347</updated>
    </task>
    <option name="localTasksCounter" value="48" />
    <servers />
  </component>
  <component name="TypeScriptGeneratedFilesManager">
@@ -626,6 +633,7 @@
    <MESSAGE value="Improve featured products layout and add support CTA" />
    <MESSAGE value="Replace desktop showcase video with scroll-driven color backgrounds" />
    <MESSAGE value="refactor(products): organize product showcase into feature module" />
-    <option name="LAST_COMMIT_MESSAGE" value="refactor(products): organize product showcase into feature module" />
+    <MESSAGE value="fix(styles): include feature modules in Tailwind content scan" />
    <option name="LAST_COMMIT_MESSAGE" value="fix(styles): include feature modules in Tailwind content scan" />
  </component>
 </project>
@@ -0,0 +1,992 @@
 # Next.js Project Development Rules
 You are working on a production Next.js application using the App Router.
 The codebase must remain:
 - simple
 - readable
 - maintainable
 - testable
 - scalable
 - junior-developer friendly
 Always prefer the simplest maintainable solution.
 Do not introduce Clean Architecture, repositories, use-cases, factories, dependency-injection systems, adapters, presenters, interactors, or unnecessary architectural layers unless they solve a real current problem.
 Avoid over-engineering.
 ---
 # Technology Stack
 Use:
 - Next.js
 - App Router
 - React
 - JavaScript and TypeScript
 - Tailwind CSS
 - Redux Toolkit
 - Vitest
 - React Testing Library
 - Playwright
 Do not introduce additional libraries without a clear reason.
 Before adding a dependency:
 1. Check whether Next.js, React, JavaScript, TypeScript, or the existing stack can solve the problem.
 2. Prefer existing project dependencies.
 3. Add a dependency only when it clearly improves maintainability, reliability, or developer experience.
 4. Briefly explain why it is necessary.
 Do not introduce Zod or another validation library unless explicitly requested.
 ---
 # App Router Only
 Use the Next.js App Router.
 Do not introduce Pages Router patterns into a new App Router project.
 Use:
 ```text
 app/
 layout.tsx
 page.tsx
 loading.tsx
 error.tsx
 not-found.tsx
 route.ts
 ```
 when appropriate.
 Use route groups for organization where helpful.
 Example:
 ```text
 app/
 ├── (public)/
 ├── (auth)/
 └── (dashboard)/
 ```
 Remember that route groups should organize the project without changing the URL.
 ---
 # Server Components by Default
 Server Components are the default.
 Do not add:
 ```ts
 "use client";
 ```
 unless the component actually requires client-side functionality.
 Client Components are appropriate when using things such as:
 - useState
 - useEffect
 - browser APIs
 - localStorage
 - event handlers
 - interactive client-side libraries
 - Redux hooks
 Keep Client Component boundaries as small as practical.
 Do not convert an entire page into a Client Component just because one small child component needs interactivity.
 Prefer:
 ```text
 Server Page
   ↓
 Server Components
   ↓
 Small Client Component
 ```
 rather than:
 ```text
 Entire Page
   ↓
 "use client"
 ```
 ---
 # General Project Structure
 Recommended structure:
 ```text
 src/
 ├── app/
 ├── features/
 ├── components/
 │   ├── ui/
 │   └── layout/
 ├── hooks/
 ├── lib/
 ├── config/
 ├── constants/
 ├── types/
 ├── utils/
 └── styles/
 ```
 Keep routing in `app/`.
 Keep business and feature-specific code in `features/`.
 Keep generic reusable UI in `components/ui/`.
 Keep infrastructure and reusable technical utilities in `lib/`.
 Do not force every project to have every directory.
 Create directories only when useful.
 ---
 # Keep Pages Thin
 `page.tsx` should primarily:
 - define the route entry
 - load route-level data when appropriate
 - compose feature components
 - pass necessary data
 Avoid putting hundreds of lines of business logic inside `page.tsx`.
 Prefer:
 ```tsx
 import { ProductList } from "@/features/products/components/ProductList";
 /**
 * Displays the product-management page.
 */
 export default async function ProductsPage() {
  return <ProductList />;
 }
 ```
 over a very large page containing:
 - data fetching
 - filtering
 - business rules
 - forms
 - modals
 - API calls
 - transformations
 - UI rendering
 all together.
 ---
 # Feature-Based Architecture
 Organize business functionality by feature.
 Example:
 ```text
 features/
 ├── auth/
 ├── products/
 ├── users/
 ├── machines/
 ├── sales/
 └── reports/
 ```
 A feature may contain:
 ```text
 features/products/
 ├── components/
 ├── hooks/
 ├── services/
 ├── store/
 ├── utils/
 ├── types/
 └── tests/
 ```
 Do not create empty folders.
 Only introduce a folder when there is actual code that belongs there.
 ---
 # Shared UI vs Feature UI
 Generic reusable components belong in:
 ```text
 components/ui/
 ```
 Examples:
 ```text
 Button
 Input
 Modal
 Table
 Card
 Badge
 Spinner
 ```
 Feature-specific components stay inside their feature.
 Examples:
 ```text
 features/products/components/ProductCard.tsx
 features/machines/components/MachineStatus.tsx
 features/sales/components/SalesTable.tsx
 ```
 Generic UI components must not contain feature-specific business logic.
 ---
 # Components
 Each component should have one clear responsibility.
 Keep components small enough to understand easily.
 Split a component when it:
 - handles unrelated responsibilities
 - contains large amounts of business logic
 - contains several independent UI sections
 - becomes difficult to test
 - becomes difficult to read
 Do not split components unnecessarily.
 Avoid creating wrappers that provide no meaningful behavior.
 ---
 # Functions
 Functions should be:
 - focused
 - descriptive
 - short enough to understand
 - easy to test
 Prefer meaningful names:
 ```ts
 calculateSaleTotal()
 formatMachineStatus()
 canUserEditProduct()
 getAvailableProducts()
 ```
 Avoid vague names:
 ```ts
 handleData()
 processStuff()
 doWork()
 helper()
 func1()
 ```
 ---
 # Function Documentation
 Write English documentation comments for important and non-trivial functions.
 Explain:
 - what the function does
 - important assumptions
 - important business behavior
 - non-obvious side effects
 Example:
 ```ts
 /**
 * Returns true when a product is enabled and still has stock available.
 */
 function canSellProduct(product: Product): boolean {
  return product.enabled && product.stock > 0;
 }
 ```
 Do not comment obvious syntax or trivial statements.
 Comments should explain intent, not translate code into English.
 ---
 # Business Logic
 Keep important business rules outside JSX when practical.
 Bad:
 ```tsx
 {machine.enabled &&
 machine.status === "online" &&
 machine.products.length > 0 &&
 user.permissions.includes("manage_machine") && (
   <ManageButton />
 )}
 ```
 Prefer:
 ```ts
 /**
 * Determines whether the current user can manage the given machine.
 */
 function canManageMachine(
  machine: Machine,
  user: User
 ): boolean {
  return (
    machine.enabled &&
    machine.status === "online" &&
    machine.products.length > 0 &&
    user.permissions.includes("manage_machine")
  );
 }
 ```
 Then:
 ```tsx
 {canManageMachine(machine, user) && <ManageButton />}
 ```
 This improves:
 - readability
 - testing
 - reuse
 - maintainability
 ---
 # Redux Toolkit
 Use Redux Toolkit as the project's global state-management solution.
 Do not store every value in Redux.
 Use local React state for local UI concerns.
 Examples:
 ```text
 modal open/close
 dropdown state
 form input
 selected tab
 temporary UI state
 ```
 Use Redux for meaningful shared application state.
 Examples:
 ```text
 authentication
 current user
 shared settings
 cross-page feature state
 global workflow state
 ```
 Keep Redux state feature-oriented.
 Example:
 ```text
 features/auth/store/authSlice.ts
 features/machines/store/machineSlice.ts
 ```
 Avoid a single giant application slice.
 ---
 # Redux in Next.js
 Redux requires Client Components.
 Keep Redux Provider boundaries explicit.
 Do not turn unrelated Server Components into Client Components just to access Redux.
 Prefer passing server-fetched data into client boundaries when practical.
 Example:
 ```text
 Server Page
   ↓
 Server data loading
   ↓
 Client Feature Component
   ↓
 Redux / interactive state
 ```
 Do not unnecessarily duplicate server data into Redux.
 Use Redux mainly for client-side shared state.
 ---
 # Data Fetching
 Prefer Server Components for server-side data fetching when appropriate.
 Example:
 ```tsx
 /**
 * Loads the available products and renders the product list.
 */
 export default async function ProductsPage() {
  const products = await getProducts();
  return <ProductList products={products} />;
 }
 ```
 Do not automatically use `useEffect` for every API request.
 Use client-side fetching only when the feature requires client-side re-fetching, polling, user-triggered requests, or interactive behavior.
 ---
 # Service Layer
 Centralize backend communication.
 Example:
 ```text
 features/products/services/productService.ts
 ```
 Example:
 ```ts
 /**
 * Loads all products from the backend.
 */
 export async function getProducts(): Promise<Product[]> {
  const response = await fetch(`${API_URL}/products`);
  if (!response.ok) {
    throw new Error("Failed to load products.");
  }
  return response.json();
 }
 ```
 Do not scatter backend URLs throughout pages and components.
 Keep HTTP concerns away from presentation components when possible.
 ---
 # Server and Client Boundaries
 Be deliberate about the boundary between server and client code.
 Server-side code may handle:
 - server-side data loading
 - secure environment variables
 - server-only APIs
 - protected backend communication
 - route handlers
 - server actions when appropriate
 Client-side code may handle:
 - interaction
 - browser APIs
 - local UI state
 - Redux
 - event listeners
 - client-only libraries
 Never expose secrets to Client Components.
 ---
 # Environment Variables
 Do not access environment variables randomly throughout the project.
 Centralize configuration when useful.
 Example:
 ```text
 config/env.ts
 ```
 Never expose secrets using:
 ```text
 NEXT_PUBLIC_*
 ```
 Only values intentionally accessible in the browser should use `NEXT_PUBLIC_`.
 ---
 # Error Handling
 Use Next.js error boundaries where appropriate.
 Examples:
 ```text
 error.tsx
 not-found.tsx
 ```
 Handle expected failures explicitly.
 Do not silently swallow errors.
 Provide user-friendly messages for recoverable failures.
 Log technical information where appropriate without exposing sensitive data to end users.
 ---
 # Loading States
 Use:
 ```text
 loading.tsx
 ```
 when route-level loading UI is appropriate.
 For local interactive operations, use explicit loading state.
 Avoid blocking unrelated parts of the UI unnecessarily.
 ---
 # State Derived from Existing State
 Do not duplicate values that can be calculated.
 Bad:
 ```ts
 const [firstName, setFirstName] = useState("");
 const [lastName, setLastName] = useState("");
 const [fullName, setFullName] = useState("");
 ```
 Prefer:
 ```ts
 const fullName = `${firstName} ${lastName}`;
 ```
 Keep state minimal.
 ---
 # useEffect
 Do not use `useEffect` to calculate values that can be derived during rendering.
 Use `useEffect` primarily for synchronizing with external systems.
 Examples:
 - WebSocket
 - browser APIs
 - subscriptions
 - external widgets
 - timers
 - event listeners
 Always clean up resources when required.
 ---
 # Avoid Deep Nesting
 Prefer guard clauses and early returns.
 Bad:
 ```ts
 if (session) {
  if (session.user) {
    if (session.user.active) {
      // logic
    }
  }
 }
 ```
 Prefer:
 ```ts
 if (!session?.user) return;
 if (!session.user.active) return;
 // Main logic
 ```
 Keep the happy path visible.
 ---
 # Avoid Magic Values
 Bad:
 ```ts
 if (status === 4) {
 }
 ```
 Prefer:
 ```ts
 if (status === MachineStatus.Offline) {
 }
 ```
 Bad:
 ```ts
 if (retryCount > 3) {
 }
 ```
 Prefer:
 ```ts
 const MAX_RETRY_COUNT = 3;
 if (retryCount > MAX_RETRY_COUNT) {
 }
 ```
 Use descriptive constants where they improve understanding.
 ---
 # Naming
 Names should explain intent.
 Prefer:
 ```ts
 selectedProduct
 currentUser
 isMachineOnline
 canEditSale
 hasAdminPermission
 shouldReloadProducts
 ```
 Avoid vague names such as:
 ```ts
 data
 info
 item2
 temp
 res2
 obj
 value1
 stuff
 ```
 unless the surrounding context makes the meaning completely obvious.
 ---
 # TypeScript and JavaScript
 JavaScript and TypeScript may coexist.
 Prefer TypeScript for new important logic where practical.
 Do not perform unnecessary project-wide TypeScript migrations during unrelated work.
 Avoid `any` where useful types can be defined.
 Keep feature-specific types close to their feature.
 Use global/shared types only when genuinely shared.
 ---
 # Tailwind CSS
 Use Tailwind CSS for styling.
 Keep styles close to components.
 Avoid creating excessive abstraction only to hide Tailwind classes.
 If a visual pattern is reused meaningfully, extract a reusable component.
 Maintain readable class structures.
 Avoid unnecessarily complex conditional class expressions.
 ---
 # Testing
 Tests are required for meaningful behavior.
 Use:
 ```text
 Vitest
 React Testing Library
 Playwright
 ```
 Use Vitest for:
 - utilities
 - business logic
 - selectors
 - reducers
 - non-UI modules
 Use React Testing Library for:
 - interactive components
 - forms
 - user behavior
 - conditional rendering
 Use Playwright for critical user flows.
 Examples:
 ```text
 login
 logout
 create product
 edit machine
 view report
 critical dashboard navigation
 ```
 Test behavior rather than implementation details.
 ---
 # Comments
 All project comments must be written in English.
 Use comments to explain:
 - intent
 - business rules
 - important decisions
 - limitations
 - unusual behavior
 - non-obvious workarounds
 Do not use excessive comments for obvious code.
 Important functions should have short English documentation comments.
 ---
 # File Organization
 Keep related code close together.
 Avoid giant generic folders containing hundreds of unrelated files.
 Bad:
 ```text
 components/
  ProductCard
  LoginForm
  SalesChart
  MachineStatus
  UserAvatar
  ReportFilter
  ...
 ```
 Prefer:
 ```text
 features/products/components/
 features/auth/components/
 features/sales/components/
 features/machines/components/
 ```
 Use global component directories only for truly shared components.
 ---
 # Refactoring Rules
 When refactoring an existing Next.js project:
 1. First understand the existing behavior.
 2. Preserve functionality unless a behavior change is requested.
 3. Identify duplicated logic.
 4. Identify large pages and components.
 5. Identify unclear naming.
 6. Identify unnecessary Client Components.
 7. Identify unnecessary `useEffect` usage.
 8. Identify duplicated state.
 9. Identify business logic buried in JSX.
 10. Identify API calls scattered across UI code.
 11. Refactor incrementally.
 12. Add or update tests.
 13. Remove dead code when safe.
 14. Do not rewrite working code only to match a theoretical architecture.
 15. Do not introduce unnecessary layers.
 16. Keep the final result understandable to junior developers.
 ---
 # New Features
 When implementing a feature:
 1. Find or create the correct feature directory.
 2. Reuse existing shared components.
 3. Keep the page thin.
 4. Prefer Server Components by default.
 5. Create Client Components only where needed.
 6. Put API communication into a service when it improves separation.
 7. Keep Redux only for meaningful shared client state.
 8. Keep business rules testable.
 9. Add appropriate tests.
 10. Keep names explicit.
 11. Avoid introducing abstractions before they are needed.
 ---
 # New Projects
 For a new Next.js project:
 - use App Router
 - use Tailwind CSS
 - configure Redux Toolkit
 - configure Vitest
 - configure React Testing Library
 - configure Playwright
 - configure linting
 - establish useful path aliases
 - create only necessary directories
 - keep Server Components as the default
 - create a clear README
 - avoid empty architecture folders
 - avoid unnecessary dependencies
 ---
 # Junior-Friendly Development Rules
 Always ask:
 "Can a junior developer understand this file without knowing hidden architectural conventions?"
 Prefer explicit code.
 Prefer:
 ```ts
 const product = await getProduct(productId);
 if (!product) {
  return null;
 }
 return product;
 ```
 over clever compressed expressions.
 Avoid:
 - excessive abstractions
 - unnecessary generics
 - complex type tricks
 - deeply nested callbacks
 - deeply nested conditions
 - complicated ternaries
 - hidden side effects
 - unnecessary factories
 - unnecessary inheritance
 - excessive indirection
 - premature reusable frameworks
 A small amount of duplication is better than a confusing abstraction.
 Refactor duplication when a clear reusable concept actually emerges.
 ---
 # Final Decision Rule
 When multiple implementations are valid, prefer the one that is:
 1. simplest
 2. easiest to read
 3. easiest to test
 4. easiest to debug
 5. easiest to extend
 6. easiest for a junior developer to understand
 Do not optimize for impressive architecture.
 Optimize for clarity, predictability, and maintainability.
@@ -1,599 +0,0 @@
 # Next.js Frontend Architecture Guide
 ## Objective
 This document defines the architecture rules for this Next.js project.
 Before implementing new features, refactoring existing code, or creating new modules, read and follow this architecture.
 The goal is to create a scalable, production-ready frontend suitable for a professional development team.
 ---
 # Technology Stack
 The project must use:
 - Next.js (App Router)
 - React
 - TypeScript
 - Redux Toolkit
 - Axios
 - Tailwind CSS
 - Ant Design
 Do not introduce alternative frameworks or libraries unless explicitly requested.
 ---
 # Architecture Pattern
 Use:
 ## Feature-Based Architecture
 Organize code around business features, not technical file types.
 Avoid:
 ```
 src/
 components/
 pages/
 services/
 utils/
 ```
 as the main structure.
 Use:
 ```
 src/
 ├── app/
 │   ├── (routes)/
 │   ├── api/
 │   ├── providers/
 │   ├── layout.tsx
 │   ├── loading.tsx
 │   ├── error.tsx
 │   └── globals.css
 │
 ├── features/
 │   ├── auth/
 │   ├── users/
 │   ├── products/
 │   ├── companies/
 │   └── ...
 │
 ├── components/
 │   ├── ui/
 │   ├── common/
 │   └── layouts/
 │
 ├── services/
 │   ├── api/
 │   ├── storage/
 │   └── websocket/
 │
 ├── store/
 │
 ├── hooks/
 │
 ├── lib/
 │
 ├── types/
 │
 ├── utils/
 │
 └── config/
 ```
 ---
 # Next.js App Router Rules
 Use Next.js App Router.
 Routes must be created using:
 ```
 app/
 ```
 Example:
 ```
 app/dashboard/page.tsx
 ```
 creates:
 ```
 /dashboard
 ```
 Do not use React Router.
 Do not manually create routing logic.
 ---
 # Server Components vs Client Components
 ## Default Rule
 All components should be Server Components by default.
 Example:
 ```tsx
 export default function UsersPage() {
    return <div>Users</div>;
 }
 ```
 ---
 ## Client Components
 Use Client Components only when required.
 Examples:
 - useState
 - useEffect
 - Redux hooks
 - Browser APIs
 - Event handlers
 Then add:
 ```tsx
 'use client';
 ```
 at the top.
 Example:
 ```tsx
 'use client';
 export default function LoginForm() {}
 ```
 Do not add `"use client"` unnecessarily.
 ---
 # Feature Structure
 Each business feature must be isolated.
 Example:
 ```
 features/auth/
 ├── api/
 │   └── auth.api.ts
 │
 ├── components/
 │   └── LoginForm.tsx
 │
 ├── hooks/
 │   └── useLogin.ts
 │
 ├── store/
 │   └── auth.slice.ts
 │
 ├── schemas/
 │   └── auth.schema.ts
 │
 ├── types.ts
 │
 └── index.ts
 ```
 Example business features:
 ```
 features/
 auth
 users
 companies
 machines
 inventory
 sales
 payments
 reports
 settings
 ```
 ---
 # Component Architecture
 ## Shared Components
 Reusable components belong here:
 ```
 components/ui/
 ```
 Examples:
 ```
 Button
 Modal
 Input
 Table
 Dropdown
 Form
 ```
 These components must not contain business logic.
 ---
 Business components belong inside features:
 Example:
 ```
 features/products/components/ProductCard.tsx
 ```
 Not:
 ```
 components/ProductCard.tsx
 ```
 ---
 # API Architecture
 All API communication must go through Axios.
 Never call Axios directly inside components.
 Wrong:
 ```tsx
 function Users() {
    axios.get('/users');
 }
 ```
 Correct:
 ```
 Component
 ↓
 Hook
 ↓
 Feature API
 ↓
 Axios Service
 ↓
 Backend API
 ```
 ---
 Axios configuration:
 ```
 services/api/
 axios.ts
 interceptors.ts
 endpoints.ts
 ```
 Example:
 ```ts
 export const api = axios.create({
    baseURL: process.env.NEXT_PUBLIC_API_URL,
 });
 ```
 ---
 # Redux Toolkit Rules
 Redux Toolkit is used only for global client state.
 Examples:
 - Authentication state
 - User preferences
 - Application settings
 - Global UI state
 Structure:
 ```
 store/
 ├── index.ts
 ├── provider.tsx
 └── slices/
 ```
 Feature state:
 ```
 features/auth/store/
 auth.slice.ts
 auth.selector.ts
 ```
 ---
 Do not store everything in Redux.
 Use:
 ```
 useState
 ```
 for local component state.
 Use Redux only for shared application state.
 ---
 # Redux Provider in Next.js
 Redux Provider must be a Client Component.
 Example:
 ```
 store/provider.tsx
 ```
 ```tsx
 'use client';
 import {Provider} from 'react-redux';
 export function ReduxProvider({children}) {
    return <Provider store={store}>{children}</Provider>;
 }
 ```
 Register it in:
 ```
 app/layout.tsx
 ```
 ---
 # TypeScript Rules
 The project must be strongly typed.
 Avoid:
 ```ts
 any;
 ```
 Prefer:
 ```ts
 interface;
 type;
 generics;
 unknown;
 ```
 Each feature owns its types:
 Example:
 ```
 features/users/types.ts
 ```
 ---
 # Tailwind CSS Rules
 Use Tailwind for:
 - Layout
 - Spacing
 - Responsive design
 - Custom styling
 Example:
 ```tsx
 <div className="flex items-center gap-4">
 ```
 Avoid unnecessary CSS files.
 Global CSS should only contain:
 - Variables
 - Theme
 - Global styles
 ---
 # Ant Design Rules
 Use Ant Design for complex UI components:
 Examples:
 - Tables
 - Forms
 - Modal
 - DatePicker
 - Dropdown
 - Pagination
 - Notification
 Use Tailwind for:
 - Layout
 - Positioning
 - Spacing
 - Responsive behavior
 Do not rewrite Ant Design components unless required.
 ---
 # Data Fetching Rules
 Follow this structure:
 ```
 Page
 ↓
 Feature Component
 ↓
 Custom Hook
 ↓
 API Layer
 ↓
 Axios
 ↓
 Backend
 ```
 Never put business API logic inside UI components.
 ---
 # Dependency Rules
 Features should remain independent.
 Wrong:
 ```
 features/products
 imports
 features/auth
 ```
 Correct:
 ```
 features/products
 ↓
 services
 components
 utils
 ```
 Shared logic belongs in:
 ```
 components/
 services/
 utils/
 lib/
 ```
 ---
 # Refactoring Rules
 When refactoring an existing project:
 1. Analyze the current structure first.
 2. Do not rewrite everything immediately.
 3. Move code gradually into feature folders.
 4. Preserve existing functionality.
 5. Improve:
    - Type safety
    - Separation of concerns
    - API abstraction
    - Component reuse
    - State management
 ---
 # Code Quality Rules
 Every file should have one responsibility.
 Avoid:
 ```
 User.tsx
 - UI
 - API
 - Validation
 - State
 ```
 Prefer:
 ```
 UserCard.tsx
 user.api.ts
 useUser.ts
 user.schema.ts
 ```
 ---
 # Final Architecture Goal
 The final project must be:
 - Scalable
 - Maintainable
 - Team-friendly
 - Type-safe
 - Easy to test
 - Ready for future features
 Always prefer clean architecture over fast implementation.
 Before creating code, understand where the code belongs in this architecture.