Kvalita, úplnost a udržovanost technické dokumentace — jak dobře je systém popsán pro nového vývojáře i pro provoz. Spolu s Architekturou je to nejsilnější indikátor předatelnosti.

📊 Skóre

Stav	Počet
🟢 OK	8
🟠 Částečně	2

Celkově: výjimečně silná oblast. Dokumentace má závazný standard struktury, pokrývá jednotně všechny služby i aplikace, obsahuje generovanou API referenci a je z drtivé většiny aktuální. Mezery jsou jen v zastaralé sekci monitoringu a prázdném decision-logu.

🔍 Co jsme hodnotili

#	Kritérium	Stav
1	Závazný standard struktury dokumentace	🟢
2	High-level architektura + technický přehled	🟢
3	Jednotná dokumentace všech backendových služeb	🟢
4	Jednotná dokumentace všech frontendových aplikací	🟢
5	Onboarding a návody pro lokální vývoj	🟢
6	API reference (generovaná, per-služba)	🟢
7	Dokumentace infrastruktury	🟢
8	Aktuálnost a udržovanost (datováno, verzováno)	🟢
9	Dokumentace monitoringu a alertingu	🟠
10	Audit dokumentace (dluh, licence, decision log)	🟠

📌 Klíčové nálezy

🟢 Závazný standard struktury

Existuje referenční dokument „Standardní struktura dokumentace", který definuje povinné položky (označené 🔶) a závaznou strukturu do 3. úrovně zanoření. Dokumentace tak není nahodilá — má jasně danou kostru, kterou lze kontrolovat. To je nadstandard, který většina projektů nemá.

🟢 Kompletní a jednotný popis všech služeb

Dokumentace je rozsáhlá (~970 stránek) a napříč službami konzistentní:

• Všech 9 backendových služeb má všech 7 povinných stránek: architektura, návod na lokální spuštění, migrace a seedování, automatizované testy, autentizace & autorizace, důležité knihovny, CRONy.
• Všechny 4 frontendové aplikace mají všech 8 povinných stránek: návod, common i komplexní komponenty, generování API klienta, lokalizace, testy, knihovny, state management.

Nový vývojář tak u kterékoli služby najde stejnou strukturu informací — to zásadně zrychluje onboarding a snižuje závislost na konkrétních lidech.

🟢 Architektura, technický přehled a návody

Existuje high-level diagram architektury a technický přehled (technologický stack, popis služeb interních i třetích stran, technologická vize, A&A model, asynchronní komunikace). Sekce návodů obsahuje 12 praktických postupů včetně „jak rozchodit lokální prostředí".

🟢 Generovaná API reference

Kompletní API reference (~700 stránek) je organizovaná per-služba a generovaná z OpenAPI specifikací — je tedy vždy v souladu s kódem (viz i drift gate v Architektuře).

🟢 Infrastruktura a aktuálnost

Dokumentace infrastruktury pokrývá obecný přehled, instance a prostředí, CI/CD a secrety, IaC (Terraform, Kubernetes), DNS, pricing i deployment služeb. Dokumentace je vedená jako VitePress markdown přímo v repozitáři (stejný systém jako tato nabídka) s frontmatterem (status, updated_at) — je tedy verzovaná a strojově čitelná. Drtivá většina stránek je aktuální (přes 850 aktualizováno v 06–07/2026).

🟠 Zastaralá sekce monitoringu

Sekce Monitoring a Alerting (logy, metriky, health checky, alerting) existuje, ale všechny její stránky jsou datované 2024-12 — tedy ~1,5 roku staré. Buď se monitoring nezměnil (méně pravděpodobné), nebo dokumentace zaostává za realitou.

🟠 Prázdný decision log

Sekce Audit obsahuje živý dokument technického dluhu (35 položek, aktuální), audit licencí i přehled aktualizací knihoven. Decision log (ADR) je ale připravený, ale prázdný (TODO) — chybí tak evidence architektonických rozhodnutí a jejich důvodů.

✅ Doporučení

Priorita	Doporučení
Střední	Zaktualizovat sekci Monitoring a Alerting podle současného stavu (poslední revize 2024-12).
Střední	Začít vést decision log (ADR) — u předávaného systému je znalost „proč to tak je" klíčová.
Nízká	Doplnit prázdnou sekci diagramů infrastruktury.

💡 Pro audit u klienta: takto vedená dokumentace je vzácná. U custom systémů držených malým týmem bývá dokumentace naopak nejslabším místem — a přitom je to nejlevnější způsob, jak snížit vendor lock. Viz Předatelnost a vendor lock.