Skip to content

New code is covered, measured once and asked two questions

One coverage measurement, test code out of the denominator, holds a crate floor, a floor over the session/continuity domain, and — the invariant of #214 — every executable line a change touches.

status
feature status: stable

What it does

scripts/rust-coverage measures the Rust executable's coverage once — one instrumented export, test code excluded from both the covered and the total so a test added never flatters the number — and reports line, function and region coverage by one rule. Three gates read that one judgment. The crate floor (scripts/rust-coverage-threshold) is a lower bound on the whole executable. The session/continuity domain (scripts/session-coverage-domain) is held to a floor of its own on lines, functions and regions. Both floors are ratchets: each is the coverage its subject measured when it was set, and may rise and never fall. And the differential gate (scripts/ci/coverage-differential, rule project.new-code-is-covered) holds every executable line, function and region a change adds or touches — measured against the branch's merge-base with the trunk, working tree included — so a change that introduces uncovered code is refused even while the aggregate percentage barely moves.

What it does not do

It never demands that untouched legacy debt be paid: the differential gate looks only at the lines a change touched, so legacy_debt_after <= legacy_debt_before holds by construction and new_debt == 0 is what it enforces. A changed line that maps to nothing executable — a comment, a use, a type declaration, test code — is not a finding. It measures the dimensions cargo-llvm-cov gives this crate (line, function, region); it does not mutation- test, so for a predicate whose sense matters it proves the line ran, not that a wrong line would fail a test — those subsystems carry their own adversarial suites, and coverage is necessary, not sufficient, for them.

How it works

The capability modules of the executable this feature names, each with the capabilities it composes. The interfaces each one reaches are listed under Interfaces below: they are projections of one declaration, not separate registrations.

Completion gates gates behaviorally verified

Completion as a state the repository decides rather than a claim a worker makes: the validation gates this repository declares in its CI model, which of them a task's own change set selects, what each one last reported, whether that verdict still describes the tree it was taken over, and therefore whether the task may be called finished. A gate that has never reported is `queued` and not `pass`, a run whose files have changed since is `stale` and refuses exactly as a failure does, and a gate the change cannot affect is `exempt` rather than unknown.

Where it sits

domain
Completion — Done is a contract the repository evaluates line by line. Work is not accepted while any line fails, and a refusal stays on the record.
areas of work
verification
names
DoctrineCI

Interfaces

Each capability behind it, on every interface it is projected onto. A link goes to this site's reference for that interface; an HTTP route and an MCP tool are answered by a running majordomus serve, not by this site.

The capabilities behind this feature, by interface
capabilitycommand lineHTTPMCP tool
gates.completion —none GET /api/v1/gates/completion majordomus_completion
gates.model —none GET /api/v1/gates majordomus_gates

Evidence

What is guaranteed

Each claim this feature names, with the status its row declares, the verdict the recorded runs support, and the test that settles it.

The rules that hold it

  • blocking New and changed executable code is covered by a test; legacy debt may only shrinkproject.new-code-is-covered

Where this page comes from

the file
.ai/repo/features/coverage.md
the same answer
majordomus product show coverage

Searches the titles and descriptions of every page this site publishes.