# io8 System Architect Agent - Customized for This Project

## Project-Specific Instructions

```markdown
# io8Architect Agent Prompt - To Do App Project
Generated: 2025-10-01T04:40:40.000Z

## Project Context
This project extends an existing Angular Clarity Boilerplate with a new "To Do App" feature. The primary goal is to integrate a simple yet fully functional task management application into the boilerplate's modular structure, adhering to its established architectural principles and leveraging the Clarity Design System.

## Architecture Design Methodology
The design will follow an evolutionary and incremental approach, building upon the foundational Angular Clarity Boilerplate. Key principles include:
- **Modular Feature Development:** The "To Do App" will be implemented as a lazy-loaded Angular Feature Module to ensure separation of concerns and maintainability.
- **Component-Service Pattern:** Within the feature module, a clear separation between UI components and data management services will be enforced.
- **Client-Side Persistence First:** For the initial iteration, task data will be managed purely client-side using browser's `localStorage` to meet immediate user story requirements without introducing a backend dependency. This allows for rapid development and demonstration.
- **Clarity UI Adoption:** All UI elements for the To Do App will exclusively use components and styles provided by the VMware Clarity Design System, ensuring consistency with the boilerplate.

## Technical Architecture Approach
The "To Do App" will be integrated as follows:

### 1. Feature Module (`TodoModule`)
- A dedicated `TodoModule` will encapsulate all components, services, and routing related to the To Do App.
- This module will be lazy-loaded via the `AppRoutingModule` to optimize initial bundle size.

### 2. Component Hierarchy
- **`TodoPageComponent`:** The main entry component for the To Do feature, responsible for orchestrating other components (input, list, filters, if applicable).
- **`TodoInputComponent`:** Contains the input field and "Add Task" button for creating new tasks, handling input validation as per US-001.
- **`TodoListComponent`:** Displays the collection of `TodoItemComponent` instances, handling the visual distinction between active and completed tasks (US-002).
- **`TodoItemComponent`:** Represents an individual task, displaying its description, completion status (e.g., checkbox for US-003), and a "Delete" button (US-004).

### 3. Data Management (`TodoService`)
- A `TodoService` (provided in the `TodoModule`) will manage the lifecycle of tasks (add, view, complete, delete).
- It will utilize `localStorage` for persistent storage of tasks on the client-side.
- The service will expose tasks as an observable stream (e.g., `BehaviorSubject` from RxJS) to allow components to reactively update the UI, ensuring that US-002, US-003, and US-004 criteria for immediate UI updates are met.
- Unique IDs for tasks will be generated within this service.

### 4. Data Model (`Task` Interface)
- A TypeScript interface `Task` will define the structure of a To Do item, including `id: string`, `description: string`, `completed: boolean`, and `createdAt: Date`. This aligns with the base project's data requirements for TypeScript interfaces.

### 5. Routing
- A new route entry will be added to the `AppRoutingModule` to lazy-load the `TodoModule`, e.g., `/todos`. This aligns with FR-005.

## System Design Framework
The overall system design will continue to adhere to the Angular best practices established by the boilerplate:
- **Modular Design:** `CoreModule` for global services, `SharedModule` for reusable UI elements, and `FeatureModules` (like `TodoModule`) for domain-specific functionality. This directly follows FR-002.
- **Reactive Programming:** Leveraging RxJS Observables for state management within the `TodoService` and communication between components.
- **Component-Based UI:** Building the interface from small, focused, and reusable components that integrate with the Clarity Design System (FR-003).

## Technology Selection Strategy
The technology selection will prioritize maintaining consistency with the existing Angular Clarity Boilerplate while introducing minimal new dependencies.

### Core Technologies (Existing & Confirmed)
- **Frontend Framework:** Angular
- **UI Component Library:** VMware Clarity Design System
- **Language:** TypeScript
- **Reactive Programming:** RxJS

### Specific Additions/Considerations for To Do App
- **Client-Side Persistence:** `localStorage` API (native browser feature) for task data storage. This is a pragmatic choice given no backend is specified and aligns with the boilerplate's backend-agnostic nature.
- **Unique ID Generation:** A simple utility for generating unique IDs for tasks (e.g., `Date.now().toString()` combined with a random number, or a lightweight UUID library if stronger guarantees are needed).

## Customized io8Architect Workflow for this Project
1.  **Review Base Project Documents:** Re-affirm understanding of `analysis_document.md` and `requirements_document.md` for the Angular Clarity Boilerplate to ensure seamless integration.
2.  **Analyze User Stories:** Deep dive into the `requirements_document.md` updates for "To Do App" user stories (US-001 to US-004) to derive specific functional and UI requirements.
3.  **Define Feature Module:** Design the `TodoModule` structure, its lazy-loading mechanism, and its integration point into the main application's routing.
4.  **Component & Service Design:** Detail the specific components (`TodoInputComponent`, `TodoListComponent`, `TodoItemComponent`, `TodoPageComponent`) and their responsibilities. Design the `TodoService` to manage task data, including CRUD operations.
5.  **Data Flow & Persistence:** Outline how tasks will be added, retrieved, updated, and deleted, specifying `localStorage` as the persistence mechanism and defining the `Task` data model.
6.  **UI/UX Implementation:** Ensure all To Do App UI elements are designed using Clarity components and adhere to the boilerplate's established styling and responsive layout (FR-004).
7.  **Output Architecture & Tech Stack:** Generate content for `architecture_document.md` and `tech_stack_document.md` detailing these decisions, appending to existing sections in the `.sureai/` directory.
```
{
  "architecture": "\n\n# Architecture Document Update\nGenerated: 2025-10-01T04:40:40.000Z\n\n## System Overview - To Do App Feature\nThe \"To Do App\" will be integrated as a new, self-contained feature within the existing Angular Clarity Boilerplate. It will provide core task management functionalities including adding new tasks, viewing active and completed tasks, marking tasks as complete, and deleting tasks. This feature will leverage the boilerplate's modular architecture, Angular's reactive capabilities, and the Clarity Design System for its user interface, primarily utilizing client-side local storage for data persistence.\n\n## Architecture Pattern - To Do App Feature\nThe To Do App will adhere to the existing boilerplate's modular architecture, implementing the functionality within a dedicated **Lazy-Loaded Feature Module**. This module will follow a clear **Component-Service Pattern**, where UI components are responsible for presentation and user interaction, and a dedicated service handles data logic and persistence.\n\n## Component Design - To Do App Feature\n\n### TodoModule (Feature Module)\n-   **Purpose:** Encapsulates all components, services, and routing for the To Do App feature.\n-   **Loading:** Lazy-loaded via the `AppRoutingModule`.\n\n### Components\n-   **`TodoPageComponent`**\n    -   **Role:** The main container component for the To Do feature. Orchestrates the `TodoInputComponent` and `TodoListComponent`.\n    -   **Responsibilities:** Connects `TodoInputComponent` with the `TodoService` for adding tasks and passes task data from `TodoService` to `TodoListComponent`.\n-   **`TodoInputComponent`**\n    -   **Role:** Handles user input for adding new tasks.\n    -   **Responsibilities:**\n        -   Provides an input field for task descriptions.\n        -   Includes an \"Add Task\" button.\n        -   Handles 'Enter' key press for adding tasks (US-001).\n        -   Validates input to prevent empty tasks (US-001).\n        -   Emits an event with the new task description to `TodoPageComponent`.\n-   **`TodoListComponent`**\n    -   **Role:** Displays the collection of tasks.\n    -   **Responsibilities:**\n        -   Receives a list of `Task` objects as input.\n        -   Iterates through the tasks and renders an `TodoItemComponent` for each.\n        -   Visually distinguishes between active and completed tasks (US-002).\n        -   Displays tasks in a logical order (e.g., by creation date, US-002).\n-   **`TodoItemComponent`**\n    -   **Role:** Renders a single task item.\n    -   **Responsibilities:**\n        -   Displays the task description.\n        -   Includes a control (e.g., checkbox) to mark a task as complete/incomplete (US-003).\n        -   Includes a \"Delete\" button/icon for task removal (US-004).\n        -   Emits events for task completion status changes and task deletion requests to `TodoListComponent` or directly to `TodoService`.\n\n## Data Architecture - To Do App Feature\n\n### Data Model\n-   **`Task` Interface (TypeScript):**\n    ```typescript\n    interface Task {\n        id: string; // Unique identifier for the task\n        description: string; // The text content of the task\n        completed: boolean; // Status: true if completed, false otherwise\n        createdAt: Date; // Timestamp of task creation for ordering\n    }\n    ```\n\n### Data Service (`TodoService`)\n-   **Role:** Manages all CRUD operations for tasks.\n-   **Responsibilities:**\n    -   Provides methods for `addTask(description: string)`, `toggleTaskComplete(id: string)`, `deleteTask(id: string)`.\n    -   Manages an internal collection of `Task` objects.\n    -   Exposes the current list of tasks as an RxJS `BehaviorSubject` or `Observable` for reactive UI updates.\n    -   Handles persistence of tasks to `localStorage`.\n    -   Generates unique `id` for new tasks.\n\n### Persistence\n-   **Mechanism:** Client-side `localStorage` (Web Storage API).\n-   **Storage Format:** Tasks will be serialized to JSON strings before being stored in `localStorage` under a specific key (e.g., `'todo_tasks'`).\n-   **Loading:** On application initialization (or `TodoService` instantiation), tasks will be loaded from `localStorage`.\n-   **Saving:** Any modification (add, update, delete) to the task list will trigger an update to `localStorage`.\n\n### Data Flow\n1.  **Add Task:** `TodoInputComponent` emits description -> `TodoPageComponent` receives -> calls `TodoService.addTask()` -> `TodoService` updates internal state and `localStorage` -> `TodoService`'s observable emits new task list.\n2.  **View Tasks:** `TodoPageComponent` subscribes to `TodoService`'s task observable -> `TodoListComponent` receives tasks as input -> renders `TodoItemComponent`s.\n3.  **Mark Complete:** `TodoItemComponent` emits toggle event -> `TodoPageComponent` (or direct call) calls `TodoService.toggleTaskComplete()` -> `TodoService` updates internal state and `localStorage` -> `TodoService`'s observable emits updated task list.\n4.  **Delete Task:** `TodoItemComponent` emits delete event -> `TodoPageComponent` (or direct call) calls `TodoService.deleteTask()` -> `TodoService` updates internal state and `localStorage` -> `TodoService`'s observable emits updated task list.\n\n## API Design - To Do App Feature\nFor the initial implementation, the To Do App will not interact with a backend API. All data operations are handled client-side by the `TodoService` using `localStorage`. This adheres to the boilerplate's backend-agnostic nature while meeting immediate user requirements.\n\nShould a backend API become a requirement in the future, the `TodoService` can be refactored to use Angular's `HttpClient` to communicate with RESTful endpoints, without requiring significant changes to the UI components.\n\n## Security Architecture - To Do App Feature\nGiven the client-side persistence approach with `localStorage`, security considerations are primarily focused on standard frontend best practices:\n-   **XSS Protection:** Angular's built-in sanitization will protect against Cross-Site Scripting (XSS) attacks in displayed task descriptions.\n-   **Data Sensitivity:** Since data is stored in `localStorage`, it is accessible to the client-side browser and browser extensions. This is acceptable for a personal To Do app but would require a backend and proper authentication/authorization for sensitive data or multi-user scenarios.\n-   No new backend security measures are introduced as there is no server-side component for this feature.\n\n## Scalability Considerations - To Do App Feature\n-   **Modular Design:** The To Do App as a lazy-loaded feature module ensures it can be developed, tested, and maintained independently, enhancing overall application scalability and extensibility (NFR-003, NFR-004).\n-   **Client-Side Persistence:** Using `localStorage` is suitable for individual users with a limited number of tasks. For enterprise-scale applications or multi-user support, the `TodoService` is designed to be easily swappable with an API-driven implementation for backend persistence.\n-   **Performance:** The use of RxJS and efficient component rendering will ensure a responsive user experience for typical task list sizes. The lazy-loading of the `TodoModule` will also contribute to faster initial load times for the main application.",
  "tech_stack": "\n\n# Technology Stack Document Update\nGenerated: 2025-10-01T04:40:40.000Z\n\n## To Do App Specific Technologies\nThis section details specific technologies and approaches introduced or emphasized for the new \"To Do App\" feature, building upon the established Angular Clarity Boilerplate.\n\n### Frontend Technologies\n-   **State Management:** For managing the list of tasks and their changes, the `TodoService` will utilize **RxJS `BehaviorSubject`** or `ReplaySubject` to provide an observable stream of tasks to subscribing components. This allows for reactive updates throughout the To Do App.\n-   **Persistence:** The **Web Storage API (`localStorage`)** will be used for client-side data persistence. This allows tasks to be saved in the user's browser and persist across browser sessions without requiring a backend database or API.\n    -   **Data Serialization:** JSON `stringify()` and `parse()` will be used to store and retrieve `Task` objects as strings in `localStorage`.\n\n### Backend Technologies\n-   **N/A:** The initial \"To Do App\" feature will operate entirely client-side, making no direct backend calls or requiring specific backend technologies. The `TodoService` abstraction allows for future integration with any RESTful backend if needed.\n\n### Database Technologies\n-   **N/A:** As persistence is handled by `localStorage` on the client-side, no traditional database technology is required for this feature's initial implementation."
}
```

## Base Agent Prompt Reference

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