G D.12 — per-fact verified_at via repo variables

[larsweiser]

Summary

Follow-up to PR #14 (G D.10 + G D.11). The post-merge state had a real semantic issue: the per-fact bbl-verified-at-dpf and bbl-verified-at-cwa markers stayed at 2026-04-29 even after both checks re-verified clean today, because they read JSON's per-fact verified_at and JSON only gets written on value-change runs (per the G D.11.1 design). The field name "verified_at" implies "when last verified" — JSON-direct sourcing didn't match.

G D.12 extends the env-var → repo-variable pattern to the per-fact markers, mirroring the top-level mechanism.

What changed

• Two new repo variables (created manually with seed 2026-04-29T00:00:00Z): VERIFIER_DPF_VERIFIED_AT, VERIFIER_CWA_VERIFIED_AT. Updated independently of VERIFIER_LAST_OK_AT by the verifier whenever the corresponding fact returns ok — so on mixed-status runs the clean-fact's marker still refreshes.
• Orchestrator (scripts/run-verifier.mjs): emits two new GITHUB_OUTPUT flags dpf_ok / cwa_retention_ok; dry-run preview expanded to log the per-fact variable-update paths.
• Verifier workflow: two new variable-update steps gated independently on the new flags (using the same VERIFIER_VARIABLE_TOKEN fine-grained PAT); mock-dispatch dry-run branch pins the new flags to false.
• All four build workflows (deploy-staging, deploy-production, rebuild-nightly, rebuild-nightly-staging): pass VERIFIED_AT_DPF + VERIFIED_AT_CWA env vars to npm run build.
• Helper (src/lib/cloudflare-facts.ts): getEffectiveVerifiedDate generalised with a source: 'top' | 'dpf' | 'cwa' parameter. JSON fallback per source. File-level JSDoc rewritten — the G D.11 note saying "per-fact markers deliberately read JSON, NOT this helper" is reversed.
• Privacy pages (DE + EN): per-fact markers now route through the helper with the right source arg. Frontmatter comment about the post-deploy smoke step removed (that step was deleted by G D.11.1).

Test plan / staging evidence

• npm run build clean; astro check 0 errors / 0 warnings.
• Local build smoke matrix:
  • All three env vars set to 2026-05-12T... → all three markers show 2026-05-12 on both DE and EN.
  • Unset → falls back to JSON.
  • Malformed → falls back to JSON (Date.parse guard).
• Verifier dry-run matrix (per-fact independence):
  • cwa-active → dpf_ok=true, cwa_retention_ok=true → would update all 3 vars.
  • cwa-changed-figure → dpf_ok=true, cwa_retention_ok=false → would update DPF var + open PR.
  • dpf-absent → dpf_ok=false, cwa_retention_ok=true → would update CWA var + open PR.
  • cwa-parser-broken → dpf_ok=true, cwa_retention_ok=false → would update DPF var + open Issue.
• Live verifier dispatch against dev (run 25728379992): all three variable-update steps succeeded; all three variables now at 2026-05-12T10:22:24Z; channel steps correctly skipped.
• Staging redeploy + curl dev.blackbrowedlabs.com/datenschutz + /en/privacy: all three markers (top + dpf + cwa) show 2026-05-12 on both locales.

Notable design

• Per-fact independence: each variable advances on its own _ok flag, so a mixed-status run (e.g., DPF ok + CWA parser-broken) still refreshes the DPF marker — the user-facing date no longer says "we didn't verify this fact today" when in fact we did.
• Vite-friendly env access: import.meta.env.X only gets build-time-replaced when X is a literal property — the helper branches explicitly on source rather than computing the env key.
• Same PAT, no new secrets: the existing VERIFIER_VARIABLE_TOKEN (Variables: read/write) covers all three update steps.

Refs

• Surfaced by Lars's review of the post-PR-G D.10 + G D.11 — Verifier hardening (source fixes + alert-model + display refresh) #14 prod state, where per-fact markers showed 2026-04-29 despite a clean verifier run that day.
• Commit: bb0ec64.

🤖 Generated with Claude Code