Interactive DAG Visualization for Campaign Status: Real-Time Step & Agent Activity Indicators

[unclesp1d3r]

Summary

The campaign status page currently renders the attack dependency graph (DAG) as a static flowchart image. This feature replaces that static image with a dynamic, interactive visualization that communicates real-time execution state — which step is running, which agent is executing it, and the outcome of each completed step.

---

Background & Context

HashHive campaigns execute as a directed acyclic graph (DAG) of attack steps. Each step can depend on one or more upstream steps completing before it begins. Agents pick up and execute individual steps. Currently, users must infer execution progress from raw status fields in the UI; there is no visual representation of live campaign state mapped onto the graph structure.

This creates friction for operators monitoring long-running campaigns with many interdependent steps — they cannot quickly identify bottlenecks, failed paths, or which agents are active on which nodes.

---

Problem Statement

• The existing DAG image is static and does not reflect runtime state.
• Users cannot visually identify which steps are pending, running, succeeded, or failed.
• There is no indication of which agent is executing a given step.
• Operators must cross-reference multiple UI panels to get a full picture of campaign execution.

---

Proposed Solution

Replace the static DAG image with a live, interactive graph component (e.g., using a library such as React Flow or D3.js) that renders each attack step as a node and each dependency relationship as a directed edge.

Node Visual States

Each node should communicate its execution state via color, icon, and optionally animation:

State	Color	Icon	Animation
Pending	Gray	⏳ Clock	None
Running	Blue	▶ Play / Spinner	Pulsing border
Completed (success)	Green	✅ Check	None
Completed (with errors / partial)	Yellow/Amber	⚠️ Warning	None
Failed	Red	❌ X	None
Skipped	Light gray	⏭ Skip	None

Agent Indicators

• Each running node should display the avatar or short identifier of the agent currently executing it (e.g., agent hostname badge or icon).
• Hovering a node should reveal a tooltip with: step name, current state, assigned agent (if any), start time, and elapsed time.

Edge Rendering

• Satisfied dependency edges: solid line.
• Unsatisfied/blocked dependency edges: dashed line.
• Edges leading into a running node: animated dash to indicate active data flow.

Interactivity

• Nodes should be clickable, navigating to the relevant step detail view.
• The graph should auto-layout (top-to-bottom or left-to-right) using a DAG layout algorithm (e.g., Dagre).
• The visualization should poll or subscribe (WebSocket/SSE) for live state updates without requiring a full page reload.

---

Acceptance Criteria

• The campaign status page renders the attack DAG as an interactive graph (not a static image).
• Each node reflects its current execution state via color and icon (pending / running / success / failed / partial / skipped).
• Running nodes display the executing agent identifier.
• Edges visually distinguish satisfied vs. unsatisfied dependencies.
• State updates in near-real-time (polling interval ≤ 5s or via WebSocket/SSE).
• Hovering a node shows a tooltip with step name, state, agent, start time, and elapsed time.
• Nodes are clickable and navigate to the step detail view.
• Graph layout is deterministic and readable for campaigns with 20+ steps.
• No regressions to existing campaign status page functionality.

---

Technical Notes

• Evaluate React Flow vs. D3.js vs. Cytoscape.js for the graph renderer — React Flow preferred if the frontend is React-based.
• The DAG layout engine should be Dagre or ELK for hierarchical layout.
• Live update mechanism should align with whatever pattern the rest of the frontend uses (polling, WebSocket, or SSE).
• Agent identifier display should reuse existing agent avatar/badge components.
• Consider accessibility: ensure color is not the sole differentiator for state — pair with icons and ARIA labels.

---

References

• Existing campaign status page component
• Agent management: see agent / agent-management labels for related issues
• Campaign DAG data model

[unclesp1d3r]

@coderabbitai Enhance this issue body with additional context and a proposed solution. Improve the issue title and assign the proper labels and other metadata.

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Fetch issue details
gh issue view 211 --repo EvilBit-Labs/hash_hive --json title,body,labels,assignees,milestone,state,comments

echo "---LABELS---"
gh label list --repo EvilBit-Labs/hash_hive --json name,description,color | jq .

echo "---MILESTONES---"
gh api repos/EvilBit-Labs/hash_hive/milestones | jq '[.[] | {title, number, state}]'

Length of output: 5537

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

NEW_TITLE="Interactive DAG Visualization for Campaign Status: Real-Time Step & Agent Activity Indicators"

NEW_BODY='## Summary

The campaign status page currently renders the attack dependency graph (DAG) as a static flowchart image. This feature replaces that static image with a dynamic, interactive visualization that communicates real-time execution state — which step is running, which agent is executing it, and the outcome of each completed step.

---

## Background & Context

HashHive campaigns execute as a directed acyclic graph (DAG) of attack steps. Each step can depend on one or more upstream steps completing before it begins. Agents pick up and execute individual steps. Currently, users must infer execution progress from raw status fields in the UI; there is no visual representation of *live* campaign state mapped onto the graph structure.

This creates friction for operators monitoring long-running campaigns with many interdependent steps — they cannot quickly identify bottlenecks, failed paths, or which agents are active on which nodes.

---

## Problem Statement

- The existing DAG image is static and does not reflect runtime state.
- Users cannot visually identify which steps are pending, running, succeeded, or failed.
- There is no indication of which agent is executing a given step.
- Operators must cross-reference multiple UI panels to get a full picture of campaign execution.

---

## Proposed Solution

Replace the static DAG image with a live, interactive graph component (e.g., using a library such as [React Flow](https://reactflow.dev/) or [D3.js](https://d3js.org/)) that renders each attack step as a node and each dependency relationship as a directed edge.

### Node Visual States

Each node should communicate its execution state via **color**, **icon**, and optionally **animation**:

| State | Color | Icon | Animation |
|---|---|---|---|
| Pending | Gray | ⏳ Clock | None |
| Running | Blue | ▶ Play / Spinner | Pulsing border |
| Completed (success) | Green | ✅ Check | None |
| Completed (with errors / partial) | Yellow/Amber | ⚠️ Warning | None |
| Failed | Red | ❌ X | None |
| Skipped | Light gray | ⏭ Skip | None |

### Agent Indicators

- Each **running** node should display the avatar or short identifier of the agent currently executing it (e.g., agent hostname badge or icon).
- Hovering a node should reveal a tooltip with: step name, current state, assigned agent (if any), start time, and elapsed time.

### Edge Rendering

- Satisfied dependency edges: solid line.
- Unsatisfied/blocked dependency edges: dashed line.
- Edges leading into a running node: animated dash to indicate active data flow.

### Interactivity

- Nodes should be clickable, navigating to the relevant step detail view.
- The graph should auto-layout (top-to-bottom or left-to-right) using a DAG layout algorithm (e.g., Dagre).
- The visualization should poll or subscribe (WebSocket/SSE) for live state updates without requiring a full page reload.

---

## Acceptance Criteria

- [ ] The campaign status page renders the attack DAG as an interactive graph (not a static image).
- [ ] Each node reflects its current execution state via color and icon (pending / running / success / failed / partial / skipped).
- [ ] Running nodes display the executing agent identifier.
- [ ] Edges visually distinguish satisfied vs. unsatisfied dependencies.
- [ ] State updates in near-real-time (polling interval ≤ 5s or via WebSocket/SSE).
- [ ] Hovering a node shows a tooltip with step name, state, agent, start time, and elapsed time.
- [ ] Nodes are clickable and navigate to the step detail view.
- [ ] Graph layout is deterministic and readable for campaigns with 20+ steps.
- [ ] No regressions to existing campaign status page functionality.

---

## Technical Notes

- Evaluate React Flow vs. D3.js vs. Cytoscape.js for the graph renderer — React Flow preferred if the frontend is React-based.
- The DAG layout engine should be Dagre or ELK for hierarchical layout.
- Live update mechanism should align with whatever pattern the rest of the frontend uses (polling, WebSocket, or SSE).
- Agent identifier display should reuse existing agent avatar/badge components.
- Consider accessibility: ensure color is not the sole differentiator for state — pair with icons and ARIA labels.

---

## References

- Existing campaign status page component
- Agent management: see `agent` / `agent-management` labels for related issues
- Campaign DAG data model'

# Update title and body
gh issue edit 211 \
  --repo EvilBit-Labs/hash_hive \
  --title "$NEW_TITLE" \
  --body "$NEW_BODY"

# Add labels
gh issue edit 211 \
  --repo EvilBit-Labs/hash_hive \
  --add-label "frontend,campaign-management"

echo "Done."

Length of output: 4929

---

---

@unclesp1d3r, issue #211 has been updated. Here's a summary of what changed:

Title:

Interactive DAG Visualization for Campaign Status: Real-Time Step & Agent Activity Indicators

Body additions:

• Background & Context — explains the current static image limitation and operator pain point
• Problem Statement — explicit bullet list of gaps
• Proposed Solution — interactive graph component (React Flow / D3.js / Cytoscape.js), full node state table (Pending/Running/Success/Failed/Partial/Skipped) with colors, icons, and animations, agent indicator spec, edge rendering rules, and interactivity requirements
• Acceptance Criteria — 9 checkboxes covering all key behaviors including real-time updates (≤5s poll or WebSocket/SSE), accessibility, and layout determinism for 20+ step campaigns
• Technical Notes — library recommendations, Dagre/ELK layout, live update pattern alignment, accessibility guidance

Labels added: frontend, campaign-management (existing labels retained)