From beb96dd11cb3c94f2a4de3201cba5031b58c617b Mon Sep 17 00:00:00 2001
From: "google-labs-jules[bot]"
 <161369871+google-labs-jules[bot]@users.noreply.github.com>
Date: Wed, 13 May 2026 18:36:26 +0000
Subject: [PATCH] docs(frontend): autonomous architectural standardization for
 modularized components

Co-authored-by: beginwebdev2002 <102213457+beginwebdev2002@users.noreply.github.com>
---
 frontend/angular/basics.md          | 309 ++++++++++++++++++++++++++++
 frontend/angular/readme.md          | 296 +-------------------------
 frontend/design-ui/basics.md        |  29 +++
 frontend/design-ui/readme.md        |  11 +-
 frontend/javascript/basic-syntax.md |  16 ++
 frontend/javascript/readme.md       |  16 --
 frontend/qwik/basics.md             |  53 +++++
 frontend/qwik/readme.md             |  20 +-
 frontend/react/basics.md            |  71 +++++++
 frontend/react/readme.md            |  60 +-----
 frontend/solidjs/basics.md          |  29 +++
 frontend/solidjs/readme.md          |  17 +-
 frontend/typescript/fundamentals.md | 156 ++++++++++++++
 frontend/typescript/readme.md       | 147 +------------
 14 files changed, 678 insertions(+), 552 deletions(-)
 create mode 100644 frontend/angular/basics.md
 create mode 100644 frontend/design-ui/basics.md
 create mode 100644 frontend/qwik/basics.md
 create mode 100644 frontend/react/basics.md
 create mode 100644 frontend/solidjs/basics.md
 create mode 100644 frontend/typescript/fundamentals.md

diff --git a/frontend/angular/basics.md b/frontend/angular/basics.md
new file mode 100644
index 0000000..ce4a380
--- /dev/null
+++ b/frontend/angular/basics.md
@@ -0,0 +1,309 @@
+---
+technology: Angular
+domain: frontend
+level: Senior/Architect
+version: 20+
+tags: [best-practices, clean-code, architecture-patterns, vibe-coding, cursor-rules, typescript, software-architecture, system-design, solid-principles, production-ready, programming-standards, react-best-practices, node-js, design-patterns, scalable-code, windsurf-rules, ai-coding, fsd, ddd, enterprise-patterns]
+ai_role: Senior Angular Performance Expert
+last_updated: 2026-03-22
+---
+
+# 🚀 Angular Basics & Popular Patterns
+
+[⬆️ Back to Top](./readme.md)
+
+### 🚨 1. Using `@Input()` Decorator
+> [!NOTE]
+> **Context:** Component Inputs
+### ❌ Bad Practice
+```typescript
+@Input() title: string;
+```
+### ⚠️ Problem
+Using the `@Input()` decorator breaks the functional reactivity of Zoneless applications.
+### ✅ Best Practice
+```typescript
+title = input<string>();
+```
+### 🚀 Solution
+Use Signal Inputs (`input()`). This allows Angular to precisely know *which* specific component requires an update, paving the way for Zoneless applications.
+---
+
+### 🚨 2. Using `@Output()` Decorator
+> [!NOTE]
+> **Context:** Component Outputs
+### ❌ Bad Practice
+```typescript
+@Output() save = new EventEmitter<void>();
+```
+### ⚠️ Problem
+The classic `EventEmitter` adds an unnecessary layer of abstraction over RxJS Subject and does not integrate with the Angular functional API.
+### ✅ Best Practice
+```typescript
+save = output<void>();
+```
+### 🚀 Solution
+Use the `output()` function. It provides strict typing, better performance, and a unified API with Signal Inputs.
+---
+
+### 🚨 3. Two-Way Binding with `@Input()` and `@Output()`
+> [!NOTE]
+> **Context:** Model Synchronization
+### ❌ Bad Practice
+```typescript
+@Input() value: string;
+@Output() valueChange = new EventEmitter<string>();
+```
+### ⚠️ Problem
+Boilerplate code that is easy to break if you make a mistake in naming the `Change` event.
+### ✅ Best Practice
+```typescript
+value = model<string>();
+```
+### 🚀 Solution
+> [!IMPORTANT]
+> Use `model()`. This creates a Signal that MUST be both read and written to, automatically synchronizing its state with the parent.
+---
+
+### 🚨 4. Structural Directives (`*ngIf`, `*ngFor`)
+> [!NOTE]
+> **Context:** Template Control Flow
+### ❌ Bad Practice
+```html
+<div *ngIf="isLoaded; else loading">
+  <li *ngFor="let item of items">{{ item }}</li>
+</div>
+```
+### ⚠️ Problem
+Directives require importing `CommonModule` or `NgIf/NgFor`, increasing bundle size. Micro-template syntax is complex for static analysis and type-checking.
+### ✅ Best Practice
+```html
+@if (isLoaded()) {
+  @for (item of items(); track item.id) {
+    <li>{{ item.name }}</li>
+  }
+} @else {
+  <app-loader />
+}
+```
+### 🚀 Solution
+Use the built-in Control Flow (`@if`, `@for`). It is built into the compiler, requires no imports, supports improved type-narrowing, and runs faster.
+---
+
+### 🚨 5. Subscribing in Components (Logic in `ngOnInit`)
+> [!NOTE]
+> **Context:** Data Fetching
+### ❌ Bad Practice
+```typescript
+data: unknown;
+ngOnInit() {
+  this.service.getData().subscribe(res => this.data = res);
+}
+```
+### ⚠️ Problem
+Imperative subscriptions lead to memory leaks (if you forget to `unsubscribe`), "Callback Hell", and state desynchronization. Requires manual subscription management.
+### ✅ Best Practice
+```typescript
+data = toSignal(this.service.getData());
+```
+### 🚀 Solution
+Use `toSignal()` to convert an Observable into a Signal. This automatically manages the subscription and integrates the data stream into the reactivity system.
+---
+
+### 🚨 6. `BehaviorSubject` for Local State
+> [!NOTE]
+> **Context:** Component State Management
+### ❌ Bad Practice
+```typescript
+private count$ = new BehaviorSubject(0);
+getCount() { return this.count$.value; }
+```
+### ⚠️ Problem
+RxJS is overkill for simple synchronous state. `BehaviorSubject` requires `.value` for access and `.next()` for writes, increasing cognitive load.
+### ✅ Best Practice
+```typescript
+count = signal(0);
+// Access: count()
+// Update: count.set(1)
+```
+### 🚀 Solution
+Use `signal()` for local state. It is a primitive designed specifically for synchronizing UI and data.
+---
+
+### 🚨 7. Derived State with `ngOnChanges`
+> [!NOTE]
+> **Context:** Reactivity
+### ❌ Bad Practice
+```typescript
+ngOnChanges(changes: SimpleChanges) {
+  if (changes['firstName']) {
+    this.fullName = `${this.firstName} ${this.lastName}`;
+  }
+}
+```
+### ⚠️ Problem
+`ngOnChanges` is triggered only when Inputs change, has complex typing, and runs before View initialization.
+### ✅ Best Practice
+```typescript
+fullName = computed(() => `${this.firstName()} ${this.lastName()}`);
+```
+### 🚀 Solution
+Use `computed()`. The signal is recalculated *only* when its dependencies change, and the result is memoized (cached).
+---
+
+### 🚨 8. Constructor Dependency Injection
+> [!NOTE]
+> **Context:** DI Pattern
+### ❌ Bad Practice
+```typescript
+constructor(private http: HttpClient, private store: Store) {}
+```
+### ⚠️ Problem
+Constructors become cluttered with many dependencies. When inheriting classes, dependencies must be passed through `super()`.
+### ✅ Best Practice
+```typescript
+private http = inject(HttpClient);
+private store = inject(Store);
+```
+### 🚀 Solution
+Use the `inject()` function. It operates in the initialization context (fields or constructor), is type-safe, and does not require `super()` during inheritance.
+---
+
+### 🚨 9. Modules (`NgModule`)
+> [!NOTE]
+> **Context:** App Architecture
+### ❌ Bad Practice
+```typescript
+@NgModule({
+  declarations: [AppComponent],
+  imports: [BrowserModule]
+})
+export class AppModule {}
+```
+### ⚠️ Problem
+Modules create an unnecessary level of indirection. Components become dependent on the module context, complicating Lazy Loading and testing.
+### ✅ Best Practice
+```typescript
+@Component({
+  standalone: true,
+  imports: [CommonModule]
+})
+```
+### 🚀 Solution
+Use Standalone Components. This is the Angular v14+ standard that makes components self-sufficient and tree-shakable.
+---
+
+### 🚨 10. String-based Route Loading
+> [!NOTE]
+> **Context:** Lazy Loading Routing
+### ❌ Bad Practice
+```typescript
+loadChildren: () => import('./module').then(m => m.UserModule)
+```
+### ⚠️ Problem
+Loading modules pulls in transitive dependencies that might not be needed.
+### ✅ Best Practice
+```typescript
+loadComponent: () => import('./user.component').then(c => c.UserComponent)
+```
+### 🚀 Solution
+Use `loadComponent` for routing to Standalone components. This ensures minimal chunk size.
+---
+
+### 🚨 11. Heavy Logic in Templates
+> [!NOTE]
+> **Context:** Template Performance
+### ❌ Bad Practice
+```html
+<div>{{ calculateTotal(items) }}</div>
+```
+### ⚠️ Problem
+The `calculateTotal` function is called during *every* Change Detection (CD) cycle, even if `items` have not changed. This kills UI performance.
+### ✅ Best Practice
+```typescript
+total = computed(() => this.calculateTotal(this.items()));
+```
+```html
+<div>{{ total() }}</div>
+```
+### 🚀 Solution
+Extract logic into `computed()` signals or Pure Pipes. They are only executed when input data changes.
+---
+
+### 🚨 12. Manual Subscription Management (`takeUntil`)
+> [!NOTE]
+> **Context:** RxJS Memory Leaks
+### ❌ Bad Practice
+```typescript
+destroy$ = new Subject<void>();
+ngOnDestroy() { this.destroy$.next(); }
+stream$.pipe(takeUntil(this.destroy$)).subscribe();
+```
+### ⚠️ Problem
+It's easy to forget `takeUntil` or `unsubscribe`. Requires a lot of boilerplate code in every component.
+### ✅ Best Practice
+```typescript
+stream$.pipe(takeUntilDestroyed()).subscribe();
+```
+### 🚀 Solution
+Use the `takeUntilDestroyed()` operator. It automatically unsubscribes upon context destruction (component, directive, service).
+---
+
+### 🚨 13. Deeply Nested Components Passing Data
+> [!NOTE]
+> **Context:** Prop Drilling
+### ❌ Bad Practice
+```html
+<!-- Parent -->
+<app-child [theme]="theme"></app-child>
+<!-- Child -->
+<app-grandchild [theme]="theme"></app-grandchild>
+```
+### ⚠️ Problem
+"Prop drilling" heavily couples intermediate components to data they don't need, just for the sake of passing it deeper.
+### ✅ Best Practice
+```typescript
+// Service
+theme = signal('dark');
+// Grandchild
+theme = inject(ThemeService).theme;
+```
+### 🚀 Solution
+Use Signal Stores or services for state sharing, or the new `input()` API with context inheritance (in the future).
+---
+
+### 🚨 14. Accessing DOM directly (`ElementRef.nativeElement`)
+> [!NOTE]
+> **Context:** Security & Abstraction
+### ❌ Bad Practice
+```typescript
+el.nativeElement.style.backgroundColor = 'red';
+```
+### ⚠️ Problem
+Direct DOM access breaks abstraction (doesn't work in SSR/Web Workers) and opens up XSS vulnerabilities. It bypasses Angular Sanitization mechanisms.
+### ✅ Best Practice
+```typescript
+// Use Renderer2 or bindings
+<div [style.background-color]="color()"></div>
+```
+### 🚀 Solution
+Use style/class bindings or `Renderer2`. For direct manipulations, consider directives.
+---
+
+### 🚨 15. Zone.js overhead
+> [!NOTE]
+> **Context:** Change Detection
+### ❌ Bad Practice
+The application relies on Zone.js for any asynchronous event (setTimeout, Promise, XHR).
+### ⚠️ Problem
+Zone.js patches all browser APIs, adding overhead and increasing bundle size. CD triggers more often than necessary.
+### ✅ Best Practice
+```typescript
+bootstrapApplication(App, {
+  providers: [provideExperimentalZonelessChangeDetection()]
+});
+```
+### 🚀 Solution
+Migrate to Zoneless mode. Use Signals to notify Angular when a re-render is needed.
+---
+[⬆️ Back to Top](#)
diff --git a/frontend/angular/readme.md b/frontend/angular/readme.md
index 77107e5..01d2284 100644
--- a/frontend/angular/readme.md
+++ b/frontend/angular/readme.md
@@ -24,304 +24,10 @@ last_updated: 2026-03-22
 
 Please refer to the specialized guides for detailed best practices:
 
+- [🚀 Basics & Popular](./basics.md)
 - [🧩 Components & Signals](./components-signals.md)
 - [⚡ Reactivity & RxJS](./reactivity.md)
 
-### 🚨 1. Using `@Input()` Decorator
-> [!NOTE]
-> **Context:** Component Inputs
-### ❌ Bad Practice
-```typescript
-@Input() title: string;
-```
-### ⚠️ Problem
-Using the `@Input()` decorator breaks the functional reactivity of Zoneless applications.
-### ✅ Best Practice
-```typescript
-title = input<string>();
-```
-### 🚀 Solution
-Use Signal Inputs (`input()`). This allows Angular to precisely know *which* specific component requires an update, paving the way for Zoneless applications.
----
-
-### 🚨 2. Using `@Output()` Decorator
-> [!NOTE]
-> **Context:** Component Outputs
-### ❌ Bad Practice
-```typescript
-@Output() save = new EventEmitter<void>();
-```
-### ⚠️ Problem
-The classic `EventEmitter` adds an unnecessary layer of abstraction over RxJS Subject and does not integrate with the Angular functional API.
-### ✅ Best Practice
-```typescript
-save = output<void>();
-```
-### 🚀 Solution
-Use the `output()` function. It provides strict typing, better performance, and a unified API with Signal Inputs.
----
-
-### 🚨 3. Two-Way Binding with `@Input()` and `@Output()`
-> [!NOTE]
-> **Context:** Model Synchronization
-### ❌ Bad Practice
-```typescript
-@Input() value: string;
-@Output() valueChange = new EventEmitter<string>();
-```
-### ⚠️ Problem
-Boilerplate code that is easy to break if you make a mistake in naming the `Change` event.
-### ✅ Best Practice
-```typescript
-value = model<string>();
-```
-### 🚀 Solution
-> [!IMPORTANT]
-> Use `model()`. This creates a Signal that MUST be both read and written to, automatically synchronizing its state with the parent.
----
-
-### 🚨 4. Structural Directives (`*ngIf`, `*ngFor`)
-> [!NOTE]
-> **Context:** Template Control Flow
-### ❌ Bad Practice
-```html
-<div *ngIf="isLoaded; else loading">
-  <li *ngFor="let item of items">{{ item }}</li>
-</div>
-```
-### ⚠️ Problem
-Directives require importing `CommonModule` or `NgIf/NgFor`, increasing bundle size. Micro-template syntax is complex for static analysis and type-checking.
-### ✅ Best Practice
-```html
-@if (isLoaded()) {
-  @for (item of items(); track item.id) {
-    <li>{{ item.name }}</li>
-  }
-} @else {
-  <app-loader />
-}
-```
-### 🚀 Solution
-Use the built-in Control Flow (`@if`, `@for`). It is built into the compiler, requires no imports, supports improved type-narrowing, and runs faster.
----
-
-### 🚨 5. Subscribing in Components (Logic in `ngOnInit`)
-> [!NOTE]
-> **Context:** Data Fetching
-### ❌ Bad Practice
-```typescript
-data: unknown;
-ngOnInit() {
-  this.service.getData().subscribe(res => this.data = res);
-}
-```
-### ⚠️ Problem
-Imperative subscriptions lead to memory leaks (if you forget to `unsubscribe`), "Callback Hell", and state desynchronization. Requires manual subscription management.
-### ✅ Best Practice
-```typescript
-data = toSignal(this.service.getData());
-```
-### 🚀 Solution
-Use `toSignal()` to convert an Observable into a Signal. This automatically manages the subscription and integrates the data stream into the reactivity system.
----
-
-### 🚨 6. `BehaviorSubject` for Local State
-> [!NOTE]
-> **Context:** Component State Management
-### ❌ Bad Practice
-```typescript
-private count$ = new BehaviorSubject(0);
-getCount() { return this.count$.value; }
-```
-### ⚠️ Problem
-RxJS is overkill for simple synchronous state. `BehaviorSubject` requires `.value` for access and `.next()` for writes, increasing cognitive load.
-### ✅ Best Practice
-```typescript
-count = signal(0);
-// Access: count()
-// Update: count.set(1)
-```
-### 🚀 Solution
-Use `signal()` for local state. It is a primitive designed specifically for synchronizing UI and data.
----
-
-### 🚨 7. Derived State with `ngOnChanges`
-> [!NOTE]
-> **Context:** Reactivity
-### ❌ Bad Practice
-```typescript
-ngOnChanges(changes: SimpleChanges) {
-  if (changes['firstName']) {
-    this.fullName = `${this.firstName} ${this.lastName}`;
-  }
-}
-```
-### ⚠️ Problem
-`ngOnChanges` is triggered only when Inputs change, has complex typing, and runs before View initialization.
-### ✅ Best Practice
-```typescript
-fullName = computed(() => `${this.firstName()} ${this.lastName()}`);
-```
-### 🚀 Solution
-Use `computed()`. The signal is recalculated *only* when its dependencies change, and the result is memoized (cached).
----
-
-### 🚨 8. Constructor Dependency Injection
-> [!NOTE]
-> **Context:** DI Pattern
-### ❌ Bad Practice
-```typescript
-constructor(private http: HttpClient, private store: Store) {}
-```
-### ⚠️ Problem
-Constructors become cluttered with many dependencies. When inheriting classes, dependencies must be passed through `super()`.
-### ✅ Best Practice
-```typescript
-private http = inject(HttpClient);
-private store = inject(Store);
-```
-### 🚀 Solution
-Use the `inject()` function. It operates in the initialization context (fields or constructor), is type-safe, and does not require `super()` during inheritance.
----
-
-### 🚨 9. Modules (`NgModule`)
-> [!NOTE]
-> **Context:** App Architecture
-### ❌ Bad Practice
-```typescript
-@NgModule({
-  declarations: [AppComponent],
-  imports: [BrowserModule]
-})
-export class AppModule {}
-```
-### ⚠️ Problem
-Modules create an unnecessary level of indirection. Components become dependent on the module context, complicating Lazy Loading and testing.
-### ✅ Best Practice
-```typescript
-@Component({
-  standalone: true,
-  imports: [CommonModule]
-})
-```
-### 🚀 Solution
-Use Standalone Components. This is the Angular v14+ standard that makes components self-sufficient and tree-shakable.
----
-
-### 🚨 10. String-based Route Loading
-> [!NOTE]
-> **Context:** Lazy Loading Routing
-### ❌ Bad Practice
-```typescript
-loadChildren: () => import('./module').then(m => m.UserModule)
-```
-### ⚠️ Problem
-Loading modules pulls in transitive dependencies that might not be needed.
-### ✅ Best Practice
-```typescript
-loadComponent: () => import('./user.component').then(c => c.UserComponent)
-```
-### 🚀 Solution
-Use `loadComponent` for routing to Standalone components. This ensures minimal chunk size.
----
-
-### 🚨 11. Heavy Logic in Templates
-> [!NOTE]
-> **Context:** Template Performance
-### ❌ Bad Practice
-```html
-<div>{{ calculateTotal(items) }}</div>
-```
-### ⚠️ Problem
-The `calculateTotal` function is called during *every* Change Detection (CD) cycle, even if `items` have not changed. This kills UI performance.
-### ✅ Best Practice
-```typescript
-total = computed(() => this.calculateTotal(this.items()));
-```
-```html
-<div>{{ total() }}</div>
-```
-### 🚀 Solution
-Extract logic into `computed()` signals or Pure Pipes. They are only executed when input data changes.
----
-
-### 🚨 12. Manual Subscription Management (`takeUntil`)
-> [!NOTE]
-> **Context:** RxJS Memory Leaks
-### ❌ Bad Practice
-```typescript
-destroy$ = new Subject<void>();
-ngOnDestroy() { this.destroy$.next(); }
-stream$.pipe(takeUntil(this.destroy$)).subscribe();
-```
-### ⚠️ Problem
-It's easy to forget `takeUntil` or `unsubscribe`. Requires a lot of boilerplate code in every component.
-### ✅ Best Practice
-```typescript
-stream$.pipe(takeUntilDestroyed()).subscribe();
-```
-### 🚀 Solution
-Use the `takeUntilDestroyed()` operator. It automatically unsubscribes upon context destruction (component, directive, service).
----
-
-### 🚨 13. Deeply Nested Components Passing Data
-> [!NOTE]
-> **Context:** Prop Drilling
-### ❌ Bad Practice
-```html
-<!-- Parent -->
-<app-child [theme]="theme"></app-child>
-<!-- Child -->
-<app-grandchild [theme]="theme"></app-grandchild>
-```
-### ⚠️ Problem
-"Prop drilling" heavily couples intermediate components to data they don't need, just for the sake of passing it deeper.
-### ✅ Best Practice
-```typescript
-// Service
-theme = signal('dark');
-// Grandchild
-theme = inject(ThemeService).theme;
-```
-### 🚀 Solution
-Use Signal Stores or services for state sharing, or the new `input()` API with context inheritance (in the future).
----
-
-### 🚨 14. Accessing DOM directly (`ElementRef.nativeElement`)
-> [!NOTE]
-> **Context:** Security & Abstraction
-### ❌ Bad Practice
-```typescript
-el.nativeElement.style.backgroundColor = 'red';
-```
-### ⚠️ Problem
-Direct DOM access breaks abstraction (doesn't work in SSR/Web Workers) and opens up XSS vulnerabilities. It bypasses Angular Sanitization mechanisms.
-### ✅ Best Practice
-```typescript
-// Use Renderer2 or bindings
-<div [style.background-color]="color()"></div>
-```
-### 🚀 Solution
-Use style/class bindings or `Renderer2`. For direct manipulations, consider directives.
----
-
-### 🚨 15. Zone.js overhead
-> [!NOTE]
-> **Context:** Change Detection
-### ❌ Bad Practice
-The application relies on Zone.js for any asynchronous event (setTimeout, Promise, XHR).
-### ⚠️ Problem
-Zone.js patches all browser APIs, adding overhead and increasing bundle size. CD triggers more often than necessary.
-### ✅ Best Practice
-```typescript
-bootstrapApplication(App, {
-  providers: [provideExperimentalZonelessChangeDetection()]
-});
-```
-### 🚀 Solution
-Migrate to Zoneless mode. Use Signals to notify Angular when a re-render is needed.
----
-[⬆️ Back to Top](#)
 ## 📚 Specialized Topics
 
 For further reading, please refer to the following specialized guides:
diff --git a/frontend/design-ui/basics.md b/frontend/design-ui/basics.md
new file mode 100644
index 0000000..204fdca
--- /dev/null
+++ b/frontend/design-ui/basics.md
@@ -0,0 +1,29 @@
+---
+technology: UI/UX Design
+domain: frontend
+level: Senior/Architect
+version: Latest
+tags: [vibe-coding, documentation, best-practices, architecture, design-system, accessibility]
+ai_role: Senior Vibe Coding Expert
+last_updated: 2026-03-29
+---
+
+# 🚀 UI/UX Basics & General
+
+[⬆️ Back to Top](./readme.md)
+
+### 🚨 1. Using Non-semantic HTML Elements
+> [!NOTE]
+> **Context:** Accessibility
+### ❌ Bad Practice
+```html
+<div class="button" onclick="submit()">Submit</div>
+```
+### ⚠️ Problem
+Using non-semantic elements for interactive components breaks keyboard navigation and screen reader support.
+### ✅ Best Practice
+```html
+<button onclick="submit()">Submit</button>
+```
+### 🚀 Solution
+Always use native, semantic HTML elements (e.g., `<button>`, `<a>`, `<nav>`, `<main>`) to ensure built-in accessibility and better SEO.
diff --git a/frontend/design-ui/readme.md b/frontend/design-ui/readme.md
index df0b2ad..45e29f3 100644
--- a/frontend/design-ui/readme.md
+++ b/frontend/design-ui/readme.md
@@ -127,4 +127,13 @@ Scattering hardcoded visual values across the codebase eliminates the ability to
 
 
 ### 🚀 Solution
-Extracting visual properties into centrally managed Design Tokens is MANDATORY. This pattern enforces strict isolation boundaries and standardizes deterministic visual properties. It STRICTLY prevents arbitrary inline style manipulation, mitigating potential style-based injection vulnerabilities, and creates a predictable environment optimized for parsing and UI refactoring by AI agents, improving overall rendering performance.
\ No newline at end of file
+Extracting visual properties into centrally managed Design Tokens is MANDATORY. This pattern enforces strict isolation boundaries and standardizes deterministic visual properties. It STRICTLY prevents arbitrary inline style manipulation, mitigating potential style-based injection vulnerabilities, and creates a predictable environment optimized for parsing and UI refactoring by AI agents, improving overall rendering performance.
+## 📚 Specialized Topics
+
+For further reading, please refer to the following specialized guides:
+
+- [🚀 Basics & General](./basics.md)
+- [💅 Styling](./styling.md)
+- [📱 Responsive Design](./responsive-design.md)
+- [♿ Accessibility](./accessibility.md)
+- [🧱 Component Architecture](./component-architecture.md)
diff --git a/frontend/javascript/basic-syntax.md b/frontend/javascript/basic-syntax.md
index 85395c7..4536f88 100644
--- a/frontend/javascript/basic-syntax.md
+++ b/frontend/javascript/basic-syntax.md
@@ -12,6 +12,22 @@ last_updated: 2026-04-05
 
 [⬆️ Back to Top](./readme.md)
 
+### 🚨 0. Common Pitfall
+> [!NOTE]
+> **Context:** An example of a common JavaScript pitfall.
+### ❌ Bad Practice
+```javascript
+var name = "Alice";
+```
+### ⚠️ Problem
+Using `var` leads to unpredictable scoping issues and hoisting bugs.
+### ✅ Best Practice
+```javascript
+const name = "Alice";
+```
+### 🚀 Solution
+Strictly use `const` and `let` to ensure block scoping and predictability.
+
 ### 🚨 1. `var` vs `const/let`
 > [!NOTE]
 > **Context:** Scoping and hoisting mechanisms in modern JavaScript. `var` is function-scoped and hoisted, leading to unpredictable behavior and accidental global leakage.
diff --git a/frontend/javascript/readme.md b/frontend/javascript/readme.md
index f195912..84ee979 100644
--- a/frontend/javascript/readme.md
+++ b/frontend/javascript/readme.md
@@ -22,22 +22,6 @@ Please refer to the specialized guides for detailed best practices:
 - [🧹 Clean Code & Logic](./clean-code.md)
 
 
-## 🚨 0. Common Pitfall
-> [!NOTE]
-> **Context:** An example of a common JavaScript pitfall.
-### ❌ Bad Practice
-```javascript
-var name = "Alice";
-```
-### ⚠️ Problem
-Using `var` leads to unpredictable scoping issues and hoisting bugs.
-### ✅ Best Practice
-```javascript
-const name = "Alice";
-```
-### 🚀 Solution
-Strictly use `const` and `let` to ensure block scoping and predictability.
-
 ## 📚 Specialized Topics
 
 For further reading, please refer to the following specialized guides:
diff --git a/frontend/qwik/basics.md b/frontend/qwik/basics.md
new file mode 100644
index 0000000..67215b8
--- /dev/null
+++ b/frontend/qwik/basics.md
@@ -0,0 +1,53 @@
+---
+technology: Qwik
+domain: frontend
+level: Senior/Architect
+version: "1.x"
+tags: [best-practices, clean-code, architecture-patterns, vibe-coding, cursor-rules, typescript, software-architecture, system-design, solid-principles, production-ready, programming-standards, react-best-practices, node-js, design-patterns, scalable-code, windsurf-rules, ai-coding, fsd, ddd, enterprise-patterns]
+ai_role: Senior Qwik Expert
+last_updated: 2026-03-22
+---
+
+# 🚀 Qwik Basics & Popular Patterns
+
+[⬆️ Back to Top](./readme.md)
+
+### 🚨 1. eagerly Loading Code
+> [!NOTE]
+> **Context:** Loading code in Qwik
+### ❌ Bad Practice
+```tsx
+export const MyComponent = () => {
+    const data = eagerlyLoadData(); // blocking!
+    return <div>{data}</div>;
+}
+```
+### ⚠️ Problem
+Loading code eagerly blocks rendering and defeats the purpose of resumability.
+### ✅ Best Practice
+```tsx
+export const MyComponent = component$(() => {
+    const data = useResource$(() => loadDataLazy());
+    return <Resource value={data} onResolved={(d) => <div>{d}</div>} />;
+});
+```
+### 🚀 Solution
+Wrap components with `component$()` and use `useResource$()` to guarantee lazy loading and non-blocking resumability.
+
+### 🚨 2. Passing Closures as Props
+> [!NOTE]
+> **Context:** Component Props
+### ❌ Bad Practice
+```tsx
+const Component = ({ onClick }) => <button onClick={onClick}>Click</button>;
+```
+### ⚠️ Problem
+Closures cannot be serialized natively by Qwik, breaking resumability and throwing an error.
+### ✅ Best Practice
+```tsx
+const Component = component$(({ onClick$ }: { onClick$: PropFunction<() => void> }) => (
+  <button onClick$={onClick$}>Click</button>
+));
+```
+### 🚀 Solution
+Use the `$` suffix (`onClick$`) to mark the prop as a `PropFunction`, allowing Qwik to serialize the closure and load it lazily.
diff --git a/frontend/qwik/readme.md b/frontend/qwik/readme.md
index a482088..8f6cf9c 100644
--- a/frontend/qwik/readme.md
+++ b/frontend/qwik/readme.md
@@ -25,29 +25,11 @@ last_updated: 2026-03-22
 
 - Adhere to the defined [Architectural Patterns](../../architectures/readme.md) when building applications.
 - Strongly prefer **Feature Sliced Design (FSD)** for applications scaling across multiple teams.
-## 🚀 I. Basics & Popular
-## 🚨 1. Passing Closures as Props
-> [!NOTE]
-> **Context:** Component Props
-### ❌ Bad Practice
-```tsx
-const Component = ({ onClick }) => <button onClick={onClick}>Click</button>;
-```
-### ⚠️ Problem
-Closures cannot be serialized natively by Qwik, breaking resumability and throwing an error.
-### ✅ Best Practice
-```tsx
-const Component = component$(({ onClick$ }: { onClick$: PropFunction<() => void> }) => (
-  <button onClick$={onClick$}>Click</button>
-));
-```
-### 🚀 Solution
-Use the `$` suffix (`onClick$`) to mark the prop as a `PropFunction`, allowing Qwik to serialize the closure and load it lazily.
-
 ## 📚 Specialized Topics
 
 For further reading, please refer to the following specialized guides:
 
+- [🚀 Basics & Popular](./basics.md)
 - [🚀 Advanced Performance](./performance.md)
 - [📦 State Management](./state-management.md)
 - [🧪 Testing](./testing.md)
diff --git a/frontend/react/basics.md b/frontend/react/basics.md
new file mode 100644
index 0000000..729faf4
--- /dev/null
+++ b/frontend/react/basics.md
@@ -0,0 +1,71 @@
+---
+technology: React
+domain: frontend
+level: Senior/Architect
+version: "19+"
+tags: [react, best-practices, architecture, clean-code, scalable-code, modern-react, server-components]
+ai_role: Senior React Expert
+last_updated: 2026-03-22
+---
+
+# 🚀 React Basics & Popular Patterns
+
+[⬆️ Back to Top](./readme.md)
+
+### 🚨 1. Direct DOM Manipulation
+> [!NOTE]
+> **Context:** Updating elements in a React component.
+### ❌ Bad Practice
+```tsx
+function Component() {
+  const handleClick = () => {
+    document.getElementById('my-element').style.color = 'red';
+  };
+  return <div id="my-element" onClick={handleClick}>Click me</div>;
+}
+```
+### ⚠️ Problem
+Direct DOM manipulation bypasses React's virtual DOM, causing inconsistencies between the actual DOM and React's internal state, leading to forced synchronous layouts and potential XSS vulnerabilities.
+### ✅ Best Practice
+```tsx
+function Component() {
+  const [isActive, setIsActive] = useState(false);
+  return (
+    <div
+      style={{ color: isActive ? 'red' : 'black' }}
+      onClick={() => setIsActive(!isActive)}
+    >
+      Click me
+    </div>
+  );
+}
+```
+### 🚀 Solution
+Always use state and props to drive the UI. React uses a virtual DOM to efficiently update the real DOM based on state changes, ensuring deterministic rendering loops.
+
+### 🚨 2. Large Component Files
+> [!NOTE]
+> **Context:** Managing component complexity.
+### ❌ Bad Practice
+```tsx
+function MassiveDashboard() {
+  // 500 lines of state and hooks
+  // 1000 lines of JSX layout
+  return <div>...</div>;
+}
+```
+### ⚠️ Problem
+Massive components are difficult to read, test, and maintain. They violate the Single Responsibility Principle and trigger overly broad re-renders when local state changes.
+### ✅ Best Practice
+```tsx
+function Dashboard() {
+  return (
+    <DashboardLayout>
+      <Sidebar />
+      <MainContent />
+    </DashboardLayout>
+  );
+}
+```
+### 🚀 Solution
+Break down the UI into smaller, reusable components. Extract logic into custom hooks and modularize presentational elements into separate, encapsulated files.
diff --git a/frontend/react/readme.md b/frontend/react/readme.md
index c62e2b8..fdec094 100644
--- a/frontend/react/readme.md
+++ b/frontend/react/readme.md
@@ -20,69 +20,11 @@ last_updated: 2026-03-22
 
 - Adhere to the defined [Architectural Patterns](../../architectures/readme.md) when building applications.
 - Strongly prefer **Feature Sliced Design (FSD)** for applications scaling across multiple teams.
-## 🚀 I. Basics & Popular
-
-### 🚨 1. Direct DOM Manipulation
-> [!NOTE]
-> **Context:** Updating elements in a React component.
-### ❌ Bad Practice
-```tsx
-function Component() {
-  const handleClick = () => {
-    document.getElementById('my-element').style.color = 'red';
-  };
-  return <div id="my-element" onClick={handleClick}>Click me</div>;
-}
-```
-### ⚠️ Problem
-Direct DOM manipulation bypasses React's virtual DOM, causing inconsistencies between the actual DOM and React's internal state, leading to forced synchronous layouts and potential XSS vulnerabilities.
-### ✅ Best Practice
-```tsx
-function Component() {
-  const [isActive, setIsActive] = useState(false);
-  return (
-    <div
-      style={{ color: isActive ? 'red' : 'black' }}
-      onClick={() => setIsActive(!isActive)}
-    >
-      Click me
-    </div>
-  );
-}
-```
-### 🚀 Solution
-Always use state and props to drive the UI. React uses a virtual DOM to efficiently update the real DOM based on state changes, ensuring deterministic rendering loops.
-
-### 🚨 2. Large Component Files
-> [!NOTE]
-> **Context:** Managing component complexity.
-### ❌ Bad Practice
-```tsx
-function MassiveDashboard() {
-  // 500 lines of state and hooks
-  // 1000 lines of JSX layout
-  return <div>...</div>;
-}
-```
-### ⚠️ Problem
-Massive components are difficult to read, test, and maintain. They violate the Single Responsibility Principle and trigger overly broad re-renders when local state changes.
-### ✅ Best Practice
-```tsx
-function Dashboard() {
-  return (
-    <DashboardLayout>
-      <Sidebar />
-      <MainContent />
-    </DashboardLayout>
-  );
-}
-```
-### 🚀 Solution
-Break down the UI into smaller, reusable components. Extract logic into custom hooks and modularize presentational elements into separate, encapsulated files.
 ## 📚 Specialized Topics
 
 For further reading, please refer to the following specialized guides:
 
+- [🚀 Basics & Popular](./basics.md)
 - [🔄 State Management](./state-management.md)
 - [⚡ Performance](./performance.md)
 - [🛡️ Security](./security.md)
diff --git a/frontend/solidjs/basics.md b/frontend/solidjs/basics.md
new file mode 100644
index 0000000..63e21cc
--- /dev/null
+++ b/frontend/solidjs/basics.md
@@ -0,0 +1,29 @@
+---
+technology: SolidJS
+domain: frontend
+level: Senior/Architect
+version: "1.8+"
+tags: [best-practices, clean-code, architecture-patterns, vibe-coding, cursor-rules, typescript, software-architecture, system-design, solid-principles, production-ready, programming-standards, react-best-practices, node-js, design-patterns, scalable-code, windsurf-rules, ai-coding, fsd, ddd, enterprise-patterns]
+ai_role: Senior SolidJS Expert
+last_updated: 2026-03-22
+---
+
+# 🚀 SolidJS Basics & Popular Patterns
+
+[⬆️ Back to Top](./readme.md)
+
+### 🚨 1. Using JSX Map for Lists
+> [!NOTE]
+> **Context:** Rendering Lists
+### ❌ Bad Practice
+```tsx
+return <ul>{items().map(item => <li>{item.name}</li>)}</ul>;
+```
+### ⚠️ Problem
+Using `.map` creates the DOM nodes once and does not react to array changes optimally, leading to unnecessary re-renders or lost reactivity.
+### ✅ Best Practice
+```tsx
+return <ul><For each={items()}>{item => <li>{item.name}</li>}</For></ul>;
+```
+### 🚀 Solution
+Use the `<For>` component. It caches DOM elements and handles granular updates when the array changes.
diff --git a/frontend/solidjs/readme.md b/frontend/solidjs/readme.md
index 628efdd..f67cd34 100644
--- a/frontend/solidjs/readme.md
+++ b/frontend/solidjs/readme.md
@@ -26,26 +26,11 @@ last_updated: 2026-03-22
 - Adhere to the defined [Architectural Patterns](../../architectures/readme.md) when building applications.
 - Strongly prefer **Feature Sliced Design (FSD)** for applications scaling across multiple teams.
 ## 🚀 I. Basics & Popular
-## 🚨 1. Using JSX Map for Lists
-> [!NOTE]
-> **Context:** Rendering Lists
-### ❌ Bad Practice
-```tsx
-return <ul>{items().map(item => <li>{item.name}</li>)}</ul>;
-```
-### ⚠️ Problem
-Using `.map` creates the DOM nodes once and does not react to array changes optimally, leading to unnecessary re-renders or lost reactivity.
-### ✅ Best Practice
-```tsx
-return <ul><For each={items()}>{item => <li>{item.name}</li>}</For></ul>;
-```
-### 🚀 Solution
-Use the `<For>` component. It caches DOM elements and handles granular updates when the array changes.
-
 ## 📚 Specialized Topics
 
 For further reading, please refer to the following specialized guides:
 
+- [🚀 Basics & Popular](./basics.md)
 - [🚀 Advanced Performance](./performance.md)
 - [📦 State Management](./state-management.md)
 - [🧪 Testing](./testing.md)
diff --git a/frontend/typescript/fundamentals.md b/frontend/typescript/fundamentals.md
new file mode 100644
index 0000000..e3208d7
--- /dev/null
+++ b/frontend/typescript/fundamentals.md
@@ -0,0 +1,156 @@
+---
+technology: TypeScript
+domain: frontend
+level: Senior/Architect
+version: 5.5+
+tags: [typescript, type-safety, clean-code, best-practices, architecture]
+ai_role: Senior TypeScript Architecture Expert
+last_updated: 2026-03-29
+---
+
+# 🚀 TypeScript Fundamentals
+
+[⬆️ Back to Top](./readme.md)
+
+### 🚨 1. `any` vs `unknown`
+> [!NOTE]
+> **Context:** Handling data of an uncertain type. `any` disables all type-checking, while `unknown` forces safety.
+### ❌ Bad Practice
+```typescript
+function process(data: any) {
+    console.log(data.name); // No error, but might crash at runtime
+}
+```
+### ⚠️ Problem
+`any` is a "get out of jail free" card that propagates through the codebase, effectively turning off TypeScript's benefits and hiding potential runtime exceptions.
+### ✅ Best Practice
+```typescript
+function process(data: unknown) {
+    if (data && typeof data === 'object' && 'name' in data) {
+        console.log((data as { name: string }).name);
+    }
+}
+```
+### 🚀 Solution
+Use `unknown` for values whose type is not yet determined. It requires a type check or assertion before usage, ensuring the developer acknowledges the data's structure.
+
+### 🚨 2. `null` vs `undefined` in APIs
+> [!NOTE]
+> **Context:** Distinguishing between "value not provided" and "value is empty."
+### ❌ Bad Practice
+```typescript
+interface UserResponse {
+    bio: string | null | undefined;
+}
+```
+### ⚠️ Problem
+Using both creates ambiguity. In JSON, `undefined` properties are often stripped, while `null` is preserved. Mixing them increases complexity in conditional checks.
+### ✅ Best Practice
+```typescript
+interface UserResponse {
+    bio?: string | null; // Optional if missing, null if explicitly empty
+}
+```
+### 🚀 Solution
+Standardize: use `undefined` (optional properties) for missing keys and `null` for intentional absence of value. Avoid using both for the same field unless strictly required by a legacy API.
+
+### 🚨 3. `Array<T>` vs `T[]`
+> [!NOTE]
+> **Context:** Visual consistency in array declarations.
+### ❌ Bad Practice
+```typescript
+const users: Array<User> = [];
+const complex: Array<string | number> = [];
+```
+### ⚠️ Problem
+`Array<T>` is more verbose and can be confused with other generic types. It is harder to scan in complex signatures.
+### ✅ Best Practice
+```typescript
+const users: User[] = [];
+const complex: (string | number)[] = [];
+```
+### 🚀 Solution
+Prefer the shorthand `T[]`. It is idiomatic, more readable, and clearly distinguishes arrays from other generic containers like `Record` or `Promise`.
+
+### 🚨 4. `interface` vs `type`
+> [!NOTE]
+> **Context:** Defining object structures and aliases.
+### ❌ Bad Practice
+```typescript
+type Point = { x: number; y: number; }; // Bad: Using type for object structure
+interface Status { status: "active" | "inactive"; } // Bad: Trying to use interface for a union-like structure
+```
+### ⚠️ Problem
+Using `type` for object structures prevents declaration merging and reduces performance in TS compiler caching. Using `interface` for unions is impossible or leads to awkward wrapper objects.
+### ✅ Best Practice
+```typescript
+interface Point { x: number; y: number; }
+type Status = "active" | "inactive";
+```
+### 🚀 Solution
+> [!IMPORTANT]
+> Prefer `interface` for structure, `type` for unions. Interfaces provide better error messages and performance for structural types in TypeScript 5.x.
+
+### 🚨 5. Function Overloads vs Union Types
+> [!NOTE]
+> **Context:** Handling functions with different input/output combinations.
+### ❌ Bad Practice
+```typescript
+function format(input: string): string;
+function format(input: number): string;
+function format(input: any): string {
+    return String(input);
+}
+```
+### ⚠️ Problem
+Overloads are verbose and can be harder to implement correctly. They often require `any` or complex type-casting in the implementation body.
+### ✅ Best Practice
+```typescript
+function format(input: string | number): string {
+    return String(input);
+}
+```
+### 🚀 Solution
+Prefer Union types when the implementation logic is identical for all types. Reserve overloads only for cases where the return type strictly depends on the input type and cannot be expressed via generics.
+
+### 🚨 6. Global Scope Pollution (Legacy Namespaces)
+> [!NOTE]
+> **Context:** Organizing code in the ES Module era.
+### ❌ Bad Practice
+```typescript
+namespace Utils {
+    export const log = (msg: string) => console.log(msg);
+}
+```
+### ⚠️ Problem
+Namespaces are a legacy TypeScript feature. They don't play well with modern bundlers (Tree Shaking), are harder to test, and can lead to naming collisions in the global scope.
+### ✅ Best Practice
+```typescript
+// utils.ts
+export const log = (msg: string) => console.log(msg);
+```
+### 🚀 Solution
+Use ES Modules (`export`/`import`). They are the industry standard, supported by all modern environments, and allow for better static analysis.
+
+### 🚨 7. `enum` vs `const object`
+> [!NOTE]
+> **Context:** Grouping related constants.
+### ❌ Bad Practice
+```typescript
+enum Status {
+    Active,
+    Inactive
+}
+```
+### ⚠️ Problem
+Enums generate extra runtime code and have "reverse mapping" behavior that can lead to bugs (e.g., `Status[0]` returns "Active"). They also don't align with "TypeScript as a type-only layer."
+### ✅ Best Practice
+```typescript
+const STATUS = {
+    ACTIVE: 'active',
+    INACTIVE: 'inactive'
+} as const;
+type Status = typeof STATUS[keyof typeof STATUS];
+```
+### 🚀 Solution
+Use `const` objects with `as const` and a derived union type. This is more predictable, emits cleaner code, and is easier to iterate over.
diff --git a/frontend/typescript/readme.md b/frontend/typescript/readme.md
index 415b8c4..fabe414 100644
--- a/frontend/typescript/readme.md
+++ b/frontend/typescript/readme.md
@@ -12,154 +12,9 @@ last_updated: 2026-03-29
 
 ![TypeScript Logo](https://img.icons8.com/?size=100&id=uJM6fQYqDaZK&format=png&color=000000)
 ## 🚀 I. Fundamentals (1-10)
-## ⚡ 1. `any` vs `unknown`
-> [!NOTE]
-> **Context:** Handling data of an uncertain type. `any` disables all type-checking, while `unknown` forces safety.
-### ❌ Bad Practice
-```typescript
-function process(data: unknown) {
-    console.log(data.name); // No error, but might crash at runtime
-}
-```
-### ⚠️ Problem
-`any` is a "get out of jail free" card that propagates through the codebase, effectively turning off TypeScript's benefits and hiding potential runtime exceptions.
-### ✅ Best Practice
-```typescript
-function process(data: unknown) {
-    if (data && typeof data === 'object' && 'name' in data) {
-        console.log((data as { name: string }).name);
-    }
-}
-```
-### 🚀 Solution
-Use `unknown` for values whose type is not yet determined. It requires a type check or assertion before usage, ensuring the developer acknowledges the data's structure.
----
-## ⚡ 2. `null` vs `undefined` in APIs
-> [!NOTE]
-> **Context:** Distinguishing between "value not provided" and "value is empty."
-### ❌ Bad Practice
-```typescript
-interface UserResponse {
-    bio: string | null | undefined;
-}
-```
-### ⚠️ Problem
-Using both creates ambiguity. In JSON, `undefined` properties are often stripped, while `null` is preserved. Mixing them increases complexity in conditional checks.
-### ✅ Best Practice
-```typescript
-interface UserResponse {
-    bio?: string | null; // Optional if missing, null if explicitly empty
-}
-```
-### 🚀 Solution
-Standardize: use `undefined` (optional properties) for missing keys and `null` for intentional absence of value. Avoid using both for the same field unless strictly required by a legacy API.
----
-## ⚡ 3. `Array<T>` vs `T[]`
-> [!NOTE]
-> **Context:** Visual consistency in array declarations.
-### ❌ Bad Practice
-```typescript
-const users: Array<User> = [];
-const complex: Array<string | number> = [];
-```
-### ⚠️ Problem
-`Array<T>` is more verbose and can be confused with other generic types. It is harder to scan in complex signatures.
-### ✅ Best Practice
-```typescript
-const users: User[] = [];
-const complex: (string | number)[] = [];
-```
-### 🚀 Solution
-Prefer the shorthand `T[]`. It is idiomatic, more readable, and clearly distinguishes arrays from other generic containers like `Record` or `Promise`.
----
-## ⚡ 4. `interface` vs `type`
-> [!NOTE]
-> **Context:** Defining object structures and aliases.
-### ❌ Bad Practice
-```typescript
-type Point = { x: number; y: number; }; // Bad: Using type for object structure
-interface Status { status: "active" | "inactive"; } // Bad: Trying to use interface for a union-like structure
-```
-### ⚠️ Problem
-Using `type` for object structures prevents declaration merging and reduces performance in TS compiler caching. Using `interface` for unions is impossible or leads to awkward wrapper objects.
-### ✅ Best Practice
-```typescript
-interface Point { x: number; y: number; }
-type Status = "active" | "inactive";
-```
-### 🚀 Solution
-> [!IMPORTANT]
-> Prefer `interface` for structure, `type` for unions. Interfaces provide better error messages and performance for structural types in TypeScript 5.x.
->
-> **Logical Conflict Resolution:** To enforce the repo standard, NEVER use `type` for defining object structures, and NEVER use `interface` for unions.
----
-## ⚡ 5. Function Overloads vs Union Types
-> [!NOTE]
-> **Context:** Handling functions with different input/output combinations.
-### ❌ Bad Practice
-```typescript
-function format(input: string): string;
-function format(input: number): string;
-function format(input: unknown): string {
-    return String(input);
-}
-```
-### ⚠️ Problem
-Overloads are verbose and can be harder to implement correctly. They often require `any` or complex type-casting in the implementation body.
-### ✅ Best Practice
-```typescript
-function format(input: string | number): string {
-    return String(input);
-}
-```
-### 🚀 Solution
-Prefer Union types when the implementation logic is identical for all types. Reserve overloads only for cases where the return type strictly depends on the input type and cannot be expressed via generics.
----
-## 🎯 6. Global Scope Pollution (Legacy Namespaces)
-> [!NOTE]
-> **Context:** Organizing code in the ES Module era.
-### ❌ Bad Practice
-```typescript
-namespace Utils {
-    export const log = (msg: string) => console.log(msg);
-}
-```
-### ⚠️ Problem
-Namespaces are a legacy TypeScript feature. They don't play well with modern bundlers (Tree Shaking), are harder to test, and can lead to naming collisions in the global scope.
-### ✅ Best Practice
-```typescript
-// utils.ts
-export const log = (msg: string) => console.log(msg);
-```
-### 🚀 Solution
-Use ES Modules (`export`/`import`). They are the industry standard, supported by all modern environments, and allow for better static analysis.
----
-## ⚡ 7. `enum` vs `const object`
-> [!NOTE]
-> **Context:** Grouping related constants.
-### ❌ Bad Practice
-```typescript
-enum Status {
-    Active,
-    Inactive
-}
-```
-### ⚠️ Problem
-Enums generate extra runtime code and have "reverse mapping" behavior that can lead to bugs (e.g., `Status[0]` returns "Active"). They also don't align with "TypeScript as a type-only layer."
-### ✅ Best Practice
-```typescript
-const STATUS = {
-    ACTIVE: 'active',
-    INACTIVE: 'inactive'
-} as const;
-type Status = typeof STATUS[keyof typeof STATUS];
-```
-### 🚀 Solution
-Use `const` objects with `as const` and a derived union type. This is more predictable, emits cleaner code, and is easier to iterate over.
----
-
 Please refer to the specialized guides for detailed best practices:
 
+- [🚀 Fundamentals](./fundamentals.md)
 - [📜 Types & Interfaces](./types-interfaces.md)
 - [🛡️ Logic Safety](./logic-safety.md)