The plan

ready

275

blocked

440

active

0

verify

3

done

291

cancelled

18

Derived from the canonical model at 2efeacea031, committed 2026-10-25T14:09:03+01:00. Every milestone in the graph's order, with the release that carried it, is the roadmap. No status is stored: each one is computed from what an issue recorded about itself and from the state of its dependencies. How that works.

Milestones

A milestone is an executable specification of an outcome, not a folder for tickets. Its state follows from its issues and from its own acceptance evidence — never from a count of closed tickets reaching a total.

• M000v0.3.1✓DONE

  Milestone and DAG driven development

  Every non-trivial change in this repository belongs to a milestone specification and to one dependency-linked issue execution contract, validated as a DAG, with status derived rather than asserted, and projected to GitHub and to the website from that one canonical model.

  15 of 15 done

• M001v0.3.1✓DONE

  A blocking question survives a handover

  An unresolved question keeps refusing a completed finish after the work moves to a new task, or the alternative is chosen deliberately and the reason is recorded where the next worker will read it.

  4 of 4 done

• M002unreleased•ACTIVE active

  A durable record names the worker that wrote it

  A durable record either names the worker that produced it or is refused, and a record written from one session can never arrive attributed to another session's task.

  2 of 4 done · 1 ready · 1 blocked

• M003unreleased•ACTIVE

  A session is a durable envelope, and knowledge is compiled from what is already canonical

  A worker with no conversation history can answer what happened, why, what was decided, which evidence supports it, where the canonical source lives, and what to do next — from records and a derived index, with git still the authority over both.

  13 of 17 done · 2 ready · 2 blocked · 1 cancelled

• M004unreleased•ACTIVE

  Performance is executable evidence, and the hot path does no canonical work twice

  Every public command can be benchmarked from the command registry with cold and warm distributions, the phases and work counters of any run can be printed, the caches and batch reads that remove repeated work preserve every observable result, an accepted baseline lives in the repository and a check refuses a regression by policy, and the pre-commit hook is fast enough that nobody routes around it.

  19 of 45 done · 14 ready · 11 blocked · 1 verify

• foundationv0.3.1✓DONE

  A supervisory control layer that is real rather than described

  A repository carries one policy, a small set of profiles, durable task state, and a set of commands that refuse work which does not meet a declared contract — with every rule dispatched from a registry that proves it reaches the command claiming to run it.

  0 of 0 done

• runtime-adaptersunreleased○PLANNED

  Profiles become runtime constraints rather than advice

  A profile's axes become opt-in runtime clamps a provider actually applies — read size, output condensation, subagent budget — with the limit derived from the profile rather than configured twice.

  0 of 6 done · 1 ready · 5 blocked

• execution-telemetryunreleased•ACTIVE

  Execution telemetry, only from providers that expose it honestly

  Execution telemetry is recorded for providers that report it truthfully, and absence is recorded as absence rather than estimated.

  1 of 4 done · 3 blocked · 1 cancelled

• cost-per-accepted-outcomeunreleased✕BLOCKED

  Cost per accepted outcome, only on measured data

  The cost of an accepted outcome is computed from measured telemetry and the finish contract that accepted it, and is reported only where both exist.

  0 of 4 done · 4 blocked

• routing-recommendationsunreleased✕BLOCKED

  Routing recommendations derived from measured cost

  The profile a task should run under is recommended from measured cost per accepted outcome, and the recommendation names the data it came from.

  0 of 4 done · 4 blocked

• shared-policyunreleased✕BLOCKED

  Shared policy across repositories and workers

  A policy can be shared across repositories and workers, with local override remaining explicit and drift from the shared source detectable in one command.

  0 of 5 done · 5 blocked

• fly-deploymentunreleased•ACTIVE

  The container image is a projection of the repository model, and its smoke is its evidence

  One canonical deployment object under .ai/repo/deployments/ describes the image; a typed Rust model parses and validates it; the Dockerfile, its ignore file, the GHCR image that docker-image.yml and release.yml build, its smoke derived from the route registry, the doctor checks, the documentation and the cockpit view are projections of that object and of the capability registry, each checked for drift. The published image runs as a non-root user, carries no secret and no developer path, answers live and ready in its smoke, and has measured size, cold-start and memory baselines. Re-scoped 2026-10-14 from a Fly.io deployment, which the owner disconnected on 2026-10-12.

  5 of 29 done · 9 ready · 15 blocked · 9 cancelled

• web-sign-inunreleased○PLANNED

  The deployed surfaces know who is asking, and the identity providers are data

  One canonical identity-provider kind under .ai/repo/identity/providers/ describes each provider as data: its issuer, its endpoints or its discovery document, the scopes requested, the claim that carries a stable subject and the environment variable names its credentials arrive in. A single OpenID-Connect-shaped flow in the executable serves every provider in that directory; Google and Facebook are two objects, not two code paths. Sessions are cookie-borne, signed, short and revocable; identity is attached to a request once, in the router, and every surface — HTTP, Cockpit, OpenAPI, MCP — reads it from the same place. The capability registry's effect classification, not a per-route list, decides what an anonymous reader may do, and the OpenAPI document and the Cockpit both state that decision because both project it from the registry. Striking a provider is deleting one file and regenerating.

  0 of 8 done · 1 ready · 7 blocked

• capability-graphunreleased•ACTIVE

  One capability graph, two projections, and no second inventory of what this repository can do

  One typed, deterministic capability graph composes the registries that already own their facts — it does not replace them — and adds typed relations between them that are inferred where a stable convention exists and declared where it does not. Both the running server and the published site render from that one graph: the static projection is the snapshot, the runtime projection is the snapshot plus live state. Navigation, overview, detail, search, the relation view and the coverage matrix are all derived, a dangling relation fails generation rather than rendering as a missing section, and a capability that exists with no documentation, no test or no enforcement is visible as such rather than indistinguishable from one that has them.

  11 of 34 done · 8 ready · 15 blocked

• external-workspacesunreleased•ACTIVE

  An external workspace is read the way this repository reads anything else, and its content never becomes public by accident

  A workspace is a declared object of the layer — vendor, identity, what the operator authorised, which browser profile reaches it, which capabilities it is expected to have — and rides the existing kind pipeline onto every surface with no code that special-cases it. Its content is synced by the Node tooling layer that already drives the system browser, lands under `.ai/local/workspaces/`, carries provenance and a support level on every record, and is read back through exactly one capability shaped like `continuity`: served, never published. A sync is incremental from a durable checkpoint, idempotent on replay, fails closed when an observed contract breaks, and never writes a credential anywhere.

  2 of 12 done · 1 ready · 9 blocked

• two-folder-integrationunreleased•ACTIVE

  A repository that adopts Majordomus gains two directories and two lines, and can give them back

  Adoption is a reconciliation, not a template copy. One typed repository model is discovered once and every consumer reads it. A desired integration is computed from that model, diffed against what the repository actually holds, and applied as the smallest mutation that closes the gap — with everything Majordomus owns living under `.ai/` and `.majordomus/`, and anything outside those two namespaces reduced to a small managed bridge whose ownership is recorded. Running the reconciliation twice changes nothing the second time, and uninstalling gives back exactly what was taken and nothing a person authored.

  1 of 31 done · 2 ready · 28 blocked

• derived-data-integrityunreleased•ACTIVE

  A committed derivation describes something it can be a projection of

  A committed derived artifact is a projection of inputs the commit owns. Landing an unrelated change on the trunk does not invalidate it, a fixture whose object database has no history can still evaluate it, and the staleness refusal exists on the path merges actually take - so the first thing that says no is a check rather than the published site.

  1 of 3 done · 2 ready · 1 cancelled

• work-graph-githubunreleased•ACTIVE

  The projection to GitHub is gated, identified and traversable, and a merged pull request leads back to the outcome it served

  The projection cannot rot silently: a gate runs the drift check on every change that can move the model or the adapter, and drift is a CI failure with the record named. Identity travels with the record rather than being parsed out of its title, so renaming a GitHub title moves nothing and creates no duplicate, and the remote can be a fixture, so which record is which is provable with no network. The reconciliation vocabulary distinguishes the states it currently conflates, so `missing` no longer stands for both a record never created and a record a person deleted, and a remote edit is reported as a remote edit. Above the projection, a pull request names the issue it realises and the edge is derived from git and GitHub rather than remembered, so a merged commit leads back to the acceptance criteria it satisfied and an outcome leads forward to the evidence that it holds. The derivations the shell already computes — ready, blocked, waves, next, status — are readable through the same capability surface as every other thing this repository knows, rather than only from a terminal.

  10 of 12 done · 2 ready

• intent-lifecycleunreleased○PLANNED

  Work is traceable to the intent it serves, and an intent is satisfied only by evidence

  An intent is a typed record above the milestones that realise it: a statement, its invariants, and satisfaction criteria each naming the evidence that settles it. Its stage is derived from the plan's milestone status and its satisfaction from the evidence ledger, never stored. A gate refuses an intent that names no milestone or evidence that resolves to nothing, a session's preflight names the intent its work serves or refuses, the Cockpit shows intents with measured and enforced coverage of its scripts, and a milestone closes on GitHub only when the intents it serves are satisfied.

  0 of 3 done · 2 ready · 1 blocked

• intent-planningunreleased✕BLOCKED

  The plan of an intent is held to it before execution

  An issue names the intent criteria it serves; coverage of every criterion is derived from the plan and refused when a criterion has no work or work has no purpose. The gap a worker observed and the critique of the plan are typed records validated against the intent and the plan, and work does not start on an intent whose plan was never critiqued or has an open blocking finding.

  0 of 2 done · 2 blocked

• development-runtimeunreleased•ACTIVE

  The runtime has a development surface

  A development transition is decided in exactly one place — a `capability!` of kind `command` in the Rust registry — and every surface that offers it is a projection: the CLI, the MCP tool, the HTTP route, the OpenAPI operation and the Cockpit's generated runner form, none of them written by hand. The lifecycle stops being a second program with no surfaces, and the execution history a development surface would show exists somewhere durable.

  58 of 92 done · 21 ready · 13 blocked

• test-evidenceunreleased•ACTIVE

  Every verifiable claim and widget resolves to revision-bound test evidence, on every surface

  Evidence is indexed by subject and judged at the presented revision, as ADR 0087 records. Every claim, rule, feature, command, capability, MCP tool and use case is a subject of one derived index, and every widget that states behaviour names one. Every surface reads its verdict from the tracked ledger alone, through one freshness function and one aggregation, at the revision it presents: the CLI and HTTP and MCP at the working tree or the checked-out commit, the site at the commit it was built from. A trunk run reaches the ledger through a reviewed recording pull request, and a supplementary record (a run record, coverage, a local row) can only weaken a verdict, naming itself when it does. Verified is rendered only for the one proven row of the freshness table, on every surface.

  19 of 32 done · 3 ready · 10 blocked

• public-proofunreleased•ACTIVE

  A visitor sees the product prove itself, and can check every claim it makes

  One recorded scenario tells the whole story — a worker strays, claims it is done, hands over, and is refused until the repository's own test passes — and it drives the homepage hero, its own route, the README's first transcript and the live smoke check, each held to the recorded run by a gate rather than by care.

  14 of 26 done · 6 ready · 6 blocked

• adopter-upgradesunreleased•ACTIVE

  An adopting repository survives a Majordomus upgrade, and what the tool vendors into it is adopter-neutral

  An adopter can upgrade the tool, or vendor its rules, and be told exactly what to migrate before anything refuses its commits. The migration is a command, not a hand replay. What the tool writes into an adopter (rules, skeleton, scope, candidates) is neutral to this repository and keeps a PR-only trunk clean.

  14 of 20 done · 4 ready · 2 blocked

• a-second-adopter-is-servedunreleased•ACTIVE

  A second adopter is served: what a foreign repository met on its first day is fixed in the tool

  Each finding is fixed generically, with no test of whether the repository is this one: by a declaration, a derivation or a default that an adopter can state. Each fix carries a case that fails without it, its derived files regenerated and its page of the documentation corrected.

  4 of 5 done · 1 verify

• intent-bound-workunreleased✕BLOCKED

  A task is bound to the intent it serves

  `start` names an issue, an intent or a declared exemption, asks the binding capability what the task serves, and refuses a refused binding where the policy requires binding. The task record carries what was named and the revision it resolved at. `context` briefs the worker from the binding, `handover` pins the revision, and `handover --resolve` reports drift.

  0 of 5 done · 5 blocked

• ci-critical-pathunreleased•ACTIVE

  The critical path from a change to its verdict, and from a merge to its verified deploy, runs under a minute warm

  The change-to-verdict path runs p50 under 40 s and p95 under 60 s warm, and merge-to-verified-deploy p50 under 45 s and p95 under 60 s, measured on GitHub with warm, partial and cold reported apart, every skip of a gate explained by the repository's own impact model, and no required test removed, skipped or made advisory to reach the number.

  4 of 32 done · 20 ready · 8 blocked

• measurements-are-tracked-over-timeunreleased○PLANNED

  Coverage and CI cost are kept, exported and drawn over time, from the one measurement each has

  Every master run's coverage and CI cost is kept as a derived series, exported in LCOV and Cobertura from the one measurement docs/COVERAGE.md requires, uploaded to Coveralls and Codecov when their secrets exist, drawn on the site and in the Cockpit, and emitted as OpenTelemetry when an endpoint is configured; no number differs between the gate, the export and the graph.

  0 of 6 done · 3 ready · 3 blocked

• automationunreleased•ACTIVE

  Repository automation is scripted capabilities over typed Rust, not shell

  A capability may be scripted (ADR 0069): a Rhai script inside the Rust executable orchestrates typed capabilities through the one registry, reaches every surface by the projections that already exist, runs in a sandbox with a declared and enforced effect ceiling, and shell shrinks by migration under a gate that refuses new shell without a declared exemption.

  3 of 6 done · 2 ready · 1 blocked

• a-session-leaves-what-it-observedv0.28.0✓DONE

  A session leaves what it observed, and the repository routes it

  Any worker records an observation in one command; the episode boundary derives a candidate that says what it is about and who should look; reading groups recurrence by subject; an episode with nothing to say records that it found nothing.

  3 of 3 done

• runtime-trustunreleased•ACTIVE

  A runtime is safe to reach from another machine, and joining the mesh trusts nobody by accident

  Discovery is not trust, trust is not authorization, and a caller is admitted to change anything only by a key the trust policy names. A host that can reach a runtime reads it and changes nothing it cannot authenticate; every event in the journal was checked against the trust policy that holds now, whether it arrived over a link or from disk; and the limits the documents state are the limits the code enforces.

  6 of 10 done · 4 ready

• runtime-lifecycleunreleased•ACTIVE

  One usable server per checkout starts, attaches, stops and reports its state without races or hidden kills

  Entering a checkout, opening the Cockpit, or starting any number of MCP clients converges on one server for that checkout, which is taken over only when it is dead, stops in order when asked, removes only its own lease, reports a typed state every surface reads, and stays up while any surface uses it.

  7 of 10 done · 3 ready · 1 cancelled

• mesh-journal-convergesunreleased•ACTIVE

  The cooperation journal is durable, converges under any delivery order, and never lets a stale claim win

  An event the runtime accepted survives a crash or is reported lost; replicas with the same authenticated event set produce the same digest after any delivery order; a claim that expired never returns to beat a claim admitted while it was gone, and every claim conflict is announced; every page of the journal returns every event once.

  4 of 14 done · 9 ready · 1 blocked

• mcp-transports-are-reliableunreleased•ACTIVE

  Every MCP transport delivers each request at most once, bounds what it carries, and honours cancellation

  A client gets each answer once or is told the outcome is unknown, can cancel what it started, cannot exhaust the server with one message, and finds its launch configuration generated from the provider declaration and diagnosed by parsing it.

  2 of 7 done · 5 ready

• surfaces-never-disagreeunreleased•ACTIVE

  Every surface projects the same state, says when it was observed, and keeps no list of its own

  A reader on any surface sees the same value, the time it was observed and whether it is stale; a capability added to or removed from the registry appears or disappears everywhere with no consumer edit; a page served beside the write routes runs only script it shipped.

  8 of 18 done · 10 ready

• failure-is-visibleunreleased•ACTIVE

  Every failure the runtime can suffer is bounded, tested or stated, and changes the health it reports

  A client can tell running from ready from mesh-healthy from degraded on one endpoint; no client can hold a worker past a declared deadline; each failure class in a published table names its test or its stated limitation.

  5 of 6 done · 1 ready

• architecture-is-enforcedunreleased•ACTIVE

  A violated invariant fails a gate, and green means every required check ran

  A deliberate architectural violation fails a named gate; a red or cancelled full run is raised the day it happens; a rule is reported proven only when its proof ran; a credential shape never leaves through a response, log or frame; an installed release is proven to serve a repository that is not this one.

  6 of 8 done · 2 ready

• safe-self-updateunreleased•ACTIVE

  Every mesh node follows the published release by itself, versions meet safely, and a release's provenance can be checked

  An enrolled mesh node follows the stable release by itself through the one installer, forward only, activating in order and rolling back a failed activation (ADR 0161); a newer client replaces an older server in an ordered hand-off and an older client is told it is older; a change to any wire or on-disk schema needs a version bump; a released archive carries a provenance attestation the installer checks.

  4 of 12 done · 3 ready · 5 blocked

• every-session-joins-the-meshunreleased•ACTIVE

  Every LLM session joins the Majordomus mesh at start, told the mesh as work

  Any LLM session that starts in a repository with an enabled mesh is on the mesh from its first turn, told who works where on every machine and what waits for it, and a task built outside the mesh is refused by the repository's gates.

  3 of 5 done · 2 ready

• truthful-plan-surfacesunreleased•ACTIVE

  The plan's surfaces are inferred from delivery, and nothing they show is typed beside the repository

  Every plan surface draws every milestone in the graph's order, each issue with its declared status beside the delivery stage inferred from branches, pull requests, merges, tags and the published site; a merged but unrecorded issue turns the trunk red past a window; no milestone carries a typed version; every relationship is a drawn, clickable diagram; every code block is highlighted by one engine with one token-derived palette.

  16 of 44 done · 22 ready · 6 blocked

• browser-computeunreleased○PLANNED

  A browser computes for the project with the server's own code, and the server verifies every result

  One portable core runs on the host and as wasm32 in a browser, held by one executed fixture; the server verifies a browser's result by recomputing it; recording browser results, enrollment and community compute follow only once the owner decides how a remote browser is authenticated and narrowly granted a task (ADR 0170).

  0 of 1 done · 1 ready

• idd-workspaceunreleased✓DONE

  The UI is where the owner directs the work, from an intent to its next move

  One screen of the UI, /ui/idd, starts from an intent and shows its milestones, their issues with status and blockers, the waves the dependencies allow and the dependency graph, each entity a link to its inspector, and every ready issue one click from the move that starts it; delivery and the live channel follow as the capabilities beneath them land.

  6 of 6 done

• idd-reads-at-a-glanceunreleased•ACTIVE

  The intent workspace reads at a glance and leads everywhere it names

  The workspace reads in the order a person asks (what the intent is, what is missing, what to do next, the work, the evidence), every id on it is a link, its numbers are the intent's, its texts render through the UI's one prose renderer, it offers one primary action, and audit rules keep bare ids and raw markdown off every /ui page from now on.

  6 of 25 done · 18 ready · 1 verify

• a-test-fails-when-the-code-is-wrongunreleased○PLANNED

  The suites that guard critical predicates are shown to fail when those predicates are wrong

  Declared critical predicates carry a scheduled mutation run with published survivors, and the compatibility analyzer's algebraic invariants are property tests.

  0 of 3 done · 3 ready

• a-claim-stands-only-on-its-evidenceunreleased○PLANNED

  A claim that something is enforced, tested or delivered stands only on recorded evidence that would have caught it being false

  The owner wants every rule, guarantee and delivered feature that Majordomus states to be backed by a recorded execution at the revision being shown. For a blocking rule, that execution shows a violation being refused. Every way around a gate (an override, a disabled protection, a proposed decision cited as law) must be visible. Any statement that lacks this evidence reads as not proven on every surface, never as done.

  0 of 20 done · 16 ready · 4 blocked

• a-stranger-adopts-it-unaidedunreleased✕BLOCKED

  A stranger installs Majordomus and is stopped from a false done in ten minutes, and every outside first run teaches the tool

  The stranger's first ten minutes are one measured gate, init tells an adopter something true about their own repository, and each real outside run is recorded unedited and turned into cases.

  0 of 5 done · 5 blocked

• the-product-shows-what-it-caughtunreleased✕BLOCKED

  What finish caught is counted from the ledger and compared on the benchmark, never asserted

  One read over the ledger answers what finish caught and what it cost, a refusal nobody answered is separated from a caught one, /ui shows it, and the benchmark gains an acceptance metric beside its token metric.

  0 of 4 done · 4 blocked

• prismatic-lumenunreleased○PLANNED

  Prismatic Lumen: the owner oversees and moves the whole mesh from one page, which owns nothing

  Lumen is a declared term naming one composed view over the runtime: a page that reads blackboard, peers, mesh and monitor with freshness and reconnect recovery, offers one authorised action whose result comes from the journal, and has measured latency before any is claimed.

  0 of 4 done · 1 ready · 3 blocked

• the-session-domain-is-written-onceunreleased○PLANNED

  The session lifecycle is written by the typed domain, and the shell only parses and renders

  Each lifecycle transition has one implementation in the typed domain; the shell commands keep their arguments, output and exit codes and delegate; a closed record states whether it is complete.

  0 of 9 done · 1 ready · 8 blocked

• entry-proves-what-it-handedunreleased✕BLOCKED

  An episode records the governance and briefing it was handed, and a change is told

  One governance digest computed by one function, recorded per episode with the briefing digest, compared at the next interaction, carried by handovers, identical across every entry surface; every route around the preflight is a case or a stated limit; task start states how far its base is behind the remote's master.

  0 of 7 done · 7 blocked

• knowledge-acts-on-what-it-learnsunreleased○PLANNED

  The repository decides when to evolve its layer, and a session carries it out

  Friction is measured and then derived; each boundary records an evolve readiness verdict the next session is told; evolve output does not feed itself; outcomes are measured; a curated note whose source moved is flagged.

  0 of 5 done · 3 ready · 2 blocked

• campaigns-are-read-as-provenanceunreleased○PLANNED

  A prompt pack is a campaign the index serves and the plan cites

  campaign is a kind; records cite campaigns through provenance and campaigns list what cites them; one command adds a pack safely; an execution of a record that cites a campaign pins the revision it ran.

  0 of 4 done · 1 ready · 3 blocked

• repository-automation-is-typedunreleased○PLANNED

  Repository automation is typed capabilities that Rhai orchestrates, and domain-logic shell only shrinks

  A person, CI and an agent run the same repository automation through one executable with an embedded Rhai engine and typed Rust capabilities; just recipes are derived from the command graph and the commit hook is one call of the executable; shell remains only at declared OS, bootstrap and provider boundaries, and the domain logic left in shell only shrinks; and every migrated unit proved it behaves as its predecessor before the predecessor was deleted.

  0 of 8 done · 3 ready · 5 blocked

• the-runtime-supervises-itselfunreleased✕BLOCKED

  The runtime says what is progressing, waiting or stalled, and repairs only what is safe

  One read capability classifies the runtime's work; a bounded repair loop acts only through ensure, recovery, leases and the reaper.

  0 of 4 done · 4 blocked

• the-host-knows-its-runtimesunreleased✕BLOCKED

  A host knows every Majordomus runtime it runs, with no project open

  A read-only host inventory first, derived from the leases every checkout already writes; a routing answer second. A hub's service is the declared deployment target of the-hub-is-reached-from-any-device, and no host-level resident is built.

  0 of 2 done · 2 blocked

• mesh-connectivityunreleased✕BLOCKED

  Trusted nodes connect across NAT through proven transports, and every surface says which path

  A connectivity decision record, a relayed path through a trusted hub, a signed bootstrap manifest on Pages, and a NAT matrix in the mesh lab.

  0 of 6 done · 6 blocked

• the-mesh-is-operated-from-one-pageunreleased✕BLOCKED

  The owner operates the mesh from one page: every runtime readable, one action authorised end to end

  /ui reads any linked runtime and says which runtime every reading came from, and one mutating operation is authorised, audited and streamed back.

  0 of 2 done · 2 blocked

• the-hub-is-reached-from-any-deviceunreleased✕BLOCKED

  The hub is reached privately from any of the owner's devices, and a public ingress is configuration

  The hub is a declared deployment target with a tailnet ingress, and the external URL is one typed fact.

  0 of 2 done · 2 blocked

• mesh-peers-execute-assigned-workunreleased✕BLOCKED

  Work is offered to a peer by capability under a fenced lease, and runs there as an execution

  An assignment is offered, accepted or refused by a peer whose declared capabilities and execution profile satisfy it, and an accepted one runs through the execution plane under the same authorisation as a local call.

  0 of 2 done · 2 blocked

• an-authorised-node-connects-from-anywhereunreleased•ACTIVE

  An authorised node reaches another across LAN, tailnet or NAT, and says how

  Two trusted Majordomus nodes cooperate whether they share a LAN, a tailnet or neither, choose a working path by themselves, fall back to a relay when no direct path exists, and every surface shows the path in use and why it was chosen.

  1 of 5 done · 4 blocked

• the-mesh-is-operated-from-any-deviceunreleased✕BLOCKED

  The owner understands and operates the whole mesh from one page, on any device

  From a phone, a desktop or a Claude Code session the owner sees which nodes, sessions and tasks are live, what is blocked and why, and performs an authorised action whose result and evidence come back live; the page is a client of the persistent runtime, so closing it or ending a session loses nothing and changes nothing.

  0 of 1 done · 1 blocked

• delivery-flow-is-measuredunreleased✕BLOCKED

  The way from a pull request to a verified publication is measured per phase, and its bounds are read where work starts

  Queue time, run time and lead time per phase are derived readings; the backlog bound is policy and the brief says when it is passed; finish names the pull request it hands on; budgets exist per phase without turning runner wall time into a correctness gate.

  0 of 6 done · 6 blocked

• a-release-is-proven-end-to-endunreleased✕BLOCKED

  Whether a commit may be released, and whether its release arrived, is proved by one read and one case

  release.readiness answers before a tag from the functions the workflow runs; site-deploy never goes back a commit; one case walks a fresh clone to published evidence; the first record commit after I2717 lands is observed with a green evidence job.

  0 of 3 done · 3 blocked

• builds-reuse-the-mesh-cacheunreleased✕BLOCKED

  Builds reuse the mesh cache: compiled Rust, the cargo build directory, mix deps and npm packages, keyed by platform, toolchain and inputs

  Majordomus derives a key for every dependency install and compilation from the repository and the machine, restores it from the local level and then a trusted node's store before the work, saves it after, and is invisible when the store is absent; every local build path of the repository goes through it, and a gate refuses a new bypass.

  0 of 6 done · 6 blocked

• finished-work-reaches-a-verified-releaseunreleased✕BLOCKED

  Finished work reaches a verified release at the pace it is finished

  Work does not end when it is written or merged. A finished change flows to master, to a release whose version the public contract decided, and to every surface that publishes it, at the pace work is finished; the flow is measured, its backlog is loud before it is large, a red trunk holds it, and nothing calls a change delivered before its publication is observed.

  0 of 2 done · 2 blocked

• ordinary-commands-never-buildunreleased○PLANNED

  No ordinary command builds: every entry path fails fast or answers through a release of the same generation

  Every entry path and every gate calls the tree's executable, a missing or stale one fails fast naming the explicit build or answers through a release whose generation matches, and no caller passes silently.

  0 of 1 done · 1 ready

• the-ui-works-on-a-phoneunreleased○PLANNED

  Every first-party surface works on a phone, and the primary flow is accepted there

  The narrow-screen menu behaves as one tested component on /ui and /cockpit, the audit refuses a control a thumb cannot hit, the dense screens have a phone projection, and the IDD loop is accepted at the floor width.

  0 of 4 done · 2 ready · 2 blocked

• every-surface-follows-what-changedunreleased○PLANNED

  Every surface follows what changed in the repository by push, and a surface that does not says so

  Executions are a monitor source; the Observatory is told over /events; a write by any client reaches the workspace; every live surface states its transport in ADR 0158's words; a follower converges after loss; a kiosk keeps following for days.

  0 of 8 done · 5 ready · 3 blocked

• a-visitor-understands-and-checks-majordomusunreleased•ACTIVE

  A first-time visitor of majordomus.dev understands what Majordomus does and can check every claim it makes

  The hero links every recorded refusal and the challenge, every problem and step leads to its derived features and evidence, and the published page is probed after deploy.

  6 of 7 done · 1 ready

• a-derive-answers-within-a-secondunreleased✕BLOCKED

  An ordinary derive answers in under a second, runs independent nodes in parallel, and a budget gate holds it

  Derive scenarios (no-op, one input, batch, plus the ten of c255#7) are bench targets under the existing benchmark policy. bench --check refuses a regression. Independent nodes run in bounded parallel against one immutable snapshot, with output identical under any order, and a derive's whole output set is published atomically.

  0 of 2 done · 2 blocked

• the-plan-says-what-a-fix-unblocksunreleased○PLANNED

  The plan says what finishing an issue unblocks, and why each blocked issue is blocked

  One counterfactual evaluator (plan.impact), a published impact page, set preview and blocked classes, all from plan.rs's readiness rules.

  0 of 4 done · 2 ready · 2 blocked

• intent-intakeunreleased✕BLOCKED

  A received brief is a campaign revision whose requirements are reconciled into the one plan

  A campaign revision's requirements get content-derived identities, are classified against the existing intents and issues into a draft, a later revision reports only the criteria whose source changed, and every intent shows the segments it was derived from.

  0 of 4 done · 4 blocked

• a-promoted-record-opens-its-messageunreleased○PLANNED

  Every record promoted from a workspace cites the message it came from, and the UI opens it for the operator who holds it

  A typed workspace: reference on every record kind, valid in every checkout, resolvable where the store is held, drawn as a link on /ui and as text on the published site.

  0 of 5 done · 1 ready · 4 blocked

• a-workspace-reaches-the-repositoryunreleased✕BLOCKED

  A vendor workspace reads the repository, and proposes to it only where the owner has decided it may

  Read-only connector first; a proposal path only after an ADR amends ADR 0126.

  0 of 2 done · 2 blocked

• a-provider-carries-the-contract-nativelyunreleased○PLANNED

  Each agent client carries the contract through its own extension points, generated once and checked for drift

  One generated Claude plugin, the edit guard wired and then refusing, a Stop-time owed report, extension provenance in doctor, bounded hooks and MCP listing, Codex hook parity where Codex offers the hook, Zed schema associations.

  0 of 11 done · 6 ready · 5 blocked

• a-change-is-judged-in-minutesunreleased○PLANNED

  A change is derived in under a second and judged in minutes, and nothing that could have changed is skipped

  The owner should never wait on the toolchain for a change that touched little. An ordinary derive finishes in under a second. A pull request's required verdict arrives within five minutes. Both are measured and enforced, and the speed comes from not repeating work whose inputs did not move, never from weakening a gate.

  0 of 11 done · 3 ready · 8 blocked

• operation-convergenceunreleased✕BLOCKED

  After the alpha, the time from an intent to its verified satisfaction is measured from the records

  Intent-to-verified-done, interventions, replans, governance time and rework are derived per intent from git history and the evidence ledger, and the with/without comparison is read from matched benchmark runs behind ADR 0082's rule.

  0 of 1 done · 1 blocked

• what-a-workspace-decides-reaches-the-repository-with-its-sourceunreleased✕BLOCKED

  What the owner decides in a vendor workspace reaches the repository, and every promoted record opens the message it came from

  The owner thinks aloud in the ChatGPT project. What the owner decides there is read into this checkout's own store, promoted by a person into intents, ADRs, milestones, issues and knowledge, and every promoted record names the conversation and message it came from, so that from the UI one click opens that message for the operator who holds the store, while the public repository and site carry only the reference.

  0 of 2 done · 2 blocked

• every-sessions-usage-is-observedunreleased•ACTIVE

  What every AI session consumed is observed from the provider, attributed to the work it served, and never estimated into a fact

  Token consumption, model and cost of every session of a declared provider (docs/generated/providers.md) on this repository are recorded automatically from what the provider itself reports, and recorded as not observed, with the reason, where the provider reports nothing Majordomus can receive; they are attributed to session, task, issue and intent, shown in /ui with a click-through to the reported event, and used to judge what Majordomus costs and saves, with no estimate shown as a measurement.

  1 of 13 done · 3 ready · 9 blocked

• the-ui-runs-and-explainsunreleased○PLANNED

  The UI runs any capability and explains what needs the owner, whose version it shows and where its time went

  I3225, I3226, I3227, I3228, I3229 and I3230 close these gaps on the existing screens.

  0 of 6 done · 2 ready · 4 blocked

• a-finish-reads-the-criteria-its-work-servesunreleased✕BLOCKED

  A finish reads what its work serves

  The completion policy asks the intent engine what stands for the work a task named, refuses completed while a served criterion is unmet or a guard is violated where the policy says completed means complete, and decides nothing about any intent.

  0 of 1 done · 1 blocked

• the-proof-tests-are-registered-before-they-rununreleased○PLANNED

  The six proof tests are registered as validated protocols, each frozen by its own digest, and every trial is a typed record that publishes only what its basis permits

  A validated proof plan names the six tests. Each protocol is frozen by its own digest; a paired protocol references its suite's registration block by digest. One typed trial record serves T1, T3, T5 and T6, refuses what its protocol does not declare and redacts what its publication basis does not permit.

  0 of 3 done · 1 ready · 2 blocked

• the-proof-scorecard-is-publishedunreleased○PLANNED

  One derived scorecard publishes every proof test's computed status, losses included, on every surface, and no value claim stands without a passed test

  economics.proof computes six rows from committed records and is served by CLI, HTTP, MCP, /ui/evidence and the site economics page; a guaranteed claim and a homepage value word stand only while the settling test reads passed.

  0 of 6 done · 1 ready · 5 blocked

• a-foreign-repository-is-adopted-and-measuredunreleased○PLANNED

  A repository not built around Majordomus is adopted from the published installer to an accepted finish, and its overhead and friction are recorded without exposing what its basis does not permit

  A declared protocol says which repository may be adopted, what is recorded and what may be published. At least one admitted foreign repository has a committed T1 trial record from the published installer to an accepted finish, with step times, overhead against declared budgets, footprint classes and every friction tied to an observed event and cited by an issue. The record is published whatever its outcome.

  0 of 7 done · 1 ready · 6 blocked

• the-corpus-is-registered-before-it-runsunreleased✕BLOCKED

  A corpus of 20 tasks, stratified by a difficulty proxy measured and registered before the new tasks are written, is registered with its analysis, run order, stopping rule and a pinned release

  suites/corpus.yaml is a registration committed before the first run: 20 tasks in three strata whose cut-offs on a measured proxy were registered before the new tasks existed, each task proven failable and passable and reviewed by someone other than its author, a seeded interleaved run order, a stopping rule, and a treatment pinned to one released version.

  0 of 6 done · 6 blocked

• a-registered-corpus-judges-majordomusunreleased○PLANNED

  The registered corpus judges the same agent with and without Majordomus, by an exact task-level test on accepted results, and the verdict is published with its losses

  The blocking chain is cut or re-scoped by recorded decisions; the calculator decides the primary outcome by an exact task-level test and reports secondary outcomes without a verdict word; the corpus is run in both arms and the verdict, losses included, is published on the T2 row.

  0 of 4 done · 2 ready · 2 blocked

• every-task-states-its-delivery-economicsunreleased○PLANNED

  Every task states its delivery economics: wall time, typed human interventions, CI reruns, spend and acceptance, each from a named record or said not observed

  One capability, economics.tasks, served by CLI, HTTP and MCP, answers one record per task with every field either a value with its class and record ids or not observed with a reason, never zero for an absence.

  0 of 6 done · 1 ready · 5 blocked

• delivery-economics-are-measured-over-declared-windowsunreleased✕BLOCKED

  Delivery economics are measured on corpus runs and on real work over a window registered before it opens, and published with their denominators and losses

  Corpus runs answer the economics.tasks shape; a delivery window registered in the proof plan before it opens is measured at its close into a committed T3 record that the scorecard reads.

  0 of 3 done · 3 blocked

• the-mesh-is-measured-against-one-agentunreleased✕BLOCKED

  Coordinated workers on the mesh are compared with a single agent on the same batch tasks, at quality held by a registered non-inferiority guard

  The runner runs a coordinated-workers arm; batch tasks compose existing corpus tasks; a registered suite compares it with a single agent; the verdict on wall time is allowed only under a non-inferiority guard on accepted share, and is published on the T4 row.

  0 of 5 done · 5 blocked

• recovery-from-injected-faults-is-provenunreleased✕BLOCKED

  A killed worker, a cut connection and a conflict are injected on purpose, and recovery is proven without lost work or duplicate completion

  A conservation reading counts completions per issue, unreachable commits, stranded claims and multiply-consumed handovers; the T5 protocol registers three fault kinds; mesh lab scenarios and live single-host trials inject them; the T5 row publishes every trial.

  0 of 5 done · 5 blocked

• a-newcomer-reaches-a-first-verified-intentunreleased○PLANNED

  A newcomer reaches an intent whose verdict is satisfied, in a repository of their own, using only what the getting-started page shows

  A criterion can cite the repository's own declared verification; documented commands take a newcomer from a proposal to a satisfied verdict; a scripted stage proves the path with zero undocumented commands; newcomer trials under a registered protocol are published on the T6 row.

  0 of 5 done · 1 ready · 4 blocked

• a-paste-is-decomposed-by-a-skillunreleased○PLANNED

  A pasted brief is decomposed into the plan by a skill, and never kept verbatim as an intent statement

  A multi-paragraph, Markdown or over-length paste given to intents.propose on any transport writes nothing and answers invalid_input, naming the skill decompose-a-brief and the digest of the paste's canonical text. The /intent alias, the domain skills, the Cockpit runner and the intent workspace lead to that skill instead of stopping at the refusal. The skill keeps the paste as a campaign whose digest equals the refused one, maps it to the existing plan, drafts only what is new, has the draft critiqued, derives and validates it, and offers its first wave on the mesh without claiming it. A test holds a decomposition of the skill's output shape valid under plan validate and intent validate.

  0 of 6 done · 1 ready · 5 blocked

• a-prompt-reaches-the-work-it-servesunreleased✕BLOCKED

  A captured prompt is matched to its existing intent and recorded on the task that follows, joined to its outcome and evidence, shown on /ui and the Cockpit, read only on its own machine and never published

  The first vertical slice of the pack, with the privacy gates landed before the first reader of the prompt archive: UserPromptSubmit, then capture with a namespaced idempotency key, a deterministic match against existing intents, the task that records the prompt it followed (the validated state change, through the task lifecycle that owns it), that task's outcome and verify command, the evidence state of the criterion it serves, and the matched intent's knowledge on /ui/idd and the Cockpit, pushed on the live channel.

  0 of 9 done · 9 blocked

• an-entity-says-how-it-is-known-and-what-it-affectsunreleased✕BLOCKED

  One entity read names how its record says it is known and when it was observed, identically on every surface, and what a change affects is derived from the same index

  entity.show answers, on every surface from one declaration, a class read from the record and the observation envelope repository.info already uses. Proof stays a pointer (entity.rs:181-185). A test fails on any divergence between surfaces. entity.affected answers what a path set or a revision range touches, with reasons, from the loaded index.

  0 of 5 done · 5 blocked

• knowledge-is-reconciled-before-it-is-reviewedunreleased✕BLOCKED

  What a session proposes as knowledge is reconciled with what the repository already knows before a person reviews it, and a promotion stands on evidence that resolves

  A known fact gets one candidate. Each candidate group names what already speaks about its subject, read from the entity layer rather than from a second derivation. A promotion needs a resolvable reference and records it. An observation can cite the review that found it.

  0 of 5 done · 5 blocked

• an-inference-names-its-source-and-budgetunreleased✕BLOCKED

  Every inference a decision rests on names its model and source, stays inside a declared budget, counts independent sources rather than answers, and is never reached from a hook path

  Each consultation is attributable, and independence is counted by a defined source. Peer critique reviews the evidence. A spent budget decides locally and says so, and consultation usage is economics data with its class. The pack's routing levels are documented as the existing plan outcomes. Hook closures are checked to reach no model. Reuse holds only while its evidence holds, and a poisoned answer stays data.

  0 of 9 done · 9 blocked

• an-outcome-becomes-a-reviewed-planunreleased○PLANNED

  A desired outcome becomes a draft plan that is checked before a record is written

  A desired outcome enters as a typed draft: one document holding a draft intent, its gap, its milestones and the issues with what each serves and depends on. intent draft brief derives what the repository already holds about the outcome; intent draft check judges a draft with the same derivations that judge the tree, as if it were written, and writes nothing; intent draft apply writes a checked draft as records with identities allocated above the high-water mark, and refuses an unchecked one. An advisor may write the draft from the brief; without one a person or a worker writes it, and the check is the same.

  0 of 4 done · 1 ready · 3 blocked

• the-intent-loop-is-proved-end-to-endunreleased✕BLOCKED

  The intent loop is proved end to end, and the plan and the documents say what it does

  One fixture asserts the same intent id, verdict, criterion states, binding standing, disposition and remains on the command line, HTTP, MCP and the Cockpit page. A test tries every bypass the owner packs name and each is refused or exempted by policy, never passed. One case carries a desired outcome through draft, check, opposition, bound start, recorded evidence, a refused and then accepted finish, the GitHub body, a moved revision that stales the evidence and fresh evidence that restores it. The documents and the claims say what the loop does and nothing more.

  0 of 2 done · 2 blocked

• an-unmet-criterion-is-drafted-into-workunreleased○PLANNED

  An unmet criterion is drafted into work from the evidence, and the draft is the same on every run

  `majordomus-cli intent draft gap <intent>` prints a gap record whose conditions are derived from the evidence at the presented commit, with every observation citing the ledger execution or claim it read; `majordomus-cli intent draft plan <intent>` prints one issue draft per criterion no live issue serves, with an identity derived from the intent and the criterion, so a rerun on unchanged inputs prints the same bytes and a criterion already served prints nothing; `majordomus-cli intent next` names the next READY issue that serves an unmet criterion and whose binding would be accepted, with why each issue ranked above it was passed over; and an intent under which tasks keep finishing while no criterion changes state is named stalled. Every draft is a read: nothing is written, and a draft becomes a record only through the worker's own commit.

  0 of 5 done · 1 ready · 4 blocked

• command-and-deployment-criteria-are-judgedunreleased○PLANNED

  A command or deployment criterion is met by a recorded run of exactly that command, or an observation of exactly that deployment, current at the presented revision

  A deployment criterion is met when a recorded observation of that deployment served a build containing the newest commit that changed the criterion's serving scope, and reads stale, failing or not_run otherwise, never met on an unreachable, malformed, dirty or undecided answer. A command criterion is met when a recorded execution of exactly the argument vector the criterion names exited 0 at a revision the evidence module's one freshness function judges current, with the scope it serves as its inputs; a different command exiting 0 meets nothing. Both carry the same evaluation a test criterion carries. The negative cases are executable, the claim is guaranteed with its test, and intent-lifecycle can be satisfied.

  0 of 3 done · 1 ready · 2 blocked

• the-mesh-works-out-of-the-boxunreleased•ACTIVE

  The mesh works out of the box: trusted machines find each other by every means and their sessions cooperate from the first turn

  A trusted machine that starts any Majordomus surface in a repository with the mesh declared is linked to every other trusted machine on the LAN or tailnet without a hand-written address, every worktree takes part, and what the mesh holds can be read in one tool answer.

  3 of 9 done · 5 ready · 1 blocked

• everything-is-followed-in-one-streamunreleased•ACTIVE

  Everything that happens in the repository is followed in one stream

  majordomus monitor is the one stream: a typed, cursor-paged feed of signals from every source, with the heartbeat noise folded away and what is addressed to the reader marked and listed first, served by the running server over HTTP, MCP and the command line (with --follow), shown live in the Cockpit, printed at every session start, named by the provider bootstrap, documented and released.

  3 of 8 done · 3 ready · 2 blocked

• a-version-follows-the-workunreleased○PLANNED

  Landed work is released as a measured version, and how long it has waited is a finding

  One capability, release.currency, answers how much landed work the trunk holds past the last release, since when, and which version the contract requires for it. The brief, doctor and /ui/delivery read it. A task holding the release seat cannot finish completed once that work has waited past its threshold. project.land-and-publish names the capability's case as its proof.

  0 of 4 done · 1 ready · 3 blocked

• peer-blackboardunreleased○PLANNED

  The peer blackboard is one projection, pushed live to every surface

  One capability computes the blackboard from the records that exist; a change of the board or the journal is pushed over one WebSocket to every page that follows it, with the monitor's cursor for resume; /ui, /cockpit and the home page read the same frames; the published site carries a public-safe snapshot labelled as one.

  0 of 9 done · 1 ready · 8 blocked

• a-derive-does-only-the-work-its-inputs-changedunreleased•ACTIVE

  A derive does only the work its inputs changed, and can say why

  The derivation is a typed graph the executable owns: every producer is a node with declared inputs and outputs, every node has a key computed from the bytes it reads, a read-only plan says for each node whether it would be reused or regenerated and why, and an incremental run regenerates only the nodes whose keys moved. The full derivation stays as the oracle, and a test holds the incremental result byte-identical to it.

  1 of 12 done · 2 ready · 9 blocked

• a-derivation-computed-once-is-reusedunreleased✕BLOCKED

  A derivation computed once is reused by every worktree and by CI, and the incremental path becomes the default on evidence

  A node's outputs are kept under its key outside every work tree, restored only after their digests are verified, bounded in size and age, and shared by the worktrees of one machine and by CI runs. The machine lock covers the moment a worktree's files are written and no longer the computation. The incremental path is the default only after the differential case, the measurements and a rollback case exist, and scripts/derive --full remains.

  0 of 5 done · 5 blocked

• one-kit-on-every-surfaceunreleased○PLANNED

  Code, charts, controls, embeds and shell blocks are one kit on every surface, declared in the design book and held there by a gate

  A reader meets one code block, one chart, one copy control, one tab control and one shell block, whichever surface they are on: the site, /ui, the Cockpit or the docs. Each is declared once in the design book with its tokens, and a gate fails the change that renders one another way, so the kit stays one as the surfaces grow.

  0 of 8 done · 2 ready · 6 blocked

• landing-survives-any-sessionunreleased○PLANNED

  Landing green work survives any session, any restart and any machine

  Landing green work on master never waits on a person or on one session staying alive.

  0 of 6 done · 2 ready · 4 blocked

• merging-and-referencing-are-enforcedunreleased○PLANNED

  Merging and referencing are enforced: every pull request carries its metadata, every reference resolves, every number is taken once

  Merging and referencing are projections, typed commands and gates: every pull request carries its metadata from the records, every reference resolves on master, every number is taken once.

  0 of 10 done · 3 ready · 7 blocked

• every-model-call-is-paid-from-a-declared-sourceunreleased○PLANNED

  How a model call Majordomus starts can be paid is declared by the vendor with evidence, and each call names the source it was declared to draw on

  Each vendor declares its funding sources with vendor evidence, an Anthropic API advisor lets a held grant pay for review, and each run and consultation carries the funding kind the owner declared for it, in I3292's one vocabulary.

  0 of 3 done · 2 ready · 1 blocked · 5 cancelled

• a-session-proceeds-through-the-meshunreleased○PLANNED

  A session proceeds through the mesh: it finds the work, claims it once, runs it watched and stops when the intent is met

  A session asks /proceed what to do, receives one idempotent work order derived from intent_realization and the claim-aware plan, takes it under a mesh claim held by the run, starts it once, reports it and schedules its own next step until the intent is met; /watchdog wakes, hands over and reaps a stalled loop from deadlines; heavy work shares the machine through one slot.

  0 of 10 done · 5 ready · 5 blocked

Execution waves

A wave is a layer of the dependency graph: an issue sits one layer past its deepest dependency. Sharing a wave is necessary for two issues to run at the same time and is not sufficient — overlapping declared scope serialises them, and that is reported below the graph on each milestone.