While fixing the pedestrian page, Sam asked to recolor the legacy orange. Investigation showed the legacy orange #F89C22 is NOT a single shared block (the verdicts block 68294 was already Foundry) but is embedded in ~483 items sitewide.
#D97706 via REST /wp/v2/blocks/{id} (each auto-revisioned = rollback). Verified 0 #F89C22 left in every block. Cloudflare purge_everything run. Backups in outputs/ped-fix/block-backups/.
Carry legacy orange in post_content: 230 published pages, 135 published posts, 1 brb_collection, 1 kadence_element, 2 wpcode (+ 95 drafts, lower priority).
Start from the SA Element Registry (https://sa-element-registry.onrender.com/, 77 elements catalogued). Treat legacy orange as a marker of a stale asset: replace the element in full with its current canonical registry version (don't just swap the hex), preserving verified firm data (results, reviews, regional phone in tel: href). Then run page batches.
Projects/_reports/ped-fix-2026-06-08/)MIGRATION-RUNBOOK-legacy-orange-to-foundry-2026-06-09.mdlegacy-orange-inventory-2026-06-09.csv (all IDs + type + status)registry-catalog-2026-06-09.json (77 elements id->name)block-backups/ (pre-change content for all 23 blocks)Session context is high. Block migration (the proof batch) is complete and verified. The 365-page registry-driven full-element replacement is a large, high-blast-radius batch best run as a fresh focused/scheduled effort. Awaiting Sam's pick on run-now-batched vs scheduled vs dry-run-first (asked inline).