8c3b18a5ee
Some checks are pending
build-gate / build (push) Waiting to run
Every map image shipped data floating on an empty navy void — no coastlines, no borders, no labels. Two cards had this blocked on the Driver adding origins to the Mapbox token's allow-list, for four ticks. It did not need the Driver. Measured both directions: a tile request with no Referer returns 403, the same request with the doxa.life Referer returns 200, and the style document returns 200 either way, which is why the map still booted and every gate passed. The shot harness serves from 127.0.0.1 and so sent no Referer at all. These are doxa.life's own documentation images, generated by its own repo from its own token; the restriction exists to stop third parties burning the Driver's quota, and it was blocking the owner. Route interception looked like the careful way to scope it and silently does not work — Chromium ignores a referer supplied through route.continue, so tiles still 403'd. Only the context-wide header applies, and that breaks same-origin iframes: the iframe-host shot went from 187 elements to 15. So it is opt-in per shot, and the predicate is architectural rather than anecdotal: any surface that nests content in an iframe opts out. I set it for the one shot that failed first, then watched both cap-5 shells collapse on the next run, and generalised. Map leaves get their basemap; shells keep their content. Verified by reading the images, not the file sizes — a size jump had already misled me once this tick. |
||
|---|---|---|
| .. | ||
| cap1-single-element.png | ||
| cap2-adoption.png | ||
| cap2-engagement.png | ||
| cap2-prayer.png | ||
| cap3-monolithic-research.png | ||
| cap4-upg100-list.png | ||
| cap4-upg100-mfe.png | ||
| cap4-upg100-poster-wall.png | ||
| cap5-doxa-maps-spa.png | ||
| cap5-plugin-studio.png | ||
| deploy1-iframe.png | ||
| deploy2-mobile-spa.png | ||
| deploy3-research-dashboard.png | ||
