add diagram code to rules and audit

concepts/framework/rules.md

@@ -39,11 +39,32 @@ The center of the rule system is the `Rule`. It is realized as a variant of the
 
 As well as a Specification class, a Rule class represents a condition to fulfill. It implements the `match(RuleScope $scope)` function to validate user defined values against a runtime state. See the following object diagram for a better understanding:
 
-![](../../assets/rule-objects.png)
+```mermaid
+classDiagram
+    root-OrRule .. lineItemCount - LineItemsInCartCountRule
+    root-OrRule .. cartPrice - GoodsPriceRule
+    class root-OrRule{
+        rules=[lineItemCount, cartPrice]
+    }
+    class lineItemCount - LineItemsInCartCountRule{
+      operator=">="
+      count="40"
+    }
+    class cartPrice - GoodsPriceRule{
+      operator=">="
+      count="500"
+    }
+```
 
 This will result in the following call order:
 
-![](../../assets/rule-sequence.png)
+```mermaid
+sequenceDiagram
+    root-->>lineItemCount: match()?
+    lineItemCount-->>root: false
+    root-->>cartPrice: match()?
+    cartPrice-->>root: false
+```
 
 As you can see, a single rule can either contain user defined values or other user defined rules. These are Container rules. The rule system here bears some resemblance to the [SearchCriteria](../../guides/plugins/plugins/framework/data-handling/reading-data#Filtering), although independent. A Search Criteria is the representation of a query that gets translated and executed through the storage engine. The rule matches in-memory in PHP and does not access the underlying storage.
 

products/extensions/b2b-suite/guides/core/audit-log.md

@@ -14,7 +14,32 @@ nav:
 The B2B Suite provides a general audit log that can be implemented in every component.
 The audit log component can save different log types and author information like first name, last name, and email. It provides a one-to-many association index. The database structure is described in the graphic below:
 
-![image](../../../../../assets/auditlog-structure.svg)
+```mermaid
+classDiagram 
+    b2b_audit_log_index o--> b2b_audit_log : n to 1
+    b2b_audit_log o--> b2b_audit_log_author : n to 1
+    class b2b_audit_log_index{
+        id 
+        audit_log_id 
+        reference_table 
+        reference_id
+    }
+    class b2b_audit_log{
+        id 
+        log_value 
+        log_type 
+        event_date 
+        author_hash
+    }
+    class b2b_audit_log_author{
+        hash
+        salutation
+        title
+        firstname
+        lastname
+        email
+    }
+```
 
 As you can see, the database structure is very flat. In the `b2b_audit_log` table, we save a log type and a serialized *AuditLogValueEntity*.
 All required author information is saved in the `b2b_audit_log_author` table.