Improved the v3.0.10 cross-field validation message and made it clickable. The v3.0.10 validator correctly refused updates.github.notify.ntfy: true when ntfy wasn't configured, but the error message had three rough edges that surfaced when the validation actually fired in real use: the phrasing was technical and a little cold ("Cannot enable update push without ntfy configured"), it named raw YAML key paths in user-facing copy ("Set notifications.enabled: true on the Notifications tab"), and it offered no way to navigate to the place the user needed to fix things. The new message reads "Configure ntfy on the Notifications tab: turn ntfy on, set a URL." — shorter, imperative, matches the voice of every other validator message in the codebase, and the "Notifications tab" portion is a real clickable link that takes the user directly to where they need to be. The "turn ntfy on, set a URL" suffix adapts based on which pieces are missing: both → "turn ntfy on and set a URL", only the master switch → "turn ntfy on", only the URL → "set a URL". One click from error to fix.
The link works because the field-error renderer injects the validation message via template literal without escaping (line 1021 of templates/config.html), so a real <a> tag in the message string renders as clickable HTML. This is safe in our specific case because validator messages come from server-side Python code hardcoded in the codebase — never from user input — so there's no XSS surface even though the renderer doesn't sanitize. The target URL is /config#notifications which uses the existing v2.42.1 URL-hash tab-routing convention.
Required a companion fix to complete v2.42.1's hash-routing feature. v2.42.1 read the URL hash on page load to set the initial active tab (so /config#notifications would open the Notifications tab when navigated to from another page or from a bookmark), and updated the hash via history.replaceState whenever the user clicked a tab button. But it never registered a hashchange event listener, meaning if the hash changed while the page was open (clicking an <a href="/config#x"> link, hitting browser back/forward, manually editing the URL), the tab wouldn't actually switch — only the URL would update. That gap was invisible until v3.0.11's improved validation message introduced an in-page link that depends on hash-driven tab switching. The fix is a 5-line addition right after switchTab(): window.addEventListener('hashchange', ...) that calls switchTab() when the hash changes externally. Net effect beyond the validation use case: browser back/forward across tabs now works naturally (the back button on the Updates tab now returns to whatever tab the user was on previously, rather than navigating away from /config entirely), and any future in-page deep links to specific tabs will Just Work.
Architectural slot used: the validator change is contained to the existing validate_config() cross-cutting-checks slot at the bottom of config_validator.py. The hash-listener change is a sibling to switchTab() in templates/config.html, placed immediately after the function it depends on with a comment explaining the v2.42.1 archaeology so the next maintainer doesn't have to reconstruct why the listener exists.
~25 lines of code change total (10 lines in the validator for the new message format and the adaptive copy logic, 8 lines in the template for the hashchange listener). No new dependencies, no schema changes, no behavior change to the channel or the notifier — pure validation-message and tab-navigation improvements on top of unchanged underlying infrastructure.