[ryanbr]

A user asked for the hero rings on the liquid Today screen to open detail, so the Key Metrics tiles below are not the only way to reach a score's own data.

What they did before

HeroScoreCell gave the ring a splash animation and nothing else. The label plus its chevron opened ScoringGuideView. So the card explained how Charge, Effort and Rest are calculated but offered no route to what they actually are, and the obvious target, the ring, did nothing but ripple.

Worth noting for anyone reading the earlier triage: this is LiquidTodayView, not TodayView. The classic screen's Charge ring does open a breakdown sheet; this one's does not, and never did. Same app, different Today.

What changed

The gauge taps through to TabRoute.metric(key), the same value-based route the Recovery Vitals rows already use, landing on the same MetricDetailView the Key-Metrics tile for that score pushes:

ring	key	destination
Charge	recovery	its metric dossier
Effort	strain	its metric dossier
Rest	sleep_performance	its metric dossier

Those are the exact keys the tiles beneath already pass, so a ring and the tile under it cannot lead to different screens.

The label keeps its own job. It still opens the scoring guide, which is this screen's only route to that explainer. The change adds a destination rather than replacing one.

The splash survives, and that took a change

A plain onTapGesture inside a NavigationLink consumes the tap, so the link never fires. That is precisely why a gauge that splashes could not also navigate. LiquidVessel gains an opt-in tapPassesThrough which runs the splash as a simultaneousGesture instead, so both happen: the liquid still splashes and the link still pushes.

It defaults to false, so every other vessel in the app is byte-identical. Only the three hero rings opt in.

Tests

Two, pinning the keys against MetricCatalog. This is not ceremony: TabRoute.metric falls back to the Health screen when a key does not resolve, and its own comment calls that fallback theoretical. Rename a catalog key and the ring would keep working, keep animating, and quietly land on the wrong screen with no crash and nothing in a log. These turn that into a build failure, and they also guard the ring/tile pair from drifting apart.

Scope

Android

The Effort and Rest rings get the same treatment, opening their own vital detail through the onOpenMetric callback the metric cards below already use, so a ring and its card cannot lead to different screens there either.

The Rest key is not the same on the two platforms, and that is deliberate. iOS routes on sleep_performance; Android's VitalDetailScreen resolves rest, and reads the sleep_performance series underneath it. Those are two namespaces: series keys and detail keys. Using the iOS key on Android would compile, run, and render an empty screen, because that when ends in else -> null, so there is no crash and nothing in a log. Both are named constants now, pinned by a test that also asserts sleep_performance is not a detail key, which is the mistake a future reader is most likely to make.

Android's Charge ring still opens its breakdown sheet, and the sheet now offers the trend from inside.

Routing the ring straight to the trend is the obvious way to make three identical-looking rings behave alike, and it is wrong. That sheet's only other entry is the Synthesis card, and SYNTHESIS is a TodaySection the user can hide, so anyone who has hidden it would lose the breakdown entirely. A "See the Charge trend" row beside the existing "How Charge is calculated" resolves the inconsistency without losing anything.

So on both platforms every hero ring now leads to that score's own detail. Charge's is simply the richer one on Android, with the trend one tap further in.

Android suite: 670 classes, 5,659 tests, 0 failures. i18n_audit.py --ci --platform android reports no new gaps.

Two new Android strings, added across all seven locales with keys generated by the repository's own algorithm, which I verified rather than assumed: sha1("How Charge is calculated")[:8] really is 142d5e8e. Each locale uses its own established term for Charge (Ladung, Carga, charge, Energia, Carga, Заряд, 充能). Android says "Ladung" in German where iOS says "Energie"; that divergence pre-dates this and is left alone rather than quietly changed.

Accessibility and localisation

The ring's spoken label carries the score, not just the metric name. The ring is the element showing the number, so a VoiceOver user hearing only "Charge" on it, while the label beneath reads the value, would have it backwards.

That needs one new hint string. I claimed in an earlier draft of this description that there were no new strings, which was wrong: "Opens the trend and readings" is new. It is appended to the catalogue with all nine non-English locales, text-spliced rather than round-tripped, so the diff is 11 lines rather than a reformat of a 6 MB file. i18n_audit.py --ci reports no new gaps.

Swift rests on CI as always.