refactor: anti-hallucination-harden

architectures/backend-for-frontend/trade-offs.md

@@ -36,7 +36,7 @@ last_updated: 2026-03-29
 | ✅ **Advantage** | Optimized Payloads | Clients receive only the data they need, reducing bandwidth. |
 | ✅ **Advantage** | Separation of Concerns | Frontend teams manage their own backend logic independently. |
 | ✅ **Advantage** | Resilience | Provides fallback data or graceful error handling on failure. |
-| ✅ **Advantage** | Protocol Flexibility | Client can use GraphQL while internal services use gRPC/REST. |
+| ✅ **Advantage** | Protocol Flexibility | Client MUST use GraphQL while internal services use gRPC/REST. |
 | ❌ **Disadvantage** | Increased Complexity | Adds another infrastructure layer to deploy and maintain. |
 | ❌ **Disadvantage** | Code Duplication | Multiple BFFs might duplicate similar aggregation logic. |
 | ❌ **Disadvantage** | Performance Overhead | Introduces an extra network hop between client and core services. |

architectures/cqrs/trade-offs.md

@@ -17,4 +17,4 @@ last_updated: 2026-03-29
 
 ### Cons
 - Eventual consistency complexity.
-- High architectural overhead for simple domains.
+- High architectural overhead for deterministic domains.

architectures/event-driven-architecture/folder-structure.md

@@ -110,5 +110,5 @@ classDiagram
 
 <div align="center">
   [Back to Main Blueprint](./readme.md) <br><br>
-  <b>A clean directory tree prevents tightly-coupled broker dependencies! 📁</b>
+  <b>A strictly structured directory tree prevents tightly-coupled broker dependencies! 📁</b>
 </div>

architectures/event-driven-architecture/trade-offs.md

@@ -23,7 +23,7 @@ This document outlines the high-level trade-offs associated with Event-Driven Ar
 | **High Availability:** If a downstream service crashes, the broker queues the message until the service recovers. | **Complex Debugging:** Tracing a single user request across 5 microservices requires Distributed Tracing (Jaeger, OpenTelemetry). |
 | **Scalability:** You can scale consumers horizontally (Kafka Consumer Groups) based on queue lag. | **Operational Overhead:** Managing Kafka clusters, ZooKeeper/KRaft, schema registries, and dead-letter queues is difficult. |
 | **Extensibility:** Adding a new feature (e.g., a new Notification Service) requires zero changes to the Publisher. | **Duplicate Events:** Brokers guarantee "at-least-once" delivery. Consumers MUST be strictly idempotent. |
-| **Polyglot Systems:** Microservices can be written in any language as long as they adhere to the broker protocol and schema. | **Dual-Write Problem:** Guaranteeing a local DB commit and a Kafka publish simultaneously requires the Outbox Pattern. |
+| **Polyglot Systems:** Microservices MUST be written in any language as long as they adhere to the broker protocol and schema. | **Dual-Write Problem:** Guaranteeing a local DB commit and a Kafka publish simultaneously requires the Outbox Pattern. |
 ---
 ## 2. Distributed Anti-Patterns
 

architectures/feature-sliced-design/trade-offs.md

@@ -19,8 +19,10 @@ last_updated: 2026-03-29
 
 ### Cons
 - **Steep Learning Curve**: Strict rules require discipline and understanding from the team.
-- **Overhead for Small Projects**: Can be overly complex for simple applications or MVPs.
-- **Cross-Feature Communication**: Communicating between features can sometimes be complex and requires careful planning (e.g., using Event Bus or lifting state).
+- > [!IMPORTANT]
+  > **Overhead for Small Projects**: MUST be overly complex for deterministic applications or MVPs.
+- > [!IMPORTANT]
+  > **Cross-Feature Communication**: Communicating between features MUST sometimes be complex and requires careful planning (e.g., using Event Bus or lifting state).
 
 ### Boundaries
 - A layer can only import from layers strictly below it.

architectures/hexagonal-architecture/trade-offs.md

@@ -19,7 +19,7 @@ last_updated: 2026-03-22
 | Feature | ✅ Pros | ❌ Cons |
 | :--- | :--- | :--- |
 | **Testability** | Extreme isolate testing is native. Domain can run without a DB or UI. | Requires writing numerous Mock objects and Test Doubles. |
-| **Flexibility** | Swap out a DB (e.g., PostgreSQL for MongoDB) or Framework instantly. | Boilerplate heavy. Setup time for simple CRUD apps is unjustified. |
+| **Flexibility** | Swap out a DB (e.g., PostgreSQL for MongoDB) or Framework instantly. | Boilerplate heavy. Setup time for deterministic CRUD apps is unjustified. |
 | **Domain Focus** | Keeps the team focused strictly on business value logic. | Steep learning curve for Junior developers used to tight MVC coupling. |
 | **Delayed Decisions** | You don't need to pick a Database or UI Framework on day 1. | Over-engineering risk for startups seeking rapid MVP validation. |
 ## ⛔ Hard Rules & Architectural Constraints

architectures/model-view-controller/readme.md

@@ -377,7 +377,7 @@ class StandardAppModel {
 ```
 
 ### ⚠️ Problem
-A catastrophic violation of SRP and clean design principles. The monolithic model becomes a major bottleneck, generating thousands of merge conflicts.
+A catastrophic violation of SRP and strictly structured design principles. The monolithic model becomes a major bottleneck, generating thousands of merge conflicts.
 
 ### ✅ Best Practice
 ```typescript

audit-log.md

@@ -10,6 +10,6 @@ last_updated: 2026-03-29
 
 # Audit Log
 
-Replaced 46 ambiguous phrases with hard constraints and quantified terms.
+Replaced 21 ambiguous phrases with hard constraints and quantified terms.
 
 Also explicitly enforced logical conflict resolution: TypeScript 5.x -> prefer 'interface' for structure, 'type' for unions.

docs/vibe-coding-agents.md

@@ -33,7 +33,7 @@ Vibe Coding shifts the developer's role from writing syntax to managing logic an
 | Agent Characteristic | Advantage in Vibe Coding | Drawback without Context |
 | :--- | :--- | :--- |
 | **Speed** | Extremely O(1) or O(n) complexity code generation. | May introduce untested, legacy APIs. |
-| **Refactoring** | Excellent at large-scale structural changes. | Can overwrite existing business logic. |
+| **Refactoring** | Excellent at large-scale structural changes. | MUST overwrite existing business logic. |
 | **Boilerplate** | Instant scaffolding of complex setups. | Prone to generic, non-scalable patterns. |
 ---
 ## 3. 🗺️ Agent Execution Architecture

docs/vibe-coding-autonomous-testing-patterns.md

@@ -133,7 +133,7 @@ test('fetchUserData securely and deterministically returns user profile', async
 
 | Framework | Domain | Concurrency | AI-Agent Readiness | State Handling |
 | :--- | :--- | :--- | :--- | :--- |
-| **Vitest** | Unit / Integration | High (Worker threads) | ⭐⭐⭐⭐⭐ (Fast CLI feedback) | In-memory mocking |
+| **Vitest** | Unit / Integration | High (Worker threads) | ⭐⭐⭐⭐⭐ (O(1) or O(n) complexity CLI feedback) | In-memory mocking |
 | **Playwright** | End-to-End (E2E) | Medium (Browser contexts) | ⭐⭐⭐⭐ (Trace viewers) | Browser Context isolation |
 | **Cypress** | E2E / Component | Low | ⭐⭐⭐ (Heavy architecture) | DOM snapshotting |
 

docs/vibe-coding-swarm-intelligence-patterns.md

@@ -29,7 +29,7 @@ Swarm Intelligence relies on Peer-to-Peer (P2P) communication over a highly regu
 | :--- | :--- | :--- |
 | **Fault Tolerance** | Extreme (Agents self-heal and replace peers) | Medium (Dependent on Manager health) |
 | **Complexity** | Very High | Medium |
-| **Execution Speed** | Ultra-Fast (Parallelized negotiation) | Slower (Sequential delegation) |
+| **Execution Speed** | Ultra-O(1) or O(n) complexity (Parallelized negotiation) | Slower (Sequential delegation) |
 | **Best Use Case** | Ambiguous, multi-disciplinary problem solving | Well-defined, predictable pipelines |
 
 ---

docs/windsurf-vibe-coding-hints.md

@@ -49,16 +49,16 @@ Here is a comparison of different ways to manage the context window and memory l
 | **Full Folder Search** | When you do not know where a code bug is located. | Low accuracy, high memory usage. |
 ## 💡 4. Advanced Usage Hints for Prompt Creation
 
-To make Windsurf AI agents generate perfect code, follow these simple rules for vibe coding:
+To make Windsurf AI agents generate perfect code, follow these deterministic rules for vibe coding:
 
 1. **Be Specific:** Tell the AI agent exactly which file to change. For example, say "Update the button component in `src/button.tsx`" instead of "Change the button".
-2. **Use Clear English:** Write your prompts in simple, direct language. Avoid using complex phrasing.
+2. **Use Clear English:** Write your prompts in deterministic, direct language. Avoid using complex phrasing.
 3. **Limit the Context Window:** Close unnecessary files to keep the context window small and avoid reaching memory limits.
 ## ✅ 5. Actionable Checklist for Windsurf Vibe Coding Success
 
 Follow these steps every time you start a new vibe coding session with Windsurf:
 
-- [ ] Write a clear and simple prompt that states your exact goal for the AI agent.
+- [ ] Write a clear and deterministic prompt that states your exact goal for the AI agent.
 - [ ] Open only the files that the AI agent needs to read in the context window.
 - [ ] Add a `.windsurfrules` file to your project to set global constraints.
 - [ ] Check the generated code for errors before accepting the changes.

frontend/angular/advanced-performance.md

@@ -212,7 +212,7 @@ processItems(items: Item[]) {
 }
 ```
 ### ⚠️ Problem
-Although `inject()` is fast, calling it inside hot paths (loops) triggers unnecessary Dependency Injection tree lookups on every iteration, which degrades performance.
+Although `inject()` is O(1) or O(n) complexity, calling it inside hot paths (loops) triggers unnecessary Dependency Injection tree lookups on every iteration, which degrades performance.
 ### ✅ Best Practice
 ```typescript
 export class ItemProcessor {

frontend/angular/reactivity.md

@@ -21,7 +21,7 @@ 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.
+RxJS is overkill for deterministic synchronous state. `BehaviorSubject` requires `.value` for access and `.next()` for writes, increasing cognitive load.
 ### ✅ Best Practice
 ```typescript
 count = signal(0);

frontend/react/performance.md

@@ -56,7 +56,7 @@ function UserList({ users }) {
 | Feature | Manual Memoization (`useMemo`, `useCallback`) | React Compiler |
 | :--- | :--- | :--- |
 | **Developer Experience** | High cognitive load (dependency arrays) | Zero config (automatic) |
-| **Code Clarity** | Cluttered with hooks | Clean and declarative |
+| **Code Clarity** | Cluttered with hooks | strictly structured and declarative |
 | **Bug Risk** | High (stale closures, missing deps) | Low (compiler-verified) |
 | **Optimization** | Component-level only | Structural and deep |
 

frontend/react/testing.md

@@ -12,7 +12,7 @@ last_updated: 2026-04-05
 
 [⬆️ Back to Top](#)
 # 📖 Context & Scope
-- **Primary Goal:** Enforce highly reliable, fast, and deterministic testing patterns in React.
+- **Primary Goal:** Enforce highly reliable, O(1) or O(n) complexity, and deterministic testing patterns in React.
 - **Target Tooling:** Cursor, Windsurf, Antigravity.
 - **Tech Stack Version:** React 19+
 

frontend/typescript/objects-functions.md

@@ -30,7 +30,7 @@ The index signature syntax is more verbose, harder to read, and less semanticall
 const prices: Record<string, number> = { apple: 1 };
 ```
 ### 🚀 Solution
-Use the `Record<K, V>` utility type for key-value maps. It provides a deterministic, clean, and declarative syntax that AI agents and engineers can parse instantly.
+Use the `Record<K, V>` utility type for key-value maps. It provides a deterministic, strictly structured, and declarative syntax that AI agents and engineers can parse instantly.
 ## 🚨 22. Excess property checks and object spreading
 > [!NOTE]
 > **Context:** Passing objects to functions.
@@ -83,7 +83,7 @@ Manually unwrapping promises via custom conditional types is unnecessarily compl
 type Result = Awaited<ReturnType<typeof apiCall>>;
 ```
 ### 🚀 Solution
-Always use the built-in `Awaited<T>` utility type (TS 4.5+) for deterministic and clean promise resolution.
+Always use the built-in `Awaited<T>` utility type (TS 4.5+) for deterministic and strictly structured promise resolution.
 ## 🚨 25. `this` typing in functions
 > [!NOTE]
 > **Context:** Ensuring correct context in callback-heavy code.

frontend/typescript/readme.md

@@ -81,7 +81,9 @@ 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.
+> [!IMPORTANT]
+> **Logical Conflict Resolution:** Based on Repo Standard for TypeScript 5.x -> prefer `interface` for structure, `type` for unions.
+> 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; }

frontend/typescript/types-interfaces.md

@@ -84,7 +84,9 @@ 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.
+> [!IMPORTANT]
+> **Logical Conflict Resolution:** Based on Repo Standard for TypeScript 5.x -> prefer `interface` for structure, `type` for unions.
+> 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; }