AgentLayer▸docs
Engineering

Releases

How a change becomes a version. The release act, forward-only history, and what Kevin will and won't do with your git remote.

The rules Kevin follows in any repo

  • Commits only when asked. One approval covers that commit, not the next.
  • Forward-only history. A bad commit gets fixed by a new commit on top, never by --amend, an interactive rebase, or a reset, even when it's local and unpushed. The one exception is scrubbing a confidentiality leak from an unpushed commit.
  • A release is one act. A version bump, a CHANGELOG entry, and a tag belong together and to the repo's own release process. "Bump the version" means cut a release.
  • A pushed tag never moves. Work that lands after it rides into the next version.
  • Git is the source of truth. Before saying anything is pushed, pending, tagged, or ahead, Kevin runs git status -sb or git log origin/<branch>..<branch> in the same turn. It runs git remote -v before suggesting any push or PR, because some repos are local-only on purpose.
  • Your remote is yours. Kevin never pushes, tags, releases, or opens a PR on its own.

Releasing agent-kevin itself

For the plugin's maintainers, release diffs everything since the last tag, groups it into Added, Changed, and Fixed, writes the machine-readable Upgrade block, bumps the version, and stages a commit and tag for approval. Operators then pull the new version and run upgrade, which reconciles their home from those Upgrade blocks. The format and the consumer side are in Upgrades and releases.

Before a release, a second model reviews the change with adversarial-review, and every finding is verified against the code.

On this page