# io8 Project Manager Agent - Customized for This Project

## Project-Specific Instructions

```json
{
  "file_to_create": ".sureai/.io8pm_agent_weather_app_weather_app_20250926_094440.md",
  "file_content": "# io8 Product Manager (PM) Agent Instructions for Weather App Project\n\n## Project Management Methodology: Agile Scrum with Lean Principles\n\nFor the Weather App project, we will adopt an Agile Scrum methodology, complemented by Lean principles to ensure rapid iteration, continuous feedback, and delivery of maximum value with minimum waste.\n\n-   **Scrum Framework:** Organize work into sprints (e.g., 1-2 weeks), with daily stand-ups, sprint planning, sprint reviews, and retrospectives.\n-   **Lean Focus:** Emphasize identifying and eliminating waste (e.g., unnecessary features, excessive documentation, waiting time) to accelerate delivery.\n-   **User-Centric Development:** Maintain a strong focus on user stories and acceptance criteria, ensuring every feature directly addresses a user need.\n-   **Iterative & Incremental:** Build the product in small, manageable increments, allowing for early user feedback and adaptation.\n\n## PRD Development Approach: Iterative & Collaborative\n\nThe Product Requirements Document (PRD) will be a living document, evolving with project insights and feedback.\n\n1.  **Initial Draft (Current Task):** Create a comprehensive initial PRD based on the user prompt and existing `analysis_document.md`, `architecture_document.md`, and `tech_stack_document.md`. This draft will establish the core vision, requirements, and epic stories.\n2.  **Stakeholder Review:** Facilitate review sessions with relevant stakeholders (e.g., development lead, UX designer) to gather feedback and refine requirements.\n3.  **Prioritization Workshop:** Conduct a prioritization session for epics and user stories, potentially using techniques like MoSCoW (Must-have, Should-have, Could-have, Won't-have) or Value/Effort matrix.\n4.  **Continuous Refinement:** Update the PRD throughout the project lifecycle based on sprint outcomes, technical discoveries, and user feedback. Append new information with clear timestamps and section headers.\n\n## Project Planning Framework: Phased Release with MVP Focus\n\nThe project will follow a phased release strategy, prioritizing a Minimum Viable Product (MVP) that delivers core weather functionality, followed by subsequent iterations for enhancements.\n\n**Phases:**\n\n1.  **Phase 0: Foundation & Setup (Completed by Project Builder/Codermaster):** Establish boilerplate, directory structure, initial code.\n2.  **Phase 1: Discovery & Definition (Current PM Task):** Deep dive into requirements, architecture, tech stack, and create the detailed PRD.\n3.  **Phase 2: Core Backend Development:** Implement backend proxy endpoints, external API integration, and caching.\n4.  **Phase 3: Core Frontend Development:** Develop UI components for search, current weather, forecast display, and unit toggle using Clarity. Integrate with backend.\n5.  **Phase 4: Integration & Testing:** End-to-end testing of frontend-backend communication, error handling, performance.\n6.  **Phase 5: Deployment & Monitoring:** Containerization, cloud deployment, and setting up monitoring.\n7.  **Phase 6: Iteration & Enhancement:** Gather user feedback, analyze data, and plan for future features (e.g., more detailed forecasts, weather alerts, saved locations).\n\n## Timeline and Milestone Strategy\n\nThe project will aim for an MVP release within a realistic timeframe, with flexibility for adaptation.\n\n*   **Milestone 1: PRD Completion (End of Phase 1):** Detailed PRD reviewed and approved.\n*   **Milestone 2: Backend Proxy MVP (End of Phase 2):** Core backend endpoints (current weather, forecast) with API key security and basic caching functional.\n*   **Milestone 3: Frontend MVP (End of Phase 3):** Angular UI with search, current weather, forecast, and unit toggle, consuming data from the backend.\n*   **Milestone 4: Integrated & Tested MVP (End of Phase 4):** Full end-to-end functionality, passing key test cases, with robust error handling.\n*   **Milestone 5: Production Deployment (End of Phase 5):** Application live and accessible.\n\n## Customized io8 PM Workflow for Weather App Project\n\n1.  **Review & Synthesize:** Thoroughly review `analysis_document.md`, `architecture_document.md`, and `tech_stack_document.md` to understand the project's current state and proposed solutions.\n2.  **Elaborate PRD:** Develop the detailed Product Requirements Document (`.sureai/prd_document.md`) based on the provided structure and content from preceding agents. This involves:\n    *   Translating user and functional requirements into comprehensive sections.\n    *   Defining Epics and breaking them down into detailed User Stories with Acceptance Criteria, Story Points, and Priority.\n    *   Incorporating non-functional, UI, and technical requirements.\n    *   Adding risk assessment, timeline, and dependencies.\n3.  **Project Plan Outline:** Create a high-level project plan (`.sureai/project_plan.md`) outlining key phases, major tasks, and approximate timelines aligned with the PRD.\n4.  **Risk & Dependency Review:** Actively identify and document potential risks, dependencies, and assumptions inherent in the \"weather app\" extension, leveraging insights from the technical documents (e.g., external API reliability, geolocation permissions).\n5.  **Communication Preparation:** Prepare summary points for stakeholders to communicate the product vision, scope, and key decisions.\n6.  **Handover:** Ensure all created documents are clear, precise, and actionable for subsequent agents (e.g., `io8codermaster`, `io8designer`, `io8tester`).\n\n**Key Instructions:**\n\n*   **Prioritize User Stories:** Ensure the initial epics and user stories reflect the core MVP functionality for a weather app, focusing on location search, current weather, and multi-day forecast.\n*   **Clarity UI Integration:** Explicitly mention the use of Clarity Design System components where appropriate in UI requirements and user stories to maintain consistency with the boilerplate.\n*   **Backend Proxy Emphasis:** Highlight the role of the Node.js/Express.js backend proxy in the solution overview and technical requirements, emphasizing its security and abstraction benefits.\n*   **Containerization & Deployment:** Include Docker and cloud deployment in technical requirements and the project plan for the full-stack nature of the extended application.\n*   **Data Models:** Reference the TypeScript interfaces defined in the architecture document for data consistency.\n*   **Acceptance Criteria Precision:** Ensure acceptance criteria for user stories are specific, measurable, achievable, relevant, and time-bound (SMART).\n",
  "prd": "\n\n# Product Requirements Document (PRD)\n\n## 1. Executive Summary\nGenerated: 2025-09-26 10:05:00\nThis document outlines the requirements for extending the existing Angular Clarity Boilerplate into a fully functional and user-friendly Weather Application. The project aims to provide immediate and reliable access to current weather conditions and multi-day forecasts for user-specified locations, demonstrating full-stack integration with a secure backend proxy and a responsive frontend built using Angular and the Clarity Design System.\n\n## 2. Product Vision & Strategy\nGenerated: 2025-09-26 10:05:00\n**Product Vision:** To empower users with quick, accurate, and intuitive weather information while serving as a robust, real-world example of a scalable Angular application built on the Clarity Design System, integrating secure backend services and external APIs.\n\n**Strategic Goals:**\n- Deliver a Minimum Viable Product (MVP) capable of displaying current weather and multi-day forecasts for searched locations.\n- Ensure secure handling of external API keys via a dedicated backend proxy.\n- Provide a highly usable and responsive interface consistent with the Clarity Design System.\n- Showcase best practices for full-stack integration, including containerization and cloud deployment readiness.\n\n**Success Metrics:**\n- **Performance:** Display current weather within 3 seconds, forecast data within 5 seconds of a successful search query.\n- **Reliability:** 99.5% uptime for the backend proxy and external API integration.\n- **User Engagement (Hypothetical):** High rates of location search and forecast viewing (if tracking implemented).\n- **Developer Feedback (Boilerplate Aspect):** Positive feedback on the clarity, maintainability, and extensibility of the codebase as a demonstration.\n\n## 3. Target Users & Personas\nGenerated: 2025-09-26 10:05:00\n**Primary User: The Everyday Planner**\n- **Demographics:** General web users, individuals planning daily activities, travelers.\n- **Needs:** Quick access to current weather, reliable multi-day forecasts for specific locations, easy-to-understand interface, preferred temperature units.\n- **Goal:** To make informed decisions about clothing, travel, and activities based on accurate weather predictions.\n\n**Secondary User: The Angular Developer (for boilerplate demonstration)**\n- **Demographics:** Mid-to-senior level Angular developers, development teams.\n- **Needs:** A well-structured, maintainable, and scalable Angular project example; clear demonstration of external API integration, backend proxy usage, state management, and Clarity UI component implementation.\n- **Goal:** To leverage the project as a learning resource or a foundation for their own enterprise-grade applications.\n\n## 4. Problem Statement\nGenerated: 2025-09-26 10:05:00\nUsers require a fast, accurate, and intuitive way to access current and forecasted weather information for specific locations. Existing solutions may lack a consistent user experience, secure backend integration, or robust error handling. For developers, there's a need for a comprehensive, real-world application built on an Angular Clarity boilerplate that effectively demonstrates full-stack development patterns, including secure external API interaction and scalable architecture.\n\n## 5. Solution Overview\nGenerated: 2025-09-26 10:05:00\nThe Weather App will be a client-server application consisting of an Angular frontend and a Node.js/Express.js backend proxy. The frontend, leveraging the Clarity Design System, will provide a responsive user interface for searching locations, displaying current weather, and multi-day forecasts, along with unit conversion. The backend proxy will securely interact with an external weather API (e.g., OpenWeatherMap), manage API keys, perform data transformation, and implement caching (using Redis) to optimize performance and reduce external API calls. Both frontend and backend services will be containerized using Docker for simplified deployment to cloud platforms.\n\n## 6. Functional Requirements\nGenerated: 2025-09-26 10:05:00\n-   **FR-001 (Display Current Weather):** The system shall display the current weather conditions, including temperature, conditions description, humidity, and wind speed, for a selected location.\n-   **FR-002 (Search by Location):** The system shall allow users to search for weather by entering a city name.\n-   **FR-003 (Geolocation Search):** The system shall provide an option for users to fetch weather data for their current device location.\n-   **FR-004 (Display Multi-Day Forecast):** The system shall display a forecast for multiple upcoming days (e.g., 5-7 days).\n-   **FR-005 (Unit Conversion):** The system shall allow users to switch between Celsius and Fahrenheit temperature units.\n-   **FR-006 (Loading Indicators):** The system shall provide visual cues (loading indicators) while fetching data to inform the user of ongoing operations.\n-   **FR-007 (Error Feedback):** The system shall display clear and informative feedback to users when a location is not found, if there are issues fetching weather data, or for other API/network errors.\n-   **FR-008 (External Weather API Integration):** The backend proxy shall integrate with a reliable third-party weather API (e.g., OpenWeatherMap) to fetch current and forecast weather data.\n-   **FR-009 (Backend Proxy Endpoints):** The backend proxy shall provide distinct RESTful API endpoints for current weather (`/api/current-weather`) and multi-day forecast (`/api/forecast`).\n\n## 7. Non-Functional Requirements\nGenerated: 2025-09-26 10:05:00\n-   **NFR-001 (Performance):**\n    *   The application shall display current weather data within 3 seconds of a successful search query.\n    *   Forecast data shall be displayed within 5 seconds of a successful forecast query.\n    *   The backend proxy should introduce minimal latency (e.g., <100ms per request).\n-   **NFR-002 (Security):**\n    *   External weather API keys shall be stored securely on the backend (e.g., environment variables) and not exposed to the client-side.\n    *   All communication between the frontend and backend shall use HTTPS.\n-   **NFR-003 (Usability):**\n    *   The user interface shall be intuitive and easy to navigate, adhering to Clarity Design System guidelines.\n    *   The application shall be responsive and function correctly across various device sizes (desktop, tablet, mobile).\n    *   Error messages shall be clear, concise, and actionable.\n-   **NFR-004 (Reliability):**\n    *   The backend proxy shall implement robust error handling for external API failures, returning appropriate status codes and messages to the frontend.\n    *   The application shall remain functional even if a specific weather data point is missing from the API response (graceful degradation).\n-   **NFR-005 (Scalability):**\n    *   The backend service shall be designed to handle a moderate load of concurrent users (e.g., up to 100 concurrent requests) with potential for future scaling via caching or load balancing.\n    *   The architecture should allow for easy addition of new weather data providers or features.\n-   **NFR-006 (Maintainability):**\n    *   The codebase shall be well-documented, adhering to Angular and backend framework coding standards.\n    *   Modules and components shall be logically structured and easily extensible.\n\n## 8. Epic Stories\nGenerated: 2025-09-26 10:05:00\n\n### Epic 1: Location-Based Weather Display\n**Epic Description:** Enable users to easily find and view current weather information for any desired location, including their own.\n**Business Value:** Provides immediate utility to users, fulfilling the primary function of a weather application, and showcases core frontend-to-backend integration.\n**Acceptance Criteria:** Users can successfully retrieve and view current weather details for a searched city or their current location.\n\n**User Stories:**\n- **US-001:** View Current Weather for a Specific Location\n  - **As a** user\n  - **I want to** search for a city by name and see its current weather conditions\n  - **So that** I can quickly get up-to-date weather information for any desired location.\n  - **Acceptance Criteria:**\n    - [ ] The application displays a prominent search bar.\n    - [ ] When I type a valid city name (e.g., \"London\") and submit, the application displays the current temperature, weather description (e.g., \"Sunny\"), humidity, and wind speed for that city.\n    - [ ] The displayed weather information is visually appealing and consistent with Clarity Design.\n  - **Story Points:** 8\n  - **Priority:** High\n\n- **US-004:** Use Current Location for Weather\n  - **As a** user\n  - **I want to** quickly see the weather for my current location\n  - **So that** I can get relevant information without typing.\n  - **Acceptance Criteria:**\n    - [ ] The application provides a clear option (e.g., a button) to use my current location.\n    - [ ] Upon granting browser's geolocation permission, the application fetches and displays the current weather for my detected location.\n    - [ ] If geolocation fails or permission is denied, an informative message is displayed to the user.\n  - **Story Points:** 8\n  - **Priority:** High\n\n### Epic 2: Forecast & Unit Management\n**Epic Description:** Allow users to plan ahead by providing multi-day weather forecasts and personalizing temperature unit preferences.\n**Business Value:** Enhances the app's utility for planning and improves user experience by catering to individual measurement system preferences.\n**Acceptance Criteria:** Users can view future weather conditions and toggle between Celsius and Fahrenheit units.\n\n**User Stories:**\n- **US-002:** View Multi-Day Weather Forecast\n  - **As a** user\n  - **I want to** see a forecast for the upcoming days for my selected location\n  - **So that** I can plan my activities for the week ahead.\n  - **Acceptance Criteria:**\n    - [ ] After searching for a location, the application displays a list of daily forecasts (e.g., for the next 5-7 days) below the current weather.\n    - [ ] Each forecast entry includes the day, date, high and low temperatures, and a relevant weather icon/description.\n    - [ ] The forecast list is responsive and easy to read.\n  - **Story Points:** 8\n  - **Priority:** High\n\n- **US-003:** Switch Temperature Units\n  - **As a** user\n  - **I want to** be able to switch between Celsius and Fahrenheit temperature units\n  - **So that** I can view weather data in my preferred measurement system.\n  - **Acceptance Criteria:**\n    - [ ] The application provides a visible toggle or button (e.g., a Clarity toggle switch) to switch temperature units.\n    - [ ] When I click the toggle, all displayed temperatures (current and forecast) instantaneously switch between Celsius and Fahrenheit.\n    - [ ] The selected unit persists during my session (e.g., using local storage).\n  - **Story Points:** 5\n  - **Priority:** Medium\n\n### Epic 3: System Resilience & User Feedback\n**Epic Description:** Ensure users are informed about the application's state and any issues, providing a robust and trustworthy experience.\n**Business Value:** Improves user satisfaction and trust by proactively communicating system status and handling errors gracefully.\n**Acceptance Criteria:** Users receive clear feedback during data loading and when errors occur.\n\n**User Stories:**\n- **US-005:** Understand Data Fetching Status and Errors\n  - **As a** user\n  - **I want to** receive clear feedback when data is loading or an error occurs\n  - **So that** I can understand the application's state and troubleshoot issues.\n  - **Acceptance Criteria:**\n    - [ ] When the application is fetching weather data, a prominent loading indicator (e.g., Clarity Spinner) is displayed in the relevant UI sections.\n    - [ ] If a network error occurs or the external API is unreachable, a user-friendly error message (e.g., \"Could not fetch weather data. Please try again later.\") is displayed.\n    - [ ] If an invalid search term is entered and no location is found, a specific message like \"Location not found. Please try another city.\" is displayed.\n    - [ ] Error messages are dismissible or disappear after a short period.\n  - **Story Points:** 5\n  - **Priority:** High\n\n## 9. User Interface Requirements\nGenerated: 2025-09-26 10:05:00\n-   **Clarity Design System Adherence:** All UI components and styling must strictly follow the VMware Clarity Design System guidelines to maintain a consistent look and feel with the base boilerplate.\n-   **Responsive Layout:** The application layout must be fully responsive, adapting seamlessly to various screen sizes, from mobile devices to large desktop monitors.\n-   **Main Layout:** Utilize the existing Angular Clarity Boilerplate's header, sidebar (if applicable for future features, though initially not prominent for weather), and main content area.\n-   **Search Bar:** A prominent input field (Clarity Input) for location search, possibly with an associated search button (Clarity Button).\n-   **Current Weather Card:** Display current weather information within a Clarity Card component, featuring: city name, temperature, weather condition icon/description, humidity, and wind speed.\n-   **Forecast List:** A scrollable list of daily forecasts, potentially using Clarity List or multiple small Clarity Card components for each day, including date, high/low temperature, and weather icon/description.\n-   **Temperature Unit Toggle:** A clear toggle switch (Clarity Toggle) or segmented button (Clarity Button Group) to switch between Celsius and Fahrenheit.\n-   **Loading Indicators:** Implement Clarity Spinner components for all data loading states.\n-   **Error Messages:** Display error and informational messages using Clarity Alert components or toast notifications.\n-   **Weather Icons:** Utilize a consistent set of weather icons (e.g., Font Awesome, custom SVGs) to visually represent weather conditions.\n\n## 10. Technical Requirements\nGenerated: 2025-09-26 10:05:00\n-   **Frontend (Angular):**\n    *   Utilize Angular v16+ and the existing boilerplate structure (CoreModule, SharedModule, Feature Modules).\n    *   Implement `HttpClient` for all API interactions with the backend proxy.\n    *   Manage application state using Angular Services with RxJS for reactive data flows.\n    *   Integrate browser's Geolocation API for location detection.\n    *   Adhere to TypeScript interfaces (`Location`, `CurrentWeather`, `ForecastDay`) for strong data typing.\n-   **Backend (Node.js/Express.js Proxy):**\n    *   Develop using Node.js v18+ and Express.js v4+.\n    *   Create RESTful API endpoints for `/api/current-weather` and `/api/forecast`.\n    *   Implement secure handling of external weather API keys using environment variables (`dotenv`).\n    *   Integrate with an external weather API (e.g., OpenWeatherMap) using `axios` or `node-fetch`.\n    *   Perform data transformation from external API responses to internal frontend data models.\n    *   Configure CORS to allow requests only from the Angular frontend's domain.\n-   **Caching (Redis):**\n    *   Implement Redis v6+ as an in-memory data store for caching weather data on the backend proxy.\n    *   Cache keys should be location and unit-specific, with configurable TTL to ensure data freshness.\n-   **Deployment & Infrastructure:**\n    *   Containerize both the Angular frontend and Node.js/Express.js backend using Docker.\n    *   Provide `docker-compose.yml` for simplified local development and orchestration.\n    *   The application should be deployable to cloud container services (e.g., AWS Fargate, Azure Container Instances, Google Cloud Run).\n-   **Security:**\n    *   All communication over HTTPS.\n    *   Robust input validation on both frontend and backend to prevent malicious inputs.\n    *   Backend should sanitize all parameters before forwarding to external API.\n-   **Error Handling:** Implement global HTTP interceptors in Angular for frontend error management and centralized error handling within the backend proxy.\n\n## 11. Success Metrics & KPIs\nGenerated: 2025-09-26 10:05:00\n-   **Response Time (Frontend):** Average time to display current weather < 3 seconds; average time to display forecast < 5 seconds.\n-   **Backend Latency:** Average backend proxy response time < 100 ms.\n-   **API Call Efficiency:** Number of external weather API calls reduced by X% due to caching (baseline to be established).\n-   **Uptime:** 99.9% availability for the Weather App service.\n-   **Error Rate:** Less than 0.1% of API requests resulting in client-facing errors (excluding invalid user input).\n-   **User Feedback:** Positive qualitative feedback on usability and accuracy.\n\n## 12. Risk Assessment\nGenerated: 2025-09-26 10:05:00\n-   **External API Dependency:**\n    *   **Risk:** External weather API downtime, rate limit issues, or changes to API structure.\n    *   **Mitigation:** Implement robust error handling, retry mechanisms, caching, and potentially support for multiple weather API providers in future iterations. Monitor API status.\n-   **Geolocation Permissions:**\n    *   **Risk:** Users may deny geolocation permissions, impacting the "current location" feature.\n    *   **Mitigation:** Provide clear explanations for permission requests and gracefully fallback to manual search if denied.\n-   **API Key Security:**\n    *   **Risk:** Exposure of external API keys if not handled securely on the backend.\n    *   **Mitigation:** Strictly enforce environment variable usage for API keys and restrict access to backend configuration.\n-   **Performance Bottlenecks:**\n    *   **Risk:** Slow response times due to inefficient data processing or network latency.\n    *   **Mitigation:** Optimize backend service logic, aggressive caching with Redis, efficient Angular change detection, and bundle optimization.\n-   **CORS Issues:**\n    *   **Risk:** Misconfiguration of CORS on the backend preventing frontend communication.\n    *   **Mitigation:** Rigorous testing of CORS setup during development and deployment, ensuring correct allowed origins.\n\n## 13. Timeline & Milestones\nGenerated: 2025-09-26 10:05:00\n**Phase 1: Discovery & Definition (Current)**\n- **Duration:** 1 week\n- **Milestone:** PRD Completion & Approval.\n\n**Phase 2: Core Backend Development**\n- **Duration:** 2-3 weeks\n- **Milestone:** Backend Proxy MVP (Current weather & forecast endpoints, API integration, basic caching).\n\n**Phase 3: Core Frontend Development**\n- **Duration:** 3-4 weeks\n- **Milestone:** Frontend MVP (Search, current weather display, forecast list, unit toggle, integrated with backend).\n\n**Phase 4: Integration, Testing & Refinement**\n- **Duration:** 1-2 weeks\n- **Milestone:** Integrated & Tested MVP (End-to-end functionality, error handling, responsiveness).\n\n**Phase 5: Deployment Readiness & Initial Launch**\n- **Duration:** 1 week\n- **Milestone:** Production Deployment (Containerization, cloud setup, monitoring).\n\n## 14. Dependencies & Assumptions\nGenerated: 2025-09-26 10:05:00\n-   **External Weather API:** Assumption of consistent availability, stable API endpoints, and adherence to specified rate limits for the chosen provider (e.g., OpenWeatherMap).\n-   **Angular Clarity Boilerplate:** Dependency on the stability and correct setup of the initial boilerplate for frontend development.\n-   **Node.js/Express.js:** Availability of Node.js and Express.js ecosystem for backend development.\n-   **Redis Service:** Availability of a Redis instance for caching in both development and production environments.\n-   **Browser Features:** User's browser supports Geolocation API and standard web features.\n-   **Development Environment:** Developers have necessary tools (Node.js, npm/yarn, Angular CLI, Docker) installed and configured.\n-   **Cloud Infrastructure:** Access to a configured cloud provider (AWS, Azure, GCP) for container deployment.\n-   **Security Policies:** Adherence to organizational security policies for API key management and data handling.\n",
  "project_plan": "\n\n# Project Plan: Weather Application Extension\nGenerated: 2025-09-26 10:05:00\n\n## Project Goal\nTo deliver a fully functional, user-friendly, and secure Weather Application by extending the Angular Clarity Boilerplate, demonstrating robust full-stack integration and best practices.\n\n## Phases & Key Activities\n\n### Phase 1: Discovery & Definition (Current - PM Lead)\n*   **Objective:** Establish a clear product vision, detailed requirements, and architectural blueprint.\n*   **Activities:**\n    *   Review and synthesize existing `analysis_document.md`, `architecture_document.md`, and `tech_stack_document.md`.\n    *   Create comprehensive `prd_document.md` including functional, non-functional requirements, and detailed user stories/epics.\n    *   Outline high-level project plan, timeline, risks, and dependencies.\n*   **Deliverables:** Finalized `prd_document.md`, initial `project_plan.md`.\n*   **Estimated Duration:** 1 week.\n\n### Phase 2: Core Backend Development (Developer Lead - io8codermaster, io8architect)\n*   **Objective:** Implement the secure backend proxy for weather data retrieval and caching.\n*   **Activities:**\n    *   Set up Node.js/Express.js project structure.\n    *   Integrate with external weather API (e.g., OpenWeatherMap).\n    *   Develop API endpoints for current weather and forecast data.\n    *   Implement data transformation and sanitization logic.\n    *   Integrate Redis for data caching.\n    *   Implement API key security and CORS configuration.\n*   **Deliverables:** Functional backend proxy API, Dockerfile for backend service, unit tests for backend logic.\n*   **Estimated Duration:** 2-3 weeks.\n\n### Phase 3: Core Frontend Development (Developer Lead - io8codermaster, io8designer)\n*   **Objective:** Build the user interface and frontend logic for weather data display and interaction.\n*   **Activities:**\n    *   Set up `WeatherFeatureModule` in Angular.\n    *   Develop `LocationSearchComponent`, `CurrentWeatherCardComponent`, `ForecastListComponent`, `TemperatureUnitToggleComponent` using Clarity Design System.\n    *   Implement `WeatherApiService` to communicate with the backend proxy.\n    *   Integrate Geolocation API functionality.\n    *   Implement unit conversion logic and display.\n*   **Deliverables:** Responsive Angular frontend components, integration with backend, initial end-to-end user flows.\n*   **Estimated Duration:** 3-4 weeks.\n\n### Phase 4: Integration, Testing & Refinement (QA Lead - io8tester, io8codermaster)\n*   **Objective:** Ensure seamless integration between frontend and backend, validate all requirements, and identify/fix bugs.\n*   **Activities:**\n    *   Perform end-to-end testing of core user flows (search, current weather, forecast, unit toggle, geolocation).\n    *   Test error handling and loading states across the application.\n    *   Conduct performance testing against NFRs (response times).\n    *   Address accessibility (WCAG) considerations for Clarity components.\n    *   Refine UI/UX based on testing feedback.\n*   **Deliverables:** Comprehensive test reports, resolved bugs, performance metrics, refined application.\n*   **Estimated Duration:** 1-2 weeks.\n\n### Phase 5: Deployment Readiness & Initial Launch (DevOps Lead - io8project_builder, io8codermaster)\n*   **Objective:** Prepare the application for production deployment and launch the MVP.\n*   **Activities:**\n    *   Finalize Dockerfiles for both frontend and backend.\n    *   Create `docker-compose.yml` for production environment deployment.\n    *   Set up CI/CD pipelines (e.g., GitHub Actions) for automated build, test, and deployment.\n    *   Configure cloud infrastructure (e.g., AWS Fargate, Redis).\n    *   Implement logging and monitoring solutions.\n*   **Deliverables:** Production-ready Docker images, deployed application, monitoring dashboards, launch communication.\n*   **Estimated Duration:** 1 week.\n\n## High-Level Timeline (Tentative)\n*   **Week 1:** Phase 1 (Discovery & Definition)\n*   **Weeks 2-4:** Phase 2 (Core Backend Development)\n*   **Weeks 5-8:** Phase 3 (Core Frontend Development)\n*   **Weeks 9-10:** Phase 4 (Integration, Testing & Refinement)\n*   **Week 11:** Phase 5 (Deployment Readiness & Launch)\n\n## Key Stakeholders\n*   **io8 Product Manager (PM):** Overall product vision, requirements, prioritization.\n*   **io8 Codermaster (Dev Lead):** Technical architecture, implementation, code quality.\n*   **io8 Architect (Architect):** System design, scalability, security.\n*   **io8 Analyst (BA):** Detailed business and user requirements.\n*   **io8 Tester (QA):** Testing strategy, test case creation, defect management.\n*   **io8 Project Builder (DevOps/Infra):** Infrastructure, deployment, CI/CD.\n\n## Communication Plan\n*   **Daily Stand-ups:** Short, daily syncs (15 mins) on progress, blockers, and next steps.\n*   **Sprint Planning:** Bi-weekly sessions to plan sprint backlog.\n*   **Sprint Review:** Bi-weekly demos of completed work to gather feedback.\n*   **Sprint Retrospective:** Bi-weekly internal team meeting for continuous improvement.\n*   **Regular PRD Updates:** PM to ensure `prd_document.md` is always current and reviewed.\n\n## Key Risks & Mitigation\n(See `prd_document.md` - Section 12: Risk Assessment for detailed information)\n"
}
```

## Base Agent Prompt Reference

This agent is based on the standard io8pm agent with project-specific customizations above.
Refer to the base io8pm agent prompt for general PM principles and workflow instructions.
