feat(app): add localization and dashboard polish

- add Italian and Chinese locale support across the app shell, settings, widgets, and energy surfaces
- add reusable overlay scroll area behavior and room navigation scrollbar polish
- improve Home Assistant connection handling and dashboard/store coverage
- update docs and package metadata for the expanded app behavior

Author: awesomestvi

AGENTS.md

@@ -58,7 +58,7 @@ style paths in Storybook configuration.
 
 ```
 src/app/
-  features/        # 17+ domain modules — each owns its hooks, stores, components
+  features/        # 16 domain modules — each owns its hooks, stores, components
   components/
     ui/            # Radix UI wrappers (buttons, dialogs, selects …)
     layout/        # Header, sidebar, navigation
@@ -260,7 +260,7 @@ copy all service state on every event.
 - Pushes to `main` publish only developer app images: `ghcr.io/awesomestvi/navet:dev` and `sha-*`.
 - Manual Publish workflow runs are for developer hardware testing and default to the `dev` app image tag.
 - Public beta app images publish only from `v*-alpha.*`, `v*-beta.*`, and `v*-rc.*` tags. They update the exact tag, `beta`, `latest`, and `sha-*`.
-- Home Assistant add-on images do not publish on every `main` push. They publish on manual workflow runs as `dev` or on public beta tags as add-on version, `beta`, `latest`, and `sha-*`.
+- Home Assistant add-on images publish `dev` and `sha-*` on `main` pushes or manual workflow runs, and add-on version, `beta`, `latest`, and `sha-*` on public beta tags.
 - There is no stable channel yet. Treat `latest` as the current public beta compatibility tag because existing users already consume it.
 
 ---

CONTRIBUTING.md

@@ -53,6 +53,11 @@ This project adheres to a code of conduct. By participating, you are expected to
    pnpm dev
    ```
 
+   Open the URL Vite prints, usually `http://localhost:5173`. For live Home Assistant testing,
+   enter your Home Assistant URL and long-lived access token in the onboarding screen. Normal source
+   development does not require copying `.env.example`; the repo-root `.env` flow is for
+   Docker/add-on runtime defaults and production-style preview work.
+
 ## 💻 Development Process
 
 ### Branch Strategy
@@ -100,7 +105,8 @@ This project adheres to a code of conduct. By participating, you are expected to
 
 ### CI and local checks
 
-Pull requests and pushes to `main` run **GitHub Actions** (`.github/workflows/ci.yml`) in this order:
+Pull requests and all branch pushes run **GitHub Actions** (`.github/workflows/ci.yml`) in this
+order:
 
 1. `pnpm check` — Biome lint and format
 2. `pnpm check:stories` — Storybook title and ownership rules
@@ -109,7 +115,9 @@ Pull requests and pushes to `main` run **GitHub Actions** (`.github/workflows/ci
 5. `pnpm test` — Vitest unit tests
 6. `pnpm build` — production Vite build
 
-Before opening a PR, run the same sequence locally (or at minimum `pnpm check`, `pnpm check:ui-kit`, `pnpm typecheck`, and `pnpm test`) so CI stays green.
+Before opening a PR, run the relevant fast checks for the area you changed, such as `pnpm check`,
+`pnpm check:stories`, `pnpm check:ui-kit`, `pnpm typecheck`, and `pnpm test`. CI remains the
+source of truth for the production `pnpm build` step.
 
 [Dependabot](.github/dependabot.yml) opens weekly PRs for npm dependency updates; review them for breaking changes before merge.
 
@@ -205,9 +213,9 @@ The current hook split is:
   - enforces the Conventional Commit format: `type(scope): summary`
 - `pre-commit`
   - `pnpm check:lockfile` to keep `package.json` and `pnpm-lock.yaml` in sync
-- `pnpm check` for Biome lint/format issues
-- `pnpm check:stories` for Storybook title conventions, primitive/pattern story coverage, and colocated story ownership
-- `pnpm check:ui-kit` for shared UI boundary rules
+  - `pnpm check` for Biome lint/format issues
+  - `pnpm check:stories` for Storybook title conventions, primitive/pattern story coverage, and colocated story ownership
+  - `pnpm check:ui-kit` for shared UI boundary rules
 - `pre-push`
   - `pnpm typecheck`
   - `pnpm test`

README.md

@@ -165,6 +165,10 @@ volumes:
   navet-data:
 ```
 
+`latest` tracks the current public beta tag. Pushes to `main` publish developer images as `dev` and
+`sha-*`, so production-style deployments should use `latest`, `beta`, or a specific prerelease tag
+instead of expecting `main` to update `latest`.
+
 Start Navet:
 
 ```bash
@@ -202,8 +206,8 @@ Use the source workflow when developing Navet, testing changes, or contributing
 
 - Node.js `^20.19.0` or `>=22.12.0`
 - `pnpm`
-- A running Home Assistant instance
-- A Home Assistant long-lived access token
+- A running Home Assistant instance only when testing live Home Assistant behavior
+- A Home Assistant long-lived access token only when connecting the local app to that instance
 
 ### Install
 
@@ -213,28 +217,20 @@ cd navet
 pnpm install
 ```
 
-### Configure Home Assistant
-
-Create `.env` from the example file:
-
-```bash
-cp .env.example .env
-```
-
-Set your Home Assistant URL and token:
-
-```env
-NAVET_HASS_URL=http://your-home-assistant:8123
-NAVET_HASS_TOKEN=your-long-lived-access-token
-```
-
 ### Start the app
 
 ```bash
 pnpm dev
 ```
 
-Open the URL Vite prints, usually `http://localhost:5173`.
+Open the URL Vite prints, usually `http://localhost:5173`. For live Home Assistant testing, enter
+your Home Assistant URL and long-lived access token in the onboarding screen. The local app stores
+that session in browser storage, so contributors do not need a repo-root `.env` file for normal
+development.
+
+Use `.env.example` only when you need runtime defaults for Docker, add-on, or production-style
+preview flows. `NAVET_HASS_URL` and `NAVET_HASS_TOKEN` are deployment/runtime values, not required
+source setup.
 
 For a production-style local preview:
 
@@ -246,12 +242,15 @@ pnpm preview
 
 ```bash
 pnpm dev
-pnpm typecheck
-pnpm check
+pnpm check:stories
+pnpm check:ui-kit
 pnpm test
 pnpm storybook
 ```
 
+CI also runs `pnpm check`, `pnpm typecheck`, and `pnpm build`. Follow the repository instructions for
+when to run those locally.
+
 ### Project docs
 
 - [docs/README.md](docs/README.md): active documentation index

addons/navet-dev/README.md

@@ -1,17 +1,17 @@
 # Navet Dev Home Assistant Add-on
 
-This add-on serves the latest manually published Navet development image through Home Assistant
-Ingress. It is intended for testing changes before they are released through the regular `Navet`
-add-on.
+This add-on serves the latest Navet development image through Home Assistant Ingress. It is intended
+for testing changes before they are released through the regular `Navet` add-on.
 
 The image is pulled from GitHub Container Registry using the `dev` tag:
 
 ```text
 ghcr.io/awesomestvi/{arch}-navet-addon:dev
 ```
 
-Publish a fresh dev image by running the **Publish Home Assistant Add-on** GitHub Actions workflow
-manually, then refresh the add-on repository in Home Assistant and rebuild or reinstall this add-on.
+Fresh dev images publish on `main` pushes and can also be published by running the **Publish Home
+Assistant Add-on** GitHub Actions workflow manually. After publishing, refresh the add-on repository
+in Home Assistant and rebuild or reinstall this add-on.
 
 ## Configuration
 

addons/navet/README.md

@@ -4,7 +4,8 @@ This add-on serves the Navet frontend through Home Assistant Ingress.
 
 [![Open your Home Assistant instance and show the add add-on repository dialog with a specific repository URL pre-filled.](https://my.home-assistant.io/badges/supervisor_add_addon_repository.svg)](https://my.home-assistant.io/redirect/supervisor_add_addon_repository/?repository_url=https%3A%2F%2Fgithub.com%2Fawesomestvi%2Fnavet)
 
-The Home Assistant add-on now pulls a prebuilt container image from GitHub Container Registry instead of relying on committed frontend build artifacts in `addons/navet/www/`.
+The Home Assistant add-on pulls a prebuilt container image from GitHub Container Registry instead
+of relying on checked-in frontend assets inside the add-on directory.
 
 The image is built from the repository root in CI, which allows the add-on image to compile the frontend directly from source while still keeping the add-on metadata in `addons/navet/`.
 

design-system/FEATURES.md

@@ -9,7 +9,6 @@ coverage is expected to exist.
 Current active feature folders under
 [`src/app/features/`](../src/app/features):
 
-- `auth`
 - `calendar`
 - `climate`
 - `dashboard`
@@ -313,12 +312,15 @@ Vitest is the preferred path for:
 Current co-located `__tests__/` directories:
 
 - `src/app/components/layout/__tests__/`
+- `src/app/components/primitives/__tests__/`
 - `src/app/components/shared/theme/__tests__/`
 - `src/app/components/system/tokens/__tests__/`
 - `src/app/features/calendar/components/calendar/__tests__/`
+- `src/app/features/climate/utils/__tests__/`
 - `src/app/features/dashboard/components/__tests__/`
 - `src/app/features/dashboard/hooks/__tests__/`
 - `src/app/features/dashboard/stores/__tests__/`
+- `src/app/features/dashboard/utils/__tests__/`
 - `src/app/features/energy/components/dashboard/__tests__/`
 - `src/app/features/energy/components/energy-setup-wizard/__tests__/`
 - `src/app/features/energy/services/__tests__/`
@@ -328,10 +330,16 @@ Current co-located `__tests__/` directories:
 - `src/app/features/media/components/media-card/__tests__/`
 - `src/app/features/media/components/media/__tests__/`
 - `src/app/features/rss/components/rss-feed-card/__tests__/`
+- `src/app/features/security/components/__tests__/`
+- `src/app/features/security/components/cover-card/__tests__/`
+- `src/app/features/security/utils/__tests__/`
 - `src/app/features/tasks/components/__tests__/`
 - `src/app/features/tasks/utils/__tests__/`
 - `src/app/features/vacuum/components/vacuum/__tests__/`
 - `src/app/hooks/__tests__/`
+- `src/app/hooks/device-mappers/__tests__/`
+- `src/app/services/__tests__/`
+- `src/app/session/__tests__/`
 - `src/app/stores/__tests__/`
 - `src/app/utils/__tests__/`
 

docs/DOCKER_HOME_ASSISTANT_ADDON.md

@@ -111,13 +111,14 @@ Then open `http://localhost:8080`.
 
 ### Release Pipeline
 
-The GitHub Actions publish workflow publishes a multi-arch image to GitHub Container Registry on pushes to `main`, and it can also be run manually:
+The GitHub Actions publish workflow publishes multi-arch app images to GitHub Container Registry:
 
-- `ghcr.io/<owner>/navet:main`
-- `ghcr.io/<owner>/navet:sha-<commit>`
-- `ghcr.io/<owner>/navet:latest`
+- pushes to `main`: `ghcr.io/<owner>/navet:dev` and `ghcr.io/<owner>/navet:sha-<commit>`
+- public prerelease tags (`v*-alpha.*`, `v*-beta.*`, `v*-rc.*`): exact tag, `beta`, `latest`, and `sha-*`
+- manual workflow runs: the requested developer tag, defaulting to `dev`, plus `sha-*`
 
-Manual dispatch can still publish an additional version tag such as `0.1.0-beta.3`.
+`latest` is the current public beta compatibility tag. It is updated by prerelease tags, not by
+ordinary `main` pushes.
 
 ### GHCR Deployment
 
@@ -183,7 +184,7 @@ Assistant pulls `ghcr.io/awesomestvi/{arch}-navet-addon:dev`.
 Typical flow:
 
 1. Push changes to the repository
-2. Merge or push to `main` and wait for **Publish Home Assistant Add-on** to publish the `dev` image
+2. Merge or push to `main`, or manually run **Publish Home Assistant Add-on**, and wait for it to publish the `dev` image
 3. In Home Assistant, open Settings -> Add-ons -> Add-on Store
 4. Refresh the custom add-on repository
 5. Open the `Navet Dev` add-on
@@ -257,7 +258,7 @@ The current add-on still expects explicit Home Assistant connection details. It
 
 ## CI Pipeline
 
-The CI workflow runs on pushes to `main` and on pull requests. It currently:
+The CI workflow runs on all branch pushes and pull requests. It currently:
 
 1. Installs dependencies with the pinned `pnpm`
 2. Runs `pnpm check`

docs/ROADMAP.md

@@ -55,7 +55,7 @@ Planned and in-progress features. Check off items as they ship. Add new ideas to
 
 - [x] **Public demo mode** — `/demo` renders a generated smart home environment with bundled assets and no Home Assistant connection, suitable for public previews without exposing private instances or tokens
 - [x] **Public launch deployment hardening** — Docker and Home Assistant add-on deployments share nginx security headers; runtime config keeps Home Assistant tokens server-only; RSS proxying, imported dashboard config, external URLs, and custom button service calls validate public-facing inputs
-- [x] **Home Assistant add-on image publishing** — add-on CI/CD builds pull request images and publishes `main` branch images to GHCR for supported architectures
+- [x] **Home Assistant add-on image publishing** — add-on CI/CD publishes `dev` images from `main` and manual workflow runs, plus versioned public beta images for supported architectures
 - [x] **Automation management** — Tasks section lists Home Assistant automations, shows active/disabled filters, displays last-run metadata and read-only config details, and supports trigger plus enable/disable actions
 - [x] **Security camera dashboard** — dedicated security camera dashboard model and view with camera live viewing support, entity mapping, stories, and tests
 - [x] **Energy history** — per-device and per-source consumption over time with Home Assistant Energy prefs, recorder statistics, source diagnostics, tracked-device sparklines, and drill-down to individual appliances

docs/VERSIONING.md

@@ -55,16 +55,17 @@ Recommended lightweight flow:
 
 1. Decide whether the change is `patch`, `minor`, or `beta prerelease`.
 2. Bump `package.json`.
-3. If the release meaning changed, update this file.
-4. Tag the commit with `v<version>`, for example `v0.1.1-beta.1`.
-5. Push the tag to GitHub to trigger [.github/workflows/github-release.yml](../.github/workflows/github-release.yml).
-6. If needed, manually run the container publish workflows for matching image tags.
+3. For add-on releases, bump `addons/navet/config.yaml` and update `addons/navet/CHANGELOG.md`.
+4. If the release meaning changed, update this file.
+5. Tag the commit with a prerelease tag such as `v0.1.1-beta.1`.
+6. Push the tag to GitHub to trigger [.github/workflows/github-release.yml](../.github/workflows/github-release.yml), app image publishing, and add-on image publishing.
+7. For developer hardware testing before a public tag, manually run the publish workflows with the `dev` tag.
 
 ## GitHub Releases
 
-- Tags matching `v*` create a GitHub Release automatically.
-- Tags containing `-beta.`, `-alpha.`, or `-rc.` are published as GitHub prereleases.
-- Stable tags such as `v0.1.0` are published as normal releases.
+- Prerelease tags matching `v*-alpha.*`, `v*-beta.*`, or `v*-rc.*` create a GitHub Release automatically.
+- The current release workflow marks those releases as prereleases.
+- Stable `v*` tags are not part of the current automated workflow; add one deliberately when Navet has a stable channel.
 
 ## Stable Exit
 

package.json

@@ -67,16 +67,16 @@
   },
   "devDependencies": {
     "@biomejs/biome": "^2.4.15",
-    "@storybook/addon-a11y": "^10.3.6",
-    "@storybook/addon-docs": "10.3.6",
-    "@storybook/addon-vitest": "^10.3.6",
-    "@storybook/react": "10.3.6",
-    "@storybook/react-vite": "^10.3.6",
+    "@storybook/addon-a11y": "^10.4.0",
+    "@storybook/addon-docs": "10.4.0",
+    "@storybook/addon-vitest": "^10.4.0",
+    "@storybook/react": "10.4.0",
+    "@storybook/react-vite": "^10.4.0",
     "@tailwindcss/vite": "4.3.0",
     "@testing-library/jest-dom": "^6.9.1",
     "@testing-library/react": "^16.3.2",
     "@types/leaflet": "^1.9.21",
-    "@types/node": "^25.8.0",
+    "@types/node": "^25.9.0",
     "@types/react": "^19.2.14",
     "@types/react-dom": "^19.2.3",
     "@vitejs/plugin-react": "6.0.2",
@@ -88,7 +88,7 @@
     "storybook": "^10.4.0",
     "tailwindcss": "4.3.0",
     "typescript": "^6.0.3",
-    "vite": "8.0.12",
+    "vite": "8.0.13",
     "vite-plugin-pwa": "^1.3.0",
     "vitest": "^4.1.6"
   },