Docs/Self-hosting docs change with AWS EC2 and GCP

.github/workflows/build_pull_request.yml

@@ -17,7 +17,7 @@ permissions:
 jobs:
   # JOB to run change detection
   changes:
-    runs-on: blacksmith-4vcpu-ubuntu-2404
+    runs-on: ubuntu-latest
     # Required permissions
     permissions:
       pull-requests: read
@@ -42,7 +42,7 @@ jobs:
   cli:
     needs: changes
     if: ${{ needs.changes.outputs.cli == 'true' }}
-    runs-on: blacksmith-4vcpu-ubuntu-2404
+    runs-on: ubuntu-latest
 
     steps:
       - uses: actions/checkout@v3
@@ -76,7 +76,7 @@ jobs:
   client:
     needs: changes
     if: ${{ needs.changes.outputs.client == 'true' }}
-    runs-on: blacksmith-4vcpu-ubuntu-2404
+    runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v3
         with:
@@ -105,7 +105,7 @@ jobs:
   server:
     needs: changes
     if: ${{ needs.changes.outputs.server == 'true' }}
-    runs-on: blacksmith-4vcpu-ubuntu-2404
+    runs-on: ubuntu-latest
 
     steps:
     - uses: actions/checkout@v3

.github/workflows/build_push.yml

@@ -16,7 +16,7 @@ permissions:
 
 jobs:
   cli:
-    runs-on: blacksmith-4vcpu-ubuntu-2404
+    runs-on: ubuntu-latest
 
     steps:
       - uses: actions/checkout@v3
@@ -48,7 +48,7 @@ jobs:
         run: ../gradlew build jacocoTestReport sonar --quiet
 
   client:
-    runs-on: blacksmith-4vcpu-ubuntu-2404
+    runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v3
         with:
@@ -75,7 +75,7 @@ jobs:
           projectBaseDir: client/
 
   server:
-    runs-on: blacksmith-4vcpu-ubuntu-2404
+    runs-on: ubuntu-latest
 
     steps:
     - uses: actions/checkout@v3

.junie/guidelines.md

@@ -366,14 +366,4 @@ Access the application at http://localhost:8080
   - Formatting rules:
     - Break each chained step onto its own line when there are 3+ operations or line length would exceed limits
     - Keep declarative chains (queries, reactive pipelines) as one logical block; prefer one operation per line
-- Avoid chaining when side effects are involved or intermediate values deserve names for clarity/debugging
-
-## Working with Tasks
-
-Follow these guidelines when working with the `docs/tasks.md` checklist:
-
-1. **Mark Completion**: Mark tasks as `[x]` as soon as they are completed.
-2. **Task Modification**: Keep existing phases intact. If additional steps are identified during development, add them as new tasks within the appropriate phase.
-3. **Traceability**: Ensure every new or modified task remains linked to both a requirement in `docs/requirements.md` and a plan item in `docs/plan.md`.
-4. **Consistency**: Maintain the existing formatting style for tasks, including headings, indentation, and linking format.
-5. **Periodic Review**: Regularly sync the task list with the actual progress of the development to ensure it remains an accurate source of truth.
+    - Avoid chaining when side effects are involved or intermediate values deserve names for clarity/debugging

AGENTS.md

@@ -357,86 +357,20 @@ it('should render button', () => {
 
 ### E2E Tests (Playwright)
 
--   Location: `test/playwright/`
--   **Fixtures Pattern**: Use independent fixtures combined with `mergeTests` (following Liferay pattern)
--   **Fixtures Location**: `test/playwright/fixtures/`
--   **Available Fixtures**:
-    -   `loginTest()` - Provides `authenticatedPage` (function, call with `()`)
-    -   `projectTest` - Provides `project` (auto-creates and cleans up)
-    -   `workflowTest` - Provides `workflow` (requires `project` when merged)
-
-#### Fixtures Pattern
-
-**The `use` Hook**: Playwright fixtures use a `use` callback that:
-1. **Setup** (before `use`) - Creates resources
-2. **Test Execution** (during `use`) - Your test runs
-3. **Cleanup** (after `use`) - Automatically cleans up resources
+-   Location: `tests/e2e/`
+-   Use helpers from `tests/e2e/helpers/auth.ts` for authentication
+-   Pattern:
 
 ```typescript
-// Example fixture structure
-export const projectTest = base.extend({
-    project: async ({page}, use) => {
-        // SETUP: Create project
-        const project = await createProject(page);
-
-        // GIVE TO TEST: Your test runs here
-        await use(project);
-
-        // CLEANUP: Delete project (runs after test)
-        await projectsPage.deleteProject(project.id);
-    },
-});
-```
+import {test, expect} from '@playwright/test';
+import {login} from './helpers/auth';
 
-**Using Fixtures with `mergeTests`**:
-
-```typescript
-import {expect, mergeTests} from '@playwright/test';
-import {loginTest, projectTest, workflowTest} from '../../fixtures';
-
-// Combine fixtures at the top of your test file
-export const test = mergeTests(loginTest(), projectTest, workflowTest);
-
-test.describe('My Tests', () => {
-    test('my test', async ({authenticatedPage, project, workflow}) => {
-        // All fixtures are available:
-        // - authenticatedPage (from loginTest)
-        // - project (from projectTest)
-        // - workflow (from workflowTest)
-
-        await authenticatedPage.goto(`/projects/${project.id}/workflows/${workflow.workflowId}`);
-        // Test logic here
-        // Fixtures automatically clean up after test
-    });
+test('should login', async ({page}) => {
+    await login(page, 'user@example.com', 'password');
+    await expect(page).toHaveURL('/');
 });
 ```
 
-**Common Patterns**:
-
-```typescript
-// Test needs only authentication
-export const test = mergeTests(loginTest());
-
-// Test needs project
-export const test = mergeTests(loginTest(), projectTest);
-
-// Test needs everything
-export const test = mergeTests(loginTest(), projectTest, workflowTest);
-```
-
-**Key Principles**:
--   Fixtures are **independent** - don't extend each other
--   Use `mergeTests` in test files to combine fixtures
--   `loginTest()` is a function - call it with `()`
--   Fixtures automatically clean up resources after tests
--   Each fixture provides specific fixtures (see table below)
-
-| Fixture | Provides | Requires |
-|---------|-----------|----------|
-| `loginTest()` | `authenticatedPage` | Nothing |
-| `projectTest` | `project` | `page` (auto-authenticated) |
-| `workflowTest` | `workflow` | `page` + `project` (when merged) |
-
 ## Common Utilities
 
 ### `twMerge()` - Class Name Utility

CLAUDE.md

@@ -75,15 +75,15 @@ docker compose -f docker-compose.dev.server.yml up -d
 ## Architecture Overview
 
 ### Core Technology Stack
-- **Backend**: Java 25 with Spring Boot 4.0.2
-- **Frontend**: React 19.2 with TypeScript 5.9, Vite 7.3, TailwindCSS 3.4
+- **Backend**: Java 25 with Spring Boot 3.5.7
+- **Frontend**: React 19.2 with TypeScript 5.9, Vite 7.2, TailwindCSS 3.4
 - **Database**: PostgreSQL 15+ with Liquibase migrations
 - **Message Broker**: Memory(default), Redis, RabbitMQ, Kafka, JMS, AMQP, AWS SQS
 - **Build System**: Gradle 8+ with Kotlin DSL
 - **Code Execution**: GraalVM Polyglot 25.0.1 (Java, JavaScript, Python, Ruby)
 - **Testing**: JUnit 5, Vitest 4, Testcontainers
 - **Node.js**: Version 20.19+ required for client development
-- **Additional Tools**: MapStruct 1.6.3, Jackson 2.19.2, SpringDoc OpenAPI 3.0.0
+- **Additional Tools**: MapStruct 1.6.3, Jackson 2.19.2, SpringDoc OpenAPI 2.8.14
 
 ### Main Server Module Structure
 
@@ -95,14 +95,10 @@ docker compose -f docker-compose.dev.server.yml up -d
     - `atlas-configuration/` - Workflow configuration management
 
 - **`automation/`** - iPaaS automation implementation
-    - `automation-ai/` - AI-powered automation features
     - `automation-configuration/` - Project and workflow configuration
-    - `automation-data-table/` - Data table management
-    - `automation-execution/` - Workflow execution services
-    - `automation-knowledge-base/` - Knowledge base integration
-    - `automation-mcp/` - MCP (Model Context Protocol) integration
-    - `automation-task/` - Task management services
+    - `automation-connection/` - Connection management
     - `automation-workflow/` - Workflow coordination and execution
+    - `automation-task/` - Task management services
 
 - **`platform/`** - Core infrastructure services
     - `platform-component/` - Component definition and management
@@ -194,12 +190,6 @@ public class ExampleComponentHandler implements ComponentHandler {
 
 ## Code Style and Best Practices
 
-### Client ESLint sort-keys Rule
-- Object keys must be in natural ascending (alphabetical) order in client code
-- Applies to mock objects, hoisted state, test data, and component props
-- ESLint `--fix` does NOT auto-fix sort-keys - must be fixed manually
-- Example: `{content: 'x', id: 'y'}` not `{id: 'y', content: 'x'}`
-
 ### Variable Naming
 - Do not use short or cryptic variable names on both the server and client sides; prefer clear, descriptive names that communicate intent.
 - This applies everywhere, including arrow function parameters and loop variables.
@@ -219,28 +209,6 @@ public class ExampleComponentHandler implements ComponentHandler {
   for (Order order : orders) { ... }
   ```
 
-### Lucide Icon Imports (Client)
-- Always import icons with the `Icon` suffix: `SearchIcon`, `DatabaseIcon`, `Loader2Icon`
-- Not: `Search`, `Database`, `Loader2`
-
-### CSS Class Merging (Client)
-- Use `twMerge` from `tailwind-merge` for conditional class merging
-- Do not use `cn()` utility
-
-### React Patterns (Client)
-- Use `fieldset` (with `border-0`) for semantic form grouping instead of `div`
-- Replace nested ternary operators with render functions (e.g., `renderTrigger()`)
-- Use `useMemo` for computed values instead of IIFEs in JSX
-- Prefer `||` over `??` for JSX fallbacks (e.g., `trigger || defaultTrigger`)
-
-### GraphQL Conventions
-- Enum values must use SCREAMING_SNAKE_CASE (e.g., `DELETE`, `GET`, `QUERY`, `PATH`)
-- Consistent with HttpMethod and other enums in `*.graphqls` files
-
-### ID Generation
-- Avoid `hashCode()` for generating unique identifiers (collision risk)
-- Prefer SHA-256 with first 8 bytes for deterministic long IDs, or UUID for true uniqueness
-
 ### Blank Line Before Control Statements (Java)
 - Insert exactly one empty line before control statements to improve visual separation of logic:
   - Applies to: `if`, `else if`, `else`, `for`, enhanced `for`, `while`, `do { ... } while (...)`, `switch`, `try`/`catch`/`finally`.
@@ -269,21 +237,6 @@ public class ExampleComponentHandler implements ComponentHandler {
   }
   ```
 
-### Blank Line After Variable Modification (Java)
-- Insert exactly one empty line between a variable modification and a subsequent statement that uses that variable
-- This improves readability by visually separating the setup from the usage
-- Example:
-  ```java
-  // Bad
-  document.setStatus(KnowledgeBaseDocument.STATUS_PROCESSING);
-  knowledgeBaseDocumentService.saveKnowledgeBaseDocument(document);
-
-  // Good
-  document.setStatus(KnowledgeBaseDocument.STATUS_PROCESSING);
-
-  knowledgeBaseDocumentService.saveKnowledgeBaseDocument(document);
-  ```
-
 ### Method Chaining
 - Do not chain method calls except where this is natural and idiomatic
 - Allowed exceptions (non-exhaustive):
@@ -306,21 +259,6 @@ public class ExampleComponentHandler implements ComponentHandler {
   - Keep declarative chains (queries, reactive pipelines) as one logical block; prefer one operation per line
   - Avoid chaining when side effects are involved or intermediate values deserve names for clarity/debugging
 
-### Code Quality Tool Patterns
-
-**SpotBugs**:
-- Don't use rough approximations of known constants (e.g., use `Math.PI` instead of `3.14`)
-- Always check return values of methods like `CountDownLatch.await(long, TimeUnit)` - returns boolean
-- Use try-with-resources for `Connection` objects to avoid resource leaks
-- Catch specific exceptions (`SQLException`) instead of generic `Exception` when possible
-
-**PMD**:
-- Use `@SuppressWarnings("PMD.UnusedFormalParameter")` for interface-required but unused parameters
-- Don't qualify static method calls with the class name when already inside that class (e.g., `builder()` not `ClassName.builder()`)
-
-**Checkstyle**:
-- Test method names must be camelCase without underscores (e.g., `testExecuteSuccess` not `testExecute_Success`)
-
 ### Spring Boot Best Practices
 
 1. **Prefer Constructor Injection over Field/Setter Injection**
@@ -492,10 +430,6 @@ cd cli
 ./gradlew :cli-app:bootRun --args="component init openapi --name=my-component --openapi-path=/path/to/openapi.yaml"
 ```
 
-### Resolving PR Review Comments
-- Use `gh api graphql` with `resolveReviewThread` mutation to close threads programmatically
-- Get thread IDs via: `gh api graphql -f query='{ repository(owner: "X", name: "Y") { pullRequest(number: N) { reviewThreads(first: 20) { nodes { id isResolved path } } } }'`
-
 ## Build and Deployment
 
 ### Docker
@@ -775,8 +709,8 @@ tail -f server/apps/server-app/build/logs/application.log
 
 **Gradle Build Optimization**
 - Gradle JVM is configured with 4GB heap in `gradle.properties`
-- Parallel builds are enabled by default
-- Build cache is enabled by default
+- Parallel builds are disabled by default but can be enabled
+- Use build cache: `./gradlew --build-cache build`
 - Use configuration cache: `./gradlew --configuration-cache build`
 - Gradle daemon runs by default for faster subsequent builds
 

build.gradle.kts

@@ -20,7 +20,7 @@ dependencyManagement {
 
 versionCatalogUpdate {
     keep {
-        versions.addAll("checkstyle", "findsecbugs", "gradle-git-properties", "jackson", "jacoco", "java", "jib-gradle-plugin", "pmd", "spotbugs", "spring-ai", "spring-boot", "spring-cloud-aws", "spring-cloud-dependencies", "spring-shell", "testcontainers")
+        versions.addAll("checkstyle", "gradle-git-properties", "jackson", "jacoco", "java", "jib-gradle-plugin", "pmd", "spotbugs", "spring-ai", "spring-boot", "spring-cloud-aws", "spring-cloud-dependencies", "spring-shell", "testcontainers")
     }
 }
 
@@ -31,7 +31,7 @@ subprojects {
 
     dependencyManagement {
         dependencies {
-            dependency("com.github.spotbugs:spotbugs-annotations:[${rootProject.libs.versions.spotbugs.get()},)")
+            dependency("com.github.spotbugs:spotbugs-annotations:[4.9.3,)")
         }
     }
 
@@ -41,8 +41,6 @@ subprojects {
         implementation("org.jspecify:jspecify")
         implementation(platform(org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES))
 
-        spotbugsPlugins("com.h3xstream.findsecbugs:findsecbugs-plugin:${rootProject.libs.versions.findsecbugs.get()}")
-
         testCompileOnly(rootProject.libs.com.github.spotbugs.spotbugs.annotations)
 
         testImplementation("org.springframework.boot:spring-boot-starter-test")