dsh-voredteam: An Auditable Security Battle System for DeepSeek Harness

What Does It Do?

dsh-voredteam is a DSH plugin for DeepSeek Harness that turns an authorized penetration test into an auditable state-space search. It solves the typical failure mode of LLM-driven security testing: the model runs eagerly but cannot say what was actually tested, retries the same surface, and delivers conclusions built on guesswork. The plugin records facts and intents on a blackboard, follows a six-stage methodology with six check matrices, and splits work between a controller that reasons and 12 specialist sub-agents that explore. Its only hard gate is no DDoS, no brute force, and low-frequency fuzzing only.

Core Features

• Blackboard data layer: organizes work around Fact (confirmed findings), Intent (an edge in the graph awaiting exploration), and Hint (human-provided scope, credentials, and exclusions), with assets, check matrices, and untested surfaces all persisted and the graph kept append-only.
• Six-stage methodology: runs from P1 starting-point collection through P2 information gathering, P3 shallow, P4 middle, P5 deep, and P6 results, verifying the previous layer before working on the current one; phase gates refuse to advance and list the gaps instead.
• Six check matrices: info, verifyInfo, shallow, verifyShallow, owasp, and deep record conclusions and evidence item by item; na, wrong, and unknown require a written reason, hit requires evidence, and untested surfaces must state why.
• Controller plus 12 specialist sub-agents: the controller reasons while recon, js-reverse, api-security, web-injection, auth-logic and others explore their domains, with a separate review sub-agent confirming or challenging vulnerability facts.
• Battle panel: an eight-lane real-time graph, coverage matrix, and per-session views show who is testing which surface, how far it has gone, and what remains untested.
• Reflow and auditable downgrade: any new asset found at any stage reopens gaps across all six matrices and sends the phase back to P1, while low-priority assets can only be exempted with a written justification at registration time.

How to Use This Plugin?

After enabling it in DSH, the plugin runs in a single Network Security mode, where one session equals one project and the session is the only project boundary. You can supply scope, credentials, and exclusions as Hints in the conversation, and the controller absorbs them each time it reads the graph; hints can also be written directly on the panel. During work, every turn's system prompt injects the current phase, the percentages of all six matrices, untested-surface declaration status, review progress, unclaimed intents, and recent facts, so the model does not have to remember anything. Open the battle panel to track progress through the eight-lane graph and coverage matrix by session. To finish, wait until gaps are cleared, untested surfaces are declared, and every vulnerability fact has passed review, and the plugin produces a report with an evidence index.

How to Troubleshoot This Plugin?

A phase that will not advance usually means a phase gate is unmet; the plugin refuses to move forward and lists the specific gaps, so fill in the corresponding matrix items. Rejected matrix entries are usually non-compliant reasons or evidence: na, wrong, and unknown need a sufficiently long reason, hit needs attached evidence, and untested surfaces must explain why they were not or could not be done. If a newly found asset sends the phase back to P1, that is the normal reflow mechanism, and it stays sealed until a round confirms zero new additions. Older databases migrate automatically on startup, including backfilling origin and goal for ghost projects and rewriting the five-stage scheme into six stages; if migration fails, repair it according to the official instructions.