refactor: remove deprecated Editor pattern and migrate to pure functions

.github/copilot-instructions.md

@@ -1,87 +1,115 @@
-## Language
-All code, files, commits, messages, and comments must be written in 
-English. Even if the user communicates in another language, the output 
-should always be in English. Answers should be short and avoid 
-unnecessary explanations.
-Only exceptions are:
-- UI text, such as button labels, form fields, and error messages, should be in Portuguese (pt-BR).
-
-## Code Quality
-The code must be:
-- Clean
-- Efficient
-- Following best practices
-Use descriptive and meaningful names for all variables, functions, 
-classes, and files. Organize the code into logical modules and packages, 
-following the project's directory structure.
-
-## Formatting
-Formatting should be consistent throughout the codebase. Use appropriate 
-tools such as:
-- Prettier or ESLint for JavaScript
-- Black for Python
-This ensures proper indentation, spacing, and line breaks.
-
-## Style
-Maintain a consistent style, including:
-- Formatting
-- Indentation
-- Naming conventions
-Add comments to explain complex logic or important decisions, but avoid 
-comments that state the obvious.
-
-## Documentation
-All functions and classes should include docstrings that explain their 
-purpose and usage.
+# Instructions
 
-## Testing
-For every new feature or bug fix:
-- Write unit tests that cover edge cases
-- Always update the test files in the same commit as the code changes (adding, modifying, or removing functions should be accompanied by corresponding test updates)
-- After making any change, run the `npm type-check` and `npx vitest run`, remember to wait for the output before reading the terminal
-- If any problems are detected, fix them immediately
-- For every code change (including refactoring, renaming, or moving code), always search for and update all related test files in the same commit. 
-- If a function, class, or file is changed, renamed, or removed, ensure all corresponding tests are also updated, renamed, or removed accordingly. 
-- Never leave orphaned or outdated tests after a code change.
-
-## Commits
-- Prioritize small commits (atomic)
-- Never make an empty commit (commit with no changes)
-- After some refactoring, suggest the user to commit the changes
-- After additions, refactors, removals, suggest a commit message
+## Language
+- All code, comments, documentation, and commit messages must be in English.
+- Exception: UI text (labels, error messages, etc.) may be in Portuguese (pt-BR) if required by the product.
+- Do not use Portuguese elsewhere.
 
-## Comments
-- Never add a comment in the code explaining to the developer the refactor made by the Copilot agent
+## Naming & Structure
+- Use descriptive, specific names for functions, files, and components.
+- Functions: Use action verbs (e.g., isRecipedGroupUpToDate, convertToGroups, addItemsToGroup).
+- Files: Name by specific purpose (e.g., comparison.ts, itemGroupService.ts, macroOverflow.ts).
+- Components: Use complete, descriptive names (e.g., ItemGroupEditModal, ExternalTemplateSearchModal).
+- Avoid generic names (e.g., utils.ts, helper.ts, group(), item(), data(), Editor, Service, Manager).
+- Organize code into logical modules and packages, following the project's directory structure.
 
-## Code Reviews
-All generated code should be ready for code review, meeting the project's 
-coding standards and passing all tests before submitting a pull request.
+## Clean Architecture
+- Domain Layer (`~/modules/*/domain/`): Only pure business logic, no side effects, no API/UI.
+- Application Layer (`~/modules/*/application/`): Use cases, orchestration, data conversion. No domain logic.
 
-## ESLint/Prettier Formatting and Style
+## Formatting & Style
+- Formatting must be consistent throughout the codebase. Use Prettier/ESLint for JS/TS and Black for Python to ensure proper indentation, spacing, and line breaks.
 - Always use single quotes for strings.
-- Do not use semicolons at the end of statements.
-- Use trailing commas where valid in ES5 (objects, arrays, etc.).
-- Use arrow functions with parentheses around parameters, even if there is only one.
-- Set the print width to 80 characters and tab width to 2 spaces.
-- Always use consistent indentation and formatting as enforced by Prettier and ESLint.
+- No semicolons at end of statements.
+- Use trailing commas where valid in ES5.
+- Arrow functions always with parentheses.
+- Print width: 80, tab width: 2 spaces.
+- Consistent indentation and formatting are required across all files.
+- Maintain consistent naming conventions for all identifiers.
+- Add comments to explain complex logic or important decisions, but avoid comments that state the obvious.
+- Never add a comment in the code explaining to the developer the refactor made by the Copilot agent.
 
 ## TypeScript
-- Prefer `type` aliases over `interface` for type definitions.
-- Never use the `any` type, NEVER.
-- Prefer explicit types, but function return types can be inferred.
+- Prefer `type` aliases over `interface`.
+- Never use `any`.
+- Prefer explicit types, but allow inferred return types.
 - Do not throw non-Error objects.
-- Do not use unused variables; remove or use all declared variables.
-- Use strict boolean expressions and avoid loose checks.
+- Remove or use all declared variables.
+- Use strict boolean expressions.
 
 ## JSX/Accessibility
 - Always provide `alt` text for images.
 - Follow accessibility best practices for ARIA roles and properties.
 
-## Naming and Structure
-- Use consistent naming conventions for all identifiers.
-- Do not modify `.eslintrc.cjs` or `.github/copilot-instructions.md` without user consent.
-
 ## Imports
-- Never use dynamic/inline imports (e.g., `import('~/sections/common/context/ConfirmModalContext')`). Always use static imports at the top of the file.
+- Always use static imports at the top of the file. No dynamic/inline imports.
+
+## Testing
+- Write unit tests for all new features and bug fixes, covering edge cases.
+- Update or add test files in the same commit as code changes.
+- For every code change (including refactoring, renaming, or moving code), always search for and update all related test files in the same commit.
+- If a function, class, or file is changed, renamed, or removed, ensure all corresponding tests are also updated, renamed, or removed accordingly.
+- After any change, run `npm type-check` and `npx vitest run` and fix all problems immediately.
+- Never leave orphaned or outdated tests after a code change.
+
+## Testing & Validation
+- After any major change (refactor, feature, or bug fix), always run:
+  - `npm run lint`
+  - `npm run type-check`
+  - `npm run test`
+- Fix all reported issues before committing or opening a pull request.
+
+## Commits
+- Prioritize small, atomic commits.
+- Never make an empty commit.
+- After refactoring, suggest the user to commit the changes.
+- Suggest a commit message after additions, refactors, or removals.
+
+## Code Reviews
+- All code must be ready for review, meet standards, and pass all tests before PR.
+
+## Error Handling
+- All errors in domain and application layers must use the shared error handler utility.
+- Use `handleApiError` from `~/shared/error/errorHandler` for logging, reporting, or propagating errors.
+- Never throw or log errors directly without also calling `handleApiError`.
+- Always provide context (component, operation, additionalData).
+
+**Example:**
+```typescript
+import { handleApiError } from '~/shared/error/errorHandler'
+
+if (somethingWentWrong) {
+  handleApiError(new Error('Something went wrong'), {
+    component: 'itemGroupDomain',
+    operation: 'isRecipedGroupUpToDate',
+    additionalData: { groupId, groupRecipeId },
+  })
+  throw new Error('Something went wrong')
+}
+```
+
+## Component Duplication
+- Avoid duplicating logic between components (e.g., clipboard logic in MealEditView.tsx and RecipeEditView.tsx).
+- Refactor shared logic into utilities or hooks.
 
-This file should not be modified directly without user consent.
+## SolidJS Best Practices
+- Always wrap side effects inside `createEffect` or similar reactive primitives (`createMemo`, `createResource`).
+- Never access reactive signals (`createSignal`) directly inside JSX without a function call: use `count()` instead of `count`.
+- Avoid destructuring signals, as this breaks reactivity:
+  - Do not do: `const { value } = someSignal`
+  - Do: `const [value] = someSignal`
+- Use `createMemo` to avoid recalculating expensive derived values unnecessarily.
+- Prefer `Show`, `Switch`, and `For` from `solid-js` instead of inline ternaries and array `.map()` for conditional and dynamic rendering.
+- Always clean up effects if using `onCleanup`.
+- SolidJS components must be named with CapitalCase and return JSX.
+- Do not use React hooks (`useEffect`, `useState`, etc.). Use Solid signals and effects instead.
+- Avoid spreading props directly unless necessary, as it may break reactivity.
+- Wrap event handlers with arrow functions to avoid extra re-renders unless performance dictates otherwise.
+- Prefer fine-grained reactivity over global state when possible.
+- Avoid using stores (`createStore`) for highly dynamic or nested state — prefer `createSignal` or `createMemo`.
+- When using `createStore`, prefer shallow updates or use `produce` to avoid performance bottlenecks.
+- Use `eslint-plugin-solid` to detect invalid reactivity patterns and non-idiomatic practices.
+- Follow the official `solid-start` template recommendations if using SSR or advanced routing.
+- For Solid components, use `@solidjs/testing-library`.
+- Always render components inside `render(<Component />)` and use `waitFor` for async tests.
+- Use `screen.getByRole`, `screen.queryByText`, etc., to ensure accessibility in tests.

.github/workflows/ci.yml

@@ -0,0 +1,96 @@
+name: CI
+
+on:
+  push:
+    branches:
+      - 'rc/**'
+      - stable
+  pull_request:
+    branches:
+      - 'rc/**'
+      - stable
+
+jobs:
+  type-check:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+      - name: Set up Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: 20
+      - name: Set up pnpm cache
+        uses: actions/cache@v4
+        with:
+          path: ~/.pnpm-store
+          key: ${{ runner.os }}-pnpm-store-${{ hashFiles('pnpm-lock.yaml') }}
+          restore-keys: |
+            ${{ runner.os }}-pnpm-store-
+      - name: Set up pnpm
+        uses: pnpm/action-setup@v3
+        with:
+          version: 8
+          run_install: false
+      - name: Install dependencies
+        run: pnpm install
+      - name: Type check
+        run: pnpm type-check
+
+  lint:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+      - name: Set up Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: 20
+      - name: Set up pnpm cache
+        uses: actions/cache@v4
+        with:
+          path: ~/.pnpm-store
+          key: ${{ runner.os }}-pnpm-store-${{ hashFiles('pnpm-lock.yaml') }}
+          restore-keys: |
+            ${{ runner.os }}-pnpm-store-
+      - name: Set up pnpm
+        uses: pnpm/action-setup@v3
+        with:
+          version: 8
+          run_install: false
+      - name: Install dependencies
+        run: pnpm install
+      - name: Lint
+        run: pnpm lint
+
+  test:
+    runs-on: ubuntu-latest
+    needs: [type-check, lint]
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+      - name: Set up Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: 20
+      - name: Set up pnpm cache
+        uses: actions/cache@v4
+        with:
+          path: ~/.pnpm-store
+          key: ${{ runner.os }}-pnpm-store-${{ hashFiles('pnpm-lock.yaml') }}
+          restore-keys: |
+            ${{ runner.os }}-pnpm-store-
+      - name: Set up pnpm
+        uses: pnpm/action-setup@v3
+        with:
+          version: 8
+          run_install: false
+      - name: Install dependencies
+        run: pnpm install
+      - name: Run unit tests with coverage
+        run: pnpm vitest run --coverage
+      - name: Upload coverage report
+        uses: actions/upload-artifact@v4
+        with:
+          name: coverage-report
+          path: coverage/