Autonomous software maintenance that stays visible, reviewable, and trustworthy.
PatchHive is a software maintenance platform for teams that want codebase upkeep to become visible, reviewable, and progressively automated.
It is not another interactive coding assistant. PatchHive is built around autonomous, outbound contribution: it finds maintenance work, evaluates risk, remembers repo-specific lessons, and can open clearly attributed pull requests when the operator allows it.
PatchHive turns maintenance from a pile of scattered signals into an operating loop:
- Detect maintenance pressure before it becomes urgent.
- Review risk before automation touches code.
- Remember conventions, failures, and reviewer feedback across runs.
- Generate patches only after the signal and trust layers are in place.
- Coordinate the suite through one control plane without making products dependent on it.
Every product remains standalone. HiveCore brings them together into one interface.
| Product | Role |
|---|---|
| SignalHive | Finds stale work, duplicate issues, recurring bug patterns, TODO/FIXME hotspots, and maintenance drag. |
| TrustGate | Reviews diffs against repo-specific safety rules and returns safe, warn, or block. |
| RepoMemory | Stores durable repo conventions, review feedback, hotspot history, and failure lessons. |
| FailGuard | Cross-cutting RepoMemory capability that turns bad outcomes into future guardrails. |
| RepoReaper | Finds fixable issues, generates patches, validates them, and opens attributed pull requests. |
| ReviewBee | Converts PR review threads into an actionable follow-up checklist. |
| MergeKeeper | Decides whether a PR is actually ready to merge, blocked, or on hold. |
| FlakeSting | Detects flaky CI behavior and explains why the signal is unstable. |
| DepTriage | Ranks dependency update noise by urgency and practical impact. |
| VulnTriage | Turns security alerts into an engineering queue with clear next steps. |
| RefactorScout | Surfaces conservative, high-value refactor opportunities. |
| HiveCore | Centralizes suite visibility, shared defaults, run history, and product launch control. |
| Layer | Products | What They Contribute |
|---|---|---|
| Discovery and signals | SignalHive, FlakeSting, DepTriage, VulnTriage, RefactorScout, ReviewBee | Surface maintenance pressure from issues, CI, dependencies, security alerts, refactor candidates, and PR review threads. |
| Trust and memory | TrustGate, RepoMemory, FailGuard, MergeKeeper | Evaluate risk, preserve repo-specific lessons, convert bad outcomes into guardrails, and decide whether PRs are truly merge-ready. |
| Autonomous action | RepoReaper | Turns trusted candidate work into validated patches and clearly attributed pull requests. |
| Suite control plane | HiveCore | Brings standalone products into one operating interface for health, launch control, shared defaults, run history, and product handoffs. |
PatchHive matures automation in that order: visibility first, trust and memory second, autonomous write actions after that foundation exists. HiveCore coordinates the suite, but every product remains independently runnable and useful on its own.
PatchHive is designed for radical delegation, not chat-driven pairing.
- Operators choose broad topics, languages, auth, and safety settings.
- Products discover candidate repos, issues, PRs, and risks on their own.
- Autonomous PRs should come from the PatchHive GitHub identity.
- PR bodies disclose that the work was generated by PatchHive.
- Trust is earned through visible output, reviewable evidence, and consistent history.
The goal is not to pretend automation is human. The goal is to make automation constrained, legible, and useful enough that maintainers can judge it on the work.
PatchHive already has the core product suite, shared Rust crates, shared frontend shell, Docker support, exported standalone mirrors, and HiveCore control-plane wiring.
The active path is:
- Bring up SignalHive, TrustGate, and RepoReaper together.
- Use HiveCore to monitor health, capabilities, run history, and contract drift.
- Exercise the first real handoff path: SignalHive finds work, TrustGate evaluates risk, RepoReaper acts only when the gate is clear.
- Feed rejected or painful outcomes back into RepoMemory through FailGuard.
Run HiveCore as the suite control plane:
cd products/hive-core
cp .env.example .env
docker compose up --buildHiveCore defaults:
- Frontend:
http://localhost:5183 - Backend:
http://localhost:8100
Most products can also run independently:
cd products/<product>
cp .env.example .env
docker compose up --buildFor split local development:
cd products/<product>/backend
cargo run
cd ../frontend
npm install
npm run devBackends bind to 0.0.0.0 by default for Docker compatibility. For loopback-only local runs, set:
PATCHHIVE_BIND_ADDR=127.0.0.1PatchHive is monorepo-first. Products and shared foundations are built here, then exported to standalone mirrors under the patchhive GitHub organization.
The standalone repos make each product easier to inspect, run, and adopt, but the monorepo remains the source of truth.
- Maintenance work should be continuously visible.
- Automation should be constrained and reviewable.
- Repo-specific memory should improve future decisions.
- Outbound contribution should be clearly attributed.
- Safety gates should come before autonomous write actions.
- Trust should be earned through signal quality, not hype.
PatchHive is in active alpha. It is being built for real operator use first; broader adoption comes after the system proves it can produce useful, reviewable maintenance work consistently.