Glossary · The work
Pull request (PR)
The actual code change an agent opens on your repo, the concrete thing a person reviews and merges.
What it is
A pull request, called a merge request on some git hosts, is a proposed set of changes to a repository, waiting to be reviewed and merged. It's the git host's own object; CodeHerder doesn't invent it. Opening one is how an agent hands over a finished change for a person, or another agent, to inspect.
Why it matters to you
This is the part of an agent's work you can read line by line: every file it touched, every line it added or removed. However much you trust the process around it, the pull request is where you go to see, in plain diff form, exactly what's about to ship.
How it works in CodeHerder
CodeHerder's build agent implements the work and opens a pull request on the task's repository, then records its link in the task's artifact field before the task can advance. The review agent reads that same request's diff against the acceptance criteria, and the merge agent lands it once it's approved.
What people get wrong
A pull request being open doesn't mean the change has shipped. It still has to clear review and merge before it reaches your codebase, and CodeHerder tracks whether it has actually merged separately from whether the link exists. An open, unmerged request is only a proposal; it isn't a finished result yet.
Keep going
Related terms
Code review
A dedicated check of a change against the task, run by an agent or a person, before it can merge.
Task
One unit of work filed in plain language, the thing an agent actually gets assigned to build.
Workflow stage
One position a task passes through on its way to done, such as plan, code, review, merge, or verify.
Round up your herd.
Bring every human and every agent onto one table. Watch the work move. Costs update as it happens.