lkd-web-kit 0.10.7 → 0.10.9
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/src/distributed-skills/{create-modal-component → lkd-create-modal-component}/SKILL.md +1 -1
- package/src/distributed-skills/{create-modal-component → lkd-create-modal-component}/agents/openai.yaml +1 -1
- package/src/distributed-skills/lkd-create-nextjs-page/SKILL.md +84 -0
- package/src/distributed-skills/lkd-create-nextjs-page/agents/openai.yaml +3 -0
- package/src/distributed-skills/{create-svg-icon → lkd-create-svg-icon}/SKILL.md +1 -1
- package/src/distributed-skills/lkd-create-svg-icon/agents/openai.yaml +3 -0
- package/src/distributed-skills/{create-table-component → lkd-create-table-component}/SKILL.md +1 -1
- package/src/distributed-skills/lkd-create-table-component/agents/openai.yaml +3 -0
- package/src/distributed-skills/lkd-layout-mantine-tailwind/SKILL.md +99 -0
- package/src/distributed-skills/lkd-layout-mantine-tailwind/agents/openai.yaml +4 -0
- package/src/distributed-skills/{rhf-lkd-forms → lkd-rhf-forms}/SKILL.md +1 -1
- package/src/distributed-skills/create-nextjs-page/SKILL.md +0 -104
- package/src/distributed-skills/create-nextjs-page/agents/openai.yaml +0 -3
- package/src/distributed-skills/create-svg-icon/agents/openai.yaml +0 -3
- package/src/distributed-skills/create-table-component/agents/openai.yaml +0 -3
package/package.json
CHANGED
package/src/distributed-skills/{create-modal-component → lkd-create-modal-component}/SKILL.md
RENAMED
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
---
|
|
2
|
-
name: create-modal-component
|
|
2
|
+
name: lkd-create-modal-component
|
|
3
3
|
description: Crear modales en proyectos internos con el modal manager global de lkd-web-kit. Usar cuando Codex deba agregar, modificar o registrar modales bajo src/components/modals, envolverlos con withModalManager, elegir entre un modal interno del proyecto o Modal de Mantine, organizar el modal en carpeta propia, tipar props para showModal, actualizar dynamicModals, MyModalManagerProvider, module augmentation o loadModals.
|
|
4
4
|
---
|
|
5
5
|
|
|
@@ -1,4 +1,4 @@
|
|
|
1
1
|
interface:
|
|
2
2
|
display_name: "Create Modal Component"
|
|
3
3
|
short_description: "Create project modals with manager registration."
|
|
4
|
-
default_prompt: "Use $create-modal-component to create a modal following this project's modal manager pattern."
|
|
4
|
+
default_prompt: "Use $lkd-create-modal-component to create a modal following this project's modal manager pattern."
|
|
@@ -0,0 +1,84 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: lkd-create-nextjs-page
|
|
3
|
+
description: Crear o refactorizar paginas de Next.js App Router manteniendo el directorio app enfocado en routing y delegando la UI a componentes Page en src/components/pages. Usar al crear page.tsx, migrar vistas fuera de app, organizar subcomponentes privados, aplicar providers de pagina o normalizar nombres y rutas de componentes Page en proyectos que consumen lkd-web-kit.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Create Next.js Page
|
|
7
|
+
|
|
8
|
+
Usar este skill para crear o refactorizar paginas de Next.js App Router en proyectos que usan `lkd-web-kit`.
|
|
9
|
+
|
|
10
|
+
## Lectura obligatoria
|
|
11
|
+
|
|
12
|
+
1. Leer la documentacion relevante de Next.js antes de tocar rutas. Si existe `node_modules/next/dist/docs/`, usarla como fuente local.
|
|
13
|
+
2. Leer la documentacion local del proyecto sobre `lkd-web-kit`, componentes compartidos y patrones de UI si existe.
|
|
14
|
+
3. Revisar una pagina y un layout cercanos antes de editar para respetar aliases, providers, carga de datos, traducciones y convenciones locales.
|
|
15
|
+
|
|
16
|
+
## Regla principal
|
|
17
|
+
|
|
18
|
+
- Mantener `app` como capa de routing de Next.js.
|
|
19
|
+
- En `app`, dejar `page.tsx`, `layout.tsx` y archivos especiales de Next.js cuando correspondan: `not-found.tsx`, `loading.tsx`, `error.tsx`, `route.ts`, `template.tsx`, `default.tsx` y archivos de metadata.
|
|
20
|
+
- No colocar vistas, subcomponentes, hooks privados, helpers de UI, schemas ni columnas de tabla dentro de `app`.
|
|
21
|
+
- Colocar la UI real de cada ruta en `src/components/pages`.
|
|
22
|
+
- No crear carpetas de features genericas en la raiz de `pages`, como `components`, `widgets` o `recommendations`. Colocar las piezas privadas dentro de la Page dueña o moverlas a componentes compartidos cuando exista reutilizacion real.
|
|
23
|
+
|
|
24
|
+
## Estructura
|
|
25
|
+
|
|
26
|
+
Derivar el area desde el route group principal cuando exista. Si termina en `-layout`, quitar ese sufijo; si no hay route group, usar el primer segmento estatico de la ruta. Ignorar locale, route groups y segmentos dinamicos.
|
|
27
|
+
|
|
28
|
+
```txt
|
|
29
|
+
src/app/(dashboard-layout)/reports/page.tsx
|
|
30
|
+
src/components/pages/dashboard/reports/ReportsPage.tsx
|
|
31
|
+
|
|
32
|
+
src/app/products/[productId]/page.tsx
|
|
33
|
+
src/components/pages/products/ProductPage.tsx
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
Para una Page con piezas privadas:
|
|
37
|
+
|
|
38
|
+
```txt
|
|
39
|
+
src/components/pages/dashboard/reports/ReportsPage/index.tsx
|
|
40
|
+
src/components/pages/dashboard/reports/ReportsPage/ReportFilters.tsx
|
|
41
|
+
src/components/pages/dashboard/reports/ReportsPage/helpers.ts
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
- Usar archivo plano `{PageName}Page.tsx` si el componente es de una pieza.
|
|
45
|
+
- Usar carpeta `{PageName}Page/index.tsx` si tiene subcomponentes, helpers, schemas o piezas privadas.
|
|
46
|
+
- Usar PascalCase y el sufijo `Page` para todo componente que represente una pagina.
|
|
47
|
+
- Para rutas dinamicas, nombrar la Page por el ultimo concepto estable, no por el nombre del parametro. En rutas anidadas, reflejar los segmentos estaticos que den contexto.
|
|
48
|
+
- Si hay colision o ambiguedad real, anteponer el segmento padre.
|
|
49
|
+
- No usar `index.tsx` como Page principal directamente bajo el area o la ruta.
|
|
50
|
+
- Mover a componentes compartidos solo cuando haya mas de un consumidor real o exista un patron local establecido.
|
|
51
|
+
|
|
52
|
+
## Providers
|
|
53
|
+
|
|
54
|
+
Si el proyecto ya define `PageProviders`, envolver cada `page.tsx` con ese componente y pasar solo props soportadas y necesarias.
|
|
55
|
+
|
|
56
|
+
```tsx
|
|
57
|
+
import PageProviders from "@/app/PageProviders";
|
|
58
|
+
import ReportsPage from "@/components/pages/dashboard/reports/ReportsPage";
|
|
59
|
+
|
|
60
|
+
export default async function Page() {
|
|
61
|
+
return (
|
|
62
|
+
<PageProviders>
|
|
63
|
+
<ReportsPage />
|
|
64
|
+
</PageProviders>
|
|
65
|
+
);
|
|
66
|
+
}
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
- Adaptar los aliases, import y props al proyecto consumidor. No crear `PageProviders` solo para cumplir este skill.
|
|
70
|
+
- No usar `PageProviders` en un `layout.tsx` compartido por varias pages. Si el layout necesita un provider, importar y aplicar solamente el provider especifico del proyecto.
|
|
71
|
+
- Excepcion: un layout dedicado exclusivamente a una page puede usar `PageProviders` cuando evita duplicar providers o carga de datos de esa unica ruta.
|
|
72
|
+
- Mantener `PageProviders` en `page.tsx` cuando la pagina necesita props propias, como datos de servidor, traducciones, catalogos o precarga de modales.
|
|
73
|
+
- Mantener en `page.tsx` solo responsabilidades de entrypoint: params, metadata, fetch server-side, redirects, `notFound` y providers.
|
|
74
|
+
- No duplicar providers dentro del componente Page salvo que el proyecto lo documente.
|
|
75
|
+
|
|
76
|
+
## Checklist
|
|
77
|
+
|
|
78
|
+
- `app` queda sin UI ni logica privada de ruta.
|
|
79
|
+
- `page.tsx` importa un componente desde `src/components/pages`.
|
|
80
|
+
- El componente de pagina termina en `Page` y sus piezas privadas estan dentro de su carpeta `*Page` cuando corresponde.
|
|
81
|
+
- Se usa el provider existente del proyecto en el limite correcto: page por defecto, layout solo si es exclusivo de una unica page.
|
|
82
|
+
- No quedan imports a la ubicacion anterior de vistas.
|
|
83
|
+
- No se usa `any`.
|
|
84
|
+
- Ejecutar una verificacion focalizada para el cambio realizado.
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
---
|
|
2
|
-
name: create-svg-icon
|
|
2
|
+
name: lkd-create-svg-icon
|
|
3
3
|
description: Create SVG icon files in projects that expose SVGs from src/icons. Use when Codex must add a new icon under src/icons from user-provided SVG markup, normalize SVG colors to currentColor for Tailwind text-* styling, and export the icon alias from src/icons/index.ts.
|
|
4
4
|
---
|
|
5
5
|
|
package/src/distributed-skills/{create-table-component → lkd-create-table-component}/SKILL.md
RENAMED
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
---
|
|
2
|
-
name: create-table-component
|
|
2
|
+
name: lkd-create-table-component
|
|
3
3
|
description: Crear, extraer o refactorizar tablas/listados tabulares en proyectos internos usando el patron estricto de componente encapsulado con MyTable, TableWrapper y createColumnHelper. Usar cuando Codex deba mostrar datos en tabla, mover columnas/hook de servicio a un componente de tabla, agregar paginacion, header/footer de tabla, acciones por fila, tablas verticales o adaptar una vista para no usar MyTablePagination.
|
|
4
4
|
---
|
|
5
5
|
|
|
@@ -0,0 +1,99 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: lkd-layout-mantine-tailwind
|
|
3
|
+
description: Create or refactor React/Next.js UI layout in this project using Mantine Layout components to express visual structure and Tailwind classes for styling, spacing, responsive behavior, columns, and display properties. Use when Codex needs to create or adjust JSX with Container, Center, Flex, Group, Stack, SimpleGrid, Grid, or Paper, especially in Page or UI components that mix Mantine and Tailwind.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Layout Mantine Tailwind
|
|
7
|
+
|
|
8
|
+
Usar este skill para maquetar componentes visuales en `aestrenar-web` con Mantine y Tailwind sin mezclar responsabilidades.
|
|
9
|
+
|
|
10
|
+
## Lectura Obligatoria
|
|
11
|
+
|
|
12
|
+
1. Leer `docs/lkd-web-kit.md` y `docs/local-components.md` antes de crear componentes nuevos o reemplazar UI existente.
|
|
13
|
+
2. Si se toca una pagina o componente de Next.js, leer la documentacion local relevante en `node_modules/next/dist/docs/`.
|
|
14
|
+
3. Revisar uno o dos componentes cercanos antes de editar para seguir imports, wrappers locales y tono visual.
|
|
15
|
+
|
|
16
|
+
## Regla Principal
|
|
17
|
+
|
|
18
|
+
- Usar componentes Layout de Mantine para que el JSX deje claro el tipo de display o contenedor.
|
|
19
|
+
- Usar Tailwind para estilos, medidas, espaciado, columnas, alineacion y responsive.
|
|
20
|
+
- No usar props visuales de Mantine cuando una clase Tailwind resuelve lo mismo.
|
|
21
|
+
|
|
22
|
+
## Componentes Layout
|
|
23
|
+
|
|
24
|
+
- `Container`: contenedor de ancho de pagina o seccion.
|
|
25
|
+
- `Paper`: superficie visual cuando ya existe una tarjeta/panel real.
|
|
26
|
+
- `Stack`: layout vertical.
|
|
27
|
+
- `Group`: layout horizontal, grupos de acciones, pills, header row o wrapping.
|
|
28
|
+
- `SimpleGrid`: grillas simples responsive. Definir columnas con Tailwind: `grid-cols-1 sm:grid-cols-2 xl:grid-cols-4`.
|
|
29
|
+
- `Grid`: usar solo si hace falta una capacidad propia de `Grid` que `SimpleGrid` no cubre.
|
|
30
|
+
- `Center`: centrar contenido en ambos ejes cuando ese sea el objetivo del layout.
|
|
31
|
+
- `Flex`: usar solo cuando se requiera cambiar entre `flex-row` y `flex-col` segun responsive, con clases Tailwind.
|
|
32
|
+
|
|
33
|
+
## Tailwind
|
|
34
|
+
|
|
35
|
+
Usar clases Tailwind para:
|
|
36
|
+
|
|
37
|
+
- `m*`, `p*`, `gap-*`, `space-*`.
|
|
38
|
+
- `rounded-*`, `shadow-*`, `border`, colores y fondos.
|
|
39
|
+
- `text-*`, `font-*`, `leading-*`, `tracking-*`.
|
|
40
|
+
- `h-*`, `w-*`, `min-*`, `max-*`.
|
|
41
|
+
- `items-*`, `justify-*`, `flex-wrap`, `grid-cols-*`, `col-span-*`.
|
|
42
|
+
- Breakpoints responsive: `sm:`, `md:`, `lg:`, `xl:`.
|
|
43
|
+
|
|
44
|
+
No usar props Mantine equivalentes como `m`, `p`, `px`, `py`, `radius`, `shadow`, `w`, `h`, `gap`, `justify`, `align` o `cols` si Tailwind lo expresa claramente.
|
|
45
|
+
|
|
46
|
+
## Texto y Semantica
|
|
47
|
+
|
|
48
|
+
- No usar `Text` ni `Title` de Mantine.
|
|
49
|
+
- Usar elementos HTML semanticos (`h1`, `h2`, `p`, `section`, `article`, `footer`, `header`) cuando correspondan.
|
|
50
|
+
- Usar la prop `component` solo para cambiar semantica real: `component="main"`, `component="section"`, `component="article"`, `component="footer"`.
|
|
51
|
+
- Omitir `component` si el resultado seria `div`, porque es el default.
|
|
52
|
+
|
|
53
|
+
## Patrones
|
|
54
|
+
|
|
55
|
+
Grilla simple:
|
|
56
|
+
|
|
57
|
+
```tsx
|
|
58
|
+
<SimpleGrid className="grid-cols-1 gap-3 md:grid-cols-2 xl:grid-cols-4">
|
|
59
|
+
{items.map((item) => (
|
|
60
|
+
<Card key={item.id} data={item} />
|
|
61
|
+
))}
|
|
62
|
+
</SimpleGrid>
|
|
63
|
+
```
|
|
64
|
+
|
|
65
|
+
Layout vertical:
|
|
66
|
+
|
|
67
|
+
```tsx
|
|
68
|
+
<Stack component="section" className="w-full gap-5">
|
|
69
|
+
<Header />
|
|
70
|
+
<Content />
|
|
71
|
+
</Stack>
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
Grupo horizontal:
|
|
75
|
+
|
|
76
|
+
```tsx
|
|
77
|
+
<Group className="items-start justify-between gap-3">
|
|
78
|
+
<h2 className="font-bold text-xl">Titulo</h2>
|
|
79
|
+
<ButtonAE>Accion</ButtonAE>
|
|
80
|
+
</Group>
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
Responsive row/column:
|
|
84
|
+
|
|
85
|
+
```tsx
|
|
86
|
+
<Flex className="flex-col gap-2 md:flex-row md:items-center md:justify-between">
|
|
87
|
+
<Summary />
|
|
88
|
+
<Actions />
|
|
89
|
+
</Flex>
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
## Checklist
|
|
93
|
+
|
|
94
|
+
- El JSX muestra el layout con Mantine, no con `div` anonimos cuando hay `Stack`, `Group`, `SimpleGrid`, `Flex`, `Center`, `Container` o `Paper` aplicable.
|
|
95
|
+
- Las columnas de grilla estan en Tailwind, no en `cols`.
|
|
96
|
+
- No hay `component="div"`.
|
|
97
|
+
- No hay `Text` ni `Title` de Mantine.
|
|
98
|
+
- No se agregaron abstracciones compartidas si el componente es privado de una pagina.
|
|
99
|
+
- Se ejecuto una verificacion focalizada, como `npx biome lint <archivo>`.
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
---
|
|
2
|
-
name: rhf-
|
|
2
|
+
name: lkd-rhf-forms
|
|
3
3
|
description: Crear y revisar formularios, filtros, campos controlados, integraciones con React Hook Form, validaciones Zod, reglas superRefine, botones de submit y patrones Form* de lkd-web-kit. Usar cuando Codex trabaje en interfaces de formularios, filtros, wrappers de campos, schemas, valores iniciales, mapeo de payloads, flujos de submit o comportamiento de validación en proyectos que usan React Hook Form, Zod y lkd-web-kit.
|
|
4
4
|
---
|
|
5
5
|
|
|
@@ -1,104 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: create-nextjs-page
|
|
3
|
-
description: Crear o refactorizar paginas de Next.js App Router manteniendo app limpio y delegando la UI a componentes de pagina en src/components/pages. Usar cuando Codex deba crear page.tsx, mover UI fuera de app, organizar subcomponentes privados de una pagina, envolver paginas con PageProviders o normalizar nombres/rutas de componentes Page en proyectos que consumen lkd-web-kit.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Create Next.js Page
|
|
7
|
-
|
|
8
|
-
Usar este skill para crear o refactorizar paginas de Next.js App Router en proyectos que usan `lkd-web-kit`.
|
|
9
|
-
|
|
10
|
-
## Lectura obligatoria
|
|
11
|
-
|
|
12
|
-
1. Leer la documentacion relevante de Next.js antes de tocar rutas. Si existe `node_modules/next/dist/docs/`, usarla como fuente local.
|
|
13
|
-
2. Leer la documentacion local del proyecto sobre `lkd-web-kit`, componentes compartidos y patrones de UI si existe.
|
|
14
|
-
3. Revisar una pagina cercana antes de editar para respetar imports, providers, carga de datos, traducciones y convenciones del proyecto.
|
|
15
|
-
|
|
16
|
-
## Regla principal
|
|
17
|
-
|
|
18
|
-
- Mantener `app` como capa de routing de Next.js.
|
|
19
|
-
- En `app`, dejar solo `layout.tsx`, `page.tsx` y archivos especiales de Next.js cuando correspondan: `not-found.tsx`, `loading.tsx`, `error.tsx`, `route.ts`, `template.tsx`, `default.tsx` o metadata files.
|
|
20
|
-
- No colocar vistas, subcomponentes, hooks privados, helpers de UI, schemas, columnas de tabla ni componentes de pagina dentro de `app`.
|
|
21
|
-
- Colocar la UI real de cada ruta en `src/components/pages`.
|
|
22
|
-
|
|
23
|
-
## Estructura de pagina
|
|
24
|
-
|
|
25
|
-
Para una pagina simple:
|
|
26
|
-
|
|
27
|
-
```txt
|
|
28
|
-
src/app/[locale]/(app-layout)/development/page.tsx
|
|
29
|
-
src/components/pages/app/DevelopmentPage.tsx
|
|
30
|
-
```
|
|
31
|
-
|
|
32
|
-
Para una pagina con subcomponentes privados:
|
|
33
|
-
|
|
34
|
-
```txt
|
|
35
|
-
src/app/[locale]/(app-layout)/development/page.tsx
|
|
36
|
-
src/components/pages/app/DevelopmentPage/index.tsx
|
|
37
|
-
src/components/pages/app/DevelopmentPage/Header.tsx
|
|
38
|
-
src/components/pages/app/DevelopmentPage/helpers.ts
|
|
39
|
-
```
|
|
40
|
-
|
|
41
|
-
- Usar archivo plano `{PageName}Page.tsx` si el componente es de una pieza.
|
|
42
|
-
- Usar carpeta `{PageName}Page/index.tsx` si hay subcomponentes, helpers, schemas o piezas privadas.
|
|
43
|
-
- Mantener dentro de esa carpeta solo lo privado de esa pagina.
|
|
44
|
-
- Mover a componentes compartidos solo cuando exista reutilizacion real.
|
|
45
|
-
|
|
46
|
-
## PageProviders
|
|
47
|
-
|
|
48
|
-
Cada `page.tsx` debe retornar el componente Page envuelto con `PageProviders`.
|
|
49
|
-
|
|
50
|
-
```tsx
|
|
51
|
-
import PageProviders from "src/app/PageProviders";
|
|
52
|
-
import DevelopmentPage from "src/components/pages/app/DevelopmentPage";
|
|
53
|
-
|
|
54
|
-
const Page = async () => {
|
|
55
|
-
return (
|
|
56
|
-
<PageProviders>
|
|
57
|
-
<DevelopmentPage />
|
|
58
|
-
</PageProviders>
|
|
59
|
-
);
|
|
60
|
-
};
|
|
61
|
-
|
|
62
|
-
export default Page;
|
|
63
|
-
```
|
|
64
|
-
|
|
65
|
-
- Usar el import real de `PageProviders` del proyecto si difiere del ejemplo.
|
|
66
|
-
- Pasar a `PageProviders` solo las props que existan y sean necesarias en ese proyecto.
|
|
67
|
-
- Mantener en `page.tsx` solo responsabilidades de entrypoint: params, metadata, fetch server-side, redirects/notFound y providers.
|
|
68
|
-
- No duplicar providers dentro del componente de pagina salvo que el proyecto tenga una razon documentada.
|
|
69
|
-
|
|
70
|
-
## Mapeo de area
|
|
71
|
-
|
|
72
|
-
Derivar `{area}` desde el route group principal cuando exista:
|
|
73
|
-
|
|
74
|
-
- `(app-layout)` -> `app`
|
|
75
|
-
- `(admin-layout)` -> `admin`
|
|
76
|
-
- `(home-layout)` -> `home`
|
|
77
|
-
- `(developer-layout)` -> `developer`
|
|
78
|
-
- `(agency-layout)` -> `agency`
|
|
79
|
-
|
|
80
|
-
Regla general:
|
|
81
|
-
|
|
82
|
-
- Si el route group termina en `-layout`, quitar ese sufijo.
|
|
83
|
-
- Si no termina en `-layout`, usar el nombre limpio del group sin parentesis.
|
|
84
|
-
- Si no hay route group claro, usar el primer segmento estable de la ruta.
|
|
85
|
-
- Ignorar `[locale]`, route groups y segmentos dinamicos para elegir el area.
|
|
86
|
-
|
|
87
|
-
## Nombres
|
|
88
|
-
|
|
89
|
-
- Usar PascalCase y sufijo `Page`.
|
|
90
|
-
- Para rutas estaticas, usar el ultimo segmento estable: `(app-layout)/development/page.tsx` -> `DevelopmentPage`.
|
|
91
|
-
- Para rutas dinamicas, usar el ultimo segmento estatico util y agregar `DetailPage`: `development/[development_slug]/page.tsx` -> `DevelopmentDetailPage`.
|
|
92
|
-
- Para rutas dinamicas anidadas, preferir el ultimo segmento estatico util: `development/[development_slug]/property/[property_slug]` -> `PropertyDetailPage`.
|
|
93
|
-
- Si el nombre colisiona o pierde contexto, anteponer el segmento padre: `DevelopmentPropertyDetailPage`.
|
|
94
|
-
- No incluir nombres de route groups, `[locale]` ni nombres de parametros como `Slug` salvo que haga falta para evitar ambiguedad real.
|
|
95
|
-
|
|
96
|
-
## Checklist
|
|
97
|
-
|
|
98
|
-
- `app` queda limpio y sin UI privada.
|
|
99
|
-
- `page.tsx` importa un componente desde `src/components/pages/{area}`.
|
|
100
|
-
- `page.tsx` envuelve siempre con `PageProviders`.
|
|
101
|
-
- Las props de `PageProviders` corresponden al proyecto actual, no a otro consumidor.
|
|
102
|
-
- El componente de pagina no usa `any`.
|
|
103
|
-
- Los subcomponentes privados viven junto a la pagina, no en `app`.
|
|
104
|
-
- Se ejecuta una verificacion focalizada cuando el cambio toca codigo de aplicacion.
|