Skip to main content

What the reviewer sees

Read it top down. A commit with a plan that names the files it changed and a high agent share is what it claims to be. A commit whose plan is empty, or whose changed files the plan never mentioned, or whose agent share is low, deserves the diff read with more care. A commit without a trailer was made by a person and is reviewed the ordinary way.

Setting it up

Add one workflow to the repository:
The action fetches refs/notes/gitvow/*, runs gitvow report over the pull request’s commits, posts the report as a single comment that it updates on every push, writes the same report to the job summary, and fails the check when a commit carries a session trailer but its note is missing, which means the author’s notes were never pushed. Inputs, all optional:

Decisions on the pull request

Each agent commit’s report lists the decisions it carries: what was accepted or declined, by whom, with what scope and reason, and any Gitvow-Open finding nobody decided. When a decision’s scope does not cover the branch the pull request targets and that branch is in decisions.production_branches, the report reopens it: “accepted for staging; this pull request targets main”. The check does not fail on it; the reviewer decides.

Squash merges

A squash merge writes one new commit whose message GitHub takes from the pull request title and description. The original commits’ trailers do not reach the target branch unless they are in that message. The action therefore writes a block into the pull request description on every push:
The block is updated on every push and can be edited around. A squash commit inherits the trailers; the session notes do not follow, so the comment stays as the evidence. Where the repository merges or rebases, the block is redundant and harmless, and pr-description: never turns it off. Where evidence should reach history, prefer merge commits or rebase merging. To produce the block by hand: gitvow report --base origin/main --decisions-summary.

Getting notes to the remote

Notes live on refs/notes/gitvow/<session-id> and git does not push them with a branch. gitvow install adds a pre-push hook that pushes those refs to the same remote every time you push, so nothing changes in your workflow. To push them by hand:

Running the report locally

Said versus did

The comparison is deliberately simple and transparent: it checks whether each changed file’s name appears in the agent’s last stated plan before the commit. It cannot judge whether the change is correct; it tells the reviewer where the agent’s stated intent and its actual edits diverge, and where no intent was stated at all. Anything smarter belongs in a separate reviewer, fed by this report.