Skip to content

Prismatic Majordomus

The control plane for AI-native repositories.

One repository.Many agents.One source of truth.

Majordomus turns a git repository into a typed, inspectable, agent-operable system: one policy every tool reads, one registry every interface is derived from, and typed records of sessions, worktrees, decisions and rules that outlive the conversation that produced them.

Install Every feature against every interface
$ majordomus product matrix 19 × 5
Every feature of the product against the interfaces it is exposed through
featurecliapimcpcockpitdocs
Declare once ●on Command line ●on HTTP API ●on MCP ●on Cockpit ●on Documentation
Interfaces ●on Command line ●on HTTP API ●on MCP ●on Cockpit ●on Documentation
Coordination ●on Command line ●on HTTP API ●on MCP ●on Cockpit ●on Documentation
Worktrees ●on Command line ●on HTTP API ●on MCP ●on Cockpit ●on Documentation
Continuity ●on Command line ●on HTTP API ●on MCP ●on Cockpit ●on Documentation
Knowledge ●on Command line ●on HTTP API ●on MCP ●on Cockpit ●on Documentation
Doctrine ●on Command line ●on HTTP API ●on MCP ●on Cockpit ●on Documentation
Finish contract ●on Command line not on HTTP API not on MCP not on Cockpit ●on Documentation
Policy ●on Command line not on HTTP API ●on MCP not on Cockpit ●on Documentation
Cockpit not on Command line ●on HTTP API ●on MCP ●on Cockpit ●on Documentation
Provenance ●on Command line not on HTTP API ●on MCP ●on Cockpit ●on Documentation
Install ●on Command line ●on HTTP API ●on MCP ●on Cockpit ●on Documentation
Planning ●on Command line ●on HTTP API ●on MCP ●on Cockpit ●on Documentation
Context ●on Command line ●on HTTP API ●on MCP ●on Cockpit ●on Documentation
Use cases ●on Command line not on HTTP API ●on MCP not on Cockpit ●on Documentation
Skills ●on Command line not on HTTP API ●on MCP not on Cockpit ●on Documentation
Why ●on Command line ●on HTTP API ●on MCP ●on Cockpit ●on Documentation
Benchmarks ●on Command line ●on HTTP API ●on MCP ●on Cockpit ●on Documentation
CI ●on Command line not on HTTP API not on MCP not on Cockpit ●on Documentation

Real output. The rows are the features this repository declares and the marks are derived from what each one names; the same answer is on the command line, over HTTP and over MCP.

install · one command

Install majordomus in one command

No git, no Rust, no Node, no root. One archive for your machine, its digest verified before anything is unpacked, into $HOME/.local/bin.

1 · paste into a terminal 
curl -fsSL https://majordomus.dev/install.sh | sh

2 · in the repository you want supervised

majordomus init

Writes .ai/ — the policy, the profiles, the rules, the prompts, the workflows — and nothing else.

3 · point your agents at it

majordomus update

Generates CLAUDE.md, AGENTS.md and the other bootstraps from the policy; every worker reads the same contract. Platforms, pinning a version, the security model →

What init creates is the layer this site is generated from: one directory, tracked, readable without the tool. The sections below are this repository's own.

You need this if, this week, you have…

  1. re-explained the same context to a brand-new sessionWhy, and what to do →
  2. found two agents fixing the same bug in two branchesWhy, and what to do →
  3. watched the strongest model, at maximum effort, rename a variableWhy, and what to do →
  4. accepted "done" because the model said so, and paid for it the next morningWhy, and what to do →
  5. opened CLAUDE.md and AGENTS.md and found two different rulebooks for one repositoryWhy, and what to do →
  6. watched a session undo last week's decision, for the reason it was madeWhy, and what to do →
  7. found a task "in progress" that nobody had touched for three weeksWhy, and what to do →
  8. asked what the workers did last night and had only transcripts to grepWhy, and what to do →
  9. found the rule for that directory in a README no session ever loadedWhy, and what to do →
  10. read three roadmaps for one project and believed none of themWhy, and what to do →

All 38, by who you are and by what part of operations they fall under →

None of these are model problems. They are operations problems, and operations is what Majordomus does.

01 / what it does

What it does

Each chapter is one feature file under the layer. The interfaces, the counts, the mechanisms and the moments beside it are derived from what that file names; the words are the only thing a person wrote.

  1. 1 / 9

    Declare once, derive every interface

    A capability is written in one place, and the command line, the HTTP API, the OpenAPI document, MCP, the Cockpit, the reference and this website are projections of it.

    Answers 15 of the catalogue’s operational moments, among them “opened CLAUDE.md and AGENTS.md and found two different rulebooks for one repository”.

    What it is, and what it does not do →
  2. 2 / 9

    Several agents on one repository, without stepping on each other

    Every worker declares the paths it may touch, every session can see who else is attached and what they announced, and a collision is reported before it is committed.

    Answers 14 of the catalogue’s operational moments, among them “re-explained the same context to a brand-new session”.

    What it is, and what it does not do →
  3. 3 / 9

    One branch, one worktree, at a path derived from git

    A branch's worktree is where git says it is, never where somebody chose to put it, and a misplaced one is a diagnostic with a remedy rather than a mystery.

    Answers 3 of the catalogue’s operational moments, among them “found a task "in progress" that nobody had touched for three weeks”.

    What it is, and what it does not do →
  4. 4 / 9

    Sessions, prompts and handovers that outlive the conversation

    A session ends and the work does not: what the next worker needs is a typed record checked against git, not a transcript somebody hopes to find.

    Answers 20 of the catalogue’s operational moments, among them “re-explained the same context to a brand-new session”.

    What it is, and what it does not do →
  5. 5 / 9

    Decisions and knowledge that compound instead of evaporating

    What was decided, why, and what was rejected is recorded where the next session reads it, and a durable decision becomes an architecture record with typed links to what it put in force.

    Answers 17 of the catalogue’s operational moments, among them “watched a session undo last week's decision, for the reason it was made”.

    What it is, and what it does not do →
  6. 6 / 9

    Rules a machine decides, wired, tested and CI-blocking

    A rule is enforced when a validator decides it, a command runs it, a test proves it and CI blocks on it; anything less is documentation, and the tool knows the difference.

    Answers 31 of the catalogue’s operational moments, among them “re-explained the same context to a brand-new session”.

    What it is, and what it does not do →
  7. 7 / 9

    Done is a contract, evaluated line by line and refused when unmet

    A worker does not get to define its own successful completion: every line of the finish contract is printed pass or fail, and nothing is written to the record until all of them pass.

    Answers 20 of the catalogue’s operational moments, among them “re-explained the same context to a brand-new session”.

    What it is, and what it does not do →
  8. 8 / 9

    The Cockpit: the registry rendered for a person

    The same server that answers agents renders every capability, object, graph, worktree and health check as pages, with a runner generated from each capability's own schema; nothing on it is a second list.

    Answers 11 of the catalogue’s operational moments, among them “accepted "done" because the model said so, and paid for it the next morning”.

    What it is, and what it does not do →
  9. 9 / 9

    Every record names the commit, the branch and the episode that made it

    Who did what, under which task, at which commit, in which session is a ledger the tool writes and a person can read back, not a memory of a conversation.

    Answers 15 of the catalogue’s operational moments, among them “re-explained the same context to a brand-new session”.

    What it is, and what it does not do →

All 19 features, each with the capabilities, objects, rules and guarantees behind it →

02 / the layer

Write once. Surface everywhere.

A rule, a skill, a decision, a use case, an operational moment, a feature: each is one file under the layer with a schema. Discovery finds it, the schema validates it, the index holds it, and every interface reads the index. Nothing registers anything.

  • adr33
  • application5
  • area9
  • audience8
  • claim148
  • command29
  • context27
  • deployment1
  • distribution-model1
  • document210
  • feature20
  • implementation45
  • issue202
  • knowledge1
  • milestone17
  • moment38
  • policy1
  • profile4
  • prompt4
  • release-record1
  • rule109
  • scope1
  • session11
  • skill3
  • taxonomy10
  • test135
  • use-case42
  • workspace1

Every one of them is discovered by a declared source class, validated against a published schema, held in one index and read by every interface. The schemas, one per kind →

03 / provider-neutral

Provider-neutral by construction

The policy is one file and every tool's instruction file is generated from it — an agent's, or an orchestrator's that runs agents over the repository. A worker's context, its worktree, its handovers and the repository's decisions belong to the repository, not to the vendor whose session happened to produce them.

  • Any tool that reads AGENTS.md
    • AGENTS.md
  • bb
    • .bb/AGENTS.md
  • Claude Code
    • CLAUDE.md

    .mcp.json

  • Codex

    .codex/config.toml

  • Gemini CLI

    .gemini/settings.json

  • A worker with no convention of its own

Repository intelligence is not a model provider.

Majordomus never invokes a model; it decides what a worker is told, what it may touch, and whether its claim of being done can be believed.

04 / one declaration

One registry, every interface

A capability is declared once. The command line, the HTTP API, the OpenAPI document and the Swagger UI over it, the MCP tools and resources, the Cockpit and this site are projections of that declaration; a projection that disagrees with it fails the build.

capabilities in the registry
1189
MCP tools
71
HTTP routes
73
objects of the layer
1116

Coverage

Every mark is derived. A feature is on an interface because a module, command or kind it names is projected there, never because a page says so; a gap is shown rather than hidden.

capability modules named by a feature
16 / 24
public commands named by a feature
27 / 28
object kinds named by a feature
22 / 25

A part of the product no feature names is reported as a gap by majordomus product validate and shown on the matrix, never quietly absent.

The full matrix, both directions → The registry itself, capability by capability →

05 / the same model

The product, composed

The same model as a graph: features, what each is made of, and the interfaces that follow. Select a node to see what it touches; the list under it is the graph without a script.

the features of the layer, the capability registry and the command registry

Select a node to see what it is and what it touches.

Every stable feature of the product, the capability modules, shell commands and object kinds it is made of, and the interfaces those project onto: the command line, the HTTP API, MCP, the Cockpit and the documentation. Every edge is derived from a feature's typed references and the registry's exposures; a feature that named something the repository does not have would fail validation rather than draw an edge to nothing.
The same graph as text — 90 nodes, 270 edges

  • majordomus adr command · conclude

    The repository's architecture decisions as objects: list, show, propose one with provenance, and validate the whole set.

    • exposed_through surface:cli

  • majordomus bench command · inspect

    Time every public command of the registry, cold and warm, and compare with the baseline.

    • exposed_through surface:cli

  • majordomus capture command · work

    Record the person's raw prompts from a provider hook as a record with its renderings, draw the episode boundary from the provider's own lifecycle hooks, install those hooks, and report what each provider actually does here.

    • exposed_through surface:cli

  • majordomus check command · verify

    Is the current task still consistent with its policy, its scope and this checkout?

    • exposed_through surface:cli

  • majordomus checkpoint command · work

    Record compact progress inside the active task, so the next worker does not start over.

    • exposed_through surface:cli

  • majordomus context command · work

    What the next worker needs to know now, in authority order and within a budget.

    • exposed_through surface:cli

  • majordomus decision command · work

    Record a decision that was made between real alternatives, with its reason, and read them back.

    • exposed_through surface:cli

  • majordomus doctor command · inspect

    Is Majordomus itself healthy, and is every enforcement it declares actually wired here?

    • exposed_through surface:cli

  • majordomus doctrine command · inspect

    What rules are enforced, by what, and whether each one is actually wired.

    • exposed_through surface:cli

  • majordomus finish command · conclude

    Evaluate the finish contract and refuse the outcome if any line of it is unmet.

    • exposed_through surface:cli

  • majordomus handover command · conclude

    Write an append-only continuation record, and resolve the most relevant prior one.

    • exposed_through surface:cli

  • majordomus history command · inspect

    Read the append-only ledger back, filtered by task, event or time.

    • exposed_through surface:cli

  • majordomus init command · setup

    Create the .ai/ layer in this repository, and refuse to overwrite an existing one.

    • exposed_through surface:cli

  • majordomus knowledge command · inspect

    The compiled index over what this repository states.

    • exposed_through surface:cli

  • majordomus migrate command · setup

    Move pre-.ai project data from .majordomus/ into .ai/, explicitly and backed up.

    • exposed_through surface:cli

  • majordomus plan command · begin

    The milestone and issue model — validate it, read it, and move one issue through it.

    • exposed_through surface:cli

  • majordomus prompt command · work

    List, show and render the repository's own prompt assets, substituting known tokens only.

    • exposed_through surface:cli

  • majordomus question command · work

    Open a question that blocks acceptance, resolve it, and list what is still open.

    • exposed_through surface:cli

  • majordomus rules command · inspect

    The effective rule set, vendored baseline plus project rules.

    • exposed_through surface:cli

  • majordomus search command · inspect

    Find a durable record without reading all of them, in authority order.

    • exposed_through surface:cli

  • majordomus session command · begin

    Open, inspect and close one execution episode.

    • exposed_through surface:cli

  • majordomus skills command · work

    The repository's skills — provider-neutral procedures under the skills section — listed, shown and checked from the one catalogue every surface reads.

    • exposed_through surface:cli

  • majordomus start command · begin

    Begin one scoped task under a profile, and refuse while another is active.

    • exposed_through surface:cli

  • majordomus update command · setup

    Regenerate every provider instruction file from the one policy, deterministically.

    • exposed_through surface:cli

  • majordomus usecase command · verify

    The executable use cases: list, show, validate, run against the real tool, coverage, impact, scaffold.

    • exposed_through surface:cli

  • majordomus version command · inspect

    Print the version, without needing a repository or an installation.

    • exposed_through surface:cli

  • majordomus watch command · inspect

    What has drifted since the last update — policy, projections, state, retention.

    • exposed_through surface:cli

  • Benchmarks feature · stable

    The benchmark targets are derived from the registry, so a capability nothing times cannot be merged; runs are compared with a tracked baseline per platform under a regression policy; the shell tool reports where every command's time went; and derived state is computed once per state version rather than per call.

    • made_of command:bench
    • related_to feature:ci
    • related_to feature:declare-once
    • made_of module:perf
    • exposed_through surface:docs

  • CI feature · stable

    The gate model names every validation gate and which classes of paths select it; the workflow is a thin adapter over that plan; the publication path proves the committed derived data current by its input hash and renders it; and the tool supervises its own repository with its own hooks.

    • made_of command:doctor
    • made_of command:watch
    • related_to feature:benchmarks
    • related_to feature:doctrine
    • exposed_through surface:docs

  • Cockpit feature · featured

    At /cockpit the shared server lays out what a capability answered — the registry explorer, every object of the layer, the derived graphs, the directory contracts, the continuity of this checkout, the worktree topology, one health report naming the engine behind every check — and every page is complete HTML before any script runs.

    • related_to feature:declare-once
    • related_to feature:interfaces
    • made_of module:health
    • exposed_through surface:docs

  • Context feature · stable

    Every README under .ai/ is a context document with an identity, a scope, the providers and audience it addresses and how it composes with its ancestors; the repository scope declares what a worker reads and what it never reads; and the briefing a worker gets is assembled from durable state within a line budget with every exclusion named.

    • made_of command:context
    • related_to feature:continuity
    • related_to feature:policy
    • made_of kind:context
    • made_of kind:scope
    • made_of module:directories
    • made_of module:repository
    • exposed_through surface:docs

  • Continuity feature · featured

    Task state, checkpoints, handovers, decisions and open questions live in files outside every conversation; a session opens and closes into an immutable record; the person's prompts are captured by the provider's own hooks; and the next episode is briefed from those records, labelled by how far git has moved since.

    • made_of command:capture
    • made_of command:checkpoint
    • made_of command:context
    • made_of command:handover
    • made_of command:prompt
    • made_of command:session
    • related_to feature:coordination
    • related_to feature:knowledge
    • related_to feature:provenance
    • made_of kind:prompt
    • made_of kind:session
    • made_of module:continuity
    • exposed_through surface:docs

  • Coordination feature · featured

    A task claims its scope before the first edit; check and finish refuse a file outside it and report another worktree's overlapping claim; every client of the shared server is a peer that can announce its intent and paths; and each branch has exactly one worktree, derived from git.

    • made_of command:check
    • made_of command:finish
    • made_of command:start
    • related_to feature:continuity
    • related_to feature:worktrees
    • made_of module:peers
    • made_of module:worktree
    • exposed_through surface:docs

  • Declare once feature · featured

    One typed declaration per capability, one file per object of the layer; every interface, generated document and page is derived from the registry those declarations build, and a stale projection fails the build.

    • made_of command:doctor
    • made_of command:update
    • related_to feature:cockpit
    • related_to feature:interfaces
    • made_of kind:claim
    • made_of kind:command
    • made_of kind:feature
    • made_of module:artifacts
    • made_of module:capabilities
    • made_of module:product
    • exposed_through surface:docs

  • Doctrine feature · featured

    Every rule is a portable Markdown object with front matter; a rule the tool enforces names its validator, the commands that dispatch it and the tests that prove it, and doctor walks that chain from the source, refusing a validator nobody declares and a declaration nothing runs; a blocking violation stops the command and an advisory one is reported.

    • made_of command:check
    • made_of command:doctor
    • made_of command:doctrine
    • made_of command:rules
    • made_of command:watch
    • related_to feature:finish-contract
    • related_to feature:policy
    • made_of kind:rule
    • made_of module:health
    • exposed_through surface:docs

  • Finish contract feature · featured

    A task starts with a declared scope and a profile; check reports whether the task is consistent with policy, scope and state; finish evaluates the policy's contract — scope respected, verification ran, state updated, no open blockers, a note present — and refuses with the reproducing command when any line fails.

    • made_of command:check
    • made_of command:finish
    • made_of command:question
    • made_of command:start
    • related_to feature:coordination
    • related_to feature:doctrine
    • exposed_through surface:docs

  • Install feature · stable

    One distribution model owns every platform, artifact name and URL; the installer, the release build matrix, the installation guide, the website's install block and the public release metadata are generated from it, and a release publishes an artifact for every supported target or it is not published.

    • made_of command:init
    • made_of command:migrate
    • made_of command:version
    • related_to feature:policy
    • made_of kind:distribution-model
    • made_of module:distribution
    • exposed_through surface:docs

  • Interfaces feature · stable

    The Rust executable serves the layer read-only over stdio MCP, MCP over HTTP, routes under /api/v1/, an OpenAPI document with a Swagger UI, and a command line, all derived from the capability registry; one shared server per repository, and every attached client is a peer the others can see.

    • related_to feature:coordination
    • related_to feature:declare-once
    • made_of module:objects
    • made_of module:repository
    • made_of module:web
    • exposed_through surface:docs

  • Knowledge feature · featured

    Decisions are recorded with their reason and their task, open questions block acceptance until resolved, architecture decision records carry typed references to the rules, claims, files and tests they put in force, and the graph of all of it is derived from those references rather than drawn.

    • made_of command:adr
    • made_of command:decision
    • made_of command:history
    • made_of command:knowledge
    • made_of command:question
    • made_of command:search
    • related_to feature:continuity
    • related_to feature:doctrine
    • made_of kind:adr
    • made_of kind:document
    • made_of kind:knowledge
    • made_of module:graph
    • exposed_through surface:docs

  • Planning feature · stable

    Milestones are outcome specifications and issues are execution contracts, one YAML file each; the dependency graph decides execution waves and the next ready issue; a milestone whose dependencies are not accepted is blocked whatever its own issues say; and the GitHub projection is rendered offline from the same model.

    • made_of command:plan
    • related_to feature:finish-contract
    • related_to feature:worktrees
    • made_of kind:issue
    • made_of kind:milestone
    • made_of module:trace
    • exposed_through surface:docs

  • Policy feature · stable

    A provider-neutral policy and four execution profiles are the one source; majordomus update renders each provider bootstrap from its template, stamps it with the policy hash and the hash of its own content, and doctor fails a bootstrap that was hand-edited, that carries a rule corpus of its own, or that exceeds the always-loaded budget.

    • made_of command:doctor
    • made_of command:init
    • made_of command:update
    • related_to feature:declare-once
    • related_to feature:doctrine
    • made_of kind:policy
    • made_of kind:profile
    • exposed_through surface:docs

  • Provenance feature · featured

    The ledger records every durable event with its task and its head; identity fields on any record are computed from git and refused when authored; a closed session is an immutable record of what one episode produced; the person's prompts are captured by the provider's hooks; and retention is capped by policy rather than by forgetting.

    • made_of command:capture
    • made_of command:history
    • made_of command:session
    • made_of command:watch
    • related_to feature:continuity
    • related_to feature:knowledge
    • made_of kind:session
    • exposed_through surface:docs

  • Skills feature · stable

    A skill is a provider-neutral procedure for one bounded kind of work, front matter under a schema over a body with a purpose, a procedure and an output contract; the source class discovers it, skills check holds every one to its contract, and nothing loads a skill unless the task is about it.

    • made_of command:skills
    • related_to feature:context
    • related_to feature:declare-once
    • made_of kind:skill
    • exposed_through surface:docs

  • Use cases feature · stable

    A use case names the commands, rules, claims and applications it relies on and carries a scenario as data; usecase run executes it in a disposable repository and records normalised evidence; maturity is observed from the evidence; coverage of commands, guaranteed claims and MCP tools is tallied and the policy says which gaps fail.

    • made_of command:usecase
    • related_to feature:doctrine
    • related_to feature:why
    • made_of kind:application
    • made_of kind:taxonomy
    • made_of kind:use-case
    • exposed_through surface:docs

  • Why feature · stable

    Moments, audiences and areas are kinds of the layer; a moment names the commands, capabilities, claims, rules and use cases that answer it, each reference validated; the catalogue, the questionnaire, the diagnosis and every page and filter are derived from those files.

    • related_to feature:declare-once
    • related_to feature:use-cases
    • made_of kind:area
    • made_of kind:audience
    • made_of kind:moment
    • made_of module:why
    • exposed_through surface:docs

  • Worktrees feature · featured

    The container is the primary checkout's sibling named with -wt, a branch's worktree is the branch name under it with its hierarchy kept, both derived from git identity and registered nowhere; a pre-commit guard refuses a feature branch committed from anywhere else, and migration moves a misplaced worktree with its uncommitted work, fingerprinted before and after.

    • related_to feature:continuity
    • related_to feature:coordination
    • made_of module:worktree
    • exposed_through surface:docs

  • adr kind

    33 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • application kind

    5 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • area kind

    9 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • audience kind

    8 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • claim kind

    148 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • command kind

    29 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • context kind

    27 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • distribution-model kind

    1 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • document kind

    210 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • feature kind

    20 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • issue kind

    202 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • knowledge kind

    1 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • milestone kind

    17 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • moment kind

    38 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • policy kind

    1 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • profile kind

    4 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • prompt kind

    4 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • rule kind

    109 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • scope kind

    1 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • session kind

    11 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • skill kind

    3 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • taxonomy kind

    10 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • use-case kind

    42 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • artifacts module · behaviorally_verified

    Generated artifacts

    • exposed_through surface:api
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • capabilities module · behaviorally_verified

    Capabilities

    • exposed_through surface:api
    • exposed_through surface:cli
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • continuity module · behaviorally_verified

    Continuity

    • exposed_through surface:api
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • directories module · behaviorally_verified

    Directory contracts

    • exposed_through surface:api
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • distribution module · behaviorally_verified

    Distribution

    • exposed_through surface:api
    • exposed_through surface:cli
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • graph module · behaviorally_verified

    Graphs

    • exposed_through surface:api
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • health module · behaviorally_verified

    Health

    • exposed_through surface:api
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • objects module · behaviorally_verified

    Objects

    • exposed_through surface:api
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • peers module · behaviorally_verified

    Peers

    • exposed_through surface:api
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • perf module · behaviorally_verified

    Performance

    • exposed_through surface:api
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • product module · behaviorally_verified

    Product

    • exposed_through surface:api
    • exposed_through surface:cli
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • repository module · behaviorally_verified

    Repository

    • exposed_through surface:api
    • exposed_through surface:cli
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • trace module · behaviorally_verified

    Traceability

    • exposed_through surface:api
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • web module · behaviorally_verified

    Web surfaces

    • exposed_through surface:api
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • why module · behaviorally_verified

    Why

    • exposed_through surface:api
    • exposed_through surface:cli
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • worktree module · behaviorally_verified

    Worktree topology

    • exposed_through surface:api
    • exposed_through surface:cli
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • HTTP API surface

  • Command line surface

  • Cockpit surface

  • Documentation surface

  • MCP surface

06 / doctrine

Rules a machine decides, not suggestions a model may follow

A rule is a portable file with a class; a rule the tool enforces names the validator that decides it, the commands that run it and the tests that prove it, and doctor walks that chain from the source.

Every rule, with the validator that decides it and the test that proves it →

07 / the finish contract

What “done” looks like when it has to be earned

Real output from the repository's own README, not a mockup. One line per check, each naming what it proved; a failing line carries the command that reproduces it, and nothing is written until every line passes.

  1. 1scope
  2. 2verification
  3. 3state
  4. 4blockers
  5. 5note

Work leaves as completed only when every line passes. Anything else gets a name, not a shrug. The full contract, argument by argument →

majordomus finish
$ majordomus finish --outcome completed --verify-command "make test"
OK   scope         t-20260903193012-a4f1 — 12 touched file(s), all within scope
OK   verification  t-20260903193012-a4f1 — make test — exit 0, 41s
OK   state         t-20260903193012-a4f1 — advanced (head 9b1e2d4)
FAIL blockers      t-20260903193012-a4f1 — unresolved entry in open-questions.md  [reproduce: grep -n 'unresolved' .ai/local/state/open-questions.md]
OK   note          t-20260903193012-a4f1 — 20260903T201455Z--main--9b1e2d4--c0ffee1234567890.md
finish: refused, 1 unmet

One directory in your repository. One source of truth for every agent that opens it.

This page is a projection of the repository it describes. Every feature, count, provider, interface and moment on it came out of the same executable that answers agents, and a stale page fails the build before it can be deployed.

Install Majordomus

Every feature Read the guarantees How this page is derived View on GitHub