docs: diagrams

Original diagrams `chain_of_responsibility_overview.puml`, `three_component_architecture.puml`, `version_agnostic_access.puml` were too complicated.
Replacing them in favor several PlantUML diagrams to inform separately about
- the objects involved in the chain of responsibility pattern (overview and detailed)
- the objects involved in the strategy pattern
- the objects involved in the creation of the chain of responsibility
- the sequence through the chain of responsibility (overview and detailed)
- Add the rendered svg to the documentation

Author: LittleCoinCoin

docs/articles/devs/architecture/ChainOfResponsibilityPattern.md

@@ -13,6 +13,10 @@ This article is about:
 
 The Chain of Responsibility pattern is the central architectural feature of Hatch-Validator, implemented consistently across three major component types. This pattern enables extensible functionality by allowing new components to inherit and modify only the changed logic from previous versions, creating a maintainable and scalable system.
 
+![Chain of Responsibility Pattern Overview](../../../resources/images/chain_of_responsibility_simplified.svg)
+
+*The diagram above shows the simplified Chain of Responsibility pattern structure across all three component types: Validators, Package Accessors, and Registry Accessors.*
+
 ### Core Principles
 
 **Delegation Over Inheritance**: Components delegate unchanged concerns to previous versions rather than using traditional class inheritance.
@@ -51,6 +55,10 @@ Validators delegate to the chain for validation concerns that remain unchanged:
 - **No new requirements**: No new validation requirements introduced
 - **Previous implementation sufficient**: Previous version's strategy meets current needs
 
+![Chain Delegation Sequence](../../../resources/images/chain_of_responsibility_delegation_sequence.svg)
+
+*The diagram above shows the detailed delegation flow through the validator chain, demonstrating how components check if they can handle a request and delegate to the next component when needed.*
+
 ## Universal Implementation Pattern
 
 ### Three Component Types
@@ -74,7 +82,7 @@ The Chain of Responsibility pattern is implemented identically across three comp
 
 ### Abstract Base Classes
 
-All component types follow the same abstract base class pattern:
+All component types follow the same abstract base class pattern (replace `ComponentBase` with the actual base class name for each component type)
 
 ```python
 # Universal pattern implemented by all three component types
@@ -102,7 +110,7 @@ class ComponentBase(ABC):
 
 ### Factory Pattern Integration
 
-All component types use identical factory patterns for chain construction:
+All component types use identical factory patterns for chain construction (replace `ComponentFactory` and `ComponentBase` with the actual factory and base class names for each component type)
 
 ```python
 # Universal factory pattern used by all three component types
@@ -254,6 +262,10 @@ components[1].set_next(components[2])  # v1.2.0 → v1.1.0
 
 Validators implement the Strategy Pattern alongside Chain of Responsibility to encapsulate validation algorithms. This dual-pattern architecture provides fine-grained control over which validation concerns use strategy composition versus chain delegation.
 
+![Strategy Pattern Implementation](../../../resources/images/strategy_pattern_focus.svg)
+
+*The diagram above shows how validation strategies are organized and implemented within the validator architecture, demonstrating the interface hierarchy and concrete strategy implementations.*
+
 ### Strategy Interface Hierarchy
 
 Located in `hatch_validator/core/validation_strategy.py`:

docs/articles/devs/architecture/ComponentTypes.md

@@ -11,6 +11,10 @@ This article is about:
 
 Hatch-Validator implements the Chain of Responsibility pattern across three distinct component types, each serving a specific purpose in the validation and data access ecosystem. These components work together to provide comprehensive, version-agnostic functionality for package management and validation.
 
+![Component Architecture Overview](../../../resources/images/component_architecture_simplified.svg)
+
+*The diagram above shows the three-component architecture with unified Chain of Responsibility patterns across Validators, Package Accessors, and Registry Accessors.*
+
 ## Validators
 
 ### Purpose and Scope
@@ -259,6 +263,10 @@ class DependencyValidation:
 
 Factory classes coordinate component creation:
 
+![Factory Pattern Implementation](../../../resources/images/factory_pattern_focus.svg)
+
+*The diagram above shows how factory classes automatically discover components, handle version precedence, and build chains with proper linking across all three component types.*
+
 ```python
 # Coordinated factory usage
 def create_validation_system(metadata: Dict[str, Any], registry_data: Dict[str, Any]):

docs/articles/users/GettingStarted.md

@@ -34,6 +34,10 @@ The validator uses the Chain of Responsibility design pattern to handle differen
 3. Delegates requests through the chain
 4. Returns results using a consistent interface
 
+![Version-Agnostic Access Flow](../../resources/images/version_agnostic_access_simplified.svg)
+
+*The diagram above shows how client requests are handled through version-agnostic access, where factories create appropriate chains and components delegate to maintain consistent interfaces.*
+
 ## Basic Package Validation
 
 ### Simple Validation Example

docs/articles/users/data_access/VersionAgnosticAccess.md

@@ -54,6 +54,10 @@ The system automatically detects schema versions from metadata and creates appro
 
 Each component in the chain implements version-specific logic while delegating unchanged concerns:
 
+![Data Access Patterns](../../../resources/images/data_access_patterns_focus.svg)
+
+*The diagram above shows how data access flows through the accessor chain, with each accessor handling its version-specific concerns and delegating unchanged operations to previous versions.*
+
 **Package Accessors Example:**
 - **v1.2.1 Accessor**: Handles dual entry point metadata → delegates dependency access to v1.2.0
 - **v1.2.0 Accessor**: Handles unified dependency structure → delegates basic fields to v1.1.0

docs/articles/users/validation/PackageValidation.md

@@ -41,6 +41,12 @@ The validation process follows these steps:
 4. **Validation Execution**: Execute validation through the chain with delegation
 5. **Result Aggregation**: Collect and return comprehensive validation results
 
+The following diagram illustrates how the validation execution integrates both Chain of Responsibility (for delegation) and Strategy Pattern (for validation algorithms):
+
+![Validation Execution Flow](../../../resources/images/validation_execution_focus.svg)
+
+*The diagram above shows how validation requests flow through the validator chain, with validators using strategies for changed concerns and delegating unchanged concerns to previous versions.*
+
 ### Validation Categories
 
 The validator performs comprehensive validation across multiple categories:

docs/resources/diagrams/chain_of_responsibility_delegation_sequence.puml

@@ -0,0 +1,62 @@
+@startuml Chain Delegation Focus
+!theme plain
+skinparam backgroundColor white
+skinparam participantBackgroundColor white
+skinparam participantBorderColor black
+skinparam arrowColor black
+
+title Chain of Responsibility - Delegation Flow
+
+participant "Client" as C
+participant "V1.2.1 Validator" as V121
+participant "V1.2.0 Validator" as V120
+participant "V1.1.0 Validator" as V110
+
+== Validation Request ==
+C -> V121 : validate(v1.2.1_metadata)
+activate V121
+
+note over V121 : **Can Handle Check**\nif schema_version == "1.2.1":\n  return True
+
+V121 -> V121 : validate_entry_points()\n[Strategy Pattern]
+V121 -> V121 : validate_tools()\n[Strategy Pattern]
+
+note over V121 : **Delegation Decision**\nFor dependencies validation:\nDelegate to v1.2.0
+
+V121 -> V120 : validate_dependencies(metadata)
+activate V120
+
+note over V120 : **Can Handle Check**\nif schema_version in ["1.2.0", "1.2.1"]:\n  return True
+
+V120 -> V120 : validate_dependencies()\n[Strategy Pattern]
+
+note over V120 : **Delegation Decision**\nFor schema validation:\nDelegate to v1.1.0
+
+V120 -> V110 : validate_schema(metadata)
+activate V110
+
+note over V110 : **Terminal Handler**\nImplements all base validation\nNo further delegation
+
+V110 -> V110 : validate_schema()\n[Strategy Pattern]
+V110 --> V120 : schema_result
+deactivate V110
+
+V120 --> V121 : dependency_result
+deactivate V120
+
+V121 --> C : combined_result
+deactivate V121
+
+== Alternative Flow: Direct Handling ==
+C -> V110 : validate(v1.1.0_metadata)
+activate V110
+
+note over V110 : **Can Handle Check**\nif schema_version == "1.1.0":\n  return True
+
+V110 -> V110 : validate_all_concerns()\n[All Strategies]
+V110 --> C : complete_result
+deactivate V110
+
+note over C, V110 : **Chain Benefits:**\n• **Automatic Routing**: Requests go to appropriate handler\n• **Code Reuse**: Unchanged logic is delegated\n• **Extensibility**: New versions extend without modification\n• **Fallback**: Older versions handle their specific cases
+
+@enduml