Sanitizační kuchařka + jak přidat bug

import { Aside, Steps } from ‘@astrojs/starlight/components’;

Tahle wiki je **veřejná**. Než přidáš jakýkoli záznam, projdi celou tuto kuchařku. Pokud si u jakéhokoli údaje nejsi jistý, jestli je citlivý → **je citlivý** → vynech ho nebo nahraď placeholderem.

1. Co se NIKDY nepíše (citlivá data)

Kategorie	Příklad zakázaného	Nahraď za
IP adresy, hostnames, porty	203.0.113.10, db.example.com:5432	<SERVER_IP>, „self-hosted server”
Hesla, klíče, tokeny, secrets	SMTP_PASS=…, sk_live_…	<SMTP_PASS>, <API_KEY>
Connection stringy	postgres://user:pass@host/db	„REST gateway nad Postgres”
Jména / e-maily klientů	„klient Jan N.”, jan@…	„klient”, „e-commerce projekt”
Názvy konkrétních firem	reálné obchodní jméno	obecný typ projektu
Identifikátory	IČO, DIČ, č. faktury, č. účtu	vynech úplně
Konkrétní názvy produktů/SKU	interní kódy	obecný popis

2. Sanitizační kuchařka — krok za krokem

1. Abstrahuj incident na vzor. Ptej se: „jaký obecný technický problém to ilustruje?” Konkrétní firma/server/částka jsou pro poučení nepodstatné.

2. Nahraď konkrétní hodnoty placeholdery podle tabulky výše (<SERVER_IP>, <API_KEY>, „platební brána” místo názvu, …).

3. Generalizuj stack. Místo „Supabase na našem Hetzneru” napiš „self-hosted Postgres přes REST gateway (PostgREST)”. Verze a vendor jen pokud jsou pro bug podstatné.

4. Projdi code snippety. Odstraň reálné domény, ID, klíče, e-maily. Nech jen ilustrativní foo, example.com, <TOKEN>.

5. Závěrečná kontrola (grep): v celém záznamu nesmí zůstat: číslice vypadající jako IP, řetězce sk_, pk_, Bearer, @(reálný e-mail), password, secret, reálné obchodní jméno.

6. Test „je to užitečné cizímu člověku?” Pokud záznam dává smysl jen někomu, kdo zná konkrétní projekt → ještě jsi dostatečně neabstrahoval.

Abstrakce na vzor není jen kvůli bezpečnosti — je to přesně to, co dělá záznam **užitečným pro ostatní**. Konkrétní incident → univerzální poučení.

3. Jak přidat záznam (workflow pro bota i člověka)

1. Najdi/zvol kategorii (deploy, payments, auth, database, frontend, monitoring, integrations, performance, security, ai-agents).

2. Zkontroluj duplicitu — projdi existující záznamy v kategorii (nebo fetch /llms-full.txt). Když už podobný existuje, rozšiř ho, nezakládej nový.

3. Vytvoř soubor src/content/docs/<kategorie>/<kebab-case-nazev>.md podle šablony.

4. Vyplň frontmatter i tělo (Symptom → Root cause → Fix → Jak se vyvarovat → Sister bugs).

5. Projdi sanitizační kuchařku z bodu 2. ← povinné, bez výjimky.

6. Commit + push do větve main:

   cd ~/Projects/tools/bug-wiki
   git add src/content/docs/<kategorie>/<soubor>.md
   git commit -m "bug(<kategorie>): <krátký popis>"
   git push

7. GitHub Action web sám přebuduje a nasadí (~30 s). Hotovo.

4. Checklist před commitem

• Frontmatter má title, description, category, severity, status, date, prevention.
• Tělo má všechny sekce ze šablony.
• Prošel jsem sanitizační kuchařku (bod 2). Žádné IP / secrets / klienti / firmy.
• Záznam dává smysl i bez znalosti konkrétního projektu.
• Soubor je ve správné kategorii, název je kebab-case.