Alexis Bruneteau b83c7a7d6d
Some checks failed
Build and Deploy to k3s / build-and-deploy (push) Failing after 1m31s
feat(migration): migrate from Angular 20 to Next.js 15
Complete framework migration from Angular to Next.js with full feature parity.

## What Changed
- Migrated from Angular 20 to Next.js 15 with App Router
- Replaced Angular components with React functional components
- Implemented React Context API for state management (replacing RxJS)
- Integrated React Hook Form for form handling
- Added shadcn/ui component library
- Configured Tailwind CSS 4.1 with @tailwindcss/postcss
- Implemented JWT authentication with middleware protection

## Core Features Implemented
-  User registration and login with validation
-  JWT token authentication with localStorage
-  Protected dashboard route with middleware
-  Portfolio listing with status indicators
-  Create portfolio functionality
-  ZIP file upload with progress tracking
-  Portfolio deployment
-  Responsive design with Tailwind CSS

## Technical Stack
- Framework: Next.js 15 (App Router)
- Language: TypeScript 5.8
- Styling: Tailwind CSS 4.1
- UI Components: shadcn/ui + Lucide icons
- State: React Context API + hooks
- Forms: React Hook Form
- API Client: Native fetch with custom wrapper

## File Structure
- /app - Next.js pages (landing, login, register, dashboard)
- /components - React components (ui primitives, auth provider)
- /lib - API client, types, utilities
- /hooks - Custom hooks (useAuth, usePortfolios)
- /middleware.ts - Route protection
- /angular-backup - Preserved Angular source code

## API Compatibility
- All backend endpoints remain unchanged
- JWT Bearer token authentication preserved
- API response format maintained

## Build Output
- Production build: 7 routes compiled successfully
- Bundle size: ~102kB shared JS (optimized)
- First Load JS: 103-126kB per route

## Documentation
- Updated README.md with Next.js setup guide
- Created OpenSpec proposal in openspec/changes/migrate-to-nextjs-launchui/
- Added project context in openspec/project.md

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-10-17 00:34:43 +02:00

5.2 KiB

UI Components Capability - Delta Specification

ADDED Requirements

Requirement: Launch UI Component Library

The application SHALL integrate the Launch UI component library, providing pre-built, conversion-optimized components built on shadcn/ui and Tailwind CSS.

Scenario: Navbar component integration

  • WHEN the Navbar component is rendered
  • THEN it SHALL display navigation links (Home, Login, Register, Dashboard)
  • AND it SHALL be responsive with mobile menu toggle
  • AND it SHALL support authenticated/unauthenticated state variations

Scenario: Hero component on landing page

  • WHEN the landing page is loaded
  • THEN the Hero component SHALL display the main value proposition
  • AND it SHALL include primary CTA button (e.g., "Get Started")
  • AND it SHALL support background gradients and imagery

Scenario: FAQ component for common questions

  • WHEN the FAQ component is displayed
  • THEN it SHALL render accordion-style question/answer pairs
  • AND clicking a question SHALL expand the answer
  • AND multiple questions can be expanded simultaneously
  • WHEN any page is rendered
  • THEN the Footer component SHALL appear at the bottom
  • AND it SHALL include copyright, links, and social media icons
  • AND it SHALL be styled consistently with the Navbar

Requirement: shadcn/ui Primitive Components

The application SHALL use shadcn/ui primitive components (Button, Input, Card, Dialog, etc.) for all interactive UI elements, ensuring consistency and accessibility.

Scenario: Button component variants

  • WHEN a button is rendered
  • THEN it SHALL support variants: default, destructive, outline, secondary, ghost, link
  • AND it SHALL support size props: default, sm, lg, icon
  • AND it SHALL be keyboard accessible and focusable

Scenario: Input component with validation states

  • WHEN an input field is rendered in a form
  • THEN it SHALL support validation states: default, error, success
  • AND it SHALL display error messages when validation fails
  • AND it SHALL be accessible with proper ARIA labels

Scenario: Card component for content grouping

  • WHEN content needs visual grouping (e.g., portfolio cards)
  • THEN the Card component SHALL be used with Header, Content, and Footer sections
  • AND it SHALL support hover effects and shadows
  • AND it SHALL be responsive to viewport changes

Requirement: Lucide Icons Integration

The application SHALL use Lucide React icons for all iconography, ensuring consistent visual language and accessibility.

Scenario: Icon usage in buttons

  • WHEN a button requires an icon
  • THEN a Lucide icon component SHALL be imported and rendered
  • AND the icon SHALL scale appropriately with button size
  • AND it SHALL support aria-hidden for decorative icons

Scenario: Status indicators with icons

  • WHEN displaying portfolio status (e.g., uploaded, pending)
  • THEN status-appropriate Lucide icons SHALL be shown
  • AND icons SHALL be color-coded to match status meaning
  • AND tooltips or labels SHALL provide context

Requirement: Component Accessibility (WCAG 2.1 AA)

All UI components SHALL meet WCAG 2.1 Level AA accessibility standards, including keyboard navigation, screen reader support, and sufficient color contrast.

Scenario: Keyboard navigation for interactive elements

  • WHEN a user navigates using only the keyboard
  • THEN all interactive components SHALL be focusable in logical order
  • AND focus indicators SHALL be visible
  • AND Enter/Space keys SHALL activate buttons and links

Scenario: Screen reader compatibility

  • WHEN a screen reader user accesses the application
  • THEN all components SHALL have appropriate ARIA labels and roles
  • AND form inputs SHALL be associated with labels
  • AND dynamic content changes SHALL be announced

Scenario: Color contrast compliance

  • WHEN components are rendered
  • THEN text SHALL have a minimum contrast ratio of 4.5:1 against backgrounds
  • AND interactive elements SHALL have 3:1 contrast for non-text elements
  • AND color SHALL not be the sole indicator of state or meaning

Requirement: Dark Mode Support (Future Enhancement)

The application SHALL provide infrastructure for dark mode theming using shadcn/ui's theme system, enabling future implementation of light and dark color scheme toggling.

(Future enhancement - infrastructure SHALL be present, but full implementation is deferred)

Scenario: Theme toggle in Navbar

  • WHEN a user clicks the theme toggle button
  • THEN the application SHALL switch between light and dark mode
  • AND the preference SHALL be persisted in localStorage
  • AND all Launch UI components SHALL adapt to the selected theme

Scenario: System preference detection

  • WHEN a user first visits the application
  • THEN the theme SHALL default to the user's system preference (prefers-color-scheme)
  • AND the theme can be manually overridden by the user

MODIFIED Requirements

No existing requirements to modify (new capability)

REMOVED Requirements

No requirements to remove (new capability)