# The change you approve

> Learn how to review a CodeHerder pull request without reading code. See the three answers you can give and what to do if an approved change goes wrong.

Source: https://customhosted.com/review/

№ 01 Review

"A human reviews and merges" is one sentence on the patching page. This page is the rest of it — what a pull request actually is, and what your approval actually does.

№ 02 The word itself

## What a pull request is

A branch, a diff, and a set of checks — nothing more mysterious than that.

- A branch — The agent writes the change on its own copy of the code. Nothing on it touches the live site until it merges.
- A diff — Every line added or removed, shown next to the current code, file by file.
- A set of checks — The same automated checks that gate every other change here run against this one too, before a person looks.

№ 03 Brief to screen

## From brief to your screen

The same 6 steps described in full on [Environments](https://customhosted.com/environments), ending exactly where this page picks up.

1. 1 — Brief the change You — Describe it in plain language, the same way as any other change under the Agentic iteration — CodeHerder add-on.
2. 2 — Agent opens the pull request CodeHerder — Reads the live codebase and makes the change on its own branch — a real diff, not a description of one.
3. 3 — CI builds it CustomHosted — The same build and checks that gate every other change on this platform run against this one too.
4. 4 — It stands on staging CustomHosted — The branch deploys to the standing staging environment automatically — a real URL, not a diff on a screen.
5. 5 — You click the real thing You — No diff-reading required — load the page, use the feature, decide if it's right.
6. 6 — Merge ships production You — Approving the pull request merges it, and the same pipeline that just built staging redeploys production.

№ 04 What arrives

## What you actually see

Four things, every time — not a raw code dump with no way in.

- A title and a plain-language summary — What changed, described in the same words as the brief that asked for it.
- A diff — The exact lines changed, file by file — the real change, not a description of one.
- A status check — Pass or fail from the pipeline, run before a person ever opens the page — see the worked checks below.
- A link to the live change — The branch already stands on staging as a real URL, not just a diff. See the path below for how it gets there.

№ 05 The anxiety question

## How to review it without reading code

You do not need to read a diff. You need to use the page.

1. 1 — Open the staging link — The pull request carries a working URL. Skip the diff and load the page instead.
2. 2 — Do the thing you asked for — Click the button, fill in the form, read the new copy. Confirm it does what the brief asked.
3. 3 — Check the status — Confirm the automated checks passed. A failed check means something is wrong before you even open the page.
4. 4 — Try to break it — Use the feature the way a real visitor might, not only the one path the brief described.
5. 5 — Decide — Approve it, ask for a change, or close it — see the three answers below.

№ 06 Three answers

## The three answers

Every review ends in one of these, and only these.

- Approve — The change is correct. Merging it sends the same pipeline that built staging to production.
- Ask for a change — Say what is wrong, in plain language. The agent reads the note and updates the same pull request.
- Close it — The change is not needed after all. Closing it drops the branch — nothing merges, and nothing ships.

№ 07 Who decides

## Who may approve

Narrowed from the full matrix on [Access](https://customhosted.com/access) to the two rows this page is about.

| Capability | Your team | CustomHosted | The pipeline | CodeHerder agent |
| --- | --- | --- | --- | --- |
| Open a pull request | Any of your own contributors can. | The same as any other contributor, reviewed the same way. | It ships a merge. It does not propose one. | Only ever on its own branch, never on the branch that ships. |
| Merge to the main branch | This is your call to make. | Only if you have asked us to review and merge for you. Most teams keep this step themselves. | It deploys after a merge. It does not decide to merge. | Never. A person approves the pull request first. |

What the agent cannot do: It cannot merge, deploy on its own, read a secret’s value, or open a shell. A person approves the pull request, and the same pipeline you already run ships it.

№ 08 The other anxiety question

## I approved it, and it was wrong

An approval is a judgement call, not a guarantee. Here is the way back — see [Deploys](https://customhosted.com/deploys) for what happens to a change once it merges.

- Revert the merge — The same pipeline that shipped the change redeploys the last known-good version. No data touched, because none was.
- Promote the previous deploy — On static hosting, the last deploy is already built and kept. Going back is a request through the usual channel, a straight promotion of it rather than a rebuild.
- A data problem is a restore, not a rollback — If the thing that's wrong is data rather than code, that's the other procedure entirely — see Recovery for the backup and point-in-time paths, and where that boundary actually sits.

№ 09 Worked artifact

## This site's own reviews

Three real pull requests against this repository, and what review caught on each.

- CF-01 — The site is blinding at night — What review changed — Review sent this branch back twice before it merged: two tokens behind the homepage's technical figure had no dark value at all, so its dashed construction lines, dimension rails, and vent strokes all composited to near-invisible on the new background — the figure lost its draughtsmanship and left two captions floating with no rail attached. And the DAY/NIGHT rocker itself picked up a display style that silently defeated its own [hidden] guard, so a JS-off visitor would have seen a control that looked live and did nothing. Both were fixed on the same branch. — [See it flip on the homepage →](https://customhosted.com/)
- CF-02 — Make sure someone on a screen reader can actually use this — What review changed — Review's own read of the first pass is what surfaced the hover blind spot: a primary call-to-action's hover state was failing contrast and no automated run had ever caught it, because the crawl never triggers :hover. The fix is the guard, not just the one button. The follow-up branch then caught a heading-order regression the original fix had introduced on /selector — the loop catching its own mistake, not just the site's. — [Read the accessibility page →](https://customhosted.com/accessibility)
- CF-03 — Answer engines should be able to read the whole site — What the audit caught — An automated audit of the site is what surfaced this, not a human reading the diff: the machine-readable index was the one failing check on an otherwise clean homepage, because it listed its URLs as plain text rather than links — so a link-following crawler saw no index at all — and it had already drifted behind the pages that existed. Patching that file would have left it a hand-maintained second copy of the site's structure, so the change deleted the copy instead: the human directory and the machine index are now both rendered from one manifest, and the build fails loudly rather than letting the two drift apart again. — [Browse the directory →](https://customhosted.com/directory)

Before a person ever looks, 17 checks already ran against every one of these:

- check:anchors — Every hub page's "On this page" index still matches its own numbered bands, in order.
- check:a11y — Every route is crawled for accessibility faults, at two sizes, in both themes.
- check:ledger — The public build-history page still matches what this repository's own history says.
- check:llms — The machine-readable site directory lists every route exactly once, and every link actually resolves.
- check:perf — Every route stays inside its own published page-weight budget.
- check:security-txt — The security-contact file is present, and not expired.
- check:supply-chain — The dependency-safety rules — locked versions, no install scripts, a release cooldown — are still in place.
- check:seo — Every route carries one canonical URL, one title, one description, and valid structured data — and nothing meant to stay out of the index does.
- check:forms — The form page's own field caps, its POST-only check, its honeypot field, and its log retention still match the real contact-form terraform.
- check:images — Every image stays under its published weight ceiling, and every picture carries alt text, its dimensions, and a loading value.
- check:limits — Every module that publishes a limits array is collected on /limits, and its published count matches what the page actually renders.
- check:logins — No password input exists anywhere on the site, every form carries a known id with no off-site action, and /logins' own worked artifact still renders.
- check:compliance — No affirmative compliance or certification claim appears anywhere on the site, and /your-data's residency and deletion bands still render.
- check:spacing — No run-together word slipped past a stripped space next to a link or other inline element, on any route.
- check:reveal — Every section that fades in on scroll actually appears, on a phone-sized screen as well as a desktop one.
- check:twins — Every route's Markdown twin exists, starts with the page's real heading, carries no stray HTML, and is linked from the page exactly once.
- check:quotes — No published quote bills an add-on its plan already includes, and the estimator prices only through the same code as the quote form.

№ 10 What it costs

## What it costs

A review is not a metered action — the loop it sits inside of is.

- Opening and checking a pull request has no separate charge — Agentic iteration — CodeHerder ($25/mo) covers the whole loop, brief to merge. There is no extra fee per review.
- Your own time is the real cost — The hours ledger prices a full brief-to-merge pass at about 2 hours. That assumes a small copy or config change, briefed and reviewed start to finish.

№ 11 Said plainly

## The honest limits

Nothing merges itself — and three more, said plainly rather than buried.

- Nothing merges itself — There is no setting that lets an agent merge its own pull request. A person approves every change, including when you would prefer that it did not.
- A passing check is not the same as a correct change — The pipeline confirms the code builds and behaves as tested. It cannot confirm the change is what you actually wanted — that read is still yours.
- No one reviews it for you — An agent can act on your feedback and update its own pull request. It cannot stand in for your approval of it.
- A closed pull request leaves nothing behind — Closing one drops the branch entirely. If the need behind it is still real, it starts over as a fresh brief.

№ 12 Answers

## Review questions

What people ask once "a human reviews and merges" stops being a good enough answer.

1. 01 Do I have to read code to review a change? No. Open the staging link the pull request carries and use the feature directly — see "How to review it without reading code" above.
2. 02 Can the agent merge its own pull request? Never. It cannot merge, deploy on its own, read a secret’s value, or open a shell. A person approves the pull request, and the same pipeline you already run ships it.
3. 03 What if I don't like the change once I see it? Ask for a change, in plain language. The agent reads your note and updates the same pull request — see "The three answers" above.
4. 04 I approved it, and the app is still wrong. Now what? See "I approved it and it was wrong" above for the ways back, and Deploys for what happens to a change once it merges.
5. 05 Who besides me can approve a change? By default, only your own team. We can review and merge on your behalf if you ask us to — see "Who may approve" above for the full matrix.
6. 06 What runs before I even see the pull request? 17 automated checks, the same ones that gate every other change here — see the worked artifact above for the full list.
7. 07 What does reviewing a change cost? Nothing extra by itself — see "What it costs" above for how the Agentic iteration — CodeHerder add-on and your own time both factor in.

№ 13 Keep reading

## What review connects to

- [Brief a change Where a pull request starts — the five parts of a good brief, before an agent ever opens a branch.](https://customhosted.com/brief)
- [Repository The repository a pull request branches off of — who owns it, and what makes it easy for an agent to iterate in.](https://customhosted.com/repository)
- [The Loop The commercial arc this page's phase 03 is one step of — brief, build, review, run.](https://customhosted.com/loop)
- [Environments The staging environment a pull request stands on before you ever click approve.](https://customhosted.com/environments)
- [Access The full capability matrix this page's "Who may approve" section narrows to two rows.](https://customhosted.com/access)
- [Deploys Everything that happens after the merge this page stops at.](https://customhosted.com/deploys)
- [Checks What actually runs before a person ever sees the pull request — the worked list behind "What runs before I even see the pull request?" above.](https://customhosted.com/checks)
- [Patching The "a human reviews and merges" step this whole page expands.](https://customhosted.com/patching)
- [Case files The three real dossiers behind the worked artifact above, followed end to end.](https://customhosted.com/case-files)
- [In flight What happens around a review — why only one change is in the air at a time, and what sets the order it ships in.](https://customhosted.com/in-flight)

## Want to see what a pull request looks like on your own stack?

Brief it through the same quote channel as any other request — see Brief a change for the five parts a good one needs.

[Get a quote →](https://customhosted.com/contact)