# Projekty (https://docs.vitrinka.ai/cs/pm/projects)



## Jeden produkt, jeden projekt [#idea]

Projekt je místo, kam dopadá práce na jednom produktu: jeho úkoly, nástěnky, nahraná sezení, hlášení a vydání. `vitrinka setup` při prvním spuštění zařadí repozitář pod projekt; `vitrinka project link [project]` zařadí další checkout pod už existující projekt — další repozitář projektu s více repozitáři — a `vitrinka project unlink` checkout zase odpojí a odebere jeho řádek z repozitářů projektu.

**Nastavení → Projekty** vypisuje všechny projekty workspace. Po otevření projektu uvidíte jeho název, jeden řádek o stavu a pět záložek: Overview · Routing · Repositories · Fields · Review. Overview, Routing a Repositories jsou koncepty s vlastním tlačítkem Save; Fields a Review ukládají každý řádek hned při změně.

## Overview [#overview]

Název, který ukazuje postranní panel — slug je adresa a nikdy se nemění — a stav: **active**, tedy produkt, nebo **system**, tedy infrastruktura skrytá z postranního panelu. Projekt sloučený do jiného je tu jen ke čtení; sloučený i přesunutý jinam odkazuje na svůj nový domov.

Záložku otevírá **ikona**: nosí ji dlaždice projektu na launchpadu, jeho řádek v liště Work, jeho drobečková navigace a záložka prohlížeče na jeho vlastních stránkách. **Fetch from site** ji načte z produkční domény projektu nebo z adresy, kterou vložíte — jen z veřejných webů a nikdy na instalaci odpojené od internetu; **Upload…** přijme soubor PNG, JPEG, WebP, GIF, ICO nebo SVG; `vitrinka setup` pošle vlastní ikonu repozitáře, aniž by sáhl na jakýkoli web. Workspace bez vlastního loga převezme ikonu prvního projektu a volba admina v Nastavení → Workspace vždy vyhrává. Skripty volají `PUT /api/v1/projects/{project}/icon` s obrázkem jako tělem požadavku.

## Routing [#routing]

Která nahraná sezení patří do tohoto projektu. **Domains** porovnají hostitele záložky prohlížeče se vzorem a označí sezení prostředím pravidla; **App ids** porovnají bundle id aplikace v Expu a app id, které už vlastní jiný projekt, server odmítne. Doména s produkčním prostředím (`production`, `prod`, `prd` nebo `live`) ukáže navíc přepínač **in-app recorder** pro [webový rekordér](/cs/qa/recorder/web#link). Skripty zapisují stejná pravidla přes `PUT /api/v1/projects/{project}/settings` — viz [rozšíření prohlížeče](/cs/qa/extension#domains).

## Repositories [#repositories]

Repozitáře na GitHubu, ve kterých žije kód projektu. První je výchozí pro commit pilulky, prohlížeč kódu a sběr pro vydání; nový [release track](/cs/pm/release#rolling) převezme všechny. Pověřením je GitHub App workspace a tenhle seznam je vazba: řádky se doplňují z toho, na co navázané účty dosáhnou, a repozitář na github.com, který žádný z nich nepřečte, dostane varování, nikdy blokaci, takže vlastní hostovaný git zůstává v pořádku. Klíč úkolu ve sloučeném pull requestu z repozitáře mimo tento seznam úkol propojí, ale nikdy nedokončí ([pravidla](/cs/pm/rules#builtins)).

## Fields [#fields]

Typovaná vlastní pole pro úkoly projektu — text, dlouhý text, výběr, vícenásobný výběr, checklist, číslo, datum, URL nebo vazba na jiný úkol — každé pro jeden typ úkolu nebo pro všechny, seskupená podle typů, na které se vztahují. Pod nimi **Type faces** nastaví glyf, který každý typ úkolu v projektu nosí. Pole definuje správce, tady nebo z terminálu; hodnoty žijí na úkolech a nastavují se ve vlastnostech úkolu nebo přes `vitrinka task field set`. Pole typu výběr se stanou aspekty filtru. Klíč a druh pole se nikdy nemění a odebrání pole smaže všechny hodnoty, které pod ním byly uložené.

```bash
vitrinka project fields add customer "Zákazník" --kind select --options acme,globex --applies-to bug
vitrinka task field set 418 customer acme
```

## Review [#review]

Vrstva review rubriky pro projekt: každé pravidlo, které projekt dědí z vestavěných a z workspace, s přepínačem zapnutí, editorem a návratem k vrstvě pod ním. Samotnou rubriku popisuje [sada nástrojů pro revize](/cs/qa/review-toolkit#brief).

## Sloučení dvou projektů [#merge]

**merge into…** v záhlaví nastavení projektu ho sloučí do jiného projektu téhož workspace. Přesune se všechno — úkoly s historií, nástěnky, sety, sezení, hlášení, vydání i paměť projektu — a starý název se stane aliasem nového domova, takže každý starý odkaz dál funguje. Dialog nejdřív ukáže náhled (zkoušku nanečisto, jejíž report je transakce samotného sloučení, vrácená zpět), pak sloučí po potvrzení. Vlastní pole s kolidujícím druhem dorazí přejmenované na `<key>-from-<old name>` a hodnoty si ponechá; průběžné vydání zdroje se přidá k průběžnému vydání cíle.

Sloučení, náhled včetně, je rozhodnutí vlastníka workspace, které dělá jako člověk; tokeny agentů server odmítne a pošle je na CLI. Chcete-li přesunout jen některé úkoly, změňte jim projekt přes dveře úkolů — podstrom se přesune celý.

```bash
vitrinka project merge old-app --into app           # report zkoušky nanečisto
vitrinka project merge old-app --into app --apply
vitrinka project merge-plan --into app              # zbloudilé projekty, které by sloučení pohltilo
```

## Přesun projektu do jiného workspace [#transfer]

`vitrinka project transfer [project] --to <workspace>` zkopíruje všechno, co projekt vlastní, do jiného workspace, který vlastníte — nástěnky s kartami a anotacemi, sety, sezení, hlášení, vydání a celý engine úkolů, včetně všech blobů, na které odkazují. Potřebuje vlastníka obou workspace, nikdy token agenta. Nejdřív zkouška nanečisto; opakovaný běh přeskočí, co už dorazilo. Slug nástěnky nebo klíč setu, který cíl už má, server odmítne, pokud `--merge` projekt nesloučí se stejnojmenným projektem na místě, a zdroj zůstane nedotčený, dokud ho `--archive-source` po potvrzení kopie nevyřadí. Agenti používají `transfer_project`.

## Značky nasazení [#deploys]

`vitrinka project deploy-mark <env> <sha>` zaznamená, že commit dorazil do prostředí — fakt, na který čeká todo s podmínkou `deployed <env>` ([todo, která dozrají sama](/cs/use/day#todos)). Spouštějte ho z nasazovací pipeline s pověřením admina nebo pipeline; pověření člena server odmítne. Agenti používají `mark_deploy`.

Značka `prod` nebo `production` zároveň v [Historii](/cs/pm/history) označí práci jako vydanou. S připojenou GitHub App vydá PR nebo commit úkolu jen tehdy, když ho označený commit obsahuje, takže hotfix nasazený ze staršího tagu si nikdy nepřivlastní práci sloučenou do hlavní větve až po jeho odbočení, a jeho vlastní commity se vydají s ním. Odpověď značky hlásí `lineage`: `ancestry` s repozitářem a počtem čekajících odkazů, které obsahuje nebo vylučuje, nebo `time` s důvodem (bez GitHubu, commit v žádném navázaném repozitáři, GitHub příliš pomalý); pak se s nasazením vydá práce sloučená před ním. Také zamergovaný PR zaznamenaný dřív, než vitrinka ukládala merge commity, se posuzuje podle předků: značka přečte jeho merge commit z jednoho výpisu PR sloučených od chvíle, kdy na větev dorazil nasazený commit (u hotfixu místo odbočení), a `lineage.filled` je počítá. Když výpis selže, nestihne se nebo skončí na limitu stránek, odpověď zůstane `ancestry`, ale je neúplná: `lineage.unfilled` počítá PR, které nedokázal zařadit. Ty se vydají jako u `time`, s nasazením, pokud byly sloučené před ním, a `lineage.reason` říká proč.