EN
Všechny projekty
Autor·vlastní nástroj · publikováno

Reservine-DX

Publikovaný Claude Code orchestrátor plugin, jehož delivery smyčku model nemůže obejít.

reservine-dx.app
Reservine-DX
GATE_RESULT: PASS
  • 11-fázová delivery smyčka
  • shell gate · FAIL = nenulový kód
  • skills sdílené napříč repozitáři

Publikovaný plugin do Claude Code marketplace (@reservine/dx) se sdílenými cross-repo skills — plánování feature, cross-plan, implement-plan, cherry-pick, commit. Jeho 11-fázová delivery smyčka je vynucená reálným shell gate, který vypíše GATE_RESULT: PASS/FAIL a při selhání skončí s nenulovým kódem, takže agent fázi doslova nemůže přeskočit. Ověřitelná agentní autonomie, ne prózou.

Problém

Typická slabina autonomního kódovacího agenta je, že přeskakuje kroky. Řekněte mu "dodrž těch 11 fází" a on si přečte celý plán, usoudí, že to ví líp, a skočí rovnou k psaní kódu — žádný worktree, žádná specifikace, žádný bezpečnostní průchod. Instrukce v textu typu "nejdřív MUSÍŠ udělat X" jsou jen doporučení; model je bere jako návrh a obejde je. Čím schopnější model, tím sebevědoměji zkracuje.

Napříč dvěma odlišnými stacky — Angular/Nx frontendem a Laravel backendem — jsem agentovi v každém sezení znovu vysvětloval tutéž disciplínu dodávky: kontext, specifikace, větev, build, ověření, review, nasazení. Ta znalost žila v mé hlavě a v roztroušeném textu, takže každé repo se rozjíždělo jinam a každé sezení znovu řešilo proces od nuly.

Chtěl jsem, aby proces byl vlastností nástroje, ne něčím, co musím neustále hlídat.

Vynucená smyčka

@reservine/dx je publikovaný plugin do Claude Code marketplace: sdílená, cross-repo sada skills — plánování feature, cross-plan, implement-plan, cherry-pick, commit — instalovaná přes `bunx @reservine/dx install`.

Jádrem je implement-plan, router fází. Místo aby agentovi předal celý playbook, načte vždy jen jeden soubor s fází — Context, pak Spec, Worktree, Implementation, Build, Verification, PR, Review, Security, Retro, Handoff (plus podmíněnou 6.5). Agent nemůže nahlédnout dopředu, protože další fáze ještě prostě není v jeho kontextu.

Mezi fázemi sedí to, co z toho dělá realitu: `scripts/validate-phase-gate.sh`, reálný shellový check, který vypíše binární `GATE_RESULT: PASS/FAIL` a při selhání skončí nenulovým exit kódem. Router ho musí spustit a před každým postupem ověřit návratový kód. Tohle není prompt prosící model, ať se chová slušně — je to proces, který vrátí 1, a nenulový exit smyčku zastaví. S textem se model dohadovat umí; s exit kódem ne.

Plugin sám pozná, jestli běží ve frontendovém, nebo backendovém repu, a podle toho nastaví automatiku worktree, takže stejná smyčka jede přes oba stacky, aniž bych ji musel znovu vysvětlovat.

Proč na tom záleží

Rozdíl, na kterém mi záleží: tohle je ověřitelná pojistka, ne přesvědčovací. Většina "pojistek pro agenty" je jen další text, který modelu říká, ať je opatrný — a to drží, dokud se model nerozhodne, že je hotovo. Shellová brána, která skončí nenulovým exitem, je stejný druh kontroly, jaký bych dal do CI: deterministická, prozkoumatelná a lhostejná k tomu, jak přesvědčivě agent vypráví o vlastním dodržení pravidel.

Publikoval jsem to jako vlastní nástroj, protože ten princip se dá zobecnit. Načítání kontextu po jedné fázi plus reálná brána na exit kódu — tak donutíte agenta odvést důkladnou práci od začátku do konce místo nadšených 60 %. A tak může tým autonomnímu běhu věřit, aniž by znovu četl každý řádek, který vyprodukoval.

Zároveň to ukládá proces tam, kam patří: do verzovaných skriptů, které tým může číst, měnit a rozšiřovat — ne do návyků jednoho inženýra nebo dlouhého systémového promptu, který nikdo nereviduje.