Wealth Watcher v0.7.0

Wealth Watcher v0.7.0

Highlights

• Rebuilds Budget as a group-based planner. Create, rename, recolour, reorder, and remove custom groups, organize line items into categories, and inspect monthly-equivalent allocations through a drill-down flow with desktop, mobile, and accessible list views.
• Adds version-2 budget settings persistence. The API stores group and category metadata alongside compatibility budget lines, preserves stable item identities and Forecast asset links, accepts legacy budget arrays during upgrade, and validates the complete document atomically.
• Moves application release information from Settings to a dedicated Application page linked from the app bar. Existing #settings?panel=application-version links redirect to #application, and missing version metadata now has an explicit fallback state.
• Updates FIRE and Forecast budget calculations and milestone context to use the grouped budget model, including custom savings groups and clear disabled, unconfigured, progress, and complete milestone states.

Fixes

• Budget edits preserve an existing Forecast asset mapping when assetId is omitted while still allowing an explicit clear, and reject duplicate or unknown identifiers, invalid amounts or cadences, invalid groups, and conflicting legacy writes without partially applying the request.
• Budget flow drill-down links, category labels, mobile colour accents, table containment, and group-editor state stay aligned across responsive layouts; uncategorised line items remain visible instead of disappearing from the flow.
• The browser-only demo now mirrors the grouped-budget API contract and migration behaviour, while API, UI, routing, responsive-layout, and demo-parity tests cover the new paths.

Upgrade notes

• This release requires a database migration (20260818093503_AddBudgetV2Document) that adds the nullable BudgetJson column to AppPreferences (requiresMigration: true). The API applies migrations during startup; existing BudgetLines remain in place. Existing legacy budget data is returned with needsUpdate: true until the Budget page is reviewed and saved successfully, which stores the v2 group document. Review group names, colours, categories, and Forecast asset links after that first save.
• No new production environment variable or Compose setting is required (requiresConfigurationChange: false). Back up PostgreSQL and the configured CONFIG_PATH Data Protection key directory before updating; the key backup is required to recover encrypted integration credentials. After restart, verify /api/health, open Budget, Forecast, FIRE, and Application, and run a representative manual or provider sync.
• For a published-image deployment, set API_IMAGE and WEB_IMAGE to v0.7.0 or an immutable sha-<full-commit-sha> tag, then pull and restart the application services. To roll back, restore the previous v0.6.0 or immutable image tags and repeat the same commands. The migration only adds nullable metadata, so an application rollback does not require a destructive down migration; do not edit and save grouped budget data from the older application because it cannot represent the v2 group metadata. Retain the verified backup and confirm compatibility before rolling back.
• For source development, use the repository-pinned .NET SDK and the Node.js version in .nvmrc; run npm ci --prefix WealthWatcher.UI after pulling the release branch. The production Docker path still requires Docker and Docker Compose, with private .env and configuration data kept outside the repository.

Docker images

• ghcr.io/paevans87/wealth-watcher-public-api:v0.7.0
• ghcr.io/paevans87/wealth-watcher-public-web:v0.7.0
• The successful tagged workflow also moves the stable latest alias for both images.
• Image digests are not available until the tagged build completes. Record the published digests from that workflow when immutable release evidence or deployment pinning is required; sha-<full-commit-sha> remains available for commit-based rollback.

Known issues

• Legacy consumers still receive the four compatibility budget arrays. A custom group without a recognized legacy role is mapped to the legacy Spend category, so those consumers cannot represent every custom group distinction; use a recognized savings role or Savings-labelled group when legacy Forecast behaviour is required.
• FIRE and Forecast projections remain illustrative estimates based on configured assumptions and available history. Results can be unavailable or unreachable when Forecast is disabled, data is incomplete, or the assumptions cannot produce a target date.
• The browser-only public demo uses fictional, resettable data and does not connect to the API, database, accounts, or provider integrations. The application also has no built-in authentication, authorization, or tenant isolation; keep it on the local machine or a trusted network.