chore(release): bump EDDI version 6.2.0 -> 6.3.0

.github/workflows/redhat-certify.yml

@@ -4,9 +4,9 @@ on:
   workflow_dispatch:
     inputs:
       version:
-        description: "EDDI version (e.g. 6.2.0)"
+        description: "EDDI version (e.g. 6.3.0)"
         required: true
-        default: "6.2.0"
+        default: "6.3.0"
       release:
         description: "Release number (e.g. 1, 2, 3)"
         required: true

README.md

@@ -290,7 +290,7 @@ EDDI implements open standards — not proprietary APIs:
 | **[A2A](https://google.github.io/A2A/)** (Agent-to-Agent Protocol)   | Full implementation             | Cross-platform agent communication, Agent Cards, and skill discovery                                     |
 | **[OpenAPI](https://www.openapis.org/)** 3.1                         | Native generation + consumption | Auto-generated spec. Paste any OpenAPI spec → get a fully deployed API-calling agent                     |
 | **OAuth 2.0 / OIDC**                                                 | Keycloak integration            | Authentication, authorization, and multi-tenant isolation                                                |
-| **SSE** (Server-Sent Events)                                         | Streaming transport             | Real-time chat responses, group discussion feeds, and live log streaming                                 |
+| **SSE** (Server-Sent Events)                                         | Streaming transport             | Token-by-token chat responses — including tool-enabled turns, which stream over the provider's streaming transport rather than going silent until the tool loop finishes — plus a live `tool_call` event for "Using {tool}…" status, group discussion feeds, and live log streaming |
 
 ### 💭 Memory & Context Management
 

docs/README.md

@@ -40,12 +40,14 @@ Built with **Java 25** and **Quarkus**. Ships as a **Red Hat-certified Docker im
 - **[Group Conversations](group-conversations.md)** — Multi-agent debates, voting, shared artifacts, and standing teams across 7 discussion styles (Round Table, Peer Review, Devil's Advocate, Delphi, Debate, Task Force, Negotiation)
 - **[Managed Agents](managed-agents.md)** — Intent-based auto-routing with one conversation per user per intent
 - **[Model Cascading](model-cascade.md)** — Cost-optimized multi-model routing with confidence-based escalation
+- **Platform Operator** — Meta-agent that reads and operates the deployment, including creating other agents, with every write behind a human approval gate. Activate it at `/manage/operator`, or use the form-based wizard at `/manage/agents/wizard` — see **[Getting Started](getting-started.md)**
 
 ### 🔗 Protocols & Interoperability
 
 - **[MCP Server](mcp-server.md)** (80+ tools) — Full EDDI control from Claude Desktop, IDE plugins, or any MCP client
 - **[A2A Protocol](a2a-protocol.md)** — Agent-to-Agent peer communication with skill discovery
 - **[OpenAI-Compatible API](open-webui-integration.md)** — Deployed agents presented as OpenAI models for Open WebUI and OpenAI SDK clients
+- **SSE Streaming** — Token-by-token responses, including tool-enabled turns, plus a live `tool_call` event so clients can show "Using {tool}…" while the turn is still running
 
 ### 🧠 Intelligence & Memory
 

docs/build-reproducibility.md

@@ -11,7 +11,7 @@ This document describes what is and is not guaranteed about EDDI builds.
 | **Verifiable provenance** — you can prove a published image came from a specific commit of this repository | ✅ Guaranteed |
 | **Bit-for-bit reproducible artifacts** — two builds of the same commit produce byte-identical JARs | ❌ Not yet — see [Bit-for-bit reproducibility](#bit-for-bit-reproducibility) |
 
-The distinction matters. Deterministic dependency resolution means nobody can slip a different library into your build; it does **not** mean you can rebuild `eddi-6.2.0.jar` and compare its SHA-256 against ours. Verify published artifacts via the [signature and attestation](#verify-a-published-image), not by rebuilding.
+The distinction matters. Deterministic dependency resolution means nobody can slip a different library into your build; it does **not** mean you can rebuild `eddi-6.3.0.jar` and compare its SHA-256 against ours. Verify published artifacts via the [signature and attestation](#verify-a-published-image), not by rebuilding.
 
 ## Build System
 
@@ -78,21 +78,21 @@ Published Docker images are signed with [Sigstore Cosign](https://docs.sigstore.
 cosign verify \
   --certificate-oidc-issuer https://token.actions.githubusercontent.com \
   --certificate-identity-regexp '^https://github\.com/labsai/EDDI/\.github/workflows/ci\.yml@refs/(heads/main|tags/.+)$' \
-  labsai/eddi:6.2.0
+  labsai/eddi:6.3.0
 ```
 
 The identity regexp is the load-bearing part: it pins the signature to the `ci.yml` workflow on `main` or a tag, so a signature produced by any other workflow, branch, or repository fails verification.
 
 Once verified, resolve and pin the digest in your deployment manifests (`k8s/base/eddi-deployment.yaml`, or `eddi.image.digest` in the Helm chart) so the kubelet can never pull different bits under the same tag:
 
 ```bash
-crane digest labsai/eddi:6.2.0
+crane digest labsai/eddi:6.3.0
 ```
 
 ### Verify the build provenance
 
 ```bash
-gh attestation verify oci://docker.io/labsai/eddi:6.2.0 --repo labsai/EDDI
+gh attestation verify oci://docker.io/labsai/eddi:6.3.0 --repo labsai/EDDI
 ```
 
 ### SBOM

docs/changelog.md

@@ -1790,6 +1790,161 @@ rename arguably raises the stakes, since the config is now explicitly the canoni
 
 
 
+## 📘 docs(readme): sync both READMEs with what landed on main for 6.3.0 (2026-08-11)
+
+**Repo:** EDDI (`chore/eddi-version-6-3-0`)
+
+Audited `README.md` and `docs/README.md` against `origin/main` after merging 589 files of it into the
+release branch. Main had already swapped Agent Father for the **Platform Operator** in the root
+README (quick start, feature bullet, and the now-dead deep-dive doc row). Verified there is no
+surviving `Agent Father` / `agent-father` reference in either README, `SUMMARY.md` or `AGENTS.md`,
+that the `docs/agent-father-*.md` pages are gone, that `install.sh` no longer claims to deploy a
+starter agent, and that every relative doc link in both files still resolves.
+
+Two real gaps remained, both features main shipped that neither README mentioned:
+
+1. **`docs/README.md` never got the Platform Operator at all.** The root README names it twice; the
+   docs index still described orchestration as if the meta-agent did not exist. Added to *Multi-Agent
+   Orchestration* with the two real entry points (`/manage/operator`, `/manage/agents/wizard`) taken
+   from `getting-started.md` rather than invented. There is no dedicated operator page to link — a
+   gap worth closing separately.
+2. **Streaming was undersold in both.** Main shipped `ToolLoopStreamingChatModel` (tool-enabled turns
+   now stream token-by-token instead of going silent until the tool loop finishes) and a live
+   `tool_call` SSE event for "Using {tool}…" status. The root README's SSE row said only "real-time
+   chat responses"; the docs index listed no streaming at all under *Protocols & Interoperability*.
+   Both now say what actually happens. Verified in code first — `ToolLoopStreamingChatModel.java`,
+   `RestAgentEngineStreaming` emitting `event: tool_call`, and the `onToolCall` hook on
+   `ConversationEventSink` / `IConversationService.StreamingResponseHandler` — not from the changelog
+   alone.
+
+**Counts re-checked, none needed changing:** 84 entries in `McpToolFilter.MCP_TOOLS` against the
+"80+" floor; 14,645 test annotations against "14,000+"; 7 named `DiscussionStyle` values (`CUSTOM` is
+the eighth and correctly not counted as a preset style). These are deliberately floors, which is
+exactly why they survived a 589-file merge without edits.
+
+Deliberately unchanged: the "12 LLM Providers" figure (main added no provider; `docs/langchain.md`
+remains its source of truth) and `README.md:559`'s language-less code fence (pre-existing, nowhere
+near this edit).
+
+---
+
+
+## 🏷️ docs(release): the release guide told you to push a tag that triggers nothing (2026-08-11)
+
+**Repo:** EDDI (`chore/eddi-version-6-3-0`)
+
+`ci.yml` triggers on `tags: ["[0-9]*"]` — a release tag must start with a digit. `docs/release-
+versioning.md` instructed `git tag v6.0.0` in eight places, and `docs/release-signing.md` in three
+more. A `v`-prefixed tag matches that filter nowhere, and **GitHub reports no error for a tag that
+matches no workflow**: the push succeeds, and nothing runs. No build, no image, no `latest`, no
+cosign signature, no SLSA attestation, no GitHub release. Following the release guide verbatim
+produced a silent non-release — the worst failure shape available, since there is nothing red to
+notice.
+
+AGENTS.md §1 already documented the digit-prefixed rule, so the two release docs were the artefacts
+disagreeing with both the workflow and the rest of the documentation. Fixed in favour of the
+workflow, which is the executable truth.
+
+Three further claims were checked against `ci.yml` while in there, rather than assumed:
+
+1. **The tag→image table was wrong twice over.** It mapped "Git tag `v6.0.0`" → `labsai/eddi:6.0.0`,
+   but CI uses the tag name *verbatim* (`PRIMARY_TAG="${GITHUB_REF#refs/tags/}"`), so the `v` would
+   not be stripped even if the tag did fire. Both halves corrected.
+2. **The `6.3` and `6` moving aliases were undocumented.** CI publishes them for stable releases
+   only, gated on `^([0-9]+)\.([0-9]+)\.([0-9]+)$` so an RC never claims them. They are user-facing
+   — `helm/eddi/values.yaml` warns against deploying from the mutable major tag — yet the tag
+   strategy table listed neither. Added, with the "pin the patch version" guidance the k8s and Helm
+   manifests already follow.
+3. **The job table said docker runs on tag `v*`.** Same defect in a second spelling; now `[0-9]*`,
+   and it records that `[skip docker]` is ignored on tags.
+
+Also: the canonical-version line quoted `<version>6.0.0</version>` and had sat three releases stale,
+so it now names the `<version>` element and the `grep` CI actually uses instead of a number that
+rots. The running example moved to 6.3.0 throughout, the lifecycle diagram was realigned (its
+columns were already off by four before this change), and a pointer was added that `pom.xml` is not
+the only artefact carrying the release number.
+
+Verified no `v`-prefixed tag command survives anywhere in tracked files; the only remaining `v6.x`
+strings in these two pages are the warnings about the prefix itself.
+
+**Review follow-up (CodeRabbit on #671).** Three findings, all on this change; the one flagged Major
+("the release guide still contains a `v`-prefixed tag") was raised against the first push and the
+bot itself closed it as addressed once the fix landed. The two real ones were markdownlint
+regressions introduced by the new warning blocks: **MD028** in both files, where the added blockquote
+sat directly beside an existing one separated by a blank line (fixed with a `>` continuation, so each
+pair is one quote with two paragraphs rather than two quotes sharing a gap), and **MD040** on a fence
+inside the edited region. For MD040 the flagged fence was fixed along with the other five plain-text
+fences in `release-versioning.md` — tagging one and leaving five would trade a lint warning for an
+inconsistency in the same file. `release-signing.md`'s two bare fences (lines 30, 93) are deliberately
+left: pre-existing, outside this change, and not worth churning a file touched by two lines.
+
+---
+
+
+
+## 🔖 chore(release): bump EDDI version 6.2.0 → 6.3.0 (2026-08-11)
+
+**Repo:** EDDI (`chore/eddi-version-6-3-0`)
+
+Straight version bump across every artefact that carries the release number. The file set was taken
+from the two previous bumps (`c0835c98d` 6.1.0 → 6.2.0, `036faa32a` 6.0.2 → 6.1.0) rather than from
+a grep, so nothing that those touched is silently skipped:
+
+- **Build/runtime:** `pom.xml` `<version>`, `application.properties`
+  (`systemRuntime.projectVersion` — the value `BaseRuntime` and the `HttpClientWrapper` User-Agent
+  read at runtime — plus `smallrye-openapi.info-version` and `container-image.additional-tags`),
+  `OpenApiConfig` `@Info(version)`, and the `EDDI_VERSION` build arg backing the Red Hat
+  certification `version` label in the Dockerfile.
+- **Deployment:** `helm/eddi/Chart.yaml` `appVersion` (and the chart's own `version`, see below)
+  and `helm/eddi/values.yaml` `eddi.image.tag`,
+  `k8s/base/eddi-deployment.yaml` and `k8s/quickstart.yaml` (both the `app.kubernetes.io/version`
+  labels and the pinned `labsai/eddi:` tag, including the cosign/crane comment examples), and the
+  `redhat-certify.yml` workflow input default.
+- **Bundled agent:** `Agent+Father-6.2.0.zip` → `Agent+Father-6.3.0.zip` with the matching line in
+  `available_agents.txt`, which `RestImportService` reads to seed initial agents. Verified in
+  `target/classes` that the manifest still names a file that exists — a rename that desynchronises
+  those two fails at first startup, not at compile time.
+- **Docs:** only the two pages using the current tag in copy-pasteable commands
+  (`build-reproducibility.md`, `redhat-openshift.md`). The per-page `**Version:**` headers did not
+  need touching — the previous docs refresh replaced all twelve with a dynamic shields.io release
+  badge precisely so a bump would stop having to sweep them.
+
+**Deliberately left at 6.2.0:** `@since 6.2.0` Javadoc, the "pre-6.2.0"/"before 6.2.0"
+compatibility comments in `AgentOrchestrator`/`VertexGeminiLanguageModelBuilder`/
+`ConversationMemorySnapshot`, `*Since 6.2.0.*` in `httpcalls.md`, and the changelog. Those are
+historical minimum-version facts, not statements about the current release; rewriting them would
+assert that features shipped in 6.3.0 when they did not. Same reasoning the docs refresh used to
+keep `**Version: ≥6.0.0**` in `security.md` out of the dynamic-badge conversion.
+
+`docs/hitl.md` already referred to "the pre-6.3.0 behavior" for the
+`eddi.hitl.tool.task-approvals.mode` default flip, so 6.3.0 was already the assumed next release —
+that page is now consistent with the version the build actually reports.
+
+**The Helm chart's own `version` moved for the first time: 1.0.0 → 1.0.1.** It is not the app
+version — `appVersion` is — but Helm requires it to change whenever anything under `helm/` changes,
+and chart repositories key on it: two different chart contents published under `1.0.0` are
+indistinguishable to any cache or mirror. It had sat at 1.0.0 since the chart was created, through
+the 6.1.0 and 6.2.0 bumps, because nothing enforces it and nothing packages the chart today — which
+is the only reason the drift was harmless rather than a stale-chart bug waiting for the first
+`helm package`. A comment on the field now states the rule so it stops depending on someone
+remembering.
+
+**Verified rather than assumed**, since a bump that misses one artefact fails at release time:
+CI's own extractor (`grep -m1 '<version>' pom.xml`) returns 6.3.0; all five edited YAML files parse;
+and `target/classes` confirms `available_agents.txt` still names a zip that exists, which is the one
+way the rename could have broken startup without breaking the build. `./mvnw compile` green, no
+formatter drift.
+
+**Not introduced here, but found while checking and left alone:** `docs/release-versioning.md`
+instructs `git tag v6.0.0` in eight places, while `ci.yml` triggers on `tags: ["[0-9]*"]` — a
+`v`-prefixed tag matches nothing, so following that guide produces no build, no image, no signature
+and no release, silently. AGENTS.md already documents the digit-prefixed rule; the release guide is
+the artefact that is wrong. Tracked separately rather than folded into a version bump.
+
+---
+
+
+
 ## 🔢 docs(mcp): the MCP tool catalogue was eight tools short, and a count sweep of both READMEs (2026-08-11)
 
 **Repo:** EDDI (`docs/group-collaboration-refresh`)

docs/redhat-openshift.md

@@ -61,7 +61,7 @@ The certification release process is fully automated:
 
 To trigger a certification release, go to **Actions → Red Hat Certification Release → Run workflow** and provide:
 
-- `version` — EDDI version (e.g., `6.2.0`)
+- `version` — EDDI version (e.g., `6.3.0`)
 - `release` — Incremental release number (e.g., `1`, `2`, `3`)
 - `submit` — Whether to submit results to Red Hat (`true`/`false`)
 - `registry` — Target registry (`docker.io` or `quay.io`)
@@ -171,5 +171,5 @@ For production deployments with MongoDB:
 docker run -d \
   -p 7070:7070 \
   -e QUARKUS_MONGODB_CONNECTION_STRING=mongodb://mongo:27017 \
-  labsai/eddi:6.2.0
+  labsai/eddi:6.3.0
 ```

docs/release-signing.md

@@ -132,17 +132,22 @@ This outputs the full certificate chain and Rekor log entry as JSON.
 
 ## Git Tag Signing
 
-For version tags in the Git repository (e.g., `v6.0.0`, `v6.0.0-RC2`), maintainers sign tags using GPG or SSH keys:
+For version tags in the Git repository (e.g., `6.3.0`, `6.3.0-RC2`), maintainers sign tags using GPG or SSH keys:
 
 ```bash
 # Create a signed tag
-git tag -s v6.0.0 -m "Release 6.0.0"
-git push origin v6.0.0
+git tag -s 6.3.0 -m "Release 6.3.0"
+git push origin 6.3.0
 
 # Verify a signed tag
-git tag -v v6.0.0
+git tag -v 6.3.0
 ```
 
+> **Release tags carry no `v` prefix.** `ci.yml` triggers on `tags: ["[0-9]*"]`, so `v6.3.0` matches
+> nothing and silently runs no workflow — no build, no image, and none of the signing or attestation
+> described on this page. Signing the tag does not change that; a signed `v6.3.0` is just as inert.
+> See [Release & Versioning Strategy](release-versioning.md#version-format).
+>
 > **Note:** The primary release integrity guarantee is provided by the Docker image signing described above. Git tag signing provides an additional layer of assurance that the tag was created by an authorized maintainer.
 
 ---