What
frontend/taskdeck-web/src/store/telemetryStore.ts:158 hardcodes appVersion: '0.1.0', // Will be set from build config in future in every telemetry event payload. Nothing in the UI renders it, and the backend-reported product version (Taskdeck.Application.Common.ProductVersion → /health/live, /health/ready, CLI version) is tag-derived and correct — but a v0.2.0 build still self-reports 0.1.0 in telemetry traces, and every future release will drift the same way.
Found by the 2026-08-29 v0.2.0 release-readiness audit (finding F-8). Not tag-blocking, not user-visible.
Acceptance
Related: #1804 (backend version stamp), #1948 (truthful sidebar version stamp).
What
frontend/taskdeck-web/src/store/telemetryStore.ts:158hardcodesappVersion: '0.1.0', // Will be set from build config in futurein every telemetry event payload. Nothing in the UI renders it, and the backend-reported product version (Taskdeck.Application.Common.ProductVersion→/health/live,/health/ready, CLIversion) is tag-derived and correct — but a v0.2.0 build still self-reports0.1.0in telemetry traces, and every future release will drift the same way.Found by the 2026-08-29 v0.2.0 release-readiness audit (finding F-8). Not tag-blocking, not user-visible.
Acceptance
appVersioncomes from build configuration (e.g. a Vitedefinefed by the release workflow's tag-derived version, with the same0.0.0-devfallback the backend uses) instead of a literal; do not hand-bump the literal to0.2.0.telemetryApicontract/spec updated to assert the injected value.docs/platform/CONFIGURATION_REFERENCE.mdor the release workflow comment records where the frontend version comes from.Related: #1804 (backend version stamp), #1948 (truthful sidebar version stamp).