feat: EDDI 6.2.0 release

.claude/workflows/feature-pipeline.js

@@ -0,0 +1,128 @@
+export const meta = {
+  name: 'feature-pipeline',
+  description: 'Explore -> plan/decompose -> parallel worktree implementers -> merge -> high-effort review',
+  whenToUse: 'Use for a substantial coding task that can be split into independent workstreams. Runs three explorers, a planner that decomposes the task, one implementer per workstream in its own git worktree, a merge step that combines the branches, and a final high-effort review. Does NOT open a PR — review the result and push/PR yourself.',
+  phases: [
+    { title: 'Explore' },
+    { title: 'Plan' },
+    { title: 'Implement' },
+    { title: 'Merge' },
+    { title: 'Review' },
+  ],
+}
+
+const PLAN_SCHEMA = {
+  type: 'object',
+  properties: {
+    workstreams: {
+      type: 'array',
+      items: {
+        type: 'object',
+        properties: {
+          id: { type: 'string' },
+          title: { type: 'string' },
+          instructions: { type: 'string' },
+        },
+        required: ['id', 'title', 'instructions'],
+      },
+    },
+  },
+  required: ['workstreams'],
+}
+
+const IMPLEMENT_SCHEMA = {
+  type: 'object',
+  properties: {
+    workstream_id: { type: 'string' },
+    branch: { type: 'string' },
+    worktree_path: { type: 'string' },
+    summary: { type: 'string' },
+    filesChanged: { type: 'array', items: { type: 'string' } },
+  },
+  required: ['workstream_id', 'branch', 'worktree_path', 'summary'],
+}
+
+const MERGE_SCHEMA = {
+  type: 'object',
+  properties: {
+    integrationBranch: { type: 'string' },
+    merged: { type: 'array', items: { type: 'string' } },
+    conflicts: { type: 'array', items: { type: 'string' } },
+    notes: { type: 'string' },
+  },
+  required: ['integrationBranch', 'merged', 'conflicts'],
+}
+
+const REVIEW_SCHEMA = {
+  type: 'object',
+  properties: {
+    findings: {
+      type: 'array',
+      items: {
+        type: 'object',
+        properties: {
+          file: { type: 'string' },
+          summary: { type: 'string' },
+          severity: { type: 'string' },
+        },
+        required: ['file', 'summary'],
+      },
+    },
+    verdict: { type: 'string' },
+  },
+  required: ['findings', 'verdict'],
+}
+
+if (!args || !args.task) {
+  throw new Error('feature-pipeline requires args.task — a description of the coding task to implement')
+}
+
+phase('Explore')
+const explorations = (await parallel([
+  () => agent(
+    `Explore the codebase to understand everything relevant to this task: ${args.task}. Report the key files, patterns, and conventions to follow. Be concrete with file paths.`,
+    { agentType: 'Explore', label: 'explore:general' }
+  ),
+  () => agent(
+    `Explore the codebase specifically for existing tests and test conventions relevant to: ${args.task}`,
+    { agentType: 'Explore', label: 'explore:tests' }
+  ),
+  () => agent(
+    `Explore the codebase for existing features/patterns similar to: ${args.task}. We want to follow existing conventions, not invent new ones.`,
+    { agentType: 'Explore', label: 'explore:conventions' }
+  ),
+])).filter(Boolean)
+
+phase('Plan')
+const plan = await agent(
+  `You are planning implementation of this task:\n\n${args.task}\n\nHere is what exploration agents found:\n\n${explorations.join('\n\n---\n\n')}\n\nDecompose the task into 2-4 INDEPENDENT workstreams that can be implemented in parallel by different engineers without touching the same files or blocking on each other. If the task is small/atomic and cannot be meaningfully split, return a single workstream. For each workstream give a clear id, title, and precise instructions (files to touch, what to build, acceptance criteria, project conventions to follow).`,
+  { schema: PLAN_SCHEMA, effort: 'high', label: 'plan' }
+)
+
+log(`Planned ${plan.workstreams.length} workstream(s): ${plan.workstreams.map(w => w.title).join(', ')}`)
+
+phase('Implement')
+const implementations = (await parallel(plan.workstreams.map(w => () =>
+  agent(
+    `Implement this workstream as part of a larger task. Follow this project's AGENTS.md/CLAUDE.md conventions.\n\nWorkstream: ${w.title}\nInstructions: ${w.instructions}\n\nFull task context: ${args.task}\n\nWork ONLY within the scope of this workstream so it can be merged independently. Commit your changes with a conventional commit message when done. After committing, report the exact current branch name (git branch --show-current) and the absolute worktree path (git rev-parse --show-toplevel).`,
+    { isolation: 'worktree', schema: IMPLEMENT_SCHEMA, label: `implement:${w.id}`, phase: 'Implement' }
+  ).then(r => r && ({ ...r, workstream: w }))
+))).filter(Boolean)
+
+if (!implementations.length) {
+  return { error: 'No workstream produced a result', plan }
+}
+
+phase('Merge')
+const mergeResult = await agent(
+  `Merge these independently-implemented git branches together into one integration branch, in THIS repo checkout (not a worktree).\n\nSteps:\n1. Create a new branch off the current HEAD named integration/<short-task-slug>.\n2. For each branch below, run 'git merge --no-ff <branch>'.\n3. If a merge conflict occurs, resolve it by reading both sides' intent (described below) and combining them correctly — do not blindly take one side. If truly unresolvable, abort that merge (git merge --abort) and report it as an unresolved conflict rather than leaving the repo broken.\n4. Report the integration branch name, which branches merged cleanly, and which had conflicts.\n\nBranches to merge:\n${implementations.map(i => `- ${i.branch} (${i.workstream.title}): ${i.summary}`).join('\n')}`,
+  { schema: MERGE_SCHEMA, label: 'merge', effort: 'high' }
+)
+
+phase('Review')
+const review = await agent(
+  `Review branch '${mergeResult.integrationBranch}' against the base branch it diverged from. Task being implemented: ${args.task}. Look for correctness bugs, integration issues between the merged workstreams (mismatched interfaces, duplicated logic, missed wiring), and violations of this project's AGENTS.md/CLAUDE.md conventions. Report findings ranked by severity, most severe first, and give an overall verdict: 'ready', 'needs_fixes', or 'blocked'.`,
+  { schema: REVIEW_SCHEMA, effort: 'max', label: 'review' }
+)
+
+return { plan, implementations, merge: mergeResult, review }

.github/workflows/redhat-certify.yml

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

AGENTS.md

@@ -152,7 +152,7 @@ Follow this order unless the user explicitly requests something different.
 | —     | GDPR/CCPA Framework      | Cascading erasure, data portability, Art. 18 restriction, per-category retention                    |
 | —     | Commit Flags             | Strict write discipline for memory — uncommit failed task data, error digest injection              |
 | —     | Template Preview         | REST endpoint for previewing resolved system prompts with sample/live data                          |
-| —     | Test Coverage            | 9,000+ tests, >90% instruction / >80% branch coverage, OpenSSF Gold compliance                     |
+| —     | Test Coverage            | 11,000+ tests, >90% instruction / >80% branch coverage, OpenSSF Gold compliance                     |
 | —     | Security Hardening v6.0.2 | SSRF prevention, SafeHttpClient, auth guard, vault salt, security headers, CodeQL + Trivy CI       |
 | 9b    | HITL Framework           | Two human-approval gates (turn-level `PAUSE_CONVERSATION` + per-tool-call gating), timeout/no-progress policies, audit ledger, Slack + MCP approval surfaces, crash recovery — see [`docs/hitl.md`](docs/hitl.md) |
 

README.md

@@ -4,7 +4,7 @@
 
 [![OpenSSF Best Practices](https://www.bestpractices.dev/projects/12355/badge?v=2)](https://www.bestpractices.dev/projects/12355) [![OpenSSF Scorecard](https://api.securityscorecards.dev/projects/github.com/labsai/EDDI/badge)](https://securityscorecards.dev/viewer/?uri=github.com/labsai/EDDI) [![Codacy Badge](https://app.codacy.com/project/badge/Grade/2c5d183d4bd24dbaa77427cfbf5d4074)](https://app.codacy.com/organizations/gh/labsai/dashboard?utm_source=github.com&utm_medium=referral&utm_content=labsai/EDDI&utm_campaign=Badge_Grade)
 
-[![CI](https://github.com/labsai/EDDI/actions/workflows/ci.yml/badge.svg)](https://github.com/labsai/EDDI/actions/workflows/ci.yml) [![CodeQL](https://github.com/labsai/EDDI/actions/workflows/codeql.yml/badge.svg)](https://github.com/labsai/EDDI/actions/workflows/codeql.yml) ![Tests](https://img.shields.io/badge/tests-9%2C000%2B-brightgreen) ![Coverage](https://img.shields.io/badge/coverage-%3E90%25-brightgreen)
+[![CI](https://github.com/labsai/EDDI/actions/workflows/ci.yml/badge.svg)](https://github.com/labsai/EDDI/actions/workflows/ci.yml) [![CodeQL](https://github.com/labsai/EDDI/actions/workflows/codeql.yml/badge.svg)](https://github.com/labsai/EDDI/actions/workflows/codeql.yml) ![Tests](https://img.shields.io/badge/tests-11%2C000%2B-brightgreen) ![Coverage](https://img.shields.io/badge/coverage-%3E90%25-brightgreen)
 
 [![Docker Pulls](https://img.shields.io/docker/pulls/labsai/eddi)](https://hub.docker.com/r/labsai/eddi) [![Latest Release](https://img.shields.io/github/v/release/labsai/EDDI?label=latest&color=blue)](https://github.com/labsai/EDDI/releases) [![Repository: AI Ready](https://img.shields.io/badge/Repository-AI_Ready-blueviolet?logo=robot)](AGENTS.md)
 
@@ -249,6 +249,7 @@ Most multi-agent frameworks (LangGraph, CrewAI, AutoGen) are Python/Node librari
 
 - 🔀 **Intelligent Routing** — Direct conversations to different agents based on context, rules, and intent
 - 🗣️ **Group Conversations** — Multi-agent debates with 6 built-in discussion styles: Round Table, Peer Review, Devil's Advocate, Delphi, Debate, and Task Force
+- 🔄 **Follow-up & Continue** — After a group discussion completes, follow up with any specific member agent or continue all phases with a new question — agents retain full context across rounds
 - 💬 **Slack Integration** — Deploy agents to Slack channels and run multi-agent debates directly in threads
 - 🪆 **Nested Groups** — Compose groups of groups for tournament brackets, red-team vs blue-team, and panel reviews
 - 🤖 **Dynamic Agents** — Create, recruit, and delegate to new agents at runtime during group discussions with configurable guardrails
@@ -265,6 +266,11 @@ Most multi-agent frameworks (LangGraph, CrewAI, AutoGen) are Python/Node librari
 | **Self-Hosted**      | Ollama · Jlama · Hugging Face                                         |
 | **Compatible**       | Any OpenAI-compatible endpoint (DeepSeek, Cohere, etc.) via `baseUrl` |
 
+- 🔀 **Multi-Model Cascading** — Start with cheap/fast models, escalate to powerful ones based on confidence ([details](#-smart-model-cascading))
+- 📋 **JSON Response Mode** — `jsonResponseFormat` policy (`auto` | `on` | `off`) negotiates structured JSON output across all execution paths with provider-aware rules
+- 🔧 **Tool Calling** — Native function/tool calling across all providers that support it
+- 🗄️ **Tool Result Caching** — Per-tool cache scoping (`GLOBAL`, `USER`, `CONVERSATION`) to avoid redundant calls; fail-safe to `USER` on misconfiguration
+
 ### 🔗 Standards & Interoperability
 
 EDDI implements open standards — not proprietary APIs:
@@ -286,12 +292,13 @@ EDDI implements open standards — not proprietary APIs:
 - 📝 **Rolling Summary** — Incremental LLM-powered summarization of older turns with a **Conversation Recall Tool** for drill-back into compressed history
 - 🔧 **Property Extraction** — Config-driven slot-filling with `longTerm` / `conversation` / `step` scoping — EDDI's importance extraction mechanism
 - 🛡️ **Memory Policy (Commit Flags)** — Strict write discipline marks failed task output as uncommitted (hidden from LLM context) and injects concise error digests for graceful degradation
+- 🧹 **Tool Context Ceiling** — `maxToolContextTokens` caps tool output within a single turn (default 60k tokens), evicting oldest tool exchanges to prevent provider context-window errors while preserving tool-call pairing
 - 🔄 **Conversation State** — Full history with undo/redo support
 
 ### 📚 RAG (Retrieval-Augmented Generation)
 
 - 📦 **7 Embedding Providers** — OpenAI, Ollama, Azure OpenAI, Mistral, Bedrock, Cohere, Vertex AI
-- 🗄️ **5 Vector Stores** — pgvector, In-Memory, MongoDB Atlas, Elasticsearch, Qdrant
+- 🗄️ **6 Vector Stores** — pgvector, Chroma, In-Memory, MongoDB Atlas, Elasticsearch, Qdrant
 - 🌐 **httpCall RAG** — Zero-infrastructure RAG via any search API (BM25, Elasticsearch, custom)
 - 📥 **REST Ingestion API** — Async document ingestion with status tracking
 
@@ -310,6 +317,17 @@ EDDI implements open standards — not proprietary APIs:
 | 🔙 **Conversation Recall**                     | Drill back into summarized conversation history                               |
 | 📎 **Multimodal Attachments**                  | Image, PDF, audio, and video input with MIME-based routing                    |
 
+### 📎 Multimodal Attachments
+
+- 📤 **3 Input Paths** — URL reference, base64 inline, or file upload (`POST /conversations/{id}/attachments` with multipart/form-data)
+- 🗄️ **DB-Agnostic Storage** — GridFS (MongoDB) or bytea (PostgreSQL) via `IAttachmentStore` SPI with grant-based access control and per-tenant quotas
+- 📄 **Hybrid PDF Extraction** — PDFs are auto-extracted to text (shared `AttachmentTextExtractor`) and forwarded as inline context to any LLM, not just vision models
+- 🔍 **readAttachment Tool** — Agents can recall attachments from earlier turns in multi-turn conversations
+- 🧠 **Model Capability Gating** — `ModelCapabilityService` routes images to vision-capable LLMs and falls back to text metadata for others
+- 🔀 **Content-Type Routing** — `contentTypeMatcher` behavior rule condition routes `image/*`, `application/pdf`, etc. to different workflows
+- 👥 **Group Parity** — Attachments fan out with grant injection so group member agents can access the original user's files
+- 🗑️ **GDPR Cleanup** — `deleteByConversation()` cascades to attachment storage when conversations are erased
+
 ### ⏰ Scheduled Execution & Heartbeats
 
 - 🫀 **Heartbeat Triggers** — Periodic agent wake-ups at configurable intervals for proactive behavior (inspired by [OpenClaw's](https://openclaw.ai) heartbeat architecture)
@@ -324,6 +342,18 @@ EDDI implements open standards — not proprietary APIs:
 - 📊 **4 Confidence Strategies** — Structured output, heuristic, judge model, or none
 - 💰 **Per-Conversation Budgets** — Automatic cost tracking with budget caps and eviction
 - 🏢 **Tenant Cost Ceilings** — Monthly cost budgets per tenant with automatic enforcement
+- 🔢 **Tenant Agent Quotas** — `maxAgentsPerTenant` enforcement on agent deployment
+
+### ✋ Human-in-the-Loop Governance
+
+- 🚦 **Turn-Level Approval** — `PAUSE_CONVERSATION` action halts the entire pipeline; new user input returns `409 Conflict` until a human resumes
+- 🔧 **Per-Tool-Call Gating** — Individual tool invocations can require human approval before execution, with glob-pattern allow/exempt lists across built-in, HTTP, MCP, A2A, dynamic, and memory tools
+- 👥 **Group Phase Approval** — Multi-agent discussion phases can require human sign-off at `PHASE` or `TASK` granularity
+- ⏱️ **Timeout Policies** — `WAIT_INDEFINITELY`, `AUTO_APPROVE`, `AUTO_REJECT`, or `ABORT` when humans don't respond in time
+- 🔁 **No-Progress Guard** — Detects infinite approval loops (identical pause fingerprints after automated decisions) and breaks the cycle
+- 💬 **Slack Approvals** — Interactive Block Kit cards with redacted argument previews and approver whitelists
+- 🔌 **MCP Approvals** — External clients can list pending approvals and approve/reject via MCP tools
+- 🔄 **Crash Recovery** — Pending approvals survive server restarts; timeout timers are re-armed automatically
 
 ### 🔐 Enterprise Security & Compliance
 
@@ -376,6 +406,7 @@ EDDI implements open standards — not proprietary APIs:
 - 🔭 **OpenTelemetry Tracing** — Per-task distributed traces via OTLP (Jaeger, Tempo, Datadog). Every pipeline task emits spans with `task.id`, `task.type`, `conversation.id`, and `agent.id`
 - 🩺 **Health Checks** — Liveness & readiness probes at `/q/health/live` and `/q/health/ready`
 - 🔄 **NATS JetStream** — Async event bus for distributed processing
+- 🛟 **Error Handling & Recovery** — Automatic retry with exponential backoff, MCP circuit breakers (3 failures / 60s cooldown), LLM response validation (`onEmpty` / `onTruncation` / `onRefusal`), streaming timeout retry, and admin endpoint to reset stuck conversations
 - ⚡ **Virtual Threads** — Java 25 virtual threads for true OS-level concurrency (no Python GIL or Node.js event loop bottleneck)
 - 🗃️ **DB-Agnostic** — Choose MongoDB or PostgreSQL; switch with one env var. Single Docker image for both
 - 🏗️ **Red Hat Certified** — Container certification with automated preflight checks in CI/CD
@@ -411,6 +442,7 @@ EDDI implements open standards — not proprietary APIs:
 | **[User Memory](docs/user-memory.md)**                       | Cross-conversation fact retention                  |
 | **[Memory Policy](docs/memory-policy.md)**                   | Commit flags and strict write discipline            |
 | **[Model Cascading](docs/model-cascade.md)**                 | Cost-optimized multi-model routing                 |
+| **[Human-in-the-Loop](docs/hitl.md)**                        | Approval gates, timeout policies, Slack & MCP surfaces |
 | **[Scheduling & Heartbeats](docs/scheduling.md)**            | Cron schedules, heartbeats, dream consolidation    |
 | **[Agent Sync](docs/agent-sync-guide.md)**                   | Live instance-to-instance sync and upgrade imports |
 | **[Import / Export](docs/import-export-an-agent.md)**        | ZIP-based agent portability and merge              |

docs/agent-father-deep-dive.md

@@ -1,6 +1,6 @@
 # The Agent Father: A Deep Dive
 
-**Version: 6.0.0**
+**Version: 6.2.0**
 
 ## Overview
 

docs/agent-father-langchain-tools-guide.md

@@ -386,5 +386,5 @@ When Agent Father creates the langchain configuration, it generates:
 ---
 
 **Last Updated:** March 2026  
-**EDDI Version:** 6.0.0  
+**EDDI Version:** 6.2.0  
 **Agent Father Version:** 3.0.1

docs/agent-manager-gui.md

@@ -1,6 +1,6 @@
 # Agent Manager Dashboard
 
-**Version: 6.0.0**
+**Version: 6.2.0**
 
 ## Overview
 

docs/architecture.md

@@ -1,6 +1,6 @@
 # EDDI Architecture
 
-**Version: 6.1.2**
+**Version: 6.2.0**
 
 This document provides a comprehensive overview of EDDI's architecture, design principles, and internal workflow.