hAIve MCP

hAIve is the team-knowledge layer inside an AI coding-agent harness. It gives agents a feedforward briefing before work starts, then adds feedback gates in MCP, Git hooks, CI, and wrappers so changes cannot quietly bypass repo policy.

A capable model already knows generic best practice. What it cannot guess is your team's arbitrary, repo-specific knowledge: that public ids are id + 100000 prefixed AC-, that the status field must be "OK"/"KO", that you never edit an applied migration. Left to itself, a confident agent invents a plausible answer - clean, tested, green, and wrong by policy. hAIve carries that unguessable knowledge into the task and blocks the change that's about to violate it.

hAIve's job is not to replace tests, linters, or observability. It makes the repo-specific knowledge those tools cannot infer available, auditable, and enforceable.

The problem

AI coding agents are powerful, but they often act with incomplete repo context. Compaction, parallel sessions, agent switches, and stale advisory docs all create the same failure mode: the agent changes code without carrying the team's current decisions into the work.

Most teams work around this with instructions and hope:

• "Please read our architecture decisions first."

• "Don't repeat the migration mistake from last sprint."

• "Remember to capture what you learned."

• "Don't merge code that invalidates a team decision."

Those rules are easy to skip. hAIve turns them into repo-native context policy.

Related MCP server: MCP Policy Gatekeeper

How it works

AI agent ──▶ hAIve briefing ──▶ code change ──▶ hAIve policy gate ──▶ merge
                  ▲                                       │
                  └── context breadcrumbs · decisions · gotchas · anchors

1. haive init creates a .ai/ context policy layer in your repo.

2. Agents start every session with get_briefing — one MCP call that returns small default context plus deeper breadcrumbs ranked by task relevance.

3. Decisions, gotchas, failed attempts, and session recaps live as Markdown files anchored to the code paths they describe. When code moves, hAIve detects stale anchors.

4. haive enforce check and CI enforcement block unsafe states: missing briefing, stale critical decisions, an anchored anti-pattern your diff is about to repeat, or uncaptured session knowledge.

Memory is the substrate. Context enforcement is the product promise. AI changes should not enter the codebase without consulting the team's current knowledge.

Where hAIve fits in the harness

Harness engineering is about the environment around the model: feedforward guidance before it acts, feedback sensors after it acts, and workflow gates that keep bad states from landing. hAIve owns the repo-specific context policy part of that harness.

The narrow positioning is intentional: hAIve is not a general memory database or an agent dashboard. It is the control layer that helps coding agents act with the validated, non-obvious knowledge of the team.

Scope & boundaries — the three harnesses

Harness engineering regulates three different things about agent-written code. hAIve deliberately covers two of them and treats the third as out of scope, for now.

Why no behaviour harness yet. Verifying functional correctness needs an oracle — an independent source of truth for what the code should do — and that oracle problem (plus the trap of an agent grading its own work) is the least-mature part of the field. That territory belongs to your tests, property-based checks, and LLM-evals; hAIve does not try to replace them. What hAIve does do is carry the unguessable intent a behaviour test would otherwise have to encode (status must be OK/KO, public ids = id + 100000) as feedforward context and deterministic sensors — a partial, static slice of behaviour control, not a runtime functional oracle.

A future, opt-in command/test sensor lane (already scaffolded behind enforcement.runCommandSensors) is the planned bridge toward real behaviour feedback without diluting the narrow scope. Until then, treat the behaviour harness as your responsibility, not hAIve's.

See STABILITY.md for the frozen 1.0 surface and CONTRIBUTING.md to extend hAIve.

Executable memory sensors

Some gotcha and attempt memories can now carry a sensor block: a deterministic regex guardrail that scans the added lines of a diff. Sensors turn a documented lesson into a repeatable feedback signal, independent of embeddings or model judgment. Autogenerated sensors start as warn; humans can promote high-confidence ones to block.

haive sensors list
haive sensors check              # scans git diff --cached
haive sensors promote <id> --yes # promote a vetted sensor to block
haive sensors export --format grep

Install

npm install -g @hiveai/cli
# Optional: local semantic search (downloads ~110MB model once)
npm install -g @hiveai/embeddings

Quick start

1. Initialize your project

cd my-project
haive init          # Creates .ai/, bridge files, MCP config, hooks, CI template

haive init now also runs agent setup. It writes project-level MCP configs, records the best available mode, and asks before changing user-level client configs. In non-interactive shells it skips global config and tells you how to finish setup.

2. Connect your AI client

Claude Code (~/.claude.json):

{
  "mcpServers": {
    "haive": {
      "command": "haive",
      "args": ["mcp", "--stdio", "--root", "/absolute/path/to/my-project"]
    }
  }
}

Cursor (~/.cursor/mcp.json):

{
  "mcpServers": {
    "haive": {
      "command": "haive",
      "args": ["mcp", "--stdio", "--root", "/absolute/path/to/my-project"]
    }
  }
}

VS Code:

code --add-mcp '{"name":"haive","command":"haive","args":["mcp","--stdio","--root","/path/to/project"]}'

3. Bootstrap your project context

In your AI client, invoke the bootstrap_project MCP prompt. The agent analyzes your codebase and writes .ai/project-context.md automatically.

4. Start work through hAIve

Every session starts with one call:

get_briefing(task: "add a Stripe payment integration", files: ["src/payments/PaymentService.ts"])

The agent gets project context + relevant module contexts + ranked context breadcrumbs in one shot — no more grepping to rediscover what the team already knows.

For CLI agents without native MCP, wrap them:

haive run -- claude --dangerously-skip-permissions -p "$(cat task.md)"

Check the selected mode any time:

haive agent status
haive agent setup          # re-run setup later
haive agent setup --yes    # approve user-level MCP config without prompting

5. Gate commits and pull requests

haive enforce install       # Installs Git hooks + CI enforcement template
haive enforce status        # Current enforcement posture
haive enforce check         # Pre-commit policy gate
haive enforce ci            # CI entrypoint (exits 1 on violations)

CLI at a glance — the golden path

haive --help shows only the commands you use day to day. Everything else (review, import, diagnostics, benchmarks) is one haive --advanced --help away — the focused surface is deliberate, not a missing feature.

One vocabulary across CLI and MCP. The memory verbs mirror the MCP tool names, so an agent learns them once: haive memory save/search/get/delete ↔ mem_save/mem_search/mem_get/mem_delete (the older add/query/show/rm still work as aliases).

Try it on your repo (5 minutes, reversible)

Want to evaluate hAIve on a real codebase that isn't a toy? It is non-destructive — everything it writes lives under .ai/ plus a few bridge files, all removable.

cd your-project
npm install -g @hiveai/cli
haive init -y            # seeds stack packs + git-history scars; writes .ai/ and bridges
haive briefing --task "the change you're about to make" --files path/to/file
haive doctor             # health + coverage report
haive sensors check      # scan your staged diff against documented lessons
haive eval --fail-under 50   # retrieval + sensor quality on your own corpus

To remove everything hAIve added: rm -rf .ai CLAUDE.md AGENTS.md GEMINI.md .cursorrules .clinerules .continuerules .windsurfrules .rules CONVENTIONS.md .github/copilot-instructions.md and drop the .github/workflows/haive-*.yml files. Feedback from a repo that isn't ours is the most valuable thing you can send — please open an issue with what worked and what didn't.

What hAIve enforces

What "block" means here. hAIve's gate is high-precision by design: it hard-blocks the case that is almost always a real mistake — an attempt/gotcha anchored to the exact file you are editing, whose warning the diff corroborates. Looser, token-only matches are surfaced for review rather than blocked, so config/doc commits don't trip on incidental keyword overlap. Tighten or loosen this with enforcement.antiPatternGate; everything else is enforced as process (was the context loaded, were decisions surfaced, is the recap present).

Cold start — value in session one

An empty corpus is worth nothing, so haive init seeds from signals the repo already has — and every seed passes a quality floor so cold-start never ships generic, guessable advice. A seed earns its place only if it carries an enforceable sensor or is concrete and non-generic.

haive init                                   # Detect stack + seed packs + seed git history
haive ingest --from sonar issues.json --min-severity major
haive ingest --from eslint report.json
haive ingest --from sarif report.sarif --dry-run   # Preview without writing

Ingested and git-seeded memories land as proposed (warn-only sensors). Review them with haive memory list --status proposed; promote vetted sensors to block with haive sensors promote.

.ai/ directory layout

your-project/
├── .ai/
│   ├── project-context.md          # Shared project overview
│   ├── modules/                    # Per-component context files
│   │   ├── backend/context.md
│   │   └── frontend/context.md
│   └── memories/
│       ├── personal/               # Private — gitignored
│       ├── team/                   # Shared — committed to git
│       └── module/<name>/          # Module-scoped memories
├── CLAUDE.md                       # Auto-generated bridge (Claude Code)
├── AGENTS.md / GEMINI.md / …       # …and 10 more native bridges (see below)
└── .github/
    ├── copilot-instructions.md     # Auto-generated bridge for Copilot
    └── workflows/
        ├── haive-sync.yml          # Anchor verification on merge
        └── haive-enforcement.yml   # Required policy gate

Native bridges — meet every agent where it is

For CLI/IDE agents without MCP, haive init generates native config files from the same corpus, so the team's memories and block sensors travel to whatever agent a developer uses — not just an empty template, the enforcement edge too. haive sync keeps them fresh; never hand-edit them (regenerate with haive bridges sync).

haive bridges list                 # Show target status
haive bridges sync --all           # Regenerate every native bridge
haive init --bridge-targets cursor,copilot   # Or scope to specific agents

Context policy records

All records can be anchored to file paths and symbol names. When anchored code changes, hAIve flags the record as potentially stale.

MCP tools reference

MCP profiles keep the product focused:

• HAIVE_TOOL_PROFILE=enforcement (default): compact coding-agent harness.

• HAIVE_TOOL_PROFILE=maintenance: corpus review, lifecycle, distillation, code-search, and project-context maintenance.

• HAIVE_TOOL_PROFILE=experimental: broader diagnostics such as runtime journal, pattern detection, why-this-file, why-this-decision, and conflict analysis.

• HAIVE_TOOL_PROFILE=full: legacy alias for experimental.

MCP prompts reference

Packages

Also in this repo: a VS Code extension (surfaces memories inline + a Strategic Cockpit over the CLI's observability) and a GitHub Action (posts relevant team memories as a PR comment so reviewers and agents never miss a non-obvious constraint).

Adaptive briefing

A briefing only earns its place when it carries unguessable knowledge, so get_briefing returns briefing_value: "high" | "low". When nothing team-specific matches the files/task, the auto-generated project context is trimmed to a one-line note (config: adaptiveBriefing, default on) — so hAIve surfaces deeper context only when it actually knows something the model doesn't.

CLI reference

# Setup
haive init [--with-ci] [--no-bridges]         # Initialize .ai/ + bridge files + seed stack/git
haive init --bridge-targets <all|csv>         # Scope generated bridges to specific agents
haive enforce install                         # Install Git hooks + CI enforcement
haive enforce status                          # Enforcement posture report
haive bridges list/sync [--all]               # Inspect / regenerate native agent bridges
haive index code                              # Build .ai/code-map.json
haive index code --status [--json]            # Report code-map / code-search index freshness

# Daily use
haive briefing [--task <text>] [--files] [--json]   # Print context + relevant memories
haive run -- <agent command>                  # Wrap any CLI agent in hAIve session
haive enforce check [--stage pre-commit]      # Policy gate
haive enforce ci                              # CI entrypoint
haive enforce finish                          # Final agent-exit gate: commit/push + version/tag protocol
haive coverage [--source git|agent|both]      # Find changed files no memory covers
haive sync [--since <ref>] [--embed]          # Verify anchors + auto-promote
haive sensors list/check/export/promote       # Operate executable memory sensors

# Memory
haive memory save --type <type> [--paths|--files <csv>] # Save a memory (anchor to files)
haive memory list [--scope] [--status]        # List memories
haive memory search <text>                    # Full-text / semantic search
haive memory get <id>                         # Read one record
haive memory approve [<id>|--all]             # Mark as validated
haive memory promote <id>                     # personal → team
haive memory tried                            # Record a failed approach
haive memory resolve-conflict [--yes]         # Guided supersede of contradicting memories
haive memory verify [--update] [--json]       # Check anchor freshness
haive memory import --from <file>             # Import docs as memories

# Cold start (seed from existing signals)
haive ingest --from sonar|sarif|eslint|npm-audit <file>  # Scanner findings → anchored memories
haive ingest --from <fmt> <file> --dry-run    # Preview without writing

# Semantic search
haive embeddings index                        # Build index (first run: downloads model)
haive embeddings query <text>                 # Semantic search

# Diagnostics
haive doctor                                  # Analyze setup, emit recommendations
haive eval --fail-under 80                    # Retrieval + sensor quality gate
haive tui                                     # Interactive terminal dashboard
haive bench                                   # Self-test MCP tools

haive eval auto-synthesizes retrieval cases from anchored memories and, when present, also loads .ai/eval/spec.json for labeled retrieval/sensor cases. This repo uses that file to keep executable memory sensors in CI, so a broken guardrail is caught before release.

haive doctor reports local setup drift that can make agents misdiagnose the repo: missing pnpm, stale workspace dist artifacts, global CLI/MCP version skew, outdated code-search indexes, and low memory-anchor coverage.

Multi-component projects

For projects with multiple components (frontend/backend/microservices), create one module context per component. get_briefing auto-loads the relevant module context based on the files being edited.

mkdir -p .ai/modules/backend .ai/modules/frontend

cat > .ai/modules/backend/context.md << 'EOF'
# Module: backend
- Spring Boot, Java 17, PostgreSQL
- Always filter by tenantId in every repository query
- Never modify existing Flyway migrations — create V{N+1}__desc.sql
EOF

cat > .ai/modules/frontend/context.md << 'EOF'
# Module: frontend
- React 19, TypeScript, TanStack Query v5
- All API calls go through hooks in features/<domain>/api/
- Env vars must start with VITE_ to be exposed to the client
EOF

Development

git clone https://github.com/Doucs91/hAIve.git
cd hAIve
pnpm install
pnpm -r build    # Build all packages
pnpm -r test     # Run tests

Requires Node 20 LTS+, pnpm 9+.

Contributing

Issues and PRs are welcome. Please open an issue before starting significant work so we can align on direction.

License

Apache 2.0 — see LICENSE.