create-tigra 2.4.0 → 2.6.0

package/bin/create-tigra.js

@@ -12,6 +12,9 @@ import crypto from 'crypto';
 const __filename = fileURLToPath(import.meta.url);
 const __dirname = path.dirname(__filename);
 
+const packageJson = JSON.parse(fs.readFileSync(path.join(__dirname, '..', 'package.json'), 'utf-8'));
+const VERSION = packageJson.version;
+
 const TEMPLATE_DIR = path.join(__dirname, '..', 'template');
 
 // Files that contain template variables and need replacement
@@ -126,11 +129,11 @@ async function main() {
   program
     .name('create-tigra')
     .description('Create a production-ready full-stack app with Next.js + Fastify + Prisma + Redis')
-    .version('2.1.0')
+    .version(VERSION)
     .argument('[project-name]', 'Name for your new project')
     .action(async (projectNameArg) => {
       console.log();
-      console.log(chalk.bold('  Create Tigra') + chalk.dim(' v2.1.0'));
+      console.log(chalk.bold('  Create Tigra') + chalk.dim(` v${VERSION}`));
       console.log();
 
       let projectName = projectNameArg;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-tigra",
-  "version": "2.4.0",
+  "version": "2.6.0",
   "type": "module",
   "description": "Create a production-ready full-stack app with Next.js 16 + Fastify 5 + Prisma + Redis",
   "bin": {

package/template/_claude/rules/client/01-project-structure.md

@@ -32,6 +32,12 @@ src/
 │       ├── store/          # <domain>Slice.ts (if needed)
 │       ├── types/          # <domain>.types.ts
 │       └── actions/        # <domain>.actions.ts (Server Actions)
+├── styles/
+│   └── themes/             # Color theme presets (switch in globals.css import)
+│       ├── warm-orange.css  # Default — earthy, warm
+│       ├── electric-indigo.css
+│       ├── ocean-teal.css
+│       └── rose-pink.css
 ├── hooks/                  # Global hooks (useDebounce, useLocalStorage, useMediaQuery)
 ├── lib/
 │   ├── api/                # axios.config.ts, api.types.ts

package/template/_claude/rules/client/04-design-system.md

@@ -14,60 +14,83 @@ Clean, airy, "expensive" look inspired by Linear, Vercel, Stripe, Arc. Every vis
 
 This project uses **Tailwind CSS v4** with **OKLCH color space** and the `@theme inline` directive (not the legacy `tailwind.config.ts`).
 
+**Key differences from Tailwind v3:**
+- No `tailwind.config.ts` — all config is CSS-based via `@theme inline`
+- Colors use **OKLCH** (perceptually uniform) not HSL
+- `@custom-variant dark` replaces `darkMode: 'class'`
+- No `@layer base { :root { } }` — variables defined on `:root` via theme preset files
+
+---
+
+## Theme Preset System (Color Management)
+
+**ALL color variables live in theme preset files, NOT in `globals.css`.** This is the single source of truth for the entire app's color palette.
+
+### How It Works
+
+```
+src/
+├── app/globals.css                    ← imports ONE theme preset (switch here)
+└── styles/themes/
+    ├── warm-orange.css                ← Earthy, warm (default)
+    ├── electric-indigo.css            ← Modern, bold, tech-forward
+    ├── ocean-teal.css                 ← Calm, professional
+    └── rose-pink.css                  ← Elegant, creative
+```
+
+`globals.css` imports the active theme via a single line:
+
 ```css
-/* app/globals.css */
-@import "tailwindcss";
-@import "tw-animate-css";
-@import "shadcn/tailwind.css";
-
-@custom-variant dark (&:is(.dark *));
-
-@theme inline {
-  --color-background: var(--background);
-  --color-foreground: var(--foreground);
-  --font-sans: var(--font-geist-sans);
-  --font-mono: var(--font-geist-mono);
-  /* ... maps all semantic tokens to Tailwind */
-}
+@import "../styles/themes/warm-orange.css";
+```
+
+**To switch the entire palette**: change that ONE import line. That's it. Every color in the app updates instantly — light mode, dark mode, charts, sidebar, everything.
+
+### Theme Preset Structure
+
+Each preset file defines ALL semantic color variables for both `:root` (light) and `.dark` (dark mode):
 
+```css
 :root {
   --radius: 0.625rem;
-  --background: oklch(1 0 0);
-  --foreground: oklch(0.145 0 0);
-  --primary: oklch(0.45 0.2 260);
-  --primary-foreground: oklch(0.985 0 0);
-  --secondary: oklch(0.97 0 0);
-  --secondary-foreground: oklch(0.205 0 0);
-  --muted: oklch(0.97 0 0);
-  --muted-foreground: oklch(0.556 0 0);
-  --accent: oklch(0.97 0 0);
-  --accent-foreground: oklch(0.205 0 0);
-  --destructive: oklch(0.577 0.245 27.325);
-  --border: oklch(0.922 0 0);
-  --input: oklch(0.922 0 0);
-  --ring: oklch(0.45 0.2 260);
-  --success: oklch(0.52 0.17 155);
-  --success-foreground: oklch(1 0 0);
-  --warning: oklch(0.75 0.18 75);
-  --warning-foreground: oklch(0.2 0 0);
-  --info: oklch(0.55 0.15 240);
-  --info-foreground: oklch(1 0 0);
-  --chart-1 through --chart-5  /* Data visualization colors */
-  --sidebar, --sidebar-foreground, etc.  /* Sidebar-specific tokens */
+  --background: oklch(...);
+  --foreground: oklch(...);
+  --primary: oklch(...);
+  --primary-foreground: oklch(...);
+  /* ... all ~35 semantic tokens */
 }
 
 .dark {
-  --background: oklch(0.145 0 0);
-  --foreground: oklch(0.985 0 0);
+  --background: oklch(...);
+  --foreground: oklch(...);
+  --primary: oklch(...);
   /* ... dark mode overrides for all tokens */
 }
 ```
 
-**Key differences from Tailwind v3:**
-- No `tailwind.config.ts` — all config is CSS-based via `@theme inline`
-- Colors use **OKLCH** (perceptually uniform) not HSL
-- `@custom-variant dark` replaces `darkMode: 'class'`
-- No `@layer base { :root { } }` — variables defined directly on `:root`
+### Creating a Custom Theme
+
+1. Copy any existing preset file (e.g., `warm-orange.css`)
+2. Rename it (e.g., `my-brand.css`)
+3. Edit the OKLCH values to match your brand palette
+4. Update the import in `globals.css`: `@import "../styles/themes/my-brand.css";`
+
+### Available Presets
+
+| Preset | Accent | Vibe | Inspired by |
+|--------|--------|------|-------------|
+| `warm-orange.css` | Terracotta orange | Earthy, warm, approachable | Claude |
+| `electric-indigo.css` | Deep indigo-violet | Modern, bold, tech-forward | Linear, Figma |
+| `ocean-teal.css` | Deep teal-cyan | Calm, professional, trustworthy | Stripe, Vercel |
+| `rose-pink.css` | Soft rose-magenta | Elegant, creative, premium | Dribbble, Notion |
+
+### CRITICAL RULES — Color Management
+
+1. **NEVER add or modify color variables directly in `globals.css`.** All `:root` and `.dark` color variables belong in the active theme preset file only.
+2. **NEVER hardcode OKLCH/hex/rgb values in components.** Always use semantic tokens (`bg-primary`, `text-foreground`).
+3. **To change the brand palette**: switch the import in `globals.css` or edit the active preset file. Never scatter color values across multiple files.
+4. **New semantic tokens**: If you need a new color token (rare), add it to ALL preset files to keep them in sync.
+5. **The `@theme inline` block in `globals.css` maps CSS vars to Tailwind** — it does NOT define colors. Colors come from the preset.
 
 ---
 
@@ -117,7 +140,7 @@ This project uses **Tailwind CSS v4** with **OKLCH color space** and the `@theme
 1. **Never hardcode**: No `bg-blue-500`, no `bg-[#3b82f6]`, no `style={{ color }}`. Always semantic tokens.
 2. **Semantic names by purpose**: `bg-destructive` not `bg-red`.
 3. **Always pair bg + foreground**: `bg-primary text-primary-foreground` for contrast.
-4. **Single source of truth**: Change colors only in `globals.css` variables.
+4. **Single source of truth**: Change colors ONLY in the active theme preset file (`src/styles/themes/*.css`). Never in `globals.css`, never in components.
 5. **90% monochrome**: 90% of UI uses `background`, `foreground`, `muted`, `border`. Color is the exception.
 6. **Opacity for hierarchy**: Use `bg-primary/10`, `bg-primary/5` for tinted backgrounds.
 

package/template/_claude/rules/client/core.md

@@ -9,7 +9,7 @@
 | Creating files, folders, feature modules | `01-project-structure.md` |
 | Building components, writing types/interfaces | `02-components-and-types.md` |
 | Fetching data, managing state, calling APIs, forms | `03-data-and-state.md` |
-| Choosing colors, styling, typography, spacing, motion | `04-design-system.md` |
+| Choosing colors, styling, typography, spacing, motion, **theme presets** | `04-design-system.md` |
 | Auth tokens, env vars, security headers | `05-security.md` |
 | UX psychology, cognitive load, a11y, performance | `06-ux-checklist.md` |
 
@@ -36,8 +36,9 @@ State: Server data (SSR) → Server Components
 1. **Mobile-first**: All Tailwind classes start at mobile. Desktop is the enhancement (`md:`, `lg:`). Touch targets min 44x44px. No functionality behind hover-only states.
 2. **Server Components by default.** Only add `'use client'` when you need hooks, state, or event handlers.
 3. **Component limits**: Max 250 lines, max 5 props, max 3 JSX nesting levels.
-4. **No hardcoded colors**: Use Tailwind semantic tokens (`bg-primary`, `text-foreground`). Never hex/rgb.
+4. **No hardcoded colors**: Use Tailwind semantic tokens (`bg-primary`, `text-foreground`). Never hex/rgb. **All color variables live in theme preset files (`src/styles/themes/*.css`), NOT in `globals.css` or components.** To change the palette, switch the import in `globals.css` or edit the active preset. Read `04-design-system.md` → "Theme Preset System" for details.
 5. **No inline styles**: Tailwind only. Use `cn()` for conditional classes.
 6. **Import order**: React/Next → third-party → UI → local → hooks → services → types → utils.
 7. **Forms**: Validate with Zod. Always validate client-side AND server-side.
 8. **Security**: Never inject raw HTML without sanitization. Never prefix secrets with `NEXT_PUBLIC_`.
+9. **Deployment**: Never remove `output: "standalone"` from `next.config.ts`. When adding `NEXT_PUBLIC_*` env vars, also add them as `ARG` + `ENV` in the Dockerfile builder stage. Read `07-deployment.md` for details.

package/template/_claude/rules/global/completion-reports.md

@@ -0,0 +1,178 @@
+> **SCOPE**: These rules apply to the **entire workspace** (server + client). Always active.
+
+# Task Completion Reports
+
+When you finish a task, phase, or multi-step implementation, you MUST provide a structured completion report. Freeform paragraphs like "Fixed issues and completed remaining tasks" are not acceptable. The report must give the user a clear, scannable picture of everything that changed, why, and what to do next.
+
+---
+
+## When to Report
+
+| Situation | Report required? |
+|-----------|-----------------|
+| Completed a full task or feature | **Yes — Full Report** |
+| Completed a phase in a multi-phase plan | **Yes — Phase Report** (subset of Full Report) |
+| Fixed a bug | **Yes — Bug Fix Report** |
+| Small config change, typo fix, single-file edit | **No** — a 1-2 sentence explanation is fine |
+
+---
+
+## Full Report Template
+
+Use this structure after completing a feature or multi-phase task. Omit sections that don't apply (e.g., skip "Database Changes" if no migrations were created), but never omit "Files Changed" or "How to Test".
+
+```
+## Summary
+[1-3 sentences: what was built/changed and why]
+
+## Files Changed
+
+### Created
+- `path/to/file.ts` — [purpose: what this file does]
+
+### Modified
+- `path/to/file.ts` — [what changed and why]
+
+### Deleted
+- `path/to/file.ts` — [why it was removed]
+
+## New API Endpoints (if applicable)
+| Method | Path | Auth | Description |
+|--------|------|------|-------------|
+
+## Database Changes (if applicable)
+- Migration: `YYYYMMDD_name` — [what it does]
+- New tables: [list]
+- Modified tables: [what changed]
+- Indexes added: [list]
+
+## Environment Variables (if applicable)
+| Variable | Required | Where | Description |
+|----------|----------|-------|-------------|
+[Where = .env / .env.example / Dockerfile ARG / Coolify]
+
+## Dependencies Added (if applicable)
+| Package | Purpose |
+|---------|---------|
+- Note if any require system-level installs (apk add)
+
+## Key Decisions & Trade-offs
+[Explain non-obvious choices. Why was approach A chosen over B? What assumptions were made? What are the limitations?]
+
+## Deployment & Production Impact (if applicable)
+[This section is REQUIRED whenever changes affect deployment, infrastructure, or production behavior. Include ALL that apply:]
+
+### Dockerfile Changes
+- [New ARG/ENV added, new COPY lines, new apk packages, port changes, etc.]
+
+### Environment / Coolify Configuration
+- [New env vars that must be set in Coolify/hosting platform]
+- [Build arguments that must be added]
+- [Volume mounts needed]
+
+### Database Migration Required
+- [Migration name and what it does]
+- [Must run `prisma migrate deploy` before/after deploying]
+- [Any data migration or backfill needed]
+
+### Infrastructure Changes
+- [New external services required (Redis, S3, third-party APIs)]
+- [DNS/domain changes needed]
+- [SSL/certificate changes]
+- [New cron jobs or background workers]
+
+### Deployment Order
+- [If server and client must be deployed in a specific order, state it]
+- [If a migration must run before the new code deploys, state it]
+
+### Rollback Plan
+- [What happens if this deployment fails — is it safe to roll back?]
+- [Are the database changes backwards-compatible with the previous code version?]
+
+## Breaking Changes (if any)
+- [What breaks, what to update, and how]
+
+## Manual Steps Required
+1. [Ordered list of things the user must do before this works]
+   - e.g., "Add GEMINI_API_KEY to .env"
+   - e.g., "Run npm run prisma:migrate dev"
+
+## How to Test
+1. [Step-by-step verification the user can follow]
+   - Be specific: exact commands, exact Postman steps, exact URLs
+   - Include expected responses where helpful
+
+## Known Limitations / TODOs (if any)
+- [Things not yet implemented, edge cases not handled, future improvements needed]
+```
+
+---
+
+## Phase Report Template
+
+Use this when completing one phase of a multi-phase plan. Shorter than a Full Report but still structured.
+
+```
+## Phase N Complete: [Phase Title]
+
+### What was done
+- [Bullet list of concrete changes]
+
+### Files Changed
+- `path/to/file.ts` — [what and why]
+
+### Key Decisions
+- [Any non-obvious choices made during this phase]
+
+### Blockers or Concerns
+- [Anything that might affect subsequent phases]
+
+### Phase Status
+- [x] Phase N complete
+- [ ] Phase N+1: [title] — next
+```
+
+---
+
+## Bug Fix Report Template
+
+```
+## Bug Fix: [Short description]
+
+### Root Cause
+[What was actually wrong — not just the symptom, but the underlying cause]
+
+### Fix Applied
+- `path/to/file.ts` — [what changed]
+
+### Why This Fix
+[Why this approach was chosen. What other approaches were considered and rejected.]
+
+### How to Verify
+1. [Steps to confirm the fix works]
+
+### Regression Risk
+- [Could this fix break anything else? What was checked?]
+```
+
+---
+
+## Rules
+
+1. **Structure over prose.** Use the templates above. Tables, bullet points, and headers — not paragraphs.
+2. **Every file gets a "why".** Don't just list `file.ts` — explain what changed and why. "Added creditBalance: 0 to mocks" → "Added `creditBalance: 0` to user mocks in `setup.ts` because the new credits module added this required field to the User model, and existing test fixtures would fail validation without it."
+3. **Be specific in "How to Test".** Not "use Postman to test." Instead: "1. POST `{{baseUrl}}/auth/login` with test credentials. 2. POST `{{baseUrl}}/generations` with body `{ templateId: '...', image: <file> }`. 3. Expected: 201 with `{ success: true, data: { id, status: 'pending' } }`."
+4. **Explain decisions, not just actions.** "Used upsert for seed data" → "Used `upsert` instead of `create` for seed data so the seed script is idempotent — running it twice won't throw duplicate key errors."
+5. **Surface what the user needs to do.** If the user must add an env var, run a migration, install something, or restart a service — put it in "Manual Steps Required" prominently. Don't bury it in a paragraph.
+6. **Honest about limitations.** If something is incomplete, has edge cases, or needs future work — say so in "Known Limitations." Don't pretend everything is perfect.
+7. **Scale to the task.** A 5-phase feature gets a full report with every section. A single service method gets a shorter report. Use judgment, but always use the structured format.
+8. **Deployment impact is never optional.** If ANY of the following changed, the "Deployment & Production Impact" section is REQUIRED — no exceptions:
+   - New or modified environment variables
+   - New npm packages with native dependencies
+   - Database schema changes (new tables, columns, indexes)
+   - Dockerfile modifications needed
+   - New external service dependencies (APIs, Redis, S3, etc.)
+   - Port, entry point, or health check changes
+   - File upload/storage changes requiring volume mounts
+   - Changes to build process or build arguments
+   If none of these apply, explicitly state: "No deployment impact — no infrastructure, env, or database changes."

package/template/_claude/rules/global/core.md

@@ -66,6 +66,12 @@ When the user asks to create, scaffold, or start a new server or client project,
 
 ---
 
+## Task Completion Reports
+
+After completing any task, phase, or bug fix, you MUST provide a structured completion report — not freeform paragraphs. **Read `completion-reports.md`** for the required templates and rules. This includes deployment/production impact analysis whenever infrastructure, env vars, database, or Docker changes are involved.
+
+---
+
 ## Code Review Checklist
 
 Before considering work done, verify:

package/template/client/.dockerignore

@@ -0,0 +1,63 @@
+# Dependencies (will be installed fresh in Docker)
+node_modules
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+pnpm-debug.log*
+
+# Build output (will be built fresh in Docker)
+.next
+out
+*.tsbuildinfo
+
+# Environment files (use Docker env vars instead)
+.env
+.env.local
+.env.*.local
+.env.development
+.env.test
+
+# Git
+.git
+.gitignore
+.gitattributes
+
+# IDE
+.vscode
+.idea
+*.swp
+*.swo
+*~
+.DS_Store
+
+# Testing
+coverage
+.nyc_output
+**/__tests__
+**/*.test.ts
+**/*.test.tsx
+**/*.spec.ts
+**/*.spec.tsx
+vitest.config.ts
+jest.config.ts
+
+# Documentation
+docs
+CHANGELOG.md
+LICENSE
+
+# Docker
+Dockerfile
+.dockerignore
+docker-compose.yml
+
+# CI/CD
+.github
+.gitlab-ci.yml
+.circleci
+
+# Misc
+.prettierrc
+.eslintrc
+.eslintignore
+.editorconfig

package/template/client/.env.example.production

@@ -0,0 +1,5 @@
+# Public API URL - points to the production server's base URL
+NEXT_PUBLIC_API_BASE_URL=https://api.yourdomain.com/api/v1
+
+# App name displayed in the UI
+NEXT_PUBLIC_APP_NAME={{PROJECT_DISPLAY_NAME}}

package/template/client/Dockerfile

@@ -0,0 +1,98 @@
+# ===================================================================
+# Multi-stage Dockerfile for Next.js Production Deployment
+# Optimized for Coolify, Docker Compose, and Kubernetes
+# Requires `output: "standalone"` in next.config.ts
+# ===================================================================
+
+# ===================================================================
+# Stage 1: Dependencies (cached layer)
+# ===================================================================
+FROM node:20-alpine AS dependencies
+
+WORKDIR /app
+
+# Copy package files
+COPY package.json package-lock.json* pnpm-lock.yaml* yarn.lock* ./
+
+# Install dependencies (use the lockfile that exists)
+RUN if [ -f pnpm-lock.yaml ]; then \
+      npm install -g pnpm && pnpm install --frozen-lockfile; \
+    elif [ -f yarn.lock ]; then \
+      yarn install --frozen-lockfile; \
+    else \
+      npm ci; \
+    fi
+
+# ===================================================================
+# Stage 2: Build (compile Next.js)
+# ===================================================================
+FROM node:20-alpine AS builder
+
+WORKDIR /app
+
+# Copy dependencies from previous stage
+COPY --from=dependencies /app/node_modules ./node_modules
+
+# Copy source code
+COPY . .
+
+# Build arguments for env vars needed at build time
+# Next.js inlines NEXT_PUBLIC_* values during build, so they must
+# be available here. Pass them via --build-arg in Coolify/Docker.
+ARG NEXT_PUBLIC_API_BASE_URL
+ARG NEXT_PUBLIC_APP_NAME
+
+ENV NEXT_PUBLIC_API_BASE_URL=$NEXT_PUBLIC_API_BASE_URL
+ENV NEXT_PUBLIC_APP_NAME=$NEXT_PUBLIC_APP_NAME
+
+# Disable Next.js telemetry during build
+ENV NEXT_TELEMETRY_DISABLED=1
+
+# Build the application (outputs to .next/standalone)
+RUN npm run build
+
+# ===================================================================
+# Stage 3: Production Runtime
+# ===================================================================
+FROM node:20-alpine AS production
+
+# Install dumb-init for proper signal handling
+RUN apk add --no-cache dumb-init
+
+# Create non-root user for security
+RUN addgroup -g 1001 -S nodejs && \
+    adduser -S nextjs -u 1001
+
+WORKDIR /app
+
+# Copy the standalone server (includes only required node_modules)
+COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
+
+# Copy static assets (not included in standalone output)
+COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static
+
+# Copy public folder (favicon, images, etc.)
+COPY --from=builder --chown=nextjs:nodejs /app/public ./public
+
+# Switch to non-root user
+USER nextjs
+
+# Disable telemetry at runtime
+ENV NEXT_TELEMETRY_DISABLED=1
+
+# Set hostname to listen on all interfaces (required in containers)
+ENV HOSTNAME="0.0.0.0"
+
+# Default port (override via PORT env var in Coolify)
+ENV PORT=3000
+EXPOSE 3000
+
+# Health check for container orchestration
+HEALTHCHECK --interval=30s --timeout=3s --start-period=10s --retries=3 \
+  CMD node -e "const p=process.env.PORT||3000;require('http').get('http://localhost:'+p,(r)=>{process.exit(r.statusCode===200?0:1)})"
+
+# Use dumb-init to handle signals properly
+ENTRYPOINT ["dumb-init", "--"]
+
+# Start the standalone Next.js server
+CMD ["node", "server.js"]

package/template/client/next.config.ts

@@ -10,6 +10,7 @@ const apiOrigin = (() => {
 })();
 
 const nextConfig: NextConfig = {
+  output: "standalone",
   async headers() {
     return [
       {

package/template/client/src/app/error.tsx

@@ -13,7 +13,7 @@ export default function GlobalError({
   reset: () => void;
 }): React.ReactElement {
   return (
-    <div className="flex min-h-[400px] flex-col items-center justify-center p-8 text-center">
+    <div className="flex min-h-dvh flex-col items-center justify-center p-8 text-center">
       <AlertCircle className="mb-4 h-12 w-12 text-destructive" />
       <h2 className="mb-2 text-2xl font-bold">Something went wrong</h2>
       <p className="mb-4 text-muted-foreground">