chore: sync develop into master

docs/audit-stores/community/couchbase-audit-store.md

@@ -8,7 +8,7 @@ import TabItem from '@theme/TabItem';
 
 # Couchbase Audit Store
 
-The Couchbase audit store (`CouchbaseSyncAuditStore`) enables Flamingock to record execution history and ensure safe coordination across distributed deployments using Couchbase as the storage backend.
+The Couchbase audit store (`CouchbaseAuditStore`) enables Flamingock to record execution history and ensure safe coordination across distributed deployments using Couchbase as the storage backend.
 
 > For a conceptual explanation of the audit store vs target systems, see [Audit store vs target system](../../get-started/audit-store-vs-target-system.md).
 
@@ -78,6 +78,8 @@ These configurations can be customized via `.withXXX()` methods with **no global
 | `Audit Repository Name` | `.withAuditRepositoryName(name)` | `flamingockAuditLog` | Collection name for audit entries             |
 | `Lock Repository Name`  | `.withLockRepositoryName(name)`  | `flamingockLock`     | Collection name for distributed locks         |
 
+The default names are suitable only when the Couchbase bucket is dedicated to one application. When applications share a bucket or cluster, configure unique audit and lock collection names for each application. Separate buckets, clusters, and connections are not required.
+
 ⚠️ **Warning**: Ensure your Couchbase user has permissions to create collections if `autoCreate` is enabled.
 
 ## Configuration example
@@ -88,9 +90,11 @@ Here's a comprehensive example showing the configuration:
 // Create a Couchbase Target System
 CouchbaseTargetSystem couchbaseTargetSystem = new CouchbaseTargetSystem("couchbase", cluster, "bucketName");
 // Audit store configuration (mandatory via constructor)
-var auditStore = CouchbaseSyncAuditStore.from(couchbaseTargetSystem)
-    .withScopeName("custom-scope")     // Optional configuration
-    .withAutoCreate(true);             // Optional configuration
+var auditStore = CouchbaseAuditStore.from(couchbaseTargetSystem)
+    .withScopeName("custom-scope")                 // Optional configuration
+    .withAuditRepositoryName("ordersServiceAuditLog")
+    .withLockRepositoryName("ordersServiceLock")
+    .withAutoCreate(true);                          // Optional configuration
 
 // Register with Flamingock
 Flamingock.builder()

docs/audit-stores/community/dynamodb-audit-store.md

@@ -8,7 +8,7 @@ import TabItem from '@theme/TabItem';
 
 # DynamoDB Audit Store
 
-The DynamoDB audit store (`DynamoSyncAuditStore`) enables Flamingock to record execution history and ensure safe coordination across distributed deployments using Amazon DynamoDB as the storage backend.
+The DynamoDB audit store (`DynamoDBAuditStore`) enables Flamingock to record execution history and ensure safe coordination across distributed deployments using Amazon DynamoDB as the storage backend.
 
 > For a conceptual explanation of the audit store vs target systems, see [Audit store vs target system](../../get-started/audit-store-vs-target-system.md).
 
@@ -56,7 +56,7 @@ This ensures that both components point to the **same external DynamoDB instance
 - The **Target System** applies your business changes.
 - The **Audit Store** stores the execution history associated with those changes.
 
-Internally, the Audit Store takes the Target System’s connection settings (DynamoClient) and creates its **own dedicated access handle**, keeping audit operations isolated while still referring to the same physical system.
+Internally, the Audit Store reuses the `DynamoDbClient` supplied by the Target System while retaining responsibility for audit operations and execution history.
 
 > For a full conceptual explanation of this relationship, see
 > **[Target Systems vs Audit Store](../../get-started/audit-store-vs-target-system.md)**.
@@ -79,6 +79,8 @@ These configurations can be customized via `.withXXX()` methods with **no global
 | `Audit Repository Name` | `.withAuditRepositoryName(name)` | `flamingockAuditLog` | Table name for audit entries                 |
 | `Lock Repository Name`  | `.withLockRepositoryName(name)`  | `flamingockLock`     | Table name for distributed locks             |
 
+The default names are suitable only when the DynamoDB backend is dedicated to one application. When applications share an AWS account or DynamoDB service, configure unique audit and lock table names for each application. Separate AWS accounts, services, and connections are not required.
+
 ⚠️ **Warning**: Adjust capacity units based on your workload. Under-provisioning may cause throttling.
 Consider using **ON_DEMAND** billing mode for unpredictable workloads.
 
@@ -87,10 +89,12 @@ Consider using **ON_DEMAND** billing mode for unpredictable workloads.
 Here's a comprehensive example showing the configuration:
 
 ```java
-// Create a DynamodDB Target System
-DynamodDBTargetSystem dynamoDBTargetSystem = new DynamodDBTargetSystem("dynamodb", dynamoDbClient);
+// Create a DynamoDB Target System
+DynamoDBTargetSystem dynamoDBTargetSystem = new DynamoDBTargetSystem("dynamodb", dynamoDbClient);
 // Audit store configuration (mandatory via constructor)
-var auditStore = DynamoSyncAuditStore.from(dynamoDBTargetSystem)
+var auditStore = DynamoDBAuditStore.from(dynamoDBTargetSystem)
+    .withAuditRepositoryName("ordersServiceAuditLog")
+    .withLockRepositoryName("ordersServiceLock")
     .withReadCapacityUnits(10)     // Optional configuration
     .withWriteCapacityUnits(10);   // Optional configuration
 

docs/audit-stores/community/mongodb-audit-store.md

@@ -80,7 +80,7 @@ These configurations can be customized via `.withXXX()` methods with **no global
 | `Audit Repository Name` | `.withAuditRepositoryName(name)` | `flamingockAuditLog`    | Collection name for audit entries     |
 | `Lock Repository Name`  | `.withLockRepositoryName(name)`  | `flamingockLock`        | Collection name for distributed locks |
 
-**Important**: These default values are optimized for maximum consistency and should ideally be left unchanged. Override them only for testing purposes or exceptional cases.
+**Important**: These default values are optimized for maximum consistency and should ideally be left unchanged. Override them only for testing purposes or exceptional cases. Repository names are the exception: when applications share a database or cluster, configure unique audit and lock collection names for each application. Separate databases, clusters, and connections are not required.
 
 ## Configuration example
 
@@ -91,8 +91,10 @@ Here's a comprehensive example showing the configuration:
 MongoDBSyncTargetSystem mongoDbSyncTargetSystem = new MongoDBSyncTargetSystem("mongodb", mongoClient, auditDatabase);
 // Audit store configuration (mandatory via constructor)
 var auditStore = MongoDBSyncAuditStore.from(mongoDbSyncTargetSystem)
-    .withWriteConcern(WriteConcern.W1)         // Optional configuration
-    .withReadPreference(ReadPreference.secondary());  // Optional configuration
+    .withAuditRepositoryName("ordersServiceAuditLog")
+    .withLockRepositoryName("ordersServiceLock")
+    .withWriteConcern(WriteConcern.W1)                 // Optional configuration
+    .withReadPreference(ReadPreference.secondary());   // Optional configuration
 
 // Register with Flamingock
 Flamingock.builder()

docs/audit-stores/community/sql-audit-store.md

@@ -104,7 +104,7 @@ These configurations can be customized via `.withXXX()` methods with **no global
 | `Audit Repository Name` | `.withAuditRepositoryName(name)` | `flamingockAuditLog` | Table name for audit entries          |
 | `Lock Repository Name`  | `.withLockRepositoryName(name)`  | `flamingockLock`     | Table name for distributed locks      |
 
-**Important**: These default values are optimized for maximum consistency and should ideally be left unchanged. Override them only for testing purposes or exceptional cases.
+**Important**: These default values are optimized for maximum consistency and should ideally be left unchanged. Override them only for testing purposes or exceptional cases. Repository names are the exception: when applications share a database or server, configure unique audit and lock table names for each application. Separate databases and connections are not required.
 
 ## Configuration example
 
@@ -114,10 +114,10 @@ Here's a comprehensive example showing the configuration:
 // Create a SQL Target System
 SqlTargetSystem sqlTargetSystem = new SqlTargetSystem("sql", dataSource);
 // Audit store configuration (mandatory via constructor)
-var auditStore = SqlAuditStore.from(couchbaseTargetSystem)
+var auditStore = SqlAuditStore.from(sqlTargetSystem)
     .withAutoCreate(true)                          // Optional configuration
-    .withAuditRepositoryName("custom_audit_log")   // Optional configuration
-    .withLockRepositoryName("custom_lock_table");  // Optional configuration
+    .withAuditRepositoryName("ordersServiceAuditLog")
+    .withLockRepositoryName("ordersServiceLock");
 
 // Register with Flamingock
 Flamingock.builder()
@@ -146,7 +146,9 @@ config.setDriverClassName("org.postgresql.Driver");
 
 DataSource dataSource = new HikariDataSource(config);
 SqlTargetSystem sqlTargetSystem = new SqlTargetSystem("sql", dataSource);
-var auditStore = SqlAuditStore.from(sqlTargetSystem);
+var auditStore = SqlAuditStore.from(sqlTargetSystem)
+    .withAuditRepositoryName("ordersServiceAuditLog")
+    .withLockRepositoryName("ordersServiceLock");
 ```
 
 ### MySQL
@@ -160,15 +162,17 @@ config.setDriverClassName("com.mysql.cj.jdbc.Driver");
 
 DataSource dataSource = new HikariDataSource(config);
 SqlTargetSystem sqlTargetSystem = new SqlTargetSystem("sql", dataSource);
-var auditStore = SqlAuditStore.from(sqlTargetSystem);
+var auditStore = SqlAuditStore.from(sqlTargetSystem)
+    .withAuditRepositoryName("ordersServiceAuditLog")
+    .withLockRepositoryName("ordersServiceLock");
 ```
 
 ## Schema management
 
-When `autoCreate` is enabled (default), Flamingock automatically creates the required tables:
+When `autoCreate` is enabled (default), Flamingock automatically creates the required tables. Use unique table names for every application when the database is shared:
 
-- **Audit table** (default: `flamingockAuditLog`): Stores execution history
-- **Lock table** (default: `flamingockLock`): Manages distributed locking
+- **Audit table** (for example, `ordersServiceAuditLog`): Stores execution history
+- **Lock table** (for example, `ordersServiceLock`): Manages distributed locking
 
 The SQL schemas are automatically optimized for each supported database dialect.
 

docs/audit-stores/introduction.md

@@ -38,8 +38,16 @@ Alternatively, you can configure your own audit store using one of the supported
 - [Couchbase audit store](./community/couchbase-audit-store.md)
 - [SQL audit store](./community/sql-audit-store.md)
 
+### Repository isolation
 
-### Registering the community audit store
+Multiple applications can share the same physical Community Audit Store backend, such as a database, cluster, or service. Each application **must** use its own audit and lock repositories so its execution history and distributed locks remain isolated.
+
+A repository is provider-specific metadata storage: tables for SQL and DynamoDB, and collections for MongoDB and Couchbase. It does not require separate databases, clusters, or connections. The default repository names are appropriate only when the backend is dedicated to one application; configure unique application-specific names when the backend is shared.
+
+This configuration applies only to Community Audit Stores. Flamingock Cloud manages its audit store and repositories for you.
+
+
+### Registering the Community audit store
 
 <Tabs groupId="registration">
   <TabItem value="builder" label="Flamingock Builder" default>
@@ -54,7 +62,9 @@ public class App {
     var targetSystem = new MongoDBSyncTargetSystem("mongodb-ts", mongoClient, "dbName");
 
     // Create your audit store connection
-    var auditStore = MongoDBSyncAuditStore.from(targetSystem);
+    var auditStore = MongoDBSyncAuditStore.from(targetSystem)
+        .withAuditRepositoryName("ordersServiceAuditLog")
+        .withLockRepositoryName("ordersServiceLock");
 
     // Register with Flamingock
     Flamingock.builder()
@@ -73,7 +83,9 @@ For Spring Boot applications, register audit stores as beans:
 ```java
 @Bean
 public AuditStore auditStore(MongoDBSyncTargetSystem mongoDBSyncTargetSystem) {
-    return MongoDBSyncAuditStore.from(mongoDBSyncTargetSystem);
+    return MongoDBSyncAuditStore.from(mongoDBSyncTargetSystem)
+        .withAuditRepositoryName("ordersServiceAuditLog")
+        .withLockRepositoryName("ordersServiceLock");
 }
 
 // Flamingock Spring Boot auto-configuration will pick this up automatically
@@ -85,5 +97,3 @@ For more details, see [Spring Boot Integration](../frameworks/springboot-integra
 
   </TabItem>
 </Tabs>
-
-

docs/cli/cli.md

@@ -119,8 +119,12 @@ flamingock execute apply --jar ./my-app.jar -J -Xmx1g -- --spring.profiles.activ
 
 List audit entries from the change history.
 
+:::note
+Enterprise feature. Requires Flamingock Cloud or Self-Hosted Edition.
+:::
+
 | Option       | Short | Required | Description                                                                 |
-|--------------|-------|----------|-----------------------------------------------------------------------------|
+|--------------|-------|----------|-------------------------------------------------------------------------------|
 | `--jar`      | `-j`  | Yes      | Path to the application JAR                                                 |
 | `--history`  |       | No       | Show full chronological history instead of snapshot                         |
 | `--since`    |       | No       | Filter entries since date (ISO-8601: `yyyy-MM-dd` or `yyyy-MM-ddTHH:mm:ss`) |

docs/flamingock-library-config/events.md

@@ -237,7 +237,7 @@ class StageCompletedListener : ApplicationListener<SpringStageCompletedEvent> {
   </TabItem>
 </Tabs>
 
-## Event payload reference <VersionBadge version="1.4.0" />
+## Event payload reference <VersionBadge version="1.4.0" /> {#event-payload-reference}
 
 The pipeline-level events carry `ExecuteResponseData`; the stage-level events carry `StageResult`. The fields a typical listener reads are:
 

docs/get-started/dependency-requirements.md

@@ -0,0 +1,39 @@
+---
+title: Dependency requirements and compatibility
+sidebar_position: 20
+---
+
+# Dependency requirements and compatibility
+
+This page summarizes the external dependencies commonly needed for Flamingock features. For detailed setup examples, follow the links in the table.
+
+## Application-owned dependencies
+
+These are verified minimums or compatibility notes, not a promise that every patch release works.
+
+| Feature | Required dependency | Minimum | Details |
+|---|---|---|---|
+| [MongoDB Sync target system](../target-systems/mongodb-target-system.md) | MongoDB Java sync driver | `4.0.0+` | The application supplies the driver; see the linked target-system setup. |
+| [DynamoDB target system](../target-systems/dynamodb-target-system.md) | AWS SDK DynamoDB Enhanced | `2.25.0+` | The application supplies the SDK; see the linked target-system setup. |
+| [Couchbase target system](../target-systems/couchbase-target-system.md) | Couchbase Java Client | `3.6.0+` | The application supplies the client; see the linked target-system setup. |
+| [MongoDB Spring Data target system](../target-systems/mongodb-springdata-target-system.md) | Spring Data MongoDB | `3.1.x–4.x` | Use a compatible Spring Boot/driver release train; see the linked target-system setup. |
+| [SQL target system](../target-systems/sql-target-system.md) | SQL JDBC driver and `DataSource` | Application-supplied | See the linked target-system setup. |
+| [GraalVM support](../frameworks/graalvm.md) | GraalVM/native-image tooling | Only when the feature is used | See the linked framework setup. |
+
+## If your application already manages these libraries
+
+This section applies only when your application already manages Jackson or an SLF4J provider. These are compatibility notes, not dependencies to add for Flamingock.
+
+| Library | Compatibility guidance |
+|---|---|
+| Jackson | Keep `jackson-core`, `jackson-databind`, and `jackson-annotations` aligned. The conservative verified floor for the full Maven/KAPT consumer path is `2.16.0`; `2.15.0` fails KAPT. This is not an absolute minimum for every integration. |
+| SLF4J provider | Optional for execution. If selected, use a 2.x provider. When no compatible 2.x provider exists, SLF4J 2.x ignores a 1.7.x provider and logging falls back to NOP. |
+
+## Related documentation
+
+- [Quick start](./quick-start.md)
+- [Gradle plugin](./gradle-plugin.md)
+- [Execution report logging](../flamingock-library-config/execution-report.md)
+- [Target systems](../target-systems/introduction.md), including [MongoDB Sync](../target-systems/mongodb-target-system.md), [MongoDB Spring Data](../target-systems/mongodb-springdata-target-system.md), [DynamoDB](../target-systems/dynamodb-target-system.md), [Couchbase](../target-systems/couchbase-target-system.md), and [SQL](../target-systems/sql-target-system.md)
+- [Audit stores](../audit-stores/introduction.md), including [MongoDB](../audit-stores/community/mongodb-audit-store.md), [DynamoDB](../audit-stores/community/dynamodb-audit-store.md), [Couchbase](../audit-stores/community/couchbase-audit-store.md), and [SQL](../audit-stores/community/sql-audit-store.md)
+- Framework docs: [Spring Boot integration](../frameworks/springboot-integration/introduction.md) and [GraalVM support](../frameworks/graalvm.md)

docs/get-started/gradle-plugin.md

@@ -59,6 +59,7 @@ This regenerates Flamingock's per-module metadata in the new incremental format.
 - **Gradle** 7.4+
 - **Java** 8+
 
+See [Dependency requirements and compatibility](./dependency-requirements.md) for application-owned dependencies and compatibility notes.
 
 ## Quick start
 

docs/get-started/quick-start.md

@@ -79,7 +79,7 @@ flamingock {
   </TabItem>
 </Tabs>
 
-
+See [Dependency requirements and compatibility](./dependency-requirements.md) for application-owned dependencies and compatibility notes.
 
 ## 2. Create target systems
 
@@ -271,4 +271,4 @@ Note:    [Flamingock] Final processing round detected - skipping execution.
 
 - [Spring Boot integration](../frameworks/springboot-integration/introduction.md)
 - [Configuration options](../flamingock-library-config/setup-and-stages.md)
-- [Recovery and safety](../safety-and-recovery/recovery-strategies.md)
+- [Recovery and safety](../safety-and-recovery/recovery-strategies.md)

docs/overview.md

@@ -13,7 +13,7 @@ It applies **versioned, auditable changes** to the external systems your applica
 Unlike infrastructure-as-code tools, Flamingock runs **inside your application** (or via the **CLI**).
 It ensures these systems evolve **safely, consistently, and in sync with your code at runtime**.
 
-👉 For a deeper explanation, see the [Introduction](./get-started/Introduction)
+👉 For a deeper explanation, see the [Introduction](./get-started/introduction)
 
 ---
 

docs/resources/coming-from-mongock.md

@@ -350,13 +350,13 @@ After the first Flamingock run against a copy of your Mongock audit history, ver
 Instead of inspecting the store manually, use the Flamingock CLI against your application JAR as the source of truth:
 
 ```bash
-# Snapshot of the current audit state
+# Snapshot of the current audit state (Enterprise feature — Cloud or Self-Hosted Edition)
 flamingock audit list --jar ./my-app.jar
 
-# Optional: full audit history
+# Optional: full audit history (Enterprise feature)
 flamingock audit list --jar ./my-app.jar --history
 
-# Optional: detect inconsistent states that require attention
+# Detect inconsistent states that require attention
 flamingock issue list --jar ./my-app.jar
 ```
 
@@ -384,8 +384,8 @@ Successful migration signal: legacy Mongock changes appear as executed, with no
 Practical verification flow:
 
 1. Run the application once with Flamingock enabled.
-2. Run `flamingock audit list --jar ./my-app.jar`.
-3. Confirm legacy Mongock changes that had already executed appear in the output and were not re-executed.
+2. Run `flamingock audit list --jar ./my-app.jar` (Enterprise) or check application logs / the target system directly.
+3. Confirm legacy Mongock changes that had already executed appear as executed and were not re-executed.
 4. Confirm previously pending legacy changes now appear as executed.
 5. Run `flamingock issue list --jar ./my-app.jar` and confirm no inconsistent audit states.