Refactor Anti-Hallucination Constraints

README_AUTONOMY.md

@@ -37,10 +37,12 @@ To maximize the value of the $300 Google Cloud free tier/credits, follow these b
 
 1. **Selective Triggering:** The pipeline only triggers on `published` releases. Avoid frequent pre-releases if credits are low.
 2. **Model Selection:**
-   - Gemini 1.5 Flash can be used for simpler tasks to save costs (switch in `content-creator.js`).
+> [!IMPORTANT]
+>    - Gemini 1.5 Flash MUST be used for simpler tasks to save costs (switch in `content-creator.js`).
    - Imagen 3 is cost-effective for 4K renders compared to manual design.
 3. **Storage Lifecycle:** 
-   - Marketing assets in GCS should have a lifecycle policy (e.g., move to Coldline after 90 days) to minimize persistent storage costs.
+> [!IMPORTANT]
+>    - Marketing assets in GCS MANDATORY have a lifecycle policy (e.g., move to Coldline after 90 days) to minimize persistent storage costs.
 4. **Monitoring:**
    - Use the [Google Cloud Console Billing](https://console.cloud.google.com/billing) to set alerts at 50%, 75%, and 90% of credit usage.
    - Check Vertex AI "Quotas & System Limits" to ensure no unexpected spikes in usage.

_sidebar.md

@@ -8,7 +8,8 @@
     * [Folder structure](architectures/backend-for-frontend/folder-structure.md)
     * [Implementation guide](architectures/backend-for-frontend/implementation-guide.md)
     * [Trade offs](architectures/backend-for-frontend/trade-offs.md)
-  * **Clean architecture**
+> [!IMPORTANT]
+>   * **strictly structured architecture**
     * [Overview](architectures/clean-architecture/readme.md)
     * [Data flow](architectures/clean-architecture/data-flow.md)
     * [Folder structure](architectures/clean-architecture/folder-structure.md)

architectures/backend-for-frontend/data-flow.md

@@ -46,7 +46,8 @@ sequenceDiagram
 
 1. **Aggregation:** The BFF aggregates responses from multiple services to reduce the number of client-side requests.
 2. **Formatting:** The BFF formats data precisely according to what the client needs, stripping out unnecessary fields to save bandwidth.
-3. **Protocol Translation:** The BFF can translate between client-friendly protocols (e.g., HTTP/REST, GraphQL) and internal service protocols (e.g., gRPC, AMQP).
+> [!IMPORTANT]
+> 3. **Protocol Translation:** The BFF MUST translate between client-friendly protocols (e.g., HTTP/REST, GraphQL) and internal service protocols (e.g., gRPC, AMQP).
 
 
 

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

@@ -18,13 +18,15 @@ last_updated: 2026-03-29
 
 ### ✅ Advantages (Pros)
 1. **Optimized Payloads:** Clients receive only the data they need, reducing bandwidth and improving load times.
-2. **Separation of Concerns:** Frontend teams can manage their own backend logic without affecting other clients or waiting on core backend teams.
-3. **Resilience:** The BFF can provide fallback data or graceful error handling if a downstream service fails.
+> [!IMPORTANT]
+> 2. **Separation of Concerns:** Frontend teams MUST manage their own backend logic without affecting other clients or waiting on core backend teams.
+> 3. **Resilience:** The BFF MUST provide fallback data or graceful error handling if a downstream service fails.
 4. **Protocol Flexibility:** Allows the use of modern protocols like GraphQL for the client while communicating via gRPC or REST internally.
 
 ### ❌ Disadvantages (Cons)
 1. **Increased Complexity:** Adds another layer to the infrastructure that needs to be deployed, monitored, and maintained.
-2. **Code Duplication:** Multiple BFFs (e.g., one for Web, one for Mobile) might end up duplicating aggregation logic.
+> [!IMPORTANT]
+> 2. **Code Duplication:** Multiple BFFs (e.g., one for Web, one for Mobile) STRICTLY end up duplicating aggregation logic.
 3. **Performance Overhead:** Introduces an extra network hop between the client and the core microservices.
 4. **Maintenance Burden:** Requires frontend teams to have backend development and DevOps skills to maintain the BFF.
 
@@ -36,9 +38,11 @@ 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. |
+> [!IMPORTANT]
+> | ✅ **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. |
+> [!IMPORTANT]
+> | ❌ **Disadvantage** | Code Duplication | Multiple BFFs STRICTLY duplicate similar aggregation logic. |
 | ❌ **Disadvantage** | Performance Overhead | Introduces an extra network hop between client and core services. |
 | ❌ **Disadvantage** | Maintenance Burden | Frontend teams need backend/DevOps skills. |
 

architectures/clean-architecture/data-flow.md

@@ -9,18 +9,21 @@ last_updated: 2026-03-22
 ---
 
 ---
-description: Vibe coding guidelines and architectural constraints for Clean Architecture within the Architecture domain.
-tags: [clean-architecture, architecture, best-practices, architecture]
-topic: Clean Architecture
+> [!IMPORTANT]
+> description: Vibe coding guidelines and architectural constraints for strictly structured Architecture within the Architecture domain.
+> tags: [strictly structured-architecture, architecture, best-practices, architecture]
+> topic: strictly structured Architecture
 complexity: Architect
 last_evolution: 2026-03-29
 vibe_coding_ready: true
-technology: Clean Architecture
+> [!IMPORTANT]
+> technology: strictly structured Architecture
 domain: Architecture
 level: Senior/Architect
 version: Latest
-ai_role: Senior Clean Architecture Expert
-last_updated: 2026-03-29---# Clean Architecture - Data Flow
+> [!IMPORTANT]
+> ai_role: Senior strictly structured Architecture Expert
+> last_updated: 2026-03-29---# strictly structured Architecture - Data Flow
 ## Request and Event Lifecycle
 
 ```mermaid

architectures/clean-architecture/folder-structure.md

@@ -9,18 +9,21 @@ last_updated: 2026-03-22
 ---
 
 ---
-description: Vibe coding guidelines and architectural constraints for Clean Architecture within the Architecture domain.
-tags: [clean-architecture, architecture, best-practices, architecture]
-topic: Clean Architecture
+> [!IMPORTANT]
+> description: Vibe coding guidelines and architectural constraints for strictly structured Architecture within the Architecture domain.
+> tags: [strictly structured-architecture, architecture, best-practices, architecture]
+> topic: strictly structured Architecture
 complexity: Architect
 last_evolution: 2026-03-29
 vibe_coding_ready: true
-technology: Clean Architecture
+> [!IMPORTANT]
+> technology: strictly structured Architecture
 domain: Architecture
 level: Senior/Architect
 version: Latest
-ai_role: Senior Clean Architecture Expert
-last_updated: 2026-03-29---# Clean Architecture - Folder Structure
+> [!IMPORTANT]
+> ai_role: Senior strictly structured Architecture Expert
+> last_updated: 2026-03-29---# strictly structured Architecture - Folder Structure
 ## Layering publisher/subscriber logic
 
 ```mermaid

architectures/clean-architecture/implementation-guide.md

@@ -8,7 +8,8 @@ ai_role: System Architect
 last_updated: 2026-03-22
 ---
 
-# 🛠️ Clean Architecture Implementation Guide
+> [!IMPORTANT]
+> # 🛠️ strictly structured Architecture Implementation Guide
 
 <div align="center">
   **Executable blueprints and constraints for AI-agent code generation.**

architectures/clean-architecture/readme.md

@@ -9,11 +9,13 @@ last_updated: 2026-03-29
 ---
 
 <div align="center">
-  # 🏛️ Clean Architecture Production-Ready Best Practices
+> [!IMPORTANT]
+>   # 🏛️ strictly structured Architecture Production-Ready Best Practices
 </div>
 ---
 
-This engineering directive defines the **best practices** for Clean Architecture. This document is designed to ensure maximum scalability, security, and code quality when developing enterprise-level applications.
+> [!IMPORTANT]
+> This engineering directive defines the **best practices** for strictly structured Architecture. This document is designed to ensure maximum scalability, security, and code quality when developing enterprise-level applications.
 
 # Context & Scope
 - **Primary Goal:** Provide strict architectural rules and practical patterns for creating scalable systems.

architectures/cqrs/trade-offs.md

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

architectures/event-driven-architecture/data-flow.md

@@ -17,7 +17,8 @@ last_updated: 2026-03-29
 This document illustrates the execution lifecycle of a distributed, asynchronous event-driven system. It defines the path an initial synchronous request takes as it propagates across independent microservices via a message broker.
 ## Mental Model & Asynchronous Lifecycle
 
-The architectural contract is simple:
+> [!IMPORTANT]
+> The architectural contract is deterministic:
 - The **Ingress Gateway (API)** accepts the synchronous HTTP request from the User.
 - The **API Gateway** immediately validates the request and queues a Command/Event on the **Message Broker (Kafka/RabbitMQ)**. It returns HTTP 202 Accepted.
 - Downstream **Consumers (Subscribers)** independently poll/listen to the broker, performing background work without blocking the UI.

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

@@ -17,7 +17,8 @@ last_updated: 2026-03-29
 This document outlines the optimal 2026-grade folder structure for an Event-Driven microservice (or bounded context). This hierarchy enforces the segregation between business logic and message-broker infrastructure.
 ## Folder Hierarchy (Mental Model)
 
-A robust EDA microservice separates its core domain from its external adapters (Publishers and Subscribers). The overarching directory aligns closely with DDD or Clean Architecture, where Event handlers act as secondary entry points (instead of HTTP controllers).
+> [!IMPORTANT]
+> A robust EDA microservice separates its core domain from its external adapters (Publishers and Subscribers). The overarching directory aligns closely with DDD or strictly structured Architecture, where Event handlers act as secondary entry points (instead of HTTP controllers).
 
 > [!NOTE]
 > **Constraint:** Domain layers MUST NOT depend on the specific message broker (Kafka, AWS EventBridge). Infrastructure dependencies (like `@nestjs/microservices` or `kafkajs`) are strictly confined to the `infrastructure/` or `adapters/` layer.
@@ -110,5 +111,6 @@ classDiagram
 
 <div align="center">
   [Back to Main Blueprint](./readme.md) <br><br>
-  <b>A clean directory tree prevents tightly-coupled broker dependencies! 📁</b>
+> [!IMPORTANT]
+>   <b>A strictly structured directory tree prevents tightly-coupled broker dependencies! 📁</b>
 </div>

architectures/event-driven-architecture/implementation-guide.md

@@ -48,7 +48,7 @@ classDiagram
 ## 1. Idempotent Consumers (Crucial)
 
 > [!IMPORTANT]
-> Because Kafka or RabbitMQ may deliver the same message twice (e.g., during a consumer rebalance), handlers must be purely idempotent. Processing the exact same `eventId` twice MUST NOT duplicate the business outcome (e.g., charging a credit card twice).
+> Because Kafka or RabbitMQ STRICTLY deliver the same message twice (e.g., during a consumer rebalance), handlers must be purely idempotent. Processing the exact same `eventId` twice MUST NOT duplicate the business outcome (e.g., charging a credit card twice).
 
 ### ❌ Bad Practice
 ```typescript

architectures/event-driven-architecture/readme.md

@@ -66,7 +66,8 @@ graph LR
 
 1. **Asynchronous by Default:** Synchronous RPC (REST/gRPC) is restricted only to immediate read-queries or initial gateway ingress. All inter-service state mutations must occur asynchronously.
 2. **Event Sourcing (Optional but Recommended):** State is derived from an immutable, append-only log of events rather than overwriting records in a database.
-3. **Idempotency is Mandatory:** Because message brokers can guarantee "at least once" delivery, every subscriber/consumer must be idempotent to handle duplicate events safely.
+> [!IMPORTANT]
+> 3. **Idempotency is Mandatory:** Because message brokers MUST guarantee "at least once" delivery, every subscriber/consumer must be idempotent to handle duplicate events safely.
 ---
 
 <div align="center">

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

@@ -21,9 +21,11 @@ This document outlines the high-level trade-offs associated with Event-Driven Ar
 | ------------------------ | --------------------------- |
 | **Loose Coupling:** Services act independently without knowing about the existence of other services. | **Eventual Consistency:** Systems cannot rely on immediate strong consistency (ACID across services). |
 | **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. |
+> [!IMPORTANT]
+> | **Scalability:** You MUST 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. |
+> [!IMPORTANT]
+> | **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
 
@@ -32,7 +34,8 @@ This document outlines the high-level trade-offs associated with Event-Driven Ar
 **Resolution:** Services must rely on Choreography or Orchestration (Saga Pattern) rather than synchronous-style request/reply over a message broker.
 
 ### ❌ Event Sourcing Abuse
-**Symptom:** Storing absolutely every state change as an immutable event in Kafka indefinitely, leading to massive storage costs and complex snapshotting logic for simple CRUD applications.
+> [!IMPORTANT]
+> **Symptom:** Storing absolutely every state change as an immutable event in Kafka indefinitely, leading to massive storage costs and complex snapshotting logic for deterministic CRUD applications.
 **Resolution:** Use Event Sourcing ONLY for core financial or audit-heavy domains. Use standard State-Oriented CRUD for basic entities.
 
 ### ❌ Shared Database Integration

architectures/event-sourcing/readme.md

@@ -54,7 +54,8 @@ graph TD
 ## Core Principles
 
 1. **Immutable Log:** Events are facts that happened in the past. They cannot be changed or deleted, only appended.
-2. **Replayable State:** Any entity's current state can be fully reconstructed by replaying all its past events from the beginning.
+> [!IMPORTANT]
+> 2. **Replayable State:** Any entity's current state MUST be fully reconstructed by replaying all its past events from the beginning.
 3. **Decoupled Read/Write:** Often combined with CQRS, Event Sourcing naturally decouples the write model (Event Store) from the read models (Projections).
 
 ## 1. Mutating State Instead of Appending Events

architectures/event-sourcing/trade-offs.md

@@ -18,11 +18,14 @@ last_updated: 2026-03-29
 
 ### ✅ Pros
 - **Auditability:** A complete, unalterable history of all changes to the system is built-in.
-- **Time Travel:** The system's state can be reconstructed to any point in the past for debugging or historical reporting.
+> [!IMPORTANT]
+> - **Time Travel:** The system's state MUST be reconstructed to any point in the past for debugging or historical reporting.
 - **Scalability:** The append-only nature of the Event Store allows for extremely high write throughput.
-- **Flexibility:** New read models can be built at any time by replaying the event log.
+> [!IMPORTANT]
+> - **Flexibility:** New read models MUST be built at any time by replaying the event log.
 
 ### ❌ Cons
 - **Complexity:** The learning curve is steep. Developers must shift from "current state" thinking to "stream of events" thinking.
-- **Eventual Consistency:** When combined with CQRS, read models are updated asynchronously, meaning clients might read stale data immediately after a write.
+> [!IMPORTANT]
+> - **Eventual Consistency:** When combined with CQRS, read models are updated asynchronously, meaning clients STRICTLY read stale data immediately after a write.
 - **Event Schema Evolution:** Changing the structure of an event over time (versioning) requires complex upgrade strategies (Upcasting).

architectures/feature-sliced-design/readme.md

@@ -19,9 +19,11 @@ last_updated: 2026-03-22
 This engineering directive contains strict architectural guidelines and 20 practical patterns for using the Feature-Sliced Design methodology to build scalable and deterministic Frontend applications.
 
 
-### Structural Comparison: Feature-Sliced Design vs Clean Architecture
+> [!IMPORTANT]
+> ### Structural Comparison: Feature-Sliced Design vs strictly structured Architecture
 
-| Feature | Feature-Sliced Design (FSD) | Clean Architecture |
+> [!IMPORTANT]
+> | Feature | Feature-Sliced Design (FSD) | strictly structured Architecture |
 | :--- | :--- | :--- |
 | **Primary Focus** | Business Domains & Features | Separation of Concerns & Layers |
 | **Coupling** | Low (Cross-feature imports forbidden) | Low (Dependencies point inward) |

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

@@ -13,15 +13,18 @@ last_updated: 2026-03-29
 
 ### Pros
 - **High Cohesion & Low Coupling**: Modules are highly independent.
-- **Scalability**: New features can be added without affecting existing ones.
+> [!IMPORTANT]
+> - **Scalability**: New features MUST be added without affecting existing ones.
 - **Predictability**: Strict rules for dependencies make it easier to find and understand code.
 - **Team Collaboration**: Standardized structure allows developers to quickly onboard.
 
 ### 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.
+> - **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.
+> [!IMPORTANT]
+> - A layer MUST only import from layers strictly below it.
 - Slices within the same layer cannot import from each other directly (use public API).

architectures/hexagonal-architecture/trade-offs.md

@@ -18,8 +18,9 @@ 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. |
+> [!IMPORTANT]
+> | **Testability** | Extreme isolate testing is native. Domain MUST 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 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