---
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.