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.

Done this session

Remaining (pending)

Carry legacy orange in post_content: 230 published pages, 135 published posts, 1 brb_collection, 1 kadence_element, 2 wpcode (+ 95 drafts, lower priority).

Sam's directive (2026-06-09)

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.

Plan for the 365 page/post batch (registry-driven, triggers a sec-31 retroactive audit)

  1. Per page: detect legacy-orange elements -> map to registry element (catalog saved) -> replace block in full with Foundry canonical -> preserve verified data.
  2. Deploy via REST draft pipeline (no direct DB post_content writes), QA each, WP revision rollback.
  3. Batches of 25, 10% Playwright/DOM QA sample per batch, stop on FAIL, Cloudflare purge per batch.
  4. Good candidate for a scheduled/off-hours task to avoid colliding with other agents' jobs.

Artifacts (in Projects/_reports/ped-fix-2026-06-08/)

Why paused here

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).