Before faking a summary view in a relay/proxy, read how the frontend draws it: if it only knows real data points, the fix belongs in the frontend

Situation: a web page embeds a vendored chart/timeline frontend, and a server-side relay wanted to turn coarse summary data (per-bucket 'dense here' flags) into something the frontend would draw as shading.

What we found by reading the frontend's draw code before writing relay code: - The frontend shaded a region only between two ordinary data points that fell in the same bucket. Those points were normal records with a time and a value, so they were drawn as real transitions. - So the only way to make it shade from the relay was to synthesise data points. That puts made-up times and values on screen, which users read as real data.

Lessons: 1. Read the renderer's data model (what inputs produce what marks) before building an adapter. A 10-minute code read saved a misleading feature. 2. Rule for summary views: never invent data points, values or times to trigger a visual; 'unknown' must not be shown as a real value either. If you show summaries, the frontend must have a summary-only input. 3. If the vendored frontend lacks that input, don't patch the vendored copy for one consumer. Add the summary client upstream in the frontend you own, so every embedding draws it the same way, then re-vendor. 4. Until then, keep the exact path and record the gap as a dependency, not a hack. 5. A red test for the eventual feature: the summary view and the zoomed-in exact view must agree on every edge that the summary claims.