projectedDate ignores the safety-floor clamp, so the nominal Pace isn't always achievable

Goal/Context

projectedDate() in shared/src/calc.ts is fromDate + ceil(remaining ÷ Pace × 7) days — a constant weekly rate. Energy expenditure scales with body mass, so a fixed calorie deficit shrinks as weight drops and loss decelerates. Constant-rate projection is the known "static model" error.

Hall KD, Sacks G, Chandramohan D, et al. Quantification of the effect of energy imbalance on bodyweight. Lancet 2011;378(9793):826–37. doi:10.1016/S0140-6736(11)60812-X — "Rather than the progressive weight loss predicted by the static model, the same intake reduction produces a modest weight-loss plateau", with half-times of about 1 year.

Public implementation: NIH Body Weight Planner (NIDDK).

Effect: our projected dates are optimistic, and increasingly so the larger the goal. KCAL_PER_KG = 7700 carries the same assumption.

Scope

• Replace the constant-rate projection with an exponential-approach form, e.g. W(t) = W0 - r·τ·(1 - exp(-t/τ)) with τ ≈ 75 weeks (half-time ≈ 1 yr → τ = 52/ln2), t in weeks. Initial slope is exactly r, so it still joins the last logged point
• r is the Goal's Pace (a user-chosen preset), so no inversion is needed — Pace is the input and the date is the output
• Update the derived-on-read date in goals.service.ts and the goal block in dashboard.service.ts
• Update buildPlanOptions so onboarding plan cards show the same dates the dashboard will
• calc.spec.ts asserts exact dates ('2026-01-15', '2026-05-21'); those expectations move

Done when

A 5 kg goal at 0.5 kg/week projects a later, decelerating date than remaining ÷ pace, and the dashboard tile, the chart endpoint, and the onboarding plan cards all agree on it.

Dependencies

Blocks nothing. #68 renders the projection as a straight line, which is correct for what the current model computes — this ticket is what would make a curve honest.

Guidance

This is a shared/ contract change (ADR-0001 puts calorie math there on purpose), so it fans out to backend read paths, onboarding, and the shared tests. Not a chart-layer change — bending the chart alone would make it disagree with the Projected goal date tile above it.

Unassigned: it is calc + backend read paths, not frontend surface.

Risks / delays / second-order effects

Changes every projected date shown in the product, including ones already on screen in a demo. Worth sequencing deliberately relative to the 6 Aug deadline. A separate, smaller option is to keep the model and soften the copy instead.

Read shared/src/calc.ts and calc.spec.ts first, then trace the derived date in goals.service.ts, dashboard.service.ts, and buildPlanOptions. Run the shared tests before changing the projection; done means the five-kilogram example decelerates and the dashboard tile, chart endpoint, and onboarding cards agree.