You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
description: "Use for all tasks. Covers local development server handling: do not start dev servers yourself by default, because the user usually has one running already. Ask the user to start the relevant server or confirm that none is running unless they explicitly request that you start it."
4
+
applyTo:
5
+
- "**/*"
6
+
---
7
+
8
+
# Local Dev Server Workflow
9
+
10
+
- Do not start local development servers by default.
11
+
- Assume the user usually already has the relevant dev server running.
12
+
- Before running commands such as `pnpm dev`, `next dev`, `vite`, `npm run dev`, `just <app>-dev`, or similar long-lived local servers, ask the user to start the server or confirm that no server is already running.
13
+
- Only start a dev server yourself when the user explicitly asks you to do that.
14
+
- When you need runtime verification and no server is available, prefer asking the user to start the correct app server instead of launching one on their behalf.
Copy file name to clipboardExpand all lines: .github/instructions/frontend-app.instructions.md
+16-1Lines changed: 16 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
---
2
2
name: "Frontend App Router Guidelines"
3
-
description: "Use when editing Next.js App Router pages, route handlers, shared frontend API helpers, or TypeScript UI code in frontend/src/. Covers file placement, backend contract preservation, typing, and frontend validation."
3
+
description: "Use when editing Next.js App Router pages, route handlers, shared frontend API helpers, or TypeScript UI code in frontend/src/. Covers file placement, backend contract preservation, typing, Tailwind token usage, and frontend validation."
4
4
applyTo:
5
5
- "frontend/src/**/*.ts"
6
6
- "frontend/src/**/*.tsx"
@@ -12,8 +12,23 @@ applyTo:
12
12
- Keep backend-facing types in `frontend/src/lib/types.ts` and shared server-side API access in `frontend/src/lib/api.ts` unless a route handler in `frontend/src/app/api/` is the correct boundary.
13
13
- Reuse the existing backend contract. This repo currently consumes `snake_case` fields from Django; do not silently rename payload keys in the frontend.
14
14
- Keep reusable components in `frontend/src/components/`, provider-style wrappers in `frontend/src/providers/`, and page composition in `frontend/src/app/`.
15
+
- Use `lucide-react` for icons in `frontend` unless the task requires a non-Lucene brand logo, product illustration, or another explicit exception.
16
+
- Use Tailwind's built-in size utilities for text size, radius, width and max-width, spacing, tracking, aspect ratio, and line-height. Do not introduce or keep custom size alias classes such as `text-2xs`, `text-button`, `rounded-panel`, `rounded-display`, `tracking-overline`, `max-w-marketing`, or `min-h-half-screen`.
17
+
- Do not use text sizes smaller than `text-xs`; if an old alias maps below `0.75rem`, replace it with `text-xs`.
18
+
- Prefer semantic Tailwind theme utility classes such as `bg-background`, `bg-page-base`, `bg-primary`, `text-content-active`, `text-content-offset`, `text-primary-foreground`, or `border-trim-offset` when the color should change with the active light or dark theme.
19
+
- Use fixed palette utility classes such as `bg-blue-50`, `text-emerald-500`, or `border-amber-400` only when the value should stay fixed across theme changes, such as data visualization, status legends, or decorative washes.
20
+
- Do not use direct CSS-variable utility syntax such as `text-[var(--color-primary)]`, `bg-(--theme-color-primary)`, `border-(--brand-border-bright)`, `text-(--font-primary)`, `rounded-[1.65rem]`, or `tracking-[0.24em]` when an existing utility class fits the need.
21
+
- Do not use slash-opacity color utilities such as `bg-primary/50`, `border-trim-offset/10`, `text-content-active/80`, or `ring-ring/40`; choose the closest existing semantic or fixed palette class instead.
22
+
- Do not add new aliases in `frontend/src/styles/theme.css` or new theme variables just to create a JSX-friendly Tailwind class. Ask the user before introducing new theme variables.
23
+
- Apply Tailwind utility classes directly on the JSX or HTML element that owns the styling. Do not add semantic helper selectors in shared CSS for combinations Tailwind can already express. Keep CSS selectors only when utilities cannot represent the behavior cleanly, such as global element rules, third-party overrides, vendor pseudos, or keyframe definitions.
15
24
- Keep Vitest files beside the route page, route-local component, or shared component they exercise instead of creating separate `__tests__/` folders.
16
25
- Add or update a colocated `*.test.ts` or `*.test.tsx` file in the same change when introducing or modifying a route handler, page, or component. If the file is only a framework passthrough, document why dedicated coverage is omitted.
26
+
- Prefer React Testing Library for frontend component tests. Test through accessible roles, labels, text alternatives, and user-visible behavior instead of implementation details or serialized markup.
27
+
- Follow React Testing Library best practices: render components like a user would experience them, prefer `screen` queries, use `user-event` for interactions, and avoid manual DOM traversal unless there is no accessible query that fits.
28
+
- Do not test product copy that is likely to change during iteration. Prefer assertions about structure, semantics, links, visibility, state, and behavior over exact headline, paragraph, button, or tagline text.
29
+
- Do not assert Tailwind or other presentational style classes in tests just to verify visual styling. Prefer behavior, accessible output, text, attributes, and state.
30
+
- Class assertions are acceptable only when the class itself carries semantic or functional meaning, such as `hidden`, stateful visibility, or another class-based contract consumed by behavior rather than presentation.
31
+
- Do not assert spacing, sizing, positioning, color, typography, radius, or shadow classes in tests. Avoid checks for classes such as `px-4`, `gap-4`, `top-4`, `inset-x-4`, `rounded-full`, or `shadow-card-strong` unless the class is part of a functional contract.
17
32
- Prefer strong explicit types over loose `Record<string, unknown>` shapes when the contract is known.
18
33
- Add JSDoc for exported utilities, route handlers, hooks, and non-trivial components when behavior is not obvious from the signature.
19
34
- For React components, providers, and App Router pages, keep the component JSDoc to a short summary paragraph and put prop descriptions on the props type or interface fields. Avoid `@param` and `@returns` tags on React components because Storybook Autodocs flattens them into a single block.
0 commit comments