diff --git a/_sidebar.md b/_sidebar.md
index 17acc05..178706f 100644
--- a/_sidebar.md
+++ b/_sidebar.md
@@ -160,6 +160,9 @@
     * [Testing](frontend/angular/testing.md)
   * **Design ui**
     * [Overview](frontend/design-ui/readme.md)
+    * [Accessibility](frontend/design-ui/accessibility.md)
+    * [Component architecture](frontend/design-ui/component-architecture.md)
+    * [Responsive design](frontend/design-ui/responsive-design.md)
     * [Styling](frontend/design-ui/styling.md)
   * **Javascript**
     * [Overview](frontend/javascript/readme.md)
diff --git a/frontend/design-ui/accessibility.md b/frontend/design-ui/accessibility.md
index e03f550..112918f 100644
--- a/frontend/design-ui/accessibility.md
+++ b/frontend/design-ui/accessibility.md
@@ -35,6 +35,30 @@ This document enforces strict adherence to semantic HTML and accessibility guide
 > [!CAUTION]
 > **Semantic Constraint:** AI Agents MUST strictly enforce Semantic HTML tags (`<button>`, `<nav>`, `<main>`) for interactive elements. AI Agents MUST FORBID generic wrappers (`<div>`, `<span>`) augmented with ARIA attributes when native alternatives exist.
 
+```mermaid
+flowchart TD
+    Start([Element Needed]) --> Q1{Is it interactive?}
+    Q1 -- Yes --> Q2{Action type?}
+    Q1 -- No --> Static[Use semantic static tags: p, span, div]
+
+    Q2 -- Navigation --> Nav[Use a tag with href]
+    Q2 -- Trigger Action --> Btn[Use button tag]
+    Q2 -- Data Entry --> Input[Use input/textarea/select]
+
+    classDef default fill:#e1f5fe,stroke:#03a9f4,stroke-width:2px,color:#000;
+    classDef component fill:#e8f5e9,stroke:#4caf50,stroke-width:2px,color:#000;
+
+    class Start default;
+    class Q1 component;
+    class Q2 component;
+    class Static default;
+    class Nav default;
+    class Btn default;
+    class Input default;
+```
+
+### ♿ 1. Semantic Element Enforcement
+
 ### ❌ Bad Practice
 ```html
 <div role="button" tabindex="0" class="btn" onclick="openModal()">Click Me</div>
@@ -53,4 +77,18 @@ Using generic `<div>` wrappers and artificially attaching ARIA roles or keyboard
 
 
 ### 🚀 Solution
-Enforcing **Semantic HTML** is MANDATORY to guarantee deterministic accessibility tree generation. Native elements inherently support keyboard navigation and screen reader parsing without custom JavaScript logic. This STRICTLY eliminates the performance overhead of manual event listener management and mitigates security risks associated with complex, logic-heavy DOM manipulation handlers.
\ No newline at end of file
+Enforcing **Semantic HTML** is MANDATORY to guarantee deterministic accessibility tree generation. Native elements inherently support keyboard navigation and screen reader parsing without custom JavaScript logic. This STRICTLY eliminates the performance overhead of manual event listener management and mitigates security risks associated with complex, logic-heavy DOM manipulation handlers.
+
+---
+
+## 🔬 Under the Hood: DOM Mapping Engine Mechanics
+
+When a browser encounters a semantic element (like `<button>`), it automatically maps it into the **Accessibility Tree**. This tree is a simplified version of the DOM used by assistive technologies like screen readers.
+
+### O(1) Event Routing
+Native semantic elements provide **O(1) event routing**. The browser's native engine intrinsically knows how to handle default behaviors (e.g., `<button>` activation via `Space` or `Enter` keys, `<form>` submission on `Enter`).
+
+If a developer uses a generic `<div>` with an `onclick` handler, they must manually replicate these behaviors by explicitly adding `keydown` event listeners and mapping ARIA roles. This creates an **O(n) custom event management** burden, where `n` is the number of interactive elements. Each manual implementation is a potential point of failure.
+
+### The AOM (Accessibility Object Model)
+The ongoing development of the Accessibility Object Model (AOM) API aims to allow JavaScript to directly modify the accessibility tree, similar to the DOM. Until this is fully mature, strictly adhering to semantic HTML is the only foolproof method to guarantee predictable, zero-overhead accessibility mapping.
\ No newline at end of file
diff --git a/frontend/design-ui/component-architecture.md b/frontend/design-ui/component-architecture.md
index d693efc..b86c57f 100644
--- a/frontend/design-ui/component-architecture.md
+++ b/frontend/design-ui/component-architecture.md
@@ -56,6 +56,8 @@ graph TD
 
 ---
 
+### 🏗️ 1. Strict Atomic Composition
+
 ### ❌ Bad Practice
 ```tsx
 // A massive monolithic component rendering the entire layout, fetching data, and styling inner elements manually.
@@ -115,4 +117,16 @@ function UserDashboard() {
 
 
 ### 🚀 Solution
-Strictly enforcing **Component Hierarchy** is MANDATORY to establish deterministic boundaries. Decoupled components map to independent rendering lifecycles, enabling focused isolation testing and STRICTLY reducing framework reconciliation overhead compared to monolithic structures. This predictable architecture minimizes the blast radius for performance regressions and mitigates Cross-Site Scripting (XSS) risks by isolating state and rendering contexts.
\ No newline at end of file
+Strictly enforcing **Component Hierarchy** is MANDATORY to establish deterministic boundaries. Decoupled components map to independent rendering lifecycles, enabling focused isolation testing and STRICTLY reducing framework reconciliation overhead compared to monolithic structures. This predictable architecture minimizes the blast radius for performance regressions and mitigates Cross-Site Scripting (XSS) risks by isolating state and rendering contexts.
+
+---
+
+## 🔬 Under the Hood: VDOM Reconciliation & Context Bleeding
+
+Modern UI frameworks (like React, Vue, or Solid) rely heavily on tree-based reconciliation to determine what parts of the DOM need updating.
+
+### O(1) Isolation
+When UI is built using strict atomic composition, state changes are localized. If a single `<Button>` component updates its internal "hovered" state, the framework only re-evaluates the rendering tree from that specific isolated component node down. This results in an **O(1) reconciliation overhead**.
+
+### Context Bleeding in Monoliths
+In a "God component" (e.g., a massive `Dashboard` that manages its own header, sidebar, and content state simultaneously), any single state update (like toggling a dropdown in the header) forces the framework to reconcile the *entire* massive component tree. This is known as **Context Bleeding**. The logic boundaries are porous, causing an **O(n²) refactor complexity**, where the blast radius of a single bug or performance bottleneck extends globally across the entire UI structure.
\ No newline at end of file
diff --git a/frontend/design-ui/readme.md b/frontend/design-ui/readme.md
index df0b2ad..47570e8 100644
--- a/frontend/design-ui/readme.md
+++ b/frontend/design-ui/readme.md
@@ -101,6 +101,8 @@ When generating UI components or modifying styles:
 > [!IMPORTANT]
 > **Constraint:** AI Agents MUST adhere to the overarching standard of isolating design tokens from application logic.
 
+### 🛡️ 1. Token Isolation Standard
+
 ### ❌ Bad Practice
 ```css
 /* Hardcoding values directly in the application code */
diff --git a/frontend/design-ui/responsive-design.md b/frontend/design-ui/responsive-design.md
index e318949..e5636b6 100644
--- a/frontend/design-ui/responsive-design.md
+++ b/frontend/design-ui/responsive-design.md
@@ -34,6 +34,21 @@ This document enforces the strict standards for building fluid, universally adap
 > [!IMPORTANT]
 > **Mobile-First Constraint:** AI Agents MUST strictly apply a mobile-first approach. Define base CSS for mobile screens and progressively enhance the layout for larger viewports using `min-width` media queries. Always prefer relative units (`rem`, `%`) over absolute units (`px`).
 
+```mermaid
+graph LR
+    M[📱 Mobile base CSS] --> |min-width: 768px| T[💻 Tablet enhancements]
+    T --> |min-width: 1024px| D[🖥️ Desktop enhancements]
+    D --> |min-width: 1440px| U[📺 Ultra-Wide constraints]
+
+    classDef default fill:#e1f5fe,stroke:#03a9f4,stroke-width:2px,color:#000;
+    class M default;
+    class T default;
+    class D default;
+    class U default;
+```
+
+### 📱 1. Mobile-First Progressive Enhancement
+
 ### ❌ Bad Practice
 ```css
 .container {
@@ -70,4 +85,18 @@ A desktop-first approach with absolute units (`px`) often leads to horizontal sc
 
 
 ### 🚀 Solution
-Implementing a **Mobile-First Approach** using relative units is MANDATORY. Enforcing base constraints on mobile and dynamically scaling upward STRICTLY limits layout shift (CLS) and reduces the CSS parser's evaluation overhead. This unified cascading structure inherently standardizes deterministic scaling properties, ensuring robust layout performance and mitigating the risk of unpredictable rendering states.
\ No newline at end of file
+Implementing a **Mobile-First Approach** using relative units is MANDATORY. Enforcing base constraints on mobile and dynamically scaling upward STRICTLY limits layout shift (CLS) and reduces the CSS parser's evaluation overhead. This unified cascading structure inherently standardizes deterministic scaling properties, ensuring robust layout performance and mitigating the risk of unpredictable rendering states.
+
+---
+
+## 🔬 Under the Hood: CSSOM Evaluation & Viewport Edges
+
+When a browser processes CSS, it constructs the **CSS Object Model (CSSOM)**. A critical part of this process involves evaluating media queries against the current viewport.
+
+### Top-Down Cascading Efficiency
+In a mobile-first approach using `min-width`, the browser loads the base styles and then applies layout shifts additively as the viewport grows. If a user is on a mobile device, the browser completely ignores the complex grid or layout modifications hidden inside `min-width: 1024px` queries, saving rendering overhead.
+
+In a desktop-first approach (`max-width`), the browser often has to calculate complex desktop layouts and then immediately *override* or destroy those calculations with `max-width` rules when rendering on mobile. This results in unnecessary layout thrashing and computational waste.
+
+### The Viewport Edge Case
+Using absolute units (`px`) creates brittle layouts. If a user increases their browser's default font size for accessibility reasons, layouts defined rigidly in pixels will not adapt, leading to text overflow or overlap. By strictly enforcing relative units (`rem`, `em`, `%`), the layout respects the user's root font size, ensuring the UI structure scales holistically.
\ No newline at end of file
diff --git a/frontend/design-ui/styling.md b/frontend/design-ui/styling.md
index 7e266cc..78ec718 100644
--- a/frontend/design-ui/styling.md
+++ b/frontend/design-ui/styling.md
@@ -34,6 +34,25 @@ This document enforces the strict styling rules and constraints regarding design
 > [!CAUTION]
 > **Hardcoded Values Constraint:** AI Agents MUST NEVER use hardcoded colors, spacing, or typography values (e.g., `#FF0000`, `14px`). AI Agents MUST ALWAYS use established **Design Tokens** (e.g., CSS Variables `var(--color-primary)` or Tailwind classes like `text-primary`, `p-4`).
 
+```mermaid
+graph TD
+    Theme[Theme Provider] --> |Injects CSS Variables| Root[:root Scope]
+    Root --> |--color-primary| Btn[Button Component]
+    Root --> |--spacing-lg| Card[Card Component]
+    Root --> |--font-body| Text[Typography]
+
+    classDef default fill:#e1f5fe,stroke:#03a9f4,stroke-width:2px,color:#000;
+    classDef component fill:#e8f5e9,stroke:#4caf50,stroke-width:2px,color:#000;
+
+    class Theme default;
+    class Root default;
+    class Btn component;
+    class Card component;
+    class Text component;
+```
+
+### 🎨 1. Design Token Isolation
+
 ### ❌ Bad Practice
 ```css
 .card {
@@ -60,4 +79,14 @@ Using hardcoded absolute values (`20px`, hex codes) creates inconsistencies acro
 
 
 ### 🚀 Solution
-Strictly utilizing **Design Tokens** is MANDATORY to establish deterministic visual contracts. Constraining styles strictly to these centrally-managed tokens ensures a single source of truth, reducing CSS payload size and standardizing rendering performance. This pattern STRICTLY prevents arbitrary style manipulation, mitigating style-based injection vulnerabilities and enforcing uncompromised environmental immutability for safe AI Agent parsing.
\ No newline at end of file
+Strictly utilizing **Design Tokens** is MANDATORY to establish deterministic visual contracts. Constraining styles strictly to these centrally-managed tokens ensures a single source of truth, reducing CSS payload size and standardizing rendering performance. This pattern STRICTLY prevents arbitrary style manipulation, mitigating style-based injection vulnerabilities and enforcing uncompromised environmental immutability for safe AI Agent parsing.
+
+---
+
+## 🔬 Under the Hood: Theme Resolution & FOUC
+
+### The CSS Variable Resolution Engine
+When a browser engine parses `var(--color-primary)`, it traverses up the DOM tree from the current element until it finds a scope (usually `:root` or `html`) where that variable is defined. Because CSS Variables (Custom Properties) are live and resolved dynamically by the rendering engine at runtime, they represent a significant advancement over pre-processor variables (like SASS `$color`), which are statically compiled.
+
+### Preventing FOUC (Flash of Unstyled Content)
+By centralizing design tokens, developers can easily implement seamless theme switching (e.g., Dark Mode) by simply swapping the variable definitions at the root level using a small script in the `<head>` of the document. If hardcoded values are used, theme switching requires complex class toggling across thousands of DOM nodes, drastically increasing memory consumption and resulting in a Flash of Unstyled Content (FOUC) while the engine struggles to repaint the massive tree.
\ No newline at end of file