Search/catalog planning notes

.planning/seeds/home-tab-content.md

@@ -0,0 +1,36 @@
+---
+title: Scope widgetów tab Home
+trigger_condition: Przed rozpoczęciem Phase 10 (UI chrome polish) lub gdy Phase 2.1 (app shell/navigation/search) wchodzi w fazę projektowania ekranów
+planted_date: 2026-05-16
+---
+
+# Scope widgetów tab Home
+
+## Kontekst
+
+Decyzja kierunkowa (patrz `notes/nav-search-as-catalog.md`): dodajemy tab Home przed Planerem. Charakter: landing z podpowiedziami i podsumowaniami — *coś musi mówić użytkownikowi*, nie być pustym powitaniem.
+
+## Otwarte pytanie
+
+Co konkretnie pokazujemy na Home, żeby:
+- nie dublować funkcji Planera/Spiżarni/Zakupów,
+- być realną wartością przy pierwszym otwarciu appki rano,
+- nie spuchnąć do nieczytelnego dashboardu z 8 sekcjami.
+
+## Kandydaci do rozważenia
+
+- **"Co jemy dziś / jutro"** — wycinek planera w formie karty; tap → Planer otwarty na danym dniu.
+- **"Czego brakuje do najbliższych posiłków"** — shortcut do brakujących składników; tap → Zakupy / Spiżarnia.
+- **"Propozycje przepisów"** — sugestie oparte na: ostatnio dodane, sezonowe, "na podstawie tego co masz w lodówce" (przyszła funkcja).
+- **"Szybkie akcje"** — m.in. potencjalne miejsce na "+Dodaj przepis".
+- **Powitanie / pasywny landing** — odrzucone we wstępnej dyskusji (Home ma podpowiadać).
+
+## Pytania pomocnicze do rozstrzygnięcia później
+
+- Czy Home jest *statyczny* (zawsze te same sekcje), czy *adaptacyjny* (sekcje pojawiają się zależnie od stanu — np. "brakuje produktów" tylko gdy faktycznie brakuje)?
+- Czy Home wystarczy na MVP w minimalnej formie (1-2 sekcje), czy czekamy z nim do momentu, gdy mamy więcej funkcji do podsumowania?
+- Czy Home jest też miejscem na onboarding (przy pierwszym uruchomieniu)?
+
+## Rekomendowana ścieżka
+
+`/gsd-sketch` na początku Phase 2.1 lub Phase 10 — Home to wyraźny przypadek "what should this look like / feel" z wieloma stanami do wyklikania w HTML.