Hadur

When several AI agents each build one part of a system from separate plans, the parts tend to disagree at their seams. A function changes signature in one plan and its callers are not updated, a security check is described and never enforced, a capability is built and never wired to anything. Hadur reviews plans and code against a shared contract and answers “are we done?” with a computed verdict instead of a judgment.

Hadur is a Python toolkit that turns the Contract-First Multi-Plan Review methodology into commands. The team writes a cross-plan contract and one plan per module, and Hadur runs the review loop that follows. It offers:

• a command-line tool, hadur, that opens review rounds, assigns each lens to a distinct reviewer, records findings and computes the verdict;
• a read-only MCP server with five tools and three resources, so any MCP client can query a project directly;
• a Claude Code plugin with six agents for the review roles and two slash commands, /hadur-convergence and /hadur-trends;
• seven static audits that find problems without a human reviewer: drift between documentation and code, security, infrastructure, performance, accessibility, SEO and integration;
• session handoff notes, written automatically before a Claude Code session is compacted, so a long session can resume cleanly;
• a local web interface and a static dashboard.

The review runs as two alternating phases. In a round, independent reviewers each read one plan plus the contract and report findings rated Critical, Major or Minor. In a wave, patch agents fix the findings and a separate verifier checks each fix. The loop repeats inside a campaign, the unit that ends in a verdict.

Each reviewer works under one of thirteen lenses, fixed questions that cover contract consistency, persistence, security, test quality, reachability and more. The thirteenth is a free sweep and needs two distinct reviewers.

A campaign converges only when five clauses hold:

• one full round has covered all thirteen lenses;
• every lens has had at least one clean dispatch, a reviewer run with no Critical or Major finding;
• every open Critical or Major finding has been re-verified by the lens that found it, on a version of the code that contains the fix;
• a closing sweep of all thirteen lenses on the version that ships finds no Critical or Major;
• the verdict states its age and itemizes every exception, such as findings closed as wontfix.

Two rules keep the loop honest. Evidence comes only from the commands: findings are never edited by hand, because the record must be stamped by the verbs that know which lens produced each finding. And the methodology requires an adversarial reviewer, the Breaker, on every fix to a Critical finding; Hadur can enforce it with an opt-in gate that refuses to resolve a Critical without a finished Breaker thread. Across about 50 Breaker passes in the project’s own record, every first-pass fix to a Critical finding was bypassed.

Tests are held to the same standard. A test that names a failure mode must go red when that defect is deliberately reintroduced, and Hadur runs these mutations in an isolated worktree.

Hadur works in two modes. In plans mode, what gets reviewed is the plan suite, before any code exists. In implementation mode, it checks the evidence the build leaves behind: each claim maps to a test, and each registered mutation was seen to turn its test red.

Hadur is in early development. The current version is 0.1.0.dev0. It is not yet published on PyPI and is installed from source with Python 3.11 or later. It is released under the MIT license.

It is meant for teams whose project splits into three or more interdependent plans, where drift between plans is the main risk. A full campaign is not cheap: the methodology estimates 40 to 70 reviewer dispatches over two to four weeks, and a campaign can still close as not converged, in which case the verdict names the lenses that still have open findings.

Hadur also states its own limit. It verifies artifacts, not attention: it can show that a distinct reviewer and a pinned brief exist, not that anyone read the code.

Hadur was distilled from Empenho, a nine-plan SaaS project that went from 318 Critical findings to none across more than thirty corrective waves. It was then applied to itself: 44 review rounds over four months produced 576 findings. An audit of that record led to a rewrite of the stop rule into the campaign clauses described above.

A gap analysis split a planned suite by audience: its engineering half shipped inside Hadur as the audit domains, and its business-communication half (timesheets, client reports and commercial proposals) moved to Pontifex, the Sigil Labs operations toolset. Pontifex reads Hadur’s findings, audits and state in one direction, and Hadur does not depend on it.