→ reviewed a well-written contribution that broke a convention it had no way to discover
- cost when it happens
- high
- how often
- common
The contribution is well written. The tests pass. It uses the pattern the project abandoned
two years ago, for reasons that are excellent and recorded nowhere the contributor could
reach. The maintainer writes the explanation for the eleventh time.
A project's real conventions are the residue of its arguments, and arguments are not
documents. They survive in the maintainers and in old review threads. Assistants changed the
economics on one side only: producing a plausible contribution is now nearly free, and
transmitting the conventions is exactly as expensive as it was.
The contributor's assistant did well with what it had — the code, the README, the tests.
None of them contains the reason the abandoned pattern was abandoned. A stronger model makes
a more convincing case for the wrong pattern.
The maintainer's scarcest resource, spent on repetition. And a queue that grows faster than
it drains, which eventually converts an open project into a closed one.
The rules are objects, not folklore: the effective set is the vendored baseline plus the
project's own, resolved as a dependency graph, each saying whether the tool enforces it or
nobody does. The context documents attach to the directories and paths they govern and
compose for the path being changed, so a contributor's assistant can be told to resolve them
before writing. Decisions carry their reason and the alternative that was rejected, which is
the sentence review keeps having to supply.
before review comment #11: "we don't use that pattern here, because ..."
after $ majordomus context resolve lib/auth
$ majordomus rules list
project.no-claim-without-test blocking enforced by: review
majordomus.scope-integrity blocking enforced by: check, finish, watch
It does not gate contributions, and it cannot make anyone read anything. It converts the
conventions from something a maintainer transmits into something a contributor can load.
What this looks like
Concrete situations, one per audience. Each is declared in the moment's front matter, so the before and the after are data rather than prose a page could drift from.
-
An assisted pull request
open-source-maintainer
- before
- A contributor''s assistant produces a clean, idiomatic change that violates a decision the project made two years ago.
- after
- The conventions and the decisions are objects in the repository, discoverable from the paths they govern, before the change is written.
-
Review as the only channel
platform-team
- before
- Contribution volume rises with assistants and review capacity does not; the queue becomes the bottleneck and the conventions the cost.
- after
- The rules are loadable by whatever is doing the writing, so review stops being the transmission mechanism.
-
Work from outside the team
enterprise
- before
- An external contribution meets the standards it could see and misses the ones held internally.
- after
- The effective rule set is readable — vendored baseline plus the project''s own — and says of each rule whether anything enforces it.
How you would know
The observable symptoms this moment declares. They are the questionnaire on the index and the input of majordomus why diagnose; nothing else defines them.
-
◻
Contributions arrive that are fluent, plausible and wrong in a project-specific way.
plausible-and-wrong
-
◻
The same review comment is written repeatedly to different contributors.
same-review-comment
-
◻
The only mechanism transmitting the project''s conventions is review.
review-is-the-gate
Where this lives in the tool
Everything below is read out of this moment's own front matter and resolved against the repository. A name here that did not exist would fail validation.
the commands that answer it
the capabilities of the executable that answer it
what it supervises — derived from the claims below
the claims that back this page, and the evidence behind each
-
guaranteed
The context that applies to a path is composed from the layer's scoped documents, root to target, in one deterministic order with provenance, and a tree that does not validate resolves nothing
-
guaranteed
The effective rule set is resolved as a dependency graph in a deterministic order, and a set that does not resolve is applied by nothing
-
guaranteed
The rule baseline is vendored into the repository with a manifest naming every file and its hash, and a hand edit is detected and refused
-
guaranteed
A doctrine's class is what decides whether a violation stops the command, not a label beside it
-
guaranteed
The impact of a change set on the scoped context is reported from git — the documents, the scopes below them, moves with their ancestry, tracked sources to review, and stale projections — and an unrelated change reports nothing
the rules that govern it
- majordomus.context-integrity
- majordomus.rule-package-integrity
- project.context-locality
- majordomus.doctrine-wiring-integrity
the use cases that show the way out
If this one is familiar, so is the next
What this moment names, what names it, and what shares its area, audience or tags. The second and third are derived; only the first is written down.
All 38, and how they connect to the tool →