# io8 System Architect Agent - Customized for This Project

## Project-Specific Instructions

```json
{
  "architecture": "\n# Architecture Document\nGenerated: 2025-10-14T06:37:01Z\n\n## Notes Application Architecture\n\n### System Overview\nThe Notes Application is designed as a self-contained feature within the existing Angular Clarity Boilerplate. It provides basic Create, Read, Update, and Delete (CRUD) functionality for text-based notes. A critical design constraint, as highlighted in `analysis_document.md` and `requirements_document.md`, is the exclusive use of browser `localStorage` for all data persistence, eliminating the need for a traditional backend service for this initial scope. The application emphasizes a simple, intuitive user experience for managing personal notes locally.\n\n### Architecture Pattern\nThe Notes app will adhere to a **Component-Based Architecture** leveraging Angular's modularity, services, and reactive programming principles. It will follow a layered approach:\n1.  **Presentation Layer (Components):** Responsible for UI rendering and user interaction, built with Clarity Design System components.\n2.  **Service Layer (Data Access):** A dedicated service (`LocalStorageService`) to abstract all data persistence logic and interactions with `localStorage`.\n3.  **Data Layer (Models):** TypeScript interfaces defining the `Note` entity structure.\n\nThis pattern ensures a clean separation of concerns, making the application maintainable and allowing for easier migration to a server-side backend in the future by replacing only the `LocalStorageService` with an `ApiService`.\n\n### Component Design\nTo integrate the Notes app into the existing Angular Clarity Boilerplate (referencing `analysis_document.md`'s scalable architecture), a new feature module will be introduced:\n\n*   **`NotesModule`**: A lazy-loaded Angular feature module encapsulating all Notes application components and services. This aligns with `requirements_document.md` (FR-002: Modular Architecture) and `analysis_document.md`'s guidance for new feature modules.\n    *   **`NotesPageComponent`**: (Container Component) Serves as the main entry point for the Notes application. It will orchestrate the `NoteFormComponent` and `NoteListComponent`, managing the overall state and data flow between them. This component will be responsible for fetching all notes on initialization and handling updates from child components.\n    *   **`NoteFormComponent`**: (Presentational/Smart Component) A reusable component responsible for creating new notes and editing existing ones. It will include input fields for `title` and `content` (as per `requirements_document.md` FR-001, IR-002) and a 'Save' button. It will emit events for saving/updating notes to its parent (`NotesPageComponent`). Clarity form components will be used for consistency.\n    *   **`NoteListComponent`**: (Presentational Component) Displays the collection of notes retrieved from local storage (as per `requirements_document.md` FR-002, IR-003). It receives a list of `Note` objects as input and renders them using `NoteItemComponent`.\n    *   **`NoteItemComponent`**: (Presentational Component) Represents a single note within the `NoteListComponent`. It displays the note's title and content snippet, along with 'Edit' and 'Delete' actions (as per `requirements_document.md` FR-003, FR-004, IR-003). It emits events for edit and delete actions to its parent (`NoteListComponent` or `NotesPageComponent`).\n    *   **`LocalStorageService`**: (Service) A singleton Angular service responsible for all interactions with the browser's `localStorage` API. This service will encapsulate the logic for storing, retrieving, updating, and deleting `Note` objects as an array of JSON strings under a defined key (e.g., `notes_app_notes`). It will expose methods such as `getNotes()`, `saveNote()`, `updateNote()`, and `deleteNote()` (referencing `requirements_document.md` FR-005, Data Requirements). It may use RxJS `BehaviorSubject` or `Subject` to provide a reactive stream of notes to components, ensuring real-time UI updates.\n\n### Data Architecture\n\n*   **Entity Model**: The core data entity is `Note`, defined as a TypeScript interface/class (as specified in `requirements_document.md` - Data Requirements).\n    ```typescript\n    interface Note {\n      id: string; // Unique identifier (UUID generated)\n      title: string; // Required, user-provided\n      content: string; // Optional, user-provided\n      dateCreated: string; // ISO 8601 timestamp, auto-generated on creation\n    }\n    ```\n*   **Storage Mechanism**: Browser `localStorage` API (as per `analysis_document.md` and `requirements_document.md` FR-005).\n    *   All notes will be stored as an array of `Note` objects, serialized into a single JSON string.\n    *   This JSON string will be stored under a specific key, e.g., `\"notes_app_notes\"`, in `localStorage`.\n*   **Data Flow**: \n    1.  On application load, `NotesPageComponent` requests notes from `LocalStorageService`.\n    2.  `LocalStorageService` retrieves and deserializes the JSON string from `localStorage`, then provides the array of `Note` objects.\n    3.  `NotesPageComponent` passes notes to `NoteListComponent` for display.\n    4.  `NoteFormComponent` submits new/updated note data to `NotesPageComponent`.\n    5.  `NotesPageComponent` calls `LocalStorageService` to persist changes.\n    6.  `LocalStorageService` updates `localStorage` and optionally notifies subscribers (e.g., `NotesPageComponent`) of the change, triggering a UI refresh (NFR-001, FR-001, FR-003, FR-004).\n\n### API Design\nGiven the constraint of using `localStorage`, there is no external API. The `LocalStorageService` acts as the data access layer, providing methods that mimic a typical API interaction:\n*   `getNotes(): Observable<Note[]>`: Retrieves all notes from `localStorage`.\n*   `getNoteById(id: string): Observable<Note | undefined>`: Retrieves a single note by its ID.\n*   `createNote(note: Partial<Note>): Observable<Note>`: Adds a new note to `localStorage`, generates `id` and `dateCreated`.\n*   `updateNote(note: Note): Observable<Note>`: Updates an existing note in `localStorage` based on its `id`.\n*   `deleteNote(id: string): Observable<void>`: Removes a note from `localStorage` by its `id`.\n\n### Security Architecture\nFor a client-side, `localStorage`-based application, security considerations are minimal:\n*   **Data Confidentiality**: Data is stored locally in the browser, accessible to other scripts on the *same origin*. It is not protected against local machine access or browser inspection. This aligns with the single-user, local persistence model.\n*   **Input Validation**: Implement basic validation for note `title` (cannot be empty, as per Business Rule BR-001 in `analysis_document.md`) to prevent invalid data from being stored.\n*   **XSS Protection**: Angular's built-in sanitization will help prevent basic Cross-Site Scripting (XSS) if note content is rendered using `[innerHTML]`, but for a local app, this is less of a concern than for a multi-user application.\n\n### Scalability Considerations\n*   **Data Volume**: The primary limitation is `localStorage` capacity (typically 5-10MB). The application is not designed for storing thousands of large notes. Performance (NFR-001) may degrade if the number of notes or their content size becomes excessive.\n*   **User Concurrency**: The application is strictly single-user, single-browser instance. It does not support synchronization across multiple devices or browsers.\n*   **Future Backend Integration**: The separation of the `LocalStorageService` allows for a clear upgrade path. If a backend database and API are required in the future, the `LocalStorageService` can be replaced by an `ApiService` that communicates with the server, with minimal changes to the UI components. This aligns with the `analysis_document.md`'s emphasis on extensibility.\n*   **Modular Growth**: The `NotesModule` can easily grow with additional features (e.g., search, tags) without impacting the core boilerplate structure, as per `requirements_document.md` FR-002.\n",
  "tech_stack": "\n# Technology Stack Document\nGenerated: 2025-10-14T06:37:01Z\n\n## Notes Application Technology Stack\nThis section details the specific technologies and tools to be used for implementing the Notes Application, building upon the existing Angular Clarity Boilerplate.\n\n### Frontend Technologies\n-   **Framework:** Angular (existing, version as per boilerplate).\n    *   The Notes application will be developed using standard Angular features: Components, Services, Modules, and Routing (for `NotesModule`).\n-   **Language:** TypeScript (existing).\n    *   Strongly typed code for defining `Note` models and ensuring code quality.\n-   **Styling:** VMware Clarity Design System (existing).\n    *   Clarity UI components (e.g., `clr-input`, `clr-textarea`, `clr-button`, `clr-datagrid` or `clr-stack-view` for note list) will be utilized for all user interface elements to ensure consistency with the base project and adherence to `requirements_document.md` (FR-003, IR-001, IR-002, IR-003).\n-   **State Management:** Component-local state management combined with reactive data streams from `LocalStorageService` using RxJS.\n    *   `BehaviorSubject` or `Subject` within `LocalStorageService` will notify components of data changes, enabling real-time UI updates without complex global state management libraries for this simple scope.\n\n### Backend Technologies\n-   **Backend:** N/A.\n    *   The application is strictly frontend-only, as per the `analysis_document.md` and `io8codermaster_breakdown.md` constraint of using local storage for data persistence.\n-   **API:** N/A.\n    *   No external API endpoints will be consumed or exposed by the Notes application.\n\n### Database Technologies\n-   **Primary Database:** Browser `localStorage` API.\n    *   All note data will be stored directly in the browser's `localStorage` as a JSON string, as specified in `requirements_document.md` (FR-005, Data Requirements).\n-   **Caching:** N/A.\n    *   `localStorage` itself serves as the persistence and caching layer for this application.\n\n### Infrastructure\n-   **Deployment:** Leverages the existing Angular Clarity Boilerplate's deployment mechanisms (e.g., Docker, static file hosting on AWS S3/CloudFront, Azure Static Web Apps, GCP Cloud Storage) for serving the static frontend application.\n-   **Hosting:** Inherited from the base boilerplate (e.g., AWS, Azure, GCP).\n\n### Development Tools\n-   **Version Control:** Git (existing).\n-   **Testing:** Karma/Jasmine for unit tests, Protractor for end-to-end tests (existing Angular setup).\n    *   Unit tests for `LocalStorageService` and `NoteFormComponent` logic.\n-   **CI/CD:** Inherited from the base boilerplate's pipeline for Angular applications.\n-   **Code Generation:** Angular CLI for generating new modules, components, and services.\n-   **Unique ID Generation:** A JavaScript UUID library (e.g., `uuid` if installed, or a simple custom ID generator based on timestamps and random numbers for small-scale uniqueness) will be used for generating unique `id`s for notes.\n"
}
```

## 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.
