Confirm where the website actually lives
Begin by identifying the website, source repository or local project, hosting provider and target environment. A Web Spark Studio project has its own editing/release flow. A Git-linked customer website should be changed through its authorized repository and deployment link.
Connect only the necessary resources. The selected GitHub repository and Vercel team/project must describe the same website before Work prepares a release. A similar project name is not enough.
1. Inspect the current source
Read the current branch and exact source commit. Identify the page and the files that need to change. On Desktop Commander, inspect the chosen project folder and project instructions without reading credentials.
Give the approved copy, offer, imagery and constraints. Ask Work to preserve unrelated files and state anything it cannot verify. Public documentation can support implementation choices; it does not supply permission to modify the project.
2. Prepare a small reviewable change
Update only the service-page headline and introduction using the approved wording below. Use a new branch, show the exact diff and preserve all other content and configuration. Do not merge or publish.
Approve the intended source action separately. Check the commit or pull request after it is created. A conflict with a newer branch head requires reconciliation, not force-pushing over the change.
3. Build and preview
Run the appropriate approved test/build process, or prepare a preview deployment of the exact authorized commit. For a local process, read its completion output. For Vercel, follow the accepted deployment to its reported build state and preview URL.
Inspect desktop and mobile, images, route links and the customer’s intended next step. Do not submit real customer forms or trigger live messages casually as a test. A provider-ready build alone does not prove the browser workflow works.
4. Publish only the approved version
Request production explicitly after reviewing the preview. Check target project, source commit and any domain consequences in the proposal. Domain registrar changes are a separate handoff unless an explicitly supported connection handles them.
After release, inspect the intended public URL and the deployed identity where available. State the proof precisely: source committed, build passed, preview ready or public page verified.
If something goes wrong
Do not create another release while the previous outcome is unknown. Read saved status and provider state first. Preserve the operation, branch, commit and deployment references. A rollback or correction is its own action and may need the provider’s native controls.
A plan coordinates steps but never removes the approval boundary. Finishing a source edit does not authorize the next production deployment automatically.