Service process framing and Bailey scope cleanup

What was done

• Verified the live /dev-iq/our-process/ page before editing service copy.
• Added a shared scope note to ProcessCallout.astro clarifying Bailey’s construction-phase role as professional engineering support.
• Updated Phase 7 descriptions across service pages to distinguish Bailey observation/agency coordination from contractor-performed construction.
• Removed Phase 2 as a Bailey service mapping from the Land Planning service page.
• Removed Phase 10 as a Bailey service mapping from the Long-Term Planning service page.
• Updated the shared Phase 6 label to match the current process wording: Submittal & Approvals (SAs).
• Reframed value-engineering bid-process language so contractor selection and final contract pricing remain owner/developer decisions.

Why it mattered

The current public process makes three boundaries explicit:

• Phase 2, Land Control, is developer-side.
• Phase 7, Construction, is horizontal construction performed by contractors; Bailey provides observation reports, agency inspection coordination, and punch-list support.
• Phase 10, Vertical Development / Sale, begins after Bailey’s engagement.

Several service pages had useful but loose wording like “inspection,” “walks the site,” or “pay applications” that could blur those boundaries. The revised copy keeps Bailey’s continuity message while preserving the scope boundary.

Audit trail

• Detailed audit: .tmp/0009_26_05_27_website_steward/PROCESS_FRAMING_AUDIT.md
• Implementation folder: .tmp/0009_26_05_27_website_steward/

Verification

• Ran a targeted rg scan for high-risk construction-management phrases in active service and FAQ files.
• Remaining contractor-selection references are contained in the value-engineering FAQ and are framed as owner/developer bid-process decisions.
• Full build verification should be run after this copy pass with npm run build.