How n1neman/sapper-v2 works
sapper is an autonomous, multi-agent penetration-testing harness for authorized competition arenas. Its workflow is to maintain a shared fact-and-intent graph, propose and dispatch work, have agents investigate in parallel, and record results; arena operations bridge challenge lifecycle and flag submission to the competition platform. The sampled core is largely a single CLI module, with separate hook, arena-client, and knowledge-base modules. The README documents broader legion roles and tmux coordination, but those runtime implementations were not sampled, so those links are documented rather than inferred from unsampled code.
Main entry points: sapper.py Sapper CLI · commander Agent Legion · sapper-hook.py Claude Hook Bridge · arena.py Arena Bridge
Components 12
Work Coordination
- Sapper CLI
lib/sapper.py - Work Dispatch
lib/sapper.py - Agent Legion
docker/commander - Watchdog
docker/commander/watchdog.sh
Shared Memory
- Fact-Intent Graph
lib/sapper.py - Claude Hook Bridge
lib/sapper-hook.py - Offline Knowledge Base
lib/kb.py
Arena Operations
- Arena Bridge
lib/arena.py
Other components
- Operator
- Competition Platform
- Claude Code
- tmux
Connections 13
- Operator → Sapper CLI: runs commands
README.md - Sapper CLI → Fact-Intent Graph: updates graph
lib/sapper.py - Sapper CLI → Work Dispatch: starts dispatch
lib/sapper.py - Work Dispatch → Fact-Intent Graph: reads frontier
lib/sapper.py - Work Dispatch → Agent Legion: assigns work
README.md - Agent Legion → Fact-Intent Graph: records findings
README.md - Watchdog → Agent Legion: keeps alive
README.md - Claude Hook Bridge → Fact-Intent Graph: renders context
lib/sapper-hook.py - Claude Code → Claude Hook Bridge: invokes events
lib/sapper-hook.py - Sapper CLI → Arena Bridge: loads client
lib/sapper.py - Arena Bridge → Competition Platform: calls API
lib/arena.py - Agent Legion → tmux: uses sessions
README.md - Sapper CLI → Offline Knowledge Base