fix(calendar): remove false offline indicator and reduce spacing

.claude/settings.local.json

@@ -68,7 +68,17 @@
       "Bash(gh pr:*)",
       "Bash(ls /home/gabry848/Documenti/MyTaskly/MyTaskly-app/src/components/*.tsx)",
       "Bash(python3:*)",
-      "Bash(but status:*)"
+      "Bash(but status:*)",
+      "mcp__claude_ai_Notion__notion-fetch",
+      "mcp__claude_ai_Notion__notion-search",
+      "mcp__claude_ai_Notion__notion-update-page",
+      "Bash(openspec list *)",
+      "mcp__revenuecat__list-projects",
+      "mcp__revenuecat__list-apps",
+      "mcp__revenuecat__list-products",
+      "mcp__revenuecat__list-offerings",
+      "mcp__revenuecat__get-product",
+      "mcp__revenuecat__get-product-store-state"
     ],
     "deny": [],
     "defaultMode": "acceptEdits"

openspec/changes/reusable-ui-foundation-plan/.openspec.yaml

@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-28

openspec/changes/reusable-ui-foundation-plan/audit-ui-matrix.md

@@ -0,0 +1,23 @@
+## UI Pattern Matrix
+
+Scope analizzato: `Categories`, `TaskList`, `Calendar`, `Calendar20`, `Home`.
+
+| Pattern | Categories | TaskList | Calendar | Calendar20 | Home | Opportunity |
+|---|---|---|---|---|---|---|
+| Screen header | titolo con `Text` custom | usa navigation header + action icon custom | titolo + toggle icon custom | top bar custom | header con title + azioni | estrarre `ScreenHeader` + `IconActionButton` |
+| Card/surface | card categoria locali | card task con ombre/radius custom | task list usa `Task` card locale | viste interne con superfici locali | bubble/input surface locali | estrarre `CardSurface` |
+| Loading | refresh control native | overlay dots animata custom | `ActivityIndicator` + dots custom | `ActivityIndicator` semplice | loading bubble e indicatori custom | estrarre `LoadingState` (`spinner`,`dots`) |
+| Empty state | non standardizzato | blocco icona + testo inline | blocco icona + testo inline | dipende dalla vista | chat pre-start state custom | estrarre `EmptyState` |
+| Modal shell | `GlobalTaskSearch` + modali categoria locali | `FilterModal` + `AddTask` | `AddTask` | `ViewSelector`, `SearchOverlay`, `MiniCalendar`, `AddTask` | `VoiceChatModal`, `VoiceCalendarModal` | estrarre `ModalShell` base |
+| Input shell | solo search button | task form esterno | task form esterno | task form esterno | input chat duplicato in 2 varianti | estrarre `InputShell` |
+| Status/metadata chip | limitato | filtri/stati custom | sync indicator chips inline | category filters/view selector locali | badge e stati locali | estrarre `StatusChip`/`MetaChip` |
+| Typography scale | titolo 30/700 | mixed local styles | titolo 30/200 + body custom | varianti locali | grande varianza (display/body/caption) | estrarre `AppText` + token typography |
+| Spacing/radii/elevation | numeri hardcoded | numeri hardcoded | numeri hardcoded | numeri hardcoded | numeri hardcoded | estrarre token `spacing`,`radius`,`elevation` |
+
+## Duplicazioni critiche emerse
+
+1. Titoli schermata non uniformi (peso/font-size diversi tra screen principali).
+2. Loader multipli con logiche simili ma implementazioni diverse.
+3. Empty state ripetuti con icona + testo hardcoded.
+4. Card/bubble/input surfaces con bordi, radius, ombre ricreate localmente.
+5. Chip di stato/sync e metadati implementati in modo ad-hoc.

openspec/changes/reusable-ui-foundation-plan/design.md

@@ -0,0 +1,89 @@
+## Context
+
+Le schermate analizzate (`Categories`, `TaskList`, `Calendar`, `Home`) mostrano una forte duplicazione di pattern UI:
+- tipografia hardcoded (`fontSize`, `fontWeight`, `letterSpacing`, `fontFamily: "System"`) con varianti incoerenti;
+- container e superfici ripetute (`backgroundColor: "#ffffff"`, ombre, bordi, raggi);
+- loader custom multipli (dots animation in `TaskListContainer` e `CalendarView`, `ActivityIndicator` diretto in altri punti);
+- shell di input/card/modal implementate localmente con stili simili ma non condivisi.
+
+L'obiettivo non e riscrivere tutto subito, ma introdurre una base riusabile che riduca i macro-componenti e abiliti refactor incrementale senza regressioni funzionali.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Definire token di design riutilizzabili per typography, spacing, radius, elevation e colori neutrali.
+- Introdurre primitive UI composabili per screen header, card shell, section header, chip, empty state, loading state, modal shell e content container.
+- Preparare un piano di migrazione progressivo per `Categories`, `TaskList`, `Calendar` e compatibilita con `Home`.
+- Ridurre l'uso di stile inline e stringhe colore/font duplicate nelle schermate target.
+
+**Non-Goals:**
+- Rebranding grafico completo o cambio radicale della visual identity.
+- Migrazione completa di tutte le schermate in un'unica PR.
+- Sostituzione totale delle librerie di animazione o navigazione esistenti.
+- Cambiamenti funzionali ai flussi business (sync, CRUD task, chat logic).
+
+## Decisions
+
+### Decisione 1: Introdurre un layer `UI Foundation` in `src/components/UI/foundation` + `src/theme`
+**Scelta:** creare moduli condivisi:
+- `src/theme/tokens.ts` (spacing, typography scale, radii, elevation, semantic colors),
+- `src/theme/primitives.ts` (helper e mapping runtime),
+- `src/components/UI/foundation/*` (primitive React Native).
+
+**Razionale:** separa stile e composizione da feature business, facilita consistenza e testing visuale.
+
+**Alternative considerate:**
+- mantenere style object locali e fare solo cleanup manuale -> scarsa scalabilita;
+- usare libreria design-system esterna completa -> overhead alto per stato attuale del progetto.
+
+### Decisione 2: Definire primitive “thin” e composabili invece di nuovi macro-componenti
+**Scelta:** introdurre componenti base a responsabilita singola:
+- `ScreenContainer`, `ScreenHeader`, `AppText`, `CardSurface`, `SectionBlock`, `StatusChip`, `EmptyState`, `LoadingState`, `ModalShell`.
+
+**Razionale:** le schermate restano owner del flusso dati ma delegano il rendering ricorrente; evita monoliti difficili da riusare.
+
+**Alternative considerate:**
+- creare un unico `SmartScreenScaffold` onnicomprensivo -> poco flessibile e rischio coupling.
+
+### Decisione 3: Loader unificato con varianti
+**Scelta:** standardizzare in un singolo `LoadingState` con varianti:
+- `spinner`,
+- `dots`,
+- `skeleton-card` (fase successiva).
+
+**Razionale:** oggi esistono almeno tre pattern loader diversi; unificando API e animazioni si migliora coerenza e manutenzione.
+
+**Alternative considerate:**
+- lasciare loader per schermata -> UI incoerente e logica animazioni duplicata.
+
+### Decisione 4: Migrazione per feature slices (Calendar/Task/Categories/Home)
+**Scelta:** refactor incrementale per schermata, con fallback semplice (si puo mantenere uno style locale se la primitive non copre un edge case).
+
+**Razionale:** riduce rischio regressioni e mantiene PR reviewabili.
+
+**Alternative considerate:**
+- big-bang migration completa -> alto rischio conflitti e bug UX.
+
+## Risks / Trade-offs
+
+- **[Rischio] Over-abstraction precoce** -> **Mitigazione:** introdurre solo primitive validate da almeno 2 schermate.
+- **[Rischio] Regressioni di spacing/typography visive** -> **Mitigazione:** checklist visuale per schermata e verifica manuale su device principali.
+- **[Rischio] Team adoption parziale** -> **Mitigazione:** documentare linee guida e usare lint rule/readme per nuovi componenti UI.
+- **[Trade-off] Layer aggiuntivo iniziale** -> **Mitigazione:** naming semplice, props minime, esempi pratici in `tasks.md`.
+
+## Migration Plan
+
+1. Creare tokens + primitive base senza toccare feature logic.
+2. Migrare `Categories` (screen header + container + spacing + action zone).
+3. Migrare `TaskList` (loading, section title, empty state, card shell fragments).
+4. Migrare `Calendar` e `Calendar20` (header blocks, loading, empty state, chip/sync indicator shell).
+5. Rifinire compatibilita con `Home` (header actions, input shell, loading bubble pattern).
+6. Rimuovere stili duplicati rimasti e documentare i pattern standard.
+
+Rollback: mantenere le primitive backward-compatible e migrare file-by-file; eventuale rollback limitato al singolo screen commit.
+
+## Open Questions
+
+- Conviene centralizzare anche icon size tokens (es. `icon.sm/md/lg`) nella prima iterazione?
+- `Home` richiede un `ChatInputShell` dedicato oppure basta comporre `CardSurface + InputRow + IconButton`?
+- Si desidera aggiungere snapshot/UI tests per primitive critiche in questa change o in una successiva?

openspec/changes/reusable-ui-foundation-plan/proposal.md

@@ -0,0 +1,27 @@
+## Why
+
+Le schermate `Categories`, `TaskList`, `Calendar` e `Home` usano pattern visivi simili (titoli, card, loader, vuoti, contenitori, modali) ma implementati in modo diverso e locale. Questo rende difficile mantenere coerenza, velocita di sviluppo e qualita UX quando si aggiungono nuove feature.
+
+## What Changes
+
+- Definire una UI foundation condivisa per spacing, tipografia, colori neutrali, raggi, ombre e layout container.
+- Introdurre componenti composabili riutilizzabili per header di schermata, card shell, blocchi di metadata, stati vuoti, indicatori di caricamento e shell modali.
+- Standardizzare i pattern di interazione comuni (FAB, input shell, chip/badge stato, section title).
+- Definire una roadmap di migrazione incrementale partendo da `Categories`, `TaskList`, `Calendar` e compatibilita con `Home`.
+- Documentare naming, props minime, e linee guida di adozione per evitare nuovi macro-componenti monolitici.
+
+## Capabilities
+
+### New Capabilities
+- `ui-foundation-primitives`: token e primitive di base (typography, spacing, colors, radii, elevation, container) con API riusabile in tutta l'app.
+- `ui-composable-patterns`: componenti composti ma generici (card, section, loader, empty state, modal shell, header screen) da applicare alle schermate principali.
+- `ui-migration-playbook`: piano operativo per migrare le schermate target senza regressioni visive o funzionali.
+
+### Modified Capabilities
+- Nessuna capability esistente da modificare (repository senza spec OpenSpec preesistenti).
+
+## Impact
+
+- Aree toccate: `src/components/UI`, `src/components/Task`, `src/components/Category`, `src/components/Calendar`, `src/navigation/screens`.
+- Possibile introduzione di nuovi file di stile condiviso (es. `src/theme/*` o `src/components/UI/foundation/*`).
+- Riduzione progressiva di stili inline e duplicazioni in componenti specifici di schermata.

openspec/changes/reusable-ui-foundation-plan/specs/ui-composable-patterns/spec.md

@@ -0,0 +1,22 @@
+## ADDED Requirements
+
+### Requirement: Reusable surface patterns SHALL standardize cards and sections
+The system SHALL provide composable surface components (card shell, section block, section header) that standardize borders, radius, elevation, and internal spacing patterns.
+
+#### Scenario: Card consistency across modules
+- **WHEN** `Task`, `Category`, or `Calendar` content is rendered in a boxed surface
+- **THEN** the rendered container MUST use the shared card surface pattern instead of independently redefined style objects
+
+### Requirement: Loading and empty states MUST use shared feedback components
+The system MUST provide reusable loading and empty-state components with configurable icon/text and visual variants for list and screen contexts.
+
+#### Scenario: Unified loading behavior
+- **WHEN** a screen enters an initial loading state
+- **THEN** it SHALL render a shared loading component variant (`spinner` or `dots`) with standardized spacing and typography
+
+### Requirement: Modal and action shells SHALL be reusable across features
+The system SHALL expose reusable modal shell and action-row patterns to support feature-level modals without duplicating structure and base styling.
+
+#### Scenario: Modal reuse between features
+- **WHEN** a feature opens a modal for data entry or quick actions
+- **THEN** the modal MUST be composable through a shared modal shell with configurable header, body, and action slots

openspec/changes/reusable-ui-foundation-plan/specs/ui-foundation-primitives/spec.md

@@ -0,0 +1,22 @@
+## ADDED Requirements
+
+### Requirement: Shared design tokens SHALL define foundational visual rules
+The system SHALL expose a shared token set for spacing, typography, colors, radii, and elevation so that screens can consume consistent values instead of local hardcoded style literals.
+
+#### Scenario: Token usage in screen styles
+- **WHEN** a screen defines layout spacing or text styles
+- **THEN** it MUST reference shared tokens for standard values (spacing scale, text roles, semantic colors, radius, shadow/elevation)
+
+### Requirement: Foundation primitives MUST provide reusable layout and text building blocks
+The system MUST provide reusable primitives for common layout and text roles used across task, category, calendar, and home experiences.
+
+#### Scenario: Primitive coverage for common needs
+- **WHEN** a developer builds or refactors a screen section
+- **THEN** they SHALL be able to use foundation components for container, heading text, body text, and grouped spacing without introducing new screen-specific base wrappers
+
+### Requirement: Foundation APIs SHALL remain lightweight and composable
+The system SHALL keep primitive component APIs minimal and composable to prevent creation of new macro-components with mixed responsibilities.
+
+#### Scenario: No monolithic primitive contracts
+- **WHEN** a new foundation primitive is introduced
+- **THEN** it MUST focus on a single concern (for example surface, typography, spacing, or status tag) and avoid coupling business logic or screen-specific behavior

openspec/changes/reusable-ui-foundation-plan/specs/ui-migration-playbook/spec.md

@@ -0,0 +1,22 @@
+## ADDED Requirements
+
+### Requirement: Migration plan SHALL prioritize target screens in defined order
+The system SHALL define and follow a phased migration order covering `Categories`, `TaskList`, and `Calendar` first, with `Home` used as compatibility validation context.
+
+#### Scenario: Ordered migration execution
+- **WHEN** migration tasks are executed
+- **THEN** implementation MUST prioritize shared primitives adoption on the target screens before broader rollout
+
+### Requirement: Migration SHALL preserve existing business behavior
+The system SHALL preserve existing screen behavior (task CRUD, sync indicators, chat interactions, navigation) while refactoring visual composition to shared components.
+
+#### Scenario: Visual refactor without functional regressions
+- **WHEN** a screen is refactored to foundation components
+- **THEN** user-visible business actions and data flows MUST continue to work equivalently to the pre-migration implementation
+
+### Requirement: Migration checklist MUST define verification criteria
+The system MUST include a per-screen verification checklist for typography, spacing, loading state, empty state, modal shell, and interactive controls after each migration slice.
+
+#### Scenario: Post-migration validation
+- **WHEN** a migration slice is completed for a screen
+- **THEN** the team SHALL verify checklist criteria before marking the slice as done

openspec/changes/reusable-ui-foundation-plan/tasks.md

@@ -0,0 +1,54 @@
+## 1. Audit e baseline UI
+
+- [x] 1.1 Estrarre in una matrice i pattern duplicati nelle schermate `Categories`, `TaskList`, `Calendar`, `Calendar20`, `Home` (header, card, loader, empty, modal, input shell)
+- [x] 1.2 Definire naming convention e cartelle target (`src/theme`, `src/components/UI/foundation`) per token e primitive
+- [x] 1.3 Creare checklist visuale di validazione per schermata (tipografia, spazi, elevazione, stati di caricamento/vuoto, azioni)
+
+## 2. Fondazioni (token + primitive)
+
+- [x] 2.1 Implementare `src/theme/tokens.ts` con scale di spacing, typography roles, colori semantici neutrali, radius, elevation
+- [x] 2.2 Implementare `AppText` con varianti (`display`, `title`, `subtitle`, `body`, `caption`, `label`) basate su token
+- [x] 2.3 Implementare `ScreenContainer` e `ContentContainer` per sostituire wrapper ripetuti `backgroundColor/padding`
+- [x] 2.4 Implementare `ScreenHeader` con supporto titolo, azioni destre, varianti allineamento
+- [x] 2.5 Implementare `CardSurface` con varianti (`default`, `outlined`, `interactive`) e supporto accent border
+
+## 3. Pattern composabili condivisi
+
+- [x] 3.1 Implementare `SectionHeader` (titolo + action slot + opzionale subtitle)
+- [x] 3.2 Implementare `StatusChip`/`MetaChip` per stati task, categoria, sync
+- [x] 3.3 Implementare `LoadingState` con varianti `spinner` e `dots` riusabili
+- [x] 3.4 Implementare `EmptyState` con icona, titolo, descrizione e CTA opzionale
+- [x] 3.5 Implementare `ModalShell` con header/body/footer slot e gestione safe-area
+- [x] 3.6 Implementare `InputShell` (row con leading/trailing action e text input) per pattern usato in `Home`
+
+## 4. Migrazione schermate prioritarie
+
+- [x] 4.1 Migrare `Categories` a `ScreenContainer + ScreenHeader + ContentContainer` e uniformare spazi e titolo
+- [x] 4.2 Migrare componenti categoria principali (`CategoryCard`/vista lista) a `CardSurface` e `SectionHeader`
+- [x] 4.3 Migrare `TaskListContainer` a `LoadingState`, `EmptyState`, `SectionHeader`, chip stato/filtro condivisi
+- [x] 4.4 Migrare `TaskCard` verso composizione `CardSurface + AppText + MetaChip` mantenendo comportamento corrente
+- [x] 4.5 Migrare `CalendarView` a loader/empty/sync chip condivisi e header standardizzato
+- [x] 4.6 Verificare `Calendar20View` su container/header coerenti e compatibilita con pattern foundation
+- [x] 4.7 Applicare hardening su `Home` (header actions, loading bubble pattern, input shell) senza alterare flussi chat
+
+## 5. Validazione, cleanup e adozione
+
+- [x] 5.1 Eseguire smoke test manuale per `Categories`, `TaskList`, `Calendar`, `Home` dopo ogni slice di migrazione
+- [x] 5.2 Rimuovere stili duplicati e inline obsolete nelle schermate migrate
+- [x] 5.3 Aggiungere documentazione d’uso dei nuovi componenti in `src/components/UI/foundation/README.md`
+- [x] 5.4 Definire lista “do/don’t” per evitare nuovi macro-componenti e favorire composizione
+
+## 6. Lista componenti da creare
+
+- [x] 6.1 `AppText`
+- [x] 6.2 `ScreenContainer`
+- [x] 6.3 `ContentContainer`
+- [x] 6.4 `ScreenHeader`
+- [x] 6.5 `CardSurface`
+- [x] 6.6 `SectionHeader`
+- [x] 6.7 `StatusChip` / `MetaChip`
+- [x] 6.8 `LoadingState` (`spinner`, `dots`)
+- [x] 6.9 `EmptyState`
+- [x] 6.10 `ModalShell`
+- [x] 6.11 `InputShell`
+- [x] 6.12 `IconActionButton`

openspec/changes/reusable-ui-foundation-plan/visual-validation-checklist.md

@@ -0,0 +1,34 @@
+## Visual Validation Checklist
+
+Da usare dopo ogni migrazione slice per `Categories`, `TaskList`, `Calendar`, `Home`.
+
+## Global
+
+- [ ] Tipografia coerente con ruoli `display/title/subtitle/body/caption/label`.
+- [ ] Spacing coerente con scala token (niente numeri arbitrari fuori scala).
+- [ ] Radius/elevation coerenti con varianti standard.
+- [ ] Stati focus/press/disabled leggibili e consistenti.
+
+## Categories
+
+- [ ] Header title e azioni rispettano pattern `ScreenHeader`.
+- [ ] Lista categorie usa superfici con spaziature omogenee.
+- [ ] Empty/loading state conformi ai componenti condivisi.
+
+## TaskList
+
+- [ ] Header sezione e filtri leggibili e allineati.
+- [ ] Task card con gerarchia tipografica consistente.
+- [ ] Loader/empty state non usano implementazioni locali duplicate.
+
+## Calendar
+
+- [ ] Header data e azioni rispettano pattern condiviso.
+- [ ] Sync indicator usa chip/metadati standard.
+- [ ] Empty state per data senza task coerente col design system.
+
+## Home
+
+- [ ] Header actions con dimensioni/padding consistenti.
+- [ ] Input shell chat non duplica stili base.
+- [ ] Loading bubble e indicatori rispettano tokens e text roles.

openspec/changes/subscription-plans-screen/.openspec.yaml

@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-17