Merge dev into test

.github/workflows/confluence-sync.yml

@@ -0,0 +1,165 @@
+name: Confluence Sync
+
+on:
+  schedule:
+    # Runs every Monday at 02:00 UTC
+    - cron: '0 2 * * 1'
+
+  workflow_dispatch:
+  # Allow manual trigger from GitHub UI
+
+  # Optional: trigger on push to main branch if confluence-config.json changes
+  push:
+    paths:
+      - 'scripts/src/confluence/confluence-config.json'
+      - 'scripts/src/confluence/sync-confluence.py'
+      - 'scripts/src/confluence/requirements.txt'
+      - '.github/workflows/confluence-sync.yml'
+    branches:
+      - main
+
+jobs:
+  sync:
+    runs-on: ubuntu-latest
+    name: Sync Confluence to Git
+
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+
+      - name: Set up Python
+        uses: actions/setup-python@v4
+        with:
+          python-version: '3.11'
+          cache: 'pip'
+
+      - name: Install dependencies
+        run: |
+          python -m pip install --upgrade pip
+          pip install -r scripts/src/confluence/requirements.txt
+
+      - name: Run converter self-test
+        run: |
+          python scripts/src/confluence/sync-confluence.py --self-test
+
+      - name: Configure git
+        run: |
+          git config --local user.email "bot@dcsa.org"
+          git config --local user.name "DCSA Bot"
+
+      - name: Run Confluence Sync
+        env:
+          CONFLUENCE_BASE_URL: ${{ secrets.CONFLUENCE_BASE_URL }}
+          CONFLUENCE_USERNAME: ${{ secrets.CONFLUENCE_USERNAME }}
+          CONFLUENCE_API_TOKEN: ${{ secrets.CONFLUENCE_API_TOKEN }}
+          CONFLUENCE_SPACE_KEY: SD
+        run: |
+          python scripts/src/confluence/sync-confluence.py
+
+      - name: Check for changes
+        id: git-check
+        run: |
+          if git diff --quiet; then
+            echo "has_changes=false" >> $GITHUB_OUTPUT
+          else
+            echo "has_changes=true" >> $GITHUB_OUTPUT
+          fi
+
+      - name: Commit and push changes
+        if: steps.git-check.outputs.has_changes == 'true'
+        run: |
+          git add specifications/confluence-sync/
+          git commit -m "docs: auto-sync Confluence documentation
+
+          - Synced specifications from Confluence space SD
+          - Timestamp: $(date -u +'%Y-%m-%dT%H:%M:%SZ')
+          - Workflow: Confluence Sync"
+          git push
+
+      - name: Create Pull Request
+        if: steps.git-check.outputs.has_changes == 'true'
+        uses: peter-evans/create-pull-request@v5
+        with:
+          commit-message: 'docs: auto-sync Confluence documentation'
+          title: 'docs: Auto-sync Confluence documentation'
+          body: |
+            ## Automated Confluence Sync
+
+            This PR contains automatically synced documentation from Confluence.
+
+            **Sync Details:**
+            - Source: Confluence Space `SD` (Standards Development)
+            - Destination: `specifications/confluence-sync/`
+            - Timestamp: ${{ github.event.head_commit.timestamp }}
+            - Trigger: ${{ github.event_name }}
+
+            ### What to check:
+            - [ ] Files have expected content
+            - [ ] No sensitive data exposed
+            - [ ] Markdown formatting looks correct
+            - [ ] Links are preserved
+
+            ### Merge Instructions:
+            If everything looks good, merge this PR to keep specifications current.
+          branch: confluence-sync-${{ github.run_number }}
+          delete-branch: true
+          labels: |
+            documentation
+            automated
+            confluence-sync
+
+      - name: Workflow Status
+        if: always()
+        run: |
+          echo "## Confluence Sync Status"
+          echo "- Scheduled: Every Monday at 02:00 UTC"
+          echo "- Last Run: $(date -u +'%Y-%m-%d %H:%M:%S UTC')"
+          echo "- Changes Detected: ${{ steps.git-check.outputs.has_changes }}"
+          echo "- Configuration: scripts/src/confluence/confluence-config.json"
+
+  verify:
+    runs-on: ubuntu-latest
+    name: Verify Sync Output
+    needs: sync
+    if: always()
+
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      - name: Check sync directory exists
+        run: |
+          if [ -d "specifications/confluence-sync" ]; then
+            echo "✓ Sync directory exists"
+            ls -la specifications/confluence-sync/
+          else
+            echo "⚠ Sync directory not found (may be first run)"
+          fi
+
+      - name: Validate markdown files
+        run: |
+          if find specifications/confluence-sync -type f -name '*.md' | grep -q .; then
+            count=$(find specifications/confluence-sync -type f -name '*.md' | wc -l)
+            echo "✓ Found ${count} markdown files"
+            while IFS= read -r file; do
+              if [ -s "$file" ]; then
+                echo "  ✓ ${file} - $(wc -l < "$file") lines"
+              fi
+            done < <(find specifications/confluence-sync -type f -name '*.md' | sort)
+          else
+            echo "ℹ No markdown files found (check config or Confluence connectivity)"
+          fi
+
+      - name: Summary
+        run: |
+          echo "## Sync Verification Complete"
+          echo "- Documentation location: specifications/confluence-sync/"
+          echo "- Config file: scripts/src/confluence/confluence-config.json"
+          echo "- Next sync: Monday 02:00 UTC"
+          echo ""
+          echo "To manually trigger sync:"
+          echo "  1. Go to: Actions → Confluence Sync"
+          echo "  2. Click: Run workflow"
+

.gitignore

@@ -33,3 +33,8 @@ build/
 .vscode/
 
 .run
+
+### Environment variables ###
+.env
+.env.local
+.env.*.local

AGENTS.md

@@ -33,20 +33,35 @@ Do not hardcode the random local auth token.
 5. Run focused tests first, then tests for all affected reactor modules.
 6. If the change can affect scenario construction, actions, parties, orchestration, validation, reports, API traffic, or standard resources, run the complete affected conformance suite and inspect its HTML report. Unit tests alone are not sufficient.
 7. Summarize commands run, report path, and any testing that could not be performed. Never claim a pass without running the command.
+8. Maintain this guide iteratively when a change reveals a durable, repository-wide convention or a
+   non-obvious failure mode likely to recur. Add only concise, actionable guidance that will help
+   future work; do not record one-off implementation details, duplicate existing rules, or expand
+   the file merely because code changed. Refine an existing rule instead of adding another when
+   that communicates the lesson more clearly.
 
 Do not temporarily comment out parameterized standards/scenarios or remove `@Disabled` and commit that change. Use focused Maven selectors or IDE run configurations instead.
 
 ## Standard specifications are authoritative
 
-Before changing a standard module, locate and read its standard-specific Markdown resources (for example, `booking.md`). When such documentation is present, treat it as the source of truth for that standard's conformance behavior. Scenario coverage and sequencing, actions, checks, validation applicability, role behavior, synthetic-party state transitions, prompts, and tests must all agree with the documented requirements. Do not alter or weaken documented behavior merely to make an existing test pass.
+Before changing a standard module, locate and read its synced standard-specific Markdown documentation under `specifications/confluence-sync/<standard>/<version>/` (for example, `specifications/confluence-sync/booking/2.0.4/conformance-scenarios.md`). Treat this synced documentation as the source of truth for that standard's conformance behavior. Scenario coverage and sequencing, actions, checks, validation applicability, role behavior, synthetic-party state transitions, prompts, and tests must all agree with the documented requirements. Do not alter or weaken documented behavior merely to make an existing test pass.
 
-If the Markdown references an Excel workbook for validations, the workbook is an authoritative part of the specification and must be analyzed directly; filenames or summaries are not sufficient. Inspect every relevant worksheet, including notes, merged cells, formulas or displayed values, alternatives such as “A or B,” optional or conditional fields, and state-dependent rules. Then trace every applicable workbook row and condition to both:
+If the synced Markdown references an Excel workbook for validations, the workbook is an authoritative part of the specification and must be analyzed directly; filenames or summaries are not sufficient. Use the synced files under `specifications/confluence-sync/<standard>/<version>/excel/`. Inspect every relevant worksheet, including notes, merged cells, formulas or displayed values, alternatives such as “A or B,” optional or conditional fields, and state-dependent rules. Then trace every applicable workbook row and condition to both:
 
 - the conformance checks and validators that accept and reject exchanges; and
 - the internal synthetic-party implementation that creates payloads and performs state transitions.
 
 The implementation must map exactly to the workbook within the applicability and exceptions defined by the Markdown. Preserve distinctions between required and optional scenarios and any explicitly documented validation bypasses. Add table-driven regression coverage where practical for every allowed combination, required/forbidden field, conditional branch, and representative invalid combination. If documentation, workbook, code, and tests disagree, resolve the discrepancy against the documented specification and workbook rather than assuming the current implementation is correct, and record any genuine ambiguity that cannot be resolved from those sources.
 
+For changes driven by multiple artifacts, reconcile them before coding in this order: synced scenario Markdown (module names, action paths, role ownership, required/optional classification and scope), each role-specific validation workbook (exact report labels and applicability), any status/state-transition sheet (allowed preconditions and expected postconditions), and the referenced OpenAPI schemas/endpoints. Maintain a working matrix from every requirement to its scenario builder, action/check, synthetic-party behavior, and regression test. A generated green report is the final cross-check, not a substitute for this artifact-by-artifact reconciliation.
+
+Keep report titles distinct from conformance expectations. Scenario and action titles should contain only identifiers explicitly intended as labels, such as `confirm`, `decline`, or `amended content`. Expected HTTP classes/codes and expected document states belong in checks and explanatory prose unless the authoritative Markdown explicitly includes them in the title. Assert exact module, scenario, action, and validation labels in tests when report wording is part of the requirement.
+
+When a specification permits any successful HTTP response, use
+`ResponseStatusCheck.forSuccessfulResponse(...)` rather than enumerating common values such as
+`200`, `202`, and `204`. Keep successful retrieval (`GET`) checks exact when the specification
+requires `200`, and preserve exact non-success status checks for negative scenarios. Apply this
+consistently to primary exchanges and notification acknowledgements.
+
 ## Scenario builder correctness
 
 `AbstractComponentFactory.generateConformanceScenarios` requires globally unique scenario titles. Module labels are also significant because they become report sections.
@@ -60,6 +75,10 @@ When combining role-specific module maps for an all-in-one sandbox:
 - Add tests for both each individual role and the all-roles selection whenever role module maps change.
 - Do not weaken duplicate scenario-title validation to make an all-in-one suite start. Fix the colliding titles so both scenarios remain identifiable.
 
+Standalone root actions that synthesize references or payloads must re-establish the relationship between those values after reset and JSON-state import. Keep prompt URL/reference fields and payload references atomic, and add a regression test that imports stale dynamic scenario parameters before serializing the prompt; constructor-only initialization is not sufficient.
+
+To disable a scenario suite without deleting its implementation: remove it from the standard's advertised suite set, disable/comment its scenario-builder dispatch branch, remove or comment any explicitly hard-coded Spring/manual/Selenium integration case, and replace documentation or runner examples that advertise it. Keep dormant builders and endpoint metadata only when useful for straightforward re-enablement. Add a contract test for the exact advertised suite set and verify the disabled sandbox ID is absent from the generated homepage.
+
 When adding a standard/version/suite, ensure it is exposed by the relevant `ConformanceStandard`, generated on the Spring Boot homepage, represented in `ConformanceApplicationTest`, and runnable through the conformance runner.
 
 ## Java build and test commands
@@ -72,6 +91,8 @@ Focused module tests (also builds dependencies):
 ./mvnw -pl booking -am test
 ```
 
+When a shared module API changes, a direct downstream command without `-am` can resolve an older locally installed snapshot even if the working tree compiles in a reactor. Prefer the reactor command; if an unrelated upstream test configuration prevents it, first install the changed shared modules with tests skipped, then run the downstream module tests normally. Treat that install only as dependency preparation, never as test validation.
+
 A specific test across a reactor (the extra property prevents dependency modules with no matching test from failing):
 
 ```bash
@@ -119,9 +140,9 @@ Or let the runner own the backend lifecycle:
 
 ```bash
 npm --prefix scripts run run-conformance-suite -- \
-  --standard Booking \
-  --version 2.0.0 \
-  --suite Conformance \
+  --standard eBL \
+  --version 3.0.0 \
+  --suite 'Conformance TD' \
   --start-command './mvnw -pl spring-boot -am spring-boot:run'
 ```
 
@@ -133,6 +154,13 @@ The runner:
 - saves HTML under root `target/conformance-reports/` by default;
 - exits non-zero for HTTP/startup/timeout/report parsing errors or any top-level role that is not conformant;
 - retains the HTML report when conformance validation fails.
+- automatically creates both `with-notifications` and `without-notifications` reports for Booking
+  and eBL; notification suppression must be applied atomically as part of reset, before scenario
+  execution, to avoid race-dependent coverage.
+- Suppressing optional notification traffic must still advance orchestration and mark the action as
+  completed without traffic. Cover both standalone notification actions carrying an action ID and
+  follow-up notifications without one; preserve any required action input and validate the
+  notification sender role before completing the current action.
 
 Open a failing report and inspect the first non-conformant scenario/action and its recorded exchange errors. Fix the cause and rerun until green; do not merely loosen the runner's status parsing or assertions.
 
@@ -165,6 +193,11 @@ npm start
 
 The local UI is served at `http://localhost:4200/environment` and the backend at `http://localhost:8080`. Add or update Jest tests for components/services you change. Backend report success does not replace frontend tests.
 
+For automatically refreshed views, update component data in place without clearing the currently
+rendered model or navigating/reloading the page. Prevent overlapping polls, stop timers on
+component destruction, preserve the last successful state when a background refresh fails, and
+refresh immediately after successful mutations such as reset.
+
 ## Local Docker option
 
 ```bash
@@ -178,7 +211,7 @@ This starts backend port `8080` and frontend port `4200`. Prefer the manual Spri
 Before finishing a change, verify:
 
 - [ ] Existing user changes were preserved.
-- [ ] The affected standard's Markdown was reviewed and scenarios, checks, parties, and tests match it.
+- [ ] The affected standard's synced Markdown in `specifications/confluence-sync/<standard>/<version>/` was reviewed and scenarios, checks, parties, and tests match it.
 - [ ] Every referenced validation workbook was directly analyzed and its applicable rows and conditions map exactly to validators, synthetic-party behavior, and regression tests.
 - [ ] New behavior has a focused regression test.
 - [ ] No role-specific scenario modules are lost to key collisions.

README.md

@@ -1,4 +1,12 @@
-# DCSA Conformance Framework
+# DCSA Conformance Gateway
+
+## Documentation & Specifications
+
+- Documentation index: [`docs/README.md`](./docs/README.md)
+- Synced Confluence pages: [`specifications/confluence-sync/`](./specifications/confluence-sync/)
+- Sync setup: [`specifications/SETUP.md`](./specifications/SETUP.md)
+
+---
 
 ## Overview
 The DCSA Conformance Framework is used by the adopters of each DCSA standard to measure the conformance of their
@@ -80,7 +88,7 @@ There are 4 types of tests in the project:
    tested in this way.
 3. Web UI testing, which is done by using Selenium. This can be found in the `SeleniumTest` class. It requires NodeJS to
    be running. These tests take quite a while, because it often needs to wait before the UI is ready.
-4. AWS testing, which only runs the EBL Conformance TD-only test on the Carrier role, by using the UI. This is also
+4. AWS testing, which only runs the EBL Conformance TD test on the Carrier role, by using the UI. This is also
    performed by Selenium. This can be found in the `AWSEnvironmentTest` class. It needs several environment variables to
    be set, which are not in the repository. Those you can set in your IDE, or by temporarily changing the code.