@mediacubeco/expo-template-fsd 2.3.1 → 2.4.0

package/src/shared/ui/templates/web-container/web-container.tsx

@@ -0,0 +1,172 @@
+import { type IterableOf, type NotNullable } from '@mediacubeco/base/types'
+import { runCallback } from '@mediacubeco/base/utils'
+import { useCallback, useState } from 'react'
+import { View } from 'react-native'
+import { WebView, type WebViewNavigation, type WebViewProps } from 'react-native-webview'
+import { useComposeRef } from '../../../hooks'
+import { Share } from '../../../services'
+import { Spinner } from '../../atoms'
+import { ScreenContainerScroll } from '../screen-container'
+import {
+  ScreenHeader,
+  ScreenHeaderIcon,
+  ScreenHeaderIconClose,
+  ScreenHeaderInfo,
+} from '../screen-header'
+import { useWebContainerStyles } from './web-container.styles'
+import { type WebContainerProps } from './web-container.types'
+
+const iconList = ['share' as const, 'refresh' as const]
+const originWhitelist = ['*']
+const injectedJavaScript =
+  'window.ReactNativeWebView.postMessage(JSON.stringify(window.location.hostname))'
+
+/**
+ * Корневой контейнер WebView для модального окна (formSheet на всю высоту). Рисует шапку
+ * с заголовком текущей страницы и кнопкой закрытия, следит за жизненным циклом загрузки:
+ * пока страница грузится — оверлей со спиннером, при провале навигации — оверлей ошибки.
+ * Все нативные пропсы `WebView` пробрасываются насквозь; свои колбэки жизненного цикла
+ * контейнер оборачивает и вызывает пользовательские после своих.
+ */
+const WebContainer = ({
+  ref: initRef,
+  uri,
+  method,
+  headers,
+  body,
+  title: initTitle = '',
+  onChange,
+}: WebContainerProps) => {
+  const hasURI = !!uri
+
+  const [title, setTitle] = useState(initTitle)
+  const [description, setDescription] = useState('')
+  const [currentUrl, setCurrentUrl] = useState(uri ?? '')
+  const [_errorCode, setErrorCode] = useState('')
+  const [_errorDescription, setErrorDescription] = useState('')
+  const [didFail, setDidFail] = useState(false)
+  const [isPending, setIsPending] = useState(true)
+  const ref = useComposeRef<WebView>(initRef)
+  const { styles } = useWebContainerStyles()
+
+  const shouldPlaceholder = !hasURI || didFail
+  const shouldSpinner = hasURI && isPending
+
+  const handleReload = useCallback(() => {
+    runCallback(ref.current?.reload)
+  }, [ref])
+
+  const handleHeaderIconPress = useCallback(
+    async (value: IterableOf<typeof iconList>) => {
+      if (value === 'refresh') {
+        handleReload()
+      } else if (value === 'share' && currentUrl) {
+        await Share.openUrl(currentUrl)
+      }
+    },
+    [currentUrl, handleReload]
+  )
+
+  const handleLoadStart: NotNullable<WebViewProps['onLoadStart']> = useCallback(() => {
+    setDidFail(false)
+  }, [])
+
+  const handleLoadEnd: NotNullable<WebViewProps['onLoadEnd']> = useCallback(() => {
+    setIsPending(false)
+  }, [])
+
+  const handleError: NotNullable<WebViewProps['onError']> = useCallback((event) => {
+    const { code, description } = event.nativeEvent
+
+    setErrorCode(String(code))
+    setErrorDescription(description)
+
+    setDidFail(true)
+    setIsPending(false)
+  }, [])
+
+  const handleHttpError: NotNullable<WebViewProps['onHttpError']> = useCallback((event) => {
+    const { statusCode, description } = event.nativeEvent
+
+    setErrorCode(String(statusCode))
+    setErrorDescription(description)
+
+    setDidFail(true)
+    setIsPending(false)
+  }, [])
+
+  const handleNavigationStateChange = useCallback(
+    (event: WebViewNavigation) => {
+      const info = event.title.split('|')
+
+      const title = info[0]?.trim()
+      const description = info[1]?.trim()
+
+      if (title) {
+        setTitle(title)
+      }
+
+      if (description) {
+        setDescription(description)
+      }
+
+      if (event.url) {
+        setCurrentUrl(event.url)
+      }
+
+      runCallback(onChange, event)
+    },
+    [onChange]
+  )
+
+  return (
+    <ScreenContainerScroll
+      variant={'secondary'}
+      wrapperStyle={styles.wrapper}
+      outerStyle={styles.outer}
+      innerStyle={styles.inner}
+      withScroll={isPending || didFail}
+      withAreaTop={false}
+      withAreaBottom={false}
+      withIndentBottom={false}
+      screenHeader={
+        <ScreenHeader
+          left={<ScreenHeaderIconClose />}
+          center={<ScreenHeaderInfo title={title} description={description} />}
+          right={<ScreenHeaderIcon value={iconList} onPress={handleHeaderIconPress} />}
+          withArea={false}
+        />
+      }
+    >
+      {hasURI && (
+        <WebView
+          ref={ref}
+          style={styles.web}
+          source={{ uri, method, headers, body }}
+          androidLayerType={'hardware'}
+          originWhitelist={originWhitelist}
+          injectedJavaScript={injectedJavaScript}
+          pullToRefreshEnabled={!isPending}
+          scalesPageToFit={false}
+          sharedCookiesEnabled={true}
+          allowsInlineMediaPlayback={true}
+          showsVerticalScrollIndicator={false}
+          mediaPlaybackRequiresUserAction={false}
+          onLoadStart={handleLoadStart}
+          onLoadEnd={handleLoadEnd}
+          onError={handleError}
+          onHttpError={handleHttpError}
+          onNavigationStateChange={handleNavigationStateChange}
+        />
+      )}
+      {shouldPlaceholder && <></>}
+      {shouldSpinner && (
+        <View style={styles.spinner}>
+          <Spinner />
+        </View>
+      )}
+    </ScreenContainerScroll>
+  )
+}
+
+export default WebContainer

package/src/shared/ui/templates/web-container/web-container.types.ts

@@ -0,0 +1,21 @@
+import { type RefObject } from 'react'
+import { type WebView, type WebViewProps } from 'react-native-webview'
+
+/**
+ * Пропсы корневого контейнера WebView: обёртка над нативными пропсами `WebView`
+ * с шапкой (заголовок текущей страницы и закрытие), индикатором загрузки и
+ * состоянием ошибки.
+ */
+type WebContainerProps = {
+  ref?: RefObject<WebView>
+  uri?: string
+  method?: string
+  headers?: object
+  body?: string
+  /** Заголовок шапки, пока страница не сообщила собственный title. */
+  title?: string
+  /** Закрытие модального окна кнопкой в шапке. */
+  onChange?: WebViewProps['onNavigationStateChange']
+}
+
+export type { WebContainerProps }

package/.claude/rules/app-routing.mdc

@@ -1,47 +0,0 @@
----
-description: Thin Expo Router layer in src/app — layout/screen and delegation to ~pages
-globs: src/app/**/*.tsx
-alwaysApply: false
----
-
-# `src/app` layer (Expo Router)
-
-Files under `src/app` only wire routes to implementation. Screen UI and business logic live in `~pages/*` (or other features), not in `app`.
-
-## `_layout.tsx`
-
-- The route’s main component is a function named **`layout`** (`Stack` / `Tabs` / `NativeTabs` config, `Stack.Screen`, options).
-- **Default**-export that function (Expo Router requirement). Follow the “exports at end” policy in `.cursor/rules/exports-at-end.mdc`: declare `function layout()` first, then `export default layout` at the bottom of the file.
-- Do not turn `_layout` into a “screen”: no content markup, only navigation and options.
-
-## Route screen files (`index.tsx`, `[param].tsx`, named routes, etc.)
-
-- The main component is a function named **`screen`**; it only renders the root screen from `~pages/...` (import a single root screen component).
-- **Default**-export it (`export default screen` at the end of the file, same export rules).
-- Do not duplicate screen markup in the route file — only a thin wrapper around the `~pages` import.
-
-## Exceptions
-
-- Special Expo Router files (`+not-found.tsx`, `+html.tsx`, etc.), if you add them, may follow a different contract — use Expo’s docs for that file.
-
-## Templates
-
-```tsx
-// _layout.tsx — navigation only
-function Layout() {
-  return <Stack>{/* Stack.Screen … */}</Stack>
-}
-
-export default Layout
-```
-
-```tsx
-// route screen
-import { SomeFeatureScreen } from '~pages/some-feature'
-
-function Screen() {
-  return <SomeFeatureScreen />
-}
-
-export default Screen
-```

package/.claude/rules/exports-at-end.mdc

@@ -1,55 +0,0 @@
----
-description: Place all export statements at the end of TS/TSX modules
-globs: **/*.{ts,tsx}
-alwaysApply: false
----
-
-# Exports at end of file
-
-All public exports from a module must appear **at the end of the file**, after imports, types, and implementation.
-
-## Rules
-
-- Do not scatter `export` on declarations through the file (e.g. `export const`, `export function`, `export class`, `export interface`). Declare first, then export in one place at the bottom.
-- Use explicit export statements: `export { … }`, `export type { … }`, and `export default …`.
-- Barrel files (`export … from '…'`) should also keep exports in the final section of the file when combined with other code (prefer dedicated barrel files with only re-exports).
-
-## Suggested order (bottom of file)
-
-1. `export { … }` — runtime named exports
-2. `export type { … }` — type-only exports
-3. `export default …` — default export last
-
-Adjust if the team prefers default first; stay consistent within the repo.
-
-## Examples
-
-```typescript
-// ❌ BAD — exports mixed with implementation
-export const someVar = 1
-export type { SomeType }
-export function someFunction() {}
-
-// ✅ GOOD — definitions first, exports last
-const someVar = 1
-type SomeType = { x: number }
-function someFunction() {}
-
-export { someVar, someFunction }
-export type { SomeType }
-export default someFunction
-```
-
-```typescript
-// ❌ BAD
-export default function SomeComponent() {
-  return null
-}
-
-// ✅ GOOD
-function SomeComponent() {
-  return null
-}
-
-export default SomeComponent
-```

package/.claude/rules/kebab-case-naming.mdc

@@ -1,29 +0,0 @@
----
-description: Enforce kebab-case naming for all files and folders
-alwaysApply: true
----
-
-# Kebab-case naming convention
-
-All files and folders must use kebab-case naming.
-
-## Rules
-
-- Use only lowercase letters, digits, and hyphens: `some-name.ts`
-- No camelCase, PascalCase, or snake_case in file/folder names
-- Dots are allowed only for file extensions and config modifiers: `eslint.config.js`, `app.json`
-
-## Examples
-
-```
-# ✅ GOOD
-src/shared/ui/
-some-entity
-some-feature
-some-widget
-
-# ❌ BAD
-SomeEntity
-some_feature
-someWidget
-```

package/.claude/rules/mediacubeco-packages.mdc

@@ -1,56 +0,0 @@
----
-description: Enforce use of @mediacubeco/* corporate packages over custom re-implementations
-alwaysApply: true
----
-
-# Use @mediacubeco/\* corporate packages
-
-All utilities, helpers, hooks, and configs that exist in `@mediacubeco/*` packages **must** be imported from there. Do not duplicate or re-implement what is already provided.
-
-## Available packages
-
-To discover what each package exports, read its DTS index:
-
-- `@mediacubeco/base` — `dist/index.d.ts`
-  - subpaths: `/helpers`, `/services`, `/types`, `/utils`
-- `@mediacubeco/base-react-native` — `dist/index.d.ts`
-  - subpaths: `/helpers`, `/hooks`, `/utils`
-
-## Rules
-
-- Before writing any utility, helper, hook, or type — read the relevant package's DTS index and check if it already exists.
-- Always import via subpath, never from the package root:
-  - `@mediacubeco/base/utils` ✅ — `@mediacubeco/base` ❌
-  - `@mediacubeco/base-react-native/hooks` ✅ — `@mediacubeco/base-react-native` ❌
-- Never copy source from a `@mediacubeco/*` package into the app.
-- ESLint, Prettier, and TypeScript configs must extend the corresponding `@mediacubeco/*` config package — do not inline equivalent rules.
-- If something is missing from a `@mediacubeco/*` package, add it there first, then import it in the app.
-
-## Examples
-
-```typescript
-// ✅ GOOD — subpath import
-import { isNull } from '@mediacubeco/base/utils'
-
-// ❌ BAD — inline
-value === null
-
-// ❌ BAD — root import
-import { isNull } from '@mediacubeco/base'
-
-// ❌ BAD — reimplementing what already exists
-function isNull(value: unknown): value is null {
-  return value === null
-}
-```
-
-```typescript
-// ✅ GOOD — subpath import
-import { useKeyboard } from '@mediacubeco/base-react-native/hooks'
-
-// ❌ BAD — root import
-import { useKeyboard } from '@mediacubeco/base-react-native'
-
-// ❌ BAD — custom re-implementation
-function useKeyboard() { /* ... */ }
-```

package/.claude/skills/generate-api-model/SKILL.md

@@ -1,230 +0,0 @@
----
-name: generate-api-model
-description: >-
-  Generates API Resource types and Entity classes from a backend JSON response.
-  Use this skill whenever the user provides a backend JSON object or API schema
-  and wants TypeScript types generated from it, asks to "add a new API model",
-  "create an entity for...", "generate resource and entity", or wants to model
-  an API response. Also use when adding new domain types to the shared API
-  library (resources/ + entities/ folders).
----
-
-# Generate API Model
-
-## What this skill does
-
-Take a **backend JSON response** (or API contract) and produce two TypeScript artifacts per domain object:
-
-1. **Resource** (`*Resource`) — a `type` that mirrors the **exact wire format** of the backend: field names are copied verbatim, including any snake_case, camelCase, kebab-case, UPPER_SNAKE_CASE, or PascalCase the backend uses.
-2. **Entity** (`*Entity`) — a `class` that maps every field to strict **camelCase** and applies project naming conventions for dates, arrays, and booleans.
-
-## Filesystem layout
-
-```
-<api-lib>/
-├── resources/
-│   ├── common.ts        ← BaseResource shared type (see references/)
-│   ├── index.ts         ← barrel re-exporting all domains
-│   └── <domain>/
-│       ├── index.ts     ← barrel for this domain
-│       └── <domain>.ts  ← Resource type(s) for this domain
-└── entities/
-    ├── common.ts        ← BaseEntity<T> base class (see references/)
-    ├── index.ts         ← barrel re-exporting all domains
-    └── <domain>/
-        ├── index.ts     ← barrel for this domain
-        └── <domain>.ts  ← Entity class for this domain
-```
-
-Domain folder names are **kebab-case**. See `references/` for complete working examples.
-
----
-
-## Step 1 — Identify domains
-
-From the backend JSON, identify independent domain objects. Exclude generic HTTP envelopes (pagination wrappers, status/error shapes) unless the user explicitly requests them.
-
-**If the user did not specify a domain name for the root object — ask before generating anything.** Never invent a domain name on your own. The root domain name determines all type names, filenames, and folder names, so it must be confirmed by the user.
-
-Every distinct nested object that carries its own data becomes its own `*Resource` + `*Entity` pair.
-
-**Where to place nested domain files:** if a nested object only appears inside one parent domain, put its files **in the parent's folder** (e.g., `brand/brand-translation.ts`, `post/post-comment.ts`, `user/user-settings.ts`). Create a separate top-level folder only when the object appears across multiple domains or is clearly a standalone concept (e.g., `stored-file` that could be attached to many entities).
-
----
-
-## Step 2 — Resource types (wire format)
-
-**Rule: Resource field names must exactly match the backend.** Copy them verbatim — do not normalize, rename, or change casing.
-
-```typescript
-// Backend sends: { "first_name": "John", "UserAge": 30, "is-active": true }
-type UserResource = BaseResource & {
-  'first_name'?: string // snake_case preserved as-is
-  'UserAge'?: number // PascalCase preserved as-is
-  'is-active'?: boolean // hyphenated keys must be quoted
-}
-```
-
-Additional rules:
-
-- All fields are **optional** (`?`) by default, unless the contract guarantees the field is always present.
-- **Do not add `id`, `createdAt` / `updatedAt`, or `isPending`** to domain Resource types — these are already declared in `BaseResource` and inherited automatically.
-- Nested objects → their own `*Resource` type in a sibling file, referenced here.
-- Arrays of objects → `ChildResource[]`.
-- String enums → `export enum` in the same file as the resource that owns the field.
-- Import `BaseResource` from `../common` (or the resources barrel).
-
----
-
-## Step 3 — Entity classes (always camelCase)
-
-Every property in the Entity must be **camelCase**, regardless of the wire-format key.
-
-### Case conversion table
-
-| Wire format      | Wire key example  | Entity field    |
-| ---------------- | ----------------- | --------------- |
-| snake_case       | `created_at`      | `createdAt`     |
-| snake_case       | `first_name`      | `firstName`     |
-| snake_case       | `number_of_likes` | `numberOfLikes` |
-| kebab-case       | `user-name`       | `userName`      |
-| kebab-case       | `post-id`         | `postId`        |
-| UPPER_SNAKE_CASE | `USER_NAME`       | `userName`      |
-| UPPER_SNAKE_CASE | `POST_ID`         | `postId`        |
-| camelCase        | `firstName`       | `firstName`     |
-| PascalCase       | `FirstName`       | `firstName`     |
-
-**Algorithm:** split the wire key on `_`, `-`, spaces, or case-boundary transitions (uppercase after lowercase) → lowercase the first segment, capitalize the first letter of every subsequent segment → join.
-
-### Entity naming conventions
-
-After converting to camelCase, apply these semantic rules:
-
-#### Dates → must end in `at`
-
-Any field that represents a point in time must end with `at`.
-
-```
-created_at    → createdAt     ✓
-updated_at    → updatedAt     ✓
-publish_date  → publishedAt   ✓  (rename: "date" → "at")
-expiry        → expiredAt     ✓  (rename: add "at" suffix)
-birth_date    → birthAt       ✓
-```
-
-#### Arrays → must end in `list`
-
-All array properties in Entity end in `list`. Strip a trailing plural `s` (when it makes the base form a clean word) before appending `List`.
-
-Resource keeps the backend wire name; Entity renames to `*List`.
-
-```
-// Resource field (wire name)         Entity field (camelCase + list)
-comments: PostCommentResource[]   →   commentList: PostCommentEntity[]
-tags: string[]                    →   tagList: string[]
-user_posts: PostResource[]        →   userPostList: PostEntity[]
-items: ItemResource[]             →   itemList: ItemEntity[]
-```
-
-If the backend already uses a `list`-style name (e.g., `comment_list`), the Entity field is simply the camelCase conversion: `commentList`.
-
-#### Booleans → should start with `is`, `has`, `did`, `can`, `should`, `was`, `will`
-
-```
-is_email_verified  → isEmailVerified  ✓
-verified           → isVerified       ✓  (add prefix when the boolean nature is clear)
-email_confirmed    → didConfirmEmail  ✓
-can_edit           → canEdit          ✓
-has_access         → hasAccess        ✓
-```
-
-### Entity constructor pattern
-
-**Do not re-declare or set `id`, `createdAt`, `updatedAt` in domain entities** — `BaseEntity` already handles them via `super(resource, context)`. Only add fields that are specific to this domain.
-
-See `references/entities/common.ts` for the full `BaseEntity<T>` implementation and `references/entities/post/post.ts` for a complete domain example (with nested entity, array `→ List`, and cross-domain reference).
-
-Default values by type:
-| Type | Default |
-|------------------|-----------------------|
-| `string` | `''` |
-| `number` | `0` |
-| `boolean` | `false` |
-| `Date` | `new Date()` |
-| nested Entity | `new ChildEntity(resource?.field, this)` |
-| array | `[]` |
-
----
-
-## Step 4 — Barrel index files
-
-Each `<domain>/` folder must have an `index.ts` re-exporting its modules. After adding a new domain, update the parent barrels too.
-
-See `references/resources/post/index.ts`, `references/entities/post/index.ts`, and `references/resources/index.ts` for examples.
-
----
-
-## Import conventions
-
-```typescript
-// Inside a Resource file:
-import { BaseResource } from '../common'
-import { ChildResource } from './child-domain'
-
-// Inside an Entity file:
-import { BaseResource, DomainResource } from '../../resources'
-import { BaseEntity } from '../common'
-import { ChildEntity } from '../child-domain'
-```
-
-Dependency direction is **entities → resources only**. Resources never import from entities.
-
----
-
-## Export style
-
-```typescript
-// Resource files:
-export type { DomainResource }
-export { DomainStatusEnum } // enums use a regular (value) export
-
-// Entity files:
-export { DomainEntity }
-
-// Index files:
-export * from './domain'
-```
-
----
-
-## Checklist before finishing
-
-- [ ] Every Resource field name matches the backend wire format exactly (no renaming)
-- [ ] Every Entity property is camelCase
-- [ ] All date fields in Entity end in `at`
-- [ ] All array fields in Entity end in `list`
-- [ ] All boolean fields in Entity start with `is` / `has` / `did` / `can` / `should` / `was` / `will`
-- [ ] Nested objects have their own `*Resource` + `*Entity` files
-- [ ] Each domain folder has an `index.ts` barrel
-- [ ] Parent `resources/index.ts` and `entities/index.ts` updated
-
----
-
-## Reference examples
-
-Read these files to understand the complete, working implementation:
-
-| File                                         | What it shows                                                                 |
-| -------------------------------------------- | ----------------------------------------------------------------------------- |
-| `references/resources/common.ts`             | `BaseResource` type — `id`, `created_at`, `updated_at`, `is_pending`          |
-| `references/entities/common.ts`              | `BaseEntity<T>` — `generateIdFactory`, `isPending` getter, `super()` contract |
-| `references/resources/post/post.ts`          | Resource with snake_case fields, nested types, cross-domain ref               |
-| `references/entities/post/post.ts`           | Entity with camelCase, `commentList`, `numberOfLikes`, nested `UserEntity`    |
-| `references/resources/post/post-comment.ts`  | Minimal nested Resource inside a parent domain folder                         |
-| `references/entities/post/post-comment.ts`   | Minimal nested Entity inside a parent domain folder                           |
-| `references/resources/user/user.ts`          | Multi-file domain Resource with two nested sub-resources                      |
-| `references/entities/user/user.ts`           | Multi-file domain Entity with two nested sub-entities                         |
-| `references/resources/user/user-settings.ts` | Leaf Resource (no further nesting)                                            |
-| `references/entities/user/user-settings.ts`  | Leaf Entity (no further nesting)                                              |
-| `references/resources/post/index.ts`         | Domain barrel — re-exports all files in the folder                            |
-| `references/resources/index.ts`              | Root barrel — re-exports all domains + common                                 |

package/.claude/skills/generate-api-model/references/resources/common.ts

@@ -1,8 +0,0 @@
-type BaseResource = {
-  id?: string
-  created_at?: Date
-  updated_at?: Date
-  is_pending?: boolean
-}
-
-export type { BaseResource }

package/.claude/skills/generate-api-model-mock/SKILL.md

@@ -1,56 +0,0 @@
----
-name: generate-api-model-mock
-description: >-
-  Generate mock data (JSON fixtures and optional helpers) aligned with API
-  resource and entity types. Use when the user asks for mocks, mock data, test
-  fixtures, or fake API responses.
----
-
-# Generate API model mocks
-
-## Purpose
-
-Produce static data that **conforms** to the project’s `*Resource` types and, when useful, round-trips through `*Entity` classes the same way production code would.
-
-## Before generating
-
-If the user has not specified **where** fixtures live or **which response shape** (single object vs array vs envelope), ask once for:
-
-- Target folder (or confirm the repo’s usual fixtures root), and
-- Whether the mock is raw JSON, a TS module that exports objects, or both.
-
-Do not invent a new root if the project already has a convention—search for existing `mock`, `fixtures`, or `__fixtures__` directories first.
-
-## Alignment with the API layer
-
-Follow the same **resources / entities** split as in `generate-api-model`:
-
-1. Read the **`{Domain}Resource`** type from `<api-lib>/resources/<domain>/<domain>.ts` (and `resources/common.ts` if the DTO extends a shared fragment).
-2. Read the **`{Domain}Entity`** class from `<api-lib>/entities/<domain>/<domain>.ts` and `entities/common.ts` if you need defaults or nesting behavior.
-3. Field names in JSON must match the **resource** type (wire names), not entity getter names—unless the user explicitly wants a camelCase transport sample that still type-checks via mapping.
-
-Generate **2–3** sample items unless the user asks otherwise. Values should be realistic and respect optional vs required fields implied by the types.
-
-## Typical artifacts
-
-### Fixture file (e.g. `resource.json` or `*.mock.json`)
-
-Valid JSON array or object matching the agreed response shape; property names match `*Resource`.
-
-### Optional helper module (e.g. `entity.ts` or `*.ts`)
-
-- Import the resource type from the API barrel or the domain module.
-- Import the fixture (JSON module or inline object) according to project bundler/tsconfig rules.
-- Export functions such as `get{Domain}MockResource()` that return a **deep clone** (e.g. `JSON.parse(JSON.stringify(data))`) when callers must not mutate shared state.
-- If tests should use entities, export helpers that return `new {Domain}Entity(resource)` from the same payload.
-
-Annotate return types with the resource type or a dedicated mock alias (e.g. `{Domain}MockResource`) if the response is a subset or wrapper around the flat resource.
-
-### Barrel
-
-If the folder has `index.ts`, re-export the helper module. Update the nearest parent barrel only if that matches existing project practice.
-
-## Constraints
-
-- Do not drift from the **current** `*Resource` definition; if the contract changed, update the types first (see `generate-api-model`), then regenerate mocks.
-- Keep skills **abstract**: no hard-coded app routes, copy-pasted production payloads, or long excerpts from `src/` in this file—describe steps and placeholders, not a snapshot of one endpoint.