Semana de 15/06 a 21/06. Daqui pra frente o changelog é semanal (arquivos YYYY-MM-DD-weekly.md, datados no último dia coberto). A fonte de verdade do front-web-base é a branch main-7k — a main está defasada e não reflete o que foi pra produção.
Semana 15–21/06 — cache overhaul: CACHE_GENERATION como token único de rotação
front-ops/config/cache/generation.yml vira a fonte operacional de verdade (ops f00c642): o arquivo carrega current: apcsrasj-v3, é lido no deploy e injetado como --var CACHE_GENERATION no wrangler deploy. Bumpar pelo workflow novo bump-cache-generation flipa de uma vez a namespace do Cache API do platform-cache, o cacheKeyPrefix do api-client e o GLOBAL_VERSION do front-service-api; sem o arquivo, o deploy cai no default in-source (fail-open). É separado do BUILD_ID, que já rotaciona a cada deploy — o CACHE_GENERATION é o "nuke from orbit" que o padrão legado de pasta-nova-por-deploy fornecia. cache-status.yml complementa como leitura read-only.- Base conectado à máquina nova (
b445a6b5a): binding declarado no worker-configuration.d.ts; app/services/platform-cache.server.ts mantém um storesByGeneration chaveado pelo token, então o cache de isolate rotaciona atomicamente; app/services/api.server.ts deriva cacheKeyPrefix como api-cache-<gen> e liga delegateCaching: true nas rotas já cacheadas na camada platform-cache, eliminando o drift de TTL duplo que causou o postmortem de /payment-providers em 05/2026. app/routes/api/cache/purge.ts passa a delegar ao createPurgeHandler do core (mesmo contrato de tag/glob/scope/dry_run, com extractApiError no lugar de [object Object]) e nasce app/routes/api/cache/inspect.ts, endpoint GET que lista recursos, tags e namespace corrente e, com ?include=state, sonda o Cache API.
- TTLs apertados e falhas de fallback visíveis (
239651ff4): KV_SSR_TTL cai de 12h pra 1h (o valor antigo era resquício da premissa "rebuild a cada 12h"), entra MAX_API_CACHE_TTL = 3600 com clamp em getApiCacheRule, e erros de fallback de asset em KV e R2 passam a ser logados — antes eram engolidos em silêncio, deixando problema de permissão ou bucket invisível no Logpush. public/_headers reduz /icons/* de 1 ano pra 30 dias.
- Defaults e purge seletivo no
front-ops (b36e445): brandConfig sai de 3600s e homeRows de 7200s, ambos pra 60s + SWR 300s, então mudança de backoffice reflete em menos de 60s; toda resource ganha tags pra o purge mirar fatias em vez de derrubar tudo; staleIfErrorSeconds capado em 6h. manual-cache-purge.yml sobe pra v3 com tags (CSV), glob, scope e dry_run. 8645ac2 cria config/cache/service-api-defaults.yml com 19 regras consumidas no deploy do service-api — base e service-api passam a compartilhar a mesma taxonomia de tags.
skip_post_deploy_purge por environment (ops 2d83a4c, aplicado em 0d4437e e 64f130f): workers atrás de Cloudflare Access devolvem 404 no purge pós-deploy porque o curl segue o redirect de login sem service token. Até os service tokens entrarem no workflow, o environment pode sair do purge por segmento — a rotação do CACHE_GENERATION já torna as entradas anteriores inalcançáveis — e um step de notice registra o skip no run summary.front-service-api com política externalizada (f80791d): DEFAULT_GLOBAL_VERSION = apcsrasj-v3, getGlobalVersion(env) lendo CACHE_GENERATION → BUILD_KEY → default, política vinda de env.SERVICE_API_CACHE_POLICY_JSON (era hardcoded) e /v2/cache/purge com o mesmo contrato do base. scripts/build-cache-policy.mjs resolve o YAML por --file, FRONT_OPS_PATH ou irmão ../front-ops. 27 testes novos, com 8d9fe4f documentando o fluxo no README.