Průvodce

Toto je praktický doprovod dvou dalších dokumentů. CONCEPTS.md je slovník; HOW_IT_WORKS.md je architektura. Tento jde funkci po funkci: jaký problém odstraňuje, jak funguje, příkazy, jimiž ji uvidíte, a testovací případy, které ji dokazují. Každý zde jmenovaný test je skutečný soubor v tomto repozitáři a Vyzkoušejte si důkazy sami je spouští.

Zralost se uvádí u každé funkce. „V masteru“ znamená sloučeno a otestováno. „Jen větev“ znamená, že práce existuje v otevřeném pull requestu a ještě není funkcí.

Proč to tým chce

Kódovací agenti AI jsou dobří pracovníci a špatní správci. Cena, kterou tým platí, není v kódu, který píší; je ve všem kolem něj. Každý řádek níže je cena, kterou Majordomus odstraňuje, mechanismus, který ji odstraňuje, a test, který ukazuje, že mechanismus funguje.

Čím záměrně není: modelem, kódovacím agentem, orchestrátorem, který spouští pracovníky, databází paměti ani správcem zámků. Pracuje vedle jakýchkoli agentů, které tým už používá, a sám nevolá žádný model.

Prvních deset minut

$ curl -fsSL https://majordomus.dev/install.sh | sh     # installs majordomus and majordomus-cli
$ cd your-repository
$ majordomus init                                       # creates .ai/ and the provider bootstraps
$ majordomus doctor                                     # read-only: is everything declared actually wired?
$ majordomus start "fix login redirect" --scope apps/web/auth
$ majordomus context                                    # what a worker needs, compiled, within a budget
$ majordomus check                                      # scope, state, blockers, selected gates
$ majordomus handover < note.md                         # or: finish --outcome completed --verify-command "make test"

Pro AI klienta vystavuje stejný stav server MCP repozitáře. bin/majordomus-mcp je to, co spouští .mcp.json, .codex/config.toml a .gemini/settings.json, a majordomus-cli serve status vypíše lokální URL Cockpitu, API a Swagger UI.

Jak to funguje, část po části

Vrstva a doctor

Jak to funguje. init vytvoří .ai/: manifest.yaml říká, která sekce žije kde, repo/ je sledován a local/ je ignorován gitem. Repozitář se počítá za dozorovaný, když manifest existuje. doctor je jen pro čtení. Rozešle každou doktrínu, která je na něj vázána: rozvržení, schémata, politiku, vendorovaný balíček pravidel proti jeho hashům, řetěz zapojení doktrín, soubory providerů proti jejich razítkům generování a zapojení hooků. Každý nález nese příkaz k reprodukci.

Vyzkoušejte. majordomus init, majordomus doctor, majordomus doctor --json.

Dokázáno. test/cases/01_init.sh, test/cases/02_doctor_basic.sh, test/cases/68_ai_discovery.sh, test/cases/32_schema_integrity.sh, test/cases/83_doctor_budget.sh.

Zralost. Na master.

Jedna politika, soubor pro každého agenta

Jak to funguje. .ai/repo/policy.yaml je politika neutrální vůči providerům. majordomus update z ní a ze šablon v .ai/repo/providers/ vykresluje CLAUDE.md, AGENTS.md a další soubory providerů. Každý soubor nese razítko s hashem politiky a vlastním hashem obsahu, takže ruční úprava je detekována, nikoli tiše přepsána.

Vyzkoušejte. majordomus update --dry-run, majordomus update --diff CLAUDE.md, majordomus update.

Dokládá. test/cases/03_update.sh, test/cases/13_region_projection.sh.

Zralost. Na master.

Úloha a rozsah

Jak to funguje. start zaznamená jednu aktivní úlohu na checkout s normalizovaným rozsahem a volitelnými závazky (--requires tests,docs,…). check selže na každém souboru změněném od začátku úlohy, který leží mimo rozsah. finish z téhož důvodu odmítne výsledek completed a finish --check běží v pre-push hooku. start a check --overlap hlásí také další worktree, jejichž aktivní úlohy nárokují překrývající se cesty. Toto hlášení je poradní a končí kódem 0.

Vyzkoušejte.

$ majordomus start "rate limiting" --scope apps/api/limits --requires tests
$ majordomus check
$ majordomus check --overlap
$ majordomus finish --check

Dokazuje: test/cases/04_start_check.sh (odmítnutí rozsahu; překryv hlášen s exit 0), test/cases/27_foreign_task.sh, test/cases/108_scope_after_trunk_merge.sh, test/cases/93_scope_policy.sh, test/cases/103_obligations.sh.

Zralost. Na masteru a vynucováno při commitu a pushi.

Profily

Jak to funguje. Profil pod .ai/repo/profiles/ určuje, kolik ceremonií druh práce dostane: sekce kontextu, rozpočty, zda se vyžaduje verify příkaz, interval checkpointů. start --profile jeden vybere; politika jmenuje výchozí.

Dokázáno čím. test/cases/16_profiles.sh.

Zralost. Na master.

Relace a epizody

Jak to funguje. Hooky poskytovatele volají majordomus capture session --event start|compact|end.

• Start otevře epizodu, zajistí, že sdílený server tohoto checkoutu běží, a vypíše briefing.
• Compact odvodí checkpoint.
• End odvodí checkpoint a předávku a poté uzavře jen vlastní epizodu tohoto poskytovatele.

Uzavřená epizoda se stane neměnným záznamem relace, který odkazuje na to, co bylo vytvořeno, a nic z toho nekopíruje. Uzavření proběhne přesně jednou, i při souběhu, a epizoda, kterou nikdo neukončil, se detekuje.

Zkuste to. majordomus session list, majordomus session show <id>.

Dokázáno čím. test/cases/54_session_lifecycle_hooks.sh, test/cases/60_session_lifecycle.sh, test/cases/61_session_envelope.sh, test/cases/220_exactly_once_close.sh, test/cases/222_an_episode_nobody_ended.sh, test/cases/170_provider_lifecycle_declared.sh.

Zralost. Na masteru pro Claude Code, jediného poskytovatele s deklarovanými hooky životního cyklu. Ostatní klienti používají stejné záznamy a povrch MCP bez automatického zachytávání.

Kontext

Jak to funguje. Tři mechanismy, držené odděleně:

1. Kontextové dokumenty. Kontextový dokument je libovolný soubor Markdown pod .ai/, který deklaruje schema: context/v1 a rozsah. context resolve <path> složí dokumenty platné pro cestu, od nejméně specifického. Každý přidává k svým předkům a nahrazené dokumenty vypadnou. context explain říká, proč se každý uplatňuje. context affected jmenuje dokumenty, kterých se změna dotýká.
2. Zkompilovaný kontext relace. context sestaví stav gitu, peery, úlohu, profil, platné dokumenty, otevřené otázky, rozhodnutí, poslední kontrolní bod a předávku, relevantní soubory a historii, přizpůsobené rozpočtu řádků:
   • sekce se zahazují v pevném pořadí;
   • kontrolní bod a předávka se před zmizením zmenší na ukazatel;
   • git, úloha, profil a otázky se nikdy nezahazují;
   • každé vyřazení je uvedeno pod EXCLUDED;
   • stále nad rozpočtem skončí exit kódem 10, nikdy tiše neořízne.
3. Seřazená pracovní množina. majordomus-cli devcontext compile prochází graf objektů od úlohy, řadí podle úrovně autority a relevance a utrácí rozpočet tokenů. Jmenuje vše, co přeskočila. Její jediná dedukce, záměr podle klíčových slov, je omezena pod každým deklarovaným vztahem.

Vyzkoušejte.

$ majordomus context --budget-lines 120
$ majordomus context resolve apps/web/auth
$ majordomus context explain apps/web/auth
$ majordomus-cli devcontext compile --help

Dokládá. test/cases/23_context.sh, test/cases/55_session_context.sh, test/cases/69_context_documents.sh, test/cases/70_context_impact.sh, test/cases/71_context_sync.sh, test/cases/106_context_peers.sh, test/cases/130_context_compiler.sh.

Zralost. V masteru. Shellový příkaz context zatím žebříček v Rustu nepoužívá.

Kontrolní body a předávky

Jak to funguje.

• Checkpoint. Omezená poznámka o postupu, zatímco práce pokračuje. Resetuje hodiny zastaralosti, které měří check.
• Předávka. Záznam jen pro připisování pro toho, kdo pokračuje. Tělo je psané a musí mít # Objective, # Current State a # Next Action. Front matter je odvozený: repozitář, worktree, větev, commit, stav pracovního stromu a změněné soubory. Tělo, které si nárokuje vlastní identitu, je odmítnuto.

handover --resolve najde nejnovější záznam pro stejný worktree a větev, pak pro stejnou větev, nikdy napříč repozitářem. Označí vztah commitu jako exact, advanced, diverged nebo different context a vytiskne verdikt čerstvosti z prahů politiky (fresh, aging nebo stale); zastaralý záznam je označen jako historie, ke čtení jako kontext, ne jako instrukce. Briefing relace aplikuje tentýž verdikt a necituje další akci zastaralé předávky. Blokátor zaznamenaný před předávkou je blokátorem i po ní.

Vyzkoušejte.

$ majordomus checkpoint --derive
$ majordomus handover --derive
$ majordomus handover --resolve

Dokládá. test/cases/20_checkpoint.sh, test/cases/05_handover.sh, test/cases/25_continuity_lifecycle.sh, test/cases/62_session_divergence.sh, test/cases/127_briefing_freshness.sh, test/cases/131_freshness_has_an_age.sh, test/cases/50_blocker_across_handover.sh.

Zralost. Na master.

Rozhodnutí, otevřené otázky a ADR

Jak to funguje.

• Rozhodnutí. Zaznamenávají se s tím, co se rozhodlo, proč a co se zamítlo. Nahrazuje je pozdější záznam, nikdy se neupravují.
• Otevřené otázky. Ukládají se jako stav. Ta, která jmenuje aktivní úlohu, odmítne finish --outcome completed.
• ADR. Žijí v .ai/repo/adrs/ a jsou proposed, dokud je člověk nepřijme. Nástroj odmítne záznam, který se přijímá sám, a čísla ADR se přidělují bez kolizí.

Vyzkoušejte. majordomus decision add "<what>" --why "<rationale>", majordomus question add "<question>", majordomus adr list, majordomus adr next.

Dokázáno čím. test/cases/21_decision_question.sh, test/cases/99_adr.sh, test/cases/271_adr_allocation.sh.

Zralost. Na master.

Plánování: milníky, úkoly, stav a vlny

Jak to funguje. Milníky a úkoly jsou YAML v .ai/repo/project/. Úkol deklaruje závislosti, rozsah, kritéria přijetí, validaci, požadované důkazy a časová razítka přechodů a nemá pole stavu. Stav se odvozuje:

1. Hotovo: nezrušeno, dokončeno a pokryt každý požadovaný token důkazu.
2. Jinak první, který platí z verify, active, blocked (závislost není hotová) a ready.
3. Stav předbíhající své blokátory se hlásí jako předčasné provádění.

Vlny jsou Kahnovo vrstvení grafu závislostí. Cykly nedostanou vlnu a hlásí se. Připravené úkoly ve stejné vlně, které sdílejí cesty, vyvolají varování o konfliktu rozsahu: závislosti říkají, co by mohlo běžet paralelně, rozsah říká, co bezpečně může. plan.transition přesune úkol jen tehdy, když to odvozený plán dovoluje.

Vyzkoušejte.

$ majordomus plan status
$ majordomus plan waves
$ majordomus plan next
$ majordomus plan validate

Dokazuje: test/cases/40_project_model.sh, test/cases/41_project_status.sh, test/cases/42_dag_waves.sh, test/cases/43_plan_command.sh, test/cases/133_plan_transition.sh, test/cases/99_plan_capabilities.sh (čtečka v Rustu je byte-identická s shellovým enginem).

Zralost. Na master.

Záměry: k čemu plán slouží

Jak to funguje. Záměr je záznam pod .ai/repo/project/intents/: co se musí stát pravdou, invarianty, které musí zůstat pravdivé, milníky, které ho realizují, a kritéria, která ho rozhodují, každé se jménem svých důkazů. Nic o něm se neukládá kromě toho. Jeho fáze se odvozuje z plánu a každé kritérium z ledgeru důkazů, takže hotová práce nesplňuje nic, dokud každé kritérium nemá aktuální úspěšný běh. Úkol jmenuje kritérium, kterému slouží, v serves a pokrytí se z toho odvozuje. Mezera, kterou worker pozoroval, a kritika plánu jsou typované záznamy, proti nimž je plán odmítnut. Která práce záměr realizuje, napříč relacemi, providery a předávkami, se spojuje při každém čtení a uzavřená práce, které důkazy odporují, se odmítne. PLANNING.md má celý model.

Vyzkoušejte.

$ majordomus-cli intent list
$ majordomus-cli intent validate
$ majordomus-cli intent coverage
$ majordomus-cli intent preflight --issue <id>
$ majordomus-cli intent binding --issue <id>
$ majordomus-cli intent realization
$ majordomus-cli intent explain <id>

Cockpit ukazuje stejné odpovědi na /cockpit/intents a /cockpit/intents/<id>.

Dokázáno. test/cases/367_an_intent_is_satisfied_only_by_evidence.sh, test/cases/386_a_plan_is_held_to_its_intent.sh, test/cases/388_an_intent_is_realised_across_providers_and_held_to_reality.sh; apps/majordomus-cli/tests/intent.rs pro preflight a apps/majordomus-cli/tests/intent_realization.rs pro povrchy HTTP, MCP a Cockpit.

Zralost. Na masteru a částečná. Úloha, která jmenuje úkol nebo záměr, se podle něj briefuje, a kde politika říká intent.binding: required, start na plánu, který nikdo nezkritizoval, se odmítne; vlastní politika tohoto repozitáře je advisory, což hlásí. Projekce na GitHub uzavírá milník, aniž by četla jeho záměry, a kritérium command nebo deployment není nikdy splněno. Každé z těch dvou je plánované tvrzení v CLAIMS.yaml.

Worktrees

Jak to funguje. Paralelní práce žije v git worktrees na cestě odvozené od větve, <repository>-wt/<branch>, bez čehokoli registrovaného. Pre-commit hook odmítne commit feature větve odkudkoli jinde. worktree migrate přesouvá zbloudilé worktrees s otisky pořízenými před a po.

Vyzkoušejte. majordomus-cli worktree create feature/x, majordomus-cli worktree status, majordomus-cli worktree migrate --plan.

Prokázáno. test/cases/96_worktree_topology.sh, test/cases/114_two_worktrees_one_repository.sh a testy crate v apps/majordomus-cli/tests/worktree.rs.

Zralost. Na masteru a vynucováno při commitu.

Sdílený server, nástěnka a překryv

Jak to funguje.

• Server. Každý checkout provozuje jeden sdílený server, zvolený prostřednictvím souboru leasu. Přežije pád svého vlastníka. serve ensure konverguje k jednomu a serve status hlásí, zda je připraven, zastaralý, nebo neaktuální.
• Peeři. Každý klient MCP, který se připojí, je peer.
• Oznamování. Pracovník oznámí záměr a rozsah pomocí majordomus_announce.
• Nástěnka. majordomus_peers shromažďuje nástěnky každého worktree repozitáře, označí každého peera jeho checkoutem a řekne, zda je odpověď úplná.
• Překryv. Dva rozsahy se setkají, když jsou si rovny nebo jeden obsahuje druhý na hranici cesty.

Překryv se ukazuje při ohlášení, v seznamu peerů a v context. Je to povědomí, ne zámek: nástěnka žije v paměti a neukládá se.

Vyzkoušejte. majordomus-cli serve status, curl -s http://127.0.0.1:8742/api/v1/peers, majordomus context (sekce PEERS).

Dokázáno čím. test/cases/90_mcp_shared_server.sh, test/cases/113_shared_server_survives_a_crash.sh, test/cases/250_the_board_is_repository_wide.sh, test/cases/106_context_peers.sh a apps/majordomus-cli/tests/peer_claims.rs.

Zralost. Na master, v rámci celého repozitáře na jednom stroji.

Mesh

Jak to funguje. Instance Majordomus se mohou navzájem objevit i za hranicí jednoho stroje:

• identita uzlu Ed25519 na uživatele;
• podepsané, omezené obálky přes UDP multicast, UDP broadcast nebo HTTP rendezvous endpoint;
• registr s TTL přítomnosti;
• důvěra deny-unknown, která mění jen popisky.

Je to pozorování: nic se nespouští vzdáleně.

Vyzkoušejte. majordomus-cli mesh identity, majordomus-cli mesh status, majordomus-cli mesh doctor.

Dokládá. test/cases/130_mesh.sh, apps/majordomus-cli/tests/mesh.rs.

Zralost. Na masteru, ve výchozím stavu vypnuto: nový repozitář nemá deklaraci. Tento repozitář provozuje vlastní (.ai/repo/mesh/majordomus.yaml, zapnuto; docs/MESH.md, „Mesh tohoto repozitáře“). Poskytovatel Tailscale ani mDNS neexistuje. Nástěnka peerů a claims se replikují napříč runtimy, na jednom stroji nebo více, přes ověřená spojení (ADR 0067).

Pravidla, doktríny a důkaz pravidla

Jak to funguje.

• Pravidla. Pravidlo je verzovaný soubor Markdown s výrokem, třídou (blocking nebo advisory), závislostmi a volitelně blokem x-majordomus. Jeho režim vynucování se odvozuje z tohoto bloku:
  • validátor, který příkaz spouští, ho činí odeslaným;
  • testy, které kontrola spouští, ji činí kontrolovanou;
  • jen uvedený důvod to činí posouzeným;
  • nic z toho nečiní deklarativním.
• Doktríny. Odeslaná pravidla. doctor kontroluje řetěz každé doktríny: validátor, odesílající příkaz, šíření selhání, test a tvrzení. Kontrola je mutačně testována.
• Důkaz pravidla. Engine pravidel v Rustu redukuje každé pravidlo na jeden stav důkazu, od proven přes gated a not run po dangling a unproven. Pojmenovaný důkaz, který neexistuje, shodí kontrolu rule-proof.

Vyzkoušejte.

$ majordomus doctrine list
$ majordomus rules list
$ majordomus-cli rules report
$ majordomus-cli rules show majordomus.scope-integrity

Dokládá. test/cases/17_doctrine_enforcement.sh, test/cases/18_doctrine_wiring.sh, test/cases/14_wiring_dispatcher.sh, test/cases/67_rule_dag.sh, test/cases/133_rule_graph.sh, test/cases/125_rule_proof.sh, apps/majordomus-cli/tests/rules.rs.

Zralost. Na masteru. Většina pravidel stojí na not run místo proven, protože CI zatím nezaznamenává své běhy do knihy důkazů.

Tvrzení a důkazy

Jak to funguje.

• Tvrzení. docs/CLAIMS.yaml drží veřejná tvrzení, každé se svým zdrojem, implementací, testem a stavem, publikovaná jako /guarantees/.
• Důkazy. Zaznamenané provedení v .ai/repo/evidence/ledger.json: test, runner, výsledek, commit, stav pracovního stromu, otisk a původ.
• Stavy důkazu. Odvozeny z knihy a stromu, nikoli z času:
  • proven: od běhu se nic nezměnilo;
  • vstupy beze změny: něco se změnilo, ale ne vstupy tohoto tvrzení;
  • zastaralé: jeho vstupy se změnily;
  • selhává, nespuštěno, nespustitelné, bez testu.

Vyzkoušejte.

$ majordomus-cli evidence show
$ majordomus-cli evidence claim scope-enforcement
$ MJ_TEST_REPORT=report.tsv bash test/run.sh 04_start_check
$ majordomus-cli evidence stamp --report report.tsv --out report.provenance.json
$ majordomus-cli evidence record --suite report.tsv --provenance report.provenance.json

Dokládá. test/cases/124_evidence.sh, test/cases/77_rust_evidence.sh.

Zralost. Na masteru. Automatické zaznamenávání běhů CI je zatím jen na větvi.

Kontroly a kontrakt dokončení

Jak to funguje. Kontroly jsou kontroly vlastněné repozitářem, deklarované v .ai/repo/ci/gates.yaml, přičemž třídy cest rozhodují, které z nich změna vybere; CI je tenký adaptér nad tímto plánem. check vypíše kontroly, které změna úlohy vybírá, a kontrola, která nikdy nehlásila, je queued, nikdy zelená.

finish --outcome completed projde finish_requires politiky: rozsah dodržen, ověření proběhlo, stav aktualizován, žádné otevřené blokace, poznámka přítomna, povinnosti splněny, kontroly prošly, publikace aktuální. Každý nesplněný řádek odmítne s exit kódem 10 a jmenuje, co chybí. Odmítnuté dokončení je běžná událost životního cyklu, ne chyba, kterou obcházet.

Zkuste to. majordomus finish --check, majordomus finish --outcome completed --verify-command "make test".

Dokázáno. test/cases/06_finish.sh, test/cases/32_refusal_lifecycle.sh, test/cases/94_ci_plan.sh, test/cases/131_completion_gates.sh, test/cases/138_governance_gates.sh.

Vyspělost. Na masteru a vynucováno v hooku pre-push.

Jeden registr za každým rozhraním

Jak to funguje. Každá operace spustitelného souboru v Rustu je deklarována jednou, s typovaným vstupem a výstupem. Z této deklarace se odvozuje následující:

• routy HTTP pod /api/v1;
• dokument OpenAPI 3.1;
• Swagger UI;
• nástroje a zdroje MCP;
• runner Cockpitu;
• generovaná reference.

Příkazová řádka se píše ručně a křížově kontroluje proti registru v obou směrech. Schopnost, která zapisuje do repozitáře, musí tento efekt deklarovat. Instrukce MCP a OpenAPI jmenují každou takovou schopnost a test drží obojí proti registru. Indexované objekty repozitáře, jako pravidla, ADR a tvrzení, se stávají zdroji MCP na majordomus://<kind>/<identity> bez registrace.

Vyzkoušejte.

$ majordomus-cli capabilities list
$ majordomus-cli capabilities describe rules.show
$ majordomus-cli capabilities validate
$ curl -s http://127.0.0.1:8742/openapi.json | jq '.paths | keys'

Dokázáno čím. test/cases/76_capabilities_projections.sh, test/cases/46_cross_surface.sh, test/cases/92_openapi_reference.sh, test/cases/72_rust_mcp.sh, apps/majordomus-cli/tests/projections.rs, apps/majordomus-cli/tests/shared_units.rs.

Zralost. Na master.

Objevování, generování a drift

Jak to funguje.

• Objevování. share/kinds.yaml definuje druhy dokumentů a .ai/repo/knowledge/sources.yaml mapuje git pathspecy na ně, takže nový soubor pravidel se indexuje bez seznamu k úpravě.
• Generování. majordomus generate zapisuje projekce programu a scripts/derive spouští celý graf odvozování.
• Drift. derive-check, generate --check a generate-site-data --check se regenerují a porovnají bajt po bajtu. Pre-commit hook odmítne zastaralé odvozené soubory.

Vyzkoušejte. just derive, just derive-check, majordomus-cli generate --check.

Dokázáno čím. test/cases/64_knowledge_discovery.sh, test/cases/51_derived_artifacts_committed.sh, test/cases/56_derived_current_gate.sh, test/cases/104_strict_derivation.sh, apps/majordomus-cli/tests/generate_check.rs, apps/majordomus-cli/tests/index_behavior.rs.

Zralost. V masteru a vynucováno při commitu i v CI.

Prostředí repozitáře a Cockpit

Jak to funguje.

• Prostředí repozitáře. Typovaný snapshot checkoutu: projekt, správa verzí, toolchainy, vrstva, workflow, provideři, lokální služby a diagnostiky, s původem každé hodnoty. Banner shellu (přes direnv), majordomus-cli env, GET /api/v1/environment a zdroj MCP jsou jeho vykreslovače.
• Cockpit. Lokální webové UI renderované serverem na /cockpit. Nabízí runner pro každou schopnost, prohlížeč pro každý indexovaný druh a pohledy na release, design, mesh, worktrees, kontinuitu, provádění a grafy. Každá stránka se ptá téhož executoru jako API.

Vyzkoušejte. majordomus-cli env, majordomus-cli env --json, pak otevřete URL Cockpitu, které majordomus-cli serve status vypíše.

Dokázáno čím. test/cases/100_environment.sh, apps/majordomus-cli/tests/environment.rs, apps/majordomus-cli/tests/cockpit.rs.

Zralost. Na masteru. Pohledy na plán a nástěnku v Cockpitu jsou jen na větvi.

Verze a publikace

Jak to funguje.

• Verze. Verze se píše na jednom místě, v manifestu crate, a zapisuje ji jeden příkaz, majordomus-cli release bump; scripts/derive ji promítá pro shellový nástroj. release analyze měří minimální zvýšení porovnáním veřejného povrchu schopností s posledním releasem.
• Releasy. Tag sestaví, publikuje, zapíše záznam o release a smoke-testuje veřejný instalátor.
• Nasazení webu. Merge do masteru publikuje web z commitnutých projekcí. Nasazení je ověřeno, když majordomus.dev/build.json servíruje merge commit, a kontrola pages-live hlídá, že žádná publikace není po termínu.

Zkuste to. majordomus-cli release analyze, curl -s https://majordomus.dev/build.json.

Dokázáno. test/cases/112_version_matches_surface.sh, test/cases/87_release_pipeline.sh, test/cases/180_publication_is_observed.sh, test/cases/275_publication_is_current.sh.

Zralost. Na master.

Samotná příkazová řádka

Jak to funguje.

• Dva programy. Shellový nástroj majordomus vlastní životní cyklus úlohy. Spustitelný soubor v Rustu majordomus-cli vlastní registr a jeho povrchy; shellový nástroj ho pojmenuje, když tam příkaz patří.
• Nápověda. Každý příkaz odpovídá na --help svým použitím a ničím jiným, před init i po něm.
• Pokrytí. Každý veřejný příkaz má behaviorální i negativní pokrytí.
• Doplňování. Odpovídá z jednoho grafu příkazů složeného z obou programů a receptů just.

Vyzkoušejte. majordomus --help, majordomus-cli --help, majordomus-cli completion zsh.

Dokázáno čím. test/cases/15_command_surface.sh, test/cases/31_command_coverage.sh, test/cases/101_command_graph.sh, test/cases/102_completion_shell.sh, test/cases/98_cli_reference.sh, apps/majordomus-cli/tests/cli_examples.rs.

Zralost. Na master.

Od začátku do konce

test/cases/19_end_to_end.sh provede jeden repozitář přes init, úlohu s rozsahem, kontroly, předávku a dokončení, tak jako nový uživatel.

Ověřte si to sami

Každý shellový případ běží proti čerstvému dočasnému git repozitáři a skutečnému bin/majordomus.

$ bash test/run.sh 04_start_check 25_continuity_lifecycle 42_dag_waves 125_rule_proof
$ MJ_TEST_JOBS=4 bash test/run.sh                      # the whole suite
$ cd apps/majordomus-cli && cargo test --test projections --test rules --test peer_claims

Chcete-li uchovat běh jako důkaz vázaný na commit, který dokazuje, změřte checkout tak, jak jej běh zanechal, a poté zaznamenejte report s tímto měřením:

$ MJ_TEST_REPORT=report.tsv bash test/run.sh 04_start_check 06_finish
$ majordomus-cli evidence stamp --report report.tsv --out report.provenance.json
$ majordomus-cli evidence record --suite report.tsv --provenance report.provenance.json
$ majordomus-cli evidence show

Co zatím nedělá

• CI spouští každou kontrolu, ale svá spuštění nezapisuje do knihy důkazů, takže většina pravidel a tvrzení se čte jako not run, dokud někdo spuštění nezaznamená.
• Mesh nemá providera Tailscale ani mDNS.
• Překryv se hlásí, nikdy nevynucuje. Jediným odmítnutím je vlastní rozsah úlohy.
• Automatický záznam relací existuje jen pro Claude Code.
• Pohledy na plán a nástěnku v Cockpitu a bohatší vstupní preflight jsou otevřené pull requesty.
• Intenty se vynucují v okamžiku zahájení práce jen tam, kde politika vyžaduje navázání; politika tohoto repozitáře je advisory. Milníky GitHubu se uzavírají, aniž by se četly, a kritérium command nebo deployment není nikdy splněno.
• Příkazová řádka a seznam oblastí Cockpitu se píší ručně a kontrolují se proti registru, negenerují se z něj. HOW_IT_WORKS.md vypíše každé takové místo.