KAM SE DÁ DOJÍT — TICKET FORGE

Z Jira ticketu hotový pull request

Takhle vypadá vývoj, který obě osy auditu splňuje. Ticket Forge je náš vlastní autonomní AI agent, do kterého jsme přetavili Agentic standard. Umí dvě věci: ohodnotit zadání, nebo z dobře ohraničeného ticketu rovnou vyrobit merge request k lidskému review. Reálně běžící systém — a důkaz, že metodika auditu nestojí na papíře.

plně automaticky

běží bez zásahu člověka — od zadání až po hotový MR

2 režimy

ohodnocení zadání · autonomní implementace

best effort

implementace bez garance — výstup vždy k lidskému review

V kostce

Ticket Forge zkracuje čas, který vývojáři tráví rutinní, dobře ohraničenou prací (bugfixy, drobné featury, refaktory, aktualizace závislostí, testy). Vývojář nebo PM označí ticket, agent připraví změnu, ověří ji a otevře MR — člověk už jen reviduje a merguje. Výsledkem je rychlejší průchod ticketu od zadání k revizi při zachované kontrole: povinné kontroly projektu se nesnižují a finální rozhodnutí (merge) zůstává vždy na člověku.

Proč je to na portálu auditu: tenhle stupeň automatizace je možný jen tehdy, když lidé i projekt splňují to, co audit měří. Je to konec cesty — audit vám ukáže, kde na ní stojíte a kudy vede dál.

🔀 Dvě funkce: ohodnotit zadání, nebo ho naprogramovat

Ticket Forge dělá přesně to, co Agentic standard staví na první místo — kvalitní vstup a spec-driven development. Proto umí dvě věci:

🔍

1. Ohodnotí zadání

Ještě před vývojem projede ticket i repo a ohodnotí kompletnost zadání skóre 0–10 s konkrétními otázkami, co doplnit.

🔨

2. Naprogramuje ho

Z dobře ohraničeného ticketu sám vyrobí MR připravený k lidskému review.

🧮 Skóre zadání rozhoduje, kdo ho vezme

Hodnocení zadání není samoúčelné — přímo rozhoduje o dalším kroku. Podle skóre se ticket automaticky nasměruje tam, kde dává největší smysl:

Skóre zadání	Rozhodnutí
8–10	Zadání je jednoznačné → rovnou ho implementuje Ticket Forge (vznikne MR).
5–7	Zadání je dobré, ale vyžaduje lidský úsudek → implementuje vývojář.
< 5	Zadání je neúplné → vrací se analytikovi k doplnění, nejde na vývoj.

V kostce

Efekt je dvojí: nekompletní zadání se zachytí dřív, než zbytečně spotřebuje čas vývojáře, a jednoznačné tickety odbaví agent sám. Vývojářský čas se soustředí tam, kde je potřeba lidský úsudek — do střední kategorie. Kvalita zadání se tak stává měřitelnou branou, ne otázkou náhody.

Analyzátor vrátí hodnocení jako komentář u ticketu — přehledné shrnutí toho, co je jasné, co chybí, a seznam otázek k doplnění. Ilustračně (fiktivní zadání):

🧪 Ukázka výstupu analyzátoru (ilustrační, fiktivní zadání)

Spec review — hodnocení zadání: 6/10

Cíl je srozumitelný a v repozitáři plně proveditelný: přidat do seznamu objednávek filtr podle stavu. Dotčené místo (endpoint i komponenta seznamu) je jednoznačně identifikovatelné a existuje zavedený vzor pro obdobné filtry. Zadání je z pohledu „co" jasné, ale „jak" obsahuje několik nedořešených detailů, které by při špatném odhadu vedly k přepracování.

Otázky k zodpovězení před implementací:

• 🔴 Má filtr přijímat více stavů najednou (multiselect), nebo vždy jen jeden?
• 🔴 Jak se má zachovat u neznámého / smazaného stavu — chyba, nebo tichý fallback?
• 🟠 Má se zvolený filtr propisovat do URL (sdílitelný odkaz), nebo jen do stavu komponenty?
• 🟢 Řadí se výsledky po odfiltrování stejně jako dosud?

Výsledek: 6/10 → střední kategorie → implementaci vezme vývojář, ne agent.

ℹ️ Krok „ohodnocení zadání před vývojem" je přímo z Agentic standardu — Ticket Forge ho jen automatizuje. Zbytek této stránky popisuje druhou funkci: jak z hotového zadání vznikne MR.

🎯 Jaký problém řeší

Vývojářské týmy tráví značnou část kapacity drobnou, dobře ohraničenou prací — je nutná, ale nevyžaduje kreativní návrh. Přesně tuto vrstvu Ticket Forge automatizuje:

• Zkracuje čas vývojářů strávený rutinou — agent připraví MR, člověk jen reviduje a merguje.
• Zrychluje průchod ticketu — ze zadání rovnou k MR s prošlou automatickou kontrolou.
• Zachovává kvalitu a kontrolu — povinné kontroly se nesnižují a merge zůstává na člověku.
• Neinvazivní napojení — žádný zásah do repozitáře ani do CI napojeného projektu; projekt se připojí jen konfigurací na své straně.

Ticket Forge je přenosný a nezávislý na platformě — stejnou logikou obsluhuje GitLab i GitHub, bez vendor lock-inu a s plnou kontrolou nad modelem, náklady i daty.

Na co se hodí a na co ne

Hodí se na dobře ohraničené tickety — bugfixy, drobné featury, refaktory, aktualizace závislostí, testy. Velké nebo rizikové úkoly (nové moduly od nuly, rozsáhlé architektonické změny, riskantní datové migrace) zůstávají na člověku.

🧱 Jak to funguje uvnitř

Vnitřně je Ticket Forge plně automatická linka o čtyřech krocích. Nemá vlastní databázi — řídí se stavem ticketu a stavem v Gitu, takže je jednoduchý a odolný.

Následující diagram ukazuje cestu od ticketu až po připravený MR pro člověka:

🛰️

Dispečer

Pravidelný automatický job kontroluje označené tickety a spouští práci. Žádné ruční spouštění.

📦

Izolované prostředí

Pro každý ticket jednorázové, bezpečné prostředí, které po doběhnutí zaniká — nic nepřežívá mezi tickety.

🧠

AI agent

Nejprve naplánuje, poté napíše změnu a sám ji zkontroluje — teprve potom ji odevzdá.

🔗

Uzavření

Otevře MR a posune ticket k lidskému review. GitLab i GitHub stejnou logikou.

🔒 Nikdy nemerguje — bezpečnostní princip

Nejdůležitější vlastnost Ticket Forge je zároveň bezpečnostní princip: agent nikdy nemerguje sám. Výstupem každého běhu je otevřený MR, který čeká na lidské review. Review i merge provádí VŽDY člověk — tzv. human gate.

Human gate je pevná hranice, ne jen procesní pravidlo

Ticket Forge nikdy nemerguje — a nemůže. Zákaz je vynucený rovnou ve dvou nezávislých vrstvách: agent na to nemá v systému cestu ani oprávnění. Ani chyba agenta, ani podvržený text ticketu tuto hranici nepřekročí.

🧊

Izolovaný běh

Jeden běh = jeden ticket v jednorázovém prostředí, které po doběhnutí zaniká.

🔑

Minimální oprávnění

Agent smí založit větev a otevřít MR, ale nikdy ne mergovat; citlivé přístupy vůbec nevidí.

🧯

Odolné vůči manipulaci

I když je text ticketu nedůvěryhodný, hranici „nemergovat" nelze obejít — je daná systémem, ne chováním agenta.

🚦

Human gate

Žádná změna se nedostane do cílové větve bez lidského review.

🔄 Tok od ticketu k Code Review

Celá cesta běží automaticky: dispečer ticket vyzvedne, agent připraví změnu a otevře MR, a podle výsledku automatické kontroly (CI) se ticket buď posune k člověku, nebo ho agent ještě sám opraví.

ℹ️ Iterace jen na automatické kontrole. Ticket Forge se sám opravuje pouze při selhání CIpřed předáním člověku. Jakmile je ticket v Code Review, veškeré další opravy dělá už člověk.

✍️ Jak vypadá dobré zadání

Kvalita výstupu agenta je přímo daná kvalitou ticketu — agent nemá žádný kontext mimo ticket a repo (nezná ústní domluvy ani chatová vlákna). Ať už ticket zakládá analytik, PM nebo vývojář, dobré zadání obsahuje:

• Cíl — jedna až dvě věty, co a proč se má udělat.
• Akceptační kritéria — konkrétní, ověřitelné podmínky „hotovo" (ideálně testovatelné).
• Dotčená oblast — modul / balíček / repo, kde se má změna odehrát (šetří čas i náklady).
• Přílohy a důkazy — screenshot chyby, log, ukázka dat.

Rychlý test vhodnosti: Zvládl by ticket nový člen týmu jen podle popisu, bez doptávání? Je jednoznačné, kdy je hotovo? Je to jedna ohraničená změna? Pokud ano, ticket je připravený pro agenta.

🧩 Vazba na Agentic standard

Ticket Forge není samostatný experiment — je to produkční aplikace našeho Agentic standardu v praxi. Prvky standardu, které v něm poznáte:

📐

Spec-driven development

Agent nejprve naplánuje, plán se zkontroluje a teprve schválený plán se implementuje.

🧭

Kontext a výběr modelu

Agent dostane zadání i kontext projektu; na náročné kroky silnější model, na rutinu rychlejší.

🔌

Napojení na systémy

Umí si dohledat souvislosti v napojených nástrojích — linkované tickety i zadání.

🛡️

Validace a guardraily

Povinné kontroly se nesnižují, pojistky na počet pokusů a nepřekročitelný human gate.

🔁

Orchestrace

Běží proaktivně sám bez lidského zásahu — konkrétní příklad orchestrace agentů.

🧑‍💻

Vývojář jako orchestrátor

Člověk zadává, kontroluje a rozhoduje o mergi; rutinu odvádí agent.

Detailní rozpad těchto prvků najdete v měřítku auditu — Ticket Forge ho převádí do praxe: vývojář jako orchestrátor agentů, ne jako vykonavatel rutiny.

Jak daleko od tohoto stavu je váš vývoj?

Přesně to audit změří — na obou osách, z faktů. A kdo ho provede, najdete na následující stránce.

⭐ Cena, rozsah a harmonogram👥 Kdo audit provádí