# Product Requirements Document (PRD) - Angular Clarity Boilerplate

## 1. Product Vision

To provide a robust, scalable, and feature-rich boilerplate that serves as a foundational template for building modern, enterprise-grade web applications using Angular and the VMware Clarity Design System. The vision is to accelerate the development lifecycle by offering a pre-configured, best-practice project structure.

## 2. Target Audience

The primary target audience consists of **Angular developers and development teams** who require a standardized, efficient, and consistent starting point for new projects. This includes:

* **Enterprise Development Teams:** Teams that need to maintain a consistent look and feel across multiple applications.
* **Independent Developers:** Individuals looking to quickly bootstrap new projects without spending significant time on initial setup and configuration.

## 3. User Stories (Developer Stories)

### User Story 1: Quick Project Initialization
- **As a developer, I want to clone the repository and run `npm install` and `ng serve` to get a live development server running, so that I can bypass manual setup and start building features immediately.**
- **Acceptance Criteria:**
    - Given I have Node.js and Angular CLI installed,
    - When I clone the repository, install dependencies, and run the start command,
    - Then the application compiles successfully and is accessible in my browser at `localhost:4200`.

### User Story 2: Add a New Feature
- **As a developer, I want to create a new lazy-loaded feature module with its own components and routing, so that I can add new sections to the application in a scalable way.**
- **Acceptance Criteria:**
    - Given the boilerplate is running,
    - When I use the Angular CLI to generate a new module and add it to the main routing configuration,
    - Then I can navigate to the new feature's route, and its components are rendered correctly.

### User Story 3: Utilize Shared Components
- **As a developer, I want to use a component from the `SharedModule` within a new feature module, so that I can reuse common UI elements and maintain consistency.**
- **Acceptance Criteria:**
    - Given I have a new feature module,
    - When I import the `SharedModule` into my feature module,
    - Then I can use the shared components (e.g., a custom card or loader) in my feature's templates without errors.

## 4. Functional Requirements

- **FR-001: Pre-configured Angular Environment:** A ready-to-use Angular CLI project with all necessary dependencies and build configurations.
- **FR-002: Clarity Design System Integration:** Full integration of Clarity UI components and styles, ready for immediate use.
- **FR-003: Scalable Architecture:** A modular structure featuring a `CoreModule` for singleton services and a `SharedModule` for reusable UI components, directives, and pipes.
- **FR-004: Responsive Layout:** A default application shell with a responsive header, navigation sidebar, and main content area.
- **FR-005: Routing:** A pre-configured routing module with examples of lazy-loaded feature modules.
- **FR-006: Theming:** Basic support for Clarity's light and dark themes.

## 5. Non-Functional Requirements

- **NFR-001: Performance:** The initial boilerplate should be lightweight, ensuring fast development server startup times and optimized production builds.
- **NFR-002: Usability (Developer Experience):** The codebase must be clean, well-commented, and logically organized to provide an excellent developer experience.
- **NFR-003: Maintainability:** The modular architecture must facilitate easy updates to dependencies and allow for the addition of new features without introducing breaking changes to the core structure.
- **NFR-004: Scalability:** The architecture is designed to support the growth of large, enterprise-scale applications.
- **NFR-005: Extensibility:** The boilerplate should be easy to customize and extend with additional libraries, modules, and configurations as per project-specific needs.

## 6. Out of Scope

The following features and functionalities are explicitly out of scope for the boilerplate:

-   **Backend Implementation:** This is a frontend-only boilerplate and does not include any backend code or database.
-   **Authentication/Authorization Logic:** While the architecture supports the implementation of security features, no pre-built authentication or authorization logic is included.
-   **State Management:** The boilerplate does not include a state management library (e.g., NgRx, Akita) by default, allowing developers to choose the best solution for their needs.
-   **Business Logic:** No specific business logic or application features are included beyond the basic structural components.
-   **CI/CD Pipelines:** While the project is ready for CI/CD, no pre-configured pipelines are included.

---

## PRD UPDATE - 2025-10-09 05:06:16

--- 
### Non-Functional Requirements Update - 2025-10-09T05:48:58Z

-   **NFR-008: Operability & Observability:** The application shall include comprehensive logging, monitoring, and health check mechanisms to ensure visibility into its performance, health, and enable rapid identification and diagnosis of issues.

---
### Technical Requirements Update - 2025-10-09T05:48:58Z

This section augments the existing technical requirements with operational details and detailed quality standards, drawing from the latest architecture and tech stack documents.

#### Operational Technical Considerations
-   **Monitoring & Logging:**
    -   Backend: Python's `logging` module will be configured for application events, errors, and warnings, favoring structured logging for easier aggregation.
    -   Frontend: A global error handler will capture client-side exceptions and can be configured to report to a centralized error tracking service.
    -   API Monitoring: Key API endpoints will be monitored for metrics such as response times, error rates (e.g., 4xx, 5xx responses), and request throughput.
    -   Infrastructure Monitoring: Resource utilization (CPU, memory, disk I/O) of deployed containers and database services will be tracked.
-   **Health Checks:** A dedicated backend endpoint (e.g., `/healthz` or `/status`) shall return a 200 OK status if the application is running and can successfully connect to its critical dependencies (e.g., database). This is essential for load balancers and container orchestrators to determine service health.

#### Advanced Deployment & CI/CD Considerations
-   **Container Orchestration (Future):** The design inherently supports deployment on container orchestration platforms (e.g., Kubernetes, AWS ECS, Azure AKS) to leverage features like auto-scaling, self-healing, and service discovery.
-   **Continuous Integration/Continuous Deployment (CI/CD):** Automated pipelines (e.g., GitHub Actions) will be established to automate code building, comprehensive testing, Docker image creation, and deployment to staging and production environments, ensuring rapid and reliable releases.
-   **Zero-Downtime Deployments:** Strategies such as rolling updates or blue/green deployments will be considered for seamless application updates in production environments, minimizing user impact.
-   **Environment Management:** Strict separation of configurations for development, testing, staging, and production will be maintained. Environment-specific variables will be managed securely (e.g., Kubernetes Secrets, AWS Secrets Manager) and injected into application containers at runtime.

#### Code Quality & Testing Standards
-   **Frontend Code Quality:**
    -   **Linting:** ESLint (configured via Angular CLI) will enforce coding style guidelines, identify potential bugs, and promote best practices.
    -   **Formatting:** Prettier will be utilized for consistent code style, integrated into the development environment and ideally enforced via pre-commit hooks.
    -   **Type Checking:** The TypeScript compiler (`tsc`) will be configured with strict settings to leverage static type analysis, catching type-related errors early.
-   **Backend Code Quality:**
    -   **Linting:** Flake8 will check for PEP 8 compliance, common Python coding errors, and stylistic issues.
    -   **Formatting:** Black will serve as the uncompromising Python code formatter, ensuring consistent and readable code style.
    -   **Static Analysis (Recommended):** Mypy can be integrated for static type checking of Python code, and Bandit for identifying common security vulnerabilities.
-   **Testing Frameworks:**
    -   **Frontend Unit Testing:** Karma (test runner) and Jasmine (BDD framework) will be used with Angular Testing Utilities to test components, services, and HTTP interactions effectively.
    -   **Backend Unit/Integration Testing:** Pytest will be the primary framework, utilizing Flask's `test_client()` for API endpoint testing and `unittest.mock`/`pytest-mock` for isolating dependencies.
    -   **End-to-End (E2E) Testing (Future Consideration):** Cypress is a strong candidate for comprehensive UI interaction and full user journey validation if prioritized.

---
### Document Status - 2025-10-09T05:48:58Z

This Product Requirements Document has been thoroughly reviewed and updated based on the latest analysis, architecture, and technology stack definitions. It now comprehensively outlines the product vision, user needs, functional and non-functional requirements, detailed technical considerations (including operability and deployment strategy), and implementation strategy for the Simple Notes Taking App.

**Prepared By:** io8 Product Manager Agent
**Status:** Ready for Development Phase

---


---

## PRD UPDATE - 2025-10-09 05:06:37

# Product Requirements Document (PRD)

## 1. Executive Summary
**[2025-10-09T05:47:30.000Z]**
The Simple Notes Taking App is a user-friendly, client-server application designed to enable users to efficiently create, view, edit, and delete personal notes. It leverages an Angular frontend integrated with the Clarity Design System (building upon an existing boilerplate), a Flask/Python RESTful API backend, and a PostgreSQL database for persistent storage. The primary objective is to deliver a Minimum Viable Product (MVP) focused on core note management functionalities, providing a straightforward and reliable digital notepad experience.

## 2. Product Vision & Strategy
**[2025-10-09T05:47:30.000Z]**
**Product Vision:** To be the most intuitive and reliable digital notepad for individuals who value simplicity and efficiency in capturing and managing their thoughts.
**Strategic Goals:**
1.  **Achieve MVP with Core CRUD:** Successfully implement all Create, Read, Update, Delete functionalities for notes.
2.  **Ensure Data Integrity:** Guarantee reliable and persistent storage of user notes without data loss.
3.  **Deliver Seamless User Experience:** Provide a responsive and intuitive interface that simplifies the note-taking process.
4.  **Establish Scalable Foundation:** Build an architecture that can easily accommodate future features like user authentication, search, and categorization.
**Success Metrics & KPIs:**
*   **User Engagement:** Number of notes created, updated, and deleted per user per session (post-authentication).
*   **Performance:** Average load time for note lists and individual notes (target: < 2 seconds).
*   **Reliability:** Uptime of backend API (target: > 99.9%), data consistency checks.
*   **User Satisfaction (Future):** Feedback via surveys or app store ratings (if applicable).

## 3. Target Users & Personas
**[2025-10-09T05:47:30.000Z]**
**Primary Target User:** "The Efficient Minimalist"
*   **Demographics:** Individuals (students, professionals, personal users) who need to quickly jot down information, reminders, or ideas.
*   **Behavior:** Often uses digital tools for organization but gets overwhelmed by feature-rich applications. Prefers straightforward interfaces.
*   **Needs:**
    *   A simple, clutter-free interface for note-taking.
    *   Reliable storage that ensures notes are always accessible.
    *   Fast and easy CRUD operations for notes.
*   **Pain Points:**
    *   Too many features in existing apps lead to decision fatigue.
    *   Slow performance or syncing issues in complex note apps.
    *   Difficulty finding basic functionality in overloaded interfaces.

## 4. Problem Statement
**[2025-10-09T05:47:30.000Z]**
Many existing digital note-taking applications offer a plethora of advanced features, which often leads to complex user interfaces, slower performance, and a steeper learning curve. This complexity can overwhelm users who primarily need a simple, reliable, and efficient way to capture, organize, and manage basic textual information without unnecessary overhead. The problem is a lack of a truly "simple" and performant solution for core note management.

## 5. Solution Overview
**[2025-10-09T05:47:30.000Z]**
The Simple Notes Taking App will address this problem by providing a focused solution with the following key components:
*   **Responsive Web Frontend:** An Angular application leveraging the Clarity Design System to provide a clean, intuitive, and consistent user interface across devices.
*   **RESTful API Backend:** A Python Flask application exposing endpoints for all note CRUD operations.
*   **Persistent Data Storage:** A PostgreSQL database (SQLite for development) to reliably store all user notes.
*   **Core CRUD Functionality:** Enable users to create, view a list of, view details of, edit, and delete notes.
This solution prioritizes simplicity and core functionality, ensuring a high-performance and reliable note-taking experience.

## 6. Functional Requirements
**[2025-10-09T05:47:30.000Z]**
Based on the updated `analysis_document.md` and user stories:
*   **FR-001: Note Creation**: The application SHALL allow users to create a new note by providing a title and optional content.
*   **FR-002: Note Listing**: The application SHALL display a list of all existing notes, showing at least the title and a short content preview.
*   **FR-003: View Single Note**: The application SHALL allow users to select a note from the list and view its full title and content on a dedicated detail page.
*   **FR-004: Note Editing**: The application SHALL enable users to modify the title and content of an existing note.
*   **FR-005: Note Deletion**: The application SHALL provide functionality to permanently delete a selected note, with a user confirmation step.
*   **FR-006: Data Persistence**: The application SHALL ensure that all notes (created, edited, deleted) are persistently stored and retrieved reliably across user sessions and application restarts.
*   **FR-007 (Stretch Goal): Basic User Authentication**: The application MAY implement user registration and login to allow for personalized note ownership.

## 7. Non-Functional Requirements
**[2025-10-09T05:47:30.000Z]**
Referencing the updated `analysis_document.md` and `architecture_document.md`:
*   **NFR-001: Performance**: 
    *   The application SHALL load the list of notes within 2 seconds.
    *   Individual note details SHALL load within 1 second.
    *   CRUD operations (create, update, delete) SHALL complete within 1.5 seconds from user action to UI update.
*   **NFR-002: Usability**: 
    *   The user interface SHALL be intuitive and easy to navigate for core note management.
    *   All interactive elements SHALL provide clear feedback to the user upon interaction.
    *   The application SHALL be accessible to users with common accessibility needs (e.g., keyboard navigation).
*   **NFR-003: Reliability**: 
    *   Note data SHALL be saved and retrieved consistently without corruption or loss.
    *   The backend API SHALL maintain an uptime of at least 99.9% in production.
    *   The application SHALL handle network errors gracefully, informing the user without crashing.
*   **NFR-004: Scalability**: 
    *   The backend architecture SHALL be designed to support an increasing number of notes (e.g., thousands per user) and concurrent users.
    *   Frontend architecture (lazy-loaded modules) SHALL ensure that adding new features does not degrade initial load performance.
*   **NFR-005: Security**: 
    *   All user input (note title, content) SHALL be validated on both frontend and backend to prevent common vulnerabilities (e.g., XSS, SQL Injection).
    *   All communication between frontend and backend SHALL use HTTPS.
    *   If user authentication is implemented, passwords SHALL be securely hashed, and user data SHALL be protected against unauthorized access.
*   **NFR-006: Maintainability**: 
    *   The codebase SHALL adhere to established coding standards (ESLint/Prettier for Angular, Flake8/Black for Flask).
    *   The project SHALL have clear documentation for setting up, building, and contributing.
    *   The modular architecture SHALL facilitate easy updates and feature additions.
*   **NFR-007: Responsiveness**: The frontend UI SHALL adapt and be fully usable across various screen sizes, including desktop, tablet, and mobile devices.

## 8. Epic Stories
**[2025-10-09T05:47:30.000Z]**

### Epic 1: Core Note Management (CRUD)
**Epic Description:** This epic encompasses all essential functionalities for users to interact with their notes, including creating, viewing (list and detail), editing, and deleting notes. It forms the backbone of the application's user value proposition.
**Business Value:** Enables users to perform fundamental note-taking activities, directly addressing the core problem of providing a simple digital notepad.
**Acceptance Criteria:**
*   Users can successfully create, retrieve, update, and delete notes through the UI.
*   All CRUD operations provide clear feedback to the user.
*   Notes are displayed consistently in lists and detail views.

**User Stories:**
-   **US-001:** Create New Note
    -   **As a** user
    -   **I want to** create a new note with a title and content
    -   **So that** I can jot down my thoughts and save new information.
    -   **Acceptance Criteria:**
        -   [ ] Given I am on the notes application, when I click 'New Note', then I see a form for title and content.
        -   [ ] When I enter a valid title (max 100 chars) and optional content and submit, then the note is saved and appears in the list.
        -   [ ] When I try to submit a note with an empty title, then I receive an error and the note is not saved.
    -   **Story Points:** 5
    -   **Priority:** High

-   **US-002:** View All Notes
    -   **As a** user
    -   **I want to** view a list of all my notes
    -   **So that** I can easily browse and find my existing notes.
    -   **Acceptance Criteria:**
        -   [ ] Given I have created notes, when I visit the notes home page, then I see a list of all my notes.
        -   [ ] Each item in the list displays the note's title and a short content preview.
        -   [ ] The list is presented in a clear, readable, and responsive format using Clarity UI components.
    -   **Story Points:** 3
    -   **Priority:** High

-   **US-003:** View Individual Note Details
    -   **As a** user
    -   **I want to** view the full details of a specific note
    -   **So that** I can read its complete content and focus on a single piece of information.
    -   **Acceptance Criteria:**
        -   [ ] Given I am viewing the list of notes, when I click on a note title, then I am navigated to a dedicated detail page.
        -   [ ] The detail page displays the full title and content of the selected note.
        -   [ ] The detail page includes options to go back to the list or edit the note.
    -   **Story Points:** 3
    -   **Priority:** High

-   **US-004:** Edit Existing Note
    -   **As a** user
    -   **I want to** edit an existing note's title and content
    -   **So that** I can update my information as needed.
    -   **Acceptance Criteria:**
        -   [ ] Given I am viewing a note's details, when I click 'Edit', then I see a pre-filled form with the note's current data.
        -   [ ] When I modify the title or content and submit, then the note is updated and the updated details are displayed.
        -   [ ] When I try to save an edited note with an empty title, then I receive an error and the note is not updated.
    -   **Story Points:** 5
    -   **Priority:** High

-   **US-005:** Delete Note
    -   **As a** user
    -   **I want to** delete a note
    -   **So that** I can remove outdated or unwanted information.
    -   **Acceptance Criteria:**
        -   [ ] Given I am viewing a note's details or the notes list, when I click 'Delete', then I see a confirmation dialog.
        -   [ ] When I confirm deletion, then the note is permanently removed from storage and no longer appears in the list.
        -   [ ] When I cancel deletion, then the note remains unchanged.
    -   **Story Points:** 3
    -   **Priority:** High

### Epic 2: Application Reliability & Data Persistence
**Epic Description:** This epic focuses on ensuring the underlying system reliably stores and retrieves user data, forming the foundation of trust for the application. It addresses the critical need for data integrity and consistency.
**Business Value:** Builds user trust by guaranteeing that their valuable notes are safe and always accessible, underpinning the utility of the entire application.
**Acceptance Criteria:**
*   All notes created or modified are permanently stored.
*   Deleted notes remain deleted.
*   Data is consistent across sessions and application restarts.

**User Stories:**
-   **US-006:** Ensure Note Persistence
    -   **As a** user
    -   **I want to** have my notes saved persistently
    -   **So that** I don't lose my data and can access it reliably across sessions.
    -   **Acceptance Criteria:**
        -   [ ] Given I have created, edited, or deleted notes (via US-001, US-004, US-005).
        -   [ ] When I close and reopen the application (or refresh the page), then all my changes are accurately reflected in the notes list and detail views.
        -   [ ] And no data is lost due to application restarts or browser closures.
    -   **Story Points:** 8
    -   **Priority:** High (as it underpins all other features)

## 9. User Interface Requirements
**[2025-10-09T05:47:30.000Z]**
*   **UI-001: Clarity Design System Adherence**: The UI SHALL strictly follow the VMware Clarity Design System for all components (buttons, forms, data grids, navigation) to ensure consistency with the boilerplate and a professional look and feel.
*   **UI-002: Responsive Design**: The application UI SHALL be fully responsive and adapt gracefully to various screen sizes (desktop, tablet, mobile) and orientations.
*   **UI-003: Intuitive Navigation**: There SHALL be clear and easy navigation paths between the list of notes, individual note details, and the note creation/edit form.
*   **UI-004: Form Design**: Note creation and edit forms SHALL be simple, clear, and include appropriate input fields (e.g., `clr-input` for title, `clr-textarea` for content) with clear labels and validation messages.
*   **UI-005: Feedback Mechanisms**: The UI SHALL provide visual feedback for actions (e.g., successful save, deletion confirmation, loading states, error messages).
*   **UI-006: Empty State**: A clear message or visual cue SHALL be displayed when there are no notes created yet.

## 10. Technical Requirements
**[2025-10-09T05:47:30.000Z]**
Referencing `architecture_document.md` and `tech_stack_document.md`:
*   **TR-001: Frontend Framework**: The frontend SHALL be built using Angular (v16+) based on the existing boilerplate.
*   **TR-002: Backend Framework**: The backend SHALL be developed using Python (v3.9+) with Flask (v2.x).
*   **TR-003: Database**: PostgreSQL (v14+) SHALL be used for production data storage, with SQLite for local development.
*   **TR-004: ORM**: SQLAlchemy (v1.4+) with Alembic SHALL be used for database interactions and migrations in the backend.
*   **TR-005: API Design**: The backend SHALL expose a RESTful API with JSON as the data interchange format, adhering to the specified endpoints (`/api/v1/notes` for CRUD operations).
*   **TR-006: Modular Architecture**: The Angular frontend SHALL encapsulate note-related functionality within a lazy-loaded `NotesModule`.
*   **TR-007: Containerization**: Both frontend and backend applications SHALL be containerized using Docker.
*   **TR-008: Environment Management**: Separate configurations for development, testing, and production environments SHALL be maintained and securely managed.
*   **TR-009: Error Handling**: Both frontend and backend SHALL implement robust error handling mechanisms, providing generic error messages to the client and detailed logs internally.

## 11. Success Metrics & KPIs
**[2025-10-09T05:47:30.000Z]**
*   **Notes Created/User (Weekly Average)**: Measures core usage.
*   **Note View Load Time (Average)**: Measures user experience performance.
*   **CRUD Operation Success Rate**: Percentage of successful create/update/delete API calls (target: >99.5%).
*   **Application Uptime**: Percentage of time the application is available (target: >99.9%).
*   **Bug/Issue Count (Post-release)**: Number of critical/high severity bugs reported.

## 12. Risk Assessment
**[2025-10-09T05:47:30.000Z]**
*   **RA-001: Scope Creep**:
    *   **Risk**: Tendency to add non-MVP features, delaying release.
    *   **Mitigation**: Strict adherence to MVP definition, ruthless backlog prioritization, explicit "Out of Scope" list.
*   **RA-002: Performance Degradation (with many notes)**:
    *   **Risk**: Application slows down if a user has a very large number of notes.
    *   **Mitigation**: Database indexing on relevant columns (`userId`, `createdAt`), efficient API queries, frontend virtualization for long lists if needed, pagination (future enhancement).
*   **RA-003: Data Loss/Corruption**:
    *   **Risk**: Issues with database or backend leading to loss or corruption of user notes.
    *   **Mitigation**: Robust database backups, transactional API operations, comprehensive testing of persistence (US-006), database migration management (Alembic).
*   **RA-004: Security Vulnerabilities**:
    *   **Risk**: XSS, SQL injection, or other attacks compromising data or user experience.
    *   **Mitigation**: Strict input validation/sanitization (frontend and backend), HTTPS, adherence to secure coding practices.
*   **RA-005: Integration Challenges (Frontend/Backend)**:
    *   **Risk**: Mismatches in API contracts or data models cause delays.
    *   **Mitigation**: Clear API documentation, early and continuous integration testing, shared data model definitions (TypeScript interfaces, Python models).

## 13. Timeline & Milestones
**[2025-10-09T05:47:30.000Z]**
This project will follow an Agile Scrum methodology with 2-week sprints. The following is an estimated high-level timeline for the MVP:

*   **Week 1-2 (Sprint 1): Discovery & Backend Setup**
    *   Milestone: PRD finalized, Architecture & Tech Stack documents reviewed, Backend basic Flask app with database connection, Note model, and initial repository/service layers ready.
*   **Week 3-4 (Sprint 2): Core Backend API & Frontend Integration Setup**
    *   Milestone: Backend API endpoints for Create/Read Notes (list & detail) complete and unit/integration tested. Frontend `NotesModule` structure, components for listing/viewing notes, and `NotesService` for API interaction established.
*   **Week 5-6 (Sprint 3): Frontend CRUD & UI/UX Refinement**
    *   Milestone: Frontend components for Create/Edit/Delete Notes fully functional and integrated with the backend. UI/UX polished, adherence to Clarity Design System. Initial end-to-end tests for core flows.
*   **Week 7-8 (Sprint 4): Testing, Bug Fixing & Deployment Prep**
    *   Milestone: Comprehensive unit, integration, and end-to-end testing complete. All high-priority bugs resolved. Performance benchmarks met. Dockerization of frontend and backend applications finalized. CI/CD pipeline setup.
*   **Week 8 End (MVP Release)**
    *   Milestone: Simple Notes Taking App (MVP) deployed to staging/production environment.

## 14. Dependencies & Assumptions
**[2025-10-09T05:47:30.000Z]**
*   **Dependencies**:
    *   Availability of a stable Angular Clarity Boilerplate as the frontend foundation.
    *   Python 3.9+, Node.js LTS, npm, Docker installed on development machines.
    *   Access to a PostgreSQL database for production deployment.
    *   Backend API must be fully functional for frontend development to proceed beyond mocking.
*   **Assumptions**:
    *   Frontend and Backend development can proceed largely in parallel after initial API contract definition.
    *   Developers are proficient in Angular, TypeScript, Python, Flask, and SQL/ORM.
    *   Existing CI/CD infrastructure (e.g., GitHub Actions) is available and configurable.
    *   No external third-party integrations (e.g., cloud storage, external authentication providers) are required for MVP.
    *   Security hardening (e.g., WAF, advanced DDoS protection) will be handled at the infrastructure level for production.
