Jackson patch

.env.example

@@ -58,7 +58,7 @@ SES_FROM=noreply@example.com
 # Optional: Set APP_BASE_URL to override the defaults:
 # - Local IDE: Defaults to http://localhost:4200
 # - Local Docker: Defaults to http://localhost
-# - AWS Fargate: Set in task definition (https://goodone.ch)
+# - AWS Fargate: Set in task definition (https://GoodOne.ch)
 # APP_BASE_URL=http://localhost:4200
 
 # JWT Secret for local development

.github/workflows/guardrails.yml

@@ -0,0 +1,34 @@
+name: Junie Guardrails
+
+on:
+  pull_request:
+    branches: [ main ]
+  push:
+    branches: [ main ]
+
+jobs:
+  validate:
+    name: Run Guardrails Validator
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Setup Python
+        uses: actions/setup-python@v5
+        with:
+          python-version: "3.11"
+
+      - name: Install dependencies
+        run: pip install pyyaml
+
+      - name: Run Validator with Autofix
+        run: python scripts/task-governance/guardrails-validator.py --autofix
+
+      - name: Check for changes after autofix
+        run: |
+          if [ -n "$(git status --porcelain)" ]; then
+            echo "Autofix applied changes. Please review and commit locally."
+            git diff
+            exit 1
+          fi

.github/workflows/task-contract-lint.yml

@@ -0,0 +1,33 @@
+name: Task Contract Lint
+
+on:
+  pull_request:
+    paths:
+      - 'doc/knowledge/junie-tasks/**'
+      - 'scripts/task-governance/**'
+      - '.github/workflows/task-contract-lint.yml'
+
+jobs:
+  lint-task-contracts:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+
+      - uses: actions/setup-python@v5
+        with:
+          python-version: '3.11'
+
+      - name: Get changed files
+        id: changed-files
+        uses: tj-actions/changed-files@v44
+        with:
+          files: doc/knowledge/junie-tasks/**
+          json: true
+
+      - name: Run task contract linter
+        if: steps.changed-files.outputs.any_changed == 'true'
+        run: |
+          echo '${{ steps.changed-files.outputs.all_changed_files }}' | jq -r '.[]' > files_to_lint.txt
+          xargs -d '\n' -r python scripts/task-governance/lint_task_contracts.py < files_to_lint.txt

.github/workflows/validate-tasks.yml

@@ -21,4 +21,4 @@ jobs:
         run: pip install pyyaml
 
       - name: Validate task files
-        run: python scripts/validate_tasks.py doc/knowledge/junie-tasks
+        run: python scripts/task-governance/validate_tasks.py doc/knowledge/junie-tasks

.gitignore

@@ -2472,3 +2472,12 @@
 /frontend/node/npx
 /frontend/node/npx.cmd
 /.ai/mcp/mcp.json
+/doc/knowledge/junie-tasks/backlog/
+/logs/ai-traces/
+/backend/logs/ai-traces/
+/tmp_repo/
+/sonar-export-new/issues/
+/sonar/sonar-export/issues/
+/sonar-export/issues/
+/sonar-export-fresh/issues/
+/test-results/

.junie/guidelines.md

@@ -5,16 +5,45 @@ This document outlines the best practices and standards for the GoodOne project.
 ## General Principles
 - **Modern Standards**: Use the latest stable versions of frameworks (Angular 21+, Spring Boot 4+). NEVER use deprecated methods, features, or syntax in any language (e.g., avoid `*ngIf` and `*ngFor` in Angular, use modern control flow instead).
 - **Consistency**: Follow existing naming conventions and project structure.
-- **Clean Code**: Remove all unused imports, variables, and commented-out code blocks. Every test case MUST have at least one explicit assertion (e.g., `expect`, `assert`, `assertEquals`). Avoid empty catch blocks; at least log the exception or add a comment explaining why it's ignored.
-- **Method Complexity**: Keep methods small and focused (Single Responsibility Principle). Avoid "Brain Methods" with high cyclomatic complexity (e.g., > 10).
+- **Clean Code**: Remove all unused imports (including for TypeScript/Angular), variables, fields, parameters, and commented-out code blocks. Every test case MUST have at least one explicit assertion (e.g., `expect`, `assert`, `assertEquals`). Avoid empty catch blocks; at least log the exception or add a comment explaining why it's ignored. NEVER append empty trailing lines to files; all files MUST end with a single newline character.
+- **Complexity Guardrails**:
+    - **Cognitive Complexity**: Max 15 per method (Sonar java:S3776).
+    - **Nesting Depth**: Max 3 levels of indentation (if, for, while, try). Use early returns (guard clauses) to reduce nesting.
+    - **Method Length**: Aim for < 30 lines. Methods exceeding 50 lines MUST be refactored into smaller, focused private methods.
+    - **Parameters**: Max 7 parameters (Sonar java:S107). Use DTOs or Value Objects for more.
+    - **Boolean Expressions**: Avoid complex conditions with more than 3 operators (`&&`, `||`). Break them down into descriptive boolean variables or helper methods.
+    - **Switch/If-Else Chains**: Long chains of `if-else if` or `switch` (e.g., > 5 cases) should be refactored using a Map-based lookup, Strategy pattern, or Polymorphism.
+- **Modern Java Standards (Java 21)**: 
+    - Use `Stream.toList()` instead of `.collect(Collectors.toList())` for unmodifiable lists.
+    - Use Pattern Matching for `instanceof` (e.g., `if (obj instanceof String s)`).
+    - Use Text Blocks (`"""..."""`) for multiline strings (e.g., SQL, JSON, HTML, or large text reports) instead of string concatenation.
+    - Use `.formatted()` for string interpolation in text blocks or literals.
+    - **Logging**: Use SLF4J `Logger` for all logging. NEVER use `System.out.println`, `System.err.println`, or `Throwable.printStackTrace()`. Use placeholders (e.g., `logger.info("User {} logged in", userId)`) instead of string concatenation.
+    - **Exceptions**: Avoid throwing generic exceptions like `RuntimeException`, `Exception`, or `Throwable`. Use specific, descriptive exceptions. NEVER ignore caught exceptions; log them or explain why they are ignored.
+    - **Modifiers**: Follow the standard Java modifier order: `public protected private abstract default static final transient volatile synchronized native strictfp`.
+- **Clean Logic**: 
+    - Avoid nested ternary operators.
+    - Merge nested `if` statements into a single `if` with a combined condition (`&&`) when they have no `else` and no other code in between.
+    - Prefer method references (e.g., `Objects::nonNull`) over lambda expressions (e.g., `x -> x != null`) when the lambda only calls an existing method.
+    - Simplify boolean returns (e.g., `return condition;` instead of `if (condition) return true; else return false;`).
+    - Avoid using Java restricted identifiers (e.g., `record`, `yield`, `var`, `sealed`, `permits`) as variable or parameter names.
+    - Remove redundant type casts.
+    - Iterate over `entrySet()` instead of `keySet()` when both keys and values are required.
+    - **Constants**: Avoid duplicating string literals; use `private static final` constants (UPPER_SNAKE_CASE) for repeated values. Avoid "magic numbers"; use descriptive constants instead.
+    - **Hardcoded Values**: Avoid hardcoding URIs, file paths, or configuration values. Use `@Value` or `@ConfigurationProperties` to inject them.
+    - Remove unused private methods, fields, and parameters.
+- **Modern Frontend Standards**:
+    - Use `readonly` for TypeScript properties that are only set in the constructor or never reassigned.
+    - Use `@use` instead of `@import` in Sass/CSS files.
+    - Avoid deprecated APIs; always prefer the modern equivalent (e.g., modern Angular control flow).
 - **Communication**: If there are doubts about the implementation or if better ways are identified, stop the implementation and ask the user before continuing.
 - **RBAC Synchronization**: Frontend and backend Role-Based Access Control (RBAC) MUST always be in sync. Every protected UI route MUST have a corresponding protected REST endpoint with the same security policy (e.g., `ROLE_ADMIN`). This ensures "Defense in Depth" and prevents security bypasses via direct API access. This is a CRITICAL security requirement.
 - **Centralized Versioning**: 
     - The **Root `pom.xml`** is the single source of truth for the project version.
     - All modules (Backend, Frontend, Android, Test Client) must share the same version.
     - Use `.\scripts\sync-version.ps1` to propagate version changes from the root `pom.xml` to other files (package.json, build.gradle, deployment scripts, and documentation).
 - **Build Integrity**: Ensure the project builds successfully (`mvn clean install`) before submitting changes.
-- **Post‑Refactoring Build**: After every refactoring (no matter how small), the application MUST build successfully. Verify locally with:
+- **Post-Refactoring Build**: After every refactoring (no matter how small), the application MUST build successfully. Verify locally with:
   - Backend+Frontend: `mvn clean install -DskipTests`
   - Frontend only: `mvn clean install -pl frontend -DskipTests`
   Any refactoring is incomplete until these builds pass.
@@ -37,6 +66,8 @@ This document outlines the best practices and standards for the GoodOne project.
     - No dev-only features are exposed.
     - Application can be demoed repeatedly without manual fixes.
     - Playwright UX guardrails are successful (`npx playwright test e2e/ux-guardrails.spec.ts`).
+    - **Task Log Update**: The relevant task `.md` file MUST be updated with a log entry and testing instructions.
+    - **Basic Regression**: All relevant unit and E2E tests MUST pass before reporting "DONE".
 - **Docker First**: Ensure all changes are compatible with the Docker-based deployment.
 - **Language**: Always communicate in English for all interactions, thoughts, and documentation, unless explicitly requested otherwise by the user.
 - **Translations**: Always provide translations for both supported languages (English `en.json` and German `de-ch.json`) when adding or modifying UI text. The `ch` part of the `de-ch` locale MUST be respected: never use the letter 'ß' (Eszett) in any German translations (e.g. use 'ss' instead).
@@ -62,6 +93,7 @@ This document outlines the best practices and standards for the GoodOne project.
             6. `## Verification`
             7. `## Links`
             8. `## Notes (optional)`
+            9. `## Acceptance Confirmation`
         - **YAML Frontmatter**: Must include `key`, `title`, `taskset`, `priority`, `status`, `created`, `updated`, and `iterations`.
             - `status` must be one of: `TODO`, `IN_PROGRESS`, `DONE`, `BLOCKED`.
             - `priority` must be one of: `P0`, `P1`, `P2`.
@@ -78,16 +110,20 @@ This document outlines the best practices and standards for the GoodOne project.
             - Never invent new metadata fields or move metadata into the markdown body.
             - Never add emojis or decorative formatting.
             - If an instruction conflicts with this guideline, refuse and explain why.
+        - **Task Storage**:
+            - The following folders are legacy and are used to keep the history of old tasks: `doc/knowledge/junie-tasks/taskset*`.
+            - All new tasks MUST be placed in category folders: `doc/knowledge/junie-tasks/AI-*/` (e.g., `doc/knowledge/junie-tasks/AI-REL/`).
+            - **CRITICAL**: Whenever you update an `.md` file in a legacy folder (e.g. `doc/knowledge/junie-tasks/taskset*`), you MUST move it to its corresponding category folder `doc/knowledge/junie-tasks/AI-*/` (e.g. `doc/knowledge/junie-tasks/AI-ARCH/`) before submitting. Do NOT update files in legacy folders anymore.
         - **Chat Summarization Workaround**:
             - If the Junie AI JetBrains plugin does not provide a manual rename option, ensure the full task filename (without extension) is mentioned prominently in the initial message of a task. This triggers the plugin's automatic summarizer to include the complete Task ID and filename in the chat history summary.
 
 ## Backend Development (Spring Boot)
 
 ### 1. Architecture
-- **Controllers**: Use RESTful controllers in `ch.goodone.goodone.backend.controller`.
-- **Models**: Use JPA entities in `ch.goodone.goodone.backend.model`. Always create a Flyway migration script (in `backend/src/main/resources/db/migration/`) whenever a JPA entity is created or modified to ensure the database schema stays in sync.
+- **Controllers**: Use RESTful controllers in `ch.goodone.backend.controller`.
+- **Models**: Use JPA entities in `ch.goodone.backend.model`. Always create a Flyway migration script (in `backend/src/main/resources/db/migration/`) whenever a JPA entity is created or modified to ensure the database schema stays in sync.
 - **Idempotent Migrations**: All Flyway migration scripts MUST be idempotent. Use `CREATE TABLE IF NOT EXISTS`, `ALTER TABLE ... ADD COLUMN IF NOT EXISTS`, and similar constructs. This is critical for Fargate deployments where tasks may restart or run concurrently during rollout.
-- **Repositories**: Use Spring Data JPA repositories in `ch.goodone.goodone.backend.repository`. Avoid using direct SQL statements (e.g., via `JdbcTemplate`) in Java code. Use JPA or Spring Data JPA abstractions for all database operations.
+- **Repositories**: Use Spring Data JPA repositories in `ch.goodone.backend.repository`. Avoid using direct SQL statements (e.g., via `JdbcTemplate`) in Java code. Use JPA or Spring Data JPA abstractions for all database operations.
 - **DTOs**: Use DTOs for API requests and responses to avoid leaking internal entity structures. Implement `fromEntity()` static methods in DTOs for centralized mapping.
 
 ### 2. Best Practices
@@ -97,15 +133,17 @@ This document outlines the best practices and standards for the GoodOne project.
     - **Log Security**: NEVER log user-provided data (e.g., request parameters, headers, paths) directly without sanitization to prevent Log Injection. Use placeholders and only log trusted or sanitized values. NEVER log sensitive information like passwords, session tokens, or PII.
 - **Type Safety**: Avoid using generic wildcard types like `ResponseEntity<?>` or `ResponseEntity<Object>` in controllers. Always use specific DTOs or `ResponseEntity<Void>` to maintain clear API contracts and avoid Sonar issues.
 - **Validation**: Use `@Column` annotations for explicit database mapping. Use unique constraints where appropriate (e.g., login, email).
-- **JSON Handling**: Use `tools.jackson.databind.ObjectMapper` for JSON processing in tests.
+- **JSON Handling**: Always use **`tools.jackson.databind.ObjectMapper`** for all Spring `@Bean` definitions, `@Autowired` injections, and JSON processing in tests (matching Spring Boot 4's default). Continue using **`com.fasterxml.jackson.annotation.*`** for DTOs to maintain compatibility with existing annotations. Refer to [ADR-0067](doc/knowledge/adrs/adr-full-set.md#adr-0067-single-serialization-ownership-jackson-3-only) for details.
 - **Auditing**: All major user interactions (login, registration, password changes, etc.) and significant system events must be logged to the `ActionLogService` to ensure a robust audit trail.
 - **Date/Time**: Use `LocalDate` for dates. Use `@JsonFormat(pattern = "yyyy-MM-dd")` for DTO date fields.
 - **Role-Based Access Control**: Enforce security in `SecurityConfig` and use the `Role` enum.
 
 ### 3. Testing
 - Use JUnit 5 and MockMvc for controller testing.
+- JUnit 5 test classes and methods should have default (package-private) visibility. Avoid using `public`.
 - Always include Spring Security in the test context if the endpoint is protected.
 - Keep tests isolated from the database using a `test` profile if needed.
+- **AI Infrastructure for Builds/Tests**: Local builds and tests MUST run with Ollama, not OpenAI. No OpenAI tokens must be consumed during the build process. Ensure all `@SpringBootTest` use the `ollama` profile or mock AI beans accordingly.
 
 ## Frontend Development (Angular)
 
@@ -133,9 +171,12 @@ This document outlines the best practices and standards for the GoodOne project.
 
 ## Deployment & Environments
 - **Local Dev**: Use `npm start` (Angular) and the Spring Boot application (IntelliJ). The Angular proxy (`proxy.conf.json`) handles routing to the backend on `localhost:8080`.
-- **Docker**: Use `docker compose up --build`. Nginx handles the reverse proxying of `/api` requests to the `backend` container.
+- **Docker (Local)**: Use `docker compose up --build`. Nginx handles the reverse proxying of `/api` requests to the `backend` container.
 - **AWS ECS (Fargate)**:
-    - **Resource Allocation**: To minimize costs, always use the minimal required resources for demo services. The standard allocation is **256 CPU units and 512 MiB memory**. Do not increase these without explicit justification and user approval.
+    - **Architecture**: Nginx is NOT used for reverse proxying. The AWS Application Load Balancer (ALB) handles routing (e.g., path-based routing for `/api`). Nginx in the frontend container only serves static files.
+    - **ALB Timeout**: Ensure the ALB 'Idle timeout' is set to at least **300 seconds** (default is 60s) to support long-running AI calls like ADR Drift detection.
+    - **Resource Allocation**: To minimize costs, always use the minimal required resources for demo services. The standard allocation is **256 CPU units and 512 MiB memory**. Do not increase these without explicit justification and user approval. For AI-heavy features with large prompts, **512 CPU units and 2048 MiB memory** may be required to avoid timeouts and high GC pressure.
+    - **Model Selection**: For latency-sensitive AI features like ADR Drift detection, use `gpt-4o-mini` to achieve response times < 10s and reduce token costs.
     - **Single Task Enforcement**: Ensure only one task runs per service by setting `desired-count` to 1 and `maximum-percent` to 100 during deployments to avoid overlapping costs.
     - **Task Definitions**: Always update the local task definition files in `deploy/aws/` and `task-def.json` at the root when making live changes to ensure consistency across deployments.
 

README.md

@@ -28,7 +28,7 @@ Instead of only generating code, the platform analyzes:
 • engineering risks
 
 Live demo  
-https://goodone.ch
+https://GoodOne.ch
 
 ---
 
@@ -221,13 +221,13 @@ Documentation is located in the `doc` directory.
 Key entry points:
 
 Architecture  
-doc/architecture/index.md
+doc/knowledge/architecture/index.md
 
 User Guide  
-doc/user-guide/user-guide.md
+doc/operations-guide.md
 
 Admin Guide  
-doc/admin-guide/admin-guide.md
+doc/operations-guide.md
 
 Deployment  
 doc/infrastructure/Deployment.md