# Private health-dashboard UI polish and bounded release

Use for a frontend-only redesign of an existing private health dashboard where database schemas, APIs, medical semantics, local chart/calendar runtimes, and write paths must remain frozen.

## Scope discipline

- Freeze and verify the requested base commit before editing.
- Reuse existing read APIs, ECharts, FullCalendar, review queues, capture queues, and routing contracts.
- Do not add tables, migrations, medical scores, recommendation logic, data sources, public exposure, or direct browser-to-health-DB writes.
- Keep missing values as unknown; never manufacture zero, a reference band, an alert color, a deficiency claim, or a treatment/supplement recommendation.
- Display a reference context only when source, unit, and observation scope are trustworthy.

## UX implementation pattern

1. **Nutrition day:** lead with date/completeness/source status, then energy/macros, then micronutrients, then meal chronology. Keep provenance/conversion details collapsed. For period means, show the period, documented-day count, expected-day count, and coverage. A macro pie may use documented grams converted to energy shares (4/4/9 kcal), but omit missing macros rather than treating them as zero and label it as documented macro energy.
2. **Food mapping:** use one queue plus one selected detail. Separate product identity, ingredients/components, SIGHi mapping, personal observation, and collapsed technical provenance. Keep one obvious action and never auto-approve a medical mapping.
3. **Record:** provide direct links to labs, medication, appointments, documents, and open review work. For a lab delta, compare only numeric observations with the same unit and describe it neutrally. Translate technical source/status codes before main-view display.
4. **Documents:** keep list/detail state, safe preview/original gates, local text search, next/previous hit controls, original/text comparison, and the existing decision workflow. Explain *which* decision is missing (for example, original/text reconciliation) instead of a vague “not reviewed.” Never render internal IDs, filenames, or paths.
5. **Calendar:** keep local FullCalendar. Use explicit category toggle buttons with `aria-pressed`; category color distinguishes type only. Desktop defaults to month; narrow mobile may default to `listMonth`. Day clicks use the central day router; drag or explicit from/to hands the range to the Explorer.
6. **Mobile capture:** expose symptom, medication, event, photo, and document entry through existing write contracts. If a fixed launcher lives inside a transformed/sticky header, it may become fixed relative to that ancestor. Verify computed position and hit-testing; on narrow viewports, move the launcher to `document.body` or otherwise escape the containing block, then keep it above—not overlapping—the fixed navigation.

## Mobile/cascade diagnostics

At the exact target viewport, inspect:

- `document.documentElement.scrollWidth - clientWidth`
- `getBoundingClientRect()` for navigation, capture launcher, dialogs, and viewers
- `getComputedStyle(...).position/top/bottom/zIndex`
- `document.elementFromPoint()` at the center of the intended touch target
- `matchMedia()` for the active breakpoint

A later desktop rule such as `top: 8px` can override an earlier mobile `inset` and stretch a fixed navigation over the whole viewport. In the final mobile media block, explicitly reassert `position`, `top: auto`, `bottom`, and bounded height. Measure visible controls for a minimum 44 px target.

## Bounded acceptance

When the user caps browser scenarios, create exactly that many scenario definitions; do not expand into the historical matrix. A corrected scenario can be rerun selectively and counted cumulatively once its final form passes. Keep automatic and manual evidence distinct.

Suggested six-scenario shape:

1. nutrition day and meal groups;
2. nutrient means/missingness/reduced motion;
3. food mapping master-detail;
4. record plus document list/detail;
5. calendar month/agenda/filter/day routing;
6. exact mobile viewport, capture menu, dialogs, overflow, and reduced motion.

Also run changed-file syntax checks, `git diff --check`, and a compact added-lines scan for SQL writes, new routes, external URLs, competing chart libraries, and prohibited medical claims.

## Private deployment and read-only smoke

- Stage the exact runtime files, create exactly the authorized commit, push, then atomically install runtime files and atomically replace the generated private HTML.
- Restart only the authorized private user service; verify active state and runtime-file hashes against the committed sources.
- Smoke nutrition, documents, calendar month/agenda, desktop/mobile, capture-menu opening, local ECharts/FullCalendar presence, console errors, request errors, and external requests.
- Use a bounded API date range accepted by the existing contract and choose a documented nutrition day from that response. An over-wide diagnostic request can produce an avoidable 422 and contaminate the smoke.
- Count HTTP 4xx/5xx and genuine `requestfailed` events. Ignore only deliberate `net::ERR_ABORTED` requests caused by immediate test navigation; do not hide actual network failures.
- Keep the smoke read-only: open menus/dialogs but do not submit. Open the production database via SQLite read-only URI for `integrity_check`.
- Recheck the frozen legacy artifact checksum, service status, remote/local commit equality, and clean worktree; remove synthetic fixtures and temporary credential/proxy/smoke helpers.

## Reporting

Return a compact release note with commit SHA, focused tests, private deployment/service state, smoke coverage for the requested areas, desktop/mobile result, console/request/external-request counts, frozen legacy checksum, and only the genuinely remaining release-candidate work (usually manual visual approval plus bounded cross-area RC regression).