Sam asked for the orange drift lane to prioritize finding the source and producing a prompt for all agents, rather than only treating the visible drift as a page-fix queue.
I deployed two read-only explorer agents:
The source is a policy split, not one bad page.
Current root governance and Skills/sail-design-foundation/SKILL.md permit approved solid Foundry orange #D97706 button/UI fills when contrast passes. Several older skills and routines still encode the pre-Foundry rule that orange is never a background or fill. Approved snippets already contain orange fills, so builder agents can generate approved Foundry UI and QA agents can then reject or revert it.
High-risk stale sources include:
Skills/wp-deploy/SKILL.md, broad no-orange-background and no-orange-button-background QA gates.Skills/website-rules-new/SKILL.md, hard fail on orange as any background/fill.Skills/sail-ui-kit/SKILL.md, text/border-only rule and old rgba(248,156,34,...) tint.Skills/pre-publish-qa/SKILL.md, broad no-orange-background wording outside the practice-area context.Skills/firm-reference/SKILL.md, never-background wording.Skills/sa-editorial-design/SKILL.md, internal contradiction between orange never being a section background and later approved Foundry CTA fill.Skills/sail-forms/SKILL.md, old RGB tint plus a form-specific submit-button ban that needs to be labeled as form-specific.routines-build/new_content_pipeline/pipeline_orchestrator.py, regex fails any background...#D97706, which can reject approved buttons or chips.The memory-side issue is evidence handling: local preview or stale Command Center data can be mistaken for current live drift. Future agents must verify live WordPress, canonical repo state, or current Notion pages before recommending design changes.
Created this reusable prompt artifact: