The pitch
As a red-team operator, I want one local engine to manage modules, providers, Mesh operations, workspace PKI, throws, events, artifacts, installed payloads, and sessions.
As an exploit developer or module author, I want a clear descriptor and testable runtime contract so third-party capabilities are easy to build, inspect, and operate safely.
What is here
Hovel is a platform for wrapping and operating third-party proofs of concept, not a catalog of first-party exploits. The project provides the engine, SDKs, descriptors, providers, strongly typed credential delivery, guardrails, examples, installed-payload inventory, and operator experience that make third-party modules acceptable to run and inspect.
The central runtime is a local engine, hoveld, which owns
operations, chains, throws, module processes, provider-backed payload
state, Mesh listeners and bridges, encrypted PKI custody, installed
payload records, sessions, events, artifacts, and workspace storage.
Interactive cli mode, one-shot chain-file
execution, and the MCP agent front end are implemented clients over the
same application services. hovel tui is an explicit
not-implemented role. The daemon publishes a stable OpenAPI-described
local HTTP/JSON contract; a remotely authenticated REST deployment,
general managed-service processes, and richer MCP resources and prompts
remain future work.
Start here
Build it
Everything goes through Task — the single entry point. Run task --list to see all commands.
task checkout:status
task check # available-slice gate for partial checkouts
task build
task test
task ci # full-checkout guard plus wired core gate