Sitearc

The pull request workflow for an approved site change

One approved change, one pull request, one commit. A filled record from a real-shaped merge, and the checks after it.

Answers
Ship an approved change as one reviewable pull request.
Included record
A filled pull request record and the post-merge checks
Written for
Developers shipping site changes from a repository

One approved change, one pull request

The tool takes the complete new contents of each file, not a patch. That makes the diff readable in the repository’s own review surface.

A filled record

Ridgeline Roofing, 2026-09-12.

before the call
- repository linked with link_repo, default branch main
- GitHub App installed for the project, shown as connected
- proposal approved by Sam, recorded 2026-09-11

the call
title         Rewrite the service page titles
files         src/pages/services/roof-repair.astro
              src/pages/services/gutters.astro
              src/pages/services/flat-roofs.astro
recommendationId  rec_5f21

what came back
pull request  #412, url recorded
branch        sitearc/title-rewrite-service-pages
base sha      9c41f0a
commit sha    4d2b7e1
files changed 3, one commit

preview
resolved      yes, matched to pull request #412
audited       16:20, three pages read, canonical on production

merge
by            Sam, in the repository
commit        7a1c88e
merged at     2026-09-12 17:05

after the merge
- the merge commit was read, and the window opened
- window        2026-09-12 to 2026-10-09, 28 days
- baseline      146 clicks, 4,180 impressions, 28 days before
- verdict       recorded when the window closed

What the workflow does not do

  • It does not merge. A person merges in the repository.
  • It does not deploy. The host does that from the merge.
  • It does not decide whether the change was good.

Acceptance: the pull request is reviewable when

  • it contains one commit and only the files the change claimed
  • the branch is named after the recommendation or the slug
  • the body carries the evidence link
  • the preview was resolved and audited before the merge
  • the merge is performed by a person, and the commit is recorded
  • re-running the same request does not create a second pull request

Troubleshooting

Symptom Likely cause What to do
The call is refused No repository linked, or no GitHub App Link the repo, then connect the App
Two pull requests appear A retry after an unknown response Reconcile before retrying, and close the duplicate
The diff touches extra files The change included a formatting pass Split it into two changes
The preview is missing The host did not build the branch Check the project’s preview settings
Nothing is measurable after merge No baseline was taken Take one before the next change

Limits

Opening a pull request ships nothing. A merge is a person’s action.

A merged change is not a result until its window closes with enough data. The honest verdict may be inconclusive.

Where this came from