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

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'

The scenario

Executed against the real tool, in a repository prepared by installed-wired, every time this site is generated. What follows is not a description of what should happen; it is what happened.

What the tool did

Evidence of the run this page was generated from: pass, 2 step(s). Output is normalised: the repository's path, timestamps, ids and durations are placeholders; nothing else is edited.

Tested by test/cases/94_use_cases.sh, which runs every scenario and refuses a step whose recorded output is not what it produced.

1. 1$ majordomus init --extend exit 0

   the layer is complete; the client configurations at the root start the server

   nothing to add; .ai/ already carries every file the skeleton seeds
   local state: .ai/local/state/ (ignored by git; this checkout's own)
   next: majordomus update      # generate the provider instruction files named in the policy
   next: majordomus doctor      # verify nothing is declared that is not wired
   hooks are not installed by init; add these two lines yourself, doctor verifies them:
     pre-commit: majordomus doctor || exit $?
     pre-push:   majordomus finish --check || exit $?

   • exit 0
   • stdout_contains /nothing to add/
2. 2$ majordomus doctor exit 0

   what the server will serve is what doctor proved

   OK   knowledge   graph — buildable here: 100 node(s), 58 edge(s), compiled into a temporary file and removed; no stored index to go stale
   OK   knowledge   records — 0 record(s) valid against knowledge/v1; every reference resolves  [reproduce: majordomus knowledge check]
   OK   knowledge   candidates — 0 await review, cap 40
   OK   layout      .ai/manifest.yaml — schema ai-repository/v1
   OK   layout      .ai/repo/scope.yaml — version 1; 14 in pathspec(s); every key is one the schema declares
   OK   layout      .ai/local/ — ignored, and nothing under it is tracked
   OK   layout      .ai/ — every section the manifest names exists; the layer is readable without the tool
   OK   layout      .ai/repo/prompts — present
   OK   layout      .ai/local/state/handovers — present, 0 record(s)
   OK   layout      .ai/local/state/checkpoints — present, 0 record(s)
   OK   records     ledger.jsonl — every line is a well-formed event
   OK   policy      39 key(s) — every policy value the code reads is declared, with no reader-side default
   OK   bootstrap   3 projection(s) — each points at .ai/README.md, carries no rule of its own and names only rules in force
   OK   catalogue   0 use case(s), 0 application(s) — every command, doctrine, claim, responsibility, category, setup and cross-reference resolves, both directions
   OK   context     .ai/ — 20 context document(s) carry the contract; ids unique, references resolve, no final document superseded, no cycle  [reproduce: majordomus context validate]
   OK   policy      .ai/repo/policy.yaml — parsed, version 1
   OK   profiles    4 files — parsed; default 'implementation' exists
   INFO adr         .ai/repo/adrs/ — no decisions; nothing to validate
   OK   records     decisions.md — every entry is attributable
   INFO project     .ai/repo/project — no canonical project model here; nothing to validate
   OK   command     surface — 30 public command(s), reconciled against the dispatch table  [reproduce: majordomus doctor]
   OK   doctrine    50 of 61 rule(s) carry a validator — validator, dispatch, propagation, test and CI resolve for every one of the 50; the remaining 11 declare no validator and this check does not examine them
   OK   wiring      doctor-on-commit — wired via .githooks/pre-commit
   OK   wiring      finish-on-push — wired via .githooks/pre-push
   OK   command     coverage — every public command is exercised and refuted  [reproduce: bash test/run.sh 31_command_coverage]
   OK   resolver    handovers — no record for this worktree and branch (absence, not a stale match)  [reproduce: majordomus handover --resolve]
   OK   lifecycle   activity — 0 episode(s) opened here; too few to judge whether the writers stopped
   OK   knowledge   wiring — the close path and the compaction adapter call the deriver
   OK   knowledge   deriver — no episode has closed here; nothing to judge
   INFO project     .ai/repo/project — no canonical project model here; nothing to validate
   OK   projection  AGENTS.md — content matches its stamp
   OK   projection  CLAUDE.md — content matches its stamp
   OK   projection  GEMINI.md — content matches its stamp
   OK   budget      AGENTS.md — 42 lines, budget 150
   OK   links       AGENTS.md — all references resolve
   OK   counts      AGENTS.md — no hardcoded counts
   OK   context     builder — 21 lines, budget 300  [reproduce: majordomus context]
   OK   capture     share/schemas/majordomus/capture/capture.v1 — 2 file(s) describe majordomus.capture/v1 at the path the identifier derives: the record as JSON Schema, the document as protobuf
   OK   capture     .ai/local/prompts — ignored and untracked
   OK   capture     .ai/local/prompts — no records yet; the archive is empty
   OK   capture     .ai/local/prompts — every prompt is present as all three: the record, the Markdown and the YAML
   OK   prompts     .ai/local/prompts — the archive and every record in it are readable by their owner only
   OK   prompts     .ai/local/prompts — no records yet; the archive is empty
   OK   prompt      4 asset(s) — front matter valid, every token known
   OK   records     open-questions.md — every entry parses
   OK   retention   ledger — 1 lines, cap 5000
   OK   retention   handovers — 0 files, cap 200
   OK   retention   checkpoints — 0 files, cap 500
   OK   retention   sessions — 0 records, cap 500
   INFO project     .ai/repo/project — no canonical project model here; nothing to validate
   OK   rules       .ai/repo/rules/vendor/majordomus — every file matches the manifest (1 (1.0.0-alpha.8))
   OK   rules       61 rule(s) — resolve in one deterministic order; vendored baseline plus project rules, no override — 51 carry a validator, 10 are normative text this tool does not check
   OK   rules       blocking — all 44 blocking rule(s) carry a validator
   OK   schema      rules — 61 rule(s) resolve in one order: the vendored baseline in manifest order, then the project's, as a dependency graph
   OK   schema      share/kinds.yaml — 37 kind(s); every one that carries metadata declares a schema
   OK   schema      share/schemas — 54 schema(s), each valid JSON and each applied — by a kind, through an allow-list the tool reads, by a validator that names it, or as a generated document's contract (15)
   OK   records     0 record(s) — every changed_files names work, not generated or local state
   OK   session     .ai/local/session-contexts — ignored and untracked
   OK   session     .ai/local/session-contexts — no working contexts yet; the store is empty
   INFO skill       .ai/repo/skills/ — no skills; nothing to validate
   OK   skill       reachable — no personal command or skill shares a name with a projected skill  [reproduce: majordomus run editors.status]
   INFO use-case    30 advisory gap(s) — not covered by an active use case, and the policy does not require it: command:init command:update command:doctor command:watch command:start command:context command:checkpoint command:handover command:check command:finish command:history command:decision command:question command:prompt command:evidence command:skills command:capture command:search command:doctrine command:plan command:version command:session command:knowledge command:adr command:usecase command:rules command:migrate command:recover command:bench command:archive  [reproduce: majordomus usecase coverage]
   OK   use-case    0 of 30 target(s) covered — every public command the policy requires is named and run by an active use case (policy use_cases.coverage)
   INFO env         - — bash <version>, git <version>, jq <version>, shellcheck present
   WARN clone       unpushed — commits on no remote: main(2) — work on one disk is invisible to every other session and cannot be integrated  [reproduce: git push -u origin <branch>]
   OK   clone       uncommitted — no linked worktree, so no uncommitted work can sit in one
   INFO clone       trunk — no remote-tracking branch, so this checkout's distance from the remote trunk cannot be measured
   INFO clone       release — no remote-tracking branch, so whether the trunk's landed work is released cannot be measured
   ·    reasoning   <decided by the advisors and the executable of the recording machine>
   ·    layout      - — <judged when the recording machine has built the executable>
   ·    budget      doctor — <timed against the policy budget>
   doctor: 0 failure(s)

   • exit 0
   • stdout_contains /doctor: 0 failure/

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.

• majordomus initCreate the .ai/ layer in this repository, and refuse to overwrite an existing one.
• majordomus doctorIt checks governance only: is Majordomus itself healthy, and is every enforcement it declares actually wired here?

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

• ✕blocking AI layer integrityThe repository's AI layer is real: the manifest declares a format this executable reads and every section it names exists, the checkout-local half is ignored by git and nothing under it is tracked, and no project data remains under the pre-.ai .majordomus/ path.
• ✕blocking Projection integrityEvery generated instruction file exists, matches the stamp it carries, and is never silently overwritten after a hand edit.
• ✕blocking Scope integrityA task touches only the paths it claimed; work found elsewhere is not accepted as done.

Guarantees exercised

• ○guaranteed The Rust executable serves the repository's AI layer to an MCP client over stdio, with protocol frames alone on stdout
• ○guaranteed A file of the layer the MCP server cannot read is excluded with a diagnostic naming its path and the index says it is degraded, never silently smaller
• ○guaranteed One shared server serves a checkout: the first majordomus mcp binds loopback HTTP with Swagger UI and MCP over HTTP beside its stdio session and logs the URL, every later client of that checkout attaches to it, and it ends when the last client leaves
• ○guaranteed Nothing a client leaves behind locks another client out of the shared server; a corrupt, empty, stale or abandoned lease is taken over and named, a client that cannot share is served alone with the reason logged, and a signal removes the lease before the server dies
• ○guaranteed Every client attached to a checkout's server is a peer named by its own initialize, and majordomus_peers lists every worker of the repository - its own board and the board of every other checkout, each peer stamped with the worktree it is working in - while majordomus_announce tells the others what it is working on and which paths it expects to touch
• ○guaranteed An MCP client opened in the repository starts the server itself, through the client configurations at the root and bin/majordomus-mcp, without ever building the executable
• ○guaranteed A majordomus:// URI resolves the same way through the MCP resource read, the majordomus_get tool and the HTTP object route, and majordomus://repository answers repository.info as a JSON document tagged builtin

Related use cases

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

• Extend what the executable serves by adding a file, never by rebuilding itAdd a rule, a prompt or a knowledge node to .ai/ and have it appear as an MCP resource, an HTTP route and a reference entry, with the same binary.
• See what the repository holds, and run one of its capabilities, without reading a fileOpen the shared server in a browser and get the whole layer as pages: what exists, where each thing came from, what depends on what, what is failing, and a form that runs any capability.
• Find an object of the layer without reading everythingSearch durable records literally across kinds from the shell, and ask the shared server the same question over MCP with majordomus_search and majordomus_get.
• Say what your work is for, once, and have every surface say itRecord an operational failure mode as one file and have the command line, the API, MCP and the website answer it without registering it anywhere.
• Install the tool in one command, on a machine with no toolchainPaste one line, get a verified binary for this machine, and run majordomus init — no git, no Rust, no Node, no Python, no root, and no way to install an archive whose digest does not match.

The moments this answers

• → had two sessions writing into one checkout without either knowing Two workers in one working tree see each other only as unexplained file changes, and each treats the other as noise.
• → shipped an interface change whose contract document still described the old one A contract maintained by hand beside the code it describes goes stale on the first change that forgets it.