Why am I seeing this? ​

Every finding, gate reason and API error Bumpkit reports links to its entry here: what it means and what to do next.

Findings ​

A checker reads the diff and reports what it can point to on a line. Findings from the model are marked as inference and never block on their own.

Architecture drift ​

Reported as architecture_drift.

Why: The release changes how the code's modules depend on each other: a new import cycle, a dependency that breaks the layers in bumpkit.yml, more coupling, or a function past the complexity limit.

What to do: Remove the new dependency or move the code to the right layer. gate.quality.architecture_drift decides whether this needs approval or blocks.

Behavior change (model's reading) ​

Reported as behavior.

Why: The model read the diff and thinks behavior changed. This is inference, not proof.

What to do: Check whether it is true. It never blocks a release on its own.

Behavior change ​

Reported as behavior_change.

Why: The code proves a behavior change: a removed error check, a changed default, a flipped condition or a changed return value.

What to do: Check that the change is intended and that a test covers it. If it is, get it approved when the policy asks.

Affected area ​

Reported as blast_radius.

Why: A changed function is called, directly or through other functions, from a product area.

What to do: Test that area. If the policy guards it, someone must approve the change.

Breaking change ​

Reported as breaking.

Why: The release removes or changes something callers depend on, such as an exported function, a route or a column.

What to do: Keep the old name working, or ship it as a major version with a migration note. If it is intended, get it approved.

AI code quality ​

Reported as code_quality.

Why: The release's new code adds weight without adding behavior: copied code, an interface with one implementation, a function that only forwards, a symbol nothing uses, an oversized function or comment noise.

What to do: Reuse, inline or remove what the finding names. gate.quality.code_quality decides whether this needs approval or blocks.

Breaks a supported pair ​

Reported as compatibility_break.

Why: This release stays inside a provider range declared under compatibility in bumpkit.yml, and it has a proven break, so a pair the team supports no longer holds. It blocks only when gate.block_on lists compatibility_break.

What to do: Keep what was removed working, or narrow the supported range in bumpkit.yml in its own change, then push.

Supported pair not checked ​

Reported as compatibility_not_checked.

Why: Bumpkit couldn't prove this release keeps a supported pair working, for the reason in the finding. It never reads as compatible, and it never blocks.

What to do: Turn on what the finding names, or run the check from a version tag so the release has a previous version.

New configuration ​

Reported as config.

Why: The code reads a new environment variable.

What to do: Set it in every environment before you deploy, and document it.

Breaks a consuming repository ​

Reported as consumer_break.

Why: Another repository that uses this code calls something this release removes or changes.

What to do: Keep the old API working until the consumer is updated, or open a pull request in the consumer first.

API contract change ​

Reported as contract.

Why: An API contract changed in a way that existing clients can still use, such as a new optional field or endpoint.

What to do: Nothing to fix. Check that the changelog and the API reference describe it.

Breaking API contract change ​

Reported as contract_breaking.

Why: An OpenAPI, GraphQL, protobuf or JSON Schema contract changed in a way that breaks its clients, such as a removed field, endpoint or enum value.

What to do: Keep the old contract working, or ship it as a major version with a migration note. If it is intended, get it approved.

Cross-repo check unavailable ​

Reported as cross_repo_check_unavailable.

Why: Bumpkit couldn't read the repositories that consume this code, so it doesn't know whether they break.

What to do: Run the check again. Until it runs, a person must approve if the policy asks for cross-repo approval.

Reachable vulnerability ​

Reported as cve_reachable.

Why: A vulnerable dependency's affected function is called from your code. The finding shows the call path from the entry point to the vulnerable function, file and line per hop, read from the SCIP code index uploaded for this commit.

What to do: Upgrade to a fixed version, or remove the call on the path. Policies with cve_reachable in gate.block_on block high and critical ones.

When it blocks: Upgrade the dependency to a fixed version, or remove the call on the path, and push.

Vulnerability not reachable ​

Reported as cve_unreachable.

Why: A vulnerable dependency's affected functions aren't reached from any function in the SCIP code index for this commit. The finding says what was searched.

What to do: Upgrade when convenient. Upload a code index for each commit so this stays measured.

Data loss ​

Reported as data_loss.

Why: A migration deletes data: it drops a table or column, or deletes every row.

What to do: Copy the data first, or split the change: stop reading it in one release and drop it in a later one.

Dependency change ​

Reported as dependency.

Why: The release adds, upgrades or removes a dependency.

What to do: Check the changelog of the dependency for breaking changes, and that the lock file is committed.

Destructive endpoint ​

Reported as destructive_endpoint.

Why: The release adds an endpoint that deletes or destroys data: a DELETE route, or a POST route named delete, purge, destroy or drop.

What to do: Check that it requires the right permission, asks for confirmation and writes an audit record. Test that it can't delete more than intended.

New feature ​

Reported as feature.

Why: The release adds something new, such as a route, so it is at least a minor version.

What to do: Nothing to fix. Check that the changelog describes it.

Change in a hotspot ​

Reported as hotspot.

Why: The release changes a file that broke often or changed often in recent releases.

What to do: Review it closely and add tests for the changed lines. The finding names the commit that changed it.

Acceptance criterion without evidence ​

Reported as intent_unevidenced.

Why: A criterion from the pull request, a linked issue or a spec has no changed file, test or behavioral result that shows it was done.

What to do: Add the code or test that does it, or get the release approved if the criterion is out of scope.

Risky migration ​

Reported as migration.

Why: A schema migration can lock a table, fail on existing rows, or must run before this release.

What to do: Run it before deploying, add defaults or CONCURRENTLY where the finding says, and test it on a copy of production.

Missing backport ​

Reported as missing_backport.

Why: This branch lacks a fix from a release tag shipped in the last year, so shipping it would bring that bug back.

What to do: Cherry-pick the named fix onto this branch, or get the release approved without it.

Performance risk ​

Reported as performance.

Why: The release adds work on a request path: a query inside a loop, blocking network or file IO, more branches, or work sized by request input. Benchmark results that got slower land here too.

What to do: Batch the query, move the call off the request path, or cap the input. gate.quality.performance decides whether this needs approval or blocks.

Tagged release ​

Reported as release_tagged.

Why: The commit being checked already carries the tag for the version Bumpkit decided, so this check is of that release.

What to do: Nothing to fix. To release again, add commits and check the new head.

Sensitive area changed ​

Reported as risk_area.

Why: The release changes code in a sensitive area: authentication, authorization, billing or cryptography.

What to do: Have someone who owns that area review the change closely.

Scanner finding ​

Reported as scanner_finding.

Why: A code scanner you run, such as CodeQL, Semgrep, Snyk or Socket, reported a problem on a line this change touches or in code it reaches. Bumpkit shows it next to the areas the change reaches, highest reach first.

What to do: Fix it in the code and run the scanner again, or dismiss it in the scanner if it's a false positive.

Secret in the diff ​

Reported as secret.

Why: The diff adds a credential, such as an API key, a private key or an environment file.

What to do: Remove it, rotate it with the provider, and load it from the environment. It stays in git history until you rewrite it.

Secret in a test or sample ​

Reported as secret_sample.

Why: A test, fixture or example file contains something shaped like a real credential.

What to do: If it is a real credential, rotate it. If it is fake, make it obviously fake or mark the finding a false positive.

Security regression ​

Reported as security_regression.

Why: The change is less secure than the base: it removes or skips an authentication or authorization check, widens a role or permission, turns off TLS certificate verification or CSRF protection, opens CORS to any website, or uses weak cryptography. The finding names the line and, for a removal, where it was at the base.

What to do: Put the protection back, or move it somewhere that still covers the same code. If the change is intended, have the owner of that area review it.

Untested change ​

Reported as untested.

Why: A sizable amount of code changed and no test file changed with it.

What to do: Add or update tests for the changed code, or get the change approved.

Version mismatch ​

Reported as version_mismatch.

Why: The version Bumpkit decided disagrees with a tag, a manifest such as package.json, go.mod or Cargo.toml, a VERSION file or the CHANGELOG heading.

What to do: Update the file the finding names to the decided version, or tag the release with it.

Vulnerability check unavailable ​

Reported as vulnerability_check_unavailable.

Why: Bumpkit couldn't reach the vulnerability database, so new dependencies weren't checked.

What to do: Run the check again. If your policy blocks on vulnerabilities, a person must approve until it runs.

Vulnerable dependency ​

Reported as vulnerable_dependency.

Why: A new or upgraded dependency has a known vulnerability in the OSV database.

What to do: Upgrade to a fixed version, or remove the dependency. The finding names the advisory.

Interface with one implementation ​

Reported as code_quality from the abstraction checker.

Why: A new interface has only one type that implements it, so it adds indirection without a second use.

What to do: Use the concrete type until a second implementation exists.

Benchmark changed ​

Reported as performance from the benchmarks checker.

Why: go test -bench results differ between the base and the head. A slower result is statistically significant.

What to do: Profile the slower benchmark and fix the regression. Run each version at least 4 times, such as with -count 10, so the results can be compared.

Blocking call on a request path ​

Reported as performance from the blocking_io checker.

Why: Code reached from an HTTP handler now waits on a network, file or process call on every request.

What to do: Move the call off the request path, cache its result, or bound it with a timeout.

Comment noise ​

Reported as code_quality from the comment_noise checker.

Why: A large share of a file's new lines are comments, and comments that restate the code go stale.

What to do: Keep the comments that explain why, and remove the ones that repeat the code.

Function too complex ​

Reported as architecture_drift from the complexity checker.

Why: A changed function has more branches than gate.quality.max_complexity allows.

What to do: Split the function or return early to flatten its branches, and add tests for the paths it keeps.

More coupling ​

Reported as architecture_drift from the coupling checker.

Why: A module now depends on more modules than before, so changes elsewhere reach it more often.

What to do: Check that each new dependency belongs there. Drop the ones that don't.

New dependency cycle ​

Reported as architecture_drift from the cycles checker.

Why: Modules now depend on each other in a loop, so none of them can change or be tested alone.

What to do: Remove the dependency the finding names, or move the shared code into a module both can depend on.

Unused new code ​

Reported as code_quality from the dead_code checker.

Why: Nothing in the repository calls or references a new symbol, tests included.

What to do: Remove it, or wire it in where it was meant to be used.

Copied code ​

Reported as code_quality from the duplication checker.

Why: New lines repeat code already in the repository.

What to do: Reuse the existing code or extract what both copies share.

Removed or changed export ​

Reported as breaking from the exports checker.

Why: An exported function, type or constant was removed or its signature changed, so code that uses it stops compiling.

What to do: Keep the old export as a wrapper, or release a major version. If it is intended, get it approved.

Function too long ​

Reported as code_quality from the function_size checker.

Why: A new or changed function is longer than gate.quality.max_function_lines allows.

What to do: Split it into smaller functions that each do one thing.

More work on a request path ​

Reported as performance from the hot_path_complexity checker.

Why: A function reached from an HTTP handler has more branches than before, so every request does more work.

What to do: Simplify the function or move the extra work off the request path, and test the new paths.

Dependency breaks a layer ​

Reported as architecture_drift from the layers checker.

Why: A module now depends on one it shouldn't: against architecture.layers or architecture.forbidden in bumpkit.yml, or against the direction the two had before.

What to do: Move the code to the right layer, or invert the dependency with an interface. If the new direction is intended, declare it in architecture.layers.

Migration breaks running code ​

Reported as breaking from the migrations checker.

Why: A migration renames a column or table, which breaks code that is still running during the deploy.

What to do: Add the new name first and deploy code that uses it, then remove the old name in a later release.

Query inside a loop ​

Reported as performance from the n_plus_one checker.

Why: A loop runs a database query once per item, so the cost grows with the data.

What to do: Fetch everything in one query before the loop, or batch it.

Removed route ​

Reported as breaking from the routes checker.

Why: An HTTP route was removed, so clients that call it get errors.

What to do: Keep the route, redirect it, or release a major version and tell clients. If it is intended, get it approved.

Unbounded work from request input ​

Reported as performance from the unbounded checker.

Why: A loop or allocation is sized by request input with no cap, so one request can make the server do unlimited work.

What to do: Cap the input before you use it, and reject requests over the cap.

Function that only forwards ​

Reported as code_quality from the wrappers checker.

Why: A new function passes its arguments straight to another one and changes nothing.

What to do: Call the other function directly, unless the wrapper is meant to become a seam.

Migration adds a NOT NULL column ​

Reported as breaking from the migrations checker, titled Adds a NOT NULL column.

Why: The migration adds a column that can't be null and has no default, so it fails on a table that already has rows.

What to do: Give the column a default (server_default in Alembic), or add it as nullable, backfill it, and make it NOT NULL in a later migration.

Migration makes a column NOT NULL ​

Reported as migration from the migrations checker, titled Makes a column NOT NULL.

Why: The migration makes an existing column NOT NULL, which fails if any row is null and scans the whole table while it holds a lock.

What to do: Backfill the nulls first. On PostgreSQL, add a CHECK (column IS NOT NULL) NOT VALID constraint, validate it, then set NOT NULL.

Checkers ​

Checker	What it looks at
abstraction	Finds new interfaces that only one type implements.
backports	Compares the branch being released with fixes in recent release tags that never reached it.
benchmarks	Compares go test -bench results between the base and the head.
blast_radius	Follows callers of the changed functions to product areas.
blocking_io	Finds network, file and process calls added on code reached from HTTP handlers.
comment_noise	Measures how much of each file's new code is comments.
compatibility	Compares each supported pair in bumpkit.yml against the release's proven breaks and its version.
complexity	Counts each changed function's branches and compares it with gate.quality.max_complexity.
config	Notices new environment variables the code reads.
contracts	Compares OpenAPI, GraphQL, protobuf and JSON Schema contracts before and after the release.
coupling	Counts how many modules each module depends on before and after the release.
cross_repo	Checks the repositories that consume this code for calls this release breaks.
cycles	Builds the module dependency graph before and after the release and reports new import cycles.
dead_code	Finds new symbols that nothing in the repository calls or references, tests included.
dependencies	Reads manifests and lock files for added, upgraded and removed dependencies.
duplication	Finds new lines that repeat code already in the repository.
exports	Compares exported functions, types and constants before and after the release.
function_size	Measures each new or changed function against gate.quality.max_function_lines.
hot_path_complexity	Compares the complexity of functions reached from HTTP handlers before and after the release.
hotspots	Ranks changed files by how often they changed and broke in recent history.
intent	Maps acceptance criteria from the pull request, linked issues and specs to the changes, tests and behavioral results that evidence them.
layers	Checks new module dependencies against architecture.layers and architecture.forbidden in bumpkit.yml, or the direction they had at the base.
llm	A model's reading of the diff, marked as inference.
migrations	Reads schema migrations for statements that lose data, break running code or lock tables.
n_plus_one	Finds database queries inside loops.
routes	Compares the HTTP routes the code registers before and after the release.
scanner	Reads the CodeQL, Semgrep, Snyk and Socket results you send, or code scanning alerts on the pull request, and keeps the ones on lines the change touches or reaches.
secrets	Matches added lines against known credential formats and committed environment files.
security	Compares the base and the head for changes that weaken authentication, authorization, TLS, CSRF, CORS, permissions and cryptography.
sensitive	Flags changes to authentication, authorization, billing and cryptography code.
tests	Notices when code changed and no tests changed.
unbounded	Finds loops and allocations sized by request input with no cap.
versions	Checks the decided version against tags, manifests, VERSION and the CHANGELOG.
vulnerabilities	Looks up new and upgraded dependencies in the OSV vulnerability database.
wrappers	Finds new functions that only pass their arguments on to another function.

Gate reasons ​

The release gate weighs findings, approvals and CI against the repository's bumpkit.yml. Each reason names the rule that applied.

Agent wrote outside its scope ​

Reported as agent_scope.

Why: A coding agent tried to write outside the paths and areas the agents: section of bumpkit.yml gives it.

What to do: Have a person make this change, or widen the agent's paths in bumpkit.yml if it should be allowed.

Gate: agent track record below the bar ​

Reported as agent_track_record_below.

Why: The policy asks for a person's approval when the agent's record in the work this change touches (reverts, fix-ups, gate blocks and failed required checks) is below the set score.

What to do: Review the change with the numbers in the reason, then: Ask a reviewer other than the author to approve the pull request's latest commit. In an emergency, an owner, admin or policy admin can override this commit on its check page in the dashboard, which is audited.

Gate: agent over its budget or scope ​

Reported as agents.

Why: The agents: section of bumpkit.yml limits what this agent may change: its open pull requests, paths, areas, changed lines or monthly spend, and this change goes past one of them.

What to do: Keep the change inside the agent's scope, split it, or close other pull requests, then push. If the limit allows approval: Ask a reviewer other than the author to approve the pull request's latest commit. In an emergency, an owner, admin or policy admin can override this commit on its check page in the dashboard, which is audited.

When it blocks: Keep the change inside the agent's scope, split it, or close other pull requests, then push. This limit blocks, so approval can't let it through.

Gate: AI review is partial or didn't run ​

Reported as ai_review_incomplete.

Why: The policy requires a person to approve when the AI review didn't cover every changed file or couldn't run. A partial or missing AI review never blocks on its own.

What to do: Read the files listed as not reviewed, then: Ask a reviewer other than the author to approve the pull request's latest commit. In an emergency, an owner, admin or policy admin can override this commit on its check page in the dashboard, which is audited.

Gate: sensitive area needs approval ​

Reported as area.

Why: The policy requires a person to approve changes to this area.

What to do: Ask a reviewer other than the author to approve the pull request's latest commit. In an emergency, an owner, admin or policy admin can override this commit on its check page in the dashboard, which is audited.

Gate: behavior change or hotspot ​

Reported as behavior.

Why: The policy's gate.behavior asks for approval or blocks when the release proves a behavior change or changes a hotspot.

What to do: Check the change and add a test, or: Ask a reviewer other than the author to approve the pull request's latest commit. In an emergency, an owner, admin or policy admin can override this commit on its check page in the dashboard, which is audited.

When it blocks: Check the change, add a test and push. The policy blocks this kind of change, so approval can't let it through.

Gate: change reaches a guarded area ​

Reported as blast_radius.approve_areas.

Why: The change reaches code in an area that gate.blast_radius.approve_areas guards.

What to do: Ask a reviewer other than the author to approve the pull request's latest commit. In an emergency, an owner, admin or policy admin can override this commit on its check page in the dashboard, which is audited.

Gate: blocked finding ​

Reported as block_on.

Why: The policy's gate.block_on fails any release with a proven, high severity finding of this kind. Approval can't override it.

What to do: Fix the finding and push. If it is a false positive, mark it so on the release page. An owner, admin or policy admin can break glass on the check page in the dashboard if the policy allows it.

Gate: break-glass override ​

Reported as break_glass.

Why: An owner, admin or policy admin let this exact commit through the gate with a recorded reason.

What to do: Review the change after the fact with bumpkit override review. A new push needs a fresh decision.

Gate: breaking change needs approval ​

Reported as breaking.

Why: The policy requires a person to approve breaking changes and major version bumps.

What to do: Ask a reviewer other than the author to approve the pull request's latest commit. In an emergency, an owner, admin or policy admin can override this commit on its check page in the dashboard, which is audited.

Gate: CI results unverified ​

Reported as ci_unverified.

Why: The policy requires CI checks or code scanning, and only the Bumpkit GitHub App can read them.

What to do: Install the Bumpkit GitHub App on the repository, or: Ask a reviewer other than the author to approve the pull request's latest commit. In an emergency, an owner, admin or policy admin can override this commit on its check page in the dashboard, which is audited.

Gate: diff only partly checked ​

Reported as complete_check.

Why: The diff was too large to check in full, so part of the release wasn't checked. It needs an approval from someone with write access or a code owner.

What to do: Split the change into smaller pull requests, or: Ask a reviewer other than the author to approve the pull request's latest commit. In an emergency, an owner, admin or policy admin can override this commit on its check page in the dashboard, which is audited.

Gate: breaking contract change needs approval ​

Reported as contract_breaking.

Why: The policy requires a person to approve breaking changes to API contracts.

What to do: Ask a reviewer other than the author to approve the pull request's latest commit. In an emergency, an owner, admin or policy admin can override this commit on its check page in the dashboard, which is audited.

Gate: breaks a consuming repository ​

Reported as cross_repo.block_on_consumer_break.

Why: The policy's gate.cross_repo.block_on_consumer_break fails releases that break another repository's code.

What to do: Keep the old API until the consumer is updated, or update the consumer first, then push.

Gate: cross-repo change needs approval ​

Reported as cross_repo.require_approval.

Why: This release breaks, or may break, another repository that uses this code.

What to do: Tell the consumer's owners, then: Ask a reviewer other than the author to approve the pull request's latest commit. In an emergency, an owner, admin or policy admin can override this commit on its check page in the dashboard, which is audited.

Gate: denied by a reviewer ​

Reported as denied.

Why: An approver denied this change in Slack, on the release page, or with bumpkit approvals deny confirmed in the browser.

What to do: Address their concern and push a new commit, or ask them to approve instead.

Gate: open fix task ​

Reported as fix_tasks.

Why: This change left callers on a function or method whose contract it changed, and Bumpkit hasn't seen them fixed yet. The policy's gate.fix_tasks blocks (the default) or asks for approval until a gate run proves every listed place clean.

What to do: Fix every listed place, or merge the fix pull request Bumpkit opened, and push. The task is marked done only when the next gate run reads each place and finds no use of the old contract. With fix_tasks: approve, a person can approve the release instead.

Gate: declared change freeze ​

Reported as freeze.

Why: Someone declared a change freeze on the Policy page, /v1/freezes or bumpkit freeze, and it is active.

What to do: Wait until it is ended, or: Ask a reviewer other than the author to approve the pull request's latest commit. In an emergency, an owner, admin or policy admin can override this commit on its check page in the dashboard, which is audited.

When it blocks: Wait until it is ended; this freeze blocks releases. Approval can't let it through. In an emergency, an owner, admin or policy admin can override this commit on its check page in the dashboard, which is audited.

Gate: change freeze ​

Reported as freezes.

Why: A freeze in the policy's gate.freezes is active.

What to do: Wait until the freeze ends, or: Ask a reviewer other than the author to approve the pull request's latest commit. In an emergency, an owner, admin or policy admin can override this commit on its check page in the dashboard, which is audited.

When it blocks: Wait until the freeze ends; this freeze blocks releases. Approval can't let it through. In an emergency, an owner, admin or policy admin can override this commit on its check page in the dashboard, which is audited.

Gate: missing backports ​

Reported as hotfix.backports.

Why: Fixes that already shipped are missing from this branch, so shipping would bring those bugs back.

What to do: Cherry-pick the named fixes onto this branch. With backports: approve, a person can approve the release without them.

Gate: not allowed in a hotfix ​

Reported as hotfix.block_on.

Why: The policy's gate.hotfix.block_on keeps this kind of change out of hotfixes.

What to do: Move this change to a regular release and keep the hotfix to the fix.

Gate: hotfix too large ​

Reported as hotfix.max_files.

Why: The hotfix changes more files than gate.hotfix.max_files allows.

What to do: Make the hotfix smaller, or: Ask a reviewer other than the author to approve the pull request's latest commit. In an emergency, an owner, admin or policy admin can override this commit on its check page in the dashboard, which is audited.

Gate: post-hoc review due ​

Reported as hotfix.review_within.

Why: This emergency change was let through, and the policy requires a review within gate.hotfix.review_within.

What to do: Review it before the due time with bumpkit override review.

Gate: hotfix carries features ​

Reported as hotfix: feature commits.

Why: A hotfix should only fix, and this one has feat: commits.

What to do: Move the feature commits to a regular release, or: Ask a reviewer other than the author to approve the pull request's latest commit. In an emergency, an owner, admin or policy admin can override this commit on its check page in the dashboard, which is audited.

Gate: hotfix is not a patch ​

Reported as hotfix: patch only.

Why: A hotfix should be a patch release, and these changes make it minor or major.

What to do: Remove the changes that raise the version, or: Ask a reviewer other than the author to approve the pull request's latest commit. In an emergency, an owner, admin or policy admin can override this commit on its check page in the dashboard, which is audited.

Gate: acceptance criterion without evidence ​

Reported as intent.

Why: The policy requires a person to approve when an acceptance criterion has no evidence in the change.

What to do: Add the code or test that does it and push, or: Ask a reviewer other than the author to approve the pull request's latest commit. In an emergency, an owner, admin or policy admin can override this commit on its check page in the dashboard, which is audited.

Gate: org policy key is locked ​

Reported as org_policy.

Why: The workspace's org policy locks this key, so the repository's bumpkit.yml can only tighten it. The stricter value applies.

What to do: Change the setting in the org policy on the Policy page, or ask an owner or admin to unlock the key.

Gate: release policy change ​

Reported as policy_change.

Why: This change edits bumpkit.yml, .bumpkit.yml or a CODEOWNERS file on its way to the default branch. It needs one approval from someone with write access or a code owner, and a repository's policy can't turn this off.

What to do: Ask a reviewer other than the author to approve the pull request's latest commit. In an emergency, an owner, admin or policy admin can override this commit on its check page in the dashboard, which is audited.

Gate: where the policy came from ​

Reported as policy_source.

Why: Without the Bumpkit GitHub App on the repository, the gate uses the bumpkit.yml the CLI or Action sends, so it can't prove the pull request didn't loosen it. With the App, Bumpkit reads bumpkit.yml from the base branch itself and ignores the one the client sends.

What to do: Install the Bumpkit GitHub App on the repository so the gate reads the policy from the base branch.

Gate: code quality, architecture or performance ​

Reported as quality.

Why: The policy's gate.quality asks for approval or blocks when the release adds new architecture drift, AI code quality problems or performance risks at or above the set severity.

What to do: Fix the problems the findings list and push, or: Ask a reviewer other than the author to approve the pull request's latest commit. In an emergency, an owner, admin or policy admin can override this commit on its check page in the dashboard, which is audited.

When it blocks: Fix the problems the findings list and push. The policy blocks at this severity, so approval can't let it through.

Gate: required check app ​

Reported as require_check_apps.

Why: The policy's gate.require_check_apps needs each named check to pass on this commit, reported by the GitHub App the policy names. If Bumpkit can't read that evidence, the gate fails closed, and approval can't stand in for it.

What to do: Install the Bumpkit GitHub App on the repository, make sure each named check runs on the latest commit from the right app, then run the gate again.

Gate: required CI check ​

Reported as require_checks.

Why: The policy's gate.require_checks needs the named CI check to pass on this commit.

What to do: Make the check run and pass on the latest commit, then run the gate again.

Gate: regression evidence ​

Reported as require_regression_evidence.

Why: The policy's gate.require_regression_evidence asks for CI-attested results of the tests this change's blast radius reaches, on the exact commit. Results from another commit or a plain API key don't count, and a missing, partial or unreadable upload never passes. A language Bumpkit can't map to tests counts as missing.

What to do: Run bumpkit test attest in GitHub Actions on this commit and fix any failing test, or: Ask a reviewer other than the author to approve the pull request's latest commit. In an emergency, an owner, admin or policy admin can override this commit on its check page in the dashboard, which is audited.

When it blocks: Run bumpkit test attest in GitHub Actions with id-token: write on this commit and fix any failing test. The policy blocks without this evidence, so approval can't let it through.

Gate: scanner finding needs approval ​

Reported as scanner_finding.

Why: The policy requires a person to approve when a code scanner reports a problem on a line the change touches or in code it reaches. Scanner findings never block on their own.

What to do: Fix the finding and push, or: Ask a reviewer other than the author to approve the pull request's latest commit. In an emergency, an owner, admin or policy admin can override this commit on its check page in the dashboard, which is audited.

Gate: code scanning alerts ​

Reported as security_alerts.

Why: The policy's gate.security_alerts fails releases with open code scanning alerts at or above the set severity, or with no scan results.

What to do: Fix or dismiss the alerts in GitHub code scanning, make sure scanning runs on pull requests, then run the gate again.

Gate: stacked pull request ​

Reported as stacks.

Why: This pull request's base branch is another open pull request's head branch, so Bumpkit checked it against that parent's head: the decision covers only this pull request's own changes.

What to do: Merge the pull requests below it first, in stack order. When the parent's head moves, or GitHub retargets this pull request after the parent merges, Bumpkit checks it again against its new base.

Gate: parent pull request not merged ​

Reported as stacks.require_parent_merged.

Why: The policy's gate.stacks.require_parent_merged holds a stacked pull request until the pull request it is stacked on has merged.

What to do: Merge the parent pull request first. Bumpkit re-checks this pull request when the parent merges or GitHub retargets it.

Gate: untested change needs approval ​

Reported as untested.

Why: The policy requires a person to approve code that changed without tests.

What to do: Add tests and push, or: Ask a reviewer other than the author to approve the pull request's latest commit. In an emergency, an owner, admin or policy admin can override this commit on its check page in the dashboard, which is audited.

Gate: vulnerable dependency ​

Reported as vulnerabilities.

Why: The policy's gate.vulnerabilities fails releases that add a dependency with a known vulnerability at or above the set severity.

What to do: Upgrade the dependency to a fixed version, or remove it, and push.

Gate: outside release windows ​

Reported as windows.

Why: The policy only allows releases inside gate.windows, and this one is outside them.

What to do: Ship inside a release window, or: Ask a reviewer other than the author to approve the pull request's latest commit. In an emergency, an owner, admin or policy admin can override this commit on its check page in the dashboard, which is audited.

When it blocks: Ship inside a release window; the policy blocks releases outside them. Approval can't let it through. In an emergency, an owner, admin or policy admin can override this commit on its check page in the dashboard, which is audited.

Proven changes ​

Each class is a repository, an area and a kind of change. Measure only: these states don't change the release gate.

Earning ​

Reported as earning.

Why: This class has no problems so far, but not yet enough settled changes to be sure. A change settles 14 days after it ships.

What to do: Keep shipping. The count shows how far along it is.

Excluded ​

Reported as excluded.

Why: This kind of change is on the repository's never list. Dependencies, migrations and auth are on it by default.

What to do: To measure this kind, set proven.never in bumpkit.yml.

Not enough signal ​

Reported as not_enough_signal.

Why: No incident source is connected to this repository, so Bumpkit can't tell a quiet stretch from an unwatched one. No signal never reads as clean. A problem Bumpkit found anyway shows as Paused.

What to do: Connect one with bumpkit sources add, or from the Integrations page.

Paused ​

Reported as paused.

Why: A change in this class had a revert found in the diff, an incident, a hotfix or a regression in the last 90 days, so it needs more settled changes to be proven.

What to do: Open the class to see the change and what happened to it.

Proven ​

Reported as proven.

Why: Bumpkit is 95% sure that fewer than 5% of this kind of change, in this part of the repository, cause a problem. It takes 59 settled changes with no problem, or about 93 with one.

What to do: Nothing to do. This is a measurement: the release gate treats these changes as it always has.

Compatibility verdicts ​

Each supported pair declared under compatibility in bumpkit.yml gets one of these verdicts, from recorded evidence only.

Pair breaking ​

Reported as breaking.

Why: A recorded release inside the declared range has a proven break, such as a removed field, export or column. Later versions in the range carry it.

What to do: Restore what was removed in a new release, or narrow the supported range in bumpkit.yml. The pair lists each break with its file and version.

Pair compatible ​

Reported as compatible.

Why: Every recorded release of the provider inside the declared range was checked in full, and none has a proven break. Bumpkit doesn't run the consumer against the provider: this is what the provider's recorded checks prove.

What to do: Nothing to do. A new release in the range is checked the same way.

Pair not checked ​

Reported as not_checked.

Why: Bumpkit has no complete evidence for this pair: a release in the range has no recorded check, the check was cut short, or contract checks or version consistency weren't on. Not checked never means compatible.

What to do: Read the reason on the pair, turn on what it names, and run a release check for that version.

API errors ​

Error responses carry code, message, explanation, next_step and docs_url.

AGENT_DECISION_NOT_FOUND ​

Why: No agent decision with that id exists in this workspace.

What to do: Use a decision id from the Approvals page or from the pause hook's output.

APPROVAL_NOT_FOUND ​

Why: No release waits for approval with that ID in this workspace.

What to do: Run bumpkit approvals list and use an ID or check ID from there.

ATTESTATION_REUSED ​

Why: This CI token was already used to upload a report.

What to do: Run bumpkit verify again so it requests a fresh token.

CHANGELOG_ENTRY_NOT_FOUND ​

Why: No public changelog entry with that version exists for this workspace and repository.

What to do: Check the version and repository on your public changelog page, then try again with one listed there.

CHECK_NOT_FOUND ​

Why: No release check with that id exists in this workspace.

What to do: List checks with bumpkit checks list or GET /v1/checks and use an id from there.

CLAIM_HELD ​

Why: Another agent holds an active claim on this resource, so it can't be claimed now.

What to do: Take the alternative the response names, wait for the claim to expire, or coordinate with the holder the response names.

CLAIM_NOT_FOUND ​

Why: No claim with that id exists in this workspace.

What to do: List claims with bumpkit claims or GET /v1/claims and use an id from there.

CLAIM_RELEASED ​

Why: That claim was already released or expired, so it can't be renewed or released again.

What to do: Claim the resource again with bumpkit claim.

COMMITS_LIMIT_EXCEEDED ​

Why: The request has more commits than one call allows.

What to do: Split the release into several requests.

COMPATIBILITY_PAIR_NOT_FOUND ​

Why: No supported pair declared in this workspace has that key.

What to do: Run bumpkit compatibility to see each pair's key.

COMPATIBILITY_POLICY_NOT_FOUND ​

Why: Bumpkit had no bumpkit.yml to read: the GitHub App isn't installed on the repository and the request sent no policy.

What to do: Run bumpkit compatibility sync from a checkout that has bumpkit.yml, or install the GitHub App.

CONFIRMATION_DECLINED ​

Why: The person who opened the confirmation link canceled it, so no vote was recorded.

What to do: Run the command again if you still want to vote.

CONFIRMATION_EXPIRED ​

Why: The vote wasn't confirmed in the browser before its link expired, or the link belongs to another key.

What to do: Run bumpkit decisions approve or deny again and confirm within ten minutes.

CONFLICT ​

Why: This would clash with something that already exists.

What to do: Read the message, change the conflicting value, and retry.

DECISION_NOT_FOUND ​

Why: No saved release check or gate decision with that id exists in this workspace. To vote, the check also needs a recorded gate decision.

What to do: List checks with bumpkit checks list or GET /v1/checks and use an id from there. If the check was never gated, run the gate on it before voting.

DELIVERY_FAILED ​

Why: The SIEM destination didn't accept the test or redelivered event.

What to do: Check the destination's URL, credentials and network access under Settings > Audit streaming, then send the test or redelivery again.

DEPLOYMENT_NOT_FOUND ​

Why: No successful deployment of that version is recorded.

What to do: Record deploys with bumpkit deploy, POST /v1/deployments or the GitHub App.

DIGEST_FAILED ​

Why: Bumpkit couldn't deliver the digest to Slack, Discord or email.

What to do: Check the digest's destination on the Digest page, then send it again.

DIGEST_JUST_SENT ​

Why: This digest went out a few seconds ago, so Bumpkit didn't send it twice.

What to do: Wait a few seconds, then send it again if you still need to.

EARLY_ACCESS_REQUIRED ​

Why: Connecting repositories through the Bumpkit GitHub App isn't turned on for this workspace yet.

What to do: Ask Bumpkit support to turn on the GitHub App for your workspace, then try again.

EMAIL_DELIVERY_OFF ​

Why: Bumpkit can't send email right now, so it can't confirm a new address. Your sign-in email stays the same.

What to do: Try again later.

EMAIL_DOMAIN_MANAGED ​

Why: A workspace's identity provider manages this email domain, so the address can't be changed in account settings. Bumpkit checks this when you ask for the change and again when you confirm it.

What to do: Ask your workspace admin to change the address in your identity provider.

EMAIL_TAKEN ​

Why: Another Bumpkit account already uses this email address. Bumpkit checks this when you ask for the change and again when you confirm it.

What to do: Choose another address, or sign in to the account that has this one.

ENCRYPTION_REQUIRED ​

Why: This Bumpkit server stores code indexes only when encryption keys are set.

What to do: Ask your Bumpkit administrator to set encryption keys, then upload again.

EXPIRED_INGEST_KEY ​

Why: The ingest key is past its expiration date.

What to do: Create a new ingest key on the Agent telemetry page and replace the old one wherever it's set.

EXPORT_TOO_LARGE ​

Why: The requested evidence export covers more records than one export can hold.

What to do: Export a shorter date range, or one repository at a time.

FEATURE_DISABLED ​

Why: The request pins the workspace to a region, and regional hosting isn't on for this workspace.

What to do: Leave region out of the request, or contact Bumpkit support about regional hosting.

FEATURE_EARLY_ACCESS ​

Why: This feature is in early access. It's on only for the teams it has been rolled out to so far, and your workspace isn't one of them yet.

What to do: Open the link in the message and choose Sign me up for early access. We'll email you as soon as it's on for your workspace.

FEATURE_UNAVAILABLE ​

Why: This integration isn't turned on for this workspace, so Bumpkit won't start its OAuth consent.

What to do: Ask Bumpkit support to turn the integration on for your workspace, then start the connection again.

FINDING_NOT_FOUND ​

Why: No finding with that id exists in this workspace.

What to do: Use a finding id from a check in this workspace.

FORBIDDEN ​

Why: Your role isn't allowed to do this.

What to do: Ask an owner or admin to do it, or to give you a role that can.

GITHUB_APP_REQUIRED ​

Why: This needs the Bumpkit GitHub App installed on the repository for this workspace.

What to do: Install the GitHub App on the repository from Settings, then try again.

GITHUB_UNAVAILABLE ​

Why: GitHub didn't answer a request Bumpkit needed: authorizing the App, listing or verifying its repositories, or reading and opening pull requests.

What to do: Retry shortly. If it keeps failing, review the Bumpkit GitHub App installation and its repository access.

GITHUB_WRITE_REQUIRED ​

Why: Opening a pull request needs the Bumpkit GitHub App to have Contents: write and Pull requests: write on the repository, and this installation doesn't. Release checks keep working without it.

What to do: Grant the Bumpkit App Contents and Pull requests write access, then approve the update in GitHub and try again.

HUMAN_APPROVAL_REQUIRED ​

Why: Release-gate votes, gate overrides, agent command decisions and release batch approvals and cuts are a person's call, so an API key, CLI token or MCP tool can't do them on its own.

What to do: Overrides, agent commands and release batches: open the link in the message and do it there while signed in to the dashboard. Vote on the release in the dashboard, or run bumpkit decisions approve CHECK_ID and confirm it in your browser while signed in.

IDEMPOTENCY_KEY_REUSED ​

Why: This Idempotency-Key was already used for a different request.

What to do: Use a new key for each different request; reuse a key only to retry the same request.

INCIDENT_NOT_FOUND ​

Why: No incident with that id exists in this workspace.

What to do: Use an incident id from the Incidents page or bumpkit incidents list.

INCIDENT_NOT_TRACED ​

Why: Bumpkit hasn't traced this incident to a release, so it doesn't know which commits to revert.

What to do: Open the rollback from the release instead, with bumpkit rollback open <version>, such as bumpkit rollback open v1.4.0.

INSUFFICIENT_SIGNAL ​

Why: The commit messages say too little to decide the version.

What to do: Write Conventional Commits, such as feat: or fix:, and call again.

INTERNAL_ERROR ​

Why: Something failed inside Bumpkit.

What to do: Retry. If it keeps happening, contact Bumpkit support with the time of the request.

INVALID_API_KEY ​

Why: The API key is malformed or doesn't exist.

What to do: Check the key, or create a new one on the API keys page.

INVALID_ATTESTATION ​

Why: The CI attestation sent with a behavioral verification report didn't verify.

What to do: Run bumpkit verify in GitHub Actions with id-token: write permission, on the commit the report is for.

INVALID_BODY ​

Why: Bumpkit couldn't read the uploaded file before the connection ended.

What to do: Upload the file again.

INVALID_COMMIT_SHAPE ​

Why: A commit is missing its message or has a field of the wrong type.

What to do: Give each commit a non-empty message string. The field in the error says which one.

INVALID_IDEMPOTENCY_KEY ​

Why: The Idempotency-Key header isn't 1 to 200 letters, digits, dots, colons, dashes or underscores.

What to do: Send a shorter key made of those characters, or leave the header out.

INVALID_INDEX ​

Why: The uploaded file isn't a SCIP index Bumpkit can read.

What to do: Upload the index.scip file your SCIP indexer wrote, unchanged.

INVALID_INGEST_KEY ​

Why: The request has no ingest key in the x-bumpkit-ingest-key header, or the key doesn't exist.

What to do: Create an ingest key on the Agent telemetry page and send its secret in the x-bumpkit-ingest-key header.

INVALID_JSON ​

Why: The request body isn't valid JSON, or isn't an object or array.

What to do: Send a JSON object with Content-Type: application/json.

INVALID_OIDC_TOKEN ​

Why: The CI job's OIDC token didn't verify, so the coverage upload can't count as evidence.

What to do: Upload from the CI job itself with id-token: write, so a fresh token is sent.

INVALID_OTLP ​

Why: The body isn't a valid OTLP export request.

What to do: Point a standard OpenTelemetry OTLP/HTTP exporter at the ingest endpoint instead of building the body by hand.

INVALID_POLICY ​

Why: bumpkit.yml doesn't parse, so the gate fails closed.

What to do: Fix the line the message names. The gate stays failed until the file parses.

INVALID_PROVIDER ​

Why: repository.provider isn't one Bumpkit knows.

What to do: Use github, gitlab or bitbucket.

INVALID_REPOSITORY_URL ​

Why: repository.url isn't a valid URL.

What to do: Send the repository's full web address, the one you open in a browser.

INVALID_SCANNER_RESULTS ​

Why: A scanner report in scans isn't one Bumpkit can read: the format isn't sarif or socket, the file is over 4 MiB, it isn't valid JSON, a Socket full scan is empty, the SARIF version isn't 2.1.0, a run has no tool name, or there are more than 5 reports.

What to do: Send SARIF 2.1.0 from CodeQL, Semgrep or Snyk, or Socket's Stream full scan response, each under 4 MiB, up to 5 per check.

INVALID_SIGNATURE ​

Why: A webhook's signature didn't match its secret.

What to do: Check that the sender uses the secret shown in Bumpkit, and that nothing rewrites the body on the way.

INVALID_VERSION_FORMAT ​

Why: previous_version isn't a semantic version.

What to do: Send a version like 1.4.2.

IP_NOT_ALLOWED ​

Why: The request came from an address that isn't on the ingest key's IP allowlist.

What to do: Send from an allowed address, or add this address to the key's allowlist on the Agent telemetry page.

KEY_NOT_FOUND ​

Why: No evidence signing key has that id.

What to do: List the published keys and use the id from the bundle's signature.

LESSON_NOT_FOUND ​

Why: No lesson with that id exists in this workspace.

What to do: List lessons with bumpkit lessons list or GET /v1/lessons and use an id from there.

LINEAR_ACCESS_FAILED ​

Why: Linear refused the API key when Bumpkit listed its teams.

What to do: Check that the Linear key has Read permission and access to the team you want, then load teams again.

LINEAR_UNAVAILABLE ​

Why: Bumpkit couldn't reach Linear to list its teams.

What to do: Load teams again in a moment.

LLM_NOT_CONFIGURED ​

Why: This needs a language model, and none is available for this workspace.

What to do: Retry later. If it keeps happening, contact Bumpkit support.

LOGIN_EXPIRED ​

Why: The CLI sign-in request expired before it was approved.

What to do: Run bumpkit login again and approve it in the browser within a few minutes.

MEMBER_NOT_FOUND ​

Why: That pull request isn't in this release train.

What to do: Read the train with bumpkit train show or GET /v1/trains/{id} to see its pull requests.

MEMORY_NOT_FOUND ​

Why: No memory with that id exists in this workspace.

What to do: List memories with bumpkit memory list and use an id from there.

MIRROR_UNAVAILABLE ​

Why: Bumpkit couldn't fetch the repository from GitHub to prepare the change, so it opened nothing.

What to do: Try again in a minute. If it keeps failing, check that the Bumpkit App can read the repository's contents, and contact support with the reference.

MISSING_API_KEY ​

Why: The request has no x-api-key header.

What to do: Create a key on the API keys page and send it in the x-api-key header, or run bumpkit login.

MISSING_COMMITS ​

Why: The request has no commits, or commits isn't an array with at least one commit.

What to do: Send commits as an array with at least one commit object.

MULTI_TRAIN_HELD ​

Why: An earlier step on this multi-repo train hasn't released yet, and a step never skips the ones ahead of it.

What to do: Release the earlier step first. bumpkit train multi show lists what holds this one.

MULTI_TRAIN_NOT_FOUND ​

Why: No multi-repo train with that id exists in this workspace.

What to do: List your trains with bumpkit train multi list or GET /v1/multi-trains and use an id from there.

MULTI_TRAIN_ORDER_CONFLICT ​

Why: That order puts a repository ahead of something it depends on, according to the service map.

What to do: Put the dependency first. If the map is out of date, refresh the service graph and set the order again.

MULTI_TRAIN_ORDER_NEEDED ​

Why: Bumpkit can't prove this train's order: an edge is missing, a cycle exists, or the service map changed. It never guesses, so no step can start.

What to do: Read what's missing with bumpkit train multi show, then have a person set the order on the train's page in the dashboard.

NOT_CONFIGURED ​

Why: OAuth for this integration isn't set up in Bumpkit yet, so Bumpkit can't send you to the provider to approve access.

What to do: Contact Bumpkit support about setting up this integration, then start the connection again.

NOT_FOUND ​

Why: There is nothing at this path, the resource doesn't exist in this workspace, or the feature isn't available.

What to do: Check the method, path and id against the API reference. A Beta feature your workspace doesn't have yet usually answers FEATURE_EARLY_ACCESS instead, with a link to request it.

NOT_SHIPPED ​

Why: The commit this release check covers isn't on the repository's default branch, so nothing from it has shipped and there's nothing to revert. This is what you see for a check on a pull request that's still open.

What to do: Close or update the pull request instead. Rollback becomes available once the change is merged.

NOT_STORED ​

Why: The workspace's data retention is ephemeral, so Bumpkit didn't keep this.

What to do: Change data retention on the Data handling page to keep it in future.

NO_DESTINATION ​

Why: The digest has nowhere it could be delivered, so nothing was sent. The message lists what failed for each destination.

What to do: Add or fix the digest's Slack, Discord or email destination on the Digest page, then send it again.

OIDC_MISMATCH ​

Why: The CI OIDC token was issued for another repository or commit than the upload names.

What to do: Upload coverage from the job that built that repository and commit.

ORG_POLICY_UNAVAILABLE ​

Why: Bumpkit couldn't read the workspace's org policy, so the gate fails closed.

What to do: Check the org policy's config repository and the GitHub App's access to it, then run the check again.

PAYLOAD_TOO_LARGE ​

Why: The request body is larger than this endpoint accepts.

What to do: Keep the request within the endpoint's documented bound. Do not truncate a release diff or treat separate partial checks as a decision for the full release.

POLICY_UNAVAILABLE ​

Why: The Bumpkit GitHub App or a GitHub Enterprise Server connection covers this repository, so the gate reads bumpkit.yml itself, and the host didn't return it.

What to do: Check the App's or the connection's access to the repository, then run the gate again.

PROVENANCE_SESSION_CONFLICT ​

Why: Another account or API key started this agent session, and a session stays bound to whoever started it.

What to do: Start a new agent session so it gets a new session ID, or send the events with the key that started it.

PROVEN_CLASS_NOT_FOUND ​

Why: No pull request merged in the last 180 days falls in that repository, area and kind.

What to do: Run bumpkit proven to see the classes that have changes.

PUBLISH_FAILED ​

Why: Bumpkit couldn't publish to one of the targets.

What to do: Check that integration's connection on the Integrations page, then publish again.

PULL_REQUEST_NOT_FOUND ​

Why: GitHub has no pull request with that number in the train's repository.

What to do: Check the number and the repository, then add the pull request again.

QUOTA_EXCEEDED ​

Why: The workspace already has as many active test databases as it's allowed.

What to do: Release one with bumpkit testdb release, or wait for a lease to expire.

RATE_LIMIT_EXCEEDED ​

Why: Too many requests in a short time.

What to do: Wait for the Retry-After or X-RateLimit-Reset-Minute time, then retry. Batch work where you can.

RELEASE_APPROVAL_IN_BROWSER ​

Why: Approving or denying a release draft is a person's vote, so the API doesn't record it from an inbox decision. Nothing is wrong with your role.

What to do: Run bumpkit release approve RELEASE_ID, or bumpkit inbox approve release_batch:RELEASE_ID, and confirm the vote in your browser.

RELEASE_NOT_FOUND ​

Why: No grouped release with that id exists in this workspace.

What to do: List releases with bumpkit release list or GET /v1/releases and use an id from there.

RELEASE_PUBLISH_COMMAND ​

Why: Publishing an approved release runs from its own command, not from an inbox decision. Nothing is wrong with your role.

What to do: Run bumpkit release publish RELEASE_ID, or bumpkit inbox approve release_publish:RELEASE_ID.

REPLAYED_REQUEST ​

Why: Bumpkit already handled this Slack request, so it didn't run it a second time.

What to do: Run the slash command again in Slack if you still need it.

REPOSITORY_ACCESS_REQUIRED ​

Why: Bumpkit can't read the repository through a GitHub App installation linked to this workspace: the App isn't installed, the repository isn't selected, or the installation belongs to another workspace.

What to do: Install the Bumpkit GitHub App from this workspace, select the repository in the installation, then run bumpkit repo verify again.

REPOSITORY_CONNECTION_UNAVAILABLE ​

Why: Bumpkit's GitHub connection is unavailable right now, so it can't list or verify repositories.

What to do: Try again later. If it keeps happening, contact Bumpkit support.

REPOSITORY_NOT_FOUND ​

Why: Bumpkit couldn't read the repository or one of its refs.

What to do: Check owner/name and the refs. For a private repository, install the Bumpkit GitHub App or send the diff yourself.

REQUEST_IN_PROGRESS ​

Why: The same request is still being checked.

What to do: Retry in a moment; you'll get the stored result once it finishes.

REVERT_FAILED ​

Why: Bumpkit fetched the repository but couldn't apply the revert in its workspace, so it opened nothing.

What to do: Run the git revert command in the message by hand, or contact support with the reference.

REVOKED_API_KEY ​

Why: The API key was revoked or has expired.

What to do: Create a new key on the API keys page and replace the old one.

REVOKED_INGEST_KEY ​

Why: The ingest key was revoked, so Bumpkit rejects what it sends.

What to do: Create a new ingest key on the Agent telemetry page and replace the old one wherever it's set.

ROLE_REQUIRED ​

Why: Evidence exports and the audit event stream are limited to owners, admins and auditors, and publishing release docs is limited to roles that can make changes. The API key's role isn't allowed here. Keys that aren't tied to a person, such as CI keys, have no role.

What to do: Use an API key created by someone with the role the message names, or ask an owner to give you that role.

ROLLBACK_NOT_FOUND ​

Why: No rollback plan with that id exists in this workspace.

What to do: Make a plan with bumpkit rollback plan and use its id.

RULE_NOT_REPRESENTABLE ​

Why: The plain-English rule asks for something bumpkit.yml can't express.

What to do: Rephrase it in terms of breaking changes, untested code, areas, approvers or required checks.

SERVICE_UNAVAILABLE ​

Why: A service Bumpkit needs is down for a moment.

What to do: Retry shortly, and check the status page if there is one.

SIGNING_KEY_INVALID ​

Why: Bumpkit can't sign provenance attestations right now.

What to do: Contact Bumpkit support, then try again.

SIGNING_UNAVAILABLE ​

Why: Bumpkit has no evidence signing key configured, so it can't sign the evidence bundle.

What to do: Contact Bumpkit support, then export again.

TELEMETRY_OFF ​

Why: Agent telemetry is turned off for this workspace, so Bumpkit stored nothing.

What to do: Ask a workspace admin to turn on agent telemetry on the Agent telemetry page, then send again.

TRAIN_NOT_FOUND ​

Why: No release train with that id exists in this workspace.

What to do: List trains with bumpkit train list or GET /v1/trains and use an id from there.

TRAIN_NOT_READY ​

Why: The release train isn't ready to cut: one of its pull requests is blocked or still needs approval.

What to do: Fix what the message lists and check readiness again. In an emergency, an owner or admin can cut it with a reason on the release batch page in the dashboard, which is audited.

TRAIN_TOO_LARGE ​

Why: The target branch has more commits since the last release than Bumpkit reads in one comparison, so the version could miss a change.

What to do: Tag a release closer to the train, or have an owner or admin cut it with a reason on the release batch page in the dashboard.

UNAUTHORIZED ​

Why: The MCP request reached Bumpkit without a valid sign-in, so no tool ran.

What to do: Connect Bumpkit to your MCP client again and sign in when it asks.

UNSUPPORTED_MEDIA_TYPE ​

Why: The body's Content-Type or Content-Encoding isn't one the ingest endpoint accepts.

What to do: Send OTLP as application/x-protobuf or application/json, uncompressed or gzip-compressed.

UNTRUSTED_PROXY ​

Why: The request didn't reach Bumpkit through its public API endpoint.

What to do: Send requests to the public API URL.

UPSTREAM_ERROR ​

Why: A service Bumpkit called, such as GitHub, Stripe or email, failed.

What to do: Retry shortly. If it keeps failing, check that integration's settings.

USAGE_BILLING_NOT_CONFIGURED ​

Why: Credit purchases aren't enabled yet.

What to do: Contact the Bumpkit team at hello@bumpkit.dev to buy credits. No payment session was created.

VALIDATION_ERROR ​

Why: The request body or a parameter doesn't have the expected shape.

What to do: Fix the field the message names. The API reference shows each request shape.

VOTE_RECORDED_REFRESH_FAILED ​

Why: The vote was recorded, but Bumpkit couldn't update the gate result on GitHub yet.

What to do: Wait a minute and reload. The check updates on the next gate run, or re-run it from the release page.

VOTE_REFUSED ​

Why: Bumpkit didn't record the vote. The message says why: for example the release has no pull request gate decision on an exact commit, a newer commit was pushed, you opened the pull request, your role or GitHub account can't vote, or the policy doesn't list you as an approver.

What to do: Open the release in the dashboard to see who can approve and what is still needed.

WRONG_REGION ​

Why: This workspace is pinned to another region.

What to do: Send the request to the endpoint named in the message.