## MODIFIED Requirements

### Requirement: Docker Production Build
The system SHALL package Next.js applications into production-ready Docker images using multi-stage builds to minimize image size while maintaining runtime performance.

#### Scenario: Multi-stage build process
- **WHEN** `docker build` is executed on the repository
- **THEN** the build completes in two stages: (1) Node.js base image compiles Next.js application to standalone output, (2) minimal runtime image includes only necessary files and runs as non-root user

#### Scenario: Standalone output optimization
- **WHEN** Next.js build completes with `output: 'standalone'` mode
- **THEN** the resulting `.next/standalone` directory contains all production dependencies and compiled code with no node_modules required in the container

#### Scenario: Runtime execution
- **WHEN** the Docker container starts
- **THEN** the Next.js application runs with `node server.js` from the standalone output directory, listening on port 3000

#### Scenario: Environment variable injection
- **WHEN** Docker container starts with environment variables (e.g., `NEXT_PUBLIC_API_URL`)
- **THEN** these variables are available to the Next.js application at runtime

## MODIFIED Requirements

### Requirement: Docker Context Efficiency
The system SHALL exclude development files and dependencies from the Docker build context to reduce build time and context size.

#### Scenario: .dockerignore file
- **WHEN** Docker build executes
- **THEN** files listed in `.dockerignore` (node_modules, .next, .git, .env.local, etc.) are excluded from the context sent to the Docker daemon

#### Scenario: Build context optimization
- **WHEN** source code changes and `docker build` is re-run
- **THEN** only necessary files (src, package.json, Dockerfile, etc.) are included, resulting in faster build context preparation

## ADDED Requirements

### Requirement: Non-Root User Security
The system SHALL run the Next.js application in the Docker container as a non-root user to enforce security best practices.

#### Scenario: Non-root container execution
- **WHEN** the Docker container starts
- **THEN** the Next.js process runs as the `nextjs` user (UID 1000) rather than root, reducing attack surface

#### Scenario: File permissions
- **WHEN** application files are copied into the runtime image
- **THEN** ownership is transferred to the `nextjs` user with appropriate read/execute permissions

## ADDED Requirements

### Requirement: Production Health Check
The system SHALL include a health check endpoint that verifies the Next.js application is responsive.

#### Scenario: Health check configuration
- **WHEN** the Docker image is built
- **THEN** a HEALTHCHECK instruction is configured to periodically verify the application responds at `http://localhost:3000/` (or similar endpoint)

#### Scenario: Health status
- **WHEN** Kubernetes or orchestration system queries container health
- **THEN** the health check returns success (exit code 0) when the application is running and responding, failure otherwise