aden-hive/hive

Description: While auditing the Hive Core v0.7.1 for "Complex Business Process" readiness, I identified a systemic race condition in the SharedStateManager. Under high concurrency (parallel tool execution), the current architecture suffers from a "Read-Clobber-Write" failure. Forensic testing on the latest main branch confirms a 90% data loss rate (50/500 updates recorded). This represents a scaling wall for any asynchronous, durable business logic. Reproduction Steps: I have isolated the failure in a 60-line biopsy script. It imports the production SharedStateManager and simulates 10 concurrent agents updating a shared counter. from pathlib import Path import importlib import sys root_path = Path(file).resolve().parent.parent.parent if str(root_path) not in sys.path: sys.path.insert(0, str(root_path)) target_file = root_path / "core" / "framework" / "runtime" / "shared_state.py" spec = importlib.util.spec_from_file_location("shared_state_module", target_file) shared_state = importlib

Summary Wire a NodeEvaluator protocol into GraphExecutor.execute() so every node produces a structured EvalReport (faithfulness, relevance, completeness, cost_efficiency, weak_dimensions) alongside its NodeResult. This completes work already started in DecisionEvaluation (core/framework/schemas/decision.py:80–107) and fills the gap left by the binary-only LLMJudge (core/framework/testing/llm_judge.py:16–139). Zero breaking changes. Current State (audit findings) Gap 1 — DecisionEvaluation has float scores but is never called during execution. core/framework/schemas/decision.py:80–107 already defines: alignment_score: float # 0.0–1.0 outcome_quality: float # 0.0–1.0 contributed_to_success: bool | None These fields are attached to Decision objects and populated post-hoc only. Nothing in executor.py or event_loop_node.py calls them. The scoring infrastructure exists; the execution-time hook does not. Gap 2 — LLMJudge is binary and lives in testing/. core/framewor

Hi Hive team, I recently installed and evaluated Hive on a Hetzner CPX62 VPS (16 vCPU, 32GB RAM, Ubuntu, Docker) as part of testing autonomous agent frameworks for a real business workflow. Test case: Client research pipeline — given a company name and industry, search recent news, identify competitors, analyze brand positioning, generate a 1-page intelligence brief. What I found: The concept is genuinely compelling. Goal-driven agent graphs with self-healing is exactly the kind of architecture production workflows need. The Queen agent setup is intuitive and the parallel execution design is well thought out. However, the execution has critical issues: Self-healing loops burn API credits — when a branch fails, the Queen retries indefinitely without a hard limit or escalation path. A single failed pipeline run cost meaningful Anthropic API spend with zero output. No provider settings UI — the dashboard has no visible provider configuration panel. The only path to set API keys was

Problem Statement There is currently no way to observe agent execution in real-time from the web dashboard. The core/framework/monitoring/ directory is empty (only init.py), even though CONTRIBUTING.md (lines 596-598) describes a monitoring dashboard that should show active agents, tool calls, token usage, and errors at /monitor. Users have to rely on terminal logs or debug event files (HIVE_DEBUG_EVENTS=1) to understand what their agents are doing. This makes it frustrating to: Monitor multiple agents running simultaneously Detect stalled nodes or tool doom loops before they cause failures Track token usage and costs across sessions Distinguish between clean, degraded, and failed executions Identify which nodes are retrying excessively Ex. I'm always frustrated when [...] Proposed Solution Build a real-time monitoring dashboard that subscribes to the existing EventBus infrastructure and surfaces metrics through a new /monitor page. Backend: MonitoringAggregator class that subscribes t

Problem Statement During testing, I gave the Queen Bee a simple natural-language input — a company name — and asked it to research that company’s competitive landscape. Without any confirmation step, it immediately committed to a full multi-node workflow and produced a detailed report for the wrong company. I had typed “Aden,” intending the AI agent framework I was testing, but the system selected Aden Group, a Singapore-based facilities management company, and spent 10–15 minutes producing a thorough analysis for the wrong target. When I corrected it and named the intended company, it re-executed immediately without asking any clarifying question and consumed the remaining API quota on a retry that produced no output. This does not feel like an edge case; it feels like a predictable failure mode of a system that commits to execution before validating what the user actually meant, whether the task warrants a full workflow, or whether the current tools/providers can realisti