Module rules 

The rules module: from a rule to what proves it, and back.

The rules section declares what this repository refuses; crate::rules decides what the repository can actually show for each one. These capabilities are the one declaration of that reading, and every surface — the command line, the HTTP API and its OpenAPI operation, the MCP tool an agent reads, the Cockpit page, the generated reference — is derived from it. There is no second rule inventory behind any of them, which is the property the whole exercise exists to buy: a rule added to the rules section tomorrow appears on all of them without a line being edited anywhere.

Validate and verify are different questions

rules.verify asks whether the rule is in order: is what it names in the tree, does a runner own it, was it ever run, did that run pass, is the run older than its subject. Whether the repository currently satisfies a rule is the dispatcher’s question, and the portable layer’s majordomus doctrine is where it is asked — one rule, one validator, run against the working tree. Collapsing the two is how “the rule is fine” and “the repository is fine” become one green badge that means neither.

Both directions

A relation that can only be walked one way is half a relation. rules.show answers “what proves this rule”; rules.proves answers “what does this test prove”, listing every rule that names it. They read the same derivation, so the two answers cannot disagree — and the second is the one that says whether deleting a case would leave a rule unenforced, which is the question nobody could ask before.

Example

The module declares three capabilities, and every projection — the command line, the HTTP operation, the MCP tool — is derived from that one declaration.

use majordomus_cli::capability::builtin::rules::module;
let m = module();
assert_eq!(m.id.as_str(), "rules");
let ids: Vec<&str> = m.capabilities.iter().map(|e| e.capability.id.as_str()).collect();
assert_eq!(ids, ["rules.report", "rules.show", "rules.proves"]);

Structs

RuleDetail

One rule, with everything that proves it and everything that depends on it.

RuleInput

One rule of the corpus.

RuleSummary

A rule named from somewhere else, with just enough to decide whether to follow it.

RuleTestInput

One test, by the path a rule names it with or by its canonical identity.

RulesReportInput

Which part of the corpus to answer for.

TestSubjects

What one test proves: the reverse of RuleDetail.

Functions

module

The rules module: rules joined to what proves them.