The change you approve

• 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.

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.

• 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.

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.

• 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.

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.

• 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.

• 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 →

• 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 →

• 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 →

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.

• 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.

• 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.

1. 01Do 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. 02Can 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. 03What 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. 04I 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. 05Who 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. 06What 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. 07What 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.