Okamžik
Jednořádkové přejmenování. Relace běží na nejschopnějším dostupném modelu, s úsilím uvažování na stropu a kontextem naplněným polovinou repozitáře, a napíše tři odstavce vysvětlující přejmenování.
Proč k tomu dochází
Tu konfiguraci nikdo nezvolil; zbyla z poslední těžké úlohy. Schopnost, hloubka uvažování, velikost kontextu a výřečnost výstupu jsou čtyři samostatná rozhodnutí, a když je nic nepojmenovává, splynou v jeden zvyk — obvykle „všechno zapnuto“. Směrovací dokumenty, z nichž byl tento nástroj destilován, slily úsilí do názvu modelu a směrovaly podle pracovní pozice pracovníka, s čísly výkonu, která nikdo neměřil.
Proč to lepší model nevyřeší
To je jediný okamžik, kdy lepší model problém zhoršuje: čím silnější výchozí volba, tím dražší zvyk. Selhání spočívá v tom, že čtyři nezávislé ovladače nebyly nikdy pojmenovány, takže žádný z nich nelze stáhnout, aniž by se stáhly všechny.
Co to stojí
Peníze, způsobem, který se projeví na faktuře a nikde jinde — žádný artefakt nezaznamenává, ke které úloze výdaj patřil. Latence, a to právě u změn, které by měly být okamžité. A hloubka zaměňovaná za upovídanost: worker na maximálním úsilí píše víc, což vypadá jako píle a je to většinou jen výstup.
Co Majordomus dělá
Profil je malý soubor, který nastavuje každou osu nezávisle: třídu schopností, úsilí uvažování, upovídanost výstupu, prezentaci, jaký kontext načíst, jaké ověření je vyžadováno a jak často dělat checkpoint. S nástrojem se dodávají čtyři — routine, implementation, debugging, deep-work — a úloha jeden jmenuje při start. Generovaný instrukční soubor říká pracovníkovi, který profil platí, takže přejmenování běží pod routine. Eskalace, pokud ji profil dovoluje, je zaznamenaná událost po stanoveném počtu zablokovaných pokusů, ne nálada.
Před a po
before (whatever the last task left set) rename SessionStore -> SessionRepo
after majordomus start "rename SessionStore" --scope lib/session --profile routine
majordomus check --explain
profile routine capability fast effort low verbosity terse
context task, current_stateJak to ověřit
majordomus check --explain vypíše efektivní osy aktivní úlohy. Spusťte stejnou úlohu pod dvěma profily a vypsané osy se liší; instrukční soubor, který pracovník čte, uvádí, který profil platí.
Co nedělá
To je ta poctivá část. Profily se promítají do instrukcí workera a validují se jako konfigurace. Zda je worker dodržuje, zvenčí workera pozorovat nelze a Majordomus nikdy nevybírá ani nevolá model. Každý řádek matice tvrzení týkající se profilů je právě z toho důvodu označen jako poradní. Měření toho, co relace skutečně spotřebovala, je v plánu rozvoje a dnes se netvrdí.