sortifal/hosting-frontend
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
hosting-frontend/.claude/commands/openspec/proposal.md
Alexis Bruneteau b83c7a7d6d
Some checks failed
Build and Deploy to k3s / build-and-deploy (push) Failing after 1m31s
Details
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

2.3 KiB
Raw Blame History

name: OpenSpec: Proposal description: Scaffold a new OpenSpec change and validate strictly. category: OpenSpec tags: [openspec, change]

Guardrails

  • Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
  • Keep changes tightly scoped to the requested outcome.
  • Refer to openspec/AGENTS.md (located inside the openspec/ directory—run ls openspec or openspec update if you don't see it) if you need additional OpenSpec conventions or clarifications.
  • Identify any vague or ambiguous details and ask the necessary follow-up questions before editing files.

Steps

  1. Review openspec/project.md, run openspec list and openspec list --specs, and inspect related code or docs (e.g., via rg/ls) to ground the proposal in current behaviour; note any gaps that require clarification.
  2. Choose a unique verb-led change-id and scaffold proposal.md, tasks.md, and design.md (when needed) under openspec/changes/<id>/.
  3. Map the change into concrete capabilities or requirements, breaking multi-scope efforts into distinct spec deltas with clear relationships and sequencing.
  4. Capture architectural reasoning in design.md when the solution spans multiple systems, introduces new patterns, or demands trade-off discussion before committing to specs.
  5. Draft spec deltas in changes/<id>/specs/<capability>/spec.md (one folder per capability) using ## ADDED|MODIFIED|REMOVED Requirements with at least one #### Scenario: per requirement and cross-reference related capabilities when relevant.
  6. Draft tasks.md as an ordered list of small, verifiable work items that deliver user-visible progress, include validation (tests, tooling), and highlight dependencies or parallelizable work.
  7. Validate with openspec validate <id> --strict and resolve every issue before sharing the proposal.

Reference

  • Use openspec show <id> --json --deltas-only or openspec show <spec> --type spec to inspect details when validation fails.
  • Search existing requirements with rg -n "Requirement:|Scenario:" openspec/specs before writing new ones.
  • Explore the codebase with rg <keyword>, ls, or direct file reads so proposals align with current implementation realities.