# Release flow (https://docs.vitrinka.ai/cs/pm/release) ## Průběžná next-release nástěnka [#rolling] Každý projekt má jednu průběžnou nástěnku **příštího vydání**, která sbírá všechno zamergované od posledního střihu — ve všech repozitářích vydání (nový release track bere všechny repozitáře navázané na projekt), v každém z jeho vlastní větve. Okno je přesné: v každém repozitáři běží od commitu, kterým v něm skončila jeho část minulého vydání, nikdy od odhadu podle data — a release stránka se na nástěnku skládá sama, jak okno roste. Dělba práce je záměrná: AI píše *prózu* — hero, položky ✨ novinek, 🐛 oprav a 🔧 vylepšení — zatímco server počítá *fakta*: pás statistik, odkazy na PR, propojené nástěnky z toho, co skutečně sesbíral. Halucinovaný počet PR není možný, protože počet nikdy neputuje přes model. Odkazy na PR nesou svůj repozitář, takže se #123 dvou repozitářů nikdy nesmíchá. ## Co stránka ukazuje [#page] Hero, pás statistik a časová osa mergů; pak ✨ novinky, 🐛 opravy a 🔧 vylepšení — jedna položka na funkci s odkazy na PR (každý do svého repozitáře), nejvýš jedním screenshotem a až třemi odkazy na nástěnky; nakonec Made this sprint — portály na až 24 nástěnek, kterých se okno dotklo. Screenshot se vybírá z až 24 kandidátů: z obrazovek zachycených v okně a ze snímků z runnerů a uploadů na nástěnkách, kterých se okno dotklo, seřazených podle vizuální kvality, souvislosti s PR v okně a čerstvosti, bez téměř shodných duplikátů. Každý screenshot se na stránce objeví jen jednou: když si stejný vyberou dvě položky, zůstane té, jejíž PR a odkazované nástěnky odpovídají nástěnce, na které vznikl — při shodě vyhraje položka výš na stránce — a druhá položka se vykreslí přes celou šířku bez obrázku. Před refreshem publikujte aktuální obrazovky, ať stránka ukazuje nejnovější UI. ## Tři slovesa [#verbs] **Refresh release** a **Cut release** jsou v sekci Release v briefu projektu, jakmile release track existuje, a jako **↻ refresh** a **✂ cut release** v hlavičce nástěnky příštího vydání. První sběr se spouští z checkoutu, protože potřebuje větev a začátek okna každého repozitáře: 1. **Start** — `vitrinka project release --refresh --repo /:@ …`, jedno `--repo` na repozitář. U práce na integrační větvi je začátkem její first-parent fork point z větve, ze které vznikla, ne `git merge-base` (viz release skill). Do prvního střihu nové spuštění s jiným začátkem okno opraví. 2. **↻ refresh** — projde GitHub pro všechno zamergované od kurzoru a předá okno release writerovi. Stránka se na nástěnce objeví, když writer odpoví, a opakované spuštění přegeneruje AI karty na místě — maže přesně svoje předchozí karty, nikdy nic, co na nástěnku dal člověk. Větve a začátky jsou uložené na vydání, tlačítko nic dalšího nepotřebuje. 3. **✂ cut** — zmrazí nástěnku jako vydání a otevře další okno; další okno každého repozitáře začne na headu, kterým v něm tohle skončilo. Střih se potvrzuje a na stejném okně nejde zopakovat. Pipeline, která stříhá po nasazení, připíchne konec okna na nasazený commit: `vitrinka project release --refresh --until ` (REST: `"until": ""` v těle refreshe, nebo po repozitářích v `repos[]`). Sebere se jen to, co ten commit obsahuje, co se zamergovalo po něm, počká na další okno, a head okna je ten commit sám; refresh vrací `headSha`, takže ho pipeline před střihem ověří. Commit, který repozitář nemá (`release_until_unknown`), který jeho větev neobsahuje nebo který leží před začátkem okna (`release_until_outside`), server odmítne dřív, než cokoli sebere. Připíchnutí se neukládá: další refresh bez něj sbírá až po head větve. Začátek okna je výlučný: okno, které začíná na commitu, drží jen mergy po něm, takže PR, který ten commit zamergoval, patří k vydání, ve kterém vyšel, a to jak u opraveného prvního začátku, tak u okna po střihu. Dvě další fakta dovolují pipeline stříhat bez dozoru. Stav vydání hlásí `docHeadSha`, head okna, pro který byla napsaná současná stránka: refresh, který head posune, ho nechá za sebou, a refresh, který okno změní jinak (opravený začátek), ho vymaže (`hasDoc` s `docHeadSha` jiným než `headSha` je zastaralá stránka), a odpověď writera na nový průchod ho nastaví na head toho průchodu. A střih může uvést head, který očekává: `vitrinka project release --cut --expect-head ` (REST: `"expectHead": ""` v těle střihu) odmítne s `release_head_mismatch` a nic nestřihne, když okno mezitím posunul refresh. Každé vydání po střihu zůstává jako zmražená nástěnka v podskupině `releases` projektu; `vitrinka project release` vypíše historii střihů s počty PR. Sběr potřebuje GitHub App připojenou k workspace s přístupem ke všem repozitářům vydání. Release track založený před navázáním repozitáře si drží svoje repozitáře, dokud je refresh všechny nevyjmenuje (`--repo`); refresh pojmenuje navázané repozitáře, které nesbíral. Bez App, začátku nebo navázaného repozitáře refresh selže a pojmenuje, co chybí. ## Dokument s poznámkami [#notes] Úplné poznámky k vydání jsou samostatný dokument — pushnutý jako jakýkoli artefakt — a vydání na něj odkazuje: `vitrinka project release --notes //` (adresa setu), `--notes ` nebo `--notes `. Release nástěnka pak vedle statistik ukáže náhledovou kartu dokumentu a sekce Release v briefu projektu na něj odkáže; odkaz na jiný dokument nahradí právě tuhle jednu kartu a `--notes-clear` ji odebere. Dokument musí žít ve stejném workspace jako vydání — odkaz do jiného workspace server odmítne. Střih odkaz na zmraženém vydání ponechá; další okno začíná bez něj. Dokument s poznámkami má vlastní rejstřík (`direction: "release"`): sekce ve stylu kapitol a KPI dlaždice, obrazovky jako galerie místo figur pod sebou, čísla před a po jako srovnávací graf a bloky označené publikem, takže jeden dokument poslouží uživatelům, vývojářům i týmu — čtenář si publikum vybere v prohlížeči a exporty do PDF, HTML, e-mailu a Wordu ho zachovají. Release skill ho tak píše; slovník elementů je v [přehledu elementů](/cs/reference/elements). ## Připravenost před vydáním a po něm [#readiness] [Přehled](/cs/pm/brief) sjednocuje vnořené úkoly, podmínky a podmíněná připomenutí jednou za každou identitu. Povinnosti **Before release** a **Ship** blokují vydání; povinnosti **After release** blokují uzavření. Výslovný odklad potřebuje vlastníka i spouštěč a začne platit, jakmile se spouštěč naplní. Volitelná práce zůstává viditelná, ale neblokuje. Počty připravenosti pokrývají celý vybraný rozsah. Stránkovaná čtení API nesou verzi rozsahu z první stránky; pokud se rozsah změní, začněte čtení znovu místo spojování různých verzí. ## Přesní kandidáti vydání [#candidates] V Přehledu vyberte [sprint](/cs/pm/sprints) a zvolte **Prepare candidate**. Kandidát uchová verzi rozsahu, úplnou revizi každého repozitáře a platformu, druh, přesnou identitu a zdrojovou revizi každého buildu. Volitelný digest může určit obsah buildu. Můžete připojit existující poznámky k vydání; kandidát pak musí odpovídat všem revizím repozitářů v jejich posledním sběru. Změněná práce, novější kandidát nebo jiné revize propojeného vydání učiní staršího kandidáta neaktuálním. Připravte nového kandidáta a ověřte jeho přesné buildy místo použití starých důkazů pro jinou práci. Ke kandidátovi zaznamenejte odkazy na původní důkazy ověření a nasazení. Označit je jako ověřené nebo použít **Record shipment** může pouze přihlášený člověk s rolí správce workspace. Vyberte ověřený důkaz nasazení pro stejného kandidáta a prostředí; povinnosti Before/Ship musí být splněné. Záznam vydání uchová kandidáta, připravenost a důkaz jako neměnné faktum v [Historii](/cs/pm/history). Opakování stejného ID požadavku ho nezaznamená dvakrát. Agenti a Eve mohou číst připravenost, vysvětlovat blokátory, připravovat kandidáty a zaznamenávat neověřené důkazy. Nemohou se sami ověřit ani potvrdit vydání. Střih poznámek zmrazí jejich okno; nezaznamenává nasazení. ## Nebo z repozitáře [#agents] Stejná slovesa jsou `vitrinka project release` (`--refresh`, `--cut`, `--notes`) a release skill (`/vitrinka:release status|refresh|cut`) — viz [skills](/cs/dev/skills/overview). Ať ✂ stiskne člověk, nebo střih spustí agent, je to tatáž pipeline a tatáž nástěnka.