A snapshot: read at commit 707a04c7ce8 on 2026-10-18T00:01:48Z by majordomus 0.29.0. Nothing on this page is read again. See it live
Documentation
What the product does, and where it is written down.
Every product feature as the layer declares it, every document of the repository, and every surface that serves or publishes them.
- Features29objects.list /count
- Documents347objects.list /count
- Surfaces11web.surfaces /surfaces
What the product does
Each feature as one file of the layer declares it.
- benchmarksEvery claim about speed is a recorded measurementThe 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.
- ciCI planned from one model, the site deployed from its verified runThe 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.
- cockpitThe Cockpit: the registry rendered for a personAt /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.
- commitA commit message is a value this repository judges, not a convention it hopes forThe same parse the changelog reads the history with decides whether a new message passes. The policy is data in the repository's own policy file, its subject width measured from the history rather than taken from the convention. The scope vocabulary is observed from at most 1500 commits of the log, so a subsystem committed today is in it today and a scope nobody uses sinks on its own. A plan over the working tree carries a fingerprint of repository, worktree, HEAD and change set, so a plan acted on after the tree moved is refused rather than applied - and a change set holding generated files is one commit, because only the last of several could carry current derived data.
- contextEvery directory of the layer carries its contract, and a worker reads what appliesEvery 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.
- continuitySessions, prompts and handovers that outlive the conversationTask 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.
- coordinationSeveral agents on one repository, without stepping on each otherA 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.
- coverageNew code is covered, measured once and asked two questionsscripts/rust-coverage is the one coverage authority: a single cargo-llvm-cov export, test code excluded from both sides of every fraction, one rule for lines, functions and regions. Three questions read that judgment — a crate-wide line floor, a floor over the session/continuity domain, and the changed-code differential gate that refuses new debt while leaving untouched legacy debt alone. The differential intersects the export with the lines git says a change touched against the branch's merge-base, working tree included, and distinguishes PASS, FAIL, UNKNOWN and BLOCKED so a crashed tool or an unresolvable base is never a silent green.
- declare-onceDeclare once, derive every interfaceOne 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.
- deploymentsA deployment is one canonical object, and every artifact built from it is generated from itOne deployment object per deployment of the executable, validated against the registry this process built; the container image definition and its ignore file are generated from it and checked for drift.
- doctrineRules a machine decides, wired, tested and CI-blockingEvery rule is a portable Markdown object with front matter, and it is enforced in one of three declared modes: a validator the dispatcher runs, a gate or case that proves it, or a stated reason why no program can express it. Doctor walks the dispatch chain from the source, refusing a validator nobody declares and a declaration nothing runs; the proof graph walks the other relation, joining each rule to the tree and to the runs recorded against it, so that a rule naming a case which was deleted is reported as reading enforced rather than being it.
- economicsToken economics, measured from matched runs and never typedA task corpus runs in a real harness twice — without Majordomus and with it — and the provider's usage, the gate verdicts and the context compiler's counted selection are recorded as raw facts; one calculator derives pairs, distributions, seeded bootstrap intervals and the one statement the methodology's publication rule allows, projected to the CLI, HTTP, OpenAPI, MCP, the Cockpit, a generated report and the site; economics check refuses any savings number typed by hand.
- evidenceA claim is proven by a run that happened, not by a file that existsThe claims matrix binds a claim to a test by path, and a path resolving says a file exists rather than that anything ran. The ledger records the latest execution of every test with its provenance; the join is derived on every read and answers, per claim, whether the repository can honestly call it proven, only-not-invalidated, stale, failing or never run.
- finish-contractDone is a contract, evaluated line by line and refused when unmetA 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.
- installOne command to install, one to initialise, nothing else to trustOne 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.
- interfacesOne registry over the command line, HTTP, OpenAPI, Swagger UI and MCPThe 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.
- knowledgeDecisions and knowledge that compound instead of evaporatingDecisions 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.
- meshSessions on several machines work one repository without collidingEach runtime is a key-authenticated participant; discovery (multicast, broadcast, rendezvous, seeds) only finds candidates, and a signed handshake admits a link only for the same repository, a compatible protocol and a trusted key. Linked runtimes replicate one signed event journal every heartbeat and fold it into the same state everywhere, so an exclusive claim on one machine refuses an overlapping claim on another, a handover published on one is consumed on another, and a runtime that crashes expires everywhere on its own. The CLI, HTTP, OpenAPI, MCP and the Cockpit render the same state, and every guarantee is held by tests over real processes and a container lab on a real network.
- modelsThe models the world offers, declared once and routed with reasonsshare/models.yaml declares vendors and models in one place, in routing's preference order, with provenance stated and pricing deliberately absent; models.list and models.route project the catalogue and its explainable routing to the CLI, HTTP, OpenAPI, MCP and the Cockpit, credential presence is reported without any value being read, and nothing anywhere calls a model — the crate's no-network boundary stands.
- observatoryThe Observatory: the repository and its mesh, drawn for a wallAt /ui/observatory, and at /ui/kiosk filling the window unattended, the shared server draws the machines of the mesh and their runtimes, the newest events of its journal, the milestones of the plan, the dimensions of health, the published releases and the sessions cooperating, from the same capabilities the other screens read. The published site carries it as a snapshot that says which commit it was read at.
- planningMilestones and issues as data; status derived, never storedMilestones 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.
- policyOne policy, projected into every tool's instruction fileA 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.
- provenanceEvery record names the commit, the branch and the episode that made itThe 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.
- reasoningReasoning that works with or without advisors, and review that is recorded rather than claimedshare/advisors.yaml declares advisory roles by reference to the provider table and the model catalogue; availability is derived from presence and recorded outcomes, with no network; a pure policy plans review by capability and treats no advisor as a structured local review; one writer records assessments, consultations, disagreements settled by experiment, conclusions with computed review counts, and validations; and the state reaches the command line, HTTP, MCP, the Cockpit, the environment banner, doctor, the context briefing and the derived handover.
- skillsSkills are procedures as data, discovered and checked, never registeredA 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.
- uimajordomus ui: the delivery, for a personAt /ui the shared server lays out the delivery in the project's own words, composed only of what capabilities answered, asked together so the first screen paints in the time of its slowest source; a panel whose source is slow arrives on its own route, and the Cockpit beneath it is one click away for the source of any value.
- use-casesEvery use case is executed against the tool, not describedA 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.
- whyThe failure modes it answers are objects, not marketing pagesMoments, 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.
- worktreesOne branch, one worktree, at a path derived from gitThe 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.
objects.list1 msAPI/api/v1/objectsMCPmajordomus_listtechnical view
Documents
The project's documents under docs/, by title.
| Document | Where it lives |
|---|---|
| Adoption | docs/ADOPTION.md |
| First run in a foreign repository — forensic finding | docs/ADOPTION_FIRST_RUN.md |
| Archiving the repository | docs/ARCHIVE.md |
| Backlog | docs/BACKLOG.md |
| The session brief — `majordomus brief` | docs/BRIEF.md |
| Capabilities — one definition, every interface derived | docs/CAPABILITIES.md |
| The catalogue | docs/CATALOGUE.md |
| Continuous integration | docs/CI.md |
| CLI specification — `majordomus` | docs/CLI.md |
| The Cockpit — the registry, rendered for a person | docs/COCKPIT.md |
| The Cockpit as a development surface: baseline, archaeology and gap matrix | docs/COCKPIT_IDE_AUDIT.md |
| The command graph | docs/COMMANDS.md |
| The commit | docs/COMMIT.md |
| Concepts | docs/CONCEPTS.md |
| Scoped context | docs/CONTEXT.md |
| Continuity — how work survives the session that was doing it | docs/CONTINUITY.md |
| Coverage: one measurement, two questions | docs/COVERAGE.md |
| Delivery | docs/DELIVERY.md |
| Prismatic Majordomus | docs/DESIGN.md |
| The design system — one declaration, every surface | docs/DESIGN_SYSTEM.md |
| The development runtime | docs/DEVELOPMENT_RUNTIME.md |
| Diagrams and charts | docs/DIAGRAMS.md |
| Distribution | docs/DISTRIBUTION.md |
| Doctrine | docs/DOCTRINE.md |
| Dogfooding | docs/DOGFOODING.md |
| Canonical ownership and derivation | docs/DYNAMICITY.md |
| Economics | docs/ECONOMICS.md |
| Editors and agents | docs/EDITORS.md |
| Entering the repository | docs/ENTRY.md |
| Repository entry: what is automatic, what is decorative, and where it breaks | docs/ENTRY_AUDIT.md |
| The repository environment — one snapshot, every surface a rendering | docs/ENVIRONMENT.md |
| Evidence — what ran, against which commit, and whether it still proves anything | docs/EVIDENCE.md |
| Executions — watching a capability call happen | docs/EXECUTIONS.md |
| Extraction Report — Prismatic Majordomus v0.1 design phase | docs/EXTRACTION_REPORT.md |
| GitHub Pages architecture | docs/GITHUB_PAGES_ARCHITECTURE.md |
| GitHub Pages performance | docs/GITHUB_PAGES_PERFORMANCE.md |
| Guide — what Majordomus does for a team, how each part works, and the tests that prove it | docs/GUIDE.md |
| The handbook | docs/HANDBOOK.md |
| How Majordomus works — one repository model, many projections | docs/HOW_IT_WORKS.md |
| Installing Majordomus | docs/INSTALL.md |
| Pull-request integration | docs/INTEGRATION.md |
| Integration rollout record | docs/INTEGRATION_ROLLOUT.md |
| Knowledge — what an episode learned, derived at its boundary and promoted by a person | docs/KNOWLEDGE.md |
| Launch kit | docs/LAUNCH.md |
| `majordomus ui` — the product | docs/MAJORDOMUS_UI.md |
| MCP surface — `majordomus mcp` | docs/MCP.md |
| Majordomus Mesh | docs/MESH.md |
| The model catalogue | docs/MODELS.md |
The first 48 of 322; 274 more not shown here.
objects.list3 msAPI/api/v1/objectsMCPmajordomus_listtechnical view
Surfaces
Every public surface of the topology and where it is served.
| Surface | Mount | Where |
|---|---|---|
| The capability registry over HTTP | /api/v1 | served-only |
| The registry, rendered for a person | /cockpit | served-only |
| The documentation, as this process serves it | /docs | served-only |
| The OpenAPI document of the capability registry | /openapi.json | both |
| The Rust crate's documentation, as rustdoc renders it | /rustdoc | both |
| Swagger UI over the OpenAPI document | /swagger | served-only |
| The delivery, for a person: majordomus ui | /ui | served-only |
| The site as it is deployed | / | published-only |
| This process, and everything it serves | / | served-only |
web.surfaces0 msAPI/api/v1/web/surfacesMCPmajordomus_web_surfacestechnical view