Vývojová smyčka — jak snadno vývojář rozjede projekt lokálně, jak se hlídá kvalita během psaní kódu, jaké je pokrytí testy a jak se řídí technický dluh. Tato oblast je klíčová pro předatelnost a onboarding nových lidí.

📊 Skóre

Stav	Počet
🟢 OK	6
🟠 Částečně	1

Celkově: vývojové prostředí je nadstandardně připravené — jeden příkaz rozjede celý stack, vzorové konfigurace jsou u všech aplikací, kvalita se vynucuje automaticky. Hlavní mezera je nerovnoměrné pokrytí testy a dílčí nekonzistence v dokumentaci.

🔍 Co jsme hodnotili

#	Položka	Stav
8	Dokumentace spuštění a konfigurace lokálního prostředí	🟢
9	Vzorové konfigurační soubory pro lokální vývoj	🟢
10	Hot reload při lokálním vývoji	🟢
11	Nástroje pro lint a statickou analýzu	🟢
12	Automatizované testy v rozsahu standardu	🟠
13	Vynucení definovaných verzí frameworků a runtime	🟢
14	Evidence a prioritizace technického dluhu	🟢

📌 Klíčové nálezy

🟢 Lokální prostředí „na jeden příkaz"

Existuje rozsáhlá dokumentace spuštění i konfigurace — obecné návody (jak-rozchodit-lokalni-prostredi.md, jak-si-vytvorit-pristupy-na-lokalni-vyvoj.md) i návod na lokální spuštění u každé z 13 aplikací. Vzorové konfigurace jsou u všech aplikací (.env.example v rootu i v každé app) a postinstall skript je automaticky zkopíruje na .env. Backendy běží ve watch režimu (nest start --watch), frontendy přes Vite — hot reload funguje.

🟢 Vynucené verze runtime

Prostředí je pevně ukotvené: .nvmrc (22.22.3), .npmrc s engine-strict=true, packageManager: pnpm@11.x, engines.node u každé aplikace a jediný pnpm-lock.yaml. CI běží na stejné verzi Node (node:22.22.3) a instaluje s --frozen-lockfile. Riziko „u mě to jede jinak" je tím minimalizované.

🟢 Kvalita hlídaná automaticky

Sjednocený ESLint (sdílená konfigurace), Prettier a type-check se vynucují jak lokálně přes git hooky (.husky/pre-commit → lint-staged, .husky/pre-push → lint + type-check), tak v CI. (Detail viz Metriky kvality kódu.)

🟢 Řízený technický dluh

Projekt má dedikovaný, prioritizovaný a datovaný dokument technického dluhu (35 položek rozdělených podle priority HIGH/MEDIUM/LOW a kategorie — bezpečnost, CI/CD, testování…). V samotném kódu jsou jen 3 značky TODO/FIXME, což ukazuje, že se dluh drží v evidenci, ne roztroušený v kódu.

⚠️ Že je dluh i pravidelně řešen (vazba na konkrétní tickety a termíny) z repozitáře doložit nelze — to je vidět až v nástroji pro řízení úkolů.

🟠 Testy jsou, ale ne rovnoměrně

Vývojový standard požaduje unit testy pro měněnou logiku. Backendy mají solidní jednotkové testy (tf-erp-server 48 spec, tf-agw 42, tf-ios 39), frontendy se opírají hlavně o Cypress / Playwright E2E místo unit testů. Výsledné pokrytí je díky tomu u většiny služeb vysoké (77–95 %); pod cílovou hranicí je skupina služeb kolem 61–73 % (zejm. gateway tf-agw).

Konkrétní čísla pokrytí podle aplikací jsou na samostatné stránce Pokrytí testy (coverage).

⚠️ Dokumentační nekonzistence

Referenční CODEBASE.md na několika místech tvrdí, že se pro aplikace používá npm (package-lock.json), zatímco realita i AGENTS.md říkají pnpm workspace (žádný package-lock.json v repozitáři neexistuje). Drobný, ale reálný dokumentační dluh, který mate nového vývojáře — přesně to, co audit odhaluje.

✅ Doporučení

Priorita	Doporučení
Vysoká	Zvýšit pokrytí u nejslabších aplikací (zejm. tf-adm) a zvážit unit testy pro frontendy vedle E2E.
Střední	Sjednotit CODEBASE.md s realitou (pnpm workspace) — odstranit zastaralé npm instrukce.
Nízká	Doplnit do evidence tech dluhu vazbu na tickety a termíny řešení.