Skip to content

Serve the repository's AI layer to every AI client through one shared server

Open the repository in any client the tool declares a provider for (docs/generated/providers.md) and have each of them read the same rules, prompts and knowledge over MCP from one process, seeing each other.

described Serving the layer to AI clientsbasicoperatoragentwrites state

Situation

Three AI clients are open in one checkout. Each reads .ai/ by hand, none knows the others exist, and the first thing two of them do is edit the same file. The layer is the contract, but nothing serves it and nothing shows who is working where.

What you run

  • init: writes the .ai/ layer the executable serves; the client configurations at the root (.mcp.json, .gemini/settings.json, .codex/config.toml) start bin/majordomus-mcp, which builds the Rust executable when it must
  • doctor: proves the layer and its projections are consistent before a client reads them, and that the MCP client autostart is wired

Scenario

setup: installed-wired
given:
  - 'a repository with the layer installed and its projections generated'
steps:
  - id: nothing-to-add
    run: ['init', '--extend']
    note: 'the layer is complete; the client configurations at the root start the server'
    expect:
      exit: 0
      stdout_contains: ['nothing to add']
  - id: healthy
    run: ['doctor']
    note: 'what the server will serve is what doctor proved'
    expect:
      exit: 0
      stdout_contains: ['doctor: 0 failure']
then:
  - 'an MCP client opened here starts the shared server through bin/majordomus-mcp and reads the same layer'

Outcome

The first client to open the repository is the shared server; every later one attaches to it. Each client sees the same objects as majordomus:// resources and the same tools, lists the other clients with majordomus_peers, and announces its intent and the paths it will touch with majordomus_announce. A lease a client leaves behind never locks the others out, and a client that cannot serve says so instead of serving a degraded layer silently.

No scenario yet

This use case is described, not proved: it names its commands and rules, and nothing executes it. It cannot be more than described until a scenario is added.

Why the tool knows this

The chain from this page to the code: the use case names commands, rules and claims; each rule is dispatched from the registry and each claim names the test that proves it; the scenario above executed the commands. Nothing in this chain is prose about intent.

Over MCP the same layer is reached through majordomus_repository, majordomus_list, majordomus_get, majordomus_peers, majordomus_announce (the MCP surface).

The rules that make it hold

Guarantees exercised

Related use cases

Computed from what they share: claims, rules, commands, category, applications. Nobody maintains this list.

The moments this answers