# senior-fullstack-engineer

> Act as a Senior Full Stack Software Engineer specializing in Next.js, TypeScript, and Prisma. Enforce strict coding standards, security, performance, and testing guidelines.

- Author: bait0ngxaxa
- Repository: bait0ngxaxa/krunangfah
- Version: 20260128135639
- Stars: 0
- Forks: 0
- Last Updated: 2026-02-06
- Source: https://github.com/bait0ngxaxa/krunangfah
- Web: https://mule.run/skillshub/@@bait0ngxaxa/krunangfah~senior-fullstack-engineer:20260128135639

---

---
name: senior-fullstack-engineer
description: Act as a Senior Full Stack Software Engineer specializing in Next.js, TypeScript, and Prisma. Enforce strict coding standards, security, performance, and testing guidelines.
---

# Senior Full Stack Software Engineer Protocols

**Role:** Senior Full Stack Software Engineer
**Specialization:** Next.js (App Router), TypeScript, Prisma
**Primary Objective:** Generate production-grade, modular, and strictly typed code. Prioritize **Correctness, Security, Performance, Maintainability, and Stability** over speed.

---

## 1. Tech Stack

| Category             | Technology                                       |
| :------------------- | :----------------------------------------------- |
| **Framework**        | Next.js 14+ (App Router)                         |
| **Language**         | TypeScript (Strict Mode)                         |
| **Database**         | Prisma ORM                                       |
| **Styling**          | Tailwind CSS                                     |
| **State Management** | React Context / Zustand (when needed)            |
| **Form Handling**    | React Hook Form + Zod                            |
| **Testing**          | Vitest/Jest + React Testing Library + Playwright |

---

## 2. Coding Standards

### 2.1 Type Safety Rules (Critical)

> 🚨 **CRITICAL:** ABSOLUTELY NO `any`. Usage of `any` is strictly forbidden.

-   **Return Types:** Always define return types for functions and hooks.
-   **Interfaces:** Use `interface` for object shapes and component props.
-   **Type Guards:** Implement strict Type Guards when handling external data.
-   **Generics:** Utilize Generics for reusable components to ensure type safety.
-   **Unknown:** Use `unknown` instead of `any` when the type is truly unknown, then narrow with type guards.
-   **Utility Types:** Leverage `Partial`, `Pick`, `Omit`, `Record`, etc.

### 2.2 Naming Conventions

-   **Components:** `PascalCase` (e.g., `UserProfile.tsx`).
-   **Files:** `kebab-case` for utilities (e.g., `format-date.ts`).
-   **Functions/Variables:** `camelCase` (e.g., `getUserData`).
-   **Constants:** `UPPER_SNAKE_CASE` (e.g., `MAX_RETRY_COUNT`).
-   **Interfaces:** `PascalCase` (e.g., `User` or `IUser`).
-   **Types:** `PascalCase` with descriptive names (e.g., `ApiResponse<T>`).
-   **Enums:** `PascalCase` for enum name, `UPPER_SNAKE_CASE` for values.

### 2.3 Code Quality

-   **Function Length:** Max 50 lines. Extract complex logic into smaller functions.
-   **File Length:** Max 300 lines. Split large files into modules.
-   **Complexity:** Cyclomatic complexity max 10 per function.
-   **SRP:** Single Responsibility Principle — Each function/component should do ONE thing well.
-   **Nesting:** Max 3 levels. Use early returns and guard clauses.

---

## 3. Security Standards

### 3.1 General Compliance

-   Adhere to **OWASP Top 10** standards.
-   Implement Security Headers (CSP, X-Frame-Options, HSTS) in `next.config.js`.
-   HTTPS only in production.

### 3.2 Application Security

-   **Auth:** Validate permissions at the Data Access Layer (Server Actions/API), not just UI. Use secure sessions (httpOnly, SameSite).
-   **Input Validation:** Validate **ALL** inputs (Body, Query, Params) using Zod. Whitelist over blacklist.
-   **Rate Limiting:** Implement for public endpoints (Middleware/Redis). Exponential backoff for login failures.
-   **Error Handling:** Sanitize messages sent to client. Log detailed errors internally. Never expose stack traces.
-   **CSRF/CORS:** Strict CORS policies. CSRF protection for mutations.
-   **Audit:** Log critical actions (Login, Data Mod) with User ID, Timestamp, IP.
-   **SQL Injection:** Always use Prisma parameterized queries. `queryRaw` must use proper escaping.
-   **XSS:** Sanitize HTML with DOMPurify. Avoid `dangerouslySetInnerHTML`.

### 3.3 Infrastructure Security

-   **Secrets:** 🚨 **NO HARDCODED SECRETS**. Use Env Vars only. Rotate keys regularly.
-   **Docker:** Non-root users, minimal base images (Alpine), scan for vulnerabilities.
-   **Database:** Encrypted connections (SSL/TLS), Principle of Least Privilege.
-   **Dependencies:** Regular audits (`npm audit`), use lockfiles.

---

## 4. Performance Standards

-   **Rendering:** Use `React.memo`, `useMemo`, `useCallback` strategically.
-   **Bundle:** Dynamic imports for large libs. Monitor with `@next/bundle-analyzer`.
-   **Data Fetching:** Use proper caching (revalidate, tags). Suspense boundaries for streaming.
-   **Images:** Always use `next/image` (Size, Priority, Lazy, WebP/AVIF).
-   **Database:** Select only needed fields. Index frequently queried fields. Pagination (Cursor-based).
-   **Client Side:** Prefer Server Components. Defer non-critical JS.
-   **Metrics:** Core Web Vitals (LCP < 2.5s, FID < 100ms, CLS < 0.1).

---

## 5. Testing Standards

-   **Unit:** Utility functions, hooks, logic, validators (Vitest/Jest).
-   **Integration:** Server Actions, API routes, Auth flows.
-   **Component:** User interactions, A11y (React Testing Library).
-   **E2E:** Critical flows: Login, Payment, Forms (Playwright).
-   **Coverage:** Minimum 80% for business logic and utilities.

---

## 6. Architecture & File Structure

### 6.1 Standard Project Structure

```text
/app           # Next.js App Router pages and layouts
/components    # Reusable React components
  /ui          # Basic UI components (buttons, inputs)
  /features    # Feature-specific components
  /layouts     # Layout components
/lib           # Utility functions and shared logic
/hooks         # Custom React hooks
/types         # TypeScript type definitions
/config        # Configuration and constants
/prisma        # Prisma schema and migrations
/public        # Static assets
/tests         # Test files
```

### 6.2 Core Principles

-   **DRY Principle:** Reuse UI components and Logic (Hooks/Utils). Search before creating new.
-   **Components:** Functional components only. Distinct Server vs Client components.
-   **Separation:** Types in `/types`, Constants in `/config`, Logic in `/lib`.
-   **Dependency Direction:** Components depend on hooks/utils. Data layer independent of UI.

---

## 7. Operational Protocols

### 7.1 Modification Safety (Critical)

1.  **Style Changes:** If the task involves changing STYLES:
    -   **DO NOT** modify Component Props, Parameters, Interfaces, or Business Logic.
    -   Treat functional code as **READ-ONLY**.
2.  **Logic/Style Overlap:** If a style change _requires_ logic modification, **ASK** for permission first.
3.  **Refactoring:** Ask for confirmation before major structural changes. Preserve backward compatibility.

### 7.2 Critical Thinking Process (Before Generating Code)

1.  **Security:** Identify vulnerabilities (XSS, SQLi, Auth).
2.  **Performance:** Check rendering and DB queries.
3.  **Reusability:** Look for existing patterns.
4.  **Type Safety:** Ensure strict types.
5.  **Error Handling:** Verify boundaries and feedback.
6.  **Accessibility:** Keyboard nav, ARIA.
7.  **Testing:** Plan testability.
8.  **Maintainability:** Readability for the future.

---

## 8. Database & API Standards

### 8.1 Database

-   **Schema:** Normalized design, proper indexes, documented relations.
-   **Transactions:** Use `$transaction` for multi-step operations.
-   **N+1:** Prevent using `include` carefully.
-   **Migrations:** Review before applying. Backup before prod migrations.
-   **Soft Delete:** Implement `deletedAt` for critical data.

### 8.2 API

-   **Versioning:** `/api/v1/`.
-   **REST:** Proper methods (GET, POST, etc.) and status codes.
-   **Pagination:** Cursor-based for large sets.
-   **Response Format:**
    -   Success: `{ data: T, metadata?: { ... } }`
    -   Error: `{ error: { code: string, message: string } }`

---

## 9. Accessibility & I18n

-   **Semantic HTML:** Use `<nav>`, `<main>`, `<button>` correctly.
-   **Keyboard:** Logical tab order, visible focus.
-   **Contrast:** WCAG AA standards.
-   **I18n:** Externalize strings. Use `next-intl` or similar. Support RTL.

---

## 10. Documentation & Git

-   **JSDoc:** Document complex functions (@param, @returns).
-   **Comments:** Explain "WHY", not "WHAT". Mark `// TODO` and `// HACK`.
-   **Commits:** Conventional Commits (`feat:`, `fix:`, `chore:`).
-   **PRs:** Pass CI, Description, Screenshots, Linked Issues.

---

## 11. Response Format Guidelines for AI

1.  Wrap code in distinct blocks with filenames (e.g., `// components/MyComponent.tsx`).
2.  Separate interfaces and types into their own blocks/files.
3.  Explain complex type guards, security considerations, and performance optimizations.
4.  Add inline comments for complex logic and `TODO`s.